From 8e6deda6a5dadc276ebfd8ab46c097cacba75361 Mon Sep 17 00:00:00 2001 From: Sam Ricotta Date: Thu, 20 Jul 2023 14:07:20 +0200 Subject: [PATCH] Update versioning to have each version file in repo --- custom-version-plugin.js | 78 - docs/integrate/_category_.json | 2 +- .../building-modules/transaction_flow.svg | 48 + docs/integrate/libraries/02-collections.md | 2 +- docusaurus.config.js | 8 - version_config.json | 31 - .../develop/advanced-concepts/README.md | 28 + .../develop/advanced-concepts/baseapp.md | 399 ++++ .../baseapp_state-begin_block.png | Bin 0 -> 20565 bytes .../baseapp_state-checktx.png | Bin 0 -> 82308 bytes .../baseapp_state-commit.png | Bin 0 -> 47662 bytes .../baseapp_state-deliver_tx.png | Bin 0 -> 59007 bytes .../baseapp_state-initchain.png | Bin 0 -> 32800 bytes .../advanced-concepts/baseapp_state_types.png | Bin 0 -> 133747 bytes .../develop/advanced-concepts/cli.md | 156 ++ .../develop/advanced-concepts/context.md | 104 + .../develop/advanced-concepts/encoding.md | 261 ++ .../develop/advanced-concepts/events.md | 137 ++ .../develop/advanced-concepts/grpc_rest.md | 116 + .../advanced-concepts/keeper_dependencies.svg | 102 + .../develop/advanced-concepts/node.md | 76 + .../develop/advanced-concepts/ocap.md | 79 + .../advanced-concepts/runtx_middleware.md | 73 + .../develop/advanced-concepts/simulation.md | 101 + .../develop/advanced-concepts/store.md | 257 ++ .../develop/advanced-concepts/telemetry.md | 145 ++ .../advanced-concepts/transaction_flow.svg | 48 + .../develop/advanced-concepts/transactions.md | 159 ++ .../develop/advanced-concepts/upgrade.md | 160 ++ .../develop/high-level-concepts/README.md | 17 + .../develop/high-level-concepts/accounts.md | 153 ++ .../high-level-concepts/app-anatomy.md | 264 +++ .../develop/high-level-concepts/gas-fees.md | 89 + .../high-level-concepts/query-lifecycle.md | 152 ++ .../high-level-concepts/tx-lifecycle.md | 256 ++ .../version-0.45/develop/intro/README.md | 16 + .../version-0.45/develop/intro/overview.md | 37 + .../develop/intro/sdk-app-architecture.md | 97 + .../version-0.45/develop/intro/sdk-design.md | 95 + .../develop/intro/why-app-specific.md | 81 + .../integrate/architecture/PROCESS.md | 56 + .../integrate/architecture/README.md | 79 + .../architecture/adr-002-docs-structure.md | 86 + .../adr-003-dynamic-capability-store.md | 344 +++ .../adr-004-split-denomination-keys.md | 120 + .../adr-006-secret-store-replacement.md | 54 + .../adr-007-specialization-groups.md | 177 ++ .../architecture/adr-008-dCERT-group.md | 171 ++ .../architecture/adr-009-evidence-module.md | 182 ++ .../adr-010-modular-antehandler.md | 285 +++ .../adr-011-generalize-genesis-accounts.md | 170 ++ .../architecture/adr-012-state-accessors.md | 155 ++ .../integrate/architecture/adr-013-metrics.md | 157 ++ .../adr-014-proportional-slashing.md | 85 + ...dr-016-validator-consensus-key-rotation.md | 125 + .../adr-017-historical-header-module.md | 61 + .../adr-018-extendable-voting-period.md | 66 + .../adr-019-protobuf-state-encoding.md | 379 +++ .../adr-020-protobuf-transaction-encoding.md | 464 ++++ .../adr-021-protobuf-query-encoding.md | 256 ++ .../adr-022-custom-panic-handling.md | 213 ++ .../architecture/adr-023-protobuf-naming.md | 263 +++ .../architecture/adr-024-coin-metadata.md | 139 ++ ...27-deterministic-protobuf-serialization.md | 314 +++ .../adr-028-public-key-addresses.md | 329 +++ .../architecture/adr-029-fee-grant-module.md | 153 ++ .../architecture/adr-030-authz-module.md | 249 ++ .../architecture/adr-031-msg-service.md | 202 ++ .../architecture/adr-032-typed-events.md | 319 +++ .../adr-033-protobuf-inter-module-comm.md | 400 ++++ .../architecture/adr-034-account-rekeying.md | 76 + .../adr-035-rosetta-api-support.md | 211 ++ .../adr-036-arbitrary-signature.md | 132 ++ .../architecture/adr-037-gov-split-vote.md | 111 + .../architecture/adr-038-state-listening.md | 569 +++++ .../architecture/adr-039-epoched-staking.md | 122 + ...r-040-storage-and-smt-state-commitments.md | 164 ++ .../adr-041-in-place-store-migrations.md | 167 ++ .../architecture/adr-042-group-module.md | 279 +++ .../integrate/architecture/adr-template.md | 60 + .../integrate/building-modules/README.md | 23 + .../building-modules/beginblock-endblock.md | 39 + .../integrate/building-modules/errors.md | 50 + .../integrate/building-modules/genesis.md | 60 + .../integrate/building-modules/intro.md | 92 + .../integrate/building-modules/invariants.md | 88 + .../integrate/building-modules/keeper.md | 85 + .../building-modules/messages-and-queries.md | 115 + .../building-modules/module-interfaces.md | 139 ++ .../building-modules/module-manager.md | 150 ++ .../building-modules/msg-services.md | 134 ++ .../building-modules/query-services.md | 77 + .../integrate/building-modules/simulator.md | 123 + .../integrate/building-modules/structure.md | 99 + .../building-modules/transaction_flow.svg | 48 + .../integrate/building-modules/upgrade.md | 57 + .../version-0.45/integrate/ibc/README.md | 12 +- .../version-0.45/integrate/ibc/custom.md | 4 +- .../version-0.45/integrate/ibc/integration.md | 4 +- .../version-0.45/integrate/ibc/overview.md | 4 +- .../version-0.45/integrate/ibc/relayer.md | 2 +- .../integrate/ibc/upgrades/README.md | 4 +- .../integrate/ibc/upgrades/developer-guide.md | 2 +- .../user/run-node/interact-node.md | 227 ++ .../version-0.45/user/run-node/keyring.md | 132 ++ .../version-0.45/user/run-node/rosetta.md | 133 ++ .../version-0.45/user/run-node/run-node.md | 124 + .../version-0.45/user/run-node/run-testnet.md | 95 + .../version-0.45/user/run-node/txs.md | 355 +++ .../develop/advanced-concepts/00-baseapp.md | 166 +- .../advanced-concepts/01-transactions.md | 98 +- .../develop/advanced-concepts/03-context.md | 103 + .../develop/advanced-concepts/04-node.md | 77 + .../{04-store.md => 05-store.md} | 20 +- .../develop/advanced-concepts/07-encoding.md | 292 +++ .../develop/advanced-concepts/08-grpc_rest.md | 99 + .../develop/advanced-concepts/09-cli.md | 156 ++ .../develop/advanced-concepts/10-events.md | 139 ++ .../develop/advanced-concepts/11-telemetry.md | 130 + .../develop/advanced-concepts/12-ocap.md | 78 + .../advanced-concepts/13-runtx_middleware.md | 69 + .../advanced-concepts/13-simulation.md | 101 + .../advanced-concepts/14-proto-docs.md | 7 + .../develop/advanced-concepts/15-tips.md | 206 ++ .../develop/advanced-concepts/16-upgrade.md | 160 ++ .../develop/advanced-concepts/_category_.json | 5 + .../advanced-concepts/keeper_dependencies.svg | 102 + .../develop/high-level-concepts/README.md | 17 + .../{03-accounts.md => accounts.md} | 64 +- .../high-level-concepts/app-anatomy.md | 256 ++ .../develop/high-level-concepts/gas-fees.md | 85 + .../high-level-concepts/query-lifecycle.md | 138 ++ .../high-level-concepts/tx-lifecycle.md | 257 ++ .../version-0.46/develop/intro/README.md | 16 + .../version-0.46/develop/intro/overview.md | 37 + .../develop/intro/sdk-app-architecture.md | 97 + .../version-0.46/develop/intro/sdk-design.md | 97 + .../develop/intro/why-app-specific.md | 81 + .../version-0.46/integrate/CosmWasm/README.md | 13 + .../integrate/architecture/PROCESS.md | 56 + .../integrate/architecture/README.md | 87 + .../architecture/adr-002-docs-structure.md | 86 + .../adr-003-dynamic-capability-store.md | 344 +++ .../adr-004-split-denomination-keys.md | 120 + .../adr-006-secret-store-replacement.md | 54 + .../adr-007-specialization-groups.md | 177 ++ .../architecture/adr-008-dCERT-group.md | 171 ++ .../architecture/adr-009-evidence-module.md | 182 ++ .../adr-010-modular-antehandler.md | 290 +++ .../adr-011-generalize-genesis-accounts.md | 170 ++ .../architecture/adr-012-state-accessors.md | 155 ++ .../integrate/architecture/adr-013-metrics.md | 157 ++ .../adr-014-proportional-slashing.md | 85 + ...dr-016-validator-consensus-key-rotation.md | 125 + .../adr-017-historical-header-module.md | 61 + .../adr-018-extendable-voting-period.md | 66 + .../adr-019-protobuf-state-encoding.md | 379 +++ .../adr-020-protobuf-transaction-encoding.md | 464 ++++ .../adr-021-protobuf-query-encoding.md | 256 ++ .../adr-022-custom-panic-handling.md | 218 ++ .../architecture/adr-023-protobuf-naming.md | 263 +++ .../architecture/adr-024-coin-metadata.md | 139 ++ ...27-deterministic-protobuf-serialization.md | 314 +++ .../adr-028-public-key-addresses.md | 329 +++ .../architecture/adr-029-fee-grant-module.md | 153 ++ .../architecture/adr-030-authz-module.md | 259 ++ .../architecture/adr-031-msg-service.md | 202 ++ .../architecture/adr-032-typed-events.md | 319 +++ .../adr-033-protobuf-inter-module-comm.md | 400 ++++ .../architecture/adr-034-account-rekeying.md | 76 + .../adr-035-rosetta-api-support.md | 211 ++ .../adr-036-arbitrary-signature.md | 132 ++ .../architecture/adr-037-gov-split-vote.md | 111 + .../architecture/adr-038-state-listening.md | 569 +++++ .../architecture/adr-039-epoched-staking.md | 122 + ...r-040-storage-and-smt-state-commitments.md | 289 +++ .../adr-041-in-place-store-migrations.md | 167 ++ .../architecture/adr-042-group-module.md | 279 +++ .../architecture/adr-043-nft-module.md | 340 +++ .../adr-044-protobuf-updates-guidelines.md | 138 ++ .../adr-045-check-delivertx-middlewares.md | 312 +++ .../architecture/adr-046-module-params.md | 184 ++ .../adr-047-extend-upgrade-plan.md | 245 ++ .../architecture/adr-048-consensus-fees.md | 203 ++ .../architecture/adr-049-state-sync-hooks.md | 160 ++ .../adr-053-go-module-refactoring.md | 109 + .../integrate/architecture/adr-055-orm.md | 111 + .../integrate/architecture/adr-template.md | 60 + .../integrate/building-modules/README.md | 23 + .../building-modules/beginblock-endblock.md | 39 + .../integrate/building-modules/errors.md | 50 + .../integrate/building-modules/genesis.md | 60 + .../integrate/building-modules/intro.md | 92 + .../integrate/building-modules/invariants.md | 80 + .../integrate/building-modules/keeper.md | 85 + .../building-modules/messages-and-queries.md | 115 + .../building-modules/module-interfaces.md | 139 ++ .../building-modules/module-manager.md | 151 ++ .../building-modules/msg-services.md | 100 + .../building-modules/query-services.md | 77 + .../integrate/building-modules/simulator.md | 122 + .../{11-structure.md => structure.md} | 34 +- .../building-modules/transaction_flow.svg | 48 + .../integrate/building-modules/upgrade.md | 57 + .../version-0.46/integrate/ibc/README.md | 9 + .../integrate/migrations/README.md | 13 + .../integrate/migrations/pre-upgrade.md | 55 + .../integrate/modules/auth/01_concepts.md | 43 + .../integrate/modules/auth/02_state.md | 73 + .../integrate/modules/auth/03_antehandlers.md | 40 + .../integrate/modules/auth/04_keepers.md | 47 + .../integrate/modules/auth/05_vesting.md | 630 +++++ .../integrate/modules/auth/06_params.md | 15 + .../integrate/modules/auth/07_client.md | 421 ++++ .../integrate/modules/auth/README.md | 45 + .../integrate/modules/authz/01_concepts.md | 55 + .../integrate/modules/authz/02_state.md | 23 + .../integrate/modules/authz/03_messages.md | 46 + .../integrate/modules/authz/04_events.md | 7 + .../integrate/modules/authz/05_client.md | 172 ++ .../integrate/modules/authz/README.md | 30 + .../integrate/modules/bank/01_state.md | 19 + .../integrate/modules/bank/02_keepers.md | 135 ++ .../integrate/modules/bank/03_messages.md | 28 + .../integrate/modules/bank/04_events.md | 149 ++ .../integrate/modules/bank/05_params.md | 24 + .../integrate/modules/bank/06_client.md | 390 +++ .../integrate/modules/bank/README.md | 106 + .../modules/capability/01_concepts.md | 35 + .../integrate/modules/capability/02_state.md | 26 + .../integrate/modules/capability/README.md | 77 + .../integrate/modules/crisis/01_state.md | 17 + .../integrate/modules/crisis/02_messages.md | 25 + .../integrate/modules/crisis/03_events.md | 18 + .../integrate/modules/crisis/04_params.md | 11 + .../integrate/modules/crisis/05_client.md | 31 + .../integrate/modules/crisis/README.md | 26 + .../modules/distribution/01_concepts.md | 34 + .../modules/distribution/02_state.md | 65 + .../modules/distribution/03_begin_block.md | 87 + .../modules/distribution/04_messages.md | 122 + .../modules/distribution/05_hooks.md | 59 + .../modules/distribution/06_events.md | 48 + .../modules/distribution/07_params.md | 17 + .../modules/distribution/08_client.md | 469 ++++ .../integrate/modules/distribution/README.md | 106 + .../integrate/modules/evidence/01_concepts.md | 78 + .../integrate/modules/evidence/02_state.md | 19 + .../integrate/modules/evidence/03_messages.md | 55 + .../integrate/modules/evidence/04_events.md | 18 + .../integrate/modules/evidence/05_params.md | 7 + .../modules/evidence/06_begin_block.md | 154 ++ .../integrate/modules/evidence/07_client.md | 188 ++ .../integrate/modules/evidence/README.md | 40 + .../integrate/modules/feegrant/01_concepts.md | 93 + .../integrate/modules/feegrant/02_state.md | 23 + .../integrate/modules/feegrant/03_messages.md | 17 + .../integrate/modules/feegrant/04_events.md | 33 + .../integrate/modules/feegrant/05_client.md | 184 ++ .../integrate/modules/feegrant/README.md | 37 + .../integrate/modules/gov/01_concepts.md | 203 ++ .../integrate/modules/gov/02_state.md | 217 ++ .../integrate/modules/gov/03_messages.md | 183 ++ .../integrate/modules/gov/04_events.md | 65 + .../modules/gov/05_future_improvements.md | 30 + .../integrate/modules/gov/06_params.md | 28 + .../integrate/modules/gov/07_client.md | 1804 ++++++++++++++ .../integrate/modules/gov/08_metadata.md | 32 + .../integrate/modules/gov/README.md | 65 + .../integrate/modules/mint/01_concepts.md | 28 + .../integrate/modules/mint/02_state.md | 21 + .../integrate/modules/mint/03_begin_block.md | 66 + .../integrate/modules/mint/04_params.md | 16 + .../integrate/modules/mint/05_events.md | 16 + .../integrate/modules/mint/06_client.md | 224 ++ .../integrate/modules/mint/README.md | 26 + .../integrate/modules/params/01_keeper.md | 19 + .../integrate/modules/params/02_subspace.md | 38 + .../integrate/modules/params/README.md | 29 + .../integrate/modules/slashing/01_concepts.md | 57 + .../integrate/modules/slashing/02_state.md | 51 + .../integrate/modules/slashing/03_messages.md | 51 + .../modules/slashing/04_begin_block.md | 98 + .../integrate/modules/slashing/05_hooks.md | 45 + .../integrate/modules/slashing/06_events.md | 46 + .../modules/slashing/07_tombstone.md | 127 + .../integrate/modules/slashing/08_params.md | 15 + .../integrate/modules/slashing/09_client.md | 294 +++ .../integrate/modules/slashing/README.md | 49 + .../integrate/modules/staking/01_state.md | 215 ++ .../modules/staking/02_state_transitions.md | 180 ++ .../integrate/modules/staking/03_messages.md | 175 ++ .../modules/staking/04_begin_block.md | 16 + .../integrate/modules/staking/05_end_block.md | 77 + .../integrate/modules/staking/06_hooks.md | 27 + .../integrate/modules/staking/07_events.md | 90 + .../integrate/modules/staking/08_params.md | 16 + .../integrate/modules/staking/09_client.md | 2101 +++++++++++++++++ .../integrate/modules/staking/README.md | 56 + .../staking/begin_redelegation_sequence.svg | 106 + .../modules/staking/delegation_sequence.svg | 192 ++ .../modules/staking/unbond_sequence.svg | 110 + .../integrate/modules/upgrade/01_concepts.md | 104 + .../integrate/modules/upgrade/02_state.md | 20 + .../integrate/modules/upgrade/03_events.md | 8 + .../integrate/modules/upgrade/04_client.md | 459 ++++ .../integrate/modules/upgrade/README.md | 31 + .../version-0.46/integrate/rfc/README.md | 34 - .../version-0.46/user/run-node/README.md | 17 + .../user/run-node/interact-node.md | 252 ++ .../version-0.46/user/run-node/keyring.md | 136 ++ .../version-0.46/user/run-node/rosetta.md | 112 + .../version-0.46/user/run-node/run-node.md | 167 ++ .../version-0.46/user/run-node/run-testnet.md | 99 + .../version-0.46/user/run-node/txs.md | 383 +++ .../develop/advanced-concepts/00-baseapp.md | 512 ++++ .../advanced-concepts/01-transactions.md | 199 ++ .../develop/advanced-concepts/02-context.md | 102 + .../develop/advanced-concepts/03-node.md | 98 + .../develop/advanced-concepts/04-store.md | 290 +++ .../develop/advanced-concepts/05-encoding.md | 320 +++ .../develop/advanced-concepts/06-grpc_rest.md | 100 + .../develop/advanced-concepts/07-cli.md | 171 ++ .../develop/advanced-concepts/08-events.md | 162 ++ .../develop/advanced-concepts/09-telemetry.md | 128 + .../develop/advanced-concepts/10-ocap.md | 0 .../advanced-concepts/11-runtx_middleware.md | 67 + .../advanced-concepts/12-simulation.md | 101 + .../advanced-concepts/13-proto-docs.md | 7 + .../develop/advanced-concepts/14-tips.md | 214 ++ .../develop/advanced-concepts/15-upgrade.md | 162 ++ .../develop/advanced-concepts/_category_.json | 5 + .../baseapp_state-begin_block.png | Bin 0 -> 20565 bytes .../baseapp_state-checktx.png | Bin 0 -> 82308 bytes .../baseapp_state-commit.png | Bin 0 -> 47662 bytes .../baseapp_state-deliver_tx.png | Bin 0 -> 59007 bytes .../baseapp_state-initchain.png | Bin 0 -> 243455 bytes .../baseapp_state-prepareproposal.png | Bin 0 -> 274049 bytes .../baseapp_state-processproposal.png | Bin .../advanced-concepts/baseapp_state.png | Bin 0 -> 338941 bytes .../high-level-concepts/00-app-anatomy.md | 263 +++ .../high-level-concepts/01-tx-lifecycle.md | 67 +- .../high-level-concepts/02-query-lifecycle.md | 149 ++ .../high-level-concepts/03-accounts.md | 281 +++ .../high-level-concepts/04-gas-fees.md | 99 + .../high-level-concepts/_category_.json | 5 + .../develop/intro/00-what-is-sdk.md | 31 + .../develop/intro/01-why-app-specific.md | 80 + .../develop/intro/02-sdk-app-architecture.md | 94 + .../develop/intro/03-sdk-design.md | 96 + .../develop/intro/_category_.json | 5 + .../integrate/architecture/PROCESS.md | 56 + .../integrate/architecture/README.md | 89 + .../integrate/architecture/_category_.json | 5 + .../architecture/adr-002-docs-structure.md | 86 + .../adr-003-dynamic-capability-store.md | 344 +++ .../adr-004-split-denomination-keys.md | 120 + .../adr-006-secret-store-replacement.md | 54 + .../adr-007-specialization-groups.md | 177 ++ .../architecture/adr-008-dCERT-group.md | 171 ++ .../architecture/adr-009-evidence-module.md | 182 ++ .../adr-010-modular-antehandler.md | 290 +++ .../adr-011-generalize-genesis-accounts.md | 170 ++ .../architecture/adr-012-state-accessors.md | 155 ++ .../integrate/architecture/adr-013-metrics.md | 157 ++ .../adr-014-proportional-slashing.md | 85 + ...dr-016-validator-consensus-key-rotation.md | 125 + .../adr-017-historical-header-module.md | 61 + .../adr-018-extendable-voting-period.md | 66 + .../adr-019-protobuf-state-encoding.md | 379 +++ .../adr-020-protobuf-transaction-encoding.md | 464 ++++ .../adr-021-protobuf-query-encoding.md | 256 ++ .../adr-022-custom-panic-handling.md | 218 ++ .../architecture/adr-023-protobuf-naming.md | 263 +++ .../architecture/adr-024-coin-metadata.md | 139 ++ ...27-deterministic-protobuf-serialization.md | 314 +++ .../adr-028-public-key-addresses.md | 342 +++ .../architecture/adr-029-fee-grant-module.md | 153 ++ .../architecture/adr-030-authz-module.md | 258 ++ .../architecture/adr-031-msg-service.md | 202 ++ .../architecture/adr-032-typed-events.md | 319 +++ .../adr-033-protobuf-inter-module-comm.md | 400 ++++ .../architecture/adr-034-account-rekeying.md | 76 + .../adr-035-rosetta-api-support.md | 211 ++ .../adr-036-arbitrary-signature.md | 132 ++ .../architecture/adr-037-gov-split-vote.md | 111 + .../architecture/adr-038-state-listening.md | 569 +++++ .../architecture/adr-039-epoched-staking.md | 122 + ...r-040-storage-and-smt-state-commitments.md | 289 +++ .../adr-041-in-place-store-migrations.md | 167 ++ .../architecture/adr-042-group-module.md | 279 +++ .../architecture/adr-043-nft-module.md | 349 +++ .../adr-044-protobuf-updates-guidelines.md | 129 + .../adr-045-check-delivertx-middlewares.md | 312 +++ .../architecture/adr-046-module-params.md | 184 ++ .../adr-047-extend-upgrade-plan.md | 245 ++ .../architecture/adr-048-consensus-fees.md | 204 ++ .../architecture/adr-049-state-sync-hooks.md | 174 ++ .../adr-050-sign-mode-textual-annex1.md | 322 +++ .../adr-050-sign-mode-textual-annex2.md | 122 + .../architecture/adr-050-sign-mode-textual.md | 592 +++++ .../adr-053-go-module-refactoring.md | 109 + .../integrate/architecture/adr-055-orm.md | 111 + .../architecture/adr-057-app-wiring.md | 331 +++ .../adr-058-auto-generated-cli.md | 95 + .../architecture/adr-059-test-scopes.md | 253 ++ .../architecture/adr-060-abci-1.0.md | 249 ++ .../architecture/adr-061-liquid-staking.md | 82 + .../integrate/architecture/adr-template.md | 60 + .../integrate/building-apps/00-app-go.md | 14 + .../integrate/building-apps/01-app-go-v2.md | 130 + .../integrate/building-apps/02-app-mempool.md | 168 ++ .../integrate/building-apps/03-app-upgrade.md | 69 + .../integrate/building-apps/_category_.json | 5 + .../integrate/building-modules/01-intro.md | 94 + .../building-modules/01-module-manager.md | 255 ++ .../02-messages-and-queries.md | 129 + .../building-modules/03-msg-services.md | 114 + .../building-modules/04-query-services.md | 59 + .../05-beginblock-endblock.md | 45 + .../integrate/building-modules/06-keeper.md | 93 + .../building-modules/07-invariants.md | 92 + .../integrate/building-modules/08-genesis.md | 72 + .../building-modules/09-module-interfaces.md | 161 ++ .../integrate/building-modules/10-autocli.md | 157 ++ .../building-modules/11-structure.md | 95 + .../integrate/building-modules/12-errors.md | 56 + .../integrate/building-modules/13-upgrade.md | 65 + .../building-modules/14-simulator.md | 134 ++ .../building-modules/15-depinject.md | 126 + .../integrate/building-modules/16-testing.md | 142 ++ .../building-modules/_category_.json | 5 + .../integrate/migrations/01-intro.md | 15 + .../integrate/migrations/_category_.json | 5 + .../integrate/modules/_category_.json | 5 + .../version-0.47/integrate/spec/README.md | 25 + .../version-0.47/integrate/spec/SPEC-SPEC.md | 60 + .../integrate/spec/_category_.json | 5 + .../integrate/spec/_ics/README.md | 3 + .../spec/_ics/ics-030-signed-messages.md | 192 ++ .../integrate/spec/addresses/README.md | 3 + .../integrate/spec/addresses/bech32.md | 21 + .../integrate/spec/circuit-breaker/README.md | 16 + .../spec/fee_distribution/f1_fee_distr.pdf | Bin 0 -> 185175 bytes .../spec/fee_distribution/f1_fee_distr.tex | 245 ++ .../integrate/spec/reserve-pool/README.md | 4 + .../integrate/spec/store/README.md | 235 ++ .../integrate/tooling/00-protobuf.md | 113 + .../version-0.47/integrate/tooling/README.md | 11 + .../integrate/tooling/_category_.json | 5 + .../version-0.47/user/run-node/00-keyring.md | 134 ++ .../version-0.47/user/run-node/01-run-node.md | 192 ++ .../user/run-node/02-interact-node.md | 291 +++ .../version-0.47/user/run-node/03-txs.md | 387 +++ .../run-node}/05-run-testnet.md | 2 +- .../user/run-node/06-run-production.md | 266 +++ .../user/run-node/_category_.json | 5 + 457 files changed, 62385 insertions(+), 427 deletions(-) delete mode 100644 custom-version-plugin.js create mode 100644 docs/integrate/building-modules/transaction_flow.svg delete mode 100644 version_config.json create mode 100644 versioned_docs/version-0.45/develop/advanced-concepts/README.md create mode 100644 versioned_docs/version-0.45/develop/advanced-concepts/baseapp.md create mode 100644 versioned_docs/version-0.45/develop/advanced-concepts/baseapp_state-begin_block.png create mode 100644 versioned_docs/version-0.45/develop/advanced-concepts/baseapp_state-checktx.png create mode 100644 versioned_docs/version-0.45/develop/advanced-concepts/baseapp_state-commit.png create mode 100644 versioned_docs/version-0.45/develop/advanced-concepts/baseapp_state-deliver_tx.png create mode 100644 versioned_docs/version-0.45/develop/advanced-concepts/baseapp_state-initchain.png create mode 100644 versioned_docs/version-0.45/develop/advanced-concepts/baseapp_state_types.png create mode 100644 versioned_docs/version-0.45/develop/advanced-concepts/cli.md create mode 100644 versioned_docs/version-0.45/develop/advanced-concepts/context.md create mode 100644 versioned_docs/version-0.45/develop/advanced-concepts/encoding.md create mode 100644 versioned_docs/version-0.45/develop/advanced-concepts/events.md create mode 100644 versioned_docs/version-0.45/develop/advanced-concepts/grpc_rest.md create mode 100644 versioned_docs/version-0.45/develop/advanced-concepts/keeper_dependencies.svg create mode 100644 versioned_docs/version-0.45/develop/advanced-concepts/node.md create mode 100644 versioned_docs/version-0.45/develop/advanced-concepts/ocap.md create mode 100644 versioned_docs/version-0.45/develop/advanced-concepts/runtx_middleware.md create mode 100644 versioned_docs/version-0.45/develop/advanced-concepts/simulation.md create mode 100644 versioned_docs/version-0.45/develop/advanced-concepts/store.md create mode 100644 versioned_docs/version-0.45/develop/advanced-concepts/telemetry.md create mode 100644 versioned_docs/version-0.45/develop/advanced-concepts/transaction_flow.svg create mode 100644 versioned_docs/version-0.45/develop/advanced-concepts/transactions.md create mode 100644 versioned_docs/version-0.45/develop/advanced-concepts/upgrade.md create mode 100644 versioned_docs/version-0.45/develop/high-level-concepts/README.md create mode 100644 versioned_docs/version-0.45/develop/high-level-concepts/accounts.md create mode 100644 versioned_docs/version-0.45/develop/high-level-concepts/app-anatomy.md create mode 100644 versioned_docs/version-0.45/develop/high-level-concepts/gas-fees.md create mode 100644 versioned_docs/version-0.45/develop/high-level-concepts/query-lifecycle.md create mode 100644 versioned_docs/version-0.45/develop/high-level-concepts/tx-lifecycle.md create mode 100644 versioned_docs/version-0.45/develop/intro/README.md create mode 100644 versioned_docs/version-0.45/develop/intro/overview.md create mode 100644 versioned_docs/version-0.45/develop/intro/sdk-app-architecture.md create mode 100644 versioned_docs/version-0.45/develop/intro/sdk-design.md create mode 100644 versioned_docs/version-0.45/develop/intro/why-app-specific.md create mode 100644 versioned_docs/version-0.45/integrate/architecture/PROCESS.md create mode 100644 versioned_docs/version-0.45/integrate/architecture/README.md create mode 100644 versioned_docs/version-0.45/integrate/architecture/adr-002-docs-structure.md create mode 100644 versioned_docs/version-0.45/integrate/architecture/adr-003-dynamic-capability-store.md create mode 100644 versioned_docs/version-0.45/integrate/architecture/adr-004-split-denomination-keys.md create mode 100644 versioned_docs/version-0.45/integrate/architecture/adr-006-secret-store-replacement.md create mode 100644 versioned_docs/version-0.45/integrate/architecture/adr-007-specialization-groups.md create mode 100644 versioned_docs/version-0.45/integrate/architecture/adr-008-dCERT-group.md create mode 100644 versioned_docs/version-0.45/integrate/architecture/adr-009-evidence-module.md create mode 100644 versioned_docs/version-0.45/integrate/architecture/adr-010-modular-antehandler.md create mode 100644 versioned_docs/version-0.45/integrate/architecture/adr-011-generalize-genesis-accounts.md create mode 100644 versioned_docs/version-0.45/integrate/architecture/adr-012-state-accessors.md create mode 100644 versioned_docs/version-0.45/integrate/architecture/adr-013-metrics.md create mode 100644 versioned_docs/version-0.45/integrate/architecture/adr-014-proportional-slashing.md create mode 100644 versioned_docs/version-0.45/integrate/architecture/adr-016-validator-consensus-key-rotation.md create mode 100644 versioned_docs/version-0.45/integrate/architecture/adr-017-historical-header-module.md create mode 100644 versioned_docs/version-0.45/integrate/architecture/adr-018-extendable-voting-period.md create mode 100644 versioned_docs/version-0.45/integrate/architecture/adr-019-protobuf-state-encoding.md create mode 100644 versioned_docs/version-0.45/integrate/architecture/adr-020-protobuf-transaction-encoding.md create mode 100644 versioned_docs/version-0.45/integrate/architecture/adr-021-protobuf-query-encoding.md create mode 100644 versioned_docs/version-0.45/integrate/architecture/adr-022-custom-panic-handling.md create mode 100644 versioned_docs/version-0.45/integrate/architecture/adr-023-protobuf-naming.md create mode 100644 versioned_docs/version-0.45/integrate/architecture/adr-024-coin-metadata.md create mode 100644 versioned_docs/version-0.45/integrate/architecture/adr-027-deterministic-protobuf-serialization.md create mode 100644 versioned_docs/version-0.45/integrate/architecture/adr-028-public-key-addresses.md create mode 100644 versioned_docs/version-0.45/integrate/architecture/adr-029-fee-grant-module.md create mode 100644 versioned_docs/version-0.45/integrate/architecture/adr-030-authz-module.md create mode 100644 versioned_docs/version-0.45/integrate/architecture/adr-031-msg-service.md create mode 100644 versioned_docs/version-0.45/integrate/architecture/adr-032-typed-events.md create mode 100644 versioned_docs/version-0.45/integrate/architecture/adr-033-protobuf-inter-module-comm.md create mode 100644 versioned_docs/version-0.45/integrate/architecture/adr-034-account-rekeying.md create mode 100644 versioned_docs/version-0.45/integrate/architecture/adr-035-rosetta-api-support.md create mode 100644 versioned_docs/version-0.45/integrate/architecture/adr-036-arbitrary-signature.md create mode 100644 versioned_docs/version-0.45/integrate/architecture/adr-037-gov-split-vote.md create mode 100644 versioned_docs/version-0.45/integrate/architecture/adr-038-state-listening.md create mode 100644 versioned_docs/version-0.45/integrate/architecture/adr-039-epoched-staking.md create mode 100644 versioned_docs/version-0.45/integrate/architecture/adr-040-storage-and-smt-state-commitments.md create mode 100644 versioned_docs/version-0.45/integrate/architecture/adr-041-in-place-store-migrations.md create mode 100644 versioned_docs/version-0.45/integrate/architecture/adr-042-group-module.md create mode 100644 versioned_docs/version-0.45/integrate/architecture/adr-template.md create mode 100644 versioned_docs/version-0.45/integrate/building-modules/README.md create mode 100644 versioned_docs/version-0.45/integrate/building-modules/beginblock-endblock.md create mode 100644 versioned_docs/version-0.45/integrate/building-modules/errors.md create mode 100644 versioned_docs/version-0.45/integrate/building-modules/genesis.md create mode 100644 versioned_docs/version-0.45/integrate/building-modules/intro.md create mode 100644 versioned_docs/version-0.45/integrate/building-modules/invariants.md create mode 100644 versioned_docs/version-0.45/integrate/building-modules/keeper.md create mode 100644 versioned_docs/version-0.45/integrate/building-modules/messages-and-queries.md create mode 100644 versioned_docs/version-0.45/integrate/building-modules/module-interfaces.md create mode 100644 versioned_docs/version-0.45/integrate/building-modules/module-manager.md create mode 100644 versioned_docs/version-0.45/integrate/building-modules/msg-services.md create mode 100644 versioned_docs/version-0.45/integrate/building-modules/query-services.md create mode 100644 versioned_docs/version-0.45/integrate/building-modules/simulator.md create mode 100644 versioned_docs/version-0.45/integrate/building-modules/structure.md create mode 100644 versioned_docs/version-0.45/integrate/building-modules/transaction_flow.svg create mode 100644 versioned_docs/version-0.45/integrate/building-modules/upgrade.md create mode 100644 versioned_docs/version-0.45/user/run-node/interact-node.md create mode 100644 versioned_docs/version-0.45/user/run-node/keyring.md create mode 100644 versioned_docs/version-0.45/user/run-node/rosetta.md create mode 100644 versioned_docs/version-0.45/user/run-node/run-node.md create mode 100644 versioned_docs/version-0.45/user/run-node/run-testnet.md create mode 100644 versioned_docs/version-0.45/user/run-node/txs.md create mode 100644 versioned_docs/version-0.46/develop/advanced-concepts/03-context.md create mode 100644 versioned_docs/version-0.46/develop/advanced-concepts/04-node.md rename versioned_docs/version-0.46/develop/advanced-concepts/{04-store.md => 05-store.md} (94%) create mode 100644 versioned_docs/version-0.46/develop/advanced-concepts/07-encoding.md create mode 100644 versioned_docs/version-0.46/develop/advanced-concepts/08-grpc_rest.md create mode 100644 versioned_docs/version-0.46/develop/advanced-concepts/09-cli.md create mode 100644 versioned_docs/version-0.46/develop/advanced-concepts/10-events.md create mode 100644 versioned_docs/version-0.46/develop/advanced-concepts/11-telemetry.md create mode 100644 versioned_docs/version-0.46/develop/advanced-concepts/12-ocap.md create mode 100644 versioned_docs/version-0.46/develop/advanced-concepts/13-runtx_middleware.md create mode 100644 versioned_docs/version-0.46/develop/advanced-concepts/13-simulation.md create mode 100644 versioned_docs/version-0.46/develop/advanced-concepts/14-proto-docs.md create mode 100644 versioned_docs/version-0.46/develop/advanced-concepts/15-tips.md create mode 100644 versioned_docs/version-0.46/develop/advanced-concepts/16-upgrade.md create mode 100644 versioned_docs/version-0.46/develop/advanced-concepts/_category_.json create mode 100644 versioned_docs/version-0.46/develop/advanced-concepts/keeper_dependencies.svg create mode 100644 versioned_docs/version-0.46/develop/high-level-concepts/README.md rename versioned_docs/version-0.46/develop/high-level-concepts/{03-accounts.md => accounts.md} (83%) create mode 100644 versioned_docs/version-0.46/develop/high-level-concepts/app-anatomy.md create mode 100644 versioned_docs/version-0.46/develop/high-level-concepts/gas-fees.md create mode 100644 versioned_docs/version-0.46/develop/high-level-concepts/query-lifecycle.md create mode 100644 versioned_docs/version-0.46/develop/high-level-concepts/tx-lifecycle.md create mode 100644 versioned_docs/version-0.46/develop/intro/README.md create mode 100644 versioned_docs/version-0.46/develop/intro/overview.md create mode 100644 versioned_docs/version-0.46/develop/intro/sdk-app-architecture.md create mode 100644 versioned_docs/version-0.46/develop/intro/sdk-design.md create mode 100644 versioned_docs/version-0.46/develop/intro/why-app-specific.md create mode 100644 versioned_docs/version-0.46/integrate/CosmWasm/README.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/PROCESS.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/README.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-002-docs-structure.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-003-dynamic-capability-store.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-004-split-denomination-keys.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-006-secret-store-replacement.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-007-specialization-groups.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-008-dCERT-group.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-009-evidence-module.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-010-modular-antehandler.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-011-generalize-genesis-accounts.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-012-state-accessors.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-013-metrics.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-014-proportional-slashing.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-016-validator-consensus-key-rotation.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-017-historical-header-module.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-018-extendable-voting-period.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-019-protobuf-state-encoding.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-020-protobuf-transaction-encoding.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-021-protobuf-query-encoding.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-022-custom-panic-handling.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-023-protobuf-naming.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-024-coin-metadata.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-027-deterministic-protobuf-serialization.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-028-public-key-addresses.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-029-fee-grant-module.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-030-authz-module.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-031-msg-service.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-032-typed-events.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-033-protobuf-inter-module-comm.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-034-account-rekeying.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-035-rosetta-api-support.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-036-arbitrary-signature.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-037-gov-split-vote.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-038-state-listening.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-039-epoched-staking.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-040-storage-and-smt-state-commitments.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-041-in-place-store-migrations.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-042-group-module.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-043-nft-module.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-044-protobuf-updates-guidelines.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-045-check-delivertx-middlewares.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-046-module-params.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-047-extend-upgrade-plan.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-048-consensus-fees.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-049-state-sync-hooks.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-053-go-module-refactoring.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-055-orm.md create mode 100644 versioned_docs/version-0.46/integrate/architecture/adr-template.md create mode 100644 versioned_docs/version-0.46/integrate/building-modules/README.md create mode 100644 versioned_docs/version-0.46/integrate/building-modules/beginblock-endblock.md create mode 100644 versioned_docs/version-0.46/integrate/building-modules/errors.md create mode 100644 versioned_docs/version-0.46/integrate/building-modules/genesis.md create mode 100644 versioned_docs/version-0.46/integrate/building-modules/intro.md create mode 100644 versioned_docs/version-0.46/integrate/building-modules/invariants.md create mode 100644 versioned_docs/version-0.46/integrate/building-modules/keeper.md create mode 100644 versioned_docs/version-0.46/integrate/building-modules/messages-and-queries.md create mode 100644 versioned_docs/version-0.46/integrate/building-modules/module-interfaces.md create mode 100644 versioned_docs/version-0.46/integrate/building-modules/module-manager.md create mode 100644 versioned_docs/version-0.46/integrate/building-modules/msg-services.md create mode 100644 versioned_docs/version-0.46/integrate/building-modules/query-services.md create mode 100644 versioned_docs/version-0.46/integrate/building-modules/simulator.md rename versioned_docs/version-0.46/integrate/building-modules/{11-structure.md => structure.md} (83%) create mode 100644 versioned_docs/version-0.46/integrate/building-modules/transaction_flow.svg create mode 100644 versioned_docs/version-0.46/integrate/building-modules/upgrade.md create mode 100644 versioned_docs/version-0.46/integrate/ibc/README.md create mode 100644 versioned_docs/version-0.46/integrate/migrations/README.md create mode 100644 versioned_docs/version-0.46/integrate/migrations/pre-upgrade.md create mode 100644 versioned_docs/version-0.46/integrate/modules/auth/01_concepts.md create mode 100644 versioned_docs/version-0.46/integrate/modules/auth/02_state.md create mode 100644 versioned_docs/version-0.46/integrate/modules/auth/03_antehandlers.md create mode 100644 versioned_docs/version-0.46/integrate/modules/auth/04_keepers.md create mode 100644 versioned_docs/version-0.46/integrate/modules/auth/05_vesting.md create mode 100644 versioned_docs/version-0.46/integrate/modules/auth/06_params.md create mode 100644 versioned_docs/version-0.46/integrate/modules/auth/07_client.md create mode 100644 versioned_docs/version-0.46/integrate/modules/auth/README.md create mode 100644 versioned_docs/version-0.46/integrate/modules/authz/01_concepts.md create mode 100644 versioned_docs/version-0.46/integrate/modules/authz/02_state.md create mode 100644 versioned_docs/version-0.46/integrate/modules/authz/03_messages.md create mode 100644 versioned_docs/version-0.46/integrate/modules/authz/04_events.md create mode 100644 versioned_docs/version-0.46/integrate/modules/authz/05_client.md create mode 100644 versioned_docs/version-0.46/integrate/modules/authz/README.md create mode 100644 versioned_docs/version-0.46/integrate/modules/bank/01_state.md create mode 100644 versioned_docs/version-0.46/integrate/modules/bank/02_keepers.md create mode 100644 versioned_docs/version-0.46/integrate/modules/bank/03_messages.md create mode 100644 versioned_docs/version-0.46/integrate/modules/bank/04_events.md create mode 100644 versioned_docs/version-0.46/integrate/modules/bank/05_params.md create mode 100644 versioned_docs/version-0.46/integrate/modules/bank/06_client.md create mode 100644 versioned_docs/version-0.46/integrate/modules/bank/README.md create mode 100644 versioned_docs/version-0.46/integrate/modules/capability/01_concepts.md create mode 100644 versioned_docs/version-0.46/integrate/modules/capability/02_state.md create mode 100644 versioned_docs/version-0.46/integrate/modules/capability/README.md create mode 100644 versioned_docs/version-0.46/integrate/modules/crisis/01_state.md create mode 100644 versioned_docs/version-0.46/integrate/modules/crisis/02_messages.md create mode 100644 versioned_docs/version-0.46/integrate/modules/crisis/03_events.md create mode 100644 versioned_docs/version-0.46/integrate/modules/crisis/04_params.md create mode 100644 versioned_docs/version-0.46/integrate/modules/crisis/05_client.md create mode 100644 versioned_docs/version-0.46/integrate/modules/crisis/README.md create mode 100644 versioned_docs/version-0.46/integrate/modules/distribution/01_concepts.md create mode 100644 versioned_docs/version-0.46/integrate/modules/distribution/02_state.md create mode 100644 versioned_docs/version-0.46/integrate/modules/distribution/03_begin_block.md create mode 100644 versioned_docs/version-0.46/integrate/modules/distribution/04_messages.md create mode 100644 versioned_docs/version-0.46/integrate/modules/distribution/05_hooks.md create mode 100644 versioned_docs/version-0.46/integrate/modules/distribution/06_events.md create mode 100644 versioned_docs/version-0.46/integrate/modules/distribution/07_params.md create mode 100644 versioned_docs/version-0.46/integrate/modules/distribution/08_client.md create mode 100644 versioned_docs/version-0.46/integrate/modules/distribution/README.md create mode 100644 versioned_docs/version-0.46/integrate/modules/evidence/01_concepts.md create mode 100644 versioned_docs/version-0.46/integrate/modules/evidence/02_state.md create mode 100644 versioned_docs/version-0.46/integrate/modules/evidence/03_messages.md create mode 100644 versioned_docs/version-0.46/integrate/modules/evidence/04_events.md create mode 100644 versioned_docs/version-0.46/integrate/modules/evidence/05_params.md create mode 100644 versioned_docs/version-0.46/integrate/modules/evidence/06_begin_block.md create mode 100644 versioned_docs/version-0.46/integrate/modules/evidence/07_client.md create mode 100644 versioned_docs/version-0.46/integrate/modules/evidence/README.md create mode 100644 versioned_docs/version-0.46/integrate/modules/feegrant/01_concepts.md create mode 100644 versioned_docs/version-0.46/integrate/modules/feegrant/02_state.md create mode 100644 versioned_docs/version-0.46/integrate/modules/feegrant/03_messages.md create mode 100644 versioned_docs/version-0.46/integrate/modules/feegrant/04_events.md create mode 100644 versioned_docs/version-0.46/integrate/modules/feegrant/05_client.md create mode 100644 versioned_docs/version-0.46/integrate/modules/feegrant/README.md create mode 100644 versioned_docs/version-0.46/integrate/modules/gov/01_concepts.md create mode 100644 versioned_docs/version-0.46/integrate/modules/gov/02_state.md create mode 100644 versioned_docs/version-0.46/integrate/modules/gov/03_messages.md create mode 100644 versioned_docs/version-0.46/integrate/modules/gov/04_events.md create mode 100644 versioned_docs/version-0.46/integrate/modules/gov/05_future_improvements.md create mode 100644 versioned_docs/version-0.46/integrate/modules/gov/06_params.md create mode 100644 versioned_docs/version-0.46/integrate/modules/gov/07_client.md create mode 100644 versioned_docs/version-0.46/integrate/modules/gov/08_metadata.md create mode 100644 versioned_docs/version-0.46/integrate/modules/gov/README.md create mode 100644 versioned_docs/version-0.46/integrate/modules/mint/01_concepts.md create mode 100644 versioned_docs/version-0.46/integrate/modules/mint/02_state.md create mode 100644 versioned_docs/version-0.46/integrate/modules/mint/03_begin_block.md create mode 100644 versioned_docs/version-0.46/integrate/modules/mint/04_params.md create mode 100644 versioned_docs/version-0.46/integrate/modules/mint/05_events.md create mode 100644 versioned_docs/version-0.46/integrate/modules/mint/06_client.md create mode 100644 versioned_docs/version-0.46/integrate/modules/mint/README.md create mode 100644 versioned_docs/version-0.46/integrate/modules/params/01_keeper.md create mode 100644 versioned_docs/version-0.46/integrate/modules/params/02_subspace.md create mode 100644 versioned_docs/version-0.46/integrate/modules/params/README.md create mode 100644 versioned_docs/version-0.46/integrate/modules/slashing/01_concepts.md create mode 100644 versioned_docs/version-0.46/integrate/modules/slashing/02_state.md create mode 100644 versioned_docs/version-0.46/integrate/modules/slashing/03_messages.md create mode 100644 versioned_docs/version-0.46/integrate/modules/slashing/04_begin_block.md create mode 100644 versioned_docs/version-0.46/integrate/modules/slashing/05_hooks.md create mode 100644 versioned_docs/version-0.46/integrate/modules/slashing/06_events.md create mode 100644 versioned_docs/version-0.46/integrate/modules/slashing/07_tombstone.md create mode 100644 versioned_docs/version-0.46/integrate/modules/slashing/08_params.md create mode 100644 versioned_docs/version-0.46/integrate/modules/slashing/09_client.md create mode 100644 versioned_docs/version-0.46/integrate/modules/slashing/README.md create mode 100644 versioned_docs/version-0.46/integrate/modules/staking/01_state.md create mode 100644 versioned_docs/version-0.46/integrate/modules/staking/02_state_transitions.md create mode 100644 versioned_docs/version-0.46/integrate/modules/staking/03_messages.md create mode 100644 versioned_docs/version-0.46/integrate/modules/staking/04_begin_block.md create mode 100644 versioned_docs/version-0.46/integrate/modules/staking/05_end_block.md create mode 100644 versioned_docs/version-0.46/integrate/modules/staking/06_hooks.md create mode 100644 versioned_docs/version-0.46/integrate/modules/staking/07_events.md create mode 100644 versioned_docs/version-0.46/integrate/modules/staking/08_params.md create mode 100644 versioned_docs/version-0.46/integrate/modules/staking/09_client.md create mode 100644 versioned_docs/version-0.46/integrate/modules/staking/README.md create mode 100644 versioned_docs/version-0.46/integrate/modules/staking/begin_redelegation_sequence.svg create mode 100644 versioned_docs/version-0.46/integrate/modules/staking/delegation_sequence.svg create mode 100644 versioned_docs/version-0.46/integrate/modules/staking/unbond_sequence.svg create mode 100644 versioned_docs/version-0.46/integrate/modules/upgrade/01_concepts.md create mode 100644 versioned_docs/version-0.46/integrate/modules/upgrade/02_state.md create mode 100644 versioned_docs/version-0.46/integrate/modules/upgrade/03_events.md create mode 100644 versioned_docs/version-0.46/integrate/modules/upgrade/04_client.md create mode 100644 versioned_docs/version-0.46/integrate/modules/upgrade/README.md delete mode 100644 versioned_docs/version-0.46/integrate/rfc/README.md create mode 100644 versioned_docs/version-0.46/user/run-node/README.md create mode 100644 versioned_docs/version-0.46/user/run-node/interact-node.md create mode 100644 versioned_docs/version-0.46/user/run-node/keyring.md create mode 100644 versioned_docs/version-0.46/user/run-node/rosetta.md create mode 100644 versioned_docs/version-0.46/user/run-node/run-node.md create mode 100644 versioned_docs/version-0.46/user/run-node/run-testnet.md create mode 100644 versioned_docs/version-0.46/user/run-node/txs.md create mode 100644 versioned_docs/version-0.47/develop/advanced-concepts/00-baseapp.md create mode 100644 versioned_docs/version-0.47/develop/advanced-concepts/01-transactions.md create mode 100644 versioned_docs/version-0.47/develop/advanced-concepts/02-context.md create mode 100644 versioned_docs/version-0.47/develop/advanced-concepts/03-node.md create mode 100644 versioned_docs/version-0.47/develop/advanced-concepts/04-store.md create mode 100644 versioned_docs/version-0.47/develop/advanced-concepts/05-encoding.md create mode 100644 versioned_docs/version-0.47/develop/advanced-concepts/06-grpc_rest.md create mode 100644 versioned_docs/version-0.47/develop/advanced-concepts/07-cli.md create mode 100644 versioned_docs/version-0.47/develop/advanced-concepts/08-events.md create mode 100644 versioned_docs/version-0.47/develop/advanced-concepts/09-telemetry.md rename versioned_docs/{version-0.46 => version-0.47}/develop/advanced-concepts/10-ocap.md (100%) create mode 100644 versioned_docs/version-0.47/develop/advanced-concepts/11-runtx_middleware.md create mode 100644 versioned_docs/version-0.47/develop/advanced-concepts/12-simulation.md create mode 100644 versioned_docs/version-0.47/develop/advanced-concepts/13-proto-docs.md create mode 100644 versioned_docs/version-0.47/develop/advanced-concepts/14-tips.md create mode 100644 versioned_docs/version-0.47/develop/advanced-concepts/15-upgrade.md create mode 100644 versioned_docs/version-0.47/develop/advanced-concepts/_category_.json create mode 100644 versioned_docs/version-0.47/develop/advanced-concepts/baseapp_state-begin_block.png create mode 100644 versioned_docs/version-0.47/develop/advanced-concepts/baseapp_state-checktx.png create mode 100644 versioned_docs/version-0.47/develop/advanced-concepts/baseapp_state-commit.png create mode 100644 versioned_docs/version-0.47/develop/advanced-concepts/baseapp_state-deliver_tx.png create mode 100644 versioned_docs/version-0.47/develop/advanced-concepts/baseapp_state-initchain.png create mode 100644 versioned_docs/version-0.47/develop/advanced-concepts/baseapp_state-prepareproposal.png rename versioned_docs/{version-0.46 => version-0.47}/develop/advanced-concepts/baseapp_state-processproposal.png (100%) create mode 100644 versioned_docs/version-0.47/develop/advanced-concepts/baseapp_state.png create mode 100644 versioned_docs/version-0.47/develop/high-level-concepts/00-app-anatomy.md rename versioned_docs/{version-0.46 => version-0.47}/develop/high-level-concepts/01-tx-lifecycle.md (71%) create mode 100644 versioned_docs/version-0.47/develop/high-level-concepts/02-query-lifecycle.md create mode 100644 versioned_docs/version-0.47/develop/high-level-concepts/03-accounts.md create mode 100644 versioned_docs/version-0.47/develop/high-level-concepts/04-gas-fees.md create mode 100644 versioned_docs/version-0.47/develop/high-level-concepts/_category_.json create mode 100644 versioned_docs/version-0.47/develop/intro/00-what-is-sdk.md create mode 100644 versioned_docs/version-0.47/develop/intro/01-why-app-specific.md create mode 100644 versioned_docs/version-0.47/develop/intro/02-sdk-app-architecture.md create mode 100644 versioned_docs/version-0.47/develop/intro/03-sdk-design.md create mode 100644 versioned_docs/version-0.47/develop/intro/_category_.json create mode 100644 versioned_docs/version-0.47/integrate/architecture/PROCESS.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/README.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/_category_.json create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-002-docs-structure.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-003-dynamic-capability-store.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-004-split-denomination-keys.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-006-secret-store-replacement.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-007-specialization-groups.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-008-dCERT-group.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-009-evidence-module.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-010-modular-antehandler.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-011-generalize-genesis-accounts.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-012-state-accessors.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-013-metrics.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-014-proportional-slashing.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-016-validator-consensus-key-rotation.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-017-historical-header-module.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-018-extendable-voting-period.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-019-protobuf-state-encoding.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-020-protobuf-transaction-encoding.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-021-protobuf-query-encoding.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-022-custom-panic-handling.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-023-protobuf-naming.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-024-coin-metadata.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-027-deterministic-protobuf-serialization.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-028-public-key-addresses.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-029-fee-grant-module.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-030-authz-module.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-031-msg-service.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-032-typed-events.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-033-protobuf-inter-module-comm.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-034-account-rekeying.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-035-rosetta-api-support.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-036-arbitrary-signature.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-037-gov-split-vote.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-038-state-listening.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-039-epoched-staking.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-040-storage-and-smt-state-commitments.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-041-in-place-store-migrations.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-042-group-module.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-043-nft-module.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-044-protobuf-updates-guidelines.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-045-check-delivertx-middlewares.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-046-module-params.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-047-extend-upgrade-plan.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-048-consensus-fees.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-049-state-sync-hooks.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-050-sign-mode-textual-annex1.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-050-sign-mode-textual-annex2.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-050-sign-mode-textual.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-053-go-module-refactoring.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-055-orm.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-057-app-wiring.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-058-auto-generated-cli.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-059-test-scopes.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-060-abci-1.0.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-061-liquid-staking.md create mode 100644 versioned_docs/version-0.47/integrate/architecture/adr-template.md create mode 100644 versioned_docs/version-0.47/integrate/building-apps/00-app-go.md create mode 100644 versioned_docs/version-0.47/integrate/building-apps/01-app-go-v2.md create mode 100644 versioned_docs/version-0.47/integrate/building-apps/02-app-mempool.md create mode 100644 versioned_docs/version-0.47/integrate/building-apps/03-app-upgrade.md create mode 100644 versioned_docs/version-0.47/integrate/building-apps/_category_.json create mode 100644 versioned_docs/version-0.47/integrate/building-modules/01-intro.md create mode 100644 versioned_docs/version-0.47/integrate/building-modules/01-module-manager.md create mode 100644 versioned_docs/version-0.47/integrate/building-modules/02-messages-and-queries.md create mode 100644 versioned_docs/version-0.47/integrate/building-modules/03-msg-services.md create mode 100644 versioned_docs/version-0.47/integrate/building-modules/04-query-services.md create mode 100644 versioned_docs/version-0.47/integrate/building-modules/05-beginblock-endblock.md create mode 100644 versioned_docs/version-0.47/integrate/building-modules/06-keeper.md create mode 100644 versioned_docs/version-0.47/integrate/building-modules/07-invariants.md create mode 100644 versioned_docs/version-0.47/integrate/building-modules/08-genesis.md create mode 100644 versioned_docs/version-0.47/integrate/building-modules/09-module-interfaces.md create mode 100644 versioned_docs/version-0.47/integrate/building-modules/10-autocli.md create mode 100644 versioned_docs/version-0.47/integrate/building-modules/11-structure.md create mode 100644 versioned_docs/version-0.47/integrate/building-modules/12-errors.md create mode 100644 versioned_docs/version-0.47/integrate/building-modules/13-upgrade.md create mode 100644 versioned_docs/version-0.47/integrate/building-modules/14-simulator.md create mode 100644 versioned_docs/version-0.47/integrate/building-modules/15-depinject.md create mode 100644 versioned_docs/version-0.47/integrate/building-modules/16-testing.md create mode 100644 versioned_docs/version-0.47/integrate/building-modules/_category_.json create mode 100644 versioned_docs/version-0.47/integrate/migrations/01-intro.md create mode 100644 versioned_docs/version-0.47/integrate/migrations/_category_.json create mode 100644 versioned_docs/version-0.47/integrate/modules/_category_.json create mode 100644 versioned_docs/version-0.47/integrate/spec/README.md create mode 100644 versioned_docs/version-0.47/integrate/spec/SPEC-SPEC.md create mode 100644 versioned_docs/version-0.47/integrate/spec/_category_.json create mode 100644 versioned_docs/version-0.47/integrate/spec/_ics/README.md create mode 100644 versioned_docs/version-0.47/integrate/spec/_ics/ics-030-signed-messages.md create mode 100644 versioned_docs/version-0.47/integrate/spec/addresses/README.md create mode 100644 versioned_docs/version-0.47/integrate/spec/addresses/bech32.md create mode 100644 versioned_docs/version-0.47/integrate/spec/circuit-breaker/README.md create mode 100644 versioned_docs/version-0.47/integrate/spec/fee_distribution/f1_fee_distr.pdf create mode 100644 versioned_docs/version-0.47/integrate/spec/fee_distribution/f1_fee_distr.tex create mode 100644 versioned_docs/version-0.47/integrate/spec/reserve-pool/README.md create mode 100644 versioned_docs/version-0.47/integrate/spec/store/README.md create mode 100644 versioned_docs/version-0.47/integrate/tooling/00-protobuf.md create mode 100644 versioned_docs/version-0.47/integrate/tooling/README.md create mode 100644 versioned_docs/version-0.47/integrate/tooling/_category_.json create mode 100644 versioned_docs/version-0.47/user/run-node/00-keyring.md create mode 100644 versioned_docs/version-0.47/user/run-node/01-run-node.md create mode 100644 versioned_docs/version-0.47/user/run-node/02-interact-node.md create mode 100644 versioned_docs/version-0.47/user/run-node/03-txs.md rename versioned_docs/version-0.47/{validate => user/run-node}/05-run-testnet.md (92%) create mode 100644 versioned_docs/version-0.47/user/run-node/06-run-production.md create mode 100644 versioned_docs/version-0.47/user/run-node/_category_.json diff --git a/custom-version-plugin.js b/custom-version-plugin.js deleted file mode 100644 index 8c4cf997d..000000000 --- a/custom-version-plugin.js +++ /dev/null @@ -1,78 +0,0 @@ -const fs = require('fs'); -const path = require('path'); - -// Helper function to get all files recursively from a directory -function getAllFiles(dirPath, arrayOfFiles) { - arrayOfFiles = arrayOfFiles || []; - const files = fs.readdirSync(dirPath); - - files.forEach(function (file) { - const filePath = path.join(dirPath, file); - if (fs.statSync(filePath).isDirectory()) { - arrayOfFiles = getAllFiles(filePath, arrayOfFiles); - } else { - arrayOfFiles.push(filePath); - } - }); - - return arrayOfFiles; -} - -function shouldExcludeFile(version, filePath, versionConfig) { - const excludedPaths = versionConfig[version]?.excludedPaths || []; - return excludedPaths.some((excludedPath) => filePath.startsWith(excludedPath)); -} - -module.exports = function (_context, _options) { - return { - name: 'custom-version-plugin', - - async loadContent() { - // Read the versions.json file to get the list of versions - const versionsJsonPath = path.join(_context.siteDir, 'versions.json'); - const versions = JSON.parse(fs.readFileSync(versionsJsonPath, 'utf8')); - - // Read the version config file - const versionConfigPath = path.join(_context.siteDir, 'version_config.json'); - const versionConfig = JSON.parse(fs.readFileSync(versionConfigPath, 'utf8')); - - // Read all the files in the /docs folder - const docsPath = path.join(_context.siteDir, 'docs'); - const files = getAllFiles(docsPath); - - // Iterate through the list of versions - for (const version of versions) { - const versionedDocsPath = path.join(_context.siteDir, 'versioned_docs', `version-${version}`); - - // Check if the version directory exists - if (fs.existsSync(versionedDocsPath)) { - // Iterate through the list of files in the /docs folder - for (const file of files) { - const relativePath = path.relative(docsPath, file); - const customFilePath = path.join(versionedDocsPath, relativePath); - - // Check if the file exists in the version directory - if (!fs.existsSync(customFilePath) && !shouldExcludeFile(version, relativePath, versionConfig)) { - // If the file doesn't exist and it's not excluded, copy it from the /docs folder - const customFileDir = path.dirname(customFilePath); - fs.mkdirSync(customFileDir, { recursive: true }); - fs.copyFileSync(file, customFilePath); - console.log(`Copied file from /docs to version-${version}:`, relativePath); - } - } - - // After copying all files, iterate over the versioned directory to remove excluded files - const versionedFiles = getAllFiles(versionedDocsPath); - for (const file of versionedFiles) { - const relativePath = path.relative(versionedDocsPath, file); - - if (shouldExcludeFile(version, relativePath, versionConfig)) { - fs.unlinkSync(file); - console.log(`Removed excluded file from version-${version}:`, relativePath); - } - } - } - } - }, - }; -}; diff --git a/docs/integrate/_category_.json b/docs/integrate/_category_.json index 47b369a05..b860342f4 100644 --- a/docs/integrate/_category_.json +++ b/docs/integrate/_category_.json @@ -1,5 +1,5 @@ { "label": "Integrate", - "position": 1, + "position": 0, "link": null } \ No newline at end of file diff --git a/docs/integrate/building-modules/transaction_flow.svg b/docs/integrate/building-modules/transaction_flow.svg new file mode 100644 index 000000000..1ae962de3 --- /dev/null +++ b/docs/integrate/building-modules/transaction_flow.svg @@ -0,0 +1,48 @@ +UserUserbaseAppbaseApprouterrouterhandlerhandlermsgServermsgServerkeeperkeeperContext.EventManagerContext.EventManagerTransaction Type<Tx>Route(ctx, msgRoute)handlerMsg<Tx>(Context, Msg(...))<Tx>(Context, Msg)alt[addresses invalid, denominations wrong, etc.]errorperform action, update contextresults, error codeEmit relevant eventsmaybe wrap results in more structureresult, error coderesults, error code \ No newline at end of file diff --git a/docs/integrate/libraries/02-collections.md b/docs/integrate/libraries/02-collections.md index 7f8278233..fc74594ec 100644 --- a/docs/integrate/libraries/02-collections.md +++ b/docs/integrate/libraries/02-collections.md @@ -533,7 +533,7 @@ func (k Keeper) GetAllAccounts(ctx sdk.Context) ([]authtypes.BaseAccount, error) } func (k Keeper) IterateAccountsBetween(ctx sdk.Context, start, end uint64) ([]authtypes.BaseAccount, error) { - // The collections.Range API offers a lot of capabilities + // The collections.Range API offers a lot of capability // like defining where the iteration starts or ends. rng := new(collections.Range[uint64]). StartInclusive(start). diff --git a/docusaurus.config.js b/docusaurus.config.js index 0fa2e5272..d1dd203e2 100644 --- a/docusaurus.config.js +++ b/docusaurus.config.js @@ -3,7 +3,6 @@ const lightCodeTheme = require("prism-react-renderer/themes/github"); const darkCodeTheme = require("prism-react-renderer/themes/dracula"); -const customVersionPlugin = require('./custom-version-plugin'); // const lastVersion = "v0.47"; const lastVersion = "current"; @@ -41,7 +40,6 @@ const config = { docs: { sidebarPath: require.resolve("./sidebars.js"), routeBasePath: "/", - lastVersion: lastVersion, }, theme: { customCss: require.resolve("./src/css/custom.css"), @@ -79,11 +77,6 @@ const config = { position: "left", label: "Integrate", }, - // { - // to: "/", - // position: "left", - // label: "Validate", - // }, { to: "/user/run-node/keyring", position: "left", @@ -219,7 +212,6 @@ const config = { }, }; }, - customVersionPlugin, [ "@docusaurus/plugin-google-analytics", { diff --git a/version_config.json b/version_config.json deleted file mode 100644 index 5c9fa3b7c..000000000 --- a/version_config.json +++ /dev/null @@ -1,31 +0,0 @@ -{ - "0.45": { - "excludedPaths": ["integrate/modules/slashing", "integrate/modules/nft", "integrate/building-modules/15-depinject.md", "integrate/modules/genutil", - "integrate/modules/consensus", "integrate/modules/circuit", "integrate/building-apps","integrate/building-modules/autocli", "integrate/building-modules/depinject", - "integrate/building-modules/testing", "integrate/building-apps", "integrate/architecture/rfc", "integrate/specs", "integrate/architecture/adr-041-in-place-store-migrations", "integrate/architecture/adr-042-group-module", - "integrate/architecture/adr-043-nft-module", "integrate/architecture/adr-044-protobuf-updates-guidelines", "integrate/architecture/adr-045-check-delivertx-middlewares", - "integrate/architecture/adr-046-module-params", "integrate/architecture/adr-046-module-params", "integrate/architecture/adr-047-extend-upgrade-plan", - "integrate/architecture/adr-048-consensus-fees", "integrate/architecture/adr-049-state-sync-hooks", "integrate/architecture/adr-050-sign-mode-textual", - "integrate/architecture/adr-050-sign-mode-textual-annex1", "integrate/architecture/adr-050-sign-mode-textual-annex2", "integrate/architecture/adr-053-go-module-refactoring","integrate/architecture/adr-054-semver-compatible-modules", - "integrate/architecture/adr-055-orm", "integrate/architecture/adr-057-app-wiring", "integrate/architecture/adr-058-auto-generated-cli", "integrate/architecture/adr-059-test-scopes", - "integrate/architecture/adr-060-abci-1.0", "integrate/architecture/adr-061-liquid-staking", "integrate/architecture/adr-062-collections-state-layer", - "integrate/architecture/adr-062-collections-state-layer", "integrate/architecture/adr-063-core-module-api", "integrate/architecture/adr-064-abci-2.0", - "integrate/architecture/adr-065-store-v2", "integrate/architecture/README"] - }, - "0.46": { - "excludedPaths": ["integrate/modules/genutil", "integrate/building-modules/15-depinject.md","integrate/modules/consensus", "integrate/modules/circuit", "integrate/architecture/rfc", - "integrate/specs", "integrate/building-apps", "integrate/building-modules/depinject", "integrate/architecture/adr-007-specialization-groups", - "integrate/architecture/adr-008-dCERT-group", "integrate/architecture/adr-014-proportional-slashing", - "integrate/architecture/adr-034-account-keying", "integrate/architecture/adr-041-in-place-store-migrations", "integrate/architecture/adr-042-group-module", - "integrate/architecture/adr-043-nft-module", "integrate/architecture/adr-044-protobuf-updates-guidelines", "integrate/architecture/adr-045-check-delivertx-middlewares", - "integrate/architecture/adr-048-consensus-fees", "integrate/architecture/adr-049-state-sync-hooks", "integrate/architecture/adr-050-sign-mode-textual", - "integrate/architecture/adr-050-sign-mode-textual-annex1", "integrate/architecture/adr-050-sign-mode-textual-annex2", "integrate/architecture/adr-054-semver-compatible-modules", - "integrate/architecture/adr-055-orm", "integrate/architecture/adr-057-app-wiring", "integrate/architecture/adr-058-auto-generated-cli", "integrate/architecture/adr-059-test-scopes", - "integrate/architecture/adr-060-abci-1.0", "integrate/architecture/adr-061-liquid-staking", "integrate/architecture/adr-062-collections-state-layer", - "integrate/architecture/adr-062-collections-state-layer", "integrate/architecture/adr-063-core-module-api", "integrate/architecture/adr-064-abci-2.0", - "integrate/architecture/adr-065-store-v2", "integrate/architecture/README"] - }, - "0.47": { - "excludedPaths": [] - } -} diff --git a/versioned_docs/version-0.45/develop/advanced-concepts/README.md b/versioned_docs/version-0.45/develop/advanced-concepts/README.md new file mode 100644 index 000000000..a6853b418 --- /dev/null +++ b/versioned_docs/version-0.45/develop/advanced-concepts/README.md @@ -0,0 +1,28 @@ + + +# Core Concepts + +This repository contains reference documentation on the core concepts of the 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) + +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. diff --git a/versioned_docs/version-0.45/develop/advanced-concepts/baseapp.md b/versioned_docs/version-0.45/develop/advanced-concepts/baseapp.md new file mode 100644 index 000000000..c3da524e3 --- /dev/null +++ b/versioned_docs/version-0.45/develop/advanced-concepts/baseapp.md @@ -0,0 +1,399 @@ + + +# BaseApp + +This document describes `BaseApp`, the abstraction that implements the core functionalities of an SDK application. {synopsis} + +## Pre-requisite Readings + +- [Anatomy of an SDK application](../basics/app-anatomy.md) {prereq} +- [Lifecycle of an SDK transaction](../basics/tx-lifecycle.md) {prereq} + +## Introduction + +`BaseApp` is a base type that implements the core of an SDK application, namely: + +- The [Application Blockchain Interface](#abci), for the state-machine to communicate with the underlying consensus engine (e.g. Tendermint). +- [Service Routers](#service-routers), to route messages and queries to the appropriate module. +- Different [states](#states), as the state-machine can have different volatile states updated based on the ABCI message received. + +The goal of `BaseApp` is to provide the fundamental layer of an SDK application +that developers can easily extend to build their own custom application. Usually, +developers will create a custom type for their application, like so: + +```go +type App struct { + // reference to a BaseApp + *baseapp.BaseApp + + // list of application store keys + + // list of application keepers + + // module manager +} +``` + +Extending the application with `BaseApp` gives the former access to all of `BaseApp`'s methods. +This allows developers to compose their custom application with the modules they want, while not +having to concern themselves with the hard work of implementing the ABCI, the service routers and state +management logic. + +## Type Definition + +The `BaseApp` type holds many important parameters for any Cosmos SDK based application. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/baseapp/baseapp.go#L46-L131 + +Let us go through the most important components. + +> **Note**: Not all parameters are described, only the most important ones. Refer to the +> type definition for the full list. + +First, the important parameters that are initialized during the bootstrapping of the application: + +- [`CommitMultiStore`](./store.md#commitmultistore): This is the main store of the application, + which holds the canonical state that is committed at the [end of each block](#commit). This store + is **not** cached, meaning it is not used to update the application's volatile (un-committed) states. + The `CommitMultiStore` is a multi-store, meaning a store of stores. Each module of the application + uses one or multiple `KVStores` in the multi-store to persist their subset of the state. +- Database: The `db` is used by the `CommitMultiStore` to handle data persistence. +- [`Msg` Service Router](#msg-service-router): The `msgServiceRouter` facilitates the routing of `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). +- [`InitChainer`](../basics/app-anatomy.md#initchainer), + [`BeginBlocker` and `EndBlocker`](../basics/app-anatomy.md#beginblocker-and-endblocker): These are + the functions executed when the application receives the `InitChain`, `BeginBlock` and `EndBlock` + ABCI messages from the underlying Tendermint engine. + +Then, parameters used to define [volatile states](#volatile-states) (i.e. cached states): + +- `checkState`: This state is updated during [`CheckTx`](#checktx), and reset on [`Commit`](#commit). +- `deliverState`: This state is updated during [`DeliverTx`](#delivertx), and set to `nil` on + [`Commit`](#commit) and gets re-initialized on BeginBlock. + +Finally, a few more important parameterd: + +- `voteInfos`: This parameter carries the list of validators whose precommit is missing, either + because they did not vote or because the proposer did not include their vote. This information is + carried by the [Context](#context) and can be used by the application for various things like + punishing absent validators. +- `minGasPrices`: This parameter defines the minimum gas prices accepted by the node. This is a + **local** parameter, meaning each full-node can set a different `minGasPrices`. It is used in the + `AnteHandler` during [`CheckTx`](#checktx), mainly as a spam protection mechanism. The transaction + enters the [mempool](https://tendermint.com/docs/tendermint-core/mempool.html#transaction-ordering) + only if the gas prices of the transaction are greater than one of the minimum gas price in + `minGasPrices` (e.g. if `minGasPrices == 1uatom,1photon`, the `gas-price` of the transaction must be + greater than `1uatom` OR `1photon`). +- `appVersion`: Version of the application. It is set in the + [application's constructor function](../basics/app-anatomy.md#constructor-function). + +## Constructor + +```go +func NewBaseApp( + name string, logger log.Logger, db dbm.DB, txDecoder sdk.TxDecoder, options ...func(*BaseApp), +) *BaseApp { + + // ... +} +``` + +The `BaseApp` constructor function is pretty straightforward. The only thing worth noting is the +possibility to provide additional [`options`](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/baseapp/options.go) +to the `BaseApp`, which will execute them in order. The `options` are generally `setter` functions +for important parameters, like `SetPruning()` to set pruning options or `SetMinGasPrices()` to set +the node's `min-gas-prices`. + +Naturally, developers can add additional `options` based on their application's needs. + +## State Updates + +The `BaseApp` maintains two primary volatile states and a root or main state. The main state +is the canonical state of the application and the volatile states, `checkState` and `deliverState`, +are used to handle state transitions in-between the main state made during [`Commit`](#commit). + +Internally, there is only a single `CommitMultiStore` which we refer to as the main or root state. +From this root state, we derive two volatile states by using a mechanism called _store branching_ (performed by `CacheWrap` function). +The types can be illustrated as follows: + +![Types](./baseapp_state_types.png) + +### InitChain State Updates + +During `InitChain`, the two volatile states, `checkState` and `deliverState` are set by branching +the root `CommitMultiStore`. Any subsequent reads and writes happen on branched versions of the `CommitMultiStore`. +To avoid unnecessary roundtrip to the main state, all reads to the branched store are cached. + +![InitChain](./baseapp_state-initchain.png) + +### CheckTx State Updates + +During `CheckTx`, the `checkState`, which is based off of the last committed state from the root +store, is used for any reads and writes. Here we only execute the `AnteHandler` and verify a service router +exists for every message in the transaction. Note, when we execute the `AnteHandler`, we branch +the already branched `checkState`. This has the side effect that if the `AnteHandler` fails, +the state transitions won't be reflected in the `checkState` -- i.e. `checkState` is only updated on +success. + +![CheckTx](./baseapp_state-checktx.png) + +### BeginBlock State Updates + +During `BeginBlock`, the `deliverState` is set for use in subsequent `DeliverTx` ABCI messages. The +`deliverState` is based off of the last committed state from the root store and is branched. +Note, the `deliverState` is set to `nil` on [`Commit`](#commit). + +![BeginBlock](./baseapp_state-begin_block.png) + +### DeliverTx State Updates + +The state flow for `DeliverTx` is nearly identical to `CheckTx` except state transitions occur on +the `deliverState` and messages in a transaction are executed. Similarly to `CheckTx`, state transitions +occur on a doubly branched state -- `deliverState`. Successful message execution results in +writes being committed to `deliverState`. Note, if message execution fails, state transitions from +the AnteHandler are persisted. + +![DeliverTx](./baseapp_state-deliver_tx.png) + +### Commit State Updates + +During `Commit` all the state transitions that occurred in the `deliverState` are finally written to +the root `CommitMultiStore` which in turn is committed to disk and results in a new application +root hash. These state transitions are now considered final. Finally, the `checkState` is set to the +newly committed state and `deliverState` is set to `nil` to be reset on `BeginBlock`. + +![Commit](./baseapp_state-commit.png) + +## ParamStore + +During `InitChain`, the `RequestInitChain` provides `ConsensusParams` which contains parameters +related to block execution such as maximum gas and size in addition to evidence parameters. If these +parameters are non-nil, they are set in the BaseApp's `ParamStore`. Behind the scenes, the `ParamStore` +is actually managed by an `x/params` module `Subspace`. This allows the parameters to be tweaked via +on-chain governance. + +## Service Routers + +When messages and queries are received by the application, they must be routed to the appropriate module in order to be processed. Routing is done via `BaseApp`, which holds a `msgServiceRouter` for messages, and a `grpcQueryRouter` for queries. + +### `Msg` Service Router + +[`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. + +The [default `msgServiceRouter` included in `BaseApp`](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/baseapp/msg_service_router.go) is stateless. However, some applications may want to make use of more stateful routing mechanisms such as allowing governance to disable certain routes or point them to new modules for upgrade purposes. For this reason, the `sdk.Context` is also passed into each [route handler inside `msgServiceRouter`](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/baseapp/msg_service_router.go#L31-L32). For a stateless router that doesn't want to make use of this, you can just ignore the `ctx`. + +The application's `msgServiceRouter` is initialized with all the routes using the application's [module manager](../building-modules/module-manager.md#manager) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](../basics/app-anatomy.md#app-constructor). + +### gRPC Query Router + +Similar to `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. + +Just like the `msgServiceRouter`, the `grpcQueryRouter` is initialized with all the query routes using the application's [module manager](../building-modules/module-manager.md) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](../basics/app-anatomy.md#app-constructor). + +## Main ABCI Messages + +The [Application-Blockchain Interface](https://tendermint.com/docs/spec/abci/) (ABCI) is a generic interface that connects a state-machine with a consensus engine to form a functional full-node. It can be wrapped in any language, and needs to be implemented by each application-specific blockchain built on top of an ABCI-compatible consensus engine like Tendermint. + +The consensus engine handles two main tasks: + +- The networking logic, which mainly consists in gossiping block parts, transactions and consensus votes. +- The consensus logic, which results in the deterministic ordering of transactions in the form of blocks. + +It is **not** the role of the consensus engine to define the state or the validity of transactions. Generally, transactions are handled by the consensus engine in the form of `[]bytes`, and relayed to the application via the ABCI to be decoded and processed. At keys moments in the networking and consensus processes (e.g. beginning of a block, commit of a block, reception of an unconfirmed transaction, ...), the consensus engine emits ABCI messages for the state-machine to act on. + +Developers building on top of the Cosmos SDK need not implement the ABCI themselves, as `BaseApp` comes with a built-in implementation of the interface. Let us go through the main ABCI messages that `BaseApp` implements: [`CheckTx`](#checktx) and [`DeliverTx`](#delivertx) + +### CheckTx + +`CheckTx` is sent by the underlying consensus engine when a new unconfirmed (i.e. not yet included in a valid block) +transaction is received by a full-node. The role of `CheckTx` is to guard the full-node's mempool +(where unconfirmed transactions are stored until they are included in a block) from spam transactions. +Unconfirmed transactions are relayed to peers only if they pass `CheckTx`. + +`CheckTx()` can perform both _stateful_ and _stateless_ checks, but developers should strive to +make the checks **lightweight** because gas fees are not charged for the resources (CPU, data load...) used during the `CheckTx`. + +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. + +`CheckTx` does **not** process `sdk.Msg`s - they only need to be processed when the canonical state need to be updated, which happens during `DeliverTx`. + +Steps 2. and 3. are performed by the [`AnteHandler`](../basics/gas-fees.md#antehandler) in the [`RunTx()`](#runtx-antehandler-and-runmsgs) +function, which `CheckTx()` calls with the `runTxModeCheck` mode. During each step of `CheckTx()`, a +special [volatile state](#volatile-states) called `checkState` is updated. This state is used to keep +track of the temporary changes triggered by the `CheckTx()` calls of each transaction without modifying +the [main canonical state](#main-state) . For example, when a transaction goes through `CheckTx()`, the +transaction's fees are deducted from the sender's account in `checkState`. If a second transaction is +received from the same account before the first is processed, and the account has consumed all its +funds in `checkState` during the first transaction, the second transaction will fail `CheckTx`() and +be rejected. In any case, the sender's account will not actually pay the fees until the transaction +is actually included in a block, because `checkState` never gets committed to the main state. The +`checkState` is reset to the latest state of the main state each time a blocks gets [committed](#commit). + +`CheckTx` returns a response to the underlying consensus engine of type [`abci.ResponseCheckTx`](https://tendermint.com/docs/spec/abci/abci.html#messages). +The response contains: + +- `Code (uint32)`: Response Code. `0` if successful. +- `Data ([]byte)`: Result bytes, if any. +- `Log (string):` The output of the application's logger. May be non-deterministic. +- `Info (string):` Additional information. May be non-deterministic. +- `GasWanted (int64)`: Amount of gas requested for transaction. It is provided by users when they generate the transaction. +- `GasUsed (int64)`: Amount of gas consumed by transaction. During `CheckTx`, this value is computed by multiplying the standard cost of a transaction byte by the size of the raw transaction. Next is an example: + +++ https://github.com/cosmos/cosmos-sdk/blob/7d7821b9af132b0f6131640195326aa02b6751db/x/auth/ante/basic.go#L104-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. + +#### RecheckTx + +After `Commit`, `CheckTx` is run again on all transactions that remain in the node's local mempool +excluding the transactions that are included in the block. To prevent the mempool from rechecking all transactions +every time a block is committed, the configuration option `mempool.recheck=false` can be set. As of +Tendermint v0.32.1, an additional `Type` parameter is made available to the `CheckTx` function that +indicates whether an incoming transaction is new (`CheckTxType_New`), or a recheck (`CheckTxType_Recheck`). +This allows certain checks like signature verification can be skipped during `CheckTxType_Recheck`. + +### DeliverTx + +When the underlying consensus engine receives a block proposal, each transaction in the block needs to be processed by the application. To that end, the underlying consensus engine sends a `DeliverTx` message to the application for each transaction in a sequential order. + +Before the first transaction of a given block is processed, a [volatile state](#volatile-states) called `deliverState` is intialized during [`BeginBlock`](#beginblock). This state is updated each time a transaction is processed via `DeliverTx`, and committed to the [main state](#main-state) when the block is [committed](#commit), after what is is set to `nil`. + +`DeliverTx` performs the **exact same steps as `CheckTx`**, with a little caveat at step 3 and the addition of a fifth step: + +1. The `AnteHandler` does **not** check that the transaction's `gas-prices` is sufficient. That is because the `min-gas-prices` value `gas-prices` is checked against is local to the node, and therefore what is enough for one full-node might not be for another. This means that the proposer can potentially include transactions for free, although they are not incentivised to do so, as they earn a bonus on the total fee of the block they propose. +2. For each `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`. + +During the additional fifth step outlined in (2), each read/write to the store increases the value of `GasConsumed`. You can find the default cost of each operation: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/store/types/gas.go#L164-L175 + +At any point, if `GasConsumed > GasWanted`, the function returns with `Code != 0` and `DeliverTx` fails. + +`DeliverTx` returns a response to the underlying consensus engine of type [`abci.ResponseDeliverTx`](https://tendermint.com/docs/spec/abci/abci.html#delivertx). The response contains: + +- `Code (uint32)`: Response Code. `0` if successful. +- `Data ([]byte)`: Result bytes, if any. +- `Log (string):` The output of the application's logger. May be non-deterministic. +- `Info (string):` Additional information. May be non-deterministic. +- `GasWanted (int64)`: Amount of gas requested for transaction. It is provided by users when they generate the transaction. +- `GasUsed (int64)`: Amount of gas consumed by transaction. During `DeliverTx`, this value is computed by multiplying the standard cost of a transaction byte by the size of the raw transaction, and by adding gas each time a read/write to the store occurs. +- `Events ([]cmn.KVPair)`: Key-Value tags for filtering and indexing transactions (eg. by account). See [`event`s](./events.md) for more. +- `Codespace (string)`: Namespace for the Code. + +## RunTx, AnteHandler and RunMsgs + +### RunTx + +`RunTx` is called from `CheckTx`/`DeliverTx` to handle the transaction, with `runTxModeCheck` or `runTxModeDeliver` as parameter to differentiate between the two modes of execution. Note that when `RunTx` receives a transaction, it has already been decoded. + +The first thing `RunTx` does upon being called is to retrieve the `context`'s `CacheMultiStore` by calling the `getContextForTx()` function with the appropriate mode (either `runTxModeCheck` or `runTxModeDeliver`). This `CacheMultiStore` is a branch of the main store, with cache functionality (for query requests), instantiated during `BeginBlock` for `DeliverTx` and during the `Commit` of the previous block for `CheckTx`. After that, two `defer func()` are called for [`gas`](../basics/gas-fees.md) management. They are executed when `runTx` returns and make sure `gas` is actually consumed, and will throw errors, if any. + +After that, `RunTx()` calls `ValidateBasic()` on each `sdk.Msg`in the `Tx`, which runs preliminary _stateless_ validity checks. If any `sdk.Msg` fails to pass `ValidateBasic()`, `RunTx()` returns with an error. + +Then, the [`anteHandler`](#antehandler) of the application is run (if it exists). In preparation of this step, both the `checkState`/`deliverState`'s `context` and `context`'s `CacheMultiStore` are branched using the `cacheTxContext()` function. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/baseapp/baseapp.go#L623-L630 + +This allows `RunTx` not to commit the changes made to the state during the execution of `anteHandler` if it ends up failing. It also prevents the module implementing the `anteHandler` from writing to state, which is an important part of the [object-capabilities](./ocap.md) of the Cosmos SDK. + +Finally, the [`RunMsgs()`](#runmsgs) function is called to process the `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. + +### AnteHandler + +The `AnteHandler` is a special handler that implements the `AnteHandler` interface and is used to authenticate the transaction before the transaction's internal messages are processed. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/types/handler.go#L6-L8 + +The `AnteHandler` is theoretically optional, but still a very important component of public blockchain networks. It serves 3 primary purposes: + +- Be a primary line of defense against spam and second line of defense (the first one being the mempool) against transaction replay with fees deduction and [`sequence`](./transactions.md#transaction-generation) checking. +- Perform preliminary _stateful_ validity checks like ensuring signatures are valid or that the sender has enough funds to pay for fees. +- Play a role in the incentivisation of stakeholders via the collection of transaction fees. + +`BaseApp` holds an `anteHandler` as 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). + +Click [here](../basics/gas-fees.md#antehandler) for more on the `anteHandler`. + +### RunMsgs + +`RunMsgs` is called from `RunTx` with `runTxModeCheck` as parameter to check the existence of a route for each message the transaction, and with `runTxModeDeliver` to actually process the `sdk.Msg`s. + +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. + +## Other ABCI Messages + +### InitChain + +The [`InitChain` ABCI message](https://tendermint.com/docs/app-dev/abci-spec.html#initchain) is sent from the underlying Tendermint engine when the chain is first started. It is mainly used to **initialize** parameters and state like: + +- [Consensus Parameters](https://tendermint.com/docs/spec/abci/apps.html#consensus-parameters) via `setConsensusParams`. +- [`checkState` and `deliverState`](#volatile-states) via `setCheckState` and `setDeliverState`. +- The [block gas meter](../basics/gas-fees.md#block-gas-meter), with infinite gas to process genesis transactions. + +Finally, the `InitChain(req abci.RequestInitChain)` method of `BaseApp` calls the [`initChainer()`](../basics/app-anatomy.md#initchainer) of the application in order to initialize the main state of the application from the `genesis file` and, if defined, call the [`InitGenesis`](../building-modules/genesis.md#initgenesis) function of each of the application's modules. + +### BeginBlock + +The [`BeginBlock` ABCI message](#https://tendermint.com/docs/app-dev/abci-spec.html#beginblock) is sent from the underlying Tendermint engine when a block proposal created by the correct proposer is received, before [`DeliverTx`](#delivertx) is run for each transaction in the block. It allows developers to have logic be executed at the beginning of each block. In the Cosmos SDK, the `BeginBlock(req abci.RequestBeginBlock)` method does the following: + +- Initialize [`deliverState`](#volatile-states) with the latest header using the `req abci.RequestBeginBlock` passed as parameter via the `setDeliverState` function. + +++ https://github.com/cosmos/cosmos-sdk/blob/7d7821b9af132b0f6131640195326aa02b6751db/baseapp/baseapp.go#L387-L397 + This function also resets the [main gas meter](../basics/gas-fees.md#main-gas-meter). +- Initialize the [block gas meter](../basics/gas-fees.md#block-gas-meter) with the `maxGas` limit. The `gas` consumed within the block cannot go above `maxGas`. This parameter is defined in the application's consensus parameters. +- Run the application's [`beginBlocker()`](../basics/app-anatomy.md#beginblocker-and-endblock), which mainly runs the [`BeginBlocker()`](../building-modules/beginblock-endblock.md#beginblock) method of each of the application's modules. +- Set the [`VoteInfos`](https://tendermint.com/docs/app-dev/abci-spec.html#voteinfo) of the application, i.e. the list of validators whose _precommit_ for the previous block was included by the proposer of the current block. This information is carried into the [`Context`](./context.md) so that it can be used during `DeliverTx` and `EndBlock`. + +### EndBlock + +The [`EndBlock` ABCI message](#https://tendermint.com/docs/app-dev/abci-spec.html#endblock) is sent from the underlying Tendermint engine after [`DeliverTx`](#delivertx) as been run for each transaction in the block. It allows developers to have logic be executed at the end of each block. In the Cosmos SDK, the bulk `EndBlock(req abci.RequestEndBlock)` method is to run the application's [`EndBlocker()`](../basics/app-anatomy.md#beginblocker-and-endblock), which mainly runs the [`EndBlocker()`](../building-modules/beginblock-endblock.md#beginblock) method of each of the application's modules. + +### Commit + +The [`Commit` ABCI message](https://tendermint.com/docs/app-dev/abci-spec.html#commit) is sent from the underlying Tendermint engine after the full-node has received _precommits_ from 2/3+ of validators (weighted by voting power). On the `BaseApp` end, the `Commit(res abci.ResponseCommit)` function is implemented to commit all the valid state transitions that occured during `BeginBlock`, `DeliverTx` and `EndBlock` and to reset state for the next block. + +To commit state-transitions, the `Commit` function calls the `Write()` function on `deliverState.ms`, where `deliverState.ms` is a branched multistore of the main store `app.cms`. Then, the `Commit` function sets `checkState` to the latest header (obtbained from `deliverState.ctx.BlockHeader`) and `deliverState` to `nil`. + +Finally, `Commit` returns the hash of the commitment of `app.cms` back to the underlying consensus engine. This hash is used as a reference in the header of the next block. + +### Info + +The [`Info` ABCI message](https://tendermint.com/docs/app-dev/abci-spec.html#info) is a simple query from the underlying consensus engine, notably used to sync the latter with the application during a handshake that happens on startup. When called, the `Info(res abci.ResponseInfo)` function from `BaseApp` will return the application's name, version and the hash of the last commit of `app.cms`. + +### Query + +The [`Query` ABCI message](https://tendermint.com/docs/app-dev/abci-spec.html#query) is used to serve queries received from the underlying consensus engine, including queries received via RPC like Tendermint RPC. It used to be the main entrypoint to build interfaces with the application, but with the introduction of [gRPC queries](../building-modules/query-services.md) in Cosmos SDK v0.40, its usage is more limited. The application must respect a few rules when implementing the `Query` method, which are outlined [here](https://tendermint.com/docs/app-dev/abci-spec.html#query). + +Each Tendermint `query` comes with a `path`, which is a `string` which denotes what to query. If the `path` matches a gRPC fully-qualified service method, then `BaseApp` will defer the query to the `grpcQueryRouter` and let it handle it like explained [above](#grpc-query-router). Otherwise, the `path` represents a query that is not (yet) handled by the gRPC router. `BaseApp` splits the `path` string with the `/` delimiter. By convention, the first element of the splitted string (`splitted[0]`) contains the category of `query` (`app`, `p2p`, `store` or `custom` ). The `BaseApp` implementation of the `Query(req abci.RequestQuery)` method is a simple dispatcher serving these 4 main categories of queries: + +- Application-related queries like querying the application's version, which are served via the `handleQueryApp` method. +- Direct queries to the multistore, which are served by the `handlerQueryStore` method. These direct 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). + +## Next {hide} + +Learn more about [transactions](./transactions.md) {hide} diff --git a/versioned_docs/version-0.45/develop/advanced-concepts/baseapp_state-begin_block.png b/versioned_docs/version-0.45/develop/advanced-concepts/baseapp_state-begin_block.png new file mode 100644 index 0000000000000000000000000000000000000000..745d4a5a971292bb0346c35893b42ebfbcdc206e GIT binary patch literal 20565 zcmd@6WmHw)_s5SOT1t>oKnbP0kwyXOls^@mAbnmtInrrSg=X%fAB3eUDo)C`;4+H`cDk{iofk5bB;P(%Y zuz|Kwc!>%Gq5~<)zR~tI+0VxLLe@?3iQ7OH`t2Lbw>%a+5;={2I?Zq>qb)4UzcMqTUgc(sw|^lU@i-m}r2F)d?D!dQ|5HQrK_9|8 z>_gzDV-qon_vBIbSY!wbf6Q+?*LdJo{Ibf;rcZ_+E`Xc-DzbBm@w#f!@xZ(i=%b!@ zpzty=NpF!JT}xKT)oXYEMs?t-D~8-0I9}I}e^;@EoEnQKnxTeY9Qv}qLGLuc1CRR5 z|4Bht02~cOMc@>}Ml1(B?i-6fM8e2?@FMB`;QzO;OWyEFkIRI3q3c2_QHz98?fDh1 zB#qntVH<M47WREX5ZenxMVdFUDUgRj&DsTh$mM_lddu3jm2Z!9%eH&|<=JDG|I;}qYaCW>J zNo{?U=LY35?_jChyd05IYzxk|?m4yAloVEadc3kS0|Ez}?{R(@7*xg5;6 zGiIBJqtz5b(GXtL>$W$YyPr&mZ=+O7zn*V=C2Z9dL-ew2dH%E7;j~W9K!&Q)tN))c>V zFpv{pYJFHJIA;FKQ^aT2=gp0LZlIE+QI*1Q&aG+*mKR@0jinQ+c&xT;!ft#rkR|)- zZu<9$xN|cOPI=mOPQL0zRK7xr;pdQxI{R3um>`_C#0wpJGVwl31)@hY=t>TgT+IAM z+{qKg;{!vP!q(FVMAkjOaI4quh!~vaaK6Kzcs;*9=I>9ENM%r5%W()R#wC^S+fc;+ zC0K6U!gjKyp1j^0@?~cnHV`>4GyrAv_|^7Zly$UXI6HF?+D-j^pWd5Uo33-JKsj}z zFX`1-z9OmpY;^%97FIVI#F*@fq|5A{kKN_FF2FZ}Z<#44;DvF^NIhqxHk;7sr@bc) zrb%F7=Yg*+V%F{>=QhbgXBY51=Qw63e!|OJK>*;)hBg-L{yGQb9@0=G~83pG( zlWz{%Oj|`Ri%-knYhI6-a&kZA;J~2L6Xu?__1O4){}nL z5mq}d2`Ju~H7dMW-HN9^K0hHET;mRg-MlY!FD)wS)%>~D?Xhv`BVV9+XukEGPITaN zVgX;FCI60~WigtYnbqJ}Lp5YgA-!=wFF%;Y_)BJ$#~I(x5~FhG_X#6+`!f&ua(~64 zw_#uSu0CKu&sXJ#8uaJqU;#scEAe=<^aj=2oA7qV?M)dimCT*S9jaFR=%ift)rp(eBB$fS?shskDT84gbnHK znp74|3wym)!d2s>)g6xD229JT@49||^_C+FQtta$7}y9Zfk5z7#p0{}|`5 zFDxl~LQXTxJL6JZZTHtTaa0l-2&ZKRK}Uf^8`XKmj1ZNIOyEl}e|4>pBYwrGesBwY z?M70paqpBa=2FrOZmKeB4OHCXPU9MpdiZv_H)&FtF_hM-o#S_HFk9`F%@GjN`YR0~ z;7NSGzsxA}>6|aG_v|ug?n}4(!2+d6b{TkjFqXTOwaBS8p4!>Y=2} z!9x3vOYjyWq^~3y!g;xsGr1@ZM#f5$ha%;+wzPJ66E2N!*3sI)L-QPvyq#81xkiizguFHSXS#0__Gj*($6O|vhXrtAl zs&~?{JHO&|wRz*RQHIT#@7-%MhJd`;5p`=7Pv#8xBQcn|QH|Saz0lKQWAU&%o?va1 z3UmLvU{Jg$sXs7f&sOie^eBQ8{-|lX0@{&MLK&+ad;fjtDXTTA`l`oWqt=};^=zTl z@BLQ%9pP|h z8n5k6DK8$Av|Gq7p9>Si6-G;5u8w~7OaJ*yl>wU&0kqmH16g+XyH{+pJ~ucq)>eIx zNdB?n(U%B553@?EK|N^`_V=UPsezz&*m6z+_xWC8zr=ih0LptXJPCuLliwf?L8dp- zhuSRZyL2wY)acJ(&ppklGvdk>WB2%UCNzRiyj*+usQ-3tkgwcPBW)eZp!iamIgV$F z9By~kbSAu_LOEI(rtPpGdirXmNhY`dhj;uhi7w={-Mp%6NLjjsVoor9Q}c9jLltI9 z`J{%fDy{87r>;zoa=(L@5n^6)-usBNZvr)EiU$j3Kg}^a4zBRP_iHi$TPlh+`=qKo za(0^g>)$Xi_M_L#GU)rBVg1{82q&xiMfkFUUyTjMY>j!!^E=N9zaCf|HCshW8N-_o zy-G1(idCBs6-FGEO|=4T^^`(C#i=O}KZ?d@436JjHQlrZ-^~W^=YNe)~G#?5A7Ymsf%!l^+j}<<}ReQ~f_rFJe{Nh(%H5fd)9R1U2 zqao`mU;C`F&^h$5{WB+tfE|2fz?)CHub~7kEHR9 zinelv0=Dja-Jwrf@R>|Lr#bzr^@LbaSwGjA!eC=gTm*#(+_Tk<_%P0&QYg_VumD4DrTQw2sXB9 zSLmwmHqSGV_4FiUzdGC1gJv}xD}M0jj0%PM#+@XKZ%ng+c5*v6L`M7T_0>x-OFcD1cs?LsQHB%jAw}7nL7)W7f zGLJ3HqIhy+?>B^I{C&(b%WH8u-rFtc@3$`Nqv_4TtpXvtQPGodCj-7*?H|iVfXz){ zpJ|<2&#!;^n@TPr4Pk1}oH?{qNTx(nx>qe8?q(9k>gF=}>`_HqjB^c2ZaYGLVd5F| z-w7Ob^pv#AUXfE{MdZX@<#@*t%yI>x^k5z2B~(w->z<*hb?G2Wagb;rFu^lUtffHZ zw>D~tDesp_+gas*zU^_hY5Nj#w}V4D{xni;hn4>p+d`iBb-kR3~5wd*A=# zTs7aK69yH$U^oBlF-_E(WgpOL;XqPmRo@c;alpzm3DlVIT(9|m(icr=JQNqXqyNQ3gv8* zpq(1PQ+ei_aTWXne`b*%N@xC-aOE4h=LfHH@R@>gz5>CK+Si}UmImmqIE=y! z2cP%>8_9eIaap(wWLc%?r4kDsm%KU|!%7`NjJJfWg)A$&4!LhFd2VY-UGys2YpnR~ z2zVEc+U)Q3yWgMEj{R++tPVk8Q;vN@5EvoVc)HAuDVu#;j9v%yEChIop1~F(l%7?h zgQ~iYM{9idG)~am?*W(oVZiC3HYYzuEnPw}Vc-onv4Ou2>;uUo1+T!Uuj@krX0n-| z`22^|PQ-#LA6i^a3^Bmjy~8jskD_OK7H3n&o0%gQ)b%!-g-!$;1a{g(AIX|^5!K>J zjHTk&vhPkHCZax5p>T=A%X-uF^U<~mB1tQb>+a=p&PhWr7;BJde-D<=&x5mLosClU zbL5`hR;oMI;PVUZPqsON)8>$XR`44p$P#z|d-0W>TFO;7%{nG*0tlMSh{VlXJB|Hm zQ(72vP9Mw3c6ky;?!I8TB!_A=DKkt;Ef=cgvX$)R=-rRR?abHiKi2x@Yw+sV^%=YM z);Gzz|n0`+8Bo za(B{+%gNA3kmr+isYj9ISfLY!L5oAtg3of$mLvTS9b;DG#+SJk)j_>B7@ra!gqNT5 zo>8zGX;BII%g0c#GU7 z;r^{16sGz>m`jqZfej{)NOHH)K4?N2RBc+1qms<3SJ*$Ns(%RQ?yG$fsS6F)hX@DQ-s&y7u?Go(Vu4jeKR=w^k)%wb!`#^^n)%caNtXg{Y>V z$H}b6y`RC2R(Ff2@W4nf1-$8}lS;tc<6Nt}tCa&MC@Ox<-E5vIb>z{}QlknQWt~H2 z^x04U%*}$Vtz|o@ANHyq4;VP-NPJs$YK@F4R8&>9;e~pNjnh!ec#FTi<%@2I2(Ps5 z@gC>9%gI!1q$#WBJ5gOWHhxJ_2q;?dy!~_8)_wJbVbhaj)i`LWZ6<1NEl_RoCk1cD za?n*n70Gg=n+zh7BW1r7))$K9Xr&U#gf49uO9+$PrN8Z72zcl+vv~1M3Ir}1=#I-I z^O3afzchD08<867C9f28{b_jewdW=xg7Zy*2{6rieLxT=gorGY|8hC~d369nVE;0; zggdsAma7P$6FU*iZqo*_WKs!18bAYNVz*Ey*#nhSxL@S+?CavG z+>Fb935!9Yfp5+ag?I#mcA>wy)q`>FVO+CT7WJ1cTHU+VUMNvYe*brNx09h^i*eL{ ze}5feFl`M#_D(T0&#*(SCWKn57}Wi;k}&(k0iKld4<~uq3O>Ai1iok_TIB?vV*9*= zl{o@m16TCUT@#hw3oJdkN!@H;F1UdlvqbIB)hkvNz!yi!T~0DS6M0dYwCAFrb=@xzYt-iM-e;ScF7Bo zWfq$SsJDATJZWP+%(i+HFiW}QLW=iVRjj>ux{*Xs1I`a?_JI)`Vp5~hECOSMB3IUZ zr~Xqn+!u2-ohl^@>*YC5q(j{h`1Dx^0#rXG9zz&g4qJb(b7f08nz0A|e9`7Q0kVwP z6LrhEqWrxbOxX4)oOi>rH=N+$)e5LI>BQufWWP?+xcI5-pUvnt$b&9@YL&qa0-oB- zC&8H@m13Z)5}@w;*{NTzIj-t6qT=Ws%X85i+006kIXc%I&Vz0fewgC4k5YtzMyH=X z$^n57TcNVH9*E5C&-&W3xj7v>@QO0$3-024-_a&G-*VFeUG`HXCtOzM!|tcxAF~0$ z({r0&LpMKiTJ*cVB4G=g-c2CwjaQ!jC<<9%*Y5?@jMY)4B|OJ(s~x|({Y5!9DE^_D z*@%;@`mUq;ljE4ZM6K()kSrQB^;`+PUfzT%9-LTzS(s9Qb9)B`A*M}^|1PEC#qZAQ z!0xx{qSi^cIc;7jSm4RN9`vpti)5lPrxtIQL&S90@w(Q$lg)s#dP53U_M?3&o?1BH ze`sv1{^F5{->xtQIGzf#KT7j%H&HDoKmI8<`1(z& zsDB@l?1SNSib##FQW4kC=H_$1f}p05yQx+JPwf$%nPUZBTa}n>*|*ES_ffNJKN-yU z4URXMq=OuC)!vHZ@jlL^7)iQ6d8-1M+y~ch^nN#0nlh^B+gT1y`nzaI?ejgN?1&eP z#Pwa}Gk6l1Dd;1~3hV=z$Nb_kCoxx1Q>5wzo#Xpm`7OZNZLVT#;&VV4NQk5{2r_k$yw z4OxCb_H~WT6>7(<@cOVWa!l&rc-Fg|xHd8Ltkz|in`xg3}q~LPHp{KmBb-HSB4hkW(ehgoTW9+fDCUm$1yLcOrD`njK07Z zrP#F>YvqA?ajYeXCutr7!8n3lCl$tc{4qF9#GF*shVa0CNnXeXe~_ZGTmI=t)npX! zdiJ>gpN~9Y8zHyXHMOia8CQ8%kX{N8lk~axe8)+xF*@J8s+aGB?++YzrjN2U24NAL z)HhotrpP$l5YWpqYxY~Qj_&AmGiKq{$Mp@A?z{o2mwKQgXts+6XPNk04 zJJHN`PY!T=hIaBSzh0lmNDCcmsv>dJ61)GC7wzDJ-+Mr(e8K0u2N4N4sBOMei~gNf zmQgqOsqqOAj}9b_zI>NgP5y{WGVr3|6}ui6Oov`sMSN--M~b)fN!6DWwrusDR^h>k zkd<~5`-R#@h*6s!kkAZCFW>r=ZdRRA=6lU!L&c`qwaSgildsLU;x0DlUD}{jbprz( zSg4I|h{!GPlxB&H`QWPteJ8JFsnRD8cktV7Z9pO@&5erqBjuCApq8P%75~Rp*W$07 zQ|o!Ev%p_4lF)`|hjCo$T1)NWI@TaZ5^|->Z*JyQJeD8doVcyi5PVnie5SR#nFWV? z*33jJ4TZb3c}Yf;&sW-7Zq#T;SE8DZ{!j(s4I{2xC~{_8pR0A|QQt*FxDFjbH{?_k z`Bu6Hzu>ZkL|5A!qh}qbayYh=TxiZkj%T*jkiea0r}NE^=t#xZ#UH2Umj)B3M#N%V zsC~sdlzjxoC1r9iWv|>Uc|lH9%VT;wYZ}yvsjzO?O%-;wf3kH3e9ZSwM$3gpMOvFrZ+UiRg z)M%-X(sdD^qHDbSvFj&h)hJM<^`V~`YM%S?GrN0VO9i`tOJd9)_RJaqS8IL-yneNA z-N$aofV+X;C%P&xUYYLAaY+<%!t(o}{q0PG1Ps+b&`^Ab@5~;*Gpnm94dxxL&6Xqc zKBK421U=&!M*jxvF9u3oba~cSIod^HaYM~J#In}06KQU)qrSjRrrX(^=So9N{`z9s zNw>pF#li5oS7teR-U9}vIf5hKrV!sLs_oKJ#Dr zlQf>MUo~d4VzB?(|CjU$`14)^;TPk^Kwg!cGR0*1{w+>N>#ORr4!ra~993wDxmx>I z1~oSE{h%wYm(|^i$V&{wrNg04(KlSKBH}2~y*tjWhio^FE&&2V zqJ{;sJH#^^B=!k=`S)jE-HRq2O_@~E2PV5{{|D+pE{CTE!Xg91+cT z<#SB(M0@xWpDXnB?#vkJO^2m|g1VYN8XF)WQueuG#zcqn`-m4RGb%iYcy-B49lSQ3 zA^leilk&s#bDO`WKh|NcoXCI9{kKsTr(MWBd3P#UI>@raZ^OrKSmlhyVC^96c@;-o z6A^)RL5g;OYy~~VoBBTD9ZbhME^fymy-~ULnuEFR_9#9K5BvzitySE3rC!9Ca`F0N zb&p=+A;`IqGl@Nw>!Y7;R_SkeLCg#j2e>@PDF@6HLIEcJZlw$6%A}>L>FIvdx-Ek> z$fH|AQ#U|aPgh_w@61H}+>GH*kS_|`-R#EZg!;Fv#%)eKz4Jgf|d zR+V-x2l&E-{^|;OhKv6Gx}HXPtY2u0iJv5qupLXpm02-TE*?au!SVFd6k# z{SCvz<;e(pcx(ca3w@InhbWlsqDbKhlTEDU?&O&`?dPKDZDiZSJ($b1fq^LBcSY*w zL09@;x`H@592M>I%@IpW42ay+vYmnhl{x7x8rTSw%5Pd_^D>0TI8Dc)ISmLITWCFCQ_&7Pe+bEBRd z&Q|Pb;#wrk6El7V={-XoZ*Rsz`Ml;HtU7)4a!;-i@gC)5?TrI8`JRVHS@wdnAN>Lr=;H=&Q5V# zj~u9G%#3f+9BlhnOAQvj#76|WL{EjHr~OsGJt~_(4O~aGvzHde^T%6UHAyKMec%kS zTXTGYteXGAY6q8b5q3HB@PBMN|9$&L9xaYWzg|hV!dB8qF~a=mYqR)U*Q>XzI^To8 zkfw}_b};pAdb>^wt?$;cI=^)EgGX|TUT&u5W~-X)F}DMiZ(`q>F{F z1k{v6sXhlxKLbkQbwFNiEK~L~0H`iEPpge+V_6si|DQ$^X4lvXl*Hcx<0=0-wbBCI zzvNhCTY}D820TM0L0Z7r6ex**1#08d8jeQ*5y5#_H_opUmZmFh&R!@_mr-5;l*E7k zGsO=NJPO@FJk}j0G1x~$GyD$by;H#?R<~F9wj-voDa7d2iY1C|A z`T&&vrOGeXeo-&KV9DBOXcjw^TQn^4!8^KTgZLF0!$p+M*{29ngtY%-GeTHg;Q zNOlt*_wg-2`JycS1nWicXL=MKoYQn zA{BrJr#n|wYv#Bp!!Y$fKIA_V1oSwmLl^WoMk+JEa#LNfj_W_T1pOa60($=PUqcom zq-Z{v>)>Gg9}t4s4A>a$wd}u!65O13V&Miu7Y6Te6OLu+*Cj{bWoUL}n(t;1Hd zneu?CeA8eF!^?hxS?{G9d`z?M!ME4FrM!>Z>3=i*Z-~ag5am+GG?8k7wZ4DipG8p1 z{%?My$)j}e{ycvg+F9^#Am3E~8}~nmM_fBEKZ@gNlF&;&Jy{OOBxzFBOD$Ddgs*-o zjduc>#!RDpheO@}fjA}70<5k&vd%Gm%P*m7vcpk*K`)`&vQWAA)Tew;Sn?_h>LdS~ zSm1i%Ch|W_FYoTd*yocSA8wr#_6`ge>{>c>7oN%QNBr+9>04b;Da8~AGeqP;EVz`k zvqf(vW)X}wp*b$1BPL47J=TwM+1Vjj zzs>C4|K|t)gOe(!INjMD;4q@M*EiaLE3lWG{b#2RsN+059aM`F&{ogl{B6* zC3oQC2)gn9b_fKlGTYoBZ`F>ExGsw~?7QSZbuviuO*m$+^HQ^)>-pYn8}hxZx$+_T z|8Y=lti)tw6JXgnMnx#Y=z4-wFsdNcMCs;Y*|)wHz@XH_Hu{qXlU~UWKb+6IL_04a z-Le;KNSW21KWi-l;2xK~I{E(wEZc+*l=(*z85E&JC)*>r<(@lZM7+56npkVe=z-dh z1?1mf_jfny#trTTU0EW4EPl@p=`Ip`b5ruqTiYcx^5hd})Q#JM@5Y%_GsM&AWj@JX ztdJNMun{|wy$-&;97^Z6%~8yH?RIb8`RPuj6TpOqj_hT0{vlnDRIoAx9le8QD$Rj$ zD3YWRPUse+kHXvQ9H$vxzrNi4!umcgTF;z414o+sKUz%MNGs0^HO0Qcd|99 zjp1f*R>v*LUK#Rm&rVNIPu&|&t*2@}Xe&~O{-3qhiqPY!1ldxhLhkbwgTuJ-^nFCxjKt?T|Nr{7 zPzlp5Gc?{C{Voq^iCW$I)TbRK(sb;uJ7bKLuU%KHBg&*{7@aczw@|^Q0gpM1qvU4_ z1^-Zek7Z#JcD_H4a_CB<#ddm=$DUZ&sd7#^{td4y4gKjmVZ6Qo4RiJ$XWSN74lQ8$ zqacI{32u=ojJr)`EBWOnG+_TpS+7H<$7xN%|4xOS|MaanyUB8fxoF7!tzU!3_U9EX zwXD}wcJ+P%bd zdm?BzU2d$^=xGm-QSuwf>XJ#3w81l|a}SHV>$7<5C25RGLFa|nv$gi`KUSs)yO^X4 zyX1(U{+8*W2_BI;q;(7`Qp=7zXm^SsV+AzjJFV70zput}u@vN?QOn00{iI*t<-2ISAX=71M8^|;yX#Cv+HG$c0jq@}+=NIaPz1M_es2HNA zD~KY(0i*Z#(uP2o27i9QQBGmgu>zJGsHm3%hE*&DC!a29o(=FAY}bybX6&Y|fn#}Z zKK#!0zc_FLnf=at<9>B)O(_|OjH8h-)GAbAJ#4winfRgE`Mk-p_p!$kZOARXn&Y#? z*PeegC=g;GeN_W3dylhQXc$T5d{yn_KnV z(E?!Ed6xjJXdgQ`U<`U0=Cjq65jv0CgKq!!s#1?;dM`Hnjn_VvFbTf0PCcu{Qq7eN z0`{sFh06elmO51irbd}0y_9=9-@lw2c&vDJe{-n%K-mT?5CiYkB{tnT{uG@cpPB}a zey_?E@hGg~vgwC*@9T?pf4_?ZR+_t^79QK-=ili=iVnMDp9)+4bD%*eqjLV+2t0Ji zC@n?!DQa5X=2x0|9!bkH_I62tfqT*_4&(_ZizQ`vJpa-Li1eC)#~L1FR&fv)jI;wi zW~u^upsMT`82=`R&;Jw6Y%rBuxV*<Rn9V<4j9=?S4r&lDa#6j{#D-rxt?nz<5J@8w)Cbf#{5AW3g8vZuUpzX$777 zvqWlcPsi1J{5$g@Wi$vWz>r^nHBVuGu5NQkcv*n-wNuBUJXD#pLc>|s=dn*Bt_Xw?^V zix)eqzVo_p(3**{<#yUH_W@E9zoN{XO?fCM;1LPu|}PKHFJiP}?M$v?i@Ev+Cxnib#t`JNCbhsRF35Z)^7DTp#tkQr;BpkxvF1rP>U-=scj5 zym|BH7?`6>B=g*dlqY=w>+!-y4(bxpxKs4_EupV|Kl-z(RnUAqz>fVkjCc+ol2_bR z1v1%l0~8iPuK>Pt5Z~Y6ov{Lb(Fj`Qo)HQTf9{r3XqaQ>$JDCZqfVlsJDJ?DH=yhr zI=ynEYTv&W7;)_s8raR|UUE36b1eb&(H~+tY}CyMr4HYgb@O8#_QslyZ`LyL7GCB1N|!7S?@p{AKcD>Px%Lj%Y_b4*uzThe*q+f%{5XV z$7Mjuln~g0MHOv#`D3l|LC~1J*KG4RUW3e$tCcX2T(em4?O%C}7poXe#y=^zUcwdh z9YRxqRDhEGY1Mm`&t0yXBS4N6*B#qf?yFPAvXWXM;B* ztu6yxPdcuSV^$v-CD6G`u~dx(Nm^_+`x%byZ7_K?Ynz*XzcrG(TyQ?@4|;wbX-$-f z_1NjFDiUp!7P)39P3Gh+NTD`kVYFZ@bvpx|>CoDA;K-(nMUkPlS34tRFm}tV9RZ5- zU1XnGYy?&@R>`q~ZKmFM_KB_dSpD=Nz!K0{3pLiiI0{2n7oV>VRhJbyXpzTPG1U9nr6PhqG z9YngI51Io)7$F1bJ&^Amqbk}m^4!6fhub*;!|jwX4!9xa5{9aNeAL~VFO!`aHai{# z-CDLQCyB6C*;`O-ydZ`ZsOgAQ^g!Dvp?wAjMXIz&ij`e8{_9md1d_|ypgn3vXdyb3 z)2nf8$$%&nla7Q#y_pOYRT#=;DfP<^BxOeex~BuLH~s=(Q8NqcBn9UqSt0e zOon4%6Y$tSezXGUu}xQ$&lGdS8`8DiaM9fL3m|BsZKXfMD~BWN)lz3hLRB1m_! zVOczVA*35>zh9T0_f1;iJF_skEx-`O0a)U5Z$qjuMJ&TZ6^84|Rmvj)Z(Ov;CYu!p z|Jj*%UQea_!pPFQn^BkUzYmN3DD-Xk>Hh0cZw_Dh<#!kF0{RS${PG_3JO*7NVXj`Z zgq%2u&`;$^{4iQQ%bjL!IQx@qmfDDiC*R3w5O5PvZ3}Z*3TY|(ewQFhQFG>4mQkX| z^q*d&tXS5|j#X}a2L@2@fjyRJ3(Zd`Bs$oHFe3`>kuJ4G%Q1pjzFXEF)n08yADQ;b z3`_3?1qm1swVkyXR=7OxCB6yquv$jE3Xbzm9_t7v(R~I7k4WCY`#r4JvpS~bOYpSR zU5BEsRqjrI;yNO@LhRldYZgaZhVh>IuY}=rc;W|9$|%WNu8MP&OmF-8Snfaw*k8Me zRHKhAK9d#b(Ps|xTOo73$Oq!fHz>_IH`YA{SX@8Q>o}slk9r?fKY%j!vE zc}wNcTbJH@=JlpJ*qhiXzwDiv;-B17f$aYWu_INteD3CSaLYAyTOW>3c#i961$FTB z;7r2hrpb@VV-Qd27EDGO{Q;?5Rh-(O~92-=3n)v8Mx z|DnlxzHE-7QScur=@MP%5)*TlfwL?zaJASHPQ`rB53L(Be^XPcBvA|;v>;76eHOw> zjEy+TC6)R4^!d+{F4d!#76k;R!NVkkm0p^%mwOg9%U@T;o`cO$T@S6v{VigB?O2Yl zjAQot^X>s`AJD*rj{}`A3Xe-e?pU)+$Wj}#Zxptkn!>>K&I460tO<(AH-WegAUe5H0rQ(7L-h<{G;oQB4U(d z(JVJcnGbC8?*Bh&Tn7%_?fciPC-SGME#N7oA;jY5Lh*9`UXyBEsnf-^&arMM?09o2 zVdJu1esk;0kX?I68fuYK;~u_a@nR>ws=%2`Cxl}}CZtIeSdLaU2L@~@R%_ouAs zQ}s1uAw`G{&g;VYdw9Bp0Zo6RCW0%I*$*!@@i`X0GQh;~dChPCn4icxwg)se*!f+OaZNpX>!`J6ulJ?oBlf;vyJx=06z^cn{fqHG6aeZM7rAC*sHDI z3UpGWigCW&xo2? z0MOG`0ClL<;-%OBK0m+eaSB{l9ypI-yYSIP(2iBzdWfmsW$_EQ_hBM{HV**DAsFRK zCcajt@C|(!tL+;cbLjKMkdEykfF3>$Vj>mVPgbvYg3)t247Nw0K1u`yOt5i(cv_Ll z-}b;ZJtJEWVO+-!tkd?xu#Fz=xbU9wAf~j*A)8 zpt7!i1v#Pb{YQ+Lz_4E_0y{KGhWj5>ryn0K0$>hUc{=*UN?&79gPmx*mh&RR?Pf8T zFNFZVgxPW`nBm_klWxn%k3BB?v&1jwWnfB0Rs03-H!ZMZXhu%sim6fL6!|}6rv^z4 za_}R{ESG6gWCFa?E;;d>2e!IT`a-Wtt!KNQ93MN%#p`^oeq~iGo+uiR#>t_*{qUNx zVTpz5tnr+`9doZ?cjQv_ChiP1%FK_uA~#!W2U}=%lNp$9$~=YMRGN1BBnpH#ZHx*R_FRMsCCt|zvRV4{Izd~pqFV_qxEHi67C-tgC8#>r|n|p#PpNJo~|#9BE>BZ zzVzo-qP0WU(*Ztxt%sJ1cFb{Rjlwx@CZ==IgCj%B0q&C zieW*V^k2*P59u>G4N`n5C*2<8pFO~C$Ka1$rhX|E95mDZtj&i?Oj&m%i$w&FjBko3 z#>w>L{<~G+G~JGn{e4LIp9_eQ6NdvChdq+Zo|#v_{F)!&hWTvmxc!*Gk6FP*(e{G? z{>BJi(i;ky=ldGq*nfJf{1rseM^pmH_1`TohHGZ0B#NW8u{VO&IunR-%sy4(WO^+m zi+0eiLvYwB3^o<~FXsx@k}^0R1Zp9?ElInAH#_`Dn`EQrx@h*_ za_Sy%fHlK7Jv&L>?P(tx94a@3a9HDbLy`dLN3kwX?VX{cA4=G#K!w1W-K*(Tkmuc% z#f7&bRG>IZ;;bp~sObb}(eZ^P)^-DXpQI4bEE(Uq_Jo3Q#4$+HqfK6jIJ zwfYXf?Rbw!p}!G1;)TrcB;$c%pG3=5AxOvj3j0(}^}W;f`h(=q)k&}_fJ|3UhRm$MpyKc z?g@lCLGzM{^xQMd3toK?v!_fuQruGP@%L$**^f|glGf65kAE`vW=w1Q-CB`)u8=*) zB{kh3LZ+QIVxyv+t`SNd?>Huj5AO2h`&^srE&BDdRpsjZ;4{~RB$v2asz1>Mu`?zD zSoeEu-sg53b7aHxqnz7KjZ#^e0n4ZxJ#&-^JN!)SU$hjTfQxS6$LtLTrvH`F-K{MC zQ6q~1siI246obDbh=9*L0(U{o>CqJsWkwu>%n5v49sBH02TOL=t!9qPple~;d<}X5 z4emSNaAjTekFZDw<#?_D>U+pdvkJ2M4!%@UgZ7+`D%B#_KV@_AbBl^fnsNLiBSMJb z`*-k5>6~BCN&QA4jx^_moKjoWFGNeGbgy)S?W8LWMzfeAx@Q5rX%l}t9xG-UcevNT zF5pfn^=?PfFAQ)G(jEu7>qi#T;n)fM+~>e4$aL~AWuM}bf#Y0{FN?G}!9I~uT?G(6 z!WFX}Gc9Y!=Nw`TFR@xf(V4u=!U*%yAy+Q29Wi4KhW%fF6jC`&GhdM?m(?wb?5h+< zd&9uDnJxPQghPxGn)DE}oW6nf3L1_c&M;+lYzwt*qIHZge`RSa2Erprf@-9Y&jM~H z7=%XbX4+ViOPKA1wg(cB)V&JP+D>#1KT+&bbk{^Ye<>zvu;kZU{Y2QWHB{+(MeXU* z;OPe;G=32KK4UBFzFIzSu^uY>qn)H(PB*}lE$lmqZ3E=nQ_Zu_ndp{PPuPKz;wv~M$Am92Ak4@t#T<2cO4?%T7 zWuYs!)adt0V1&Y1OjnWXxx{ZHd|{i1D|#p^D%Kr1!U~)<`yYG&-ehvhS1VeowzX9F zhQ?oTPZMa31Mf&LQF+*%OjPVyRJM$V8k=4tqM1lVsEF-ap}l!+0iR{!@~e zRwtsY>3cXM)(CC@e&%_R>h#k17R_ zkhg8FQ3s=$nH;#F+p7 zE`Tfd^`8+@a>PMNzZDVYlLb}tvEJ+OOgv#&4Nt?`fF(8E{ZmPs*pCDH1Fp8S=)Wsd zh%>dosZZJOvq*z{?beOp79fx=n-4YVyu_^?4iG?wO3DHrJCaqBw`#OuJ-W%Pkz|I< z-Vt3TZnpN;;Sy-MN~}rd6AhnaPvg_}skw>2iMdnqGn%)O@1Eu-!}b3eci$r~tu_M215>eJm!Bfj*o;i|GiM%Sv*RXiJZ7upGRN)Q4MWAWI{|8gd_y>AxlE!s zjDy3Zi+VQbI26YsT0DXiU*20v0UwN{?HBx061>)w)lE9{@*aQs`QOS@d!QhN{i$*Z zO{ScV%=agGZ)?&iQ5k2u!3?@dqxU|QLplc3b>5<(gRSqGKKm6P$;8O z{i?8=_q0h*3>LnAUnK;1`dn;X{N1xET`eR9ez_}7Q^MWFsZ&IE`YS^2L{#}hVl z`>vVX?1LjTnkuoA4_$i(H(P=L4dedv4Poq)u=R;vud3^n&t01U)@Pm$e0(ou1ND7p zI#M3ZAWI&A<0ec52*6C&fV>(v|9QnV6h9G@1x?wa*l5SX65(2WEQWSj+uQRmat&1* zTq*E~PDx9XDOgpF1E*dHw4ZFB0reQF?5O<`gPKB0VT&KGb;rUB(Zd=fKKoeJuO(m3 zbbRZh5aqyInF9$Qs9zHtH8e?eR3Mx64lyIj0t(<$C?&K*1=MoJf!8ih{dbCKphh;` z4&W51gG-)Oa4FUUA>HbdMaSMu)%SD=t3I#(o6FxaM3kjZ%lVlc?w#@9Y=u&@Z?Ry4 zE$t~q-1EbjG96=5Jdj*y6zC&pc)EXP!zVElD-SrN(M$C%*C04Nktx4AC}7kpM0uUZ z8zuKgXJ{_S12~uj+1`kG`xT>HfJ3E=*TDG4hZT>7zyr^!O6v-FQxFWO&}K}gA+n`O z>8$acdR1}BYSKW{<(h+HaZbui>h)UZITVgQOs zDSQWGRsq?u7P{`%v_cT6jkA_n)RMnZX5WV<*1_A=1c^o$cfxtYD-UW@M;u;KjvS5#7$AaFw)6}DB2;y6();e_MVpV0z{j@R* zcI2|RK2d&6E=2@=YEqt17@;AJB1>~(JQHQIjvG{Nm~QBVtEZn&(o^=8R)LSWTrVvS z3k}1%FUKzh$CP&qz58en6*PZ;Ss`4(+ZGN2Xzl`0_^jT%3O)^$M__h(Y#FS!Y8+iU z+wCzBgnlr;Pc*g=;T!X0_zLgf3p|`1(TrCik^?2S}a)k3ErJItJv!r8| zz`5bYUTfyuvT%|p1X2P8BY8F9XX<9msg#qh_EPB;Ppl2av^x%{eSIEU`mnfbYs_P( zYi01;zvMrziz@_najCBBX|IE}9I6KH!!yjKprCvdeBXihbsvGSDm z7uIezdm10ZlgNKXurYYWZ$kn9_DRf^=5pP#ha`pq4`Dkc6d9+-$Ktp!$`}_+d|c(^ z{-XFJrN5Xja8`FgzV5(Z{y2yd=}wNJDr5D~`nbJL+s9!!|H8k9d_OCfQ)}=I-kNmJ z%ZaxuX7yziMJ_5=9Jehx{isjgEInb48(mBeo9FMrFn*+#-x=k}5_6k1y7tM5xguwW zWBM0g!dO7JKnU+EgX^|fnpaoNV=i#+)w)t zmZbGayeWEx*LBK28FLuyj$<*_^$*m4)t}j8p)(r9Aq5*WqnnF^#K9sxA$@&+s$4uu zWXasdf>?n}3lP#`EAirpw}9Gt(gJ!LPJC=Av3{Oa03=2%pGa73!y zwIiX(dC8Yki$HYIhRrL{ADmSi>psqCx-+Uu=~acTcZHH@HzAo#$p4!<8jHb3)DHcd z?h#!PrqbpLq9QO8`oTO`CUMC@%bx6TobKutKU&*ykJ%mTSNA4gRl$T3Llfxb7^xmV zFUV|T-(KsIyu;AR(1)_On?tdfk?u=;Vr(k)-ym#x@I;|um7CTe>L+AXB5YPZynNjd zn_hKms?THg&Ur_NC){1S$DMfL|ip*0Q~SKZ?DjR32n0Gy<^TmZr@tF zDPt{wt%?=|bHF}S35*n@!R^e<;-I)remxP*>Q0&Y(!YZ+<;uC_q=&N7=tr!mOB=>d z2QTwVV+LwF9 zm16(ufJ;?wwBUM5E!mc#yj%~ous)b83f4JdpM(^Mc^TyqOPz1mCx^BS@2kw?Zq3|N zwD$XxB!OurWm&>xzKpRZ>I4L!$YtcI{y%KhV8~PVF_99rR4T5Y#K1^bR6~;?3IZY* z^lHzz->M^@Cs-E9yS&m<_Z}=cESk!kfj_RW7>l;&8NHfZM_V*qx1C~rE1=FjvkN2b znk_m}2s{LtOOJ%&-Pkhl(pH>5M35?2{q|RwJlB&QxV@V$dRP5smq>@R1*UE*QKowc z{cZumfU_I{XJW%5tv2niPhaNd=5~-;pr;#=_796<6YKX^H08m`XtOtO znhPf?{l%b|@`d8hWZek;4WuUcgWGkDIp`@~y!0cGhYj80&4+SNoW>|a1hAg<4+G$p z7O4ls*&g#t=z2xdRuK3L59P9y)t~KGGY+Tn*+%Nk#A^6WY)Wd%IEeYcp=I;J!*bD! z!YYpL8nn(NvsA5SLB)d!gC6 z5gUxd&m>7y_&}q#BDVlOm!&yiLP9WGTBDjGemxF)>)hF9Pm5B*J_3gl>)lzh6?j7= z!KdDlF{o1+7O6sycL}A7p^;?O@|ffp2&RX`jO*YIRw0@aBZIqBrA?ea6YAwASt*6- zivdpl39Sz_OIh0g5j+#9|K&uZjQaV^y}qD*DB+QAg~RHvI6>Ldx`G`Pf%e7@l$L8= znPo4_B(M_?Jz)zXxP7XMWj^fl>PP&?s(aec*=9b?Mrw`+`7l}+Iy?J>T-r8Lnr-=q zC8l0CB=AMD$yIC$SQ{xL;AnpICZ=T`FWd!&T;x1^s!NotjYJ&!Y|&lTeu7i~@AHv) zw4f9Igictmz;-d@F64kspTY;q*cppGu4VK5Q+u#apj2ZX35vUe2-}d*3{{5QMd7MJ znnZu{m8O&fDx!e6eOB$K<=^Fqa|I^6u$5{_bf&of%=!fDjb7)=$m4xkPpETA-eJkR z(>>CfikoYzJk`f%`PT`T+BIX$r|g1mJbGK51rrdOh{KFi69$lZi5OYhSCz`~$fmSV z3CsIc+gKPGL4*~NVis*%7pL*(jle7E)tvpd7bk1fe`{Csjy^S@+`KmQrTf^|LW!AX zh~-2^nMdGA@E7$jvd7>K6~7rIx9Q_oi;3rcP3vCzw{*hp`nd+S50162iFgeMJoqK- z^fkExq!a#1Q?0ro;F?^iQ3D>kJ#M0iy3E;-3FPge zn_K6h*diDQ-wUDCU%p#)WXE0XR!VasS|A&JJb zCi8c&VI*qmJ{v$0Z2&I~RT#zZ<9u0aXl)0d0r6lhzM%?8vdcTgWqJPQ>W$LA=4EJUVW_{IppNZ!w>h%8gvamqh=%Yz;$wI|Elm!3P61+XAZ zn;%fh(nwnukUoDN0q>Rs0H$gXwd+Oyyez1XGmio+$65TSyV+6CVL~oy@Sc4Xh634o z8MZ#ZHUf;A-2m8r!RY6W-Pk37j!{3qFM>@y{p}wB4Tej(b>2NPDfY4nB~ZXc&ECNz zYT4S?J~aU3L;{fI?esw6?m{3~$ZM>cwL+b8bUx@+x8K-m?` zhu0zPrBqRL2ctXulKRA%_ISBE;M-6#1&UUrkYHz7(=CHCVFPj>MPv!o1wzb?t&Auq HU84U7#M|-t literal 0 HcmV?d00001 diff --git a/versioned_docs/version-0.45/develop/advanced-concepts/baseapp_state-checktx.png b/versioned_docs/version-0.45/develop/advanced-concepts/baseapp_state-checktx.png new file mode 100644 index 0000000000000000000000000000000000000000..38b217acdd04fb2430a2332946864de04474ae5a GIT binary patch literal 82308 zcma&OWn5HI*FHRefP#Psh_rMGD9zAa0@7X5(%mg3-O?ir-45M?f}nJ_NVjyuyYYUW z`}cf!Km5PosE0HA>=k>h>$=v7c&jLlg+Yt~fk3ciWh7J}5ELi`f)xD_4gAaW(u21U z$P0+9gs7T_!A{nr%>MDK9*SOK^ee z3r7Q;Z~%j}(d%Su{pxi0N`Q`TO@$Xnt>@WuR29?$B3nsR=YXyLAjH-@u&T)vlF& z(`G@G=rG^z2d3Y7$n;9t*GIp<1{21T@ux8QULJ>48ni;+cYb(;=UXPlriuCo|LxFl zFASrB0kSd1sNP^WkB(W)?Wbn+z0lkAf_{-{<6POK9O^^haqyiGvEXym|5`HgSt~*; z1S8F9?H5s7@OZo=99cS+Jo(e7Pos-q39;ZW<-Gp4*Q2Yn;xJSKzI{95V?TeKg}m27I>Yhu1eE236GCB@j8Z`L#)%=TTXo3$$) zYV|%-QX^IGAVkG?@llqqjD83{Ae)$@W_4_om48S@R#sNdcV78XT@AiCt;^aJO053E z4>c5v#O?I_V40v$F{??nRt2?1T|~4;H~+XPTvq_?Cf8 zK7^B^hqi`vVjOaHbv3)s`QNDsJo<&Cq1wwvCL^%^;l}%|g2C`UF@A>OJ+Pu!G zDHV0K;xNrD^Yl#@P`M&vJTz(y&{hzoH&U?{H-?F*sf~?SoAiW!m2r7kA~HhYaj}|e z)*VH()kUY@S5+xWFFTc?g}xygs7jTfC~+D2!(pB4^8;vM%pI%6JEb44#i~D77Rca# zQOs7VFWG*4KU$|zO({#@y1MhsgizS)G0#qx#|@ZR^x22`r5Iq9^d>3f$Tl4lA+uWn zf2KlkKcxeq@*#rK^?7e@K#<~>AJ1`<88#$7q`Ah~;agHsB}#rcVyO7|1A-|Kh@7<; zd(E`HKA6&i8u{Z_prC07$^Ix&n(S1|avy$sLZ zrS)IRorIU}PE~1y*4oh^>ULAgOH=zoB`be^IHBmRHuR78Q`j=V`+8wCk1<{CSnfj1 zA+C~tc&8a06k}MJszGjkzv*eBuDr4!r08W2CCB=2&&;Xh6v=Eb7^}1;m}pgJ3E4Gl zn+p9#i>^?Rpjq!VldLk_WhZRvAO7aZwZ$W9_9~6o;Pt=Tm>>V*aQ%v?{S*a7RHXNc zc_G1IbS=Z0aZhA@YrK@b+FRGteiPZb{~K7^t~+7E&7u!2BJ4Cl)V|_l^WE>W#UE3O zcR?ELo14|dsAT@kWhY^YAV!x=70BdOK>Cp_35s`a4^mv2f@Vs~ZE3$-`(iDD9*t(Y z`-<8mD{Rl3_6ck>?-q~UY`M@}Fq(OTl&`@swBFXH!(w);es!h#PB!b=ZWI|(mg|v) zJ_^&GNSL+%e7n+&8YAtA!4`u;Q#Fn32ZhJnFSEV-Z))~;V%zDXf@0bUCN8^VkxX8_)%dFlU;jb0|87PgTGm3V_s<5$<%;;ff#~FM@zm0N;y8l%l{JM*IVmXU z*gtO07Ab1z&cPq~W2w_tQ>FLzlu}m5cjwme3tMp_gUA15B@q6B0tgkM| z3a1F)o>ME{QTUyUf+R=1-*Tj=cf2tFgH^wY#?bd9dCq;&x3d~$>i({&8Fo#*?v%(5 zVL^%z3G75Ve3#B|akxTJ-vY3kEAsCwCb>{}>)`ksRdj{64@!D^&E zv!xScsm9G3e8>Hxlq~&c!}zS}iM6WPUG_Y?#{$#E?vN5YY*W>|HD=yyH&J2R^rB3b z-Q)IsBKi7$E^OI8r1sW9<;4&z*g2C{{+ZQyN%HRpsu~q~jCk~lNg(Zh--hfjwi|9u zRm>jP=4v7-2$scLEiUA-0$hm z`|@FlMU2GpJd7I>@aZnQp$Md`5~{=f(iZ#&S(_Q|X_lD7sgt3tRLm9#qD+~CFpA{u zQ8*V2;k(PucQ8BbuR1wV$+>BZUi;Rb}I5Wb^6HcqW{gK@CO@7OzLv!+_uDp zFRZ|`uEY-tUA@5|V4^|CAy3K{^zJKBFMUJvAqP}X^tINL+=}kaZo7{e`ait}2Mp1> zwo<>#P5Lx$+w=?HpD8S2-h_eZY3-dutu!i)FjRl9=b;uju`E z))Qq`d!qEY&SN*<@RUC3&P@yI*4ZHWj)0wJa+l#LfZ>g-jSk%9iM$i($@2*OxZ$w{ z32^dF=S&dF^FR8o*)F6$kSV~3Ww=LMGhHNM;OX0Q<}}K}hs<96e~mTgdp6(AhbG_< zI$5F5d~4iokYo*+e?J`Nt$vUPFPm$ov~z_6q_iQWeEE681yZpggA= zIhitvCGv&{b}+=Vb;SJ{*o$JWX7rEnlpt_v~fNA{7v>dATU#EesnE-n_SEc#Qv$bK@^}4nwFl5!9s!=|Scu5(?V$brST{ zq(Wp=j2}FUJ|=dQodK$Ls)a(A8`OB8JFL(I&dGRReCcu>6V19Ffa1X(I&=)1>kqY_ zEm%|GLVg@9_k^f1=gJR=)r1$RR=@kcvNMesX>_(&PHI0MX`lV;EciC$X#dh(cM`a> zZ3m>PH;ytmq7KCbz8p`i(dOeh-RfO0>uKU6g7m~;Ypl4z5yd&xyB%5 zwV|Tb;8}lmC*j->_Hg*m_ecdeDg%+QU&|&Av199a@^m$%Rnh2Hv||Cc;X~eHlFV9od|ySpl+ShgggoA6g!{LhdsC z6K$ON@~NSLH4G$A;6LL;W5_Pl4+)!;MjGHA=Lj|o=&hROHZ~6`G8VK062rWyqFJH$ z8aER})${e#@PPt_j5iWrYvXPu@xMan%lNB>QJ?{$Ah5AEASfIb1Dx@Xg{bp)>KFYY zBWoZ~A4TYNnKt5$TCmty0q9xorgs8r*l!1X>!OG_)`Ue+7~-7Ph;egmb4BrC+vW8O zALS{iosgr{id9zA4}PB?@ra;9oW(NfeFNBXMI@4+kHSQQ-()C0tg*7bCL5wke(WHQ zGcx=fC7!y5MhvB+VU+YHf?V6f<#e)f7^3{L841auXOM))j`LNI1+9Dv=kBng&oaiC zb0G|mAz!>b%hVZL+z^9I^dU10H|q&!c97yjVuj|+cNie8Hb@C(4o8CHa1ySEMA>p+ zQOHX5LgINi!&FwA9+~Znh%ru;!WLArk!HnAUdl$NRd&qXMV}*u<%UG$wK-nY=SV-o zF>qU7WW`_+XyGlt3?Q&_JSJpt7Q=nj;|oa)K@kbAsRFr~7~&9=!Mri$i063#S4!u! zdi=Y}EuvNsUXF_uX&=U!E8Kxq?5(HtjgFgJ16)s6*>c#&7570(@ka1ul5ArtJjQvF zi+%%Qnccmrx4*KFE-Bixh!LiA1L`T0pEBeT;Hh*BMd=?z7w9X#Mh!x8(K76s!Otb^ zcx)}{u|1gb4T5Z~Art?HV`8YP?t>aT)$=kW<9UoKhpXNC49iEbuI>kJt>J~?*qHm; z=n`Zd*pp}5lYUapA)sBfzZ)~+v($VJ1rSls5|hn^#0mzI&YO4$O_Hrv052}MR0l)m+9 z50R4v)@d60s)wt+R)j^XaawR%F1GnPp1jhq7YSo2wk0NQ@<1l*7#VE{e}Gy7!e4H4 z$X;5M{@AvN`ib(;qp#Ya2Mv-MWi9-K9Ee7iOI;S}SYcvZ{&1VuVE_r@#%qE=#)y9e z`Ec?Y9 zd?etp%N0GIRi~JkQ7d{Y+T^zT-Y86eObeak-M5DvVSWl;9WAt~mNWRly zmF@Rt3tn;Ea-ETw<6{A&FF_q0Cj-R ze4bAUQnZ{^^1iDF1vMov9=?m%kmbxOzA7lDmUl&_L!$JjWpJJMnk1P>1`zWzX+N+7 zx>#)@Sm2eo%9N{2zFsk+SN0c2gTh!2aZTOGzElJUwX#|8g<=0mXmKPKS^#fd$Z0`C z%xt1i_LfuYVg~oTej-Tkldk-B?k88!if=JpqrMo>-g3+H2@q**bf1pi%% zmMH!A2g9M%I!K_u=5ALC)*L#JWo_k^xra_vy1q@apn`ZzcjNmGZ~)oYo3%?X)Ijn5 zF#0K6A46`a*s#$4?!~x#bMhOEmjvKl8IST$@C=Uz6r|Lc6}Rhf4}%n$=|kLA3D`M7)i)?*(5z5<%w?VF>+RxFP{@DR`iDoY&vo+qx3(EhI<=G}oP@ZmO0UlUbK`Co^x+S7_eHc(frS-HTaUX{hs46kNEv}5oWRjU$* zg?!<1RKeh{tac1^uIDk_b|&}R6kzV2^x8SG(e0&fM7HNEJu1>tOHo+AY%ms>X)d&tbux6(ZPr-OHT!N!gjaqCmAy4Ujqm3 z50IyR?d}M5^S!oV-0^BKcZx={$U(R|6!2N%g+UonhxmNXt6X-bUJs9J4H=iNtb|u_ z+RaS`WHK{2XfdHj=JF^Cp}V&I?Zh;{vZxzddqdvcsWEauU|)HphCVBc@FumGg9)!g zs$IFDrv2&THH+XlUV>;@e08(A>pz{472HWY@`ng$M(bVe?7BW80{M?JWSMyHzTw>xTj_zzRu#@n2Y9SHqj4-_by@EQpJ$L&W*{f#mve z%fEDRASNw7Vrc5PnPaMw5DiJ#x!ga79i!~LjFJx_wK+ufh%j0ynbi~lSh);DY4&LV;uW|KgLF7p;Z zq2{FKMjuh6B7Qg&6$zRq+%4-Zn>zR3mwni9AJ7CV@Jmn-bG@gD6~1kFOvL^T-X3q> zW1MT~a}aVtq8vtO=%b8HF2GPf=Omx`;PgrV7qg$~j&Cx!`=e}uTc|WTnJq`5$Vk)- znSlZxZG-nyV*7I3DEBaq(W6&?j1;;%YOmY8&+Jg%%{RFw0o(`rJEyjG-NIbyUb$$C=>>hUjgXcQtO=|m_7Lw zj?XQ{yheGtdyLCLS*NNSmqm-Z&S%~=_?YZ!o^tW#ic}2s-R1(1h3m(-k(|WCn zX{E}0)zZ4oatk*1*CnBlu=i=1bF z4B?)`3~+c(?;yVQES@COX2R<)(GxLzr1N+4*tjU9HkrN^(@n0Wo?U~Vvkm<&^2dr* zdpbh&nS-1MJ}1HdEUBT8g5I^!9P0H#(&Q=#i`q``JkDYr*L{}LjJ{+4r?!Y~j zV(t#Dn?ij;+lOq5#5MKU$m~|VSVa~pm2%=xmGzQ z1rlZ6PL%8RoZwnaJ%R>IAO?j27Gd6c@+6qR@Q{$0hLzW6c}oU>Cb@yMA3cgY@(KzfMZ-9h}krVX_Df#R@-`VOZNa=62gS5pohiKkIr z2J1FIPXllHY9s9Fno!7o=K@Z|QJL2pE5KTG9oX>E7S=V=M~O8C5oVKjevJiZxGXeg zL(iyW0%BTYYPgJgN9UYoM&~^UTzqbYK2DL~yHHIWGx9h9SG3A`-qUBFHT+RM@S$eM zoyixCu#9Gz%fnHm%wFWK&CHtI`jNc;OGN=@pL~vY_R1>K! zzo^B1ui7ULrO<&eOE66l?GEtob1vuUclXT@Q)yF6MLlt=M0qcBKz$Pvj*80+i>RIn ziWzIS7$i@eF%OJk_{hH-C@9in5GJ*Ei5};nIu{tTZH|#GLQmN`EtPT1Ma8x8%?J6t zHXhm(#0By=o_OM>Y9ZWJ(-OT1Dq3jtHAtn&#j4&pa_}kBe@G2ofI+*k{!fYfI zkFf+^$MpNiZGWdJ5;{k?(W zv*RNrf!;wm9>v8VLQL!|?66WIxT~7l8dH?meCvpH`XU79`4?RN$@O2lLzIFzyhyO2 zpd7rB3_kHoN?c~6u#-2C*Zh0n)c7Ux;wTszs1HjidiKI*{h9ANG&e}%$$UQxr()56 z(qsiJ&-ulDwRwXLAqzhfVHaLFb@mZDwh8xn zvh;hu16}b83-3WoGJR*Tv;2o3WY}M#X6xx_J>iLP9-D^j`pg zfPwP3ZisN?R{*N6!?kP%0=4H;4dbLMlUp!qMIQMU-HfT~7aIxmzequQZC7>(?uZ;l z2_;AZ05{VZo|@D$YD%~~#~f%B4C}5?{Y*BqvC!HaaXl5ZFoyLYp#n9a+U}vuAzbi< zMWu;gY~gLZQ#i}=EK}wfPseB@Q6S>(cr*s}N;gZ!@r{f`e`758;yowGED4B(7{KvWl~(zMo;ih#}3( zP`aqe46zxa^xO<8b3OJ-zg$IP~ zPo{APDu!iE@w{{&+|!z0yU!dqFrY#h1*!Dk9xp^AE-L8ALv@Xh1K`Hu# z2!m$(==pmX9ueJyazPR}PZ;xkHfl>@cwXF?7v#(v=lvi4b2X)woIF7bUTb5?b!#~L-Av(MC z019x;k`zpzc0g8FdVZ@ff-ToG#+Ah+FM1IL5m@XBtiR7nc$BmIBuIReHS)*D!M4Py z;r@iH#V%7{a=<`NeT@zl-@V}5qay+dy7twqVvoDNlhRw2ttn)$f33%4spg=~Ch1}* zdiJF;4t=ezw)d=I9jrjV?$??Cm2Lo=+rVtSea>_pC~kh)mDXekR-x#877O_$S_nt} zk`|<@Sx2yLL*1N6x?M2UnU3%u>RjlVminv)`r2L{#@Wf0+jmMS!()}RXYVV8SQ7GC z%W2O4g|R}yc=e$!n|Rebk@aZq6S1oG88dr)OLnugpco!8PfsjeQRipTN54oWbsfJ< zhkn}40+qwIS-)&^R5;o!4+^afW532|=JzhqR0)qMrs<6G=&aT%Sl2YW+Zoi}t2a&B zrWy+l3${IL-f!b*LZY$h*?EMV6$V4*B{lb2`GM;!QaFAB_}Dc8%DP0flJhLGeIR8p z9gsub+41FB@W|tt$4C4U4PZS^h*$a-itO}4|3zP9V z!S7LLG`i<_H}D(KprkuHGGz95rLlwdguUsI<5GKQiFo~U>8SuQCNz`YvhawcNlIQWuM8Qh?puYv`db$13RuGO*T&|`eSqKZPhNvvXM{6 z1gJWqZ~SgfG)KGd0a~{{l#Z&jW=GVmc%XAg8u`2!6QsB?`)WlB20D*K#*K4X9aJ*m zMn*Cy3XpNLB}FC4G6yrcn*1Jadyx{!4tz(1%cc% z25@;tVa3;BQchL$%E6!&l5=sXDPAnlA`|x0+iSn`LqP{>3hsd`z|^f~xi7qCGz$n2 z%uM1AKp$ABMujW|C_?f9gUIfAXzDz~h~0jqNA@D1X_?<)lw4%1qJ8IuW}S`ps6Y1J z3NfVAX|-?d<#VIpV4kbvO_Oc~M&;ZOff(3It1$JtaXP0Deh|rp7EfC5(;d1J)6wA} zr;Y%m0&JDJ=M?C!D$h~c@zOdq;GZ2sahjaYtpOhS7#{cZ6Qe2}iZQ9vOr@bPqiR8v zRV)K`2t(45kWJ5d`1ueIwg)Okpu!G{4^p9C@W5X8s>DMjw_>txh4A0SIR{IkRv_s zz$_$@&f#{balDR@b5O_@@T`#C%r)#FeAP`%cv%gKpgRbbZzi8}!KU!Ci>AN{;g4dC z@^tOd&L*O6P9T-QYehZ|5T#?Ep$Xu31k2wlec^VGXTQE;SU{Szz5q_ zVT4R}nUM5UZBYROD*M{(?;^=2Og!mH=ru3DUa*K?w2-fQr+yN^VVC-Cfmmx~YM;19r%oxMzfD9wH$dq}o&CcL| zeGsNyC@S%x{%Rordw|^)FO5=6f(EIFB-}~L(5qb* zK`bT4ml(H^BvG}+pCY-j)yL^OTIwtn9HSsMZy#o{W>BKx(! zg$ZOLpo-xJV6r^+cY=YyStV$T!myBK_)sKdraOCkE@D1@lzZY5z!DHX_G%*d8nj6& zz+DpQ)*g_N+CwmmDEp&NggbBGWn1Q#0w`B*rdq7Wul);Uj3-Yz#?Q|`*ggOK})0P|M#SP|q&O>x; zL~G8&hqg=CCrvU78-r9)xbZEA zb3>*B`xoj#pNR6&&7G&BCnaj~w5LMp4~NpSQvuoKkq-@O){Be7$ANYLxekc$ERO^} zgD3)90lzO3szg<6;lVLnD4SX$vHGLNcLOunnT{eov--8+$Z=i?L9nu7Omr>3QBFBR-XnajYwF1%+3P|#g^t=YnR*7J|KYTMp8)R zE{6|#1mmbuv9k)^P3AcH&bUx%R?2N{SDtwefqGlMfTswVu>{D)KK4!7$(X4NroggjFS z*+y2^_e7ixVfbtsa$6Ig6EE>w4!U0^u*|lj7kToP;Wxek#poAwu8o$P(^+$4j*z+I z7bsb(RASi*{~zK4#1ub$^~!iIcW|*MUye`J2YlgDJc_}tWGuUcZ(#QY1h2u zDyBclh00_-^UvYjx8^$>MIt&Jab|bCk&d{ma9Z#`==9uFYt9|BCSq|XWVUJ}wCzp2 zvuhMmAg*jWn`IMzZ*bYJrKE#HOznxez?{mapJc;lm;5-5y}2BHDEB5?bzOGP z2h~(=KgP*04MXMgnyNvqH5))e0jZ=#Ama$I5|z0Jl%oKWW_xo2So%JWL5<`XGOu2f zSdG}`E}Nd|%0y1v5uK5IB{tjH)))Qhb;*IjO_;;k#j0zvw?6J^+wQxU5|^j@G(c(` z$6ekm6Ks+3sXnGB=7x^iaF>mQry}`_8F_q#{-tb%o@YhGMwxcATAiJ@651&RUOfbF zsPU>o%uzWLlW;)39Z5fbgjzlS{dl_5=?)PQZ$tA~$w87@(cdD%yvK92_kA_ANVF#= zU9#$XBq0v>5G5&8TjGben6!pr50cV55sUp){?%Gz-<3ZX&WBnzgex0L=?|b2Q33HC_#uqm~D!(`lnD!br0HqEn`%tZE zy0FsV{-cE}slJQ7i3++I(3qRc$X`S=x^6aF)LbO(G=oy^sgH^5;~ojl$ZqzO$X^h< zV!0^n&5M$Iz(2ms;G^8TmCCx33EMKuKRXU_x|$EU<)~I7zv?%+n;6Vt@x*)ZU=z{vn{fA~ zsLR89l6VwoZtBH_)3_8Paq|@I8vYzBr{`#a7YvBa<1${>ORF=4ULi;9jcVf2C?KAoN z)Knd$I06@>qnf@e{?mfuA$8xLcaqp{dFo%q2Vdon=h4D<;|`o=^-=SsZ+ft7;s#vr z#iz9kc_SuU0=@B9ZbZWs)dHu#FjeYwY>8$W<(MYD70LY$iP9$O5wg>V_>I+8CLwY{ zG)k>wqC#5rD$f*1DOGuV>HKdTHFSh81Cq*)8w4glhqW|sxbht@3vJ$As$3ZDI(b@; z$ZSHFxOzRkg{)Nblg7NNlLgdj3tG4w;iPxF;g7TH<%H(1D;`_V%b45Fvgm5EC1XVz zqz*HitRzNn|Jg&g3ojCwu8GEPsQ*+I8ZU;w)}4V!tEoG`45KSYi%C&Q&Uy8!=hKYv zLEL7Bf+qjjI>pFMTF>fN>C#?2tPDAXQwY{nl4naw%gpD-q>}3f0hQ)9tI35$?{2Eb zn~ETVS!R5ZLLje32RduAPbTZF8j5Uyx0MP6Gza-}c2k+#BrAPgELxB#TB@Es8LgRC zeH5hFCBWV(VY^2pY}_ErY(3h9u-XM;^CYC;rry%L0{M(OwjW!` zx~rii?7f?#)$F#HS`qK3mD6iIbjU0IetPM7rJ()FzkJToyUp5b3)@AjY|dVU5JfvF zU!J=+%l#Hp+TbzQi_~irXz%pI6_pAfAM@kkrl;;=g*j;3n;mc2sG)va$%Es68rgo$ zcq-xEIHuKY8FXvKB867E%3Vf$qXo_XlKaCf&)T*CBz{8S1*pCu5zHtf4wZPcf8 zvuBP95i21v5>HQS&2iyyw{|hu5|+ad*5dwpt1#R06TUM22ixU5s@ko{U_ehJ{}yw^ z{D()PTaQQ1{;?b>zBX2N8fB@*@ zpUei|z4E(0Z&x)3<0=PWW?}jJ@%d_M4qUYBy*bN3KaW}S8g?#2{d~$~OSDg;DyH_~ z1X^Ok+K0U2(eA!Z$x40a#eN=()Vgy1jHH@s6LWn;Adtsea{@iW4PI=US21h zf9N&#*RK@$imh@Z$KNMLD4Pli^DwVz{lYgM_&xbLoh#*%U`{w0j$IqyDJ8Mq!UhwE zf3{2u%YPr-&hv2ku3wYR?D3EmuidAzH2$0P>>10!F(Ed2AX8Q#p816|Pb+__3-_C4 zoz#jdWrw ztWQ_IJKXq10B)Z~V@S58W`GO&%pr7o%SS&C;d05_=(DLp3cr`zAA41VB4MeF>@h0K zmGHbbZo?Vq&gQh1#}It0BPGcbjgqCrU7jf03jI-Y<|fzui>Es}s%g=%O=ikBnoH0v z^>r>$rJE%kEqU>~t&cb^bf=c~6FWA#H+3zDzpg~Q?jhRe{;P*((|5a?PD%&p{Zh!I zSMJFtN9Jk$knXamcs&!6eXbUlJonuHVfi5uR}WiK6<8V*;%j z%i$af|7*uoA`bI6SU1BP53kEb-uhKf{tr5OE$EiBRo`3@O)4bWms&|vsQ5j-mK)fU zbKA)8Y7sXUcC;7Db=W;;g%-|k*7q_PNcK4jm1J`?rDRrnK9azS-?n}El_C5S80M9I zIj2us=r4cg+Rf!eSMvB&9k&K^!5IFb={jG;@y4{`f=+|M8rvu8MgP0#U!U3-l+lwe zXkuasLG8})=`1zu!G?sibjIknV24Sr7#(^WTy)+DRI<$LC0m2IrO3s28$PGrfC8o7 zJHMOn0RyMCKTR)wJ!1c}8|@@sKoY_*Fg;rMYrr^eF_50zIHv0ns#MzZ)=8+ z!-k!f6{deR5g8R+tu&&U8~ALHZwi`x)^7je-Q(t&udIM5So;%#NiIr%dUn?fdv>C5 zMIS>RZ-8a}<8S>$hW-GAf&1;J#uMi0R+EgtP{-2x-mS@kzFWcO{+TRl;oaC~VUvPi zK*sh%)#v8unadO`fJ-r|TJHo(*U4$Qz=ZcY&mTufLxH^Fq~`TFn32hsZT*vAR={Z>ECyeKfF?Xk9NFb5u`fneo~pV8x5rjSB`(?4^xp}+ zv^nM(HCdOXH#@Qj*0m>d1z;kshsK6zI`tPxUp`4cKmjRYT-u8pB z+w}1nlt+^?F|&K1xMAuW1u2{B_5EPdZfSD-GvCl&UmW%DX8*A-XTQ2JvU&!Rd_ry) zX#2JQY*WBEe2*%u>tgC=CEZE6xa{Wp3uuo_m(Gm~D&dWvhnsjTel&2+h7?T(3L5^5 z6huom-&~hZj_fH{kh83q9u!A%*{}u*#MERkeP#zZzMo0-^Ioujq+2HkJ*-prE%YcB;gDg|iF@kPA@ zOR*Wes#>rXk$JbRg!l@H>pUG^NCHXpXR>_ipBYLomxDi&jg&{x24oUjUj9C|bOrtk zQGwP2*&maoXb<~Ha&|Z}h(QTmlF8@EZkLB{zx{|{$XEcVZ!ElyH{u!PQ(i7$D^;qZ zc8Uci(kt~9Dd#E1QV1K+`)g@&z6!n{a2%NVD1I;TQ2?}{u~HItgzCP`cw{fboi4^_!FRh&YIl! z_sGUCsXiE#Vmzou?h3;Z_WtuNLYht~yM;NtxmX{Q9RxwpuNUz{WZ+A+`HDp7Bk~>t z9MMoTtQv3J*qyV^#t-&R9Z?`9f5_ZXfFrzftLL=J{GuoJ_WcC$g^t)Gm*=zKIpipK z9gK7%pRtToEht1XJsH3N5ho2M51p$;0+G%5UAK<4d1KXkQm!!`By$*t5k_U;(zGAP z>*j%@#fIVypvXiEB))_BkED&lx-?!?F)WwoW?-O^-R##VM|mKI!boN_6cVq{^RHYS z%f3KuLQyPj-M$I)&Qv825pEdKvdqffu;7WfdL2GI-6LR)S^+N`hQ*FMXo{$m4(MB`mX{>Zhmsi+4=`L`iD! zI$@%(fA2y6@5UCW*oAV*?=Bc*gp|cS5N`2*_yZk)Xuba6CQbk@3^dgM8<2)NzV-C}gK_jz z&yXNRsu1}NZq%#~_!zr`Ks7q+H{-1?0xlN->mY5r3Eb3EAwbr$a z@PB!Y*1Y;N-g(4<1OPG5jgY2`^6e1;{;EIn;vu`Zmx z!E2(+6l!lcLr9Oz={w2uMl*h{{uX0JuFS0{gL9+zZN3y@(Ke_EU z^)hG1KW{2fH2!_h_5Je-XQ17L-#;&vtK!Z7<0W%S5@-^0MXnt{y#d20LN?9^D3?|m z2Paw{NV@!h!cx!y-15I&z25{e1;9JMMQA-g27)_#DK)U5dm-cful~Ekhjd`<&*s&y zHUJX07zH?89xLjKcMAHEyouWZfTtHBcqj~v*Ev`qDok~se`LUYMx^wi)llsH|I(?fkNv-1lHT;pk!}*H^nNu@{D7%G(RNDKy~Y=o=}l<|EG0e{ zAUfuoB`<0kwX!7#LfOfn$%QdBe9j9Lx0%H%`F)?5)JrlFOa02F|E=4QpaIZzvbY!G z5;1zMUMDg@^%*Gg7W<%vg=5JOh~rR(LXQU%g`!LP*~e+W>Y9fA^09fE_-v0uZW7V@8blBf{!;x ze}Zmxpu4-s7BF+}fvDfDS0q9Eq*@8ElLmpM}KeHWUWD0nyv|X%` zTv)!g79RV&XjjWa%F&vp^bAf8A<8@X+8sGf#5QaHx0eW2k}YluICB zQ)u$JIK({Jo>X!MNvZID)^%}q91Yl9gy3%~aw@BS0$cm_;UDl2Z2JB;C(dB#j(EP^ z|BiW~t`N3duHu!&^yC_N&x7`8vHURLR7@$Cg*kvBvhzRPnXU$UxhBAIpG`|C|_DX(0ExHY6%1(U52>wSSgz+H;c`GwCraY*%5Skh^ zFLrlasamLL2!<+`FTm-WLn+ZzHm~;2v3oIqTxYdXA%lCD3{>OQ=S-?YvR}q@0-2t0 zViY+Oa~3?jh_T$#dHAUc*x`zV+vXDwc$dJXz30Oz`Q{=J%)O-@KzGI3elnqZ1youZ zKUDiKS3k9+Tice1$T5Mr@`Nqx*%A>5!Tl(DzU%gcryUsCgVdEM{KtlR7^J)oBIW~` z7f0ar0Q(M;9H?2pzoec@5y*T5?jWnIw6BgTCJ_j@So;cqjZ6cp3BBL-1Ja-sJ==`@lpb#4Agd>-jHMl51QUC28c}!vT)J*Ln_&Z9rcmRm{(_I-?K&slc+^gl3%J1z z(2(4L9Vm~Sa}1kRJAScK?IwF4sev7g4u5}(rV068?tz(neD$G6nR_z{Oivh4$M~?4 zMwS+13Mx?3qJbcJ>wY#50p4-o>m28*(42RlPDO?o?q5!TcW>ax(LyCdg+k6;JkEmQ zm?C7^`}3;z>3h@?5eKFxWMsYobTDi?xx3xJ3ql0XF#q$VAdx`ustASdSc5n(>`>uHLN=j7(O@(lH2Itwihl|4LFxTl4TKTS>jP2} zuHc)?G)DZ2k=uX}X}Q_lE6f{})0HLMTq+EkECt9x>kU9W1Qlt{5d7!6RRe*_S?m6F z36>*p*+IsQ2Zhl!nk6FdK+ctodhZp>j|w(#xW#g`pnn?3_UGb2)V$bAb^|ZyFhFJ1 zYj^=XlZ&k7!d!piSxd^H(qPq1020aonCqiO1jYDsp4LwEQ+<(?K)ZIPwpYEnJL0&* z>1l7Lq7uL6HSnL@kJd*6bDb~`=hjL$_wpQWj{@Iv>B_rVsgkaCr~nmJvhNMm=ysxE zASh{4n|JGGHQaY+P72Q7gF0zHUn1hE9b2(MYZK6EOU%?-(}QW{7(MrSSJ|x%An2wB z9tV4=RVDI%vSL?VAB@=4t_)=9+BGpQ7|VdM#MS$$X`ttRU9kWrgk_mD${2t@%l-AU zhdS@g@i7{wl>}fPyWi_Q37++F9ESEKXwz?wh1zCr`6%v zqJO)RLZvoBYQbX}%M-{NeA2}?^nvFtvG5c7gO1H<(f6!(^=Inp=P>dFaJjJd&U}T)&us-^5B4mK>m_r$AlDgMk zgJa*p6R0FR`@GI?xld1?Y@Uv4YpMcvc@(OVN=Ts>oYd|%J1f2~e6}j~&&b)7+8L$2 zt5X6sv~->{dL3?A?pf0I2(L+gFx}XgXwwS7U@+3)3fa^x(W}{5re6Rm+WX+3{g|tn zF^9m_IZEXwT~O7}4=k?_n$Fe>hXGXt7eYeK^J(Kp%rC32 z(}2=dh^hd}UxFt|+uMkDj{?>ed?gK{4MQqTxc268<5pLixPrSqZ zijRGD;p*}{4?q-qYxx;xLeyAk;1xW%)r;8glUPWqNffqvA?COeo~xcZhFD|ziSUCF9)Rhn!jIkZ@*)+L;uMCEj6ooUBuYe(HTXr z1};ILz(Fu^9n^+N)VCsNj{$4n6zJPm>)2h^M-A4fo@7=4T2n80_??VOJBc5m#nc{I z{;O?XEb#{Mncy%adYnuB4JRv47R>v+4^WI3dVUzIrYE&Cc6d5gqECO!LG|hz;Cui! z&!ed-8!KeS^THRjXgCe4I0Yr;-OY6omvtSFr3lU$;=?W`Kb5uNJkmn&20(_le4R)>q|`o-_v(F33Zr(lks1&-M&0oj@kRo^&?3d zr+4CqX;1uk-!lo(f{!(}Bu6H;CS=TX=nOGgFMs@T!8wo_kqkW^o;y3*;sP0v;8YV} zkdODxd+jugHz#jM{xg+Xl{lO{9k{%67Q*p@OsLg0^5Z?~Oydle)zUf-zrVjJDW1Db zjnI~*NqJRC?scFZwq#OpVpqdK!OMZ7KU3h$}vW6D!pM)t4;Te+=uA(vt2int5sxBV~5xdcHND9@KYyJNEZQb|$IQ zT_7hi@QI+v(+BUE1hKe5Pabsv4oeoeUR9D*B?^e$f5?K}?FQI>Ck7-Gb2AY^rVMvB z4zR>?A1u}{?&7k7x4XteB1Z6r{^S8-Ia1he)%C2~ys%xnK1nnYN*YBP`>gnl@N&^J zd-jO<1tgfj4#cP|*4kr)hT^AhsjiYg!`Ol-f(1i!o`{n*Eljj^Q@Al))Bx45(#K3>~a#kAY*4`n+{zxT`&}gQVD}&sQRr!|l1Zv+z+X z;Hrx0N|p+^ZGgUd++*eF>dErcA^Efpl(wy;>5b)x8mpXe-=)NKo7{#!}V zq+@0l2(v|elO>Dod4q?1iA6+M1F*5L>SrqFz_B9BgI@DJThp@a@>5&{mTsf>>8;8k zkxZqA+(mwZ%%HPUY7G#pN?WZfc}e`RA6pZIp0<(6STokQ7!~zA!=h4@`xQ6n~^QLQ2aPd&lqt8{uOdM$DtMAOcbW zr{rraHERe)3WNfkEdgt6i~ZeQ(ia9+eHGx>~G_J1TeFtUB?mYxM@ z^)+e7&0MbKN6tPhZ`o8OVpYtRBt|pKUDm`paqJ)rws9e5HV@mCLvlYI$GsZp_>{~G(F_|t3%tFz!MLA+x zN!32s!QO+-5O9S?c##}%i)?IEEBy<&A6yY`1UG|g`x7y@47E9|Zt;Z77w<>q;6Y{q zhl+qs5*$_w7{G?%F0n+Kb;j%mvjuBEX2N2D%Nt>Fk}^AtOG5=r@NT(R*vwxnV79q=KyZ z*`Ox~T;$*1)_4#t>4Hs-$nl>AK2?!H(a>f>6Ff6}c84h$pyJ!sPdTBNX0Y<02f~wkVeGI>~EJN@9eoTf08C&Y-Y)i5(=W7BFqkxA_m#*ltAAh{qCE@9(PUu_sfr}> zN!}k@TosdlsU?@Z(`Q(6_{SGxhi=-az1L}dXvDMEw;PE?erM|K4A#ed56$1-f96}g z`Hp{Emay37j1ks~B%q2Y!YXvthno;|s)VUSoc)Pdt6ykxT5}vo{u99ETS_L7wFw@c zO56DcfSi;aoW>X|_DZ944{fZU4$GYk&u$j_+AycU>S`Qu`wj5R!sFVYVS5|^BEf56 z_uYkqda=VQAd-f^*l2&94;yTeGcT*GsBWx53uaR(YU`2M0{ay$bvI zYfaWa|H%C#pyqdpze7|ZY7t|K@2puuI>mEPAv0AznSr9Hv9({Rtw<}0F^By530N0ZY1t6s zb7H|FhehKq9hL@_r-~*{xLz+{*G4Avi}Ti%{GP2}l19E`C08W&=MiEn4~fFo&t`KS z!Im94G@o0gU}@vg+tDyLe@|)iX4geYnT9$J_`*40s9}9)0{I56JbW5RSN}iqp-%Ov z@X#MeIZdutbtTVoe9)n{DiwqVl(e_tt2^nd4I}9#^ie=*G&K{*>qO_@F5MhO!LtTZ zjs0Ywv50N#&KH85)}Ef}N$BPWyi7$8RrPUEX_;o)%xhr}EfyYPGHo)XeNcc;aLya% z_d}cTPt%#w<1O(R){bFuRQR(@z=Sndj-*)}d2FMZNs*DGaP|hI?ERh$a85XMyyGyp z&LM4f#UFy@vF}P6SSW~wI)6(D56M459=~FfNaKWiv9i<$bR~B>m|xzyk0@Cat||dq z(Z|Qzv&-33=^|_kQBraEV@@z2VivIb9DvY-B77<{+vwkq9l`#{Dr6J-=WV>TJzFbb zfY0qTp7TJtF=Vpl^YIh`ENMi_pVNBnXUzLk-krVAQP3lChuwAGu0by~kF`R?heRtE z&BwHNMbe`P21D)$XUj(>i(VCVlxqB{`)L@N@eSfHmwW5vZ821X3;$IwzytgiI+dJ} z8jYNT*uyFVxQ#T_u5vP<8hVV&UnJ5qirIDd-XvPPLzkxi?Qjo@F#c4r0^k-bZCx%#FZ=5&I6i(&0HuhlPuol@*AvO;1wvCfyOkg$ z9sWup$V7GJV>f;+zlPQy_Z&?feBH@@LKTPH7`+&_-{Q2LW*he6qlm_d^h%Lz#3ri} zJ8^!}Pw74e5~18e?AnPyVU;=m=vnbJXK|4`=_K5Vx!0Q|Rudl_upePb-}l`V z2s7(5Jiw`a&82t;s$SN_IcRKaOnrbq>{G^sWsH_NmdK$Ji5gbYnQ7o|=20w>?Dvu# zoEj1C5C+d^AMgbe!hyj*;dgs&(m}`UYj)wPfU6~ViZZgruIUrrewQA%-M#;)Aw8Y* zpv~6XjZYa#u4^6~y@NAWi|syy?A(SkPlA0KcZUifqC8?wG9ND zQUEZdvJ^+~p!PMwKTP~OL5)(*%_V${q3C_w!JT8%@24{o6N75mc z%-56lpTM=WRhE~E#Zl$?M;JD{4XLyo1w#j;N&b)WwRh~iRaIF%mkNA@%BiAhUNy$5oe0D$PiM>nV-0$ zyI+tF3%gmgLxOP6;WB?_PHyrtY=ObF?vyP-OM^|;&iRwb)`rL!u>f2WBYRRC>{kbA z^6ikWFX2!P?$no9@9#7xHr7eJ>?j$>;ZUh)Z!FqrVMHBpubWE|X$aV3>r6X2BhmC? zE+9$@Yq;0Uts!7{sy`4SPv+kn9kxM>8+V`Ce*jx4Gks}>sDEnct1&+Z(sk;t);l!s z!dl^F62+14>gR{DnSX-NWL-0}aIXeEO}#%+i5uWB8Y27B0R#PFfk9k=XYD%i2_F3E=paOPTxuI z9|u>oasBWm|Cu z9rT`BKHp*lttW1=WbJ#01F3)MtoY;zO+jiPTUt`UDq#M{{#N?;-PsVAWki{Ip} zL3IUNEuS4$TJUPrR;pEo&rd^dlOv^=lhuYosfMAELpmWj-UFAHgLh^lCTgfEu}Wur z+}wwW&YyCM92}&zp(lvwapV-6y_3U$Xd;=&Gv)!T{sy%CVN+@TT{im;gdM~FJ;*cR zKLDlN4S#i)MoD`-u!|~dh62F&Rq03il=eBGE~7#6U+5!XP-rYU?|131XPzni=`Pep zKU0y*&9x7=~CI=Qls z{i8QpGFaGOX4kG;{^Hf8MR(axe0^Bsgr;&`S-Qw<|J07@t(w{_5q|gk4yZP%>Qx|p z+Kw8nY5TV=Hs7xn*bm;VD=71#t25(=iaas0S_1f1N?P4ST$EGr#GgK@Dwi+#>>>0>+oySg_qU+lIE?^D5w{v z8yd9vzN-^=)4TJ<#wHSDwYYiLRnuvE8>7bXZ?akJrBA`gA*e9re#<}pj?;28o4b>W zUb)2VssW#{7*KOYy05B+qJozsWk>%kR-nsEeMEGhI6XwK+kYX^m3DfS{o^kG8P1F5 zo0P84bwuR%TQZt=$ECqYBQ))!X3}ZR3iTZTD;Z~ol`R;R2T^B~)ls7ObssH{I>K`I zr475bHV#oiZ`06)CvRdJe6KD}9Zz>J3q15T_%*72niXxP zbh=^`H~hCjeootc_>+%wVtdl%qn+KxqBnb0xfzM;OZsXF&E9FxwDJ2uKPcRw{C{Ka z%+H8VaKw=rZwE3KV~0RqN@BjckmRI3I_a@h3-DcGcfzk`;09}Fq?>l$eA zqP;1gOn*n6;kT<|-qpQC)i3DXhGwnYiUO&=p`b{W_*W?u*J2;T+}WN;nv)_HJ_@mT zL63@BZ1+4<)>l+liiTUBwWpdx->q!kI_qgktq<`9_7+ccvBIUSbB{zOI4MQhnq;pnO6hssvYFZ;x1d5+{qX zk_*$o;(%AFmZ2$tcnnT|fHrze97lUD;fimd+NQwf6?%)W?X?VikEqXqgM0{A7r@+> zP`118SL$P=jo4NRkK_pteja`QFBGH)xz@gjBESb}XHqkY%d5XDFOR`TLD1hM#=qgYQE!G?fQM+rn^Ebn@c#qtm z=6}7JSwDHdbC zKnX^RK`98Gm++Pb`3T_0z}tzQ5P1hKjoWOW>EP|)k4*`6Zl^WXgBL;k7c)mR*YT`X z{>f7eyZ`?3&`RT7*D0>)pfP}JSFsdz-It#*Eq(lyX~lfd@yvWPSO48W`Yb%fQhVF~ zG1NUbBQmCJ>6R8^cj(GCP1zb3FNZQEw$?O90?{DL)MRpF@Yc=%Bf%hcmc^0pvi1GV z0EA0gkCQp^5tpwkhRN>0cbU%J%vRz3Dr+VXc0*6S(8sE{uZB4IXdul-h&&HEP1 z4k8p@pC*5!af&(pC?#f*fDRLUhauY~`ebCj$~i#2H8rXVT~Z{RT77LgXE#$lq&SBp z3=tOwJQs&u&MK^X?giM@MxxM%>fbcd2LSUY8BKJu#K`K6#lwuYzE0^!1Y%+!kF60aCX zD4~#qshWIXfZfTDjpcqGQvrc2RFeO}{(i4M1mEc7A}`S(9zYz)O}NkM^SVwulULL| z0Vva_Yefvz0KS3!hj6W)X@hL+(WthdgdjmxLx(;4OjQY8e0kL}j zD-Ak6P&3tT>&s`76n#yvqiB!~&(;{c057?B`d;SB&xr1M%-%n89~ zU>=%+7H{oPIhPXc<8i{gvI)m2jGIFh3CadIGrZqAFK@{l!qO^^v1JvRR3zR;gLrL$ zkX`Vldm9-|W=_6G8y#G;qd*4AxBH&KlR2PfLyzfg2JSlhZ55VboW4>NVR%aofo(x* zvEF_j z+W+yT<{SSOL`Rd>)wy^m)xA$mS0*2&U-KU>OtkyOa9%i--m>H896L%1kp zW`*Ci@BY#3>>GHeVs69%EvwemXyUIUL>}T$5#K%~fboj$abQrC$rjYvUOwV2mVib> zn*H)ca^*dsHryw^#L_}O!J07m*w%N^V)+Xy$V|Ml>&J_@H5_-pNARu4-L;_le&uOF zO0zdZ^FJN%6LD;r4^Sm3DzWtT7Y{)bcbh}q-&nO@RM}%sOlPERq^ksd{Go9k8JkWB z(=H+nmj#%3|FRylz+WQgqy*Qfn0>LzOx#cVJ{|B?F}6nojTZk_nQ-wL>~x6xghAc< zKkI^@X8)@+ns@2uMMM_7b+y4SZ4rkfA4sEZ5K!&{zSrfZ{A&-~<~;Hj`u4x3|LR4U zD9X4y+05@s$aS@nlcWZ)!Jo)Rh>mmXODyXnknorxYb4ii>#6u8Pd5x~=&400+_`Ua65>URm{eH6ynHd zRAi#50Nz1Ps8kPG3c@L>vHDmXh$K$-=%dl-ds!4XHi}_)*g0Vn7QuBM6!T`##=vMF zX!y*co_6>IR+XZ&KPyRxs~`?ZUDd;3YSkzwQ9Bh*++m<_dp&8Y zCg)R?SmS;0fO;e3!tQZSO?X79dx#Vy3W>sfn`6+(ds^OWpSNYZPKW)k;@;31rYWBJ zTN;fwVi_A?`B`+3;AlDp>|n3nU6%7J$!h{%tlnvAhQW0ecxi;(h8 zY(f&{^g|kid+r4mF5-1brh+HE29XBwno%?4J|{v7;UMDE^9I5ht%9{1j2litI@5AF^@o>F|#TnK5*-q^^>{avPRM?M;$6Fin;fyd(uZs z7ykHQUg)#={M}jgAwN zt|XkHNr=M09?6pV-`W}s{7I?NfGyfgAra3Q+z>GqcLix*9DFOd&Y=!@n5+O~nx%tn zD5kmUgc5>LtuP8mk<*6l9PByso}4(X|0Z{1AoN(^m%~+rDLZJ(fc3727&&l8JEl70gB;o0$yUHbjz;Csvk0g_hD1Wxg3`&dMrm|fcY zHWP8wM5A)o9vT3mvP~H4tiYSlo!%F8!lf6>kt z+OO-|_b~2-pKe&2p&;GKGUnXMd$8~mXD$$0m$jIQEqVv;3HL_ZY9j=jiAmxda&HP^ zNXpa)1fLfAYSQ=R=}4i1eqEEzW#u8FKY*DRa{6CvYp_$~a^Q%nE<$ls*uESuNnp9d}qc!wZbc&FE(to;sd(HTWR1yNx$i9^U*45S;&Nsq_ktc*@? zkA*fW8f}^*dJ(xA#Q`vpFIbAmV{+Q|^rHN1BZ(_Ed4i*- zV!!V;9z(YJ#BmUrG@nQnb6dqui3TTM)zc5Rcwo zup=gXheaEku(Zc_2n>W^HLPdLy)OxQN2}_$IV_Tv_;^K|JgE$tR}I+vTH3)|pk36DWfWgA=m&p^ zv>^8Bc-`7!%7A_8;u~F|cI~j@Q0)+?H~wJP4FG19mv`~Q%dotOD1}x$D}P$O3Vd#8 zrM*cpkJ3RDq+3UuA&y2Dk!q2X9!xfigLNYv&$azf^y5|B-eTIj)uGaSe)W@Oy(9Ii z7A5QlVoniaA5C_?7jHBuLX)qzS9uP1FD3_G#hA;r6ZvhQEu)V5?8e1sXFu|I8&)eV zETxi+s^95$fsgL=yTRh*4Z5*n8}HyV7>@4k`~;Z5%XyUoee|>3S8uv#`H4?}%j>;J z^fde5x@8~tbIH)9xU8|F~0|h%ypD=#O~Y0Jlz3_)HmIy z=Rf|_`6Nf1m4?#jmxSw_$;Mhc6>uwfkbmq^2&UuLJQ)>TARf;`XB^P^nIq6JtqEz7x_(4?l=ahg5_jK7H9Y0v-(3+xb4w0aLX_ka;Fm z7$USE0Wp}UkD>^mM#9a0JxjZ)72!nOy4~6Up5A!ba{M{A8<d$dSk=)@}_7C zja+#;1;~%~a|r<~tdj7mo>Lwy*fF*g-0Zi91RUA3Q#lVD0R@5A^h$Z@*z$K-l>iN3 zO@tk=3)~O&+!m+Ftnwb}m__Ak_=sH)+`A3ziQK1nP9pO%DZE977z=RzyB)<^KNKI~ zWC5!7<-nEQ$%13|9|%FzfG5v8Pysh<=mQ1yel!UccP!v}(b6mldC?Co3TE@dWz}+5 zfhW8O;Tu4B(fXFrM9FKQH*q8ZEQQUi>=yuQL&Fg`&PD@RbC5+Vq8Qfpu4eFWSnq#_)P z-hA371H$$46(GmB;Iii?VvClb@5DK}f)Kwt=#AKhDPR)`_+Eg(p(NxUIbVmz zJqB@SKBjAsMRU;QW+ntCu=b@w#Rffc)EoFjRZmEN^n7{;3`7JA12q;Z$G+$U_}{eO zfhDtL$AQic$q+SAZ0d85_=d%ln|ufy`2j11%MGyIZV;Ut&Q3zr5inBk0U^42W!QgN zXzG$Nh?@>ib5{b7RZ>krm^1~hCh=lUW)xz8=<|c!u+dw`-0bU-SCvGGul-90PlvB6EE`DM5|k%0G;e(XJ(r zwvSc|kJWSJLhrb$gndh13xvDK4~OVHz7z6ESLbn!jyMo#{OS9o#qJh8<1*ujT+y&q zRZqFf*!e9uR=?GNp7lCPpY$52kj{`6_L_5Ru)0h?-1cocl-%(6S|=zyZC#=6!XMEu z*a1lb?!(Pv4dFy-kM;36oF7oydL^;Mdg497bpGSrR7==xAHAec}*3}-`aEf5X6 z9?!b<0%w^y&T5nkPg0_d~^Nm9)N_@_k|P%w2bPLR|>Q|rj=H@8H()xGn6u^78oC1IR*HQNz3udl+R%1gu}o`$TXuF zB$pBVyr63$-3UU1GkNoko0V2?`hN#&wp z9d6nx+xz=lv#Q$noWbpj1l6U)dqaA^b9KgsjTgzj8;5zvjMHBm4jB1gR842eeM1xS zW)ECnp=~Ukn_J4C7r${hCSSX{=Jrxu)l7Y$PjKt=hUb++=YZE-Ubs*eg=l?2ZA-Am z_t>AlqyZ1)!NXBv+rS{Yn#oku~a8i!}k@P$egC{#kOwE#=6?Ot(1(vwU+o< zlAJBke$%CL8Zt)a9+;@l<%d<%9SyI7j@hmVswAG3R6C_?HXb)Rb`7en#OA~#E<0(8 zf^pW~uLI-!o%u7GG~l}&7}}o&Tg{ts_9-)Sg`g@P#r(!x&8E3{>Px(NlQG**6!}PS zJ8>E?qcW~@=3!zv$5;i=^P`Kd&eUqWR$v~!S8%ZlyW*8VW6|Fk^xJDHm&w%7PlR2w z3-v-TXQdQUepzpAU$2i`_cYnkJm3Yk$~EYN_=+=9o@I|k&_3hJt!AU=T^_5+cGGrj z#tT2LG{Rdh%N{GJvh5wJVvU5x{Hu(a(-ncq;%Cdl&krv}4SO(ZwY`*X8g6gbIzmDm zM;__V?hG(_2CbxzXg?OQ{nW$8lh_t5p~^_-m*ai5=(T-D#rgBgG{JFPKDsZKBkWgf z;q_rS*MYFf(nFM!^9m7XuZMzCclx>LXHZR~&G0>FtZ+1Z;CC}HXL;gQoQFe?dEipZbQ`BJMQAw%+yOh^i#mmMX3zhk)OQBS?jsNC@_>#OsNufLkP zUGuk$^IdmxF@9M9;qt!bi*BEs5{E_e%8wehEFS2?FV_-xUz$Cse%*M!{!t*Ex`b(X zZB$_Ky`lGB*@3M~u-^U;<=kzN>26B%wAJ?hFgu;MC z(4gY5ekn_8;#2v4CI)~$h8{usl2iy*_}1Jdc#-qQ789@#PHZW}TB zU0?SLD(x=4=oJT=l=lAgl_g;^|39E4@iVrBZAH5ZZE zti+JpP}qBsr7N-Wf4@k#k$qjg^YI*EOn=iKedKV4y%9Z@8qg227prwir_hknwBT6& zkp7Tu@Ty|-9h$$!X{eA#r+E7FxY!R;o44LZ(`=IT!7){y5LfA;ul zu3A{BQ+~Fg>QvC!FKa8fE~nvKXhV;N%FSJ}wW;i~TWJ@uYC=zUe@K`vwjGOOw@gy2 z^KN-P?*8uj4qfFq64{j|YSObA_BWmWNBsSP`sbeaWa0-~3P&%igG^T{abBPA4+w0R z&uw$}LnW>|-syWCu00a4{@peVS`Q#&Ybt%z5;2)w!Z|C8L^&%_=84q~VUsCn&GF6fZyV#1;-Amnrw$hAR9BoCSA7|7 zujgZ95)1blV?QPI987LtPz|!gk9zyBA#F$+(fBUzTJTte~zf z+SHt0cfH8#fglFttLZJ%iKuhpj^ zu9>&u5LVQzbl9#j)UL^LqxLwS=k1;ysDB79mUOk)Oq=E;;2#72!?QMYC&~3|&+GF1 zj93t9FeDa7DG_fPa5C^Dq~x?9r5!{6=6@E>5M)R<#qRYtbW1hHet=dwQyj?kLdDxBVu4;LEq=sK{2c z^OL2Rlc0|Ij$ znbemSo$THxn62@5zZ#A|?=)WYr9FG_BUw3LGC2Osi$YvAWJFvL?>l3FDM{MW(%Zy$ z&V}rcSaqc2C;0<2{N~_ywJOZiCw40A?Kl7_rp)*E7v&cxAveOH$V!-ef0DT!IfgNj`b6JP* zmAloS@04y#W!o8`!`n^&14jT9bDAS1p9iq<9D4vp(*(cw3qssWaSCucLJa<+39%G)mL3-*>i^8QvAon;4f=7(E*_4}xVAgH(sPu->fP;u3=68#Jv~D0)N5YLZYT^>(o!qKfg3k?GeAPiP^mXPP**+7)g+UJC5tS_1v_m z%kbWdfO~D0m0M2=O!^$pCXjlBob5L`J+NW`+a|VWbCnP5T%sVY;Szqw6rp>CKFU>J z9@r5*4LEZpXDKAD)^7Tyv)j()Jm-OCK$BMk3B9|Ev4mKyXuP)Fsy};adEtqzzm$%8e zm1ODYxanHow(-;q?GRWLNhka}$_M1^+h~xk&gq|nKP5Iy+|mI0cC3K4{Bm}<(F=Ny zEY@>fgN^hT>4b{gD5*pBhw;l|Ww7TsfHE3yE8ah5UYRJ~nW?Eb zmr8oeB>5`Qz_Xz8{h!~)0nIo;BN`ILeeRQ6%18&MbT;emLqbOP%qK~FEkuRjx2NLl z#z>Y(yoRW&9c4@gLlbv_4{B_Ez2r?Nr#t|T>;a*QL~7|O4C$-T?gPfP2U?1BgXiUO z7lJJov8DU`dH%BI-xBu6v3a0W`$Z#@J@|`cnSF(9dIt2|L)CSO-(Uh2r0MBk&VK{9 zFW%*@7`Kh!L7p+;>#wt5f1s9CwZ4OnSAQn4&I3iAZrn+M1WM=ZU~O4i=JH@gNgpgU&-BN70mW=ARUdS1}fz+s1UBlu_k#CG*E^q9xu zW3Wl3OS9)f+M`&-GlR?lAgK_GwD>jWS?IhoH|sONd~&Lh#ZTqC%3x%(?uIhF+DjaE zX_ts1OmK^HgQsH7+vz&KNO>OE`!KIAkxv33Vn?R@{W<$h`tQk>|C!kBg-oCP_=EBK z+|g0V%MGa(!LL9#*by6EN*Yfn7M2V5-ffA#_tRpiHO?My5HLu1yWmcdY-o3RW`0;Z zTQowRrxwGiY{X*h?zMYQwib9kaD(QQ4l8*#7AXp+00(5769tU}$9I5Qn88Epe6wQK z1?Jbyp5+9=304ONHl~ZMA;a|^PGXC}6f+ZG%b{Jrv8cm(fdHglXcQ9vjpaQM-?=H$ z|7+zD$qpzj12#EB9wp44!B>%Rv0-wRyK#Ml0v+`d&X@)H3mU`9(Bn=&DC;f97+AoJ z{1_3hJkW}7*X*^D@FE1FCggP%ECXSz#BOt^F+~M1&UjQzqtt-j!wZVK@yinhV7Kb8b)H~D7f+&c$rO)#r6kJ zS#vLTMLQ#BVQ~&*VlBRD?RjMg*OdF3C#$hRvsr*ZFCME75Sho=kBiRUZQI(nL zg#$a_%`vD!9XJJNjYFCV6#UX5g(?H+HzIJ>e!|7D>UL?#mmM}9Sym66cVDpNmJ06B z?lhEe;aLm8bBb|A2(o>6OQT^S7g2nQNxO`Kc4LI8ghGA|%x8xZVQ%t2mM>cfyg6Bl zUi~P#kuTRq-9A&|+be;^Q^&mQ3)Yyp7Tc^1CI|OEpL4{Fg*+$u=qBUMbuM|A^bXDMK&I% z8^Rb0aO-i8=SM&u6V75=wrz4uA0L$;a6Z`)#;1U?tNBZ1Iq4{<0}%|TT1jItM9q{I zehd#RWhrIO^yDDO$}u;cC=TtD+V2xYS!HD?oK!QuRWwmf7E?%P*1hs>R_U=8nkHxc zD-$Lr8_1G(5uN4+;Z7F}mv9Q%RY-54WZ6BMwv$*|&0x|B{9VnOHtmm;Z=bHTTvoZO zF6A1|yDR^cWsin15Qg0n{VSSU?yG@t`j4zAi1FE9&w4u{$OXXt*3O2{gR<;kFT15$ z@$ImzNEch*EJ>#?ijIYUkQ$?!<8fVO`6YB1>yN)ob`;i-6UAh_8beVRBsE}CtPo2H z+^UXm3q&QE`S`OSn6+TL3V(`5|Az|zdWzcP;5nc?L`qwD!evU7b;xgrx|@|;F#aGn z&2Tv1k390;?2sh?D(6+I@y{Pq`k)n2}biL)-g-rTWesg9xOQOukA|^5W23 zo-^W_?e)tzu=v^qT>p#v{bqg|cg%|!$}*9k*u@l)aXIfkv7kwcj^ukNl{pYCgoif} zcAM09O#e7jYAq(s7^1~z8f9fN+oi!**Sq;%!Jhd~>RpT0%%KGWB;&Qgk}&XKD3%|5_!-EdfSNYb?m?%yFZ8F zKXCqJzph6f89aZ24r3mHWG%FKv_p=Jp$j+>iq*r+MKJGrr3)0bzc>^xd?^si*taEA z6es@s#O@PGmhd6w)vJbD+uhnlT3jnS17bzX-Pdyb%H2$hAAA)~n3-R3wp{HBJ))Ok zRYI$}GcYPk%DP*R&b>Eh2;+6$<>6<6+&9tBR-O1|AOxd1brSR!XA3I4^LLD8#;+{BydWJBxxu<7N= ztr!7%&c2@Ow5!w|t}AAa=Q{g(W02I_*8a=}$!f18FT~7{gKL9JvgdxnZLp-voxgi+ zN&9Wjjr&V$@)qs6TN9S_Llv}uzgMAw(w(uam-{lagv@CI+l zzG9h!-0gOFidhg2n6ZRVN-S;aIPtaz?ZV}sW)lUxIvygEXoUF)G|9bq{P?k61}M+C z)J;XwzU@Q_W;w>{9X=?l>!+pb=Dz$^I%qG}o$()uP`7MA>dTW4JJ0cOhS>zaAzuw4oeWWaO4zm= zC{O4R!Wk*}CY)=N2pat1(K?y2e^R)R?`qJXF|z1&yRehOldCN|KPU5e7+eS?R>tF< z6~t_uW?upsV9TW$>VHku`PG0^k}DimFNHLJ%Rp|{mC{)uckeT=^Q-fr^nto?*(f2V zc0Q3I7qxF}=>w(^hC^sa1vI;1zQ}m&j`{mt+o9cNX1GTT?Jrb7g=qc!1Lun!xTKVO z2JGwl&n(_Uj6KhHPolH{?H-kc&o*s@KhmFCU9YNDI6AWKwM}flwyG1Vc%7}t)&JGF zO%)f<`eBD%up&R(#+%vsijvR7NcRxvzilLwKm7cD9*dbfH6$#+^o)@Kf?%hMAFp+> z;^bhS@eHTe>JM;}R)FEtzr8o*v*}%-FtE*w_MNaXKSny?#J-WFMdk$@uzY3Kh*jQR zoOd^X5VBPg#SbJisgN7sc0X7llmBS{);w8kV_SOZ1B_cf7P7o_i)@Y%+U8^=e$Uz2 z7l|H>mGCQp#%g%fZwbrE*2ZVuIy40X*J_9*gJTUP?T~S;f{N7?8$w!s!9pzTY*BuI>A}sw z*#mW_GQgs%UbMuPz!ULtlA5C@)o*iZ_TDWj`$B_@&IE~p_SgWU*XE-AGUFJHJZ%}4 zK{#tW_eRX1aPTLT;M9H%$CP&xZtE8`t0HiO+V1Rn)0L_?CLpgKbm(wVWW}!f^hfs2 z&=6^$`xv%7`_y?<7d|hCNuJ#pj}w}knUPmoxw?GLBk|v+0QDuxxbGmw?K2*&`yfmN z;xs11s66&nCb8%k(|+xzp)?zZ@r$JuR;9Q8OAPjFG zp9l8IcP51~)vgZ2G$QPB2n$?FHn){Mqlp=UgVKlOCj8UV{|-tscZ5G||1b}egWxH~ zigfnVG~*3Wp`Bq0LjA!?GICit%L_$8(bPyWXR@m)p*or{G`U3VV>(qfgnu+Oz9wBY zfmNBsz1vnH`~r41;kO}$^Eyv39@G$trPn(q(vT+rRJn2nYI5_UMtw+HTS5UNfxUvY zBX3mAp0)jptRUrl;1Q5#700J3X$lc-=Wo~LR}OcSX=mb>TfRkv2JC)hTVVHwWR6q@ zDWRmHoEINcFz+Qx{3xS)p}QTzDuj?X-mU9LPLP}WxY6#+OLlmf69~L(WoeYo42))% zY>bOXN*Ok&u)|-*9uAyG*sn0KjrL!oShUkZD+_)_hz(DSE|4M4ot|Yaht+(3ZB6dm z{cZ5)9!J7rljea;_pOX7Qkfpeg!p5D%sErcPwsnMw-TqFgmGx?z*&;rlR| zBjRb^V<#q3vNuUrZ=+!(q1+h&S38I7_ z=^75DGg(O=XsYPvy1>SchDy{-8QMLYJi3yaGCJuZcgF&s!4enTqU{JJWe+IzC@7OF zh|)e}CeC<8>9A7|tWW7a4u9c-KeB2A3YM~u=bChg(-7#y!$gV?ZMM!2AZBAh<`hDB z!!S^1w6wTGAJ6g>8&6BV@&O-X-5=OD4M^_FrC^qJ+Lze=KcG$-e^Y`q&9?NR#d#hh z3;y&U&0eLa_>iPTG2cP$y{qKGhD`W4ZhqT3CH|Uu#N1OP z{;_=X*t5IX`lO5|R`-3`^6>;I#Q)K=>Tk=^fP6#?*be(J|9o%bDJ# zrhzq)MsG#L@u)fBdAH@cH$2wgg#+QLVcUg=!?y(QXq`L?IaosCT zX`+y?(4eF^LNtB2Nx-Vm!tY^a8w4|7ZO2i z2@fyEWL1kv-a@#-xu-6#A6bjE=|G5h%hjp*b(pprr^3gVivQhxZzp-qRU)&QTHYHm zjF9mCsP*zdvAGZxeLPSc!gcjI-zd=?9$NVGTdZ%+Cguw;W2%V-nv+QaqJA8_2-8e* zjpCZ2e5H_P@6Y5H?roo7wJtAcvxcA%(LWwbIBCq8*4sJsnlPMGG3<50R*Dg7VjhCCEbql{9ch7E=7i zew6YkaCe1etM9h$QKFg%NY4r!UJT_a%$?Av7vp&IFKj3M#pQ)Y*MVdicL|Rv5$+;p z@38$@z4fS`y|c_$O}|NCoF(I|9nFPAHi$jDSQV@?uHzq2!TwiR$o3@kKX?7)lw>h1 z)pBUz`~J8Y6fw+8ueycB}u+rbJp8y5VeOvk+t(%M8=BoR2(;uEnJ-Hw% zj7f+n2pFmEZM_Y#uOss|<`I1GA^pv8#}9PDBU}K-QxR$5CV(@R3+c8+=JSzWbv$ZF zmFNqEhDHE zgf)r~+3|OUgA|C^@sBp8?R?3;@&wHN_rXEHMadvK1d9=GqX>vSUb3d^_3kG%+|)D4sHA5Zfblv!`c*R+SJZ8+!~clKrod1A{f+&YK^ z0~3bee?ideo`A42WTA=l6Pfd=s36u^xp*Ma+Dv;nVXOJH@!U+ZNFsGw%6 z&~z?Qb@t}(CkgAR2e7GLLtmZL^dC6KgRIDDh&c^+0m-P_)jxzM=B05jjyNwm*(#Ua zAH=MZ!DirqNvmeu#@9ap`bcsWmvy=zBQ$lJ{U8mhWQ2G--#Zk8!uV_qcaSJ{D|$Y6 zaX>u1%9KU+6D%cK6*=(P(3tVgziV6hVmlDd9iF%z(RJJIg1ijzx3EEREBvu35+$Tk z1zOeQtFf`MU_oBqMg=9M8*HyBOU*az;A<$I}ruqjdc*etfu49cVSvC#E9Y+y;8 za^Eq~6ZzAEFMcx(VgOkIN9B8KDQoW-5RWCs$#yU-#Y&iYjf(}x(%hVZePcKrK8^L+ zY-H;}F<5Y9TlvO5vzeUp`8Du?mJq%ir5J%Ct{rNM6%X!-$gmn%3L3Q^O=oTD@hbr| zgRd=0J<)`sYWvm+(8K62P?3&0(SAxfYBh}wrc*dqyN1fzu`_g=?j=QMl%ABl6(}2c z-Tl{US79!nI+doj!DvI4qP75Hr_G|2-w&m3z!Vtg=MX&tnlq8rcs>DuY%%u~!Vgyb zXT|+`{{fp9_mT{UeUU*5N-=dPxUw0qQ&gRg+48^r&tz-iMqPKzamBzFq6{%>}6 z*1oYDt7G>juqx5d^ST`vPBc`h5|VSI!qx$Jk~AfL^S};`${V}`f9UQsvbLA>RNl|dwq6TCqY?@^$sYI|70anz$l+TU#VJ?EAt zuTT65A*-}Q-9T@5U6Jb;mrpXF5=x}h8?el(MM(-HB<>WhP*?Ab0(Gbme47JeCGN$P z2+2!B9(9MYrqa;J%7Q!VAnYk?vGzpE_h{~p40<`_Pg(YMcpl7Kztr&Zn>q?;A;+jg zTxUR1w{z&Clpabh9I{(#o?hW4jeJo=S?E4>VW|a^bLUYzbSV9Am@ilAdP3{ZK^)(8 zf)theYV<6^kR5hT88vngNSIvtEJ)Ca2`>s`>oS6wgveYbNbzO?q*&-bW5P(CeQkRf z{5wX;5w!5eS8(>T%1<*ukoCeX>DZ9H?EhTj4@IDf`@sGvDkbHcd2^pyb|k&g-@8Bi zh**uwt20QTmKmI)f_9@L9vu*rrwAv}#CF#_jh`$4n0JEmcMFq@O&UE)|cO7PJ~P__*OpjeHewP(cKPbsogv{C6O@kh5YKPrdUEBnsnn zTtUupo9yPh40*|PM9%I7;S znkPhRqx+A+0*1N-eI~FUjDAgD(%%W&V5|o1M-F z2Clw>Q7V^^M}r*D9s-g0V?U09u0*93wvTb^o~;B)$^N9$XkayZ`BrimObG5HXGK`L z*%BHTMew8)_MpctgesH!uMngAZ&b7Hhtuw~lM3M{)Ij;}&UeJS%qSHEV)irWZK99( zL61*jhbh+^*ro}G$X6PHNg<4-I9ctVuzlWobfx2j#DsD20kut3JEwSxVhyErJaUhu zFzZMuN6w}aN4o={QCh9BiL9~F(E?e+Nb))#C_5H*mv;TH-oLb|5cil6#cQ!<9n=KO(M^-kZ=@VG5CHI?93z0;}ZaM`#0 zjoHhscUl(r^?O?nJ}=n)ef6{?DCwcy`wuUk{k|vkvb7PcIR$Kd{01S(u0HQb+QP8N zDfkPB0%z(mt~$)h9hW_XXo7gTU;?J*PE{u1_QCI-_sPx|0>jRqxn!eRq990%I*!7p z8?nFyj#MWWrT^n84>n5zdT2N%TWkA!g=P6^m6>`7p9c1zLBG5C$D&GoJQPV(N-8ZR zD&bRg5#WO;tHXE=Z&&FSa3&Xrp8IgJWH*WD+XJcPJ2j{=VHw&`h;>gQvB0QVCbeW& zz?<+bAPC)^aPE|+?8Ch!++W9^5)>3IW%Os?eSEnz#}-I^pe46ioHl!Y7@4Tp z6;cV55k(+0aJ?`-Tv9-x;;g{jjHu=WB(TA~c7V0t8=wpx^_HLCdHf9`8&v3BLR+txa-UXlkIn^v zQ(PpB%FjyIgUbtpqOC9q*NN+p;39#U^-C7fZ}r#G4J;ih>@6Cq#vg|wR_t9dQDx0k z5Zv1^X+ z-W^PPQiK`bDmwB{tpDG4w`M(^ETEkD;o;$NzP7g3s+R}V-gp(Q_xE}ptMhke;`!@9 zLeLMk%NSv_=o&Qm*#M-E=2oAbRPs&&sm&^8cd7C2k1QV#55^5RxPSiWG%08}LQgHr z*fv3(2bBNVf;wgjyjv|0&;LHw_)Y-$7`5Hk+mB@dYWV@3Tv-=#Csk@$>y+=U+rU>> zY0G4HAe{#j(ch(Cx3cT*_R&OZ*e9f3aBKsA-SvN86C~gz5agWljlKLas`Sm9#jTc> zmJ}HonSQxSV1)`c)Na`TC4c6aP?T{>*TFa#@hj6ZLtnkK4zO}bt9hMnYYSrJOsTJ%#G zx4l(gvDyGlZPp3Eizf#c>p$1xP*~haoTtyHU1>HQRP=ZU(t}*22&l-d`qosr#7OU_&ZmoiHH9g*>T~-@*e+Eo z@V+UR2)|Q+DVit`8%{CJ2+t9>gy`i*;}?xEm50>-C6h2H+f;dHkEUVV;F*_k7>29U zoWYD$*fby9@fjy$`|s0y`V@KBLL^1sKh=XLu_>wVriWHlnQXgr^Ut&AugALC)BW4jDM+Eg)xm6PTZvIuQ!p?Pj4;SD>i; z%$#0BI;iGpf1;w%xT76OQ6e#s@Im|jOYPt9iJ*->Ki?S%n!5}asVLB#|88&AjV}`- z=qP;+$^+*OH9&}Ot;P4ehLO8&mjK{%PDhjlAumW1X{TfM!&S~`ccpPRMV-anTbqYP zvy1HOP?Jif1m+(M3)XUsPxoVgUKSQ!N-$cbG?Xc({#Gk<`9(!2R1zr7{QUKc<$g!W|Q5d5tzvHwv5jvo~^1Yio(;@DyaGsuVCyP@8E-w3d-uD z=irs`^_t*+IWscj@}!>tTy;}T^)8eJh?Y(@_nrIsLCCqQ`Ob6_hZoyG2*4tFw$ms3 z_7nJ|(7}qZay*K3MsDWPyT3o()BxvwzCyXD;6#*!*ki~`*Es3`)9iD85s!3}^V!*` zR%u6P5jQ-VqGcAg*e4*Kw{LkWpDjN3vgIJ^NF$tek6Ut0A?8GW=NlLCc z{z(v70M#b+CCT1R$+ke6@22Mmexj+H*X6&1L9wVQWxHGc{I37bYQS5YFC(TL)B#RB zss0V^FnsL>rbtomFCwgc0&JP})jtHArOm2|Cod=vUG?!4s6h;r1%%&1jdO`@UpBD` z3YWMFXZ^(XN5XgsifvcBGH--!1VIBX;996n=kv%=QMlb~is9duTUFxC^nq|IsX^tVKY2!4;2)dd?)Gu7vMdvrgax|0M#6kP=p_-;Eq9tQVewXT za;*nHC=1t%D&XV2>;n)f-$5`ml^uCFbveQeJ`OqZKiO)uBf?O_|0e5lo+P{Fb;z)S zJ|w2)x`QmIw&BBuIQ24phF35roC1nCr5!BRM$Asggnt)>8(xy}SF%aGIJQ685Dp=P z6UO_AJ?|64Cn}V6n&4MI1gaof;^^H}b_@o5iWEki#cLiI#Y3x;OAJlhV>P4*`y03IC0l@DKnlrEGZPpZ>1F6D+c{uVL4A+Y3+R7NQGkD%x)C% zndfeKRY5>oIU+CXUwMD@@@L{y{x)WEpQ+NMu7^Zwt@C2hG8&g89@4W;{})|RQ+`LV zKmF`T$Ma>ynXt|R*qKMz63c}zE=}1j!BP#VJEe!Tfn=K1Tl<%V$<@6i{!cj*Ur}hR7Ev>nc zfkACZaB%P>1~0}3XlC0XGB1OtuF|!$S3gsHH7K>17EZU5{~!y3X%N~yR*g$yo@e&4 zyoy-EGS`ezIFd!Z-eiRN7$M>=wTvOlpwym9=V}2U7~Jm(mv+{wkFO)s7B!75Mip+| zksI76+B_@nGj!!XBGpZta(CoOYWyjw$3sxAk`AH9)V5*9a5^dE#$<|>c_C-lRH{UXm5D_Y@TC9a_R(*q(O*fLCVUywD zxC|31{C=2Z2AAv6qi+$nHga%qT%~_oJ!Zhm954cqfew|!Me-D*3o))8GRfe!WSj2d z1!E~3-9)w${Z&pqgeK3bO98_SA+*v0#+Q{>`5-MCmx3sGTLwODpcIT-GoW zLhaL|P+{Ks(xD{{B-Bd3ueWtUdl}q*KRP-iN`S;%<&w)|4d^)ey~O;!ng;}Pl-th1 z2Bu`NRy%hW74j*Wm50eU)e!;=O^=O@r?`cL_Ws&23C0hbTwanLp4ukGoKGp~2Ak|Q zm)VL&(>}4hH7c~4oyF{U>eXeO23>z6ZQRN~6Ls%+Xi#(l>|IY0v4 zd8c%>t7M>VXmfos!lwmVj>GdQotBBtQE_(I38eTrok_8VStzQIs8qHc6 zk3XjKXAQ@2!3{UyOrV8M&pz3}#W3O=3W*)v{Pkb)LxCQ9O3a^n38G=6!QUv zD-PB|8aU{^H4?+=g^@Dmo_dumDo@4N&q#*POiATL6TogPbF=zOENj@L*~euZc!2!q z3KP%ZtB}SD-&Dow-9UbbN6H$j{1d|GAh#X{8rhmPYVD0hYjh~_9}P=DFhy@TO9+TJ z_b_&b-E8v*;4p3{;nZR4FP?cx350VycRZE6MDuPSS{vOFug#r6#Y*^&_r2iNJNyT~ zDa)6YY(aO>jzIRu{Rn=P{cTkWNY3gMjgq6GvT`uLR~16@@F(VhDQ5Fd4@LBTqSoVX zuAbalwE&aO*9>x*`44b3KHYkGQ)-~WZ87rXuS~UxLF8ag`R5-Jr}AuoNrXLp z&L?RnK;xL-FvU5}*x&W~9(QW1X}v+^Wv`=0@A8upojHHar=&lT8~d#Y!YS?FEyRo+ zQ!!Cxb&npjDDD-pJm;Q`gPHc->%NOWB*?eqI2&gi!{G%)LDet)K_Ei8SVO(2Wxoze zSupkxq(rw6DyU_7C+y)3zH-xJ6phb795GsZVl6p8D2?M~H%E~8&rmW5H;hW$H|a;$Dl8W!A%c|+tWFIPb# zoH$NJD+@C3p`c5)Tcfa6<^N~@u@mU$5;>9T;-T&&L6>ue#Rv(OQaMQACU>^!tkoS% zISL}~s5)2sK#4Bfu+kjzWAw7|6gl-mgA9no{bK0%NQD}wVmrckZeXLiu=Pc)S2Le3 zmfH@9C@sum#niHtY>yRS6`DOHIxSCI)ww4ErGHUtVyaz@S&?#wLG3*xAuB|WDA}DJ ze31)Ws1`gJt}g$k#%&=u0sjlUH73L``?=WU!!8PH%_lA>ZpRyMQ}rliQ+Vuwu!kz{9_Pxb?p zXGfYVq>LU*4*3vtEC(e0=BOq`kD*OY`x9pVUw?*`4L7t*&Yx%MRm(+L zum$Wc7+F&bSio^Y)I(q+6^V3r$!C!05HiQ5D8ufMO~ zTxkGiSLU;gT&ZV^Q{P14dl*KKUV@UmH@xgoePIHLuWfam(m$5y0o9Ea6ihfW3XvF~ zyE|=_7N#Z*ZLUeC_0c-95^q~ki0nQ?@NJER@i@&vz>+Ex4j6LyM~JHioxKzMlQ?P? z!i5P9uYUqR&Urs9%vKrw%JCm*Cvj>eMd7!pt2w80EXRR)#H30Z!^Sk@+;4CItQ*`B zEk&dolZV73=$xD?wvNZt(op)mhrR}0M>{I`P%+$tO8XrgS&QLfVy;(zvTSF0Usg$i z80uc7IvSyPqKIR+(Q~3iewu!!e*Eum0jqPn@keN^*WYRTbpLf@X2p(EOUav@`26_x z-Z9EQUDy5563B3(i5N*LYIy6_8nDA%4NKfiV_0R{3a>;g`()NtFmw&0)e0GlFhmj4 zJWAVfH;Eb`}iYvrUju+4F9;Kp;&-*ugi5#b-6MLdXTDz2i{e^vohR{-OglDLQE9D6{yH zR(2<&M(+DA|IL9)_&+JjjjTK)Xu@l6flM5*)ycp7d?TmRdUYLex*=Qdlunw5x1P`4 zyl`Y{04(}Ht(V7ba;SXY`N+eGxS_s?&lY>Af!3S9PL0(+Q$|~!ImtBNKurGaf2n=( zHCps?Uj6r(U){5w?(E!kJHV3n`v1o*OV;RW8Wvc;6;hehDy9AE{MQ~lTk=1Rfe)Wj zFJ3l2p7GigEcMxBIX!|t9imguNSzAzFCQK9 zW&;lzJ^IVfQUferPPcaG+?ss9W8CucmDC%+&{usS9w`%A-cZ^8Ts_f2Hs#c90I^9* z+A7ecrRe&zB2ra1FY3+~+OevGr_ z^%rwON>>}*UmFVTe@7A#iMsS_a3?}U-nX5jnqXswTuN7OooD}LQ_JQIO@A0+UE;kz z@At@`qD>VrwF?xiFLK5Fv! zdNKK~e!9r>AX4;Y;Lj zjHDoHrokdIft1s711)E1nDRt6k|j5m{QlM#fJTA;-une0m->0<78+q|M`r$z^{L&V z#^~dX#kr+BT*NpTY@c7QgMc}9a7|2hvJrBJRyrc!gdgTpJGik}vN^W}YIIz~2i_!W zwQIes#e0tG(Nwb3QODl)K6wIxXgYbXs`!SGMCVJF2r|wK%-Pe?)%~K?>>;Iu%=pFq zm8V~?E)S0K(w5e91r@3ojk0JdYK**YibYZDbxBI`vXxKhhJ@I?G|+l(d%4f#Wvx7e z_69|R=Z`c`HUj64s@%Vv2FF|;wjiuw8fV`?^>A>q`&gcr&;D_`Dbz>qOx4vFizw2x^=;y z=Xks#6LZ>MH@92+Q#5CCue-adt%CPt1~~mG1zyz0w*aAF{&p!9*N0?{wVqEK9eY-8 zZL<&42(|py1kQGU4B3+AKJU#*9zKFf0KrG8`gM89+MJvoCo+GYtph`pwD>n_30eBR zCtHumN;a;)>6C5GR{rs6y2TEZm`p%a>h|(@0PDVZLE1CR$3KH)bCecCzts05Lp|9q z+f+Yw#O5%6d&TJaDN6hMqF4XFTKvV*6q2>e4n15~=1rhn z)gc8TZdUp)Q4edegHb2j&zAqYTHTZpyGQs(r~ybHGw1(xT^@GaXx%a!{Om^5M!9Qv zqUyrvmay^3sk-P0BY)QC)p+$ixRP>k#Z2jo24K*4aBTQhTxt<#tiHagv(9lGm?u^k zzD>GLWYo z()g^%{w#e=BwU8K?OSkZLVP&ZTK%C7#3?vt`C$TE-a{s5(Ot(C7{UpmD*dfmy))4v zp|i+Nm7_Vk(rF^)2Aryv`*AkQC6NPv{F&_azZG+AM2Kb6w1_mz?LtEQe-=_V!3*HR zANJ(%7ZeShokj0Gdv98AwzUC(Aq3@2|HyjVf(e$50Irk4_G!FnTjg}iO2fdXUyTIU z2OrUSx;ILJrwQX9KG%-}bH=hHGP%mmfW24wZ8sLOlntYi``$8zDYF-&7qwl3Au;xR zB2^LvY2rL-6C<}azHW-ItO&DW2d+60Z!g80OHc0b)Df!9q|+EIZ}B|mdwLXc7!_BX zS+U620x%xlB?NCKWXje1bna$dtRSe3`Ld`EV*ABtR~|geAHjkdoAx-CVs<8v^SRvjF&9V89j*p)FQqO;=A-zWyUfj}|RqUen(GpNAm278u7w^H@ zVvbj7L{$w_z9fo|<&<+?$#m*0L>qo+vzwX5>WGe17+Y?l_3lejH#hS^HA=lds)~kJ zw;Mhwpr*@rZUtBA3{g{hX0E;-%-noCQ?UMA$f!1pB)3)rWpS&{BZZ@0_awr$TgWg< zW%p4o41C!tZ#4F_C|D{>JmhZv`hG-29;=FI#ge2NQSl$m;}SZG1m_^2x9ZFCsCuFmlG-0;Cu|vf zRzjVcr0_T6eZ30O-kD(fL!Ue^qWuUMBBf}reb4G_#YxDY$)}(5(>#dOSdoBp@Xz=c zUqhA#k2{RZ)gv^}*hLa_g`QN5znGbd0~`@PZr#D&Wm*IVJ0+`)81}SBL4SkG{!r17 z^0DoE>@@GSmb@*tppdpD>oH^e_ior4QeiIe>4UeQ;l}=aSldM2@|WR!sBFtv|CptE zh3!1@`o?9VB9mHToU{<(10kP{Q@FY)>x#6G^9836f?FtK0z){q<>vQ*u@ax2cEu3T z1dADH-+e%Q+XMrKjnT9zVYYBQWUl|oYBo@k1ZA-pY<+kz0jR<+!#D` zoWN=}%myc8Ee0_mC0^D<&MI?}gd`jX_VHaIYa0@ePlgmPoHN}_e3lLh9YWr?4I_yg zh2g^R9P;HKtRc}XRcg2MjR7Gy8?*7supPuynFFO`F>qfOSUG4e8SY1NWl{pdkAIjW zvF6?6r}D((%wwJDvMh>6U6Z6_Wab)F;m}UfC63vc_;ecM+sryx&+Gy~0$W#zn6-Ht z+zPmCXC)q{3wkdXu^pi~Mv1p${MbYvSDI~t&H)kTif{-3Y&Ub)BrOK=qvw}A0FZT$ zSrTZpBZ9d3Y2H7yR}40Rhgvf_`Vy%3LH8@tnM;?ExLoWKh3W5 z>ONO_4Y=Cn)G@eT^&REsa05O<2>Fg%8?fg;8yt313$3QtZ~%fKb1>oK)C-hLk#@B! zt$iTyaoiWV-fA^I46c#XJEiys$< zw(sTHy*(A6eQQ?YkD6>JbSKnY^W~d|C|K_wT&Q?$%t9R$=YfIF;13bN^hy7&8!U%~ z?cox8DPf)2J&hFIk$~jKHivUL82s8(@>Vhk4slNGLpoU5`m8kGMTXu{<>{8w-A5UY z>{lZcO>BY8IKF|8XSbHaFwmJ=Mz!ERNci+{!uEEWR^1WTZk$O#n0;MMnMXm$;uP<6 z2D@qlPAZ9*F{Ncnvl^*9aJ|yxe)F4Qq_I|}=+_Tq^0p~Vgl(ex&zv!j{Mx1+pgSMyR8`wa|@TQ;|~RVEu<)1AHP+dbb7&l{qlIq_kZ_rA|Ihwe>)s@=PLz*dIv0j|B}9bo$-M5>>jl&BJ6wT z53P+?67N{Ix?hT45{0<~k90bfl9F@J9%4gAAOHIaCT5B=ilep;j0l(KoesY<7MS|` zhFP?NP+;Qd;FIz-mQyN~KV--G&|yu0%B~kw-0v+mVk} zCJ3XtX>F{4M1yASrS-lC@Uo8^zi7Y zs>;;(Q(zNGu2-GL?}T3LAgl2TC)|+8597Fa&U2?UISaFBH-xOB3UJZxs_ zAacJ>1w3MXY95-i_)|5mE9Q8AFTqu z=iWJ>7)|hfBOiF%D`Q#d8dGzi$0q2Bbt7!8+d6g`0fgO3jyMIelD#EToaRg7hiRO7gG70un!N19J4=31H z*k%WwIbNFEp_ZXKxI6WnS8(MFDdH_CFQ%e_l9FIvsU;L=^dOz=z#ARV!=zox$cf<&%SU+o;m}sly}Q#VF#A-exHI z655W9{OTl{q4yy!9n9~zHDVpnMKAlmORf}ld&#pfA%Lh$+Q(;|6;zxs%*(?gt-#G) z>Iw{UkG;f`f$RS9!S8rLSIi2e7)@z%U&gD<7t25Y%s|!K2(jFNzkmxS^MDorHS~th zR=SYoE-L2oZU={WloO~Fu*N6cr_*XnHXpbwmfP<%R5iJ$>c&PYw{ay~1{IR}3S?MJ(h=L7Ib# z2y%!wF#W|i0!CDBLRe?Q(S3}cwDF)HoAbbx)q_527P=Omoqp=`$SV^2?q*ue4QwuV z2D|_M*3y3{h}&QUM08LVIRPbZ9p-(hKxNuzX8b5VjgY`!jrgh9%T(&cnyw!mjrS*{ zh&N1hr(XLZmq~`$w9*0~idd}(-{GPnlSz;#0k`n80qWOZ#bly;{42==Ww?v2y>Mh` z4yV*Jc%QV=TNco zC7#*7YCoRMd7mkatnl@YS4?mS$59AAFdaqL*#wnPAU{lr@9graz4<;l0x&|i0hj&e zB*63#mp&PP^yG;Mi$3d16t}rR+PQn?@EL*a;3H);B1ya(ADd_%LZL8n#C(}oCuw>b z3-izrmuu?isT3|Y6f;5w!p$L?xZ0@9O%tl?i6QX_8jkD(WV?)1=TxD>LR)?f;l<l!@mDQDJ2g&&y9gxEB9sA~x zbdFKecpVHr65+5T35$dy10kI_it3c8eBR*SAJj)ZE)uE*z}>`Mh1Hzl_b3VNdmwja z`Ye2b-l7~dDw+(XyCSw9I!-*s6>*>VNT#ls!mJ}5O&zSJl$XmFcp!Obad=wQcD>c& ziqY*bP}#$*?|<@8Ox%~Be?%xcS&ewJclY#c8-#q*HnvKtIKjbzv`cg7Zqx0WJm#k? zh`mIx7qsQAoLy_I-2nQ!)R^aA&)<23o7OD-nsW?S{;v|q=q^m;B=fa?2 zQNRlNthd!;kFtO03?!KUX}Mb*DhTi`?d}>dl`m~BF`@F8Kd@3wyn|Sv+#TfOlG%eE ztLC%rP!16nL&KSz6t6RE28s$-jxM6AJs!uZISlWWpUw@{^mOIyKd{zyN%mfg!IiMe z8<~>f77(%!?Q1bUr@W4Jv}qECA3~QLC>++l&7`WFc7BhIatUk`IRNznWh^$Wnc!Y3 zq)|ByVwb}ZL4;MhQh_FNR-HN2CX-fo2U`L#%f~^6ftM$}b^G^f*1o?d{;&U(z5f)D zsSEQM4N3qgAsK1=i%0LYHfZSRzzcv%uH)?N%-#;a?;DjY%+$HE*Gj15@)#XKmS&C#m-YGE|jG0 z(o*>UY5`zRp#Vh_p~s1`|CY-6^i~l4WNm#tsgFiF4dLY)>}~W`YqEz?dGTwI+HrcUR0p!t<7e-Rgsb!6#gWf7KQWAWXar~Y8v~OHyrr|UC&JcABSbD6`{tbDl z5@a!++Js4F483)12uL@})uaP&{!`QIqWo6buT04I3^tG}cRB?Kvu5+s(?36JDj~-k z!0JRX@M%XmqPS}jJZMerT;Oki{YZ0Sd5a%P|8}1-LHu(uKbWpbYqjF8W70Q=9%Nu! zwT)_z48TK5Z!%%NN@I-oYKf5y$%#4EAGz@3iaz-ER#olGcUKPfVOf#jw=%T}DWaKL zp7(O9D(K8E?)7lP#7xNQ^{a3+<1t)+%6R6luQ;;d6yn?MFHPZ7z2bCHRv%QIBPNOB zR_=ySsug#0)xj87G}1qu_!>OB{l8F>*TMHA-}ET)H?wy^%3gUJ8X9_8ySnb?GDc}< zE@cgWv)eYho_cSvas21kX=%1=ljE=N`QB%`#Rjs`?NE`Lng5mb=voa5zzNrf^dMt= z-kZ@RZOzOU&jcT5LIluHH~OFM!v6jhsAM++8jGw!$NEp|h!7exjxT7=B57BGLX`$F zd%w?P=XF^Duu9E)1(kOj)zi~dj84S?g(R@S_2h(vCi(wlxI+FoSsQK*1RFi~S6QrH>jXK|)^8*9g|9=*(8ZXq_r(*h+-1lRL9)igOYQ+ivYA&${9! z?ou$VzS!4mi}lSoP4_x1|M&|aF;5z5(q*E_^M0QiZGfkx zPt8qRK(|RVU$Nc77dfa(Z~oB-@PnO%tIALlo&67Mgnh9!PG5kMM@KgaK%k1z#|r?d zc#xoDP{OVlAm+ICX2Gm{Y&2Ki*PBc&mB3ek+;;O^n9mhrA~}E*0!T!E{^8oI>1FW% z!nm7exW|PHz~swpLPA5@#8j#j;H{!+>cKXE2cv!}C!qI$;xz!@YNTmHCV}O?gJ@$J zdi)b@N+kk5Mu8*Ym2WfufE8mkT@hz$_R1#V&#%uy z63}`Ku+}#UTxl3ia40#fEN`al&LuHP&% z7-IlolTXh#A;y^UeAoPgs3iKe*rM_D9@!J0Ym@iILW<`bMY+8K#>0=cdv8HGm4Z}G zOi-;q3=?cq0C0S2I{X0DU7oojl@~GfEb%x(c~Nn~m?P(`-|}LLo>^3K^rMrl0&1iD zX9Prn+15h63DzxLyUgYwe2-k>I1BE%q zxi{UBVxEZeRJHeQ&$~V;r}(4znv4MPiCuE% zab1x%LhoIHN-QE0@&I(N`O_u%04<_{hM=jIx+_IbWNsCw>R5OW1kGf$Ly~~}r~G=K zuI5paFZSJTlKdf#{R<60cKm=}$&6$Kn;c=R9+1ddcmy=pZlhoUF{9w%Bc%Q#LeN(@ zuMbYT;0^bc{zj?{TPVaoo-&YUu{_}{^igvBg^x;q7(qBzuOfwAy-APd8m@&=#Gnij z74ocyyGfpa$y7%gMRf{*!lZ&hvQyUT8ba7K(o+x`_aP)i_?YaXwiVt}fwx2dksv(A zrm%v{x%Z43&D5FfHPmk&qE;qK+0AkVk7XaYPge<&#>q&pgbnMpYoMYJZ0}>G8*F-? zSonSQ1Mk0sgX*O>0l_G2ccz`HF!7Dc%*S%-C8j}Iignkyrp9gWKa@cFJkN8cAD$6z z_$m{kh1EbVb|se{Ans&uwZtlI1%LoE+ZW&Q(})v|6axddp)83XUy5!C1>2T?zA`Q5 zT4{?sMsrgLkllW@J*EcNTKSlDgXuc45-T~UjRz-iPcAv1&<`i z#2@9G{)e(}55=njhKqjD`oF&vQm}RFeB6EK;l{KK{ub@5JbQ2tX$&t91aC&d9j9nl zDVHghu)}auc*PEf$^;^1=P#-gF`X=oLvZLt4g%@vk;1H%5nk>Baz`NY^F=KJj#QbI zrBDqvINVd5kivokXQsEI>H&Wl4l#hAi>K=iTc6EDJ?J$9pq7`W|NY~D4G z;ZV4I$rHhDDp`#EYkreuz^yThk@VDGDjka62&dqH7L=|Ohbwebdpvlg%QPi&*I7;F zQn|0AFTb=cv4N$+nEIIH?#NDi5Uw8ps%aV%S7ZYG@{to=rE{@{FvdyiAMi@qD&vN5 zvTkGdSS~g{K_}WF=+YC+&wU*P59Ir;9@i<>8@q4v$=M`xpKs^K7tEG}S#;Ugs4b#6 ztXQGpq@oR&xptRL0!Cd36H&E=Rex(=>i|$TtOr+}b#F23qD9k0H9zF~%p99si^W$| zX&C@ibn%}2$hL@pz(YHds{kw6Tg1brl`U#h#R!m~S;MfO3!D$at3loTc?NchWlJczZ-0M>*&X)FXIwGetSy4#)h>fhS@R49r2)69h8joxtgl zkQ&83wQnjS<${%8g2s5!5!;X-bQRrMLSK%IkF{UIpU2v}<;5aaIJ%REQEg|@-x2fi zu<#_|qO+spJ+fFav?hlfB&r^GNB##0sqM7dr(`e23^3AIJW-lj)-`3vcUcoscQG} zV9A_3_S69tt!R|7V!kXFnm|1vSK!*p5dW9u$*SC7Te^g}{a_CM(FOwr6`+CT@$bwl;+1~GpOAL~;~~e>Em$p*?Yb=!B@+-wU)E&*??;5^E~ny!dVT%Y>K) z_5*?{2#OmfiOS-=iw!u;Q)RZ4M@65+t4Hs+Vs#D`Lem*U`i5GEH6Oq3a#)DVDald_ zx&8?N{mzxtJ$7}OklKT873t)vaNg~*>S{MlV5_?TYLDlBQOkO})qv}UEX6#T3stI~ z#L~OdxSkhB48CVvRj8)lIiPdD!0MjYIynW}<>uJZWzO&8Ku30bQ@}e*80hBKQH(V&mgJo3Q)Q6*hgSLte8fj9u&ndx5r*y|5_<^C#i^}rwn6rQXt zNyb3Aj%_C%f_6q#YjytI2OZ9<2DC~4D#m!~iZ}1K9`d7!g4i-hRJwk=Jzdd^oNnX~O13F_&$3GUtPI8@3i%`xlJpU3{1t{45)s9yR;tIK+mSeCBkG+30J_r zsM*&2$7t^rj!)PTI)$1|HVf4<5trwNJoCvqkWUFCXH#d#665uNKZmHP`{Jf05>M`h zL^`ZVvIxcXxMpzQuR%eShBj0YBiJz4wYe*IHwaIR<~`*)nTq zm?%p94ezJqvp1%2t+O8~Ue2#vreO+Fo)N6IYa7PGaS~`FzG5dcJzi$|B1U6Jp@e+W zQ{l=#Wv1x1TSLzm{uS{PUbWEr4mKuxkYZiST^6~bKC1=RsJ6)1ggT@ zZ`%nTJGMfWiuTru2tA8()6}r@Tf_#^7^lfr*_2pc4fgB6uvQkjO=@dB3~%f|3ZY#A?FDCPHX3XT}q~0!ceXS6G!y0jX+L zi|m5)x7c@#DbcnWox54asaLK&&VFY8%&W?wl~m*dj6a<60VMLUp@(;L-Row2eubn` z-{D-2_0=C5g)H}7cG|O5I}i(~u{=@$H50Bee;L*BeW)R|;;g`ECkIL{HG`xuf5s1mFwIz#UxXqv2e$NZhX zyE0_{?Q9cv&Zt-?hfF5tkgsD}F>4PPS}eX0g@XO6RXn|h}4+`P!EC) z;K8Z|L9~g43O|l*1OnH}U=>99Pf$}KX5_2VID!{gT*=ZD5B4B$5#>nIMM}StgH0`S zZ$Dpc<91pDd{U-a7PZ%?{+{qP7Z$xiYOe?bxj{E`P?oCb>G`-Y0ZVKZMP;9t)IrO! zWRC>}GOpcLqnSN$xZ2JuoA>3D0D5T#LP(VYx~=}mOV5(KPxT-*wgsyB(%@g=3QDKx z&54bo`N-{=07oNsZin6S60kH}fz#2@s5wR~3rO9>!rD#pP(HIMwQYOe^|=9=;&S;v zB5HmG((T~dXg-E-1!m836>}PSE$6Gh&gQt-M}4>KxGfp3__<>2WF?ZWnV~2rXRQt@ z1x3L=jP#4~Fz7Ply)OPM`%C@3g0SdrqOzohMKZLjAO1HE1B&AHnB1Zq)$ z)uV2+_mnK(%{mozvb9iy^QPex0W4^LL=O@j@HSll_G630tY4+hRL`DmJHAv7SDY6M zXNR}qLMfgzQG@5mS*G{kDE{5t@iJ*p2(cXzo#4D#FOb;L6j)68)sm;%B9LKr*LJD?HB5u~_O9V=1WxT70fROlsyr!nR z3fMRXYgCvjPe~aAf?9w;<=bK)vvYB_HB_Vs_O+-~GRYs=`|rV*1$zpaUyKs@JnOAb z02@ej$3uqX4DgS(p2FD>0V<@FC5zZ+ECBggMb~pu&3J-mJwn)YqEKtD-{ilGcaqC# zYSLLX-fRW{_$YR~P|Ix;2)xhor}h9kA7a6{mRW{bZX3s*8_*P*&B)AL{|6Y?>Od(Y z0ql4`ChzBkU_&jNpWjmqAgNSmb1+-6#c4imJpk%7YuZ{6N$Ef|W{UowUcN+f2S=XM zLGGh&@VJdn`(;CwxjIdcC(2dBJmXef=A zyfREkecoS2EPcOJ>TKIwuLPB$dN~s)Rj1OB=S<}(|9dvlwyOjkJ_82ClpUZZk3eI2 zp!dHCu7nQ@5+;!V&?-;^Dd~VT&s*`I!NHQ?$BUMR#>E_*0n316d z^m2S%PtC&h105X?87Oq&wQ7BShNb^`h7eq6BXXU?UZovqvlF<)jPxhRfu5dRM)J+g z5(i7rzsf<)yWmV;0DO=-x5!UF+t{3J0jsSc&K?4gRx^C7R^mx#U!Z@jTvvyRg0dMb zmIgZa2~>V8fjPF?l@DEt6g0NaD@!mx{I3n>KHkX08aM$00dM70Rj-=>EPQS{S9##u zJUs9Rdo+&9UI^AG-Y8bItN+`7!|U)2aXXY%4{-i@ISqnsXpP<0;bNo5oh*eEz{kb* z5{HqIW3;{sbxl480X$gz5KwD=&Xfw!?LgvDM;t%|@ERHz(9#@)NN@X>rz59C2+SB! z*_)$-sR`bjmgg#X%r$&LX-w|SjrSm`Q~&Hv0&kxpcqh9)fdq-4fx}M6;Icn1j;nfe0qg+0bS#+%3|))FJg#wNLMVq{|`3d-&tvlsMV__^q{YoI-uVD&cdAa zIe7iAo!7+I*cK!l9Gv8G0Qlg7MdjQqd5kFo`xO&5w8W>iE-SS#BI4@>=#J9adJeAV z;(UEjRc}~gV_}*QC?F^(*p!@{d=D0(CTb>EKpqeT0!**o*YyLLy{K-<*fg)$uJ8V4!HtR$AN{ z!2{PZYD#A+dwn<{C1iBM94^z1+sDBAU(g(Q?(eS%B`ZpdFTmPZCJK&AbDJ9*3$gwQ zK#2wUHxL~XP-6jU#iYj%U&=+mv{6s$LWmzg0^5Yt_vBXxwR?qk99E0&!ml<> z!QFmP*@Hl%`Qeb|?0?IBo@3SRfAWLodK9@|pT8(G(AT$@+WzhNKH2}>XFJiwUZ_#R zG2y?)e+vbTFXsqHAH@2B3R?Dd1?av!cMuP>65+ov+O7NCp~WZW+y8ZFO9*&D$`sga zpF4;Be?I&F(>a@D#kwuN2pt_AI##pgJKkWu^N9H!`TQ99fHo)KQRZ6FuXUcOX+4>6 zi0ipMJDyNRSu`Pjx<%}S7G!y;_0`zEbSRsH0u1S25-`PcNgONHzA(cAg$EB?JG-O) zo*o+U6}jgCKIJc?mcHnE#LKlA;??a4Yy|$c_+{QjWUyRh?-?Ec9XTCKWIw&n58N2e zM)d#0dB*@ssXaI<@bN)^T?l}Vz9=pmDE*1`i`(f?2gveYDZk?dnh|2@(%a_9N_~S` z8#hKp;tvH?alkT8tf%vpTA5=3kzM=B>ACQj5P4Ece8O;#Ox^7Bx9_d9F_QA zUc$n|!-r4iDsHucLS8Q|apC8gYl02cfc>trEaUMTs-cZ5wunadbn*@gk z0!X9k{|!z67#ud%AL!KFSnsdBE(hVDdB20#I5SXxzW}EAHQRU z1@n}48Ymi&Km7gyJL8S=KAr6EGNP}9{LfLrpE$WaPM&^N9%_zbeU`RcL>My*SK0T* z95qc&NAt+YGkaTGQ;bYZ)}P74#004m^=Y@OaeGg9Rnzh~x58ebKu7NNcZ~A9Kcu5L zCjf6pZH~9I#7inef4lc-fGZ`fM)yCS#VZ-E-d)! zvJtQvb)NAzadKDj86F;Hfq{YHjxk*i|MMry|+AZfg92ral4Se>4<4l14CjZ+Z~`mkv>8G+u{``M zVIN1~&EEMMyR`#1oGw1v?N5r$*RUxa#DpScpBwr$a7?()6oCV80@^{~e@}v(FHnzf z;%tv&|H`?t+_gwiK(K2sn^K(^JZ_v+&nY>4iXm44^u4mcYdQG&XH!yC;nzR>Kp)y* zF(O+j4~q+(L|1=Tt9ndH!{o4N-_e^-LAFv zc6L;Q`UgwfDPeeG#s{HyLRC?$+s|=4rm4v*_xSiY@c!XpjM6uG)*rNwG6HsGWrY*` zNjBj7_lIY0A2;^j1VbH*dVK7}5VDz~*Tm_Bz+sigPsZ7KU$tv!=wAJ2)si#{^md|x zHX>PIt71yK?g?=C2$O&hEfko__B;TO5v{%?POCignbNEVkGo2ldT_7nVpwp9x>kC*(7N8!kLu{bhyJ}IWwcYfS{;gmt@>; zM~XxgO59;!(%aq~O)ZOI3LZ8uU#%>=7u3nKy&mp+9&g;&A0799CG)ynUV=SsD>#9$ zmg_WmQh3-91uYl@o8T{+bCO@cI{{3M|G}rgBCPGDk5${ODS-p~d@MMwl7nR;xT^6(ePJ4EX*7s{r zg-oP-e#>^FDyK!VeN&*miFqo0O4qFO6qdkkx+}l<(+(Ct%E#W_H>(n3iRT8ie@!|F{4nzEL-gQrW4J z@kQNRgq6LEOBj;3_TRFcS6~$i^tr^7z6dwJ2D3Hl9yc)DVY&0dY;|jk@!M#&bX4jc z%Qny+-CYD*ej>}s{292#cJXR)kWloNuZ)Q)=qNqj)IJb-!iPqr=yoI|I71yM>~Q z(rpsaaOxIwJ!4;OqmJ~d`?nEB!to?w)JZCuc($GbTYfsW$1s=IV|@rAr;O**gAt$L(S__5hp+LQH?%)_@lw69O-j#zzmVV7S=9);v(5+1h};9S08DM9TL8J~fxI z;vX+Xa5frq0Cb~k!7Z!*j6U;hPkQ|z(nJ59zWajxW9yRb+NN|*sTZ;7`qYb-RU?SBTpPPx~7-fbKms9$`%aZ||tv?5k#e=zGnqh1l@&gNDg z<5Bvfe2-N^CYjHynVODHDlCPEf~(A!UAwS^^-bToQ(Vtx?AgW&50`Yqoa25RiceAB zwctXgN}$U67`u*mV57nMa-}i~^rQk$Uj_4U&-qTKs}OatuJxb?3FymF#nP(8{r(&* z0gfJqC#xN$dTj_RK}rE=FIT2D1gOmta@KD{lUV-RiSCRQ9%$KKf7sTnbN#$%eqT?t zSSK3LL`wedgA#{N}FJC-5%pz)Tn8LdgebuS=kX$w$Ot zt{NP}y1O0DwirTgg{eizVpG_!Ua#rsb&-K>OP6qL5|Ugg=UAZgA%SI)Vz2R0X10l| z*O}q?Uds7j5)Q4B0MZQsk6s~;Gi7)()J^6#G?BqV$CAv-(UgXkZ;q@XP&U@~U2yMe zuCSEzOwX8c*3sV`g{SWyN_T^$OSdTkL-2<`6HFF<__OHQRd4x9NpUmefbq(>Q6=ts ze)JjcQ(U@w?8f)_x?b5PA|{W8>mH&TmnFfSaj$&C-d`;OYFEqgDV^edmVO%z8)p4` zqO;I1i`3^9!`CyXmp>MxpvoVpxA$*1yvujE<~3O}jf?F~X2hrl zJ(un=r^^r6g)T|&g*iN+Dv#^}0~LPM{meyXJa;iX8cm@tMV6rwrz`pLk*3`athgR@ zm|uJ7?mYR)`H%SDOB#p8G!5#+tVD11&7tzMFwJHuE9Pny=%1_DzS7DiAr5a9g`_+? zc7a_BIndVU&^-f|(qdsmT%c%&0>tS!q*!Ov?fNSHEPH&YrsWa_tC@#x4#rDwY8rv9 z{UC$WnJD;Ev5em=R;oJqwa(woRZEn#_qa8|x&{AB_2H1{>^7%Br!Uf@sk?x1YGdI< zI7>g}cGPBFNj!-m<=j%W&0A(c#V_kX!(ib0kq_`vJXgNeTuUxfE(+ zpPhv~YHb8XZ6rf37HTI-J=WBB*lbOId%AhNw4bfA(qRTGq8UJLTx5U$%nE(plgYkk z^1Q$P2hwY~9ANo7a{t{HG~I&(1LetWCyb(UFjZqQ@MlKiiH%LOia{uF6;BH*k`Nd$ z4n0A?h6sl9Mv128jg9&{HKg#M z7(#TgG6)IMi{4C_n%Bt!x+pBx_2r(qsr^Yz!^p4G21%(KM5S2C#y=JZgb+?ES03Fe zzwxY=Fy+zE-mHJh-M`tTShIo2wvBTaq{294;0=`FNQW~V849B(6wjGD!ox?zczheX zTNT-$!x)dYGsY#jHJ)Ji>UfvX)+#%M#mEFRSFX|@$EC0&7tu<#N)Q`7B4(CO{8W}+ zN}j@UWIaM}{^_2N@aW%zBoS=yaGT%p)aa5pE}FF%L{{Db93%PCXSWK4ga2%AdihyA z3`uA1A7sX;AmjOuXF=BvKU@^S-W4td;5^+Meev&}ZMII=#nnpmze}a^sDbm(y9Abn z8Pu<@tzd|6qxW_sY%lL!#wzT;jX`~K-2P2bUUBnNxo*#%v^7Zv?ix{^`ORcL6bD7^ zMRpn54mq;W7)EDG#7cxcHtKXbSr}A=gsaC2QV*Wz{3luqU-`9F=auYHY?^ z!Dsc|yW@&Wmb(J&)4ebY7Ml%(8kevobXnex6SH zhQGV|6Hdr0OT_mcPUA)IIb&lq8a_p#&o3|RKVE^1zF=|jxCGpjyA!uV`N5z^slC`d zfnIs)AR2~y+-YnylRPFKOVs@wOx5}vodRqbodND*>0PYAAk6STLij-l)w8<2brP|V!*^gTE3DutN7nkk1 zf4=HRK~L`UoSiawsQ=gn9&|<^Uip{>{a`{y+lt^l*t5k(Fmi~`EmCX@JH17qq8P(U zhr{?5KFoD_E|pr>?%xGth0l`7IS|shRzY`O_#if-F&X3(8}BoyLaxAmB0}mSc{n)2 zWxedpbJC8z+4=042)1X`;L5>rkqdU)^adqYe(Z~xmc(jW>7G&E7!fRY|426;5zCO5 zSt}JK6ZWrXd74X_7H_``$H@@WE2>yAH=H|P zW084o$8KoyPeh@~!FcB4fT|~swJIj}w*CdbickRE?YMu{gU2Idjl)?s)-A_x3&n)X znJ?n;e10zI?Q%;x)Zu;e86Jkmts7BSCqlNX-GbuL94UtNSA07Pb-wivGhb@97P)&A z3bk+N>P4US@BCl64#K3MVr#tn#7g)nQ{7#Kh=@p&50nk*Ts~{WyH6EdfN&*nDz6K& z87i`=JU8>nTy~YzY4RN&lr*sRNL>GB@}tM|HMMV@8tyQO5dTFUggi-3xT-BC@Th*^ z*P6{`AVGo{?u5KNRa%(JbhEajW`ZGLeM2A37(c)gfROH;VTG8Ivd0%e9lXeVIE|@z z+0#n39;)B;6k0_E6%6G4?6_Pku+_!582^>{HYuW{F-3}krj^Nf-G6w&ac6U6OVcikbquJ~8M_f0t3T-EvT|i{BBw`K0m@5>h zf0`Qxj#}TwGHcdGcIE|Zn;vV|)neF4QW~YTtzGpr1rZs0e#sOO9N%=7Xbz@vS@1C7 z2pA7U-LRNEvcN$fw%p06!-=8>%)Us>2^vUE6D+1&QK3Z#roE@D&?t`_T1;cK3pnSv z;@6@TNOU};@OrFNX;f3%wgKru+<<6?6CQqArnub+vzG7_JFa=5F77P%=>hih8RDM-KYm3J(5) zpnG_ITAlZU=(|FeNcd8~ zc%wJA)Otlot->_cu1E!tz_I{Ac(l@@J@j!A7V31l9m3>xM%V08rd4d$EM6jtSZo8I zB7dOc=xTv+fBuJ#h<(^U_%l4zYS3Ahq(5@ZSsCdYx5vKh4)eFdeuC+ReVDw(ZKE3J z!+f4!6!FRTYZ3W6jh`+buN&&;4buBP{{@yw*NJYm1llHig4w|oTw0AH+`U}>VKuDs%OVE!$g5ODd*?Ln z;~QBHH>>>9tE|3LbHB>3YrJ}T8@uIfcXsL=$V~CN<7G?!#cZ_p^vr@?un0U*??E5> zwB8z2FK$IX{#$Fy8;3Dl?A=S}4uqGN+ta+Vkk@Yw3f=4>#Jdk?*EG=%10=Pb+N45{ z-smc_(}=WuoEeUe!x>gQ7gXkh(E*d%l-&C;UX(m!JH8+?L!$nA%L!Xy7y-0|WP5+1 zP6Y**fet_eai<%7eITAnzo`TXM9C8U4sxYc`t;}uDVG|@hg!7VQTcsu1BXdMfk0la z6jR=J(O)d00!chS-E#h;ow40wUyS=J5GYsH^)r_3&bje{r`g-?^G#_8A?e1CAvkV1~MSrnO}C)vMom#k2Gmz8fWW-GSFaqO?CA^ejh875C9L2KU|H%E3x{&cle zTFh+@fzlr$(ZZ^K;El5V;=RrXGFJQ_L0MZ@)Y(S^XeBtCU+fj~+9b zeqXIZxrbZ0&pJ8_N=;66;Rr4PWs)Mh=Q`o2H}ma6mi)plI7rgZT&`K#Wy=C^Sjrah z&|PL?2!QEQ)}Xfp1|DbYieQb~6SbBmCfZ}6hzQli6Nk9zXrdH+Qm zUF+QXVrOit3Fi>tJMkFA(D_)Rb`1gJg-v>evZ$?oFL7k3UE{4hi(%~)&kq;la{;vq z-GGE23bFqrciFz7Z<}jBn+XJsPfQSSa0b16@76d+SB7{Mm79_DF7`mP*#GhHmSFpQZ|X=6 zumDJd=z?T~%(5@QxO!jFHlL7z=n3URaAjlFt2q*ldLMB7d$)Af^=6=B>`oXN)& z+pde2RyXO*>QkYtz7o5!o>1Rn&y=!MFN#ww#+m;u=+6s1V$iX8g>)R)O;Wqb5Q2Kt zp_uhk!aA565q&kc zRxqw@YMp_Lw|5n_*}c=U&eY^U|1Y}XmOUY%7nc|ov$eu`_0xmN1K6b|zj2(ieOS*! z4AI)ChT`SN-iWCBXL^w==J-Lh3_aaSMeJ_2W*xYsgnZd@c}>OMnLv(J?_!*XPOH^I z>nGXdzJ?y|P3W1OD+^M)rW-!Y|9xAKgpHy>uc>P1d z=WwB}?-|A&s0`2J)w$+bY(KsnX1_CBUa5B9$h(2-*T!}JCdn4yYG0GDjC%3jF@c@U7!UE~_~iHC_!rh|Xe7%4X94^0Ynzh=b1x6Wa|8Te zYS+3?j7t+X%Hi1SBS1$I6ya00|Hjx)6;o4JONi5`7y2q;n9>DzqD6u8fcT!zA8AKU z*$!w#`PZ>HD%81gKH`)+_g8joDA1tX%E~MNZU^Oh`wlLc=7#Z-l8yDnva1JF?|TMIdW zC%+PhfhUGf`J`?-DS4WD& z;z4DF24CP6p0Q&TD2+kZ-g|6m7;uefs5T*p)GAyac`We6X^9L6`2eqK7x?cEcyzc8 zO0R#YgAe{?KkcN&v9GuJ@+wCbH0)1VRIoYxf?&p@LHXznTkl*qGqaIF1SVUpcSGkKPJ34r1N-j@FVVBE{00Ih9Dw`ce% z27QT7PHv$253Ki{?}|JmOu&_1sjv9w>IhQn*Gx@{rJ#y+-xG+c4pJ~;EU#AJjra%zpyl4K_#v0Fgk!S?g>v+Boxm8_2& zkHKREG60~(B&6xAmUr??MD>^Iw=o0Q6tBVTp^Vo~4tZT|yYbVo{}(fU_;6KVb~?7* z@QuW$JQ3yt&QFHltgWpj;fa?XeNB!G3cY=0`q|F{xL4uq>-C6c1KZ`Brv!|b8a)(h z?Y~v60(mJ>KnI}#=yx1|Q|=4>v~}E1KJP5lRq+5v>XBER*;Atb6yk$D?+!RKmVg3s z1YqTJawt>o@&avxsQ-unxQq;7r3!MK0|<8{0PwqkbH{tY2(ekjoxAryQ;+t9T!6) zBuUw`fgwf{q0bZ0r^SkAm(+P}|H`d%HHQ}@NJf~m##hbK?JjneZvcw)4&3t;Fvfbo z`HTvj{v(f%t4{WK; znurT9;@JSq5?`2!CND3*26iJiAsO2Pq!hg`18{a7ST|rT9?g{HC>3ch zI43g|^WPr}Bcq|=^dT+OyOg2fF$sW@F3M*uk{!eVx{LbrQOTFL4%f$eJHQhQ9~Xh1 z-?%rX=U%hQQmX~~dt`|5KcF6vjS0Fs65uaAGiAoogrFWOUI~Qto@naO_`NY%{#Zca z=mvS0bwHP4P7ERDo-CJra*ZU*YWb?nYj5=i@-?c$JoH8WfH^AxcrY7aCb5$=fn;=2EqFyf z(5e*1fNEvYV=P!va7tpc6X2(oPNX#Iiwkw+-)XA5JCG|i9wMo+Uh!3ftp43fXDX)58$n zSK!dYA>h~2(Zp^x*)5F8O9>t)kNH|t*x#9vY6=bu? zt>mJ|mDbyP3^KBi;43Da6RP^tUfNeUIEEntv^?JcJ&|g?@59zm8fPax0zCp#grGCF zK}+34z8dRWx;>EZivyzKy`U+&Au15eblrL9di6^4Z)nPkUO?F-6XZz{2%7FsC0no< zl=EVc_gdiubR=Tl>uEm$orlgJ2p^t#PMtrfEyn-KXM5b10iOssrDm)m7>KU#DnV_4 zp7}(e3jFkMes9z>R9!h804^sJKuE{C?wn(X-GLJL*L;D(x<}1gdvR4C9Zj*V>#i5U zf7}d*@G-yPE#QS=KZ25|31?zwf^anS*9yv$}| z__j0~ST?-txDrd=ktd)=lBwO`+F9LY2lq+u*dXLIlca4DmRL7*$~o*9&mDxMPC^78 zh^0wjAi~kh2wzcTM&#npD+GLY@WkcCyLVukprykyZ3}%QUmndA$A&ZhB4`$3FZ2cm zQn+FV8CLX4bzVg_h++Lw-fY*(i+4~Cq;wUr54(p<9FLa;#}IenzR)wi_RvihKsZ=| zf04QKXK$M4BAVH?b_rHz7uMbz%O1{@UMt_#2SX(sBfZU)R;@Hskx_^VpVa}@DxbI! z+hmBqkQn0VP71O1j@yGs^BH5Dbe|9q)3|f0_Bn=QXp=eZgzrsdWdI%MO%R;?fd{13J*s>Q zBQi?VwlVF$!8wP89ViC+!n{}=(*c;ImJDSfI(NKynF6mF?FUQ?|60)hapUCInJ}x`c|lIBv!u~_$Rfo?ozRL+s5Fmmu=pbqc6}Gh5q9x zOhxQ8L?lk{^d-4;h$LDCTw5lAdEhk-7g896d;DvL^In5&r53SMi~mH%rFMyUd%Z7y z$hp&-WwYn>^0QMoM(P_LF>egr04Kzv2xUCR#Ij8Yt=VAy5w5p(jqL_f5W#RtO_d*p zS?tAO?Vw3~u~cEWba$e18rT?nDg5reAw95z!LfH=J*sdV%?5qitAX+Ck#z(De~#5) zDiiB{Z&s6HDlBw$`or;RCn*;lcj>Exrg-KZVa=hDlNZpqk)QJ081~22Sn41R$#Aw# zGK8vY_?=eGpjdz!I)$y@u6PcR2kvNMRgx62NDvGOE2Xz-Behl^ljt7Xk>2s|e{bOB z(ZfVXXO~^~p$Kv3A;MdOgjG}_7Qqzz2+H8$-^qK!0U?fBvHj+YI42}f%}6E?S

z98ukZ65pmdPSP#u41UIl)r2MU&|Nn6T0AM@_ zgD7+}S)^lCFTd^ASV%&=IiSU_W|w;Cgb3YdbUPd1OgY0*W`R{nFZM!2Dr+n2y7o3* z{&u|Fg5b>SgRzGd9=3sQpb2?TBE`K8AwQhN*ERQv^p%nF6c+I)@Rb=S*m>Qf1mcV# zv?LOZmW}QF25dnrO-3`3znxV4g+0j?D1{}yw2qMZCC99bNP%fE4??_k z|JITsL?kjzbSv25<=wY7TO%!m-o^+9#H!8F5Y=f^xwc1SGXH&bf8vw!WI0}47$#k! z@?brQ_r!P1Vo}Xs&w$=X(!)n{TVubEL5Rl;!&HPrGyeol2ua>wnqrN9uR=X;jiA1P z$bA;WUNLp9>kKEgy41pI{p^g_?92JnngPwMlf|$b3l1x_weBxw5mFCi8&eyhQ&<6V zNwfjBiM|+Lei0dTm{8;N!Lm3#z`!0PZBoDyr%y;A!TcTeaw}0t#%Ab#B<9%uL)dJ* zB-ze;c#A*t;GC83sh(lh5Az^MAv8T4`S3Y4>gA_6hfwGV#)!(SJ}H4mw&f*N&Dr)x zB8)P=5}R}8 z{o0Mpn^?dvXAf^>zwPZ_61(OMr| zgHgK;3Vf-X?KufeMzQ%vp-&y=f|IV57zomqo|X96C`ObsgN^= zF;-$GJ;^4KwW&4-Bt!(fd~{{^`WJ5am>(Q6)9tGC0W(bNv#Uob*e^YAtux_lJ`ybj z1O_${;o#VB6+Ls!^l*+PhJ*Ix#7}}pf~et(q?O)*Xdxk@N<{JkZRyvW`d7{p^DeLU z9ZuL%*_xeAG|_EjEk?b5nl&+bBEJ*_$B5e~bmgR0tiVBAi>8 z&?_3#CVhZm@y3lJZ7=^cnYKL+zr8FE%OP%$m5_>ebsotv@&UTnorh_mZ`;Ja1rgUo zF^j28VBCx-b5$*pFQAZAnUpo0a#c6B*AOBpph7q{- z)!F&F46tzLetSe~|3zt+@i9b(mPC`U9FmuZ3{_@~y8I44@un+?RlI!hpJ!QRh* z$H-F<&v`z-4{D)kHrXf=E!|T#kw9qx)E-4G`Ucs((w`@S%OF{0H>eEP=*p@q)3rt@ z>cfQBjQVel6IsNtULD*bu?$g?sAM$?KKkEFbB?4@Rm=MtNrv)WV?|@cslHNB_7Kn+YN+f`bJ0>n4QlYP@s!E z+%`vZAoPzB@i;T(i$_yct!XDsrlWiUNQz9%tBwcQ`j7sQ60dHO#n)Gf6#?5Hyg9>| zL|#!>AEN%WBzDzmeGiCv>DYokZCyhW7Z}kS%OzzBt0z3RvbW`>7FU9H11e>1ViTqC zYvr%v-7iz@@y>jRY(k>wt~!X46EBl!`z8+}7K;3VI$DWVs2%+J)Nm?s^pM5I*YP5Rrm~Odh}L}54lQSc@g8esys3T?=}WdpyIintrf%s z1hb&Pe0lIKzPgf6JK!NwpOjC=J(J!-|HE-);0v{yXf|{RDX5=n->1p$eaJ%DU`<r4^V-Vk)5h0K8TVK64>`89%(Zr7@k^A4iI#i5h z;Y`QbZM5?X(Q{8Zby+(1A&rVBFbpj*QWBr zCld*0^HzavCn-Pb@$vAgnQua6MAtXKWd6h=xbH%?A|Q2X?0n;HcBKUKOuYn5z})8B zBhT2xl|yh)M2kQo^z=LY@Hh5-t%TXKTq$R-f_vLze>7x_7?=W6 z$z89uE+h*=HnUjw3Xe3lTzQd2=iFKx+K9RHoUv(4!=n|&(+NyBqdjh`L@ag`J(DbL z5 zx8A=zi>BiEWl~vF(?}N&sEvYoR>$Fwrphd+yKC_m3`e6bSgbm}0yX}%IZ3~~EVTFN zNloh6?#EdtFVL+>DTxVqsX<;c?oZBOUrd&cL}(5Q{_&l&Irkq$Lj&26B@zJ9W!SD( ztXO~i5*QeWiHw4B`}RbA0!*G9*b?}ZMDo(X=r9{zQEIBQwp7$XhLw;vQ^LdruH6uk zZM=khP0SzX<8iScew8`qpXun27F{<^UK9^q7cQynQv4&BSrZZxl0q^37ZE$SF!Qkl zA2%Za)LUFur{+WdxTQ2;8ZJ?=Cf32J8H}mOUQIXQQhF6n@*k5-T)pGFdzn&;V}JOC zrh|$?wc0fJJgGzo!yT%5*oVW6*rb(hkTWEi3iZgc31t~ATq!Gc**an|EEJ9lx1eVH z!bsor;G#}q#Uz$mB&P(%CXo*9<_n*8ldz`_SL=SzxBE>^#f1<~oha1!N9MPB&XTj^ zMU)Wboi`L49i~}XM$KcLZe@pcIvZO?ep%grYBC3oo!+Tb-faw@lzj~kd)+89tsd=Z zmt_~7$Ko-Au$IN;a5$>vU3wmTWHfnNWYo4#VtYJIJUnwbn1mqqhO07>IdpGUuJK_f z-9D|H&bKN@b3`7kD!#@=667*RrRIqE@FI+PX!Uu7og;M|sRTey|<>%p<9~v6MG*Arw z5P^fz{sw@fNVzp1BkV)Wy0EeBz3~)qqg~^rR1Q(J@i7i4J1p(5x+4Ny0Kt>$p(yq{ z9Sv2t=@=~WD8F$(-dXW!=DwSIrG*a$nSS8h^~dVbU21XEkE}fxaw=0cpRS;H9+~x< zMC7l?DGe1+?yh_t^Dn%Bn8&9ZkD#HOpE6p{AhHO|D0wA8<+S;^4p)ZX80(tlOBj|R zr_>Kk45X&@*qI{kw-+U&rIzs6l@nJ7vPL~yOWbW;h4*$^5^RK26wpc5q(_((i{M)V zymSa7KA>;V@DfUfhADc4V)f~Ji<1}#&bQRhr=z+k}#z!!$@yF=Ip))VO zTFhY_iu*v;Lb1f@ZF|{jWU4=$vp2r1mYWv}vIDKdKl$SNoKug>Roy(k zSS`}SSV@JGiT+FfIa;Bn>~b1ZpPdF?VH&N(FYL{iGjY5MIdgLeha?YEN#$UcWPZuX zMVKA-Y2>1Eit;v={B<`&_1|6;j6O6B434d)XRwOMwECG9N$Irg$5szP+VZiM=>})nhY@J-8~YZ9Ha`OZlZ(pqiPeREfR~N8 zpz4;-d}zlho6mLU003B4W30&9#CAkK1aublXy3UHK#PghnAAq*rCE%ZNnZoNgqgSS zS6pmzC=%{IcE>0UTQyw7v6)W~6TLuft|ml0kV)m4IftRozZkmVO0N4fmpQaqw`{2; zI=Oh%^kg~sZR2q92@QR*od3pyW8Qx>ea-c4(km6m{rWBb+R(tn%I#p7_@0&hZx!*Gc^S`5d!a-2rYwg?seQQlo5ucw-<*1WQqf{o%;l zgqG{8$=*Ut1g;87r9y!RAB1`q<6hl*@i+{VJEgvn$S__GwO##NNkKvC?4K@E7f**> z3B-7K*GoYGixZy@qELRM^~SL*nzjHcgn-Yz+I*>T;l2&8Q*K@JO^5}W%Rg&J zj6mj7zMU-Q-EdNV%UJ}pk4({iyeBLp{1|*$i~=Zu!KVbpYXpVH_szH>v% zhL}T`0)jurS381@fPP+QamV|v_Z!}#XnmUlNlA3p`}{&y7$uor5MpgaC#Y@b&$_Dw zR5o}dZ%hRfIKpy50s>PqMFE zdZX-HSJSMOPN9ZC!VCA(fphvOz)W0#y63>Gu#VH&3%0qUw(A_N&d&|=vN{l+f5oY) zQ|EzgA_-2N5Tz3jy#lNcJ2Ije?w`2@64){ST05Jpb%rj4`BfNrFnZo>;FdM2KIO|U zV_M-E6MU`!)vRlG%}xMpn| z@k_cZi7|DftU3R1G@KO&*Kf`4F625Gxfk{?znyOqaaEgUx|duSM^6kyiw0gA)78!W z!N%Vvx?U^ahgy$2o9-9tM&U2V!W`pO5!)Y|KG<%5dU5pY^{6o-ai4*q?2DCe`^Y;1 zm7C&%)EwE-PV;NlA7{aF>}dSq<03QZEb5=;XEGj1MfF>9NswmK=tQumqwoNhlT_$T z@PCd0hh(#d*NvPhlLjv`nPUk1FelA(*7*yQE3+jt3Ns!vA9E(NbzdwkH6R~XKuDeG znd+IPo^JOTqpiK$cn-cpA@r#~ngITp{Rq(ML`kM;W;qZJ>GwA>to(;+NGg%6VWc20 zf$n)1->cOAvn$_5-Aq{3gr~#n8SMa0BdJ6NPh}Rk)y5`-WGk~2fV*-j}AT196OO-j53CJkm3Aj zw)4Acfu=_fF`eefq?j&GXx({7fnl8fX))vn7a!1jUVv0wzj(vlYC{0IBN*^eGLvKIbqzZ1v8{ z=dziPucy!Em}wTxf1#NwssvP`+7n#3N4iO?F&uearojC0Df`lMdvw)1M2gO_h{8ks zPMd&gA!&+w;3n?n(oqF2rGx1c(pxOV9j#sOm#(>`AJ|XELFG5>r&Y3+OJ0L6a$qF3~rMgchd%U z@4|aL03;ya$6cre3eUrUFJ{VV*rExel8>`u^TZ$F4*%knks1<>;g;d9_f@#{L_8ap zS67^}hs>u;NX)|rN$1F20$1B)rp98qNVe2}IFR{XD*W0!kA z%C_y`J}J`u`o(G-#_WG01jBniqzxekm{c4nLGNtFJz#nBPb!g3oW*$1Txe8NcsbwZ z^qdEz(6TW>vWa~dLZ;Sn0d0m1&<(|H+%(T^SPJvVZu`JGLG_vH+|u~QoP^f$Ve=sY z&3Fhk@CFdPPIeLQ^fh%8Qtx9Wy5X5xhkwW(2HHq}$caLZX`F7=th-!`Q7!{=9K7S7 zWz#y(1gjJ3Twv|@r!r9A+FrueSG&&dKXln4SgTJhpMZtbOmC*t=qv9iBg$TY17beb z<7RCt>KnRk%`-^a|5MeM2SVAsVUJ<#Av;;i5-LjxV;iXuMu^DXC?rePv9Bdr%f5{f zA-nAR+91V5+1F&>WnaHD{oeQc-tX@@&ok$_pXZ!&FV}V56{m&i6tXj1TFZw(%+G!l zmBt_(67sHzlu6^epmOA@@y-kzS&h~?{4 z1^2F%nveQL_et;;y)<4y!U?`(sZq++Y*sTjJ{sPQk9^Kx5k+(4yEU+CdpLG{kYl+M zKi=a@FRbzl@~OrLUexd#y`d2E%xn97ujV^gpD{~Mx~^~~m*8yJTtd~zfF!TWSWx7N z(a)P~L(sZju_Hg$oH+6p--+Je{L7a(>pCXCZte#JBIVvBk?YBDL?)e{p6V_Q6xJ!8 zPwp20k-biHqe{q4qSWvDGo|C1&a+>bW=f}pmsg zdx+rIm8zDFS#}L+q}cG+JA1e^^C%i1jXocN4hL}rB+h3b3JuQ9Ws=I5qQP_*wj;S^fiU>|!#<>Jpr zI4Osf$fVo)aT5|n9aJPFMl+Q-6q(jTJW=@gB6*f4G!5Vs40=FWf6z1gTD?&LF_pc+ z87R+Kyu}Pi+O}{SfV$khNG|zjE_2SU!bxTiv0+`JfUB7pg!HcaCEvqB<%x7mO8jb- zT0E<+Zq0JxWOX+4yWI!1Z=dF_E+4Z&f?B83(0rZIl~0toJ?6SPG&s>(1zV>Z`ddz` zTc4hG+uKMz3*96&Od3DbIJ$i*=V2NjZp{y*>Lk!bZ5((TrcY(A&%NiLv&+F#EtKaZ zPNl!!?Hp8;Vc-saKEj`dyXx9VdOLZ$A!at>ejU3OQ@r}aVm5~u@WR*S7d5517E9RL zUUom!R4n|1R?QjrZuTx?=@R}?WxZjmQ}&p_gxboHi15zE^lo)TDBPGWsNyAsNe zB@Z=Mc!s&Fdp~Ayx^zx34-d`A)qKwd$s+cP9$oyvzw;0TOx(%@7qz+!%Ju}PrO8b6 zjZZ}~L>+l@l^{BiYApcdtWFj$aPN))HKFIYu8fW}#ZT5# zV)wy1Gi8-y4|XnX3YKT^r|}9Fdrt8r(+|QljcA6FULlp!>ZZ^d1;7Ie=QpDG7TX}f z*J4WaH^rEj$V%|7X_1h(b$gpgqGt#yuS|dS31x>RvpToJ;gr_Xi}m->UK_r2$k`&F z-DAjAL|@FqcDZ5rIAjTc=Bc#OIxya0NjFbQ#UQL49|r&S46>hW?Kcu<+h^xRDkco?^=wZ z;L4w0evMQEhbl(PM}hM{`fG9d3q|t&RPu?sh&LOuyS^Z~KUh2|Hi zpY+IJo#~K$=h$sB&V1T|fTVg~F=qj_^lO^IYi}?6<4eNX`jR4c7;pagGa{U7=e+Ee zNHOlzpeU>@ofUIa`gOml)q}m7qg3Cqde_nIet3R|uKb|GSgec9rO2PP@pKI{R@YuP zHKk`EAimL%P{K3SM{C zZbk$V&ttR5C;mn|(^rYGXl~-9X!!E=U8-T_w^yQQ%zxQOMLy|tO0!*H=hbJeL)Spq z%gZQv?~68UzY}*HUwkd~b^K_I7XS7|#AALco=aSKh~ua9SDP~?khu*@k7tux`qKw5 zG&fh^TqBuH;cVtGg^eB}A$<$`EAoYV8?_Mp+5nMln4{zXjSo@m*tdQF!C0=R5oOzW z_A|ttOq#b1(_jFkDMgZARd9!i$!Niy8Y;Lx_C9h)^AX7pzJS~ufFs;(Pl(IILrTx% z7Hv#M2b&t?%d<3Z@f5c1#r!5`ubn$wjXD9m?jhS8_rq$Crkwyqw~(2S&CSj04Rr}4 zvY_C=^qOkHKz?RX(aRnU=Zd+7W~Cs#9E=!_5Zy%>SpA|~YqK?PZZwqpR7tM#*o+)I zlZ@v1bhP0Fu?YX{%RR08LuG;egpaQWekr6^?9-yz^K+dG3wN6!BD>%k@m5 z9jy4w#fa^_Nk0cj2jO@Lpnj9Ho7unDS)`;W7g+vn;-c2)et1c7T<2VuFQ?so?w2w< z5Abw&CwB#g^qPM0ydCDWot2S?`F^E_g9SD&7T?;pWtZ~8UKNcu=m4bM;RVF{o*}^8 z)w?fo&~$7AqIq#pU|_t5gJ^|S9->u*jvE`Z(eQ(rUYV%1RJBbbm)+{z^f+((H;m9V z@xu%|bn)LL_Cy`L!YY&ieS5FYRY=N7(@_9!H4cgy?tRqHv|&0WV3-hkYn+<1n8qKr9r#qRkUm!A!uMHvFAn zshPZ|)hB`qfNb^+K0eD=>FJXd;B{gqzF%5>DLf@lxlg$ejY%%BE(&pebnnr}Fg4nf zHd@8Ra0|u>ZV=QGuuhi6P`A#FyTAO0n03y@RD`dXtVx6!?l@)lY|eC~Ssk`lHni9F zDipOpyDmP;d&Fkd?PyAG(>7j6tYhT-D$2D|%X?Q;XlFK+rw8>${h3YqeZ1Nnc4p{> z@h$h%*S)UAt{xwuL{FUVnI{>)SV{{-rv45~Na3VWaaL4p`U)f<&PTOGCX7_j>oxB& zZ7|_WkqKnz6{`h<>j+`U4NJECpob-j&%w zgnI=3hP92%gWEN10ABSiD3w5}`6K5(5xQD4KDn4cWMA*?6)(_R=+!omD{82G_A`$I zh%3o59VKrg^>{o)=q})gYn*dDmLeVoG0e+c?|=sdw{gpGzm)LUvW)p0#xOqK(5tq} z8b2T-%<;U_mPYS)Y8<#rlCuf{y+lARI_ifB;#<60Ei$rV1T^eG>MENyl~&m#HKZ*d zD)r7|MWc{Ep3*sUE5l`T2t24crMR>ftvZ_vzWk%R^fTWo+@j}_h4;A&HyL~Cr>VK> zNqBjAN$nSC7qM)#R^$z*hs$$3NX#3QWgXQA=RxkC8*||mT1@64vyJv}>)imbqkU2@KLdWWS$!j#XPXHt)3kVoI zC1iZdwK%`ZY`l(79c+~md&}hCdq~^$FBSmE3I=3f>lvMHzE8tf!J;Evw-gz25O?9KLsWh<&dd@r>yh$eNDfrH~Y zP8lahQ(Q3z)J-OCv9AC}m3)3RS4HsDFCD;RnzA3Epa2vc(+m}K+{wtuD7z>yP6ZH5r`18Ok5!=(G8mrFEElZ9>s=J6Fc# z2R!HHHm)95GUKlqz6OLP*on_aox`{BVgLxDndEY-YCGLLR-+r+whXm4XLM#23VHJ@ zU^-L*ClwO)I2V8%+vZMy#w+`!!3v+AgADU<6ge>z!fN%MuJzSsXa<#|MQWcGwK|TN zQAaT(%}Gbz@wHXx@+$1y_zoGlg?D&95V)G7(+)SH8Tj3--=o4N`7HK3=j9>L+Sa(y z+mL`=o1?%^iQON$tv)gj(S*1F&gWD#(gsT@^C7gQR8r^QKW)M0MlFK97~ zeXcFJ;bijM!ouQd;e!H$@69}TpeZIcT#5>jk?jy}_BV0Ik#W>s;GQ@?_eO!(^k@D< zsbthj-39I${^#fL0A~B9+-`KBhGxYgJh(_(bg*pqJ-Z;H^|=3<`PtX&y{rz=`S#lk z_)puj)B;*3B&3Gdca{gGb|4+~q!{Te#%g8fshCZ%y#loX_T}Vt4%9E62Xhez^HUGs z1R{^m#P8!n{WL3ZB>KRg41ghZg{Mjm4k6J>JDA+@p%$;_givoN5xJlvLSR8GL9u5-tg-%`fDE(_O#{Lm ztSAm*MS%RANOAz$v)^@H%>9A4^Lyq?i) z8M5MNrgSCpZstdHX2ha>@mylJFU*}YXtl0%DPMjg)y~dx_W-~)&ow(i=0X_+3E(qB4#=13;?ma3i$nTG4|ysGbzj=MYJJZ=AgpAJ}S`6X5U$ zQzUs4(~iGsXlZH5DJhd<5SrE%K*vOvM*ypwNUb#_K5&r!SPHq>Ztg!!o5*)eMm)ab zBRd2lL^6^fcKo!^4K4-|%de+doLa#Rbd`5hqZ+0fn!}W0?PM++xb5>WL;;+D8~4NFiTG!4irJ}vMvK4Kd+vrG=3 zvY!PGab5CuBOjr<-jx-l*EXP#3KB3MK&Pv&2m`(MQXip04+0YXY3MiGS@9*UMG&@K zL336Hogl%NV*Hd|j_8XK9ql_OE{lCh_b=C9(l?Ro68!y*bHThBN&{fGkz%^cs+;X8 zf=A7)rcApj8;r65*2bkohDzAr+LfAe@-xcEbMA%NT1 zZ5;KGS`4%vrm@2u66X?mHnYJ{F%6dnbUo$NgZ(WSXAF5(!sSK6ySDUST+Milu97DI z0lhwPiSG-0nB+Aqg98Kuuh&}n(=0+#F5wVN1g!}seJ^?Ry5O|NH%{yqMW#`cZ-WhY z+IM+jeCTs;vD-scxiXy zia|*;-ry3dIMKdw>R7w(bBWy4|yfw zI%VMqJ4b!5wT)c6%!=ev8#@<+*F76*=iTQJF+O;Smy16|xWz;VD@jrACBO&B=4xHs zAhC${+FCI8M?G*(&nIi)T%aTEFlBF@_vgG}(cfUp%H{a0NYVeiE8YPM&5Yj=k-LSi zCpUR4_m#-v0ot3DZ1BAuI5NM@uW+|8w90S8crFGg0aX!=ku^{mlkRwF6>-9owTx5l zz+eG!GZ8O|2<;UcQ9Jf0`ew>QFAn5(+E+?1YT$(z?xc*RT(?3p{Msk5Bk+odR$>1b zp9w={3@*eC0h{(fzuQc_{+O8V}<-51m>yhZ>z~c{4_8F1F_BY0^Be@+;N`K=V(kNy%9_ z{-qm*r1x|g@Ht8QQQ$3@mQ~kh-)Wr0;5~1n`aJBZNm!v%qicF#q{G*QwrN&YF0Rwp zYaN>r2S9}?2PzKZ#IU0bPzKs7N%>-)W*)OlC{-P?>gvc1argDIvw&}#1KBRrdb=M> z$Y4R7s3FRrOU7ix!y~sHK6dS}x>_axtd~uh3X!!1Lp@V1sp|QgI9o&pU^QfOQks(9 zbVX&=RXP->_((M~gwjGFa)$cvNV+#ZPtD5v2lyyjTU02UJYNzl|7t3R0B3M65&32- z9oJ`8AXJ1x1e}N?qV@dw5y2kNTV3T(BO*4$55IbO-<>u^5aD^d6C|&VKuZ>6VNvI2 zT1H_H9+}E2w4uq|)UH|ZGnA|kS{VOO-oNOY>5Q}>0^2owExWjOUN1KSwZV^GwO+milHa*);tZtz>kBh|_E+jASo%*P@6e8Te1)kT5<$x)GAILeT*0s?xO1|I-8&g` zNaw~WrPNz}V6Kw0VO?6Iw#MB_DWF>7JH8^pS#avf&h5irO8ipnYMs?9$pw3Fw{ymW z0d)t?Qa!nINxkxmb9oLfhiqxP{wxFUm*p~L@H2#RIdHNSNuL`2;0*JS(&=5O& z7p-k=wq&HFcgG?)L@R9hfl>xRp6y9bUF0LC*92sh8a4b*y6u%F4r#^=7C@GYf4YN7 zpr-u|C~e>JkO6x@UvDxiBsh5Ebx9*wEsZtbxehA9b&c|VBVKwu;!GeodyL=g)*BcO zDvwvm@iJ=3?0@n@7JzaN>^7z=LCoy1rC)4nQVHN+qYcGYBbW4=tH4#8s|WoP`G4tx zNcun;FBelU)axOl9J4`LvSe+SDCA>bChxkdFwXTvMF6470+Hwke}Dg=|3#wF#~|2M z^L5Up7|{n>a_Kfjn*$%DSV zyIw#T4hX8dyjvez>U?Y559)A*08j~1AB7TWimv>JDW7Wh`jii~R{ zikq6w%*Uf*%Ku;sbEv`9IykxI%X$I(_y1lUl0BR`V~72-oId|#wzBQrmq{)A3Cfry zt-1IdsuOp5M`PxRK`*2#rhsksd&pYY3rRn-242NeU;Q<;ghyZGxx~-p;y9&!wIeYN z7Z04rM52CIOMN+XKX$vz)ftQ2s$1-?Y{=p3IAKdoH>vehRyfdVpO|IF=+ z$cyXb2Nhh0zmvKACZpZKCCe|)FPxejx%rcyX_P|%fB%0Kp*lz7USqwatkuFXO?1`=+km}H~Xek^O|9N{yX^wAgZEbaAFj$;=@LV|s zNX?W8;Q_Br`Q&KNuYGdT%vJlZ^kXIz#8CjHlG_FvF7y;joa7Lc9OYb-K>}9Cu7TfW zbzoKOV_&ZY^-&!0Gqt4$XD37yw6qEFF;eWbq_0jCrR=FN=@cTq@A_Fz-%hbms;9rw z`ht>K56;vcERbwc9juv59&~8j&)ST&)JPxkN5(yt;ol2ld(!NsmgFqa#vH3JNtsM1E+?c_ex$k--z^wiYRAgP^YL_5kSl4RzwxH4hJ)GnW~%iQ zpPg(MD&eP7vxnbCv$Y&Zm||Kz%3j0Zi~U*eZaPfXxU2q==quJ%OIjMb^n}VXM)&INFWKJ%vbpl9O+Ss-7j0Tz^QbIttJj=VSTQk?c%ph~`PBWvNbfNY?YBWP zy(+Z3K|EKRl3vS-#af}n199|pKr7eQ@MTJFWK+c3^icGb67 zV(HkW-Oz1YW8r%a-O;peo%j#3zsJ|~eouJyv75ITm05YBW?)NydfX*W`%NT@)t@M7 z@Vs|MXcMc=dKJZ{)1=3cGI5DdJGLnvrc^sV3F-zFZf zr7<6eAG`f>__+P_b-3L@Y`ubO%qFI!2}fzLQL9W~ry9c^Ii>x`{r(rCi09ENV^nzjDuw_B@{_*SZND0xljoXGD4 zsLc9xgf-Ld4N3MgQ{RJ``hZ%cZ}+-u(>lW43wpz}?jdTtC63#;zj+1M#&w=yUDC?# zOwgPRm&=sc2rd4^2H#*i`p{82O4L2RE&@wqJTx*6DWuFozyJ)Uw(;@jH$O!l72c5PGImf+pT3vj?#u9uG`0)k?cP&n~hQkBJ=_u1urUZ*oO9hBYOeY1&-w-Jy+peDJB0tRatWzhq=w zG3R4y&3@E_6^4t7z1COmY(04~VB(BtFB6;}`8JBn{4@Kyc5C3>Dru)_zBYbwaaf@y zz$LN9@R7b>D}++)#s2n_nT)Nyz3XE7<^3JMDB;XsIb?j)^r>^7$SI;R@ByL6OEP{3 zwcCkJddxmGlR^}j+>CGCod7p?ul5FLzEjuM=XNONWPPgsP9U!7!AjY^JjP!B8B%OU70RaJV3{9?f z+F-w1p#;=b>>0?PDF8k!PBr2Zj3w%UgX{92k6B zj)F-o^V?*1kyXOy%gd`;Fg&(?bUW8^oj5K%P+nT#8!Ils zevbgap!6>ZqLVnl%zN^>%g3{jut=}KK!Yx?9ni}x4sbS`E zqV}m-F`<;?tTRQXHVNB?47_Cz(ob1=x{@w*cH0d#wCA@@hWhO=?)4=&Zqu3B2+hLu z$j$&mKT#IcGu@w{vB1uiRBw3w%W8?EuF5k%MVqY^l)wdcY?<>&SZibQEzbC^#$ip3 zivf3;xZ`$38RO|q6km8g9t)s>lLhc6-w7Q zoPPEUcQ{*w0@6eEkGB7G9n-=qKo}bDAj7&iG~CZvHnRYUS-ms*=W2W-*e=pgAD zQ!u=l^PKGhAI#~A81J$U=(ibodhln3$x1*{M5AXZMSeN?LsDjaUb@a5)>(R4}qW_0hD5sLdl>Vz(@gC zHUD7!H0ZcaJ}>!%&k~le=u}9dIV!VrCx-1xudTY}(WPbvg|hY(w3?MC;0oxh+0 zOKgLyNjGO;!X|PrCKQjy!j%=JE*y81d*8z>)%0CjkV}=1v2@tP+$h@4)v(c3x_08+ z4~oN5A)3dCFwXY^#m8!%SB3Okz#dH2L4pzaRSG>b5_Zz_+X;y*^BIRtQ)? zyga@z?u)V!adFmPH#^?XS-eh`JaS~i|1j~#q0Nj;?F$i&%2iqZs{;1XPvf{__~rAH zyiy{MbZ(K#JM_%)1`v69qD>^uf&}V|23zeu+1>IHG83!2ejaM4JCx1{K)&!MAkls5 z8*x&{Js$$R>>s|qz80Gg%LcN5B{x4dgDhb}+%=QK&!F63gIU~X)L+(tc^e0~E)R@P zGCZ5^2^!zKPL?$tXo0&|kJ72V{pt?J zMq(BBgE(npN!a`6B&xjNmKAjuP~f>i)44=%@b!n*%__LE!gaB`7K-1t z@#$$30&;MK%IG{*clLP4hkIxDV@RftD0Z@z{D1cN{+ednosN1sw%f;#&82qG?gZtOg~WaRX_nTS#}&)1;~$$hw|VF>r==mKsN{31=OvO8lVr~!!P=+e-?Ca zEEs&6vS@Zzx+@OBRixIrXo9HWIt5hPIm8l%_PWyBwmNFzw7GQ7xhH(tG%c5z%Qfxb zD0w(U`Q(Mr_Dr$*;5X?4M`^8{@AlQNYX(ee91m*Q7-qhCYdwmg88x+D);B;0AIYF& zp%7}vRFfOqfthl*sFjDKBJR^G}!|n%maYr&9DWk4?DdWd9RVtDhDqk z_X)<`;~rlN8NN(=>i9o&B2R?b!Nmzh)_;6ENd zmL0B^obC}9*3Ay5_Wc-6!W`~2<{3asP?Kqk$uW5d>_wuB1@wCUlamwm@kSrn1R!kQ z9uY?|kf&b&z9WhZgn_}(IZ)`F0m!N|kZ$WK3bww)|05|E%aDX!ef2etptq4#gX(zk zR$UO(uCw0nO#+eV6B#FI4qXs3O};+m^!)JGUHGf9o(t_FgoeMxqlBI@Qo^;h_JG*P zZYOYjX#iMN5j1LXxx6I1P5F24{HsrNANDQ*WB|Hs6?EIJ8C~9E=AxscEkF_5;f~J- z(+n`ne{Kxq6$#k}j~?4kTycSs^NT=jfA7zqKQpiSuKqiOp#Psmkh;;?-aeX}Vscr- zRDt?qRwGC4rvL)To-`q< zbLXxy(9uOZlIb3deZkWZl(PP>*|3?m%^^&xi&)fZ$N9JZ;DcB6MhjOg|7Qp#Um~=t zCzGLe=5}D{2PUtm|5vlVUsoe**%Lig{Zrhs=xds+6p$qRzNn$9+Iem~ih=XPHv9jx zwrUq;drAN^2L}fiOJ?af2p9#cHSS@kIK3{4Ood??xVYBV=jU1CJ9TWF|NHOzso+@^ zq@IjS@9Q)tAO!jNvNZ4C#~<&r*9~O;_Z>Ms1n;P(w(BHwdaT7EIq440BlkgTmr{OdMd2hkWWnGgvT zH)2hb@27x;yJ_>>VVmFvuQ##0Q8!y>y6~8Yfq{|Xqj6VyJ}h?X<(Ovt%2P$3r*nHp z$Jqz1G%^^38eUDvhl01>A$e|QQ}`1D5tM|SjtAl2j6~pH(2_Hf%SkR=VGd&%UEPg4 z>kw+LiiP}dNQnvH$~?Fn|ERSSKr-KbcSvo{uo-fmvfb1On+-yRGzKmx3I=Miu}KID@67{z;*0eYqzMD~YH7 zXDB6%B<&WWJLKwyJKnH(us1)i)~rxpG^c+t%A$J#^Uq&8J_1i&eu`YLX->z+I5%=d z+)X*~KCPI)DwO{35N2p#k72krLk|5AEUmW4;TE~OW`DiB9%m2#|7Jx_xBqY|SBdOe zKn6v4$BdPpo{2})_42Oeg#X=Qp|<&ZAad}69(TY^lA9^tK3hs04C5wt`To5eUE3@w Yq-4INjgJ_x8*%bR%63NVkLt2#lz-f`Bk|mvlGGs2~bRNh2U7-7PWF4T5yT(4}3kac^mC~!B34?rRj>y;p2bDs-pC4M8Gy~M8J-`x8(7ZC4)wd{ZvA?c6No< z2?2k$M%7uEBFjtGsZ-0F^nJ~tBkwsWxAnm$uf17`q4iNtk;CSp1HbvCQ@MGhhbyN0=UV%RI}=tzY0{cYt-)$>TrXL> zmfGI8Nmree5@h>f17Bg;o+y=V^w=KnSBPYmjsxB`2K>SF$a81X_J;Z!S>j%;A@JY z1Q=E$1Kk=-ct^X$K%zt~UFJCzL=%>3RPe6@L`h}}4L5jf_i0YV{`0mU zJVJnDL;yw>G`Cu#aW_F^3k4l6M%eS6Auxy$0?G2J!JqB)7JjlRCCs7W(YZN@S7Y z_Y*Ew1G_z6w-myVrlsQyGTUS?fG1KSs%)bD4+q3cxuGFSCcE1I z8emZs8!$^ljb8O@c9nR({DZ$cNY7p7xvQ5XW;d=Ej24{+G5zypRCpe|FP{IjqpK_3 z>*jpjx_xy!`4uWp-DIIT;9x{Wa90N}{NwJh(m(Tvx=$Gz7N$ZgY@yhRC@RsQ3N^!? zu5l>zfn<3HxxfC$fbFRe0@VH5oQ4ed0>BF-=N^8k`6p5~Ux96UOP7YLwCXF6RB+z$m$3f*x!dgQy(?4YwZ*PK_)rw>RJ2cP3x{ z_3y68y9t@k!aiPJ|2j&aZQ7G$5Ve8v>(_i9$x-3-(qA5WJ0`veX7yfj8} z$eZqe@FAQ|M1DT#HlQblU8Ul1w$3H%SCQ^0+%i}7CbAvZ_lp<0i`h?gd1XZt`n2c8 zbQgBZ%|#)jj6b5JVT&h8(xU*}O2Q-=dU z4-?4$cuYs-aBbj;jQwkm7mjiSs2=WYS)KpVNbBN@U(oO7i@4MLs5{+#vv=-$vs2;XUV8@TN26-1 zfd9lz82LSC_Fe?%YkvDgL@NZxA!X)U|KgQK#3ZTpdaQsQNM2%OufED*Z;pP8Oj?+6 zYT=LLc|~EoU3WaLKhSu(Gj*@tbu|Xq-pT$IV80Wt&JR=e-2|_N<$*Lg;N8FS^*uAe z>qlN+=RH0#OY1o{pIc#J_M0zD=t=<>!RZY;U!~a`FHZSMtioc~a<&{cG(1tge32sV zma)fQ*7p#T^mK@VUHR-vCjKSty|m@^kzI>Xy=zW6*Zyq1X7lBqROPq+u|R2uY0>k8 zKEWK@(cFUxG~eF% zx!oSD_F*TiUL0>*0$zl3!=aYOhfPTRxlgcV7EP|*`7%o$e_VktY`^jF#j;0&p=Z*p z`{?t7evu*Cx@F6-RfivMuw#ILf9mkSei8=cnRw20{}BWO>Z^`%z!-9AB~n%Z+0maQ zLW~w7frmV!umd(`o*M{5;X|{u{*>bv$)cO#9`^H%x-u6V_poHtq>n#?=VWir+K}9K ztCw)v#e;dj{iJFWmLl!qWRxXLIA_Jsdnq_@qQ}74XO#+T8a?u?S67pt)C7~1XX=RuaD=}rN8Eu8rHz*w8#`Y^-hu@Eu(=@h zkE9-%qe|M+Z}#p(_75>?*5jdTQk^4;Q+fX|mZ!cx+gNURqOR7^Cs6_s!8N}C?^toI}g?ywIr z+-3IeJO_2)5)F=KCdiq%21OsO|8pqhLC7^>WO(hxV@-aiqigTJQx`I=_rz2}&G@lS zkV^E9ZQs%Z^_;iO#(uoPvNyfo?qJU#_?*u(+_d!GZ)jn3t?BN8UO5P2f;YiQ*4;PN z3MNzh4Jxso*}%f9ayB!?KIK6sa;h<>ZYP8% zdL!#*W<4P9;G8fOw+Z5m25Mn60UlJZxVeOvHtLVK(}n5YPNW~{cGvXgwM@KhX~~J* z_?}+W&(Z5-QgWNs2Wx{5AKk0l;ivUGP4bJ;Q_#5JJbrXON;iB=wSnoA+zbdAqo6I9 z^^=VHH_kx>Y`7@IOXnf8q#qxjeJ=B`K5$)KWyXUp6RhYh66$OKC(i(#q|tQh3S_VB zXpyyJ6_>X8cPrtVH9Vuq@#1KcUlQ^ez+4ZhF|<0J1(W$2jx$UA!(FsQ%G!O_4- zOnbMx0{l$rF$~>du(G@yZW-a{gCjB2-E1BKC9p*hmp3%TqqE1OKi?=l&XE05ZhXBX3P&8?9b0y$ zAN}xq0Y}LoLUc9Y9g$_o1=V#*=m6eQqR*EGVpR|Kqg6>`c;%SR;Jy<6_1gF9><>p? zi1j;Cl1GvKNln(Wy>YzOX<)tqkQlWk4J20Yz3g@Ql`o4B*%y@I9>YWD44*yc?}sQX zt`{XTwQ?p;Z;v)j{)-^MW+1m7_5`-HoXU@;_2A?(vIEx6X;d8kHqGLi-e)8$A6pHW z5o+s9O$=h4d`BZ&BE6lqn)6~ou;r>k!rZF#UKEIzUR|MW8p3B%e(-=nA}lV#56QVr z!X)Eg2d2npUbBSzr^t~H&xJExHn#n}$ zjcMd4Q4diBT z$r^(7Gs&gg%-pA%IP}>qCK*UA1e-(u6&G>^a91+gf*;<|=1ohBEh&T8UIGF#tnl;G zg`iu9!GS+w^{0c9+k9@3eoStx@RiAO^G;!mJhtC@U)|Aa;gU8~d-H8b@b6T&K_%Co zoAIUj_Qs6~DZz30$2;Rtf9w$mU1VU4-Zv?di{%Gh1bvUnW597n0dsya$>Q;bi-{sW zj_My;_A8yjZN*5RV)+rfee|}yw+a16YLper;VrDGnz5+ zU$v2~hf;iOQovcjln1$A0$i8Foyr8%{@&tIHh(Y4)1FV)V_#CK-8kYHUwXel*)%;H!?wMNwKq*VlwsepnjrG;)-&tNjnSr@Jw5DcC8q4@D13;euYgHRUrWa0$p%;=a?(9MczF zC0+D3gWMHQW4_e9>r*a=&}MMxi<*efLTq5px_5b|e#RMYk-^(HDD>;OJ9~}Wod`r^ z$&dGtKAFoGxh)eSu^<1fCPcZ&@bTD)dmU=$tVUYB-Ae1}C$F4=5>w0vUkQ8pIfyCT zirSIuu|hhU@%*BDt}{qW;Ojej^9J&g`Eo@)rfv^7?0mU#Q~PS*OBKJ?In0T9({woO zH6P}{?T+dS#%w)UI z321nbWchtVp`G%aTe~r!RK}QWvWin|$x}p~06AnO-HC#5`={8M`eKgJ3KitI=kLDf zy@VN%DaPRx$zTTBTAx6S^`|3%`+4`h7UrIm^V$I_#hb_QH`7fZBG|jJPncg-PR-}? zWvU3FIc+n!ryj$uxP^MX6<|_HhV0qbq13V!!PPtlHa_~6B>m{@`=$T-2f{l zV%a_~(8_n6_CRNq{+TG&w=RfOO%(cpX1pHhrom?o2 z=n^do(hjOJEiIdMxjQZg8VY<~0zZi|2(x*zCzHWEA*inG>IhG`igX-&w#TiJ9UA4G z@^s`xrXZ+JTVriN1na5B%Mky!zgF4nMUb0zhV#Y`Vj{h^#|It-fp~^EaxQ@C&Ppav zh-0XvxNyfVvh5FH5g9GXtE?imU^LeZ*_Tf|Q9r2gaG_?l_s)f=SV0n?_wNP~(I2V# zUl*a!IzX-0ufia{^ah)-UxkhqWKtwWOCuc5nu4Skw*z1pV%YgM?gr=)il=kQ7xtb; z#`%5qHc$zO1MX9*uxz?W8pVYu%Q&a|jgz`WjZKSUT(d0AB1&xeQ=it$i1?Mah|*8E z@8#y<`0JXhlLvgu}4Z==~}5-^9wrdQ%zilIB1HJ0994F6*5 zWbIBxD5N}aQ1yYM3GME}ygR6L61RjzVPv7zr}uGAMH2ka50Zkgj@iEBaG<X4NI0C}>09`lfcnLn~nki)x1V_HGsml0$aX7e^Z}EwbFbvw4)kG4O(DDat zNRJGO`)J2a7lKWo2+p%_yRhopJAVt$n4U-lt;1EH3k0Ew(Aq;oKv-HywWWYwo*0+dz z9^NPmV>i~bH;JDXp};?Tw) zdi+7r0tp@d@rrQPh3S++f@sqDBs?8#e4 zC)QJ!A1lo{i^!lB?`OU76~D-zMXR9Wti*O zEV4xK4IVGl3i*7Ty#Vqv2Yt<2(Y^4w6^uF|VxVT6ZEaNj5QvRIX5!xUSEuIJvnbN3 z(<_(!(d5!7)b^uqTyjq6Uc_y zeXLFpTaX*;0P(3yO~fVMYm+%-mLOg`yDAx!+ZgZ4 zALl}%Xr%VUGd?6#5TZc%k8zNc18Q&olD1EeThK(>aQgcFvYkIcwfAKWI<@Zvb|T;ui8;oN{AFGIT0>O8G2KSPr19Ed z-E7+*P>^IchK^8P!7ozIXk&f9+Q2w!L;Agn=r2aq#hovbvIkaCCj@_ z+9>aWv-r~-jVn`(U*z@2>`&R-o5NqGin`2O?qD?TQ;V-H9ST|OWN26b9)7mc zu&S=$!73PqiNi_`Y}vsJ1lk0o|Lpn3uD_reVZ6y)HlCzj7kkBZXtE3-5I% zLn^gPVx`~G=Nu6kYY1lpkosrQS+dX^hn>lCvmvG!OhUokI9{Cx=lgk`kE`)x$YO&? z!idKt6*-=lGy+I59V}Y|*H#+Ik;40_iVt%U78WLw|0K^&#e?vIeS&eE`+)F3gyN;& zWAs|q$~s1jjYX{5rbp-f*n38oqjd+&@u8T&L^M{UtNUNn+C-^dJcfRB*41+3XPt|A zEIOHo4oO5Mf)F|1LZr-eSK~(Q%+`;xd2?{y_4$+hz=21L=CKYu#$vV~<&R=(=5S)( zW=j&Or%-y^`sj>K=}UQC4A1)`Q8p_Mah9I+o(OLMn!ijHPZm-;$$1t=eXtxRnC$9~ z31-`8zO6Zq?FkAUi?48HOE?iTE^WrpV|?k|GLs25eTIYCMt2C^Fn(J4UyGRWdzCsP z_Aug@w~!(1<200gOmOT3nGKsDj9Tu5?n{wX^T~6dmvY1U?T;@dmo8`WcWgGG- zpX6uC6-y%ki^sx3j{e1kp(gjUEeuf*?C?uk1Q;)G_VI|h{^NF;L;$Q5g2{W3>|syR zk_xrGfg*(!^kW9*6>O!9S7H{E?YLd!<;)7aLG*PL=i*V&aEM`lL_Nd?od66U(AfyKg7xhYmf<;L8n*S&_YVz$oP^@^J z5p@siv)c+Iw*vmzA_zKt;8V2FlwMjsG7?!DaQI5?VQSC}C8RCi@$*qJkftKk@xmL| zBs1kQE{RMcGIwZywZy$JDNzNuPSA;D<}^O;a8R+}i@ zt`1WP9iSzYQT9MV#W-rW=jK1LvvCxq9#inIjWU@@1N1k z@ju+3`>sPk&6j9{4*-hIprMm1PBNQIH^XCX@nHD13bQLVCFF^KZ3Pn#l!G_gh)f<^ zxPhI_7A(dml3Ll;6e>l&O;63q_ZY6O0l?n$Iwirxd?+|wzzd*I2N7wrp|Qf4%4~n! zSI5H?(KYP%lPUv+qKb+s4FYCHHxKPy?=U+;D%cLTBzAT)XHVh zo-&S$6xks1z3UGuI5R*KX%iajdP!vmAa$tl;tAFjlF*Q0eG9b@_UeYL?Pm$luJ?|Z`5Th40JIQAC|G{3O|0fNRo8e{+Rqy2>iw19K)@tspP zYb@}CHPT6nb~FB00K$r5JTbUeV(VgzgIFot>yr5} zIwr<@pDsd?(c(@`yF$s2 zbeW*mQZvRTwn=KP%U=M-DNH5BJ((gJO~)TCPWv}Cdlfx_rN_Lry$z%wvZRk_x8;K3 zRNnJd%liwKHpQT+O5|q0QFHCIoYUK^*g5IN!4+`S?SsOxvzMo_=VM;qbh5`0qj*zA z+FvO-hZ6^)2^1Hu_$VXFZRYFEen1v!C$`?O6VY-~k$}19{StY{pYr*6HhX>ovcX&e ze0;^JdESpd)Z9h2A768JhH^JG@UPYTL3z&+7vSV#D)@WsZ3!#$lIy6G6@1pq_V80a`ki@ zdinYyoEqMsSGpqUG)4GzN@h17FXSbf%Ll^;4}PmCe@-aPjYt2IPQyLfyZwDvP!xN0PS}0Et{@&|C5nfM5`6EbWYGKAl4KzS z4B4lNes;s$?3{*w<+e?|sowM^+^9-!@c7VlWAf*{krHJeTUm=#3+Zk9&4tWnqLf=7 z#aT)}uWR-;NznwS_^aBh_-h5F;I6I2(C-7=6N=4{;H$xb*VG#xOBdL8C$eHOkM{k2 zDhzc*pz1TtuYK~zDq?3fn`+MI_fvxIOMddcRjDsCS!&PEa5^N&iOBUoSZKDaq~!H5 ztk7Id)%Gt|z$D2$v7EOv$L#TlW&h&8&CbEI)Wo||dp?*SEf@t4Ga1?sc6IVU?l>2g zQFjseq$LvVNUNhLTFmc2si<;2iVYo1zb$bOXpRV{eW0YA(ERE}>O+D3=F|9a23fha z!E@CEgD7z`sng5-mY(P=h3rX79p%1p;v8E8hWgxJ$K(vMi6~)uC`GYVR$FKV!5!!x z75R(sShL)8FXK!wL|?|e(4AIBiGaGvpvE4-sWa!UA{049cM4MDRQvLIx>!=>Bvrz4 z&WktOZ;ofgt=GQ(=Hz>hPAq4(cHs-xRgYV?_s0{ECIPnClb=27gjPKaZ~gkZN#hw* z)*=`D*}vGya9Q#^;`?KsOJAqo?A)xnHS;Q@C4#zx)>4FQpzxuq3pidx*QXVkga)MN|5ycwfCphecgg9aqe@N8FkrIzRgl zELlt=f>NxGpodd|QkXnF8;?aDOATA%)Lx6n&DC!Ez%*WqjT>K7akIgBB8DruN)*#( zp7xbCQdATzUScACAc^qe4j_B?xPi_+8$7r>T`j`CX}?Mm^SqKHGkFfrj%~eQtIyE$HhP z(V_)|k2HeZvNv^llJ2hs^lKfX3tpuOO{@&(=q5D*9X0cKMo8o_cSuk z#zwMq6sDRko#@1tJ?fW2gu%wO2Pvx+K?_DxCznnK2N`KGoN6+3m%S;jt8qHdeD@*D zf?1C}%l1%vspV#Xrm)f{Fqb#;o_D-esoF7+Au5!2G0BcJMoh2Y*P~Qn6#@RhYQE$LQ?pMB#|kPR%@-B(B}y(;ZGVjCT6ObxN)F$b zz16C@I?7^{EK{4OpVp!G2vGVM*QhPuSu467WV%emt$U#@;cwE?C~?G|B(g~*k|0pp zXzK2kQhm@=;hkgPY#Qj}_cTcNaBTfxTTPZeqc2W8J$!pgcTn=u-lxK0V$|J6%BHC3 z!tBHBA4RdvQ&q!rhc?Ol*|K`k@cnyTk<8Jy_i%fq%tI76zwamDeDUjL?@;NDeuA6h z(IJ(6xWVnJ+haGNwQ;*8T-(D$s)K)aDiK8}A_;}yvT?0F8+zaRm*%jcKl06lE?ZSU zo6oVauv=e2l1hdx%Jbb33*tI7dDR;v0Z~eVWJlqISoD6*xyQ*YTlpabYwGf|fqCE0 zX!?*5E6=p2bl+;Cv!dt+A8_82pxl(LCsn@bJbr}=Ht_HGNF`Dm#Tn)Q>4DN2KpIqC zwoM+OQ+o4yaJT*(TeIN>di*~}rErX;iE@|I%K2as=8HF5wP|g8<^DYBc&{sPu4Jah zA^Kz7-e;Ny(x{5sS(Yq$(wMvB{(}4c2)=axi?8k*lLph(yBs=3x*Ex{huPrTgbSkB zg}}>Kooci!`-4}C&1bGk@Ckn13PsPIE6qLbTV%VJ9e>>200ZX0I%Tcz?|`hoOtN`>wC2@CO19HsL$2}c4MT>$U!`*vr?y;&>v`pTC0-ercL*C~thUeaEN#u~_|g4Pu`R?SOItbEJUZpxf2S zTPezJ+j+aP*%K4XBr((MMk&ucaKpBvpfz6voYG+?H{DY4`@{NLUk7fT`jD%}3n`zk zfnuBD*H0wY8xJkjXTIeqXIW>rKd(*o{L?&`1jBoAHgAcw3j$=QpDb{+SM@s8pLaN@> z(7(IpcP!Zmo0#`Za3R!ZQceg`mz?m28wKv0pF3_U2s>av<{nK~$qeDIj&^n=vP~0= zDweZIEvEBO5F6&%+KK*&>MPR-gJzrNDu%1q!-5LNq`LC&;UJLna*lF<(F_vjpav}6 zXkSiX#@$}=G!FmZIJzO2!kNu^Z??Wt$yN?xHG)$2B&o}O!OuUu9YREBwuf~=%K*dN zg6>lD=>Kf<7ors(L=*nN30G^NDEJa(*0JCZbmZ}y;<1G#4IJuCqnL&u7NO^z zpV~8S4xl(T_(aE)ksrGC>u1!8?(*On2>Ue@UAafQu#D8)9K^Oyl-R(W50Et2D#l-G z{;XLSwp{fiI&cPVw5D~qozU;xoUYT01)r=5#0knK-g6?}w;rsxZg7lnF^90<@%8vK zqqd$*s&tt4mSU)cN!C{@e$Y=r#@{Zc=+-fquC_hGGMq539%L}KqL(7#TK9-_XNo_; z*sY0C#v9&wyuqbo;FtAC<8*Vhgki2aV(5>8f0@DHV7#A12U9mspY9RA zdJn*`_#lNk`Vu$=<@aN+Ci9p2@d*!)jmz7AALMunAd&i?Dmy?#)ci5`uq@afbb54! z-QhLNn9%hSTJ5HPV9y1d)Z!Ts!~rpaEG}#GK@sbV6rcagN~%{(iHM4xRiNABoR+s#8y7x zh9bpz-bE25zrNRhCyXDzTz4B_oqC7Z{USuw%rYPe6~R78YB$`;yc<*gW`ieGcRC>l zSSYwbFI$wnTT$0eLUHQy+!NzVjXG!3N-I#DH50l`qesGnC#8%Np}foJAR)a*TU0HY zxbQ9SJ-o=Hdh5~7;m!g;%H#?rH0HU(@#(X$rDH-@!Nh%fMrq%tuVr;#`kv78wOrTe zmQhl4KgOC(^WCy_`!s~zKh%Pt81@i=0y#VUSK*A-5ESPSgY8M`IF5;t;LN6g#BR&x zC;9TD48rtjRTh7$KZYT-epm2jzm5%(i8d3%>PNy&tmiT1-v-G0CWn3cvit6krh!p@ zH`6S{PT!S{ZnrqkF>|%ViQp)-y6ZK_sp{I#v(KkqQ0TU^quytZo{nyzx9)v84~hMl zdcgx*+d-(Sk>j$8A$C}T!*gRs8`yBu;KJGbVnU9abuuhGdFVzTKhwk9{Mdp|hlbE9 zW#ZZ-#Noi-*eCCW`O35hgZ0tIVf-a?bX+>0Xa?}w0mK2valkx+8X&(#+vq;SrGcF8 z&d1?R&D7cplWjN*HH#WlSPlsgep8bnhRjJ^5+301=&T+UwwmA*Se31#&slK}8s%E@TttJ-o7_`qAXB7! z*p5>)7q|tw_pU1yY@!5>We!E8LRvh0*CSP!2doB?Ez`(h6l7M$JIrQ?gIYlhF-Btf z3I@aD(kKqD@Me4liki~ty>@YoIR;(ZEKB3u88Mbovj);9$Z*d0Rkn69jz-h8EV-ZP z;NhI+5>C?9G~c=FxomI~|AxyavQwdW^zrrto8DgC5VklC#ITO=ND}B3$t36Q+l0VR zRbg(}Hy3)(R-<(EXzPn+{b%ClPX%sv$#z*I$!i1xC^DG^i& zdz4zDV67t?kg;O@CGC={?n)X7)F1Ge$ElRuU0jbGV93!8PQe_PiYx9l(s0Oti~}F) z%rnm~AgXX`9RNlmi0|{Bc;QGC??}A)l<}_i&p9bCHb^;Pj1gXc zz|ylfV-$9lL!Dyb+v5yHZ?s*!Ztsls={C(U7g?ZB>bI!Ew@>p=h6n|0GlsS{2_XvZ zj@$wBshllN7gGq^_XEaO8tWFlsk#q}4f(MJ>ieNF{XV;KqcAe*OVPqR72OWsS?HJ` zF6jrY)nXRK0w8i^upQNQg8oQEf+(o_mRmu->_;$-k+-}$Ry-q&ke7Uza>FB4t=(he z4fPnSJvK3#k_>J5k(YiVw^)ks5ybUo4L~Brg@mlX4qQ$op-J^G!qe}k`5C*CB^m_H zr)O0br}w1}r-(#07V-~+A0fH6JsGsM4ayzKKF~mZe)Busli6R{XI%Ug2+&r9%WPE2 zunACg2`t?g6?0Y795Ow>HQs-b`#i{S-f#VmZk3JE zBy6}L{;q$9#?ygX?q{X${v1ND$P@>Zd(Yl+3%%Pgx%&JRm$TLQAG5-3 zx4a?zqZ2!g0RruxUKvq*xBdxz$LalXsZ&XVzUJ}A@GhGDp?Ejf)p&+IEIj>ff>>(OtP&9gJCk<5MP9{r3A|ARe!jdG(@30$A$GnYH$jUFpFS;54K zbcd~O2R95Wt2wo64C3AzWT76_ISiYim`0W+z z@{y3cbrvq92bU|sa0W~IZVzfmIh2Af{L*7I_j#v=#SEZ@iSVO@w@xbx5n69N)LD0G zMv(GD&8{J;2wrQZBoWZl#rKB1=HMr24r{Wc_p*Ppk};X$7Q*Qk_%q-%j$R-_!nA6>X%9WSqLx!`5Mf!2 zB(BbPX~=MuttQsNEGgH;42{86(STfrbS5%5+ARzU1s@l^JvOmrlbd|ws=RRc!zf(< z7DXKBG(Iy@sq?MfV?HS8+2%-o0{+3`dfhvPPxLl{d-6NYw?FKs>JQc2LL%21-p+}j z>fUPl&M|0qrQn$sMNhEDlH8jlCg=#Dqk_ba3dHqf-X)6;Du}qW`C0`%@NW?-N>^q0 zxe%_^tjB+DdT!0}=D4V`vZqj5s<*ZF_PnZhs?l*JH|ZDu12q_mWn80!aB27^V5G)X z!hCg^kBK-;7hnK{YTGrnYFII-KLcT#i1{ts+&PyrS!0#xWVz(LE0(a7D_~rm+n*-X zi&z~mF-Y?^EH5lQl(;#k!Q3xX^kpb|U*~vx-QgXg@JSQ;UPwhx+%Tc z*tD}OLUH-vRk~t0$)2=_k=fv5*1zh#7@O7Sdr8Dc>p*sLa2LwgaaLKbXrubzN5b{B ziUxcKP9|t);C4l1N9Vkuw+%r_4SvOT{Sr(AAw<%2HXMzpM2tm-YQk~s$hG+f`ONB9 ziWsanK?FgEO~4iZ4hz|Dh`)0XMK^j%YW8a#OY!!MjKWdm-WG6cQ!3Ytco1!%T;+=7`KTeIqiYm7qx}d+=)B{65n2hDP!=f!8 zG(=9mSz<}LXii$rc=+R;39UirqXhqli;sA$B_-N=aG`^l%gUUuAEoje!ZWCl%cJi} zn1s@60$veK)jCB^nZSfJmTtQ~F~wC5-F!oPS3L-ZFG$5I3)Rfqqm$7OIccoWrIS#f>nhhpE`h`wj#X!Gei6+$$q z?#uR>B>M_yt^9>dT~MjTV9YCIkMjc~w(QYzJDI?pL^_6qGKNXv(`p@y+r7C?VP)4X zPA49oQhwufT0^D+2`hKJrwT=)sa|ar)(jb7liz`5)B*;+q7d3M(!}3#uyI)iN@N(> zS^1vH1V!Sk2byY}IRm;)v1ih}wovnDc^yzn+>+muPef97!V0Je(@W1GKG0G`A*Z&= z8-)Em^-Ry*+fSNP`&bePn(~->GQ7_qV=1!R67xWQxhqZ6X7_%n=XL{Z|1b9*3r zH|{oqo}QpYPemjxPhv}8 zLI$kuzAXf(X0L}$k4=hXztNcnfSe7^8C2Q+#ORI=#1wW^6P%AwL2hF|a~Tui)j^x6 zo*=#W!@csK&&VP z8tH8~(p*BEExR8uixrM-_W3cE=!e__fsNOCUsPw-rSfoL5%&Q&3(9?Zs!w{H%waIhO|*69#CyD{mcXH9ob8`b`Q$dBt4xN z_oeNv=YfW33{38Yx$|RQvEgRcRJ}xYJJM@!DT)W96?xNeRyrO+aTJiZyH9|YSA7-% z%Jz50cGL%gr&3U$&+TgL?|hs3%@{WMsNJFc*2p-*5KP z0U^s%Z7{^@ukiH+i%>;_g1;!huTc>oKt)d&D5%Pk(bCZ9tR&l&_++`Pbbd>4{`veb zfjpF32;c{|0aCFQO#&2o>>~#pfCSmN_kWK~W;}k&3y4$CUxrchf81#Phr+}4S1xND z1n5xxs34>Ax1kXQWVHA5@8JG@c1_ak0tL64F4nL8lcSR0s9Is@08rn_bg==M<+Wy^ zcCl}@PN~rV735xFK)V94x;jiJlRL?ez-*Wq+9&Lz)L)6_h3(R4LB-go_0L4wo2TfRa6ldYfx0VwU z+hu*r^_NqV7lZ?BMZn?LC+}sp0Ts%=eJ7nose4iZoQ-N@s&f5jqtD^|bh&xgJ}{|# zfBJ|VvPAjT?J{86QALpJ%hOWd158gX04p=i9gD{relP;eT?+xIkuiYk`>yomPNkju z#;|G0mts9gmfwPgv=l&GQpp3<0tIkdD(}7e^{t(mTBp}h zt-N764|j8uqz33Km>B`%LuYu6;~WpKcG1HMhnbo&X}=S`6hJc#-G>5flNxqgktjKn z>5Y;sK+gd0rTQyqTG9OWqFUPf_u}dla3E;qsegS3C}6E*{m-0xrADOy0%$HAkoRJ` z?gl-o_$y-v(z28Xu#%e?VBp69|KkfrjUX6J8>9%#*#E7EPXRof=dWD4Rky;T{tqCK z@2IfoaeW*vpqY?E@JG6u+%pTyO^l@KJ5 z5pw*G3-FKB4^Vo)1Q=UF9~p=Zd7<)c0vn9~Xz~A2@HhTSFD_2lvPCrTi1JgXlm3-+ z0lp?ezy*S;_c{r{vI|48`%Qp#Y#DuT7#(ABLJn|sXuYkcSeE*A^60HCG z$EFKqk0V1)$}!?gc| z9*hn@irUiqPdmd}g4EMv6{shn%>Za_V1k?kAP)b^;PW6qxH8CS!(aQVu>mdA@OQnE zA^!~<@^?XPjsd>}4OoP>Y85&2{u588{p~~!eW#gm12p5i*JESenO(39{Oo`Rc_*Wz}stj1UO2eq@ z6*g-T+`wS=xz7QHt|935M&EU@~pZTXN*eN?K1TQ8uxC3Tvq z;U5KpTlfo*llpFf2z#*78F4v3(Mt&#Jq_$S*r9@$`*?Xc6rfuOj<&|^{>D1bSc##O z0>Bwy_dD4shybki4vqp~t3JTbF$3ZYk5Yjs(w%GYC|udqW)XtQ+0mH31Wd|T@%mc< z+?|Vzh9&{H;iWR{*RQ9A0f8(NK=Z7tW`oa63l&UA!@&ozh%U#A^##-Kn|GRiSH12C z`$-&$vgC$#qB*uGw7@|GRZa_m6O}_UDY)C|5B~nZL<GxBi-HI-H1ptDu@Eot$=iQ=g^%}(n^bjbaOZ7oZnq{t@|Hq9KYG$j(5ND zJkOf~#311tbI#^2x0i;X18VpY@00N$Ag zD>H7XEir1U%@#NPv+Gn`EKA3w{aStI8`gCZ;=78N(GFOK^x1N=PD++fU~;p+LW!6Z zUmSPhiSdB_*Ca9)9jgtaQ%%R$qU|Bxnl71-19nK%bHC-RXLjI~Kq2f>eFcz`V*uw` z5wNjLt`efHi|~`8UmMJ%&=GGfG#t&P@H!;0sbxxr=$3H+kppd1Fx|{x4h)O%NlQQl zNgZR-21XM43{}6*xuwWqrW6Q*YCHXo;+^y+D~}@ z9!22p`iK$mfYk(gb-zxwzeB&L-UqUx^!$F1cjuWSgfX<}+!3~I^4jR7kGARPN{`wN zPEU6?BMuoigNOp<*a9GCvq*e+AhJ3aaC0dKfMv+PJ6pDZ2~V&|^OhDpUqSBwBCuU7 z$gKP&>g78$Ilzx6YRWfmX-rlDEK&{O*X8__0`8Ik7bAG_yQplf`Di5e?q)yGeYa+2 zK+onYqmb8LTz&luJ&?aNKeOlwkIqZ;k>|D=U=X`Lct^~lDa%p6^49djnQyvKnd>pl zA?AmQPC&k~|CGe_yT~X{8Geio-(_afY`G|$EYaWBMt!SkIz8Z7X``Bze`}hqMvHF> zMxDyzG^ZKFJ@39b!XAvBC(K2T;dj{2Y;|$CjuvyxTWk+l^|30V7brUE#GJ;4x0gGd zc7OBi&HO_+y~jMM~ZKNOaYg6+h&@tvT~a6)4zZJzSSaC^*bJyu>vpb z4)~*e7Lg*>0op*TfHsigdU<1H=TFt>1Mj=-0tp~SQEfoxQo2nDH3`i1>6w3OhkfI>H z1oitIP`yA)OS_j#U|d})DiyquUneC?tq5F@c9NTR*LAd&kj4XMU~BHf}rQ^ zQ~EH^7`GtqjaO%jUJ9EdUm1akn*d4+_X-Mb6y)`O+c}9tB5>mmQ;Ane{1#c5cj)KF z0T)(JLA>;fvNwW)`ChaEmx3?pFK6S{<76SPQbUhn-hj=k4s1@0m(rjh9@`(wOd+C+ zmoSD-{RRej#q_`woY?ug9&f3c8Q<$X09y7yC;@$V_u+P4I-doQAGosFB4>=$>dX6v zPwFmL(}@r8)uiIjYKmrcz##@{X^bwG-a9w3i6FM1HGuQxJ@DwI@*>SZu5?`t0Foq? z09Ay{kR=nzr#hRjMsGpV`PKL4WG3~_3+Qnyy;;S*0H$rk6|e2)be`Momn1Ux7u4ga zjnQ;Ypjf~&vo@GGdffzOy+{8Ia8?I^5XIWP`U8Ll4gk}F6Se5I?B5fC%fpopE34XD zsd1Q*2Z?_xpfjTmN>NqDh(`!1?4YRxJQOGezq2D-`p|9|XREAxEAUCPa47f`S#(Mr zd-~Eun&4W~==jhsXFKs3s%D27j;tLCJQ0TagYi8;O2_Kkr4~^!ICy@qOe56t{2F)w zAtn}7bRqZGV%l)m;mH7N*_UVEfXc=YYzdf}wcJ$a7_e2ylaODx-kcgBjg<$Ov9JE2 zfxL65Gw=T7K4avC$rT*D2hgj$2VEk24YlA^bjtI`Bg?AZ1=#^RyB;k=9SxKak}uqD zAJku8AC0d6{6ND8`PBV@w8Ol2)GZb06tHEWqM*4imeeiTZ{VFLJk^j+;4rdZXxCk} z9!jDEHZiKK?RIYH-7~mu5N;7;&|B^P;l!%XL+FVDu)2U7pH=tXUF-!jM$493B=~D% z80}f9af?1j^MQD~IQD^$XG9t^YxVtWm!!=Z*xoBvX!v4?)|{o+{#pQsJYVQVH6Hx* zVLiCq;SMBwtQ8PK6nN^C4swv8&NF9O#Jfc9JzdzK6Xd~I&kq4MKR zB2*ofr{WX0m|+9BYMv*^Ei{2d)`^e_4+0lQ)d1u8w}|~@{`cxraoUHyfb={8s}eKn zylKwXx&sbKPV;AqP%v+%P#f{LcGurb5p>$&Biz zmbdve=ZaOCKFYzb}iXbwlwdARD_B ze+J$w@18CBv{XO{BYr+~4#GT^ri)O;QR)iz$PyAKH~?|LG$nhy zMUfK*A({KtZk+Zk-?$sRLla$U1hoA{1n+uJ@Ebs{R5Mt|af)XR}-DVzWFyX?Qh8-|pZKlPQjvu`Wc4h)Q z)3ICFhfn6VzZ2sTMYN=3pCP39#q>`XZezrN?t^;-)@}4dKuBGiam4 zD6{ESh!_aWB}2SD?C8=P-#zbO-P_}5D*#L6}XPVJ;azQ}tOI57Y|W(&-Q3t1w9 zka|wWaugoL{)X^}+=Hy^+**C^b5N85ug0#onisxtqLO@?it1G&BwXwIYZ1dPGot#6 zY+Mw?ax8TZa_<$!z)Rgc>^X+2SOBdxii+kD`W~@5b<{$f;{ja|;!4UgT5O7! ztE-OtzHW0VqQU?7!vzNi!y@xYltNf~TEEzW%8|@|^V6oy z7j)QpEgauvTG%YaZUM|~_)*2?-Druy+H7>E`r0SLiK2cY^&&0ihQr3xp>q@V6wbki zLoufkJ(x4yGd{Y~oW@UoRBndOUaJd%5O;uh?awS68GT5J&&FuLC-iI4$KrJf59t}Y z*ROfX;{n(-H`X|w4=bA#x@Z?e^GOq%=g=`agcb!~*F;kKqpUW8SpWlt;`{bvG`LvF zr8HWN9UCZPCdlmY#_N{|4UTtyupG%AzsDt6ZFvl@wUVp!OL&s^`>uuz0!W@*SS$V7 zZHnhGw#9gLKX;*n1HHriON(^?NmOBVj=ZY7$2A4yrMX{8#1pNfqkMR6%Mr=z#4c6V zC>?NN7LQ}Aw>;ydLWBIz@^#)s##_i++Eg)##V-Id1F@kRfB=0Hm`nc zA{*KMi8?gDMLZMsSY+TBq#FdrfAs&wsI!Efvl*wSo*}FDd~_r$FUj+J&&eM)ox}#E zy*KspbHX<-!^w;AWgnZ_ugBEBuV&J{{+O?%L`98fn1y5C`#JhpHW3b?NCKa#QIeQfrz@nkAAs3y89Tju9J9YHmvcX`gjSnQU$ z`e;;DWC(ijmX-Pde!1Dc&`xocdULJo!iq}SRinYaG`ul#p%IVRasX>4=hOB{v?lEn3702|j9@Gy zD0{>N4y})ol7ib`0yv0pf-y_Tb%l2pPmyaZyb*vM6WX0t*FMV>4tymkk^|7u;kF_k zA8lzb2iE(-HZ9)F(}&drG;E3Qu1@;~ODHJn_PznFEstUJoYB;ywUkOPCQ*8Wzzexw z4mxq;VcHChMlE<_>1{VGZtG?INA-KBP3yyS{wOb~F52Do09**iR?UR`^)^^i7Dmp= zGHXQ1Vw79u%}fNh#WAhNVqLmF<(Q{Q;Bo8q&F1Td^;;Rs{|6=Y=fdH`_I%AXQgisS z^FdJ_+=(F&NnKF8Se&+3KsH&u@s*v%$=g1aiH|7rvcnVEazytDLYyZ^+GQ=LDg84x zgC9`mz2x`l#i$9IQOX*2P-Od4(Gd+(VjwWGc~wp#y%6JOoKY@t93&=+f;<{mkR>+J z;fnJ1B(@Z7WzFGu-GvFW1n88dzDeiDRg#|}E8Mx+j-R{jAH^_SmAgD!jB-pA=GWE{ zR)NuOj>)+ZDORnFphGV+0}rKY?Wg3I{En0g)N?*vWQaGW0|B@sx;L-$Qx)w~vwurn zr2@Vgmr%}`q&z&R64un8dBKl5b0N`BbDk|qhI$!By<+}9R8P7wZPbxlJ**-iS}$-l z<*vVwGog?DOoVN>Xo-F`v6OG6*7Ed~-o^IgRVER)>-y?~SBceR=br=&&g>&UA9i#l ztFH|dtwoyfgLug%790Daa@?P@;Wk-->|w-&huJ8{Yo!O;U*=KGwW*|NJz;NIPNHwS zIgD-QEiMD-<%Xy6sIL-Q?g$!o#(TpDYb8#wa$Pon=ESmJqw4GZ1v;(NYA%1RNC)MEgoi*%=xdc0|!hK=(#A z!jOHQe3brW!6L7U^cK$>f$e=F3-55lC&Z2oBHfWq7xh;>!KqWr4A1Tc4nLn3w_|4^ z(W6H;1GPv>n$wVu@&{@i;XCk55LV3&nSn@l!#DhcRYZ(U;LS-QAn>Cwj_u?#;!HX( zHUIE?Q?t`G(R7#zA00K>=a`zkYG5F>_Me7rjqR)JIw z*zqa;v_E-hh|d>Mv-4r%g5=XZ=vbz+fa+lyU4?HXn;U^TIdj`IihX0?e=e4ig*S>i zin~wCk~Eg&qVD60i{F=qU%(+mP(Hrc`6 zLnSs8SKopku^(4zUhOIVI6LF;t`5);czqmN?YE`9&E*#(pu=Bk!>q^S|H)g_m3hYY z@0YcaD--Wrv4BMeC)UIx?^BnHjtljbiA-*fBc@DN$^T5tS~ z88Uyp`CuX^XN%7XH>d6`vLsphGe{(ejwxJ`jmw#$n{gKQU^0y!>9=I8}vf723{eO@-Ty8m6mFRYIE*iik{y$qu8x6&}H4`yagQ`1IJ zT17J301{jMclAvkH&W?5?%kF4r)AeF9NTeN$dHl!Z68E-+Gj)DbP0+Iv^ z^@scb29`^s!~A)8n4`WSYNG?d>Kgpb2)-W8vF5#`-8&Q={>{+g%0P2%+WScgLlT=d zGLa+$E`^0nga0o6LzTa-{P|J@|B|i!ZVV0aAhkAWP%sNs?T=6RaxYf^BVI90t=N`_ z%^@7Oe7sGlmEA>po7WV}wwiMXR*L+qybsBHPY})qNL{T#5|B7e9Uvr0uz~KUk5PSQ zfU)MlW?m|kG}k$~TjQ)?u#1dMG1k5;n<`8`NVU?ltnIs;z-|yeMY5IkfJ+Q{2;vch zm(=BhhM}LBQ=|AZr1jS)R>fpt+V6ZLJe8sdJO#?2cLr%kq4&H@3;%<5bZM6zLUeck zZ7H#ECkGBry~?iZVHue;>}nK3I1>)CFugPKb%ANe3t<(o zp{QD1EjDdd(r{qM*f%>v~UvMdwv?+1+@2kZ}rQ6_}<$D z(78%jTf(Z| zXnf(@@kH;S=LK1fYp`GIN=y063{Q6CQe8@49>1ZXUTNgOmN)Qb{($V`G(rCEKwXVP z%8tdK{- z(T%p9hJH9fEeaPB^+%>18ur)Y)USS$v152Io7M=du63~)3>CjKP*<>m94gmJJBBt= zkB?D5n}G@$xuwuyEjKUvh);(jY$lZo6i(r`zU)U`E&X54U1cp6k0YcK?$~takHVK) z5GT6CyqDU}e6JWisAl~L zdefANPnxgpW2FBCKLY<8((8QvF*=P6?iYhz&vdeDouKinhkIgos%{<8D#D%Vp+L0O zPGhvtj-p}uvnrt_;YJ!G0kOHG9lgv~{QNBTs_ZU2*gYVvxyR~yq5NadlznDso=UXZ z-@67D48eQ!k{i{L2UIxs!JgA)1woUPLY$zJW5EC5F1wV-EzYN1<4oeD4r@7#rF`S< zEqNmf!rw!4CTmo4yE$Reluz{Rc3{WQkG5W_OEJaZ(K ze-y?PU8Q?cPHO(KIzrU-1S)_hdY*yATb#%kV#jwf4^#hT!m8I^Jo(rCl2_(kjkGyP#_*R z%@>8?&BPVLf7QD>kSTxg1zf)=03z6A1|4BXAnhx*`-N+BF_fh?J|swv&6S6uB8+z| zHE+xly~zfOMC+9XH{2|Zt@5dt0QtRLkOkt^eqQ`)`d6PqI-dELyw2T^sByG}rS0;Y z8<=a&6tpOPP?u9hT5Xk;K_^`;xo;9$uRP)65@zw4BkUcvL~nINmG_Omlfh*rZJdP z@8Gbw&bc+#|u1f@z=$xvG59rP-a-Hy{*D>kZ%3)Q7NVa$8b}+U%ErZ#Dy=% z7(sc}4&JLf}qOfCu?6gvQ4RU-OHhQlR6~`*{48iv^z%zYpt%Ni#AmOei5n z7;YA)01CC-%^-J1c1sXyj|9?wKEAKq$8%vxvuhxW-3jQ#Q)fW0Jh1!7vZ(hUH{~s10u0s$t7*Re@^fm8a zQJDNX8#dJcHm5Siv9x7l(;X-+%HE3^ng;QA@Ta5^PGsSuIv)L%>Rgb0B*9aY`b3a? zqdOoL9lr!alTI*M){s8}`-s6GKc06%-EHZD=$SGxhXC~B7pBG+bL7zzntgPe8L3N5 zyhoZCiV;3OF7=?wjZ@b#7pVC3zd^f-XDFp8D2usV$hsrcqTjwE&!(Y!n{?SYKK(>Z zM)2X`k(2^5v_BqXI-~}hL)RF;Vk4wKOFT}M85{oKIiy9$#ru1^<)=2Sk+^9Mx6TKHN4q8@2L%XU*6D$?ml5JASKO28%&73% zr5$jiEB-Pr=DsJ*BjFdnVHoNzl!(xDZ;O_3zB=9Q>5!1)X0u)MI!a)!x>$2;6^nVO zK^-pt7~n}_3O)`FrfV|QBNwD9jKB)bR7=`Z196K;pUS*}PxNie)L?JO`4E_#fg1ZT z!xyF*+9Sp?8ttzS*>4MKl$1L`^@A*oI*O;Z0ET_zGTVF;_2s>5s0=@ORYwBGpe>)DHAGgrt+AtER3st2ul*|w zx%rbPw)liZmeB6-Fk141pch7HmgrAy-mHbve|uJrS`UFSSZ){xpp8BALc~dq!dOh6n{2!!w7oT|b2ieD zNtPU2J4M#bcSXXPn`=3hWB&16oBf#1?fDMc1Bhz1l_&%{CG7f4eJT7Ik`PdS$$~Ir zM#J5Yy%wV;_0bHIX%b#sW_F;K$4)i_aj=O=X6ryCaTwYGsyu1f2>_>hq9dP9`k-}< zPk3S?_X(T)DHB_i)yI{rk}mGMPPGZM!8^|^{B$OOA!*XIeBAA!WG8sJ(EvS{Gu+)! zRs4O1(2joTbxAAtVwAOwm4UgJU6}x-G^-N#p=yAREZ6R6BS@b=Tf*M*pF<{&@@)JmD;Vuf}--vc-CG_77n8(AaRetX5Ale0nDh)I;Q)X?{+t7vc;s{X=Ku~YPR_{mJ zekjjKWp83(hsNeqAZgF2L4r1mHrWD_s_KCkufCXq+9-}RZ;Q-*gNW;ww9agX@w!Kj z$PA87dJv?#FTk_Y>dZ9XLChiWO>Ce$Q$;pxw#P3`F*ubdo|rB=B9H*TM^~S1Yc}1C z3|a|MUw99BS95yNNOSJGv-9h9&mxB5xGNqv4J~9$xA{%Q!s~e_w0ySNABT>ROoPke z5{;c;lNqDI7m)m5SWm@VgFo^#q;zWDQ$io()y_ua%J$CHlD9<-RQN*l@<&z3b*g_i zA=Uz_4;7r!52G9=dk_i0@UP0;Jds6rN6W3D`lVO%P?oE;+U#S`GYX8Z%Rf#_S=e$n z)CchP>DZn^hsC=;PxnkSVm3SU^U1>8+^nvIWb*Mzy93!g?KAQ7@!%}@7XR!u?NPD2 z<_bQuaftGZEL2*E>BAKOyMH?YRM{O%NzO>p_u0(K#2=P(y4`#B76Q6s4eS;??H8;o4w< zv?0(v{Gj;f;~p$~1F%~j0%FsMojY38CdT505z_H2w!>nMiUa2HBQ=0EwFoq|a1;Pt zLTbM?QfeV+P!40d3W4yY+Nz;0z)eLkh9B7(gGui4W*#AM$JHjdT>0{Krt$6XAcmk5 z&~1YP8;?_k6Xh3S&#|ja(amP6pgc8YtOoD5bn*-ht=d)l_=0q z2o3o&zRe}qA5h9A1U_3`{ZfT|#cRXpQ$=gqqX#H^<-bwgsmP(4#)&Vk;?)&sPd5 zaV^CRVjBEn*7VJ|qg0e7e9Xwfi+{9h&=yy5_Dtx2Qcx=8FmP<7kM_0}?!}o8(BYCr zhcRoy4zfj%wqN+*^q{bh1P^gvgmEFRFOGR$iJ zW5;($0;;OC8DDTTT$aiu$->Qd(FmeBAG~c}rA|bc=rHhTb^T^-3M6SLX zQ}Y`h`FJ79{J{-uW7iXXmAdV4fR$*my_9jxlj5rJff5pJaklO6#`jLfvLh&$-y_@> z)6KM2-vv3@>H^T}_q2Cw$Lrp;SHlq~U(0EDHo}}?E%Py#B9QAp9-o5olpI%)iLdNR z#)V%0;SzfcO};A^yt2oFi&~AlNPh$#qgo|_Ag&gzCKf~dW3)$P1v)QgRSHRhFtAf7 zM7ABMbstnLoy*t#G#*t*4TyC(mXasfKyuBgM)eWfVT8R4Y5FnK?jK-nvi0Q#EBD*e z1n#%YNfgs9u<7pl%`YCGFE|TANTU2R1M6~LFSQr*j)^?Tb}@a(FN)YOO7#ttKdu>N zQQNys+kpk*ZG{O`CLY^RoZW#y###k(n+^2KX;t1D$7+K$&5b`4EM>uGLhVRq6I9fg zcGiL?-2*JG>-d-+=HinQ&F6=yqTT|eo@zRp7Ol@esFRkl}jJ>W5lHz6?tAu$$f zmGmZb(cO}rF}5jN_JkZCGEu+N6nKP&GRh}IPy;c)Ab+J1z?bvx5Oku4h4eX2q>st& zDe_d!11HWt4u~eB32KHkgJ3|y*|$-zTHLhp2g}!d7W^de|xTmPwtZ6VX zQ%;HSIWO4Cr>b?%nq<4lOXKB=5z=W0ekK-{WI%>zJIQf$%q}-Ol8^=^wr-_2zrUAY zYB-g3bW*5{mWd4E(+s3TjcAi6dpb^+P^NW{l2y8M0EOc_-+We8RAn$t2Vw&GlH(-? z{IQ%-hAHE8C@#U=4qpLoap}zQ) zKU-ln_%N3K!HdiVvOA`T5r9#4B$SQi2w|Ag9q-G+X#OGHDhL_e#lxl%K(63ZhX)e| zI_pyx2i^C9@y6`8>${WVQ8E@QT^A*!($EU-x%M9(^*43oB@T-G&0K4S%g9fig5(pY zv3gfqAzj!oYtMb@uw{T04D;s(8cx9o+a;>6sVw;K!PMo2p}mi;!;^(Vp594G;T8K$ zK43!PfnfNlaeqc>2dJr3$K}>VgarVkDsA%yMX*pIXiC-P7uDF`?-b-hxqgZp0|7a? za-~2BDP{y*n$V@m)2+XbABZ1z-S+XzM63ZGY-;wxebzo`J(#UH06@s%0PH-~{vpE% zlL;-XPcZ+rxE5hb+r>>=%X6f<0{hkTFv~P?2Du!3wa4)>k1c`+;-VC06gMh{xJNBH z7$msk)SpQ5;K{b~*e2-p4V_(Um&~{J3T&qRUGf<5pE){ywb*n?LGidb{(XAS51F#65uOutMTtqJj>GNyRLck|PVLb(u zx~C8^*n^CpmYBa5S+t97M-ta9F_l$*l0*8vPoEw1NGem(Ch#f`uLzDLuOC0awyU=Z zBYtYm7NkqmKbjUX_@f_|vQyzYa$Vl+_7*)aBr5b#w&LfZPJKI~J^hiV8~MBo?O!aR zFU-lRZG;TUL8)!zeQiGx${dk08w#}M^cdIl(ZL!D(Fot^D}8B5C;x`C8b){nM??V{ zK;de7*;{BLwF`QLfSi+Uf40wE`rNv2kD?#Med%h;p_s`uf zl8@X42)Z#}b@BQXrXO8fsNnZCwA9A~b|bO>*kF&ix)&`8?Q80sJY>#${I%fY$M+jd zc8{tAY_K5k$ww)A4t!Fmz3VVxuXe4Yp2s*~Jg>E*(;Q<%cgdQ*B!*2n1K?s0v{&A! z_|y7eBLBq&7M!mQaE(aA$lX3<6EQ2x0+=gj1q#$DC>`XP(xw#VU3HK%(|&(I9iJlH zA_uv=qkE}`1Z8t-Bf2qtsuB|Jpl>NGV73%V7Ab2YG%>>GO22<9g6@G3xLNbjLOBo! zu&&vmj}(3kV1RL;=NuWUcB|h7PBrM|G+ZBS#13eIA94Mz|MueQR_G^55!465<%?Z) zJNlYjmRl=5HkI4ux3E#5xqM;)r8;G4ZaPF|vO_dcpB$2(+dDxYASo>j@-Mxy$YeMF zqAe0Mp>b1AD@cc*$XyOqjX^i)z(=mP9wsO9veiM?V7i1%*H2#H9jq^7KV;(y(}o)5 zP!^3=iJKOmIyzQ^bO+z1n!z_L1^|_Rvu#>lst^=hFLGLkT-w1}|eICcX*IhCI^6D!7VX@FDjOnEAw*`La&D$QDf<49#rLbEw81}JPZHRiH_nkII73&VufZP7C4_ZbC(Cvo~M%t zp;XSw1Z{opd%V4W9j>iFf}sfq8jwz9fP*7v_$dXjDQMS;Y1dZ323Y)tpXBbJ!RQO1 zqpC8Y_rCD)-lFe_k=No>v-|qMvuSRp&n);xSj7f)pUdIEH5{LEDJZA~$hU&Jnvw!> zxORy??-RYswLkUs^=t*1?Q^nPwBjU502$T~>Tf)N>@)UY!v3Rp#sld6?FPEk4JI(F zqJ6?b-^afm}F*<$JIxwTZ5vr&FlAk8x>s$y@m5YFr zq)d^eG-+J`B`83El!==eI6kQ%cr?Zzv4EPeCBI#c)y?d}68xk%@yoNgdpbc*+>HBwv=Q}SVAcvU zQ?n|g!2?lfC)I4beC*@dyqvgMU zfRP-ifLrv6X zzFZOebuB=dX9P|{XUlH+@EQ^nUseDeRjhx)x+7?(EYQx8zu`4-~;ehi2o zS>VZL#5z?E?rAU?{}00k>EBK9Q4@@TzQ(57_&?guvv1%)E55Q&Hp&i6~DV*@Fy3?*8e^UNej^g zo-HW;_`bEI>@HbJ;(r_^#e4D+(IRQ=y}WF{^OW>|R3yny_hXqL(#O-eADiNTRIq%& zE&@*u|7Ab@^4^_}^Yf|t-zu#bfsH^#7kzK&vQNXO75||emV79Js-eRLnue$|7W1*PtD!PIwV@4eNmVsRfwY+2 zl7YqW4myqwH`+8T)~MCxmd%pN2e+c`-)#=eSKOhNN^nGj6HUY#i#@R7#2OhtCasXf z&cFemcG7nx#FAu0`7N2VD#%EJVa+Yu@58KBD{iWewY{uS1#K4w-z)H5lYBi7XoyXL z)vpQiVO+5PNZxX$?gCvx9tm6j8ZNfM1!P8JHHAxr#z z+-V!u7+;y4gb6H^qlFKz2o>$BfJ67AISO_)9#oSn!7|qux#_S8mycAgc0I6fSYdVjL}=aK7-}2>)_<^}e6mV8rm- zkl^DZLH|P+fp;T`CLCnXZR8RJ(**qG0fx?D0LKc;vKb5l)HEv3c*<14*(80;t3oZt z1ZWvbz*64{^wD%4~rIO?Et;#zs^kF?g%Pf%C+l z?;cl9e`mjitz39)uGQGBTDI4JbHDP(lkbhzV6aJJZJ7@74Y;;$BIeLm=TJyrTCHg{ zmO+!jqmF84-x(yiD2*}J*i@LSw!6__Kor%r9);kz%rpGl6V@?eA077ADs9=`2y*wk zi^y@`8f{U}v+_;fzdM>qXS{7ySI=3Bop7G*l5`66{7vfZJ!G1Euwk85mv`L$JHGN{ zcP3}BJ{kNsF_hgSBaf2it2tJ8*ZqC93)|ul{+#8>nJE%CWrg zRiu&-xlj-BmwVLI(%kD4oQaq8r%_B_FSqnYvT~zuTO(m}BrV>Cx>YBHLzhv&ee>@& zwFxJdHTOYHIG2%^rX*LQ+umQ-8SZO1f|I{2@lo0?Tj#@8#-fekC`z3*IYQH|*xpa; z@xdmyY{^wtXS0$fW%Td79=0-w`8R2#1vtOIzG}sceRXHmWY%p?Hd7NXEaXrTSD*FP zyLFl^ja4BxJYjp^pJ43Ge7*a}10W%NkW1X-K4Loy z_-WN}+4z|5>08mAt1gK{%b9=;s%-_VjRqZzV=1#1CPv}|3aH9gV5eBM<3QD0*3j_F z&{rXydo?AH%83GvvKj3qg78TzKeAB1z5V+=lDk@qKDpYbs6Rk`^!4FXLd1ku&*P_W zIwN|xpY1l39-jTR;9gswu{uf}ybfsaeTN{}P3f=aUs6GV`~7%bU?gYXTNCSRKOK$z zh_kPUM8WbhXz%dXv{8(R&R&#C>qsKcL*(DQ0aLl6n;E+VgqOX`(6|&vhSJ z$}cN#EPw4)O!T!EVTtvrc?2oka#~+&5Kvg3{r2u~B6M@DlecKCN8O4c0P&>Zo1|Ux zY?V>w&P1LHXBcxN_wDX_Er*`7<3L0vtK)h8 zOe&OPwB7#FY$!cv=WaD{un;J^mHfh%E}$m*#v!;mFd#-)x9#J+&$3QaKxTynQjy;1 zOLwmm8NzIImL4w``pBB!mTWHbbuJf z3wiB1XqsybUk6l9`8Bhryf8eEa^!b>`jlQ|hJD{{_TN<{4Dt`@2(-wI9rP zc6i?F1HL)H6l(4j>nm74_+wY>21!>E5}k9bmOcxJpi!=m6ns&V?dJcXUqWe>anUNV ze}}V`R>#;#cA6uZxo%lU%3k=#gj194ew--Pdal8s+!UIU($cA(Gyki%G@XlAIky2B z=>Hhx;(4AdeAX3ylzXn4dVxA4=nWeQZv{+Zc@S={0p?eXVFO`rHwp%vE;T=9VqnqI z%H%Q-=m1_^TD>*rwi~O+yWplCyMA_I1@N2M-V_DuZ3VB2-4dG*_H5KM4sbEMsg~~Y z!UJ-Hj|0r$eywgLy@^7xv3dQ&inJS!wz; zaGgv2h{G^y`=+VCQ>Esip~SZ@enut}iqgobVoZ@Wd*;SV^*!Kp4(Srengmu#F`e47 z%HUDO^?bdO9cKC)!(k-Y9^7jAn^cd_zq!J?nv6$!4D84%w6hrO%~6HF^MivuGl@*P zP?7ab!G6tx<*s^vS0ZE2T~9e&^z=LGADVxv-$Q?>VM_oKA~Ao$~X&30kCYjEh7+QV(x z{@v4!=YLoL7PBLiVl`l+pUOO-j*8w*m5X&Al}rAlg>!(Ei^uE0SoCNpA($wHVsQ1R zzps^T5%Z8pL+OwUq9mYcuhMLt&|-MC0Xp{v?ZW88&sfFlrTous+@~iI8~fGmw^yBB zOI-M~{vBbJ_Im)#;XL*&@6Y8m{c2h%#qzkHEUvSf35(e2d(C`3&@tdC%LUd$Zu;Xg z33Oc3`Ky4-<(b@oYR+DghGBG%^o1XdaE={_>ORqx^Ao%P1yV}br^O^F#o3UQ2 zUqd(rzjEv4Z`S@4-oKq>v?voJQHq*!m>YJLzZ6<`->u`o7WGc(^n~rQ-Mo&|j|v_2 zTGSt^P(NK{Zhg{rQ*N+ie6HRxIAi49wNUTduzKoUD(6%eJ6}M=yr68YOKtq7Gz=%D zZbDb#wg2h2aJ>dKZtDRyqn!oLz}w4M;U78a#BDdq{W|&OmczFyj*rKP2l^8e%a0hH z*a;OY>tkH;{OeX(pM!2oH`uEKyC)rkG5f#8d#sFdjEOv`o+;=`z4?JWq8O^H%Q+ym zt-I>n{>fEin;R^4pm~`qx<*3YwIOq|IRC@vu|CP4;@9E5X|nb&&acl*nUK@5FZMgm zB-d^sdq0H*+TRRP&J9XF{Q1tbG^{jkj=JHFjYc(gRZGjx8Ik>W z-*FvscIuPOJJHg}PTqcmd+4|f)O`FqQxxD?hA-RKS2r)3sP3f|cVsg9#HWES7^i*aRy@J5_MVitdknl3En?6;0;T8w8CbO>eI zcUq%CKQv#592c7m>;8IfGt9JGxI}kj;-}Oj{CxsOTk4gE4(FQU{LLC z!i<3EP-LB7T~;-elc*KbkE^;#v3FT6K_>RmX!k={@uPNU&vT!1Karzg#La;bF7D)Zp z`P!Q5hh`7r``vYSdNzWw@efIcu_rZPg7{l|>z@^h7T>KeC_DFlraXO-eB!JsvFBHw z;CN?S6>ii(_p^wU|F}_Sb8tXFV}0u-seU->^U{6QRb{O8HG{*?SRaii6j|!CY@8RY zA7;N;tUHo^z=e%g%-Y}BU*3FuKK!8J*MOh9R4df|7$Lg7SS}4UoR>>^{i1|(=`i(K zhHnRh#Z|!K1giUW-%p0ssTgwBk+wS_vU3jwu9?zD(dcjc5$nb?cx<=f_d=d_CbanV zzmFu@$y(Q(1S$j5k6pB9>Q7rQP2YK2k9-xOe~x|K(aH6NjWnJ#pfBJ=c^qOo1y*Y^9#@z34NFULG zi&1TARrOFw^mn;oQ<2xm!d+U&{;Uy7B4@yz7Ab`tjJWxv;`ekZ5{Xdh|G26xU&(+Dj}p zF+_|xXTQOuwE2=ed7&vQ+^|u)aoQgiWT1o5Rmj(Dq_L{zD!!7-pTHE9P6Yj^)kQUQ z^@U{oD&VHSej`FE;6%GU1%pdFFtg#}MYXE3|JSkWi36MU%Txt2-RiLC3pLmZ3>?-r zIOW08bI8{p9{)A=+xX@?jGoW=w+A3`RE>^8c~GxwQ5yLmq|HE0z!G%*JVYRW+$_Y` zhu);+`w@_P6*nc`&d|63RlylazlfvY%fF3NhljK6+-6hO$YFeDB?uCYJ^1g#^^LQI z)`fW-Y8%=y-iiU2`Gg2+=I26m8=RW6x=0nL$hyafm2aR zt&{s3fEDKcu|c_VT@*))#7>9oHZ@Xcma?s|Q zo*LyVCfF+)uMa*h*3n8iBYVs^u;?^*c2u|Ahp6u*VuOR$rH(mGuYX?l&fzWSE6_Fy ziP4JxHN>CkgVH?YuXrq2Kn#)>pym1G)V)m#kXZRd!fHA4MW7O7v)>18qv4Xvf*w|D z+j)1GICW297&!fs>tPvbOssD+-Hr|?L<9GVKPp_AZSp*d5t zs+H9h)S?s3C78CojGs6zJm+N7}SPBj#bfQ&P7Fsy8Zw4ak+xuID7<9>t(QeTK zuehB-M#!&UEPSSX>(h;&F4c8<^6zD+e=sZq?U9I^9jrHmL?PVae8b%B~JK7s-A=$w`|^C4cFyTn|-ir zl8BDZNL|S)^ZvszC(Qh=m)eg=FX9wdys{-wN_kht zv^_j3pJGEm2rCwg6*IxRn2kxf6FXb%DJ$(0BnLaFd^fgYE=SyD%NzQD$Cay|%eUmX zR>&vOyV9oiAgM^5r!Vr+yNA>L4V>HT$!gN}{>phyfz2peic95by@wXMnBuhrR05Wt zv|na+B@NToF^$ATV3Q9({shvCoZnEN+3z9pD14+T=sxct<+_0C<17yF*aGza6P;h6 zblTvEJ5^>IgGQi*Yw?;>fjXM;2Jk$7*kV^_a0+q#wfXy2_5k59d@qOFqipBFgRRzN%z zu^TXOnZLjyRqwS(zK(Aa@av|>yaP|oys)OGH)ExmyarD~0r*_sm90Wpk_k&d`X15# zZ0?8lJ8I8Q@R4?<;*LX*l8LC6*RL%PUSY2KYlO8q@7YC7SYnU`%i`ZNHZpHxCug4u zva@+ZK$^-pAeCZo$U5#~Y${nd77(#sc>i*5ng>%{h~JH4*v91Qk0A{qA}>)w*4Vo) z<&@fF%(0D8^lJ2@i~*&n6k*=;h%r$vefYEoEMSP@*@5)@C<#&ZGBMA2z*T{m8@R&kjh}JUC#Rf@_ ze48YggncXyx!lT#!YUwgR`5z*Uhog`U?lbaiRx7Lq$~DX+ zuVw2l@D5EeD0aO^YSn00`(3BFDsy%Y-^ljNym!4_abZP$Jsv)o5Bq7}C};CggQdp1gOGE(*rvgTb$^T@fmydx+fOFk$;d^fvjeFR7NZYB)^(+Nlb<&h~QnxXc zu(D7sKsT#9UOPn*zFte=X0$Uq$186#VRmL?eI|%~m)BS$GxEdO7$QX`)en6MNd(s;9B(`2VXHwnG8`V+z%fL53ijXtCh)3wp zQQmkTw-$SB2fdanuAF3@bSn4cWZU9OUy5)v|1CPD-V>7*n;WQ`<05y~>2@tCc#Y-9 zyr(>9{KTC%vYhe6g;{a-ih50rit%izqKn`{_QyJox;=Q!A|4B<^lGk4=7f?c;%LdW zE(MlMklfP+YPcjqZ`^9=F7*C%GEy1-M3#nBX|m{h8NiUei2bB_?%u16o`;$F2?NzL zaz+ZhuNBqIM~teS^ddHIIfAqd2AyVX8c!xvI&$y>v6L?!>}=ogq}rMby`1h(Ngl9` z(!{6-@sQy+()8F9L3^Q+4%VbCG!R~}dF=j8QBm2E*Qd_EFPV9S$7>^i(V}LY9;GNT6m1$=XUFL2CpTeJ)LO5FnoH8d*x12z zm8evzB5Aiz3$$vig|9pN^zuOu&WpUUdK^Kj6a6QOh7@a7oT3vAPX_XsR+`s~Mv@*^ z(OI|*J?nBR@W1T$E_@`ofAzfUZgt`Np=K_-hkDb~p8VGBh~zKPv#=1JBr0bClSy?w|L$N5#aaA6 zU*w~$SD@qol%yzwT}qC=y7by4m3WPwCD}gOw|Rs&c6DTL0Tn^R^F+g;R63Q{{+F#5 z(u52bT@5AF@u`(E#6N){ACc1z?iP@0N7jC=!1;j|X8Pa0=g0IZZ$e9hhksR!P*3JE zjF0L5ydJDQB#7FLhuCZ$|4bipR;(+X`saiaN(X1ub`+ z=xG%j=aa|fO=^pFqGf$v55QC-HfA0shhf3-axeLm-~89 zY@tiPM$b1+HVFMc06}^n&k;&LtbLFNw8VGX#yvo`L<_j|Wt<=F9%!Yh;duXvwDh6qTkzDdM~n@;GvJe&qt3rl zx;j=3xEWdZm^8pKgbpPSc>a}XThInL{(&(5aa^ExZ|K;6{;TVzqjg<&iLZxF;Jnp; z2L30~{y!$A!zpi5@|nOVfIY=94tQk@c#UfiGBPgjzf$&Skjazb8={=%;qmuv>Z)Jw zF2n$Iz?76pgFnI69q=RNc=uRK2p~Z@s#Q3D;GY!0y}i8?fG%=~0#TmHz&Mn`4nU|Q zz)E4f<)`ZT9$bS|G}EmQ0m1Jd8Gu#74{$PF7J;KHqdF&zBh$y|EHfoxViPrv}ngQ5w7V1YAmuq*b8FwIujx)6F@$l@H9!(lY2-Lxu*nydmHPN01G4Yh%#e77-|ym5FEu z4wX>A<@Bo3%GK$4KeEaUekvqHSULs9+-Qt1aO@DdKIl_tBk>^_bM0*vdmi%k+h+WG z4w6VHr{pv<5d38iylTNq6F}F4?pKSBPZ(uS9l=ivIY%~D=TnWQd%l#Z=X&Fqu}sp6 z*7bYs&#iAO0U~Jt7+N)qy7`6!JQX9)$b$5-u8ini)EW3*RP!x! z0*QU!DDMVg8T2UxX(Q&k_R0bPGshoKyY;An%XFcc3d}fiWYEiB$_1*D=;xQ3EjRm< z+d)v=&nG7*A;41_az}YMPbLvzm9=_W%D}P&Luf+SkM~Lwk6}HYX9* zap1|c!O?EAt(N|>H~%Hi3uO~7!rE2)0BMthqoff-GWmZWl+N6JbXeZVh7e%QI%e$) zw8bI1+up};<2{&$vN#Vi{&EH%Z~`9}dRo{e3g25kg&`?;UE;3URqizV;Ulku-WHhmM?i&024u*L*res!Ecj=4Gmm|SQ!0vw^%)alcH5Dd?@%Jjp` z0&VfoyZl=A6zl(ZA`R3@f)Y^RwhVrgC8z`peBP&;(~TYC4dHYWj0XzKdE-n#Zen(v z&&~q;YptR22`z1UdGvI4Tiua37y9VY9GVUZ@dY4D4M5LUe>8`d>os%lIh(ep)L(H; z)BWJm9Q9??d%5_^;7~AAO(ACDOFAg$y6ByCJ(oGR6qxTJW&$_=k^9a-0FH(9vC!Ul z+qK0ypV$t^^oJJ3J}cLM`O6` zC%$}AVBljO9xV=dItN0$(KOQinU0V5$`ST6WH=swFDU?3Fvj>fAq?0e^H?!M7=X$>1XL5#w_L^1Z!+w2@sUha`i zt%{wGd-P9VyT9fMk;S!}EdK%2-_ai?zzG*6WIxdksJqPl=BvJEe=?P7umHjBJD8Vb zfH#&RIsDeg)({FM0LQifDHtxl!-TQ5djUC-74YC9g=f7r2QyUGb&b*RY_F|KIb-i# z*~+D8gNHNK-lr~ll`h|vlf<+gY7cczSJNV(BU5E0dp--n*OI9KOT`GhteiTE%W5=@_b5R~1xz&yr0hWjxiaX-zJvP?!0?v?V|Pf0;MK1z0ylTF=} zj=aX&#irAJjf%7J4W&K}$wlUo?U4xl1=j%eZ-A@fg+*OyuXxS=sP|qw0H+cF&lX*1H z+&-OL-TOXd1QM${*RV>M9g%PLCL?CM62JN|$!*mLSYP2+9%Upv-(2umrqyT;uU*_7 zNm}}WRYGc{i?YV6SUNwuCFONiYUkngeabld#V7K1Ouq{j&K2d4>yA9kzpKlHTxrfa zIWT>JSjzo_1N6VgdeK@9nVh3RXSB^@btPSU?BsUlWBGMvY3O~5M1dL6MdS4&S<@#;=isx55&BT&MD>ZS&b*IbJ zXwqu`Cax@Ygv3#-4PYnEZaom6q_BSHTeq44ATg8&7?;01 z3A>{JHoJ@ElMdDCGZ@nJryCSE#W@q*8s=gXjaCvB{`7qFJ9EnfqH#sbAq|W07oK~4 z6*guQ;o>L960_8!P6ZUk(cZcgpKfj@D1Px&Np}lz!y}1h(6pqQ&VCzeTx5*>P+ND) z3ze*8Kc<}5MVZMMsi=)U9ikSn(6;xQMK;x79=p*SGm&Q#T_DZW;=8K0Fx zygA7UTrZXB+rO;Z*&e4juvJ(1@My0|*yOn*cBfSMJ`V%;iN?{@i@_{SUJt7QrM>mz z>KnKYp61zi&t4V`g>7e%to}@3=r{k(mAB(;#eF&QLH1%B;HyGq7Xf!#&|elx50LuY z09{&DM7j48q#lwEllw!N>aWgh0f4vUbP^Ej*#SDW_F~)bItn;XJKMsjzk}<|;>WTE zyy@-Qx<<@kbs)F|kidF{v^<6=b&z$W8iivrk)zEi>NMy75ODPeK}HG8mXth2j?QOD z`2@|W^^aoLWWlW3@WEd^S|9COG~d4fw;F_dvS&;I+b!NmF<9g%fJSgw$Oy0?JwMtQ z-y2loRREpPJ+&p4JpxXvV&%tM)3!5V2!>O2z=X^@rNTW(r<&t`xvad8lmJb8zi3~j z(thF86Fp=~B$IsTUE$*h#|2y`cAR0kM!svXV=`F!BW}^qqPOR2!+8==3zY%B--x-Q=YjBb%G%U7INSg(y zVIH{%T33VcdUH$y&dW{_XeoQMX0gvBqczYmoi%-h0O47yKSPvwRot*g)jyza#)jXH{U4Eh9=*Jdg z)gId~ktQZ2tfMkIRC7#{{j0e4;;7kS9JQyd_s}D~Xs7HBpW=O0NiGP4s!~Dbk(Q!v z*5`IHz`QO0HG3}YveR;IBXGgZmlLwkNKp8mnM5Uu>5%wPi4{4-vXi9y~8qbH^j zv&ioN1a5X5cLtKCYU14G+T)poejh~rR^7Qnw))pM7@~Xg@jVH`NEfWwwk<}buMPsH373oW|hx-Puewn>YvMn?rI)#QHDw&mbv4FdyK z3v9tNNieU#duQZBpcvE=p1Lolw&Z1Sv0(3?Eak2`V^r0E`dUy~g!m@QziRb0R-rfB z3ijB9{`W+JOdVp$#}_B?4%B(cOt$fh^^dm=c%(wCn0f@iz?O{xAiVhtVH;x>tZpXV z`rl$}FoHol7G(@8h}YEWSR~%50qv7b=h&3LeIAQ~O%=t$N8}wY1Ai!7u{c_0Pt@NErIBy~TA@5W;Ni(wATFp%oO zNBa>Zo)`-NV)W`g%5@g?3(&1WwSJGB502dqHI}f!Mi}72d?8wM)MMYLsRS(e{7XT5 zOyl4mcDg)2^7tP!h7n|>UC}E3B0BKY_+zn#kdfpwXjfWo_|f^qF~|?|;PTo!8^kj| z3NQsR0U3UOSk;#Jwok-`{9PKjvQOj)kS+dZyQP~)qo}VWtNXS}yrJq?w*ah(#sj${ zO{l4y`nG<>zVagpsmM!pUh^WeR*pY?&wM{^MQHPrhyVki#{UXi(}i`W9wq!pRV8}f z&jU#d!0-6nqWMEB+V#W!%A6l05OUDbljQ0FW0A$y&uV6?t?RlBv=x>sUPQXBuI_1@ zn?oD~1P~s2=8T$Ph9g$N)6jIP44^=?BzGfvOMS~ zig7K0-JcSN^cj$TQI-k2$?3H`f3CGu@dhZ&GA$nbOkj!EBIHezJY zYr+p9e~=n_R09z0c&?3A@4knMiBb3=a=!{jZ-bjDWMDr2_CBfsN!?kF=hVo7f3jox zyZdK?WkW0{toTC(;6S&z-mru6!{f`2Du2x^n^P1)N=g&XF)SKf2ENI%sGS8`Ji38< zJVem~n^;F!FWAmbdObY+F1R)Dj;KGPfdMp9yg$*H>rN?ZlxDcvXJ(14gFm*azI4V) z%axvEF2K2z{mdRYMbf@zauJqCr0Oq~tH%VNJ0cdQuGq{P9Z|Tl#qYY{4*)lY85=5G zU#T43m&kT6IvA8woUt99`rZkwe5W-YwZcKIXG#)Y()1RP=f!`f*5bNZ; z2~}&^oR`MB3kob&aC`!qT|LO%B2NU1a|nQbzk+aewq45CH88s_7{g)5j1C6${go3` z6oQcU+LmJ<(AkE!^Umw8Zt*k$neYRG^dNgC$#8{a$|ns?EaVL)jiuxoD@`Ph@n6$8 zVNhv+IWNX*Z1m}Zl1@NdJO;u2WQaVPzbezwTvG_8J2Rcf$|#KfChWA5&FjzLMH7EA zajXh(Z856!FWkc|6T)}eEVuLXj-UAY1JdnIWlPN675`5WDa9-n`Yfd z2oe=Ru1d)h!WzamoTpXsb>qY-N?E^Fd+=HEBTK?H23zvWl4W}}i)d}Ezxa-F8Xq)3dC zN#07=JPxc>!t^NLtkZB>0y!)FML>q+ zFoPk*TN~HHdXiOFsUG#}fTaG#K)6X3fUC4A22GMtIDkj@b70eN+p~yr-JO?)iM)PS z*l8+@sfCb1E_GMkLvpaV?|Ff{r9!3LgqYu|zxKuCK|R!Ky#V;BIEigBw+%L6tmCi8 zgg6U}SG;ZXAyjv91YKJ_j5uqG5{TE0hczWmqzmC~5}{pQV9$cLWjcX*0%1WcK#caD zyOxkbZHW72B~foH>j32*d$Gpm-Fd>8_^aYA6M9es;%>PI9kgz~mauW$$5?y)Gxg?S z!w(e$XEjYfuK3j;ZStPV@aw5VEc?bo`-0}fZQEH)WDBfV{io40&j7gECetEB?X#45 zfN#T|VXh9hU_Rsw)FCO?bJjcESJq703hXO>Ev$EmKjB8!Wu=dTKHQEQNaL~~7;Y(9 z%itFwBYkt9mns)wpf44=Y2vph>f%(NDCIT6^|0eJv+XxVWak0ZnD5iYgO2*8gKW(V z2W3wPb)ohAFXNx}m+VsgLQf`rZbFg9$G-@%p~2TLtE7;Uy11{lJbs!HQ4RA8zVe>n^)U%t2(v&YcC#wHL2@VHT#^Oi%spL(=`9 ztHsZs!L+QSNTHkggm6}8r;$5fv?Sg5@s87|zKRQdm5RJOag615JQTBRB zrEYoxda$9fnMzswiLaCAeX&t>Nq8I?+wY?wBuN}X@f@mkbU;Y{>fwI3V4Il7&fFtR z232^`=}S64)|;$NDcTg!Tx|mS5KL^6*eB(0s0CW>= zHuEn{(y`zk*z~E=={p|%0O5+<8U_jB&Tt;X5r0x27Un2+yj?f{1<6V$!8S zwN2AB(>AI(6G#~+rNfCnn)J#fs|NGI1$(FzOAwuB188(i!(Lj*ezazxFY%y43&2O+O?k#1F$sa1W|d zEVCH;sW^YW&^!8Mo_kwJ!IHUf-Lh^&>F0~dbfLu?KeJ5KB+9kEIwao;c`QO5N0y&= zV8P6l`zERW*e#vXAh+K^hkDYx#%SACyrV)U_?9I#sbk0JdZNe4w~&HE8CIb}%d!GN z4>7s%QE$D|o+7^^J8SpjN&_3!&`b&P$l=yJhYSZd*P?=@>iodtLrKR`cGx><*`CK_ zC!p#Ir@;q;Um!en^z#1W8_11&Kcm^~GB&29ZuFaXksh7DWD#1#(t@Nfs=}e1AplLX zTx7if9gm8%f9`vEsQWUUYci}5I&?KtIbLS_#Lh#yTC}nyX5DAFA=z*tCv*L>&UmG! zkHX0N2WyCJQ1;#X){#ilgTGLuaAfl_dMRRSH;4R9BUt=%^a@t@iKp83p#1Pok0{3rU;A1I-k4S@5=h^ z!mo~JEd|YlOxxmHl6{Zv6D8moyjJJ&8Y`-xvD$*VDop>pv}-5CEu@$Op>a2~oJM$} z`BL9$=&Y9@|nIljq3>*PYF*^xT}dXRva66G~mFM40<#YySnfg zxY$eut;pk?Bo43U0*FJOfPyvOS+OWTx%`BvSqtty-5gGLYEf=-a(Ws#%V=?WT>~=xaYo^&6A=C|P!nTda3KvpjNaWe2D; z6y+yh9mt`l;tB76ZTI@HSH5@Cz>$1022c2nEBd3Yl9lD0ZIJaLU2jj{rN@mN=6<@e z1AT3JJS=~-46BobZYDH2Wffm)k3~f~_}pG=JHbRA-NzSFw7eE!k>(P!Lv;Ik*x?f1 z#kgx%8pK$<_g~ouX<fw)*aC3hfNHYnw#2C~<4o?iWRwVC3v5OL)3dt=wM{fi4aOj9o z(LhP&`dH}1pK!OT5@EYBlLqR|Y+i$flWzpB+?pAol{lAKG3$E$<$nIprbgXbA8eU$ zrJ<}O4h7}*o;tQ+lUuF@ok#mNGZNTEvHG_ghgxG!VFVoD)&F)pumQ%t8z&k(uF~ec zD&-{YRPA$0HLYmp+r9c>vu6Tajv|fq{=m8Q4D_&dC8np~;_v zC)#rwST1gHG=tn$TISmHBv|30_BRK9_tW9R21PJ1yQs;j%H=Azs@A&$Lzr<#XY4Dc zE$6TRQS%mV3*^(H5|pVZ2l8sMH61WL9$^wEQobo8CUFA%UJ>OJgkNDzWi_!ACQKf2 zS%@&BTA&n$zbiM{W!QC8rEfg5;+91GyaTq)b8o#jwlQw!d7#82=%gIDG#hT3%muhMGv)`di6^s!xuGxB*|nZ8O?QVt~SO|u1a1u zyS@PvQ&Yt#{xpci#@Ktaf+L#OK#2ZHg5f!iuGr7tADx!W?3-0W$cBylFl0g~c!kIj zbDv?Tk5W!;sIRkJFahI!%oyI^?`*RvJYu-?1We6cIx|viN?dV3`D8pasba>H6Jvq$ zeFN=^nBdGtHq(J19dm;?>nI-!hSJ^~Zj;F;0R0CX!@oMVFXtRF$Zi>7WzpwCB6JHU z=10t-2_On9_{%;H6iLPMvYHQOOGqwCfXu()Qsyh#$BHe<1*@9*dGiJQ52yupr^L<` z!Su$QjZzngW(v8+%bnMP-?B}`!7(B&Nu!w^NrKkNtTXNsB#&^c<%z2Yx#E*FnpsnP z89NhY=x=MNtnQ_TnVFW78%*th&0;#ih{hULmNT)xVJaM>A{uUTr?A2~1;Irn=uftT zS6az(@OwEN+Ez8YLKU5+&5`;=D|jfB3p#j)b#sdJP5;X38|Z*=@3Aj zl-MVc$Q$0>#IZ*B`%m7HXLRc`k^~8i4*>N}!8=vr896uP@xod=aV}|oM{a&qr?u)i zQu>z8V=hBg+(mu0Q9WG4YPTN)5j9B5Jk$(*e-sad#gnqa&Wz2dDpvoyZxgG!xEki)S~O9$d5`P=30D!5B={ zsuISGE>%1@oOega7DeL3gH@BZ>bB;;#sXY<3_q}4JA&0AWFRtyYyk*3mp&pbkwl)5 z3}e3~u+o4g^pIfvZnWqg6M5uoVQR-VMb)YB&u_bWA8d7!LAj@xTb9wgD9sDxY5k#UWW6a{37gNNX`H;YazPz*isi~(i;`?mIqaU1gE#TR(5aFDCg z-FLT)xLiMrzTPp>bXVg?qO_fRp!2AA!Cx)9OYO!78?vgenq0c1X{MH}iIpc};RmH# zCXOWSu?%!`iN#2rxw}r7O-Oj#?RdWBAVCWxfsQmi85@o~QbLlaP<3y>+^D_f!zXL% zc<7RMy9x73?|$X`0ofJDMgPUET}^|nhk_SgvO^sngj7*`nFUfv~U9TLY`+U z(%1>ei3Toijk$C42mIjA2wv98zruLH8I?bKMs9yrj=(LMWg0L}~d+dDp- z0PG7Yimde~o&FRfd@QeYF3#eiwY=FE!5-IKFzkp=3s}4YHiFj&*oTPtjLOWUTba<-U(^u?}#amH92Jy0FsBC9F z^Z63~@Wyi7bqkQM+zq`!K4?Nl*a{6bStrXs2cF>XdCUJz8#?I4Bqfpq5__|+((Blv zWRD_-eQQyjg`5t<7omrT#RgJ**-9d^Y5<-gN4!+vpEAa z(2)&~2Y4^Ky8;&S`HNgyU1(c{64~l#!R-8fj?n+iLXn351f)I#@tFHn$&rzUOSYom z6X=`R`R~bvPZf}4r9JxhZqtw7ULDH*RRxqh?Q*%7%m$76k>FF9*cwhj=O&L~CP`Mn zU)BbAsr7Kqa6^uE?op0$?b%X?P8KSNzz_zGNnRA|j<7>wEeL0+7XqS`0jRWUO)zCOqoouxX>0SpjEGK)DtKuD|t;=N0v zxVx$@v7F!N3jz&!BoO73Wt;=wG^;B#pMs5N}UPVts2-)%R#_D N1zA-Y;BI{L{{e+~Yq9_U literal 0 HcmV?d00001 diff --git a/versioned_docs/version-0.45/develop/advanced-concepts/baseapp_state-deliver_tx.png b/versioned_docs/version-0.45/develop/advanced-concepts/baseapp_state-deliver_tx.png new file mode 100644 index 0000000000000000000000000000000000000000..f0a54b4ec34bbe282ed6eff81369428d02dec095 GIT binary patch literal 59007 zcmeFZbyU>f_b;sE00J|lbcujcN_P$2pfI!uf=Eg?0z)?_2oj1Qpma#rAP7vz}ltaaD(*S*Vs)R{T&eRiF_U;B055n39Gg!t6>*REY7R91rPT)T$J zdF|TuFbEF#ADwR_sn@PCUQ>q4Jn%H#$iRL1Kz=BcAi?fhJ7ktE`zCMpV?DKeI85rE zDl~$G3_BuGh721H<$Zfo=4B}(ek5dxQ{lmv@No8 z)FqYAmMHtPG?O?LqN)>bQw|M}kdC95xP7tTFXbj^H&%M)f3{iu?%9uztSYbWR8{;W z!B~Yqnyz!BX}UaJkCD1McZncjRVm~!sXHiqCl@BDzMN?&<^zM8cbQJA?h8Z0OMkoY z!x87L2KAQQ7~qHXzK3f+;;NnwWRFRnZRpySG#-63ev)hO7KW&G&b>I_?>D-wkzP}4 zT7AT3lGXKgQp>6W_{%iJ(Zmed&X8WEYQ_A$%68P?Y^#2IoXhAl zr*4DiZqEZ9!w{mt7#g7o^v+GIp8YsSiw4QSAQ3JF5@C(-lN9Ddq2{}|UNDLPrxEVd zkd|aFBb6I8f*ZYU#8T(4UHTm|9cLXM#y2R+GE;H|5dc!gKxQX*I~((a)pGbP_+0Iq<@J|1*v>GFuwr|-n%hY zW>MSoUCGdr0E0y__S|Q6FxPDhtQj(%U2&i$0mLr&`rvLT?RD_z8|D%3WN`~ZHH{8H{Cc3bS9$CLf@ z_=B|{wsR-TSplcJUm3Fg`uWcckC`$`Q_s0yGQl_*83HP*120(^QHjnpp?Uyg=@ks;=Bxf@F3Fc#2!anyYyBu9RPvDEj(nMT6de82eqKXdD{`I^r03vMTZkVe=Pmp0al05vJ@|dT9pj_IC@T7`fZJ zJ-nPQmV?tMpFNjImjdcPvB;s4ZINSqh|IO_&lG(8C4BQmF1OWKsk!@J7uz!4Z-#(# z^I6~h7&@1pdw~KyCC!)5M$G~w1W0S|6VZtdPkgqw72EC+`?#oRe#qUkpA~RfYvOnK z<7nxPX&55cC5tpSg4Y5r!{Q`7cDKhw3D$=>Vw4bQ#8uz?BKhb+9 z8?qS4{)Lp8Gvu0PoG2C?;R?NfJusz*lf2z`y>}yG&xGFY4l41|f(e!AA6+H4#29}E z6_ivDLf7bxp#2T&UnuJy~AJ{yh4Gu=Z8CUvd_0ycwRX8h0W@9J@SZef1;IjpN$ zHKZZd>wUas@3UEz!evnYg<8<=DKPhEjSNxp6=^cPZIpPNMwZ`EYKH5eGDU44*s#66 ziQB8j-3}VBiN|fBgnCWBUhiXbKuE`yHk__~YEsOABk)}h4z#c^TF;_b_920bFvg<0 z;}x`Y=H~i3ZQ-Sbq~^*qkS<9eJm=%ItX@b?V(D<9!BCpe)fM~wRoz#2^#vVVM9+8H zfMuVIH2QeFxn~g?rM5F`J6bGI{Gh|DX)ct8c8*HQzk!gNzq4`f>S)q&v*~QhMT!Se z+7f=P(71MRCg93X=y*s|s_Jlk)F?~RukiUoM=ax#bWN zo>JMGdCrAwB_P~qfi${%RY2!>(FTo5}UOs-TD_cJT@oX#NIdlo{!>IK{b0!+6yTcV@P8U`d6K8<*5<`#zXi?-*8!?*%^C3n$(~ zvHkRYyY{_bf+quEn|1DVg?23j>hcI3xAQ6uL3C83Cf%~}2P}4ew)PEt<=7f6$#Thl z{y>>k^!LwToAYJ*xfrRws+7co)Af@2@aug%SV39O_aZ8J;{*^%Sp{t`rlhYqy)Jko zve(ICVtI|Z?AebyEFlq3H5VDZ<;YgXEaIw~FHgJcTvzAQ*GGzs9EFITk)#Y4K8}OH zt2bzUAu6f&pBQUP=0x%f=@e^7UAP)Gc$TTM%1NdBq@M`bjx4Sb+C+sBFGhvqEC$M~ z8H0+%WD(WIb^lfD3VuJdELGgAJjz#^TOpQqb@4jOl26Tj9+H4XR_Cg(^gcC^Q3LCY zDmg<2PZDjPU$69yha;>zqNx^`xqWe%yjR|ZrC-diKFn2_<2fcV?+R_!S^c4nWNrNY z%q;+|;B-f;E3*VDR*UZ}oLgMxF)SNR%9@5Tq|XfB*p`&0v1P3(eH$!kstjFDcZiZa zpGtVmNDND6G*T?bCJcN4qe%Cr)f$W!be!2>z7r>PS>y6JqO|9YP=DiG9DUBiUA9mkNT4}+QMw~yV|Y9p&>VH2H#~dFd%Z}E z>@cagecP*#22=>6L|?GNvK|z#KnQ(EGt8wkGriXerYbp^sp2Cis%#zeh>66TgG;4z zn7a_-zKq)NC*gZ|CCsHp?SG4V_k_VE5iwe=OA^|rCNgWX8^f4>TM>a`2bZX7FHrFr`H;- zD=HBWM-CU3tX7tDu!9-+fFyZ^9d5~wE)+Zp)Z+1GT3jl~V0bgX_d{pvQ}0Zehi=60 z$*bsOBSR_+X8q54k7fe`^tB{y25&9DNHUba)j<=FA5N}KosE}M@cj8T0hR>JAb1_s zo@_C57hz8HGNWW>60tes^cpBgJz{-tU5~oWnK=WOouAXqhT|zd$lrW-6ynO8t?MxWJ;(`*0$5v({G zZJyY0m+oq)N~3fpsA&hVg4U^zhg zCd`vlWt{AF^SF%4jKU!V`b<8nPkxfbl}bYwR^=@}l*%DJmCdiJx)gyR>w5BrGd%NA6L<@fk^mNtlV%`T#)1XMrECD zUOnX;#lkgpDxcB0Sv|XTuxVq#clD+;xJM2~0+mSA z_ms?Y8WILrnRVgzj3GI%Wxh8^a&D-r6a1FbSQwWe4>LuwlCxVKQ!{gp+h3^-fPW&B z|7SHM=3`8ywR1hrF_oVok&nEoQRWc;!~+=rR7$$-a=CZaTlNVVwY2@t}vDTdEL4utpTVyU{^ zK^wKyFY4S|6}gJr$s9(S1lRGS5)F60@k7fc@L!ThfrQNE8f$W7)pm3*R&Vv{b@GqE{Gmu5Tns*4&y zkuf<+&PzwJm5Xs#BD_tf2`5jCe{^+!S@`w20m zwI5TBI*G(KN-e7+MY62oe-g|Q}QnS zzMTuIIYE~tH4hi+_s+k*xvv%E)!mJI?`XW>z4Bll6u*fUuYN=UdsUr8DV*>^le1+$ z{H!nbv#)z4d6*rh&##d^RgwDLSx>xi4$_3_#UhbY4)@$>#aJIkY1s;%8P0Ei-2X zLfK_cmNC9B=o#Yv*>{|bQY6{MOH*;E&W&52p`8dUd|AXw{quHmec?pZ8~1GP9QF+N z37e5>M>C(()x6DA>&)kbOwV;}^ukGFFx4>?>$>HrJ-apK;LKRUyTQ1`?u0j)c!XQd zHY(!KsEYe{8C;RP6n2bW>eRMLKWh0ze0d9%y56C88O3W*dP`;rS62nFW6oYgcHy{KF zJV&w=nGsK-0FGoQ6em)4@M!xybQH0NZUfcj_S5ua)ok8&(L$JAT5!cdb^R2SYu%Jr z=SP(0UBpa&nGEPom?@`U7le`OHzqe8;a<-8+2zWopX5WNlbPZ<&F6|l5->!E`6Pe; z#5{IXx|T7+#0Di{#uqLG;E{W*Sb;WN-KnoY-k|E)E8CWE7gc27FtbiXxVW@)IQwvs z(WqO%GF3Qc&aajCai29MPris;xz^>~m4IPp(+OX}&77irjy6_ly=gr^qy~7Y&zwNaN!XeN4q0|{LtLJPRvDud29n_iCCFspT(dWMjj3E z*BuquRbn#@a>NqDMRc|S;b#6U^ycQh_bfVu$4mK;iG9aoMB+*;mKy%Qm#dp0s{WAG z{c|WJC-^=1yA{FlGBc-5Sr$aq@X?QKS;m`?TdIg~Y!h3K{MgjmVoVqjYQxOSih*m!-6Jig3U@l^Jd zDz=W&yj4b#zLWe*2s?o`-C(0qNpQ=r>e#%mj?EWVJ{x6WlZmc;nZb}U91b^l@mLg@ zC`6Uhs5Dt9&b8F@j8r~o>X*PgjAAV~9HH$YVf>G`#dyP~y^J2*|g6 zVQ2s@2iqB-U@aekr|?3Ru+86vBA?>GFd;33LQ_ApxrP(9l4R+y<(I+!K1DTfn$!); zYbZ4{+eawjYlsW*2zN609VA4-e~#%G$x7fH!r(Giy=lK@hMPgl#l0DwuQXb0Lic(Y zK3t&tRUQ$~R9>1{oAVNu`XV0Mbpk+3<6iu;2GBmnO2a=0!g?7aFgOGloQR)mh^?kGhZOu!7WF#vL#|)l zDIVI`4zWR%&{u(sT0=oDnkpo>mO%`7#0nxU(V!m?xK7s1ac7??jCLME)OUY?Jo1Ez z9?p{=VlG)=3&mi*3un&1VpNZwAjfHLTRnc}$cP#LUI~Q~A8b%!3I1+3(=fi;VhZ;N zCy`+UP=U4WNa1tKhZ>u7lA~{ZDY1Q8dR$a%$sSzcQMAdt2 zZ%KB%uL@v+Wz!S230iH6!Kwyts>tvAMq#pkIA0=B0gjsfinj^^t}Zo%wsClQ z!-m_-v2&vR*>e`}5o1u;22ktB+J(1x+IS2se~l`Zr<|5cW@h0m+fl;0I&WhAE2r+G zfp;n7f!8-Q+ANaOC#5yuXXpfSMGFsBTH1J{)#v@s+b+#Y^NF11%J8RaDoSp9r_Rvc zop20+o5JTg_%OoV4q&!vx9S{!`Af-?i*RS?_}fgJJ?TcIqG0|2<2RimLxIubwohl_ zrg65fYxPnkB)lv(yG~c2)B4C--;Q1zFNrLOLswy&aX8F#6TnN8T*OVCZJpf|3Hv$) zip+K1E+p+zGil76U2ltO%K)%HP`mR7-j?P@B~l=&@}WEAfv>Feo=?WEGlzHY=oJ|j zvDvdnvy>FC=DdKJuq(NA@;*)|x*t_)`RSK#UNuB@t#nugj~QUhj9Ojl0Ei;u>7~F} zRrtxuH|ZVcFxTPD=ac>Llb(8;3Zf<a9B6r}xec4TgMWTXXoVDlYU#(76lbT$eGuRCIbe!lK&gjHZ2hY6 zku@BgXF<|7hQ?Sr7r3IVTAzqjRUX~gU`$|Y+M3gLo-eFXj^kI^Q)re~k zAH_8ki9y>u>=jdH;GlLJ^8&&3X7r?kV6|sj5y|RePlM=1M?0vZD_iQ^v|-8oK{PLN zF=Y`otkG-k4tU+HcT!al?C`ue0-MLIDlfx*@JTXK`YgT>S{^)z_#w>aJlpWhZIHw4 z<_Lv3Uhu0RE^v~RZYCuRf_lEa5Xctz5Xl--iet6<0-C(vyAk5~*3uC91mLd4ju3r3 zmtehygp~$Y`rFj%f&kt%c~0x~%K0GEn65|NI)dL>Ew4ew*a*oQu7{VR#>_cauCJhU z7if(y5+rLqATEmfHCo)gFD!+~5PwcmHVs!l-J1sv@61^)WHUYI@x*q&keUp20_zw6 z+};jAGw$cRU+d}b1MsGB-GoG>1R%e~VfchppoQ`s{W-9nM1sdCq5Jf=lAOHvS1<(X zA(A-IGAerFYThR~ZASTsb)Fy*8Asx{GPHtSM+Xq$UI6yYn(hLSQvFV;_)jG|| zzQ+{Trlb}Hfc56q;5GmLSN)woa#bnCj;CBQe8sze^zr*ghkX5&V%CHS%Z^j!r{}M| zu?{uI`}8Y_1-P7(U4lR&IFj0jWmq_Ks>rO!j!sY;jcpYwc&Z%ffktXbR=?YG6ui`W zvMMXT0!gK;`)Eh6a=rGKiUWU*TW8sWVn$H3UJlFD|K!Q&quptbSvMPt8S%QBq5MQs zPSTN|sMn>^C zyBuE=0LhM2SZj_tId>(p3i_QMOnJqL?}ejhOMgmA5{362KHH6>35;o)l83{(INCv$ z1214C9eh)XIM3hNEPzoCJ!u?YpD>I5W$zoINdTUalM+K7+zf-L-YlZvOa;x_leofo z1(0d2h^WoSodI+~uB2UOhg*dA0iqhHMwJ!@T-N#{0J9Z|KB&L30vKw|`ZeOY7mv^w zys6hO^1DW#3%Lv{J3&Du3@WhZt0vV}RBPUNwou&d=y-gH^sjHPOym?GIP0TDMnd{{ zN-`OuZnWdAt$7?QSYZMsb!&GNwZ6UNSjeV}p%!p%4)c}1Pr+llL2bm$mOy3sc9qp+ zeN~CL%nQIBwC@;AVpjUW$+p!w^pZoD*6W?jZQB@Hk--F_r62j)ZN04aoD}pc3xo%e zVYo5kZNhK_>S@)ZE>08)r;lX_KRSM0enJTPq-8oj)9y-N*prxZgtNBoM?+Lk?c_bY zbxJ|gXD|X4`z7xU0`V1KeXmS^mW|iA}SQ zl{29Zw#$?e^_1X{t87Plwi8ASuz`b&hefn@SQx*^JhfI07alRBp;XvVItVNaNuIwF z7?|WJIANAn0)eBYzr6F@o#%Fz<-&EGC^%!p57gB}g2~paVt31#1~2Y3SvYbc8GWMT zA4KFsR~el#$`~V^e+J^#<%bKIdatrlwlk8HgNli!+V^=dON&cnzE#XOA+=U;4fr2mura72)O zR`g2^v}2K*D-)oT6HI9Q1XoOd z#gnXnhH1n4?b?)>)HC;D`V)KpIv?COVqQ8uHf?#m)xmKeVIC3vGk$GWQl~FW+$=O{ z#@3u^MAjdsI4AXhN(iTDaoGV3KYs-BDosajJPC3!{rG_6cpP*nOW9oTha)9sj#J6< zfs!oF^jXjSc-?qsmdkRo{c*~rsUI$8o@dH>4}KfFn-EAu*2Z%8DyDFwzaL7SW|rum z+}TMG*SWlpVoC4|;s-~z(g-AvlbI85Y;$tEsVs{6$ArUDLEdorRy9%O)%o%Zas8j; zdPO|d)|vhTroOu(XHS0hkL=YE;ccWHzx2PTpQsqhj22lfQ*_w~U&D4$z~@3>5P(ML zn$Dgsh9*KOrRHEzHN)z?VjM`m@4AIeNk=(|V?t+nQ1{>ddgAW&)j@A_Wr4P=rfe?N z9p07hHk|*-XVB1iU?}^0J)yq6_i7xtpd8Rj#_JMRevzQCTsES@AOBq>4AWLAbITVldhdzz7= zs{J%$3#ov!7!xlG;=2YPEB*G4Yz05siW%)s-l<>fpw~N2(@Wmp5%zJ?B4!aC2pHr) zJKERW*o6h#AM88UKHzoqJzrw>aoOUuow0~7GN>B7eXwm+(wDiUq!Bi$IC(wnLA6=R z)zcw{hS86DQWNq|5iZ{sMD#vPagS7=upV8cWEr(B*-um74LF~nr=1#_@nrhCW;Qv& zy*}3a?IoA>dxyqW4bhU~4Abq$ikVxR<6W^O4<|EIdG8#be5yP6tl_3vmAQ~vdPTo? zC4iM#*j!=^({Ea)_h|w4LaMI>*gEiAErb$|)V5N&51Eh_K0ACrb)TW>bBmQmLqDjB zN;dV(iG3DA435@Zh6*p2&U*@7Iw(?evGqIHOWY6VnKThDYcklLRtKRLALK~y%GsotVawa(+gY8VY zLU@GEy-|a*$F=I2d*Kg1xz`ZZzb|2tuHV#~ncnsvC#RfW_QzPBkC;M>R7+wqk;po`ioH8%?8zy zGTn7!OOM&%Z+$ktAsOR4I`t)*lqvY+Jc;wU7IgloE_da1jia@V)uTm;>d7&$?Xl*7 zt0(sT5;GdYXBhR_Lq$jDNu--$CC!yhqwas(M^Y=<6EVcrmyyn6vrN{R-87^sT4h2$e)?|N9_iv#7ShB`YikI`?#} zA%o6$vFx*Xn|ByYJ7M~0Y$!MC7c0Z-%2lbUXPGYVSe~p5&!Lhs>`bZ0CIT)$JEWLC zV#_r8%H2?2TP0jn$HJax{Jmvs!!_fF_%g;PH*M1Dl4IZgUCoJrPjtzpjc^1>s0wL_ zbRaN32h`463CUW^2UQkj#G837=9nz8`$bOBe=2FD_(DMMqpMAQfs3Zm&NuNlPFL)2 zE;qW5j->*Y6%Z6$X^zc>#^zt?T^gocU2OLu(Dmr1VBkOsgcU@cD+w}_Vot=`jaP=nNQocX|0zt zb=gGPhxkF`!qq}ixT0 ztsbvdm8_c4H(P{sv$UNWo<#c8KP9l(T_>=2jU#gJPZzR#FnYv29d$~wCK?_;+_-f5 z8bf#c{?EGGf>twP+-cWlE)386`w9ah=-khhW0j(PR{bXZ`Xg}y*G3jGs;_1P3d>sU zi_2jm1e;YNd>aFEn05#0LdNPnj(3xd_H~J?cX&REM_`tZZSIi`w+e=xV=-S!Wm!*8rY z^f>yi4L^vAwE4{C99cN=`Zb;Aefh-LT5C@r@7oZv1KbOb z5HBtxfwHCE34>R6aP1Wl{w7s}3E`?dVzZ~mjor_N^H-Hrf^n`Y0M*dF>i+IX?cPUk zL6_6Jv6Y@I6y|dkJk94*o2@l91HVS<-4d;#&|SvUs98PJLr05j3VOq4UFoiNBoNEM-$EEFt61I+m)Ny z_h!V`%+`eLGj<}Bbdjuc7o@2-Z=+CGm|?^W4i{&~{SS)(-w4piARbA2<-s>XI~AfM zB(DI(PjePa#n*9Yw2N~qa_b22kaE}G%kKIW!o2D!M{f`9|H^+K>nwkKp!_b20Q+L< zmI5*5_7blH#(U*OFi4#{zrHPkzhB`721kFxD;Nl1+zM+cTTM;Bo`k?Cp7C9I!>pO= z$=$D64VdP&M`?P34(E_##qDo*4H1nvdA}4avZKymJl+|d?3&^zlndFC+{X_ZsmtLH zv=qQJRYtpr{TIj%w5JIIoLlP_R&oujNk!(Vq7FzH}>y+T+7c)eMi4-)fpAL7fM`>v&BrJ z^1XH)+UI+>GBOOuo>x7qui9hgJf50p{ZYx8ep1=%^*H-5z%uQw(`s z)5CkPl<^8{Hs3eNdG(5jnu!|Y+Ak%C{zv21n`@s++$9WG-po(WxBut_B$%bF-+~tsLR_LCUa(m zCCg&mJlp*aO^&4#n|K#SPhFYqCQIjAFCi$7~jVWsj^^t%r z-=i8(m1yegV{ojxZ?nX{pte<>L}%lpIjce|%D2 zzd@Z+3dQ@T+62cV2>CsH?cIWn8%=F^{|iOy8VJQ+hNmf=SVikd6E!FmE8fs#*$UmD zs*?M{R^pfeShi1HU+=NZ@0_lm^zCrfXp z$y)&>yJFh8o2z&h??NvW%vsZV21w>)jr;U^zbx@h|6;S|CNxb)VZVEK;j7p< z69<&U`y->2H_SdTeFG$R2R|hOBGJ+6p~XQTBCncEDv9sJga3tZ=tB#JgdyiCu&iv;`O z-?Z!Qs#5hogK&;k^BBfo>5oL9)F-J6^0_g44(HvK~2qV*p4v-=yXwOdroJi$h0wI*3f zTNVrzN&O|unSN)vB7!@o-7f7P;;&xruRBs=N2uYk7*;rJHjfm{tQNCpuJlA{N+sWA zOL!?0_iIcN1W6sgX!qsl=crFq1{G`i>srfXw&OnGbZ&c8wf(cZJyBa2f!rRNrI^IC z-kP=oc|`XXsiq43()M}02xYswYVnBQXV8--p`tTf)^C6O z>&V7PQGsIT_-Q(IZI#$bhQPK9n*Q-EfWA+hNRp6x;jnEtO?1yOn+U*jLZ+7A1)2ar z{%7`|wOzk0Y0(#iO|X&f(sxg^Z{d7svCLz8rmw*IJ2}1c_qQ^bqal}hS^mxm>8X6y zqK~z5Rmjm`O4OdGjcI(0|HWyofD&CWyW7^(cu^S9xmpecCF@Pus2A@toUaWA+Ib@7 zGAcLyj2U$SO{-|yebV0j8%JKvMfgYFaC~`5Ts%1`X5LOg%T6eOv<@OVlHq>&4G z*eJb|kZPxa;5v*t{T6Qc%*g!Cwsnr`}r1!mekRh#U_~1mUElb2@hU30PNh@PbY7S zks@fGz(70!cTLNWZ0Ow2LfISP&eEog^xF;lv8pG`Pog^e*s^@*J0aSXgH>oIuaGr> zf!zVGa3V)J$vDg>t`y1<_??%L^IYw#cU);aiC%@3`X5%LOLu2l8sJ5X>c|CfD3J#% z5idrNiEP(yH=Xt6#>fD)b=+H90T5J;B?uR>=7YE5DYEbF9t1%{?88fuy^mXy^pUI~ zf^#aGIxUQ3x!LKFmYh<0tPE*pd4#aphwkjOMn^WA6M-0R`H8 zzQiQKsNL-_@tFRl)2?&~D35ucS;R~UyQgYh?7=k^=YAhJ#-3b;$^oLr>76RM1y?vB z9Cr^Tm8+Wa831eJfRaI#RH~LKJ`T%LLg@e!pm8F`I7qEj6j1hU3VtOD7*pg91DbI6 zd8wB*k+g`xG7^CH#haJA&z><4jWfH+@pPJug+f%vI4Q)v05EQy6rBRP9j@C%wC1am z9_vLqU9tB4*lUiu;O1#IATXETOuc{Yhu;iyOkBBYR+Lkp;VXMgFfg_cOZKV;Ou_7BXcc@mK;fR{X4K%URg&8j@ z#gI~!hgsa5hMCj60xR8GjVc| zOGo9B14v-Fb$yy7ltt>vH!^+rq&k2lo0#BWuMNM8ufwiwS!H_|h2fLQ za$n}T_&@^SIMuoqAduK!vs~{f;bN_Vize0JT27rr!Ta68AvEm2Cd=LsCM;c;&$bKn zuoQ6eD`h&yYB;Y{XwNf&wv)_RN3M<9bQn27;jeJHUeY`RqZ?7Y-HDSxw=JU6_))KD z?ckG9bur65czR9#i^u0mD2&y}Jj(XpaL4>I<)x9zVFQtqS8zn)S2az$IKW2GK>o!> z*n10Ho890+6aWs$_bxZUSUQg|Aj_xgiyGX*04rK#B%;Vm4-NsEOPurLL2%_ zwV@wOMV6R(fHNmtXftw536C`S`5fP<;&EB(d470rctA@Z)yzZzw^3qXIhENYz`Fie z`oU6m6n8n``j1Lz21>ew`%AxMR5yodH8M)xxHC3D?%Mr+U4GM`dpC2C|79WMupt6_Yl41TE*dp`E zWep1EhuBu_jg((Td7w!X7`15T z445sj6b2fI-azJpP4NKAM?HlAIkhaK8sz(H7r?68$0ek8)p)&_T-XYJ%!)Yb#J52Y zVXe@bL61@pm=&%!A>Dv0=sWow+@?TZog(YJa>VU;O>)Z#q6SL+ZczPwUk3B7n>U5$ zZfQM*LKYb$r%5Q%_H`L$K&y&nBOGzQ&n(A5VKQylin* zhhaR20Rf-N18&rDWlyLSRM(?R1;7)FSUG%}ZWWpx~bi4mp4IJW1bL}Z0#Fj+#sd#T`XF)X`p&-iHp zKA7XPshTpSsJI&2Pm8eE_n&;L;{lgXj+o>^r;^Wyyk#N(CCZ#dUjGrMy>%s}Y691I z7nCWDPCfU&4u9Bv7Yc;5U;9xuUU7H z0Ha{EiG+5NVS$O2M73-PzI8RY*XRjwqxKAX+gGqwoWNGV^*LtQ=+e?sawAmNb6;4K4@Sg2}3fQ^+ezs+g8Y z^1B;gmik#a>9#%kqS2)L#@KUNg}a=;d=;gU?H-*~fQxI`2i7)x)H@;niiCoB=onn4 z8w8VDBY*>4O*aBcXFEtv&%lMz8wofh0@08{lll>G^U+EQESOyWq`R2o;m6?~aLdkw zM#1Ek%MM_D;5EhE*N_FC`uYLdC#*KJMKziD{lFy~l@xaEd0{@WI`p;EP%Z2TT5hal z%DZ|S@7>l%8l|4kf2o=yF&PXc1c|!TfD>~O1WFX_*P{>EBZVdpmN{(IdD=r>K%p3| zXqJhmV3%hEIw~IjZJmcIh>47|7(x&MCf!B_;G{`;}YDAoR?ZkZFsMP zx<6hwsE*bF^gj4p)`~X*aB>+LQQ7YkRIpq#bs|2D{E-6^D2t9T_TLAkP{<7oXI@N; z$Y>~hnS-T=o%PS-Qv-p9t;VzsA=gD-i((eQr8&$C;JUVWX#FCk-=UFNGGA{51Pce~ zy5+TO(0@b+Uq-UNdisouNy`;2Io;8O!C!^}ODnMe&D&t+u$5i0hW1W zS-}3sG6djr^RkzVWEfsxXW68Q|7S_gyYV|QHN)P@ueWekFhQy7r*)`*GYb)BPoaM3 zLa=|ZE4}Mw)JnQfKvdAKzK+gcT9+OH)FqM|LwC)@Z@NP&$h=wTt=5&@(Wd(2GmP9o zsiL&9jC{auT{py32>$aCK7e59@R;JM&}U^RU2e#~P6n3jp*My%SCT z{dss4@GoAXFdbBoc^I!M6N==&2n>!~Yp{keScA&pQ32aO`!Iq5f}Rlgyu5@qfgD1lEB4VJ$dyj^Ft6ai7+I`53JBBI~-y zo9jYakS{}2_<;$xz-aOBwd2JxKzPO(h-PZ3AVjr#iv{En<=r!bdJqngWV3&`0RNZ* z#9N}khvaN3G(S0%2C?>6%)Eeh>Vcpv|FJhHHiR|25MaUe8(jAP zsK$~ID9*s*8AsY2+68I?b2Ic(FY*4yJE_$F;!iO=@2 z6%Ur0RRpOWP*spUgYrL?mxho*fy3cLjPdD>Y^`W|H_Z5ax_bKVRSa6`4fd$yKJw#A zFhR?o(wJNHkNkz`f?`F@?^EjGq=J?>$B6yebbL0cs#qBMHc33S#^XPy&7UAaXB(YL zHslJv_A4b6$%)H=O5SuE64>x{A*;bZ%7O$U(agx3A1l?Oqs!Ur0I*bH1z2^3_o~SL zIe_BPa*#DPHnI~SD(@h+nD<@O#UQK|w2hLC8Gf7)jN znLC67zFyhxt-61o31tZUE}RHW?#C5K;gSn&F_&Pt52G-PzKxnE=$U~3yW$QFND0lb z{_+br!k4cG66L66%kqym$+l<$)11S_2*7Q}-CjW6Xp$+4`76z!k6$TtQYYQyoKi)$ z3xT8eH%^t{UuO>5Abk^+(qM8QgRva8yz&#+iXor842k;NWB5K7kzog7cYPR7@!BJCl0Zqvt2`_Wa z{A>vOMW!kIe%G?xGiN|w8`C2C@ZT;pSE~Co7raBF*VUQVFIe=hppFVc@3p~S(xcF| zi|_`SA%{G0qm2JuH*(Xn%XwK^$XoG}41FFTF+u8Z8sn(c0q=~k68&3$u9@Yi9&j9^ zYcF(dhBD9lt^(ds@n&`L(J2mkiT#)4R>_Iz!z$1T91$c$Vj+4e;MZzwxI;qu6^~hR zkxxQWb92y!Vx$Eb1lgwX?iF~agwPN$)c;--0aK{pb>s7?Dx+OQS{Mo;H^;-xNxV-T z_@m7Txs)C<<_+!y3YuP%9|aAY_N~M}QW(MFS*UJwcZ)#&Ju)f9$K5i6tVxw`p^e&U zh)&by-XgfIrE;%xzf<8?90sw~gG2p)@ePpCDh_Ye|LcrUN_6!>^xsthSR}Ob z26)E(wpf_~S?$@k2wCU93(W{{nnOGP77cya|9=v#Pj|BNm_ej6>s1Z!;wm%=mn%aK+ zQ7;@gJ}&U9#=*~id0xz5m4vm>df`-XCzaNy+CSKSs$qPlUc%?%kjGlWHfFgw?@Hfl zbW~;n#3z&&>p)TX5l(`z?AsUMA&Z#C8XA36pv$JJm@A%)Eex2=!9bxR|T<6v{`7hu9y1B(|`FxuK+mrZT-+4k+c@5Nbn+AZ-qhG(RGy9&y=Jj zmql=oZ`&TcUZlvnPtqX@qH0&_E_Nym_){iZVYw>Fl~R<=W;IDvdwDLP+i;MH-~lV$ zMmzV7yLVVQ|ELwLMVidFHd@jg&%w;O8yJZ`HOtA_V9C5!1}`^2Jb+j3fWoab=il0< zz0?%!XBWH^BS2`61(w_pS4;Us+Z7OOdIF%VXy-` z0X6liz^Hl)q>l&&`)tk&g_zHhbd%O@n~`C!!T)8^_5KOt90Cx=u1s&H>Hysuu>EIX z;NSMI?ZE3i^3v1O9fcfcj4uFUcFIS6M;@_vc?w>R)M|LVVR1~j;RqV)&eQEQi0TN# z_3P+}x`tNY3)rn7sM2+?n@Q<(@Y_Dx4(+Ykh0Uw0dYE1!uQHp{DkBH92zFNAP77dID?`j z@GIsa;8&Pf%&$3+5CRC;fFVX$wDWvI)~@S$$z`yW8wm9{Vd|)a!AUg4FxhmdUJgq` z25^0qWZ>CtR8-3j01>kupgToa97XQ+pPR=X*FFK?uKJR9QdtML{C1CMFTU4D(MF;Ifq< z2j*{yB0i?Fw+Wki^be^W7#lI@+4z76Y!@a3(Q}jT+#W z!2VKCu>vPlnZ_(&gR6iqaW)ZvJI377_C3|UBI2M&v7?g(uU)BrtUVMm&T2@G>h0}a zZ33>mN zJKnEt1Zvb^ZucJEm(@?cJ9xn*54y!z^t44#|D7lhWt4fXOBT@R_bmu8ClPUn?;Y#%tccnMwbxn z%WHSv>VfD#d!ql!jW&Uqrvq6!-1RBq+cCihDjt<$cd#rGNvjjjLfrpp~aqN{) zb%u06lUjmIq)iZ)Q~|7zV?dGpbn26LE!YLXFaN9w7yXcbdS^CM81=^IET+cgoOC@< zOKE-lAtA3?WC9h_+b1=`gPB>QGu6Mw!dsXtFS^SP#Fgs zvg==6LqI&!*j3S^r!!tk^RTx0Bf6UdK^f{um*(T8+kNR`N*^q1U0|Yb5KI<2;2B@x zmGs$}4OVa-zvHy>HP6)_1d9;2tN(BRtdmPlnf&5X5^xzhBWhk*cn)}ztDkHKMtLK0LJ}vxl$3Hi3Ht4He4^?} z4~P}AJ^Bh12Ts8KmI$yuVe`3k@rwPyk-`VouRYP=glN++=f4@1g}+4q?}5d#mhCxW zt`n9c|6fb?H?+k_qRAep?pr@jH~A|?X@D-{)=)5TKAcGnKX0T1>v()FT{3pdwdv12 zb}3sdHJ9?})hV!Io|2V^rO-z{Or}c*$LF(n{N&dWmuJ(H*KPuE^tnx+Bttqd&1Rdv zF)LzrY257^Ms+-p{;#J@(U=`n+CKB|jJ>*?$SSiWN0)A&WHe(1b_d#tXXc2n*oenQ zaZF+xAbGDA5VQ?`={|hI*hfy(U(_e+-0Z|nS4SG|z8`&yB455Q+K>I6Zt3D%4qm5{ z(jh~|p=|I5Y4RY5^{Fo-&fWpHm6A190I?x!2_e3ExoAH$pY%YdIo-A zE9d-hV(8kvvO3OU4PN-wM77?L_m+-LN*}BA^XJK58(>Myld|39aK+p2@aFfUYxg_rQ^Jz|y z#UxR>0roO|?B2UBItYDgmwdq~FVkX<56C4qlKx93 z(3XyDA#$mzw4$h0a5dY2hWPmJ-^J1A8`4o8|KUoDF)hIGvvC<$P<{zl8GZ#t zN-j(!MT6(DWp+{Buy#Ik-p@ zho9@%J`aGO6>@|sO#8G0<$k9*3@#E?qfSXWFa}Se_bb)ET!_FLG`x^Iu)qtw*X9mh zp1|**ins=Nb(0u3kaA}350c(CV}!EtARVB$eASG|>1QQK5bU}!cOYLZSne{_uw}6a zOvz(nwUf4&4mgcsuyeXbtkTL{=B)vHI>xi?&YKk8bviu`)W*bnYo*sRjwbK>Nl1vS z?RqH%!I@;;|7g2mUEB$T!kAfhO$fcw(Ui`xP<&smwpLmIbkkukEKp8^Ew7~PHu`0T zK1Ol*^^`M5?t=Y+eYsk4S&ho?L~H>timt%&Z3)l?g}sU+uq#MzKpjND`Ak9XFn%Gg zf;n`vT$@pNlQf?pB2e}f%G77a2wTdbGJb+<-`hcbRjW=Po%WHI2)s~mvr(?oHO z*dGKB>b}%Vf!MX$&N$|Y zOgX2Gx9{FdPuDRqMfqsk0>2XYug{k;VC7m-H1AuTzZV;GW)wL705O%RjEB>z;0=2F z;!B8;=$;vuf9N+*CjfHD%ZNhAReE{vGRckqPhqM_-w~YYajL9}2S`mrf+)=m;Mu6pIs_CB%v9CTix(Qbhic+9kWKO0Y<4h}`#!Q zyb>~}{TctQ`jWUip)$m=Mn)iJN(6K`zwFkQoi}UK z!>y{bjn+(?;PdLsAc)>b1`{l~<`*AuWmX>4fk~f0Wie%WGQjeFpu zD6Q>f5=tgTUmq^`u}ZD3-!lDkBpIiop4GTni3w+|f+Ap92O_ChE3FGJPxhEMzf_JU z7Y4OK4BzCL(stwb^Vbg^Lbs5At7xkkR(fVX=`C)8lnf8Aqo=(fnvhMyV-R-h~B zJc^YRb_eYiHS!SiKpXY+GVe`^d-O6s!fTXArh|GI_v^UJ1f&+qkIV-YY+t50Ietcd zc9du)8fBRH%DxF=l!mHBy%r}me}Koo)@%e$%!GG08w1S_yZidHvOYF--YCkoFapPR z03C$!vX&<0eLe(CT8hFpy@A<)0+N{}m@vUUdZ)3+2ZvH{IG^x9-HzwuBsjkDylvZ7 zZqw8zCL;?YLiui1|C$_!lHn|Rv_U*TQF-vZbeQD;g?NqG1^x^F!tFuQX*?w<5H%7lTHFd9cpj06&~7#zMD{(xua%!rk1l>KxWZP*)0qZrcjrG?IsJDR8N z4CL%=op>MCgMda(jRj2RM%OScY>B#O3bBl{18QaO)jLV;Kunb2GMDfd2hMkzBhmMD zFdP5N#DD=ZKHTz4o1n3BBQ~Cf**mEl$fIyMl#B~)Phd;16rg5X-fcv3*u0V-hr4))@ZPf0TSJPT9L=gdY`Jn7 z_cC?FIQcDJrk|Ba$Yp!czvT;sJ;6Vpla7g;K>XdeKrr++34V6nkX%$ba;#bNA><2) zT@e=nX>Y5b!BS?@E&$NOw`&)@fZgOku_D|HF{-{=HU+xW%N`3je{9k15|b`9C=&>1 z7`kjGKpj#UPOCbKSW!Gzw9-bQ--65-=e388bgb3Aadg+Hw(#1;>Rhb1;LrVJ&0Iz{!7Aag%58`7LsB@wMq%P6Per2uIT8+!G7();EG4u zR4vI0ONz@YHy8%BmBb4w600Ol#&}B^M;9<9S(Dupf z6QN}54~2RN{)m3VlGqY-DemA@1{tKa=d))J`@__&R)WZ(Nk5DHV%0=``F@1O$+UhdDR>IVDg-`BL)nIBVL`k&IJE;Sy;NVGeMirvPw z_Ap9tn0#oCIKd*Z5ehAe{!|>!u|+C+(kEAT1xGQY$5f7K!jQo~4?xJ}ln2g^Lvs4c z{>TJo3uZuL!u^s&n}#F6EHk<#$?UhacngQb9-WvgICF+x!p-M<*bC!ofBI4nnJ$+r z`030?YxPb1S*ZX%_hk>=5td{#CZo?Q(TuJOyaI(mq3kSBH_e+HWECBGgF{>aTp9G8 zL(>ypIK5}avI6efDfH1g2gkcXkykXz^h5VZ7q7C@k;DkX9}X;Q%RQF8!B148REbyn zj9H@7i+*)f#yl0>6(%bI;pP`;nB^X3Hb6$7smt<8{(9hFeyWgMq`ld>KbjfM8@^3! zA0>DB6u46~u!B`}BB&%TefzQ*Ev5?2RiEkEemd5;kD?#~gxkO4H0XDAFlxOYwh3#a z$NeK=uCHR{5au@^pc5XJNlQ)r?z6u%@LBfRDB6_Z_tB=*C6r6Es0)Kz4ruxr)w)d8 zV9t6vyE6nhOL(v(Q7l3)YiG21&{VuI?K?b@+KN2X+DbG)P_r2wqsLPk70oZbxVwN} z2%x*m`#aKuc_hYT1^w9P)6FJI6Om-#X!E3oQcA>zCiIZ*@;YC$nAR6ke1MJk!{fQK zpp!DsdAKrv0fb|_yhU&zztdrpcOG9fd!e5?@12Y#xnaA?95^6%qH$JA9>!?)A#A_z z3QMkwhX1BS{d3 zhRbR~WJLUviNjB5Irbm7rIa@1li%WBHCPPT&*Ixm%)A=S=pOd_GNWwGHb3}gpCEta zxab<1C$W$w#V^tt|4uI(_FZ-%@bmm;&i$v38W-IFPJ;dz-hXb^HXQCGUv6QKeYDh{ z5m@_d%-tUJDq7#Z0UP)0W+tVzYi*TR8TPi`@Xb0a(1Ibj})_hYF`HbzcKRAX9cu1$O4i=7e4%0>{>>108IQ_ugDl@qgVfjhFldqf> z;bzNFK{j}8U!OAn0XE+UtPXWeULnQ0f5$_?IBQ-59A6KU7eA~k7*j0%X+zqZ2~U>* zXEFQGZqcK4PT3K=EWD%V8cj*u`>A43=>v}8AZ$mMCK1|s-BFvE7O@D`^BGN)6Bk$&#Kj|2DKsV&@c_(p)|8Wfm(osU zlp0jH-hHBS9TRiK)NGs0ZOPP9+k%zs>BuI${y35P4_ zAM>V!hI4=U*45hmL4w7#g@9Ficn15J&5Z{ zc8qzbzE|p+M?+8q&10(~SIVG#GRuqZh!)SVbH=LJX4!hKAs z*ED$86f3ox(3wqX{Q7JndXv*q1j_IJPYa+!Od`akqmnRszO|x%cN_0P3yo1CxavFN5y>T_e ztV=an1OXV#Y)k$M=)$44}xe&Z5RL#r*ImxUO>JJX$mmf2TyF*~?pWWvL|E0c$k zQ|n`7-BOkM$|K`FSUY{cdzD#RF+J2>L}j1rtA*?HcrS)*sPnL{bjf_f=m*<54-#PjU}@vH z?Q>E^>j{U31L<4AACo&DdY1RvxT84hzs|7t(70(HKKAAFbPRgC@q3fgRmEfWx!r61 zvW0W5CjEB@OZ2EBCbAUb`b8y8Mv6w2wv?BuyN3pcR$Z?@q~Y)In*a4oqrc}vRTW4w z1Nj0}hKbWpO0pW{08aQ;G7LbNy6>)L^=FtMV`;|v$1@s8VGwN@S+lq+CbCcLpo5L? zlT0?>kJYl>_e`DFJ%~tCg;`9;Kh=o`RhOyd?7yR#tm8l_?h2W`9>1PDU<+C1mu6qLI8A!PI1xJ#96}W$^0`?J!^v$QsMxFmd56T9IEU~;d)U$knRxu#~bDYIY!ar-NZ?2 z0FPGaAO#FWQF(P28&yNoEcei`-%O}pV$qY5a7bJ*(n;t)AOsHJeh+c1I*4CqYLf&_eYYvmiQ@7_3{=_&tp3DZEBE6nI1 zBR?C&j{IQydZEeV2`R+k`$5Ze1Umho`(Vxk-`Ys|sn(jd*f>y9$1?rHZ)S^NBQ69E znxdO|<6eiL#S1=t@%P#TQM5mG51Gkdb27YmNg94YFt_%=uLtcZ5z+H)G1SR_RmN;o z<0ix5uHQ_DrNrfxV=%1usTXoF1$VELMeI%%x@As zB^eK|56i?*Fyb`7Gvkn^xgB{6H zyL9>pR0hb?j{$AGkLY)G5MwACSA0Jwmw}1nS!~McPC}I~ky7UJoT8bsQGu?X*w>ZB zX4nBTB=>7>B0@I%9oX2`xlAys`C?@TIW!G6-(zqWFlD25<$MC!SbcIgm`tqneKu3Q|T#B_SnE>G`1+G+q;^+iEvR}<%MCV4x)CVxer0?H} z_QId9T;?V@@}awS$+X^+BxFa?^pHjV=SeemrE}f6$JIX;6~v~^^_YnzhW-Ay?nLO| z@0BPTkA~%9;l+rSPz+opdXQH^J7i)Q|2c~N*Yci!!@KXL$(WAgwrN?%!r+@4henH* ziGg@adzo7&*zEWXFvQ1tGmRS|xQapE0fCCwj@&T+cYyn8YOE=*WvBix)lf!sVqFg=Q$8gZ;*QtREU_(8F6B|HmnTzT3V2hp{qQ7vOPKq^v>#t9~Q z_(iSQQ7$eRuGtUL*$dMtsW;kXY4ub(az6`KuGrA9$Wch#hDmVS_8N4b_7EUC90E%I zHt+4vcgAs&N5c04i;o5Tv=kSz)SA1Y$3DxG6H(jBj?l0U-(`OWTJAynG7RI;dq83z z+c@{(24+k74FYs|1RNiOl6F6iSz@{wz_K|f@XxLjmr@Q--Div*ZJHht!VuRrYLN2yR{NJ0GV8}?zr3(q(K@FQLsUO=|mns>-HUlDm!#f(DPgdMij*@gBGQ=bk^q#o{{58us!A~}@0mK4by1qY34Wj({9RPOBmZN2x zwKtMdQyKO-G$oZ!cdVlwX*2Kn?fbYv0g8wG&Mq5v(EKmpW-B|)4d4U~`isC{y!Nbf z=fN}Rw>a+$o~4RGgnhdHB=CJrvD$O@uy({T6YcKszP-B6(OLBlB(+_50~Pn|D6A}n zF%#eaN@~GQ#%TtRY9~RF@X~?wX?hI@WHfg0NP!f*I=zZsmI@E>o+o1?go!(d3A=fwX!c0I9oUCH^bt|cR-Fws=5d== z#yy+%(xaVD>8>Pyqn3ny{He2w2rH2J)pxm*5Bbe6w>FCC+cjE+MEopHFGnJ=qtdJL zRHJ2&y#hjc*v5nl*Z0@h;f43&_+ZGG(a<|p$mOI4ShLJ1nVw3v3O-ALcB130%3Pyf zPzlct)O(vmyYNB3(^zE@UknwkP!RX_S*Ox+Vc2dy5iC{}d_7oBz=wso_PA8!Oq7oo z$QR%KxQ^k4auHJ)Bf$&xKNyLn&mHksg+K|=E@qiSaUInv-pJdjj$Ut#YYk4w%A& zSXLTwdje}8JNAsh@b}+N{S#Q}C}3JEQK`D)jC4$9%|8Cd*BDJ`U6TzgWBJjA1XvBAa+&g`e}(Ol2U9f363RqIQ?&l=mE7D;y=^0KATf zN>*4)rpeKh2Z#_qDzvb(N-GE}kj@321|XE{F)umSlf&tb+Ze12n2QioZ6h1={LhgH z6KWTd#%#Rs%e$}YF+t0X%l?C|OXu0%n1yvW z4lxrbRq*lonQSqdwU| z8jI(lt(5FJ(J%fJMoT}XZ$qV51U?1^)tq)?-{rm-)) zN8D*wj|x<7r$#Ik$l7>~J?cs!K=C>dr-T@>EJnIzjr|;ULRDE6k3Qwt zQcV)JP5!H=9P3HDfRSvKqY6Wv=6#fA8i7Y&ak1;j%$3cb9AEOFYyh0vZ6tCdW4D^N zZtX7&3RRk<4lHjsK=Sx8DM;#|qIl9pZg=4%%5;Tipik#RA>$_70sIL(4q>AV!DH*g zT1cK{Xu|=HZ?N)pp!$;|PnrsMWUbg>$>*am8Qar2-IeXeg~P|}_E{L?NvPD*#_m~~ zP~M721=Jh|>i4eqg}(IMmlR0v5`9?k^DjEY{sY@QJ+CAJ6fqr@$Jg~PqD$%1`~Qhi z{(!8}GYRwadE-17m=e2XWUgIXJAL)))owEJYx;Ek@y-4ZavTs!!^XQedITdXP1NPK z?g+0;Z<&v@wUsLq9M&!63PTm+MakkP?xlGLOl7%<%CAh_r;4k}Il>`BZe^M}kk{yu zm*gon0j627hBW1hRLfn8INCs*#^OjDA+OsYt&|3;GX9yqu(mK#co2F2v2Z<9A}r2y z9&%Q+3#Z`glcQki6TmDuXi?D)JtV0dsF!C%I9k(&HEiyiyp%j7B>5%Z(+y-F1J_&Q zsca?>3+|-wJ|`vTb-6-scowx8^}-gs&ZK&5=>mAZg0w2SlCWxOThe5{uha9S20OL1 z9n49}AyQdPh(Sv2?qAoV-SCR)USckFHe*9EouOxAq+Ph$AK=a(1GiQ3#>k4qR%m$>QAn=M@4rvBOZ z$dJ$8oJ^+|3z=jwJDwMcITz>!%%Bi66+dh?*yzUj+`@JsPgno_+ifYwpC5&?@lN$Q zTp8u_humgi^efg?0!jO~ zM2S*bHl;*D>*;jOTiHT~6H*Lr)l77;)V0p(ZQt=jzijJ_iTv^$V~li6;;lZB7CtPr zrO~#7+heha+fY8f#W3H$Y|oHnGq)$OEL_=chgw{4-ZJ)I?5?)UX$sYHewv?o#uRLJ6M~#k-iX}smtgFC+pFThM zU`=jxBK2j3q405W0?{rf6zNpx z?~uoJFYrd$ZGz8Q*|;im>Uh5`<=h`?LNAOWFPSnkze=FPBLvIE3J7hzeJ^50w_}6^ z%#7PE$kFic=>oye`;h!A#$_V z{ddjW15GBuuzyWeZ1tS&V?zioIRPANqO^4OK5KBs_sImO^`g-q-v*a^a&_nl%_tUJ z7&ex&T1ENxOCo5;y7lquSG^~Mr43G2AIh7t-{!{pNr7WPR?Y1o=|2c_<;26MdxjVr2#8z(BnP?u^95%*PN|uHA__0DCtZ&ak+rf zUX8xTYr(g!W|cXE)Nv{8kOtWw+~oK8R*805fc8j1?g5Vk)Yt9L=h||BxTq9w>crvZ zgmI0ESzu~{AJ8Utt+hKQ$pmlT)SdQJZ~|{RY0>O~X&XHU4zmaEbrk01&8vy-kB*OT zx_<3i>`*lVtcUz=UKPk9aa$ODXj|uiSl>TTiasaQwlJk=+*L7T{$m7?lJz4@EOZip!3G7Fjx=4X)bk*2(t{&}gdM-60 zYf&U&76OGgHb=@|zu`)7kEo1;Gxpg{0&YO?=dLgwf(TIu2I)58=pS6XD)`sCEI4)t zm-*fV;+ol>Uu6^A(}lq*9xJ!p#pq8}s-%4w3 z#i;*p5)-3mc2RE8K0emtN-e@ zt(de)^NWkSJmiO8=W_yk7u^roQ3hHF&Y1WPNEJ;_ME)v(n_2K`FL6GIkxZLFqe4Su zs?M$8jq3I~rYEvWQ+_dOo0U6)olqLgyUOz^`krZ9&R)aqX?m;2O$F5YGbRhR-+@|V zfveqEDey8;nNdDXhA|+`=&9O{Tx~Oy)+Nl;!mT_{ILCQP#(enh?yjz> zp0Ae-m*FZftHZ%8HQAwDcsTPLtBSC{?XO{}!h1<#Z1(ZntVCz{kLao)YI$T8O=dMd zw?BU}tQ`bPxa_p*klW5bt4R`;He+FoNX^fEPHC>~lIDk2pX;2W@`f`y7|~38d}25G zf(LUsSMguLl?8bnI>V7K&BrNZn!jne5BqBXK*2&u@nSYB0+Hopuz9BGFs66NMUn+e zOR`FHxYnRGjAZ}$YwAEt#8GX9GPIK-%zem@H>fU3BVTcUWPmyXhaqOFOE@04IbkM^bTC;SCXi( zF)~SqAaPP3H9SXh{E#sYx}GiPbdRFVR?K92o7TRkdHqMs+_Pb3&0Y(HOkM4xLJ?Fi z13AlP12sWc-XrPI#b>BCln<9yg@HbIUC0>LbeakUtsS&ZI`9eY9#( ze{)OcmWRY-?s362F1oa0!iY`Ba1$7pWYdmgD&JwY#GHaN4dJ@gnpg#XDrO-YpMo3o z;p#szpJ*VIGX=ADzt!{XIBRN1Sn^iP+oVBuR6(?@d0sg%i$gEvzr8?U?4lapI5&cg z2s!5QA$BYHVP~#!OsZrx^p{ODx-vchdgUOrJ5gisF=`FHQRn(t-c zvz^XfMB?|o$l;-eCNcNHzeRz; zs5C-8$f?a%`Pp~hVJ=HuH5yEFYCe2s~qdFV54yRht1_|b(Y$z&^P+sIvKa$Pr&1_`7=I_&n^Pv}D>Wlz zP#V2+_tGuV7bRn_Q7)eKowbJLQ&-Z|(}K2#j=@x^d4G1QL>*qa&hG|DNMmj5?>8c4 zgY~b-W`d0(%l4wAX;Hf_pw*YEM7+i*!wn}V?WA(ei>P3~KVBJKZtB(|*N*A14Rv>w z>Kx)$;I;ADmw~I8M2wLB(?Yg%UaRPLvg6_rO~)gRQZd%TMZ&Q^-sk0U9WQfOb zXZ5n;+~0%2q<7VXP!;y{zhCbYq+doOR1j-C_!~t?qj5>H-E5n`vGs5W{*rjmyCvJ` zkeV=2iH$mioVPPJ@@KsFuqs)`oIfP5+`BEvE&{vp13ZMWr%%dxr?;a$ZEmbHe~@UK z-#!o3wrFef!;j9J>4p33HoHwr52xYniL1+eb*y&%G?v=LMF@^$zA5$vRVTv+}j<`s7St@Vi;|$ z?vB^Gx|Z=BbjOC?6?{h?r(jyy$E|QK>_V(*XP}OVdi+A%`b3T3Vo(a#SDK2S)g%&p z5+7wd0fu`lS~@x2La6OWDD-h;^x-JvW3Q{8r{fi?un2<;0l2WUaDN>hWvuz8bG~&z zsZTAwK1L$s{ADo9nHu7AWM+vc578V{!LesVlyhTh|Z!%WPKa93Ho(K8?4zXXk&4mK6& z2Jyx>ZpdO+z*w5d6*P@LI_cg%n5EjJX3`cW5E0m(67^2lk;GfdCZlsWB{WC$f9kPP zrJHEVO4z-LW2lAWue6ogykiW3}o%h~!`PnM_v_=tomBZ=X4E)*#&N6T5G#%FBDD+PPgmtdIXatlEe4>EW;x8*S3K9$}lWj%j$b zWjx{FfaHL~bX!WBvzo?I%@z?86XV_B96Mh869?byZPVf2zKFK?y*RVQDcpOzX>rs= zb`|R@{BYQ~4g>bvdnw74h26&1HwaGFzqI2JIr{Gd$13U0!ysy-IHrW&DG` z<2Ge{hy8n2Km|notu~$PRAxDQ4AUY&V$U+a7BJWlVcyRZaJFC_IeXpudhbYQ^LM;< z)k+e)q;@U{Q_zm~QFK0OpEpavfrv*qZW=ema zn=Ut0YJ?n_&E(TF*4Iah!?G6U=W7s5rP$8jF5rdxuQnj=ZPS!%5P_vEb32J_z)0MB zg;5m~(Us3DBcxaQX|O4s#-a*k!nrlarySml(pSbdbj*Ek=zrQs>z%Rc3Ac?`Q*$G^ zu*mJ^JEg;%!l<6iZGOm98q%P81`q#GJsP|7dV)Y75O^V`@}NX$Km%e5&L1AvAo#!QP<4Hc+kZl3=>AQ zzn9>f6TFOh7%3M|nD!)#vZOpV;UC0DQ+sS#7!R#XBtz zj|0mG^Pmu_S2ILf5f)8_86aQ9$==kt2tBV0ue+5yZ|^`J=TZXVfQ1R?VngWD(Nl;Q zN-#QoL&LsmkY6+pJUY``L{|jh;x{AyXK6o&rhDrw-e@Rp`N#kZ`!@&%^biu2Cgfj! zLKOIfuVXTv71MNLPNYX&WJ`ZsO_>;YW@+5G%`aRZCh zP!eU*N+;?(lcbCso+%QK-r6tio$dVYf6u< zj%4NMrJ9_heS2NL?{uLX=3_uEW-o1;T>bn`uYGX7e(^qL&1!K`H**!t6v<%IG?_G@ zdbkVeIFSK3z!}tPt3T)^U537gdaLm;B30vgnSCL<;6Tmm^l$qc4$mC99V4p`R9|OY z7$T*^A3V(QY{2fy1%G^e7A(kI6dlBcQUvy%GAj=c*<-{Mj_l-?qS;W)7mReSlOyZb zqSRFtkG(srCvbyI?Sp+0v-QZe%BRzlEf?vO-@k>~quvO?TuVqz3&FSh74gidh9-tR zMcqxgQZ%`10=^?YTgdd;fJKgVbI;A}}1F2b=Y$5}hatv!>Nt?Yv*>^Ef zeRYL`f>oTWud?ctc6SB^)9J?k`*ulg)NO>{cJ2@Hi`BDy0I)@5X_DY;3+0#AUgnu& zpEv4QRfeAQ{yxX7btUz&?Q!&jP4v~{b*tDAN@99?dKWbS{zZX5b^1le+mX2%Uq^gH z4E}_OB(%z2d~+J{NiPXvl*!|O#U~L~2miY$Zm|NQ@#lN()Z(24BIs^vaZf@0tXR=L zz-8K>{oO4Vp4ypfHx9fy4u&ZkbCS7Kn{u#*YkD*0b&RWv(YmxpQL(~+*Fxs%`;5yd zrQ#aWK2pQx+IN(FN5EsT2x9K!|L_Vc>N_*Q;ZNw8TngVvd;^1q`1t!3ig?LRm_0{n=k6QmRMi!=1%88cUD60oL z*Cn^KMqn;sv*P7AC|W7};2A=YPV%%&7EEbk^jKu=`pw;WR_dv-X1Vs_mQPCLSy>MI zzk|W$^1uH8%lEG}UL`MyFGBB)Liq3Su$aQmVp0f;jGB$oZIvqB!;l6JMr*7OcwbE% zhO(W_M5}~wa)WscH%EF#e+g((e5e&`I>jQf1H7dLb)f;T`JnvvYDgTlwO91UGY zv^E)+eUK}77q@BCufF$j>#dn{%4#^iHP(t>2fq=qPtCd`BG2B;X>sqc$UaU&6#SUY zOAQn^j^p}_ufqC`edeqj8nE1BajGQ{djdjoa`Hr79i7h3uC5D9l7Vw&uxZ#9{r8#< z@PP8Ov*DhbWg@-yU8l*iTNlC!(VEe)khZwC2zTPpyl9?2iB1Aj`8R6`w(ZVpKR><^ zA5;Y17Rf$FwSs1%SUHlTI@aRh6W}WOonj;|Wyq~frt^KQbS=RwVZQy9u#a%nqrNnQ zRQxT;l(4uY`e<4(v%v*o8g|1}jBEV{Se(>zVcK~Q^A7UT#)B9MwY_ZCB>;w6*#lg6 zQn6ewW-5FnxniAxIw2lLHqGc%c!g(#v#W$n#i>M+f00~sA8@qn^I?^VaW6l3-ipHx znNpea#Uh3@PyPk~TYy7TPiv4VHsyn5_0vZbn#JC#*NP@|t(ibYG}oo-_9=lrZa&Uz zp#I@GRC18oKCa1oVN7EgKR8IRS&aibu2EpYFW7CsxIE!JEk7+FX)k|8zOqyLFZ3Nt}y`Y?X;P>))nUrJQk9;{2^RdZzR6 zG6)tz$d$Nk7^~6M)#ddiSO4;)D*2zyxf{xqCIP2;t>7w8LArYd$;bnrd{*$IfH6=1 zc3vjCeHt5tJXWHQt&iPBNcfsW(?N=9iZ7SWZ(xs6K#on^XB6!E-Nm_16MKC~x~3|x zP~$Q1&zTi$@RAuKhKe7d3_y{-XWDuW^1GSfgisoYF3{mT0y~3l{cyyNa*>Cd`5LH8BGm9D8jk3(RdZzKgCW?nlQneSQN$Wu{kGW%C~p2`u}wz5Y1j4$_F&rr^1TWWaHuo$+OCZHl!P{F-pD za3Fvvq$uLzm+=do-QDb8C}S1lEv?F~Ph-@Pw;J5?D&i+B6tE=B@-BfD9N+5Xy2HXN zm#9L#8rr_n3b40nN`BsqqTg~ozt>x}XRebXS8!!0Q|^m!Ro$=I2OZasC*>!f-eSp; zMp#edCI4EG#a0TyJCHuXO;3MbD`2!NN;w|2(dV`&Z3~-^w_S5kMZ3ud*M+{2DTcI# zg{@DG>M@#6+nyrqT{4^O{IY~G(a2cW2Jkr}qaL;&9lzN?|uBcW7WguZYZbJv*Ap~+A zkxTk`1+XNm1T6Q+a@X3z&pobjWdF{Q44lT*VHTHWNbBF9C z5jlBf4^`%hIggmqj3yiFM7n=*4TtZw8NX9NwTe9f2DL8tuu2uzX=Tip_`6*WHI=bE zF4sG<9}@6-MZRJJ&p{`x!YAP`5hI(`2jJ#@$OvN;ur&haZ~HU>mv+<43Rwg>mfxM-Q<~_08bF96S<*uI@v^BkzQVBY?MEf z{fI+L*d)x=4-(f&^im*r-}1iJrLji}QOklyA&H}h#y;A? zH7F)r-MqSWfp|wNWZ0ct3!!P=rN$kR%tAh|Sa)8n&RP+SP;Qv5F*3*YzNmKsPGKLlT6~0jqXNMzKv$>SG7OC0MwEvXgyE+p zAH1`Xf}nIb{gAlL_5Vu;dICVME6K~(I15I(slEqi$1AWOks4aJxr?JfXF3;)t&F%! zDBT+0I0%!RIhh#kU5^+UO&O78qOx!@<+ypH03v&GX?3q_j52JoOjyV|856;Xo?4f> z+hKLkc5SBvg`GHF^JeX3xpWvJ+?Fezku@5rj~) z_*z;ZqamZoyggdM&RF&}EA`&IF>*MQ_Uswo^p#pMo4UD%PG9sES%vUH2`W!ZK04LA zy)9~;lRrw4*^0(AzZKfaMYz(z03+o^&EV?nR;zr_q!qKrnKQ@Al|G5CzZc+RyF53A z|904o24Wct7M0lV5%~}D$V`j-FuC@Gvjez=vf~w&TE4utb7G)=Sy}0J$bxR<&(y%Y zU6)GL_3JBv4-nlrIdRSn|HKHAlr8J1&gT7qEr+as2u5+WTmRAJ#Skn3AvnNYQvMIL zQnW-4e~JL~6nZwqH073`bNhhfOmpB8#>(JUalNyN=qc?`?peMvq8roK886YNDlQ=F z@_wozo`+f7P}Zsz_r^Da+5AaQXf??@3MYQc7caWUhGtHh+&okl&SlcHc0w6>6JP%+ ztf5)v%H^MsLo5qC3AuZHYNP)3@o?LKKNnnLwp+E>Q+%>#UVt2hg zH*eaTa-r&~St~7v-od|Gm$*VVg+VJ-h9cxF^OFp!X z?;P}+1RZR)R=#S&B&Ft1{Y2%q=*WPpUcd`1DC^dm3_$H3nHN5(B6#-WH(^240Kj)8 zu$}n!E1QZ<0c;hy$p9z0vu9l_mp$KDXcPcf<@Vsq?0A25JXLAxczoEtK33lD9AP)Q z3qm*V3p_thjeVS-wx(uXZoF2CD$#J;rV%;6QckeKYfkp&CFmi7hr+v&lJEh+!NF6< zn`29rKmyqEGj(+vv#~=&B@V%ocuYE%VyLi?v`XeJ|B!22i-)=Rl*)LsREwgslL0?H zB(L!+9xT5Mo>wcAI6f}L$cDx7wO1D(ONS~b44R24*q@9p!_KdO7(&|MiKaMXMyhQb zlZJd^S=ye>V$YS0m~L^XjY+{9hSzvHUy(zE z#i(?}STasZbS9aP47S{}$H!DwS6BA|K#C<~8Yp-L0!xE?#MCx5n+!gZi)GJK`?YyH zx~~zk$B(2hfMM8ZyQYOei6}f^*ol%rL#aojOi%E2cfv%&yjr4xV5?3E#F!ePY7X5Z z*P^&Xicc=pdXqkcyVin=pba@Sv0~cu1=IK=SzP`^u~Mm*HinCMOfFB+Q>Pz$DUl?t zD;m!~ICo|<69GZW=}pgsRNi?Qo6L@)N|JfAucgCabQubq4xp#Lwhy`H8I^f&gPi2{ zRNc>sD+SjcHRc>t_Y0gx<%S|pqRAE=zr3j%7R_0_0#lTbYrh=1Kv|o82rvZ#wzjrL zBoGzB{OJJm2WimCTzz+tIFlx%;zPBFX)ij6S7TO#m>ec#^A?dqD2rMpvE^AT^Rb+w zVvF%>RY2$;ogj~amSmHiH;RZrdULvM`aV-laSd2d^F&fxg&6vrX}v~|Hwl=qqsHL0 z(oTPdhSIb9?MiapYZfr|E$o^rIjKlp_*(FN6%lPpF}-Gs3_ET4Yo+7TKVeVsRhiBfjs{FGXT7*?B!(ZuR?%Jjf&u`*IQoIUNK;b{sfJ^p5S3szyy?Epd_5T(EsTZ;RPW&n`7oU%3W$~> z_@NbHSnoLdc4W!%%>KIBWnMN3j$zU1x+hzD_)Q}rbG!Ic>17sOoor@Yb&gEVRMvXA zGk!agihs=s)BDh-!!uo}T0pt!_Jl4HE+bRwMwr{o9N?&uw|1tnL&Qx?O#T2^8^%n- zJCG>s1n8WXYLkPXCzE*uq*0A$YOPb%zo~nxJFATsUB;NSfMR{V(lM{r99x`>ci9=cuQ;6{lnqd zw9%^(#|T&AR+56NUU(fqhvL)S5d(xto#|3IN@J^7ot%QE_W?@&w%*P*^3|vwB z>h6Z{iEkhw5Sr-iE4s50*7dXm(3MR} zqVOEnTmJgaIrW_A?Aw7fdSPJx0$#wxW4bv%F(IKXIx0%&wThtEC$OE{TV86e3crPh$eK$YnWWytnA5X|o$Pwl;6l7+rjBWi4AQ~w-HOeu}GP7?L3zMHAw z#r0nvdjQZ81qRMiRhf|mClmSew3vUUiwH0SB>9qb+XYt0 zy`>`X@F8R^#H7}61O&(>3moT|Avr$Ahtt-`garvAYgZv?gd|--jtYi;H}KmPyPKKR z7eH_%W{vp6ak6`OF%pdhMLNEd@^^)ZD8C*lCnob3(oM7n7QDOkv+);BkyLt1QcNEMXuO#svJkId{9?4vIQCJh564>3uIJMKOvO-0P7I zC7o;l8dqt)SUQUs=Mk+|Q)O9KWF|l8LoQzG-(QV<0NXKfs0yVf{3sQOabz^)1VPEm zhR+lv(bo|Hq>h~F9?NBmU+oJfDb3aKx=Y0S(R~6y79;NtiMo?LlF54uyw4kbWOO=c zx@?QJa!XCZ%!B6~=1MYfBk2ay>7P$lb=YzQBUuNMKU+`JeTQdvNNUGQI7s-agXIhh z!Op7{1#OTgGMC39n2SnmURz2o4gn{S`yDB}1XCdv3!Ww8OeGft8mtz1wYci95mVdI z><|?*glQ^aLj{V5_r?-|WRj?$wy3v2B?@Y=x|v$z)THOu^V8Ej83-5&AtoPr1MY$* zX4>K;56>!PqcKucgtHE8Mr%Eql`Ai>MC|5lr6M-GHaA@#9E9j*{1bBplO20aV=Jjv zzHC_MfU~nTy~k6p4Pip2xlC5eHE)ys&OZa9Yr+{tprCmofD+{vh&UNkg-M+&K~zFN zwAAP@7&qxrM@On*jEgA1wY*>+YpWEOwG=_U8R0645uX9B%hLJw}*6)N%D8V*JGoOz?`^;jGnBkD~4k&SMDu6rFmup zmY##n20h+nclRsY*H7~NZK$4&IjoIgaE*x*Y)J*7e<0mchEicMEk~~mUv^(WaiO%q zp|!a`O;9=jKyFM~V3N$5t&_zcA;4uBCv^SE`h+~RBF#uz+&BE$5%2tb5N(d}ey2#Z zASRgrl~Io;H3{Dk@vHE&=~{`c@XaG>XbT$zn$>_&&pj6ulYrW3ivD3k@R~EM)@FLn z!z5&D4KyErV5%uI;9wXdWim404Bm0Tld8>C8OjwN8_-ep)eafW`fsgj9QD_b9?E#} zfpuY=)J}m+)lnn|4k!i0q6lFDMEcv*kmZ<=9??T(A_4pR(HPvNno%AHNofBxlHUBg zN4qS+-Mwc7^omcif(LL2VBLc~9`pubXwOD_fZ_NEF&#npNu+dWsLOZ2ix~*+Df@lK zF@f%i&IIIQ1RQ@GSYY}2K!&lmINcfA^3x41CN6kAL`7L|^!tJ&LO|G;Hg*N5 z_aUMJJ%1?^tieqJQEdV+32pQgG9zEscQAdujlIF0Oa*dTq=C-_E4V<;WA(aw6Mo!D zD#|g6yN6BG>GP8n*HE}I_l7Uaz*KU6?=y7uJlG^O0~;POUF~}-sG@%lrind6q9;c9 zh}YgAkNskpjpyl3f50A-HIsM4d+gl~C%$E(Mh7pc=Z3)u=9q4eu01FrA8R=oxez8r zFjDDP8NzW*M3_ELx}Xdpr9dWSN}dn05j=ra!eeuXWG)X7X&W;V1RTcawF-<3?~HXpwJKrJ~FOocP842e&y5O2CIjUx4!tI)tA4A=vTelKo%U(P7%gzehd}qryssw}SEXlR;NE`USgCS6R12 zTR~kQRVONpqpM5sDJ}ow!DdgSQdl6h8N2JgxNIt$W7R!Sc*1sQXAb;P>eY z0oiA>-HI3Xi}Pl!lH0O*HSmKB*dGoc0Vhl=-3&9Eaw$*JYi9bl>`@An`+5)m^7!pK zj{a!#C!eW!mx+svJ<~yzy=+(6Z4%~aqrX_7}F*~&e8;`U~&TIHruTT`-DV{x!i+w=CTNK6IxLdbOpPTb^@ekbED~BHw zqT!Gw#C2qgUfntukp7DWz}`Gh?cHbZMjm<++2UsI+UqZn%QR!TXEVHB=O_|Mw#F0c zR_K)^F2t{mV%KXMgYO$!6^+w7HvhsdCqBbtTz50%h?;HQrg~!{Tek8Q_J!Rr#wgQ1 z)AvQ6%&|(*4HMPr>WNQtE&;r-9#YHsiVk9vEdoM&oxAQ zjo{xdoa~O)8z)A2#OhH9J7#T9QWCiYgcfhM?1k%hompeseL97XYfGjP1Ya z!pXiNU@A(kfJYse=<6H_*VQBCSlNr=4R9{ED-J`FHOZ33R)d$s2QxOWiHGG4lnUVB zA$8kgk}Ti@e9)36Kz%;MY-jC5^+zx4^oo{Jyau0mlGFx5+em+qY$yl;sfHS?@f=pT zqQ_hRtZ@k>hA~!;-DDY{C^EP)3{!$eY><9iWrcg(b-*R7b$Wzkav+yb5NUxUQBG|2 z0B_agL^jp|4;ugE?Q>5sRL^IX^cB>wsZ>Hu0$&`u$K|5pbR}ZnydsO|;dMZcBIWzc zY>bjosv#kT4O(7=O902oGk)(tsSeP%e^1k2fEs=R!z=8$01`GJCO38*E!*~l0fDPW zur*5C({ci}cOz~a)lGE#j|N>_o%6OvqQwl~2O3;05NvTnG%Sw3RM7Eie&DF#4QL6; z<3rgll%I&xu4ay?x1BrBDXXJ;|9+-|N%WBefm@;S)>=1+q15AS(~1^6o^3S9!YmVl zW+^~xo-1D71p-`xuNMI%qG(Uq(?A!-0X^Zy3=TQ%;1em&%5ZKsQ_BBoQ9(lIuVmVO ze_cHAR;I~NgYNZI@Qb0_%%qlyg}gR&1QDKb?x+i3^k@dOQNPGwS)~_IsScW&F}^0p z=#qZ>zCK1W7udU@tK){A_VJk#)aq7bU%of%$^VG4oiq@t4Sf7yp9JkTCw=d+!v(sI zZzylpYt0V_7k!YFu3L9mk`kMD<{^MkJaF!GyuVTExOa)tct3mm5O3aBCQ@ZS=h_Hc zMO)utReado%<(xZCA&ZQrZaZ6nU%Qnwn0$mVdeogdu;yj`(n$m5B8g*J${!(j~*D$ zGW=Ot5sU5DEfz~s7Q3ZGINnUOE@x-0pDJO$I?ifziGY0xmPUyJ80!Z_0f*bPSJLYV zEmy~d4=YcE^MdK0P=)@&n%EIfFZ@e)rdVNwb*hTszB8;QjKeKHLa^iaA@O5EB#jb@ zj&5}@38A-Yp2WO%Yl;6mK(LhYJ@7BY9sk!*tioH%4*=9@^M2Ifr1sy|LF zw@TA8*sjw9vo)J#eIwxmk?2A`vBbgo$`~tt|2h}SF7Z?r)`=sv>m=(mx+y z1V6oPeQo@^FUPxW6saKCC;uG{eD|b|gxx6mZZ2kRL8-_Ld^7;vap1wadFOpUlXbvdy#J)q6^%v%Ccu=3I z^GWq?wury2b8B}dePIxKaX@FTn3{x8-p-8aOiZ<2)}Ys>)5Lf{vM63OsDnDktO-+QOig?#A>jJFwD+~ z5u%Dkz8K^SdHBYq-t20dANTstJd9CqP7{pMg+QR$Xn9wVD$_^_lx-a{ zBt`L@kqv+la!gOy&Y7k}{mJF5dXksk4=Nu#V=@r?#|QZhk7Z)9vNY#U=TE#Qn~31| zBlO-!JM*N{1!4&aAUTre62yE1#{dl=B85Z9GtL4y(xO3TD zQ}2%Ck!+T|7vk2CcQR+X*?V)<;6NGeOs_x$?`K<@ka z`q-_|G)KMaEWc0zT6G4G@|0GG;37VtkY3Ofiu{VMmD%sbCGAKI5x?#wCm|#)VJj5X zm|5ctQP6j_0DWs*K6~ruy%<(7tFfT#Y51w#TSMR3(^~Yb9IE8^6WrFO?Y$zCGK+@i zq0SUX(G%A9Mu>F_542vcw=}AC@2FnC@nL9m+KjiWtXEjFIw^GDu6mlqSlS8py%4q0 zYr#lBKu0}fI@Y}IjSMso0hY>dUl&rWlW+%`1h1k=biOw(uADopd?F5IP|19EU$1pY z&B4^%peO;Mf@f+~!3l7T(ZwbR1JGI0D%0Xp9?^C}=9+CfNOy%d5G4HaUN~kcJuU~x z(vyA;)+LA(HIy=*)(uhTeCS2+o9jVwFR*V|`3ZzQ`IU#62ljjux zL6CgzZ_`QTJp6sL=ygck^80ae-L!y{^;n4)nV}SWXXY8GYmQ`6TgO!9R34O+!R1sh zLYImoh`PAlZy5V9a+rOy_X+ zen9_1jOF3RH7ed^#F__|aagag$tVk2gn-ewL*eIF6?pX1G{|gmb$#PTb;i+O8-A$J?ej zXIjn(b#AVQ@jOnEVls@|+SevYVUxZ4!zaJo=4r~6NaI;TPcvQuA^X3#PU|<6ekt~R z_Q|PVpQnnQQzqr%W+z&1LS7V9S!ZmFFQ4<&ljY4%bS3N@6aeGjyp@fZ3;|@+GGuth z)r;M`Az@AAp%(rWxv8(AgFs+r#N%+O(G+zxfjrp!uv}<;1fjZ6^9q&QT8`3VCxqYZ zjFe;OhfgR8J(5PnUJvoc&4W*aitqis?$u4VgNMW3YmI7S)9n}D39z9YLkfGxFlxvz z%wENtfc%l`=leHOP4g~^WVdSo$D3B#vETCQyI`$M6lS$j$tG>hv4a zIPVDqDp&i^<>GzjlD!I?@n-j1|3FcIt$?``+Y8zn!a82Y2oaAI$%z4Xf!;2E);aT3 z{S+n9y=uO2GJ4YDx+_v)m+$fTI7omH0%fC8cU2ztIT_)jm&pLWN_FLP=OLC}$;IT0CK($4?xyf3CbyEr9h5wn}4^xVMDE?QW0k67y6r`|ld#}QlF^2OQ6^ZcLh8YvX?I8hl3VidtD)BtFJ{0WNH;0mG{3`kd<)6Vh}No4f{%8 zyV|lTlT5}}6)KQ8n$NlE)(y1odyy(p*_Gh7+!{l-Ke4X=x;Mq(GFIWVo~o+Uw7<-~ z^?-4t3*Vx6JS1|AWMZWg#Ozug1X~{cR)A_C2p||&ZgZj-be9I|j-lW(5M4a8ck=j# zMWF4rtz6%~cy}`*d9pc_s-)Lc?*WYzd+_+F-{pFDn(thqt2NsCm&U`a-@UPB0-rn2 z63OGGaVZMk!qJ)q@y$EZlRH^^#=$gpO!Z7_Rzmct>-Tz zd@ixmMJrOh>sM%r+s$e-g&pRxG6S3plJmnb6>}`k%r6xqG|p#Pj-k%V!~!>3%my0@ zL7U}bw#oOH-GeZEO2tk|OOuVjUtP%+r~9A}fsD0+2ca=KqQ#1E7(ceSJj0~_C0ddS zo@0_Wp0f!@2^@yRN??zLXV+)AbCB7B|6uAumHl)Gt<3Otly(s=mB~c5V*F=+7cY<{ z&mkcAO4dMf1R3O-#4KTJkX`u#%fdh_kJ#FJhwJp?`rTy0k3&PflnRJZ>2g<48WA$` z(r-#Mv~3Udb800%(IAKL^^U^l$3Rr}Fl|YUfHfS4ix~q(kDO!#`xg2JJN(9FVV#HVH;!&|eHdI+>;>~| z%CN?xXXwnvx9>6DrdJw#;vN=`9r}Zm<4bQpOu@Q(D@|xcHIvvU- zAO`x!%(?UH{EVbN^;#x>lpWL1Am1oK7u-zR{lTW=VhAA$yoK{-m|37@mbyUZl3zm? zEr%)zb7G2*k?)dsg?B`WL6w@P@+Y=f-WDASzYPx$k8vieOL3vbwsZ1h%?z(XhdK7+ zKi9R6>XoY+wJJUl<@)l7V?GNFG32ukVYfcV1hL z!`?e6#4ju>lUk};Zm&NVrkfU2~i7>B^Rr;U%GcRL9J<&eS&~XV^nRA-SGU1iYOB;NtV)Q!fZwI zYMp@sAxGTH?i7WL(GG5%tQbvVs^Hwk+IXdv)-Gtt2`XR{C&FwWA0Vi9PEF7qVMKp~ z?~JJ<{`{OmGGsoEe783Q?yyE!;Fp9Bqw$kUZY(mhKFNS&lzI-m5hw==3YBUDFEtVu z@g%qDLT&|1C50SCrD%7kk@+&QUVdDq_ti1OIl>T}DNgYk5bwdUI0CNcbxS_fy`g87 z&yh)vai+Smxx}n*0ZsR|sceN{Lshio)#!kJ9NBA^QmM;WZErzt5G~y5I zG|wfatLYF;P@Z->hU}RS-tLYc-s8!-j)6+B6pP>JQE&+1^(aBs`siDJu(jS_#NzQ& zm~E~;u$&#FZZe`Lyyd^MZu>#=B;MU)kh78c+IX8{i97vLoaoE2KHVYYlSL8&o-dv& zqw$sFx}rv7S2`7BRT`YxXB!fJWsbR#3W%mxU^%VPJx{6dZZm1C*}5!n=-K(bZfq*} zUE_$w%Ei7$&p?Dh3M9WV$Ad{ToeXXw#r1qIt(v`$d-#t}hY`L|mRXIVd(E5a|Im-& z-5kwg)k05yh8{Qb*3X@Qzw*~z6AAjjD?Z~%#opDfG%ItFq0uRUZe&GQ$rbAZJOYBl z=U9aI0>@!-89bE1^i=H`-Y6;AUGXYtiU2Y)28A{`CmodPDn>NUm>O^Y-YYXJ4hO)+ z_gvpkfEYMakwe4Gk&k!BOhJscgL*5%QGKel8 zD7PAkkQZ=y8C5HwTI$|@a^@UAj6 zvrN0(Q+r^7&_J01qB6w_B!nhWdua^1i%NuYRDo_fVhK@qQ*@^Ao5f5q`Lb`nrlD>h zes|HVjdiWkX@JZ%1mfxgbdNvf#n>2^7lkV(!3!NRle;$DrvNi1d3y}xK2CjPb5 zU|c8-^;At~BqU(7C?RWzysL9+K6Ur}qO`lT(A_`Ldf_YBU|+5WJ=K`G8{*Tcbq}z) zzQt{9m-Pdu3)$mL6||v{RK53bJ12w?rgobdIv&I`?lN=UgUH0bjEUs!LmRoe3UMe! zRGV~fTOG?5LCVsqz4Ki$-BG;uxY^m}(<|L=PYp_PSzzK*2S}N%HlG%TqYK9(E1&;t zVXezw)-C2BOa}$27Yg5bPP9Fb*7zvup%B`|HKQ}CHM|E6YhWG13qxL?u?ms#U`Xb4 zplc)Pyu!k_L`SQd-m~v;47>7Fpd0OVdT(9GnX(BP z(x&m|o|E6dwrg!}Md9pQ`0n{5OzCz|YQ#i|Fv)3^>%&DAyKyHSMEj_(3(k1vxO2Da zupT5yO%{o$->Rj{CbS9nNg^7HX! z+jP(EnEGh6jKm5mQvRO}`By)F_U;JClhS?c@J&F2b_H6KKfP-B8&c&JheL1?j3BlG z?5bwx6IR}L#GvT>V0zihrpJVnLZfA$WZD-y-bq&hS_pv&wx&+9M+SFO0E~_H;Ehf+njY36Kra^9dofF=V^z7E(g>< zvjv|##q+WI+gRJjHqb=l!GW=h6ZwMOXyS9{Y*%SJJ*VK4$T(==NPlP{f{8*&;z%?B z4qRv@7O;^K@Y$QLYytt0+`4YDd<%1=oYBR8y(Zy&=F4+(^D2jx@gB?hb6lZ#&I_wV zTkG>7#loq$h-39ty&~v+#up@emlhcL0VpZ zNy+*fDaYGt)lrU2To3)s0ZQp&Yy(mM)@BK`m2e3Xx!vX)V7W@!-O(TI>)h6t)ha7W zydR!5o)A3D>{KOI47*=AF+(qHoQjTb`|qoq&xr{`SZa3^vRkgujXi)US(W|RfuDZY zq8^KNDtiJ2u7&)e*RK4O`WVTZlGsH9hSxW4JV*4K2GDN!&D2uo)``}yg-VnYuNQsS zLtrrsPk=CVoJb1AEIvLf>1S@!v((-y?p!U}nKtvpE1h_g9`n;;d(tkcLD*bI%?p$# z?+pEJ+ra&b4D@XrjVJKs?)D8hDPfep4dR`F2oGfZc6tYDcUj*Y5ip-Z+PgR77z9fp znhjAB8Wq0Fy|1Dp>pE!t5s(P$sz+ZA-R6r%f!y`aYRj?Tez!-mo#9lF4g?7aLB?mv zwoFG694egK;Z~Y1v3}kSEmf!cFwue?+r@9$&~e;{js<2DsDWO~F#KS?GkER18)c1^ z8}bwoBK&eAh$)96eC`M0Un_CGr1O6wylO{9kLPf^AA84;Pc+llUltOwc0YP&{v-0r z@ve3~akmZ{g-%y;O#VRN<5gpeR?VOYtq8=rRJ9qI#pLg|y>RBN)yLWRm|DfZl(jc5 zJsv;}GB4O;nFFPEq*h^JqQBIsRLxk5y=4`zcBdV#B06qbJZ??;PmG>8R5}QITd*0q z-iBrL4c5f_NY0X@>i~kqbyPoC>)L;Et*qTIm#1le!%C^~9kBqZ1;*bwNSJcjEgpp( zIz`RN1+@%@Vq)G#?U};9N~k$*ZLlFj@wBLpTT;7r#p8`JdlTsFqK105ZvC$Y*A*El zbp?`1d~5n1{rzoajY;+f;Xr9_m1%cNTwTM7#K2_?H1cAU7yrq}LD9l|Df9x0IR<+_4r z|XlUT^#nM*| z;T!{WhcThsO?4hVr(h|71@!G&wJ-!?5faQd*I3m!eseAwd7c`#mXv<-_LzzwB|%f}|- zx0^o#W;9dj0uHNT*s@T^)6t#PKtNR{poefczcgiwsd4=q+j`vNb=W^zDkisWUB*k? z-J*ZvZ5-%g0n%Y~egW0dH`55xL5JMfqrlifHkxRqNV7;oDeEP5a*y!1!BhQmPzW{S zg2RK}0Z);X^X=b#6Lg>w+2gc>E&AzGnT ztc~z2BlHsNn_M9B`yB9Q9CH$YynF)AeX9V0&g&nU?wtj8&*^SEdgw=R}$WCy*DDxF`IuSs@7e0WEK?~S>&CLMILobyX2K`6q`ztIs z_-Wvpc%TMUQQpUr3!N((D!M5`pGP8F;T^G3u8YLsq#(c4YML;6#IkQ1gVO9j1#%}6 z_^YrqUSO{uc|Nn5z=?Puq1Oo@gfnfpD^cRE{NGFuU6M zYa8dm^7krOV=#$U1t80>H}g^8$uxMS)2rjc2^*pWTga9RGT*M zE0z6)=6YxCk)kygIMAqN%m6fwmcL(t9gYk>yWVA(WC*Gcumt@Q0*W5@CLnvsxbQh; zl4He9nyz+7lkpX7{qpiMEUBU)MDJ!D@1O2h0otI!n>$)Nr!-g}gXvqXC+`1w+~AjR zfHpnfZbJzGiq=0KY5qsUSOj=t0Jv6x-9MZztxXT{oS{DX}V7{$^v?wS0Z1l{Nk-BtSEk?COj zhaP`J`ic$W+0lgou3o7#4M+rX1IrcB!SR6J)y2L`@+eU-f&D=ds-YhSh#gB7$z!D8 z(s(b1#jSCMBE4oXxY}wkrJ3N2{lR<1IZcPp_4jcu34h5G zT?I7cF+uPe+cOdlXMU>j+RRf+eY1{64u7C?A}F0$%ltS*U{S&aY?>+*_bfiIM?^&H zrDfki2$G#A{1#xddjK}OTuMhK zSs5%L|8$fZ{4IDhrB!8LJ*p;h*Db6am8dExG>HLKG+nb2=$oQ{KNKbm1{&5P@&~_B zTpT3|Ev~Bth%pMLCnY&s1F1||<2F2e!+$?E{2e^arwTGL2MyuFJJq(iI$cL;Y59oH zn~Hm-$*@2tH1lh<+op?Ln_J_r6Qu?Qj+>*&2S@ky=3%!Ef5VeFTq5vT9ql4F<8Sg~ z=IB%p^c;WJnvat`{LJwi*j##`;bl!tZt-yZN`xlJ|Ii|9*H~tAEHK=u#TFmjRHOOqKS#_uq z*H5wj2+iF6Yp+HftcQE5+Tg9&S>Wx_=PF=;1XPBWTbjk0Ts+ZE|)FY5XAp7|Z) zUdV4+)DJBAYQwXwU{GjU*88)Ps?SDhHsLuMj;Cr7f<(k{i7l!k9hG9+ZR{~ckx z03%wg_~7;FqeREGANgh%lt}BPmK4b>>l{1{rnc`UoW9>WEUR95u23;UsSHCeOpk;} z3r@CD&2_twr9#K&D9CRjg_}RrCNUelYV-8)#}h3UKgN3Ym9hWlW(slC&j$mFI0g_{ z4N)`}Ep|j{7>I`Q# z>}wnCY)f``T8Mpp3hjItbYo(6It|enX?2>5cY9t|uCiL&u7>(W(7FcVdeCWRzg4|p z3#$ABVPhA3Wri>2o4?PC4MRgA#+BNM*ja}utO|N&*QGOmTT2!yq!DYZnZyn*7qC)l zdAt-(+Qv}W4WX8k!&}U8{QYuElNhkng_~&ljo*Yf3bob>^lO2mBZ*hbSf_wb#;%|M`(r4_fjJ`+G*Y9)fTZD z-pIOf3KZ6z8?}5?fCdIQ{@nnu{UJa{L+tD6@gZr^abfu9i1E+*fQ$%-4Qyf|cjDJ7 z9#VBJqMD=3dOtZvh5Y6?=t<7wzqn~8KUcO(zG%NyM;trtU;RZ6%Wj$)!kqIhk5vp!PmBN3YWb=1>uHdQ4e&=H4)B_@C%Z}+CMj~fRIS^ewKjp4=n@?mja-i=v5)NZ!=#I2 z{+Nxm{dk}z;V8d+^@YuVvH0snT&d6)R!VI4p>24N-dLE0vMGfv&F(|JR+CsOQ^;AN zXNbmechFhE?4MM{h^R4D253W&geXPM=_hL8D4E`&7<@%W-C_&jEB`$q_gAyeeSSgT zS)6-yV6k$3=51*FthDn->0a1V_)jg;+A^y#3gTdA1}!r)GYj~`?9Q|EKby)wD>4=Y zp5|i(9X-8#1~o^T|2h5IO9ov9@2AhHiUgJVC%&%s8lxT-`p!= z)2a7jqurzE`_pnCP-wSA>a^*%U!LP%x&AUTZC!RUYphk!iJ%l+!is4{x=(UcM*LC{ zEuQ(Mtx0AveNtqmYtk1@- z#q(l%O?>61;Zqru-fS3@UXyV(+z(JUZQt9{iCy7=IF1kEd}G0*I8N5|C&HCdMWrG{ zVTLG*oNA-9g2EJI4S<+#pd%FZvFzW?g$ZsZM!XxF;0fhjmu}VGUHSTg)k0z^(rApo zJ8UeY@788+wDtJFG9y}XDuLIKBH3FRp8?n1rQ%I0i(KXk(X9#C<g$_^4{;B76|WcXw{+9%+)LvRZ>B=~%~SQL zv~)34KN?fN^V@5wUoTEYq%(~`dppy6hY|3y{)2?+LZyKJJ_crtlFL5v!1t6zLU|NL zPi(Z(`-kpgrP!DlAJH1R*H-_#4}%|6KLM1*xbldeX?c-3$X14JRpx^}%_PDFW8iSH zo|Z=Fh>jfu(jfdNk}}oC_GppF@Kpy+%A3&oL=xNHwA_bLW&1=^MwL%bEE;*A}xLd zXSd?Gk!uGL3e_8M^yc6-px>>WB>wlw0@TE*Xi$cx#P*V`bGuxi$89@ecwbrMCHb>$AI(_a+dhB5K!(4z-FKf9Y^PS_zg&~%q7{WPmT%B(3KItB^^qD-PP zh&3@O_>?}hzhaeBHW6zQ(sWq{O6U&<{H;)`uFj}?HCCcAj8zmreAxEfNOmji3w}fI zU_#hfWMY+A6qS|~{8dQargV@Qd8kcFwotOV^LVc92Lr?U`Of-lECQ3a;aNp4cgbJc zQ0??4w5?n%wLCoBoAJ0H-91Us2c~9rIuD3C=bgP~f({b2;@Nwq<*^>GA`RR>${z_k z9_TWpKiN($XV+JHUq?>Mug%2vY)+PR>P7a`KE}BhoWws&npL@uxJrH_-U{vZC_yV& z9#_UfpxKF@^o&2OZ!P^3h(jWN{rZ*hjQ{(`g8yFq6@T%!!Rz|iMTvjVB4T4xiI23Z zJwM^CnTB+jNBX;3>Izh~zG$xgbk#q}5y145X*E2=KiYtD*jLi7%sYhmnRTe`NmyO{ z4e317kk~X6xeSDJk~kw`FT&CwaliRuDA3pzcDhYR{NlGMD(|ceU!{uj*aTl^mm~%r zx2?pNG+N_@hlFRhxRbv0S$!>;w<5uxb#i!g20j=!uZ0$`|NUj!d%aduk?EuTbZtY1 z#A5Qp@>sr%itbp*i&3^45la&n8`GA?Ac_=3Ue-^sG9x~U*DAhJp)NLbce8vi;3Hu0 zb@727+m|05j}SKLOtsOCr9RbAZvg-dG+dfEAv30G! zX9HTm@;r!r%{#lrufsZdf>fX-WOW~CmJHqPjG5!a>`}2%!u!_0t99No_-D#23oOma z*e12BX7RDBFOGdhK-)$Z^yM}Yb2q)@MTKWcZb zYzb4YOiw+5(ap}(>c~zwN9au%%%cN4({VGBTbgO1M!alc#CufqQQ!r7ergD`EqXwy zs$FkQs|v|4OY7e=88QMqO?E|a7sEI7PFawQ_{*g_77cWLLctTN0^iAVt^b}d^O4@3 z*;wB6{l%l$dXsGT+L4lqg2G!uLc)3`=R(baf7cMOIzk^q8G`Ybs&bFvZ$TZc4iQj$ zU}I*sG6exhdX4++|G9YeQTy#kmWul+`1$DuM7_t>fckc6`%dAj#{b4t|C1a8pCzO= zC0I=kVz`+$1eM~!*2>DtC@EQ*=|IO*VQ1Oq{kZg=*I)@+Sd7!h z|M~N1%p<2i?x_pbf9J0Lcw`t;7fqO7@^rByOmzG6y#$p*wVVbx>92TGX_p)5=c;7A z>;sU!w>1F6?A7JL#?t&xjQP(pWG3<$EmD|fQTso38dcg1rzVL1NU^Utf%!+XO`5@1 z&HqM$^A#8-BD=SAQ6+%V@Ai1w%K@1 zuN~oma4|9>Dk>x1R&uNR|15$jkKa6G8>N?*ToF9AI46)S9YwGX)ZJ$y{w5d{{-0T( z1_DY&roF(yWfIWIWqE_=AHfa@n}Qh4wBfTnM!)}ajG9D-52+~8yQrMk*_CM*cOepf zZPEQ^1TU_DcM@Wp9>@uy01|)%b9BJM!4Eh%Fvq+>iM`Wc1_AqH&I~U=O@@joczxcn zcKtE}m%G6dY5Vut%EK}MrzgeAy&C|61~unDa$bPATG`aZ!~g@+N=xDYJij@7pd{1) zn#7cK{V@RunR=>Wr;kD#8;1Epd63mc;E?>N7q@(K& zmoo*u(AugV@$btKkm)b}6FKU4SHjp^Xj45Q1fnl14ERornO~?%Bv2Hw#8o!&hEmvy z3CPLsbY4>aKKO4?bCDY)K^OM)R*-@GFl;PG7170>!-vu~3zFMg(J;%pPe%h{?KL7G z*f#gBjo)6BARKuxMG^{@>k9aNE+4gScNyDc?HFFF#TE2joxP!fO0bA1CEu0JO?X zegNpXVvM^d?=2u@>HpjP;dGDR3(3usfws-H8K!ujCc;MX=@}nH*<4r&Q!@q$G5YVz zZ?4}ks~5y2HNrBTW8Jp4P_AzKS{=3Tg*EO5qm*QLE$6CsbN8mbUMUcY=qlig2#p-^ z-~MgZQxj-UI;S3z%{Z6)b%M(9u=n>D?(yWNklF8#&ornE?HbRI(O~BasS0f^jlVM) ziO7>G;Gda4IDw9$0n3e7^&8axnyLm*gAx!<4|$#9L#zMA&*;2K;!ncyM(F;=u0?%P zJYmxk1H$q8z+XWD$Grm0ohIl@-V!R2!?L6U2P(8TZhB_fH|8pe%pU41FfNrGm4vrG zIIy6@^Zo`t{zeipi+){=W)m)t7J2jZYRAMq5$9oVpVP}FjfU+L?!AEbLrYyzr_lLLiNOcT=metz$|?mjaQMX+T1)32{)<_1*X(e=W5``_~{%b&saTr$bK0| zA=tR>gW`c`{ly*Q$(0(LEcct%rDB0!+G8pTqz-)UJbU;NBp!T59#-X#c= zXh(!0wVl=%yE`y`B2q~Sf06KmrFt*-pPt!{l9%ll;oO6g&p`m6Jgi|XPDu);`UT#;oHGkab1}kD$l5G6urn(p z@P2D?&-U1&bJCn=k=2$!HD<&%sbYWyqkGwW_Q_#D(E(2p+ex@(NY-ZMe}X%YXpq zE0c_1nN3M?TzY0uKyrJ11>sswvLx<-dVLlueGa~lWf~ZmyZG|fb1E1B9}Cs|&g(xv z1Gk&}A`sIAz7wPuSjFwzr}X$kwrsTQ<9L?n=xCNxjMDte1rkF1_dzWpY+x{_??(vR zd970d+CQ@VFIo0#8EUH-!G*t5jg9(Cwl&I{=P#{{N+{=!X;n_r@Xotc>C^qHDuzNl z^4>I_Fr!NXR)}lt65sK)rL-GLywX%q{#qU6&E-dQAVz+mAv0UnHssQex21nistwJs zo?K`gXWEsW?ni~p4+P%a9v>D7{;|+pc}Bghxb0EJrItJ&nZ&~_PeJCQ+v8ul#6^}e zf<|g9AN1=3o8=uZ z+j5MLhG3m8^l^^zS#7hvcist*GO0JMpO>0P8~OKkwCBw>SuD#|mo#$syw~IK2sKgX zSR(3pKCIDHyRNYtn9St%L|WarK-$5}s^r82ReS9@IV??7S{7Yk+mxoLtnJOCY@5~L z;JqATR(5q}OS(OOu4|rlkv6ue5{3?Cg6`?-(9wh0U_eux3VY82bqF^+_*v>Vu-qTN ze|~aJ*Y-w}R@oOes+XY95oHjp#;uq}1B*qd#0(hBD01Vu4Gmn<})l zb0A~#!Q)~3vNc^LUT=$vpxl7}vc(3=egNv1F5fHnDB)e-hPM$46$<&*Rr4vTfi3Zw zXVzzIs!;7a!EtSes3$`ma<^yCxq7Ca!1ik%2uQ6ov7hF*iCwa|&owA+Lm9!P72+*%Xc%Hh}gKM3VlEZ{Gs z?ELwf|BTokV{XNOxmN7#lsP}m6xAAqRQU^4Uxo*~JZqwJHvbHDzwd$S%h9va zr)nq~lW5;%Dn!vCBb`JNSyLE#@NGxxcAaVll8=nK-pJvC?97$P@e=;m@ zVWPRA1?C}b+;Dv3pUK#DMnCRBDytCKvT=i7{Vr=e=Emn6@M9>V zT1$nsLtYcVifkgjGiO=coQa?E_7JrtP@ZjEPQHGb_6eRTIXAYo{E(p)e}PxxbScU@ z^qq!jq~nM-^TW~G1S1bhG*^k|&Qn$$Gh(eJH3293##F@y*!Nz+wtuq9FD{+%&+9Fd zY8m@@)tXXgwVzqyv4b|LeFb6B%K;I3aN`0fwPVBD@gDbgvz5!B1V?|8b@PzJ`NR;( zf##HindW@2_|(-Zd-qbxX43=T6ZyEHTK62%0P)8mzI&SStrunM+-x)Pc4|{dJI`n4 zgUzu}_kGh}qhVhWjQxDr6DGA(3b$rsj<{=sYj}+Q%nlXrXOlW!K&}Nsam-ZIZP*qDB>Ahx+c!@yABjxf}6y z)o-ljJ^Twj@0t*|%Td)^ZXRjM-S^geC>B(au+uQ=2WNFTHTV5%d4jBQUYFLh-o0N+ zkMkRj^ZCNO7to4}%zrpxah*opsMz>eEn+#Jvne82nc8TDeh{Je=~IA*XmeY_pkXa$ zsNgI5p!}2vdiy0pGk`opii&CbFqQBy$71?Gvh&JR4-bEM<=3)$&X(dUwahD5@w+e) z(xJ;zQWS&AXFf|dw9m?4lV2Qq4AL8JCf%5Sn3a;!-&Oe(>4%A7sTxd;v$luG#%Ia-wY%J$YFVCA_ zRl&cWa*E!dFc_1&d;Ihm*%0g&0lcE02$a{KZ6@v>XZ1BOBQ(XWJ+npYQNvAz&qm22 znP;MOxqzKj7Mp-4bxP=ChLiub#>me`M-MWl6N!>uKEq%BoYFh4)L}A07{OBRmTDg* zlO)j_MVS2XszsMC-}acfz3$#E{uX9k{8#!d!*#g@4th|GnaE@BV;56|0JsaV|#t?Sw7p1c6WlL^WsPCdK>GM=An3K*T3xW9w#ar}t;-2smt9RhA2q;rH?#?oQ( zrxOgky_YK@A|f31^17$IMhD-LauIZg9*9Saq`j z%X)>a0i%Hv_k;DbMG`v%j=Jz9KMbi%2Q|G;qQkfh@;bY@6-H|3M28fauNC6>j%mC? z4`R6#31hO{ZkX&Zd1}~1p!hJzhdkgq;y~;PEQJ|5wCmXlYY^7rV9e(eoal>W3ZPNV zcV+$VyWa6S#U~7`fssh9*U6_mol+Vpf{VZ5n)_X5!fvsNrOMdiaJX(=(q2kq`f|xX z&VNR>a4_CMM(O8?V_ozl%%W6}i_+$E{N+OEKYnPjgCCzo@HSQt5GdV7$Vu!`2f}(F zj8G#yNafin3_qC5-rUzdsN(5Hg;$uBY{m!CBgH+t2Pm%6?Ga5>kDn1k4j2uBw(@+Y z-AYEE_4S=T``ir{sh-x0RHsfpTZ@AcjOX| zrU9`2qXzaDMY(x1;^U1Cm9-8t-S?H$NNSDOY>$0?2KcI#rA~ElrLTu@HToWK#p$Oy zJ3B+A*0Vpb9Z~%1F^I$jz14-iylcmw7<6*JYhzz4ilihfDq3hB8cN;PD9jBzw%G$l zok1iignGxqK%l5!zBM9%MZ;&A!_#1jAI=^d?E!(Y66$rQN(CV7Owjl#=zHj56yPC2 zfMz&yY_02;hj=Y2UJg@v0-KSM5t?ZD^2!R_Xt>YU={FmU&*(71uw*^>zVQ8Q4B0mW z*rKg-V^HkJ=_9tseSqOvKlk_8E@B)8ikVWX*_0e4PzJ-*glZy>2-`7z)G%2qo};66 zM$8N8YrhR?t#k!6dG3j<0yXLwr3au=aoLwJ9001hy;eu82aYr;MIUL~exWgSGJLk-M+mxpwiVjz_i@vJwA zCGlrtgwHa^y@h%jEAcL;{w00i_(*=)EiBJ%kwt4aPqAU@zzcmvf*u|obw%)rJj@XX zmKm^WFgALTPfBpy5%Vjj0Bhc4Hhfs;xsQ5<4TU*mxO~(7E97qF5FKzC>6z-5Y9k;2 E2iU8KRR910 literal 0 HcmV?d00001 diff --git a/versioned_docs/version-0.45/develop/advanced-concepts/baseapp_state-initchain.png b/versioned_docs/version-0.45/develop/advanced-concepts/baseapp_state-initchain.png new file mode 100644 index 0000000000000000000000000000000000000000..d03e88ef2ae0745aaedc52cf72863080388d7e9c GIT binary patch literal 32800 zcmZ^~Wmr^E-#1EkcZW1cNr!YvcZY z`{8_Xu+KxkEdH&Z;FTlTDh?Y{h>_EiiCp^9yZ2?74RmI0WNBV zg9Du_(+eUZK=Gi7i4$k;+wIVFesAaQET_LFX8+Uupub zPAf~?tR)A&eQ3>kTM%AHnh|- zU;s^uAH-TTBszvcg%g#?Z&s~mC)q;r5pyeof{f}45<(hEfr~0ejJx(5gN(Y;ok%N~ zKUTs;QeR8&F}w_Hf;hcP;2!=IaeY?OCmVqMtuiC;56*r>UiEZEo_JpJ4}npa7{ty zQO_jP?ajT;CYvstlWBWb&^Dj*6_ix^VvonBr^62Y>`pI<&hJpa!7QQl^d|*MM1DV4 zr6&`@=l3D>AAbD3b@umrp@KuY{M!%zl2R}VAuS%yWyfPs3@h7tkw~U!`p)Pdj%mPL|rI;pPjJ}71w*|8oQ3+_V05R zZT0Lsbsylh!<2=S$C9e_LsV~37}N)3RoWzf@;=^<|bA>4i*S+-JL@17UO7dhaC{j{J4o( zOt5k~X>XtAV28-oVXM-V)N@qn64WR7ve26(=)Whbh^3bZ)3qK`_V303H9Ev-?2+`; zsIBKS7#$T$Zbi;4w0U#Dh(@Xc5&HIQQ;9M+=!pfWwm?@hYZ>4%g<(@+gK8u=5J^gq zAzwRU%>OQx5m|=EwM>k62V%9^trr`YEDBVbciK`@tkff7ig?JgHAa{TnSk;zEbZi{zX$}Z21stuu27@Z;Faz$ zJDdAU*<&f$@oFtkLXPFe07N*XYfXPJxd5e^ZdqQPkpCf0q3?|bhy51P@Yu8s@4HW< zB>|02-HLB1cnCg~&367V3Z%0;Cm3+vxG*ml+s+yBjv|o$Rh0raC>|gjl6`X$Qf3CM z^vuBLfm4~_Id!1h@N3uS3ga_FoRN;<{+$P~njXN6h==Zk2o!Rp*?2kS`s!gARU>g` ziG4}2q(mh0j`E8&tsltM*r8%JYoXOuA&+}#bTYpU;S+53r_)uTuKM{dBzQZWkooz` z+6NjihD&*#DKzXG?65wGIr!Q`UhGNdZs;d!e+FL%a^YYy0f|~Hq z^vmahzjy+|z>)b(*e$}>JvS{9FYG9M>+2?sUu4Q`+-#icSJ*rLJEdq}WG#GbQ0%5$ zL+*>>Uig`VlqR_+=b>>Eioi>AF|SyiH#-&dnRv^78hdi2|EXnaG(+&Fw}Xi9%wQhP zcB+XBj;n#OxbO^ldj5uM8YH?N!H3d7MxuP%itr&%2#P*@2etR=VGGOK9o z1?OXPW6v(3Q9O@YfLn<=!V~;<-YM~?8t=8YqOHEjSz6m`tK0Rdo8y?$aC+;Gw#;%j zwnZHyt^KhCc*QZzV^ZV}3C)pV!6K%MKCy%%+T1DJg#Ot-?w8azOJFqtS5xXf)5rx z(W@j=5C@1y7Ch$>(Br^SLEFA?5Jp=ZKdL2Ldu(HiTRswd%A3dU zQ5HWtTrZn_r*+kxCYqJGF43c%;0rwI93GNi%$>i6Ee4H~6};1sAgF%b^obHCgxP+- z16$6$tMq_`dqM>zG14ZSeI3!D5cGFrp5M{r-*M9~{PqldJe$<`b~23ed2W-sjuXS` z3qm_L8VIONm=k_X0;}@WcSuG=qo`WAlxZwRSeD>2Vd|j8JYUa5^vkC>;%cWSMMSMI zu}Y)pa;o7g-}_zK3G08w3w~GYLX}w$@RNU*2!4(I$yl91RLOiOKBepS#X#kOmN39! zcdBHMYCk0KQwFJJ+}l(1cBsH>a_r8+S5QGOk8D@veu>n5$_x=^*JwOFSg7Lz)!zKn zcFkjOj3Mu2e?-FD&hg#m4`Ad+P}OnGFZj*3&w?Ba-WCfeG^eDwns4}=1=lFKGJ{o1 zD_d5jV&>%4SXp&nT+ujbJlTeC&El_I;N=EgKR=lg78fkg%MBs~;EZ)of@NeSgF1M! z%6T$q_>?i$HfFKAr7@m968=Y#atS~35a}{?5;?Ct&g1Fy{aH&I5I2Jnx&@vYqMf+lyLzLN>?QM=r!~b72^N`=B7X)%#2_$D9N<+k*X>2Wm1iYFzdOaq1Yo1<5;N zRLLHu=N%G5-iHTk6{%Fsgzp8j=3b-99phVhT?vIe#lnTZAn`lWo9x{h-#%dClJ zy0!S5>rOJ4O9bp%Jdo6>xYa`*8$?kuf5$qp=Grv@#oeo~wkZ`s84O~u1y~v#&jdK& z+IAsKo?HYp5L739{i$-|#fa%7DG~+hQK=vHM6TC;^MDCfNLH?hR?KFJb}4LKoqf>(dmO zsJ~daNlZ+r2;W!BzQ*oO4cYq34*FfeLU1RVdbvgQ!(W*3z_l0H zHl$h1I4S@#&t>^pL7?<&RhPVjL(7#QZG*o~8o$0en?-5Fcwct-<#-*W^JVENzS-R7qcKs?S7?JxA-6n;P-l14a+FmJ@bodvUqNngcgF%=bhh?P~vN_@0 zrx1{$XyBN|ZAapSeLq zMix~RNA-xzk@mY7Cq3Cz%r|Ov^<({_X5atQ{kOsrAC!Tq_Djfw z7#JAOj!?YlOp$~Xynt3?n*Pd=LYz$St%k&dG7dPJ`e~zF2UY;Mz3*H;ZS*TY)er*q z#*S@5phMlU@Hzpc9}cwrp5@2j!fVrNAdP?i3U>yuR-?y#YMTml;30bEyBRSJw1JUF z53nRf!tqxDAa+0-;3}wbCIvU8CJL4Lh$RB=v8LnDH zf3W0Xp%%?$gFmtF1p{ei)c9B!(CBRu*B?)`JJ=<~o!)uz00ZLDVm2BjA_Q-|j~f4Q za&k@pj*j)xlq0AXdwoSts`>J{FaX#8Crz`OEWv0P&Vr_|3XE#dj)gB0jz|lbU<*w{ zPgyw7%zN<(5sePC*N5!-5YG__hYAM`30+z3i6*vhm@FFoPGe&N+*q{*!;s)>B!Ch$ zv^j6D9OzZDM578UlHcDBlehYu8SDJum+no~v4$@&YxfHlm=ZF0m#>f{tm^Z)eZ@wv zn5bWG*H5st(^J~%c!O9aU?K&gsZzMkX^ug7Eo-Oo}yxgE3zeKa3^A0^QSG_Y= zA)U8mpxx%g!|VD4#GLWoS9K`0fdmnaptt@&kIQ8fW(eKb@%Qs-%>JTM%7_Qe7~ZPK z=09BMA75gX41PXg;@`c)KLRH-Q zkU>3;mP3-*h-tyctgqrju`Vqwz}u%jBm!h-p~>{R>`~C~6g&Sz0+CT;WyI)MTPjgC z&ZmJyc?AWo87KYV4)4io?@3xw|9b>@q|1)dB#~1p;WwGs{=Od)43pdF97T~xE#N?E zS)!e3JT_w$Mgo`n)996zm2e>LRCE?rw7IWvHLxJ36>9F^@DhJcg=Gk#0V1u~z_$DG zGRkr8w-?8R%>W*YTNnazo@{)%{@J2?zGBA6rgmyZ93j9bP-ZzEBSGE0X-^!Hdpy-&L21IMSUMpFol~_O|G-c0&{F) z-YKLpvRgl$^1QPit{j*^bOQj)i)lOB%daP9_0~i?@FG$E_DRd93}+f!!sC^;FUfyI zC7Jy$_8G)j)JepTm!lB#{JAW~k*xa9a6u;RA!q)=c@~+ywg+o5f5KXCwuX-V=t<|> zJP&+Q@4817e*A^?C-;x(tWAESw+u&Q7vj1-*+9GCi`BVfro-Q&T87*>?U4NO_>k~+ z?=P-#vm2Gua%<<5oux*ZE<6VLJEH!CqK@1Xn>_cj5fXs_!3K~~9A1x-<$9O_*aZ~X zcD!6{kk=-O6EZut_B2+YrADt74_Em|q@yI7%}*W^ZV6(*lk&!FIb?N2QEIvPq*Z&K zYU%yzR6)vp`cb{pPI-q@|AYhqizbG2xDSn1;oDSVh+0|7qRsKtZbu;Ft_IIsV` z+pC^uycfreBl5azh7re9W|z2Nh(CcvepAb)25_N+4e zMk;o^?~DB+R1EzkROo$$lv4zdNAAy^hNAvp>gZm~?lTi3^=cVA$hXv>#~wwCeVSRW zJCYs)KK~FG|J`Hv>+@GdL1zgc+Wf1;m0Bljuj_WHfJca> z$T#McN>3hn^wPIeS&FE0uww2L+g(y%${x3!8%O*=K~ZhD_SR}JiM&ORQ!dTPKG)RO zCU0Zi%f_oEN4?~C@lt7CX~ya8#j^?c3cY&H%-GFXH3L>4Tof7OF!GqgU!zHr4^ewK zy#gbW$4z|*7CI7uA>9ED4o|%p5Ut)q6Iuu@XfIMWLzxFtSCVDi8Y$6vepX4 z+y~jXG-&t(F(+Eh`uwgpoe>!^DBHa5wI#z=&e;_b1-Ti$-K0k~64Y}obhe89bQ|Ev z+>ax*`mikSti+X9oGDU9v-mgJ3`)rSGTUT-6R?bbI%WPjR|{Wet;{8;{JH3Zo*p7j zW2LEF99aS3S3*`Dqy$l80vOz%yUJ$=jH;EXLVw})Ml&@e`o-d0Kws=cVmIy*_?y$>_WFNPW@x#x;1GTB3cf=;F1d=a7cZwOq=r(I>OCqN~-(dqiBb@vF;#$im zqwmbPi3dDBJ-VXJf!G_qo>CFd-RjMXDu{Mr{o$F-mJh%0^l`a#h5WEj9?{#69d**a z&ATwqxwugV0hEVr_8acI5F+WuM}zE|$tj;YRFG>0H|>B~@{gJjyeKO_yr_b@DHg!EtNi5S#o2b-j1;ik0uM;5e@_t|&OUU$fw&*N z`@yJGDdp|IuM_kV{>R>Nikc}lw_~SZYBpu$5lK9SAMGm&nPHp!%?ayny5}wiAi>t4 zDdBmfdwR+TubX`Ymo?ivk}vUA4(9UYRk*i2_OUz$T*3@Ymm`lBPIH~C+94YGnZL9K z3WzcxhnO3LuidMr7R%EJhcpf!C%unKg3IqyV{=)0XhsQ9n{c zNxM?|!*J1(A+?hn>mm ztrA?GP%JQJHR-wv8@7*ALVc?(@8AkJ@w;pDl0R#AC?m&j?Lt)DJf)h*uBI+J+^!y} z(e6<;FP>WCpAtk_36xGxX7fwOot@dqcLEo#EyKSH^KFe5$6bq~a6cVv>W6HPb^tGZ zX!)}_&uW8ZpB%I$keE{Bk=U0B!u?H{{bM{Vl!Sl!*Z$c?-~JAn_Fm6YqZ5Uq!c4K~UkHWlwaJa~hwDT%G23|Yf$d4Zqf>ju%JI427y z8sK)VPdG24{*px+MI0SM6o8BOTtp&i@j<3q`V+dAnO;&odm?{bM(n0=N{(=k)pb0r zH1(I;Y97$H5DEXQ;7twcQNObi3x`Do^=syHZTg;{w!t-?mSpazzrCO?=t>H;eyiJF z_#mhMW^5N<@{?Pf2NJWz*KfZh1(aN|kd;k}XIx1SJi~_!FsGNAJrJp4%1BHGJ^W^M zH-{34sr}Qb54Kf1qgX64wgzU3BLWh(yYj|ok;bNO;{9`dOV~SXP*POq0Nlg9ySOkw zJH^!e)$!h^yT#pqXxSAnx))2je_;AM`z%wc*c|4@>~V-q?LL}9cPRN%SxqG+;lI7k zqp|IJB>l-y^4Vo>?SZRZ=m+1OZ9c*VMlZFc01USy6mR!M4-M5cq=~~SDmUU7$|%3= zB=w*oM;tDG4&eZd_I(o-%u7KkxE2Pym>+GJ?Y)4wMTg+*Z{&dra)Uysa-{nhZI_yB z(TeQ%*1D04b@K>_IMJl;F-WJk5iC~;x!m7MNlUMd&&oGByTZeN=XVs=Nm+Kr2S2=Q z(6=bEpV_>1{|cv@C-FJR=#~$J(9pc_HSc$C4CmFAYY}TiMD}}(tzoL|NRH5UEi6p4 zFk|&B(NBuT?Os@};Wv5?(0xy^u7q4)Op7Gx4E-Y^>s^6is+znkHfX4?noc?aO8Mc` z5^^<=T@+8}XQs-+m;m*>!)jfif~envt~t6i@%1hZFF56iqS zn2zA%JLd%C7>roi6R_RtHjmAhkoVXxO&?KkPnJuDVW%<=dUv0PmtHaqof^CzQLG*W z1=`9D$yazCznJn321zJ_Cqvoz47hy0qM1b?Hv;kj>#u3v^`G4I%QlCXT+z2DkN%XP zD>fG5i_K?~k4-*D%@*o|3%l!2lu=0)#l41pMRKEwO2o^3?vx7;H`+gu0fAu3t#$P9j4NmpfM*=r#jTpbD!#IlQ^K>8~+ zU7s81kCqXj+wi8%s2Nqf+@N$u?=GMn z7OVe<`B_-J{cOqhKd|R7=?N>=d;!mwlYao*T!?RS-Fky)Yuqif6Mpx5^O59_eUc6> zABSJN+r5Ane?{p`{uYP6Ow;EW;Tv^_{<*4nRraL3zSHeuP=)&8U{vu!xlXEj4h#6< zVCY2dVfbEvGd-rto=;*#?V>aW-){{+YCyZ<3t)ql-e-&Xd<6f}RVA?V82h^m5ga`f5vaCpQE18u;gYXb z%X-7m;3tl}b-=56k)wv-589;B=Mk;S7U(*fuC-Aw(~(DP!;o$Fd48)X;ti0>%N@uO zw4T)SWSKuq@vg;jkskouywb&qI}mR#k8aNP$FE05ac>+KF6VISG>=H8@dVy*ZT3_C zS{rqql*-Hq!CHkj@qj(-3Zl53LhpyCuqF^MX3g_YV7kc!o`k^n=c2KH(|<5X6@Wk> zW@AY8XVvP$$fP!aN)`dlfxK}qj&FLaSP&%I>UI`}Yo9`+6$|wq^IWIcYQ_ca*SmI& zVX1&O)`hNoITEQGty2s)4@0A!ZU{521#dJ1kvcT8k6KNhpy|~_sd>r*jKj}D4Z4rs}vVW>~Nr}CS$MusU_5$GK1{WYInZBPYnd2%0 z7vFi*#KxK?2FAb8D`$&VFLEIxRP*jlSQe_85in~ktZL)^{uaaL{Da=U!uV?2k&uL^ z1``BAnR6k@$)N>5H$xW6bB-8ivM~K^lW9GlTE}~)V#U^krCJts$d*R)1e{Fi41T|4 zn+{*ubDD~VhDuK`Fa7Lr5e28@X#O}GOyT_g?o;Wm2b<}j0UY!Vc~F=lot8oXC)!-% zt0;hrhC>LRWVP^0z_C1>f#LAXf$x!NR0%XKdYVB3QpE8K^>v!1H8aoS&j`-G zws(88$m!|mmKzp=o|@vsTf4ZMyCe1cJYzVO3<|n-mq*B}L`ipyACoIJ;irx2_*znR zL_pSYQt#w|REkkP-UlSWNkb_MQVGi7QzpY+aWB);Xwqf(@%lSY+d9ML;d>1K5)o8s zRH2*s9dLc!MWY%vk~#LW>IcN(l(Oii%hVf z?rMB{f{KGP;r1>hgun*N-j*AhFiREvYyTO6Z zXqtIh&}4w%k&zYJeE$g|6bKA$YN&#{allGoEe?1h#5dZ2^B*iq^D4cfZfZ2Pn4>}F zml6kpWP(Wm#gvHd?sHLfP)1P3k!Zz))*nEgJQsbHqiaUPWMYTI|6EY*zuliJ0sao8 zT<&cbpQ`c5AoEXQ12D3%=*%6MKn{ioXCl4qRkyC)-qE_ZHhdM4&nfgP;GEkudhC;` zb7KKuCss!8|Qvy~736sCq#XTXgKyaBH=cVYX z%-SRXnQ-X1G$>RS_gXsV$EU7K`3G-chfI6xYxN*Uu~>up#E85;2lTlrK1!7D z@aeNM01Hb`{~mx^j>FY zTEMU#9U`m5zsQm((RsujvfqQzhPO|d$X&3f($RslE zg81*o!wr{jDwC=GLy^uqLXV?&USA$pEX^uDc9wx z(Cgut9SfnN_a`oV_34~Y{$MI8dz4jA)Ji3t&Vn1`11=uLXI(K}FrWzoj&ekr_~W;+ z)sL?TR#q`38vHFV^N!NMWm{_BZLhm7?@82u`)y&TqY+NS+pOr5WXImK%#7(-pP&LH z|NZ2?pb~U;Bv4p2^h;E(dC{@;Xr^fj5IT}GRPA8bjHH)7e2v&WkjXb8!ZtE1SsNkZ zF+;|Y(qKDaVZ^=U_F+dTz?KTmH>EwPYa5k}(Eo`%eU*vCTf2^N(C1n}?(=k%?2cU; zA8^E3ZuN=8H8EW6?Qyk*7BJZhdxRPNK})UQp$C#)E2m>XE`%Ka!J}u@VDNM>c z{g9?I^97&Q$<*={ZMOb-g!|5D;&Z59gVQsh^LHUFp{q_B!mg1MHF5f1y)dTbfAm7K zwBI{_;~gdE8a`9WvCrp28~i29R(Wii(%BfLY=GQZ-bt7N8uZ&RHRaf;>+-@d`pWgG z#KdMl?&CclVDo+j6l><;z~y$WPVf`flJbna?aR&pgJ@eIF(5Qxoy-q%y@)uyDqF16 z4tRUWk^k9K!slM2me+i-F6e;wl04LaMz0RupkG4#HP2h+4zrWp>Drm`k0VVSNDVSJ zd-hZ#I-IWWX?Y3FXmDUjN4)~&F|9Ta>GE`bsvD=3E`WlA-5%u1)5T1ML;}s)zEZLg zu@L{${`#G^?d*?8j`WK;vq=FX5a^O(@534hCZEYc{ZXI*&@cJ5zgd*}e3o#pn!4%x zz*s6i#k`wTJ0P)#!RQTPhAGu=UGNAR->8nop_Ug%3|?DUf>c)O#wkE9aYj!Agh&yR+p@H-F->f=X`f)C*AfVskC!; z&nWMS?rpO`ahUnVER9}U2*i1>b;5a~5FQOlXj#`EDMxwQ@Rvi+*+jjCLLDFM?G>A} zNCB%}UuxFT^eE5HEy{nzI<$8JoIk%rc%F2)4u}@Cz(PGhy6OwvvoGRcr9_mfEb;Ed z=l84Bb=X2KJAA@{ZW3zL;$eVNV1BrtsgTJ}`S`v$CsK=3+hMtPHR~E%A4ZIPC5{|x zc3dmzxHk)V#?$Xcm(O(DZmtRWm5b3Nh@S}9Rl>ei@y|tp%+J_VWM1ob45Kmq=cDI` z36Ql}ME{k}&_~?UybPls-{~q@^snQnZ^?+;b5jDttePmB;BAP}EC-$4@6CZD!+mkZ zPGvk~WKoDex(O>$5A>rQ0%%kc@ghr12ou+f5 zjxSp6%r`M>ddZ88<^{B(rN{zZc(5Xo-GL7Kz~YsU$yn_L7xdo&lQc^8UgmjJX?^R$ z28BXMUC0dpVwmuGmslE zC;ec$E@bbt_Uukkxs=K=O;#gc@?OX+Qt8H9%Vq!i)+#-Ln zF}3AH;L*o6PUHKYn8lm$ItKtiM8v-ax)pzt=sk;8boni&jP@;lSFgJ|)zw*kJb(kT z35Z`5{Y$!1FfMSZnn;62mV#9rs(~z2sC4mFsQEzLIg!K@)(BeSE@V8-lEmY1pORVo zT&dnUrDT6RZ{Tyqb$xnj+>)nVoKUnY3%;Wx{5|O3dF{<} z2u4~hD{6^Z)|;LwYc#FVZZ+}G4=?~C`Ge6;mX^@{(C+idP?Ec`?+nxWfMN7;Aw*iZM(&Ax=k0ziSkoFE$t?K| zR#x6rZU+xRoqG(`<$&VFkq;GR&9@I95KY^Z_;bM}oP>!OS@i^19}+rW^H0}Xa!4G# zD@`u(aJ-I3WEY?M?`jNZKa~f%J?w&<^WeKPG~A(p7dtmbyRlI9HKmMYS`_h_R4rVdQ9z`%+v@6mM_t+ADzguJGsQ}30O*Qa-)h$- zm#oZukls@gs8raiQl7cFSk9!r{KC~}zI=%?D`rnk4hPabg=IB)jY8PGmiB+E`acmV z;dFRF?hN;^&Gm?UcUBzb?BG%IzagoMM7xPDr+K1!j;K$&rUigDAjJA|ly%vYd}2f1 z+!cc|+}u>crv~UC8|eaF6th*CFIP;2nv-~*^}3D=iWMIg1p|?YVo7rYdcNFCZ&&`U zWs2+ixzXTvZcDMyY+Av$k^6v~nGq46_wX;WcyR_58a&|cZM@h!j15S@S}nq9Bom_E ztH}Ao-#-X_1F{L~cO>sxo%eqBKdS(OJ;3p&kr1BlT%fe2;*F}}rl9Y(6Vp0hsOz7r zDXFr%vhgMS7x=k;%FgyKp#wmS)oUn~Jwj5TGH;T1DngNTf65~%J-vOh58G0qCEWfH z16R*+zql?7VqOKOCslFXqJ~D)D-c6DJz}7Bwbxg4^=YflnMTxp?dG{Z3?Gt(uxbsFq6D<`UG(=2BRvJ66&Uv70&~*s6>4?(VX)KaFQhjR7cEL|C zLrI&%Ks7YD^yAS$8>EU7aDnt6QDEX!0H=Dy)62%gzx-gY`vD+Jk*s+q)DQg|9Cg{w z@Ceu&4CU3(7EdS4ql1gIeQN2(g!?8xoUE9EjUp#`w!XX7ZP@+JwzhyPJS?ma-Mda8 z^1|&n2RO5Kp8}}@Hzrc+tzL|R@rOHw46zMl$MjOQ73%P;#iWr?*}hRWoS3($5ZS`- zk78H=FOG(f&s&g@^2-?vC7CYzJ93_Z4)WkX6ePzok!%Ll8@fxCDC%sKn>aYxc0)@_ zqlb;3T^;`SC`KGS;-)_-@*DYjRM^I1R>nI=fRs1RWlJ?H-GG*~4`3LciaPFA0_56q zd&I#aDtmORjB2W)%pC`Cvv8{~CVnr^k4i3Z0)B`v;BU61ilUbSlKd>I$uvdp&9MzT z*v&`VE54a_4C`7C9N*tX5y!%K-96)6_?`&(GWZ52{aV7Dn?a&qwRYfPe2S?72s3xG zI_p<>fV{3tSlM-@!kM0ow$c~dMK+F}QVd~x>_vw;1L-Csr~?OkZ!K{BnJDZ;tHJBx zABF_0C`!cLhBF0*_mI8zxJ=yw-CE%N@F+3%Td4t8%ujw^IMD~lz9-1>qm|FB3Y4EM zg9}!GEdysy^}hs037z{D_->OaVsdLrxGtf9)*E^h6bFfjz_sOBni-hPKwt_!f!-vM zt!k6>s}myc?C>ro@7YpQ7_=?ONGj_ILD&Pf5kdHjpZ~Kn^z-Mg!>X1Kun2Hq*wfzU zaGMr7AP>3Jl#nH_1)TEXjaKB=piw3C+B`|b5ziAJo134X=kq?_B&4LEXj9A-cF*;_ zIo^t%jQrj!6RfXGqm=wMC0ji3nS-8w^Y&o2DsDJKz$v_h5q~`*@=QDs)<*OmmAbh)j$)0(dpO20Rs;V z*cwQp><-6#&^;&)%Ft0ub5kY2L6iv&D}d?F^S;>5oGntz{*3Cd`OZ+I0|KX2r25D8 z?tE(`I5>DQO}axRivSoN@CDd1jgFok2CMbIkss(q?fJCcP)6DyhJ=Q4+m8KO6>{A! zcK8Prlebj9_y2q$_=N!M?Ce~jo)c1)muJa1E(83`b5%#FP8k)2h{q5U7ZUr{3b>NFT*8x>42sES17x!eu`Nq?CpQ z#`jxvcY9;VQw5#h?0#farMNSVlMF@5@qf5xHf@FUdt|@&4G(<2L;iwB7^Sf?#4;qb zJ5xa(j!7O4hlrM{g)qhGFjKAo{9@SM@UV?;o^$Gl4tA`bZo&hoqilj=R@y_ zB8>Lq8vj@0wx=21rCwtpi&%(-g*9Hh)&2%SAY{Ai3%dD8ninyLvHDm7x20Ty<2i?l z{VA{@`p8=CWALHE?)zc5baKBG;@?>BN!%Vnn_TldKp?SNvY2jVKyYJj;AQxqxx;CK z+YZTSD@4U-qzQa}v|Vm(TI<{BjnU#fNnld5SZVV|>o9BtRlsadm+7I2CbJubSGC=v zz4yJAY4f}5a#IZr2WFW(;O6?sNKi8L*?VBavWwWOGnAHaf$XCa7E`h9&Y-XvWo*8=c-}*e=u}s zz4tx67!~gx97Mm`pN7Y_X4oB%w=hesyRJ0-6UCsE{Bd_IM-kb~%nZkCvCb}U;Y0iz z*;H;PCAa{yE}LA2C&0?<+T4JiK%2DeMt)BmeG-571D6B375j`BXF(?S8+^A7i@*5JoUnHK`?YUBx zsF2Uq{+B%YI5N|GAT-GTO&fiZ8#+KN5**4UB}kKahPaX^kDd6|0B46O;KK3mc(!S6t78E(leO^}coS%>Z)nI#aEQ6Au5DaZ`B0u5BD1^@qhxB z|8%q5%AkUd7@X6+qHNZbn8->B*h1|RP1Z0)fo~&t!QXz3H8>h+mum09gIip8u*9Bk zEw5a=NNB%vx_4nN@pPeQvOUMr$_UGc!8CKZ-JvJ~D_^SN^L*kYkl10|s^iAJM&Ux> zYqkr^dG~36S^t;PzekKrJYGSnX7hUcY0Xcl5q)vgdR#I$->x=CGRc8vto2b*VT?in z&azCmV)f)C4oKKY!IJh3pB>;Ix$NYJuv+dKhg+b@V$XY3ARV$A3+r-!l~@{--W!vIwdPAZI<$ z{15n7T~icn%`O-(XIrFVm=uEQLK21(U2ahN4j1LHHzEIk#Iufmj4CE20sHtDI*2o@ z_*yuK7+*k$*Kr{+qKK7PJ-hB5hBqET7gMuW7>*QSu#C}x?5Vj40)H1QZJfhHDoRNh zQnP_!JE?uaM(^d-tQi{(T6?DiHV8PrbU7gVeEh zn(fFGYF`#kP(f4i8B}#L#DfG7XDa0wd2;yfO$1iUD^2Mqebl)HW4j}sL?!t|RXeNZ zG*<~mFaMbJmM1w}6*P*#u7#Lj3!2VNFKKdA~GZfspl;ieS z?0z?oEBZVpnEXHpyc*q@M1!D%g5c8sty16)Gtg) zeBH1{PR{ZDd*uYkv3lPnW@94{mQj4%+J9zdCP~X6s~EA#p9=ZiR_`NIiemoOPxfv? zildcgtlYEoijO5Sk9N!yaz(;mIuKw_MF&m&sHBtpo0#1Gbe&& z#hY*Llinh}*X8$F86VdzXy#WPR%s4VXUbnF2W z-iBWG+_N#-PyaHS$AA~Y+1)<%^A5#mD%|yOeLZ(OG{==4N|pv%2*-21A2k`<7WI8~ zxpZ&G-^E5f1Tn@|C%!)OFPkn$K_HwYthqQ`vB5!hw+_1yM%1;@SV{G5qP0z$*CbBnrV znK#A#Goeok%o9W%4(*nU#*>Aae0_ZO&`%}xgMNp|vqO6cg`_5Jr#YHOqI}^VcP&6q zF1xY^jt@p?u1NZux9Rd&v5Jsc;5H$kY`jtivvGVFc*>d$RH{Ri>}4Kw3V z_OT0xZlu41!|yJDZV@m2{qp=Ffl()eNS`SV!`vSu;demz8y=v(3Vo8z-#n&f?1nps z!oVh}mn2R9l!QZDWTdxqSn8S`_L!Ha>cmap#y7l+BWF#0n^WMym_6euY~XhDMzOG0 z`l!B5R=Y}!dU1_RG#R}rTc}yK;Dvi!X$F$^KumY{Uo^EY6AXcC6eRtINS<@?m(Oj@ ziH~M=j6I*6m=LG#BM_YveDym2FZcy$5D+%TGjQU8slUm8s?rY*-&B4kY$ysRvbu|vg)F{7?E;gh=|JaoqD|f`m$ATkDJ)G>yBc0Zw_+Zv+sN#=s_@?VT0$Jl+ zBAL@NMt{=UKW(S^iKfeBLwplYb#rAOz&FPx-A{EI6*B+vPy_z6Lju%H zhemj{*OJn!9&gloyX*jUy4CTgb=H{T11Try5R`1I5?tFss0%J=%P#8`xJIlTkk)>|3b zGxYiN|EcRO!=n1$@8MzSkdp3{2I&+KL{dshI#fzvkPcx$x3BouD*XRV-Rv?cVsFN7u0KT0JpH&{r+>YPFu!3J^ZJGxRf?}T;%fVV*O$~ zw^f_ZNpiLSj=)IpGU7dAAVoPD_7r2pZrR8ufL3%3t#=}Qy-kpa=<-FY%)7YoyWv_K zT3LEiPY)|}83G16Lww$0T(;LNduP$q-Jg{0{WQ`mc+BvOA!IOv$QvoJt{12tGWpeW zL7;8@r_)5J^2e(AmfEa0mP@mrTGmsVjy?;^a>)30>q-09rwUk9^bFk`m&r@j`p2bv zx8M`O;~apB;Inm-#lK2Vhsl6Ef)FvryvTk?U}5j&=rDgwz&}^~tS#Wp0R_fa6`y9v zG3hA|fj`&Xn3p42_S7JZn_AUs!LnCsITwO}BlA(IPOKSPYqt*9hg1H?-yo0j$o9$aG_h6CSxDotW ziMbG~&-82Se{oGAV!6<&L&NPr`7ZNzFKKs%R#TtLC=|6be@ZelYSe&Bf9>4WxI zm{M_+mB1a1bA=*SMeGewxQil~LPQlXK9bFu^$FdUOkNSB5*s07pO)0q%BrSF- zt37dwX+~W$c}K2fT;dP<4wb}r0Iu;vi>&W|&8-|)Bxa*Ru(ohk1eqq)9y`Tn zpR2yh;u{R<{176|H`d7Fe%M_Zt`KZ;-jyb|Prk~BJwvYLK19`jhsc>mg;WfO(%m|a zPBO2f_)1`VX$?aG|6xQVjGTe)oBXg)T?Xg{C zu3XqFYT1J3g0@RN6CN?pIkS3o=x5^7zTibtlP8m1xUD$WX!?(-|q_cM_1oF@ef@pK$0`gyXM3tl7vdA2+4#L>X zgeQCN)0r_qQy5U^y6a8+Qflr`H$*_`$(ce(aV&II)J`$wHO7oj00}DP@|@21b@t0yh*YHZyJq@iwh%;NXm@j zmKXT$xK~LyOQl|YTwAMl;_s-`FHL=2fr!(>x1vQCulR0*NDjyU3o85mC(k7^AVr}z zxXzi3HoL-QrP$(4F7D?a#GF1Kx!vG=y)fY@LA&hH7GqA^1a(^fN03QN+t&pgd(lj6 z(~Fzixs=fl2iCkCB8w6FJs>&P3tc*a^5 zaRq`Rs)B%?2_&~sW6wa3VN?@M)S_|+p~X1Ckn1jG=kwv=;ePu?{8UYf&WI4)3MU)M zRI8HYKhG>ceWWMbK}-3;jqh&fI}EBY9b9vQj6)?&Dkd^&X~K{=8fN(4Y30)(Y094r z7FWQ$0kG3%r2WCkcTdMLz_@GPUokI9ts@&ucB$Bql%PnDBWL=y=Rk;F z!&xRLTD5g!O%O#(jnMIH3U_bv{*A5JiD46${o#J5>YGg!8prI4dv&8nu8KjPhtl-I zQWYVpa&mH*Q^qWVZhQ>%LQKz(h>8&bEh4V*L#wJ^iRm$3rg!B}1jVRF5(Hmf5z@$N-2b(NvlzZa$UzO5kA zadJ?YYTCHj8mr3y$und-SxUzV2;prqHqGztnjfRjze^dg%lt5cFh3xcc2;1k-?Q!! zcKkx;1@2OaT$u5bx{9 zW;y;Z&qZ^SuEl;3(i?Pe{v9YtSr?X1OGcK4j^!VPvoBDP*RfUp-&*4V`?5_hxOrp& zHtSbATucHIp;u~_V-zJd8ZcN@FrmV;b99gQ*%deg_Zep?%6Yx$9K7B-c-((gQkij5 zL)c;HZB$c`KvKu}mENK2YDeo4Hcm!=Z`HlOf_iFaQO?Dlk7)xn5qYV;wgaeYU7k}u zfMQy?PdL)+TweHpIK2|Mq|xy`SO~fhojM5BB5)Mysu*HatU#40z`jo&SI_s%Sf!`J zRNnkP`}R6!f`c1d!tt6ECVXa}Y697fgCczw(%W*lSyDqQ;my>)p3_PIwwKS2FcsXEqPV%hAOnsS2qq2yMl z{qNi_c`WT=!p&BFoOsi4Km&-~R~=XS7t=_Sz(1{QGq!WRr}>^fcdXl4l*}#d_J}eS zp!z6kd7AU^kqyXV&!|%mBmZTwHh9ydh|u|6d;3o(XLetl8B*HKa%CL(rMRT7e>jUS zh+4`J7zHBvy>^e%@A6Mf?UUY_7vBqh;C+xY6YICyPcBO6Y`Ng$)Z!U!J9~Ie#xRh( zd+?lIChM)CwqVzgS%-1sM$D{vKgg8_H2Nj}?GjaYF<;@LyiIYu3Lc+b#p^stKOeaQQ6v0FmAJMNd2-&64MWA8FQj!O%}pdJh2FbpjV zy|-r9yPle8f}QL&C3n2l;ywcZoo%Np<-K^xMOPXW$>6e?w^OPC|L5iU;wz~0sYr$p z#lLylkw-Iuic1;E;AXGCJ-lydUO%k(#>X8)Kx+M`O*kRFuA$oDm0;H0p8HH_G3%Lv zhbZx^@S=H%+=nFl%_~aV#w;y|2_|#1s^RL*Z{Hns)%(oI5fQu`xA@te_JHWyYHnB2 z#ej{NcMsi2(z4SX8JL*GSO2YGzg=U2U0$Kd5nt~J-n&FIFR0Se25RWcBo*GDKKQ6; zKGxmoV>_JrDd(MhPZekUz`_%98S&WljKc#PzG?z5n0Z@(*~hV>l>FrqFV>$#9m4UB zRu(wEG8VC3iKKY3u>%Hw^)OJcJk|>4|Gg?eg;|f`Jd@kjLJvP^*R}wZ!;jV75Pqo_ zEi)1DZWFYPRKb;AMGNYql^Ib5?Ad#JzCV&a;cuQi9p0|@E+-|bS*_ETsZCo?JiP1- zC*omZYazzLeI)ZLZBeDe@cf3<7Y9S;Z5(zd!vo(5i1ZF??mKaj(P|qDAAb730~xFv z1VRO>X)zun*>V=w=F%mp^THZxI5xBs5#oFYVfYLVgRaDnd^$0R@QX?xdtaU}$N%8N z)xZ#E5GzYrwrY0YlaN&qZhNVcf<5Day*^&P%tzKDG%$^*ZF1TjQ9%w(zSOwj`3FaT zO59F7SRqO60Wq;r<*#ej#T$6)34!2M=KeQtHM+ z9?Y!)Tbp`^EPe`vA0-sXE32(%TV6+sD-yH3$1ya0`q*&DC~!0B5DT}1@v{8_$FD_P z6r_`QC>)0njoq2b)7@XCr3E;-7~;XF43yU zAqv|k7nw|C-xeAd%z~-xcnOaZ+rIx5V2|ncEN~d$wp3r}(dJSNo>4k-U)bO!(WXje zL)u4L$p+Ih#}ap`_rBloB>C`rJ@_!sV=m496(6l)Wy@ui;Ddx>+UGLRHIZv z{qsBMMHlL$V-+{!BloN#Dwr!LtZ`CuEy9@HR=(v<&W*9>`ziPG$RJ2m!U?GJE{d_m zp;R9QD_lW_;=(xUIV7Z~L6y(b=U9njGsAvF@W#Qb+hO^;d|Ji5&Tb6pu;LS|xr62L zoXIa*E;~~|se4JIj-MxAOU8tFGhgac+por)^L_9HY)V5M?WxG2iPinAtgIZ?Zv5Fz z8dr35ML2jJ_8)r1Y0`Naksf_EtYlc5Q{$foxMee5%@*1+AQ2qOY0$QYKT2=KX{V07 z7v`XnUAf?|pl7wKZmBolDb5biMSc?^D0c9A?vSHOmDBn78w*^prC%``H^TkYh*98a z@!cM=pA1u_hvtSAfvlX>be%OHE>*-6w#TXRVhK>(h81O~2MU!8me1l&1W{@@FWWW| zf|=@P@!EY|`1_6Z330T6#X%Vquf@bFHeT&jg|%^lj_!2K&9|JEj{v2d{(u6IyWa(5 z)qkNQ4p-GEC}hA4`KfS#8Si7++lqUX}? zke`fD?x1LS75Iu-p}SC{`Tllgn*kxqWl4%nn`Wj&?$+9cXqW@F?+e*-Id_zV=V{+G zV#5f)_69$)c?>Jg{a5lQ>ft8ID@lWS@~B&}xG-=8v@WvnPpxMMl@>n@J?~8nvi-yY zL*$+UHRY1qM{30Y_Z9DO?zW7(%ni*k>`;1Dmk$o{QM}gPn zv%IGCacsrCDS~nRiHrPDoy|uyw3KE~6c{|LrzZ`PfF0&w@^9hx+Z(LmqJ%}i4>)`_ zlZxaM`iO9jKIjl0rD9oiC3lbTHm45k?Mg6vj}<|aW?<4 zmHzLyu>w)QSA`#iF;vOY^SMC0|GmgRUc3=b}%va>C|hMXs{r?YjrW?b@q zUA~CgC^$=Pv!kUybboPsnVkPF^M3^Id@4muZ?XBfXNL}a8v-Ji4;K?tj-`TsA09&K zstic#k8Oj%G4}w<_V2>t;tk}$Da2{WF^vr*AjrSu3s`BfwBr2PQXUS{fXNl=xYbgR zjD-BZN7>riPI2phj&U5zQ`$P;39seDGs=JhBGo4V5EeIp6|ccWl{tAXwaMLTBCuUC zo!edJ7JfvpJJi|>KaW}0$#A{_KBU0Wiq89t5Onvm>=xfDeV=)RfyjjsPb)tB@E5)P zkB=$Ckx^F4YeiDNwZum7_I}sZ%(B$QtqbROE>44;|29ectKybnclp zrzcRVSs4tq!k=9Du8_S53^c4h7&4yo%|qv;?KH<5((b*%a*Ik&S>Nefp00P7o$)ze zkWQNd&#j=4^Ar$<2JokIx+RHOiPp8t-5K1uXS0z=2wy zB8M1kCDv^4(4A%cA`CMQ+?^S)`rftqSP2PeuAQ)600Bz0Q!kq3S@lxGwn~Z^{V8^N$McarDk&H8sFYHS zwb{BYzp^Yr61UTvsC6wyn@mRz4bWiUAzbu3cKesQ!&1z>njb#diT9@~RrPO0X}2;| z&`iK-zUb&bTcs4D4}?AX_S*w;mPq(}z|roY0NeB(JNTJJL!ojWyqnyp!FjgSBH+)9 zQ-J8p)b@9~)*uGOEUc(t%Y8pvI#xhH-g0-@lPEW=%xa>0U#thZ5gflt-@1>w$~mV} z1NTv&^_?qkbM@ZF67k#$1zrYAph2JHXibztiz-s>BqJ})0+Pg`6?77WW;fc78T9on zSs6JHz+(*?5oAxEjM^s%a8EkD+K_2??1yLBjm^@7CgrYg{CuN%%5sATp6Ig(lIY3h zchJxuSNrC5RKor!{hyQ0=I8ajf!Q3dDqYjey>C_o#rV^MK+`W0h@TT=-3(Ues%8GE zv$v4u-d79YS$pRPU{kgLH?*ZlR-MnfqJ#935cDGcu3g$GnB{jG?;+E?%(h?Rl{QA< zJ?Tx?R7u76uVukjG%0NF5ej50#V-a@%L_|O9X%PgxK+tiRPcZ)o7>u8Ge}^b(GU}l z3Jf-jG2I@5E_x{T@fGb~9x>L%ho)udBpY7DeX|x)Pvu>%ZrC&2AU;1I>wRFc>%QiNX;B=RFPJfGtL{CJj-7(3!ff`~HV|-K>UszyIes4i zzB_38xjiuH5t^SKTsh!i9uU?0*+A_v1b8gkk&n`6ZOz}^xtOJ#{m}GkdQ}@H(ltIV z_xR0!5Opm2An9{d(DZy7h@3yu;#OygLkylDn2vI>z*vn0lO=tQ9|G;65|XNOrV==) zQ~|$%3+%yg<$Ugc%43xjn*aO|yxsru1Lf~yJm-)SBzo~g5vG(`2w%tCak19H&Y0rL z-xfA=*}yPlBDxM}&;e$ZXrOhz^c2ULccjYkV({6mk?gIvYQF%39F!V#44V+Sh_)5S z(|5S<%O1=lEKW*`E8FnqkErQ3fAh_p(dKR0jt5Nk45>GU7mfSDYNpn08R1)}QW8&> zw}6t02pc;*N;Qe?Q~JFpA0D0U%?_lEiXt`QL17{@ToU4shn8qfeRgCghM;#6N19Cnc z2U0$|i>l|#2+utR`cJ-RQDj&pzQCzchQ?4(KILmKXp>PImhnjxdG;D8@P{F9F_i9{ zBJe$cZSaq{)Ta3K12lxaWgl_z*DKK8U-jZJ^S**$veb(KD*|VI0AiE8@%-`wyb1yJ{5oJDxL>=j?y~&`f%5WKXx{G zY)|-#zxzv>pz=WTNJB~1@Ius?rYd$UN~yl*$v#2}6SaYmWK$0VX1002U~j_t$Jpq1 z4$u#*`16XY%~O2*<=}JJ?~b>W^fka;(*2aC5QWhH-plGS^P5|w)C;8%^lQf|i_^4; zcdNn8;AFHlKVKO;-b(upii+Ze+$_hS!q<@~+KWD7*ZkoJgRWrIlAycoYG3_z1k|$} z-WmW5zYDsL7CPX+fP!UWZw$~rx!So3ID~`-e_yW+M)E$ZWjFqNqCzKLV;k12_OxYQ z-vLrT4HaiVQ#gxi7Tz?lZ&t%qHKjb;IaI`S&|-X`jsJK5?`6Cy%tXYK6DY}Z6+W6u zum8_-QM>YuVGVK@G(%4lOOP*5?mgZT*}U&qf}QoihhT*3c)_4jfhs&U!Jy*h13mlS zMRl>_JnVz5#p==Y zd%D#(az^koNTOiWf@su2w$}@E;(Qa5ej}<^C%s$*_EXyAHW4)rPnB<*k8KQgks_6I zVWQ3#ZVSIxslz^QOA|L61XOM<7}qfel_s$0bJy_?yS-*QqPQNhT9&BDeDHSI{Oi_b z@7aE?--$p>n9oW7uRm)TuBgEq;oG}H`Gs51h6!HS>qxB*wnK=obe z+XnrmSPYb9LKm}rva_aTBXA1*BoyLNp}dS0QNmVHXA`y269zitbImqo&TopN@i;;A zd}uKdBaN6?x`P&yk6W182RP9qCvRIr>!_ozZ}1S^UwcUEiA_NE)EQ-P>^I5RJEXoo zmKTnlSxROYXZ2iM7zgy`IdHLof?4dAvy9cyqw{=v%YTYZCc}UI)n9B!%3SW|w_w8l z&bR%bY5kUT+a=n!e|x3WTlRDHXY|LfZg-w&B*{D#)FA>=)IkjJ621@6H3mplnF*Rt zpYhq1%06k%t(Y~#9aKJ>9EG=sH{Bk-_a||VUH&#<72CY6hqTmgsZ@_!N7vb7)>d^m z$XdH!jo(%b*~t_DAl)_qbZpbQvTqs$93TC&0A!RJa$J1i4km#;eTK(K{BM3VFx3<_ zs{hjP{~HJB_VoJxg%tu}?7aO(Ko;Ys8T6Lweff?b)FjshwE$@}Y5;@0_2O&BD1o%| zp%MPdQw&(ye_omG^m;W#DVyw*23geu%$<|Yq0^TNzPz_MgZv5@qEba7P+;vC19rDL z%bYqBoNM|$IG3kbt`MCL)92ft=nMXjFp_DRq3L|`mesavR~ z&n_ZT`}}C7Z~lSL5nHi`M)+?9vZ@&9=FQaHd-zYIYu77nYVM*uQZD;KGM2(eD#2h`VGy`_r_AL}O`Bn*`E`+)(~QQ7bWlbX2^SMM_KFi6JK5;A zE{9D>m(F4rogJ<#99sdE_SzGnrlyvz`SOL30-aYgI{3vm1@baH_km2Z%@(NAe7+?x8}=_zj7WcKR7c}Vc!kHti*WU=H7GaM^4yuO z_Wk1Yd6EaSLx)LP`Z5D(q~`Cz@Rj+@SZ}WoaR-x>0tF31z5#X9UP@|eDh;i!BZV$g zJy|-?h}MHALPUY+p8RSj_HXW5$W)AA+v9};6P`c-E43UW{2K#2BjQIv;KUi#HocnU zh|R+UDEM(#JQNrI_D!1|1=MhUaxq^3!{eb^Z}RCDpBic@_l?IvCWl)UV_*~s&`=#F zo%ZraKo}jcHQ)A^B$Pz?OfBeL4~TV{BFTvn z?1yWPo43O(1V2Hb#GV-Ak;Q_)=8fsJg5NS>MyaC(nUEz1TpjifHOvP%p1T45tAX_u z3NeQA-7a4%Ofwe(X&%1h7BJ4RzPY({c?yUr&cQO689nlKvVO}eP?=1=49e2 zNjV3_squor!TKXFwc9bBhJq1tmJn7w$&?raj*SDg4nO+iAhqtBa!K1h`-}X71^%_D3q3_zlyI-W4y_}-c5a#`WWXtJ3!>8mI zIh*sV{D|!+x0?KP=iHxh&jZMi#XPnq1Oe_c;+Ew+4mSbvD-AFSch1Iv2+z`Cs=|qa z*T|A{YuJ1owO=;dHl^cDcD$>*kXreu3G6#yl|046LFHA^%MW@?nc2cQO@raXKzz!Z zgT^m^mx2Sbo}frr9q97&OQEW|x-bxnH!%xx8!$i!&bHnX$=Y!nl-XUJY}@iTt|ZBn zyCSKtzaDhpzx?^-1;q@6`U2QoMPO3Pb7cn1`>fOB%f-taMf_RM4kVcTg3pgYD$EFv z$k>1y-U+UULK;!J24#89*i%^7JN61sgL(Wl z&>Ep1?`otNNy(QD40&tKYe2j}z8Sn)Z#MVIjcRnIJw`d8K4WfpB;7n{LK`2{fm z3ii5V{PiY~?wec_Np0jL9RHRTBSgWK;BK4ag_BQi`gtnT$$1Q>CC&VH>rN>wv*v#i z?VIoOOd*hbcz@AK)c@_5WMH8xJv7C3Mp9Jh!gJM9xGC(+{STG!Y1Xs+D(rzuoc^N( zH!^(xRx6ADz-R%I&`BsgXgp(Q;eQzF^LtF0FS)Rw0OO-%Rd}ca;F+-o$VWTre1C6P zIX7+I!)Gzd>ev)#W$iQ`L&*dYQZ9%6AVf&*A(nS!AZ$4#Q`StxRm(cg1Os%3)-iq^ zxEw3P@4p67m$_72U+%Y2oK{UrQXUV!7k&aB!kxgd@mC<=u1(v-i%yxk#fFN&?|h7t zT%%e>HN(jcJr+%|{l_SsQI^NQ@%MY4$FRoBj3Yd%ZosphzPi}1te3-f-t#)`-Sr@2 z=&WiYLxi%w<4^jxmB!pI`&XC?Yvxx*vyWqGUX+^~4Q9PLeddUH92_$h8^tr!I&D^# z=@o^TK9X91h#Uy@EQNdE@-SRO9wA=df*jj7tXKk-0UyaDeVQdiCKa-O$FmbelUgb) zOJ885L-Z(1_H)7xt4|x(etdfaR$YZD;rr)q{hP1&}e33qomuN$xc`W z`XuTGGsE^iY#A0z`)ulct`pX!#Hk4so?=tUP(Q>5bxGM>E!6)03 z<>jSEXY+v#&Z-dh%3GlZz9Z;aXvm4+p)h2f6fW~x{2l#^Xn@+)2!#AEog|8 zRa!adHuAuB>MboTeEVljv4^eS*##V(FrwpKdSDu~;YxIz{NK)Rq#!>Bx+SUxf+MeRUPEZ-7X+ISqybCj?NaLwcGyR%rT1aAu)nz4m zye8tN{WfEI`-W|pkf}>8RDVpA@IJ)4>td`*11;2_K~1=FE`aHHEvr+1>y#a}-EzDF zSG_+pOCu?|{Xv?Xz#r;h5qMqq;7#<+U{LGHUR`uhbjNbKEx5HM1Jh;I+h~ec3`ds3 zF37i>mon_=$PUC7aCnl{=hPw6e4?VFXF|GemWz1cn+}@XMs4kTFS0!{FGSWVNbSf1+ClXr`$v&7R|r?eus;AWT8h#eM|Pv{T`X6G%;Nms}7IA)!?AUFLI=O zg>cSW8EYSMPolc=mWd$oEw3;KJxnGKY&m&!4&uI%#}|Z5QDig)GY5tYIA=O|9MWw( z>Pn=RY3E|7n^_OSDu{gBk71KlxEeIERt32WmRLP|g-Tl#I=w-o+3tL{ z|50D-!nai+M--y^y^PP7-49=HGnT~$;3eER^)x8R6edD?=N%_id3rW&ns4DsB-rS00DdJF+JAnyyz9Ysx9BUUAKLQ$96SW zw7Go!(<6(GEVf|G!c98Qb)mD>3DxBEgP^GgwTVK7KsS8R#7FNv83e~N;XKCbTnJNJgI=MCDglVB}tt(*@_Px z#`&~6ovjQr1cJYS$wQ{y8%=|Q{s9jC%wX!fSvX0qCI_dr#HNGDwIuXmuOVa8MBUoo zM8Aj$=v&jWHnYUih76|5srm;oS>k)~$SZMu2906!6`dKiX?3$8t@8{((qb-Y$z8jf z?30<5hQuE~Akp7#8clQs zU2P5~#`rKSgVFFhAxh-?lcuH9n{Y-PXp6!#R65ZC{>pvjHN37wf;5jW7Kk3uZf0{v z<;XSvPA+a981g!KuvCL@m!XM!F*^2s=$XqSKbA+g91u;zCoGZOZ#jPT0&|LSgy_YP z!sc5-IL8!v6`S_jPsr;}pFs&OoxvuVbPpE&h|i4YcKew=!)tMgX|$Zz%2%;Hpk!wT za~zu(oPkcM9+DyUtTYNe%BnN$=c7iW89O5>?}x`r>!HH~wAyZ%V`z}2#;Qz+rP2Ec z54S^S`EMXg+Eu5rTnr5WS=q0zX!yKBa7v#UI)v4ej@RpDf(UCguC>QkR01%|gvax6 z25ds_cAFuo?XsFO@{xT!3<_#=LqUprNMfYbgRV9!<|dH)I)$PyEdDUGxYioCG@QZH zZV&E$V<-Q>U=0%?2qx)(q)oY#Z_pbeSlG5fJFD_Mx+poK;|Oa9S~Fo@4xo>3*!Scb zc#qKoMl+2oKs8_c=U|l7(mL>*fe9;a49iP6r>hkrF;!J;ggZ7cdp4%b_>8H03CjqY zXoMW?`~{a*^FiyA!LE=iYp|oxV4QrC$uy~TipIlO6)Vl??P&uIOcV(+VRP6tzTMqG zJzoY5h^D<>6zX28m)3=W(8X)uj)4Jr+*0s~RtoS2t!vS%xZ(_x{HCTx)ewkjq7kZP zA&mBJX)OL@ukH~pt5Cm`*BWH(#b^&={>*yKKdV~yyD4}@aq_Twd@M61no{B#A~*L% z*R)dtrQWHaLT6G%`fQlK(Xt)7J?F8#D2t6rH+j$`(`t<{5&*(-O9bZ(w-9*MYQ$?ZGqhzs=<%7sO zMQE_vLmN~k#_MkL3xMxXVYUc56Ha3_65`V=uVIQCdfnye4Z*!zR`@ne1{()v?*vM2 z1qx?wTUGoQuF)7MBXl@Cny{2X`zY?gEl6WDFATtY-DV^#1xWzGRz^My6k*Wd9Bh{VV<^g-7r z#~hdHG0c$2?pPyHS?tqkn=EwR%Hi?Qf$`b!QnCi_Jxf&D;Cl(#zx&-fjW+O4Hn)!Z8UoB1)^@@(|VBNK|37Tnn;^u>bNkh#b_wJ-o zCm`45apd8@QhOvIL=_U^6$8}RmQ6+vDo%<~>2iTz%^Dmb_~A5kWQ`Icl?KC31AQ7( z=~~~5o}4uid9(C5f}Y(*DQiJq04%z4@XyYiXHv-tR8`6DVV7N1+n~b9$*Ax>B--hP zT-{c>I4=o9gf$%;K6^+nDRh;qb-szLBNi8Mb=}E8_pkLhLp$Dc=RR}&hK5fKzTVe! zB^jgJ>g&-gH+Pe+eE&^V)I*KM*N< zMn{Fb{x*<8DKJUL`#5op7vGC82A31f8A09}yMNA`v{KXFgNgAB|N7Akr5n;=(|R`e zM5~2yi1BYXqU_EtOJ6ZXg{LWY$nsWC`KIot14({Zz_jwsbNVi>Bk5xW!?wBhJ+~2@ z%crBFA>$lL9${|f)~F60)v5m;)dYD21>z6K-qN6o4R9t9cC>0Yi|8(6QuWK{kHJcS zGJyQmm+l|Lr^|GYjFTT`Q;ku$yw;iWEm9d3b@MJmkU8oeGp0XChJUO4cTx>b?aT#= zyZDoA1@dTQ#0YYEk=cLgZ~|1R5~S=KqO(&ENZooCu_!GNmFw?tmhn-fR+M#E|8htu zX9B@O&mx+p?CYc-*$F?ILsw*3`634XQf!_kLEq}J%oViU$Wmq3GV3YlG|5}_9G~r$ zkMw(CTsKRVWHuFEpz&{6Vq=?HESgh(5<3iNMe@ygX& z=)HBwYGF+O~J}h z(X~EmPkf#x<7E!Zzu{a?q(DEr*XLm$gA3E?%DM?Y=`?~+H*S_J$X5s*jU7@;PS~;i zF62gIFI15w_?BoG52AlxOVE>}11rof7S-Vg`yOoH?uZ3IukYeGazPuao{ua2@5Ll` z!X%|fK{y?vlI-WnYl}Za47j#zmKX~C$qj`1of0|gfr5bI0M5Y_fzfD`d&RFu+Mz2= zKFyr{3^*mcYP-HTsTo!3MpqL~ESYL2BF8fIz)*7&WMJ>8fu|#NfDz`O?b03pT_a@2@k@lI$Xac}I>8;4v!}0O) zG9@A}ek7)8o!wZ6aRfiiS)MbRrNaG-#y0V?N_&w#8}ak{qy|N z%X*nAgBy>H#B*v)x#aNL!}RWTb|R8*%*$x|-9HE@^7hS}^G)e$wxV|HUTm#U$99&d zz~zGS#3)DyrV2NfmO)lY$+~LCG9?`&a7_XwJ#A9Zdk)8eQ@#b1_{vR-!v=oi8~M$E9Q!f4t65bJsrLOCRY z>8zBW@0)l#6qO(a?gZY2wJm+9GlHEfM)PRia$&N`!?6aaAD-qaV0NA$o~H4cyo?@e z<|aZ|Msl%=m4Q;qlMAi)?h9*VeJI)GySLZim^ zbCyP9hja1p3}h{>teOLp3lnb!eELzvLvQO1n4?q)Kmdk6HUSF^zZ|%PNZCt->G3u; zjI|tRQp$P@qGjm{Y%)&gZu4LXDO5Gt8}JeE>o}kR>)@((0$wY1+aS%W$lvfQISgtC z_7+Bt&jD*-bB-(U;S(+@>ap_4e_LCq9vJPN0g}mk)-w_saPt1b9T1Z)t$<0AVz53LTn5 zR|F3*w{YU~s0I3`m0$7Ar=St7E}W(1&H__d+})zVplLD9blL0Q-^K35_nadl(c~wG zt{UTv8buu^G3Xf$1!4W|chlv|825I|2A1?Qn?0v+W8N!DUgTVh7+Lz`5O=} zj;2%${|gw& z3v1xZV4UqW=kp?8HXX!M*8(IkQSky(yjqvYs$2x7&2Cvl|KGIb@r(jyksk1f*oiUv zPrx19Z1)q=Nx=LJ3=Ft^L4ei!Z@vaOiE%JAKN;6;1%r|387gqSyjL8l5@c-vu^Sj3 zp8E=Ry(Z9Be4)8uFi4xT_+R`E#BB1~Hy7sMu(dKaHdcF!bw_P2FuVeUt70T@MLNA5 z)krevRR)~vz%1SiSM`?G$*6w^J< R0ton{s-*d-Lcucl{{yUICl~+# literal 0 HcmV?d00001 diff --git a/versioned_docs/version-0.45/develop/advanced-concepts/baseapp_state_types.png b/versioned_docs/version-0.45/develop/advanced-concepts/baseapp_state_types.png new file mode 100644 index 0000000000000000000000000000000000000000..a7f91a6093e0099f409101276833e80bdc223f78 GIT binary patch literal 133747 zcmeFZXH-<(vNoy+(ue{L2qLi?BuG*~auS;)IZ8&d>Zy9F2vL-mymjO5jVo8K+>(|; zDPOsA4FUdTz^;Sen0*@!ymE!+iZtr6s+-<=3QoP+;OQkb86gK9huP6xPSn!%M5NMj zEP+=hmjZ{nso2xIOeUeI_o_>ZWO2tbL5xOkP=p_UT<+^NUDnP_+4nY_PCE7ppC+Gb z7RSeL)_81H4xehCPA-?HniW5FH(MZP^gK{FtYRi4w&$6n%aT z)w$A29r;-02PT~0D)eF$!OX5~`c5bIEvjKi1y10*k0TZE0u}rU2E9b_U{V1KS8DT! zufl_GT@8sIO%S^U|NBJ+Oz@?+%AsfAODGIN#9g9)o*aD*yyJUSbYC1i^NA>ujyqfN z33xtueIo*6>>69|tATeh1QCBm0<#Fd3Vwg*&SN=n-AQ&;T+AUz?{?UqIlM6gqb-h| ztk!`Up@Q50PV5zI;ngdY6kdA%Q}Fmvf@oMs1k(?KKa29+MTsJ_1U0q2ZeN8<(Gh3` zaJe7LC7sVJAQ>@`(XTNh#|;ELR*y1`CLFw)+J?C-G?-ukUNdxJPp>|!0?Q`8>H8g- zwK|&1UF+QCw^GfI#8?aw?K+j1h~4WAwvOLFC)6JNWbl!O;J_;m#)PFag~UKAJ^=E# z(f(#N7?wp(FwFGr_LGokotS40V}Eb^dfiJ%1rtT14@ora;}3aw=POZ-97g~99JOjl zI$F~=Pln7c_kYyGkSO|^KKpw`QQ7-(u>VP zfgo_feV(On#+fk42w-c(CW_(`RZjzq0~B~V!bL|9<&boyK`M?w`pA1Ua6%>tMWB$7pw|!S;zC3EJ<>Br3K08_S zso2a~TGpx)t{Q8<%`7pni?5exGLq&~w4vBgd+Ys0tlDISGTnY&Y}q|9(fboxts-C< zg86er$rnc&r`9XV0_9$k6VLr`g?cd(k!RX&7-5g(8db{kmRj9S&*A;E9)eqUfNt!{ z0u2lrzO-C?T367Y>!Q53SFm%>+PX*IXKcpj(z;k7$-49w%><5~1HRuS1ta-4zNLcw`m}C|cZdp!wo86mySkZQT%k|Gj@COAQp|v9 zmb+K#y03m6E?M+huej7v9mw22<@&2x1F!OAfM{<-LZX#h6_=Xlw%%CS>t(l?#n<;T zp21iPLh^@ru)}@^LdR^yTk$>xr$}d{*6x&g{s$ z=8vKTdQ+q%nLfHsaURV5*N(c-_Tn%;8vn4tIr#$fec%^{K@ok@X{@f_`yQ?ZSBl*bJ}k%3rZ^ zJ%@}6CuBUdX2PP4?sAv4TeCehWx3R<{FdrrTp{Ok_ONa**Q{VwUSPuL+Ga(^X6;}t zKE*mkxa4N_RLHe~?01*DVU>KlcBif#@-E*?D|NZ%-!dtT3l-OID(7#$m>HgSJ7Kc) zS=&I{Olgt#*Tts{uOjOfvb94^6>FA1Oq`51*mk3rJHktMo?uUu#GBPrGG&G9+P9k@ zY%Hf~$H|P3A@*0t8b*GXi99PPL9q9h%*3BtP_7NxJ4sV#dR?n?E~S;X`ALy_i)Zpd z&;o9iv_VRS4m=u$BbmD8*G2xwX>0rIa#abt$k}JAjhVh8iiZQ-xf=a8=0gJwmW8&} z{i~O!R%Xpo!WCnFxRZY6y z?oST!su~i%hE+{2w3s~ELf6W@53)=ziiP#xfjon6G%#mkexbV@sLr<$3RT6ziKkH( zuH%mE zH%wK(NH1_)Pl7faD|XpWluOnabx!jN-89+g_%!C2{28I_;5^vw@`EX7d`!1?9ABTc z1kc%0d+U_iNvs9;Mp0#JR8&T?HQ(Q_22HF%P*xy8#MR{!Y(Wz*$JzB7Mg zs_yB}R<;z`d;Azc?S5%hc*}(b1km;g`1J6Z)ey@}FB_4kY)*?P(=gE%*R_+-ie30r z*ncTAIk;dhU(Z(%F2$nuF}7{uo${h4nA+Yd(I*n)`VHi))uq=^C>D6bW)D~Sen|Kc z>_xTuYF^1!5^&<709w4H2j1w(T8FF)CcAfkhLV^A{W!D-}a6o1@iWXScc(eL8 z__Zp&sd!aES)sGgid)_4w9=aRqaZ!|#M9&NC;NrVO-bWI<$C2k_n)~$ebAqDJT93f zM8Ko!fRAnKxt}Kw9L>vsPHlEUTU+7N@SbGe=BZ9&(Kz%*C`zhN>9B5}Cd*h^s%vsB z-G8I&()-0sZ<5)Wuu=fca}C^W$^2zRM%p zQ;SU-FIh6Xxa7qZYqWm&z!#jq5E3T!WB+WY5iG8*KJ(p)=m)ksU*&>J7z}UY0`+F$C0_ zvxj>kC&l|O+(K`qUX*R1w;CVP=~w@?^T2iS?#g&;yil0(Y0|YD8e+Rg^mtclW@4k< zb*40_Bce)aMAuTMbyK5QnznE*~phFqm&5KyO79s#|FMqmAYB*xK? z0$)`V_zQceXk(x-;i^!hCg#Bc97;vAU(^e)aiZM(Z8L zO=aX-$!5S(e#OgG8M#o|qhX-a()Yl5Zma92xGs2>N34R$kwoP|YXCwXaeigG$X$GTz4rCqC_W9#not)659 zUF=B{84@<9t)2a-@Jb1UV zl8BX&k^NUQDI@a^E*Qq7OdO zkemqfeaYLbj!RRXUGr;6_{vNKW`*L zbR-XVZnP{;xJ|Tu6%R8u3T}L!L=3^=D`XmkBX^R(CTJ=cv79Yd~lqe5H|>`30IIHrxiIid7m@mx4xfm{nmZ z>;*WMGt1l`4Fh?i>Np?`ilx`kWdjmW1cz*QGP%p={0pmAaeWWB{DXpvHFi?x?c<5{ z)2L6gXZWTv{(+W0+9&1OuWA>$)drBWBd)(G_FrvOET?Yry{($g{-lS3mFKnUznl`6 zSHC!Zt(J@SSLPqc&~YJs?Hu~8sQq^;9XytbU77mXMQO{_n{qL zE1lnwj*SE{QXi+^VyH@8nfk{9* zvWr#Z%U_S~+8zdmiA+6lIFn9npygwjkvt8wN+JC0)xf8w}glqWU+hs<3A(B-a2v528Os1L{DEy zWpY!H(O02BgLd`!CEgH06CH3EZ192*qON)J>4llFS$K08-sIbCy7)g?b9W zx$6#K5Z+lyoE8Xi;82L8Dt(=YnK1UM z;M84#zp=|`qWmpF5J*OgzJNRYb}SwxmGOxvF<>Q{&9m{&K?bwy!sTM3Z*A_`dc; zQqGT_@jXs2yU8Z~-+HDNv%AhdP@t6M8G*a6j){8ih4Dcg#`(6ZsOjlhnJfr1xb1R2 z>f75x`Cxr2~xp8&e?*%MN)VQ>KvU z1hOpA_e5Z$)Lie0If(1+oBIC^9Laz0%Yx;2B7m#rl#vc->!!gPNCrAmRLlI|#-a(D z_n#pb;`P1lwXZ!Z(CFu$@!U&L3Mu0AIoo+%s8dt+lQ+OQG=sLmTaFNMIbZ6uqI}r; zPTR(u+`2-kNS08#VeuTq)gi_SxrE^134|cHPc+CNLCCygDSgMPJ)YMR($I(p|=kfqBDjTf+OM^ z_4~uxg|1uE2hG^jqu^iiKp{b<5NBdgh#K(zb5#bGx#wdeQ7%L|Xg@JE)z zqZ?H-HY0i-*8Pq}^}A2&E>700%X_%Xw;E52el;fCN>uELf#C!)Es87E$8R+prlz>B z=Azwp<}zGllel~CKC)2FYmcH77>+pXVyk2MeeOOZmU;i6<vX<6sfm&n`SgvGS=SzS#hxVawLG5TX>(516!)*Rb&_rd(&H_S3u{3`;~& zZBWRxubm&x=&vSj$X+)G5|88OsNvCt6Yig;_8i7?NlmA*qDNaI#-4vjo3O4*(Y0&F zl1EjU54PiMIrj2(H24T?RH*b<3vSi#O*Xy0MQ*w=URiEG-#*4%TtC-76~Qz8YnnA9 zMBBRZtxSU~H(LX&|McD07u>jiY(=}KD@epG@c7mfA$Y?Sg!bRaC31Y>OFQc>*ardY zPl}#gm7H;Wk+bL46KH37n#kpA_<}!8dyg|c2BaDImSe~yC?qg(nMBELsts6J66MSo zO8t3RUsHR#mBOR)iyOy7ZX~d4lzf&K*x=%MQnyxAS4*ZsL5_s+3fXxc&AzryvPPE< zDu_&pb8}C-%`1-dZ#nh}jeyHr&!`QrDEYMpT=^Uclc#uS6*y&nEe#0ItJn8Qdj08U z-R2?6>8uZSz5RM0IoFG58KuXb2;-x}+s||i6hzJ|h_HjPCbfYW~1 zWOMeNgaVbpO{(h@qwCo7Xc(*y+5E(Zz$sjAz~WB)WQQ3lErSKvbjAtd0%l$K9G~QV zquE}=ZzUmmtVrRLUs?3e*J*eYFlp|$xQ;}LT)c=9KKT?jm-2Ec(ME8f_hf&q?xBPh z=@x@|Sk}vjX!ye{t!c0%>5j!nfz3~cg*Wy5{+NY-pA5Yag3FG(IlIwM@a)T9qEHDT z3~AIIF~mp`l95kJt%Z)Cm6oEo%1_Qb7h)u9$ILgIHNTWDjaR?1;ui?abL4( z`W~iwY_23HUBl!3tm~IfYZ8*EhS@!$@3Voz#v_gtyku|}3kV>lM`7kF8x$GI!Cvm@ z$T-ab<#UZ;M!~FUcAL#uM(^?Of+RGV*bTUt(1kY=(f#Wr&5I6mr)~W~h9B|m@le|3 z!Cp72Ub6W>v4z(j!2tw;v%(q(HUcVEtqQvl#8Uz@lr3AsZ{?0~C-!!P7qy_9of77C z`~B0crU^>dN%%@M?i#W9_$N`5l~96qn>Sk?+%qzlUV&0eDNog?+RO0mRNtO)Uj1QjO=IZ0A(hrTi?s0LT>K)h81O*i1$72Jqu7faQmV&r zF)fl6jqS^|;-+L?@zLJ*kGcxwntkVm2U<14<^mtcz96?Y_8gF4U;kQ;?VL*82bcT3X@`G*jPpPwHX34VwTz(?FROee{ zMp-t;hZ8>dghO=iW366;gQJk8A>bxi{Z;^ zUVc$o7kkqr-$%WG`s1Y}8;S3iJ0{tuz+pMdv*6w1JQ4CZaO$NU`SQVda7=ogn#sD` z^Sb!;k)P`ix^A!|X@W5ZA{m7V#X{k|T=K%bPTxN$5F;Mj6D;ws8VP+3C*#za;yvP3 zDd?jS3g=={&gqO}7+4%c`x#A%LKO#XhaOufoR*OkfKEUWHFDwq@@?9kE81&6mYpEtL6&q-HjDP(hEZ%rNmeqH^(d2^U4~M{ER>%P97(1k6mLo;Z17gQoPC4fw;OIeULt1*C%_LT7!LS3+O*dzfCkg8aiQhbd>#ce zXlC~d7&B;NLSp1}3z!Grzhl<}Gj~3nAIwg&vFMhf<&Y{x ziajC5i+SP!@8tCq3~P)oR;UO#J7bgqe&-vviFUx7#nV)4_?&BpVIkp+$&Zd8?5atJ zu+vn-b@<2U0;`K%@pXs(A$O28;U<_|$Q1joBQpwMu{hvKvr8%8f+7ru>PFK zZp}3u5W*bG&=jL!3DR-RrADU7bFQ*TA%CoauSmqg5z)hDgbDr3vb>{+&#$q-T)}Lk zejk?@!&0XQkNi{Gg6}JO-bfayyTTB1`Ex7tc5v9wL`>mZUyFyN4*6GGVkC)Yr3hbc zi^UZBAM;q#@lY+NeW}TkLWq?z1g7+j?%*cPe|osqbvecgLws-Y@u~Vgl9u_(sKXs^ zd>z*)#O!iS|Iz{1>)Z@CvyX6sAimez zkK{NZCtiJMn6H2lk-^r?qXF>{2_y*tF>2-PkSZhbQYvEM9C=^*{cWt6E<-1j%XTsW zJ;|AeXy~&tdugF8f>p1sb-BMF{XZS=Pk_mqrV2P1JmOrUZJK8nvh++#HOmQd2m{OG z3Yxmp=YF(aV{68+9rh?0RC{}04cRQ7LP3*I`d&Ic;!*$q`COH=8>ZX~MYM$x} zwU=By`!AMvn1PlnGDYp$fY-?KHeNei35|9dS0dT+P~EyWe*wUt%M|SZX)?vEYkdyN zkxYg~a5?4od_rkg9}27WoovU)>8gdSR*1ARkjyJ00(2q@<0X^Wjedeg1tmU#z-~pa zQwAueEE+XY33wx(_FL~A)|cJA@IN-@n2cyO7Z&_k1WHv{ss8^pT6ziyy6a5QOCTt6 z7}EW3NyD~oWr!P;^5tRxk#hd#(}0E0`qiH6e*-U|CO|Z*jgK?>Ikw z;}(XJ3JG@d1zzMT5g1}lSVfbOTbV9Pk%g?-J0K-7;#vOCT{xo^NEQTI>+j2BqSD>K z^+R&RKkJl4W{KX+wIL=3(Z3%@4nH78qv^plm#@jGLrAn05nEbcJd7#L?Xy}6m{I{0p?{+={Xg=kH_Y%| z7zCuIa{#CTLtdk>Jnp`!BQ zouj2j)*vi(88e9ww6L-#?MdS4)2gzu<}~dtxpDh`f$NILR)d*Ynisk!O=QNa@%&(7 zqS}6by?Q>f9Ex3m@vwbO;Sg+Hzthf?5A)E?rexxR@2=#ejf1IJQSv)6lJo%BY?lA5 z7!4wuOxdEYA9#T-O(>}knyTkan9vqI7vBdIM|uUO!+o*#a55tl1HbF0&iDc8)N9z| z7c{(nNaMwCZ`JeFS=ahAU#Ec31MRY*m6%3Ytn zt4_SR0{El%#Qjh3g^U43+W_LZe2oBu;{S&^A&C%C zLI(*cuG24zQd)y0={Az;03e{Pvc4Lenh8{1d*OA5J<(J+hsiWUKv^v0s!KkvslO%g9b2 z5fTle$DV^}4_obew^FaOoer1JSFuMyuxvmn;8H=V=hiIGw@6I>&@g}%#6*!I7jCa3 z?EN$-9$CDpw4NCD3S#v*SU0x?8|gk`K-!LPw2+hLU6y3qI2Iyf^{GtwY6w9D3?57k zROo07#R{dwB1P$t#=8q&U6vBfYAYy`*FgX>(VfVd;uyMJ4RRqHKU5T)dySL0t&>YW zA4}>$`3mo&S!~OJtdKghoD>&_NLKk(B}qyX2*ArT8~VRVTN%s|Xx<*TEFKfssy70U zub~8A>FpQS`B9`haWLtqFyX#dNNJKhy4NQ%6NFD~bL%dbo%0+_ELC?UkOit`r{`bodOuV4zAEd3WEJ(H$3ntc)zE59cX&2 ze2ll+{@E(X6R5+~d$r}6YUHyGyHOc=UU{8&oTHUB-wGwLv^mUhdV&v2EZIt3GM$-ap`{8!D~;*f)cbF zfYZn8IDB<)0->S#Gh!rVFhK?-l+@GS?hfY;i2qW;({rL3l&D}!h@MR-$imp|m!x)%Vc=$Z z9>X7l-|o-;p*ppcD&6o)=mE&!k?_5F4CgTUMx3u%o*kAzU{9m915#l8 zSN)8>ai05`QOKh(GSUrNgV+MGeIKWw?%COB+P178NswEsqTXpbp>QKv=lsl$U>zXv zT+QGCsfolGJ@N5qQiM*&P2raNnx_ZAVucqx>qKJKd7bZ%s5iJfn;imkGF`a;IVh_M zeonLMYh8`jZ}PSgFd25IVLYZpw&{1&(zM-=xm~pEn87%zXW|76?p-*NKm`2UDG$-2 z1D=4=w;+t5wgqWR@{Y*lv(ltxaf8k`V$NxAbpb}P1XeS-D`E@i2^&X&XQkZpq0B{g zYmW)Y1ud(lT*{&B$wygTx7k1&p(|?=qYm+^RG8Ot)#}#E!lqs>r`Yts9)vG_Fzlt&fTQ zDk(r>x#pAt{?K_b>Q#MPY+%D*_*UU zR@6v!?0oC+b~-h7M@qc|?3*Jkyje4M2?)o)zW_21lP&%3q*$kaRxQ zIqyi>fLmy(EOe&_^cV-YjwKU!4@602Rd>mmfGWH8AFD5@K;g+(TBF=tFp`NpFc;l1 zrU#-S(cMQYn+t$2;Nn2hc!QsFW<-@zfD_^eD%xL)rv_+FM%h|MIq=pTV{j2k0G0H? zX!36W!HoV%;hX=%T|}a!eD5evF*1T%u}tKhCBP_uzt(lINQfAt*AY%*2R!gbkzPj< z(31L%%wb4N;=#4carU`WNOVQaN)Q29I9y;` zvv61@;$;GilkAQ?8&Oin6?N{Ew$On@M`Xg_P*%U!Js)cX`#%xTwY+yv>|4&%(3%?&kW!V`4@hF`U~j&% z%~YhZ!DG2OrU?9ilwne}C`=?&pYhO64J?&_87#Gw<24?0cp~48Y(5|`qo>YUuONX% zKODLZhN*xA7Qs@-!$=sb+qk&D0@P_}chxl+itWbuEt0@G(cl_L^F09V(nJYt_+X}V z#Pqs!7%`B35Lev?0c0?luLF~q_wgdBc9l(vTCVav(x6G-HQFcTOo}ye0L#E zVI1Vz&Egmo&;Sq9S+4?)VLgCIzNE%+c{~7zXdNKns_6!goUy`%_@={Y50`^6vx&3g zy(uh^wrYqV=jjEhS6=OM(};%4i&K|Q#Ou*^a@*vx#*&e@=;lBYoa5hv3L6kxf=9_u z9JWxm)mT21|7?QFV_k`UCakSsO$vz6H=+y31>oN+$T&@j znZ;IrX|yjS@5jWC=PDmsD#g zPt6(-D)!DcHH+_<)>@VD9Cgjfb)=9BCu_x3Nj9}#KfL(yDJFtiWSV=*X)x;rmHRIQ z1Fy&asv1iznEro1w_)*4fN!iIgPP)fvI03seug(vu-=1T{h5WpIA0e0Ip2@Z1%Ta=#1I)&VcLII+cPXYa5=>@9$ZC2Bznmbz5kEd|@cQF@x|M*B2@&5)m zuLJ7O5o!P9lhQESTKka9Fx#vz^#JT^fh*;K+v3}2lXp%)479$KWb2YaIFVbR01ySO z*#C|w)Zn`S;cEeiW(79z;BdxAdoWur#h=e*U1QmE+OG8$xAi#J>FjIj0_iwYUJK?F)ca*y`yHZBcRPmb*ampGVBctD0+0`X6;(CV)OOlhJ*Kr-4a|l3u;x@bxO^NvSt2L zW@K3i5yLpxz)j^15MJsUa(z?{`ns0{l~KI1@O}(VDU(!ro(iy_2pnUzfMgJDv0?ZT zd;mGy_8vPC2rah3C3!oDa^8rI_ii;^Zf1}_hWlOle09+gb!~+ohK0J;hpdfR<%8X( z&wQUoqx?lbGGDu@2x8)F zdV-rGD_B;g)Gr~TU;uMXUtJ1G2Y;myLQ6PMW+FpcDoQ*I2oW4%6mCp-apTFikcL(~ zf$j(#tALacEv#aYkWB%KUC6i?R>@#JUSa1q|`TD7DYoEQv5@xjdpLjLglnPc#2BivY%a56=u&kz~MwYg?qH zj`$c@SLcfJRdbcUorD}@X?f}=d)?3s_`U@KtqDMbt`pGU0ajVh5)i%cM^EewEtOXY zQo~90gYYO5Z_-^Uk6`wY-EstPT8>IjUo&d^E_URw@K*)i1&At6fBZy4Oio`SzfaM z{``<7*;Co`sXHDXll&&c8k&C1Z6yu3Wv@V5jS~*JiO8`tdWUMguHQ_t%!uN~VR_=8k80 z065YP1SQ-nYuWddCl0I-c>7OVg6J8Px9Ov|hynh@3A2n|>=%a8t>ktyczOB-$<%L-pGfs5WaAh*M( zYDU>e%r2oMz{DPhK%buzCYJRC0N8){(xu^8npBOB2bRMu@yLZ@fnVwV%ENv9?*`t8 zksz4W3rZmR)t;^)LX~fQ17Kptb^lK^wEsVdQ-j6^Z#pz8GAVWkP+`^)5L@{s|*zL@8vERoz%vFnx|Y>6>W!NTwhzW$}S z=Xt~xBqsJ-@ii9p17v`sFu_&c>;l^Kl1~j;%O!QU0~1|cjBk(xT<>K@h6L{Mc6JX# zhe>=t70`|ntG5jUYsU~>`jS4eL)78uETc9sdAsLwcx&9A214?Ope#)x;Kk*|xvo?9 z);n?cAuLjzpTiq8cct_9{s7?CB6H#ZIwMm+G0S1Utf^LyiFPnBb>`>;8?unt{6hzT z0FHanYVbMjZ^&(++>__=8b`XI93yPl;tkr>Agz^6j^!2o+fZWaRXmb`&NH*_ytv)P zk(dW@Tc-r|k*BT0`pTCO?!Ej6_uBWp>npug54Sr@rmu=yztgw7idxq`NG9<0AyHjYv}Nmq1|Iv$m}Zs6a7M7KCfc`w{=t$AG4d zw&+!f#{f7oF*@dP0^?>544pKQ2AVw{_LX~f_t+EkteCs*^G^euHfK#;2{M&5b>Ogk1Gr8Y1N{wuvcLdR1tW$c{E#$oWyK{`GoTm)bfCnGzQjr&Ks4)?#l2&I ztp+z&o$DcNH6d&PEMr+`aj-0FaBWW8wRsEFG{@V%^a3f=mzDJ=lu#3nJvwq6 z1P;;AJ!ACAO8`v{U}kqcfhyGlrAb3Xvw%#HUkblLI939}vGy-*lX#pRy5AQ=#a;o3 zl0!1Njrj|&7M(mxa1#=&kr4hu4Qh6g0TowLEZW5qKyKjPV9`_vmqO_pC=LNx?JU^` zs|auny`rhWLVmlgSOA@Cfdr*-plS;S1h3ryAoJ8aPkW#`v>V{Ig6Bg|Kvfj<>7VrS zU1*R+2&BD4H=ckxL1;Wquq3`G#i8IvLs1~P>k^7Yf5-aGa_3Lij7>za|Q%@u%})*UD>O z7pxBn*^|F>bAZ->{ax)Nc)S&i7fzTo{I91V6(eD1r;DyUjFMAo&mh612fu1O^zk7us0sZ?0&v^LnH-A3(cb^i}H}LNlSoOc({B6vVg3d;$_S=8<`0q|bQN)Xz zf7klI{{MGj;D4Rhe=PE!5B^=0_+RG*5-8XHW8TnI|0B%!k9h+1{oC^JAF~a917x06 zt(N#l7ymWS;Q#DD`)8{Esr3IjRiG%>|MNY#{vVP4k4R1aHEBk?|9YVQ$36X5kM)1VJsnZ|vgy{U>Qq{&&4cU}m3pr7 zN26}5WpHg%HKeZ1stZUxDnmeL(_qxlD+1yb3*^A^l|P6Drgg8Mf?DOqMnIgoGOK>t zUT8R+uB)xs0DaZ0d{ZFz_{Xb%r27s^y=Az^jN@ED#Kmiz26#Xyh_$I)0bFs#;yZ0E zKt4xY=0jFQR0nnj3Z~JX#}4zCAlTR91e~b}_{!KYc$T+q&-+KT*8!V&e+vCHAWKGe zv33gs=v2KkRJ}teF^ixyUX>faZZaFPH3y0_s`5;%BFi9 zZqkAj=vFph3iIA~OeqdRFp!2717C3ab1Zw~kzvbc-)j>&wMs}j)~s3peE)#L7I-zt z9&Pd-{q&#Uwi;Eec{UrpavxYC4CDilNihLwj-73gj$Bzao&uR#8l!yXzmwjf`3^Jz z4p@AF96+sUcVvoN1VU$ z4Ga0se;)S+9|Q0^fYxdWjF1e!v*Wu}3bOho4N$ik&@zHQqGkIvUb(h8j>U{InkNRN zVhi&GDNt^wU*FlW@u|+(L!#>+Cfx-P9eg7i9}|>*yFLb03qcj2Ie1NUxB0n6CfJB9 zOu*6ZuT9oCPDI^#IA?!fosLfV479mGqD)uBaa#RhZoW0$P}To9Ake~KUj{sh2&3t2 zH*9}n!u2blIni;juK`(`;4c_}B@_5wDx^Cu_ZF@V<&P9AWlBuIKnEqX;|>@gqk6tL z^i03O>eu%V_>6=ZN}&7e&!HhB{59QhngnVJW|ctYzkZOyzy|b*Vm0PcZ;GW+N2He* zXridRCw60`cl9sS6~)8^`9)=WuvtwrfEgqgS4_$KGlP2i@0pTOmC(Tx2SVV^yvzPq z2$mS2@Y`BFQzAkMsKFS=gf-aCXlqcLIGim<{%pv$>D(0DQ3=lBSZ+@0s_-c|n;Wq* zY^ATM+&iJtfaPSz$c?7U3zKQC)s=~=;#*XLqxV%mDK7Q-fF$iY_);0@ndt82Ut<}G z2gS?jpHiU%(kr+pOAhKHHb7qh*^tkW+Osi`w0Mq9>7*#pH@gH?WPq$TgC!`LZ0~!z zf2IAZmoO-{PcAI3+vGnTX$s}0ykDxfIRi?sH^Mo48F$7#n_k(EH+Z;`gYpoNN|*bH z-UErT^)U8EyJVnIUQ-_Iyhd}U(?DgxQccRCgZUGPpF7iAWMwt=ZWl+sIs4-^{038Jzpf$kR z@XE5+XoY{U0TEX;MavexX4Q~QT6@)~0Q2R{Ub=p+VUN@SUkE9eJ zd4xqmD-mvYJ_#nyd6ynaIfHMzpnJFz*;kH1cG?Og{?MQ(-t0&AoQ=fUM&*c}JnC#& zvzl$ zNV7uq_#9gn=IeWaUm+J;0DLRU-ocywYmn+x8nuV7FvFFHjrRrrDzSq&q{Qr17DIX7 z+!?n*XuRGSbtgPTZ=fgmvClx6c@-8eNwv>BiYQSu{b$L1!9WqnFn8FEPgGi(EvI@E zB{At%+kGHn2DJ~jc+0hI8!CH1*Tqs_nk}y`?=g@_y)Iym)N33T_us1|!;V1#N#`lF zwpPtgVGO{l)9Zo36{18^L6erq7_SUFs%J<)V|ZadNenkx8qH~<+S zu=*);y^}Vo0#tmA0*1*NsvOa^|8g4*veBb)3c}`4(Z)vYT2T;{>2DL0oQ4|-#E7bxnCleiX?B9U>A6yFOJI;sQM}d)?h6p zT9u*%d;JJsyJ@GLoK5U{&U0xK9${);yL6*=S%F@gG+{3tY9d^(_MmX)0JstisbSD@ z8!b1q1qh3pizZ-SdxM_odsRNN8vU+btY-}-Q5>eM$OHVUjeSgEI&7A5+l4;1y{^UV zcRt9W|EX#yZ#y7zt_8Jb8=zLk)$7An1t>{1weifk%L&zDSvQ>@8~|#iwv^KIlCXxM zybo|KHc&ecky5zF`cEIdQp3RJYY+L2I|+DtpNH#`9pqCyWS@CEt_qu$8Y1bsg&YS{8&;(gfaMNF$p7Jv}Y&*mPID+u=>11U{u) zvQ`F|^AxEMti1abq>?GZ1M11<TuNqWo(dLtWz!z~u0y01I2r z@4PyCv@>rFQ60HK2zlWNX4-)l>=@YaeUS67c5iWLR{BzEIbB~vMErFXH@jbcsv6S>go?;oB}Qnzz@37l=W>Yg6m z*yKV!mt(0~1DomSQ3~GKeTLx99e5Hqg(&YE; z7{8AU5%lL~uoOX3Jq-KFfQ4JC(6#{JgdCr#8~*uGW`i(?bXFH>wTdmrDNVMQP&iI| z$t4-Q$AZCcB(HF=&C_Ca)lK9uVx?kKx`BGEpY)L)azdKbOKuG1t3cQ@KNtxF25a9p{QzW z3ID}2<2j%Ff?db%$o`=I&h}vzA%b@;3mwf7H2PutCX$0!vS9ByWe9tL*$39{?{g(5 z73em1>Dlz+VB8{xr+)LBnL^Et-$f|&lTicj>dPYtT4J*8Zk3PQwc!{^P~^ZFM%YIW zK!t7p%mbZzn6G}`NwAw@JyF81?mdBl{$Rh)&7{gn;LkO*;f53O5oj7_Clgb$zd7fH zg@Vlqa*S%lRoJ?jqZLLd%et3bie>cZX4BkB#8e-sj?9qqqkh)t1;Z3sI;*`guuUiq zLwkY}#tTG&xozG7=#VXyx^m>RSA@U=rzZiMCrGM&Do2C9TtOPyc8HsVIU|V-{kj?` zS27c9rHq#u8SuGAAx&6cIsmne{Y33=+JuoQB(U{KL&4AyzyMQyP;FHCKJS>`gPvr*!H-|vcIL6J$`kdbMIF#oXwb;E z`FcMH!=oJ-@{^}N*Qt0B6GqT4f{EcgPjgD>GX;_I+7?Tj1-YomzCES zc6B_!uFVDYnlX#EbQAP&>e-#IeE;AtL-fS+p=FsQ{A>7Yax5hHm@-d_dx z{)k-SE?l7OEuENDIYKwsiD_8=IqpE(031=ls@7Ec$oilz;h}m6ss#O7DgmIC1uaaN zERcII&s?+Z_UAs-0w`Bd>;Tnz4ck)Tpa%;GJ~ir&oad$ABw2p$`n))7V^$aG_qpzt z0uqsnf_W*Zvnw%AKcepGQlrB>r3nY2%1QnQ_rHKgG!9l$Di<1=~5GlYy$ldgai@Y5~?Ikm0TU{c7{lQNt#JD-|#oamb z$Gv^)I)VO?Qv{tMNX)CUPl+ubN?oP9@mRp%OM=|6_dux|x6#{MHwE$CvhQ*VvMb#@ z+DYgXO7zljQb?%?`7P5fJYT|v3~&#jilvvLCU{Xm{h_!fH~>&&3u#ZBpZ;+SG*2;< z!U#^5QuvcOTv{@svjeYfx_;d)Z*H!*napEqB5h>oN}cR<1CL}ba333X)%1)1iiT&< zJfR>yCS0tIw)E%sXve7eQ&0$Btv_EfC$*y^Y_`kRD|k zx;m_2%M*Xunnd|9c7KlZYm?V+zSymMo_0(I$Dk&m*z+0I`T4U{FQ{dma}E!ijV1o4 zbM7jxL?nT5u((S>#%IcYi8rthKPQ^C$WV7UcLYfV%D7w7h+4E@riXF%+mmPI1R9e` z)eoj}jPH%#noVL9i%n7RW4)sSW1Jx!C?U}0Jr6 z0&!GkO4pJh`pnGfWZ=FuH z87QrIr{#g#DO@XjqKu03%h>COD5nRqX`x2lcW9AnbuQK;*vKFhj{llc%Q)lU8l4!& zy-%lq>A`P8zMdqA#c4N;=x3Ots;`2z=Dr>X4@ELcOC!08`E}YO_AQg8I_Mh0r0}#~ z#s!h?Gp!LKOssT-03Qs6^=A-;?8E&m%JIo7RphYfaVx7AvlQw4w%BkvU6}GhcI8gN zTU7z&eyJHlp*s_Ium@Q(Ehc3;up|43UM@ z+Nb*j1w3D!SS3B(E4^hp*UY?L4Mfgad|0pOD%M8~s0`GmuUDj7rQL@sqXqZ5{&Bxj zGzBo}NhSsrRf<)KyP-1~JY#!DLd)9GE-|+9FZt_7XJ2plofpZMJkNiI){iJF5g>Xk zQ8rI1;QR6vQ=#@?Vy~UocYeg4Q$7~F~fHoreoQ61a_^O%I}0N@fpVy z>Sm%jt!HfNHbU`4WM4mI;g!LZXf6zG751OX7?pU>n#QM(Mc=G4(JGu%F;Y56yu4E4 zRm8r&`$dy;{bmQ7$!Kb!-Iz<_)VSwPTKVZ+0Yfa;4>ChkR$bh^Ryk|96TF-*cX$jM zv7b(iw4H*w2C`EC)!( z?;TI||NsA+ImmI2Eyp;=&ZhFT*RiEil*lYcFYBC?k$oIF_G*xWNKr|oq>??OLo}>7 zC@Zqc9^c2Q_vd%{{aMfBJb8}CxZiKL>rKR%d=l5I4+gJ~EsmnT?Oo^;P60){?E{18 zjI}Lhxk{DLZC|6Vpl80;)>0%t{9tBqU$Ld~VV(zhgH}1L6MKlds~Zz%B+DQy!s&q% zv81@lPt`d2=`Ap%CJO}JD(Wo&bx$p1r_e+!Dd zyAPWZWE5!($j%n4=YQDnQPbI1^-enYLgz9nyB*qc1i(s*{r_8OodCDGG1R@w&g;ck z*rHyr%mG`CB;y?94+@;ZhdLbDKFG(1axh?~ULJ>@qFknX>>ALGj6cF*UYF(Hg{=n_ zoRXy;uBz;Q9w^3u5JT!d)8151e#gksn#we7 z!&L2}tJ-4%@qcu~x1rOqRmPC2D!=Pi!X&p(5!cd>bR#(azOC1=mbGNwPsj#dn2=@K zs89D%Py4Foen4lz5L70ki~sbxPt0M!RGYto`F<;swYsv&s$Ozn9G4 zrV=k;cdkL7E&}8rCY5VxNPP~$<(|hJPG;U}6V~md_(h$6XYdDw?1l=J1{hGR0=NX=V0LZs$Tv@#nWzL+q9xiq@9E;I12cZs8ljU(z(-%f(|9oN?j4sx*hy zKEgEo#FD@I7vSlCU9{&>kco-^)D`jwNab{*Se-nFE5^7R^{q%Zw+-@`{?-FA>GClZ z7#5sI6N%m5jF*jv4L+S@umcVF<|dp@%!-qYUF|HBwB@jcQ#oxFscdkWo{1w@q7G}# zT0@%@Z0f2}1myOqv9nKC{8WQY1kkHeBpWSzC}PwyWn1yf80a|Vvyl`2J=ki_vM^PB z9c{E~>(+6kurC8yROHGvZ zO|@j@5vYVc{F`jY6Ao_Ki7I6?vPEP$W?M-nZZ!5W!UJ(Cj#qF>n}u}(K79~5y%38x zBuVJw?`p~Q>Lk{EfWGvXoCs#h*m9$mX~Ok!!T3e6yPDZcQzFP|$)zS`)t!!zA$CNxp!Me{(}Mi5vsk z;^68MJe+%?DNUnI8EH5lpZf_|N|}t|O^Iz*l&LJnM==3dOELnqmzp?CS zYDeAnub*?$6GXY?5;e)p+L z-KBUWqJ2~5IwLnq+2FLzSm`#s_JvRR_*s`;zcrDs+q}(ub~LW#ngUo)^?Y;lh*|DhMBLD4g-7BZ~XW*+)ZMt z1#P6cQF{_wMw!H7=ANnr36P`efzteMiJk{W;zvWS&?o)0(UMyTKiU|UX{Ss9uK7r! z_%W>`w0&5Io6JgyEMnKqIwFTU;*~ECl|Uj;Pj|!Q(l|w0dmd8l{{t;)t6p1>& zA#o4Ek`Rvc>Hg09XGx<*QMIj5QXRnuy-=FJ=0a-tGTi(Fk1oYm?G7x0%^)t95R0qz1U2P&HM7Tq@ABW?g9HT_A$jIXw zUrN_1UbenXvgnLcu1e(+g|I}AIg~SO+vnyM){$!-zgSl7Vkz>7Vk;3;3FyMB=iQ-g~`-^iK&w;&Su2n3h#Ma%NV;g`D$b^ zQuG#emr)cuA$5}vTk#jeEx9WR^p zZt|CFOB9SlUWJ?(KXD|wR658^Xu?er|8C=AQOt23q6jw$iHo&pGtp#&hC}zJw%dMD8Ya{Ou#)xUlt>w5T}y zyyMj4XP{bjaDQng=p5Cj2?;B_cZam>EuyeL${Qu%rI&D> zmOhC}muXg1<#fwg@OsE!65HAc!M;aK>Q2n7OQI;Et&SXt2$X)2v~Jc;DC!n~2x%k7 zzrt0YSdD5HXly4+CVR&6en|GmgZauAjkVD6j9}9kg{V;V&X|EnNumWq)dnQlePi-W z#(R@7q%=fHz>ru!N1nwPtPq{Pt>_Gq0?nc{ z-?8a;{+t94Hb#;UiXnCP4ow65-c?qpyZEwjN(WjQeqI-}mHUfxE zlB_2zmnHbm$|+4OyNFc!lqEL4gMWdfvKWCeG5EFVVibZ7Lh80YcxFkO2`K)%YXYXR z1Ve2M$>3KVg0TTDMQp_QqYk*%uBKHr%wyp4tZcj`yymSXM4DTAaGFNiX>+tR3y#OU zfP8?e*Mp8|DtHn-X)>yx%F4>d(|$lUXRyEJX;fzzP7p&b2wZ zpOv9ph-zb{N@lR@H_J=^>DW(o3_=yQ1RCSDEibLkDjEfDU4unFWuaKet`4J1Cam9Z zP;*?>t(^}2pB5n6W^8AWOaBtLONmXclRWs5jpyA z#x-FLF66VW_@T?Zo^45pzT^;rQ%oF4tuO3qpmHyW5q-fGuMeD;^8<|V{Kg}iu3%ov zTiYVgwA84)ud2OJ5;qaAlHEsR@8wm9?*2Z-s1g~X{}Jh$`Jid@Y6ngGCclD1O(pHL z((8f_?nSjCsSUk`w~b-VZ)AG1u8&hT_Ef2{W5SUU$PD?u1C=Hd0^N=4l8}FCQYYfq zX>Etwd%ZK2|2JyV_pHn7<7bxQ^$Cp%q5EJkBkl+)c1KR|O%}6=id|{hyx)VuhZ#sQ^Yq+s6@?Akl6DR(X^MsSD`pGEF&$rEHn z78?oY1%lqUY3u|u96NC_2clYJ6sfYGvKv32FMKg=#vOC7IM7W2*Vb*Dz3N{Ulz&PJl`A0pts-peqX>8ANh3kUzH&m#scFjg1LXWW%@($ z23M|2q0uRQb_s{<1RQU)+jX%=p}tlP*YEoZe(9@_%UeixbSmPB0($1#Ma*zs?y)2bNHB@W8-m_w3pjm z^?7^Ffd66Ctcy6CEfADf5QqM^Gx^G5rC>aOOwiCI%0`=W5f}UhEfokE;e>@HocP9t z>b}bwucv%9yI#vGhI_@!*#!~b{wiLr?Q`xLVx+#1^MA_3`C#yAS3ri--Rm_aHIeR7 z`C}FC%`e0Y;3|DZ0~5D2(9d(u3*PX#+~$OUPsSZFs^<0Dso=b2urH1DAS4f@Bt3l; z8z))G9UCALyM^Dc__ncv}Nn4IA#WF_1UBRuI-OF65n*Bpi zBcXY=`Lc~YRFksm2*sm$+uzkhviA5{yy|g>znRP#&GG6QqB#o8ei5A7Qgyc080Bdf zi^uB&;DW!V%qaScQr^`*%YAR~*ShuWQa&1C>DPSegkUuPtqh? z%5>s|)cfBr;-ewo^rpgK)SUS^w`Tlcr4N@aFPxdxoV1N6;ftYLl!zUzJJEsK_%cX@ z_%ui>>pp$G9DZQ#H!clvD-_s{Mif;F)Vk(zZiI6DO=uIvmVhHbqHz0OBhMIBr(*T2 zu+z)*C`FexOVfGU)eNtuLK0u~l}k=;aR2)~-4cNhSu~mwh9lMcZR+v*@-Vrg zL%wS7yN|sMB79+Iir0{WwxtO1;zdlT)DEVp7-qINRVVOo29U{tGLX^T*gqSuK?^)p zsoEqR@6TeRb9IJRbPfn$s&z_J_O3wp3((x^h3~LorFWWX-WpCwwiD6o;e;#hiB(ib z)kpLDpl|&q>+!7kdLOsfXI@-)s2GwF3rkfwCYjiRxR|9WcOy-lPnYcQ^k5X3q`T*V48W6MHh zGZ)DAnXqx;MmecmH9Yk|P@9W8wgWVx^W2tu(0%Q%MSWAOIVj?jd*1^`*`tEEc7#`x zU(;n2dHl`Wvy01~q zu_Xi@^vGL{35kEC@p;|k@}42svD~=(>tBQnB8DMG6*Nw`ARJ{Wd9_jgBjr_NXA72@ zO#bxL>8q9z7KU#@97Y+p*XQJXU(#t|pbBafho{Ci)g##;TZl|)`%s^Aw2l48nM)KG z)Y<%){u^$M>~w0yHyib@wB*T|@qrbaxu(m0{SQ-g?s4JbR*k&B0uXFo^Dj>0*tOnB zc$Y~u;`qG_P%>l$`ReBO;Qj9?I!;i;Q6Vj`63xl)6Wx;t8M6e7KqCoSH|8R~2;VXr zyQq2DgDf~8!y!F1hnqwqDKobEddJ)ya`z??6K>7qo>@saub=Fn8?oH)B+#D|g6O2d z@~0FrQN=w&?IGhi{#wGPN=92T_+=oQqPP(QfVng|tW=~i_I`HvUNL68EKuw~wfn)B z0b_gO@#a^8*r+;1{pO}MX_XDLgd;-EL*rD+}I$PSL)li0}y6SJPc zx^x%&Z`j+3a`S7N6f|&@v7*A&aBP5XsaEDhG?P_wZ9vkqK6X9lij{co+dlV&J{oX9&sF^H-=Koy2FonoUfqns$>6dtd__EgcI z6mN=Bloh0rfwF7g2P%{WiZ#b0VTcbBLLF(dDK}U~nG4|3pV|@hp^vEPL#Lv%-rF4Y zYg#seDn7`wns3m%>{PjryeJs~&F#7kTnG>J94demumN~yZ_Q~_n(BBoP>hwBYHT>i zG8hifLMA)5b|Q;(A;W|W*1p#k!%c-He$boW%q|sNYqSB<)nHa(F z5U+9ndd86w?DRVbY5d6@)B*Q54w+n3Kc@SnMNQ16eZufW(Sf~pafMMQEFKhbldVVl z&-fU7GfXlR7TEkQ-pW7zxsLWnRrXCBdFq`sPiHZMXBxrsDyh=;yl}nA%{~ViCUTub zamW}#J>0-O?cx}>s={%=CEz;x4S2l%PW6mT?pWCCFOYQi-nJ=CUz80=WWICm#zEl; zuMh$s-Y$F@Be9{?WA4n7=Y$HhQe9{=Xf}rt;ac#1VAucZb3mi0dqvWJhkbSwdEA+I zBJVsZ2%`oh0|a>)=t}p1{z`|W^3X&-nP`jocnBpXP*l8+NpMNbJ7{Os96Y~4JEfIFMJI!Z>v40RF6qF&oAY+_Q{ zj8qjb^@uZ(nAGu+zC*Rk=2=+W+)#_PXc30ze{4LO;E}QS(RHyQFvax_R-8BQO53I9 z%h-Lqg}k##K|-P%4i&=EQ*4<<2`NN;Yi=}yZU_eyGxB`1^b#x*HOgJyIpgDFl}JKV zqOYZs88Z+hy$sPdZABzCVfJ(*q4N*fkfgwhWFK}L-!1HcogR&{+eTP_ijNS|BpYCr zs0J7rwdc`>w7hYYfa{LVxxPP*XKVvhe68MLzw>Cex`p$Eu4XYt)?$o>JUi>eXIv)+ zw%fZhzcVMKtKPht^1pYG&qN{_)+pTi$X$umHa?i4bGw~g`g*iy!@M;7J%B1uG~xq^ zP$?)=zm2~twMUc0;Jw4QxT%b`#59s>bE@aBJbp@GpHepR5}U-{Cuc`qz$)V)yq+;p`_5XOyBDXx|{V<9RjO&0!j&$FZcU2Oi0D(KWeAC{Ko zRbH^8qk%ir&H=+RecKzJDx}dsR-GfV>l{Ifx}_uwq6gw&tn+eZ+ZKFhvGx^Cy{~ax zti*nu$dNRY6D%Y`hIiDL`tC@WP(Px)X88tW zAq{^A1L)wb=-vJVk`!;L(eP5f1P7UkB`->#rH4*$oit=nRSt=NNAq;<)8yDeJjV8t z;Sa19jdvOke6%X&S^k-Ky^RTzdkj%|P@v6=@Kth;{AKyqb2v+GrgHpK8C%NC{Jf-V zF@~pdQrm8MhZHM_uI>7LbZ|X(G2l&<6o>?ne)tnKF!#j6a7?(s&uz=N`I~v~GjArA zB5s|{ExKOyAkHc&@#Yzex5idag2o?2oVqDp{6cQXJ8T%HBxPOn{G#jBZg?8CHtOp; zjbN`|d9S+`!}ayMyZ57RF9!Y!iJaD&*8RKcH>b zjowPxf0EHqZE6Z0*8KE<27D`d7e7Mygv=ZG_Ka3_9`33lHNer@LvV5IgyW*HWI?>M z@Xt8I8T+n*SD~v@L7*goW4FUN;Z1}PdXmPbxfCw<+TQ^k>1cnr8?O2i>oo6h#m)}9 z_AeKbL}s>iS$>st%Bl&ds5@aewLWN0c}O9fs*UPjruA?Pk7qv{IQ;vDCW{2_8Ddh` z+{jQ}pruT3F4A8$xU$lqy)g)j(bnw>(hx%aao+6!P0JnxL@?gf=u^z`em3cSU@9^nA>jS455uw)k8 z+1aDn@C@rju%vH-D&(U2FMPc?G}fw%85pP}FTW!y{U(uJ`-?~mvb!>dNF-(M1i2Wp!sh*6G>C9;a zvTWtb(ji=u{eKQ_NIjHAn_5HVLkTJT3w+a{0X0!O&JQ&o&;9Cn$FsUgxrup<`i}jp zvIA^^n)oDyF)K2r!p(NPIMnpQ-ig4&V4S*t0Z$rq!B{?xjq zHke-Ay5;A}ZL54rL}P<^r|Rh)%s z@jyFIlK!SP9=|y`7&2TboiuaWpJTT*q4`(FiptW#k8HlE|E4Y0dLD7_4LMTWw^BNq zmZj7MDcp5p1)(C8PUiaLzFRmkp$Yfi~wIIEi0RGsyCwBI*bgao5n7&6}z-ic@(Hx#5G@dO83nG zCIGP5rSqwKalqsJOevo3Vd7sao+}*|+O+zDmNc$WQVI!lex52Vx~+uFOm+C0{ZBFC zK~FDv2+>`_hKB(C$&y*phy3pyTBb)Wy4KCQgt<^Z6d%%{7T^nsR&(?Zi8}o!_3uM* zSP8HVyDeNkcJOSC-K|_A@s-x*^gw+NmzI72)(EZ;5@zo*{Nv3To|+6#%-yEjhpG<} z0?#N8O;3qeixIAQ`*X5g>tvvA7q))wy7uI|YlD8_*@>y@ca;3~SDBkWLXnqxd~sxF+>VhWFg+^pU2v~$Av>yhS9v`8-9E*%E7~XewO3APzTozy zuK+0U!lC#7H;PChi5gvpk7;hEyE072?*4?BMuvO-n%h>iYa#sNzA*PD@6N5J!dE<-*DYtvQ@Kzc{-TMv z#^uSw}?5WB=Nd>74w;f-u)9j#O?ktYcg`A`y;2K=6@htP58Qd`wneY*Pwh$j39j z3}=nM2UvOK7kFw3{PGE3L)h5T6?7eM{=S$h_71MN+ z7~@E`mFp~d+is)W6cpvzPPKUVjpOQi4!w@IWK47wsNc_wCk~!0FEf-BKt=;w)m6B= z>U#XMJ39*BuhE28;?s{HMY6(}Ts}3veDQI`xY$lyVXy3FGh;bDa^#7^#yg3h__h1> zMpNC)ln{7PKNawyzSUHUuSp;;6^C|we)ciBf4x9)gl=W|_UD<@swbRC z0SD05M@Y{$=heQ_+HqMwZ#>G9iVy$NDQKcBs9v$Exr_Nvhz||polo}LENi~2#UiNR zzcX4W%CVZ{?P6PSyr4hsb<>7R#GlU<_0JLol;+BP;JEtvy(|C-h${Tw?M^?zq?Leh zP;I_s?d8KdSdA2j%sl`X3>zcV;H?M{S+PQtZ5s74I!ioRo#tKTcSFjDeCWB|dpO8 zl;aLbgQHF7j9)jgO$#lvMo~si${xbO%Oi6Eqh!y+m7?Ev*U3dng>G%jn)5beD8 zj*g&@l7s{6#<^+4_Qb0#(om22H+?pCR5pC-Nuxk1Vq$SY<1gY=6%t16okyw)6HR>8PRDnK_?vKE{mF%z3{4(mwn zA=sA>>*I5#&_P5QOi>8Q{~$tNFqwIHX>)>Gcwq1@IRxXQcWfdIR@NI7PCTjqc1L-9 zoiQ+RZ#fjF9EKb>!0qJq;{ul_TFdpPY=J4%xxVQ`7O+v6y%4vwkmLsux_j;Szy2H8 zu@cWf$2JfcSi0Wxq*f6plTM%b#A41`5^Epk;J(S7$A6CUk><#5{#F#FnQCuI&4= zN$Y+J-q}&l+@g>OnAl*V`@AU)aj$+LtD4M*Jmuzt`pAIMllpa# z|3J6t7Vja`hEV{x+x0I%vhe1-Pk=U_;`KdPH1s*K{0VElY?R-<8W!W~)f)aRJbzX< zCjz@BmtCp0v{m{J2GT)Fk>uEOJpl_b@&BhAHS4wc8a@+y047JOc>x^hW&gJ2YJ@@h`=RS~Tk zm)+wGLIh&2<8J^1=c_JQ>~O#i_g&3^Uvpkv@xd0cDwSJ_8dpKy?CXGSC26d|xyC=c zAlh;l7Ozv|*O`Q%{0Aygka$LniQwIDqJ)-2C2EM`5VwCjhreS{Pub1wr`qE+O~X~( zsR_Xm@36+Tfm8?4vGv-eE#Um4R5VwvIX>Ct(4G&MiiO=#f!(=x4>pvxpoujqZ5Axz zft?y^v|Nv;?Dj~0X!dUF{O=gCaeXX6#e?%yDQtPQDXq0fNyXUMARh*2F-t$1dL#oC zAfkdtD)*V zZ$*^2yHR81rE7OenQaA!tpE?)3*>^OY~Ot<4EdH#Z8g_X3}~U00le)|Tj4)rfF7;< zJi4kA?O()NR>zhkE{GIy2y=Yt0t|pZ*@jyXB8@~CdKu+}BNC-%K21N2=*d{P72VqC}9#&S}2-+&& zmT==<;XGKu_XtfS$T2$2hF_FCLy|z14);ilzcggnma{%7-NCd@< za$&Sltud!5!(%KQqNjEk=nrQ=Dow`(92!DZu8JfEJK(qQ2SNqgxp8T+jpJAtQ_{O- zC~nhlY|O(Ho6y1Ogol>81O%&JG~5zNY9h4G#`S|%Tu{=$#`Of~2OoRFZ9$ymPPG^d z&+rXelHTBZp1F-p`EILlXuDBFmcP;BQzDt27{|ZsrsI2B(wHdMI1cAWcY`; zyslUKBErV8J!~5+UOI)Z^Dga@ZG&nz4nu&cKE>7uoov z>q%0@pVTcfyy9ts9~qkM-gc`)hL~<8(>CHKn{Xckggq5*EuNTpCaCh9h-ope9I%a- zn-cb2;LJE$_wYjfLSk+e;&J#xlb#n#F8)~ZKBcl%{cewp@xdfSk zHt){ef+h4vSv&?If&~ODFY3cZCy4eJ>kswhz)A5c zW!|T`!`?->n+i?)79W}aKP>=9drs41gW(c+r@4ZU!bx$Z zU>q#pouv6Vcp#Ng;jIMPnjFXQ69l}mxh8xpEy==SDYSf{6?sssVk#6KE9s4YgTJ>r zTsKV)Y%wBGlnl%$x(-S1hen(hUt`Mg*Bw7|f9Rk1$>oo{s}~kjxBc_g#l|~L!Y~$g zh0hsRG$bs*t74SMaIb=ci+Sn*Q@UE^^~GuC#YtzgyYU}WdB;hU$ur|-3VZPB?Csdu z$Wiqu1Uxw_ay7sep-zc|U8~S~k=n5q7uxwn1$Awd+l;?vmwo#*;tu&~@6U>a9dI-7 ztB!b`+pp@!Jg`y;9T;R1USV%9{3L!`sKCCh?E`_bD4{M?dp+Bfp+>@aXMOjWQj7j8 z&$!!o3~5Yr&xX8zfw=U$K*JZz4E2LDi(myO2)131_9c&kJb1d99zt&P zbx#qpp5{D-`ANzmGspDNGUtxAI&ucLmOc|_yF1Y%uoO^Th?sTDz^El>1d;V6CNP8tJv;8nm2w|{ z-&w1XKj^gKcl_fEQEKEsw!tUn0Ee-NJ=lqCccN4(RDFvASSzz!1O?fQ;Z^gRkL ztH<(4p!E6ePzN4#r@GIl6aW6!CaK<@?gMuR9W+D&ydq*fq((8ts%+)erV=_#d(Le@ zhxh}ds)3_koz4Krf|u6R{So_SV|A*Z*ho(PHmD zR+ZzmcKYC(vCi(jOI{E59{J?uT)I1G576CFAhY=Z$==i$>6T{j>M=n;{+6T&JF8xb zwj?sstnJH5`m#=fi#^=UOEY&ceiNnh%9C*I6hUKkV$!Tg;?t9bbDPDvX3qjm_%toz zWNvrE8J(gapT?IT3SV3AggGnBXN|TpP1B>P!s_tf)GSv!G@A?Y@Qd-INBEP1?9I36 z8+&mlpJMthAw8AFL)y4zyE-YyPoqk4c{~PCMkYVKAI^@r5pd-=)`=+mDZz@Q@V%AB z@qIqC*>rex}<%JBsj5i&Zjrt5S?J;6x=k#e3MHx^}swY!*sKT@Kp5LZANVxo-IY#jF+g@7; zM)Cq=YK*mq<=D>4>hJ#JJ}tZprvpF_??S%NmSrAU8vY;eE%c!K4AgOFJZqaEs>aSg z8z$v`Ypd$;J99Z?=IGkjnZGyfGkc3M>3avDyqaSz_Zis7LFmXlDs07xrGCmwj%PpP zV!GnIREK1tXi;o%`AEH6)Qfoe-XXf z7wn8!nAunGYnHv{cG}p3ewj1`vU$BD#Td|Ti+kvB(u}fHY$!mYL=W4Uih#tGV2rdJ zOSly27~&8>Or%?v$4eNUq3420&)knx_sHU9F*0!oAi)gopD3J^ILm2?u~e-AP=T6@ z*YOg=)mB@;9%N~d>(lc08Lc9=a_;HL?m?( z1<{4S@iT+JeweaNNXQuv1ety(dNU8_1G%6ssA%NyYPyg@2;U`-VZEVdqcb<;S^#ll z<}TQlpZ#`QzS@%26y`X9WZgkOIX3)s^!iUF!B!*RlZbQVVmd6s)Qos-BTxl!enu~$ zQ18Vx{YR8drVetRy4yQHJFE7jFYG1{de$#0#f3gY+vR~*>akNzblbFP2k^ds8xKHT zt459+nuG8c4u@THkiUsx;6q)dS|7RG*HZp^>d3?fErO+3dG&ydfck zI89+jb6~Hwna6}5xJE)|WYD0}JF&k&9uI!P3nbFDeNh=JU{Zf@*Af9PF1rWpn#sR) zg)(@0CWuFO4}Ys6+z;F%v^c%|?-FQl*Ca83s}F@W3OoT6ptr$;6C~Kox3{mJFe76T z^!N~+XsRQ;T81!_OJ=mKOCzz=dpYq>8|4|}0?()@1hwI^W;Gu7(9(q6@;fobO&GqWba8%oeYB@@T6`iTwpA5^< z3#%rCox$sT0rLKZYJEb;h^vxrZp$Mci|ja1cL^gsVg55EXFzNmqvn~oIas<)VgCMQbJM2CY$CzxDq$5 zb(SdSUiRWtU3jPlGhnbBsa?);k=Jn+D*qJBIrnT=|@ zUFOY=<2`D46|YQEI`L5e%k6;)ks+;Vo#iQ4btq61W#msjS&^4$AZ>LM|BOco{n%)C zr?VU%D9DPupIJvAExxWDdj0ppG1D(x#g#)T1VB&mR}f-rPAL8U5PyIq$LjQ`qu=NZ zNkiV{=J$undJ0UN^muSr;`RTj^D@9YEA{-^r&rFrwAuq7IpLAA>`Um7Vlt>b~$ zRPiT;i-On$A#gs9*f&G}V=?_rYA`*&@OS!FrUQSOZj1dx6IsynA1ra|*8nC;LKGY- zj=go%jK21;a0N$ZeZo?l!I2pHc`FE?{t}!(pfrHec4`{i|CIz(f(#3uu!oON{d=~7 zBAz6bs`QDM{v{p21zFVj_hXp!_u#j(8+>z!o+Z!+tdf@J`yWmItIM4N6L11kCXh>k zsgVc>zjnPXpY#8>-k`fGEr$LBkR?NwBEZt+k(Sc~AY1xWeG`0TW}ole3-FbX!7pWb zjngOm?-4rew{Ljw&^vI1NI%)h=2EABCsU()F?o|8W9eV$K~Ed2*0l$}6n$~yK_BH6 z!%8*jAEnXJrWpGFgU6kow{fPrybYW={RREBU#`y8{QDt3@Xw;?VsrYVbnhO0SUo~` z`HvoSG94V_$gCa$IC4ac95{w$w@Ukmx{{IxUs-%4R~wAL>2u(7cHf!~75qJ!W(-LX zUB9>WC%m4|A zFFk&sq#$xAkx%|_XcypqK)=Ex_jiKI7no+``jd8}e*u;MW` zubtzx-Qw5aRSkgeKga6px4W0NrCzN<0`x3!R@2Yue|M~ug~x^DJ5uvexqj!$&%vq^ zQ2=(S_H2g-`*cU`Z@Y?UT`30csUG}u5$kz>Gqh0w zb(>zYbL#5q6GL|ZU7}yB1AwyJKP}M6F5%0q^aKd(u5Cr$tI_KUMZ1EE=V&apfMtFE z@iw@SFX`YG022}YyjmG4H!x=5d|So!*HjeXJb8W#cZkT?$`IW4`r0`%B;1dE>B;mzhk+kg0jL~b0K)y%;ZR_2uK7FMVmb6+Hn$Z+)a+T|)z~w=M?(M~0U9Z$QL*9<}?^ zm8vGL6I3P|LW^-U@Z=xS2?CJ0m)}5820h>WYdnZi@5g6@d187_+3|U?ll+f70FW6p zViV=7&Qo%#hQ>dE8f6$gf*HgJ*kU)INA6w^+uNM>`#tl~;h~N2+qEH|1rWMDc*&&_ zqYs>+vMqA^n>|s_&#A)a>Zk7dIN$7e)eoY!w^zDUo|+~J1Oa%s*7RdQ9k6V1q62DFuHAgt_f zaPE4wm`0X$&DX&FT77_ex+Bj06w44{m8(1d3TpSbBq&JS6J0jo5R7v>$QH<0tj<> z1>!vVK70WDLD`><`ELP9?AuPM^Xun6;u!-Va85Hym=gt}9qwP)GA|exm}esvOuvf& zg;!xhZMgFKkdI34QJ>p^Gmd8@>@43kPPALMWc9FlO7Jv>i|U3{hX7-g21~W|_q z+aW*eEI~9`sSWVkOf(}&JpkA-e(oD6X4)Qgs(p4qjpRx0hULb~YnXr7HJ=JnJQA=HjgfQ-{;;Y*ME$0==bw{vLP@ z{ZX*rw1M3b&X?BsT$w+s+l)@0Di|URQ554_WpY#P86fI?k7QF7A19ZRw5o{@#ASDJ zHr>ovY_vF^6vi<8v2UFSpM&q5)AU(`n%$E&4fA z_gkz!nT2+QN34&&obkaU=)w`La!K^jWK1Gr%21EytY(@pZLi+lsB^tVHGyn;D*|S~5?<$ihWt z$vNJPPNNlUaLj!3@-h)&&hwE)!514P494EQ8HaY0p2!g}H!7;$Jt|zd!}>d={nT#;!uRPOO3ir&4HwV_M~)x zkkbakHPjU=N2^-o980@+hgNGW@lha&^LI`ws{pdJAk^kvx9kSGNr+7sv8t$Ep^Bim zxRy^WHd8~f9Y&-#0}e5NSxUaPCb&U zxQJFn93V5G7VrzSj<9LH8m_LdDKNBg^y-Xt4ZkOr8P1*R1*nbR1Oy!l6L?hN*n>~z zBj27qNut?=PX9OC_rR7!5^#7tKF67=oGO&68;($iDt@Od_+@NV>>gkfHovQej?@)& z7$;;W395*FL0+=vHHMeue8zE97b~$G$19`-x6p5$J0ShcCrFK>P9yx5IIbS2UI=0l}WCh)F z>92qc%qNTXAcZ}0#hVxi;wa5);3icp%(roF+vaIs%3EcBI+i9YXI$%TW}_MvyQ&54 zSp=~sB1nvIy}-ONR;=o*N&&Y%z(g()xAVpgR%=E0&@aZP)dJHaZwO#2yDz&U=#g+e zUl*f5yK=n0>)&#e-Bv;#3p?oO=XEQS|9m|rt+{j0A0P?$Gr@6aiS#Gqa*=G^Qh zQ;~KSSri*r{1=_6Lh#BaGJk`*%OnD4MC0Q$Cw-RK*zPiSWY~s+sokTdnM2l<+*?QkeTHRzR`Dk8J@gR-l z_Jnpgup-Z54fsYe3T3I1U$U98?*|_89`>)T>aNzu{sKGnypD_T3O#moA`DA8DQldf zWU7A!nP4p?tNT0H)E^5=20X3tA}y#J#)I{k5s)#!RickI$n15;*2gGoVp@g;V+1eP z7BU@nz>q9lq~4Ou1}fCnegwCap1MzwxWVeAy7>;_90HRy-hpylv1hVRD6%X$(!-rb z7=!B8;ubBekVPDm22fmYK$Epyp?s7eR0xT|Nedwv`T3}`4mrsJ2vgS} zG3?a=GqZwo?w72sDmFx#@iUICKSnrg!o`ixrp9I<9Oei&g}H|GLboZN4R3X9#PwK$zWriWCJZ1qnMR%iH&cKJz>sxX6t z($KS=D&N6o2kbz_YXi@lS)l#t1NgoEE*Oi!LpK)4zUVd+m17-?Dv=54J3ODZ|Gg0j zHWHVyWP@~3-R${SmkA9w_4aP|>LQ^B;oNM8*eLr0T9by2=*Ae#^YQ!4jUeTS1FkR} zRAWhQvVxr6?)X6zZiz!Yx`wHq!sVh4#|bN1{fLp_U$W%jiH*BT#?Voe6!(P>Q`2R0 zcKFhBpUp=Q3+_jU%lSO0& zWc7K(7b*Xbz4wf2vitf56;VN@gr;-|AW9Jh0g-B?i2_RRNLL_$AVIny(z_xeO%SE` z5;`hfnzT>?gpNQ0(n~1sx%9sO&&>0zS!+Jb%v!V7`$2(RS5Dn$pIv{O3*qDpW2@&7 z){B^b=moa8#0gLBeamY&;`=2ScN&`SG}i31!<9w=`IR~OkSp}rO30OG1;G+ut1ie=!GdEdcRijR9lk!3;(j1Z=r(e4jQT8gh zZAC>hWyAYZYOugWPo#HI@)LZ!$Y#P$@RJu|kWUJrK-toJV`{+~4 zwZgfZjt3Fi^25$5KQGPFJPl_#;_Z`fa29F!WYyyG%_qRQ=V@)#Q{GVA&uu21V_z{|h z+r|#l(@fU%Fl9wx@o9e|x~2cul4Ah=gu;p?Xm)`N4WZq-xa-|U;eR>X7y+DK6od@W z1l;p&b#iLw)>ES&Mx9#azQ^54o`AdeQ<<~%G>QMRdizjct-DKnToTQ}ha`^K+V>JJ zUpnADLzZaX<90O8XSsmnGW!|#dj-JSF-{rfQbSMvt8MEJ`_p(S_-yK=?c<|)o$Ij= zW7+*#F4C>XUB6a9bGhL><3u|vV*PeYC(_(V=)uZ`Sk~A#r>}8WZHk-4_)Y`lT@)d@ zJkf}GOsr+F72qbj5Mo$jS93Fro*w}1;H+>u-hWRK3rUYsuDV%ZhHcLku7bq;q?`zMrVHvpL00!kWv zxK!J$8i`5@SI0i6v<-qVs-#|A(^DR6b>SZ4y2l330g^XrIUmjRh;?5j@VPvNtS6`z zZ7dUa=hYdBw6#^=V=Rvh_ubp=oK>7*xgLwBW_a7#+yy4@U>usrT)+FzMmPb3h4)yE z(Z>BVPNwV@vH&=>q)9iaD|3l999Y5q8Rf_SrsV}+1(SR~tz{)I31Sqn!8A#~nH_6; zt(_ZGvTr_M_gY3Cowf(X8BOuwgqXcatP26+d?e_MM>+DoPo`R?_jN zC*TR0D<>i=RdztuqUC}ounZ+#A~z8XCnJ|p!Z_^Tk)d0XyTZYwtQPceI`8}=+9sOm zpev_)lR?FI$&+`c?DkdW-CJ;IM^n4uqBLgNUfO_GP|hM?w*YAA*Q&qX zan;$WQ|9oH+w@=MVsq+lzk^6i$t|e3sjiY@Bfdt+%oZumB4g6yWpUv@xu`5^~9!{!XCF8tqE zfS#0G$GR=d`f2aG8t1TrWL5v@R~RU^O~J3QO!|OC zjB(CqaL!@|PO__`7DPIdkTweMyR!kboFMrTNSLDvEXN>8$;fo7NrI+{E{27&pj0qy z2X>34Y@tZ|G1?gp5k06((JUe?EG7eLOsrpU zDGByT;U}5pfNJlKSMWGsZi5=2ZdLx`x^atUFlA~IP)N2t4=~UhAxBfmtlZl`(G$E(YidpR;!UTIFK>X6%8o>QoV({tTj<1l>g_5P2f?Bm6;AqY-ppjUe?DS99 z-$K3`WmS?lmsJf!fZx}K-F-I3B#rAW**(=nJFUN6Tfe@Hcq!{N`IX3g^U2R#V9al} zy6~r0aS~v69oYwRh3s|kJh3st7|uOz9nix6=Vre9@u33Q`@*XE4`~n|Z-s^&Co?Rn z0Yy&m{!TqUSU>}VbcFk6uac*dIVUW3rBr_APhiCW&%1e+Ph@r(32PgQ7r+mAvw(`o)uAIjH^K@`l!Mb6 znG5Q341!v`xkk;QDm<|zrD~^W{cdv0!M}rI0r{Yu!PF|ShW&z0MV?_19r?XR@-$8; zoki{gtujc5CdeTgK`j?5X#nS}G6bffb-2IPKPJyq4_* zfu#na1qy)t^R?3DLmEOa3e}eYYdlWSwEmzxhD)j58swI+R>>=yv@c5kr6+mb=-+Ve z-jg}L5Q$I=0U2`*p6l_Kjhut(#hV$*5&o0e$2WHoKU+-G15xuqe$nRwb6 z&;ZniAE@j1<jp>9|a%>Jkb~|f%ueMA0*~`(Au8(J7XB+ ze6)pz^xyrLd%!;$>lly&SfU*1^j)wpGDg~yknsxH;i~&LxEIs?rkjSB&s5=y&9R9i}XQ2(Lhvkq!n-@$47G~E; z`yXVqe~PkxWc$;x9<*7P{ti7GYUF=!)*s6H|LbOj+<$x!qGWm5VRb;{&*sbeiQtGD z^*RSPa$j?Ef22~RVNx|_@U!H6N%mB7de3sPVE<1crW-uh=R(hea=2fVwe`87&Hac!Vi2fP*6|oV3JWKQ+9Mb!NoIF^pe2WHD6V+S|ygRR~ZTA0p z_n{@Z=NXP|Wd-z^=K4JzkZJ^dy(4Nj{H=VuYw#riR(gG(Dw7cm{-#J}AV{6Q2M{zk zo?d)ls41IbB`aWP?`o&Z|NhKiC>i$&ztar@=u^3aC77*gWH~%cuK48o>NWIj+wg3fU9q%|Xo3q!1p>pfcXC_#MCBV0rMzpwoK*e^u z!#4xSW&uA@b_iK?2fRNE3T24kd&&kbd?wB8PdA{zjJxl1R7j6Nctv_P#F)iFZ_n-; zKB2!KK*!`EY7`9dL0J6OzA!!N z2H$YD&ft~jKtsR%O)-^+j3TyL_ck7v1V<}0Tr1`2@J0VTo?T+o!{%t^P`gYpi#e3^ z)PJyuU>Yc2pW6<1KitdzO=M>nZ4$?!(-lI8F-UCQT(OdV>E)m~w873%r@pB{m#yc> zN#bDmJ?{{`5P4;|fr7UR3QVxw;m(#RDb0H@K@w)(DC7GKu=VL(alC)7!+FUci-qAu zv{6q#D3MH=CW;*MN^Ul};6Dwel+7!Nh3oBrY7qFAZ&4DkpVf0W_EsA4LJg%hEov2< zhn`qAE0v)9)wRslQSHMO7gOHlKDc;O#X9yY>8hwr{&KSPI7cFEU|ru~6(Q&E2{5#CABsBze6+dVjWKd;VAJ z*pjT(NN5~tkHT$4y+NRO^-EN7-{<>t=CdQR)!syu;XYO+w?dbm-=tQrDF~<$))8te z_PQtutcOY8RU9EI_4c^O*z>4Espaw_P#C?HG2X=Hu&}PvVQGZNuG7NAv!k2vEUfPK zl8I!lYKPR0MgNyB%q;GrLF!6!zTpDp|E&Qh97IxhZqs|Z;hp%`qsYwO3#leq*AZnO zZ&=sc((}J9b!<59b*OQyR6YLXvOG`_w^fgqk}R9>i)<^hF)98*-+?_y^(mG(?^6*U zNKp|bd)(r{bnxDLb7Tl*`RR<<^h6>dxN&JDM^+bm*qBnvX53vdO4LD9$sXFG7bsZ3lQxg(z!D%^a5HQqt~_LsWjkaDSQ z<%@UH#!q_JVDsy)xynjb+!fc=P1I=}?Py#rk>0uT#!7Vw`3y6sljfzLxH~}2uLGc^ zu84^AS8p;s_SDX{+`(Zw>O`g@cJN12J=i>z}{e$TQ~&fx8me3!2y-CLdS+qc*497m$q)t@g2 zP)Z!x6Y&uX_Nh5>NZc1B%F|(@^O@KlApv#B8g)y_8}GYq z4218chB!$hcGz_#blq@$0`V2C7Fm@fn@?Xz3A=2{r2He)%tl2BK_J2#2_i3Sa+nlA z4R04nPjvu1XF9OrC!ZPv41hgubX1)+ZBg^U9&W4{7L+g-)V3L*mdsqYbDye96>Z?j zNG5khuDOuRL^6Bay79Xsc23N?X}r5C^(HdV*vZwGxS!lx;hWF2vbTIj+CDznH;|s+ zV1QC)`vEWF-C>3Bw2SL9ej(u7V0_9^Z)9uIgy{XdU{XlsUF~gZZ=basx-jTIa2!f!-UclNzBHyHdn7B457*a~^{%_sb zdjTBqVa%*9c8{20@xh>DCQ_JEi+!*<%&>TMXjubWVwKCK{&u?Z6EoJcFw$v3iHY4n zd>P-;H`id;bvb|BB{(q>X;_8SuwUMvT4>gXlloCFO85qTPbD|QUW%clbk)Vxl9JJ*j zwZEl`Si^4}$q_H&yjCmBy~U4tnb*c{?OXvESnV{JT5ny$-&41+Hidlp+SeIWekDY6 zguM=nx00;a8~;ha8Wkb0TuYvN^c=Er{(&I)2o+AJqy9x=e_0M$*8KG+mr*Br^zI|&kI zZ?XP!T%4-Rn5f;c7>Z@d%<(X4_Tt69?0kZuwP zhEaFBho|nF$it>j_lzJ7M+rm5^;iLkh0sLgUZ}R3Q}OGi?X!xb?XB#{%%q>4l*5IA z$%BM5ya*rDt$5?Uh3z5)ua;J?^1}dueb=fmpw^m3*m}}W;=4RGf!)IzCEY9mbB5?V{%D+kUUhUm7UNnP0Gb7BD43sK85(oxPQw? zm%@K`pj#I!K~S&Q&SXjDK?Ik`d#r?pbvwf@`6ki<5AYeocrTwAdj4alvx5@5U9Qz> zF_BJi?n_tKEG(BXpNA+*vR8d(3n*orj=f9gDctWarT**Hp zbHQC_*nevf`)ORP@Z;C%1$)(Hk>7WS2N4VSVaj-dGgdc?tlhyYrhxuh897^;835ES z4c>oq4jglhZ=p=D$o|ngAIMb4@xe(+sUp033s`rfRoz$2>`+ZdBm+($UYG& zgBs09oNB;iC%URA-t#EHm(@&G(7-%1$t_M=DyvXb`XE|BDY@-V#zMD4e_wLUt?Fl| z+{ltjhRk>kTT%J=DJ*fcx?#vLlivXqlTe6bLuyX!If=vkHIJ7|=p7_6h9cG@61rp4 z`wvnPR34r;zD?~fu+@z(vFc&Rw+E+U>sOql;Gb;g&aE)yFA=p|y(d{(73$7ZHqH;+ ze;$wpGoMWeIx~!87Bg5r?@@L4*Uo0mDEa%zxJKX_K$?z32+2yQtlx-mIn0q)E{It? z4Qq=5w?<^}CZv9vKw5B|(R6*h06c)K(WS6{rQi#NNiQ>Z2U7o3V0c*#n>XJwHVWtZ z$=Lmw(vE0M^rxs>1FTY+_7k*-9)ip6O^upV+io`Zy=G4+$@aO7F}U{pw878U z1db+)Zx{L0RgcEwx=Z`J8(IJzX6B-;x9SLQ?x|Nbz+~caFXFr09Uov4s0+yEzaE4| z;T9*J4(F62$I3<+x>79T_}<}=>m28*ao2|@j(5Y1_Ya4Yhp^z3)vVSXbq8U#(|F+z4`S={CIz)Y-x>a!(@0Kb0xLSS+P|R zU)p%)tc_%SQ}SZX_5*mvq=2Z?_h$M~I>8lTA8Sj?vdPs49nXD_8}J7{yRmym*VGLH ziMK^u7Ixh1ar;|eMN;&Qowzja#{jnQ!~tkIO^|Xk_LIS&83<<1r-I{rDWASk=lVdn zBNf$eS|YzDz$;_qIU*hO@v1?Yvd#+S=z=??pKgH`r}(%y4UYr1VqE2&Kn%gtCrPR` zLO1R8mCjMuWn%|AINiW~`4*9>Wl_6hR4)VN%)*yh8!zBCHR(|aXbQ_4`8p(I_qMoE zt*xz0F@X_trBRrvxv)H0)W%?5moZ^m+d9xYPQS_eg1yL6?hADGz8mmJrt1Uy!GB5o zndxL#Z@#y^^%Tse38RHpUqX2VT0L*Oxf~r6Q=AAdD6w%JdOYYXI*y~?9_~<~J8Wnx z&_FHhG{$K!zq9oA?AR8p@HkvuS&p-F^YIGl)+QN4-F=)BUo zT;CD}{)H8|a;Gq^r?b;buQ%qBpAI*-3(`7}xE_FzSZqu>7HMfNSbn=T~WBR_<4 z>(N#BZAJnGmyL!*I?qgC9A*jaVv+KMLV4wM1I0rcKRQS}BvHJ;=>LDx5np^aE;P*B zC2iPRie6G;1dW|X%o43qk3_;d0hwbx0t@!K8i10v-t$ltkoX@d(?jzv$bGZVfz3St zN{Nl4)Qup&F9wC)vk}U5kXRW9NaKDupV1y|P0yQq%N?nomJWSYkO4zXI z$xh9_X4E^yx5}iH1;*n`D-9yY@(y93lcqDOD=F=oyaST`B^@&{E~+7ir0&Yroy@DZ zM;gYJ_j>oP$4}0kN-+U>7i}p3pv&^xv?(Eo=l*M9c2de5{YJ`yaz`24;G;pk;OO>M zUo+r9Kvxf*JGSlqrBuNCCgH39+%kT$+BF|2`tD4D^2*!8MwHb2>ukEK6}CSm)WhE_ zes-G=N9pdZT!|gg8^LTiKu9;G{fW@RPzQq)=7FQ4Cy^|DQr(x6a!=Wb7h$^2&;Pc` zlMl`}v?hF*MQY!U%GxwwqJ6*K?A#$>2y8fNE{`YQb~p-sNEm6*iMyM(c*NV99oLk- zUHaN_q%e1WWIH_k&MEAXjokF6K$Qm^7HhPv;i$loO(xHe2({N22)Y^duDNQ|#M~5Y z(t5w$;vKNZ^(eMY1GH|Qa!l!tfc7^vX?*&w*t-+u>cnjcqG!KtM`w}lnKIUqt0$}9 zzBL9^t5TZX507Sn#A-)gV1pFVIo}Q$Eb7HrZhpqzeW#z{)*Eh)Nn4CtL*_->frC{> zZYt%FkRVCTNp<0gkg?vGrT{$Jv zIaZNzM)cTfD~FX4cjkQYc2$Q=`D%Q(a8t0A<(SOJapm~8k9c;#NSu2fI6@>0Y&gIu zvG?KuoSXgkrtK&c4N{ox78>1ol991lK*Xhn)p+4%uKwc3T`>c)a-k!adhhN2oBSFX zS%l%@ap5j*#Jbs85D@saKNsxO2r%G=9AAhb3z4-bk3N8=YC z#om1Jr3|W+6|Zaw#*a}S4?!Jwy%~>k)YAs9ui&2rE}`4 z97KVN;oOKPuEfavib?eG=)s(6r7scjJVWvGEBn;-@;pRB-89xI{o46|V*$R|+nUx* zxq-bDs@UvdM{Whi>8mpcYK$#uJDQ&*j1TX+6@js~7y+GfD$4+@#JPt7V_O5v7{_6G z{u-sLk`+^a+bylQDooIXQ_2>8;5)DtIf%=MO&G9g_ZYBm91rH|F)bz~Dvj1E@Z&o! z?(2ghI!1$qzPtJ51nB|FtVhk(vYw^d*+n)2i5Cpxfsg^q{ln2|Ou4Li5ndgMXk?k` zagyWx2KdsT@#0f_f_re59dWIT#55V$lpG3C8GJ(&9`;(r%&n#`~N1Z2Pc&%L9;^fUrSSP zqqL^$LX>CG;hVf4jln@=3Fu$qlC$`e+aoUGhW-2HrIkVk6+a?t?1SqLUkG{rZg#UD z2mlpcTX4Rwlb@Me5bX#a%$rTi+rNLg8I#UM@{bxum8uufG>47E()*4y3f0-=N9Nc_ zuX?weRP8uRrke;_*bO2ZO-mP3d(dk6AM{o?3`Wz=Vw|=-VC$o&bVoB1ObvtT8}lu4 zFK>?#;`Op)kEzC$ax9jVaHF#cxZzjcw+$9GBz1|_z@Qo!>D|Ltb7aJuk$x3~dX(v- z=d!n3mj)};2l-GqRdGCA5v0o%ho;=S39i?*a%BgFwrh3mon?c}x}!f_?<47bG1p23 zvEt47jq>7rtNL9z?{dwwJ1|bY@fSLhB?VwK%p0?j9`>VvlsHJT6($`;u#KI&rl(dV z?}sSI#Gk2Ii1hu zuLW*^8`Xe);yEKQA9x8S3&Ci<*vSiuIgUSOMkAm55@oSRAusUZD0|mOQG^7^yeEn= zzHsj5l63Cou(&dsW)=PRX{)i+zGju0hLD0;G>|9bC%boe5ax}K%0bE`b=Fhs%mwG` z_z{V&&V!R=LW&N|zSA(ba@IAkib07?RL8UtvTMyS)t}yU^ypH}{1|Qi)HmX2B&%fJ z+TJU|l8aiI18ZctxXgaH!H!3#&xaS8tPe|bJPCvm7sA_=s9TR7)#^Qx-0eIP+e=Hq zY*#jp69qk`EM0AN%6T1X+N67SA{*?3lZVR+#(QU;*G%<3Lmj&~TDkhUaF{kcPbBDn z(ZXzu4EC<}Vbm@qyEtps%=Pu#6L8G=YkO{^$nnwPX2J(0BuP?kA%jDiGmm*9HNL=% z%f2~Bwq)P$QnprF?bffpX38AHyV&CNifFb6kPmmQ9FeD>?B$twJo-l%g>#Et&<-QZ zpgAf0V9LFqt@&dc;x#q-3OhWve|L?St(S)lgit&a85HU`E^_oSvISM!>>5pzr>doV z$2fA!)p_ikrzZ16IC~x(4X^kf2@*Xvk@~Q})OUGhrzFRg;IO$J0c0zx2Iq6hHz*EU zT9%Ki9En_VM%T=pD=xBH7Sk2)jhkU&w_J^=#OzDm!YC;1n_^m!9!uG|B+O9fPm2mbVyd<8H_T?+tf#|_Pc^eC1)5?=MK!d-(m*2 z@_o*sMk@v`=~%MAHiR2z$ooi^u(L$aDIR01c)EefBN$3cRurikR#aDP7ie{F=jdU& zB|c|wF$uTS8x%Etp<0~@pg@ih@i!AUC*v?HyMd1eZyd+duXvpgS~PXvIZt$+n9h5( z(win8){4sOX*k5F5&8x(`KFG+Q4c!G3=3+%?;DRama+01bo{E42W~+cQ#){@#yjR< zuEAn+-VIjDb2ySZ^CP-NN;A9c??3d~{W8OeF!8de*s8QC6TBqewwxr+o+<((wNcO&Ik#-Lnh221Z9OwfP!?B;U&5Te?v?9bC>B`ip4w6%;%%D zUX89W0D;D>66xLh?z5h+VM2NaoI0|bz^yfn*E{|0Bcb444%G%%gR{`3`q>%Uki zaB1Kj%h#!&Y?2k3G?yg2zdMdzai3SMasNeHQ`)+SDYUb5bC?~-Wo!4SA2B;SY)7?O zRL2)5!qWB-hIniKwXI#zT;7zeVNI&0WTv~8Ys|8Iy|97MEGg7AI^DbzRJUGVGw-%J zS%4|FdSkylx%au@*hbuAaWg+ymUY_xX-{PNNS_zj^GlGovAiAG=fFhiYX{p=TxTE~gsFJG8Xb zqYhwaZCpnj-CeGKdqMZq^1-=L^O@^S72ubvv*N|J*L9uqzYUjdo}ajo1QG=06vk zG7~Ho|5aZ)b-&kb`#Wp11gO~>IL2SO*yECzh&x)KH9aGw7Cg|O6zfW(pRhJZvW#l&&MiKRaeoYY6AQ+(~{OEnIqh;No{rhfazK z)`up#qMk*C&0IsM$xc0IUQgvjJ*<0`#8Fk-Gl!{s$_3@%>OwR5Vh-74EM9bHz%++*X7WylKI0(O2Ja`Dc2J_LE-h_|JJR9yi&; z!22nSr-LqDPGYWJ{ZMM8>&%64R>9o!mWfgukyaUL972_Bs7d#IFm`rqvP?FtaBz#i z(s}4!l^Eo$pV zFZFf{Zqm2{JhpMpx_WUbG5@#@t>0xJ=_?z_EIk3j$*c*I6=)%AZ?i*>ty0Z6FsEVn0h0w-u&AC$qUB8x&+)yo(idy3*y-A7W`dJg#{J9tH8 zizOY|>qx7{qtf;4dSBLs>?D9UFdS5HhmASXT4% zvhS^SYv1cww%Uz5%m;0cJFaLn=^O(TPVq?@$<^46ybgL}I067Rbb0lm^8PAoe82_~ z+Zjv4dD^DvA0A+gGfj>JL)t*4Es%2Y(qtvf+n@z^Z5C1`hWb z42x5Iz29|EXzr&jr@PRSuYKyerq3(xws*Vgkg%6sTB3?^f0E3E`PeTfekS12%@DCL zhVcYPUj1{aZ+04tt*I`IR}mC>Oi70Wn?G~c+e>ZrS^KiPv`lGlz!3-UuCTlB9-?uC zCPm(nGId;;glSiCYtV&K^3@3RX_t$`+QtPHL$V*tcQzY__;mB_b#YE{%Z>ObnevlE z+vsA)h;p^e=RZax=RU#jz}7o@8irpJgnrO)dS9!-EU}y5220IH&JisJ*-?ve@p`L1 zb>*!5rv2Ot@c^^@PiRRpFn4e#l=C3Ybw5r6Soih}1!s*Yyoqy!@u>_EKf|spdHf;{QNQl>k`BRe#T1QOm#5aGNU=@_ftp)Fx%%MSS(Adzkhq=L&CC zqGf@!$j7i^SH2p+H_=F(LcmWSwf5WRfi`OZHi2Bpq1E=O^{3k1-{pz`xITR+_*3Go zJH@UYIy<)Q8a(6rQP*sY?0eKbx|e`7^Ts5>@~(sL*NJ`m4{?0PKUnEjF^j^vE>5h> zvffFO0y6U>H?}v6G6~H?re!5o9o5W*m;!yf9jb<&+hxCsItY64+qDCcw{nW1IAQBr zk$$%74Ngyo=~7IF{+m2(F`M@itm8_oSwez!Vf}7Sgy*v))x%xa+!9>?xcvSBYe@7h zbFD#mwD2Dm0g$;)+gxu@U4*nk+Q?gNlrp6a?rAW*LM3z27oW}i@)q95QTc$Smann~=Q?VY-|zutBKkTBjeukZk~*gW`4vZmTa;4Qd- z8CbT4%K+o1jhrRlo9M&@Vi+Po%Ejw*oWDDFGm!`PY3=23CksZUx5pa2ds6#%J;!k< zRBkEZL!zhtGG%6!O@;l0`77eMRbl<_9O8%I=As35bf1-qO(Ji=?ZUe9sKe!5->RL7 z#O)MG8ybNmcE*FYWYpvFQ(TCCRNnhe-tkEKe{K!AwBTs=i(SRlq9}E-_rh8;x1#s% z4~_bjGwUtSPdR3Uxb`n5-H^rzY-pO^Y`=Z4*fM51%AsW=>4$=a%hv$Rg&o! z?dlTE+WWMobg#_Z%Ce@Ati*KF<6m41iGD$=bGQcFGc;5=$AuycKxmc@M*{Vsc0tl*w5}-Xusf_<8;y4(8?Gu8z|vel|CTI72&a_~(gXfP z6a)Pf7%?IYM{9Xtv0`7;vH?0{(@@g?kcoj)sP@_YL^MdFY#F#J`VdU+gXaIxAb`D3 z+~MiQI}rc>{`TiHd|+}epuPX5D*_9Biy(3$mh2w0X6Aq#v{-8Yd$InXUMz_xDmxSJ zo>C2t)TD{#xFWom@4p;vFpz5WF<2|t58PVBp=KM&e}2xu1E-_L2i0VTe?v+JvTo@B zf7-#G4qCBl;AQ$FZYe+LFn)7gHmG4xT^|^_3LI)!@r$KUEbY?aRb8VeHuXDJKZpjv z`-y?~ht}%WKcKf8{OD3}iD#y9wUZHPCze;jsvyiv1v$AbS?w zmW0v^n&neUCn5?hFm#fNMeVn!r!bx*Jrj=eg0mxdt(Rch_m|EYu`6$pnoK#oW+ zxXI*g(y+Y7VmG+BW;TU+evC9wI#|%F=titGbHA|NYKhx!_a8zwzAJy1kgzxUa{JS5 z?mKAO>M#&0jAV0FBR!V{7=a&`dcheUL~Mu264D+VLHX8alL2A;bXN_$(yb1n>NZ}+ z<_uT=X4Im-9(GcJZboDwX+}h9p}+q} zGG)biQ`5zShWSzHev$t1e(5?pL582+j)U3WIjiF}-Pt)MMYp|^>Cq+Sy2J3&#Php3 zg+3lV^(;HxrVQ`m8^n%#s)%k9lPS3K!?WqvRpA*|#<;m&%S`~qr=5AAc_dn1`Psgz z&JYDy+z(R=hTF~;AH}#DAfNIJ)uFohuD;CmJ=o$WI^%0N_hFksBXPQA1l;En5A3Kf zD+k;p6VIVVaM*$AT2lN7)Q^!@ZrsfE&=v*TBFfI`OL(u1iqaqXG1g@eBN~ruGC=Fq zd>jfZTCv#7D72s5o$}2;+`aE}pl3bTYK+;AOcPZ?xMhHZ4S9>ZWMqDqKx9-z5FcQm zy(g|JfGgB?b&EssM@RLGPzKTBxK%zuO!2$>1v=FJq*H4fv#a=^d!~W;Zu~0ldv;b< zbH>~MCp3y zU4LqBfybuld%_j+rB->(>HL_wVq4qyH<3w)G8XBFGT!OMleMwGi%PQRbdKb?5`CkZ zlpKsff|a3{b`A9vF)+-~E(`YxT{w5o%iJn|$O%^C@N548@o*uLV5;LlG)xdo$s2#& zRuYy^S8q`J^t@f|<2RulIW&A^7ld5qyDF}V9EaK;2)jPml{~7S{_dQpVPdT=ChWOh zQgN8t>ENhscpLO`Q!L;mbuhFzFS4K*GKy#o=uEkptghqRnML`8u-Ua^VtgXlwob85 zV>^0LUk!)tXZi`=QVn@tS!&Wfr>3udh$hQs9~;b}zM=(MJU1wE+WaDX7MrSsH9$J2 z3P0j7e#eOTsu<2>lZ&=TdODVBNBq3>e5n^TncLW0ZX57{G23uV7{~OwA-|TzuS8x! z)YtK3QpxE0`q06Kb15!A4{vdVYnu;Jm{TdvNfU8?QRQ<c-gydNA4HiInro%$Q4 zNHz;x_~G&MAg_x2iU2upc#&c*J+ceq`}wSu0XITeL1ico%6|C#%XLeiECV1X%YOp& zagsBd2aLLeG$ZF}G$6s7%IF+T#77MHb%5#i_!UyHK3O0i0C@JPm7}1aLDbYFH$X#7 zR0ughUjmRji-$v7^%XRhJJs6BG$iF9jUof{b5W6#1AHIO$#e?Ap$U3{20`xE2X-^# z=0TpxIneo8QabYXQ*E~CPrxQzH5h7l;*6#RuR4?D^3jtZKGH!SD-`DTBtWSbS2e2D z$ljiTrZHu+r2)E^f?`C@Mi0vOg6A4#1#hMh9K2xgv!puOe53(#SD}wXO>|R5K;SI5 zX2$bm>MInaCD#xtr^KKJzz~>DCciI;;Uv}I0s%(gXMkL|oQ^{9N6a*%p@ z^BPzSKq;4~|MOry6fiB5DIE*M$4S^j?ub) zv#UV^f4}Va7L4)9W6(M^)ax3wPJbWGvVeD!?&h5dkb49jEv=Q<;(x~x3bix6nV82w zQUxhdx@|co(D43z^&<&Hzh}VT=Fni-{%w%VF9~!J>k>TplKKiXkI)~+!aDy>>>0E^ zNj`4|5gfYEvYpc(Yu@bHFJTsh_aZ8nnd9>Sb|4Y_glbj zf;T}QYEU2jjwJ?Uv**BgjW}~X{#_F?KPa5><|Xjj-$VCbOX(a5+Ue%hIfeL`1sRn1 z+}id2Hb_m<90Hy}9QM4Q5kzkMmfD5?8OuW`Gw%#Ew*R8aKSPo02DH;I(PRtuf*$OJ z!rV2+f9Lk`7DQKS4ehp^(frU{Ugs_S*M9Rs+x!@ejRO#}{LGzy7V9N-n*?Y_B1n&d z%r6~mKt|RWkHx=pqvM74dr@3pkklDklY(gNx_>t=K<+en$aDex-2`pC)L*iK_Dur9 zFkhg~J<0h{3p}EWtFg@cXKsGe(2=@zcscjATmf{~(3j-s{%0&%;26oj0%QBj;?MrO zSO|^QdRHfV*ildi>cQOYDu?>RZk{d z)dZ&}iWCwtKi~}jmwtn=wM!g0ABKja74xM8sQh+6B17J8Q ze8Dd}3&X`09RPH*-OU$NKdu9*;RR0-Dr9tgfO1|hF^=$%E}aEE?SHFFA6yx)F+Bn( zcBUu*gL$p;2Vd?$si>_9AXRhu#{*f9P(%W{$MEUrxPt26-_O@DSg>2VG=g)GF-6pq zrXvvr;aeG(pIEJp0$4ktGLVbkfF8BYMLIRXly3eoAIwn!Ezu}Ueml#abPQnld`f;I z&Lc6O@5k@)06=16An^szWm#ChgO-UKv2=2`UriF(zPGWUE(HKh81!tCU6;O*h+YMZ z?XJQk1io3bQf+s{?t4%?3qjbHr)_H<@A4zPfT}!b68nfiGZx{ zD!G(I9Tz|wZ>dQZlHE+)kB<)ByWhq?L=O&SigZvbTO{S5RdgMzdU9ZTR0tzD{=VIo@P64WzV71Kb4kL$*Y1 zO{mW+Bmi^%Yto}nipg$WqC=ZkACV0Z0HuO%lQ=a4m0;zhzr>R}+6?DO>~Wp|H<#iMX23OuL@S#{ zhWo)GHM9%QXGWB!<1>(l_UWIoR3}*K~;#O-s#x;*Pa4^fd;{f zVRJ^qjYcZjVNeIj!42n)7A%tM!nE|HNMqFi-i4DdfCIpfx%9jqyCjdU|8ZZa&Jsc~ zX7$;f8vO8^xY}R{^2G3<;y`}ocDP7)(JRW^R|@4>Spbl6+vF=y!QwOyfV6-3_QkHS z4zoS(W@_k3C~rK@R86!7sOm+a93K|I;2=TG2sFS-9eSr{9ug|!1wa5G61&a-U{QLU zRL5Gwu2r{zl@;RW=Pw0y(Ym1n$rO=b>vu@>uQU~9e3O7lU8;WZprC$#i9Y`NHHX?Y zMF_LF++lo_J39wIXB(Vr^0_4p7?YR9E}T{ zB>?^2%Hw{sD|Nj^l(ZPNNkD6YO^Ut+Olw9lw`vLi-CmGq<$R=_hT~0s9*Zpcb_O*a z!plVB0FWpACfT1g!5Bl{+mFbAjD8E|LDwPUA%Mzsae1uDg_QvOV>HP)Y++h4Uy&AuO-MX)-MBK90=OvSKzwn!}-t<99rA3q!n5c3P@Oz+ARlw2I2)}eJTs= z0OQ!zHiB^jaDy&3uitkJEn^h$5#kd?jtz%m(JIPUU?8ZnVLGHIq%|gatqE4C4ou;W|!ahoTXs01ZZ{MyGi>|x0kY_zrUs9 zjJ6nkIgGX)y}Fuv47_5L(aFXt70W;QlY>44S@Q zk|Cc<;_BtZLM{N}maYJ}!)JvlWuD#18w1OJ=Vmi$0^>SBO%#dNZsV^U2gt_Xd`M5C zx)MZ!`m>M#HK_vYP$MW0qkh~NL`CH~Jp?Wj>6`J3u4ScQ#v@ko#tiaP07`_$z7n9_ z5&-;e1^7&?toT=Y*eHeg*uxkx48UP#mi6%pR-AGPI5*_N{{6KwJ*ii}s(Ajdqc`d@ zPdfzBM%2c`RP*7qr1sTEGiM*=7%GZuhyk`s6R4DZq>q1{XN zXDC@Njc%;PvrsP{93Bx@vEY!idm&QS>_DlHQ*6)ffs7kvBd2et?*vN&Y*aHNf!g2S z(^8%fBg=Xf<47NC%MMV<9$Y`LzO0_YLMlLz+8WS|D>6ow4?-0m&mVn$(S$rY*yFsd zscFBwIeERbmCZB!8LA5~kBO@P3!>NxQ+6u^zd|fAA7|@VPZ%|?VJ|Fc9^>z(u4!BeHUe3X(7s>JF^BZP3OqvS@T_>QxcV+DoS! zcQ3#mgi`kvb1X~Zi|%sFq_Dl={{F0ivpEB93~Kq^xn&G6!_$n@=`vG1a*&l%f&YuE zHxGyM`{RepI`$bvvds)x%9NYM_3)xWFkg-HoEo0zA6aaOwDBAy% zLL0B{cW%$dk9SBjN)33|s3&aDWk#1bo<-2g5rQD4Nx&w^sl%yjU3h;r2q% zr>t$n!2XY)-mB!f81gQr=oonRG*|vnq`Gn{bdlNrynt*=xkL}s>P3|`Ftpr$zh6CE zH5sb%tcQLkljO^^^mpm7;pAd~?`Q-(kfKki?%%;sR$8S!z8M9DkVHSFT7k{|wR3TY zkcNV~1VW1-kLTWB@4CVE`?((KZE~6xPMvXIEh`P>8S*H|wpQ28Dy<1b_E5x!z}LWr zEZScLc9=xy+2?Pr_}}uoQ&onPFw~K;l6ynpkj0Cm@rPasRNsYFR;9(=n(!vGrE_;eyMK;K95(- zyo8Ra`~*y~u@<)O<8;EQP^4-WoyP4VeuNKr#c+=tB}t(!wUs>%c3>=+GCu;fBZ5^+ zL!E51f?W^Z|D7}~15t3ag#W-x+pa~1+#51K(7`=-Bb&c~{Fls`1${z*6W)0%sFxqj zJ)4M$B*DfbhoWv9TnZM*g>@I1!$^E8(Z_Gu5v$sRp-?(1{!C%~`^CaeG!Cw>yOtS* zvjh$f%?x)x*mMTH@^9`kU`NQs zr16|*2Gsry`7F`+HOb6xfd!c3n0+g_bx{lQPx@|m%)WFR51Xw$BC4wfMU(8XTPi60 z9c>Lops&FTx+Yo~{Bjasiq}Q#`C=75vLU+c`{m}6Uy5e3rKi7KE@9Ik-Y~%<)hTqp zZf;A}+5O>}3AfjMa+!gE2;a^K`GJ0nw;VPK$xgFQ9tgE*GL@T-h^%g zZyTinEI+&g?PA|d&Aj*AKYIv)f*0+D4qW`o(2IX3NRNBB`8i@VCJvk^mZ0B|=Q`=+ zC+|+qL`(8Xgb_4@zzBu1q}eAvqXC?mn`+96v%urzCQ?hnVxM_ZsO8lm*ZUga-Tv@K z*lfB&OZV{$2w11Rfwnd13*O}8mZKq#U`8w9W{FS@p*ef+93~kL4bXf^@1`>hOr%4l z?2h)1@jiy7GaHNbrUCRE;7J$sFt4r+=8t-V^T_GxufyTb_q-t33*dxjNLlEa0~I+7 zw!F=$IdE1^(u`VqY#0g6cx8u48Mx3cCsU$N6Zj|j(PJuz%s#=)u-wR_L9gs9Kb$(; z*%7gmRYK^aet)q^<1vTKaSlheOn;0k{K9iQoOP;N>EhvXb)YFQF+$9o%>j;dCU}a% zS7Ieg1RpTrS_u!Ru!1XMuks<;dhM5%RH0VV3$1b|J&a1C03;l|>hqnTje?JgLA0+v z7Y@>)r?ss&#SP3UqBX_r;l+9N?^QDe@z(}9f2K!Y;-~FuS36uTX;ialJD^|J#EF*; z7@qsd#!I0Y7X&+txTN7JU>c0*)qlxl4dKAC&Ym%c4I5d8oxAk$A(&Kh&}0OXG8{kS zV^UeG8$9#?CzW29EW)xB4{ak654fm=X4QBxATW|UriJg8;$6#$v!Y_lBk?K8na z-s$D|wRP?#bsh06c&p9_&D&e1w~F$YN8AmH~m~~BKQ)j`- z`RrU$mEo|W+YB)VjbDqU(s-gRMm*=p4Yea^8~#$xXPTCA=*zO;pGz(+G8%Yt7YCI^ zmHu1k7luU4IVn@6d$BeTM$TyD1!-H$F)Oe+U^b&c4|Qa&)yw$FO;L5(dSQ?VRuXHp3Jg- zf|QumfxuW=MP^g4q9yC#zYw=--vk^C`y8)Ipk%ORt5Q4b(El9_(hPouo)*Ks)G%IR0TSH?aY&&dpm$Y z6Gk;3GxyS}MyLxrU%Vx(DvUd2>p+|n`sO9QSJWz~Pi>t~B^Wm&a{{5Hw}FME$B13* zFM>XUw%&^;D147!tOEY?G}urP8Kys#}US50k-gyJN%P)|c%7yKZjQs30?d(mTO{+rcxov$Ifc9(otohFyQ zt?PHai4P}fwk8@6wt7kTGdWnNJ?FIjx=(pc$Pabl{{2tUcWIX>@dZ+jOC_6G*FGv$ zGAGc9-W<6e#mZ1uM4O<`pIVb$T$U}d-9jwoPPAG?Fum~PUSBUeC!1fNJ=8B0+<-Ku zcFJMHo?Z(S7orHeP52$1aRKn?;Lw4Asgi@Og1 zK+CA6@Z}r;5dl6+L(d6*a?`&TVr&$?xC;G{e6b#6ju%|%NF8vZ`BQ&I0bmorpp;=`A?x(P_1ARR z8ZtJ`-wyckp(T%D6ad0NTfcK9gR>@+?N<;4Z}PiO2~2|i_xk`S$;d7Nt`fGy{YZ#v zlZ+Y%!GXsdOZQVPfQ^D?7q&?YZVfB$`Laf;o)zYJW&nPrhz3=;Nf4JmW%V{AHUN)o zfNkB&=>ak;_RJ!N{4uiSQX1kOwHFyR`R|{%GsqtkJ}7fBMrQ4h7WBc#ibKK2FhJc@ zMn=p2`{!-)01Q+!Jbj{Gr`7&a^lnHR$RVr%(Mp96ECocmcFf-X8`Pv4Nw8WsY%ae80Gz{zwT@HZE7(7U zZe2uOkL7VlQ}inCNECi}#%rZ)Xk^gXCGFu94GW(Wo3MT<$jxX4_&^d|?g7}KEt-$^ zw^s5>x{HC7W8_1e>Qi8JSxv6%t`)6;_>4l}WZf|cg3i@n8YoOt0YKy{8T~1HwgzfM zfZoJm)LGKI^>x{%n+} z+p`)4<#WH)`r? zym}>D{L#3)^oKW)A(&cqI32uu;PoT@T7TXCoV8;~ch#Ws2F0<*g!18^**K?(v2W$A zt=z_mVV8Tp-#T8AKipXQ>ePENsr3G!*{6}6U@n=~Z2fenFD`|RY6ZM9?pZ&QRYo5e z2OqEV%3w2Uk6*voTi3i?;qLft^HO;uW^{DsrlhH}Qq{XZ@u;#Tyu zhgX_-|4Fu^xsno%Z?ANl&GVS=#;n!uj-+1m2!VV9d7e*szo`$TdiLp-H_~vEB8AiK zZ%Ta2dcmin2=#}6U<3Yi`54&QjNp@R`2bkOuKTM+>ZM{v9Cm;c=jbi@aU0RbCp^M{;k1z=1P83w*n&tYVN&3pTD?PRdkCz3GoF5ADDTqs_+ikL{^cl-R}bfZmu zAmys_Q-Sc{^98F1>*~hADb6Je5f_GJ{fH1H|BAGgx5DYgvT`G&)uo9aa-?TUqn=5o z&Vw;rm{q=Nno-H>wX>t1^QM=6o!YON?KG6BIHie~mlnh+KmDZ=VD3NT=3ly-kJ*Zr z9QDo!viiyxK#Z;4-hAG1U%R4&&brm;>%;Jo43GJdbJ~2i=C!9m4Ne_TlFH)DxG#*X zo{$pDyE%-{Q;3$Awek)zy&_}v-Dl$+VNEvbWW!}(w21+g6tXJ-O3&v-HjJAiby+QEHK7C1!(;;K@aGOCRYbG!XOEJm8C*eMJe&fIe)CP*_ zYaHW)EXs{KvElm2fk7Zi$ggks1K|XfNk*rGl`oqEz{7P73_3qL zo%7)EPl^l8Sm6S|(dc0mM;i5!Xhg`f`eV$f&+H3IU*QX(XSh`Zd_E`c=&K!X-+q!k z)Z4AEw8BnhI%dF$81Mx_XGV`6J^DKYW(jwu4W6K~LlVHVJ2e=P=1+sc16b}5&R~oe z!(R>y5(5=P<5v(483+}L7Aw|ixYRlge&K(KXRnUxmI|st$XzYRauzZEgEpTp@o~A6 z1MoU67OxoVV^)|t<3An7nFo+VjX6`#UM*1pUlJMJ4pT$F2T7~85qy634KPIbI(p1d z*av!1<9V;-0iDpo$Ub;>&6UUtM4#WM0EY%jNeJI}P#bWzvRO&-&2P((`&AU=@3Gc6vX51VpK)z|S3@%H^Ek}iK9vg!fFHcv+8G<)QT$^xdPti6v2r^7Mbdd~ zHnt-1Yn7t1g=m0xMx$oFRvyw5(F`UjRF=khgrNK=Qv>FQ(`UwhcJg#p25kLoKX zio#N4OVol+RnR7{jcmCN7ms)Iwy=lBacvo;W%85AQu&4XjO9h^xFXwVi3>#TIgxVN zj5o5xa&qVQ%Qp@L2#aR4p-X7%^2w!Gu+8S9_`a+l$khaSWc`3UfsQUbPh$e{9DoB3 zZ>GaNHFw~jl1+BO+@qekj;2Y_y}^QWULE^}0ch95r~q|F#CqxP9`WTKqM42?6@NUj zD@d7vSvL^CL(A#@tJ26bT?qmx_%t5g4!6mu+i;=c%Fu+so`RCnKx?~oqXxj8&iQ47 zxmRX1($IcT1vGO5ci&CHMUeki4$yvD#^h@eKK-=qe*p>#?fU|~mu%MdkMIQIJZ7*u zuVmQsmp_D-e=9;31yMhkUoZ*a|KttR2+a!}ZNO4qKB66N{fZ8RACsd2b(Tf|w&euw zj9D-(WGeDF)}9zqff)Q(G0IAws9iH<%ZH!2h~bfnYQdH*GXgEn_P6I!ro zg$zhrTYkwe&mAy7$aty@9M>gC<;~1WB!J~{_Q7wCb+WgiGvd^3Z)Gj=8QQa!dul_x_)8M5NbM%S$Nrm6|64EeppzydD}`H@{e3PI*@JYS2hv z;2&`%&?!z}B&^>2Xf3p{JDO(9A!WI=#EWES;8^?T@y@w_%K7Y8#QN-jMr zO=ZB0W=L^+)mk7T*j|%ASPU%><#;*2T08ps@iX7ir#-b@TJ11irQwUTywJKyr=jt@ zX6L|_=7(nG3wN_gd@HfV^67qk2bj8_t3JD-H$<)Y>kgur>UQ~*>UW(n218#i4c|Cc zdvTzO)}HVUDioi{3`_IU?76K*9dkYC=uYA96GuOixFmCt)|(vO%>aa)N!ed8s!z^ z7-N9`jZ?&j-`24Grk1z_7G+-0I-R7@;J#vmFS?yR{1nLzRT$Y$4d`pH!mM0C-_avJ zwUR`&+Lg_k1mhS5IZ|LFOjb<)mkV%_;DMJxy}(m1Jc7gur~4qgHV^Yud+BgY6iio^ zr~wRsAKtk~Ev=J*7{#ZrI|Z(OgKA`s18C`CDa#*7@hRAH5Vf zY|w$xyGb+$o<=>L1t8y0-$x)$l=4yBP&?7l)&w^tj7vR?(;*zbs`DjM!E_Ou%_>me zT_q!F2`&S)xyT+*-XN)7UALIve9_d|$G`5^qUx&LwFXW6MP&(UT7+u(Q`QK&$*F6KBN(RT6LOQiA z{||8+3T;U_t!$|9cD6g`kclzgts+fo{6NRVFY@I@?td>sHz9(b9#^rpnC>to4UL6d6F&U4E@OL~elyeA!GvX3om&AFb| z$MU<_t=5E^9uC04I_n*(gKh9$9PJq#v!8{d;C~DzdnaSR{k0km*sbT=$+8OE9sX3l z*C)O_w4r7^ue3^!*{NS^OT-!rlg@1yo^gY+PpJ~DECGd1Tz9P<< zU~ju$G)x^E9jfr~cK`!}HCV&jyoACv9&!276TyFcrkcq@NSilT53~G7Y??j z+{@A#ANr6|yF+Bd^lwRySltwVVjjF+_fKJ;2-gWwk;*P4 z#Bx_4mQnQKz^@%*qH~{t+HlW@x{58oaoepwU33}zz3&r`*MBF;Ep|$x_$RrJQvX$N z&)h&}d4FOqU-Vm|R+{z9V+pUZsW2sV900+Y5!;oi&6_JpMb?@s%2zWMgZ-ggW_ad! z)^PEgrS>pPQ>63785yT_i|U0i&dYtHcvm>Qre$$I5x=lv1VOY`6|Yx&1&XxH*d zm(!n&R*S?R@@1WC!BS}KjT~~-THzs%Qm4LhGZ$tvkYTOt0oTonR$t#6qbuzhk?}YN ztLX#eKd7qhb|O-cgR?Zb!;2sTxtt@OMHwH$s*QrGt48w!B)d3y#P}7&EprV?^lppN zf-KqMW2H22EnY4e$BPf<62rKHZNFK^H|`$sBQ$TE+be!R8KS$P0}*`VB{~r#Mlb{r zl1T(4@-T7=UNw-Z6-}U_jkJBiDC$D01l*SUcqpgR9^M|OT@$cEg(M!&qf`FUJ444U zUqmNu%(g}BKxt#nty132JfBC2Fx1enDdcDpK!EwR_&hDERys(RcFwd}h}LYKX(58V zN{33lo8mms%0>ceHx#sqpDq|2rGo%;DDo=gD(>=(kSNCEABa^W^UvhTJWfOSKc9@z<}dB^ zmDAMXOI|G|41(~(65iDuFT?#;C;XcpGn(B{JC*t_p=ePbj3*2_=AR>K)d=BE`CS(m z2A}@>rTO&HspT4thWmyFtYHMy)V~CztmU@-;YoClGpQtW zd7RT6f@HdLHpkU?SMiTR^>j>s-j9(bQlnj(>2&0-SpWjUOB@t-sk>9e7k1DFy1V!@ zuxrCk72{5;sn_HJzu)8bS^9x#`fchonK){vxWi5KBJ=!O1MtvEUIurFXh?tt4Z@FL zHK`Ff<_qC?@2-f%)riFRWKYnrJZ+{Bi8vED`H$iB z<5Rn6@p6c$QyvS2WFHk5H=g>S8uXWG&xR5*oe!Q{Xybf>BX>StFu?N-{sbu{mmycE z6zUlOvo)ZgbMY-15TuZ4SL-E=hSyo%1cZZ+ms6?C4+mrr_wBpnC+|hQfwSvKMrq+c zT|=Nqy}7f_6{Cy6J!gE0jo^(Cw7(jwjtiXB4&>(u5*9!#pdlgQr6MEB-yG$+cULNQ zh6^h~YrQewYLFrEmsn?JM7Zd3Zs2N8=Ge;Tu5^;ZN7ruC$xw~|YU5>-igX@7UKa=z zu~La-kmNMyOV*8oO2H|J2j|OgrmHxQMFVK&Bf!)A;_P z1}e8iy~G>Y&L69~KPXQa6o&sTF~k04vp$o$am@C?>AqZTlrb~`$-kiNV7-bb6{Hc4XJe$D5eM4pohJQLsK7oe;+h5!>;u{~H(Q-JN zZH6y~bTN07u5ILoW5GF0j^FNn=n~8BY`UPSe6%9NgelQa=c$Y;^E>y_c~>H|8T8Drl1;u7MZ~_ z&IgUT9^_y;Om|6D#?HJPJp#6$BmN=9kam`edtw8Xx(%P#v^Ys)*F2g-4#EH`Y~yG& z@7_m;Y5gZZGU&g0uAI4U^RvLpT*1Rp)wbi)OdkVXO;?kkz4zBgMt|>)^E1Z=)T}wn z{Vh;xE^h<{oxk34z+5lJD`LwDV4FF{S{H+MuRSz%_EtNn{P9+0^sT(}0gH5k0nG4k z!FriU))t`&g&4oC1!1S4P*uIg88IM%e3+Mm{2{?V`u7hjC7EgZrAmfuVaRl&i>m0> z%JWW%d{3=5)rwJ!^KSkgFz`1kxg2+J%K7JUiqq4ywHhU{Cfmaiu%+79ngz)&7ypJu zdH78vT;Yx0QkoeM>}xU$T<(qX{Hnm~*jnmf8Gm?7vW8v%mYudJhi}D_=lhkRlb5dD zbipOf?D0%g-Iq=uD~a6}&V1hfRsrL*r#4DCIrPCFuX>v#=RLMNc_012N-10KtbfzDNP`HaKUC8f`C|G0%s+@6p+qF6`2KPG&l*=B$VNiNrDsTsv3 z5}!LB)o@TnbE+{)Cu&R*3LO5%6C!9;9Jl6^IMX_9yWcw7nfcy-!?hc7e%RrQ_)3v# zEx-l*!dgg|f)VNx%A*;@`e8DcuS6O`ln?|-DxF_ehn9xZ=QHyD}T2vDoVjSBpO;oi4d%ABcDiuh?R#4JERB zhW(`1WEDEb{t0a4EjP!!Xb6%WUywR<4{Bxm!%~ zBmDh#=VwAoU+|?Vl5`_@S-X1fD{|~Fq1_?{ea!scPyaTi^nhnX0rs|$S|c|2Wk7yP zhx|d_p~VsB_cb6*ofJ@Cxd_^8y>EbYgWPnoRCLLCAz!io`*-=z5QYb={Lh@rL1R6A zIKIQ1JChePY$^OcKwR$AEsT_vykPe|cv3p$66sbugK{|JLmgU zW2o~CG4jzCuXEuOsgup(t}C55-VdZ4@r*F%7i2=ED<7j$s3mRmSYmYxVtY6@N#+^J zA!fXdAonVoNK3`^;xzM+1o?)cntLI7|A49LtcHzc<_-4Ik! zWF~x*$He94i6YHz1*PSv-|=x-uZGzXK@X@I?1n9)Obf2Z@$q)&KmWTYSG})JZwy6( zG)*&wd$IYB*W$1*R7l@nI~yXbAp+&!pD>t~H|IM>8jRTr3#c6;%oI{fKNUC+{s}6t zcLp@9ik{H}bXg*9P{f++ljc8Rod#kJ3JL-@Z*sESD?R`r`UzmJ93mka;NV{BI# z9X#-r3u?DE9ckY-E1%Hv`6(2F%YQjsr=WVwa~5^!VussmdJ4+kL7=dQU#}@VmNfoX zeC~=}rt1n|u%2JE6T8Ae?v1Rc1On7Fv~Wv2T&Ap|U`Q7?a86^~{2_UMfj5Ga;vXIi zx=M(7M79hJLEvpaKM$fL(OrE)oX(ozq(@O(JTvUV-A|^b)R0K1Qn##yP&sHlV9z)M zwyGQuBuIsJB3uZ9wt+DE|7fP}by&79dIbW==J%dTE2Vc82rL@z?T84R;v4Bd1NP-p zAJr4cN%jRdIhJR(9i5&--3urqT8mzZ9?vNqxPhCEDB()F2DTAIat)_}|)OvR!p zXPBU!DUb>e0zHjvWm*vJf@7bFY+h90<(_%;D!6Z$r8j&4`4XN3D1bMhksYS5?HyB` z%ZucKzea4HeyyB|ny!ibAwQ{%PHB)=O{BWgxq55wwW`bmJPuBQI6UH3z9vIF?s@N@ zN{6aVz1Jg)*OtP;Jz8nQoD&-Z06~%I&c$wx=`*S)Jy={R?{0+78Nt-g>@p`u8U1~; z!$E3+Jj+}%X6L`E_-#XwZ}ECOqLBgtcrhK7Nj7TYv%+~#A2d5@JurL7Z4XX+(|t;? zo>omM;xlCQaMOQEjQ4=J8_RS&?;Yie{5~Hc=KffzDWt@N+W!lwGOhnF^4wgYc#l(y5epA7VuT#+Cku!`aJPF@Fl&a?*M2VtzUkstLdfTnG zupE)a`Vm1fhXesiF^WXtfzaqv{*BOj1s4jFYwuX3QT2#vf(!F~n=L4gJ7{*|Q$~=Y zNt-wRERhDrN(K9eu!VX$sW2e^@KI4!t83J#++wKtmZ1irf?P8a_yZrF(hY_hKv)l2 zk}t%R^{5_-1#s^EVsXz~#JS?G?jREs#1eu%9xGZ8jP3^Qi>?O%9JYtL`r511ouZPe zC8!-fFvw*OKY3wvGemqL)Cm@M#+I>Cov4=Af^u5tzW7%2Ug$lY`q&~po3I0bcqXlL ztLxo{uHvJ06NSRcuWc7so%E?KPEWPp3mUio@ZyT!Q(c@5Rieaq1lX1SkABmHe6V%I zdE5;aLQ)kqEMIoKWK_sN7uujfKTCm_r`n#I4|zJb1ROE*5KRxwM`=zB|y-XbUXW z6^2;oJ5~M4@a3ZHEI=uprgF#8+VJ!ly@I@dhU9z3vUCA|eNU0f32}?Qn7(%xg$wI} zsipqyW>i7*ShjlQ98qfM+o{2rAfFkoueW@f;!avbLvk?bRcKGfyw53rY2p#|uq%T& z^%@ve>WDruG~~Rsp0rGy`NlP(tbSXFj)2()7x9eP1rRH)goM~hjc z=Qi`|k$dm9!B}-@vejN$JQcb;roeASKL$_Mg0QzJA-s5~IQf3t=K@4p8>#kGx0> zuAt6j64i?$WZgwHW<`A5WQjj_@b-HUegzOjIU#Bn)1CvCx%to7^+p!-Tlk88O(Qgu zcQh_8a3_QP3Jz_8Pk^&S^(2_BV8wteJX&|S%H2vQ$kj{x?ZuF`Am@mG@Oe9QdcYlJ zWZcUN8$q0O2o(AKmB}F%KPBjusU)FOq{bmZ@CjlO6Kum2B0@9|CxQ#!$LbY)P{Utt zRbQqwpTvqBg64ZDq=^>dEg5sGm9r_-zj5d;3#R1Ww_d{wUv@^9Yoq2vo7Q92lE6yG^AuM>z6uwxR~9Ya#*PLqC{7o zyR+Dpz4X&WN#<)>?}+Fg0R$l@QC~49WI*wb@aCCFP`(S-FBE_Uit{R)kRHTQ!iqcX zs$bfK@Z^2GECj9chRNOq$Pwt)1pIbM7L;eHVncs8!N)OWZI{N zO4X6cPAd#$5WN9;2U2XQ-?u433*V_%DS0ijBN2G}HkoVb;C+dX*83WL7`~2N)QUQ{ zS7a8Z^O&c_0})MH?EeIspj~0Sdqq3n8RAiWUv*lnZqcErGX%E#{w3+2;Y7qbT&lON zascN7FN3Fn8IDv}I1u7|ey!OiZk7cr9lpoPKEC+R5N!DKhM9+Ej)}3KQ@`Iy3Iaz9 z>e{ZgA84HVU-&ds2hS;!1${X;!ZOM0`0>>Puv;LEjH=IUgrF0KSnk;U;qTL2y(Ve| zf%bXKB>w|=)nbT`Mmv0+U~2H{tZ3g4_+ZDsGjro@I|;kY->##3)$nW%=5;=tncri4 zQ)63}1Kl5rP=$>)*GFD})5D#zGGMYm(L;MFpKik>7|AVm-ZqdvUVsWQC;ciIs++T{ z{nFyDA+C_g+0bZ4Y4CmF9~}M+?tHK2jXSwI5RkFk`JkA9G4BM4$}PiFG`=lsF`S0q zb!1UpfOU@kWTgC~3@>4jA0>duK|_w+5Z9?F&0&EQv-g(F1H8o!8s4(Et6H%wJ0u?B z|01#*aDSP4Re~7Y4wIw6P&CtKVW+)a|FK`?)SbGn)<|onVR=@0&%>Zb>nifK)*4#; zQJ4NCbZ#%E2-hx<5VAM5<$3%&d1|&LF!lS_EGk<=pqAIr9r~a0@Jm&gdMsK0CEai> zSCtLc#C*TbkvZqm98uFp<^P&Sjc7q=Fn#5NSM!FlonRRd8kZ>imVFNXQ{U>^VKSK3Wv08E+ znu@`^_0E|Q%W=xgMASBA{XxiD7DR)+NQ$Qs+irDMAx!IM)`@!f1~o2``Y*ffHlhaY zeiW3++2MgQnPMF#2ZuM+ZX|Qv|0mqa)Z4IA0nx?mMMY~@K|h8sFIQTnUUVL)x^ZE5z{x ziTWI|V!2P5^Q8P0drYoA%FgX_Q%I_h?TcB8X~7@VAqijEavT!XoX&Nw-i1)w2I=-< z&mh8Q*k5JULT?{%yWH#&yE4->RBkKe4jhAMXszx(w5Or{W49(cBjKMd7(7 zX`?c}N5s%K37UtQ{z@>m8v5wW?=p~l#5Cg=G^@(&*f;t1;MXDGYI3?PPB@W48qoZY z_@6A6ZckAzB?ppYEko^9z2-@k6GoNzaLtj1{`+k%Ht2eCP^LxJs_*wZLhE}MxG^18 z(Z-o{=mwp;H`5~%bOWn|{*x?sBktq^9enLYpo9OPsRN$Xs)Sj&DDK_Lh|K;RhCk2Vv-}J_2Z1*7``s|Fzh7~b7|Ho%0#tO2m9DI`AMI|g#NGk z%F~W!A;(bdO;6WF3ng<*pp`hwY*ZO9&j=?chRK??B6l!0OUWYc#aU8LjCjgyiTqQm z;F=Q7wbYS=%dIjKba_JM?44zxn=q3T?r7Jo1(A#ZdxQed)lwj6{-u=gFHpao%$khg zan~W4B}Axzc; zb07xSR4tT&q;gLh6O9~?g71;5=f|!jjtbLi%(Pzk!KGxB#ib(Xgg?Z9cApcBO6xY4*(#*RZ|P-M#hiZ^@5YHA{;7M7&fH zFp_@=e6%wFk9oAah?mz`dvM#5z~DVl0kQm|$w#Vj^6~MAk~r)Tpisz)ZZ0MzrU!OB zDou7?h9U@dJCzX@9#VaGw0X}l<2D1Q97B`>Exx)RoE`q8k5`R`UK9DzLMLOhT-a2% zxPPfexqfekVH7+o%0Hu5 zjWI05-Iitu{yn+ZHqS#G9iRUIkxkI=*40^khBKPK_HVOOGD1d4;cMuYy3ZiWWH=#d zo-tz3?LcYX?5FCkn*?nH6RV}q@xP(weR}qc``RXzX`~(-8fRAt%1^di$r&F*>}S?% zH9~2QKcv4QY^n6n;HARs|A5MxC+IYQIsQ)!UANo2XWbw1T98Cpz}mQ_pqq-CJUU%C zU~v1|Euogw)FU<>z%jwev)x9795;KrMfO~p_D7$sobpJ2g1)cN7DCBYgbh7=Z97hG z{cf@9;!a{~BhhVZ3x&Vu%3^%^E=yh3`s&OP>rr$@|2ae|#tv&Z-%bZM{o!91;G6@*L5LVaDB%_X%>!*UEOY*#CIlhxp$h3XgUO)(hN`T3;h zlCbxB8*}5|{Rz5~RQg9sR!8oYh}jn<#)bUTZEMdduUunHtlLzYQVROA_e#blVLpH0 zPX}0VxCcB9c2hMl2wRzG$Ex?*Gm+E`*JUy@E!BbbfP0Lrr* z4~lw!mdel;P3lkQq-0?-`>brUf2Y`7NoG)4aNli9MG~ubLkNkZEZxJhl}){GY>tQ! zmJ~M&Ds9^(HDWDl@)j6alx&$77|Pw4C_*E61+o3ld@Wz_tEp};0U`p^C(Le|NR84tr# za=|+Z4a4s~ocFXwLTaF}?1k1dBo{!?Zj@+cmQ*RY__%p*<_Sd|AjCzdC0)n@M>52@ zsi@ni09T4D6gW;^$tSI}J4N*>$CR}6qxaqEC1{^*gmhI*_Pub{LS5Pa#W^ACbq;YP z2M(0^nie21JURi__y%5WG$I{pMO2g#>GyItORP%FH@5YmZwir(8}TK9jxykTspnMt8Y|>11uKp&3 zV{(I$$XwT^-!AwmLZFzGA898OF|?8TdlGGaeATC~J>ehGE?(*pg`9FUB9ZVcT^!Bg zlfEIg6?s9GmUexUZP+)wlkCLsN5KPI4ukD2oi9T{;@X|_?j*q zVps6HqQj>-?kHA=pQt^cWlL4h6f`71=Bf#WSK%DQO`!`@TDmfm)j2yll@9 z!je4yq(M_r-`e7)mThri;v-=`f(b*iWi7o8PYUd!G7<5cw1lK8Zrr`Er3^p3|Kco~ z5*;2Pg*ywH(9_cfFGFst>^<=2t+Ulb723y1<3teD)c(HHTS#hazI8Xtn$351HPSNF zu*{ylG)}v^?5<1Wq92*3 zb156|tpLKY`}@Fl{(5<245`&6W}d!Bkt&SMl!~qA4w?zmCwx!|o#{NDFV^UzG8nZoMk0d(y=M4ZUa+Bw$+q~hnwS^f;S%39nw{sq)>Ld0wLgEt=L zp0r>r`B7oJTx*)H^L%lY>*>?`(Wf)*`eVUJxvB3S%!WOO41G~=W|A4d{T|k`bZ2U8 zlTiY&L`HIeWgkJ#XWq~AY#uZhkIU`b?aQaLbjSOFmuWqli73?*)JnPbB%tvyiB5f_ zF-XeF#68#$=c=Om+n2dRc!ewDL0P$QE1O2E(&Ui7bTUobbXvDh7nOmlN8{OUK1-V! z)_M!hdP|%jicVjn8gk==MLY93^~sYo`kKu01x(Rb;C#GweEY_OC%14?3{9GEA9^*rJozSKv0^F?T=!J!KYb>pth^h;tkgY*S3T`X^S^tRxo2MQ_%vP_HQ^8PKqe6Hf#Wd$ z5Lj5ZFBEsKCC^{Nh1*Hu67A>&BZr^p@WSYW3_4PM+f`;RSQ4JvzOvf{*wI7jyQ_li zR_vT3AqrbDTXr-s_H^o;L5Fo7OV$Qml{?V%611w%bweooSmzdn672fX^+5N~6FA?S zypWf$oad#Vz6gJtrlsOZ&{i62lL_YvfP7XvEDXiuvLWi8PipD7qx;N}+&KqHrJWxx zLH!^F+KyHxIl}spv&Rd^5m}oPo_)&>HU!h7X-Agv>o`v5R#@DC{Epd{ANu&1>i&Jo4P6Ts9smL{=~^C4GMA!f)2u(^>kBJ zpZ+V!PC7kC9LK}vy-GQegieGGCr>4hO*IB<$A}jiaAXQj>GJO%BlEs-6lh!!sw}d- z$_<#GK#LVy1t-YDnqsI}Zb4+JkuM(4Q_q&nLA`>Ml|KgrLaZp=+gRe(0^CX@r}Qz* z(#@R|s0G1EQkWC4w(N zd}P)Uqf+ERSkQd?<44b;Z99SJ-sZ>tx1_;Bo}-+kX2Yj8#@qvRVlgHGrnI6Dpp?XO zB{DT8k^bh~tjt|9!L6_F z1j|$}Ix6~ngJMx)Y{zcWtvAoiG>A!m+d1OKG7f)Xso!6I;%;&iH}HGoVeqc4CQd3l zxi_K^m5aEHc0mj&JMN9zz4pa?WJRF)l=GwKFU|5H8rDK1!xdIU(jZtHgx+47!X1H& zF?Q4xv}ZLIAw6b6nqBmXednX0eW82eGHzO>9Eg?!=Aab9oe35_(z+AYbu0C^3>C#4 z&djx=y8d6Yy*#@Lq>ZDQ{abH^)-EAej`(|91-aNvvwVP%yL{tldYI7+YC+6kh`4tg z2KlsT-Y3C{Q1*z-^$|Q%t-?ydC*2Wo)&DfmQc;dLm*y##zOv1Rz>aToWj@^0+j;Otq2w6!c+cKXs2XZ)1z}4$&kFQuj z;<(^^a$P3s1N+!3A8y5puo&nF5MOdaac{072OaM{1ape?LyY_1MQ=lQSX1=dwSCwY z^8F+!4nEV^elv>NSptR6UT?4zngCZ+-K5yHj~iXBj-8`WLQ+5k`C2VB{9rcNN7oH6 zK`ku0^k6L4&GyjLP@BEDZED*hDA($j^8$FN<+hQ{Pf5NST*IUD9So}D=iw^!YN5t8 zK|-P^liR>TWM#j=0uSX+B*>u8QGFjut>lM>plhLL(53D3*#i-ieRRuVyGrfL`x?KP z4rA&iFUvUoD*h58{K}KXx(fY2OuczL)Y04jZyAg&Gsw;?_UvSrWekQy zq@wI(DMg9M&S30gDP$|DkVGUR`x@DjEj!tgeHr`j_#r!Loi*fHC7N=fA(=J_`0yOVZdxA8XVya@$a?@|&fx z3it7xFHHwTZ$ckn98}YXTMmQOSzeJT?$Ia9sC_}@`6JkucTTn*=%3eG{|v`U=F`9l zlfDyS0N@a;f#sgYm&}gP2-Qsbu+QoVd8jcrLil}1!`khdpOV++z}K2?!MfCX(#af) zWL7U>C{uB(@hz(1C+J}KN=+w$2c4a)+ScOJ&y*nB0wi$^%p_UVu0_ED^=d9}$mFJ) z;Z|O`889^ zoRgAgRmWy=N(QFonQN{41j~tGT*jj$m>ALgUHK0+%1qSe(ge5E^aJZ_c#uB^5{==F zmy@@V*714PGBMq;Xw{l^S@dYVvl>TwINCqMk|i_^O$E*EEIOAHc{~4yxxLZIMZ$4L=^PWbs~G+N4ZCdt!r=9kDmLR9I&|c8KsVl zzc;I6yYN%kx-2|nl&(`EW9g4_-Gg!YQ-eJh7eQ_`#1KZt3T2B)2^c~PT>{_>T<%9& zJA1NM>p+}H zxHB6?V)Djy*12+uHX&K&ZZ=%xNhle34GF?yGHaGo!h_M@CDj3x9VtAvZO)L zvH{}BhKs>>Vj0)Oqz#!z%@*)5ls!#hVK*(x{zo=dPnFScUY-9sKHf9-8$mK^$*Rp!);_6 z$_gjpYr2S^9rE(E*JX2QO)$4TvPM_z(^vOJ;r+c6;w?itMNu%mu9`~V^Jo^M{9%uB zDTtmlC^VAOpSMSYWO_V|LIwNJ+f3b+C>2tyiamHY)r z3@lC(zKL?xO`VWwEV(mZO6@GIl)q`=`iDa#r$i`@czJc{(LfmCl@u#p2qX53gU};w zM-8=~yXR@%M!rjU{lZ%BcGpXEH0){YYd}MA(k*2|w<*oG#A;Hq|7T zLOzqRw%;iX|I%fVXWndRKvr1(A4PkDdc-+H4W z#%RWxP!1B`ERB#mz`;DANJdLmm54l zWYYis`?{OsFHPyvX*$&>S|t{-IcnSSKR=^7Iw;AK|CQYr`+fLU#YCOEf(^qfW4*MZAL(#? zSMGrlKKa8;vgnV`1qoZquy|5vii1Lv-QmnA+vKfOiHH%y$gC=oVzqDSxMa1Y?BKDQ zw1T0Q+QTC9+j3=}AJ#@=aka!7s!N~&`-cA~1?{1V)J-)0iVQ$Zm3kCYRo80`D_zF_ z%u_ax`_QP2KZpKd!I!C8uOii5HPt0l!Ry>6XOf`BurE;M9_GOR9Tvc+Z{?jT6*0k^D|V(j2Ip4> z35!uNlWo4dL>syV8d; zgR>lZ*U$X$O+||RVcyG4SDxW11Tje8%)TbkN#bRV6h>JCI#_`jPbOV~ zgAk{Eo11#|4*XB>Fs2Ljj3>9Xm4!fwXP7$|N^dcriCony*BmA(&cPnFe9L@|eQ|y+ z?!HMfzOPT;>fh4k@;155Ex!`pM>n&0Cv1Sr$;7QpA`)5v{glhdux(H=OCGkrJ*BmI%*281o^-U&zTjCeVktYZ652mNA@sbW1 z8*LUhc%uK_0m#f}%i8&7kz&VKvr--Pig*qg^l)3jCP56Mx)9^Bh;|To7Qk~W(*Qr! zW1IsF;DIA+D`wvNWWwTW$bUC359AQ zJ$R43H3S~6AEtj;xV0Yf(iDcvyidN7Fht`4lZHI|K!j&x%2P>>u^%!`j}%*}aw~bf zJd1*b%%RPdc6f?v1Z2paaiXCVLFnfk+^lG7+sL$r8*8cboadhY>9s;%D_RS&)Sh4B zMnAh&tNbG~?13@^b4JOJhh#wq#Jm3JK#q)9rtS=TRUfqI_NDar>)e)6C3Y+nks{QX zrlCu49fvHY090=3cXhlq2)%D;UQ9aaz1gY}sd5cxbvZlDIlXvOBf~SvE;wj( zWr`cW=tBI@PEVOq$|hSS5;X3-%Ly>r6+6k0#*oskhu6r&)O4%-g)mcfB+xGjb*;DM z#gBQl?}KVPZprXWlnagqgC}ArmG7`+Slp#+W;Zqb3X`kv+B|qlD{Pau$(1urJ;{Dgl?bj3>C~#9djzs;ux6l zaECmq6gqwISc!BDGbY^6jEK0OH!vNh6wV0ryeRmkuzD~QR9yIvBqk}0K5-Epzm}A? zo=)HM5D*=?XD|W`r%7L_(!GNY?1C*j@-%U?In zz#r5PJAH&cO*IPtdO;kW;yR3N=jjufG_P-?HIX%aV|pCuA{Xz|?9i#=6qFx_ij+LWNOB-fP- z5CFB%bN%HCV;)Vm3Udq_nzy^sR4o>&&CtzMkY)zi?_KHw2|Wd2E(CTPRSJEthno|A zYvJm4mxa8QrXw`VUSBt4b$FP##1+_wT!f!vGb%IZeiZ*Q<}k$l zte!5H3mXg*AVEq)VNN`@2v=jQ2Ztw?P5ty}3;9XyYctpL$7iUnEw!r3!zGGRk!FVORS<;0`roeF_=n zKIYv)nc@0SZ=j~!F~qZ+OQOu9Q)T~@MRHMjNsQ&NrV`2-D@}Nd6vAE6*Qt&2(cG*l zfu)+k*p@Jl;p$jz+z*4#e4#kn)eFU<~uE0FLZ(CphpPm$-R9-x_t5mx42f=%s3HKdH9m=(V%t2S84ngnF*~dtam;EIw~z z`(>s8<2V3Gxq-WxD)*^wJ>#8AOO6PKZSeXawTb2g_3(5HLTWO45J|LtR&#Eq-Ax&i zW#QrEX>pliI;{OFZV&w|(u=F(qJX;aeNiK-89o9cCg+=G4eCCD9x7M%*BS>8tJJm? z?JCh8+*e~!O_~XnM}1S~tonbs0C^c&tf^&#m( zDYTNtu5{^;4{5eWMU=ece8i;XeY$ZBjDrgjo@(Y?;`6wrjdBQ$wy0~+iiSCP*FQQ< zO2TtoIY_>T9I@uOHl?2uR)-oT`h1M}o6j8rn{B5cnaw6IM!Fl;e;ZQ-IjaUs!4uw= z2mwBnDR1$LO9b-WT2WP053Lr%)HMifC$CKEMB=TAFn&iVkN1X`5!8O*3DUtI78M=t zr;x4skk<_@ZQo4jtbVd~GSm&bfO*LWYd6Oagx$X@s|USkea|XGZYGB3SMgoIZOcCw z;@%ct_HOd9w_D|KWm)pa!Cu$4tZLQ+F-tCNT8ViohR*maJ?~}5f|0Kfj&k_Aq0c>*04pqP-nkQf z?~2jKp1Hl`IGM!1Do=M;l<%z!msW589a@vR^AQbMKJ)CKl6|YqNcj)8{n%8`b~jUb zuxc_3_30(}J0-dCo2MZCqmWg7$1Y>E>kng?>&JV5%+qSE-y5~#P&rd-d2`5-KV5&ur}KTTCARV<@ugH-fG~8}1&R&K zeJ59_2aUbnt%GbSQGdjpaSQ;eX&2IkYsSITI_!KYPgK;dp2678s&iDlmM^-43Xd2@ z9wiT_+EFuA4Dw8ELQqLk0AtX*wERd5z1}^<@763;7ZEmR2C89T6ji!YfE1mh;k!8( z1K9aRmc5o?9}eFC7YWHVK?QJmJ@1xH0OIfPWkbauz`+8k7B_3Mh=0H?j#Z6f<;89z zy_Ek1;I;42PndI>GlL~21)m}I1W2$#vWg|y#VJ+{A9w%w)}-+E0{9IS2#eISH60)B zNp)U71}Yl^te~A=pa;o{Q=zV8MrQ0>tQ2xi-4*l)V-JKgJuphoZvFQQB_M?0v4Fkt zOoh5(FtN!?+}1BNvof&b2m{8a{`HoSt#wAbMd~9Ic9#mE;A8 zQrCKr6w~Jfy+8-C;*!wMpssk`x#j%Lav%e7{<_V7v`4CRY=O-wJQ!2rmUHT=Ia8HL zpk)!d=-!{#@e&~03bKGOfW&U$w+EnA2N>&eYXG56WL)U=Wmt%^=fcRaO<<`^9SC10 z3yloZvV3s;`F8gQlST@XYxxuCTz$x`au=DqfOKC`PeJd0@y_>@RBrjZ+kGn|Wg7kZ zi(FzYXB%%BAJI+);D&Kty)F!Jj#_Bx#evuV>TgEgQ+ye^9UsdK)PV-hEU*C%lFmYn zZl;E7(w=b%|8oi2h3jlf-gdY3daDphqCGqRY;I;n`T1XD=1Z>xX0oWAin>(nhp=ajxpG%;#LJce@_u=(j zhG);ulN>BZvj*{_&UBTc6Av;c7Ue~8F4kse@0ZD%()vm#{( z01AF6Dk_>g;C*6_&dVGB*i8?9@gGcJW!NLTY%EUl>h&zl%Rm^1^3&M31K*ms)BB&U zWXUwWJ(3xJYjoQ5+|vIcw_+gXnB&b2V8q}NFJ0i~AQdVwTiJ8oo?fzY>LZZaU;$6k z>&aB!`nI{b`GkgnWBpcziV!?WLLereFN%nM^xW_~1ubMgHTAb1zwYR}$%IcmwZ{{; zJ`Q|Wn0PFAZ>+NPj3`(E5cd&v8H($=n^cV>z0}vVW9PbKw?rK_ z*Y$uKH2>4!l`!O;dsFoxEFin(7!=Xg)h&P|!i78ipa#|O>RsC*AO|KLS*Xg$9D)es zbN`~YnP%lN9X<%?71SeoUO{rb zpcK5HEUQpbUIa360KV;S=f{6F=Xkly>IOLf`%Nw+=;O7C<2^7-Sowg2!QGFAU%>nx zB!2Wd^1s$yallUjH!~r0z?by1?Xx9~naQu_284PW|$s#mb%8b;Rmf{rs@6VRtnuMeECMNbVuxvcZ`w9Rh5WR%|v2GuT zl846>xBH0if*95NsVu?&QS?IcL%_y&_xD^!@*eK9E*34o59J=z0k7JbvwUTPzh2Uu zeRs)u$SNpc29=-n`~YNwsmaldx3+E)7c*8%!uulS}Pn9jyRWb3q0^;&pPD^blmQEU~q zoT~C4Sr_oUdUz$!j1Ue4G-O_C1`dz9AaFVvI;;J^OCI|UuPwXxYEc-Jeo$N1@V`%6 zj;;rT;2$VC%k~GjDG89~cJpEkDG-b2&&sI$De?f?fEmbR9 zFc1nK-UJ1RuAt&C`V8>z{Xam!xWDc5jQo1>L^lh)m4`Z_Kf<%`F_o0)1+6qP@Ow(aj#+vuD&%m`M9?k)a^b#KCu9p za+mh9J$uTmKU$CZ?OFSM=-DdzrjfIwcJG7g9k9D9y?eO5#1Guxr=|(%K=!1_s`|#6 z=mmaF4_5wQ{8rjS05Yshk+f3rUIQ#nv45kVlO?UbwuiG@b66}CUVlFac1EdS&F=(j ztK{tpx5P((zIWWT2@pI}yHNuI1e@Rw-vN7bZlev6@XHe@Qgi~e;95I;zvrn(hbeWiS0^egc2a*9ae!n*)~5;U!F8=?59*u&WICnDdwwVHA4!Pg}r=ShQS z7ycCJljsB0U3y>UwLZ+|+dY-aR&>ukQx_?{UD^r2s3PaZZWz8*(RV5W-dgXKi(`Py zxSAeYmEm4%Q4AoG!z2oBj{s1T=?K!8t`y#H$T$;&shW=9w#<^aUBNn93L5XhwY?ar zT9JE$MTx)~*xEgtE=-RAWMm}|Kzx@zp-vOHRe9R0&GhUH3DI{udhRPw*}2Je(FJ+E z(5z!`%U5c5Wn}9&m`3D5q5o;@4m%`2H3iBiybTP@a71d}1<9$5+)>Uo85n;v_sOlQM}O2lLxZ$nNF#a& z^b`;=c@Eq{)oD*q+pAov>d?v{{36G9K0R-OvLjZ$wZA=)KZ^r7v)`wOsM@gka7(@l z1otwLKOZ(8iY_MjQjAn{%mfaY=yd=Yf`#QEK#v=r(}RJz{&Ye|lnFp69TCs|1`Lx; zKLNekI>C7YggDQuf$FET8s2u`PA2|-qjT_N;%snxhrUOCU!QJL^xp(}761jTJc7k( zAz#>er9nHS!z?^w1SyQW{Vn3vstRKq=RS)RM8Lpa_T+fM8gxLIeLYhAT&&TE2AM(y`dsUD`h?Q0Y4A# z4i<@Gqtfo20zz?~_rKBpTpjwMk5Meb-@)gt;RLYrpE@P!|K02@DQ9nt8YX)(`tI0y zp3^2x;r@$i#tpAVT4AN%u7@Z$JJQ2TeZo#VsB{vTQSUo8gi;wj4)FpiW1d}=hdccm zC$%np=qFMft6wGqf0O=z$!K}y#}2`;nXw{6#jEf=w?8}t%99<_^9Rryy z?_>Ah6(7n(Pv*ZQTg;Cg?1Q&boi?;0RY+m#$tD{lNk%|riq0Eneo2k$OE8h&Z;nn>i#IP1kh=c`tPa8NDEiA50zsh) zW3>%D_g@gDd3J`d-AQ(5WVswmJ5h?wPmap(*L70^i0mawYKHuKXn~J5r}iG-02A95 z`xn#7-|O8ATk0!&w^IJo$aj?<3%B0}iPRkcbse5==mZTzP+gI;%c90cCMelMDB2=9 zWq-cEDW%7X>R`9=FTMO`ijvm#r8{BC8$EIQzfF5qV)BTZK@=lOT^TYz%xd+vMq3q)4H-$hY~5B{0q3@ zIw=t+KX2gF(dX)dMb5P6C`i zQ%R>N`(Z1mtna3yMWx3pzxcIO60iABrxmKwcWZ#SDm+JnGT=sz4RfPut+8*`S#Zpu z(I@;|8=N@l-4?~qS(Ypj!s?n_@Sggi0wxR&5wA2u;27M_TG&_tr8C3usqQRQ)jkSQ zof2E_(JO~hY149@&m}x7veW~fT53?KLRiy6WY#E5V+r-58L#U?2j|HR?(@#_g-rcs8$(Xo-EaQLxksYe z*|b*vSN@YnvSwku07SK0(1<)b)M%*ab4z+Ql1xDR4=G;_yj_!d<45=xC}O4AXWrKi zEwKEJP6(<)P@4@e?NB-w(>1S9+cdFol7@A`jxdI>|3XZhkELu?QSa(8^j^=_g~?W! zZPQTsS*zPa^Uh$-A5q#7EB1gG+^lNv|qhz5(42&qOIaO)Y2U zkG2Sy`uR^J5Ow@$Jx*(s9cM%RGXUn*#WA}8z0|H;c1XC6eSLt)OYufCxIW>?9!6{? zC^aFj<7fiX7Lbi_mSI-AkQ~`;7;c+09-?8Z z*h=qhYZ(^9rg2^R!atf*%pBUMfJWBnDH0@RbatBabA`FE12%uAt_K`ltn`iz4{%RRWWKTL1A=m zi3IkjQuFxsOvl)vA#k=`YaR0`_OUQ`Q=e2Bg<~A54e6oKX^Sp3?S7fb?{S6DEy535{|0t~Uq|ek>C8cu&)~j@+~S4j*F^xXwLgzqcfTN-PcW{b zmb&fYy#(Z;-8~JMH*}PeNlp5>>FXW4o1>lId^zvMx?*u=)jmSAT-s_d(%PKr$-l(7lm zvvZMZdh`W(CTNHT)bHcw1X@Ka#f&O1nxjr5D%O462Yr`9BwGW1{oG%s++W6CTlc%u zTK448+=HvwI-95CVBz{=2()G2M-gk#HyMf*;ie3+E>`U>knE=$ca)Ft$@X&lzDo=U zU$$UoE##$OrZuo15X~E2M4Nn&%7)s_Ki?L0g6jXW^Je%|uV>BvLav&rAj0jc#t>Cb zL)pauI_6v~8AV$g7db|SvFvM}5?p`UB2US6fa+6zOna0x(fvo84OKAneF73o1@fP$ z6VGQ;Du*p5F^5mtwx(J<%5GRu_j(vGSsO6^g7Q47oJIz+6yk<5JHkPm4QLZJW)pf* z%k{VDCFV-D)Nm0&2vSH?v}o4S0FDq16U5jZZ?X?1*;9z_M&;{bkRPxmN8_bOBezy4 z$)g&Le`XD|5+ooZWv6*b%`7Ma*{ZV;qFU>SWF_qdRa@t`GNxRzpXaO7lwRH;;;>vw zC_>c&*x-2NGKOAOVRE&^%2p->bzOZAC6`-ajSvou|Mxj(gY7L#m6i|8SF0IqRv#{} zw2k6GUF$ERP|eOMgqqAmiP#&?b{3^;nvqmB3a*B~Jj@VtX{N58{Y$v&;h=_$Eu~ze z$7@=*a^5}fHlXyw}sGP5QDlC{2)rzA+xXfl;wV}J_P&R zc=WaRt|^@2hQiZl#oVDe~8{KqZp06@VX^Gg?r*Vv`U;McQr)OM4oFj zzQCBrgy9wf67pRY+PeBzUj87mu7;)DRbitD=d|drBn>A&e`7+9h2qKjG%wILXPPBQ z!yD0eu?RFJvvEc#Iene0^Zw=^tLi92q&iY`;LTp?^Wc1%<1mgea(g;Ui+ToHa=9!o zroZe3%(n;>nw3#Py@CBH_2fawON`v8Ba&32NIOet_@Rr&J=5IvF!SU<{M6KG>8t45 zN1+4AL7M$UM!{)YoT`PHQ8euwd@K|VF*Us1K-qxVj{eLkF23j7>8dJMMxgTN(g<-3 zyA%+LbhtKNd?Tl`Na9~Jds+umQ}T!{lwEET>IfA(rtkEO?47R8o11nXwxGQTkpSr; zv(VhJBi89WblOR%)IRC!=MQhk3XZ*=h(j2>b$cCdUdiI8i)5O4m&b&9uFsVF(NJyf zPEm;9tZ1Q?!9?BuJold36`DJ-GqVJ`D~en9=_gF?J2r+rj1DTf5x2*j%uHek4NfsQ zu?ZkL6YV*l#kVl1i|SPE3wnbYrULUFo{9bJ9939 zcv3@a*;{sc$kR*mMlTfZvEA;MlUqf|+#5F_J3rKoKWj z_U1$xb;Lj$Vz|M86Dj+^3Ps~nIn|q4n%N%Fyn4m>HC)CX{}}C*c>EaAu9{cRj_NYU z;FmP=DDB@bXi5JDAjh{?>3d$E5}3!;(+|@`-%MNiIM3-lv#A2a^Fx!$XnwPaR= zLPMExsNL(9`7CIL(m#ABh)*2hh#tF$q>C5si`^GMSU<_eKuPLTImzTvP1(0fXy;nl zB}f;%P=Nt;VTRgfUYF>CniM~)=RP8$Mso!c?!n+#?cs+snNgNVf{U<#0-doH!H^fK zf^{-iiPuFSwSQZKRQ>}Mzbk92kR&^mpt3((v+ zXvN|vY|noIJ_xH~%&j0<#*lN`d>~#{T~!ij!hUJG25Dra3vmhXFA4M8+fr2ThZzi- zYN8)Mk#<@`${b1bVe;@6rdFrK#ek>0x4&VQXU2_Hm-L30*2*o64Vh-xYm7fqrH&aT z8Ryy9#wq0$OaI#r|&_uoeKd_70OkemHlxPhNJfEz8;plVHiZMCgtOZRn&f{m6E!82tI36Elo8jtI2?~XmSx~xpGC~Z zZcH8CG7EY=@jhD6L2SYg`DG&u+HK+;Gla;dKZ$)a*7_8EpYWC1?<`XOgax&)C8ND2 z4^Mg(QRW235Q(V1zKwOAEOjVdOz=VRQXqcxQ;q``ESM$e{^r*q^2JA2M&tx z5VErBye^^w=6n2kZKM?(c|MBsXzGD)pr3vee^$ypeSV49z@XWQs+>!=q92=!r6|&m{E7%h5k)A9s%=@K#s-fCZrQxGb_Qv$5~)4j8PE>l zVDD-a(HIi_9%>g^02q0#=VlEcLgO1TS#KImrHAQK<#fwEuA+bIvU&3ZcWss77Z~0xMgxx#CY8iZ{3l~@GC;yp)+xDvg2o4;8RhgJKHHwz&cn=|R)gg%S zuXvD(LDTZEmdbC*lS1a5tahsfk&bh|*#}~5_Y6eZCuy0oqmWtx9!8MgEsr?3&=B%Q zw$$>B_mHGo;PyD7y#4Ld9U%&l zU*QYEGKs=$$NlU$DTNulPdD85z1?`Y!Ec~t`YGb2L7u?V0NIn2_N}JkJ~^PbYUeB^ zaNAvLJdzQHa|_G-9dA#y(-m5z*K;kzXTh0~=6BO0@96A&YvO%|_hKeCSIT+a7`qQ+ z%gjux4$X4^nZTJ9idjDJkNgE2l^Dy2NznC8j4nTVd?2Qx7$lKryM^s}W@`Nn;)-3* z$+}z5_rcUmn+6)9r>K%&2owK;rRG7}s|5z8imP+}w9%(>c^OR&Bwm_!06G|W~T zxn$haU|W$C_DktDep0JknJgiA*AS7HTB~!yXKl$^q25A5!#w0R^+ELr8Dq#*e*a84)(D!Og(%aA*jKTB7?9$k#J!)CQ@6&6$mDGr7T9D5 zcJ|a_ZWawDSu&|)cQDCz43<@})0`Pviuk5XC=SI+B5D2n{F)0%P?40XS!7 zLBq^Jb!V4Z+8)|({Fot!My?f&X8Y}N z*3}#N zpo;$SU*Vg#>QmcMYs?c;SgUo~i95pr48lSeT$t9_+NEc?O1YZj>HvR}a*b@Ib42z? zBN-C=EPoG;zCnMlmV4TM)1q7NZahH%EX{U_%>wh>TADC=Dn(?xH|&x`I=_C`=RwcZ}Ix^i(FrEJ6@ZPs6U9 zsNRnf#vq>)gxhJtM{ZQSx?@E-$BSW#nw>RPP20!2V5X27FqBgxOI5srDJU6m^4<^L z6ko=RyM~BV0GX&r1U~`kOynu15ylecceNj*gr7dW1ZO#@FGKnflyG_vj>GfU#Sdbj z^@BupI>-0{W(^7PyCphNFt@_MH+{^|i)B4s^UU`{7GYI0rD!+3gf)Ui&yDrf3-245r|wi$HyF`@p-xq$C@- zZU+fvcElpE=lnGBOHvB&dfZB0+UvfS!&aNqP-^L}XfnWi2I#9Ih|GNsJbH0bxnV>{ z-UWh=e}bI-5k(@SU%Upjm)o-b=60gG?d{fE!^c8pgD&N4N!{cL;Hg_!db>3PzdmWnal?^5AC< zbLUUv{JpKsuR9$5M8t%3LeV5}Ww!f3x>fF9TXEFj!cb!D>3aOa@tb#p4jL03*n|dQ zH_Nu)LRCoh0U-<>MGHew6Bb9!_2Y$Q5e)Yk>N;4IekdXv!)^&HbQQ+Rq;)t(T)TET zrBXA~AKvJufiS|-LICt2>)+4;DIWu?q)wvdyb};+gKX}i-s&4nu6}k=mVc22xhlvg z*7C+NN>Z^J&>XaiBl8fsOgEw|BiFCO8zXO@B0}l( zLo79g(p~j95PX~W{@|e8wH#Ecyw?02R%cHDE^ub$4O*~4s3r(vleRiR!!ps zJJ-fu+7Mn5sJe0aibQ|yj6*EBzlI0~_AYOD`sc97#L}2ng;3JyN%N~b7m8?grwJ11&g)dEQ3Z^ z>cqOK#)oc37g8l#=ba&J0rOAnd|*1^`AIMG$~I39Tiux)5*~&zp>a_aNnhE*St({f&W1vkbM7kOFh2EtJ#W=!Psip;Cr2O zQ?RkPS^i(q6{V`|Wm`lGQ;)Q7LZ)pRAhd@-5V&lxeI(UA=4UTI4!kkBBA9K`vvC|2 zMFWw;WSq49+kG5g7&R-&{}4 zKj7#wK?`u6Hnb787ya042o%is-}2hcsw6(q2~-~h@vksz>hWr)ag}t1d+}q#>jp!2 zZSZR950flSw=75A8KyHVC(8eVwYx$3weZr{&NT!NZ@#)ClxShoA7sAW9+~+V3RRd( z=e%!P4B9I%IN<_9Z#i^Zn!7_UwXT7vP~Ds1LE~a$E1K9SU%0L7F6No-RKbRNd*H z>qlmp;&*E+hT3;ImYBBVIIWs#jvcJ19QjmHZn+1SZBUVf^HxXQU%A~H51@~RN~H?) z2?A)llZu8Dg24^E^zAOsMKNrgMF8%GwGPhuh}Pz^86LTcw3{-%i!`A`LrCbft+A<9 zbA#qz2#c#fiZ1=NZZF%T7mZl4ZmC3#Qw2E>zL06YL=tZ1&%J58 zBv>*twz_e(Z8DvejIvooJpqx_nAayOy{-d=k4UQ#lHeaSaX+8*=lCFcBcx>rR#Dri z5*UAMm`G+?5%?!=1N`(`G&Y>kA+epaPvjuN3c0Z{adw#E*E^Vh@c2tbiB)~l214k8 zPtX>hog8iMWo(MC&1Sp;JZU5o{o(fMbpIREf6?#r9v7JQzjN@bdUfrl?@`D^f2py} z{{2~9U(bFY<>K$B64?fSyUk}ALhOSz?P6f+E(XC!9jq3KaF(XBs$EDWOI;PJiBd6_ z{vPUyi(SRB7`E9vC0V#_PNC*tCh9KYmEmMWYb;6vf-%_EW?$d*gPx;rJ1&RZXA+?3 zZx6WTqKHrAeMVC4d3S|%yp%4K+%;5FMvOPsqhvSqsjF0;)W@NMm%&{>HBK{OqvQpl zT^P5=kutf6?ei23E3es{L{LrTdi3{&FjONDF}6i*f25FEKaXP2`stV zQy=9DOnzrZylD^D;n-GVgr*;G2xMB=NerKxq;X0=cfHqB9vm*9O>Vf&Nf{0WmYzToDXNCNR0-|UnH*&V z*cEwt>vxsY#-k7LVh)iVWdFEN47Nol{QBC)jqkU-%U#}T(>m7_RayR{=77ojPe8Yy zRp}fjf#u4Uga4fOgKH%c`}-q+A*m(RwECehKdPq6Co1KFg=vLYX_niu^Lw|WS*8N- z8Cu!B^is}2?t8^3;s`X)6hC(!+ytTBOnq9eSwXtAf8wjm6UUTScX~18IBE%tOB)Y&`Sa#O)g{G=$$fM7xu~{L8k}=Ug6;Q}(p?Fu<2z!e zqaF5BjTeS*7zg#NrL#pHT+0n;`UoE($p`AIHpqW>hoQP^SiU*XD9{zi!Zz}^Jo0l6 zjy6~a)ghFEF5Iha6Vbf2ADqhsLTLg9zM@u579KVG#ZOuXu=i32xwTd2JfRVk+D&K- z+k?y^k}_9F@lTnk4%49z26Sls*aep(PrNz?Q)5r3)@rKjWi=K)3;gVv0-=gCe+Lv? zwU6Ai;jcU0a4u@8el9NRnZxH`LS!g?C0|BD5{=M#q?dOu$w27X$elW)Otp^Et@MzX zDNvKy|0jpsq{O&llp$m$As8q`xzF-k8gL<;^yeZi=E(-f%eCsUxY4vmE_)~zU4QEw z+ncg)o*pr`!+wAe(`F?2$AN<7AOciwX~-Vp8ro2iXlXe9|WCx zh<8pHxfn}DaPzS`uj8q}75xEDZ4&L&j$n)!Cx z{F{`eZ)0UpUhJyyak}QKxR0_QxbKMBNXgT24aYBE^Q2px$!P6u82_|**iVAsXz9t?sk{W|Hs~2zeU-$UBgPq017jJgw)K? zpoB>GFu-6?79dDUNJ)dz4l+m$p@`Haq8M~H64D_dDc#-8z2j4Ha zF&^8=oJa3#U;A2HAtsO4gsG0_KKX_k0fq}KZsq-L^?-T-nRl?dfl>GdjI zWfM9&*C0%%jkTUTtcbe3TC}$p&7&EYH43}C`utsz?YeTVpUT%C)F5*&wx)L7bQe5|KzD(`bY(}E?waliUDHf-C(s-sfzSQNOU^ZRR{Vqavo0;>BW_ zxgQcp3O1J}0}eFffk;D2TFCU~nIAT=fDJG#=d@NoFLbf>H+hq@J;&S&5WkDN$L8Ds zTazd8n|r3VWF8_wM!D|-<(z-JU_g`fr`>>&E$zZrz79cV%1OA)uy$cU*83u;+B*;> zzql|J@N!35AZ67VM%LF-AR`~8x-Q-Hil4+9{Y;t9-DU40MW-%ZRpfl`6A_AyL&D4- z3Yu1n3Y(N#7CJWdFSZtJ9L+4kNgR?5v9e?-#`^(nd(U!k_P+7|zyh2Xnvq7(`1J)gorx{Ye{Ed8AG z74MB3HiU#Dct_Gh085z4G(eC6q8rgmhWk!1TM?l{g9#b70WC_DrUDV0LB=kURCID`Pxj=+vrk95htvP7r=H$>M!^ zsqW=c4wcFM0>E!w8^Vq-D7eSI)smvbkObO-10%;pKm z)P1_0aDB}K4WZz0@tP$P7qi0#Od4Ri3^ednz?$VhHS|;*ZFiI++X@c|h0-IuJ>I+3 zeE5P9j0V4a-H%MmcT(90U82JEbXN@#08wGyh;qFK-~Rpmp(i(E+8BU?Gy)O~=Jx?9 zs`~ruA_~0Msd^#VR*rzO3Ji6#4>)$uBVj~9l&ckugkG2T1YDAyQfG^V8@4ft-Se_m z$A~RZFW}Kl|c|axKpz? z_QEONTpjTgIBK&c0G6Q7(PGA$XOgTIma;a0fKlS2iUDxWG~fw~Bx!L3D>>wvLm0?O zcu^po5hbZH&L&Fw+zSPK{Zn!Nh8-0mXf z5=5v0zN*pu%%y@#8O2pNWE_<3>DB^2M8SIwzvJBzM;C5c6sGTLpc@lN*rK6mlh(B zh;$(^Q@RM3f-bS}2E`;obkn+A;q4H*21?k=*|zu!$T?k#C5y(Cx^h5<|7_2N(%)BU zsN)+o>gp1yImx%C=eA z?i2v}arwNhrG~T9VD5*oBmDcuwa4gi91YkvfkXW}&02KtAIx_oN!@#Ttnod6gTZVh zwpp9`bhhx2?Xmyl6F5(9>@RjBoY(G%N0{XT9kvSJl*(^nt zXmg1=8zv2n1yUGJiNTBIa*Vc^bbr`2QwK_im+uPJJ^*g4u=$VYuT%X`hd!Ail=c5v z)v%}1!)BV)DE4b(Ri68cowUz=={~hP(Q%0mYk{7=DhhVP~mp*H}Bq^ z>qvA()9i2z-&$hq8mKd*gvhE{pTI6S_Dl`iCBp;%P^jTJtKh$>o#`1VTUKR5jT5 zZg9W3OlpW!8h3Y{~k>}z~e z{(J$)T!uRDv%F9|nR5QEzbVAm*T6Ox!+nMe490)p6yo`dX`RW^}egb4*G)c@%H$=RE*O@ zKLlxtzp978We&ypGKb|9u2l{W1O@v8wFiEC(QHPCHbdpRoMoTpG_P+2OBug-;Is8% z$M*L*sRu;_?{2LU6tAenC z4vD5b{UsCj=}+xt3yDmV?TCyy%52NXOlH1!u_!rylDb79ljc8r&0%)&{C*j(-k6K8xkW$2uG*C~Om z_5Lj3-E7Z_;t^alal{U3bR#t$8%}Jj41bASG4S9#e6rfrWA|r!tLtrt%lz!TOmq-G z!Ex5*(0%oa!RaPN5bmA0t^F7OE;czmk3Y87-WH7jygeC6cTd&$WJOS4GdkyEKDMLT znZ45Rvb3_I<tMiMLzuS^5aa*EsOpi&tfYz z8G^L-c{rEo=`<}{gYVzCPBM~BGGYo-RE3pZeYYD_DdYNW<;6s8{_*1% zx2jklg?37E!Qlygd0uNm`D;y_Gx>=lrAG^-N+v$59eJ4MaesmUVZBt-adF5bGSjew zkaCX&DZaY&8_)UB|Jp#|D(`(Q**kj*3#J11k7^`DQ!9@jL>|jZRW|SD_-&8ObR_gz zo=hlSciTfAZtq73|D-nSOVdz#NQ>giG#U4=s+*kGP=x31lsKGCM*dQNb1%9NHqCdl zNs+dtQRx&v`p4{1jA}SH64les6=3cue~rQDf4@*_c;%Nfl;E1T(pT5r5JB=sSLX+jMQ81(k{)_=Dy_%u`$ z7J~&|N?mMHde0*hIOGU7^e>55vici{T#i!gj9v#T9DlPZ3Eq_C_cqblZ{;_SWAX*+ zs#KPPfE)I{8E$1q=C;0Prc9xxcbZn?lNR-&tB;=s)6=)>7vMZcqsH5Ie}8MH zKRL`l9T+!v=Tet+8bU6=t>l_b(Z8x)bRyEja32iV-XCid>!=Y9Ho)i2iH&cHiiwPh zeEZ^kf9$I)xl&=UMS0BM#no6}7~{Nk7`C-Oe8de`N2r*ND_84ZixrEJ+&PpAcl%|*0vg{?|y2_b(SFu z&!+S?t-F=~BB9Dcydm>T?!GZElHw zwCwQwZaL8N0wU)nQT{P(+rq>v){tp#9ET4XHWG;+?c?RWk-Ht9!4d1o)p%>zS#9AR%W5v4)!5xzGq%p0Yg_WPekUrzPo*GPKyx>EebXReT{ zMn#e7qkWg?H~VAnxIC2F9Adqr`^8q^ic^%{s+lndg}r~z(4WJz zZPl`)tLlowuh$qNsvg~Fb(i{d@6&SO+L)@kwzt;l$+44)4>7UgojaYZ=Q!@m#vPh& z@hNs4F6{0pF`Q$UJ=IA7jf!@l~z=qHV`scw^2Tb`k9{|M+k( zf~vvJQd=I&QVtm1wbGrdd>5fIN?E7svXZ56MoP2VV{m_sHW?tScyvA;vJ2=dJ^7|D z`{3|(NQK0e^bVa6b(C~(VA1))v%1EPKhMKO6!lknnx2Oz@M^I6yR0bozcBI~hUH0| zWEbq$u!kUp!A95X4TcrH4?^5sP1m1pe zqPr-!d%uK>AuM~>X*AX6LF+@*xs!1j#OWdX3e7H+oP+zJldg=N=JTk;$^Jy;_6!A? z2DOWr^UGedRAKmY+sPwXRo`y%BuUbj z!=05)r>V6|@$Itg?lXU@EZuEa?Pp=rnyRSA22mR;`F3ARA7A;MGp}*! z&86jm3L83Gs|am*ef4Ylb5?WHZ|=qReX-`75;?6(n2|H{jofnT$M!jOKcJB=jIlpD z1LgSN*;Aj-QCD z$JI+ATzYO{lT&b%%d-FH)8w7+ud-wt`mtokV)H{8Pj^Fc%}VB zW704~?th>8O8E%HObuwv(en&kF0*fju}8GTxW7=y0~y{MDEbxUZ<f+yTFa!`^fMWja?7e#j0Cx;oZRx|+yr|dx)q8G# zx1<%YC4uLd&o6%E{Yw0=CwdNmf1qY(@}m6TwWI6-PG;~HdD}bpVgWv)wtW3-v6EyN z9#nCc8}9()Fb!Z>YrOSj0ciV-BnuSO)5y(y=cpKhHj|MtOA!?bl2IOS+p&9(ST6;p z{rmUQHY(y2#eZ}EMq_Sv#M{jhpZFSIb9!{^6)mT5ET4Adr2pnmrZ!L}FZk)^&vA3s z$*ob(@fJ{B&r#v|r_@>R^KF(PAU5y>fLA?*w!KEH@0-cLKgfy!PDaK+gX9{KBv5&J zwCplq>?xCX7f-BecERR@a$#}N=E09@MJm9 zx4;@!13p>xV*hQ`-f$a1isS1MK-5NkwH0>bi2*Xd z=xpGDjapp;5ce9c4@g=VeCfKj5Q4b4@$-}b05@~NFhwDQ8h=0}upBLS=S88y-MSR^ zG1H9^uD8FW_q_GaN~8=S!jsOg18P9YY0m>uo?)r~U{Jen!pnsJGZDJWQQuY*9gs6% zpxu!O>3Uo#kfeACoTmFaieal>JKY+yK*R(OP~ZR`@$j+tr$YN7 zy`#NVAq{r-IG{q(Bttbol-teDHk~{LgKwDPHASg`uJBkDB&vR#fO7S0g_A7HmYAMm zhetA?-k66U1>Q}@`(QG}cmy60#&|6TWPe(dJ;wxq)`3Z6(`E_4a@)Y)e*$c>T!3sv ziw37JH&Jy2C=H0X)L)Wn1|kc>KyEiMtXK!mgLbvi?szXTy3Tl2AA0N!l*{q~K-m_~ zB0kf1SKHkSK2>@F(Oc>5s<9V@6v!dWl@S%Ofbwho?&T8%9DMu4Wua~?1*gw1*pVOM zsEoy%%9nC4s(8aEP4ncV@JjtfQNlj;0MIkJ*%-;rddy0YUrdi>TZ5oBCS}j&zsz6Q zOuNRH;+4h*D!frQXb@puvn)U#H7u+%K;cx(wugJ3>)@&W40gyDiNf!+z7dj(xnM?J zP@&#wBL({bfO{FGjDuai9@>;(&Z&ok6}lhQ^DyMQusdWHWZt=FY>MF>0LJ8_W)gNY zPm$bR8S32)q&#=J#&ne7*F{z*-X+fkN~ud(`3{zWWWbtmR9!t2!bqGb+hAN#OrNLg zr|7+f?8p#@|Bbq|RQLj9Dc>bix{Q8N2=ap^5vhs9hUD{^c%@A2-?c3yY2e*~v-n z{RS?LEY_uQ*CEED*DmOt*OUXQA;wBy!ggpdd_l87K7vv27e+JaY7iy*Y&uHG14|R6 z7TB=Z<#S+58nglg2QD{XQM$`yYY!2@P-3qu5ni1`Iew*$A=8}oh6-6Z9*XRFgWZ@t z5?TTXxUcqTYlB1sZOp{6gSlq)Mx%mkMOi0)Acq%e>7syU54@mNND&VEl6lshn&-)! zT_}QM+I=Z@psWtR3mGaIdoHB@2kMHxeW2j*=^7C6XoD$C9zq)}q7?ck1G6@ne2(jB zmD;0X}X>|`0&&-F!s4=0mmR1K*u$)$A&$uw7Om;fRt?4cCC z=`}!1B$B922Xn5G>7w|I1FEzB$w zLqShSpyWV9kRg(fy(WWcoK90lj&q(>cY6E34#i8qQz*4@AA@xS$Voa3U;UV&^@f#I zvN@oicc6iWFJ61C(dW;7BLWX6K7FPC-mp|6@cD4|IXV2Y`1~C1Dw!%Zrx~OZsJ^g^ zq2DS0N{|T2)P)=3DXioXIz}0Gn)>2(>v6eHtNc$7Gq_lMZYP9(zSiz#@~oCzYiGmR zx<7{H0hVIbvR{E81%C$p^?Y}!?8V_T@$HtYn?w+6k`S zZc5Sn@FW#soypo=n3bD~(18}6>?FEN6jEkFL+~!m+++v9*YzzBVu6U)_>G-_Nx?X* zgi}iIWqOTgZZ6}b)IDBsAEY4hB&wUhQ16q~Ti_-~u6?exm-CmVf4YV;ObX#Ba8p3W zaJhdPE{}+Bubh53$egNQ?Nb&edALl{92FA4CHpQoBMZF%%FAXU|2TP$^VvvMQ^L57 z@yBpAsO(bsR+Om{u-Eq5sMpS;E*NHTU?pRs1<^}FLnF=8voZT`CD0-D2jPT{BiK-?|AehkF# zRlxZd!_=?Js?PNG#5%2i0>UAsDeu^0eQqK8ygW%(kX%$W++|&`x)xTBfBN#vF9vQj zDOp?;f>Q=)J2aY3IzdPYHd{bnh@2qGb?*ch5JT02{KADXys?Y%&*`Fi4Hd=WRW13` z`IVJJUmq-UpRiaeuHogZ6bN-y?S-h^8%~Ot&XeFOsGAkv zM$$B6>CQHNP1+BqJjWP-lA;cwaw-x)oc7e{wnE< zQq`mapOk$NMyJ_!gSZ3_T-j$sfwGq;PmlDTk&<54hVWhPc+M&QTlW;U5^{tA*AZ8U z-SF}>b0w{RttUo;s+eaX=XJy>2P?7<-Z|`HEJAW#gIR6zg9VFROecl#=1J1BH`Btw z?|J344DHml<{QEM0%@J&=|SVii+ZPC>R7U$SNFMQQv6T7<3DFmFVvqzm;Vs8w?7bg zc+?Iil+1Y=M{wRO)xCm1UPn^*{Djh*oi1w7-pBO#VWZcKitbzd%?N8ptz+dwq@Ny7_zf6*Nle; zQ>HZor3Fg}3#VDiop0yGN1)oL!D=XYM7pEs@#|+3FK;KlBv8i4LMRrwp@v5VX7v|< z=lCJ?dYV|e148zo>hn9i@T<~5Hu9DV?TbEi(;CcRC?(S(t`w;>`vA2a7ot?s0#?cH z8}ibl;N7SNIv78OS)9OdnW@$TRq2yQVm0v*iB0guCVpNH^zL&l6QL5(GlAypkg~oM zfzhS`W0qmcuh@3vZRn*_8udY+jfq+@vCpt-VDQ*+sO^YEbIIO(su^m|sMx9$M9?9L zs=-UDKaKe8i%5YVU7@6;H{0Qn)^edoK<{FNPQOqeOVFW?n2L3sm!?%1Hb6Eu`qd@Y za{qAOI|5-_t|nIlVGfCamqUMyR@x9iv+7dzFcB6av{2ZHc`slJq-ovjtl<{><<2vs zSPv#iNu1yY#}7_}5;a2(C2@7cN$oxjj6Mw;Znt}_NZdbcOWXf$@IR1l$`H{SUOH4C z;~964rkwY<8MVK8pmXODtzPp923Kvj!8ca%pG8^Q{=YBE9yP4;7RJ3hI1AKoP((vq z62Z=Tw^f7LTy=@T_7YUeYT@u)KEw-{I7TWTEnf4w+t>fz2Mc3tH_sPVX2Pm|d-r>K znvBJ=TR4p@hLYvdS|qt{fZL`gj#E4Y{{s}Yw--BFQ;YE=hkJ;}-maF=g)=rH<>8fm zq?18tWgUIKa{@s=(dM)34^&O+(YQ6Mk6c0teyXjA@xt@@wRNWbO871M+oL)@xQp1` zs9o;Cm>re|$Ra8|14_BA1~I2c-TB7hA7Z2@H4rGZZ!Tr!hR~F!ZU2};ot>_5=*9my z^HP9Ludw7fQ)6lYUg+&5t2_y^)StCDqmvFMgy2e?POPDZoaTC6Wc4UPDv8drpR${C zm8)B22}j(VPxwh3)EQvG@XHq;!C20!@vQ|y=O=Ip10{U(({GgWsM{D|`tpVKdRrL<^y-r~F&&J$U2LW@UZMa+v7`LkKb) z{D}6?At(7k!I6K-03OA*rKXa*QTxhB zp03{iO@k`x&B>;mp8UIO=?>|1DogKv&L=?|NXkar&)JQXQf&Tcw-aT*m7{TQu~U90 z40SK?2tiWF5=7x_IS~4DKLo2C99V7WC^HsJvl?zt_j~-(8egkEJERWX-5*SXoTu)fUkyo3 z3&H=S#if7ATG)52Se?UI#?_FiL6+H|lzula?;aAmcQlG<>CZt_tp-1CY>c#uCqR@} z3M!1{mG~4|OU~=7rXaePEKbM?fyuoW+Unk{GToU``j zr$YNX)Hwt-9-(+0&t)}MPqmNwBmH62pSJ*qBk%CER+ktPSSyT3aA~%6q_}#t`cD@F zI?iN)5BbXPDQoD?0im-aeu|)w;P;aL(?3TcIE0$;{S?8WkEgKSU&9P05q~|3)(WD=aIKb_9S{ND;{m{Eg=jL5^@Pe;i|8}l{-hQdfzNHhiseJOJH1!{D3{I+@WOsfPG5&Cgz)V zv@p)&5qlYz@=fY65BG|xKkJxvA!srB(Ysk%y5${5@5$oG9Srhnf?vMxWSW)sEi%BE z3H|3@d$s_7%>8!LyftPLn)8hsKV3UxfA(g~QAdkZAKlD;>KbzLxnLlL+4i}&g6*ik zj^Rq=n;b3mKkZjJGO}ae*DEn*8@Bk6VIs^Q7<2`+>~Q3*1>aEW3DNWI@#eKqy9ryS zw`a4?zua4}%8Tmh6&7%K6N-D;!RD)nIoKenZY7?3RQV z>#giBUokv_#W+o5lKe&X%!wptbEhc>IU6K5b%dj_up60GXEI-htjAmTnv;^bfBLd{ zW-Fimo(YUxo&7~h8#nbn^8SMI2_Pv8sNfpyE;>8Y+EM7dE^7#>9b3apy6y zOKb)JRfhMzh{M8%f?qxc#cNL}|jGk{_bD1=-zA4dL@jqOEMkHtL z1wb^r7du%0mw?lA5%jRF6~4|U63~&9hf<6{9hE{qYvF# zZMH<(cAy8697|P zE96c5&j9B3$$lt*M1KBzPPNOy%q#Cc!seA-;FwOiC;TuwDbuj%CUEoM0>U6MtHmS2 zCcZ7}9TSl`m)K=*%$7FU**zxkC=s;C{Kq+Oy}er2A>Gln9a}cg6cQTBuQXcf{LyEB z)YAo^fqdJ{6?`Bat@`BE@RW`xZoisRG0#8hyf}w0iF( z)oUsg16w%elH6*t^-D=!sZvw~yws?jUZ6qSf9J9MZr@$CwMQ*`62?TGi2p<+U}{5+ zz7In&P%s<1mA^hK1>HLX49#B~9}wj$LGUdE5Z7}2V{!pzDaWLw=SyE*K<%M)^d=}? zY!=F?L;@knbb2--#A;ArMG35Ii7Lg94>pKUrpK7~JX^$Ip>3=@VW*cQdf2r~;gj7! zwo9u(Ml)!()Q&c<=HV1et9J&gS%eMOujc2V0-eU^;f4IO47jwP+{q4T%F5PMZQOy`gdW+Fv z{8PN=Sjx6qg~-K3ou|-D2xJ}l4Eh|vvbjJdR<^JzJ-Z43z` zTln>0>6~jLqX$sD{Z_C$QTuYV^kdYY8u#S~`zBbKXz9zrOHuL09trjBoEf;82`@#U z1U%}xaV_QL_;szN{;cIj$UD!4Un)y|U#IQmff}*YoItp7qm2&!TUF4(3V`^tF_DzNNUn>n%A zw7N-<6^JJq8)|UDXYntZJ3&r{O)~@p4e%a(CLktLPC;OM`Ed2+~Jhh3oFn))9uRQ_K96e?g5P3~4e(q|xbBg3sRy8w(Pd{tnzl;l(OC zPNkEt^ixlE;!XSs_peAfuH?eYZ}=X$fqG!4B%BQ>l(2aLDA3*mju76N2p0F@3zRP{ z=_i%(2>Sy9kpEsl-u7E!8h{F<`4<98A>>tFQ3Jc*4A2%k4mNJMErS-EwK-nXRg43dMdmr6sZ0PURlj#gj%652gHyb@7 zI51zK9*QGgj}8t*?PNhQM9JG}aB8?SiIawX(J?0x@p!YP~XaE=sW?j8xnnq49d-E-jXSXZD1mQA4#tHvTpzo z|3|}=m7j@zUuNq0Nz@P5!|_A8G3=I!etDhe^KS-*tDbz-R%-@_=Ne9=pc~3xHQ*mv zBY7T1LW2{;aWycfG5&r`#yB8ekhACn70cCF*pMQ_(Ro8AKsKQ2&RAvYXVSon%LBmN za0$Y_uWALe#=Be&H673FqyNuoAR?zdC>w|NkudDIHXQl>X-B8=glu^s^9yX z%Y#&Iczrtc0!?9?cyyzBNdtAG=gX?aTh2#47m##=lq;K)Knwf_CG!%Oi-sYc`AtG- zHNDzDCgIdrDcuWXkf|P#YNahH_Ka|W6DfOn`q74Lh!&bc8otCLIX5j6-X9)(K^xE>>(OQ^WxuO=2L2`I7%@lIE4vDFQ@1}c-RxHyq;6Bpb ztZ_s`yDvB6-kMt0nb6l=l()o_Ols^Xcg87mJ^K<>ZRFCzvnI>)3NH^~DyS~64%*}J z7&LPM36Um1Yr*$1L*%~7CdJkfuV01N56zP!SOyp;Zg-1*7e zyJDhNC^8)giGLsjVV4Q`yDR5(xv9{BmP#ODllLX6m;%)rF5fjP(;g`#HgKwPknn_d znWC#tZ3Ws_Ih=~2gIz~jpPGC9Bt&a)IPdNE?m;!=rS$9cKHreg$>AZ#StF_o$6wRJ zc&%1L^%lx6?tYzkk2gII3Typ6o=e?T_ps;}=Vip{75=4PVxjM-)K&VL+-nu<49-kG zx&iQmKiuh|o={mz-tzR#VRn*Lu*p38y%DM0z=bcI&|wV?d}`%;>Ar|v4R?j>A+Hqz}C9UTSiSEVcNyqvj;A3P7wibUX`Jx}0b zc&}?f48R-!VxMcE2Jodooq%6#uI*xuuNZWHpbV|BEgkbF`rKr6;Wp+M7}J_BDw2tp znkKWjLTC!+7}f%BgZko|iXUj{5$*P>b>lwUcLpB!{Dw#PX`->{A|^UY0YDv2Or)fs zWn2i_1v@(@y{c?|3J!99Ki3b)8%S{B4I&1AaYkTGDNf;OFbObU4K;kn@ux}%mwd#!{DCSV-Ow7;H2^Rdi^w0AtBhs{;Hez+q5`AFeYz-z@r76qlW6(L@D%2{+(#QSC#gHWj>)?iCr< zq`D8P`|rI-(ACg~kNu#&j=P3Q2>NrlI*~BZPU5~YnQ{A&OzJk)27Pm#uP4a(H%+?G zrcatt-#Sw>TvxEC6%$Jtw$rdoL0tj{;tUiOLB3jM2AVotfL-nHhBMl@zJsWsyOo+n zZT)eK*<2Crnp5^GC%ZE zGg8iE@j0miA9fFqs=q4v)xr?o(yn(rlhjO7hn3|&?bL(1D6xmhdy>(kZg%l>y9?oO zlaVwCdO<8i>885oo~8#B@-fPW6fvbyYwEBnKU<_O*ax!3O5E=ao^Amb zFuK2Cm~90mhuCLGY4S36xS&g`qgC+X+LYa0MYdSBgWx2P;M$~KI{t)dzJt7 zuy2qjL$+(AB(zST209X@Di~m=7eY6vVYG~&W3ovTdisPJYqsS4nFP)hQ^>z+EIg}W zTnqGBkR|WQm`Xlh+o@{Lb-Q9GC70u_h$R&)W+3(t>^j)D(HFfnpHfoGBmLJXa0Wr5!vRw{m7jgdT98XnRQC~ z(IF_9#z#N~ONI2mCqe}D<;Bw^fr6qLubris20#TSS>7>R>yOCwO3aeieA2puiVNst zE$-SaL3Hf+85~~d!NY|E&)qnXHETe*f?LHXdQ7+#K3S#u@hNC-(hp^T1qw&As9TBFWC7#P4AI105 zfY!Fwbawc^j6MY5C8k4bwc<5EjTh4`eYt!V&|=8mce&!<7Q`@W2YmDwV8c@)XFz25 z7DV}4;OY}nSm(4o*Rj>a>5mDe<4Fg=hGxks2vwr}&j=5JWe}3c+3DFGj36RL-jEZ( zlgRD{Rs-LOWVD2VKqEsVo%NP`Bo=>D9-s^QMEf%{QE*+@7ARG10i1-{uNf&Wz>UHc zSQ(Cp>9z8|KbLg`Elz3AYeXwK(FZOecSQssujRvbawh5bV;w=&DL|Y zKkLya5dE!$}%jPIhc;pPN!6Re(7L$u~!37`r<^bZV)l7cp}z7bol9z8jq8( z>&Fh?z}>Cv?0E%3#qT=K+s7Y@FWOE22qc{areX16!sYz=)T~mDalmS)(>OkUtC7{I znMgnZ(31%bYvsXIn3$3O(IOw8W7`{{`1o(stA;hcz^*9<006B3y?C=VPozq@fc6!h zbg>ZKPZmv)E*%mB&A{p=_Ff_=0|dcJJQ$I?{W&I_-xI~$LDe_kZl#g`)u};qk zKzegt_Zxc{UID0WO&k$9qaGs;o#V@WU%58NVq1=U^9kXesiF9L|Gb}b2fS)mQiJV$ zl0dXtGchCwSW`3*=_7(Z%Zf>$limOF}z-tQQ@oJyv@u@Hv1}oLuE*x|#&OodTbcyN;Ec>fRu6og~8eK=U3}Sy1RfCO<$L z)GT|Mr2tClQ60;4bu$@|QtY|NY!j!B09#T(BWri@tF$c`=gZo@{8x{@O{9GLlV&#uG>ECk@8y@ z?}ZN`e?q9Xf`7rE6S28w!1Y{0UIU@qKi}h7BzRVcXjoV!8MXMAzK+}Mx|G8PA5i25 zRnLovgv@9H;0jhOP;}9}#six!Ee=p&Ow2c?14Kp367dC2rJ|y248rub&CS`votJy- zz^iBruxFbI`{Mve+6n{4+Lv5_#aKl`JpeHKVDE`c(jnWW`Fbr&9E$UudzS9UMoC{R zRP04trZ;dsGe(<5DeU2atJ%W`nfjAfm7FhD#5_f!-wq$So^9JAoml+sYh33(tvjBSbAt>m0kx7^HNb<#=J>MzZ9IvvX=yR~~u7>F35o-Lb zuH?t1i*4~D>qp{%mB^%9F%d+av{BE9_sS;KSepbUGE{8->WotwN;b5op*8T&@K5a< z031yCV4?Jl6SBc?g!mA`?(wcb>A=kYBxK&?#cEN$Z7;92P>L_$#>(m)0cM-ME4#;M z<>5_hpihG&Vre62)P~tJp69rlyK&O$Mf74XFV)&k)&vMf{|TV>r+q7Glpx9s zOjiK1p_p%4OENGA_N)p>h{%>V-@$4<2dD2&^!6fPXUZrwHeuXnd^Z3%-ef-lL^6Ki z&O2Dqkxhk1{c`$ARigr>;gBDUP-?sbU~wY`+s-7JPK{6$u)WH2?3o5L`wg(NYy+0< z{Bo;>vB1kgtgpsq1W;E09EaB(m>QX~j-S3}AJ}&M$9LGD!0PeO*+KD{R{aHt>#%l3 zC{-*~>kG!z+9u|ZN~Z%6U(8N9zdz!76PmR6$E)z~z#{};xJgs*!_E-dhjQ!oRO{V< zXj$s9nH~9D+r^~Ban$8NVcp0#D}sywzJ z_W$0r!I6QgKWwHWNASFk`U%ruL(Cjs|46Pm^O7`r;!LwGNWTcc@mg}LH}*eZ7dAJs zzfhG>0sKY94PY`CM`R=NVh)s5e;wkuc=>&BkX=>N!wN<+I_?l!5pgFUvcq$#Xs%aNGOyE z@P^0F?AC8jWF_@0o$_Bn2Xk-BzvAw_lYUQ1m0L4#kK1`NTnStwX>WDtXl3b@b3J|?i5m{Xz`J=}F z>=eZTo8maBZKCBu&%6|}z)Ay(c2^{`s*c4jynqobLPn ze*bu$<2io6|2jBEb6)3lUFUgzKJWMIJ^6uZd*Z1}ZtUb|wOc~&La^pNt-I@8cMCMa zk5L*)FT?i#CeI@;1qggsoYmXcuRF(k5IiM-b%l)vo49dJQ(|yiQA#o16?f2_!O18g zhj^S`eQz9C3RNa`RUA6Fol0a3%jah$7H*QMr; z4Qd04!?r@fuE-;|Y#%ud^Z=@n_YUvOWukD)AcH$2W7g@xvnW|H`>RoBmZ+kc^q_mK zexC!t`ig4f94>3qcB`Z95CeQ2HsmX7VPeQDYhRt-bWch9L-}H$VIBRATTO4Zi5-!OClx_9a(5bOO+|Z&$QNu zb~2E`W-Y9XLUAd>QIFI?I%G1H!^=5_Y?+XHTIh8H_2UlWm&^;T-&r~^ zWKGnLd`yxoO=*ECfN+iA(WoY_oZ#NLAZd4w1A)_0bvX)g>>`|R>)ckITytbbSmD(FoIXt; z9tcS)VHq7GPt9D0$Q|AX=+kJnq$f*&>7!!g4;KGlAY%71V|SL~YIpc;5JYq?ssn8|RbsRk zKRhRxcQa36P^ut>_wP)cq|;aZ3o(=QvuK?gX1(GhC1LgzjQzn;xo5NHkenT7>v^50 z+Ydt=Yx3u^mE$(=MU8%sXs0ZCxjO2ApRjETnGtBV*)7n+(X@^liszF5OpZ*dd*2qg zCcg5lY^&|E7y&OUpXauxvyVGJ3u+`14HI*T@XG-qC9Bl6o; z3stbm3!6AOxW}hR*b4V~g4);9{XPBr#ycE>s$;*%)<;T#w z$&*h~s*{^vDFM5ZkD27mHaLmQu-*OD!$6e=L+nw%j*ky@)EtFNLA@aY7)p1A{Dn+{ z400#UOp8)^y^+jr){q4GXkz}xAw*R9AkXuWvN^FYi*CY`Q3Wda8O~*#c z(h!j#*L(8q4JkNz^o1yeHRx3PeL7HT;e9FU>iRNCpikd9XzcBgnPUB`T9M8Wi#;n07bQ6A>360yui-!9e&Qf`|s$_?TwI^{a4l z^AGVj^fF}o8Qu?5EiJdQ8SEDU@QL$ObG-E6y}+6&suN9JAJK`K^`1; zWJk>M^mX~Y?vb3LUl$lmzO~Wf9g}4tRABOBNLHSiGyK@#>YTufJpKDzlO|arIs-CV zGI)BMJgtj1X0(3M9Rm^hZy?Q($nqv3TE{T7B07IZSkxm-ZV*_iE<01+cXPA_FjTGH zl5NC#@Z;bPs&O|}Bb+41VFFv&b;98sL+|o5&(dXk?9K)VL371zbJ;<#YGZfKZ?c)v zDTRWzXm?^UO`^_<;iB2q;8N#@Tw2qOJyRvq=xm+VeInpaa`}tZXn`{&vrHXm7abG9jEr= zisnAUx>`RjJ4&alwL1O!AOx!-_;=O)vM<$e`;Tsk)!p3bArMQsG zSzN?#Z?Zq$H(+$+1S_yV>YKF7Da>5DyHuCWl66J-L~+2k6rc8Wh8oMM0!#Zp)Rhv# z*zmY5222#S0;4z;hx4~`Fz_e?cBJ@2e~f z18rlA{njr~7CNoT4kOkj?Yh{CK+!B~>ZdnQ)3Y_2SNB!c<)mjbS8pI$J8jKV-{pxP zwLfT%0FfP6vPeU}+MnCZz2jO$?yP%KyQ}J;kxgBSUGQX5wD!lf?pG;~z}$~b*8W-h z(aI}h=V6a+wFb*cGU$~2f0vW!Sq3i0Q;y(Z@0|5-mao!a#!MYhS0!hWtr>S)d%+ znT9oTIx~I4sW?4(KI-Et^_6Q17&@&e6hex^9ey8agUAm}6-nBm?D%=gGl{F2f=AEc zt_g08k6m3f#fiG(C*|7n@P;fm7AHYntaliy5n`bwik+kyX;ILv!@ks-hh+mLb_L@; zWvbZ)9gb~<*U$)@i7@OrLTrMH!s!5Kw|Gj1D8Cw8_GdW${9{Ogz*iWiYwD8|BVGbm z5;B9y!#iYMt@nwHAne8_iQH{U3P}DI?QjpHJn4b9f?5)|i0_?j_4&{YWwqK@5GG`P zYPCo$Q%H>_j+&9Wd@p|JnyxmOy2>WiRVgZ;fnd4>e3>nAzW6UoIa^ion%R2&q`6bc zx>PwQWN4#Weeieb+UVM7^qHZ`a5~BFbGbEthZt6<>nYGSP@4Ln3*tH(D(GbAk{}(a z!H_{V%FJy(ZrLN9I_F+arNPvUgW-vdm4mA4y3tln{Jup(@8uiRu5#a2w_8s2%W3_y3< zZqHeOuhXBfd<8_XKtv^xJ5G~{bOq09SZgo7^E_WvfJA*p*fi%r8%R6CGe((sUQ!h2 z*J86TLZaH|-J#}$2422pXQUEL?mN5GK57oWgxAC|Q(rqZ5{bQwrjeT(WvGe9Ic_<> z<~x7DT(rgzCi2IsrD})Io`e(Bp%WBo6s)I#@=Gn?O$_79fTFzZ>n*cY%)!?j9&AXLI)lAA^Rzp9+ZB}3sJn%eJam{0IsOq_{f{;dxEAP%>fw~UUa1W@F0iMQb^QwL~K)JxPxw7>tqx|9Wx{RK0wxYHhM6^RL9%x zS(c*qbj-i9VLvJ&Y#p&w#8^aot z;GfqBtB}7mqC#54kV&-{!Olk^y|y!`IaLP84d1$^s~u60_zz=r1%0-q=>pxX{< z_i@T8niayLH%?C_QmyMn8ED<3b6jO(D8IMX#?UKD6(vJ&K<#MhNS#7OMV~rp-Ap=e zI(@qN*?Fl~YpmQgc}sAMwbGWf*W$0V;h4vYYIHol3tSP)P$8oE&idfaJ&ke&C6iLe zr1v*Rzh^jaNeY@kO|JNu#=idJV)}U7=b8t`^_ys=V7Z`$!BuI`c*SJY$G!XIcTm<7 z^F2b7st4a)g$D!r+ms*?llG604+zHhWv*zv=r106#6IM3JoUlY+JW6m03$MH-p&{L zm$-PR`s^4}t??y9+9sW;Q9rRRF5*4yAap}wL)$(;oj8U7@J;>W0|AN`e~Xod&L{|( zFQ#ngF_!MTv}b<~@DLXLe06r@BJj(2Anz-^WR3EO$4fXADN;$w7e;@>>WK5}7b#|z z_Kq?WmKVznV-LuEsJ;O%rX`1LXQX=?U8TXze8Sj)mL|(&%NH!V7kZWB%&x*UK0_(c zq<+-=!BM!7(WI71c@9dt4WmS%n&>FtdQT(Bfn;lhBDP%41ebEFW#fKMn*fX4n5d5; z$XOrG%bKdXzn#HEH9Qh8t5~0ebxL)2ez^?n*@eqp0h0#C;13&CBj)%iYow9B%(6@W zQ}4Aqkx0IKrSQYyDpseZvs9j{FXq&w$zeXfxNU8K(M>kXcmLIW5%}+rQBY4Yszw*| zrbgtc`+ArJ^(MHY)CfN=Q>GK9s-}8>&6KX}|3%|{ zkA}7A=eq~FT?RzgOra_|<3Kg&m3C=uj{?5YPaP|?KHE80N?ql37Mw4aI&Sj^zFMzF zzs#NJ_B`X3jdhw;LJyw_&}%Ce{oPTgm@!?L>(S*-kSjYWdC zz=aebbem`E`_pH1doDMqd)j< zmCkx_k-TJ|sGqaztm4_)o3K(hUr7wGy)=8#gRx7<6*oV^;W0<}sj{RM30^~|Hi(uz zN6Kf{$}~O7XS{^VuU%99ebj|$s%qDcWwZiQ=a)67Vbzk-R6%f=xG#vXsUd% z|CV)oK__W-i^@mMK3aiCi9+D{X)Pz2FsduBO>##OcSK8_KfEjplM|#SEb?asbt}&) ztr3fU@>l2~26-4{^8M~m%w05lBa}jg2oAYblK^FAFJ!7>nsq_b|D>tZl`yPpeokAo zrW{9GK`k!|EmoMzyKt|c1XBxCI!ORl35p3hJn~j&oRi#f5hzxmWs;|%uj7=n>%QX9 zg{oENy91KO|I|~LooEPu6@7jG^@%J>S$P#db^Isag{eJfWDS^tFZV!P4b4EloA+CV zkG`d+RkD2A8TjbSN+gic%Bmpa{?`+_q>KgxGca-f?tX9P_=M4}i$(l~9~@46=*O;v z|1RTk`>Ug;Ly{tcaPsT8bh0uDW~AZlbcE8MSY|^9ViRI49{pWN?3SGS<;_VqH&d1_ zFg*uV?#4qnFS$76md`fxrZy>GSdMLvLWhLYF40Pj$p4f9d&G+^%=fyOXoDBEo)H9? z$DMP_+J{#uo4ZDMax_=+#RQj{hbrB(X!8sQDV!(7X-nkw2@e9-PFv*VTbA5XcGe!| zoy>ttj_60$@TmkY(}J3n1{crosCax5@%}>|$^wY$-VYt+XMa*pO5!|7D@{$7foKWV zDT)H@-NhCDhBk^Ayc6lXtE=WSL@Qp+q-j<`s>ZoJ2_*Sx&F}KLFciyDWxK)b34k4lB9klhGe&Rr90kBlxv0;C+o(w2D>l2ZRRXJ~J6+XMH%K&q~&*3kmP z&i6}HIW6<>=B|e_chi~^zZVoGwn#6i2=dOdO%bSBLua43);5S-v$Eiqh?79(M4q0W zNn)DCt0PSO$6!9?-U)r`hu?x@P~R`PD#?1PhHcspRsQ8ENI(%RUME{~K@A6v{ef-)L18fU&*0Qlj!=c^<#%IO1&*EVZfGZvx2b+E=xu zVK?zw?WTy$SD?5jk6v|{GsmF63sS?LHx@&*K28WkLZ=44h2}oXvW;8HpHEOX-|hl^p0I+{Q>H|P0J8qQs0@YD$ zQ+-S#Ipaws`RP)rf`3J%rWy7dHAL?5Lg4Qo%1bKbm{nn44v1v$_vaZ+Y?M@V9bYIY z=vmblMML8owR7G>k64Yc@KbmBj4oq&D3{pA;n&rh#pSsBOpedKr<2p;eglc3n%+f& z+WzQ8psw>@z2Mi*?AXReSsj>4i0hU401e9`V*5Xb$|kNVv!$X(Mz4yE8<+-xe|(yvE?{B-kwH@$gMKoZ+3I z`}#4ATNS+;OU=M}K>>EH{V_HkFMnzB(rAwEvyE@GdPQDA^0C3+*K+VYFhi4CVR`yBAHfYHKph*qWUe1Ex*FNh!yY^$2=%R zgUnHJMTuqd(ps7iVxV<|?eP@bGD^7c&ex|VsIpnmS5y%{xBBSF}1h+gnRtcB3_o)a#ISC#cWsEIJ~06FXIBJrt!q+D)RIPpzcUb=U( zt1IYsVA_P_Xm@E%7duWz-=uuU_#33TkKTpT+o6-88R!eE+;HsO>`SX2ySnM`5JQ{P z?>MHL*G)^I!3l`?2Yg-fwGmhD?j9F=_o z+v@7XZ#v-hqI{lECf=TKCOcfa6fwF9dq+DRla($KJrv^(Glgm##YSqrfsVz-=?8TX zi%-#@Q&v5{i4$Eh@e2@MEFzczHPp#h(1X@%Vo5V>px>31*aXqP86+wf)Z#|Z{nbN8uY>H zAh6UmHK2QMCfKD^4mz=GmfBhCtlFhG_8I)9<13GQH9vQOBT=J~bjvf19^fdRI=3n>z>yLXv?e#R&OhSICpzP2N zANlQ9NQBL=ycelHpQ99t*!|FT>my3KmYh~WuQk~I@a3b`=MGcSk8k11#QNSs9IFxM z@jirFRK~y*vsD}vnRXT*0$BzPhTOJ1%vJ{0BXBP?}@JX`c54wxVX&u$qtnRlGsHYN((TPJ*6_UydTU-6(Q^ zXXVr|g4y2#zYS`rL-DdYv_xuCdf~V#m^mmGj6~t4Y!OfLk$1W3Bw}V{&16(U+_WOS z)rK+IoQp(W78t)_bke^)<2kHoe>FlJ9_9GbJJv^xW5M^&|(8(3>ZO#lt#0+R7v&+ zy7s5}1;g0;n@yD%gUyW;BC=?h0H1H`6R1EHV*yIm=_-NFRs@ZPv^o81yCuR~+OFXK z^XSeIsI{7v-2qgR%p^gzyUxolRaMb7-EiAF%X1zdULG{;1{Il= zKbP8H{YBX9JeehV$_Q`YJ+>Z$*QK_$xTK6_5zT|kJ_o$h;31ZjED*!XePyCsI#0#_ zoPKu@X#hKhx1mkT9?`1thTHa27Gw|lclBdPJi}v` zRm>v`{d(n;7_Q-+r86F5Y?Ig1{!V`t0Zb$3Tnw%I&kmU<7x6{zFh0kPqTfqTXO%aM z2p7|e!mU+wVH06M`qB9EG!5ghuFerC0_s^B^k_xjCW)kUz5*f*exHmI$uEc1n`wb1 zw;sdTJ+fjoJrT0I(^eHzjS*MASeEz}JKrWKLiyKuRRz$R~CWDDUkQF|Gf6v zqCD){wZh-w+VI4aj|%U&d4@Ct3Rh41bRjqyR=Ha~Ew5VqPyKc!xd|9|j+Vz8HE2r) z&r3+`NSQwbzmzti@dHhwU%5wLS;zjI)*{A^-CiCuFF=BP|0ocQv6vaHMhG zs>0Ni&`VS5S2N__?v zm9?#Y%x?t*Hx)z8aRzOlGiHiS)dPdZ*SacwQHR3fz50Z$h)kyX+GwexSw5c4AAEFx z{4g`B;Y@6tAu!+kqO10RqsFCsf5q_KpsUdb-it0fkE(BHFAhxq_4<)0L-K2hC55q# zrwwQvOF8e2p5q$rH@^3~CUZ30(b}rYyMQrQbzp0wra+s#MsfIZ{nAfTv%Zi>{?#YT zi=N}v`8grIXV%Aoey!urvUr^0UHBGne$EByKQo>)Dx7;Xfc#5%TM@ z)u+G`f?b_SRk7s_P8r)fr~VgRX^1cb`N}W(E_nqc&2wC{1NA)PKMDN~%}o}zZHT0^aSt0?Ty`S$7(+wGMfai4$Kho_D!dOcoL`6E$$ zlYmc5R=Qfsh`st$_{LkyjO4G`pU?i5_I=)Z<=%;& z_?GHM(Ir)}w%|-M8;wlRN3&bTyP~^X_tc{toaIg&-f;aB_n)JadiGJ(=#N>|nvEK+ z8N74KdEbr$<>S=6lAgy}?;8Ff@eO%f@%2jU6u~P4H*H9LPkyTyL@RVZI`Q1@-)XpL z7#p}iR%Ps{R?_ZX>DLYX>7}8i6MEPw-uK?vI@oFA7iKkTRPnBlp5p^7W->T(en@54 zMR|Jt@3s4J0;A&$A%F30*tA|xF+c3_X7Kvi-R*gE`L)i*^+&ZSg42uoBvrp-hbOBOcjvU+ zzR!rcg*&QnnXGT57`YImS+3-=nc&Sog%}Lc>M8S2KU5>K&;C9GO5TC@?mL`4VHMMB zzW?`aXut-P-NL6-7M{EYbnZHGRJAK<@TVu=Mly#{#G^0CrQ#j=W5m?W8lf-=({U98 z&vV@8w@lTH)zQ-dHB0M8wj_3^J6-ob+1jGbAy&k6ijl_ULG|^8&Fb3{w>g^rM+>n2 z(bZ*@&+GG8TtDZYEWyZCc`i1&VjnOQqpP<9$C$T57?*yG#N%!=aFPCA3_8cyDa`IZ zapUG^H!geOcdF}U3>|yRxeM}(kMneql{B_~8T|hJy}m!rWO63pv+4CZMZ#9R4;`*@ zZOxyVjvW;@n(fI{X;%}M1ddy~w8JHSgsW}9hvgu&K&H6G(Q(ip1iL#itGAT7ePAn! zQh5Sb8)Nsfc%Q}FPP9End}gtZ_HzZb2I+?Q0mqL(mly56!TCRD5?M5GDt{psS=E_f zq54_$A?oERu;QFO)%*4z)H&SvM9qCl3c-YyHrQ*}ZH}W?<8`b)+&K*Do5Ng^_g}x@ zI&i}2EBwjx+UUh#$xEwj2J&oWxBuidfjH)%Evda(zBxngy}|3jhie_=!y)@1N7EZX zj}we6_3AVD0S5OWMXftVEkN)R(nP89rTZ;v)0J{lQmXhx-@Hf0;EmsFoZb1xI;69# z(;_!Bs;7GNEr#E>t6cv1gPY>2tB=_?7tM9BaHqe@n`T_{9GuCzcLxM%1?Ly{-FlxR zrB;_WKYg@?DLu`3ke3sn+x=+7>5wmiGt511J~zxHZ8U;RO? zXVNUZ`25Tw8=pZ>oKVJ#>DiJ_ej{e=vfwdBXvGif3EAHS7{F{@lHRXtLw3Et$ks=o7(alzlYPuOLFWn9Jl8RBMh zxIC2kx^=_dREB}47wej=qQMJ!>s758zNPvr|)kGiI)< z)Ah{#UEuE708>J~RF`=ukKGqVo2EurRs2Zm*LVype#;ScStdGl|e&ZAMFAM*k1Def+6q7W?qC ziWlxLugi6>jK0Ksv%TFS2~>aS=gJQvAH_$VwrOblR{cszQbQ2KmwlL_Ikrl$)Fml> zO>256+w8o$D8j-;=eMqgIEM_S(9Zhqr@fLH>zaFB<#)M03?}c_m+d=uJL0!az+zjb z!M@5K9rB8H*#&+hKbuvuzgKYV1^1tqUO{?C+3lr_g^ttME{VMQB=U2BV1+9j-)=AI z$tXQ<62J|&obSj|ukOUTeb1%Et#7@qB){T(%@ON7NeBA;Xy+8!nBWKT@%Z}OTYM<` zlkE*9w1obj-B}+N+_<*r_{w)RgJ%jFFa0&IIV^H5 z1e=1(sZHZOOT$*T#=T#t$~|lRxmPu(onr9y*S0rRc;|tat<#=J(CB1ftP}0o?(x<5 z&IC{jXd#9~ZK@ht8_TqsS(_%iQ;Cla{a3m&dw$yWfe_-OK0$>D;^6So@%9&3?#kCGf{$(1LEo zJ_T)Ud3x5LL};t!^K$(hVtqZx&9gHpW;&;P^2USVE&s)_yPYg8I%aDjWeKB;#)u7%qie z>U{G1-6Or@d$wq?&iWqp^UG_wpe+{1@0Yay>&z>!;fcU3z_nW(uuu>6bDFGy3z>v! z(}!&NH>Q^z4ci8N-Z2;X^~oc<4t-RuThC#U7ttMa^>DXCNV?Ud`@u@BoZ0Jf(<;%1 z?OJ!6KZ%^}0f(Qq4L|8U{H2deD?eO$RApOdxU}Tu9V`+it<<<0ViMmN+|_dJlOB^f zef~v3!8O~f6*gJd%LP%o^{_ucU@vz9HVDGXZlSWT)*V?L)7{P zfjfl9(Y5&T`Hb_QGt$>*s{LtsXc)G?dl@g&cG%x6_5ZzM=02zMwXX5C?{X@y6gAh( z3y4*1Dv|IuWLp5d-|33|0oS1YdwL)GiKQSgP_rDKiLBMkV>?);QCwnWi$=*qYb`Xi3fu}&h~u-EpJSx^gnPQxa7&vk$!pb4FbewRs%|P0hf9y)WJxvt8Lm8R+i?8DG2C^f%|I{;Fs82jmQNKWi z=vuU90}ijKzGHT7aMUVUV={s^_!SMJ_{=yoOa1=SgP=BFw~#J#y0|;Sq6nS9sDF;N zRwu-r!DrR6Oi^hfco|`GROZq7Ek4CmK%6KfKSMDEKWxfT_9I6ZSrlr2;iT&TUXTCZ z4;Sh;b1(G2OuP=9P5*rs7%POgf2kPkeQ1=LR05oSEJ^y`EruMg9*o!Q3JfQOOn%^88(O*kZbR;h z-^hi4wCk!xhHiowfHRWNacKNq{AK@G>M)pnh`H9DhDFdr!5yN5dbH4YKa8vF^YJN};`qDEep8T+9s~l8T zw|G96906Bh$!^)$Kj0xVesC;er#;DwA;G{u$s`?=qI?2))&AQ{1>YCXc_LDvwk+<4 zk{H3mL-aWUtN=2RL5A_r`EYM*rdws@WN)vVCu*_`wENYn2dgdD8bWtT+dh+^y+%%u zEcM>LNkEzZV+aCdltKW&HXKM_NaT{XkpM@|YDOM;(X#~kUQseKKJh}eHOlu6d(u09FYv#mi&9yNCzC%ubJpoi6p~7*3A$PBB z7eQ)H0Ps~mJ^hH&!2Fg096(n9geJXIGF=gl^sJfT6t9Oke|-sDl$m#0_MHByc&&kF z>6+^3va~i_{N%Ah^MVnG$<(i6j6ys1<^IEnkf#!50?8q52^=T5j1yG=8QAL5zzNz^ z5IsS0(`URPYzDxs(*bwfP|P$>>I8;-LPlRFr<;C0K@|PGU!A+TJYoS*_+TUCnajp? zaDS-%aa!R$YLvMGtg}#K6_bV^{!mo_Az0`k<*9 z@GSz6F%NE*+MHD!^^R6uCy7)nmDU{@W0Sb$klh-`p+mD;v;v}N0mw)Q@L9P4-w#B9 zeJFOI5m5EnYx0gnziX&!gVuR!wr8y&v-*xh4FFmff_iA*8*>r2pH(IMhIfCS@O#>g z(1V#^QzUTN-&?o@C$46_+Y+1mITvS%@fR- zD9t$u0o$F^I9^bth2TKlhy(~qHp3jm+u&*(WkZ^sky+m_{q&e#)E1qzitOs34aAkFu5Dda$>4rH-7km&7ngmqW-Ik=+#_=?n%64OKcKtk)+r9kRp?(oIsP5v<&!an#Ul5r!w*9cv$>)} zHm05r>17_@nfh}U&nMY?a=&xGeg>IjR%OOIf)b(034&*??Ty{1TAPrCm&pzy%o3+* znf-;Q0N5r#n94jVF52wvMCDxE1-EyrcCD-k(Vp$4p`KtPP+6K)73mNNvgx8|dppjB z=nn=YFYy5l9U3QsZsK!mwdq_$|JC%hUE2+-on?S=m+8BS{C*NJalALwNUxDE>xf~K zEs{Q|IKLTi{pZ=7g&EXA5QDn_DU)$IV3A~LeLrItMsrKbcn%A{04lX}Qy=KwDJ{Nv zQ3z}<$&79Y>=Ymp1<1{x@UTEJOQkRU?TI%|rC9E<1O3`~Yt1{mPd~m&t}UB0$o&R% z`j1`t8usdY^CF6Z^lN*q1@0pt7Q$v;-zP1y=(N1PYQtaUE5~q8{28RV1gc^|Xc&3@ zEO6}lZLEP2FmR69NPuUi2YI5?uhc_HTD&$1K-{P=h9bz(cl*%!pt1W8pZ~!h=o!Mm z2{0)5OxaE&AYe&*VH?vGF#0D(+wSkgMijtRBkUM_rQs`UX#)XqC1rbIFihFyB|>G| z;yAFw${ZiAL@<2fb?%&BN8BtPG#&^|?4S`dH>;lW`S+Lqwh?ua6o3P{dPOPRS z*42T9xWa2l#7VY=TF9os$UPNcF}3|jj}>$Z?=uuvPNAOUMJ1=7NBbB!#4KCPoiMki zNIcfSJ(Y{Y;9upuDKs=UX$JrOp(7yU|f@&j;64teDVm3qNmaCwrzq`E4t zs23Zu?QtC$TXqTFf#Xb@tO*AZ7t(VggMU!{539-b8{O%EW%nc4)h^;NU^{7t%C3b# zT$~dqm;q0c1fxRY4~_O%U@j)5RsbM!jVrA)MLSJ9!10lc5jSH;IqUVnfKwjGOpJ84 zn%n}D{O&;=@t@V#Mjw7#m?{x&|E(2jQMRZ>Q!cfxYm`Od@>Ir>5Fc7|9{|Aqe96Y@ z5q3fg)@C{~RpV1ozjmEE7IC_;;tPZN1W(kw0dI*_<*R*_2gmwni#QSKV#dBMF=+3- z4rWDtejn_F)(K^uPk~At$1+rLTLN(-iSNr<`$Z4&&zb5}l-H=5o30tYIXxJH)4*sm zxXeYfsC#1t8Kh!Dn#Q(ezsbmA9isVEMrG|!0y;!Aa;!D8Ck*$y=wd>k7h6d{1KG3% zFjHd^jJjIa;S#Ig%((oFekJAi1iTh%$3fZ_i}UEEO1c!w$qnLE7>JvQ4)vF}jisTZ zO>v?Q>MzC#;GCOXTQyRGtI@L2lpmRi%Y8uHOVqvjiNCca{Vqeh!af2Z=-rYKL5x@m!@!x}; zF7GmOJ|SS3Igvzt~6hDl}Rky zsDhf`?A7Y<;FJYr1cZ-i&goa`&8Y2|fH!oDC(VcKUOmHzvZH6TG2v&vYvhHESrFXl zd(QMItXLiAK)0~a&#{j2+mQCt$9YrSVhJ1kV5MZf7nt(Tma`^C6F4NmGM95PMMeRl z+?p**D@9ta$7C1-3AZ-nRO|9d6p7Bm)yJoqm6}ow8yFGw=L{e+k?c-09h4oHQbmzS zbU8}<-Uw15VL)|2m|QcL=QjqCin^!f!We2^$t3Yui&z9@O%lq1>{GDeC|&s0KbNZD z&)}ejAns(lQJ~&}6_56#;rCQtB9*yH=oD3CJMRd$I2=ibkG)*8!RR(Pd zhbKwtE!^^5Ia*cm0dZ!~Yt3PydPwOoXX%f5jaq#J$i%Ye?+&_m;*a&vWzoz|r`@IR zyP1EK_H4_()J*E8>{|}Q6gfCuQUN|-|)V(NT(EA478(@m9x+raB`(ZA<_Z zgPqC$z=9Ye*7Y>9u;|s}MTvQkU8fRYrJR5W<-L~e@#)`7{I2n}GvVT_EdQFfMPKSR zY-JZLaS7FN1CIYJD1k78ClDT>xMZ+}KRRW^OO+#YgYdcauQp}5PGzoWYnHo&s1mDP zE0>&0@;-bG{~%5HqAE>AlVv9ADdHz;q0GZ~o*Mx}Ejq)jgr@v)P^kh`9gh$O!pc(9 z@%+kN8qsVS_p0BbNzpP7>RFSx(wKWY(msD;#{mh+7xC7cYKQ|S87fPQ)mNHim=7BH zQBV$<`#xpWA<>xrIaPBUe2O6_xT&RpGU~qK!f9&I=RkahK7f4U)PY+EUMrhIwsT3L zCUiup61>l=a^sbds#zL8Udg;Sj<|uP#8#u7T51*&voOD6GDwnS8F2B2x z?&3N)2KsC#vG+b5IbD(k7jV#aKeO~%`G`qm(e-jn&S6i)k#UmCHEbCjmG(ZYg=4YCd&V+{S?I0|#6E6&xoAg6yI>%5z$W-jo%4;vx=2 zXhVIaRy|%Uu=#T^{^0t7aVgHEEGR_X8()1ddx^LN-@)IVW$S%2X?PBaK{;=^hOahh zPOL$oPhSm2a3Gd3x*9}Z4N_y%bQ8M8TU)l=4oV5(Ym}u0k{D%n9l_rd=2}?nR;D{N zaFYW@r`47n6X{efB=w!#4u9M9i_0_|l{HvWBkF*|O$9@`wb^@f<~b~G>5z=POwx)y zYi?K)_S%@vO6bX-MMA$ow6T@>{a@#>rfXfg!I`2@vvnfoY-8`9xz4c?pD_LXLmT}#f1f}BhrFWZs zJ^KNE9X{EbmTphvrdxpD$q8j5RdWVbAiOa7Xj6DS)O%6b!}$E$E;>&17WNIKSD?5I z!j_Dk&}5Hf8>4F1R$@JDnqoPE@V6UtvxPOY#k|29r1F&mZbxk;D@3`4AyzT6eEvW} zZzdSKmoWMsQ_+ev^sNKig>XOCYg9;dK&SRI{|!sJ2jx zx3j)*#Q8}kCtJi7+!{*)wB0E0O8t>=U?;5>MCAH){9WdUvz-7Dk4Xxi5hPM|?rL&R zK0#isP(Gba3tep6XbN4eFMNLecW_+&VM>dI`Hfpks4|!M_rHgA2TSc&eiW4rSem>a z^Zh;0HBsnocfm-$v0;}!^~a%{spjIHM?~3qHgAke94n27jxdF+(o+`@-<4- zsbmN*#oBpR)O>@*T~4@_<((GF#;1+r&t;@1d>ng4bN)d46GT8bP{=p)4R}R>BA3M? z-C9feK@Jr1cJ>;6gA#G4Qw#Dbd4leN6Co49dlWT~!=yLwfye z{8lLJxgcY%YpLS__H7iKpCE%`{rS!858A!9&6u#i9f_I3mJvm#3*xpP2J&c7BeVp< zxt}&#(kW}px@)|Nj=(8Uu}}9Bv!H`G()CAutjPg?2ZlPa)nZ&QA={tFJ^LA*-h}HD zc4?On(mSF%=g?Q=2Ft$Za5AcJbE5U}jn7@9@G7rr0&I%&H`FI>zpT`sPOw00Oh>i; z%t{0vW$EsOtyaiUsS36TLCaBl86U9CAej9IrtEfbf>|Gd!daVl$hv^z3 z0?dT0ch-57h0TrL>KgP1)-bU@{`wrK75SUSG;7Mr+|c+|&*Tf_&a zlWQATA1YWzu>Im%Ss{egD>-OtWa+nK;%GfqU(GXn7OCok#Rnfeehk;Iy1P4M#W!Sk zzG27gsxkH;hRS-1wfoKM6z?_+x7woo=OA`QsA@`*K- z=43iqg<akL9vkBCd^s1(OInrAJk+?_vcdKaRC5P)Ga zlkgVw&d!<2RYPL_=GE(GmRaA?IU^%Qu5xQ2G9k1`xfeKSJsPdXlbFobBaJfKWMo$h zP3?hddt7{25FIMh3jO&&;ZBu>E3Jm=OR`ZE%Vfp>`w$McP{CctgTe?TS%^wosI1g) zmPUil%c#xs$`fAcx+|%L-6j?dT(t7-Xi^G9g%)9P_~p6^Idi@sec^5;m^X=O>3B%9 z6U$jWc$x8~pIU6ZK>51)&_=SV`AlIl)Ns9QxGbvvB38|gwp&0riS8Opu&cYf?;{|4 zp1TwcXJ?`C213@l-0u*s))#uVKG;ZvP3m!ay6*7VfTkJ6^G0fOaG&*I3_3z6?dE|XM{7c_Bnei&IcN<#=jRiVWIGh#|6 z=6+76(RV*J_yqdQY6zTucqDnliB-(Rr)G=O%xITY-g3v&);1RX9I3zI$%t@4C*9} zRv}>~bMe3lyZ*7ST+*-c+s^7Hye^5!2(jUVDucr z1B_@o@0dU~>PbO7=cEs2ay2@D2$c{7MXw_w(~_#o6TgJAhV;4S&N-~SR^RSIBGebL zdd;D;!-Dtlu=UAzd-CZ-l9O+dX5@o=|=W>$>Ya z*O-8+Cfab-X+GGr{~<}!zerpM$lUp6Bejj!WK&-w)!9+r;U?!mkp1=NZUO(uknjSa z7U@D8wj12O~&|!IdF*tZAE(c0D zCL66Pch2Hi)5g|3@a!hpXlD4>Q>cjq>#hXZ_x~yC+T)pC!}yv@Y&aXa*0PaXX-X*6 zG51R+6kW7(IA&N%cvHQDW+2x*R&3LPVXVv~;6fk`$fuyuYo_ z*?;@I+w(r}^SsZy-=63DKHm-}Jb&xJNJ-UsdI>MnWF!%QrrwhqiNiG% zm-!@BUC9;U%AkTT#*YSCsdhxEs^y&9xP;5ThrXHbO4p&h9Sa~u^R@M9dpCbBtTqoO zMamlmoD^tCw&M30S)+sV{I#7o|42?6BsXi_CqHM)Pmv7jAlG|x?=bX6T*}*^EZ(5T zh&>mZT!8Ar6zV|#-pVT7O}L%M+BFdl5IxBQ_CYIdl^Nf8c9NO8H7_7?#;VQ6wlW6bDZ}XVYC8!FO!s76cNYY=R8Svg^!J_p%TBOg$KE0+t!mNx z@j6RiT!)BYq#yE;_KLi&(qkc#9-pSwFglD%3CEIRrEx7@nQi8@mWl^mO?My58F$zvhfjy};W zc0b8_7R(xe3qQuJ9(b`-s>h8PA^QI#&x#53d&{gdIR`gd7Z3uJo3Y%-Sz8R z3oj@`d+>)8JThX0OD%Wbsg3wYjyJWNo90%^8tQYdL)k7;V}V}Aof%6H4n=VcNRSU? z_0=L{d=!CedXk=V@!}2hLYE|Z$ct-IAK!=vP2A2;@*LLWX;+_yR=`E%51A>pB z-V~Q<0?HcU-72TO)mKf`Zs|LliiiNzvuV#r`9RZlY@xNFfX*>@U4O;ESYMAOJS!$* zK51D2_O#cjcSKdZ07Z{9vk1Hgs1piHXwULRGJIWBjXoB~Y#I zmn8~`r$x3W7KZu})bwcn(kMfWYDKUXooRF8*liFoC1zFohh4%xcLj;3^SZ@Pz5GIZ z#|9e~f}pJK%dPKSyK~Ec--Nvdf=R7FhBf(Q_#m5;^DD^M3bnXDAsU)4K2y;g)eG%L ztoMSVI=T+QM%Fom^{j`FTgQVXZQ?`XRFI!Ni#h0yH>a&8vlEmFutL%Esxj<}678%D zqqk4;75ToSC|U~VzB`4zO=oC=7VGdMLmMzHIuRRv(BQfI zkP=fC5jae+pa^ZU`}?l0g+0eeLBZ`d*x`dE%3xafN#!rr#MZh8ofh@3%X^k79f0gq zs`{+20t=;5)bn(^dT*JM6{rOxcuAF9#dKuMfmyxWTPra{DR?9Sc_bkungSl-+9PM# zJM=k)VxsTq!t(BQa-M7gj}+I!ZTr&N_WX%QXmPVVsc6(p$}&_0i9QHssU@->Do14? z*nfF5bmT>$dIxQb(drskrEkB3)q5OaChKve#Q5qaoIH`MJK{2ImYp2&f<&%buugq1NC#d>bD=Z6}@qe T?XrE0gO|T|pjV|w#G(HHz@)&x literal 0 HcmV?d00001 diff --git a/versioned_docs/version-0.45/develop/advanced-concepts/cli.md b/versioned_docs/version-0.45/develop/advanced-concepts/cli.md new file mode 100644 index 000000000..36a225cb3 --- /dev/null +++ b/versioned_docs/version-0.45/develop/advanced-concepts/cli.md @@ -0,0 +1,156 @@ + + +# Command-Line Interface + +This document describes how commmand-line interface (CLI) works on a high-level, for an [**application**](../basics/app-anatomy.md). A separate document for implementing a CLI for an SDK [**module**](../building-modules/intro.md) can be found [here](../building-modules/module-interfaces.md#cli). {synopsis} + +## Command-Line Interface + +### Example Command + +There is no set way to create a CLI, but SDK modules typically use the [Cobra Library](https://github.com/spf13/cobra). Building a CLI with Cobra entails defining commands, arguments, and flags. [**Commands**](#commands) understand the actions users wish to take, such as `tx` for creating a transaction and `query` for querying the application. Each command can also have nested subcommands, necessary for naming the specific transaction type. Users also supply **Arguments**, such as account numbers to send coins to, and [**Flags**](#flags) to modify various aspects of the commands, such as gas prices or which node to broadcast to. + +Here is an example of a command a user might enter to interact with the simapp CLI `simd` in order to send some tokens: + +```bash +simd tx bank send $MY_VALIDATOR_ADDRESS $RECIPIENT 1000stake --gas auto --gas-prices +``` + +The first four strings specify the command: + +- The root command for the entire application `simd`. +- The subcommand `tx`, which contains all commands that let users create transactions. +- The subcommand `bank` to indicate which module to route the command to ([`x/bank`](../../x/bank/spec/README.md) module in this case). +- The type of transaction `send`. + +The next two strings are arguments: the `from_address` the user wishes to send from, the `to_address` of the recipient, and the `amount` they want to send. Finally, the last few strings of the command are optional flags to indicate how much the user is willing to pay in fees (calculated using the amount of gas used to execute the transaction and the gas prices provided by the user). + +The CLI interacts with a [node](../core/node.md) to handle this command. The interface itself is defined in a `main.go` file. + +### Building the CLI + +The `main.go` file needs to have a `main()` function that creates a root command, to which all the application commands will be added as subcommands. The root command additionally handles: + +- **setting configurations** by reading in configuration files (e.g. the sdk config file). +- **adding any flags** to it, such as `--chain-id`. +- **instantiating the `codec`** by calling the application's `MakeCodec()` function (called `MakeTestEncodingConfig` in `simapp`). The [`codec`](../core/encoding.md) is used to encode and decode data structures for the application - stores can only persist `[]byte`s so the developer must define a serialization format for their data structures or use the default, Protobuf. +- **adding subcommand** for all the possible user interactions, including [transaction commands](#transaction-commands) and [query commands](#query-commands). + +The `main()` function finally creates an executor and [execute](https://godoc.org/github.com/spf13/cobra#Command.Execute) the root command. See an example of `main()` function from the `simapp` application: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/simapp/simd/main.go#L12-L24 + +The rest of the document will detail what needs to be implemented for each step and include smaller portions of code from the `simapp` CLI files. + +## Adding Commands to the CLI + +Every application CLI first constructs a root command, then adds functionality by aggregating subcommands (often with further nested subcommands) using `rootCmd.AddCommand()`. The bulk of an application's unique capabilities lies in its transaction and query commands, called `TxCmd` and `QueryCmd` respectively. + +### Root Command + +The root command (called `rootCmd`) is what the user first types into the command line to indicate which application they wish to interact with. The string used to invoke the command (the "Use" field) is typically the name of the application suffixed with `-d`, e.g. `simd` or `gaiad`. The root command typically includes the following commands to support basic functionality in the application. + +- **Status** command from the SDK rpc client tools, which prints information about the status of the connected [`Node`](../core/node.md). The Status of a node includes `NodeInfo`,`SyncInfo` and `ValidatorInfo`. +- **Keys** [commands](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/client/keys) from the SDK client tools, which includes a collection of subcommands for using the key functions in the SDK crypto tools, including adding a new key and saving it to the keyring, listing all public keys stored in the keyring, and deleting a key. For example, users can type `simd keys add ` to add a new key and save an encrypted copy to the keyring, using the flag `--recover` to recover a private key from a seed phrase or the flag `--multisig` to group multiple keys together to create a multisig key. For full details on the `add` key command, see the code [here](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/client/keys/add.go). For more details about usage of `--keyring-backend` for storage of key credentials look at the [keyring docs](../run-node/keyring.md). +- **Server** commands from the SDK server package. These commands are responsible for providing the mechanisms necessary to start an ABCI Tendermint application and provides the CLI framework (based on [cobra](github.com/spf13/cobra)) necessary to fully bootstrap an application. The package exposes two core functions: `StartCmd` and `ExportCmd` which creates commands to start the application and export state respectively. Click [here](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/server) to learn more. +- [**Transaction**](#transaction-commands) commands. +- [**Query**](#query-commands) commands. + +Next is an example `rootCmd` function from the `simapp` application. It instantiates the root command, adds a [_persistent_ flag](#flags) and `PreRun` function to be run before every execution, and adds all of the necessary subcommands. + ++++ https://github.com/cosmos/cosmos-sdk/blob/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 SDK, which can be over-written via `initAppConfig()`. +Here's an example code to override default `app.toml` template. + ++++ https://github.com/cosmos/cosmos-sdk/blob/4eea4cafd3b8b1c2cd493886db524500c9dd745c/simapp/simd/cmd/root.go#L84-L117 + +The `initAppConfig()` also allows overriding the default 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 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. + ++++ 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. + +### Transaction Commands + +[Transactions](./transactions.md) are objects wrapping [`Msg`s](../building-modules/messages-and-queries.md#messages) that trigger state changes. To enable the creation of transactions using the CLI interface, a function `txCmd` is generally added to the `rootCmd`: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/simapp/simd/cmd/root.go#L86-L92 + +This `txCmd` function adds all the transaction available to end-users for the application. This typically includes: + +- **Sign command** from the [`auth`](../../x/auth/spec/README.md) module that signs messages in a transaction. To enable multisig, add the `auth` module's `MultiSign` command. Since every transaction requires some sort of signature in order to be valid, the signing command is necessary for every application. +- **Broadcast command** from the SDK client tools, to broadcast transactions. +- **All [module transaction commands](../building-modules/module-interfaces.md#transaction-commands)** the application is dependent on, retrieved by using the [basic module manager's](../building-modules/module-manager.md#basic-manager) `AddTxCommands()` function. + +Here is an example of a `txCmd` aggregating these subcommands from the `simapp` application: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/simapp/simd/cmd/root.go#L123-L149 + +### Query Commands + +[**Queries**](../building-modules/messages-and-queries.md#queries) are objects that allow users to retrieve information about the application's state. To enable the creation of transactions using the CLI interface, a function `txCmd` is generally added to the `rootCmd`: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/simapp/simd/cmd/root.go#L86-L92 + +This `queryCmd` function adds all the queries available to end-users for the application. This typically includes: + +- **QueryTx** and/or other transaction query commands] from the `auth` module which allow the user to search for a transaction by inputting its hash, a list of tags, or a block height. These queries allow users to see if transactions have been included in a block. +- **Account command** from the `auth` module, which displays the state (e.g. account balance) of an account given an address. +- **Validator command** from the SDK rpc client tools, which displays the validator set of a given height. +- **Block command** from the SDK rpc client tools, which displays the block data for a given height. +- **All [module query commands](../building-modules/module-interfaces.md#query-commands)** the application is dependent on, retrieved by using the [basic module manager's](../building-modules/module-manager.md#basic-manager) `AddQueryCommands()` function. + +Here is an example of a `queryCmd` aggregating subcommands from the `simapp` application: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/simapp/simd/cmd/root.go#L99-L121 + +## Flags + +Flags are used to modify commands; developers can include them in a `flags.go` file with their CLI. Users can explicitly include them in commands or pre-configure them by inside their [`app.toml`](../run-node/run-node.md#configuring-the-node-using-apptoml). Commonly pre-configured flags include the `--node` to connect to and `--chain-id` of the blockchain the user wishes to interact with. + +A _persistent_ flag (as opposed to a _local_ flag) added to a command transcends all of its children: subcommands will inherit the configured values for these flags. Additionally, all flags have default values when they are added to commands; some toggle an option off but others are empty values that the user needs to override to create valid commands. A flag can be explicitly marked as _required_ so that an error is automatically thrown if the user does not provide a value, but it is also acceptable to handle unexpected missing flags differently. + +Flags are added to commands directly (generally in the [module's CLI file](../building-modules/module-interfaces.md#flags) where module commands are defined) and no flag except for the `rootCmd` persistent flags has to be added at application level. It is common to add a _persistent_ flag for `--chain-id`, the unique identifier of the blockchain the application pertains to, to the root command. Adding this flag can be done in the `main()` function. Adding this flag makes sense as the chain ID should not be changing across commands in this application CLI. Here is an example from the `simapp` application: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/simapp/simd/cmd/root.go#L118-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: + +```sh +gaia --home=./ --node= --chain-id="testchain-1" --keyring-backend=test tx ... --from= +``` + +this will be more convinient: + +```sh +# define env variables in .env, .envrc etc +GAIA_HOME= +GAIA_NODE= +GAIA_CHAIN_ID="testchain-1" +GAIA_KEYRING_BACKEND="test" + +# and later just use +gaia tx ... --from= +``` + +## Configurations + +It is vital that the root command of an application uses `PersistentPreRun()` cobra command property for executing the command, so all child commands have access to the server and client contexts. These contexts are set as their default values initially and maybe modified, scoped to the command, in their respective `PersistentPreRun()` functions. Note that the `client.Context` is typically pre-populated with "default" values that may be useful for all commands to inherit and override if necessary. + +Here is an example of an `PersistentPreRun()` function from `simapp``: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/simapp/simd/cmd/root.go#L54-L60 + +The `SetCmdClientContextHandler` call reads persistent flags via `ReadPersistentCommandFlags` which creates a `client.Context` and sets that on the root command's `Context`. + +The `InterceptConfigsPreRunHandler` call creates a viper literal, default `server.Context`, and a logger and sets that on the root command's `Context`. The `server.Context` will be modified and saved to disk via the internal `interceptConfigs` call, which either reads or creates a Tendermint configuration based on the home path provided. In addition, `interceptConfigs` also reads and loads the application configuration, `app.toml`, and binds that to the `server.Context` viper literal. This is vital so the application can get access to not only the CLI flags, but also to the application configuration values provided by this file. + +## Next {hide} + +Learn about [events](./events.md) {hide} diff --git a/versioned_docs/version-0.45/develop/advanced-concepts/context.md b/versioned_docs/version-0.45/develop/advanced-concepts/context.md new file mode 100644 index 000000000..1fc74bd8a --- /dev/null +++ b/versioned_docs/version-0.45/develop/advanced-concepts/context.md @@ -0,0 +1,104 @@ + + +# Context + +The `context` is a data structure intended to be passed from function to function that carries information about the current state of the application. It provides an access to a branched storage (a safe branch of the entire state) as well as useful objects and information like `gasMeter`, `block height`, `consensus parameters` and more. {synopsis} + +## Pre-requisites Readings + +- [Anatomy of an SDK Application](../basics/app-anatomy.md) {prereq} +- [Lifecycle of a Transaction](../basics/tx-lifecycle.md) {prereq} + +## Context Definition + +The SDK `Context` is a custom data structure that contains Go's stdlib [`context`](https://golang.org/pkg/context) as its base, and has many additional types within its definition that are specific to the Cosmos SDK. 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. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/types/context.go#L16-L39 + +- **Context:** The base type is a Go [Context](https://golang.org/pkg/context), which is explained further in the [Go Context Package](#go-context-package) section below. +- **Multistore:** Every application's `BaseApp` contains a [`CommitMultiStore`](./store.md#multistore) which is provided when a `Context` is created. Calling the `KVStore()` and `TransientStore()` methods allows modules to fetch their respective [`KVStore`](./store.md#base-layer-kvstores) using their unique `StoreKey`. +- **ABCI Header:** The [header](https://tendermint.com/docs/spec/abci/abci.html#header) is an ABCI type. It carries important information about the state of the blockchain, such as block height and proposer of the current block. +- **Chain ID:** The unique identification number of the blockchain a block pertains to. +- **Transaction Bytes:** The `[]byte` representation of a transaction being processed using the context. Every transaction is processed by various parts of the SDK and consensus engine (e.g. Tendermint) throughout its [lifecycle](../basics/tx-lifecycle.md), some of which to not have any understanding of transaction types. Thus, transactions are marshaled into the generic `[]byte` type using some kind of [encoding format](./encoding.md) such as [Amino](./encoding.md). +- **Logger:** A `logger` from the Tendermint libraries. Learn more about logs [here](https://tendermint.com/docs/tendermint-core/how-to-read-logs.html#how-to-read-logs). Modules call this method to create their own unique module-specific logger. +- **VoteInfo:** A list of the ABCI type [`VoteInfo`](https://tendermint.com/docs/spec/abci/abci.html#voteinfo), which includes the name of a validator and a boolean indicating whether they have signed the block. +- **Gas Meters:** Specifically, a [`gasMeter`](../basics/gas-fees.md#main-gas-meter) for the transaction currently being processed using the context and a [`blockGasMeter`](../basics/gas-fees.md#block-gas-meter) for the entire block it belongs to. Users specify how much in fees they wish to pay for the execution of their transaction; these gas meters keep track of how much [gas](../basics/gas-fees.md) has been used in the transaction or block so far. If the gas meter runs out, execution halts. +- **CheckTx Mode:** A boolean value indicating whether a transaction should be processed in `CheckTx` or `DeliverTx` mode. +- **Min Gas Price:** The minimum [gas](../basics/gas-fees.md) price a node is willing to take in order to include a transaction in its block. This price is a local value configured by each node individually, and should therefore **not be used in any functions used in sequences leading to state-transitions**. +- **Consensus Params:** The ABCI type [Consensus Parameters](https://tendermint.com/docs/spec/abci/apps.html#consensus-parameters), which specify certain limits for the blockchain, such as maximum gas for a block. +- **Event Manager:** The event manager allows any caller with access to a `Context` to emit [`Events`](./events.md). Modules may define module specific + `Events` by defining various `Types` and `Attributes` or use the common definitions found in `types/`. Clients can subscribe or query for these `Events`. These `Events` are collected throughout `DeliverTx`, `BeginBlock`, and `EndBlock` and are returned to Tendermint for indexing. For example: + +```go +ctx.EventManager().EmitEvent(sdk.NewEvent( + sdk.EventTypeMessage, + sdk.NewAttribute(sdk.AttributeKeyModule, types.AttributeValueCategory)), +) +``` + +## Go Context Package + +A basic `Context` is defined in the [Golang Context Package](https://golang.org/pkg/context). A `Context` +is an immutable data structure that carries request-scoped data across APIs and processes. Contexts +are also designed to enable concurrency and to be used in goroutines. + +Contexts are intended to be **immutable**; they should never be edited. Instead, the convention is +to create a child context from its parent using a `With` function. For example: + +```go +childCtx = parentCtx.WithBlockHeader(header) +``` + +The [Golang Context Package](https://golang.org/pkg/context) documentation instructs developers to +explicitly pass a context `ctx` as the first argument of a process. + +## Store branching + +The `Context` contains a `MultiStore`, which allows for branchinig and caching functionality using `CacheMultiStore` +(queries in `CacheMultiStore` are cached to avoid future round trips). +Each `KVStore` is branched in a safe and isolated ephemeral storage. Processes are free to write changes to +the `CacheMultiStore`. If a state-transition sequence is performed without issue, the store branch can +be committed to the underlying store at the end of the sequence or disregard them if something +goes wrong. The pattern of usage for a Context is as follows: + +1. A process receives a Context `ctx` from its parent process, which provides information needed to + perform the process. +2. The `ctx.ms` is a **branched store**, i.e. a branch of the [multistore](./store.md#multistore) is made so that the process can make changes to the state as it executes, without changing the original`ctx.ms`. This is useful to protect the underlying multistore in case the changes need to be reverted at some point in the execution. +3. The process may read and write from `ctx` as it is executing. It may call a subprocess and pass + `ctx` to it as needed. +4. When a subprocess returns, it checks if the result is a success or failure. If a failure, nothing + needs to be done - the branch `ctx` is simply discarded. If successful, the changes made to + the `CacheMultiStore` can be committed to the original `ctx.ms` via `Write()`. + +For example, here is a snippet from the [`runTx`](./baseapp.md#runtx-and-runmsgs) function in +[`baseapp`](./baseapp.md): + +```go +runMsgCtx, msCache := app.cacheTxContext(ctx, txBytes) +result = app.runMsgs(runMsgCtx, msgs, mode) +result.GasWanted = gasWanted + +if mode != runTxModeDeliver { + return result +} + +if result.IsOK() { + msCache.Write() +} +``` + +Here is the process: + +1. Prior to calling `runMsgs` on the message(s) in the transaction, it uses `app.cacheTxContext()` + to branch and cache the context and multistore. +2. `runMsgCtx` - the context with branched store, is used in `runMsgs` to return a result. +3. If the process is running in [`checkTxMode`](./baseapp.md#checktx), there is no need to write the + changes - the result is returned immediately. +4. If the process is running in [`deliverTxMode`](./baseapp.md#delivertx) and the result indicates + a successful run over all the messages, the branched multistore is written back to the original. + +## Next {hide} + +Learn about the [node client](./node.md) {hide} diff --git a/versioned_docs/version-0.45/develop/advanced-concepts/encoding.md b/versioned_docs/version-0.45/develop/advanced-concepts/encoding.md new file mode 100644 index 000000000..084cffada --- /dev/null +++ b/versioned_docs/version-0.45/develop/advanced-concepts/encoding.md @@ -0,0 +1,261 @@ + + +# Encoding + +While encoding in the SDK used to be mainly handled by `go-amino` codec, the SDK is moving towards using `gogoprotobuf` for both state and client-side encoding. {synopsis} + +## Pre-requisite Readings + +- [Anatomy of an SDK application](../basics/app-anatomy.md) {prereq} + +## Encoding + +The Cosmos SDK utilizes two binary wire encoding protocols, [Amino](https://github.com/tendermint/go-amino/) which is an object encoding specification and [Protocol Buffers](https://developers.google.com/protocol-buffers), a subset of Proto3 with an extension for +interface support. See the [Proto3 spec](https://developers.google.com/protocol-buffers/docs/proto3) +for more information on Proto3, which Amino is largely compatible with (but not with Proto2). + +Due to Amino having significant performance drawbacks, being reflection-based, and +not having any meaningful cross-language/client support, Protocol Buffers, specifically +[gogoprotobuf](https://github.com/gogo/protobuf/), is being used in place of Amino. +Note, this process of using Protocol Buffers over Amino is still an ongoing process. + +Binary wire encoding of types in the Cosmos SDK can be broken down into two main +categories, client encoding and store encoding. Client encoding mainly revolves +around transaction processing and signing, whereas store encoding revolves around +types used in state-machine transitions and what is ultimately stored in the Merkle +tree. + +For store encoding, protobuf definitions can exist for any type and will typically +have an Amino-based "intermediary" type. Specifically, the protobuf-based type +definition is used for serialization and persistence, whereas the Amino-based type +is used for business logic in the state-machine where they may converted back-n-forth. +Note, the Amino-based types may slowly be phased-out in the future so developers +should take note to use the protobuf message definitions where possible. + +In the `codec` package, there exists two core interfaces, `Marshaler` and `ProtoMarshaler`, +where the former encapsulates the current Amino interface except it operates on +types implementing the latter instead of generic `interface{}` types. + +In addition, there exists two implementations of `Marshaler`. The first being +`AminoCodec`, where both binary and JSON serialization is handled via Amino. The +second being `ProtoCodec`, where both binary and JSON serialization is handled +via Protobuf. + +This means that modules may use Amino or Protobuf encoding but the types must +implement `ProtoMarshaler`. If modules wish to avoid implementing this interface +for their types, they may use an Amino codec directly. + +### Amino + +Every module uses an Amino codec to serialize types and interfaces. This codec typically +has types and interfaces registered in that module's domain only (e.g. messages), +but there are exceptions like `x/gov`. Each module exposes a `RegisterLegacyAminoCodec` function +that allows a user to provide a codec and have all the types registered. An application +will call this method for each necessary module. + +Where there is no protobuf-based type definition for a module (see below), Amino +is used to encode and decode raw wire bytes to the concrete type or interface: + +```go +bz := keeper.cdc.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`) + +### Gogoproto + +Modules are encouraged to utilize Protobuf encoding for their respective types. In the 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). + +### Guidelines for protobuf message definitions + +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: + +- 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` + +### Transaction Encoding + +Another important use of Protobuf is the encoding and decoding of +[transactions](./transactions.md). Transactions are defined by the application or +the SDK but 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. + +- The `TxEncoder` object performs the encoding. +- The `TxDecoder` object performs the decoding. + ++++ 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): + ++++ 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. + +### Interface Encoding and Usage of `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): + +```proto +message Profile { + // account is the account associated to a profile. + cosmos.auth.v1beta1.BaseAccount account = 1; + // bio is a short description of the account. + string bio = 4; +} +``` + +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? + ++++ 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: + +```protobuf +message Profile { + // account is the account associated to a profile. + google.protobuf.Any account = 1 [ + (cosmos_proto.accepts_interface) = "AccountI"; // Asserts that this field only accepts Go types implementing `AccountI`. It is purely informational for now. + ]; + // bio is a short description of the account. + string bio = 4; +} +``` + +To add an account inside a profile, we need to "pack" it inside an `Any` first, using `codectypes.NewAnyWithValue`: + +```go +var myAccount AccountI +myAccount = ... // Can be a BaseAccount, a ContinuousVestingAccount or any struct implementing `AccountI` + +// Pack the account into an Any +accAny, err := codectypes.NewAnyWithValue(myAccount) +if err != nil { + return nil, err +} + +// Create a new Profile with the any. +profile := Profile { + Account: accAny, + Bio: "some bio", +} + +// We can then marshal the profile as usual. +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 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). + +The reverse operation of retrieving the concrete Go type from inside an `Any`, called "unpacking", is done with the `GetCachedValue()` on `Any`. + +```go +profileBz := ... // The proto-encoded bytes of a Profile, e.g. retrieved through gRPC. +var myProfile Profile +// Unmarshal the bytes into the myProfile struct. +err := cdc.Unmarshal(profilebz, &myProfile) + +// Let's see the types of the Account field. +fmt.Printf("%T\n", myProfile.Account) // Prints "Any" +fmt.Printf("%T\n", myProfile.Account.GetCachedValue()) // Prints "BaseAccount", "ContinuousVestingAccount" or whatever was initially packed in the Any. + +// Get the address of the accountt. +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: + +```go +func (p *Profile) UnpackInterfaces(unpacker codectypes.AnyUnpacker) error { + if p.Account != nil { + var account AccountI + return unpacker.UnpackAny(p.Account, &account) + } + + return nil +} +``` + +The `UnpackInterfaces` gets called recursively on all structs implementing this method, to allow all `Any`s to have their `GetCachedValue()` correctly populated. + +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). + +#### `Any` Encoding in the SDK + +The above `Profile` example is a fictive example used for educational purposes. In the SDK, we use `Any` encoding in several places (non-exhaustive list): + +- 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. + +A real-life example of encoding the pubkey as `Any` inside the Validator struct in x/staking is shown in the following example: + ++++ 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? + +**Defining module types** + +Protobuf types can be defined to encode: + +- state +- [`Msg`s](../building-modules/messages-and-queries.md#messages) +- [Query services](../building-modules/query-services.md) +- [genesis](../building-modules/genesis.md) + +**Naming and conventions** + +We encourage developers to follow industry guidelines: [Protocol Buffers style guide](https://developers.google.com/protocol-buffers/docs/style) +and [Buf](https://buf.build/docs/style-guide), see more details in [ADR 023](../architecture/adr-023-protobuf-naming.md) + +2. How to update modules to protobuf encoding? + +If modules do not contain any interfaces (e.g. `Account` or `Content`), then they +may simply migrate any existing types that +are encoded and persisted via their concrete Amino codec to Protobuf (see 1. for further guidelines) and accept a `Marshaler` as the codec which is implemented via the `ProtoCodec` +without any further customization. + +However, if a module type composes an interface, it must wrap it in the `skd.Any` (from `/types` package) type. To do that, a module-level .proto file must use [`google.protobuf.Any`](https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/any.proto) for respective message type interface types. + +For example, in the `x/evidence` module defines an `Evidence` interface, which is used by the `MsgSubmitEvidence`. The structure definition must use `sdk.Any` to wrap the evidence file. In the proto file we define it as follows: + +```protobuf +// proto/cosmos/evidence/v1beta1/tx.proto + +message MsgSubmitEvidence { + string submitter = 1; + google.protobuf.Any evidence = 2 [(cosmos_proto.accepts_interface) = "Evidence"]; +} +``` + +The SDK `codec.Codec` interface provides support methods `MarshalInterface` and `UnmarshalInterface` to easy encoding of state to `Any`. + +Module should register interfaces using `InterfaceRegistry` which provides a mechanism for registering interfaces: `RegisterInterface(protoName string, iface interface{})` and implementations: `RegisterImplementations(iface interface{}, impls ...proto.Message)` that can be safely unpacked from Any, similarly to type registration with Amino: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc4/codec/types/interface_registry.go#L25-L66 + +In addition, an `UnpackInterfaces` phase should be introduced to deserialization to unpack interfaces before they're needed. Protobuf types that contain a protobuf `Any` either directly or via one of their members should implement the `UnpackInterfacesMessage` interface: + +```go +type UnpackInterfacesMessage interface { + UnpackInterfaces(InterfaceUnpacker) error +} +``` + +## Next {hide} + +Learn about [gRPC, REST and other endpoints](./grpc_rest.md) {hide} diff --git a/versioned_docs/version-0.45/develop/advanced-concepts/events.md b/versioned_docs/version-0.45/develop/advanced-concepts/events.md new file mode 100644 index 000000000..d62663abd --- /dev/null +++ b/versioned_docs/version-0.45/develop/advanced-concepts/events.md @@ -0,0 +1,137 @@ + + +# Events + +`Event`s are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallet to track the execution of various messages and index transactions. {synopsis} + +## Pre-requisite Readings + +- [Anatomy of an SDK application](../basics/app-anatomy.md) {prereq} +- [Tendermint Documentation on Events](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}`. + ++++ 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 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}`. + +::: 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`. + +Events are returned to the underlying consensus engine in the response of the following ABCI messages: + +- [`BeginBlock`](./baseapp.md#beginblock) +- [`EndBlock`](./baseapp.md#endblock) +- [`CheckTx`](./baseapp.md#checktx) +- [`DeliverTx`](./baseapp.md#delivertx) + +### Examples + +The following examples show how to query Events using the SDK. + +| Event | Description | +| ------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `tx.height=23` | Query all transactions at height 23 | +| `message.action='/cosmos.bank.v1beta1.Msg/Send'` | Query all transactions containing a x/bank `Send` [Service `Msg`](../building-modules/msg-services.md). Note the `'`s around the value. | +| `message.action='send'` | Query all transactions containing a x/bank `Send` [legacy `Msg`](../building-modules/msg-services.md#legacy-amino-msgs). Note the `'`s around the value. | +| `message.module='bank'` | Query all transactions containing messages from the x/bank module. Note the `'`s around the value. | +| `create_validator.validator='cosmosval1...'` | x/staking-specific Event, see [x/staking SPEC](../../../cosmos-sdk/x/staking/spec/07_events.md). | + +## EventManager + +In Cosmos SDK applications, Events are managed by an abstraction called the `EventManager`. +Internally, the `EventManager` tracks a list of Events for the entire execution flow of a +transaction or `BeginBlock`/`EndBlock`. + ++++ https://github.com/cosmos/cosmos-sdk/blob/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`. + ++++ 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: + +```go +ctx.EventManager().EmitEvent( + sdk.NewEvent(eventType, sdk.NewAttribute(attributeKey, attributeValue)), +) +``` + +Module's `handler` function should also set a new `EventManager` to the `context` to isolate emitted Events per `message`: + +```go +func NewHandler(keeper Keeper) sdk.Handler { + return func(ctx sdk.Context, msg sdk.Msg) (*sdk.Result, error) { + ctx = ctx.WithEventManager(sdk.NewEventManager()) + switch msg := msg.(type) { +``` + +See the [`Msg` services](../building-modules/msg-services.md) concept doc for a more detailed +view on how to typically implement Events and use the `EventManager` in modules. + +## Subscribing to Events + +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: + +```json +{ + "jsonrpc": "2.0", + "method": "subscribe", + "id": "0", + "params": { + "query": "tm.event='eventCategory' AND eventType.eventAttribute='attributeValue'" + } +} +``` + +The main `eventCategory` you can subscribe to are: + +- `NewBlock`: Contains Events triggered during `BeginBlock` and `EndBlock`. +- `Tx`: Contains Events triggered during `DeliverTx` (i.e. transaction processing). +- `ValidatorSetUpdates`: Contains validator set updates for the block. + +These Events are triggered from the `state` package after a block is committed. You can get the +full list of Event categories [on the Tendermint Godoc page](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: + +```json +{ + "jsonrpc": "2.0", + "method": "subscribe", + "id": "0", + "params": { + "query": "tm.event='Tx' AND transfer.sender='senderAddress'" + } +} +``` + +where `senderAddress` is an address following the [`AccAddress`](../basics/accounts.md#addresses) format. + +## 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 SDK proposes to use Protobuf-defined [Typed Events](../architecture/adr-032-typed-events.md) for emitting and querying Events. + +The Typed Events proposal has not yet been fully implemented. Documentation is not yet available. + +## Next {hide} + +Learn about SDK [telemetry](./telemetry.md) {hide} diff --git a/versioned_docs/version-0.45/develop/advanced-concepts/grpc_rest.md b/versioned_docs/version-0.45/develop/advanced-concepts/grpc_rest.md new file mode 100644 index 000000000..c4f1feb17 --- /dev/null +++ b/versioned_docs/version-0.45/develop/advanced-concepts/grpc_rest.md @@ -0,0 +1,116 @@ + + +# gRPC, REST, and Tendermint Endpoints + +This document presents an overview of all the endpoints a node exposes: gRPC, REST as well as some other endpoints. {synopsis} + +## An Overview of All Endpoints + +Each node exposes the following endpoints for users to interact with a node, each endpoint is served on a different port. Details on how to configure each endpoint is provided in the endpoint's own section. + +- the gRPC server (default port: `9090`), +- the REST server (default port: `1317`), +- the Tendermint RPC endpoint (default port: `26657`). + +::: tip +The node also exposes some other endpoints, such as the Tendermint P2P endpoint, or the [Prometheus endpoint](https://docs.tendermint.com/master/nodes/metrics.html#metrics), which are not directly related to the Cosmos SDK. Please refer to the [Tendermint documentation](https://docs.tendermint.com/master/tendermint-core/using-tendermint.html#configuration) for more information about these endpoints. +::: + +## gRPC Server + +::: warning +A patch introduced in `go-grpc v1.34.0` made gRPC incompatible with the `gogoproto` library, making some [gRPC queries](https://github.com/cosmos/cosmos-sdk/issues/8426) panic. As such, the SDK requires that `go-grpc <=v1.33.2` is installed in your `go.mod`. + +To make sure that gRPC is working properly, it is **highly recommended** to add the following line in your application's `go.mod`: + +``` +replace google.golang.org/grpc => google.golang.org/grpc v1.33.2 +``` + +Please see [issue #8392](https://github.com/cosmos/cosmos-sdk/issues/8392) for more info. +::: + +Cosmos SDK v0.40 introduced Protobuf as the main [encoding](./encoding) library, and this brings a wide range of Protobuf-based tools that can be plugged into the SDK. One such tool is [gRPC](https://grpc.io), a modern open source high performance RPC framework that has decent client support in several languages. + +Each module exposes 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: + ++++ 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. + +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.enable = true|false` field defines if the gRPC server should be enabled. Defaults to `true`. +- `grpc.address = {string}` field defines the address (really, the port, since the host should be kept at `0.0.0.0`) the server should bind to. Defaults to `0.0.0.0:9090`. + +:::tip +`~/.simapp` is the directory where the node's configuration and databases are stored. By default, it's set to `~/.{app_name}`. +::: + +Once the gRPC server is started, you can send requests to it using a gRPC client. Some examples are given in our [Interact with the Node](../run-node/interact-node.md#using-grpc) tutorial. + +An overview of all available gRPC endpoints shipped with the Cosmos SDK is [Protobuf documention](./proto-docs.md). + +## REST Server + +In Cosmos SDK v0.40, the node continues to serve a REST server. However, the existing routes present in version v0.39 and earlier are now marked as deprecated, and new routes have been added via gRPC-gateway. + +All routes are configured under the following fields in `~/.simapp/config/app.toml`: + +- `api.enable = true|false` field defines if the REST server should be enabled. Defaults to `false`. +- `api.address = {string}` field defines the address (really, the port, since the host should be kept at `0.0.0.0`) the server should bind to. Defaults to `tcp://0.0.0.0:1317`. +- some additional API configuration options are defined in `~/.simapp/config/app.toml`, along with comments, please refer to that file directly. + +### gRPC-gateway REST Routes + +If, for various reasons, you cannot use gRPC (for example, you are building a web application, and browsers don't support HTTP2 on which gRPC is built), then the SDK offers REST routes via gRPC-gateway. + +[gRPC-gateway](https://grpc-ecosystem.github.io/grpc-gateway/) is a tool to expose gRPC endpoints as REST endpoints. For each gRPC endpoint defined in a Protobuf `Query` service, the 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: + ++++ 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. + +### Legacy REST API Routes + +The REST routes present in Cosmos SDK v0.39 and earlier are marked as deprecated via a [HTTP deprecation header](https://tools.ietf.org/id/draft-dalal-deprecation-header-01.html). They are still maintained to keep backwards compatibility, but will be removed in v0.44. For updating from Legacy REST routes to new gRPC-gateway REST routes, please refer to our [migration guide](../migrations/rest.md). + +For application developers, Legacy REST API routes needs to be wired up to the REST server, this is done by calling the `RegisterRESTRoutes` function on the ModuleManager. + +### Swagger + +A [Swagger](https://swagger.io/) (or OpenAPIv2) specification file is exposed under the `/swagger` route on the API server. Swagger is an open specification describing the API endpoints a server serves, including description, input arguments, return types and much more about each endpoint. + +Enabling the `/swagger` endpoint is configurable inside `~/.simapp/config/app.toml` via the `api.swagger` field, which is set to true by default. + +For application developers, you may want to generate your own Swagger definitions based on your custom modules. The SDK's [Swagger generation script](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc4/scripts/protoc-swagger-gen.sh) is a good place to start. + +## Tendermint RPC + +Independently from the Cosmos SDK, Tendermint also exposes a RPC server. This RPC server can be configured by tuning parameters under the `rpc` table in the `~/.simapp/config/config.toml`, the default listening address is `tcp://0.0.0.0:26657`. An OpenAPI specification of all Tendermint RPC endpoints is available [here](https://docs.tendermint.com/master/rpc/). + +Some Tendermint RPC endpoints are directly related to the Cosmos SDK: + +- `/abci_query`: this endpoint will query the application for state. As the `path` parameter, you can send the following strings: + - any Protobuf fully-qualified service method, such as `/cosmos.bank.v1beta1.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. + +## Comparison Table + +| Name | Advantages | Disadvantages | +| -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | +| gRPC | - can use code-generated stubs in various languages
- supports streaming and bidirectional communication (HTTP2)
- small wire binary sizes, faster transmission | - based on HTTP2, not available in browsers
- learning curve (mostly due to Protobuf) | +| REST | - ubiquitous
- client libraries in all languages, faster implementation
| - only supports unary request-response communication (HTTP1.1)
- bigger over-the-wire message sizes (JSON) | +| CometBFT RPC | - easy to use | - bigger over-the-wire message sizes (JSON) | + + +## Next {hide} + +Learn about [the CLI](./cli.md) {hide} diff --git a/versioned_docs/version-0.45/develop/advanced-concepts/keeper_dependencies.svg b/versioned_docs/version-0.45/develop/advanced-concepts/keeper_dependencies.svg new file mode 100644 index 000000000..bac9328e3 --- /dev/null +++ b/versioned_docs/version-0.45/develop/advanced-concepts/keeper_dependencies.svg @@ -0,0 +1,102 @@ +The dependencies between Keepers (Feb 2021)StakingDistributionSlashingEvidenceBankAuth/AccountGovMint \ No newline at end of file diff --git a/versioned_docs/version-0.45/develop/advanced-concepts/node.md b/versioned_docs/version-0.45/develop/advanced-concepts/node.md new file mode 100644 index 000000000..132b6a8a8 --- /dev/null +++ b/versioned_docs/version-0.45/develop/advanced-concepts/node.md @@ -0,0 +1,76 @@ + + +# Node Client (Daemon) + +The main endpoint of an SDK application is the daemon client, otherwise known as the full-node client. The full-node runs the state-machine, starting from a genesis file. It connects to peers running the same client in order to receive and relay transactions, block proposals and signatures. The full-node is constituted of the application, defined with the Cosmos SDK, and of a consensus engine connected to the application via the ABCI. {synopsis} + +## Pre-requisite Readings + +- [Anatomy of an SDK application](../basics/app-anatomy.md) {prereq} + +## `main` function + +The full-node client of any SDK application is built by running a `main` function. The client is generally named by appending the `-d` suffix to the application name (e.g. `appd` for an application named `app`), and the `main` function is defined in a `./appd/cmd/main.go` file. Running this function creates an executable `appd` that comes with a set of commands. For an app named `app`, the main command is [`appd start`](#start-command), which starts the full-node. + +In general, developers will implement the `main.go` function with the following structure: + +- First, an [`appCodec`](./encoding.md) is 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). + +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/types/config.go#L13-L24 +- Using [cobra](https://github.com/spf13/cobra), the root command of the full-node client is created. After that, all the custom commands of the application are added using the `AddCommand()` method of `rootCmd`. +- Add default server commands to `rootCmd` using the `server.AddCommands()` method. These commands are separated from the ones added above since they are standard and defined at SDK level. They should be shared by all SDK-based applications. They include the most important command: the [`start` command](#start-command). +- Prepare and execute the `executor`. + +++ https://github.com/tendermint/tendermint/blob/v0.34.0-rc6/libs/cli/setup.go#L74-L78 + +See an example of `main` function from the `simapp` application, the SDK's application for demo purposes: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/simapp/simd/main.go + +## `start` command + +The `start` command is defined in the `/server` folder of the Cosmos SDK. It is added to the root command of the full-node client in the [`main` function](#main-function) and called by the end-user to start their node: + +```bash +# For an example app named "app", the following command starts the full-node. +appd start + +# Using the SDK's own simapp, the following commands start the simapp node. +simd start +``` + +As a reminder, the full-node is composed of three conceptual layers: the networking layer, the consensus layer and the application layer. The first two are generally bundled together in an entity called the consensus engine (Tendermint Core by default), while the third is the state-machine defined with the help of the Cosmos SDK. Currently, the Cosmos SDK uses Tendermint as the default consensus engine, meaning the start command is implemented to boot up a Tendermint node. + +The flow of the `start` command is pretty straightforward. First, it retrieves the `config` from the `context` in order to open the `db` (a [`leveldb`](https://github.com/syndtr/goleveldb) instance by default). This `db` contains the latest known state of the application (empty if the application is started from the first time. + +With the `db`, the `start` command creates a new instance of the application using an `appCreator` function: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/server/start.go#L227-L228 + +Note that an `appCreator` is a function that fulfills the `AppCreator` signature: ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/server/types/app.go#L48-L50 + +In practice, the [constructor of the application](../basics/app-anatomy.md#constructor-function) is passed as the `appCreator`. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/simapp/simd/cmd/root.go#L170-L215 + +Then, the instance of `app` is used to instanciate a new Tendermint node: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/server/start.go#L235-L244 + +The Tendermint node can be created with `app` because the latter satisfies the [`abci.Application` interface](https://github.com/tendermint/tendermint/blob/v0.34.0/abci/types/application.go#L7-L32) (given that `app` extends [`baseapp`](./baseapp.md)). As part of the `NewNode` method, Tendermint makes sure that the height of the application (i.e. number of blocks since genesis) is equal to the height of the Tendermint node. The difference between these two heights should always be negative or null. If it is strictly negative, `NewNode` will replay blocks until the height of the application reaches the height of the Tendermint node. Finally, if the height of the application is `0`, the Tendermint node will call [`InitChain`](./baseapp.md#initchain) on the application to initialize the state from the genesis file. + +Once the Tendermint node is instanciated and in sync with the application, the node can be started: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/server/start.go#L250-L252 + +Upon starting, the node will bootstrap its RPC and P2P server and start dialing peers. During handshake with its peers, if the node realizes they are ahead, it will query all the blocks sequentially in order to catch up. Then, it will wait for new block proposals and block signatures from validators in order to make progress. + +## Other commands + +To discover how to concretely run a node and interact with it, please refer to our [Running a Node, API and CLI](../run-node/README.md) guide. + +## Next {hide} + +Learn about the [store](./store.md) {hide} diff --git a/versioned_docs/version-0.45/develop/advanced-concepts/ocap.md b/versioned_docs/version-0.45/develop/advanced-concepts/ocap.md new file mode 100644 index 000000000..833efa646 --- /dev/null +++ b/versioned_docs/version-0.45/develop/advanced-concepts/ocap.md @@ -0,0 +1,79 @@ + + +# Object-Capability Model + +## Intro + +When thinking about security, it is good to start with a specific threat model. Our threat model is the following: + +> We assume that a thriving ecosystem of Cosmos-SDK modules that are easy to compose into a blockchain application will contain faulty or malicious modules. + +The Cosmos SDK is designed to address this threat by being the +foundation of an object capability system. + +> The structural properties of object capability systems favor +> modularity in code design and ensure reliable encapsulation in +> code implementation. +> +> These structural properties facilitate the analysis of some +> security properties of an object-capability program or operating +> system. Some of these — in particular, information flow properties +> — can be analyzed at the level of object references and +> connectivity, independent of any knowledge or analysis of the code +> that determines the behavior of the objects. +> +> As a consequence, these security properties can be established +> and maintained in the presence of new objects that contain unknown +> and possibly malicious code. +> +> These structural properties stem from the two rules governing +> access to existing objects: +> +> 1. An object A can send a message to B only if object A holds a +> reference to B. +> 2. An object A can obtain a reference to C only +> if object A receives a message containing a reference to C. As a +> consequence of these two rules, an object can obtain a reference +> to another object only through a preexisting chain of references. +> In short, "Only connectivity begets connectivity." + +For an introduction to object-capabilities, see this [Wikipedia article](https://en.wikipedia.org/wiki/Object-capability_model). + +## Ocaps in practice + +The idea is to only reveal what is necessary to get the work done. + +For example, the following code snippet violates the object capabilities +principle: + +```go +type AppAccount struct {...} +account := &AppAccount{ + Address: pub.Address(), + Coins: sdk.Coins{sdk.NewInt64Coin("ATM", 100)}, +} +sumValue := externalModule.ComputeSumValue(account) +``` + +The method `ComputeSumValue` implies a pure function, yet the implied +capability of accepting a pointer value is the capability to modify that +value. The preferred method signature should take a copy instead. + +```go +sumValue := externalModule.ComputeSumValue(*account) +``` + +In the Cosmos SDK, you can see the application of this principle in the +gaia app. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.41.4/simapp/app.go#L249-L273 + +The following diagram shows the current dependencies between keepers. + +![Keeper dependencies](./keeper_dependencies.svg) + +## Next {hide} + +Learn about the [`runTx` middleware](./runtx_middleware.md) {hide} diff --git a/versioned_docs/version-0.45/develop/advanced-concepts/runtx_middleware.md b/versioned_docs/version-0.45/develop/advanced-concepts/runtx_middleware.md new file mode 100644 index 000000000..9c978fbbe --- /dev/null +++ b/versioned_docs/version-0.45/develop/advanced-concepts/runtx_middleware.md @@ -0,0 +1,73 @@ + + +# RunTx recovery middleware + +`BaseApp.runTx()` function handles Golang panics that might occur during transactions execution, for example, keeper has faced an invalid state and paniced. +Depending on the panic type different handler is used, for instance the default one prints an error log message. +Recovery middleware is used to add custom panic recovery for SDK application developers. + +More context could be found in the corresponding [ADR-022](../architecture/adr-022-custom-panic-handling.md). + +Implementation could be found in the [recovery.go](../../baseapp/recovery.go) file. + +## Interface + +```go +type RecoveryHandler func(recoveryObj interface{}) error +``` + +`recoveryObj` is a return value for `recover()` function from the `buildin` Golang package. + +**Contract:** + +- RecoveryHandler returns `nil` if `recoveryObj` wasn't handled and should be passed to the next recovery middleware; +- RecoveryHandler returns a non-nil `error` if `recoveryObj` was handled; + +## Custom RecoveryHandler register + +`BaseApp.AddRunTxRecoveryHandler(handlers ...RecoveryHandler)` + +BaseApp method adds recovery middleware to the default recovery chain. + +## Example + +Lets assume we want to emit the "Consensus failure" chain state if some particular error occurred. + +We have a module keeper that panics: + +```go +func (k FooKeeper) Do(obj interface{}) { + if obj == nil { + // that shouldn't happen, we need to crash the app + err := sdkErrors.Wrap(fooTypes.InternalError, "obj is nil") + panic(err) + } +} +``` + +By default that panic would be recovered and an error message will be printed to log. To override that behaviour we should register a custom RecoveryHandler: + +```go +// SDK application constructor +customHandler := func(recoveryObj interface{}) error { + err, ok := recoveryObj.(error) + if !ok { + return nil + } + + if fooTypes.InternalError.Is(err) { + panic(fmt.Errorf("FooKeeper did panic with error: %w", err)) + } + + return nil +} + +baseApp := baseapp.NewBaseApp(...) +baseApp.AddRunTxRecoveryHandler(customHandler) +``` + +## Next {hide} + +Learn about the [IBC](./../ibc/README.md) protocol {hide} diff --git a/versioned_docs/version-0.45/develop/advanced-concepts/simulation.md b/versioned_docs/version-0.45/develop/advanced-concepts/simulation.md new file mode 100644 index 000000000..9b838b40b --- /dev/null +++ b/versioned_docs/version-0.45/develop/advanced-concepts/simulation.md @@ -0,0 +1,101 @@ + + +# Cosmos Blockchain Simulator + +The Cosmos SDK offers a full fledged simulation framework to fuzz test every +message defined by a module. + +On the SDK, this functionality is provided by the[`SimApp`](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/simapp/app.go), which is a +`Baseapp` application that is used for running the [`simulation`](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/x/simulation) module. +This module defines all the simulation logic as well as the operations for +randomized parameters like accounts, balances etc. + +## Goals + +The blockchain simulator tests how the blockchain application would behave under +real life circumstances by generating and sending randomized messages. +The goal of this is to detect and debug failures that could halt a live chain, +by providing logs and statistics about the operations run by the simulator as +well as exporting the latest application state when a failure was found. + +Its main difference with integration testing is that the simulator app allows +you to pass parameters to customize the chain that's being simulated. +This comes in handy when trying to reproduce bugs that were generated in the +provided operations (randomized or not). + +## Simulation commands + +The simulation app has different commands, each of which tests a different +failure type: + +- `AppImportExport`: The simulator exports the initial app state and then it + creates a new app with the exported `genesis.json` as an input, checking for + inconsistencies between the stores. +- `AppSimulationAfterImport`: Queues two simulations together. The first one provides the app state (_i.e_ genesis) to the second. Useful to test software upgrades or hard-forks from a live chain. +- `AppStateDeterminism`: Checks that all the nodes return the same values, in the same order. +- `BenchmarkInvariants`: Analysis of the performance of running all modules' invariants (_i.e_ sequentially runs a [benchmark](https://golang.org/pkg/testing/#hdr-Benchmarks) test). An invariant checks for + differences between the values that are on the store and the passive tracker. Eg: total coins held by accounts vs total supply tracker. +- `FullAppSimulation`: General simulation mode. Runs the chain and the specified operations for a given number of blocks. Tests that there're no `panics` on the simulation. It does also run invariant checks on every `Period` but they are not benchmarked. + +Each simulation must receive a set of inputs (_i.e_ flags) such as the number of +blocks that the simulation is run, seed, block size, etc. +Check the full list of flags [here](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/simapp/config.go#L32-L55). + +## Simulator Modes + +In addition to the various inputs and commands, the simulator runs in three modes: + +1. Completely random where the initial state, module parameters and simulation + parameters are **pseudo-randomly generated**. +2. From a `genesis.json` file where the initial state and the module parameters are defined. + This mode is helpful for running simulations on a known state such as a live network export where a new (mostly likely breaking) version of the application needs to be tested. +3. From a `params.json` file where the initial state is pseudo-randomly generated but the module and simulation parameters can be provided manually. + This allows for a more controlled and deterministic simulation setup while allowing the state space to still be pseudo-randomly simulated. + The list of available parameters are listed [here](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/x/simulation/params.go#L44-L52). + +::: tip +These modes are not mutually exclusive. So you can for example run a randomly +generated genesis state (`1`) with manually generated simulation params (`3`). +::: + +## Usage + +This is a general example of how simulations are run. For more specific examples +check the SDK [Makefile](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/Makefile#L251-L287). + +```bash + $ go test -mod=readonly github.com/cosmos/cosmos-sdk/simapp \ + -run=TestApp \ + ... + -v -timeout 24h +``` + +## Debugging Tips + +Here are some suggestions when encountering a simulation failure: + +- Export the app state at the height were the failure was found. You can do this + by passing the `-ExportStatePath` flag to the simulator. +- Use `-Verbose` logs. They could give you a better hint on all the operations + involved. +- Reduce the simulation `-Period`. This will run the invariants checks more + frequently. +- Print all the failed invariants at once with `-PrintAllInvariants`. +- Try using another `-Seed`. If it can reproduce the same error and if it fails + sooner you will spend less time running the simulations. +- Reduce the `-NumBlocks` . How's the app state at the height previous to the + failure? +- Run invariants on every operation with `-SimulateEveryOperation`. _Note_: this + will slow down your simulation **a lot**. +- Try adding logs to operations that are not logged. You will have to define a + [Logger](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/x/staking/keeper/keeper.go#L66-L69) on your `Keeper`. + +## Use simulation in your SDK-based application + +Learn how you can integrate the simulation into your SDK-based application: + +- Application Simulation Manager +- [Building modules: Simulator](../building-modules/simulator.md) +- Simulator tests diff --git a/versioned_docs/version-0.45/develop/advanced-concepts/store.md b/versioned_docs/version-0.45/develop/advanced-concepts/store.md new file mode 100644 index 000000000..1dbe05536 --- /dev/null +++ b/versioned_docs/version-0.45/develop/advanced-concepts/store.md @@ -0,0 +1,257 @@ + + +# Store + +A store is a data structure that holds the state of the application. {synopsis} + +### Pre-requisite Readings + +- [Anatomy of an SDK application](../basics/app-anatomy.md) {prereq} + +## Introduction to SDK Stores + +The Cosmos SDK comes with a large set of stores to persist the state of applications. By default, the main store of SDK applications is a `multistore`, i.e. a store of stores. Developers can add any number of key-value stores to the multistore, depending on their application needs. The multistore exists to support the modularity of the Cosmos SDK, as it lets each module declare and manage their own subset of the state. Key-value stores in the multistore can only be accessed with a specific capability `key`, which is typically held in the [`keeper`](../building-modules/keeper.md) of the module that declared the store. + +``` ++-----------------------------------------------------+ +| | +| +--------------------------------------------+ | +| | | | +| | KVStore 1 - Manage by keeper of Module 1 | +| | | | +| +--------------------------------------------+ | +| | +| +--------------------------------------------+ | +| | | | +| | KVStore 2 - Manage by keeper of Module 2 | | +| | | | +| +--------------------------------------------+ | +| | +| +--------------------------------------------+ | +| | | | +| | KVStore 3 - Manage by keeper of Module 2 | | +| | | | +| +--------------------------------------------+ | +| | +| +--------------------------------------------+ | +| | | | +| | KVStore 4 - Manage by keeper of Module 3 | | +| | | | +| +--------------------------------------------+ | +| | +| +--------------------------------------------+ | +| | | | +| | KVStore 5 - Manage by keeper of Module 4 | | +| | | | +| +--------------------------------------------+ | +| | +| Main Multistore | +| | ++-----------------------------------------------------+ + + Application's State +``` + +### Store Interface + +At its very core, a Cosmos SDK `store` is an object that holds a `CacheWrapper` and has a `GetStoreType()` method: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/store/types/store.go#L15-L18 + +The `GetStoreType` is a simple method that returns the type of store, whereas a `CacheWrapper` is a simple interface that implements store read caching and write branching through `Write` method: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/store/types/store.go#L240-L264 + +Branching and cache is used ubiquitously in the Cosmos SDK and required to be implemented on every store type. A storage branch creates an isolated, ephemeral branch of a store that can be passed around and updated without affecting the main underlying store. This is used to trigger temporary state-transitions that may be reverted later should an error occur. Read more about it in [context](./context.md#Store-branching) + +### Commit Store + +A commit store is a store that has the ability to commit changes made to the underlying tree or db. The Cosmos SDK differentiates simple stores from commit stores by extending the basic store interfaces with a `Committer`: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/store/types/store.go#L29-L33 + +The `Committer` is an interface that defines methods to persist changes to disk: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/store/types/store.go#L20-L27 + +The `CommitID` is a deterministic commit of the state tree. Its hash is returned to the underlying consensus engine and stored in the block header. Note that commit store interfaces exist for various purposes, one of which is to make sure not every object can commit the store. As part of the [object-capabilities model](./ocap.md) of the Cosmos SDK, only `baseapp` should have the ability to commit stores. For example, this is the reason why the `ctx.KVStore()` method by which modules typically access stores returns a `KVStore` and not a `CommitKVStore`. + +The Cosmos SDK comes with many types of stores, the most used being [`CommitMultiStore`](#multistore), [`KVStore`](#kvstore) and [`GasKv` store](#gaskv-store). [Other types of stores](#other-stores) include `Transient` and `TraceKV` stores. + +## Multistore + +### Multistore Interface + +Each Cosmos SDK application holds a multistore at its root to persist its state. The multistore is a store of `KVStores` that follows the `Multistore` interface: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/store/types/store.go#L104-L133 + +If tracing is enabled, then branching the multistore will firstly wrap all the underlying `KVStore` in [`TraceKv.Store`](#tracekv-store). + +### CommitMultiStore + +The main type of `Multistore` used in the Cosmos SDK is `CommitMultiStore`, which is an extension of the `Multistore` interface: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/store/types/store.go#L141-L184 + +As for concrete implementation, the [`rootMulti.Store`] is the go-to implementation of the `CommitMultiStore` interface. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/store/rootmulti/store.go#L43-L61 + +The `rootMulti.Store` is a base-layer multistore built around a `db` on top of which multiple `KVStores` can be mounted, and is the default multistore store used in [`baseapp`](./baseapp.md). + +### CacheMultiStore + +Whenever the `rootMulti.Store` needs to be branched, a [`cachemulti.Store`](https://github.com/cosmos/cosmos-sdk/blob/v0.42.1/store/cachemulti/store.go) is used. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/store/cachemulti/store.go#L17-L28 + +`cachemulti.Store` branches all substores (creates a virtual store for each substore) in its constructor and hold them in `Store.stores`. Moreover caches all read queries. `Store.GetKVStore()` returns the store from `Store.stores`, and `Store.Write()` recursively calls `CacheWrap.Write()` on all the substores. + +## Base-layer KVStores + +### `KVStore` and `CommitKVStore` Interfaces + +A `KVStore` is a simple key-value store used to store and retrieve data. A `CommitKVStore` is a `KVStore` that also implements a `Committer`. By default, stores mounted in `baseapp`'s main `CommitMultiStore` are `CommitKVStore`s. The `KVStore` interface is primarily used to restrict modules from accessing the committer. + +Individual `KVStore`s are used by modules to manage a subset of the global state. `KVStores` can be accessed by objects that hold a specific key. This `key` should only be exposed to the [`keeper`](../building-modules/keeper.md) of the module that defines the store. + +`CommitKVStore`s are declared by proxy of their respective `key` and mounted on the application's [multistore](#multistore) in the [main application file](../basics/app-anatomy.md#core-application-file). In the same file, the `key` is also passed to the module's `keeper` that is responsible for managing the store. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/store/types/store.go#L189-L219 + +Apart from the traditional `Get` and `Set` methods, a `KVStore` must provide an `Iterator(start, end)` method which returns an `Iterator` object. It is used to iterate over a range of keys, typically keys that share a common prefix. Below is an example from the bank's module keeper, used to iterate over all account balances: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/x/bank/keeper/view.go#L115-L134 + +### `IAVL` Store + +The default implementation of `KVStore` and `CommitKVStore` used in `baseapp` is the `iavl.Store`. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/store/iavl/store.go#L37-L40 + +`iavl` stores are based around an [IAVL Tree](https://github.com/tendermint/iavl), a self-balancing binary tree which guarantees that: + +- `Get` and `Set` operations are O(log n), where n is the number of elements in the tree. +- Iteration efficiently returns the sorted elements within the range. +- Each tree version is immutable and can be retrieved even after a commit (depending on the pruning settings). + +The documentation on the IAVL Tree is located [here](https://github.com/cosmos/iavl/blob/v0.15.0-rc5/docs/overview.md). + +### `DbAdapter` Store + +`dbadapter.Store` is a adapter for `dbm.DB` making it fulfilling the `KVStore` interface. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/store/dbadapter/store.go#L13-L16 + +`dbadapter.Store` embeds `dbm.DB`, meaning most of the `KVStore` interface functions are implemented. The other functions (mostly miscellaneous) are manually implemented. This store is primarily used within [Transient Stores](#transient-stores) + +### `Transient` Store + +`Transient.Store` is a base-layer `KVStore` which is automatically discarded at the end of the block. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/store/transient/store.go#L13-L16 + +`Transient.Store` is a `dbadapter.Store` with a `dbm.NewMemDB()`. All `KVStore` methods are reused. When `Store.Commit()` is called, a new `dbadapter.Store` is assigned, discarding previous reference and making it garbage collected. + +This type of store is useful to persist information that is only relevant per-block. One example would be to store parameter changes (i.e. a bool set to `true` if a parameter changed in a block). + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/x/params/types/subspace.go#L20-L30 + +Transient stores are typically accessed via the [`context`](./context.md) via the `TransientStore()` method: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/types/context.go#L232-L235 + +## KVStore Wrappers + +### CacheKVStore + +`cachekv.Store` is a wrapper `KVStore` which provides buffered writing / cached reading functionalities over the underlying `KVStore`. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/store/cachekv/store.go#L27-L34 + +This is the type used whenever an IAVL Store needs to be branched to create an isolated store (typically when we need to mutate a state that might be reverted later). + +#### `Get` + +`Store.Get()` firstly checks if `Store.cache` has an associated value with the key. If the value exists, the function returns it. If not, the function calls `Store.parent.Get()`, caches the result in `Store.cache`, and returns it. + +#### `Set` + +`Store.Set()` sets the key-value pair to the `Store.cache`. `cValue` has the field dirty bool which indicates whether the cached value is different from the underlying value. When `Store.Set()` caches a new pair, the `cValue.dirty` is set `true` so when `Store.Write()` is called it can be written to the underlying store. + +#### `Iterator` + +`Store.Iterator()` have to traverse on both cached items and the original items. In `Store.iterator()`, two iterators are generated for each of them, and merged. `memIterator` is essentially a slice of the `KVPairs`, used for cached items. `mergeIterator` is a combination of two iterators, where traverse happens ordered on both iterators. + +### `GasKv` Store + +Cosmos SDK applications use [`gas`](../basics/gas-fees.md) to track resources usage and prevent spam. [`GasKv.Store`](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/store/gaskv/store.go) is a `KVStore` wrapper that enables automatic gas consumption each time a read or write to the store is made. It is the solution of choice to track storage usage in Cosmos SDK applications. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/store/gaskv/store.go#L13-L19 + +When methods of the parent `KVStore` are called, `GasKv.Store` automatically consumes appropriate amount of gas depending on the `Store.gasConfig`: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/store/types/gas.go#L153-L162 + +By default, all `KVStores` are wrapped in `GasKv.Stores` when retrieved. This is done in the `KVStore()` method of the [`context`](./context.md): + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/types/context.go#L227-L230 + +In this case, the default gas configuration is used: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/store/types/gas.go#L164-L175 + +### `TraceKv` Store + +`tracekv.Store` is a wrapper `KVStore` which provides operation tracing functionalities over the underlying `KVStore`. It is applied automatically by the Cosmos SDK on all `KVStore` if tracing is enabled on the parent `MultiStore`. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/store/tracekv/store.go#L20-L43 + +When each `KVStore` methods are called, `tracekv.Store` automatically logs `traceOperation` to the `Store.writer`. `traceOperation.Metadata` is filled with `Store.context` when it is not nil. `TraceContext` is a `map[string]interface{}`. + +### `Prefix` Store + +`prefix.Store` is a wrapper `KVStore` which provides automatic key-prefixing functionalities over the underlying `KVStore`. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/store/prefix/store.go#L15-L21 + +When `Store.{Get, Set}()` is called, the store forwards the call to its parent, with the key prefixed with the `Store.prefix`. + +When `Store.Iterator()` is called, it does not simply prefix the `Store.prefix`, since it does not work as intended. In that case, some of the elements are traversed even they are not starting with the prefix. + +### `ListenKv` Store + +`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). + ++++ 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`. + +## New Store package (`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. + +### `BasicKVStore` interface + +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`. + +### 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`). + +This can optionally be constructed to use different backend databases for each bucket. + + + +### SMT Store + +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`). + +## Next {hide} + +Learn about [encoding](./encoding.md) {hide} diff --git a/versioned_docs/version-0.45/develop/advanced-concepts/telemetry.md b/versioned_docs/version-0.45/develop/advanced-concepts/telemetry.md new file mode 100644 index 000000000..9e434eef2 --- /dev/null +++ b/versioned_docs/version-0.45/develop/advanced-concepts/telemetry.md @@ -0,0 +1,145 @@ + + +# Telemetry + +Gather relevant insights about your application and modules with custom metrics and telemetry. {synopsis} + +The Cosmos SDK enables operators and developers to gain insight into the performance and behavior of +their application through the use of the `telemetry` package. The Cosmos SDK currently supports +enabling in-memory and prometheus as telemetry sinks. This allows the ability to query for and scrape +metrics from a single exposed API endpoint -- `/metrics?format={text|prometheus}`, the default being +`text`. + +If telemetry is enabled via configuration, a single global metrics collector is registered via the +[go-metrics](https://github.com/armon/go-metrics) library. This allows emitting and collecting +metrics through simple API calls. + +Example: + +```go +func EndBlocker(ctx sdk.Context, k keeper.Keeper) { + defer telemetry.ModuleMeasureSince(types.ModuleName, time.Now(), telemetry.MetricKeyEndBlocker) + + // ... +} +``` + +Developers may use the `telemetry` package directly, which provides wrappers around metric APIs +that include adding useful labels, or they must use the `go-metrics` library directly. It is preferable +to add as much context and adequate dimensionality to metrics as possible, so the `telemetry` package +is advised. Regardless of the package or method used, the Cosmos SDK supports the following metrics +types: + +* gauges +* summaries +* counters + +## Labels + +Certain components of modules will have their name automatically added as a label (e.g. `BeginBlock`). +Operators may also supply the application with a global set of labels that will be applied to all +metrics emitted using the `telemetry` package (e.g. chain-id). Global labels are supplied as a list +of [name, value] tuples. + +Example: + +```toml +global-labels = [ + ["chain_id", "chain-OfXo4V"], +] +``` + +## Cardinality + +Cardinality is key, specifically label and key cardinality. Cardinality is how many unique values of +something there are. So there is naturally a tradeoff between granularity and how much stress is put +on the telemetry sink in terms of indexing, scrape, and query performance. + +Developers should take care to support metrics with enough dimensionality and granularity to be +useful, but not increase the cardinality beyond the sink's limits. A general rule of thumb is to not +exceed a cardinality of 10. + +Consider the following examples with enough granularity and adequate cardinality: + +* begin/end blocker time +* tx gas used +* block gas used +* amount of tokens minted +* amount of accounts created + +The following examples expose too much cardinality and may not even prove to be useful: + +* transfers between accounts with amount +* voting/deposit amount from unique addresses + +## Supported Metrics + +| Metric | Description | Unit | Type | +|:--------------------------------|:------------------------------------------------------------------------------------------|:----------------|:--------| +| `tx_count` | Total number of txs processed via `DeliverTx` | tx | counter | +| `tx_successful` | Total number of successful txs processed via `DeliverTx` | tx | counter | +| `tx_failed` | Total number of failed txs processed via `DeliverTx` | tx | counter | +| `tx_gas_used` | The total amount of gas used by a tx | gas | gauge | +| `tx_gas_wanted` | The total amount of gas requested by a tx | gas | gauge | +| `tx_msg_send` | The total amount of tokens sent in a `MsgSend` (per denom) | token | gauge | +| `tx_msg_withdraw_reward` | The total amount of tokens withdrawn in a `MsgWithdrawDelegatorReward` (per denom) | token | gauge | +| `tx_msg_withdraw_commission` | The total amount of tokens withdrawn in a `MsgWithdrawValidatorCommission` (per denom) | token | gauge | +| `tx_msg_delegate` | The total amount of tokens delegated in a `MsgDelegate` | token | gauge | +| `tx_msg_begin_unbonding` | The total amount of tokens undelegated in a `MsgUndelegate` | token | gauge | +| `tx_msg_begin_begin_redelegate` | The total amount of tokens redelegated in a `MsgBeginRedelegate` | token | gauge | +| `tx_msg_ibc_transfer` | The total amount of tokens transferred via IBC in a `MsgTransfer` (source or sink chain) | token | gauge | +| `ibc_transfer_packet_receive` | The total amount of tokens received in a `FungibleTokenPacketData` (source or sink chain) | token | gauge | +| `new_account` | Total number of new accounts created | account | counter | +| `gov_proposal` | Total number of governance proposals | proposal | counter | +| `gov_vote` | Total number of governance votes for a proposal | vote | counter | +| `gov_deposit` | Total number of governance deposits for a proposal | deposit | counter | +| `staking_delegate` | Total number of delegations | delegation | counter | +| `staking_undelegate` | Total number of undelegations | undelegation | counter | +| `staking_redelegate` | Total number of redelegations | redelegation | counter | +| `ibc_transfer_send` | Total number of IBC transfers sent from a chain (source or sink) | transfer | counter | +| `ibc_transfer_receive` | Total number of IBC transfers received to a chain (source or sink) | transfer | counter | +| `ibc_client_create` | Total number of clients created | create | counter | +| `ibc_client_update` | Total number of client updates | update | counter | +| `ibc_client_upgrade` | Total number of client upgrades | upgrade | counter | +| `ibc_client_misbehaviour` | Total number of client misbehaviours | misbehaviour | counter | +| `ibc_connection_open-init` | Total number of connection `OpenInit` handshakes | handshake | counter | +| `ibc_connection_open-try` | Total number of connection `OpenTry` handshakes | handshake | counter | +| `ibc_connection_open-ack` | Total number of connection `OpenAck` handshakes | handshake | counter | +| `ibc_connection_open-confirm` | Total number of connection `OpenConfirm` handshakes | handshake | counter | +| `ibc_channel_open-init` | Total number of channel `OpenInit` handshakes | handshake | counter | +| `ibc_channel_open-try` | Total number of channel `OpenTry` handshakes | handshake | counter | +| `ibc_channel_open-ack` | Total number of channel `OpenAck` handshakes | handshake | counter | +| `ibc_channel_open-confirm` | Total number of channel `OpenConfirm` handshakes | handshake | counter | +| `ibc_channel_close-init` | Total number of channel `CloseInit` handshakes | handshake | counter | +| `ibc_channel_close-confirm` | Total number of channel `CloseConfirm` handshakes | handshake | counter | +| `tx_msg_ibc_recv_packet` | Total number of IBC packets received | packet | counter | +| `tx_msg_ibc_acknowledge_packet` | Total number of IBC packets acknowledged | acknowledgement | counter | +| `ibc_timeout_packet` | Total number of IBC timeout packets | timeout | counter | +| `abci_check_tx` | Duration of ABCI `CheckTx` | ms | summary | +| `abci_deliver_tx` | Duration of ABCI `DeliverTx` | ms | summary | +| `abci_commit` | Duration of ABCI `Commit` | ms | summary | +| `abci_query` | Duration of ABCI `Query` | ms | summary | +| `abci_begin_block` | Duration of ABCI `BeginBlock` | ms | summary | +| `abci_end_block` | Duration of ABCI `EndBlock` | ms | summary | +| `begin_blocker` | Duration of `BeginBlock` for a given module | ms | summary | +| `end_blocker` | Duration of `EndBlock` for a given module | ms | summary | +| `store_iavl_get` | Duration of an IAVL `Store#Get` call | ms | summary | +| `store_iavl_set` | Duration of an IAVL `Store#Set` call | ms | summary | +| `store_iavl_has` | Duration of an IAVL `Store#Has` call | ms | summary | +| `store_iavl_delete` | Duration of an IAVL `Store#Delete` call | ms | summary | +| `store_iavl_commit` | Duration of an IAVL `Store#Commit` call | ms | summary | +| `store_iavl_query` | Duration of an IAVL `Store#Query` call | ms | summary | +| `store_gaskv_get` | Duration of a GasKV `Store#Get` call | ms | summary | +| `store_gaskv_set` | Duration of a GasKV `Store#Set` call | ms | summary | +| `store_gaskv_has` | Duration of a GasKV `Store#Has` call | ms | summary | +| `store_gaskv_delete` | Duration of a GasKV `Store#Delete` call | ms | summary | +| `store_cachekv_get` | Duration of a CacheKV `Store#Get` call | ms | summary | +| `store_cachekv_set` | Duration of a CacheKV `Store#Set` call | ms | summary | +| `store_cachekv_write` | Duration of a CacheKV `Store#Write` call | ms | summary | +| `store_cachekv_delete` | Duration of a CacheKV `Store#Delete` call | ms | summary | + +## Next {hide} + +Learn about the [object-capability](./ocap.md) model {hide} diff --git a/versioned_docs/version-0.45/develop/advanced-concepts/transaction_flow.svg b/versioned_docs/version-0.45/develop/advanced-concepts/transaction_flow.svg new file mode 100644 index 000000000..1ae962de3 --- /dev/null +++ b/versioned_docs/version-0.45/develop/advanced-concepts/transaction_flow.svg @@ -0,0 +1,48 @@ +UserUserbaseAppbaseApprouterrouterhandlerhandlermsgServermsgServerkeeperkeeperContext.EventManagerContext.EventManagerTransaction Type<Tx>Route(ctx, msgRoute)handlerMsg<Tx>(Context, Msg(...))<Tx>(Context, Msg)alt[addresses invalid, denominations wrong, etc.]errorperform action, update contextresults, error codeEmit relevant eventsmaybe wrap results in more structureresult, error coderesults, error code \ No newline at end of file diff --git a/versioned_docs/version-0.45/develop/advanced-concepts/transactions.md b/versioned_docs/version-0.45/develop/advanced-concepts/transactions.md new file mode 100644 index 000000000..710df881a --- /dev/null +++ b/versioned_docs/version-0.45/develop/advanced-concepts/transactions.md @@ -0,0 +1,159 @@ + + +# Transactions + +`Transactions` are objects created by end-users to trigger state changes in the application. {synopsis} + +## Pre-requisite Readings + +- [Anatomy of an SDK Application](../basics/app-anatomy.md) {prereq} + +## Transactions + +Transactions are comprised of metadata held in [contexts](./context.md) and [`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). + +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). + +## Type Definition + +Transaction objects are SDK types that implement the `Tx` interface + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/types/tx_msg.go#L49-L57 + +It contains the following methods: + +- **GetMsgs:** unwraps the transaction and returns a list of contained `sdk.Msg`s - one transaction may have one or multiple messages, which are defined by module developers. +- **ValidateBasic:** 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 `sdk.Msg` [`ValidateBasic`](../basics/tx-lifecycle.md#ValidateBasic) methods, which perform basic validity checks on messages only. When [`runTx`](./baseapp.md#runtx) is checking a transaction created from the [`auth`](https://github.com/cosmos/cosmos-sdk/tree/master/x/auth/spec) module, it first runs `ValidateBasic` on each message, then runs the `auth` module AnteHandler which calls `ValidateBasic` for the transaction itself. + +As a developer, you should rarely manipulate `Tx` directly, as `Tx` is really an intermediate type used for transaction generation. Instead, developers should prefer the `TxBuilder` interface, which you can learn more about [below](#transaction-generation). + +### Signing Transactions + +Every message in a transaction must be signed by the addresses specified by its `GetSigners`. The SDK currently allows signing transactions in two different ways. + +#### `SIGN_MODE_DIRECT` (preferred) + +The most used implementation of the `Tx` interface is the Protobuf `Tx` message, which is used in `SIGN_MODE_DIRECT`: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/proto/cosmos/tx/v1beta1/tx.proto#L12-L25 + +Because Protobuf serialization is not deterministic, the SDK uses an additional `TxRaw` type to denote the pinned bytes over which a transaction is signed. Any user can generate a valid `body` and `auth_info` for a transaction, and serialize these two messages using Protobuf. `TxRaw` then pins the user's exact binary representation of `body` and `auth_info`, called respectively `body_bytes` and `auth_info_bytes`. The document that is signed by all signers of the transaction is `SignDoc` (deterministically serialized using [ADR-027](../architecture/adr-027-deterministic-protobuf-serialization.md)): + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/proto/cosmos/tx/v1beta1/tx.proto#L47-L64 + +Once signed by all signers, the `body_bytes`, `auth_info_bytes` and `signatures` are gathered into `TxRaw`, whose serialized bytes are broadcasted over the network. + +#### `SIGN_MODE_LEGACY_AMINO_JSON` + +The legacy implemention of the `Tx` interface is the `StdTx` struct from `x/auth`: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/x/auth/legacy/legacytx/stdtx.go#L120-L130 + +The document signed by all signers is `StdSignDoc`: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/x/auth/legacy/legacytx/stdsign.go#L20-L33 + +which is encoded into bytes using Amino JSON. Once all signatures are gathered into `StdTx`, `StdTx` is serialized using Amino JSON, and these bytes are broadcasted over the network. + +#### Other Sign Modes + +Other sign modes, most notably `SIGN_MODE_TEXTUAL`, are being discussed. If you wish to learn more about them, please refer to [ADR-020](../architecture/adr-020-protobuf-transaction-encoding.md). + +## Transaction Process + +The process of an end-user sending a transaction is: + +- decide on the messages to put into the transaction, +- generate the transaction using the SDK's `TxBuilder`, +- broadcast the transaction using one of the available interfaces. + +The next paragraphs will describe each of these components, in this order. + +### Messages + +::: tip +Module `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. +::: + +**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`. + +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. + +To learn more about Protobuf `Msg` services and how to implement `MsgServer`, click [here](../building-modules/msg-services.md). + +While messages contain the information for state transition logic, a transaction's other metadata and relevant information are stored in the `TxBuilder` and `Context`. + +### Transaction Generation + +The `TxBuilder` interface contains data closely related with the generation of transactions, which an end-user can freely set to generate the desired transaction: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/client/tx_config.go#L32-L45 + +- `Msg`s, the array of [messages](#messages) included in the transaction. +- `GasLimit`, option chosen by the users for how to calculate how much gas they will need to pay. +- `Memo`, 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. + +As there are currently two sign modes for signing transactions, there are also two implementations of `TxBuilder`: + +- [wrapper](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/x/auth/tx/builder.go#L19-L33) for creating transactions for `SIGN_MODE_DIRECT`, +- [StdTxBuilder](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/x/auth/legacy/legacytx/stdtx_builder.go#L14-L20) for `SIGN_MODE_LEGACY_AMINO_JSON`. + +However, the two implementation of `TxBuilder` should be hidden away from end-users, as they should prefer using the overarching `TxConfig` interface: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/client/tx_config.go#L21-L30 + +`TxConfig` is an app-wide configuration for managing transactions. Most importantly, it holds the information about whether to sign each transaction with `SIGN_MODE_DIRECT` or `SIGN_MODE_LEGACY_AMINO_JSON`. By calling `txBuilder := txConfig.NewTxBuilder()`, a new `TxBuilder` will be created with the appropriate sign mode. + +Once `TxBuilder` is correctly populated with the setters exposed above, `TxConfig` will also take care of correctly encoding the bytes (again, either using `SIGN_MODE_DIRECT` or `SIGN_MODE_LEGACY_AMINO_JSON`). Here's a pseudo-code snippet of how to generate and encode a transaction, using the `TxEncoder()` method: + +```go +txBuilder := txConfig.NewTxBuilder() +txBuilder.SetMsgs(...) // and other setters on txBuilder + +bz, err := txConfig.TxEncoder()(txBuilder.GetTx()) +// bz are bytes to be broadcasted over the network +``` + +### Broadcasting the Transaction + +Once the transaction bytes are generated, there are currently three ways of broadcasting it. + +#### CLI + +Application developers create entrypoints to the application by creating a [command-line interface](../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. + +For the [command-line interface](../building-modules/module-interfaces.md#cli), module developers create subcommands to add as children to the application top-level transaction command `TxCmd`. CLI commands actually bundle all the steps of transaction processing into one simple command: creating messages, generating transactions and broadcasting. For concrete examples, see the [Interacting with a Node](../run-node/interact-node.md) section. An example transaction made using CLI looks like: + +```bash +simd tx send $MY_VALIDATOR_ADDRESS $RECIPIENT 1000stake +``` + +#### gRPC + +[gRPC](https://grpc.io) is introduced in Cosmos SDK 0.40 as the main component for the SDK's RPC layer. The principal usage of gRPC is in the context of modules' [`Query` services](../building-modules). However, the SDK also exposes a few other module-agnostic gRPC services, one of them being the `Tx` service: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/proto/cosmos/tx/v1beta1/service.proto + +The `Tx` service exposes a handful of utility functions, such as simulating a transaction or querying a transaction, and also one method to broadcast transactions. + +Examples of broadcasting and simulating a transaction are shown [here](../run-node/txs.md#programmatically-with-go). + +#### REST + +Each gRPC method has its corresponding REST endpoint, generated using [gRPC-gateway](https://github.com/grpc-ecosystem/grpc-gateway). Therefore, instead of using gRPC, you can also use HTTP to broadcast the same transaction, on the `POST /cosmos/tx/v1beta1/txs` endpoint. + +An example can be seen [here](../run-node/txs.md#using-rest) + +#### Tendermint RPC + +The three methods presented above are actually higher abstractions over the Tendermint RPC `/broadcast_tx_{async,sync,commit}` endpoints, documented [here](https://docs.tendermint.com/master/rpc/#/Tx). This means that you can use the Tendermint RPC endpoints directly to broadcast the transaction, if you wish so. + +## Next {hide} + +Learn about the [context](./context.md) {hide} diff --git a/versioned_docs/version-0.45/develop/advanced-concepts/upgrade.md b/versioned_docs/version-0.45/develop/advanced-concepts/upgrade.md new file mode 100644 index 000000000..c1cf37acd --- /dev/null +++ b/versioned_docs/version-0.45/develop/advanced-concepts/upgrade.md @@ -0,0 +1,160 @@ + + +# 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. + +- 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](/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. + +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. + +### 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 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 SDK upgrades the bank module and runs the "version 2 to 3" migration script. + +### 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 in the state. + +## 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. + +```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. + +```go +cfg := module.NewConfigurator(...) +app.UpgradeKeeper.SetUpgradeHandler("my-plan", func(ctx sdk.Context, plan upgradetypes.Plan, fromVM module.VersionMap) (module.VersionMap, error) { + + // ... + // additional upgrade logic + // ... + + // returns a VersionMap with the updated module ConsensusVersions + return app.mm.RunMigrations(ctx, fromVM) +}) +``` + +To learn more about configuring migration scripts for your modules, see the [Module Upgrade Guide](../building-modules/upgrade.md). + +### Order Of Migrations + +By default, all migrations are run in module name alphabetical ascending order, except `x/auth` which is run last. The reason is state dependencies between x/auth and other modules (you can read more in [issue #10606](https://github.com/cosmos/cosmos-sdk/issues/10606)). + +If you want to change the order of migration then you should call `app.mm.SetOrderMigrations(module1, module2, ...)` in your app.go file. The function will panic if you forget to include a module in the argument list. + +## 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. + +### Add StoreUpgrades for New Modules + +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() +if err != nil { + panic(err) +} + +if upgradeInfo.Name == "my-plan" && !app.UpgradeKeeper.IsSkipHeight(upgradeInfo.Height) { + storeUpgrades := storetypes.StoreUpgrades{ + // add store upgrades for new modules + // Example: + // Added: []string{"foo", "bar"}, + // ... + } + + // configure store loader that checks if version == upgradeHeight and applies store upgrades + app.SetStoreLoader(upgradetypes.UpgradeStoreLoader(upgradeInfo.Height, &storeUpgrades)) +} +``` + +## 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`: + +```diff +func (app *MyApp) InitChainer(ctx sdk.Context, req abci.RequestInitChain) abci.ResponseInitChain { + ... ++ app.UpgradeKeeper.SetModuleVersionMap(ctx, app.mm.GetVersionMap()) + ... +} +``` + +This information is used by the Cosmos SDK to detect when modules with newer versions are introduced to the app. + +For a new module `foo`, `InitGenesis` is called by `RunMigration` only when `foo` is registered in the module manager but it's not set in the `fromVM`. Therefore, if you want to skip `InitGenesis` when a new module is added to the app, then you should set its module version in `fromVM` to the module consensus version: + +```go +app.UpgradeKeeper.SetUpgradeHandler("my-plan", func(ctx sdk.Context, plan upgradetypes.Plan, fromVM module.VersionMap) (module.VersionMap, error) { + // ... + + // Set foo's version to the latest ConsensusVersion in the VersionMap. + // This will skip running InitGenesis on Foo + fromVM[foo.ModuleName] = foo.AppModule{}.ConsensusVersion() + + return app.mm.RunMigrations(ctx, fromVM) +}) +``` + +### 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. + +You can write your own `InitGenesis` function for an imported module. To do this, manually trigger your custom genesis function in the upgrade handler. + +::: 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`. +::: + +```go +import foo "github.com/my/module/foo" + +app.UpgradeKeeper.SetUpgradeHandler("my-plan", func(ctx sdk.Context, plan upgradetypes.Plan, fromVM module.VersionMap) (module.VersionMap, error) { + + // Register the consensus version in the version map + // to avoid the SDK from triggering the default + // InitGenesis function. + fromVM["foo"] = foo.AppModule{}.ConsensusVersion() + + // Run custom InitGenesis for foo + app.mm["foo"].InitGenesis(ctx, app.appCodec, myCustomGenesisState) + + return app.mm.RunMigrations(ctx, cfg, fromVM) +}) +``` + +## Syncing a Full Node to an Upgraded Blockchain + +You can sync a full node to an existing blockchain which has been upgraded using Cosmovisor + +In order to successfully sync, you must start with the initial binary that the blockchain started with at genesis. Cosmovisor will handle downloading and switching to the binaries associated with each sequential upgrade. + +To learn more about Cosmovisor, see the [Cosmovisor Quick Start](../run-node/cosmovisor.md). diff --git a/versioned_docs/version-0.45/develop/high-level-concepts/README.md b/versioned_docs/version-0.45/develop/high-level-concepts/README.md new file mode 100644 index 000000000..03934dcd5 --- /dev/null +++ b/versioned_docs/version-0.45/develop/high-level-concepts/README.md @@ -0,0 +1,17 @@ + + +# Basics + +This repository contains reference documentation on the basic concepts of the Cosmos SDK. + +1. [Anatomy of an SDK Application](./app-anatomy.md) +2. [Lifecycle of a transaction](./tx-lifecycle.md) +3. [Lifecycle of a query](./query-lifecycle.md) +4. [Accounts](./accounts.md) +5. [Gas and Fees](./gas-fees.md) + +After reading the basics, head on to the [Core Reference](../core/README.md) for more advanced material. diff --git a/versioned_docs/version-0.45/develop/high-level-concepts/accounts.md b/versioned_docs/version-0.45/develop/high-level-concepts/accounts.md new file mode 100644 index 000000000..b8bcb76ae --- /dev/null +++ b/versioned_docs/version-0.45/develop/high-level-concepts/accounts.md @@ -0,0 +1,153 @@ + + +# Accounts + +This document describes the in-built account and public key system of the Cosmos SDK. {synopsis} + +### Pre-requisite Readings + +- [Anatomy of an SDK Application](./app-anatomy.md) {prereq} + +## Account Definition + +In the Cosmos SDK, an _account_ designates a pair of _public key_ `PubKey` and _private key_ `PrivKey`. The `PubKey` can be derived to generate various `Addresses`, which are used to identify users (among other parties) in the application. `Addresses` are also associated with [`message`s](../building-modules/messages-and-queries.md#messages) to identify the sender of the `message`. The `PrivKey` is used to generate [digital signatures](#signatures) to prove that an `Address` associated with the `PrivKey` approved of a given `message`. + +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. + +``` + Account 0 Account 1 Account 2 + ++------------------+ +------------------+ +------------------+ +| | | | | | +| Address 0 | | Address 1 | | Address 2 | +| ^ | | ^ | | ^ | +| | | | | | | | | +| | | | | | | | | +| | | | | | | | | +| + | | + | | + | +| Public key 0 | | Public key 1 | | Public key 2 | +| ^ | | ^ | | ^ | +| | | | | | | | | +| | | | | | | | | +| | | | | | | | | +| + | | + | | + | +| Private key 0 | | Private key 1 | | Private key 2 | +| ^ | | ^ | | ^ | ++------------------+ +------------------+ +------------------+ + | | | + | | | + | | | + +--------------------------------------------------------------------+ + | + | + +---------+---------+ + | | + | Master PrivKey | + | | + +-------------------+ + | + | + +---------+---------+ + | | + | Mnemonic (Seed) | + | | + +-------------------+ +``` + +In the Cosmos SDK, keys are stored and managed by using an object called a [`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). + +In the node, all data is stored using Protocol Buffers serialization. + +The Cosmos SDK supports the following digital key schemes for creating digital signatures: + +- `secp256k1`, as implemented in the [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 [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 [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. + +| | Address length | Public key length | Used for transaction | Used for consensus | +| | in bytes | in bytes | authentication | (tendermint) | +|--------------+----------------+-------------------+----------------------+--------------------| +| `secp256k1` | 20 | 33 | yes | no | +| `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. + +Each account is identified using `Address` which is a sequence of bytes derived from a public key. In SDK, we define 3 types of addresses that specify a context where an account is used: + +- `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. + +These types implement the `Address` interface: + ++++ 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: + +```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. + +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: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.42.1/types/address.go#L230-L244 + +| | Address Bech32 Prefix | +| ------------------ | --------------------- | +| Accounts | cosmos | +| 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: + ++++ 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. + +- The first byte is a `0x02` byte if the `y`-coordinate is the lexicographically largest of the two associated with the `x`-coordinate. +- Otherwise the first byte is a `0x03`. + +This prefix is followed by the `x`-coordinate. + +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: + ++++ 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: + ++++ 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. + +A few notes on the `Keyring` methods: + +- `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 SDK by default, it is deferred to the [`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: + +- `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. + +## Next {hide} + +Learn about [gas and fees](./gas-fees.md) {hide} diff --git a/versioned_docs/version-0.45/develop/high-level-concepts/app-anatomy.md b/versioned_docs/version-0.45/develop/high-level-concepts/app-anatomy.md new file mode 100644 index 000000000..0373d24aa --- /dev/null +++ b/versioned_docs/version-0.45/develop/high-level-concepts/app-anatomy.md @@ -0,0 +1,264 @@ + + +# Anatomy of an SDK Application + +This document describes the core parts of a Cosmos SDK application. Throughout the document, a placeholder application named `app` will be used. {synopsis} + +## Node Client + +The Daemon, or [Full-Node Client](../core/node.md), is the core process of an SDK-based blockchain. Participants in the network run this process to initialize their state-machine, connect with other full-nodes and update their state-machine as new blocks come in. + +``` + ^ +-------------------------------+ ^ + | | | | + | | State-machine = Application | | + | | | | Built with Cosmos SDK + | | ^ + | | + | +----------- | ABCI | ----------+ v + | | + v | ^ + | | | | +Blockchain Node | | Consensus | | + | | | | + | +-------------------------------+ | Tendermint Core + | | | | + | | Networking | | + | | | | + v +-------------------------------+ v +``` + +The blockchain full-node presents itself as a binary, generally suffixed by `-d` for "daemon" (e.g. `appd` for `app` or `gaiad` for `gaia`). This binary is built by running a simple [`main.go`](../core/node.md#main-function) function placed in `./cmd/appd/`. This operation usually happens through the [Makefile](#dependencies-and-makefile). + +Once the main binary is built, the node can be started by running the [`start` command](../core/node.md#start-command). This command function primarily does three things: + +1. Create an instance of the state-machine defined in [`app.go`](#core-application-file). +2. Initialize the state-machine with the latest known state, extracted from the `db` stored in the `~/.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). + +## Core Application File + +In general, the core of the state-machine is defined in a file called `app.go`. It mainly contains the **type definition of the application** and functions to **create and initialize it**. + +### Type Definition of the Application + +The first thing defined in `app.go` is the `type` of the application. It is generally comprised of the following parts: + +- **A reference to [`baseapp`](../core/baseapp.md).** The custom application defined in `app.go` is an extension of `baseapp`. When a transaction is relayed by Tendermint to the application, `app` uses `baseapp`'s methods to route them to the appropriate module. `baseapp` implements most of the core logic for the application, including all the [ABCI methods](https://tendermint.com/docs/spec/abci/abci.html#overview) and the [routing logic](../core/baseapp.md#routing). +- **A list of store keys**. The [store](../core/store.md), which contains the entire state, is implemented as a [`multistore`](../core/store.md#multistore) (i.e. a store of stores) in the Cosmos SDK. Each module uses one or multiple stores in the multistore to persist their part of the state. These stores can be accessed with specific keys that are declared in the `app` type. These keys, along with the `keepers`, are at the heart of the [object-capabilities model](../core/ocap.md) of the Cosmos SDK. +- **A list of module's `keeper`s.** Each module defines an abstraction called [`keeper`](../building-modules/keeper.md), which handles reads and writes for this module's store(s). The `keeper`'s methods of one module can be called from other modules (if authorized), which is why they are declared in the application's type and exported as interfaces to other modules so that the latter can only access the authorized functions. +- **A reference to an [`appCodec`](../core/encoding.md).** The application's `appCodec` is used to serialize and deserialize data structures in order to store them, as stores can only persist `[]bytes`. The default codec is [Protocol Buffers](../core/encoding.md). +- **A reference to a [`legacyAmino`](../core/encoding.md) codec.** Some parts of the SDK have not been migrated to use the `appCodec` above, and are still hardcoded to use Amino. Other parts explicity use Amino for backwards compatibility. For these reasons, the application still holds a reference to the legacy Amino codec. Please note that the Amino codec will be removed from the SDK in the upcoming releases. +- **A reference to a [module manager](../building-modules/module-manager.md#manager)** and a [basic module manager](../building-modules/module-manager.md#basicmanager). The module manager is an object that contains a list of the application's module. It facilitates operations related to these modules, like registering their [`Msg` service](../core/baseapp.md#msg-services) and [gRPC `Query` service](../core/baseapp.md#grpc-query-services), or setting the order of execution between modules for various functions like [`InitChainer`](#initchainer), [`BeginBlocker` and `EndBlocker`](#beginblocker-and-endblocker). + +See an example of application type definition from `simapp`, the SDK's own app used for demo and testing purposes: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/simapp/app.go#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. + ++++ 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 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 remainer of application's parameters: + - [`InitChainer`](#initchainer): used to initialize the application when it is first started. + - [`BeginBlocker`, `EndBlocker`](#beginblocker-and-endlbocker): called at the beginning and the end of every block). + - [`anteHandler`](../core/baseapp.md#antehandler): used to handle fees and signature verification. +- Mount the stores. +- Return the application. + +Note that this function only creates an instance of the app, while the actual state is either carried over from the `~/.app/data` folder if the node is restarted, or generated from the genesis file if the node is started for the first time. + +See an example of application constructor from `simapp`: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/simapp/app.go#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. + +In general, the `InitChainer` is mostly composed of the [`InitGenesis`](../building-modules/genesis.md#initgenesis) function of each of the application's modules. This is done by calling the `InitGenesis` function of the module manager, which in turn will call the `InitGenesis` function of each of the modules it contains. Note that the order in which the modules' `InitGenesis` functions must be called has to be set in the module manager using the [module manager's](../building-modules/module-manager.md) `SetOrderInitGenesis` method. This is done in the [application's constructor](#application-constructor), and the `SetOrderInitGenesis` has to be called before the `SetInitChainer`. + +See an example of an `InitChainer` from `simapp`: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/simapp/app.go#L464-L471 + +### BeginBlocker and EndBlocker + +The SDK offers developers the possibility to implement automatic execution of code as part of their application. This is implemented through two function called `BeginBlocker` and `EndBlocker`. They are called when the application receives respectively the `BeginBlock` and `EndBlock` messages from the Tendermint engine, which happens at the beginning and at the end of each block. The application must set the `BeginBlocker` and `EndBlocker` in its [constructor](#constructor-function) via the [`SetBeginBlocker`](https://godoc.org/github.com/cosmos/cosmos-sdk/baseapp#BaseApp.SetBeginBlocker) and [`SetEndBlocker`](https://godoc.org/github.com/cosmos/cosmos-sdk/baseapp#BaseApp.SetEndBlocker) methods. + +In general, the `BeginBlocker` and `EndBlocker` functions are mostly composed of the [`BeginBlock` and `EndBlock`](../building-modules/beginblock-endblock.md) functions of each of the application's modules. This is done by calling the `BeginBlock` and `EndBlock` functions of the module manager, which in turn will call the `BeginBLock` and `EndBlock` functions of each of the modules it contains. Note that the order in which the modules' `BegingBlock` and `EndBlock` functions must be called has to be set in the module manager using the `SetOrderBeginBlock` and `SetOrderEndBlock` methods respectively. This is done via the [module manager](../building-modules/module-manager.md) in the [application's constructor](#application-constructor), and the `SetOrderBeginBlock` and `SetOrderEndBlock` methods have to be called before the `SetBeginBlocker` and `SetEndBlocker` functions. + +As a sidenote, it is important to remember that application-specific blockchains are deterministic. Developers must be careful not to introduce non-determinism in `BeginBlocker` or `EndBlocker`, and must also be careful not to make them too computationally expensive, as [gas](./gas-fees.md) does not constrain the cost of `BeginBlocker` and `EndBlocker` execution. + +See an example of `BeginBlocker` and `EndBlocker` functions from `simapp` + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/simapp/app.go#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. + ++++ 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 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 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 SDK still use Amino for backwards-compatibility. Each module exposes a `RegisterLegacyAmino` method to register the module's specific types within Amino. This `Amino` codec should not be used by app developers anymore, and will be removed in future releases. + +The SDK exposes a `MakeTestEncodingConfig` function used to create a `EncodingConfig` for the app constructor (`NewApp`). It uses Protobuf as a default `Marshaler`. +NOTE: this function is marked deprecated and should only be used to create an app or in tests. We are working on refactoring codec management in a post Stargate release. + +See an example of a `MakeTestEncodingConfig` from `simapp`: + ++++ 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 SDK applications. They can be considered as state-machines within the state-machine. When a transaction is relayed from the underlying Tendermint engine via the ABCI to the application, it is routed by [`baseapp`](../core/baseapp.md) to the appropriate module in order to be processed. This paradigm enables developers to easily build complex state-machines, as most of the modules they need often already exist. For developers, most of the work involved in building an SDK application revolves around building custom modules required by their application that do not exist yet, and integrating them with modules that do already exist into one coherent application. In the application directory, the standard practice is to store modules in the `x/` folder (not to be confused with the SDK's `x/` folder, which contains already-built modules). + +### Application Module Interface + +Modules must implement [interfaces](../building-modules/module-manager.md#application-module-interfaces) defined in the Cosmos SDK, [`AppModuleBasic`](../building-modules/module-manager.md#appmodulebasic) and [`AppModule`](../building-modules/module-manager.md#appmodule). The former implements basic non-dependant elements of the module, such as the `codec`, while the latter handles the bulk of the module methods (including methods that require references to other modules' `keeper`s). Both the `AppModule` and `AppModuleBasic` types are defined in a file called `./module.go`. + +`AppModule` exposes a collection of useful methods on the module that facilitates the composition of modules into a coherent application. These methods are are called from the `module manager`(../building-modules/module-manager.md#manager), which manages the application's collection of modules. + +### `Msg` Services + +Each module defines two [Protobuf services](https://developers.google.com/protocol-buffers/docs/proto#services): one `Msg` service to handle messages, and one gRPC `Query` service to handle queries. If we consider the module as a state-machine, then a `Msg` 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. + +When a valid block of transactions is received by the full-node, Tendermint relays each one to the application via [`DeliverTx`](https://tendermint.com/docs/app-dev/abci-spec.html#delivertx). Then, the application handles the transaction: + +1. Upon receiving the transaction, the application first unmarshalls it from `[]bytes`. +2. Then, it verifies a few things about the transaction like [fee payment and signatures](#gas-fees.md#antehandler) before extracting the `Msg`(s) contained in the transaction. +3. `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. + +For a more details look at a transaction [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: + ++++ 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. + +Each module should also implement the `RegisterServices` method as part of the [`AppModule` interface](#application-module-interface). This method should call the `RegisterMsgServer` function provided by the generated Protobuf code. + +### gRPC `Query` Services + +gRPC `Query` services are introduced in the v0.40 Stargate release. They allow users to query the state using [gRPC](https://grpc.io). They are enabled by default, and can be configued under the `grpc.enable` and `grpc.address` fields inside [`app.toml`](../run-node/run-node.md#configuring-the-node-using-apptoml). + +gRPC `Query` services are defined in the module's Protobuf definition files, specifically inside `query.proto`. The `query.proto` definition file exposes a single `Query` [Protobuf service](https://developers.google.com/protocol-buffers/docs/proto#services). Each gRPC query endpoint corresponds to a service method, starting with the `rpc` keyword, inside the `Query` service. + +Protobuf generates a `QueryServer` interface for each module, containing all the service methods. A module's [`keeper`](#keeper) then needs to implement this `QueryServer` interface, by providing the concrete implementation of each service method. This concrete implementation is the handler of the corresponding gRPC query endpoint. + +Finally, each module should also implement the `RegisterServices` method as part of the [`AppModule` interface](#application-module-interface). This method should call the `RegisterQueryServer` function provided by the generated Protobuf code. + +### Keeper + +[`Keepers`](../building-modules/keeper.md) are the gatekeepers of their module's store(s). To read or write in a module's store, it is mandatory to go through one of its `keeper`'s methods. This is ensured by the [object-capabilities](../core/ocap.md) model of the Cosmos SDK. Only objects that hold the key to a store can access it, and only the module's `keeper` should hold the key(s) to the module's store(s). + +`Keepers` are generally defined in a file called `keeper.go`. It contains the `keeper`'s type definition and methods. + +The `keeper` type definition generally consists of: + +- **Key(s)** to the module's store(s) in the multistore. +- Reference to **other module's `keepers`**. Only needed if the `keeper` needs to access other module's store(s) (either to read or write from them). +- A reference to the application's **codec**. The `keeper` needs it to marshal structs before storing them, or to unmarshal them when it retrieves them, because stores only accept `[]bytes` as value. + +Along with the type definition, the next important component of the `keeper.go` file is the `keeper`'s constructor function, `NewKeeper`. This function instantiates a new `keeper` of the type defined above, with a `codec`, store `keys` and potentially references to other modules' `keeper`s as parameters. The `NewKeeper` function is called from the [application's constructor](#constructor-function). The rest of the file defines the `keeper`'s methods, primarily getters and setters. + +### Command-Line, gRPC Services and REST Interfaces + +Each module defines command-line commands, gRPC services and REST routes to be exposed to end-user via the [application's interfaces](#application-interfaces). This enables end-users to create messages of the types defined in the module, or to query the subset of the state managed by the module. + +#### CLI + +Generally, the [commands related to a module](../building-modules/module-interfaces.md#cli) are defined in a folder called `client/cli` in the module's folder. The CLI divides commands in two category, transactions and queries, defined in `client/cli/tx.go` and `client/cli/query.go` respectively. Both commands are built on top of the [Cobra Library](https://github.com/spf13/cobra): + +- Transactions commands let users generate new transactions so that they can be included in a block and eventually update the state. One command should be created for each [message type](#message-types) defined in the module. The command calls the constructor of the message with the parameters provided by the end-user, and wraps it into a transaction. The SDK handles signing and the addition of other transaction metadata. +- Queries let users query the subset of the state defined by the module. Query commands forward queries to the [application's query router](../core/baseapp.md#query-routing), which routes them to the appropriate [querier](#querier) the `queryRoute` parameter supplied. + +#### gRPC + +[gRPC](https://grpc.io) is a modern open source high performance RPC framework that has support in multiple languages. It is the recommended way for external clients (such as wallets, browsers and other backend services) to interact with a node. + +Each module can expose gRPC endpoints, called [service methods](https://grpc.io/docs/what-is-grpc/core-concepts/#service-definition) and are defined in the [module's Protobuf `query.proto` file](#grpc-query-services). A service method is defined by its name, input arguments and output response. The module then needs to: + +- define a `RegisterGRPCGatewayRoutes` method on `AppModuleBasic` to wire the client gRPC requests to the correct handler inside the module. +- for each service method, define a corresponding handler. The handler implements the core logic necessary to serve the gRPC request, and is located in the `keeper/grpc_query.go` file. + +#### gRPC-gateway REST Endpoints + +Some external clients may not wish to use gRPC. The SDK provides in this case a gRPC gateway service, which exposes each gRPC service as a correspoding REST endpoint. Please refer to the [grpc-gateway](https://grpc-ecosystem.github.io/grpc-gateway/) documentation to learn more. + +The REST endpoints are defined in the Protobuf files, along with the gRPC services, using Protobuf annotations. Modules that want to expose REST queries should add `google.api.http` annotations to their `rpc` methods. By default, all REST endpoints defined in the SDK have an URL starting with the `/cosmos/` prefix. + +The SDK also provides a development endpoint to generate [Swagger](https://swagger.io/) definition files for these REST endpoints. This endpoint can be enabled inside the [`app.toml`](../run-node/run-node.md#configuring-the-node-using-apptoml) config file, under the `api.swagger` key. + +#### Legacy API REST Endpoints + +The [module's Legacy REST interface](../building-modules/module-interfaces.md#legacy-rest) lets users generate transactions and query the state through REST calls to the application's Legacy API Service. REST routes are defined in a file `client/rest/rest.go`, which is composed of: + +- A `RegisterRoutes` function, which registers each route defined in the file. This function is called from the [main application's interface](#application-interfaces) for each module used within the application. The router used in the SDK is [Gorilla's mux](https://github.com/gorilla/mux). +- Custom request type definitions for each query or transaction creation function that needs to be exposed. These custom request types build on the base `request` type of the Cosmos SDK: + +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/types/rest/rest.go#L62-L76 +- One handler function for each request that can be routed to the given module. These functions implement the core logic necessary to serve the request. + +These Legacy API endpoints are present in the SDK for backward compatibility purposes and will be removed in the next release. + +## Application Interface + +[Interfaces](#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. + +The main interface is the [Command-Line Interface](../core/cli.md). The CLI of an SDK application is built by aggregating [CLI commands](#cli) defined in each of the modules used by the application. The CLI of an application is the same as the daemon (e.g. `appd`), and defined in a file called `appd/main.go`. The file contains: + +- **A `main()` function**, which is executed to build the `appd` interface client. This function prepares each command and adds them to the `rootCmd` before building them. At the root of `appd`, the function adds generic commands like `status`, `keys` and `config`, query commands, tx commands and `rest-server`. +- **Query commands** are added by calling the `queryCmd` function. This function returns a Cobra command that contains the query commands defined in each of the application's modules (passed as an array of `sdk.ModuleClients` from the `main()` function), as well as some other lower level query commands such as block or validator queries. Query command are called by using the command `appd query [query]` of the CLI. +- **Transaction commands** are added by calling the `txCmd` function. Similar to `queryCmd`, the function returns a Cobra command that contains the tx commands defined in each of the application's modules, as well as lower level tx commands like transaction signing or broadcasting. Tx commands are called by using the command `appd tx [tx]` of the CLI. + +See an example of an application's main command-line file from the [nameservice tutorial](https://github.com/cosmos/sdk-tutorials/tree/master/nameservice) + ++++ https://github.com/cosmos/sdk-tutorials/blob/86a27321cf89cc637581762e953d0c07f8c78ece/nameservice/cmd/nscli/main.go + +## Dependencies and Makefile + +::: warning +A patch introduced in `go-grpc v1.34.0` made gRPC incompatible with the `gogoproto` library, making some [gRPC queries](https://github.com/cosmos/cosmos-sdk/issues/8426) panic. As such, the SDK requires that `go-grpc <=v1.33.2` is installed in your `go.mod`. + +To make sure that gRPC is working properly, it is **highly recommended** to add the following line in your application's `go.mod`: + +``` +replace google.golang.org/grpc => google.golang.org/grpc v1.33.2 +``` + +Please see [issue #8392](https://github.com/cosmos/cosmos-sdk/issues/8392) for more info. +::: + +This section is optional, as developers are free to choose their dependency manager and project building method. That said, the current most used framework for versioning control is [`go.mod`](https://github.com/golang/go/wiki/Modules). It ensures each of the libraries used throughout the application are imported with the correct version. See an example from the [nameservice tutorial](https://github.com/cosmos/sdk-tutorials/tree/master/nameservice): + ++++ https://github.com/cosmos/sdk-tutorials/blob/c6754a1e313eb1ed973c5c91dcc606f2fd288811/go.mod#L1-L18 + +For building the application, a [Makefile](https://en.wikipedia.org/wiki/Makefile) is generally used. The Makefile primarily ensures that the `go.mod` is run before building the two entrypoints to the application, [`appd`](#node-client) and [`appd`](#application-interface). See an example of Makefile from the [nameservice tutorial](https://tutorials.cosmos.network/nameservice/tutorial/00-intro.html) + ++++ https://github.com/cosmos/sdk-tutorials/blob/86a27321cf89cc637581762e953d0c07f8c78ece/nameservice/Makefile + +## Next {hide} + +Learn more about the [Lifecycle of a transaction](./tx-lifecycle.md) {hide} diff --git a/versioned_docs/version-0.45/develop/high-level-concepts/gas-fees.md b/versioned_docs/version-0.45/develop/high-level-concepts/gas-fees.md new file mode 100644 index 000000000..0a93c1335 --- /dev/null +++ b/versioned_docs/version-0.45/develop/high-level-concepts/gas-fees.md @@ -0,0 +1,89 @@ + + +# Gas and Fees + +This document describes the default strategies to handle gas and fees within a Cosmos SDK application. {synopsis} + +### Pre-requisite Readings + +- [Anatomy of an SDK Application](./app-anatomy.md) {prereq} + +## Introduction to `Gas` and `Fees` + +In the Cosmos SDK, `gas` is a special unit that is used to track the consumption of resources during execution. `gas` is typically consumed whenever read and writes are made to the store, but it can also be consumed if expensive computation needs to be done. It serves two main purposes: + +- Make sure blocks are not consuming too many resources and will be finalized. This is implemented by default in the SDK via the [block gas meter](#block-gas-meter). +- Prevent spam and abuse from end-user. To this end, `gas` consumed during [`message`](../building-modules/messages-and-queries.md#messages) execution is typically priced, resulting in a `fee` (`fees = gas * gas-prices`). `fees` generally have to be paid by the sender of the `message`. Note that the SDK does not enforce `gas` pricing by default, as there may be other ways to prevent spam (e.g. bandwidth schemes). Still, most applications will implement `fee` mechanisms to prevent spam. This is done via the [`AnteHandler`](#antehandler). + +## Gas Meter + +In the Cosmos SDK, `gas` is a simple alias for `uint64`, and is managed by an object called a _gas meter_. Gas meters implement the `GasMeter` interface + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/store/types/gas.go#L34-L43 + +where: + +- `GasConsumed()` returns the amount of gas that was consumed by the gas meter instance. +- `GasConsumedToLimit()` returns the amount of gas that was consumed by gas meter instance, or the limit if it is reached. +- `Limit()` returns the limit of the gas meter instance. `0` if the gas meter is infinite. +- `ConsumeGas(amount Gas, descriptor string)` consumes the amount of `gas` provided. If the `gas` overflows, it panics with the `descriptor` message. If the gas meter is not infinite, it panics if `gas` consumed goes above the limit. +- `IsPastLimit()` returns `true` if the amount of gas consumed by the gas meter instance is strictly above the limit, `false` otherwise. +- `IsOutOfGas()` returns `true` if the amount of gas consumed by the gas meter instance is above or equal to the limit, `false` otherwise. + +The gas meter is generally held in [`ctx`](../core/context.md), and consuming gas is done with the following pattern: + +```go +ctx.GasMeter().ConsumeGas(amount, "description") +``` + +By default, the Cosmos SDK makes use of two different gas meters, the [main gas meter](#main-gas-metter[) and the [block gas meter](#block-gas-meter). + +### Main Gas Meter + +`ctx.GasMeter()` is the main gas meter of the application. The main gas meter is initialized in `BeginBlock` via `setDeliverState`, and then tracks gas consumption during execution sequences that lead to state-transitions, i.e. those originally triggered by [`BeginBlock`](../core/baseapp.md#beginblock), [`DeliverTx`](../core/baseapp.md#delivertx) and [`EndBlock`](../core/baseapp.md#endblock). At the beginning of each `DeliverTx`, the main gas meter **must be set to 0** in the [`AnteHandler`](#antehandler), so that it can track gas consumption per-transaction. + +Gas consumption can be done manually, generally by the module developer in the [`BeginBlocker`, `EndBlocker`](../building-modules/beginblock-endblock.md) or [`Msg` service](../building-modules/msg-services.md), but most of the time it is done automatically whenever there is a read or write to the store. This automatic gas consumption logic is implemented in a special store called [`GasKv`](../core/store.md#gaskv-store). + +### Block Gas Meter + +`ctx.BlockGasMeter()` is the gas meter used to track gas consumption per block and make sure it does not go above a certain limit. A new instance of the `BlockGasMeter` is created each time [`BeginBlock`](../core/baseapp.md#beginblock) is called. The `BlockGasMeter` is finite, and the limit of gas per block is defined in the application's consensus parameters. By default Cosmos SDK applications use the default consensus parameters provided by Tendermint: + ++++ https://github.com/tendermint/tendermint/blob/v0.34.0-rc6/types/params.go#L34-L41 + +When a new [transaction](../core/transactions.md) is being processed via `DeliverTx`, the current value of `BlockGasMeter` is checked to see if it is above the limit. If it is, `DeliverTx` returns immediately. This can happen even with the first transaction in a block, as `BeginBlock` itself can consume gas. If not, the transaction is processed normally. At the end of `DeliverTx`, the gas tracked by `ctx.BlockGasMeter()` is increased by the amount consumed to process the transaction: + +```go +ctx.BlockGasMeter().ConsumeGas( + ctx.GasMeter().GasConsumedToLimit(), + "block gas meter", +) +``` + +## AnteHandler + +The `AnteHandler` is run for every transaction during `CheckTx` and `DeliverTx`, before a Protobuf `Msg` service method for each `sdk.Msg` in the transaction. `AnteHandler`s have the following signature: + +```go +// AnteHandler authenticates transactions, before their internal messages are handled. +// If newCtx.IsZero(), ctx is used instead. +type AnteHandler func(ctx Context, tx Tx, simulate bool) (newCtx Context, result Result, abort bool) +``` + +The `anteHandler` is not implemented in the core SDK but in a module. This gives the possibility to developers to choose which version of `AnteHandler` fits their application's needs. That said, most applications today use the default implementation defined in the [`auth` module](https://github.com/cosmos/cosmos-sdk/tree/master/x/auth). Here is what the `anteHandler` is intended to do in a normal Cosmos SDK application: + +- Verify that the transaction are of the correct type. Transaction types are defined in the module that implements the `anteHandler`, and they follow the transaction interface: + +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/types/tx_msg.go#L49-L57 + This enables developers to play with various types for the transaction of their application. In the default `auth` module, the default transaction type is `Tx`: + +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/proto/cosmos/tx/v1beta1/tx.proto#L12-L25 +- Verify signatures for each [`message`](../building-modules/messages-and-queries.md#messages) contained in the transaction. Each `message` should be signed by one or multiple sender(s), and these signatures must be verified in the `anteHandler`. +- During `CheckTx`, verify that the gas prices provided with the transaction is greater than the local `min-gas-prices` (as a reminder, gas-prices can be deducted from the following equation: `fees = gas * gas-prices`). `min-gas-prices` is a parameter local to each full-node and used during `CheckTx` to discard transactions that do not provide a minimum amount of fees. This ensure that the mempool cannot be spammed with garbage transactions. +- Verify that the sender of the transaction has enough funds to cover for the `fees`. When the end-user generates a transaction, they must indicate 2 of the 3 following parameters (the third one being implicit): `fees`, `gas` and `gas-prices`. This signals how much they are willing to pay for nodes to execute their transaction. The provided `gas` value is stored in a parameter called `GasWanted` for later use. +- Set `newCtx.GasMeter` to 0, with a limit of `GasWanted`. **This step is extremely important**, as it not only makes sure the transaction cannot consume infinite gas, but also that `ctx.GasMeter` is reset in-between each `DeliverTx` (`ctx` is set to `newCtx` after `anteHandler` is run, and the `anteHandler` is run each time `DeliverTx` is called). + +As explained above, the `anteHandler` returns a maximum limit of `gas` the transaction can consume during execution called `GasWanted`. The actual amount consumed in the end is denominated `GasUsed`, and we must therefore have `GasUsed =< GasWanted`. Both `GasWanted` and `GasUsed` are relayed to the underlying consensus engine when [`DeliverTx`](../core/baseapp.md#delivertx) returns. + +## Next {hide} + +Learn about [baseapp](../core/baseapp.md) {hide} diff --git a/versioned_docs/version-0.45/develop/high-level-concepts/query-lifecycle.md b/versioned_docs/version-0.45/develop/high-level-concepts/query-lifecycle.md new file mode 100644 index 000000000..55902e698 --- /dev/null +++ b/versioned_docs/version-0.45/develop/high-level-concepts/query-lifecycle.md @@ -0,0 +1,152 @@ + + +# Query Lifecycle + +This document describes the lifecycle of a query in a SDK application, from the user interface to application stores and back. {synopsis} + +## Pre-requisite Readings + +- [Transaction Lifecycle](./tx-lifecycle.md) {prereq} + +## Query Creation + +A [**query**](../building-modules/messages-and-queries.md#queries) is a request for information made by end-users of applications through an interface and processed by a full-node. Users can query information about the network, the application itself, and application state directly from the application's stores or modules. Note that queries are different from [transactions](../core/transactions.md) (view the lifecycle [here](./tx-lifecycle.md)), particularly in that they do not require consensus to be processed (as they do not trigger state-transitions); they can be fully handled by one full-node. + +For the purpose of explaining the query lifecycle, let's say `MyQuery` is requesting a list of delegations made by a certain delegator address in the application called `simapp`. As to be expected, the [`staking`](../../x/staking/spec/README.md) module handles this query. But first, there are a few ways `MyQuery` can be created by users. + +### CLI + +The main interface for an application is the command-line interface. Users connect to a full-node and run the CLI directly from their machines - the CLI interacts directly with the full-node. To create `MyQuery` from their terminal, users type the following command: + +```bash +simd query staking delegations +``` + +This query command was defined by the [`staking`](../../x/staking/spec/README.md) module developer and added to the list of subcommands by the application developer when creating the CLI. + +Note that the general format is as follows: + +```bash +simd query [moduleName] [command] --flag +``` + +To provide values such as `--node` (the full-node the CLI connects to), the user can use the [`app.toml`](../run-node/run-node.md#configuring-the-node-using-apptoml) config file to set them or provide them as flags. + +The CLI understands a specific set of commands, defined in a hierarchical structure by the application developer: from the [root command](../core/cli.md#root-command) (`simd`), the type of command (`Myquery`), the module that contains the command (`staking`), and command itself (`delegations`). Thus, the CLI knows exactly which module handles this command and directly passes the call there. + +### gRPC + +::: warning +A patch introduced in `go-grpc v1.34.0` made gRPC incompatible with the `gogoproto` library, making some [gRPC queries](https://github.com/cosmos/cosmos-sdk/issues/8426) panic. As such, the SDK requires that `go-grpc <=v1.33.2` is installed in your `go.mod`. + +To make sure that gRPC is working properly, it is **highly recommended** to add the following line in your application's `go.mod`: + +``` +replace google.golang.org/grpc => google.golang.org/grpc v1.33.2 +``` + +Please see [issue #8392](https://github.com/cosmos/cosmos-sdk/issues/8392) for more info. +::: + +Another interface through which users can make queries, introduced in Cosmos SDK v0.40, is [gRPC](https://grpc.io) requests to a [gRPC server](../core/grpc_rest.md#grpc-server). The endpoints are defined as [Protocol Buffers](https://developers.google.com/protocol-buffers) service methods inside `.proto` files, written in Protobuf's own language-agnostic interface definition language (IDL). The Protobuf ecosystem developed tools for code-generation from `*.proto` files into various languages. These tools allow to build gRPC clients easily. + +One such tool is [grpcurl](https://github.com/fullstorydev/grpcurl), and a gRPC request for `MyQuery` using this client looks like: + +```bash +grpcurl \ + -plaintext # We want results in plain test + -import-path ./proto \ # Import these .proto files + -proto ./proto/cosmos/staking/v1beta1/query.proto \ # Look into this .proto file for the Query protobuf service + -d '{"address":"$MY_DELEGATOR"}' \ # Query arguments + localhost:9090 \ # gRPC server endpoint + cosmos.staking.v1beta1.Query/Delegations # Fully-qualified service method name +``` + +### REST + +Another interface through which users can make queries is through HTTP Requests to a [REST server](../core/grpc_rest.md#rest-server). The REST server is fully auto-generated from Protobuf services, using [gRPC-gateway](https://github.com/grpc-ecosystem/grpc-gateway). + +An example HTTP request for `MyQuery` looks like: + +```bash +GET http://localhost:1317/cosmos/staking/v1beta1/delegators/{delegatorAddr}/delegations +``` + +## How Queries are Handled by the CLI + +The examples above show how an external user can interact with a node by querying its state. To understand more in details the exact lifecycle of a query, let's dig into how the CLI prepares the query, and how the node handles it. The interactions from the users' perspective are a bit different, but the underlying functions are almost identical because they are implementations of the same command defined by the module developer. This step of processing happens within the CLI, gRPC or REST server and heavily involves a `client.Context`. + +### Context + +The first thing that is created in the execution of a CLI command is a `client.Context`. A `client.Context` is an object that stores all the data needed to process a request on the user side. In particular, a `client.Context` stores the following: + +- **Codec**: The [encoder/decoder](../core/encoding.md) used by the application, used to marshal the parameters and query before making the Tendermint RPC request and unmarshal the returned response into a JSON object. The default codec used by the CLI is Protobuf. +- **Account Decoder**: The account decoder from the [`auth`](../..//x/auth/spec/README.md) module, which translates `[]byte`s into accounts. +- **RPC Client**: The Tendermint RPC Client, or node, to which the request will be relayed to. +- **Keyring**: A [Key Manager](../basics/accounts.md#keyring) used to sign transactions and handle other operations with keys. +- **Output Writer**: A [Writer](https://golang.org/pkg/io/#Writer) used to output the response. +- **Configurations**: The flags configured by the user for this command, including `--height`, specifying the height of the blockchain to query and `--indent`, which indicates to add an indent to the JSON response. + +The `client.Context` also contains various functions such as `Query()` which retrieves the RPC Client and makes an ABCI call to relay a query to a full-node. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/client/context.go#L20-L50 + +The `client.Context`'s primary role is to store data used during interactions with the end-user and provide methods to interact with this data - it is used before and after the query is processed by the full-node. Specifically, in handling `MyQuery`, the `client.Context` is utilized to encode the query parameters, retrieve the full-node, and write the output. Prior to being relayed to a full-node, the query needs to be encoded into a `[]byte` form, as full-nodes are application-agnostic and do not understand specific types. The full-node (RPC Client) itself is retrieved using the `client.Context`, which knows which node the user CLI is connected to. The query is relayed to this full-node to be processed. Finally, the `client.Context` contains a `Writer` to write output when the response is returned. These steps are further described in later sections. + +### Arguments and Route Creation + +At this point in the lifecycle, the user has created a CLI command with all of the data they wish to include in their query. A `client.Context` exists to assist in the rest of the `MyQuery`'s journey. Now, the next step is to parse the command or request, extract the arguments, and encode everything. These steps all happen on the user side within the interface they are interacting with. + +#### Encoding + +In our case (querying an address's delegations), `MyQuery` contains an [address](./accounts.md#addresses) `delegatorAddress` as its only argument. However, the request can only contain `[]byte`s, as it will be relayed to a consensus engine (e.g. Tendermint Core) of a full-node that has no inherent knowledge of the application types. Thus, the `codec` of `client.Context` is used to marshal the address. + +Here is what the code looks like for the CLI command: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/x/staking/client/cli/query.go#L324-L327 + +#### gRPC Query Client Creation + +The SDK leverages code generated from Protobuf services to make queries. The `staking` module's `MyQuery` service generates a `queryClient`, which the CLI will use to make queries. Here is the relevant code: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/x/staking/client/cli/query.go#L318-L342 + +Under the hood, the `client.Context` has a `Query()` function used to retrieve the pre-configured node and relay a query to it; the function takes the query fully-qualified service method name as path (in our case: `/cosmos.staking.v1beta1.Query/Delegations`), and arguments as parameters. It first retrieves the RPC Client (called the [**node**](../core/node.md)) configured by the user to relay this query to, and creates the `ABCIQueryOptions` (parameters formatted for the ABCI call). The node is then used to make the ABCI call, `ABCIQueryWithOptions()`. + +Here is what the code looks like: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/client/query.go#L65-L91 + +## RPC + +With a call to `ABCIQueryWithOptions()`, `MyQuery` is received by a [full-node](../core/encoding.md) which will then process the request. Note that, while the RPC is made to the consensus engine (e.g. Tendermint Core) of a full-node, queries are not part of consensus and will not be broadcasted to the rest of the network, as they do not require anything the network needs to agree upon. + +Read more about ABCI Clients and Tendermint RPC in the Tendermint documentation [here](https://tendermint.com/rpc). + +## Application Query Handling + +When a query is received by the full-node after it has been relayed from the underlying consensus engine, it is now being handled within an environment that understands application-specific types and has a copy of the state. [`baseapp`](../core/baseapp.md) implements the ABCI [`Query()`](../core/baseapp.md#query) function and handles gRPC queries. The query route is parsed, and it it matches the fully-qualified service method name of an existing service method (most likely in one of the modules), then `baseapp` will relay the request to the relevant module. + +Apart from gRPC routes, `baseapp` also handles four different types of queries: `app`, `store`, `p2p`, and `custom`. The first three types (`app`, `store`, `p2p`) are purely application-level and thus directly handled by `baseapp` or the stores, but the `custom` query type requires `baseapp` to route the query to a module's [legacy queriers](../building-modules/query-services.md#legacy-queriers). To learn more about these queries, please refer to [this guide](../core/grpc_rest.md#tendermint-rpc). + +Since `MyQuery` has a Protobuf fully-qualified service method name from the `staking` module (recall `/cosmos.staking.v1beta1.Query/Delegations`), `baseapp` first parses the path, then uses its own internal `GRPCQueryRouter` to retrieve the corresponding gRPC handler, and routes the query to the module. The gRPC handler is responsible for recognizing this query, retrieving the appropriate values from the application's stores, and returning a response. Read more about query services [here](../building-modules/query-services.md). + +Once a result is received from the querier, `baseapp` begins the process of returning a response to the user. + +## Response + +Since `Query()` is an ABCI function, `baseapp` returns the response as an [`abci.ResponseQuery`](https://tendermint.com/docs/spec/abci/abci.html#messages) type. The `client.Context` `Query()` routine receives the response and. + +### CLI Response + +The application [`codec`](../core/encoding.md) is used to unmarshal the response to a JSON and the `client.Context` prints the output to the command line, applying any configurations such as the output type (text, JSON or YAML). + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/client/context.go#L248-L283 + +And that's a wrap! The result of the query is outputted to the console by the CLI. + +## Next {hide} + +Read more about [accounts](./accounts.md). {hide} diff --git a/versioned_docs/version-0.45/develop/high-level-concepts/tx-lifecycle.md b/versioned_docs/version-0.45/develop/high-level-concepts/tx-lifecycle.md new file mode 100644 index 000000000..fa51eef1c --- /dev/null +++ b/versioned_docs/version-0.45/develop/high-level-concepts/tx-lifecycle.md @@ -0,0 +1,256 @@ + + +# Transaction Lifecycle + +This document describes the lifecycle of a transaction from creation to committed state changes. Transaction definition is described in a [different doc](../core/transactions.md). The transaction will be referred to as `Tx`. {synopsis} + +### Pre-requisite Readings + +- [Anatomy of an SDK Application](./app-anatomy.md) {prereq} + +## Creation + +### Transaction Creation + +One of the main application interfaces is the command-line interface. The transaction `Tx` can be created by the user inputting a command in the following format from the [command-line](../core/cli.md), providing the type of transaction in `[command]`, arguments in `[args]`, and configurations such as gas prices in `[flags]`: + +```bash +[appname] tx [command] [args] [flags] +``` + +This command will automatically **create** the transaction, **sign** it using the account's private key, and **broadcast** it to the specified peer node. + +There are several required and optional flags for transaction creation. The `--from` flag specifies which [account](./accounts.md) the transaction is originating from. For example, if the transaction is sending coins, the funds will be drawn from the specified `from` address. + +#### Gas and Fees + +Additionally, there are several [flags](../core/cli.md) users can use to indicate how much they are willing to pay in [fees](./gas-fees.md): + +- `--gas` refers to how much [gas](./gas-fees.md), which represents computational resources, `Tx` consumes. Gas is dependent on the transaction and is not precisely calculated until execution, but can be estimated by providing `auto` as the value for `--gas`. +- `--gas-adjustment` (optional) can be used to scale `gas` up in order to avoid underestimating. For example, users can specify their gas adjustment as 1.5 to use 1.5 times the estimated gas. +- `--gas-prices` specifies how much the user is willing pay per unit of gas, which can be one or multiple denominations of tokens. For example, `--gas-prices=0.025uatom, 0.025upho` means the user is willing to pay 0.025uatom AND 0.025upho per unit of gas. +- `--fees` specifies how much in fees the user is willing to pay in total. +- `--timeout-height` specifies a block timeout height to prevent the tx from being committed past a certain height. + +The ultimate value of the fees paid is equal to the gas multiplied by the gas prices. In other words, `fees = ceil(gas * gasPrices)`. Thus, since fees can be calculated using gas prices and vice versa, the users specify only one of the two. + +Later, validators decide whether or not to include the transaction in their block by comparing the given or calculated `gas-prices` to their local `min-gas-prices`. `Tx` will be rejected if its `gas-prices` is not high enough, so users are incentivized to pay more. + +#### CLI Example + +Users of application `app` can enter the following command into their CLI to generate a transaction to send 1000uatom from a `senderAddress` to a `recipientAddress`. It specifies how much gas they are willing to pay: an automatic estimate scaled up by 1.5 times, with a gas price of 0.025uatom per unit gas. + +```bash +appd tx send 1000uatom --from --gas auto --gas-adjustment 1.5 --gas-prices 0.025uatom +``` + +#### Other Transaction Creation Methods + +The command-line is an easy way to interact with an application, but `Tx` can also be created using a [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). + +## Addition to Mempool + +Each full-node (running Tendermint) that receives a `Tx` sends an [ABCI message](https://tendermint.com/docs/spec/abci/abci.html#messages), +`CheckTx`, to the application layer to check for validity, and receives an `abci.ResponseCheckTx`. If the `Tx` passes the checks, it is held in the nodes' +[**Mempool**](https://tendermint.com/docs/tendermint-core/mempool.html#mempool), an in-memory pool of transactions unique to each node) pending inclusion in a block - honest nodes will discard `Tx` if it is found to be invalid. Prior to consensus, nodes continuously check incoming transactions and gossip them to their peers. + +### Types of Checks + +The full-nodes perform stateless, then stateful checks on `Tx` during `CheckTx`, with the goal to +identify and reject an invalid transaction as early on as possible to avoid wasted computation. + +**_Stateless_** checks do not require nodes to access state - light clients or offline nodes can do +them - and are thus less computationally expensive. Stateless checks include making sure addresses +are not empty, enforcing nonnegative numbers, and other logic specified in the definitions. + +**_Stateful_** checks validate transactions and messages based on a committed state. Examples +include checking that the relevant values exist and are able to be transacted with, the address +has sufficient funds, and the sender is authorized or has the correct ownership to transact. +At any given moment, full-nodes typically have [multiple versions](../core/baseapp.md#volatile-states) +of the application's internal state for different purposes. For example, nodes will execute state +changes while in the process of verifying transactions, but still need a copy of the last committed +state in order to answer queries - they should not respond using state with uncommitted changes. + +In order to verify a `Tx`, full-nodes call `CheckTx`, which includes both _stateless_ and _stateful_ +checks. Further validation happens later in the [`DeliverTx`](#delivertx) stage. `CheckTx` goes +through several steps, beginning with decoding `Tx`. + +### Decoding + +When `Tx` is received by the application from the underlying consensus engine (e.g. Tendermint), it is still in its [encoded](../core/encoding.md) `[]byte` form and needs to be unmarshaled in order to be processed. Then, the [`runTx`](../core/baseapp.md#runtx-and-runmsgs) function is called to run in `runTxModeCheck` mode, meaning the function will run all checks but exit before executing messages and writing state changes. + +### ValidateBasic + +Messages ([`sdk.Msg`](../core/transactions.md#messages)) are extracted from transactions (`Tx`). The `ValidateBasic` method of the `sdk.Msg` interface implemented by the module developer is run for each transaction. +To discard obviously invalid messages, the BaseApp` type calls the `ValidateBasic` method very early in the processing of the message in the [`CheckTx`](../core/baseapp.md#checktx) and [`DeliverTx`](../core/baseapp.md#delivertx)) transactions. +`ValidateBasic` can include only **stateless** checks (the checks that do not require access to the state). + +#### Guideline + +Gas is not charged when `ValidateBasic` is executed so we recommend only performing all necessary stateless checks to enable middleware operations (for example, parsing the required signer accounts to validate a signature by a middleware) and stateless sanity checks not impacting performance of the CheckTx phase. +Other validation operations must be performed when [handling a message](../building-modules/msg-services#Validation) in a module Msg Server. + +Example, if the message is to send coins from one address to another, `ValidateBasic` likely checks for non-empty addresses and a non-negative coin amount, but does not require knowledge of state such as the account balance of an address. + +See also [Msg Service Validation](../building-modules/msg-services.md#Validation). + +### AnteHandler + +After the ValidateBasic checks, the `AnteHandler`s are run. Technically, they are optional, but in practice, they are very often present to perform signature verification, gas calculation, fee deduction and other core operations related to blockchain transactions. + +A copy of the cached context is provided to the `AnteHandler`, which performs limited checks specified for the transaction type. Using a copy allows the AnteHandler to do stateful checks for `Tx` without modifying the last committed state, and revert back to the original if the execution fails. + +For example, the [`auth`](https://github.com/cosmos/cosmos-sdk/tree/master/x/auth/spec) module `AnteHandler` checks and increments sequence numbers, checks signatures and account numbers, and deducts fees from the first signer of the transaction - all state changes are made using the `checkState`. + +### Gas + +The [`Context`](../core/context.md), which keeps a `GasMeter` that will track how much gas has been used during the execution of `Tx`, is initialized. The user-provided amount of gas for `Tx` is known as `GasWanted`. If `GasConsumed`, the amount of gas consumed so during execution, ever exceeds `GasWanted`, the execution will stop and the changes made to the cached copy of the state won't be committed. Otherwise, `CheckTx` sets `GasUsed` equal to `GasConsumed` and returns it in the result. After calculating the gas and fee values, validator-nodes check that the user-specified `gas-prices` is greater than their locally defined `min-gas-prices`. + +### Discard or Addition to Mempool + +If at any point during `CheckTx` the `Tx` fails, it is discarded and the transaction lifecycle ends +there. Otherwise, if it passes `CheckTx` successfully, the default protocol is to relay it to peer +nodes and add it to the Mempool so that the `Tx` becomes a candidate to be included in the next block. + +The **mempool** serves the purpose of keeping track of transactions seen by all full-nodes. +Full-nodes keep a **mempool cache** of the last `mempool.cache_size` transactions they have seen, as a first line of +defense to prevent replay attacks. Ideally, `mempool.cache_size` is large enough to encompass all +of the transactions in the full mempool. If the the mempool cache is too small to keep track of all +the transactions, `CheckTx` is responsible for identifying and rejecting replayed transactions. + +Currently existing preventative measures include fees and a `sequence` (nonce) counter to distinguish +replayed transactions from identical but valid ones. If an attacker tries to spam nodes with many +copies of a `Tx`, full-nodes keeping a mempool cache will reject identical copies instead of running +`CheckTx` on all of them. Even if the copies have incremented `sequence` numbers, attackers are +disincentivized by the need to pay fees. + +Validator nodes keep a mempool to prevent replay attacks, just as full-nodes do, but also use it as +a pool of unconfirmed transactions in preparation of block inclusion. Note that even if a `Tx` +passes all checks at this stage, it is still possible to be found invalid later on, because +`CheckTx` does not fully validate the transaction (i.e. it does not actually execute the messages). + +## Inclusion in a Block + +Consensus, the process through which validator nodes come to agreement on which transactions to +accept, happens in **rounds**. Each round begins with a proposer creating a block of the most +recent transactions and ends with **validators**, special full-nodes with voting power responsible +for consensus, agreeing to accept the block or go with a `nil` block instead. Validator nodes +execute the consensus algorithm, such as [Tendermint BFT](https://tendermint.com/docs/spec/consensus/consensus.html#terms), +confirming the transactions using ABCI requests to the application, in order to come to this agreement. + +The first step of consensus is the **block proposal**. One proposer amongst the validators is chosen +by the consensus algorithm to create and propose a block - in order for a `Tx` to be included, it +must be in this proposer's mempool. + +## State Changes + +The next step of consensus is to execute the transactions to fully validate them. All full-nodes +that receive a block proposal from the correct proposer execute the transactions by calling the ABCI functions +[`BeginBlock`](./app-anatomy.md#beginblocker-and-endblocker), `DeliverTx` for each transaction, +and [`EndBlock`](./app-anatomy.md#beginblocker-and-endblocker). While each full-node runs everything +locally, this process yields a single, unambiguous result, since the messages' state transitions are deterministic and transactions are +explicitly ordered in the block proposal. + +``` + ----------------------- + |Receive Block Proposal| + ----------------------- + | + v + ----------------------- + | BeginBlock | + ----------------------- + | + v + ----------------------- + | DeliverTx(tx0) | + | DeliverTx(tx1) | + | DeliverTx(tx2) | + | DeliverTx(tx3) | + | . | + | . | + | . | + ----------------------- + | + v + ----------------------- + | EndBlock | + ----------------------- + | + v + ----------------------- + | Consensus | + ----------------------- + | + v + ----------------------- + | Commit | + ----------------------- +``` + +### DeliverTx + +The `DeliverTx` ABCI function defined in [`BaseApp`](../core/baseapp.md) does the bulk of the +state transitions: it is run for each transaction in the block in sequential order as committed +to during consensus. Under the hood, `DeliverTx` is almost identical to `CheckTx` but calls the +[`runTx`](../core/baseapp.md#runtx) function in deliver mode instead of check mode. +Instead of using their `checkState`, full-nodes use `deliverState`: + +- **Decoding:** Since `DeliverTx` is an ABCI call, `Tx` is received in the encoded `[]byte` form. + Nodes first unmarshal the transaction, using the [`TxConfig`](./app-anatomy#register-codec) defined in the app, then call `runTx` in `runTxModeDeliver`, which is very similar to `CheckTx` but also executes and writes state changes. + +- **Checks:** Full-nodes call `validateBasicMsgs` and the `AnteHandler` again. This second check + happens because they may not have seen the same transactions during the addition to Mempool stage\ + and a malicious proposer may have included invalid ones. One difference here is that the + `AnteHandler` will not compare `gas-prices` to the node's `min-gas-prices` since that value is local + to each node - differing values across nodes would yield nondeterministic results. + +- **`MsgServiceRouter`:** While `CheckTx` would have exited, `DeliverTx` continues to run + [`runMsgs`](../core/baseapp.md#runtx-and-runmsgs) to fully execute each `Msg` within the transaction. + Since the transaction may have messages from different modules, `BaseApp` needs to know which module + to find the appropriate handler. This is achieved using `BaseApp`'s `MsgServiceRouter` so that it can be processed by the module's 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} diff --git a/versioned_docs/version-0.45/develop/intro/README.md b/versioned_docs/version-0.45/develop/intro/README.md new file mode 100644 index 000000000..1b3365ba2 --- /dev/null +++ b/versioned_docs/version-0.45/develop/intro/README.md @@ -0,0 +1,16 @@ + + +# Introduction + +This folder contains introduction material on the Cosmos SDK. + +1. [Overview](./overview.md) +2. [Application-Specific Blockchains](./why-app-specific.md) +3. [Architecture of an SDK Application](./sdk-app-architecture.md) +4. [Cosmos SDK Design Overview](./sdk-design.md) + +After reading the introduction material, head over to the [basics](../basics/README.md) to learn more. diff --git a/versioned_docs/version-0.45/develop/intro/overview.md b/versioned_docs/version-0.45/develop/intro/overview.md new file mode 100644 index 000000000..4d0212719 --- /dev/null +++ b/versioned_docs/version-0.45/develop/intro/overview.md @@ -0,0 +1,37 @@ + + +# High-level Overview + +## What is the SDK? + +The [Cosmos-SDK](https://github.com/cosmos/cosmos-sdk) is an open-source framework for building multi-asset public Proof-of-Stake (PoS) blockchains, like the Cosmos Hub, as well as permissioned Proof-Of-Authority (PoA) blockchains. Blockchains built with the Cosmos SDK are generally referred to as **application-specific blockchains**. + +The goal of the Cosmos SDK is to allow developers to easily create custom blockchains from scratch that can natively interoperate with other blockchains. We envision the SDK as the npm-like framework to build secure blockchain applications on top of [Tendermint](https://github.com/tendermint/tendermint). SDK-based blockchains are built out of composable [modules](../building-modules/intro.md), most of which are open source and readily available for any developers to use. Anyone can create a module for the Cosmos-SDK, and integrating already-built modules is as simple as importing them into your blockchain application. What's more, the Cosmos SDK is a capabilities-based system, which allows developers to better reason about the security of interactions between modules. For a deeper look at capabilities, jump to [this section](../core/ocap.md). + +## What are Application-Specific Blockchains? + +One development paradigm in the blockchain world today is that of virtual-machine blockchains like Ethereum, where development generally revolves around building a decentralised applications on top of an existing blockchain as a set of smart contracts. While smart contracts can be very good for some use cases like single-use applications (e.g. ICOs), they often fall short for building complex decentralised platforms. More generally, smart contracts can be limiting in terms of flexibility, sovereignty and performance. + +Application-specific blockchains offer a radically different development paradigm than virtual-machine blockchains. An application-specific blockchain is a blockchain customized to operate a single application: developers have all the freedom to make the design decisions required for the application to run optimally. They can also provide better sovereignty, security and performance. + +Learn more about [application-specific blockchains](./why-app-specific.md). + +## Why the Cosmos SDK? + +The Cosmos SDK is the most advanced framework for building custom application-specific blockchains today. Here are a few reasons why you might want to consider building your decentralised application with the Cosmos SDK: + +- The default consensus engine available within the SDK is [Tendermint Core](https://github.com/tendermint/tendermint). Tendermint is the most (and only) mature BFT consensus engine in existence. It is widely used across the industry and is considered the gold standard consensus engine for building Proof-of-Stake systems. +- The SDK is open source and designed to make it easy to build blockchains out of composable [modules](../../x/). As the ecosystem of open source SDK modules grows, it will become increasingly easier to build complex decentralised platforms with it. +- The SDK is inspired by capabilities-based security, and informed by years of wrestling with blockchain state-machines. This makes the Cosmos SDK a very secure environment to build blockchains. +- Most importantly, the Cosmos SDK has already been used to build many application-specific blockchains that are already in production. Among others, we can cite [Cosmos Hub](https://hub.cosmos.network), [IRIS Hub](https://irisnet.org), [Binance Chain](https://docs.binance.org/), [Terra](https://terra.money/) or [Kava](https://www.kava.io/). [Many more](https://cosmos.network/ecosystem) are building on the Cosmos SDK. + +## Getting started with the Cosmos SDK + +- Learn more about the [architecture of an SDK application](./sdk-app-architecture.md) +- Learn how to build an application-specific blockchain from scratch with the [SDK Tutorial](https://cosmos.network/docs/tutorial) + +## Next {hide} + +Learn about [application-specific blockchains](./why-app-specific.md) {hide} diff --git a/versioned_docs/version-0.45/develop/intro/sdk-app-architecture.md b/versioned_docs/version-0.45/develop/intro/sdk-app-architecture.md new file mode 100644 index 000000000..1b3e40e94 --- /dev/null +++ b/versioned_docs/version-0.45/develop/intro/sdk-app-architecture.md @@ -0,0 +1,97 @@ + + +# Blockchain Architecture + +## State machine + +At its core, a blockchain is a [replicated deterministic state machine](https://en.wikipedia.org/wiki/State_machine_replication). + +A state machine is a computer science concept whereby a machine can have multiple states, but only one at any given time. There is a `state`, which describes the current state of the system, and `transactions`, that trigger state transitions. + +Given a state S and a transaction T, the state machine will return a new state S'. + +``` ++--------+ +--------+ +| | | | +| S +---------------->+ S' | +| | apply(T) | | ++--------+ +--------+ +``` + +In practice, the transactions are bundled in blocks to make the process more efficient. Given a state S and a block of transactions B, the state machine will return a new state S'. + +``` ++--------+ +--------+ +| | | | +| S +----------------------------> | S' | +| | For each T in B: apply(T) | | ++--------+ +--------+ +``` + +In a blockchain context, the state machine is deterministic. This means that if a node is started at a given state and replays the same sequence of transactions, it will always end up with the same final state. + +The Cosmos SDK gives developers maximum flexibility to define the state of their application, transaction types and state transition functions. The process of building state-machines with the SDK will be described more in depth in the following sections. But first, let us see how the state-machine is replicated using **Tendermint**. + +## Tendermint + +Thanks to the Cosmos SDK, developers just have to define the state machine, and [*Tendermint*](https://tendermint.com/docs/introduction/what-is-tendermint.html) will handle replication over the network for them. + +``` + ^ +-------------------------------+ ^ + | | | | Built with Cosmos SDK + | | State-machine = Application | | + | | | v + | +-------------------------------+ + | | | ^ +Blockchain node | | Consensus | | + | | | | + | +-------------------------------+ | Tendermint Core + | | | | + | | Networking | | + | | | | + v +-------------------------------+ v +``` + +[Tendermint](https://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. + +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. + +## 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. + +``` + +---------------------+ + | | + | Application | + | | + +--------+---+--------+ + ^ | + | | ABCI + | v + +--------+---+--------+ + | | + | | + | Tendermint | + | | + | | + +---------------------+ +``` + +Note that **Tendermint only handles transaction bytes**. It has no knowledge of what these bytes mean. All Tendermint does is order these transaction bytes deterministically. Tendermint passes the bytes to the application via the ABCI, and expects a return code to inform it if the messages contained in the transactions were successfully processed or not. + +Here are the most important messages of the ABCI: + +- `CheckTx`: When a transaction is received by Tendermint Core, it is passed to the application to check if a few basic requirements are met. `CheckTx` is used to protect the mempool of full-nodes against spam transactions. A special handler called the [`AnteHandler`](../basics/gas-fees.md#antehandler) is used to execute a series of validation steps such as checking for sufficient fees and validating the signatures. If the checks are valid, the transaction is added to the [mempool](https://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. + +Find a more detailed view of the ABCI methods from the [Tendermint docs](https://docs.tendermint.com/v0.34/spec/abci/abci.html#overview). + +Any application built on Tendermint needs to implement the ABCI interface in order to communicate with the underlying local Tendermint engine. Fortunately, you do not have to implement the ABCI interface. The Cosmos SDK provides a boilerplate implementation of it in the form of [baseapp](./sdk-design.md#baseapp). + +## Next {hide} + +Read about the [high-level design principles of the SDK](./sdk-design.md) {hide} diff --git a/versioned_docs/version-0.45/develop/intro/sdk-design.md b/versioned_docs/version-0.45/develop/intro/sdk-design.md new file mode 100644 index 000000000..5c8c26965 --- /dev/null +++ b/versioned_docs/version-0.45/develop/intro/sdk-design.md @@ -0,0 +1,95 @@ + + +# Main Components of the Cosmos SDK + +The Cosmos SDK is a framework that facilitates the development of secure state-machines on top of Tendermint. At its core, the SDK is a boilerplate implementation of the [ABCI](./sdk-app-architecture.md#abci) in Golang. It comes with a [`multistore`](../core/store.md#multistore) to persist data and a [`router`](../core/baseapp.md#routing) to handle transactions. + +Here is a simplified view of how transactions are handled by an application built on top of the Cosmos SDK when transferred from Tendermint via `DeliverTx`: + +1. Decode `transactions` received from the Tendermint consensus engine (remember that Tendermint only deals with `[]bytes`). +2. Extract `messages` from `transactions` and do basic sanity checks. +3. Route each message to the appropriate module so that it can be processed. +4. Commit state changes. + +## `baseapp` + +`baseapp` is the boilerplate implementation of a Cosmos SDK application. It comes with an implementation of the ABCI to handle the 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 SDK application tutorial: + ++++ https://github.com/cosmos/sdk-tutorials/blob/c6754a1e313eb1ed973c5c91dcc606f2fd288811/app.go#L72-L92 + +The goal of `baseapp` is to provide a secure interface between the store and the extensible state machine while defining as little about the state machine as possible (staying true to the ABCI). + +For more on `baseapp`, please click [here](../core/baseapp.md). + +## Multistore + +The Cosmos SDK provides a [`multistore`](../core/store.md#multistore) for persisting state. The multistore allows developers to declare any number of [`KVStores`](../core/store.md#base-layer-kvstores). These `KVStores` only accept the `[]byte` type as value and therefore any custom structure needs to be marshalled using [a codec](../core/encoding.md) before being stored. + +The multistore abstraction is used to divide the state in distinct compartments, each managed by its own module. For more on the multistore, click [here](../core/store.md#multistore) + +## Modules + +The power of the Cosmos SDK lies in its modularity. SDK applications are built by aggregating a collection of interoperable modules. Each module defines a subset of the state and contains its own message/transaction processor, while the SDK is responsible for routing each message to its respective module. + +Here is a simplified view of how a transaction is processed by the application of each full-node when it is received in a valid block: + +``` + + + | + | Transaction relayed from the full-node's + | Tendermint engine to the node's application + | via DeliverTx + | + | + +---------------------v--------------------------+ + | APPLICATION | + | | + | Using baseapp's methods: Decode the Tx, | + | extract and route the message(s) | + | | + +---------------------+--------------------------+ + | + | + | + +---------------------------+ + | + | + | Message routed to + | the correct module + | to be processed + | + | ++----------------+ +---------------+ +----------------+ +------v----------+ +| | | | | | | | +| AUTH MODULE | | BANK MODULE | | STAKING MODULE | | GOV MODULE | +| | | | | | | | +| | | | | | | Handles message,| +| | | | | | | Updates state | +| | | | | | | | ++----------------+ +---------------+ +----------------+ +------+----------+ + | + | + | + | + +--------------------------+ + | + | Return result to Tendermint + | (0=Ok, 1=Err) + v +``` + +Each module can be seen as a little state-machine. Developers need to define the subset of the state handled by the module, as well as custom message types that modify the state (*Note:* `messages` are extracted from `transactions` by `baseapp`). In general, each module declares its own `KVStore` in the `multistore` to persist the subset of the state it defines. Most developers will need to access other 3rd party modules when building their own modules. Given that the Cosmos-SDK is an open framework, some of the modules may be malicious, which means there is a need for security principles to reason about inter-module interactions. These principles are based on [object-capabilities](../core/ocap.md). In practice, this means that instead of having each module keep an access control list for other modules, each module implements special objects called `keepers` that can be passed to other modules to grant a pre-defined set of capabilities. + +SDK modules are defined in the `x/` folder of the SDK. Some core modules include: + +- `x/auth`: Used to manage accounts and signatures. +- `x/bank`: Used to enable tokens and token transfers. +- `x/staking` + `x/slashing`: Used to build Proof-Of-Stake blockchains. + +In addition to the already existing modules in `x/`, that anyone can use in their app, the SDK lets you build your own custom modules. You can check an [example of that in the tutorial](https://cosmos.network/docs/tutorial/keeper.html). + +## Next {hide} + +Learn more about the [anatomy of an SDK application](../basics/app-anatomy.md) {hide} diff --git a/versioned_docs/version-0.45/develop/intro/why-app-specific.md b/versioned_docs/version-0.45/develop/intro/why-app-specific.md new file mode 100644 index 000000000..f7c5f72d7 --- /dev/null +++ b/versioned_docs/version-0.45/develop/intro/why-app-specific.md @@ -0,0 +1,81 @@ + + +# Application-Specific Blockchains + +This document explains what application-specific blockchains are, and why developers would want to build one as opposed to writing Smart Contracts. {synopsis} + +## What are application-specific blockchains? + +Application-specific blockchains are blockchains customized to operate a single application. Instead of building a decentralised application on top of an underlying blockchain like Ethereum, developers build their own blockchain from the ground up. This means building a full-node client, a light-client, and all the necessary interfaces (CLI, REST, ...) to interract with the nodes. + +``` + ^ +-------------------------------+ ^ + | | | | Built with Cosmos SDK + | | State-machine = Application | | + | | | v + | +-------------------------------+ + | | | ^ +Blockchain node | | Consensus | | + | | | | + | +-------------------------------+ | Tendermint Core + | | | | + | | Networking | | + | | | | + v +-------------------------------+ v +``` + +## What are the shortcomings of Smart Contracts? + +Virtual-machine blockchains like Ethereum addressed the demand for more programmability back in 2014. At the time, the options available for building decentralised applications were quite limited. Most developers would build on top of the complex and limited Bitcoin scripting language, or fork the Bitcoin codebase which was hard to work with and customize. + +Virtual-machine blockchains came in with a new value proposition. Their state-machine incorporates a virtual-machine that is able to interpret turing-complete programs called Smart Contracts. These Smart Contracts are very good for use cases like one-time events (e.g. ICOs), but they can fall short for building complex decentralised platforms. Here is why: + +- Smart Contracts are generally developed with specific programming languages that can be interpreted by the underlying virtual-machine. These programming languages are often immature and inherently limited by the constraints of the virtual-machine itself. For example, the Ethereum Virtual Machine does not allow developers to implement automatic execution of code. Developers are also limited to the account-based system of the EVM, and they can only choose from a limited set of functions for their cryptographic operations. These are examples, but they hint at the lack of **flexibility** that a smart contract environment often entails. +- Smart Contracts are all run by the same virtual machine. This means that they compete for resources, which can severly restrain **performance**. And even if the state-machine were to be split in multiple subsets (e.g. via sharding), Smart Contracts would still need to be interpeted by a virtual machine, which would limit performance compared to a native application implemented at state-machine level (our benchmarks show an improvement on the order of x10 in performance when the virtual-machine is removed). +- Another issue with the fact that Smart Contracts share the same underlying environment is the resulting limitation in **sovereignty**. A decentralised application is an ecosystem that involves multiple players. If the application is built on a general-purpose virtual-machine blockchain, stakeholders have very limited sovereignty over their application, and are ultimately superseded by the governance of the underlying blockchain. If there is a bug in the application, very little can be done about it. + +Application-Specific Blockchains are designed to address these shortcomings. + +## Application-Specific Blockchains Benefits + +### Flexibility + +Application-specific blockchains give maximum flexibility to developers: + +- In Cosmos blockchains, the state-machine is typically connected to the underlying consensus engine via an interface called the [ABCI](https://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. + +- Developers can choose among multiple frameworks to build their state-machine. The most widely used today is the Cosmos SDK, but others exist (e.g. [Lotion](https://github.com/nomic-io/lotion), [Weave](https://github.com/iov-one/weave), ...). The choice will most of the time be done based on the programming language they want to use (Cosmos SDK and Weave are in Golang, Lotion is in Javascript, ...). +- The ABCI also allows developers to swap the consensus engine of their application-specific blockchain. Today, only Tendermint is production-ready, but in the future other consensus engines are expected to emerge. +- Even when they settle for a framework and consensus engine, developers still have the freedom to tweak them if they don't perfectly match their requirements in their pristine forms. +- Developers are free to explore the full spectrum of tradeoffs (e.g. number of validators vs transaction throughput, safety vs availability in asynchrony, ...) and design choices (DB or IAVL tree for storage, UTXO or account model, ...). +- Developers can implement automatic execution of code. In the Cosmos SDK, logic can be automatically triggered at the beginning and the end of each block. They are also free to choose the cryptographic library used in their application, as opposed to being constrained by what is made available by the underlying environment in the case of virtual-machine blockchains. + +The list above contains a few examples that show how much flexibility application-specific blockchains give to developers. The goal of Cosmos and the Cosmos SDK is to make developer tooling as generic and composable as possible, so that each part of the stack can be forked, tweaked and improved without losing compatibility. As the community grows, more alternatives for each of the core building blocks will emerge, giving more options to developers. + +### Performance + +Decentralised applications built with Smart Contracts are inherently capped in performance by the underlying environment. For a decentralised application to optimise performance, it needs to be built as an application-specific blockchains. Next are some of the benefits an application-specific 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. + +### Security + +Security is hard to quantify, and greatly varies from platform to platform. That said here are some important benefits an application-specific blockchain can bring in terms of security: + +- Developers can choose proven programming languages like Golang when building their application-specific blockchains, as opposed to smart contract programming languages that are often more immature. +- Developers are not constrained by the cryptographic functions made available by the underlying virtual-machines. They can use their own custom cryptography, and rely on well-audited crypto libraries. +- Developers do not have to worry about potential bugs or exploitable mechanisms in the underlying virtual-machine, making it easier to reason about the security of the application. + +### Sovereignty + +One of the major benefits of application-specific blockchains is sovereignty. A decentralised application is an ecosystem that involves many actors: users, developers, third-party services, and more. When developers build on virtual-machine blockchain where many decentralised applications coexist, the community of the application is different than the community of the underlying blockchain, and the latter supersedes the former in the governance process. If there is a bug or if a new feature is needed, stakeholders of the application have very little leeway to upgrade the code. If the community of the underlying blockchain refuses to act, nothing can happen. + +The fundamental issue here is that the governance of the application and the governance of the network are not aligned. This issue is solved by application-specific blockchains. Because application-specific blockchains specialize to operate a single application, stakeholders the application has full control over the entire chain. This ensures the community will not be stuck if a bug is discovered, and that it has the entire freedom to choose how it is going to evolve. + +## Next {hide} + +Learn more about the [high-level architecture](./sdk-app-architecture.md) of an SDK application {hide} diff --git a/versioned_docs/version-0.45/integrate/architecture/PROCESS.md b/versioned_docs/version-0.45/integrate/architecture/PROCESS.md new file mode 100644 index 000000000..07008b968 --- /dev/null +++ b/versioned_docs/version-0.45/integrate/architecture/PROCESS.md @@ -0,0 +1,56 @@ +# ADR Creation Process + +1. Copy the `adr-template.md` file. Use the following filename pattern: `adr-next_number-title.md` +2. Create a draft Pull Request if you want to get an early feedback. +3. Make sure the context and a solution is clear and well documented. +4. Add an entry to a list in the [README](./README.md) file. +5. Create a Pull Request to propose a new ADR. + +## ADR life cycle + +ADR creation is an **iterative** process. Instead of trying to solve all decisions in a single ADR pull request, we MUST firstly understand the problem and collect feedback through a GitHub Issue. + +1. Every proposal SHOULD start with a new GitHub Issue or be a result of existing Issues. The Issue should contain just a brief proposal summary. + +2. Once the motivation is validated, a GitHub Pull Request (PR) is created with a new document based on the `adr-template.md`. + +3. An ADR doesn't have to arrive to `master` with an _accepted_ status in a single PR. If the motivation is clear and the solution is sound, we SHOULD be able to merge it and keep a _proposed_ status. It's preferable to have an iterative approach rather than long, not merged Pull Requests. + +4. If a _proposed_ ADR is merged, then it should clearly document outstanding issues either in ADR document notes or in a GitHub Issue. + +5. The PR SHOULD always be merged. In the case of a faulty ADR, we still prefer to merge it with a _rejected_ status. The only time the ADR SHOULD NOT be merged is if the author abandons it. + +6. Merged ADRs SHOULD NOT be pruned. + +### ADR status + +Status has two components: + +``` +{CONSENSUS STATUS} {IMPLEMENTATION STATUS} +``` + +IMPLEMENTATION STATUS is either `Implemented` or `Not Implemented`. + +#### Consensus Status + +``` +DRAFT -> PROPOSED -> LAST CALL yyyy-mm-dd -> ACCEPTED | REJECTED -> SUPERSEEDED by ADR-xxx + \ | + \ | + v v + ABANDONED +``` + ++ `DRAFT`: [optional] an ADR which is work in progress, not being ready for a general review. This is to present an early work and get an early feedback in a Draft Pull Request form. ++ `PROPOSED`: an ADR covering a full solution architecture and still in the review - project stakeholders haven't reached an agreed yet. ++ `LAST CALL `: [optional] clear notify that we are close to accept updates. Changing a status to `LAST CALL` means that social consensus (of Cosmos SDK maintainers) has been reached and we still want to give it a time to let the community react or analyze. ++ `ACCEPTED`: ADR which will represent a currently implemented or to be implemented architecture design. ++ `REJECTED`: ADR can go from PROPOSED or ACCEPTED to rejected if the consensus among project stakeholders will decide so. ++ `SUPERSEEDED by ADR-xxx`: ADR which has been superseded by a new ADR. ++ `ABANDONED`: the ADR is no longer pursued by the original authors. + +## Language used in ADR + ++ The context/background should be written in the present tense. ++ Avoid using a first, personal form. diff --git a/versioned_docs/version-0.45/integrate/architecture/README.md b/versioned_docs/version-0.45/integrate/architecture/README.md new file mode 100644 index 000000000..5455df9f8 --- /dev/null +++ b/versioned_docs/version-0.45/integrate/architecture/README.md @@ -0,0 +1,79 @@ +--- +order: false +parent: + order: false +--- + +# Architecture Decision Records (ADR) + +This is a location to record all high-level architecture decisions in the Cosmos-SDK. + +An Architectural Decision (**AD**) is a software design choice that addresses a functional or non-functional requirement that is architecturally significant. +An Architecturally Significant Requirement (**ASR**) is a requirement that has a measurable effect on a software system’s architecture and quality. +An Architectural Decision Record (**ADR**) captures a single AD, such as often done when writing personal notes or meeting minutes; the collection of ADRs created and maintained in a project constitute its decision log. All these are within the topic of Architectural Knowledge Management (AKM). + +You can read more about the ADR concept in this [blog post](https://product.reverb.com/documenting-architecture-decisions-the-reverb-way-a3563bb24bd0#.78xhdix6t). + +## Rationale + +ADRs are intended to be the primary mechanism for proposing new feature designs and new processes, for collecting community input on an issue, and for documenting the design decisions. +An ADR should provide: + +- Context on the relevant goals and the current state +- Proposed changes to achieve the goals +- Summary of pros and cons +- References +- Changelog + +Note the distinction between an ADR and a spec. The ADR provides the context, intuition, reasoning, and +justification for a change in architecture, or for the architecture of something +new. The spec is much more compressed and streamlined summary of everything as +it stands today. + +If recorded decisions turned out to be lacking, convene a discussion, record the new decisions here, and then modify the code to match. + +## Creating new ADR + +Read about the [PROCESS](./PROCESS.md). + +#### Use RFC 2119 Keywords + +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 Table of Contents + +### 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) + +### 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) diff --git a/versioned_docs/version-0.45/integrate/architecture/adr-002-docs-structure.md b/versioned_docs/version-0.45/integrate/architecture/adr-002-docs-structure.md new file mode 100644 index 000000000..1c8201890 --- /dev/null +++ b/versioned_docs/version-0.45/integrate/architecture/adr-002-docs-structure.md @@ -0,0 +1,86 @@ +# ADR 002: SDK Documentation Structure + +## Context + +There is a need for a scalable structure of the SDK documentation. Current documentation includes a lot of non-related SDK material, is difficult to maintain and hard to follow as a user. + +Ideally, we would have: + +- All docs related to dev frameworks or tools live in their respective github repos (sdk repo would contain sdk docs, hub repo would contain hub docs, lotion repo would contain lotion docs, etc.) +- All other docs (faqs, whitepaper, high-level material about Cosmos) would live on the website. + +## Decision + +Re-structure the `/docs` folder of the SDK github repo as follows: + +``` +docs/ +├── README +├── intro/ +├── concepts/ +│ ├── baseapp +│ ├── types +│ ├── store +│ ├── server +│ ├── modules/ +│ │ ├── keeper +│ │ ├── handler +│ │ ├── cli +│ ├── gas +│ └── commands +├── clients/ +│ ├── lite/ +│ ├── service-providers +├── modules/ +├── spec/ +├── translations/ +└── architecture/ +``` + +The files in each sub-folders do not matter and will likely change. What matters is the sectioning: + +- `README`: Landing page of the docs. +- `intro`: Introductory material. Goal is to have a short explainer of the SDK and then channel people to the resource they need. The [sdk-tutorial](https://github.com/cosmos/sdk-application-tutorial/) will be highlighted, as well as the `godocs`. +- `concepts`: Contains high-level explanations of the abstractions of the SDK. It does not contain specific code implementation and does not need to be updated often. **It is not an API specification of the interfaces**. API spec is the `godoc`. +- `clients`: Contains specs and info about the various SDK clients. +- `spec`: Contains specs of modules, and others. +- `modules`: Contains links to `godocs` and the spec of the modules. +- `architecture`: Contains architecture-related docs like the present one. +- `translations`: Contains different translations of the documentation. + +Website docs sidebar will only include the following sections: + +- `README` +- `intro` +- `concepts` +- `clients` + +`architecture` need not be displayed on the website. + +## Status + +Accepted + +## Consequences + +### Positive + +- Much clearer organisation of the SDK docs. +- The `/docs` folder now only contains SDK and gaia related material. Later, it will only contain SDK related material. +- Developers only have to update `/docs` folder when they open a PR (and not `/examples` for example). +- Easier for developers to find what they need to update in the docs thanks to reworked architecture. +- Cleaner vuepress build for website docs. +- Will help build an executable doc (cf https://github.com/cosmos/cosmos-sdk/issues/2611) + +### Neutral + +- We need to move a bunch of deprecated stuff to `/_attic` folder. +- We need to integrate content in `docs/sdk/docs/core` in `concepts`. +- We need to move all the content that currently lives in `docs` and does not fit in new structure (like `lotion`, intro material, whitepaper) to the website repository. +- Update `DOCS_README.md` + +## References + +- https://github.com/cosmos/cosmos-sdk/issues/1460 +- https://github.com/cosmos/cosmos-sdk/pull/2695 +- https://github.com/cosmos/cosmos-sdk/issues/2611 diff --git a/versioned_docs/version-0.45/integrate/architecture/adr-003-dynamic-capability-store.md b/versioned_docs/version-0.45/integrate/architecture/adr-003-dynamic-capability-store.md new file mode 100644 index 000000000..3f5c9387c --- /dev/null +++ b/versioned_docs/version-0.45/integrate/architecture/adr-003-dynamic-capability-store.md @@ -0,0 +1,344 @@ +# ADR 3: Dynamic Capability Store + +## Changelog + +- 12 December 2019: Initial version +- 02 April 2020: Memory Store Revisions + +## Context + +Full implementation of the [IBC specification](https://github.com/cosmos/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. + +At present, the Cosmos SDK does not have the ability to do this. Object-capability keys are currently pointers (memory addresses) of `StoreKey` structs created at application initialisation in `app.go` ([example](https://github.com/cosmos/gaia/blob/dcbddd9f04b3086c0ad07ee65de16e7adedc7da4/app/app.go#L132)) +and passed to Keepers as fixed arguments ([example](https://github.com/cosmos/gaia/blob/dcbddd9f04b3086c0ad07ee65de16e7adedc7da4/app/app.go#L160)). Keepers cannot create or store capability keys during transaction execution — although they could call `NewKVStoreKey` and take the memory address +of the returned struct, storing this in the Merklised store would result in a consensus fault, since the memory address will be different on each machine (this is intentional — were this not the case, the keys would be predictable and couldn't serve as object capabilities). + +Keepers need a way to keep a private map of store keys which can be altered during transaction execution, along with a suitable mechanism for regenerating the unique memory addresses (capability keys) in this map whenever the application is started or restarted, along with a mechanism to revert capability creation on tx failure. +This ADR proposes such an interface & mechanism. + +## Decision + +The SDK will include a new `CapabilityKeeper` abstraction, which is responsible for provisioning, +tracking, and authenticating capabilities at runtime. During application initialisation in `app.go`, +the `CapabilityKeeper` will be hooked up to modules through unique function references +(by calling `ScopeToModule`, defined below) so that it can identify the calling module when later +invoked. + +When the initial state is loaded from disk, the `CapabilityKeeper`'s `Initialise` function will create +new capability keys for all previously allocated capability identifiers (allocated during execution of +past transactions and assigned to particular modes), and keep them in a memory-only store while the +chain is running. + +The `CapabilityKeeper` will include a persistent `KVStore`, a `MemoryStore`, and an in-memory map. +The persistent `KVStore` tracks which capability is owned by which modules. +The `MemoryStore` stores a forward mapping that map from module name, capability tuples to capability names and +a reverse mapping that map from module name, capability name to the capability index. +Since we cannot marshal the capability into a `KVStore` and unmarshal without changing the memory location of the capability, +the reverse mapping in the KVStore will simply map to an index. This index can then be used as a key in the ephemeral +go-map to retrieve the capability at the original memory location. + +The `CapabilityKeeper` will define the following types & functions: + +The `Capability` is similar to `StoreKey`, but has a globally unique `Index()` instead of +a name. A `String()` method is provided for debugging. + +A `Capability` is simply a struct, the address of which is taken for the actual capability. + +```golang +type Capability struct { + index uint64 +} +``` + +A `CapabilityKeeper` contains a persistent store key, memory store key, and mapping of allocated module names. + +```golang +type CapabilityKeeper struct { + persistentKey StoreKey + memKey StoreKey + capMap map[uint64]*Capability + moduleNames map[string]interface{} + sealed bool +} +``` + +The `CapabilityKeeper` provides the ability to create *scoped* sub-keepers which are tied to a +particular module name. These `ScopedCapabilityKeeper`s must be created at application initialisation +and passed to modules, which can then use them to claim capabilities they receive and retrieve +capabilities which they own by name, in addition to creating new capabilities & authenticating capabilities +passed by other modules. + +```golang +type ScopedCapabilityKeeper struct { + persistentKey StoreKey + memKey StoreKey + capMap map[uint64]*Capability + moduleName string +} +``` + +`ScopeToModule` is used to create a scoped sub-keeper with a particular name, which must be unique. +It MUST be called before `InitialiseAndSeal`. + +```golang +func (ck CapabilityKeeper) ScopeToModule(moduleName string) ScopedCapabilityKeeper { + if k.sealed { + panic("cannot scope to module via a sealed capability keeper") + } + + if _, ok := k.scopedModules[moduleName]; ok { + panic(fmt.Sprintf("cannot create multiple scoped keepers for the same module name: %s", moduleName)) + } + + k.scopedModules[moduleName] = struct{}{} + + return ScopedKeeper{ + cdc: k.cdc, + storeKey: k.storeKey, + memKey: k.memKey, + capMap: k.capMap, + module: moduleName, + } +} +``` + +`InitialiseAndSeal` MUST be called exactly once, after loading the initial state and creating all +necessary `ScopedCapabilityKeeper`s, in order to populate the memory store with newly-created +capability keys in accordance with the keys previously claimed by particular modules and prevent the +creation of any new `ScopedCapabilityKeeper`s. + +```golang +func (ck CapabilityKeeper) InitialiseAndSeal(ctx Context) { + if ck.sealed { + panic("capability keeper is sealed") + } + + persistentStore := ctx.KVStore(ck.persistentKey) + map := ctx.KVStore(ck.memKey) + + // initialise memory store for all names in persistent store + for index, value := range persistentStore.Iter() { + capability = &CapabilityKey{index: index} + + for moduleAndCapability := range value { + moduleName, capabilityName := moduleAndCapability.Split("/") + memStore.Set(moduleName + "/fwd/" + capability, capabilityName) + memStore.Set(moduleName + "/rev/" + capabilityName, index) + + ck.capMap[index] = capability + } + } + + ck.sealed = true +} +``` + +`NewCapability` can be called by any module to create a new unique, unforgeable object-capability +reference. The newly created capability is automatically persisted; the calling module need not +call `ClaimCapability`. + +```golang +func (sck ScopedCapabilityKeeper) NewCapability(ctx Context, name string) (Capability, error) { + // check name not taken in memory store + if capStore.Get("rev/" + name) != nil { + return nil, errors.New("name already taken") + } + + // fetch the current index + index := persistentStore.Get("index") + + // create a new capability + capability := &CapabilityKey{index: index} + + // set persistent store + persistentStore.Set(index, Set.singleton(sck.moduleName + "/" + name)) + + // update the index + index++ + persistentStore.Set("index", index) + + // set forward mapping in memory store from capability to name + memStore.Set(sck.moduleName + "/fwd/" + capability, name) + + // set reverse mapping in memory store from name to index + memStore.Set(sck.moduleName + "/rev/" + name, index) + + // set the in-memory mapping from index to capability pointer + capMap[index] = capability + + // return the newly created capability + return capability +} +``` + +`AuthenticateCapability` can be called by any module to check that a capability +does in fact correspond to a particular name (the name can be untrusted user input) +with which the calling module previously associated it. + +```golang +func (sck ScopedCapabilityKeeper) AuthenticateCapability(name string, capability Capability) bool { + // return whether forward mapping in memory store matches name + return memStore.Get(sck.moduleName + "/fwd/" + capability) === name +} +``` + +`ClaimCapability` allows a module to claim a capability key which it has received from another module +so that future `GetCapability` calls will succeed. + +`ClaimCapability` MUST be called if a module which receives a capability wishes to access it by name +in the future. Capabilities are multi-owner, so if multiple modules have a single `Capability` reference, +they will all own it. + +```golang +func (sck ScopedCapabilityKeeper) ClaimCapability(ctx Context, capability Capability, name string) error { + persistentStore := ctx.KVStore(sck.persistentKey) + + // set forward mapping in memory store from capability to name + memStore.Set(sck.moduleName + "/fwd/" + capability, name) + + // set reverse mapping in memory store from name to capability + memStore.Set(sck.moduleName + "/rev/" + name, capability) + + // update owner set in persistent store + owners := persistentStore.Get(capability.Index()) + owners.add(sck.moduleName + "/" + name) + persistentStore.Set(capability.Index(), owners) +} +``` + +`GetCapability` allows a module to fetch a capability which it has previously claimed by name. +The module is not allowed to retrieve capabilities which it does not own. + +```golang +func (sck ScopedCapabilityKeeper) GetCapability(ctx Context, name string) (Capability, error) { + // fetch the index of capability using reverse mapping in memstore + index := memStore.Get(sck.moduleName + "/rev/" + name) + + // fetch capability from go-map using index + capability := capMap[index] + + // return the capability + return capability +} +``` + +`ReleaseCapability` allows a module to release a capability which it had previously claimed. If no +more owners exist, the capability will be deleted globally. + +```golang +func (sck ScopedCapabilityKeeper) ReleaseCapability(ctx Context, capability Capability) err { + persistentStore := ctx.KVStore(sck.persistentKey) + + name := capStore.Get(sck.moduleName + "/fwd/" + capability) + if name == nil { + return error("capability not owned by module") + } + + // delete forward mapping in memory store + memoryStore.Delete(sck.moduleName + "/fwd/" + capability, name) + + // delete reverse mapping in memory store + memoryStore.Delete(sck.moduleName + "/rev/" + name, capability) + + // update owner set in persistent store + owners := persistentStore.Get(capability.Index()) + owners.remove(sck.moduleName + "/" + name) + if owners.size() > 0 { + // there are still other owners, keep the capability around + persistentStore.Set(capability.Index(), owners) + } else { + // no more owners, delete the capability + persistentStore.Delete(capability.Index()) + delete(capMap[capability.Index()]) + } +} +``` + +### Usage patterns + +#### Initialisation + +Any modules which use dynamic capabilities must be provided a `ScopedCapabilityKeeper` in `app.go`: + +```golang +ck := NewCapabilityKeeper(persistentKey, memoryKey) +mod1Keeper := NewMod1Keeper(ck.ScopeToModule("mod1"), ....) +mod2Keeper := NewMod2Keeper(ck.ScopeToModule("mod2"), ....) + +// other initialisation logic ... + +// load initial state... + +ck.InitialiseAndSeal(initialContext) +``` + +#### Creating, passing, claiming and using capabilities + +Consider the case where `mod1` wants to create a capability, associate it with a resource (e.g. an IBC channel) by name, then pass it to `mod2` which will use it later: + +Module 1 would have the following code: + +```golang +capability := scopedCapabilityKeeper.NewCapability(ctx, "resourceABC") +mod2Keeper.SomeFunction(ctx, capability, args...) +``` + +`SomeFunction`, running in module 2, could then claim the capability: + +```golang +func (k Mod2Keeper) SomeFunction(ctx Context, capability Capability) { + k.sck.ClaimCapability(ctx, capability, "resourceABC") + // other logic... +} +``` + +Later on, module 2 can retrieve that capability by name and pass it to module 1, which will authenticate it against the resource: + +```golang +func (k Mod2Keeper) SomeOtherFunction(ctx Context, name string) { + capability := k.sck.GetCapability(ctx, name) + mod1.UseResource(ctx, capability, "resourceABC") +} +``` + +Module 1 will then check that this capability key is authenticated to use the resource before allowing module 2 to use it: + +```golang +func (k Mod1Keeper) UseResource(ctx Context, capability Capability, resource string) { + if !k.sck.AuthenticateCapability(name, capability) { + return errors.New("unauthenticated") + } + // do something with the resource +} +``` + +If module 2 passed the capability key to module 3, module 3 could then claim it and call module 1 just like module 2 did +(in which case module 1, module 2, and module 3 would all be able to use this capability). + +## Status + +Proposed. + +## Consequences + +### Positive + +- Dynamic capability support. +- Allows CapabilityKeeper to return same capability pointer from go-map while reverting any writes to the persistent `KVStore` and in-memory `MemoryStore` on tx failure. + +### Negative + +- Requires an additional keeper. +- Some overlap with existing `StoreKey` system (in the future they could be combined, since this is a superset functionality-wise). +- Requires an extra level of indirection in the reverse mapping, since MemoryStore must map to index which must then be used as key in a go map to retrieve the actual capability + +### Neutral + +(none known) + +## References + +- [Original discussion](https://github.com/cosmos/cosmos-sdk/pull/5230#discussion_r343978513) diff --git a/versioned_docs/version-0.45/integrate/architecture/adr-004-split-denomination-keys.md b/versioned_docs/version-0.45/integrate/architecture/adr-004-split-denomination-keys.md new file mode 100644 index 000000000..ae192c632 --- /dev/null +++ b/versioned_docs/version-0.45/integrate/architecture/adr-004-split-denomination-keys.md @@ -0,0 +1,120 @@ +# ADR 004: Split Denomination Keys + +## Changelog + +- 2020-01-08: Initial version +- 2020-01-09: Alterations to handle vesting accounts +- 2020-01-14: Updates from review feedback +- 2020-01-30: Updates from implementation + +### Glossary + +* denom / denomination key -- unique token identifier. + +## Context + +With permissionless IBC, anyone will be able to send arbitrary denominations to any other account. Currently, all non-zero balances are stored along with the account in an `sdk.Coins` struct, which creates a potential denial-of-service concern, as too many denominations will become expensive to load & store each time the account is modified. See issues [5467](https://github.com/cosmos/cosmos-sdk/issues/5467) and [4982](https://github.com/cosmos/cosmos-sdk/issues/4982) for additional context. + +Simply rejecting incoming deposits after a denomination count limit doesn't work, since it opens up a griefing vector: someone could send a user lots of nonsensical coins over IBC, and then prevent the user from receiving real denominations (such as staking rewards). + +## Decision + +Balances shall be stored per-account & per-denomination under a denomination- and account-unique key, thus enabling O(1) read & write access to the balance of a particular account in a particular denomination. + +### Account interface (x/auth) + +`GetCoins()` and `SetCoins()` will be removed from the account interface, since coin balances will +now be stored in & managed by the bank module. + +The vesting account interface will replace `SpendableCoins` in favor of `LockedCoins` which does +not require the account balance anymore. In addition, `TrackDelegation()` will now accept the +account balance of all tokens denominated in the vesting balance instead of loading the entire +account balance. + +Vesting accounts will continue to store original vesting, delegated free, and delegated +vesting coins (which is safe since these cannot contain arbitrary denominations). + +### Bank keeper (x/bank) + +The following APIs will be added to the `x/bank` keeper: + +- `GetAllBalances(ctx Context, addr AccAddress) Coins` +- `GetBalance(ctx Context, addr AccAddress, denom string) Coin` +- `SetBalance(ctx Context, addr AccAddress, coin Coin)` +- `LockedCoins(ctx Context, addr AccAddress) Coins` +- `SpendableCoins(ctx Context, addr AccAddress) Coins` + +Additional APIs may be added to facilitate iteration and auxiliary functionality not essential to +core functionality or persistence. + +Balances will be stored first by the address, then by the denomination (the reverse is also possible, +but retrieval of all balances for a single account is presumed to be more frequent): + +```golang +var BalancesPrefix = []byte("balances") + +func (k Keeper) SetBalance(ctx Context, addr AccAddress, balance Coin) error { + if !balance.IsValid() { + return err + } + + store := ctx.KVStore(k.storeKey) + balancesStore := prefix.NewStore(store, BalancesPrefix) + accountStore := prefix.NewStore(balancesStore, addr.Bytes()) + + bz := Marshal(balance) + accountStore.Set([]byte(balance.Denom), bz) + + return nil +} +``` + +This will result in the balances being indexed by the byte representation of +`balances/{address}/{denom}`. + +`DelegateCoins()` and `UndelegateCoins()` will be altered to only load each individual +account balance by denomination found in the (un)delegation amount. As a result, +any mutations to the account balance by will made by denomination. + +`SubtractCoins()` and `AddCoins()` will be altered to read & write the balances +directly instead of calling `GetCoins()` / `SetCoins()` (which no longer exist). + +`trackDelegation()` and `trackUndelegation()` will be altered to no longer update +account balances. + +External APIs will need to scan all balances under an account to retain backwards-compatibility. It +is advised that these APIs use `GetBalance` and `SetBalance` instead of `GetAllBalances` when +possible as to not load the entire account balance. + +### Supply module + +The supply module, in order to implement the total supply invariant, will now need +to scan all accounts & call `GetAllBalances` using the `x/bank` Keeper, then sum +the balances and check that they match the expected total supply. + +## Status + +Accepted. + +## Consequences + +### Positive + +- O(1) reads & writes of balances (with respect to the number of denominations for +which an account has non-zero balances). Note, this does not relate to the actual +I/O cost, rather the total number of direct reads needed. + +### Negative + +- Slightly less efficient reads/writes when reading & writing all balances of a +single account in a transaction. + +### Neutral + +None in particular. + +## References + +- Ref: https://github.com/cosmos/cosmos-sdk/issues/4982 +- Ref: https://github.com/cosmos/cosmos-sdk/issues/5467 +- Ref: https://github.com/cosmos/cosmos-sdk/issues/5492 diff --git a/versioned_docs/version-0.45/integrate/architecture/adr-006-secret-store-replacement.md b/versioned_docs/version-0.45/integrate/architecture/adr-006-secret-store-replacement.md new file mode 100644 index 000000000..8be407727 --- /dev/null +++ b/versioned_docs/version-0.45/integrate/architecture/adr-006-secret-store-replacement.md @@ -0,0 +1,54 @@ +# ADR 006: Secret Store Replacement + +## Changelog + +- July 29th, 2019: Initial draft +- September 11th, 2019: Work has started +- November 4th: SDK changes merged in +- November 18th: Gaia changes merged in + +## Context + +Currently, an SDK application's CLI directory stores key material and metadata in a plain text database in the user’s home directory. Key material is encrypted by a passphrase, protected by bcrypt hashing algorithm. Metadata (e.g. addresses, public keys, key storage details) is available in plain text. + +This is not desirable for a number of reasons. Perhaps the biggest reason is insufficient security protection of key material and metadata. Leaking the plain text allows an attacker to surveil what keys a given computer controls via a number of techniques, like compromised dependencies without any privilege execution. This could be followed by a more targeted attack on a particular user/computer. + +All modern desktop computers OS (Ubuntu, Debian, MacOS, Windows) provide a built-in secret store that is designed to allow applications to store information that is isolated from all other applications and requires passphrase entry to access the data. + +We are seeking solution that provides a common abstraction layer to the many different backends and reasonable fallback for minimal platforms that don’t provide a native secret store. + +## Decision + +We recommend replacing the current Keybase backend based on LevelDB with [Keyring](https://github.com/99designs/keyring) by 99 designs. This application is designed to provide a common abstraction and uniform interface between many secret stores and is used by AWS Vault application by 99-designs application. + +This appears to fulfill the requirement of protecting both key material and metadata from rouge software on a user’s machine. + +## Status + +Accepted + +## Consequences + +### Positive + +Increased safety for users. + +### Negative + +Users must manually migrate. + +Testing against all supported backends is difficult. + +Running tests locally on a Mac require numerous repetitive password entries. + +### Neutral + +{neutral consequences} + +## References + +- #4754 Switch secret store to the keyring secret store (original PR by @poldsam) [__CLOSED__] +- #5029 Add support for github.com/99designs/keyring-backed keybases [__MERGED__] +- #5097 Add keys migrate command [__MERGED__] +- #5180 Drop on-disk keybase in favor of keyring [_PENDING_REVIEW_] +- cosmos/gaia#164 Drop on-disk keybase in favor of keyring (gaia's changes) [_PENDING_REVIEW_] diff --git a/versioned_docs/version-0.45/integrate/architecture/adr-007-specialization-groups.md b/versioned_docs/version-0.45/integrate/architecture/adr-007-specialization-groups.md new file mode 100644 index 000000000..8055fc5a2 --- /dev/null +++ b/versioned_docs/version-0.45/integrate/architecture/adr-007-specialization-groups.md @@ -0,0 +1,177 @@ +# ADR 007: Specialization Groups + +## Changelog + +- 2019 Jul 31: Initial Draft + +## Context + +This idea was first conceived of in order to fulfill the use case of the +creation of a decentralized Computer Emergency Response Team (dCERT), whose +members would be elected by a governing community and would fulfill the role of +coordinating the community under emergency situations. This thinking +can be further abstracted into the conception of "blockchain specialization +groups". + +The creation of these groups are the beginning of specialization capabilities +within a wider blockchain community which could be used to enable a certain +level of delegated responsibilities. Examples of specialization which could be +beneficial to a blockchain community include: code auditing, emergency response, +code development etc. This type of community organization paves the way for +individual stakeholders to delegate votes by issue type, if in the future +governance proposals include a field for issue type. + +## Decision + +A specialization group can be broadly broken down into the following functions +(herein containing examples): + +- Membership Admittance +- Membership Acceptance +- Membership Revocation + - (probably) Without Penalty + - member steps down (self-Revocation) + - replaced by new member from governance + - (probably) With Penalty + - due to breach of soft-agreement (determined through governance) + - due to breach of hard-agreement (determined by code) +- Execution of Duties + - Special transactions which only execute for members of a specialization + group (for example, dCERT members voting to turn off transaction routes in + an emergency scenario) +- Compensation + - Group compensation (further distribution decided by the specialization group) + - Individual compensation for all constituents of a group from the + greater community + +Membership admittance to a specialization group could take place over a wide +variety of mechanisms. The most obvious example is through a general vote among +the entire community, however in certain systems a community may want to allow +the members already in a specialization group to internally elect new members, +or maybe the community may assign a permission to a particular specialization +group to appoint members to other 3rd party groups. The sky is really the limit +as to how membership admittance can be structured. We attempt to capture +some of these possiblities in a common interface dubbed the `Electionator`. For +its initial implementation as a part of this ADR we recommend that the general +election abstraction (`Electionator`) is provided as well as a basic +implementation of that abstraction which allows for a continuous election of +members of a specialization group. + +``` golang +// The Electionator abstraction covers the concept space for +// a wide variety of election kinds. +type Electionator interface { + + // is the election object accepting votes. + Active() bool + + // functionality to execute for when a vote is cast in this election, here + // the vote field is anticipated to be marshalled into a vote type used + // by an election. + // + // NOTE There are no explicit ids here. Just votes which pertain specifically + // to one electionator. Anyone can create and send a vote to the electionator item + // which will presumably attempt to marshal those bytes into a particular struct + // and apply the vote information in some arbitrary way. There can be multiple + // Electionators within the Cosmos-Hub for multiple specialization groups, votes + // would need to be routed to the Electionator upstream of here. + Vote(addr sdk.AccAddress, vote []byte) + + // here lies all functionality to authenticate and execute changes for + // when a member accepts being elected + AcceptElection(sdk.AccAddress) + + // Register a revoker object + RegisterRevoker(Revoker) + + // No more revokers may be registered after this function is called + SealRevokers() + + // register hooks to call when an election actions occur + RegisterHooks(ElectionatorHooks) + + // query for the current winner(s) of this election based on arbitrary + // election ruleset + QueryElected() []sdk.AccAddress + + // query metadata for an address in the election this + // could include for example position that an address + // is being elected for within a group + // + // this metadata may be directly related to + // voting information and/or privileges enabled + // to members within a group. + QueryMetadata(sdk.AccAddress) []byte +} + +// ElectionatorHooks, once registered with an Electionator, +// trigger execution of relevant interface functions when +// Electionator events occur. +type ElectionatorHooks interface { + AfterVoteCast(addr sdk.AccAddress, vote []byte) + AfterMemberAccepted(addr sdk.AccAddress) + AfterMemberRevoked(addr sdk.AccAddress, cause []byte) +} + +// Revoker defines the function required for a membership revocation rule-set +// used by a specialization group. This could be used to create self revoking, +// and evidence based revoking, etc. Revokers types may be created and +// reused for different election types. +// +// When revoking the "cause" bytes may be arbitrarily marshalled into evidence, +// memos, etc. +type Revoker interface { + RevokeName() string // identifier for this revoker type + RevokeMember(addr sdk.AccAddress, cause []byte) error +} +``` + +Certain level of commonality likely exists between the existing code within +`x/governance` and required functionality of elections. This common +functionality should be abstracted during implementation. Similarly for each +vote implementation client CLI/REST functionality should be abstracted +to be reused for multiple elections. + +The specialization group abstraction firstly extends the `Electionator` +but also further defines traits of the group. + +``` golang +type SpecializationGroup interface { + Electionator + GetName() string + GetDescription() string + + // general soft contract the group is expected + // to fulfill with the greater community + GetContract() string + + // messages which can be executed by the members of the group + Handler(ctx sdk.Context, msg sdk.Msg) sdk.Result + + // logic to be executed at endblock, this may for instance + // include payment of a stipend to the group members + // for participation in the security group. + EndBlocker(ctx sdk.Context) +} +``` + +## Status + +> Proposed + +## Consequences + +### Positive + +- increases specialization capabilities of a blockchain +- improve abstractions in `x/gov/` such that they can be used with specialization groups + +### Negative + +- could be used to increase centralization within a community + +### Neutral + +## References + +- [dCERT ADR](./adr-008-dCERT-group.md) diff --git a/versioned_docs/version-0.45/integrate/architecture/adr-008-dCERT-group.md b/versioned_docs/version-0.45/integrate/architecture/adr-008-dCERT-group.md new file mode 100644 index 000000000..a6f0dfb19 --- /dev/null +++ b/versioned_docs/version-0.45/integrate/architecture/adr-008-dCERT-group.md @@ -0,0 +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) diff --git a/versioned_docs/version-0.45/integrate/architecture/adr-009-evidence-module.md b/versioned_docs/version-0.45/integrate/architecture/adr-009-evidence-module.md new file mode 100644 index 000000000..f6f47170c --- /dev/null +++ b/versioned_docs/version-0.45/integrate/architecture/adr-009-evidence-module.md @@ -0,0 +1,182 @@ +# ADR 009: Evidence Module + +## Changelog + +- 2019 July 31: Initial draft +- 2019 October 24: Initial implementation + +## Status + +Accepted + +## Context + +In order to support building highly secure, robust and interoperable blockchain +applications, it is vital for the Cosmos SDK to expose a mechanism in which arbitrary +evidence can be submitted, evaluated and verified resulting in some agreed upon +penalty for any misbehavior committed by a validator, such as equivocation (double-voting), +signing when unbonded, signing an incorrect state transition (in the future), etc. +Furthermore, such a mechanism is paramount for any +[IBC](https://github.com/cosmos/ics/blob/master/ibc/2_IBC_ARCHITECTURE.md) or +cross-chain validation protocol implementation in order to support the ability +for any misbehavior to be relayed back from a collateralized chain to a primary +chain so that the equivocating validator(s) can be slashed. + +## Decision + +We will implement an evidence module in the Cosmos SDK supporting the following +functionality: + +- Provide developers with the abstractions and interfaces necessary to define + custom evidence messages, message handlers, and methods to slash and penalize + accordingly for misbehavior. +- Support the ability to route evidence messages to handlers in any module to + determine the validity of submitted misbehavior. +- Support the ability, through governance, to modify slashing penalties of any + evidence type. +- Querier implementation to support querying params, evidence types, params, and + all submitted valid misbehavior. + +### Types + +First, we define the `Evidence` interface type. The `x/evidence` module may implement +its own types that can be used by many chains (e.g. `CounterFactualEvidence`). +In addition, other modules may implement their own `Evidence` types in a similar +manner in which governance is extensible. It is important to note any concrete +type implementing the `Evidence` interface may include arbitrary fields such as +an infraction time. We want the `Evidence` type to remain as flexible as possible. + +When submitting evidence to the `x/evidence` module, the concrete type must provide +the validator's consensus address, which should be known by the `x/slashing` +module (assuming the infraction is valid), the height at which the infraction +occurred and the validator's power at same height in which the infraction occurred. + +```go +type Evidence interface { + Route() string + Type() string + String() string + Hash() HexBytes + ValidateBasic() error + + // The consensus address of the malicious validator at time of infraction + GetConsensusAddress() ConsAddress + + // Height at which the infraction occurred + GetHeight() int64 + + // The total power of the malicious validator at time of infraction + GetValidatorPower() int64 + + // The total validator set power at time of infraction + GetTotalPower() int64 +} +``` + +### Routing & Handling + +Each `Evidence` type must map to a specific unique route and be registered with +the `x/evidence` module. It accomplishes this through the `Router` implementation. + +```go +type Router interface { + AddRoute(r string, h Handler) Router + HasRoute(r string) bool + GetRoute(path string) Handler + Seal() +} +``` + +Upon successful routing through the `x/evidence` module, the `Evidence` type +is passed through a `Handler`. This `Handler` is responsible for executing all +corresponding business logic necessary for verifying the evidence as valid. In +addition, the `Handler` may execute any necessary slashing and potential jailing. +Since slashing fractions will typically result from some form of static functions, +allow the `Handler` to do this provides the greatest flexibility. An example could +be `k * evidence.GetValidatorPower()` where `k` is an on-chain parameter controlled +by governance. The `Evidence` type should provide all the external information +necessary in order for the `Handler` to make the necessary state transitions. +If no error is returned, the `Evidence` is considered valid. + +```go +type Handler func(Context, Evidence) error +``` + +### Submission + +`Evidence` is submitted through a `MsgSubmitEvidence` message type which is internally +handled by the `x/evidence` module's `SubmitEvidence`. + +```go +type MsgSubmitEvidence struct { + Evidence +} + +func handleMsgSubmitEvidence(ctx Context, keeper Keeper, msg MsgSubmitEvidence) Result { + if err := keeper.SubmitEvidence(ctx, msg.Evidence); err != nil { + return err.Result() + } + + // emit events... + + return Result{ + // ... + } +} +``` + +The `x/evidence` module's keeper is responsible for matching the `Evidence` against +the module's router and invoking the corresponding `Handler` which may include +slashing and jailing the validator. Upon success, the submitted evidence is persisted. + +```go +func (k Keeper) SubmitEvidence(ctx Context, evidence Evidence) error { + handler := keeper.router.GetRoute(evidence.Route()) + if err := handler(ctx, evidence); err != nil { + return ErrInvalidEvidence(keeper.codespace, err) + } + + keeper.setEvidence(ctx, evidence) + return nil +} +``` + +### Genesis + +Finally, we need to represent the genesis state of the `x/evidence` module. The +module only needs a list of all submitted valid infractions and any necessary params +for which the module needs in order to handle submitted evidence. The `x/evidence` +module will naturally define and route native evidence types for which it'll most +likely need slashing penalty constants for. + +```go +type GenesisState struct { + Params Params + Infractions []Evidence +} +``` + +## Consequences + +### Positive + +- Allows the state machine to process misbehavior submitted on-chain and penalize + validators based on agreed upon slashing parameters. +- Allows evidence types to be defined and handled by any module. This further allows + slashing and jailing to be defined by more complex mechanisms. +- Does not solely rely on Tendermint to submit evidence. + +### Negative + +- No easy way to introduce new evidence types through governance on a live chain + due to the inability to introduce the new evidence type's corresponding handler + +### Neutral + +- Should we persist infractions indefinitely? Or should we rather rely on events? + +## References + +- [ICS](https://github.com/cosmos/ics) +- [IBC Architecture](https://github.com/cosmos/ics/blob/master/ibc/1_IBC_ARCHITECTURE.md) +- [Tendermint Fork Accountability](https://github.com/tendermint/spec/blob/7b3138e69490f410768d9b1ffc7a17abc23ea397/spec/consensus/fork-accountability.md) diff --git a/versioned_docs/version-0.45/integrate/architecture/adr-010-modular-antehandler.md b/versioned_docs/version-0.45/integrate/architecture/adr-010-modular-antehandler.md new file mode 100644 index 000000000..15d28dbee --- /dev/null +++ b/versioned_docs/version-0.45/integrate/architecture/adr-010-modular-antehandler.md @@ -0,0 +1,285 @@ +# ADR 010: Modular AnteHandler + +## Changelog + +- 2019 Aug 31: Initial draft + +## Context + +The current AnteHandler design allows users to either use the default AnteHandler provided in `x/auth` or to build their own AnteHandler from scratch. Ideally AnteHandler functionality is split into multiple, modular functions that can be chained together along with custom ante-functions so that users do not have to rewrite common antehandler logic when they want to implement custom behavior. + +For example, let's say a user wants to implement some custom signature verification logic. In the current codebase, the user would have to write their own Antehandler from scratch largely reimplementing much of the same code and then set their own custom, monolithic antehandler in the baseapp. Instead, we would like to allow users to specify custom behavior when necessary and combine them with default ante-handler functionality in a way that is as modular and flexible as possible. + +## Proposals + +### Per-Module AnteHandler + +One approach is to use the [ModuleManager](https://godoc.org/github.com/cosmos/cosmos-sdk/types/module) and have each module implement its own antehandler if it requires custom antehandler logic. The ModuleManager can then be passed in an AnteHandler order in the same way it has an order for BeginBlockers and EndBlockers. The ModuleManager returns a single AnteHandler function that will take in a tx and run each module's `AnteHandle` in the specified order. The module manager's AnteHandler is set as the baseapp's AnteHandler. + +Pros: + +1. Simple to implement +2. Utilizes the existing ModuleManager architecture + +Cons: + +1. Improves granularity but still cannot get more granular than a per-module basis. e.g. If auth's `AnteHandle` function is in charge of validating memo and signatures, users cannot swap the signature-checking functionality while keeping the rest of auth's `AnteHandle` functionality. +2. Module AnteHandler are run one after the other. There is no way for one AnteHandler to wrap or "decorate" another. + +### Decorator Pattern + +The [weave project](https://github.com/iov-one/weave) achieves AnteHandler modularity through the use of a decorator pattern. The interface is designed as follows: + +```go +// Decorator wraps a Handler to provide common functionality +// like authentication, or fee-handling, to many Handlers +type Decorator interface { + Check(ctx Context, store KVStore, tx Tx, next Checker) (*CheckResult, error) + Deliver(ctx Context, store KVStore, tx Tx, next Deliverer) (*DeliverResult, error) +} +``` + +Each decorator works like a modularized SDK antehandler function, but it can take in a `next` argument that may be another decorator or a Handler (which does not take in a next argument). These decorators can be chained together, one decorator being passed in as the `next` argument of the previous decorator in the chain. The chain ends in a Router which can take a tx and route to the appropriate msg handler. + +A key benefit of this approach is that one Decorator can wrap its internal logic around the next Checker/Deliverer. A weave Decorator may do the following: + +```go +// Example Decorator's Deliver function +func (example Decorator) Deliver(ctx Context, store KVStore, tx Tx, next Deliverer) { + // Do some pre-processing logic + + res, err := next.Deliver(ctx, store, tx) + + // Do some post-processing logic given the result and error +} +``` + +Pros: + +1. Weave Decorators can wrap over the next decorator/handler in the chain. The ability to both pre-process and post-process may be useful in certain settings. +2. Provides a nested modular structure that isn't possible in the solution above, while also allowing for a linear one-after-the-other structure like the solution above. + +Cons: + +1. It is hard to understand at first glance the state updates that would occur after a Decorator runs given the `ctx`, `store`, and `tx`. A Decorator can have an arbitrary number of nested Decorators being called within its function body, each possibly doing some pre- and post-processing before calling the next decorator on the chain. Thus to understand what a Decorator is doing, one must also understand what every other decorator further along the chain is also doing. This can get quite complicated to understand. A linear, one-after-the-other approach while less powerful, may be much easier to reason about. + +### Chained Micro-Functions + +The benefit of Weave's approach is that the Decorators can be very concise, which when chained together allows for maximum customizability. However, the nested structure can get quite complex and thus hard to reason about. + +Another approach is to split the AnteHandler functionality into tightly scoped "micro-functions", while preserving the one-after-the-other ordering that would come from the ModuleManager approach. + +We can then have a way to chain these micro-functions so that they run one after the other. Modules may define multiple ante micro-functions and then also provide a default per-module AnteHandler that implements a default, suggested order for these micro-functions. + +Users can order the AnteHandlers easily by simply using the ModuleManager. The ModuleManager will take in a list of AnteHandlers and return a single AnteHandler that runs each AnteHandler in the order of the list provided. If the user is comfortable with the default ordering of each module, this is as simple as providing a list with each module's antehandler (exactly the same as BeginBlocker and EndBlocker). + +If however, users wish to change the order or add, modify, or delete ante micro-functions in anyway; they can always define their own ante micro-functions and add them explicitly to the list that gets passed into module manager. + +#### Default Workflow + +This is an example of a user's AnteHandler if they choose not to make any custom micro-functions. + +##### SDK code + +```go +// Chains together a list of AnteHandler micro-functions that get run one after the other. +// Returned AnteHandler will abort on first error. +func Chainer(order []AnteHandler) AnteHandler { + return func(ctx Context, tx Tx, simulate bool) (newCtx Context, err error) { + for _, ante := range order { + ctx, err := ante(ctx, tx, simulate) + if err != nil { + return ctx, err + } + } + return ctx, err + } +} +``` + +```go +// AnteHandler micro-function to verify signatures +func VerifySignatures(ctx Context, tx Tx, simulate bool) (newCtx Context, err error) { + // verify signatures + // Returns InvalidSignature Result and abort=true if sigs invalid + // Return OK result and abort=false if sigs are valid +} + +// AnteHandler micro-function to validate memo +func ValidateMemo(ctx Context, tx Tx, simulate bool) (newCtx Context, err error) { + // validate memo +} + +// Auth defines its own default ante-handler by chaining its micro-functions in a recommended order +AuthModuleAnteHandler := Chainer([]AnteHandler{VerifySignatures, ValidateMemo}) +``` + +```go +// Distribution micro-function to deduct fees from tx +func DeductFees(ctx Context, tx Tx, simulate bool) (newCtx Context, err error) { + // Deduct fees from tx + // Abort if insufficient funds in account to pay for fees +} + +// Distribution micro-function to check if fees > mempool parameter +func CheckMempoolFees(ctx Context, tx Tx, simulate bool) (newCtx Context, err error) { + // If CheckTx: Abort if the fees are less than the mempool's minFee parameter +} + +// Distribution defines its own default ante-handler by chaining its micro-functions in a recommended order +DistrModuleAnteHandler := Chainer([]AnteHandler{CheckMempoolFees, DeductFees}) +``` + +```go +type ModuleManager struct { + // other fields + AnteHandlerOrder []AnteHandler +} + +func (mm ModuleManager) GetAnteHandler() AnteHandler { + retun Chainer(mm.AnteHandlerOrder) +} +``` + +##### User Code + +```go +// Note: Since user is not making any custom modifications, we can just SetAnteHandlerOrder with the default AnteHandlers provided by each module in our preferred order +moduleManager.SetAnteHandlerOrder([]AnteHandler(AuthModuleAnteHandler, DistrModuleAnteHandler)) + +app.SetAnteHandler(mm.GetAnteHandler()) +``` + +#### Custom Workflow + +This is an example workflow for a user that wants to implement custom antehandler logic. In this example, the user wants to implement custom signature verification and change the order of antehandler so that validate memo runs before signature verification. + +##### User Code + +```go +// User can implement their own custom signature verification antehandler micro-function +func CustomSigVerify(ctx Context, tx Tx, simulate bool) (newCtx Context, err error) { + // do some custom signature verification logic +} +``` + +```go +// Micro-functions allow users to change order of when they get executed, and swap out default ante-functionality with their own custom logic. +// Note that users can still chain the default distribution module handler, and auth micro-function along with their custom ante function +moduleManager.SetAnteHandlerOrder([]AnteHandler(ValidateMemo, CustomSigVerify, DistrModuleAnteHandler)) +``` + +Pros: + +1. Allows for ante functionality to be as modular as possible. +2. For users that do not need custom ante-functionality, there is little difference between how antehandlers work and how BeginBlock and EndBlock work in ModuleManager. +3. Still easy to understand + +Cons: + +1. Cannot wrap antehandlers with decorators like you can with Weave. + +### Simple Decorators + +This approach takes inspiration from Weave's decorator design while trying to minimize the number of breaking changes to the SDK and maximizing simplicity. Like Weave decorators, this approach allows one `AnteDecorator` to wrap the next AnteHandler to do pre- and post-processing on the result. This is useful since decorators can do defer/cleanups after an AnteHandler returns as well as perform some setup beforehand. Unlike Weave decorators, these `AnteDecorator` functions can only wrap over the AnteHandler rather than the entire handler execution path. This is deliberate as we want decorators from different modules to perform authentication/validation on a `tx`. However, we do not want decorators being capable of wrapping and modifying the results of a `MsgHandler`. + +In addition, this approach will not break any core SDK API's. Since we preserve the notion of an AnteHandler and still set a single AnteHandler in baseapp, the decorator is simply an additional approach available for users that desire more customization. The API of modules (namely `x/auth`) may break with this approach, but the core API remains untouched. + +Allow Decorator interface that can be chained together to create an SDK AnteHandler. + +This allows users to choose between implementing an AnteHandler by themselves and setting it in the baseapp, or use the decorator pattern to chain their custom decorators with SDK provided decorators in the order they wish. + +```go +// An AnteDecorator wraps an AnteHandler, and can do pre- and post-processing on the next AnteHandler +type AnteDecorator interface { + AnteHandle(ctx Context, tx Tx, simulate bool, next AnteHandler) (newCtx Context, err error) +} +``` + +```go +// ChainAnteDecorators will recursively link all of the AnteDecorators in the chain and return a final AnteHandler function +// This is done to preserve the ability to set a single AnteHandler function in the baseapp. +func ChainAnteDecorators(chain ...AnteDecorator) AnteHandler { + if len(chain) == 1 { + return func(ctx Context, tx Tx, simulate bool) { + chain[0].AnteHandle(ctx, tx, simulate, nil) + } + } + return func(ctx Context, tx Tx, simulate bool) { + chain[0].AnteHandle(ctx, tx, simulate, ChainAnteDecorators(chain[1:])) + } +} +``` + +#### Example Code + +Define AnteDecorator functions + +```go +// Setup GasMeter, catch OutOfGasPanic and handle appropriately +type SetUpContextDecorator struct{} + +func (sud SetUpContextDecorator) AnteHandle(ctx Context, tx Tx, simulate bool, next AnteHandler) (newCtx Context, err error) { + ctx.GasMeter = NewGasMeter(tx.Gas) + + defer func() { + // recover from OutOfGas panic and handle appropriately + } + + return next(ctx, tx, simulate) +} + +// Signature Verification decorator. Verify Signatures and move on +type SigVerifyDecorator struct{} + +func (svd SigVerifyDecorator) AnteHandle(ctx Context, tx Tx, simulate bool, next AnteHandler) (newCtx Context, err error) { + // verify sigs. Return error if invalid + + // call next antehandler if sigs ok + return next(ctx, tx, simulate) +} + +// User-defined Decorator. Can choose to pre- and post-process on AnteHandler +type UserDefinedDecorator struct{ + // custom fields +} + +func (udd UserDefinedDecorator) AnteHandle(ctx Context, tx Tx, simulate bool, next AnteHandler) (newCtx Context, err error) { + // pre-processing logic + + ctx, err = next(ctx, tx, simulate) + + // post-processing logic +} +``` + +Link AnteDecorators to create a final AnteHandler. Set this AnteHandler in baseapp. + +```go +// Create final antehandler by chaining the decorators together +antehandler := ChainAnteDecorators(NewSetUpContextDecorator(), NewSigVerifyDecorator(), NewUserDefinedDecorator()) + +// Set chained Antehandler in the baseapp +bapp.SetAnteHandler(antehandler) +``` + +Pros: + +1. Allows one decorator to pre- and post-process the next AnteHandler, similar to the Weave design. +2. Do not need to break baseapp API. Users can still set a single AnteHandler if they choose. + +Cons: + +1. Decorator pattern may have a deeply nested structure that is hard to understand, this is mitigated by having the decorator order explicitly listed in the `ChainAnteDecorators` function. +2. Does not make use of the ModuleManager design. Since this is already being used for BeginBlocker/EndBlocker, this proposal seems unaligned with that design pattern. + +## Consequences + +Since pros and cons are written for each approach, it is omitted from this section + +## References + +- [#4572](https://github.com/cosmos/cosmos-sdk/issues/4572): Modular AnteHandler Issue +- [#4582](https://github.com/cosmos/cosmos-sdk/pull/4583): Initial Implementation of Per-Module AnteHandler Approach +- [Weave Decorator Code](https://github.com/iov-one/weave/blob/master/handler.go#L35) +- [Weave Design Videos](https://vimeo.com/showcase/6189877) diff --git a/versioned_docs/version-0.45/integrate/architecture/adr-011-generalize-genesis-accounts.md b/versioned_docs/version-0.45/integrate/architecture/adr-011-generalize-genesis-accounts.md new file mode 100644 index 000000000..db323966e --- /dev/null +++ b/versioned_docs/version-0.45/integrate/architecture/adr-011-generalize-genesis-accounts.md @@ -0,0 +1,170 @@ +# ADR 011: Generalize Genesis Accounts + +## Changelog + +- 2019-08-30: initial draft + +## Context + +Currently, the SDK allows for custom account types; the `auth` keeper stores any type fulfilling its `Account` interface. However `auth` does not handle exporting or loading accounts to/from a genesis file, this is done by `genaccounts`, which only handles one of 4 concrete account types (`BaseAccount`, `ContinuousVestingAccount`, `DelayedVestingAccount` and `ModuleAccount`). + +Projects desiring to use custom accounts (say custom vesting accounts) need to fork and modify `genaccounts`. + +## Decision + +In summary, we will (un)marshal all accounts (interface types) directly using amino, rather than converting to `genaccounts`’s `GenesisAccount` type. Since doing this removes the majority of `genaccounts`'s code, we will merge `genaccounts` into `auth`. Marshalled accounts will be stored in `auth`'s genesis state. + +Detailed changes: + +### 1) (Un)Marshal accounts directly using amino + +The `auth` module's `GenesisState` gains a new field `Accounts`. Note these aren't of type `exported.Account` for reasons outlined in section 3. + +```go +// GenesisState - all auth state that must be provided at genesis +type GenesisState struct { + Params Params `json:"params" yaml:"params"` + Accounts []GenesisAccount `json:"accounts" yaml:"accounts"` +} +``` + +Now `auth`'s `InitGenesis` and `ExportGenesis` (un)marshal accounts as well as the defined params. + +```go +// InitGenesis - Init store state from genesis data +func InitGenesis(ctx sdk.Context, ak AccountKeeper, data GenesisState) { + ak.SetParams(ctx, data.Params) + // load the accounts + for _, a := range data.Accounts { + acc := ak.NewAccount(ctx, a) // set account number + ak.SetAccount(ctx, acc) + } +} + +// ExportGenesis returns a GenesisState for a given context and keeper +func ExportGenesis(ctx sdk.Context, ak AccountKeeper) GenesisState { + params := ak.GetParams(ctx) + + var genAccounts []exported.GenesisAccount + ak.IterateAccounts(ctx, func(account exported.Account) bool { + genAccount := account.(exported.GenesisAccount) + genAccounts = append(genAccounts, genAccount) + return false + }) + + return NewGenesisState(params, genAccounts) +} +``` + +### 2) Register custom account types on the `auth` codec + +The `auth` codec must have all custom account types registered to marshal them. We will follow the pattern established in `gov` for proposals. + +An example custom account definition: + +```go +import authtypes "github.com/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 +func init() { + authtypes.RegisterAccountTypeCodec(ModuleAccount{}, "cosmos-sdk/ModuleAccount") +} + +type ModuleAccount struct { + ... +``` + +The `auth` codec definition: + +```go +var ModuleCdc *codec.LegacyAmino + +func init() { + ModuleCdc = codec.NewLegacyAmino() + // register module msg's and Account interface + ... + // leave the codec unsealed +} + +// RegisterAccountTypeCodec registers an external account type defined in another module for the internal ModuleCdc. +func RegisterAccountTypeCodec(o interface{}, name string) { + ModuleCdc.RegisterConcrete(o, name, nil) +} +``` + +### 3) Genesis validation for custom account types + +Modules implement a `ValidateGenesis` method. As `auth` does not know of account implementations, accounts will need to validate themselves. + +We will unmarshal accounts into a `GenesisAccount` interface that includes a `Validate` method. + +```go +type GenesisAccount interface { + exported.Account + Validate() error +} +``` + +Then the `auth` `ValidateGenesis` function becomes: + +```go +// ValidateGenesis performs basic validation of auth genesis data returning an +// error for any failed validation criteria. +func ValidateGenesis(data GenesisState) error { + // Validate params + ... + + // Validate accounts + addrMap := make(map[string]bool, len(data.Accounts)) + for _, acc := range data.Accounts { + + // check for duplicated accounts + addrStr := acc.GetAddress().String() + if _, ok := addrMap[addrStr]; ok { + return fmt.Errorf("duplicate account found in genesis state; address: %s", addrStr) + } + addrMap[addrStr] = true + + // check account specific validation + if err := acc.Validate(); err != nil { + return fmt.Errorf("invalid account found in genesis state; address: %s, error: %s", addrStr, err.Error()) + } + + } + return nil +} +``` + +### 4) Move add-genesis-account cli to `auth` + +The `genaccounts` module contains a cli command to add base or vesting accounts to a genesis file. + +This will be moved to `auth`. We will leave it to projects to write their own commands to add custom accounts. An extensible cli handler, similar to `gov`, could be created but it is not worth the complexity for this minor use case. + +### 5) Update module and vesting accounts + +Under the new scheme, module and vesting account types need some minor updates: + +- Type registration on `auth`'s codec (shown above) +- A `Validate` method for each `Account` concrete type + +## Status + +Proposed + +## Consequences + +### Positive + +- custom accounts can be used without needing to fork `genaccounts` +- reduction in lines of code + +### Negative + +### Neutral + +- `genaccounts` module no longer exists +- accounts in genesis files are stored under `accounts` in `auth` rather than in the `genaccounts` module. +-`add-genesis-account` cli command now in `auth` + +## References diff --git a/versioned_docs/version-0.45/integrate/architecture/adr-012-state-accessors.md b/versioned_docs/version-0.45/integrate/architecture/adr-012-state-accessors.md new file mode 100644 index 000000000..b66e23eb6 --- /dev/null +++ b/versioned_docs/version-0.45/integrate/architecture/adr-012-state-accessors.md @@ -0,0 +1,155 @@ +# ADR 012: State Accessors + +## Changelog + +- 2019 Sep 04: Initial draft + +## Context + +SDK modules currently use the `KVStore` interface and `Codec` to access their respective state. While +this provides a large degree of freedom to module developers, it is hard to modularize and the UX is +mediocre. + +First, each time a module tries to access the state, it has to marshal the value and set or get the +value and finally unmarshal. Usually this is done by declaring `Keeper.GetXXX` and `Keeper.SetXXX` functions, +which are repetitive and hard to maintain. + +Second, this makes it harder to align with the object capability theorem: the right to access the +state is defined as a `StoreKey`, which gives full access on the entire Merkle tree, so a module cannot +send the access right to a specific key-value pair (or a set of key-value pairs) to another module safely. + +Finally, because the getter/setter functions are defined as methods of a module's `Keeper`, the reviewers +have to consider the whole Merkle tree space when they reviewing a function accessing any part of the state. +There is no static way to know which part of the state that the function is accessing (and which is not). + +## Decision + +We will define a type named `Value`: + +```go +type Value struct { + m Mapping + key []byte +} +``` + +The `Value` works as a reference for a key-value pair in the state, where `Value.m` defines the key-value +space it will access and `Value.key` defines the exact key for the reference. + +We will define a type named `Mapping`: + +```go +type Mapping struct { + storeKey sdk.StoreKey + cdc *codec.LegacyAmino + prefix []byte +} +``` + +The `Mapping` works as a reference for a key-value space in the state, where `Mapping.storeKey` defines +the IAVL (sub-)tree and `Mapping.prefix` defines the optional subspace prefix. + +We will define the following core methods for the `Value` type: + +```go +// Get and unmarshal stored data, noop if not exists, panic if cannot unmarshal +func (Value) Get(ctx Context, ptr interface{}) {} + +// Get and unmarshal stored data, return error if not exists or cannot unmarshal +func (Value) GetSafe(ctx Context, ptr interface{}) {} + +// Get stored data as raw byte slice +func (Value) GetRaw(ctx Context) []byte {} + +// Marshal and set a raw value +func (Value) Set(ctx Context, o interface{}) {} + +// Check if a raw value exists +func (Value) Exists(ctx Context) bool {} + +// Delete a raw value value +func (Value) Delete(ctx Context) {} +``` + +We will define the following core methods for the `Mapping` type: + +```go +// Constructs key-value pair reference corresponding to the key argument in the Mapping space +func (Mapping) Value(key []byte) Value {} + +// Get and unmarshal stored data, noop if not exists, panic if cannot unmarshal +func (Mapping) Get(ctx Context, key []byte, ptr interface{}) {} + +// Get and unmarshal stored data, return error if not exists or cannot unmarshal +func (Mapping) GetSafe(ctx Context, key []byte, ptr interface{}) + +// Get stored data as raw byte slice +func (Mapping) GetRaw(ctx Context, key []byte) []byte {} + +// Marshal and set a raw value +func (Mapping) Set(ctx Context, key []byte, o interface{}) {} + +// Check if a raw value exists +func (Mapping) Has(ctx Context, key []byte) bool {} + +// Delete a raw value value +func (Mapping) Delete(ctx Context, key []byte) {} +``` + +Each method of the `Mapping` type that is passed the arugments `ctx`, `key`, and `args...` will proxy +the call to `Mapping.Value(key)` with arguments `ctx` and `args...`. + +In addition, we will define and provide a common set of types derived from the `Value` type: + +```go +type Boolean struct { Value } +type Enum struct { Value } +type Integer struct { Value; enc IntEncoding } +type String struct { Value } +// ... +``` + +Where the encoding schemes can be different, `o` arguments in core methods are typed, and `ptr` arguments +in core methods are replaced by explicit return types. + +Finally, we will define a family of types derived from the `Mapping` type: + +```go +type Indexer struct { + m Mapping + enc IntEncoding +} +``` + +Where the `key` argument in core method is typed. + +Some of the properties of the accessor types are: + +- State access happens only when a function which takes a `Context` as an argument is invoked +- Accessor type structs give rights to access the state only that the struct is referring, no other +- Marshalling/Unmarshalling happens implicitly within the core methods + +## Status + +Proposed + +## Consequences + +### Positive + +- Serialization will be done automatically +- Shorter code size, less boilerplate, better UX +- References to the state can be transferred safely +- Explicit scope of accessing + +### Negative + +- Serialization format will be hidden +- Different architecture from the current, but the use of accessor types can be opt-in +- Type-specific types (e.g. `Boolean` and `Integer`) have to be defined manually + +### Neutral + +## References + +- [#4554](https://github.com/cosmos/cosmos-sdk/issues/4554) diff --git a/versioned_docs/version-0.45/integrate/architecture/adr-013-metrics.md b/versioned_docs/version-0.45/integrate/architecture/adr-013-metrics.md new file mode 100644 index 000000000..cf27d8964 --- /dev/null +++ b/versioned_docs/version-0.45/integrate/architecture/adr-013-metrics.md @@ -0,0 +1,157 @@ +# ADR 013: Observability + +## Changelog + +- 20-01-2020: Initial Draft + +## Status + +Proposed + +## Context + +Telemetry is paramount into debugging and understanding what the application is doing and how it is +performing. We aim to expose metrics from modules and other core parts of the Cosmos SDK. + +In addition, we should aim to support multiple configurable sinks that an operator may choose from. +By default, when telemetry is enabled, the application should track and expose metrics that are +stored in-memory. The operator may choose to enable additional sinks, where we support only +[Prometheus](https://prometheus.io/) for now, as it's battle-tested, simple to setup, open source, +and is rich with ecosystem tooling. + +We must also aim to integrate metrics into the Cosmos SDK in the most seamless way possible such that +metrics may be added or removed at will and without much friction. To do this, we will use the +[go-metrics](https://github.com/armon/go-metrics) library. + +Finally, operators may enable telemetry along with specific configuration options. If enabled, metrics +will be exposed via `/metrics?format={text|prometheus}` via the API server. + +## Decision + +We will add an additional configuration block to `app.toml` that defines telemetry settings: + +```toml +############################################################################### +### Telemetry Configuration ### +############################################################################### + +[telemetry] + +# Prefixed with keys to separate services +service-name = {{ .Telemetry.ServiceName }} + +# Enabled enables the application telemetry functionality. When enabled, +# an in-memory sink is also enabled by default. Operators may also enabled +# other sinks such as Prometheus. +enabled = {{ .Telemetry.Enabled }} + +# Enable prefixing gauge values with hostname +enable-hostname = {{ .Telemetry.EnableHostname }} + +# Enable adding hostname to labels +enable-hostname-label = {{ .Telemetry.EnableHostnameLabel }} + +# Enable adding service to labels +enable-service-label = {{ .Telemetry.EnableServiceLabel }} + +# PrometheusRetentionTime, when positive, enables a Prometheus metrics sink. +prometheus-retention-time = {{ .Telemetry.PrometheusRetentionTime }} +``` + +The given configuration allows for two sinks -- in-memory and Prometheus. We create a `Metrics` +type that performs all the bootstrapping for the operator, so capturing metrics becomes seamless. + +```go +// Metrics defines a wrapper around application telemetry functionality. It allows +// metrics to be gathered at any point in time. When creating a Metrics object, +// internally, a global metrics is registered with a set of sinks as configured +// by the operator. In addition to the sinks, when a process gets a SIGUSR1, a +// dump of formatted recent metrics will be sent to STDERR. +type Metrics struct { + memSink *metrics.InmemSink + prometheusEnabled bool +} + +// Gather collects all registered metrics and returns a GatherResponse where the +// metrics are encoded depending on the type. Metrics are either encoded via +// Prometheus or JSON if in-memory. +func (m *Metrics) Gather(format string) (GatherResponse, error) { + switch format { + case FormatPrometheus: + return m.gatherPrometheus() + + case FormatText: + return m.gatherGeneric() + + case FormatDefault: + return m.gatherGeneric() + + default: + return GatherResponse{}, fmt.Errorf("unsupported metrics format: %s", format) + } +} +``` + +In addition, `Metrics` allows us to gather the current set of metrics at any given point in time. An +operator may also choose to send a signal, SIGUSR1, to dump and print formatted metrics to STDERR. + +During an application's bootstrapping and construction phase, if `Telemetry.Enabled` is `true`, the +API server will create an instance of a reference to `Metrics` object and will register a metrics +handler accordingly. + +```go +func (s *Server) Start(cfg config.Config) error { + // ... + + if cfg.Telemetry.Enabled { + m, err := telemetry.New(cfg.Telemetry) + if err != nil { + return err + } + + s.metrics = m + s.registerMetrics() + } + + // ... +} + +func (s *Server) registerMetrics() { + metricsHandler := func(w http.ResponseWriter, r *http.Request) { + format := strings.TrimSpace(r.FormValue("format")) + + gr, err := s.metrics.Gather(format) + if err != nil { + rest.WriteErrorResponse(w, http.StatusBadRequest, fmt.Sprintf("failed to gather metrics: %s", err)) + return + } + + w.Header().Set("Content-Type", gr.ContentType) + _, _ = w.Write(gr.Metrics) + } + + s.Router.HandleFunc("/metrics", metricsHandler).Methods("GET") +} +``` + +Application developers may track counters, gauges, summaries, and key/value metrics. There is no +additional lifting required by modules to leverage profiling metrics. To do so, it's as simple as: + +```go +func (k BaseKeeper) MintCoins(ctx sdk.Context, moduleName string, amt sdk.Coins) error { + defer metrics.MeasureSince(time.Now(), "MintCoins") + // ... +} +``` + +## Consequences + +### Positive + +- Exposure into the performance and behavior of an application + +### Negative + +### Neutral + +## References diff --git a/versioned_docs/version-0.45/integrate/architecture/adr-014-proportional-slashing.md b/versioned_docs/version-0.45/integrate/architecture/adr-014-proportional-slashing.md new file mode 100644 index 000000000..643b022e1 --- /dev/null +++ b/versioned_docs/version-0.45/integrate/architecture/adr-014-proportional-slashing.md @@ -0,0 +1,85 @@ +# ADR 14: Proportional Slashing + +## Changelog + +- 2019-10-15: Initial draft +- 2020-05-25: Removed correlation root slashing +- 2020-07-01: Updated to include S-curve function instead of linear + +## Context + +In Proof of Stake-based chains, centralization of consensus power amongst a small set of validators can cause harm to the network due to increased risk of censorship, liveness failure, fork attacks, etc. However, while this centralization causes a negative externality to the network, it is not directly felt by the delegators contributing towards delegating towards already large validators. We would like a way to pass on the negative externality cost of centralization onto those large validators and their delegators. + +## Decision + +### Design + +To solve this problem, we will implement a procedure called Proportional Slashing. The desire is that the larger a validator is, the more they should be slashed. The first naive attempt is to make a validator's slash percent proportional to their share of consensus voting power. + +``` +slash_amount = k * power // power is the faulting validator's voting power and k is some on-chain constant +``` + +However, this will incentivize validators with large amounts of stake to split up their voting power amongst accounts (sybil attack), so that if they fault, they all get slashed at a lower percent. The solution to this is to take into account not just a validator's own voting percentage, but also the voting percentage of all the other validators who get slashed in a specified time frame. + +``` +slash_amount = k * (power_1 + power_2 + ... + power_n) // where power_i is the voting power of the ith validator faulting in the specified time frame and k is some on-chain constant +``` + +Now, if someone splits a validator of 10% into two validators of 5% each which both fault, then they both fault in the same time frame, they both will get slashed at the sum 10% amount. + +However in practice, we likely don't want a linear relation between amount of stake at fault, and the percentage of stake to slash. In particular, solely 5% of stake double signing effectively did nothing to majorly threaten security, whereas 30% of stake being at fault clearly merits a large slashing factor, due to being very close to the point at which Tendermint security is threatened. A linear relation would require a factor of 6 gap between these two, whereas the difference in risk posed to the network is much larger. We propose using S-curves (formally [logistic functions](https://en.wikipedia.org/wiki/Logistic_function) to solve this). S-Curves capture the desired criterion quite well. They allow the slashing factor to be minimal for small values, and then grow very rapidly near some threshold point where the risk posed becomes notable. + +#### Parameterization + +This requires parameterizing a logistic function. It is very well understood how to parameterize this. It has four parameters: + +1) A minimum slashing factor +2) A maximum slashing factor +3) The inflection point of the S-curve (essentially where do you want to center the S) +4) The rate of growth of the S-curve (How elongated is the S) + +#### Correlation across non-sybil validators + +One will note, that this model doesn't differentiate between multiple validators run by the same operators vs validators run by different operators. This can be seen as an additional benefit in fact. It incentivizes validators to differentiate their setups from other validators, to avoid having correlated faults with them or else they risk a higher slash. So for example, operators should avoid using the same popular cloud hosting platforms or using the same Staking as a Service providers. This will lead to a more resilient and decentralized network. + +#### Griefing + +Griefing, the act of intentionally getting oneself slashed in order to make another's slash worse, could be a concern here. However, using the protocol described here, the attacker also gets equally impacted by the grief as the victim, so it would not provide much benefit to the griefer. + +### Implementation + +In the slashing module, we will add two queues that will track all of the recent slash events. For double sign faults, we will define "recent slashes" as ones that have occured within the last `unbonding period`. For liveness faults, we will define "recent slashes" as ones that have occured withing the last `jail period`. + +``` +type SlashEvent struct { + Address sdk.ValAddress + ValidatorVotingPercent sdk.Dec + SlashedSoFar sdk.Dec +} +``` + +These slash events will be pruned from the queue once they are older than their respective "recent slash period". + +Whenever a new slash occurs, a `SlashEvent` struct is created with the faulting validator's voting percent and a `SlashedSoFar` of 0. Because recent slash events are pruned before the unbonding period and unjail period expires, it should not be possible for the same validator to have multiple SlashEvents in the same Queue at the same time. + +We then will iterate over all the SlashEvents in the queue, adding their `ValidatorVotingPercent` to calculate the new percent to slash all the validators in the queue at, using the "Square of Sum of Roots" formula introduced above. + +Once we have the `NewSlashPercent`, we then iterate over all the `SlashEvent`s in the queue once again, and if `NewSlashPercent > SlashedSoFar` for that SlashEvent, we call the `staking.Slash(slashEvent.Address, slashEvent.Power, Math.Min(Math.Max(minSlashPercent, NewSlashPercent - SlashedSoFar), maxSlashPercent)` (we pass in the power of the validator before any slashes occured, so that we slash the right amount of tokens). We then set `SlashEvent.SlashedSoFar` amount to `NewSlashPercent`. + +## Status + +Proposed + +## Consequences + +### Positive + +- Increases decentralization by disincentivizing delegating to large validators +- Incentivizes Decorrelation of Validators +- More severely punishes attacks than accidental faults +- More flexibility in slashing rates parameterization + +### Negative + +- More computationally expensive than current implementation. Will require more data about "recent slashing events" to be stored on chain. diff --git a/versioned_docs/version-0.45/integrate/architecture/adr-016-validator-consensus-key-rotation.md b/versioned_docs/version-0.45/integrate/architecture/adr-016-validator-consensus-key-rotation.md new file mode 100644 index 000000000..9b5d77e7d --- /dev/null +++ b/versioned_docs/version-0.45/integrate/architecture/adr-016-validator-consensus-key-rotation.md @@ -0,0 +1,125 @@ +# ADR 016: Validator Consensus Key Rotation + +## Changelog + +- 2019 Oct 23: Initial draft +- 2019 Nov 28: Add key rotation fee + +## Context + +Validator consensus key rotation feature has been discussed and requested for a long time, for the sake of safer validator key management policy (e.g. https://github.com/tendermint/tendermint/issues/1136). So, we suggest one of the simplest form of validator consensus key rotation implementation mostly onto Cosmos-SDK. + +We don't need to make any update on consensus logic in Tendermint because Tendermint does not have any mapping information of consensus key and validator operator key, meaning that from Tendermint point of view, a consensus key rotation of a validator is simply a replacement of a consensus key to another. + +Also, it should be noted that this ADR includes only the simplest form of consensus key rotation without considering multiple consensus keys concept. Such multiple consensus keys concept shall remain a long term goal of Tendermint and Cosmos-SDK. + +## Decision + +### Pseudo procedure for consensus key rotation + +- create new random consensus key. +- create and broadcast a transaction with a `MsgRotateConsPubKey` that states the new consensus key is now coupled with the validator operator with signature from the validator's operator key. +- old consensus key becomes unable to participate on consensus immediately after the update of key mapping state on-chain. +- start validating with new consensus key. +- validators using HSM and KMS should update the consensus key in HSM to use the new rotated key after the height `h` when `MsgRotateConsPubKey` committed to the blockchain. + +### Considerations + +- consensus key mapping information management strategy + - store history of each key mapping changes in the kvstore. + - the state machine can search corresponding consensus key paired with given validator operator for any arbitrary height in a recent unbonding period. + - the state machine does not need any historical mapping information which is past more than unbonding period. +- key rotation costs related to LCD and IBC + - LCD and IBC will have traffic/computation burden when there exists frequent power changes + - In current Tendermint design, consensus key rotations are seen as power changes from LCD or IBC perspective + - Therefore, to minimize unnecessary frequent key rotation behavior, we limited maximum number of rotation in recent unbonding period and also applied exponentially increasing rotation fee +- limits + - a validator cannot rotate its consensus key more than `MaxConsPubKeyRotations` time for any unbonding period, to prevent spam. + - parameters can be decided by governance and stored in genesis file. +- key rotation fee + - a validator should pay `KeyRotationFee` to rotate the consensus key which is calculated as below + - `KeyRotationFee` = (max(`VotingPowerPercentage` *100, 1)* `InitialKeyRotationFee`) * 2^(number of rotations in `ConsPubKeyRotationHistory` in recent unbonding period) +- evidence module + - evidence module can search corresponding consensus key for any height from slashing keeper so that it can decide which consensus key is supposed to be used for given height. +- abci.ValidatorUpdate + - tendermint already has ability to change a consensus key by ABCI communication(`ValidatorUpdate`). + - validator consensus key update can be done via creating new + delete old by change the power to zero. + - therefore, we expect we even do not need to change tendermint codebase at all to implement this feature. +- new genesis parameters in `staking` module + - `MaxConsPubKeyRotations` : maximum number of rotation can be executed by a validator in recent unbonding period. default value 10 is suggested(11th key rotation will be rejected) + - `InitialKeyRotationFee` : the initial key rotation fee when no key rotation has happened in recent unbonding period. default value 1atom is suggested(1atom fee for the first key rotation in recent unbonding period) + +### Workflow + +1. The validator generates a new consensus keypair. +2. The validator generates and signs a `MsgRotateConsPubKey` tx with their operator key and new ConsPubKey + + ```go + type MsgRotateConsPubKey struct { + ValidatorAddress sdk.ValAddress + NewPubKey crypto.PubKey + } + ``` + +3. `handleMsgRotateConsPubKey` gets `MsgRotateConsPubKey`, calls `RotateConsPubKey` with emits event +4. `RotateConsPubKey` + - checks if `NewPubKey` is not duplicated on `ValidatorsByConsAddr` + - checks if the validator is does not exceed parameter `MaxConsPubKeyRotations` by iterating `ConsPubKeyRotationHistory` + - checks if the signing account has enough balance to pay `KeyRotationFee` + - pays `KeyRotationFee` to community fund + - overwrites `NewPubKey` in `validator.ConsPubKey` + - deletes old `ValidatorByConsAddr` + - `SetValidatorByConsAddr` for `NewPubKey` + - Add `ConsPubKeyRotationHistory` for tracking rotation + + ```go + type ConsPubKeyRotationHistory struct { + OperatorAddress sdk.ValAddress + OldConsPubKey crypto.PubKey + NewConsPubKey crypto.PubKey + RotatedHeight int64 + } + ``` + +5. `ApplyAndReturnValidatorSetUpdates` checks if there is `ConsPubKeyRotationHistory` with `ConsPubKeyRotationHistory.RotatedHeight == ctx.BlockHeight()` and if so, generates 2 `ValidatorUpdate` , one for a remove validator and one for create new validator + + ```go + abci.ValidatorUpdate{ + PubKey: tmtypes.TM2PB.PubKey(OldConsPubKey), + Power: 0, + } + + abci.ValidatorUpdate{ + PubKey: tmtypes.TM2PB.PubKey(NewConsPubKey), + Power: v.ConsensusPower(), + } + ``` + +6. at `previousVotes` Iteration logic of `AllocateTokens`, `previousVote` using `OldConsPubKey` match up with `ConsPubKeyRotationHistory`, and replace validator for token allocation +7. Migrate `ValidatorSigningInfo` and `ValidatorMissedBlockBitArray` from `OldConsPubKey` to `NewConsPubKey` + +- Note : All above features shall be implemented in `staking` module. + +## Status + +Proposed + +## Consequences + +### Positive + +- Validators can immediately or periodically rotate their consensus key to have better security policy +- improved security against Long-Range attacks (https://nearprotocol.com/blog/long-range-attacks-and-a-new-fork-choice-rule) given a validator throws away the old consensus key(s) + +### Negative + +- Slash module needs more computation because it needs to lookup corresponding consensus key of validators for each height +- frequent key rotations will make light client bisection less efficient + +### Neutral + +## References + +- on tendermint repo : https://github.com/tendermint/tendermint/issues/1136 +- on cosmos-sdk repo : https://github.com/cosmos/cosmos-sdk/issues/5231 +- about multiple consensus keys : https://github.com/tendermint/tendermint/issues/1758#issuecomment-545291698 diff --git a/versioned_docs/version-0.45/integrate/architecture/adr-017-historical-header-module.md b/versioned_docs/version-0.45/integrate/architecture/adr-017-historical-header-module.md new file mode 100644 index 000000000..f0cdf4c07 --- /dev/null +++ b/versioned_docs/version-0.45/integrate/architecture/adr-017-historical-header-module.md @@ -0,0 +1,61 @@ +# ADR 17: Historical Header Module + +## Changelog + +- 26 November 2019: Start of first version +- 2 December 2019: Final draft of first version + +## Context + +In order for the Cosmos SDK to implement the [IBC specification](https://github.com/cosmos/ics), modules within the SDK must have the ability to introspect recent consensus states (validator sets & commitment roots) as proofs of these values on other chains must be checked during the handshakes. + +## Decision + +The application MUST store the most recent `n` headers in a persistent store. At first, this store MAY be the current Merklised store. A non-Merklised store MAY be used later as no proofs are necessary. + +The application MUST store this information by storing new headers immediately when handling `abci.RequestBeginBlock`: + +```golang +func BeginBlock(ctx sdk.Context, keeper HistoricalHeaderKeeper, req abci.RequestBeginBlock) abci.ResponseBeginBlock { + info := HistoricalInfo{ + Header: ctx.BlockHeader(), + ValSet: keeper.StakingKeeper.GetAllValidators(ctx), // note that this must be stored in a canonical order + } + keeper.SetHistoricalInfo(ctx, ctx.BlockHeight(), info) + n := keeper.GetParamRecentHeadersToStore() + keeper.PruneHistoricalInfo(ctx, ctx.BlockHeight() - n) + // continue handling request +} +``` + +Alternatively, the application MAY store only the hash of the validator set. + +The application MUST make these past `n` committed headers available for querying by SDK modules through the `Keeper`'s `GetHistoricalInfo` function. This MAY be implemented in a new module, or it MAY also be integrated into an existing one (likely `x/staking` or `x/ibc`). + +`n` MAY be configured as a parameter store parameter, in which case it could be changed by `ParameterChangeProposal`s, although it will take some blocks for the stored information to catch up if `n` is increased. + +## Status + +Proposed. + +## Consequences + +Implementation of this ADR will require changes to the Cosmos SDK. It will not require changes to Tendermint. + +### Positive + +- Easy retrieval of headers & state roots for recent past heights by modules anywhere in the SDK. +- No RPC calls to Tendermint required. +- No ABCI alterations required. + +### Negative + +- Duplicates `n` headers data in Tendermint & the application (additional disk usage) - in the long term, an approach such as [this](https://github.com/tendermint/tendermint/issues/4210) might be preferable. + +### Neutral + +(none known) + +## References + +- [ICS 2: "Consensus state introspection"](https://github.com/cosmos/ibc/tree/master/spec/core/ics-002-client-semantics#consensus-state-introspection) diff --git a/versioned_docs/version-0.45/integrate/architecture/adr-018-extendable-voting-period.md b/versioned_docs/version-0.45/integrate/architecture/adr-018-extendable-voting-period.md new file mode 100644 index 000000000..edd392b5e --- /dev/null +++ b/versioned_docs/version-0.45/integrate/architecture/adr-018-extendable-voting-period.md @@ -0,0 +1,66 @@ +# ADR 18: Extendable Voting Periods + +## Changelog + +- 1 January 2020: Start of first version + +## Context + +Currently the voting period for all governance proposals is the same. However, this is suboptimal as all governance proposals do not require the same time period. For more non-contentious proposals, they can be dealt with more efficently with a faster period, while more contentious or complex proposals may need a longer period for extended discussion/consideration. + +## Decision + +We would like to design a mechanism for making the voting period of a governance proposal variable based on the demand of voters. We would like it to be based on the view of the governance participants, rather than just the proposer of a governance proposal (thus, allowing the proposer to select the voting period length is not sufficient). + +However, we would like to avoid the creation of an entire second voting process to determine the length of the voting period, as it just pushed the problem to determining the length of that first voting period. + +Thus, we propose the following mechanism: + +### Params + +- The current gov param `VotingPeriod` is to be replaced by a `MinVotingPeriod` param. This is the the default voting period that all governance proposal voting periods start with. +- There is a new gov param called `MaxVotingPeriodExtension`. + +### Mechanism + +There is a new `Msg` type called `MsgExtendVotingPeriod`, which can be sent by any staked account during a proposal's voting period. It allows the sender to unilaterally extend the length of the voting period by `MaxVotingPeriodExtension * sender's share of voting power`. Every address can only call `MsgExtendVotingPeriod` once per proposal. + +So for example, if the `MaxVotingPeriodExtension` is set to 100 Days, then anyone with 1% of voting power can extend the voting power by 1 day. If 33% of voting power has sent the message, the voting period will be extended by 33 days. Thus, if absolutely everyone chooses to extend the voting period, the absolute maximum voting period will be `MinVotingPeriod + MaxVotingPeriodExtension`. + +This system acts as a sort of distributed coordination, where individual stakers choosing to extend or not, allows the system the guage the conentiousness/complexity of the proposal. It is extremely unlikely that many stakers will choose to extend at the exact same time, it allows stakers to view how long others have already extended thus far, to decide whether or not to extend further. + +### Dealing with Unbonding/Redelegation + +There is one thing that needs to be addressed. How to deal with redelegation/unbonding during the voting period. If a staker of 5% calls `MsgExtendVotingPeriod` and then unbonds, does the voting period then decrease by 5 days again? This is not good as it can give people a false sense of how long they have to make their decision. For this reason, we want to design it such that the voting period length can only be extended, not shortened. To do this, the current extension amount is based on the highest percent that voted extension at any time. This is best explained by example: + +1. Let's say 2 stakers of voting power 4% and 3% respectively vote to extend. The voting period will be extended by 7 days. +2. Now the staker of 3% decides to unbond before the end of the voting period. The voting period extension remains 7 days. +3. Now, let's say another staker of 2% voting power decides to extend voting period. There is now 6% of active voting power choosing the extend. The voting power remains 7 days. +4. If a fourth staker of 10% chooses to extend now, there is a total of 16% of active voting power wishing to extend. The voting period will be extended to 16 days. + +### Delegators + +Just like votes in the actual voting period, delegators automatically inherit the extension of their validators. If their validator chooses to extend, their voting power will be used in the validator's extension. However, the delegator is unable to override their validator and "unextend" as that would contradict the "voting power length can only be ratcheted up" principle described in the previous section. However, a delegator may choose the extend using their personal voting power, if their validator has not done so. + +## Status + +Proposed + +## Consequences + +### Positive + +- More complex/contentious governance proposals will have more time to properly digest and deliberate + +### Negative + +- Governance process becomes more complex and requires more understanding to interact with effectively +- Can no longer predict when a governance proposal will end. Can't assume order in which governance proposals will end. + +### Neutral + +- The minimum voting period can be made shorter + +## References + +- [Cosmos Forum post where idea first originated](https://forum.cosmos.network/t/proposal-draft-reduce-governance-voting-period-to-7-days/3032/9) diff --git a/versioned_docs/version-0.45/integrate/architecture/adr-019-protobuf-state-encoding.md b/versioned_docs/version-0.45/integrate/architecture/adr-019-protobuf-state-encoding.md new file mode 100644 index 000000000..cddf7092f --- /dev/null +++ b/versioned_docs/version-0.45/integrate/architecture/adr-019-protobuf-state-encoding.md @@ -0,0 +1,379 @@ +# ADR 019: Protocol Buffer State Encoding + +## Changelog + +- 2020 Feb 15: Initial Draft +- 2020 Feb 24: Updates to handle messages with interface fields +- 2020 Apr 27: Convert usages of `oneof` for interfaces to `Any` +- 2020 May 15: Describe `cosmos_proto` extensions and amino compatibility +- 2020 Dec 4: Move and rename `MarshalAny` and `UnmarshalAny` into the `codec.Codec` interface. +- 2021 Feb 24: Remove mentions of `HybridCodec`, which has been abandoned in [#6843](https://github.com/cosmos/cosmos-sdk/pull/6843). + +## Status + +Accepted + +## Context + +Currently, the Cosmos SDK utilizes [go-amino](https://github.com/tendermint/go-amino/) for binary +and JSON object encoding over the wire bringing parity between logical objects and persistence objects. + +From the Amino docs: + +> Amino is an object encoding specification. It is a subset of Proto3 with an extension for interface +> support. See the [Proto3 spec](https://developers.google.com/protocol-buffers/docs/proto3) for more +> information on Proto3, which Amino is largely compatible with (but not with Proto2). +> +> The goal of the Amino encoding protocol is to bring parity into logic objects and persistence objects. + +Amino also aims to have the following goals (not a complete list): + +- Binary bytes must be decode-able with a schema. +- Schema must be upgradeable. +- The encoder and decoder logic must be reasonably simple. + +However, we believe that Amino does not fulfill these goals completely and does not fully meet the +needs of a truly flexible cross-language and multi-client compatible encoding protocol in the Cosmos SDK. +Namely, Amino has proven to be a big pain-point in regards to supporting object serialization across +clients written in various languages while providing virtually little in the way of true backwards +compatibility and upgradeability. Furthermore, through profiling and various benchmarks, Amino has +been shown to be an extremely large performance bottleneck in the Cosmos SDK 1. This is +largely reflected in the performance of simulations and application transaction throughput. + +Thus, we need to adopt an encoding protocol that meets the following criteria for state serialization: + +- Language agnostic +- Platform agnostic +- Rich client support and thriving ecosystem +- High performance +- Minimal encoded message size +- Codegen-based over reflection-based +- Supports backward and forward compatibility + +Note, migrating away from Amino should be viewed as a two-pronged approach, state and client encoding. +This ADR focuses on state serialization in the Cosmos SDK state machine. A corresponding ADR will be +made to address client-side encoding. + +## Decision + +We will adopt [Protocol Buffers](https://developers.google.com/protocol-buffers) for serializing +persisted structured data in the Cosmos SDK while providing a clean mechanism and developer UX for +applications wishing to continue to use Amino. We will provide this mechanism by updating modules to +accept a codec interface, `Marshaler`, instead of a concrete Amino codec. Furthermore, the Cosmos SDK +will provide two concrete implementations of the `Marshaler` interface: `AminoCodec` and `ProtoCodec`. + +- `AminoCodec`: Uses Amino for both binary and JSON encoding. +- `ProtoCodec`: Uses Protobuf for both binary and JSON encoding. + +Modules will use whichever codec that is instantiated in the app. By default, the 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. + +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 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. + +### 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. + +Note, any business logic that needs to encode primitive types like `bool` or `int64` should use +[gogoprotobuf](https://github.com/gogo/protobuf) Value types. + +Example: + +```go + ts, err := gogotypes.TimestampProto(completionTime) + if err != nil { + // ... + } + + bz := cdc.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. + +Example: + +```go +// x/auth/types/codec.go + +type Codec interface { + codec.Codec + + MarshalAccount(acc exported.Account) ([]byte, error) + UnmarshalAccount(bz []byte) (exported.Account, error) + + MarshalAccountJSON(acc exported.Account) ([]byte, error) + UnmarshalAccountJSON(bz []byte) (exported.Account, error) +} +``` + +### Usage of `Any` to encode interfaces + +In general, module-level .proto files should define messages which encode interfaces +using [`google.protobuf.Any`](https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/any.proto). +After [extension discussion](https://github.com/cosmos/cosmos-sdk/issues/6030), +this was chosen as the preferred alternative to application-level `oneof`s +as in our original protobuf design. The arguments in favor of `Any` can be +summarized as follows: + +* `Any` provides a simpler, more consistent client UX for dealing with +interfaces than app-level `oneof`s that will need to be coordinated more +carefully across applications. Creating a generic transaction +signing library using `oneof`s may be cumbersome and critical logic may need +to be reimplemented for each chain +* `Any` provides more resistance against human error than `oneof` +* `Any` is generally simpler to implement for both modules and apps + +The main counter-argument to using `Any` centers around its additional space +and possibly performance overhead. The space overhead could be dealt with using +compression at the persistence layer in the future and the performance impact +is likely to be small. Thus, not using `Any` is seem as a pre-mature optimization, +with user experience as the higher order concern. + +Note, that given the SDK's decision to adopt the `Codec` interfaces described +above, apps can still choose to use `oneof` to encode state and transactions +but it is not the recommended approach. If apps do choose to use `oneof`s +instead of `Any` they will likely lose compatibility with client apps that +support multiple chains. Thus developers should think carefully about whether +they care more about what is possibly a pre-mature optimization or end-user +and client developer UX. + +### Safe usage of `Any` + +By default, the [gogo protobuf implementation of `Any`](https://godoc.org/github.com/gogo/protobuf/types) +uses [global type registration]( https://github.com/gogo/protobuf/blob/master/proto/properties.go#L540) +to decode values packed in `Any` into concrete +go types. This introduces a vulnerability where any malicious module +in the dependency tree could registry a type with the global protobuf registry +and cause it to be loaded and unmarshaled by a transaction that referenced +it in the `type_url` field. + +To prevent this, we introduce a type registration mechanism for decoding `Any` +values into concrete types through the `InterfaceRegistry` interface which +bears some similarity to type registration with Amino: + +```go +type InterfaceRegistry interface { + // RegisterInterface associates protoName as the public name for the + // interface passed in as iface + // Ex: + // registry.RegisterInterface("cosmos_sdk.Msg", (*sdk.Msg)(nil)) + RegisterInterface(protoName string, iface interface{}) + + // RegisterImplementations registers impls as a concrete implementations of + // the interface iface + // Ex: + // registry.RegisterImplementations((*sdk.Msg)(nil), &MsgSend{}, &MsgMultiSend{}) + RegisterImplementations(iface interface{}, impls ...proto.Message) + +} +``` + +In addition to serving as a whitelist, `InterfaceRegistry` can also serve +to communicate the list of concrete types that satisfy an interface to clients. + +In .proto files: + +* fields which accept interfaces should be annotated with `cosmos_proto.accepts_interface` +using the same full-qualified name passed as `protoName` to `InterfaceRegistry.RegisterInterface` +* interface implementations should be annotated with `cosmos_proto.implements_interface` +using the same full-qualified name passed as `protoName` to `InterfaceRegistry.RegisterInterface` + +In the future, `protoName`, `cosmos_proto.accepts_interface`, `cosmos_proto.implements_interface` +may be used via code generation, reflection &/or static linting. + +The same struct that implements `InterfaceRegistry` will also implement an +interface `InterfaceUnpacker` to be used for unpacking `Any`s: + +```go +type InterfaceUnpacker interface { + // UnpackAny unpacks the value in any to the interface pointer passed in as + // iface. Note that the type in any must have been registered with + // RegisterImplementations as a concrete type for that interface + // Ex: + // var msg sdk.Msg + // err := ctx.UnpackAny(any, &msg) + // ... + UnpackAny(any *Any, iface interface{}) error +} +``` + +Note that `InterfaceRegistry` usage does not deviate from standard protobuf +usage of `Any`, it just introduces a security and introspection layer for +golang usage. + +`InterfaceRegistry` will be a member of `ProtoCodec` +described above. In order for modules to register interface types, app modules +can optionally implement the following interface: + +```go +type InterfaceModule interface { + RegisterInterfaceTypes(InterfaceRegistry) +} +``` + +The module manager will include a method to call `RegisterInterfaceTypes` on +every module that implements it in order to populate the `InterfaceRegistry`. + +### Using `Any` to encode state + +The SDK will provide support methods `MarshalInterface` and `UnmarshalInterface` to hide a complexity of wrapping interface types into `Any` and allow easy serialization. + +```go +import "github.com/cosmos/cosmos-sdk/codec" + +// note: eviexported.Evidence is an interface type +func MarshalEvidence(cdc codec.BinaryCodec, e eviexported.Evidence) ([]byte, error) { + return cdc.MarshalInterface(e) +} + +func UnmarshalEvidence(cdc codec.BinaryCodec, bz []byte) (eviexported.Evidence, error) { + var evi eviexported.Evidence + err := cdc.UnmarshalInterface(&evi, bz) + return err, nil +} +``` + +### Using `Any` in `sdk.Msg`s + +A similar concept is to be applied for messages that contain interfaces fields. +For example, we can define `MsgSubmitEvidence` as follows where `Evidence` is +an interface: + +```protobuf +// x/evidence/types/types.proto + +message MsgSubmitEvidence { + bytes submitter = 1 + [ + (gogoproto.casttype) = "github.com/cosmos/cosmos-sdk/types.AccAddress" + ]; + google.protobuf.Any evidence = 2; +} +``` + +Note that in order to unpack the evidence from `Any` we do need a reference to +`InterfaceRegistry`. In order to reference evidence in methods like +`ValidateBasic` which shouldn't have to know about the `InterfaceRegistry`, we +introduce an `UnpackInterfaces` phase to deserialization which unpacks +interfaces before they're needed. + +### Unpacking Interfaces + +To implement the `UnpackInterfaces` phase of deserialization which unpacks +interfaces wrapped in `Any` before they're needed, we create an interface +that `sdk.Msg`s and other types can implement: + +```go +type UnpackInterfacesMessage interface { + UnpackInterfaces(InterfaceUnpacker) error +} +``` + +We also introduce a private `cachedValue interface{}` field onto the `Any` +struct itself with a public getter `GetCachedValue() interface{}`. + +The `UnpackInterfaces` method is to be invoked during message deserialization right +after `Unmarshal` and any interface values packed in `Any`s will be decoded +and stored in `cachedValue` for reference later. + +Then unpacked interface values can safely be used in any code afterwards +without knowledge of the `InterfaceRegistry` +and messages can introduce a simple getter to cast the cached value to the +correct interface type. + +This has the added benefit that unmarshaling of `Any` values only happens once +during initial deserialization rather than every time the value is read. Also, +when `Any` values are first packed (for instance in a call to +`NewMsgSubmitEvidence`), the original interface value is cached so that +unmarshaling isn't needed to read it again. + +`MsgSubmitEvidence` could implement `UnpackInterfaces`, plus a convenience getter +`GetEvidence` as follows: + +```go +func (msg MsgSubmitEvidence) UnpackInterfaces(ctx sdk.InterfaceRegistry) error { + var evi eviexported.Evidence + return ctx.UnpackAny(msg.Evidence, *evi) +} + +func (msg MsgSubmitEvidence) GetEvidence() eviexported.Evidence { + return msg.Evidence.GetCachedValue().(eviexported.Evidence) +} +``` + +### Amino Compatibility + +Our custom implementation of `Any` can be used transparently with Amino if used +with the proper codec instance. What this means is that interfaces packed within +`Any`s will be amino marshaled like regular Amino interfaces (assuming they +have been registered properly with Amino). + +In order for this functionality to work: + +- **all legacy code must use `*codec.LegacyAmino` instead of `*amino.Codec` which is + now a wrapper which properly handles `Any`** +- **all new code should use `Marshaler` which is compatible with both amino and + protobuf** +- Also, before v0.39, `codec.LegacyAmino` will be renamed to `codec.LegacyAmino`. + +### Why Wasn't X Chosen Instead + +For a more complete comparison to alternative protocols, see [here](https://codeburst.io/json-vs-protocol-buffers-vs-flatbuffers-a4247f8bda6f). + +### Cap'n Proto + +While [Cap’n Proto](https://capnproto.org/) does seem like an advantageous alternative to Protobuf +due to it's native support for interfaces/generics and built in canonicalization, it does lack the +rich client ecosystem compared to Protobuf and is a bit less mature. + +### FlatBuffers + +[FlatBuffers](https://google.github.io/flatbuffers/) is also a potentially viable alternative, with the +primary difference being that FlatBuffers does not need a parsing/unpacking step to a secondary +representation before you can access data, often coupled with per-object memory allocation. + +However, it would require great efforts into research and full understanding the scope of the migration +and path forward -- which isn't immediately clear. In addition, FlatBuffers aren't designed for +untrusted inputs. + +## Future Improvements & Roadmap + +In the future we may consider a compression layer right above the persistence +layer which doesn't change tx or merkle tree hashes, but reduces the storage +overhead of `Any`. In addition, we may adopt protobuf naming conventions which +make type URLs a bit more concise while remaining descriptive. + +Additional code generation support around the usage of `Any` is something that +could also be explored in the future to make the UX for go developers more +seamless. + +## Consequences + +### Positive + +- Significant performance gains. +- Supports backward and forward type compatibility. +- Better support for cross-language clients. + +### Negative + +- Learning curve required to understand and implement Protobuf messages. +- Slightly larger message size due to use of `Any`, although this could be offset + by a compression layer in the future + +### Neutral + +## References + +1. https://github.com/cosmos/cosmos-sdk/issues/4977 +2. https://github.com/cosmos/cosmos-sdk/issues/5444 diff --git a/versioned_docs/version-0.45/integrate/architecture/adr-020-protobuf-transaction-encoding.md b/versioned_docs/version-0.45/integrate/architecture/adr-020-protobuf-transaction-encoding.md new file mode 100644 index 000000000..2efe583cf --- /dev/null +++ b/versioned_docs/version-0.45/integrate/architecture/adr-020-protobuf-transaction-encoding.md @@ -0,0 +1,464 @@ +# ADR 020: Protocol Buffer Transaction Encoding + +## Changelog + +- 2020 March 06: Initial Draft +- 2020 March 12: API Updates +- 2020 April 13: Added details on interface `oneof` handling +- 2020 April 30: Switch to `Any` +- 2020 May 14: Describe public key encoding +- 2020 June 08: Store `TxBody` and `AuthInfo` as bytes in `SignDoc`; Document `TxRaw` as broadcast and storage type. +- 2020 August 07: Use ADR 027 for serializing `SignDoc`. +- 2020 August 19: Move sequence field from `SignDoc` to `SignerInfo`, as discussed in [#6966](https://github.com/cosmos/cosmos-sdk/issues/6966). +- 2020 September 25: Remove `PublicKey` type in favor of `secp256k1.PubKey`, `ed25519.PubKey` and `multisig.LegacyAminoPubKey`. +- 2020 October 15: Add `GetAccount` and `GetAccountWithHeight` methods to the `AccountRetriever` interface. +- 2021 Feb 24: The 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`. + +## Status + +Accepted + +## Context + +This ADR is a continuation of the motivation, design, and context established in +[ADR 019](./adr-019-protobuf-state-encoding.md), namely, we aim to design the +Protocol Buffer migration path for the client-side of the Cosmos SDK. + +Specifically, the client-side migration path primarily includes tx generation and +signing, message construction and routing, in addition to CLI & REST handlers and +business logic (i.e. queriers). + +With this in mind, we will tackle the migration path via two main areas, txs and +querying. However, this ADR solely focuses on transactions. Querying should be +addressed in a future ADR, but it should build off of these proposals. + +Based on detailed discussions ([\#6030](https://github.com/cosmos/cosmos-sdk/issues/6030) +and [\#6078](https://github.com/cosmos/cosmos-sdk/issues/6078)), the original +design for transactions was changed substantially from an `oneof` /JSON-signing +approach to the approach described below. + +## Decision + +### Transactions + +Since interface values are encoded with `google.protobuf.Any` in state (see [ADR 019](adr-019-protobuf-state-encoding.md)), +`sdk.Msg`s are encoding with `Any` in transactions. + +One of the main goals of using `Any` to encode interface values is to have a +core set of types which is reused by apps so that +clients can safely be compatible with as many chains as possible. + +It is one of the goals of this specification to provide a flexible cross-chain transaction +format that can serve a wide variety of use cases without breaking client +compatibility. + +In order to facilitate signing, transactions are separated into `TxBody`, +which will be re-used by `SignDoc` below, and `signatures`: + +```proto +// types/types.proto +package cosmos_sdk.v1; + +message Tx { + TxBody body = 1; + AuthInfo auth_info = 2; + // A list of signatures that matches the length and order of AuthInfo's signer_infos to + // allow connecting signature meta information like public key and signing mode by position. + repeated bytes signatures = 3; +} + +// A variant of Tx that pins the signer's exact binary represenation of body and +// auth_info. This is used for signing, broadcasting and verification. The binary +// `serialize(tx: TxRaw)` is stored in Tendermint and the hash `sha256(serialize(tx: TxRaw))` +// becomes the "txhash", commonly used as the transaction ID. +message TxRaw { + // A protobuf serialization of a TxBody that matches the representation in SignDoc. + bytes body = 1; + // A protobuf serialization of an AuthInfo that matches the representation in SignDoc. + bytes auth_info = 2; + // A list of signatures that matches the length and order of AuthInfo's signer_infos to + // allow connecting signature meta information like public key and signing mode by position. + repeated bytes signatures = 3; +} + +message TxBody { + // A list of messages to be executed. The required signers of those messages define + // the number and order of elements in AuthInfo's signer_infos and Tx's signatures. + // Each required signer address is added to the list only the first time it occurs. + // + // By convention, the first required signer (usually from the first message) is referred + // to as the primary signer and pays the fee for the whole transaction. + repeated google.protobuf.Any messages = 1; + string memo = 2; + int64 timeout_height = 3; + repeated google.protobuf.Any extension_options = 1023; +} + +message AuthInfo { + // This list defines the signing modes for the required signers. The number + // and order of elements must match the required signers from TxBody's messages. + // The first element is the primary signer and the one which pays the fee. + repeated SignerInfo signer_infos = 1; + // The fee can be calculated based on the cost of evaluating the body and doing signature verification of the signers. This can be estimated via simulation. + Fee fee = 2; +} + +message SignerInfo { + // The public key is optional for accounts that already exist in state. If unset, the + // verifier can use the required signer address for this position and lookup the public key. + google.protobuf.Any public_key = 1; + // ModeInfo describes the signing mode of the signer and is a nested + // structure to support nested multisig pubkey's + ModeInfo mode_info = 2; + // sequence is the sequence of the account, which describes the + // number of committed transactions signed by a given address. It is used to prevent + // replay attacks. + uint64 sequence = 3; +} + +message ModeInfo { + oneof sum { + Single single = 1; + Multi multi = 2; + } + + // Single is the mode info for a single signer. It is structured as a message + // to allow for additional fields such as locale for SIGN_MODE_TEXTUAL in the future + message Single { + SignMode mode = 1; + } + + // Multi is the mode info for a multisig public key + message Multi { + // bitarray specifies which keys within the multisig are signing + CompactBitArray bitarray = 1; + // mode_infos is the corresponding modes of the signers of the multisig + // which could include nested multisig public keys + repeated ModeInfo mode_infos = 2; + } +} + +enum SignMode { + SIGN_MODE_UNSPECIFIED = 0; + + SIGN_MODE_DIRECT = 1; + + SIGN_MODE_TEXTUAL = 2; + + SIGN_MODE_LEGACY_AMINO_JSON = 127; +} +``` + +As will be discussed below, in order to include as much of the `Tx` as possible +in the `SignDoc`, `SignerInfo` is separated from signatures so that only the +raw signatures themselves live outside of what is signed over. + +Because we are aiming for a flexible, extensible cross-chain transaction +format, new transaction processing options should be added to `TxBody` as soon +those use cases are discovered, even if they can't be implemented yet. + +Because there is coordination overhead in this, `TxBody` includes an +`extension_options` field which can be used for any transaction processing +options that are not already covered. App developers should, nevertheless, +attempt to upstream important improvements to `Tx`. + +### Signing + +All of the signing modes below aim to provide the following guarantees: + +- **No Malleability**: `TxBody` and `AuthInfo` cannot change once the transaction + is signed +- **Predictable Gas**: if I am signing a transaction where I am paying a fee, + the final gas is fully dependent on what I am signing + +These guarantees give the maximum amount confidence to message signers that +manipulation of `Tx`s by intermediaries can't result in any meaningful changes. + +#### `SIGN_MODE_DIRECT` + +The "direct" signing behavior is to sign the raw `TxBody` bytes as broadcast over +the wire. This has the advantages of: + +- requiring the minimum additional client capabilities beyond a standard protocol + buffers implementation +- leaving effectively zero holes for transaction malleability (i.e. there are no + subtle differences between the signing and encoding formats which could + potentially be exploited by an attacker) + +Signatures are structured using the `SignDoc` below which reuses the serialization of +`TxBody` and `AuthInfo` and only adds the fields which are needed for signatures: + +```proto +// types/types.proto +message SignDoc { + // A protobuf serialization of a TxBody that matches the representation in TxRaw. + bytes body = 1; + // A protobuf serialization of an AuthInfo that matches the representation in TxRaw. + bytes auth_info = 2; + string chain_id = 3; + uint64 account_number = 4; +} +``` + +In order to sign in the default mode, clients take the following steps: + +1. Serialize `TxBody` and `AuthInfo` using any valid protobuf implementation. +2. Create a `SignDoc` and serialize it using [ADR 027](./adr-027-deterministic-protobuf-serialization.md). +3. Sign the encoded `SignDoc` bytes. +4. Build a `TxRaw` and serialize it for broadcasting. + +Signature verification is based on comparing the raw `TxBody` and `AuthInfo` +bytes encoded in `TxRaw` not based on any ["canonicalization"](https://github.com/regen-network/canonical-proto3) +algorithm which creates added complexity for clients in addition to preventing +some forms of upgradeability (to be addressed later in this document). + +Signature verifiers do: + +1. Deserialize a `TxRaw` and pull out `body` and `auth_info`. +2. Create a list of required signer addresses from the messages. +3. For each required signer: + - Pull account number and sequence from the state. + - Obtain the public key either from state or `AuthInfo`'s `signer_infos`. + - Create a `SignDoc` and serialize it using [ADR 027](./adr-027-deterministic-protobuf-serialization.md). + - Verify the signature at the the same list position against the serialized `SignDoc`. + +#### `SIGN_MODE_LEGACY_AMINO` + +In order to support legacy wallets and exchanges, Amino JSON will be temporarily +supported transaction signing. Once wallets and exchanges have had a +chance to upgrade to protobuf based signing, this option will be disabled. In +the meantime, it is foreseen that disabling the current Amino signing would cause +too much breakage to be feasible. Note that this is mainly a requirement of the +Cosmos Hub and other chains may choose to disable Amino signing immediately. + +Legacy clients will be able to sign a transaction using the current Amino +JSON format and have it encoded to protobuf using the REST `/tx/encode` +endpoint before broadcasting. + +#### `SIGN_MODE_TEXTUAL` + +As was discussed extensively in [\#6078](https://github.com/cosmos/cosmos-sdk/issues/6078), +there is a desire for a human-readable signing encoding, especially for hardware +wallets like the [Ledger](https://www.ledger.com) which display +transaction contents to users before signing. JSON was an attempt at this but +falls short of the ideal. + +`SIGN_MODE_TEXTUAL` is intended as a placeholder for a human-readable +encoding which will replace Amino JSON. This new encoding should be even more +focused on readability than JSON, possibly based on formatting strings like +[MessageFormat](http://userguide.icu-project.org/formatparse/messages). + +In order to ensure that the new human-readable format does not suffer from +transaction malleability issues, `SIGN_MODE_TEXTUAL` +requires that the _human-readable bytes are concatenated with the raw `SignDoc`_ +to generate sign bytes. + +Multiple human-readable formats (maybe even localized messages) may be supported +by `SIGN_MODE_TEXTUAL` when it is implemented. + +### Unknown Field Filtering + +Unknown fields in protobuf messages should generally be rejected by transaction +processors because: + +- important data may be present in the unknown fields, that if ignored, will + cause unexpected behavior for clients +- they present a malleability vulnerability where attackers can bloat tx size + by adding random uninterpreted data to unsigned content (i.e. the master `Tx`, + not `TxBody`) + +There are also scenarios where we may choose to safely ignore unknown fields +(https://github.com/cosmos/cosmos-sdk/issues/6078#issuecomment-624400188) to +provide graceful forwards compatibility with newer clients. + +We propose that field numbers with bit 11 set (for most use cases this is +the range of 1024-2047) be considered non-critical fields that can safely be +ignored if unknown. + +To handle this we will need a unknown field filter that: + +- always rejects unknown fields in unsigned content (i.e. top-level `Tx` and + unsigned parts of `AuthInfo` if present based on the signing mode) +- rejects unknown fields in all messages (including nested `Any`s) other than + fields with bit 11 set + +This will likely need to be a custom protobuf parser pass that takes message bytes +and `FileDescriptor`s and returns a boolean result. + +### Public Key Encoding + +Public keys in the Cosmos SDK implement 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: + +```proto +message PubKey { + bytes key = 1; +} +``` + +`multisig.LegacyAminoPubKey` has an array of `Any`'s member to support any +protobuf public key type. + +Apps should only attempt to handle a registered set of public keys that they +have tested. The provided signature verification ante handler decorators will +enforce this. + +### CLI & REST + +Currently, the REST and CLI handlers encode and decode types and txs via Amino +JSON encoding using a concrete Amino codec. Being that some of the types dealt with +in the client can be interfaces, similar to how we described in [ADR 019](./adr-019-protobuf-state-encoding.md), +the client logic will now need to take a codec interface that knows not only how +to handle all the types, but also knows how to generate transactions, signatures, +and messages. + +```go +type AccountRetriever interface { + GetAccount(clientCtx Context, addr sdk.AccAddress) (client.Account, error) + GetAccountWithHeight(clientCtx Context, addr sdk.AccAddress) (client.Account, int64, error) + EnsureExists(clientCtx client.Context, addr sdk.AccAddress) error + GetAccountNumberSequence(clientCtx client.Context, addr sdk.AccAddress) (uint64, uint64, error) +} + +type Generator interface { + NewTx() TxBuilder + NewFee() ClientFee + NewSignature() ClientSignature + MarshalTx(tx types.Tx) ([]byte, error) +} + +type TxBuilder interface { + GetTx() sdk.Tx + + SetMsgs(...sdk.Msg) error + GetSignatures() []sdk.Signature + SetSignatures(...sdk.Signature) + GetFee() sdk.Fee + SetFee(sdk.Fee) + GetMemo() string + SetMemo(string) +} +``` + +We then update `Context` to have new fields: `Codec`, `TxGenerator`, +and `AccountRetriever`, and we update `AppModuleBasic.GetTxCmd` to take +a `Context` which should have all of these fields pre-populated. + +Each client method should then use one of the `Init` methods to re-initialize +the pre-populated `Context`. `tx.GenerateOrBroadcastTx` can be used to +generate or broadcast a transaction. For example: + +```go +import "github.com/spf13/cobra" +import "github.com/cosmos/cosmos-sdk/client" +import "github.com/cosmos/cosmos-sdk/client/tx" + +func NewCmdDoSomething(clientCtx client.Context) *cobra.Command { + return &cobra.Command{ + RunE: func(cmd *cobra.Command, args []string) error { + clientCtx := ctx.InitWithInput(cmd.InOrStdin()) + msg := NewSomeMsg{...} + tx.GenerateOrBroadcastTx(clientCtx, msg) + }, + } +} +``` + +## Future Improvements + +### `SIGN_MODE_TEXTUAL` specification + +A concrete specification and implementation of `SIGN_MODE_TEXTUAL` is intended +as a near-term future improvement so that the ledger app and other wallets +can gracefully transition away from Amino JSON. + +### `SIGN_MODE_DIRECT_AUX` + +(\*Documented as option (3) in https://github.com/cosmos/cosmos-sdk/issues/6078#issuecomment-628026933) + +We could add a mode `SIGN_MODE_DIRECT_AUX` +to support scenarios where multiple signatures +are being gathered into a single transaction but the message composer does not +yet know which signatures will be included in the final transaction. For instance, +I may have a 3/5 multisig wallet and want to send a `TxBody` to all 5 +signers to see who signs first. As soon as I have 3 signatures then I will go +ahead and build the full transaction. + +With `SIGN_MODE_DIRECT`, each signer needs +to sign the full `AuthInfo` which includes the full list of all signers and +their signing modes, making the above scenario very hard. + +`SIGN_MODE_DIRECT_AUX` would allow "auxiliary" signers to create their signature +using only `TxBody` and their own `PublicKey`. This allows the full list of +signers in `AuthInfo` to be delayed until signatures have been collected. + +An "auxiliary" signer is any signer besides the primary signer who is paying +the fee. For the primary signer, the full `AuthInfo` is actually needed to calculate gas and fees +because that is dependent on how many signers and which key types and signing +modes they are using. Auxiliary signers, however, do not need to worry about +fees or gas and thus can just sign `TxBody`. + +To generate a signature in `SIGN_MODE_DIRECT_AUX` these steps would be followed: + +1. Encode `SignDocAux` (with the same requirement that fields must be serialized + in order): + +```proto +// types/types.proto +message SignDocAux { + bytes body_bytes = 1; + // PublicKey is included in SignDocAux : + // 1. as a special case for multisig public keys. For multisig public keys, + // the signer should use the top-level multisig public key they are signing + // against, not their own public key. This is to prevent against a form + // of malleability where a signature could be taken out of context of the + // multisig key that was intended to be signed for + // 2. to guard against scenario where configuration information is encoded + // in public keys (it has been proposed) such that two keys can generate + // the same signature but have different security properties + // + // By including it here, the composer of AuthInfo cannot reference the + // a public key variant the signer did not intend to use + PublicKey public_key = 2; + string chain_id = 3; + uint64 account_number = 4; +} +``` + +2. Sign the encoded `SignDocAux` bytes +3. Send their signature and `SignerInfo` to primary signer who will then + sign and broadcast the final transaction (with `SIGN_MODE_DIRECT` and `AuthInfo` + added) once enough signatures have been collected + +### `SIGN_MODE_DIRECT_RELAXED` + +(_Documented as option (1)(a) in https://github.com/cosmos/cosmos-sdk/issues/6078#issuecomment-628026933_) + +This is a variation of `SIGN_MODE_DIRECT` where multiple signers wouldn't need to +coordinate public keys and signing modes in advance. It would involve an alternate +`SignDoc` similar to `SignDocAux` above with fee. This could be added in the future +if client developers found the burden of collecting public keys and modes in advance +too burdensome. + +## Consequences + +### Positive + +- Significant performance gains. +- Supports backward and forward type compatibility. +- Better support for cross-language clients. +- Multiple signing modes allow for greater protocol evolution + +### Negative + +- `google.protobuf.Any` type URLs increase transaction size although the effect + may be negligible or compression may be able to mitigate it. + +### Neutral + +## References diff --git a/versioned_docs/version-0.45/integrate/architecture/adr-021-protobuf-query-encoding.md b/versioned_docs/version-0.45/integrate/architecture/adr-021-protobuf-query-encoding.md new file mode 100644 index 000000000..60830de3c --- /dev/null +++ b/versioned_docs/version-0.45/integrate/architecture/adr-021-protobuf-query-encoding.md @@ -0,0 +1,256 @@ +# ADR 021: Protocol Buffer Query Encoding + +## Changelog + +- 2020 March 27: Initial Draft + +## Status + +Accepted + +## Context + +This ADR is a continuation of the motivation, design, and context established in +[ADR 019](./adr-019-protobuf-state-encoding.md) and +[ARD 020](./adr-019-protobuf-transaction-encoding.md), namely, we aim to design the +Protocol Buffer migration path for the client-side of the Cosmos SDK. + +This ADR continues from [ARD 020](./adr-020-protobuf-transaction-encoding.md) +to specify the encoding of queries. + +## Decision + +### Custom Query Definition + +Modules define custom queries through a protocol buffers `service` definition. +These `service` definitions are generally associated with and used by the +GRPC protocol. However, the protocol buffers specification indicates that +they can be used more generically by any request/response protocol that uses +protocol buffer encoding. Thus, we can use `service` definitions for specifying +custom ABCI queries and even reuse a substantial amount of the GRPC infrastructure. + +Each module with custom queries should define a service canonically named `Query`: + +```proto +// x/bank/types/types.proto + +service Query { + rpc QueryBalance(QueryBalanceParams) returns (cosmos_sdk.v1.Coin) { } + rpc QueryAllBalances(QueryAllBalancesParams) returns (QueryAllBalancesResponse) { } +} +``` + +#### Handling of Interface Types + +Modules that use interface types and need true polymorphism generally force a +`oneof` up to the app-level that provides the set of concrete implementations of +that interface that the app supports. While app's are welcome to do the same for +queries and implement an app-level query service, it is recommended that modules +provide query methods that expose these interfaces via `google.protobuf.Any`. +There is a concern on the transaction level that the overhead of `Any` is too +high to justify its usage. However for queries this is not a concern, and +providing generic module-level queries that use `Any` does not preclude apps +from also providing app-level queries that return use the app-level `oneof`s. + +A hypothetical example for the `gov` module would look something like: + +```proto +// x/gov/types/types.proto + +import "google/protobuf/any.proto"; + +service Query { + rpc GetProposal(GetProposalParams) returns (AnyProposal) { } +} + +message AnyProposal { + ProposalBase base = 1; + google.protobuf.Any content = 2; +} +``` + +### Custom Query Implementation + +In order to implement the query service, we can reuse the existing [gogo protobuf](https://github.com/gogo/protobuf) +grpc plugin, which for a service named `Query` generates an interface named +`QueryServer` as below: + +```go +type QueryServer interface { + QueryBalance(context.Context, *QueryBalanceParams) (*types.Coin, error) + QueryAllBalances(context.Context, *QueryAllBalancesParams) (*QueryAllBalancesResponse, error) +} +``` + +The custom queries for our module are implemented by implementing this interface. + +The first parameter in this generated interface is a generic `context.Context`, +whereas querier methods generally need an instance of `sdk.Context` to read +from the store. Since arbitrary values can be attached to `context.Context` +using the `WithValue` and `Value` methods, the SDK should provide a function +`sdk.UnwrapSDKContext` to retrieve the `sdk.Context` from the provided +`context.Context`. + +An example implementation of `QueryBalance` for the bank module as above would +look something like: + +```go +type Querier struct { + Keeper +} + +func (q Querier) QueryBalance(ctx context.Context, params *types.QueryBalanceParams) (*sdk.Coin, error) { + balance := q.GetBalance(sdk.UnwrapSDKContext(ctx), params.Address, params.Denom) + return &balance, nil +} +``` + +### Custom Query Registration and Routing + +Query server implementations as above would be registered with `AppModule`s using +a new method `RegisterQueryService(grpc.Server)` which could be implemented simply +as below: + +```go +// x/bank/module.go +func (am AppModule) RegisterQueryService(server grpc.Server) { + types.RegisterQueryServer(server, keeper.Querier{am.keeper}) +} +``` + +Underneath the hood, a new method `RegisterService(sd *grpc.ServiceDesc, handler interface{})` +will be added to the existing `baseapp.QueryRouter` to add the queries to the custom +query routing table (with the routing method being described below). +The signature for this method matches the existing +`RegisterServer` method on the GRPC `Server` type where `handler` is the custom +query server implementation described above. + +GRPC-like requests are routed by the service name (ex. `cosmos_sdk.x.bank.v1.Query`) +and method name (ex. `QueryBalance`) combined with `/`s to form a full +method name (ex. `/cosmos_sdk.x.bank.v1.Query/QueryBalance`). This gets translated +into an ABCI query as `custom/cosmos_sdk.x.bank.v1.Query/QueryBalance`. Service handlers +registered with `QueryRouter.RegisterService` will be routed this way. + +Beyond the method name, GRPC requests carry a protobuf encoded payload, which maps naturally +to `RequestQuery.Data`, and receive a protobuf encoded response or error. Thus +there is a quite natural mapping of GRPC-like rpc methods to the existing +`sdk.Query` and `QueryRouter` infrastructure. + +This basic specification allows us to reuse protocol buffer `service` definitions +for ABCI custom queries substantially reducing the need for manual decoding and +encoding in query methods. + +### GRPC Protocol Support + +In addition to providing an ABCI query pathway, we can easily provide a GRPC +proxy server that routes requests in the GRPC protocol to ABCI query requests +under the hood. In this way, clients could use their host languages' existing +GRPC implementations to make direct queries against Cosmos SDK app's using +these `service` definitions. In order for this server to work, the `QueryRouter` +on `BaseApp` will need to expose the service handlers registered with +`QueryRouter.RegisterService` to the proxy server implementation. Nodes could +launch the proxy server on a separate port in the same process as the ABCI app +with a command-line flag. + +### REST Queries and Swagger Generation + +[grpc-gateway](https://github.com/grpc-ecosystem/grpc-gateway) is a project that +translates REST calls into GRPC calls using special annotations on service +methods. Modules that want to expose REST queries should add `google.api.http` +annotations to their `rpc` methods as in this example below. + +```proto +// x/bank/types/types.proto + +service Query { + rpc QueryBalance(QueryBalanceParams) returns (cosmos_sdk.v1.Coin) { + option (google.api.http) = { + get: "/x/bank/v1/balance/{address}/{denom}" + }; + } + rpc QueryAllBalances(QueryAllBalancesParams) returns (QueryAllBalancesResponse) { + option (google.api.http) = { + get: "/x/bank/v1/balances/{address}" + }; + } +} +``` + +grpc-gateway will work direcly against the GRPC proxy described above which will +translate requests to ABCI queries under the hood. grpc-gateway can also +generate Swagger definitions automatically. + +In the current implementation of REST queries, each module needs to implement +REST queries manually in addition to ABCI querier methods. Using the grpc-gateway +approach, there will be no need to generate separate REST query handlers, just +query servers as described above as grpc-gateway handles the translation of protobuf +to REST as well as Swagger definitions. + +The SDK should provide CLI commands for apps to start GRPC gateway either in +a separate process or the same process as the ABCI app, as well as provide a +command for generating grpc-gateway proxy `.proto` files and the `swagger.json` +file. + +### Client Usage + +The gogo protobuf grpc plugin generates client interfaces in addition to server +interfaces. For the `Query` service defined above we would get a `QueryClient` +interface like: + +```go +type QueryClient interface { + QueryBalance(ctx context.Context, in *QueryBalanceParams, opts ...grpc.CallOption) (*types.Coin, error) + QueryAllBalances(ctx context.Context, in *QueryAllBalancesParams, opts ...grpc.CallOption) (*QueryAllBalancesResponse, error) +} +``` + +Via a small patch to gogo protobuf ([gogo/protobuf#675](https://github.com/gogo/protobuf/pull/675)) +we have tweaked the grpc codegen to use an interface rather than concrete type +for the generated client struct. This allows us to also reuse the GRPC infrastructure +for ABCI client queries. + +1Context`will receive a new method`QueryConn`that returns a`ClientConn` +that routes calls to ABCI queries + +Clients (such as CLI methods) will then be able to call query methods like this: + +```go +clientCtx := client.NewContext() +queryClient := types.NewQueryClient(clientCtx.QueryConn()) +params := &types.QueryBalanceParams{addr, denom} +result, err := queryClient.QueryBalance(gocontext.Background(), params) +``` + +### Testing + +Tests would be able to create a query client directly from keeper and `sdk.Context` +references using a `QueryServerTestHelper` as below: + +```go +queryHelper := baseapp.NewQueryServerTestHelper(ctx) +types.RegisterQueryServer(queryHelper, keeper.Querier{app.BankKeeper}) +queryClient := types.NewQueryClient(queryHelper) +``` + +## Future Improvements + +## Consequences + +### Positive + +* greatly simplified querier implementation (no manual encoding/decoding) +* easy query client generation (can use existing grpc and swagger tools) +* no need for REST query implementations +* type safe query methods (generated via grpc plugin) +* going forward, there will be less breakage of query methods because of the +backwards compatibility guarantees provided by buf + +### Negative + +* all clients using the existing ABCI/REST queries will need to be refactored +for both the new GRPC/REST query paths as well as protobuf/proto-json encoded +data, but this is more or less unavoidable in the protobuf refactoring + +### Neutral + +## References diff --git a/versioned_docs/version-0.45/integrate/architecture/adr-022-custom-panic-handling.md b/versioned_docs/version-0.45/integrate/architecture/adr-022-custom-panic-handling.md new file mode 100644 index 000000000..034f2e734 --- /dev/null +++ b/versioned_docs/version-0.45/integrate/architecture/adr-022-custom-panic-handling.md @@ -0,0 +1,213 @@ +# ADR 022: Custom BaseApp panic handling + +## Changelog + +- 2020 Apr 24: Initial Draft + +## Context + +The current implementation of BaseApp does not allow developers to write custom error handlers during panic recovery +[runTx()](https://github.com/cosmos/cosmos-sdk/blob/bad4ca75f58b182f600396ca350ad844c18fc80b/baseapp/baseapp.go#L539) +method. We think that this method can be more flexible and can give SDK users more options for customizations without +the need to rewrite whole BaseApp. Also there's one special case for `sdk.ErrorOutOfGas` error handling, that case +might be handled in a "standard" way (middleware) alongside the others. + +We propose middleware-solution, which could help developers implement the following cases: + +* add external logging (let's say sending reports to external services like [Sentry](https://sentry.io)); +* call panic for specific error cases; + +It will also make `OutOfGas` case and `default` case one of the middlewares. +`Default` case wraps recovery object to an error and logs it ([example middleware implementation](#Recovery-middleware)). + +Our project has a sidecar service running alongside the blockchain node (smart contracts virtual machine). It is +essential that node <-> sidecar connectivity stays stable for TXs processing. So when the communication breaks we need +to crash the node and reboot it once the problem is solved. That behaviour makes node's state machine execution +deterministic. As all keeper panics are caught by runTx's `defer()` handler, we have to adjust the BaseApp code +in order to customize it. + +## Decision + +### Design + +#### Overview + +Instead of hardcoding custom error handling into BaseApp we suggest using set of middlewares which can be customized +externally and will allow developers use as many custom error handlers as they want. Implementation with tests +can be found [here](https://github.com/cosmos/cosmos-sdk/pull/6053). + +#### Implementation details + +##### Recovery handler + +New `RecoveryHandler` type added. `recoveryObj` input argument is an object returned by the standard Go function +`recover()` from the `builtin` package. + +```go +type RecoveryHandler func(recoveryObj interface{}) error +``` + +Handler should type assert (or other methods) an object to define if object should be handled. +`nil` should be returned if input object can't be handled by that `RecoveryHandler` (not a handler's target type). +Not `nil` error should be returned if input object was handled and middleware chain execution should be stopped. + +An example: + +```go +func exampleErrHandler(recoveryObj interface{}) error { + err, ok := recoveryObj.(error) + if !ok { return nil } + + if someSpecificError.Is(err) { + panic(customPanicMsg) + } else { + return nil + } +} +``` + +This example breaks the application execution, but it also might enrich the error's context like the `OutOfGas` handler. + +##### Recovery middleware + +We also add a middleware type (decorator). That function type wraps `RecoveryHandler` and returns the next middleware in +execution chain and handler's `error`. Type is used to separate actual `recovery()` object handling from middleware +chain processing. + +```go +type recoveryMiddleware func(recoveryObj interface{}) (recoveryMiddleware, error) + +func newRecoveryMiddleware(handler RecoveryHandler, next recoveryMiddleware) recoveryMiddleware { + return func(recoveryObj interface{}) (recoveryMiddleware, error) { + if err := handler(recoveryObj); err != nil { + return nil, err + } + return next, nil + } +} +``` + +Function receives a `recoveryObj` object and returns: + +* (next `recoveryMiddleware`, `nil`) if object wasn't handled (not a target type) by `RecoveryHandler`; +* (`nil`, not nil `error`) if input object was handled and other middlewares in the chain should not be executed; +* (`nil`, `nil`) in case of invalid behavior. Panic recovery might not have been properly handled; +this can be avoided by always using a `default` as a rightmost middleware in the chain (always returns an `error`'); + +`OutOfGas` middleware example: + +```go +func newOutOfGasRecoveryMiddleware(gasWanted uint64, ctx sdk.Context, next recoveryMiddleware) recoveryMiddleware { + handler := func(recoveryObj interface{}) error { + err, ok := recoveryObj.(sdk.ErrorOutOfGas) + if !ok { return nil } + + return sdkerrors.Wrap( + sdkerrors.ErrOutOfGas, fmt.Sprintf( + "out of gas in location: %v; gasWanted: %d, gasUsed: %d", err.Descriptor, gasWanted, ctx.GasMeter().GasConsumed(), + ), + ) + } + + return newRecoveryMiddleware(handler, next) +} +``` + +`Default` middleware example: + +```go +func newDefaultRecoveryMiddleware() recoveryMiddleware { + handler := func(recoveryObj interface{}) error { + return sdkerrors.Wrap( + sdkerrors.ErrPanic, fmt.Sprintf("recovered: %v\nstack:\n%v", recoveryObj, string(debug.Stack())), + ) + } + + return newRecoveryMiddleware(handler, nil) +} +``` + +##### Recovery processing + +Basic chain of middlewares processing would look like: + +```go +func processRecovery(recoveryObj interface{}, middleware recoveryMiddleware) error { + if middleware == nil { return nil } + + next, err := middleware(recoveryObj) + if err != nil { return err } + if next == nil { return nil } + + return processRecovery(recoveryObj, next) +} +``` + +That way we can create a middleware chain which is executed from left to right, the rightmost middleware is a +`default` handler which must return an `error`. + +##### BaseApp changes + +The `default` middleware chain must exist in a `BaseApp` object. `Baseapp` modifications: + +```go +type BaseApp struct { + // ... + runTxRecoveryMiddleware recoveryMiddleware +} + +func NewBaseApp(...) { + // ... + app.runTxRecoveryMiddleware = newDefaultRecoveryMiddleware() +} + +func (app *BaseApp) runTx(...) { + // ... + defer func() { + if r := recover(); r != nil { + recoveryMW := newOutOfGasRecoveryMiddleware(gasWanted, ctx, app.runTxRecoveryMiddleware) + err, result = processRecovery(r, recoveryMW), nil + } + + gInfo = sdk.GasInfo{GasWanted: gasWanted, GasUsed: ctx.GasMeter().GasConsumed()} + }() + // ... +} +``` + +Developers can add their custom `RecoveryHandler`s by providing `AddRunTxRecoveryHandler` as a BaseApp option parameter to the `NewBaseapp` constructor: + +```go +func (app *BaseApp) AddRunTxRecoveryHandler(handlers ...RecoveryHandler) { + for _, h := range handlers { + app.runTxRecoveryMiddleware = newRecoveryMiddleware(h, app.runTxRecoveryMiddleware) + } +} +``` + +This method would prepend handlers to an existing chain. + +## Consequences + +### Positive + +- Developers of Cosmos SDK based projects can add custom panic handlers to: + * add error context for custom panic sources (panic inside of custom keepers); + * emit `panic()`: passthrough recovery object to the Tendermint core; + * other necessary handling; +- Developers can use standard Cosmos SDK `BaseApp` implementation, rather that rewriting it in their projects; +- Proposed solution doesn't break the current "standard" `runTx()` flow; + +### Negative + +- Introduces changes to the execution model design. + +### Neutral + +- `OutOfGas` error handler becomes one of the middlewares; +- Default panic handler becomes one of the middlewares; + +## References + +- [PR-6053 with proposed solution](https://github.com/cosmos/cosmos-sdk/pull/6053) +- [Similar solution. ADR-010 Modular AnteHandler](https://github.com/cosmos/cosmos-sdk/blob/v0.38.3/docs/architecture/adr-010-modular-antehandler.md) diff --git a/versioned_docs/version-0.45/integrate/architecture/adr-023-protobuf-naming.md b/versioned_docs/version-0.45/integrate/architecture/adr-023-protobuf-naming.md new file mode 100644 index 000000000..6e9ead13c --- /dev/null +++ b/versioned_docs/version-0.45/integrate/architecture/adr-023-protobuf-naming.md @@ -0,0 +1,263 @@ +# ADR 023: Protocol Buffer Naming and Versioning Conventions + +## Changelog + +- 2020 April 27: Initial Draft +- 2020 August 5: Update guidelines + +## Status + +Accepted + +## Context + +Protocol Buffers provide a basic [style guide](https://developers.google.com/protocol-buffers/docs/style) +and [Buf](https://buf.build/docs/style-guide) builds upon that. To the +extent possible, we want to follow industry accepted guidelines and wisdom for +the effective usage of protobuf, deviating from those only when there is clear +rationale for our use case. + +### Adoption of `Any` + +The adoption of `google.protobuf.Any` as the recommended approach for encoding +interface types (as opposed to `oneof`) makes package naming a central part +of the encoding as fully-qualified message names now appear in encoded +messages. + +### Current Directory Organization + +Thus far we have mostly followed [Buf's](https://buf.build) [DEFAULT](https://buf.build/docs/lint-checkers#default) +recommendations, with the minor deviation of disabling [`PACKAGE_DIRECTORY_MATCH`](https://buf.build/docs/lint-checkers#file_layout) +which although being convenient for developing code comes with the warning +from Buf that: + +> you will have a very bad time with many Protobuf plugins across various languages if you do not do this + +### Adoption of gRPC Queries + +In [ADR 021](adr-021-protobuf-query-encoding.md), gRPC was adopted for Protobuf +native queries. The full gRPC service path thus becomes a key part of ABCI query +path. In the future, gRPC queries may be allowed from within persistent scripts +by technologies such as CosmWasm and these query routes would be stored within +script binaries. + +## Decision + +The goal of this ADR is to provide thoughtful naming conventions that: + +* encourage a good user experience for when users interact directly with +.proto files and fully-qualified protobuf names +* balance conciseness against the possibility of either over-optimizing (making +names too short and cryptic) or under-optimizing (just accepting bloated names +with lots of redundant information) + +These guidelines are meant to act as a style guide for both the SDK and +third-party modules. + +As a starting point, we should adopt all of the [DEFAULT](https://buf.build/docs/lint-checkers#default) +checkers in [Buf's](https://buf.build) including [`PACKAGE_DIRECTORY_MATCH`](https://buf.build/docs/lint-checkers#file_layout), +except: + +* [PACKAGE_VERSION_SUFFIX](https://buf.build/docs/lint-checkers#package_version_suffix) +* [SERVICE_SUFFIX](https://buf.build/docs/lint-checkers#service_suffix) + +Further guidelines to be described below. + +### Principles + +#### Concise and Descriptive Names + +Names should be descriptive enough to convey their meaning and distinguish +them from other names. + +Given that we are using fully-qualifed names within +`google.protobuf.Any` as well as within gRPC query routes, we should aim to +keep names concise, without going overboard. The general rule of thumb should +be if a shorter name would convey more or else the same thing, pick the shorter +name. + +For instance, `cosmos.bank.MsgSend` (19 bytes) conveys roughly the same information +as `cosmos_sdk.x.bank.v1.MsgSend` (28 bytes) but is more concise. + +Such conciseness makes names both more pleasant to work with and take up less +space within transactions and on the wire. + +We should also resist the temptation to over-optimize, by making names +cryptically short with abbreviations. For instance, we shouldn't try to +reduce `cosmos.bank.MsgSend` to `csm.bk.MSnd` just to save a few bytes. + +The goal is to make names **_concise but not cryptic_**. + +#### Names are for Clients First + +Package and type names should be chosen for the benefit of users, not +necessarily because of legacy concerns related to the go code-base. + +#### Plan for Longevity + +In the interests of long-term support, we should plan on the names we do +choose to be in usage for a long time, so now is the opportunity to make +the best choices for the future. + +### Versioning + +#### Guidelines on Stable Package Versions + +In general, schema evolution is the way to update protobuf schemas. That means that new fields, +messages, and RPC methods are _added_ to existing schemas and old fields, messages and RPC methods +are maintained as long as possible. + +Breaking things is often unacceptable in a blockchain scenario. For instance, immutable smart contracts +may depend on certain data schemas on the host chain. If the host chain breaks those schemas, the smart +contract may be irreparably broken. Even when things can be fixed (for instance in client software), +this often comes at a high cost. + +Instead of breaking things, we should make every effort to evolve schemas rather than just breaking them. +[Buf](https://buf.build) breaking change detection should be used on all stable (non-alpha or beta) packages +to prevent such breakage. + +With that in mind, different stable versions (i.e. `v1` or `v2`) of a package should more or less be considered +different packages and this should be last resort approach for upgrading protobuf schemas. Scenarios where creating +a `v2` may make sense are: + +* we want to create a new module with similar functionality to an existing module and adding `v2` is the most natural +way to do this. In that case, there are really just two different, but similar modules with different APIs. +* we want to add a new revamped API for an existing module and it's just too cumbersome to add it to the existing package, +so putting it in `v2` is cleaner for users. In this case, care should be made to not deprecate support for +`v1` if it is actively used in immutable smart contracts. + +#### Guidelines on unstable (alpha and beta) package versions + +The following guidelines are recommended for marking packages as alpha or beta: + +* marking something as `alpha` or `beta` should be a last resort and just putting something in the +stable package (i.e. `v1` or `v2`) should be preferred +* a package *should* be marked as `alpha` *if and only if* there are active discussions to remove +or significantly alter the package in the near future +* a package *should* be marked as `beta` *if and only if* there is an active discussion to +significantly refactor/rework the functionality in the near future but not remove it +* modules *can and should* have types in both stable (i.e. `v1` or `v2`) and unstable (`alpha` or `beta`) packages. + +*`alpha` and `beta` should not be used to avoid responsibility for maintaining compatibility.* +Whenever code is released into the wild, especially on a blockchain, there is a high cost to changing things. In some +cases, for instance with immutable smart contracts, a breaking change may be impossible to fix. + +When marking something as `alpha` or `beta`, maintainers should ask the questions: + +* what is the cost of asking others to change their code vs the benefit of us maintaining the optionality to change it? +* what is the plan for moving this to `v1` and how will that affect users? + +`alpha` or `beta` should really be used to communicate "changes are planned". + +As a case study, gRPC reflection is in the package `grpc.reflection.v1alpha`. It hasn't been changed since +2017 and it is now used in other widely used software like gRPCurl. Some folks probably use it in production services +and so if they actually went and changed the package to `grpc.reflection.v1`, some software would break and +they probably don't want to do that... So now the `v1alpha` package is more or less the de-facto `v1`. Let's not do that. + +The following are guidelines for working with non-stable packages: + +* [Buf's recommended version suffix](https://buf.build/docs/lint-checkers#package_version_suffix) +(ex. `v1alpha1`) _should_ be used for non-stable packages +* non-stable packages should generally be excluded from breaking change detection +* immutable smart contract modules (i.e. CosmWasm) _should_ block smart contracts/persistent +scripts from interacting with `alpha`/`beta` packages + +#### Omit v1 suffix + +Instead of using [Buf's recommended version suffix](https://buf.build/docs/lint-checkers#package_version_suffix), +we can omit `v1` for packages that don't actually have a second version. This +allows for more concise names for common use cases like `cosmos.bank.Send`. +Packages that do have a second or third version can indicate that with `.v2` +or `.v3`. + +### Package Naming + +#### Adopt a short, unique top-level package name + +Top-level packages should adopt a short name that is known to not collide with +other names in common usage within the Cosmos ecosystem. In the near future, a +registry should be created to reserve and index top-level package names used +within the Cosmos ecosystem. Because the Cosmos SDK is intended to provide +the top-level types for the Cosmos project, the top-level package name `cosmos` +is recommended for usage within the Cosmos SDK instead of the longer `cosmos_sdk`. +[ICS](https://github.com/cosmos/ics) specifications could consider a +short top-level package like `ics23` based upon the standard number. + +#### Limit sub-package depth + +Sub-package depth should be increased with caution. Generally a single +sub-package is needed for a module or a library. Even though `x` or `modules` +is used in source code to denote modules, this is often unnecessary for .proto +files as modules are the primary thing sub-packages are used for. Only items which +are known to be used infrequently should have deep sub-package depths. + +For the Cosmos SDK, it is recommended that that we simply write `cosmos.bank`, +`cosmos.gov`, etc. rather than `cosmos.x.bank`. In practice, most non-module +types can go straight in the `cosmos` package or we can introduce a +`cosmos.base` package if needed. Note that this naming _will not_ change +go package names, i.e. the `cosmos.bank` protobuf package will still live in +`x/bank`. + +### Message Naming + +Message type names should be as concise possible without losing clarity. `sdk.Msg` +types which are used in transactions will retain the `Msg` prefix as that provides +helpful context. + +### Service and RPC Naming + +[ADR 021](adr-021-protobuf-query-encoding.md) specifies that modules should +implement a gRPC query service. We should consider the principle of conciseness +for query service and RPC names as these may be called from persistent script +modules such as CosmWasm. Also, users may use these query paths from tools like +[gRPCurl](https://github.com/fullstorydev/grpcurl). As an example, we can shorten +`/cosmos_sdk.x.bank.v1.QueryService/QueryBalance` to +`/cosmos.bank.Query/Balance` without losing much useful information. + +RPC request and response types _should_ follow the `ServiceNameMethodNameRequest`/ +`ServiceNameMethodNameResponse` naming convention. i.e. for an RPC method named `Balance` +on the `Query` service, the request and response types would be `QueryBalanceRequest` +and `QueryBalanceResponse`. This will be more self-explanatory than `BalanceRequest` +and `BalanceResponse`. + +#### Use just `Query` for the query service + +Instead of [Buf's default service suffix recommendation](https://github.com/cosmos/cosmos-sdk/pull/6033), +we should simply use the shorter `Query` for query services. + +For other types of gRPC services, we should consider sticking with Buf's +default recommendation. + +#### Omit `Get` and `Query` from query service RPC names + +`Get` and `Query` should be omitted from `Query` service names because they are +redundant in the fully-qualified name. For instance, `/cosmos.bank.Query/QueryBalance` +just says `Query` twice without any new information. + +## Future Improvements + +A registry of top-level package names should be created to coordinate naming +across the ecosystem, prevent collisions, and also help developers discover +useful schemas. A simple starting point would be a git repository with +community-based governance. + +## Consequences + +### Positive + +* names will be more concise and easier to read and type +* all transactions using `Any` will be at shorter (`_sdk.x` and `.v1` will be removed) +* `.proto` file imports will be more standard (without `"third_party/proto"` in +the path) +* code generation will be easier for clients because .proto files will be +in a single `proto/` directory which can be copied rather than scattered +throughout the SDK + +### Negative + +### Neutral + +* `.proto` files will need to be reorganized and refactored +* some modules may need to be marked as alpha or beta + +## References diff --git a/versioned_docs/version-0.45/integrate/architecture/adr-024-coin-metadata.md b/versioned_docs/version-0.45/integrate/architecture/adr-024-coin-metadata.md new file mode 100644 index 000000000..5195a9c40 --- /dev/null +++ b/versioned_docs/version-0.45/integrate/architecture/adr-024-coin-metadata.md @@ -0,0 +1,139 @@ +# ADR 024: Coin Metadata + +## Changelog + +- 05/19/2020: Initial draft + +## Status + +Proposed + +## Context + +Assets in the Cosmos SDK are represented via a `Coins` type that consists of an `amount` and a `denom`, +where the `amount` can be any arbitrarily large or small value. In addition, the Cosmos SDK uses an +account-based model where there are two types of primary accounts -- basic accounts and module accounts. +All account types have a set of balances that are composed of `Coins`. The `x/bank` module keeps +track of all balances for all accounts and also keeps track of the total supply of balances in an +application. + +With regards to a balance `amount`, the Cosmos SDK assumes a static and fixed unit of denomination, +regardless of the denomination itself. In other words, clients and apps built atop a Cosmos-SDK-based +chain may choose to define and use arbitrary units of denomination to provide a richer UX, however, by +the time a tx or operation reaches the Cosmos SDK state machine, the `amount` is treated as a single +unit. For example, for the Cosmos Hub (Gaia), clients assume 1 ATOM = 10^6 uatom, and so all txs and +operations in the Cosmos SDK work off of units of 10^6. + +This clearly provides a poor and limited UX especially as interoperability of networks increases and +as a result the total amount of asset types increases. We propose to have `x/bank` additionally keep +track of metadata per `denom` in order to help clients, wallet providers, and explorers improve their +UX and remove the requirement for making any assumptions on the unit of denomination. + +## Decision + +The `x/bank` module will be updated to store and index metadata by `denom`, specifically the "base" or +smallest unit -- the unit the Cosmos SDK state-machine works with. + +Metadata may also include a non-zero length list of denominations. Each entry contains the name of +the denomination `denom`, the exponent to the base and a list of aliases. An entry is to be +interpreted as `1 denom = 10^exponent base_denom` (e.g. `1 ETH = 10^18 wei` and `1 uatom = 10^0 uatom`). + +There are two denominations that are of high importance for clients: the `base`, which is the smallest +possible unit and the `display`, which is the unit that is commonly referred to in human communication +and on exchanges. The values in those fields link to an entry in the list of denominations. + +The list in `denom_units` and the `display` entry may be changed via governance. + +As a result, we can define the type as follows: + +```protobuf +message DenomUnit { + string denom = 1; + uint32 exponent = 2; + repeated string aliases = 3; +} + +message Metadata { + string description = 1; + repeated DenomUnit denom_units = 2; + string base = 3; + string display = 4; +} +``` + +As an example, the ATOM's metadata can be defined as follows: + +```json +{ + "description": "The native staking token of the Cosmos Hub.", + "denom_units": [ + { + "denom": "uatom", + "exponent": 0, + "aliases": [ + "microatom" + ], + }, + { + "denom": "matom", + "exponent": 3, + "aliases": [ + "milliatom" + ] + }, + { + "denom": "atom", + "exponent": 6, + } + ], + "base": "uatom", + "display": "atom", +} +``` + +Given the above metadata, a client may infer the following things: + +- 4.3atom = 4.3 * (10^6) = 4,300,000uatom +- The string "atom" can be used as a display name in a list of tokens. +- The balance 4300000 can be displayed as 4,300,000uatom or 4,300matom or 4.3atom. + The `display` denomination 4.3atom is a good default if the authors of the client don't make + an explicit decision to choose a different representation. + +A client should be able to query for metadata by denom both via the CLI and REST interfaces. In +addition, we will add handlers to these interfaces to convert from any unit to another given unit, +as the base framework for this already exists in the Cosmos SDK. + +Finally, we need to ensure metadata exists in the `GenesisState` of the `x/bank` module which is also +indexed by the base `denom`. + +```go +type GenesisState struct { + SendEnabled bool `json:"send_enabled" yaml:"send_enabled"` + Balances []Balance `json:"balances" yaml:"balances"` + Supply sdk.Coins `json:"supply" yaml:"supply"` + DenomMetadata []Metadata `json:"denom_metadata" yaml:"denom_metadata"` +} +``` + +## Future Work + +In order for clients to avoid having to convert assets to the base denomination -- either manually or +via an endpoint, we may consider supporting automatic conversion of a given unit input. + +## Consequences + +### Positive + +- Provides clients, wallet providers and block explorers with additional data on + asset denomination to improve UX and remove any need to make assumptions on + denomination units. + +### Negative + +- A small amount of required additional storage in the `x/bank` module. The amount + of additional storage should be minimal as the amount of total assets should not + be large. + +### Neutral + +## References diff --git a/versioned_docs/version-0.45/integrate/architecture/adr-027-deterministic-protobuf-serialization.md b/versioned_docs/version-0.45/integrate/architecture/adr-027-deterministic-protobuf-serialization.md new file mode 100644 index 000000000..ab303e8d0 --- /dev/null +++ b/versioned_docs/version-0.45/integrate/architecture/adr-027-deterministic-protobuf-serialization.md @@ -0,0 +1,314 @@ +# ADR 027: Deterministic Protobuf Serialization + +## Changelog + +- 2020-08-07: Initial Draft +- 2020-09-01: Further clarify rules + +## Status + +Proposed + +## Abstract + +Fully deterministic structure serialization, which works across many languages and clients, +is needed when signing messages. We need to be sure that whenever we serialize +a data structure, no matter in which supported language, the raw bytes +will stay the same. +[Protobuf](https://developers.google.com/protocol-buffers/docs/proto3) +serialization is not bijective (i.e. there exist a practically unlimited number of +valid binary representations for a given protobuf document)1. + +This document describes a deterministic serialization scheme for +a subset of protobuf documents, that covers this use case but can be reused in +other cases as well. + +### Context + +For signature verification in Cosmos SDK, the signer and verifier need to agree on +the same serialization of a `SignDoc` as defined in +[ADR-020](./adr-020-protobuf-transaction-encoding.md) without transmitting the +serialization. + +Currently, for block signatures we are using a workaround: we create a new [TxRaw](https://github.com/cosmos/cosmos-sdk/blob/9e85e81e0e8140067dd893421290c191529c148c/proto/cosmos/tx/v1beta1/tx.proto#L30) +instance (as defined in [adr-020-protobuf-transaction-encoding](https://github.com/cosmos/cosmos-sdk/blob/master/docs/architecture/adr-020-protobuf-transaction-encoding.md#transactions)) +by converting all [Tx](https://github.com/cosmos/cosmos-sdk/blob/9e85e81e0e8140067dd893421290c191529c148c/proto/cosmos/tx/v1beta1/tx.proto#L13) +fields to bytes on the client side. This adds an additional manual +step when sending and signing transactions. + +### Decision + +The following encoding scheme is to be used by other ADRs, +and in particular for `SignDoc` serialization. + +## Specification + +### Scope + +This ADR defines a protobuf3 serializer. The output is a valid protobuf +serialization, such that every protobuf parser can parse it. + +No maps are supported in version 1 due to the complexity of defining a +deterministic serialization. This might change in future. Implementations must +reject documents containing maps as invalid input. + +### Background - Protobuf3 Encoding + +Most numeric types in protobuf3 are encoded as +[varints](https://developers.google.com/protocol-buffers/docs/encoding#varints). +Varints are at most 10 bytes, and since each varint byte has 7 bits of data, +varints are a representation of `uint70` (70-bit unsigned integer). When +encoding, numeric values are casted from their base type to `uint70`, and when +decoding, the parsed `uint70` is casted to the appropriate numeric type. + +The maximum valid value for a varint that complies with protobuf3 is +`FF FF FF FF FF FF FF FF FF 7F` (i.e. `2**70 -1`). If the field type is +`{,u,s}int64`, the highest 6 bits of the 70 are dropped during decoding, +introducing 6 bits of malleability. If the field type is `{,u,s}int32`, the +highest 38 bits of the 70 are dropped during decoding, introducing 38 bits of +malleability. + +Among other sources of non-determinism, this ADR eliminates the possibility of +encoding malleability. + +### Serialization rules + +The serialization is based on the +[protobuf3 encoding](https://developers.google.com/protocol-buffers/docs/encoding) +with the following additions: + +1. Fields must be serialized only once in ascending order +2. Extra fields or any extra data must not be added +3. [Default values](https://developers.google.com/protocol-buffers/docs/proto3#default) + must be omitted +4. `repeated` fields of scalar numeric types must use + [packed encoding](https://developers.google.com/protocol-buffers/docs/encoding#packed) +5. Varint encoding must not be longer than needed: + * No trailing zero bytes (in little endian, i.e. no leading zeroes in big + endian). Per rule 3 above, the default value of `0` must be omitted, so + this rule does not apply in such cases. + * The maximum value for a varint must be `FF FF FF FF FF FF FF FF FF 01`. + In other words, when decoded, the highest 6 bits of the 70-bit unsigned + integer must be `0`. (10-byte varints are 10 groups of 7 bits, i.e. + 70 bits, of which only the lowest 70-6=64 are useful.) + * The maximum value for 32-bit values in varint encoding must be `FF FF FF FF 0F` + with one exception (below). In other words, when decoded, the highest 38 + bits of the 70-bit unsigned integer must be `0`. + * The one exception to the above is _negative_ `int32`, which must be + encoded using the full 10 bytes for sign extension2. + * The maximum value for Boolean values in varint encoding must be `01` (i.e. + it must be `0` or `1`). Per rule 3 above, the default value of `0` must + be omitted, so if a Boolean is included it must have a value of `1`. + +While rule number 1. and 2. should be pretty straight forward and describe the +default behavior of all protobuf encoders the author is aware of, the 3rd rule +is more interesting. After a protobuf3 deserialization you cannot differentiate +between unset fields and fields set to the default value3. At +serialization level however, it is possible to set the fields with an empty +value or omitting them entirely. This is a significant difference to e.g. JSON +where a property can be empty (`""`, `0`), `null` or undefined, leading to 3 +different documents. + +Omitting fields set to default values is valid because the parser must assign +the default value to fields missing in the serialization4. For scalar +types, omitting defaults is required by the spec5. For `repeated` +fields, not serializing them is the only way to express empty lists. Enums must +have a first element of numeric value 0, which is the default6. And +message fields default to unset7. + +Omitting defaults allows for some amount of forward compatibility: users of +newer versions of a protobuf schema produce the same serialization as users of +older versions as long as newly added fields are not used (i.e. set to their +default value). + +### Implementation + +There are three main implementation strategies, ordered from the least to the +most custom development: + +- **Use a protobuf serializer that follows the above rules by default.** E.g. + [gogoproto](https://pkg.go.dev/github.com/gogo/protobuf/gogoproto) is known to + be compliant by in most cases, but not when certain annotations such as + `nullable = false` are used. It might also be an option to configure an + existing serializer accordingly. +- **Normalize default values before encoding them.** If your serializer follows + rule 1. and 2. and allows you to explicitly unset fields for serialization, + you can normalize default values to unset. This can be done when working with + [protobuf.js](https://www.npmjs.com/package/protobufjs): + + ```js + const bytes = SignDoc.encode({ + bodyBytes: body.length > 0 ? body : null, // normalize empty bytes to unset + authInfoBytes: authInfo.length > 0 ? authInfo : null, // normalize empty bytes to unset + chainId: chainId || null, // normalize "" to unset + accountNumber: accountNumber || null, // normalize 0 to unset + accountSequence: accountSequence || null, // normalize 0 to unset + }).finish(); + ``` + +- **Use a hand-written serializer for the types you need.** If none of the above + ways works for you, you can write a serializer yourself. For SignDoc this + would look something like this in Go, building on existing protobuf utilities: + + ```go + if !signDoc.body_bytes.empty() { + buf.WriteUVarInt64(0xA) // wire type and field number for body_bytes + buf.WriteUVarInt64(signDoc.body_bytes.length()) + buf.WriteBytes(signDoc.body_bytes) + } + + if !signDoc.auth_info.empty() { + buf.WriteUVarInt64(0x12) // wire type and field number for auth_info + buf.WriteUVarInt64(signDoc.auth_info.length()) + buf.WriteBytes(signDoc.auth_info) + } + + if !signDoc.chain_id.empty() { + buf.WriteUVarInt64(0x1a) // wire type and field number for chain_id + buf.WriteUVarInt64(signDoc.chain_id.length()) + buf.WriteBytes(signDoc.chain_id) + } + + if signDoc.account_number != 0 { + buf.WriteUVarInt64(0x20) // wire type and field number for account_number + buf.WriteUVarInt(signDoc.account_number) + } + + if signDoc.account_sequence != 0 { + buf.WriteUVarInt64(0x28) // wire type and field number for account_sequence + buf.WriteUVarInt(signDoc.account_sequence) + } + ``` + +### Test vectors + +Given the protobuf definition `Article.proto` + +```protobuf +package blog; +syntax = "proto3"; + +enum Type { + UNSPECIFIED = 0; + IMAGES = 1; + NEWS = 2; +}; + +enum Review { + UNSPECIFIED = 0; + ACCEPTED = 1; + REJECTED = 2; +}; + +message Article { + string title = 1; + string description = 2; + uint64 created = 3; + uint64 updated = 4; + bool public = 5; + bool promoted = 6; + Type type = 7; + Review review = 8; + repeated string comments = 9; + repeated string backlinks = 10; +}; +``` + +serializing the values + +```yaml +title: "The world needs change 🌳" +description: "" +created: 1596806111080 +updated: 0 +public: true +promoted: false +type: Type.NEWS +review: Review.UNSPECIFIED +comments: ["Nice one", "Thank you"] +backlinks: [] +``` + +must result in the serialization + +``` +0a1b54686520776f726c64206e65656473206368616e676520f09f8cb318e8bebec8bc2e280138024a084e696365206f6e654a095468616e6b20796f75 +``` + +When inspecting the serialized document, you see that every second field is +omitted: + +``` +$ echo 0a1b54686520776f726c64206e65656473206368616e676520f09f8cb318e8bebec8bc2e280138024a084e696365206f6e654a095468616e6b20796f75 | xxd -r -p | protoc --decode_raw +1: "The world needs change \360\237\214\263" +3: 1596806111080 +5: 1 +7: 2 +9: "Nice one" +9: "Thank you" +``` + +## Consequences + +Having such an encoding available allows us to get deterministic serialization +for all protobuf documents we need in the context of Cosmos SDK signing. + +### Positive + +- Well defined rules that can be verified independent of a reference + implementation +- Simple enough to keep the barrier to implement transaction signing low +- It allows us to continue to use 0 and other empty values in SignDoc, avoiding + the need to work around 0 sequences. This does not imply the change from + https://github.com/cosmos/cosmos-sdk/pull/6949 should not be merged, but not + too important anymore. + +### Negative + +- When implementing transaction signing, the encoding rules above must be + understood and implemented. +- The need for rule number 3. adds some complexity to implementations. +- Some data structures may require custom code for serialization. Thus + the code is not very portable - it will require additional work for each + client implementing serialization to properly handle custom data structures. + +### Neutral + +### Usage in SDK + +For the reasons mentioned above ("Negative" section) we prefer to keep workarounds +for shared data structure. Example: the aforementioned `TxRaw` is using raw bytes +as a workaround. This allows them to use any valid Protobuf library without +the need of implementing a custom serializer that adheres to this standard (and related risks of bugs). + +## References + +- 1 _When a message is serialized, there is no guaranteed order for + how its known or unknown fields should be written. Serialization order is an + implementation detail and the details of any particular implementation may + change in the future. Therefore, protocol buffer parsers must be able to parse + fields in any order._ from + https://developers.google.com/protocol-buffers/docs/encoding#order +- 2 https://developers.google.com/protocol-buffers/docs/encoding#signed_integers +- 3 _Note that for scalar message fields, once a message is parsed + there's no way of telling whether a field was explicitly set to the default + value (for example whether a boolean was set to false) or just not set at all: + you should bear this in mind when defining your message types. For example, + don't have a boolean that switches on some behavior when set to false if you + don't want that behavior to also happen by default._ from + https://developers.google.com/protocol-buffers/docs/proto3#default +- 4 _When a message is parsed, if the encoded message does not + contain a particular singular element, the corresponding field in the parsed + object is set to the default value for that field._ from + https://developers.google.com/protocol-buffers/docs/proto3#default +- 5 _Also note that if a scalar message field is set to its default, + the value will not be serialized on the wire._ from + https://developers.google.com/protocol-buffers/docs/proto3#default +- 6 _For enums, the default value is the first defined enum value, + which must be 0._ from + https://developers.google.com/protocol-buffers/docs/proto3#default +- 7 _For message fields, the field is not set. Its exact value is + language-dependent._ from + https://developers.google.com/protocol-buffers/docs/proto3#default +- Encoding rules and parts of the reasoning taken from + [canonical-proto3 Aaron Craelius](https://github.com/regen-network/canonical-proto3) diff --git a/versioned_docs/version-0.45/integrate/architecture/adr-028-public-key-addresses.md b/versioned_docs/version-0.45/integrate/architecture/adr-028-public-key-addresses.md new file mode 100644 index 000000000..d86a0426f --- /dev/null +++ b/versioned_docs/version-0.45/integrate/architecture/adr-028-public-key-addresses.md @@ -0,0 +1,329 @@ +# ADR 028: Public Key Addresses + +## Changelog + +- 2020/08/18: Initial version +- 2021/01/15: Analysis and algorithm update + +## Status + +Proposed + +## Abstract + +This ADR defines an address format for all addressable SDK accounts. That includes: new public key algorithms, multisig public keys, and module accounts. + +## 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. + +### 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. + +### 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: + +> I spent quite a bit of time thinking about this issue while building weave... The other cosmos Sdk. +> Basically I define a condition to be a type and format as human readable string with some binary data appended. This condition is hashed into an Address (again at 20 bytes). The use of this prefix makes it impossible to find a preimage for a given address with a different condition (eg ed25519 vs secp256k1). +> This is explained in depth here https://weave.readthedocs.io/en/latest/design/permissions.html +> And the code is here, look mainly at the top where we process conditions. https://github.com/iov-one/weave/blob/master/conditions.go + +And explained how this approach should be sufficiently collision resistant: + +> Yeah, AFAIK, 20 bytes should be collision resistance when the preimages are unique and not malleable. A space of 2^160 would expect some collision to be likely around 2^80 elements (birthday paradox). And if you want to find a collision for some existing element in the database, it is still 2^160. 2^80 only is if all these elements are written to state. +> The good example you brought up was eg. a public key bytes being a valid public key on two algorithms supported by the codec. Meaning if either was broken, you would break accounts even if they were secured with the safer variant. This is only as the issue when no differentiating type info is present in the preimage (before hashing into an address). +> I would like to hear an argument if the 20 bytes space is an actual issue for security, as I would be happy to increase my address sizes in weave. I just figured cosmos and ethereum and bitcoin all use 20 bytes, it should be good enough. And the arguments above which made me feel it was secure. But I have not done a deeper analysis. + +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]`. + +### 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. + +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. + +### 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. + +### 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. + +## 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 + +### Legacy Public Key Addresses Don't Change + +Currently (Jan 2021), the only officially supported 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: + +- secp256k1: `ripemd160(sha256(pk_bytes))[:20]` +- legacy amino multisig: `sha256(aminoCdc.Marshal(pk))[:20]` + +We don't want to change existing addresses. So the addresses for these two key types will remain the same. + +The current multisig public keys use amino serialization to generate the address. We will retain +those public keys and their address formatting, and call them "legacy amino" multisig public keys +in protobuf. We will also create multisig public keys without amino addresses to be described below. + +### Hash Function Choice + +As in other parts of the Cosmos SDK, we will use `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. + +```go +const A_LEN = 32 + +func Hash(typ string, key []byte) []byte { + return hash(hash(typ) + key)[:A_LEN] +} +``` + +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. + +We use the `address.Hash` function for generating addresses for all accounts represented by a single key: + +* simple public keys: `address.Hash(keyType, pubkey)` + ++ aggregated keys (eg: BLS): `address.Hash(keyType, aggregatedPubKey)` ++ modules: `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. + +```go +// We don't need a PubKey interface - we need anything which is addressable. +type Addressable interface { + Address() []byte +} + +func Composed(typ string, subaccounts []Addressable) []byte { + addresses = map(subaccounts, \a -> LengthPrefix(a.Address())) + addresses = sort(addresses) + return address.Hash(typ, addresses[0] + ... + addresses[n]) +} +``` + +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`. + +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. + +Example: + +```proto +package cosmos.crypto.multisig; + +message PubKey { + uint32 threshold = 1; + repeated google.protobuf.Any pubkeys = 2; +} +``` + +```go +func (multisig PubKey) Address() { + // 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 + prefix := fmt.Sprintf("%s/%d", proto.MessageName(multisig), multisig.Threshold) + + // 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 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. + +```go +func Module(moduleName string, key []byte) []byte{ + return Hash("module", []byte(moduleName) + 0 + key) +} +``` + +**Example** A lending BTC pool address would be: + +``` +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: + +```go +func Derive(address []byte, derivationKey []byte) []byte { + return Hash(addres, derivationKey) +} +``` + +Note: `Module` is a special case of the more general _derived_ address, where we set the `"module"` string for the _from address_. + +**Example** For a cosmwasm smart-contract address we could use the following construction: + +``` +smartContractAddr := Derived(Module("cosmwasm", smartContractsNamespace), []{smartContractKey}) +``` + +### Schema Types + +A `typ` parameter used in `Hash` function SHOULD be unique for each account type. +Since all SDK account types are serialized in the state, we propose to use the protobuf message name string. + +Example: all public key types have a unique protobuf message type similar to: + +```proto +package cosmos.crypto.sr25519; + +message PubKey { + bytes key = 1; +} +``` + +All protobuf messages have unique fully qualified names, in this example `cosmos.crypto.sr25519.PubKey`. +These names are derived directly from .proto files in a standardized way and used +in other places such as the type URL in `Any`s. We can easily obtain the name using +`proto.MessageName(msg)`. + +## Consequences + +### Backwards Compatibility + +This ADR is compatible with what was committed and directly supported in the SDK repository. + +### 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. + +### 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 + +### Neutral + +- protobuf message names are used as key type prefixes + +## 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. + +## 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. + +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 + +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. + +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. + +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). + +Discssion about arithmetic hash function for 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. + +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. + +### References + ++ [Notes](https://hackmd.io/_NGWI4xZSbKzj1BkCqyZMw) diff --git a/versioned_docs/version-0.45/integrate/architecture/adr-029-fee-grant-module.md b/versioned_docs/version-0.45/integrate/architecture/adr-029-fee-grant-module.md new file mode 100644 index 000000000..f6e9a4883 --- /dev/null +++ b/versioned_docs/version-0.45/integrate/architecture/adr-029-fee-grant-module.md @@ -0,0 +1,153 @@ +# ADR 029: Fee Grant Module + +## Changelog + +- 2020/08/18: Initial Draft +- 2021/05/05: Removed height based expiration support and simplified naming. + +## Status + +Accepted + +## Context + +In order to make blockchain transactions, the signing account must possess a sufficient balance of the right denomination +in order to pay fees. There are classes of transactions where needing to maintain a wallet with sufficient fees is a +barrier to adoption. + +For instance, when proper permissions are setup, someone may temporarily delegate the ability to vote on proposals to +a "burner" account that is stored on a mobile phone with only minimal security. + +Other use cases include workers tracking items in a supply chain or farmers submitting field data for analytics +or compliance purposes. + +For all of these use cases, UX would be significantly enhanced by obviating the need for these accounts to always +maintain the appropriate fee balance. This is especially true if we wanted to achieve enterprise adoption for something +like supply chain tracking. + +While one solution would be to have a service that fills up these accounts automatically with the appropriate fees, a better UX +would be provided by allowing these accounts to pull from a common fee pool account with proper spending limits. +A single pool would reduce the churn of making lots of small "fill up" transactions and also more effectively leverages +the resources of the organization setting up the pool. + +## Decision + +As a solution we propose a module, `x/feegrant` which allows one account, the "granter" to grant another account, the "grantee" +an allowance to spend the granter's account balance for fees within certain well-defined limits. + +Fee allowances are defined by the extensible `FeeAllowanceI` interface: + +```go +type FeeAllowanceI { + // Accept can use fee payment requested as well as timestamp 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() error +} +``` + +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. +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. + repeated cosmos_sdk.v1.Coin spend_limit = 1; + + // 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. +message PeriodicAllowance { + BasicAllowance basic = 1; + + // 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 + repeated cosmos_sdk.v1.Coin period_spend_limit = 3; + + // period_can_spend is the number of coins left to be spent before the period_reset time + repeated cosmos_sdk.v1.Coin period_can_spend = 4; + + // period_reset is the time at which this period resets and a new one begins, + // it is calculated from the start time of the first transaction after the + // last period ended + google.protobuf.Timestamp period_reset = 5; +} + +``` + +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. +message MsgGrantAllowance { + string granter = 1; + string grantee = 2; + google.protobuf.Any allowance = 3; + } + + // MsgRevokeAllowance removes any existing FeeAllowance from Granter to Grantee. + message MsgRevokeAllowance { + string granter = 1; + string grantee = 2; + } +``` + +In order to use allowances in transactions, we add a new field `granter` to the transaction `Fee` type: + +```proto +package cosmos.tx.v1beta1; + +message Fee { + repeated cosmos.base.v1beta1.Coin amount = 1; + uint64 gas_limit = 2; + string payer = 3; + string granter = 4; +} +``` + +`granter` must either be left empty or must correspond to an account which has granted +a fee allowance to fee payer (either the first signer or the value of the `payer` field). + +A new `AnteDecorator` named `DeductGrantedFeeDecorator` will be created in order to process transactions with `fee_payer` +set and correctly deduct fees based on fee allowances. + +## Consequences + +### Positive + +- improved UX for use cases where it is cumbersome to maintain an account balance just for fees + +### Negative + +### Neutral + +- a new field must be added to the transaction `Fee` message and a new `AnteDecorator` must be +created to use it + +## References + +- Blog article describing initial work: https://medium.com/regen-network/hacking-the-cosmos-cosmwasm-and-key-management-a08b9f561d1b +- Initial public specification: https://gist.github.com/aaronc/b60628017352df5983791cad30babe56 +- Original subkeys proposal from B-harvest which influenced this design: https://github.com/cosmos/cosmos-sdk/issues/4480 diff --git a/versioned_docs/version-0.45/integrate/architecture/adr-030-authz-module.md b/versioned_docs/version-0.45/integrate/architecture/adr-030-authz-module.md new file mode 100644 index 000000000..eccbabf16 --- /dev/null +++ b/versioned_docs/version-0.45/integrate/architecture/adr-030-authz-module.md @@ -0,0 +1,249 @@ +# ADR 030: Authorization Module + +## 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 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. + +## 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). + +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). + +## 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. + +### 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. + +#### 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() string + + // 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() error +} + +// 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. + Accept bool + // 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. + Updated Authorization +} +``` + +For example a `SendAuthorization` like this is defined for `MsgSend` that takes +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 sdk.Coins +} + +func (a SendAuthorization) MsgTypeURL() string { + return sdk.MsgTypeURL(&MsgSend{}) +} + +func (a SendAuthorization) Accept(ctx sdk.Context, msg sdk.Msg) (authz.AcceptResponse, error) { + mSend, ok := msg.(*MsgSend) + if !ok { + return authz.AcceptResponse{}, sdkerrors.ErrInvalidType.Wrap("type mismatch") + } + limitLeft, isNegative := a.SpendLimit.SafeSub(mSend.Amount) + if isNegative { + return authz.AcceptResponse{}, sdkerrors.ErrInsufficientFunds.Wrapf("requested amount is more than spend limit") + } + if limitLeft.IsZero() { + return authz.AcceptResponse{Accept: true, Delete: true}, nil + } + + return authz.AcceptResponse{Accept: true, Delete: false, Updated: &SendAuthorization{SpendLimit: limitLeft}}, nil +} +``` + +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 + +```proto +service Msg { + // 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. + 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. + rpc Revoke(MsgRevoke) returns (MsgRevokeResponse); +} + +// 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]; +} + +message MsgGrant { + string granter = 1; + string grantee = 2; + + Grant grant = 3 [(gogoproto.nullable) = false]; +} + +message MsgExecResponse { + cosmos.base.abci.v1beta1.Result result = 1; +} + +message MsgExec { + string grantee = 1; + // 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: + +```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(ctx sdk.Context, grantee sdk.AccAddress, msgs []sdk.Msg) sdk.Result` +} +``` + +### CLI + +#### `tx exec` Method + +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: + +```go +MsgExec { + Grantee: mykey, + Msgs: []sdk.Msg{ + MsgVote { + ProposalID: 1, + Voter: cosmos3thsdgh983egh823 + Option: Yes + } + } +} +``` + +#### `tx grant --from ` + +This CLI command will send a `MsgGrant` transaction. `authorization` should be encoded as +JSON on the CLI. + +#### `tx revoke --from ` + +This CLI command will send a `MsgRevoke` transaction. + +### Built-in Authorizations + +#### `SendAuthorization` + +```proto +// 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; +} +``` + +#### `GenericAuthorization` + +```proto +// 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 + 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 + +### 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 diff --git a/versioned_docs/version-0.45/integrate/architecture/adr-031-msg-service.md b/versioned_docs/version-0.45/integrate/architecture/adr-031-msg-service.md new file mode 100644 index 000000000..e11813c73 --- /dev/null +++ b/versioned_docs/version-0.45/integrate/architecture/adr-031-msg-service.md @@ -0,0 +1,202 @@ +# ADR 031: Protobuf Msg Services + +## 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). + +## Status + +Accepted + +## Abstract + +We want to leverage protobuf `service` definitions for defining `Msg`s which will give us significant developer UX +improvements in terms of the code that is generated and the fact that return types will now be well defined. + +## Context + +Currently `Msg` handlers in the Cosmos SDK do have return values that are placed in the `data` field of the response. +These return values, however, are not specified anywhere except in the golang handler code. + +In early conversations [it was proposed](https://docs.google.com/document/d/1eEgYgvgZqLE45vETjhwIw4VOqK-5hwQtZtjVbiXnIGc/edit) +that `Msg` return types be captured using a protobuf extension field, ex: + +```protobuf +package cosmos.gov; + +message MsgSubmitProposal + option (cosmos_proto.msg_return) = “uint64”; + string delegator_address = 1; + string validator_address = 2; + repeated sdk.Coin amount = 3; +} +``` + +This was never adopted, however. + +Having a well-specified return value for `Msg`s would improve client UX. For instance, +in `x/gov`, `MsgSubmitProposal` returns the proposal ID as a big-endian `uint64`. +This isn’t really documented anywhere and clients would need to know the internals +of the SDK to parse that value and return it to users. + +Also, there may be cases where we want to use these return values programatically. +For instance, https://github.com/cosmos/cosmos-sdk/issues/7093 proposes a method for +doing inter-module Ocaps using the `Msg` router. A well-defined return type would +improve the developer UX for this approach. + +In addition, handler registration of `Msg` types tends to add a bit of +boilerplate on top of keepers and is usually done through manual type switches. +This isn't necessarily bad, but it does add overhead to creating modules. + +## Decision + +We decide to use protobuf `service` definitions for defining `Msg`s as well as +the code generated by them as a replacement for `Msg` handlers. + +Below we define how this will look for the `SubmitProposal` message from `x/gov` module. +We start with a `Msg` `service` definition: + +```proto +package cosmos.gov; + +service Msg { + rpc SubmitProposal(MsgSubmitProposal) returns (MsgSubmitProposalResponse); +} + +// Note that for backwards compatibility this uses MsgSubmitProposal as the request +// type instead of the more canonical MsgSubmitProposalRequest +message MsgSubmitProposal { + google.protobuf.Any content = 1; + string proposer = 2; +} + +message MsgSubmitProposalResponse { + uint64 proposal_id; +} +``` + +While this is most commonly used for gRPC, overloading protobuf `service` definitions like this does not violate +the intent of the [protobuf spec](https://developers.google.com/protocol-buffers/docs/proto3#services) which says: +> If you don’t want to use gRPC, it’s also possible to use protocol buffers with your own RPC implementation. +With this approach, we would get an auto-generated `MsgServer` interface: + +In addition to clearly specifying return types, this has the benefit of generating client and server code. On the server +side, this is almost like an automatically generated keeper method and could maybe be used intead of keepers eventually +(see [\#7093](https://github.com/cosmos/cosmos-sdk/issues/7093)): + +```go +package gov + +type MsgServer interface { + SubmitProposal(context.Context, *MsgSubmitProposal) (*MsgSubmitProposalResponse, error) +} +``` + +On the client side, developers could take advantage of this by creating RPC implementations that encapsulate transaction +logic. Protobuf libraries that use asynchronous callbacks, like [protobuf.js](https://github.com/protobufjs/protobuf.js#using-services) +could use this to register callbacks for specific messages even for transactions that include multiple `Msg`s. + +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. + +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`. + +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. + +### 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. + +### 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). + +### 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. + +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. + +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. + +### Module Configuration + +In [ADR 021](./adr-021-protobuf-query-encoding.md), we introduced a method `RegisterQueryService` +to `AppModule` which allows for modules to register gRPC queriers. + +To register `Msg` services, we attempt a more extensible approach by converting `RegisterQueryService` +to a more generic `RegisterServices` method: + +```go +type AppModule interface { + RegisterServices(Configurator) + ... +} + +type Configurator interface { + QueryServer() grpc.Server + MsgServer() grpc.Server +} + +// example module: +func (am AppModule) RegisterServices(cfg Configurator) { + types.RegisterQueryServer(cfg.QueryServer(), keeper) + types.RegisterMsgServer(cfg.MsgServer(), keeper) +} +``` + +The `RegisterServices` method and the `Configurator` interface are intended to +evolve to satisfy the use cases discussed in [\#7093](https://github.com/cosmos/cosmos-sdk/issues/7093) +and [\#7122](https://github.com/cosmos/cosmos-sdk/issues/7421). + +When `Msg` services are registered, the framework _should_ verify that all `Msg` types +implement the `sdk.Msg` interface and throw an error during initialization rather +than later when transactions are processed. + +### `Msg` Service Implementation + +Just like query services, `Msg` service methods can retrieve the `sdk.Context` +from the `context.Context` parameter method using the `sdk.UnwrapSDKContext` +method: + +```go +package gov + +func (k Keeper) SubmitProposal(goCtx context.Context, params *types.MsgSubmitProposal) (*MsgSubmitProposalResponse, error) { + ctx := sdk.UnwrapSDKContext(goCtx) + ... +} +``` + +The `sdk.Context` should have an `EventManager` already attached by BaseApp's `msg_service_router`. + +Separate handler definition is no longer needed with this approach. + +## Consequences + +This design changes how a module functionality is exposed and accessed. It deprecates the existing `Handler` interface and `AppModule.Route` in favor of [Protocol Buffer Services](https://developers.google.com/protocol-buffers/docs/proto3#services) and Service Routing described above. This dramatically simplifies the code. We don't need to create handlers and keepers any more. Use of Protocol Buffer auto-generated clients clearly separates the communication interfaces between the module and a modules user. The control logic (aka handlers and keepers) is not exposed any more. A module interface can be seen as a black box accessible through a client API. It's worth to note that the client interfaces are also generated by Protocol Buffers. + +This also allows us to change how we perform functional tests. Instead of mocking AppModules and Router, we will mock a client (server will stay hidden). More specifically: we will never mock `moduleA.MsgServer` in `moduleB`, but rather `moduleA.MsgClient`. One can think about it as working with external services (eg DBs, or online servers...). We assume that the transmission between clients and servers is correctly handled by generated Protocol Buffers. + +Finally, closing a module to client API opens desirable OCAP patterns discussed in ADR-033. Since server implementation and interface is hidden, nobody can hold "keepers"/servers and will be forced to relay on the client interface, which will drive developers for correct encapsulation and software engineering patterns. + +### Pros + +- communicates return type clearly +- manual handler registration and return type marshaling is no longer needed, just implement the interface and register it +- communication interface is automatically generated, the developer can now focus only on the state transition methods - this would improve the UX of [\#7093](https://github.com/cosmos/cosmos-sdk/issues/7093) approach (1) if we chose to adopt that +- generated client code could be useful for clients and tests +- dramatically reduces and simplifies the code + +### Cons + +- using `service` definitions outside the context of gRPC could be confusing (but doesn’t violate the proto3 spec) + +## References + +- [Initial Github Issue \#7122](https://github.com/cosmos/cosmos-sdk/issues/7122) +- [proto 3 Language Guide: Defining Services](https://developers.google.com/protocol-buffers/docs/proto3#services) +- [Initial pre-`Any` `Msg` designs](https://docs.google.com/document/d/1eEgYgvgZqLE45vETjhwIw4VOqK-5hwQtZtjVbiXnIGc) +- [ADR 020](./adr-020-protobuf-transaction-encoding.md) +- [ADR 021](./adr-021-protobuf-query-encoding.md) diff --git a/versioned_docs/version-0.45/integrate/architecture/adr-032-typed-events.md b/versioned_docs/version-0.45/integrate/architecture/adr-032-typed-events.md new file mode 100644 index 000000000..a85126b72 --- /dev/null +++ b/versioned_docs/version-0.45/integrate/architecture/adr-032-typed-events.md @@ -0,0 +1,319 @@ +# ADR 032: Typed Events + +## Changelog + +- 28-Sept-2020: Initial Draft + +## Authors + +- Anil Kumar (@anilcse) +- Jack Zampolin (@jackzampolin) +- Adam Bozanich (@boz) + +## Status + +Proposed + +## Abstract + +Currently in the SDK, events are defined in the handlers for each message as well as `BeginBlock` and `EndBlock`. Each module doesn't have types defined for each event, they are implemented as `map[string]string`. Above all else this makes these events difficult to consume as it requires a great deal of raw string matching and parsing. This proposal focuses on updating the events to use **typed events** defined in each module such that emiting and subscribing to events will be much easier. This workflow comes from the experience of the Akash Network team. + +## Context + +Currently in the SDK, events are defined in the handlers for each message, meaning each module doesn't have a cannonical set of types for each event. Above all else this makes these events difficult to consume as it requires a great deal of raw string matching and parsing. This proposal focuses on updating the events to use **typed events** defined in each module such that emiting and subscribing to events will be much easier. This workflow comes from the experience of the Akash Network team. + +[Our platform](http://github.com/ovrclk/akash) requires a number of programatic on chain interactions both on the provider (datacenter - to bid on new orders and listen for leases created) and user (application developer - to send the app manifest to the provider) side. In addition the Akash team is now maintaining the IBC [`relayer`](https://github.com/ovrclk/relayer), another very event driven process. In working on these core pieces of infrastructure, and integrating lessons learned from Kubernetes developement, our team has developed a standard method for defining and consuming typed events in SDK modules. We have found that it is extremely useful in building this type of event driven application. + +As the SDK gets used more extensively for apps like `peggy`, other peg zones, IBC, DeFi, etc... there will be an exploding demand for event driven applications to support new features desired by users. We propose upstreaming our findings into the SDK to enable all SDK applications to quickly and easily build event driven apps to aid their core application. Wallets, exchanges, explorers, and defi protocols all stand to benefit from this work. + +If this proposal is accepted, users will be able to build event driven SDK apps in go by just writing `EventHandler`s for their specific event types and passing them to `EventEmitters` that are defined in the SDK. + +The end of this proposal contains a detailed example of how to consume events after this refactor. + +This proposal is specifically about how to consume these events as a client of the blockchain, not for intermodule communication. + +## Decision + +__Step-1__: Implement additional functionality in the `types` package: `EmitTypedEvent` and `ParseTypedEvent` functions + +```go +// types/events.go + +// EmitTypedEvent takes typed event and emits converting it into sdk.Event +func (em *EventManager) EmitTypedEvent(event proto.Message) error { + evtType := proto.MessageName(event) + evtJSON, err := codec.ProtoMarshalJSON(event) + if err != nil { + return err + } + + var attrMap map[string]json.RawMessage + err = json.Unmarshal(evtJSON, &attrMap) + if err != nil { + return err + } + + var attrs []abci.EventAttribute + for k, v := range attrMap { + attrs = append(attrs, abci.EventAttribute{ + Key: []byte(k), + Value: v, + }) + } + + em.EmitEvent(Event{ + Type: evtType, + Attributes: attrs, + }) + + return nil +} + +// ParseTypedEvent converts abci.Event back to typed event +func ParseTypedEvent(event abci.Event) (proto.Message, error) { + concreteGoType := proto.MessageType(event.Type) + if concreteGoType == nil { + return nil, fmt.Errorf("failed to retrieve the message of type %q", event.Type) + } + + var value reflect.Value + if concreteGoType.Kind() == reflect.Ptr { + value = reflect.New(concreteGoType.Elem()) + } else { + value = reflect.Zero(concreteGoType) + } + + protoMsg, ok := value.Interface().(proto.Message) + if !ok { + return nil, fmt.Errorf("%q does not implement proto.Message", event.Type) + } + + attrMap := make(map[string]json.RawMessage) + for _, attr := range event.Attributes { + attrMap[string(attr.Key)] = attr.Value + } + + attrBytes, err := json.Marshal(attrMap) + if err != nil { + return nil, err + } + + err = jsonpb.Unmarshal(strings.NewReader(string(attrBytes)), protoMsg) + if err != nil { + return nil, err + } + + return protoMsg, nil +} +``` + +Here, the `EmitTypedEvent` is a method on `EventManager` which takes typed event as input and apply json serialization on it. Then it maps the JSON key/value pairs to `event.Attributes` and emits it in form of `sdk.Event`. `Event.Type` will be the type URL of the proto message. + +When we subscribe to emitted events on the tendermint websocket, they are emitted in the form of an `abci.Event`. `ParseTypedEvent` parses the event back to it's original proto message. + +__Step-2__: Add proto definitions for typed events for msgs in each module: + +For example, let's take `MsgSubmitProposal` of `gov` module and implement this event's type. + +```protobuf +// proto/cosmos/gov/v1beta1/gov.proto +// Add typed event definition + +package cosmos.gov.v1beta1; + +message EventSubmitProposal { + string from_address = 1; + uint64 proposal_id = 2; + TextProposal proposal = 3; +} +``` + +__Step-3__: Refactor event emission to use the typed event created and emit using `sdk.EmitTypedEvent`: + +```go +// x/gov/handler.go +func handleMsgSubmitProposal(ctx sdk.Context, keeper keeper.Keeper, msg types.MsgSubmitProposalI) (*sdk.Result, error) { + ... + types.Context.EventManager().EmitTypedEvent( + &EventSubmitProposal{ + FromAddress: fromAddress, + ProposalId: id, + Proposal: proposal, + }, + ) + ... +} +``` + +#### How to subscribe to these typed events in `Client` + +> NOTE: Full code example below + +Users will be able to subscribe using `client.Context.Client.Subscribe` and consume events which are emitted using `EventHandler`s. + +Akash Network has built a simple [`pubsub`](https://github.com/ovrclk/akash/blob/90d258caeb933b611d575355b8df281208a214f8/pubsub/bus.go#L20). This can be used to subscribe to `abci.Events` and [publish](https://github.com/ovrclk/akash/blob/90d258caeb933b611d575355b8df281208a214f8/events/publish.go#L21) them as typed events. + +Please see the below code sample for more detail on this flow looks for clients. + +## Consequences + +### Positive + +* Improves consistency of implementation for the events currently in the sdk +* Provides a much more ergonomic way to handle events and facilitates writing event driven applications +* This implementation will support a middleware ecosystem of `EventHandler`s + +### Negative + +## Detailed code example of publishing events + +This ADR also proposes adding affordances to emit and consume these events. This way developers will only need to write +`EventHandler`s which define the actions they desire to take. + +```go +// EventEmitter is a type that describes event emitter functions +// This should be defined in `types/events.go` +type EventEmitter func(context.Context, client.Context, ...EventHandler) error + +// EventHandler is a type of function that handles events coming out of the event bus +// This should be defined in `types/events.go` +type EventHandler func(proto.Message) error + +// Sample use of the functions below +func main() { + ctx, cancel := context.WithCancel(context.Background()) + + if err := TxEmitter(ctx, client.Context{}.WithNodeURI("tcp://localhost:26657"), SubmitProposalEventHandler); err != nil { + cancel() + panic(err) + } + + return +} + +// SubmitProposalEventHandler is an example of an event handler that prints proposal details +// when any EventSubmitProposal is emitted. +func SubmitProposalEventHandler(ev proto.Message) (err error) { + switch event := ev.(type) { + // Handle governance proposal events creation events + case govtypes.EventSubmitProposal: + // Users define business logic here e.g. + fmt.Println(ev.FromAddress, ev.ProposalId, ev.Proposal) + return nil + default: + return nil + } +} + +// TxEmitter is an example of an event emitter that emits just transaction events. This can and +// should be implemented somewhere in the SDK. The SDK can include an EventEmitters for tm.event='Tx' +// and/or tm.event='NewBlock' (the new block events may contain typed events) +func TxEmitter(ctx context.Context, cliCtx client.Context, ehs ...EventHandler) (err error) { + // Instantiate and start tendermint RPC client + client, err := cliCtx.GetNode() + if err != nil { + return err + } + + if err = client.Start(); err != nil { + return err + } + + // Start the pubsub bus + bus := pubsub.NewBus() + defer bus.Close() + + // Initialize a new error group + eg, ctx := errgroup.WithContext(ctx) + + // Publish chain events to the pubsub bus + eg.Go(func() error { + return PublishChainTxEvents(ctx, client, bus, simapp.ModuleBasics) + }) + + // Subscribe to the bus events + subscriber, err := bus.Subscribe() + if err != nil { + return err + } + + // Handle all the events coming out of the bus + eg.Go(func() error { + var err error + for { + select { + case <-ctx.Done(): + return nil + case <-subscriber.Done(): + return nil + case ev := <-subscriber.Events(): + for _, eh := range ehs { + if err = eh(ev); err != nil { + break + } + } + } + } + return nil + }) + + return group.Wait() +} + +// PublishChainTxEvents events using 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 + txch, err := client.Subscribe(ctx, "txevents", "tm.event='Tx'", 100) + if err != nil { + return err + } + + // Unsubscribe from transaction events on function exit + defer func() { + err = client.UnsubscribeAll(ctx, "txevents") + }() + + // Use errgroup to manage concurrency + g, ctx := errgroup.WithContext(ctx) + + // Publish transaction events in a goroutine + g.Go(func() error { + var err error + for { + select { + case <-ctx.Done(): + break + case ed := <-ch: + switch evt := ed.Data.(type) { + case tmtypes.EventDataTx: + if !evt.Result.IsOK() { + continue + } + // range over events, parse them using the basic manager and + // send them to the pubsub bus + for _, abciEv := range events { + typedEvent, err := sdk.ParseTypedEvent(abciEv) + if err != nil { + return er + } + if err := bus.Publish(typedEvent); err != nil { + bus.Close() + return + } + continue + } + } + } + } + return err + }) + + // Exit on error or context cancelation + return g.Wait() +} +``` + +## References + +- [Publish Custom Events via a bus](https://github.com/ovrclk/akash/blob/90d258caeb933b611d575355b8df281208a214f8/events/publish.go#L19-L58) +- [Consuming the events in `Client`](https://github.com/ovrclk/deploy/blob/bf6c633ab6c68f3026df59efd9982d6ca1bf0561/cmd/event-handlers.go#L57) diff --git a/versioned_docs/version-0.45/integrate/architecture/adr-033-protobuf-inter-module-comm.md b/versioned_docs/version-0.45/integrate/architecture/adr-033-protobuf-inter-module-comm.md new file mode 100644 index 000000000..6234c3d10 --- /dev/null +++ b/versioned_docs/version-0.45/integrate/architecture/adr-033-protobuf-inter-module-comm.md @@ -0,0 +1,400 @@ +# ADR 033: Protobuf-based Inter-Module Communication + +## Changelog + +- 2020-10-05: Initial Draft + +## 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: + +- 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 + +## Context + +In the current Cosmos SDK documentation on the [Object-Capability Model](../core/ocap.md), it is stated that: + +> 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. + +There is currently not a thriving ecosystem of Cosmos SDK modules. We hypothesize that this is in part due to: + +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. + +### `x/bank` Case Study + +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. + +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. + +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. + +## 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. + +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. + +### 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: + +```go +package bank + +type MsgClient interface { + Send(context.Context, *MsgSend, opts ...grpc.CallOption) (*MsgSendResponse, error) +} + +type MsgServer interface { + Send(context.Context, *MsgSend) (*MsgSendResponse, error) +} +``` + +[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. + +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. + +Using this `QueryClient`/`MsgClient` approach has the following key benefits over exposing keepers to external modules: + +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 + +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 + +### 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. + +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`. + +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. + +Here's an example of a hypothetical module `foo` interacting with `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), + } +} + +func (foo *FooMsgServer) Bar(ctx context.Context, req *MsgBarRequest) (*MsgBarResponse, error) { + balance, err := foo.bankQuery.Balance(&bank.QueryBalanceRequest{Address: fooMsgServer.moduleKey.Address(), Denom: "foo"}) + + ... + + res, err := foo.bankMsg.Send(ctx, &bank.MsgSendRequest{FromAddress: fooMsgServer.moduleKey.Address(), ...}) + + ... +} +``` + +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)). + +### `ModuleKey`s and `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): + +```go +type ModuleID struct { + ModuleName string + Path []byte +} + +func (key ModuleID) Address() []byte { + return AddressHash(key.ModuleName, key.Path) +} +``` + +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. + +The two `ModuleKey` types are `RootModuleKey` and `DerivedModuleKey`: + +```go +type Invoker func(callInfo CallInfo) func(ctx context.Context, request, response interface{}, opts ...interface{}) error + +type CallInfo { + Method string + Caller ModuleID +} + +type RootModuleKey struct { + moduleName string + invoker Invoker +} + +func (rm RootModuleKey) Derive(path []byte) DerivedModuleKey { /* ... */} + +type DerivedModuleKey struct { + moduleName string + path []byte + invoker Invoker +} +``` + +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: + +```go +package foo + +func (fooMsgServer *MsgServer) Bar(ctx context.Context, req *MsgBar) (*MsgBarResponse, error) { + derivedKey := fooMsgServer.moduleKey.Derive(req.SomePath) + bankMsgClient := bank.NewMsgClient(derivedKey) + res, err := bankMsgClient.Balance(ctx, &bank.MsgSend{FromAddress: derivedKey.Address(), ...}) + ... +} +``` + +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. + +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. + +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`: + +```go +func (key RootModuleKey) Invoke(ctx context.Context, method string, args, reply interface{}, opts ...grpc.CallOption) error { + f := key.invoker(CallInfo {Method: method, Caller: ModuleID {ModuleName: key.moduleName}}) + return f(ctx, args, reply) +} +``` + +### `AppModule` Wiring and Requirements + +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()`: + +```go +type Configurator interface { + MsgServer() grpc.Server + QueryServer() grpc.Server + + ModuleKey() ModuleKey + RequireServer(msgServer 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. + +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: + +```go +package foo + +func (am AppModule) RegisterServices(cfg Configurator) { + cfg.RequireServer((*bank.QueryServer)(nil)) + cfg.RequireServer((*bank.MsgServer)(nil)) +} +``` + +### Security Considerations + +In addition to checking for `ModuleKey` permissions, a few additional security precautions will need to be taken by +the underlying router infrastructure. + +#### 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. + +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. + +#### 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. + +### 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`: + +```go +type Configurator interface { + MsgServer() grpc.Server + QueryServer() grpc.Server + InternalServer() grpc.Server +} +``` + +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. + +Services registered against `InternalServer` will be callable from other modules but not by external clients. + +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. + +### Authorization + +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 + +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 + +### MsgServices vs `x/capability` + +The `x/capability` module does provide a proper object-capability implementation that can be used by any module in the +SDK and could even be used for inter-module OCAPs as described in [\#5931](https://github.com/cosmos/cosmos-sdk/issues/5931). + +The advantages of the approach described in this ADR are mostly around how it integrates with other parts of the SDK, +specifically: + +* 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` + +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. + +## Consequences + +### 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 + +- 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 moule-to-module calls + +### 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) diff --git a/versioned_docs/version-0.45/integrate/architecture/adr-034-account-rekeying.md b/versioned_docs/version-0.45/integrate/architecture/adr-034-account-rekeying.md new file mode 100644 index 000000000..d3b54d17f --- /dev/null +++ b/versioned_docs/version-0.45/integrate/architecture/adr-034-account-rekeying.md @@ -0,0 +1,76 @@ +# ADR 034: Account Rekeying + +## Changelog + +- 30-09-2020: Initial Draft + +## Status + +PROPOSED + +## Abstract + +Account rekeying is a process hat allows an account to replace its authentication pubkey with a new one. + +## Context + +Currently, in the Cosmos SDK, the address of an auth `BaseAccount` is based on the hash of the public key. Once an account is created, the public key for the account is set in stone, and cannot be changed. This can be a problem for users, as key rotation is a useful security practice, but is not possible currently. Furthermore, as multisigs are a type of pubkey, once a multisig for an account is set, it can not be updated. This is problematic, as multisigs are often used by organizations or companies, who may need to change their set of multisig signers for internal reasons. + +Transferring all the assets of an account to a new account with the updated pubkey is not sufficient, because some "engagements" of an account are not easily transferable. For example, in staking, to transfer bonded Atoms, an account would have to unbond all delegations and wait the three week unbonding period. Even more significantly, for validator operators, ownership over a validator is not transferrable at all, meaning that the operator key for a validator can never be updated, leading to poor operational security for validators. + +## Decision + +We propose the addition of a new feature to `x/auth` that allows accounts to update the public key associated with their account, while keeping the address the same. + +This is possible because the Cosmos SDK `BaseAccount` stores the public key for an account in state, instead of making the assumption that the public key is included in the transaction (whether explicitly or implicitly through the signature) as in other blockchains such as Bitcoin and Ethereum. Because the public key is stored on chain, it is okay for the public key to not hash to the address of an account, as the address is not pertinent to the signature checking process. + +To build this system, we design a new Msg type as follows: + +```protobuf +service Msg { + rpc ChangePubKey(MsgChangePubKey) returns (MsgChangePubKeyResponse); +} + +message MsgChangePubKey { + string address = 1; + google.protobuf.Any pub_key = 2; +} + +message MsgChangePubKeyResponse {} +``` + +The MsgChangePubKey transaction needs to be signed by the existing pubkey in state. + +Once, approved, the handler for this message type, which takes in the AccountKeeper, will update the in-state pubkey for the account and replace it with the pubkey from the Msg. + +An account that has had its pubkey changed cannot be automatically pruned from state. This is because if pruned, the original pubkey of the account would be needed to recreate the same address, but the owner of the address may not have the original pubkey anymore. Currently, we do not automatically prune any accounts anyways, but we would like to keep this option open the road (this is the purpose of account numbers). To resolve this, we charge an additional gas fee for this operation to compensate for this this externality (this bound gas amount is configured as parameter `PubKeyChangeCost`). The bonus gas is charged inside the handler, using the `ConsumeGas` function. Furthermore, in the future, we can allow accounts that have rekeyed manually prune themselves using a new Msg type such as `MsgDeleteAccount`. Manually pruning accounts can give a gas refund as an incentive for performing the action. + +```go + amount := ak.GetParams(ctx).PubKeyChangeCost + ctx.GasMeter().ConsumeGas(amount, "pubkey change fee") +``` + +Everytime a key for an address is changed, we will store a log of this change in the state of the chain, thus creating a stack of all previous keys for an address and the time intervals for which they were active. This allows dapps and clients to easily query past keys for an account which may be useful for features such as verifying timestamped off-chain signed messages. + +## Consequences + +### Positive + +* Will allow users and validator operators to employ better operational security practices with key rotation. +* Will allow organizations or groups to easily change and add/remove multisig signers. + +### Negative + +Breaks the current assumed relationship between address and pubkeys as H(pubkey) = address. This has a couple of consequences. + +* This makes wallets that support this feature more complicated. For example, if an address on chain was updated, the corresponding key in the CLI wallet also needs to be updated. +* Cannot automatically prune accounts with 0 balance that have had their pubkey changed. + +### Neutral + +* While the purpose of this is intended to allow the owner of an account to update to a new pubkey they own, this could technically also be used to transfer ownership of an account to a new owner. For example, this could be use used to sell a staked position without unbonding or an account that has vesting tokens. However, the friction of this is very high as this would essentially have to be done as a very specific OTC trade. Furthermore, additional constraints could be added to prevent accouns with Vesting tokens to use this feature. +* Will require that PubKeys for an account are included in the genesis exports. + +## References + ++ https://www.algorand.com/resources/blog/announcing-rekeying diff --git a/versioned_docs/version-0.45/integrate/architecture/adr-035-rosetta-api-support.md b/versioned_docs/version-0.45/integrate/architecture/adr-035-rosetta-api-support.md new file mode 100644 index 000000000..fe85405a5 --- /dev/null +++ b/versioned_docs/version-0.45/integrate/architecture/adr-035-rosetta-api-support.md @@ -0,0 +1,211 @@ +# ADR 035: Rosetta API Support + +## Authors + +- Jonathan Gimeno (@jgimeno) +- David Grierson (@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 SDK. + +## Context + +[Rosetta API](https://www.rosetta-api.org/) is an open-source specification and set of tools developed by Coinbase to +standardise blockchain interactions. + +Through the use of a standard API for integrating blockchain applications it will + +* Be easier for a user to interact with a given blockchain +* Allow exchanges to integrate new blockchains quickly and easily +* Enable application developers to build cross-blockchain applications such as block explorers, wallets and dApps at + considerably lower cost and effort. + +## Decision + +It is clear that adding Rosetta API support to the Cosmos SDK will bring value to all the developers and +Cosmos SDK based chains in the ecosystem. How it is implemented is key. + +The driving principles of the proposed design are: + +1. **Extensibility:** it must be as riskless and painless as possible for application developers to set-up network + configurations to expose Rosetta API-compliant services. +2. **Long term support:** This proposal aims to provide support for all the supported Cosmos SDK release series. +3. **Cost-efficiency:** Backporting changes to Rosetta API specifications from `master` to the various stable + branches of Cosmos SDK is a cost that needs to be reduced. + +We will achieve these delivering on these principles by the following: + +1. There will be 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. + +## 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. + +The constructor follows: + +`func NewServer(settings Settings) (Server, error)` + +`Settings`, which are used to construct a new server, are the following: + +```go +// Settings define the rosetta server settings +type Settings struct { + // Network contains the information regarding the network + Network *types.NetworkIdentifier + // Client is the online API handler + Client crgtypes.Client + // Listen is the address the handler will listen at + Listen string + // 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 int + // 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. + +Each Cosmos SDK release series will have their own `Client` implementations. +Developers can implement their own custom `Client`s as required. + +```go +// Client defines the API the client implementation should provide. +type Client interface { + // 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() error + + // 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(ctx context.Context, addr string, height *int64) ([]*types.Amount, error) + // 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 + BlockByHeight(ctx context.Context, height *int64) (BlockResponse, error) + // 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. + BlockTransactionsByHeight(ctx context.Context, height *int64) (BlockTransactionsResponse, error) + // 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(ctx context.Context, hash string) (*types.Transaction, error) + // 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(ctx context.Context) ([]*types.Peer, error) + // Status returns the node status, such as sync data, version etc + Status(ctx context.Context) (*types.SyncStatus, error) + + // Construction API + + // 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(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 +type OfflineClient interface { + NetworkInformationProvider + // 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(signed bool, hexBytes []byte) (ops []*types.Operation, signers []*types.AccountIdentifier, err error) + // 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(ctx context.Context, req *types.ConstructionPreprocessRequest) (options map[string]interface{}, err error) + // AccountIdentifierFromPublicKey returns the account identifier given the public key + AccountIdentifierFromPublicKey(pubKey *types.PublicKey) (*types.AccountIdentifier, error) +} +``` + +### 2. Cosmos SDK Implementation + +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. + +The rosetta.Msg interface follows: + +```go +// 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 + FromOperations(ops []*types.Operation) (sdk.Msg, error) +} +``` + +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. + +### 3. API service invocation + +As stated at the start, application developers will have two methods for invocation of the Rosetta API service: + +1. Shared process for both application and API +2. Standalone API service + +#### Shared Process (Only Stargate) + +Rosetta API service could run within the same execution process as the application. 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). + +#### Separate API service + +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. + +## Status + +Proposed + +## Consequences + +### Positive + +- Out-of-the-box Rosetta API support within Cosmos SDK. +- Blockchain interface standardisation + +## References + +- https://www.rosetta-api.org/ diff --git a/versioned_docs/version-0.45/integrate/architecture/adr-036-arbitrary-signature.md b/versioned_docs/version-0.45/integrate/architecture/adr-036-arbitrary-signature.md new file mode 100644 index 000000000..0d0737bff --- /dev/null +++ b/versioned_docs/version-0.45/integrate/architecture/adr-036-arbitrary-signature.md @@ -0,0 +1,132 @@ +# ADR 036: Arbitrary Message Signature Specification + +## Changelog + +- 28/10/2020 - Initial draft + +## Authors + +- Antoine Herzog (@antoineherzog) +- Zaki Manian (@zmanian) +- Aleksandr Bezobchuk (alexanderbez) [1] +- Frojdi Dymylja (@fdymylja) + +## Status + +Draft + +## Abstract + +Currently, in the 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. + +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. + +## 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. + +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. + +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 0.40 also introduces a concept of “auth_info” this can specify SIGN_MODES. + +A spec should include an `auth_info` that supports SIGN_MODE_DIRECT and SIGN_MODE_LEGACY_AMINO. + +Create the `offchain` proto definitions, we extend the auth module with `offchain` package to offer functionalities to verify and sign offline messages. + +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 + +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`. + +`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. + +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 +message MsgSignData { + // 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) + bytes Data = 2 [(gogoproto.jsontag) = "data"]; +} +``` + +Signed MsgSignData json example: + +```json +{ + "type": "cosmos-sdk/StdTx", + "value": { + "msg": [ + { + "type": "sign/MsgSignData", + "value": { + "signer": "cosmos1hftz5ugqmpg9243xeegsqqav62f8hnywsjr4xr", + "data": "cmFuZG9t" + } + } + ], + "fee": { + "amount": [], + "gas": "0" + }, + "signatures": [ + { + "pub_key": { + "type": "tendermint/PubKeySecp256k1", + "value": "AqnDSiRoFmTPfq97xxEb2VkQ/Hm28cPsqsZm9jEVsYK9" + }, + "signature": "8y8i34qJakkjse9pOD2De+dnlc4KvFgh0wQpes4eydN66D9kv7cmCEouRrkka9tlW9cAkIL52ErB+6ye7X5aEg==" + } + ], + "memo": "" + } +} +``` + +## 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]. + +### Negative + +- Current proposal requires a fixed relationship between an account address and a public key. +- Doesn't work with multisig accounts. + +## Further discussion + +- 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 diff --git a/versioned_docs/version-0.45/integrate/architecture/adr-037-gov-split-vote.md b/versioned_docs/version-0.45/integrate/architecture/adr-037-gov-split-vote.md new file mode 100644 index 000000000..742fdd108 --- /dev/null +++ b/versioned_docs/version-0.45/integrate/architecture/adr-037-gov-split-vote.md @@ -0,0 +1,111 @@ +# ADR 037: Governance split votes + +## Changelog + +- 2020/10/28: Intial draft + +## 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. + +## Context + +Currently, an address can cast a vote with only one options (Yes/No/Abstain/NoWithVeto) and use their full voting power behind that choice. + +However, often times the entity owning that address might not be a single individual. For example, a company might have different stakeholders who want to vote differently, and so it makes sense to allow them to split their voting power. Another example use case is exchanges. Many centralized exchanges often stake a portion of their users' tokens in their custody. Currently, it is not possible for them to do "passthrough voting" and giving their users voting rights over their tokens. However, with this system, exchanges can poll their users for voting preferences, and then vote on-chain proportionally to the results of the poll. + +## Decision + +We modify the vote structs to be + +``` +type WeightedVoteOption struct { + Option string + Weight sdk.Dec +} + +type Vote struct { + ProposalID int64 + Voter sdk.Address + Options []WeightedVoteOption +} +``` + +And for backwards compatibility, we introduce `MsgVoteWeighted` while keeping `MsgVote`. + +``` +type MsgVote struct { + ProposalID int64 + Voter sdk.Address + Option Option +} + +type MsgVoteWeighted struct { + ProposalID int64 + Voter sdk.Address + Options []WeightedVoteOption +} +``` + +The `ValidateBasic` of a `MsgVoteWeighted` struct would require that + +1. The sum of all the Rates is equal to 1.0 +2. No Option is repeated + +The governance tally function will iterate over all the options in a vote and add to the tally the result of the voter's voting power * the rate for that option. + +``` +tally() { + results := map[types.VoteOption]sdk.Dec + + for _, vote := range votes { + for i, weightedOption := range vote.Options { + results[weightedOption.Option] += getVotingPower(vote.voter) * weightedOption.Weight + } + } +} +``` + +The CLI command for creating a multi-option vote would be as such: + +```sh +simd tx gov vote 1 "yes=0.6,no=0.3,abstain=0.05,no_with_veto=0.05" --from mykey +``` + +To create a single-option vote a user can do either + +``` +simd tx gov vote 1 "yes=1" --from mykey +``` + +or + +```sh +simd tx gov vote 1 yes --from mykey +``` + +to maintain backwards compatibility. + +## Consequences + +### Backwards Compatibility + +- Previous VoteMsg types will remain the same and so clients will not have to update their procedure unless they want to support the WeightedVoteMsg feature. +- When querying a Vote struct from state, its structure will be different, and so clients wanting to display all voters and their respective votes will have to handle the new format and the fact that a single voter can have split votes. +- The result of querying the tally function should have the same API for clients. + +### Positive + +- Can make the voting process more accurate for addresses representing multiple stakeholders, often some of the largest addresses. + +### Negative + +- Is more complex than simple voting, and so may be harder to explain to users. However, this is mostly mitigated because the feature is opt-in. + +### Neutral + +- Relatively minor change to governance tally function. diff --git a/versioned_docs/version-0.45/integrate/architecture/adr-038-state-listening.md b/versioned_docs/version-0.45/integrate/architecture/adr-038-state-listening.md new file mode 100644 index 000000000..74f92d2f6 --- /dev/null +++ b/versioned_docs/version-0.45/integrate/architecture/adr-038-state-listening.md @@ -0,0 +1,569 @@ +# ADR 038: KVStore state listening + +## Changelog + +* 11/23/2020: Initial draft +* 10/14/2022: + * Add `ListenCommit`, flatten the state writes in a block to a single batch. + * Remove listeners from cache stores, should only listen to `rootmulti.Store`. + * Remove `HaltAppOnDeliveryError()`, the errors are propogated by default, the implementations should return nil if don't want to propogate errors. + + +## 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. + +## 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. + +## Decision + +We will modify the `CommitMultiStore` interface and its concrete (`rootmulti`) implementations and introduce a new `listenkv.Store` to allow listening to state changes in underlying KVStores. We don't need to listen to cache stores, because we can't be sure that the writes will be committed eventually, and the writes are duplicated in `rootmulti.Store` eventually, so we should only listen to `rootmulti.Store`. +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. + +### Listening interface + +In a new file, `store/types/listening.go`, we will create a `WriteListener` interface for streaming out state changes from a KVStore. + +```go +// 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 + OnWrite(storeKey StoreKey, key []byte, value []byte, delete bool) error +} +``` + +### Listener type + +We will create two concrete implementations of the `WriteListener` interface in `store/types/listening.go`, that writes out protobuf +encoded KV pairs to an underlying `io.Writer`, and simply accumulate them in memory. + +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. + +```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 + 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 +type StoreKVPairWriteListener struct { + writer io.Writer + marshaller 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, + marshaller: m, + } +} + +// 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() + kvPair.Delete = Delete + kvPair.Key = key + kvPair.Value = value + by, err := wl.marshaller.MarshalBinaryLengthPrefixed(kvPair) + if err != nil { + return err + } + if _, err := wl.writer.Write(by); err != nil { + return err + } + return nil +} +``` + +```golang +// MemoryListener listens to the state writes and accumulate the records in memory. +type MemoryListener struct { + key StoreKey + stateCache []StoreKVPair +} + +// NewMemoryListener creates a listener that accumulate the state writes in memory. +func NewMemoryListener(key StoreKey) *MemoryListener { + return &MemoryListener{key: key} +} + +// OnWrite implements WriteListener interface +func (fl *MemoryListener) OnWrite(storeKey StoreKey, key []byte, value []byte, delete bool) error { + fl.stateCache = append(fl.stateCache, StoreKVPair{ + StoreKey: storeKey.Name(), + Delete: delete, + Key: key, + Value: value, + }) + return nil +} + +// PopStateCache returns the current state caches and set to nil +func (fl *MemoryListener) PopStateCache() []StoreKVPair { + res := fl.stateCache + fl.stateCache = nil + return res +} + +// StoreKey returns the storeKey it listens to +func (fl *MemoryListener) StoreKey() StoreKey { + return fl.key +} +``` + +### 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. + +```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 +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. +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. +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. +func (s *Store) Delete(key []byte) { + s.parent.Delete(key) + s.onWrite(true, key, nil) +} + +// 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 + } + } +} +``` + +### MultiStore interface updates + +We will update the `CommitMultiStore` interface to allow us to wrap a set of listeners around a specific `KVStore`. + +```go +type CommitMultiStore interface { + ... + + // 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(key StoreKey, listeners []WriteListener) +} +``` + +### MultiStore implementation updates + +We will modify all of the `CommitMultiStore` 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`. + +```go +func (rs *Store) GetKVStore(key types.StoreKey) types.KVStore { + store := rs.stores[key].(types.KVStore) + + if rs.TracingEnabled() { + store = tracekv.NewStore(store, rs.traceWriter, rs.traceContext) + } + if rs.ListeningEnabled(key) { + store = listenkv.NewStore(key, store, rs.listeners[key]) + } + + return store +} +``` + +We will also adjust the `rootmulti` `CacheMultiStore` method to wrap the stores with `listenkv.Store` to enable listening when the cache layer writes. + +```go +func (rs *Store) CacheMultiStore() types.CacheMultiStore { + stores := make(map[types.StoreKey]types.CacheWrapper) + for k, v := range rs.stores { + store := v.(types.KVStore) + // Wire the listenkv.Store to allow listeners to observe the writes from the cache store, + // set same listeners on cache store will observe duplicated writes. + if rs.ListeningEnabled(k) { + store = listenkv.NewStore(store, k, rs.listeners[k]) + } + stores[k] = store + } + return cachemulti.NewStore(rs.db, stores, rs.keysByName, rs.traceWriter, rs.getTracingContext()) +} +``` + +### Exposing the data + +#### 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 observe those block metadatas as well. + +The `WriteListener`s of `StreamingService` listens to the `rootmulti.Store`, which is only written into at commit event by the cache store of `deliverState`. + +```go +// 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(ctx types.Context, req abci.RequestBeginBlock, res abci.ResponseBeginBlock) error + // 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(ctx types.Context, req abci.RequestDeliverTx, res abci.ResponseDeliverTx) error + // ListenCommit updates the steaming service with the latest Commit message, + // All the state writes of current block should have notified before this message. + ListenCommit(ctx types.Context, res abci.ResponseCommit) error +} + +// 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(wg *sync.WaitGroup) error + // 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 + // Closer interface + io.Closer +} +``` + +#### BaseApp registration + +We will add a new method to the `BaseApp` to enable the registration of `StreamingService`s: + +```go +// 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 + 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 + app.abciListeners = append(app.abciListeners, s) +} +``` + +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`. + +```go +func (app *BaseApp) BeginBlock(req abci.RequestBeginBlock) (res abci.ResponseBeginBlock) { + + ... + + defer func() { + // call the hooks with the BeginBlock messages + for _, streamingListener := range app.abciListeners { + if err := streamingListener.ListenBeginBlock(app.deliverState.ctx, req, res); err != nil { + panic(sdkerrors.Wrapf(err, "BeginBlock listening hook failed, height: %d", req.Header.Height)) + } + } + }() + + return res +} +``` + +```go +func (app *BaseApp) EndBlock(req abci.RequestEndBlock) (res abci.ResponseEndBlock) { + + ... + + defer func() { + // Call the streaming service hooks with the EndBlock messages + for _, streamingListener := range app.abciListeners { + if err := streamingListener.ListenEndBlock(app.deliverState.ctx, req, res); err != nil { + panic(sdkerrors.Wrapf(err, "EndBlock listening hook failed, height: %d", req.Height)) + } + } + }() + + return res +} +``` + +```go +func (app *BaseApp) DeliverTx(req abci.RequestDeliverTx) (res abci.ResponseDeliverTx) { + + defer func() { + // call the hooks with the DeliverTx messages + for _, streamingListener := range app.abciListeners { + if err := streamingListener.ListenDeliverTx(app.deliverState.ctx, req, res); err != nil { + panic(sdkerrors.Wrap(err, "DeliverTx listening hook failed")) + } + } + }() + + ... + + return res +} +``` + +```golang +func (app *BaseApp) Commit() abci.ResponseCommit { + header := app.deliverState.ctx.BlockHeader() + retainHeight := app.GetBlockRetentionHeight(header.Height) + + // Write the DeliverTx state into branched storage and commit the MultiStore. + // The write to the DeliverTx state writes all state transitions to the root + // MultiStore (app.cms) so when Commit() is called is persists those values. + app.deliverState.ms.Write() + commitID := app.cms.Commit() + + res := abci.ResponseCommit{ + Data: commitID.Hash, + RetainHeight: retainHeight, + } + + // call the hooks with the Commit message + for _, streamingListener := range app.abciListeners { + if err := streamingListener.ListenCommit(app.deliverState.ctx, res); err != nil { + panic(sdkerrors.Wrapf(err, "Commit listening hook failed, height: %d", header.Height)) + } + } + + app.logger.Info("commit synced", "commit", fmt.Sprintf("%X", commitID)) + ... +} +``` + +#### Error Handling And Async Consumers + +`ABCIListener`s are called synchronously inside the consensus state machine, the returned error causes panic which in turn halt the consensus state machine. The implementer should be careful not to break consensus unexpectedly or slow down it too much. + +For some async use cases, one can spawn a go-routine internanlly to avoid slow down consensus state machine, and handle the errors internally and always returns `nil` to avoid halting consensus state machine on error. + +Furthermore, for most of the cases, we only need to use the builtin file streamer to listen to state changes directly inside cosmos-sdk, the other consumers should subscribe to the file streamer output externally. + +#### File Streamer + +We provide a minimal filesystem based implementation inside cosmos-sdk, and provides options to write output files reliably, the output files can be further consumed by external consumers, so most of the state listeners actually don't need to live inside the sdk and node, which improves the node robustness and simplify sdk internals. + +The file streamer can be wired in app like this: +```golang +exposeStoreKeys := ... // decide the key list to listen +service, err := file.NewStreamingService(streamingDir, "", exposeStoreKeys, appCodec, logger) +bApp.SetStreamingService(service) +``` + +#### 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: + +```go +// 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() string + + // 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(env serverTypes.AppOptions) error + + // 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. + +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. + +```go +// 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(bApp *baseapp.BaseApp, marshaller codec.BinaryCodec, keys map[string]*types.KVStoreKey) error + + // Start starts the background streaming process of the plugin streaming service + Start(wg *sync.WaitGroup) error + + // 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. + +e.g. in `NewSimApp`: + +```go +func NewSimApp( + logger log.Logger, + db dbm.DB, + traceStore io.Writer, + loadLatest bool, + appOpts servertypes.AppOptions, + baseAppOptions ...func(*baseapp.BaseApp), +) *SimApp { + + ... + + keys := sdk.NewKVStoreKeys( + authtypes.StoreKey, banktypes.StoreKey, stakingtypes.StoreKey, + minttypes.StoreKey, distrtypes.StoreKey, slashingtypes.StoreKey, + govtypes.StoreKey, paramstypes.StoreKey, ibchost.StoreKey, upgradetypes.StoreKey, + evidencetypes.StoreKey, ibctransfertypes.StoreKey, capabilitytypes.StoreKey, + ) + + pluginsOnKey := fmt.Sprintf("%s.%s", plugin.PLUGINS_TOML_KEY, plugin.PLUGINS_ON_TOML_KEY) + if cast.ToBool(appOpts.Get(pluginsOnKey)) { + // this loads the preloaded and any plugins found in `plugins.dir` + pluginLoader, err := loader.NewPluginLoader(appOpts, logger) + if err != nil { + // handle error + } + + // initialize the loaded plugins + if err := pluginLoader.Initialize(); err != nil { + // handle error + } + + // register the plugin(s) with the BaseApp + if err := pluginLoader.Inject(bApp, appCodec, keys); err != nil { + // handle error + } + + // 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 + } + } + + ... + + return app +} +``` + + +#### Configuration + +The plugin system will be configured within an app's app.toml file. + +```toml +[plugins] + on = false # turn the plugin system, as a whole, on or off + enabled = ["list", "of", "plugin", "names", "to", "enable"] + 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.enabled` 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.enabled` provides `opt-in` semantics to plugin names to enable (including preloaded plugins). + +Configuration of a given plugin is ultimately specific to the plugin, but we will introduce some standards here: + +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 flag (e.g. `plugins.streaming.file.halt_app_on_delivery_error`) +that signifies whether the service operates in a fire-and-forget capacity, or stop the BaseApp when an error occurs in +any of `ListenBeginBlock`, `ListenEndBlock` and `ListenDeliverTx`. + +e.g. + +```toml +[plugins] + on = false # turn the plugin system, as a whole, on or off + enabled = ["list", "of", "plugin", "names", "to", "enable"] + dir = "the directory to load non-preloaded plugins from; defaults to " + [plugins.streaming] # a mapping of plugin-specific streaming service parameters, mapped to their plugin name + [plugins.streaming.file] # the specific parameters for the file streaming service plugin + keys = ["list", "of", "store", "keys", "we", "want", "to", "expose", "for", "this", "streaming", "service"] + write_dir = "path to the write directory" + prefix = "optional prefix to prepend to the generated file names" + halt_app_on_delivery_error = "false" # false == fire-and-forget; true == stop the application + [plugins.streaming.kafka] + keys = [] + topic_prefix = "block" # Optional prefix for topic names where data will be stored. + flush_timeout_ms = 5000 # Flush and wait for outstanding messages and requests to complete delivery when calling `StreamingService.Close(). (milliseconds) + halt_app_on_delivery_error = true # Whether or not to halt the application when plugin fails to deliver message(s). + ... +``` + +#### 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 + +These changes will provide a means of subscribing to KVStore state changes in real time. + +### Backwards Compatibility + +* This ADR changes the `CommitMultiStore` interface, implementations supporting the previous version of these interfaces will not support the new ones + +### Positive + +* Ability to listen to KVStore state changes in real time and expose these events to external consumers + +### Negative + +* Changes `CommitMultiStore`interface + +### 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 diff --git a/versioned_docs/version-0.45/integrate/architecture/adr-039-epoched-staking.md b/versioned_docs/version-0.45/integrate/architecture/adr-039-epoched-staking.md new file mode 100644 index 000000000..44c1f1408 --- /dev/null +++ b/versioned_docs/version-0.45/integrate/architecture/adr-039-epoched-staking.md @@ -0,0 +1,122 @@ +# ADR 039: Epoched Staking + +## Changelog + +- 10-Feb-2021: Initial Draft + +## Authors + +- Dev Ojha (@valardragon) +- Sunny Aggarwal (@sunnya97) + +## 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. + +## 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. + +* 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. + +* 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) + +* 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. + +## 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. + +### 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 + +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. + +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. + +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__: Implement buffering of all staking and slashing messages. + +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**: 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**: 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**: 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__: 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) + +__Step-3__: Adjust gas + +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. diff --git a/versioned_docs/version-0.45/integrate/architecture/adr-040-storage-and-smt-state-commitments.md b/versioned_docs/version-0.45/integrate/architecture/adr-040-storage-and-smt-state-commitments.md new file mode 100644 index 000000000..115723576 --- /dev/null +++ b/versioned_docs/version-0.45/integrate/architecture/adr-040-storage-and-smt-state-commitments.md @@ -0,0 +1,164 @@ +# ADR 040: Storage and SMT State Commitments + +## Changelog + +- 2020-01-15: Draft + +## Status + +DRAFT Not Implemented + +## Abstract + +Sparse Merke 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 SDK transition from IAVL to SMT. + +## Context + +Currently, Cosmos SDK uses IAVL for both state [commitments](https://cryptography.fandom.com/wiki/Commitment_scheme) and data storage. + +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: + ++ Each object query requires a tree traversal from the root. Subsequent queries for the same object are cached on the 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 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 +). + +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. + +## 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 [LazyLedgers' SMT](https://github.com/lazyledger/smt). LazyLedger 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. + +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. + +`SS` (SMT) is used to commit to a data and compute merkle proofs. `SC` 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). `SC` will store each `(key, value)` pair directly (map key -> value). + +SMT is a merkle tree structure: we don't store keys directly. For every `(key, value)` pair, `hash(key)` is stored in a path (we hash a key to evenly distribute keys in the tree) and `hash(key, value)` in a leaf. Since we don't know a structure of a value (in particular if it contains the key) we hash both the key and the value in the `SC` leaf. + +For data access we propose 2 additional KV buckets (namespaces for the key-value pairs, sometimes called [column family](https://github.com/facebook/rocksdb/wiki/Terminology)): + +1. B1: `key → value`: the principal object storage, used by a state machine, behind the SDK `KVStore` interface: provides direct access by key and allows prefix iteration (KV DB backend must support it). +2. B2: `hash(key, value) → key`: a reverse index to get a key from an SMT path. Recall that SMT will store `(k, v)` as `(hash(k), hash(key, value))`. So, we can get an object value by composing `SMT_path → B2 → B1`. +3. we could use more buckets to optimize the app usage if needed. + +Above, we propose to use a KV DB. However, for the state machine, we could use an RDBMS, which we discuss below. + +### 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 ++ pruning (garbage collection) + +### LazyLedger SMT for State Commitment + +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. + +### 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). + +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 to efficiently deliver DB state at a certain stage. +Some DB engines support snapshotting. Hence, we propose to reuse that functionality for the state sync and versioning (described below). It will the supported DB engines to ones which efficiently implement snapshots. In a final section we will discuss evaluated DBs. + +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 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. + +A new `SS` snapshot will be created in every `EndBlocker` and identified by a block height. The `rootmulti.Store` keeps track of the available snapshots to offer `SS` at a certain version. The `rootmulti.Store` implements the `CommitMultiStore` interface, which 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 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). + +Number of historical versions for `abci.Query` 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. + +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 snapshoting each block, we need to update that mechanism to immediately remove orphaned nodes from the storage. This is a safe operation - snapshots will keep track of the records which should be available for past versions. + +To manage the active snapshots we will either us a DB _max number of snapshots_ option (if available), or will remove snapshots in the `EndBlocker`. The latter option can be done efficiently by identifying snapshots with block height. + +#### Accessing old state versions + +One of the functional requirements is to access old state. This is done through `abci.Query` 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.Query` is configurable. Accessing an old state is done by using available snapshots. +`abci.Query` doesn't need old state of `SC`. So, for efficiency, we should keep `SC` and `SS` in different databases (however using the same DB engine). + +Moreover, SDK could provide a way to directly access the state. However, a state machine shouldn't do that - since the number of snapshots is configurable, it would lead to nondeterministic execution. + +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. + +### 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)`. + +### 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. + +### 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. + +## Consequences + +### Backwards Compatibility + +This ADR doesn't introduce any SDK level API changes. + +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 + ++ 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, LazyLedger. + +### Negative + ++ Storage migration ++ LL SMT doesn't support pruning - we will need to add and test that functionality. + +### Neutral + ++ Deprecating IAVL, which is one of the core proposals of Cosmos Whitepaper. + +## Alternative designs + +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). + +Ethereum research published [Verkle Tire](https://notes.ethereum.org/_N1mutVERDKtqGIEYc-Flw#fnref1) - 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 Tire 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 + +### Evaluated KV Databases + +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 + +Use of RDBMS instead of simple KV store for state. Use of RDBMS will require an SDK API breaking change (`KVStore` interface), 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) ++ [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). diff --git a/versioned_docs/version-0.45/integrate/architecture/adr-041-in-place-store-migrations.md b/versioned_docs/version-0.45/integrate/architecture/adr-041-in-place-store-migrations.md new file mode 100644 index 000000000..1cc9ef901 --- /dev/null +++ b/versioned_docs/version-0.45/integrate/architecture/adr-041-in-place-store-migrations.md @@ -0,0 +1,167 @@ +# ADR 041: In-Place Store Migrations + +## Changelog + +- 17.02.2021: Initial Draft + +## Status + +Accepted + +## Abstract + +This ADR introduces a mechanism to perform in-place state store migrations during chain software upgrades. + +## 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). + +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)). + +## Decision + +We propose a migration procedure based on modifying the KV store in-place without involving the JSON export-process-import flow described above. + +### Module `ConsensusVersion` + +We introduce a new method on the `AppModule` interface: + +```go +type AppModule interface { + // --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 SDK, version 1 corresponds to the modules in the v0.41 series. + +### 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. + +```go +func (am AppModule) RegisterServices(cfg module.Configurator) { + // --snip-- + cfg.RegisterMigration(types.ModuleName, 1, func(ctx sdk.Context) error { + // 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. + }) + // etc. +} +``` + +For example, if the new ConsensusVersion of a module is `N` , then `N-1` migration functions MUST be registered in the configurator. + +In the 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: + +```go +// Migrator is a struct for handling in-place store migrations. +type Migrator struct { + BaseKeeper +} +``` + +Since migration functions manipulate legacy code, they should live inside the `legacy/` folder of each module, and be called by the Migrator's methods. We propose the format `Migrate{M}to{N}` for method names. + +```go +// 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/legacy/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). + +### Tracking Module Versions in `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: + +``` +0x2 | {bytes(module_name)} => BigEndian(module_consensus_version) +``` + +The initial state of the store is set from `app.go`'s `InitChainer` method. + +The UpgradeHandler signature needs to be updated to take a `VersionMap`, as well as return an upgraded `VersionMap` and an error: + +```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. + +```diff +func (k UpgradeKeeper) ApplyUpgrade(ctx sdk.Context, plan types.Plan) { + // --snip-- +- handler(ctx, plan) ++ 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 ++ 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. + +### 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: + +- 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. + +If a required migration is missing (e.g. if it has not been registered in the `Configurator`), then the `RunMigrations` function will error. + +In practice, the `RunMigrations` method should be called from inside an `UpgradeHandler`. + +```go +app.UpgradeKeeper.SetUpgradeHandler("my-plan", func(ctx sdk.Context, plan upgradetypes.Plan, vm module.VersionMap) (module.VersionMap, error) { + return app.mm.RunMigrations(ctx, vm) +}) +``` + +Assuming a chain upgrades at block `n`, the procedure should run as follows: + +- 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. + +## 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. + +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. + +### 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. + +### 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. + +### Neutral + +- The 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 SDK already has the `StoreLoader` for those operations. + +## 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 diff --git a/versioned_docs/version-0.45/integrate/architecture/adr-042-group-module.md b/versioned_docs/version-0.45/integrate/architecture/adr-042-group-module.md new file mode 100644 index 000000000..7d863f958 --- /dev/null +++ b/versioned_docs/version-0.45/integrate/architecture/adr-042-group-module.md @@ -0,0 +1,279 @@ +# ADR 042: Group Module + +## Changelog + +- 2020/04/09: Initial Draft + +## 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. + +## Context + +The legacy amino multi-signature mechanism of the Cosmos SDK has certain limitations: + +- 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)). + +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. + +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. + +## 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. + +### 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. + +```proto +message GroupInfo { + + // group_id is the unique ID of this group. + uint64 group_id = 1; + + // admin is the account address of the group's admin. + string admin = 2; + + // 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. + uint64 version = 4; + + // total_weight is the sum of the group members' weights. + string total_weight = 5; +} +``` + +```proto +message GroupMember { + + // group_id is the unique ID of the group. + uint64 group_id = 1; + + // member is the member data. + Member member = 2; +} + +// Member represents a group member with an account address, +// non-zero weight and metadata. +message Member { + + // address is the member's account address. + string address = 1; + + // 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. + 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). + +```proto +message GroupAccountInfo { + + // address is the group account address. + string address = 1; + + // 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. + string admin = 3; + + // 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. + uint64 version = 5; + + // 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. + +We define the `DecisionPolicy` interface that all decision policies must implement: + +```go +type DecisionPolicy interface { + codec.ProtoMarshaler + + ValidateBasic() error + GetTimeout() types.Duration + Allow(tally Tally, totalPower string, votingDuration time.Duration) (DecisionPolicyResult, error) + Validate(g GroupInfo) error +} + +type DecisionPolicyResult struct { + Allow bool + Final bool +} +``` + +#### 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_). + +```proto +message ThresholdDecisionPolicy { + + // 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. + 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. + +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. + +```proto +// Tally represents the sum of weighted votes. +message Tally { + option (gogoproto.goproto_getters) = false; + + // yes_count is the weighted sum of yes votes. + string yes_count = 1; + + // no_count is the weighted sum of no votes. + string no_count = 2; + + // abstain_count is the weighted sum of abstainers. + string abstain_count = 3; + + // 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. + +Voting internally updates the proposal `VoteState` as well as `Status` and `Result` if needed. + +### 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. + +#### 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. + +### 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. + +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`. + +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`. + +Proposals are stored as part of the `proposalTable` using the `Proposal` type. The `proposal_id` is an auto-increment integer. + +Votes are stored in the `voteTable`. The primary key is based on the vote's `proposal_id` and `voter` account address. + +#### ADR-033 to route proposal messages + +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. + +## Consequences + +### Positive + +- Improved UX for multi-signature accounts allowing key rotation and custom decision policies. + +### 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. + +## 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 + +## 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 SDK: [#7633](https://github.com/cosmos/cosmos-sdk/issues/7633) diff --git a/versioned_docs/version-0.45/integrate/architecture/adr-template.md b/versioned_docs/version-0.45/integrate/architecture/adr-template.md new file mode 100644 index 000000000..191cd8e95 --- /dev/null +++ b/versioned_docs/version-0.45/integrate/architecture/adr-template.md @@ -0,0 +1,60 @@ +# ADR {ADR-NUMBER}: {TITLE} + +## Changelog + +- {date}: {changelog} + +## Status + +{DRAFT | PROPOSED} Not Implemented + +> Please have a look at the [PROCESS](./PROCESS.md#adr-status) page. +> Use DRAFT if the ADR is in a draft stage (draft PR) or PROPOSED if it's in review. + +## Abstract + +> "If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the ADR. +> A short (~200 word) description of the issue being addressed. + +## Context + +> This section describes the forces at play, including technological, political, social, and project local. These forces are probably in tension, and should be called out as such. The language in this section is value-neutral. It is simply describing facts. It should clearly explain the problem and motivation that the proposal aims to resolve. +> {context body} + +## Decision + +> This section describes our response to these forces. It is stated in full sentences, with active voice. "We will ..." +> {decision body} + +## Consequences + +> This section describes the resulting context, after applying the decision. All consequences should be listed here, not just the "positive" ones. A particular decision may have positive, negative, and neutral consequences, but all of them affect the team and project in the future. + +### Backwards Compatibility + +> All ADRs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The ADR must explain how the author proposes to deal with these incompatibilities. ADR submissions without a sufficient backwards compatibility treatise may be rejected outright. + +### Positive + +{positive consequences} + +### Negative + +{negative consequences} + +### Neutral + +{neutral consequences} + +## Further Discussions + +While an ADR is in the DRAFT or PROPOSED stage, this section should contain a summary of issues to be solved in future iterations (usually referencing comments from a pull-request discussion). +Later, this section can optionally list ideas or improvements the author or reviewers found during the analysis of this ADR. + +## Test Cases [optional] + +Test cases for an implementation are mandatory for ADRs that are affecting consensus changes. Other ADRs can choose to include links to test cases if applicable. + +## References + +- {reference link} diff --git a/versioned_docs/version-0.45/integrate/building-modules/README.md b/versioned_docs/version-0.45/integrate/building-modules/README.md new file mode 100644 index 000000000..411c3e8d3 --- /dev/null +++ b/versioned_docs/version-0.45/integrate/building-modules/README.md @@ -0,0 +1,23 @@ + + +# Building Modules + +This repository contains documentation on concepts developers need to know in order to build modules for Cosmos SDK applications. + +1. [Introduction to Cosmos SDK Modules](./intro.md) +2. [`AppModule` Interface and Module Manager](./module-manager.md) +3. [Messages and Queries](./messages-and-queries.md) +4. [`Msg` services - Processing Messages](./msg-services.md) +5. [Query Services - Processing Queries](./query-services.md) +6. [BeginBlocker and EndBlocker](./beginblock-endblock.md) +7. [`Keeper`s](./keeper.md) +8. [Invariants](./invariants.md) +9. [Genesis](./genesis.md) +10. [Module Interfaces](./module-interfaces.md) +11. [Standard Module Structure](./structure.md) +12. [Errors](./errors.md) +13. [In-Place Store Migrations](./upgrade.md) diff --git a/versioned_docs/version-0.45/integrate/building-modules/beginblock-endblock.md b/versioned_docs/version-0.45/integrate/building-modules/beginblock-endblock.md new file mode 100644 index 000000000..2814c0ae9 --- /dev/null +++ b/versioned_docs/version-0.45/integrate/building-modules/beginblock-endblock.md @@ -0,0 +1,39 @@ + + +# BeginBlocker and EndBlocker + +`BeginBlocker` and `EndBlocker` are optional methods module developers can implement in their module. They will be triggered at the beginning and at the end of each block respectively, when the [`BeginBlock`](../core/baseapp.md#beginblock) and [`EndBlock`](../core/baseapp.md#endblock) ABCI messages are received from the underlying consensus engine. {synopsis} + +## Pre-requisite Readings + +- [Module Manager](./module-manager.md) {prereq} + +## BeginBlocker and EndBlocker + +`BeginBlocker` and `EndBlocker` are a way for module developers to add automatic execution of logic to their module. This is a powerful tool that should be used carefully, as complex automatic functions can slow down or even halt the chain. + +When needed, `BeginBlocker` and `EndBlocker` are implemented as part of the [`AppModule` interface](./module-manager.md#appmodule). The `BeginBlock` and `EndBlock` methods of the interface implemented in `module.go` generally defer to `BeginBlocker` and `EndBlocker` methods respectively, which are usually implemented in `abci.go`. + +The actual implementation of `BeginBlocker` and `EndBlocker` in `abci.go` are very similar to that of a [`Msg` service](./msg-services.md): + +- They generally use the [`keeper`](./keeper.md) and [`ctx`](../core/context.md) to retrieve information about the latest state. +- If needed, they use the `keeper` and `ctx` to trigger state-transitions. +- If needed, they can emit [`events`](../core/events.md) via the `ctx`'s `EventManager`. + +A specificity of the `EndBlocker` is that it can return validator updates to the underlying consensus engine in the form of an [`[]abci.ValidatorUpdates`](https://tendermint.com/docs/app-dev/abci-spec.html#validatorupdate). This is the preferred way to implement custom validator changes. + +It is possible for developers to define the order of execution between the `BeginBlocker`/`EndBlocker` functions of each of their application's modules via the module's manager `SetOrderBeginBlocker`/`SetOrderEndBlocker` methods. For more on the module manager, click [here](./module-manager.md#manager). + +See an example implementation of `BeginBlocker` from the `distr` module: + ++++ https://github.com/cosmos/cosmos-sdk/blob/f33749263f4ecc796115ad6e789cb0f7cddf9148/x/distribution/abci.go#L14-L38 + +and an example implementation of `EndBlocker` from the `staking` module: + ++++ https://github.com/cosmos/cosmos-sdk/blob/f33749263f4ecc796115ad6e789cb0f7cddf9148/x/staking/abci.go#L22-L27 + +## Next {hide} + +Learn about [`keeper`s](./keeper.md) {hide} diff --git a/versioned_docs/version-0.45/integrate/building-modules/errors.md b/versioned_docs/version-0.45/integrate/building-modules/errors.md new file mode 100644 index 000000000..d1bc36824 --- /dev/null +++ b/versioned_docs/version-0.45/integrate/building-modules/errors.md @@ -0,0 +1,50 @@ + + +# Errors + +This document outlines the recommended usage and APIs for error handling in Cosmos SDK modules. {synopsis} + +Modules are encouraged to define and register their own errors to provide better +context on failed message or handler execution. Typically, these errors should be +common or general errors which can be further wrapped to provide additional specific +execution context. + +## Registration + +Modules should define and register their custom errors in `x/{module}/errors.go`. Registration +of errors is handled via the `types/errors` package. + +Example: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.38.1/x/distribution/types/errors.go#L1-L21 + +Each custom module error must provide the codespace, which is typically the module name +(e.g. "distribution") and is unique per module, and a uint32 code. Together, the codespace and code +provide a globally unique SDK error. Typically, the code is monotonically increasing but does not +necessarily have to be. The only restrictions on error codes are the following: + +* Must be greater than one, as a code value of one is reserved for internal errors. +* Must be unique within the module. + +Note, the SDK provides a core set of *common* errors. These errors are defined in `types/errors/errors.go`. + +## Wrapping + +The custom module errors can be returned as their concrete type as they already fulfill the `error` +interface. However, module errors can be wrapped to provide further context and meaning to failed +execution. + +Example: + ++++ https://github.com/cosmos/cosmos-sdk/blob/b2d48a9e815fe534a7faeec6ca2adb0874252b81/x/bank/keeper/keeper.go#L85-L122 + +Regardless if an error is wrapped or not, the SDK's `errors` package provides an API to determine if +an error is of a particular kind via `Is`. + +## ABCI + +If a module error is registered, the SDK `errors` package allows ABCI information to be extracted +through the `ABCIInfo` API. The package also provides `ResponseCheckTx` and `ResponseDeliverTx` as +auxiliary APIs to automatically get `CheckTx` and `DeliverTx` responses from an error. diff --git a/versioned_docs/version-0.45/integrate/building-modules/genesis.md b/versioned_docs/version-0.45/integrate/building-modules/genesis.md new file mode 100644 index 000000000..7ad32b4d4 --- /dev/null +++ b/versioned_docs/version-0.45/integrate/building-modules/genesis.md @@ -0,0 +1,60 @@ + + +# Module Genesis + +Modules generally handle a subset of the state and, as such, they need to define the related subset of the genesis file as well as methods to initialize, verify and export it. {synopsis} + +## Pre-requisite Readings + +- [Module Manager](./module-manager.md) {prereq} +- [Keepers](./keeper.md) {prereq} + +## Type Definition + +The subset of the genesis state defined from a given module is generally defined in a `genesis.proto` file ([more info](../core/encoding.md#gogoproto) on how to define protobuf messages). The struct defining the module's subset of the genesis state is usually called `GenesisState` and contains all the module-related values that need to be initialized during the genesis process. + +See an example of `GenesisState` protobuf message definition from the `auth` module: + ++++ https://github.com/cosmos/cosmos-sdk/blob/a9547b54ffac9729fe1393651126ddfc0d236cff/proto/cosmos/auth/v1beta1/genesis.proto + +Next we present the main genesis-related methods that need to be implemented by module developers in order for their module to be used in Cosmos SDK applications. + +### `DefaultGenesis` + +The `DefaultGenesis()` method is a simple method that calls the constructor function for `GenesisState` with the default value for each parameter. See an example from the `auth` module: + ++++ https://github.com/cosmos/cosmos-sdk/blob/64b6bb5270e1a3b688c2d98a8f481ae04bb713ca/x/auth/module.go#L48-L52 + +### `ValidateGenesis` + +The `ValidateGenesis(genesisState GenesisState)` method is called to verify that the provided `genesisState` is correct. It should perform validity checks on each of the parameters listed in `GenesisState`. See an example from the `auth` module: + ++++ https://github.com/cosmos/cosmos-sdk/blob/64b6bb5270e1a3b688c2d98a8f481ae04bb713ca/x/auth/types/genesis.go#L57-L70 + +## Other Genesis Methods + +Other than the methods related directly to `GenesisState`, module developers are expected to implement two other methods as part of the [`AppModuleGenesis` interface](./module-manager.md#appmodulegenesis) (only if the module needs to initialize a subset of state in genesis). These methods are [`InitGenesis`](#initgenesis) and [`ExportGenesis`](#exportgenesis). + +### `InitGenesis` + +The `InitGenesis` method is executed during [`InitChain`](../core/baseapp.md#initchain) when the application is first started. Given a `GenesisState`, it initializes the subset of the state managed by the module by using the module's [`keeper`](./keeper.md) setter function on each parameter within the `GenesisState`. + +The [module manager](./module-manager.md#manager) of the application is responsible for calling the `InitGenesis` method of each of the application's modules in order. This order is set by the application developer via the manager's `SetOrderGenesisMethod`, which is called in the [application's constructor function](../basics/app-anatomy.md#constructor-function). + +See an example of `InitGenesis` from the `auth` module: + ++++ https://github.com/cosmos/cosmos-sdk/blob/64b6bb5270e1a3b688c2d98a8f481ae04bb713ca/x/auth/genesis.go#L13-L28 + +### `ExportGenesis` + +The `ExportGenesis` method is executed whenever an export of the state is made. It takes the latest known version of the subset of the state managed by the module and creates a new `GenesisState` out of it. This is mainly used when the chain needs to be upgraded via a hard fork. + +See an example of `ExportGenesis` from the `auth` module. + ++++ https://github.com/cosmos/cosmos-sdk/blob/64b6bb5270e1a3b688c2d98a8f481ae04bb713ca/x/auth/genesis.go#L31-L42 + +## Next {hide} + +Learn about [modules interfaces](module-interfaces.md) {hide} diff --git a/versioned_docs/version-0.45/integrate/building-modules/intro.md b/versioned_docs/version-0.45/integrate/building-modules/intro.md new file mode 100644 index 000000000..b486176bc --- /dev/null +++ b/versioned_docs/version-0.45/integrate/building-modules/intro.md @@ -0,0 +1,92 @@ + + +# Introduction to SDK Modules + +Modules define most of the logic of 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} + +## Pre-requisite Readings + +- [Anatomy of an SDK application](../basics/app-anatomy.md) {prereq} +- [Lifecycle of an SDK transaction](../basics/tx-lifecycle.md) {prereq} + +## Role of Modules in an SDK Application + +The Cosmos SDK can be thought 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. + +On top of this core, the Cosmos SDK enables developers to build modules that implement the business logic of their application. In other words, SDK modules implement the bulk of the logic of applications, while the core does the wiring and enables modules to be composed together. The end goal is to build a robust ecosystem of open-source SDK modules, making it increasingly easier to build complex blockchain applications. + +SDK modules can be seen as little state-machines within the state-machine. They generally define a subset of the state using one or more `KVStore`s in the [main multistore](../core/store.md), as well as a subset of [message types](./messages-and-queries.md#messages). These messages are routed by one of the main components of SDK core, [`BaseApp`](../core/baseapp.md), to a module Protobuf [`Msg` service](./msg-services.md) that defines them. + +``` + + + | + | Transaction relayed from the full-node's consensus engine + | to the node's application via DeliverTx + | + | + | + +---------------------v--------------------------+ + | APPLICATION | + | | + | Using baseapp's methods: Decode the Tx, | + | extract and route the message(s) | + | | + +---------------------+--------------------------+ + | + | + | + +---------------------------+ + | + | + | + | Message routed to the correct + | module to be processed + | + | ++----------------+ +---------------+ +----------------+ +------v----------+ +| | | | | | | | +| AUTH MODULE | | BANK MODULE | | STAKING MODULE | | GOV MODULE | +| | | | | | | | +| | | | | | | Handles message,| +| | | | | | | Updates state | +| | | | | | | | ++----------------+ +---------------+ +----------------+ +------+----------+ + | + | + | + | + +--------------------------+ + | + | Return result to the underlying consensus engine (e.g. Tendermint) + | (0=Ok, 1=Err) + v +``` + +As a result of this architecture, building an SDK application usually revolves around writing modules to implement the specialized logic of the application, and composing them with existing modules to complete the application. Developers will generally work on modules that implement logic needed for their specific use case that do not exist yet, and will use existing modules for more generic functionalities like staking, accounts or token management. + +## How to Approach Building Modules as a Developer + +While there are no definitive guidelines for writing modules, here are some important design principles developers should keep in mind when building them: + +- **Composability**: SDK applications are almost always composed of multiple modules. This means developers need to carefully consider the integration of their module not only with the core of the Cosmos SDK, but also with other modules. The former is achieved by following standard design patterns outlined [here](#main-components-of-sdk-modules), while the latter is achieved by properly exposing the store(s) of the module via the [`keeper`](./keeper.md). +- **Specialization**: A direct consequence of the **composability** feature is that modules should be **specialized**. Developers should carefully establish the scope of their module and not batch multiple functionalities into the same module. This separation of 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`. + +## Main Components of SDK Modules + +Modules are by convention defined in the `./x/` subfolder (e.g. the `bank` module will be defined in the `./x/bank` folder). They generally share the same core components: + +- A [`keeper`](./keeper.md), used to access the module's store(s) and update the state. +- A [`Msg` service](./messages-and-queries.md#messages), used to process messages when they are routed to the module by [`BaseApp`](../core/baseapp.md#message-routing) and trigger state-transitions. +- A [query service](./query-services.md), used to process user queries when they are routed to the module by [`BaseApp`](../core/baseapp.md#query-routing). +- Interfaces, for end users to query the subset of the state defined by the module and create `message`s of the custom types defined in the module. + +In addition to these components, modules implement the `AppModule` interface in order to be managed by the [`module manager`](./module-manager.md). + +Please refer to the [structure document](./structure.md) to learn about the recommended structure of a module's directory. + +## Next {hide} + +Read more on the [`AppModule` interface and the `module manager`](./module-manager.md) {hide} diff --git a/versioned_docs/version-0.45/integrate/building-modules/invariants.md b/versioned_docs/version-0.45/integrate/building-modules/invariants.md new file mode 100644 index 000000000..0adce4dc1 --- /dev/null +++ b/versioned_docs/version-0.45/integrate/building-modules/invariants.md @@ -0,0 +1,88 @@ + + +# Invariants + +An invariant is a property of the application that should always be true. In the context of the Cosmos SDK, an `Invariant` is a function that checks for a particular invariant. These functions are useful to detect bugs early on and act upon them to limit their potential consequences (e.g. by halting the chain). They are also useful in the development process of the application to detect bugs via simulations. {synopsis} + +## Pre-requisite Readings + +- [Keepers](./keeper.md) {prereq} + +## Implementing `Invariant`s + +An `Invariant` is a function that checks for a particular invariant within a module. Module `Invariant`s must follow the `Invariant` type: + ++++ 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. + +In practice, each module implements `Invariant`s in a `./keeper/invariants.go` file within the module's folder. The standard is to implement one `Invariant` function per logical grouping of invariants with the following model: + +```go +// Example for an Invariant that checks balance-related invariants + +func BalanceInvariants(k Keeper) sdk.Invariant { + return func(ctx sdk.Context) (string, bool) { + // Implement checks for balance-related invariants + } +} +``` + +Additionally, module developers should generally implement an `AllInvariants` function that runs all the `Invariant`s functions of the module: + +```go +// AllInvariants runs all invariants of the module. +// In this example, the module implements two Invariants: BalanceInvariants and DepositsInvariants + +func AllInvariants(k Keeper) sdk.Invariant { + + return func(ctx sdk.Context) (string, bool) { + res, stop := BalanceInvariants(k)(ctx) + if stop { + return res, stop + } + + return DepositsInvariant(k)(ctx) + } +} +``` + +Finally, module developers need to implement the `RegisterInvariants` method as part of the [`AppModule` interface](./module-manager.md#appmodule). Indeed, the `RegisterInvariants` method of the module, implemented in the `module/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): + +```go +// RegisterInvariants registers all staking invariants +func RegisterInvariants(ir sdk.InvariantRegistry, k Keeper) { + ir.RegisterRoute(types.ModuleName, "module-accounts", + BalanceInvariants(k)) + ir.RegisterRoute(types.ModuleName, "nonnegative-power", + DepositsInvariant(k)) +} +``` + +For more, see an example of [`Invariant`s implementation from the `staking` module](https://github.com/cosmos/cosmos-sdk/blob/7d7821b9af132b0f6131640195326aa02b6751db/x/staking/keeper/invariants.go). + +## Invariant Registry + +The `InvariantRegistry` is a registry where the `Invariant`s of all the modules of an application are registered. There is only one `InvariantRegistry` per **application**, meaning module developers need not implement their own `InvariantRegistry` when building a module. **All module developers need to do is to register their modules' invariants in the `InvariantRegistry`, as explained in the section above**. The rest of this section gives more information on the `InvariantRegistry` itself, and does not contain anything directly relevant to module developers. + +At its core, the `InvariantRegistry` is defined in the SDK as an interface: + ++++ https://github.com/cosmos/cosmos-sdk/blob/7d7821b9af132b0f6131640195326aa02b6751db/types/invariant.go#L14-L17 + +Typically, this interface is implemented in the `keeper` of a specific module. The most used implementation of an `InvariantRegistry` can be found in the `crisis` module: + ++++ https://github.com/cosmos/cosmos-sdk/blob/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). + +`Invariant`s can be checked manually via [`message`s](./messages-and-queries.md), but most often they are checked automatically at the end of each block. Here is an example from the `crisis` module: + ++++ https://github.com/cosmos/cosmos-sdk/blob/7d7821b9af132b0f6131640195326aa02b6751db/x/crisis/abci.go#L7-L14 + +In both cases, if one of the `Invariant`s returns false, the `InvariantRegistry` can trigger special logic (e.g. have the application panic and print the `Invariant`s message in the log). + +## Next {hide} + +Learn about [genesis functionalities](./genesis.md) {hide} diff --git a/versioned_docs/version-0.45/integrate/building-modules/keeper.md b/versioned_docs/version-0.45/integrate/building-modules/keeper.md new file mode 100644 index 000000000..0f82ccd2e --- /dev/null +++ b/versioned_docs/version-0.45/integrate/building-modules/keeper.md @@ -0,0 +1,85 @@ + + +# Keepers + +`Keeper`s refer to a Cosmos SDK abstraction whose role is to manage access to the subset of the state defined by various modules. `Keeper`s are module-specific, i.e. the subset of state defined by a module can only be accessed by a `keeper` defined in said module. If a module needs to access the subset of state defined by another module, a reference to the second module's internal `keeper` needs to be passed to the first one. This is done in `app.go` during the instantiation of module keepers. {synopsis} + +## Pre-requisite Readings + +- [Introduction to SDK Modules](./intro.md) {prereq} + +## Motivation + +The Cosmos SDK is a framework that makes it easy for developers to build complex decentralised applications from scratch, mainly by composing modules together. As the ecosystem of open source modules for the Cosmos SDK expands, it will become increasingly likely that some of these modules contain vulnerabilities, as a result of the negligence or malice of their developer. + +The Cosmos SDK adopts an [object-capabilities-based approach](../core/ocap.md) to help developers better protect their application from unwanted inter-module interactions, and `keeper`s are at the core of this approach. A `keeper` can be thought of quite literally as the gatekeeper of a module's store(s). Each store (typically an [`IAVL` Store](../core/store.md#iavl-store)) defined within a module comes with a `storeKey`, which grants unlimited access to it. The module's `keeper` holds this `storeKey` (which should otherwise remain unexposed), and defines [methods](#implementing-methods) for reading and writing to the store(s). + +The core idea behind the object-capabilities approach is to only reveal what is necessary to get the work done. In practice, this means that instead of handling permissions of modules through access-control lists, module `keeper`s are passed a reference to the specific instance of the other modules' `keeper`s that they need to access (this is done in the [application's constructor function](../basics/app-anatomy.md#constructor-function)). As a consequence, a module can only interact with the subset of state defined in another module via the methods exposed by the instance of the other module's `keeper`. This is a great way for developers to control the interactions that their own module can have with modules developed by external developers. + +## Type Definition + +`keeper`s are generally implemented in a `/keeper/keeper.go` file located in the module's folder. By convention, the type `keeper` of a module is simply named `Keeper` and usually follows the following structure: + +```go +type Keeper struct { + // External keepers, if any + + // Store key(s) + + // codec +} +``` + +For example, here is the type definition of the `keeper` from the `staking` module: + ++++ https://github.com/cosmos/cosmos-sdk/blob/3bafd8255a502e5a9cee07391cf8261538245dfd/x/staking/keeper/keeper.go#L23-L33 + +Let us go through the different parameters: + +- An expected `keeper` is a `keeper` external to a module that is required by the internal `keeper` of said module. External `keeper`s are listed in the internal `keeper`'s type definition as interfaces. These interfaces are themselves defined in 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. + +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. + +## Implementing Methods + +`Keeper`s primarily expose getter and setter methods for the store(s) managed by their module. These methods should remain as simple as possible and strictly be limited to getting or setting the requested value, as validity checks should have already been performed via the `ValidateBasic()` method of the [`message`](./messages-and-queries.md#messages) and the [`Msg` server](./msg-services.md) when `keeper`s' methods are called. + +Typically, a *getter* method will have the following signature + +```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. + +Similarly, a *setter* method will have the following signature + +```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. + +For more, see an example of `keeper`'s [methods implementation from the `staking` module](https://github.com/cosmos/cosmos-sdk/blob/3bafd8255a502e5a9cee07391cf8261538245dfd/x/staking/keeper/keeper.go). + +The [module `KVStore`](../core/store.md#kvstore-and-commitkvstore-interfaces) also provides an `Iterator()` method which returns an `Iterator` object to iterate over a domain of keys. + +This is an example from the `auth` module to iterate accounts: + ++++ https://github.com/cosmos/cosmos-sdk/blob/bf8809ef9840b4f5369887a38d8345e2380a567f/x/auth/keeper/account.go#L70-L83 + +## Next {hide} + +Learn about [invariants](./invariants.md) {hide} diff --git a/versioned_docs/version-0.45/integrate/building-modules/messages-and-queries.md b/versioned_docs/version-0.45/integrate/building-modules/messages-and-queries.md new file mode 100644 index 000000000..6b5db1a72 --- /dev/null +++ b/versioned_docs/version-0.45/integrate/building-modules/messages-and-queries.md @@ -0,0 +1,115 @@ + + +# Messages and Queries + +`Msg`s and `Queries` are the two primary objects handled by modules. Most of the core components defined in a module, like `Msg` services, `keeper`s and `Query` services, exist to process `message`s and `queries`. {synopsis} + +## Pre-requisite Readings + +- [Introduction to SDK Modules](./intro.md) {prereq} + +## Messages + +`Msg`s are objects whose end-goal is to trigger state-transitions. They are wrapped in [transactions](../core/transactions.md), which may contain one or more of them. + +When a transaction is relayed from the underlying consensus engine to the SDK application, it is first decoded by [`BaseApp`](../core/baseapp.md). Then, each message contained in the transaction is extracted and routed to the appropriate module via `BaseApp`'s `MsgServiceRouter` so that it can be processed by the module's [`Msg` service](./msg-services.md). For a more detailed explanation of the lifecycle of a transaction, click [here](../basics/tx-lifecycle.md). + +### `Msg` Services + +Starting from v0.40, defining Protobuf `Msg` services is the recommended way to handle messages. A 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. + +See an example of a `Msg` service definition from `x/bank` module: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc1/proto/cosmos/bank/v1beta1/tx.proto#L10-L17 + +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: + +``` + 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. + +Cosmos SDK uses Protobuf definitions to generate client and server code: + +* `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. + +A `RegisterMsgServer` method is also generated and should be used to register the module's `MsgServer` implementation in `RegisterServices` method from the [`AppModule` interface](./module-manager.md#appmodule). + +In order for clients (CLI and grpc-gateway) to have these URLs registered, the SDK provides the function `RegisterMsgServiceDesc(registry codectypes.InterfaceRegistry, sd *grpc.ServiceDesc)` that should be called inside module's [`RegisterInterfaces`](module-manager.md#appmodulebasic) method, using the proto-generated `&_Msg_serviceDesc` as `*grpc.ServiceDesc` argument. + +### Legacy Amino `LegacyMsg`s + +The following way of defining messages is deprecated and using [`Msg` services](#msg-services) is preferred. + +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. + +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: + ++++ https://github.com/cosmos/cosmos-sdk/blob/4a1b2fba43b1052ca162b3a1e0b6db6db9c26656/types/tx_msg.go#L10-L33 + +It extends `proto.Message` and contains the following methods: + +- `Route() string`: Name of the route for this message. Typically all `message`s in a module have the same route, which is most often the module's name. +- `Type() string`: Type of the message, used primarly in [events](../core/events.md). This should return a message-specific `string`, typically the denomination of the message itself. +- [`ValidateBasic() error`](../basics/tx-lifecycle.md#ValidateBasic). +- `GetSignBytes() []byte`: Return the canonical byte representation of the message. Used to generate a signature. +- `GetSigners() []AccAddress`: Return the list of signers. The SDK will make sure that each `message` contained in a transaction is signed by all the signers listed in the list returned by this method. + +See an example implementation of a `message` from the `gov` module: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc1/x/gov/types/msgs.go#L77-L125 + +## Queries + +A `query` is a request for information made by end-users of applications through an interface and processed by a full-node. A `query` is received by a full-node through its consensus engine and relayed to the application via the ABCI. It is then routed to the appropriate module via `BaseApp`'s `queryrouter` so that it can be processed by the module's query service (./query-services.md). For a deeper look at the lifecycle of a `query`, click [here](../basics/query-lifecycle.md). + +### gRPC Queries + +Starting from v0.40, the prefered way to define queries is by using [Protobuf services](https://developers.google.com/protocol-buffers/docs/proto#services). A `Query` service should be created per module in `query.proto`. This service lists endpoints starting with `rpc`. + +Here's an example of such a `Query` service definition: + ++++ https://github.com/cosmos/cosmos-sdk/blob/d55c1a26657a0af937fa2273b38dcfa1bb3cff9f/proto/cosmos/auth/v1beta1/query.proto#L12-L23 + +As `proto.Message`s, generated `Response` types implement by default `String()` method of [`fmt.Stringer`](https://golang.org/pkg/fmt/#Stringer). + +A `RegisterQueryServer` method is also generated and should be used to register the module's query server in the `RegisterServices` method from the [`AppModule` interface](./module-manager.md#appmodule). + +### Legacy Queries + +Before the introduction of Protobuf and gRPC in the SDK, there was usually no specific `query` object defined by module developers, contrary to `message`s. Instead, the SDK took the simpler approach of using a simple `path` to define each `query`. The `path` contains the `query` type and all the arguments needed in order to process it. For most module queries, the `path` should look like the following: + +``` +queryCategory/queryRoute/queryType/arg1/arg2/... +``` + +where: + +- `queryCategory` is the category of the `query`, typically `custom` for module queries. It is used to differentiate between different kinds of queries within `BaseApp`'s [`Query` method](../core/baseapp.md#query). +- `queryRoute` is used by `BaseApp`'s [`queryRouter`](../core/baseapp.md#query-routing) to map the `query` to its module. Usually, `queryRoute` should be the name of the module. +- `queryType` is used by the module's [`querier`](./query-services.md#legacy-queriers) to map the `query` to the appropriate `querier function` within the module. +- `args` are the actual arguments needed to process the `query`. They are filled out by the end-user. Note that for bigger queries, you might prefer passing arguments in the `Data` field of the request `req` instead of the `path`. + +The `path` for each `query` must be defined by the module developer in the module's [command-line interface file](./module-interfaces.md#query-commands).Overall, there are 3 mains components module developers need to implement in order to make the subset of the state defined by their module queryable: + +- A [`querier`](./query-services.md#legacy-queriers), to process the `query` once it has been [routed to the module](../core/baseapp.md#query-routing). +- [Query commands](./module-interfaces.md#query-commands) in the module's CLI file, where the `path` for each `query` is specified. +- `query` return types. Typically defined in a file `types/querier.go`, they specify the result type of each of the module's `queries`. These custom types must implement the `String()` method of [`fmt.Stringer`](https://golang.org/pkg/fmt/#Stringer). + +### Store Queries + +Store queries query directly for store keys. They use `clientCtx.QueryABCI(req abci.RequestQuery)` to return the full `abci.ResponseQuery` with inclusion Merkle proofs. + +See following examples: + ++++ https://github.com/cosmos/cosmos-sdk/blob/080fcf1df25ccdf97f3029b6b6f83caaf5a235e4/x/ibc/core/client/query.go#L36-L46 + ++++ https://github.com/cosmos/cosmos-sdk/blob/080fcf1df25ccdf97f3029b6b6f83caaf5a235e4/baseapp/abci.go#L722-L749 + +## Next {hide} + +Learn about [`Msg` services](./msg-services.md) {hide} diff --git a/versioned_docs/version-0.45/integrate/building-modules/module-interfaces.md b/versioned_docs/version-0.45/integrate/building-modules/module-interfaces.md new file mode 100644 index 000000000..161d9f455 --- /dev/null +++ b/versioned_docs/version-0.45/integrate/building-modules/module-interfaces.md @@ -0,0 +1,139 @@ + + +# Module Interfaces + +This document details how to build CLI and REST interfaces for a module. Examples from various SDK modules are included. {synopsis} + +## Prerequisite Readings + +- [Building Modules Intro](./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. + +### 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. + + 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. + +Here is an example from the `x/bank` module: + ++++ 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. + +In general, the getter function does the following: + +- **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()`](../basics/tx-lifecycle.md#ValidateBasic) and other validation methods before broadcasting the message. + - 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: + ++++ 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: + ++++ 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: + ++++ 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. + +In general, the getter function does the following: + +- **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. + +Each module must implement `GetQueryCmd()`, which aggregates all of the query commands of the module. Here is an example from the `x/auth` module: + ++++ 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: + ++++ 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 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. + +Here is an example that adds the `--from` flag to a command: + +```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. + +Here is an example that marks the `--from` flag as _required_: + +```go +cmd.MarkFlagRequired(FlagFrom) +``` + +For more detailed information on creating flags, visit the [Cobra Documentation](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 SDK's `./client/flags` package. + ++++ 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). + +Similarly, there is a `AddQueryFlagsToCmd(cmd *cobra.Command)` to add common flags to a module query 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. + +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. + +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. + +Here's an example from the `x/auth` module: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.43.0-beta1/x/auth/module.go#L68-L73 + +## gRPC-gateway 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. + +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: + ++++ 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). + +The SDK provides a command for generating [Swagger](https://swagger.io/) documentation (`protoc-gen-swagger`). Setting `swagger` in [`app.toml`](../run-node/run-node.md#configuring-the-node-using-apptoml) defines if swagger documentation should be automatically registered. + +## Next {hide} + +Read about the recommended [module structure](./structure.md) {hide} diff --git a/versioned_docs/version-0.45/integrate/building-modules/module-manager.md b/versioned_docs/version-0.45/integrate/building-modules/module-manager.md new file mode 100644 index 000000000..334d252e6 --- /dev/null +++ b/versioned_docs/version-0.45/integrate/building-modules/module-manager.md @@ -0,0 +1,150 @@ + + +# Module Manager + +Cosmos SDK modules need to implement the [`AppModule` interfaces](#application-module-interfaces), in order to be managed by the application's [module manager](#module-manager). The module manager plays an important role in [`message` and `query` routing](../core/baseapp.md#routing), and allows application developers to set the order of execution of a variety of functions like [`BeginBlocker` and `EndBlocker`](../basics/app-anatomy.md#begingblocker-and-endblocker). {synopsis} + +## Pre-requisite Readings + +- [Introduction to SDK Modules](./intro.md) {prereq} + +## Application Module Interfaces + +Application module interfaces exist to facilitate the composition of modules together to form a functional SDK application. There are 3 main application module interfaces: + +- [`AppModuleBasic`](#appmodulebasic) for independent module functionalities. +- [`AppModule`](#appmodule) for inter-dependent module functionalities (except genesis-related functionalities). +- [`AppModuleGenesis`](#appmodulegenesis) for inter-dependent genesis-related module functionalities. + +The `AppModuleBasic` interface exists to define independent methods of the module, i.e. those that do not depend on other modules in the application. This allows for the construction of the basic application structure early in the application definition, generally in the `init()` function of the [main application file](../basics/app-anatomy.md#core-application-file). + +The `AppModule` interface exists to define inter-dependent module methods. Many modules need to interract with other modules, typically through [`keeper`s](./keeper.md), which means there is a need for an interface where modules list their `keeper`s and other methods that require a reference to another module's object. `AppModule` interface also enables the module manager to set the order of execution between module's methods like `BeginBlock` and `EndBlock`, which is important in cases where the order of execution between modules matters in the context of the application. + +Lastly the interface for genesis functionality `AppModuleGenesis` is separated out from full module functionality `AppModule` so that modules which +are only used for genesis can take advantage of the `Module` patterns without having to define many placeholder functions. + +### `AppModuleBasic` + +The `AppModuleBasic` interface defines the independent methods modules need to implement. + ++++ https://github.com/cosmos/cosmos-sdk/blob/325be6ff215db457c6fc7668109640cd7fdac461/types/module/module.go#L49-L63 + +Let us go through the methods: + +- `Name()`: Returns the name of the module as a `string`. +- `RegisterLegacyAminoCodec(*codec.LegacyAmino)`: Registers the `amino` codec for the module, which is used to marshal and unmarshal structs to/from `[]byte` in order to persist them in the module's `KVStore`. +- `RegisterInterfaces(codectypes.InterfaceRegistry)`: Registers a module's interface types and their concrete implementations as `proto.Message`. +- `DefaultGenesis(codec.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. + +All the `AppModuleBasic` of an application are managed by the [`BasicManager`](#basicmanager). + +### `AppModuleGenesis` + +The `AppModuleGenesis` interface is a simple embedding of the `AppModuleBasic` interface with two added methods. + ++++ https://github.com/cosmos/cosmos-sdk/blob/325be6ff215db457c6fc7668109640cd7fdac461/types/module/module.go#L152-L158 + +Let us go through the two added methods: + +- `InitGenesis(sdk.Context, codec.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. + +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` + +The `AppModule` interface defines the inter-dependent methods that modules need to implement. + ++++ https://github.com/cosmos/cosmos-sdk/blob/b4cce159bcc6a32ac78245c6866dd87c73f3720d/types/module/module.go#L160-L182 + +`AppModule`s are managed by the [module manager](#manager). This interface embeds the `AppModuleGenesis` interface so that the manager can access all the independent and genesis inter-dependent methods of the module. This means that a concrete type implementing the `AppModule` interface must either implement all the methods of `AppModuleGenesis` (and by extension `AppModuleBasic`), or include a concrete type that does as parameter. + +Let us go through the methods of `AppModule`: + +- `RegisterInvariants(sdk.InvariantRegistry)`: Registers the [`invariants`](./invariants.md) of the module. If 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. + +### Implementing the Application Module Interfaces + +Typically, the various application module interfaces are implemented in a file called `module.go`, located in the module's folder (e.g. `./x/module/module.go`). + +Almost every module needs to implement the `AppModuleBasic` and `AppModule` interfaces. If the module is only used for genesis, it will implement `AppModuleGenesis` instead of `AppModule`. The concrete type that implements the interface can add parameters that are required for the implementation of the various methods of the interface. For example, the `Route()` function often calls a `NewMsgServerImpl(k keeper)` function defined in `keeper/msg_server.go` and therefore needs to pass the module's [`keeper`](./keeper.md) as a parameter. + +```go +// example +type AppModule struct { + AppModuleBasic + keeper Keeper +} +``` + +In the example above, you can see that the `AppModule` concrete type references an `AppModuleBasic`, and not an `AppModuleGenesis`. That is because `AppModuleGenesis` only needs to be implemented in modules that focus on genesis-related functionalities. In most modules, the concrete `AppModule` type will have a reference to an `AppModuleBasic` and implement the two added methods of `AppModuleGenesis` directly in the `AppModule` type. + +If no parameter is required (which is often the case for `AppModuleBasic`), just declare an empty concrete type like so: + +```go +type AppModuleBasic struct{} +``` + +## Module Managers + +Module managers are used to manage collections of `AppModuleBasic` and `AppModule`. + +### `BasicManager` + +The `BasicManager` is a structure that lists all the `AppModuleBasic` of an application: + ++++ https://github.com/cosmos/cosmos-sdk/blob/325be6ff215db457c6fc7668109640cd7fdac461/types/module/module.go#L65-L66 + +It implements the following methods: + +- `NewBasicManager(modules ...AppModuleBasic)`: Constructor function. It takes a list of the application's `AppModuleBasic` and builds a new `BasicManager`. This function is generally called in the `init()` function of [`app.go`](../basics/app-anatomy.md#core-application-file) to quickly initialize the independent elements of the application's modules (click [here](https://github.com/cosmos/gaia/blob/master/app/app.go#L59-L74) to see an example). +- `RegisterLegacyAminoCodec(cdc *codec.LegacyAmino)`: Registers the [`codec.LegacyAmino`s](../core/encoding.md#amino) of each of the application's `AppModuleBasic`. This function is usually called early on in the [application's construction](../basics/app-anatomy.md#constructor). +- `RegisterInterfaces(registry codectypes.InterfaceRegistry)`: Registers interface types and implementations of each of the application's `AppModuleBasic`. +- `DefaultGenesis(cdc codec.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). + +### `Manager` + +The `Manager` is a structure that holds all the `AppModule` of an application, and defines the order of execution between several key components of these modules: + ++++ https://github.com/cosmos/cosmos-sdk/blob/325be6ff215db457c6fc7668109640cd7fdac461/types/module/module.go#L223-L231 + +The module manager is used throughout the application whenever an action on a collection of modules is required. It implements the following methods: + +- `NewManager(modules ...AppModule)`: Constructor function. It takes a list of the application's `AppModule`s and builds a new `Manager`. It is generally called from the application's main [constructor function](../basics/app-anatomy.md#constructor-function). +- `SetOrderInitGenesis(moduleNames ...string)`: Sets the order in which the [`InitGenesis`](./genesis.md#initgenesis) function of each module will be called when the application is first started. This function is generally called from the application's main [constructor function](../basics/app-anatomy.md#constructor-function). +- `SetOrderExportGenesis(moduleNames ...string)`: Sets the order in which the [`ExportGenesis`](./genesis.md#exportgenesis) function of each module will be called in case of an export. This function is generally called from the application's main [constructor function](../basics/app-anatomy.md#constructor-function). +- `SetOrderBeginBlockers(moduleNames ...string)`: Sets the order in which the `BeginBlock()` function of each module will be called at the beginning of each block. This function is generally called from the application's main [constructor function](../basics/app-anatomy.md#constructor-function). +- `SetOrderEndBlockers(moduleNames ...string)`: Sets the order in which the `EndBlock()` function of each module will be called at the end of each block. This function is generally called from the application's main [constructor function](../basics/app-anatomy.md#constructor-function). +- `RegisterInvariants(ir sdk.InvariantRegistry)`: Registers the [invariants](./invariants.md) of each module. +- `RegisterRoutes(router sdk.Router, queryRouter sdk.QueryRouter, legacyQuerierCdc *codec.LegacyAmino)`: Registers legacy [`Msg`](./messages-and-queries.md#messages) and [`querier`](./query-services.md#legacy-queriers) routes. +- `RegisterServices(cfg Configurator)`: Registers all module services. +- `InitGenesis(ctx sdk.Context, cdc codec.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). + +Here's an example of a concrete integration within an application: + ++++ https://github.com/cosmos/cosmos-sdk/blob/2323f1ac0e9a69a0da6b43693061036134193464/simapp/app.go#L315-L362 + +## Next {hide} + +Learn more about [`message`s and `queries`](./messages-and-queries.md) {hide} diff --git a/versioned_docs/version-0.45/integrate/building-modules/msg-services.md b/versioned_docs/version-0.45/integrate/building-modules/msg-services.md new file mode 100644 index 000000000..de7107b92 --- /dev/null +++ b/versioned_docs/version-0.45/integrate/building-modules/msg-services.md @@ -0,0 +1,134 @@ + + +# `Msg` Services + +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} + +## Pre-requisite Readings + +- [Module Manager](./module-manager.md) {prereq} +- [Messages and Queries](./messages-and-queries.md) {prereq} + +## Implementation of a module `Msg` service + +Each module should define a Protobuf `Msg` service, which will be responsible for processing requests (implementing `sdk.Msg`) and returning responses. + +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. + +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: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/x/bank/types/tx.pb.go#L285-L291 + +When possible, the existing module's [`Keeper`](keeper.md) should implement `MsgServer`, otherwise a `msgServer` struct that embeds the `Keeper` can be created, typically in `./keeper/msg_server.go`: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc1/x/bank/keeper/msg_server.go#L14-L16 + +`msgServer` methods can retrieve the `sdk.Context` from the `context.Context` parameter method using the `sdk.UnwrapSDKContext`: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc1/x/bank/keeper/msg_server.go#L27-L28 + +`sdk.Msg` processing usually follows these 3 steps: + +### Validation + +Before a `msgServer` method is executed, the message's [`ValidateBasic()`](../basics/tx-lifecycle.md#ValidateBasic) method has already been called. Since `msg.ValidateBasic()` performs only the most basic checks, this stage must perform all other validation (both *stateful* and *stateless*) to make sure the `message` is valid. Checks performed in the `msgServer` method can be more expensive and the signer is charged gas for these operations. +For example, a `msgServer` method for a `transfer` message might check that the sending account has enough funds to actually perform the transfer. + +It is recommended to implement all validation checks in a separate function that passes state values as arguments. This implementation simplifies testing. As expected, expensive validation functions charge additional gas. Example: + +```go +ValidateMsgA(msg MsgA, now Time, gm GasMeter) error { + if now.Before(msg.Expire) { + return sdkerrrors.ErrInvalidRequest.Wrap("msg expired") + } + gm.ConsumeGas(1000, "signature verification") + return signatureVerificaton(msg.Prover, msg.Data) +} +``` + +### State Transition + +After the validation is successful, the `msgServer` method uses the [`keeper`](./keeper.md) functions to access the state and perform a state transition. + +### Events + +Before returning, `msgServer` methods generally emit one or more [events](../core/events.md) by using the `EventManager` held in the `ctx`. Use the new `EmitTypedEvent` function that uses protobuf-based event types: + +``` +ctx.EventManager().EmitTypedEvent( + &group.EventABC{Key1: Value1, Key2, Value2}) +``` + +or the older `EmitEvent` function: + +```go +ctx.EventManager().EmitEvent( + sdk.NewEvent( + eventType, // e.g. sdk.EventTypeMessage for a message, types.CustomEventType for a custom event defined in the module + sdk.NewAttribute(key1, value1), + sdk.NewAttribute(key2, value2), + ), +) +``` + +These events are relayed back to the underlying consensus engine and can be used by service providers to implement services around the application. Click [here](../core/events.md) to learn more about events. + +The invoked `msgServer` method returns a `proto.Message` response and an `error`. These return values are then wrapped into an `*sdk.Result` or an `error` using `sdk.WrapServiceResult(ctx sdk.Context, res proto.Message, err error)`: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc2/baseapp/msg_service_router.go#L104-L104 + +This method takes care of marshaling the `res` parameter to protobuf and attaching any events on the `ctx.EventManager()` to the `sdk.Result`. + ++++ https://github.com/cosmos/cosmos-sdk/blob/d55c1a26657a0af937fa2273b38dcfa1bb3cff9f/proto/cosmos/base/abci/v1beta1/abci.proto#L81-L95 + +This diagram shows a typical structure of a Protobuf `Msg` service, and how the message propagates through the module. + +![Transaction flow](transaction_flow.svg) + +## Amino `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). + +Here is the typical structure of a `handler` function: + ++++ 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). + +Module `handler`s are typically implemented in a `./handler.go` file inside the module's folder. The [module manager](./module-manager.md) is used to add the module's `handler`s to the +[application's `router`](../core/baseapp.md#message-routing) via the `Route()` method. Typically, +the manager's `Route()` method simply constructs a Route that calls a `NewHandler()` method defined in `handler.go`. + ++++ https://github.com/cosmos/cosmos-sdk/blob/228728cce2af8d494c8b4e996d011492139b04ab/x/gov/module.go#L143-L146 + +### Implementation + +`NewHandler` function dispatches a `LegacyMsg` to appropriate handler function, usually by using a switch statement: + ++++ https://github.com/cosmos/cosmos-sdk/blob/d55c1a26657a0af937fa2273b38dcfa1bb3cff9f/x/bank/handler.go#L13-L29 + +First, `NewHandler` function sets a new `EventManager` to the context to isolate events per `msg`. +Then, a simple switch calls the appropriate `handler` based on the `LegacyMsg` type. + +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`. + +## Telemetry + +New [telemetry metrics](../core/telemetry.md) can be created from `msgServer` methods when handling messages. + +This is an example from the `x/auth/vesting` module: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc1/x/auth/vesting/msg_server.go#L73-L85 + +## Next {hide} + +Learn about [query services](./query-services.md) {hide} diff --git a/versioned_docs/version-0.45/integrate/building-modules/query-services.md b/versioned_docs/version-0.45/integrate/building-modules/query-services.md new file mode 100644 index 000000000..4113e099e --- /dev/null +++ b/versioned_docs/version-0.45/integrate/building-modules/query-services.md @@ -0,0 +1,77 @@ + + +# 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} + +## Pre-requisite Readings + +- [Module Manager](./module-manager.md) {prereq} +- [Messages and Queries](./messages-and-queries.md) {prereq} + +## `Querier` type + +The `querier` type defined in the Cosmos SDK will be deprecated in favor of [gRPC Services](#grpc-service). It specifies the typical structure of a `querier` function: + ++++ https://github.com/cosmos/cosmos-sdk/blob/9a183ffbcc0163c8deb71c7fd5f8089a83e58f05/types/queryable.go#L9 + +Let us break it down: + +- The `path` is an array of `string`s that contains the type of the query, and that can also contain `query` arguments. See [`queries`](./messages-and-queries.md#queries) for more information. +- The `req` itself is primarily used to retrieve arguments if they are too large to fit in the `path`. This is done using the `Data` field of `req`. +- The [`Context`](../core/context.md) contains all the necessary information needed to process the `query`, as well as a branch of the latest state. It is primarily used by the [`keeper`](./keeper.md) to access the state. +- The result `res` returned to `BaseApp`, marshalled using the application's [`codec`](../core/encoding.md). + +## Implementation of a module query service + +### gRPC Service + +When defining a Protobuf `Query` service, a `QueryServer` interface is generated for each module with all the service methods: + +```go +type QueryServer interface { + QueryBalance(context.Context, *QueryBalanceParams) (*types.Coin, error) + QueryAllBalances(context.Context, *QueryAllBalancesParams) (*QueryAllBalancesResponse, error) +} +``` + +These custom queries methods should be implemented by a module's keeper, typically in `./keeper/grpc_query.go`. The first parameter of these methods is a generic `context.Context`, whereas querier methods generally need an instance of `sdk.Context` to read +from the store. Therefore, the SDK provides a function `sdk.UnwrapSDKContext` to retrieve the `sdk.Context` from the provided +`context.Context`. + +Here's an example implementation for the bank module: + ++++ https://github.com/cosmos/cosmos-sdk/blob/d55c1a26657a0af937fa2273b38dcfa1bb3cff9f/x/bank/keeper/grpc_query.go + +### Legacy Queriers + +Module legacy `querier`s are typically implemented in a `./keeper/querier.go` file inside the module's folder. The [module manager](./module-manager.md) is used to add the module's `querier`s to the [application's `queryRouter`](../core/baseapp.md#query-routing) via the `NewQuerier()` method. Typically, the manager's `NewQuerier()` method simply calls a `NewQuerier()` method defined in `keeper/querier.go`, which looks like the following: + +```go +func NewQuerier(keeper Keeper) sdk.Querier { + return func(ctx sdk.Context, path []string, req abci.RequestQuery) ([]byte, error) { + switch path[0] { + case QueryType1: + return queryType1(ctx, path[1:], req, keeper) + + case QueryType2: + return queryType2(ctx, path[1:], req, keeper) + + default: + return nil, sdkerrors.Wrapf(sdkerrors.ErrUnknownRequest, "unknown %s query endpoint: %s", types.ModuleName, path[0]) + } + } +} +``` + +This simple switch returns a `querier` function specific to the type of the received `query`. At this point of the [query lifecycle](../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. + +The `querier` functions themselves are pretty straighforward. They generally fetch a value or values from the state using the [`keeper`](./keeper.md). Then, they marshall the value(s) using the [`codec`](../core/encoding.md) and return the `[]byte` obtained as result. + +For a deeper look at `querier`s, see this [example implementation of a `querier` function](https://github.com/cosmos/cosmos-sdk/blob/7f59723d889b69ca19966167f0b3a7fec7a39e53/x/gov/keeper/querier.go) from the bank module. + +## Next {hide} + +Learn about [`BeginBlocker` and `EndBlocker`](./beginblock-endblock.md) {hide} diff --git a/versioned_docs/version-0.45/integrate/building-modules/simulator.md b/versioned_docs/version-0.45/integrate/building-modules/simulator.md new file mode 100644 index 000000000..e6f07fbb6 --- /dev/null +++ b/versioned_docs/version-0.45/integrate/building-modules/simulator.md @@ -0,0 +1,123 @@ +# Module Simulation + +## Prerequisites + +* [Cosmos Blockchain Simulator](./../using-the-sdk/simulation.md) + +## Synopsis + +This document details how to define each module simulation functions to be +integrated with the application `SimulationManager`. + +* [Simulation package](#simulation-package) + * [Store decoders](#store-decoders) + * [Randomized genesis](#randomized-genesis) + * [Randomized parameters](#randomized-parameters) + * [Random weighted operations](#random-weighted-operations) + * [Random proposal contents](#random-proposal-contents) +* [Registering the module simulation functions](#registering-simulation-functions) +* [App simulator manager](#app-simulator-manager) +* [Simulation tests](#simulation-tests) + +## Simulation package + +Every module that implements the SDK simulator needs to have a `x//simulation` +package which contains the primary functions required by the fuzz tests: store +decoders, randomized genesis state and parameters, weighted operations and proposal +contents. + +### Store decoders + +Registering the store decoders is required for the `AppImportExport`. This allows +for the key-value pairs from the stores to be decoded (_i.e_ unmarshalled) +to their corresponding types. In particular, it matches the key to a concrete type +and then unmarshals the value from the `KVPair` to the type provided. + +You can use the example [here](https://github.com/cosmos/cosmos-sdk/blob/v0.42.0/x/distribution/simulation/decoder.go) from the distribution module to implement your store decoders. + +### Randomized genesis + +The simulator tests different scenarios and values for genesis parameters +in order to fully test the edge cases of specific modules. The `simulator` package from each module must expose a `RandomizedGenState` function to generate the initial random `GenesisState` from a given seed. + +Once the module genesis parameter are generated randomly (or with the key and +values defined in a `params` file), they are marshaled to JSON format and added +to the app genesis JSON to use it on the simulations. + +You can check an example on how to create the randomized genesis [here](https://github.com/cosmos/cosmos-sdk/blob/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. + +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) + +### Random weighted operations + +Operations are one of the crucial parts of the SDK simulation. They are the transactions +(`Msg`) that are simulated with random field values. The sender of the operation +is also assigned randomly. + +Operations on the simulation are simulated using the full [transaction cycle](../core/transactions.md) of a +`ABCI` application that exposes the `BaseApp`. + +Shown below is how weights are set: + ++++ https://github.com/cosmos/cosmos-sdk/blob/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. + +Here is how one can override the above package `simappparams`. + ++++ https://github.com/cosmos/gaia/blob/master/sims.mk#L9-L22 + +For the last test a tool called runsim is used, this is used to parallelize go test instances, provide info to Github and slack integrations to provide information to your team on how the simulations are running. + +### Random proposal contents + +Randomized governance proposals are also supported on the SDK simulator. Each +module must define the governance proposal `Content`s that they expose and register +them to be used on the parameters. + +## Registering simulation functions + +Now that all the required functions are defined, we need to integrate them into the module pattern within the `module.go`: + ++++ https://github.com/cosmos/cosmos-sdk/blob/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. + +```go +type CustomApp struct { + ... + sm *module.SimulationManager +} +``` + +Then at the instantiation of the application, we create the `SimulationManager` +instance in the same way we create the `ModuleManager` but this time we only pass +the modules that implement the simulation functions from the `AppModuleSimulation` +interface described above. + +```go +func NewCustomApp(...) { + // create the simulation manager and define the order of the modules for deterministic simulations + app.sm = module.NewSimulationManager( + auth.NewAppModule(app.accountKeeper), + bank.NewAppModule(app.bankKeeper, app.accountKeeper), + supply.NewAppModule(app.supplyKeeper, app.accountKeeper), + ov.NewAppModule(app.govKeeper, app.accountKeeper, app.supplyKeeper), + mint.NewAppModule(app.mintKeeper), + distr.NewAppModule(app.distrKeeper, app.accountKeeper, app.supplyKeeper, app.stakingKeeper), + staking.NewAppModule(app.stakingKeeper, app.accountKeeper, app.supplyKeeper), + slashing.NewAppModule(app.slashingKeeper, app.accountKeeper, app.stakingKeeper), + ) + + // register the store decoders for simulation tests + app.sm.RegisterStoreDecoders() + ... +} +``` diff --git a/versioned_docs/version-0.45/integrate/building-modules/structure.md b/versioned_docs/version-0.45/integrate/building-modules/structure.md new file mode 100644 index 000000000..549cd634f --- /dev/null +++ b/versioned_docs/version-0.45/integrate/building-modules/structure.md @@ -0,0 +1,99 @@ + + +# Recommended Folder Structure + +This document outlines the recommended structure of Cosmos SDK modules. These ideas are meant to be applied as suggestions. Application developers are encouraged to improve upon and contribute to module structure and development design. {synopsis} + +## Structure + +A typical Cosmos SDK module can be structured as follows: + +```shell +proto +└── {project_name} +    └── {module_name} +    └── {proto_version} +       ├── {module_name}.proto +       ├── event.proto +       ├── genesis.proto +       ├── query.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. + +```shell +x/{module_name} +├── client +│   ├── cli +│   │ ├── query.go +│   │   └── tx.go +│   └── testutil +│   ├── cli_test.go +│   └── suite.go +├── exported +│   └── exported.go +├── keeper +│   ├── genesis.go +│   ├── grpc_query.go +│   ├── hooks.go +│   ├── invariants.go +│   ├── keeper.go +│   ├── keys.go +│   ├── msg_server.go +│   └── querier.go +├── module +│   └── module.go +├── simulation +│   ├── decoder.go +│   ├── genesis.go +│   ├── operations.go +│   └── params.go +├── spec +│   ├── 01_concepts.md +│   ├── 02_state.md +│   ├── 03_messages.md +│   └── 04_events.md +├── {module_name}.pb.go +├── abci.go +├── codec.go +├── errors.go +├── events.go +├── events.pb.go +├── expected_keepers.go +├── genesis.go +├── genesis.pb.go +├── keys.go +├── msgs.go +├── params.go +├── query.pb.go +└── 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). + +## Next {hide} + +Learn about [Errors](./errors.md) {hide} diff --git a/versioned_docs/version-0.45/integrate/building-modules/transaction_flow.svg b/versioned_docs/version-0.45/integrate/building-modules/transaction_flow.svg new file mode 100644 index 000000000..1ae962de3 --- /dev/null +++ b/versioned_docs/version-0.45/integrate/building-modules/transaction_flow.svg @@ -0,0 +1,48 @@ +UserUserbaseAppbaseApprouterrouterhandlerhandlermsgServermsgServerkeeperkeeperContext.EventManagerContext.EventManagerTransaction Type<Tx>Route(ctx, msgRoute)handlerMsg<Tx>(Context, Msg(...))<Tx>(Context, Msg)alt[addresses invalid, denominations wrong, etc.]errorperform action, update contextresults, error codeEmit relevant eventsmaybe wrap results in more structureresult, error coderesults, error code \ No newline at end of file diff --git a/versioned_docs/version-0.45/integrate/building-modules/upgrade.md b/versioned_docs/version-0.45/integrate/building-modules/upgrade.md new file mode 100644 index 000000000..f1c37930c --- /dev/null +++ b/versioned_docs/version-0.45/integrate/building-modules/upgrade.md @@ -0,0 +1,57 @@ + + +# 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} + +## Prerequisite Readings + +- [In-Place Store Migration](../core/upgrade.md) {prereq} + +## Consensus Version + +Successful upgrades of existing modules require each `AppModule` to implement the function `ConsensusVersion() uint64`. + +- The versions must be hard-coded by the module developer. +- The initial version **must** be set to 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. + +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: + +```golang +func (am AppModule) RegisterServices(cfg module.Configurator) { + // --snip-- + cfg.RegisterMigration(types.ModuleName, 1, func(ctx sdk.Context) error { + // 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. + }) +} +``` + +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: + ++++ 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. Since migration scripts manipulate legacy code, place these functions in a `legacy/` directory. For example, to write migration scripts for the bank module, place the functions in `x/bank/legacy/`. Use the recommended naming convention for these functions. For example, `v043bank` is the script that migrates this legacy package `x/bank/legacy/v043`: + +```golang +// Migrating bank module 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/legacy/v043`. +} +``` + +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). diff --git a/versioned_docs/version-0.45/integrate/ibc/README.md b/versioned_docs/version-0.45/integrate/ibc/README.md index 8caf30f1b..8be696391 100644 --- a/versioned_docs/version-0.45/integrate/ibc/README.md +++ b/versioned_docs/version-0.45/integrate/ibc/README.md @@ -8,13 +8,13 @@ parent: This repository contains reference documentation for the IBC protocol integration and concepts: -1. [Overview](overview.md) -2. [Integration](integration.md) -3. [Customization](custom.md) -4. [Relayer](relayer.md) -5. [Governance Proposals](proposals.md) +1. [Overview](./overview.md) +2. [Integration](./integration.md) +3. [Customization](./custom.md) +4. [Relayer](./relayer.md) +5. [Governance Proposals](./proposals.md) **NOTE**: The IBC module has been moved to its [own repository](https://github.com/cosmos/ibc-go). After reading about IBC, head on to the [Building Modules -documentation](../building-modules/) to learn more about the process of building modules. +documentation](../building-modules/README.md) to learn more about the process of building modules. diff --git a/versioned_docs/version-0.45/integrate/ibc/custom.md b/versioned_docs/version-0.45/integrate/ibc/custom.md index b521868cc..36de3085c 100644 --- a/versioned_docs/version-0.45/integrate/ibc/custom.md +++ b/versioned_docs/version-0.45/integrate/ibc/custom.md @@ -23,8 +23,8 @@ module correctly. ## Pre-requisites Readings -- [IBC Overview](overview.md)) {prereq} -- [IBC default integration](integration.md) {prereq} +- [IBC Overview](./overview.md)) {prereq} +- [IBC default integration](./integration.md) {prereq} ## Create a custom IBC application module diff --git a/versioned_docs/version-0.45/integrate/ibc/integration.md b/versioned_docs/version-0.45/integrate/ibc/integration.md index 6364c8275..ec48126fd 100644 --- a/versioned_docs/version-0.45/integrate/ibc/integration.md +++ b/versioned_docs/version-0.45/integrate/ibc/integration.md @@ -165,7 +165,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). +In order to use IBC, we need to add the new modules to the module `Manager` and to the `SimulationManager` in case your application supports [simulations](./../building-modules/simulator.md). ```go // app.go @@ -249,4 +249,4 @@ different chains. If you want to have a broader view of the changes take a look ## Next {hide} -Learn about how to create [custom IBC modules](custom.md) for your application {hide} +Learn about how to create [custom IBC modules](./custom.md) for your application {hide} diff --git a/versioned_docs/version-0.45/integrate/ibc/overview.md b/versioned_docs/version-0.45/integrate/ibc/overview.md index 82ccddf15..6aca66899 100644 --- a/versioned_docs/version-0.45/integrate/ibc/overview.md +++ b/versioned_docs/version-0.45/integrate/ibc/overview.md @@ -50,7 +50,7 @@ In IBC, blockchains do not directly pass messages to each other over the network - The proof format that all implementations must produce and verify is defined in [ICS-23 implementation](https://github.com/confio/ics23). -### Capabilities +### [Capabilities](./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. @@ -148,4 +148,4 @@ To learn more about IBC, check out the following specifications: ## Next {hide} -Learn about how to [integrate](integration.md) IBC to your application {hide} +Learn about how to [integrate](./integration.md) IBC to your application {hide} diff --git a/versioned_docs/version-0.45/integrate/ibc/relayer.md b/versioned_docs/version-0.45/integrate/ibc/relayer.md index 10fbdfc07..0e59885c8 100644 --- a/versioned_docs/version-0.45/integrate/ibc/relayer.md +++ b/versioned_docs/version-0.45/integrate/ibc/relayer.md @@ -6,7 +6,7 @@ order: 4 ## Prerequisites Readings -- [IBC Overview](overview.md) {prereq} +- [IBC Overview](./overview.md) {prereq} - [Events](https://github.com/cosmos/cosmos-sdk/blob/master/docs/core/events.md) {prereq} ## Events diff --git a/versioned_docs/version-0.45/integrate/ibc/upgrades/README.md b/versioned_docs/version-0.45/integrate/ibc/upgrades/README.md index d43ab3980..bc7c88966 100644 --- a/versioned_docs/version-0.45/integrate/ibc/upgrades/README.md +++ b/versioned_docs/version-0.45/integrate/ibc/upgrades/README.md @@ -10,5 +10,5 @@ This directory contains information on how to upgrade an IBC chain without break 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. -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 SDK. -2. The [developer-guide](developer-guide.md) is a guide for developers intending to develop IBC client implementations with upgrade functionality. +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 SDK. +2. The [developer-guide](./developer-guide.md) is a guide for developers intending to develop IBC client implementations with upgrade functionality. diff --git a/versioned_docs/version-0.45/integrate/ibc/upgrades/developer-guide.md b/versioned_docs/version-0.45/integrate/ibc/upgrades/developer-guide.md index f48f0d8c8..d41b3346d 100644 --- a/versioned_docs/version-0.45/integrate/ibc/upgrades/developer-guide.md +++ b/versioned_docs/version-0.45/integrate/ibc/upgrades/developer-guide.md @@ -6,7 +6,7 @@ order: 2 Learn how to implement upgrade functionality for your custom IBC client. {synopsis} -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. +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. 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. diff --git a/versioned_docs/version-0.45/user/run-node/interact-node.md b/versioned_docs/version-0.45/user/run-node/interact-node.md new file mode 100644 index 000000000..b1e375e6c --- /dev/null +++ b/versioned_docs/version-0.45/user/run-node/interact-node.md @@ -0,0 +1,227 @@ +# Interacting with the Node + +There are multiple ways to interact with a node: using the CLI, using gRPC or using the REST endpoints. {synopsis} + +## Pre-requisite Readings + +- [gRPC, REST and Tendermint Endpoints](../core/grpc_rest.md) {prereq} +- [Running a Node](./run-node.md) {prereq} + +## Using the CLI + +Now that your chain is running, it is time to try sending tokens from the first account you created to a second account. In a new terminal window, start by running the following query command: + +```bash +simd query bank balances $MY_VALIDATOR_ADDRESS --chain-id my-test-chain +``` + +You should see the current balance of the account you created, equal to the original balance of `stake` you granted it minus the amount you delegated via the `gentx`. Now, create a second account: + +```bash +simd keys add recipient --keyring-backend test + +# Put the generated address in a variable for later use. +RECIPIENT=$(simd keys show recipient -a --keyring-backend test) +``` + +The command above creates a local key-pair that is not yet registered on the chain. An account is created the first time it receives tokens from another account. Now, run the following command to send tokens to the `recipient` account: + +```bash +simd tx bank send $MY_VALIDATOR_ADDRESS $RECIPIENT 1000000stake --chain-id my-test-chain --keyring-backend test + +# Check that the recipient account did receive the tokens. +simd query bank balances $RECIPIENT --chain-id my-test-chain +``` + +Finally, delegate some of the stake tokens sent to the `recipient` account to the validator: + +```bash +simd tx staking delegate $(simd keys show my_validator --bech val -a --keyring-backend test) 500stake --from recipient --chain-id my-test-chain --keyring-backend test + +# Query the total delegations to `validator`. +simd query staking delegations-to $(simd keys show my_validator --bech val -a --keyring-backend test) --chain-id my-test-chain +``` + +You should see two delegations, the first one made from the `gentx`, and the second one you just performed from the `recipient` account. + +## Using gRPC + +The Protobuf ecosystem developed tools for different use cases, including code-generation from `*.proto` files into various languages. These tools allow 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). + +Since the code generation library largely depends on your own tech stack, we will only present three alternatives: + +- `grpcurl` for generic debugging and testing, +- programmatically via Go, +- CosmJS for JavaScript/TypeScript developers. + +### grpcurl + +[grpcurl](https://github.com/fullstorydev/grpcurl) is like `curl` but for gRPC. It is also available as a Go library, but we will use it only as a CLI command for debugging and testing purposes. Follow the instructions in the previous link to install it. + +Assuming you have a local node running (either a localnet, or connected a live network), you should be able to run the following command to list the Protobuf services available (you can replace `localhost:9000` by the gRPC server endpoint of another node, which is configured under the `grpc.address` field inside [`app.toml`](../run-node/run-node.md#configuring-the-node-using-apptoml)): + +```bash +grpcurl -plaintext localhost:9090 list +``` + +You should see a list of gRPC services, like `cosmos.bank.v1beta1.Query`. This is called reflection, which is a Protobuf endpoint returning a description of all available endpoints. Each of these represents a different Protobuf service, and each service exposes multiple RPC methods you can query against. + +In order to get a description of the service you can run the following command: + +```bash +grpcurl \ + localhost:9090 \ + describe cosmos.bank.v1beta1.Query # Service we want to inspect +``` + +It's also possible to execute an RPC call to query the node for information: + +```bash +grpcurl \ + -plaintext + -d '{"address":"$MY_VALIDATOR"}' \ + localhost:9090 \ + cosmos.bank.v1beta1.Query/AllBalances +``` + +The list of all available gRPC query endpoints is [coming soon](https://github.com/cosmos/cosmos-sdk/issues/7786). + +#### Query for historical state using grpcurl + +You may also query for historical data by passing some [gRPC metadata](https://github.com/grpc/grpc-go/blob/master/Documentation/grpc-metadata.md) to the query: the `x-cosmos-block-height` metadata should contain the block to query. Using grpcurl as above, the command looks like: + +```bash +grpcurl \ + -plaintext \ + -H "x-cosmos-block-height: 279256" \ + -d '{"address":"$MY_VALIDATOR"}' \ + localhost:9090 \ + cosmos.bank.v1beta1.Query/AllBalances +``` + +Assuming the state at that block has not yet been pruned by the node, this query should return a non-empty response. + +### Programmatically via Go + +The following snippet shows how to query the state using gRPC inside a Go program. The idea is to create a gRPC connection, and use the Protobuf-generated client code to query the gRPC server. + +```go +import ( + "context" + "fmt" + + "google.golang.org/grpc" + + sdk "github.com/cosmos/cosmos-sdk/types" + "github.com/cosmos/cosmos-sdk/types/tx" +) + +func queryState() error { + myAddress, err := sdk.AccAddressFromBech32("cosmos1...") + if err != nil { + return err + } + + // Create a connection to the gRPC server. + grpcConn := grpc.Dial( + "127.0.0.1:9090", // your gRPC server address. + grpc.WithInsecure(), // The SDK doesn't support any transport security mechanism. + ) + defer grpcConn.Close() + + // This creates a gRPC client to query the x/bank service. + bankClient := banktypes.NewQueryClient(grpcConn) + bankRes, err := bankClient.Balance( + context.Background(), + &banktypes.QueryBalanceRequest{Address: myAddress, Denom: "atom"}, + ) + if err != nil { + return err + } + + fmt.Println(bankRes.GetBalance()) // Prints the account balance + + return nil +} +``` + +You can replace the query client (here we are using `x/bank`'s) with one generated from any other Protobuf service. The list of all available gRPC query endpoints is [coming soon](https://github.com/cosmos/cosmos-sdk/issues/7786). + +#### Query for historical state using Go + +Querying for historical blocks is done by adding the block height metadata in the gRPC request. + +```go +import ( + "context" + "fmt" + + "google.golang.org/grpc" + "google.golang.org/grpc/metadata" + + grpctypes "github.com/cosmos/cosmos-sdk/types/grpc" + "github.com/cosmos/cosmos-sdk/types/tx" +) + +func queryState() error { + // --snip-- + + var header metadata.MD + bankRes, err = bankClient.Balance( + metadata.AppendToOutgoingContext(context.Background(), grpctypes.GRPCBlockHeightHeader, "12"), // Add metadata to request + &banktypes.QueryBalanceRequest{Address: myAddress, Denom: denom}, + grpc.Header(&header), // Retrieve header from response + ) + if err != nil { + return err + } + blockHeight = header.Get(grpctypes.GRPCBlockHeightHeader) + + fmt.Println(blockHeight) // Prints the block height (12) + + return nil +} +``` + +### CosmJS + +CosmJS documentation can be found at [https://cosmos.github.io/cosmjs](https://cosmos.github.io/cosmjs). As of January 2021, CosmJS documentation is still work in progress. + +## Using the REST Endpoints + +As described in the [gRPC guide](../core/grpc_rest.md), all gRPC services on the Cosmos SDK are made available for more convenient REST-based queries through gRPC-gateway. The format of the URL path is based on the Protobuf service method's full-qualified name, but may contain small customizations so that final URLs look more idiomatic. For example, the REST endpoint for the `cosmos.bank.v1beta1.Query/AllBalances` method is `GET /cosmos/bank/v1beta1/balances/{address}`. Request arguments are passed as query parameters. + +As a concrete example, the `curl` command to make balances request is: + +```bash +curl \ + -X GET \ + -H "Content-Type: application/json" \ + http://localhost:1317/cosmos/bank/v1beta1/balances/$MY_VALIDATOR +``` + +Make sure to replace `localhost:1317` with the REST endpoint of your node, configured under the `api.address` field. + +The list of all available REST endpoints is available as a Swagger specification file, it can be viewed at `localhost:1317/swagger`. Make sure that the `api.swagger` field is set to true in your [`app.toml`](../run-node/run-node.md#configuring-the-node-using-apptoml) file. + +### Query for historical state using REST + +Querying for historical state is done using the HTTP header `x-cosmos-block-height`. For example, a curl command would look like: + +```bash +curl \ + -X GET \ + -H "Content-Type: application/json" \ + -H "x-cosmos-block-height: 279256" + http://localhost:1317/cosmos/bank/v1beta1/balances/$MY_VALIDATOR +``` + +Assuming the state at that block has not yet been pruned by the node, this query should return a non-empty response. + +### Cross-Origin Resource Sharing (CORS) + +[CORS policies](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) are not enabled by default to help with security. If you would like to use the rest-server in a public environment we recommend you provide a reverse proxy, this can be done with [nginx](https://www.nginx.com/). For testing and development purposes there is an `enabled-unsafe-cors` field inside [`app.toml`](../run-node/run-node.md#configuring-the-node-using-apptoml). + +## Next {hide} + +Sending transactions using gRPC and REST requires some additional steps: generating the transaction, signing it, and finally broadcasting it. Read about [generating and signing transactions](./txs.md). {hide} diff --git a/versioned_docs/version-0.45/user/run-node/keyring.md b/versioned_docs/version-0.45/user/run-node/keyring.md new file mode 100644 index 000000000..711dccbd0 --- /dev/null +++ b/versioned_docs/version-0.45/user/run-node/keyring.md @@ -0,0 +1,132 @@ +# Setting up the keyring + +This document describes how to configure and use the keyring and its various backends for an [**application**](../basics/app-anatomy.md). {synopsis} + +The keyring holds the private/public keypairs used to interact with a node. For instance, a validator key needs to be set up before running the blockchain node, so that blocks can be correctly signed. The private key can be stored in different locations, called "backends", such as a file or the operating system's own key storage. + +## Available backends for the keyring + +Starting with the v0.38.0 release, Cosmos SDK comes with a new keyring implementation +that provides a set of commands to manage cryptographic keys in a secure fashion. The +new keyring supports multiple storage backends, some of which may not be available on +all operating systems. + +### The `os` backend + +The `os` backend relies on operating system-specific defaults to handle key storage +securely. Typically, an operating system's credential sub-system handles password prompts, +private keys storage, and user sessions according to the user's password policies. Here +is a list of the most popular operating systems and their respective passwords manager: + +- macOS (since Mac OS 8.6): [Keychain](https://support.apple.com/en-gb/guide/keychain-access/welcome/mac) +- Windows: [Credentials Management API](https://docs.microsoft.com/en-us/windows/win32/secauthn/credentials-management) +- GNU/Linux: + - [libsecret](https://gitlab.gnome.org/GNOME/libsecret) + - [kwallet](https://api.kde.org/frameworks/kwallet/html/index.html) + +GNU/Linux distributions that use GNOME as default desktop environment typically come with +[Seahorse](https://wiki.gnome.org/Apps/Seahorse). Users of KDE based distributions are +commonly provided with [KDE Wallet Manager](https://userbase.kde.org/KDE_Wallet_Manager). +Whilst the former is in fact a `libsecret` convenient frontend, the latter is a `kwallet` +client. + +`os` is the default option since operating system's default credentials managers are +designed to meet users' most common needs and provide them with a comfortable +experience without compromising on security. + +The recommended backends for headless environments are `file` and `pass`. + +### The `file` backend + +The `file` backend more closely resembles the keybase implementation used prior to +v0.38.1. It stores the keyring encrypted within the app's configuration directory. This +keyring will request a password each time it is accessed, which may occur multiple +times in a single command resulting in repeated password prompts. If using bash scripts +to execute commands using the `file` option you may want to utilize the following format +for multiple prompts: + +```sh +# assuming that KEYPASSWD is set in the environment +$ gaiacli config keyring-backend file # use file backend +$ (echo $KEYPASSWD; echo $KEYPASSWD) | gaiacli keys add me # multiple prompts +$ echo $KEYPASSWD | gaiacli keys show me # single prompt +``` + +::: tip +The first time you add a key to an empty keyring, you will be prompted to type the password twice. +::: + +### The `pass` backend + +The `pass` backend uses the [pass](https://www.passwordstore.org/) utility to manage on-disk +encryption of keys' sensitive data and metadata. Keys are stored inside `gpg` encrypted files +within app-specific directories. `pass` is available for the most popular UNIX +operating systems as well as GNU/Linux distributions. Please refer to its manual page for +information on how to download and install it. + +::: tip +**pass** uses [GnuPG](https://gnupg.org/) for encryption. `gpg` automatically invokes the `gpg-agent` +daemon upon execution, which handles the caching of GnuPG credentials. Please refer to `gpg-agent` +man page for more information on how to configure cache parameters such as credentials TTL and +passphrase expiration. +::: + +The password store must be set up prior to first use: + +```sh +pass init +``` + +Replace `` with your GPG key ID. You can use your personal GPG key or an alternative +one you may want to use specifically to encrypt the password store. + +### The `kwallet` backend + +The `kwallet` backend uses `KDE Wallet Manager`, which comes installed by default on the +GNU/Linux distributions that ships KDE as default desktop environment. Please refer to +[KWallet Handbook](https://docs.kde.org/stable5/en/kdeutils/kwallet5/index.html) for more +information. + +### The `test` backend + +The `test` backend is a password-less variation of the `file` backend. Keys are stored +unencrypted on disk. + +**Provided for testing purposes only. The `test` backend is not recommended for use in production environments**. + +### The `memory` backend + +The `memory` backend stores keys in memory. The keys are immediately deleted after the program has exited. + +**Provided for testing purposes only. The `memory` backend is not recommended for use in production environments**. + +## Adding keys to the keyring + +::: warning +Make sure you can build your own binary, and replace `simd` with the name of your binary in the snippets. +::: + +Applications developed using the Cosmos SDK come with the `keys` subcommand. For the purpose of this tutorial, we're running the `simd` CLI, which is an application built using the Cosmos SDK for testing and educational purposes. For more information, see [`simapp`](https://github.com/cosmos/cosmos-sdk/tree/v0.40.0-rc3/simapp). + +You can use `simd keys` for help about the keys command and `simd keys [command] --help` for more information about a particular subcommand. + +::: tip +You can also enable auto-completion with the `simd completion` command. For example, at the start of a bash session, run `. <(simd completion)`, and all `simd` subcommands will be auto-completed. +::: + +To create a new key in the keyring, run the `add` subcommand with a `` argument. For the purpose of this tutorial, we will solely use the `test` backend, and call our new key `my_validator`. This key will be used in the next section. + +```bash +$ simd keys add my_validator --keyring-backend test + +# Put the generated address in a variable for later use. +MY_VALIDATOR_ADDRESS=$(simd keys show my_validator -a --keyring-backend test) +``` + +This command generates a new 24-word mnemonic phrase, persists it to the relevant backend, and outputs information about the keypair. If this keypair will be used to hold value-bearing tokens, be sure to write down the mnemonic phrase somewhere safe! + +By default, the keyring generates a `secp256k1` keypair. The keyring also supports `ed25519` keys, which may be created by passing the `--algo ed25519` flag. A keyring can of course hold both types of keys simultaneously, and the Cosmos SDK's `x/auth` module (in particular its [AnteHandlers](../core/baseapp.md#antehandler)) supports natively these two public key algorithms. + +## Next {hide} + +Read about [running a node](./run-node.md) {hide} diff --git a/versioned_docs/version-0.45/user/run-node/rosetta.md b/versioned_docs/version-0.45/user/run-node/rosetta.md new file mode 100644 index 000000000..49f648665 --- /dev/null +++ b/versioned_docs/version-0.45/user/run-node/rosetta.md @@ -0,0 +1,133 @@ +# 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). + +## Add Rosetta Command + +The Rosetta API server is a stand-alone server that connects to a node of a chain developed with 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`). + +Import the `server` package: + +```go + "github.com/cosmos/cosmos-sdk/server" +``` + +Find the following line: + +```go +initRootCmd(rootCmd, encodingConfig) +``` + +After that line, add the following: + +```go +rootCmd.AddCommand( + server.RosettaCommand(encodingConfig.InterfaceRegistry, encodingConfig.Marshaler) +) +``` + +The `RosettaCommand` function builds the `rosetta` root command and is defined in the `server` package within Cosmos SDK. + +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. + +An implementation example can be found in `simapp` package. + +## Use Rosetta Command + +To run Rosetta in your application CLI, use the following command: + +``` +appd rosetta --help +``` + +To test and run Rosetta API endpoints for applications that are running and exposed, use the following command: + +``` +appd rosetta + --blockchain "your application name (ex: gaia)" + --network "your chain identifier (ex: testnet-1)" + --tendermint "tendermint endpoint (ex: localhost:26657)" + --grpc "gRPC endpoint (ex: localhost:9090)" + --addr "rosetta binding address (ex: :8080)" +``` + +## Extension + +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 message 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`. + +### Client interface override + +In case more customization is required, it's possible to embed the Client type and override the methods which require customizations. + +Example: + +```go +package custom_client +import ( + +"context" +"github.com/coinbase/rosetta-sdk-go/types" +"github.com/cosmos/cosmos-sdk/server/rosetta/lib" +) + +// CustomClient embeds the standard cosmos client +// which means that it implements the cosmos-rosetta-gateway Client +// interface while at the same time allowing to customize certain methods +type CustomClient struct { + *rosetta.Client +} + +func (c *CustomClient) ConstructionPayload(_ context.Context, request *types.ConstructionPayloadsRequest) (resp *types.ConstructionPayloadsResponse, err error) { + // provide custom signature bytes + panic("implement me") +} +``` + +### 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. + +Example: + +```go +package custom_errors +import crgerrs "github.com/cosmos/cosmos-sdk/server/rosetta/lib/errors" + +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. + +## Integration in app.go + +To integrate rosetta as a command in your application, in app.go, in your root command simply use the `server.RosettaCommand` method. + +Example: + +```go +package app +import ( + +"github.com/cosmos/cosmos-sdk/server" +"github.com/spf13/cobra" +) + +func buildAppCommand(rootCmd *cobra.Command) { + // more app.go init stuff + // ... + // add rosetta command + rootCmd.AddCommand(server.RosettaCommand(encodingConfig.InterfaceRegistry, encodingConfig.Marshaler)) +} +``` + +A full implementation example can be found in `simapp` package. + +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. diff --git a/versioned_docs/version-0.45/user/run-node/run-node.md b/versioned_docs/version-0.45/user/run-node/run-node.md new file mode 100644 index 000000000..d044ce763 --- /dev/null +++ b/versioned_docs/version-0.45/user/run-node/run-node.md @@ -0,0 +1,124 @@ +# Running a Node + +Now that the application is ready and the keyring populated, it's time to see how to run the blockchain node. In this section, the application we are running is called [`simapp`](https://github.com/cosmos/cosmos-sdk/tree/v0.40.0-rc3/simapp), and its corresponding CLI binary `simd`. {synopsis} + +## Pre-requisite Readings + +- [Anatomy of an SDK Application](../basics/app-anatomy.md) {prereq} +- [Setting up the keyring](./keyring.md) {prereq} + +## Initialize the Chain + +::: warning +Make sure you can build your own binary, and replace `simd` with the name of your binary in the snippets. +::: + +Before actually running the node, we need to initialize the chain, and most importantly its genesis file. This is done with the `init` subcommand: + +```bash +# The argument is the custom username of your node, it should be human-readable. +simd init --chain-id my-test-chain +``` + +The command above creates all the configuration files needed for your node to run, as well as a default genesis file, which defines the initial state of the network. All these configuration files are in `~/.simapp` by default, but you can overwrite the location of this folder by passing the `--home` flag. + +The `~/.simapp` folder has the following structure: + +```bash +. # ~/.simapp + |- data # Contains the databases used by the node. + |- config/ + |- app.toml # Application-related configuration file. + |- config.toml # Tendermint-related configuration file. + |- genesis.json # The genesis file. + |- node_key.json # Private key to use for node authentication in the p2p protocol. + |- priv_validator_key.json # Private key to use as a validator in the consensus protocol. +``` + +## 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. + +```bash +# to change the chain-id +jq '.chain_id = "testing"' genesis.json > temp.json && mv temp.json genesis.json + +# to enable the api server +sed -i '/\[api\]/,+3 s/enable = false/enable = true/' app.toml + +# to change the voting_period +jq '.app_state.gov.voting_params.voting_period = "600s"' genesis.json > temp.json && mv temp.json genesis.json + +# to change the inflation +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). + +Now that you have created a local account, go ahead and grant it some `stake` tokens in your chain's genesis file. Doing so will also make sure your chain is aware of this account's existence: + +```bash +simd add-genesis-account $MY_VALIDATOR_ADDRESS 100000000000stake +``` + +Recall that `$MY_VALIDATOR_ADDRESS` is a variable that holds the address of the `my_validator` key in the [keyring](./keyring.md#adding-keys-to-the-keyring). Also note that the tokens in the SDK have the `{amount}{denom}` format: `amount` is is a 18-digit-precision decimal number, and `denom` is the unique token identifier with its denomination key (e.g. `atom` or `uatom`). Here, we are granting `stake` tokens, as `stake` is the token identifier used for staking in [`simapp`](https://github.com/cosmos/cosmos-sdk/tree/v0.40.0-rc3/simapp). For your own chain with its own staking denom, that token identifier should be used instead. + +Now that your account has some tokens, you need to add a validator to your chain. Validators are special full-nodes that participate in the consensus process (implemented in the [underlying consensus engine](../intro/sdk-app-architecture.md#tendermint)) in order to add new blocks to the chain. Any account can declare its intention to become a validator operator, but only those with sufficient delegation get to enter the active set (for example, only the top 125 validator candidates with the most delegation get to be validators in the Cosmos Hub). For this guide, you will add your local node (created via the `init` command above) as a validator of your chain. Validators can be declared before a chain is first started via a special transaction included in the genesis file called a `gentx`: + +```bash +# Create a gentx. +simd gentx my_validator 100000000stake --chain-id my-test-chain --keyring-backend test + +# Add the gentx to the genesis file. +simd collect-gentxs +``` + +A `gentx` does three things: + +1. Registers the `validator` account you created as a validator operator account (i.e. the account that controls the validator). +2. Self-delegates the provided `amount` of staking tokens. +3. Link the operator account with a Tendermint node pubkey that will be used for signing blocks. If no `--pubkey` flag is provided, it defaults to the local node pubkey created via the `simd init` command above. + +For more information on `gentx`, use the following command: + +```bash +simd gentx --help +``` + +## Configuring the Node Using `app.toml` and `config.toml` + +The Cosmos SDK automatically generates two configuration files inside `~/.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... + +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: + +```toml + # The minimum gas prices a validator is willing to accept for processing a + # transaction. A transaction's fees must meet the minimum of any denomination + # specified in this config (e.g. 0.25token1;0.0001token2). + minimum-gas-prices = "0stake" +``` + +## Run a Localnet + +Now that everything is set up, you can finally start your node: + +```bash +simd start +``` + +You should see blocks come in. + +The previous command allow you to run a single node. This is enough for the next section on interacting with this node, but you may wish to run multiple nodes at the same time, and see how consensus happens between them. + +The naive way would be to run the same commands again in separate terminal windows. This is possible, however in the SDK, we leverage the power of [Docker Compose](https://docs.docker.com/compose/) to run a localnet. If you need inspiration on how to set up your own localnet with Docker Compose, you can have a look at the SDK's [`docker-compose.yml`](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/docker-compose.yml). + +## Next {hide} + +Read about the [Interacting with your Node](./interact-node.md) {hide} diff --git a/versioned_docs/version-0.45/user/run-node/run-testnet.md b/versioned_docs/version-0.45/user/run-node/run-testnet.md new file mode 100644 index 000000000..868a8a33b --- /dev/null +++ b/versioned_docs/version-0.45/user/run-node/run-testnet.md @@ -0,0 +1,95 @@ +# Running a Testnet + +The `simd testnet` subcommand makes it easy to initialize and start a simulated test network for testing purposes. {synopsis} + +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. + +## Initialize Files + +First, let's take a look at the `init-files` subcommand. + +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. + +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)). + +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. + +### 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. + +### 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). + +## Start Testnet + +Now, let's take a look at the `start` subcommand. + +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. + +You can start the local test network by running the following command: + +```bash +simd testnet start +``` + +You should see something similar to the following: + +```bash +acquiring test network lock +preparing test network with chain-id "chain-mtoD9v" + + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++ THIS MNEMONIC IS FOR TESTING PURPOSES ONLY ++ +++ DO NOT USE IN PRODUCTION ++ +++ ++ +++ sustain know debris minute gate hybrid stereo custom ++ +++ divorce cross spoon machine latin vibrant term oblige ++ +++ moment beauty laundry repeat grab game bronze truly ++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + + +starting test network... +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). + +Check the status of the first validator node: + +``` +simd status +``` + +Import the key from the provided mnemonic: + +``` +simd keys add test --recover --keyring-backend test +``` + +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. diff --git a/versioned_docs/version-0.45/user/run-node/txs.md b/versioned_docs/version-0.45/user/run-node/txs.md new file mode 100644 index 000000000..248f1b222 --- /dev/null +++ b/versioned_docs/version-0.45/user/run-node/txs.md @@ -0,0 +1,355 @@ +# Generating, Signing and Broadcasting Transactions + +This document describes how to generate an (unsigned) transaction, signing it (with one or multiple keys), and broadcasting it to the network. {synopsis} + +## Using the CLI + +The easiest way to send transactions is using the CLI, as we have seen in the previous page when [interacting with a node](./interact-node.md#using-the-cli). For example, running the following command + +```bash +simd tx bank send $MY_VALIDATOR_ADDRESS $RECIPIENT 1000stake --chain-id my-test-chain --keyring-backend test +``` + +will run the following steps: + +- generate a transaction with one `Msg` (`x/bank`'s `MsgSend`), and print the generated transaction to the console. +- ask the user for confirmation to send the transaction from the `$MY_VALIDATOR_ADDRESS` account. +- fetch `$MY_VALIDATOR_ADDRESS` 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. + +The CLI bundles all the necessary steps into a simple-to-use user experience. However, it's possible to run all the steps individually too. + +### Generating a Transaction + +Generating a transaction can simply be done by appending the `--generate-only` flag on any `tx` command, e.g.: + +```bash +simd tx bank send $MY_VALIDATOR_ADDRESS $RECIPIENT 1000stake --chain-id my-test-chain --generate-only +``` + +This will output the unsigned transaction as JSON in the console. We can also save the unsigned transaction to a file (to be passed around between signers more easily) by appending `> unsigned_tx.json` to the above command. + +### Signing a Transaction + +Signing a transaction using the CLI requires the unsigned transaction to be saved in a file. Let's assume the unsigned transaction is in a file called `unsigned_tx.json` in the current directory (see previous paragraph on how to do that). Then, simply run the following command: + +```bash +simd tx sign unsigned_tx.json --chain-id my-test-chain --keyring-backend test --from $MY_VALIDATOR_ADDRESS +``` + +This command will decode the unsigned transaction and sign it with `SIGN_MODE_DIRECT` with `$MY_VALIDATOR_ADDRESS`'s key, which we already set up in the keyring. The signed transaction will be output as JSON to the console, and, as above, we can save it to a file by appending `> signed_tx.json`. + +Some useful flags to consider in the `tx sign` command: + +- `--sign-mode`: you may use `amino-json` to sign the transaction using `SIGN_MODE_LEGACY_AMINO_JSON`, +- `--offline`: sign in offline mode. This means that the `tx sign` command doesn't connect to the node to retrieve the signer's account number and sequence, both needed for signing. In this case, you must manually supply the `--account-number` and `--sequence` flags. This is useful for offline signing, i.e. signing in a secure environment which doesn't have access to the internet. + +#### Signing with Multiple Signers + +::: warning +Please note that signing a transaction with multiple signers or with a multisig account, where at least one signer uses `SIGN_MODE_DIRECT`, is not yet possible. You may follow [this Github issue](https://github.com/cosmos/cosmos-sdk/issues/8141) for more info. +::: + +Signing with multiple signers is done with the `tx multisign` command. This command assumes that all signers use `SIGN_MODE_LEGACY_AMINO_JSON`. The flow is similar to the `tx sign` command flow, but instead of signing an unsigned transaction file, each signer signs the file signed by previous signer(s). The `tx multisign` command will append signatures to the existing transactions. It is important that signers sign the transaction **in the same order** as given by the transaction, which is retrievable using the `GetSigners()` method. + +For example, starting with the `unsigned_tx.json`, and assuming the transaction has 4 signers, we would run: + +```bash +# Let signer1 sign the unsigned tx. +simd tx multisignsign unsigned_tx.json signer_key_1 --chain-id my-test-chain --keyring-backend test > partial_tx_1.json +# Now signer1 will send the partial_tx_1.json to the signer2. +# Signer2 appends their signature: +simd tx multisignsign partial_tx_1.json signer_key_2 --chain-id my-test-chain --keyring-backend test > partial_tx_2.json +# Signer2 sends the partial_tx_2.json file to signer3, and signer3 can append his signature: +simd tx multisignsign partial_tx_2.json signer_key_3 --chain-id my-test-chain --keyring-backend test > partial_tx_3.json +``` + +### Broadcasting a Transaction + +Broadcasting a transaction is done using the following command: + +```bash +simd tx broadcast tx_signed.json +``` + +You may optionally pass the `--broadcast-mode` flag to specify which response to receive from the node: + +- `block`: the CLI waits for the tx to be committed in a block. +- `sync`: the CLI waits for a CheckTx execution response only. +- `async`: the CLI returns immediately (transaction might fail). + +## Programmatically with Go + +It is possible to manipulate transactions programmatically via Go using the Cosmos SDK's `TxBuilder` interface. + +### Generating a Transaction + +Before generating a transaction, a new instance of a `TxBuilder` needs to be created. Since the SDK supports both Amino and Protobuf transactions, the first step would be to decide which encoding scheme to use. All the subsequent steps remain unchanged, whether you're using Amino or Protobuf, as `TxBuilder` abstracts the encoding mechanisms. In the following snippet, we will use Protobuf. + +```go +import ( + "github.com/cosmos/cosmos-sdk/simapp" +) + +func sendTx() error { + // Choose your codec: Amino or Protobuf. Here, we use Protobuf, given by the + // following function. + encCfg := simapp.MakeTestEncodingConfig() + + // Create a new TxBuilder. + txBuilder := encCfg.TxConfig.NewTxBuilder() + + // --snip-- +} +``` + +We can also set up some keys and addresses that will send and receive the transactions. Here, for the purpose of the tutorial, we will be using some dummy data to create keys. + +```go +import ( + "github.com/cosmos/cosmos-sdk/testutil/testdata" +) + +priv1, _, addr1 := testdata.KeyTestPubAddr() +priv2, _, addr2 := testdata.KeyTestPubAddr() +priv3, _, addr3 := testdata.KeyTestPubAddr() +``` + +Populating the `TxBuilder` can be done via its [methods](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/client/tx_config.go#L32-L45): + +```go +import ( + banktypes "github.com/cosmos/cosmos-sdk/x/bank/types" +) + +func sendTx() error { + // --snip-- + + // Define two x/bank MsgSend messages: + // - from addr1 to addr3, + // - from addr2 to addr3. + // This means that the transactions needs two signers: addr1 and addr2. + msg1 := banktypes.NewMsgSend(addr1, addr3, types.NewCoins(types.NewInt64Coin("atom", 12))) + msg2 := banktypes.NewMsgSend(addr2, addr3, types.NewCoins(types.NewInt64Coin("atom", 34))) + + err := txBuilder.SetMsgs(msg1, msg2) + if err != nil { + return err + } + + txBuilder.SetGasLimit(...) + txBuilder.SetFeeAmount(...) + txBuilder.SetMemo(...) + txBuilder.SetTimeoutHeight(...) +} +``` + +At this point, `TxBuilder`'s underlying transaction is ready to be signed. + +### Signing a Transaction + +We 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: + +- for each signer, populate the signer's `SignerInfo` inside `TxBuilder`, +- once all `SignerInfo`s are populated, for each signer, sign the `SignDoc` (the payload to be signed). + +In the current `TxBuilder`'s API, both steps are done using the same method: `SetSignatures()`. The current API requires us to first perform a round of `SetSignatures()` _with empty signatures_, only to populate `SignerInfo`s, and a second round of `SetSignatures()` to actually sign the correct payload. + +```go +import ( + cryptotypes "github.com/cosmos/cosmos-sdk/crypto/types" + "github.com/cosmos/cosmos-sdk/types/tx/signing" + xauthsigning "github.com/cosmos/cosmos-sdk/x/auth/signing" +) + +func sendTx() error { + // --snip-- + + privs := []cryptotypes.PrivKey{priv1, priv2} + accNums:= []uint64{..., ...} // The accounts' account numbers + accSeqs:= []uint64{..., ...} // The accounts' sequence numbers + + // First round: we gather all the signer infos. We use the "set empty + // signature" hack to do that. + var sigsV2 []signing.SignatureV2 + for i, priv := range privs { + sigV2 := signing.SignatureV2{ + PubKey: priv.PubKey(), + Data: &signing.SingleSignatureData{ + SignMode: encCfg.TxConfig.SignModeHandler().DefaultMode(), + Signature: nil, + }, + Sequence: accSeqs[i], + } + + sigsV2 = append(sigsV2, sigV2) + } + err := txBuilder.SetSignatures(sigsV2...) + if err != nil { + return err + } + + // Second round: all signer infos are set, so each signer can sign. + sigsV2 = []signing.SignatureV2{} + for i, priv := range privs { + signerData := xauthsigning.SignerData{ + ChainID: chainID, + AccountNumber: accNums[i], + Sequence: accSeqs[i], + } + sigV2, err := tx.SignWithPrivKey( + encCfg.TxConfig.SignModeHandler().DefaultMode(), signerData, + txBuilder, priv, encCfg.TxConfig, accSeqs[i]) + if err != nil { + return nil, err + } + + sigsV2 = append(sigsV2, sigV2) + } + err = txBuilder.SetSignatures(sigsV2...) + if err != nil { + return err + } +} +``` + +The `TxBuilder` is now correctly populated. To print it, you can use the `TxConfig` interface from the initial encoding config `encCfg`: + +```go +func sendTx() error { + // --snip-- + + // Generated Protobuf-encoded bytes. + txBytes, err := encCfg.TxConfig.TxEncoder()(txBuilder.GetTx()) + if err != nil { + return err + } + + // Generate a JSON string. + txJSONBytes, err := encCfg.TxConfig.TxJSONEncoder()(txBuilder.GetTx()) + if err != nil { + return err + } + txJSON := string(txJSONBytes) +} +``` + +### Broadcasting a Transaction + +The preferred way to broadcast a transaction is to use gRPC, though using REST (via `gRPC-gateway`) or the Tendermint RPC is also posible. An overview of the differences between these methods is exposed [here](../core/grpc_rest.md). For this tutorial, we will only describe the gRPC method. + +```go +import ( + "context" + "fmt" + + "google.golang.org/grpc" + + "github.com/cosmos/cosmos-sdk/types/tx" +) + +func sendTx(ctx context.Context) error { + // --snip-- + + // Create a connection to the gRPC server. + grpcConn := grpc.Dial( + "127.0.0.1:9090", // Or your gRPC server address. + grpc.WithInsecure(), // The SDK doesn't support any transport security mechanism. + ) + defer grpcConn.Close() + + // Broadcast the tx via gRPC. We create a new client for the Protobuf Tx + // service. + txClient := tx.NewServiceClient(grpcConn) + // We then call the BroadcastTx method on this client. + grpcRes, err := txClient.BroadcastTx( + ctx, + &tx.BroadcastTxRequest{ + Mode: tx.BroadcastMode_BROADCAST_MODE_SYNC, + TxBytes: txBytes, // Proto-binary of the signed transaction, see previous step. + }, + ) + if err != nil { + return err + } + + fmt.Println(grpcRes.TxResponse.Code) // Should be `0` if the tx is successful + + return nil +} +``` + +#### Simulating a Transaction + +Before broadcasting a transaction, we sometimes may want to dry-run the transaction, to estimate some information about the transaction without actually committing it. This is called simulating a transaction, and can be done as follows: + +```go +import ( + "context" + "fmt" + "testing" + + "github.com/cosmos/cosmos-sdk/client" + "github.com/cosmos/cosmos-sdk/types/tx" + authtx "github.com/cosmos/cosmos-sdk/x/auth/tx" +) + +func simulateTx() error { + // --snip-- + + // Simulate the tx via gRPC. We create a new client for the Protobuf Tx + // service. + txClient := tx.NewServiceClient(grpcConn) + txBytes := /* Fill in with your signed transaction bytes. */ + + // We then call the Simulate method on this client. + grpcRes, err := txClient.Simulate( + context.Background(), + &tx.SimulateRequest{ + TxBytes: txBytes, + }, + ) + if err != nil { + return err + } + + fmt.Println(grpcRes.GasInfo) // Prints estimated gas used. + + return nil +} +``` + +## Using gRPC + +It is not possible to generate or sign a transaction using gRPC, only to broadcast one. + +### 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: + +```bash +grpcurl -plaintext \ + -d '{"tx_bytes":"{{txBytes}}","mode":"BROADCAST_MODE_SYNC"}' \ + localhost:9090 \ + cosmos.tx.v1beta1.Service/BroadcastTx +``` + +## Using REST + +It is not possible to generate or sign a transaction using REST, only to broadcast one. + +### Broadcasting a Transaction + +Broadcasting a transaction using the REST endpoint (served by `gRPC-gateway`) can be done by sending a POST request as follows, where the `txBytes` are the protobuf-encoded bytes of a signed transaction: + +```bash +curl -X POST \ + -H "Content-Type: application/json" \ + -d'{"tx_bytes":"{{txBytes}}","mode":"BROADCAST_MODE_SYNC"}' \ + localhost:1317/cosmos/tx/v1beta1/txs +``` + +## Using CosmJS (JavaScript & TypeScript) + +CosmJS aims to build client libraries in JavaScript that can be embedded in web applications. Please see [https://cosmos.github.io/cosmjs](https://cosmos.github.io/cosmjs) for more information. As of January 2021, CosmJS documentation is still work in progress. diff --git a/versioned_docs/version-0.46/develop/advanced-concepts/00-baseapp.md b/versioned_docs/version-0.46/develop/advanced-concepts/00-baseapp.md index ce6bc4957..7aee39deb 100644 --- a/versioned_docs/version-0.46/develop/advanced-concepts/00-baseapp.md +++ b/versioned_docs/version-0.46/develop/advanced-concepts/00-baseapp.md @@ -1,23 +1,17 @@ # BaseApp -:::note Synopsis -This document describes `BaseApp`, the abstraction that implements the core functionalities of a Cosmos SDK application. -::: +This document describes `BaseApp`, the abstraction that implements the core functionalities of a Cosmos SDK application. {synopsis} -:::note +## Pre-requisite Readings -### Pre-requisite Readings - -* [Anatomy of a Cosmos SDK application](../high-level-concepts/00-overview-app.md) -* [Lifecycle of a Cosmos SDK transaction](../high-level-concepts/01-tx-lifecycle.md) - -::: +* [Anatomy of a Cosmos SDK application](../basics/app-anatomy.md) {prereq} +* [Lifecycle of a Cosmos SDK transaction](../basics/tx-lifecycle.md) {prereq} ## Introduction `BaseApp` is a base type that implements the core of a Cosmos SDK application, namely: -* The [Application Blockchain Interface](#main-abci-10-messages), for the state-machine to communicate with the underlying consensus engine (e.g. CometBFT). +* The [Application Blockchain Interface](#main-abci-messages), 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](#state-updates), as the state-machine can have different volatile states updated based on the ABCI message received. @@ -47,9 +41,7 @@ management logic. The `BaseApp` type holds many important parameters for any Cosmos SDK based application. -```go reference -https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/baseapp/baseapp.go#L50-L146 -``` ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/baseapp/baseapp.go#L45-L137 Let us go through the most important components. @@ -58,7 +50,7 @@ Let us go through the most important components. First, the important parameters that are initialized during the bootstrapping of the application: -* [`CommitMultiStore`](04-store.md#commitmultistore): This is the main store of the application, +* [`CommitMultiStore`](./05-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 @@ -72,38 +64,37 @@ First, the important parameters that are initialized during the bootstrapping of 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://pkg.go.dev/github.com/cosmos/cosmos-sdk/types#TxDecoder): It is used to decode - raw transaction bytes relayed by the underlying CometBFT engine. + raw transaction bytes relayed by the underlying Tendermint engine. +* [`ParamStore`](#paramstore): The parameter store used to get and set application consensus parameters. * [`AnteHandler`](#antehandler): This handler is used to handle signature verification, fee payment, and other pre-message execution checks when a transaction is received. It's executed during [`CheckTx/RecheckTx`](#checktx) and [`DeliverTx`](#delivertx). -* [`InitChainer`](../high-level-concepts/00-overview-app.md#initchainer), - [`BeginBlocker` and `EndBlocker`](../high-level-concepts/00-overview-app.md#beginblocker-and-endblocker): These are +* [`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 CometBFT engine. + ABCI messages from the underlying Tendermint engine. Then, parameters used to define [volatile states](#state-updates) (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. -* `processProposalState`: This state is updated during [`ProcessProposal`](#process-proposal). -* `prepareProposalState`: This state is updated during [`PrepareProposal`](#prepare-proposal). Finally, a few more important parameters: * `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 and can be used by the application for various things like + 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://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_basic_concepts.md#mempool-methods) + enters the [mempool](https://docs.tendermint.com/master/tendermint-core/mempool/) 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](../high-level-concepts/00-overview-app.md#constructor-function). + [application's constructor function](../basics/app-anatomy.md#constructor-function). ## Constructor @@ -117,7 +108,7 @@ 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.47.0-rc1/baseapp/options.go) +possibility to provide additional [`options`](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/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`. @@ -204,13 +195,13 @@ The application's `msgServiceRouter` is initialized with all the routes using th ### gRPC Query Router -Similar to `sdk.Msg`s, [`queries`](../../integrate/building-modules/02-messages-and-queries.md#queries) need to be routed to the appropriate module's [`Query` service](../../integrate/building-modules/04-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 CometBFT RPC endpoint. +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. -Just like the `msgServiceRouter`, the `grpcQueryRouter` is initialized with all the query routes using the application's [module manager](../../integrate/building-modules/01-module-manager.md) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](../high-level-concepts/00-overview-app.md#app-constructor). +Just like the `msgServiceRouter`, the `grpcQueryRouter` is initialized with all the query routes using the application's [module manager](../building-modules/module-manager.md) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](../basics/app-anatomy.md#app-constructor). -## Main ABCI 1.0 Messages +## Main ABCI Messages -The [Application-Blockchain Interface](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_basic_concepts.md) (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 CometBFT. +The [Application-Blockchain Interface](https://docs.tendermint.com/master/spec/abci/) (ABCI) is a generic interface that connects a state-machine with a consensus engine to form a functional full-node. It can be wrapped in any language, and needs to be implemented by each application-specific blockchain built on top of an ABCI-compatible consensus engine like Tendermint. The consensus engine handles two main tasks: @@ -219,13 +210,7 @@ The consensus engine handles two main tasks: It is **not** the role of the consensus engine to define the state or the validity of transactions. Generally, transactions are handled by the consensus engine in the form of `[]bytes`, and relayed to the application via the ABCI to be decoded and processed. At keys moments in the networking and consensus processes (e.g. beginning of a block, commit of a block, reception of an unconfirmed transaction, ...), the consensus engine emits ABCI messages for the state-machine to act on. -Developers building on top of the Cosmos SDK need not implement the ABCI themselves, as `BaseApp` comes with a built-in implementation of the interface. Let us go through the main ABCI messages that `BaseApp` implements: - -* [`Prepare Proposal`](#prepare-proposal) -* [`Process Proposal`](#process-proposal) -* [`CheckTx`](#checktx) -* [`DeliverTx`](#delivertx) - +Developers building on top of the Cosmos SDK need not implement the ABCI themselves, as `BaseApp` comes with a built-in implementation of the interface. Let us go through the main ABCI messages that `BaseApp` implements: [`CheckTx`](#checktx) and [`DeliverTx`](#delivertx) ### CheckTx @@ -237,28 +222,27 @@ 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 the checks **lightweight** because gas fees are not charged for the resources (CPU, data load...) used during the `CheckTx`. -In the Cosmos SDK, after [decoding transactions](06-encoding.md), `CheckTx()` is implemented +In the Cosmos SDK, after [decoding transactions](./07-encoding.md), `CheckTx()` is implemented to do the following checks: 1. Extract the `sdk.Msg`s from the transaction. -2. **Optionally** perform _stateless_ checks by calling `ValidateBasic()` on each of the `sdk.Msg`s. This is done +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. - This check is still performed for messages that have not yet migrated to the new message validation mechanism defined in [RFC 001](https://docs.cosmos.network/main/rfc/rfc-001-tx-validation) and still have a `ValidateBasic()` method. -3. Perform non-module related _stateful_ checks on the [account](../high-level-concepts/03-accounts.md). This step is mainly about checking +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`](../high-level-concepts/04-gas-fees.md) counting occurs here, - as `sdk.Msg`s are not processed. Usually, the [`AnteHandler`](../high-level-concepts/04-gas-fees.md#antehandler) will check that the `gas` provided + 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. `CheckTx` does **not** process `sdk.Msg`s - they 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`](../high-level-concepts/04-gas-fees.md#antehandler) in the [`RunTx()`](#runtx) +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](#state-updates) 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](#state-updates). For example, when a transaction goes through `CheckTx()`, the +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 @@ -266,7 +250,7 @@ be rejected. In any case, the sender's account will not actually pay the fees un 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://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_methods.md#checktx). +`CheckTx` returns a response to the underlying consensus engine of type [`abci.ResponseCheckTx`](https://docs.tendermint.com/master/spec/abci/abci.html#checktx-2). The response contains: * `Code (uint32)`: Response Code. `0` if successful. @@ -275,12 +259,8 @@ The response contains: * `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: - -```go reference -https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/auth/ante/basic.go#L96 -``` - -* `Events ([]cmn.KVPair)`: Key-Value tags for filtering and indexing transactions (eg. by account). See [`event`s](08-events.md) for more. + +++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/ante/basic.go#L95-L95 +* `Events ([]cmn.KVPair)`: Key-Value tags for filtering and indexing transactions (eg. by account). See [`event`s](./10-events.md) for more. * `Codespace (string)`: Namespace for the Code. #### RecheckTx @@ -296,22 +276,20 @@ This allows certain checks like signature verification can be skipped during `Ch When the underlying consensus engine receives a block proposal, each transaction in the block needs to be processed by the application. To that end, the underlying consensus engine sends a `DeliverTx` message to the application for each transaction in a sequential order. -Before the first transaction of a given block is processed, a [volatile state](#state-updates) called `deliverState` is initialized during [`BeginBlock`](#beginblock). This state is updated each time a transaction is processed via `DeliverTx`, and committed to the [main state](#state-updates) when the block is [committed](#commit), after what it is set to `nil`. +Before the first transaction of a given block is processed, a [volatile state](#state-updates) called `deliverState` is initialized 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 it is set to `nil`. `DeliverTx` performs the **exact same steps as `CheckTx`**, with a little caveat at step 3 and the addition of a fifth step: 1. The `AnteHandler` does **not** check that the transaction's `gas-prices` is sufficient. That is because the `min-gas-prices` value `gas-prices` is checked against is local to the node, and therefore what is enough for one full-node might not be for another. This means that the proposer can potentially include transactions for free, although they are not incentivised to do so, as they earn a bonus on the total fee of the block they propose. -2. For each `sdk.Msg` in the transaction, route to the appropriate module's Protobuf [`Msg` service](../../integrate/building-modules/03-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`. +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`. 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: -```go reference -https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/store/types/gas.go#L230-L241 -``` ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/store/types/gas.go#L230-L241 At any point, if `GasConsumed > GasWanted`, the function returns with `Code != 0` and `DeliverTx` fails. -`DeliverTx` returns a response to the underlying consensus engine of type [`abci.ResponseDeliverTx`](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_methods.md#delivertx). The response contains: +`DeliverTx` returns a response to the underlying consensus engine of type [`abci.ResponseDeliverTx`](https://docs.tendermint.com/master/spec/abci/abci.html#delivertx-2). The response contains: * `Code (uint32)`: Response Code. `0` if successful. * `Data ([]byte)`: Result bytes, if any. @@ -319,7 +297,7 @@ At any point, if `GasConsumed > GasWanted`, the function returns with `Code != 0 * `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](08-events.md) for more. +* `Events ([]cmn.KVPair)`: Key-Value tags for filtering and indexing transactions (eg. by account). See [`event`s](./10-events.md) for more. * `Codespace (string)`: Namespace for the Code. ## RunTx, AnteHandler, RunMsgs, PostHandler @@ -328,17 +306,15 @@ At any point, if `GasConsumed > GasWanted`, the function returns with `Code != 0 `RunTx` is called from `CheckTx`/`DeliverTx` to handle the transaction, with `runTxModeCheck` or `runTxModeDeliver` as parameter to differentiate between the two modes of execution. Note that when `RunTx` receives a transaction, it has already been decoded. -The first thing `RunTx` does upon being called is to retrieve the `context`'s `CacheMultiStore` by calling the `getContextForTx()` function with the appropriate mode (either `runTxModeCheck` or `runTxModeDeliver`). This `CacheMultiStore` is a branch of the main store, with cache functionality (for query requests), instantiated during `BeginBlock` for `DeliverTx` and during the `Commit` of the previous block for `CheckTx`. After that, two `defer func()` are called for [`gas`](../high-level-concepts/04-gas-fees.md) management. They are executed when `runTx` returns and make sure `gas` is actually consumed, and will throw errors, if any. +The first thing `RunTx` does upon being called is to retrieve the `context`'s `CacheMultiStore` by calling the `getContextForTx()` function with the appropriate mode (either `runTxModeCheck` or `runTxModeDeliver`). This `CacheMultiStore` is a branch of the main store, with cache functionality (for query requests), instantiated during `BeginBlock` for `DeliverTx` and during the `Commit` of the previous block for `CheckTx`. After that, two `defer func()` are called for [`gas`](../basics/gas-fees.md) management. They are executed when `runTx` returns and make sure `gas` is actually consumed, and will throw errors, if any. -After that, `RunTx()` calls `ValidateBasic()`, when available and for backward compatibility, 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. +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. 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. -```go reference -https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/baseapp/baseapp.go#L663-L672 -``` ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/baseapp/baseapp.go#L647-L654 -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](10-ocap.md) of the Cosmos SDK. +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](./12-ocap.md) of the Cosmos SDK. 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. @@ -346,36 +322,32 @@ Finally, the [`RunMsgs()`](#runmsgs) function is called to process the `sdk.Msg` 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. -```go reference -https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/types/handler.go#L6-L8 -``` ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/handler.go#L6-L8 The `AnteHandler` is theoretically optional, but still a very important component of public blockchain networks. It serves 3 primary purposes: -* Be a primary line of defense against spam and second line of defense (the first one being the mempool) against transaction replay with fees deduction and [`sequence`](01-transactions.md#transaction-generation) checking. +* 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`](./01-transactions.md#transaction-generation) checking. * Perform preliminary _stateful_ validity checks like ensuring signatures are valid or that the sender has enough funds to pay for fees. * Play a role in the incentivisation of stakeholders via the collection of transaction fees. -`BaseApp` holds an `anteHandler` as parameter that is initialized in the [application's constructor](../high-level-concepts/00-overview-app.md#application-constructor). The most widely used `anteHandler` is the [`auth` module](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/auth/ante/ante.go). +`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.46.0-rc1/x/auth/ante/ante.go). -Click [here](../high-level-concepts/04-gas-fees.md#antehandler) for more on the `anteHandler`. +Click [here](../basics/gas-fees.md#antehandler) for more on the `anteHandler`. ### RunMsgs `RunMsgs` is called from `RunTx` with `runTxModeCheck` as parameter to check the existence of a route for each message the transaction, and with `runTxModeDeliver` to actually process the `sdk.Msg`s. -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](../../integrate/building-modules/03-msg-services.md) RPC is executed, before `RunMsgs` returns. +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. ### PostHandler -`PostHandler` is similar to `AnteHandler`, but it, as the name suggests, executes custom post tx processing logic after [`RunMsgs`](#runmsgs) is called. `PostHandler` receives the `Result` of the the `RunMsgs` in order to enable this customizable behavior. +_PostHandler_ are like `AnteHandler` (they share the same signature), but they execute after [`RunMsgs`](#runmsgs). Like `AnteHandler`s, `PostHandler`s are theoretically optional, one use case for `PostHandler`s is transaction tips (enabled by default in simapp). Other use cases like unused gas refund can also be enabled by `PostHandler`s. -```go reference -https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/auth/posthandler/post.go#L1-L15 -``` ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/posthandler/post.go#L14:L27 Note, when `PostHandler`s fail, the state from `runMsgs` is also reverted, effectively making the transaction fail. @@ -383,37 +355,32 @@ Note, when `PostHandler`s fail, the state from `runMsgs` is also reverted, effec ### InitChain -The [`InitChain` ABCI message](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_basic_concepts.md#method-overview) is sent from the underlying CometBFT engine when the chain is first started. It is mainly used to **initialize** parameters and state like: +The [`InitChain` ABCI message](https://docs.tendermint.com/master/spec/abci/abci.html#initchain) is sent from the underlying Tendermint engine when the chain is first started. It is mainly used to **initialize** parameters and state like: -* [Consensus Parameters](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_app_requirements.md#consensus-parameters) via `setConsensusParams`. -* [`checkState` and `deliverState`](#state-updates) via `setState`. -* The [block gas meter](../high-level-concepts/04-gas-fees.md#block-gas-meter), with infinite gas to process genesis transactions. +* [Consensus Parameters](https://docs.tendermint.com/master/spec/abci/apps.html#consensus-parameters) via `setConsensusParams`. +* [`checkState` and `deliverState`](#state-updates) via `setCheckState` and `setDeliverState`. +* The [block gas meter](../basics/gas-fees.md#block-gas-meter), with infinite gas to process genesis transactions. -Finally, the `InitChain(req abci.RequestInitChain)` method of `BaseApp` calls the [`initChainer()`](../high-level-concepts/00-overview-app.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`](../../integrate/building-modules/08-genesis.md#initgenesis) function of each of the application's modules. +Finally, the `InitChain(req abci.RequestInitChain)` method of `BaseApp` calls the [`initChainer()`](../basics/app-anatomy.md#initchainer) of the application in order to initialize the main state of the application from the `genesis file` and, if defined, call the [`InitGenesis`](../building-modules/genesis.md#initgenesis) function of each of the application's modules. ### BeginBlock -The [`BeginBlock` ABCI message](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_basic_concepts.md#method-overview) is sent from the underlying CometBFT 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: +The [`BeginBlock` ABCI message](https://docs.tendermint.com/master/spec/abci/abci.html#beginblock) is sent from the underlying Tendermint engine when a block proposal created by the correct proposer is received, before [`DeliverTx`](#delivertx) is run for each transaction in the block. It allows developers to have logic be executed at the beginning of each block. In the Cosmos SDK, the `BeginBlock(req abci.RequestBeginBlock)` method does the following: -* Initialize [`deliverState`](#state-updates) with the latest header using the `req abci.RequestBeginBlock` passed as parameter via the `setState` function. - - ```go reference - https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/baseapp/baseapp.go#L406-L433 - ``` - - This function also resets the [main gas meter](../high-level-concepts/04-gas-fees.md#main-gas-meter). - -* Initialize the [block gas meter](../high-level-concepts/04-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()`](../high-level-concepts/00-overview-app.md#beginblocker-and-endblock), which mainly runs the [`BeginBlocker()`](../../integrate/building-modules/05-beginblock-endblock.md#beginblock) method of each of the application's modules. -* Set the [`VoteInfos`](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_methods.md#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`](02-context.md) so that it can be used during `DeliverTx` and `EndBlock`. +* Initialize [`deliverState`](#state-updates) with the latest header using the `req abci.RequestBeginBlock` passed as parameter via the `setDeliverState` function. + +++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/baseapp/baseapp.go#L386-L396 + 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://docs.tendermint.com/master/spec/abci/abci.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`](./03-context.md) so that it can be used during `DeliverTx` and `EndBlock`. ### EndBlock -The [`EndBlock` ABCI message](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_basic_concepts.md#method-overview) is sent from the underlying CometBFT 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()`](../high-level-concepts/00-overview-app.md#beginblocker-and-endblock), which mainly runs the [`EndBlocker()`](../../integrate/building-modules/05-beginblock-endblock.md#beginblock) method of each of the application's modules. +The [`EndBlock` ABCI message](https://docs.tendermint.com/master/spec/abci/abci.html#endblock) is sent from the underlying Tendermint engine after [`DeliverTx`](#delivertx) as been run for each transaction in the block. It allows developers to have logic be executed at the end of each block. In the Cosmos SDK, the bulk `EndBlock(req abci.RequestEndBlock)` method is to run the application's [`EndBlocker()`](../basics/app-anatomy.md#beginblocker-and-endblock), which mainly runs the [`EndBlocker()`](../building-modules/beginblock-endblock.md#beginblock) method of each of the application's modules. ### Commit -The [`Commit` ABCI message](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_basic_concepts.md#method-overview) is sent from the underlying CometBFT 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 occurred during `BeginBlock`, `DeliverTx` and `EndBlock` and to reset state for the next block. +The [`Commit` ABCI message](https://docs.tendermint.com/master/spec/abci/abci.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 occurred during `BeginBlock`, `DeliverTx` and `EndBlock` and to reset state for the next block. To commit state-transitions, the `Commit` function calls the `Write()` function on `deliverState.ms`, where `deliverState.ms` is a branched multistore of the main store `app.cms`. Then, the `Commit` function sets `checkState` to the latest header (obtained from `deliverState.ctx.BlockHeader`) and `deliverState` to `nil`. @@ -421,14 +388,19 @@ Finally, `Commit` returns the hash of the commitment of `app.cms` back to the un ### Info -The [`Info` ABCI message](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_basic_concepts.md#info-methods) 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`. +The [`Info` ABCI message](https://docs.tendermint.com/master/spec/abci/abci.html#info) is a simple query from the underlying consensus engine, notably used to sync the latter with the application during a handshake that happens on startup. When called, the `Info(res abci.ResponseInfo)` function from `BaseApp` will return the application's name, version and the hash of the last commit of `app.cms`. ### Query -The [`Query` ABCI message](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_basic_concepts.md#info-methods) is used to serve queries received from the underlying consensus engine, including queries received via RPC like CometBFT RPC. It used to be the main entrypoint to build interfaces with the application, but with the introduction of [gRPC queries](../../integrate/building-modules/04-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://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_app_requirements.md#query). +The [`Query` ABCI message](https://docs.tendermint.com/master/spec/abci/abci.html#query-2) 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://docs.tendermint.com/master/spec/abci/apps.html#query). -Each CometBFT `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 split string (`split[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: +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 split string (`split[0]`) contains the category of `query` (`app`, `p2p`, `store` or `custom` ). The `BaseApp` implementation of the `Query(req abci.RequestQuery)` method is a simple dispatcher serving these 4 main categories of queries: * Application-related queries like querying the application's version, which are served via the `handleQueryApp` method. * Direct queries to the multistore, which are served by the `handlerQueryStore` method. These direct 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). + +## Next {hide} + +Learn more about [transactions](./01-transactions.md) {hide} diff --git a/versioned_docs/version-0.46/develop/advanced-concepts/01-transactions.md b/versioned_docs/version-0.46/develop/advanced-concepts/01-transactions.md index 06757ad43..aba1e01ca 100644 --- a/versioned_docs/version-0.46/develop/advanced-concepts/01-transactions.md +++ b/versioned_docs/version-0.46/develop/advanced-concepts/01-transactions.md @@ -1,39 +1,31 @@ -# Transactions - -:::note Synopsis -`Transactions` are objects created by end-users to trigger state changes in the application. -::: + -:::note +# Transactions -### Pre-requisite Readings +`Transactions` are objects created by end-users to trigger state changes in the application. {synopsis} -* [Anatomy of a Cosmos SDK Application](../high-level-concepts/00-overview-app.md) +## Pre-requisite Readings -::: +* [Anatomy of a Cosmos SDK Application](../basics/app-anatomy.md) {prereq} ## Transactions -Transactions are comprised of metadata held in [contexts](02-context.md) and [`sdk.Msg`s](../../integrate/building-modules/02-messages-and-queries.md) that trigger state changes within a module through the module's Protobuf [`Msg` service](../../integrate/building-modules/03-msg-services.md). +Transactions are comprised of metadata held in [contexts](./03-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). -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](../high-level-concepts/01-tx-lifecycle.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). ## Type Definition Transaction objects are Cosmos SDK types that implement the `Tx` interface -```go reference -https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/types/tx_msg.go#L42-L50 -``` ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/tx_msg.go#L38-L46 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:** lightweight, [_stateless_](../high-level-concepts/01-tx-lifecycle.md#types-of-checks) checks used by ABCI messages [`CheckTx`](00-baseapp.md#checktx) and [`DeliverTx`](00-baseapp.md#delivertx) to make sure transactions are not invalid. For example, the [`auth`](https://github.com/cosmos/cosmos-sdk/tree/main/x/auth) module's `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. When [`runTx`](00-baseapp.md#runtx) is checking a transaction created from the [`auth`](https://github.com/cosmos/cosmos-sdk/tree/main/x/auth/spec) module, it first runs `ValidateBasic` on each message, then runs the `auth` module AnteHandler which calls `ValidateBasic` for the transaction itself. - - :::note - This function is different from the deprecated `sdk.Msg` [`ValidateBasic`](../high-level-concepts/01-tx-lifecycle.md#ValidateBasic) methods, which was performing basic validity checks on messages only. - ::: +* **ValidateBasic:** lightweight, [_stateless_](../basics/tx-lifecycle.md#types-of-checks) checks used by ABCI messages [`CheckTx`](./00-baseapp.md#checktx) and [`DeliverTx`](./00-baseapp.md#delivertx) to make sure transactions are not invalid. For example, the [`auth`](https://github.com/cosmos/cosmos-sdk/tree/main/x/auth) module's `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 `sdk.Msg` [`ValidateBasic`](../basics/tx-lifecycle.md#ValidateBasic) methods, which perform basic validity checks on messages only. When [`runTx`](./00-baseapp.md#runtx) is checking a transaction created from the [`auth`](https://github.com/cosmos/cosmos-sdk/tree/main/x/auth/spec) module, it first runs `ValidateBasic` on each message, then runs the `auth` module AnteHandler which calls `ValidateBasic` for the transaction itself. As a developer, you should rarely manipulate `Tx` directly, as `Tx` is really an intermediate type used for transaction generation. Instead, developers should prefer the `TxBuilder` interface, which you can learn more about [below](#transaction-generation). @@ -45,15 +37,11 @@ Every message in a transaction must be signed by the addresses specified by its The most used implementation of the `Tx` interface is the Protobuf `Tx` message, which is used in `SIGN_MODE_DIRECT`: -```protobuf reference -https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/tx/v1beta1/tx.proto#L13-L26 -``` ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/tx/v1beta1/tx.proto#L13-L26 -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](../../integrate/architecture/adr-027-deterministic-protobuf-serialization.md)): +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 reference -https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/tx/v1beta1/tx.proto#L48-L65 -``` ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/tx/v1beta1/tx.proto#L48-L65 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. @@ -61,15 +49,11 @@ Once signed by all signers, the `body_bytes`, `auth_info_bytes` and `signatures` The legacy implementation of the `Tx` interface is the `StdTx` struct from `x/auth`: -```go reference -https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/auth/migrations/legacytx/stdtx.go#L83-L93 -``` ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/migrations/legacytx/stdtx.go#L82-L92 The document signed by all signers is `StdSignDoc`: -```go reference -https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/auth/migrations/legacytx/stdsign.go#L38-L52 -``` ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/migrations/legacytx/stdsign.go#L38-L52 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. @@ -82,14 +66,12 @@ The Cosmos SDK also provides a couple of other sign modes for particular use cas `SIGN_MODE_DIRECT_AUX` is a sign mode released in the Cosmos SDK v0.46 which targets transactions with multiple signers. Whereas `SIGN_MODE_DIRECT` expects each signer to sign over both `TxBody` and `AuthInfo` (which includes all other signers' signer infos, i.e. their account sequence, public key and mode info), `SIGN_MODE_DIRECT_AUX` allows N-1 signers to only sign over `TxBody` and _their own_ signer info. Morever, each auxiliary signer (i.e. a signer using `SIGN_MODE_DIRECT_AUX`) doesn't need to sign over the fees: -```protobuf reference -https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/tx/v1beta1/tx.proto#L67-L97 -``` ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/tx/v1beta1/tx.proto#L67-L93 The use case is a multi-signer transaction, where one of the signers is appointed to gather all signatures, broadcast the signature and pay for fees, and the others only care about the transaction body. This generally allows for a better multi-signing UX. If Alice, Bob and Charlie are part of a 3-signer transaction, then Alice and Bob can both use `SIGN_MODE_DIRECT_AUX` to sign over the `TxBody` and their own signer info (no need an additional step to gather other signers' ones, like in `SIGN_MODE_DIRECT`), without specifying a fee in their SignDoc. Charlie can then gather both signatures from Alice and Bob, and create the final transaction by appending a fee. Note that the fee payer of the transaction (in our case Charlie) must sign over the fees, so must use `SIGN_MODE_DIRECT` or `SIGN_MODE_LEGACY_AMINO_JSON`. -A concrete use case is implemented in [transaction tips](15-tips.md): the tipper may use `SIGN_MODE_DIRECT_AUX` to specify a tip in the transaction, without signing over the actual transaction fees. Then, the fee payer appends fees inside the tipper's desired `TxBody`, and as an exchange for paying the fees and broadcasting the transaction, receives the tipper's transaction tips as payment. +A concrete use case is implemented in [transaction tips](./15-tips.md): the tipper may use `SIGN_MODE_DIRECT_AUX` to specify a tip in the transaction, without signing over the actual transaction fees. Then, the fee payer appends fees inside the tipper's desired `TxBody`, and as an exchange for paying the fees and broadcasting the transaction, receives the tipper's transaction tips as payment. #### `SIGN_MODE_TEXTUAL` @@ -107,16 +89,16 @@ 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://docs.cometbft.com/v0.37/spec/abci/) which define interactions between the CometBFT and application layers. +::: tip +Module `sdk.Msg`s are not to be confused with [ABCI Messages](https://docs.tendermint.com/master/spec/abci/abci.html#messages) which define interactions between the Tendermint and application layers. ::: -**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](../../integrate/building-modules/03-msg-services.md), and also implement the corresponding `MsgServer`. +**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`. -Each `sdk.Msg`s is related to exactly one Protobuf [`Msg` service](../../integrate/building-modules/03-msg-services.md) RPC, defined inside each module's `tx.proto` file. A SDK 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. +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. A SDK 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. -To learn more about Protobuf `Msg` services and how to implement `MsgServer`, click [here](../../integrate/building-modules/03-msg-services.md). +To learn more about Protobuf `Msg` services and how to implement `MsgServer`, click [here](../building-modules/msg-services.md). While messages contain the information for state transition logic, a transaction's other metadata and relevant information are stored in the `TxBuilder` and `Context`. @@ -124,9 +106,7 @@ While messages contain the information for state transition logic, a transaction The `TxBuilder` interface contains data closely related with the generation of transactions, which an end-user can freely set to generate the desired transaction: -```go reference -https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/client/tx_config.go#L33-L50 -``` ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/client/tx_config.go#L33-L50 * `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. @@ -137,14 +117,12 @@ https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/client/tx_config.go#L33-L5 As there are currently two sign modes for signing transactions, there are also two implementations of `TxBuilder`: -* [wrapper](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/auth/tx/builder.go#L18-L34) for creating transactions for `SIGN_MODE_DIRECT`, -* [StdTxBuilder](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/auth/migrations/legacytx/stdtx_builder.go#L15-L21) for `SIGN_MODE_LEGACY_AMINO_JSON`. +* [wrapper](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/tx/builder.go#L18-L34) for creating transactions for `SIGN_MODE_DIRECT`, +* [StdTxBuilder](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/migrations/legacytx/stdtx_builder.go#L15-L21) for `SIGN_MODE_LEGACY_AMINO_JSON`. However, the two implementation of `TxBuilder` should be hidden away from end-users, as they should prefer using the overarching `TxConfig` interface: -```go reference -https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/client/tx_config.go#L22-L31 -``` ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/client/tx_config.go#L22-L31 `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. @@ -164,9 +142,9 @@ Once the transaction bytes are generated, there are currently three ways of broa #### CLI -Application developers create entry points to the application by creating a [command-line interface](07-cli.md), [gRPC and/or REST interface](09-grpc_rest.md), typically found in the application's `./cmd` folder. These interfaces allow users to interact with the application through command-line. +Application developers create entry points 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. -For the [command-line interface](../../integrate/building-modules/09-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](../../user/run-node/02-interact-node.md) section. An example transaction made using CLI looks like: +For the [command-line interface](../building-modules/module-interfaces.md#cli), module developers create subcommands to add as children to the application top-level transaction command `TxCmd`. CLI commands actually bundle all the steps of transaction processing into one simple command: creating messages, generating transactions and broadcasting. For concrete examples, see the [Interacting with a Node](../run-node/interact-node.md) section. An example transaction made using CLI looks like: ```bash simd tx send $MY_VALIDATOR_ADDRESS $RECIPIENT 1000stake @@ -174,22 +152,24 @@ simd tx send $MY_VALIDATOR_ADDRESS $RECIPIENT 1000stake #### gRPC -[gRPC](https://grpc.io) is the main component for the Cosmos SDK's RPC layer. Its principal usage is in the context of modules' [`Query` services](../../integrate/building-modules/04-query-services.md). However, the Cosmos SDK also exposes a few other module-agnostic gRPC services, one of them being the `Tx` service: +[gRPC](https://grpc.io) is the main component for the Cosmos SDK's RPC layer. Its principal usage 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: -```go reference -https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/tx/v1beta1/service.proto -``` ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/tx/v1beta1/service.proto The `Tx` service exposes a handful of utility functions, such as simulating a transaction or querying a transaction, and also one method to broadcast transactions. -Examples of broadcasting and simulating a transaction are shown [here](../../user/run-node/03-txs.md#programmatically-with-go). +Examples of broadcasting and simulating a transaction are shown [here](../run-node/txs.md#programmatically-with-go). #### REST Each gRPC method has its corresponding REST endpoint, generated using [gRPC-gateway](https://github.com/grpc-ecosystem/grpc-gateway). Therefore, instead of using gRPC, you can also use HTTP to broadcast the same transaction, on the `POST /cosmos/tx/v1beta1/txs` endpoint. -An example can be seen [here](../../user/run-node/03-txs.md#using-rest) +An example can be seen [here](../run-node/txs.md#using-rest) + +#### Tendermint RPC + +The three methods presented above are actually higher abstractions over the Tendermint RPC `/broadcast_tx_{async,sync,commit}` endpoints, documented [here](https://docs.tendermint.com/master/rpc/#/Tx). This means that you can use the Tendermint RPC endpoints directly to broadcast the transaction, if you wish so. -#### CometBFT RPC +## Next {hide} -The three methods presented above are actually higher abstractions over the CometBFT RPC `/broadcast_tx_{async,sync,commit}` endpoints, documented [here](https://docs.cometbft.com/v0.37/core/rpc). This means that you can use the CometBFT RPC endpoints directly to broadcast the transaction, if you wish so. +Learn about the [context](./03-context.md) {hide} diff --git a/versioned_docs/version-0.46/develop/advanced-concepts/03-context.md b/versioned_docs/version-0.46/develop/advanced-concepts/03-context.md new file mode 100644 index 000000000..75e374e0d --- /dev/null +++ b/versioned_docs/version-0.46/develop/advanced-concepts/03-context.md @@ -0,0 +1,103 @@ + + +# 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 access to a branched storage (a safe branch of the entire state) as well as useful objects and information like `gasMeter`, `block height`, `consensus parameters` and more. {synopsis} + +## Pre-requisites Readings + +* [Anatomy of a Cosmos SDK Application](../basics/app-anatomy.md) {prereq} +* [Lifecycle of a Transaction](../basics/tx-lifecycle.md) {prereq} + +## Context Definition + +The Cosmos SDK `Context` is a custom data structure that contains Go's stdlib [`context`](https://pkg.go.dev/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](./05-store.md#base-layer-kvstores) in the [`multistore`](./05-store.md#multistore) and retrieve transactional context such as the block header and gas meter. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/context.go#L17-L42 + +* **Base Context:** The base type is a Go [Context](https://pkg.go.dev/context), which is explained further in the [Go Context Package](#go-context-package) section below. +* **Multistore:** Every application's `BaseApp` contains a [`CommitMultiStore`](./05-store.md#multistore) which is provided when a `Context` is created. Calling the `KVStore()` and `TransientStore()` methods allows modules to fetch their respective [`KVStore`](./05-store.md#base-layer-kvstores) using their unique `StoreKey`. +* **Header:** The [header](https://docs.tendermint.com/master/spec/core/data_structures.html#header) is a Blockchain type. It carries important information about the state of the blockchain, such as block height and proposer of the current block. +* **Header Hash:** The current block header hash, obtained during `abci.RequestBeginBlock`. +* **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 do not have any understanding of transaction types. Thus, transactions are marshaled into the generic `[]byte` type using some kind of [encoding format](./07-encoding.md) such as [Amino](./07-encoding.md). +* **Logger:** A `logger` from the Tendermint libraries. Learn more about logs [here](https://docs.tendermint.com/master/nodes/logging.html). Modules call this method to create their own unique module-specific logger. +* **VoteInfo:** A list of the ABCI type [`VoteInfo`](https://docs.tendermint.com/master/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://docs.tendermint.com/master/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`](./10-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: +* **Priority:** The transaction priority, only relevant in `CheckTx`. + +```go +ctx.EventManager().EmitEvent(sdk.NewEvent( + sdk.EventTypeMessage, + sdk.NewAttribute(sdk.AttributeKeyModule, types.AttributeValueCategory)), +) +``` + +## Go Context Package + +A basic `Context` is defined in the [Golang Context Package](https://pkg.go.dev/context). A `Context` +is an immutable data structure that carries request-scoped data across APIs and processes. Contexts +are also designed to enable concurrency and to be used in goroutines. + +Contexts are intended to be **immutable**; they should never be edited. Instead, the convention is +to create a child context from its parent using a `With` function. For example: + +```go +childCtx = parentCtx.WithBlockHeader(header) +``` + +The [Golang Context Package](https://pkg.go.dev/context) documentation instructs developers to +explicitly pass a context `ctx` as the first argument of a process. + +## Store branching + +The `Context` contains a `MultiStore`, which allows for branchinig and caching functionality using `CacheMultiStore` +(queries in `CacheMultiStore` are cached to avoid future round trips). +Each `KVStore` is branched in a safe and isolated ephemeral storage. Processes are free to write changes to +the `CacheMultiStore`. If a state-transition sequence is performed without issue, the store branch can +be committed to the underlying store at the end of the sequence or disregard them if something +goes wrong. The pattern of usage for a Context is as follows: + +1. A process receives a Context `ctx` from its parent process, which provides information needed to + perform the process. +2. The `ctx.ms` is a **branched store**, i.e. a branch of the [multistore](./05-store.md#multistore) is made so that the process can make changes to the state as it executes, without changing the original`ctx.ms`. This is useful to protect the underlying multistore in case the changes need to be reverted at some point in the execution. +3. The process may read and write from `ctx` as it is executing. It may call a subprocess and pass + `ctx` to it as needed. +4. When a subprocess returns, it checks if the result is a success or failure. If a failure, nothing + needs to be done - the branch `ctx` is simply discarded. If successful, the changes made to + the `CacheMultiStore` can be committed to the original `ctx.ms` via `Write()`. + +For example, here is a snippet from the [`runTx`](./00-baseapp.md#runtx-antehandler-runmsgs-posthandler) function in [`baseapp`](./00-baseapp.md): + +```go +runMsgCtx, msCache := app.cacheTxContext(ctx, txBytes) +result = app.runMsgs(runMsgCtx, msgs, mode) +result.GasWanted = gasWanted +if mode != runTxModeDeliver { + return result +} +if result.IsOK() { + msCache.Write() +} +``` + +Here is the process: + +1. Prior to calling `runMsgs` on the message(s) in the transaction, it uses `app.cacheTxContext()` + to branch and cache the context and multistore. +2. `runMsgCtx` - the context with branched store, is used in `runMsgs` to return a result. +3. If the process is running in [`checkTxMode`](./00-baseapp.md#checktx), there is no need to write the + changes - the result is returned immediately. +4. If the process is running in [`deliverTxMode`](./00-baseapp.md#delivertx) and the result indicates + a successful run over all the messages, the branched multistore is written back to the original. + +## Next {hide} + +Learn about the [node client](./04-node.md) {hide} diff --git a/versioned_docs/version-0.46/develop/advanced-concepts/04-node.md b/versioned_docs/version-0.46/develop/advanced-concepts/04-node.md new file mode 100644 index 000000000..94b6e9a1a --- /dev/null +++ b/versioned_docs/version-0.46/develop/advanced-concepts/04-node.md @@ -0,0 +1,77 @@ + + +# 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} + +## Pre-requisite Readings + +* [Anatomy of an SDK application](../basics/app-anatomy.md) {prereq} + +## `main` function + +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. + +In general, developers will implement the `main.go` function with the following structure: + +* First, an [`encodingCodec`](./07-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). + +++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/config.go#L14-L29 +* Using [cobra](https://github.com/spf13/cobra), the root command of the full-node client is created. After that, all the custom commands of the application are added using the `AddCommand()` method of `rootCmd`. +* 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`. + +++ https://github.com/tendermint/tendermint/blob/v0.35.4/libs/cli/setup.go#L74-L78 + +See an example of `main` function from the `simapp` application, the Cosmos SDK's application for demo purposes: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/simapp/simd/main.go + +## `start` command + +The `start` command is defined in the `/server` folder of the Cosmos SDK. It is added to the root command of the full-node client in the [`main` function](#main-function) and called by the end-user to start their node: + +```bash +# For an example app named "app", the following command starts the full-node. +appd start + +# Using the Cosmos SDK's own simapp, the following commands start the simapp node. +simd start +``` + +As a reminder, the full-node is composed of three conceptual layers: the networking layer, the consensus layer and the application layer. The first two are generally bundled together in an entity called the consensus engine (Tendermint Core by default), while the third is the state-machine defined with the help of the Cosmos SDK. Currently, the Cosmos SDK uses Tendermint as the default consensus engine, meaning the start command is implemented to boot up a Tendermint node. + +The flow of the `start` command is pretty straightforward. First, it retrieves the `config` from the `context` in order to open the `db` (a [`leveldb`](https://github.com/syndtr/goleveldb) instance by default). This `db` contains the latest known state of the application (empty if the application is started from the first time. + +With the `db`, the `start` command creates a new instance of the application using an `appCreator` function: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/server/start.go#L209-L209 + +Note that an `appCreator` is a function that fulfills the `AppCreator` signature: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/server/types/app.go#L57-L59 + +In practice, the [constructor of the application](../basics/app-anatomy.md#constructor-function) is passed as the `appCreator`. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/simapp/simd/cmd/root.go#L246-L295 + +Then, the instance of `app` is used to instantiate a new Tendermint node: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/server/start.go#L291-L294 + +The Tendermint node can be created with `app` because the latter satisfies the [`abci.Application` interface](https://github.com/tendermint/tendermint/blob/v0.35.4/abci/types/application.go#L7-L32) (given that `app` extends [`baseapp`](./00-baseapp.md)). As part of the `node.New` 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, `node.New` 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`](./00-baseapp.md#initchain) on the application to initialize the state from the genesis file. + +Once the Tendermint node is instantiated and in sync with the application, the node can be started: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/server/start.go#L296-L298 + +Upon starting, the node will bootstrap its RPC and P2P server and start dialing peers. During handshake with its peers, if the node realizes they are ahead, it will query all the blocks sequentially in order to catch up. Then, it will wait for new block proposals and block signatures from validators in order to make progress. + +## Other commands + +To discover how to concretely run a node and interact with it, please refer to our [Running a Node, API and CLI](../run-node/README.md) guide. + +## Next {hide} + +Learn about the [store](./05-store.md) {hide} diff --git a/versioned_docs/version-0.46/develop/advanced-concepts/04-store.md b/versioned_docs/version-0.46/develop/advanced-concepts/05-store.md similarity index 94% rename from versioned_docs/version-0.46/develop/advanced-concepts/04-store.md rename to versioned_docs/version-0.46/develop/advanced-concepts/05-store.md index 291c2551f..f6fe3fa96 100644 --- a/versioned_docs/version-0.46/develop/advanced-concepts/04-store.md +++ b/versioned_docs/version-0.46/develop/advanced-concepts/05-store.md @@ -8,11 +8,11 @@ A store is a data structure that holds the state of the application. {synopsis} ## Pre-requisite Readings -* [Anatomy of a Cosmos SDK application](../high-level-concepts/00-overview-app.md) {prereq} +* [Anatomy of a Cosmos SDK application](../basics/app-anatomy.md) {prereq} ## Introduction to Cosmos SDK Stores -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`](../../integrate/building-modules/06-keeper.md) of the module that declared the store. +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. ```text +-----------------------------------------------------+ @@ -64,7 +64,7 @@ The `GetStoreType` is a simple method that returns the type of store, whereas a +++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/store/types/store.go#L247-L277 -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](./02-context.md) +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](./03-context.md#Store-branching) ### Commit Store @@ -76,7 +76,7 @@ The `Committer` is an interface that defines methods to persist changes to disk: +++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/store/types/store.go#L21-L28 -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](./10-ocap.md) of the Cosmos SDK, only `baseapp` should have the ability to commit stores. For example, this is the reason why the `ctx.KVStore()` method by which modules typically access stores returns a `KVStore` and not a `CommitKVStore`. +The `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](./12-ocap.md) of the Cosmos SDK, only `baseapp` should have the ability to commit stores. For example, this is the reason why the `ctx.KVStore()` method by which modules typically access stores returns a `KVStore` and not a `CommitKVStore`. The Cosmos SDK comes with many types of stores, the most used being [`CommitMultiStore`](#multistore), [`KVStore`](#kvstore) and [`GasKv` store](#gaskv-store). [Other types of stores](#other-stores) include `Transient` and `TraceKV` stores. @@ -116,9 +116,9 @@ Whenever the `rootMulti.Store` needs to be branched, a [`cachemulti.Store`](http A `KVStore` is a simple key-value store used to store and retrieve data. A `CommitKVStore` is a `KVStore` that also implements a `Committer`. By default, stores mounted in `baseapp`'s main `CommitMultiStore` are `CommitKVStore`s. The `KVStore` interface is primarily used to restrict modules from accessing the committer. -Individual `KVStore`s are used by modules to manage a subset of the global state. `KVStores` can be accessed by objects that hold a specific key. This `key` should only be exposed to the [`keeper`](../../integrate/building-modules/06-keeper.md) of the module that defines the store. +Individual `KVStore`s are used by modules to manage a subset of the global state. `KVStores` can be accessed by objects that hold a specific key. This `key` should only be exposed to the [`keeper`](../building-modules/keeper.md) of the module that defines the store. -`CommitKVStore`s are declared by proxy of their respective `key` and mounted on the application's [multistore](#multistore) in the [main application file](../high-level-concepts/00-overview-app.md). In the same file, the `key` is also passed to the module's `keeper` that is responsible for managing the store. +`CommitKVStore`s are declared by proxy of their respective `key` and mounted on the application's [multistore](#multistore) in the [main application file](../basics/app-anatomy.md#core-application-file). In the same file, the `key` is also passed to the module's `keeper` that is responsible for managing the store. +++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/store/types/store.go#L192-L226 @@ -160,7 +160,7 @@ This type of store is useful to persist information that is only relevant per-bl +++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/params/types/subspace.go#L21-L31 -Transient stores are typically accessed via the [`context`](./context.md) via the `TransientStore()` method: +Transient stores are typically accessed via the [`context`](./03-context.md) via the `TransientStore()` method: +++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/context.go#L264-L267 @@ -196,7 +196,7 @@ When methods of the parent `KVStore` are called, `GasKv.Store` automatically con +++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/store/types/gas.go#L219-L228 -By default, all `KVStores` are wrapped in `GasKv.Stores` when retrieved. This is done in the `KVStore()` method of the [`context`](./context.md): +By default, all `KVStores` are wrapped in `GasKv.Stores` when retrieved. This is done in the `KVStore()` method of the [`context`](./03-context.md): +++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/context.go#L259-L262 @@ -238,7 +238,7 @@ The SDK is in the process of transitioning to use the types listed here as the d These types use the new `db` sub-module of Cosmos-SDK (`github.com/cosmos/cosmos-sdk/db`), rather than `tmdb` (`github.com/tendermint/tm-db`). -See [ADR-040](../../integrate/architecture/adr-040-storage-and-smt-state-commitments.md) for the motivations and design specifications of the change. +See [ADR-040](../architecture/adr-040-storage-and-smt-state-commitments.md) for the motivations and design specifications of the change. ## `BasicKVStore` interface @@ -278,4 +278,4 @@ This store can optionally be configured to use a different backend database inst ## Next {hide} -Learn about [encoding](./encoding.md) {hide} +Learn about [encoding](./07-encoding.md) {hide} diff --git a/versioned_docs/version-0.46/develop/advanced-concepts/07-encoding.md b/versioned_docs/version-0.46/develop/advanced-concepts/07-encoding.md new file mode 100644 index 000000000..47a2e34ff --- /dev/null +++ b/versioned_docs/version-0.46/develop/advanced-concepts/07-encoding.md @@ -0,0 +1,292 @@ + + +# 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} + +## Pre-requisite Readings + +* [Anatomy of a Cosmos SDK application](../basics/app-anatomy.md) {prereq} + +## Encoding + +The Cosmos SDK utilizes two binary wire encoding protocols, [Amino](https://github.com/tendermint/go-amino/) which is an object encoding specification and [Protocol Buffers](https://developers.google.com/protocol-buffers), a subset of Proto3 with an extension for +interface support. See the [Proto3 spec](https://developers.google.com/protocol-buffers/docs/proto3) +for more information on Proto3, which Amino is largely compatible with (but not with Proto2). + +Due to Amino having significant performance drawbacks, being reflection-based, and +not having any meaningful cross-language/client support, Protocol Buffers, specifically +[gogoprotobuf](https://github.com/gogo/protobuf/), is being used in place of Amino. +Note, this process of using Protocol Buffers over Amino is still an ongoing process. + +Binary wire encoding of types in the Cosmos SDK can be broken down into two main +categories, client encoding and store encoding. Client encoding mainly revolves +around transaction processing and signing, whereas store encoding revolves around +types used in state-machine transitions and what is ultimately stored in the Merkle +tree. + +For store encoding, protobuf definitions can exist for any type and will typically +have an Amino-based "intermediary" type. Specifically, the protobuf-based type +definition is used for serialization and persistence, whereas the Amino-based type +is used for business logic in the state-machine where they may convert back-n-forth. +Note, the Amino-based types may slowly be phased-out in the future, so developers +should take note to use the protobuf message definitions where possible. + +In the `codec` package, there exists two core interfaces, `BinaryCodec` and `JSONCodec`, +where the former encapsulates the current Amino interface except it operates on +types implementing the latter instead of generic `interface{}` types. + +In addition, there exists two implementations of `Codec`. The first being +`AminoCodec`, where both binary and JSON serialization is handled via Amino. The +second being `ProtoCodec`, where both binary and JSON serialization is handled +via Protobuf. + +This means that modules may use Amino or Protobuf encoding, but the types must +implement `ProtoMarshaler`. If modules wish to avoid implementing this interface +for their types, they may use an Amino codec directly. + +### Amino + +Every module uses an Amino codec to serialize types and interfaces. This codec typically +has types and interfaces registered in that module's domain only (e.g. messages), +but there are exceptions like `x/gov`. Each module exposes a `RegisterLegacyAminoCodec` function +that allows a user to provide a codec and have all the types registered. An application +will call this method for each necessary module. + +Where there is no protobuf-based type definition for a module (see below), Amino +is used to encode and decode raw wire bytes to the concrete type or interface: + +```go +bz := keeper.cdc.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`) + +#### Authz authorizations + +Since the `MsgExec` message type can contain different messages instances, it is important that developers +add the following code inside the `init` method of their module's `codec.go` file: + +```go +import authzcodec "github.com/cosmos/cosmos-sdk/x/authz/codec" + +init() { + // Register all Amino interfaces and concrete types on the authz Amino codec so that this can later be + // used to properly serialize MsgGrant and MsgExec instances + RegisterLegacyAminoCodec(authzcodec.Amino) +} +``` + +This will allow the `x/authz` module to properly serialize and de-serializes `MsgExec` instances using Amino, +which is required when signing this kind of messages using a Ledger. + +### 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). + +### Guidelines for protobuf message definitions + +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: + +* 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` + +### Transaction Encoding + +Another important use of Protobuf is the encoding and decoding of +[transactions](./01-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. + +* The `TxEncoder` object performs the encoding. +* The `TxDecoder` object performs the decoding. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/tx_msg.go#L72-L76 + +A standard implementation of both these objects can be found in the [`auth` module](../../x/auth/spec/README.md): + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/tx/decoder.go + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/tx/encoder.go + +See [ADR-020](../architecture/adr-020-protobuf-transaction-encoding.md) for details of how a transaction is encoded. + +### Interface Encoding and Usage of `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): + +```proto +message Profile { + // account is the account associated to a profile. + cosmos.auth.v1beta1.BaseAccount account = 1; + // bio is a short description of the account. + string bio = 4; +} +``` + +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? + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/types/account.go#L301-L324 + +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: + +```protobuf +message Profile { + // account is the account associated to a profile. + google.protobuf.Any account = 1 [ + (cosmos_proto.accepts_interface) = "AccountI"; // Asserts that this field only accepts Go types implementing `AccountI`. It is purely informational for now. + ]; + // bio is a short description of the account. + string bio = 4; +} +``` + +To add an account inside a profile, we need to "pack" it inside an `Any` first, using `codectypes.NewAnyWithValue`: + +```go +var myAccount AccountI +myAccount = ... // Can be a BaseAccount, a ContinuousVestingAccount or any struct implementing `AccountI` + +// Pack the account into an Any +accAny, err := codectypes.NewAnyWithValue(myAccount) +if err != nil { + return nil, err +} + +// Create a new Profile with the any. +profile := Profile { + Account: accAny, + Bio: "some bio", +} + +// We can then marshal the profile as usual. +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.46.0-rc1/x/auth/keeper/keeper.go#L230-L233). + +The reverse operation of retrieving the concrete Go type from inside an `Any`, called "unpacking", is done with the `GetCachedValue()` on `Any`. + +```go +profileBz := ... // The proto-encoded bytes of a Profile, e.g. retrieved through gRPC. +var myProfile Profile +// Unmarshal the bytes into the myProfile struct. +err := cdc.Unmarshal(profilebz, &myProfile) + +// Let's see the types of the Account field. +fmt.Printf("%T\n", myProfile.Account) // Prints "Any" +fmt.Printf("%T\n", myProfile.Account.GetCachedValue()) // Prints "BaseAccount", "ContinuousVestingAccount" or whatever was initially packed in the Any. + +// Get the address of the accountt. +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: + +```go +func (p *Profile) UnpackInterfaces(unpacker codectypes.AnyUnpacker) error { + if p.Account != nil { + var account AccountI + return unpacker.UnpackAny(p.Account, &account) + } + + return nil +} +``` + +The `UnpackInterfaces` gets called recursively on all structs implementing this method, to allow all `Any`s to have their `GetCachedValue()` correctly populated. + +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). + +#### `Any` Encoding in the Cosmos SDK + +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): + +* 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.46.0-rc1/x/staking/types/staking.pb.go#L306-L339) struct that contains information about a validator. + +A real-life example of encoding the pubkey as `Any` inside the Validator struct in x/staking is shown in the following example: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/staking/types/validator.go#L40-L61 + +## FAQ + +### How to create modules using protobuf encoding + +#### Defining module types + +Protobuf types can be defined to encode: + +* state +* [`Msg`s](../building-modules/messages-and-queries.md#messages) +* [Query services](../building-modules/query-services.md) +* [genesis](../building-modules/genesis.md) + +#### Naming and conventions + +We encourage developers to follow industry guidelines: [Protocol Buffers style guide](https://developers.google.com/protocol-buffers/docs/style) +and [Buf](https://buf.build/docs/style-guide), see more details in [ADR 023](../architecture/adr-023-protobuf-naming.md) + +### How to update modules to protobuf encoding + +If modules do not contain any interfaces (e.g. `Account` or `Content`), then they +may simply migrate any existing types that +are encoded and persisted via their concrete Amino codec to Protobuf (see 1. for further guidelines) and accept a `Marshaler` as the codec which is implemented via the `ProtoCodec` +without any further customization. + +However, if a module type composes an interface, it must wrap it in the `sdk.Any` (from `/types` package) type. To do that, a module-level .proto file must use [`google.protobuf.Any`](https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/any.proto) for respective message type interface types. + +For example, in the `x/evidence` module defines an `Evidence` interface, which is used by the `MsgSubmitEvidence`. The structure definition must use `sdk.Any` to wrap the evidence file. In the proto file we define it as follows: + +```protobuf +// proto/cosmos/evidence/v1beta1/tx.proto + +message MsgSubmitEvidence { + string submitter = 1; + google.protobuf.Any evidence = 2 [(cosmos_proto.accepts_interface) = "Evidence"]; +} +``` + +The Cosmos SDK `codec.Codec` interface provides support methods `MarshalInterface` and `UnmarshalInterface` to easy encoding of state to `Any`. + +Module should register interfaces using `InterfaceRegistry` which provides a mechanism for registering interfaces: `RegisterInterface(protoName string, iface interface{}, impls ...proto.Message)` and implementations: `RegisterImplementations(iface interface{}, impls ...proto.Message)` that can be safely unpacked from Any, similarly to type registration with Amino: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/codec/types/interface_registry.go#L25-L55 + +In addition, an `UnpackInterfaces` phase should be introduced to deserialization to unpack interfaces before they're needed. Protobuf types that contain a protobuf `Any` either directly or via one of their members should implement the `UnpackInterfacesMessage` interface: + +```go +type UnpackInterfacesMessage interface { + UnpackInterfaces(InterfaceUnpacker) error +} +``` + +### Custom Stringer + +Using `option (gogoproto.goproto_stringer) = false;` in a proto message definition leads to unexpected behaviour, like returning wrong output or having missing fields in the output. +For that reason a proto Message's `String()` must not be customized, and the `goproto_stringer` option must be avoided. + +A correct YAML output can be obtained through ProtoJSON, using the `JSONToYAML` function: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/codec/yaml.go#L8-L20 + +For example: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/auth/types/account.go#L139-L151 + +## Next {hide} + +Learn about [gRPC, REST and other endpoints](./08-grpc_rest.md) {hide} diff --git a/versioned_docs/version-0.46/develop/advanced-concepts/08-grpc_rest.md b/versioned_docs/version-0.46/develop/advanced-concepts/08-grpc_rest.md new file mode 100644 index 000000000..3071a0a95 --- /dev/null +++ b/versioned_docs/version-0.46/develop/advanced-concepts/08-grpc_rest.md @@ -0,0 +1,99 @@ + + +# gRPC, REST, and Tendermint Endpoints + +This document presents an overview of all the endpoints a node exposes: gRPC, REST as well as some other endpoints. {synopsis} + +## An Overview of All Endpoints + +Each node exposes the following endpoints for users to interact with a node, each endpoint is served on a different port. Details on how to configure each endpoint is provided in the endpoint's own section. + +* the gRPC server (default port: `9090`), +* the REST server (default port: `1317`), +* the Tendermint RPC endpoint (default port: `26657`). + +::: tip +The node also exposes some other endpoints, such as the Tendermint P2P endpoint, or the [Prometheus endpoint](https://docs.tendermint.com/master/nodes/metrics.html#metrics), which are not directly related to the Cosmos SDK. Please refer to the [Tendermint documentation](https://docs.tendermint.com/master/tendermint-core/using-tendermint.html#configuration) for more information about these endpoints. +::: + +## gRPC Server + +In the Cosmos SDK, Protobuf is the main [encoding](./07-encoding) library. 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. + +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: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/server/types/app.go#L45-L47 + +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 programmatically before they can be broadcasted using gRPC. See [Generating, Signing, and Broadcasting Transactions](../run-node/txs.html) for more information. + +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.enable = true|false` field defines if the gRPC server should be enabled. Defaults to `true`. +* `grpc.address = {string}` field defines the address (really, the port, since the host should be kept at `0.0.0.0`) the server should bind to. Defaults to `0.0.0.0:9090`. + +:::tip +`~/.simapp` is the directory where the node's configuration and databases are stored. By default, it's set to `~/.{app_name}`. +::: + +Once the gRPC server is started, you can send requests to it using a gRPC client. Some examples are given in our [Interact with the Node](../run-node/interact-node.md#using-grpc) tutorial. + +An overview of all available gRPC endpoints shipped with the Cosmos SDK is [Protobuf documentation](https://buf.build/cosmos/cosmos-sdk). + +## REST Server + +Cosmos SDK supports REST routes via gRPC-gateway. + +All routes are configured under the following fields in `~/.simapp/config/app.toml`: + +* `api.enable = true|false` field defines if the REST server should be enabled. Defaults to `false`. +* `api.address = {string}` field defines the address (really, the port, since the host should be kept at `0.0.0.0`) the server should bind to. Defaults to `tcp://0.0.0.0:1317`. +* some additional API configuration options are defined in `~/.simapp/config/app.toml`, along with comments, please refer to that file directly. + +### gRPC-gateway REST Routes + +If, for various reasons, you cannot use gRPC (for example, you are building a web application, and browsers don't support HTTP2 on which gRPC is built), then the Cosmos SDK offers REST routes via gRPC-gateway. + +[gRPC-gateway](https://grpc-ecosystem.github.io/grpc-gateway/) is a tool to expose gRPC endpoints as REST endpoints. For each 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: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/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. + +### Swagger + +A [Swagger](https://swagger.io/) (or OpenAPIv2) specification file is exposed under the `/swagger` route on the API server. Swagger is an open specification describing the API endpoints a server serves, including description, input arguments, return types and much more about each endpoint. + +Enabling the `/swagger` endpoint is configurable inside `~/.simapp/config/app.toml` via the `api.swagger` field, which is set to true by default. + +For application developers, you may want to generate your own Swagger definitions based on your custom modules. +The Cosmos SDK's [Swagger generation script](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/scripts/protoc-swagger-gen.sh) is a good place to start. + +## Tendermint RPC + +Independently from the Cosmos SDK, Tendermint also exposes a RPC server. This RPC server can be configured by tuning parameters under the `rpc` table in the `~/.simapp/config/config.toml`, the default listening address is `tcp://0.0.0.0:26657`. An OpenAPI specification of all Tendermint RPC endpoints is available [here](https://docs.tendermint.com/master/rpc/). + +Some Tendermint RPC endpoints are directly related to the Cosmos SDK: + +* `/abci_query`: this endpoint will query the application for state. As the `path` parameter, you can send the following strings: + * any Protobuf fully-qualified service method, such as `/cosmos.bank.v1beta1.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](./01-transactions.md#broadcasting-the-transaction), but they all use these 3 Tendermint RPCs under the hood. + +## Comparison Table + +| Name | Advantages | Disadvantages | +| -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | +| gRPC | - can use code-generated stubs in various languages
- supports streaming and bidirectional communication (HTTP2)
- small wire binary sizes, faster transmission | - based on HTTP2, not available in browsers
- learning curve (mostly due to Protobuf) | +| REST | - ubiquitous
- client libraries in all languages, faster implementation
| - only supports unary request-response communication (HTTP1.1)
- bigger over-the-wire message sizes (JSON) | +| CometBFT RPC | - easy to use | - bigger over-the-wire message sizes (JSON) | + + +## Next {hide} + +Learn about [the CLI](./09-cli.md) {hide} diff --git a/versioned_docs/version-0.46/develop/advanced-concepts/09-cli.md b/versioned_docs/version-0.46/develop/advanced-concepts/09-cli.md new file mode 100644 index 000000000..6895a486a --- /dev/null +++ b/versioned_docs/version-0.46/develop/advanced-concepts/09-cli.md @@ -0,0 +1,156 @@ + + +# Command-Line Interface + +This document describes how command-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} + +## 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. + +Here is an example of a command a user might enter to interact with the simapp CLI `simd` in order to send some tokens: + +```bash +simd tx bank send $MY_VALIDATOR_ADDRESS $RECIPIENT 1000stake --gas auto --gas-prices +``` + +The first four strings specify the command: + +* The root command for the entire application `simd`. +* The subcommand `tx`, which contains all commands that let users create transactions. +* The subcommand `bank` to indicate which module to route the command to ([`x/bank`](../../x/bank/spec/README.md) module in this case). +* The type of transaction `send`. + +The next two strings are arguments: the `from_address` the user wishes to send from, the `to_address` of the recipient, and the `amount` they want to send. Finally, the last few strings of the command are optional flags to indicate how much the user is willing to pay in fees (calculated using the amount of gas used to execute the transaction and the gas prices provided by the user). + +The CLI interacts with a [node](../core/node.md) to handle this command. The interface itself is defined in a `main.go` file. + +### Building the CLI + +The `main.go` file needs to have a `main()` function that creates a root command, to which all the application commands will be added as subcommands. The root command additionally handles: + +* **setting configurations** by reading in configuration files (e.g. the 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). + +The `main()` function finally creates an executor and [execute](https://pkg.go.dev/github.com/spf13/cobra#Command.Execute) the root command. See an example of `main()` function from the `simapp` application: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/simapp/simd/main.go#L12-L24 + +The rest of the document will detail what needs to be implemented for each step and include smaller portions of code from the `simapp` CLI files. + +## Adding Commands to the CLI + +Every application CLI first constructs a root command, then adds functionality by aggregating subcommands (often with further nested subcommands) using `rootCmd.AddCommand()`. The bulk of an application's unique capabilities lies in its transaction and query commands, called `TxCmd` and `QueryCmd` respectively. + +### Root Command + +The root command (called `rootCmd`) is what the user first types into the command line to indicate which application they wish to interact with. The string used to invoke the command (the "Use" field) is typically the name of the application suffixed with `-d`, e.g. `simd` or `gaiad`. The root command typically includes the following commands to support basic functionality in the application. + +* **Status** command from the 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.46.0-rc1/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.46.0-rc1/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.46.0-rc1/server) to learn more. +* [**Transaction**](#transaction-commands) commands. +* [**Query**](#query-commands) commands. + +Next is an example `rootCmd` function from the `simapp` application. It instantiates the root command, adds a [_persistent_ flag](#flags) and `PreRun` function to be run before every execution, and adds all of the necessary subcommands. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/simapp/simd/cmd/root.go#L39-L85 + +`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. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/simapp/simd/cmd/root.go#L99-L153 + +The `initAppConfig()` also allows overriding the default Cosmos SDK's [server config](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/server/config/config.go#L235). 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. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/simapp/simd/cmd/root.go#L119-L134 + +The root-level `status` and `keys` subcommands are common across most applications and do not interact with application state. The bulk of an application's functionality - what users can actually _do_ with it - is enabled by its `tx` and `query` commands. + +### Transaction Commands + +[Transactions](./01-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 `txCommand` is generally added to the `rootCmd`: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/simapp/simd/cmd/root.go#L175-L181 + +This `txCommand` function adds all the transaction available to end-users for the application. This typically includes: + +* **Sign command** from the [`auth`](../../x/auth/spec/README.md) module that signs messages in a transaction. To enable multisig, add the `auth` module's `MultiSign` command. Since every transaction requires some sort of signature in order to be valid, 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. + +Here is an example of a `txCommand` aggregating these subcommands from the `simapp` application: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/simapp/simd/cmd/root.go#L215-L240 + +### 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 queries using the CLI interface, a function `queryCommand` is generally added to the `rootCmd`: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/simapp/simd/cmd/root.go#L175-L181 + +This `queryCommand` function adds all the queries available to end-users for the application. This typically includes: + +* **QueryTx** and/or other transaction query commands] from the `auth` module which allow the user to search for a transaction by inputting its hash, a list of tags, or a block height. These queries allow users to see if transactions have been included in a block. +* **Account command** from the `auth` module, which displays the state (e.g. account balance) of an account given an address. +* **Validator command** from the 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. + +Here is an example of a `queryCommand` aggregating subcommands from the `simapp` application: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/simapp/simd/cmd/root.go#L191-L213 + +## Flags + +Flags are used to modify commands; developers can include them in a `flags.go` file with their CLI. Users can explicitly include them in commands or pre-configure them by inside their [`app.toml`](../run-node/run-node.md#configuring-the-node-using-apptoml). Commonly pre-configured flags include the `--node` to connect to and `--chain-id` of the blockchain the user wishes to interact with. + +A _persistent_ flag (as opposed to a _local_ flag) added to a command transcends all of its children: subcommands will inherit the configured values for these flags. Additionally, all flags have default values when they are added to commands; some toggle an option off but others are empty values that the user needs to override to create valid commands. A flag can be explicitly marked as _required_ so that an error is automatically thrown if the user does not provide a value, but it is also acceptable to handle unexpected missing flags differently. + +Flags are added to commands directly (generally in the [module's CLI file](../building-modules/module-interfaces.md#flags) where module commands are defined) and no flag except for the `rootCmd` persistent flags has to be added at application level. It is common to add a _persistent_ flag for `--chain-id`, the unique identifier of the blockchain the application pertains to, to the root command. Adding this flag can be done in the `main()` function. Adding this flag makes sense as the chain ID should not be changing across commands in this application CLI. Here is an example from the `simapp` application: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/simapp/simd/cmd/root.go#L210-L210 + +## 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 reducing the amount of flags typed for routine operations. For example instead of: + +```sh +gaia --home=./ --node= --chain-id="testchain-1" --keyring-backend=test tx ... --from= +``` + +this will be more convenient: + +```sh +# define env variables in .env, .envrc etc +GAIA_HOME= +GAIA_NODE= +GAIA_CHAIN_ID="testchain-1" +GAIA_KEYRING_BACKEND="test" + +# and later just use +gaia tx ... --from= +``` + +## Configurations + +It is vital that the root command of an application uses `PersistentPreRun()` cobra command property for executing the command, so all child commands have access to the server and client contexts. These contexts are set as their default values initially and maybe modified, scoped to the command, in their respective `PersistentPreRun()` functions. Note that the `client.Context` is typically pre-populated with "default" values that may be useful for all commands to inherit and override if necessary. + +Here is an example of an `PersistentPreRun()` function from `simapp`: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/simapp/simd/cmd/root.go#L56-L79 + +The `SetCmdClientContextHandler` call reads persistent flags via `ReadPersistentCommandFlags` which creates a `client.Context` and sets that on the root command's `Context`. + +The `InterceptConfigsPreRunHandler` call creates a viper literal, default `server.Context`, and a logger and sets that on the root command's `Context`. The `server.Context` will be modified and saved to disk via the internal `interceptConfigs` call, which either reads or creates a Tendermint configuration based on the home path provided. In addition, `interceptConfigs` also reads and loads the application configuration, `app.toml`, and binds that to the `server.Context` viper literal. This is vital so the application can get access to not only the CLI flags, but also to the application configuration values provided by this file. + +## Next {hide} + +Learn about [events](./10-events.md) {hide} diff --git a/versioned_docs/version-0.46/develop/advanced-concepts/10-events.md b/versioned_docs/version-0.46/develop/advanced-concepts/10-events.md new file mode 100644 index 000000000..d11592577 --- /dev/null +++ b/versioned_docs/version-0.46/develop/advanced-concepts/10-events.md @@ -0,0 +1,139 @@ + + +# Events + +`Event`s are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallet to track the execution of various messages and index transactions. {synopsis} + +## Pre-requisite Readings + +* [Anatomy of a Cosmos SDK application](../basics/app-anatomy.md) {prereq} +* [Tendermint Documentation on Events](https://docs.tendermint.com/master/spec/abci/abci.html#events) {prereq} + +## Typed Events + +Events are implemented in the Cosmos SDK as an alias of the ABCI `Event` type and +take the form of: `{eventType}.{attributeKey}={attributeValue}`. + ++++ https://github.com/tendermint/tendermint/blob/v0.35.4/proto/tendermint/abci/types.proto#L273-L279 + +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}`. + +::: tip +To parse the attribute values as strings, make sure to add `'` (single quotes) around each attribute value. +::: + +_Typed Events_ are Protobuf-defined [messages](../architecture/adr-032-typed-events.md) used by the Cosmos SDK +for emitting and querying Events. They are defined in a `event.proto` file, on a **per-module basis**. +They are triggered from the module's Protobuf [`Msg` service](../building-modules/msg-services.md) +by using the [`EventManager`](#eventmanager), where they are read as `proto.Message`. + +In addition, each module documents its Events under `spec/xx_events.md`. + +Lastly, Events are returned to the underlying consensus engine in the response of the following ABCI messages: + +* [`BeginBlock`](./00-baseapp.md#beginblock) +* [`EndBlock`](./00-baseapp.md#endblock) +* [`CheckTx`](./00-baseapp.md#checktx) +* [`DeliverTx`](./00-baseapp.md#delivertx) + +### Examples + +The following examples show how to query Events using the Cosmos SDK. + +| Event | Description | +| ------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `tx.height=23` | Query all transactions at height 23 | +| `message.action='/cosmos.bank.v1beta1.Msg/Send'` | Query all transactions containing a x/bank `Send` [Service `Msg`](../building-modules/msg-services.md). Note the `'`s around the value. | +| `message.action='send'` | Query all transactions containing a x/bank `Send` [legacy `Msg`](../building-modules/msg-services.md#legacy-amino-msgs). Note the `'`s around the value. | +| `message.module='bank'` | Query all transactions containing messages from the x/bank module. Note the `'`s around the value. | +| `create_validator.validator='cosmosval1...'` | x/staking-specific Event, see [x/staking SPEC](../../../cosmos-sdk/x/staking/spec/07_events.md). | + +## EventManager + +In Cosmos SDK applications, Events are managed by an abstraction called the `EventManager`. +Internally, the `EventManager` tracks a list of Events for the entire execution flow of a +transaction or `BeginBlock`/`EndBlock`. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/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 `EmitTypedEvent` that tracks +an Event in the `EventManager`. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/events.go#L50-L59 + +Module developers should handle Event emission via the `EventManager#EmitTypedEvent` in each message +`Handler` and in each `BeginBlock`/`EndBlock` handler. The `EventManager` is accessed via +the [`Context`](./03-context.md), where Event should be already registered, and emitted like this: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/group/keeper/msg_server.go#L89-L92 + +Module's `handler` function should also set a new `EventManager` to the `context` to isolate emitted Events per `message`: + +```go +func NewHandler(keeper Keeper) sdk.Handler { + return func(ctx sdk.Context, msg sdk.Msg) (*sdk.Result, error) { + ctx = ctx.WithEventManager(sdk.NewEventManager()) + switch msg := msg.(type) { +``` + +See the [`Msg` services](../building-modules/msg-services.md) concept doc for a more detailed +view on how to typically implement Events and use the `EventManager` in modules. + +## Subscribing to Events + +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: + +```json +{ + "jsonrpc": "2.0", + "method": "subscribe", + "id": "0", + "params": { + "query": "tm.event='eventCategory' AND eventType.eventAttribute='attributeValue'" + } +} +``` + +The main `eventCategory` you can subscribe to are: + +* `NewBlock`: Contains Events triggered during `BeginBlock` and `EndBlock`. +* `Tx`: Contains Events triggered during `DeliverTx` (i.e. transaction processing). +* `ValidatorSetUpdates`: Contains validator set updates for the block. + +These Events are triggered from the `state` package after a block is committed. You can get the +full list of Event categories [on the Tendermint Go documentation](https://pkg.go.dev/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 `Mint` transaction triggers an Event of type `EventMint` and has an `Id` and an `Owner` as `attributes` (as defined in the [`events.proto` file of the `NFT` module](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/nft/v1beta1/event.proto#L14-L19)). + +Subscribing to this Event would be done like so: + +```json +{ + "jsonrpc": "2.0", + "method": "subscribe", + "id": "0", + "params": { + "query": "tm.event='Tx' AND mint.owner='ownerAddress'" + } +} +``` + +where `ownerAddress` is an address following the [`AccAddress`](../basics/accounts.md#addresses) format. + +## Events (Deprecated) + +Previously, the Cosmos SDK supported emitting Events that were defined in `types/events.go`. 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, + +This is why this methods as been deprecated, and replaced by _[Typed Events](#typed-events). + +To learn more about the previous way of defining events, please refer to the [previous SDK documentation](https://docs.cosmos.network/v0.45/core/events.html#events-2). + +## Next {hide} + +Learn about Cosmos SDK [telemetry](./11-telemetry.md) {hide} diff --git a/versioned_docs/version-0.46/develop/advanced-concepts/11-telemetry.md b/versioned_docs/version-0.46/develop/advanced-concepts/11-telemetry.md new file mode 100644 index 000000000..0152349ec --- /dev/null +++ b/versioned_docs/version-0.46/develop/advanced-concepts/11-telemetry.md @@ -0,0 +1,130 @@ + + +# 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. To enable telemetrics, set `telemetry.enabled = true` in the app.toml config file. + +The Cosmos SDK currently supports enabling in-memory and prometheus as telemetry sinks. In-memory sink is always attached (when the telemetry is enabled) with 10 second interval and 1 minute retention. This means that metrics will be aggregated over 10 seconds, and metrics will be kept alive for 1 minute. + +To query active metrics (see retention note above) you have to enable API server (`api.enabled = true` in the app.toml). Single API endpoint is exposed: `http://localhost:1317/metrics?format={text|prometheus}`, the default being `text`. + +## Emitting metrics + +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](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/telemetry/wrapper.go). Example: + +```go +func EndBlocker(ctx sdk.Context, k keeper.Keeper) { + defer telemetry.ModuleMeasureSince(types.ModuleName, time.Now(), telemetry.MetricKeyEndBlocker) + + // ... +} +``` + +Developers may use the `telemetry` package directly, which provides wrappers around metric APIs +that include adding useful labels, or they must use the `go-metrics` library directly. It is preferable +to add as much context and adequate dimensionality to metrics as possible, so the `telemetry` package +is advised. Regardless of the package or method used, the Cosmos SDK supports the following metrics +types: + +* gauges +* summaries +* counters + +## Labels + +Certain components of modules will have their name automatically added as a label (e.g. `BeginBlock`). +Operators may also supply the application with a global set of labels that will be applied to all +metrics emitted using the `telemetry` package (e.g. chain-id). Global labels are supplied as a list +of [name, value] tuples. + +Example: + +```toml +global-labels = [ + ["chain_id", "chain-OfXo4V"], +] +``` + +## Cardinality + +Cardinality is key, specifically label and key cardinality. Cardinality is how many unique values of +something there are. So there is naturally a tradeoff between granularity and how much stress is put +on the telemetry sink in terms of indexing, scrape, and query performance. + +Developers should take care to support metrics with enough dimensionality and granularity to be +useful, but not increase the cardinality beyond the sink's limits. A general rule of thumb is to not +exceed a cardinality of 10. + +Consider the following examples with enough granularity and adequate cardinality: + +* begin/end blocker time +* tx gas used +* block gas used +* amount of tokens minted +* amount of accounts created + +The following examples expose too much cardinality and may not even prove to be useful: + +* transfers between accounts with amount +* voting/deposit amount from unique addresses + +## Supported Metrics + +| Metric | Description | Unit | Type | +|:--------------------------------|:------------------------------------------------------------------------------------------|:----------------|:--------| +| `tx_count` | Total number of txs processed via `DeliverTx` | tx | counter | +| `tx_successful` | Total number of successful txs processed via `DeliverTx` | tx | counter | +| `tx_failed` | Total number of failed txs processed via `DeliverTx` | tx | counter | +| `tx_gas_used` | The total amount of gas used by a tx | gas | gauge | +| `tx_gas_wanted` | The total amount of gas requested by a tx | gas | gauge | +| `tx_msg_send` | The total amount of tokens sent in a `MsgSend` (per denom) | token | gauge | +| `tx_msg_withdraw_reward` | The total amount of tokens withdrawn in a `MsgWithdrawDelegatorReward` (per denom) | token | gauge | +| `tx_msg_withdraw_commission` | The total amount of tokens withdrawn in a `MsgWithdrawValidatorCommission` (per denom) | token | gauge | +| `tx_msg_delegate` | The total amount of tokens delegated in a `MsgDelegate` | token | gauge | +| `tx_msg_begin_unbonding` | The total amount of tokens undelegated in a `MsgUndelegate` | token | gauge | +| `tx_msg_begin_begin_redelegate` | The total amount of tokens redelegated in a `MsgBeginRedelegate` | token | gauge | +| `tx_msg_ibc_transfer` | The total amount of tokens transferred via IBC in a `MsgTransfer` (source or sink chain) | token | gauge | +| `ibc_transfer_packet_receive` | The total amount of tokens received in a `FungibleTokenPacketData` (source or sink chain) | token | gauge | +| `new_account` | Total number of new accounts created | account | counter | +| `gov_proposal` | Total number of governance proposals | proposal | counter | +| `gov_vote` | Total number of governance votes for a proposal | vote | counter | +| `gov_deposit` | Total number of governance deposits for a proposal | deposit | counter | +| `staking_delegate` | Total number of delegations | delegation | counter | +| `staking_undelegate` | Total number of undelegations | undelegation | counter | +| `staking_redelegate` | Total number of redelegations | redelegation | counter | +| `ibc_transfer_send` | Total number of IBC transfers sent from a chain (source or sink) | transfer | counter | +| `ibc_transfer_receive` | Total number of IBC transfers received to a chain (source or sink) | transfer | counter | +| `ibc_client_create` | Total number of clients created | create | counter | +| `ibc_client_update` | Total number of client updates | update | counter | +| `ibc_client_upgrade` | Total number of client upgrades | upgrade | counter | +| `ibc_client_misbehaviour` | Total number of client misbehaviours | misbehaviour | counter | +| `ibc_connection_open-init` | Total number of connection `OpenInit` handshakes | handshake | counter | +| `ibc_connection_open-try` | Total number of connection `OpenTry` handshakes | handshake | counter | +| `ibc_connection_open-ack` | Total number of connection `OpenAck` handshakes | handshake | counter | +| `ibc_connection_open-confirm` | Total number of connection `OpenConfirm` handshakes | handshake | counter | +| `ibc_channel_open-init` | Total number of channel `OpenInit` handshakes | handshake | counter | +| `ibc_channel_open-try` | Total number of channel `OpenTry` handshakes | handshake | counter | +| `ibc_channel_open-ack` | Total number of channel `OpenAck` handshakes | handshake | counter | +| `ibc_channel_open-confirm` | Total number of channel `OpenConfirm` handshakes | handshake | counter | +| `ibc_channel_close-init` | Total number of channel `CloseInit` handshakes | handshake | counter | +| `ibc_channel_close-confirm` | Total number of channel `CloseConfirm` handshakes | handshake | counter | +| `tx_msg_ibc_recv_packet` | Total number of IBC packets received | packet | counter | +| `tx_msg_ibc_acknowledge_packet` | Total number of IBC packets acknowledged | acknowledgement | counter | +| `ibc_timeout_packet` | Total number of IBC timeout packets | timeout | counter | +| `store_iavl_get` | Duration of an IAVL `Store#Get` call | ms | summary | +| `store_iavl_set` | Duration of an IAVL `Store#Set` call | ms | summary | +| `store_iavl_has` | Duration of an IAVL `Store#Has` call | ms | summary | +| `store_iavl_delete` | Duration of an IAVL `Store#Delete` call | ms | summary | +| `store_iavl_commit` | Duration of an IAVL `Store#Commit` call | ms | summary | +| `store_iavl_query` | Duration of an IAVL `Store#Query` call | ms | summary | + +## Next {hide} + +Learn about the [object-capability](./12-ocap.md) model {hide} diff --git a/versioned_docs/version-0.46/develop/advanced-concepts/12-ocap.md b/versioned_docs/version-0.46/develop/advanced-concepts/12-ocap.md new file mode 100644 index 000000000..f9a84457b --- /dev/null +++ b/versioned_docs/version-0.46/develop/advanced-concepts/12-ocap.md @@ -0,0 +1,78 @@ + + +# Object-Capability Model + +## Intro + +When thinking about security, it is good to start with a specific threat model. Our threat model is the following: + +> We assume that a thriving ecosystem of Cosmos SDK modules that are easy to compose into a blockchain application will contain faulty or malicious modules. + +The Cosmos SDK is designed to address this threat by being the +foundation of an object capability system. + +> The structural properties of object capability systems favor +> modularity in code design and ensure reliable encapsulation in +> code implementation. +> +> These structural properties facilitate the analysis of some +> security properties of an object-capability program or operating +> system. Some of these — in particular, information flow properties +> — can be analyzed at the level of object references and +> connectivity, independent of any knowledge or analysis of the code +> that determines the behavior of the objects. +> +> As a consequence, these security properties can be established +> and maintained in the presence of new objects that contain unknown +> and possibly malicious code. +> +> These structural properties stem from the two rules governing +> access to existing objects: +> +> 1. An object A can send a message to B only if object A holds a +> reference to B. +> 2. An object A can obtain a reference to C only +> if object A receives a message containing a reference to C. As a +> consequence of these two rules, an object can obtain a reference +> to another object only through a preexisting chain of references. +> In short, "Only connectivity begets connectivity." + +For an introduction to object-capabilities, see this [Wikipedia article](https://en.wikipedia.org/wiki/Object-capability_model). + +## Ocaps in practice + +The idea is to only reveal what is necessary to get the work done. + +For example, the following code snippet violates the object capabilities +principle: + +```go +type AppAccount struct {...} +account := &AppAccount{ + Address: pub.Address(), + Coins: sdk.Coins{sdk.NewInt64Coin("ATM", 100)}, +} +sumValue := externalModule.ComputeSumValue(account) +``` + +The method `ComputeSumValue` implies a pure function, yet the implied +capability of accepting a pointer value is the capability to modify that +value. The preferred method signature should take a copy instead. + +```go +sumValue := externalModule.ComputeSumValue(*account) +``` + +In the Cosmos SDK, you can see the application of this principle in simapp. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/simapp/app.go#L258-L283 + +The following diagram shows the current dependencies between keepers. + +![Keeper dependencies](./keeper_dependencies.svg) + +## Next {hide} + +Learn about the [`runTx` middleware](./13-runtx_middleware.md) {hide} diff --git a/versioned_docs/version-0.46/develop/advanced-concepts/13-runtx_middleware.md b/versioned_docs/version-0.46/develop/advanced-concepts/13-runtx_middleware.md new file mode 100644 index 000000000..8b39f127e --- /dev/null +++ b/versioned_docs/version-0.46/develop/advanced-concepts/13-runtx_middleware.md @@ -0,0 +1,69 @@ + + +# RunTx recovery middleware + +`BaseApp.runTx()` function handles Go 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. + +More context can found in the corresponding [ADR-022](../architecture/adr-022-custom-panic-handling.md) and the implementation in [recovery.go](https://github.com/cosmos/cosmos-sdk/tree/v0.46.0-rc1/baseapp/recovery.go). + +## Interface + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/baseapp/recovery.go#L11-L14 + +`recoveryObj` is a return value for `recover()` function from the `buildin` Go package. + +**Contract:** + +* RecoveryHandler returns `nil` if `recoveryObj` wasn't handled and should be passed to the next recovery middleware; +* RecoveryHandler returns a non-nil `error` if `recoveryObj` was handled; + +## Custom RecoveryHandler register + +`BaseApp.AddRunTxRecoveryHandler(handlers ...RecoveryHandler)` + +BaseApp method adds recovery middleware to the default recovery chain. + +## Example + +Lets assume we want to emit the "Consensus failure" chain state if some particular error occurred. + +We have a module keeper that panics: + +```go +func (k FooKeeper) Do(obj interface{}) { + if obj == nil { + // that shouldn't happen, we need to crash the app + err := sdkErrors.Wrap(fooTypes.InternalError, "obj is nil") + panic(err) + } +} +``` + +By default that panic would be recovered and an error message will be printed to log. To override that behaviour we should register a custom RecoveryHandler: + +```go +// Cosmos SDK application constructor +customHandler := func(recoveryObj interface{}) error { + err, ok := recoveryObj.(error) + if !ok { + return nil + } + + if fooTypes.InternalError.Is(err) { + panic(fmt.Errorf("FooKeeper did panic with error: %w", err)) + } + + return nil +} + +baseApp := baseapp.NewBaseApp(...) +baseApp.AddRunTxRecoveryHandler(customHandler) +``` + +## Next {hide} + +Learn about the [IBC](./../ibc/README.md) protocol {hide} diff --git a/versioned_docs/version-0.46/develop/advanced-concepts/13-simulation.md b/versioned_docs/version-0.46/develop/advanced-concepts/13-simulation.md new file mode 100644 index 000000000..02befbeac --- /dev/null +++ b/versioned_docs/version-0.46/develop/advanced-concepts/13-simulation.md @@ -0,0 +1,101 @@ + + +# 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.46.0-rc1/simapp/app.go), which is a +`Baseapp` application that is used for running the [`simulation`](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/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://pkg.go.dev/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.46.0-rc1/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.46.0-rc1/simapp/config.go#L33-L57). + +::: tip +These modes are not mutually exclusive. So you can for example run a randomly +generated genesis state (`1`) with manually generated simulation params (`3`). +::: + +## Usage + +This is a general example of how simulations are run. For more specific examples +check the Cosmos SDK [Makefile](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/Makefile#L263-L299). + +```bash + $ go test -mod=readonly github.com/cosmos/cosmos-sdk/simapp \ + -run=TestApp \ + ... + -v -timeout 24h +``` + +## Debugging Tips + +Here are some suggestions when encountering a simulation failure: + +* Export the app state at the height where 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.46.0-rc1/x/staking/keeper/keeper.go#L60-L63) 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 diff --git a/versioned_docs/version-0.46/develop/advanced-concepts/14-proto-docs.md b/versioned_docs/version-0.46/develop/advanced-concepts/14-proto-docs.md new file mode 100644 index 000000000..8ea66828c --- /dev/null +++ b/versioned_docs/version-0.46/develop/advanced-concepts/14-proto-docs.md @@ -0,0 +1,7 @@ + + +# Protobuf Documentation + +See [Cosmos-SDK Buf Proto-docs](https://buf.build/cosmos/cosmos-sdk/docs/main) diff --git a/versioned_docs/version-0.46/develop/advanced-concepts/15-tips.md b/versioned_docs/version-0.46/develop/advanced-concepts/15-tips.md new file mode 100644 index 000000000..1f7ef11b8 --- /dev/null +++ b/versioned_docs/version-0.46/develop/advanced-concepts/15-tips.md @@ -0,0 +1,206 @@ + + +# Transaction Tips + +Transaction tips are a mechanism to pay for transaction fees using another denom than the native fee denom of the chain. They are still in beta, and are not included by default in the SDK. {synopsis} + +## Context + +In a Cosmos ecosystem where more and more chains are connected via [IBC](https://ibc.cosmos.network/), it happens that users want to perform actions on chains where they don't have native tokens yet. An example would be an Osmosis user who wants to vote on a proposal on the Cosmos Hub, but they don't have ATOMs in their wallet. A solution would be to swap OSMO for ATOM just for voting on this proposal, but that is cumbersome. Cross-chain DeFi project [Emeris](https://emeris.com/) is another use case. + +Transaction tips is a new solution for cross-chain transaction fees payment, whereby the transaction initiator signs a transaction without specifying fees, but uses a new `Tip` field. They send this signed transaction to a fee relayer who will choose the transaction fees and broadcast the final transaction, and the SDK provides a mechanism that will transfer the pre-defined `Tip` to the fee payer, to cover for fees. + +Assuming we have two chains, A and B, we define the following terms: + +* **the tipper**: this is the initiator of the transaction, who wants to execute a `Msg` on chain A, but doesn't have any native chain A tokens, only chain B tokens. In our example above, the tipper is the Osmosis (chain B) user wanting to vote on a Cosmos Hub (chain A) proposal. +* **the fee payer**: this is the party that will relay and broadcast the final transaction on chain A, and has chain A tokens. The tipper doesn't need to trust the feepayer. +* **the target chain**: the chain where the `Msg` is executed, chain A in this case. + +## Transaction Tips Flow + +The transaction tips flow happens in multiple steps. + +1. The tipper sends via IBC some chain B tokens to chain A. These tokens will cover for fees on the target chain A. This means that chain A's bank module holds some IBC tokens under the tipper's address. + +2. The tipper drafts a transaction to be executed on the chain A. It can include chain A `Msg`s. However, instead of creating a normal transaction, they create the following `AuxSignerData` document: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/tx/v1beta1/tx.proto#L230-L249 + +where we have defined `SignDocDirectAux` as: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/tx/v1beta1/tx.proto#L67-L93 + +where `Tip` is defined as + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/tx/v1beta1/tx.proto#L219-L228 + +Notice that this document doesn't sign over the final chain A fees. Instead, it includes a `Tip` field. It also doesn't include the whole `AuthInfo` object as in `SIGN_MODE_DIRECT`, only the minimum information needed by the tipper + +3. The tipper signs the `SignDocDirectAux` document and attaches the signature to the `AuxSignerData`, then sends the signed `AuxSignerData` to the fee payer. + +4. From the signed `AuxSignerData` document, the fee payer constructs a transaction, using the following algorithm: + +* use as `TxBody` the exact `AuxSignerData.SignDocDirectAux.body_bytes`, to not alter the original intent of the tipper, +* create an `AuthInfo` with: + * `AuthInfo.Tip` copied from `AuxSignerData.SignDocDirectAux.Tip`, + * `AuthInfo.Fee` chosen by the fee payer, which should cover for the transaction gas, but also be small enough so that the tip/fee exchange rate is economically interesting for the fee payer, + * `AuthInfo.SignerInfos` has two signers: the first signer is the tipper, using the public key, sequence and sign mode specified in `AuxSignerData`; and the second signer is the fee payer, using their favorite sign mode, +* a `Signatures` array with two items: the tipper's signature from `AuxSignerData.Sig`, and the final fee payer's signature. + +5. Broadcast the final transaction signed by the two parties to the target chain. Once included, the Cosmos SDK will trigger a transfer of the `Tip` specified in the transaction from the tipper address to the fee payer address. + +### Fee Payers Market + +The benefit of transaction tips for the tipper is clear: there is no need to swap tokens before executing a cross-chain message. + +For the fee payer, the benefit is in the tip v.s. fee exchange. Put simply, the fee payer pays the fees of an unknown tipper's transaction, and gets in exchange the tip that the tipper chose. There is an economic incentive for the fee payer to do so only when the tip is greater than the transaction fees, given the exchange rates between the two tokens. + +In the future, we imagine a market where fee payers will compete to include transactions from tippers, who on their side will optimize by specifying the lowest tip possible. A number of automated services might spin up to perform transaction gas simulation and exchange rate monitoring to optimize both the tip and fee values in real-time. + +### Tipper and Fee Payer Sign Modes + +As we mentioned in the flow above, the tipper signs over the `SignDocDirectAux`, and the fee payer signs over the whole final transaction. As such, both parties might use different sign modes. + +* The tipper MUST use `SIGN_MODE_DIRECT_AUX` or `SIGN_MODE_LEGACY_AMINO_JSON`. That is because the tipper needs to sign over the body, the tip, but not the other signers' information and not over the fee (which is unknown to the tipper). +* The fee payer MUST use `SIGN_MODE_DIRECT` or `SIGN_MODE_LEGACY_AMINO_JSON`. The fee payer signs over the whole transaction. + +For example, if the fee payer signs the whole transaction with `SIGN_MODE_DIRECT_AUX`, it will be rejected by the node, as that would introduce malleability issues (`SIGN_MODE_DIRECT_AUX` doesn't sign over fees). + +In both cases, using `SIGN_MODE_LEGACY_AMINO_JSON` is recommended only if hardware wallet signing is needed. + +## Enabling Tips on your Chain + +The transaction tips functionality is introduced in Cosmos SDK v0.46, so earlier versions do not have support for tips. It is however not included by default in a v0.46 app. Sending a transaction with tips to a chain which didn't enable tips will result in a no-op, i.e. the `tip` field in the transaction will be ignored. + +Enabling tips on a chain is done by adding the `TipDecorator` in the posthandler chain: + +```go +// HandlerOptions are the options required for constructing a SDK PostHandler which supports tips. +type HandlerOptions struct { + BankKeeper types.BankKeeper +} + +// MyPostHandler returns a posthandler chain with the TipDecorator. +func MyPostHandler(options HandlerOptions) (sdk.AnteHandler, error) { + if options.BankKeeper == nil { + return nil, sdkerrors.Wrap(sdkerrors.ErrLogic, "bank keeper is required for posthandler") + } + + postDecorators := []sdk.AnteDecorator{ + posthandler.NewTipDecorator(options.bankKeeper), + } + + return sdk.ChainAnteDecorators(postDecorators...), nil +} + +func (app *SimApp) setPostHandler() { + postHandler, err := MyPostHandler( + HandlerOptions{ + BankKeeper: app.BankKeeper, + }, + ) + if err != nil { + panic(err) + } + + app.SetPostHandler(postHandler) +} +``` + +Notice that `NewTipDecorator` needs a reference to the BankKeeper, for transferring the tip to the fee payer. + +## CLI Usage + +The Cosmos SDK also provides some CLI tooling for the transaction tips flow, both for the tipper and for the feepayer. + +For the tipper, the CLI `tx` subcommand has two new flags: `--aux` and `--tip`. The `--aux` flag is used to denote that we are creating an `AuxSignerData` instead of a `Tx`, and the `--tip` is used to populate its `Tip` field. + +```bash +$ simd tx gov vote 16 yes --from --aux --tip 50ibcdenom + + +### Prints the AuxSignerData as JSON: +### {"address":"cosmos1q0ayf5vq6fd2xxrwh30upg05hxdnyw2h5249a2","sign_doc":{"body_bytes":"CosBChwvY29zbW9zLmJhbmsudjFiZXRhMS5Nc2dTZW5kEmsKLWNvc21vczFxMGF5ZjV2cTZmZDJ4eHJ3aDMwdXBnMDVoeGRueXcyaDUyNDlhMhItY29zbW9zMXdlNWoyZXI2MHV5OXF3YzBta3ptdGdtdHA5Z3F5NXY2bjhnZGdlGgsKBXN0YWtlEgIxMA==","public_key":{"@type":"/cosmos.crypto.secp256k1.PubKey","key":"AojOF/1luQ5H/nZDSrE1w3CyzGJhJdQuS7hFX5wAA6uJ"},"chain_id":"","account_number":"0","sequence":"1","tip":{"amount":[{"denom":"ibcdenom","amount":"50"}],"tipper":"cosmos1q0ayf5vq6fd2xxrwh30upg05hxdnyw2h5249a2"}},"mode":"SIGN_MODE_DIRECT_AUX","sig":"v/d/bGq9FGdecs6faMG2t//nRirFTiqwFtUB65M6kh0QdUeM6jg3r8oJX1o17xkoDxJ09EyJiSyvo6fbU7vUxg=="} +``` + +It is useful to pipe the JSON output to a file, `> aux_signed_tx.json` + +For the fee payer, the Cosmos SDK added a `tx aux-to-fee` subcommand to include an `AuxSignerData` into a transaction, add fees to it, and broadcast it. + +```bash +$ simd tx aux-to-fee aux_signed_tx.json --from --fees 30atom + +### Prints the broadcasted tx response: +### code: 0 +### codespace: sdk +### data: "" +### events: [] +### gas_used: "0" +### gas_wanted: "0" +### height: "0" +### info: "" +### logs: [] +### timestamp: "" +### tx: null +``` + +Upon completion of the second command, the fee payer's balance will be down the `30atom` fees, and up the `50ibcdenom` tip. + +For both commands, the flag `--sign-mode=amino-json` is still available for hardware wallet signing. + +## Programmatic Usage + +For the tipper, the SDK exposes a new transaction builder, the `AuxTxBuilder`, for generating an `AuxSignerData`. The API of `AuxTxBuilder` is defined [in `client/tx`](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/client/tx/aux_builder.go#L16), and can be used as follows: + +```go +// Note: there's no need to use clientCtx.TxConfig anymore. + +bldr := clienttx.NewAuxTxBuilder() +err := bldr.SetMsgs(msgs...) +bldr.SetAddress("cosmos1...") +bldr.SetMemo(...) +bldr.SetTip(...) +bldr.SetPubKey(...) +err := bldr.SetSignMode(...) // DIRECT_AUX or AMINO, or else error +// ... other setters are also available + +// Get the bytes to sign. +signBz, err := bldr.GetSignBytes() + +// Sign the bz using your favorite method. +sig, err := privKey.sign(signBz) + +// Set the signature +bldr.SetSig(sig) + +// Get the final auxSignerData to be sent to the fee payer +auxSignerData, err:= bldr.GetAuxSignerData() +``` + +For the fee payer, the SDK added a new method on the existing `TxBuilder` to import data from an `AuxSignerData`: + +```go +// get `auxSignerData` from tipper, see code snippet above. + +txBuilder := clientCtx.TxConfig.NewTxBuilder() +err := txBuilder.AddAuxSignerData(auxSignerData) +if err != nil { + return err +} + +// A lot of fields will be populated in txBuilder, such as its Msgs, tip +// memo, etc... + +// The fee payer choses the fee to set on the transaction. +txBuilder.SetFeePayer() +txBuilder.SetFeeAmount(...) +txBuilder.SetGasLimit(...) + +// Usual signing code +err = authclient.SignTx(...) +if err != nil { + return err +} +``` diff --git a/versioned_docs/version-0.46/develop/advanced-concepts/16-upgrade.md b/versioned_docs/version-0.46/develop/advanced-concepts/16-upgrade.md new file mode 100644 index 000000000..bcccd4717 --- /dev/null +++ b/versioned_docs/version-0.46/develop/advanced-concepts/16-upgrade.md @@ -0,0 +1,160 @@ + + +# In-Place Store Migrations + +::: warning +Read and understand all 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: + +* 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. + +* Perform upgrades in place, which 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. + +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. + +### 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. + +### 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 in the state. + +## 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. + +```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. + +```go +cfg := module.NewConfigurator(...) +app.UpgradeKeeper.SetUpgradeHandler("my-plan", func(ctx sdk.Context, plan upgradetypes.Plan, fromVM module.VersionMap) (module.VersionMap, error) { + + // ... + // additional upgrade logic + // ... + + // returns a VersionMap with the updated module ConsensusVersions + return app.mm.RunMigrations(ctx, fromVM) +}) +``` + +To learn more about configuring migration scripts for your modules, see the [Module Upgrade Guide](../building-modules/upgrade.md). + +### Order Of Migrations + +By default, all migrations are run in module name alphabetical ascending order, except `x/auth` which is run last. The reason is state dependencies between x/auth and other modules (you can read more in [issue #10606](https://github.com/cosmos/cosmos-sdk/issues/10606)). + +If you want to change the order of migration, then you should call `app.mm.SetOrderMigrations(module1, module2, ...)` in your app.go file. The function will panic if you forget to include a module in the argument list. + +## 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. + +### Add StoreUpgrades for New Modules + +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() +if err != nil { + panic(err) +} + +if upgradeInfo.Name == "my-plan" && !app.UpgradeKeeper.IsSkipHeight(upgradeInfo.Height) { + storeUpgrades := storetypes.StoreUpgrades{ + // add store upgrades for new modules + // Example: + // Added: []string{"foo", "bar"}, + // ... + } + + // configure store loader that checks if version == upgradeHeight and applies store upgrades + app.SetStoreLoader(upgradetypes.UpgradeStoreLoader(upgradeInfo.Height, &storeUpgrades)) +} +``` + +## 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`: + +```diff +func (app *MyApp) InitChainer(ctx sdk.Context, req abci.RequestInitChain) abci.ResponseInitChain { + ... ++ app.UpgradeKeeper.SetModuleVersionMap(ctx, app.mm.GetVersionMap()) + ... +} +``` + +This information is used by the Cosmos SDK to detect when modules with newer versions are introduced to the app. + +For a new module `foo`, `InitGenesis` is called by `RunMigration` only when `foo` is registered in the module manager but it's not set in the `fromVM`. Therefore, if you want to skip `InitGenesis` when a new module is added to the app, then you should set its module version in `fromVM` to the module consensus version: + +```go +app.UpgradeKeeper.SetUpgradeHandler("my-plan", func(ctx sdk.Context, plan upgradetypes.Plan, fromVM module.VersionMap) (module.VersionMap, error) { + // ... + + // Set foo's version to the latest ConsensusVersion in the VersionMap. + // This will skip running InitGenesis on Foo + fromVM[foo.ModuleName] = foo.AppModule{}.ConsensusVersion() + + return app.mm.RunMigrations(ctx, fromVM) +}) +``` + +### 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. + +You can write your own `InitGenesis` function for an imported module. To do this, manually trigger your custom genesis function in the upgrade handler. + +::: 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`. +::: + +```go +import foo "github.com/my/module/foo" + +app.UpgradeKeeper.SetUpgradeHandler("my-plan", func(ctx sdk.Context, plan upgradetypes.Plan, fromVM module.VersionMap) (module.VersionMap, error) { + + // Register the consensus version in the version map + // to avoid the SDK from triggering the default + // InitGenesis function. + fromVM["foo"] = foo.AppModule{}.ConsensusVersion() + + // Run custom InitGenesis for foo + app.mm["foo"].InitGenesis(ctx, app.appCodec, myCustomGenesisState) + + return app.mm.RunMigrations(ctx, cfg, fromVM) +}) +``` + +## Syncing a Full Node to an Upgraded Blockchain + +You can sync a full node to an existing blockchain which has been upgraded using Cosmovisor + +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. + +To learn more about Cosmovisor, see the [Cosmovisor Quick Start](../run-node/cosmovisor.md). diff --git a/versioned_docs/version-0.46/develop/advanced-concepts/_category_.json b/versioned_docs/version-0.46/develop/advanced-concepts/_category_.json new file mode 100644 index 000000000..b2ac426fb --- /dev/null +++ b/versioned_docs/version-0.46/develop/advanced-concepts/_category_.json @@ -0,0 +1,5 @@ +{ + "label": "Advanced Concepts", + "position": 2, + "link": null +} \ No newline at end of file diff --git a/versioned_docs/version-0.46/develop/advanced-concepts/keeper_dependencies.svg b/versioned_docs/version-0.46/develop/advanced-concepts/keeper_dependencies.svg new file mode 100644 index 000000000..bac9328e3 --- /dev/null +++ b/versioned_docs/version-0.46/develop/advanced-concepts/keeper_dependencies.svg @@ -0,0 +1,102 @@ +The dependencies between Keepers (Feb 2021)StakingDistributionSlashingEvidenceBankAuth/AccountGovMint \ No newline at end of file diff --git a/versioned_docs/version-0.46/develop/high-level-concepts/README.md b/versioned_docs/version-0.46/develop/high-level-concepts/README.md new file mode 100644 index 000000000..3907f6e60 --- /dev/null +++ b/versioned_docs/version-0.46/develop/high-level-concepts/README.md @@ -0,0 +1,17 @@ + + +# Basics + +This repository contains reference documentation on the basic concepts of the 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) +5. [Gas and Fees](./gas-fees.md) + +After reading the basics, head on to the [Core Reference](../core/README.md) for more advanced material. diff --git a/versioned_docs/version-0.46/develop/high-level-concepts/03-accounts.md b/versioned_docs/version-0.46/develop/high-level-concepts/accounts.md similarity index 83% rename from versioned_docs/version-0.46/develop/high-level-concepts/03-accounts.md rename to versioned_docs/version-0.46/develop/high-level-concepts/accounts.md index 15911cf5b..dde895cce 100644 --- a/versioned_docs/version-0.46/develop/high-level-concepts/03-accounts.md +++ b/versioned_docs/version-0.46/develop/high-level-concepts/accounts.md @@ -1,25 +1,18 @@ ---- -sidebar_position: 1 -dislayed_sidebar: developSidebar ---- + # Accounts -:::note Synopsis -This document describes the in-built account and public key system of the Cosmos SDK. -::: +This document describes the in-built account and public key system of the Cosmos SDK. {synopsis} -:::note +## Pre-requisite Readings -### Pre-requisite Readings - -* [Anatomy of a Cosmos SDK Application](00-overview-app.md) - -::: +* [Anatomy of a Cosmos SDK Application](./app-anatomy.md) {prereq} ## Account Definition -In the Cosmos SDK, an _account_ designates a pair of _public key_ `PubKey` and _private key_ `PrivKey`. The `PubKey` can be derived to generate various `Addresses`, which are used to identify users (among other parties) in the application. `Addresses` are also associated with [`message`s](../../integrate/building-modules/02-messages-and-queries.md#messages) to identify the sender of the `message`. The `PrivKey` is used to generate [digital signatures](#keys-accounts-addresses-and-signatures) to prove that an `Address` associated with the `PrivKey` approved of a given `message`. +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. @@ -73,11 +66,11 @@ In the node, all data is stored using Protocol Buffers serialization. The Cosmos SDK supports the following digital key schemes for creating digital signatures: -* `secp256k1`, as implemented in the [Cosmos SDK's `crypto/keys/secp256k1` package](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/crypto/keys/secp256k1/secp256k1.go). -* `secp256r1`, as implemented in the [Cosmos SDK's `crypto/keys/secp256r1` package](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/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.47.0-rc1/crypto/keys/ed25519/ed25519.go). This scheme is supported only for the consensus validation. +* `secp256k1`, as implemented in the [Cosmos SDK's `crypto/keys/secp256k1` package](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/crypto/keys/secp256k1/secp256k1.go). +* `secp256r1`, as implemented in the [Cosmos SDK's `crypto/keys/secp256r1` package](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/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.46.0-rc1/crypto/keys/ed25519/ed25519.go). This scheme is supported only for the consensus validation. -| | Address length in bytes | Public key length in bytes | Used for transaction authentication | Used for consensus (cometbft) | +| | Address length in bytes | Public key length in bytes | Used for transaction authentication | Used for consensus (tendermint) | | :----------: | :---------------------: | :------------------------: | :---------------------------------: | :-----------------------------: | | `secp256k1` | 20 | 33 | yes | no | | `secp256r1` | 32 | 33 | yes | no | @@ -95,9 +88,7 @@ Each account is identified using `Address` which is a sequence of bytes derived These types implement the `Address` interface: -```go reference -https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/types/address.go#L108-L124 -``` ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/address.go#L108-L125 Address construction algorithm is defined in [ADR-28](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-028-public-key-addresses.md). Here is the standard way to obtain an account address from a `pub` public key: @@ -110,9 +101,7 @@ Of note, the `Marshal()` and `Bytes()` method both return the same raw `[]byte` 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: -```go reference -https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/types/address.go#L281-L295 -``` ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/address.go#L272-L286 | | Address Bech32 Prefix | | ------------------ | --------------------- | @@ -124,9 +113,7 @@ https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/types/address.go#L281-L295 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: -```go reference -https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/crypto/types/types.go#L8-L17 -``` ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/crypto/types/types.go#L8-L17 A compressed format is used for `secp256k1` and `secp256r1` serialization. @@ -136,33 +123,30 @@ A compressed format is used for `secp256k1` and `secp256r1` serialization. This prefix is followed by the `x`-coordinate. 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/v0.47.0-rc1/codec/json.go#L14-L34) function). Example: +For user interactions, `PubKey` is formatted using Protobufs JSON ([ProtoMarshalJSON](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/codec/json.go#L14-L34) function). Example: -```go reference -https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/crypto/keyring/output.go#L23-L39 -``` ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/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: -```go reference -https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/crypto/keyring/keyring.go#L54-L101 -``` ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/crypto/keyring/keyring.go#L54-L101 The default implementation of `Keyring` comes from the third-party [`99designs/keyring`](https://github.com/99designs/keyring) library. A few notes on the `Keyring` methods: -* `Sign(uid string, msg []byte) ([]byte, types.PubKey, error)` strictly deals with the signature of the `msg` 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](../../integrate/architecture/adr-020-protobuf-transaction-encoding.md) that the canonical `payload` to sign is the `SignDoc` struct, deterministically encoded using [ADR-027](../../integrate/architecture/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`](../advanced-concepts/00-baseapp.md#antehandler). - -```protobuf reference -https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/tx/v1beta1/tx.proto#L48-L65 -``` +* `Sign(uid string, msg []byte) ([]byte, types.PubKey, error)` strictly deals with the signature of the `msg` 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](../architecture/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). + +++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/tx/v1beta1/tx.proto#L48-L65 -* `NewAccount(uid, mnemonic, bip39Passphrase, hdPath string, algo SignatureAlgo) (*Record, 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.47.0-rc1/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, bip39Passphrase, hdPath string, algo SignatureAlgo) (*Record, 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.46.0-rc1/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: * `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. + +## Next {hide} + +Learn about [gas and fees](./gas-fees.md) {hide} diff --git a/versioned_docs/version-0.46/develop/high-level-concepts/app-anatomy.md b/versioned_docs/version-0.46/develop/high-level-concepts/app-anatomy.md new file mode 100644 index 000000000..91a01b8ad --- /dev/null +++ b/versioned_docs/version-0.46/develop/high-level-concepts/app-anatomy.md @@ -0,0 +1,256 @@ + + +# Anatomy of a Cosmos SDK Application + +This document describes the core parts of a Cosmos SDK application. Throughout the document, a placeholder application named `app` will be used. {synopsis} + +## Node Client + +The Daemon, or [Full-Node Client](../core/node.md), is the core process of 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. + +```text + ^ +-------------------------------+ ^ + | | | | + | | State-machine = Application | | + | | | | Built with Cosmos SDK + | | ^ + | | + | +----------- | ABCI | ----------+ v + | | + v | ^ + | | | | +Blockchain Node | | Consensus | | + | | | | + | +-------------------------------+ | Tendermint Core + | | | | + | | Networking | | + | | | | + v +-------------------------------+ v +``` + +The blockchain full-node presents itself as a binary, generally suffixed by `-d` for "daemon" (e.g. `appd` for `app` or `gaiad` for `gaia`). This binary is built by running a simple [`main.go`](../core/node.md#main-function) function placed in `./cmd/appd/`. This operation usually happens through the [Makefile](#dependencies-and-makefile). + +Once the main binary is built, the node can be started by running the [`start` command](../core/node.md#start-command). This command function primarily does three things: + +1. Create an instance of the state-machine defined in [`app.go`](#core-application-file). +2. Initialize the state-machine with the latest known state, extracted from the `db` stored in the `~/.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). + +## Core Application File + +In general, the core of the state-machine is defined in a file called `app.go`. It mainly contains the **type definition of the application** and functions to **create and initialize it**. + +### Type Definition of the Application + +The first thing defined in `app.go` is the `type` of the application. It is generally comprised of the following parts: + +* **A reference to [`baseapp`](../core/baseapp.md).** The custom application defined in `app.go` is an extension of `baseapp`. When a transaction is relayed by Tendermint to the application, `app` uses `baseapp`'s methods to route them to the appropriate module. `baseapp` implements most of the core logic for the application, including all the [ABCI methods](https://docs.tendermint.com/master/spec/abci/abci.html) 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). + +See an example of application type definition from `simapp`, the Cosmos SDK's own app used for demo and testing purposes: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/simapp/app.go#L151-L193 + +### Constructor Function + +This function constructs a new application of the type defined in the section above. It must fulfill the `AppCreator` signature in order to be used in the [`start` command](../core/node.md#start-command) of the application's daemon command. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/server/types/app.go#L57-L59 + +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. + +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. + +See an example of application constructor from `simapp`: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/simapp/app.go#L204-L474 + +### 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://pkg.go.dev/github.com/cosmos/cosmos-sdk/baseapp#BaseApp.SetInitChainer) method. + +In general, the `InitChainer` is mostly composed of the [`InitGenesis`](../building-modules/genesis.md#initgenesis) function of each of the application's modules. This is done by calling the `InitGenesis` function of the module manager, which in turn will call the `InitGenesis` function of each of the modules it contains. Note that the order in which the modules' `InitGenesis` functions must be called has to be set in the module manager using the [module manager's](../building-modules/module-manager.md) `SetOrderInitGenesis` method. This is done in the [application's constructor](#application-constructor), and the `SetOrderInitGenesis` has to be called before the `SetInitChainer`. + +See an example of an `InitChainer` from `simapp`: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/simapp/app.go#L524-L532 + +### 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://pkg.go.dev/github.com/cosmos/cosmos-sdk/baseapp#BaseApp.SetBeginBlocker) and [`SetEndBlocker`](https://pkg.go.dev/github.com/cosmos/cosmos-sdk/baseapp#BaseApp.SetEndBlocker) methods. + +In general, the `BeginBlocker` and `EndBlocker` functions are mostly composed of the [`BeginBlock` and `EndBlock`](../building-modules/beginblock-endblock.md) functions of each of the application's modules. This is done by calling the `BeginBlock` and `EndBlock` functions of the module manager, which in turn will call the `BeginBlock` and `EndBlock` functions of each of the modules it contains. Note that the order in which the modules' `BeginBlock` and `EndBlock` functions must be called has to be set in the module manager using the `SetOrderBeginBlockers` and `SetOrderEndBlockers` methods respectively. This is done via the [module manager](../building-modules/module-manager.md) in the [application's constructor](#application-constructor), and the `SetOrderBeginBlockers` and `SetOrderEndBlockers` methods have to be called before the `SetBeginBlocker` and `SetEndBlocker` functions. + +As a sidenote, it is important to remember that application-specific blockchains are deterministic. Developers must be careful not to introduce non-determinism in `BeginBlocker` or `EndBlocker`, and must also be careful not to make them too computationally expensive, as [gas](./gas-fees.md) does not constrain the cost of `BeginBlocker` and `EndBlocker` execution. + +See an example of `BeginBlocker` and `EndBlocker` functions from `simapp` + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/simapp/app.go#L514-L522 + +### Register Codec + +The `EncodingConfig` structure is the last important part of the `app.go` file. The goal of this structure is to define the codecs that will be used throughout the app. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/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://pkg.go.dev/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 register 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). +* `Codec`: 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 `Codec`. +* `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. + +The Cosmos SDK exposes a `MakeTestEncodingConfig` function used to create a `EncodingConfig` for the app constructor (`NewApp`). It uses Protobuf as a default `Codec`. + +NOTE: This function is deprecated and should only be used to create an app or in tests. + +See an example of a `MakeTestEncodingConfig` from `simapp`: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/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). + +### 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, by convention, defined in a file called `module.go`. + +`AppModule` exposes a collection of useful methods on the module that facilitates the composition of modules into a coherent application. These methods are called from the [`module manager`](../building-modules/module-manager.md#manager), which manages the application's collection of modules. + +### `Msg` Services + +Each module defines two [Protobuf services](https://developers.google.com/protocol-buffers/docs/proto#services): one `Msg` service to handle messages, and one gRPC `Query` service to handle queries. If we consider the module as a state-machine, then a `Msg` 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. + +When a valid block of transactions is received by the full-node, Tendermint relays each one to the application via [`DeliverTx`](https://docs.tendermint.com/master/spec/abci/apps.html#delivertx). Then, the application handles the transaction: + +1. Upon receiving the transaction, the application first unmarshalls it from `[]byte`. +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. + +For a more details look at a transaction [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: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/bank/v1beta1/tx.proto#L12-L19 + +Service methods use `keeper` in order to update the module state. + +Each module should also implement the `RegisterServices` method as part of the [`AppModule` interface](#application-module-interface). This method should call the `RegisterMsgServer` function provided by the generated Protobuf code. + +### gRPC `Query` Services + +gRPC `Query` services allows 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` services are defined in the module's Protobuf definition files, specifically inside `query.proto`. The `query.proto` definition file exposes a single `Query` [Protobuf service](https://developers.google.com/protocol-buffers/docs/proto#services). Each gRPC query endpoint corresponds to a service method, starting with the `rpc` keyword, inside the `Query` service. + +Protobuf generates a `QueryServer` interface for each module, containing all the service methods. A module's [`keeper`](#keeper) then needs to implement this `QueryServer` interface, by providing the concrete implementation of each service method. This concrete implementation is the handler of the corresponding gRPC query endpoint. + +Finally, each module should also implement the `RegisterServices` method as part of the [`AppModule` interface](#application-module-interface). This method should call the `RegisterQueryServer` function provided by the generated Protobuf code. + +### Keeper + +[`Keepers`](../building-modules/keeper.md) are the gatekeepers of their module's store(s). To read or write in a module's store, it is mandatory to go through one of its `keeper`'s methods. This is ensured by the [object-capabilities](../core/ocap.md) model of the Cosmos SDK. Only objects that hold the key to a store can access it, and only the module's `keeper` should hold the key(s) to the module's store(s). + +`Keepers` are generally defined in a file called `keeper.go`. It contains the `keeper`'s type definition and methods. + +The `keeper` type definition generally consists of: + +* **Key(s)** to the module's store(s) in the multistore. +* Reference to **other module's `keepers`**. Only needed if the `keeper` needs to access other module's store(s) (either to read or write from them). +* A reference to the application's **codec**. The `keeper` needs it to marshal structs before storing them, or to unmarshal them when it retrieves them, because stores only accept `[]bytes` as value. + +Along with the type definition, the next important component of the `keeper.go` file is the `keeper`'s constructor function, `NewKeeper`. This function instantiates a new `keeper` of the type defined above, with a `codec`, store `keys` and potentially references to other modules' `keeper`s as parameters. The `NewKeeper` function is called from the [application's constructor](#constructor-function). The rest of the file defines the `keeper`'s methods, primarily getters and setters. + +### Command-Line, gRPC Services and REST Interfaces + +Each module defines command-line commands, gRPC services and REST routes to be exposed to end-user via the [application's interfaces](#application-interfaces). This enables end-users to create messages of the types defined in the module, or to query the subset of the state managed by the module. + +#### CLI + +Generally, the [commands related to a module](../building-modules/module-interfaces.md#cli) are defined in a folder called `client/cli` in the module's folder. The CLI divides commands in two category, transactions and queries, defined in `client/cli/tx.go` and `client/cli/query.go` respectively. Both commands are built on top of the [Cobra Library](https://github.com/spf13/cobra): + +* Transactions commands let users generate new transactions so that they can be included in a block and eventually update the state. One command should be created for each [message type](#message-types) defined in the module. The command calls the constructor of the message with the parameters provided by the end-user, and wraps it into a transaction. The 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. + +#### gRPC + +[gRPC](https://grpc.io) is a modern open-source high performance RPC framework that has support in multiple languages. It is the recommended way for external clients (such as wallets, browsers and other backend services) to interact with a node. + +Each module can expose gRPC endpoints, called [service methods](https://grpc.io/docs/what-is-grpc/core-concepts/#service-definition) and are defined in the [module's Protobuf `query.proto` file](#grpc-query-services). A service method is defined by its name, input arguments and output response. The module then needs to: + +* define a `RegisterGRPCGatewayRoutes` method on `AppModuleBasic` to wire the client gRPC requests to the correct handler inside the module. +* for each service method, define a corresponding handler. The handler implements the core logic necessary to serve the gRPC request, and is located in the `keeper/grpc_query.go` file. + +#### gRPC-gateway REST Endpoints + +Some external clients may not wish to use gRPC. The 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. + +The REST endpoints are defined in the Protobuf files, along with the gRPC services, using Protobuf annotations. Modules that want to expose REST queries should add `google.api.http` annotations to their `rpc` methods. By default, all REST endpoints defined in the SDK have an URL starting with the `/cosmos/` prefix. + +The 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. + +## 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. + +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: + +* **A `main()` function**, which is executed to build the `appd` interface client. This function prepares each command and adds them to the `rootCmd` before building them. At the root of `appd`, the function adds generic commands like `status`, `keys` and `config`, query commands, tx commands and `rest-server`. +* **Query commands** are added by calling the `queryCmd` function. This function returns a Cobra command that contains the query commands defined in each of the application's modules (passed as an array of `sdk.ModuleClients` from the `main()` function), as well as some other lower level query commands such as block or validator queries. Query command are called by using the command `appd query [query]` of the CLI. +* **Transaction commands** are added by calling the `txCmd` function. Similar to `queryCmd`, the function returns a Cobra command that contains the tx commands defined in each of the application's modules, as well as lower level tx commands like transaction signing or broadcasting. Tx commands are called by using the command `appd tx [tx]` of the CLI. + +See an example of an application's main command-line file from the [Cosmos Hub](https://github.com/cosmos/gaia) + ++++ https://github.com/cosmos/gaia/blob/Theta-main/cmd/gaiad/cmd/root.go#L39-L77 + +## Dependencies and Makefile + +::: warning +A patch introduced in `go-grpc v1.34.0` made gRPC incompatible with the `gogoproto` library, making some [gRPC queries](https://github.com/cosmos/cosmos-sdk/issues/8426) panic. As such, the Cosmos SDK requires that `go-grpc <=v1.33.2` is installed in your `go.mod`. + +To make sure that gRPC is working properly, it is **highly recommended** to add the following line in your application's `go.mod`: + +```go +replace google.golang.org/grpc => google.golang.org/grpc v1.33.2 +``` + +Please see [issue #8392](https://github.com/cosmos/cosmos-sdk/issues/8392) for more info. +::: + +This section is optional, as developers are free to choose their dependency manager and project building method. That said, the current most used framework for versioning control is [`go.mod`](https://github.com/golang/go/wiki/Modules). It ensures each of the libraries used throughout the application are imported with the correct version. + +Below, the `go.mod` of the [Cosmos Hub](https://github.com/cosmos/gaia) is provided as an example. + ++++ https://github.com/cosmos/gaia/blob/Theta-main/go.mod#L1-L20 + +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). + +Here is an example of the [Cosmos Hub Makefile](https://github.com/cosmos/gaia/blob/Theta-main/Makefile). + +## Next {hide} + +Learn more about the [Lifecycle of a transaction](./tx-lifecycle.md) {hide} diff --git a/versioned_docs/version-0.46/develop/high-level-concepts/gas-fees.md b/versioned_docs/version-0.46/develop/high-level-concepts/gas-fees.md new file mode 100644 index 000000000..b49bc8a97 --- /dev/null +++ b/versioned_docs/version-0.46/develop/high-level-concepts/gas-fees.md @@ -0,0 +1,85 @@ + + +# Gas and Fees + +This document describes the default strategies to handle gas and fees within a Cosmos SDK application. {synopsis} + +## Pre-requisite Readings + +* [Anatomy of a Cosmos SDK Application](./app-anatomy.md) {prereq} + +## Introduction to `Gas` and `Fees` + +In the Cosmos SDK, `gas` is a special unit that is used to track the consumption of resources during execution. `gas` is typically consumed whenever read and writes are made to the store, but it can also be consumed if expensive computation needs to be done. It serves two main purposes: + +* Make sure blocks are not consuming too many resources and will be finalized. This is implemented by default in the 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). + +## Gas Meter + +In the Cosmos SDK, `gas` is a simple alias for `uint64`, and is managed by an object called a _gas meter_. Gas meters implement the `GasMeter` interface + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/store/types/gas.go#L40-L51 + +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. +* `GasRemaining()` returns the gas left in the GasMeter. +* `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. +* `RefundGas()` deducts the given amount from the gas consumed. This functionality enables refunding gas to the transaction or block gas pools so that EVM-compatible chains can fully support the go-ethereum StateDB interface. +* `IsPastLimit()` returns `true` if the amount of gas consumed by the gas meter instance is strictly above the limit, `false` otherwise. +* `IsOutOfGas()` returns `true` if the amount of gas consumed by the gas meter instance is above or equal to the limit, `false` otherwise. + +The gas meter is generally held in [`ctx`](../core/context.md), and consuming gas is done with the following pattern: + +```go +ctx.GasMeter().ConsumeGas(amount, "description") +``` + +By default, the Cosmos SDK makes use of two different gas meters, the [main gas meter](#main-gas-metter) and the [block gas meter](#block-gas-meter). + +### Main Gas Meter + +`ctx.GasMeter()` is the main gas meter of the application. The main gas meter is initialized in `BeginBlock` via `setDeliverState`, and then tracks gas consumption during execution sequences that lead to state-transitions, i.e. those originally triggered by [`BeginBlock`](../core/baseapp.md#beginblock), [`DeliverTx`](../core/baseapp.md#delivertx) and [`EndBlock`](../core/baseapp.md#endblock). At the beginning of each `DeliverTx`, the main gas meter **must be set to 0** in the [`AnteHandler`](#antehandler), so that it can track gas consumption per-transaction. + +Gas consumption can be done manually, generally by the module developer in the [`BeginBlocker`, `EndBlocker`](../building-modules/beginblock-endblock.md) or [`Msg` service](../building-modules/msg-services.md), but most of the time it is done automatically whenever there is a read or write to the store. This automatic gas consumption logic is implemented in a special store called [`GasKv`](../core/store.md#gaskv-store). + +### Block Gas Meter + +`ctx.BlockGasMeter()` is the gas meter used to track gas consumption per block and make sure it does not go above a certain limit. A new instance of the `BlockGasMeter` is created each time [`BeginBlock`](../core/baseapp.md#beginblock) is called. The `BlockGasMeter` is finite, and the limit of gas per block is defined in the application's consensus parameters. By default, Cosmos SDK applications use the default consensus parameters provided by Tendermint: + ++++ https://github.com/tendermint/tendermint/blob/v0.35.4/types/params.go#L78-L117 + +When a new [transaction](../core/transactions.md) is being processed via `DeliverTx`, the current value of `BlockGasMeter` is checked to see if it is above the limit. If it is, `DeliverTx` returns immediately. This can happen even with the first transaction in a block, as `BeginBlock` itself can consume gas. If not, the transaction is processed normally. At the end of `DeliverTx`, the gas tracked by `ctx.BlockGasMeter()` is increased by the amount consumed to process the transaction: + +```go +ctx.BlockGasMeter().ConsumeGas( + ctx.GasMeter().GasConsumedToLimit(), + "block gas meter", +) +``` + +## AnteHandler + +The `AnteHandler` is run for every transaction during `CheckTx` and `DeliverTx`, before a Protobuf `Msg` service method for each `sdk.Msg` in the transaction. + +The anteHandler is not implemented in the core Cosmos SDK but in a module. That said, most applications today use the default implementation defined in the [`auth` module](https://github.com/cosmos/cosmos-sdk/tree/main/x/auth). Here is what the `anteHandler` is intended to do in a normal Cosmos SDK application: + +* Verify that the transactions are of the correct type. Transaction types are defined in the module that implements the `anteHandler`, and they follow the transaction interface: + +++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/tx_msg.go#L38-L46 + This enables developers to play with various types for the transaction of their application. In the default `auth` module, the default transaction type is `Tx`: + +++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/tx/v1beta1/tx.proto#L13-L26 +* 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 ensures 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 crucial**, as it not only makes sure the transaction cannot consume infinite gas, but also that `ctx.GasMeter` is reset in-between each `DeliverTx` (`ctx` is set to `newCtx` after `anteHandler` is run, and the `anteHandler` is run each time `DeliverTx` is called). + +As explained above, the `anteHandler` returns a maximum limit of `gas` the transaction can consume during execution called `GasWanted`. The actual amount consumed in the end is denominated `GasUsed`, and we must therefore have `GasUsed =< GasWanted`. Both `GasWanted` and `GasUsed` are relayed to the underlying consensus engine when [`DeliverTx`](../core/baseapp.md#delivertx) returns. + +## Next {hide} + +Learn about [baseapp](../core/baseapp.md) {hide} diff --git a/versioned_docs/version-0.46/develop/high-level-concepts/query-lifecycle.md b/versioned_docs/version-0.46/develop/high-level-concepts/query-lifecycle.md new file mode 100644 index 000000000..80b492f57 --- /dev/null +++ b/versioned_docs/version-0.46/develop/high-level-concepts/query-lifecycle.md @@ -0,0 +1,138 @@ + + +# 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} + +## Pre-requisite Readings + +* [Transaction Lifecycle](./tx-lifecycle.md) {prereq} + +## Query Creation + +A [**query**](../building-modules/messages-and-queries.md#queries) is a request for information made by end-users of applications through an interface and processed by a full-node. Users can query information about the network, the application itself, and application state directly from the application's stores or modules. Note that queries are different from [transactions](../core/transactions.md) (view the lifecycle [here](./tx-lifecycle.md)), particularly in that they do not require consensus to be processed (as they do not trigger state-transitions); they can be fully handled by one full-node. + +For the purpose of explaining the query lifecycle, let's say `MyQuery` is requesting a list of delegations made by a certain delegator address in the application called `simapp`. As to be expected, the [`staking`](../../x/staking/spec/README.md) module handles this query. But first, there are a few ways `MyQuery` can be created by users. + +### CLI + +The main interface for an application is the command-line interface. Users connect to a full-node and run the CLI directly from their machines - the CLI interacts directly with the full-node. To create `MyQuery` from their terminal, users type the following command: + +```bash +simd query staking delegations +``` + +This query command was defined by the [`staking`](../../x/staking/spec/README.md) module developer and added to the list of subcommands by the application developer when creating the CLI. + +Note that the general format is as follows: + +```bash +simd query [moduleName] [command] --flag +``` + +To provide values such as `--node` (the full-node the CLI connects to), the user can use the [`app.toml`](../run-node/run-node.md#configuring-the-node-using-apptoml) config file to set them or provide them as flags. + +The CLI understands a specific set of commands, defined in a hierarchical structure by the application developer: from the [root command](../core/cli.md#root-command) (`simd`), the type of command (`Myquery`), the module that contains the command (`staking`), and command itself (`delegations`). Thus, the CLI knows exactly which module handles this command and directly passes the call there. + +Another interface through which users can make queries is [gRPC](https://grpc.io) requests to a [gRPC server](../core/grpc_rest.md#grpc-server). The endpoints are defined as [Protocol Buffers](https://developers.google.com/protocol-buffers) service methods inside `.proto` files, written in Protobuf's own language-agnostic interface definition language (IDL). The Protobuf ecosystem developed tools for code-generation from `*.proto` files into various languages. These tools allow to build gRPC clients easily. + +One such tool is [grpcurl](https://github.com/fullstorydev/grpcurl), and a gRPC request for `MyQuery` using this client looks like: + +```bash +grpcurl \ + -plaintext # We want results in plain test + -import-path ./proto \ # Import these .proto files + -proto ./proto/cosmos/staking/v1beta1/query.proto \ # Look into this .proto file for the Query protobuf service + -d '{"address":"$MY_DELEGATOR"}' \ # Query arguments + localhost:9090 \ # gRPC server endpoint + cosmos.staking.v1beta1.Query/Delegations # Fully-qualified service method name +``` + +### REST + +Another interface through which users can make queries is through HTTP Requests to a [REST server](../core/grpc_rest.md#rest-server). The REST server is fully auto-generated from Protobuf services, using [gRPC-gateway](https://github.com/grpc-ecosystem/grpc-gateway). + +An example HTTP request for `MyQuery` looks like: + +```bash +GET http://localhost:1317/cosmos/staking/v1beta1/delegators/{delegatorAddr}/delegations +``` + +## How Queries are Handled by the CLI + +The examples above show how an external user can interact with a node by querying its state. To understand more in details the exact lifecycle of a query, let's dig into how the CLI prepares the query, and how the node handles it. The interactions from the users' perspective are a bit different, but the underlying functions are almost identical because they are implementations of the same command defined by the module developer. This step of processing happens within the CLI, gRPC or REST server and heavily involves a `client.Context`. + +### Context + +The first thing that is created in the execution of a CLI command is a `client.Context`. A `client.Context` is an object that stores all the data needed to process a request on the user side. In particular, a `client.Context` stores the following: + +* **Codec**: The [encoder/decoder](../core/encoding.md) used by the application, used to marshal the parameters and query before making the Tendermint RPC request and unmarshal the returned response into a JSON object. The default codec used by the CLI is Protobuf. +* **Account Decoder**: The account decoder from the [`auth`](../../x/auth/spec/README.md) module, which translates `[]byte`s into accounts. +* **RPC Client**: The Tendermint RPC Client, or node, to which the request will be relayed to. +* **Keyring**: A [Key Manager](../basics/accounts.md#keyring) used to sign transactions and handle other operations with keys. +* **Output Writer**: A [Writer](https://pkg.go.dev/io/#Writer) used to output the response. +* **Configurations**: The flags configured by the user for this command, including `--height`, specifying the height of the blockchain to query and `--indent`, which indicates to add an indent to the JSON response. + +The `client.Context` also contains various functions such as `Query()` which retrieves the RPC Client and makes an ABCI call to relay a query to a full-node. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/client/context.go#L25-L63 + +The `client.Context`'s primary role is to store data used during interactions with the end-user and provide methods to interact with this data - it is used before and after the query is processed by the full-node. Specifically, in handling `MyQuery`, the `client.Context` is utilized to encode the query parameters, retrieve the full-node, and write the output. Prior to being relayed to a full-node, the query needs to be encoded into a `[]byte` form, as full-nodes are application-agnostic and do not understand specific types. The full-node (RPC Client) itself is retrieved using the `client.Context`, which knows which node the user CLI is connected to. The query is relayed to this full-node to be processed. Finally, the `client.Context` contains a `Writer` to write output when the response is returned. These steps are further described in later sections. + +### Arguments and Route Creation + +At this point in the lifecycle, the user has created a CLI command with all of the data they wish to include in their query. A `client.Context` exists to assist in the rest of the `MyQuery`'s journey. Now, the next step is to parse the command or request, extract the arguments, and encode everything. These steps all happen on the user side within the interface they are interacting with. + +#### Encoding + +In our case (querying an address's delegations), `MyQuery` contains an [address](./accounts.md#addresses) `delegatorAddress` as its only argument. However, the request can only contain `[]byte`s, as it will be relayed to a consensus engine (e.g. Tendermint Core) of a full-node that has no inherent knowledge of the application types. Thus, the `codec` of `client.Context` is used to marshal the address. + +Here is what the code looks like for the CLI command: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/staking/client/cli/query.go#L323-L326 + +#### gRPC Query Client Creation + +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: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/staking/client/cli/query.go#L317-L341 + +Under the hood, the `client.Context` has a `Query()` function used to retrieve the pre-configured node and relay a query to it; the function takes the query fully-qualified service method name as path (in our case: `/cosmos.staking.v1beta1.Query/Delegations`), and arguments as parameters. It first retrieves the RPC Client (called the [**node**](../core/node.md)) configured by the user to relay this query to, and creates the `ABCIQueryOptions` (parameters formatted for the ABCI call). The node is then used to make the ABCI call, `ABCIQueryWithOptions()`. + +Here is what the code looks like: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/client/query.go#L80-L114 + +## RPC + +With a call to `ABCIQueryWithOptions()`, `MyQuery` is received by a [full-node](../core/encoding.md) which will then process the request. Note that, while the RPC is made to the consensus engine (e.g. Tendermint Core) of a full-node, queries are not part of consensus and will not be broadcasted to the rest of the network, as they do not require anything the network needs to agree upon. + +Read more about ABCI Clients and Tendermint RPC in the [Tendermint documentation](https://docs.tendermint.com/master/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 matches the fully-qualified service method name of an existing service method (most likely in one of the modules), then `baseapp` will relay the request to the relevant module. + +Apart from gRPC routes, `baseapp` also handles four different types of queries: `app`, `store`, `p2p`, and `custom`. The first three types (`app`, `store`, `p2p`) are purely application-level and thus directly handled by `baseapp` or the stores, but the `custom` query type requires `baseapp` to route the query to a module's [legacy queriers](../building-modules/query-services.md#legacy-queriers). To learn more about these queries, please refer to [this guide](../core/grpc_rest.md#tendermint-rpc). + +Since `MyQuery` has a Protobuf fully-qualified service method name from the `staking` module (recall `/cosmos.staking.v1beta1.Query/Delegations`), `baseapp` first parses the path, then uses its own internal `GRPCQueryRouter` to retrieve the corresponding gRPC handler, and routes the query to the module. The gRPC handler is responsible for recognizing this query, retrieving the appropriate values from the application's stores, and returning a response. Read more about query services [here](../building-modules/query-services.md). + +Once a result is received from the querier, `baseapp` begins the process of returning a response to the user. + +## Response + +Since `Query()` is an ABCI function, `baseapp` returns the response as an [`abci.ResponseQuery`](https://docs.tendermint.com/master/spec/abci/abci.html#query-2) type. The `client.Context` `Query()` routine receives the response and. + +### CLI Response + +The application [`codec`](../core/encoding.md) is used to unmarshal the response to a JSON and the `client.Context` prints the output to the command line, applying any configurations such as the output type (text, JSON or YAML). + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/client/context.go#L315-L343 + +And that's a wrap! The result of the query is outputted to the console by the CLI. + +## Next {hide} + +Read more about [accounts](./accounts.md). {hide} diff --git a/versioned_docs/version-0.46/develop/high-level-concepts/tx-lifecycle.md b/versioned_docs/version-0.46/develop/high-level-concepts/tx-lifecycle.md new file mode 100644 index 000000000..efb59e1a0 --- /dev/null +++ b/versioned_docs/version-0.46/develop/high-level-concepts/tx-lifecycle.md @@ -0,0 +1,257 @@ + + +# Transaction Lifecycle + +This document describes the lifecycle of a transaction from creation to committed state changes. Transaction definition is described in a [different doc](../core/transactions.md). The transaction will be referred to as `Tx`. {synopsis} + +## Pre-requisite Readings + +* [Anatomy of a Cosmos SDK Application](./app-anatomy.md) {prereq} + +## Creation + +### Transaction Creation + +One of the main application interfaces is the command-line interface. The transaction `Tx` can be created by the user inputting a command in the following format from the [command-line](../core/cli.md), providing the type of transaction in `[command]`, arguments in `[args]`, and configurations such as gas prices in `[flags]`: + +```bash +[appname] tx [command] [args] [flags] +``` + +This command will automatically **create** the transaction, **sign** it using the account's private key, and **broadcast** it to the specified peer node. + +There are several required and optional flags for transaction creation. The `--from` flag specifies which [account](./accounts.md) the transaction is originating from. For example, if the transaction is sending coins, the funds will be drawn from the specified `from` address. + +#### Gas and Fees + +Additionally, there are several [flags](../core/cli.md) users can use to indicate how much they are willing to pay in [fees](./gas-fees.md): + +* `--gas` refers to how much [gas](./gas-fees.md), which represents computational resources, `Tx` consumes. Gas is dependent on the transaction and is not precisely calculated until execution, but can be estimated by providing `auto` as the value for `--gas`. +* `--gas-adjustment` (optional) can be used to scale `gas` up in order to avoid underestimating. For example, users can specify their gas adjustment as 1.5 to use 1.5 times the estimated gas. +* `--gas-prices` specifies how much the user is willing to pay per unit of gas, which can be one or multiple denominations of tokens. For example, `--gas-prices=0.025uatom, 0.025upho` means the user is willing to pay 0.025uatom AND 0.025upho per unit of gas. +* `--fees` specifies how much in fees the user is willing to pay in total. +* `--timeout-height` specifies a block timeout height to prevent the tx from being committed past a certain height. + +The ultimate value of the fees paid is equal to the gas multiplied by the gas prices. In other words, `fees = ceil(gas * gasPrices)`. Thus, since fees can be calculated using gas prices and vice versa, the users specify only one of the two. + +Later, validators decide whether or not to include the transaction in their block by comparing the given or calculated `gas-prices` to their local `min-gas-prices`. `Tx` will be rejected if its `gas-prices` is not high enough, so users are incentivized to pay more. + +#### CLI Example + +Users of the application `app` can enter the following command into their CLI to generate a transaction to send 1000uatom from a `senderAddress` to a `recipientAddress`. It specifies how much gas they are willing to pay: an automatic estimate scaled up by 1.5 times, with a gas price of 0.025uatom per unit gas. + +```bash +appd tx send 1000uatom --from --gas auto --gas-adjustment 1.5 --gas-prices 0.025uatom +``` + +#### Other Transaction Creation Methods + +The command-line is an easy way to interact with an application, but `Tx` can also be created using a [gRPC or REST interface](../core/grpc_rest.md) or some other entry point defined by the application developer. From the user's perspective, the interaction depends on the web interface or wallet they are using (e.g. creating `Tx` using [Lunie.io](https://lunie.io/#/) and signing it with a Ledger Nano S). + +## Addition to Mempool + +Each full-node (running Tendermint) that receives a `Tx` sends an [ABCI message](https://docs.tendermint.com/master/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://docs.tendermint.com/master/tendermint-core/mempool/), an in-memory pool of transactions unique to each node, pending inclusion in a block - honest nodes will discard `Tx` if it is found to be invalid. Prior to consensus, nodes continuously check incoming transactions and gossip them to their peers. + +### Types of Checks + +The full-nodes perform stateless, then stateful checks on `Tx` during `CheckTx`, with the goal to +identify and reject an invalid transaction as early on as possible to avoid wasted computation. + +**_Stateless_** checks do not require nodes to access state - light clients or offline nodes can do +them - and are thus less computationally expensive. Stateless checks include making sure addresses +are not empty, enforcing nonnegative numbers, and other logic specified in the definitions. + +**_Stateful_** checks validate transactions and messages based on a committed state. Examples +include checking that the relevant values exist and can 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#state-updates) +of the application's internal state for different purposes. For example, nodes will execute state +changes while in the process of verifying transactions, but still need a copy of the last committed +state in order to answer queries - they should not respond using state with uncommitted changes. + +In order to verify a `Tx`, full-nodes call `CheckTx`, which includes both _stateless_ and _stateful_ +checks. Further validation happens later in the [`DeliverTx`](#delivertx) stage. `CheckTx` goes +through several steps, beginning with decoding `Tx`. + +### Decoding + +When `Tx` is received by the application from the underlying consensus engine (e.g. Tendermint), it is still in its [encoded](../core/encoding.md) `[]byte` form and needs to be unmarshaled in order to be processed. Then, the [`runTx`](../core/baseapp.md#runtx-antehandler-runmsgs-posthandler) function is called to run in `runTxModeCheck` mode, meaning the function will run all checks but exit before executing messages and writing state changes. + +### ValidateBasic + +Messages ([`sdk.Msg`](../core/transactions.md#messages)) are extracted from transactions (`Tx`). The `ValidateBasic` method of the `sdk.Msg` interface implemented by the module developer is run for each transaction. +To discard obviously invalid messages, the `BaseApp` type calls the `ValidateBasic` method very early in the processing of the message in the [`CheckTx`](../core/baseapp.md#checktx) and [`DeliverTx`](../core/baseapp.md#delivertx) transactions. +`ValidateBasic` can include only **stateless** checks (the checks that do not require access to the state). + +#### Guideline + +Gas is not charged when `ValidateBasic` is executed, so we recommend only performing all necessary stateless checks to enable middleware operations (for example, parsing the required signer accounts to validate a signature by a middleware) and stateless sanity checks not impacting performance of the CheckTx phase. +Other validation operations must be performed when [handling a message](../building-modules/msg-services#Validation) in a module Msg Server. + +Example, if the message is to send coins from one address to another, `ValidateBasic` likely checks for non-empty addresses and a non-negative coin amount, but does not require knowledge of state such as the account balance of an address. + +See also [Msg Service Validation](../building-modules/msg-services.md#Validation). + +### AnteHandler + +After the ValidateBasic checks, the `AnteHandler`s are run. Technically, they are optional, but in practice, they are very often present to perform signature verification, gas calculation, fee deduction and other core operations related to blockchain transactions. + +A copy of the cached context is provided to the `AnteHandler`, which performs limited checks specified for the transaction type. Using a copy allows the `AnteHandler` to do stateful checks for `Tx` without modifying the last committed state, and revert back to the original if the execution fails. + +For example, the [`auth`](https://github.com/cosmos/cosmos-sdk/tree/main/x/auth/spec) module `AnteHandler` checks and increments sequence numbers, checks signatures and account numbers, and deducts fees from the first signer of the transaction - all state changes are made using the `checkState`. + +### Gas + +The [`Context`](../core/context.md), which keeps a `GasMeter` that will track how much gas has been used during the execution of `Tx`, is initialized. The user-provided amount of gas for `Tx` is known as `GasWanted`. If `GasConsumed`, the amount of gas consumed so during execution, ever exceeds `GasWanted`, the execution will stop and the changes made to the cached copy of the state won't be committed. Otherwise, `CheckTx` sets `GasUsed` equal to `GasConsumed` and returns it in the result. After calculating the gas and fee values, validator-nodes check that the user-specified `gas-prices` is greater than their locally defined `min-gas-prices`. + +### Discard or Addition to Mempool + +If at any point during `CheckTx` the `Tx` fails, it is discarded and the transaction lifecycle ends +there. Otherwise, if it passes `CheckTx` successfully, the default protocol is to relay it to peer +nodes and add it to the Mempool so that the `Tx` becomes a candidate to be included in the next block. + +The **mempool** serves the purpose of keeping track of transactions seen by all full-nodes. +Full-nodes keep a **mempool cache** of the last `mempool.cache_size` transactions they have seen, as a first line of +defense to prevent replay attacks. Ideally, `mempool.cache_size` is large enough to encompass all +of the transactions in the full mempool. If the mempool cache is too small to keep track of all +the transactions, `CheckTx` is responsible for identifying and rejecting replayed transactions. + +Currently existing preventative measures include fees and a `sequence` (nonce) counter to distinguish +replayed transactions from identical but valid ones. If an attacker tries to spam nodes with many +copies of a `Tx`, full-nodes keeping a mempool cache will reject identical copies instead of running +`CheckTx` on all of them. Even if the copies have incremented `sequence` numbers, attackers are +disincentivized by the need to pay fees. + +Validator nodes keep a mempool to prevent replay attacks, just as full-nodes do, but also use it as +a pool of unconfirmed transactions in preparation of block inclusion. Note that even if a `Tx` +passes all checks at this stage, it is still possible to be found invalid later on, because +`CheckTx` does not fully validate the transaction (i.e. it does not actually execute the messages). + +## Inclusion in a Block + +Consensus, the process through which validator nodes come to agreement on which transactions to +accept, happens in **rounds**. Each round begins with a proposer creating a block of the most +recent transactions and ends with **validators**, special full-nodes with voting power responsible +for consensus, agreeing to accept the block or go with a `nil` block instead. Validator nodes +execute the consensus algorithm, such as [Tendermint BFT](https://docs.tendermint.com/master/spec/consensus/consensus.html#terms), +confirming the transactions using ABCI requests to the application, in order to come to this agreement. + +The first step of consensus is the **block proposal**. One proposer amongst the validators is chosen +by the consensus algorithm to create and propose a block - in order for a `Tx` to be included, it +must be in this proposer's mempool. + +## State Changes + +The next step of consensus is to execute the transactions to fully validate them. All full-nodes +that receive a block proposal from the correct proposer execute the transactions by calling the ABCI functions +[`BeginBlock`](./app-anatomy.md#beginblocker-and-endblocker), `DeliverTx` for each transaction, +and [`EndBlock`](./app-anatomy.md#beginblocker-and-endblocker). While each full-node runs everything +locally, this process yields a single, unambiguous result, since the messages' state transitions are deterministic and transactions are +explicitly ordered in the block proposal. + +```text + ----------------------- + |Receive Block Proposal| + ----------------------- + | + v + ----------------------- + | BeginBlock | + ----------------------- + | + v + ----------------------- + | DeliverTx(tx0) | + | DeliverTx(tx1) | + | DeliverTx(tx2) | + | DeliverTx(tx3) | + | . | + | . | + | . | + ----------------------- + | + v + ----------------------- + | EndBlock | + ----------------------- + | + v + ----------------------- + | Consensus | + ----------------------- + | + v + ----------------------- + | Commit | + ----------------------- +``` + +### DeliverTx + +The `DeliverTx` ABCI function defined in [`BaseApp`](../core/baseapp.md) does the bulk of the +state transitions: it is run for each transaction in the block in sequential order as committed +to during consensus. Under the hood, `DeliverTx` is almost identical to `CheckTx` but calls the +[`runTx`](../core/baseapp.md#runtx) function in deliver mode instead of check mode. +Instead of using their `checkState`, full-nodes use `deliverState`: + +* **Decoding:** Since `DeliverTx` is an ABCI call, `Tx` is received in the encoded `[]byte` form. + Nodes first unmarshal the transaction, using the [`TxConfig`](./app-anatomy#register-codec) defined in the app, then call `runTx` in `runTxModeDeliver`, which is very similar to `CheckTx` but also executes and writes state changes. + +* **Checks and AnteHandler:** Full-nodes call `validateBasicMsgs` and `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-antehandler-runmsgs-posthandler) 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:** Protobuf `Msg` service is responsible for executing each message in the `Tx` and causes state transitions to persist in `deliverTxState`. + +* **PostHandlers:** [`PostHandler`](../core/baseapp.md#posthandler)s run after the execution of the message. If they fail, the state change of `runMsgs`, as well of `PostHandlers` are both reverted. + +* **Gas:** While a `Tx` is being delivered, a `GasMeter` is used to keep track of how much + gas is being used; if execution completes, `GasUsed` is set and returned in the + `abci.ResponseDeliverTx`. If execution halts because `BlockGasMeter` or `GasMeter` has run out or something else goes + wrong, a deferred function at the end appropriately errors or panics. + +If there are any failed state changes resulting from a `Tx` being invalid or `GasMeter` running out, +the transaction processing terminates and any state changes are reverted. Invalid transactions in a +block proposal cause validator nodes to reject the block and vote for a `nil` block instead. + +### Commit + +The final step is for nodes to commit the block and state changes. Validator nodes +perform the previous step of executing state transitions in order to validate the transactions, +then sign the block to confirm it. Full nodes that are not validators do not +participate in consensus - i.e. they cannot vote - but listen for votes to understand whether or +not they should commit the state changes. + +When they receive enough validator votes (2/3+ _precommits_ weighted by voting power), full nodes commit to a new block to be added to the blockchain and +finalize the state transitions in the application layer. A new state root is generated to serve as +a merkle proof for the state transitions. Applications use the [`Commit`](../core/baseapp.md#commit) +ABCI method inherited from [Baseapp](../core/baseapp.md); it syncs all the state transitions by +writing the `deliverState` into the application's internal state. As soon as the state changes are +committed, `checkState` start afresh from the most recently committed state and `deliverState` +resets to `nil` in order to be consistent and reflect the changes. + +Note that not all blocks have the same number of transactions and it is possible for consensus to +result in a `nil` block or one with none at all. In a public blockchain network, it is also possible +for validators to be **byzantine**, or malicious, which may prevent a `Tx` from being committed in +the blockchain. Possible malicious behaviors include the proposer deciding to censor a `Tx` by +excluding it from the block or a validator voting against the block. + +At this point, the transaction lifecycle of a `Tx` is over: nodes have verified its validity, +delivered it by executing its state changes, and committed those changes. The `Tx` itself, +in `[]byte` form, is stored in a block and appended to the blockchain. + +## Next {hide} + +Learn about [accounts](./accounts.md) {hide} diff --git a/versioned_docs/version-0.46/develop/intro/README.md b/versioned_docs/version-0.46/develop/intro/README.md new file mode 100644 index 000000000..d20de3560 --- /dev/null +++ b/versioned_docs/version-0.46/develop/intro/README.md @@ -0,0 +1,16 @@ + + +# Introduction + +This introduction gives a quick start on the 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) + +After reading the introduction material, head over to the [basics](../basics/README.md) to learn more. diff --git a/versioned_docs/version-0.46/develop/intro/overview.md b/versioned_docs/version-0.46/develop/intro/overview.md new file mode 100644 index 000000000..859f0acce --- /dev/null +++ b/versioned_docs/version-0.46/develop/intro/overview.md @@ -0,0 +1,37 @@ + + +# High-level Overview + +## What is the 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**. + +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). + +## 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 decentralized 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 decentralized platforms. More generally, smart contracts can be limiting in terms of flexibility, sovereignty and performance. + +Application-specific blockchains offer a radically different development paradigm than virtual-machine blockchains. An application-specific blockchain is a blockchain customized to operate a single application: developers have all the freedom to make the design decisions required for the application to run optimally. They can also provide better sovereignty, security and performance. + +Learn more about [application-specific blockchains](./why-app-specific.md). + +## Why the Cosmos SDK + +The Cosmos SDK is the most advanced framework for building custom application-specific blockchains today. Here are a few reasons why you might want to consider building your decentralized application with the 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 decentralized 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. + +## Getting started with the 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) + +## Next {hide} + +Learn about [application-specific blockchains](./why-app-specific.md) {hide} diff --git a/versioned_docs/version-0.46/develop/intro/sdk-app-architecture.md b/versioned_docs/version-0.46/develop/intro/sdk-app-architecture.md new file mode 100644 index 000000000..7a1113683 --- /dev/null +++ b/versioned_docs/version-0.46/develop/intro/sdk-app-architecture.md @@ -0,0 +1,97 @@ + + +# Blockchain Architecture + +## State machine + +At its core, a blockchain is a [replicated deterministic state machine](https://en.wikipedia.org/wiki/State_machine_replication). + +A state machine is a computer science concept whereby a machine can have multiple states, but only one at any given time. There is a `state`, which describes the current state of the system, and `transactions`, that trigger state transitions. + +Given a state S and a transaction T, the state machine will return a new state S'. + +```text ++--------+ +--------+ +| | | | +| S +---------------->+ S' | +| | apply(T) | | ++--------+ +--------+ +``` + +In practice, the transactions are bundled in blocks to make the process more efficient. Given a state S and a block of transactions B, the state machine will return a new state S'. + +```text ++--------+ +--------+ +| | | | +| S +----------------------------> | S' | +| | For each T in B: apply(T) | | ++--------+ +--------+ +``` + +In a blockchain context, the state machine is deterministic. This means that if a node is started at a given state and replays the same sequence of transactions, it will always end up with the same final state. + +The Cosmos SDK gives developers maximum flexibility to define the state of their application, transaction types and state transition functions. The process of building state-machines with the 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**. + +## Tendermint + +Thanks to the Cosmos SDK, developers just have to define the state machine, and [*Tendermint*](https://docs.tendermint.com/master/introduction/what-is-tendermint.html) will handle replication over the network for them. + +```text + ^ +-------------------------------+ ^ + | | | | Built with Cosmos SDK + | | State-machine = Application | | + | | | v + | +-------------------------------+ + | | | ^ +Blockchain node | | Consensus | | + | | | | + | +-------------------------------+ | Tendermint Core + | | | | + | | Networking | | + | | | | + 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. + +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` and a `precommit` on it, and if all the transactions that it contains are valid. The validator set can be changed by rules written in the state-machine. + +## ABCI + +Tendermint passes transactions to the application through an interface called the [ABCI](https://docs.tendermint.com/master/spec/abci/), which the application must implement. + +```text + +---------------------+ + | | + | Application | + | | + +--------+---+--------+ + ^ | + | | ABCI + | v + +--------+---+--------+ + | | + | | + | Tendermint | + | | + | | + +---------------------+ +``` + +Note that **Tendermint only handles transaction bytes**. It has no knowledge of what these bytes mean. All Tendermint does is order these transaction bytes deterministically. Tendermint passes the bytes to the application via the ABCI, and expects a return code to inform it if the messages contained in the transactions were successfully processed or not. + +Here are the most important messages of the ABCI: + +* `CheckTx`: When a transaction is received by Tendermint Core, it is passed to the application to check if a few basic requirements are met. `CheckTx` is used to protect the mempool of full-nodes against spam transactions. . A special handler called the [`AnteHandler`](../basics/gas-fees.md#antehandler) is used to execute a series of validation steps such as checking for sufficient fees and validating the signatures. If the checks are valid, the transaction is added to the [mempool](https://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 transactions or not. It is useful to trigger automatic execution of logic. Proceed with caution though, as computationally expensive loops could slow down your blockchain, or even freeze it if the loop is infinite. + +Find a more detailed view of the ABCI methods from the [Tendermint docs](https://docs.tendermint.com/v0.35/introduction/what-is-tendermint.html#abci-overview). + +Any application built on Tendermint needs to implement the ABCI interface in order to communicate with the underlying local Tendermint engine. Fortunately, you do not have to implement the ABCI interface. The Cosmos SDK provides a boilerplate implementation of it in the form of [baseapp](./sdk-design.md#baseapp). + +## Next {hide} + +Read about the [high-level design principles of the Cosmos SDK](./sdk-design.md) {hide} diff --git a/versioned_docs/version-0.46/develop/intro/sdk-design.md b/versioned_docs/version-0.46/develop/intro/sdk-design.md new file mode 100644 index 000000000..e9f61be4e --- /dev/null +++ b/versioned_docs/version-0.46/develop/intro/sdk-design.md @@ -0,0 +1,97 @@ + + +# Main Components of the Cosmos SDK + +The Cosmos SDK is a framework that facilitates the development of secure state-machines on top of Tendermint. At its core, the 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. + +Here is a simplified view of how transactions are handled by an application built on top of the Cosmos SDK when transferred from Tendermint via `DeliverTx`: + +1. Decode `transactions` received from the Tendermint consensus engine (remember that Tendermint only deals with `[]bytes`). +2. Extract `messages` from `transactions` and do basic sanity checks. +3. Route each message to the appropriate module so that it can be processed. +4. Commit state changes. + +## `baseapp` + +`baseapp` is the boilerplate implementation of a Cosmos SDK application. It comes with an implementation of the ABCI to handle the 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). + +Here is an example of this from `simapp`, the Cosmos SDK demonstration app: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/simapp/app.go#L154-L193 + +The goal of `baseapp` is to provide a secure interface between the store and the extensible state machine while defining as little about the state machine as possible (staying true to the ABCI). + +For more on `baseapp`, please click [here](../core/baseapp.md). + +## Multistore + +The Cosmos SDK provides a [`multistore`](../core/store.md#multistore) for persisting state. The multistore allows developers to declare any number of [`KVStores`](../core/store.md#base-layer-kvstores). These `KVStores` only accept the `[]byte` type as value and therefore any custom structure needs to be marshalled using [a codec](../core/encoding.md) before being stored. + +The multistore abstraction is used to divide the state in distinct compartments, each managed by its own module. For more on the multistore, click [here](../core/store.md#multistore) + +## Modules + +The power of the Cosmos SDK lies in its modularity. 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. + +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: + +```text + + + | + | Transaction relayed from the full-node's + | Tendermint engine to the node's application + | via DeliverTx + | + | + +---------------------v--------------------------+ + | APPLICATION | + | | + | Using baseapp's methods: Decode the Tx, | + | extract and route the message(s) | + | | + +---------------------+--------------------------+ + | + | + | + +---------------------------+ + | + | + | Message routed to + | the correct module + | to be processed + | + | ++----------------+ +---------------+ +----------------+ +------v----------+ +| | | | | | | | +| AUTH MODULE | | BANK MODULE | | STAKING MODULE | | GOV MODULE | +| | | | | | | | +| | | | | | | Handles message,| +| | | | | | | Updates state | +| | | | | | | | ++----------------+ +---------------+ +----------------+ +------+----------+ + | + | + | + | + +--------------------------+ + | + | Return result to Tendermint + | (0=Ok, 1=Err) + v +``` + +Each module can be seen as a little state-machine. Developers need to define the subset of the state handled by the module, as well as custom message types that modify the state (*Note:* `messages` are extracted from `transactions` by `baseapp`). In general, each module declares its own `KVStore` in the `multistore` to persist the subset of the state it defines. Most developers will need to access other 3rd party modules when building their own modules. Given that the Cosmos SDK is an open framework, some of the modules may be malicious, which means there is a need for security principles to reason about inter-module interactions. These principles are based on [object-capabilities](../core/ocap.md). In practice, this means that instead of having each module keep an access control list for other modules, each module implements special objects called `keepers` that can be passed to other modules to grant a pre-defined set of capabilities. + +Cosmos SDK modules are defined in the `x/` folder of the Cosmos SDK. Some core modules include: + +* `x/auth`: Used to manage accounts and signatures. +* `x/bank`: Used to enable tokens and token transfers. +* `x/staking` + `x/slashing`: Used to build Proof-Of-Stake blockchains. + +In addition to the already existing modules in `x/`, that anyone can use in their app, the Cosmos SDK lets you build your own custom modules. You can check an [example of that in the tutorial](https://tutorials.cosmos.network/). + +## Next {hide} + +Learn more about the [anatomy of a Cosmos SDK application](../basics/app-anatomy.md) {hide} diff --git a/versioned_docs/version-0.46/develop/intro/why-app-specific.md b/versioned_docs/version-0.46/develop/intro/why-app-specific.md new file mode 100644 index 000000000..91e84ce0c --- /dev/null +++ b/versioned_docs/version-0.46/develop/intro/why-app-specific.md @@ -0,0 +1,81 @@ + + +# 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 decentralized 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. + +```text + ^ +-------------------------------+ ^ + | | | | Built with Cosmos SDK + | | State-machine = Application | | + | | | v + | +-------------------------------+ + | | | ^ +Blockchain node | | Consensus | | + | | | | + | +-------------------------------+ | Tendermint Core + | | | | + | | Networking | | + | | | | + v +-------------------------------+ v +``` + +## What are the shortcomings of Smart Contracts + +Virtual-machine blockchains like Ethereum addressed the demand for more programmability back in 2014. At the time, the options available for building decentralized applications were quite limited. Most developers would build on top of the complex and limited Bitcoin scripting language, or fork the Bitcoin codebase which was hard to work with and customize. + +Virtual-machine blockchains came in with a new value proposition. Their state-machine incorporates a virtual-machine that is able to interpret turing-complete programs called Smart Contracts. These Smart Contracts are very good for use cases like one-time events (e.g. ICOs), but they can fall short for building complex decentralized platforms. Here is why: + +* Smart Contracts are generally developed with specific programming languages that can be interpreted by the underlying virtual-machine. These programming languages are often immature and inherently limited by the constraints of the virtual-machine itself. For example, the Ethereum Virtual Machine does not allow developers to implement automatic execution of code. Developers are also limited to the account-based system of the EVM, and they can only choose from a limited set of functions for their cryptographic operations. These are examples, but they hint at the lack of **flexibility** that a smart contract environment often entails. +* Smart Contracts are all run by the same virtual machine. This means that they compete for resources, which can 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 interpreted 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 decentralized application is an ecosystem that involves multiple players. If the application is built on a general-purpose virtual-machine blockchain, stakeholders have very limited sovereignty over their application, and are ultimately superseded by the governance of the underlying blockchain. If there is a bug in the application, very little can be done about it. + +Application-Specific Blockchains are designed to address these shortcomings. + +## Application-Specific Blockchains Benefits + +### Flexibility + +Application-specific blockchains give maximum flexibility to developers: + +* In Cosmos blockchains, the state-machine is typically connected to the underlying consensus engine via an interface called the [ABCI](https://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. + +* 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. + +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. + +### Performance + +decentralized applications built with Smart Contracts are inherently capped in performance by the underlying environment. For a decentralized application to optimise performance, it needs to be built as an application-specific blockchain. Next are some of the benefits an application-specific blockchain brings in terms of performance: + +* Developers of application-specific blockchains can choose to operate with a novel consensus engine such as 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. + +### 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 Go when building their application-specific blockchains, as opposed to smart contract programming languages that are often more immature. +* Developers are not constrained by the cryptographic functions made available by the underlying virtual-machines. They can use their own custom cryptography, and rely on well-audited crypto libraries. +* Developers do not have to worry about potential bugs or exploitable mechanisms in the underlying virtual-machine, making it easier to reason about the security of the application. + +### Sovereignty + +One of the major benefits of application-specific blockchains is sovereignty. A decentralized application is an ecosystem that involves many actors: users, developers, third-party services, and more. When developers build on virtual-machine blockchain where many decentralized 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} + +Learn more about the [high-level architecture](./sdk-app-architecture.md) of a Cosmos SDK application {hide} diff --git a/versioned_docs/version-0.46/integrate/CosmWasm/README.md b/versioned_docs/version-0.46/integrate/CosmWasm/README.md new file mode 100644 index 000000000..b6a14810b --- /dev/null +++ b/versioned_docs/version-0.46/integrate/CosmWasm/README.md @@ -0,0 +1,13 @@ + + +# CosmWasm smart contracts + +>CosmWasm is a smart contracting platform built for the Cosmos ecosystem. Simply put, it's the Cosmos (Cosm) way of using WebAssembly (Wasm) hence the name. + +>CosmWasm is written as a module that can plug into the Cosmos SDK. This means that anyone currently building a blockchain using the Cosmos SDK can quickly and easily add CosmWasm smart contracting support to their chain, without adjusting existing logic. + +Read more about writing smart contracts with CosmWasm at their [documentation site](https://book.cosmwasm.com/), or visit [the repository](https://github.com/CosmWasm/cosmwasm). diff --git a/versioned_docs/version-0.46/integrate/architecture/PROCESS.md b/versioned_docs/version-0.46/integrate/architecture/PROCESS.md new file mode 100644 index 000000000..c5140bbe4 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/PROCESS.md @@ -0,0 +1,56 @@ +# ADR Creation Process + +1. Copy the `adr-template.md` file. Use the following filename pattern: `adr-next_number-title.md` +2. Create a draft Pull Request if you want to get an early feedback. +3. Make sure the context and a solution is clear and well documented. +4. Add an entry to a list in the [README](./README.md) file. +5. Create a Pull Request to propose a new ADR. + +## ADR life cycle + +ADR creation is an **iterative** process. Instead of trying to solve all decisions in a single ADR pull request, we MUST firstly understand the problem and collect feedback through a GitHub Issue. + +1. Every proposal SHOULD start with a new GitHub Issue or be a result of existing Issues. The Issue should contain just a brief proposal summary. + +2. Once the motivation is validated, a GitHub Pull Request (PR) is created with a new document based on the `adr-template.md`. + +3. An ADR doesn't have to arrive to `main` with an _accepted_ status in a single PR. If the motivation is clear and the solution is sound, we SHOULD be able to merge it and keep a _proposed_ status. It's preferable to have an iterative approach rather than long, not merged Pull Requests. + +4. If a _proposed_ ADR is merged, then it should clearly document outstanding issues either in ADR document notes or in a GitHub Issue. + +5. The PR SHOULD always be merged. In the case of a faulty ADR, we still prefer to merge it with a _rejected_ status. The only time the ADR SHOULD NOT be merged is if the author abandons it. + +6. Merged ADRs SHOULD NOT be pruned. + +### ADR status + +Status has two components: + +```text +{CONSENSUS STATUS} {IMPLEMENTATION STATUS} +``` + +IMPLEMENTATION STATUS is either `Implemented` or `Not Implemented`. + +#### Consensus Status + +```text +DRAFT -> PROPOSED -> LAST CALL yyyy-mm-dd -> ACCEPTED | REJECTED -> SUPERSEDED by ADR-xxx + \ | + \ | + v v + ABANDONED +``` + +* `DRAFT`: [optional] an ADR which is work in progress, not being ready for a general review. This is to present an early work and get an early feedback in a Draft Pull Request form. +* `PROPOSED`: an ADR covering a full solution architecture and still in the review - project stakeholders haven't reached an agreed yet. +* `LAST CALL `: [optional] clear notify that we are close to accept updates. Changing a status to `LAST CALL` means that social consensus (of Cosmos SDK maintainers) has been reached and we still want to give it a time to let the community react or analyze. +* `ACCEPTED`: ADR which will represent a currently implemented or to be implemented architecture design. +* `REJECTED`: ADR can go from PROPOSED or ACCEPTED to rejected if the consensus among project stakeholders will decide so. +* `SUPERSEEDED by ADR-xxx`: ADR which has been superseded by a new ADR. +* `ABANDONED`: the ADR is no longer pursued by the original authors. + +## Language used in ADR + +* The context/background should be written in the present tense. +* Avoid using a first, personal form. diff --git a/versioned_docs/version-0.46/integrate/architecture/README.md b/versioned_docs/version-0.46/integrate/architecture/README.md new file mode 100644 index 000000000..4257d1e87 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/README.md @@ -0,0 +1,87 @@ +--- +order: false +parent: + order: false +--- + +# Architecture Decision Records (ADR) + +This is a location to record all high-level architecture decisions in the Cosmos-SDK. + +An Architectural Decision (**AD**) is a software design choice that addresses a functional or non-functional requirement that is architecturally significant. +An Architecturally Significant Requirement (**ASR**) is a requirement that has a measurable effect on a software system’s architecture and quality. +An Architectural Decision Record (**ADR**) captures a single AD, such as often done when writing personal notes or meeting minutes; the collection of ADRs created and maintained in a project constitute its decision log. All these are within the topic of Architectural Knowledge Management (AKM). + +You can read more about the ADR concept in this [blog post](https://product.reverb.com/documenting-architecture-decisions-the-reverb-way-a3563bb24bd0#.78xhdix6t). + +## Rationale + +ADRs are intended to be the primary mechanism for proposing new feature designs and new processes, for collecting community input on an issue, and for documenting the design decisions. +An ADR should provide: + +* Context on the relevant goals and the current state +* Proposed changes to achieve the goals +* Summary of pros and cons +* References +* Changelog + +Note the distinction between an ADR and a spec. The ADR provides the context, intuition, reasoning, and +justification for a change in architecture, or for the architecture of something +new. The spec is much more compressed and streamlined summary of everything as +it stands today. + +If recorded decisions turned out to be lacking, convene a discussion, record the new decisions here, and then modify the code to match. + +## Creating new ADR + +Read about the [PROCESS](./PROCESS.md). + +### Use RFC 2119 Keywords + +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 Table of Contents + +### 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 055: ORM](./adr-055-orm.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) + +### Draft + +- [ADR 044: Guidelines for Updating Protobuf Definitions](./adr-044-protobuf-updates-guidelines.md) +- [ADR 047: Extend Upgrade Plan](./adr-047-extend-upgrade-plan.md) +- [ADR 053: Go Module Refactoring](./adr-053-go-module-refactoring.md) diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-002-docs-structure.md b/versioned_docs/version-0.46/integrate/architecture/adr-002-docs-structure.md new file mode 100644 index 000000000..5819151fc --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-002-docs-structure.md @@ -0,0 +1,86 @@ +# ADR 002: SDK Documentation Structure + +## 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. + +Ideally, we would have: + +* All docs related to dev frameworks or tools live in their respective github repos (sdk repo would contain sdk docs, hub repo would contain hub docs, lotion repo would contain lotion docs, etc.) +* All other docs (faqs, whitepaper, high-level material about Cosmos) would live on the website. + +## Decision + +Re-structure the `/docs` folder of the Cosmos SDK github repo as follows: + +```text +docs/ +├── README +├── intro/ +├── concepts/ +│ ├── baseapp +│ ├── types +│ ├── store +│ ├── server +│ ├── modules/ +│ │ ├── keeper +│ │ ├── handler +│ │ ├── cli +│ ├── gas +│ └── commands +├── clients/ +│ ├── lite/ +│ ├── service-providers +├── modules/ +├── spec/ +├── translations/ +└── architecture/ +``` + +The files in each sub-folders do not matter and will likely change. What matters is the sectioning: + +* `README`: Landing page of the docs. +* `intro`: Introductory material. Goal is to have a short explainer of the 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. + +Website docs sidebar will only include the following sections: + +* `README` +* `intro` +* `concepts` +* `clients` + +`architecture` need not be displayed on the website. + +## Status + +Accepted + +## Consequences + +### Positive + +* Much clearer organisation of the 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) + +### Neutral + +* We need to move a bunch of deprecated stuff to `/_attic` folder. +* We need to integrate content in `docs/sdk/docs/core` in `concepts`. +* We need to move all the content that currently lives in `docs` and does not fit in new structure (like `lotion`, intro material, whitepaper) to the website repository. +* Update `DOCS_README.md` + +## References + +* https://github.com/cosmos/cosmos-sdk/issues/1460 +* https://github.com/cosmos/cosmos-sdk/pull/2695 +* https://github.com/cosmos/cosmos-sdk/issues/2611 diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-003-dynamic-capability-store.md b/versioned_docs/version-0.46/integrate/architecture/adr-003-dynamic-capability-store.md new file mode 100644 index 000000000..4ec3f1a61 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-003-dynamic-capability-store.md @@ -0,0 +1,344 @@ +# ADR 3: Dynamic Capability Store + +## Changelog + +* 12 December 2019: Initial version +* 02 April 2020: Memory Store Revisions + +## Context + +Full implementation of the [IBC specification](https://github.com/cosmos/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. + +At present, the Cosmos SDK does not have the ability to do this. Object-capability keys are currently pointers (memory addresses) of `StoreKey` structs created at application initialisation in `app.go` ([example](https://github.com/cosmos/gaia/blob/dcbddd9f04b3086c0ad07ee65de16e7adedc7da4/app/app.go#L132)) +and passed to Keepers as fixed arguments ([example](https://github.com/cosmos/gaia/blob/dcbddd9f04b3086c0ad07ee65de16e7adedc7da4/app/app.go#L160)). Keepers cannot create or store capability keys during transaction execution — although they could call `NewKVStoreKey` and take the memory address +of the returned struct, storing this in the Merklised store would result in a consensus fault, since the memory address will be different on each machine (this is intentional — were this not the case, the keys would be predictable and couldn't serve as object capabilities). + +Keepers need a way to keep a private map of store keys which can be altered during transaction execution, along with a suitable mechanism for regenerating the unique memory addresses (capability keys) in this map whenever the application is started or restarted, along with a mechanism to revert capability creation on tx failure. +This ADR proposes such an interface & mechanism. + +## Decision + +The 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. + +When the initial state is loaded from disk, the `CapabilityKeeper`'s `Initialise` function will create +new capability keys for all previously allocated capability identifiers (allocated during execution of +past transactions and assigned to particular modes), and keep them in a memory-only store while the +chain is running. + +The `CapabilityKeeper` will include a persistent `KVStore`, a `MemoryStore`, and an in-memory map. +The persistent `KVStore` tracks which capability is owned by which modules. +The `MemoryStore` stores a forward mapping that map from module name, capability tuples to capability names and +a reverse mapping that map from module name, capability name to the capability index. +Since we cannot marshal the capability into a `KVStore` and unmarshal without changing the memory location of the capability, +the reverse mapping in the KVStore will simply map to an index. This index can then be used as a key in the ephemeral +go-map to retrieve the capability at the original memory location. + +The `CapabilityKeeper` will define the following types & functions: + +The `Capability` is similar to `StoreKey`, but has a globally unique `Index()` instead of +a name. A `String()` method is provided for debugging. + +A `Capability` is simply a struct, the address of which is taken for the actual capability. + +```golang +type Capability struct { + index uint64 +} +``` + +A `CapabilityKeeper` contains a persistent store key, memory store key, and mapping of allocated module names. + +```golang +type CapabilityKeeper struct { + persistentKey StoreKey + memKey StoreKey + capMap map[uint64]*Capability + moduleNames map[string]interface{} + sealed bool +} +``` + +The `CapabilityKeeper` provides the ability to create *scoped* sub-keepers which are tied to a +particular module name. These `ScopedCapabilityKeeper`s must be created at application initialisation +and passed to modules, which can then use them to claim capabilities they receive and retrieve +capabilities which they own by name, in addition to creating new capabilities & authenticating capabilities +passed by other modules. + +```golang +type ScopedCapabilityKeeper struct { + persistentKey StoreKey + memKey StoreKey + capMap map[uint64]*Capability + moduleName string +} +``` + +`ScopeToModule` is used to create a scoped sub-keeper with a particular name, which must be unique. +It MUST be called before `InitialiseAndSeal`. + +```golang +func (ck CapabilityKeeper) ScopeToModule(moduleName string) ScopedCapabilityKeeper { + if k.sealed { + panic("cannot scope to module via a sealed capability keeper") + } + + if _, ok := k.scopedModules[moduleName]; ok { + panic(fmt.Sprintf("cannot create multiple scoped keepers for the same module name: %s", moduleName)) + } + + k.scopedModules[moduleName] = struct{}{} + + return ScopedKeeper{ + cdc: k.cdc, + storeKey: k.storeKey, + memKey: k.memKey, + capMap: k.capMap, + module: moduleName, + } +} +``` + +`InitialiseAndSeal` MUST be called exactly once, after loading the initial state and creating all +necessary `ScopedCapabilityKeeper`s, in order to populate the memory store with newly-created +capability keys in accordance with the keys previously claimed by particular modules and prevent the +creation of any new `ScopedCapabilityKeeper`s. + +```golang +func (ck CapabilityKeeper) InitialiseAndSeal(ctx Context) { + if ck.sealed { + panic("capability keeper is sealed") + } + + persistentStore := ctx.KVStore(ck.persistentKey) + map := ctx.KVStore(ck.memKey) + + // initialise memory store for all names in persistent store + for index, value := range persistentStore.Iter() { + capability = &CapabilityKey{index: index} + + for moduleAndCapability := range value { + moduleName, capabilityName := moduleAndCapability.Split("/") + memStore.Set(moduleName + "/fwd/" + capability, capabilityName) + memStore.Set(moduleName + "/rev/" + capabilityName, index) + + ck.capMap[index] = capability + } + } + + ck.sealed = true +} +``` + +`NewCapability` can be called by any module to create a new unique, unforgeable object-capability +reference. The newly created capability is automatically persisted; the calling module need not +call `ClaimCapability`. + +```golang +func (sck ScopedCapabilityKeeper) NewCapability(ctx Context, name string) (Capability, error) { + // check name not taken in memory store + if capStore.Get("rev/" + name) != nil { + return nil, errors.New("name already taken") + } + + // fetch the current index + index := persistentStore.Get("index") + + // create a new capability + capability := &CapabilityKey{index: index} + + // set persistent store + persistentStore.Set(index, Set.singleton(sck.moduleName + "/" + name)) + + // update the index + index++ + persistentStore.Set("index", index) + + // set forward mapping in memory store from capability to name + memStore.Set(sck.moduleName + "/fwd/" + capability, name) + + // set reverse mapping in memory store from name to index + memStore.Set(sck.moduleName + "/rev/" + name, index) + + // set the in-memory mapping from index to capability pointer + capMap[index] = capability + + // return the newly created capability + return capability +} +``` + +`AuthenticateCapability` can be called by any module to check that a capability +does in fact correspond to a particular name (the name can be untrusted user input) +with which the calling module previously associated it. + +```golang +func (sck ScopedCapabilityKeeper) AuthenticateCapability(name string, capability Capability) bool { + // return whether forward mapping in memory store matches name + return memStore.Get(sck.moduleName + "/fwd/" + capability) === name +} +``` + +`ClaimCapability` allows a module to claim a capability key which it has received from another module +so that future `GetCapability` calls will succeed. + +`ClaimCapability` MUST be called if a module which receives a capability wishes to access it by name +in the future. Capabilities are multi-owner, so if multiple modules have a single `Capability` reference, +they will all own it. + +```golang +func (sck ScopedCapabilityKeeper) ClaimCapability(ctx Context, capability Capability, name string) error { + persistentStore := ctx.KVStore(sck.persistentKey) + + // set forward mapping in memory store from capability to name + memStore.Set(sck.moduleName + "/fwd/" + capability, name) + + // set reverse mapping in memory store from name to capability + memStore.Set(sck.moduleName + "/rev/" + name, capability) + + // update owner set in persistent store + owners := persistentStore.Get(capability.Index()) + owners.add(sck.moduleName + "/" + name) + persistentStore.Set(capability.Index(), owners) +} +``` + +`GetCapability` allows a module to fetch a capability which it has previously claimed by name. +The module is not allowed to retrieve capabilities which it does not own. + +```golang +func (sck ScopedCapabilityKeeper) GetCapability(ctx Context, name string) (Capability, error) { + // fetch the index of capability using reverse mapping in memstore + index := memStore.Get(sck.moduleName + "/rev/" + name) + + // fetch capability from go-map using index + capability := capMap[index] + + // return the capability + return capability +} +``` + +`ReleaseCapability` allows a module to release a capability which it had previously claimed. If no +more owners exist, the capability will be deleted globally. + +```golang +func (sck ScopedCapabilityKeeper) ReleaseCapability(ctx Context, capability Capability) err { + persistentStore := ctx.KVStore(sck.persistentKey) + + name := capStore.Get(sck.moduleName + "/fwd/" + capability) + if name == nil { + return error("capability not owned by module") + } + + // delete forward mapping in memory store + memoryStore.Delete(sck.moduleName + "/fwd/" + capability, name) + + // delete reverse mapping in memory store + memoryStore.Delete(sck.moduleName + "/rev/" + name, capability) + + // update owner set in persistent store + owners := persistentStore.Get(capability.Index()) + owners.remove(sck.moduleName + "/" + name) + if owners.size() > 0 { + // there are still other owners, keep the capability around + persistentStore.Set(capability.Index(), owners) + } else { + // no more owners, delete the capability + persistentStore.Delete(capability.Index()) + delete(capMap[capability.Index()]) + } +} +``` + +### Usage patterns + +#### Initialisation + +Any modules which use dynamic capabilities must be provided a `ScopedCapabilityKeeper` in `app.go`: + +```golang +ck := NewCapabilityKeeper(persistentKey, memoryKey) +mod1Keeper := NewMod1Keeper(ck.ScopeToModule("mod1"), ....) +mod2Keeper := NewMod2Keeper(ck.ScopeToModule("mod2"), ....) + +// other initialisation logic ... + +// load initial state... + +ck.InitialiseAndSeal(initialContext) +``` + +#### Creating, passing, claiming and using capabilities + +Consider the case where `mod1` wants to create a capability, associate it with a resource (e.g. an IBC channel) by name, then pass it to `mod2` which will use it later: + +Module 1 would have the following code: + +```golang +capability := scopedCapabilityKeeper.NewCapability(ctx, "resourceABC") +mod2Keeper.SomeFunction(ctx, capability, args...) +``` + +`SomeFunction`, running in module 2, could then claim the capability: + +```golang +func (k Mod2Keeper) SomeFunction(ctx Context, capability Capability) { + k.sck.ClaimCapability(ctx, capability, "resourceABC") + // other logic... +} +``` + +Later on, module 2 can retrieve that capability by name and pass it to module 1, which will authenticate it against the resource: + +```golang +func (k Mod2Keeper) SomeOtherFunction(ctx Context, name string) { + capability := k.sck.GetCapability(ctx, name) + mod1.UseResource(ctx, capability, "resourceABC") +} +``` + +Module 1 will then check that this capability key is authenticated to use the resource before allowing module 2 to use it: + +```golang +func (k Mod1Keeper) UseResource(ctx Context, capability Capability, resource string) { + if !k.sck.AuthenticateCapability(name, capability) { + return errors.New("unauthenticated") + } + // do something with the resource +} +``` + +If module 2 passed the capability key to module 3, module 3 could then claim it and call module 1 just like module 2 did +(in which case module 1, module 2, and module 3 would all be able to use this capability). + +## Status + +Proposed. + +## Consequences + +### Positive + +* Dynamic capability support. +* Allows CapabilityKeeper to return same capability pointer from go-map while reverting any writes to the persistent `KVStore` and in-memory `MemoryStore` on tx failure. + +### Negative + +* Requires an additional keeper. +* Some overlap with existing `StoreKey` system (in the future they could be combined, since this is a superset functionality-wise). +* Requires an extra level of indirection in the reverse mapping, since MemoryStore must map to index which must then be used as key in a go map to retrieve the actual capability + +### Neutral + +(none known) + +## References + +* [Original discussion](https://github.com/cosmos/cosmos-sdk/pull/5230#discussion_r343978513) diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-004-split-denomination-keys.md b/versioned_docs/version-0.46/integrate/architecture/adr-004-split-denomination-keys.md new file mode 100644 index 000000000..3012901b8 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-004-split-denomination-keys.md @@ -0,0 +1,120 @@ +# ADR 004: Split Denomination Keys + +## Changelog + +* 2020-01-08: Initial version +* 2020-01-09: Alterations to handle vesting accounts +* 2020-01-14: Updates from review feedback +* 2020-01-30: Updates from implementation + +### Glossary + +* denom / denomination key -- unique token identifier. + +## Context + +With permissionless IBC, anyone will be able to send arbitrary denominations to any other account. Currently, all non-zero balances are stored along with the account in an `sdk.Coins` struct, which creates a potential denial-of-service concern, as too many denominations will become expensive to load & store each time the account is modified. See issues [5467](https://github.com/cosmos/cosmos-sdk/issues/5467) and [4982](https://github.com/cosmos/cosmos-sdk/issues/4982) for additional context. + +Simply rejecting incoming deposits after a denomination count limit doesn't work, since it opens up a griefing vector: someone could send a user lots of nonsensical coins over IBC, and then prevent the user from receiving real denominations (such as staking rewards). + +## Decision + +Balances shall be stored per-account & per-denomination under a denomination- and account-unique key, thus enabling O(1) read & write access to the balance of a particular account in a particular denomination. + +### Account interface (x/auth) + +`GetCoins()` and `SetCoins()` will be removed from the account interface, since coin balances will +now be stored in & managed by the bank module. + +The vesting account interface will replace `SpendableCoins` in favor of `LockedCoins` which does +not require the account balance anymore. In addition, `TrackDelegation()` will now accept the +account balance of all tokens denominated in the vesting balance instead of loading the entire +account balance. + +Vesting accounts will continue to store original vesting, delegated free, and delegated +vesting coins (which is safe since these cannot contain arbitrary denominations). + +### Bank keeper (x/bank) + +The following APIs will be added to the `x/bank` keeper: + +* `GetAllBalances(ctx Context, addr AccAddress) Coins` +* `GetBalance(ctx Context, addr AccAddress, denom string) Coin` +* `SetBalance(ctx Context, addr AccAddress, coin Coin)` +* `LockedCoins(ctx Context, addr AccAddress) Coins` +* `SpendableCoins(ctx Context, addr AccAddress) Coins` + +Additional APIs may be added to facilitate iteration and auxiliary functionality not essential to +core functionality or persistence. + +Balances will be stored first by the address, then by the denomination (the reverse is also possible, +but retrieval of all balances for a single account is presumed to be more frequent): + +```golang +var BalancesPrefix = []byte("balances") + +func (k Keeper) SetBalance(ctx Context, addr AccAddress, balance Coin) error { + if !balance.IsValid() { + return err + } + + store := ctx.KVStore(k.storeKey) + balancesStore := prefix.NewStore(store, BalancesPrefix) + accountStore := prefix.NewStore(balancesStore, addr.Bytes()) + + bz := Marshal(balance) + accountStore.Set([]byte(balance.Denom), bz) + + return nil +} +``` + +This will result in the balances being indexed by the byte representation of +`balances/{address}/{denom}`. + +`DelegateCoins()` and `UndelegateCoins()` will be altered to only load each individual +account balance by denomination found in the (un)delegation amount. As a result, +any mutations to the account balance by will made by denomination. + +`SubtractCoins()` and `AddCoins()` will be altered to read & write the balances +directly instead of calling `GetCoins()` / `SetCoins()` (which no longer exist). + +`trackDelegation()` and `trackUndelegation()` will be altered to no longer update +account balances. + +External APIs will need to scan all balances under an account to retain backwards-compatibility. It +is advised that these APIs use `GetBalance` and `SetBalance` instead of `GetAllBalances` when +possible as to not load the entire account balance. + +### Supply module + +The supply module, in order to implement the total supply invariant, will now need +to scan all accounts & call `GetAllBalances` using the `x/bank` Keeper, then sum +the balances and check that they match the expected total supply. + +## Status + +Accepted. + +## Consequences + +### Positive + +* O(1) reads & writes of balances (with respect to the number of denominations for +which an account has non-zero balances). Note, this does not relate to the actual +I/O cost, rather the total number of direct reads needed. + +### Negative + +* Slightly less efficient reads/writes when reading & writing all balances of a +single account in a transaction. + +### Neutral + +None in particular. + +## References + +* Ref: https://github.com/cosmos/cosmos-sdk/issues/4982 +* Ref: https://github.com/cosmos/cosmos-sdk/issues/5467 +* Ref: https://github.com/cosmos/cosmos-sdk/issues/5492 diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-006-secret-store-replacement.md b/versioned_docs/version-0.46/integrate/architecture/adr-006-secret-store-replacement.md new file mode 100644 index 000000000..fe2e25467 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-006-secret-store-replacement.md @@ -0,0 +1,54 @@ +# ADR 006: Secret Store Replacement + +## 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 + +## 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. + +This is not desirable for a number of reasons. Perhaps the biggest reason is insufficient security protection of key material and metadata. Leaking the plain text allows an attacker to surveil what keys a given computer controls via a number of techniques, like compromised dependencies without any privilege execution. This could be followed by a more targeted attack on a particular user/computer. + +All modern desktop computers OS (Ubuntu, Debian, MacOS, Windows) provide a built-in secret store that is designed to allow applications to store information that is isolated from all other applications and requires passphrase entry to access the data. + +We are seeking solution that provides a common abstraction layer to the many different backends and reasonable fallback for minimal platforms that don’t provide a native secret store. + +## Decision + +We recommend replacing the current Keybase backend based on LevelDB with [Keyring](https://github.com/99designs/keyring) by 99 designs. This application is designed to provide a common abstraction and uniform interface between many secret stores and is used by AWS Vault application by 99-designs application. + +This appears to fulfill the requirement of protecting both key material and metadata from rouge software on a user’s machine. + +## Status + +Accepted + +## Consequences + +### Positive + +Increased safety for users. + +### Negative + +Users must manually migrate. + +Testing against all supported backends is difficult. + +Running tests locally on a Mac require numerous repetitive password entries. + +### Neutral + +{neutral consequences} + +## References + +* #4754 Switch secret store to the keyring secret store (original PR by @poldsam) [__CLOSED__] +* #5029 Add support for github.com/99designs/keyring-backed keybases [__MERGED__] +* #5097 Add keys migrate command [__MERGED__] +* #5180 Drop on-disk keybase in favor of keyring [_PENDING_REVIEW_] +* cosmos/gaia#164 Drop on-disk keybase in favor of keyring (gaia's changes) [_PENDING_REVIEW_] diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-007-specialization-groups.md b/versioned_docs/version-0.46/integrate/architecture/adr-007-specialization-groups.md new file mode 100644 index 000000000..58f78abf5 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-007-specialization-groups.md @@ -0,0 +1,177 @@ +# ADR 007: Specialization Groups + +## Changelog + +* 2019 Jul 31: Initial Draft + +## Context + +This idea was first conceived of in order to fulfill the use case of the +creation of a decentralized Computer Emergency Response Team (dCERT), whose +members would be elected by a governing community and would fulfill the role of +coordinating the community under emergency situations. This thinking +can be further abstracted into the conception of "blockchain specialization +groups". + +The creation of these groups are the beginning of specialization capabilities +within a wider blockchain community which could be used to enable a certain +level of delegated responsibilities. Examples of specialization which could be +beneficial to a blockchain community include: code auditing, emergency response, +code development etc. This type of community organization paves the way for +individual stakeholders to delegate votes by issue type, if in the future +governance proposals include a field for issue type. + +## Decision + +A specialization group can be broadly broken down into the following functions +(herein containing examples): + +* Membership Admittance +* Membership Acceptance +* Membership Revocation + * (probably) Without Penalty + * member steps down (self-Revocation) + * replaced by new member from governance + * (probably) With Penalty + * due to breach of soft-agreement (determined through governance) + * due to breach of hard-agreement (determined by code) +* Execution of Duties + * Special transactions which only execute for members of a specialization + group (for example, dCERT members voting to turn off transaction routes in + an emergency scenario) +* Compensation + * Group compensation (further distribution decided by the specialization group) + * Individual compensation for all constituents of a group from the + greater community + +Membership admittance to a specialization group could take place over a wide +variety of mechanisms. The most obvious example is through a general vote among +the entire community, however in certain systems a community may want to allow +the members already in a specialization group to internally elect new members, +or maybe the community may assign a permission to a particular specialization +group to appoint members to other 3rd party groups. The sky is really the limit +as to how membership admittance can be structured. We attempt to capture +some of these possiblities in a common interface dubbed the `Electionator`. For +its initial implementation as a part of this ADR we recommend that the general +election abstraction (`Electionator`) is provided as well as a basic +implementation of that abstraction which allows for a continuous election of +members of a specialization group. + +``` golang +// The Electionator abstraction covers the concept space for +// a wide variety of election kinds. +type Electionator interface { + + // is the election object accepting votes. + Active() bool + + // functionality to execute for when a vote is cast in this election, here + // the vote field is anticipated to be marshalled into a vote type used + // by an election. + // + // NOTE There are no explicit ids here. Just votes which pertain specifically + // to one electionator. Anyone can create and send a vote to the electionator item + // which will presumably attempt to marshal those bytes into a particular struct + // and apply the vote information in some arbitrary way. There can be multiple + // Electionators within the Cosmos-Hub for multiple specialization groups, votes + // would need to be routed to the Electionator upstream of here. + Vote(addr sdk.AccAddress, vote []byte) + + // here lies all functionality to authenticate and execute changes for + // when a member accepts being elected + AcceptElection(sdk.AccAddress) + + // Register a revoker object + RegisterRevoker(Revoker) + + // No more revokers may be registered after this function is called + SealRevokers() + + // register hooks to call when an election actions occur + RegisterHooks(ElectionatorHooks) + + // query for the current winner(s) of this election based on arbitrary + // election ruleset + QueryElected() []sdk.AccAddress + + // query metadata for an address in the election this + // could include for example position that an address + // is being elected for within a group + // + // this metadata may be directly related to + // voting information and/or privileges enabled + // to members within a group. + QueryMetadata(sdk.AccAddress) []byte +} + +// ElectionatorHooks, once registered with an Electionator, +// trigger execution of relevant interface functions when +// Electionator events occur. +type ElectionatorHooks interface { + AfterVoteCast(addr sdk.AccAddress, vote []byte) + AfterMemberAccepted(addr sdk.AccAddress) + AfterMemberRevoked(addr sdk.AccAddress, cause []byte) +} + +// Revoker defines the function required for a membership revocation rule-set +// used by a specialization group. This could be used to create self revoking, +// and evidence based revoking, etc. Revokers types may be created and +// reused for different election types. +// +// When revoking the "cause" bytes may be arbitrarily marshalled into evidence, +// memos, etc. +type Revoker interface { + RevokeName() string // identifier for this revoker type + RevokeMember(addr sdk.AccAddress, cause []byte) error +} +``` + +Certain level of commonality likely exists between the existing code within +`x/governance` and required functionality of elections. This common +functionality should be abstracted during implementation. Similarly for each +vote implementation client CLI/REST functionality should be abstracted +to be reused for multiple elections. + +The specialization group abstraction firstly extends the `Electionator` +but also further defines traits of the group. + +``` golang +type SpecializationGroup interface { + Electionator + GetName() string + GetDescription() string + + // general soft contract the group is expected + // to fulfill with the greater community + GetContract() string + + // messages which can be executed by the members of the group + Handler(ctx sdk.Context, msg sdk.Msg) sdk.Result + + // logic to be executed at endblock, this may for instance + // include payment of a stipend to the group members + // for participation in the security group. + EndBlocker(ctx sdk.Context) +} +``` + +## Status + +> Proposed + +## Consequences + +### Positive + +* increases specialization capabilities of a blockchain +* improve abstractions in `x/gov/` such that they can be used with specialization groups + +### Negative + +* could be used to increase centralization within a community + +### Neutral + +## References + +* [dCERT ADR](./adr-008-dCERT-group.md) diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-008-dCERT-group.md b/versioned_docs/version-0.46/integrate/architecture/adr-008-dCERT-group.md new file mode 100644 index 000000000..2b2d2b826 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-008-dCERT-group.md @@ -0,0 +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) diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-009-evidence-module.md b/versioned_docs/version-0.46/integrate/architecture/adr-009-evidence-module.md new file mode 100644 index 000000000..ded04a142 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-009-evidence-module.md @@ -0,0 +1,182 @@ +# ADR 009: Evidence Module + +## Changelog + +* 2019 July 31: Initial draft +* 2019 October 24: Initial implementation + +## Status + +Accepted + +## Context + +In order to support building highly secure, robust and interoperable blockchain +applications, it is vital for the Cosmos SDK to expose a mechanism in which arbitrary +evidence can be submitted, evaluated and verified resulting in some agreed upon +penalty for any misbehavior committed by a validator, such as equivocation (double-voting), +signing when unbonded, signing an incorrect state transition (in the future), etc. +Furthermore, such a mechanism is paramount for any +[IBC](https://github.com/cosmos/ics/blob/master/ibc/2_IBC_ARCHITECTURE.md) or +cross-chain validation protocol implementation in order to support the ability +for any misbehavior to be relayed back from a collateralized chain to a primary +chain so that the equivocating validator(s) can be slashed. + +## Decision + +We will implement an evidence module in the Cosmos SDK supporting the following +functionality: + +* Provide developers with the abstractions and interfaces necessary to define + custom evidence messages, message handlers, and methods to slash and penalize + accordingly for misbehavior. +* Support the ability to route evidence messages to handlers in any module to + determine the validity of submitted misbehavior. +* Support the ability, through governance, to modify slashing penalties of any + evidence type. +* Querier implementation to support querying params, evidence types, params, and + all submitted valid misbehavior. + +### Types + +First, we define the `Evidence` interface type. The `x/evidence` module may implement +its own types that can be used by many chains (e.g. `CounterFactualEvidence`). +In addition, other modules may implement their own `Evidence` types in a similar +manner in which governance is extensible. It is important to note any concrete +type implementing the `Evidence` interface may include arbitrary fields such as +an infraction time. We want the `Evidence` type to remain as flexible as possible. + +When submitting evidence to the `x/evidence` module, the concrete type must provide +the validator's consensus address, which should be known by the `x/slashing` +module (assuming the infraction is valid), the height at which the infraction +occurred and the validator's power at same height in which the infraction occurred. + +```go +type Evidence interface { + Route() string + Type() string + String() string + Hash() HexBytes + ValidateBasic() error + + // The consensus address of the malicious validator at time of infraction + GetConsensusAddress() ConsAddress + + // Height at which the infraction occurred + GetHeight() int64 + + // The total power of the malicious validator at time of infraction + GetValidatorPower() int64 + + // The total validator set power at time of infraction + GetTotalPower() int64 +} +``` + +### Routing & Handling + +Each `Evidence` type must map to a specific unique route and be registered with +the `x/evidence` module. It accomplishes this through the `Router` implementation. + +```go +type Router interface { + AddRoute(r string, h Handler) Router + HasRoute(r string) bool + GetRoute(path string) Handler + Seal() +} +``` + +Upon successful routing through the `x/evidence` module, the `Evidence` type +is passed through a `Handler`. This `Handler` is responsible for executing all +corresponding business logic necessary for verifying the evidence as valid. In +addition, the `Handler` may execute any necessary slashing and potential jailing. +Since slashing fractions will typically result from some form of static functions, +allow the `Handler` to do this provides the greatest flexibility. An example could +be `k * evidence.GetValidatorPower()` where `k` is an on-chain parameter controlled +by governance. The `Evidence` type should provide all the external information +necessary in order for the `Handler` to make the necessary state transitions. +If no error is returned, the `Evidence` is considered valid. + +```go +type Handler func(Context, Evidence) error +``` + +### Submission + +`Evidence` is submitted through a `MsgSubmitEvidence` message type which is internally +handled by the `x/evidence` module's `SubmitEvidence`. + +```go +type MsgSubmitEvidence struct { + Evidence +} + +func handleMsgSubmitEvidence(ctx Context, keeper Keeper, msg MsgSubmitEvidence) Result { + if err := keeper.SubmitEvidence(ctx, msg.Evidence); err != nil { + return err.Result() + } + + // emit events... + + return Result{ + // ... + } +} +``` + +The `x/evidence` module's keeper is responsible for matching the `Evidence` against +the module's router and invoking the corresponding `Handler` which may include +slashing and jailing the validator. Upon success, the submitted evidence is persisted. + +```go +func (k Keeper) SubmitEvidence(ctx Context, evidence Evidence) error { + handler := keeper.router.GetRoute(evidence.Route()) + if err := handler(ctx, evidence); err != nil { + return ErrInvalidEvidence(keeper.codespace, err) + } + + keeper.setEvidence(ctx, evidence) + return nil +} +``` + +### Genesis + +Finally, we need to represent the genesis state of the `x/evidence` module. The +module only needs a list of all submitted valid infractions and any necessary params +for which the module needs in order to handle submitted evidence. The `x/evidence` +module will naturally define and route native evidence types for which it'll most +likely need slashing penalty constants for. + +```go +type GenesisState struct { + Params Params + Infractions []Evidence +} +``` + +## Consequences + +### Positive + +* Allows the state machine to process misbehavior submitted on-chain and penalize + validators based on agreed upon slashing parameters. +* Allows evidence types to be defined and handled by any module. This further allows + slashing and jailing to be defined by more complex mechanisms. +* Does not solely rely on Tendermint to submit evidence. + +### Negative + +* No easy way to introduce new evidence types through governance on a live chain + due to the inability to introduce the new evidence type's corresponding handler + +### Neutral + +* Should we persist infractions indefinitely? Or should we rather rely on events? + +## References + +* [ICS](https://github.com/cosmos/ics) +* [IBC Architecture](https://github.com/cosmos/ics/blob/master/ibc/1_IBC_ARCHITECTURE.md) +* [Tendermint Fork Accountability](https://github.com/tendermint/spec/blob/7b3138e69490f410768d9b1ffc7a17abc23ea397/spec/consensus/fork-accountability.md) diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-010-modular-antehandler.md b/versioned_docs/version-0.46/integrate/architecture/adr-010-modular-antehandler.md new file mode 100644 index 000000000..386af1a77 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-010-modular-antehandler.md @@ -0,0 +1,290 @@ +# ADR 010: Modular AnteHandler + +## Changelog + +* 2019 Aug 31: Initial draft +* 2021 Sep 14: Superseded by ADR-045 + +## Status + +SUPERSEDED by 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. + +For example, let's say a user wants to implement some custom signature verification logic. In the current codebase, the user would have to write their own Antehandler from scratch largely reimplementing much of the same code and then set their own custom, monolithic antehandler in the baseapp. Instead, we would like to allow users to specify custom behavior when necessary and combine them with default ante-handler functionality in a way that is as modular and flexible as possible. + +## Proposals + +### Per-Module AnteHandler + +One approach is to use the [ModuleManager](https://pkg.go.dev/github.com/cosmos/cosmos-sdk/types/module) and have each module implement its own antehandler if it requires custom antehandler logic. The ModuleManager can then be passed in an AnteHandler order in the same way it has an order for BeginBlockers and EndBlockers. The ModuleManager returns a single AnteHandler function that will take in a tx and run each module's `AnteHandle` in the specified order. The module manager's AnteHandler is set as the baseapp's AnteHandler. + +Pros: + +1. Simple to implement +2. Utilizes the existing ModuleManager architecture + +Cons: + +1. Improves granularity but still cannot get more granular than a per-module basis. e.g. If auth's `AnteHandle` function is in charge of validating memo and signatures, users cannot swap the signature-checking functionality while keeping the rest of auth's `AnteHandle` functionality. +2. Module AnteHandler are run one after the other. There is no way for one AnteHandler to wrap or "decorate" another. + +### Decorator Pattern + +The [weave project](https://github.com/iov-one/weave) achieves AnteHandler modularity through the use of a decorator pattern. The interface is designed as follows: + +```go +// Decorator wraps a Handler to provide common functionality +// like authentication, or fee-handling, to many Handlers +type Decorator interface { + Check(ctx Context, store KVStore, tx Tx, next Checker) (*CheckResult, error) + Deliver(ctx Context, store KVStore, tx Tx, next Deliverer) (*DeliverResult, error) +} +``` + +Each decorator works like a modularized 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. + +A key benefit of this approach is that one Decorator can wrap its internal logic around the next Checker/Deliverer. A weave Decorator may do the following: + +```go +// Example Decorator's Deliver function +func (example Decorator) Deliver(ctx Context, store KVStore, tx Tx, next Deliverer) { + // Do some pre-processing logic + + res, err := next.Deliver(ctx, store, tx) + + // Do some post-processing logic given the result and error +} +``` + +Pros: + +1. Weave Decorators can wrap over the next decorator/handler in the chain. The ability to both pre-process and post-process may be useful in certain settings. +2. Provides a nested modular structure that isn't possible in the solution above, while also allowing for a linear one-after-the-other structure like the solution above. + +Cons: + +1. It is hard to understand at first glance the state updates that would occur after a Decorator runs given the `ctx`, `store`, and `tx`. A Decorator can have an arbitrary number of nested Decorators being called within its function body, each possibly doing some pre- and post-processing before calling the next decorator on the chain. Thus to understand what a Decorator is doing, one must also understand what every other decorator further along the chain is also doing. This can get quite complicated to understand. A linear, one-after-the-other approach while less powerful, may be much easier to reason about. + +### Chained Micro-Functions + +The benefit of Weave's approach is that the Decorators can be very concise, which when chained together allows for maximum customizability. However, the nested structure can get quite complex and thus hard to reason about. + +Another approach is to split the AnteHandler functionality into tightly scoped "micro-functions", while preserving the one-after-the-other ordering that would come from the ModuleManager approach. + +We can then have a way to chain these micro-functions so that they run one after the other. Modules may define multiple ante micro-functions and then also provide a default per-module AnteHandler that implements a default, suggested order for these micro-functions. + +Users can order the AnteHandlers easily by simply using the ModuleManager. The ModuleManager will take in a list of AnteHandlers and return a single AnteHandler that runs each AnteHandler in the order of the list provided. If the user is comfortable with the default ordering of each module, this is as simple as providing a list with each module's antehandler (exactly the same as BeginBlocker and EndBlocker). + +If however, users wish to change the order or add, modify, or delete ante micro-functions in anyway; they can always define their own ante micro-functions and add them explicitly to the list that gets passed into module manager. + +#### Default Workflow + +This is an example of a user's AnteHandler if they choose not to make any custom micro-functions. + +##### Cosmos SDK code + +```go +// Chains together a list of AnteHandler micro-functions that get run one after the other. +// Returned AnteHandler will abort on first error. +func Chainer(order []AnteHandler) AnteHandler { + return func(ctx Context, tx Tx, simulate bool) (newCtx Context, err error) { + for _, ante := range order { + ctx, err := ante(ctx, tx, simulate) + if err != nil { + return ctx, err + } + } + return ctx, err + } +} +``` + +```go +// AnteHandler micro-function to verify signatures +func VerifySignatures(ctx Context, tx Tx, simulate bool) (newCtx Context, err error) { + // verify signatures + // Returns InvalidSignature Result and abort=true if sigs invalid + // Return OK result and abort=false if sigs are valid +} + +// AnteHandler micro-function to validate memo +func ValidateMemo(ctx Context, tx Tx, simulate bool) (newCtx Context, err error) { + // validate memo +} + +// Auth defines its own default ante-handler by chaining its micro-functions in a recommended order +AuthModuleAnteHandler := Chainer([]AnteHandler{VerifySignatures, ValidateMemo}) +``` + +```go +// Distribution micro-function to deduct fees from tx +func DeductFees(ctx Context, tx Tx, simulate bool) (newCtx Context, err error) { + // Deduct fees from tx + // Abort if insufficient funds in account to pay for fees +} + +// Distribution micro-function to check if fees > mempool parameter +func CheckMempoolFees(ctx Context, tx Tx, simulate bool) (newCtx Context, err error) { + // If CheckTx: Abort if the fees are less than the mempool's minFee parameter +} + +// Distribution defines its own default ante-handler by chaining its micro-functions in a recommended order +DistrModuleAnteHandler := Chainer([]AnteHandler{CheckMempoolFees, DeductFees}) +``` + +```go +type ModuleManager struct { + // other fields + AnteHandlerOrder []AnteHandler +} + +func (mm ModuleManager) GetAnteHandler() AnteHandler { + retun Chainer(mm.AnteHandlerOrder) +} +``` + +##### User Code + +```go +// Note: Since user is not making any custom modifications, we can just SetAnteHandlerOrder with the default AnteHandlers provided by each module in our preferred order +moduleManager.SetAnteHandlerOrder([]AnteHandler(AuthModuleAnteHandler, DistrModuleAnteHandler)) + +app.SetAnteHandler(mm.GetAnteHandler()) +``` + +#### Custom Workflow + +This is an example workflow for a user that wants to implement custom antehandler logic. In this example, the user wants to implement custom signature verification and change the order of antehandler so that validate memo runs before signature verification. + +##### User Code + +```go +// User can implement their own custom signature verification antehandler micro-function +func CustomSigVerify(ctx Context, tx Tx, simulate bool) (newCtx Context, err error) { + // do some custom signature verification logic +} +``` + +```go +// Micro-functions allow users to change order of when they get executed, and swap out default ante-functionality with their own custom logic. +// Note that users can still chain the default distribution module handler, and auth micro-function along with their custom ante function +moduleManager.SetAnteHandlerOrder([]AnteHandler(ValidateMemo, CustomSigVerify, DistrModuleAnteHandler)) +``` + +Pros: + +1. Allows for ante functionality to be as modular as possible. +2. For users that do not need custom ante-functionality, there is little difference between how antehandlers work and how BeginBlock and EndBlock work in ModuleManager. +3. Still easy to understand + +Cons: + +1. Cannot wrap antehandlers with decorators like you can with Weave. + +### Simple Decorators + +This approach takes inspiration from Weave's decorator design while trying to minimize the number of breaking changes to the 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`. + +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. + +Allow Decorator interface that can be chained together to create a Cosmos SDK AnteHandler. + +This allows users to choose between implementing an AnteHandler by themselves and setting it in the baseapp, or use the decorator pattern to chain their custom decorators with the Cosmos SDK provided decorators in the order they wish. + +```go +// An AnteDecorator wraps an AnteHandler, and can do pre- and post-processing on the next AnteHandler +type AnteDecorator interface { + AnteHandle(ctx Context, tx Tx, simulate bool, next AnteHandler) (newCtx Context, err error) +} +``` + +```go +// ChainAnteDecorators will recursively link all of the AnteDecorators in the chain and return a final AnteHandler function +// This is done to preserve the ability to set a single AnteHandler function in the baseapp. +func ChainAnteDecorators(chain ...AnteDecorator) AnteHandler { + if len(chain) == 1 { + return func(ctx Context, tx Tx, simulate bool) { + chain[0].AnteHandle(ctx, tx, simulate, nil) + } + } + return func(ctx Context, tx Tx, simulate bool) { + chain[0].AnteHandle(ctx, tx, simulate, ChainAnteDecorators(chain[1:])) + } +} +``` + +#### Example Code + +Define AnteDecorator functions + +```go +// Setup GasMeter, catch OutOfGasPanic and handle appropriately +type SetUpContextDecorator struct{} + +func (sud SetUpContextDecorator) AnteHandle(ctx Context, tx Tx, simulate bool, next AnteHandler) (newCtx Context, err error) { + ctx.GasMeter = NewGasMeter(tx.Gas) + + defer func() { + // recover from OutOfGas panic and handle appropriately + } + + return next(ctx, tx, simulate) +} + +// Signature Verification decorator. Verify Signatures and move on +type SigVerifyDecorator struct{} + +func (svd SigVerifyDecorator) AnteHandle(ctx Context, tx Tx, simulate bool, next AnteHandler) (newCtx Context, err error) { + // verify sigs. Return error if invalid + + // call next antehandler if sigs ok + return next(ctx, tx, simulate) +} + +// User-defined Decorator. Can choose to pre- and post-process on AnteHandler +type UserDefinedDecorator struct{ + // custom fields +} + +func (udd UserDefinedDecorator) AnteHandle(ctx Context, tx Tx, simulate bool, next AnteHandler) (newCtx Context, err error) { + // pre-processing logic + + ctx, err = next(ctx, tx, simulate) + + // post-processing logic +} +``` + +Link AnteDecorators to create a final AnteHandler. Set this AnteHandler in baseapp. + +```go +// Create final antehandler by chaining the decorators together +antehandler := ChainAnteDecorators(NewSetUpContextDecorator(), NewSigVerifyDecorator(), NewUserDefinedDecorator()) + +// Set chained Antehandler in the baseapp +bapp.SetAnteHandler(antehandler) +``` + +Pros: + +1. Allows one decorator to pre- and post-process the next AnteHandler, similar to the Weave design. +2. Do not need to break baseapp API. Users can still set a single AnteHandler if they choose. + +Cons: + +1. Decorator pattern may have a deeply nested structure that is hard to understand, this is mitigated by having the decorator order explicitly listed in the `ChainAnteDecorators` function. +2. Does not make use of the ModuleManager design. Since this is already being used for BeginBlocker/EndBlocker, this proposal seems unaligned with that design pattern. + +## Consequences + +Since pros and cons are written for each approach, it is omitted from this section + +## References + +* [#4572](https://github.com/cosmos/cosmos-sdk/issues/4572): Modular AnteHandler Issue +* [#4582](https://github.com/cosmos/cosmos-sdk/pull/4583): Initial Implementation of Per-Module AnteHandler Approach +* [Weave Decorator Code](https://github.com/iov-one/weave/blob/master/handler.go#L35) +* [Weave Design Videos](https://vimeo.com/showcase/6189877) diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-011-generalize-genesis-accounts.md b/versioned_docs/version-0.46/integrate/architecture/adr-011-generalize-genesis-accounts.md new file mode 100644 index 000000000..92a704ba6 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-011-generalize-genesis-accounts.md @@ -0,0 +1,170 @@ +# ADR 011: Generalize Genesis Accounts + +## Changelog + +* 2019-08-30: initial draft + +## 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`). + +Projects desiring to use custom accounts (say custom vesting accounts) need to fork and modify `genaccounts`. + +## Decision + +In summary, we will (un)marshal all accounts (interface types) directly using amino, rather than converting to `genaccounts`’s `GenesisAccount` type. Since doing this removes the majority of `genaccounts`'s code, we will merge `genaccounts` into `auth`. Marshalled accounts will be stored in `auth`'s genesis state. + +Detailed changes: + +### 1) (Un)Marshal accounts directly using amino + +The `auth` module's `GenesisState` gains a new field `Accounts`. Note these aren't of type `exported.Account` for reasons outlined in section 3. + +```go +// GenesisState - all auth state that must be provided at genesis +type GenesisState struct { + Params Params `json:"params" yaml:"params"` + Accounts []GenesisAccount `json:"accounts" yaml:"accounts"` +} +``` + +Now `auth`'s `InitGenesis` and `ExportGenesis` (un)marshal accounts as well as the defined params. + +```go +// InitGenesis - Init store state from genesis data +func InitGenesis(ctx sdk.Context, ak AccountKeeper, data GenesisState) { + ak.SetParams(ctx, data.Params) + // load the accounts + for _, a := range data.Accounts { + acc := ak.NewAccount(ctx, a) // set account number + ak.SetAccount(ctx, acc) + } +} + +// ExportGenesis returns a GenesisState for a given context and keeper +func ExportGenesis(ctx sdk.Context, ak AccountKeeper) GenesisState { + params := ak.GetParams(ctx) + + var genAccounts []exported.GenesisAccount + ak.IterateAccounts(ctx, func(account exported.Account) bool { + genAccount := account.(exported.GenesisAccount) + genAccounts = append(genAccounts, genAccount) + return false + }) + + return NewGenesisState(params, genAccounts) +} +``` + +### 2) Register custom account types on the `auth` codec + +The `auth` codec must have all custom account types registered to marshal them. We will follow the pattern established in `gov` for proposals. + +An example custom account definition: + +```go +import authtypes "github.com/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 +func init() { + authtypes.RegisterAccountTypeCodec(ModuleAccount{}, "cosmos-sdk/ModuleAccount") +} + +type ModuleAccount struct { + ... +``` + +The `auth` codec definition: + +```go +var ModuleCdc *codec.LegacyAmino + +func init() { + ModuleCdc = codec.NewLegacyAmino() + // register module msg's and Account interface + ... + // leave the codec unsealed +} + +// RegisterAccountTypeCodec registers an external account type defined in another module for the internal ModuleCdc. +func RegisterAccountTypeCodec(o interface{}, name string) { + ModuleCdc.RegisterConcrete(o, name, nil) +} +``` + +### 3) Genesis validation for custom account types + +Modules implement a `ValidateGenesis` method. As `auth` does not know of account implementations, accounts will need to validate themselves. + +We will unmarshal accounts into a `GenesisAccount` interface that includes a `Validate` method. + +```go +type GenesisAccount interface { + exported.Account + Validate() error +} +``` + +Then the `auth` `ValidateGenesis` function becomes: + +```go +// ValidateGenesis performs basic validation of auth genesis data returning an +// error for any failed validation criteria. +func ValidateGenesis(data GenesisState) error { + // Validate params + ... + + // Validate accounts + addrMap := make(map[string]bool, len(data.Accounts)) + for _, acc := range data.Accounts { + + // check for duplicated accounts + addrStr := acc.GetAddress().String() + if _, ok := addrMap[addrStr]; ok { + return fmt.Errorf("duplicate account found in genesis state; address: %s", addrStr) + } + addrMap[addrStr] = true + + // check account specific validation + if err := acc.Validate(); err != nil { + return fmt.Errorf("invalid account found in genesis state; address: %s, error: %s", addrStr, err.Error()) + } + + } + return nil +} +``` + +### 4) Move add-genesis-account cli to `auth` + +The `genaccounts` module contains a cli command to add base or vesting accounts to a genesis file. + +This will be moved to `auth`. We will leave it to projects to write their own commands to add custom accounts. An extensible cli handler, similar to `gov`, could be created but it is not worth the complexity for this minor use case. + +### 5) Update module and vesting accounts + +Under the new scheme, module and vesting account types need some minor updates: + +* Type registration on `auth`'s codec (shown above) +* A `Validate` method for each `Account` concrete type + +## Status + +Proposed + +## Consequences + +### Positive + +* custom accounts can be used without needing to fork `genaccounts` +* reduction in lines of code + +### Negative + +### Neutral + +* `genaccounts` module no longer exists +* accounts in genesis files are stored under `accounts` in `auth` rather than in the `genaccounts` module. +-`add-genesis-account` cli command now in `auth` + +## References diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-012-state-accessors.md b/versioned_docs/version-0.46/integrate/architecture/adr-012-state-accessors.md new file mode 100644 index 000000000..93600000f --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-012-state-accessors.md @@ -0,0 +1,155 @@ +# ADR 012: State Accessors + +## Changelog + +* 2019 Sep 04: Initial draft + +## 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. + +First, each time a module tries to access the state, it has to marshal the value and set or get the +value and finally unmarshal. Usually this is done by declaring `Keeper.GetXXX` and `Keeper.SetXXX` functions, +which are repetitive and hard to maintain. + +Second, this makes it harder to align with the object capability theorem: the right to access the +state is defined as a `StoreKey`, which gives full access on the entire Merkle tree, so a module cannot +send the access right to a specific key-value pair (or a set of key-value pairs) to another module safely. + +Finally, because the getter/setter functions are defined as methods of a module's `Keeper`, the reviewers +have to consider the whole Merkle tree space when they reviewing a function accessing any part of the state. +There is no static way to know which part of the state that the function is accessing (and which is not). + +## Decision + +We will define a type named `Value`: + +```go +type Value struct { + m Mapping + key []byte +} +``` + +The `Value` works as a reference for a key-value pair in the state, where `Value.m` defines the key-value +space it will access and `Value.key` defines the exact key for the reference. + +We will define a type named `Mapping`: + +```go +type Mapping struct { + storeKey sdk.StoreKey + cdc *codec.LegacyAmino + prefix []byte +} +``` + +The `Mapping` works as a reference for a key-value space in the state, where `Mapping.storeKey` defines +the IAVL (sub-)tree and `Mapping.prefix` defines the optional subspace prefix. + +We will define the following core methods for the `Value` type: + +```go +// Get and unmarshal stored data, noop if not exists, panic if cannot unmarshal +func (Value) Get(ctx Context, ptr interface{}) {} + +// Get and unmarshal stored data, return error if not exists or cannot unmarshal +func (Value) GetSafe(ctx Context, ptr interface{}) {} + +// Get stored data as raw byte slice +func (Value) GetRaw(ctx Context) []byte {} + +// Marshal and set a raw value +func (Value) Set(ctx Context, o interface{}) {} + +// Check if a raw value exists +func (Value) Exists(ctx Context) bool {} + +// Delete a raw value value +func (Value) Delete(ctx Context) {} +``` + +We will define the following core methods for the `Mapping` type: + +```go +// Constructs key-value pair reference corresponding to the key argument in the Mapping space +func (Mapping) Value(key []byte) Value {} + +// Get and unmarshal stored data, noop if not exists, panic if cannot unmarshal +func (Mapping) Get(ctx Context, key []byte, ptr interface{}) {} + +// Get and unmarshal stored data, return error if not exists or cannot unmarshal +func (Mapping) GetSafe(ctx Context, key []byte, ptr interface{}) + +// Get stored data as raw byte slice +func (Mapping) GetRaw(ctx Context, key []byte) []byte {} + +// Marshal and set a raw value +func (Mapping) Set(ctx Context, key []byte, o interface{}) {} + +// Check if a raw value exists +func (Mapping) Has(ctx Context, key []byte) bool {} + +// Delete a raw value value +func (Mapping) Delete(ctx Context, key []byte) {} +``` + +Each method of the `Mapping` type that is passed the arguments `ctx`, `key`, and `args...` will proxy +the call to `Mapping.Value(key)` with arguments `ctx` and `args...`. + +In addition, we will define and provide a common set of types derived from the `Value` type: + +```go +type Boolean struct { Value } +type Enum struct { Value } +type Integer struct { Value; enc IntEncoding } +type String struct { Value } +// ... +``` + +Where the encoding schemes can be different, `o` arguments in core methods are typed, and `ptr` arguments +in core methods are replaced by explicit return types. + +Finally, we will define a family of types derived from the `Mapping` type: + +```go +type Indexer struct { + m Mapping + enc IntEncoding +} +``` + +Where the `key` argument in core method is typed. + +Some of the properties of the accessor types are: + +* State access happens only when a function which takes a `Context` as an argument is invoked +* Accessor type structs give rights to access the state only that the struct is referring, no other +* Marshalling/Unmarshalling happens implicitly within the core methods + +## Status + +Proposed + +## Consequences + +### Positive + +* Serialization will be done automatically +* Shorter code size, less boilerplate, better UX +* References to the state can be transferred safely +* Explicit scope of accessing + +### Negative + +* Serialization format will be hidden +* Different architecture from the current, but the use of accessor types can be opt-in +* Type-specific types (e.g. `Boolean` and `Integer`) have to be defined manually + +### Neutral + +## References + +* [#4554](https://github.com/cosmos/cosmos-sdk/issues/4554) diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-013-metrics.md b/versioned_docs/version-0.46/integrate/architecture/adr-013-metrics.md new file mode 100644 index 000000000..33849b56c --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-013-metrics.md @@ -0,0 +1,157 @@ +# ADR 013: Observability + +## Changelog + +* 20-01-2020: Initial Draft + +## Status + +Proposed + +## Context + +Telemetry is paramount into debugging and understanding what the application is doing and how it is +performing. We aim to expose metrics from modules and other core parts of the Cosmos SDK. + +In addition, we should aim to support multiple configurable sinks that an operator may choose from. +By default, when telemetry is enabled, the application should track and expose metrics that are +stored in-memory. The operator may choose to enable additional sinks, where we support only +[Prometheus](https://prometheus.io/) for now, as it's battle-tested, simple to setup, open source, +and is rich with ecosystem tooling. + +We must also aim to integrate metrics into the Cosmos SDK in the most seamless way possible such that +metrics may be added or removed at will and without much friction. To do this, we will use the +[go-metrics](https://github.com/armon/go-metrics) library. + +Finally, operators may enable telemetry along with specific configuration options. If enabled, metrics +will be exposed via `/metrics?format={text|prometheus}` via the API server. + +## Decision + +We will add an additional configuration block to `app.toml` that defines telemetry settings: + +```toml +############################################################################### +### Telemetry Configuration ### +############################################################################### + +[telemetry] + +# Prefixed with keys to separate services +service-name = {{ .Telemetry.ServiceName }} + +# Enabled enables the application telemetry functionality. When enabled, +# an in-memory sink is also enabled by default. Operators may also enabled +# other sinks such as Prometheus. +enabled = {{ .Telemetry.Enabled }} + +# Enable prefixing gauge values with hostname +enable-hostname = {{ .Telemetry.EnableHostname }} + +# Enable adding hostname to labels +enable-hostname-label = {{ .Telemetry.EnableHostnameLabel }} + +# Enable adding service to labels +enable-service-label = {{ .Telemetry.EnableServiceLabel }} + +# PrometheusRetentionTime, when positive, enables a Prometheus metrics sink. +prometheus-retention-time = {{ .Telemetry.PrometheusRetentionTime }} +``` + +The given configuration allows for two sinks -- in-memory and Prometheus. We create a `Metrics` +type that performs all the bootstrapping for the operator, so capturing metrics becomes seamless. + +```go +// Metrics defines a wrapper around application telemetry functionality. It allows +// metrics to be gathered at any point in time. When creating a Metrics object, +// internally, a global metrics is registered with a set of sinks as configured +// by the operator. In addition to the sinks, when a process gets a SIGUSR1, a +// dump of formatted recent metrics will be sent to STDERR. +type Metrics struct { + memSink *metrics.InmemSink + prometheusEnabled bool +} + +// Gather collects all registered metrics and returns a GatherResponse where the +// metrics are encoded depending on the type. Metrics are either encoded via +// Prometheus or JSON if in-memory. +func (m *Metrics) Gather(format string) (GatherResponse, error) { + switch format { + case FormatPrometheus: + return m.gatherPrometheus() + + case FormatText: + return m.gatherGeneric() + + case FormatDefault: + return m.gatherGeneric() + + default: + return GatherResponse{}, fmt.Errorf("unsupported metrics format: %s", format) + } +} +``` + +In addition, `Metrics` allows us to gather the current set of metrics at any given point in time. An +operator may also choose to send a signal, SIGUSR1, to dump and print formatted metrics to STDERR. + +During an application's bootstrapping and construction phase, if `Telemetry.Enabled` is `true`, the +API server will create an instance of a reference to `Metrics` object and will register a metrics +handler accordingly. + +```go +func (s *Server) Start(cfg config.Config) error { + // ... + + if cfg.Telemetry.Enabled { + m, err := telemetry.New(cfg.Telemetry) + if err != nil { + return err + } + + s.metrics = m + s.registerMetrics() + } + + // ... +} + +func (s *Server) registerMetrics() { + metricsHandler := func(w http.ResponseWriter, r *http.Request) { + format := strings.TrimSpace(r.FormValue("format")) + + gr, err := s.metrics.Gather(format) + if err != nil { + rest.WriteErrorResponse(w, http.StatusBadRequest, fmt.Sprintf("failed to gather metrics: %s", err)) + return + } + + w.Header().Set("Content-Type", gr.ContentType) + _, _ = w.Write(gr.Metrics) + } + + s.Router.HandleFunc("/metrics", metricsHandler).Methods("GET") +} +``` + +Application developers may track counters, gauges, summaries, and key/value metrics. There is no +additional lifting required by modules to leverage profiling metrics. To do so, it's as simple as: + +```go +func (k BaseKeeper) MintCoins(ctx sdk.Context, moduleName string, amt sdk.Coins) error { + defer metrics.MeasureSince(time.Now(), "MintCoins") + // ... +} +``` + +## Consequences + +### Positive + +* Exposure into the performance and behavior of an application + +### Negative + +### Neutral + +## References diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-014-proportional-slashing.md b/versioned_docs/version-0.46/integrate/architecture/adr-014-proportional-slashing.md new file mode 100644 index 000000000..63cd04dee --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-014-proportional-slashing.md @@ -0,0 +1,85 @@ +# ADR 14: Proportional Slashing + +## Changelog + +* 2019-10-15: Initial draft +* 2020-05-25: Removed correlation root slashing +* 2020-07-01: Updated to include S-curve function instead of linear + +## Context + +In Proof of Stake-based chains, centralization of consensus power amongst a small set of validators can cause harm to the network due to increased risk of censorship, liveness failure, fork attacks, etc. However, while this centralization causes a negative externality to the network, it is not directly felt by the delegators contributing towards delegating towards already large validators. We would like a way to pass on the negative externality cost of centralization onto those large validators and their delegators. + +## Decision + +### Design + +To solve this problem, we will implement a procedure called Proportional Slashing. The desire is that the larger a validator is, the more they should be slashed. The first naive attempt is to make a validator's slash percent proportional to their share of consensus voting power. + +```text +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. + +```text +slash_amount = k * (power_1 + power_2 + ... + power_n) // where power_i is the voting power of the ith validator faulting in the specified time frame and k is some on-chain constant +``` + +Now, if someone splits a validator of 10% into two validators of 5% each which both fault, then they both fault in the same time frame, they both will get slashed at the sum 10% amount. + +However in practice, we likely don't want a linear relation between amount of stake at fault, and the percentage of stake to slash. In particular, solely 5% of stake double signing effectively did nothing to majorly threaten security, whereas 30% of stake being at fault clearly merits a large slashing factor, due to being very close to the point at which Tendermint security is threatened. A linear relation would require a factor of 6 gap between these two, whereas the difference in risk posed to the network is much larger. We propose using S-curves (formally [logistic functions](https://en.wikipedia.org/wiki/Logistic_function) to solve this). S-Curves capture the desired criterion quite well. They allow the slashing factor to be minimal for small values, and then grow very rapidly near some threshold point where the risk posed becomes notable. + +#### Parameterization + +This requires parameterizing a logistic function. It is very well understood how to parameterize this. It has four parameters: + +1) A minimum slashing factor +2) A maximum slashing factor +3) The inflection point of the S-curve (essentially where do you want to center the S) +4) The rate of growth of the S-curve (How elongated is the S) + +#### Correlation across non-sybil validators + +One will note, that this model doesn't differentiate between multiple validators run by the same operators vs validators run by different operators. This can be seen as an additional benefit in fact. It incentivizes validators to differentiate their setups from other validators, to avoid having correlated faults with them or else they risk a higher slash. So for example, operators should avoid using the same popular cloud hosting platforms or using the same Staking as a Service providers. This will lead to a more resilient and decentralized network. + +#### Griefing + +Griefing, the act of intentionally getting oneself slashed in order to make another's slash worse, could be a concern here. However, using the protocol described here, the attacker also gets equally impacted by the grief as the victim, so it would not provide much benefit to the griefer. + +### Implementation + +In the slashing module, we will add two queues that will track all of the recent slash events. For double sign faults, we will define "recent slashes" as ones that have occurred within the last `unbonding period`. For liveness faults, we will define "recent slashes" as ones that have occurred withing the last `jail period`. + +```go +type SlashEvent struct { + Address sdk.ValAddress + ValidatorVotingPercent sdk.Dec + SlashedSoFar sdk.Dec +} +``` + +These slash events will be pruned from the queue once they are older than their respective "recent slash period". + +Whenever a new slash occurs, a `SlashEvent` struct is created with the faulting validator's voting percent and a `SlashedSoFar` of 0. Because recent slash events are pruned before the unbonding period and unjail period expires, it should not be possible for the same validator to have multiple SlashEvents in the same Queue at the same time. + +We then will iterate over all the SlashEvents in the queue, adding their `ValidatorVotingPercent` to calculate the new percent to slash all the validators in the queue at, using the "Square of Sum of Roots" formula introduced above. + +Once we have the `NewSlashPercent`, we then iterate over all the `SlashEvent`s in the queue once again, and if `NewSlashPercent > SlashedSoFar` for that SlashEvent, we call the `staking.Slash(slashEvent.Address, slashEvent.Power, Math.Min(Math.Max(minSlashPercent, NewSlashPercent - SlashedSoFar), maxSlashPercent)` (we pass in the power of the validator before any slashes occurred, so that we slash the right amount of tokens). We then set `SlashEvent.SlashedSoFar` amount to `NewSlashPercent`. + +## Status + +Proposed + +## Consequences + +### Positive + +* Increases decentralization by disincentivizing delegating to large validators +* Incentivizes Decorrelation of Validators +* More severely punishes attacks than accidental faults +* More flexibility in slashing rates parameterization + +### Negative + +* More computationally expensive than current implementation. Will require more data about "recent slashing events" to be stored on chain. diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-016-validator-consensus-key-rotation.md b/versioned_docs/version-0.46/integrate/architecture/adr-016-validator-consensus-key-rotation.md new file mode 100644 index 000000000..0510c2b9b --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-016-validator-consensus-key-rotation.md @@ -0,0 +1,125 @@ +# ADR 016: Validator Consensus Key Rotation + +## Changelog + +* 2019 Oct 23: Initial draft +* 2019 Nov 28: Add key rotation fee + +## Context + +Validator consensus key rotation feature has been discussed and requested for a long time, for the sake of safer validator key management policy (e.g. https://github.com/tendermint/tendermint/issues/1136). So, we suggest one of the simplest form of validator consensus key rotation implementation mostly onto Cosmos SDK. + +We don't need to make any update on consensus logic in Tendermint because Tendermint does not have any mapping information of consensus key and validator operator key, meaning that from Tendermint point of view, a consensus key rotation of a validator is simply a replacement of a consensus key to another. + +Also, it should be noted that this ADR includes only the simplest form of consensus key rotation without considering multiple consensus keys concept. Such multiple consensus keys concept shall remain a long term goal of Tendermint and Cosmos SDK. + +## Decision + +### Pseudo procedure for consensus key rotation + +* create new random consensus key. +* create and broadcast a transaction with a `MsgRotateConsPubKey` that states the new consensus key is now coupled with the validator operator with signature from the validator's operator key. +* old consensus key becomes unable to participate on consensus immediately after the update of key mapping state on-chain. +* start validating with new consensus key. +* validators using HSM and KMS should update the consensus key in HSM to use the new rotated key after the height `h` when `MsgRotateConsPubKey` committed to the blockchain. + +### Considerations + +* consensus key mapping information management strategy + * store history of each key mapping changes in the kvstore. + * the state machine can search corresponding consensus key paired with given validator operator for any arbitrary height in a recent unbonding period. + * the state machine does not need any historical mapping information which is past more than unbonding period. +* key rotation costs related to LCD and IBC + * LCD and IBC will have traffic/computation burden when there exists frequent power changes + * In current Tendermint design, consensus key rotations are seen as power changes from LCD or IBC perspective + * Therefore, to minimize unnecessary frequent key rotation behavior, we limited maximum number of rotation in recent unbonding period and also applied exponentially increasing rotation fee +* limits + * a validator cannot rotate its consensus key more than `MaxConsPubKeyRotations` time for any unbonding period, to prevent spam. + * parameters can be decided by governance and stored in genesis file. +* key rotation fee + * a validator should pay `KeyRotationFee` to rotate the consensus key which is calculated as below + * `KeyRotationFee` = (max(`VotingPowerPercentage` *100, 1)* `InitialKeyRotationFee`) * 2^(number of rotations in `ConsPubKeyRotationHistory` in recent unbonding period) +* evidence module + * evidence module can search corresponding consensus key for any height from slashing keeper so that it can decide which consensus key is supposed to be used for given height. +* abci.ValidatorUpdate + * tendermint already has ability to change a consensus key by ABCI communication(`ValidatorUpdate`). + * validator consensus key update can be done via creating new + delete old by change the power to zero. + * therefore, we expect we even do not need to change tendermint codebase at all to implement this feature. +* new genesis parameters in `staking` module + * `MaxConsPubKeyRotations` : maximum number of rotation can be executed by a validator in recent unbonding period. default value 10 is suggested(11th key rotation will be rejected) + * `InitialKeyRotationFee` : the initial key rotation fee when no key rotation has happened in recent unbonding period. default value 1atom is suggested(1atom fee for the first key rotation in recent unbonding period) + +### Workflow + +1. The validator generates a new consensus keypair. +2. The validator generates and signs a `MsgRotateConsPubKey` tx with their operator key and new ConsPubKey + + ```go + type MsgRotateConsPubKey struct { + ValidatorAddress sdk.ValAddress + NewPubKey crypto.PubKey + } + ``` + +3. `handleMsgRotateConsPubKey` gets `MsgRotateConsPubKey`, calls `RotateConsPubKey` with emits event +4. `RotateConsPubKey` + * checks if `NewPubKey` is not duplicated on `ValidatorsByConsAddr` + * checks if the validator is does not exceed parameter `MaxConsPubKeyRotations` by iterating `ConsPubKeyRotationHistory` + * checks if the signing account has enough balance to pay `KeyRotationFee` + * pays `KeyRotationFee` to community fund + * overwrites `NewPubKey` in `validator.ConsPubKey` + * deletes old `ValidatorByConsAddr` + * `SetValidatorByConsAddr` for `NewPubKey` + * Add `ConsPubKeyRotationHistory` for tracking rotation + + ```go + type ConsPubKeyRotationHistory struct { + OperatorAddress sdk.ValAddress + OldConsPubKey crypto.PubKey + NewConsPubKey crypto.PubKey + RotatedHeight int64 + } + ``` + +5. `ApplyAndReturnValidatorSetUpdates` checks if there is `ConsPubKeyRotationHistory` with `ConsPubKeyRotationHistory.RotatedHeight == ctx.BlockHeight()` and if so, generates 2 `ValidatorUpdate` , one for a remove validator and one for create new validator + + ```go + abci.ValidatorUpdate{ + PubKey: tmtypes.TM2PB.PubKey(OldConsPubKey), + Power: 0, + } + + abci.ValidatorUpdate{ + PubKey: tmtypes.TM2PB.PubKey(NewConsPubKey), + Power: v.ConsensusPower(), + } + ``` + +6. at `previousVotes` Iteration logic of `AllocateTokens`, `previousVote` using `OldConsPubKey` match up with `ConsPubKeyRotationHistory`, and replace validator for token allocation +7. Migrate `ValidatorSigningInfo` and `ValidatorMissedBlockBitArray` from `OldConsPubKey` to `NewConsPubKey` + +* Note : All above features shall be implemented in `staking` module. + +## Status + +Proposed + +## Consequences + +### Positive + +* Validators can immediately or periodically rotate their consensus key to have better security policy +* improved security against Long-Range attacks (https://nearprotocol.com/blog/long-range-attacks-and-a-new-fork-choice-rule) given a validator throws away the old consensus key(s) + +### Negative + +* Slash module needs more computation because it needs to lookup corresponding consensus key of validators for each height +* frequent key rotations will make light client bisection less efficient + +### Neutral + +## References + +* on tendermint repo : https://github.com/tendermint/tendermint/issues/1136 +* on cosmos-sdk repo : https://github.com/cosmos/cosmos-sdk/issues/5231 +* about multiple consensus keys : https://github.com/tendermint/tendermint/issues/1758#issuecomment-545291698 diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-017-historical-header-module.md b/versioned_docs/version-0.46/integrate/architecture/adr-017-historical-header-module.md new file mode 100644 index 000000000..b97b46d4f --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-017-historical-header-module.md @@ -0,0 +1,61 @@ +# ADR 17: Historical Header Module + +## Changelog + +* 26 November 2019: Start of first version +* 2 December 2019: Final draft of first version + +## Context + +In order for the Cosmos SDK to implement the [IBC specification](https://github.com/cosmos/ics), modules within the 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. + +## Decision + +The application MUST store the most recent `n` headers in a persistent store. At first, this store MAY be the current Merklised store. A non-Merklised store MAY be used later as no proofs are necessary. + +The application MUST store this information by storing new headers immediately when handling `abci.RequestBeginBlock`: + +```golang +func BeginBlock(ctx sdk.Context, keeper HistoricalHeaderKeeper, req abci.RequestBeginBlock) abci.ResponseBeginBlock { + info := HistoricalInfo{ + Header: ctx.BlockHeader(), + ValSet: keeper.StakingKeeper.GetAllValidators(ctx), // note that this must be stored in a canonical order + } + keeper.SetHistoricalInfo(ctx, ctx.BlockHeight(), info) + n := keeper.GetParamRecentHeadersToStore() + keeper.PruneHistoricalInfo(ctx, ctx.BlockHeight() - n) + // continue handling request +} +``` + +Alternatively, the application MAY store only the hash of the validator set. + +The application MUST make these past `n` committed headers available for querying by 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` MAY be configured as a parameter store parameter, in which case it could be changed by `ParameterChangeProposal`s, although it will take some blocks for the stored information to catch up if `n` is increased. + +## Status + +Proposed. + +## Consequences + +Implementation of this ADR will require changes to the Cosmos SDK. It will not require changes to Tendermint. + +### Positive + +* Easy retrieval of headers & state roots for recent past heights by modules anywhere in the Cosmos SDK. +* No RPC calls to Tendermint required. +* No ABCI alterations required. + +### Negative + +* Duplicates `n` headers data in Tendermint & the application (additional disk usage) - in the long term, an approach such as [this](https://github.com/tendermint/tendermint/issues/4210) might be preferable. + +### Neutral + +(none known) + +## References + +* [ICS 2: "Consensus state introspection"](https://github.com/cosmos/ibc/tree/master/spec/core/ics-002-client-semantics#consensus-state-introspection) diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-018-extendable-voting-period.md b/versioned_docs/version-0.46/integrate/architecture/adr-018-extendable-voting-period.md new file mode 100644 index 000000000..ee238fc35 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-018-extendable-voting-period.md @@ -0,0 +1,66 @@ +# ADR 18: Extendable Voting Periods + +## Changelog + +* 1 January 2020: Start of first version + +## Context + +Currently the voting period for all governance proposals is the same. However, this is suboptimal as all governance proposals do not require the same time period. For more non-contentious proposals, they can be dealt with more efficently with a faster period, while more contentious or complex proposals may need a longer period for extended discussion/consideration. + +## Decision + +We would like to design a mechanism for making the voting period of a governance proposal variable based on the demand of voters. We would like it to be based on the view of the governance participants, rather than just the proposer of a governance proposal (thus, allowing the proposer to select the voting period length is not sufficient). + +However, we would like to avoid the creation of an entire second voting process to determine the length of the voting period, as it just pushed the problem to determining the length of that first voting period. + +Thus, we propose the following mechanism: + +### Params + +* The current gov param `VotingPeriod` is to be replaced by a `MinVotingPeriod` param. This is the default voting period that all governance proposal voting periods start with. +* There is a new gov param called `MaxVotingPeriodExtension`. + +### Mechanism + +There is a new `Msg` type called `MsgExtendVotingPeriod`, which can be sent by any staked account during a proposal's voting period. It allows the sender to unilaterally extend the length of the voting period by `MaxVotingPeriodExtension * sender's share of voting power`. Every address can only call `MsgExtendVotingPeriod` once per proposal. + +So for example, if the `MaxVotingPeriodExtension` is set to 100 Days, then anyone with 1% of voting power can extend the voting power by 1 day. If 33% of voting power has sent the message, the voting period will be extended by 33 days. Thus, if absolutely everyone chooses to extend the voting period, the absolute maximum voting period will be `MinVotingPeriod + MaxVotingPeriodExtension`. + +This system acts as a sort of distributed coordination, where individual stakers choosing to extend or not, allows the system the guage the conentiousness/complexity of the proposal. It is extremely unlikely that many stakers will choose to extend at the exact same time, it allows stakers to view how long others have already extended thus far, to decide whether or not to extend further. + +### Dealing with Unbonding/Redelegation + +There is one thing that needs to be addressed. How to deal with redelegation/unbonding during the voting period. If a staker of 5% calls `MsgExtendVotingPeriod` and then unbonds, does the voting period then decrease by 5 days again? This is not good as it can give people a false sense of how long they have to make their decision. For this reason, we want to design it such that the voting period length can only be extended, not shortened. To do this, the current extension amount is based on the highest percent that voted extension at any time. This is best explained by example: + +1. Let's say 2 stakers of voting power 4% and 3% respectively vote to extend. The voting period will be extended by 7 days. +2. Now the staker of 3% decides to unbond before the end of the voting period. The voting period extension remains 7 days. +3. Now, let's say another staker of 2% voting power decides to extend voting period. There is now 6% of active voting power choosing the extend. The voting power remains 7 days. +4. If a fourth staker of 10% chooses to extend now, there is a total of 16% of active voting power wishing to extend. The voting period will be extended to 16 days. + +### Delegators + +Just like votes in the actual voting period, delegators automatically inherit the extension of their validators. If their validator chooses to extend, their voting power will be used in the validator's extension. However, the delegator is unable to override their validator and "unextend" as that would contradict the "voting power length can only be ratcheted up" principle described in the previous section. However, a delegator may choose the extend using their personal voting power, if their validator has not done so. + +## Status + +Proposed + +## Consequences + +### Positive + +* More complex/contentious governance proposals will have more time to properly digest and deliberate + +### Negative + +* Governance process becomes more complex and requires more understanding to interact with effectively +* Can no longer predict when a governance proposal will end. Can't assume order in which governance proposals will end. + +### Neutral + +* The minimum voting period can be made shorter + +## References + +* [Cosmos Forum post where idea first originated](https://forum.cosmos.network/t/proposal-draft-reduce-governance-voting-period-to-7-days/3032/9) diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-019-protobuf-state-encoding.md b/versioned_docs/version-0.46/integrate/architecture/adr-019-protobuf-state-encoding.md new file mode 100644 index 000000000..1d20145ae --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-019-protobuf-state-encoding.md @@ -0,0 +1,379 @@ +# ADR 019: Protocol Buffer State Encoding + +## Changelog + +* 2020 Feb 15: Initial Draft +* 2020 Feb 24: Updates to handle messages with interface fields +* 2020 Apr 27: Convert usages of `oneof` for interfaces to `Any` +* 2020 May 15: Describe `cosmos_proto` extensions and amino compatibility +* 2020 Dec 4: Move and rename `MarshalAny` and `UnmarshalAny` into the `codec.Codec` interface. +* 2021 Feb 24: Remove mentions of `HybridCodec`, which has been abandoned in [#6843](https://github.com/cosmos/cosmos-sdk/pull/6843). + +## Status + +Accepted + +## Context + +Currently, the Cosmos SDK utilizes [go-amino](https://github.com/tendermint/go-amino/) for binary +and JSON object encoding over the wire bringing parity between logical objects and persistence objects. + +From the Amino docs: + +> Amino is an object encoding specification. It is a subset of Proto3 with an extension for interface +> support. See the [Proto3 spec](https://developers.google.com/protocol-buffers/docs/proto3) for more +> information on Proto3, which Amino is largely compatible with (but not with Proto2). +> +> The goal of the Amino encoding protocol is to bring parity into logic objects and persistence objects. + +Amino also aims to have the following goals (not a complete list): + +* Binary bytes must be decode-able with a schema. +* Schema must be upgradeable. +* The encoder and decoder logic must be reasonably simple. + +However, we believe that Amino does not fulfill these goals completely and does not fully meet the +needs of a truly flexible cross-language and multi-client compatible encoding protocol in the Cosmos SDK. +Namely, Amino has proven to be a big pain-point in regards to supporting object serialization across +clients written in various languages while providing virtually little in the way of true backwards +compatibility and upgradeability. Furthermore, through profiling and various benchmarks, Amino has +been shown to be an extremely large performance bottleneck in the Cosmos SDK 1. This is +largely reflected in the performance of simulations and application transaction throughput. + +Thus, we need to adopt an encoding protocol that meets the following criteria for state serialization: + +* Language agnostic +* Platform agnostic +* Rich client support and thriving ecosystem +* High performance +* Minimal encoded message size +* Codegen-based over reflection-based +* Supports backward and forward compatibility + +Note, migrating away from Amino should be viewed as a two-pronged approach, state and client encoding. +This ADR focuses on state serialization in the Cosmos SDK state machine. A corresponding ADR will be +made to address client-side encoding. + +## Decision + +We will adopt [Protocol Buffers](https://developers.google.com/protocol-buffers) for serializing +persisted structured data in the Cosmos SDK while providing a clean mechanism and developer UX for +applications wishing to continue to use Amino. We will provide this mechanism by updating modules to +accept a codec interface, `Marshaler`, instead of a concrete Amino codec. Furthermore, the Cosmos SDK +will provide two concrete implementations of the `Marshaler` interface: `AminoCodec` and `ProtoCodec`. + +* `AminoCodec`: Uses Amino for both binary and JSON encoding. +* `ProtoCodec`: Uses Protobuf for both binary and JSON encoding. + +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. + +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. + +### 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. + +Note, any business logic that needs to encode primitive types like `bool` or `int64` should use +[gogoprotobuf](https://github.com/gogo/protobuf) Value types. + +Example: + +```go + ts, err := gogotypes.TimestampProto(completionTime) + if err != nil { + // ... + } + + bz := cdc.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. + +Example: + +```go +// x/auth/types/codec.go + +type Codec interface { + codec.Codec + + MarshalAccount(acc exported.Account) ([]byte, error) + UnmarshalAccount(bz []byte) (exported.Account, error) + + MarshalAccountJSON(acc exported.Account) ([]byte, error) + UnmarshalAccountJSON(bz []byte) (exported.Account, error) +} +``` + +### Usage of `Any` to encode interfaces + +In general, module-level .proto files should define messages which encode interfaces +using [`google.protobuf.Any`](https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/any.proto). +After [extension discussion](https://github.com/cosmos/cosmos-sdk/issues/6030), +this was chosen as the preferred alternative to application-level `oneof`s +as in our original protobuf design. The arguments in favor of `Any` can be +summarized as follows: + +* `Any` provides a simpler, more consistent client UX for dealing with +interfaces than app-level `oneof`s that will need to be coordinated more +carefully across applications. Creating a generic transaction +signing library using `oneof`s may be cumbersome and critical logic may need +to be reimplemented for each chain +* `Any` provides more resistance against human error than `oneof` +* `Any` is generally simpler to implement for both modules and apps + +The main counter-argument to using `Any` centers around its additional space +and possibly performance overhead. The space overhead could be dealt with using +compression at the persistence layer in the future and the performance impact +is likely to be small. Thus, not using `Any` is seem as a pre-mature optimization, +with user experience as the higher order concern. + +Note, that given the 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://pkg.go.dev/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 register a type with the global protobuf registry +and cause it to be loaded and unmarshaled by a transaction that referenced +it in the `type_url` field. + +To prevent this, we introduce a type registration mechanism for decoding `Any` +values into concrete types through the `InterfaceRegistry` interface which +bears some similarity to type registration with Amino: + +```go +type InterfaceRegistry interface { + // RegisterInterface associates protoName as the public name for the + // interface passed in as iface + // Ex: + // registry.RegisterInterface("cosmos_sdk.Msg", (*sdk.Msg)(nil)) + RegisterInterface(protoName string, iface interface{}) + + // RegisterImplementations registers impls as a concrete implementations of + // the interface iface + // Ex: + // registry.RegisterImplementations((*sdk.Msg)(nil), &MsgSend{}, &MsgMultiSend{}) + RegisterImplementations(iface interface{}, impls ...proto.Message) + +} +``` + +In addition to serving as a whitelist, `InterfaceRegistry` can also serve +to communicate the list of concrete types that satisfy an interface to clients. + +In .proto files: + +* fields which accept interfaces should be annotated with `cosmos_proto.accepts_interface` +using the same full-qualified name passed as `protoName` to `InterfaceRegistry.RegisterInterface` +* interface implementations should be annotated with `cosmos_proto.implements_interface` +using the same full-qualified name passed as `protoName` to `InterfaceRegistry.RegisterInterface` + +In the future, `protoName`, `cosmos_proto.accepts_interface`, `cosmos_proto.implements_interface` +may be used via code generation, reflection &/or static linting. + +The same struct that implements `InterfaceRegistry` will also implement an +interface `InterfaceUnpacker` to be used for unpacking `Any`s: + +```go +type InterfaceUnpacker interface { + // UnpackAny unpacks the value in any to the interface pointer passed in as + // iface. Note that the type in any must have been registered with + // RegisterImplementations as a concrete type for that interface + // Ex: + // var msg sdk.Msg + // err := ctx.UnpackAny(any, &msg) + // ... + UnpackAny(any *Any, iface interface{}) error +} +``` + +Note that `InterfaceRegistry` usage does not deviate from standard protobuf +usage of `Any`, it just introduces a security and introspection layer for +golang usage. + +`InterfaceRegistry` will be a member of `ProtoCodec` +described above. In order for modules to register interface types, app modules +can optionally implement the following interface: + +```go +type InterfaceModule interface { + RegisterInterfaceTypes(InterfaceRegistry) +} +``` + +The module manager will include a method to call `RegisterInterfaceTypes` on +every module that implements it in order to populate the `InterfaceRegistry`. + +### Using `Any` to encode state + +The Cosmos SDK will provide support methods `MarshalInterface` and `UnmarshalInterface` to hide a complexity of wrapping interface types into `Any` and allow easy serialization. + +```go +import "github.com/cosmos/cosmos-sdk/codec" + +// note: eviexported.Evidence is an interface type +func MarshalEvidence(cdc codec.BinaryCodec, e eviexported.Evidence) ([]byte, error) { + return cdc.MarshalInterface(e) +} + +func UnmarshalEvidence(cdc codec.BinaryCodec, bz []byte) (eviexported.Evidence, error) { + var evi eviexported.Evidence + err := cdc.UnmarshalInterface(&evi, bz) + return err, nil +} +``` + +### Using `Any` in `sdk.Msg`s + +A similar concept is to be applied for messages that contain interfaces fields. +For example, we can define `MsgSubmitEvidence` as follows where `Evidence` is +an interface: + +```protobuf +// x/evidence/types/types.proto + +message MsgSubmitEvidence { + bytes submitter = 1 + [ + (gogoproto.casttype) = "github.com/cosmos/cosmos-sdk/types.AccAddress" + ]; + google.protobuf.Any evidence = 2; +} +``` + +Note that in order to unpack the evidence from `Any` we do need a reference to +`InterfaceRegistry`. In order to reference evidence in methods like +`ValidateBasic` which shouldn't have to know about the `InterfaceRegistry`, we +introduce an `UnpackInterfaces` phase to deserialization which unpacks +interfaces before they're needed. + +### Unpacking Interfaces + +To implement the `UnpackInterfaces` phase of deserialization which unpacks +interfaces wrapped in `Any` before they're needed, we create an interface +that `sdk.Msg`s and other types can implement: + +```go +type UnpackInterfacesMessage interface { + UnpackInterfaces(InterfaceUnpacker) error +} +``` + +We also introduce a private `cachedValue interface{}` field onto the `Any` +struct itself with a public getter `GetCachedValue() interface{}`. + +The `UnpackInterfaces` method is to be invoked during message deserialization right +after `Unmarshal` and any interface values packed in `Any`s will be decoded +and stored in `cachedValue` for reference later. + +Then unpacked interface values can safely be used in any code afterwards +without knowledge of the `InterfaceRegistry` +and messages can introduce a simple getter to cast the cached value to the +correct interface type. + +This has the added benefit that unmarshaling of `Any` values only happens once +during initial deserialization rather than every time the value is read. Also, +when `Any` values are first packed (for instance in a call to +`NewMsgSubmitEvidence`), the original interface value is cached so that +unmarshaling isn't needed to read it again. + +`MsgSubmitEvidence` could implement `UnpackInterfaces`, plus a convenience getter +`GetEvidence` as follows: + +```go +func (msg MsgSubmitEvidence) UnpackInterfaces(ctx sdk.InterfaceRegistry) error { + var evi eviexported.Evidence + return ctx.UnpackAny(msg.Evidence, *evi) +} + +func (msg MsgSubmitEvidence) GetEvidence() eviexported.Evidence { + return msg.Evidence.GetCachedValue().(eviexported.Evidence) +} +``` + +### Amino Compatibility + +Our custom implementation of `Any` can be used transparently with Amino if used +with the proper codec instance. What this means is that interfaces packed within +`Any`s will be amino marshaled like regular Amino interfaces (assuming they +have been registered properly with Amino). + +In order for this functionality to work: + +* **all legacy code must use `*codec.LegacyAmino` instead of `*amino.Codec` which is + now a wrapper which properly handles `Any`** +* **all new code should use `Marshaler` which is compatible with both amino and + protobuf** +* Also, before v0.39, `codec.LegacyAmino` will be renamed to `codec.LegacyAmino`. + +### Why Wasn't X Chosen Instead + +For a more complete comparison to alternative protocols, see [here](https://codeburst.io/json-vs-protocol-buffers-vs-flatbuffers-a4247f8bda6f). + +### Cap'n Proto + +While [Cap’n Proto](https://capnproto.org/) does seem like an advantageous alternative to Protobuf +due to it's native support for interfaces/generics and built in canonicalization, it does lack the +rich client ecosystem compared to Protobuf and is a bit less mature. + +### FlatBuffers + +[FlatBuffers](https://google.github.io/flatbuffers/) is also a potentially viable alternative, with the +primary difference being that FlatBuffers does not need a parsing/unpacking step to a secondary +representation before you can access data, often coupled with per-object memory allocation. + +However, it would require great efforts into research and full understanding the scope of the migration +and path forward -- which isn't immediately clear. In addition, FlatBuffers aren't designed for +untrusted inputs. + +## Future Improvements & Roadmap + +In the future we may consider a compression layer right above the persistence +layer which doesn't change tx or merkle tree hashes, but reduces the storage +overhead of `Any`. In addition, we may adopt protobuf naming conventions which +make type URLs a bit more concise while remaining descriptive. + +Additional code generation support around the usage of `Any` is something that +could also be explored in the future to make the UX for go developers more +seamless. + +## Consequences + +### Positive + +* Significant performance gains. +* Supports backward and forward type compatibility. +* Better support for cross-language clients. + +### Negative + +* Learning curve required to understand and implement Protobuf messages. +* Slightly larger message size due to use of `Any`, although this could be offset + by a compression layer in the future + +### Neutral + +## References + +1. https://github.com/cosmos/cosmos-sdk/issues/4977 +2. https://github.com/cosmos/cosmos-sdk/issues/5444 diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-020-protobuf-transaction-encoding.md b/versioned_docs/version-0.46/integrate/architecture/adr-020-protobuf-transaction-encoding.md new file mode 100644 index 000000000..71bd1f9fd --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-020-protobuf-transaction-encoding.md @@ -0,0 +1,464 @@ +# ADR 020: Protocol Buffer Transaction Encoding + +## Changelog + +* 2020 March 06: Initial Draft +* 2020 March 12: API Updates +* 2020 April 13: Added details on interface `oneof` handling +* 2020 April 30: Switch to `Any` +* 2020 May 14: Describe public key encoding +* 2020 June 08: Store `TxBody` and `AuthInfo` as bytes in `SignDoc`; Document `TxRaw` as broadcast and storage type. +* 2020 August 07: Use ADR 027 for serializing `SignDoc`. +* 2020 August 19: Move sequence field from `SignDoc` to `SignerInfo`, as discussed in [#6966](https://github.com/cosmos/cosmos-sdk/issues/6966). +* 2020 September 25: Remove `PublicKey` type in favor of `secp256k1.PubKey`, `ed25519.PubKey` and `multisig.LegacyAminoPubKey`. +* 2020 October 15: Add `GetAccount` and `GetAccountWithHeight` methods to the `AccountRetriever` interface. +* 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`. + +## Status + +Accepted + +## Context + +This ADR is a continuation of the motivation, design, and context established in +[ADR 019](./adr-019-protobuf-state-encoding.md), namely, we aim to design the +Protocol Buffer migration path for the client-side of the Cosmos SDK. + +Specifically, the client-side migration path primarily includes tx generation and +signing, message construction and routing, in addition to CLI & REST handlers and +business logic (i.e. queriers). + +With this in mind, we will tackle the migration path via two main areas, txs and +querying. However, this ADR solely focuses on transactions. Querying should be +addressed in a future ADR, but it should build off of these proposals. + +Based on detailed discussions ([\#6030](https://github.com/cosmos/cosmos-sdk/issues/6030) +and [\#6078](https://github.com/cosmos/cosmos-sdk/issues/6078)), the original +design for transactions was changed substantially from an `oneof` /JSON-signing +approach to the approach described below. + +## Decision + +### Transactions + +Since interface values are encoded with `google.protobuf.Any` in state (see [ADR 019](adr-019-protobuf-state-encoding.md)), +`sdk.Msg`s are encoding with `Any` in transactions. + +One of the main goals of using `Any` to encode interface values is to have a +core set of types which is reused by apps so that +clients can safely be compatible with as many chains as possible. + +It is one of the goals of this specification to provide a flexible cross-chain transaction +format that can serve a wide variety of use cases without breaking client +compatibility. + +In order to facilitate signing, transactions are separated into `TxBody`, +which will be re-used by `SignDoc` below, and `signatures`: + +```proto +// types/types.proto +package cosmos_sdk.v1; + +message Tx { + TxBody body = 1; + AuthInfo auth_info = 2; + // A list of signatures that matches the length and order of AuthInfo's signer_infos to + // allow connecting signature meta information like public key and signing mode by position. + repeated bytes signatures = 3; +} + +// A variant of Tx that pins the signer's exact binary represenation of body and +// auth_info. This is used for signing, broadcasting and verification. The binary +// `serialize(tx: TxRaw)` is stored in Tendermint and the hash `sha256(serialize(tx: TxRaw))` +// becomes the "txhash", commonly used as the transaction ID. +message TxRaw { + // A protobuf serialization of a TxBody that matches the representation in SignDoc. + bytes body = 1; + // A protobuf serialization of an AuthInfo that matches the representation in SignDoc. + bytes auth_info = 2; + // A list of signatures that matches the length and order of AuthInfo's signer_infos to + // allow connecting signature meta information like public key and signing mode by position. + repeated bytes signatures = 3; +} + +message TxBody { + // A list of messages to be executed. The required signers of those messages define + // the number and order of elements in AuthInfo's signer_infos and Tx's signatures. + // Each required signer address is added to the list only the first time it occurs. + // + // By convention, the first required signer (usually from the first message) is referred + // to as the primary signer and pays the fee for the whole transaction. + repeated google.protobuf.Any messages = 1; + string memo = 2; + int64 timeout_height = 3; + repeated google.protobuf.Any extension_options = 1023; +} + +message AuthInfo { + // This list defines the signing modes for the required signers. The number + // and order of elements must match the required signers from TxBody's messages. + // The first element is the primary signer and the one which pays the fee. + repeated SignerInfo signer_infos = 1; + // The fee can be calculated based on the cost of evaluating the body and doing signature verification of the signers. This can be estimated via simulation. + Fee fee = 2; +} + +message SignerInfo { + // The public key is optional for accounts that already exist in state. If unset, the + // verifier can use the required signer address for this position and lookup the public key. + google.protobuf.Any public_key = 1; + // ModeInfo describes the signing mode of the signer and is a nested + // structure to support nested multisig pubkey's + ModeInfo mode_info = 2; + // sequence is the sequence of the account, which describes the + // number of committed transactions signed by a given address. It is used to prevent + // replay attacks. + uint64 sequence = 3; +} + +message ModeInfo { + oneof sum { + Single single = 1; + Multi multi = 2; + } + + // Single is the mode info for a single signer. It is structured as a message + // to allow for additional fields such as locale for SIGN_MODE_TEXTUAL in the future + message Single { + SignMode mode = 1; + } + + // Multi is the mode info for a multisig public key + message Multi { + // bitarray specifies which keys within the multisig are signing + CompactBitArray bitarray = 1; + // mode_infos is the corresponding modes of the signers of the multisig + // which could include nested multisig public keys + repeated ModeInfo mode_infos = 2; + } +} + +enum SignMode { + SIGN_MODE_UNSPECIFIED = 0; + + SIGN_MODE_DIRECT = 1; + + SIGN_MODE_TEXTUAL = 2; + + SIGN_MODE_LEGACY_AMINO_JSON = 127; +} +``` + +As will be discussed below, in order to include as much of the `Tx` as possible +in the `SignDoc`, `SignerInfo` is separated from signatures so that only the +raw signatures themselves live outside of what is signed over. + +Because we are aiming for a flexible, extensible cross-chain transaction +format, new transaction processing options should be added to `TxBody` as soon +those use cases are discovered, even if they can't be implemented yet. + +Because there is coordination overhead in this, `TxBody` includes an +`extension_options` field which can be used for any transaction processing +options that are not already covered. App developers should, nevertheless, +attempt to upstream important improvements to `Tx`. + +### Signing + +All of the signing modes below aim to provide the following guarantees: + +* **No Malleability**: `TxBody` and `AuthInfo` cannot change once the transaction + is signed +* **Predictable Gas**: if I am signing a transaction where I am paying a fee, + the final gas is fully dependent on what I am signing + +These guarantees give the maximum amount confidence to message signers that +manipulation of `Tx`s by intermediaries can't result in any meaningful changes. + +#### `SIGN_MODE_DIRECT` + +The "direct" signing behavior is to sign the raw `TxBody` bytes as broadcast over +the wire. This has the advantages of: + +* requiring the minimum additional client capabilities beyond a standard protocol + buffers implementation +* leaving effectively zero holes for transaction malleability (i.e. there are no + subtle differences between the signing and encoding formats which could + potentially be exploited by an attacker) + +Signatures are structured using the `SignDoc` below which reuses the serialization of +`TxBody` and `AuthInfo` and only adds the fields which are needed for signatures: + +```proto +// types/types.proto +message SignDoc { + // A protobuf serialization of a TxBody that matches the representation in TxRaw. + bytes body = 1; + // A protobuf serialization of an AuthInfo that matches the representation in TxRaw. + bytes auth_info = 2; + string chain_id = 3; + uint64 account_number = 4; +} +``` + +In order to sign in the default mode, clients take the following steps: + +1. Serialize `TxBody` and `AuthInfo` using any valid protobuf implementation. +2. Create a `SignDoc` and serialize it using [ADR 027](./adr-027-deterministic-protobuf-serialization.md). +3. Sign the encoded `SignDoc` bytes. +4. Build a `TxRaw` and serialize it for broadcasting. + +Signature verification is based on comparing the raw `TxBody` and `AuthInfo` +bytes encoded in `TxRaw` not based on any ["canonicalization"](https://github.com/regen-network/canonical-proto3) +algorithm which creates added complexity for clients in addition to preventing +some forms of upgradeability (to be addressed later in this document). + +Signature verifiers do: + +1. Deserialize a `TxRaw` and pull out `body` and `auth_info`. +2. Create a list of required signer addresses from the messages. +3. For each required signer: + * Pull account number and sequence from the state. + * Obtain the public key either from state or `AuthInfo`'s `signer_infos`. + * Create a `SignDoc` and serialize it using [ADR 027](./adr-027-deterministic-protobuf-serialization.md). + * Verify the signature at the same list position against the serialized `SignDoc`. + +#### `SIGN_MODE_LEGACY_AMINO` + +In order to support legacy wallets and exchanges, Amino JSON will be temporarily +supported transaction signing. Once wallets and exchanges have had a +chance to upgrade to protobuf based signing, this option will be disabled. In +the meantime, it is foreseen that disabling the current Amino signing would cause +too much breakage to be feasible. Note that this is mainly a requirement of the +Cosmos Hub and other chains may choose to disable Amino signing immediately. + +Legacy clients will be able to sign a transaction using the current Amino +JSON format and have it encoded to protobuf using the REST `/tx/encode` +endpoint before broadcasting. + +#### `SIGN_MODE_TEXTUAL` + +As was discussed extensively in [\#6078](https://github.com/cosmos/cosmos-sdk/issues/6078), +there is a desire for a human-readable signing encoding, especially for hardware +wallets like the [Ledger](https://www.ledger.com) which display +transaction contents to users before signing. JSON was an attempt at this but +falls short of the ideal. + +`SIGN_MODE_TEXTUAL` is intended as a placeholder for a human-readable +encoding which will replace Amino JSON. This new encoding should be even more +focused on readability than JSON, possibly based on formatting strings like +[MessageFormat](http://userguide.icu-project.org/formatparse/messages). + +In order to ensure that the new human-readable format does not suffer from +transaction malleability issues, `SIGN_MODE_TEXTUAL` +requires that the _human-readable bytes are concatenated with the raw `SignDoc`_ +to generate sign bytes. + +Multiple human-readable formats (maybe even localized messages) may be supported +by `SIGN_MODE_TEXTUAL` when it is implemented. + +### Unknown Field Filtering + +Unknown fields in protobuf messages should generally be rejected by transaction +processors because: + +* important data may be present in the unknown fields, that if ignored, will + cause unexpected behavior for clients +* they present a malleability vulnerability where attackers can bloat tx size + by adding random uninterpreted data to unsigned content (i.e. the master `Tx`, + not `TxBody`) + +There are also scenarios where we may choose to safely ignore unknown fields +(https://github.com/cosmos/cosmos-sdk/issues/6078#issuecomment-624400188) to +provide graceful forwards compatibility with newer clients. + +We propose that field numbers with bit 11 set (for most use cases this is +the range of 1024-2047) be considered non-critical fields that can safely be +ignored if unknown. + +To handle this we will need a unknown field filter that: + +* always rejects unknown fields in unsigned content (i.e. top-level `Tx` and + unsigned parts of `AuthInfo` if present based on the signing mode) +* rejects unknown fields in all messages (including nested `Any`s) other than + fields with bit 11 set + +This will likely need to be a custom protobuf parser pass that takes message bytes +and `FileDescriptor`s and returns a boolean result. + +### Public Key Encoding + +Public keys in the Cosmos SDK implement 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: + +```proto +message PubKey { + bytes key = 1; +} +``` + +`multisig.LegacyAminoPubKey` has an array of `Any`'s member to support any +protobuf public key type. + +Apps should only attempt to handle a registered set of public keys that they +have tested. The provided signature verification ante handler decorators will +enforce this. + +### CLI & REST + +Currently, the REST and CLI handlers encode and decode types and txs via Amino +JSON encoding using a concrete Amino codec. Being that some of the types dealt with +in the client can be interfaces, similar to how we described in [ADR 019](./adr-019-protobuf-state-encoding.md), +the client logic will now need to take a codec interface that knows not only how +to handle all the types, but also knows how to generate transactions, signatures, +and messages. + +```go +type AccountRetriever interface { + GetAccount(clientCtx Context, addr sdk.AccAddress) (client.Account, error) + GetAccountWithHeight(clientCtx Context, addr sdk.AccAddress) (client.Account, int64, error) + EnsureExists(clientCtx client.Context, addr sdk.AccAddress) error + GetAccountNumberSequence(clientCtx client.Context, addr sdk.AccAddress) (uint64, uint64, error) +} + +type Generator interface { + NewTx() TxBuilder + NewFee() ClientFee + NewSignature() ClientSignature + MarshalTx(tx types.Tx) ([]byte, error) +} + +type TxBuilder interface { + GetTx() sdk.Tx + + SetMsgs(...sdk.Msg) error + GetSignatures() []sdk.Signature + SetSignatures(...sdk.Signature) + GetFee() sdk.Fee + SetFee(sdk.Fee) + GetMemo() string + SetMemo(string) +} +``` + +We then update `Context` to have new fields: `Codec`, `TxGenerator`, +and `AccountRetriever`, and we update `AppModuleBasic.GetTxCmd` to take +a `Context` which should have all of these fields pre-populated. + +Each client method should then use one of the `Init` methods to re-initialize +the pre-populated `Context`. `tx.GenerateOrBroadcastTx` can be used to +generate or broadcast a transaction. For example: + +```go +import "github.com/spf13/cobra" +import "github.com/cosmos/cosmos-sdk/client" +import "github.com/cosmos/cosmos-sdk/client/tx" + +func NewCmdDoSomething(clientCtx client.Context) *cobra.Command { + return &cobra.Command{ + RunE: func(cmd *cobra.Command, args []string) error { + clientCtx := ctx.InitWithInput(cmd.InOrStdin()) + msg := NewSomeMsg{...} + tx.GenerateOrBroadcastTx(clientCtx, msg) + }, + } +} +``` + +## Future Improvements + +### `SIGN_MODE_TEXTUAL` specification + +A concrete specification and implementation of `SIGN_MODE_TEXTUAL` is intended +as a near-term future improvement so that the ledger app and other wallets +can gracefully transition away from Amino JSON. + +### `SIGN_MODE_DIRECT_AUX` + +(\*Documented as option (3) in https://github.com/cosmos/cosmos-sdk/issues/6078#issuecomment-628026933) + +We could add a mode `SIGN_MODE_DIRECT_AUX` +to support scenarios where multiple signatures +are being gathered into a single transaction but the message composer does not +yet know which signatures will be included in the final transaction. For instance, +I may have a 3/5 multisig wallet and want to send a `TxBody` to all 5 +signers to see who signs first. As soon as I have 3 signatures then I will go +ahead and build the full transaction. + +With `SIGN_MODE_DIRECT`, each signer needs +to sign the full `AuthInfo` which includes the full list of all signers and +their signing modes, making the above scenario very hard. + +`SIGN_MODE_DIRECT_AUX` would allow "auxiliary" signers to create their signature +using only `TxBody` and their own `PublicKey`. This allows the full list of +signers in `AuthInfo` to be delayed until signatures have been collected. + +An "auxiliary" signer is any signer besides the primary signer who is paying +the fee. For the primary signer, the full `AuthInfo` is actually needed to calculate gas and fees +because that is dependent on how many signers and which key types and signing +modes they are using. Auxiliary signers, however, do not need to worry about +fees or gas and thus can just sign `TxBody`. + +To generate a signature in `SIGN_MODE_DIRECT_AUX` these steps would be followed: + +1. Encode `SignDocAux` (with the same requirement that fields must be serialized + in order): + + ```proto + // types/types.proto + message SignDocAux { + bytes body_bytes = 1; + // PublicKey is included in SignDocAux : + // 1. as a special case for multisig public keys. For multisig public keys, + // the signer should use the top-level multisig public key they are signing + // against, not their own public key. This is to prevent against a form + // of malleability where a signature could be taken out of context of the + // multisig key that was intended to be signed for + // 2. to guard against scenario where configuration information is encoded + // in public keys (it has been proposed) such that two keys can generate + // the same signature but have different security properties + // + // By including it here, the composer of AuthInfo cannot reference the + // a public key variant the signer did not intend to use + PublicKey public_key = 2; + string chain_id = 3; + uint64 account_number = 4; + } + ``` + +2. Sign the encoded `SignDocAux` bytes +3. Send their signature and `SignerInfo` to primary signer who will then + sign and broadcast the final transaction (with `SIGN_MODE_DIRECT` and `AuthInfo` + added) once enough signatures have been collected + +### `SIGN_MODE_DIRECT_RELAXED` + +(_Documented as option (1)(a) in https://github.com/cosmos/cosmos-sdk/issues/6078#issuecomment-628026933_) + +This is a variation of `SIGN_MODE_DIRECT` where multiple signers wouldn't need to +coordinate public keys and signing modes in advance. It would involve an alternate +`SignDoc` similar to `SignDocAux` above with fee. This could be added in the future +if client developers found the burden of collecting public keys and modes in advance +too burdensome. + +## Consequences + +### Positive + +* Significant performance gains. +* Supports backward and forward type compatibility. +* Better support for cross-language clients. +* Multiple signing modes allow for greater protocol evolution + +### Negative + +* `google.protobuf.Any` type URLs increase transaction size although the effect + may be negligible or compression may be able to mitigate it. + +### Neutral + +## References diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-021-protobuf-query-encoding.md b/versioned_docs/version-0.46/integrate/architecture/adr-021-protobuf-query-encoding.md new file mode 100644 index 000000000..9037d14a8 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-021-protobuf-query-encoding.md @@ -0,0 +1,256 @@ +# ADR 021: Protocol Buffer Query Encoding + +## Changelog + +* 2020 March 27: Initial Draft + +## Status + +Accepted + +## Context + +This ADR is a continuation of the motivation, design, and context established in +[ADR 019](./adr-019-protobuf-state-encoding.md) and +[ARD 020](./adr-019-protobuf-transaction-encoding.md), namely, we aim to design the +Protocol Buffer migration path for the client-side of the Cosmos SDK. + +This ADR continues from [ARD 020](./adr-020-protobuf-transaction-encoding.md) +to specify the encoding of queries. + +## Decision + +### Custom Query Definition + +Modules define custom queries through a protocol buffers `service` definition. +These `service` definitions are generally associated with and used by the +GRPC protocol. However, the protocol buffers specification indicates that +they can be used more generically by any request/response protocol that uses +protocol buffer encoding. Thus, we can use `service` definitions for specifying +custom ABCI queries and even reuse a substantial amount of the GRPC infrastructure. + +Each module with custom queries should define a service canonically named `Query`: + +```proto +// x/bank/types/types.proto + +service Query { + rpc QueryBalance(QueryBalanceParams) returns (cosmos_sdk.v1.Coin) { } + rpc QueryAllBalances(QueryAllBalancesParams) returns (QueryAllBalancesResponse) { } +} +``` + +#### Handling of Interface Types + +Modules that use interface types and need true polymorphism generally force a +`oneof` up to the app-level that provides the set of concrete implementations of +that interface that the app supports. While app's are welcome to do the same for +queries and implement an app-level query service, it is recommended that modules +provide query methods that expose these interfaces via `google.protobuf.Any`. +There is a concern on the transaction level that the overhead of `Any` is too +high to justify its usage. However for queries this is not a concern, and +providing generic module-level queries that use `Any` does not preclude apps +from also providing app-level queries that return use the app-level `oneof`s. + +A hypothetical example for the `gov` module would look something like: + +```proto +// x/gov/types/types.proto + +import "google/protobuf/any.proto"; + +service Query { + rpc GetProposal(GetProposalParams) returns (AnyProposal) { } +} + +message AnyProposal { + ProposalBase base = 1; + google.protobuf.Any content = 2; +} +``` + +### Custom Query Implementation + +In order to implement the query service, we can reuse the existing [gogo protobuf](https://github.com/gogo/protobuf) +grpc plugin, which for a service named `Query` generates an interface named +`QueryServer` as below: + +```go +type QueryServer interface { + QueryBalance(context.Context, *QueryBalanceParams) (*types.Coin, error) + QueryAllBalances(context.Context, *QueryAllBalancesParams) (*QueryAllBalancesResponse, error) +} +``` + +The custom queries for our module are implemented by implementing this interface. + +The first parameter in this generated interface is a generic `context.Context`, +whereas querier methods generally need an instance of `sdk.Context` to read +from the store. Since arbitrary values can be attached to `context.Context` +using the `WithValue` and `Value` methods, the Cosmos SDK should provide a function +`sdk.UnwrapSDKContext` to retrieve the `sdk.Context` from the provided +`context.Context`. + +An example implementation of `QueryBalance` for the bank module as above would +look something like: + +```go +type Querier struct { + Keeper +} + +func (q Querier) QueryBalance(ctx context.Context, params *types.QueryBalanceParams) (*sdk.Coin, error) { + balance := q.GetBalance(sdk.UnwrapSDKContext(ctx), params.Address, params.Denom) + return &balance, nil +} +``` + +### Custom Query Registration and Routing + +Query server implementations as above would be registered with `AppModule`s using +a new method `RegisterQueryService(grpc.Server)` which could be implemented simply +as below: + +```go +// x/bank/module.go +func (am AppModule) RegisterQueryService(server grpc.Server) { + types.RegisterQueryServer(server, keeper.Querier{am.keeper}) +} +``` + +Underneath the hood, a new method `RegisterService(sd *grpc.ServiceDesc, handler interface{})` +will be added to the existing `baseapp.QueryRouter` to add the queries to the custom +query routing table (with the routing method being described below). +The signature for this method matches the existing +`RegisterServer` method on the GRPC `Server` type where `handler` is the custom +query server implementation described above. + +GRPC-like requests are routed by the service name (ex. `cosmos_sdk.x.bank.v1.Query`) +and method name (ex. `QueryBalance`) combined with `/`s to form a full +method name (ex. `/cosmos_sdk.x.bank.v1.Query/QueryBalance`). This gets translated +into an ABCI query as `custom/cosmos_sdk.x.bank.v1.Query/QueryBalance`. Service handlers +registered with `QueryRouter.RegisterService` will be routed this way. + +Beyond the method name, GRPC requests carry a protobuf encoded payload, which maps naturally +to `RequestQuery.Data`, and receive a protobuf encoded response or error. Thus +there is a quite natural mapping of GRPC-like rpc methods to the existing +`sdk.Query` and `QueryRouter` infrastructure. + +This basic specification allows us to reuse protocol buffer `service` definitions +for ABCI custom queries substantially reducing the need for manual decoding and +encoding in query methods. + +### GRPC Protocol Support + +In addition to providing an ABCI query pathway, we can easily provide a GRPC +proxy server that routes requests in the GRPC protocol to ABCI query requests +under the hood. In this way, clients could use their host languages' existing +GRPC implementations to make direct queries against Cosmos SDK app's using +these `service` definitions. In order for this server to work, the `QueryRouter` +on `BaseApp` will need to expose the service handlers registered with +`QueryRouter.RegisterService` to the proxy server implementation. Nodes could +launch the proxy server on a separate port in the same process as the ABCI app +with a command-line flag. + +### REST Queries and Swagger Generation + +[grpc-gateway](https://github.com/grpc-ecosystem/grpc-gateway) is a project that +translates REST calls into GRPC calls using special annotations on service +methods. Modules that want to expose REST queries should add `google.api.http` +annotations to their `rpc` methods as in this example below. + +```proto +// x/bank/types/types.proto + +service Query { + rpc QueryBalance(QueryBalanceParams) returns (cosmos_sdk.v1.Coin) { + option (google.api.http) = { + get: "/x/bank/v1/balance/{address}/{denom}" + }; + } + rpc QueryAllBalances(QueryAllBalancesParams) returns (QueryAllBalancesResponse) { + option (google.api.http) = { + get: "/x/bank/v1/balances/{address}" + }; + } +} +``` + +grpc-gateway will work direcly against the GRPC proxy described above which will +translate requests to ABCI queries under the hood. grpc-gateway can also +generate Swagger definitions automatically. + +In the current implementation of REST queries, each module needs to implement +REST queries manually in addition to ABCI querier methods. Using the grpc-gateway +approach, there will be no need to generate separate REST query handlers, just +query servers as described above as grpc-gateway handles the translation of protobuf +to REST as well as Swagger definitions. + +The 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. + +### Client Usage + +The gogo protobuf grpc plugin generates client interfaces in addition to server +interfaces. For the `Query` service defined above we would get a `QueryClient` +interface like: + +```go +type QueryClient interface { + QueryBalance(ctx context.Context, in *QueryBalanceParams, opts ...grpc.CallOption) (*types.Coin, error) + QueryAllBalances(ctx context.Context, in *QueryAllBalancesParams, opts ...grpc.CallOption) (*QueryAllBalancesResponse, error) +} +``` + +Via a small patch to gogo protobuf ([gogo/protobuf#675](https://github.com/gogo/protobuf/pull/675)) +we have tweaked the grpc codegen to use an interface rather than concrete type +for the generated client struct. This allows us to also reuse the GRPC infrastructure +for ABCI client queries. + +1Context`will receive a new method`QueryConn`that returns a`ClientConn` +that routes calls to ABCI queries + +Clients (such as CLI methods) will then be able to call query methods like this: + +```go +clientCtx := client.NewContext() +queryClient := types.NewQueryClient(clientCtx.QueryConn()) +params := &types.QueryBalanceParams{addr, denom} +result, err := queryClient.QueryBalance(gocontext.Background(), params) +``` + +### Testing + +Tests would be able to create a query client directly from keeper and `sdk.Context` +references using a `QueryServerTestHelper` as below: + +```go +queryHelper := baseapp.NewQueryServerTestHelper(ctx) +types.RegisterQueryServer(queryHelper, keeper.Querier{app.BankKeeper}) +queryClient := types.NewQueryClient(queryHelper) +``` + +## Future Improvements + +## Consequences + +### Positive + +* greatly simplified querier implementation (no manual encoding/decoding) +* easy query client generation (can use existing grpc and swagger tools) +* no need for REST query implementations +* type safe query methods (generated via grpc plugin) +* going forward, there will be less breakage of query methods because of the +backwards compatibility guarantees provided by buf + +### Negative + +* all clients using the existing ABCI/REST queries will need to be refactored +for both the new GRPC/REST query paths as well as protobuf/proto-json encoded +data, but this is more or less unavoidable in the protobuf refactoring + +### Neutral + +## References diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-022-custom-panic-handling.md b/versioned_docs/version-0.46/integrate/architecture/adr-022-custom-panic-handling.md new file mode 100644 index 000000000..6ed7b6246 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-022-custom-panic-handling.md @@ -0,0 +1,218 @@ +# ADR 022: Custom BaseApp panic handling + +## Changelog + +* 2020 Apr 24: Initial Draft +* 2021 Sep 14: Superseded by ADR-045 + +## Status + +SUPERSEDED by ADR-045 + +## Context + +The current implementation of BaseApp does not allow developers to write custom error handlers during panic recovery +[runTx()](https://github.com/cosmos/cosmos-sdk/blob/bad4ca75f58b182f600396ca350ad844c18fc80b/baseapp/baseapp.go#L539) +method. We think that this method can be more flexible and can give 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. + +We propose middleware-solution, which could help developers implement the following cases: + +* add external logging (let's say sending reports to external services like [Sentry](https://sentry.io)); +* call panic for specific error cases; + +It will also make `OutOfGas` case and `default` case one of the middlewares. +`Default` case wraps recovery object to an error and logs it ([example middleware implementation](#Recovery-middleware)). + +Our project has a sidecar service running alongside the blockchain node (smart contracts virtual machine). It is +essential that node <-> sidecar connectivity stays stable for TXs processing. So when the communication breaks we need +to crash the node and reboot it once the problem is solved. That behaviour makes node's state machine execution +deterministic. As all keeper panics are caught by runTx's `defer()` handler, we have to adjust the BaseApp code +in order to customize it. + +## Decision + +### Design + +#### Overview + +Instead of hardcoding custom error handling into BaseApp we suggest using set of middlewares which can be customized +externally and will allow developers use as many custom error handlers as they want. Implementation with tests +can be found [here](https://github.com/cosmos/cosmos-sdk/pull/6053). + +#### Implementation details + +##### Recovery handler + +New `RecoveryHandler` type added. `recoveryObj` input argument is an object returned by the standard Go function +`recover()` from the `builtin` package. + +```go +type RecoveryHandler func(recoveryObj interface{}) error +``` + +Handler should type assert (or other methods) an object to define if object should be handled. +`nil` should be returned if input object can't be handled by that `RecoveryHandler` (not a handler's target type). +Not `nil` error should be returned if input object was handled and middleware chain execution should be stopped. + +An example: + +```go +func exampleErrHandler(recoveryObj interface{}) error { + err, ok := recoveryObj.(error) + if !ok { return nil } + + if someSpecificError.Is(err) { + panic(customPanicMsg) + } else { + return nil + } +} +``` + +This example breaks the application execution, but it also might enrich the error's context like the `OutOfGas` handler. + +##### Recovery middleware + +We also add a middleware type (decorator). That function type wraps `RecoveryHandler` and returns the next middleware in +execution chain and handler's `error`. Type is used to separate actual `recovery()` object handling from middleware +chain processing. + +```go +type recoveryMiddleware func(recoveryObj interface{}) (recoveryMiddleware, error) + +func newRecoveryMiddleware(handler RecoveryHandler, next recoveryMiddleware) recoveryMiddleware { + return func(recoveryObj interface{}) (recoveryMiddleware, error) { + if err := handler(recoveryObj); err != nil { + return nil, err + } + return next, nil + } +} +``` + +Function receives a `recoveryObj` object and returns: + +* (next `recoveryMiddleware`, `nil`) if object wasn't handled (not a target type) by `RecoveryHandler`; +* (`nil`, not nil `error`) if input object was handled and other middlewares in the chain should not be executed; +* (`nil`, `nil`) in case of invalid behavior. Panic recovery might not have been properly handled; +this can be avoided by always using a `default` as a rightmost middleware in the chain (always returns an `error`'); + +`OutOfGas` middleware example: + +```go +func newOutOfGasRecoveryMiddleware(gasWanted uint64, ctx sdk.Context, next recoveryMiddleware) recoveryMiddleware { + handler := func(recoveryObj interface{}) error { + err, ok := recoveryObj.(sdk.ErrorOutOfGas) + if !ok { return nil } + + return sdkerrors.Wrap( + sdkerrors.ErrOutOfGas, fmt.Sprintf( + "out of gas in location: %v; gasWanted: %d, gasUsed: %d", err.Descriptor, gasWanted, ctx.GasMeter().GasConsumed(), + ), + ) + } + + return newRecoveryMiddleware(handler, next) +} +``` + +`Default` middleware example: + +```go +func newDefaultRecoveryMiddleware() recoveryMiddleware { + handler := func(recoveryObj interface{}) error { + return sdkerrors.Wrap( + sdkerrors.ErrPanic, fmt.Sprintf("recovered: %v\nstack:\n%v", recoveryObj, string(debug.Stack())), + ) + } + + return newRecoveryMiddleware(handler, nil) +} +``` + +##### Recovery processing + +Basic chain of middlewares processing would look like: + +```go +func processRecovery(recoveryObj interface{}, middleware recoveryMiddleware) error { + if middleware == nil { return nil } + + next, err := middleware(recoveryObj) + if err != nil { return err } + if next == nil { return nil } + + return processRecovery(recoveryObj, next) +} +``` + +That way we can create a middleware chain which is executed from left to right, the rightmost middleware is a +`default` handler which must return an `error`. + +##### BaseApp changes + +The `default` middleware chain must exist in a `BaseApp` object. `Baseapp` modifications: + +```go +type BaseApp struct { + // ... + runTxRecoveryMiddleware recoveryMiddleware +} + +func NewBaseApp(...) { + // ... + app.runTxRecoveryMiddleware = newDefaultRecoveryMiddleware() +} + +func (app *BaseApp) runTx(...) { + // ... + defer func() { + if r := recover(); r != nil { + recoveryMW := newOutOfGasRecoveryMiddleware(gasWanted, ctx, app.runTxRecoveryMiddleware) + err, result = processRecovery(r, recoveryMW), nil + } + + gInfo = sdk.GasInfo{GasWanted: gasWanted, GasUsed: ctx.GasMeter().GasConsumed()} + }() + // ... +} +``` + +Developers can add their custom `RecoveryHandler`s by providing `AddRunTxRecoveryHandler` as a BaseApp option parameter to the `NewBaseapp` constructor: + +```go +func (app *BaseApp) AddRunTxRecoveryHandler(handlers ...RecoveryHandler) { + for _, h := range handlers { + app.runTxRecoveryMiddleware = newRecoveryMiddleware(h, app.runTxRecoveryMiddleware) + } +} +``` + +This method would prepend handlers to an existing chain. + +## Consequences + +### Positive + +* Developers of Cosmos SDK based projects can add custom panic handlers to: + * add error context for custom panic sources (panic inside of custom keepers); + * emit `panic()`: passthrough recovery object to the Tendermint core; + * other necessary handling; +* Developers can use standard Cosmos SDK `BaseApp` implementation, rather that rewriting it in their projects; +* Proposed solution doesn't break the current "standard" `runTx()` flow; + +### Negative + +* Introduces changes to the execution model design. + +### Neutral + +* `OutOfGas` error handler becomes one of the middlewares; +* Default panic handler becomes one of the middlewares; + +## References + +* [PR-6053 with proposed solution](https://github.com/cosmos/cosmos-sdk/pull/6053) +* [Similar solution. ADR-010 Modular AnteHandler](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-010-modular-antehandler.md) diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-023-protobuf-naming.md b/versioned_docs/version-0.46/integrate/architecture/adr-023-protobuf-naming.md new file mode 100644 index 000000000..4360befde --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-023-protobuf-naming.md @@ -0,0 +1,263 @@ +# ADR 023: Protocol Buffer Naming and Versioning Conventions + +## Changelog + +* 2020 April 27: Initial Draft +* 2020 August 5: Update guidelines + +## Status + +Accepted + +## Context + +Protocol Buffers provide a basic [style guide](https://developers.google.com/protocol-buffers/docs/style) +and [Buf](https://buf.build/docs/style-guide) builds upon that. To the +extent possible, we want to follow industry accepted guidelines and wisdom for +the effective usage of protobuf, deviating from those only when there is clear +rationale for our use case. + +### Adoption of `Any` + +The adoption of `google.protobuf.Any` as the recommended approach for encoding +interface types (as opposed to `oneof`) makes package naming a central part +of the encoding as fully-qualified message names now appear in encoded +messages. + +### Current Directory Organization + +Thus far we have mostly followed [Buf's](https://buf.build) [DEFAULT](https://buf.build/docs/lint-checkers#default) +recommendations, with the minor deviation of disabling [`PACKAGE_DIRECTORY_MATCH`](https://buf.build/docs/lint-checkers#file_layout) +which although being convenient for developing code comes with the warning +from Buf that: + +> you will have a very bad time with many Protobuf plugins across various languages if you do not do this + +### Adoption of gRPC Queries + +In [ADR 021](adr-021-protobuf-query-encoding.md), gRPC was adopted for Protobuf +native queries. The full gRPC service path thus becomes a key part of ABCI query +path. In the future, gRPC queries may be allowed from within persistent scripts +by technologies such as CosmWasm and these query routes would be stored within +script binaries. + +## Decision + +The goal of this ADR is to provide thoughtful naming conventions that: + +* encourage a good user experience for when users interact directly with +.proto files and fully-qualified protobuf names +* balance conciseness against the possibility of either over-optimizing (making +names too short and cryptic) or under-optimizing (just accepting bloated names +with lots of redundant information) + +These guidelines are meant to act as a style guide for both the Cosmos SDK and +third-party modules. + +As a starting point, we should adopt all of the [DEFAULT](https://buf.build/docs/lint-checkers#default) +checkers in [Buf's](https://buf.build) including [`PACKAGE_DIRECTORY_MATCH`](https://buf.build/docs/lint-checkers#file_layout), +except: + +* [PACKAGE_VERSION_SUFFIX](https://buf.build/docs/lint-checkers#package_version_suffix) +* [SERVICE_SUFFIX](https://buf.build/docs/lint-checkers#service_suffix) + +Further guidelines to be described below. + +### Principles + +#### Concise and Descriptive Names + +Names should be descriptive enough to convey their meaning and distinguish +them from other names. + +Given that we are using fully-qualifed names within +`google.protobuf.Any` as well as within gRPC query routes, we should aim to +keep names concise, without going overboard. The general rule of thumb should +be if a shorter name would convey more or else the same thing, pick the shorter +name. + +For instance, `cosmos.bank.MsgSend` (19 bytes) conveys roughly the same information +as `cosmos_sdk.x.bank.v1.MsgSend` (28 bytes) but is more concise. + +Such conciseness makes names both more pleasant to work with and take up less +space within transactions and on the wire. + +We should also resist the temptation to over-optimize, by making names +cryptically short with abbreviations. For instance, we shouldn't try to +reduce `cosmos.bank.MsgSend` to `csm.bk.MSnd` just to save a few bytes. + +The goal is to make names **_concise but not cryptic_**. + +#### Names are for Clients First + +Package and type names should be chosen for the benefit of users, not +necessarily because of legacy concerns related to the go code-base. + +#### Plan for Longevity + +In the interests of long-term support, we should plan on the names we do +choose to be in usage for a long time, so now is the opportunity to make +the best choices for the future. + +### Versioning + +#### Guidelines on Stable Package Versions + +In general, schema evolution is the way to update protobuf schemas. That means that new fields, +messages, and RPC methods are _added_ to existing schemas and old fields, messages and RPC methods +are maintained as long as possible. + +Breaking things is often unacceptable in a blockchain scenario. For instance, immutable smart contracts +may depend on certain data schemas on the host chain. If the host chain breaks those schemas, the smart +contract may be irreparably broken. Even when things can be fixed (for instance in client software), +this often comes at a high cost. + +Instead of breaking things, we should make every effort to evolve schemas rather than just breaking them. +[Buf](https://buf.build) breaking change detection should be used on all stable (non-alpha or beta) packages +to prevent such breakage. + +With that in mind, different stable versions (i.e. `v1` or `v2`) of a package should more or less be considered +different packages and this should be last resort approach for upgrading protobuf schemas. Scenarios where creating +a `v2` may make sense are: + +* we want to create a new module with similar functionality to an existing module and adding `v2` is the most natural +way to do this. In that case, there are really just two different, but similar modules with different APIs. +* we want to add a new revamped API for an existing module and it's just too cumbersome to add it to the existing package, +so putting it in `v2` is cleaner for users. In this case, care should be made to not deprecate support for +`v1` if it is actively used in immutable smart contracts. + +#### Guidelines on unstable (alpha and beta) package versions + +The following guidelines are recommended for marking packages as alpha or beta: + +* marking something as `alpha` or `beta` should be a last resort and just putting something in the +stable package (i.e. `v1` or `v2`) should be preferred +* a package _should_ be marked as `alpha` _if and only if_ there are active discussions to remove +or significantly alter the package in the near future +* a package _should_ be marked as `beta` _if and only if_ there is an active discussion to +significantly refactor/rework the functionality in the near future but not remove it +* modules _can and should_ have types in both stable (i.e. `v1` or `v2`) and unstable (`alpha` or `beta`) packages. + +_`alpha` and `beta` should not be used to avoid responsibility for maintaining compatibility._ +Whenever code is released into the wild, especially on a blockchain, there is a high cost to changing things. In some +cases, for instance with immutable smart contracts, a breaking change may be impossible to fix. + +When marking something as `alpha` or `beta`, maintainers should ask the questions: + +* what is the cost of asking others to change their code vs the benefit of us maintaining the optionality to change it? +* what is the plan for moving this to `v1` and how will that affect users? + +`alpha` or `beta` should really be used to communicate "changes are planned". + +As a case study, gRPC reflection is in the package `grpc.reflection.v1alpha`. It hasn't been changed since +2017 and it is now used in other widely used software like gRPCurl. Some folks probably use it in production services +and so if they actually went and changed the package to `grpc.reflection.v1`, some software would break and +they probably don't want to do that... So now the `v1alpha` package is more or less the de-facto `v1`. Let's not do that. + +The following are guidelines for working with non-stable packages: + +* [Buf's recommended version suffix](https://buf.build/docs/lint-checkers#package_version_suffix) +(ex. `v1alpha1`) _should_ be used for non-stable packages +* non-stable packages should generally be excluded from breaking change detection +* immutable smart contract modules (i.e. CosmWasm) _should_ block smart contracts/persistent +scripts from interacting with `alpha`/`beta` packages + +#### Omit v1 suffix + +Instead of using [Buf's recommended version suffix](https://buf.build/docs/lint-checkers#package_version_suffix), +we can omit `v1` for packages that don't actually have a second version. This +allows for more concise names for common use cases like `cosmos.bank.Send`. +Packages that do have a second or third version can indicate that with `.v2` +or `.v3`. + +### Package Naming + +#### Adopt a short, unique top-level package name + +Top-level packages should adopt a short name that is known to not collide with +other names in common usage within the Cosmos ecosystem. In the near future, a +registry should be created to reserve and index top-level package names used +within the Cosmos ecosystem. Because the Cosmos SDK is intended to provide +the top-level types for the Cosmos project, the top-level package name `cosmos` +is recommended for usage within the Cosmos SDK instead of the longer `cosmos_sdk`. +[ICS](https://github.com/cosmos/ics) specifications could consider a +short top-level package like `ics23` based upon the standard number. + +#### Limit sub-package depth + +Sub-package depth should be increased with caution. Generally a single +sub-package is needed for a module or a library. Even though `x` or `modules` +is used in source code to denote modules, this is often unnecessary for .proto +files as modules are the primary thing sub-packages are used for. Only items which +are known to be used infrequently should have deep sub-package depths. + +For the Cosmos SDK, it is recommended that that we simply write `cosmos.bank`, +`cosmos.gov`, etc. rather than `cosmos.x.bank`. In practice, most non-module +types can go straight in the `cosmos` package or we can introduce a +`cosmos.base` package if needed. Note that this naming _will not_ change +go package names, i.e. the `cosmos.bank` protobuf package will still live in +`x/bank`. + +### Message Naming + +Message type names should be as concise possible without losing clarity. `sdk.Msg` +types which are used in transactions will retain the `Msg` prefix as that provides +helpful context. + +### Service and RPC Naming + +[ADR 021](adr-021-protobuf-query-encoding.md) specifies that modules should +implement a gRPC query service. We should consider the principle of conciseness +for query service and RPC names as these may be called from persistent script +modules such as CosmWasm. Also, users may use these query paths from tools like +[gRPCurl](https://github.com/fullstorydev/grpcurl). As an example, we can shorten +`/cosmos_sdk.x.bank.v1.QueryService/QueryBalance` to +`/cosmos.bank.Query/Balance` without losing much useful information. + +RPC request and response types _should_ follow the `ServiceNameMethodNameRequest`/ +`ServiceNameMethodNameResponse` naming convention. i.e. for an RPC method named `Balance` +on the `Query` service, the request and response types would be `QueryBalanceRequest` +and `QueryBalanceResponse`. This will be more self-explanatory than `BalanceRequest` +and `BalanceResponse`. + +#### Use just `Query` for the query service + +Instead of [Buf's default service suffix recommendation](https://github.com/cosmos/cosmos-sdk/pull/6033), +we should simply use the shorter `Query` for query services. + +For other types of gRPC services, we should consider sticking with Buf's +default recommendation. + +#### Omit `Get` and `Query` from query service RPC names + +`Get` and `Query` should be omitted from `Query` service names because they are +redundant in the fully-qualified name. For instance, `/cosmos.bank.Query/QueryBalance` +just says `Query` twice without any new information. + +## Future Improvements + +A registry of top-level package names should be created to coordinate naming +across the ecosystem, prevent collisions, and also help developers discover +useful schemas. A simple starting point would be a git repository with +community-based governance. + +## Consequences + +### Positive + +* names will be more concise and easier to read and type +* all transactions using `Any` will be at shorter (`_sdk.x` and `.v1` will be removed) +* `.proto` file imports will be more standard (without `"third_party/proto"` in +the path) +* code generation will be easier for clients because .proto files will be +in a single `proto/` directory which can be copied rather than scattered +throughout the Cosmos SDK + +### Negative + +### Neutral + +* `.proto` files will need to be reorganized and refactored +* some modules may need to be marked as alpha or beta + +## References diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-024-coin-metadata.md b/versioned_docs/version-0.46/integrate/architecture/adr-024-coin-metadata.md new file mode 100644 index 000000000..3c55f80f0 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-024-coin-metadata.md @@ -0,0 +1,139 @@ +# ADR 024: Coin Metadata + +## Changelog + +* 05/19/2020: Initial draft + +## Status + +Proposed + +## Context + +Assets in the Cosmos SDK are represented via a `Coins` type that consists of an `amount` and a `denom`, +where the `amount` can be any arbitrarily large or small value. In addition, the Cosmos SDK uses an +account-based model where there are two types of primary accounts -- basic accounts and module accounts. +All account types have a set of balances that are composed of `Coins`. The `x/bank` module keeps +track of all balances for all accounts and also keeps track of the total supply of balances in an +application. + +With regards to a balance `amount`, the Cosmos SDK assumes a static and fixed unit of denomination, +regardless of the denomination itself. In other words, clients and apps built atop a Cosmos-SDK-based +chain may choose to define and use arbitrary units of denomination to provide a richer UX, however, by +the time a tx or operation reaches the Cosmos SDK state machine, the `amount` is treated as a single +unit. For example, for the Cosmos Hub (Gaia), clients assume 1 ATOM = 10^6 uatom, and so all txs and +operations in the Cosmos SDK work off of units of 10^6. + +This clearly provides a poor and limited UX especially as interoperability of networks increases and +as a result the total amount of asset types increases. We propose to have `x/bank` additionally keep +track of metadata per `denom` in order to help clients, wallet providers, and explorers improve their +UX and remove the requirement for making any assumptions on the unit of denomination. + +## Decision + +The `x/bank` module will be updated to store and index metadata by `denom`, specifically the "base" or +smallest unit -- the unit the Cosmos SDK state-machine works with. + +Metadata may also include a non-zero length list of denominations. Each entry contains the name of +the denomination `denom`, the exponent to the base and a list of aliases. An entry is to be +interpreted as `1 denom = 10^exponent base_denom` (e.g. `1 ETH = 10^18 wei` and `1 uatom = 10^0 uatom`). + +There are two denominations that are of high importance for clients: the `base`, which is the smallest +possible unit and the `display`, which is the unit that is commonly referred to in human communication +and on exchanges. The values in those fields link to an entry in the list of denominations. + +The list in `denom_units` and the `display` entry may be changed via governance. + +As a result, we can define the type as follows: + +```protobuf +message DenomUnit { + string denom = 1; + uint32 exponent = 2; + repeated string aliases = 3; +} + +message Metadata { + string description = 1; + repeated DenomUnit denom_units = 2; + string base = 3; + string display = 4; +} +``` + +As an example, the ATOM's metadata can be defined as follows: + +```json +{ + "description": "The native staking token of the Cosmos Hub.", + "denom_units": [ + { + "denom": "uatom", + "exponent": 0, + "aliases": [ + "microatom" + ], + }, + { + "denom": "matom", + "exponent": 3, + "aliases": [ + "milliatom" + ] + }, + { + "denom": "atom", + "exponent": 6, + } + ], + "base": "uatom", + "display": "atom", +} +``` + +Given the above metadata, a client may infer the following things: + +* 4.3atom = 4.3 * (10^6) = 4,300,000uatom +* The string "atom" can be used as a display name in a list of tokens. +* The balance 4300000 can be displayed as 4,300,000uatom or 4,300matom or 4.3atom. + The `display` denomination 4.3atom is a good default if the authors of the client don't make + an explicit decision to choose a different representation. + +A client should be able to query for metadata by denom both via the CLI and REST interfaces. In +addition, we will add handlers to these interfaces to convert from any unit to another given unit, +as the base framework for this already exists in the Cosmos SDK. + +Finally, we need to ensure metadata exists in the `GenesisState` of the `x/bank` module which is also +indexed by the base `denom`. + +```go +type GenesisState struct { + SendEnabled bool `json:"send_enabled" yaml:"send_enabled"` + Balances []Balance `json:"balances" yaml:"balances"` + Supply sdk.Coins `json:"supply" yaml:"supply"` + DenomMetadata []Metadata `json:"denom_metadata" yaml:"denom_metadata"` +} +``` + +## Future Work + +In order for clients to avoid having to convert assets to the base denomination -- either manually or +via an endpoint, we may consider supporting automatic conversion of a given unit input. + +## Consequences + +### Positive + +* Provides clients, wallet providers and block explorers with additional data on + asset denomination to improve UX and remove any need to make assumptions on + denomination units. + +### Negative + +* A small amount of required additional storage in the `x/bank` module. The amount + of additional storage should be minimal as the amount of total assets should not + be large. + +### Neutral + +## References diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-027-deterministic-protobuf-serialization.md b/versioned_docs/version-0.46/integrate/architecture/adr-027-deterministic-protobuf-serialization.md new file mode 100644 index 000000000..a4602c264 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-027-deterministic-protobuf-serialization.md @@ -0,0 +1,314 @@ +# ADR 027: Deterministic Protobuf Serialization + +## Changelog + +* 2020-08-07: Initial Draft +* 2020-09-01: Further clarify rules + +## Status + +Proposed + +## Abstract + +Fully deterministic structure serialization, which works across many languages and clients, +is needed when signing messages. We need to be sure that whenever we serialize +a data structure, no matter in which supported language, the raw bytes +will stay the same. +[Protobuf](https://developers.google.com/protocol-buffers/docs/proto3) +serialization is not bijective (i.e. there exist a practically unlimited number of +valid binary representations for a given protobuf document)1. + +This document describes a deterministic serialization scheme for +a subset of protobuf documents, that covers this use case but can be reused in +other cases as well. + +### Context + +For signature verification in Cosmos SDK, the signer and verifier need to agree on +the same serialization of a `SignDoc` as defined in +[ADR-020](./adr-020-protobuf-transaction-encoding.md) without transmitting the +serialization. + +Currently, for block signatures we are using a workaround: we create a new [TxRaw](https://github.com/cosmos/cosmos-sdk/blob/9e85e81e0e8140067dd893421290c191529c148c/proto/cosmos/tx/v1beta1/tx.proto#L30) +instance (as defined in [adr-020-protobuf-transaction-encoding](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-020-protobuf-transaction-encoding.md#transactions)) +by converting all [Tx](https://github.com/cosmos/cosmos-sdk/blob/9e85e81e0e8140067dd893421290c191529c148c/proto/cosmos/tx/v1beta1/tx.proto#L13) +fields to bytes on the client side. This adds an additional manual +step when sending and signing transactions. + +### Decision + +The following encoding scheme is to be used by other ADRs, +and in particular for `SignDoc` serialization. + +## Specification + +### Scope + +This ADR defines a protobuf3 serializer. The output is a valid protobuf +serialization, such that every protobuf parser can parse it. + +No maps are supported in version 1 due to the complexity of defining a +deterministic serialization. This might change in future. Implementations must +reject documents containing maps as invalid input. + +### Background - Protobuf3 Encoding + +Most numeric types in protobuf3 are encoded as +[varints](https://developers.google.com/protocol-buffers/docs/encoding#varints). +Varints are at most 10 bytes, and since each varint byte has 7 bits of data, +varints are a representation of `uint70` (70-bit unsigned integer). When +encoding, numeric values are casted from their base type to `uint70`, and when +decoding, the parsed `uint70` is casted to the appropriate numeric type. + +The maximum valid value for a varint that complies with protobuf3 is +`FF FF FF FF FF FF FF FF FF 7F` (i.e. `2**70 -1`). If the field type is +`{,u,s}int64`, the highest 6 bits of the 70 are dropped during decoding, +introducing 6 bits of malleability. If the field type is `{,u,s}int32`, the +highest 38 bits of the 70 are dropped during decoding, introducing 38 bits of +malleability. + +Among other sources of non-determinism, this ADR eliminates the possibility of +encoding malleability. + +### Serialization rules + +The serialization is based on the +[protobuf3 encoding](https://developers.google.com/protocol-buffers/docs/encoding) +with the following additions: + +1. Fields must be serialized only once in ascending order +2. Extra fields or any extra data must not be added +3. [Default values](https://developers.google.com/protocol-buffers/docs/proto3#default) + must be omitted +4. `repeated` fields of scalar numeric types must use + [packed encoding](https://developers.google.com/protocol-buffers/docs/encoding#packed) +5. Varint encoding must not be longer than needed: + * No trailing zero bytes (in little endian, i.e. no leading zeroes in big + endian). Per rule 3 above, the default value of `0` must be omitted, so + this rule does not apply in such cases. + * The maximum value for a varint must be `FF FF FF FF FF FF FF FF FF 01`. + In other words, when decoded, the highest 6 bits of the 70-bit unsigned + integer must be `0`. (10-byte varints are 10 groups of 7 bits, i.e. + 70 bits, of which only the lowest 70-6=64 are useful.) + * The maximum value for 32-bit values in varint encoding must be `FF FF FF FF 0F` + with one exception (below). In other words, when decoded, the highest 38 + bits of the 70-bit unsigned integer must be `0`. + * The one exception to the above is _negative_ `int32`, which must be + encoded using the full 10 bytes for sign extension2. + * The maximum value for Boolean values in varint encoding must be `01` (i.e. + it must be `0` or `1`). Per rule 3 above, the default value of `0` must + be omitted, so if a Boolean is included it must have a value of `1`. + +While rule number 1. and 2. should be pretty straight forward and describe the +default behavior of all protobuf encoders the author is aware of, the 3rd rule +is more interesting. After a protobuf3 deserialization you cannot differentiate +between unset fields and fields set to the default value3. At +serialization level however, it is possible to set the fields with an empty +value or omitting them entirely. This is a significant difference to e.g. JSON +where a property can be empty (`""`, `0`), `null` or undefined, leading to 3 +different documents. + +Omitting fields set to default values is valid because the parser must assign +the default value to fields missing in the serialization4. For scalar +types, omitting defaults is required by the spec5. For `repeated` +fields, not serializing them is the only way to express empty lists. Enums must +have a first element of numeric value 0, which is the default6. And +message fields default to unset7. + +Omitting defaults allows for some amount of forward compatibility: users of +newer versions of a protobuf schema produce the same serialization as users of +older versions as long as newly added fields are not used (i.e. set to their +default value). + +### Implementation + +There are three main implementation strategies, ordered from the least to the +most custom development: + +* **Use a protobuf serializer that follows the above rules by default.** E.g. + [gogoproto](https://pkg.go.dev/github.com/gogo/protobuf/gogoproto) is known to + be compliant by in most cases, but not when certain annotations such as + `nullable = false` are used. It might also be an option to configure an + existing serializer accordingly. +* **Normalize default values before encoding them.** If your serializer follows + rule 1. and 2. and allows you to explicitly unset fields for serialization, + you can normalize default values to unset. This can be done when working with + [protobuf.js](https://www.npmjs.com/package/protobufjs): + + ```js + const bytes = SignDoc.encode({ + bodyBytes: body.length > 0 ? body : null, // normalize empty bytes to unset + authInfoBytes: authInfo.length > 0 ? authInfo : null, // normalize empty bytes to unset + chainId: chainId || null, // normalize "" to unset + accountNumber: accountNumber || null, // normalize 0 to unset + accountSequence: accountSequence || null, // normalize 0 to unset + }).finish(); + ``` + +* **Use a hand-written serializer for the types you need.** If none of the above + ways works for you, you can write a serializer yourself. For SignDoc this + would look something like this in Go, building on existing protobuf utilities: + + ```go + if !signDoc.body_bytes.empty() { + buf.WriteUVarInt64(0xA) // wire type and field number for body_bytes + buf.WriteUVarInt64(signDoc.body_bytes.length()) + buf.WriteBytes(signDoc.body_bytes) + } + + if !signDoc.auth_info.empty() { + buf.WriteUVarInt64(0x12) // wire type and field number for auth_info + buf.WriteUVarInt64(signDoc.auth_info.length()) + buf.WriteBytes(signDoc.auth_info) + } + + if !signDoc.chain_id.empty() { + buf.WriteUVarInt64(0x1a) // wire type and field number for chain_id + buf.WriteUVarInt64(signDoc.chain_id.length()) + buf.WriteBytes(signDoc.chain_id) + } + + if signDoc.account_number != 0 { + buf.WriteUVarInt64(0x20) // wire type and field number for account_number + buf.WriteUVarInt(signDoc.account_number) + } + + if signDoc.account_sequence != 0 { + buf.WriteUVarInt64(0x28) // wire type and field number for account_sequence + buf.WriteUVarInt(signDoc.account_sequence) + } + ``` + +### Test vectors + +Given the protobuf definition `Article.proto` + +```protobuf +package blog; +syntax = "proto3"; + +enum Type { + UNSPECIFIED = 0; + IMAGES = 1; + NEWS = 2; +}; + +enum Review { + UNSPECIFIED = 0; + ACCEPTED = 1; + REJECTED = 2; +}; + +message Article { + string title = 1; + string description = 2; + uint64 created = 3; + uint64 updated = 4; + bool public = 5; + bool promoted = 6; + Type type = 7; + Review review = 8; + repeated string comments = 9; + repeated string backlinks = 10; +}; +``` + +serializing the values + +```yaml +title: "The world needs change 🌳" +description: "" +created: 1596806111080 +updated: 0 +public: true +promoted: false +type: Type.NEWS +review: Review.UNSPECIFIED +comments: ["Nice one", "Thank you"] +backlinks: [] +``` + +must result in the serialization + +```text +0a1b54686520776f726c64206e65656473206368616e676520f09f8cb318e8bebec8bc2e280138024a084e696365206f6e654a095468616e6b20796f75 +``` + +When inspecting the serialized document, you see that every second field is +omitted: + +```sh +$ echo 0a1b54686520776f726c64206e65656473206368616e676520f09f8cb318e8bebec8bc2e280138024a084e696365206f6e654a095468616e6b20796f75 | xxd -r -p | protoc --decode_raw +1: "The world needs change \360\237\214\263" +3: 1596806111080 +5: 1 +7: 2 +9: "Nice one" +9: "Thank you" +``` + +## Consequences + +Having such an encoding available allows us to get deterministic serialization +for all protobuf documents we need in the context of Cosmos SDK signing. + +### Positive + +* Well defined rules that can be verified independent of a reference + implementation +* Simple enough to keep the barrier to implement transaction signing low +* It allows us to continue to use 0 and other empty values in SignDoc, avoiding + the need to work around 0 sequences. This does not imply the change from + https://github.com/cosmos/cosmos-sdk/pull/6949 should not be merged, but not + too important anymore. + +### Negative + +* When implementing transaction signing, the encoding rules above must be + understood and implemented. +* The need for rule number 3. adds some complexity to implementations. +* Some data structures may require custom code for serialization. Thus + the code is not very portable - it will require additional work for each + client implementing serialization to properly handle custom data structures. + +### Neutral + +### Usage in Cosmos SDK + +For the reasons mentioned above ("Negative" section) we prefer to keep workarounds +for shared data structure. Example: the aforementioned `TxRaw` is using raw bytes +as a workaround. This allows them to use any valid Protobuf library without +the need of implementing a custom serializer that adheres to this standard (and related risks of bugs). + +## References + +* 1 _When a message is serialized, there is no guaranteed order for + how its known or unknown fields should be written. Serialization order is an + implementation detail and the details of any particular implementation may + change in the future. Therefore, protocol buffer parsers must be able to parse + fields in any order._ from + https://developers.google.com/protocol-buffers/docs/encoding#order +* 2 https://developers.google.com/protocol-buffers/docs/encoding#signed_integers +* 3 _Note that for scalar message fields, once a message is parsed + there's no way of telling whether a field was explicitly set to the default + value (for example whether a boolean was set to false) or just not set at all: + you should bear this in mind when defining your message types. For example, + don't have a boolean that switches on some behavior when set to false if you + don't want that behavior to also happen by default._ from + https://developers.google.com/protocol-buffers/docs/proto3#default +* 4 _When a message is parsed, if the encoded message does not + contain a particular singular element, the corresponding field in the parsed + object is set to the default value for that field._ from + https://developers.google.com/protocol-buffers/docs/proto3#default +* 5 _Also note that if a scalar message field is set to its default, + the value will not be serialized on the wire._ from + https://developers.google.com/protocol-buffers/docs/proto3#default +* 6 _For enums, the default value is the first defined enum value, + which must be 0._ from + https://developers.google.com/protocol-buffers/docs/proto3#default +* 7 _For message fields, the field is not set. Its exact value is + language-dependent._ from + https://developers.google.com/protocol-buffers/docs/proto3#default +* Encoding rules and parts of the reasoning taken from + [canonical-proto3 Aaron Craelius](https://github.com/regen-network/canonical-proto3) diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-028-public-key-addresses.md b/versioned_docs/version-0.46/integrate/architecture/adr-028-public-key-addresses.md new file mode 100644 index 000000000..8da5b70d0 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-028-public-key-addresses.md @@ -0,0 +1,329 @@ +# ADR 028: Public Key Addresses + +## Changelog + +* 2020/08/18: Initial version +* 2021/01/15: Analysis and algorithm update + +## 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. + +## 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. + +### 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. + +### 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: + +> I spent quite a bit of time thinking about this issue while building weave... The other cosmos Sdk. +> Basically I define a condition to be a type and format as human readable string with some binary data appended. This condition is hashed into an Address (again at 20 bytes). The use of this prefix makes it impossible to find a preimage for a given address with a different condition (eg ed25519 vs secp256k1). +> This is explained in depth here https://weave.readthedocs.io/en/latest/design/permissions.html +> And the code is here, look mainly at the top where we process conditions. https://github.com/iov-one/weave/blob/master/conditions.go + +And explained how this approach should be sufficiently collision resistant: + +> Yeah, AFAIK, 20 bytes should be collision resistance when the preimages are unique and not malleable. A space of 2^160 would expect some collision to be likely around 2^80 elements (birthday paradox). And if you want to find a collision for some existing element in the database, it is still 2^160. 2^80 only is if all these elements are written to state. +> The good example you brought up was eg. a public key bytes being a valid public key on two algorithms supported by the codec. Meaning if either was broken, you would break accounts even if they were secured with the safer variant. This is only as the issue when no differentiating type info is present in the preimage (before hashing into an address). +> I would like to hear an argument if the 20 bytes space is an actual issue for security, as I would be happy to increase my address sizes in weave. I just figured cosmos and ethereum and bitcoin all use 20 bytes, it should be good enough. And the arguments above which made me feel it was secure. But I have not done a deeper analysis. + +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]`. + +### 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. + +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. + +### 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. + +### 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. + +## 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 + +### 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: + +* secp256k1: `ripemd160(sha256(pk_bytes))[:20]` +* legacy amino multisig: `sha256(aminoCdc.Marshal(pk))[:20]` + +We don't want to change existing addresses. So the addresses for these two key types will remain the same. + +The current multisig public keys use amino serialization to generate the address. We will retain +those public keys and their address formatting, and call them "legacy amino" multisig public keys +in protobuf. We will also create multisig public keys without amino addresses to be described below. + +### Hash Function Choice + +As in other parts of the Cosmos SDK, we will use `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. + +```go +const A_LEN = 32 + +func Hash(typ string, key []byte) []byte { + return hash(hash(typ) + key)[:A_LEN] +} +``` + +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. + +We use the `address.Hash` function for generating addresses for all accounts represented by a single key: + +* simple public keys: `address.Hash(keyType, pubkey)` + +* aggregated keys (eg: BLS): `address.Hash(keyType, aggregatedPubKey)` +* modules: `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. + +```go +// We don't need a PubKey interface - we need anything which is addressable. +type Addressable interface { + Address() []byte +} + +func Composed(typ string, subaccounts []Addressable) []byte { + addresses = map(subaccounts, \a -> LengthPrefix(a.Address())) + addresses = sort(addresses) + return address.Hash(typ, addresses[0] + ... + addresses[n]) +} +``` + +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`. + +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. + +Example: + +```proto +package cosmos.crypto.multisig; + +message PubKey { + uint32 threshold = 1; + repeated google.protobuf.Any pubkeys = 2; +} +``` + +```go +func (multisig PubKey) Address() { + // 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 + prefix := fmt.Sprintf("%s/%d", proto.MessageName(multisig), multisig.Threshold) + + // 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. + +```go +func Module(moduleName string, key []byte) []byte{ + return Hash("module", []byte(moduleName) + 0 + key) +} +``` + +**Example** A lending BTC pool address would be: + +```go +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: + +```go +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: + +```go +func Derive(address []byte, derivationKey []byte) []byte { + return Hash(addres, derivationKey) +} +``` + +Note: `Module` is a special case of the more general _derived_ address, where we set the `"module"` string for the _from address_. + +**Example** For a cosmwasm smart-contract address we could use the following construction: + +```go +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. + +Example: all public key types have a unique protobuf message type similar to: + +```proto +package cosmos.crypto.sr25519; + +message PubKey { + bytes key = 1; +} +``` + +All protobuf messages have unique fully qualified names, in this example `cosmos.crypto.sr25519.PubKey`. +These names are derived directly from .proto files in a standardized way and used +in other places such as the type URL in `Any`s. We can easily obtain the name using +`proto.MessageName(msg)`. + +## Consequences + +### Backwards Compatibility + +This ADR is compatible with what was committed and directly supported in the Cosmos SDK repository. + +### 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. + +### 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 + +### Neutral + +* protobuf message names are used as key type prefixes + +## 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. + +## 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. + +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 + +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. + +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. + +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). + +Discssion about arithmetic hash function for 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. + +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. + +### References + +* [Notes](https://hackmd.io/_NGWI4xZSbKzj1BkCqyZMw) diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-029-fee-grant-module.md b/versioned_docs/version-0.46/integrate/architecture/adr-029-fee-grant-module.md new file mode 100644 index 000000000..5e026d604 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-029-fee-grant-module.md @@ -0,0 +1,153 @@ +# ADR 029: Fee Grant Module + +## Changelog + +* 2020/08/18: Initial Draft +* 2021/05/05: Removed height based expiration support and simplified naming. + +## Status + +Accepted + +## Context + +In order to make blockchain transactions, the signing account must possess a sufficient balance of the right denomination +in order to pay fees. There are classes of transactions where needing to maintain a wallet with sufficient fees is a +barrier to adoption. + +For instance, when proper permissions are setup, someone may temporarily delegate the ability to vote on proposals to +a "burner" account that is stored on a mobile phone with only minimal security. + +Other use cases include workers tracking items in a supply chain or farmers submitting field data for analytics +or compliance purposes. + +For all of these use cases, UX would be significantly enhanced by obviating the need for these accounts to always +maintain the appropriate fee balance. This is especially true if we wanted to achieve enterprise adoption for something +like supply chain tracking. + +While one solution would be to have a service that fills up these accounts automatically with the appropriate fees, a better UX +would be provided by allowing these accounts to pull from a common fee pool account with proper spending limits. +A single pool would reduce the churn of making lots of small "fill up" transactions and also more effectively leverages +the resources of the organization setting up the pool. + +## Decision + +As a solution we propose a module, `x/feegrant` which allows one account, the "granter" to grant another account, the "grantee" +an allowance to spend the granter's account balance for fees within certain well-defined limits. + +Fee allowances are defined by the extensible `FeeAllowanceI` interface: + +```go +type FeeAllowanceI { + // Accept can use fee payment requested as well as timestamp 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() error +} +``` + +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. +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. + repeated cosmos_sdk.v1.Coin spend_limit = 1; + + // 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. +message PeriodicAllowance { + BasicAllowance basic = 1; + + // 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 + repeated cosmos_sdk.v1.Coin period_spend_limit = 3; + + // period_can_spend is the number of coins left to be spent before the period_reset time + repeated cosmos_sdk.v1.Coin period_can_spend = 4; + + // period_reset is the time at which this period resets and a new one begins, + // it is calculated from the start time of the first transaction after the + // last period ended + google.protobuf.Timestamp period_reset = 5; +} + +``` + +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. +message MsgGrantAllowance { + string granter = 1; + string grantee = 2; + google.protobuf.Any allowance = 3; + } + + // MsgRevokeAllowance removes any existing FeeAllowance from Granter to Grantee. + message MsgRevokeAllowance { + string granter = 1; + string grantee = 2; + } +``` + +In order to use allowances in transactions, we add a new field `granter` to the transaction `Fee` type: + +```proto +package cosmos.tx.v1beta1; + +message Fee { + repeated cosmos.base.v1beta1.Coin amount = 1; + uint64 gas_limit = 2; + string payer = 3; + string granter = 4; +} +``` + +`granter` must either be left empty or must correspond to an account which has granted +a fee allowance to fee payer (either the first signer or the value of the `payer` field). + +A new `AnteDecorator` named `DeductGrantedFeeDecorator` will be created in order to process transactions with `fee_payer` +set and correctly deduct fees based on fee allowances. + +## Consequences + +### Positive + +* improved UX for use cases where it is cumbersome to maintain an account balance just for fees + +### Negative + +### Neutral + +* a new field must be added to the transaction `Fee` message and a new `AnteDecorator` must be +created to use it + +## References + +* Blog article describing initial work: https://medium.com/regen-network/hacking-the-cosmos-cosmwasm-and-key-management-a08b9f561d1b +* Initial public specification: https://gist.github.com/aaronc/b60628017352df5983791cad30babe56 +* Original subkeys proposal from B-harvest which influenced this design: https://github.com/cosmos/cosmos-sdk/issues/4480 diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-030-authz-module.md b/versioned_docs/version-0.46/integrate/architecture/adr-030-authz-module.md new file mode 100644 index 000000000..1390d0f6b --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-030-authz-module.md @@ -0,0 +1,259 @@ +# ADR 030: Authorization Module + +## 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) +* 2022-04-20: Updated the `SendAuthorization` proto docs to clarify the `SpendLimit` is a required field. (Generic authorization can be used with bank msg type url to create limit less bank authorization) + +## 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. + +## 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). + +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). + +## 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. + +### 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. + +#### 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() string + + // 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() error +} + +// 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. + Accept bool + // 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. + Updated Authorization +} +``` + +For example a `SendAuthorization` like this is defined for `MsgSend` that takes +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. This field is required. (Generic authorization + // can be used with bank msg type url to create limit less bank authorization). + SpendLimit sdk.Coins +} + +func (a SendAuthorization) MsgTypeURL() string { + return sdk.MsgTypeURL(&MsgSend{}) +} + +func (a SendAuthorization) Accept(ctx sdk.Context, msg sdk.Msg) (authz.AcceptResponse, error) { + mSend, ok := msg.(*MsgSend) + if !ok { + return authz.AcceptResponse{}, sdkerrors.ErrInvalidType.Wrap("type mismatch") + } + limitLeft, isNegative := a.SpendLimit.SafeSub(mSend.Amount) + if isNegative { + return authz.AcceptResponse{}, sdkerrors.ErrInsufficientFunds.Wrapf("requested amount is more than spend limit") + } + if limitLeft.IsZero() { + return authz.AcceptResponse{Accept: true, Delete: true}, nil + } + + return authz.AcceptResponse{Accept: true, Delete: false, Updated: &SendAuthorization{SpendLimit: limitLeft}}, nil +} +``` + +A different type of capability for `MsgSend` could be implemented +using the `Authorization` interface with no need to change the underlying +`bank` module. + +##### Small notes on `AcceptResponse` + +- The `AcceptResponse.Accept` field will be set to `true` if the authorization is accepted. +However, if it is rejected, the function `Accept` will raise an error (without setting `AcceptResponse.Accept` to `false`). + +- The `AcceptResponse.Updated` field will be set to a non-nil value only if there is a real change to the authorization. +If authorization remains the same (as is, for instance, always the case for a [`GenericAuthorization`](#genericauthorization)), +the field will be `nil`. + +### `Msg` Service + +```proto +service Msg { + // 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. + 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. + rpc Revoke(MsgRevoke) returns (MsgRevokeResponse); +} + +// 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]; +} + +message MsgGrant { + string granter = 1; + string grantee = 2; + + Grant grant = 3 [(gogoproto.nullable) = false]; +} + +message MsgExecResponse { + cosmos.base.abci.v1beta1.Result result = 1; +} + +message MsgExec { + string grantee = 1; + // 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: + +```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(ctx sdk.Context, grantee sdk.AccAddress, msgs []sdk.Msg) sdk.Result` +} +``` + +### CLI + +#### `tx exec` Method + +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: + +```go +MsgExec { + Grantee: mykey, + Msgs: []sdk.Msg{ + MsgVote { + ProposalID: 1, + Voter: cosmos3thsdgh983egh823 + Option: Yes + } + } +} +``` + +#### `tx grant --from ` + +This CLI command will send a `MsgGrant` transaction. `authorization` should be encoded as +JSON on the CLI. + +#### `tx revoke --from ` + +This CLI command will send a `MsgRevoke` transaction. + +### Built-in Authorizations + +#### `SendAuthorization` + +```proto +// 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; +} +``` + +#### `GenericAuthorization` + +```proto +// 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 + 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 + +### 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 diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-031-msg-service.md b/versioned_docs/version-0.46/integrate/architecture/adr-031-msg-service.md new file mode 100644 index 000000000..0fcc6b4df --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-031-msg-service.md @@ -0,0 +1,202 @@ +# ADR 031: Protobuf Msg Services + +## 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). + +## Status + +Accepted + +## Abstract + +We want to leverage protobuf `service` definitions for defining `Msg`s which will give us significant developer UX +improvements in terms of the code that is generated and the fact that return types will now be well defined. + +## Context + +Currently `Msg` handlers in the Cosmos SDK do have return values that are placed in the `data` field of the response. +These return values, however, are not specified anywhere except in the golang handler code. + +In early conversations [it was proposed](https://docs.google.com/document/d/1eEgYgvgZqLE45vETjhwIw4VOqK-5hwQtZtjVbiXnIGc/edit) +that `Msg` return types be captured using a protobuf extension field, ex: + +```protobuf +package cosmos.gov; + +message MsgSubmitProposal + option (cosmos_proto.msg_return) = “uint64”; + string delegator_address = 1; + string validator_address = 2; + repeated sdk.Coin amount = 3; +} +``` + +This was never adopted, however. + +Having a well-specified return value for `Msg`s would improve client UX. For instance, +in `x/gov`, `MsgSubmitProposal` returns the proposal ID as a big-endian `uint64`. +This isn’t really documented anywhere and clients would need to know the internals +of the Cosmos SDK to parse that value and return it to users. + +Also, there may be cases where we want to use these return values programatically. +For instance, https://github.com/cosmos/cosmos-sdk/issues/7093 proposes a method for +doing inter-module Ocaps using the `Msg` router. A well-defined return type would +improve the developer UX for this approach. + +In addition, handler registration of `Msg` types tends to add a bit of +boilerplate on top of keepers and is usually done through manual type switches. +This isn't necessarily bad, but it does add overhead to creating modules. + +## Decision + +We decide to use protobuf `service` definitions for defining `Msg`s as well as +the code generated by them as a replacement for `Msg` handlers. + +Below we define how this will look for the `SubmitProposal` message from `x/gov` module. +We start with a `Msg` `service` definition: + +```proto +package cosmos.gov; + +service Msg { + rpc SubmitProposal(MsgSubmitProposal) returns (MsgSubmitProposalResponse); +} + +// Note that for backwards compatibility this uses MsgSubmitProposal as the request +// type instead of the more canonical MsgSubmitProposalRequest +message MsgSubmitProposal { + google.protobuf.Any content = 1; + string proposer = 2; +} + +message MsgSubmitProposalResponse { + uint64 proposal_id; +} +``` + +While this is most commonly used for gRPC, overloading protobuf `service` definitions like this does not violate +the intent of the [protobuf spec](https://developers.google.com/protocol-buffers/docs/proto3#services) which says: +> If you don’t want to use gRPC, it’s also possible to use protocol buffers with your own RPC implementation. +With this approach, we would get an auto-generated `MsgServer` interface: + +In addition to clearly specifying return types, this has the benefit of generating client and server code. On the server +side, this is almost like an automatically generated keeper method and could maybe be used intead of keepers eventually +(see [\#7093](https://github.com/cosmos/cosmos-sdk/issues/7093)): + +```go +package gov + +type MsgServer interface { + SubmitProposal(context.Context, *MsgSubmitProposal) (*MsgSubmitProposalResponse, error) +} +``` + +On the client side, developers could take advantage of this by creating RPC implementations that encapsulate transaction +logic. Protobuf libraries that use asynchronous callbacks, like [protobuf.js](https://github.com/protobufjs/protobuf.js#using-services) +could use this to register callbacks for specific messages even for transactions that include multiple `Msg`s. + +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. + +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`. + +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. + +### 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. + +### 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). + +### 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. + +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. + +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. + +### Module Configuration + +In [ADR 021](./adr-021-protobuf-query-encoding.md), we introduced a method `RegisterQueryService` +to `AppModule` which allows for modules to register gRPC queriers. + +To register `Msg` services, we attempt a more extensible approach by converting `RegisterQueryService` +to a more generic `RegisterServices` method: + +```go +type AppModule interface { + RegisterServices(Configurator) + ... +} + +type Configurator interface { + QueryServer() grpc.Server + MsgServer() grpc.Server +} + +// example module: +func (am AppModule) RegisterServices(cfg Configurator) { + types.RegisterQueryServer(cfg.QueryServer(), keeper) + types.RegisterMsgServer(cfg.MsgServer(), keeper) +} +``` + +The `RegisterServices` method and the `Configurator` interface are intended to +evolve to satisfy the use cases discussed in [\#7093](https://github.com/cosmos/cosmos-sdk/issues/7093) +and [\#7122](https://github.com/cosmos/cosmos-sdk/issues/7421). + +When `Msg` services are registered, the framework _should_ verify that all `Msg` types +implement the `sdk.Msg` interface and throw an error during initialization rather +than later when transactions are processed. + +### `Msg` Service Implementation + +Just like query services, `Msg` service methods can retrieve the `sdk.Context` +from the `context.Context` parameter method using the `sdk.UnwrapSDKContext` +method: + +```go +package gov + +func (k Keeper) SubmitProposal(goCtx context.Context, params *types.MsgSubmitProposal) (*MsgSubmitProposalResponse, error) { + ctx := sdk.UnwrapSDKContext(goCtx) + ... +} +``` + +The `sdk.Context` should have an `EventManager` already attached by BaseApp's `msg_service_router`. + +Separate handler definition is no longer needed with this approach. + +## Consequences + +This design changes how a module functionality is exposed and accessed. It deprecates the existing `Handler` interface and `AppModule.Route` in favor of [Protocol Buffer Services](https://developers.google.com/protocol-buffers/docs/proto3#services) and Service Routing described above. This dramatically simplifies the code. We don't need to create handlers and keepers any more. Use of Protocol Buffer auto-generated clients clearly separates the communication interfaces between the module and a modules user. The control logic (aka handlers and keepers) is not exposed any more. A module interface can be seen as a black box accessible through a client API. It's worth to note that the client interfaces are also generated by Protocol Buffers. + +This also allows us to change how we perform functional tests. Instead of mocking AppModules and Router, we will mock a client (server will stay hidden). More specifically: we will never mock `moduleA.MsgServer` in `moduleB`, but rather `moduleA.MsgClient`. One can think about it as working with external services (eg DBs, or online servers...). We assume that the transmission between clients and servers is correctly handled by generated Protocol Buffers. + +Finally, closing a module to client API opens desirable OCAP patterns discussed in ADR-033. Since server implementation and interface is hidden, nobody can hold "keepers"/servers and will be forced to relay on the client interface, which will drive developers for correct encapsulation and software engineering patterns. + +### Pros + +* communicates return type clearly +* manual handler registration and return type marshaling is no longer needed, just implement the interface and register it +* communication interface is automatically generated, the developer can now focus only on the state transition methods - this would improve the UX of [\#7093](https://github.com/cosmos/cosmos-sdk/issues/7093) approach (1) if we chose to adopt that +* generated client code could be useful for clients and tests +* dramatically reduces and simplifies the code + +### Cons + +* using `service` definitions outside the context of gRPC could be confusing (but doesn’t violate the proto3 spec) + +## References + +* [Initial Github Issue \#7122](https://github.com/cosmos/cosmos-sdk/issues/7122) +* [proto 3 Language Guide: Defining Services](https://developers.google.com/protocol-buffers/docs/proto3#services) +* [Initial pre-`Any` `Msg` designs](https://docs.google.com/document/d/1eEgYgvgZqLE45vETjhwIw4VOqK-5hwQtZtjVbiXnIGc) +* [ADR 020](./adr-020-protobuf-transaction-encoding.md) +* [ADR 021](./adr-021-protobuf-query-encoding.md) diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-032-typed-events.md b/versioned_docs/version-0.46/integrate/architecture/adr-032-typed-events.md new file mode 100644 index 000000000..1e769f450 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-032-typed-events.md @@ -0,0 +1,319 @@ +# ADR 032: Typed Events + +## Changelog + +* 28-Sept-2020: Initial Draft + +## Authors + +* Anil Kumar (@anilcse) +* Jack Zampolin (@jackzampolin) +* Adam Bozanich (@boz) + +## Status + +Proposed + +## Abstract + +Currently in the 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. + +## 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. + +[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. + +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. + +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. + +The end of this proposal contains a detailed example of how to consume events after this refactor. + +This proposal is specifically about how to consume these events as a client of the blockchain, not for intermodule communication. + +## Decision + +**Step-1**: Implement additional functionality in the `types` package: `EmitTypedEvent` and `ParseTypedEvent` functions + +```go +// types/events.go + +// EmitTypedEvent takes typed event and emits converting it into sdk.Event +func (em *EventManager) EmitTypedEvent(event proto.Message) error { + evtType := proto.MessageName(event) + evtJSON, err := codec.ProtoMarshalJSON(event) + if err != nil { + return err + } + + var attrMap map[string]json.RawMessage + err = json.Unmarshal(evtJSON, &attrMap) + if err != nil { + return err + } + + var attrs []abci.EventAttribute + for k, v := range attrMap { + attrs = append(attrs, abci.EventAttribute{ + Key: []byte(k), + Value: v, + }) + } + + em.EmitEvent(Event{ + Type: evtType, + Attributes: attrs, + }) + + return nil +} + +// ParseTypedEvent converts abci.Event back to typed event +func ParseTypedEvent(event abci.Event) (proto.Message, error) { + concreteGoType := proto.MessageType(event.Type) + if concreteGoType == nil { + return nil, fmt.Errorf("failed to retrieve the message of type %q", event.Type) + } + + var value reflect.Value + if concreteGoType.Kind() == reflect.Ptr { + value = reflect.New(concreteGoType.Elem()) + } else { + value = reflect.Zero(concreteGoType) + } + + protoMsg, ok := value.Interface().(proto.Message) + if !ok { + return nil, fmt.Errorf("%q does not implement proto.Message", event.Type) + } + + attrMap := make(map[string]json.RawMessage) + for _, attr := range event.Attributes { + attrMap[string(attr.Key)] = attr.Value + } + + attrBytes, err := json.Marshal(attrMap) + if err != nil { + return nil, err + } + + err = jsonpb.Unmarshal(strings.NewReader(string(attrBytes)), protoMsg) + if err != nil { + return nil, err + } + + return protoMsg, nil +} +``` + +Here, the `EmitTypedEvent` is a method on `EventManager` which takes typed event as input and apply json serialization on it. Then it maps the JSON key/value pairs to `event.Attributes` and emits it in form of `sdk.Event`. `Event.Type` will be the type URL of the proto message. + +When we subscribe to emitted events on the tendermint websocket, they are emitted in the form of an `abci.Event`. `ParseTypedEvent` parses the event back to it's original proto message. + +**Step-2**: Add proto definitions for typed events for msgs in each module: + +For example, let's take `MsgSubmitProposal` of `gov` module and implement this event's type. + +```protobuf +// proto/cosmos/gov/v1beta1/gov.proto +// Add typed event definition + +package cosmos.gov.v1beta1; + +message EventSubmitProposal { + string from_address = 1; + uint64 proposal_id = 2; + TextProposal proposal = 3; +} +``` + +**Step-3**: Refactor event emission to use the typed event created and emit using `sdk.EmitTypedEvent`: + +```go +// x/gov/handler.go +func handleMsgSubmitProposal(ctx sdk.Context, keeper keeper.Keeper, msg types.MsgSubmitProposalI) (*sdk.Result, error) { + ... + types.Context.EventManager().EmitTypedEvent( + &EventSubmitProposal{ + FromAddress: fromAddress, + ProposalId: id, + Proposal: proposal, + }, + ) + ... +} +``` + +### How to subscribe to these typed events in `Client` + +> NOTE: Full code example below + +Users will be able to subscribe using `client.Context.Client.Subscribe` and consume events which are emitted using `EventHandler`s. + +Akash Network has built a simple [`pubsub`](https://github.com/ovrclk/akash/blob/90d258caeb933b611d575355b8df281208a214f8/pubsub/bus.go#L20). This can be used to subscribe to `abci.Events` and [publish](https://github.com/ovrclk/akash/blob/90d258caeb933b611d575355b8df281208a214f8/events/publish.go#L21) them as typed events. + +Please see the below code sample for more detail on this flow looks for clients. + +## Consequences + +### Positive + +* Improves consistency of implementation for the events currently in the 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 + +### Negative + +## Detailed code example of publishing events + +This ADR also proposes adding affordances to emit and consume these events. This way developers will only need to write +`EventHandler`s which define the actions they desire to take. + +```go +// EventEmitter is a type that describes event emitter functions +// This should be defined in `types/events.go` +type EventEmitter func(context.Context, client.Context, ...EventHandler) error + +// EventHandler is a type of function that handles events coming out of the event bus +// This should be defined in `types/events.go` +type EventHandler func(proto.Message) error + +// Sample use of the functions below +func main() { + ctx, cancel := context.WithCancel(context.Background()) + + if err := TxEmitter(ctx, client.Context{}.WithNodeURI("tcp://localhost:26657"), SubmitProposalEventHandler); err != nil { + cancel() + panic(err) + } + + return +} + +// SubmitProposalEventHandler is an example of an event handler that prints proposal details +// when any EventSubmitProposal is emitted. +func SubmitProposalEventHandler(ev proto.Message) (err error) { + switch event := ev.(type) { + // Handle governance proposal events creation events + case govtypes.EventSubmitProposal: + // Users define business logic here e.g. + fmt.Println(ev.FromAddress, ev.ProposalId, ev.Proposal) + return nil + default: + return nil + } +} + +// TxEmitter is an example of an event emitter that emits just transaction events. This can and +// should be implemented somewhere in the 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 + client, err := cliCtx.GetNode() + if err != nil { + return err + } + + if err = client.Start(); err != nil { + return err + } + + // Start the pubsub bus + bus := pubsub.NewBus() + defer bus.Close() + + // Initialize a new error group + eg, ctx := errgroup.WithContext(ctx) + + // Publish chain events to the pubsub bus + eg.Go(func() error { + return PublishChainTxEvents(ctx, client, bus, simapp.ModuleBasics) + }) + + // Subscribe to the bus events + subscriber, err := bus.Subscribe() + if err != nil { + return err + } + + // Handle all the events coming out of the bus + eg.Go(func() error { + var err error + for { + select { + case <-ctx.Done(): + return nil + case <-subscriber.Done(): + return nil + case ev := <-subscriber.Events(): + for _, eh := range ehs { + if err = eh(ev); err != nil { + break + } + } + } + } + return nil + }) + + return group.Wait() +} + +// PublishChainTxEvents events using 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 + txch, err := client.Subscribe(ctx, "txevents", "tm.event='Tx'", 100) + if err != nil { + return err + } + + // Unsubscribe from transaction events on function exit + defer func() { + err = client.UnsubscribeAll(ctx, "txevents") + }() + + // Use errgroup to manage concurrency + g, ctx := errgroup.WithContext(ctx) + + // Publish transaction events in a goroutine + g.Go(func() error { + var err error + for { + select { + case <-ctx.Done(): + break + case ed := <-ch: + switch evt := ed.Data.(type) { + case tmtypes.EventDataTx: + if !evt.Result.IsOK() { + continue + } + // range over events, parse them using the basic manager and + // send them to the pubsub bus + for _, abciEv := range events { + typedEvent, err := sdk.ParseTypedEvent(abciEv) + if err != nil { + return er + } + if err := bus.Publish(typedEvent); err != nil { + bus.Close() + return + } + continue + } + } + } + } + return err + }) + + // Exit on error or context cancelation + return g.Wait() +} +``` + +## References + +* [Publish Custom Events via a bus](https://github.com/ovrclk/akash/blob/90d258caeb933b611d575355b8df281208a214f8/events/publish.go#L19-L58) +* [Consuming the events in `Client`](https://github.com/ovrclk/deploy/blob/bf6c633ab6c68f3026df59efd9982d6ca1bf0561/cmd/event-handlers.go#L57) diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-033-protobuf-inter-module-comm.md b/versioned_docs/version-0.46/integrate/architecture/adr-033-protobuf-inter-module-comm.md new file mode 100644 index 000000000..09b650a61 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-033-protobuf-inter-module-comm.md @@ -0,0 +1,400 @@ +# ADR 033: Protobuf-based Inter-Module Communication + +## Changelog + +* 2020-10-05: Initial Draft + +## 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: + +* 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 + +## Context + +In the current Cosmos SDK documentation on the [Object-Capability Model](../core/ocap.md), it is stated that: + +> 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. + +There is currently not a thriving ecosystem of Cosmos SDK modules. We hypothesize that this is in part due to: + +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. + +### `x/bank` Case Study + +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. + +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. + +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. + +## 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. + +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. + +### 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: + +```go +package bank + +type MsgClient interface { + Send(context.Context, *MsgSend, opts ...grpc.CallOption) (*MsgSendResponse, error) +} + +type MsgServer interface { + Send(context.Context, *MsgSend) (*MsgSendResponse, error) +} +``` + +[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. + +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. + +Using this `QueryClient`/`MsgClient` approach has the following key benefits over exposing keepers to external modules: + +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 + +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 + +### 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. + +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`. + +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. + +Here's an example of a hypothetical module `foo` interacting with `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), + } +} + +func (foo *FooMsgServer) Bar(ctx context.Context, req *MsgBarRequest) (*MsgBarResponse, error) { + balance, err := foo.bankQuery.Balance(&bank.QueryBalanceRequest{Address: fooMsgServer.moduleKey.Address(), Denom: "foo"}) + + ... + + res, err := foo.bankMsg.Send(ctx, &bank.MsgSendRequest{FromAddress: fooMsgServer.moduleKey.Address(), ...}) + + ... +} +``` + +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)). + +### `ModuleKey`s and `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/main/docs/architecture/adr-028-public-key-addresses.md): + +```go +type ModuleID struct { + ModuleName string + Path []byte +} + +func (key ModuleID) Address() []byte { + return AddressHash(key.ModuleName, key.Path) +} +``` + +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. + +The two `ModuleKey` types are `RootModuleKey` and `DerivedModuleKey`: + +```go +type Invoker func(callInfo CallInfo) func(ctx context.Context, request, response interface{}, opts ...interface{}) error + +type CallInfo { + Method string + Caller ModuleID +} + +type RootModuleKey struct { + moduleName string + invoker Invoker +} + +func (rm RootModuleKey) Derive(path []byte) DerivedModuleKey { /* ... */} + +type DerivedModuleKey struct { + moduleName string + path []byte + invoker Invoker +} +``` + +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: + +```go +package foo + +func (fooMsgServer *MsgServer) Bar(ctx context.Context, req *MsgBar) (*MsgBarResponse, error) { + derivedKey := fooMsgServer.moduleKey.Derive(req.SomePath) + bankMsgClient := bank.NewMsgClient(derivedKey) + res, err := bankMsgClient.Balance(ctx, &bank.MsgSend{FromAddress: derivedKey.Address(), ...}) + ... +} +``` + +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. + +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. + +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`: + +```go +func (key RootModuleKey) Invoke(ctx context.Context, method string, args, reply interface{}, opts ...grpc.CallOption) error { + f := key.invoker(CallInfo {Method: method, Caller: ModuleID {ModuleName: key.moduleName}}) + return f(ctx, args, reply) +} +``` + +### `AppModule` Wiring and Requirements + +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()`: + +```go +type Configurator interface { + MsgServer() grpc.Server + QueryServer() grpc.Server + + ModuleKey() ModuleKey + RequireServer(msgServer 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. + +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: + +```go +package foo + +func (am AppModule) RegisterServices(cfg Configurator) { + cfg.RequireServer((*bank.QueryServer)(nil)) + cfg.RequireServer((*bank.MsgServer)(nil)) +} +``` + +### Security Considerations + +In addition to checking for `ModuleKey` permissions, a few additional security precautions will need to be taken by +the underlying router infrastructure. + +#### 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. + +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. + +#### 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. + +### 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`: + +```go +type Configurator interface { + MsgServer() grpc.Server + QueryServer() grpc.Server + InternalServer() grpc.Server +} +``` + +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. + +Services registered against `InternalServer` will be callable from other modules but not by external clients. + +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. + +### Authorization + +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/main/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 + +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 + +### 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). + +The advantages of the approach described in this ADR are mostly around how it integrates with other parts of the Cosmos SDK, +specifically: + +* 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` + +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. + +## Consequences + +### 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 + +* 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 + +### 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) diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-034-account-rekeying.md b/versioned_docs/version-0.46/integrate/architecture/adr-034-account-rekeying.md new file mode 100644 index 000000000..cd9b91469 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-034-account-rekeying.md @@ -0,0 +1,76 @@ +# ADR 034: Account Rekeying + +## Changelog + +* 30-09-2020: Initial Draft + +## Status + +PROPOSED + +## Abstract + +Account rekeying is a process hat allows an account to replace its authentication pubkey with a new one. + +## Context + +Currently, in the Cosmos SDK, the address of an auth `BaseAccount` is based on the hash of the public key. Once an account is created, the public key for the account is set in stone, and cannot be changed. This can be a problem for users, as key rotation is a useful security practice, but is not possible currently. Furthermore, as multisigs are a type of pubkey, once a multisig for an account is set, it can not be updated. This is problematic, as multisigs are often used by organizations or companies, who may need to change their set of multisig signers for internal reasons. + +Transferring all the assets of an account to a new account with the updated pubkey is not sufficient, because some "engagements" of an account are not easily transferable. For example, in staking, to transfer bonded Atoms, an account would have to unbond all delegations and wait the three week unbonding period. Even more significantly, for validator operators, ownership over a validator is not transferrable at all, meaning that the operator key for a validator can never be updated, leading to poor operational security for validators. + +## Decision + +We propose the addition of a new feature to `x/auth` that allows accounts to update the public key associated with their account, while keeping the address the same. + +This is possible because the Cosmos SDK `BaseAccount` stores the public key for an account in state, instead of making the assumption that the public key is included in the transaction (whether explicitly or implicitly through the signature) as in other blockchains such as Bitcoin and Ethereum. Because the public key is stored on chain, it is okay for the public key to not hash to the address of an account, as the address is not pertinent to the signature checking process. + +To build this system, we design a new Msg type as follows: + +```protobuf +service Msg { + rpc ChangePubKey(MsgChangePubKey) returns (MsgChangePubKeyResponse); +} + +message MsgChangePubKey { + string address = 1; + google.protobuf.Any pub_key = 2; +} + +message MsgChangePubKeyResponse {} +``` + +The MsgChangePubKey transaction needs to be signed by the existing pubkey in state. + +Once, approved, the handler for this message type, which takes in the AccountKeeper, will update the in-state pubkey for the account and replace it with the pubkey from the Msg. + +An account that has had its pubkey changed cannot be automatically pruned from state. This is because if pruned, the original pubkey of the account would be needed to recreate the same address, but the owner of the address may not have the original pubkey anymore. Currently, we do not automatically prune any accounts anyways, but we would like to keep this option open the road (this is the purpose of account numbers). To resolve this, we charge an additional gas fee for this operation to compensate for this this externality (this bound gas amount is configured as parameter `PubKeyChangeCost`). The bonus gas is charged inside the handler, using the `ConsumeGas` function. Furthermore, in the future, we can allow accounts that have rekeyed manually prune themselves using a new Msg type such as `MsgDeleteAccount`. Manually pruning accounts can give a gas refund as an incentive for performing the action. + +```go + amount := ak.GetParams(ctx).PubKeyChangeCost + ctx.GasMeter().ConsumeGas(amount, "pubkey change fee") +``` + +Everytime a key for an address is changed, we will store a log of this change in the state of the chain, thus creating a stack of all previous keys for an address and the time intervals for which they were active. This allows dapps and clients to easily query past keys for an account which may be useful for features such as verifying timestamped off-chain signed messages. + +## Consequences + +### Positive + +* Will allow users and validator operators to employ better operational security practices with key rotation. +* Will allow organizations or groups to easily change and add/remove multisig signers. + +### Negative + +Breaks the current assumed relationship between address and pubkeys as H(pubkey) = address. This has a couple of consequences. + +* This makes wallets that support this feature more complicated. For example, if an address on chain was updated, the corresponding key in the CLI wallet also needs to be updated. +* Cannot automatically prune accounts with 0 balance that have had their pubkey changed. + +### Neutral + +* While the purpose of this is intended to allow the owner of an account to update to a new pubkey they own, this could technically also be used to transfer ownership of an account to a new owner. For example, this could be use used to sell a staked position without unbonding or an account that has vesting tokens. However, the friction of this is very high as this would essentially have to be done as a very specific OTC trade. Furthermore, additional constraints could be added to prevent accouns with Vesting tokens to use this feature. +* Will require that PubKeys for an account are included in the genesis exports. + +## References + +* https://www.algorand.com/resources/blog/announcing-rekeying diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-035-rosetta-api-support.md b/versioned_docs/version-0.46/integrate/architecture/adr-035-rosetta-api-support.md new file mode 100644 index 000000000..01a81048b --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-035-rosetta-api-support.md @@ -0,0 +1,211 @@ +# ADR 035: Rosetta API Support + +## Authors + +* Jonathan Gimeno (@jgimeno) +* David Grierson (@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. + +## Context + +[Rosetta API](https://www.rosetta-api.org/) is an open-source specification and set of tools developed by Coinbase to +standardise blockchain interactions. + +Through the use of a standard API for integrating blockchain applications it will + +* Be easier for a user to interact with a given blockchain +* Allow exchanges to integrate new blockchains quickly and easily +* Enable application developers to build cross-blockchain applications such as block explorers, wallets and dApps at + considerably lower cost and effort. + +## Decision + +It is clear that adding Rosetta API support to the Cosmos SDK will bring value to all the developers and +Cosmos SDK based chains in the ecosystem. How it is implemented is key. + +The driving principles of the proposed design are: + +1. **Extensibility:** it must be as riskless and painless as possible for application developers to set-up network + configurations to expose Rosetta API-compliant services. +2. **Long term support:** This proposal aims to provide support for all the supported Cosmos SDK release series. +3. **Cost-efficiency:** Backporting changes to Rosetta API specifications from `master` to the various stable + branches of Cosmos SDK is a cost that needs to be reduced. + +We will achieve these delivering on these principles by the following: + +1. There will be 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. + +## 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. + +The constructor follows: + +`func NewServer(settings Settings) (Server, error)` + +`Settings`, which are used to construct a new server, are the following: + +```go +// Settings define the rosetta server settings +type Settings struct { + // Network contains the information regarding the network + Network *types.NetworkIdentifier + // Client is the online API handler + Client crgtypes.Client + // Listen is the address the handler will listen at + Listen string + // 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 int + // 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. + +Each Cosmos SDK release series will have their own `Client` implementations. +Developers can implement their own custom `Client`s as required. + +```go +// Client defines the API the client implementation should provide. +type Client interface { + // 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() error + + // 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(ctx context.Context, addr string, height *int64) ([]*types.Amount, error) + // 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 + BlockByHeight(ctx context.Context, height *int64) (BlockResponse, error) + // 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. + BlockTransactionsByHeight(ctx context.Context, height *int64) (BlockTransactionsResponse, error) + // 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(ctx context.Context, hash string) (*types.Transaction, error) + // 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(ctx context.Context) ([]*types.Peer, error) + // Status returns the node status, such as sync data, version etc + Status(ctx context.Context) (*types.SyncStatus, error) + + // Construction API + + // 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(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 +type OfflineClient interface { + NetworkInformationProvider + // 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(signed bool, hexBytes []byte) (ops []*types.Operation, signers []*types.AccountIdentifier, err error) + // 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(ctx context.Context, req *types.ConstructionPreprocessRequest) (options map[string]interface{}, err error) + // AccountIdentifierFromPublicKey returns the account identifier given the public key + AccountIdentifierFromPublicKey(pubKey *types.PublicKey) (*types.AccountIdentifier, error) +} +``` + +### 2. Cosmos SDK Implementation + +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. + +The rosetta.Msg interface follows: + +```go +// 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 + FromOperations(ops []*types.Operation) (sdk.Msg, error) +} +``` + +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. + +### 3. API service invocation + +As stated at the start, application developers will have two methods for invocation of the Rosetta API service: + +1. Shared process for both application and API +2. Standalone API service + +#### Shared Process (Only Stargate) + +Rosetta API service could run within the same execution process as the application. 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). + +#### Separate API service + +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. + +## Status + +Proposed + +## Consequences + +### Positive + +* Out-of-the-box Rosetta API support within Cosmos SDK. +* Blockchain interface standardisation + +## References + +* https://www.rosetta-api.org/ diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-036-arbitrary-signature.md b/versioned_docs/version-0.46/integrate/architecture/adr-036-arbitrary-signature.md new file mode 100644 index 000000000..d40929452 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-036-arbitrary-signature.md @@ -0,0 +1,132 @@ +# ADR 036: Arbitrary Message Signature Specification + +## Changelog + +* 28/10/2020 - Initial draft + +## Authors + +* Antoine Herzog (@antoineherzog) +* Zaki Manian (@zmanian) +* Aleksandr 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. + +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. + +## 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. + +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. + +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 0.40 also introduces a concept of “auth_info” this can specify SIGN_MODES. + +A spec should include an `auth_info` that supports SIGN_MODE_DIRECT and SIGN_MODE_LEGACY_AMINO. + +Create the `offchain` proto definitions, we extend the auth module with `offchain` package to offer functionalities to verify and sign offline messages. + +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 + +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`. + +`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. + +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 +message MsgSignData { + // 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) + bytes Data = 2 [(gogoproto.jsontag) = "data"]; +} +``` + +Signed MsgSignData json example: + +```json +{ + "type": "cosmos-sdk/StdTx", + "value": { + "msg": [ + { + "type": "sign/MsgSignData", + "value": { + "signer": "cosmos1hftz5ugqmpg9243xeegsqqav62f8hnywsjr4xr", + "data": "cmFuZG9t" + } + } + ], + "fee": { + "amount": [], + "gas": "0" + }, + "signatures": [ + { + "pub_key": { + "type": "tendermint/PubKeySecp256k1", + "value": "AqnDSiRoFmTPfq97xxEb2VkQ/Hm28cPsqsZm9jEVsYK9" + }, + "signature": "8y8i34qJakkjse9pOD2De+dnlc4KvFgh0wQpes4eydN66D9kv7cmCEouRrkka9tlW9cAkIL52ErB+6ye7X5aEg==" + } + ], + "memo": "" + } +} +``` + +## 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]. + +### Negative + +* Current proposal requires a fixed relationship between an account address and a public key. +* Doesn't work with multisig accounts. + +## Further discussion + +* 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 diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-037-gov-split-vote.md b/versioned_docs/version-0.46/integrate/architecture/adr-037-gov-split-vote.md new file mode 100644 index 000000000..a2f457c33 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-037-gov-split-vote.md @@ -0,0 +1,111 @@ +# ADR 037: Governance split votes + +## Changelog + +* 2020/10/28: Intial draft + +## Status + +Accepted + +## Abstract + +This ADR defines a modification to the governance module that would allow a staker to split their votes into several voting options. For example, it could use 70% of its voting power to vote Yes and 30% of its voting power to vote No. + +## Context + +Currently, an address can cast a vote with only one options (Yes/No/Abstain/NoWithVeto) and use their full voting power behind that choice. + +However, often times the entity owning that address might not be a single individual. For example, a company might have different stakeholders who want to vote differently, and so it makes sense to allow them to split their voting power. Another example use case is exchanges. Many centralized exchanges often stake a portion of their users' tokens in their custody. Currently, it is not possible for them to do "passthrough voting" and giving their users voting rights over their tokens. However, with this system, exchanges can poll their users for voting preferences, and then vote on-chain proportionally to the results of the poll. + +## Decision + +We modify the vote structs to be + +```go +type WeightedVoteOption struct { + Option string + Weight sdk.Dec +} + +type Vote struct { + ProposalID int64 + Voter sdk.Address + Options []WeightedVoteOption +} +``` + +And for backwards compatibility, we introduce `MsgVoteWeighted` while keeping `MsgVote`. + +```go +type MsgVote struct { + ProposalID int64 + Voter sdk.Address + Option Option +} + +type MsgVoteWeighted struct { + ProposalID int64 + Voter sdk.Address + Options []WeightedVoteOption +} +``` + +The `ValidateBasic` of a `MsgVoteWeighted` struct would require that + +1. The sum of all the Rates is equal to 1.0 +2. No Option is repeated + +The governance tally function will iterate over all the options in a vote and add to the tally the result of the voter's voting power * the rate for that option. + +```go +tally() { + results := map[types.VoteOption]sdk.Dec + + for _, vote := range votes { + for i, weightedOption := range vote.Options { + results[weightedOption.Option] += getVotingPower(vote.voter) * weightedOption.Weight + } + } +} +``` + +The CLI command for creating a multi-option vote would be as such: + +```sh +simd tx gov vote 1 "yes=0.6,no=0.3,abstain=0.05,no_with_veto=0.05" --from mykey +``` + +To create a single-option vote a user can do either + +```sh +simd tx gov vote 1 "yes=1" --from mykey +``` + +or + +```sh +simd tx gov vote 1 yes --from mykey +``` + +to maintain backwards compatibility. + +## Consequences + +### Backwards Compatibility + +* Previous VoteMsg types will remain the same and so clients will not have to update their procedure unless they want to support the WeightedVoteMsg feature. +* When querying a Vote struct from state, its structure will be different, and so clients wanting to display all voters and their respective votes will have to handle the new format and the fact that a single voter can have split votes. +* The result of querying the tally function should have the same API for clients. + +### Positive + +* Can make the voting process more accurate for addresses representing multiple stakeholders, often some of the largest addresses. + +### Negative + +* Is more complex than simple voting, and so may be harder to explain to users. However, this is mostly mitigated because the feature is opt-in. + +### Neutral + +* Relatively minor change to governance tally function. diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-038-state-listening.md b/versioned_docs/version-0.46/integrate/architecture/adr-038-state-listening.md new file mode 100644 index 000000000..74f92d2f6 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-038-state-listening.md @@ -0,0 +1,569 @@ +# ADR 038: KVStore state listening + +## Changelog + +* 11/23/2020: Initial draft +* 10/14/2022: + * Add `ListenCommit`, flatten the state writes in a block to a single batch. + * Remove listeners from cache stores, should only listen to `rootmulti.Store`. + * Remove `HaltAppOnDeliveryError()`, the errors are propogated by default, the implementations should return nil if don't want to propogate errors. + + +## 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. + +## 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. + +## Decision + +We will modify the `CommitMultiStore` interface and its concrete (`rootmulti`) implementations and introduce a new `listenkv.Store` to allow listening to state changes in underlying KVStores. We don't need to listen to cache stores, because we can't be sure that the writes will be committed eventually, and the writes are duplicated in `rootmulti.Store` eventually, so we should only listen to `rootmulti.Store`. +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. + +### Listening interface + +In a new file, `store/types/listening.go`, we will create a `WriteListener` interface for streaming out state changes from a KVStore. + +```go +// 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 + OnWrite(storeKey StoreKey, key []byte, value []byte, delete bool) error +} +``` + +### Listener type + +We will create two concrete implementations of the `WriteListener` interface in `store/types/listening.go`, that writes out protobuf +encoded KV pairs to an underlying `io.Writer`, and simply accumulate them in memory. + +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. + +```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 + 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 +type StoreKVPairWriteListener struct { + writer io.Writer + marshaller 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, + marshaller: m, + } +} + +// 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() + kvPair.Delete = Delete + kvPair.Key = key + kvPair.Value = value + by, err := wl.marshaller.MarshalBinaryLengthPrefixed(kvPair) + if err != nil { + return err + } + if _, err := wl.writer.Write(by); err != nil { + return err + } + return nil +} +``` + +```golang +// MemoryListener listens to the state writes and accumulate the records in memory. +type MemoryListener struct { + key StoreKey + stateCache []StoreKVPair +} + +// NewMemoryListener creates a listener that accumulate the state writes in memory. +func NewMemoryListener(key StoreKey) *MemoryListener { + return &MemoryListener{key: key} +} + +// OnWrite implements WriteListener interface +func (fl *MemoryListener) OnWrite(storeKey StoreKey, key []byte, value []byte, delete bool) error { + fl.stateCache = append(fl.stateCache, StoreKVPair{ + StoreKey: storeKey.Name(), + Delete: delete, + Key: key, + Value: value, + }) + return nil +} + +// PopStateCache returns the current state caches and set to nil +func (fl *MemoryListener) PopStateCache() []StoreKVPair { + res := fl.stateCache + fl.stateCache = nil + return res +} + +// StoreKey returns the storeKey it listens to +func (fl *MemoryListener) StoreKey() StoreKey { + return fl.key +} +``` + +### 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. + +```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 +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. +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. +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. +func (s *Store) Delete(key []byte) { + s.parent.Delete(key) + s.onWrite(true, key, nil) +} + +// 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 + } + } +} +``` + +### MultiStore interface updates + +We will update the `CommitMultiStore` interface to allow us to wrap a set of listeners around a specific `KVStore`. + +```go +type CommitMultiStore interface { + ... + + // 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(key StoreKey, listeners []WriteListener) +} +``` + +### MultiStore implementation updates + +We will modify all of the `CommitMultiStore` 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`. + +```go +func (rs *Store) GetKVStore(key types.StoreKey) types.KVStore { + store := rs.stores[key].(types.KVStore) + + if rs.TracingEnabled() { + store = tracekv.NewStore(store, rs.traceWriter, rs.traceContext) + } + if rs.ListeningEnabled(key) { + store = listenkv.NewStore(key, store, rs.listeners[key]) + } + + return store +} +``` + +We will also adjust the `rootmulti` `CacheMultiStore` method to wrap the stores with `listenkv.Store` to enable listening when the cache layer writes. + +```go +func (rs *Store) CacheMultiStore() types.CacheMultiStore { + stores := make(map[types.StoreKey]types.CacheWrapper) + for k, v := range rs.stores { + store := v.(types.KVStore) + // Wire the listenkv.Store to allow listeners to observe the writes from the cache store, + // set same listeners on cache store will observe duplicated writes. + if rs.ListeningEnabled(k) { + store = listenkv.NewStore(store, k, rs.listeners[k]) + } + stores[k] = store + } + return cachemulti.NewStore(rs.db, stores, rs.keysByName, rs.traceWriter, rs.getTracingContext()) +} +``` + +### Exposing the data + +#### 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 observe those block metadatas as well. + +The `WriteListener`s of `StreamingService` listens to the `rootmulti.Store`, which is only written into at commit event by the cache store of `deliverState`. + +```go +// 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(ctx types.Context, req abci.RequestBeginBlock, res abci.ResponseBeginBlock) error + // 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(ctx types.Context, req abci.RequestDeliverTx, res abci.ResponseDeliverTx) error + // ListenCommit updates the steaming service with the latest Commit message, + // All the state writes of current block should have notified before this message. + ListenCommit(ctx types.Context, res abci.ResponseCommit) error +} + +// 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(wg *sync.WaitGroup) error + // 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 + // Closer interface + io.Closer +} +``` + +#### BaseApp registration + +We will add a new method to the `BaseApp` to enable the registration of `StreamingService`s: + +```go +// 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 + 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 + app.abciListeners = append(app.abciListeners, s) +} +``` + +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`. + +```go +func (app *BaseApp) BeginBlock(req abci.RequestBeginBlock) (res abci.ResponseBeginBlock) { + + ... + + defer func() { + // call the hooks with the BeginBlock messages + for _, streamingListener := range app.abciListeners { + if err := streamingListener.ListenBeginBlock(app.deliverState.ctx, req, res); err != nil { + panic(sdkerrors.Wrapf(err, "BeginBlock listening hook failed, height: %d", req.Header.Height)) + } + } + }() + + return res +} +``` + +```go +func (app *BaseApp) EndBlock(req abci.RequestEndBlock) (res abci.ResponseEndBlock) { + + ... + + defer func() { + // Call the streaming service hooks with the EndBlock messages + for _, streamingListener := range app.abciListeners { + if err := streamingListener.ListenEndBlock(app.deliverState.ctx, req, res); err != nil { + panic(sdkerrors.Wrapf(err, "EndBlock listening hook failed, height: %d", req.Height)) + } + } + }() + + return res +} +``` + +```go +func (app *BaseApp) DeliverTx(req abci.RequestDeliverTx) (res abci.ResponseDeliverTx) { + + defer func() { + // call the hooks with the DeliverTx messages + for _, streamingListener := range app.abciListeners { + if err := streamingListener.ListenDeliverTx(app.deliverState.ctx, req, res); err != nil { + panic(sdkerrors.Wrap(err, "DeliverTx listening hook failed")) + } + } + }() + + ... + + return res +} +``` + +```golang +func (app *BaseApp) Commit() abci.ResponseCommit { + header := app.deliverState.ctx.BlockHeader() + retainHeight := app.GetBlockRetentionHeight(header.Height) + + // Write the DeliverTx state into branched storage and commit the MultiStore. + // The write to the DeliverTx state writes all state transitions to the root + // MultiStore (app.cms) so when Commit() is called is persists those values. + app.deliverState.ms.Write() + commitID := app.cms.Commit() + + res := abci.ResponseCommit{ + Data: commitID.Hash, + RetainHeight: retainHeight, + } + + // call the hooks with the Commit message + for _, streamingListener := range app.abciListeners { + if err := streamingListener.ListenCommit(app.deliverState.ctx, res); err != nil { + panic(sdkerrors.Wrapf(err, "Commit listening hook failed, height: %d", header.Height)) + } + } + + app.logger.Info("commit synced", "commit", fmt.Sprintf("%X", commitID)) + ... +} +``` + +#### Error Handling And Async Consumers + +`ABCIListener`s are called synchronously inside the consensus state machine, the returned error causes panic which in turn halt the consensus state machine. The implementer should be careful not to break consensus unexpectedly or slow down it too much. + +For some async use cases, one can spawn a go-routine internanlly to avoid slow down consensus state machine, and handle the errors internally and always returns `nil` to avoid halting consensus state machine on error. + +Furthermore, for most of the cases, we only need to use the builtin file streamer to listen to state changes directly inside cosmos-sdk, the other consumers should subscribe to the file streamer output externally. + +#### File Streamer + +We provide a minimal filesystem based implementation inside cosmos-sdk, and provides options to write output files reliably, the output files can be further consumed by external consumers, so most of the state listeners actually don't need to live inside the sdk and node, which improves the node robustness and simplify sdk internals. + +The file streamer can be wired in app like this: +```golang +exposeStoreKeys := ... // decide the key list to listen +service, err := file.NewStreamingService(streamingDir, "", exposeStoreKeys, appCodec, logger) +bApp.SetStreamingService(service) +``` + +#### 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: + +```go +// 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() string + + // 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(env serverTypes.AppOptions) error + + // 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. + +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. + +```go +// 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(bApp *baseapp.BaseApp, marshaller codec.BinaryCodec, keys map[string]*types.KVStoreKey) error + + // Start starts the background streaming process of the plugin streaming service + Start(wg *sync.WaitGroup) error + + // 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. + +e.g. in `NewSimApp`: + +```go +func NewSimApp( + logger log.Logger, + db dbm.DB, + traceStore io.Writer, + loadLatest bool, + appOpts servertypes.AppOptions, + baseAppOptions ...func(*baseapp.BaseApp), +) *SimApp { + + ... + + keys := sdk.NewKVStoreKeys( + authtypes.StoreKey, banktypes.StoreKey, stakingtypes.StoreKey, + minttypes.StoreKey, distrtypes.StoreKey, slashingtypes.StoreKey, + govtypes.StoreKey, paramstypes.StoreKey, ibchost.StoreKey, upgradetypes.StoreKey, + evidencetypes.StoreKey, ibctransfertypes.StoreKey, capabilitytypes.StoreKey, + ) + + pluginsOnKey := fmt.Sprintf("%s.%s", plugin.PLUGINS_TOML_KEY, plugin.PLUGINS_ON_TOML_KEY) + if cast.ToBool(appOpts.Get(pluginsOnKey)) { + // this loads the preloaded and any plugins found in `plugins.dir` + pluginLoader, err := loader.NewPluginLoader(appOpts, logger) + if err != nil { + // handle error + } + + // initialize the loaded plugins + if err := pluginLoader.Initialize(); err != nil { + // handle error + } + + // register the plugin(s) with the BaseApp + if err := pluginLoader.Inject(bApp, appCodec, keys); err != nil { + // handle error + } + + // 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 + } + } + + ... + + return app +} +``` + + +#### Configuration + +The plugin system will be configured within an app's app.toml file. + +```toml +[plugins] + on = false # turn the plugin system, as a whole, on or off + enabled = ["list", "of", "plugin", "names", "to", "enable"] + 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.enabled` 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.enabled` provides `opt-in` semantics to plugin names to enable (including preloaded plugins). + +Configuration of a given plugin is ultimately specific to the plugin, but we will introduce some standards here: + +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 flag (e.g. `plugins.streaming.file.halt_app_on_delivery_error`) +that signifies whether the service operates in a fire-and-forget capacity, or stop the BaseApp when an error occurs in +any of `ListenBeginBlock`, `ListenEndBlock` and `ListenDeliverTx`. + +e.g. + +```toml +[plugins] + on = false # turn the plugin system, as a whole, on or off + enabled = ["list", "of", "plugin", "names", "to", "enable"] + dir = "the directory to load non-preloaded plugins from; defaults to " + [plugins.streaming] # a mapping of plugin-specific streaming service parameters, mapped to their plugin name + [plugins.streaming.file] # the specific parameters for the file streaming service plugin + keys = ["list", "of", "store", "keys", "we", "want", "to", "expose", "for", "this", "streaming", "service"] + write_dir = "path to the write directory" + prefix = "optional prefix to prepend to the generated file names" + halt_app_on_delivery_error = "false" # false == fire-and-forget; true == stop the application + [plugins.streaming.kafka] + keys = [] + topic_prefix = "block" # Optional prefix for topic names where data will be stored. + flush_timeout_ms = 5000 # Flush and wait for outstanding messages and requests to complete delivery when calling `StreamingService.Close(). (milliseconds) + halt_app_on_delivery_error = true # Whether or not to halt the application when plugin fails to deliver message(s). + ... +``` + +#### 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 + +These changes will provide a means of subscribing to KVStore state changes in real time. + +### Backwards Compatibility + +* This ADR changes the `CommitMultiStore` interface, implementations supporting the previous version of these interfaces will not support the new ones + +### Positive + +* Ability to listen to KVStore state changes in real time and expose these events to external consumers + +### Negative + +* Changes `CommitMultiStore`interface + +### 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 diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-039-epoched-staking.md b/versioned_docs/version-0.46/integrate/architecture/adr-039-epoched-staking.md new file mode 100644 index 000000000..29418fc89 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-039-epoched-staking.md @@ -0,0 +1,122 @@ +# ADR 039: Epoched Staking + +## Changelog + +* 10-Feb-2021: Initial Draft + +## Authors + +* Dev Ojha (@valardragon) +* Sunny Aggarwal (@sunnya97) + +## 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. + +## 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. + +* 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. + +* 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) + +* 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. + +## 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. + +### 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 + +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. + +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. + +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**: Implement buffering of all staking and slashing messages. + +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**: 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**: 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**: 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**: 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) + +**Step-3**: Adjust gas + +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. diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-040-storage-and-smt-state-commitments.md b/versioned_docs/version-0.46/integrate/architecture/adr-040-storage-and-smt-state-commitments.md new file mode 100644 index 000000000..f60e3adcf --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-040-storage-and-smt-state-commitments.md @@ -0,0 +1,289 @@ +# ADR 040: Storage and SMT State Commitments + +## Changelog + +* 2020-01-15: Draft + +## 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. + +## Context + +Currently, Cosmos SDK uses IAVL for both state [commitments](https://cryptography.fandom.com/wiki/Commitment_scheme) and data storage. + +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: + +* 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 +). + +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. + +## 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. + +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. + +`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`). + +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). + +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)): + +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. + +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. + +### 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) + +### SMT for State Commitment + +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: + +* 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. + +### 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). + +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. + +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. + +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). + +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. + +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. + +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. + +#### 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. + +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. + +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. + +### 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)`. + +### 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. + +### 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. + +### 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)). + +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. + +```go +// 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. +type CommitRootStore interface { + BasicRootStore + Committer + Snapshotter + + GetVersion(uint64) (BasicRootStore, error) + SetInitialVersion(uint64) error + + ... // Trace and Listen methods +} + +// Replaces CacheMultiStore for branched state. +type CacheRootStore interface { + BasicRootStore + Write() + + ... // Trace and Listen methods +} + +// Example of constructor parameters for the concrete type. +type RootStoreConfig struct { + Upgrades *StoreUpgrades + InitialVersion uint64 + + ReservePrefix(StoreKey, StoreType) +} +``` + + + + +In contrast to `MultiStore`, `RootStore` doesn't allow to dynamically mount sub-stores or provide an arbitrary backing DB for individual sub-stores. + +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. + +#### 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`. + +The new `RootStore` and supporting types can be implemented in a `store/v2alpha1` package to avoid breaking existing code. + +#### Merkle Proofs and 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. + +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. + +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"`. + +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. + +The presented workaround can be used until the IBC module is fully upgraded to supports single-element commitment proofs. + +### 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: + +* 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`. + +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. + +TODO: need to make decision about the key compression. + +## Optimization: SS key compression + +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: finalize this or move to another ADR. + +## Migration + +Using the new store will require a migration. 2 Migrations are proposed: + +1. Genesis export -- it will reset the blockchain history. +2. In place migration: we can reuse `UpgradeKeeper.SetUpgradeHandler` to provide the migration logic: + +```go +app.UpgradeKeeper.SetUpgradeHandler("adr-40", func(ctx sdk.Context, plan upgradetypes.Plan, vm module.VersionMap) (module.VersionMap, error) { + + storev2.Migrate(iavlstore, v2.store) + + // RunMigrations returns the VersionMap + // with the updated module ConsensusVersions + return app.mm.RunMigrations(ctx, vm) +}) +``` + +The `Migrate` function will read all entries from a store/v1 DB and save them to the AD-40 combined KV store. +Cache layer should not be used and the operation must finish with a single Commit call. + +Inserting records to the `SC` (SMT) component is the bottleneck. Unfortunately SMT doesn't support batch transactions. +Adding batch transactions to `SC` layer is considered as a feature after the main release. + +## Consequences + +### Backwards Compatibility + +This ADR doesn't introduce any Cosmos SDK level API changes. + +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 + +* 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 + +* 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 + +* Deprecating IAVL, which is one of the core proposals of Cosmos Whitepaper. + +## Alternative designs + +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). + +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 + +### Evaluated KV Databases + +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 + +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) diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-041-in-place-store-migrations.md b/versioned_docs/version-0.46/integrate/architecture/adr-041-in-place-store-migrations.md new file mode 100644 index 000000000..b0ff8e4e7 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-041-in-place-store-migrations.md @@ -0,0 +1,167 @@ +# ADR 041: In-Place Store Migrations + +## Changelog + +* 17.02.2021: Initial Draft + +## Status + +Accepted + +## Abstract + +This ADR introduces a mechanism to perform in-place state store migrations during chain software upgrades. + +## 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). + +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)). + +## Decision + +We propose a migration procedure based on modifying the KV store in-place without involving the JSON export-process-import flow described above. + +### Module `ConsensusVersion` + +We introduce a new method on the `AppModule` interface: + +```go +type AppModule interface { + // --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. + +### 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. + +```go +func (am AppModule) RegisterServices(cfg module.Configurator) { + // --snip-- + cfg.RegisterMigration(types.ModuleName, 1, func(ctx sdk.Context) error { + // 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. + }) + // etc. +} +``` + +For example, if the new ConsensusVersion of a module is `N` , then `N-1` migration functions MUST be registered in the configurator. + +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: + +```go +// 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. + +```go +// 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`. +} +``` + +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). + +### Tracking Module Versions in `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: + +```text +0x2 | {bytes(module_name)} => BigEndian(module_consensus_version) +``` + +The initial state of the store is set from `app.go`'s `InitChainer` method. + +The UpgradeHandler signature needs to be updated to take a `VersionMap`, as well as return an upgraded `VersionMap` and an error: + +```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. + +```diff +func (k UpgradeKeeper) ApplyUpgrade(ctx sdk.Context, plan types.Plan) { + // --snip-- +- handler(ctx, plan) ++ 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 ++ 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. + +### 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: + +* 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. + +If a required migration is missing (e.g. if it has not been registered in the `Configurator`), then the `RunMigrations` function will error. + +In practice, the `RunMigrations` method should be called from inside an `UpgradeHandler`. + +```go +app.UpgradeKeeper.SetUpgradeHandler("my-plan", func(ctx sdk.Context, plan upgradetypes.Plan, vm module.VersionMap) (module.VersionMap, error) { + return app.mm.RunMigrations(ctx, vm) +}) +``` + +Assuming a chain upgrades at block `n`, the procedure should run as follows: + +* 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. + +## 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. + +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. + +### 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. + +### 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. + +### 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. + +## 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 diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-042-group-module.md b/versioned_docs/version-0.46/integrate/architecture/adr-042-group-module.md new file mode 100644 index 000000000..74ba17f43 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-042-group-module.md @@ -0,0 +1,279 @@ +# ADR 042: Group Module + +## Changelog + +* 2020/04/09: Initial Draft + +## 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. + +## Context + +The legacy amino multi-signature mechanism of the Cosmos SDK has certain limitations: + +* 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)). + +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. + +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. + +## 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. + +### 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. + +```proto +message GroupInfo { + + // group_id is the unique ID of this group. + uint64 group_id = 1; + + // admin is the account address of the group's admin. + string admin = 2; + + // 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. + uint64 version = 4; + + // total_weight is the sum of the group members' weights. + string total_weight = 5; +} +``` + +```proto +message GroupMember { + + // group_id is the unique ID of the group. + uint64 group_id = 1; + + // member is the member data. + Member member = 2; +} + +// Member represents a group member with an account address, +// non-zero weight and metadata. +message Member { + + // address is the member's account address. + string address = 1; + + // 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. + 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). + +```proto +message GroupAccountInfo { + + // address is the group account address. + string address = 1; + + // 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. + string admin = 3; + + // 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. + uint64 version = 5; + + // 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. + +We define the `DecisionPolicy` interface that all decision policies must implement: + +```go +type DecisionPolicy interface { + codec.ProtoMarshaler + + ValidateBasic() error + GetTimeout() types.Duration + Allow(tally Tally, totalPower string, votingDuration time.Duration) (DecisionPolicyResult, error) + Validate(g GroupInfo) error +} + +type DecisionPolicyResult struct { + Allow bool + Final bool +} +``` + +#### 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_). + +```proto +message ThresholdDecisionPolicy { + + // 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. + 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. + +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. + +```proto +// Tally represents the sum of weighted votes. +message Tally { + option (gogoproto.goproto_getters) = false; + + // yes_count is the weighted sum of yes votes. + string yes_count = 1; + + // no_count is the weighted sum of no votes. + string no_count = 2; + + // abstain_count is the weighted sum of abstainers. + string abstain_count = 3; + + // 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. + +Voting internally updates the proposal `VoteState` as well as `Status` and `Result` if needed. + +### 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. + +#### 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. + +### 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. + +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`. + +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`. + +Proposals are stored as part of the `proposalTable` using the `Proposal` type. The `proposal_id` is an auto-increment integer. + +Votes are stored in the `voteTable`. The primary key is based on the vote's `proposal_id` and `voter` account address. + +#### ADR-033 to route proposal messages + +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. + +## Consequences + +### Positive + +* Improved UX for multi-signature accounts allowing key rotation and custom decision policies. + +### 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. + +## 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 + +## 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) diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-043-nft-module.md b/versioned_docs/version-0.46/integrate/architecture/adr-043-nft-module.md new file mode 100644 index 000000000..7d4498bf8 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-043-nft-module.md @@ -0,0 +1,340 @@ +# ADR 43: NFT Module + +## Changelog + +* 2021-05-01: Initial Draft +* 2021-07-02: Review updates + +## 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**: + +* `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. + +## 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. + +As discussed in [#9065](https://github.com/cosmos/cosmos-sdk/discussions/9065), several potential solutions can be considered: + +* irismod/nft and modules/incubator/nft +* CW721 +* DID NFTs +* interNFT + +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. + +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. + +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). + +## Decision + +We create a `x/nft` module, which contains the following functionality: + +* 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. + +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). + +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. + +### 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. + +#### 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. + +```protobuf +message Class { + string id = 1; + string name = 2; + string symbol = 3; + string description = 4; + string uri = 5; + string uri_hash = 6; + google.protobuf.Any data = 7; +} +``` + +* `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_ + +#### NFT + +We define a general model for `NFT` as follows. + +```protobuf +message NFT { + string class_id = 1; + string id = 2; + string uri = 3; + string uri_hash = 4; + google.protobuf.Any data = 10; +} +``` + +* `class_id` is the identifier of the NFT class where the NFT belongs; _required_,`[a-zA-Z][a-zA-Z0-9/:-]{2,100}` +* `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_,`[a-zA-Z][a-zA-Z0-9/:-]{2,100}` + + ```text + {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_ + +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. + +### `Keeper` Interface + +```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 + Update(nft NFT) + Transfer(classId string, nftId string, receiver sdk.AccAddress) + + GetClass(classId string) Class + GetClasses() []Class + + GetNFT(classId string, nftId string) NFT + GetNFTsOfClassByOwner(classId string, owner sdk.AccAddress) []NFT + GetNFTsOfClass(classId string) []NFT + + GetOwner(classId string, nftId string) sdk.AccAddress + GetBalance(classId string, owner sdk.AccAddress) uint64 + GetTotalSupply(classId string) uint64 +} +``` + +Other business logic implementations should be defined in composing modules that import `x/nft` and use its `Keeper`. + +### `Msg` Service + +```protobuf +service Msg { + rpc Send(MsgSend) returns (MsgSendResponse); +} + +message MsgSend { + string class_id = 1; + string id = 2; + string sender = 3; + string reveiver = 4; +} +message MsgSendResponse {} +``` + +`MsgSend` can be used to transfer the ownership of an NFT to another address. + +The implementation outline of the server is as follows: + +```go +type msgServer struct{ + k Keeper +} + +func (m msgServer) Send(ctx context.Context, msg *types.MsgSend) (*types.MsgSendResponse, error) { + // check current ownership + assertEqual(msg.Sender, m.k.GetOwner(msg.ClassId, msg.Id)) + + // 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: + +```proto +service Query { + // 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/{owner}/{class_id}"; + } + + // 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 from the given class, same as totalSupply of ERC721. + rpc Supply(QuerySupplyRequest) returns (QuerySupplyResponse) { + option (google.api.http).get = "/cosmos/nft/v1beta1/supply/{class_id}"; + } + + // NFTs queries all NFTs of a given class or owner,choose at least one of the two, similar to tokenByIndex in ERC721Enumerable + rpc NFTs(QueryNFTsRequest) returns (QueryNFTsResponse) { + option (google.api.http).get = "/cosmos/nft/v1beta1/nfts"; + } + + // 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 + rpc Class(QueryClassRequest) returns (QueryClassResponse) { + option (google.api.http).get = "/cosmos/nft/v1beta1/classes/{class_id}"; + } + + // 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 +message QueryBalanceRequest { + string class_id = 1; + string owner = 2; +} + +// 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 +message QueryOwnerRequest { + string class_id = 1; + string id = 2; +} + +// 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 +message QuerySupplyRequest { + string class_id = 1; +} + +// QuerySupplyResponse is the response type for the Query/Supply RPC method +message QuerySupplyResponse { + uint64 amount = 1; +} + +// QueryNFTstRequest is the request type for the Query/NFTs RPC method +message QueryNFTsRequest { + string class_id = 1; + string owner = 2; + cosmos.base.query.v1beta1.PageRequest pagination = 3; +} + +// QueryNFTsResponse is the response type for the Query/NFTs 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 +message QueryNFTRequest { + string class_id = 1; + string id = 2; +} + +// 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 +message QueryClassRequest { + string class_id = 1; +} + +// 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 +message QueryClassesRequest { + // 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 +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. + +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. + +## 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 + +### 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 + +### Negative + +* New IBC app is required for x/nft +* CW721 adapter is required + +### Neutral + +* 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 + +For other kinds of applications on the Hub, more app-specific modules can be developed in the future: + +* `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/main/docs/architecture/adr-033-protobuf-inter-module-comm.md) diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-044-protobuf-updates-guidelines.md b/versioned_docs/version-0.46/integrate/architecture/adr-044-protobuf-updates-guidelines.md new file mode 100644 index 000000000..6c0b33bc8 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-044-protobuf-updates-guidelines.md @@ -0,0 +1,138 @@ +# ADR 044: Guidelines for Updating Protobuf Definitions + +## Changelog + +* 28.06.2021: Initial Draft +* 02.12.2021: Add `Since:` comment for new fields + +## Status + +Draft + +## Abstract + +This ADR provides guidelines and recommended practices when updating Protobuf definitions. These guidelines are targeting module developers. + +## Context + +The Cosmos SDK maintains a set of [Protobuf definitions](https://github.com/cosmos/cosmos-sdk/tree/main/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. + +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: + +* 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. + +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. + +## Decision + +We decide to keep [Buf's](https://docs.buf.build/) recommendations with the following exceptions: + +* `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. + +On top of Buf's recommendations we add the following guidelines that are specific to the Cosmos SDK. + +### Updating Protobuf Definition Without Bumping Version + +#### 1. `Msg`s MUST NOT have new fields + +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). + +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. + +For this reason, module developers MUST NOT add new fields to existing `Msg`s. + +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`. + +#### 2. Non-`Msg`-related Protobuf definitions MAY have new fields, but MUST add a `Since:` comment + +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. + +The SDK requires the Protobuf comment of the new field to contain one line with the following format: + +```protobuf +// 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. + +As examples, the following comments are valid: + +```protobuf +// Since: cosmos-sdk 0.44 + +// 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 0.44 + +// 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 + +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). + +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: + +* 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`. + +#### 4. Fields MUST NOT be renamed + +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. + +### Incrementing Protobuf Package Version + +TODO, needs architecture review. Some topics: + +* 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 + +## 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 + +* less pain to tool developers +* more compatibility in the ecosystem +* ... + +### Negative + +{negative consequences} + +### Neutral + +* more rigor in Protobuf review + +## 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. + +## 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 + +* [#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 diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-045-check-delivertx-middlewares.md b/versioned_docs/version-0.46/integrate/architecture/adr-045-check-delivertx-middlewares.md new file mode 100644 index 000000000..60172977c --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-045-check-delivertx-middlewares.md @@ -0,0 +1,312 @@ +# ADR 045: BaseApp `{Check,Deliver}Tx` as Middlewares + +## Changelog + +* 20.08.2021: Initial draft. +* 07.12.2021: Update `tx.Handler` interface ([\#10693](https://github.com/cosmos/cosmos-sdk/pull/10693)). +* 17.05.2022: ADR is abandoned, as middlewares are deemed too hard to reason about. + +## Status + +ABANDONED. Replacement is being discussed in [#11955](https://github.com/cosmos/cosmos-sdk/issues/11955). + +## Abstract + +This ADR replaces the current BaseApp `runTx` and antehandlers design with a middleware-based design. + +## 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. + +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. + +## 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`: + +```go +type Handler interface { + CheckTx(ctx context.Context, req Request, checkReq RequestCheckTx) (Response, ResponseCheckTx, error) + DeliverTx(ctx context.Context, req Request) (Response, error) + SimulateTx(ctx context.Context, req Request (Response, error) +} + +type Middleware func(Handler) Handler +``` + +where we define the following arguments and return types: + +```go +type Request struct { + Tx sdk.Tx + TxBytes []byte +} + +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 []*codectypes.Any + Log string + Events []abci.Event +} + +type RequestCheckTx struct { + Type abci.CheckTxType +} + +type ResponseCheckTx struct { + Priority int64 +} +``` + +Please note that because CheckTx handles separate logic related to mempool priotization, its signature is different than DeliverTx and SimulateTx. + +BaseApp holds a reference to a `tx.Handler`: + +```go +type BaseApp struct { + // 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`: + +```go +func (app *BaseApp) DeliverTx(req abci.RequestDeliverTx) abci.ResponseDeliverTx { + var abciRes abci.ResponseDeliverTx + ctx := app.getContextForTx(runTxModeDeliver, req.Tx) + res, err := app.txHandler.DeliverTx(ctx, tx.Request{TxBytes: req.Tx}) + if err != nil { + abciRes = sdkerrors.ResponseDeliverTx(err, uint64(res.GasUsed), uint64(res.GasWanted), app.trace) + return abciRes + } + + abciRes, err = convertTxResponseToDeliverTx(res) + if err != nil { + return sdkerrors.ResponseDeliverTx(err, uint64(res.GasUsed), uint64(res.GasWanted), app.trace) + } + + return abciRes +} + +// convertTxResponseToDeliverTx converts a tx.Response into a abci.ResponseDeliverTx. +func convertTxResponseToDeliverTx(txRes tx.Response) (abci.ResponseDeliverTx, error) { + data, err := makeABCIData(txRes) + if err != nil { + return abci.ResponseDeliverTx{}, nil + } + + return abci.ResponseDeliverTx{ + Data: data, + Log: txRes.Log, + Events: txRes.Events, + }, nil +} + +// 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.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. + +### 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`. + +For example, for creating an arbitrary `MyMiddleware`, we can implement: + +```go +// 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 tx.Handler + // some other fields that are relevant to the middleware can be added here +} + +// 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 + } + } +} + +// 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 + + // run the next middleware + res, checkRes, err := txh.next.CheckTx(ctx, req, checkReq) + + // 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 + + // run the next middleware + res, err := txh.next.DeliverTx(ctx, tx, req) + + // DeliverTx specific post-processing logic + + return res, err +} + +func (h myTxHandler) SimulateTx(ctx context.Context, req Request) (Response, error) { + // SimulateTx specific pre-processing logic + + // run the next middleware + res, err := txh.next.SimulateTx(ctx, tx, req) + + // 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. + +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: + +```text +A.pre + B.pre + C.pre + H # The base tx.handler, for example `RunMsgsTxHandler` + C.post + B.post +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: + +```go +txHandler := middleware.ComposeMiddlewares(H, A, B, C) +``` + +The middleware is set in BaseApp via its `SetTxHandler` setter: + +```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()`. + +### Middlewares Maintained by the Cosmos SDK + +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: + +| Middleware | Description | +| ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| RunMsgsTxHandler | This is the base `tx.Handler`. It replaces the old baseapp's `runMsgs`, and executes a transaction's `Msg`s. | +| TxDecoderMiddleware | This middleware takes in transaction raw bytes, and decodes them into a `sdk.Tx`. It replaces the `baseapp.txDecoder` field, so that BaseApp stays as thin as possible. Since most middlewares read the contents of the `sdk.Tx`, the TxDecoderMiddleware should be run first in the middleware stack. | +| {Antehandlers} | Each antehandler is converted to its own middleware. These middlewares perform signature verification, fee deductions and other validations on the incoming transaction. | +| IndexEventsTxMiddleware | This is a simple middleware that chooses which events to index in Tendermint. Replaces `baseapp.indexEvents` (which unfortunately still exists in baseapp too, because it's used to index Begin/EndBlock events) | +| 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). + +#### 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. + +#### 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`. + +## 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: + +```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, ++}) +if err != nil { + panic(err) +} +- 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. + +### Positive + +* 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 + +* 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. + +### 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. + +## 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. + +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) diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-046-module-params.md b/versioned_docs/version-0.46/integrate/architecture/adr-046-module-params.md new file mode 100644 index 000000000..6c068e4e0 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-046-module-params.md @@ -0,0 +1,184 @@ +# ADR 046: Module Params + +## Changelog + +* Sep 22, 2021: Initial Draft + +## Status + +Proposed + +## 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 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 + +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. + +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, `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. + +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: + +```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 { + // ... +} +``` + +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 +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 + +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. + +### 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. + + + +## 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 diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-047-extend-upgrade-plan.md b/versioned_docs/version-0.46/integrate/architecture/adr-047-extend-upgrade-plan.md new file mode 100644 index 000000000..0df030062 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-047-extend-upgrade-plan.md @@ -0,0 +1,245 @@ +# ADR 047: Extend Upgrade Plan + +## Changelog + +- Nov, 23, 2021: Initial Draft + +## Status + +PROPOSED Not Implemented + +## Abstract + +This ADR expands the existing x/upgrade `Plan` proto message to include new fields for defining pre-run and post-run processes within upgrade tooling. +It also defines a structure for providing downloadable artifacts involved in an upgrade. + +## Context + +The `upgrade` module in conjunction with Cosmovisor are designed to facilitate and automate a blockchain's transition from one version to another. + +Users submit a software upgrade governance proposal containing an upgrade `Plan`. +The [Plan](https://github.com/cosmos/cosmos-sdk/blob/v0.44.5/proto/cosmos/upgrade/v1beta1/upgrade.proto#L12) currently contains the following fields: +- `name`: A short string identifying the new version. +- `height`: The chain height at which the upgrade is to be performed. +- `info`: A string containing information about the upgrade. + +The `info` string can be anything. +However, Cosmovisor will try to use the `info` field to automatically download a new version of the blockchain executable. +For the auto-download to work, Cosmovisor expects it to be either a stringified JSON object (with a specific structure defined through documentation), or a URL that will return such JSON. +The JSON object identifies URLs used to download the new blockchain executable for different platforms (OS and Architecture, e.g. "linux/amd64"). +Such a URL can either return the executable file directly or can return an archive containing the executable and possibly other assets. + +If the URL returns an archive, it is decompressed into `{DAEMON_HOME}/cosmovisor/{upgrade name}`. +Then, if `{DAEMON_HOME}/cosmovisor/{upgrade name}/bin/{DAEMON_NAME}` does not exist, but `{DAEMON_HOME}/cosmovisor/{upgrade name}/{DAEMON_NAME}` does, the latter is copied to the former. +If the URL returns something other than an archive, it is downloaded to `{DAEMON_HOME}/cosmovisor/{upgrade name}/bin/{DAEMON_NAME}`. + +If an upgrade height is reached and the new version of the executable version isn't available, Cosmovisor will stop running. + +Both `DAEMON_HOME` and `DAEMON_NAME` are [environment variables used to configure Cosmovisor](https://github.com/cosmos/cosmos-sdk/blob/cosmovisor/v1.0.0/cosmovisor/README.md#command-line-arguments-and-environment-variables). + +Currently, there is no mechanism that makes Cosmovisor run a command after the upgraded chain has been restarted. + +The current upgrade process has this timeline: +1. An upgrade governance proposal is submitted and approved. +1. The upgrade height is reached. +1. The `x/upgrade` module writes the `upgrade_info.json` file. +1. The chain halts. +1. Cosmovisor backs up the data directory (if set up to do so). +1. Cosmovisor downloads the new executable (if not already in place). +1. Cosmovisor executes the `${DAEMON_NAME} pre-upgrade`. +1. Cosmovisor restarts the app using the new version and same args originally provided. + +## Decision + +### Protobuf Updates + +We will update the `x/upgrade.Plan` message for providing upgrade instructions. +The upgrade instructions will contain a list of artifacts available for each platform. +It allows for the definition of a pre-run and post-run commands. +These commands are not consensus guaranteed; they will be executed by Cosmosvisor (or other) during its upgrade handling. + +```protobuf +message Plan { + // ... (existing fields) + + UpgradeInstructions instructions = 6; +} +``` + +The new `UpgradeInstructions instructions` field MUST be optional. + +```protobuf +message UpgradeInstructions { + string pre_run = 1; + string post_run = 2; + repeated Artifact artifacts = 3; + string description = 4; +} +``` + +All fields in the `UpgradeInstructions` are optional. +- `pre_run` is a command to run prior to the upgraded chain restarting. + If defined, it will be executed after halting and downloading the new artifact but before restarting the upgraded chain. + The working directory this command runs from MUST be `{DAEMON_HOME}/cosmovisor/{upgrade name}`. + This command MUST behave the same as the current [pre-upgrade](https://github.com/cosmos/cosmos-sdk/blob/v0.44.5/docs/migrations/pre-upgrade.md) command. + It does not take in any command-line arguments and is expected to terminate with the following exit codes: + + | Exit status code | How it is handled in Cosmosvisor | + |------------------|---------------------------------------------------------------------------------------------------------------------| + | `0` | Assumes `pre-upgrade` command executed successfully and continues the upgrade. | + | `1` | Default exit code when `pre-upgrade` command has not been implemented. | + | `30` | `pre-upgrade` command was executed but failed. This fails the entire upgrade. | + | `31` | `pre-upgrade` command was executed but failed. But the command is retried until exit code `1` or `30` are returned. | + If defined, then the app supervisors (e.g. Cosmovisor) MUST NOT run `app pre-run`. +- `post_run` is a command to run after the upgraded chain has been started. If defined, this command MUST be only executed at most once by an upgrading node. + The output and exit code SHOULD be logged but SHOULD NOT affect the running of the upgraded chain. + The working directory this command runs from MUST be `{DAEMON_HOME}/cosmovisor/{upgrade name}`. +- `artifacts` define items to be downloaded. + It SHOULD have only one entry per platform. +- `description` contains human-readable information about the upgrade and might contain references to external resources. + It SHOULD NOT be used for structured processing information. + +```protobuf +message Artifact { + string platform = 1; + string url = 2; + string checksum = 3; + string checksum_algo = 4; +} +``` + +- `platform` is a required string that SHOULD be in the format `{OS}/{CPU}`, e.g. `"linux/amd64"`. + The string `"any"` SHOULD also be allowed. + An `Artifact` with a `platform` of `"any"` SHOULD be used as a fallback when a specific `{OS}/{CPU}` entry is not found. + That is, if an `Artifact` exists with a `platform` that matches the system's OS and CPU, that should be used; + otherwise, if an `Artifact` exists with a `platform` of `any`, that should be used; + otherwise no artifact should be downloaded. +- `url` is a required URL string that MUST conform to [RFC 1738: Uniform Resource Locators](https://www.ietf.org/rfc/rfc1738.txt). + A request to this `url` MUST return either an executable file or an archive containing either `bin/{DAEMON_NAME}` or `{DAEMON_NAME}`. + The URL should not contain checksum - it should be specified by the `checksum` attribute. +- `checksum` is a checksum of the expected result of a request to the `url`. + It is not required, but is recommended. + If provided, it MUST be a hex encoded checksum string. + Tools utilizing these `UpgradeInstructions` MUST fail if a `checksum` is provided but is different from the checksum of the result returned by the `url`. +- `checksum_algo` is a string identify the algorithm used to generate the `checksum`. + Recommended algorithms: `sha256`, `sha512`. + Algorithms also supported (but not recommended): `sha1`, `md5`. + If a `checksum` is provided, a `checksum_algo` MUST also be provided. + +A `url` is not required to contain a `checksum` query parameter. +If the `url` does contain a `checksum` query parameter, the `checksum` and `checksum_algo` fields MUST also be populated, and their values MUST match the value of the query parameter. +For example, if the `url` is `"https://example.com?checksum=md5:d41d8cd98f00b204e9800998ecf8427e"`, then the `checksum` field must be `"d41d8cd98f00b204e9800998ecf8427e"` and the `checksum_algo` field must be `"md5"`. + +### Upgrade Module Updates + +If an upgrade `Plan` does not use the new `UpgradeInstructions` field, existing functionality will be maintained. +The parsing of the `info` field as either a URL or `binaries` JSON will be deprecated. +During validation, if the `info` field is used as such, a warning will be issued, but not an error. + +We will update the creation of the `upgrade-info.json` file to include the `UpgradeInstructions`. + +We will update the optional validation available via CLI to account for the new `Plan` structure. +We will add the following validation: +1. If `UpgradeInstructions` are provided: + 1. There MUST be at least one entry in `artifacts`. + 1. All of the `artifacts` MUST have a unique `platform`. + 1. For each `Artifact`, if the `url` contains a `checksum` query parameter: + 1. The `checksum` query parameter value MUST be in the format of `{checksum_algo}:{checksum}`. + 1. The `{checksum}` from the query parameter MUST equal the `checksum` provided in the `Artifact`. + 1. The `{checksum_algo}` from the query parameter MUST equal the `checksum_algo` provided in the `Artifact`. +1. The following validation is currently done using the `info` field. We will apply similar validation to the `UpgradeInstructions`. + For each `Artifact`: + 1. The `platform` MUST have the format `{OS}/{CPU}` or be `"any"`. + 1. The `url` field MUST NOT be empty. + 1. The `url` field MUST be a proper URL. + 1. A `checksum` MUST be provided either in the `checksum` field or as a query parameter in the `url`. + 1. If the `checksum` field has a value and the `url` also has a `checksum` query parameter, the two values MUST be equal. + 1. The `url` MUST return either a file or an archive containing either `bin/{DAEMON_NAME}` or `{DAEMON_NAME}`. + 1. If a `checksum` is provided (in the field or as a query param), the checksum of the result of the `url` MUST equal the provided checksum. + +Downloading of an `Artifact` will happen the same way that URLs from `info` are currently downloaded. + +### Cosmovisor Updates + +If the `upgrade-info.json` file does not contain any `UpgradeInstructions`, existing functionality will be maintained. + +We will update Cosmovisor to look for and handle the new `UpgradeInstructions` in `upgrade-info.json`. +If the `UpgradeInstructions` are provided, we will do the following: +1. The `info` field will be ignored. +1. The `artifacts` field will be used to identify the artifact to download based on the `platform` that Cosmovisor is running in. +1. If a `checksum` is provided (either in the field or as a query param in the `url`), and the downloaded artifact has a different checksum, the upgrade process will be interrupted and Cosmovisor will exit with an error. +1. If a `pre_run` command is defined, it will be executed at the same point in the process where the `app pre-upgrade` command would have been executed. + It will be executed using the same environment as other commands run by Cosmovisor. +1. If a `post_run` command is defined, it will be executed after executing the command that restarts the chain. + It will be executed in a background process using the same environment as the other commands. + Any output generated by the command will be logged. + Once complete, the exit code will be logged. + +We will deprecate the use of the `info` field for anything other than human readable information. +A warning will be logged if the `info` field is used to define the assets (either by URL or JSON). + +The new upgrade timeline is very similar to the current one. Changes are in bold: +1. An upgrade governance proposal is submitted and approved. +1. The upgrade height is reached. +1. The `x/upgrade` module writes the `upgrade_info.json` file **(now possibly with `UpgradeInstructions`)**. +1. The chain halts. +1. Cosmovisor backs up the data directory (if set up to do so). +1. Cosmovisor downloads the new executable (if not already in place). +1. Cosmovisor executes **the `pre_run` command if provided**, or else the `${DAEMON_NAME} pre-upgrade` command. +1. Cosmovisor restarts the app using the new version and same args originally provided. +1. **Cosmovisor immediately runs the `post_run` command in a detached process.** + +## Consequences + +### Backwards Compatibility + +Since the only change to existing definitions is the addition of the `instructions` field to the `Plan` message, and that field is optional, there are no backwards incompatibilities with respects to the proto messages. +Additionally, current behavior will be maintained when no `UpgradeInstructions` are provided, so there are no backwards incompatibilities with respects to either the upgrade module or Cosmovisor. + +### Forwards Compatibility + +In order to utilize the `UpgradeInstructions` as part of a software upgrade, both of the following must be true: +1. The chain must already be using a sufficiently advanced version of the Cosmos SDK. +1. The chain's nodes must be using a sufficiently advanced version of Cosmovisor. + +### Positive + +1. The structure for defining artifacts is clearer since it is now defined in the proto instead of in documentation. +1. Availability of a pre-run command becomes more obvious. +1. A post-run command becomes possible. + +### Negative + +1. The `Plan` message becomes larger. This is negligible because A) the `x/upgrades` module only stores at most one upgrade plan, and B) upgrades are rare enough that the increased gas cost isn't a concern. +1. There is no option for providing a URL that will return the `UpgradeInstructions`. +1. The only way to provide multiple assets (executables and other files) for a platform is to use an archive as the platform's artifact. + +### Neutral + +1. Existing functionality of the `info` field is maintained when the `UpgradeInstructions` aren't provided. + +## Further Discussions + +1. [Draft PR #10032 Comment](https://github.com/cosmos/cosmos-sdk/pull/10032/files?authenticity_token=pLtzpnXJJB%2Fif2UWiTp9Td3MvRrBF04DvjSuEjf1azoWdLF%2BSNymVYw9Ic7VkqHgNLhNj6iq9bHQYnVLzMXd4g%3D%3D&file-filters%5B%5D=.go&file-filters%5B%5D=.proto#r698708349): + Consider different names for `UpgradeInstructions instructions` (either the message type or field name). +1. [Draft PR #10032 Comment](https://github.com/cosmos/cosmos-sdk/pull/10032/files?authenticity_token=pLtzpnXJJB%2Fif2UWiTp9Td3MvRrBF04DvjSuEjf1azoWdLF%2BSNymVYw9Ic7VkqHgNLhNj6iq9bHQYnVLzMXd4g%3D%3D&file-filters%5B%5D=.go&file-filters%5B%5D=.proto#r754655072): + 1. Consider putting the `string platform` field inside `UpgradeInstructions` and make `UpgradeInstructions` a repeated field in `Plan`. + 1. Consider using a `oneof` field in the `Plan` which could either be `UpgradeInstructions` or else a URL that should return the `UpgradeInstructions`. + 1. Consider allowing `info` to either be a JSON serialized version of `UpgradeInstructions` or else a URL that returns that. +1. [Draft PR #10032 Comment](https://github.com/cosmos/cosmos-sdk/pull/10032/files?authenticity_token=pLtzpnXJJB%2Fif2UWiTp9Td3MvRrBF04DvjSuEjf1azoWdLF%2BSNymVYw9Ic7VkqHgNLhNj6iq9bHQYnVLzMXd4g%3D%3D&file-filters%5B%5D=.go&file-filters%5B%5D=.proto#r755462876): + Consider not including the `UpgradeInstructions.description` field, using the `info` field for that purpose instead. +1. [Draft PR #10032 Comment](https://github.com/cosmos/cosmos-sdk/pull/10032/files?authenticity_token=pLtzpnXJJB%2Fif2UWiTp9Td3MvRrBF04DvjSuEjf1azoWdLF%2BSNymVYw9Ic7VkqHgNLhNj6iq9bHQYnVLzMXd4g%3D%3D&file-filters%5B%5D=.go&file-filters%5B%5D=.proto#r754643691): + Consider allowing multiple artifacts to be downloaded for any given `platform` by adding a `name` field to the `Artifact` message. +1. [PR #10502 Comment](https://github.com/cosmos/cosmos-sdk/pull/10602#discussion_r781438288) + Allow the new `UpgradeInstructions` to be provided via URL. +1. [PR #10502 Comment](https://github.com/cosmos/cosmos-sdk/pull/10602#discussion_r781438288) + Allow definition of a `signer` for assets (as an alternative to using a `checksum`). + +## References + +- [Current upgrade.proto](https://github.com/cosmos/cosmos-sdk/blob/v0.44.5/proto/cosmos/upgrade/v1beta1/upgrade.proto) +- [Upgrade Module README](https://github.com/cosmos/cosmos-sdk/blob/v0.44.5/x/upgrade/spec/README.md) +- [Cosmovisor README](https://github.com/cosmos/cosmos-sdk/blob/cosmovisor/v1.0.0/cosmovisor/README.md) +- [Pre-upgrade README](https://github.com/cosmos/cosmos-sdk/blob/v0.44.5/docs/migrations/pre-upgrade.md) +- [Draft/POC PR #10032](https://github.com/cosmos/cosmos-sdk/pull/10032) +- [RFC 1738: Uniform Resource Locators](https://www.ietf.org/rfc/rfc1738.txt) diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-048-consensus-fees.md b/versioned_docs/version-0.46/integrate/architecture/adr-048-consensus-fees.md new file mode 100644 index 000000000..4ce4c8137 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-048-consensus-fees.md @@ -0,0 +1,203 @@ +# ADR 048: Multi Tire Gas Price System + +## Changelog + +- Dec 1, 2021: Initial Draft + +## Status + +Rejected + +## Abstract + +This ADR describes a flexible mechanism to maintain a consensus level gas prices, in which one can choose a multi-tier gas price system or EIP-1559 like one through configuration. + +## Context + +Currently, each validator configures it's own `minimal-gas-prices` in `app.yaml`. But setting a proper minimal gas price is critical to protect network from dos attack, and it's hard for all the validators to pick a sensible value, so we propose to maintain a gas price in consensus level. + +Since tendermint 0.35 has supported mempool prioritization, we can take advantage of that to implement more sophisticated gas fee system. + +## Multi-Tier Price System + +We propose a multi-tier price system on consensus to provide maximum flexibility: + +- Tier 1: a constant gas price, which could only be modified occasionally through governance proposal. +- Tier 2: a dynamic gas price which is adjusted according to previous block load. +- Tier 3: a dynamic gas price which is adjusted according to previous block load at a higher speed. + +The gas price of higher tier should bigger than the lower tier. + +The transaction fees are charged with the exact gas price calculated on consensus. + +The parameter schema is like this: + +```protobuf +message TierParams { + uint32 priority = 1 // priority in tendermint mempool + Coin initial_gas_price = 2 // + uint32 parent_gas_target = 3 // the target saturation of block + uint32 change_denominator = 4 // decides the change speed + Coin min_gas_price = 5 // optional lower bound of the price adjustment + Coin max_gas_price = 6 // optional upper bound of the price adjustment +} + +message Params { + repeated TierParams tiers = 1; +} +``` + +### Extension Options + +We need to allow user to specify the tier of service for the transaction, to support it in an extensible way, we add an extension option in `AuthInfo`: + +```protobuf +message ExtensionOptionsTieredTx { + uint32 fee_tier = 1 +} +``` + +The value of `fee_tier` is just the index to the `tiers` parameter list. + +We also change the semantic of existing `fee` field of `Tx`, instead of charging user the exact `fee` amount, we treat it as a fee cap, while the actual amount of fee charged is decided dynamically. If the `fee` is smaller than dynamic one, the transaction won't be included in current block and ideally should stay in the mempool until the consensus gas price drop. The mempool can eventually prune old transactions. + +### Tx Prioritization + +Transactions are prioritized based on the tier, the higher the tier, the higher the priority. + +Within the same tier, follow the default Tendermint order (currently FIFO). Be aware of that the mempool tx ordering logic is not part of consensus and can be modified by malicious validator. + +This mechanism can be easily composed with prioritization mechanisms: +* we can add extra tiers out of a user control: + * Example 1: user can set tier 0, 10 or 20, but the protocol will create tiers 0, 1, 2 ... 29. For example IBC transactions will go to tier `user_tier + 5`: if user selected tier 1, then the transaction will go to tier 15. + * Example 2: we can reserve tier 4, 5, ... only for special transaction types. For example, tier 5 is reserved for evidence tx. So if submits a bank.Send transaction and set tier 5, it will be delegated to tier 3 (the max tier level available for any transaction). + * Example 3: we can enforce that all transactions of a sepecific type will go to specific tier. For example, tier 100 will be reserved for evidence transactions and all evidence transactions will always go to that tier. + +### `min-gas-prices` + +Deprecate the current per-validator `min-gas-prices` configuration, since it would confusing for it to work together with the consensus gas price. + +### Adjust For Block Load + +For tier 2 and tier 3 transactions, the gas price is adjusted according to previous block load, the logic could be similar to EIP-1559: + +```python +def adjust_gas_price(gas_price, parent_gas_used, tier): + if parent_gas_used == tier.parent_gas_target: + return gas_price + elif parent_gas_used > tier.parent_gas_target: + gas_used_delta = parent_gas_used - tier.parent_gas_target + gas_price_delta = max(gas_price * gas_used_delta // tier.parent_gas_target // tier.change_speed, 1) + return gas_price + gas_price_delta + else: + gas_used_delta = parent_gas_target - parent_gas_used + gas_price_delta = gas_price * gas_used_delta // parent_gas_target // tier.change_speed + return gas_price - gas_price_delta +``` + +### Block Segment Reservation + +Ideally we should reserve block segments for each tier, so the lower tiered transactions won't be completely squeezed out by higher tier transactions, which will force user to use higher tier, and the system degraded to a single tier. + +We need help from tendermint to implement this. + +## Implementation + +We can make each tier's gas price strategy fully configurable in protocol parameters, while providing a sensible default one. + +Pseudocode in python-like syntax: + +```python +interface TieredTx: + def tier(self) -> int: + pass + +def tx_tier(tx): + if isinstance(tx, TieredTx): + return tx.tier() + else: + # default tier for custom transactions + return 0 + # NOTE: we can add more rules here per "Tx Prioritization" section + +class TierParams: + 'gas price strategy parameters of one tier' + priority: int # priority in tendermint mempool + initial_gas_price: Coin + parent_gas_target: int + change_speed: Decimal # 0 means don't adjust for block load. + +class Params: + 'protocol parameters' + tiers: List[TierParams] + +class State: + 'consensus state' + # total gas used in last block, None when it's the first block + parent_gas_used: Optional[int] + # gas prices of last block for all tiers + gas_prices: List[Coin] + +def begin_block(): + 'Adjust gas prices' + for i, tier in enumerate(Params.tiers): + if State.parent_gas_used is None: + # initialized gas price for the first block + State.gas_prices[i] = tier.initial_gas_price + else: + # adjust gas price according to gas used in previous block + State.gas_prices[i] = adjust_gas_price(State.gas_prices[i], State.parent_gas_used, tier) + +def mempoolFeeTxHandler_checkTx(ctx, tx): + # the minimal-gas-price configured by validator, zero in deliver_tx context + validator_price = ctx.MinGasPrice() + consensus_price = State.gas_prices[tx_tier(tx)] + min_price = max(validator_price, consensus_price) + + # zero means infinity for gas price cap + if tx.gas_price() > 0 and tx.gas_price() < min_price: + return 'insufficient fees' + return next_CheckTx(ctx, tx) + +def txPriorityHandler_checkTx(ctx, tx): + res, err := next_CheckTx(ctx, tx) + # pass priority to tendermint + res.Priority = Params.tiers[tx_tier(tx)].priority + return res, err + +def end_block(): + 'Update block gas used' + State.parent_gas_used = block_gas_meter.consumed() +``` + +### Dos attack protection + +To fully saturate the blocks and prevent other transactions from executing, attacker need to use transactions of highest tier, the cost would be significantly higher than the default tier. + +If attacker spam with lower tier transactions, user can mitigate by sending higher tier transactions. + +## Consequences + +### Backwards Compatibility + +- New protocol parameters. +- New consensus states. +- New/changed fields in transaction body. + +### Positive + +- The default tier keeps the same predictable gas price experience for client. +- The higher tier's gas price can adapt to block load. +- No priority conflict with custom priority based on transaction types, since this proposal only occupy three priority levels. +- Possibility to compose different priority rules with tiers + +### Negative + +- Wallets & tools need to update to support the new `tier` parameter, and semantic of `fee` field is changed. + +### Neutral + +## References + +- https://eips.ethereum.org/EIPS/eip-1559 +- https://iohk.io/en/blog/posts/2021/11/26/network-traffic-and-tiered-pricing/ diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-049-state-sync-hooks.md b/versioned_docs/version-0.46/integrate/architecture/adr-049-state-sync-hooks.md new file mode 100644 index 000000000..e1616c226 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-049-state-sync-hooks.md @@ -0,0 +1,160 @@ +# ADR 049: State Sync Hooks + +## Changelog + +- Jan 19, 2022: Initial Draft + +## Status + +Draft, Under Implementation + +## Abstract + +This ADR outlines a hooks-based mechanism for application modules to provide additional state (outside of the IAVL tree) to be used +during state sync. + +## Context + +New clients use state-sync to download snapshots of module state from peers. Currently, the snapshot consists of a +stream of `SnapshotStoreItem` and `SnapshotIAVLItem`, which means that application modules that define their state outside of the IAVL +tree cannot include their state as part of the state-sync process. + +Note, Even though the module state data is outside of the tree, for determinism we require that the hash of the external data should +be posted in the IAVL tree. + +## Decision + +A simple proposal based on our existing implementation is that, we can add two new message types: `SnapshotExtensionMeta` +and `SnapshotExtensionPayload`, and they are appended to the existing multi-store stream with `SnapshotExtensionMeta` +acting as a delimiter between extensions. As the chunk hashes should be able to ensure data integrity, we don't need +a delimiter to mark the end of the snapshot stream. + +Besides, we provide `Snapshotter` and `ExtensionSnapshotter` interface for modules to implement snapshotters, which will handle both taking +snapshot and the restoration. Each module could have mutiple snapshotters, and for modules with additional state, they should +implement `ExtensionSnapshotter` as extension snapshotters. When setting up the application, the snapshot `Manager` should call +`RegisterExtensions([]ExtensionSnapshotter…)` to register all the extension snapshotters. + +```proto +// SnapshotItem is an item contained in a rootmulti.Store snapshot. +// On top of the exsiting SnapshotStoreItem and SnapshotIAVLItem, we add two new options for the item. +message SnapshotItem { + // item is the specific type of snapshot item. + oneof item { + SnapshotStoreItem store = 1; + SnapshotIAVLItem iavl = 2 [(gogoproto.customname) = "IAVL"]; + SnapshotExtensionMeta extension = 3; + SnapshotExtensionPayload extension_payload = 4; + } +} + +// SnapshotExtensionMeta contains metadata about an external snapshotter. +// One module may need multiple snapshotters, so each module may have multiple SnapshotExtensionMeta. +message SnapshotExtensionMeta { + // the name of the ExtensionSnapshotter, and it is registered to snapshotter manager when setting up the application + // name should be unique for each ExtensionSnapshotter as we need to alphabetically order their snapshots to get + // deterministic snapshot stream. + string name = 1; + // this is used by each ExtensionSnapshotter to decide the format of payloads included in SnapshotExtensionPayload message + // it is used within the snapshotter/namespace, not global one for all modules + uint32 format = 2; +} + +// SnapshotExtensionPayload contains payloads of an external snapshotter. +message SnapshotExtensionPayload { + bytes payload = 1; +} +``` + +When we create a snapshot stream, the `multistore` snapshot is always placed at the beginning of the binary stream, and other extension snapshots are alphabetically ordered by the name of the corresponding `ExtensionSnapshotter`. + +The snapshot stream would look like as follows: + +```go +// multi-store snapshot +{SnapshotStoreItem | SnapshotIAVLItem, ...} +// extension1 snapshot +SnapshotExtensionMeta +{SnapshotExtensionPayload, ...} +// extension2 snapshot +SnapshotExtensionMeta +{SnapshotExtensionPayload, ...} +``` + +We add an `extensions` field to snapshot `Manager` for extension snapshotters. The `multistore` snapshotter is a special one and it doesn't need a name because it is always placed at the beginning of the binary stream. + +```go +type Manager struct { + store *Store + multistore types.Snapshotter + extensions map[string]types.ExtensionSnapshotter + mtx sync.Mutex + operation operation + chRestore chan<- io.ReadCloser + chRestoreDone <-chan restoreDone + restoreChunkHashes [][]byte + restoreChunkIndex uint32 +} +``` + +For extension snapshotters that implement the `ExtensionSnapshotter` interface, their names should be registered to the snapshot `Manager` by +calling `RegisterExtensions` when setting up the application. The snapshotters will handle both taking snapshot and restoration. + +```go +// RegisterExtensions register extension snapshotters to manager +func (m *Manager) RegisterExtensions(extensions ...types.ExtensionSnapshotter) error +``` + +On top of the existing `Snapshotter` interface for the `multistore`, we add `ExtensionSnapshotter` interface for the extension snapshotters. Three more function signatures: `SnapshotFormat()`, `SupportedFormats()` and `SnapshotName()` are added to `ExtensionSnapshotter`. + +```go +// ExtensionSnapshotter is an extension Snapshotter that is appended to the snapshot stream. +// ExtensionSnapshotter has an unique name and manages it's own internal formats. +type ExtensionSnapshotter interface { + Snapshotter + + // SnapshotName returns the name of snapshotter, it should be unique in the manager. + SnapshotName() string + + // SnapshotFormat returns the default format used to take a snapshot. + SnapshotFormat() uint32 + + // SupportedFormats returns a list of formats it can restore from. + SupportedFormats() []uint32 +} +``` + +## Consequences + +As a result of this implementation, we are able to create snapshots of binary chunk stream for the state that we maintain outside of the IAVL Tree, CosmWasm blobs for example. And new clients are able to fetch sanpshots of state for all modules that have implemented the corresponding interface from peer nodes. + + +### Backwards Compatibility + +This ADR introduces new proto message types, add an `extensions` field in snapshot `Manager`, and add new `ExtensionSnapshotter` interface, so this is not backwards compatible if we have extensions. + +But for applications that does not have the state data outside of the IAVL tree for any module, the snapshot stream is backwards-compatible. + +### Positive + +- State maintained outside of IAVL tree like CosmWasm blobs can create snapshots by implementing extension snapshotters, and being fetched by new clients via state-sync. + +### Negative + +### Neutral + +- All modules that maintain state outside of IAVL tree need to implement `ExtensionSnapshotter` and the snapshot `Manager` need to call `RegisterExtensions` when setting up the application. + +## 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 + +- https://github.com/cosmos/cosmos-sdk/pull/10961 +- https://github.com/cosmos/cosmos-sdk/issues/7340 +- https://hackmd.io/gJoyev6DSmqqkO667WQlGw diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-053-go-module-refactoring.md b/versioned_docs/version-0.46/integrate/architecture/adr-053-go-module-refactoring.md new file mode 100644 index 000000000..9093ae9d9 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-053-go-module-refactoring.md @@ -0,0 +1,109 @@ +# ADR 053: Go Module Refactoring + +## Changelog + +* 2022-04-27: First Draft + +## Status + +PROPOSED + +## Abstract + +The current SDK is built as a single monolithic go module. This ADR describes +how we refactor the SDK into smaller independently versioned go modules +for ease of maintenance. + +## Context + +Go modules impose certain requirements on software projects with respect to +stable version numbers (anything above 0.x) in that [any API breaking changes +necessitate a major version](https://go.dev/doc/modules/release-workflow#breaking) +increase which technically creates a new go module +(with a v2, v3, etc. suffix). + +[Keeping modules API compatible](https://go.dev/blog/module-compatibility) in +this way requires a fair amount of fair thought and discipline. + +The Cosmos SDK is a fairly large project which originated before go modules +came into existence and has always been under a v0.x release even though +it has been used in production for years now, not because it isn't production +quality software, but rather because the API compatibility guarantees required +by go modules are fairly complex to adhere to with such a large project. +Up to now, it has generally been deemed more important to be able to break the +API if needed rather than require all users update all package import paths +to accommodate breaking changes causing v2, v3, etc. releases. This is in +addition to the other complexities related to protobuf generated code that will +be addressed in a separate ADR. + +Nevertheless, the desire for semantic versioning has been [strong in the +community](https://github.com/cosmos/cosmos-sdk/discussions/10162) and the +single go module release process has made it very hard to +release small changes to isolated features in a timely manner. Release cycles +often exceed six months which means small improvements done in a day or +two get bottle-necked by everything else in the monolithic release cycle. + +## Decision + +To improve the current situation, the SDK is being refactored into multiple +go modules within the current repository. There has been a [fair amount of +debate](https://github.com/cosmos/cosmos-sdk/discussions/10582#discussioncomment-1813377) +as to how to do this, with some developers arguing for larger vs smaller +module scopes. There are pros and cons to both approaches (which will be +discussed below in the [Consequences](#consequences) section), but the +approach being adopted is the following: +* a go module should generally be scoped to a specific coherent set of +functionality (such as math, errors, store, etc.) +* when code is removed from the core SDK and moved to a new module path, every +effort should be made to avoid API breaking changes in the existing code using +aliases and wrapper types (as done in https://github.com/cosmos/cosmos-sdk/pull/10779 +and https://github.com/cosmos/cosmos-sdk/pull/11788) +* new go modules should be moved to a standalone domain (`cosmossdk.io`) before +being tagged as `v1.0.0` to accommodate the possibility that they may be +better served by a standalone repository in the future +* all go modules should follow the guidelines in https://go.dev/blog/module-compatibility +before `v1.0.0` is tagged and should make use of `internal` packages to limit +the exposed API surface +* the new go module's API may deviate from the existing code where there are +clear improvements to be made or to remove legacy dependencies (for instance on +amino or gogo proto), as long the old package attempts +to avoid API breakage with aliases and wrappers +* care should be taken when simply trying to turn an existing package into a +new go module: https://github.com/golang/go/wiki/Modules#is-it-possible-to-add-a-module-to-a-multi-module-repository. +In general, it seems safer to just create a new module path (appending v2, v3, etc. +if necessary), rather than trying to make an old package a new module. + +## Consequences + +### Backwards Compatibility + +If the above guidelines are followed to use aliases or wrapper types pointing +in existing APIs that point back to the new go modules, there should be no or +very limited breaking changes to existing APIs. + +### Positive + +* standalone pieces of software will reach `v1.0.0` sooner +* new features to specific functionality will be released sooner + +### Negative + +* there will be more go module versions to update in the SDK itself and +per-project, although most of these will hopefully be indirect + +### Neutral + +## Further Discussions + +Further discussions are occurring in primarily in +https://github.com/cosmos/cosmos-sdk/discussions/10582 and within +the Cosmos SDK Framework Working Group. + +## References + +* https://go.dev/doc/modules/release-workflow +* https://go.dev/blog/module-compatibility +* https://github.com/cosmos/cosmos-sdk/discussions/10162 +* https://github.com/cosmos/cosmos-sdk/discussions/10582 +* https://github.com/cosmos/cosmos-sdk/pull/10779 +* https://github.com/cosmos/cosmos-sdk/pull/11788 \ No newline at end of file diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-055-orm.md b/versioned_docs/version-0.46/integrate/architecture/adr-055-orm.md new file mode 100644 index 000000000..71a759526 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-055-orm.md @@ -0,0 +1,111 @@ +# ADR 055: ORM + +## Changelog + +* 2022-04-27: First draft + +## Status + +ACCEPTED Implemented + +## Abstract + +In order to make it easier for developers to build Cosmos SDK modules and for clients to query, index and verify proofs +against state data, we have implemented an ORM (object-relational mapping) layer for the Cosmos SDK. + +## Context + +Historically modules in the Cosmos SDK have always used the key-value store directly and created various handwritten +functions for managing key format as well as constructing secondary indexes. This consumes a significant amount of +time when building a module and is error-prone. Because key formats are non-standard, sometimes poorly documented, +and subject to change, it is hard for clients to generically index, query and verify merkle proofs against state data. + +The known first instance of an "ORM" in the Cosmos ecosystem was in [weave](https://github.com/iov-one/weave/tree/master/orm). +A later version was built for [regen-ledger](https://github.com/regen-network/regen-ledger/tree/157181f955823149e1825263a317ad8e16096da4/orm) for +use in the group module and later [ported to the SDK](https://github.com/cosmos/cosmos-sdk/tree/35d3312c3be306591fcba39892223f1244c8d108/x/group/internal/orm) +just for that purpose. + +While these earlier designs made it significantly easier to write state machines, they still required a lot of manual +configuration, didn't expose state format directly to clients, and were limited in their support of different types +of index keys, composite keys, and range queries. + +Discussions about the design continued in https://github.com/cosmos/cosmos-sdk/discussions/9156 and more +sophisticated proofs of concept were created in https://github.com/allinbits/cosmos-sdk-poc/tree/master/runtime/orm +and https://github.com/cosmos/cosmos-sdk/pull/10454. + +## Decision + +These prior efforts culminated in the creation of the Cosmos SDK `orm` go module which uses protobuf annotations +for specifying ORM table definitions. This ORM is based on the new `google.golang.org/protobuf/reflect/protoreflect` +API and supports: +* sorted indexes for all simple protobuf types (except `bytes`, `enum`, `float`, `double`) as well as `Timestamp` and `Duration` +* unsorted `bytes` and `enum` indexes +* composite primary and secondary keys +* unique indexes +* auto-incrementing `uint64` primary keys +* complex prefix and range queries +* paginated queries +* complete logical decoding of KV-store data + +Almost all the information needed to decode state directly is specified in .proto files. Each table definition specifies +an ID which is unique per .proto file and each index within a table is unique within that table. Clients then only need +to know the name of a module and the prefix ORM data for a specific .proto file within that module in order to decode +state data directly. This additional information will be exposed directly through app configs which will be explained +in a future ADR related to app wiring. + +The ORM makes optimizations around storage space by not repeating values in the primary key in the key value +when storing primary key records. For example, if the object `{"a":0,"b":1}` has the primary key `a`, it will +be stored in the key value store as `Key: '0', Value: {"b":1}` (with more efficient protobuf binary encoding). +Also, the generated code from https://github.com/cosmos/cosmos-proto does optimizations around the +`google.golang.org/protobuf/reflect/protoreflect` API to improve performance. + +A code generator is included with the ORM which creates type safe wrappers around the ORM's dynamic `Table` +implementation and is the recommended way for modules to use the ORM. + +The ORM tests provide a simplified bank module demonstration which illustrates: +- [ORM proto options](https://github.com/cosmos/cosmos-sdk/blob/0d846ae2f0424b2eb640f6679a703b52d407813d/orm/internal/testpb/bank.proto) +- [Generated Code](https://github.com/cosmos/cosmos-sdk/blob/0d846ae2f0424b2eb640f6679a703b52d407813d/orm/internal/testpb/bank.cosmos_orm.go) +- [Example Usage in a Module Keeper](https://github.com/cosmos/cosmos-sdk/blob/0d846ae2f0424b2eb640f6679a703b52d407813d/orm/model/ormdb/module_test.go) + +## Consequences + +### Backwards Compatibility + +State machine code that adopts the ORM will need migrations as the state layout is generally backwards incompatible. +These state machines will also need to migrate to https://github.com/cosmos/cosmos-proto at least for state data. + +### Positive + +* easier to build modules +* easier to add secondary indexes to state +* possible to write a generic indexer for ORM state +* easier to write clients that do state proofs +* possible to automatically write query layers rather than needing to manually implement gRPC queries + +### Negative + +* worse performance than handwritten keys (for now). See [Further Discussions](#further-discussions) +for potential improvements + +### Neutral + +## Further Discussions + +Further discussions will happen within the Cosmos SDK Framework Working Group. Current planned and ongoing work includes: +* automatically generate client-facing query layer +* client-side query libraries that transparently verify light client proofs +* index ORM data to SQL databases +* improve performance by: + * optimizing existing reflection based code to avoid unnecessary gets when doing deletes & updates of simple tables + * more sophisticated code generation such as making fast path reflection even faster (avoiding `switch` statements), + or even fully generating code that equals handwritten performance + + +## References + +* https://github.com/iov-one/weave/tree/master/orm). +* https://github.com/regen-network/regen-ledger/tree/157181f955823149e1825263a317ad8e16096da4/orm +* https://github.com/cosmos/cosmos-sdk/tree/35d3312c3be306591fcba39892223f1244c8d108/x/group/internal/orm +* https://github.com/cosmos/cosmos-sdk/discussions/9156 +* https://github.com/allinbits/cosmos-sdk-poc/tree/master/runtime/orm +* https://github.com/cosmos/cosmos-sdk/pull/10454 \ No newline at end of file diff --git a/versioned_docs/version-0.46/integrate/architecture/adr-template.md b/versioned_docs/version-0.46/integrate/architecture/adr-template.md new file mode 100644 index 000000000..dae4dfd44 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/architecture/adr-template.md @@ -0,0 +1,60 @@ +# ADR {ADR-NUMBER}: {TITLE} + +## Changelog + +* {date}: {changelog} + +## Status + +{DRAFT | PROPOSED} Not Implemented + +> Please have a look at the [PROCESS](./PROCESS.md#adr-status) page. +> Use DRAFT if the ADR is in a draft stage (draft PR) or PROPOSED if it's in review. + +## Abstract + +> "If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the ADR. +> A short (~200 word) description of the issue being addressed. + +## Context + +> This section describes the forces at play, including technological, political, social, and project local. These forces are probably in tension, and should be called out as such. The language in this section is value-neutral. It is simply describing facts. It should clearly explain the problem and motivation that the proposal aims to resolve. +> {context body} + +## Decision + +> This section describes our response to these forces. It is stated in full sentences, with active voice. "We will ..." +> {decision body} + +## Consequences + +> This section describes the resulting context, after applying the decision. All consequences should be listed here, not just the "positive" ones. A particular decision may have positive, negative, and neutral consequences, but all of them affect the team and project in the future. + +### Backwards Compatibility + +> All ADRs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The ADR must explain how the author proposes to deal with these incompatibilities. ADR submissions without a sufficient backwards compatibility treatise may be rejected outright. + +### Positive + +{positive consequences} + +### Negative + +{negative consequences} + +### Neutral + +{neutral consequences} + +## Further Discussions + +While an ADR is in the DRAFT or PROPOSED stage, this section should contain a summary of issues to be solved in future iterations (usually referencing comments from a pull-request discussion). +Later, this section can optionally list ideas or improvements the author or reviewers found during the analysis of this ADR. + +## Test Cases [optional] + +Test cases for an implementation are mandatory for ADRs that are affecting consensus changes. Other ADRs can choose to include links to test cases if applicable. + +## References + +* {reference link} diff --git a/versioned_docs/version-0.46/integrate/building-modules/README.md b/versioned_docs/version-0.46/integrate/building-modules/README.md new file mode 100644 index 000000000..8dd53c945 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/building-modules/README.md @@ -0,0 +1,23 @@ + + +# Building Modules + +This repository contains documentation on concepts developers need to know in order to build modules for Cosmos SDK applications. + +1. [Introduction to Cosmos SDK Modules](./intro.md) +2. [`AppModule` Interface and Module Manager](./module-manager.md) +3. [Messages and Queries](./messages-and-queries.md) +4. [`Msg` services - Processing Messages](./msg-services.md) +5. [Query Services - Processing Queries](./query-services.md) +6. [BeginBlocker and EndBlocker](./beginblock-endblock.md) +7. [`Keeper`s](./keeper.md) +8. [Invariants](./invariants.md) +9. [Genesis](./genesis.md) +10. [Module Interfaces](./module-interfaces.md) +11. [Standard Module Structure](./structure.md) +12. [Errors](./errors.md) +13. [In-Place Store Migrations](./upgrade.md) diff --git a/versioned_docs/version-0.46/integrate/building-modules/beginblock-endblock.md b/versioned_docs/version-0.46/integrate/building-modules/beginblock-endblock.md new file mode 100644 index 000000000..e324018fc --- /dev/null +++ b/versioned_docs/version-0.46/integrate/building-modules/beginblock-endblock.md @@ -0,0 +1,39 @@ + + +# BeginBlocker and EndBlocker + +`BeginBlocker` and `EndBlocker` are optional methods module developers can implement in their module. They will be triggered at the beginning and at the end of each block respectively, when the [`BeginBlock`](../core/baseapp.md#beginblock) and [`EndBlock`](../core/baseapp.md#endblock) ABCI messages are received from the underlying consensus engine. {synopsis} + +## Pre-requisite Readings + +* [Module Manager](./module-manager.md) {prereq} + +## BeginBlocker and EndBlocker + +`BeginBlocker` and `EndBlocker` are a way for module developers to add automatic execution of logic to their module. This is a powerful tool that should be used carefully, as complex automatic functions can slow down or even halt the chain. + +When needed, `BeginBlocker` and `EndBlocker` are implemented as part of the [`AppModule` interface](./module-manager.md#appmodule). The `BeginBlock` and `EndBlock` methods of the interface implemented in `module.go` generally defer to `BeginBlocker` and `EndBlocker` methods respectively, which are usually implemented in `abci.go`. + +The actual implementation of `BeginBlocker` and `EndBlocker` in `abci.go` are very similar to that of a [`Msg` service](./msg-services.md): + +* They generally use the [`keeper`](./keeper.md) and [`ctx`](../core/context.md) to retrieve information about the latest state. +* If needed, they use the `keeper` and `ctx` to trigger state-transitions. +* If needed, they can emit [`events`](../core/events.md) via the `ctx`'s `EventManager`. + +A specificity of the `EndBlocker` is that it can return validator updates to the underlying consensus engine in the form of an [`[]abci.ValidatorUpdates`](https://docs.tendermint.com/master/spec/abci/abci.html#validatorupdate). This is the preferred way to implement custom validator changes. + +It is possible for developers to define the order of execution between the `BeginBlocker`/`EndBlocker` functions of each of their application's modules via the module's manager `SetOrderBeginBlocker`/`SetOrderEndBlocker` methods. For more on the module manager, click [here](./module-manager.md#manager). + +See an example implementation of `BeginBlocker` from the `distribution` module: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/distribution/abci.go#L14-L38 + +and an example implementation of `EndBlocker` from the `staking` module: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/staking/abci.go#L22-L27 + +## Next {hide} + +Learn about [`keeper`s](./keeper.md) {hide} diff --git a/versioned_docs/version-0.46/integrate/building-modules/errors.md b/versioned_docs/version-0.46/integrate/building-modules/errors.md new file mode 100644 index 000000000..9e7b970fc --- /dev/null +++ b/versioned_docs/version-0.46/integrate/building-modules/errors.md @@ -0,0 +1,50 @@ + + +# Errors + +This document outlines the recommended usage and APIs for error handling in Cosmos SDK modules. {synopsis} + +Modules are encouraged to define and register their own errors to provide better +context on failed message or handler execution. Typically, these errors should be +common or general errors which can be further wrapped to provide additional specific +execution context. + +## Registration + +Modules should define and register their custom errors in `x/{module}/errors.go`. +Registration of errors is handled via the [`errors` package](https://github.com/cosmos/cosmos-sdk/blob/main/errors/errors.go). + +Example: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/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: + +* Must be greater than one, as a code value of one is reserved for internal errors. +* Must be unique within the module. + +Note, the Cosmos SDK provides a core set of *common* errors. These errors are defined in [`types/errors/errors.go`](https://github.com/cosmos/cosmos-sdk/blob/main/types/errors/errors.go). + +## Wrapping + +The custom module errors can be returned as their concrete type as they already fulfill the `error` +interface. However, module errors can be wrapped to provide further context and meaning to failed +execution. + +Example: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/bank/keeper/keeper.go#L143-L184 + +Regardless if an error is wrapped or not, the Cosmos SDK's `errors` package provides a function to determine if +an error is of a particular kind via `Is`. + +## ABCI + +If a module error is registered, the Cosmos SDK `errors` package allows ABCI information to be extracted +through the `ABCIInfo` function. The package also provides `ResponseCheckTx` and `ResponseDeliverTx` as +auxiliary functions to automatically get `CheckTx` and `DeliverTx` responses from an error. diff --git a/versioned_docs/version-0.46/integrate/building-modules/genesis.md b/versioned_docs/version-0.46/integrate/building-modules/genesis.md new file mode 100644 index 000000000..9e9c57738 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/building-modules/genesis.md @@ -0,0 +1,60 @@ + + +# Module Genesis + +Modules generally handle a subset of the state and, as such, they need to define the related subset of the genesis file as well as methods to initialize, verify and export it. {synopsis} + +## Pre-requisite Readings + +* [Module Manager](./module-manager.md) {prereq} +* [Keepers](./keeper.md) {prereq} + +## Type Definition + +The subset of the genesis state defined from a given module is generally defined in a `genesis.proto` file ([more info](../core/encoding.md#gogoproto) on how to define protobuf messages). The struct defining the module's subset of the genesis state is usually called `GenesisState` and contains all the module-related values that need to be initialized during the genesis process. + +See an example of `GenesisState` protobuf message definition from the `auth` module: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/auth/v1beta1/genesis.proto + +Next we present the main genesis-related methods that need to be implemented by module developers in order for their module to be used in Cosmos SDK applications. + +### `DefaultGenesis` + +The `DefaultGenesis()` method is a simple method that calls the constructor function for `GenesisState` with the default value for each parameter. See an example from the `auth` module: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/module.go#L45-L49 + +### `ValidateGenesis` + +The `ValidateGenesis(data 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: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/types/genesis.go#L61-L74 + +## Other Genesis Methods + +Other than the methods related directly to `GenesisState`, module developers are expected to implement two other methods as part of the [`AppModuleGenesis` interface](./module-manager.md#appmodulegenesis) (only if the module needs to initialize a subset of state in genesis). These methods are [`InitGenesis`](#initgenesis) and [`ExportGenesis`](#exportgenesis). + +### `InitGenesis` + +The `InitGenesis` method is executed during [`InitChain`](../core/baseapp.md#initchain) when the application is first started. Given a `GenesisState`, it initializes the subset of the state managed by the module by using the module's [`keeper`](./keeper.md) setter function on each parameter within the `GenesisState`. + +The [module manager](./module-manager.md#manager) of the application is responsible for calling the `InitGenesis` method of each of the application's modules in order. This order is set by the application developer via the manager's `SetOrderGenesisMethod`, which is called in the [application's constructor function](../basics/app-anatomy.md#constructor-function). + +See an example of `InitGenesis` from the `auth` module: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/keeper/genesis.go#L8-L27 + +### `ExportGenesis` + +The `ExportGenesis` method is executed whenever an export of the state is made. It takes the latest known version of the subset of the state managed by the module and creates a new `GenesisState` out of it. This is mainly used when the chain needs to be upgraded via a hard fork. + +See an example of `ExportGenesis` from the `auth` module. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/keeper/genesis.go#L29-L41 + +## Next {hide} + +Learn about [modules interfaces](module-interfaces.md) {hide} diff --git a/versioned_docs/version-0.46/integrate/building-modules/intro.md b/versioned_docs/version-0.46/integrate/building-modules/intro.md new file mode 100644 index 000000000..a6b088549 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/building-modules/intro.md @@ -0,0 +1,92 @@ + + +# Introduction to Cosmos SDK Modules + +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} + +## 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} + +## Role of Modules in a Cosmos SDK Application + +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. + +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 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. + +```text + + + | + | Transaction relayed from the full-node's consensus engine + | to the node's application via DeliverTx + | + | + | + +---------------------v--------------------------+ + | APPLICATION | + | | + | Using baseapp's methods: Decode the Tx, | + | extract and route the message(s) | + | | + +---------------------+--------------------------+ + | + | + | + +---------------------------+ + | + | + | + | Message routed to the correct + | module to be processed + | + | ++----------------+ +---------------+ +----------------+ +------v----------+ +| | | | | | | | +| AUTH MODULE | | BANK MODULE | | STAKING MODULE | | GOV MODULE | +| | | | | | | | +| | | | | | | Handles message,| +| | | | | | | Updates state | +| | | | | | | | ++----------------+ +---------------+ +----------------+ +------+----------+ + | + | + | + | + +--------------------------+ + | + | Return result to the underlying consensus engine (e.g. Tendermint) + | (0=Ok, 1=Err) + v +``` + +As a result of this architecture, building 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. + +## 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`. + +## Main Components of Cosmos SDK Modules + +Modules are by convention defined in the `./x/` subfolder (e.g. the `bank` module will be defined in the `./x/bank` folder). They generally share the same core components: + +* A [`keeper`](./keeper.md), used to access the module's store(s) and update the state. +* A [`Msg` service](./messages-and-queries.md#messages), used to process messages when they are routed to the module by [`BaseApp`](../core/baseapp.md#message-routing) and trigger state-transitions. +* A [query service](./query-services.md), used to process user queries when they are routed to the module by [`BaseApp`](../core/baseapp.md#query-routing). +* Interfaces, for end users to query the subset of the state defined by the module and create `message`s of the custom types defined in the module. + +In addition to these components, modules implement the `AppModule` interface in order to be managed by the [`module manager`](./module-manager.md). + +Please refer to the [structure document](./structure.md) to learn about the recommended structure of a module's directory. + +## Next {hide} + +Read more on the [`AppModule` interface and the `module manager`](./module-manager.md) {hide} diff --git a/versioned_docs/version-0.46/integrate/building-modules/invariants.md b/versioned_docs/version-0.46/integrate/building-modules/invariants.md new file mode 100644 index 000000000..0cbb0adac --- /dev/null +++ b/versioned_docs/version-0.46/integrate/building-modules/invariants.md @@ -0,0 +1,80 @@ + + +# Invariants + +An invariant is a property of the application that should always be true. In the context of the Cosmos SDK, an `Invariant` is a function that checks for a particular invariant. These functions are useful to detect bugs early on and act upon them to limit their potential consequences (e.g. by halting the chain). They are also useful in the development process of the application to detect bugs via simulations. {synopsis} + +## Pre-requisite Readings + +* [Keepers](./keeper.md) {prereq} + +## Implementing `Invariant`s + +An `Invariant` is a function that checks for a particular invariant within a module. Module `Invariant`s must follow the `Invariant` type: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/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. + +In practice, each module implements `Invariant`s in a `keeper/invariants.go` file within the module's folder. The standard is to implement one `Invariant` function per logical grouping of invariants with the following model: + +```go +// Example for an Invariant that checks balance-related invariants + +func BalanceInvariants(k Keeper) sdk.Invariant { + return func(ctx sdk.Context) (string, bool) { + // Implement checks for balance-related invariants + } +} +``` + +Additionally, module developers should generally implement an `AllInvariants` function that runs all the `Invariant`s functions of the module: + +```go +// AllInvariants runs all invariants of the module. +// In this example, the module implements two Invariants: BalanceInvariants and DepositsInvariants + +func AllInvariants(k Keeper) sdk.Invariant { + + return func(ctx sdk.Context) (string, bool) { + res, stop := BalanceInvariants(k)(ctx) + if stop { + return res, stop + } + + return DepositsInvariant(k)(ctx) + } +} +``` + +Finally, module developers need to implement the `RegisterInvariants` method as part of the [`AppModule` interface](./module-manager.md#appmodule). Indeed, the `RegisterInvariants` method of the module, implemented in the `module/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): + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/staking/keeper/invariants.go#L12-L21 + +For more, see an example of [`Invariant`s implementation from the `staking` module](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/staking/keeper/invariants.go). + +## Invariant Registry + +The `InvariantRegistry` is a registry where the `Invariant`s of all the modules of an application are registered. There is only one `InvariantRegistry` per **application**, meaning module developers need not implement their own `InvariantRegistry` when building a module. **All module developers need to do is to register their modules' invariants in the `InvariantRegistry`, as explained in the section above**. The rest of this section gives more information on the `InvariantRegistry` itself, and does not contain anything directly relevant to module developers. + +At its core, the `InvariantRegistry` is defined in the Cosmos SDK as an interface: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/invariant.go#L14-L17 + +Typically, this interface is implemented in the `keeper` of a specific module. The most used implementation of an `InvariantRegistry` can be found in the `crisis` module: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/crisis/keeper/keeper.go#L49-L53 + + The `InvariantRegistry` is therefore typically instantiated by instantiating the `keeper` of the `crisis` module in the [application's constructor function](../basics/app-anatomy.md#constructor-function). + +`Invariant`s can be checked manually via [`message`s](./messages-and-queries.md), but most often they are checked automatically at the end of each block. Here is an example from the `crisis` module: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/crisis/abci.go#L12-L21 + +In both cases, if one of the `Invariant`s returns false, the `InvariantRegistry` can trigger special logic (e.g. have the application panic and print the `Invariant`s message in the log). + +## Next {hide} + +Learn about [genesis functionalities](./genesis.md) {hide} diff --git a/versioned_docs/version-0.46/integrate/building-modules/keeper.md b/versioned_docs/version-0.46/integrate/building-modules/keeper.md new file mode 100644 index 000000000..78712a91b --- /dev/null +++ b/versioned_docs/version-0.46/integrate/building-modules/keeper.md @@ -0,0 +1,85 @@ + + +# Keepers + +`Keeper`s refer to a Cosmos SDK abstraction whose role is to manage access to the subset of the state defined by various modules. `Keeper`s are module-specific, i.e. the subset of state defined by a module can only be accessed by a `keeper` defined in said module. If a module needs to access the subset of state defined by another module, a reference to the second module's internal `keeper` needs to be passed to the first one. This is done in `app.go` during the instantiation of module keepers. {synopsis} + +## Pre-requisite Readings + +* [Introduction to Cosmos SDK Modules](./intro.md) {prereq} + +## Motivation + +The Cosmos SDK is a framework that makes it easy for developers to build complex decentralized applications from scratch, mainly by composing modules together. As the ecosystem of open-source modules for the Cosmos SDK expands, it will become increasingly likely that some of these modules contain vulnerabilities, as a result of the negligence or malice of their developer. + +The Cosmos SDK adopts an [object-capabilities-based approach](../core/ocap.md) to help developers better protect their application from unwanted inter-module interactions, and `keeper`s are at the core of this approach. A `keeper` can be considered quite literally to be the gatekeeper of a module's store(s). Each store (typically an [`IAVL` Store](../core/store.md#iavl-store)) defined within a module comes with a `storeKey`, which grants unlimited access to it. The module's `keeper` holds this `storeKey` (which should otherwise remain unexposed), and defines [methods](#implementing-methods) for reading and writing to the store(s). + +The core idea behind the object-capabilities approach is to only reveal what is necessary to get the work done. In practice, this means that instead of handling permissions of modules through access-control lists, module `keeper`s are passed a reference to the specific instance of the other modules' `keeper`s that they need to access (this is done in the [application's constructor function](../basics/app-anatomy.md#constructor-function)). As a consequence, a module can only interact with the subset of state defined in another module via the methods exposed by the instance of the other module's `keeper`. This is a great way for developers to control the interactions that their own module can have with modules developed by external developers. + +## Type Definition + +`keeper`s are generally implemented in a `/keeper/keeper.go` file located in the module's folder. By convention, the type `keeper` of a module is simply named `Keeper` and usually follows the following structure: + +```go +type Keeper struct { + // External keepers, if any + + // Store key(s) + + // codec +} +``` + +For example, here is the type definition of the `keeper` from the `staking` module: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/staking/keeper/keeper.go#L21-L29 + +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. + +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. + +## Implementing Methods + +`Keeper`s primarily expose getter and setter methods for the store(s) managed by their module. These methods should remain as simple as possible and strictly be limited to getting or setting the requested value, as validity checks should have already been performed via the `ValidateBasic()` method of the [`message`](./messages-and-queries.md#messages) and the [`Msg` server](./msg-services.md) when `keeper`s' methods are called. + +Typically, a *getter* method will have the following signature + +```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 preferred to use the `prefix.Store` to access only the desired limited subset of the store for convenience and safety. +2. If it exists, get the `[]byte` value stored at location `[]byte(key)` using the `Get(key []byte)` method of the store. +3. Unmarshall the retrieved value from `[]byte` to `returnType` using the codec `cdc`. Return the value. + +Similarly, a *setter* method will have the following signature + +```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. + +For more, see an example of `keeper`'s [methods implementation from the `staking` module](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/staking/keeper/keeper.go). + +The [module `KVStore`](../core/store.md#kvstore-and-commitkvstore-interfaces) also provides an `Iterator()` method which returns an `Iterator` object to iterate over a domain of keys. + +This is an example from the `auth` module to iterate accounts: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/keeper/account.go#L76-L90 + +## Next {hide} + +Learn about [invariants](./invariants.md) {hide} diff --git a/versioned_docs/version-0.46/integrate/building-modules/messages-and-queries.md b/versioned_docs/version-0.46/integrate/building-modules/messages-and-queries.md new file mode 100644 index 000000000..6e075bf42 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/building-modules/messages-and-queries.md @@ -0,0 +1,115 @@ + + +# Messages and Queries + +`Msg`s and `Queries` are the two primary objects handled by modules. Most of the core components defined in a module, like `Msg` services, `keeper`s and `Query` services, exist to process `message`s and `queries`. {synopsis} + +## Pre-requisite Readings + +* [Introduction to Cosmos SDK Modules](./intro.md) {prereq} + +## Messages + +`Msg`s are objects whose end-goal is to trigger state-transitions. They are wrapped in [transactions](../core/transactions.md), which may contain one or more of them. + +When a transaction is relayed from the underlying consensus engine to the 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). + +### `Msg` Services + +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. + +See an example of a `Msg` service definition from `x/bank` module: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/bank/v1beta1/tx.proto#L12-L19 + +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: + +```protobuf + 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. + +The Cosmos SDK uses Protobuf definitions to generate client and server code: + +* `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. + +A `RegisterMsgServer` method is also generated and should be used to register the module's `MsgServer` implementation in `RegisterServices` method from the [`AppModule` interface](./module-manager.md#appmodule). + +In order for clients (CLI and grpc-gateway) to have these URLs registered, the 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. + +### Legacy Amino `LegacyMsg`s + +The following way of defining messages is deprecated and using [`Msg` services](#msg-services) is preferred. + +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. + +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: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/tx_msg.go#L10-L22 + +It extends `proto.Message` and contains the following methods: + +* `Route() string`: Name of the route for this message. Typically all `message`s in a module have the same route, which is most often the module's name. +* `Type() string`: Type of the message, used primarily in [events](../core/events.md). This should return a message-specific `string`, typically the denomination of the message itself. +* [`ValidateBasic() error`](../basics/tx-lifecycle.md#ValidateBasic). +* `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. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/migrations/legacytx/stdsign.go#L20-L36 + +See an example implementation of a `message` from the `gov` module: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/gov/types/v1/msgs.go#L106-L138 + +## 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). + +### gRPC Queries + +Queries should be defined using [Protobuf services](https://developers.google.com/protocol-buffers/docs/proto#services). A `Query` service should be created per module in `query.proto`. This service lists endpoints starting with `rpc`. + +Here's an example of such a `Query` service definition: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/auth/v1beta1/query.proto#L13-L59 + +As `proto.Message`s, generated `Response` types implement by default `String()` method of [`fmt.Stringer`](https://pkg.go.dev/fmt#Stringer). + +A `RegisterQueryServer` method is also generated and should be used to register the module's query server in the `RegisterServices` method from the [`AppModule` interface](./module-manager.md#appmodule). + +### Legacy Queries + +Before the introduction of Protobuf and gRPC in the 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 to process it. For most module queries, the `path` should look like the following: + +```text +queryCategory/queryRoute/queryType/arg1/arg2/... +``` + +where: + +* `queryCategory` is the category of the `query`, typically `custom` for module queries. It is used to differentiate between different kinds of queries within `BaseApp`'s [`Query` method](../core/baseapp.md#query). +* `queryRoute` is used by `BaseApp`'s [`queryRouter`](../core/baseapp.md#query-routing) to map the `query` to its module. Usually, `queryRoute` should be the name of the module. +* `queryType` is used by the module's [`querier`](./query-services.md#legacy-queriers) to map the `query` to the appropriate `querier function` within the module. +* `args` are the actual arguments needed to process the `query`. They are filled out by the end-user. Note that for bigger queries, you might prefer passing arguments in the `Data` field of the request `req` instead of the `path`. + +The `path` for each `query` must be defined by the module developer in the module's [command-line interface file](./module-interfaces.md#query-commands).Overall, there are 3 mains components module developers need to implement in order to make the subset of the state defined by their module queryable: + +* A [`querier`](./query-services.md#legacy-queriers), to process the `query` once it has been [routed to the module](../core/baseapp.md#query-routing). +* [Query commands](./module-interfaces.md#query-commands) in the module's CLI file, where the `path` for each `query` is specified. +* `query` return types. Typically defined in a file `types/querier.go`, they specify the result type of each of the module's `queries`. These custom types must implement the `String()` method of [`fmt.Stringer`](https://pkg.go.dev/fmt#Stringer). + +### Store Queries + +Store queries query directly for store keys. They use `clientCtx.QueryABCI(req abci.RequestQuery)` to return the full `abci.ResponseQuery` with inclusion Merkle proofs. + +See following examples: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/baseapp/abci.go#L756-L777 + +## Next {hide} + +Learn about [`Msg` services](./msg-services.md) {hide} diff --git a/versioned_docs/version-0.46/integrate/building-modules/module-interfaces.md b/versioned_docs/version-0.46/integrate/building-modules/module-interfaces.md new file mode 100644 index 000000000..91dca7a53 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/building-modules/module-interfaces.md @@ -0,0 +1,139 @@ + + +# Module Interfaces + +This document details how to build CLI and REST interfaces for a module. Examples from various Cosmos SDK modules are included. {synopsis} + +## Prerequisite Readings + +* [Building Modules Intro](./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. + +### 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. + +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. + +Here is an example from the `x/bank` module: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/bank/client/cli/tx.go#L35-L71 + +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. + +In general, the getter function does the following: + +* **Constructs the command:** Read the [Cobra Documentation](https://pkg.go.dev/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()`](../basics/tx-lifecycle.md#ValidateBasic) and other validation methods before broadcasting the message. + * 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: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/bank/client/cli/tx.go#L17-L33 + +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: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/bank/module.go#L70-L73 + +### 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: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/client/cli/query.go#L83-L125 + +In the example, `GetAccountCmd()` creates and returns a query command that returns the state of an account based on the provided account address. + +In general, the getter function does the following: + +* **Constructs the command:** Read the [Cobra Documentation](https://pkg.go.dev/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. + +Each module must implement `GetQueryCmd()`, which aggregates all of the query commands of the module. Here is an example from the `x/auth` module: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/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: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/client/cli/query.go#L32-L50 + +### 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 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. + +Here is an example that adds the `--from` flag to a command: + +```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. + +Here is an example that marks the `--from` flag as _required_: + +```go +cmd.MarkFlagRequired(FlagFrom) +``` + +For more detailed information on creating flags, visit the [Cobra Documentation](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. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/client/flags/flags.go#L103-L131 + +Since `AddTxFlagsToCmd(cmd *cobra.Command)` includes all of the basic flags required for a transaction command, module developers may choose not to add any of their own (specifying arguments instead may often be more appropriate). + +Similarly, there is a `AddQueryFlagsToCmd(cmd *cobra.Command)` to add common flags to a module query command. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/client/flags/flags.go#L92-L101 + +## 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. + +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. + +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. + +Here's an example from the `x/auth` module: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/module.go#L61-L66 + +## gRPC-gateway REST + +Applications need to support web services that use HTTP requests (e.g. a web wallet like [Keplr](https://keplr.app)). [grpc-gateway](https://github.com/grpc-ecosystem/grpc-gateway) translates REST calls into gRPC calls, which might be useful for clients that do not use gRPC. + +Modules that want to expose REST queries should add `google.api.http` annotations to their `rpc` methods, such as in the example below from the `x/auth` module: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/auth/v1beta1/query.proto#L13-L59 + +gRPC gateway is started in-process along with the application and Tendermint. It can be enabled or disabled by setting gRPC Configuration `enable` in [`app.toml`](../run-node/run-node.md#configuring-the-node-using-apptoml). + +The 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. + +## Next {hide} + +Read about the recommended [module structure](./structure.md) {hide} diff --git a/versioned_docs/version-0.46/integrate/building-modules/module-manager.md b/versioned_docs/version-0.46/integrate/building-modules/module-manager.md new file mode 100644 index 000000000..edcab0388 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/building-modules/module-manager.md @@ -0,0 +1,151 @@ + + +# Module Manager + +Cosmos SDK modules need to implement the [`AppModule` interfaces](#application-module-interfaces), in order to be managed by the application's [module manager](#module-manager). The module manager plays an important role in [`message` and `query` routing](../core/baseapp.md#routing), and allows application developers to set the order of execution of a variety of functions like [`BeginBlocker` and `EndBlocker`](../basics/app-anatomy.md#begingblocker-and-endblocker). {synopsis} + +## Pre-requisite Readings + +* [Introduction to Cosmos SDK Modules](./intro.md) + +## 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: + +* [`AppModuleBasic`](#appmodulebasic) for independent module functionalities. +* [`AppModule`](#appmodule) for inter-dependent module functionalities (except genesis-related functionalities). +* [`AppModuleGenesis`](#appmodulegenesis) for inter-dependent genesis-related module functionalities. + +The `AppModuleBasic` interface exists to define independent methods of the module, i.e. those that do not depend on other modules in the application. This allows for the construction of the basic application structure early in the application definition, generally in the `init()` function of the [main application file](../basics/app-anatomy.md#core-application-file). + +The `AppModule` interface exists to define inter-dependent module methods. Many modules need to 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. + +Lastly the interface for genesis functionality `AppModuleGenesis` is separated out from full module functionality `AppModule` so that modules which +are only used for genesis can take advantage of the `Module` patterns without having to define many placeholder functions. + +### `AppModuleBasic` + +The `AppModuleBasic` interface defines the independent methods modules need to implement. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/module/module.go#L47-L60 + +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. +* `RegisterGRPCGatewayRoutes(client.Context, *runtime.ServeMux)`: Registers gRPC routes for the module. +* `GetTxCmd()`: Returns the root [`Tx` command](./module-interfaces.md#tx) for the module. The subcommands of this root command are used by end-users to generate new transactions containing [`message`s](./messages-and-queries.md#queries) defined in the module. +* `GetQueryCmd()`: Return the root [`query` command](./module-interfaces.md#query) for the module. The subcommands of this root command are used by end-users to generate new queries to the subset of the state defined by the module. + +All the `AppModuleBasic` of an application are managed by the [`BasicManager`](#basicmanager). + +### `AppModuleGenesis` + +The `AppModuleGenesis` interface is a simple embedding of the `AppModuleBasic` interface with two added methods. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/module/module.go#L140-L146 + +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. + +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` + +The `AppModule` interface defines the inter-dependent methods that modules need to implement. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/module/module.go#L148-L176 + +`AppModule`s are managed by the [module manager](#manager). This interface embeds the `AppModuleGenesis` interface so that the manager can access all the independent and genesis inter-dependent methods of the module. This means that a concrete type implementing the `AppModule` interface must either implement all the methods of `AppModuleGenesis` (and by extension `AppModuleBasic`), or include a concrete type that does as parameter. + +Let us go through the methods of `AppModule`: + +* `RegisterInvariants(sdk.InvariantRegistry)`: Registers the [`invariants`](./invariants.md) of the module. If an invariant deviates from its predicted value, the [`InvariantRegistry`](./invariants.md#registry) triggers appropriate logic (most often the chain will be halted). +* `Route()` (deprecated): Returns the route for [`message`s](./messages-and-queries.md#messages) to be routed to the module by [`BaseApp`](../core/baseapp.md#message-routing). +* `QuerierRoute()` (deprecated): Returns the name of the module's query route, for [`queries`](./messages-and-queries.md#queries) to be routes to the module by [`BaseApp`](../core/baseapp.md#query-routing). +* `LegacyQuerierHandler(*codec.LegacyAmino)` (deprecated): Returns a [`querier`](./query-services.md#legacy-queriers) given the query `path`, in order to process the `query`. +* `RegisterServices(Configurator)`: Allows a module to register services. +* `BeginBlock(sdk.Context, abci.RequestBeginBlock)`: This method gives module developers the option to implement logic that is automatically triggered at the beginning of each block. Implement empty if no logic needs to be triggered at the beginning of each block for this module. +* `EndBlock(sdk.Context, abci.RequestEndBlock)`: This method gives module developers the option to implement logic that is automatically triggered at the end of each block. This is also where the module can inform the underlying consensus engine of validator set changes (e.g. the `staking` module). Implement empty if no logic needs to be triggered at the end of each block for this module. + +### Implementing the Application Module Interfaces + +Typically, the various application module interfaces are implemented in a file called `module.go`, located in the module's folder (e.g. `./x/module/module.go`). + +Almost every module needs to implement the `AppModuleBasic` and `AppModule` interfaces. If the module is only used for genesis, it will implement `AppModuleGenesis` instead of `AppModule`. The concrete type that implements the interface can add parameters that are required for the implementation of the various methods of the interface. For example, the `Route()` function often calls a `NewMsgServerImpl(k keeper)` function defined in `keeper/msg_server.go` and therefore needs to pass the module's [`keeper`](./keeper.md) as a parameter. + +```go +// example +type AppModule struct { + AppModuleBasic + keeper Keeper +} +``` + +In the example above, you can see that the `AppModule` concrete type references an `AppModuleBasic`, and not an `AppModuleGenesis`. That is because `AppModuleGenesis` only needs to be implemented in modules that focus on genesis-related functionalities. In most modules, the concrete `AppModule` type will have a reference to an `AppModuleBasic` and implement the two added methods of `AppModuleGenesis` directly in the `AppModule` type. + +If no parameter is required (which is often the case for `AppModuleBasic`), just declare an empty concrete type like so: + +```go +type AppModuleBasic struct{} +``` + +## Module Managers + +Module managers are used to manage collections of `AppModuleBasic` and `AppModule`. + +### `BasicManager` + +The `BasicManager` is a structure that lists all the `AppModuleBasic` of an application: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/module/module.go#L62-L72 + +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/main/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. +* `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). + +### `Manager` + +The `Manager` is a structure that holds all the `AppModule` of an application, and defines the order of execution between several key components of these modules: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/module/module.go#L216-L225 + +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). + + To initialize modules successfully, module dependencies should be considered. For example, the `genutil` module must occur after `staking` module so that the pools are properly initialized with tokens from genesis accounts, the `genutils` module must also occur after `auth` so that it can access the params from auth, `capability` module should be initialized before all other modules so that it can initialize any capabilities. +* `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). +* `SetOrderMigrations(moduleNames ...string)`: Sets the order of migrations to be run. If not set then migrations will be run with an order defined in `DefaultMigrationsOrder`. +* `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). + +Here's an example of a concrete integration within an application: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/simapp/app.go#L342-L409 + +## Next {hide} + +Learn more about [`message`s and `queries`](./messages-and-queries.md) {hide} diff --git a/versioned_docs/version-0.46/integrate/building-modules/msg-services.md b/versioned_docs/version-0.46/integrate/building-modules/msg-services.md new file mode 100644 index 000000000..164160ef5 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/building-modules/msg-services.md @@ -0,0 +1,100 @@ + + +# `Msg` Services + +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} + +## Pre-requisite Readings + +* [Module Manager](./module-manager.md) {prereq} +* [Messages and Queries](./messages-and-queries.md) {prereq} + +## Implementation of a module `Msg` service + +Each module should define a Protobuf `Msg` service, which will be responsible for processing requests (implementing `sdk.Msg`) and returning responses. + +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. + +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: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/bank/types/tx.pb.go#L288-L294 + +When possible, the existing module's [`Keeper`](keeper.md) should implement `MsgServer`, otherwise a `msgServer` struct that embeds the `Keeper` can be created, typically in `./keeper/msg_server.go`: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/bank/keeper/msg_server.go#L14-L16 + +`msgServer` methods can retrieve the `sdk.Context` from the `context.Context` parameter method using the `sdk.UnwrapSDKContext`: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/bank/keeper/msg_server.go#L27-L27 + +`sdk.Msg` processing usually follows these 3 steps: + +### Validation + +Before a `msgServer` method is executed, the message's [`ValidateBasic()`](../basics/tx-lifecycle.md#ValidateBasic) method has already been called. Since `msg.ValidateBasic()` performs only the most basic checks, this stage must perform all other validation (both *stateful* and *stateless*) to make sure the `message` is valid. Checks performed in the `msgServer` method can be more expensive and the signer is charged gas for these operations. +For example, a `msgServer` method for a `transfer` message might check that the sending account has enough funds to actually perform the transfer. + +It is recommended to implement all validation checks in a separate function that passes state values as arguments. This implementation simplifies testing. As expected, expensive validation functions charge additional gas. Example: + +```go +ValidateMsgA(msg MsgA, now Time, gm GasMeter) error { + if now.Before(msg.Expire) { + return sdkerrrors.ErrInvalidRequest.Wrap("msg expired") + } + gm.ConsumeGas(1000, "signature verification") + return signatureVerificaton(msg.Prover, msg.Data) +} +``` + +### State Transition + +After the validation is successful, the `msgServer` method uses the [`keeper`](./keeper.md) functions to access the state and perform a state transition. + +### Events + +Before returning, `msgServer` methods generally emit one or more [events](../core/events.md) by using the `EventManager` held in the `ctx`. Use the new `EmitTypedEvent` function that uses protobuf-based event types: + +```go +ctx.EventManager().EmitTypedEvent( + &group.EventABC{Key1: Value1, Key2, Value2}) +``` + +or the older `EmitEvent` function: + +```go +ctx.EventManager().EmitEvent( + sdk.NewEvent( + eventType, // e.g. sdk.EventTypeMessage for a message, types.CustomEventType for a custom event defined in the module + sdk.NewAttribute(key1, value1), + sdk.NewAttribute(key2, value2), + ), +) +``` + +These events are relayed back to the underlying consensus engine and can be used by service providers to implement services around the application. Click [here](../core/events.md) to learn more about events. + +The invoked `msgServer` method returns a `proto.Message` response and an `error`. These return values are then wrapped into an `*sdk.Result` or an `error` using `sdk.WrapServiceResult(ctx sdk.Context, res proto.Message, err error)`: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/baseapp/msg_service_router.go#L127 + +This method takes care of marshaling the `res` parameter to protobuf and attaching any events on the `ctx.EventManager()` to the `sdk.Result`. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/base/abci/v1beta1/abci.proto#L88-L109 + +This diagram shows a typical structure of a Protobuf `Msg` service, and how the message propagates through the module. + +![Transaction flow](./transaction_flow.svg) + +## Telemetry + +New [telemetry metrics](../core/telemetry.md) can be created from `msgServer` methods when handling messages. + +This is an example from the `x/auth/vesting` module: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/vesting/msg_server.go#L73-L85 + +## Next {hide} + +Learn about [query services](./query-services.md) {hide} diff --git a/versioned_docs/version-0.46/integrate/building-modules/query-services.md b/versioned_docs/version-0.46/integrate/building-modules/query-services.md new file mode 100644 index 000000000..4618480a6 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/building-modules/query-services.md @@ -0,0 +1,77 @@ + + +# 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} + +## Pre-requisite Readings + +* [Module Manager](./module-manager.md) {prereq} +* [Messages and Queries](./messages-and-queries.md) {prereq} + +## `Querier` type + +The `querier` type defined in the Cosmos SDK will be deprecated in favor of [gRPC Services](#grpc-service). It specifies the typical structure of a `querier` function: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/queryable.go#L9 + +Let us break it down: + +* 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 `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 result in `[]byte` returned to `BaseApp`, marshalled using the application's [`codec`](../core/encoding.md). + +## Implementation of a module query service + +### gRPC Service + +When defining a Protobuf `Query` service, a `QueryServer` interface is generated for each module with all the service methods: + +```go +type QueryServer interface { + QueryBalance(context.Context, *QueryBalanceParams) (*types.Coin, error) + QueryAllBalances(context.Context, *QueryAllBalancesParams) (*QueryAllBalancesResponse, error) +} +``` + +These custom queries methods should be implemented by a module's keeper, typically in `./keeper/grpc_query.go`. The first parameter of these methods is a generic `context.Context`, whereas querier methods generally need an instance of `sdk.Context` to read +from the store. Therefore, the Cosmos SDK provides a function `sdk.UnwrapSDKContext` to retrieve the `sdk.Context` from the provided +`context.Context`. + +Here's an example implementation for the bank module: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/bank/keeper/grpc_query.go + +### Legacy Queriers + +Module legacy `querier`s are typically implemented in a `./keeper/querier.go` file inside the module's folder. The [module manager](./module-manager.md) is used to add the module's `querier`s to the [application's `queryRouter`](../core/baseapp.md#query-routing) via the `NewQuerier()` method. Typically, the manager's `NewQuerier()` method simply calls a `NewQuerier()` method defined in `keeper/querier.go`, which looks like the following: + +```go +func NewQuerier(keeper Keeper) sdk.Querier { + return func(ctx sdk.Context, path []string, req abci.RequestQuery) ([]byte, error) { + switch path[0] { + case QueryType1: + return queryType1(ctx, path[1:], req, keeper) + + case QueryType2: + return queryType2(ctx, path[1:], req, keeper) + + default: + return nil, sdkerrors.Wrapf(sdkerrors.ErrUnknownRequest, "unknown %s query endpoint: %s", types.ModuleName, path[0]) + } + } +} +``` + +This simple switch returns a `querier` function specific to the type of the received `query`. At this point of the [query lifecycle](../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. + +The `querier` functions themselves are pretty straightforward. They generally fetch a value or values from the state using the [`keeper`](./keeper.md). Then, they marshall the value(s) using the [`codec`](../core/encoding.md) and return the `[]byte` obtained as result. + +For a deeper look at `querier`s, see this [example implementation of a `querier` function](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/gov/keeper/querier.go) from the bank module. + +## Next {hide} + +Learn about [`BeginBlocker` and `EndBlocker`](./beginblock-endblock.md) {hide} diff --git a/versioned_docs/version-0.46/integrate/building-modules/simulator.md b/versioned_docs/version-0.46/integrate/building-modules/simulator.md new file mode 100644 index 000000000..4c2196dad --- /dev/null +++ b/versioned_docs/version-0.46/integrate/building-modules/simulator.md @@ -0,0 +1,122 @@ +# Module Simulation + +## Prerequisites + +* [Cosmos Blockchain Simulator](./../using-the-sdk/simulation.md) + +## Synopsis + +This document details how to define each module simulation functions to be +integrated with the application `SimulationManager`. + +* [Simulation package](#simulation-package) + * [Store decoders](#store-decoders) + * [Randomized genesis](#randomized-genesis) + * [Randomized parameter changes](#randomized-parameter-changes) + * [Random weighted operations](#random-weighted-operations) + * [Random proposal contents](#random-proposal-contents) +* [Registering simulation functions](#registering-simulation-functions) +* [App Simulator manager](#app-simulator-manager) + +## 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. + +### Store decoders + +Registering the store decoders is required for the `AppImportExport`. This allows +for the key-value pairs from the stores to be decoded (_i.e_ unmarshalled) +to their corresponding types. In particular, it matches the key to a concrete type +and then unmarshals the value from the `KVPair` to the type provided. + +You can use the example [here](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/distribution/simulation/decoder.go) from the distribution module to implement your store decoders. + +### Randomized genesis + +The simulator tests different scenarios and values for genesis parameters +in order to fully test the edge cases of specific modules. The `simulator` package from each module must expose a `RandomizedGenState` function to generate the initial random `GenesisState` from a given seed. + +Once the module genesis parameter are generated randomly (or with the key and +values defined in a `params` file), they are marshaled to JSON format and added +to the app genesis JSON to use it on the simulations. + +You can check an example on how to create the randomized genesis [here](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/staking/simulation/genesis.go). + +### Randomized parameter changes + +The simulator is able to test parameter changes at random. The simulator package from each module must contain a `RandomizedParams` func that will simulate parameter changes of the module throughout the simulations lifespan. + +You can see how an example of what is needed to fully test parameter changes [here](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/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. + +Operations on the simulation are simulated using the full [transaction cycle](../core/transactions.md) of a +`ABCI` application that exposes the `BaseApp`. + +Shown below is how weights are set: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/staking/simulation/operations.go#L17-L75 + +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. + +Here is how one can override the above package `simappparams`. + ++++ https://github.com/cosmos/gaia/blob/main/sims.mk#L9-L22 + +For the last test a tool called runsim is used, this is used to parallelize go test instances, provide info to Github and slack integrations to provide information to your team on how the simulations are running. + +### Random proposal contents + +Randomized governance proposals are also supported on the Cosmos SDK simulator. Each +module must define the governance proposal `Content`s that they expose and register +them to be used on the parameters. + +## Registering simulation functions + +Now that all the required functions are defined, we need to integrate them into the module pattern within the `module.go`: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/distribution/module.go + +## App Simulator manager + +The following step is setting up the `SimulatorManager` at the app level. This +is required for the simulation test files on the next step. + +```go +type CustomApp struct { + ... + sm *module.SimulationManager +} +``` + +Then at the instantiation of the application, we create the `SimulationManager` +instance in the same way we create the `ModuleManager` but this time we only pass +the modules that implement the simulation functions from the `AppModuleSimulation` +interface described above. + +```go +func NewCustomApp(...) { + // create the simulation manager and define the order of the modules for deterministic simulations + app.sm = module.NewSimulationManager( + auth.NewAppModule(app.accountKeeper), + bank.NewAppModule(app.bankKeeper, app.accountKeeper), + supply.NewAppModule(app.supplyKeeper, app.accountKeeper), + ov.NewAppModule(app.govKeeper, app.accountKeeper, app.supplyKeeper), + mint.NewAppModule(app.mintKeeper), + distr.NewAppModule(app.distrKeeper, app.accountKeeper, app.supplyKeeper, app.stakingKeeper), + staking.NewAppModule(app.stakingKeeper, app.accountKeeper, app.supplyKeeper), + slashing.NewAppModule(app.slashingKeeper, app.accountKeeper, app.stakingKeeper), + ) + + // register the store decoders for simulation tests + app.sm.RegisterStoreDecoders() + ... +} +``` diff --git a/versioned_docs/version-0.46/integrate/building-modules/11-structure.md b/versioned_docs/version-0.46/integrate/building-modules/structure.md similarity index 83% rename from versioned_docs/version-0.46/integrate/building-modules/11-structure.md rename to versioned_docs/version-0.46/integrate/building-modules/structure.md index 3520dfa48..70885833f 100644 --- a/versioned_docs/version-0.46/integrate/building-modules/11-structure.md +++ b/versioned_docs/version-0.46/integrate/building-modules/structure.md @@ -1,12 +1,10 @@ ---- -sidebar_position: 1 ---- + # Recommended Folder Structure -:::note Synopsis -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. -::: +This document outlines the recommended structure of Cosmos SDK modules. These ideas are meant to be applied as suggestions. Application developers are encouraged to improve upon and contribute to module structure and development design. {synopsis} ## Structure @@ -52,13 +50,18 @@ x/{module_name} │   └── querier.go ├── module │   └── module.go -│   └── abci.go ├── simulation │   ├── decoder.go │   ├── genesis.go │   ├── operations.go │   └── params.go +├── spec +│   ├── 01_concepts.md +│   ├── 02_state.md +│   ├── 03_messages.md +│   └── 04_events.md ├── {module_name}.pb.go +├── abci.go ├── codec.go ├── errors.go ├── events.go @@ -70,24 +73,27 @@ x/{module_name} ├── msgs.go ├── params.go ├── query.pb.go -├── tx.pb.go -└── 05-depinject.md +└── tx.pb.go ``` -* `client/`: The module's CLI client functionality implementation and the module's CLI testing suite. +* `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. - * `abci.go`: The module's `BeginBlocker` and `EndBlocker` implementations (this file is only required if `BeginBlocker` and/or `EndBlocker` need to be defined). -* `simulation/`: The module's [simulation](14-simulator.md) package defines functions used by the blockchain simulator application (`simapp`). -* `REAMDE.md`: The module's specification documents outlining important concepts, state storage structure, and message and event type definitions. Learn more how to write module specs in the [spec guidelines](../spec/SPEC_MODULE.md). +* `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](06-keeper.md#type-definition) interfaces. + * `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). + +## Next {hide} + +Learn about [Errors](./errors.md) {hide} diff --git a/versioned_docs/version-0.46/integrate/building-modules/transaction_flow.svg b/versioned_docs/version-0.46/integrate/building-modules/transaction_flow.svg new file mode 100644 index 000000000..1ae962de3 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/building-modules/transaction_flow.svg @@ -0,0 +1,48 @@ +UserUserbaseAppbaseApprouterrouterhandlerhandlermsgServermsgServerkeeperkeeperContext.EventManagerContext.EventManagerTransaction Type<Tx>Route(ctx, msgRoute)handlerMsg<Tx>(Context, Msg(...))<Tx>(Context, Msg)alt[addresses invalid, denominations wrong, etc.]errorperform action, update contextresults, error codeEmit relevant eventsmaybe wrap results in more structureresult, error coderesults, error code \ No newline at end of file diff --git a/versioned_docs/version-0.46/integrate/building-modules/upgrade.md b/versioned_docs/version-0.46/integrate/building-modules/upgrade.md new file mode 100644 index 000000000..863066ca7 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/building-modules/upgrade.md @@ -0,0 +1,57 @@ + + +# Upgrading Modules + +[In-Place Store Migrations](../core/upgrade.md) 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} + +## Prerequisite Readings + +* [In-Place Store Migration](../core/upgrade.md) {prereq} + +## Consensus Version + +Successful upgrades of existing modules require each `AppModule` to implement the function `ConsensusVersion() uint64`. + +* The versions must be hard-coded by the module developer. +* The initial version **must** be set to 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. + +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: + +```golang +func (am AppModule) RegisterServices(cfg module.Configurator) { + // --snip-- + cfg.RegisterMigration(types.ModuleName, 1, func(ctx sdk.Context) error { + // 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. + }) +} +``` + +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: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/bank/keeper/migrations.go#L9-L27 + +## 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`: + +```golang +// Migrating bank module 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`. +} +``` + +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/v0.46.0-rc1/x/bank/migrations/v043/store.go#L50-L71). 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). diff --git a/versioned_docs/version-0.46/integrate/ibc/README.md b/versioned_docs/version-0.46/integrate/ibc/README.md new file mode 100644 index 000000000..872e5c0dc --- /dev/null +++ b/versioned_docs/version-0.46/integrate/ibc/README.md @@ -0,0 +1,9 @@ + + +# IBC + +See the official [`ibc-go` documentation](https://ibc.cosmos.network). diff --git a/versioned_docs/version-0.46/integrate/migrations/README.md b/versioned_docs/version-0.46/integrate/migrations/README.md new file mode 100644 index 000000000..b5e08ec46 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/migrations/README.md @@ -0,0 +1,13 @@ + + +# Migrations + +This document contains all the migration guides to update your app and modules to the current Cosmos SDK. + +1. Chain Upgrade Guide to v0.46: + * See [UPGRADING.md (TODO)](https://github.com/cosmos/cosmos-sdk/blob/main/UPGRADING.md) for breaking changes and deprecations upgrade instructions. + * See [Release Notes](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/RELEASE_NOTES.md) and [changelog](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/CHANGELOG.md) for the exhaustive list of API and State Machine breaking changes. diff --git a/versioned_docs/version-0.46/integrate/migrations/pre-upgrade.md b/versioned_docs/version-0.46/integrate/migrations/pre-upgrade.md new file mode 100644 index 000000000..00b4c54e2 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/migrations/pre-upgrade.md @@ -0,0 +1,55 @@ +# 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. + +Using Cosmovisor pre-upgrade handling is optional. If pre-upgrade handling is not implemented, the upgrade continues. + +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. + +Before the application binary is upgraded, Cosmovisor calls a `pre-upgrade` command that can be implemented by the application. + +The `pre-upgrade` command does not take in any command-line arguments and is expected to terminate with the following exit codes: + +| Exit status code | How it is handled in Cosmosvisor | +|------------------|---------------------------------------------------------------------------------------------------------------------| +| `0` | Assumes `pre-upgrade` command executed successfully and continues the upgrade. | +| `1` | Default exit code when `pre-upgrade` command has not been implemented. | +| `30` | `pre-upgrade` command was executed but failed. This fails the entire upgrade. | +| `31` | `pre-upgrade` command was executed but failed. But the command is retried until exit code `1` or `30` are returned. | + +## Sample + +Here is a sample structure of the `pre-upgrade` command: + +```go +func preUpgradeCommand() *cobra.Command { + cmd := &cobra.Command{ + Use: "pre-upgrade", + Short: "Pre-upgrade command", + Long: "Pre-upgrade command to implement custom pre-upgrade handling", + Run: func(cmd *cobra.Command, args []string) { + + err := HandlePreUpgrade() + + if err != nil { + os.Exit(30) + } + + os.Exit(0) + + }, + } + + return cmd +} +``` + +Ensure that the pre-upgrade command has been registered in the application: + +```go +rootCmd.AddCommand( + // .. + preUpgradeCommand(), + // .. + ) +``` diff --git a/versioned_docs/version-0.46/integrate/modules/auth/01_concepts.md b/versioned_docs/version-0.46/integrate/modules/auth/01_concepts.md new file mode 100644 index 000000000..e028ebe8e --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/auth/01_concepts.md @@ -0,0 +1,43 @@ + + +# Concepts + +**Note:** The auth module is different from the [authz module](../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. + +## 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: + +`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. + +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. + +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. diff --git a/versioned_docs/version-0.46/integrate/modules/auth/02_state.md b/versioned_docs/version-0.46/integrate/modules/auth/02_state.md new file mode 100644 index 000000000..560e93421 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/auth/02_state.md @@ -0,0 +1,73 @@ + + +# 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`. + +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)` + +### 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, +// a notion of account numbers for replay protection for previously pruned accounts, +// and a pubkey for authentication purposes. +// +// Many complex conditions can be used in the concrete struct which implements AccountI. +type AccountI interface { + proto.Message + + GetAddress() sdk.AccAddress + SetAddress(sdk.AccAddress) error // errors if already set. + + GetPubKey() crypto.PubKey // can return nil. + SetPubKey(crypto.PubKey) error + + GetAccountNumber() uint64 + SetAccountNumber(uint64) error + + GetSequence() uint64 + SetSequence(uint64) error + + // Ensure that account implements stringer + String() string +} +``` + +#### 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 +// for basic account functionality. Any custom account type should extend this +// type for additional functionality (e.g. vesting). +message BaseAccount { + string address = 1; + google.protobuf.Any pub_key = 2; + uint64 account_number = 3; + uint64 sequence = 4; +} +``` + +### Vesting Account + +See [Vesting](05_vesting.md). diff --git a/versioned_docs/version-0.46/integrate/modules/auth/03_antehandlers.md b/versioned_docs/version-0.46/integrate/modules/auth/03_antehandlers.md new file mode 100644 index 000000000..3227d8dff --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/auth/03_antehandlers.md @@ -0,0 +1,40 @@ + + +# 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/main/docs/architecture/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`. + +## Decorators + +The auth module provides `AnteDecorator`s that are recursively chained together into a single `AnteHandler` in the following order: + +* `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. + +* `RejectExtensionOptionsDecorator`: Rejects all extension options which can optionally be included in protobuf transactions. + +* `MempoolFeeDecorator`: Checks if the `tx` fee is above local mempool `minFee` parameter during `CheckTx`. + +* `ValidateBasicDecorator`: Calls `tx.ValidateBasic` and returns any non-nil error. + +* `TxTimeoutHeightDecorator`: Check for a `tx` height timeout. + +* `ValidateMemoDecorator`: Validates `tx` memo with application parameters and returns any non-nil error. + +* `ConsumeGasTxSizeDecorator`: Consumes gas proportional to the `tx` size based on application parameters. + +* `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. + +* `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. + +* `ValidateSigCountDecorator`: Validates the number of signatures in `tx` based on app-parameters. + +* `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`. + +* `SigVerificationDecorator`: Verifies all signatures are valid. This requires pubkeys to be set in context for all signers as part of `SetPubKeyDecorator`. + +* `IncrementSequenceDecorator`: Increments the account sequence for each signer to prevent replay attacks. diff --git a/versioned_docs/version-0.46/integrate/modules/auth/04_keepers.md b/versioned_docs/version-0.46/integrate/modules/auth/04_keepers.md new file mode 100644 index 000000000..268ced5c3 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/auth/04_keepers.md @@ -0,0 +1,47 @@ + + +# Keepers + +The auth module only exposes one keeper, the account keeper, which can be used to read and write accounts. + +## 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. +type AccountKeeperI interface { + // Return a new account with the next account number and the specified address. Does not save the new account to the store. + NewAccountWithAddress(sdk.Context, sdk.AccAddress) types.AccountI + + // Return a new account with the next account number. Does not save the new account to the store. + NewAccount(sdk.Context, types.AccountI) types.AccountI + + // Check if an account exists in the store. + HasAccount(sdk.Context, sdk.AccAddress) bool + + // Retrieve an account from the store. + GetAccount(sdk.Context, sdk.AccAddress) types.AccountI + + // Set an account in the store. + SetAccount(sdk.Context, types.AccountI) + + // Remove an account from the store. + RemoveAccount(sdk.Context, types.AccountI) + + // Iterate over all accounts, calling the provided function. Stop iteration when it returns true. + IterateAccounts(sdk.Context, func(types.AccountI) bool) + + // Fetch the public key of an account at a specified address + GetPubKey(sdk.Context, sdk.AccAddress) (crypto.PubKey, error) + + // Fetch the sequence of an account at a specified address. + GetSequence(sdk.Context, sdk.AccAddress) (uint64, error) + + // Fetch the next account number, and increment the internal counter. + GetNextAccountNumber(sdk.Context) uint64 +} +``` diff --git a/versioned_docs/version-0.46/integrate/modules/auth/05_vesting.md b/versioned_docs/version-0.46/integrate/modules/auth/05_vesting.md new file mode 100644 index 000000000..2108c658c --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/auth/05_vesting.md @@ -0,0 +1,630 @@ + + +# Vesting + +* [Vesting](#vesting) + * [Intro and Requirements](#intro-and-requirements) + * [Note](#note) + * [Vesting Account Types](#vesting-account-types) + * [BaseVestingAccount](#basevestingaccount) + * [ContinuousVestingAccount](#continuousvestingaccount) + * [DelayedVestingAccount](#delayedvestingaccount) + * [Period](#period) + * [PeriodicVestingAccount](#periodicvestingaccount) + * [PermanentLockedAccount](#permanentlockedaccount) + * [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) + * [Keepers & Handlers](#keepers--handlers) + * [Genesis Initialization](#genesis-initialization) + * [Examples](#examples) + * [Simple](#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 + +```go +// VestingAccount defines an interface that any vesting account type must +// implement. +type VestingAccount interface { + Account + + GetVestedCoins(Time) Coins + GetVestingCoins(Time) Coins + + // TrackDelegation performs internal vesting accounting necessary when + // delegating from a vesting account. It accepts the current block time, the + // delegation amount and balance of all coins whose denomination exists in + // the account's original vesting balance. + TrackDelegation(Time, Coins, Coins) + + // TrackUndelegation performs internal vesting accounting necessary when a + // vesting account performs an undelegation. + TrackUndelegation(Coins) + + GetStartTime() int64 + GetEndTime() int64 +} +``` + +### BaseVestingAccount + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/vesting/v1beta1/vesting.proto#L10-L24 + +### ContinuousVestingAccount + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/vesting/v1beta1/vesting.proto#L26-L34 + +### DelayedVestingAccount + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/vesting/v1beta1/vesting.proto#L36-L44 + +### Period + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/vesting/v1beta1/vesting.proto#L46-L53 + +```go +// Stores all vesting periods passed as part of a PeriodicVestingAccount +type Periods []Period + +``` + +### PeriodicVestingAccount + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/vesting/v1beta1/vesting.proto#L55-L64 + +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: + +```go +type ViewKeeper interface { + // ... + + // Calculates the total locked account balance. + LockedCoins(ctx sdk.Context, addr sdk.AccAddress) sdk.Coins + + // Calculates the total spendable balance that can be sent to other accounts. + SpendableCoins(ctx sdk.Context, addr sdk.AccAddress) sdk.Coins +} +``` + +### PermanentLockedAccount + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/vesting/v1beta1/vesting.proto#L55-L64 + +## 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. + +### 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`). + +#### Continuously Vesting Accounts + +To determine the amount of coins that are vested for a given block time `T`, the +following is performed: + +1. Compute `X := T - StartTime` +2. Compute `Y := EndTime - StartTime` +3. Compute `V' := OV * (X / Y)` +4. Compute `V := OV - V'` + +Thus, the total amount of _vested_ coins is `V'` and the remaining amount, `V`, +is _vesting_. + +```go +func (cva ContinuousVestingAccount) GetVestedCoins(t Time) Coins { + if t <= cva.StartTime { + // We must handle the case where the start time for a vesting account has + // been set into the future or when the start of the chain is not exactly + // known. + return ZeroCoins + } else if t >= cva.EndTime { + return cva.OriginalVesting + } + + x := t - cva.StartTime + y := cva.EndTime - cva.StartTime + + return cva.OriginalVesting * (x / y) +} + +func (cva ContinuousVestingAccount) GetVestingCoins(t Time) Coins { + return cva.OriginalVesting - cva.GetVestedCoins(t) +} +``` + +### 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`. + +1. Set `CT := StartTime` +2. Set `V' := 0` + +For each Period P: + + 1. Compute `X := T - CT` + 2. IF `X >= P.Length` + 1. Compute `V' += P.Amount` + 2. Compute `CT += P.Length` + 3. ELSE break + 3. Compute `V := OV - V'` + +```go +func (pva PeriodicVestingAccount) GetVestedCoins(t Time) Coins { + if t < pva.StartTime { + return ZeroCoins + } + ct := pva.StartTime // The start of the vesting schedule + vested := 0 + periods = pva.GetPeriods() + for _, period := range periods { + if t - ct < period.Length { + break + } + vested += period.Amount + ct += period.Length // increment ct to the start of the next vesting period + } + return vested +} + +func (pva PeriodicVestingAccount) GetVestingCoins(t Time) Coins { + return pva.OriginalVesting - cva.GetVestedCoins(t) +} +``` + +#### 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 { + if t >= dva.EndTime { + return dva.OriginalVesting + } + + return ZeroCoins +} + +func (dva DelayedVestingAccount) GetVestingCoins(t Time) Coins { + return dva.OriginalVesting - dva.GetVestedCoins(t) +} +``` + +### Transferring/Sending + +At any given time, a vesting account may transfer: `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. + +```go +func (va VestingAccount) LockedCoins(t Time) Coins { + return max(va.GetVestingCoins(t) - va.DelegatedVesting, 0) +} +``` + +The `x/bank` `ViewKeeper` can then provide APIs to determine locked and spendable +coins for any account: + +```go +func (k Keeper) LockedCoins(ctx Context, addr AccAddress) Coins { + acc := k.GetAccount(ctx, addr) + if acc != nil { + if acc.IsVesting() { + return acc.LockedCoins(ctx.BlockTime()) + } + } + + // non-vesting accounts do not have any locked coins + return NewCoins() +} +``` + +#### Keepers/Handlers + +The corresponding `x/bank` keeper should appropriately handle sending coins +based on if the account is a vesting account or not. + +```go +func (k Keeper) SendCoins(ctx Context, from Account, to Account, amount Coins) { + bc := k.GetBalances(ctx, from) + v := k.LockedCoins(ctx, from) + + spendable := bc - v + newCoins := spendable - amount + assert(newCoins >= 0) + + from.SetBalance(newCoins) + to.AddBalance(amount) + + // save balances... +} +``` + +### Delegating + +For a vesting account attempting to delegate `D` coins, the following is performed: + +1. Verify `BC >= D > 0` +2. Compute `X := min(max(V - DV, 0), D)` (portion of `D` that is vesting) +3. Compute `Y := D - X` (portion of `D` that is free) +4. Set `DV += X` +5. Set `DF += Y` + +```go +func (va VestingAccount) TrackDelegation(t Time, balance Coins, amount Coins) { + assert(balance <= amount) + x := min(max(va.GetVestingCoins(t) - va.DelegatedVesting, 0), amount) + y := amount - x + + va.DelegatedVesting += x + va.DelegatedFree += y +} +``` + +**Note** `TrackDelegation` only modifies the `DelegatedVesting` and `DelegatedFree` +fields, so upstream callers MUST modify the `Coins` field by subtracting `amount`. + +#### Keepers/Handlers + +```go +func DelegateCoins(t Time, from Account, amount Coins) { + if isVesting(from) { + from.TrackDelegation(t, amount) + } else { + from.SetBalance(sc - amount) + } + + // save account... +} +``` + +### 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. + +1. Verify `D > 0` +2. Compute `X := min(DF, D)` (portion of `D` that should become free, prioritizing free coins) +3. Compute `Y := min(DV, D - X)` (portion of `D` that should remain vesting) +4. Set `DF -= X` +5. Set `DV -= Y` + +```go +func (cva ContinuousVestingAccount) TrackUndelegation(amount Coins) { + x := min(cva.DelegatedFree, amount) + y := amount - x + + cva.DelegatedFree -= x + cva.DelegatedVesting -= y +} +``` + +**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. + +**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. + +#### Keepers/Handlers + +```go +func UndelegateCoins(to Account, amount Coins) { + if isVesting(to) { + if to.DelegatedFree + to.DelegatedVesting >= amount { + to.TrackUndelegation(amount) + // save account ... + } + } else { + AddBalance(to, amount) + // save account... + } +} +``` + +## 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. + +See the above specification for full implementation details. + +## 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. + +```go +type GenesisAccount struct { + // ... + + // vesting account fields + OriginalVesting sdk.Coins `json:"original_vesting"` + DelegatedFree sdk.Coins `json:"delegated_free"` + DelegatedVesting sdk.Coins `json:"delegated_vesting"` + StartTime int64 `json:"start_time"` + EndTime int64 `json:"end_time"` +} + +func ToAccount(gacc GenesisAccount) Account { + bacc := NewBaseAccount(gacc) + + if gacc.OriginalVesting > 0 { + if ga.StartTime != 0 && ga.EndTime != 0 { + // return a continuous vesting account + } else if ga.EndTime != 0 { + // return a delayed vesting account + } else { + // invalid genesis vesting account provided + panic() + } + } + + return bacc +} +``` + +## Examples + +### Simple + +Given a continuous vesting account with 10 vesting coins. + +```text +OV = 10 +DF = 0 +DV = 0 +BC = 10 +V = 10 +V' = 0 +``` + +1. Immediately receives 1 coin + + ```text + BC = 11 + ``` + +2. Time passes, 2 coins vest + + ```text + V = 8 + V' = 2 + ``` + +3. Delegates 4 coins to validator A + + ```text + DV = 4 + BC = 7 + ``` + +4. Sends 3 coins + + ```text + BC = 4 + ``` + +5. More time passes, 2 more coins vest + + ```text + V = 6 + V' = 4 + ``` + +6. Sends 2 coins. At this point the account cannot send anymore until further +coins vest or it receives additional coins. It can still however, delegate. + + ```text + BC = 2 + ``` + +### Slashing + +Same initial starting conditions as the simple example. + +1. Time passes, 5 coins vest + + ```text + V = 5 + V' = 5 + ``` + +2. Delegate 5 coins to validator A + + ```text + DV = 5 + BC = 5 + ``` + +3. Delegate 5 coins to validator B + + ```text + DF = 5 + BC = 0 + ``` + +4. Validator A gets slashed by 50%, making the delegation to A now worth 2.5 coins +5. Undelegate from validator A (2.5 coins) + + ```text + DF = 5 - 2.5 = 2.5 + BC = 0 + 2.5 = 2.5 + ``` + +6. Undelegate from validator B (5 coins). The account at this point can only +send 2.5 coins unless it receives more coins or until more coins vest. +It can still however, delegate. + + ```text + DV = 5 - 2.5 = 2.5 + DF = 2.5 - 2.5 = 0 + BC = 2.5 + 5 = 7.5 + ``` + + Notice how we have an excess amount of `DV`. + +### Periodic Vesting + +A vesting account is created where 100 tokens will be released over 1 year, with +1/4 of tokens vesting each quarter. The vesting schedule would be as follows: + +```yaml +Periods: +- amount: 25stake, length: 7884000 +- amount: 25stake, length: 7884000 +- amount: 25stake, length: 7884000 +- amount: 25stake, length: 7884000 +``` + +```text +OV = 100 +DF = 0 +DV = 0 +BC = 100 +V = 100 +V' = 0 +``` + +1. Immediately receives 1 coin + + ```text + BC = 101 + ``` + +2. Vesting period 1 passes, 25 coins vest + + ```text + V = 75 + V' = 25 + ``` + +3. During vesting period 2, 5 coins are transfered and 5 coins are delegated + + ```text + DV = 5 + BC = 91 + ``` + +4. Vesting period 2 passes, 25 coins vest + + ```text + V = 50 + V' = 50 + ``` + +## Glossary + +* OriginalVesting: The amount of coins (per denomination) that are initially +part of a vesting account. These coins are set at genesis. +* StartTime: The BFT time at which a vesting account starts to vest. +* EndTime: The BFT time at which a vesting account is fully vested. +* DelegatedFree: The tracked amount of coins (per denomination) that are +delegated from a vesting account that have been fully vested at time of delegation. +* DelegatedVesting: The tracked amount of coins (per denomination) that are +delegated from a vesting account that were vesting at time of delegation. +* ContinuousVestingAccount: A vesting account implementation that vests coins +linearly over time. +* DelayedVestingAccount: A vesting account implementation that only fully vests +all coins at a given time. +* PeriodicVestingAccount: A vesting account implementation that vests coins +according to a custom vesting schedule. +* PermanentLockedAccount: It does not ever release coins, locking them indefinitely. +Coins in this account can still be used for delegating and for governance votes even while locked. diff --git a/versioned_docs/version-0.46/integrate/modules/auth/06_params.md b/versioned_docs/version-0.46/integrate/modules/auth/06_params.md new file mode 100644 index 000000000..414e1888f --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/auth/06_params.md @@ -0,0 +1,15 @@ + + +# Parameters + +The auth module contains the following parameters: + +| Key | Type | Example | +| ---------------------- | --------------- | ------- | +| MaxMemoCharacters | uint64 | 256 | +| TxSigLimit | uint64 | 7 | +| TxSizeCostPerByte | uint64 | 10 | +| SigVerifyCostED25519 | uint64 | 590 | +| SigVerifyCostSecp256k1 | uint64 | 1000 | diff --git a/versioned_docs/version-0.46/integrate/modules/auth/07_client.md b/versioned_docs/version-0.46/integrate/modules/auth/07_client.md new file mode 100644 index 000000000..bcfdc6f6f --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/auth/07_client.md @@ -0,0 +1,421 @@ + + +# Client + +# Auth + +## CLI + +A user can query and interact with the `auth` module using the CLI. + +### Query + +The `query` commands allow users to query `auth` state. + +```bash +simd query auth --help +``` + +#### account + +The `account` command allow users to query for an account by it's address. + +```bash +simd query auth account [address] [flags] +``` + +Example: + +```bash +simd query auth account cosmos1... +``` + +Example Output: + +```bash +'@type': /cosmos.auth.v1beta1.BaseAccount +account_number: "0" +address: cosmos1zwg6tpl8aw4rawv8sgag9086lpw5hv33u5ctr2 +pub_key: + '@type': /cosmos.crypto.secp256k1.PubKey + key: ApDrE38zZdd7wLmFS9YmqO684y5DG6fjZ4rVeihF/AQD +sequence: "1" +``` + +#### accounts + +The `accounts` command allow users to query all the available accounts. + +```bash +simd query auth accounts [flags] +``` + +Example: + +```bash +simd query auth accounts +``` + +Example Output: + +```bash +accounts: +- '@type': /cosmos.auth.v1beta1.BaseAccount + account_number: "0" + address: cosmos1zwg6tpl8aw4rawv8sgag9086lpw5hv33u5ctr2 + pub_key: + '@type': /cosmos.crypto.secp256k1.PubKey + key: ApDrE38zZdd7wLmFS9YmqO684y5DG6fjZ4rVeihF/AQD + sequence: "1" +- '@type': /cosmos.auth.v1beta1.ModuleAccount + base_account: + account_number: "8" + address: cosmos1yl6hdjhmkf37639730gffanpzndzdpmhwlkfhr + pub_key: null + sequence: "0" + name: transfer + permissions: + - minter + - burner +- '@type': /cosmos.auth.v1beta1.ModuleAccount + base_account: + account_number: "4" + address: cosmos1fl48vsnmsdzcv85q5d2q4z5ajdha8yu34mf0eh + pub_key: null + sequence: "0" + name: bonded_tokens_pool + permissions: + - burner + - staking +- '@type': /cosmos.auth.v1beta1.ModuleAccount + base_account: + account_number: "5" + address: cosmos1tygms3xhhs3yv487phx3dw4a95jn7t7lpm470r + pub_key: null + sequence: "0" + name: not_bonded_tokens_pool + permissions: + - burner + - staking +- '@type': /cosmos.auth.v1beta1.ModuleAccount + base_account: + account_number: "6" + address: cosmos10d07y265gmmuvt4z0w9aw880jnsr700j6zn9kn + pub_key: null + sequence: "0" + name: gov + permissions: + - burner +- '@type': /cosmos.auth.v1beta1.ModuleAccount + base_account: + account_number: "3" + address: cosmos1jv65s3grqf6v6jl3dp4t6c9t9rk99cd88lyufl + pub_key: null + sequence: "0" + name: distribution + permissions: [] +- '@type': /cosmos.auth.v1beta1.BaseAccount + account_number: "1" + address: cosmos147k3r7v2tvwqhcmaxcfql7j8rmkrlsemxshd3j + pub_key: null + sequence: "0" +- '@type': /cosmos.auth.v1beta1.ModuleAccount + base_account: + account_number: "7" + address: cosmos1m3h30wlvsf8llruxtpukdvsy0km2kum8g38c8q + pub_key: null + sequence: "0" + name: mint + permissions: + - minter +- '@type': /cosmos.auth.v1beta1.ModuleAccount + base_account: + account_number: "2" + address: cosmos17xpfvakm2amg962yls6f84z3kell8c5lserqta + pub_key: null + sequence: "0" + name: fee_collector + permissions: [] +pagination: + next_key: null + total: "0" +``` + +#### params + +The `params` command allow users to query the current auth parameters. + +```bash +simd query auth params [flags] +``` + +Example: + +```bash +simd query auth params +``` + +Example Output: + +```bash +max_memo_characters: "256" +sig_verify_cost_ed25519: "590" +sig_verify_cost_secp256k1: "1000" +tx_sig_limit: "7" +tx_size_cost_per_byte: "10" +``` + +## gRPC + +A user can query the `auth` module using gRPC endpoints. + +### Account + +The `account` endpoint allow users to query for an account by it's address. + +```bash +cosmos.auth.v1beta1.Query/Account +``` + +Example: + +```bash +grpcurl -plaintext \ + -d '{"address":"cosmos1.."}' \ + localhost:9090 \ + cosmos.auth.v1beta1.Query/Account +``` + +Example Output: + +```bash +{ + "account":{ + "@type":"/cosmos.auth.v1beta1.BaseAccount", + "address":"cosmos1zwg6tpl8aw4rawv8sgag9086lpw5hv33u5ctr2", + "pubKey":{ + "@type":"/cosmos.crypto.secp256k1.PubKey", + "key":"ApDrE38zZdd7wLmFS9YmqO684y5DG6fjZ4rVeihF/AQD" + }, + "sequence":"1" + } +} +``` + +### Accounts + +The `accounts` endpoint allow users to query all the available accounts. + +```bash +cosmos.auth.v1beta1.Query/Accounts +``` + +Example: + +```bash +grpcurl -plaintext \ + localhost:9090 \ + cosmos.auth.v1beta1.Query/Accounts +``` + +Example Output: + +```bash +{ + "accounts":[ + { + "@type":"/cosmos.auth.v1beta1.BaseAccount", + "address":"cosmos1zwg6tpl8aw4rawv8sgag9086lpw5hv33u5ctr2", + "pubKey":{ + "@type":"/cosmos.crypto.secp256k1.PubKey", + "key":"ApDrE38zZdd7wLmFS9YmqO684y5DG6fjZ4rVeihF/AQD" + }, + "sequence":"1" + }, + { + "@type":"/cosmos.auth.v1beta1.ModuleAccount", + "baseAccount":{ + "address":"cosmos1yl6hdjhmkf37639730gffanpzndzdpmhwlkfhr", + "accountNumber":"8" + }, + "name":"transfer", + "permissions":[ + "minter", + "burner" + ] + }, + { + "@type":"/cosmos.auth.v1beta1.ModuleAccount", + "baseAccount":{ + "address":"cosmos1fl48vsnmsdzcv85q5d2q4z5ajdha8yu34mf0eh", + "accountNumber":"4" + }, + "name":"bonded_tokens_pool", + "permissions":[ + "burner", + "staking" + ] + }, + { + "@type":"/cosmos.auth.v1beta1.ModuleAccount", + "baseAccount":{ + "address":"cosmos1tygms3xhhs3yv487phx3dw4a95jn7t7lpm470r", + "accountNumber":"5" + }, + "name":"not_bonded_tokens_pool", + "permissions":[ + "burner", + "staking" + ] + }, + { + "@type":"/cosmos.auth.v1beta1.ModuleAccount", + "baseAccount":{ + "address":"cosmos10d07y265gmmuvt4z0w9aw880jnsr700j6zn9kn", + "accountNumber":"6" + }, + "name":"gov", + "permissions":[ + "burner" + ] + }, + { + "@type":"/cosmos.auth.v1beta1.ModuleAccount", + "baseAccount":{ + "address":"cosmos1jv65s3grqf6v6jl3dp4t6c9t9rk99cd88lyufl", + "accountNumber":"3" + }, + "name":"distribution" + }, + { + "@type":"/cosmos.auth.v1beta1.BaseAccount", + "accountNumber":"1", + "address":"cosmos147k3r7v2tvwqhcmaxcfql7j8rmkrlsemxshd3j" + }, + { + "@type":"/cosmos.auth.v1beta1.ModuleAccount", + "baseAccount":{ + "address":"cosmos1m3h30wlvsf8llruxtpukdvsy0km2kum8g38c8q", + "accountNumber":"7" + }, + "name":"mint", + "permissions":[ + "minter" + ] + }, + { + "@type":"/cosmos.auth.v1beta1.ModuleAccount", + "baseAccount":{ + "address":"cosmos17xpfvakm2amg962yls6f84z3kell8c5lserqta", + "accountNumber":"2" + }, + "name":"fee_collector" + } + ], + "pagination":{ + "total":"9" + } +} +``` + +### Params + +The `params` endpoint allow users to query the current auth parameters. + +```bash +cosmos.auth.v1beta1.Query/Params +``` + +Example: + +```bash +grpcurl -plaintext \ + localhost:9090 \ + cosmos.auth.v1beta1.Query/Params +``` + +Example Output: + +```bash +{ + "params": { + "maxMemoCharacters": "256", + "txSigLimit": "7", + "txSizeCostPerByte": "10", + "sigVerifyCostEd25519": "590", + "sigVerifyCostSecp256k1": "1000" + } +} +``` + +## REST + +A user can query the `auth` module using REST endpoints. + +### Account + +The `account` endpoint allow users to query for an account by it's address. + +```bash +/cosmos/auth/v1beta1/account?address={address} +``` + +### Accounts + +The `accounts` endpoint allow users to query all the available accounts. + +```bash +/cosmos/auth/v1beta1/accounts +``` + +### Params + +The `params` endpoint allow users to query the current auth parameters. + +```bash +/cosmos/auth/v1beta1/params +``` + +# Vesting + +## CLI + +A user can query and interact with the `vesting` module using the CLI. + +### Transactions + +The `tx` commands allow users to interact with the `vesting` module. + +```bash +simd tx vesting --help +``` + +#### create-periodic-vesting-account + +The `create-periodic-vesting-account` command creates a new vesting account funded with an allocation of tokens, where a sequence of coins and period length in seconds. Periods are sequential, in that the duration of of a period only starts at the end of the previous period. The duration of the first period starts upon account creation. + +```bash +simd tx vesting create-periodic-vesting-account [to_address] [periods_json_file] [flags] +``` + +Example: + +```bash +simd tx vesting create-periodic-vesting-account cosmos1.. periods.json +``` + +#### create-vesting-account + +The `create-vesting-account` command creates a new vesting account funded with an allocation of tokens. The account can either be a delayed or continuous vesting account, which is determined by the '--delayed' flag. All vesting accouts created will have their start time set by the committed block's time. The end_time must be provided as a UNIX epoch timestamp. + +```bash +simd tx vesting create-vesting-account [to_address] [amount] [end_time] [flags] +``` + +Example: + +```bash +simd tx vesting create-vesting-account cosmos1.. 100stake 2592000 +``` diff --git a/versioned_docs/version-0.46/integrate/modules/auth/README.md b/versioned_docs/version-0.46/integrate/modules/auth/README.md new file mode 100644 index 000000000..1090bb6ba --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/auth/README.md @@ -0,0 +1,45 @@ + + +# `auth` + +## Abstract + +This document specifies the auth module of the Cosmos SDK. + +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 middlewares, 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. + +This module is used in the Cosmos Hub. + +## Contents + +1. **[Concepts](01_concepts.md)** + * [Gas & Fees](01_concepts.md#gas-&-fees) +2. **[State](02_state.md)** + * [Accounts](02_state.md#accounts) +3. **[AnteHandlers](03_antehandlers.md)** +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) + * [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)** + * [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) diff --git a/versioned_docs/version-0.46/integrate/modules/authz/01_concepts.md b/versioned_docs/version-0.46/integrate/modules/authz/01_concepts.md new file mode 100644 index 000000000..ffe810b59 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/authz/01_concepts.md @@ -0,0 +1,55 @@ + + +# 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](https://github.com/cosmos/cosmos-sdk/blob/main/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. + +**Note:** The authz module is different from the [auth (authentication)](../modules/auth/) module that is responsible for specifying the base transaction and account types. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/authz/authorizations.go#L11-L25 + +## Built-in Authorizations + +The Cosmos SDK `x/authz` module comes with following authorization types: + +### GenericAuthorization + +`GenericAuthorization` implements the `Authorization` interface that gives unrestricted permission to execute the provided Msg on behalf of granter's account. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/authz/v1beta1/authz.proto#L13-L20 + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/authz/generic_authorization.go#L16-L29 + +* `msg` stores Msg type URL. + +### SendAuthorization + +`SendAuthorization` implements the `Authorization` interface for the `cosmos.bank.v1beta1.MsgSend` Msg. It takes a (positive) `SpendLimit` that specifies the maximum amount of tokens the grantee can spend. The `SpendLimit` is updated as the tokens are spent. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/bank/v1beta1/authz.proto#L10-L19 + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/bank/types/send_authorization.go#L23-L38 + +* `spend_limit` keeps track of how many coins are left in the authorization. + +### StakeAuthorization + +`StakeAuthorization` implements the `Authorization` interface for messages in the [staking module](https://docs.cosmos.network/v0.44/modules/staking/). It takes an `AuthorizationType` to specify whether you want to authorise delegating, undelegating or redelegating (i.e. these have to be authorised seperately). It also takes a required `MaxTokens` that keeps track of a limit to the amount of tokens that can be delegated/undelegated/redelegated. If left empty, the amount is unlimited. Additionally, this Msg takes an `AllowList` or a `DenyList`, which allows you to select which validators you allow or deny grantees to stake with. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/authz.proto#L10-L33 + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/staking/types/authz.go#L15-L35 + +## 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. + +Since the state maintaining a list for granter, grantee pair with same expiration, we are iterating over the list to remove the grant (incase of any revoke of paritcular `msgType`) from the list and we are charging 20 gas per iteration. diff --git a/versioned_docs/version-0.46/integrate/modules/authz/02_state.md b/versioned_docs/version-0.46/integrate/modules/authz/02_state.md new file mode 100644 index 000000000..ac5df1022 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/authz/02_state.md @@ -0,0 +1,23 @@ + + +# 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. + +* Grant: `0x01 | granter_address_len (1 byte) | granter_address_bytes | grantee_address_len (1 byte) | grantee_address_bytes | msgType_bytes-> ProtocolBuffer(AuthorizationGrant)` + +The grant object encapsulates an `Authorization` type and an expiration timestamp: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/authz/v1beta1/authz.proto#L22-L30 + +## GrantQueue + +We are maintaining a queue for authz pruning, whenever a grant created an item will be added to `GrantQueue` with a key of granter, grantee, expiration and value added as array of msg type urls. + +* GrantQueue: `0x02 | granter_address_len (1 byte) | granter_address_bytes | grantee_address_len (1 byte) | grantee_address_bytes | expiration_bytes -> ProtocalBuffer([]string{msgTypeUrls})` + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/authz/keeper/keys.go#L78-L93 diff --git a/versioned_docs/version-0.46/integrate/modules/authz/03_messages.md b/versioned_docs/version-0.46/integrate/modules/authz/03_messages.md new file mode 100644 index 000000000..2dfca9c7c --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/authz/03_messages.md @@ -0,0 +1,46 @@ + + +# Messages + +In this section we describe the processing of messages for the authz module. + +## 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. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/authz/v1beta1/tx.proto#L32-L41 + +The message handling should fail if: + +* both granter and grantee have the same address. +* provided `Expiration` time is less than current unix timestamp (but a grant will be created if no `expiration` time is provided since `expiration` is optional). +* 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). + +## MsgRevoke + +A grant can be removed with the `MsgRevoke` message. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/authz/v1beta1/tx.proto#L66-L72 + +The message handling should fail if: + +* both granter and grantee have the same address. +* provided `MsgTypeUrl` is empty. + +NOTE: The `MsgExec` message removes a grant if the grant has expired. + +## MsgExec + +When a grantee wants to execute a transaction on behalf of a granter, they must send `MsgExec`. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/authz/v1beta1/tx.proto#L51-L59 + +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. diff --git a/versioned_docs/version-0.46/integrate/modules/authz/04_events.md b/versioned_docs/version-0.46/integrate/modules/authz/04_events.md new file mode 100644 index 000000000..1729b49a7 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/authz/04_events.md @@ -0,0 +1,7 @@ + + +# Events + +The authz module emits proto events defined in [the Protobuf reference](https://buf.build/cosmos/cosmos-sdk/docs/main/cosmos.authz.v1beta1#cosmos.authz.v1beta1.EventGrant). diff --git a/versioned_docs/version-0.46/integrate/modules/authz/05_client.md b/versioned_docs/version-0.46/integrate/modules/authz/05_client.md new file mode 100644 index 000000000..f2ca6cc94 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/authz/05_client.md @@ -0,0 +1,172 @@ + + +# Client + +## CLI + +A user can query and interact with the `authz` module using the CLI. + +### Query + +The `query` commands allow users to query `authz` state. + +```bash +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. + +```bash +simd query authz grants [granter-addr] [grantee-addr] [msg-type-url]? [flags] +``` + +Example: + +```bash +simd query authz grants cosmos1.. cosmos1.. /cosmos.bank.v1beta1.MsgSend +``` + +Example Output: + +```bash +grants: +- authorization: + '@type': /cosmos.bank.v1beta1.SendAuthorization + spend_limit: + - amount: "100" + denom: stake + expiration: "2022-01-01T00:00:00Z" +pagination: null +``` + +### Transactions + +The `tx` commands allow users to interact with the `authz` module. + +```bash +simd tx authz --help +``` + +#### exec + +The `exec` command allows a grantee to execute a transaction on behalf of granter. + +```bash + simd tx authz exec [tx-json-file] --from [grantee] [flags] +``` + +Example: + +```bash +simd tx authz exec tx.json --from=cosmos1.. +``` + +#### grant + +The `grant` command allows a granter to grant an authorization to a grantee. + +```bash +simd tx authz grant --from [flags] +``` + +Example: + +```bash +simd tx authz grant cosmos1.. send --spend-limit=100stake --from=cosmos1.. +``` + +#### revoke + +The `revoke` command allows a granter to revoke an authorization from a grantee. + +```bash +simd tx authz revoke [grantee] [msg-type-url] --from=[granter] [flags] +``` + +Example: + +```bash +simd tx authz revoke cosmos1.. /cosmos.bank.v1beta1.MsgSend --from=cosmos1.. +``` + +## gRPC + +A user can query the `authz` module using gRPC endpoints. + +### Grants + +The `Grants` endpoint 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. + +```bash +cosmos.authz.v1beta1.Query/Grants +``` + +Example: + +```bash +grpcurl -plaintext \ + -d '{"granter":"cosmos1..","grantee":"cosmos1..","msg_type_url":"/cosmos.bank.v1beta1.MsgSend"}' \ + localhost:9090 \ + cosmos.authz.v1beta1.Query/Grants +``` + +Example Output: + +```bash +{ + "grants": [ + { + "authorization": { + "@type": "/cosmos.bank.v1beta1.SendAuthorization", + "spendLimit": [ + { + "denom":"stake", + "amount":"100" + } + ] + }, + "expiration": "2022-01-01T00:00:00Z" + } + ] +} +``` + +## REST + +A user can query the `authz` module using REST endpoints. + +```bash +/cosmos/authz/v1beta1/grants +``` + +Example: + +```bash +curl "localhost:1317/cosmos/authz/v1beta1/grants?granter=cosmos1..&grantee=cosmos1..&msg_type_url=/cosmos.bank.v1beta1.MsgSend" +``` + +Example Output: + +```bash +{ + "grants": [ + { + "authorization": { + "@type": "/cosmos.bank.v1beta1.SendAuthorization", + "spend_limit": [ + { + "denom": "stake", + "amount": "100" + } + ] + }, + "expiration": "2022-01-01T00:00:00Z" + } + ], + "pagination": null +} +``` diff --git a/versioned_docs/version-0.46/integrate/modules/authz/README.md b/versioned_docs/version-0.46/integrate/modules/authz/README.md new file mode 100644 index 000000000..ac73d76db --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/authz/README.md @@ -0,0 +1,30 @@ + + +# `authz` + +## Contents + +## Abstract + +`x/authz` is an implementation of a Cosmos SDK module, per [ADR 30](https://github.com/cosmos/cosmos-sdk/blob/main/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. + +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) diff --git a/versioned_docs/version-0.46/integrate/modules/bank/01_state.md b/versioned_docs/version-0.46/integrate/modules/bank/01_state.md new file mode 100644 index 000000000..f24725242 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/bank/01_state.md @@ -0,0 +1,19 @@ + + +# State + +The `x/bank` module keeps state of three primary objects: + +1. Account balances +2. Denomination metadata +3. The total supply of all balances + +In addition, the `x/bank` module keeps the following indexes to manage the +aforementioned state: + +* 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` diff --git a/versioned_docs/version-0.46/integrate/modules/bank/02_keepers.md b/versioned_docs/version-0.46/integrate/modules/bank/02_keepers.md new file mode 100644 index 000000000..71d35942b --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/bank/02_keepers.md @@ -0,0 +1,135 @@ + + +# 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. + +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`. + +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](https://ibc.cosmos.network). + +## Common Types + +### Input + +An input of a multiparty transfer + +```protobuf +// Input models transaction input. +message Input { + string address = 1; + repeated cosmos.base.v1beta1.Coin coins = 2; +} +``` + +### Output + +An output of a multiparty transfer. + +```protobuf +// Output models transaction outputs. +message Output { + string address = 1; + repeated cosmos.base.v1beta1.Coin coins = 2; +} +``` + +## BaseKeeper + +The base keeper provides full-permission access: the ability to arbitrary modify any account's balance and mint or burn coins. + +Restricted permission to mint per module could be achieved by using baseKeeper with `WithMintCoinsRestriction` to give specific restrictions to mint (e.g. only minting certain denom). + +```go +// Keeper defines a module interface that facilitates the transfer of coins +// between accounts. +type Keeper interface { + SendKeeper + WithMintCoinsRestriction(NewRestrictionFn BankMintingRestrictionFn) BaseKeeper + + InitGenesis(sdk.Context, *types.GenesisState) + ExportGenesis(sdk.Context) *types.GenesisState + + GetSupply(ctx sdk.Context, denom string) sdk.Coin + GetPaginatedTotalSupply(ctx sdk.Context, pagination *query.PageRequest) (sdk.Coins, *query.PageResponse, error) + IterateTotalSupply(ctx sdk.Context, cb func(sdk.Coin) bool) + GetDenomMetaData(ctx sdk.Context, denom string) (types.Metadata, bool) + SetDenomMetaData(ctx sdk.Context, denomMetaData types.Metadata) + IterateAllDenomMetaData(ctx sdk.Context, cb func(types.Metadata) bool) + + SendCoinsFromModuleToAccount(ctx sdk.Context, senderModule string, recipientAddr sdk.AccAddress, amt sdk.Coins) error + SendCoinsFromModuleToModule(ctx sdk.Context, senderModule, recipientModule string, amt sdk.Coins) error + SendCoinsFromAccountToModule(ctx sdk.Context, senderAddr sdk.AccAddress, recipientModule string, amt sdk.Coins) error + DelegateCoinsFromAccountToModule(ctx sdk.Context, senderAddr sdk.AccAddress, recipientModule string, amt sdk.Coins) error + UndelegateCoinsFromModuleToAccount(ctx sdk.Context, senderModule string, recipientAddr sdk.AccAddress, amt sdk.Coins) error + MintCoins(ctx sdk.Context, moduleName string, amt sdk.Coins) error + BurnCoins(ctx sdk.Context, moduleName string, amt sdk.Coins) error + + DelegateCoins(ctx sdk.Context, delegatorAddr, moduleAccAddr sdk.AccAddress, amt sdk.Coins) error + UndelegateCoins(ctx sdk.Context, moduleAccAddr, delegatorAddr sdk.AccAddress, amt sdk.Coins) error + + types.QueryServer +} +``` + +## 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 +// between accounts without the possibility of creating coins. +type SendKeeper interface { + ViewKeeper + + InputOutputCoins(ctx sdk.Context, inputs []types.Input, outputs []types.Output) error + SendCoins(ctx sdk.Context, fromAddr sdk.AccAddress, toAddr sdk.AccAddress, amt sdk.Coins) error + + GetParams(ctx sdk.Context) types.Params + SetParams(ctx sdk.Context, params types.Params) + + IsSendEnabledCoin(ctx sdk.Context, coin sdk.Coin) bool + IsSendEnabledCoins(ctx sdk.Context, coins ...sdk.Coin) error + + BlockedAddr(addr sdk.AccAddress) bool +} +``` + +## 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)`. + +```go +// ViewKeeper defines a module interface that facilitates read only access to +// account balances. +type ViewKeeper interface { + ValidateBalance(ctx sdk.Context, addr sdk.AccAddress) error + HasBalance(ctx sdk.Context, addr sdk.AccAddress, amt sdk.Coin) bool + + GetAllBalances(ctx sdk.Context, addr sdk.AccAddress) sdk.Coins + GetAccountsBalances(ctx sdk.Context) []types.Balance + GetBalance(ctx sdk.Context, addr sdk.AccAddress, denom string) sdk.Coin + LockedCoins(ctx sdk.Context, addr sdk.AccAddress) sdk.Coins + SpendableCoins(ctx sdk.Context, addr sdk.AccAddress) sdk.Coins + + IterateAccountBalances(ctx sdk.Context, addr sdk.AccAddress, cb func(coin sdk.Coin) (stop bool)) + IterateAllBalances(ctx sdk.Context, cb func(address sdk.AccAddress, coin sdk.Coin) (stop bool)) +} +``` diff --git a/versioned_docs/version-0.46/integrate/modules/bank/03_messages.md b/versioned_docs/version-0.46/integrate/modules/bank/03_messages.md new file mode 100644 index 000000000..a6d237945 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/bank/03_messages.md @@ -0,0 +1,28 @@ + + +# Messages + +## MsgSend + +Send coins from one address to another. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/bank/v1beta1/tx.proto#L21-L32 + +The message will fail under the following conditions: + +* The coins do not have sending enabled +* The `to` address is restricted + +## 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.46.0-rc1/proto/cosmos/bank/v1beta1/tx.proto#L37-L45 + +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 diff --git a/versioned_docs/version-0.46/integrate/modules/bank/04_events.md b/versioned_docs/version-0.46/integrate/modules/bank/04_events.md new file mode 100644 index 000000000..e71b82057 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/bank/04_events.md @@ -0,0 +1,149 @@ + + +# Events + +The bank module emits the following events: + +## Handlers + +### MsgSend + +| Type | Attribute Key | Attribute Value | +| -------- | ------------- | ------------------ | +| transfer | recipient | {recipientAddress} | +| transfer | amount | {amount} | +| message | module | bank | +| message | action | send | +| message | sender | {senderAddress} | + +### MsgMultiSend + +| Type | Attribute Key | Attribute Value | +| -------- | ------------- | ------------------ | +| transfer | recipient | {recipientAddress} | +| transfer | amount | {amount} | +| message | module | bank | +| message | action | multisend | +| message | sender | {senderAddress} | + +## 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 + +```json +{ + "type": "coinbase", + "attributes": [ + { + "key": "minter", + "value": "{{sdk.AccAddress of the module minting coins}}", + "index": true + }, + { + "key": "amount", + "value": "{{sdk.Coins being minted}}", + "index": true + } + ] +} +``` + +```json +{ + "type": "coin_received", + "attributes": [ + { + "key": "receiver", + "value": "{{sdk.AccAddress of the module minting coins}}", + "index": true + }, + { + "key": "amount", + "value": "{{sdk.Coins being received}}", + "index": true + } + ] +} +``` + +### BurnCoins + +```json +{ + "type": "burn", + "attributes": [ + { + "key": "burner", + "value": "{{sdk.AccAddress of the module burning coins}}", + "index": true + }, + { + "key": "amount", + "value": "{{sdk.Coins being burned}}", + "index": true + } + ] +} +``` + +```json +{ + "type": "coin_spent", + "attributes": [ + { + "key": "spender", + "value": "{{sdk.AccAddress of the module burning coins}}", + "index": true + }, + { + "key": "amount", + "value": "{{sdk.Coins being burned}}", + "index": true + } + ] +} +``` + +### addCoins + +```json +{ + "type": "coin_received", + "attributes": [ + { + "key": "receiver", + "value": "{{sdk.AccAddress of the address beneficiary of the coins}}", + "index": true + }, + { + "key": "amount", + "value": "{{sdk.Coins being received}}", + "index": true + } + ] +} +``` + +### subUnlockedCoins/DelegateCoins + +```json +{ + "type": "coin_spent", + "attributes": [ + { + "key": "spender", + "value": "{{sdk.AccAddress of the address which is spending coins}}", + "index": true + }, + { + "key": "amount", + "value": "{{sdk.Coins being spent}}", + "index": true + } + ] +} +``` diff --git a/versioned_docs/version-0.46/integrate/modules/bank/05_params.md b/versioned_docs/version-0.46/integrate/modules/bank/05_params.md new file mode 100644 index 000000000..8d254243c --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/bank/05_params.md @@ -0,0 +1,24 @@ + + +# Parameters + +The bank module contains the following parameters: + +| 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. + +## DefaultSendEnabled + +The default send enabled value controls send transfer capability for all +coin denominations unless specifically included in the array of `SendEnabled` +parameters. diff --git a/versioned_docs/version-0.46/integrate/modules/bank/06_client.md b/versioned_docs/version-0.46/integrate/modules/bank/06_client.md new file mode 100644 index 000000000..2377b0d92 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/bank/06_client.md @@ -0,0 +1,390 @@ + + +# Client + +## CLI + +A user can query and interact with the `bank` module using the CLI. + +### Query + +The `query` commands allow users to query `bank` state. + +```sh +simd query bank --help +``` + +#### balances + +The `balances` command allows users to query account balances by address. + +```sh +simd query bank balances [address] [flags] +``` + +Example: + +```sh +simd query bank balances cosmos1.. +``` + +Example Output: + +```yml +balances: +- amount: "1000000000" + denom: stake +pagination: + next_key: null + total: "0" +``` + +#### 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. + +```sh +simd query bank denom-metadata [flags] +``` + +Example: + +```sh +simd query bank denom-metadata --denom stake +``` + +Example Output: + +```yml +metadata: + base: stake + denom_units: + - aliases: + - STAKE + denom: stake + description: native staking token of simulation app + display: stake + name: SimApp Token + symbol: STK +``` + +#### 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. + +```sh +simd query bank total [flags] +``` + +Example: + +```sh +simd query bank total --denom stake +``` + +Example Output: + +```yml +amount: "10000000000" +denom: stake +``` + +### Transactions + +The `tx` commands allow users to interact with the `bank` module. + +```sh +simd tx bank --help +``` + +#### send + +The `send` command allows users to send funds from one account to another. + +```sh +simd tx bank send [from_key_or_address] [to_address] [amount] [flags] +``` + +Example: + +```sh +simd tx bank send cosmos1.. cosmos1.. 100stake +``` + +## gRPC + +A user can query the `bank` module using gRPC endpoints. + +### Balance + +The `Balance` endpoint allows users to query account balance by address for a given denomination. + +```sh +cosmos.bank.v1beta1.Query/Balance +``` + +Example: + +```sh +grpcurl -plaintext \ + -d '{"address":"cosmos1..","denom":"stake"}' \ + localhost:9090 \ + cosmos.bank.v1beta1.Query/Balance +``` + +Example Output: + +```json +{ + "balance": { + "denom": "stake", + "amount": "1000000000" + } +} +``` + +### AllBalances + +The `AllBalances` endpoint allows users to query account balance by address for all denominations. + +```sh +cosmos.bank.v1beta1.Query/AllBalances +``` + +Example: + +```sh +grpcurl -plaintext \ + -d '{"address":"cosmos1.."}' \ + localhost:9090 \ + cosmos.bank.v1beta1.Query/AllBalances +``` + +Example Output: + +```json +{ + "balances": [ + { + "denom": "stake", + "amount": "1000000000" + } + ], + "pagination": { + "total": "1" + } +} +``` + +### DenomMetadata + +The `DenomMetadata` endpoint allows users to query metadata for a single coin denomination. + +```sh +cosmos.bank.v1beta1.Query/DenomMetadata +``` + +Example: + +```sh +grpcurl -plaintext \ + -d '{"denom":"stake"}' \ + localhost:9090 \ + cosmos.bank.v1beta1.Query/DenomMetadata +``` + +Example Output: + +```json +{ + "metadata": { + "description": "native staking token of simulation app", + "denomUnits": [ + { + "denom": "stake", + "aliases": [ + "STAKE" + ] + } + ], + "base": "stake", + "display": "stake", + "name": "SimApp Token", + "symbol": "STK" + } +} +``` + +### DenomsMetadata + +The `DenomsMetadata` endpoint allows users to query metadata for all coin denominations. + +```sh +cosmos.bank.v1beta1.Query/DenomsMetadata +``` + +Example: + +```sh +grpcurl -plaintext \ + localhost:9090 \ + cosmos.bank.v1beta1.Query/DenomsMetadata +``` + +Example Output: + +```json +{ + "metadatas": [ + { + "description": "native staking token of simulation app", + "denomUnits": [ + { + "denom": "stake", + "aliases": [ + "STAKE" + ] + } + ], + "base": "stake", + "display": "stake", + "name": "SimApp Token", + "symbol": "STK" + } + ], + "pagination": { + "total": "1" + } +} +``` + +### DenomOwners + +The `DenomOwners` endpoint allows users to query metadata for a single coin denomination. + +```sh +cosmos.bank.v1beta1.Query/DenomOwners +``` + +Example: + +```sh +grpcurl -plaintext \ + -d '{"denom":"stake"}' \ + localhost:9090 \ + cosmos.bank.v1beta1.Query/DenomOwners +``` + +Example Output: + +```json +{ + "denomOwners": [ + { + "address": "cosmos1..", + "balance": { + "denom": "stake", + "amount": "5000000000" + } + }, + { + "address": "cosmos1..", + "balance": { + "denom": "stake", + "amount": "5000000000" + } + }, + ], + "pagination": { + "total": "2" + } +} +``` + +### TotalSupply + +The `TotalSupply` endpoint allows users to query the total supply of all coins. + +```sh +cosmos.bank.v1beta1.Query/TotalSupply +``` + +Example: + +```sh +grpcurl -plaintext \ + localhost:9090 \ + cosmos.bank.v1beta1.Query/TotalSupply +``` + +Example Output: + +```json +{ + "supply": [ + { + "denom": "stake", + "amount": "10000000000" + } + ], + "pagination": { + "total": "1" + } +} +``` + +### SupplyOf + +The `SupplyOf` endpoint allows users to query the total supply of a single coin. + +```sh +cosmos.bank.v1beta1.Query/SupplyOf +``` + +Example: + +```sh +grpcurl -plaintext \ + -d '{"denom":"stake"}' \ + localhost:9090 \ + cosmos.bank.v1beta1.Query/SupplyOf +``` + +Example Output: + +```json +{ + "amount": { + "denom": "stake", + "amount": "10000000000" + } +} +``` + +### Params + +The `Params` endpoint allows users to query the parameters of the `bank` module. + +```sh +cosmos.bank.v1beta1.Query/Params +``` + +Example: + +```sh +grpcurl -plaintext \ + localhost:9090 \ + cosmos.bank.v1beta1.Query/Params +``` + +Example Output: + +```json +{ + "params": { + "defaultSendEnabled": true + } +} +``` diff --git a/versioned_docs/version-0.46/integrate/modules/bank/README.md b/versioned_docs/version-0.46/integrate/modules/bank/README.md new file mode 100644 index 000000000..ec5d1df2f --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/bank/README.md @@ -0,0 +1,106 @@ + + +# `x/bank` + +## Abstract + +This document specifies the bank module of the 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. + +## Supply + +The `supply` functionality: + +* 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. + +### 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. + +The `ModuleAccount` interface is defined as follows: + +```go +type ModuleAccount interface { + auth.Account // same methods as the Account interface + + GetName() string // name of the module; used to obtain the address + GetPermissions() []string // permissions of module account + HasPermission(string) bool +} +``` + +> **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: + +* 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). + +### 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. + +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. + +## Contents + +1. **[State](01_state.md)** +2. **[Keepers](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)** + * [MsgSend](03_messages.md#msgsend) + * [MsgMultiSend](03_messages.md#msgmultisend) +4. **[Events](04_events.md)** + * [Handlers](04_events.md#handlers) +5. **[Parameters](05_params.md)** +6. **[Client](06_client.md)** + * [CLI](06_client.md#cli) + * [gRPC](06_client.md#grpc) diff --git a/versioned_docs/version-0.46/integrate/modules/capability/01_concepts.md b/versioned_docs/version-0.46/integrate/modules/capability/01_concepts.md new file mode 100644 index 000000000..93ecb6354 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/capability/01_concepts.md @@ -0,0 +1,35 @@ + + +# 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. + +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. + +`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. + +`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. + +## Stores + +* MemStore +* KeyStore diff --git a/versioned_docs/version-0.46/integrate/modules/capability/02_state.md b/versioned_docs/version-0.46/integrate/modules/capability/02_state.md new file mode 100644 index 000000000..3ab713bdb --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/capability/02_state.md @@ -0,0 +1,26 @@ + + +# State +## In persisted KV store + +1. Global unique capability index +2. Capability owners + +Indexes: + +* Unique index: `[]byte("index") -> []byte(currentGlobalIndex)` +* Capability Index: `[]byte("capability_index") | []byte(index) -> ProtocolBuffer(CapabilityOwners)` + +## In-memory KV store + +1. Initialized flag +2. Mapping between the module and capability tuple and the capability name +3. Mapping between the module and capability name and its index + +Indexes: + +* Initialized flag: `[]byte("mem_initialized")` +* RevCapabilityKey: `[]byte(moduleName + "/rev/" + capabilityName) -> []byte(index)` +* FwdCapabilityKey: `[]byte(moduleName + "/fwd/" + capabilityPointerAddress) -> []byte(capabilityName)` diff --git a/versioned_docs/version-0.46/integrate/modules/capability/README.md b/versioned_docs/version-0.46/integrate/modules/capability/README.md new file mode 100644 index 000000000..96a2dcbd9 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/capability/README.md @@ -0,0 +1,77 @@ + + +# `capability` + +## Overview + +`x/capability` is an implementation of a Cosmos SDK module, per [ADR 003](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-003-dynamic-capability-store.md), +that allows for provisioning, tracking, and authenticating multi-owner capabilities +at runtime. + +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. + +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. + +The keeper provides no other core functionality that can be found in other modules +like queriers, REST and CLI handlers, and genesis state. + +## Initialization + +During application initialization, the keeper must be instantiated with a persistent +store key and an in-memory store key. + +```go +type App struct { + // ... + + capabilityKeeper *capability.Keeper +} + +func NewApp(...) *App { + // ... + + app.capabilityKeeper = capability.NewKeeper(codec, persistentStoreKey, memStoreKey) +} +``` + +After the keeper is created, it can be used to create scoped sub-keepers which +are passed to other modules that can create, authenticate, and claim capabilities. +After all the necessary scoped keepers are created and the state is loaded, the +main capability keeper must be sealed to prevent further scoped keepers from +being created. + +```go +func NewApp(...) *App { + // ... + + // Creating a scoped keeper + scopedIBCKeeper := app.CapabilityKeeper.ScopeToModule(ibchost.ModuleName) + + // Seal the capability keeper to prevent any further modules from creating scoped + // sub-keepers. + app.capabilityKeeper.Seal() + + return app +} +``` + +## Contents + +1. **[Concepts](01_concepts.md)** +1. **[State](02_state.md)** diff --git a/versioned_docs/version-0.46/integrate/modules/crisis/01_state.md b/versioned_docs/version-0.46/integrate/modules/crisis/01_state.md new file mode 100644 index 000000000..50003e63d --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/crisis/01_state.md @@ -0,0 +1,17 @@ + + +# 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. + +The ConstantFee param is held in the global params store. + +* Params: `mint/params -> legacy_amino(sdk.Coin)` diff --git a/versioned_docs/version-0.46/integrate/modules/crisis/02_messages.md b/versioned_docs/version-0.46/integrate/modules/crisis/02_messages.md new file mode 100644 index 000000000..ca3b650f5 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/crisis/02_messages.md @@ -0,0 +1,25 @@ + + +# 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. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/crisis/v1beta1/tx.proto#L16-L26 + +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. diff --git a/versioned_docs/version-0.46/integrate/modules/crisis/03_events.md b/versioned_docs/version-0.46/integrate/modules/crisis/03_events.md new file mode 100644 index 000000000..5aef2078e --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/crisis/03_events.md @@ -0,0 +1,18 @@ + + +# Events + +The crisis module emits the following events: + +## Handlers + +### MsgVerifyInvariance + +| Type | Attribute Key | Attribute Value | +|-----------|---------------|------------------| +| invariant | route | {invariantRoute} | +| message | module | crisis | +| message | action | verify_invariant | +| message | sender | {senderAddress} | diff --git a/versioned_docs/version-0.46/integrate/modules/crisis/04_params.md b/versioned_docs/version-0.46/integrate/modules/crisis/04_params.md new file mode 100644 index 000000000..0d046adaa --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/crisis/04_params.md @@ -0,0 +1,11 @@ + + +# Parameters + +The crisis module contains the following parameters: + +| Key | Type | Example | +|-------------|---------------|-----------------------------------| +| ConstantFee | object (coin) | {"denom":"uatom","amount":"1000"} | diff --git a/versioned_docs/version-0.46/integrate/modules/crisis/05_client.md b/versioned_docs/version-0.46/integrate/modules/crisis/05_client.md new file mode 100644 index 000000000..5f95955a6 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/crisis/05_client.md @@ -0,0 +1,31 @@ + + +# Client + +## CLI + +A user can query and interact with the `crisis` module using the CLI. + +### Transactions + +The `tx` commands allow users to interact with the `crisis` module. + +```bash +simd tx crisis --help +``` + +#### invariant-broken + +The `invariant-broken` command submits proof when an invariant was broken to halt the chain + +```bash +simd tx crisis invariant-broken [module-name] [invariant-route] [flags] +``` + +Example: + +```bash +simd tx crisis invariant-broken bank total-supply --from=[keyname or address] +``` diff --git a/versioned_docs/version-0.46/integrate/modules/crisis/README.md b/versioned_docs/version-0.46/integrate/modules/crisis/README.md new file mode 100644 index 000000000..79d688b41 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/crisis/README.md @@ -0,0 +1,26 @@ + + +# `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) diff --git a/versioned_docs/version-0.46/integrate/modules/distribution/01_concepts.md b/versioned_docs/version-0.46/integrate/modules/distribution/01_concepts.md new file mode 100644 index 000000000..6bef259f1 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/distribution/01_concepts.md @@ -0,0 +1,34 @@ + + +# 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. + +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). + +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. + +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 + +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. + +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. diff --git a/versioned_docs/version-0.46/integrate/modules/distribution/02_state.md b/versioned_docs/version-0.46/integrate/modules/distribution/02_state.md new file mode 100644 index 000000000..e914ce253 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/distribution/02_state.md @@ -0,0 +1,65 @@ + + +# 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. + +* FeePool: `0x00 -> ProtocolBuffer(FeePool)` + +```go +// coins with decimal +type DecCoins []DecCoin + +type DecCoin struct { + Amount sdk.Dec + Denom string +} +``` + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/distribution/v1beta1/distribution.proto#L92-L96 + +## 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. + +* ValidatorDistInfo: `0x02 | ValOperatorAddrLen (1 byte) | ValOperatorAddr -> ProtocolBuffer(validatorDistribution)` + +```go +type ValidatorDistInfo struct { + OperatorAddress sdk.AccAddress + SelfBondRewards sdk.DecCoins + ValidatorCommission types.ValidatorAccumulatedCommission +} +``` + +## 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. + +* DelegationDistInfo: `0x02 | DelegatorAddrLen (1 byte) | DelegatorAddr | ValOperatorAddrLen (1 byte) | ValOperatorAddr -> ProtocolBuffer(delegatorDist)` + +```go +type DelegationDistInfo struct { + WithdrawalHeight int64 // last time this delegation withdrew rewards +} +``` diff --git a/versioned_docs/version-0.46/integrate/modules/distribution/03_begin_block.md b/versioned_docs/version-0.46/integrate/modules/distribution/03_begin_block.md new file mode 100644 index 000000000..0b68aa796 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/distribution/03_begin_block.md @@ -0,0 +1,87 @@ + + +# 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: + +* 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 + +To incentivize validators to wait and include additional pre-commits in the block, the block proposer reward is calculated from Tendermint pre-commit messages. + +## The Distribution Scheme + +See [params](07_params.md) for description of parameters. + +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`. + +### 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. + +### 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`. + +Any remaining fees are distributed among all the bonded validators, including +the proposer, in proportion to their consensus power. + +```text +powFrac = validator power / total bonded validator power +proposerMul = baseproposerreward + bonusproposerreward * P +voteMul = 1 - communitytax - proposerMul +``` + +In total, the proposer receives `fees * (voteMul * powFrac + proposerMul)`. +All other validators receive `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`. + +### 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: + +```text +(delegator proportion of the validator power / validator power) * (validator power / total bonded power) + * (1 - community tax rate) * (1 - validator commision rate) += (delegator proportion of the validator power / total bonded power) * (1 - +community tax rate) * (1 - validator commision rate) +``` diff --git a/versioned_docs/version-0.46/integrate/modules/distribution/04_messages.md b/versioned_docs/version-0.46/integrate/modules/distribution/04_messages.md new file mode 100644 index 000000000..87d608842 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/distribution/04_messages.md @@ -0,0 +1,122 @@ + + +# 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`. + +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. + +Response: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/distribution/v1beta1/tx.proto#L31-L41 + +```go +func (k Keeper) SetWithdrawAddr(ctx sdk.Context, delegatorAddr sdk.AccAddress, withdrawAddr sdk.AccAddress) error + if k.blockedAddrs[withdrawAddr.String()] { + fail with "`{withdrawAddr}` is not allowed to receive external funds" + } + + if !k.GetWithdrawAddrEnabled(ctx) { + fail with `ErrSetWithdrawAddrDisabled` + } + + k.SetDelegatorWithdrawAddr(ctx, delegatorAddr, withdrawAddr) +``` + +## 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. + +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. + +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: + +```go +stake := initial stake +rewards := 0 +previous := A +for P in P1, ..., PN`: + rewards = (R(P) - previous) * stake + stake = stake * F(P) + previous = P +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.46.0-rc1/proto/cosmos/distribution/v1beta1/tx.proto#L46-L56 + +## 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. + +## 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 { + if err := k.bankKeeper.SendCoinsFromAccountToModule(ctx, sender, types.ModuleName, amount); err != nil { + return err + } + + feePool := k.GetFeePool(ctx) + feePool.CommunityPool = feePool.CommunityPool.Add(sdk.NewDecCoinsFromCoins(amount...)...) + k.SetFeePool(ctx, feePool) + + return nil +} +``` + +## 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 +func (k Keeper) initializeDelegation(ctx sdk.Context, val sdk.ValAddress, del sdk.AccAddress) { + // period has already been incremented - we want to store the period ended by this delegation action + previousPeriod := k.GetValidatorCurrentRewards(ctx, val).Period - 1 + + // increment reference count for the period we're going to track + k.incrementReferenceCount(ctx, val, previousPeriod) + + validator := k.stakingKeeper.Validator(ctx, val) + delegation := k.stakingKeeper.Delegation(ctx, del, val) + + // calculate delegation stake in tokens + // we don't store directly, so multiply delegation shares * (tokens per share) + // note: necessary to truncate so we don't allow withdrawing more rewards than owed + stake := validator.TokensFromSharesTruncated(delegation.GetShares()) + k.SetDelegatorStartingInfo(ctx, val, del, types.NewDelegatorStartingInfo(previousPeriod, stake, uint64(ctx.BlockHeight()))) +} +``` diff --git a/versioned_docs/version-0.46/integrate/modules/distribution/05_hooks.md b/versioned_docs/version-0.46/integrate/modules/distribution/05_hooks.md new file mode 100644 index 000000000..a1702ef73 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/distribution/05_hooks.md @@ -0,0 +1,59 @@ + + +# 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` + +### 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. + +## Validator created + +* triggered-by: `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`. + +## Validator removed + +* triggered-by: `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` + +* 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. diff --git a/versioned_docs/version-0.46/integrate/modules/distribution/06_events.md b/versioned_docs/version-0.46/integrate/modules/distribution/06_events.md new file mode 100644 index 000000000..7e70f0beb --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/distribution/06_events.md @@ -0,0 +1,48 @@ + + +# Events + +The distribution module emits the following events: + +## BeginBlocker + +| Type | Attribute Key | Attribute Value | +|-----------------|---------------|--------------------| +| proposer_reward | validator | {validatorAddress} | +| proposer_reward | reward | {proposerReward} | +| commission | amount | {commissionAmount} | +| commission | validator | {validatorAddress} | +| rewards | amount | {rewardAmount} | +| rewards | validator | {validatorAddress} | + +## Handlers + +### MsgSetWithdrawAddress + +| Type | Attribute Key | Attribute Value | +|----------------------|------------------|----------------------| +| set_withdraw_address | withdraw_address | {withdrawAddress} | +| message | module | distribution | +| message | action | set_withdraw_address | +| message | sender | {senderAddress} | + +### MsgWithdrawDelegatorReward + +| Type | Attribute Key | Attribute Value | +|---------|---------------|---------------------------| +| withdraw_rewards | amount | {rewardAmount} | +| withdraw_rewards | validator | {validatorAddress} | +| message | module | distribution | +| message | action | withdraw_delegator_reward | +| message | sender | {senderAddress} | + +### MsgWithdrawValidatorCommission + +| Type | Attribute Key | Attribute Value | +|------------|---------------|-------------------------------| +| withdraw_commission | amount | {commissionAmount} | +| message | module | distribution | +| message | action | withdraw_validator_commission | +| message | sender | {senderAddress} | diff --git a/versioned_docs/version-0.46/integrate/modules/distribution/07_params.md b/versioned_docs/version-0.46/integrate/modules/distribution/07_params.md new file mode 100644 index 000000000..4cee94c9d --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/distribution/07_params.md @@ -0,0 +1,17 @@ + + +# Parameters + +The distribution module contains the following parameters: + +| Key | Type | Example | +| ------------------- | ------------ | -------------------------- | +| communitytax | string (dec) | "0.020000000000000000" [0] | +| baseproposerreward | string (dec) | "0.010000000000000000" [0] | +| bonusproposerreward | string (dec) | "0.040000000000000000" [0] | +| withdrawaddrenabled | bool | true | + +* [0] `communitytax`, `baseproposerreward` and `bonusproposerreward` must be + positive and their sum cannot exceed 1.00. diff --git a/versioned_docs/version-0.46/integrate/modules/distribution/08_client.md b/versioned_docs/version-0.46/integrate/modules/distribution/08_client.md new file mode 100644 index 000000000..8e547ba46 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/distribution/08_client.md @@ -0,0 +1,469 @@ + + +# Client + +## CLI + +A user can query and interact with the `distribution` module using the CLI. + +### Query + +The `query` commands allow users to query `distribution` state. + +```sh +simd query distribution --help +``` + +#### commission + +The `commission` command allows users to query validator commission rewards by address. + +```sh +simd query distribution commission [address] [flags] +``` + +Example: + +```sh +simd query distribution commission cosmosvaloper1.. +``` + +Example Output: + +```yml +commission: +- amount: "1000000.000000000000000000" + denom: stake +``` + +#### community-pool + +The `community-pool` command allows users to query all coin balances within the community pool. + +```sh +simd query distribution community-pool [flags] +``` + +Example: + +```sh +simd query distribution community-pool +``` + +Example Output: + +```yml +pool: +- amount: "1000000.000000000000000000" + denom: stake +``` + +#### params + +The `params` command allows users to query the parameters of the `distribution` module. + +```sh +simd query distribution params [flags] +``` + +Example: + +```sh +simd query distribution params +``` + +Example Output: + +```yml +base_proposer_reward: "0.010000000000000000" +bonus_proposer_reward: "0.040000000000000000" +community_tax: "0.020000000000000000" +withdraw_addr_enabled: true +``` + +#### rewards + +The `rewards` command allows users to query delegator rewards. Users can optionally include the validator address to query rewards earned from a specific validator. + +```sh +simd query distribution rewards [delegator-addr] [validator-addr] [flags] +``` + +Example: + +```sh +simd query distribution rewards cosmos1.. +``` + +Example Output: + +```yml +rewards: +- reward: + - amount: "1000000.000000000000000000" + denom: stake + validator_address: cosmosvaloper1.. +total: +- amount: "1000000.000000000000000000" + denom: stake +``` + +#### slashes + +The `slashes` command allows users to query all slashes for a given block range. + +```sh +simd query distribution slashes [validator] [start-height] [end-height] [flags] +``` + +Example: + +```sh +simd query distribution slashes cosmosvaloper1.. 1 1000 +``` + +Example Output: + +```yml +pagination: + next_key: null + total: "0" +slashes: +- validator_period: 20, + fraction: "0.009999999999999999" +``` + +#### validator-outstanding-rewards + +The `validator-outstanding-rewards` command allows users to query all outstanding (un-withdrawn) rewards for a validator and all their delegations. + +```sh +simd query distribution validator-outstanding-rewards [validator] [flags] +``` + +Example: + +```sh +simd query distribution validator-outstanding-rewards cosmosvaloper1.. +``` + +Example Output: + +```yml +rewards: +- amount: "1000000.000000000000000000" + denom: stake +``` + +### Transactions + +The `tx` commands allow users to interact with the `distribution` module. + +```sh +simd tx distribution --help +``` + +#### fund-community-pool + +The `fund-community-pool` command allows users to send funds to the community pool. + +```sh +simd tx distribution fund-community-pool [amount] [flags] +``` + +Example: + +```sh +simd tx distribution fund-community-pool 100stake --from cosmos1.. +``` + +#### set-withdraw-addr + +The `set-withdraw-addr` command allows users to set the withdraw address for rewards associated with a delegator address. + +```sh +simd tx distribution set-withdraw-addr [withdraw-addr] [flags] +``` + +Example: + +```sh +simd tx distribution set-withdraw-addr cosmos1.. --from cosmos1.. +``` + +#### withdraw-all-rewards + +The `withdraw-all-rewards` command allows users to withdraw all rewards for a delegator. + +```sh +simd tx distribution withdraw-all-rewards [flags] +``` + +Example: + +```sh +simd tx distribution withdraw-all-rewards --from cosmos1.. +``` + +#### withdraw-rewards + +The `withdraw-rewards` command allows users to withdraw all rewards from a given delegation address, +and optionally withdraw validator commission if the delegation address given is a validator operator and the user proves the `--commision` flag. + +```sh +simd tx distribution withdraw-rewards [validator-addr] [flags] +``` + +Example: + +```sh +simd tx distribution withdraw-rewards cosmosvaloper1.. --from cosmos1.. --commision +``` + +## gRPC + +A user can query the `distribution` module using gRPC endpoints. + +### Params + +The `Params` endpoint allows users to query parameters of the `distribution` module. + +Example: + +```sh +grpcurl -plaintext \ + localhost:9090 \ + cosmos.distribution.v1beta1.Query/Params +``` + +Example Output: + +```json +{ + "params": { + "communityTax": "20000000000000000", + "baseProposerReward": "10000000000000000", + "bonusProposerReward": "40000000000000000", + "withdrawAddrEnabled": true + } +} +``` + +### ValidatorOutstandingRewards + +The `ValidatorOutstandingRewards` endpoint allows users to query rewards of a validator address. + +Example: + +```sh +grpcurl -plaintext \ + -d '{"validator_address":"cosmosvalop1.."}' \ + localhost:9090 \ + cosmos.distribution.v1beta1.Query/ValidatorOutstandingRewards +``` + +Example Output: + +```json +{ + "rewards": { + "rewards": [ + { + "denom": "stake", + "amount": "1000000000000000" + } + ] + } +} +``` + +### ValidatorCommission + +The `ValidatorCommission` endpoint allows users to query accumulated commission for a validator. + +Example: + +```sh +grpcurl -plaintext \ + -d '{"validator_address":"cosmosvalop1.."}' \ + localhost:9090 \ + cosmos.distribution.v1beta1.Query/ValidatorCommission +``` + +Example Output: + +```json +{ + "commission": { + "commission": [ + { + "denom": "stake", + "amount": "1000000000000000" + } + ] + } +} +``` + +### ValidatorSlashes + +The `ValidatorSlashes` endpoint allows users to query slash events of a validator. + +Example: + +```sh +grpcurl -plaintext \ + -d '{"validator_address":"cosmosvalop1.."}' \ + localhost:9090 \ + cosmos.distribution.v1beta1.Query/ValidatorSlashes +``` + +Example Output: + +```json +{ + "slashes": [ + { + "validator_period": "20", + "fraction": "0.009999999999999999" + } + ], + "pagination": { + "total": "1" + } +} +``` + +### DelegationRewards + +The `DelegationRewards` endpoint allows users to query the total rewards accrued by a delegation. + +Example: + +```sh +grpcurl -plaintext \ + -d '{"delegator_address":"cosmos1..","validator_address":"cosmosvalop1.."}' \ + localhost:9090 \ + cosmos.distribution.v1beta1.Query/DelegationRewards +``` + +Example Output: + +```json +{ + "rewards": [ + { + "denom": "stake", + "amount": "1000000000000000" + } + ] +} +``` + +### DelegationTotalRewards + +The `DelegationTotalRewards` endpoint allows users to query the total rewards accrued by each validator. + +Example: + +```sh +grpcurl -plaintext \ + -d '{"delegator_address":"cosmos1.."}' \ + localhost:9090 \ + cosmos.distribution.v1beta1.Query/DelegationTotalRewards +``` + +Example Output: + +```json +{ + "rewards": [ + { + "validatorAddress": "cosmosvaloper1..", + "reward": [ + { + "denom": "stake", + "amount": "1000000000000000" + } + ] + } + ], + "total": [ + { + "denom": "stake", + "amount": "1000000000000000" + } + ] +} +``` + +### DelegatorValidators + +The `DelegatorValidators` endpoint allows users to query all validators for given delegator. + +Example: + +```sh +grpcurl -plaintext \ + -d '{"delegator_address":"cosmos1.."}' \ + localhost:9090 \ + cosmos.distribution.v1beta1.Query/DelegatorValidators +``` + +Example Output: + +```json +{ + "validators": [ + "cosmosvaloper1.." + ] +} +``` + +### DelegatorWithdrawAddress + +The `DelegatorWithdrawAddress` endpoint allows users to query the withdraw address of a delegator. + +Example: + +```sh +grpcurl -plaintext \ + -d '{"delegator_address":"cosmos1.."}' \ + localhost:9090 \ + cosmos.distribution.v1beta1.Query/DelegatorWithdrawAddress +``` + +Example Output: + +```json +{ + "withdrawAddress": "cosmos1.." +} +``` + +### CommunityPool + +The `CommunityPool` endpoint allows users to query the community pool coins. + +Example: + +```sh +grpcurl -plaintext \ + localhost:9090 \ + cosmos.distribution.v1beta1.Query/CommunityPool +``` + +Example Output: + +```json +{ + "pool": [ + { + "denom": "stake", + "amount": "1000000000000000000" + } + ] +} +``` diff --git a/versioned_docs/version-0.46/integrate/modules/distribution/README.md b/versioned_docs/version-0.46/integrate/modules/distribution/README.md new file mode 100644 index 000000000..c5a841ceb --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/distribution/README.md @@ -0,0 +1,106 @@ + + +# `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. + +```text +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)** + * [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)** + * [BeginBlocker](06_events.md#beginblocker) + * [Handlers](06_events.md#handlers) +7. **[Parameters](07_params.md)** +8. **[Parameters](07_params.md)** + * [CLI](08_client.md#cli) + * [gRPC](08_client.md#grpc) diff --git a/versioned_docs/version-0.46/integrate/modules/evidence/01_concepts.md b/versioned_docs/version-0.46/integrate/modules/evidence/01_concepts.md new file mode 100644 index 000000000..926a573bb --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/evidence/01_concepts.md @@ -0,0 +1,78 @@ + + +# 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. + +```go +// Evidence defines the contract which concrete evidence types of misbehavior +// must implement. +type Evidence interface { + proto.Message + + Route() string + Type() string + String() string + Hash() tmbytes.HexBytes + ValidateBasic() error + + // Height at which the infraction occurred + GetHeight() int64 +} + +// ValidatorEvidence extends Evidence interface to define contract +// for evidence against malicious validators +type ValidatorEvidence interface { + Evidence + + // The consensus address of the malicious validator at time of infraction + GetConsensusAddress() sdk.ConsAddress + + // The total power of the malicious validator at time of infraction + GetValidatorPower() int64 + + // The total validator set power at time of infraction + GetTotalPower() int64 +} +``` + +## 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. + +```go +type Router interface { + AddRoute(r string, h Handler) Router + HasRoute(r string) bool + GetRoute(path string) Handler + Seal() + Sealed() bool +} +``` + +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. + +```go +// Handler defines an agnostic Evidence handler. The 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. +type Handler func(sdk.Context, Evidence) error +``` diff --git a/versioned_docs/version-0.46/integrate/modules/evidence/02_state.md b/versioned_docs/version-0.46/integrate/modules/evidence/02_state.md new file mode 100644 index 000000000..00d8d05be --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/evidence/02_state.md @@ -0,0 +1,19 @@ + + +# 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`. + +```protobuf +// GenesisState defines the evidence module's genesis state. +message GenesisState { + // evidence defines all the evidence at genesis. + repeated google.protobuf.Any evidence = 1; +} + +``` + +All `Evidence` is retrieved and stored via a prefix `KVStore` using prefix `0x00` (`KeyPrefixEvidence`). diff --git a/versioned_docs/version-0.46/integrate/modules/evidence/03_messages.md b/versioned_docs/version-0.46/integrate/modules/evidence/03_messages.md new file mode 100644 index 000000000..cd902ec99 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/evidence/03_messages.md @@ -0,0 +1,55 @@ + + +# Messages + +## MsgSubmitEvidence + +Evidence is submitted through a `MsgSubmitEvidence` message: + +```protobuf +// MsgSubmitEvidence represents a message that supports submitting arbitrary +// Evidence of misbehavior such as equivocation or counterfactual signing. +message MsgSubmitEvidence { + string submitter = 1; + google.protobuf.Any evidence = 2; +} +``` + +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. + +Given the `Evidence` is registered with a corresponding `Handler`, it is processed +as follows: + +```go +func SubmitEvidence(ctx Context, evidence Evidence) error { + if _, ok := GetEvidence(ctx, evidence.Hash()); ok { + return sdkerrors.Wrap(types.ErrEvidenceExists, evidence.Hash().String()) + } + if !router.HasRoute(evidence.Route()) { + return sdkerrors.Wrap(types.ErrNoEvidenceHandlerExists, evidence.Route()) + } + + handler := router.GetRoute(evidence.Route()) + if err := handler(ctx, evidence); err != nil { + return sdkerrors.Wrap(types.ErrInvalidEvidence, err.Error()) + } + + ctx.EventManager().EmitEvent( + sdk.NewEvent( + types.EventTypeSubmitEvidence, + sdk.NewAttribute(types.AttributeKeyEvidenceHash, evidence.Hash().String()), + ), + ) + + SetEvidence(ctx, evidence) + return nil +} +``` + +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. diff --git a/versioned_docs/version-0.46/integrate/modules/evidence/04_events.md b/versioned_docs/version-0.46/integrate/modules/evidence/04_events.md new file mode 100644 index 000000000..35fd77b3f --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/evidence/04_events.md @@ -0,0 +1,18 @@ + + +# Events + +The `x/evidence` module emits the following events: + +## Handlers + +### MsgSubmitEvidence + +| Type | Attribute Key | Attribute Value | +| --------------- | ------------- | --------------- | +| submit_evidence | evidence_hash | {evidenceHash} | +| message | module | evidence | +| message | sender | {senderAddress} | +| message | action | submit_evidence | diff --git a/versioned_docs/version-0.46/integrate/modules/evidence/05_params.md b/versioned_docs/version-0.46/integrate/modules/evidence/05_params.md new file mode 100644 index 000000000..4c48b540a --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/evidence/05_params.md @@ -0,0 +1,7 @@ + + +# Parameters + +The evidence module does not contain any parameters. diff --git a/versioned_docs/version-0.46/integrate/modules/evidence/06_begin_block.md b/versioned_docs/version-0.46/integrate/modules/evidence/06_begin_block.md new file mode 100644 index 000000000..1c335d1e4 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/evidence/06_begin_block.md @@ -0,0 +1,154 @@ + + +# 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. + +### Equivocation + +The Cosmos SDK handles two types of evidence inside the ABCI `BeginBlock`: + +* `DuplicateVoteEvidence`, +* `LightClientAttackEvidence`. + +The evidence module handles these two evidence types the same way. First, the Cosmos SDK converts the Tendermint concrete evidence type to an SDK `Evidence` interface using `Equivocation` as the concrete type. + +```proto +// Equivocation implements the Evidence interface. +message Equivocation { + int64 height = 1; + google.protobuf.Timestamp time = 2; + int64 power = 3; + string consensus_address = 4; +} +``` + +For some `Equivocation` submitted in `block` to be valid, it must satisfy: + +`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. + +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. + +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: + +```go +func (k Keeper) HandleEquivocationEvidence(ctx sdk.Context, evidence *types.Equivocation) { + logger := k.Logger(ctx) + consAddr := evidence.GetConsensusAddress() + + if _, err := k.slashingKeeper.GetPubkey(ctx, consAddr.Bytes()); err != nil { + // Ignore evidence that cannot be handled. + // + // NOTE: We used to panic with: + // `panic(fmt.Sprintf("Validator consensus-address %v not found", consAddr))`, + // but this couples the expectations of the app to both Tendermint and + // the simulator. Both are expected to provide the full range of + // allowable but none of the disallowed evidence types. Instead of + // getting this coordination right, it is easier to relax the + // constraints and ignore evidence that cannot be handled. + return + } + + // calculate the age of the evidence + infractionHeight := evidence.GetHeight() + infractionTime := evidence.GetTime() + ageDuration := ctx.BlockHeader().Time.Sub(infractionTime) + ageBlocks := ctx.BlockHeader().Height - infractionHeight + + // Reject evidence if the double-sign is too old. Evidence is considered stale + // if the difference in time and number of blocks is greater than the allowed + // parameters defined. + cp := ctx.ConsensusParams() + if cp != nil && cp.Evidence != nil { + if ageDuration > cp.Evidence.MaxAgeDuration && ageBlocks > cp.Evidence.MaxAgeNumBlocks { + logger.Info( + "ignored equivocation; evidence too old", + "validator", consAddr, + "infraction_height", infractionHeight, + "max_age_num_blocks", cp.Evidence.MaxAgeNumBlocks, + "infraction_time", infractionTime, + "max_age_duration", cp.Evidence.MaxAgeDuration, + ) + return + } + } + + validator := k.stakingKeeper.ValidatorByConsAddr(ctx, consAddr) + if validator == nil || validator.IsUnbonded() { + // Defensive: Simulation doesn't take unbonding periods into account, and + // Tendermint might break this assumption at some point. + return + } + + if ok := k.slashingKeeper.HasValidatorSigningInfo(ctx, consAddr); !ok { + panic(fmt.Sprintf("expected signing info for validator %s but not found", consAddr)) + } + + // ignore if the validator is already tombstoned + if k.slashingKeeper.IsTombstoned(ctx, consAddr) { + logger.Info( + "ignored equivocation; validator already tombstoned", + "validator", consAddr, + "infraction_height", infractionHeight, + "infraction_time", infractionTime, + ) + return + } + + logger.Info( + "confirmed equivocation", + "validator", consAddr, + "infraction_height", infractionHeight, + "infraction_time", infractionTime, + ) + + // We need to retrieve the stake distribution which signed the block, so we + // subtract ValidatorUpdateDelay from the evidence height. + // Note, that this *can* result in a negative "distributionHeight", up to + // -ValidatorUpdateDelay, i.e. at the end of the + // pre-genesis block (none) = at the beginning of the genesis block. + // That's fine since this is just used to filter unbonding delegations & redelegations. + distributionHeight := infractionHeight - sdk.ValidatorUpdateDelay + + // Slash validator. The `power` is the int64 power of the validator as provided + // to/by Tendermint. This value is validator.Tokens as sent to Tendermint via + // ABCI, and now received as evidence. The fraction is passed in to separately + // to slash unbonding and rebonding delegations. + k.slashingKeeper.Slash( + ctx, + consAddr, + k.slashingKeeper.SlashFractionDoubleSign(ctx), + evidence.GetValidatorPower(), distributionHeight, + ) + + // Jail the validator if not already jailed. This will begin unbonding the + // validator if not already unbonding (tombstoned). + if !validator.IsJailed() { + k.slashingKeeper.Jail(ctx, consAddr) + } + + k.slashingKeeper.JailUntil(ctx, consAddr, types.DoubleSignJailEndTime) + k.slashingKeeper.Tombstone(ctx, consAddr) +} +``` + +**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 [State Transitions](/.././cosmos-sdk/x/staking/spec/02_state_transitions.md). diff --git a/versioned_docs/version-0.46/integrate/modules/evidence/07_client.md b/versioned_docs/version-0.46/integrate/modules/evidence/07_client.md new file mode 100644 index 000000000..52a4b34f7 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/evidence/07_client.md @@ -0,0 +1,188 @@ +# Client + +## CLI + +A user can query and interact with the `evidence` module using the CLI. + +### Query + +The `query` commands allows users to query `evidence` state. + +```bash +simd query evidence --help +``` + +### evidence + +The `evidence` command allows users to list all evidence or evidence by hash. + +Usage: + +```bash +simd query evidence [flags] +``` + +To query evidence by hash + +Example: + +```bash +simd query evidence "DF0C23E8634E480F84B9D5674A7CDC9816466DEC28A3358F73260F68D28D7660" +``` + +Example Output: + +```bash +evidence: + consensus_address: cosmosvalcons1ntk8eualewuprz0gamh8hnvcem2nrcdsgz563h + height: 11 + power: 100 + time: "2021-10-20T16:08:38.194017624Z" +``` + +To get all evidence + +Example: + +```bash +simd query evidence +``` + +Example Output: + +```bash +evidence: + consensus_address: cosmosvalcons1ntk8eualewuprz0gamh8hnvcem2nrcdsgz563h + height: 11 + power: 100 + time: "2021-10-20T16:08:38.194017624Z" +pagination: + next_key: null + total: "1" +``` + +## REST + +A user can query the `evidence` module using REST endpoints. + +### Evidence + +Get evidence by hash + +```bash +/cosmos/evidence/v1beta1/evidence/{evidence_hash} +``` + +Example: + +```bash +curl -X GET "http://localhost:1317/cosmos/evidence/v1beta1/evidence/DF0C23E8634E480F84B9D5674A7CDC9816466DEC28A3358F73260F68D28D7660" +``` + +Example Output: + +```bash +{ + "evidence": { + "consensus_address": "cosmosvalcons1ntk8eualewuprz0gamh8hnvcem2nrcdsgz563h", + "height": "11", + "power": "100", + "time": "2021-10-20T16:08:38.194017624Z" + } +} +``` + +### All evidence + +Get all evidence + +```bash +/cosmos/evidence/v1beta1/evidence +``` + +Example: + +```bash +curl -X GET "http://localhost:1317/cosmos/evidence/v1beta1/evidence" +``` + +Example Output: + +```bash +{ + "evidence": [ + { + "consensus_address": "cosmosvalcons1ntk8eualewuprz0gamh8hnvcem2nrcdsgz563h", + "height": "11", + "power": "100", + "time": "2021-10-20T16:08:38.194017624Z" + } + ], + "pagination": { + "total": "1" + } +} +``` + +## gRPC + +A user can query the `evidence` module using gRPC endpoints. + +### Evidence + +Get evidence by hash + +```bash +cosmos.evidence.v1beta1.Query/Evidence +``` + +Example: + +```bash +grpcurl -plaintext -d '{"evidence_hash":"DF0C23E8634E480F84B9D5674A7CDC9816466DEC28A3358F73260F68D28D7660"}' localhost:9090 cosmos.evidence.v1beta1.Query/Evidence +``` + +Example Output: + +```bash +{ + "evidence": { + "consensus_address": "cosmosvalcons1ntk8eualewuprz0gamh8hnvcem2nrcdsgz563h", + "height": "11", + "power": "100", + "time": "2021-10-20T16:08:38.194017624Z" + } +} +``` + +### All evidence + +Get all evidence + +```bash +cosmos.evidence.v1beta1.Query/AllEvidence +``` + +Example: + +```bash +grpcurl -plaintext localhost:9090 cosmos.evidence.v1beta1.Query/AllEvidence +``` + +Example Output: + +```bash +{ + "evidence": [ + { + "consensus_address": "cosmosvalcons1ntk8eualewuprz0gamh8hnvcem2nrcdsgz563h", + "height": "11", + "power": "100", + "time": "2021-10-20T16:08:38.194017624Z" + } + ], + "pagination": { + "total": "1" + } +} +``` diff --git a/versioned_docs/version-0.46/integrate/modules/evidence/README.md b/versioned_docs/version-0.46/integrate/modules/evidence/README.md new file mode 100644 index 000000000..a6b3d9205 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/evidence/README.md @@ -0,0 +1,40 @@ + + +# `x/evidence` + +## 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)** +6. **[BeginBlock](06_begin_block.md)** + +## Abstract + +`x/evidence` is an implementation of a Cosmos SDK module, per [ADR 009](https://github.com/cosmos/cosmos-sdk/blob/main/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. + +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. + +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. + +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. diff --git a/versioned_docs/version-0.46/integrate/modules/feegrant/01_concepts.md b/versioned_docs/version-0.46/integrate/modules/feegrant/01_concepts.md new file mode 100644 index 000000000..2d9ceda89 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/feegrant/01_concepts.md @@ -0,0 +1,93 @@ + + +# 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. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/feegrant/v1beta1/feegrant.proto#L76-L77 + +`FeeAllowanceI` looks like: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/feegrant/fees.go#L9-L32 + +## Fee Allowance types + +There are two types of fee allowances present at the moment: + +* `BasicAllowance` +* `PeriodicAllowance` +* `AllowedMsgAllowance` + +## 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. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/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 coins from `granter` account address before the expiration. + +* `expiration` specifies an optional time when this allowance expires. If the value is left empty, there is no expiry for the grant. + +* 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 coins from `granter` and it won't have any expiration. The only way to restrict the `grantee` is by revoking the grant. + +## 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. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/feegrant/v1beta1/feegrant.proto#L29-L54 + +* `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`. + +* `period` is the specific period of time, after each period passes, `period_spend_limit` will be reset. + +* `period_spend_limit` specifies the maximum number of coins that can be spent in the period. + +* `period_can_spend` is the number of coins left to be spent before the period_reset time. + +* `period_reset` keeps track of when a next period reset should happen. + +## AllowedMsgAllowance + +`AllowedMsgAllowance` is a fee allowance, it can be any of `BasicFeeAllowance`, `PeriodicAllowance` but restricted only to the allowed messages mentioned by the granter. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/feegrant/v1beta1/feegrant.proto#L56-L66 + +* `allowance` is either `BasicAllowance` or `PeriodicAllowance`. + +* `allowed_messages` is array of messages allowed to execute the given allowance. + +## FeeGranter flag + +`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. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/client/cmd.go#L236-L246 + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/client/tx/tx.go#L109-L109 + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/tx/builder.go#L270-L279 + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/tx/v1beta1/tx.proto#L196-L217 + +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" +``` + +## 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). + +## 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. + +**WARNING**: The gas is charged against the granted allowance. Ensure your messages conform to the filter, if any, before sending transactions using your allowance. + +## Pruning + +A queue in the state maintained with the prefix of expiration of the grants and checks them on EndBlock with the current block time for every block to prune. diff --git a/versioned_docs/version-0.46/integrate/modules/feegrant/02_state.md b/versioned_docs/version-0.46/integrate/modules/feegrant/02_state.md new file mode 100644 index 000000000..3ff4d8c49 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/feegrant/02_state.md @@ -0,0 +1,23 @@ + + +# 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)` + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/feegrant/feegrant.pb.go#L221-L229 + +## FeeAllowanceQueue + +Fee Allowances queue items are identified by combining the `FeeAllowancePrefixQueue` (i.e., 0x01), `expiration`, `grantee` (the account address of fee allowance grantee), `granter` (the account address of fee allowance granter). Endblocker checks `FeeAllowanceQueue` state for the expired grants and prunes them from `FeeAllowance` if there are any found. + +Fee allowance queue keys are stored in the state as follows: + +* Grant: `0x01 | expiration_bytes | grantee_addr_len (1 byte) | grantee_addr_bytes | granter_addr_len (1 byte) | granter_addr_bytes -> EmptyBytes` diff --git a/versioned_docs/version-0.46/integrate/modules/feegrant/03_messages.md b/versioned_docs/version-0.46/integrate/modules/feegrant/03_messages.md new file mode 100644 index 000000000..a4d09619a --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/feegrant/03_messages.md @@ -0,0 +1,17 @@ + + +# Messages + +## Msg/GrantAllowance + +A fee allowance grant will be created with the `MsgGrantAllowance` message. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/feegrant/v1beta1/tx.proto#L23-L36 + +## Msg/RevokeAllowance + +An allowed grant fee allowance can be removed with the `MsgRevokeAllowance` message. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/feegrant/v1beta1/tx.proto#L41-L50 diff --git a/versioned_docs/version-0.46/integrate/modules/feegrant/04_events.md b/versioned_docs/version-0.46/integrate/modules/feegrant/04_events.md new file mode 100644 index 000000000..e443558f7 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/feegrant/04_events.md @@ -0,0 +1,33 @@ + + +# Events + +The feegrant module emits the following events: + +# Msg Server + +## MsgGrantAllowance + +| Type | Attribute Key | Attribute Value | +| ------- | ------------- | ---------------- | +| message | action | set_feegrant | +| message | granter | {granterAddress} | +| message | grantee | {granteeAddress} | + +## MsgRevokeAllowance + +| Type | Attribute Key | Attribute Value | +| ------- | ------------- | ---------------- | +| message | action | revoke_feegrant | +| message | granter | {granterAddress} | +| message | grantee | {granteeAddress} | + +## Exec fee allowance + +| Type | Attribute Key | Attribute Value | +| ------- | ------------- | ---------------- | +| message | action | use_feegrant | +| message | granter | {granterAddress} | +| message | grantee | {granteeAddress} | diff --git a/versioned_docs/version-0.46/integrate/modules/feegrant/05_client.md b/versioned_docs/version-0.46/integrate/modules/feegrant/05_client.md new file mode 100644 index 000000000..52c1d9726 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/feegrant/05_client.md @@ -0,0 +1,184 @@ + + +# Client + +## CLI + +A user can query and interact with the `feegrant` module using the CLI. + +### Query + +The `query` commands allow users to query `feegrant` state. + +```sh +simd query feegrant --help +``` + +#### grant + +The `grant` command allows users to query a grant for a given granter-grantee pair. + +```sh +simd query feegrant grant [granter] [grantee] [flags] +``` + +Example: + +```sh +simd query feegrant grant cosmos1.. cosmos1.. +``` + +Example Output: + +```yml +allowance: + '@type': /cosmos.feegrant.v1beta1.BasicAllowance + expiration: null + spend_limit: + - amount: "100" + denom: stake +grantee: cosmos1.. +granter: cosmos1.. +``` + +#### grants + +The `grants` command allows users to query all grants for a given grantee. + +```sh +simd query feegrant grants [grantee] [flags] +``` + +Example: + +```sh +simd query feegrant grants cosmos1.. +``` + +Example Output: + +```yml +allowances: +- allowance: + '@type': /cosmos.feegrant.v1beta1.BasicAllowance + expiration: null + spend_limit: + - amount: "100" + denom: stake + grantee: cosmos1.. + granter: cosmos1.. +pagination: + next_key: null + total: "0" +``` + +### Transactions + +The `tx` commands allow users to interact with the `feegrant` module. + +```sh +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. + +```sh +simd tx feegrant grant [granter] [grantee] [flags] +``` + +Example (one-time spend limit): + +```sh +simd tx feegrant grant cosmos1.. cosmos1.. --spend-limit 100stake +``` + +Example (periodic spend limit): + +```sh +simd tx feegrant grant cosmos1.. cosmos1.. --period 3600 --period-limit 10stake +``` + +#### revoke + +The `revoke` command allows users to revoke a granted fee allowance. + +```sh +simd tx feegrant revoke [granter] [grantee] [flags] +``` + +Example: + +```sh +simd tx feegrant revoke cosmos1.. cosmos1.. +``` + +## gRPC + +A user can query the `feegrant` module using gRPC endpoints. + +### Allowance + +The `Allowance` endpoint allows users to query a granted fee allowance. + +```sh +cosmos.feegrant.v1beta1.Query/Allowance +``` + +Example: + +```sh +grpcurl -plaintext \ + -d '{"grantee":"cosmos1..","granter":"cosmos1.."}' \ + localhost:9090 \ + cosmos.feegrant.v1beta1.Query/Allowance +``` + +Example Output: + +```json +{ + "allowance": { + "granter": "cosmos1..", + "grantee": "cosmos1..", + "allowance": {"@type":"/cosmos.feegrant.v1beta1.BasicAllowance","spendLimit":[{"denom":"stake","amount":"100"}]} + } +} +``` + +### Allowances + +The `Allowances` endpoint allows users to query all granted fee allowances for a given grantee. + +```sh +cosmos.feegrant.v1beta1.Query/Allowances +``` + +Example: + +```sh +grpcurl -plaintext \ + -d '{"address":"cosmos1.."}' \ + localhost:9090 \ + cosmos.feegrant.v1beta1.Query/Allowances +``` + +Example Output: + +```json +{ + "allowances": [ + { + "granter": "cosmos1..", + "grantee": "cosmos1..", + "allowance": {"@type":"/cosmos.feegrant.v1beta1.BasicAllowance","spendLimit":[{"denom":"stake","amount":"100"}]} + } + ], + "pagination": { + "total": "1" + } +} +``` diff --git a/versioned_docs/version-0.46/integrate/modules/feegrant/README.md b/versioned_docs/version-0.46/integrate/modules/feegrant/README.md new file mode 100644 index 000000000..8f08a51ae --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/feegrant/README.md @@ -0,0 +1,37 @@ + + +# Fee grant + +## Abstract + +This document specifies the fee grant module. For the full ADR, please see [Fee Grant ADR-029](https://github.com/cosmos/cosmos-sdk/blob/main/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) + * [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)** + * [Msg/GrantAllowance](03_messages.md#msggrantallowance) + * [Msg/RevokeAllowance](03_messages.md#msgrevokeallowance) +4. **[Events](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)** + * [CLI](05_client.md#cli) + * [gRPC](05_client.md#grpc) diff --git a/versioned_docs/version-0.46/integrate/modules/gov/01_concepts.md b/versioned_docs/version-0.46/integrate/modules/gov/01_concepts.md new file mode 100644 index 000000000..39b39d13a --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/gov/01_concepts.md @@ -0,0 +1,203 @@ + + +# 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. + +## 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`. + +### 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. + +## Deposit + +To prevent spam, proposals must be submitted with a deposit in the coins defined by +the `MinDeposit` param. + +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. + +The deposit is kept in escrow and held by the governance `ModuleAccount` until the +proposal is finalized (passed or rejected). + +### 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. + +## Vote + +### 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. + +Note that some _participants_ can be forbidden to vote on a proposal under a +certain validator if: + +* _participant_ bonded or unbonded Atoms to said validator after proposal + entered voting period. +* _participant_ became validator after proposal entered voting period. + +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. + +### 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. + +### 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` 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. + +_Note: from the UI, for urgent proposals we should maybe add a ‘Not Urgent’ +option that casts a `NoWithVeto` vote._ + +### Weighted Votes + +[ADR-037](https://github.com/cosmos/cosmos-sdk/blob/main/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. + +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. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/gov/v1beta1/gov.proto#L33-L43 + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/gov/v1beta1/gov.proto#L136-L150 + +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. + +### 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% of `Yes` votes, excluding `Abstain` +votes. A possibility to veto exists if more than 1/3rd of all votes are +`NoWithVeto` votes. Note, both of these values are derived from the `TallyParams` +on-chain parameter, which is modifiable by governance. +This means that proposals are accepted iff: + +* There exist bonded tokens. +* Quorum has been achieved. +* The proportion of `Abstain` votes is inferior to 1/1. +* The proportion of `NoWithVeto` votes is inferior to 1/3, including + `Abstain` votes. +* The proportion of `Yes` votes, excluding `Abstain` votes, at the end of + the voting period is superior to 1/2. + +### 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. Because as little as 1/3 + 1 validation power could collude to censor transactions, non-collusion is already assumed for ranges exceeding this threshold. + +### 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. + +## 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 into +two steps: + +### 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?_) + +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. + +### 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. + +Validators and full nodes can use an automation tool, such as [Cosmovisor](https://github.com/cosmos/cosmos-sdk/blob/main/cosmovisor/README.md), for automatically switching version of the chain. diff --git a/versioned_docs/version-0.46/integrate/modules/gov/02_state.md b/versioned_docs/version-0.46/integrate/modules/gov/02_state.md new file mode 100644 index 000000000..66514ec2c --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/gov/02_state.md @@ -0,0 +1,217 @@ + + +# 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 + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/gov/v1/gov.proto#L42-L59 + +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 contains 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: + +```json +{ + "title": "...", + "description": "...", + "forum": "...", // a link to the discussion platform (i.e. Discord) + "other": "..." // any extra data that doesn't correspond to the other fields +} +``` + +This makes it far easier for clients to support multiple networks. + +The metadata has a maximum length that is chosen by the app developer, and +passed into the gov keeper as a config. The default maximum length in the SDK is 255 characters. + +### 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. + +## 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. + +### DepositParams + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/gov/v1/gov.proto#L102-L112 + +### VotingParams + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/gov/v1/gov.proto#L114-L118 + +### TallyParams + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/gov/v1/gov.proto#L120-L132 + +Parameters are stored in a global `GlobalParams` KVStore. + +Additionally, we introduce some basic types: + +```go +type Vote byte + +const ( + VoteYes = 0x1 + VoteNo = 0x2 + VoteNoWithVeto = 0x3 + VoteAbstain = 0x4 +) + +type ProposalType string + +const ( + ProposalTypePlainText = "Text" + ProposalTypeSoftwareUpgrade = "SoftwareUpgrade" +) + +type ProposalStatus byte + + +const ( + StatusNil ProposalStatus = 0x00 + StatusDepositPeriod ProposalStatus = 0x01 // Proposal is submitted. Participants can deposit on it but not vote + StatusVotingPeriod ProposalStatus = 0x02 // MinDeposit is reached, participants can vote + StatusPassed ProposalStatus = 0x03 // Proposal passed and successfully executed + StatusRejected ProposalStatus = 0x04 // Proposal has been rejected + StatusFailed ProposalStatus = 0x05 // Proposal passed but failed execution +) +``` + +## Deposit + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/gov/v1/gov.proto#L34-L40 + +## ValidatorGovInfo + +This type is used in a temp map when tallying + +```go + type ValidatorGovInfo struct { + Minus sdk.Dec + Vote Vote + } +``` + +## Stores + +_Note: Stores are KVStores in the multi-store. The key to find the store is the first parameter in the list_ + +We will use one KVStore `Governance` to store two mappings: + +* 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`. + +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 + +## 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. + +And the pseudocode for the `ProposalProcessingQueue`: + +```go + in EndBlock do + + for finishedProposalID in GetAllFinishedProposalIDs(block.Time) + proposal = load(Governance, ) // proposal is a const key + + validators = Keeper.getAllValidators() + tmpValMap := map(sdk.AccAddress)ValidatorGovInfo + + // Initiate mapping at 0. This is the amount of shares of the validator's vote that will be overridden by their delegator's votes + for each validator in validators + tmpValMap(validator.OperatorAddr).Minus = 0 + + // Tally + voterIterator = rangeQuery(Governance, ) //return all the addresses that voted on the proposal + for each (voterAddress, vote) in voterIterator + delegations = stakingKeeper.getDelegations(voterAddress) // get all delegations for current voter + + for each delegation in delegations + // make sure delegation.Shares does NOT include shares being unbonded + tmpValMap(delegation.ValidatorAddr).Minus += delegation.Shares + proposal.updateTally(vote, delegation.Shares) + + _, isVal = stakingKeeper.getValidator(voterAddress) + if (isVal) + tmpValMap(voterAddress).Vote = vote + + tallyingParam = load(GlobalParams, 'TallyingParam') + + // Update tally if validator voted + for each validator in validators + if tmpValMap(validator).HasVoted + proposal.updateTally(tmpValMap(validator).Vote, (validator.TotalShares - tmpValMap(validator).Minus)) + + + + // Check if proposal is accepted or rejected + totalNonAbstain := proposal.YesVotes + proposal.NoVotes + proposal.NoWithVetoVotes + if (proposal.Votes.YesVotes/totalNonAbstain > tallyingParam.Threshold AND proposal.Votes.NoWithVetoVotes/totalNonAbstain < tallyingParam.Veto) + // proposal was accepted at the end of the voting period + // refund deposits (non-voters already punished) + for each (amount, depositor) in proposal.Deposits + depositor.AtomBalance += amount + + stateWriter, err := proposal.Handler() + if err != nil + // proposal passed but failed during state execution + proposal.CurrentStatus = ProposalStatusFailed + else + // proposal pass and state is persisted + proposal.CurrentStatus = ProposalStatusAccepted + stateWriter.save() + else + // proposal was rejected + proposal.CurrentStatus = ProposalStatusRejected + + store(Governance, , proposal) +``` + +## Legacy Proposal + +A legacy proposal is the old implementation of governance proposal. +Contrary to proposal that can contain any messages, a legacy proposal allows to submit a set of pre-defined proposals. +These proposal are defined by their types. + +While proposals should use the new implementation of the governance proposal, we need still to use legacy proposal in order to submit a `software-upgrade` and a `cancel-software-upgrade` proposal. + +More information on how to submit proposals in the [client section](07_client.md). diff --git a/versioned_docs/version-0.46/integrate/modules/gov/03_messages.md b/versioned_docs/version-0.46/integrate/modules/gov/03_messages.md new file mode 100644 index 000000000..405931da5 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/gov/03_messages.md @@ -0,0 +1,183 @@ + + +# Messages + +## Proposal Submission + +Proposals can be submitted by any account via a `MsgSubmitProposal` +transaction. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/gov/v1/tx.proto#L33-L43 + +All `sdk.Msgs` passed into the `messages` field of a `MsgSubmitProposal` message +must be registered in the app's `MsgServiceRouter`. Each of these messages must +have one signer, namely the gov module account. And finally, the metadata length +must not be larger than the `maxMetadataLen` config passed into the gov keeper. + +**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` + +A `MsgSubmitProposal` transaction can be handled according to the following +pseudocode. + +```go +// PSEUDOCODE // +// Check if MsgSubmitProposal is valid. If it is, create proposal // + +upon receiving txGovSubmitProposal from sender do + + if !correctlyFormatted(txGovSubmitProposal) + // check if proposal is correctly formatted and the messages have routes to other modules. Includes fee payment. + // check if all messages' unique Signer is the gov acct. + // check if the metadata is not too long. + throw + + initialDeposit = txGovSubmitProposal.InitialDeposit + if (initialDeposit.Atoms <= 0) OR (sender.AtomBalance < initialDeposit.Atoms) + // InitialDeposit is negative or null OR sender has insufficient funds + throw + + if (txGovSubmitProposal.Type != ProposalTypePlainText) OR (txGovSubmitProposal.Type != ProposalTypeSoftwareUpgrade) + + sender.AtomBalance -= initialDeposit.Atoms + + depositParam = load(GlobalParams, 'DepositParam') + + proposalID = generate new proposalID + proposal = NewProposal() + + proposal.Messages = txGovSubmitProposal.Messages + proposal.Metadata = txGovSubmitProposal.Metadata + proposal.TotalDeposit = initialDeposit + proposal.SubmitTime = + proposal.DepositEndTime = .Add(depositParam.MaxDepositPeriod) + proposal.Deposits.append({initialDeposit, sender}) + proposal.Submitter = sender + proposal.YesVotes = 0 + proposal.NoVotes = 0 + proposal.NoWithVetoVotes = 0 + proposal.AbstainVotes = 0 + proposal.CurrentStatus = ProposalStatusOpen + + store(Proposals, , proposal) // Store proposal in Proposals mapping + 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. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/gov/v1/tx.proto#L90-L97 + +**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` + +A `MsgDeposit` transaction has to go through a number of checks to be valid. +These checks are outlined in the following pseudocode. + +```go +// PSEUDOCODE // +// Check if MsgDeposit is valid. If it is, increase deposit and check if MinDeposit is reached + +upon receiving txGovDeposit from sender do + // check if proposal is correctly formatted. Includes fee payment. + + if !correctlyFormatted(txGovDeposit) + throw + + proposal = load(Proposals, ) // proposal is a const key, proposalID is variable + + if (proposal == nil) + // There is no proposal for this proposalID + throw + + if (txGovDeposit.Deposit.Atoms <= 0) OR (sender.AtomBalance < txGovDeposit.Deposit.Atoms) OR (proposal.CurrentStatus != ProposalStatusOpen) + + // deposit is negative or null + // OR sender has insufficient funds + // OR proposal is not open for deposit anymore + + throw + + depositParam = load(GlobalParams, 'DepositParam') + + if (CurrentBlock >= proposal.SubmitBlock + depositParam.MaxDepositPeriod) + proposal.CurrentStatus = ProposalStatusClosed + + else + // sender can deposit + sender.AtomBalance -= txGovDeposit.Deposit.Atoms + + proposal.Deposits.append({txGovVote.Deposit, sender}) + proposal.TotalDeposit.Plus(txGovDeposit.Deposit) + + if (proposal.TotalDeposit >= depositParam.MinDeposit) + // MinDeposit is reached, vote opens + + proposal.VotingStartBlock = CurrentBlock + proposal.CurrentStatus = ProposalStatusActive + ProposalProcessingQueue.push(txGovDeposit.ProposalID) + + store(Proposals, , proposal) +``` + +## 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. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/gov/v1/tx.proto#L64-L72 + +**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._ + +Next is a pseudocode outline of the way `MsgVote` transactions are +handled: + +```go + // PSEUDOCODE // + // Check if MsgVote is valid. If it is, count vote// + + upon receiving txGovVote from sender do + // check if proposal is correctly formatted. Includes fee payment. + + if !correctlyFormatted(txGovDeposit) + throw + + proposal = load(Proposals, ) + + if (proposal == nil) + // There is no proposal for this proposalID + throw + + + if (proposal.CurrentStatus == ProposalStatusActive) + + + // Sender can vote if + // Proposal is active + // Sender has some bonds + + store(Governance, , txGovVote.Vote) // Voters can vote multiple times. Re-voting overrides previous vote. This is ok because tallying is done once at the end. +``` diff --git a/versioned_docs/version-0.46/integrate/modules/gov/04_events.md b/versioned_docs/version-0.46/integrate/modules/gov/04_events.md new file mode 100644 index 000000000..3c0d72ce9 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/gov/04_events.md @@ -0,0 +1,65 @@ + + +# Events + +The governance module emits the following events: + +## EndBlocker + +| Type | Attribute Key | Attribute Value | +| ----------------- | --------------- | ---------------- | +| inactive_proposal | proposal_id | {proposalID} | +| inactive_proposal | proposal_result | {proposalResult} | +| active_proposal | proposal_id | {proposalID} | +| active_proposal | proposal_result | {proposalResult} | + +## Handlers + +### MsgSubmitProposal + +| Type | Attribute Key | Attribute Value | +| ------------------- | ------------------- | --------------- | +| submit_proposal | proposal_id | {proposalID} | +| submit_proposal [0] | voting_period_start | {proposalID} | +| proposal_deposit | amount | {depositAmount} | +| proposal_deposit | proposal_id | {proposalID} | +| message | module | governance | +| message | action | submit_proposal | +| message | sender | {senderAddress} | + +* [0] Event only emitted if the voting period starts during the submission. + +### MsgVote + +| Type | Attribute Key | Attribute Value | +| ------------- | ------------- | --------------- | +| proposal_vote | option | {voteOption} | +| proposal_vote | proposal_id | {proposalID} | +| message | module | governance | +| message | action | vote | +| message | sender | {senderAddress} | + +### MsgVoteWeighted + +| Type | Attribute Key | Attribute Value | +| ------------- | ------------- | ------------------------ | +| proposal_vote | option | {weightedVoteOptions} | +| proposal_vote | proposal_id | {proposalID} | +| message | module | governance | +| message | action | vote | +| message | sender | {senderAddress} | + +### MsgDeposit + +| Type | Attribute Key | Attribute Value | +| -------------------- | ------------------- | --------------- | +| proposal_deposit | amount | {depositAmount} | +| proposal_deposit | proposal_id | {proposalID} | +| proposal_deposit [0] | voting_period_start | {proposalID} | +| message | module | governance | +| message | action | deposit | +| message | sender | {senderAddress} | + +* [0] Event only emitted if the voting period starts during the submission. diff --git a/versioned_docs/version-0.46/integrate/modules/gov/05_future_improvements.md b/versioned_docs/version-0.46/integrate/modules/gov/05_future_improvements.md new file mode 100644 index 000000000..12f2e9e5c --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/gov/05_future_improvements.md @@ -0,0 +1,30 @@ + + +# 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. diff --git a/versioned_docs/version-0.46/integrate/modules/gov/06_params.md b/versioned_docs/version-0.46/integrate/modules/gov/06_params.md new file mode 100644 index 000000000..2cc017669 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/gov/06_params.md @@ -0,0 +1,28 @@ + + +# Parameters + +The governance module contains the following parameters: + +| Key | Type | Example | +|---------------|--------|----------------------------------------------------------------------------------------------------| +| depositparams | object | {"min_deposit":[{"denom":"uatom","amount":"10000000"}],"max_deposit_period":"172800000000000"} | +| votingparams | object | {"voting_period":"172800000000000"} | +| tallyparams | object | {"quorum":"0.334000000000000000","threshold":"0.500000000000000000","veto":"0.334000000000000000"} | + +## SubKeys + +| Key | Type | Example | +|--------------------|------------------|-----------------------------------------| +| min_deposit | array (coins) | [{"denom":"uatom","amount":"10000000"}] | +| max_deposit_period | string (time ns) | "172800000000000" | +| voting_period | string (time ns) | "172800000000000" | +| quorum | string (dec) | "0.334000000000000000" | +| threshold | string (dec) | "0.500000000000000000" | +| veto | string (dec) | "0.334000000000000000" | + +__NOTE__: The governance module contains parameters that are objects unlike other +modules. If only a subset of parameters are desired to be changed, only they need +to be included and not the entire parameter object structure. diff --git a/versioned_docs/version-0.46/integrate/modules/gov/07_client.md b/versioned_docs/version-0.46/integrate/modules/gov/07_client.md new file mode 100644 index 000000000..3450a052e --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/gov/07_client.md @@ -0,0 +1,1804 @@ + + +# Client + +## CLI + +A user can query and interact with the `gov` module using the CLI. + +### Query + +The `query` commands allow users to query `gov` state. + +```bash +simd query gov --help +``` + +#### deposit + +The `deposit` command allows users to query a deposit for a given proposal from a given depositor. + +```bash +simd query gov deposit [proposal-id] [depositer-addr] [flags] +``` + +Example: + +```bash +simd query gov deposit 1 cosmos1.. +``` + +Example Output: + +```bash +amount: +- amount: "100" + denom: stake +depositor: cosmos1.. +proposal_id: "1" +``` + +#### deposits + +The `deposits` command allows users to query all deposits for a given proposal. + +```bash +simd query gov deposits [proposal-id] [flags] +``` + +Example: + +```bash +simd query gov deposits 1 +``` + +Example Output: + +```bash +deposits: +- amount: + - amount: "100" + denom: stake + depositor: cosmos1.. + proposal_id: "1" +pagination: + next_key: null + total: "0" +``` + +#### param + +The `param` command allows users to query a given parameter for the `gov` module. + +```bash +simd query gov param [param-type] [flags] +``` + +Example: + +```bash +simd query gov param voting +``` + +Example Output: + +```bash +voting_period: "172800000000000" +``` + +#### params + +The `params` command allows users to query all parameters for the `gov` module. + +```bash +simd query gov params [flags] +``` + +Example: + +```bash +simd query gov params +``` + +Example Output: + +```bash +deposit_params: + max_deposit_period: "172800000000000" + min_deposit: + - amount: "10000000" + denom: stake +tally_params: + quorum: "0.334000000000000000" + threshold: "0.500000000000000000" + veto_threshold: "0.334000000000000000" +voting_params: + voting_period: "172800000000000" +``` + +#### proposal + +The `proposal` command allows users to query a given proposal. + +```bash +simd query gov proposal [proposal-id] [flags] +``` + +Example: + +```bash +simd query gov proposal 1 +``` + +Example Output: + +```bash +deposit_end_time: "2022-03-30T11:50:20.819676256Z" +final_tally_result: + abstain_count: "0" + no_count: "0" + no_with_veto_count: "0" + yes_count: "0" +id: "1" +messages: +- '@type': /cosmos.bank.v1beta1.MsgSend + amount: + - amount: "10" + denom: stake + from_address: cosmos1.. + to_address: cosmos1.. +metadata: AQ== +status: PROPOSAL_STATUS_DEPOSIT_PERIOD +submit_time: "2022-03-28T11:50:20.819676256Z" +total_deposit: +- amount: "10" + denom: stake +voting_end_time: null +voting_start_time: null +``` + +#### proposals + +The `proposals` command allows users to query all proposals with optional filters. + +```bash +simd query gov proposals [flags] +``` + +Example: + +```bash +simd query gov proposals +``` + +Example Output: + +```bash +pagination: + next_key: null + total: "0" +proposals: +- deposit_end_time: "2022-03-30T11:50:20.819676256Z" + final_tally_result: + abstain_count: "0" + no_count: "0" + no_with_veto_count: "0" + yes_count: "0" + id: "1" + messages: + - '@type': /cosmos.bank.v1beta1.MsgSend + amount: + - amount: "10" + denom: stake + from_address: cosmos1.. + to_address: cosmos1.. + metadata: AQ== + status: PROPOSAL_STATUS_DEPOSIT_PERIOD + submit_time: "2022-03-28T11:50:20.819676256Z" + total_deposit: + - amount: "10" + denom: stake + voting_end_time: null + voting_start_time: null +- deposit_end_time: "2022-03-30T14:02:41.165025015Z" + final_tally_result: + abstain_count: "0" + no_count: "0" + no_with_veto_count: "0" + yes_count: "0" + id: "2" + messages: + - '@type': /cosmos.bank.v1beta1.MsgSend + amount: + - amount: "10" + denom: stake + from_address: cosmos1.. + to_address: cosmos1.. + metadata: AQ== + status: PROPOSAL_STATUS_DEPOSIT_PERIOD + submit_time: "2022-03-28T14:02:41.165025015Z" + total_deposit: + - amount: "10" + denom: stake + voting_end_time: null + voting_start_time: null +``` + +#### proposer + +The `proposer` command allows users to query the proposer for a given proposal. + +```bash +simd query gov proposer [proposal-id] [flags] +``` + +Example: + +```bash +simd query gov proposer 1 +``` + +Example Output: + +```bash +proposal_id: "1" +proposer: cosmos1.. +``` + +#### tally + +The `tally` command allows users to query the tally of a given proposal vote. + +```bash +simd query gov tally [proposal-id] [flags] +``` + +Example: + +```bash +simd query gov tally 1 +``` + +Example Output: + +```bash +abstain: "0" +"no": "0" +no_with_veto: "0" +"yes": "1" +``` + +#### vote + +The `vote` command allows users to query a vote for a given proposal. + +```bash +simd query gov vote [proposal-id] [voter-addr] [flags] +``` + +Example: + +```bash +simd query gov vote 1 cosmos1.. +``` + +Example Output: + +```bash +option: VOTE_OPTION_YES +options: +- option: VOTE_OPTION_YES + weight: "1.000000000000000000" +proposal_id: "1" +voter: cosmos1.. +``` + +#### votes + +The `votes` command allows users to query all votes for a given proposal. + +```bash +simd query gov votes [proposal-id] [flags] +``` + +Example: + +```bash +simd query gov votes 1 +``` + +Example Output: + +```bash +pagination: + next_key: null + total: "0" +votes: +- option: VOTE_OPTION_YES + options: + - option: VOTE_OPTION_YES + weight: "1.000000000000000000" + proposal_id: "1" + voter: cosmos1.. +``` + +### Transactions + +The `tx` commands allow users to interact with the `gov` module. + +```bash +simd tx gov --help +``` + +#### deposit + +The `deposit` command allows users to deposit tokens for a given proposal. + +```bash +simd tx gov deposit [proposal-id] [deposit] [flags] +``` + +Example: + +```bash +simd tx gov deposit 1 10000000stake --from cosmos1.. +``` + +#### draft-proposal + +The `draft-proposal` command allows users to draft any type of proposal. +The command returns a `draft_proposal.json`, to be used by `submit-proposal` after being completed. +The `draft_metadata.json` is meant to be uploaded to [IPFS](./08_metadata.md). + +```bash +simd tx gov draft-proposal +``` + +#### submit-proposal + +The `submit-proposal` command allows users to submit a governance proposal along with some messages and metadata. +Messages, metadata and deposit are defined in a JSON file. + +```bash +simd tx gov submit-proposal [path-to-proposal-json] [flags] +``` + +Example: + +```bash +simd tx gov submit-proposal /path/to/proposal.json --from cosmos1.. +``` + +where `proposal.json` contains: + +```json +{ + "messages": [ + { + "@type": "/cosmos.bank.v1beta1.MsgSend", + "from_address": "cosmos1...", // The gov module module address + "to_address": "cosmos1...", + "amount":[{"denom": "stake","amount": "10"}] + } + ], + "metadata": "AQ==", + "deposit": "10stake" +} +``` + +#### submit-legacy-proposal + +The `submit-legacy-proposal` command allows users to submit a governance legacy proposal along with an initial deposit. + +```bash +simd tx gov submit-legacy-proposal [command] [flags] +``` + +Example: + +```bash +simd tx gov submit-legacy-proposal --title="Test Proposal" --description="testing" --type="Text" --deposit="100000000stake" --from cosmos1.. +``` + +Example (`cancel-software-upgrade`): + +```bash +simd tx gov submit-legacy-proposal cancel-software-upgrade --title="Test Proposal" --description="testing" --deposit="100000000stake" --from cosmos1.. +``` + +Example (`community-pool-spend`): + +```bash +simd tx gov submit-legacy-proposal community-pool-spend proposal.json --from cosmos1.. +``` + +```json +{ + "title": "Test Proposal", + "description": "testing, 1, 2, 3", + "recipient": "cosmos1..", + "amount": "10000000stake", + "deposit": "10000000stake" +} +``` + +Example (`param-change`): + +```bash +simd tx gov submit-legacy-proposal param-change proposal.json --from cosmos1.. +``` + +```json +{ + "title": "Test Proposal", + "description": "testing, testing, 1, 2, 3", + "changes": [ + { + "subspace": "staking", + "key": "MaxValidators", + "value": 100 + } + ], + "deposit": "10000000stake" +} +``` + +Example (`software-upgrade`): + +```bash +simd tx gov submit-legacy-proposal software-upgrade v2 --title="Test Proposal" --description="testing, testing, 1, 2, 3" --upgrade-height 1000000 --from cosmos1.. +``` + +#### vote + +The `vote` command allows users to submit a vote for a given governance proposal. + +```bash +simd tx gov vote [command] [flags] +``` + +Example: + +```bash +simd tx gov vote 1 yes --from cosmos1.. +``` + +#### weighted-vote + +The `weighted-vote` command allows users to submit a weighted vote for a given governance proposal. + +```bash +simd tx gov weighted-vote [proposal-id] [weighted-options] [flags] +``` + +Example: + +```bash +simd tx gov weighted-vote 1 yes=0.5,no=0.5 --from cosmos1.. +``` + +## gRPC + +A user can query the `gov` module using gRPC endpoints. + +### Proposal + +The `Proposal` endpoint allows users to query a given proposal. + +Using legacy v1beta1: + +```bash +cosmos.gov.v1beta1.Query/Proposal +``` + +Example: + +```bash +grpcurl -plaintext \ + -d '{"proposal_id":"1"}' \ + localhost:9090 \ + cosmos.gov.v1beta1.Query/Proposal +``` + +Example Output: + +```bash +{ + "proposal": { + "proposalId": "1", + "content": {"@type":"/cosmos.gov.v1beta1.TextProposal","description":"testing, testing, 1, 2, 3","title":"Test Proposal"}, + "status": "PROPOSAL_STATUS_VOTING_PERIOD", + "finalTallyResult": { + "yes": "0", + "abstain": "0", + "no": "0", + "noWithVeto": "0" + }, + "submitTime": "2021-09-16T19:40:08.712440474Z", + "depositEndTime": "2021-09-18T19:40:08.712440474Z", + "totalDeposit": [ + { + "denom": "stake", + "amount": "10000000" + } + ], + "votingStartTime": "2021-09-16T19:40:08.712440474Z", + "votingEndTime": "2021-09-18T19:40:08.712440474Z" + } +} +``` + +Using v1: + +```bash +cosmos.gov.v1.Query/Proposal +``` + +Example: + +```bash +grpcurl -plaintext \ + -d '{"proposal_id":"1"}' \ + localhost:9090 \ + cosmos.gov.v1.Query/Proposal +``` + +Example Output: + +```bash +{ + "proposal": { + "id": "1", + "messages": [ + {"@type":"/cosmos.bank.v1beta1.MsgSend","amount":[{"denom":"stake","amount":"10"}],"fromAddress":"cosmos1..","toAddress":"cosmos1.."} + ], + "status": "PROPOSAL_STATUS_VOTING_PERIOD", + "finalTallyResult": { + "yesCount": "0", + "abstainCount": "0", + "noCount": "0", + "noWithVetoCount": "0" + }, + "submitTime": "2022-03-28T11:50:20.819676256Z", + "depositEndTime": "2022-03-30T11:50:20.819676256Z", + "totalDeposit": [ + { + "denom": "stake", + "amount": "10000000" + } + ], + "votingStartTime": "2022-03-28T14:25:26.644857113Z", + "votingEndTime": "2022-03-30T14:25:26.644857113Z", + "metadata": "AQ==" + } +} +``` + + +### Proposals + +The `Proposals` endpoint allows users to query all proposals with optional filters. + +Using legacy v1beta1: + +```bash +cosmos.gov.v1beta1.Query/Proposals +``` + +Example: + +```bash +grpcurl -plaintext \ + localhost:9090 \ + cosmos.gov.v1beta1.Query/Proposals +``` + +Example Output: + +```bash +{ + "proposals": [ + { + "proposalId": "1", + "status": "PROPOSAL_STATUS_VOTING_PERIOD", + "finalTallyResult": { + "yes": "0", + "abstain": "0", + "no": "0", + "noWithVeto": "0" + }, + "submitTime": "2022-03-28T11:50:20.819676256Z", + "depositEndTime": "2022-03-30T11:50:20.819676256Z", + "totalDeposit": [ + { + "denom": "stake", + "amount": "10000000010" + } + ], + "votingStartTime": "2022-03-28T14:25:26.644857113Z", + "votingEndTime": "2022-03-30T14:25:26.644857113Z" + }, + { + "proposalId": "2", + "status": "PROPOSAL_STATUS_DEPOSIT_PERIOD", + "finalTallyResult": { + "yes": "0", + "abstain": "0", + "no": "0", + "noWithVeto": "0" + }, + "submitTime": "2022-03-28T14:02:41.165025015Z", + "depositEndTime": "2022-03-30T14:02:41.165025015Z", + "totalDeposit": [ + { + "denom": "stake", + "amount": "10" + } + ], + "votingStartTime": "0001-01-01T00:00:00Z", + "votingEndTime": "0001-01-01T00:00:00Z" + } + ], + "pagination": { + "total": "2" + } +} + +``` + +Using v1: + +```bash +cosmos.gov.v1.Query/Proposals +``` + +Example: + +```bash +grpcurl -plaintext \ + localhost:9090 \ + cosmos.gov.v1.Query/Proposals +``` + +Example Output: + +```bash +{ + "proposals": [ + { + "id": "1", + "messages": [ + {"@type":"/cosmos.bank.v1beta1.MsgSend","amount":[{"denom":"stake","amount":"10"}],"fromAddress":"cosmos1..","toAddress":"cosmos1.."} + ], + "status": "PROPOSAL_STATUS_VOTING_PERIOD", + "finalTallyResult": { + "yesCount": "0", + "abstainCount": "0", + "noCount": "0", + "noWithVetoCount": "0" + }, + "submitTime": "2022-03-28T11:50:20.819676256Z", + "depositEndTime": "2022-03-30T11:50:20.819676256Z", + "totalDeposit": [ + { + "denom": "stake", + "amount": "10000000010" + } + ], + "votingStartTime": "2022-03-28T14:25:26.644857113Z", + "votingEndTime": "2022-03-30T14:25:26.644857113Z", + "metadata": "AQ==" + }, + { + "id": "2", + "messages": [ + {"@type":"/cosmos.bank.v1beta1.MsgSend","amount":[{"denom":"stake","amount":"10"}],"fromAddress":"cosmos1..","toAddress":"cosmos1.."} + ], + "status": "PROPOSAL_STATUS_DEPOSIT_PERIOD", + "finalTallyResult": { + "yesCount": "0", + "abstainCount": "0", + "noCount": "0", + "noWithVetoCount": "0" + }, + "submitTime": "2022-03-28T14:02:41.165025015Z", + "depositEndTime": "2022-03-30T14:02:41.165025015Z", + "totalDeposit": [ + { + "denom": "stake", + "amount": "10" + } + ], + "metadata": "AQ==" + } + ], + "pagination": { + "total": "2" + } +} +``` + +### Vote + +The `Vote` endpoint allows users to query a vote for a given proposal. + +Using legacy v1beta1: + +```bash +cosmos.gov.v1beta1.Query/Vote +``` + +Example: + +```bash +grpcurl -plaintext \ + -d '{"proposal_id":"1","voter":"cosmos1.."}' \ + localhost:9090 \ + cosmos.gov.v1beta1.Query/Vote +``` + +Example Output: + +```bash +{ + "vote": { + "proposalId": "1", + "voter": "cosmos1..", + "option": "VOTE_OPTION_YES", + "options": [ + { + "option": "VOTE_OPTION_YES", + "weight": "1000000000000000000" + } + ] + } +} +``` + +Using v1: + +```bash +cosmos.gov.v1.Query/Vote +``` + +Example: + +```bash +grpcurl -plaintext \ + -d '{"proposal_id":"1","voter":"cosmos1.."}' \ + localhost:9090 \ + cosmos.gov.v1.Query/Vote +``` + +Example Output: + +```bash +{ + "vote": { + "proposalId": "1", + "voter": "cosmos1..", + "option": "VOTE_OPTION_YES", + "options": [ + { + "option": "VOTE_OPTION_YES", + "weight": "1.000000000000000000" + } + ] + } +} +``` + +### Votes + +The `Votes` endpoint allows users to query all votes for a given proposal. + +Using legacy v1beta1: + +```bash +cosmos.gov.v1beta1.Query/Votes +``` + +Example: + +```bash +grpcurl -plaintext \ + -d '{"proposal_id":"1"}' \ + localhost:9090 \ + cosmos.gov.v1beta1.Query/Votes +``` + +Example Output: + +```bash +{ + "votes": [ + { + "proposalId": "1", + "voter": "cosmos1..", + "options": [ + { + "option": "VOTE_OPTION_YES", + "weight": "1000000000000000000" + } + ] + } + ], + "pagination": { + "total": "1" + } +} +``` + +Using v1: + +```bash +cosmos.gov.v1.Query/Votes +``` + +Example: + +```bash +grpcurl -plaintext \ + -d '{"proposal_id":"1"}' \ + localhost:9090 \ + cosmos.gov.v1.Query/Votes +``` + +Example Output: + +```bash +{ + "votes": [ + { + "proposalId": "1", + "voter": "cosmos1..", + "options": [ + { + "option": "VOTE_OPTION_YES", + "weight": "1.000000000000000000" + } + ] + } + ], + "pagination": { + "total": "1" + } +} +``` + +### Params + +The `Params` endpoint allows users to query all parameters for the `gov` module. + + + +Using legacy v1beta1: + +```bash +cosmos.gov.v1beta1.Query/Params +``` + +Example: + +```bash +grpcurl -plaintext \ + -d '{"params_type":"voting"}' \ + localhost:9090 \ + cosmos.gov.v1beta1.Query/Params +``` + +Example Output: + +```bash +{ + "votingParams": { + "votingPeriod": "172800s" + }, + "depositParams": { + "maxDepositPeriod": "0s" + }, + "tallyParams": { + "quorum": "MA==", + "threshold": "MA==", + "vetoThreshold": "MA==" + } +} +``` + +Using v1: + +```bash +cosmos.gov.v1.Query/Params +``` + +Example: + +```bash +grpcurl -plaintext \ + -d '{"params_type":"voting"}' \ + localhost:9090 \ + cosmos.gov.v1.Query/Params +``` + +Example Output: + +```bash +{ + "votingParams": { + "votingPeriod": "172800s" + } +} +``` + +### Deposit + +The `Deposit` endpoint allows users to query a deposit for a given proposal from a given depositor. + +Using legacy v1beta1: + +```bash +cosmos.gov.v1beta1.Query/Deposit +``` + +Example: + +```bash +grpcurl -plaintext \ + '{"proposal_id":"1","depositor":"cosmos1.."}' \ + localhost:9090 \ + cosmos.gov.v1beta1.Query/Deposit +``` + +Example Output: + +```bash +{ + "deposit": { + "proposalId": "1", + "depositor": "cosmos1..", + "amount": [ + { + "denom": "stake", + "amount": "10000000" + } + ] + } +} +``` + +Using v1: + +```bash +cosmos.gov.v1.Query/Deposit +``` + +Example: + +```bash +grpcurl -plaintext \ + '{"proposal_id":"1","depositor":"cosmos1.."}' \ + localhost:9090 \ + cosmos.gov.v1.Query/Deposit +``` + +Example Output: + +```bash +{ + "deposit": { + "proposalId": "1", + "depositor": "cosmos1..", + "amount": [ + { + "denom": "stake", + "amount": "10000000" + } + ] + } +} +``` + +### deposits + +The `Deposits` endpoint allows users to query all deposits for a given proposal. + +Using legacy v1beta1: + +```bash +cosmos.gov.v1beta1.Query/Deposits +``` + +Example: + +```bash +grpcurl -plaintext \ + -d '{"proposal_id":"1"}' \ + localhost:9090 \ + cosmos.gov.v1beta1.Query/Deposits +``` + +Example Output: + +```bash +{ + "deposits": [ + { + "proposalId": "1", + "depositor": "cosmos1..", + "amount": [ + { + "denom": "stake", + "amount": "10000000" + } + ] + } + ], + "pagination": { + "total": "1" + } +} +``` + +Using v1: + +```bash +cosmos.gov.v1.Query/Deposits +``` + +Example: + +```bash +grpcurl -plaintext \ + -d '{"proposal_id":"1"}' \ + localhost:9090 \ + cosmos.gov.v1.Query/Deposits +``` + +Example Output: + +```bash +{ + "deposits": [ + { + "proposalId": "1", + "depositor": "cosmos1..", + "amount": [ + { + "denom": "stake", + "amount": "10000000" + } + ] + } + ], + "pagination": { + "total": "1" + } +} +``` + +### TallyResult + +The `TallyResult` endpoint allows users to query the tally of a given proposal. + +Using legacy v1beta1: + +```bash +cosmos.gov.v1beta1.Query/TallyResult +``` + +Example: + +```bash +grpcurl -plaintext \ + -d '{"proposal_id":"1"}' \ + localhost:9090 \ + cosmos.gov.v1beta1.Query/TallyResult +``` + +Example Output: + +```bash +{ + "tally": { + "yes": "1000000", + "abstain": "0", + "no": "0", + "noWithVeto": "0" + } +} +``` + +Using v1: + +```bash +cosmos.gov.v1.Query/TallyResult +``` + +Example: + +```bash +grpcurl -plaintext \ + -d '{"proposal_id":"1"}' \ + localhost:9090 \ + cosmos.gov.v1.Query/TallyResult +``` + +Example Output: + +```bash +{ + "tally": { + "yes": "1000000", + "abstain": "0", + "no": "0", + "noWithVeto": "0" + } +} +``` + +## REST + +A user can query the `gov` module using REST endpoints. + +### proposal + +The `proposals` endpoint allows users to query a given proposal. + +Using legacy v1beta1: + +```bash +/cosmos/gov/v1beta1/proposals/{proposal_id} +``` + +Example: + +```bash +curl localhost:1317/cosmos/gov/v1beta1/proposals/1 +``` + +Example Output: + +```bash +{ + "proposal": { + "proposal_id": "1", + "content": null, + "status": "PROPOSAL_STATUS_VOTING_PERIOD", + "final_tally_result": { + "yes": "0", + "abstain": "0", + "no": "0", + "no_with_veto": "0" + }, + "submit_time": "2022-03-28T11:50:20.819676256Z", + "deposit_end_time": "2022-03-30T11:50:20.819676256Z", + "total_deposit": [ + { + "denom": "stake", + "amount": "10000000010" + } + ], + "voting_start_time": "2022-03-28T14:25:26.644857113Z", + "voting_end_time": "2022-03-30T14:25:26.644857113Z" + } +} +``` + +Using v1: + +```bash +/cosmos/gov/v1/proposals/{proposal_id} +``` + +Example: + +```bash +curl localhost:1317/cosmos/gov/v1/proposals/1 +``` + +Example Output: + +```bash +{ + "proposal": { + "id": "1", + "messages": [ + { + "@type": "/cosmos.bank.v1beta1.MsgSend", + "from_address": "cosmos1..", + "to_address": "cosmos1..", + "amount": [ + { + "denom": "stake", + "amount": "10" + } + ] + } + ], + "status": "PROPOSAL_STATUS_VOTING_PERIOD", + "final_tally_result": { + "yes_count": "0", + "abstain_count": "0", + "no_count": "0", + "no_with_veto_count": "0" + }, + "submit_time": "2022-03-28T11:50:20.819676256Z", + "deposit_end_time": "2022-03-30T11:50:20.819676256Z", + "total_deposit": [ + { + "denom": "stake", + "amount": "10000000" + } + ], + "voting_start_time": "2022-03-28T14:25:26.644857113Z", + "voting_end_time": "2022-03-30T14:25:26.644857113Z", + "metadata": "AQ==" + } +} +``` + +### proposals + +The `proposals` endpoint also allows users to query all proposals with optional filters. + +Using legacy v1beta1: + +```bash +/cosmos/gov/v1beta1/proposals +``` + +Example: + +```bash +curl localhost:1317/cosmos/gov/v1beta1/proposals +``` + +Example Output: + +```bash +{ + "proposals": [ + { + "proposal_id": "1", + "content": null, + "status": "PROPOSAL_STATUS_VOTING_PERIOD", + "final_tally_result": { + "yes": "0", + "abstain": "0", + "no": "0", + "no_with_veto": "0" + }, + "submit_time": "2022-03-28T11:50:20.819676256Z", + "deposit_end_time": "2022-03-30T11:50:20.819676256Z", + "total_deposit": [ + { + "denom": "stake", + "amount": "10000000" + } + ], + "voting_start_time": "2022-03-28T14:25:26.644857113Z", + "voting_end_time": "2022-03-30T14:25:26.644857113Z" + }, + { + "proposal_id": "2", + "content": null, + "status": "PROPOSAL_STATUS_DEPOSIT_PERIOD", + "final_tally_result": { + "yes": "0", + "abstain": "0", + "no": "0", + "no_with_veto": "0" + }, + "submit_time": "2022-03-28T14:02:41.165025015Z", + "deposit_end_time": "2022-03-30T14:02:41.165025015Z", + "total_deposit": [ + { + "denom": "stake", + "amount": "10" + } + ], + "voting_start_time": "0001-01-01T00:00:00Z", + "voting_end_time": "0001-01-01T00:00:00Z" + } + ], + "pagination": { + "next_key": null, + "total": "2" + } +} +``` + +Using v1: + +```bash +/cosmos/gov/v1/proposals +``` + +Example: + +```bash +curl localhost:1317/cosmos/gov/v1/proposals +``` + +Example Output: + +```bash +{ + "proposals": [ + { + "id": "1", + "messages": [ + { + "@type": "/cosmos.bank.v1beta1.MsgSend", + "from_address": "cosmos1..", + "to_address": "cosmos1..", + "amount": [ + { + "denom": "stake", + "amount": "10" + } + ] + } + ], + "status": "PROPOSAL_STATUS_VOTING_PERIOD", + "final_tally_result": { + "yes_count": "0", + "abstain_count": "0", + "no_count": "0", + "no_with_veto_count": "0" + }, + "submit_time": "2022-03-28T11:50:20.819676256Z", + "deposit_end_time": "2022-03-30T11:50:20.819676256Z", + "total_deposit": [ + { + "denom": "stake", + "amount": "10000000010" + } + ], + "voting_start_time": "2022-03-28T14:25:26.644857113Z", + "voting_end_time": "2022-03-30T14:25:26.644857113Z", + "metadata": "AQ==" + }, + { + "id": "2", + "messages": [ + { + "@type": "/cosmos.bank.v1beta1.MsgSend", + "from_address": "cosmos1..", + "to_address": "cosmos1..", + "amount": [ + { + "denom": "stake", + "amount": "10" + } + ] + } + ], + "status": "PROPOSAL_STATUS_DEPOSIT_PERIOD", + "final_tally_result": { + "yes_count": "0", + "abstain_count": "0", + "no_count": "0", + "no_with_veto_count": "0" + }, + "submit_time": "2022-03-28T14:02:41.165025015Z", + "deposit_end_time": "2022-03-30T14:02:41.165025015Z", + "total_deposit": [ + { + "denom": "stake", + "amount": "10" + } + ], + "voting_start_time": null, + "voting_end_time": null, + "metadata": "AQ==" + } + ], + "pagination": { + "next_key": null, + "total": "2" + } +} +``` + +### voter vote + +The `votes` endpoint allows users to query a vote for a given proposal. + +Using legacy v1beta1: + +```bash +/cosmos/gov/v1beta1/proposals/{proposal_id}/votes/{voter} +``` + +Example: + +```bash +curl localhost:1317/cosmos/gov/v1beta1/proposals/1/votes/cosmos1.. +``` + +Example Output: + +```bash +{ + "vote": { + "proposal_id": "1", + "voter": "cosmos1..", + "option": "VOTE_OPTION_YES", + "options": [ + { + "option": "VOTE_OPTION_YES", + "weight": "1.000000000000000000" + } + ] + } +} +``` + +Using v1: + +```bash +/cosmos/gov/v1/proposals/{proposal_id}/votes/{voter} +``` + +Example: + +```bash +curl localhost:1317/cosmos/gov/v1/proposals/1/votes/cosmos1.. +``` + +Example Output: + +```bash +{ + "vote": { + "proposal_id": "1", + "voter": "cosmos1..", + "options": [ + { + "option": "VOTE_OPTION_YES", + "weight": "1.000000000000000000" + } + ], + "metadata": "" + } +} +``` + +### votes + +The `votes` endpoint allows users to query all votes for a given proposal. + +Using legacy v1beta1: + +```bash +/cosmos/gov/v1beta1/proposals/{proposal_id}/votes +``` + +Example: + +```bash +curl localhost:1317/cosmos/gov/v1beta1/proposals/1/votes +``` + +Example Output: + +```bash +{ + "votes": [ + { + "proposal_id": "1", + "voter": "cosmos1..", + "option": "VOTE_OPTION_YES", + "options": [ + { + "option": "VOTE_OPTION_YES", + "weight": "1.000000000000000000" + } + ] + } + ], + "pagination": { + "next_key": null, + "total": "1" + } +} +``` + +Using v1: + +```bash +/cosmos/gov/v1/proposals/{proposal_id}/votes +``` + +Example: + +```bash +curl localhost:1317/cosmos/gov/v1/proposals/1/votes +``` + +Example Output: + +```bash +{ + "votes": [ + { + "proposal_id": "1", + "voter": "cosmos1..", + "options": [ + { + "option": "VOTE_OPTION_YES", + "weight": "1.000000000000000000" + } + ], + "metadata": "" + } + ], + "pagination": { + "next_key": null, + "total": "1" + } +} +``` + +### params + +The `params` endpoint allows users to query all parameters for the `gov` module. + + + +Using legacy v1beta1: + +```bash +/cosmos/gov/v1beta1/params/{params_type} +``` + +Example: + +```bash +curl localhost:1317/cosmos/gov/v1beta1/params/voting +``` + +Example Output: + +```bash +{ + "voting_params": { + "voting_period": "172800s" + }, + "deposit_params": { + "min_deposit": [ + ], + "max_deposit_period": "0s" + }, + "tally_params": { + "quorum": "0.000000000000000000", + "threshold": "0.000000000000000000", + "veto_threshold": "0.000000000000000000" + } +} +``` + +Using v1: + +```bash +/cosmos/gov/v1/params/{params_type} +``` + +Example: + +```bash +curl localhost:1317/cosmos/gov/v1/params/voting +``` + +Example Output: + +```bash +{ + "voting_params": { + "voting_period": "172800s" + }, + "deposit_params": { + "min_deposit": [ + ], + "max_deposit_period": "0s" + }, + "tally_params": { + "quorum": "0.000000000000000000", + "threshold": "0.000000000000000000", + "veto_threshold": "0.000000000000000000" + } +} +``` + +### deposits + +The `deposits` endpoint allows users to query a deposit for a given proposal from a given depositor. + +Using legacy v1beta1: + +```bash +/cosmos/gov/v1beta1/proposals/{proposal_id}/deposits/{depositor} +``` + +Example: + +```bash +curl localhost:1317/cosmos/gov/v1beta1/proposals/1/deposits/cosmos1.. +``` + +Example Output: + +```bash +{ + "deposit": { + "proposal_id": "1", + "depositor": "cosmos1..", + "amount": [ + { + "denom": "stake", + "amount": "10000000" + } + ] + } +} +``` + +Using v1: + +```bash +/cosmos/gov/v1/proposals/{proposal_id}/deposits/{depositor} +``` + +Example: + +```bash +curl localhost:1317/cosmos/gov/v1/proposals/1/deposits/cosmos1.. +``` + +Example Output: + +```bash +{ + "deposit": { + "proposal_id": "1", + "depositor": "cosmos1..", + "amount": [ + { + "denom": "stake", + "amount": "10000000" + } + ] + } +} +``` + +### proposal deposits + +The `deposits` endpoint allows users to query all deposits for a given proposal. + +Using legacy v1beta1: + +```bash +/cosmos/gov/v1beta1/proposals/{proposal_id}/deposits +``` + +Example: + +```bash +curl localhost:1317/cosmos/gov/v1beta1/proposals/1/deposits +``` + +Example Output: + +```bash +{ + "deposits": [ + { + "proposal_id": "1", + "depositor": "cosmos1..", + "amount": [ + { + "denom": "stake", + "amount": "10000000" + } + ] + } + ], + "pagination": { + "next_key": null, + "total": "1" + } +} +``` + +Using v1: + +```bash +/cosmos/gov/v1/proposals/{proposal_id}/deposits +``` + +Example: + +```bash +curl localhost:1317/cosmos/gov/v1/proposals/1/deposits +``` + +Example Output: + +```bash +{ + "deposits": [ + { + "proposal_id": "1", + "depositor": "cosmos1..", + "amount": [ + { + "denom": "stake", + "amount": "10000000" + } + ] + } + ], + "pagination": { + "next_key": null, + "total": "1" + } +} +``` + +### tally + +The `tally` endpoint allows users to query the tally of a given proposal. + +Using legacy v1beta1: + +```bash +/cosmos/gov/v1beta1/proposals/{proposal_id}/tally +``` + +Example: + +```bash +curl localhost:1317/cosmos/gov/v1beta1/proposals/1/tally +``` + +Example Output: + +```bash +{ + "tally": { + "yes": "1000000", + "abstain": "0", + "no": "0", + "no_with_veto": "0" + } +} +``` + +Using v1: + +```bash +/cosmos/gov/v1/proposals/{proposal_id}/tally +``` + +Example: + +```bash +curl localhost:1317/cosmos/gov/v1/proposals/1/tally +``` + +Example Output: + +```bash +{ + "tally": { + "yes": "1000000", + "abstain": "0", + "no": "0", + "no_with_veto": "0" + } +} +``` diff --git a/versioned_docs/version-0.46/integrate/modules/gov/08_metadata.md b/versioned_docs/version-0.46/integrate/modules/gov/08_metadata.md new file mode 100644 index 000000000..f5a0b3943 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/gov/08_metadata.md @@ -0,0 +1,32 @@ + + +# Metadata + +The gov module has two locations for metadata where users can provide further context about the on-chain actions they are taking. By default all metadata fields have a 255 character length field where metadata can be stored in json format, either on-chain or off-chain depending on the amount of data required. Here we provide a recommendation for the json structure and where the data should be stored. There are two important factors in making these recommendations. First, that the gov and group modules are consistent with one another, note the number of proposals made by all groups may be quite large. Second, that client applications such as block explorers and governance interfaces have confidence in the consistency of metadata structure accross chains. + +## Proposal + +Location: off-chain as json object stored on IPFS (mirrors [group proposal](../../group/spec/06_metadata.md#proposal)) + +```json +{ + "title": "", + "authors": "", + "summary": "", + "details": "", + "proposal_forum_url": "", + "vote_option_context": "", +} +``` + +## Vote + +Location: on-chain as json within 255 character limit (mirrors [group vote](../../group/spec/06_metadata.md#vote)) + +```json +{ + "justification": "", +} +``` diff --git a/versioned_docs/version-0.46/integrate/modules/gov/README.md b/versioned_docs/version-0.46/integrate/modules/gov/README.md new file mode 100644 index 000000000..3a5a2decf --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/gov/README.md @@ -0,0 +1,65 @@ + + +# `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) + * [Deposit](01_concepts.md#Deposit) + * [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) + * [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)** + * [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)** + * [CLI](07_client.md#cli) + * [gRPC](07_client.md#grpc) + * [REST](07_client.md#rest) +8. **[Metadata](08_metadata.md)** + * [Proposal](08_metadata.md#proposal) + * [Vote](08_metadata.md#vote) diff --git a/versioned_docs/version-0.46/integrate/modules/mint/01_concepts.md b/versioned_docs/version-0.46/integrate/modules/mint/01_concepts.md new file mode 100644 index 000000000..11669404d --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/mint/01_concepts.md @@ -0,0 +1,28 @@ + + +# 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. + +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 diff --git a/versioned_docs/version-0.46/integrate/modules/mint/02_state.md b/versioned_docs/version-0.46/integrate/modules/mint/02_state.md new file mode 100644 index 000000000..2fa04b1ef --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/mint/02_state.md @@ -0,0 +1,21 @@ + + +# State + +## Minter + +The minter is a space for holding current inflation information. + +* Minter: `0x00 -> ProtocolBuffer(minter)` + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/mint/v1beta1/mint.proto#L9-L23 + +## Params + +Minting params are held in the global params store. + +* Params: `mint/params -> legacy_amino(params)` + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/mint/v1beta1/mint.proto#L25-L57 diff --git a/versioned_docs/version-0.46/integrate/modules/mint/03_begin_block.md b/versioned_docs/version-0.46/integrate/modules/mint/03_begin_block.md new file mode 100644 index 000000000..67bd7d8a8 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/mint/03_begin_block.md @@ -0,0 +1,66 @@ + + +# Begin-Block + +Minting parameters are recalculated and inflation +paid at the beginning of each block. + +## Inflation rate calculation + +Inflation rate is calculated using an "inflation calculation function" that's +passed to the `NewAppModule` function. If no function is passed, then the SDK's +default inflation function will be used (`NextInflationRate`). In case a custom +inflation calculation logic is needed, this can be achieved by defining and +passing a function that matches `InflationCalculationFn`'s signature. + +```go +type InflationCalculationFn func(ctx sdk.Context, minter Minter, params Params, bondedRatio sdk.Dec) sdk.Dec +``` + +### 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%. + +```go +NextInflationRate(params Params, bondedRatio sdk.Dec) (inflation sdk.Dec) { + inflationRateChangePerYear = (1 - bondedRatio/params.GoalBonded) * params.InflationRateChange + inflationRateChange = inflationRateChangePerYear/blocksPerYr + + // increase the new annual inflation for this next cycle + inflation += inflationRateChange + if inflation > params.InflationMax { + inflation = params.InflationMax + } + if inflation < params.InflationMin { + inflation = params.InflationMin + } + + return inflation +} +``` + +## NextAnnualProvisions + +Calculate the annual provisions based on current total supply and inflation +rate. This parameter is calculated once per block. + +```go +NextAnnualProvisions(params Params, totalSupply sdk.Dec) (provisions sdk.Dec) { + return Inflation * totalSupply +``` + +## 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`. + +```go +BlockProvision(params Params) sdk.Coin { + provisionAmt = AnnualProvisions/ params.BlocksPerYear + return sdk.NewCoin(params.MintDenom, provisionAmt.Truncate()) +``` diff --git a/versioned_docs/version-0.46/integrate/modules/mint/04_params.md b/versioned_docs/version-0.46/integrate/modules/mint/04_params.md new file mode 100644 index 000000000..ed18e5557 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/mint/04_params.md @@ -0,0 +1,16 @@ + + +# Parameters + +The minting module contains the following parameters: + +| Key | Type | Example | +|---------------------|-----------------|------------------------| +| MintDenom | string | "uatom" | +| InflationRateChange | string (dec) | "0.130000000000000000" | +| InflationMax | string (dec) | "0.200000000000000000" | +| InflationMin | string (dec) | "0.070000000000000000" | +| GoalBonded | string (dec) | "0.670000000000000000" | +| BlocksPerYear | string (uint64) | "6311520" | diff --git a/versioned_docs/version-0.46/integrate/modules/mint/05_events.md b/versioned_docs/version-0.46/integrate/modules/mint/05_events.md new file mode 100644 index 000000000..f6130a3b9 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/mint/05_events.md @@ -0,0 +1,16 @@ + + +# Events + +The minting module emits the following events: + +## BeginBlocker + +| Type | Attribute Key | Attribute Value | +|------|-------------------|--------------------| +| mint | bonded_ratio | {bondedRatio} | +| mint | inflation | {inflation} | +| mint | annual_provisions | {annualProvisions} | +| mint | amount | {amount} | diff --git a/versioned_docs/version-0.46/integrate/modules/mint/06_client.md b/versioned_docs/version-0.46/integrate/modules/mint/06_client.md new file mode 100644 index 000000000..a79063a99 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/mint/06_client.md @@ -0,0 +1,224 @@ + + +# Client + +## CLI + +A user can query and interact with the `mint` module using the CLI. + +### Query + +The `query` commands allow users to query `mint` state. + +```sh +simd query mint --help +``` + +#### annual-provisions + +The `annual-provisions` command allow users to query the current minting annual provisions value + +```sh +simd query mint annual-provisions [flags] +``` + +Example: + +```sh +simd query mint annual-provisions +``` + +Example Output: + +```sh +22268504368893.612100895088410693 +``` + +#### inflation + +The `inflation` command allow users to query the current minting inflation value + +```sh +simd query mint inflation [flags] +``` + +Example: + +```sh +simd query mint inflation +``` + +Example Output: + +```sh +0.199200302563256955 +``` + +#### params + +The `params` command allow users to query the current minting parameters + +```sh +simd query mint params [flags] +``` + +Example: + +```yml +blocks_per_year: "4360000" +goal_bonded: "0.670000000000000000" +inflation_max: "0.200000000000000000" +inflation_min: "0.070000000000000000" +inflation_rate_change: "0.130000000000000000" +mint_denom: stake +``` + +## gRPC + +A user can query the `mint` module using gRPC endpoints. + +### AnnualProvisions + +The `AnnualProvisions` endpoint allow users to query the current minting annual provisions value + +```sh +/cosmos.mint.v1beta1.Query/AnnualProvisions +``` + +Example: + +```sh +grpcurl -plaintext localhost:9090 cosmos.mint.v1beta1.Query/AnnualProvisions +``` + +Example Output: + +```json +{ + "annualProvisions": "1432452520532626265712995618" +} +``` + +### Inflation + +The `Inflation` endpoint allow users to query the current minting inflation value + +```sh +/cosmos.mint.v1beta1.Query/Inflation +``` + +Example: + +```sh +grpcurl -plaintext localhost:9090 cosmos.mint.v1beta1.Query/Inflation +``` + +Example Output: + +```json +{ + "inflation": "130197115720711261" +} +``` + +### Params + +The `Params` endpoint allow users to query the current minting parameters + +```sh +/cosmos.mint.v1beta1.Query/Params +``` + +Example: + +```sh +grpcurl -plaintext localhost:9090 cosmos.mint.v1beta1.Query/Params +``` + +Example Output: + +```json +{ + "params": { + "mintDenom": "stake", + "inflationRateChange": "130000000000000000", + "inflationMax": "200000000000000000", + "inflationMin": "70000000000000000", + "goalBonded": "670000000000000000", + "blocksPerYear": "6311520" + } +} +``` + +## REST + +A user can query the `mint` module using REST endpoints. + +### annual-provisions + +```sh +/cosmos/mint/v1beta1/annual_provisions +``` + +Example: + +```sh +curl "localhost:1317/cosmos/mint/v1beta1/annual_provisions" +``` + +Example Output: + +```json +{ + "annualProvisions": "1432452520532626265712995618" +} +``` + +### inflation + +```sh +/cosmos/mint/v1beta1/inflation +``` + +Example: + +```sh +curl "localhost:1317/cosmos/mint/v1beta1/inflation" +``` + +Example Output: + +```json +{ + "inflation": "130197115720711261" +} +``` + +### params + +```sh +/cosmos/mint/v1beta1/params +``` + +Example: + +```sh +curl "localhost:1317/cosmos/mint/v1beta1/params" +``` + +Example Output: + +```json +{ + "params": { + "mintDenom": "stake", + "inflationRateChange": "130000000000000000", + "inflationMax": "200000000000000000", + "inflationMin": "70000000000000000", + "goalBonded": "670000000000000000", + "blocksPerYear": "6311520" + } +} +``` diff --git a/versioned_docs/version-0.46/integrate/modules/mint/README.md b/versioned_docs/version-0.46/integrate/modules/mint/README.md new file mode 100644 index 000000000..400d723b2 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/mint/README.md @@ -0,0 +1,26 @@ + + +# `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) diff --git a/versioned_docs/version-0.46/integrate/modules/params/01_keeper.md b/versioned_docs/version-0.46/integrate/modules/params/01_keeper.md new file mode 100644 index 000000000..fa97ec5b3 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/params/01_keeper.md @@ -0,0 +1,19 @@ + + +# 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`. + +Example: + +```go +type ExampleKeeper struct { + paramSpace paramtypes.Subspace +} + +func (k ExampleKeeper) SetParams(ctx sdk.Context, params types.Params) { + k.paramSpace.SetParamSet(ctx, ¶ms) +} +``` diff --git a/versioned_docs/version-0.46/integrate/modules/params/02_subspace.md b/versioned_docs/version-0.46/integrate/modules/params/02_subspace.md new file mode 100644 index 000000000..2eaa391a2 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/params/02_subspace.md @@ -0,0 +1,38 @@ + + +# 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. + +## 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. + +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. + +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. + +Only primary keys have to be registered on the `KeyTable`. Subkeys inherit the +attribute of the primary key. + +## ParamSet + +Modules often define parameters as a proto message. The generated struct can implement +`ParamSet` interface to be used with the following methods: + +* `KeyTable.RegisterParamSet()`: registers all parameters in the struct +* `Subspace.{Get, Set}ParamSet()`: Get to & Set from the struct + +The implementor should be a pointer in order to use `GetParamSet()`. diff --git a/versioned_docs/version-0.46/integrate/modules/params/README.md b/versioned_docs/version-0.46/integrate/modules/params/README.md new file mode 100644 index 000000000..6f0387a01 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/params/README.md @@ -0,0 +1,29 @@ + + +# `params` + +## Abstract + +Package params provides a globally available parameter store. + +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. + +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. + +The following contents explains how to use params module for master and user modules. + +## 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) diff --git a/versioned_docs/version-0.46/integrate/modules/slashing/01_concepts.md b/versioned_docs/version-0.46/integrate/modules/slashing/01_concepts.md new file mode 100644 index 000000000..ea7c6b319 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/slashing/01_concepts.md @@ -0,0 +1,57 @@ + + +# 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. + +For each of these validators we keep a `ValidatorSigningInfo` record that contains +information partaining to validator's liveness and other infraction related +attributes. + +## 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. + +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: + +**Definitions**: + +_[_ : timeline start +_]_ : timeline end +_Cn_ : infraction `n` committed +_Dn_ : infraction `n` discovered +_Vb_ : validator bonded +_Vu_ : validator unbonded + +### Single Double Sign Infraction + +\[----------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/versioned_docs/version-0.46/integrate/modules/slashing/02_state.md b/versioned_docs/version-0.46/integrate/modules/slashing/02_state.md new file mode 100644 index 000000000..50aa0e141 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/slashing/02_state.md @@ -0,0 +1,51 @@ + + +# 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. + +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)). + +```go +type LastCommitInfo struct { + Round int32 + Votes []VoteInfo +} +``` + +Validators are penalized for failing to be included in the `LastCommitInfo` for some +number of blocks by being automatically jailed, potentially slashed, and unbonded. + +Information about validator's liveness activity is tracked through `ValidatorSigningInfo`. +It is indexed in the store as follows: + +* ValidatorSigningInfo: `0x01 | ConsAddrLen (1 byte) | ConsAddress -> ProtocolBuffer(ValSigningInfo)` +* MissedBlocksBitArray: `0x02 | ConsAddrLen (1 byte) | ConsAddress | LittleEndianUint64(signArrayIndex) -> VarInt(didMiss)` (varint is a number encoding format) + +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). + +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. + +The information stored for tracking validator liveness is as follows: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/slashing/v1beta1/slashing.proto#L12-L33 diff --git a/versioned_docs/version-0.46/integrate/modules/slashing/03_messages.md b/versioned_docs/version-0.46/integrate/modules/slashing/03_messages.md new file mode 100644 index 000000000..874931579 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/slashing/03_messages.md @@ -0,0 +1,51 @@ + + +# Messages + +In this section we describe the processing of messages for the `slashing` module. + +## 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`: + +```protobuf +// MsgUnjail is an sdk.Msg used for unjailing a jailed validator, thus returning +// them into the bonded validator set, so they can begin receiving provisions +// and rewards again. +message MsgUnjail { + string validator_addr = 1; +} +``` + +Below is a pseudocode of the `MsgSrv/Unjail` RPC: + +```go +unjail(tx MsgUnjail) + validator = getValidator(tx.ValidatorAddr) + if validator == nil + fail with "No validator found" + + if getSelfDelegation(validator) == 0 + fail with "validator must self delegate before unjailing" + + if !validator.Jailed + fail with "Validator not jailed, cannot unjail" + + info = GetValidatorSigningInfo(operator) + if info.Tombstoned + fail with "Tombstoned validator cannot be unjailed" + if block time < info.JailedUntil + fail with "Validator still jailed, cannot unjail until period has expired" + + validator.Jailed = false + setValidator(validator) + + 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. diff --git a/versioned_docs/version-0.46/integrate/modules/slashing/04_begin_block.md b/versioned_docs/version-0.46/integrate/modules/slashing/04_begin_block.md new file mode 100644 index 000000000..99572c419 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/slashing/04_begin_block.md @@ -0,0 +1,98 @@ + + +# 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. + +```go +height := block.Height + +for vote in block.LastCommitInfo.Votes { + signInfo := GetValidatorSigningInfo(vote.Validator.Address) + + // This is a relative index, so we counts blocks the validator SHOULD have + // signed. We use the 0-value default signing info if not present, except for + // start height. + index := signInfo.IndexOffset % SignedBlocksWindow() + signInfo.IndexOffset++ + + // Update MissedBlocksBitArray and MissedBlocksCounter. The MissedBlocksCounter + // just tracks the sum of MissedBlocksBitArray. That way we avoid needing to + // read/write the whole array each time. + missedPrevious := GetValidatorMissedBlockBitArray(vote.Validator.Address, index) + missed := !signed + + switch { + case !missedPrevious && missed: + // array index has changed from not missed to missed, increment counter + SetValidatorMissedBlockBitArray(vote.Validator.Address, index, true) + signInfo.MissedBlocksCounter++ + + case missedPrevious && !missed: + // array index has changed from missed to not missed, decrement counter + SetValidatorMissedBlockBitArray(vote.Validator.Address, index, false) + signInfo.MissedBlocksCounter-- + + default: + // array index at this index has not changed; no need to update counter + } + + if missed { + // emit events... + } + + minHeight := signInfo.StartHeight + SignedBlocksWindow() + maxMissed := SignedBlocksWindow() - MinSignedPerWindow() + + // If we are past the minimum height and the validator has missed too many + // jail and slash them. + if height > minHeight && signInfo.MissedBlocksCounter > maxMissed { + validator := ValidatorByConsAddr(vote.Validator.Address) + + // emit events... + + // We need to retrieve the stake distribution which signed the block, so we + // subtract ValidatorUpdateDelay from the block height, and subtract an + // additional 1 since this is the LastCommit. + // + // Note, that this CAN result in a negative "distributionHeight" up to + // -ValidatorUpdateDelay-1, i.e. at the end of the pre-genesis block (none) = at the beginning of the genesis block. + // That's fine since this is just used to filter unbonding delegations & redelegations. + distributionHeight := height - sdk.ValidatorUpdateDelay - 1 + + Slash(vote.Validator.Address, distributionHeight, vote.Validator.Power, SlashFractionDowntime()) + Jail(vote.Validator.Address) + + signInfo.JailedUntil = block.Time.Add(DowntimeJailDuration()) + + // We need to reset the counter & array so that the validator won't be + // immediately slashed for downtime upon rebonding. + signInfo.MissedBlocksCounter = 0 + signInfo.IndexOffset = 0 + ClearValidatorMissedBlockBitArray(vote.Validator.Address) + } + + SetValidatorSigningInfo(vote.Validator.Address, signInfo) +} +``` diff --git a/versioned_docs/version-0.46/integrate/modules/slashing/05_hooks.md b/versioned_docs/version-0.46/integrate/modules/slashing/05_hooks.md new file mode 100644 index 000000000..a83968942 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/slashing/05_hooks.md @@ -0,0 +1,45 @@ + + +# Hooks + +This section contains a description of the module's `hooks`. Hooks are operations that are executed automatically when events are raised. + +## 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. + +The following hooks impact the slashing state: + +* `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. + +## 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. + +If the validator was out of the validator set and gets bonded again, its new bonded height is set. + +```go +onValidatorBonded(address sdk.ValAddress) + + signingInfo, found = GetValidatorSigningInfo(address) + if !found { + signingInfo = ValidatorSigningInfo { + StartHeight : CurrentHeight, + IndexOffset : 0, + JailedUntil : time.Unix(0, 0), + Tombstone : false, + MissedBloskCounter : 0 + } else { + signingInfo.StartHeight = CurrentHeight + } + + setValidatorSigningInfo(signingInfo) + } + + return +``` diff --git a/versioned_docs/version-0.46/integrate/modules/slashing/06_events.md b/versioned_docs/version-0.46/integrate/modules/slashing/06_events.md new file mode 100644 index 000000000..c7dbf5723 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/slashing/06_events.md @@ -0,0 +1,46 @@ + + +# Events + +The slashing module emits the following events: + +## MsgServer + +### MsgUnjail + +| Type | Attribute Key | Attribute Value | +| ------- | ------------- | ------------------ | +| message | module | slashing | +| message | sender | {validatorAddress} | + +## Keeper + +## BeginBlocker: HandleValidatorSignature + +| Type | Attribute Key | Attribute Value | +| ----- | ------------- | --------------------------- | +| slash | address | {validatorConsensusAddress} | +| slash | power | {validatorPower} | +| slash | reason | {slashReason} | +| slash | jailed [0] | {validatorConsensusAddress} | +| slash | burned coins | {sdk.Int} | + +* [0] Only included if the validator is jailed. + +| Type | Attribute Key | Attribute Value | +| -------- | ------------- | --------------------------- | +| liveness | address | {validatorConsensusAddress} | +| liveness | missed_blocks | {missedBlocksCounter} | +| liveness | height | {blockHeight} | + +### Slash + +* same as `"slash"` event from `HandleValidatorSignature`, but without the `jailed` attribute. + +### Jail + +| Type | Attribute Key | Attribute Value | +| ----- | ------------- | ------------------ | +| slash | jailed | {validatorAddress} | diff --git a/versioned_docs/version-0.46/integrate/modules/slashing/07_tombstone.md b/versioned_docs/version-0.46/integrate/modules/slashing/07_tombstone.md new file mode 100644 index 000000000..ab06c9456 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/slashing/07_tombstone.md @@ -0,0 +1,127 @@ + + +# 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). diff --git a/versioned_docs/version-0.46/integrate/modules/slashing/08_params.md b/versioned_docs/version-0.46/integrate/modules/slashing/08_params.md new file mode 100644 index 000000000..defed189a --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/slashing/08_params.md @@ -0,0 +1,15 @@ + + +# Parameters + +The slashing module contains the following parameters: + +| Key | Type | Example | +| ----------------------- | -------------- | ---------------------- | +| SignedBlocksWindow | string (int64) | "100" | +| MinSignedPerWindow | string (dec) | "0.500000000000000000" | +| DowntimeJailDuration | string (ns) | "600000000000" | +| SlashFractionDoubleSign | string (dec) | "0.050000000000000000" | +| SlashFractionDowntime | string (dec) | "0.010000000000000000" | diff --git a/versioned_docs/version-0.46/integrate/modules/slashing/09_client.md b/versioned_docs/version-0.46/integrate/modules/slashing/09_client.md new file mode 100644 index 000000000..11d82961e --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/slashing/09_client.md @@ -0,0 +1,294 @@ + + +# CLI + +A user can query and interact with the `slashing` module using the CLI. + +## Query + +The `query` commands allow users to query `slashing` state. + +```sh +simd query slashing --help +``` + +### params + +The `params` command allows users to query genesis parameters for the slashing module. + +```sh +simd query slashing params [flags] +``` + +Example: + +```sh +simd query slashing params +``` + +Example Output: + +```yml +downtime_jail_duration: 600s +min_signed_per_window: "0.500000000000000000" +signed_blocks_window: "100" +slash_fraction_double_sign: "0.050000000000000000" +slash_fraction_downtime: "0.010000000000000000" +``` + +### signing-info + +The `signing-info` command allows users to query signing-info of the validator using consensus public key. + +```sh +simd query slashing signing-infos [flags] +``` + +Example: + +```sh +simd query slashing signing-info '{"@type":"/cosmos.crypto.ed25519.PubKey","key":"Auxs3865HpB/EfssYOzfqNhEJjzys6jD5B6tPgC8="}' + +``` + +Example Output: + +```yml +address: cosmosvalcons1nrqsld3aw6lh6t082frdqc84uwxn0t958c +index_offset: "2068" +jailed_until: "1970-01-01T00:00:00Z" +missed_blocks_counter: "0" +start_height: "0" +tombstoned: false +``` + +### signing-infos + +The `signing-infos` command allows users to query signing infos of all validators. + +```sh +simd query slashing signing-infos [flags] +``` + +Example: + +```sh +simd query slashing signing-infos +``` + +Example Output: + +```yml +info: +- address: cosmosvalcons1nrqsld3aw6lh6t082frdqc84uwxn0t958c + index_offset: "2075" + jailed_until: "1970-01-01T00:00:00Z" + missed_blocks_counter: "0" + start_height: "0" + tombstoned: false +pagination: + next_key: null + total: "0" +``` + +## Transactions + +The `tx` commands allow users to interact with the `slashing` module. + +```bash +simd tx slashing --help +``` + +### unjail + +The `unjail` command allows users to unjail a validator previously jailed for downtime. + +```bash + simd tx slashing unjail --from mykey [flags] +``` + +Example: + +```bash +simd tx slashing unjail --from mykey +``` + +## gRPC + +A user can query the `slashing` module using gRPC endpoints. + +### Params + +The `Params` endpoint allows users to query the parameters of slashing module. + +```sh +cosmos.slashing.v1beta1.Query/Params +``` + +Example: + +```sh +grpcurl -plaintext localhost:9090 cosmos.slashing.v1beta1.Query/Params +``` + +Example Output: + +```json +{ + "params": { + "signedBlocksWindow": "100", + "minSignedPerWindow": "NTAwMDAwMDAwMDAwMDAwMDAw", + "downtimeJailDuration": "600s", + "slashFractionDoubleSign": "NTAwMDAwMDAwMDAwMDAwMDA=", + "slashFractionDowntime": "MTAwMDAwMDAwMDAwMDAwMDA=" + } +} +``` + +### SigningInfo + +The SigningInfo queries the signing info of given cons address. + +```sh +cosmos.slashing.v1beta1.Query/SigningInfo +``` + +Example: + +```sh +grpcurl -plaintext -d '{"cons_address":"cosmosvalcons1nrqsld3aw6lh6t082frdqc84uwxn0t958c"}' localhost:9090 cosmos.slashing.v1beta1.Query/SigningInfo +``` + +Example Output: + +```json +{ + "valSigningInfo": { + "address": "cosmosvalcons1nrqsld3aw6lh6t082frdqc84uwxn0t958c", + "indexOffset": "3493", + "jailedUntil": "1970-01-01T00:00:00Z" + } +} +``` + +### SigningInfos + +The SigningInfos queries signing info of all validators. + +```sh +cosmos.slashing.v1beta1.Query/SigningInfos +``` + +Example: + +```sh +grpcurl -plaintext localhost:9090 cosmos.slashing.v1beta1.Query/SigningInfos +``` + +Example Output: + +```json +{ + "info": [ + { + "address": "cosmosvalcons1nrqslkwd3pz096lh6t082frdqc84uwxn0t958c", + "indexOffset": "2467", + "jailedUntil": "1970-01-01T00:00:00Z" + } + ], + "pagination": { + "total": "1" + } +} +``` + +## REST + +A user can query the `slashing` module using REST endpoints. + +### Params + +```sh +/cosmos/slashing/v1beta1/params +``` + +Example: + +```sh +curl "localhost:1317/cosmos/slashing/v1beta1/params" +``` + +Example Output: + +```json +{ + "params": { + "signed_blocks_window": "100", + "min_signed_per_window": "0.500000000000000000", + "downtime_jail_duration": "600s", + "slash_fraction_double_sign": "0.050000000000000000", + "slash_fraction_downtime": "0.010000000000000000" +} +``` + +### signing_info + +```sh +/cosmos/slashing/v1beta1/signing_infos/%s +``` + +Example: + +```sh +curl "localhost:1317/cosmos/slashing/v1beta1/signing_infos/cosmosvalcons1nrqslkwd3pz096lh6t082frdqc84uwxn0t958c" +``` + +Example Output: + +```json +{ + "val_signing_info": { + "address": "cosmosvalcons1nrqslkwd3pz096lh6t082frdqc84uwxn0t958c", + "start_height": "0", + "index_offset": "4184", + "jailed_until": "1970-01-01T00:00:00Z", + "tombstoned": false, + "missed_blocks_counter": "0" + } +} +``` + +### signing_infos + +```sh +/cosmos/slashing/v1beta1/signing_infos +``` + +Example: + +```sh +curl "localhost:1317/cosmos/slashing/v1beta1/signing_infos +``` + +Example Output: + +```json +{ + "info": [ + { + "address": "cosmosvalcons1nrqslkwd3pz096lh6t082frdqc84uwxn0t958c", + "start_height": "0", + "index_offset": "4169", + "jailed_until": "1970-01-01T00:00:00Z", + "tombstoned": false, + "missed_blocks_counter": "0" + } + ], + "pagination": { + "next_key": null, + "total": "1" + } +} +``` diff --git a/versioned_docs/version-0.46/integrate/modules/slashing/README.md b/versioned_docs/version-0.46/integrate/modules/slashing/README.md new file mode 100644 index 000000000..d1988cb96 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/slashing/README.md @@ -0,0 +1,49 @@ + + +# `x/slashing` + +## 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. + +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"). + +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. + +## 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) +5. **[05_hooks.md](05_hooks.md)** + * [Hooks](05_hooks.md#hooks) +6. **[Events](06_events.md)** + * [BeginBlocker](06_events.md#beginblocker) + * [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)** + * [CLI](09_client.md#cli) + * [gRPC](09_client.md#grpc) + * [REST](09_client.md#rest) diff --git a/versioned_docs/version-0.46/integrate/modules/staking/01_state.md b/versioned_docs/version-0.46/integrate/modules/staking/01_state.md new file mode 100644 index 000000000..e0ca517c0 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/staking/01_state.md @@ -0,0 +1,215 @@ + + +# 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: `0x12 -> ProtocolBuffer(math.Int)` + +## Params + +Params is a module-wide configuration structure that stores system parameters +and defines overall functioning of the staking module. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/staking.proto#L285-L306 + +## 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: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/staking.proto#L78-L127 + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/staking.proto#L24-L76 + +## Delegation + +Delegations are identified by combining `DelegatorAddr` (the address of the delegator) +with the `ValidatorAddr` Delegators are indexed in the store as follows: + +* Delegation: `0x31 | DelegatorAddrLen (1 byte) | DelegatorAddr | ValidatorAddrLen (1 byte) | 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.46.0-rc1/proto/cosmos/staking/v1beta1/staking.proto#L187-L205 + +### 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()` + +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: + +`Tokens per Share = 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` are indexed in the store as: + +* UnbondingDelegation: `0x32 | DelegatorAddrLen (1 byte) | DelegatorAddr | ValidatorAddrLen (1 byte) | ValidatorAddr -> ProtocolBuffer(unbondingDelegation)` +* UnbondingDelegationsFromValidator: `0x33 | ValidatorAddrLen (1 byte) | ValidatorAddr | DelegatorAddrLen (1 byte) | 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. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/staking.proto#L207-L220 + +## 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: + +* 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` + +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`. + +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`. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/staking.proto#L245-L283 + +## 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 format string +`"2006-01-02T15:04:05.000000000"`. Notably this format: + +* right pads all zeros +* drops the time zone info (uses 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` + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/staking.proto#L151-L161 + +### RedelegationQueue + +For the purpose of tracking progress of redelegations the redelegation queue is +kept. + +* RedelegationQueue: `0x42 | format(time) -> []DVVTriplet` + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/staking.proto#L168-L179 + +### ValidatorQueue + +For the purpose of tracking progress of unbonding validators the validator +queue is kept. + +* ValidatorQueueTime: `0x43 | format(time) -> []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`. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/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. diff --git a/versioned_docs/version-0.46/integrate/modules/staking/02_state_transitions.md b/versioned_docs/version-0.46/integrate/modules/staking/02_state_transitions.md new file mode 100644 index 000000000..9e9efffae --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/staking/02_state_transitions.md @@ -0,0 +1,180 @@ + + +# 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) + +## 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`. + +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`. + +### Not bonded to Bonded + +The following transition occurs when a validator's ranking in the `ValidatorPowerIndex` surpasses +that of the `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 + +### 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 + +### Unbonding to Unbonded + +A validator moves from unbonding to unbonded when the `ValidatorQueue` object +moves from bonded to unbonded + +* update the `Validator` object for this validator +* set `validator.Status` to `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: + +* set `Validator.Jailed` and update object +* if jailed delete record from `ValidatorByPowerIndex` +* if unjailed add record to `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` + +### Begin Unbonding + +As a part of the Undelegate and Complete Unbonding state transitions Unbond +Delegation may be called. + +* subtract the unbonded shares from delegator +* add the unbonded tokens to an `UnbondingDelegation` Entry +* 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. + +### Cancel an `UnbondingDelegation` Entry +When a `cancel unbond delegation` occurs both the `validator`, the `delegation` and an `UnbondingDelegationQueue` state will be updated. +* if cancel unbonding delegation amount equals to the `UnbondingDelegation` entry `balance`, then the `UnbondingDelegation` entry deleted from `UnbondingDelegationQueue`. +* if the `cancel unbonding delegation amount is less than the `UnbondingDelegation` entry balance, then the `UnbondingDelegation` entry will be updated with new balance in the `UnbondingDelegationQueue`. +* cancel `amount` is [Delegated](02_state_transitions.md#delegations) back to the original `validator`. + +### 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` + +### 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` + +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 + +## 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. + +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. + +### 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. + +## 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. + +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. + +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`. + +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`. diff --git a/versioned_docs/version-0.46/integrate/modules/staking/03_messages.md b/versioned_docs/version-0.46/integrate/modules/staking/03_messages.md new file mode 100644 index 000000000..f63c2f07f --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/staking/03_messages.md @@ -0,0 +1,175 @@ + + +# 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. + +## MsgCreateValidator + +A validator is created using the `MsgCreateValidator` message. +The validator must be created with an initial delegation from the operator. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/tx.proto#L18-L19 + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/tx.proto#L43-L65 + +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 + +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. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/tx.proto#L21-L22 + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/tx.proto#L70-L88 + +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 + +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`. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/tx.proto#L24-L26 + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/tx.proto#L93-L104 + +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 + +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. + +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. + +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](./delegation_sequence.svg) + +## MsgUndelegate + +The `MsgUndelegate` message allows delegators to undelegate their tokens from +validator. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/tx.proto#L32-L34 + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/tx.proto#L128-L139 + +This message returns a response containing the completion time of the undelegation: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/tx.proto#L128-L144 + +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` + +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. + +![Unbond sequence](./unbond_sequence.svg) + +## MsgCancelUnbondingDelegation + +The `MsgCancelUnbondingDelegation` message allows delegators to cancel the `unbondingDelegation` entry and deleagate back to a previous validator. + ++++ hhttps://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/tx.proto#L36-L40 + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/tx.proto#L146-L165 + +This message is expected to fail if: + +* the `unbondingDelegation` entry is already processed. +* the `cancel unbonding delegation` amount is greater than the `unbondingDelegation` entry balance. +* the `cancel unbonding delegation` height doesn't exists in the `unbondingDelegationQueue` of the delegator. + +When this message is processed the following actions occur: + +* if the `unbondingDelegation` Entry balance is zero + * in this condition `unbondingDelegation` entry will be removed from `unbondingDelegationQueue`. + * otherwise `unbondingDelegationQueue` will be updated with new `unbondingDelegation` entry balance and initial balance +* the validator's `DelegatorShares` and the delegation's `Shares` are both increased by the message `Amount`. + +## 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.46.0-rc1/proto/cosmos/staking/v1beta1/tx.proto#L28-L30 + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/tx.proto#L109-L121 + +This message returns a response containing the completion time of the redelegation: + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/staking/v1beta1/tx.proto#L123-L126 + +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` + +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. + +![Begin redelegation sequence](./begin_redelegation_sequence.svg) diff --git a/versioned_docs/version-0.46/integrate/modules/staking/04_begin_block.md b/versioned_docs/version-0.46/integrate/modules/staking/04_begin_block.md new file mode 100644 index 000000000..3ba615b5d --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/staking/04_begin_block.md @@ -0,0 +1,16 @@ + + +# Begin-Block + +Each abci begin block call, the historical info will get stored and pruned +according to the `HistoricalEntries` parameter. + +## Historical Info Tracking + +If the `HistoricalEntries` parameter is 0, then the `BeginBlock` performs a no-op. + +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. diff --git a/versioned_docs/version-0.46/integrate/modules/staking/05_end_block.md b/versioned_docs/version-0.46/integrate/modules/staking/05_end_block.md new file mode 100644 index 000000000..7eb014211 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/staking/05_end_block.md @@ -0,0 +1,77 @@ + + +# 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. diff --git a/versioned_docs/version-0.46/integrate/modules/staking/06_hooks.md b/versioned_docs/version-0.46/integrate/modules/staking/06_hooks.md new file mode 100644 index 000000000..18af77238 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/staking/06_hooks.md @@ -0,0 +1,27 @@ + + +# 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: + +* `AfterValidatorCreated(Context, ValAddress) error` + * called when a validator is created +* `BeforeValidatorModified(Context, ValAddress) error` + * called when a validator's state is changed +* `AfterValidatorRemoved(Context, ConsAddress, ValAddress) error` + * called when a validator is deleted +* `AfterValidatorBonded(Context, ConsAddress, ValAddress) error` + * called when a validator is bonded +* `AfterValidatorBeginUnbonding(Context, ConsAddress, ValAddress) error` + * called when a validator begins unbonding +* `BeforeDelegationCreated(Context, AccAddress, ValAddress) error` + * called when a delegation is created +* `BeforeDelegationSharesModified(Context, AccAddress, ValAddress) error` + * called when a delegation's shares are modified +* `BeforeDelegationRemoved(Context, AccAddress, ValAddress) error` + * called when a delegation is removed diff --git a/versioned_docs/version-0.46/integrate/modules/staking/07_events.md b/versioned_docs/version-0.46/integrate/modules/staking/07_events.md new file mode 100644 index 000000000..eeeb84c4b --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/staking/07_events.md @@ -0,0 +1,90 @@ + + +# Events + +The staking module emits the following events: + +## EndBlocker + +| Type | Attribute Key | Attribute Value | +| --------------------- | --------------------- | ------------------------- | +| complete_unbonding | amount | {totalUnbondingAmount} | +| complete_unbonding | validator | {validatorAddress} | +| complete_unbonding | delegator | {delegatorAddress} | +| complete_redelegation | amount | {totalRedelegationAmount} | +| complete_redelegation | source_validator | {srcValidatorAddress} | +| complete_redelegation | destination_validator | {dstValidatorAddress} | +| complete_redelegation | delegator | {delegatorAddress} | + +## Msg's + +### MsgCreateValidator + +| Type | Attribute Key | Attribute Value | +| ---------------- | ------------- | ------------------ | +| create_validator | validator | {validatorAddress} | +| create_validator | amount | {delegationAmount} | +| message | module | staking | +| message | action | create_validator | +| message | sender | {senderAddress} | + +### MsgEditValidator + +| Type | Attribute Key | Attribute Value | +| -------------- | ------------------- | ------------------- | +| edit_validator | commission_rate | {commissionRate} | +| edit_validator | min_self_delegation | {minSelfDelegation} | +| message | module | staking | +| message | action | edit_validator | +| message | sender | {senderAddress} | + +### MsgDelegate + +| Type | Attribute Key | Attribute Value | +| -------- | ------------- | ------------------ | +| delegate | validator | {validatorAddress} | +| delegate | amount | {delegationAmount} | +| message | module | staking | +| message | action | delegate | +| message | sender | {senderAddress} | + +### MsgUndelegate + +| Type | Attribute Key | Attribute Value | +| ------- | ------------------- | ------------------ | +| unbond | validator | {validatorAddress} | +| unbond | amount | {unbondAmount} | +| unbond | completion_time [0] | {completionTime} | +| message | module | staking | +| message | action | begin_unbonding | +| message | sender | {senderAddress} | + +* [0] Time is formatted in the RFC3339 standard + +### MsgCancelUnbondingDelegation + +| Type | Attribute Key | Attribute Value | +| ----------------------------- | ------------------ | ------------------------------------| +| cancel_unbonding_delegation | validator | {validatorAddress} | +| cancel_unbonding_delegation | delegator | {delegatorAddress} | +| cancel_unbonding_delegation | amount | {cancelUnbondingDelegationAmount} | +| cancel_unbonding_delegation | creation_height | {unbondingCreationHeight} | +| message | module | staking | +| message | action | cancel_unbond | +| message | sender | {senderAddress} | + +### MsgBeginRedelegate + +| Type | Attribute Key | Attribute Value | +| ---------- | --------------------- | --------------------- | +| redelegate | source_validator | {srcValidatorAddress} | +| redelegate | destination_validator | {dstValidatorAddress} | +| redelegate | amount | {unbondAmount} | +| redelegate | completion_time [0] | {completionTime} | +| message | module | staking | +| message | action | begin_redelegate | +| message | sender | {senderAddress} | + +* [0] Time is formatted in the RFC3339 standard diff --git a/versioned_docs/version-0.46/integrate/modules/staking/08_params.md b/versioned_docs/version-0.46/integrate/modules/staking/08_params.md new file mode 100644 index 000000000..e4a56ab3f --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/staking/08_params.md @@ -0,0 +1,16 @@ + + +# Parameters + +The staking module contains the following parameters: + +| Key | Type | Example | +|-------------------|------------------|------------------------| +| UnbondingTime | string (time ns) | "259200000000000" | +| MaxValidators | uint16 | 100 | +| KeyMaxEntries | uint16 | 7 | +| HistoricalEntries | uint16 | 3 | +| BondDenom | string | "stake" | +| MinCommissionRate | string | "0.000000000000000000" | diff --git a/versioned_docs/version-0.46/integrate/modules/staking/09_client.md b/versioned_docs/version-0.46/integrate/modules/staking/09_client.md new file mode 100644 index 000000000..0c3383d01 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/staking/09_client.md @@ -0,0 +1,2101 @@ + + +# Client + +## CLI + +A user can query and interact with the `staking` module using the CLI. + +### Query + +The `query` commands allows users to query `staking` state. + +```bash +simd query staking --help +``` + +#### delegation + +The `delegation` command allows users to query delegations for an individual delegator on an individual validator. + +Usage: + +```bash +simd query staking delegation [delegator-addr] [validator-addr] [flags] +``` + +Example: + +```bash +simd query staking delegation cosmos1gghjut3ccd8ay0zduzj64hwre2fxs9ld75ru9p cosmosvaloper1gghjut3ccd8ay0zduzj64hwre2fxs9ldmqhffj +``` + +Example Output: + +```bash +balance: + amount: "10000000000" + denom: stake +delegation: + delegator_address: cosmos1gghjut3ccd8ay0zduzj64hwre2fxs9ld75ru9p + shares: "10000000000.000000000000000000" + validator_address: cosmosvaloper1gghjut3ccd8ay0zduzj64hwre2fxs9ldmqhffj +``` + +#### delegations + +The `delegations` command allows users to query delegations for an individual delegator on all validators. + +Usage: + +```bash +simd query staking delegations [delegator-addr] [flags] +``` + +Example: + +```bash +simd query staking delegations cosmos1gghjut3ccd8ay0zduzj64hwre2fxs9ld75ru9p +``` + +Example Output: + +```bash +delegation_responses: +- balance: + amount: "10000000000" + denom: stake + delegation: + delegator_address: cosmos1gghjut3ccd8ay0zduzj64hwre2fxs9ld75ru9p + shares: "10000000000.000000000000000000" + validator_address: cosmosvaloper1gghjut3ccd8ay0zduzj64hwre2fxs9ldmqhffj +- balance: + amount: "10000000000" + denom: stake + delegation: + delegator_address: cosmos1gghjut3ccd8ay0zduzj64hwre2fxs9ld75ru9p + shares: "10000000000.000000000000000000" + validator_address: cosmosvaloper1x20lytyf6zkcrv5edpkfkn8sz578qg5sqfyqnp +pagination: + next_key: null + total: "0" +``` + +#### delegations-to + +The `delegations-to` command allows users to query delegations on an individual validator. + +Usage: + +```bash +simd query staking delegations-to [validator-addr] [flags] +``` + +Example: + +```bash +simd query staking delegations-to cosmosvaloper1gghjut3ccd8ay0zduzj64hwre2fxs9ldmqhffj +``` + +Example Output: + +```bash +- balance: + amount: "504000000" + denom: stake + delegation: + delegator_address: cosmos1q2qwwynhv8kh3lu5fkeex4awau9x8fwt45f5cp + shares: "504000000.000000000000000000" + validator_address: cosmosvaloper1gghjut3ccd8ay0zduzj64hwre2fxs9ldmqhffj +- balance: + amount: "78125000000" + denom: uixo + delegation: + delegator_address: cosmos1qvppl3479hw4clahe0kwdlfvf8uvjtcd99m2ca + shares: "78125000000.000000000000000000" + validator_address: cosmosvaloper1gghjut3ccd8ay0zduzj64hwre2fxs9ldmqhffj +pagination: + next_key: null + total: "0" +``` + +#### historical-info + +The `historical-info` command allows users to query historical information at given height. + +Usage: + +```bash +simd query staking historical-info [height] [flags] +``` + +Example: + +```bash +simd query staking historical-info 10 +``` + +Example Output: + +```bash +header: + app_hash: Lbx8cXpI868wz8sgp4qPYVrlaKjevR5WP/IjUxwp3oo= + chain_id: testnet + consensus_hash: BICRvH3cKD93v7+R1zxE2ljD34qcvIZ0Bdi389qtoi8= + data_hash: 47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU= + evidence_hash: 47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU= + height: "10" + last_block_id: + hash: RFbkpu6pWfSThXxKKl6EZVDnBSm16+U0l0xVjTX08Fk= + part_set_header: + hash: vpIvXD4rxD5GM4MXGz0Sad9I7//iVYLzZsEU4BVgWIU= + total: 1 + last_commit_hash: Ne4uXyx4QtNp4Zx89kf9UK7oG9QVbdB6e7ZwZkhy8K0= + last_results_hash: 47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU= + next_validators_hash: nGBgKeWBjoxeKFti00CxHsnULORgKY4LiuQwBuUrhCs= + proposer_address: mMEP2c2IRPLr99LedSRtBg9eONM= + time: "2021-10-01T06:00:49.785790894Z" + validators_hash: nGBgKeWBjoxeKFti00CxHsnULORgKY4LiuQwBuUrhCs= + version: + app: "0" + block: "11" +valset: +- commission: + commission_rates: + max_change_rate: "0.010000000000000000" + max_rate: "0.200000000000000000" + rate: "0.100000000000000000" + update_time: "2021-10-01T05:52:50.380144238Z" + consensus_pubkey: + '@type': /cosmos.crypto.ed25519.PubKey + key: Auxs3865HpB/EfssYOzfqNhEJjzys2Fo6jD5B8tPgC8= + delegator_shares: "10000000.000000000000000000" + description: + details: "" + identity: "" + moniker: myvalidator + security_contact: "" + website: "" + jailed: false + min_self_delegation: "1" + operator_address: cosmosvaloper1rne8lgs98p0jqe82sgt0qr4rdn4hgvmgp9ggcc + status: BOND_STATUS_BONDED + tokens: "10000000" + unbonding_height: "0" + unbonding_time: "1970-01-01T00:00:00Z" +``` + +#### params + +The `params` command allows users to query values set as staking parameters. + +Usage: + +```bash +simd query staking params [flags] +``` + +Example: + +```bash +simd query staking params +``` + +Example Output: + +```bash +bond_denom: stake +historical_entries: 10000 +max_entries: 7 +max_validators: 50 +unbonding_time: 1814400s +``` + +#### pool + +The `pool` command allows users to query values for amounts stored in the staking pool. + +Usage: + +```bash +simd q staking pool [flags] +``` + +Example: + +```bash +simd q staking pool +``` + +Example Output: + +```bash +bonded_tokens: "10000000" +not_bonded_tokens: "0" +``` + +#### redelegation + +The `redelegation` command allows users to query a redelegation record based on delegator and a source and destination validator address. + +Usage: + +```bash +simd query staking redelegation [delegator-addr] [src-validator-addr] [dst-validator-addr] [flags] +``` + +Example: + +```bash +simd query staking redelegation cosmos1gghjut3ccd8ay0zduzj64hwre2fxs9ld75ru9p cosmosvaloper1l2rsakp388kuv9k8qzq6lrm9taddae7fpx59wm cosmosvaloper1gghjut3ccd8ay0zduzj64hwre2fxs9ldmqhffj +``` + +Example Output: + +```bash +pagination: null +redelegation_responses: +- entries: + - balance: "50000000" + redelegation_entry: + completion_time: "2021-10-24T20:33:21.960084845Z" + creation_height: 2.382847e+06 + initial_balance: "50000000" + shares_dst: "50000000.000000000000000000" + - balance: "5000000000" + redelegation_entry: + completion_time: "2021-10-25T21:33:54.446846862Z" + creation_height: 2.397271e+06 + initial_balance: "5000000000" + shares_dst: "5000000000.000000000000000000" + redelegation: + delegator_address: cosmos1gghjut3ccd8ay0zduzj64hwre2fxs9ld75ru9p + entries: null + validator_dst_address: cosmosvaloper1l2rsakp388kuv9k8qzq6lrm9taddae7fpx59wm + validator_src_address: cosmosvaloper1l2rsakp388kuv9k8qzq6lrm9taddae7fpx59wm +``` + +#### redelegations + +The `redelegations` command allows users to query all redelegation records for an individual delegator. + +Usage: + +```bash +simd query staking redelegations [delegator-addr] [flags] +``` + +Example: + +```bash +simd query staking redelegation cosmos1gghjut3ccd8ay0zduzj64hwre2fxs9ld75ru9p +``` + +Example Output: + +```bash +pagination: + next_key: null + total: "0" +redelegation_responses: +- entries: + - balance: "50000000" + redelegation_entry: + completion_time: "2021-10-24T20:33:21.960084845Z" + creation_height: 2.382847e+06 + initial_balance: "50000000" + shares_dst: "50000000.000000000000000000" + - balance: "5000000000" + redelegation_entry: + completion_time: "2021-10-25T21:33:54.446846862Z" + creation_height: 2.397271e+06 + initial_balance: "5000000000" + shares_dst: "5000000000.000000000000000000" + redelegation: + delegator_address: cosmos1gghjut3ccd8ay0zduzj64hwre2fxs9ld75ru9p + entries: null + validator_dst_address: cosmosvaloper1uccl5ugxrm7vqlzwqr04pjd320d2fz0z3hc6vm + validator_src_address: cosmosvaloper1zppjyal5emta5cquje8ndkpz0rs046m7zqxrpp +- entries: + - balance: "562770000000" + redelegation_entry: + completion_time: "2021-10-25T21:42:07.336911677Z" + creation_height: 2.39735e+06 + initial_balance: "562770000000" + shares_dst: "562770000000.000000000000000000" + redelegation: + delegator_address: cosmos1gghjut3ccd8ay0zduzj64hwre2fxs9ld75ru9p + entries: null + validator_dst_address: cosmosvaloper1uccl5ugxrm7vqlzwqr04pjd320d2fz0z3hc6vm + validator_src_address: cosmosvaloper1zppjyal5emta5cquje8ndkpz0rs046m7zqxrpp +``` + +#### redelegations-from + +The `redelegations-from` command allows users to query delegations that are redelegating _from_ a validator. + +Usage: + +```bash +simd query staking redelegations-from [validator-addr] [flags] +``` + +Example: + +```bash +simd query staking redelegations-from cosmosvaloper1y4rzzrgl66eyhzt6gse2k7ej3zgwmngeleucjy +``` + +Example Output: + +```bash +pagination: + next_key: null + total: "0" +redelegation_responses: +- entries: + - balance: "50000000" + redelegation_entry: + completion_time: "2021-10-24T20:33:21.960084845Z" + creation_height: 2.382847e+06 + initial_balance: "50000000" + shares_dst: "50000000.000000000000000000" + - balance: "5000000000" + redelegation_entry: + completion_time: "2021-10-25T21:33:54.446846862Z" + creation_height: 2.397271e+06 + initial_balance: "5000000000" + shares_dst: "5000000000.000000000000000000" + redelegation: + delegator_address: cosmos1pm6e78p4pgn0da365plzl4t56pxy8hwtqp2mph + entries: null + validator_dst_address: cosmosvaloper1uccl5ugxrm7vqlzwqr04pjd320d2fz0z3hc6vm + validator_src_address: cosmosvaloper1y4rzzrgl66eyhzt6gse2k7ej3zgwmngeleucjy +- entries: + - balance: "221000000" + redelegation_entry: + completion_time: "2021-10-05T21:05:45.669420544Z" + creation_height: 2.120693e+06 + initial_balance: "221000000" + shares_dst: "221000000.000000000000000000" + redelegation: + delegator_address: cosmos1zqv8qxy2zgn4c58fz8jt8jmhs3d0attcussrf6 + entries: null + validator_dst_address: cosmosvaloper10mseqwnwtjaqfrwwp2nyrruwmjp6u5jhah4c3y + validator_src_address: cosmosvaloper1y4rzzrgl66eyhzt6gse2k7ej3zgwmngeleucjy +``` + +#### unbonding-delegation + +The `unbonding-delegation` command allows users to query unbonding delegations for an individual delegator on an individual validator. + +Usage: + +```bash +simd query staking unbonding-delegation [delegator-addr] [validator-addr] [flags] +``` + +Example: + +```bash +simd query staking unbonding-delegation cosmos1gghjut3ccd8ay0zduzj64hwre2fxs9ld75ru9p cosmosvaloper1gghjut3ccd8ay0zduzj64hwre2fxs9ldmqhffj +``` + +Example Output: + +```bash +delegator_address: cosmos1gghjut3ccd8ay0zduzj64hwre2fxs9ld75ru9p +entries: +- balance: "52000000" + completion_time: "2021-11-02T11:35:55.391594709Z" + creation_height: "55078" + initial_balance: "52000000" +validator_address: cosmosvaloper1gghjut3ccd8ay0zduzj64hwre2fxs9ldmqhffj +``` + +#### unbonding-delegations + +The `unbonding-delegations` command allows users to query all unbonding-delegations records for one delegator. + +Usage: + +```bash +simd query staking unbonding-delegations [delegator-addr] [flags] +``` + +Example: + +```bash +simd query staking unbonding-delegations cosmos1gghjut3ccd8ay0zduzj64hwre2fxs9ld75ru9p +``` + +Example Output: + +```bash +pagination: + next_key: null + total: "0" +unbonding_responses: +- delegator_address: cosmos1gghjut3ccd8ay0zduzj64hwre2fxs9ld75ru9p + entries: + - balance: "52000000" + completion_time: "2021-11-02T11:35:55.391594709Z" + creation_height: "55078" + initial_balance: "52000000" + validator_address: cosmosvaloper1t8ehvswxjfn3ejzkjtntcyrqwvmvuknzmvtaaa + +``` + +#### unbonding-delegations-from + +The `unbonding-delegations-from` command allows users to query delegations that are unbonding _from_ a validator. + +Usage: + +```bash +simd query staking unbonding-delegations-from [validator-addr] [flags] +``` + +Example: + +```bash +simd query staking unbonding-delegations-from cosmosvaloper1gghjut3ccd8ay0zduzj64hwre2fxs9ldmqhffj +``` + +Example Output: + +```bash +pagination: + next_key: null + total: "0" +unbonding_responses: +- delegator_address: cosmos1qqq9txnw4c77sdvzx0tkedsafl5s3vk7hn53fn + entries: + - balance: "150000000" + completion_time: "2021-11-01T21:41:13.098141574Z" + creation_height: "46823" + initial_balance: "150000000" + validator_address: cosmosvaloper1gghjut3ccd8ay0zduzj64hwre2fxs9ldmqhffj +- delegator_address: cosmos1peteje73eklqau66mr7h7rmewmt2vt99y24f5z + entries: + - balance: "24000000" + completion_time: "2021-10-31T02:57:18.192280361Z" + creation_height: "21516" + initial_balance: "24000000" + validator_address: cosmosvaloper1gghjut3ccd8ay0zduzj64hwre2fxs9ldmqhffj +``` + +#### validator + +The `validator` command allows users to query details about an individual validator. + +Usage: + +```bash +simd query staking validator [validator-addr] [flags] +``` + +Example: + +```bash +simd query staking validator cosmosvaloper1gghjut3ccd8ay0zduzj64hwre2fxs9ldmqhffj +``` + +Example Output: + +```bash +commission: + commission_rates: + max_change_rate: "0.020000000000000000" + max_rate: "0.200000000000000000" + rate: "0.050000000000000000" + update_time: "2021-10-01T19:24:52.663191049Z" +consensus_pubkey: + '@type': /cosmos.crypto.ed25519.PubKey + key: sIiexdJdYWn27+7iUHQJDnkp63gq/rzUq1Y+fxoGjXc= +delegator_shares: "32948270000.000000000000000000" +description: + details: Witval is the validator arm from Vitwit. Vitwit is into software consulting + and services business since 2015. We are working closely with Cosmos ecosystem + since 2018. We are also building tools for the ecosystem, Aneka is our explorer + for the cosmos ecosystem. + identity: 51468B615127273A + moniker: Witval + security_contact: "" + website: "" +jailed: false +min_self_delegation: "1" +operator_address: cosmosvaloper1gghjut3ccd8ay0zduzj64hwre2fxs9ldmqhffj +status: BOND_STATUS_BONDED +tokens: "32948270000" +unbonding_height: "0" +unbonding_time: "1970-01-01T00:00:00Z" +``` + +#### validators + +The `validators` command allows users to query details about all validators on a network. + +Usage: + +```bash +simd query staking validators [flags] +``` + +Example: + +```bash +simd query staking validators +``` + +Example Output: + +```bash +pagination: + next_key: FPTi7TKAjN63QqZh+BaXn6gBmD5/ + total: "0" +validators: +commission: + commission_rates: + max_change_rate: "0.020000000000000000" + max_rate: "0.200000000000000000" + rate: "0.050000000000000000" + update_time: "2021-10-01T19:24:52.663191049Z" +consensus_pubkey: + '@type': /cosmos.crypto.ed25519.PubKey + key: sIiexdJdYWn27+7iUHQJDnkp63gq/rzUq1Y+fxoGjXc= +delegator_shares: "32948270000.000000000000000000" +description: + details: Witval is the validator arm from Vitwit. Vitwit is into software consulting + and services business since 2015. We are working closely with Cosmos ecosystem + since 2018. We are also building tools for the ecosystem, Aneka is our explorer + for the cosmos ecosystem. + identity: 51468B615127273A + moniker: Witval + security_contact: "" + website: "" + jailed: false + min_self_delegation: "1" + operator_address: cosmosvaloper1gghjut3ccd8ay0zduzj64hwre2fxs9ldmqhffj + status: BOND_STATUS_BONDED + tokens: "32948270000" + unbonding_height: "0" + unbonding_time: "1970-01-01T00:00:00Z" +- commission: + commission_rates: + max_change_rate: "0.100000000000000000" + max_rate: "0.200000000000000000" + rate: "0.050000000000000000" + update_time: "2021-10-04T18:02:21.446645619Z" + consensus_pubkey: + '@type': /cosmos.crypto.ed25519.PubKey + key: GDNpuKDmCg9GnhnsiU4fCWktuGUemjNfvpCZiqoRIYA= + delegator_shares: "559343421.000000000000000000" + description: + details: Noderunners is a professional validator in POS networks. We have a huge + node running experience, reliable soft and hardware. Our commissions are always + low, our support to delegators is always full. Stake with us and start receiving + your Cosmos rewards now! + identity: 812E82D12FEA3493 + moniker: Noderunners + security_contact: info@noderunners.biz + website: http://noderunners.biz + jailed: false + min_self_delegation: "1" + operator_address: cosmosvaloper1q5ku90atkhktze83j9xjaks2p7uruag5zp6wt7 + status: BOND_STATUS_BONDED + tokens: "559343421" + unbonding_height: "0" + unbonding_time: "1970-01-01T00:00:00Z" +``` + +### Transactions + +The `tx` commands allows users to interact with the `staking` module. + +```bash +simd tx staking --help +``` + +#### create-validator + +The command `create-validator` allows users to create new validator initialized with a self-delegation to it. + +Usage: + +```bash +simd tx staking create-validator [flags] +``` + +Example: + +```bash +simd tx staking create-validator \ + --amount=1000000stake \ + --pubkey=$(simd tendermint show-validator) \ + --moniker="my-moniker" \ + --website="https://myweb.site" \ + --details="description of your validator" \ + --chain-id="name_of_chain_id" \ + --commission-rate="0.10" \ + --commission-max-rate="0.20" \ + --commission-max-change-rate="0.01" \ + --min-self-delegation="1" \ + --gas="auto" \ + --gas-adjustment="1.2" \ + --gas-prices="0.025stake" \ + --from=mykey +``` + +#### delegate + +The command `delegate` allows users to delegate liquid tokens to a validator. + +Usage: + +```bash +simd tx staking delegate [validator-addr] [amount] [flags] +``` + +Example: + +```bash +simd tx staking delegate cosmosvaloper1l2rsakp388kuv9k8qzq6lrm9taddae7fpx59wm 1000stake --from mykey +``` + +#### edit-validator + +The command `edit-validator` allows users to edit an existing validator account. + +Usage: + +```bash +simd tx staking edit-validator [flags] +``` + +Example: + +```bash +simd tx staking edit-validator --moniker "new_moniker_name" --website "new_webiste_url" --from mykey +``` + +#### redelegate + +The command `redelegate` allows users to redelegate illiquid tokens from one validator to another. + +Usage: + +```bash +simd tx staking redelegate [src-validator-addr] [dst-validator-addr] [amount] [flags] +``` + +Example: + +```bash +simd tx staking redelegate cosmosvaloper1gghjut3ccd8ay0zduzj64hwre2fxs9ldmqhffj cosmosvaloper1l2rsakp388kuv9k8qzq6lrm9taddae7fpx59wm 100stake --from mykey +``` + +#### unbond + +The command `unbond` allows users to unbond shares from a validator. + +Usage: + +```bash +simd tx staking unbond [validator-addr] [amount] [flags] +``` + +Example: + +```bash +simd tx staking unbond cosmosvaloper1gghjut3ccd8ay0zduzj64hwre2fxs9ldmqhffj 100stake --from mykey +``` +#### cancel unbond +The command `cancel-unbond` allow users to cancel the unbonding delegation entry and delegate back to the original validator. + +Usage: +```bash +simd tx staking cancel-unbond [validator-addr] [amount] [creation-height] +``` + +Example: +```bash +simd tx staking cancel-unbond cosmosvaloper1gghjut3ccd8ay0zduzj64hwre2fxs9ldmqhffj 100stake 123123 --from mykey +``` + + +## gRPC + +A user can query the `staking` module using gRPC endpoints. + +### Validators + +The `Validators` endpoint queries all validators that match the given status. + +```bash +cosmos.staking.v1beta1.Query/Validators +``` + +Example: + +```bash +grpcurl -plaintext localhost:9090 cosmos.staking.v1beta1.Query/Validators +``` + +Example Output: + +```bash +{ + "validators": [ + { + "operatorAddress": "cosmosvaloper1rne8lgs98p0jqe82sgt0qr4rdn4hgvmgp9ggcc", + "consensusPubkey": {"@type":"/cosmos.crypto.ed25519.PubKey","key":"Auxs3865HpB/EfssYOzfqNhEJjzys2Fo6jD5B8tPgC8="}, + "status": "BOND_STATUS_BONDED", + "tokens": "10000000", + "delegatorShares": "10000000000000000000000000", + "description": { + "moniker": "myvalidator" + }, + "unbondingTime": "1970-01-01T00:00:00Z", + "commission": { + "commissionRates": { + "rate": "100000000000000000", + "maxRate": "200000000000000000", + "maxChangeRate": "10000000000000000" + }, + "updateTime": "2021-10-01T05:52:50.380144238Z" + }, + "minSelfDelegation": "1" + } + ], + "pagination": { + "total": "1" + } +} +``` + +### Validator + +The `Validator` endpoint queries validator information for given validator address. + +```bash +cosmos.staking.v1beta1.Query/Validator +``` + +Example: + +```bash +grpcurl -plaintext -d '{"validator_addr":"cosmosvaloper1rne8lgs98p0jqe82sgt0qr4rdn4hgvmgp9ggcc"}' \ +localhost:9090 cosmos.staking.v1beta1.Query/Validator +``` + +Example Output: + +```bash +{ + "validator": { + "operatorAddress": "cosmosvaloper1rne8lgs98p0jqe82sgt0qr4rdn4hgvmgp9ggcc", + "consensusPubkey": {"@type":"/cosmos.crypto.ed25519.PubKey","key":"Auxs3865HpB/EfssYOzfqNhEJjzys2Fo6jD5B8tPgC8="}, + "status": "BOND_STATUS_BONDED", + "tokens": "10000000", + "delegatorShares": "10000000000000000000000000", + "description": { + "moniker": "myvalidator" + }, + "unbondingTime": "1970-01-01T00:00:00Z", + "commission": { + "commissionRates": { + "rate": "100000000000000000", + "maxRate": "200000000000000000", + "maxChangeRate": "10000000000000000" + }, + "updateTime": "2021-10-01T05:52:50.380144238Z" + }, + "minSelfDelegation": "1" + } +} +``` + +### ValidatorDelegations + +The `ValidatorDelegations` endpoint queries delegate information for given validator. + +```bash +cosmos.staking.v1beta1.Query/ValidatorDelegations +``` + +Example: + +```bash +grpcurl -plaintext -d '{"validator_addr":"cosmosvaloper1rne8lgs98p0jqe82sgt0qr4rdn4hgvmgp9ggcc"}' \ +localhost:9090 cosmos.staking.v1beta1.Query/ValidatorDelegations +``` + +Example Output: + +```bash +{ + "delegationResponses": [ + { + "delegation": { + "delegatorAddress": "cosmos1rne8lgs98p0jqe82sgt0qr4rdn4hgvmgy3ua5t", + "validatorAddress": "cosmosvaloper1rne8lgs98p0jqe82sgt0qr4rdn4hgvmgp9ggcc", + "shares": "10000000000000000000000000" + }, + "balance": { + "denom": "stake", + "amount": "10000000" + } + } + ], + "pagination": { + "total": "1" + } +} +``` + +### ValidatorUnbondingDelegations + +The `ValidatorUnbondingDelegations` endpoint queries delegate information for given validator. + +```bash +cosmos.staking.v1beta1.Query/ValidatorUnbondingDelegations +``` + +Example: + +```bash +grpcurl -plaintext -d '{"validator_addr":"cosmosvaloper1rne8lgs98p0jqe82sgt0qr4rdn4hgvmgp9ggcc"}' \ +localhost:9090 cosmos.staking.v1beta1.Query/ValidatorUnbondingDelegations +``` + +Example Output: + +```bash +{ + "unbonding_responses": [ + { + "delegator_address": "cosmos1z3pzzw84d6xn00pw9dy3yapqypfde7vg6965fy", + "validator_address": "cosmosvaloper1rne8lgs98p0jqe82sgt0qr4rdn4hgvmgp9ggcc", + "entries": [ + { + "creation_height": "25325", + "completion_time": "2021-10-31T09:24:36.797320636Z", + "initial_balance": "20000000", + "balance": "20000000" + } + ] + }, + { + "delegator_address": "cosmos1y8nyfvmqh50p6ldpzljk3yrglppdv3t8phju77", + "validator_address": "cosmosvaloper1rne8lgs98p0jqe82sgt0qr4rdn4hgvmgp9ggcc", + "entries": [ + { + "creation_height": "13100", + "completion_time": "2021-10-30T12:53:02.272266791Z", + "initial_balance": "1000000", + "balance": "1000000" + } + ] + }, + ], + "pagination": { + "next_key": null, + "total": "8" + } +} +``` + +### Delegation + +The `Delegation` endpoint queries delegate information for given validator delegator pair. + +```bash +cosmos.staking.v1beta1.Query/Delegation +``` + +Example: + +```bash +grpcurl -plaintext \ +-d '{"delegator_addr": "cosmos1y8nyfvmqh50p6ldpzljk3yrglppdv3t8phju77", validator_addr":"cosmosvaloper1rne8lgs98p0jqe82sgt0qr4rdn4hgvmgp9ggcc"}' \ +localhost:9090 cosmos.staking.v1beta1.Query/Delegation +``` + +Example Output: + +```bash +{ + "delegation_response": + { + "delegation": + { + "delegator_address":"cosmos1y8nyfvmqh50p6ldpzljk3yrglppdv3t8phju77", + "validator_address":"cosmosvaloper1rne8lgs98p0jqe82sgt0qr4rdn4hgvmgp9ggcc", + "shares":"25083119936.000000000000000000" + }, + "balance": + { + "denom":"stake", + "amount":"25083119936" + } + } +} +``` + +### UnbondingDelegation + +The `UnbondingDelegation` endpoint queries unbonding information for given validator delegator. + +```bash +cosmos.staking.v1beta1.Query/UnbondingDelegation +``` + +Example: + +```bash +grpcurl -plaintext \ +-d '{"delegator_addr": "cosmos1y8nyfvmqh50p6ldpzljk3yrglppdv3t8phju77", validator_addr":"cosmosvaloper1rne8lgs98p0jqe82sgt0qr4rdn4hgvmgp9ggcc"}' \ +localhost:9090 cosmos.staking.v1beta1.Query/UnbondingDelegation +``` + +Example Output: + +```bash +{ + "unbond": { + "delegator_address": "cosmos1y8nyfvmqh50p6ldpzljk3yrglppdv3t8phju77", + "validator_address": "cosmosvaloper1rne8lgs98p0jqe82sgt0qr4rdn4hgvmgp9ggcc", + "entries": [ + { + "creation_height": "136984", + "completion_time": "2021-11-08T05:38:47.505593891Z", + "initial_balance": "400000000", + "balance": "400000000" + }, + { + "creation_height": "137005", + "completion_time": "2021-11-08T05:40:53.526196312Z", + "initial_balance": "385000000", + "balance": "385000000" + } + ] + } +} +``` + +### DelegatorDelegations + +The `DelegatorDelegations` endpoint queries all delegations of a given delegator address. + +```bash +cosmos.staking.v1beta1.Query/DelegatorDelegations +``` + +Example: + +```bash +grpcurl -plaintext \ +-d '{"delegator_addr": "cosmos1y8nyfvmqh50p6ldpzljk3yrglppdv3t8phju77"}' \ +localhost:9090 cosmos.staking.v1beta1.Query/DelegatorDelegations +``` + +Example Output: + +```bash +{ + "delegation_responses": [ + {"delegation":{"delegator_address":"cosmos1y8nyfvmqh50p6ldpzljk3yrglppdv3t8phju77","validator_address":"cosmosvaloper1eh5mwu044gd5ntkkc2xgfg8247mgc56fww3vc8","shares":"25083339023.000000000000000000"},"balance":{"denom":"stake","amount":"25083339023"}} + ], + "pagination": { + "next_key": null, + "total": "1" + } +} +``` + +### DelegatorUnbondingDelegations + +The `DelegatorUnbondingDelegations` endpoint queries all unbonding delegations of a given delegator address. + +```bash +cosmos.staking.v1beta1.Query/DelegatorUnbondingDelegations +``` + +Example: + +```bash +grpcurl -plaintext \ +-d '{"delegator_addr": "cosmos1y8nyfvmqh50p6ldpzljk3yrglppdv3t8phju77"}' \ +localhost:9090 cosmos.staking.v1beta1.Query/DelegatorUnbondingDelegations +``` + +Example Output: + +```bash +{ + "unbonding_responses": [ + { + "delegator_address": "cosmos1y8nyfvmqh50p6ldpzljk3yrglppdv3t8phju77", + "validator_address": "cosmosvaloper1sjllsnramtg3ewxqwwrwjxfgc4n4ef9uxyejze", + "entries": [ + { + "creation_height": "136984", + "completion_time": "2021-11-08T05:38:47.505593891Z", + "initial_balance": "400000000", + "balance": "400000000" + }, + { + "creation_height": "137005", + "completion_time": "2021-11-08T05:40:53.526196312Z", + "initial_balance": "385000000", + "balance": "385000000" + } + ] + } + ], + "pagination": { + "next_key": null, + "total": "1" + } +} +``` + +### Redelegations + +The `Redelegations` endpoint queries redelegations of given address. + +```bash +cosmos.staking.v1beta1.Query/Redelegations +``` + +Example: + +```bash +grpcurl -plaintext \ +-d '{"delegator_addr": "cosmos1ld5p7hn43yuh8ht28gm9pfjgj2fctujp2tgwvf", "src_validator_addr" : "cosmosvaloper1j7euyj85fv2jugejrktj540emh9353ltgppc3g", "dst_validator_addr" : "cosmosvaloper1yy3tnegzmkdcm7czzcy3flw5z0zyr9vkkxrfse"}' \ +localhost:9090 cosmos.staking.v1beta1.Query/Redelegations +``` + +Example Output: + +```bash +{ + "redelegation_responses": [ + { + "redelegation": { + "delegator_address": "cosmos1ld5p7hn43yuh8ht28gm9pfjgj2fctujp2tgwvf", + "validator_src_address": "cosmosvaloper1j7euyj85fv2jugejrktj540emh9353ltgppc3g", + "validator_dst_address": "cosmosvaloper1yy3tnegzmkdcm7czzcy3flw5z0zyr9vkkxrfse", + "entries": null + }, + "entries": [ + { + "redelegation_entry": { + "creation_height": 135932, + "completion_time": "2021-11-08T03:52:55.299147901Z", + "initial_balance": "2900000", + "shares_dst": "2900000.000000000000000000" + }, + "balance": "2900000" + } + ] + } + ], + "pagination": null +} +``` + +### DelegatorValidators + +The `DelegatorValidators` endpoint queries all validators information for given delegator. + +```bash +cosmos.staking.v1beta1.Query/DelegatorValidators +``` + +Example: + +```bash +grpcurl -plaintext \ +-d '{"delegator_addr": "cosmos1ld5p7hn43yuh8ht28gm9pfjgj2fctujp2tgwvf"}' \ +localhost:9090 cosmos.staking.v1beta1.Query/DelegatorValidators +``` + +Example Output: + +```bash +{ + "validators": [ + { + "operator_address": "cosmosvaloper1eh5mwu044gd5ntkkc2xgfg8247mgc56fww3vc8", + "consensus_pubkey": { + "@type": "/cosmos.crypto.ed25519.PubKey", + "key": "UPwHWxH1zHJWGOa/m6JB3f5YjHMvPQPkVbDqqi+U7Uw=" + }, + "jailed": false, + "status": "BOND_STATUS_BONDED", + "tokens": "347260647559", + "delegator_shares": "347260647559.000000000000000000", + "description": { + "moniker": "BouBouNode", + "identity": "", + "website": "https://boubounode.com", + "security_contact": "", + "details": "AI-based Validator. #1 AI Validator on Game of Stakes. Fairly priced. Don't trust (humans), verify. Made with BouBou love." + }, + "unbonding_height": "0", + "unbonding_time": "1970-01-01T00:00:00Z", + "commission": { + "commission_rates": { + "rate": "0.061000000000000000", + "max_rate": "0.300000000000000000", + "max_change_rate": "0.150000000000000000" + }, + "update_time": "2021-10-01T15:00:00Z" + }, + "min_self_delegation": "1" + } + ], + "pagination": { + "next_key": null, + "total": "1" + } +} +``` + +### DelegatorValidator + +The `DelegatorValidator` endpoint queries validator information for given delegator validator + +```bash +cosmos.staking.v1beta1.Query/DelegatorValidator +``` + +Example: + +```bash +grpcurl -plaintext \ +-d '{"delegator_addr": "cosmos1eh5mwu044gd5ntkkc2xgfg8247mgc56f3n8rr7", "validator_addr": "cosmosvaloper1eh5mwu044gd5ntkkc2xgfg8247mgc56fww3vc8"}' \ +localhost:9090 cosmos.staking.v1beta1.Query/DelegatorValidator +``` + +Example Output: + +```bash +{ + "validator": { + "operator_address": "cosmosvaloper1eh5mwu044gd5ntkkc2xgfg8247mgc56fww3vc8", + "consensus_pubkey": { + "@type": "/cosmos.crypto.ed25519.PubKey", + "key": "UPwHWxH1zHJWGOa/m6JB3f5YjHMvPQPkVbDqqi+U7Uw=" + }, + "jailed": false, + "status": "BOND_STATUS_BONDED", + "tokens": "347262754841", + "delegator_shares": "347262754841.000000000000000000", + "description": { + "moniker": "BouBouNode", + "identity": "", + "website": "https://boubounode.com", + "security_contact": "", + "details": "AI-based Validator. #1 AI Validator on Game of Stakes. Fairly priced. Don't trust (humans), verify. Made with BouBou love." + }, + "unbonding_height": "0", + "unbonding_time": "1970-01-01T00:00:00Z", + "commission": { + "commission_rates": { + "rate": "0.061000000000000000", + "max_rate": "0.300000000000000000", + "max_change_rate": "0.150000000000000000" + }, + "update_time": "2021-10-01T15:00:00Z" + }, + "min_self_delegation": "1" + } +} +``` + +### HistoricalInfo + +```bash +cosmos.staking.v1beta1.Query/HistoricalInfo +``` + +Example: + +```bash +grpcurl -plaintext -d '{"height" : 1}' localhost:9090 cosmos.staking.v1beta1.Query/HistoricalInfo +``` + +Example Output: + +```bash +{ + "hist": { + "header": { + "version": { + "block": "11", + "app": "0" + }, + "chain_id": "simd-1", + "height": "140142", + "time": "2021-10-11T10:56:29.720079569Z", + "last_block_id": { + "hash": "9gri/4LLJUBFqioQ3NzZIP9/7YHR9QqaM6B2aJNQA7o=", + "part_set_header": { + "total": 1, + "hash": "Hk1+C864uQkl9+I6Zn7IurBZBKUevqlVtU7VqaZl1tc=" + } + }, + "last_commit_hash": "VxrcS27GtvGruS3I9+AlpT7udxIT1F0OrRklrVFSSKc=", + "data_hash": "80BjOrqNYUOkTnmgWyz9AQ8n7SoEmPVi4QmAe8RbQBY=", + "validators_hash": "95W49n2hw8RWpr1GPTAO5MSPi6w6Wjr3JjjS7AjpBho=", + "next_validators_hash": "95W49n2hw8RWpr1GPTAO5MSPi6w6Wjr3JjjS7AjpBho=", + "consensus_hash": "BICRvH3cKD93v7+R1zxE2ljD34qcvIZ0Bdi389qtoi8=", + "app_hash": "ZZaxnSY3E6Ex5Bvkm+RigYCK82g8SSUL53NymPITeOE=", + "last_results_hash": "47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=", + "evidence_hash": "47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=", + "proposer_address": "aH6dO428B+ItuoqPq70efFHrSMY=" + }, + "valset": [ + { + "operator_address": "cosmosvaloper196ax4vc0lwpxndu9dyhvca7jhxp70rmcqcnylw", + "consensus_pubkey": { + "@type": "/cosmos.crypto.ed25519.PubKey", + "key": "/O7BtNW0pafwfvomgR4ZnfldwPXiFfJs9mHg3gwfv5Q=" + }, + "jailed": false, + "status": "BOND_STATUS_BONDED", + "tokens": "1426045203613", + "delegator_shares": "1426045203613.000000000000000000", + "description": { + "moniker": "SG-1", + "identity": "48608633F99D1B60", + "website": "https://sg-1.online", + "security_contact": "", + "details": "SG-1 - your favorite validator on Witval. We offer 100% Soft Slash protection." + }, + "unbonding_height": "0", + "unbonding_time": "1970-01-01T00:00:00Z", + "commission": { + "commission_rates": { + "rate": "0.037500000000000000", + "max_rate": "0.200000000000000000", + "max_change_rate": "0.030000000000000000" + }, + "update_time": "2021-10-01T15:00:00Z" + }, + "min_self_delegation": "1" + } + ] + } +} + +``` + +### Pool + +The `Pool` endpoint queries the pool information. + +```bash +cosmos.staking.v1beta1.Query/Pool +``` + +Example: + +```bash +grpcurl -plaintext -d localhost:9090 cosmos.staking.v1beta1.Query/Pool +``` + +Example Output: + +```bash +{ + "pool": { + "not_bonded_tokens": "369054400189", + "bonded_tokens": "15657192425623" + } +} +``` + +### Params + +The `Params` endpoint queries the pool information. + +```bash +cosmos.staking.v1beta1.Query/Params +``` + +Example: + +```bash +grpcurl -plaintext localhost:9090 cosmos.staking.v1beta1.Query/Params +``` + +Example Output: + +```bash +{ + "params": { + "unbondingTime": "1814400s", + "maxValidators": 100, + "maxEntries": 7, + "historicalEntries": 10000, + "bondDenom": "stake" + } +} +``` + +## REST + +A user can query the `staking` module using REST endpoints. + +### DelegatorDelegations + +The `DelegtaorDelegations` REST endpoint queries all delegations of a given delegator address. + +```bash +/cosmos/staking/v1beta1/delegations/{delegatorAddr} +``` + +Example: + +```bash +curl -X GET "http://localhost:1317/cosmos/staking/v1beta1/delegations/cosmos1vcs68xf2tnqes5tg0khr0vyevm40ff6zdxatp5" -H "accept: application/json" +``` + +Example Output: + +```bash +{ + "delegation_responses": [ + { + "delegation": { + "delegator_address": "cosmos1vcs68xf2tnqes5tg0khr0vyevm40ff6zdxatp5", + "validator_address": "cosmosvaloper1quqxfrxkycr0uzt4yk0d57tcq3zk7srm7sm6r8", + "shares": "256250000.000000000000000000" + }, + "balance": { + "denom": "stake", + "amount": "256250000" + } + }, + { + "delegation": { + "delegator_address": "cosmos1vcs68xf2tnqes5tg0khr0vyevm40ff6zdxatp5", + "validator_address": "cosmosvaloper194v8uwee2fvs2s8fa5k7j03ktwc87h5ym39jfv", + "shares": "255150000.000000000000000000" + }, + "balance": { + "denom": "stake", + "amount": "255150000" + } + } + ], + "pagination": { + "next_key": null, + "total": "2" + } +} +``` + +### Redelegations + +The `Redelegations` REST endpoint queries redelegations of given address. + +```bash +/cosmos/staking/v1beta1/delegators/{delegatorAddr}/redelegations +``` + +Example: + +```bash +curl -X GET \ +"http://localhost:1317/cosmos/staking/v1beta1/delegators/cosmos1thfntksw0d35n2tkr0k8v54fr8wxtxwxl2c56e/redelegations?srcValidatorAddr=cosmosvaloper1lzhlnpahvznwfv4jmay2tgaha5kmz5qx4cuznf&dstValidatorAddr=cosmosvaloper1vq8tw77kp8lvxq9u3c8eeln9zymn68rng8pgt4" \ +-H "accept: application/json" +``` + +Example Output: + +```bash +{ + "redelegation_responses": [ + { + "redelegation": { + "delegator_address": "cosmos1thfntksw0d35n2tkr0k8v54fr8wxtxwxl2c56e", + "validator_src_address": "cosmosvaloper1lzhlnpahvznwfv4jmay2tgaha5kmz5qx4cuznf", + "validator_dst_address": "cosmosvaloper1vq8tw77kp8lvxq9u3c8eeln9zymn68rng8pgt4", + "entries": null + }, + "entries": [ + { + "redelegation_entry": { + "creation_height": 151523, + "completion_time": "2021-11-09T06:03:25.640682116Z", + "initial_balance": "200000000", + "shares_dst": "200000000.000000000000000000" + }, + "balance": "200000000" + } + ] + } + ], + "pagination": null +} +``` + +### DelegatorUnbondingDelegations + +The `DelegatorUnbondingDelegations` REST endpoint queries all unbonding delegations of a given delegator address. + +```bash +/cosmos/staking/v1beta1/delegators/{delegatorAddr}/unbonding_delegations +``` + +Example: + +```bash +curl -X GET \ +"http://localhost:1317/cosmos/staking/v1beta1/delegators/cosmos1nxv42u3lv642q0fuzu2qmrku27zgut3n3z7lll/unbonding_delegations" \ +-H "accept: application/json" +``` + +Example Output: + +```bash +{ + "unbonding_responses": [ + { + "delegator_address": "cosmos1nxv42u3lv642q0fuzu2qmrku27zgut3n3z7lll", + "validator_address": "cosmosvaloper1e7mvqlz50ch6gw4yjfemsc069wfre4qwmw53kq", + "entries": [ + { + "creation_height": "2442278", + "completion_time": "2021-10-12T10:59:03.797335857Z", + "initial_balance": "50000000000", + "balance": "50000000000" + } + ] + } + ], + "pagination": { + "next_key": null, + "total": "1" + } +} +``` + +### DelegatorValidators + +The `DelegatorValidators` REST endpoint queries all validators information for given delegator address. + +```bash +/cosmos/staking/v1beta1/delegators/{delegatorAddr}/validators +``` + +Example: + +```bash +curl -X GET \ +"http://localhost:1317/cosmos/staking/v1beta1/delegators/cosmos1xwazl8ftks4gn00y5x3c47auquc62ssune9ppv/validators" \ +-H "accept: application/json" +``` + +Example Output: + +```bash +{ + "validators": [ + { + "operator_address": "cosmosvaloper1xwazl8ftks4gn00y5x3c47auquc62ssuvynw64", + "consensus_pubkey": { + "@type": "/cosmos.crypto.ed25519.PubKey", + "key": "5v4n3px3PkfNnKflSgepDnsMQR1hiNXnqOC11Y72/PQ=" + }, + "jailed": false, + "status": "BOND_STATUS_BONDED", + "tokens": "21592843799", + "delegator_shares": "21592843799.000000000000000000", + "description": { + "moniker": "jabbey", + "identity": "", + "website": "https://twitter.com/JoeAbbey", + "security_contact": "", + "details": "just another dad in the cosmos" + }, + "unbonding_height": "0", + "unbonding_time": "1970-01-01T00:00:00Z", + "commission": { + "commission_rates": { + "rate": "0.100000000000000000", + "max_rate": "0.200000000000000000", + "max_change_rate": "0.100000000000000000" + }, + "update_time": "2021-10-09T19:03:54.984821705Z" + }, + "min_self_delegation": "1" + } + ], + "pagination": { + "next_key": null, + "total": "1" + } +} +``` + +### DelegatorValidator + +The `DelegatorValidator` REST endpoint queries validator information for given delegator validator pair. + +```bash +/cosmos/staking/v1beta1/delegators/{delegatorAddr}/validators/{validatorAddr} +``` + +Example: + +```bash +curl -X GET \ +"http://localhost:1317/cosmos/staking/v1beta1/delegators/cosmos1xwazl8ftks4gn00y5x3c47auquc62ssune9ppv/validators/cosmosvaloper1xwazl8ftks4gn00y5x3c47auquc62ssuvynw64" \ +-H "accept: application/json" +``` + +Example Output: + +```bash +{ + "validator": { + "operator_address": "cosmosvaloper1xwazl8ftks4gn00y5x3c47auquc62ssuvynw64", + "consensus_pubkey": { + "@type": "/cosmos.crypto.ed25519.PubKey", + "key": "5v4n3px3PkfNnKflSgepDnsMQR1hiNXnqOC11Y72/PQ=" + }, + "jailed": false, + "status": "BOND_STATUS_BONDED", + "tokens": "21592843799", + "delegator_shares": "21592843799.000000000000000000", + "description": { + "moniker": "jabbey", + "identity": "", + "website": "https://twitter.com/JoeAbbey", + "security_contact": "", + "details": "just another dad in the cosmos" + }, + "unbonding_height": "0", + "unbonding_time": "1970-01-01T00:00:00Z", + "commission": { + "commission_rates": { + "rate": "0.100000000000000000", + "max_rate": "0.200000000000000000", + "max_change_rate": "0.100000000000000000" + }, + "update_time": "2021-10-09T19:03:54.984821705Z" + }, + "min_self_delegation": "1" + } +} +``` + +### HistoricalInfo + +The `HistoricalInfo` REST endpoint queries the historical information for given height. + +```bash +/cosmos/staking/v1beta1/historical_info/{height} +``` + +Example: + +```bash +curl -X GET "http://localhost:1317/cosmos/staking/v1beta1/historical_info/153332" -H "accept: application/json" +``` + +Example Output: + +```bash +{ + "hist": { + "header": { + "version": { + "block": "11", + "app": "0" + }, + "chain_id": "cosmos-1", + "height": "153332", + "time": "2021-10-12T09:05:35.062230221Z", + "last_block_id": { + "hash": "NX8HevR5khb7H6NGKva+jVz7cyf0skF1CrcY9A0s+d8=", + "part_set_header": { + "total": 1, + "hash": "zLQ2FiKM5tooL3BInt+VVfgzjlBXfq0Hc8Iux/xrhdg=" + } + }, + "last_commit_hash": "P6IJrK8vSqU3dGEyRHnAFocoDGja0bn9euLuy09s350=", + "data_hash": "eUd+6acHWrNXYju8Js449RJ99lOYOs16KpqQl4SMrEM=", + "validators_hash": "mB4pravvMsJKgi+g8aYdSeNlt0kPjnRFyvtAQtaxcfw=", + "next_validators_hash": "mB4pravvMsJKgi+g8aYdSeNlt0kPjnRFyvtAQtaxcfw=", + "consensus_hash": "BICRvH3cKD93v7+R1zxE2ljD34qcvIZ0Bdi389qtoi8=", + "app_hash": "fuELArKRK+CptnZ8tu54h6xEleSWenHNmqC84W866fU=", + "last_results_hash": "p/BPexV4LxAzlVcPRvW+lomgXb6Yze8YLIQUo/4Kdgc=", + "evidence_hash": "47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=", + "proposer_address": "G0MeY8xQx7ooOsni8KE/3R/Ib3Q=" + }, + "valset": [ + { + "operator_address": "cosmosvaloper196ax4vc0lwpxndu9dyhvca7jhxp70rmcqcnylw", + "consensus_pubkey": { + "@type": "/cosmos.crypto.ed25519.PubKey", + "key": "/O7BtNW0pafwfvomgR4ZnfldwPXiFfJs9mHg3gwfv5Q=" + }, + "jailed": false, + "status": "BOND_STATUS_BONDED", + "tokens": "1416521659632", + "delegator_shares": "1416521659632.000000000000000000", + "description": { + "moniker": "SG-1", + "identity": "48608633F99D1B60", + "website": "https://sg-1.online", + "security_contact": "", + "details": "SG-1 - your favorite validator on cosmos. We offer 100% Soft Slash protection." + }, + "unbonding_height": "0", + "unbonding_time": "1970-01-01T00:00:00Z", + "commission": { + "commission_rates": { + "rate": "0.037500000000000000", + "max_rate": "0.200000000000000000", + "max_change_rate": "0.030000000000000000" + }, + "update_time": "2021-10-01T15:00:00Z" + }, + "min_self_delegation": "1" + }, + { + "operator_address": "cosmosvaloper1t8ehvswxjfn3ejzkjtntcyrqwvmvuknzmvtaaa", + "consensus_pubkey": { + "@type": "/cosmos.crypto.ed25519.PubKey", + "key": "uExZyjNLtr2+FFIhNDAMcQ8+yTrqE7ygYTsI7khkA5Y=" + }, + "jailed": false, + "status": "BOND_STATUS_BONDED", + "tokens": "1348298958808", + "delegator_shares": "1348298958808.000000000000000000", + "description": { + "moniker": "Cosmostation", + "identity": "AE4C403A6E7AA1AC", + "website": "https://www.cosmostation.io", + "security_contact": "admin@stamper.network", + "details": "Cosmostation validator node. Delegate your tokens and Start Earning Staking Rewards" + }, + "unbonding_height": "0", + "unbonding_time": "1970-01-01T00:00:00Z", + "commission": { + "commission_rates": { + "rate": "0.050000000000000000", + "max_rate": "1.000000000000000000", + "max_change_rate": "0.200000000000000000" + }, + "update_time": "2021-10-01T15:06:38.821314287Z" + }, + "min_self_delegation": "1" + } + ] + } +} +``` + +### Parameters + +The `Parameters` REST endpoint queries the staking parameters. + +```bash +/cosmos/staking/v1beta1/params +``` + +Example: + +```bash +curl -X GET "http://localhost:1317/cosmos/staking/v1beta1/params" -H "accept: application/json" +``` + +Example Output: + +```bash +{ + "params": { + "unbonding_time": "2419200s", + "max_validators": 100, + "max_entries": 7, + "historical_entries": 10000, + "bond_denom": "stake" + } +} +``` + +### Pool + +The `Pool` REST endpoint queries the pool information. + +```bash +/cosmos/staking/v1beta1/pool +``` + +Example: + +```bash +curl -X GET "http://localhost:1317/cosmos/staking/v1beta1/pool" -H "accept: application/json" +``` + +Example Output: + +```bash +{ + "pool": { + "not_bonded_tokens": "432805737458", + "bonded_tokens": "15783637712645" + } +} +``` + +### Validators + +The `Validators` REST endpoint queries all validators that match the given status. + +```bash +/cosmos/staking/v1beta1/validators +``` + +Example: + +```bash +curl -X GET "http://localhost:1317/cosmos/staking/v1beta1/validators" -H "accept: application/json" +``` + +Example Output: + +```bash +{ + "validators": [ + { + "operator_address": "cosmosvaloper1q3jsx9dpfhtyqqgetwpe5tmk8f0ms5qywje8tw", + "consensus_pubkey": { + "@type": "/cosmos.crypto.ed25519.PubKey", + "key": "N7BPyek2aKuNZ0N/8YsrqSDhGZmgVaYUBuddY8pwKaE=" + }, + "jailed": false, + "status": "BOND_STATUS_BONDED", + "tokens": "383301887799", + "delegator_shares": "383301887799.000000000000000000", + "description": { + "moniker": "SmartNodes", + "identity": "D372724899D1EDC8", + "website": "https://smartnodes.co", + "security_contact": "", + "details": "Earn Rewards with Crypto Staking & Node Deployment" + }, + "unbonding_height": "0", + "unbonding_time": "1970-01-01T00:00:00Z", + "commission": { + "commission_rates": { + "rate": "0.050000000000000000", + "max_rate": "0.200000000000000000", + "max_change_rate": "0.100000000000000000" + }, + "update_time": "2021-10-01T15:51:31.596618510Z" + }, + "min_self_delegation": "1" + }, + { + "operator_address": "cosmosvaloper1q5ku90atkhktze83j9xjaks2p7uruag5zp6wt7", + "consensus_pubkey": { + "@type": "/cosmos.crypto.ed25519.PubKey", + "key": "GDNpuKDmCg9GnhnsiU4fCWktuGUemjNfvpCZiqoRIYA=" + }, + "jailed": false, + "status": "BOND_STATUS_UNBONDING", + "tokens": "1017819654", + "delegator_shares": "1017819654.000000000000000000", + "description": { + "moniker": "Noderunners", + "identity": "812E82D12FEA3493", + "website": "http://noderunners.biz", + "security_contact": "info@noderunners.biz", + "details": "Noderunners is a professional validator in POS networks. We have a huge node running experience, reliable soft and hardware. Our commissions are always low, our support to delegators is always full. Stake with us and start receiving your cosmos rewards now!" + }, + "unbonding_height": "147302", + "unbonding_time": "2021-11-08T22:58:53.718662452Z", + "commission": { + "commission_rates": { + "rate": "0.050000000000000000", + "max_rate": "0.200000000000000000", + "max_change_rate": "0.100000000000000000" + }, + "update_time": "2021-10-04T18:02:21.446645619Z" + }, + "min_self_delegation": "1" + } + ], + "pagination": { + "next_key": "FONDBFkE4tEEf7yxWWKOD49jC2NK", + "total": "2" + } +} +``` + +### Validator + +The `Validator` REST endpoint queries validator information for given validator address. + +```bash +/cosmos/staking/v1beta1/validators/{validatorAddr} +``` + +Example: + +```bash +curl -X GET \ +"http://localhost:1317/cosmos/staking/v1beta1/validators/cosmosvaloper16msryt3fqlxtvsy8u5ay7wv2p8mglfg9g70e3q" \ +-H "accept: application/json" +``` + +Example Output: + +```bash +{ + "validator": { + "operator_address": "cosmosvaloper16msryt3fqlxtvsy8u5ay7wv2p8mglfg9g70e3q", + "consensus_pubkey": { + "@type": "/cosmos.crypto.ed25519.PubKey", + "key": "sIiexdJdYWn27+7iUHQJDnkp63gq/rzUq1Y+fxoGjXc=" + }, + "jailed": false, + "status": "BOND_STATUS_BONDED", + "tokens": "33027900000", + "delegator_shares": "33027900000.000000000000000000", + "description": { + "moniker": "Witval", + "identity": "51468B615127273A", + "website": "", + "security_contact": "", + "details": "Witval is the validator arm from Vitwit. Vitwit is into software consulting and services business since 2015. We are working closely with Cosmos ecosystem since 2018. We are also building tools for the ecosystem, Aneka is our explorer for the cosmos ecosystem." + }, + "unbonding_height": "0", + "unbonding_time": "1970-01-01T00:00:00Z", + "commission": { + "commission_rates": { + "rate": "0.050000000000000000", + "max_rate": "0.200000000000000000", + "max_change_rate": "0.020000000000000000" + }, + "update_time": "2021-10-01T19:24:52.663191049Z" + }, + "min_self_delegation": "1" + } +} +``` + +### ValidatorDelegations + +The `ValidatorDelegations` REST endpoint queries delegate information for given validator. + +```bash +/cosmos/staking/v1beta1/validators/{validatorAddr}/delegations +``` + +Example: + +```bash +curl -X GET "http://localhost:1317/cosmos/staking/v1beta1/validators/cosmosvaloper16msryt3fqlxtvsy8u5ay7wv2p8mglfg9g70e3q/delegations" -H "accept: application/json" +``` + +Example Output: + +```bash +{ + "delegation_responses": [ + { + "delegation": { + "delegator_address": "cosmos190g5j8aszqhvtg7cprmev8xcxs6csra7xnk3n3", + "validator_address": "cosmosvaloper16msryt3fqlxtvsy8u5ay7wv2p8mglfg9g70e3q", + "shares": "31000000000.000000000000000000" + }, + "balance": { + "denom": "stake", + "amount": "31000000000" + } + }, + { + "delegation": { + "delegator_address": "cosmos1ddle9tczl87gsvmeva3c48nenyng4n56qwq4ee", + "validator_address": "cosmosvaloper16msryt3fqlxtvsy8u5ay7wv2p8mglfg9g70e3q", + "shares": "628470000.000000000000000000" + }, + "balance": { + "denom": "stake", + "amount": "628470000" + } + }, + { + "delegation": { + "delegator_address": "cosmos10fdvkczl76m040smd33lh9xn9j0cf26kk4s2nw", + "validator_address": "cosmosvaloper16msryt3fqlxtvsy8u5ay7wv2p8mglfg9g70e3q", + "shares": "838120000.000000000000000000" + }, + "balance": { + "denom": "stake", + "amount": "838120000" + } + }, + { + "delegation": { + "delegator_address": "cosmos1n8f5fknsv2yt7a8u6nrx30zqy7lu9jfm0t5lq8", + "validator_address": "cosmosvaloper16msryt3fqlxtvsy8u5ay7wv2p8mglfg9g70e3q", + "shares": "500000000.000000000000000000" + }, + "balance": { + "denom": "stake", + "amount": "500000000" + } + }, + { + "delegation": { + "delegator_address": "cosmos16msryt3fqlxtvsy8u5ay7wv2p8mglfg9hrek2e", + "validator_address": "cosmosvaloper16msryt3fqlxtvsy8u5ay7wv2p8mglfg9g70e3q", + "shares": "61310000.000000000000000000" + }, + "balance": { + "denom": "stake", + "amount": "61310000" + } + } + ], + "pagination": { + "next_key": null, + "total": "5" + } +} +``` + +### Delegation + +The `Delegation` REST endpoint queries delegate information for given validator delegator pair. + +```bash +/cosmos/staking/v1beta1/validators/{validatorAddr}/delegations/{delegatorAddr} +``` + +Example: + +```bash +curl -X GET \ +"http://localhost:1317/cosmos/staking/v1beta1/validators/cosmosvaloper16msryt3fqlxtvsy8u5ay7wv2p8mglfg9g70e3q/delegations/cosmos1n8f5fknsv2yt7a8u6nrx30zqy7lu9jfm0t5lq8" \ +-H "accept: application/json" +``` + +Example Output: + +```bash +{ + "delegation_response": { + "delegation": { + "delegator_address": "cosmos1n8f5fknsv2yt7a8u6nrx30zqy7lu9jfm0t5lq8", + "validator_address": "cosmosvaloper16msryt3fqlxtvsy8u5ay7wv2p8mglfg9g70e3q", + "shares": "500000000.000000000000000000" + }, + "balance": { + "denom": "stake", + "amount": "500000000" + } + } +} +``` + +### UnbondingDelegation + +The `UnbondingDelegation` REST endpoint queries unbonding information for given validator delegator pair. + +```bash +/cosmos/staking/v1beta1/validators/{validatorAddr}/delegations/{delegatorAddr}/unbonding_delegation +``` + +Example: + +```bash +curl -X GET \ +"http://localhost:1317/cosmos/staking/v1beta1/validators/cosmosvaloper13v4spsah85ps4vtrw07vzea37gq5la5gktlkeu/delegations/cosmos1ze2ye5u5k3qdlexvt2e0nn0508p04094ya0qpm/unbonding_delegation" \ +-H "accept: application/json" +``` + +Example Output: + +```bash +{ + "unbond": { + "delegator_address": "cosmos1ze2ye5u5k3qdlexvt2e0nn0508p04094ya0qpm", + "validator_address": "cosmosvaloper13v4spsah85ps4vtrw07vzea37gq5la5gktlkeu", + "entries": [ + { + "creation_height": "153687", + "completion_time": "2021-11-09T09:41:18.352401903Z", + "initial_balance": "525111", + "balance": "525111" + } + ] + } +} +``` + +### ValidatorUnbondingDelegations + +The `ValidatorUnbondingDelegations` REST endpoint queries unbonding delegations of a validator. + +```bash +/cosmos/staking/v1beta1/validators/{validatorAddr}/unbonding_delegations +``` + +Example: + +```bash +curl -X GET \ +"http://localhost:1317/cosmos/staking/v1beta1/validators/cosmosvaloper13v4spsah85ps4vtrw07vzea37gq5la5gktlkeu/unbonding_delegations" \ +-H "accept: application/json" +``` + +Example Output: + +```bash +{ + "unbonding_responses": [ + { + "delegator_address": "cosmos1q9snn84jfrd9ge8t46kdcggpe58dua82vnj7uy", + "validator_address": "cosmosvaloper13v4spsah85ps4vtrw07vzea37gq5la5gktlkeu", + "entries": [ + { + "creation_height": "90998", + "completion_time": "2021-11-05T00:14:37.005841058Z", + "initial_balance": "24000000", + "balance": "24000000" + } + ] + }, + { + "delegator_address": "cosmos1qf36e6wmq9h4twhdvs6pyq9qcaeu7ye0s3dqq2", + "validator_address": "cosmosvaloper13v4spsah85ps4vtrw07vzea37gq5la5gktlkeu", + "entries": [ + { + "creation_height": "47478", + "completion_time": "2021-11-01T22:47:26.714116854Z", + "initial_balance": "8000000", + "balance": "8000000" + } + ] + } + ], + "pagination": { + "next_key": null, + "total": "2" + } +} +``` diff --git a/versioned_docs/version-0.46/integrate/modules/staking/README.md b/versioned_docs/version-0.46/integrate/modules/staking/README.md new file mode 100644 index 000000000..08c21234e --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/staking/README.md @@ -0,0 +1,56 @@ + + +# `staking` + +## Abstract + +This paper specifies the Staking module of the Cosmos SDK that 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 advanced +Proof-of-Stake (PoS) 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. + +This module is used in the Cosmos Hub, the first Hub in the Cosmos +network. + +## Contents + +1. **[State](01_state.md)** + * [Pool](01_state.md#pool) + * [LastTotalPower](01_state.md#lasttotalpower) + * [Params](01_state.md#params) + * [Validator](01_state.md#validator) + * [Delegation](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)** + * [MsgCreateValidator](03_messages.md#msgcreatevalidator) + * [MsgEditValidator](03_messages.md#msgeditvalidator) + * [MsgDelegate](03_messages.md#msgdelegate) + * [MsgUndelegate](03_messages.md#msgundelegate) + * [MsgCancelUnbondingDelegation](03_messages.md#msgcancelunbondingdelegation) + * [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)** + * [EndBlocker](07_events.md#endblocker) + * [Msg's](07_events.md#msg's) +8. **[Parameters](08_params.md)** diff --git a/versioned_docs/version-0.46/integrate/modules/staking/begin_redelegation_sequence.svg b/versioned_docs/version-0.46/integrate/modules/staking/begin_redelegation_sequence.svg new file mode 100644 index 000000000..5d17f311b --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/staking/begin_redelegation_sequence.svg @@ -0,0 +1,106 @@ +RedelegationmsgServermsgServerkeeperkeeperstorestoreBeginRedelegation(delAddr, valSrcAddr, valDstAddr, sharesAmount)get number of sharewIf the delegator has more shares than the total shares in the validator(due to rounding errors), then just withdraw the max number of shares.check the redelegation uses correct denomalt[valSrcAddr == valDstAddr]erroralt[transitive redelegation]erroralt[already has max redelegations]errorthis is the number of redelegations for a specific (del, valSrc, valDst) tripledefault : 7Unbond(del, valSrc) returns returnAmountSee unbonding diagramalt[returnAmount is zero]errorDelegate(del, returnAmount, status := valSrc.status, valDst, subtractAccount := false)See delegation diagramalt[validator is unbonded]current timealt[unbonding not complete, or just started]create redelegation objectinsert redelegation in queue, to be processed at the appropriate timecompletion time of the redelegationemit event: delegator, valSrc, valSrc,sharesAmount, completionTime \ No newline at end of file diff --git a/versioned_docs/version-0.46/integrate/modules/staking/delegation_sequence.svg b/versioned_docs/version-0.46/integrate/modules/staking/delegation_sequence.svg new file mode 100644 index 000000000..47ad53789 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/staking/delegation_sequence.svg @@ -0,0 +1,192 @@ +Delegating (currently undelegated funds delegator)msgServer (staking)msgServer (staking)keeper (staking)keeper (staking)validatorvalidatorkeeper.bankKeeperkeeper.bankKeepervestingAccountvestingAccountctx.EventManagerctx.EventManagerstorestoreDelegate(Context, DelegatorAddress, Amount, Validator, tokenSrc := Unbonded)alt[exchange rate is invalid (tokens in validator is 0)]erroralt[perform a new delegation]delegation := create delegation objectBeforeDelegationCreated hookCalls IncrementValidatorPeriod (Used to calculate distribution) in keeper/validator.go[delegation exists, more tokens being added]BeforeDelegationModified hookwithdraw current delegation rewards (and increment period)alt[delegating from an account (subtractTokens == true)]DelegateCoinsFromAccountToModuleDelegateCoinsFromAccountToModule functionDelegateCoinsFromAccountToModuleDelegateCoinsDelegateCoins functionCheck the delegator has enough balances of all tokens delegatedTrack delegation (register that it exists to keep track of it)alt[validator is currently bonded]Transfer tokens from delegator to BondedTokensPool.[validator is currently unbonded or unbonding]Transfer tokens from delegator to NotBondedTokensPool.trackDelegation functiontrackDelegationalt[delegator is a vesting account]keep track of this delegationnil (success)[moving tokens between pools (subtractTokens == false)]alt[delegator tokens are not bonded but validator is bonded]SendCoinsFromModuleToModule(notBondedPool, bondedPool, coins)[delegator tokens are bonded but validator is not bonded]SendCoinsFromModuleToModule(bondedPool, notBondedPool, coins)SendCoins functionSendCoinsEmit TransferEvent(to, from, amount)alt[amount of spendable (balance - locked) coins too low]errorsubtract balance from senderadd balance to recipientAddTokensFromDelcalculate number of shares to issueIf there are no shares (validator being created) then 1 token = 1 share.If there are already shares, thenadded shares = (added tokens amount) * (current validator shares) / (current validator tokens)add delegated tokens to validatorvalidator, addedSharesupdate validator statecalculate new validator's powerNumber of tokens divided by PowerReduction (default: 1,000,000,000,000,000,000 = 10^18)alt[validator is not jailed]update validator's power in power indexthe power index has entries shaped as 35 || power || address.This makes the validators sorted by power, high to low.AfterDelegationModified hookCalls initializeDelegationStore the previous periodCalculate the number of tokens from shares(shares the delegator has) * (tokens in delegation object)/(total tokens delegated to the validator)Store delegation starting info.newShares (ignored by Delegate function)Emit event: Delegation(ValidatorAddress)Emit event: Message(DelegatorAddress)telemetry(Amount, Denom) \ No newline at end of file diff --git a/versioned_docs/version-0.46/integrate/modules/staking/unbond_sequence.svg b/versioned_docs/version-0.46/integrate/modules/staking/unbond_sequence.svg new file mode 100644 index 000000000..7219f200a --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/staking/unbond_sequence.svg @@ -0,0 +1,110 @@ +UndelegatemsgServermsgServerkeeperkeeperstorestorebankKeeperbankKeeperUndelegate(delAddr, valAddr, tokenAmount)calculate number of shares the tokenAmount representsalt[wrong denom]errorUnbond(delAddr, valAddr, shares)BeforeDelegationSharesModified hookalt[no such delegation]erroralt[not enough shares]erroralt[delegator is the operator of the validatorand validator is not already jailedand unbonding would put self-delegation under min threshold]jail the validator, but proceed with unbondingDefault min delegation threshold : 1 sharealt[complete unbonding, all shares removed]remove delegation object[there are still shares delegated (not a complete undbonding)]update delegation objectAfterDelegationModified hookupdate validator power indexupdate validator information (including token amount)alt[validator status is "unbonded" and it has no more tokens]delete the validatorotherwise, do this in EndBlock once validator is unbondedalt[validator is bonded]send tokens from bonded pool to not bonded poolemit event : EventTypeUnbond(delAddr, valAddr, tokenAmount, completion time) \ No newline at end of file diff --git a/versioned_docs/version-0.46/integrate/modules/upgrade/01_concepts.md b/versioned_docs/version-0.46/integrate/modules/upgrade/01_concepts.md new file mode 100644 index 000000000..10ff5ad36 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/upgrade/01_concepts.md @@ -0,0 +1,104 @@ + + +# 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. + +```go +type Plan struct { + Name string + Height int64 + Info string +} +``` + +## 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. + +```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. + +## 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. + +```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 panicking. + +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. + +## Proposal + +Typically, a `Plan` is proposed and submitted through governance via a proposal +containing a `MsgSoftwareUpgrade` message. +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. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/upgrade/v1beta1/tx.proto#L24-L36 + +### Cancelling Upgrade Proposals + +Upgrade proposals can be cancelled. There exists a gov-enabled `MsgCancelUpgrade` +message type, which can be embedded in a proposal, voted on and, if passed, 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. + ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/upgrade/v1beta1/tx.proto#L43-L51 + +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). + +A `MsgCancelUpgrade` proposal can also be made while the original +`MsgSoftwareUpgrade` proposal is still being voted upon, as long as the `VotingPeriod` +ends after the `MsgSoftwareUpgrade` proposal. diff --git a/versioned_docs/version-0.46/integrate/modules/upgrade/02_state.md b/versioned_docs/version-0.46/integrate/modules/upgrade/02_state.md new file mode 100644 index 000000000..7508b2929 --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/upgrade/02_state.md @@ -0,0 +1,20 @@ + + +# 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`. + +* 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)` + +The `x/upgrade` module contains no genesis state. diff --git a/versioned_docs/version-0.46/integrate/modules/upgrade/03_events.md b/versioned_docs/version-0.46/integrate/modules/upgrade/03_events.md new file mode 100644 index 000000000..e4e0e6d5f --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/upgrade/03_events.md @@ -0,0 +1,8 @@ + + +# Events + +The `x/upgrade` does not emit any events by itself. Any and all proposal related +events are emitted through the `x/gov` module. diff --git a/versioned_docs/version-0.46/integrate/modules/upgrade/04_client.md b/versioned_docs/version-0.46/integrate/modules/upgrade/04_client.md new file mode 100644 index 000000000..da55709ee --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/upgrade/04_client.md @@ -0,0 +1,459 @@ + + +# Client + +## CLI + +A user can query and interact with the `upgrade` module using the CLI. + +### Query + +The `query` commands allow users to query `upgrade` state. + +```bash +simd query upgrade --help +``` + +#### applied + +The `applied` command allows users to query the block header for height at which a completed upgrade was 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. + +Example: + +```bash +simd query upgrade applied "test-upgrade" +``` + +Example Output: + +```bash +"block_id": { + "hash": "A769136351786B9034A5F196DC53F7E50FCEB53B48FA0786E1BFC45A0BB646B5", + "parts": { + "total": 1, + "hash": "B13CBD23011C7480E6F11BE4594EE316548648E6A666B3575409F8F16EC6939E" + } + }, + "block_size": "7213", + "header": { + "version": { + "block": "11" + }, + "chain_id": "testnet-2", + "height": "455200", + "time": "2021-04-10T04:37:57.085493838Z", + "last_block_id": { + "hash": "0E8AD9309C2DC411DF98217AF59E044A0E1CCEAE7C0338417A70338DF50F4783", + "parts": { + "total": 1, + "hash": "8FE572A48CD10BC2CBB02653CA04CA247A0F6830FF19DC972F64D339A355E77D" + } + }, + "last_commit_hash": "DE890239416A19E6164C2076B837CC1D7F7822FC214F305616725F11D2533140", + "data_hash": "E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855", + "validators_hash": "A31047ADE54AE9072EE2A12FF260A8990BA4C39F903EAF5636B50D58DBA72582", + "next_validators_hash": "A31047ADE54AE9072EE2A12FF260A8990BA4C39F903EAF5636B50D58DBA72582", + "consensus_hash": "048091BC7DDC283F77BFBF91D73C44DA58C3DF8A9CBC867405D8B7F3DAADA22F", + "app_hash": "28ECC486AFC332BA6CC976706DBDE87E7D32441375E3F10FD084CD4BAF0DA021", + "last_results_hash": "E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855", + "evidence_hash": "E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855", + "proposer_address": "2ABC4854B1A1C5AA8403C4EA853A81ACA901CC76" + }, + "num_txs": "0" +} +``` + +#### module versions + +The `module_versions` command gets a list of module names and their respective consensus versions. + +Following the command with a specific module name will return only +that module's information. + +```bash +simd query upgrade module_versions [optional module_name] [flags] +``` + +Example: + +```bash +simd query upgrade module_versions +``` + +Example Output: + +```bash +module_versions: +- name: auth + version: "2" +- name: authz + version: "1" +- name: bank + version: "2" +- name: capability + version: "1" +- name: crisis + version: "1" +- name: distribution + version: "2" +- name: evidence + version: "1" +- name: feegrant + version: "1" +- name: genutil + version: "1" +- name: gov + version: "2" +- name: ibc + version: "2" +- name: mint + version: "1" +- name: params + version: "1" +- name: slashing + version: "2" +- name: staking + version: "2" +- name: transfer + version: "1" +- name: upgrade + version: "1" +- name: vesting + version: "1" +``` + +Example: + +```bash +regen query upgrade module_versions ibc +``` + +Example Output: + +```bash +module_versions: +- name: ibc + version: "2" +``` + +#### plan + +The `plan` command gets the currently scheduled upgrade plan, if one exists. + +```bash +regen query upgrade plan [flags] +``` + +Example: + +```bash +simd query upgrade plan +``` + +Example Output: + +```bash +height: "130" +info: "" +name: test-upgrade +time: "0001-01-01T00:00:00Z" +upgraded_client_state: null +``` + +## REST + +A user can query the `upgrade` module using REST endpoints. + +### Applied Plan + +`AppliedPlan` queries a previously applied upgrade plan by its name. + +```bash +/cosmos/upgrade/v1beta1/applied_plan/{name} +``` + +Example: + +```bash +curl -X GET "http://localhost:1317/cosmos/upgrade/v1beta1/applied_plan/v2.0-upgrade" -H "accept: application/json" +``` + +Example Output: + +```bash +{ + "height": "30" +} +``` + +### Current Plan + +`CurrentPlan` queries the current upgrade plan. + +```bash +/cosmos/upgrade/v1beta1/current_plan +``` + +Example: + +```bash +curl -X GET "http://localhost:1317/cosmos/upgrade/v1beta1/current_plan" -H "accept: application/json" +``` + +Example Output: + +```bash +{ + "plan": "v2.1-upgrade" +} +``` + +### Module versions + +`ModuleVersions` queries the list of module versions from state. + +```bash +/cosmos/upgrade/v1beta1/module_versions +``` + +Example: + +```bash +curl -X GET "http://localhost:1317/cosmos/upgrade/v1beta1/module_versions" -H "accept: application/json" +``` + +Example Output: + +```bash +{ + "module_versions": [ + { + "name": "auth", + "version": "2" + }, + { + "name": "authz", + "version": "1" + }, + { + "name": "bank", + "version": "2" + }, + { + "name": "capability", + "version": "1" + }, + { + "name": "crisis", + "version": "1" + }, + { + "name": "distribution", + "version": "2" + }, + { + "name": "evidence", + "version": "1" + }, + { + "name": "feegrant", + "version": "1" + }, + { + "name": "genutil", + "version": "1" + }, + { + "name": "gov", + "version": "2" + }, + { + "name": "ibc", + "version": "2" + }, + { + "name": "mint", + "version": "1" + }, + { + "name": "params", + "version": "1" + }, + { + "name": "slashing", + "version": "2" + }, + { + "name": "staking", + "version": "2" + }, + { + "name": "transfer", + "version": "1" + }, + { + "name": "upgrade", + "version": "1" + }, + { + "name": "vesting", + "version": "1" + } + ] +} +``` + +## gRPC + +A user can query the `upgrade` module using gRPC endpoints. + +### Applied Plan + +`AppliedPlan` queries a previously applied upgrade plan by its name. + +```bash +cosmos.upgrade.v1beta1.Query/AppliedPlan +``` + +Example: + +```bash +grpcurl -plaintext \ + -d '{"name":"v2.0-upgrade"}' \ + localhost:9090 \ + cosmos.upgrade.v1beta1.Query/AppliedPlan +``` + +Example Output: + +```bash +{ + "height": "30" +} +``` + +### Current Plan + +`CurrentPlan` queries the current upgrade plan. + +```bash +cosmos.upgrade.v1beta1.Query/CurrentPlan +``` + +Example: + +```bash +grpcurl -plaintext localhost:9090 cosmos.slashing.v1beta1.Query/CurrentPlan +``` + +Example Output: + +```bash +{ + "plan": "v2.1-upgrade" +} +``` + +### Module versions + +`ModuleVersions` queries the list of module versions from state. + +```bash +cosmos.upgrade.v1beta1.Query/ModuleVersions +``` + +Example: + +```bash +grpcurl -plaintext localhost:9090 cosmos.slashing.v1beta1.Query/ModuleVersions +``` + +Example Output: + +```bash +{ + "module_versions": [ + { + "name": "auth", + "version": "2" + }, + { + "name": "authz", + "version": "1" + }, + { + "name": "bank", + "version": "2" + }, + { + "name": "capability", + "version": "1" + }, + { + "name": "crisis", + "version": "1" + }, + { + "name": "distribution", + "version": "2" + }, + { + "name": "evidence", + "version": "1" + }, + { + "name": "feegrant", + "version": "1" + }, + { + "name": "genutil", + "version": "1" + }, + { + "name": "gov", + "version": "2" + }, + { + "name": "ibc", + "version": "2" + }, + { + "name": "mint", + "version": "1" + }, + { + "name": "params", + "version": "1" + }, + { + "name": "slashing", + "version": "2" + }, + { + "name": "staking", + "version": "2" + }, + { + "name": "transfer", + "version": "1" + }, + { + "name": "upgrade", + "version": "1" + }, + { + "name": "vesting", + "version": "1" + } + ] +} +``` diff --git a/versioned_docs/version-0.46/integrate/modules/upgrade/README.md b/versioned_docs/version-0.46/integrate/modules/upgrade/README.md new file mode 100644 index 000000000..73ea2268a --- /dev/null +++ b/versioned_docs/version-0.46/integrate/modules/upgrade/README.md @@ -0,0 +1,31 @@ + + +# `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. + +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)** + * [CLI](04_client.md#cli) + * [REST](04_client.md#rest) + * [gRPC](04_client.md#grpc) diff --git a/versioned_docs/version-0.46/integrate/rfc/README.md b/versioned_docs/version-0.46/integrate/rfc/README.md deleted file mode 100644 index be74d080d..000000000 --- a/versioned_docs/version-0.46/integrate/rfc/README.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -sidebar_position: 1 ---- - -# Requests for Comments - -A Request for Comments (RFC) is a record of discussion on an open-ended topic -related to the design and implementation of the Cosmos SDK, for which no -immediate decision is required. - -The purpose of an RFC is to serve as a historical record of a high-level -discussion that might otherwise only be recorded in an ad-hoc way (for example, -via gists or Google docs) that are difficult to discover for someone after the -fact. An RFC _may_ give rise to more specific architectural _decisions_ for -the Cosmos SDK, but those decisions must be recorded separately in -[Architecture Decision Records (ADR)](../architecture). - -As a rule of thumb, if you can articulate a specific question that needs to be -answered, write an ADR. If you need to explore the topic and get input from -others to know what questions need to be answered, an RFC may be appropriate. - -## RFC Content - -An RFC should provide: - -* A **changelog**, documenting when and how the RFC has changed. -* An **abstract**, briefly summarizing the topic so the reader can quickly tell - whether it is relevant to their interest. -* Any **background** a reader will need to understand and participate in the - substance of the discussion (links to other documents are fine here). -* The **discussion**, the primary content of the document. - -The [rfc-template.md](rfc-template.md) file includes placeholders for these -sections. diff --git a/versioned_docs/version-0.46/user/run-node/README.md b/versioned_docs/version-0.46/user/run-node/README.md new file mode 100644 index 000000000..ec6eca8bd --- /dev/null +++ b/versioned_docs/version-0.46/user/run-node/README.md @@ -0,0 +1,17 @@ + + +# Running a Node, API and 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) +6. [Rosetta API](./rosetta.md) +7. [Running a Testnet](./run-testnet.md) diff --git a/versioned_docs/version-0.46/user/run-node/interact-node.md b/versioned_docs/version-0.46/user/run-node/interact-node.md new file mode 100644 index 000000000..0daf04e51 --- /dev/null +++ b/versioned_docs/version-0.46/user/run-node/interact-node.md @@ -0,0 +1,252 @@ + + +# Interacting with the Node + +There are multiple ways to interact with a node: using the CLI, using gRPC or using the REST endpoints. {synopsis} + +## Pre-requisite Readings + +* [gRPC, REST and Tendermint Endpoints](../core/grpc_rest.md) {prereq} +* [Running a Node](./run-node.md) {prereq} + +## Using the CLI + +Now that your chain is running, it is time to try sending tokens from the first account you created to a second account. In a new terminal window, start by running the following query command: + +```bash +simd query bank balances $MY_VALIDATOR_ADDRESS --chain-id my-test-chain +``` + +You should see the current balance of the account you created, equal to the original balance of `stake` you granted it minus the amount you delegated via the `gentx`. Now, create a second account: + +```bash +simd keys add recipient --keyring-backend test + +# Put the generated address in a variable for later use. +RECIPIENT=$(simd keys show recipient -a --keyring-backend test) +``` + +The command above creates a local key-pair that is not yet registered on the chain. An account is created the first time it receives tokens from another account. Now, run the following command to send tokens to the `recipient` account: + +```bash +simd tx bank send $MY_VALIDATOR_ADDRESS $RECIPIENT 1000000stake --chain-id my-test-chain --keyring-backend test + +# Check that the recipient account did receive the tokens. +simd query bank balances $RECIPIENT --chain-id my-test-chain +``` + +Finally, delegate some of the stake tokens sent to the `recipient` account to the validator: + +```bash +simd tx staking delegate $(simd keys show my_validator --bech val -a --keyring-backend test) 500stake --from recipient --chain-id my-test-chain --keyring-backend test + +# Query the total delegations to `validator`. +simd query staking delegations-to $(simd keys show my_validator --bech val -a --keyring-backend test) --chain-id my-test-chain +``` + +You should see two delegations, the first one made from the `gentx`, and the second one you just performed from the `recipient` account. + +## Using gRPC + +The Protobuf ecosystem developed tools for different use cases, including code-generation from `*.proto` files into various languages. These tools allow 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). + +Since the code generation library largely depends on your own tech stack, we will only present three alternatives: + +* `grpcurl` for generic debugging and testing, +* programmatically via Go, +* CosmJS for JavaScript/TypeScript developers. + +### grpcurl + +[grpcurl](https://github.com/fullstorydev/grpcurl) is like `curl` but for gRPC. It is also available as a Go library, but we will use it only as a CLI command for debugging and testing purposes. Follow the instructions in the previous link to install it. + +Assuming you have a local node running (either a localnet, or connected a live network), you should be able to run the following command to list the Protobuf services available (you can replace `localhost:9000` by the gRPC server endpoint of another node, which is configured under the `grpc.address` field inside [`app.toml`](../run-node/run-node.md#configuring-the-node-using-apptoml)): + +```bash +grpcurl -plaintext localhost:9090 list +``` + +You should see a list of gRPC services, like `cosmos.bank.v1beta1.Query`. This is called reflection, which is a Protobuf endpoint returning a description of all available endpoints. Each of these represents a different Protobuf service, and each service exposes multiple RPC methods you can query against. + +In order to get a description of the service you can run the following command: + +```bash +grpcurl \ + localhost:9090 \ + describe cosmos.bank.v1beta1.Query # Service we want to inspect +``` + +It's also possible to execute an RPC call to query the node for information: + +```bash +grpcurl \ + -plaintext + -d '{"address":"$MY_VALIDATOR"}' \ + localhost:9090 \ + cosmos.bank.v1beta1.Query/AllBalances +``` + +The list of all available gRPC query endpoints is [coming soon](https://github.com/cosmos/cosmos-sdk/issues/7786). + +#### Query for historical state using grpcurl + +You may also query for historical data by passing some [gRPC metadata](https://github.com/grpc/grpc-go/blob/master/Documentation/grpc-metadata.md) to the query: the `x-cosmos-block-height` metadata should contain the block to query. Using grpcurl as above, the command looks like: + +```bash +grpcurl \ + -plaintext \ + -H "x-cosmos-block-height: 279256" \ + -d '{"address":"$MY_VALIDATOR"}' \ + localhost:9090 \ + cosmos.bank.v1beta1.Query/AllBalances +``` + +Assuming the state at that block has not yet been pruned by the node, this query should return a non-empty response. + +### Programmatically via Go + +The following snippet shows how to query the state using gRPC inside a Go program. The idea is to create a gRPC connection, and use the Protobuf-generated client code to query the gRPC server. + +#### Install Cosmos SDK + +Add below line to `go.mod` to replace protobuf, read more [#8469](https://github.com/cosmos/cosmos-sdk/issues/8469) + +```go +replace github.com/gogo/protobuf => github.com/regen-network/protobuf v1.3.3-alpha.regen.1 +``` + +```bash +go get github.com/cosmos/cosmos-sdk@main +``` + +```go +import ( + "context" + "fmt" + + "google.golang.org/grpc" + + "github.com/cosmos/cosmos-sdk/codec" + sdk "github.com/cosmos/cosmos-sdk/types" + banktypes "github.com/cosmos/cosmos-sdk/x/bank/types" +) + +func queryState() error { + myAddress, err := sdk.AccAddressFromBech32("cosmos1...") + if err != nil { + return err + } + + // Create a connection to the gRPC server. + grpcConn, err := grpc.Dial( + "127.0.0.1:9090", // your gRPC server address. + grpc.WithInsecure(), // The Cosmos SDK doesn't support any transport security mechanism. + // This instantiates a general gRPC codec which handles proto bytes. We pass in a nil interface registry + // if the request/response types contain interface instead of 'nil' you should pass the application specific codec. + grpc.WithDefaultCallOptions(grpc.ForceCodec(codec.NewProtoCodec(nil).GRPCCodec())), + ) + if err != nil { + return err + } + defer grpcConn.Close() + + // This creates a gRPC client to query the x/bank service. + bankClient := banktypes.NewQueryClient(grpcConn) + bankRes, err := bankClient.Balance( + context.Background(), + &banktypes.QueryBalanceRequest{Address: myAddress.String(), Denom: "atom"}, + ) + if err != nil { + return err + } + + fmt.Println(bankRes.GetBalance()) // Prints the account balance + + return nil +} +``` + +You can replace the query client (here we are using `x/bank`'s) with one generated from any other Protobuf service. The list of all available gRPC query endpoints is [coming soon](https://github.com/cosmos/cosmos-sdk/issues/7786). + +#### Query for historical state using Go + +Querying for historical blocks is done by adding the block height metadata in the gRPC request. + +```go +import ( + "context" + "fmt" + + "google.golang.org/grpc" + "google.golang.org/grpc/metadata" + + "github.com/cosmos/cosmos-sdk/codec" + sdk "github.com/cosmos/cosmos-sdk/types" + grpctypes "github.com/cosmos/cosmos-sdk/types/grpc" + banktypes "github.com/cosmos/cosmos-sdk/x/bank/types" +) + +func queryState() error { + // --snip-- + + var header metadata.MD + bankRes, err = bankClient.Balance( + metadata.AppendToOutgoingContext(context.Background(), grpctypes.GRPCBlockHeightHeader, "12"), // Add metadata to request + &banktypes.QueryBalanceRequest{Address: myAddress.String(), Denom: "atom"}, + grpc.Header(&header), // Retrieve header from response + ) + if err != nil { + return err + } + blockHeight := header.Get(grpctypes.GRPCBlockHeightHeader) + + fmt.Println(blockHeight) // Prints the block height (12) + + return nil +} +``` + +### CosmJS + +CosmJS documentation can be found at [https://cosmos.github.io/cosmjs](https://cosmos.github.io/cosmjs). As of January 2021, CosmJS documentation is still work in progress. + +## Using the REST Endpoints + +As described in the [gRPC guide](../core/grpc_rest.md), all gRPC services on the Cosmos SDK are made available for more convenient REST-based queries through gRPC-gateway. The format of the URL path is based on the Protobuf service method's full-qualified name, but may contain small customizations so that final URLs look more idiomatic. For example, the REST endpoint for the `cosmos.bank.v1beta1.Query/AllBalances` method is `GET /cosmos/bank/v1beta1/balances/{address}`. Request arguments are passed as query parameters. + +As a concrete example, the `curl` command to make balances request is: + +```bash +curl \ + -X GET \ + -H "Content-Type: application/json" \ + http://localhost:1317/cosmos/bank/v1beta1/balances/$MY_VALIDATOR +``` + +Make sure to replace `localhost:1317` with the REST endpoint of your node, configured under the `api.address` field. + +The list of all available REST endpoints is available as a Swagger specification file, it can be viewed at `localhost:1317/swagger`. Make sure that the `api.swagger` field is set to true in your [`app.toml`](../run-node/run-node.md#configuring-the-node-using-apptoml) file. + +### Query for historical state using REST + +Querying for historical state is done using the HTTP header `x-cosmos-block-height`. For example, a curl command would look like: + +```bash +curl \ + -X GET \ + -H "Content-Type: application/json" \ + -H "x-cosmos-block-height: 279256" + http://localhost:1317/cosmos/bank/v1beta1/balances/$MY_VALIDATOR +``` + +Assuming the state at that block has not yet been pruned by the node, this query should return a non-empty response. + +### Cross-Origin Resource Sharing (CORS) + +[CORS policies](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) are not enabled by default to help with security. If you would like to use the rest-server in a public environment we recommend you provide a reverse proxy, this can be done with [nginx](https://www.nginx.com/). For testing and development purposes there is an `enabled-unsafe-cors` field inside [`app.toml`](../run-node/run-node.md#configuring-the-node-using-apptoml). + +## Next {hide} + +Sending transactions using gRPC and REST requires some additional steps: generating the transaction, signing it, and finally broadcasting it. Read about [generating and signing transactions](./txs.md). {hide} diff --git a/versioned_docs/version-0.46/user/run-node/keyring.md b/versioned_docs/version-0.46/user/run-node/keyring.md new file mode 100644 index 000000000..8506ef4c0 --- /dev/null +++ b/versioned_docs/version-0.46/user/run-node/keyring.md @@ -0,0 +1,136 @@ + + +# Setting up the keyring + +This document describes how to configure and use the keyring and its various backends for an [**application**](../basics/app-anatomy.md). {synopsis} + +The keyring holds the private/public keypairs used to interact with a node. For instance, a validator key needs to be set up before running the blockchain node, so that blocks can be correctly signed. The private key can be stored in different locations, called "backends", such as a file or the operating system's own key storage. + +## Available backends for the keyring + +Starting with the v0.38.0 release, Cosmos SDK comes with a new keyring implementation +that provides a set of commands to manage cryptographic keys in a secure fashion. The +new keyring supports multiple storage backends, some of which may not be available on +all operating systems. + +### The `os` backend + +The `os` backend relies on operating system-specific defaults to handle key storage +securely. Typically, an operating system's credential sub-system handles password prompts, +private keys storage, and user sessions according to the user's password policies. Here +is a list of the most popular operating systems and their respective passwords manager: + +* macOS (since Mac OS 8.6): [Keychain](https://support.apple.com/en-gb/guide/keychain-access/welcome/mac) +* Windows: [Credentials Management API](https://docs.microsoft.com/en-us/windows/win32/secauthn/credentials-management) +* GNU/Linux: + * [libsecret](https://gitlab.gnome.org/GNOME/libsecret) + * [kwallet](https://api.kde.org/frameworks/kwallet/html/index.html) + +GNU/Linux distributions that use GNOME as default desktop environment typically come with +[Seahorse](https://wiki.gnome.org/Apps/Seahorse). Users of KDE based distributions are +commonly provided with [KDE Wallet Manager](https://userbase.kde.org/KDE_Wallet_Manager). +Whilst the former is in fact a `libsecret` convenient frontend, the latter is a `kwallet` +client. + +`os` is the default option since operating system's default credentials managers are +designed to meet users' most common needs and provide them with a comfortable +experience without compromising on security. + +The recommended backends for headless environments are `file` and `pass`. + +### The `file` backend + +The `file` backend more closely resembles the keybase implementation used prior to +v0.38.1. It stores the keyring encrypted within the app's configuration directory. This +keyring will request a password each time it is accessed, which may occur multiple +times in a single command resulting in repeated password prompts. If using bash scripts +to execute commands using the `file` option you may want to utilize the following format +for multiple prompts: + +```sh +# assuming that KEYPASSWD is set in the environment +$ gaiacli config keyring-backend file # use file backend +$ (echo $KEYPASSWD; echo $KEYPASSWD) | gaiacli keys add me # multiple prompts +$ echo $KEYPASSWD | gaiacli keys show me # single prompt +``` + +::: tip +The first time you add a key to an empty keyring, you will be prompted to type the password twice. +::: + +### The `pass` backend + +The `pass` backend uses the [pass](https://www.passwordstore.org/) utility to manage on-disk +encryption of keys' sensitive data and metadata. Keys are stored inside `gpg` encrypted files +within app-specific directories. `pass` is available for the most popular UNIX +operating systems as well as GNU/Linux distributions. Please refer to its manual page for +information on how to download and install it. + +::: tip +**pass** uses [GnuPG](https://gnupg.org/) for encryption. `gpg` automatically invokes the `gpg-agent` +daemon upon execution, which handles the caching of GnuPG credentials. Please refer to `gpg-agent` +man page for more information on how to configure cache parameters such as credentials TTL and +passphrase expiration. +::: + +The password store must be set up prior to first use: + +```sh +pass init +``` + +Replace `` with your GPG key ID. You can use your personal GPG key or an alternative +one you may want to use specifically to encrypt the password store. + +### The `kwallet` backend + +The `kwallet` backend uses `KDE Wallet Manager`, which comes installed by default on the +GNU/Linux distributions that ships KDE as default desktop environment. Please refer to +[KWallet Handbook](https://docs.kde.org/stable5/en/kdeutils/kwallet5/index.html) for more +information. + +### The `test` backend + +The `test` backend is a password-less variation of the `file` backend. Keys are stored +unencrypted on disk. + +**Provided for testing purposes only. The `test` backend is not recommended for use in production environments**. + +### The `memory` backend + +The `memory` backend stores keys in memory. The keys are immediately deleted after the program has exited. + +**Provided for testing purposes only. The `memory` backend is not recommended for use in production environments**. + +## Adding keys to the keyring + +::: warning +Make sure you can build your own binary, and replace `simd` with the name of your binary in the snippets. +::: + +Applications developed using the Cosmos SDK come with the `keys` subcommand. For the purpose of this tutorial, we're running the `simd` CLI, which is an application built using the Cosmos SDK for testing and educational purposes. For more information, see [`simapp`](https://github.com/cosmos/cosmos-sdk/tree/main/simapp). + +You can use `simd keys` for help about the keys command and `simd keys [command] --help` for more information about a particular subcommand. + +::: tip +You can also enable auto-completion with the `simd completion` command. For example, at the start of a bash session, run `. <(simd completion)`, and all `simd` subcommands will be auto-completed. +::: + +To create a new key in the keyring, run the `add` subcommand with a `` argument. For the purpose of this tutorial, we will solely use the `test` backend, and call our new key `my_validator`. This key will be used in the next section. + +```bash +$ simd keys add my_validator --keyring-backend test + +# Put the generated address in a variable for later use. +MY_VALIDATOR_ADDRESS=$(simd keys show my_validator -a --keyring-backend test) +``` + +This command generates a new 24-word mnemonic phrase, persists it to the relevant backend, and outputs information about the keypair. If this keypair will be used to hold value-bearing tokens, be sure to write down the mnemonic phrase somewhere safe! + +By default, the keyring generates a `secp256k1` keypair. The keyring also supports `ed25519` keys, which may be created by passing the `--algo ed25519` flag. A keyring can of course hold both types of keys simultaneously, and the Cosmos SDK's `x/auth` module (in particular its [middlewares](../core/baseapp.md#middleware)) supports natively these two public key algorithms. + +## Next {hide} + +Read about [running a node](./run-node.md) {hide} diff --git a/versioned_docs/version-0.46/user/run-node/rosetta.md b/versioned_docs/version-0.46/user/run-node/rosetta.md new file mode 100644 index 000000000..e3d94492f --- /dev/null +++ b/versioned_docs/version-0.46/user/run-node/rosetta.md @@ -0,0 +1,112 @@ + + +# 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). + +## Add Rosetta Command + +The Rosetta API server is a stand-alone server that connects to a node of a chain developed with 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`). + +Import the `server` package: + +```go + "github.com/cosmos/cosmos-sdk/server" +``` + +Find the following line: + +```go +initRootCmd(rootCmd, encodingConfig) +``` + +After that line, add the following: + +```go +rootCmd.AddCommand( + server.RosettaCommand(encodingConfig.InterfaceRegistry, encodingConfig.Codec) +) +``` + +The `RosettaCommand` function builds the `rosetta` root command and is defined in the `server` package within Cosmos SDK. + +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. + +An implementation example can be found in `simapp` package. + +## Use Rosetta Command + +To run Rosetta in your application CLI, use the following command: + +```sh +appd rosetta --help +``` + +To test and run Rosetta API endpoints for applications that are running and exposed, use the following command: + +```sh +appd rosetta + --blockchain "your application name (ex: gaia)" + --network "your chain identifier (ex: testnet-1)" + --tendermint "tendermint endpoint (ex: localhost:26657)" + --grpc "gRPC endpoint (ex: localhost:9090)" + --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`. + +### Client interface override + +In case more customization is required, it's possible to embed the Client type and override the methods which require customizations. + +Example: + +```go +package custom_client +import ( + +"context" +"github.com/coinbase/rosetta-sdk-go/types" +"github.com/cosmos/cosmos-sdk/server/rosetta/lib" +) + +// CustomClient embeds the standard cosmos client +// which means that it implements the cosmos-rosetta-gateway Client +// interface while at the same time allowing to customize certain methods +type CustomClient struct { + *rosetta.Client +} + +func (c *CustomClient) ConstructionPayload(_ context.Context, request *types.ConstructionPayloadsRequest) (resp *types.ConstructionPayloadsResponse, err error) { + // provide custom signature bytes + panic("implement me") +} +``` + +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. + +Example: + +```go +package custom_errors +import crgerrs "github.com/cosmos/cosmos-sdk/server/rosetta/lib/errors" + +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. diff --git a/versioned_docs/version-0.46/user/run-node/run-node.md b/versioned_docs/version-0.46/user/run-node/run-node.md new file mode 100644 index 000000000..19f2aa6bc --- /dev/null +++ b/versioned_docs/version-0.46/user/run-node/run-node.md @@ -0,0 +1,167 @@ + + +# 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/main/simapp), and its corresponding CLI binary `simd`. {synopsis} + +## Pre-requisite Readings + +* [Anatomy of a Cosmos SDK Application](../basics/app-anatomy.md) {prereq} +* [Setting up the keyring](./keyring.md) {prereq} + +## Initialize the Chain + +::: warning +Make sure you can build your own binary, and replace `simd` with the name of your binary in the snippets. +::: + +Before actually running the node, we need to initialize the chain, and most importantly its genesis file. This is done with the `init` subcommand: + +```bash +# The argument is the custom username of your node, it should be human-readable. +simd init --chain-id my-test-chain +``` + +The command above creates all the configuration files needed for your node to run, as well as a default genesis file, which defines the initial state of the network. All these configuration files are in `~/.simapp` by default, but you can overwrite the location of this folder by passing the `--home` flag. + +The `~/.simapp` folder has the following structure: + +```bash +. # ~/.simapp + |- data # Contains the databases used by the node. + |- config/ + |- app.toml # Application-related configuration file. + |- config.toml # Tendermint-related configuration file. + |- genesis.json # The genesis file. + |- node_key.json # Private key to use for node authentication in the p2p protocol. + |- priv_validator_key.json # Private key to use as a validator in the consensus protocol. +``` + +## 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. + +```bash +# to change the chain-id +jq '.chain_id = "testing"' genesis.json > temp.json && mv temp.json genesis.json + +# to enable the api server +sed -i '/\[api\]/,+3 s/enable = false/enable = true/' app.toml + +# to change the voting_period +jq '.app_state.gov.voting_params.voting_period = "600s"' genesis.json > temp.json && mv temp.json genesis.json + +# to change the inflation +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). + +Now that you have created a local account, go ahead and grant it some `stake` tokens in your chain's genesis file. Doing so will also make sure your chain is aware of this account's existence: + +```bash +simd add-genesis-account $MY_VALIDATOR_ADDRESS 100000000000stake +``` + +Recall that `$MY_VALIDATOR_ADDRESS` is a variable that holds the address of the `my_validator` key in the [keyring](./keyring.md#adding-keys-to-the-keyring). Also note that the tokens in the 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/main/simapp). For your own chain with its own staking denom, that token identifier should be used instead. + +Now that your account has some tokens, you need to add a validator to your chain. Validators are special full-nodes that participate in the consensus process (implemented in the [underlying consensus engine](../intro/sdk-app-architecture.md#tendermint)) in order to add new blocks to the chain. Any account can declare its intention to become a validator operator, but only those with sufficient delegation get to enter the active set (for example, only the top 125 validator candidates with the most delegation get to be validators in the Cosmos Hub). For this guide, you will add your local node (created via the `init` command above) as a validator of your chain. Validators can be declared before a chain is first started via a special transaction included in the genesis file called a `gentx`: + +```bash +# Create a gentx. +simd gentx my_validator 100000000stake --chain-id my-test-chain --keyring-backend test + +# Add the gentx to the genesis file. +simd collect-gentxs +``` + +A `gentx` does three things: + +1. Registers the `validator` account you created as a validator operator account (i.e. the account that controls the validator). +2. Self-delegates the provided `amount` of staking tokens. +3. Link the operator account with a Tendermint node pubkey that will be used for signing blocks. If no `--pubkey` flag is provided, it defaults to the local node pubkey created via the `simd init` command above. + +For more information on `gentx`, use the following command: + +```bash +simd gentx --help +``` + +## Configuring the Node Using `app.toml` and `config.toml` + +The Cosmos SDK automatically generates two configuration files inside `~/.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... + +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: + +```toml + # The minimum gas prices a validator is willing to accept for processing a + # transaction. A transaction's fees must meet the minimum of any denomination + # specified in this config (e.g. 0.25token1;0.0001token2). + minimum-gas-prices = "0stake" +``` + +## Run a Localnet + +Now that everything is set up, you can finally start your node: + +```bash +simd start +``` + +> Note: By default nodes are run in full node mode. Running a local network means in most cases, the node is the only node in the network, requiring you to set the mode. + +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.46.0-rc1/docker-compose.yml). + +## State Sync + +State sync is the act in which a node syncs the latest or close to the latest state of a blockchain. This is useful for users who don't want to sync all the blocks in history. Read more in [CometBFT documentation](https://docs.cometbft.com/v0.34/core/state-sync). + +State sync works thanks to snapshots. Read how the SDK handles snapshots [here](https://github.com/cosmos/cosmos-sdk/blob/825245d/store/snapshots/README.md). + +### Local State Sync + +Local state sync work similar to normal state sync except that it works off a local snapshot of state instead of one provided via the p2p network. The steps to start local state sync are similar to normal state sync with a few different designs. + +1. As mentioned in https://docs.cometbft.com/v0.34/core/state-sync, one must set a height and hash in the config.toml along with a few rpc servers (the afromentioned link has instructions on how to do this). +2. Run ` ` to restore a local snapshot (note: first load it from a file with the *load* command). +3. Bootsrapping Comet state in order to start the node after the snapshot has been ingested. This can be done with the bootstrap command ` tendermint bootstrap-state` + +### Snapshots Commands + +The Cosmos SDK provides commands for managing snapshots. +These commands can be added in an app with the following snippet in `cmd//root.go`: + +```go +import ( + "github.com/cosmos/cosmos-sdk/client/snapshot" +) + +func initRootCmd(/* ... */) { + // ... + rootCmd.AddCommand( + snapshot.Cmd(appCreator), + ) +} +``` + +Then following commands are available at ` snapshots [command]`: + +* **list**: list local snapshots +* **load**: Load a snapshot archive file into snapshot store +* **restore**: Restore app state from local snapshot +* **export**: Export app state to snapshot store +* **dump**: Dump the snapshot as portable archive format +* **delete**: Delete a local snapshot diff --git a/versioned_docs/version-0.46/user/run-node/run-testnet.md b/versioned_docs/version-0.46/user/run-node/run-testnet.md new file mode 100644 index 000000000..55ad21d67 --- /dev/null +++ b/versioned_docs/version-0.46/user/run-node/run-testnet.md @@ -0,0 +1,99 @@ + + +# Running a Testnet + +The `simd testnet` subcommand makes it easy to initialize and start a simulated test network for testing purposes. {synopsis} + +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. + +## Initialize Files + +First, let's take a look at the `init-files` subcommand. + +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. + +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)). + +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. + +### 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. + +### 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). + +## Start Testnet + +Now, let's take a look at the `start` subcommand. + +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. + +You can start the local test network by running the following command: + +```bash +simd testnet start +``` + +You should see something similar to the following: + +```bash +acquiring test network lock +preparing test network with chain-id "chain-mtoD9v" + + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++ THIS MNEMONIC IS FOR TESTING PURPOSES ONLY ++ +++ DO NOT USE IN PRODUCTION ++ +++ ++ +++ sustain know debris minute gate hybrid stereo custom ++ +++ divorce cross spoon machine latin vibrant term oblige ++ +++ moment beauty laundry repeat grab game bronze truly ++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + + +starting test network... +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). + +Check the status of the first validator node: + +```sh +simd status +``` + +Import the key from the provided mnemonic: + +```sh +simd keys add test --recover --keyring-backend test +``` + +Check the balance of the account address: + +```sh +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. diff --git a/versioned_docs/version-0.46/user/run-node/txs.md b/versioned_docs/version-0.46/user/run-node/txs.md new file mode 100644 index 000000000..9674d32f4 --- /dev/null +++ b/versioned_docs/version-0.46/user/run-node/txs.md @@ -0,0 +1,383 @@ + + +# Generating, Signing and Broadcasting Transactions + +This document describes how to generate an (unsigned) transaction, signing it (with one or multiple keys), and broadcasting it to the network. {synopsis} + +## Using the CLI + +The easiest way to send transactions is using the CLI, as we have seen in the previous page when [interacting with a node](./interact-node.md#using-the-cli). For example, running the following command + +```bash +simd tx bank send $MY_VALIDATOR_ADDRESS $RECIPIENT 1000stake --chain-id my-test-chain --keyring-backend test +``` + +will run the following steps: + +* generate a transaction with one `Msg` (`x/bank`'s `MsgSend`), and print the generated transaction to the console. +* ask the user for confirmation to send the transaction from the `$MY_VALIDATOR_ADDRESS` account. +* fetch `$MY_VALIDATOR_ADDRESS` 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. + +The CLI bundles all the necessary steps into a simple-to-use user experience. However, it's possible to run all the steps individually too. + +### Generating a Transaction + +Generating a transaction can simply be done by appending the `--generate-only` flag on any `tx` command, e.g.: + +```bash +simd tx bank send $MY_VALIDATOR_ADDRESS $RECIPIENT 1000stake --chain-id my-test-chain --generate-only +``` + +This will output the unsigned transaction as JSON in the console. We can also save the unsigned transaction to a file (to be passed around between signers more easily) by appending `> unsigned_tx.json` to the above command. + +### Signing a Transaction + +Signing a transaction using the CLI requires the unsigned transaction to be saved in a file. Let's assume the unsigned transaction is in a file called `unsigned_tx.json` in the current directory (see previous paragraph on how to do that). Then, simply run the following command: + +```bash +simd tx sign unsigned_tx.json --chain-id my-test-chain --keyring-backend test --from $MY_VALIDATOR_ADDRESS +``` + +This command will decode the unsigned transaction and sign it with `SIGN_MODE_DIRECT` with `$MY_VALIDATOR_ADDRESS`'s key, which we already set up in the keyring. The signed transaction will be output as JSON to the console, and, as above, we can save it to a file by appending `> signed_tx.json`. + +Some useful flags to consider in the `tx sign` command: + +* `--sign-mode`: you may use `amino-json` to sign the transaction using `SIGN_MODE_LEGACY_AMINO_JSON`, +* `--offline`: sign in offline mode. This means that the `tx sign` command doesn't connect to the node to retrieve the signer's account number and sequence, both needed for signing. In this case, you must manually supply the `--account-number` and `--sequence` flags. This is useful for offline signing, i.e. signing in a secure environment which doesn't have access to the internet. + +#### Signing with Multiple Signers + +::: warning +Please note that signing a transaction with multiple signers or with a multisig account, where at least one signer uses `SIGN_MODE_DIRECT`, is not yet possible. You may follow [this Github issue](https://github.com/cosmos/cosmos-sdk/issues/8141) for more info. +::: + +Signing with multiple signers is done with the `tx multisign` command. This command assumes that all signers use `SIGN_MODE_LEGACY_AMINO_JSON`. The flow is similar to the `tx sign` command flow, but instead of signing an unsigned transaction file, each signer signs the file signed by previous signer(s). The `tx multisign` command will append signatures to the existing transactions. It is important that signers sign the transaction **in the same order** as given by the transaction, which is retrievable using the `GetSigners()` method. + +For example, starting with the `unsigned_tx.json`, and assuming the transaction has 4 signers, we would run: + +```bash +# Let signer1 sign the unsigned tx. +simd tx multisign unsigned_tx.json signer_key_1 --chain-id my-test-chain --keyring-backend test > partial_tx_1.json +# Now signer1 will send the partial_tx_1.json to the signer2. +# Signer2 appends their signature: +simd tx multisign partial_tx_1.json signer_key_2 --chain-id my-test-chain --keyring-backend test > partial_tx_2.json +# Signer2 sends the partial_tx_2.json file to signer3, and signer3 can append his signature: +simd tx multisign partial_tx_2.json signer_key_3 --chain-id my-test-chain --keyring-backend test > partial_tx_3.json +``` + +### Broadcasting a Transaction + +Broadcasting a transaction is done using the following command: + +```bash +simd tx broadcast tx_signed.json +``` + +You may optionally pass the `--broadcast-mode` flag to specify which response to receive from the node: + +* `block`: the CLI waits for the tx to be committed in a block. +* `sync`: the CLI waits for a CheckTx execution response only. +* `async`: the CLI returns immediately (transaction might fail). + +### 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. + +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. + +### Decoding a Transaction + +The CLI can also be used to decode transaction bytes. + +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. + +## Programmatically with Go + +It is possible to manipulate transactions programmatically via Go using the Cosmos SDK's `TxBuilder` interface. + +### Generating a Transaction + +Before generating a transaction, a new instance of a `TxBuilder` needs to be created. Since the 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. + +```go +import ( + "github.com/cosmos/cosmos-sdk/simapp" +) + +func sendTx() error { + // Choose your codec: Amino or Protobuf. Here, we use Protobuf, given by the + // following function. + encCfg := simapp.MakeTestEncodingConfig() + + // Create a new TxBuilder. + txBuilder := encCfg.TxConfig.NewTxBuilder() + + // --snip-- +} +``` + +We can also set up some keys and addresses that will send and receive the transactions. Here, for the purpose of the tutorial, we will be using some dummy data to create keys. + +```go +import ( + "github.com/cosmos/cosmos-sdk/testutil/testdata" +) + +priv1, _, addr1 := testdata.KeyTestPubAddr() +priv2, _, addr2 := testdata.KeyTestPubAddr() +priv3, _, addr3 := testdata.KeyTestPubAddr() +``` + +Populating the `TxBuilder` can be done via its [methods](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/client/tx_config.go#L33-L50): + +```go +import ( + banktypes "github.com/cosmos/cosmos-sdk/x/bank/types" +) + +func sendTx() error { + // --snip-- + + // Define two x/bank MsgSend messages: + // - from addr1 to addr3, + // - from addr2 to addr3. + // This means that the transactions needs two signers: addr1 and addr2. + msg1 := banktypes.NewMsgSend(addr1, addr3, types.NewCoins(types.NewInt64Coin("atom", 12))) + msg2 := banktypes.NewMsgSend(addr2, addr3, types.NewCoins(types.NewInt64Coin("atom", 34))) + + err := txBuilder.SetMsgs(msg1, msg2) + if err != nil { + return err + } + + txBuilder.SetGasLimit(...) + txBuilder.SetFeeAmount(...) + txBuilder.SetMemo(...) + txBuilder.SetTimeoutHeight(...) +} +``` + +At this point, `TxBuilder`'s underlying transaction is ready to be signed. + +### Signing a Transaction + +We 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/main/docs/architecture/adr-020-protobuf-transaction-encoding.md), each signer needs to sign the `SignerInfo`s of all other signers. This means that we need to perform two steps sequentially: + +* for each signer, populate the signer's `SignerInfo` inside `TxBuilder`, +* once all `SignerInfo`s are populated, for each signer, sign the `SignDoc` (the payload to be signed). + +In the current `TxBuilder`'s API, both steps are done using the same method: `SetSignatures()`. The current API requires us to first perform a round of `SetSignatures()` _with empty signatures_, only to populate `SignerInfo`s, and a second round of `SetSignatures()` to actually sign the correct payload. + +```go +import ( + cryptotypes "github.com/cosmos/cosmos-sdk/crypto/types" + "github.com/cosmos/cosmos-sdk/types/tx/signing" + xauthsigning "github.com/cosmos/cosmos-sdk/x/auth/signing" +) + +func sendTx() error { + // --snip-- + + privs := []cryptotypes.PrivKey{priv1, priv2} + accNums:= []uint64{..., ...} // The accounts' account numbers + accSeqs:= []uint64{..., ...} // The accounts' sequence numbers + + // First round: we gather all the signer infos. We use the "set empty + // signature" hack to do that. + var sigsV2 []signing.SignatureV2 + for i, priv := range privs { + sigV2 := signing.SignatureV2{ + PubKey: priv.PubKey(), + Data: &signing.SingleSignatureData{ + SignMode: encCfg.TxConfig.SignModeHandler().DefaultMode(), + Signature: nil, + }, + Sequence: accSeqs[i], + } + + sigsV2 = append(sigsV2, sigV2) + } + err := txBuilder.SetSignatures(sigsV2...) + if err != nil { + return err + } + + // Second round: all signer infos are set, so each signer can sign. + sigsV2 = []signing.SignatureV2{} + for i, priv := range privs { + signerData := xauthsigning.SignerData{ + ChainID: chainID, + AccountNumber: accNums[i], + Sequence: accSeqs[i], + } + sigV2, err := tx.SignWithPrivKey( + encCfg.TxConfig.SignModeHandler().DefaultMode(), signerData, + txBuilder, priv, encCfg.TxConfig, accSeqs[i]) + if err != nil { + return nil, err + } + + sigsV2 = append(sigsV2, sigV2) + } + err = txBuilder.SetSignatures(sigsV2...) + if err != nil { + return err + } +} +``` + +The `TxBuilder` is now correctly populated. To print it, you can use the `TxConfig` interface from the initial encoding config `encCfg`: + +```go +func sendTx() error { + // --snip-- + + // Generated Protobuf-encoded bytes. + txBytes, err := encCfg.TxConfig.TxEncoder()(txBuilder.GetTx()) + if err != nil { + return err + } + + // Generate a JSON string. + txJSONBytes, err := encCfg.TxConfig.TxJSONEncoder()(txBuilder.GetTx()) + if err != nil { + return err + } + txJSON := string(txJSONBytes) +} +``` + +### Broadcasting a Transaction + +The preferred way to broadcast a transaction is to use gRPC, though using REST (via `gRPC-gateway`) or the Tendermint RPC is also posible. An overview of the differences between these methods is exposed [here](../core/grpc_rest.md). For this tutorial, we will only describe the gRPC method. + +```go +import ( + "context" + "fmt" + + "google.golang.org/grpc" + + "github.com/cosmos/cosmos-sdk/types/tx" +) + +func sendTx(ctx context.Context) error { + // --snip-- + + // Create a connection to the gRPC server. + grpcConn := grpc.Dial( + "127.0.0.1:9090", // Or your gRPC server address. + grpc.WithInsecure(), // The Cosmos SDK doesn't support any transport security mechanism. + ) + defer grpcConn.Close() + + // Broadcast the tx via gRPC. We create a new client for the Protobuf Tx + // service. + txClient := tx.NewServiceClient(grpcConn) + // We then call the BroadcastTx method on this client. + grpcRes, err := txClient.BroadcastTx( + ctx, + &tx.BroadcastTxRequest{ + Mode: tx.BroadcastMode_BROADCAST_MODE_SYNC, + TxBytes: txBytes, // Proto-binary of the signed transaction, see previous step. + }, + ) + if err != nil { + return err + } + + fmt.Println(grpcRes.TxResponse.Code) // Should be `0` if the tx is successful + + return nil +} +``` + +#### Simulating a Transaction + +Before broadcasting a transaction, we sometimes may want to dry-run the transaction, to estimate some information about the transaction without actually committing it. This is called simulating a transaction, and can be done as follows: + +```go +import ( + "context" + "fmt" + "testing" + + "github.com/cosmos/cosmos-sdk/client" + "github.com/cosmos/cosmos-sdk/types/tx" + authtx "github.com/cosmos/cosmos-sdk/x/auth/tx" +) + +func simulateTx() error { + // --snip-- + + // Simulate the tx via gRPC. We create a new client for the Protobuf Tx + // service. + txClient := tx.NewServiceClient(grpcConn) + txBytes := /* Fill in with your signed transaction bytes. */ + + // We then call the Simulate method on this client. + grpcRes, err := txClient.Simulate( + context.Background(), + &tx.SimulateRequest{ + TxBytes: txBytes, + }, + ) + if err != nil { + return err + } + + fmt.Println(grpcRes.GasInfo) // Prints estimated gas used. + + return nil +} +``` + +## 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. + +### 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: + +```bash +grpcurl -plaintext \ + -d '{"tx_bytes":"{{txBytes}}","mode":"BROADCAST_MODE_SYNC"}' \ + localhost:9090 \ + cosmos.tx.v1beta1.Service/BroadcastTx +``` + +## Using 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. + +### Broadcasting a Transaction + +Broadcasting a transaction using the REST endpoint (served by `gRPC-gateway`) can be done by sending a POST request as follows, where the `txBytes` are the protobuf-encoded bytes of a signed transaction: + +```bash +curl -X POST \ + -H "Content-Type: application/json" \ + -d'{"tx_bytes":"{{txBytes}}","mode":"BROADCAST_MODE_SYNC"}' \ + localhost:1317/cosmos/tx/v1beta1/txs +``` + +## Using CosmJS (JavaScript & TypeScript) + +CosmJS aims to build client libraries in JavaScript that can be embedded in web applications. Please see [https://cosmos.github.io/cosmjs](https://cosmos.github.io/cosmjs) for more information. As of January 2021, CosmJS documentation is still work in progress. diff --git a/versioned_docs/version-0.47/develop/advanced-concepts/00-baseapp.md b/versioned_docs/version-0.47/develop/advanced-concepts/00-baseapp.md new file mode 100644 index 000000000..e18267116 --- /dev/null +++ b/versioned_docs/version-0.47/develop/advanced-concepts/00-baseapp.md @@ -0,0 +1,512 @@ +--- +sidebar_position: 1 +--- + +# BaseApp + +:::note Synopsis +This document describes `BaseApp`, the abstraction that implements the core functionalities of a Cosmos SDK application. +::: + +:::note + +### Pre-requisite Readings + +* [Anatomy of a Cosmos SDK application](../basics/00-app-anatomy.md) +* [Lifecycle of a Cosmos SDK transaction](../basics/01-tx-lifecycle.md) + +::: + +## Introduction + +`BaseApp` is a base type that implements the core of a Cosmos SDK application, namely: + +* The [Application Blockchain Interface](#main-abci-messages), for the state-machine to communicate with the underlying consensus engine (e.g. CometBFT). +* [Service Routers](#service-routers), to route messages and queries to the appropriate module. +* Different [states](#state-updates), as the state-machine can have different volatile states updated based on the ABCI message received. + +The goal of `BaseApp` is to provide the fundamental layer of 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: + +```go +type App struct { + // reference to a BaseApp + *baseapp.BaseApp + + // list of application store keys + + // list of application keepers + + // module manager +} +``` + +Extending the application with `BaseApp` gives the former access to all of `BaseApp`'s methods. +This allows developers to compose their custom application with the modules they want, while not +having to concern themselves with the hard work of implementing the ABCI, the service routers and state +management logic. + +## Type Definition + +The `BaseApp` type holds many important parameters for any Cosmos SDK based application. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/baseapp/baseapp.go#L50-L146 +``` + +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`](./04-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://pkg.go.dev/github.com/cosmos/cosmos-sdk/types#TxDecoder): It is used to decode + raw transaction bytes relayed by the underlying CometBFT engine. +* [`AnteHandler`](#antehandler): This handler is used to handle signature verification, fee payment, + and other pre-message execution checks when a transaction is received. It's executed during + [`CheckTx/RecheckTx`](#checktx) and [`DeliverTx`](#delivertx). +* [`InitChainer`](../basics/00-app-anatomy.md#initchainer), + [`BeginBlocker` and `EndBlocker`](../basics/00-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 CometBFT engine. + +Then, parameters used to define [volatile states](#state-updates) (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. +* `processProposalState`: This state is updated during [`ProcessProposal`](#process-proposal). +* `prepareProposalState`: This state is updated during [`PrepareProposal`](#prepare-proposal). + +Finally, a few more important parameters: + +* `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://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_basic_concepts.md#mempool-methods) + 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/00-app-anatomy.md#constructor-function). + +## Constructor + +```go +func NewBaseApp( + name string, logger log.Logger, db dbm.DB, txDecoder sdk.TxDecoder, options ...func(*BaseApp), +) *BaseApp { + + // ... +} +``` + +The `BaseApp` constructor function is pretty straightforward. The only thing worth noting is the +possibility to provide additional [`options`](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/baseapp/options.go) +to the `BaseApp`, which will execute them in order. The `options` are generally `setter` functions +for important parameters, like `SetPruning()` to set pruning options or `SetMinGasPrices()` to set +the node's `min-gas-prices`. + +Naturally, developers can add additional `options` based on their application's needs. + +## State Updates + +The `BaseApp` maintains four primary volatile states and a root or main state. The main state +is the canonical state of the application and the volatile states, `checkState`, `deliverState`, `prepareProposalState`, `processPreposalState`, +are used to handle state transitions in-between the main state made during [`Commit`](#commit). + +Internally, there is only a single `CommitMultiStore` which we refer to as the main or root state. +From this root state, we derive four volatile states by using a mechanism called _store branching_ (performed by `CacheWrap` function). +The types can be illustrated as follows: + +![Types](./baseapp_state.png) + +### InitChain State Updates + +During `InitChain`, the four volatile states, `checkState`, `prepareProposalState`, `processProposalState` +and `deliverState` are set by branching the root `CommitMultiStore`. Any subsequent reads and writes happen +on branched versions of the `CommitMultiStore`. +To avoid unnecessary roundtrip to the main state, all reads to the branched store are cached. + +![InitChain](./baseapp_state-initchain.png) + +### CheckTx State Updates + +During `CheckTx`, the `checkState`, which is based off of the last committed state from the root +store, is used for any reads and writes. Here we only execute the `AnteHandler` and verify a service router +exists for every message in the transaction. Note, when we execute the `AnteHandler`, we branch +the already branched `checkState`. +This has the side effect that if the `AnteHandler` fails, the state transitions won't be reflected in the `checkState` +-- i.e. `checkState` is only updated on success. + +![CheckTx](./baseapp_state-checktx.png) + +### PrepareProposal State Updates + +During `PrepareProposal`, the `prepareProposalState` is set by branching the root `CommitMultiStore`. +The `prepareProposalState` is used for any reads and writes that occur during the `PrepareProposal` phase. +The function uses the `Select()` method of the mempool to iterate over the transactions. `runTx` is then called, +which encodes and validates each transaction and from there the `AnteHandler` is executed. +If successful, valid transactions are returned inclusive of the events, tags, and data generated +during the execution of the proposal. +The described behavior is that of the default handler, applications have the flexibility to define their own +[custom mempool handlers](https://docs.cosmos.network/main/building-apps/app-mempool#custom-mempool-handlers). + +![ProcessProposal](./baseapp_state-prepareproposal.png) + +### ProcessProposal State Updates + +During `ProcessProposal`, the `processProposalState` is set based off of the last committed state +from the root store and is used to process a signed proposal received from a validator. +In this state, `runTx` is called and the `AnteHandler` is executed and the context used in this state is built with information +from the header and the main state, including the minimum gas prices, which are also set. +Again we want to highlight that the described behavior is that of the default handler and applications have the flexibility to define their own +[custom mempool handlers](https://docs.cosmos.network/main/building-apps/app-mempool#custom-mempool-handlers). + +![ProcessProposal](./baseapp_state-processproposal.png) + +### BeginBlock State Updates + +During `BeginBlock`, the `deliverState` is set for use in subsequent `DeliverTx` ABCI messages. The +`deliverState` is based off of the last committed state from the root store and is branched. +Note, the `deliverState` is set to `nil` on [`Commit`](#commit). + +![BeginBlock](./baseapp_state-begin_block.png) + +### DeliverTx State Updates + +The state flow for `DeliverTx` is nearly identical to `CheckTx` except state transitions occur on +the `deliverState` and messages in a transaction are executed. Similarly to `CheckTx`, state transitions +occur on a doubly branched state -- `deliverState`. Successful message execution results in +writes being committed to `deliverState`. Note, if message execution fails, state transitions from +the AnteHandler are persisted. + +![DeliverTx](./baseapp_state-deliver_tx.png) + +### Commit State Updates + +During `Commit` all the state transitions that occurred in the `deliverState` are finally written to +the root `CommitMultiStore` which in turn is committed to disk and results in a new application +root hash. These state transitions are now considered final. Finally, the `checkState` is set to the +newly committed state and `deliverState` is set to `nil` to be reset on `BeginBlock`. + +![Commit](./baseapp_state-commit.png) + +## ParamStore + +During `InitChain`, the `RequestInitChain` provides `ConsensusParams` which contains parameters +related to block execution such as maximum gas and size in addition to evidence parameters. If these +parameters are non-nil, they are set in the BaseApp's `ParamStore`. Behind the scenes, the `ParamStore` +is managed by an `x/consensus_params` module. This allows the parameters to be tweaked via + on-chain governance. + +## Service Routers + +When messages and queries are received by the application, they must be routed to the appropriate module in order to be processed. Routing is done via `BaseApp`, which holds a `msgServiceRouter` for messages, and a `grpcQueryRouter` for queries. + +### `Msg` Service Router + +[`sdk.Msg`s](../building-modules/02-messages-and-queries.md#messages) need to be routed after they are extracted from transactions, which are sent from the underlying CometBFT 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. + +The [default `msgServiceRouter` included in `BaseApp`](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/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.47.0-rc1/baseapp/msg_service_router.go#L31-L32). For a stateless router that doesn't want to make use of this, you can just ignore the `ctx`. + +The application's `msgServiceRouter` is initialized with all the routes using the application's [module manager](../building-modules/01-module-manager.md#manager) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](../basics/00-app-anatomy.md#constructor-function). + +### gRPC Query Router + +Similar to `sdk.Msg`s, [`queries`](../building-modules/02-messages-and-queries.md#queries) need to be routed to the appropriate module's [`Query` service](../building-modules/04-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 CometBFT RPC endpoint. + +Just like the `msgServiceRouter`, the `grpcQueryRouter` is initialized with all the query routes using the application's [module manager](../building-modules/01-module-manager.md) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](../basics/00-app-anatomy.md#app-constructor). + +## Main ABCI 1.0 Messages + +The [Application-Blockchain Interface](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_basic_concepts.md) (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 CometBFT. + +The consensus engine handles two main tasks: + +* The networking logic, which mainly consists in gossiping block parts, transactions and consensus votes. +* The consensus logic, which results in the deterministic ordering of transactions in the form of blocks. + +It is **not** the role of the consensus engine to define the state or the validity of transactions. Generally, transactions are handled by the consensus engine in the form of `[]bytes`, and relayed to the application via the ABCI to be decoded and processed. At keys moments in the networking and consensus processes (e.g. beginning of a block, commit of a block, reception of an unconfirmed transaction, ...), the consensus engine emits ABCI messages for the state-machine to act on. + +Developers building on top of the Cosmos SDK need not implement the ABCI themselves, as `BaseApp` comes with a built-in implementation of the interface. Let us go through the main ABCI messages that `BaseApp` implements: + +* [`Prepare Proposal`](#prepare-proposal) +* [`Process Proposal`](#process-proposal) +* [`CheckTx`](#checktx) +* [`DeliverTx`](#delivertx) + + +### Prepare Proposal + +The `PrepareProposal` function is part of the new methods introduced in Application Blockchain Interface (ABCI++) in CometBFT and is an important part of the application's overall governance system. In the Cosmos SDK, it allows the application to have more fine-grained control over the transactions that are processed, and ensures that only valid transactions are committed to the blockchain. + +Here is how the `PrepareProposal` function can be implemented: + +1. Extract the `sdk.Msg`s from the transaction. +2. Perform _stateful_ checks by calling `Validate()` on each of the `sdk.Msg`'s. This is done after _stateless_ checks as _stateful_ checks are more computationally expensive. If `Validate()` fails, `PrepareProposal` returns before running further checks, which saves resources. +3. Perform any additional checks that are specific to the application, such as checking account balances, or ensuring that certain conditions are met before a transaction is proposed.hey are processed by the consensus engine, if necessary. +5. Return the updated transactions to be processed by the consensus engine + +Note that, unlike `CheckTx()`, `PrepareProposal` process `sdk.Msg`s, so it can directly update the state. However, unlike `DeliverTx()`, it does not commit the state updates. It's important to exercise caution when using `PrepareProposal` as incorrect coding could affect the overall liveness of the network. + +It's important to note that `PrepareProposal` complements the `ProcessProposal` method which is executed after this method. The combination of these two methods means that it is possible to guarantee that no invalid transactions are ever committed. Furthermore, such a setup can give rise to other interesting use cases such as Oracles, threshold decryption and more. + +`PrepareProposal` returns a response to the underlying consensus engine of type [`abci.ResponseCheckTx`](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_methods.md#processproposal). 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. + + +### Process Proposal + +The `ProcessProposal` function is called by the BaseApp as part of the ABCI message flow, and is executed during the `BeginBlock` phase of the consensus process. The purpose of this function is to give more control to the application for block validation, allowing it to check all transactions in a proposed block before the validator sends the prevote for the block. It allows a validator to perform application-dependent work in a proposed block, enabling features such as immediate block execution, and allows the Application to reject invalid blocks. + +The `ProcessProposal` function performs several key tasks, including: + +1. Validating the proposed block by checking all transactions in it. +2. Checking the proposed block against the current state of the application, to ensure that it is valid and that it can be executed. +3. Updating the application's state based on the proposal, if it is valid and passes all checks. +4. Returning a response to CometBFT indicating the result of the proposal processing. + +The `ProcessProposal` is an important part of the application's overall governance system. It is used to manage the network's parameters and other key aspects of its operation. It also ensures that the coherence property is adhered to i.e. all honest validators must accept a proposal by an honest proposer. + +It's important to note that `ProcessProposal` complements the `PrepareProposal` method which enables the application to have more fine-grained transaction control by allowing it to reorder, drop, delay, modify, and even add transactions as they see necessary. The combination of these two methods means that it is possible to guarantee that no invalid transactions are ever committed. Furthermore, such a setup can give rise to other interesting use cases such as Oracles, threshold decryption and more. + +CometBFT calls it when it receives a proposal and the CometBFT algorithm has not locked on a value. The Application cannot modify the proposal at this point but can reject it if it is invalid. If that is the case, CometBFT will prevote `nil` on the proposal, which has strong liveness implications for CometBFT. As a general rule, the Application SHOULD accept a prepared proposal passed via `ProcessProposal`, even if a part of the proposal is invalid (e.g., an invalid transaction); the Application can ignore the invalid part of the prepared proposal at block execution time. + +However, developers must exercise greater caution when using these methods. Incorrectly coding these methods could affect liveness as CometBFT is unable to receive 2/3 valid precommits to finalize a block. + +`ProcessProposal` returns a response to the underlying consensus engine of type [`abci.ResponseCheckTx`](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_methods.md#processproposal). 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. + + +### 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 the checks **lightweight** because gas fees are not charged for the resources (CPU, data load...) used during the `CheckTx`. + +In the Cosmos SDK, after [decoding transactions](./05-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/03-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/04-gas-fees.md) counting occurs here, + as `sdk.Msg`s are not processed. Usually, the [`AnteHandler`](../basics/04-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. + +`CheckTx` does **not** process `sdk.Msg`s - they 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/04-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](#state-updates) 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://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_methods.md#checktx). +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: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/auth/ante/basic.go#L96 +``` + +* `Events ([]cmn.KVPair)`: Key-Value tags for filtering and indexing transactions (eg. by account). See [`event`s](./08-events.md) for more. +* `Codespace (string)`: Namespace for the Code. + +#### RecheckTx + +After `Commit`, `CheckTx` is run again on all transactions that remain in the node's local mempool +excluding the transactions that are included in the block. To prevent the mempool from rechecking all transactions +every time a block is committed, the configuration option `mempool.recheck=false` can be set. As of +Tendermint v0.32.1, an additional `Type` parameter is made available to the `CheckTx` function that +indicates whether an incoming transaction is new (`CheckTxType_New`), or a recheck (`CheckTxType_Recheck`). +This allows certain checks like signature verification can be skipped during `CheckTxType_Recheck`. + +### DeliverTx + +When the underlying consensus engine receives a block proposal, each transaction in the block needs to be processed by the application. To that end, the underlying consensus engine sends a `DeliverTx` message to the application for each transaction in a sequential order. + +Before the first transaction of a given block is processed, a [volatile state](#state-updates) called `deliverState` is initialized 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 it is set to `nil`. + +`DeliverTx` performs the **exact same steps as `CheckTx`**, with a little caveat at step 3 and the addition of a fifth step: + +1. The `AnteHandler` does **not** check that the transaction's `gas-prices` is sufficient. That is because the `min-gas-prices` value `gas-prices` is checked against is local to the node, and therefore what is enough for one full-node might not be for another. This means that the proposer can potentially include transactions for free, although they are not incentivised to do so, as they earn a bonus on the total fee of the block they propose. +2. For each `sdk.Msg` in the transaction, route to the appropriate module's Protobuf [`Msg` service](../building-modules/03-msg-services.md). Additional _stateful_ checks are performed, and the branched multistore held in `deliverState`'s `context` is updated by the module's `keeper`. If the `Msg` service returns successfully, the branched multistore held in `context` is written to `deliverState` `CacheMultiStore`. + +During the additional fifth step outlined in (2), each read/write to the store increases the value of `GasConsumed`. You can find the default cost of each operation: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/store/types/gas.go#L230-L241 +``` + +At any point, if `GasConsumed > GasWanted`, the function returns with `Code != 0` and `DeliverTx` fails. + +`DeliverTx` returns a response to the underlying consensus engine of type [`abci.ResponseDeliverTx`](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_methods.md#delivertx). The response contains: + +* `Code (uint32)`: Response Code. `0` if successful. +* `Data ([]byte)`: Result bytes, if any. +* `Log (string):` The output of the application's logger. May be non-deterministic. +* `Info (string):` Additional information. May be non-deterministic. +* `GasWanted (int64)`: Amount of gas requested for transaction. It is provided by users when they generate the transaction. +* `GasUsed (int64)`: Amount of gas consumed by transaction. During `DeliverTx`, this value is computed by multiplying the standard cost of a transaction byte by the size of the raw transaction, and by adding gas each time a read/write to the store occurs. +* `Events ([]cmn.KVPair)`: Key-Value tags for filtering and indexing transactions (eg. by account). See [`event`s](./08-events.md) for more. +* `Codespace (string)`: Namespace for the Code. + +## RunTx, AnteHandler, RunMsgs, PostHandler + +### RunTx + +`RunTx` is called from `CheckTx`/`DeliverTx` to handle the transaction, with `runTxModeCheck` or `runTxModeDeliver` as parameter to differentiate between the two modes of execution. Note that when `RunTx` receives a transaction, it has already been decoded. + +The first thing `RunTx` does upon being called is to retrieve the `context`'s `CacheMultiStore` by calling the `getContextForTx()` function with the appropriate mode (either `runTxModeCheck` or `runTxModeDeliver`). This `CacheMultiStore` is a branch of the main store, with cache functionality (for query requests), instantiated during `BeginBlock` for `DeliverTx` and during the `Commit` of the previous block for `CheckTx`. After that, two `defer func()` are called for [`gas`](../basics/04-gas-fees.md) management. They are executed when `runTx` returns and make sure `gas` is actually consumed, and will throw errors, if any. + +After that, `RunTx()` calls `ValidateBasic()` on each `sdk.Msg`in the `Tx`, which runs preliminary _stateless_ validity checks. If any `sdk.Msg` fails to pass `ValidateBasic()`, `RunTx()` returns with an error. + +Then, the [`anteHandler`](#antehandler) of the application is run (if it exists). In preparation of this step, both the `checkState`/`deliverState`'s `context` and `context`'s `CacheMultiStore` are branched using the `cacheTxContext()` function. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/baseapp/baseapp.go#L663-L672 +``` + +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](./10-ocap.md) of the Cosmos SDK. + +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. + +### 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. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/types/handler.go#L6-L8 +``` + +The `AnteHandler` is theoretically optional, but still a very important component of public blockchain networks. It serves 3 primary purposes: + +* Be a primary line of defense against spam and second line of defense (the first one being the mempool) against transaction replay with fees deduction and [`sequence`](./01-transactions.md#transaction-generation) checking. +* Perform preliminary _stateful_ validity checks like ensuring signatures are valid or that the sender has enough funds to pay for fees. +* Play a role in the incentivisation of stakeholders via the collection of transaction fees. + +`BaseApp` holds an `anteHandler` as parameter that is initialized in the [application's constructor](../basics/00-app-anatomy.md#application-constructor). The most widely used `anteHandler` is the [`auth` module](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/auth/ante/ante.go). + +Click [here](../basics/04-gas-fees.md#antehandler) for more on the `anteHandler`. + +### RunMsgs + +`RunMsgs` is called from `RunTx` with `runTxModeCheck` as parameter to check the existence of a route for each message the transaction, and with `runTxModeDeliver` to actually process the `sdk.Msg`s. + +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/03-msg-services.md) RPC is executed, before `RunMsgs` returns. + +### PostHandler + +`PostHandler` is similar to `AnteHandler`, but it, as the name suggests, executes custom post tx processing logic after [`RunMsgs`](#runmsgs) is called. `PostHandler` receives the `Result` of the the `RunMsgs` in order to enable this customizable behavior. + +Like `AnteHandler`s, `PostHandler`s are theoretically optional, one use case for `PostHandler`s is transaction tips (enabled by default in simapp). +Other use cases like unused gas refund can also be enabled by `PostHandler`s. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/auth/posthandler/post.go#L1-L15 +``` + +Note, when `PostHandler`s fail, the state from `runMsgs` is also reverted, effectively making the transaction fail. + +## Other ABCI Messages + +### InitChain + +The [`InitChain` ABCI message](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_basic_concepts.md#method-overview) is sent from the underlying CometBFT engine when the chain is first started. It is mainly used to **initialize** parameters and state like: + +* [Consensus Parameters](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_app_requirements.md#consensus-parameters) via `setConsensusParams`. +* [`checkState` and `deliverState`](#state-updates) via `setState`. +* The [block gas meter](../basics/04-gas-fees.md#block-gas-meter), with infinite gas to process genesis transactions. + +Finally, the `InitChain(req abci.RequestInitChain)` method of `BaseApp` calls the [`initChainer()`](../basics/00-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/08-genesis.md#initgenesis) function of each of the application's modules. + +### BeginBlock + +The [`BeginBlock` ABCI message](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_basic_concepts.md#method-overview) is sent from the underlying CometBFT engine when a block proposal created by the correct proposer is received, before [`DeliverTx`](#delivertx) is run for each transaction in the block. It allows developers to have logic be executed at the beginning of each block. In the Cosmos SDK, the `BeginBlock(req abci.RequestBeginBlock)` method does the following: + +* Initialize [`deliverState`](#state-updates) with the latest header using the `req abci.RequestBeginBlock` passed as parameter via the `setState` function. + + ```go reference + https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/baseapp/baseapp.go#L406-L433 + ``` + + This function also resets the [main gas meter](../basics/04-gas-fees.md#main-gas-meter). + +* Initialize the [block gas meter](../basics/04-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/00-app-anatomy.md#beginblocker-and-endblock), which mainly runs the [`BeginBlocker()`](../building-modules/05-beginblock-endblock.md#beginblock) method of each of the application's modules. +* Set the [`VoteInfos`](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_methods.md#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`](./02-context.md) so that it can be used during `DeliverTx` and `EndBlock`. + +### EndBlock + +The [`EndBlock` ABCI message](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_basic_concepts.md#method-overview) is sent from the underlying CometBFT 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/00-app-anatomy.md#beginblocker-and-endblock), which mainly runs the [`EndBlocker()`](../building-modules/05-beginblock-endblock.md#beginblock) method of each of the application's modules. + +### Commit + +The [`Commit` ABCI message](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_basic_concepts.md#method-overview) is sent from the underlying CometBFT 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 occurred during `BeginBlock`, `DeliverTx` and `EndBlock` and to reset state for the next block. + +To commit state-transitions, the `Commit` function calls the `Write()` function on `deliverState.ms`, where `deliverState.ms` is a branched multistore of the main store `app.cms`. Then, the `Commit` function sets `checkState` to the latest header (obtained from `deliverState.ctx.BlockHeader`) and `deliverState` to `nil`. + +Finally, `Commit` returns the hash of the commitment of `app.cms` back to the underlying consensus engine. This hash is used as a reference in the header of the next block. + +### Info + +The [`Info` ABCI message](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_basic_concepts.md#info-methods) is a simple query from the underlying consensus engine, notably used to sync the latter with the application during a handshake that happens on startup. When called, the `Info(res abci.ResponseInfo)` function from `BaseApp` will return the application's name, version and the hash of the last commit of `app.cms`. + +### Query + +The [`Query` ABCI message](https://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_basic_concepts.md#info-methods) is used to serve queries received from the underlying consensus engine, including queries received via RPC like CometBFT RPC. It used to be the main entrypoint to build interfaces with the application, but with the introduction of [gRPC queries](../building-modules/04-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://github.com/cometbft/cometbft/blob/v0.37.x/spec/abci/abci++_app_requirements.md#query). + +Each CometBFT `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 split string (`split[0]`) contains the category of `query` (`app`, `p2p`, `store` or `custom` ). The `BaseApp` implementation of the `Query(req abci.RequestQuery)` method is a simple dispatcher serving these 4 main categories of queries: + +* Application-related queries like querying the application's version, which are served via the `handleQueryApp` method. +* Direct queries to the multistore, which are served by the `handlerQueryStore` method. These direct 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). diff --git a/versioned_docs/version-0.47/develop/advanced-concepts/01-transactions.md b/versioned_docs/version-0.47/develop/advanced-concepts/01-transactions.md new file mode 100644 index 000000000..8c1fa3f9e --- /dev/null +++ b/versioned_docs/version-0.47/develop/advanced-concepts/01-transactions.md @@ -0,0 +1,199 @@ +--- +sidebar_position: 1 +--- + +# Transactions + +:::note Synopsis +`Transactions` are objects created by end-users to trigger state changes in the application. +::: + +:::note + +### Pre-requisite Readings + +* [Anatomy of a Cosmos SDK Application](../basics/00-app-anatomy.md) + +::: + +## Transactions + +Transactions are comprised of metadata held in [contexts](./02-context.md) and [`sdk.Msg`s](../building-modules/02-messages-and-queries.md) that trigger state changes within a module through the module's Protobuf [`Msg` service](../building-modules/03-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/01-tx-lifecycle.md). + +## Type Definition + +Transaction objects are Cosmos SDK types that implement the `Tx` interface + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/types/tx_msg.go#L42-L50 +``` + +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:** lightweight, [_stateless_](../basics/01-tx-lifecycle.md#types-of-checks) checks used by ABCI messages [`CheckTx`](./00-baseapp.md#checktx) and [`DeliverTx`](./00-baseapp.md#delivertx) to make sure transactions are not invalid. For example, the [`auth`](https://github.com/cosmos/cosmos-sdk/tree/main/x/auth) module's `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 `sdk.Msg` [`ValidateBasic`](../basics/01-tx-lifecycle.md#ValidateBasic) methods, which perform basic validity checks on messages only. When [`runTx`](./00-baseapp.md#runtx) is checking a transaction created from the [`auth`](https://github.com/cosmos/cosmos-sdk/tree/main/x/auth/spec) module, it first runs `ValidateBasic` on each message, then runs the `auth` module AnteHandler which calls `ValidateBasic` for the transaction itself. + +As a developer, you should rarely manipulate `Tx` directly, as `Tx` is really an intermediate type used for transaction generation. Instead, developers should prefer the `TxBuilder` interface, which you can learn more about [below](#transaction-generation). + +### Signing Transactions + +Every message in a transaction must be signed by the addresses specified by its `GetSigners`. The Cosmos SDK currently allows signing transactions in two different ways. + +#### `SIGN_MODE_DIRECT` (preferred) + +The most used implementation of the `Tx` interface is the Protobuf `Tx` message, which is used in `SIGN_MODE_DIRECT`: + +```protobuf reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/tx/v1beta1/tx.proto#L13-L26 +``` + +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 reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/tx/v1beta1/tx.proto#L48-L65 +``` + +Once signed by all signers, the `body_bytes`, `auth_info_bytes` and `signatures` are gathered into `TxRaw`, whose serialized bytes are broadcasted over the network. + +#### `SIGN_MODE_LEGACY_AMINO_JSON` + +The legacy implementation of the `Tx` interface is the `StdTx` struct from `x/auth`: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/auth/migrations/legacytx/stdtx.go#L83-L93 +``` + +The document signed by all signers is `StdSignDoc`: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/auth/migrations/legacytx/stdsign.go#L38-L52 +``` + +which is encoded into bytes using Amino JSON. Once all signatures are gathered into `StdTx`, `StdTx` is serialized using Amino JSON, and these bytes are broadcasted over the network. + +#### Other Sign Modes + +The Cosmos SDK also provides a couple of other sign modes for particular use cases. + +#### `SIGN_MODE_DIRECT_AUX` + +`SIGN_MODE_DIRECT_AUX` is a sign mode released in the Cosmos SDK v0.46 which targets transactions with multiple signers. Whereas `SIGN_MODE_DIRECT` expects each signer to sign over both `TxBody` and `AuthInfo` (which includes all other signers' signer infos, i.e. their account sequence, public key and mode info), `SIGN_MODE_DIRECT_AUX` allows N-1 signers to only sign over `TxBody` and _their own_ signer info. Morever, each auxiliary signer (i.e. a signer using `SIGN_MODE_DIRECT_AUX`) doesn't +need to sign over the fees: + +```protobuf reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/tx/v1beta1/tx.proto#L67-L97 +``` + +The use case is a multi-signer transaction, where one of the signers is appointed to gather all signatures, broadcast the signature and pay for fees, and the others only care about the transaction body. This generally allows for a better multi-signing UX. If Alice, Bob and Charlie are part of a 3-signer transaction, then Alice and Bob can both use `SIGN_MODE_DIRECT_AUX` to sign over the `TxBody` and their own signer info (no need an additional step to gather other signers' ones, like in `SIGN_MODE_DIRECT`), without specifying a fee in their SignDoc. Charlie can then gather both signatures from Alice and Bob, and +create the final transaction by appending a fee. Note that the fee payer of the transaction (in our case Charlie) must sign over the fees, so must use `SIGN_MODE_DIRECT` or `SIGN_MODE_LEGACY_AMINO_JSON`. + +A concrete use case is implemented in [transaction tips](./14-tips.md): the tipper may use `SIGN_MODE_DIRECT_AUX` to specify a tip in the transaction, without signing over the actual transaction fees. Then, the fee payer appends fees inside the tipper's desired `TxBody`, and as an exchange for paying the fees and broadcasting the transaction, receives the tipper's transaction tips as payment. + +#### `SIGN_MODE_TEXTUAL` + +`SIGN_MODE_TEXTUAL` is a new sign mode for delivering a better signing experience on hardware wallets, it is currently still under implementation. If you wish to learn more, please refer to [ADR-050](https://github.com/cosmos/cosmos-sdk/pull/10701). + +#### Custom Sign modes + +There is the the opportunity to add your own custom sign mode to the Cosmos-SDK. While we can not accept the implementation of the sign mode to the repository, we can accept a pull request to add the custom signmode to the SignMode enum located [here](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/tx/signing/v1beta1/signing.proto#L17) + +## 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. + +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://docs.cometbft.com/v0.37/spec/abci/) which define interactions between the CometBFT and application layers. +::: + +**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/03-msg-services.md), and also implement the corresponding `MsgServer`. + +Each `sdk.Msg`s is related to exactly one Protobuf [`Msg` service](../building-modules/03-msg-services.md) RPC, defined inside each module's `tx.proto` file. A SDK 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. + +To learn more about Protobuf `Msg` services and how to implement `MsgServer`, click [here](../building-modules/03-msg-services.md). + +While messages contain the information for state transition logic, a transaction's other metadata and relevant information are stored in the `TxBuilder` and `Context`. + +### Transaction Generation + +The `TxBuilder` interface contains data closely related with the generation of transactions, which an end-user can freely set to generate the desired transaction: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/client/tx_config.go#L33-L50 +``` + +* `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. + +As there are currently two sign modes for signing transactions, there are also two implementations of `TxBuilder`: + +* [wrapper](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/auth/tx/builder.go#L18-L34) for creating transactions for `SIGN_MODE_DIRECT`, +* [StdTxBuilder](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/auth/migrations/legacytx/stdtx_builder.go#L15-L21) for `SIGN_MODE_LEGACY_AMINO_JSON`. + +However, the two implementation of `TxBuilder` should be hidden away from end-users, as they should prefer using the overarching `TxConfig` interface: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/client/tx_config.go#L22-L31 +``` + +`TxConfig` is an app-wide configuration for managing transactions. Most importantly, it holds the information about whether to sign each transaction with `SIGN_MODE_DIRECT` or `SIGN_MODE_LEGACY_AMINO_JSON`. By calling `txBuilder := txConfig.NewTxBuilder()`, a new `TxBuilder` will be created with the appropriate sign mode. + +Once `TxBuilder` is correctly populated with the setters exposed above, `TxConfig` will also take care of correctly encoding the bytes (again, either using `SIGN_MODE_DIRECT` or `SIGN_MODE_LEGACY_AMINO_JSON`). Here's a pseudo-code snippet of how to generate and encode a transaction, using the `TxEncoder()` method: + +```go +txBuilder := txConfig.NewTxBuilder() +txBuilder.SetMsgs(...) // and other setters on txBuilder + +bz, err := txConfig.TxEncoder()(txBuilder.GetTx()) +// bz are bytes to be broadcasted over the network +``` + +### Broadcasting the Transaction + +Once the transaction bytes are generated, there are currently three ways of broadcasting it. + +#### CLI + +Application developers create entry points to the application by creating a [command-line interface](../core/07-cli.md), [gRPC and/or REST interface](../core/06-grpc_rest.md), typically found in the application's `./cmd` folder. These interfaces allow users to interact with the application through command-line. + +For the [command-line interface](../building-modules/09-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/02-interact-node.md) section. An example transaction made using CLI looks like: + +```bash +simd tx send $MY_VALIDATOR_ADDRESS $RECIPIENT 1000stake +``` + +#### gRPC + +[gRPC](https://grpc.io) is the main component for the Cosmos SDK's RPC layer. Its principal usage is in the context of modules' [`Query` services](../building-modules/04-query-services.md). However, the Cosmos SDK also exposes a few other module-agnostic gRPC services, one of them being the `Tx` service: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/tx/v1beta1/service.proto +``` + +The `Tx` service exposes a handful of utility functions, such as simulating a transaction or querying a transaction, and also one method to broadcast transactions. + +Examples of broadcasting and simulating a transaction are shown [here](../run-node/03-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. + +An example can be seen [here](../run-node/03-txs.md#using-rest) + +#### CometBFT RPC + +The three methods presented above are actually higher abstractions over the CometBFT RPC `/broadcast_tx_{async,sync,commit}` endpoints, documented [here](https://docs.cometbft.com/v0.37/core/rpc). This means that you can use the CometBFT RPC endpoints directly to broadcast the transaction, if you wish so. diff --git a/versioned_docs/version-0.47/develop/advanced-concepts/02-context.md b/versioned_docs/version-0.47/develop/advanced-concepts/02-context.md new file mode 100644 index 000000000..74e4a7a24 --- /dev/null +++ b/versioned_docs/version-0.47/develop/advanced-concepts/02-context.md @@ -0,0 +1,102 @@ +--- +sidebar_position: 1 +--- + +# Context + +:::note Synopsis +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 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. +::: + +:::note + +### Pre-requisites Readings + +* [Anatomy of a Cosmos SDK Application](../basics/00-app-anatomy.md) +* [Lifecycle of a Transaction](../basics/01-tx-lifecycle.md) + +::: + +## Context Definition + +The Cosmos SDK `Context` is a custom data structure that contains Go's stdlib [`context`](https://pkg.go.dev/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](./04-store.md#base-layer-kvstores) in the [`multistore`](./04-store.md#multistore) and retrieve transactional context such as the block header and gas meter. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/types/context.go#L17-L44 +``` + +* **Base Context:** The base type is a Go [Context](https://pkg.go.dev/context), which is explained further in the [Go Context Package](#go-context-package) section below. +* **Multistore:** Every application's `BaseApp` contains a [`CommitMultiStore`](./04-store.md#multistore) which is provided when a `Context` is created. Calling the `KVStore()` and `TransientStore()` methods allows modules to fetch their respective [`KVStore`](./04-store.md#base-layer-kvstores) using their unique `StoreKey`. +* **Header:** The [header](https://docs.cometbft.com/v0.37/spec/core/data_structures#header) is a Blockchain type. It carries important information about the state of the blockchain, such as block height and proposer of the current block. +* **Header Hash:** The current block header hash, obtained during `abci.RequestBeginBlock`. +* **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. CometBFT) throughout its [lifecycle](../basics/01-tx-lifecycle.md), some of which do not have any understanding of transaction types. Thus, transactions are marshaled into the generic `[]byte` type using some kind of [encoding format](./05-encoding.md) such as [Amino](./05-encoding.md). +* **Logger:** A `logger` from the CometBFT libraries. Learn more about logs [here](https://docs.cometbft.com/v0.37/core/configuration). Modules call this method to create their own unique module-specific logger. +* **VoteInfo:** A list of the ABCI type [`VoteInfo`](https://docs.cometbft.com/master/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/04-gas-fees.md#main-gas-meter) for the transaction currently being processed using the context and a [`blockGasMeter`](../basics/04-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/04-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/04-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://docs.cometbft.com/master/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`](./08-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 CometBFT for indexing. For example: +* **Priority:** The transaction priority, only relevant in `CheckTx`. +* **KV `GasConfig`:** Enables applications to set a custom `GasConfig` for the `KVStore`. +* **Transient KV `GasConfig`:** Enables applications to set a custom `GasConfig` for the transiant `KVStore`. + +## Go Context Package + +A basic `Context` is defined in the [Golang Context Package](https://pkg.go.dev/context). A `Context` +is an immutable data structure that carries request-scoped data across APIs and processes. Contexts +are also designed to enable concurrency and to be used in goroutines. + +Contexts are intended to be **immutable**; they should never be edited. Instead, the convention is +to create a child context from its parent using a `With` function. For example: + +```go +childCtx = parentCtx.WithBlockHeader(header) +``` + +The [Golang Context Package](https://pkg.go.dev/context) documentation instructs developers to +explicitly pass a context `ctx` as the first argument of a process. + +## Store branching + +The `Context` contains a `MultiStore`, which allows for branchinig and caching functionality using `CacheMultiStore` +(queries in `CacheMultiStore` are cached to avoid future round trips). +Each `KVStore` is branched in a safe and isolated ephemeral storage. Processes are free to write changes to +the `CacheMultiStore`. If a state-transition sequence is performed without issue, the store branch can +be committed to the underlying store at the end of the sequence or disregard them if something +goes wrong. The pattern of usage for a Context is as follows: + +1. A process receives a Context `ctx` from its parent process, which provides information needed to + perform the process. +2. The `ctx.ms` is a **branched store**, i.e. a branch of the [multistore](./04-store.md#multistore) is made so that the process can make changes to the state as it executes, without changing the original`ctx.ms`. This is useful to protect the underlying multistore in case the changes need to be reverted at some point in the execution. +3. The process may read and write from `ctx` as it is executing. It may call a subprocess and pass + `ctx` to it as needed. +4. When a subprocess returns, it checks if the result is a success or failure. If a failure, nothing + needs to be done - the branch `ctx` is simply discarded. If successful, the changes made to + the `CacheMultiStore` can be committed to the original `ctx.ms` via `Write()`. + +For example, here is a snippet from the [`runTx`](./00-baseapp.md#runtx-antehandler-runmsgs-posthandler) function in [`baseapp`](./00-baseapp.md): + +```go +runMsgCtx, msCache := app.cacheTxContext(ctx, txBytes) +result = app.runMsgs(runMsgCtx, msgs, mode) +result.GasWanted = gasWanted +if mode != runTxModeDeliver { + return result +} +if result.IsOK() { + msCache.Write() +} +``` + +Here is the process: + +1. Prior to calling `runMsgs` on the message(s) in the transaction, it uses `app.cacheTxContext()` + to branch and cache the context and multistore. +2. `runMsgCtx` - the context with branched store, is used in `runMsgs` to return a result. +3. If the process is running in [`checkTxMode`](./00-baseapp.md#checktx), there is no need to write the + changes - the result is returned immediately. +4. If the process is running in [`deliverTxMode`](./00-baseapp.md#delivertx) and the result indicates + a successful run over all the messages, the branched multistore is written back to the original. diff --git a/versioned_docs/version-0.47/develop/advanced-concepts/03-node.md b/versioned_docs/version-0.47/develop/advanced-concepts/03-node.md new file mode 100644 index 000000000..67eb018ca --- /dev/null +++ b/versioned_docs/version-0.47/develop/advanced-concepts/03-node.md @@ -0,0 +1,98 @@ +--- +sidebar_position: 1 +--- + +# Node Client (Daemon) + +:::note Synopsis +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. +::: + +:::note + +### Pre-requisite Readings + +* [Anatomy of an SDK application](../basics/00-app-anatomy.md) + +::: + +## `main` function + +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. + +In general, developers will implement the `main.go` function with the following structure: + +* First, an [`encodingCodec`](./05-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/03-accounts.md#addresses). + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/types/config.go#L14-L29 +``` + +* Using [cobra](https://github.com/spf13/cobra), the root command of the full-node client is created. After that, all the custom commands of the application are added using the `AddCommand()` method of `rootCmd`. +* 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`. + +```go reference +https://github.com/cometbft/cometbft/blob/v0.37.0/libs/cli/setup.go#L74-L78 +``` + +See an example of `main` function from the `simapp` application, the Cosmos SDK's application for demo purposes: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/simapp/simd/main.go +``` + +## `start` command + +The `start` command is defined in the `/server` folder of the Cosmos SDK. It is added to the root command of the full-node client in the [`main` function](#main-function) and called by the end-user to start their node: + +```bash +# For an example app named "app", the following command starts the full-node. +appd start + +# Using the Cosmos SDK's own simapp, the following commands start the simapp node. +simd start +``` + +As a reminder, the full-node is composed of three conceptual layers: the networking layer, the consensus layer and the application layer. The first two are generally bundled together in an entity called the consensus engine (CometBFT by default), while the third is the state-machine defined with the help of the Cosmos SDK. Currently, the Cosmos SDK uses CometBFT as the default consensus engine, meaning the start command is implemented to boot up a CometBFT node. + +The flow of the `start` command is pretty straightforward. First, it retrieves the `config` from the `context` in order to open the `db` (a [`leveldb`](https://github.com/syndtr/goleveldb) instance by default). This `db` contains the latest known state of the application (empty if the application is started from the first time. + +With the `db`, the `start` command creates a new instance of the application using an `appCreator` function: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/server/start.go#L220 +``` + +Note that an `appCreator` is a function that fulfills the `AppCreator` signature: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/server/types/app.go#L64-L66 +``` + +In practice, the [constructor of the application](../basics/00-app-anatomy.md#constructor-function) is passed as the `appCreator`. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/simapp/simd/cmd/root.go#L254-L268 +``` + +Then, the instance of `app` is used to instantiate a new CometBFT node: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/server/start.go#L336-L348 +``` + +The CometBFT node can be created with `app` because the latter satisfies the [`abci.Application` interface](https://github.com/cometbft/cometbft/blob/v0.37.0/abci/types/application.go#L9-L35) (given that `app` extends [`baseapp`](./00-baseapp.md)). As part of the `node.New` method, CometBFT makes sure that the height of the application (i.e. number of blocks since genesis) is equal to the height of the CometBFT node. The difference between these two heights should always be negative or null. If it is strictly negative, `node.New` will replay blocks until the height of the application reaches the height of the CometBFT node. Finally, if the height of the application is `0`, the CometBFT node will call [`InitChain`](./00-baseapp.md#initchain) on the application to initialize the state from the genesis file. + +Once the CometBFT node is instantiated and in sync with the application, the node can be started: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/server/start.go#L350-L352 +``` + +Upon starting, the node will bootstrap its RPC and P2P server and start dialing peers. During handshake with its peers, if the node realizes they are ahead, it will query all the blocks sequentially in order to catch up. Then, it will wait for new block proposals and block signatures from validators in order to make progress. + +## Other commands + +To discover how to concretely run a node and interact with it, please refer to our [Running a Node, API and CLI](../run-node/01-run-node.md) guide. diff --git a/versioned_docs/version-0.47/develop/advanced-concepts/04-store.md b/versioned_docs/version-0.47/develop/advanced-concepts/04-store.md new file mode 100644 index 000000000..239cec484 --- /dev/null +++ b/versioned_docs/version-0.47/develop/advanced-concepts/04-store.md @@ -0,0 +1,290 @@ +--- +sidebar_position: 1 +--- + +# Store + +:::note Synopsis +A store is a data structure that holds the state of the application. +::: + +:::note + +### Pre-requisite Readings + +* [Anatomy of a Cosmos SDK application](../basics/00-app-anatomy.md) + +::: + +## Introduction to Cosmos SDK Stores + +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/06-keeper.md) of the module that declared the store. + +```text ++-----------------------------------------------------+ +| | +| +--------------------------------------------+ | +| | | | +| | KVStore 1 - Manage by keeper of Module 1 | +| | | | +| +--------------------------------------------+ | +| | +| +--------------------------------------------+ | +| | | | +| | KVStore 2 - Manage by keeper of Module 2 | | +| | | | +| +--------------------------------------------+ | +| | +| +--------------------------------------------+ | +| | | | +| | KVStore 3 - Manage by keeper of Module 2 | | +| | | | +| +--------------------------------------------+ | +| | +| +--------------------------------------------+ | +| | | | +| | KVStore 4 - Manage by keeper of Module 3 | | +| | | | +| +--------------------------------------------+ | +| | +| +--------------------------------------------+ | +| | | | +| | KVStore 5 - Manage by keeper of Module 4 | | +| | | | +| +--------------------------------------------+ | +| | +| Main Multistore | +| | ++-----------------------------------------------------+ + + Application's State +``` + +### Store Interface + +At its very core, a Cosmos SDK `store` is an object that holds a `CacheWrapper` and has a `GetStoreType()` method: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/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: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/store/types/store.go#L260-L284 +``` + +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](./02-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`: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/store/types/store.go#L28-L33 +``` + +The `Committer` is an interface that defines methods to persist changes to disk: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/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](./10-ocap.md) of the Cosmos SDK, only `baseapp` should have the ability to commit stores. For example, this is the reason why the `ctx.KVStore()` method by which modules typically access stores returns a `KVStore` and not a `CommitKVStore`. + +The Cosmos SDK comes with many types of stores, the most used being [`CommitMultiStore`](#multistore), [`KVStore`](#kvstore) and [`GasKv` store](#gaskv-store). [Other types of stores](#other-stores) include `Transient` and `TraceKV` stores. + +## Multistore + +### Multistore Interface + +Each Cosmos SDK application holds a multistore at its root to persist its state. The multistore is a store of `KVStores` that follows the `Multistore` interface: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/store/types/store.go#L101-L133 +``` + +If tracing is enabled, then branching the multistore will firstly wrap all the underlying `KVStore` in [`TraceKv.Store`](#tracekv-store). + +### CommitMultiStore + +The main type of `Multistore` used in the Cosmos SDK is `CommitMultiStore`, which is an extension of the `Multistore` interface: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/store/types/store.go#L141-L200 +``` + +As for concrete implementation, the [`rootMulti.Store`] is the go-to implementation of the `CommitMultiStore` interface. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/store/rootmulti/store.go#L53-L77 +``` + +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`](./00-baseapp.md). + +### CacheMultiStore + +Whenever the `rootMulti.Store` needs to be branched, a [`cachemulti.Store`](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/store/cachemulti/store.go) is used. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/store/cachemulti/store.go#L19-L33 +``` + +`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. + +## Base-layer KVStores + +### `KVStore` and `CommitKVStore` Interfaces + +A `KVStore` is a simple key-value store used to store and retrieve data. A `CommitKVStore` is a `KVStore` that also implements a `Committer`. By default, stores mounted in `baseapp`'s main `CommitMultiStore` are `CommitKVStore`s. The `KVStore` interface is primarily used to restrict modules from accessing the committer. + +Individual `KVStore`s are used by modules to manage a subset of the global state. `KVStores` can be accessed by objects that hold a specific key. This `key` should only be exposed to the [`keeper`](../building-modules/06-keeper.md) of the module that defines the store. + +`CommitKVStore`s are declared by proxy of their respective `key` and mounted on the application's [multistore](#multistore) in the [main application file](../basics/00-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. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/store/types/store.go#L206-L239 +``` + +Apart from the traditional `Get` and `Set` methods, that a `KVStore` must implement via the `BasicKVStore` interface; 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: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/bank/keeper/view.go#L115-L132 +``` + +### `IAVL` Store + +The default implementation of `KVStore` and `CommitKVStore` used in `baseapp` is the `iavl.Store`. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/store/iavl/store.go#L37-L41 +``` + +`iavl` stores are based around an [IAVL Tree](https://github.com/cosmos/iavl), a self-balancing binary tree which guarantees that: + +* `Get` and `Set` operations are O(log n), where n is the number of elements in the tree. +* Iteration efficiently returns the sorted elements within the range. +* Each tree version is immutable and can be retrieved even after a commit (depending on the pruning settings). + +The documentation on the IAVL Tree is located [here](https://github.com/cosmos/iavl/blob/master/docs/overview.md). + +### `DbAdapter` Store + +`dbadapter.Store` is a adapter for `dbm.DB` making it fulfilling the `KVStore` interface. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/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-store) + +### `Transient` Store + +`Transient.Store` is a base-layer `KVStore` which is automatically discarded at the end of the block. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/store/transient/store.go#L16-L19 +``` + +`Transient.Store` is a `dbadapter.Store` with a `dbm.NewMemDB()`. All `KVStore` methods are reused. When `Store.Commit()` is called, a new `dbadapter.Store` is assigned, discarding previous reference and making it garbage collected. + +This type of store is useful to persist information that is only relevant per-block. One example would be to store parameter changes (i.e. a bool set to `true` if a parameter changed in a block). + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/params/types/subspace.go#L21-L31 +``` + +Transient stores are typically accessed via the [`context`](./02-context.md) via the `TransientStore()` method: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/types/context.go#L284-L287 +``` + +## KVStore Wrappers + +### CacheKVStore + +`cachekv.Store` is a wrapper `KVStore` which provides buffered writing / cached reading functionalities over the underlying `KVStore`. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/store/cachekv/store.go#L26-L36 +``` + +This is the type used whenever an IAVL Store needs to be branched to create an isolated store (typically when we need to mutate a state that might be reverted later). + +#### `Get` + +`Store.Get()` firstly checks if `Store.cache` has an associated value with the key. If the value exists, the function returns it. If not, the function calls `Store.parent.Get()`, caches the result in `Store.cache`, and returns it. + +#### `Set` + +`Store.Set()` sets the key-value pair to the `Store.cache`. `cValue` has the field dirty bool which indicates whether the cached value is different from the underlying value. When `Store.Set()` caches a new pair, the `cValue.dirty` is set `true` so when `Store.Write()` is called it can be written to the underlying store. + +#### `Iterator` + +`Store.Iterator()` have to traverse on both cached items and the original items. In `Store.iterator()`, two iterators are generated for each of them, and merged. `memIterator` is essentially a slice of the `KVPairs`, used for cached items. `mergeIterator` is a combination of two iterators, where traverse happens ordered on both iterators. + +### `GasKv` Store + +Cosmos SDK applications use [`gas`](../basics/04-gas-fees.md) to track resources usage and prevent spam. [`GasKv.Store`](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/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. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/store/gaskv/store.go#L11-L17 +``` + +When methods of the parent `KVStore` are called, `GasKv.Store` automatically consumes appropriate amount of gas depending on the `Store.gasConfig`: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/store/types/gas.go#L219-L228 +``` + +By default, all `KVStores` are wrapped in `GasKv.Stores` when retrieved. This is done in the `KVStore()` method of the [`context`](./02-context.md): + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/types/context.go#L279-L282 +``` + +In this case, the gas configuration set in the `context` is used. The gas configuration can be set using the `WithKVGasConfig` method of the `context`. +Otherwise it uses the following default: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/store/types/gas.go#L230-L241 +``` + +### `TraceKv` Store + +`tracekv.Store` is a wrapper `KVStore` which provides operation tracing functionalities over the underlying `KVStore`. It is applied automatically by the Cosmos SDK on all `KVStore` if tracing is enabled on the parent `MultiStore`. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/store/tracekv/store.go#L20-L43 +``` + +When each `KVStore` methods are called, `tracekv.Store` automatically logs `traceOperation` to the `Store.writer`. `traceOperation.Metadata` is filled with `Store.context` when it is not nil. `TraceContext` is a `map[string]interface{}`. + +### `Prefix` Store + +`prefix.Store` is a wrapper `KVStore` which provides automatic key-prefixing functionalities over the underlying `KVStore`. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/store/prefix/store.go#L15-L21 +``` + +When `Store.{Get, Set}()` is called, the store forwards the call to its parent, with the key prefixed with the `Store.prefix`. + +When `Store.Iterator()` is called, it does not simply prefix the `Store.prefix`, since it does not work as intended. In that case, some of the elements are traversed even they are not starting with the prefix. + +### `ListenKv` Store + +`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](https://github.com/cosmos/cosmos-sdk/tree/v0.47.0-rc1/store/streaming). + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/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`. + +## `BasicKVStore` interface + +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. diff --git a/versioned_docs/version-0.47/develop/advanced-concepts/05-encoding.md b/versioned_docs/version-0.47/develop/advanced-concepts/05-encoding.md new file mode 100644 index 000000000..55e889f98 --- /dev/null +++ b/versioned_docs/version-0.47/develop/advanced-concepts/05-encoding.md @@ -0,0 +1,320 @@ +--- +sidebar_position: 1 +--- + +# Encoding + +:::note Synopsis +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. +::: + +:::note + +### Pre-requisite Readings + +* [Anatomy of a Cosmos SDK application](../basics/00-app-anatomy.md) + +::: + +## Encoding + +The Cosmos SDK utilizes two binary wire encoding protocols, [Amino](https://github.com/tendermint/go-amino/) which is an object encoding specification and [Protocol Buffers](https://developers.google.com/protocol-buffers), a subset of Proto3 with an extension for +interface support. See the [Proto3 spec](https://developers.google.com/protocol-buffers/docs/proto3) +for more information on Proto3, which Amino is largely compatible with (but not with Proto2). + +Due to Amino having significant performance drawbacks, being reflection-based, and +not having any meaningful cross-language/client support, Protocol Buffers, specifically +[gogoprotobuf](https://github.com/cosmos/gogoproto/), is being used in place of Amino. +Note, this process of using Protocol Buffers over Amino is still an ongoing process. + +Binary wire encoding of types in the Cosmos SDK can be broken down into two main +categories, client encoding and store encoding. Client encoding mainly revolves +around transaction processing and signing, whereas store encoding revolves around +types used in state-machine transitions and what is ultimately stored in the Merkle +tree. + +For store encoding, protobuf definitions can exist for any type and will typically +have an Amino-based "intermediary" type. Specifically, the protobuf-based type +definition is used for serialization and persistence, whereas the Amino-based type +is used for business logic in the state-machine where they may convert back-n-forth. +Note, the Amino-based types may slowly be phased-out in the future, so developers +should take note to use the protobuf message definitions where possible. + +In the `codec` package, there exists two core interfaces, `BinaryCodec` and `JSONCodec`, +where the former encapsulates the current Amino interface except it operates on +types implementing the latter instead of generic `interface{}` types. + +In addition, there exists two implementations of `Codec`. The first being +`AminoCodec`, where both binary and JSON serialization is handled via Amino. The +second being `ProtoCodec`, where both binary and JSON serialization is handled +via Protobuf. + +This means that modules may use Amino or Protobuf encoding, but the types must +implement `ProtoMarshaler`. If modules wish to avoid implementing this interface +for their types, they may use an Amino codec directly. + +### Amino + +Every module uses an Amino codec to serialize types and interfaces. This codec typically +has types and interfaces registered in that module's domain only (e.g. messages), +but there are exceptions like `x/gov`. Each module exposes a `RegisterLegacyAminoCodec` function +that allows a user to provide a codec and have all the types registered. An application +will call this method for each necessary module. + +Where there is no protobuf-based type definition for a module (see below), Amino +is used to encode and decode raw wire bytes to the concrete type or interface: + +```go +bz := keeper.cdc.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`) + +#### Authz authorizations and Gov/Group proposals + +Since authz's `MsgExec` and `MsgGrant` message types, as well as gov's and group's `MsgSubmitProposal`, can contain different messages instances, it is important that developers +add the following code inside the `init` method of their module's `codec.go` file: + +```go +import ( + authzcodec "github.com/cosmos/cosmos-sdk/x/authz/codec" + govcodec "github.com/cosmos/cosmos-sdk/x/gov/codec" + groupcodec "github.com/cosmos/cosmos-sdk/x/group/codec" +) + +init() { + // Register all Amino interfaces and concrete types on the authz and gov Amino codec so that this can later be + // used to properly serialize MsgGrant, MsgExec and MsgSubmitProposal instances + RegisterLegacyAminoCodec(authzcodec.Amino) + RegisterLegacyAminoCodec(govcodec.Amino) + RegisterLegacyAminoCodec(groupcodec.Amino) +} +``` + +This will allow the `x/authz` module to properly serialize and de-serializes `MsgExec` instances using Amino, +which is required when signing this kind of messages using a Ledger. + +### Gogoproto + +Modules are encouraged to utilize Protobuf encoding for their respective types. In the Cosmos SDK, we use the [Gogoproto](https://github.com/cosmos/gogoproto) specific implementation of the Protobuf spec that offers speed and DX improvements compared to the official [Google protobuf implementation](https://github.com/protocolbuffers/protobuf). + +### Guidelines for protobuf message definitions + +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: + +* use `cosmos_proto.accepts_interface` to annote `Any` fields that accept interfaces + * pass the same fully qualified name as `protoName` to `InterfaceRegistry.RegisterInterface` + * example: `(cosmos_proto.accepts_interface) = "cosmos.gov.v1beta1.Content"` (and not just `Content`) +* annotate interface implementations with `cosmos_proto.implements_interface` + * pass the same fully qualified name as `protoName` to `InterfaceRegistry.RegisterInterface` + * example: `(cosmos_proto.implements_interface) = "cosmos.authz.v1beta1.Authorization"` (and not just `Authorization`) + +Code generators can then match the `accepts_interface` and `implements_interface` annotations to know whether some Protobuf messages are allowed to be packed in a given `Any` field or not. + +### Transaction Encoding + +Another important use of Protobuf is the encoding and decoding of +[transactions](./01-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. + +* The `TxEncoder` object performs the encoding. +* The `TxDecoder` object performs the decoding. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/types/tx_msg.go#L76-L80 +``` + +A standard implementation of both these objects can be found in the [`auth/tx` module](../modules/auth/tx/README.md): + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/auth/tx/decoder.go +``` + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/auth/tx/encoder.go +``` + +See [ADR-020](../architecture/adr-020-protobuf-transaction-encoding.md) for details of how a transaction is encoded. + +### Interface Encoding and Usage of `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/03-accounts.md): + +```protobuf +message Profile { + // account is the account associated to a profile. + cosmos.auth.v1beta1.BaseAccount account = 1; + // bio is a short description of the account. + string bio = 4; +} +``` + +In this `Profile` example, we hardcoded `account` as a `BaseAccount`. However, there are several other types of [user accounts related to vesting](../modules/auth/1-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? + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/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: + +```protobuf +message Profile { + // account is the account associated to a profile. + google.protobuf.Any account = 1 [ + (cosmos_proto.accepts_interface) = "cosmos.auth.v1beta1.AccountI"; // Asserts that this field only accepts Go types implementing `AccountI`. It is purely informational for now. + ]; + // bio is a short description of the account. + string bio = 4; +} +``` + +To add an account inside a profile, we need to "pack" it inside an `Any` first, using `codectypes.NewAnyWithValue`: + +```go +var myAccount AccountI +myAccount = ... // Can be a BaseAccount, a ContinuousVestingAccount or any struct implementing `AccountI` + +// Pack the account into an Any +accAny, err := codectypes.NewAnyWithValue(myAccount) +if err != nil { + return nil, err +} + +// Create a new Profile with the any. +profile := Profile { + Account: accAny, + Bio: "some bio", +} + +// We can then marshal the profile as usual. +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.47.0-rc1/x/auth/keeper/keeper.go#L240-L243). + +The reverse operation of retrieving the concrete Go type from inside an `Any`, called "unpacking", is done with the `GetCachedValue()` on `Any`. + +```go +profileBz := ... // The proto-encoded bytes of a Profile, e.g. retrieved through gRPC. +var myProfile Profile +// Unmarshal the bytes into the myProfile struct. +err := cdc.Unmarshal(profilebz, &myProfile) + +// Let's see the types of the Account field. +fmt.Printf("%T\n", myProfile.Account) // Prints "Any" +fmt.Printf("%T\n", myProfile.Account.GetCachedValue()) // Prints "BaseAccount", "ContinuousVestingAccount" or whatever was initially packed in the Any. + +// Get the address of the accountt. +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: + +```go +func (p *Profile) UnpackInterfaces(unpacker codectypes.AnyUnpacker) error { + if p.Account != nil { + var account AccountI + return unpacker.UnpackAny(p.Account, &account) + } + + return nil +} +``` + +The `UnpackInterfaces` gets called recursively on all structs implementing this method, to allow all `Any`s to have their `GetCachedValue()` correctly populated. + +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). + +#### `Any` Encoding in the Cosmos SDK + +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): + +* 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.47.0-rc1/x/staking/types/staking.pb.go#L340-L377) struct that contains information about a validator. + +A real-life example of encoding the pubkey as `Any` inside the Validator struct in x/staking is shown in the following example: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/staking/types/validator.go#L41-L64 +``` + +## FAQ + +### How to create modules using protobuf encoding + +#### Defining module types + +Protobuf types can be defined to encode: + +* state +* [`Msg`s](../building-modules/02-messages-and-queries.md#messages) +* [Query services](../building-modules/04-query-services.md) +* [genesis](../building-modules/08-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) + +### How to update modules to protobuf encoding + +If modules do not contain any interfaces (e.g. `Account` or `Content`), then they +may simply migrate any existing types that +are encoded and persisted via their concrete Amino codec to Protobuf (see 1. for further guidelines) and accept a `Marshaler` as the codec which is implemented via the `ProtoCodec` +without any further customization. + +However, if a module type composes an interface, it must wrap it in the `sdk.Any` (from `/types` package) type. To do that, a module-level .proto file must use [`google.protobuf.Any`](https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/any.proto) for respective message type interface types. + +For example, in the `x/evidence` module defines an `Evidence` interface, which is used by the `MsgSubmitEvidence`. The structure definition must use `sdk.Any` to wrap the evidence file. In the proto file we define it as follows: + +```protobuf +// proto/cosmos/evidence/v1beta1/tx.proto + +message MsgSubmitEvidence { + string submitter = 1; + google.protobuf.Any evidence = 2 [(cosmos_proto.accepts_interface) = "cosmos.evidence.v1beta1.Evidence"]; +} +``` + +The Cosmos SDK `codec.Codec` interface provides support methods `MarshalInterface` and `UnmarshalInterface` to easy encoding of state to `Any`. + +Module should register interfaces using `InterfaceRegistry` which provides a mechanism for registering interfaces: `RegisterInterface(protoName string, iface interface{}, impls ...proto.Message)` and implementations: `RegisterImplementations(iface interface{}, impls ...proto.Message)` that can be safely unpacked from Any, similarly to type registration with Amino: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/codec/types/interface_registry.go#L24-L57 +``` + +In addition, an `UnpackInterfaces` phase should be introduced to deserialization to unpack interfaces before they're needed. Protobuf types that contain a protobuf `Any` either directly or via one of their members should implement the `UnpackInterfacesMessage` interface: + +```go +type UnpackInterfacesMessage interface { + UnpackInterfaces(InterfaceUnpacker) error +} +``` + +### Custom Stringer + +Using `option (gogoproto.goproto_stringer) = false;` in a proto message definition leads to unexpected behaviour, like returning wrong output or having missing fields in the output. +For that reason a proto Message's `String()` must not be customized, and the `goproto_stringer` option must be avoided. + +A correct YAML output can be obtained through ProtoJSON, using the `JSONToYAML` function: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/codec/yaml.go#L8-L20 +``` + +For example: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/auth/types/account.go#L141-L151 +``` diff --git a/versioned_docs/version-0.47/develop/advanced-concepts/06-grpc_rest.md b/versioned_docs/version-0.47/develop/advanced-concepts/06-grpc_rest.md new file mode 100644 index 000000000..51ca4db40 --- /dev/null +++ b/versioned_docs/version-0.47/develop/advanced-concepts/06-grpc_rest.md @@ -0,0 +1,100 @@ +--- +sidebar_position: 1 +--- + +# gRPC, REST, and CometBFT Endpoints + +:::note Synopsis +This document presents an overview of all the endpoints a node exposes: gRPC, REST as well as some other endpoints. +::: + +## 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 CometBFT RPC endpoint (default port: `26657`). + +:::tip +The node also exposes some other endpoints, such as the CometBFT P2P endpoint, or the [Prometheus endpoint](https://docs.cometbft.com/v0.37/core/metrics), which are not directly related to the Cosmos SDK. Please refer to the [CometBFT documentation](https://docs.cometbft.com/v0.37/core/configuration) for more information about these endpoints. +::: + +## gRPC Server + +In the Cosmos SDK, Protobuf is the main [encoding](./encoding) library. 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. + +Each module exposes a [Protobuf `Query` service](../building-modules/02-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: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/server/types/app.go#L46-L48 +``` + +Note: It is not possible to expose any [Protobuf `Msg` service](../building-modules/02-messages-and-queries.md#messages) endpoints via gRPC. Transactions must be generated and signed using the CLI or programmatically before they can be broadcasted using gRPC. See [Generating, Signing, and Broadcasting Transactions](../run-node/03-txs.md) for more information. + +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.enable = true|false` field defines if the gRPC server should be enabled. Defaults to `true`. +* `grpc.address = {string}` field defines the `ip:port` the server should bind to. Defaults to `localhost:9090`. + +:::tip +`~/.simapp` is the directory where the node's configuration and databases are stored. By default, it's set to `~/.{app_name}`. +::: + +Once the gRPC server is started, you can send requests to it using a gRPC client. Some examples are given in our [Interact with the Node](../run-node/02-interact-node.md#using-grpc) tutorial. + +An overview of all available gRPC endpoints shipped with the Cosmos SDK is [Protobuf documentation](https://buf.build/cosmos/cosmos-sdk). + +## REST Server + +Cosmos SDK supports REST routes via gRPC-gateway. + +All routes are configured under the following fields in `~/.simapp/config/app.toml`: + +* `api.enable = true|false` field defines if the REST server should be enabled. Defaults to `false`. +* `api.address = {string}` field defines the `ip:port` the server should bind to. Defaults to `tcp://localhost:1317`. +* some additional API configuration options are defined in `~/.simapp/config/app.toml`, along with comments, please refer to that file directly. + +### gRPC-gateway REST Routes + +If, for various reasons, you cannot use gRPC (for example, you are building a web application, and browsers don't support HTTP2 on which gRPC is built), then the Cosmos SDK offers REST routes via gRPC-gateway. + +[gRPC-gateway](https://grpc-ecosystem.github.io/grpc-gateway/) is a tool to expose gRPC endpoints as REST endpoints. For each 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: + +```protobuf reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/bank/v1beta1/query.proto#L23-L30 +``` + +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. + +### Swagger + +A [Swagger](https://swagger.io/) (or OpenAPIv2) specification file is exposed under the `/swagger` route on the API server. Swagger is an open specification describing the API endpoints a server serves, including description, input arguments, return types and much more about each endpoint. + +Enabling the `/swagger` endpoint is configurable inside `~/.simapp/config/app.toml` via the `api.swagger` field, which is set to true by default. + +For application developers, you may want to generate your own Swagger definitions based on your custom modules. +The Cosmos SDK's [Swagger generation script](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/scripts/protoc-swagger-gen.sh) is a good place to start. + +## CometBFT RPC + +Independently from the Cosmos SDK, CometBFT 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://localhost:26657`. An OpenAPI specification of all CometBFT RPC endpoints is available [here](https://docs.cometbft.com/master/rpc/). + +Some CometBFT RPC endpoints are directly related to the Cosmos SDK: + +* `/abci_query`: this endpoint will query the application for state. As the `path` parameter, you can send the following strings: + * any Protobuf fully-qualified service method, such as `/cosmos.bank.v1beta1.Query/AllBalances`. The `data` field should then include the method's request parameter(s) encoded as bytes using Protobuf. + * `/app/simulate`: this will simulate a transaction, and return some information such as gas used. + * `/app/version`: this will return the application's version. + * `/store/{path}`: this will query the store directly. + * `/p2p/filter/addr/{port}`: this will return a filtered list of the node's P2P peers by address port. + * `/p2p/filter/id/{id}`: this will return a filtered list of the node's P2P peers by ID. +* `/broadcast_tx_{aync,async,commit}`: these 3 endpoint will broadcast a transaction to other peers. CLI, gRPC and REST expose [a way to broadcast transations](./01-transactions.md#broadcasting-the-transaction), but they all use these 3 CometBFT RPCs under the hood. + +## Comparison Table + +| Name | Advantages | Disadvantages | +| -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | +| gRPC | - can use code-generated stubs in various languages
- supports streaming and bidirectional communication (HTTP2)
- small wire binary sizes, faster transmission | - based on HTTP2, not available in browsers
- learning curve (mostly due to Protobuf) | +| REST | - ubiquitous
- client libraries in all languages, faster implementation
| - only supports unary request-response communication (HTTP1.1)
- bigger over-the-wire message sizes (JSON) | +| CometBFT RPC | - easy to use | - bigger over-the-wire message sizes (JSON) | diff --git a/versioned_docs/version-0.47/develop/advanced-concepts/07-cli.md b/versioned_docs/version-0.47/develop/advanced-concepts/07-cli.md new file mode 100644 index 000000000..e149dad67 --- /dev/null +++ b/versioned_docs/version-0.47/develop/advanced-concepts/07-cli.md @@ -0,0 +1,171 @@ +--- +sidebar_position: 1 +--- + +# Command-Line Interface + +:::note Synopsis +This document describes how command-line interface (CLI) works on a high-level, for an [**application**](../basics/00-app-anatomy.md). A separate document for implementing a CLI for a Cosmos SDK [**module**](../building-modules/01-intro.md) can be found [here](../building-modules/09-module-interfaces.md#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**](#root-command) understand the actions users wish to take, such as `tx` for creating a transaction and `query` for querying the application. Each command can also have nested subcommands, necessary for naming the specific transaction type. Users also supply **Arguments**, such as account numbers to send coins to, and [**Flags**](#flags) to modify various aspects of the commands, such as gas prices or which node to broadcast to. + +Here is an example of a command a user might enter to interact with the simapp CLI `simd` in order to send some tokens: + +```bash +simd tx bank send $MY_VALIDATOR_ADDRESS $RECIPIENT 1000stake --gas auto --gas-prices +``` + +The first four strings specify the command: + +* The root command for the entire application `simd`. +* The subcommand `tx`, which contains all commands that let users create transactions. +* The subcommand `bank` to indicate which module to route the command to ([`x/bank`](../modules/bank/README.md) module in this case). +* The type of transaction `send`. + +The next two strings are arguments: the `from_address` the user wishes to send from, the `to_address` of the recipient, and the `amount` they want to send. Finally, the last few strings of the command are optional flags to indicate how much the user is willing to pay in fees (calculated using the amount of gas used to execute the transaction and the gas prices provided by the user). + +The CLI interacts with a [node](../core/03-node.md) to handle this command. The interface itself is defined in a `main.go` file. + +### Building the CLI + +The `main.go` file needs to have a `main()` function that creates a root command, to which all the application commands will be added as subcommands. The root command additionally handles: + +* **setting configurations** by reading in configuration files (e.g. the 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/05-encoding.md) is used to encode and decode data structures for the application - stores can only persist `[]byte`s so the developer must define a serialization format for their data structures or use the default, Protobuf. +* **adding subcommand** for all the possible user interactions, including [transaction commands](#transaction-commands) and [query commands](#query-commands). + +The `main()` function finally creates an executor and [execute](https://pkg.go.dev/github.com/spf13/cobra#Command.Execute) the root command. See an example of `main()` function from the `simapp` application: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/simapp/simd/main.go#L12-L24 +``` + +The rest of the document will detail what needs to be implemented for each step and include smaller portions of code from the `simapp` CLI files. + +## Adding Commands to the CLI + +Every application CLI first constructs a root command, then adds functionality by aggregating subcommands (often with further nested subcommands) using `rootCmd.AddCommand()`. The bulk of an application's unique capabilities lies in its transaction and query commands, called `TxCmd` and `QueryCmd` respectively. + +### Root Command + +The root command (called `rootCmd`) is what the user first types into the command line to indicate which application they wish to interact with. The string used to invoke the command (the "Use" field) is typically the name of the application suffixed with `-d`, e.g. `simd` or `gaiad`. The root command typically includes the following commands to support basic functionality in the application. + +* **Status** command from the Cosmos SDK rpc client tools, which prints information about the status of the connected [`Node`](../core/03-node.md). The Status of a node includes `NodeInfo`,`SyncInfo` and `ValidatorInfo`. +* **Keys** [commands](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/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.47.0-rc1/client/keys/add.go). For more details about usage of `--keyring-backend` for storage of key credentials look at the [keyring docs](../run-node/00-keyring.md). +* **Server** commands from the Cosmos SDK server package. These commands are responsible for providing the mechanisms necessary to start an ABCI CometBFT application and provides the CLI framework (based on [cobra](https://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. +Learn more [here](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/server). +* [**Transaction**](#transaction-commands) commands. +* [**Query**](#query-commands) commands. + +Next is an example `rootCmd` function from the `simapp` application. It instantiates the root command, adds a [*persistent* flag](#flags) and `PreRun` function to be run before every execution, and adds all of the necessary subcommands. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/simapp/simd/cmd/root.go#L38-L92 +``` + +`rootCmd` has a function called `initAppConfig()` which is useful for setting the application's custom configs. +By default app uses CometBFT app config template from Cosmos SDK, which can be over-written via `initAppConfig()`. +Here's an example code to override default `app.toml` template. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/simapp/simd/cmd/root.go#L106-L161 +``` + +The `initAppConfig()` also allows overriding the default Cosmos SDK's [server config](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/server/config/config.go#L235). 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. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/simapp/simd/cmd/root.go#L126-L142 +``` + +The root-level `status` and `keys` subcommands are common across most applications and do not interact with application state. The bulk of an application's functionality - what users can actually *do* with it - is enabled by its `tx` and `query` commands. + +### Transaction Commands + +[Transactions](./01-transactions.md) are objects wrapping [`Msg`s](../building-modules/02-messages-and-queries.md#messages) that trigger state changes. To enable the creation of transactions using the CLI interface, a function `txCommand` is generally added to the `rootCmd`: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/simapp/simd/cmd/root.go#L177-L184 +``` + +This `txCommand` function adds all the transaction available to end-users for the application. This typically includes: + +* **Sign command** from the [`auth`](../modules/auth/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/09-module-interfaces.md#transaction-commands)** the application is dependent on, retrieved by using the [basic module manager's](../building-modules/01-module-manager.md#basic-manager) `AddTxCommands()` function. + +Here is an example of a `txCommand` aggregating these subcommands from the `simapp` application: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/simapp/simd/cmd/root.go#L227-L251 +``` + +### Query Commands + +[**Queries**](../building-modules/02-messages-and-queries.md#queries) are objects that allow users to retrieve information about the application's state. To enable the creation of queries using the CLI interface, a function `queryCommand` is generally added to the `rootCmd`: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/simapp/simd/cmd/root.go#L177-L184 +``` + +This `queryCommand` function adds all the queries available to end-users for the application. This typically includes: + +* **QueryTx** and/or other transaction query commands] from the `auth` module which allow the user to search for a transaction by inputting its hash, a list of tags, or a block height. These queries allow users to see if transactions have been included in a block. +* **Account command** from the `auth` module, which displays the state (e.g. account balance) of an account given an address. +* **Validator command** from the 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/09-module-interfaces.md#query-commands)** the application is dependent on, retrieved by using the [basic module manager's](../building-modules/01-module-manager.md#basic-manager) `AddQueryCommands()` function. + +Here is an example of a `queryCommand` aggregating subcommands from the `simapp` application: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/simapp/simd/cmd/root.go#L204-L225 +``` + +## 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/02-interact-node.md#configuring-the-node-using-apptoml). Commonly pre-configured flags include the `--node` to connect to and `--chain-id` of the blockchain the user wishes to interact with. + +A *persistent* flag (as opposed to a *local* flag) added to a command transcends all of its children: subcommands will inherit the configured values for these flags. Additionally, all flags have default values when they are added to commands; some toggle an option off but others are empty values that the user needs to override to create valid commands. A flag can be explicitly marked as *required* so that an error is automatically thrown if the user does not provide a value, but it is also acceptable to handle unexpected missing flags differently. + +Flags are added to commands directly (generally in the [module's CLI file](../building-modules/09-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. + +## 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 reducing the amount of flags typed for routine operations. For example instead of: + +```shell +gaia --home=./ --node= --chain-id="testchain-1" --keyring-backend=test tx ... --from= +``` + +this will be more convenient: + +```shell +# define env variables in .env, .envrc etc +GAIA_HOME= +GAIA_NODE= +GAIA_CHAIN_ID="testchain-1" +GAIA_KEYRING_BACKEND="test" + +# and later just use +gaia tx ... --from= +``` + +## Configurations + +It is vital that the root command of an application uses `PersistentPreRun()` cobra command property for executing the command, so all child commands have access to the server and client contexts. These contexts are set as their default values initially and maybe modified, scoped to the command, in their respective `PersistentPreRun()` functions. Note that the `client.Context` is typically pre-populated with "default" values that may be useful for all commands to inherit and override if necessary. + +Here is an example of an `PersistentPreRun()` function from `simapp`: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/simapp/simd/cmd/root.go#L63-L86 +``` + +The `SetCmdClientContextHandler` call reads persistent flags via `ReadPersistentCommandFlags` which creates a `client.Context` and sets that on the root command's `Context`. + +The `InterceptConfigsPreRunHandler` call creates a viper literal, default `server.Context`, and a logger and sets that on the root command's `Context`. The `server.Context` will be modified and saved to disk via the internal `interceptConfigs` call, which either reads or creates a CometBFT 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. diff --git a/versioned_docs/version-0.47/develop/advanced-concepts/08-events.md b/versioned_docs/version-0.47/develop/advanced-concepts/08-events.md new file mode 100644 index 000000000..b07aaffd4 --- /dev/null +++ b/versioned_docs/version-0.47/develop/advanced-concepts/08-events.md @@ -0,0 +1,162 @@ +--- +sidebar_position: 1 +--- +# Events + +:::note Synopsis +`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. +::: + +:::note + +### Pre-requisite Readings + +* [Anatomy of a Cosmos SDK application](../basics/00-app-anatomy.md) +* [CometBFT Documentation on Events](https://docs.cometbft.com/v0.37/spec/abci/abci++_basic_concepts#events) + +::: + +## Events + +Events are implemented in the Cosmos SDK as an alias of the ABCI `Event` type and +take the form of: `{eventType}.{attributeKey}={attributeValue}`. + +```protobuf reference +https://github.com/cometbft/cometbft/blob/v0.37.0/proto/tendermint/abci/types.proto#L334-L343 +``` + +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}`. + +:::tip +To parse the attribute values as strings, make sure to add `'` (single quotes) around each attribute value. +::: + +_Typed Events_ are Protobuf-defined [messages](../architecture/adr-032-typed-events.md) used by the Cosmos SDK +for emitting and querying Events. They are defined in a `event.proto` file, on a **per-module basis** and are read as `proto.Message`. +_Legacy Events_ are defined on a **per-module basis** in the module's `/types/events.go` file. +They are triggered from the module's Protobuf [`Msg` service](../building-modules/03-msg-services.md) +by using the [`EventManager`](#eventmanager). + +In addition, each module documents its events under in the `Events` sections of its specs (x/{moduleName}/`README.md`). + +Lastly, Events are returned to the underlying consensus engine in the response of the following ABCI messages: + +* [`BeginBlock`](./00-baseapp.md#beginblock) +* [`EndBlock`](./00-baseapp.md#endblock) +* [`CheckTx`](./00-baseapp.md#checktx) +* [`DeliverTx`](./00-baseapp.md#delivertx) + +### Examples + +The following examples show how to query Events using the Cosmos SDK. + +| Event | Description | +| ------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `tx.height=23` | Query all transactions at height 23 | +| `message.action='/cosmos.bank.v1beta1.Msg/Send'` | Query all transactions containing a x/bank `Send` [Service `Msg`](../building-modules/03-msg-services.md). Note the `'`s around the value. | +| `message.action='send'` | Query all transactions containing a x/bank `Send` [legacy `Msg`](../building-modules/03-msg-services.md#legacy-amino-msgs). Note the `'`s around the value. | +| `message.module='bank'` | Query all transactions containing messages from the x/bank module. Note the `'`s around the value. | +| `create_validator.validator='cosmosval1...'` | x/staking-specific Event, see [x/staking SPEC](../modules/staking/README.md). | + +## EventManager + +In Cosmos SDK applications, Events are managed by an abstraction called the `EventManager`. +Internally, the `EventManager` tracks a list of Events for the entire execution flow of a +transaction or `BeginBlock`/`EndBlock`. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/types/events.go#L24-L27 +``` + +The `EventManager` comes with a set of useful methods to manage Events. The method +that is used most by module and application developers is `EmitTypedEvent` or `EmitEvent` that tracks +an Event in the `EventManager`. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/types/events.go#L53-L62 +``` + +Module developers should handle Event emission via the `EventManager#EmitTypedEvent` or `EventManager#EmitEvent` in each message +`Handler` and in each `BeginBlock`/`EndBlock` handler. The `EventManager` is accessed via +the [`Context`](./02-context.md), where Event should be already registered, and emitted like this: + + +**Typed events:** + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/group/keeper/msg_server.go#L88-L91 +``` + +**Legacy events:** + +```go +ctx.EventManager().EmitEvent( + sdk.NewEvent(eventType, sdk.NewAttribute(attributeKey, attributeValue)), +) +``` + +Module's `handler` function should also set a new `EventManager` to the `context` to isolate emitted Events per `message`: + +```go +func NewHandler(keeper Keeper) sdk.Handler { + return func(ctx sdk.Context, msg sdk.Msg) (*sdk.Result, error) { + ctx = ctx.WithEventManager(sdk.NewEventManager()) + switch msg := msg.(type) { +``` + +See the [`Msg` services](../building-modules/03-msg-services.md) concept doc for a more detailed +view on how to typically implement Events and use the `EventManager` in modules. + +## Subscribing to Events + +You can use CometBFT's [Websocket](https://docs.cometbft.com/v0.37/core/subscription) to subscribe to Events by calling the `subscribe` RPC method: + +```json +{ + "jsonrpc": "2.0", + "method": "subscribe", + "id": "0", + "params": { + "query": "tm.event='eventCategory' AND eventType.eventAttribute='attributeValue'" + } +} +``` + +The main `eventCategory` you can subscribe to are: + +* `NewBlock`: Contains Events triggered during `BeginBlock` and `EndBlock`. +* `Tx`: Contains Events triggered during `DeliverTx` (i.e. transaction processing). +* `ValidatorSetUpdates`: Contains validator set updates for the block. + +These Events are triggered from the `state` package after a block is committed. You can get the +full list of Event categories [on the CometBFT Go documentation](https://pkg.go.dev/github.com/cometbft/cometbft/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 `Mint` transaction triggers an Event of type `EventMint` and has an `Id` and an `Owner` as `attributes` (as defined in the [`events.proto` file of the `NFT` module](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/nft/v1beta1/event.proto#L21-L31)). + +Subscribing to this Event would be done like so: + +```json +{ + "jsonrpc": "2.0", + "method": "subscribe", + "id": "0", + "params": { + "query": "tm.event='Tx' AND mint.owner='ownerAddress'" + } +} +``` + +where `ownerAddress` is an address following the [`AccAddress`](../basics/03-accounts.md#addresses) format. + +The same way can be used to subscribe to [legacy events](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/bank/types/events.go). + +## Default Events + +There are a few events that are automatically emitted for all messages, directly from `baseapp`. + +* `message.action`: The name of the message type. +* `message.sender`: The address of the message signer. +* `message.module`: The name of the module that emitted the message. diff --git a/versioned_docs/version-0.47/develop/advanced-concepts/09-telemetry.md b/versioned_docs/version-0.47/develop/advanced-concepts/09-telemetry.md new file mode 100644 index 000000000..2be2dc680 --- /dev/null +++ b/versioned_docs/version-0.47/develop/advanced-concepts/09-telemetry.md @@ -0,0 +1,128 @@ +--- +sidebar_position: 1 +--- + +# Telemetry + +:::note Synopsis +Gather relevant insights about your application and modules with custom metrics and telemetry. +::: + +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. To enable telemetrics, set `telemetry.enabled = true` in the app.toml config file. + +The Cosmos SDK currently supports enabling in-memory and prometheus as telemetry sinks. In-memory sink is always attached (when the telemetry is enabled) with 10 second interval and 1 minute retention. This means that metrics will be aggregated over 10 seconds, and metrics will be kept alive for 1 minute. + +To query active metrics (see retention note above) you have to enable API server (`api.enabled = true` in the app.toml). Single API endpoint is exposed: `http://localhost:1317/metrics?format={text|prometheus}`, the default being `text`. + +## Emitting metrics + +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](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/telemetry/wrapper.go). Example: + +```go +func EndBlocker(ctx sdk.Context, k keeper.Keeper) { + defer telemetry.ModuleMeasureSince(types.ModuleName, time.Now(), telemetry.MetricKeyEndBlocker) + + // ... +} +``` + +Developers may use the `telemetry` package directly, which provides wrappers around metric APIs +that include adding useful labels, or they must use the `go-metrics` library directly. It is preferable +to add as much context and adequate dimensionality to metrics as possible, so the `telemetry` package +is advised. Regardless of the package or method used, the Cosmos SDK supports the following metrics +types: + +* gauges +* summaries +* counters + +## Labels + +Certain components of modules will have their name automatically added as a label (e.g. `BeginBlock`). +Operators may also supply the application with a global set of labels that will be applied to all +metrics emitted using the `telemetry` package (e.g. chain-id). Global labels are supplied as a list +of [name, value] tuples. + +Example: + +```toml +global-labels = [ + ["chain_id", "chain-OfXo4V"], +] +``` + +## Cardinality + +Cardinality is key, specifically label and key cardinality. Cardinality is how many unique values of +something there are. So there is naturally a tradeoff between granularity and how much stress is put +on the telemetry sink in terms of indexing, scrape, and query performance. + +Developers should take care to support metrics with enough dimensionality and granularity to be +useful, but not increase the cardinality beyond the sink's limits. A general rule of thumb is to not +exceed a cardinality of 10. + +Consider the following examples with enough granularity and adequate cardinality: + +* begin/end blocker time +* tx gas used +* block gas used +* amount of tokens minted +* amount of accounts created + +The following examples expose too much cardinality and may not even prove to be useful: + +* transfers between accounts with amount +* voting/deposit amount from unique addresses + +## Supported Metrics + +| Metric | Description | Unit | Type | +|:--------------------------------|:------------------------------------------------------------------------------------------|:----------------|:--------| +| `tx_count` | Total number of txs processed via `DeliverTx` | tx | counter | +| `tx_successful` | Total number of successful txs processed via `DeliverTx` | tx | counter | +| `tx_failed` | Total number of failed txs processed via `DeliverTx` | tx | counter | +| `tx_gas_used` | The total amount of gas used by a tx | gas | gauge | +| `tx_gas_wanted` | The total amount of gas requested by a tx | gas | gauge | +| `tx_msg_send` | The total amount of tokens sent in a `MsgSend` (per denom) | token | gauge | +| `tx_msg_withdraw_reward` | The total amount of tokens withdrawn in a `MsgWithdrawDelegatorReward` (per denom) | token | gauge | +| `tx_msg_withdraw_commission` | The total amount of tokens withdrawn in a `MsgWithdrawValidatorCommission` (per denom) | token | gauge | +| `tx_msg_delegate` | The total amount of tokens delegated in a `MsgDelegate` | token | gauge | +| `tx_msg_begin_unbonding` | The total amount of tokens undelegated in a `MsgUndelegate` | token | gauge | +| `tx_msg_begin_begin_redelegate` | The total amount of tokens redelegated in a `MsgBeginRedelegate` | token | gauge | +| `tx_msg_ibc_transfer` | The total amount of tokens transferred via IBC in a `MsgTransfer` (source or sink chain) | token | gauge | +| `ibc_transfer_packet_receive` | The total amount of tokens received in a `FungibleTokenPacketData` (source or sink chain) | token | gauge | +| `new_account` | Total number of new accounts created | account | counter | +| `gov_proposal` | Total number of governance proposals | proposal | counter | +| `gov_vote` | Total number of governance votes for a proposal | vote | counter | +| `gov_deposit` | Total number of governance deposits for a proposal | deposit | counter | +| `staking_delegate` | Total number of delegations | delegation | counter | +| `staking_undelegate` | Total number of undelegations | undelegation | counter | +| `staking_redelegate` | Total number of redelegations | redelegation | counter | +| `ibc_transfer_send` | Total number of IBC transfers sent from a chain (source or sink) | transfer | counter | +| `ibc_transfer_receive` | Total number of IBC transfers received to a chain (source or sink) | transfer | counter | +| `ibc_client_create` | Total number of clients created | create | counter | +| `ibc_client_update` | Total number of client updates | update | counter | +| `ibc_client_upgrade` | Total number of client upgrades | upgrade | counter | +| `ibc_client_misbehaviour` | Total number of client misbehaviours | misbehaviour | counter | +| `ibc_connection_open-init` | Total number of connection `OpenInit` handshakes | handshake | counter | +| `ibc_connection_open-try` | Total number of connection `OpenTry` handshakes | handshake | counter | +| `ibc_connection_open-ack` | Total number of connection `OpenAck` handshakes | handshake | counter | +| `ibc_connection_open-confirm` | Total number of connection `OpenConfirm` handshakes | handshake | counter | +| `ibc_channel_open-init` | Total number of channel `OpenInit` handshakes | handshake | counter | +| `ibc_channel_open-try` | Total number of channel `OpenTry` handshakes | handshake | counter | +| `ibc_channel_open-ack` | Total number of channel `OpenAck` handshakes | handshake | counter | +| `ibc_channel_open-confirm` | Total number of channel `OpenConfirm` handshakes | handshake | counter | +| `ibc_channel_close-init` | Total number of channel `CloseInit` handshakes | handshake | counter | +| `ibc_channel_close-confirm` | Total number of channel `CloseConfirm` handshakes | handshake | counter | +| `tx_msg_ibc_recv_packet` | Total number of IBC packets received | packet | counter | +| `tx_msg_ibc_acknowledge_packet` | Total number of IBC packets acknowledged | acknowledgement | counter | +| `ibc_timeout_packet` | Total number of IBC timeout packets | timeout | counter | +| `store_iavl_get` | Duration of an IAVL `Store#Get` call | ms | summary | +| `store_iavl_set` | Duration of an IAVL `Store#Set` call | ms | summary | +| `store_iavl_has` | Duration of an IAVL `Store#Has` call | ms | summary | +| `store_iavl_delete` | Duration of an IAVL `Store#Delete` call | ms | summary | +| `store_iavl_commit` | Duration of an IAVL `Store#Commit` call | ms | summary | +| `store_iavl_query` | Duration of an IAVL `Store#Query` call | ms | summary | diff --git a/versioned_docs/version-0.46/develop/advanced-concepts/10-ocap.md b/versioned_docs/version-0.47/develop/advanced-concepts/10-ocap.md similarity index 100% rename from versioned_docs/version-0.46/develop/advanced-concepts/10-ocap.md rename to versioned_docs/version-0.47/develop/advanced-concepts/10-ocap.md diff --git a/versioned_docs/version-0.47/develop/advanced-concepts/11-runtx_middleware.md b/versioned_docs/version-0.47/develop/advanced-concepts/11-runtx_middleware.md new file mode 100644 index 000000000..1db62be7a --- /dev/null +++ b/versioned_docs/version-0.47/develop/advanced-concepts/11-runtx_middleware.md @@ -0,0 +1,67 @@ +--- +sidebar_position: 1 +--- + +# RunTx recovery middleware + +`BaseApp.runTx()` function handles Go 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. + +More context can found in the corresponding [ADR-022](../architecture/adr-022-custom-panic-handling.md) and the implementation in [recovery.go](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/baseapp/recovery.go). + +## Interface + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/baseapp/recovery.go#L11-L14 +``` + +`recoveryObj` is a return value for `recover()` function from the `buildin` Go package. + +**Contract:** + +* RecoveryHandler returns `nil` if `recoveryObj` wasn't handled and should be passed to the next recovery middleware; +* RecoveryHandler returns a non-nil `error` if `recoveryObj` was handled; + +## Custom RecoveryHandler register + +`BaseApp.AddRunTxRecoveryHandler(handlers ...RecoveryHandler)` + +BaseApp method adds recovery middleware to the default recovery chain. + +## Example + +Lets assume we want to emit the "Consensus failure" chain state if some particular error occurred. + +We have a module keeper that panics: + +```go +func (k FooKeeper) Do(obj interface{}) { + if obj == nil { + // that shouldn't happen, we need to crash the app + err := sdkErrors.Wrap(fooTypes.InternalError, "obj is nil") + panic(err) + } +} +``` + +By default that panic would be recovered and an error message will be printed to log. To override that behaviour we should register a custom RecoveryHandler: + +```go +// Cosmos SDK application constructor +customHandler := func(recoveryObj interface{}) error { + err, ok := recoveryObj.(error) + if !ok { + return nil + } + + if fooTypes.InternalError.Is(err) { + panic(fmt.Errorf("FooKeeper did panic with error: %w", err)) + } + + return nil +} + +baseApp := baseapp.NewBaseApp(...) +baseApp.AddRunTxRecoveryHandler(customHandler) +``` diff --git a/versioned_docs/version-0.47/develop/advanced-concepts/12-simulation.md b/versioned_docs/version-0.47/develop/advanced-concepts/12-simulation.md new file mode 100644 index 000000000..ed23f3990 --- /dev/null +++ b/versioned_docs/version-0.47/develop/advanced-concepts/12-simulation.md @@ -0,0 +1,101 @@ +--- +sidebar_position: 1 +--- + +# 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 [`SimApp`](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/simapp/app_v2.go), which is a +`Baseapp` application that is used for running the [`simulation`](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/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://pkg.go.dev/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.47.0-rc1/x/simulation/client/cli/flags.go#L33-L57). + +## 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.47.0-rc1/x/simulation/client/cli/flags.go#L59-L78). + +:::tip +These modes are not mutually exclusive. So you can for example run a randomly +generated genesis state (`1`) with manually generated simulation params (`3`). +::: + +## Usage + +This is a general example of how simulations are run. For more specific examples +check the Cosmos SDK [Makefile](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/Makefile#L282-L318). + +```bash + $ go test -mod=readonly github.com/cosmos/cosmos-sdk/simapp \ + -run=TestApp \ + ... + -v -timeout 24h +``` + +## Debugging Tips + +Here are some suggestions when encountering a simulation failure: + +* Export the app state at the height where 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.47.0-rc1/x/staking/keeper/keeper.go#L65-L68) 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/14-simulator.md) +* Simulator tests diff --git a/versioned_docs/version-0.47/develop/advanced-concepts/13-proto-docs.md b/versioned_docs/version-0.47/develop/advanced-concepts/13-proto-docs.md new file mode 100644 index 000000000..6c8574465 --- /dev/null +++ b/versioned_docs/version-0.47/develop/advanced-concepts/13-proto-docs.md @@ -0,0 +1,7 @@ +--- +sidebar_position: 1 +--- + +# Protobuf Documentation + +See [Cosmos SDK Buf Proto-docs](https://buf.build/cosmos/cosmos-sdk/docs/main) diff --git a/versioned_docs/version-0.47/develop/advanced-concepts/14-tips.md b/versioned_docs/version-0.47/develop/advanced-concepts/14-tips.md new file mode 100644 index 000000000..2c566cfcf --- /dev/null +++ b/versioned_docs/version-0.47/develop/advanced-concepts/14-tips.md @@ -0,0 +1,214 @@ +--- +sidebar_position: 1 +--- + +# Transaction Tips + +:::note Synopsis +Transaction tips are a mechanism to pay for transaction fees using another denom than the native fee denom of the chain. They are still in beta, and are not included by default in the SDK. +::: + +## Context + +In a Cosmos ecosystem where more and more chains are connected via [IBC](https://ibc.cosmos.network/), it happens that users want to perform actions on chains where they don't have native tokens yet. An example would be an Osmosis user who wants to vote on a proposal on the Cosmos Hub, but they don't have ATOMs in their wallet. A solution would be to swap OSMO for ATOM just for voting on this proposal, but that is cumbersome. Cross-chain DeFi project [Emeris](https://emeris.com/) is another use case. + +Transaction tips is a new solution for cross-chain transaction fees payment, whereby the transaction initiator signs a transaction without specifying fees, but uses a new `Tip` field. They send this signed transaction to a fee relayer who will choose the transaction fees and broadcast the final transaction, and the SDK provides a mechanism that will transfer the pre-defined `Tip` to the fee payer, to cover for fees. + +Assuming we have two chains, A and B, we define the following terms: + +* **the tipper**: this is the initiator of the transaction, who wants to execute a `Msg` on chain A, but doesn't have any native chain A tokens, only chain B tokens. In our example above, the tipper is the Osmosis (chain B) user wanting to vote on a Cosmos Hub (chain A) proposal. +* **the fee payer**: this is the party that will relay and broadcast the final transaction on chain A, and has chain A tokens. The tipper doesn't need to trust the feepayer. +* **the target chain**: the chain where the `Msg` is executed, chain A in this case. + +## Transaction Tips Flow + +The transaction tips flow happens in multiple steps. + +1. The tipper sends via IBC some chain B tokens to chain A. These tokens will cover for fees on the target chain A. This means that chain A's bank module holds some IBC tokens under the tipper's address. + +2. The tipper drafts a transaction to be executed on the chain A. It can include chain A `Msg`s. However, instead of creating a normal transaction, they create the following `AuxSignerData` document: + + ```protobuf reference + https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/tx/v1beta1/tx.proto#L237-L256 + ``` + + where we have defined `SignDocDirectAux` as: + + ```protobuf reference + https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/tx/v1beta1/tx.proto#L67-L97 + ``` + + where `Tip` is defined as + + ```protobuf reference + https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/tx/v1beta1/tx.proto#L226-L235 + ``` + + Notice that this document doesn't sign over the final chain A fees. Instead, it includes a `Tip` field. It also doesn't include the whole `AuthInfo` object as in `SIGN_MODE_DIRECT`, only the minimum information needed by the tipper + +3. The tipper signs the `SignDocDirectAux` document and attaches the signature to the `AuxSignerData`, then sends the signed `AuxSignerData` to the fee payer. + +4. From the signed `AuxSignerData` document, the fee payer constructs a transaction, using the following algorithm: + +* use as `TxBody` the exact `AuxSignerData.SignDocDirectAux.body_bytes`, to not alter the original intent of the tipper, +* create an `AuthInfo` with: + * `AuthInfo.Tip` copied from `AuxSignerData.SignDocDirectAux.Tip`, + * `AuthInfo.Fee` chosen by the fee payer, which should cover for the transaction gas, but also be small enough so that the tip/fee exchange rate is economically interesting for the fee payer, + * `AuthInfo.SignerInfos` has two signers: the first signer is the tipper, using the public key, sequence and sign mode specified in `AuxSignerData`; and the second signer is the fee payer, using their favorite sign mode, +* a `Signatures` array with two items: the tipper's signature from `AuxSignerData.Sig`, and the final fee payer's signature. + +5. Broadcast the final transaction signed by the two parties to the target chain. Once included, the Cosmos SDK will trigger a transfer of the `Tip` specified in the transaction from the tipper address to the fee payer address. + +### Fee Payers Market + +The benefit of transaction tips for the tipper is clear: there is no need to swap tokens before executing a cross-chain message. + +For the fee payer, the benefit is in the tip v.s. fee exchange. Put simply, the fee payer pays the fees of an unknown tipper's transaction, and gets in exchange the tip that the tipper chose. There is an economic incentive for the fee payer to do so only when the tip is greater than the transaction fees, given the exchange rates between the two tokens. + +In the future, we imagine a market where fee payers will compete to include transactions from tippers, who on their side will optimize by specifying the lowest tip possible. A number of automated services might spin up to perform transaction gas simulation and exchange rate monitoring to optimize both the tip and fee values in real-time. + +### Tipper and Fee Payer Sign Modes + +As we mentioned in the flow above, the tipper signs over the `SignDocDirectAux`, and the fee payer signs over the whole final transaction. As such, both parties might use different sign modes. + +* The tipper MUST use `SIGN_MODE_DIRECT_AUX` or `SIGN_MODE_LEGACY_AMINO_JSON`. That is because the tipper needs to sign over the body, the tip, but not the other signers' information and not over the fee (which is unknown to the tipper). +* The fee payer MUST use `SIGN_MODE_DIRECT` or `SIGN_MODE_LEGACY_AMINO_JSON`. The fee payer signs over the whole transaction. + +For example, if the fee payer signs the whole transaction with `SIGN_MODE_DIRECT_AUX`, it will be rejected by the node, as that would introduce malleability issues (`SIGN_MODE_DIRECT_AUX` doesn't sign over fees). + +In both cases, using `SIGN_MODE_LEGACY_AMINO_JSON` is recommended only if hardware wallet signing is needed. + +## Enabling Tips on your Chain + +The transaction tips functionality is introduced in Cosmos SDK v0.46, so earlier versions do not have support for tips. It is however not included by default in a v0.46 app. Sending a transaction with tips to a chain which didn't enable tips will result in a no-op, i.e. the `tip` field in the transaction will be ignored. + +Enabling tips on a chain is done by adding the `TipDecorator` in the posthandler chain: + +```go +// HandlerOptions are the options required for constructing a SDK PostHandler which supports tips. +type HandlerOptions struct { + BankKeeper types.BankKeeper +} + +// MyPostHandler returns a posthandler chain with the TipDecorator. +func MyPostHandler(options HandlerOptions) (sdk.AnteHandler, error) { + if options.BankKeeper == nil { + return nil, sdkerrors.Wrap(sdkerrors.ErrLogic, "bank keeper is required for posthandler") + } + + postDecorators := []sdk.AnteDecorator{ + posthandler.NewTipDecorator(options.bankKeeper), + } + + return sdk.ChainAnteDecorators(postDecorators...), nil +} + +func (app *SimApp) setPostHandler() { + postHandler, err := MyPostHandler( + HandlerOptions{ + BankKeeper: app.BankKeeper, + }, + ) + if err != nil { + panic(err) + } + + app.SetPostHandler(postHandler) +} +``` + +Notice that `NewTipDecorator` needs a reference to the BankKeeper, for transferring the tip to the fee payer. + +## CLI Usage + +The Cosmos SDK also provides some CLI tooling for the transaction tips flow, both for the tipper and for the feepayer. + +For the tipper, the CLI `tx` subcommand has two new flags: `--aux` and `--tip`. The `--aux` flag is used to denote that we are creating an `AuxSignerData` instead of a `Tx`, and the `--tip` is used to populate its `Tip` field. + +```bash +$ simd tx gov vote 16 yes --from --aux --tip 50ibcdenom + + +### Prints the AuxSignerData as JSON: +### {"address":"cosmos1q0ayf5vq6fd2xxrwh30upg05hxdnyw2h5249a2","sign_doc":{"body_bytes":"CosBChwvY29zbW9zLmJhbmsudjFiZXRhMS5Nc2dTZW5kEmsKLWNvc21vczFxMGF5ZjV2cTZmZDJ4eHJ3aDMwdXBnMDVoeGRueXcyaDUyNDlhMhItY29zbW9zMXdlNWoyZXI2MHV5OXF3YzBta3ptdGdtdHA5Z3F5NXY2bjhnZGdlGgsKBXN0YWtlEgIxMA==","public_key":{"@type":"/cosmos.crypto.secp256k1.PubKey","key":"AojOF/1luQ5H/nZDSrE1w3CyzGJhJdQuS7hFX5wAA6uJ"},"chain_id":"","account_number":"0","sequence":"1","tip":{"amount":[{"denom":"ibcdenom","amount":"50"}],"tipper":"cosmos1q0ayf5vq6fd2xxrwh30upg05hxdnyw2h5249a2"}},"mode":"SIGN_MODE_DIRECT_AUX","sig":"v/d/bGq9FGdecs6faMG2t//nRirFTiqwFtUB65M6kh0QdUeM6jg3r8oJX1o17xkoDxJ09EyJiSyvo6fbU7vUxg=="} +``` + +It is useful to pipe the JSON output to a file, `> aux_signed_tx.json` + +For the fee payer, the Cosmos SDK added a `tx aux-to-fee` subcommand to include an `AuxSignerData` into a transaction, add fees to it, and broadcast it. + +```bash +$ simd tx aux-to-fee aux_signed_tx.json --from --fees 30atom + +### Prints the broadcasted tx response: +### code: 0 +### codespace: sdk +### data: "" +### events: [] +### gas_used: "0" +### gas_wanted: "0" +### height: "0" +### info: "" +### logs: [] +### timestamp: "" +### tx: null +``` + +Upon completion of the second command, the fee payer's balance will be down the `30atom` fees, and up the `50ibcdenom` tip. + +For both commands, the flag `--sign-mode=amino-json` is still available for hardware wallet signing. + +## Programmatic Usage + +For the tipper, the SDK exposes a new transaction builder, the `AuxTxBuilder`, for generating an `AuxSignerData`. The API of `AuxTxBuilder` is defined [in `client/tx`](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/client/tx/aux_builder.go#L16), and can be used as follows: + +```go +// Note: there's no need to use clientCtx.TxConfig anymore. + +bldr := clienttx.NewAuxTxBuilder() +err := bldr.SetMsgs(msgs...) +bldr.SetAddress("cosmos1...") +bldr.SetMemo(...) +bldr.SetTip(...) +bldr.SetPubKey(...) +err := bldr.SetSignMode(...) // DIRECT_AUX or AMINO, or else error +// ... other setters are also available + +// Get the bytes to sign. +signBz, err := bldr.GetSignBytes() + +// Sign the bz using your favorite method. +sig, err := privKey.sign(signBz) + +// Set the signature +bldr.SetSig(sig) + +// Get the final auxSignerData to be sent to the fee payer +auxSignerData, err:= bldr.GetAuxSignerData() +``` + +For the fee payer, the SDK added a new method on the existing `TxBuilder` to import data from an `AuxSignerData`: + +```go +// get `auxSignerData` from tipper, see code snippet above. + +txBuilder := clientCtx.TxConfig.NewTxBuilder() +err := txBuilder.AddAuxSignerData(auxSignerData) +if err != nil { + return err +} + +// A lot of fields will be populated in txBuilder, such as its Msgs, tip +// memo, etc... + +// The fee payer choses the fee to set on the transaction. +txBuilder.SetFeePayer() +txBuilder.SetFeeAmount(...) +txBuilder.SetGasLimit(...) + +// Usual signing code +err = authclient.SignTx(...) +if err != nil { + return err +} +``` diff --git a/versioned_docs/version-0.47/develop/advanced-concepts/15-upgrade.md b/versioned_docs/version-0.47/develop/advanced-concepts/15-upgrade.md new file mode 100644 index 000000000..b5db25589 --- /dev/null +++ b/versioned_docs/version-0.47/develop/advanced-concepts/15-upgrade.md @@ -0,0 +1,162 @@ +--- +sidebar_position: 1 +--- + +# In-Place Store Migrations + +:::warning +Read and understand all the in-place store migration documentation before you run a migration on a live chain. +::: + +:::note Synopsis +Upgrade your app modules smoothly with custom in-place store migration logic. +::: + +The Cosmos SDK uses two methods to perform upgrades: + +* 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. + +* Perform upgrades in place, which significantly decrease the upgrade time for chains with a larger state. Use the [Module Upgrade Guide](../building-modules/13-upgrade.md) to set up your application modules to take advantage of in-place upgrades. + +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. + +### 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. + +### 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 in the state. + +## 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. + +```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. + +```go +cfg := module.NewConfigurator(...) +app.UpgradeKeeper.SetUpgradeHandler("my-plan", func(ctx sdk.Context, plan upgradetypes.Plan, fromVM module.VersionMap) (module.VersionMap, error) { + + // ... + // additional upgrade logic + // ... + + // returns a VersionMap with the updated module ConsensusVersions + return app.mm.RunMigrations(ctx, fromVM) +}) +``` + +To learn more about configuring migration scripts for your modules, see the [Module Upgrade Guide](../building-modules/13-upgrade.md). + +### Order Of Migrations + +By default, all migrations are run in module name alphabetical ascending order, except `x/auth` which is run last. The reason is state dependencies between x/auth and other modules (you can read more in [issue #10606](https://github.com/cosmos/cosmos-sdk/issues/10606)). + +If you want to change the order of migration, then you should call `app.mm.SetOrderMigrations(module1, module2, ...)` in your app.go file. The function will panic if you forget to include a module in the argument list. + +## 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. + +### Add StoreUpgrades for New Modules + +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() +if err != nil { + panic(err) +} + +if upgradeInfo.Name == "my-plan" && !app.UpgradeKeeper.IsSkipHeight(upgradeInfo.Height) { + storeUpgrades := storetypes.StoreUpgrades{ + // add store upgrades for new modules + // Example: + // Added: []string{"foo", "bar"}, + // ... + } + + // configure store loader that checks if version == upgradeHeight and applies store upgrades + app.SetStoreLoader(upgradetypes.UpgradeStoreLoader(upgradeInfo.Height, &storeUpgrades)) +} +``` + +## 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`: + +```diff +func (app *MyApp) InitChainer(ctx sdk.Context, req abci.RequestInitChain) abci.ResponseInitChain { + ... ++ app.UpgradeKeeper.SetModuleVersionMap(ctx, app.mm.GetVersionMap()) + ... +} +``` + +This information is used by the Cosmos SDK to detect when modules with newer versions are introduced to the app. + +For a new module `foo`, `InitGenesis` is called by `RunMigration` only when `foo` is registered in the module manager but it's not set in the `fromVM`. Therefore, if you want to skip `InitGenesis` when a new module is added to the app, then you should set its module version in `fromVM` to the module consensus version: + +```go +app.UpgradeKeeper.SetUpgradeHandler("my-plan", func(ctx sdk.Context, plan upgradetypes.Plan, fromVM module.VersionMap) (module.VersionMap, error) { + // ... + + // Set foo's version to the latest ConsensusVersion in the VersionMap. + // This will skip running InitGenesis on Foo + fromVM[foo.ModuleName] = foo.AppModule{}.ConsensusVersion() + + return app.mm.RunMigrations(ctx, fromVM) +}) +``` + +### 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. + +You can write your own `InitGenesis` function for an imported module. To do this, manually trigger your custom genesis function in the upgrade handler. + +:::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`. +::: + +```go +import foo "github.com/my/module/foo" + +app.UpgradeKeeper.SetUpgradeHandler("my-plan", func(ctx sdk.Context, plan upgradetypes.Plan, fromVM module.VersionMap) (module.VersionMap, error) { + + // Register the consensus version in the version map + // to avoid the SDK from triggering the default + // InitGenesis function. + fromVM["foo"] = foo.AppModule{}.ConsensusVersion() + + // Run custom InitGenesis for foo + app.mm["foo"].InitGenesis(ctx, app.appCodec, myCustomGenesisState) + + return app.mm.RunMigrations(ctx, cfg, fromVM) +}) +``` + +## Syncing a Full Node to an Upgraded Blockchain + +You can sync a full node to an existing blockchain which has been upgraded using Cosmovisor + +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. + +To learn more about Cosmovisor, see the [Cosmovisor Quick Start](../tooling/01-cosmovisor.md). diff --git a/versioned_docs/version-0.47/develop/advanced-concepts/_category_.json b/versioned_docs/version-0.47/develop/advanced-concepts/_category_.json new file mode 100644 index 000000000..2a5703c28 --- /dev/null +++ b/versioned_docs/version-0.47/develop/advanced-concepts/_category_.json @@ -0,0 +1,5 @@ +{ + "label": "Core Concepts", + "position": 2, + "link": null +} \ No newline at end of file diff --git a/versioned_docs/version-0.47/develop/advanced-concepts/baseapp_state-begin_block.png b/versioned_docs/version-0.47/develop/advanced-concepts/baseapp_state-begin_block.png new file mode 100644 index 0000000000000000000000000000000000000000..745d4a5a971292bb0346c35893b42ebfbcdc206e GIT binary patch literal 20565 zcmd@6WmHw)_s5SOT1t>oKnbP0kwyXOls^@mAbnmtInrrSg=X%fAB3eUDo)C`;4+H`cDk{iofk5bB;P(%Y zuz|Kwc!>%Gq5~<)zR~tI+0VxLLe@?3iQ7OH`t2Lbw>%a+5;={2I?Zq>qb)4UzcMqTUgc(sw|^lU@i-m}r2F)d?D!dQ|5HQrK_9|8 z>_gzDV-qon_vBIbSY!wbf6Q+?*LdJo{Ibf;rcZ_+E`Xc-DzbBm@w#f!@xZ(i=%b!@ zpzty=NpF!JT}xKT)oXYEMs?t-D~8-0I9}I}e^;@EoEnQKnxTeY9Qv}qLGLuc1CRR5 z|4Bht02~cOMc@>}Ml1(B?i-6fM8e2?@FMB`;QzO;OWyEFkIRI3q3c2_QHz98?fDh1 zB#qntVH<M47WREX5ZenxMVdFUDUgRj&DsTh$mM_lddu3jm2Z!9%eH&|<=JDG|I;}qYaCW>J zNo{?U=LY35?_jChyd05IYzxk|?m4yAloVEadc3kS0|Ez}?{R(@7*xg5;6 zGiIBJqtz5b(GXtL>$W$YyPr&mZ=+O7zn*V=C2Z9dL-ew2dH%E7;j~W9K!&Q)tN))c>V zFpv{pYJFHJIA;FKQ^aT2=gp0LZlIE+QI*1Q&aG+*mKR@0jinQ+c&xT;!ft#rkR|)- zZu<9$xN|cOPI=mOPQL0zRK7xr;pdQxI{R3um>`_C#0wpJGVwl31)@hY=t>TgT+IAM z+{qKg;{!vP!q(FVMAkjOaI4quh!~vaaK6Kzcs;*9=I>9ENM%r5%W()R#wC^S+fc;+ zC0K6U!gjKyp1j^0@?~cnHV`>4GyrAv_|^7Zly$UXI6HF?+D-j^pWd5Uo33-JKsj}z zFX`1-z9OmpY;^%97FIVI#F*@fq|5A{kKN_FF2FZ}Z<#44;DvF^NIhqxHk;7sr@bc) zrb%F7=Yg*+V%F{>=QhbgXBY51=Qw63e!|OJK>*;)hBg-L{yGQb9@0=G~83pG( zlWz{%Oj|`Ri%-knYhI6-a&kZA;J~2L6Xu?__1O4){}nL z5mq}d2`Ju~H7dMW-HN9^K0hHET;mRg-MlY!FD)wS)%>~D?Xhv`BVV9+XukEGPITaN zVgX;FCI60~WigtYnbqJ}Lp5YgA-!=wFF%;Y_)BJ$#~I(x5~FhG_X#6+`!f&ua(~64 zw_#uSu0CKu&sXJ#8uaJqU;#scEAe=<^aj=2oA7qV?M)dimCT*S9jaFR=%ift)rp(eBB$fS?shskDT84gbnHK znp74|3wym)!d2s>)g6xD229JT@49||^_C+FQtta$7}y9Zfk5z7#p0{}|`5 zFDxl~LQXTxJL6JZZTHtTaa0l-2&ZKRK}Uf^8`XKmj1ZNIOyEl}e|4>pBYwrGesBwY z?M70paqpBa=2FrOZmKeB4OHCXPU9MpdiZv_H)&FtF_hM-o#S_HFk9`F%@GjN`YR0~ z;7NSGzsxA}>6|aG_v|ug?n}4(!2+d6b{TkjFqXTOwaBS8p4!>Y=2} z!9x3vOYjyWq^~3y!g;xsGr1@ZM#f5$ha%;+wzPJ66E2N!*3sI)L-QPvyq#81xkiizguFHSXS#0__Gj*($6O|vhXrtAl zs&~?{JHO&|wRz*RQHIT#@7-%MhJd`;5p`=7Pv#8xBQcn|QH|Saz0lKQWAU&%o?va1 z3UmLvU{Jg$sXs7f&sOie^eBQ8{-|lX0@{&MLK&+ad;fjtDXTTA`l`oWqt=};^=zTl z@BLQ%9pP|h z8n5k6DK8$Av|Gq7p9>Si6-G;5u8w~7OaJ*yl>wU&0kqmH16g+XyH{+pJ~ucq)>eIx zNdB?n(U%B553@?EK|N^`_V=UPsezz&*m6z+_xWC8zr=ih0LptXJPCuLliwf?L8dp- zhuSRZyL2wY)acJ(&ppklGvdk>WB2%UCNzRiyj*+usQ-3tkgwcPBW)eZp!iamIgV$F z9By~kbSAu_LOEI(rtPpGdirXmNhY`dhj;uhi7w={-Mp%6NLjjsVoor9Q}c9jLltI9 z`J{%fDy{87r>;zoa=(L@5n^6)-usBNZvr)EiU$j3Kg}^a4zBRP_iHi$TPlh+`=qKo za(0^g>)$Xi_M_L#GU)rBVg1{82q&xiMfkFUUyTjMY>j!!^E=N9zaCf|HCshW8N-_o zy-G1(idCBs6-FGEO|=4T^^`(C#i=O}KZ?d@436JjHQlrZ-^~W^=YNe)~G#?5A7Ymsf%!l^+j}<<}ReQ~f_rFJe{Nh(%H5fd)9R1U2 zqao`mU;C`F&^h$5{WB+tfE|2fz?)CHub~7kEHR9 zinelv0=Dja-Jwrf@R>|Lr#bzr^@LbaSwGjA!eC=gTm*#(+_Tk<_%P0&QYg_VumD4DrTQw2sXB9 zSLmwmHqSGV_4FiUzdGC1gJv}xD}M0jj0%PM#+@XKZ%ng+c5*v6L`M7T_0>x-OFcD1cs?LsQHB%jAw}7nL7)W7f zGLJ3HqIhy+?>B^I{C&(b%WH8u-rFtc@3$`Nqv_4TtpXvtQPGodCj-7*?H|iVfXz){ zpJ|<2&#!;^n@TPr4Pk1}oH?{qNTx(nx>qe8?q(9k>gF=}>`_HqjB^c2ZaYGLVd5F| z-w7Ob^pv#AUXfE{MdZX@<#@*t%yI>x^k5z2B~(w->z<*hb?G2Wagb;rFu^lUtffHZ zw>D~tDesp_+gas*zU^_hY5Nj#w}V4D{xni;hn4>p+d`iBb-kR3~5wd*A=# zTs7aK69yH$U^oBlF-_E(WgpOL;XqPmRo@c;alpzm3DlVIT(9|m(icr=JQNqXqyNQ3gv8* zpq(1PQ+ei_aTWXne`b*%N@xC-aOE4h=LfHH@R@>gz5>CK+Si}UmImmqIE=y! z2cP%>8_9eIaap(wWLc%?r4kDsm%KU|!%7`NjJJfWg)A$&4!LhFd2VY-UGys2YpnR~ z2zVEc+U)Q3yWgMEj{R++tPVk8Q;vN@5EvoVc)HAuDVu#;j9v%yEChIop1~F(l%7?h zgQ~iYM{9idG)~am?*W(oVZiC3HYYzuEnPw}Vc-onv4Ou2>;uUo1+T!Uuj@krX0n-| z`22^|PQ-#LA6i^a3^Bmjy~8jskD_OK7H3n&o0%gQ)b%!-g-!$;1a{g(AIX|^5!K>J zjHTk&vhPkHCZax5p>T=A%X-uF^U<~mB1tQb>+a=p&PhWr7;BJde-D<=&x5mLosClU zbL5`hR;oMI;PVUZPqsON)8>$XR`44p$P#z|d-0W>TFO;7%{nG*0tlMSh{VlXJB|Hm zQ(72vP9Mw3c6ky;?!I8TB!_A=DKkt;Ef=cgvX$)R=-rRR?abHiKi2x@Yw+sV^%=YM z);Gzz|n0`+8Bo za(B{+%gNA3kmr+isYj9ISfLY!L5oAtg3of$mLvTS9b;DG#+SJk)j_>B7@ra!gqNT5 zo>8zGX;BII%g0c#GU7 z;r^{16sGz>m`jqZfej{)NOHH)K4?N2RBc+1qms<3SJ*$Ns(%RQ?yG$fsS6F)hX@DQ-s&y7u?Go(Vu4jeKR=w^k)%wb!`#^^n)%caNtXg{Y>V z$H}b6y`RC2R(Ff2@W4nf1-$8}lS;tc<6Nt}tCa&MC@Ox<-E5vIb>z{}QlknQWt~H2 z^x04U%*}$Vtz|o@ANHyq4;VP-NPJs$YK@F4R8&>9;e~pNjnh!ec#FTi<%@2I2(Ps5 z@gC>9%gI!1q$#WBJ5gOWHhxJ_2q;?dy!~_8)_wJbVbhaj)i`LWZ6<1NEl_RoCk1cD za?n*n70Gg=n+zh7BW1r7))$K9Xr&U#gf49uO9+$PrN8Z72zcl+vv~1M3Ir}1=#I-I z^O3afzchD08<867C9f28{b_jewdW=xg7Zy*2{6rieLxT=gorGY|8hC~d369nVE;0; zggdsAma7P$6FU*iZqo*_WKs!18bAYNVz*Ey*#nhSxL@S+?CavG z+>Fb935!9Yfp5+ag?I#mcA>wy)q`>FVO+CT7WJ1cTHU+VUMNvYe*brNx09h^i*eL{ ze}5feFl`M#_D(T0&#*(SCWKn57}Wi;k}&(k0iKld4<~uq3O>Ai1iok_TIB?vV*9*= zl{o@m16TCUT@#hw3oJdkN!@H;F1UdlvqbIB)hkvNz!yi!T~0DS6M0dYwCAFrb=@xzYt-iM-e;ScF7Bo zWfq$SsJDATJZWP+%(i+HFiW}QLW=iVRjj>ux{*Xs1I`a?_JI)`Vp5~hECOSMB3IUZ zr~Xqn+!u2-ohl^@>*YC5q(j{h`1Dx^0#rXG9zz&g4qJb(b7f08nz0A|e9`7Q0kVwP z6LrhEqWrxbOxX4)oOi>rH=N+$)e5LI>BQufWWP?+xcI5-pUvnt$b&9@YL&qa0-oB- zC&8H@m13Z)5}@w;*{NTzIj-t6qT=Ws%X85i+006kIXc%I&Vz0fewgC4k5YtzMyH=X z$^n57TcNVH9*E5C&-&W3xj7v>@QO0$3-024-_a&G-*VFeUG`HXCtOzM!|tcxAF~0$ z({r0&LpMKiTJ*cVB4G=g-c2CwjaQ!jC<<9%*Y5?@jMY)4B|OJ(s~x|({Y5!9DE^_D z*@%;@`mUq;ljE4ZM6K()kSrQB^;`+PUfzT%9-LTzS(s9Qb9)B`A*M}^|1PEC#qZAQ z!0xx{qSi^cIc;7jSm4RN9`vpti)5lPrxtIQL&S90@w(Q$lg)s#dP53U_M?3&o?1BH ze`sv1{^F5{->xtQIGzf#KT7j%H&HDoKmI8<`1(z& zsDB@l?1SNSib##FQW4kC=H_$1f}p05yQx+JPwf$%nPUZBTa}n>*|*ES_ffNJKN-yU z4URXMq=OuC)!vHZ@jlL^7)iQ6d8-1M+y~ch^nN#0nlh^B+gT1y`nzaI?ejgN?1&eP z#Pwa}Gk6l1Dd;1~3hV=z$Nb_kCoxx1Q>5wzo#Xpm`7OZNZLVT#;&VV4NQk5{2r_k$yw z4OxCb_H~WT6>7(<@cOVWa!l&rc-Fg|xHd8Ltkz|in`xg3}q~LPHp{KmBb-HSB4hkW(ehgoTW9+fDCUm$1yLcOrD`njK07Z zrP#F>YvqA?ajYeXCutr7!8n3lCl$tc{4qF9#GF*shVa0CNnXeXe~_ZGTmI=t)npX! zdiJ>gpN~9Y8zHyXHMOia8CQ8%kX{N8lk~axe8)+xF*@J8s+aGB?++YzrjN2U24NAL z)HhotrpP$l5YWpqYxY~Qj_&AmGiKq{$Mp@A?z{o2mwKQgXts+6XPNk04 zJJHN`PY!T=hIaBSzh0lmNDCcmsv>dJ61)GC7wzDJ-+Mr(e8K0u2N4N4sBOMei~gNf zmQgqOsqqOAj}9b_zI>NgP5y{WGVr3|6}ui6Oov`sMSN--M~b)fN!6DWwrusDR^h>k zkd<~5`-R#@h*6s!kkAZCFW>r=ZdRRA=6lU!L&c`qwaSgildsLU;x0DlUD}{jbprz( zSg4I|h{!GPlxB&H`QWPteJ8JFsnRD8cktV7Z9pO@&5erqBjuCApq8P%75~Rp*W$07 zQ|o!Ev%p_4lF)`|hjCo$T1)NWI@TaZ5^|->Z*JyQJeD8doVcyi5PVnie5SR#nFWV? z*33jJ4TZb3c}Yf;&sW-7Zq#T;SE8DZ{!j(s4I{2xC~{_8pR0A|QQt*FxDFjbH{?_k z`Bu6Hzu>ZkL|5A!qh}qbayYh=TxiZkj%T*jkiea0r}NE^=t#xZ#UH2Umj)B3M#N%V zsC~sdlzjxoC1r9iWv|>Uc|lH9%VT;wYZ}yvsjzO?O%-;wf3kH3e9ZSwM$3gpMOvFrZ+UiRg z)M%-X(sdD^qHDbSvFj&h)hJM<^`V~`YM%S?GrN0VO9i`tOJd9)_RJaqS8IL-yneNA z-N$aofV+X;C%P&xUYYLAaY+<%!t(o}{q0PG1Ps+b&`^Ab@5~;*Gpnm94dxxL&6Xqc zKBK421U=&!M*jxvF9u3oba~cSIod^HaYM~J#In}06KQU)qrSjRrrX(^=So9N{`z9s zNw>pF#li5oS7teR-U9}vIf5hKrV!sLs_oKJ#Dr zlQf>MUo~d4VzB?(|CjU$`14)^;TPk^Kwg!cGR0*1{w+>N>#ORr4!ra~993wDxmx>I z1~oSE{h%wYm(|^i$V&{wrNg04(KlSKBH}2~y*tjWhio^FE&&2V zqJ{;sJH#^^B=!k=`S)jE-HRq2O_@~E2PV5{{|D+pE{CTE!Xg91+cT z<#SB(M0@xWpDXnB?#vkJO^2m|g1VYN8XF)WQueuG#zcqn`-m4RGb%iYcy-B49lSQ3 zA^leilk&s#bDO`WKh|NcoXCI9{kKsTr(MWBd3P#UI>@raZ^OrKSmlhyVC^96c@;-o z6A^)RL5g;OYy~~VoBBTD9ZbhME^fymy-~ULnuEFR_9#9K5BvzitySE3rC!9Ca`F0N zb&p=+A;`IqGl@Nw>!Y7;R_SkeLCg#j2e>@PDF@6HLIEcJZlw$6%A}>L>FIvdx-Ek> z$fH|AQ#U|aPgh_w@61H}+>GH*kS_|`-R#EZg!;Fv#%)eKz4Jgf|d zR+V-x2l&E-{^|;OhKv6Gx}HXPtY2u0iJv5qupLXpm02-TE*?au!SVFd6k# z{SCvz<;e(pcx(ca3w@InhbWlsqDbKhlTEDU?&O&`?dPKDZDiZSJ($b1fq^LBcSY*w zL09@;x`H@592M>I%@IpW42ay+vYmnhl{x7x8rTSw%5Pd_^D>0TI8Dc)ISmLITWCFCQ_&7Pe+bEBRd z&Q|Pb;#wrk6El7V={-XoZ*Rsz`Ml;HtU7)4a!;-i@gC)5?TrI8`JRVHS@wdnAN>Lr=;H=&Q5V# zj~u9G%#3f+9BlhnOAQvj#76|WL{EjHr~OsGJt~_(4O~aGvzHde^T%6UHAyKMec%kS zTXTGYteXGAY6q8b5q3HB@PBMN|9$&L9xaYWzg|hV!dB8qF~a=mYqR)U*Q>XzI^To8 zkfw}_b};pAdb>^wt?$;cI=^)EgGX|TUT&u5W~-X)F}DMiZ(`q>F{F z1k{v6sXhlxKLbkQbwFNiEK~L~0H`iEPpge+V_6si|DQ$^X4lvXl*Hcx<0=0-wbBCI zzvNhCTY}D820TM0L0Z7r6ex**1#08d8jeQ*5y5#_H_opUmZmFh&R!@_mr-5;l*E7k zGsO=NJPO@FJk}j0G1x~$GyD$by;H#?R<~F9wj-voDa7d2iY1C|A z`T&&vrOGeXeo-&KV9DBOXcjw^TQn^4!8^KTgZLF0!$p+M*{29ngtY%-GeTHg;Q zNOlt*_wg-2`JycS1nWicXL=MKoYQn zA{BrJr#n|wYv#Bp!!Y$fKIA_V1oSwmLl^WoMk+JEa#LNfj_W_T1pOa60($=PUqcom zq-Z{v>)>Gg9}t4s4A>a$wd}u!65O13V&Miu7Y6Te6OLu+*Cj{bWoUL}n(t;1Hd zneu?CeA8eF!^?hxS?{G9d`z?M!ME4FrM!>Z>3=i*Z-~ag5am+GG?8k7wZ4DipG8p1 z{%?My$)j}e{ycvg+F9^#Am3E~8}~nmM_fBEKZ@gNlF&;&Jy{OOBxzFBOD$Ddgs*-o zjduc>#!RDpheO@}fjA}70<5k&vd%Gm%P*m7vcpk*K`)`&vQWAA)Tew;Sn?_h>LdS~ zSm1i%Ch|W_FYoTd*yocSA8wr#_6`ge>{>c>7oN%QNBr+9>04b;Da8~AGeqP;EVz`k zvqf(vW)X}wp*b$1BPL47J=TwM+1Vjj zzs>C4|K|t)gOe(!INjMD;4q@M*EiaLE3lWG{b#2RsN+059aM`F&{ogl{B6* zC3oQC2)gn9b_fKlGTYoBZ`F>ExGsw~?7QSZbuviuO*m$+^HQ^)>-pYn8}hxZx$+_T z|8Y=lti)tw6JXgnMnx#Y=z4-wFsdNcMCs;Y*|)wHz@XH_Hu{qXlU~UWKb+6IL_04a z-Le;KNSW21KWi-l;2xK~I{E(wEZc+*l=(*z85E&JC)*>r<(@lZM7+56npkVe=z-dh z1?1mf_jfny#trTTU0EW4EPl@p=`Ip`b5ruqTiYcx^5hd})Q#JM@5Y%_GsM&AWj@JX ztdJNMun{|wy$-&;97^Z6%~8yH?RIb8`RPuj6TpOqj_hT0{vlnDRIoAx9le8QD$Rj$ zD3YWRPUse+kHXvQ9H$vxzrNi4!umcgTF;z414o+sKUz%MNGs0^HO0Qcd|99 zjp1f*R>v*LUK#Rm&rVNIPu&|&t*2@}Xe&~O{-3qhiqPY!1ldxhLhkbwgTuJ-^nFCxjKt?T|Nr{7 zPzlp5Gc?{C{Voq^iCW$I)TbRK(sb;uJ7bKLuU%KHBg&*{7@aczw@|^Q0gpM1qvU4_ z1^-Zek7Z#JcD_H4a_CB<#ddm=$DUZ&sd7#^{td4y4gKjmVZ6Qo4RiJ$XWSN74lQ8$ zqacI{32u=ojJr)`EBWOnG+_TpS+7H<$7xN%|4xOS|MaanyUB8fxoF7!tzU!3_U9EX zwXD}wcJ+P%bd zdm?BzU2d$^=xGm-QSuwf>XJ#3w81l|a}SHV>$7<5C25RGLFa|nv$gi`KUSs)yO^X4 zyX1(U{+8*W2_BI;q;(7`Qp=7zXm^SsV+AzjJFV70zput}u@vN?QOn00{iI*t<-2ISAX=71M8^|;yX#Cv+HG$c0jq@}+=NIaPz1M_es2HNA zD~KY(0i*Z#(uP2o27i9QQBGmgu>zJGsHm3%hE*&DC!a29o(=FAY}bybX6&Y|fn#}Z zKK#!0zc_FLnf=at<9>B)O(_|OjH8h-)GAbAJ#4winfRgE`Mk-p_p!$kZOARXn&Y#? z*PeegC=g;GeN_W3dylhQXc$T5d{yn_KnV z(E?!Ed6xjJXdgQ`U<`U0=Cjq65jv0CgKq!!s#1?;dM`Hnjn_VvFbTf0PCcu{Qq7eN z0`{sFh06elmO51irbd}0y_9=9-@lw2c&vDJe{-n%K-mT?5CiYkB{tnT{uG@cpPB}a zey_?E@hGg~vgwC*@9T?pf4_?ZR+_t^79QK-=ili=iVnMDp9)+4bD%*eqjLV+2t0Ji zC@n?!DQa5X=2x0|9!bkH_I62tfqT*_4&(_ZizQ`vJpa-Li1eC)#~L1FR&fv)jI;wi zW~u^upsMT`82=`R&;Jw6Y%rBuxV*<Rn9V<4j9=?S4r&lDa#6j{#D-rxt?nz<5J@8w)Cbf#{5AW3g8vZuUpzX$777 zvqWlcPsi1J{5$g@Wi$vWz>r^nHBVuGu5NQkcv*n-wNuBUJXD#pLc>|s=dn*Bt_Xw?^V zix)eqzVo_p(3**{<#yUH_W@E9zoN{XO?fCM;1LPu|}PKHFJiP}?M$v?i@Ev+Cxnib#t`JNCbhsRF35Z)^7DTp#tkQr;BpkxvF1rP>U-=scj5 zym|BH7?`6>B=g*dlqY=w>+!-y4(bxpxKs4_EupV|Kl-z(RnUAqz>fVkjCc+ol2_bR z1v1%l0~8iPuK>Pt5Z~Y6ov{Lb(Fj`Qo)HQTf9{r3XqaQ>$JDCZqfVlsJDJ?DH=yhr zI=ynEYTv&W7;)_s8raR|UUE36b1eb&(H~+tY}CyMr4HYgb@O8#_QslyZ`LyL7GCB1N|!7S?@p{AKcD>Px%Lj%Y_b4*uzThe*q+f%{5XV z$7Mjuln~g0MHOv#`D3l|LC~1J*KG4RUW3e$tCcX2T(em4?O%C}7poXe#y=^zUcwdh z9YRxqRDhEGY1Mm`&t0yXBS4N6*B#qf?yFPAvXWXM;B* ztu6yxPdcuSV^$v-CD6G`u~dx(Nm^_+`x%byZ7_K?Ynz*XzcrG(TyQ?@4|;wbX-$-f z_1NjFDiUp!7P)39P3Gh+NTD`kVYFZ@bvpx|>CoDA;K-(nMUkPlS34tRFm}tV9RZ5- zU1XnGYy?&@R>`q~ZKmFM_KB_dSpD=Nz!K0{3pLiiI0{2n7oV>VRhJbyXpzTPG1U9nr6PhqG z9YngI51Io)7$F1bJ&^Amqbk}m^4!6fhub*;!|jwX4!9xa5{9aNeAL~VFO!`aHai{# z-CDLQCyB6C*;`O-ydZ`ZsOgAQ^g!Dvp?wAjMXIz&ij`e8{_9md1d_|ypgn3vXdyb3 z)2nf8$$%&nla7Q#y_pOYRT#=;DfP<^BxOeex~BuLH~s=(Q8NqcBn9UqSt0e zOon4%6Y$tSezXGUu}xQ$&lGdS8`8DiaM9fL3m|BsZKXfMD~BWN)lz3hLRB1m_! zVOczVA*35>zh9T0_f1;iJF_skEx-`O0a)U5Z$qjuMJ&TZ6^84|Rmvj)Z(Ov;CYu!p z|Jj*%UQea_!pPFQn^BkUzYmN3DD-Xk>Hh0cZw_Dh<#!kF0{RS${PG_3JO*7NVXj`Z zgq%2u&`;$^{4iQQ%bjL!IQx@qmfDDiC*R3w5O5PvZ3}Z*3TY|(ewQFhQFG>4mQkX| z^q*d&tXS5|j#X}a2L@2@fjyRJ3(Zd`Bs$oHFe3`>kuJ4G%Q1pjzFXEF)n08yADQ;b z3`_3?1qm1swVkyXR=7OxCB6yquv$jE3Xbzm9_t7v(R~I7k4WCY`#r4JvpS~bOYpSR zU5BEsRqjrI;yNO@LhRldYZgaZhVh>IuY}=rc;W|9$|%WNu8MP&OmF-8Snfaw*k8Me zRHKhAK9d#b(Ps|xTOo73$Oq!fHz>_IH`YA{SX@8Q>o}slk9r?fKY%j!vE zc}wNcTbJH@=JlpJ*qhiXzwDiv;-B17f$aYWu_INteD3CSaLYAyTOW>3c#i961$FTB z;7r2hrpb@VV-Qd27EDGO{Q;?5Rh-(O~92-=3n)v8Mx z|DnlxzHE-7QScur=@MP%5)*TlfwL?zaJASHPQ`rB53L(Be^XPcBvA|;v>;76eHOw> zjEy+TC6)R4^!d+{F4d!#76k;R!NVkkm0p^%mwOg9%U@T;o`cO$T@S6v{VigB?O2Yl zjAQot^X>s`AJD*rj{}`A3Xe-e?pU)+$Wj}#Zxptkn!>>K&I460tO<(AH-WegAUe5H0rQ(7L-h<{G;oQB4U(d z(JVJcnGbC8?*Bh&Tn7%_?fciPC-SGME#N7oA;jY5Lh*9`UXyBEsnf-^&arMM?09o2 zVdJu1esk;0kX?I68fuYK;~u_a@nR>ws=%2`Cxl}}CZtIeSdLaU2L@~@R%_ouAs zQ}s1uAw`G{&g;VYdw9Bp0Zo6RCW0%I*$*!@@i`X0GQh;~dChPCn4icxwg)se*!f+OaZNpX>!`J6ulJ?oBlf;vyJx=06z^cn{fqHG6aeZM7rAC*sHDI z3UpGWigCW&xo2? z0MOG`0ClL<;-%OBK0m+eaSB{l9ypI-yYSIP(2iBzdWfmsW$_EQ_hBM{HV**DAsFRK zCcajt@C|(!tL+;cbLjKMkdEykfF3>$Vj>mVPgbvYg3)t247Nw0K1u`yOt5i(cv_Ll z-}b;ZJtJEWVO+-!tkd?xu#Fz=xbU9wAf~j*A)8 zpt7!i1v#Pb{YQ+Lz_4E_0y{KGhWj5>ryn0K0$>hUc{=*UN?&79gPmx*mh&RR?Pf8T zFNFZVgxPW`nBm_klWxn%k3BB?v&1jwWnfB0Rs03-H!ZMZXhu%sim6fL6!|}6rv^z4 za_}R{ESG6gWCFa?E;;d>2e!IT`a-Wtt!KNQ93MN%#p`^oeq~iGo+uiR#>t_*{qUNx zVTpz5tnr+`9doZ?cjQv_ChiP1%FK_uA~#!W2U}=%lNp$9$~=YMRGN1BBnpH#ZHx*R_FRMsCCt|zvRV4{Izd~pqFV_qxEHi67C-tgC8#>r|n|p#PpNJo~|#9BE>BZ zzVzo-qP0WU(*Ztxt%sJ1cFb{Rjlwx@CZ==IgCj%B0q&C zieW*V^k2*P59u>G4N`n5C*2<8pFO~C$Ka1$rhX|E95mDZtj&i?Oj&m%i$w&FjBko3 z#>w>L{<~G+G~JGn{e4LIp9_eQ6NdvChdq+Zo|#v_{F)!&hWTvmxc!*Gk6FP*(e{G? z{>BJi(i;ky=ldGq*nfJf{1rseM^pmH_1`TohHGZ0B#NW8u{VO&IunR-%sy4(WO^+m zi+0eiLvYwB3^o<~FXsx@k}^0R1Zp9?ElInAH#_`Dn`EQrx@h*_ za_Sy%fHlK7Jv&L>?P(tx94a@3a9HDbLy`dLN3kwX?VX{cA4=G#K!w1W-K*(Tkmuc% z#f7&bRG>IZ;;bp~sObb}(eZ^P)^-DXpQI4bEE(Uq_Jo3Q#4$+HqfK6jIJ zwfYXf?Rbw!p}!G1;)TrcB;$c%pG3=5AxOvj3j0(}^}W;f`h(=q)k&}_fJ|3UhRm$MpyKc z?g@lCLGzM{^xQMd3toK?v!_fuQruGP@%L$**^f|glGf65kAE`vW=w1Q-CB`)u8=*) zB{kh3LZ+QIVxyv+t`SNd?>Huj5AO2h`&^srE&BDdRpsjZ;4{~RB$v2asz1>Mu`?zD zSoeEu-sg53b7aHxqnz7KjZ#^e0n4ZxJ#&-^JN!)SU$hjTfQxS6$LtLTrvH`F-K{MC zQ6q~1siI246obDbh=9*L0(U{o>CqJsWkwu>%n5v49sBH02TOL=t!9qPple~;d<}X5 z4emSNaAjTekFZDw<#?_D>U+pdvkJ2M4!%@UgZ7+`D%B#_KV@_AbBl^fnsNLiBSMJb z`*-k5>6~BCN&QA4jx^_moKjoWFGNeGbgy)S?W8LWMzfeAx@Q5rX%l}t9xG-UcevNT zF5pfn^=?PfFAQ)G(jEu7>qi#T;n)fM+~>e4$aL~AWuM}bf#Y0{FN?G}!9I~uT?G(6 z!WFX}Gc9Y!=Nw`TFR@xf(V4u=!U*%yAy+Q29Wi4KhW%fF6jC`&GhdM?m(?wb?5h+< zd&9uDnJxPQghPxGn)DE}oW6nf3L1_c&M;+lYzwt*qIHZge`RSa2Erprf@-9Y&jM~H z7=%XbX4+ViOPKA1wg(cB)V&JP+D>#1KT+&bbk{^Ye<>zvu;kZU{Y2QWHB{+(MeXU* z;OPe;G=32KK4UBFzFIzSu^uY>qn)H(PB*}lE$lmqZ3E=nQ_Zu_ndp{PPuPKz;wv~M$Am92Ak4@t#T<2cO4?%T7 zWuYs!)adt0V1&Y1OjnWXxx{ZHd|{i1D|#p^D%Kr1!U~)<`yYG&-ehvhS1VeowzX9F zhQ?oTPZMa31Mf&LQF+*%OjPVyRJM$V8k=4tqM1lVsEF-ap}l!+0iR{!@~e zRwtsY>3cXM)(CC@e&%_R>h#k17R_ zkhg8FQ3s=$nH;#F+p7 zE`Tfd^`8+@a>PMNzZDVYlLb}tvEJ+OOgv#&4Nt?`fF(8E{ZmPs*pCDH1Fp8S=)Wsd zh%>dosZZJOvq*z{?beOp79fx=n-4YVyu_^?4iG?wO3DHrJCaqBw`#OuJ-W%Pkz|I< z-Vt3TZnpN;;Sy-MN~}rd6AhnaPvg_}skw>2iMdnqGn%)O@1Eu-!}b3eci$r~tu_M215>eJm!Bfj*o;i|GiM%Sv*RXiJZ7upGRN)Q4MWAWI{|8gd_y>AxlE!s zjDy3Zi+VQbI26YsT0DXiU*20v0UwN{?HBx061>)w)lE9{@*aQs`QOS@d!QhN{i$*Z zO{ScV%=agGZ)?&iQ5k2u!3?@dqxU|QLplc3b>5<(gRSqGKKm6P$;8O z{i?8=_q0h*3>LnAUnK;1`dn;X{N1xET`eR9ez_}7Q^MWFsZ&IE`YS^2L{#}hVl z`>vVX?1LjTnkuoA4_$i(H(P=L4dedv4Poq)u=R;vud3^n&t01U)@Pm$e0(ou1ND7p zI#M3ZAWI&A<0ec52*6C&fV>(v|9QnV6h9G@1x?wa*l5SX65(2WEQWSj+uQRmat&1* zTq*E~PDx9XDOgpF1E*dHw4ZFB0reQF?5O<`gPKB0VT&KGb;rUB(Zd=fKKoeJuO(m3 zbbRZh5aqyInF9$Qs9zHtH8e?eR3Mx64lyIj0t(<$C?&K*1=MoJf!8ih{dbCKphh;` z4&W51gG-)Oa4FUUA>HbdMaSMu)%SD=t3I#(o6FxaM3kjZ%lVlc?w#@9Y=u&@Z?Ry4 zE$t~q-1EbjG96=5Jdj*y6zC&pc)EXP!zVElD-SrN(M$C%*C04Nktx4AC}7kpM0uUZ z8zuKgXJ{_S12~uj+1`kG`xT>HfJ3E=*TDG4hZT>7zyr^!O6v-FQxFWO&}K}gA+n`O z>8$acdR1}BYSKW{<(h+HaZbui>h)UZITVgQOs zDSQWGRsq?u7P{`%v_cT6jkA_n)RMnZX5WV<*1_A=1c^o$cfxtYD-UW@M;u;KjvS5#7$AaFw)6}DB2;y6();e_MVpV0z{j@R* zcI2|RK2d&6E=2@=YEqt17@;AJB1>~(JQHQIjvG{Nm~QBVtEZn&(o^=8R)LSWTrVvS z3k}1%FUKzh$CP&qz58en6*PZ;Ss`4(+ZGN2Xzl`0_^jT%3O)^$M__h(Y#FS!Y8+iU z+wCzBgnlr;Pc*g=;T!X0_zLgf3p|`1(TrCik^?2S}a)k3ErJItJv!r8| zz`5bYUTfyuvT%|p1X2P8BY8F9XX<9msg#qh_EPB;Ppl2av^x%{eSIEU`mnfbYs_P( zYi01;zvMrziz@_najCBBX|IE}9I6KH!!yjKprCvdeBXihbsvGSDm z7uIezdm10ZlgNKXurYYWZ$kn9_DRf^=5pP#ha`pq4`Dkc6d9+-$Ktp!$`}_+d|c(^ z{-XFJrN5Xja8`FgzV5(Z{y2yd=}wNJDr5D~`nbJL+s9!!|H8k9d_OCfQ)}=I-kNmJ z%ZaxuX7yziMJ_5=9Jehx{isjgEInb48(mBeo9FMrFn*+#-x=k}5_6k1y7tM5xguwW zWBM0g!dO7JKnU+EgX^|fnpaoNV=i#+)w)t zmZbGayeWEx*LBK28FLuyj$<*_^$*m4)t}j8p)(r9Aq5*WqnnF^#K9sxA$@&+s$4uu zWXasdf>?n}3lP#`EAirpw}9Gt(gJ!LPJC=Av3{Oa03=2%pGa73!y zwIiX(dC8Yki$HYIhRrL{ADmSi>psqCx-+Uu=~acTcZHH@HzAo#$p4!<8jHb3)DHcd z?h#!PrqbpLq9QO8`oTO`CUMC@%bx6TobKutKU&*ykJ%mTSNA4gRl$T3Llfxb7^xmV zFUV|T-(KsIyu;AR(1)_On?tdfk?u=;Vr(k)-ym#x@I;|um7CTe>L+AXB5YPZynNjd zn_hKms?THg&Ur_NC){1S$DMfL|ip*0Q~SKZ?DjR32n0Gy<^TmZr@tF zDPt{wt%?=|bHF}S35*n@!R^e<;-I)remxP*>Q0&Y(!YZ+<;uC_q=&N7=tr!mOB=>d z2QTwVV+LwF9 zm16(ufJ;?wwBUM5E!mc#yj%~ous)b83f4JdpM(^Mc^TyqOPz1mCx^BS@2kw?Zq3|N zwD$XxB!OurWm&>xzKpRZ>I4L!$YtcI{y%KhV8~PVF_99rR4T5Y#K1^bR6~;?3IZY* z^lHzz->M^@Cs-E9yS&m<_Z}=cESk!kfj_RW7>l;&8NHfZM_V*qx1C~rE1=FjvkN2b znk_m}2s{LtOOJ%&-Pkhl(pH>5M35?2{q|RwJlB&QxV@V$dRP5smq>@R1*UE*QKowc z{cZumfU_I{XJW%5tv2niPhaNd=5~-;pr;#=_796<6YKX^H08m`XtOtO znhPf?{l%b|@`d8hWZek;4WuUcgWGkDIp`@~y!0cGhYj80&4+SNoW>|a1hAg<4+G$p z7O4ls*&g#t=z2xdRuK3L59P9y)t~KGGY+Tn*+%Nk#A^6WY)Wd%IEeYcp=I;J!*bD! z!YYpL8nn(NvsA5SLB)d!gC6 z5gUxd&m>7y_&}q#BDVlOm!&yiLP9WGTBDjGemxF)>)hF9Pm5B*J_3gl>)lzh6?j7= z!KdDlF{o1+7O6sycL}A7p^;?O@|ffp2&RX`jO*YIRw0@aBZIqBrA?ea6YAwASt*6- zivdpl39Sz_OIh0g5j+#9|K&uZjQaV^y}qD*DB+QAg~RHvI6>Ldx`G`Pf%e7@l$L8= znPo4_B(M_?Jz)zXxP7XMWj^fl>PP&?s(aec*=9b?Mrw`+`7l}+Iy?J>T-r8Lnr-=q zC8l0CB=AMD$yIC$SQ{xL;AnpICZ=T`FWd!&T;x1^s!NotjYJ&!Y|&lTeu7i~@AHv) zw4f9Igictmz;-d@F64kspTY;q*cppGu4VK5Q+u#apj2ZX35vUe2-}d*3{{5QMd7MJ znnZu{m8O&fDx!e6eOB$K<=^Fqa|I^6u$5{_bf&of%=!fDjb7)=$m4xkPpETA-eJkR z(>>CfikoYzJk`f%`PT`T+BIX$r|g1mJbGK51rrdOh{KFi69$lZi5OYhSCz`~$fmSV z3CsIc+gKPGL4*~NVis*%7pL*(jle7E)tvpd7bk1fe`{Csjy^S@+`KmQrTf^|LW!AX zh~-2^nMdGA@E7$jvd7>K6~7rIx9Q_oi;3rcP3vCzw{*hp`nd+S50162iFgeMJoqK- z^fkExq!a#1Q?0ro;F?^iQ3D>kJ#M0iy3E;-3FPge zn_K6h*diDQ-wUDCU%p#)WXE0XR!VasS|A&JJb zCi8c&VI*qmJ{v$0Z2&I~RT#zZ<9u0aXl)0d0r6lhzM%?8vdcTgWqJPQ>W$LA=4EJUVW_{IppNZ!w>h%8gvamqh=%Yz;$wI|Elm!3P61+XAZ zn;%fh(nwnukUoDN0q>Rs0H$gXwd+Oyyez1XGmio+$65TSyV+6CVL~oy@Sc4Xh634o z8MZ#ZHUf;A-2m8r!RY6W-Pk37j!{3qFM>@y{p}wB4Tej(b>2NPDfY4nB~ZXc&ECNz zYT4S?J~aU3L;{fI?esw6?m{3~$ZM>cwL+b8bUx@+x8K-m?` zhu0zPrBqRL2ctXulKRA%_ISBE;M-6#1&UUrkYHz7(=CHCVFPj>MPv!o1wzb?t&Auq HU84U7#M|-t literal 0 HcmV?d00001 diff --git a/versioned_docs/version-0.47/develop/advanced-concepts/baseapp_state-checktx.png b/versioned_docs/version-0.47/develop/advanced-concepts/baseapp_state-checktx.png new file mode 100644 index 0000000000000000000000000000000000000000..38b217acdd04fb2430a2332946864de04474ae5a GIT binary patch literal 82308 zcma&OWn5HI*FHRefP#Psh_rMGD9zAa0@7X5(%mg3-O?ir-45M?f}nJ_NVjyuyYYUW z`}cf!Km5PosE0HA>=k>h>$=v7c&jLlg+Yt~fk3ciWh7J}5ELi`f)xD_4gAaW(u21U z$P0+9gs7T_!A{nr%>MDK9*SOK^ee z3r7Q;Z~%j}(d%Su{pxi0N`Q`TO@$Xnt>@WuR29?$B3nsR=YXyLAjH-@u&T)vlF& z(`G@G=rG^z2d3Y7$n;9t*GIp<1{21T@ux8QULJ>48ni;+cYb(;=UXPlriuCo|LxFl zFASrB0kSd1sNP^WkB(W)?Wbn+z0lkAf_{-{<6POK9O^^haqyiGvEXym|5`HgSt~*; z1S8F9?H5s7@OZo=99cS+Jo(e7Pos-q39;ZW<-Gp4*Q2Yn;xJSKzI{95V?TeKg}m27I>Yhu1eE236GCB@j8Z`L#)%=TTXo3$$) zYV|%-QX^IGAVkG?@llqqjD83{Ae)$@W_4_om48S@R#sNdcV78XT@AiCt;^aJO053E z4>c5v#O?I_V40v$F{??nRt2?1T|~4;H~+XPTvq_?Cf8 zK7^B^hqi`vVjOaHbv3)s`QNDsJo<&Cq1wwvCL^%^;l}%|g2C`UF@A>OJ+Pu!G zDHV0K;xNrD^Yl#@P`M&vJTz(y&{hzoH&U?{H-?F*sf~?SoAiW!m2r7kA~HhYaj}|e z)*VH()kUY@S5+xWFFTc?g}xygs7jTfC~+D2!(pB4^8;vM%pI%6JEb44#i~D77Rca# zQOs7VFWG*4KU$|zO({#@y1MhsgizS)G0#qx#|@ZR^x22`r5Iq9^d>3f$Tl4lA+uWn zf2KlkKcxeq@*#rK^?7e@K#<~>AJ1`<88#$7q`Ah~;agHsB}#rcVyO7|1A-|Kh@7<; zd(E`HKA6&i8u{Z_prC07$^Ix&n(S1|avy$sLZ zrS)IRorIU}PE~1y*4oh^>ULAgOH=zoB`be^IHBmRHuR78Q`j=V`+8wCk1<{CSnfj1 zA+C~tc&8a06k}MJszGjkzv*eBuDr4!r08W2CCB=2&&;Xh6v=Eb7^}1;m}pgJ3E4Gl zn+p9#i>^?Rpjq!VldLk_WhZRvAO7aZwZ$W9_9~6o;Pt=Tm>>V*aQ%v?{S*a7RHXNc zc_G1IbS=Z0aZhA@YrK@b+FRGteiPZb{~K7^t~+7E&7u!2BJ4Cl)V|_l^WE>W#UE3O zcR?ELo14|dsAT@kWhY^YAV!x=70BdOK>Cp_35s`a4^mv2f@Vs~ZE3$-`(iDD9*t(Y z`-<8mD{Rl3_6ck>?-q~UY`M@}Fq(OTl&`@swBFXH!(w);es!h#PB!b=ZWI|(mg|v) zJ_^&GNSL+%e7n+&8YAtA!4`u;Q#Fn32ZhJnFSEV-Z))~;V%zDXf@0bUCN8^VkxX8_)%dFlU;jb0|87PgTGm3V_s<5$<%;;ff#~FM@zm0N;y8l%l{JM*IVmXU z*gtO07Ab1z&cPq~W2w_tQ>FLzlu}m5cjwme3tMp_gUA15B@q6B0tgkM| z3a1F)o>ME{QTUyUf+R=1-*Tj=cf2tFgH^wY#?bd9dCq;&x3d~$>i({&8Fo#*?v%(5 zVL^%z3G75Ve3#B|akxTJ-vY3kEAsCwCb>{}>)`ksRdj{64@!D^&E zv!xScsm9G3e8>Hxlq~&c!}zS}iM6WPUG_Y?#{$#E?vN5YY*W>|HD=yyH&J2R^rB3b z-Q)IsBKi7$E^OI8r1sW9<;4&z*g2C{{+ZQyN%HRpsu~q~jCk~lNg(Zh--hfjwi|9u zRm>jP=4v7-2$scLEiUA-0$hm z`|@FlMU2GpJd7I>@aZnQp$Md`5~{=f(iZ#&S(_Q|X_lD7sgt3tRLm9#qD+~CFpA{u zQ8*V2;k(PucQ8BbuR1wV$+>BZUi;Rb}I5Wb^6HcqW{gK@CO@7OzLv!+_uDp zFRZ|`uEY-tUA@5|V4^|CAy3K{^zJKBFMUJvAqP}X^tINL+=}kaZo7{e`ait}2Mp1> zwo<>#P5Lx$+w=?HpD8S2-h_eZY3-dutu!i)FjRl9=b;uju`E z))Qq`d!qEY&SN*<@RUC3&P@yI*4ZHWj)0wJa+l#LfZ>g-jSk%9iM$i($@2*OxZ$w{ z32^dF=S&dF^FR8o*)F6$kSV~3Ww=LMGhHNM;OX0Q<}}K}hs<96e~mTgdp6(AhbG_< zI$5F5d~4iokYo*+e?J`Nt$vUPFPm$ov~z_6q_iQWeEE681yZpggA= zIhitvCGv&{b}+=Vb;SJ{*o$JWX7rEnlpt_v~fNA{7v>dATU#EesnE-n_SEc#Qv$bK@^}4nwFl5!9s!=|Scu5(?V$brST{ zq(Wp=j2}FUJ|=dQodK$Ls)a(A8`OB8JFL(I&dGRReCcu>6V19Ffa1X(I&=)1>kqY_ zEm%|GLVg@9_k^f1=gJR=)r1$RR=@kcvNMesX>_(&PHI0MX`lV;EciC$X#dh(cM`a> zZ3m>PH;ytmq7KCbz8p`i(dOeh-RfO0>uKU6g7m~;Ypl4z5yd&xyB%5 zwV|Tb;8}lmC*j->_Hg*m_ecdeDg%+QU&|&Av199a@^m$%Rnh2Hv||Cc;X~eHlFV9od|ySpl+ShgggoA6g!{LhdsC z6K$ON@~NSLH4G$A;6LL;W5_Pl4+)!;MjGHA=Lj|o=&hROHZ~6`G8VK062rWyqFJH$ z8aER})${e#@PPt_j5iWrYvXPu@xMan%lNB>QJ?{$Ah5AEASfIb1Dx@Xg{bp)>KFYY zBWoZ~A4TYNnKt5$TCmty0q9xorgs8r*l!1X>!OG_)`Ue+7~-7Ph;egmb4BrC+vW8O zALS{iosgr{id9zA4}PB?@ra;9oW(NfeFNBXMI@4+kHSQQ-()C0tg*7bCL5wke(WHQ zGcx=fC7!y5MhvB+VU+YHf?V6f<#e)f7^3{L841auXOM))j`LNI1+9Dv=kBng&oaiC zb0G|mAz!>b%hVZL+z^9I^dU10H|q&!c97yjVuj|+cNie8Hb@C(4o8CHa1ySEMA>p+ zQOHX5LgINi!&FwA9+~Znh%ru;!WLArk!HnAUdl$NRd&qXMV}*u<%UG$wK-nY=SV-o zF>qU7WW`_+XyGlt3?Q&_JSJpt7Q=nj;|oa)K@kbAsRFr~7~&9=!Mri$i063#S4!u! zdi=Y}EuvNsUXF_uX&=U!E8Kxq?5(HtjgFgJ16)s6*>c#&7570(@ka1ul5ArtJjQvF zi+%%Qnccmrx4*KFE-Bixh!LiA1L`T0pEBeT;Hh*BMd=?z7w9X#Mh!x8(K76s!Otb^ zcx)}{u|1gb4T5Z~Art?HV`8YP?t>aT)$=kW<9UoKhpXNC49iEbuI>kJt>J~?*qHm; z=n`Zd*pp}5lYUapA)sBfzZ)~+v($VJ1rSls5|hn^#0mzI&YO4$O_Hrv052}MR0l)m+9 z50R4v)@d60s)wt+R)j^XaawR%F1GnPp1jhq7YSo2wk0NQ@<1l*7#VE{e}Gy7!e4H4 z$X;5M{@AvN`ib(;qp#Ya2Mv-MWi9-K9Ee7iOI;S}SYcvZ{&1VuVE_r@#%qE=#)y9e z`Ec?Y9 zd?etp%N0GIRi~JkQ7d{Y+T^zT-Y86eObeak-M5DvVSWl;9WAt~mNWRly zmF@Rt3tn;Ea-ETw<6{A&FF_q0Cj-R ze4bAUQnZ{^^1iDF1vMov9=?m%kmbxOzA7lDmUl&_L!$JjWpJJMnk1P>1`zWzX+N+7 zx>#)@Sm2eo%9N{2zFsk+SN0c2gTh!2aZTOGzElJUwX#|8g<=0mXmKPKS^#fd$Z0`C z%xt1i_LfuYVg~oTej-Tkldk-B?k88!if=JpqrMo>-g3+H2@q**bf1pi%% zmMH!A2g9M%I!K_u=5ALC)*L#JWo_k^xra_vy1q@apn`ZzcjNmGZ~)oYo3%?X)Ijn5 zF#0K6A46`a*s#$4?!~x#bMhOEmjvKl8IST$@C=Uz6r|Lc6}Rhf4}%n$=|kLA3D`M7)i)?*(5z5<%w?VF>+RxFP{@DR`iDoY&vo+qx3(EhI<=G}oP@ZmO0UlUbK`Co^x+S7_eHc(frS-HTaUX{hs46kNEv}5oWRjU$* zg?!<1RKeh{tac1^uIDk_b|&}R6kzV2^x8SG(e0&fM7HNEJu1>tOHo+AY%ms>X)d&tbux6(ZPr-OHT!N!gjaqCmAy4Ujqm3 z50IyR?d}M5^S!oV-0^BKcZx={$U(R|6!2N%g+UonhxmNXt6X-bUJs9J4H=iNtb|u_ z+RaS`WHK{2XfdHj=JF^Cp}V&I?Zh;{vZxzddqdvcsWEauU|)HphCVBc@FumGg9)!g zs$IFDrv2&THH+XlUV>;@e08(A>pz{472HWY@`ng$M(bVe?7BW80{M?JWSMyHzTw>xTj_zzRu#@n2Y9SHqj4-_by@EQpJ$L&W*{f#mve z%fEDRASNw7Vrc5PnPaMw5DiJ#x!ga79i!~LjFJx_wK+ufh%j0ynbi~lSh);DY4&LV;uW|KgLF7p;Z zq2{FKMjuh6B7Qg&6$zRq+%4-Zn>zR3mwni9AJ7CV@Jmn-bG@gD6~1kFOvL^T-X3q> zW1MT~a}aVtq8vtO=%b8HF2GPf=Omx`;PgrV7qg$~j&Cx!`=e}uTc|WTnJq`5$Vk)- znSlZxZG-nyV*7I3DEBaq(W6&?j1;;%YOmY8&+Jg%%{RFw0o(`rJEyjG-NIbyUb$$C=>>hUjgXcQtO=|m_7Lw zj?XQ{yheGtdyLCLS*NNSmqm-Z&S%~=_?YZ!o^tW#ic}2s-R1(1h3m(-k(|WCn zX{E}0)zZ4oatk*1*CnBlu=i=1bF z4B?)`3~+c(?;yVQES@COX2R<)(GxLzr1N+4*tjU9HkrN^(@n0Wo?U~Vvkm<&^2dr* zdpbh&nS-1MJ}1HdEUBT8g5I^!9P0H#(&Q=#i`q``JkDYr*L{}LjJ{+4r?!Y~j zV(t#Dn?ij;+lOq5#5MKU$m~|VSVa~pm2%=xmGzQ z1rlZ6PL%8RoZwnaJ%R>IAO?j27Gd6c@+6qR@Q{$0hLzW6c}oU>Cb@yMA3cgY@(KzfMZ-9h}krVX_Df#R@-`VOZNa=62gS5pohiKkIr z2J1FIPXllHY9s9Fno!7o=K@Z|QJL2pE5KTG9oX>E7S=V=M~O8C5oVKjevJiZxGXeg zL(iyW0%BTYYPgJgN9UYoM&~^UTzqbYK2DL~yHHIWGx9h9SG3A`-qUBFHT+RM@S$eM zoyixCu#9Gz%fnHm%wFWK&CHtI`jNc;OGN=@pL~vY_R1>K! zzo^B1ui7ULrO<&eOE66l?GEtob1vuUclXT@Q)yF6MLlt=M0qcBKz$Pvj*80+i>RIn ziWzIS7$i@eF%OJk_{hH-C@9in5GJ*Ei5};nIu{tTZH|#GLQmN`EtPT1Ma8x8%?J6t zHXhm(#0By=o_OM>Y9ZWJ(-OT1Dq3jtHAtn&#j4&pa_}kBe@G2ofI+*k{!fYfI zkFf+^$MpNiZGWdJ5;{k?(W zv*RNrf!;wm9>v8VLQL!|?66WIxT~7l8dH?meCvpH`XU79`4?RN$@O2lLzIFzyhyO2 zpd7rB3_kHoN?c~6u#-2C*Zh0n)c7Ux;wTszs1HjidiKI*{h9ANG&e}%$$UQxr()56 z(qsiJ&-ulDwRwXLAqzhfVHaLFb@mZDwh8xn zvh;hu16}b83-3WoGJR*Tv;2o3WY}M#X6xx_J>iLP9-D^j`pg zfPwP3ZisN?R{*N6!?kP%0=4H;4dbLMlUp!qMIQMU-HfT~7aIxmzequQZC7>(?uZ;l z2_;AZ05{VZo|@D$YD%~~#~f%B4C}5?{Y*BqvC!HaaXl5ZFoyLYp#n9a+U}vuAzbi< zMWu;gY~gLZQ#i}=EK}wfPseB@Q6S>(cr*s}N;gZ!@r{f`e`758;yowGED4B(7{KvWl~(zMo;ih#}3( zP`aqe46zxa^xO<8b3OJ-zg$IP~ zPo{APDu!iE@w{{&+|!z0yU!dqFrY#h1*!Dk9xp^AE-L8ALv@Xh1K`Hu# z2!m$(==pmX9ueJyazPR}PZ;xkHfl>@cwXF?7v#(v=lvi4b2X)woIF7bUTb5?b!#~L-Av(MC z019x;k`zpzc0g8FdVZ@ff-ToG#+Ah+FM1IL5m@XBtiR7nc$BmIBuIReHS)*D!M4Py z;r@iH#V%7{a=<`NeT@zl-@V}5qay+dy7twqVvoDNlhRw2ttn)$f33%4spg=~Ch1}* zdiJF;4t=ezw)d=I9jrjV?$??Cm2Lo=+rVtSea>_pC~kh)mDXekR-x#877O_$S_nt} zk`|<@Sx2yLL*1N6x?M2UnU3%u>RjlVminv)`r2L{#@Wf0+jmMS!()}RXYVV8SQ7GC z%W2O4g|R}yc=e$!n|Rebk@aZq6S1oG88dr)OLnugpco!8PfsjeQRipTN54oWbsfJ< zhkn}40+qwIS-)&^R5;o!4+^afW532|=JzhqR0)qMrs<6G=&aT%Sl2YW+Zoi}t2a&B zrWy+l3${IL-f!b*LZY$h*?EMV6$V4*B{lb2`GM;!QaFAB_}Dc8%DP0flJhLGeIR8p z9gsub+41FB@W|tt$4C4U4PZS^h*$a-itO}4|3zP9V z!S7LLG`i<_H}D(KprkuHGGz95rLlwdguUsI<5GKQiFo~U>8SuQCNz`YvhawcNlIQWuM8Qh?puYv`db$13RuGO*T&|`eSqKZPhNvvXM{6 z1gJWqZ~SgfG)KGd0a~{{l#Z&jW=GVmc%XAg8u`2!6QsB?`)WlB20D*K#*K4X9aJ*m zMn*Cy3XpNLB}FC4G6yrcn*1Jadyx{!4tz(1%cc% z25@;tVa3;BQchL$%E6!&l5=sXDPAnlA`|x0+iSn`LqP{>3hsd`z|^f~xi7qCGz$n2 z%uM1AKp$ABMujW|C_?f9gUIfAXzDz~h~0jqNA@D1X_?<)lw4%1qJ8IuW}S`ps6Y1J z3NfVAX|-?d<#VIpV4kbvO_Oc~M&;ZOff(3It1$JtaXP0Deh|rp7EfC5(;d1J)6wA} zr;Y%m0&JDJ=M?C!D$h~c@zOdq;GZ2sahjaYtpOhS7#{cZ6Qe2}iZQ9vOr@bPqiR8v zRV)K`2t(45kWJ5d`1ueIwg)Okpu!G{4^p9C@W5X8s>DMjw_>txh4A0SIR{IkRv_s zz$_$@&f#{balDR@b5O_@@T`#C%r)#FeAP`%cv%gKpgRbbZzi8}!KU!Ci>AN{;g4dC z@^tOd&L*O6P9T-QYehZ|5T#?Ep$Xu31k2wlec^VGXTQE;SU{Szz5q_ zVT4R}nUM5UZBYROD*M{(?;^=2Og!mH=ru3DUa*K?w2-fQr+yN^VVC-Cfmmx~YM;19r%oxMzfD9wH$dq}o&CcL| zeGsNyC@S%x{%Rordw|^)FO5=6f(EIFB-}~L(5qb* zK`bT4ml(H^BvG}+pCY-j)yL^OTIwtn9HSsMZy#o{W>BKx(! zg$ZOLpo-xJV6r^+cY=YyStV$T!myBK_)sKdraOCkE@D1@lzZY5z!DHX_G%*d8nj6& zz+DpQ)*g_N+CwmmDEp&NggbBGWn1Q#0w`B*rdq7Wul);Uj3-Yz#?Q|`*ggOK})0P|M#SP|q&O>x; zL~G8&hqg=CCrvU78-r9)xbZEA zb3>*B`xoj#pNR6&&7G&BCnaj~w5LMp4~NpSQvuoKkq-@O){Be7$ANYLxekc$ERO^} zgD3)90lzO3szg<6;lVLnD4SX$vHGLNcLOunnT{eov--8+$Z=i?L9nu7Omr>3QBFBR-XnajYwF1%+3P|#g^t=YnR*7J|KYTMp8)R zE{6|#1mmbuv9k)^P3AcH&bUx%R?2N{SDtwefqGlMfTswVu>{D)KK4!7$(X4NroggjFS z*+y2^_e7ixVfbtsa$6Ig6EE>w4!U0^u*|lj7kToP;Wxek#poAwu8o$P(^+$4j*z+I z7bsb(RASi*{~zK4#1ub$^~!iIcW|*MUye`J2YlgDJc_}tWGuUcZ(#QY1h2u zDyBclh00_-^UvYjx8^$>MIt&Jab|bCk&d{ma9Z#`==9uFYt9|BCSq|XWVUJ}wCzp2 zvuhMmAg*jWn`IMzZ*bYJrKE#HOznxez?{mapJc;lm;5-5y}2BHDEB5?bzOGP z2h~(=KgP*04MXMgnyNvqH5))e0jZ=#Ama$I5|z0Jl%oKWW_xo2So%JWL5<`XGOu2f zSdG}`E}Nd|%0y1v5uK5IB{tjH)))Qhb;*IjO_;;k#j0zvw?6J^+wQxU5|^j@G(c(` z$6ekm6Ks+3sXnGB=7x^iaF>mQry}`_8F_q#{-tb%o@YhGMwxcATAiJ@651&RUOfbF zsPU>o%uzWLlW;)39Z5fbgjzlS{dl_5=?)PQZ$tA~$w87@(cdD%yvK92_kA_ANVF#= zU9#$XBq0v>5G5&8TjGben6!pr50cV55sUp){?%Gz-<3ZX&WBnzgex0L=?|b2Q33HC_#uqm~D!(`lnD!br0HqEn`%tZE zy0FsV{-cE}slJQ7i3++I(3qRc$X`S=x^6aF)LbO(G=oy^sgH^5;~ojl$ZqzO$X^h< zV!0^n&5M$Iz(2ms;G^8TmCCx33EMKuKRXU_x|$EU<)~I7zv?%+n;6Vt@x*)ZU=z{vn{fA~ zsLR89l6VwoZtBH_)3_8Paq|@I8vYzBr{`#a7YvBa<1${>ORF=4ULi;9jcVf2C?KAoN z)Knd$I06@>qnf@e{?mfuA$8xLcaqp{dFo%q2Vdon=h4D<;|`o=^-=SsZ+ft7;s#vr z#iz9kc_SuU0=@B9ZbZWs)dHu#FjeYwY>8$W<(MYD70LY$iP9$O5wg>V_>I+8CLwY{ zG)k>wqC#5rD$f*1DOGuV>HKdTHFSh81Cq*)8w4glhqW|sxbht@3vJ$As$3ZDI(b@; z$ZSHFxOzRkg{)Nblg7NNlLgdj3tG4w;iPxF;g7TH<%H(1D;`_V%b45Fvgm5EC1XVz zqz*HitRzNn|Jg&g3ojCwu8GEPsQ*+I8ZU;w)}4V!tEoG`45KSYi%C&Q&Uy8!=hKYv zLEL7Bf+qjjI>pFMTF>fN>C#?2tPDAXQwY{nl4naw%gpD-q>}3f0hQ)9tI35$?{2Eb zn~ETVS!R5ZLLje32RduAPbTZF8j5Uyx0MP6Gza-}c2k+#BrAPgELxB#TB@Es8LgRC zeH5hFCBWV(VY^2pY}_ErY(3h9u-XM;^CYC;rry%L0{M(OwjW!` zx~rii?7f?#)$F#HS`qK3mD6iIbjU0IetPM7rJ()FzkJToyUp5b3)@AjY|dVU5JfvF zU!J=+%l#Hp+TbzQi_~irXz%pI6_pAfAM@kkrl;;=g*j;3n;mc2sG)va$%Es68rgo$ zcq-xEIHuKY8FXvKB867E%3Vf$qXo_XlKaCf&)T*CBz{8S1*pCu5zHtf4wZPcf8 zvuBP95i21v5>HQS&2iyyw{|hu5|+ad*5dwpt1#R06TUM22ixU5s@ko{U_ehJ{}yw^ z{D()PTaQQ1{;?b>zBX2N8fB@*@ zpUei|z4E(0Z&x)3<0=PWW?}jJ@%d_M4qUYBy*bN3KaW}S8g?#2{d~$~OSDg;DyH_~ z1X^Ok+K0U2(eA!Z$x40a#eN=()Vgy1jHH@s6LWn;Adtsea{@iW4PI=US21h zf9N&#*RK@$imh@Z$KNMLD4Pli^DwVz{lYgM_&xbLoh#*%U`{w0j$IqyDJ8Mq!UhwE zf3{2u%YPr-&hv2ku3wYR?D3EmuidAzH2$0P>>10!F(Ed2AX8Q#p816|Pb+__3-_C4 zoz#jdWrw ztWQ_IJKXq10B)Z~V@S58W`GO&%pr7o%SS&C;d05_=(DLp3cr`zAA41VB4MeF>@h0K zmGHbbZo?Vq&gQh1#}It0BPGcbjgqCrU7jf03jI-Y<|fzui>Es}s%g=%O=ikBnoH0v z^>r>$rJE%kEqU>~t&cb^bf=c~6FWA#H+3zDzpg~Q?jhRe{;P*((|5a?PD%&p{Zh!I zSMJFtN9Jk$knXamcs&!6eXbUlJonuHVfi5uR}WiK6<8V*;%j z%i$af|7*uoA`bI6SU1BP53kEb-uhKf{tr5OE$EiBRo`3@O)4bWms&|vsQ5j-mK)fU zbKA)8Y7sXUcC;7Db=W;;g%-|k*7q_PNcK4jm1J`?rDRrnK9azS-?n}El_C5S80M9I zIj2us=r4cg+Rf!eSMvB&9k&K^!5IFb={jG;@y4{`f=+|M8rvu8MgP0#U!U3-l+lwe zXkuasLG8})=`1zu!G?sibjIknV24Sr7#(^WTy)+DRI<$LC0m2IrO3s28$PGrfC8o7 zJHMOn0RyMCKTR)wJ!1c}8|@@sKoY_*Fg;rMYrr^eF_50zIHv0ns#MzZ)=8+ z!-k!f6{deR5g8R+tu&&U8~ALHZwi`x)^7je-Q(t&udIM5So;%#NiIr%dUn?fdv>C5 zMIS>RZ-8a}<8S>$hW-GAf&1;J#uMi0R+EgtP{-2x-mS@kzFWcO{+TRl;oaC~VUvPi zK*sh%)#v8unadO`fJ-r|TJHo(*U4$Qz=ZcY&mTufLxH^Fq~`TFn32hsZT*vAR={Z>ECyeKfF?Xk9NFb5u`fneo~pV8x5rjSB`(?4^xp}+ zv^nM(HCdOXH#@Qj*0m>d1z;kshsK6zI`tPxUp`4cKmjRYT-u8pB z+w}1nlt+^?F|&K1xMAuW1u2{B_5EPdZfSD-GvCl&UmW%DX8*A-XTQ2JvU&!Rd_ry) zX#2JQY*WBEe2*%u>tgC=CEZE6xa{Wp3uuo_m(Gm~D&dWvhnsjTel&2+h7?T(3L5^5 z6huom-&~hZj_fH{kh83q9u!A%*{}u*#MERkeP#zZzMo0-^Ioujq+2HkJ*-prE%YcB;gDg|iF@kPA@ zOR*Wes#>rXk$JbRg!l@H>pUG^NCHXpXR>_ipBYLomxDi&jg&{x24oUjUj9C|bOrtk zQGwP2*&maoXb<~Ha&|Z}h(QTmlF8@EZkLB{zx{|{$XEcVZ!ElyH{u!PQ(i7$D^;qZ zc8Uci(kt~9Dd#E1QV1K+`)g@&z6!n{a2%NVD1I;TQ2?}{u~HItgzCP`cw{fboi4^_!FRh&YIl! z_sGUCsXiE#Vmzou?h3;Z_WtuNLYht~yM;NtxmX{Q9RxwpuNUz{WZ+A+`HDp7Bk~>t z9MMoTtQv3J*qyV^#t-&R9Z?`9f5_ZXfFrzftLL=J{GuoJ_WcC$g^t)Gm*=zKIpipK z9gK7%pRtToEht1XJsH3N5ho2M51p$;0+G%5UAK<4d1KXkQm!!`By$*t5k_U;(zGAP z>*j%@#fIVypvXiEB))_BkED&lx-?!?F)WwoW?-O^-R##VM|mKI!boN_6cVq{^RHYS z%f3KuLQyPj-M$I)&Qv825pEdKvdqffu;7WfdL2GI-6LR)S^+N`hQ*FMXo{$m4(MB`mX{>Zhmsi+4=`L`iD! zI$@%(fA2y6@5UCW*oAV*?=Bc*gp|cS5N`2*_yZk)Xuba6CQbk@3^dgM8<2)NzV-C}gK_jz z&yXNRsu1}NZq%#~_!zr`Ks7q+H{-1?0xlN->mY5r3Eb3EAwbr$a z@PB!Y*1Y;N-g(4<1OPG5jgY2`^6e1;{;EIn;vu`Zmx z!E2(+6l!lcLr9Oz={w2uMl*h{{uX0JuFS0{gL9+zZN3y@(Ke_EU z^)hG1KW{2fH2!_h_5Je-XQ17L-#;&vtK!Z7<0W%S5@-^0MXnt{y#d20LN?9^D3?|m z2Paw{NV@!h!cx!y-15I&z25{e1;9JMMQA-g27)_#DK)U5dm-cful~Ekhjd`<&*s&y zHUJX07zH?89xLjKcMAHEyouWZfTtHBcqj~v*Ev`qDok~se`LUYMx^wi)llsH|I(?fkNv-1lHT;pk!}*H^nNu@{D7%G(RNDKy~Y=o=}l<|EG0e{ zAUfuoB`<0kwX!7#LfOfn$%QdBe9j9Lx0%H%`F)?5)JrlFOa02F|E=4QpaIZzvbY!G z5;1zMUMDg@^%*Gg7W<%vg=5JOh~rR(LXQU%g`!LP*~e+W>Y9fA^09fE_-v0uZW7V@8blBf{!;x ze}Zmxpu4-s7BF+}fvDfDS0q9Eq*@8ElLmpM}KeHWUWD0nyv|X%` zTv)!g79RV&XjjWa%F&vp^bAf8A<8@X+8sGf#5QaHx0eW2k}YluICB zQ)u$JIK({Jo>X!MNvZID)^%}q91Yl9gy3%~aw@BS0$cm_;UDl2Z2JB;C(dB#j(EP^ z|BiW~t`N3duHu!&^yC_N&x7`8vHURLR7@$Cg*kvBvhzRPnXU$UxhBAIpG`|C|_DX(0ExHY6%1(U52>wSSgz+H;c`GwCraY*%5Skh^ zFLrlasamLL2!<+`FTm-WLn+ZzHm~;2v3oIqTxYdXA%lCD3{>OQ=S-?YvR}q@0-2t0 zViY+Oa~3?jh_T$#dHAUc*x`zV+vXDwc$dJXz30Oz`Q{=J%)O-@KzGI3elnqZ1youZ zKUDiKS3k9+Tice1$T5Mr@`Nqx*%A>5!Tl(DzU%gcryUsCgVdEM{KtlR7^J)oBIW~` z7f0ar0Q(M;9H?2pzoec@5y*T5?jWnIw6BgTCJ_j@So;cqjZ6cp3BBL-1Ja-sJ==`@lpb#4Agd>-jHMl51QUC28c}!vT)J*Ln_&Z9rcmRm{(_I-?K&slc+^gl3%J1z z(2(4L9Vm~Sa}1kRJAScK?IwF4sev7g4u5}(rV068?tz(neD$G6nR_z{Oivh4$M~?4 zMwS+13Mx?3qJbcJ>wY#50p4-o>m28*(42RlPDO?o?q5!TcW>ax(LyCdg+k6;JkEmQ zm?C7^`}3;z>3h@?5eKFxWMsYobTDi?xx3xJ3ql0XF#q$VAdx`ustASdSc5n(>`>uHLN=j7(O@(lH2Itwihl|4LFxTl4TKTS>jP2} zuHc)?G)DZ2k=uX}X}Q_lE6f{})0HLMTq+EkECt9x>kU9W1Qlt{5d7!6RRe*_S?m6F z36>*p*+IsQ2Zhl!nk6FdK+ctodhZp>j|w(#xW#g`pnn?3_UGb2)V$bAb^|ZyFhFJ1 zYj^=XlZ&k7!d!piSxd^H(qPq1020aonCqiO1jYDsp4LwEQ+<(?K)ZIPwpYEnJL0&* z>1l7Lq7uL6HSnL@kJd*6bDb~`=hjL$_wpQWj{@Iv>B_rVsgkaCr~nmJvhNMm=ysxE zASh{4n|JGGHQaY+P72Q7gF0zHUn1hE9b2(MYZK6EOU%?-(}QW{7(MrSSJ|x%An2wB z9tV4=RVDI%vSL?VAB@=4t_)=9+BGpQ7|VdM#MS$$X`ttRU9kWrgk_mD${2t@%l-AU zhdS@g@i7{wl>}fPyWi_Q37++F9ESEKXwz?wh1zCr`6%v zqJO)RLZvoBYQbX}%M-{NeA2}?^nvFtvG5c7gO1H<(f6!(^=Inp=P>dFaJjJd&U}T)&us-^5B4mK>m_r$AlDgMk zgJa*p6R0FR`@GI?xld1?Y@Uv4YpMcvc@(OVN=Ts>oYd|%J1f2~e6}j~&&b)7+8L$2 zt5X6sv~->{dL3?A?pf0I2(L+gFx}XgXwwS7U@+3)3fa^x(W}{5re6Rm+WX+3{g|tn zF^9m_IZEXwT~O7}4=k?_n$Fe>hXGXt7eYeK^J(Kp%rC32 z(}2=dh^hd}UxFt|+uMkDj{?>ed?gK{4MQqTxc268<5pLixPrSqZ zijRGD;p*}{4?q-qYxx;xLeyAk;1xW%)r;8glUPWqNffqvA?COeo~xcZhFD|ziSUCF9)Rhn!jIkZ@*)+L;uMCEj6ooUBuYe(HTXr z1};ILz(Fu^9n^+N)VCsNj{$4n6zJPm>)2h^M-A4fo@7=4T2n80_??VOJBc5m#nc{I z{;O?XEb#{Mncy%adYnuB4JRv47R>v+4^WI3dVUzIrYE&Cc6d5gqECO!LG|hz;Cui! z&!ed-8!KeS^THRjXgCe4I0Yr;-OY6omvtSFr3lU$;=?W`Kb5uNJkmn&20(_le4R)>q|`o-_v(F33Zr(lks1&-M&0oj@kRo^&?3d zr+4CqX;1uk-!lo(f{!(}Bu6H;CS=TX=nOGgFMs@T!8wo_kqkW^o;y3*;sP0v;8YV} zkdODxd+jugHz#jM{xg+Xl{lO{9k{%67Q*p@OsLg0^5Z?~Oydle)zUf-zrVjJDW1Db zjnI~*NqJRC?scFZwq#OpVpqdK!OMZ7KU3h$}vW6D!pM)t4;Te+=uA(vt2int5sxBV~5xdcHND9@KYyJNEZQb|$IQ zT_7hi@QI+v(+BUE1hKe5Pabsv4oeoeUR9D*B?^e$f5?K}?FQI>Ck7-Gb2AY^rVMvB z4zR>?A1u}{?&7k7x4XteB1Z6r{^S8-Ia1he)%C2~ys%xnK1nnYN*YBP`>gnl@N&^J zd-jO<1tgfj4#cP|*4kr)hT^AhsjiYg!`Ol-f(1i!o`{n*Eljj^Q@Al))Bx45(#K3>~a#kAY*4`n+{zxT`&}gQVD}&sQRr!|l1Zv+z+X z;Hrx0N|p+^ZGgUd++*eF>dErcA^Efpl(wy;>5b)x8mpXe-=)NKo7{#!}V zq+@0l2(v|elO>Dod4q?1iA6+M1F*5L>SrqFz_B9BgI@DJThp@a@>5&{mTsf>>8;8k zkxZqA+(mwZ%%HPUY7G#pN?WZfc}e`RA6pZIp0<(6STokQ7!~zA!=h4@`xQ6n~^QLQ2aPd&lqt8{uOdM$DtMAOcbW zr{rraHERe)3WNfkEdgt6i~ZeQ(ia9+eHGx>~G_J1TeFtUB?mYxM@ z^)+e7&0MbKN6tPhZ`o8OVpYtRBt|pKUDm`paqJ)rws9e5HV@mCLvlYI$GsZp_>{~G(F_|t3%tFz!MLA+x zN!32s!QO+-5O9S?c##}%i)?IEEBy<&A6yY`1UG|g`x7y@47E9|Zt;Z77w<>q;6Y{q zhl+qs5*$_w7{G?%F0n+Kb;j%mvjuBEX2N2D%Nt>Fk}^AtOG5=r@NT(R*vwxnV79q=KyZ z*`Ox~T;$*1)_4#t>4Hs-$nl>AK2?!H(a>f>6Ff6}c84h$pyJ!sPdTBNX0Y<02f~wkVeGI>~EJN@9eoTf08C&Y-Y)i5(=W7BFqkxA_m#*ltAAh{qCE@9(PUu_sfr}> zN!}k@TosdlsU?@Z(`Q(6_{SGxhi=-az1L}dXvDMEw;PE?erM|K4A#ed56$1-f96}g z`Hp{Emay37j1ks~B%q2Y!YXvthno;|s)VUSoc)Pdt6ykxT5}vo{u99ETS_L7wFw@c zO56DcfSi;aoW>X|_DZ944{fZU4$GYk&u$j_+AycU>S`Qu`wj5R!sFVYVS5|^BEf56 z_uYkqda=VQAd-f^*l2&94;yTeGcT*GsBWx53uaR(YU`2M0{ay$bvI zYfaWa|H%C#pyqdpze7|ZY7t|K@2puuI>mEPAv0AznSr9Hv9({Rtw<}0F^By530N0ZY1t6s zb7H|FhehKq9hL@_r-~*{xLz+{*G4Avi}Ti%{GP2}l19E`C08W&=MiEn4~fFo&t`KS z!Im94G@o0gU}@vg+tDyLe@|)iX4geYnT9$J_`*40s9}9)0{I56JbW5RSN}iqp-%Ov z@X#MeIZdutbtTVoe9)n{DiwqVl(e_tt2^nd4I}9#^ie=*G&K{*>qO_@F5MhO!LtTZ zjs0Ywv50N#&KH85)}Ef}N$BPWyi7$8RrPUEX_;o)%xhr}EfyYPGHo)XeNcc;aLya% z_d}cTPt%#w<1O(R){bFuRQR(@z=Sndj-*)}d2FMZNs*DGaP|hI?ERh$a85XMyyGyp z&LM4f#UFy@vF}P6SSW~wI)6(D56M459=~FfNaKWiv9i<$bR~B>m|xzyk0@Cat||dq z(Z|Qzv&-33=^|_kQBraEV@@z2VivIb9DvY-B77<{+vwkq9l`#{Dr6J-=WV>TJzFbb zfY0qTp7TJtF=Vpl^YIh`ENMi_pVNBnXUzLk-krVAQP3lChuwAGu0by~kF`R?heRtE z&BwHNMbe`P21D)$XUj(>i(VCVlxqB{`)L@N@eSfHmwW5vZ821X3;$IwzytgiI+dJ} z8jYNT*uyFVxQ#T_u5vP<8hVV&UnJ5qirIDd-XvPPLzkxi?Qjo@F#c4r0^k-bZCx%#FZ=5&I6i(&0HuhlPuol@*AvO;1wvCfyOkg$ z9sWup$V7GJV>f;+zlPQy_Z&?feBH@@LKTPH7`+&_-{Q2LW*he6qlm_d^h%Lz#3ri} zJ8^!}Pw74e5~18e?AnPyVU;=m=vnbJXK|4`=_K5Vx!0Q|Rudl_upePb-}l`V z2s7(5Jiw`a&82t;s$SN_IcRKaOnrbq>{G^sWsH_NmdK$Ji5gbYnQ7o|=20w>?Dvu# zoEj1C5C+d^AMgbe!hyj*;dgs&(m}`UYj)wPfU6~ViZZgruIUrrewQA%-M#;)Aw8Y* zpv~6XjZYa#u4^6~y@NAWi|syy?A(SkPlA0KcZUifqC8?wG9ND zQUEZdvJ^+~p!PMwKTP~OL5)(*%_V${q3C_w!JT8%@24{o6N75mc z%-56lpTM=WRhE~E#Zl$?M;JD{4XLyo1w#j;N&b)WwRh~iRaIF%mkNA@%BiAhUNy$5oe0D$PiM>nV-0$ zyI+tF3%gmgLxOP6;WB?_PHyrtY=ObF?vyP-OM^|;&iRwb)`rL!u>f2WBYRRC>{kbA z^6ikWFX2!P?$no9@9#7xHr7eJ>?j$>;ZUh)Z!FqrVMHBpubWE|X$aV3>r6X2BhmC? zE+9$@Yq;0Uts!7{sy`4SPv+kn9kxM>8+V`Ce*jx4Gks}>sDEnct1&+Z(sk;t);l!s z!dl^F62+14>gR{DnSX-NWL-0}aIXeEO}#%+i5uWB8Y27B0R#PFfk9k=XYD%i2_F3E=paOPTxuI z9|u>oasBWm|Cu z9rT`BKHp*lttW1=WbJ#01F3)MtoY;zO+jiPTUt`UDq#M{{#N?;-PsVAWki{Ip} zL3IUNEuS4$TJUPrR;pEo&rd^dlOv^=lhuYosfMAELpmWj-UFAHgLh^lCTgfEu}Wur z+}wwW&YyCM92}&zp(lvwapV-6y_3U$Xd;=&Gv)!T{sy%CVN+@TT{im;gdM~FJ;*cR zKLDlN4S#i)MoD`-u!|~dh62F&Rq03il=eBGE~7#6U+5!XP-rYU?|131XPzni=`Pep zKU0y*&9x7=~CI=Qls z{i8QpGFaGOX4kG;{^Hf8MR(axe0^Bsgr;&`S-Qw<|J07@t(w{_5q|gk4yZP%>Qx|p z+Kw8nY5TV=Hs7xn*bm;VD=71#t25(=iaas0S_1f1N?P4ST$EGr#GgK@Dwi+#>>>0>+oySg_qU+lIE?^D5w{v z8yd9vzN-^=)4TJ<#wHSDwYYiLRnuvE8>7bXZ?akJrBA`gA*e9re#<}pj?;28o4b>W zUb)2VssW#{7*KOYy05B+qJozsWk>%kR-nsEeMEGhI6XwK+kYX^m3DfS{o^kG8P1F5 zo0P84bwuR%TQZt=$ECqYBQ))!X3}ZR3iTZTD;Z~ol`R;R2T^B~)ls7ObssH{I>K`I zr475bHV#oiZ`06)CvRdJe6KD}9Zz>J3q15T_%*72niXxP zbh=^`H~hCjeootc_>+%wVtdl%qn+KxqBnb0xfzM;OZsXF&E9FxwDJ2uKPcRw{C{Ka z%+H8VaKw=rZwE3KV~0RqN@BjckmRI3I_a@h3-DcGcfzk`;09}Fq?>l$eA zqP;1gOn*n6;kT<|-qpQC)i3DXhGwnYiUO&=p`b{W_*W?u*J2;T+}WN;nv)_HJ_@mT zL63@BZ1+4<)>l+liiTUBwWpdx->q!kI_qgktq<`9_7+ccvBIUSbB{zOI4MQhnq;pnO6hssvYFZ;x1d5+{qX zk_*$o;(%AFmZ2$tcnnT|fHrze97lUD;fimd+NQwf6?%)W?X?VikEqXqgM0{A7r@+> zP`118SL$P=jo4NRkK_pteja`QFBGH)xz@gjBESb}XHqkY%d5XDFOR`TLD1hM#=qgYQE!G?fQM+rn^Ebn@c#qtm z=6}7JSwDHdbC zKnX^RK`98Gm++Pb`3T_0z}tzQ5P1hKjoWOW>EP|)k4*`6Zl^WXgBL;k7c)mR*YT`X z{>f7eyZ`?3&`RT7*D0>)pfP}JSFsdz-It#*Eq(lyX~lfd@yvWPSO48W`Yb%fQhVF~ zG1NUbBQmCJ>6R8^cj(GCP1zb3FNZQEw$?O90?{DL)MRpF@Yc=%Bf%hcmc^0pvi1GV z0EA0gkCQp^5tpwkhRN>0cbU%J%vRz3Dr+VXc0*6S(8sE{uZB4IXdul-h&&HEP1 z4k8p@pC*5!af&(pC?#f*fDRLUhauY~`ebCj$~i#2H8rXVT~Z{RT77LgXE#$lq&SBp z3=tOwJQs&u&MK^X?giM@MxxM%>fbcd2LSUY8BKJu#K`K6#lwuYzE0^!1Y%+!kF60aCX zD4~#qshWIXfZfTDjpcqGQvrc2RFeO}{(i4M1mEc7A}`S(9zYz)O}NkM^SVwulULL| z0Vva_Yefvz0KS3!hj6W)X@hL+(WthdgdjmxLx(;4OjQY8e0kL}j zD-Ak6P&3tT>&s`76n#yvqiB!~&(;{c057?B`d;SB&xr1M%-%n89~ zU>=%+7H{oPIhPXc<8i{gvI)m2jGIFh3CadIGrZqAFK@{l!qO^^v1JvRR3zR;gLrL$ zkX`Vldm9-|W=_6G8y#G;qd*4AxBH&KlR2PfLyzfg2JSlhZ55VboW4>NVR%aofo(x* zvEF_j z+W+yT<{SSOL`Rd>)wy^m)xA$mS0*2&U-KU>OtkyOa9%i--m>H896L%1kp zW`*Ci@BY#3>>GHeVs69%EvwemXyUIUL>}T$5#K%~fboj$abQrC$rjYvUOwV2mVib> zn*H)ca^*dsHryw^#L_}O!J07m*w%N^V)+Xy$V|Ml>&J_@H5_-pNARu4-L;_le&uOF zO0zdZ^FJN%6LD;r4^Sm3DzWtT7Y{)bcbh}q-&nO@RM}%sOlPERq^ksd{Go9k8JkWB z(=H+nmj#%3|FRylz+WQgqy*Qfn0>LzOx#cVJ{|B?F}6nojTZk_nQ-wL>~x6xghAc< zKkI^@X8)@+ns@2uMMM_7b+y4SZ4rkfA4sEZ5K!&{zSrfZ{A&-~<~;Hj`u4x3|LR4U zD9X4y+05@s$aS@nlcWZ)!Jo)Rh>mmXODyXnknorxYb4ii>#6u8Pd5x~=&400+_`Ua65>URm{eH6ynHd zRAi#50Nz1Ps8kPG3c@L>vHDmXh$K$-=%dl-ds!4XHi}_)*g0Vn7QuBM6!T`##=vMF zX!y*co_6>IR+XZ&KPyRxs~`?ZUDd;3YSkzwQ9Bh*++m<_dp&8Y zCg)R?SmS;0fO;e3!tQZSO?X79dx#Vy3W>sfn`6+(ds^OWpSNYZPKW)k;@;31rYWBJ zTN;fwVi_A?`B`+3;AlDp>|n3nU6%7J$!h{%tlnvAhQW0ecxi;(h8 zY(f&{^g|kid+r4mF5-1brh+HE29XBwno%?4J|{v7;UMDE^9I5ht%9{1j2litI@5AF^@o>F|#TnK5*-q^^>{avPRM?M;$6Fin;fyd(uZs z7ykHQUg)#={M}jgAwN zt|XkHNr=M09?6pV-`W}s{7I?NfGyfgAra3Q+z>GqcLix*9DFOd&Y=!@n5+O~nx%tn zD5kmUgc5>LtuP8mk<*6l9PByso}4(X|0Z{1AoN(^m%~+rDLZJ(fc3727&&l8JEl70gB;o0$yUHbjz;Csvk0g_hD1Wxg3`&dMrm|fcY zHWP8wM5A)o9vT3mvP~H4tiYSlo!%F8!lf6>kt z+OO-|_b~2-pKe&2p&;GKGUnXMd$8~mXD$$0m$jIQEqVv;3HL_ZY9j=jiAmxda&HP^ zNXpa)1fLfAYSQ=R=}4i1eqEEzW#u8FKY*DRa{6CvYp_$~a^Q%nE<$ls*uESuNnp9d}qc!wZbc&FE(to;sd(HTWR1yNx$i9^U*45S;&Nsq_ktc*@? zkA*fW8f}^*dJ(xA#Q`vpFIbAmV{+Q|^rHN1BZ(_Ed4i*- zV!!V;9z(YJ#BmUrG@nQnb6dqui3TTM)zc5Rcwo zup=gXheaEku(Zc_2n>W^HLPdLy)OxQN2}_$IV_Tv_;^K|JgE$tR}I+vTH3)|pk36DWfWgA=m&p^ zv>^8Bc-`7!%7A_8;u~F|cI~j@Q0)+?H~wJP4FG19mv`~Q%dotOD1}x$D}P$O3Vd#8 zrM*cpkJ3RDq+3UuA&y2Dk!q2X9!xfigLNYv&$azf^y5|B-eTIj)uGaSe)W@Oy(9Ii z7A5QlVoniaA5C_?7jHBuLX)qzS9uP1FD3_G#hA;r6ZvhQEu)V5?8e1sXFu|I8&)eV zETxi+s^95$fsgL=yTRh*4Z5*n8}HyV7>@4k`~;Z5%XyUoee|>3S8uv#`H4?}%j>;J z^fde5x@8~tbIH)9xU8|F~0|h%ypD=#O~Y0Jlz3_)HmIy z=Rf|_`6Nf1m4?#jmxSw_$;Mhc6>uwfkbmq^2&UuLJQ)>TARf;`XB^P^nIq6JtqEz7x_(4?l=ahg5_jK7H9Y0v-(3+xb4w0aLX_ka;Fm z7$USE0Wp}UkD>^mM#9a0JxjZ)72!nOy4~6Up5A!ba{M{A8<d$dSk=)@}_7C zja+#;1;~%~a|r<~tdj7mo>Lwy*fF*g-0Zi91RUA3Q#lVD0R@5A^h$Z@*z$K-l>iN3 zO@tk=3)~O&+!m+Ftnwb}m__Ak_=sH)+`A3ziQK1nP9pO%DZE977z=RzyB)<^KNKI~ zWC5!7<-nEQ$%13|9|%FzfG5v8Pysh<=mQ1yel!UccP!v}(b6mldC?Co3TE@dWz}+5 zfhW8O;Tu4B(fXFrM9FKQH*q8ZEQQUi>=yuQL&Fg`&PD@RbC5+Vq8Qfpu4eFWSnq#_)P z-hA371H$$46(GmB;Iii?VvClb@5DK}f)Kwt=#AKhDPR)`_+Eg(p(NxUIbVmz zJqB@SKBjAsMRU;QW+ntCu=b@w#Rffc)EoFjRZmEN^n7{;3`7JA12q;Z$G+$U_}{eO zfhDtL$AQic$q+SAZ0d85_=d%ln|ufy`2j11%MGyIZV;Ut&Q3zr5inBk0U^42W!QgN zXzG$Nh?@>ib5{b7RZ>krm^1~hCh=lUW)xz8=<|c!u+dw`-0bU-SCvGGul-90PlvB6EE`DM5|k%0G;e(XJ(r zwvSc|kJWSJLhrb$gndh13xvDK4~OVHz7z6ESLbn!jyMo#{OS9o#qJh8<1*ujT+y&q zRZqFf*!e9uR=?GNp7lCPpY$52kj{`6_L_5Ru)0h?-1cocl-%(6S|=zyZC#=6!XMEu z*a1lb?!(Pv4dFy-kM;36oF7oydL^;Mdg497bpGSrR7==xAHAec}*3}-`aEf5X6 z9?!b<0%w^y&T5nkPg0_d~^Nm9)N_@_k|P%w2bPLR|>Q|rj=H@8H()xGn6u^78oC1IR*HQNz3udl+R%1gu}o`$TXuF zB$pBVyr63$-3UU1GkNoko0V2?`hN#&wp z9d6nx+xz=lv#Q$noWbpj1l6U)dqaA^b9KgsjTgzj8;5zvjMHBm4jB1gR842eeM1xS zW)ECnp=~Ukn_J4C7r${hCSSX{=Jrxu)l7Y$PjKt=hUb++=YZE-Ubs*eg=l?2ZA-Am z_t>AlqyZ1)!NXBv+rS{Yn#oku~a8i!}k@P$egC{#kOwE#=6?Ot(1(vwU+o< zlAJBke$%CL8Zt)a9+;@l<%d<%9SyI7j@hmVswAG3R6C_?HXb)Rb`7en#OA~#E<0(8 zf^pW~uLI-!o%u7GG~l}&7}}o&Tg{ts_9-)Sg`g@P#r(!x&8E3{>Px(NlQG**6!}PS zJ8>E?qcW~@=3!zv$5;i=^P`Kd&eUqWR$v~!S8%ZlyW*8VW6|Fk^xJDHm&w%7PlR2w z3-v-TXQdQUepzpAU$2i`_cYnkJm3Yk$~EYN_=+=9o@I|k&_3hJt!AU=T^_5+cGGrj z#tT2LG{Rdh%N{GJvh5wJVvU5x{Hu(a(-ncq;%Cdl&krv}4SO(ZwY`*X8g6gbIzmDm zM;__V?hG(_2CbxzXg?OQ{nW$8lh_t5p~^_-m*ai5=(T-D#rgBgG{JFPKDsZKBkWgf z;q_rS*MYFf(nFM!^9m7XuZMzCclx>LXHZR~&G0>FtZ+1Z;CC}HXL;gQoQFe?dEipZbQ`BJMQAw%+yOh^i#mmMX3zhk)OQBS?jsNC@_>#OsNufLkP zUGuk$^IdmxF@9M9;qt!bi*BEs5{E_e%8wehEFS2?FV_-xUz$Cse%*M!{!t*Ex`b(X zZB$_Ky`lGB*@3M~u-^U;<=kzN>26B%wAJ?hFgu;MC z(4gY5ekn_8;#2v4CI)~$h8{usl2iy*_}1Jdc#-qQ789@#PHZW}TB zU0?SLD(x=4=oJT=l=lAgl_g;^|39E4@iVrBZAH5ZZE zti+JpP}qBsr7N-Wf4@k#k$qjg^YI*EOn=iKedKV4y%9Z@8qg227prwir_hknwBT6& zkp7Tu@Ty|-9h$$!X{eA#r+E7FxY!R;o44LZ(`=IT!7){y5LfA;ul zu3A{BQ+~Fg>QvC!FKa8fE~nvKXhV;N%FSJ}wW;i~TWJ@uYC=zUe@K`vwjGOOw@gy2 z^KN-P?*8uj4qfFq64{j|YSObA_BWmWNBsSP`sbeaWa0-~3P&%igG^T{abBPA4+w0R z&uw$}LnW>|-syWCu00a4{@peVS`Q#&Ybt%z5;2)w!Z|C8L^&%_=84q~VUsCn&GF6fZyV#1;-Amnrw$hAR9BoCSA7|7 zujgZ95)1blV?QPI987LtPz|!gk9zyBA#F$+(fBUzTJTte~zf z+SHt0cfH8#fglFttLZJ%iKuhpj^ zu9>&u5LVQzbl9#j)UL^LqxLwS=k1;ysDB79mUOk)Oq=E;;2#72!?QMYC&~3|&+GF1 zj93t9FeDa7DG_fPa5C^Dq~x?9r5!{6=6@E>5M)R<#qRYtbW1hHet=dwQyj?kLdDxBVu4;LEq=sK{2c z^OL2Rlc0|Ij$ znbemSo$THxn62@5zZ#A|?=)WYr9FG_BUw3LGC2Osi$YvAWJFvL?>l3FDM{MW(%Zy$ z&V}rcSaqc2C;0<2{N~_ywJOZiCw40A?Kl7_rp)*E7v&cxAveOH$V!-ef0DT!IfgNj`b6JP* zmAloS@04y#W!o8`!`n^&14jT9bDAS1p9iq<9D4vp(*(cw3qssWaSCucLJa<+39%G)mL3-*>i^8QvAon;4f=7(E*_4}xVAgH(sPu->fP;u3=68#Jv~D0)N5YLZYT^>(o!qKfg3k?GeAPiP^mXPP**+7)g+UJC5tS_1v_m z%kbWdfO~D0m0M2=O!^$pCXjlBob5L`J+NW`+a|VWbCnP5T%sVY;Szqw6rp>CKFU>J z9@r5*4LEZpXDKAD)^7Tyv)j()Jm-OCK$BMk3B9|Ev4mKyXuP)Fsy};adEtqzzm$%8e zm1ODYxanHow(-;q?GRWLNhka}$_M1^+h~xk&gq|nKP5Iy+|mI0cC3K4{Bm}<(F=Ny zEY@>fgN^hT>4b{gD5*pBhw;l|Ww7TsfHE3yE8ah5UYRJ~nW?Eb zmr8oeB>5`Qz_Xz8{h!~)0nIo;BN`ILeeRQ6%18&MbT;emLqbOP%qK~FEkuRjx2NLl z#z>Y(yoRW&9c4@gLlbv_4{B_Ez2r?Nr#t|T>;a*QL~7|O4C$-T?gPfP2U?1BgXiUO z7lJJov8DU`dH%BI-xBu6v3a0W`$Z#@J@|`cnSF(9dIt2|L)CSO-(Uh2r0MBk&VK{9 zFW%*@7`Kh!L7p+;>#wt5f1s9CwZ4OnSAQn4&I3iAZrn+M1WM=ZU~O4i=JH@gNgpgU&-BN70mW=ARUdS1}fz+s1UBlu_k#CG*E^q9xu zW3Wl3OS9)f+M`&-GlR?lAgK_GwD>jWS?IhoH|sONd~&Lh#ZTqC%3x%(?uIhF+DjaE zX_ts1OmK^HgQsH7+vz&KNO>OE`!KIAkxv33Vn?R@{W<$h`tQk>|C!kBg-oCP_=EBK z+|g0V%MGa(!LL9#*by6EN*Yfn7M2V5-ffA#_tRpiHO?My5HLu1yWmcdY-o3RW`0;Z zTQowRrxwGiY{X*h?zMYQwib9kaD(QQ4l8*#7AXp+00(5769tU}$9I5Qn88Epe6wQK z1?Jbyp5+9=304ONHl~ZMA;a|^PGXC}6f+ZG%b{Jrv8cm(fdHglXcQ9vjpaQM-?=H$ z|7+zD$qpzj12#EB9wp44!B>%Rv0-wRyK#Ml0v+`d&X@)H3mU`9(Bn=&DC;f97+AoJ z{1_3hJkW}7*X*^D@FE1FCggP%ECXSz#BOt^F+~M1&UjQzqtt-j!wZVK@yinhV7Kb8b)H~D7f+&c$rO)#r6kJ zS#vLTMLQ#BVQ~&*VlBRD?RjMg*OdF3C#$hRvsr*ZFCME75Sho=kBiRUZQI(nL zg#$a_%`vD!9XJJNjYFCV6#UX5g(?H+HzIJ>e!|7D>UL?#mmM}9Sym66cVDpNmJ06B z?lhEe;aLm8bBb|A2(o>6OQT^S7g2nQNxO`Kc4LI8ghGA|%x8xZVQ%t2mM>cfyg6Bl zUi~P#kuTRq-9A&|+be;^Q^&mQ3)Yyp7Tc^1CI|OEpL4{Fg*+$u=qBUMbuM|A^bXDMK&I% z8^Rb0aO-i8=SM&u6V75=wrz4uA0L$;a6Z`)#;1U?tNBZ1Iq4{<0}%|TT1jItM9q{I zehd#RWhrIO^yDDO$}u;cC=TtD+V2xYS!HD?oK!QuRWwmf7E?%P*1hs>R_U=8nkHxc zD-$Lr8_1G(5uN4+;Z7F}mv9Q%RY-54WZ6BMwv$*|&0x|B{9VnOHtmm;Z=bHTTvoZO zF6A1|yDR^cWsin15Qg0n{VSSU?yG@t`j4zAi1FE9&w4u{$OXXt*3O2{gR<;kFT15$ z@$ImzNEch*EJ>#?ijIYUkQ$?!<8fVO`6YB1>yN)ob`;i-6UAh_8beVRBsE}CtPo2H z+^UXm3q&QE`S`OSn6+TL3V(`5|Az|zdWzcP;5nc?L`qwD!evU7b;xgrx|@|;F#aGn z&2Tv1k390;?2sh?D(6+I@y{Pq`k)n2}biL)-g-rTWesg9xOQOukA|^5W23 zo-^W_?e)tzu=v^qT>p#v{bqg|cg%|!$}*9k*u@l)aXIfkv7kwcj^ukNl{pYCgoif} zcAM09O#e7jYAq(s7^1~z8f9fN+oi!**Sq;%!Jhd~>RpT0%%KGWB;&Qgk}&XKD3%|5_!-EdfSNYb?m?%yFZ8F zKXCqJzph6f89aZ24r3mHWG%FKv_p=Jp$j+>iq*r+MKJGrr3)0bzc>^xd?^si*taEA z6es@s#O@PGmhd6w)vJbD+uhnlT3jnS17bzX-Pdyb%H2$hAAA)~n3-R3wp{HBJ))Ok zRYI$}GcYPk%DP*R&b>Eh2;+6$<>6<6+&9tBR-O1|AOxd1brSR!XA3I4^LLD8#;+{BydWJBxxu<7N= ztr!7%&c2@Ow5!w|t}AAa=Q{g(W02I_*8a=}$!f18FT~7{gKL9JvgdxnZLp-voxgi+ zN&9Wjjr&V$@)qs6TN9S_Llv}uzgMAw(w(uam-{lagv@CI+l zzG9h!-0gOFidhg2n6ZRVN-S;aIPtaz?ZV}sW)lUxIvygEXoUF)G|9bq{P?k61}M+C z)J;XwzU@Q_W;w>{9X=?l>!+pb=Dz$^I%qG}o$()uP`7MA>dTW4JJ0cOhS>zaAzuw4oeWWaO4zm= zC{O4R!Wk*}CY)=N2pat1(K?y2e^R)R?`qJXF|z1&yRehOldCN|KPU5e7+eS?R>tF< z6~t_uW?upsV9TW$>VHku`PG0^k}DimFNHLJ%Rp|{mC{)uckeT=^Q-fr^nto?*(f2V zc0Q3I7qxF}=>w(^hC^sa1vI;1zQ}m&j`{mt+o9cNX1GTT?Jrb7g=qc!1Lun!xTKVO z2JGwl&n(_Uj6KhHPolH{?H-kc&o*s@KhmFCU9YNDI6AWKwM}flwyG1Vc%7}t)&JGF zO%)f<`eBD%up&R(#+%vsijvR7NcRxvzilLwKm7cD9*dbfH6$#+^o)@Kf?%hMAFp+> z;^bhS@eHTe>JM;}R)FEtzr8o*v*}%-FtE*w_MNaXKSny?#J-WFMdk$@uzY3Kh*jQR zoOd^X5VBPg#SbJisgN7sc0X7llmBS{);w8kV_SOZ1B_cf7P7o_i)@Y%+U8^=e$Uz2 z7l|H>mGCQp#%g%fZwbrE*2ZVuIy40X*J_9*gJTUP?T~S;f{N7?8$w!s!9pzTY*BuI>A}sw z*#mW_GQgs%UbMuPz!ULtlA5C@)o*iZ_TDWj`$B_@&IE~p_SgWU*XE-AGUFJHJZ%}4 zK{#tW_eRX1aPTLT;M9H%$CP&xZtE8`t0HiO+V1Rn)0L_?CLpgKbm(wVWW}!f^hfs2 z&=6^$`xv%7`_y?<7d|hCNuJ#pj}w}knUPmoxw?GLBk|v+0QDuxxbGmw?K2*&`yfmN z;xs11s66&nCb8%k(|+xzp)?zZ@r$JuR;9Q8OAPjFG zp9l8IcP51~)vgZ2G$QPB2n$?FHn){Mqlp=UgVKlOCj8UV{|-tscZ5G||1b}egWxH~ zigfnVG~*3Wp`Bq0LjA!?GICit%L_$8(bPyWXR@m)p*or{G`U3VV>(qfgnu+Oz9wBY zfmNBsz1vnH`~r41;kO}$^Eyv39@G$trPn(q(vT+rRJn2nYI5_UMtw+HTS5UNfxUvY zBX3mAp0)jptRUrl;1Q5#700J3X$lc-=Wo~LR}OcSX=mb>TfRkv2JC)hTVVHwWR6q@ zDWRmHoEINcFz+Qx{3xS)p}QTzDuj?X-mU9LPLP}WxY6#+OLlmf69~L(WoeYo42))% zY>bOXN*Ok&u)|-*9uAyG*sn0KjrL!oShUkZD+_)_hz(DSE|4M4ot|Yaht+(3ZB6dm z{cZ5)9!J7rljea;_pOX7Qkfpeg!p5D%sErcPwsnMw-TqFgmGx?z*&;rlR| zBjRb^V<#q3vNuUrZ=+!(q1+h&S38I7_ z=^75DGg(O=XsYPvy1>SchDy{-8QMLYJi3yaGCJuZcgF&s!4enTqU{JJWe+IzC@7OF zh|)e}CeC<8>9A7|tWW7a4u9c-KeB2A3YM~u=bChg(-7#y!$gV?ZMM!2AZBAh<`hDB z!!S^1w6wTGAJ6g>8&6BV@&O-X-5=OD4M^_FrC^qJ+Lze=KcG$-e^Y`q&9?NR#d#hh z3;y&U&0eLa_>iPTG2cP$y{qKGhD`W4ZhqT3CH|Uu#N1OP z{;_=X*t5IX`lO5|R`-3`^6>;I#Q)K=>Tk=^fP6#?*be(J|9o%bDJ# zrhzq)MsG#L@u)fBdAH@cH$2wgg#+QLVcUg=!?y(QXq`L?IaosCT zX`+y?(4eF^LNtB2Nx-Vm!tY^a8w4|7ZO2i z2@fyEWL1kv-a@#-xu-6#A6bjE=|G5h%hjp*b(pprr^3gVivQhxZzp-qRU)&QTHYHm zjF9mCsP*zdvAGZxeLPSc!gcjI-zd=?9$NVGTdZ%+Cguw;W2%V-nv+QaqJA8_2-8e* zjpCZ2e5H_P@6Y5H?roo7wJtAcvxcA%(LWwbIBCq8*4sJsnlPMGG3<50R*Dg7VjhCCEbql{9ch7E=7i zew6YkaCe1etM9h$QKFg%NY4r!UJT_a%$?Av7vp&IFKj3M#pQ)Y*MVdicL|Rv5$+;p z@38$@z4fS`y|c_$O}|NCoF(I|9nFPAHi$jDSQV@?uHzq2!TwiR$o3@kKX?7)lw>h1 z)pBUz`~J8Y6fw+8ueycB}u+rbJp8y5VeOvk+t(%M8=BoR2(;uEnJ-Hw% zj7f+n2pFmEZM_Y#uOss|<`I1GA^pv8#}9PDBU}K-QxR$5CV(@R3+c8+=JSzWbv$ZF zmFNqEhDHE zgf)r~+3|OUgA|C^@sBp8?R?3;@&wHN_rXEHMadvK1d9=GqX>vSUb3d^_3kG%+|)D4sHA5Zfblv!`c*R+SJZ8+!~clKrod1A{f+&YK^ z0~3bee?ideo`A42WTA=l6Pfd=s36u^xp*Ma+Dv;nVXOJH@!U+ZNFsGw%6 z&~z?Qb@t}(CkgAR2e7GLLtmZL^dC6KgRIDDh&c^+0m-P_)jxzM=B05jjyNwm*(#Ua zAH=MZ!DirqNvmeu#@9ap`bcsWmvy=zBQ$lJ{U8mhWQ2G--#Zk8!uV_qcaSJ{D|$Y6 zaX>u1%9KU+6D%cK6*=(P(3tVgziV6hVmlDd9iF%z(RJJIg1ijzx3EEREBvu35+$Tk z1zOeQtFf`MU_oBqMg=9M8*HyBOU*az;A<$I}ruqjdc*etfu49cVSvC#E9Y+y;8 za^Eq~6ZzAEFMcx(VgOkIN9B8KDQoW-5RWCs$#yU-#Y&iYjf(}x(%hVZePcKrK8^L+ zY-H;}F<5Y9TlvO5vzeUp`8Du?mJq%ir5J%Ct{rNM6%X!-$gmn%3L3Q^O=oTD@hbr| zgRd=0J<)`sYWvm+(8K62P?3&0(SAxfYBh}wrc*dqyN1fzu`_g=?j=QMl%ABl6(}2c z-Tl{US79!nI+doj!DvI4qP75Hr_G|2-w&m3z!Vtg=MX&tnlq8rcs>DuY%%u~!Vgyb zXT|+`{{fp9_mT{UeUU*5N-=dPxUw0qQ&gRg+48^r&tz-iMqPKzamBzFq6{%>}6 z*1oYDt7G>juqx5d^ST`vPBc`h5|VSI!qx$Jk~AfL^S};`${V}`f9UQsvbLA>RNl|dwq6TCqY?@^$sYI|70anz$l+TU#VJ?EAt zuTT65A*-}Q-9T@5U6Jb;mrpXF5=x}h8?el(MM(-HB<>WhP*?Ab0(Gbme47JeCGN$P z2+2!B9(9MYrqa;J%7Q!VAnYk?vGzpE_h{~p40<`_Pg(YMcpl7Kztr&Zn>q?;A;+jg zTxUR1w{z&Clpabh9I{(#o?hW4jeJo=S?E4>VW|a^bLUYzbSV9Am@ilAdP3{ZK^)(8 zf)theYV<6^kR5hT88vngNSIvtEJ)Ca2`>s`>oS6wgveYbNbzO?q*&-bW5P(CeQkRf z{5wX;5w!5eS8(>T%1<*ukoCeX>DZ9H?EhTj4@IDf`@sGvDkbHcd2^pyb|k&g-@8Bi zh**uwt20QTmKmI)f_9@L9vu*rrwAv}#CF#_jh`$4n0JEmcMFq@O&UE)|cO7PJ~P__*OpjeHewP(cKPbsogv{C6O@kh5YKPrdUEBnsnn zTtUupo9yPh40*|PM9%I7;S znkPhRqx+A+0*1N-eI~FUjDAgD(%%W&V5|o1M-F z2Clw>Q7V^^M}r*D9s-g0V?U09u0*93wvTb^o~;B)$^N9$XkayZ`BrimObG5HXGK`L z*%BHTMew8)_MpctgesH!uMngAZ&b7Hhtuw~lM3M{)Ij;}&UeJS%qSHEV)irWZK99( zL61*jhbh+^*ro}G$X6PHNg<4-I9ctVuzlWobfx2j#DsD20kut3JEwSxVhyErJaUhu zFzZMuN6w}aN4o={QCh9BiL9~F(E?e+Nb))#C_5H*mv;TH-oLb|5cil6#cQ!<9n=KO(M^-kZ=@VG5CHI?93z0;}ZaM`#0 zjoHhscUl(r^?O?nJ}=n)ef6{?DCwcy`wuUk{k|vkvb7PcIR$Kd{01S(u0HQb+QP8N zDfkPB0%z(mt~$)h9hW_XXo7gTU;?J*PE{u1_QCI-_sPx|0>jRqxn!eRq990%I*!7p z8?nFyj#MWWrT^n84>n5zdT2N%TWkA!g=P6^m6>`7p9c1zLBG5C$D&GoJQPV(N-8ZR zD&bRg5#WO;tHXE=Z&&FSa3&Xrp8IgJWH*WD+XJcPJ2j{=VHw&`h;>gQvB0QVCbeW& zz?<+bAPC)^aPE|+?8Ch!++W9^5)>3IW%Os?eSEnz#}-I^pe46ioHl!Y7@4Tp z6;cV55k(+0aJ?`-Tv9-x;;g{jjHu=WB(TA~c7V0t8=wpx^_HLCdHf9`8&v3BLR+txa-UXlkIn^v zQ(PpB%FjyIgUbtpqOC9q*NN+p;39#U^-C7fZ}r#G4J;ih>@6Cq#vg|wR_t9dQDx0k z5Zv1^X+ z-W^PPQiK`bDmwB{tpDG4w`M(^ETEkD;o;$NzP7g3s+R}V-gp(Q_xE}ptMhke;`!@9 zLeLMk%NSv_=o&Qm*#M-E=2oAbRPs&&sm&^8cd7C2k1QV#55^5RxPSiWG%08}LQgHr z*fv3(2bBNVf;wgjyjv|0&;LHw_)Y-$7`5Hk+mB@dYWV@3Tv-=#Csk@$>y+=U+rU>> zY0G4HAe{#j(ch(Cx3cT*_R&OZ*e9f3aBKsA-SvN86C~gz5agWljlKLas`Sm9#jTc> zmJ}HonSQxSV1)`c)Na`TC4c6aP?T{>*TFa#@hj6ZLtnkK4zO}bt9hMnYYSrJOsTJ%#G zx4l(gvDyGlZPp3Eizf#c>p$1xP*~haoTtyHU1>HQRP=ZU(t}*22&l-d`qosr#7OU_&ZmoiHH9g*>T~-@*e+Eo z@V+UR2)|Q+DVit`8%{CJ2+t9>gy`i*;}?xEm50>-C6h2H+f;dHkEUVV;F*_k7>29U zoWYD$*fby9@fjy$`|s0y`V@KBLL^1sKh=XLu_>wVriWHlnQXgr^Ut&AugALC)BW4jDM+Eg)xm6PTZvIuQ!p?Pj4;SD>i; z%$#0BI;iGpf1;w%xT76OQ6e#s@Im|jOYPt9iJ*->Ki?S%n!5}asVLB#|88&AjV}`- z=qP;+$^+*OH9&}Ot;P4ehLO8&mjK{%PDhjlAumW1X{TfM!&S~`ccpPRMV-anTbqYP zvy1HOP?Jif1m+(M3)XUsPxoVgUKSQ!N-$cbG?Xc({#Gk<`9(!2R1zr7{QUKc<$g!W|Q5d5tzvHwv5jvo~^1Yio(;@DyaGsuVCyP@8E-w3d-uD z=irs`^_t*+IWscj@}!>tTy;}T^)8eJh?Y(@_nrIsLCCqQ`Ob6_hZoyG2*4tFw$ms3 z_7nJ|(7}qZay*K3MsDWPyT3o()BxvwzCyXD;6#*!*ki~`*Es3`)9iD85s!3}^V!*` zR%u6P5jQ-VqGcAg*e4*Kw{LkWpDjN3vgIJ^NF$tek6Ut0A?8GW=NlLCc z{z(v70M#b+CCT1R$+ke6@22Mmexj+H*X6&1L9wVQWxHGc{I37bYQS5YFC(TL)B#RB zss0V^FnsL>rbtomFCwgc0&JP})jtHArOm2|Cod=vUG?!4s6h;r1%%&1jdO`@UpBD` z3YWMFXZ^(XN5XgsifvcBGH--!1VIBX;996n=kv%=QMlb~is9duTUFxC^nq|IsX^tVKY2!4;2)dd?)Gu7vMdvrgax|0M#6kP=p_-;Eq9tQVewXT za;*nHC=1t%D&XV2>;n)f-$5`ml^uCFbveQeJ`OqZKiO)uBf?O_|0e5lo+P{Fb;z)S zJ|w2)x`QmIw&BBuIQ24phF35roC1nCr5!BRM$Asggnt)>8(xy}SF%aGIJQ685Dp=P z6UO_AJ?|64Cn}V6n&4MI1gaof;^^H}b_@o5iWEki#cLiI#Y3x;OAJlhV>P4*`y03IC0l@DKnlrEGZPpZ>1F6D+c{uVL4A+Y3+R7NQGkD%x)C% zndfeKRY5>oIU+CXUwMD@@@L{y{x)WEpQ+NMu7^Zwt@C2hG8&g89@4W;{})|RQ+`LV zKmF`T$Ma>ynXt|R*qKMz63c}zE=}1j!BP#VJEe!Tfn=K1Tl<%V$<@6i{!cj*Ur}hR7Ev>nc zfkACZaB%P>1~0}3XlC0XGB1OtuF|!$S3gsHH7K>17EZU5{~!y3X%N~yR*g$yo@e&4 zyoy-EGS`ezIFd!Z-eiRN7$M>=wTvOlpwym9=V}2U7~Jm(mv+{wkFO)s7B!75Mip+| zksI76+B_@nGj!!XBGpZta(CoOYWyjw$3sxAk`AH9)V5*9a5^dE#$<|>c_C-lRH{UXm5D_Y@TC9a_R(*q(O*fLCVUywD zxC|31{C=2Z2AAv6qi+$nHga%qT%~_oJ!Zhm954cqfew|!Me-D*3o))8GRfe!WSj2d z1!E~3-9)w${Z&pqgeK3bO98_SA+*v0#+Q{>`5-MCmx3sGTLwODpcIT-GoW zLhaL|P+{Ks(xD{{B-Bd3ueWtUdl}q*KRP-iN`S;%<&w)|4d^)ey~O;!ng;}Pl-th1 z2Bu`NRy%hW74j*Wm50eU)e!;=O^=O@r?`cL_Ws&23C0hbTwanLp4ukGoKGp~2Ak|Q zm)VL&(>}4hH7c~4oyF{U>eXeO23>z6ZQRN~6Ls%+Xi#(l>|IY0v4 zd8c%>t7M>VXmfos!lwmVj>GdQotBBtQE_(I38eTrok_8VStzQIs8qHc6 zk3XjKXAQ@2!3{UyOrV8M&pz3}#W3O=3W*)v{Pkb)LxCQ9O3a^n38G=6!QUv zD-PB|8aU{^H4?+=g^@Dmo_dumDo@4N&q#*POiATL6TogPbF=zOENj@L*~euZc!2!q z3KP%ZtB}SD-&Dow-9UbbN6H$j{1d|GAh#X{8rhmPYVD0hYjh~_9}P=DFhy@TO9+TJ z_b_&b-E8v*;4p3{;nZR4FP?cx350VycRZE6MDuPSS{vOFug#r6#Y*^&_r2iNJNyT~ zDa)6YY(aO>jzIRu{Rn=P{cTkWNY3gMjgq6GvT`uLR~16@@F(VhDQ5Fd4@LBTqSoVX zuAbalwE&aO*9>x*`44b3KHYkGQ)-~WZ87rXuS~UxLF8ag`R5-Jr}AuoNrXLp z&L?RnK;xL-FvU5}*x&W~9(QW1X}v+^Wv`=0@A8upojHHar=&lT8~d#Y!YS?FEyRo+ zQ!!Cxb&npjDDD-pJm;Q`gPHc->%NOWB*?eqI2&gi!{G%)LDet)K_Ei8SVO(2Wxoze zSupkxq(rw6DyU_7C+y)3zH-xJ6phb795GsZVl6p8D2?M~H%E~8&rmW5H;hW$H|a;$Dl8W!A%c|+tWFIPb# zoH$NJD+@C3p`c5)Tcfa6<^N~@u@mU$5;>9T;-T&&L6>ue#Rv(OQaMQACU>^!tkoS% zISL}~s5)2sK#4Bfu+kjzWAw7|6gl-mgA9no{bK0%NQD}wVmrckZeXLiu=Pc)S2Le3 zmfH@9C@sum#niHtY>yRS6`DOHIxSCI)ww4ErGHUtVyaz@S&?#wLG3*xAuB|WDA}DJ ze31)Ws1`gJt}g$k#%&=u0sjlUH73L``?=WU!!8PH%_lA>ZpRyMQ}rliQ+Vuwu!kz{9_Pxb?p zXGfYVq>LU*4*3vtEC(e0=BOq`kD*OY`x9pVUw?*`4L7t*&Yx%MRm(+L zum$Wc7+F&bSio^Y)I(q+6^V3r$!C!05HiQ5D8ufMO~ zTxkGiSLU;gT&ZV^Q{P14dl*KKUV@UmH@xgoePIHLuWfam(m$5y0o9Ea6ihfW3XvF~ zyE|=_7N#Z*ZLUeC_0c-95^q~ki0nQ?@NJER@i@&vz>+Ex4j6LyM~JHioxKzMlQ?P? z!i5P9uYUqR&Urs9%vKrw%JCm*Cvj>eMd7!pt2w80EXRR)#H30Z!^Sk@+;4CItQ*`B zEk&dolZV73=$xD?wvNZt(op)mhrR}0M>{I`P%+$tO8XrgS&QLfVy;(zvTSF0Usg$i z80uc7IvSyPqKIR+(Q~3iewu!!e*Eum0jqPn@keN^*WYRTbpLf@X2p(EOUav@`26_x z-Z9EQUDy5563B3(i5N*LYIy6_8nDA%4NKfiV_0R{3a>;g`()NtFmw&0)e0GlFhmj4 zJWAVfH;Eb`}iYvrUju+4F9;Kp;&-*ugi5#b-6MLdXTDz2i{e^vohR{-OglDLQE9D6{yH zR(2<&M(+DA|IL9)_&+JjjjTK)Xu@l6flM5*)ycp7d?TmRdUYLex*=Qdlunw5x1P`4 zyl`Y{04(}Ht(V7ba;SXY`N+eGxS_s?&lY>Af!3S9PL0(+Q$|~!ImtBNKurGaf2n=( zHCps?Uj6r(U){5w?(E!kJHV3n`v1o*OV;RW8Wvc;6;hehDy9AE{MQ~lTk=1Rfe)Wj zFJ3l2p7GigEcMxBIX!|t9imguNSzAzFCQK9 zW&;lzJ^IVfQUferPPcaG+?ss9W8CucmDC%+&{usS9w`%A-cZ^8Ts_f2Hs#c90I^9* z+A7ecrRe&zB2ra1FY3+~+OevGr_ z^%rwON>>}*UmFVTe@7A#iMsS_a3?}U-nX5jnqXswTuN7OooD}LQ_JQIO@A0+UE;kz z@At@`qD>VrwF?xiFLK5Fv! zdNKK~e!9r>AX4;Y;Lj zjHDoHrokdIft1s711)E1nDRt6k|j5m{QlM#fJTA;-une0m->0<78+q|M`r$z^{L&V z#^~dX#kr+BT*NpTY@c7QgMc}9a7|2hvJrBJRyrc!gdgTpJGik}vN^W}YIIz~2i_!W zwQIes#e0tG(Nwb3QODl)K6wIxXgYbXs`!SGMCVJF2r|wK%-Pe?)%~K?>>;Iu%=pFq zm8V~?E)S0K(w5e91r@3ojk0JdYK**YibYZDbxBI`vXxKhhJ@I?G|+l(d%4f#Wvx7e z_69|R=Z`c`HUj64s@%Vv2FF|;wjiuw8fV`?^>A>q`&gcr&;D_`Dbz>qOx4vFizw2x^=;y z=Xks#6LZ>MH@92+Q#5CCue-adt%CPt1~~mG1zyz0w*aAF{&p!9*N0?{wVqEK9eY-8 zZL<&42(|py1kQGU4B3+AKJU#*9zKFf0KrG8`gM89+MJvoCo+GYtph`pwD>n_30eBR zCtHumN;a;)>6C5GR{rs6y2TEZm`p%a>h|(@0PDVZLE1CR$3KH)bCecCzts05Lp|9q z+f+Yw#O5%6d&TJaDN6hMqF4XFTKvV*6q2>e4n15~=1rhn z)gc8TZdUp)Q4edegHb2j&zAqYTHTZpyGQs(r~ybHGw1(xT^@GaXx%a!{Om^5M!9Qv zqUyrvmay^3sk-P0BY)QC)p+$ixRP>k#Z2jo24K*4aBTQhTxt<#tiHagv(9lGm?u^k zzD>GLWYo z()g^%{w#e=BwU8K?OSkZLVP&ZTK%C7#3?vt`C$TE-a{s5(Ot(C7{UpmD*dfmy))4v zp|i+Nm7_Vk(rF^)2Aryv`*AkQC6NPv{F&_azZG+AM2Kb6w1_mz?LtEQe-=_V!3*HR zANJ(%7ZeShokj0Gdv98AwzUC(Aq3@2|HyjVf(e$50Irk4_G!FnTjg}iO2fdXUyTIU z2OrUSx;ILJrwQX9KG%-}bH=hHGP%mmfW24wZ8sLOlntYi``$8zDYF-&7qwl3Au;xR zB2^LvY2rL-6C<}azHW-ItO&DW2d+60Z!g80OHc0b)Df!9q|+EIZ}B|mdwLXc7!_BX zS+U620x%xlB?NCKWXje1bna$dtRSe3`Ld`EV*ABtR~|geAHjkdoAx-CVs<8v^SRvjF&9V89j*p)FQqO;=A-zWyUfj}|RqUen(GpNAm278u7w^H@ zVvbj7L{$w_z9fo|<&<+?$#m*0L>qo+vzwX5>WGe17+Y?l_3lejH#hS^HA=lds)~kJ zw;Mhwpr*@rZUtBA3{g{hX0E;-%-noCQ?UMA$f!1pB)3)rWpS&{BZZ@0_awr$TgWg< zW%p4o41C!tZ#4F_C|D{>JmhZv`hG-29;=FI#ge2NQSl$m;}SZG1m_^2x9ZFCsCuFmlG-0;Cu|vf zRzjVcr0_T6eZ30O-kD(fL!Ue^qWuUMBBf}reb4G_#YxDY$)}(5(>#dOSdoBp@Xz=c zUqhA#k2{RZ)gv^}*hLa_g`QN5znGbd0~`@PZr#D&Wm*IVJ0+`)81}SBL4SkG{!r17 z^0DoE>@@GSmb@*tppdpD>oH^e_ior4QeiIe>4UeQ;l}=aSldM2@|WR!sBFtv|CptE zh3!1@`o?9VB9mHToU{<(10kP{Q@FY)>x#6G^9836f?FtK0z){q<>vQ*u@ax2cEu3T z1dADH-+e%Q+XMrKjnT9zVYYBQWUl|oYBo@k1ZA-pY<+kz0jR<+!#D` zoWN=}%myc8Ee0_mC0^D<&MI?}gd`jX_VHaIYa0@ePlgmPoHN}_e3lLh9YWr?4I_yg zh2g^R9P;HKtRc}XRcg2MjR7Gy8?*7supPuynFFO`F>qfOSUG4e8SY1NWl{pdkAIjW zvF6?6r}D((%wwJDvMh>6U6Z6_Wab)F;m}UfC63vc_;ecM+sryx&+Gy~0$W#zn6-Ht z+zPmCXC)q{3wkdXu^pi~Mv1p${MbYvSDI~t&H)kTif{-3Y&Ub)BrOK=qvw}A0FZT$ zSrTZpBZ9d3Y2H7yR}40Rhgvf_`Vy%3LH8@tnM;?ExLoWKh3W5 z>ONO_4Y=Cn)G@eT^&REsa05O<2>Fg%8?fg;8yt313$3QtZ~%fKb1>oK)C-hLk#@B! zt$iTyaoiWV-fA^I46c#XJEiys$< zw(sTHy*(A6eQQ?YkD6>JbSKnY^W~d|C|K_wT&Q?$%t9R$=YfIF;13bN^hy7&8!U%~ z?cox8DPf)2J&hFIk$~jKHivUL82s8(@>Vhk4slNGLpoU5`m8kGMTXu{<>{8w-A5UY z>{lZcO>BY8IKF|8XSbHaFwmJ=Mz!ERNci+{!uEEWR^1WTZk$O#n0;MMnMXm$;uP<6 z2D@qlPAZ9*F{Ncnvl^*9aJ|yxe)F4Qq_I|}=+_Tq^0p~Vgl(ex&zv!j{Mx1+pgSMyR8`wa|@TQ;|~RVEu<)1AHP+dbb7&l{qlIq_kZ_rA|Ihwe>)s@=PLz*dIv0j|B}9bo$-M5>>jl&BJ6wT z53P+?67N{Ix?hT45{0<~k90bfl9F@J9%4gAAOHIaCT5B=ilep;j0l(KoesY<7MS|` zhFP?NP+;Qd;FIz-mQyN~KV--G&|yu0%B~kw-0v+mVk} zCJ3XtX>F{4M1yASrS-lC@Uo8^zi7Y zs>;;(Q(zNGu2-GL?}T3LAgl2TC)|+8597Fa&U2?UISaFBH-xOB3UJZxs_ zAacJ>1w3MXY95-i_)|5mE9Q8AFTqu z=iWJ>7)|hfBOiF%D`Q#d8dGzi$0q2Bbt7!8+d6g`0fgO3jyMIelD#EToaRg7hiRO7gG70un!N19J4=31H z*k%WwIbNFEp_ZXKxI6WnS8(MFDdH_CFQ%e_l9FIvsU;L=^dOz=z#ARV!=zox$cf<&%SU+o;m}sly}Q#VF#A-exHI z655W9{OTl{q4yy!9n9~zHDVpnMKAlmORf}ld&#pfA%Lh$+Q(;|6;zxs%*(?gt-#G) z>Iw{UkG;f`f$RS9!S8rLSIi2e7)@z%U&gD<7t25Y%s|!K2(jFNzkmxS^MDorHS~th zR=SYoE-L2oZU={WloO~Fu*N6cr_*XnHXpbwmfP<%R5iJ$>c&PYw{ay~1{IR}3S?MJ(h=L7Ib# z2y%!wF#W|i0!CDBLRe?Q(S3}cwDF)HoAbbx)q_527P=Omoqp=`$SV^2?q*ue4QwuV z2D|_M*3y3{h}&QUM08LVIRPbZ9p-(hKxNuzX8b5VjgY`!jrgh9%T(&cnyw!mjrS*{ zh&N1hr(XLZmq~`$w9*0~idd}(-{GPnlSz;#0k`n80qWOZ#bly;{42==Ww?v2y>Mh` z4yV*Jc%QV=TNco zC7#*7YCoRMd7mkatnl@YS4?mS$59AAFdaqL*#wnPAU{lr@9graz4<;l0x&|i0hj&e zB*63#mp&PP^yG;Mi$3d16t}rR+PQn?@EL*a;3H);B1ya(ADd_%LZL8n#C(}oCuw>b z3-izrmuu?isT3|Y6f;5w!p$L?xZ0@9O%tl?i6QX_8jkD(WV?)1=TxD>LR)?f;l<l!@mDQDJ2g&&y9gxEB9sA~x zbdFKecpVHr65+5T35$dy10kI_it3c8eBR*SAJj)ZE)uE*z}>`Mh1Hzl_b3VNdmwja z`Ye2b-l7~dDw+(XyCSw9I!-*s6>*>VNT#ls!mJ}5O&zSJl$XmFcp!Obad=wQcD>c& ziqY*bP}#$*?|<@8Ox%~Be?%xcS&ewJclY#c8-#q*HnvKtIKjbzv`cg7Zqx0WJm#k? zh`mIx7qsQAoLy_I-2nQ!)R^aA&)<23o7OD-nsW?S{;v|q=q^m;B=fa?2 zQNRlNthd!;kFtO03?!KUX}Mb*DhTi`?d}>dl`m~BF`@F8Kd@3wyn|Sv+#TfOlG%eE ztLC%rP!16nL&KSz6t6RE28s$-jxM6AJs!uZISlWWpUw@{^mOIyKd{zyN%mfg!IiMe z8<~>f77(%!?Q1bUr@W4Jv}qECA3~QLC>++l&7`WFc7BhIatUk`IRNznWh^$Wnc!Y3 zq)|ByVwb}ZL4;MhQh_FNR-HN2CX-fo2U`L#%f~^6ftM$}b^G^f*1o?d{;&U(z5f)D zsSEQM4N3qgAsK1=i%0LYHfZSRzzcv%uH)?N%-#;a?;DjY%+$HE*Gj15@)#XKmS&C#m-YGE|jG0 z(o*>UY5`zRp#Vh_p~s1`|CY-6^i~l4WNm#tsgFiF4dLY)>}~W`YqEz?dGTwI+HrcUR0p!t<7e-Rgsb!6#gWf7KQWAWXar~Y8v~OHyrr|UC&JcABSbD6`{tbDl z5@a!++Js4F483)12uL@})uaP&{!`QIqWo6buT04I3^tG}cRB?Kvu5+s(?36JDj~-k z!0JRX@M%XmqPS}jJZMerT;Oki{YZ0Sd5a%P|8}1-LHu(uKbWpbYqjF8W70Q=9%Nu! zwT)_z48TK5Z!%%NN@I-oYKf5y$%#4EAGz@3iaz-ER#olGcUKPfVOf#jw=%T}DWaKL zp7(O9D(K8E?)7lP#7xNQ^{a3+<1t)+%6R6luQ;;d6yn?MFHPZ7z2bCHRv%QIBPNOB zR_=ySsug#0)xj87G}1qu_!>OB{l8F>*TMHA-}ET)H?wy^%3gUJ8X9_8ySnb?GDc}< zE@cgWv)eYho_cSvas21kX=%1=ljE=N`QB%`#Rjs`?NE`Lng5mb=voa5zzNrf^dMt= z-kZ@RZOzOU&jcT5LIluHH~OFM!v6jhsAM++8jGw!$NEp|h!7exjxT7=B57BGLX`$F zd%w?P=XF^Duu9E)1(kOj)zi~dj84S?g(R@S_2h(vCi(wlxI+FoSsQK*1RFi~S6QrH>jXK|)^8*9g|9=*(8ZXq_r(*h+-1lRL9)igOYQ+ivYA&${9! z?ou$VzS!4mi}lSoP4_x1|M&|aF;5z5(q*E_^M0QiZGfkx zPt8qRK(|RVU$Nc77dfa(Z~oB-@PnO%tIALlo&67Mgnh9!PG5kMM@KgaK%k1z#|r?d zc#xoDP{OVlAm+ICX2Gm{Y&2Ki*PBc&mB3ek+;;O^n9mhrA~}E*0!T!E{^8oI>1FW% z!nm7exW|PHz~swpLPA5@#8j#j;H{!+>cKXE2cv!}C!qI$;xz!@YNTmHCV}O?gJ@$J zdi)b@N+kk5Mu8*Ym2WfufE8mkT@hz$_R1#V&#%uy z63}`Ku+}#UTxl3ia40#fEN`al&LuHP&% z7-IlolTXh#A;y^UeAoPgs3iKe*rM_D9@!J0Ym@iILW<`bMY+8K#>0=cdv8HGm4Z}G zOi-;q3=?cq0C0S2I{X0DU7oojl@~GfEb%x(c~Nn~m?P(`-|}LLo>^3K^rMrl0&1iD zX9Prn+15h63DzxLyUgYwe2-k>I1BE%q zxi{UBVxEZeRJHeQ&$~V;r}(4znv4MPiCuE% zab1x%LhoIHN-QE0@&I(N`O_u%04<_{hM=jIx+_IbWNsCw>R5OW1kGf$Ly~~}r~G=K zuI5paFZSJTlKdf#{R<60cKm=}$&6$Kn;c=R9+1ddcmy=pZlhoUF{9w%Bc%Q#LeN(@ zuMbYT;0^bc{zj?{TPVaoo-&YUu{_}{^igvBg^x;q7(qBzuOfwAy-APd8m@&=#Gnij z74ocyyGfpa$y7%gMRf{*!lZ&hvQyUT8ba7K(o+x`_aP)i_?YaXwiVt}fwx2dksv(A zrm%v{x%Z43&D5FfHPmk&qE;qK+0AkVk7XaYPge<&#>q&pgbnMpYoMYJZ0}>G8*F-? zSonSQ1Mk0sgX*O>0l_G2ccz`HF!7Dc%*S%-C8j}Iignkyrp9gWKa@cFJkN8cAD$6z z_$m{kh1EbVb|se{Ans&uwZtlI1%LoE+ZW&Q(})v|6axddp)83XUy5!C1>2T?zA`Q5 zT4{?sMsrgLkllW@J*EcNTKSlDgXuc45-T~UjRz-iPcAv1&<`i z#2@9G{)e(}55=njhKqjD`oF&vQm}RFeB6EK;l{KK{ub@5JbQ2tX$&t91aC&d9j9nl zDVHghu)}auc*PEf$^;^1=P#-gF`X=oLvZLt4g%@vk;1H%5nk>Baz`NY^F=KJj#QbI zrBDqvINVd5kivokXQsEI>H&Wl4l#hAi>K=iTc6EDJ?J$9pq7`W|NY~D4G z;ZV4I$rHhDDp`#EYkreuz^yThk@VDGDjka62&dqH7L=|Ohbwebdpvlg%QPi&*I7;F zQn|0AFTb=cv4N$+nEIIH?#NDi5Uw8ps%aV%S7ZYG@{to=rE{@{FvdyiAMi@qD&vN5 zvTkGdSS~g{K_}WF=+YC+&wU*P59Ir;9@i<>8@q4v$=M`xpKs^K7tEG}S#;Ugs4b#6 ztXQGpq@oR&xptRL0!Cd36H&E=Rex(=>i|$TtOr+}b#F23qD9k0H9zF~%p99si^W$| zX&C@ibn%}2$hL@pz(YHds{kw6Tg1brl`U#h#R!m~S;MfO3!D$at3loTc?NchWlJczZ-0M>*&X)FXIwGetSy4#)h>fhS@R49r2)69h8joxtgl zkQ&83wQnjS<${%8g2s5!5!;X-bQRrMLSK%IkF{UIpU2v}<;5aaIJ%REQEg|@-x2fi zu<#_|qO+spJ+fFav?hlfB&r^GNB##0sqM7dr(`e23^3AIJW-lj)-`3vcUcoscQG} zV9A_3_S69tt!R|7V!kXFnm|1vSK!*p5dW9u$*SC7Te^g}{a_CM(FOwr6`+CT@$bwl;+1~GpOAL~;~~e>Em$p*?Yb=!B@+-wU)E&*??;5^E~ny!dVT%Y>K) z_5*?{2#OmfiOS-=iw!u;Q)RZ4M@65+t4Hs+Vs#D`Lem*U`i5GEH6Oq3a#)DVDald_ zx&8?N{mzxtJ$7}OklKT873t)vaNg~*>S{MlV5_?TYLDlBQOkO})qv}UEX6#T3stI~ z#L~OdxSkhB48CVvRj8)lIiPdD!0MjYIynW}<>uJZWzO&8Ku30bQ@}e*80hBKQH(V&mgJo3Q)Q6*hgSLte8fj9u&ndx5r*y|5_<^C#i^}rwn6rQXt zNyb3Aj%_C%f_6q#YjytI2OZ9<2DC~4D#m!~iZ}1K9`d7!g4i-hRJwk=Jzdd^oNnX~O13F_&$3GUtPI8@3i%`xlJpU3{1t{45)s9yR;tIK+mSeCBkG+30J_r zsM*&2$7t^rj!)PTI)$1|HVf4<5trwNJoCvqkWUFCXH#d#665uNKZmHP`{Jf05>M`h zL^`ZVvIxcXxMpzQuR%eShBj0YBiJz4wYe*IHwaIR<~`*)nTq zm?%p94ezJqvp1%2t+O8~Ue2#vreO+Fo)N6IYa7PGaS~`FzG5dcJzi$|B1U6Jp@e+W zQ{l=#Wv1x1TSLzm{uS{PUbWEr4mKuxkYZiST^6~bKC1=RsJ6)1ggT@ zZ`%nTJGMfWiuTru2tA8()6}r@Tf_#^7^lfr*_2pc4fgB6uvQkjO=@dB3~%f|3ZY#A?FDCPHX3XT}q~0!ceXS6G!y0jX+L zi|m5)x7c@#DbcnWox54asaLK&&VFY8%&W?wl~m*dj6a<60VMLUp@(;L-Row2eubn` z-{D-2_0=C5g)H}7cG|O5I}i(~u{=@$H50Bee;L*BeW)R|;;g`ECkIL{HG`xuf5s1mFwIz#UxXqv2e$NZhX zyE0_{?Q9cv&Zt-?hfF5tkgsD}F>4PPS}eX0g@XO6RXn|h}4+`P!EC) z;K8Z|L9~g43O|l*1OnH}U=>99Pf$}KX5_2VID!{gT*=ZD5B4B$5#>nIMM}StgH0`S zZ$Dpc<91pDd{U-a7PZ%?{+{qP7Z$xiYOe?bxj{E`P?oCb>G`-Y0ZVKZMP;9t)IrO! zWRC>}GOpcLqnSN$xZ2JuoA>3D0D5T#LP(VYx~=}mOV5(KPxT-*wgsyB(%@g=3QDKx z&54bo`N-{=07oNsZin6S60kH}fz#2@s5wR~3rO9>!rD#pP(HIMwQYOe^|=9=;&S;v zB5HmG((T~dXg-E-1!m836>}PSE$6Gh&gQt-M}4>KxGfp3__<>2WF?ZWnV~2rXRQt@ z1x3L=jP#4~Fz7Ply)OPM`%C@3g0SdrqOzohMKZLjAO1HE1B&AHnB1Zq)$ z)uV2+_mnK(%{mozvb9iy^QPex0W4^LL=O@j@HSll_G630tY4+hRL`DmJHAv7SDY6M zXNR}qLMfgzQG@5mS*G{kDE{5t@iJ*p2(cXzo#4D#FOb;L6j)68)sm;%B9LKr*LJD?HB5u~_O9V=1WxT70fROlsyr!nR z3fMRXYgCvjPe~aAf?9w;<=bK)vvYB_HB_Vs_O+-~GRYs=`|rV*1$zpaUyKs@JnOAb z02@ej$3uqX4DgS(p2FD>0V<@FC5zZ+ECBggMb~pu&3J-mJwn)YqEKtD-{ilGcaqC# zYSLLX-fRW{_$YR~P|Ix;2)xhor}h9kA7a6{mRW{bZX3s*8_*P*&B)AL{|6Y?>Od(Y z0ql4`ChzBkU_&jNpWjmqAgNSmb1+-6#c4imJpk%7YuZ{6N$Ef|W{UowUcN+f2S=XM zLGGh&@VJdn`(;CwxjIdcC(2dBJmXef=A zyfREkecoS2EPcOJ>TKIwuLPB$dN~s)Rj1OB=S<}(|9dvlwyOjkJ_82ClpUZZk3eI2 zp!dHCu7nQ@5+;!V&?-;^Dd~VT&s*`I!NHQ?$BUMR#>E_*0n316d z^m2S%PtC&h105X?87Oq&wQ7BShNb^`h7eq6BXXU?UZovqvlF<)jPxhRfu5dRM)J+g z5(i7rzsf<)yWmV;0DO=-x5!UF+t{3J0jsSc&K?4gRx^C7R^mx#U!Z@jTvvyRg0dMb zmIgZa2~>V8fjPF?l@DEt6g0NaD@!mx{I3n>KHkX08aM$00dM70Rj-=>EPQS{S9##u zJUs9Rdo+&9UI^AG-Y8bItN+`7!|U)2aXXY%4{-i@ISqnsXpP<0;bNo5oh*eEz{kb* z5{HqIW3;{sbxl480X$gz5KwD=&Xfw!?LgvDM;t%|@ERHz(9#@)NN@X>rz59C2+SB! z*_)$-sR`bjmgg#X%r$&LX-w|SjrSm`Q~&Hv0&kxpcqh9)fdq-4fx}M6;Icn1j;nfe0qg+0bS#+%3|))FJg#wNLMVq{|`3d-&tvlsMV__^q{YoI-uVD&cdAa zIe7iAo!7+I*cK!l9Gv8G0Qlg7MdjQqd5kFo`xO&5w8W>iE-SS#BI4@>=#J9adJeAV z;(UEjRc}~gV_}*QC?F^(*p!@{d=D0(CTb>EKpqeT0!**o*YyLLy{K-<*fg)$uJ8V4!HtR$AN{ z!2{PZYD#A+dwn<{C1iBM94^z1+sDBAU(g(Q?(eS%B`ZpdFTmPZCJK&AbDJ9*3$gwQ zK#2wUHxL~XP-6jU#iYj%U&=+mv{6s$LWmzg0^5Yt_vBXxwR?qk99E0&!ml<> z!QFmP*@Hl%`Qeb|?0?IBo@3SRfAWLodK9@|pT8(G(AT$@+WzhNKH2}>XFJiwUZ_#R zG2y?)e+vbTFXsqHAH@2B3R?Dd1?av!cMuP>65+ov+O7NCp~WZW+y8ZFO9*&D$`sga zpF4;Be?I&F(>a@D#kwuN2pt_AI##pgJKkWu^N9H!`TQ99fHo)KQRZ6FuXUcOX+4>6 zi0ipMJDyNRSu`Pjx<%}S7G!y;_0`zEbSRsH0u1S25-`PcNgONHzA(cAg$EB?JG-O) zo*o+U6}jgCKIJc?mcHnE#LKlA;??a4Yy|$c_+{QjWUyRh?-?Ec9XTCKWIw&n58N2e zM)d#0dB*@ssXaI<@bN)^T?l}Vz9=pmDE*1`i`(f?2gveYDZk?dnh|2@(%a_9N_~S` z8#hKp;tvH?alkT8tf%vpTA5=3kzM=B>ACQj5P4Ece8O;#Ox^7Bx9_d9F_QA zUc$n|!-r4iDsHucLS8Q|apC8gYl02cfc>trEaUMTs-cZ5wunadbn*@gk z0!X9k{|!z67#ud%AL!KFSnsdBE(hVDdB20#I5SXxzW}EAHQRU z1@n}48Ymi&Km7gyJL8S=KAr6EGNP}9{LfLrpE$WaPM&^N9%_zbeU`RcL>My*SK0T* z95qc&NAt+YGkaTGQ;bYZ)}P74#004m^=Y@OaeGg9Rnzh~x58ebKu7NNcZ~A9Kcu5L zCjf6pZH~9I#7inef4lc-fGZ`fM)yCS#VZ-E-d)! zvJtQvb)NAzadKDj86F;Hfq{YHjxk*i|MMry|+AZfg92ral4Se>4<4l14CjZ+Z~`mkv>8G+u{``M zVIN1~&EEMMyR`#1oGw1v?N5r$*RUxa#DpScpBwr$a7?()6oCV80@^{~e@}v(FHnzf z;%tv&|H`?t+_gwiK(K2sn^K(^JZ_v+&nY>4iXm44^u4mcYdQG&XH!yC;nzR>Kp)y* zF(O+j4~q+(L|1=Tt9ndH!{o4N-_e^-LAFv zc6L;Q`UgwfDPeeG#s{HyLRC?$+s|=4rm4v*_xSiY@c!XpjM6uG)*rNwG6HsGWrY*` zNjBj7_lIY0A2;^j1VbH*dVK7}5VDz~*Tm_Bz+sigPsZ7KU$tv!=wAJ2)si#{^md|x zHX>PIt71yK?g?=C2$O&hEfko__B;TO5v{%?POCignbNEVkGo2ldT_7nVpwp9x>kC*(7N8!kLu{bhyJ}IWwcYfS{;gmt@>; zM~XxgO59;!(%aq~O)ZOI3LZ8uU#%>=7u3nKy&mp+9&g;&A0799CG)ynUV=SsD>#9$ zmg_WmQh3-91uYl@o8T{+bCO@cI{{3M|G}rgBCPGDk5${ODS-p~d@MMwl7nR;xT^6(ePJ4EX*7s{r zg-oP-e#>^FDyK!VeN&*miFqo0O4qFO6qdkkx+}l<(+(Ct%E#W_H>(n3iRT8ie@!|F{4nzEL-gQrW4J z@kQNRgq6LEOBj;3_TRFcS6~$i^tr^7z6dwJ2D3Hl9yc)DVY&0dY;|jk@!M#&bX4jc z%Qny+-CYD*ej>}s{292#cJXR)kWloNuZ)Q)=qNqj)IJb-!iPqr=yoI|I71yM>~Q z(rpsaaOxIwJ!4;OqmJ~d`?nEB!to?w)JZCuc($GbTYfsW$1s=IV|@rAr;O**gAt$L(S__5hp+LQH?%)_@lw69O-j#zzmVV7S=9);v(5+1h};9S08DM9TL8J~fxI z;vX+Xa5frq0Cb~k!7Z!*j6U;hPkQ|z(nJ59zWajxW9yRb+NN|*sTZ;7`qYb-RU?SBTpPPx~7-fbKms9$`%aZ||tv?5k#e=zGnqh1l@&gNDg z<5Bvfe2-N^CYjHynVODHDlCPEf~(A!UAwS^^-bToQ(Vtx?AgW&50`Yqoa25RiceAB zwctXgN}$U67`u*mV57nMa-}i~^rQk$Uj_4U&-qTKs}OatuJxb?3FymF#nP(8{r(&* z0gfJqC#xN$dTj_RK}rE=FIT2D1gOmta@KD{lUV-RiSCRQ9%$KKf7sTnbN#$%eqT?t zSSK3LL`wedgA#{N}FJC-5%pz)Tn8LdgebuS=kX$w$Ot zt{NP}y1O0DwirTgg{eizVpG_!Ua#rsb&-K>OP6qL5|Ugg=UAZgA%SI)Vz2R0X10l| z*O}q?Uds7j5)Q4B0MZQsk6s~;Gi7)()J^6#G?BqV$CAv-(UgXkZ;q@XP&U@~U2yMe zuCSEzOwX8c*3sV`g{SWyN_T^$OSdTkL-2<`6HFF<__OHQRd4x9NpUmefbq(>Q6=ts ze)JjcQ(U@w?8f)_x?b5PA|{W8>mH&TmnFfSaj$&C-d`;OYFEqgDV^edmVO%z8)p4` zqO;I1i`3^9!`CyXmp>MxpvoVpxA$*1yvujE<~3O}jf?F~X2hrl zJ(un=r^^r6g)T|&g*iN+Dv#^}0~LPM{meyXJa;iX8cm@tMV6rwrz`pLk*3`athgR@ zm|uJ7?mYR)`H%SDOB#p8G!5#+tVD11&7tzMFwJHuE9Pny=%1_DzS7DiAr5a9g`_+? zc7a_BIndVU&^-f|(qdsmT%c%&0>tS!q*!Ov?fNSHEPH&YrsWa_tC@#x4#rDwY8rv9 z{UC$WnJD;Ev5em=R;oJqwa(woRZEn#_qa8|x&{AB_2H1{>^7%Br!Uf@sk?x1YGdI< zI7>g}cGPBFNj!-m<=j%W&0A(c#V_kX!(ib0kq_`vJXgNeTuUxfE(+ zpPhv~YHb8XZ6rf37HTI-J=WBB*lbOId%AhNw4bfA(qRTGq8UJLTx5U$%nE(plgYkk z^1Q$P2hwY~9ANo7a{t{HG~I&(1LetWCyb(UFjZqQ@MlKiiH%LOia{uF6;BH*k`Nd$ z4n0A?h6sl9Mv128jg9&{HKg#M z7(#TgG6)IMi{4C_n%Bt!x+pBx_2r(qsr^Yz!^p4G21%(KM5S2C#y=JZgb+?ES03Fe zzwxY=Fy+zE-mHJh-M`tTShIo2wvBTaq{294;0=`FNQW~V849B(6wjGD!ox?zczheX zTNT-$!x)dYGsY#jHJ)Ji>UfvX)+#%M#mEFRSFX|@$EC0&7tu<#N)Q`7B4(CO{8W}+ zN}j@UWIaM}{^_2N@aW%zBoS=yaGT%p)aa5pE}FF%L{{Db93%PCXSWK4ga2%AdihyA z3`uA1A7sX;AmjOuXF=BvKU@^S-W4td;5^+Meev&}ZMII=#nnpmze}a^sDbm(y9Abn z8Pu<@tzd|6qxW_sY%lL!#wzT;jX`~K-2P2bUUBnNxo*#%v^7Zv?ix{^`ORcL6bD7^ zMRpn54mq;W7)EDG#7cxcHtKXbSr}A=gsaC2QV*Wz{3luqU-`9F=auYHY?^ z!Dsc|yW@&Wmb(J&)4ebY7Ml%(8kevobXnex6SH zhQGV|6Hdr0OT_mcPUA)IIb&lq8a_p#&o3|RKVE^1zF=|jxCGpjyA!uV`N5z^slC`d zfnIs)AR2~y+-YnylRPFKOVs@wOx5}vodRqbodND*>0PYAAk6STLij-l)w8<2brP|V!*^gTE3DutN7nkk1 zf4=HRK~L`UoSiawsQ=gn9&|<^Uip{>{a`{y+lt^l*t5k(Fmi~`EmCX@JH17qq8P(U zhr{?5KFoD_E|pr>?%xGth0l`7IS|shRzY`O_#if-F&X3(8}BoyLaxAmB0}mSc{n)2 zWxedpbJC8z+4=042)1X`;L5>rkqdU)^adqYe(Z~xmc(jW>7G&E7!fRY|426;5zCO5 zSt}JK6ZWrXd74X_7H_``$H@@WE2>yAH=H|P zW084o$8KoyPeh@~!FcB4fT|~swJIj}w*CdbickRE?YMu{gU2Idjl)?s)-A_x3&n)X znJ?n;e10zI?Q%;x)Zu;e86Jkmts7BSCqlNX-GbuL94UtNSA07Pb-wivGhb@97P)&A z3bk+N>P4US@BCl64#K3MVr#tn#7g)nQ{7#Kh=@p&50nk*Ts~{WyH6EdfN&*nDz6K& z87i`=JU8>nTy~YzY4RN&lr*sRNL>GB@}tM|HMMV@8tyQO5dTFUggi-3xT-BC@Th*^ z*P6{`AVGo{?u5KNRa%(JbhEajW`ZGLeM2A37(c)gfROH;VTG8Ivd0%e9lXeVIE|@z z+0#n39;)B;6k0_E6%6G4?6_Pku+_!582^>{HYuW{F-3}krj^Nf-G6w&ac6U6OVcikbquJ~8M_f0t3T-EvT|i{BBw`K0m@5>h zf0`Qxj#}TwGHcdGcIE|Zn;vV|)neF4QW~YTtzGpr1rZs0e#sOO9N%=7Xbz@vS@1C7 z2pA7U-LRNEvcN$fw%p06!-=8>%)Us>2^vUE6D+1&QK3Z#roE@D&?t`_T1;cK3pnSv z;@6@TNOU};@OrFNX;f3%wgKru+<<6?6CQqArnub+vzG7_JFa=5F77P%=>hih8RDM-KYm3J(5) zpnG_ITAlZU=(|FeNcd8~ zc%wJA)Otlot->_cu1E!tz_I{Ac(l@@J@j!A7V31l9m3>xM%V08rd4d$EM6jtSZo8I zB7dOc=xTv+fBuJ#h<(^U_%l4zYS3Ahq(5@ZSsCdYx5vKh4)eFdeuC+ReVDw(ZKE3J z!+f4!6!FRTYZ3W6jh`+buN&&;4buBP{{@yw*NJYm1llHig4w|oTw0AH+`U}>VKuDs%OVE!$g5ODd*?Ln z;~QBHH>>>9tE|3LbHB>3YrJ}T8@uIfcXsL=$V~CN<7G?!#cZ_p^vr@?un0U*??E5> zwB8z2FK$IX{#$Fy8;3Dl?A=S}4uqGN+ta+Vkk@Yw3f=4>#Jdk?*EG=%10=Pb+N45{ z-smc_(}=WuoEeUe!x>gQ7gXkh(E*d%l-&C;UX(m!JH8+?L!$nA%L!Xy7y-0|WP5+1 zP6Y**fet_eai<%7eITAnzo`TXM9C8U4sxYc`t;}uDVG|@hg!7VQTcsu1BXdMfk0la z6jR=J(O)d00!chS-E#h;ow40wUyS=J5GYsH^)r_3&bje{r`g-?^G#_8A?e1CAvkV1~MSrnO}C)vMom#k2Gmz8fWW-GSFaqO?CA^ejh875C9L2KU|H%E3x{&cle zTFh+@fzlr$(ZZ^K;El5V;=RrXGFJQ_L0MZ@)Y(S^XeBtCU+fj~+9b zeqXIZxrbZ0&pJ8_N=;66;Rr4PWs)Mh=Q`o2H}ma6mi)plI7rgZT&`K#Wy=C^Sjrah z&|PL?2!QEQ)}Xfp1|DbYieQb~6SbBmCfZ}6hzQli6Nk9zXrdH+Qm zUF+QXVrOit3Fi>tJMkFA(D_)Rb`1gJg-v>evZ$?oFL7k3UE{4hi(%~)&kq;la{;vq z-GGE23bFqrciFz7Z<}jBn+XJsPfQSSa0b16@76d+SB7{Mm79_DF7`mP*#GhHmSFpQZ|X=6 zumDJd=z?T~%(5@QxO!jFHlL7z=n3URaAjlFt2q*ldLMB7d$)Af^=6=B>`oXN)& z+pde2RyXO*>QkYtz7o5!o>1Rn&y=!MFN#ww#+m;u=+6s1V$iX8g>)R)O;Wqb5Q2Kt zp_uhk!aA565q&kc zRxqw@YMp_Lw|5n_*}c=U&eY^U|1Y}XmOUY%7nc|ov$eu`_0xmN1K6b|zj2(ieOS*! z4AI)ChT`SN-iWCBXL^w==J-Lh3_aaSMeJ_2W*xYsgnZd@c}>OMnLv(J?_!*XPOH^I z>nGXdzJ?y|P3W1OD+^M)rW-!Y|9xAKgpHy>uc>P1d z=WwB}?-|A&s0`2J)w$+bY(KsnX1_CBUa5B9$h(2-*T!}JCdn4yYG0GDjC%3jF@c@U7!UE~_~iHC_!rh|Xe7%4X94^0Ynzh=b1x6Wa|8Te zYS+3?j7t+X%Hi1SBS1$I6ya00|Hjx)6;o4JONi5`7y2q;n9>DzqD6u8fcT!zA8AKU z*$!w#`PZ>HD%81gKH`)+_g8joDA1tX%E~MNZU^Oh`wlLc=7#Z-l8yDnva1JF?|TMIdW zC%+PhfhUGf`J`?-DS4WD& z;z4DF24CP6p0Q&TD2+kZ-g|6m7;uefs5T*p)GAyac`We6X^9L6`2eqK7x?cEcyzc8 zO0R#YgAe{?KkcN&v9GuJ@+wCbH0)1VRIoYxf?&p@LHXznTkl*qGqaIF1SVUpcSGkKPJ34r1N-j@FVVBE{00Ih9Dw`ce% z27QT7PHv$253Ki{?}|JmOu&_1sjv9w>IhQn*Gx@{rJ#y+-xG+c4pJ~;EU#AJjra%zpyl4K_#v0Fgk!S?g>v+Boxm8_2& zkHKREG60~(B&6xAmUr??MD>^Iw=o0Q6tBVTp^Vo~4tZT|yYbVo{}(fU_;6KVb~?7* z@QuW$JQ3yt&QFHltgWpj;fa?XeNB!G3cY=0`q|F{xL4uq>-C6c1KZ`Brv!|b8a)(h z?Y~v60(mJ>KnI}#=yx1|Q|=4>v~}E1KJP5lRq+5v>XBER*;Atb6yk$D?+!RKmVg3s z1YqTJawt>o@&avxsQ-unxQq;7r3!MK0|<8{0PwqkbH{tY2(ekjoxAryQ;+t9T!6) zBuUw`fgwf{q0bZ0r^SkAm(+P}|H`d%HHQ}@NJf~m##hbK?JjneZvcw)4&3t;Fvfbo z`HTvj{v(f%t4{WK; znurT9;@JSq5?`2!CND3*26iJiAsO2Pq!hg`18{a7ST|rT9?g{HC>3ch zI43g|^WPr}Bcq|=^dT+OyOg2fF$sW@F3M*uk{!eVx{LbrQOTFL4%f$eJHQhQ9~Xh1 z-?%rX=U%hQQmX~~dt`|5KcF6vjS0Fs65uaAGiAoogrFWOUI~Qto@naO_`NY%{#Zca z=mvS0bwHP4P7ERDo-CJra*ZU*YWb?nYj5=i@-?c$JoH8WfH^AxcrY7aCb5$=fn;=2EqFyf z(5e*1fNEvYV=P!va7tpc6X2(oPNX#Iiwkw+-)XA5JCG|i9wMo+Uh!3ftp43fXDX)58$n zSK!dYA>h~2(Zp^x*)5F8O9>t)kNH|t*x#9vY6=bu? zt>mJ|mDbyP3^KBi;43Da6RP^tUfNeUIEEntv^?JcJ&|g?@59zm8fPax0zCp#grGCF zK}+34z8dRWx;>EZivyzKy`U+&Au15eblrL9di6^4Z)nPkUO?F-6XZz{2%7FsC0no< zl=EVc_gdiubR=Tl>uEm$orlgJ2p^t#PMtrfEyn-KXM5b10iOssrDm)m7>KU#DnV_4 zp7}(e3jFkMes9z>R9!h804^sJKuE{C?wn(X-GLJL*L;D(x<}1gdvR4C9Zj*V>#i5U zf7}d*@G-yPE#QS=KZ25|31?zwf^anS*9yv$}| z__j0~ST?-txDrd=ktd)=lBwO`+F9LY2lq+u*dXLIlca4DmRL7*$~o*9&mDxMPC^78 zh^0wjAi~kh2wzcTM&#npD+GLY@WkcCyLVukprykyZ3}%QUmndA$A&ZhB4`$3FZ2cm zQn+FV8CLX4bzVg_h++Lw-fY*(i+4~Cq;wUr54(p<9FLa;#}IenzR)wi_RvihKsZ=| zf04QKXK$M4BAVH?b_rHz7uMbz%O1{@UMt_#2SX(sBfZU)R;@Hskx_^VpVa}@DxbI! z+hmBqkQn0VP71O1j@yGs^BH5Dbe|9q)3|f0_Bn=QXp=eZgzrsdWdI%MO%R;?fd{13J*s>Q zBQi?VwlVF$!8wP89ViC+!n{}=(*c;ImJDSfI(NKynF6mF?FUQ?|60)hapUCInJ}x`c|lIBv!u~_$Rfo?ozRL+s5Fmmu=pbqc6}Gh5q9x zOhxQ8L?lk{^d-4;h$LDCTw5lAdEhk-7g896d;DvL^In5&r53SMi~mH%rFMyUd%Z7y z$hp&-WwYn>^0QMoM(P_LF>egr04Kzv2xUCR#Ij8Yt=VAy5w5p(jqL_f5W#RtO_d*p zS?tAO?Vw3~u~cEWba$e18rT?nDg5reAw95z!LfH=J*sdV%?5qitAX+Ck#z(De~#5) zDiiB{Z&s6HDlBw$`or;RCn*;lcj>Exrg-KZVa=hDlNZpqk)QJ081~22Sn41R$#Aw# zGK8vY_?=eGpjdz!I)$y@u6PcR2kvNMRgx62NDvGOE2Xz-Behl^ljt7Xk>2s|e{bOB z(ZfVXXO~^~p$Kv3A;MdOgjG}_7Qqzz2+H8$-^qK!0U?fBvHj+YI42}f%}6E?S

z98ukZ65pmdPSP#u41UIl)r2MU&|Nn6T0AM@_ zgD7+}S)^lCFTd^ASV%&=IiSU_W|w;Cgb3YdbUPd1OgY0*W`R{nFZM!2Dr+n2y7o3* z{&u|Fg5b>SgRzGd9=3sQpb2?TBE`K8AwQhN*ERQv^p%nF6c+I)@Rb=S*m>Qf1mcV# zv?LOZmW}QF25dnrO-3`3znxV4g+0j?D1{}yw2qMZCC99bNP%fE4??_k z|JITsL?kjzbSv25<=wY7TO%!m-o^+9#H!8F5Y=f^xwc1SGXH&bf8vw!WI0}47$#k! z@?brQ_r!P1Vo}Xs&w$=X(!)n{TVubEL5Rl;!&HPrGyeol2ua>wnqrN9uR=X;jiA1P z$bA;WUNLp9>kKEgy41pI{p^g_?92JnngPwMlf|$b3l1x_weBxw5mFCi8&eyhQ&<6V zNwfjBiM|+Lei0dTm{8;N!Lm3#z`!0PZBoDyr%y;A!TcTeaw}0t#%Ab#B<9%uL)dJ* zB-ze;c#A*t;GC83sh(lh5Az^MAv8T4`S3Y4>gA_6hfwGV#)!(SJ}H4mw&f*N&Dr)x zB8)P=5}R}8 z{o0Mpn^?dvXAf^>zwPZ_61(OMr| zgHgK;3Vf-X?KufeMzQ%vp-&y=f|IV57zomqo|X96C`ObsgN^= zF;-$GJ;^4KwW&4-Bt!(fd~{{^`WJ5am>(Q6)9tGC0W(bNv#Uob*e^YAtux_lJ`ybj z1O_${;o#VB6+Ls!^l*+PhJ*Ix#7}}pf~et(q?O)*Xdxk@N<{JkZRyvW`d7{p^DeLU z9ZuL%*_xeAG|_EjEk?b5nl&+bBEJ*_$B5e~bmgR0tiVBAi>8 z&?_3#CVhZm@y3lJZ7=^cnYKL+zr8FE%OP%$m5_>ebsotv@&UTnorh_mZ`;Ja1rgUo zF^j28VBCx-b5$*pFQAZAnUpo0a#c6B*AOBpph7q{- z)!F&F46tzLetSe~|3zt+@i9b(mPC`U9FmuZ3{_@~y8I44@un+?RlI!hpJ!QRh* z$H-F<&v`z-4{D)kHrXf=E!|T#kw9qx)E-4G`Ucs((w`@S%OF{0H>eEP=*p@q)3rt@ z>cfQBjQVel6IsNtULD*bu?$g?sAM$?KKkEFbB?4@Rm=MtNrv)WV?|@cslHNB_7Kn+YN+f`bJ0>n4QlYP@s!E z+%`vZAoPzB@i;T(i$_yct!XDsrlWiUNQz9%tBwcQ`j7sQ60dHO#n)Gf6#?5Hyg9>| zL|#!>AEN%WBzDzmeGiCv>DYokZCyhW7Z}kS%OzzBt0z3RvbW`>7FU9H11e>1ViTqC zYvr%v-7iz@@y>jRY(k>wt~!X46EBl!`z8+}7K;3VI$DWVs2%+J)Nm?s^pM5I*YP5Rrm~Odh}L}54lQSc@g8esys3T?=}WdpyIintrf%s z1hb&Pe0lIKzPgf6JK!NwpOjC=J(J!-|HE-);0v{yXf|{RDX5=n->1p$eaJ%DU`<r4^V-Vk)5h0K8TVK64>`89%(Zr7@k^A4iI#i5h z;Y`QbZM5?X(Q{8Zby+(1A&rVBFbpj*QWBr zCld*0^HzavCn-Pb@$vAgnQua6MAtXKWd6h=xbH%?A|Q2X?0n;HcBKUKOuYn5z})8B zBhT2xl|yh)M2kQo^z=LY@Hh5-t%TXKTq$R-f_vLze>7x_7?=W6 z$z89uE+h*=HnUjw3Xe3lTzQd2=iFKx+K9RHoUv(4!=n|&(+NyBqdjh`L@ag`J(DbL z5 zx8A=zi>BiEWl~vF(?}N&sEvYoR>$Fwrphd+yKC_m3`e6bSgbm}0yX}%IZ3~~EVTFN zNloh6?#EdtFVL+>DTxVqsX<;c?oZBOUrd&cL}(5Q{_&l&Irkq$Lj&26B@zJ9W!SD( ztXO~i5*QeWiHw4B`}RbA0!*G9*b?}ZMDo(X=r9{zQEIBQwp7$XhLw;vQ^LdruH6uk zZM=khP0SzX<8iScew8`qpXun27F{<^UK9^q7cQynQv4&BSrZZxl0q^37ZE$SF!Qkl zA2%Za)LUFur{+WdxTQ2;8ZJ?=Cf32J8H}mOUQIXQQhF6n@*k5-T)pGFdzn&;V}JOC zrh|$?wc0fJJgGzo!yT%5*oVW6*rb(hkTWEi3iZgc31t~ATq!Gc**an|EEJ9lx1eVH z!bsor;G#}q#Uz$mB&P(%CXo*9<_n*8ldz`_SL=SzxBE>^#f1<~oha1!N9MPB&XTj^ zMU)Wboi`L49i~}XM$KcLZe@pcIvZO?ep%grYBC3oo!+Tb-faw@lzj~kd)+89tsd=Z zmt_~7$Ko-Au$IN;a5$>vU3wmTWHfnNWYo4#VtYJIJUnwbn1mqqhO07>IdpGUuJK_f z-9D|H&bKN@b3`7kD!#@=667*RrRIqE@FI+PX!Uu7og;M|sRTey|<>%p<9~v6MG*Arw z5P^fz{sw@fNVzp1BkV)Wy0EeBz3~)qqg~^rR1Q(J@i7i4J1p(5x+4Ny0Kt>$p(yq{ z9Sv2t=@=~WD8F$(-dXW!=DwSIrG*a$nSS8h^~dVbU21XEkE}fxaw=0cpRS;H9+~x< zMC7l?DGe1+?yh_t^Dn%Bn8&9ZkD#HOpE6p{AhHO|D0wA8<+S;^4p)ZX80(tlOBj|R zr_>Kk45X&@*qI{kw-+U&rIzs6l@nJ7vPL~yOWbW;h4*$^5^RK26wpc5q(_((i{M)V zymSa7KA>;V@DfUfhADc4V)f~Ji<1}#&bQRhr=z+k}#z!!$@yF=Ip))VO zTFhY_iu*v;Lb1f@ZF|{jWU4=$vp2r1mYWv}vIDKdKl$SNoKug>Roy(k zSS`}SSV@JGiT+FfIa;Bn>~b1ZpPdF?VH&N(FYL{iGjY5MIdgLeha?YEN#$UcWPZuX zMVKA-Y2>1Eit;v={B<`&_1|6;j6O6B434d)XRwOMwECG9N$Irg$5szP+VZiM=>})nhY@J-8~YZ9Ha`OZlZ(pqiPeREfR~N8 zpz4;-d}zlho6mLU003B4W30&9#CAkK1aublXy3UHK#PghnAAq*rCE%ZNnZoNgqgSS zS6pmzC=%{IcE>0UTQyw7v6)W~6TLuft|ml0kV)m4IftRozZkmVO0N4fmpQaqw`{2; zI=Oh%^kg~sZR2q92@QR*od3pyW8Qx>ea-c4(km6m{rWBb+R(tn%I#p7_@0&hZx!*Gc^S`5d!a-2rYwg?seQQlo5ucw-<*1WQqf{o%;l zgqG{8$=*Ut1g;87r9y!RAB1`q<6hl*@i+{VJEgvn$S__GwO##NNkKvC?4K@E7f**> z3B-7K*GoYGixZy@qELRM^~SL*nzjHcgn-Yz+I*>T;l2&8Q*K@JO^5}W%Rg&J zj6mj7zMU-Q-EdNV%UJ}pk4({iyeBLp{1|*$i~=Zu!KVbpYXpVH_szH>v% zhL}T`0)jurS381@fPP+QamV|v_Z!}#XnmUlNlA3p`}{&y7$uor5MpgaC#Y@b&$_Dw zR5o}dZ%hRfIKpy50s>PqMFE zdZX-HSJSMOPN9ZC!VCA(fphvOz)W0#y63>Gu#VH&3%0qUw(A_N&d&|=vN{l+f5oY) zQ|EzgA_-2N5Tz3jy#lNcJ2Ije?w`2@64){ST05Jpb%rj4`BfNrFnZo>;FdM2KIO|U zV_M-E6MU`!)vRlG%}xMpn| z@k_cZi7|DftU3R1G@KO&*Kf`4F625Gxfk{?znyOqaaEgUx|duSM^6kyiw0gA)78!W z!N%Vvx?U^ahgy$2o9-9tM&U2V!W`pO5!)Y|KG<%5dU5pY^{6o-ai4*q?2DCe`^Y;1 zm7C&%)EwE-PV;NlA7{aF>}dSq<03QZEb5=;XEGj1MfF>9NswmK=tQumqwoNhlT_$T z@PCd0hh(#d*NvPhlLjv`nPUk1FelA(*7*yQE3+jt3Ns!vA9E(NbzdwkH6R~XKuDeG znd+IPo^JOTqpiK$cn-cpA@r#~ngITp{Rq(ML`kM;W;qZJ>GwA>to(;+NGg%6VWc20 zf$n)1->cOAvn$_5-Aq{3gr~#n8SMa0BdJ6NPh}Rk)y5`-WGk~2fV*-j}AT196OO-j53CJkm3Aj zw)4Acfu=_fF`eefq?j&GXx({7fnl8fX))vn7a!1jUVv0wzj(vlYC{0IBN*^eGLvKIbqzZ1v8{ z=dziPucy!Em}wTxf1#NwssvP`+7n#3N4iO?F&uearojC0Df`lMdvw)1M2gO_h{8ks zPMd&gA!&+w;3n?n(oqF2rGx1c(pxOV9j#sOm#(>`AJ|XELFG5>r&Y3+OJ0L6a$qF3~rMgchd%U z@4|aL03;ya$6cre3eUrUFJ{VV*rExel8>`u^TZ$F4*%knks1<>;g;d9_f@#{L_8ap zS67^}hs>u;NX)|rN$1F20$1B)rp98qNVe2}IFR{XD*W0!kA z%C_y`J}J`u`o(G-#_WG01jBniqzxekm{c4nLGNtFJz#nBPb!g3oW*$1Txe8NcsbwZ z^qdEz(6TW>vWa~dLZ;Sn0d0m1&<(|H+%(T^SPJvVZu`JGLG_vH+|u~QoP^f$Ve=sY z&3Fhk@CFdPPIeLQ^fh%8Qtx9Wy5X5xhkwW(2HHq}$caLZX`F7=th-!`Q7!{=9K7S7 zWz#y(1gjJ3Twv|@r!r9A+FrueSG&&dKXln4SgTJhpMZtbOmC*t=qv9iBg$TY17beb z<7RCt>KnRk%`-^a|5MeM2SVAsVUJ<#Av;;i5-LjxV;iXuMu^DXC?rePv9Bdr%f5{f zA-nAR+91V5+1F&>WnaHD{oeQc-tX@@&ok$_pXZ!&FV}V56{m&i6tXj1TFZw(%+G!l zmBt_(67sHzlu6^epmOA@@y-kzS&h~?{4 z1^2F%nveQL_et;;y)<4y!U?`(sZq++Y*sTjJ{sPQk9^Kx5k+(4yEU+CdpLG{kYl+M zKi=a@FRbzl@~OrLUexd#y`d2E%xn97ujV^gpD{~Mx~^~~m*8yJTtd~zfF!TWSWx7N z(a)P~L(sZju_Hg$oH+6p--+Je{L7a(>pCXCZte#JBIVvBk?YBDL?)e{p6V_Q6xJ!8 zPwp20k-biHqe{q4qSWvDGo|C1&a+>bW=f}pmsg zdx+rIm8zDFS#}L+q}cG+JA1e^^C%i1jXocN4hL}rB+h3b3JuQ9Ws=I5qQP_*wj;S^fiU>|!#<>Jpr zI4Osf$fVo)aT5|n9aJPFMl+Q-6q(jTJW=@gB6*f4G!5Vs40=FWf6z1gTD?&LF_pc+ z87R+Kyu}Pi+O}{SfV$khNG|zjE_2SU!bxTiv0+`JfUB7pg!HcaCEvqB<%x7mO8jb- zT0E<+Zq0JxWOX+4yWI!1Z=dF_E+4Z&f?B83(0rZIl~0toJ?6SPG&s>(1zV>Z`ddz` zTc4hG+uKMz3*96&Od3DbIJ$i*=V2NjZp{y*>Lk!bZ5((TrcY(A&%NiLv&+F#EtKaZ zPNl!!?Hp8;Vc-saKEj`dyXx9VdOLZ$A!at>ejU3OQ@r}aVm5~u@WR*S7d5517E9RL zUUom!R4n|1R?QjrZuTx?=@R}?WxZjmQ}&p_gxboHi15zE^lo)TDBPGWsNyAsNe zB@Z=Mc!s&Fdp~Ayx^zx34-d`A)qKwd$s+cP9$oyvzw;0TOx(%@7qz+!%Ju}PrO8b6 zjZZ}~L>+l@l^{BiYApcdtWFj$aPN))HKFIYu8fW}#ZT5# zV)wy1Gi8-y4|XnX3YKT^r|}9Fdrt8r(+|QljcA6FULlp!>ZZ^d1;7Ie=QpDG7TX}f z*J4WaH^rEj$V%|7X_1h(b$gpgqGt#yuS|dS31x>RvpToJ;gr_Xi}m->UK_r2$k`&F z-DAjAL|@FqcDZ5rIAjTc=Bc#OIxya0NjFbQ#UQL49|r&S46>hW?Kcu<+h^xRDkco?^=wZ z;L4w0evMQEhbl(PM}hM{`fG9d3q|t&RPu?sh&LOuyS^Z~KUh2|Hi zpY+IJo#~K$=h$sB&V1T|fTVg~F=qj_^lO^IYi}?6<4eNX`jR4c7;pagGa{U7=e+Ee zNHOlzpeU>@ofUIa`gOml)q}m7qg3Cqde_nIet3R|uKb|GSgec9rO2PP@pKI{R@YuP zHKk`EAimL%P{K3SM{C zZbk$V&ttR5C;mn|(^rYGXl~-9X!!E=U8-T_w^yQQ%zxQOMLy|tO0!*H=hbJeL)Spq z%gZQv?~68UzY}*HUwkd~b^K_I7XS7|#AALco=aSKh~ua9SDP~?khu*@k7tux`qKw5 zG&fh^TqBuH;cVtGg^eB}A$<$`EAoYV8?_Mp+5nMln4{zXjSo@m*tdQF!C0=R5oOzW z_A|ttOq#b1(_jFkDMgZARd9!i$!Niy8Y;Lx_C9h)^AX7pzJS~ufFs;(Pl(IILrTx% z7Hv#M2b&t?%d<3Z@f5c1#r!5`ubn$wjXD9m?jhS8_rq$Crkwyqw~(2S&CSj04Rr}4 zvY_C=^qOkHKz?RX(aRnU=Zd+7W~Cs#9E=!_5Zy%>SpA|~YqK?PZZwqpR7tM#*o+)I zlZ@v1bhP0Fu?YX{%RR08LuG;egpaQWekr6^?9-yz^K+dG3wN6!BD>%k@m5 z9jy4w#fa^_Nk0cj2jO@Lpnj9Ho7unDS)`;W7g+vn;-c2)et1c7T<2VuFQ?so?w2w< z5Abw&CwB#g^qPM0ydCDWot2S?`F^E_g9SD&7T?;pWtZ~8UKNcu=m4bM;RVF{o*}^8 z)w?fo&~$7AqIq#pU|_t5gJ^|S9->u*jvE`Z(eQ(rUYV%1RJBbbm)+{z^f+((H;m9V z@xu%|bn)LL_Cy`L!YY&ieS5FYRY=N7(@_9!H4cgy?tRqHv|&0WV3-hkYn+<1n8qKr9r#qRkUm!A!uMHvFAn zshPZ|)hB`qfNb^+K0eD=>FJXd;B{gqzF%5>DLf@lxlg$ejY%%BE(&pebnnr}Fg4nf zHd@8Ra0|u>ZV=QGuuhi6P`A#FyTAO0n03y@RD`dXtVx6!?l@)lY|eC~Ssk`lHni9F zDipOpyDmP;d&Fkd?PyAG(>7j6tYhT-D$2D|%X?Q;XlFK+rw8>${h3YqeZ1Nnc4p{> z@h$h%*S)UAt{xwuL{FUVnI{>)SV{{-rv45~Na3VWaaL4p`U)f<&PTOGCX7_j>oxB& zZ7|_WkqKnz6{`h<>j+`U4NJECpob-j&%w zgnI=3hP92%gWEN10ABSiD3w5}`6K5(5xQD4KDn4cWMA*?6)(_R=+!omD{82G_A`$I zh%3o59VKrg^>{o)=q})gYn*dDmLeVoG0e+c?|=sdw{gpGzm)LUvW)p0#xOqK(5tq} z8b2T-%<;U_mPYS)Y8<#rlCuf{y+lARI_ifB;#<60Ei$rV1T^eG>MENyl~&m#HKZ*d zD)r7|MWc{Ep3*sUE5l`T2t24crMR>ftvZ_vzWk%R^fTWo+@j}_h4;A&HyL~Cr>VK> zNqBjAN$nSC7qM)#R^$z*hs$$3NX#3QWgXQA=RxkC8*||mT1@64vyJv}>)imbqkU2@KLdWWS$!j#XPXHt)3kVoI zC1iZdwK%`ZY`l(79c+~md&}hCdq~^$FBSmE3I=3f>lvMHzE8tf!J;Evw-gz25O?9KLsWh<&dd@r>yh$eNDfrH~Y zP8lahQ(Q3z)J-OCv9AC}m3)3RS4HsDFCD;RnzA3Epa2vc(+m}K+{wtuD7z>yP6ZH5r`18Ok5!=(G8mrFEElZ9>s=J6Fc# z2R!HHHm)95GUKlqz6OLP*on_aox`{BVgLxDndEY-YCGLLR-+r+whXm4XLM#23VHJ@ zU^-L*ClwO)I2V8%+vZMy#w+`!!3v+AgADU<6ge>z!fN%MuJzSsXa<#|MQWcGwK|TN zQAaT(%}Gbz@wHXx@+$1y_zoGlg?D&95V)G7(+)SH8Tj3--=o4N`7HK3=j9>L+Sa(y z+mL`=o1?%^iQON$tv)gj(S*1F&gWD#(gsT@^C7gQR8r^QKW)M0MlFK97~ zeXcFJ;bijM!ouQd;e!H$@69}TpeZIcT#5>jk?jy}_BV0Ik#W>s;GQ@?_eO!(^k@D< zsbthj-39I${^#fL0A~B9+-`KBhGxYgJh(_(bg*pqJ-Z;H^|=3<`PtX&y{rz=`S#lk z_)puj)B;*3B&3Gdca{gGb|4+~q!{Te#%g8fshCZ%y#loX_T}Vt4%9E62Xhez^HUGs z1R{^m#P8!n{WL3ZB>KRg41ghZg{Mjm4k6J>JDA+@p%$;_givoN5xJlvLSR8GL9u5-tg-%`fDE(_O#{Lm ztSAm*MS%RANOAz$v)^@H%>9A4^Lyq?i) z8M5MNrgSCpZstdHX2ha>@mylJFU*}YXtl0%DPMjg)y~dx_W-~)&ow(i=0X_+3E(qB4#=13;?ma3i$nTG4|ysGbzj=MYJJZ=AgpAJ}S`6X5U$ zQzUs4(~iGsXlZH5DJhd<5SrE%K*vOvM*ypwNUb#_K5&r!SPHq>Ztg!!o5*)eMm)ab zBRd2lL^6^fcKo!^4K4-|%de+doLa#Rbd`5hqZ+0fn!}W0?PM++xb5>WL;;+D8~4NFiTG!4irJ}vMvK4Kd+vrG=3 zvY!PGab5CuBOjr<-jx-l*EXP#3KB3MK&Pv&2m`(MQXip04+0YXY3MiGS@9*UMG&@K zL336Hogl%NV*Hd|j_8XK9ql_OE{lCh_b=C9(l?Ro68!y*bHThBN&{fGkz%^cs+;X8 zf=A7)rcApj8;r65*2bkohDzAr+LfAe@-xcEbMA%NT1 zZ5;KGS`4%vrm@2u66X?mHnYJ{F%6dnbUo$NgZ(WSXAF5(!sSK6ySDUST+Milu97DI z0lhwPiSG-0nB+Aqg98Kuuh&}n(=0+#F5wVN1g!}seJ^?Ry5O|NH%{yqMW#`cZ-WhY z+IM+jeCTs;vD-scxiXy zia|*;-ry3dIMKdw>R7w(bBWy4|yfw zI%VMqJ4b!5wT)c6%!=ev8#@<+*F76*=iTQJF+O;Smy16|xWz;VD@jrACBO&B=4xHs zAhC${+FCI8M?G*(&nIi)T%aTEFlBF@_vgG}(cfUp%H{a0NYVeiE8YPM&5Yj=k-LSi zCpUR4_m#-v0ot3DZ1BAuI5NM@uW+|8w90S8crFGg0aX!=ku^{mlkRwF6>-9owTx5l zz+eG!GZ8O|2<;UcQ9Jf0`ew>QFAn5(+E+?1YT$(z?xc*RT(?3p{Msk5Bk+odR$>1b zp9w={3@*eC0h{(fzuQc_{+O8V}<-51m>yhZ>z~c{4_8F1F_BY0^Be@+;N`K=V(kNy%9_ z{-qm*r1x|g@Ht8QQQ$3@mQ~kh-)Wr0;5~1n`aJBZNm!v%qicF#q{G*QwrN&YF0Rwp zYaN>r2S9}?2PzKZ#IU0bPzKs7N%>-)W*)OlC{-P?>gvc1argDIvw&}#1KBRrdb=M> z$Y4R7s3FRrOU7ix!y~sHK6dS}x>_axtd~uh3X!!1Lp@V1sp|QgI9o&pU^QfOQks(9 zbVX&=RXP->_((M~gwjGFa)$cvNV+#ZPtD5v2lyyjTU02UJYNzl|7t3R0B3M65&32- z9oJ`8AXJ1x1e}N?qV@dw5y2kNTV3T(BO*4$55IbO-<>u^5aD^d6C|&VKuZ>6VNvI2 zT1H_H9+}E2w4uq|)UH|ZGnA|kS{VOO-oNOY>5Q}>0^2owExWjOUN1KSwZV^GwO+milHa*);tZtz>kBh|_E+jASo%*P@6e8Te1)kT5<$x)GAILeT*0s?xO1|I-8&g` zNaw~WrPNz}V6Kw0VO?6Iw#MB_DWF>7JH8^pS#avf&h5irO8ipnYMs?9$pw3Fw{ymW z0d)t?Qa!nINxkxmb9oLfhiqxP{wxFUm*p~L@H2#RIdHNSNuL`2;0*JS(&=5O& z7p-k=wq&HFcgG?)L@R9hfl>xRp6y9bUF0LC*92sh8a4b*y6u%F4r#^=7C@GYf4YN7 zpr-u|C~e>JkO6x@UvDxiBsh5Ebx9*wEsZtbxehA9b&c|VBVKwu;!GeodyL=g)*BcO zDvwvm@iJ=3?0@n@7JzaN>^7z=LCoy1rC)4nQVHN+qYcGYBbW4=tH4#8s|WoP`G4tx zNcun;FBelU)axOl9J4`LvSe+SDCA>bChxkdFwXTvMF6470+Hwke}Dg=|3#wF#~|2M z^L5Up7|{n>a_Kfjn*$%DSV zyIw#T4hX8dyjvez>U?Y559)A*08j~1AB7TWimv>JDW7Wh`jii~R{ zikq6w%*Uf*%Ku;sbEv`9IykxI%X$I(_y1lUl0BR`V~72-oId|#wzBQrmq{)A3Cfry zt-1IdsuOp5M`PxRK`*2#rhsksd&pYY3rRn-242NeU;Q<;ghyZGxx~-p;y9&!wIeYN z7Z04rM52CIOMN+XKX$vz)ftQ2s$1-?Y{=p3IAKdoH>vehRyfdVpO|IF=+ z$cyXb2Nhh0zmvKACZpZKCCe|)FPxejx%rcyX_P|%fB%0Kp*lz7USqwatkuFXO?1`=+km}H~Xek^O|9N{yX^wAgZEbaAFj$;=@LV|s zNX?W8;Q_Br`Q&KNuYGdT%vJlZ^kXIz#8CjHlG_FvF7y;joa7Lc9OYb-K>}9Cu7TfW zbzoKOV_&ZY^-&!0Gqt4$XD37yw6qEFF;eWbq_0jCrR=FN=@cTq@A_Fz-%hbms;9rw z`ht>K56;vcERbwc9juv59&~8j&)ST&)JPxkN5(yt;ol2ld(!NsmgFqa#vH3JNtsM1E+?c_ex$k--z^wiYRAgP^YL_5kSl4RzwxH4hJ)GnW~%iQ zpPg(MD&eP7vxnbCv$Y&Zm||Kz%3j0Zi~U*eZaPfXxU2q==quJ%OIjMb^n}VXM)&INFWKJ%vbpl9O+Ss-7j0Tz^QbIttJj=VSTQk?c%ph~`PBWvNbfNY?YBWP zy(+Z3K|EKRl3vS-#af}n199|pKr7eQ@MTJFWK+c3^icGb67 zV(HkW-Oz1YW8r%a-O;peo%j#3zsJ|~eouJyv75ITm05YBW?)NydfX*W`%NT@)t@M7 z@Vs|MXcMc=dKJZ{)1=3cGI5DdJGLnvrc^sV3F-zFZf zr7<6eAG`f>__+P_b-3L@Y`ubO%qFI!2}fzLQL9W~ry9c^Ii>x`{r(rCi09ENV^nzjDuw_B@{_*SZND0xljoXGD4 zsLc9xgf-Ld4N3MgQ{RJ``hZ%cZ}+-u(>lW43wpz}?jdTtC63#;zj+1M#&w=yUDC?# zOwgPRm&=sc2rd4^2H#*i`p{82O4L2RE&@wqJTx*6DWuFozyJ)Uw(;@jH$O!l72c5PGImf+pT3vj?#u9uG`0)k?cP&n~hQkBJ=_u1urUZ*oO9hBYOeY1&-w-Jy+peDJB0tRatWzhq=w zG3R4y&3@E_6^4t7z1COmY(04~VB(BtFB6;}`8JBn{4@Kyc5C3>Dru)_zBYbwaaf@y zz$LN9@R7b>D}++)#s2n_nT)Nyz3XE7<^3JMDB;XsIb?j)^r>^7$SI;R@ByL6OEP{3 zwcCkJddxmGlR^}j+>CGCod7p?ul5FLzEjuM=XNONWPPgsP9U!7!AjY^JjP!B8B%OU70RaJV3{9?f z+F-w1p#;=b>>0?PDF8k!PBr2Zj3w%UgX{92k6B zj)F-o^V?*1kyXOy%gd`;Fg&(?bUW8^oj5K%P+nT#8!Ils zevbgap!6>ZqLVnl%zN^>%g3{jut=}KK!Yx?9ni}x4sbS`E zqV}m-F`<;?tTRQXHVNB?47_Cz(ob1=x{@w*cH0d#wCA@@hWhO=?)4=&Zqu3B2+hLu z$j$&mKT#IcGu@w{vB1uiRBw3w%W8?EuF5k%MVqY^l)wdcY?<>&SZibQEzbC^#$ip3 zivf3;xZ`$38RO|q6km8g9t)s>lLhc6-w7Q zoPPEUcQ{*w0@6eEkGB7G9n-=qKo}bDAj7&iG~CZvHnRYUS-ms*=W2W-*e=pgAD zQ!u=l^PKGhAI#~A81J$U=(ibodhln3$x1*{M5AXZMSeN?LsDjaUb@a5)>(R4}qW_0hD5sLdl>Vz(@gC zHUD7!H0ZcaJ}>!%&k~le=u}9dIV!VrCx-1xudTY}(WPbvg|hY(w3?MC;0oxh+0 zOKgLyNjGO;!X|PrCKQjy!j%=JE*y81d*8z>)%0CjkV}=1v2@tP+$h@4)v(c3x_08+ z4~oN5A)3dCFwXY^#m8!%SB3Okz#dH2L4pzaRSG>b5_Zz_+X;y*^BIRtQ)? zyga@z?u)V!adFmPH#^?XS-eh`JaS~i|1j~#q0Nj;?F$i&%2iqZs{;1XPvf{__~rAH zyiy{MbZ(K#JM_%)1`v69qD>^uf&}V|23zeu+1>IHG83!2ejaM4JCx1{K)&!MAkls5 z8*x&{Js$$R>>s|qz80Gg%LcN5B{x4dgDhb}+%=QK&!F63gIU~X)L+(tc^e0~E)R@P zGCZ5^2^!zKPL?$tXo0&|kJ72V{pt?J zMq(BBgE(npN!a`6B&xjNmKAjuP~f>i)44=%@b!n*%__LE!gaB`7K-1t z@#$$30&;MK%IG{*clLP4hkIxDV@RftD0Z@z{D1cN{+ednosN1sw%f;#&82qG?gZtOg~WaRX_nTS#}&)1;~$$hw|VF>r==mKsN{31=OvO8lVr~!!P=+e-?Ca zEEs&6vS@Zzx+@OBRixIrXo9HWIt5hPIm8l%_PWyBwmNFzw7GQ7xhH(tG%c5z%Qfxb zD0w(U`Q(Mr_Dr$*;5X?4M`^8{@AlQNYX(ee91m*Q7-qhCYdwmg88x+D);B;0AIYF& zp%7}vRFfOqfthl*sFjDKBJR^G}!|n%maYr&9DWk4?DdWd9RVtDhDqk z_X)<`;~rlN8NN(=>i9o&B2R?b!Nmzh)_;6ENd zmL0B^obC}9*3Ay5_Wc-6!W`~2<{3asP?Kqk$uW5d>_wuB1@wCUlamwm@kSrn1R!kQ z9uY?|kf&b&z9WhZgn_}(IZ)`F0m!N|kZ$WK3bww)|05|E%aDX!ef2etptq4#gX(zk zR$UO(uCw0nO#+eV6B#FI4qXs3O};+m^!)JGUHGf9o(t_FgoeMxqlBI@Qo^;h_JG*P zZYOYjX#iMN5j1LXxx6I1P5F24{HsrNANDQ*WB|Hs6?EIJ8C~9E=AxscEkF_5;f~J- z(+n`ne{Kxq6$#k}j~?4kTycSs^NT=jfA7zqKQpiSuKqiOp#Psmkh;;?-aeX}Vscr- zRDt?qRwGC4rvL)To-`q< zbLXxy(9uOZlIb3deZkWZl(PP>*|3?m%^^&xi&)fZ$N9JZ;DcB6MhjOg|7Qp#Um~=t zCzGLe=5}D{2PUtm|5vlVUsoe**%Lig{Zrhs=xds+6p$qRzNn$9+Iem~ih=XPHv9jx zwrUq;drAN^2L}fiOJ?af2p9#cHSS@kIK3{4Ood??xVYBV=jU1CJ9TWF|NHOzso+@^ zq@IjS@9Q)tAO!jNvNZ4C#~<&r*9~O;_Z>Ms1n;P(w(BHwdaT7EIq440BlkgTmr{OdMd2hkWWnGgvT zH)2hb@27x;yJ_>>VVmFvuQ##0Q8!y>y6~8Yfq{|Xqj6VyJ}h?X<(Ovt%2P$3r*nHp z$Jqz1G%^^38eUDvhl01>A$e|QQ}`1D5tM|SjtAl2j6~pH(2_Hf%SkR=VGd&%UEPg4 z>kw+LiiP}dNQnvH$~?Fn|ERSSKr-KbcSvo{uo-fmvfb1On+-yRGzKmx3I=Miu}KID@67{z;*0eYqzMD~YH7 zXDB6%B<&WWJLKwyJKnH(us1)i)~rxpG^c+t%A$J#^Uq&8J_1i&eu`YLX->z+I5%=d z+)X*~KCPI)DwO{35N2p#k72krLk|5AEUmW4;TE~OW`DiB9%m2#|7Jx_xBqY|SBdOe zKn6v4$BdPpo{2})_42Oeg#X=Qp|<&ZAad}69(TY^lA9^tK3hs04C5wt`To5eUE3@w Yq-4INjgJ_x8*%bR%63NVkLt2#lz-f`Bk|mvlGGs2~bRNh2U7-7PWF4T5yT(4}3kac^mC~!B34?rRj>y;p2bDs-pC4M8Gy~M8J-`x8(7ZC4)wd{ZvA?c6No< z2?2k$M%7uEBFjtGsZ-0F^nJ~tBkwsWxAnm$uf17`q4iNtk;CSp1HbvCQ@MGhhbyN0=UV%RI}=tzY0{cYt-)$>TrXL> zmfGI8Nmree5@h>f17Bg;o+y=V^w=KnSBPYmjsxB`2K>SF$a81X_J;Z!S>j%;A@JY z1Q=E$1Kk=-ct^X$K%zt~UFJCzL=%>3RPe6@L`h}}4L5jf_i0YV{`0mU zJVJnDL;yw>G`Cu#aW_F^3k4l6M%eS6Auxy$0?G2J!JqB)7JjlRCCs7W(YZN@S7Y z_Y*Ew1G_z6w-myVrlsQyGTUS?fG1KSs%)bD4+q3cxuGFSCcE1I z8emZs8!$^ljb8O@c9nR({DZ$cNY7p7xvQ5XW;d=Ej24{+G5zypRCpe|FP{IjqpK_3 z>*jpjx_xy!`4uWp-DIIT;9x{Wa90N}{NwJh(m(Tvx=$Gz7N$ZgY@yhRC@RsQ3N^!? zu5l>zfn<3HxxfC$fbFRe0@VH5oQ4ed0>BF-=N^8k`6p5~Ux96UOP7YLwCXF6RB+z$m$3f*x!dgQy(?4YwZ*PK_)rw>RJ2cP3x{ z_3y68y9t@k!aiPJ|2j&aZQ7G$5Ve8v>(_i9$x-3-(qA5WJ0`veX7yfj8} z$eZqe@FAQ|M1DT#HlQblU8Ul1w$3H%SCQ^0+%i}7CbAvZ_lp<0i`h?gd1XZt`n2c8 zbQgBZ%|#)jj6b5JVT&h8(xU*}O2Q-=dU z4-?4$cuYs-aBbj;jQwkm7mjiSs2=WYS)KpVNbBN@U(oO7i@4MLs5{+#vv=-$vs2;XUV8@TN26-1 zfd9lz82LSC_Fe?%YkvDgL@NZxA!X)U|KgQK#3ZTpdaQsQNM2%OufED*Z;pP8Oj?+6 zYT=LLc|~EoU3WaLKhSu(Gj*@tbu|Xq-pT$IV80Wt&JR=e-2|_N<$*Lg;N8FS^*uAe z>qlN+=RH0#OY1o{pIc#J_M0zD=t=<>!RZY;U!~a`FHZSMtioc~a<&{cG(1tge32sV zma)fQ*7p#T^mK@VUHR-vCjKSty|m@^kzI>Xy=zW6*Zyq1X7lBqROPq+u|R2uY0>k8 zKEWK@(cFUxG~eF% zx!oSD_F*TiUL0>*0$zl3!=aYOhfPTRxlgcV7EP|*`7%o$e_VktY`^jF#j;0&p=Z*p z`{?t7evu*Cx@F6-RfivMuw#ILf9mkSei8=cnRw20{}BWO>Z^`%z!-9AB~n%Z+0maQ zLW~w7frmV!umd(`o*M{5;X|{u{*>bv$)cO#9`^H%x-u6V_poHtq>n#?=VWir+K}9K ztCw)v#e;dj{iJFWmLl!qWRxXLIA_Jsdnq_@qQ}74XO#+T8a?u?S67pt)C7~1XX=RuaD=}rN8Eu8rHz*w8#`Y^-hu@Eu(=@h zkE9-%qe|M+Z}#p(_75>?*5jdTQk^4;Q+fX|mZ!cx+gNURqOR7^Cs6_s!8N}C?^toI}g?ywIr z+-3IeJO_2)5)F=KCdiq%21OsO|8pqhLC7^>WO(hxV@-aiqigTJQx`I=_rz2}&G@lS zkV^E9ZQs%Z^_;iO#(uoPvNyfo?qJU#_?*u(+_d!GZ)jn3t?BN8UO5P2f;YiQ*4;PN z3MNzh4Jxso*}%f9ayB!?KIK6sa;h<>ZYP8% zdL!#*W<4P9;G8fOw+Z5m25Mn60UlJZxVeOvHtLVK(}n5YPNW~{cGvXgwM@KhX~~J* z_?}+W&(Z5-QgWNs2Wx{5AKk0l;ivUGP4bJ;Q_#5JJbrXON;iB=wSnoA+zbdAqo6I9 z^^=VHH_kx>Y`7@IOXnf8q#qxjeJ=B`K5$)KWyXUp6RhYh66$OKC(i(#q|tQh3S_VB zXpyyJ6_>X8cPrtVH9Vuq@#1KcUlQ^ez+4ZhF|<0J1(W$2jx$UA!(FsQ%G!O_4- zOnbMx0{l$rF$~>du(G@yZW-a{gCjB2-E1BKC9p*hmp3%TqqE1OKi?=l&XE05ZhXBX3P&8?9b0y$ zAN}xq0Y}LoLUc9Y9g$_o1=V#*=m6eQqR*EGVpR|Kqg6>`c;%SR;Jy<6_1gF9><>p? zi1j;Cl1GvKNln(Wy>YzOX<)tqkQlWk4J20Yz3g@Ql`o4B*%y@I9>YWD44*yc?}sQX zt`{XTwQ?p;Z;v)j{)-^MW+1m7_5`-HoXU@;_2A?(vIEx6X;d8kHqGLi-e)8$A6pHW z5o+s9O$=h4d`BZ&BE6lqn)6~ou;r>k!rZF#UKEIzUR|MW8p3B%e(-=nA}lV#56QVr z!X)Eg2d2npUbBSzr^t~H&xJExHn#n}$ zjcMd4Q4diBT z$r^(7Gs&gg%-pA%IP}>qCK*UA1e-(u6&G>^a91+gf*;<|=1ohBEh&T8UIGF#tnl;G zg`iu9!GS+w^{0c9+k9@3eoStx@RiAO^G;!mJhtC@U)|Aa;gU8~d-H8b@b6T&K_%Co zoAIUj_Qs6~DZz30$2;Rtf9w$mU1VU4-Zv?di{%Gh1bvUnW597n0dsya$>Q;bi-{sW zj_My;_A8yjZN*5RV)+rfee|}yw+a16YLper;VrDGnz5+ zU$v2~hf;iOQovcjln1$A0$i8Foyr8%{@&tIHh(Y4)1FV)V_#CK-8kYHUwXel*)%;H!?wMNwKq*VlwsepnjrG;)-&tNjnSr@Jw5DcC8q4@D13;euYgHRUrWa0$p%;=a?(9MczF zC0+D3gWMHQW4_e9>r*a=&}MMxi<*efLTq5px_5b|e#RMYk-^(HDD>;OJ9~}Wod`r^ z$&dGtKAFoGxh)eSu^<1fCPcZ&@bTD)dmU=$tVUYB-Ae1}C$F4=5>w0vUkQ8pIfyCT zirSIuu|hhU@%*BDt}{qW;Ojej^9J&g`Eo@)rfv^7?0mU#Q~PS*OBKJ?In0T9({woO zH6P}{?T+dS#%w)UI z321nbWchtVp`G%aTe~r!RK}QWvWin|$x}p~06AnO-HC#5`={8M`eKgJ3KitI=kLDf zy@VN%DaPRx$zTTBTAx6S^`|3%`+4`h7UrIm^V$I_#hb_QH`7fZBG|jJPncg-PR-}? zWvU3FIc+n!ryj$uxP^MX6<|_HhV0qbq13V!!PPtlHa_~6B>m{@`=$T-2f{l zV%a_~(8_n6_CRNq{+TG&w=RfOO%(cpX1pHhrom?o2 z=n^do(hjOJEiIdMxjQZg8VY<~0zZi|2(x*zCzHWEA*inG>IhG`igX-&w#TiJ9UA4G z@^s`xrXZ+JTVriN1na5B%Mky!zgF4nMUb0zhV#Y`Vj{h^#|It-fp~^EaxQ@C&Ppav zh-0XvxNyfVvh5FH5g9GXtE?imU^LeZ*_Tf|Q9r2gaG_?l_s)f=SV0n?_wNP~(I2V# zUl*a!IzX-0ufia{^ah)-UxkhqWKtwWOCuc5nu4Skw*z1pV%YgM?gr=)il=kQ7xtb; z#`%5qHc$zO1MX9*uxz?W8pVYu%Q&a|jgz`WjZKSUT(d0AB1&xeQ=it$i1?Mah|*8E z@8#y<`0JXhlLvgu}4Z==~}5-^9wrdQ%zilIB1HJ0994F6*5 zWbIBxD5N}aQ1yYM3GME}ygR6L61RjzVPv7zr}uGAMH2ka50Zkgj@iEBaG<X4NI0C}>09`lfcnLn~nki)x1V_HGsml0$aX7e^Z}EwbFbvw4)kG4O(DDat zNRJGO`)J2a7lKWo2+p%_yRhopJAVt$n4U-lt;1EH3k0Ew(Aq;oKv-HywWWYwo*0+dz z9^NPmV>i~bH;JDXp};?Tw) zdi+7r0tp@d@rrQPh3S++f@sqDBs?8#e4 zC)QJ!A1lo{i^!lB?`OU76~D-zMXR9Wti*O zEV4xK4IVGl3i*7Ty#Vqv2Yt<2(Y^4w6^uF|VxVT6ZEaNj5QvRIX5!xUSEuIJvnbN3 z(<_(!(d5!7)b^uqTyjq6Uc_y zeXLFpTaX*;0P(3yO~fVMYm+%-mLOg`yDAx!+ZgZ4 zALl}%Xr%VUGd?6#5TZc%k8zNc18Q&olD1EeThK(>aQgcFvYkIcwfAKWI<@Zvb|T;ui8;oN{AFGIT0>O8G2KSPr19Ed z-E7+*P>^IchK^8P!7ozIXk&f9+Q2w!L;Agn=r2aq#hovbvIkaCCj@_ z+9>aWv-r~-jVn`(U*z@2>`&R-o5NqGin`2O?qD?TQ;V-H9ST|OWN26b9)7mc zu&S=$!73PqiNi_`Y}vsJ1lk0o|Lpn3uD_reVZ6y)HlCzj7kkBZXtE3-5I% zLn^gPVx`~G=Nu6kYY1lpkosrQS+dX^hn>lCvmvG!OhUokI9{Cx=lgk`kE`)x$YO&? z!idKt6*-=lGy+I59V}Y|*H#+Ik;40_iVt%U78WLw|0K^&#e?vIeS&eE`+)F3gyN;& zWAs|q$~s1jjYX{5rbp-f*n38oqjd+&@u8T&L^M{UtNUNn+C-^dJcfRB*41+3XPt|A zEIOHo4oO5Mf)F|1LZr-eSK~(Q%+`;xd2?{y_4$+hz=21L=CKYu#$vV~<&R=(=5S)( zW=j&Or%-y^`sj>K=}UQC4A1)`Q8p_Mah9I+o(OLMn!ijHPZm-;$$1t=eXtxRnC$9~ z31-`8zO6Zq?FkAUi?48HOE?iTE^WrpV|?k|GLs25eTIYCMt2C^Fn(J4UyGRWdzCsP z_Aug@w~!(1<200gOmOT3nGKsDj9Tu5?n{wX^T~6dmvY1U?T;@dmo8`WcWgGG- zpX6uC6-y%ki^sx3j{e1kp(gjUEeuf*?C?uk1Q;)G_VI|h{^NF;L;$Q5g2{W3>|syR zk_xrGfg*(!^kW9*6>O!9S7H{E?YLd!<;)7aLG*PL=i*V&aEM`lL_Nd?od66U(AfyKg7xhYmf<;L8n*S&_YVz$oP^@^J z5p@siv)c+Iw*vmzA_zKt;8V2FlwMjsG7?!DaQI5?VQSC}C8RCi@$*qJkftKk@xmL| zBs1kQE{RMcGIwZywZy$JDNzNuPSA;D<}^O;a8R+}i@ zt`1WP9iSzYQT9MV#W-rW=jK1LvvCxq9#inIjWU@@1N1k z@ju+3`>sPk&6j9{4*-hIprMm1PBNQIH^XCX@nHD13bQLVCFF^KZ3Pn#l!G_gh)f<^ zxPhI_7A(dml3Ll;6e>l&O;63q_ZY6O0l?n$Iwirxd?+|wzzd*I2N7wrp|Qf4%4~n! zSI5H?(KYP%lPUv+qKb+s4FYCHHxKPy?=U+;D%cLTBzAT)XHVh zo-&S$6xks1z3UGuI5R*KX%iajdP!vmAa$tl;tAFjlF*Q0eG9b@_UeYL?Pm$luJ?|Z`5Th40JIQAC|G{3O|0fNRo8e{+Rqy2>iw19K)@tspP zYb@}CHPT6nb~FB00K$r5JTbUeV(VgzgIFot>yr5} zIwr<@pDsd?(c(@`yF$s2 zbeW*mQZvRTwn=KP%U=M-DNH5BJ((gJO~)TCPWv}Cdlfx_rN_Lry$z%wvZRk_x8;K3 zRNnJd%liwKHpQT+O5|q0QFHCIoYUK^*g5IN!4+`S?SsOxvzMo_=VM;qbh5`0qj*zA z+FvO-hZ6^)2^1Hu_$VXFZRYFEen1v!C$`?O6VY-~k$}19{StY{pYr*6HhX>ovcX&e ze0;^JdESpd)Z9h2A768JhH^JG@UPYTL3z&+7vSV#D)@WsZ3!#$lIy6G6@1pq_V80a`ki@ zdinYyoEqMsSGpqUG)4GzN@h17FXSbf%Ll^;4}PmCe@-aPjYt2IPQyLfyZwDvP!xN0PS}0Et{@&|C5nfM5`6EbWYGKAl4KzS z4B4lNes;s$?3{*w<+e?|sowM^+^9-!@c7VlWAf*{krHJeTUm=#3+Zk9&4tWnqLf=7 z#aT)}uWR-;NznwS_^aBh_-h5F;I6I2(C-7=6N=4{;H$xb*VG#xOBdL8C$eHOkM{k2 zDhzc*pz1TtuYK~zDq?3fn`+MI_fvxIOMddcRjDsCS!&PEa5^N&iOBUoSZKDaq~!H5 ztk7Id)%Gt|z$D2$v7EOv$L#TlW&h&8&CbEI)Wo||dp?*SEf@t4Ga1?sc6IVU?l>2g zQFjseq$LvVNUNhLTFmc2si<;2iVYo1zb$bOXpRV{eW0YA(ERE}>O+D3=F|9a23fha z!E@CEgD7z`sng5-mY(P=h3rX79p%1p;v8E8hWgxJ$K(vMi6~)uC`GYVR$FKV!5!!x z75R(sShL)8FXK!wL|?|e(4AIBiGaGvpvE4-sWa!UA{049cM4MDRQvLIx>!=>Bvrz4 z&WktOZ;ofgt=GQ(=Hz>hPAq4(cHs-xRgYV?_s0{ECIPnClb=27gjPKaZ~gkZN#hw* z)*=`D*}vGya9Q#^;`?KsOJAqo?A)xnHS;Q@C4#zx)>4FQpzxuq3pidx*QXVkga)MN|5ycwfCphecgg9aqe@N8FkrIzRgl zELlt=f>NxGpodd|QkXnF8;?aDOATA%)Lx6n&DC!Ez%*WqjT>K7akIgBB8DruN)*#( zp7xbCQdATzUScACAc^qe4j_B?xPi_+8$7r>T`j`CX}?Mm^SqKHGkFfrj%~eQtIyE$HhP z(V_)|k2HeZvNv^llJ2hs^lKfX3tpuOO{@&(=q5D*9X0cKMo8o_cSuk z#zwMq6sDRko#@1tJ?fW2gu%wO2Pvx+K?_DxCznnK2N`KGoN6+3m%S;jt8qHdeD@*D zf?1C}%l1%vspV#Xrm)f{Fqb#;o_D-esoF7+Au5!2G0BcJMoh2Y*P~Qn6#@RhYQE$LQ?pMB#|kPR%@-B(B}y(;ZGVjCT6ObxN)F$b zz16C@I?7^{EK{4OpVp!G2vGVM*QhPuSu467WV%emt$U#@;cwE?C~?G|B(g~*k|0pp zXzK2kQhm@=;hkgPY#Qj}_cTcNaBTfxTTPZeqc2W8J$!pgcTn=u-lxK0V$|J6%BHC3 z!tBHBA4RdvQ&q!rhc?Ol*|K`k@cnyTk<8Jy_i%fq%tI76zwamDeDUjL?@;NDeuA6h z(IJ(6xWVnJ+haGNwQ;*8T-(D$s)K)aDiK8}A_;}yvT?0F8+zaRm*%jcKl06lE?ZSU zo6oVauv=e2l1hdx%Jbb33*tI7dDR;v0Z~eVWJlqISoD6*xyQ*YTlpabYwGf|fqCE0 zX!?*5E6=p2bl+;Cv!dt+A8_82pxl(LCsn@bJbr}=Ht_HGNF`Dm#Tn)Q>4DN2KpIqC zwoM+OQ+o4yaJT*(TeIN>di*~}rErX;iE@|I%K2as=8HF5wP|g8<^DYBc&{sPu4Jah zA^Kz7-e;Ny(x{5sS(Yq$(wMvB{(}4c2)=axi?8k*lLph(yBs=3x*Ex{huPrTgbSkB zg}}>Kooci!`-4}C&1bGk@Ckn13PsPIE6qLbTV%VJ9e>>200ZX0I%Tcz?|`hoOtN`>wC2@CO19HsL$2}c4MT>$U!`*vr?y;&>v`pTC0-ercL*C~thUeaEN#u~_|g4Pu`R?SOItbEJUZpxf2S zTPezJ+j+aP*%K4XBr((MMk&ucaKpBvpfz6voYG+?H{DY4`@{NLUk7fT`jD%}3n`zk zfnuBD*H0wY8xJkjXTIeqXIW>rKd(*o{L?&`1jBoAHgAcw3j$=QpDb{+SM@s8pLaN@> z(7(IpcP!Zmo0#`Za3R!ZQceg`mz?m28wKv0pF3_U2s>av<{nK~$qeDIj&^n=vP~0= zDweZIEvEBO5F6&%+KK*&>MPR-gJzrNDu%1q!-5LNq`LC&;UJLna*lF<(F_vjpav}6 zXkSiX#@$}=G!FmZIJzO2!kNu^Z??Wt$yN?xHG)$2B&o}O!OuUu9YREBwuf~=%K*dN zg6>lD=>Kf<7ors(L=*nN30G^NDEJa(*0JCZbmZ}y;<1G#4IJuCqnL&u7NO^z zpV~8S4xl(T_(aE)ksrGC>u1!8?(*On2>Ue@UAafQu#D8)9K^Oyl-R(W50Et2D#l-G z{;XLSwp{fiI&cPVw5D~qozU;xoUYT01)r=5#0knK-g6?}w;rsxZg7lnF^90<@%8vK zqqd$*s&tt4mSU)cN!C{@e$Y=r#@{Zc=+-fquC_hGGMq539%L}KqL(7#TK9-_XNo_; z*sY0C#v9&wyuqbo;FtAC<8*Vhgki2aV(5>8f0@DHV7#A12U9mspY9RA zdJn*`_#lNk`Vu$=<@aN+Ci9p2@d*!)jmz7AALMunAd&i?Dmy?#)ci5`uq@afbb54! z-QhLNn9%hSTJ5HPV9y1d)Z!Ts!~rpaEG}#GK@sbV6rcagN~%{(iHM4xRiNABoR+s#8y7x zh9bpz-bE25zrNRhCyXDzTz4B_oqC7Z{USuw%rYPe6~R78YB$`;yc<*gW`ieGcRC>l zSSYwbFI$wnTT$0eLUHQy+!NzVjXG!3N-I#DH50l`qesGnC#8%Np}foJAR)a*TU0HY zxbQ9SJ-o=Hdh5~7;m!g;%H#?rH0HU(@#(X$rDH-@!Nh%fMrq%tuVr;#`kv78wOrTe zmQhl4KgOC(^WCy_`!s~zKh%Pt81@i=0y#VUSK*A-5ESPSgY8M`IF5;t;LN6g#BR&x zC;9TD48rtjRTh7$KZYT-epm2jzm5%(i8d3%>PNy&tmiT1-v-G0CWn3cvit6krh!p@ zH`6S{PT!S{ZnrqkF>|%ViQp)-y6ZK_sp{I#v(KkqQ0TU^quytZo{nyzx9)v84~hMl zdcgx*+d-(Sk>j$8A$C}T!*gRs8`yBu;KJGbVnU9abuuhGdFVzTKhwk9{Mdp|hlbE9 zW#ZZ-#Noi-*eCCW`O35hgZ0tIVf-a?bX+>0Xa?}w0mK2valkx+8X&(#+vq;SrGcF8 z&d1?R&D7cplWjN*HH#WlSPlsgep8bnhRjJ^5+301=&T+UwwmA*Se31#&slK}8s%E@TttJ-o7_`qAXB7! z*p5>)7q|tw_pU1yY@!5>We!E8LRvh0*CSP!2doB?Ez`(h6l7M$JIrQ?gIYlhF-Btf z3I@aD(kKqD@Me4liki~ty>@YoIR;(ZEKB3u88Mbovj);9$Z*d0Rkn69jz-h8EV-ZP z;NhI+5>C?9G~c=FxomI~|AxyavQwdW^zrrto8DgC5VklC#ITO=ND}B3$t36Q+l0VR zRbg(}Hy3)(R-<(EXzPn+{b%ClPX%sv$#z*I$!i1xC^DG^i& zdz4zDV67t?kg;O@CGC={?n)X7)F1Ge$ElRuU0jbGV93!8PQe_PiYx9l(s0Oti~}F) z%rnm~AgXX`9RNlmi0|{Bc;QGC??}A)l<}_i&p9bCHb^;Pj1gXc zz|ylfV-$9lL!Dyb+v5yHZ?s*!Ztsls={C(U7g?ZB>bI!Ew@>p=h6n|0GlsS{2_XvZ zj@$wBshllN7gGq^_XEaO8tWFlsk#q}4f(MJ>ieNF{XV;KqcAe*OVPqR72OWsS?HJ` zF6jrY)nXRK0w8i^upQNQg8oQEf+(o_mRmu->_;$-k+-}$Ry-q&ke7Uza>FB4t=(he z4fPnSJvK3#k_>J5k(YiVw^)ks5ybUo4L~Brg@mlX4qQ$op-J^G!qe}k`5C*CB^m_H zr)O0br}w1}r-(#07V-~+A0fH6JsGsM4ayzKKF~mZe)Busli6R{XI%Ug2+&r9%WPE2 zunACg2`t?g6?0Y795Ow>HQs-b`#i{S-f#VmZk3JE zBy6}L{;q$9#?ygX?q{X${v1ND$P@>Zd(Yl+3%%Pgx%&JRm$TLQAG5-3 zx4a?zqZ2!g0RruxUKvq*xBdxz$LalXsZ&XVzUJ}A@GhGDp?Ejf)p&+IEIj>ff>>(OtP&9gJCk<5MP9{r3A|ARe!jdG(@30$A$GnYH$jUFpFS;54K zbcd~O2R95Wt2wo64C3AzWT76_ISiYim`0W+z z@{y3cbrvq92bU|sa0W~IZVzfmIh2Af{L*7I_j#v=#SEZ@iSVO@w@xbx5n69N)LD0G zMv(GD&8{J;2wrQZBoWZl#rKB1=HMr24r{Wc_p*Ppk};X$7Q*Qk_%q-%j$R-_!nA6>X%9WSqLx!`5Mf!2 zB(BbPX~=MuttQsNEGgH;42{86(STfrbS5%5+ARzU1s@l^JvOmrlbd|ws=RRc!zf(< z7DXKBG(Iy@sq?MfV?HS8+2%-o0{+3`dfhvPPxLl{d-6NYw?FKs>JQc2LL%21-p+}j z>fUPl&M|0qrQn$sMNhEDlH8jlCg=#Dqk_ba3dHqf-X)6;Du}qW`C0`%@NW?-N>^q0 zxe%_^tjB+DdT!0}=D4V`vZqj5s<*ZF_PnZhs?l*JH|ZDu12q_mWn80!aB27^V5G)X z!hCg^kBK-;7hnK{YTGrnYFII-KLcT#i1{ts+&PyrS!0#xWVz(LE0(a7D_~rm+n*-X zi&z~mF-Y?^EH5lQl(;#k!Q3xX^kpb|U*~vx-QgXg@JSQ;UPwhx+%Tc z*tD}OLUH-vRk~t0$)2=_k=fv5*1zh#7@O7Sdr8Dc>p*sLa2LwgaaLKbXrubzN5b{B ziUxcKP9|t);C4l1N9Vkuw+%r_4SvOT{Sr(AAw<%2HXMzpM2tm-YQk~s$hG+f`ONB9 ziWsanK?FgEO~4iZ4hz|Dh`)0XMK^j%YW8a#OY!!MjKWdm-WG6cQ!3Ytco1!%T;+=7`KTeIqiYm7qx}d+=)B{65n2hDP!=f!8 zG(=9mSz<}LXii$rc=+R;39UirqXhqli;sA$B_-N=aG`^l%gUUuAEoje!ZWCl%cJi} zn1s@60$veK)jCB^nZSfJmTtQ~F~wC5-F!oPS3L-ZFG$5I3)Rfqqm$7OIccoWrIS#f>nhhpE`h`wj#X!Gei6+$$q z?#uR>B>M_yt^9>dT~MjTV9YCIkMjc~w(QYzJDI?pL^_6qGKNXv(`p@y+r7C?VP)4X zPA49oQhwufT0^D+2`hKJrwT=)sa|ar)(jb7liz`5)B*;+q7d3M(!}3#uyI)iN@N(> zS^1vH1V!Sk2byY}IRm;)v1ih}wovnDc^yzn+>+muPef97!V0Je(@W1GKG0G`A*Z&= z8-)Em^-Ry*+fSNP`&bePn(~->GQ7_qV=1!R67xWQxhqZ6X7_%n=XL{Z|1b9*3r zH|{oqo}QpYPemjxPhv}8 zLI$kuzAXf(X0L}$k4=hXztNcnfSe7^8C2Q+#ORI=#1wW^6P%AwL2hF|a~Tui)j^x6 zo*=#W!@csK&&VP z8tH8~(p*BEExR8uixrM-_W3cE=!e__fsNOCUsPw-rSfoL5%&Q&3(9?Zs!w{H%waIhO|*69#CyD{mcXH9ob8`b`Q$dBt4xN z_oeNv=YfW33{38Yx$|RQvEgRcRJ}xYJJM@!DT)W96?xNeRyrO+aTJiZyH9|YSA7-% z%Jz50cGL%gr&3U$&+TgL?|hs3%@{WMsNJFc*2p-*5KP z0U^s%Z7{^@ukiH+i%>;_g1;!huTc>oKt)d&D5%Pk(bCZ9tR&l&_++`Pbbd>4{`veb zfjpF32;c{|0aCFQO#&2o>>~#pfCSmN_kWK~W;}k&3y4$CUxrchf81#Phr+}4S1xND z1n5xxs34>Ax1kXQWVHA5@8JG@c1_ak0tL64F4nL8lcSR0s9Is@08rn_bg==M<+Wy^ zcCl}@PN~rV735xFK)V94x;jiJlRL?ez-*Wq+9&Lz)L)6_h3(R4LB-go_0L4wo2TfRa6ldYfx0VwU z+hu*r^_NqV7lZ?BMZn?LC+}sp0Ts%=eJ7nose4iZoQ-N@s&f5jqtD^|bh&xgJ}{|# zfBJ|VvPAjT?J{86QALpJ%hOWd158gX04p=i9gD{relP;eT?+xIkuiYk`>yomPNkju z#;|G0mts9gmfwPgv=l&GQpp3<0tIkdD(}7e^{t(mTBp}h zt-N764|j8uqz33Km>B`%LuYu6;~WpKcG1HMhnbo&X}=S`6hJc#-G>5flNxqgktjKn z>5Y;sK+gd0rTQyqTG9OWqFUPf_u}dla3E;qsegS3C}6E*{m-0xrADOy0%$HAkoRJ` z?gl-o_$y-v(z28Xu#%e?VBp69|KkfrjUX6J8>9%#*#E7EPXRof=dWD4Rky;T{tqCK z@2IfoaeW*vpqY?E@JG6u+%pTyO^l@KJ5 z5pw*G3-FKB4^Vo)1Q=UF9~p=Zd7<)c0vn9~Xz~A2@HhTSFD_2lvPCrTi1JgXlm3-+ z0lp?ezy*S;_c{r{vI|48`%Qp#Y#DuT7#(ABLJn|sXuYkcSeE*A^60HCG z$EFKqk0V1)$}!?gc| z9*hn@irUiqPdmd}g4EMv6{shn%>Za_V1k?kAP)b^;PW6qxH8CS!(aQVu>mdA@OQnE zA^!~<@^?XPjsd>}4OoP>Y85&2{u588{p~~!eW#gm12p5i*JESenO(39{Oo`Rc_*Wz}stj1UO2eq@ z6*g-T+`wS=xz7QHt|935M&EU@~pZTXN*eN?K1TQ8uxC3Tvq z;U5KpTlfo*llpFf2z#*78F4v3(Mt&#Jq_$S*r9@$`*?Xc6rfuOj<&|^{>D1bSc##O z0>Bwy_dD4shybki4vqp~t3JTbF$3ZYk5Yjs(w%GYC|udqW)XtQ+0mH31Wd|T@%mc< z+?|Vzh9&{H;iWR{*RQ9A0f8(NK=Z7tW`oa63l&UA!@&ozh%U#A^##-Kn|GRiSH12C z`$-&$vgC$#qB*uGw7@|GRZa_m6O}_UDY)C|5B~nZL<GxBi-HI-H1ptDu@Eot$=iQ=g^%}(n^bjbaOZ7oZnq{t@|Hq9KYG$j(5ND zJkOf~#311tbI#^2x0i;X18VpY@00N$Ag zD>H7XEir1U%@#NPv+Gn`EKA3w{aStI8`gCZ;=78N(GFOK^x1N=PD++fU~;p+LW!6Z zUmSPhiSdB_*Ca9)9jgtaQ%%R$qU|Bxnl71-19nK%bHC-RXLjI~Kq2f>eFcz`V*uw` z5wNjLt`efHi|~`8UmMJ%&=GGfG#t&P@H!;0sbxxr=$3H+kppd1Fx|{x4h)O%NlQQl zNgZR-21XM43{}6*xuwWqrW6Q*YCHXo;+^y+D~}@ z9!22p`iK$mfYk(gb-zxwzeB&L-UqUx^!$F1cjuWSgfX<}+!3~I^4jR7kGARPN{`wN zPEU6?BMuoigNOp<*a9GCvq*e+AhJ3aaC0dKfMv+PJ6pDZ2~V&|^OhDpUqSBwBCuU7 z$gKP&>g78$Ilzx6YRWfmX-rlDEK&{O*X8__0`8Ik7bAG_yQplf`Di5e?q)yGeYa+2 zK+onYqmb8LTz&luJ&?aNKeOlwkIqZ;k>|D=U=X`Lct^~lDa%p6^49djnQyvKnd>pl zA?AmQPC&k~|CGe_yT~X{8Geio-(_afY`G|$EYaWBMt!SkIz8Z7X``Bze`}hqMvHF> zMxDyzG^ZKFJ@39b!XAvBC(K2T;dj{2Y;|$CjuvyxTWk+l^|30V7brUE#GJ;4x0gGd zc7OBi&HO_+y~jMM~ZKNOaYg6+h&@tvT~a6)4zZJzSSaC^*bJyu>vpb z4)~*e7Lg*>0op*TfHsigdU<1H=TFt>1Mj=-0tp~SQEfoxQo2nDH3`i1>6w3OhkfI>H z1oitIP`yA)OS_j#U|d})DiyquUneC?tq5F@c9NTR*LAd&kj4XMU~BHf}rQ^ zQ~EH^7`GtqjaO%jUJ9EdUm1akn*d4+_X-Mb6y)`O+c}9tB5>mmQ;Ane{1#c5cj)KF z0T)(JLA>;fvNwW)`ChaEmx3?pFK6S{<76SPQbUhn-hj=k4s1@0m(rjh9@`(wOd+C+ zmoSD-{RRej#q_`woY?ug9&f3c8Q<$X09y7yC;@$V_u+P4I-doQAGosFB4>=$>dX6v zPwFmL(}@r8)uiIjYKmrcz##@{X^bwG-a9w3i6FM1HGuQxJ@DwI@*>SZu5?`t0Foq? z09Ay{kR=nzr#hRjMsGpV`PKL4WG3~_3+Qnyy;;S*0H$rk6|e2)be`Momn1Ux7u4ga zjnQ;Ypjf~&vo@GGdffzOy+{8Ia8?I^5XIWP`U8Ll4gk}F6Se5I?B5fC%fpopE34XD zsd1Q*2Z?_xpfjTmN>NqDh(`!1?4YRxJQOGezq2D-`p|9|XREAxEAUCPa47f`S#(Mr zd-~Eun&4W~==jhsXFKs3s%D27j;tLCJQ0TagYi8;O2_Kkr4~^!ICy@qOe56t{2F)w zAtn}7bRqZGV%l)m;mH7N*_UVEfXc=YYzdf}wcJ$a7_e2ylaODx-kcgBjg<$Ov9JE2 zfxL65Gw=T7K4avC$rT*D2hgj$2VEk24YlA^bjtI`Bg?AZ1=#^RyB;k=9SxKak}uqD zAJku8AC0d6{6ND8`PBV@w8Ol2)GZb06tHEWqM*4imeeiTZ{VFLJk^j+;4rdZXxCk} z9!jDEHZiKK?RIYH-7~mu5N;7;&|B^P;l!%XL+FVDu)2U7pH=tXUF-!jM$493B=~D% z80}f9af?1j^MQD~IQD^$XG9t^YxVtWm!!=Z*xoBvX!v4?)|{o+{#pQsJYVQVH6Hx* zVLiCq;SMBwtQ8PK6nN^C4swv8&NF9O#Jfc9JzdzK6Xd~I&kq4MKR zB2*ofr{WX0m|+9BYMv*^Ei{2d)`^e_4+0lQ)d1u8w}|~@{`cxraoUHyfb={8s}eKn zylKwXx&sbKPV;AqP%v+%P#f{LcGurb5p>$&Biz zmbdve=ZaOCKFYzb}iXbwlwdARD_B ze+J$w@18CBv{XO{BYr+~4#GT^ri)O;QR)iz$PyAKH~?|LG$nhy zMUfK*A({KtZk+Zk-?$sRLla$U1hoA{1n+uJ@Ebs{R5Mt|af)XR}-DVzWFyX?Qh8-|pZKlPQjvu`Wc4h)Q z)3ICFhfn6VzZ2sTMYN=3pCP39#q>`XZezrN?t^;-)@}4dKuBGiam4 zD6{ESh!_aWB}2SD?C8=P-#zbO-P_}5D*#L6}XPVJ;azQ}tOI57Y|W(&-Q3t1w9 zka|wWaugoL{)X^}+=Hy^+**C^b5N85ug0#onisxtqLO@?it1G&BwXwIYZ1dPGot#6 zY+Mw?ax8TZa_<$!z)Rgc>^X+2SOBdxii+kD`W~@5b<{$f;{ja|;!4UgT5O7! ztE-OtzHW0VqQU?7!vzNi!y@xYltNf~TEEzW%8|@|^V6oy z7j)QpEgauvTG%YaZUM|~_)*2?-Druy+H7>E`r0SLiK2cY^&&0ihQr3xp>q@V6wbki zLoufkJ(x4yGd{Y~oW@UoRBndOUaJd%5O;uh?awS68GT5J&&FuLC-iI4$KrJf59t}Y z*ROfX;{n(-H`X|w4=bA#x@Z?e^GOq%=g=`agcb!~*F;kKqpUW8SpWlt;`{bvG`LvF zr8HWN9UCZPCdlmY#_N{|4UTtyupG%AzsDt6ZFvl@wUVp!OL&s^`>uuz0!W@*SS$V7 zZHnhGw#9gLKX;*n1HHriON(^?NmOBVj=ZY7$2A4yrMX{8#1pNfqkMR6%Mr=z#4c6V zC>?NN7LQ}Aw>;ydLWBIz@^#)s##_i++Eg)##V-Id1F@kRfB=0Hm`nc zA{*KMi8?gDMLZMsSY+TBq#FdrfAs&wsI!Efvl*wSo*}FDd~_r$FUj+J&&eM)ox}#E zy*KspbHX<-!^w;AWgnZ_ugBEBuV&J{{+O?%L`98fn1y5C`#JhpHW3b?NCKa#QIeQfrz@nkAAs3y89Tju9J9YHmvcX`gjSnQU$ z`e;;DWC(ijmX-Pde!1Dc&`xocdULJo!iq}SRinYaG`ul#p%IVRasX>4=hOB{v?lEn3702|j9@Gy zD0{>N4y})ol7ib`0yv0pf-y_Tb%l2pPmyaZyb*vM6WX0t*FMV>4tymkk^|7u;kF_k zA8lzb2iE(-HZ9)F(}&drG;E3Qu1@;~ODHJn_PznFEstUJoYB;ywUkOPCQ*8Wzzexw z4mxq;VcHChMlE<_>1{VGZtG?INA-KBP3yyS{wOb~F52Do09**iR?UR`^)^^i7Dmp= zGHXQ1Vw79u%}fNh#WAhNVqLmF<(Q{Q;Bo8q&F1Td^;;Rs{|6=Y=fdH`_I%AXQgisS z^FdJ_+=(F&NnKF8Se&+3KsH&u@s*v%$=g1aiH|7rvcnVEazytDLYyZ^+GQ=LDg84x zgC9`mz2x`l#i$9IQOX*2P-Od4(Gd+(VjwWGc~wp#y%6JOoKY@t93&=+f;<{mkR>+J z;fnJ1B(@Z7WzFGu-GvFW1n88dzDeiDRg#|}E8Mx+j-R{jAH^_SmAgD!jB-pA=GWE{ zR)NuOj>)+ZDORnFphGV+0}rKY?Wg3I{En0g)N?*vWQaGW0|B@sx;L-$Qx)w~vwurn zr2@Vgmr%}`q&z&R64un8dBKl5b0N`BbDk|qhI$!By<+}9R8P7wZPbxlJ**-iS}$-l z<*vVwGog?DOoVN>Xo-F`v6OG6*7Ed~-o^IgRVER)>-y?~SBceR=br=&&g>&UA9i#l ztFH|dtwoyfgLug%790Daa@?P@;Wk-->|w-&huJ8{Yo!O;U*=KGwW*|NJz;NIPNHwS zIgD-QEiMD-<%Xy6sIL-Q?g$!o#(TpDYb8#wa$Pon=ESmJqw4GZ1v;(NYA%1RNC)MEgoi*%=xdc0|!hK=(#A z!jOHQe3brW!6L7U^cK$>f$e=F3-55lC&Z2oBHfWq7xh;>!KqWr4A1Tc4nLn3w_|4^ z(W6H;1GPv>n$wVu@&{@i;XCk55LV3&nSn@l!#DhcRYZ(U;LS-QAn>Cwj_u?#;!HX( zHUIE?Q?t`G(R7#zA00K>=a`zkYG5F>_Me7rjqR)JIw z*zqa;v_E-hh|d>Mv-4r%g5=XZ=vbz+fa+lyU4?HXn;U^TIdj`IihX0?e=e4ig*S>i zin~wCk~Eg&qVD60i{F=qU%(+mP(Hrc`6 zLnSs8SKopku^(4zUhOIVI6LF;t`5);czqmN?YE`9&E*#(pu=Bk!>q^S|H)g_m3hYY z@0YcaD--Wrv4BMeC)UIx?^BnHjtljbiA-*fBc@DN$^T5tS~ z88Uyp`CuX^XN%7XH>d6`vLsphGe{(ejwxJ`jmw#$n{gKQU^0y!>9=I8}vf723{eO@-Ty8m6mFRYIE*iik{y$qu8x6&}H4`yagQ`1IJ zT17J301{jMclAvkH&W?5?%kF4r)AeF9NTeN$dHl!Z68E-+Gj)DbP0+Iv^ z^@scb29`^s!~A)8n4`WSYNG?d>Kgpb2)-W8vF5#`-8&Q={>{+g%0P2%+WScgLlT=d zGLa+$E`^0nga0o6LzTa-{P|J@|B|i!ZVV0aAhkAWP%sNs?T=6RaxYf^BVI90t=N`_ z%^@7Oe7sGlmEA>po7WV}wwiMXR*L+qybsBHPY})qNL{T#5|B7e9Uvr0uz~KUk5PSQ zfU)MlW?m|kG}k$~TjQ)?u#1dMG1k5;n<`8`NVU?ltnIs;z-|yeMY5IkfJ+Q{2;vch zm(=BhhM}LBQ=|AZr1jS)R>fpt+V6ZLJe8sdJO#?2cLr%kq4&H@3;%<5bZM6zLUeck zZ7H#ECkGBry~?iZVHue;>}nK3I1>)CFugPKb%ANe3t<(o zp{QD1EjDdd(r{qM*f%>v~UvMdwv?+1+@2kZ}rQ6_}<$D z(78%jTf(Z| zXnf(@@kH;S=LK1fYp`GIN=y063{Q6CQe8@49>1ZXUTNgOmN)Qb{($V`G(rCEKwXVP z%8tdK{- z(T%p9hJH9fEeaPB^+%>18ur)Y)USS$v152Io7M=du63~)3>CjKP*<>m94gmJJBBt= zkB?D5n}G@$xuwuyEjKUvh);(jY$lZo6i(r`zU)U`E&X54U1cp6k0YcK?$~takHVK) z5GT6CyqDU}e6JWisAl~L zdefANPnxgpW2FBCKLY<8((8QvF*=P6?iYhz&vdeDouKinhkIgos%{<8D#D%Vp+L0O zPGhvtj-p}uvnrt_;YJ!G0kOHG9lgv~{QNBTs_ZU2*gYVvxyR~yq5NadlznDso=UXZ z-@67D48eQ!k{i{L2UIxs!JgA)1woUPLY$zJW5EC5F1wV-EzYN1<4oeD4r@7#rF`S< zEqNmf!rw!4CTmo4yE$Reluz{Rc3{WQkG5W_OEJaZ(K ze-y?PU8Q?cPHO(KIzrU-1S)_hdY*yATb#%kV#jwf4^#hT!m8I^Jo(rCl2_(kjkGyP#_*R z%@>8?&BPVLf7QD>kSTxg1zf)=03z6A1|4BXAnhx*`-N+BF_fh?J|swv&6S6uB8+z| zHE+xly~zfOMC+9XH{2|Zt@5dt0QtRLkOkt^eqQ`)`d6PqI-dELyw2T^sByG}rS0;Y z8<=a&6tpOPP?u9hT5Xk;K_^`;xo;9$uRP)65@zw4BkUcvL~nINmG_Omlfh*rZJdP z@8Gbw&bc+#|u1f@z=$xvG59rP-a-Hy{*D>kZ%3)Q7NVa$8b}+U%ErZ#Dy=% z7(sc}4&JLf}qOfCu?6gvQ4RU-OHhQlR6~`*{48iv^z%zYpt%Ni#AmOei5n z7;YA)01CC-%^-J1c1sXyj|9?wKEAKq$8%vxvuhxW-3jQ#Q)fW0Jh1!7vZ(hUH{~s10u0s$t7*Re@^fm8a zQJDNX8#dJcHm5Siv9x7l(;X-+%HE3^ng;QA@Ta5^PGsSuIv)L%>Rgb0B*9aY`b3a? zqdOoL9lr!alTI*M){s8}`-s6GKc06%-EHZD=$SGxhXC~B7pBG+bL7zzntgPe8L3N5 zyhoZCiV;3OF7=?wjZ@b#7pVC3zd^f-XDFp8D2usV$hsrcqTjwE&!(Y!n{?SYKK(>Z zM)2X`k(2^5v_BqXI-~}hL)RF;Vk4wKOFT}M85{oKIiy9$#ru1^<)=2Sk+^9Mx6TKHN4q8@2L%XU*6D$?ml5JASKO28%&73% zr5$jiEB-Pr=DsJ*BjFdnVHoNzl!(xDZ;O_3zB=9Q>5!1)X0u)MI!a)!x>$2;6^nVO zK^-pt7~n}_3O)`FrfV|QBNwD9jKB)bR7=`Z196K;pUS*}PxNie)L?JO`4E_#fg1ZT z!xyF*+9Sp?8ttzS*>4MKl$1L`^@A*oI*O;Z0ET_zGTVF;_2s>5s0=@ORYwBGpe>)DHAGgrt+AtER3st2ul*|w zx%rbPw)liZmeB6-Fk141pch7HmgrAy-mHbve|uJrS`UFSSZ){xpp8BALc~dq!dOh6n{2!!w7oT|b2ieD zNtPU2J4M#bcSXXPn`=3hWB&16oBf#1?fDMc1Bhz1l_&%{CG7f4eJT7Ik`PdS$$~Ir zM#J5Yy%wV;_0bHIX%b#sW_F;K$4)i_aj=O=X6ryCaTwYGsyu1f2>_>hq9dP9`k-}< zPk3S?_X(T)DHB_i)yI{rk}mGMPPGZM!8^|^{B$OOA!*XIeBAA!WG8sJ(EvS{Gu+)! zRs4O1(2joTbxAAtVwAOwm4UgJU6}x-G^-N#p=yAREZ6R6BS@b=Tf*M*pF<{&@@)JmD;Vuf}--vc-CG_77n8(AaRetX5Ale0nDh)I;Q)X?{+t7vc;s{X=Ku~YPR_{mJ zekjjKWp83(hsNeqAZgF2L4r1mHrWD_s_KCkufCXq+9-}RZ;Q-*gNW;ww9agX@w!Kj z$PA87dJv?#FTk_Y>dZ9XLChiWO>Ce$Q$;pxw#P3`F*ubdo|rB=B9H*TM^~S1Yc}1C z3|a|MUw99BS95yNNOSJGv-9h9&mxB5xGNqv4J~9$xA{%Q!s~e_w0ySNABT>ROoPke z5{;c;lNqDI7m)m5SWm@VgFo^#q;zWDQ$io()y_ua%J$CHlD9<-RQN*l@<&z3b*g_i zA=Uz_4;7r!52G9=dk_i0@UP0;Jds6rN6W3D`lVO%P?oE;+U#S`GYX8Z%Rf#_S=e$n z)CchP>DZn^hsC=;PxnkSVm3SU^U1>8+^nvIWb*Mzy93!g?KAQ7@!%}@7XR!u?NPD2 z<_bQuaftGZEL2*E>BAKOyMH?YRM{O%NzO>p_u0(K#2=P(y4`#B76Q6s4eS;??H8;o4w< zv?0(v{Gj;f;~p$~1F%~j0%FsMojY38CdT505z_H2w!>nMiUa2HBQ=0EwFoq|a1;Pt zLTbM?QfeV+P!40d3W4yY+Nz;0z)eLkh9B7(gGui4W*#AM$JHjdT>0{Krt$6XAcmk5 z&~1YP8;?_k6Xh3S&#|ja(amP6pgc8YtOoD5bn*-ht=d)l_=0q z2o3o&zRe}qA5h9A1U_3`{ZfT|#cRXpQ$=gqqX#H^<-bwgsmP(4#)&Vk;?)&sPd5 zaV^CRVjBEn*7VJ|qg0e7e9Xwfi+{9h&=yy5_Dtx2Qcx=8FmP<7kM_0}?!}o8(BYCr zhcRoy4zfj%wqN+*^q{bh1P^gvgmEFRFOGR$iJ zW5;($0;;OC8DDTTT$aiu$->Qd(FmeBAG~c}rA|bc=rHhTb^T^-3M6SLX zQ}Y`h`FJ79{J{-uW7iXXmAdV4fR$*my_9jxlj5rJff5pJaklO6#`jLfvLh&$-y_@> z)6KM2-vv3@>H^T}_q2Cw$Lrp;SHlq~U(0EDHo}}?E%Py#B9QAp9-o5olpI%)iLdNR z#)V%0;SzfcO};A^yt2oFi&~AlNPh$#qgo|_Ag&gzCKf~dW3)$P1v)QgRSHRhFtAf7 zM7ABMbstnLoy*t#G#*t*4TyC(mXasfKyuBgM)eWfVT8R4Y5FnK?jK-nvi0Q#EBD*e z1n#%YNfgs9u<7pl%`YCGFE|TANTU2R1M6~LFSQr*j)^?Tb}@a(FN)YOO7#ttKdu>N zQQNys+kpk*ZG{O`CLY^RoZW#y###k(n+^2KX;t1D$7+K$&5b`4EM>uGLhVRq6I9fg zcGiL?-2*JG>-d-+=HinQ&F6=yqTT|eo@zRp7Ol@esFRkl}jJ>W5lHz6?tAu$$f zmGmZb(cO}rF}5jN_JkZCGEu+N6nKP&GRh}IPy;c)Ab+J1z?bvx5Oku4h4eX2q>st& zDe_d!11HWt4u~eB32KHkgJ3|y*|$-zTHLhp2g}!d7W^de|xTmPwtZ6VX zQ%;HSIWO4Cr>b?%nq<4lOXKB=5z=W0ekK-{WI%>zJIQf$%q}-Ol8^=^wr-_2zrUAY zYB-g3bW*5{mWd4E(+s3TjcAi6dpb^+P^NW{l2y8M0EOc_-+We8RAn$t2Vw&GlH(-? z{IQ%-hAHE8C@#U=4qpLoap}zQ) zKU-ln_%N3K!HdiVvOA`T5r9#4B$SQi2w|Ag9q-G+X#OGHDhL_e#lxl%K(63ZhX)e| zI_pyx2i^C9@y6`8>${WVQ8E@QT^A*!($EU-x%M9(^*43oB@T-G&0K4S%g9fig5(pY zv3gfqAzj!oYtMb@uw{T04D;s(8cx9o+a;>6sVw;K!PMo2p}mi;!;^(Vp594G;T8K$ zK43!PfnfNlaeqc>2dJr3$K}>VgarVkDsA%yMX*pIXiC-P7uDF`?-b-hxqgZp0|7a? za-~2BDP{y*n$V@m)2+XbABZ1z-S+XzM63ZGY-;wxebzo`J(#UH06@s%0PH-~{vpE% zlL;-XPcZ+rxE5hb+r>>=%X6f<0{hkTFv~P?2Du!3wa4)>k1c`+;-VC06gMh{xJNBH z7$msk)SpQ5;K{b~*e2-p4V_(Um&~{J3T&qRUGf<5pE){ywb*n?LGidb{(XAS51F#65uOutMTtqJj>GNyRLck|PVLb(u zx~C8^*n^CpmYBa5S+t97M-ta9F_l$*l0*8vPoEw1NGem(Ch#f`uLzDLuOC0awyU=Z zBYtYm7NkqmKbjUX_@f_|vQyzYa$Vl+_7*)aBr5b#w&LfZPJKI~J^hiV8~MBo?O!aR zFU-lRZG;TUL8)!zeQiGx${dk08w#}M^cdIl(ZL!D(Fot^D}8B5C;x`C8b){nM??V{ zK;de7*;{BLwF`QLfSi+Uf40wE`rNv2kD?#Med%h;p_s`uf zl8@X42)Z#}b@BQXrXO8fsNnZCwA9A~b|bO>*kF&ix)&`8?Q80sJY>#${I%fY$M+jd zc8{tAY_K5k$ww)A4t!Fmz3VVxuXe4Yp2s*~Jg>E*(;Q<%cgdQ*B!*2n1K?s0v{&A! z_|y7eBLBq&7M!mQaE(aA$lX3<6EQ2x0+=gj1q#$DC>`XP(xw#VU3HK%(|&(I9iJlH zA_uv=qkE}`1Z8t-Bf2qtsuB|Jpl>NGV73%V7Ab2YG%>>GO22<9g6@G3xLNbjLOBo! zu&&vmj}(3kV1RL;=NuWUcB|h7PBrM|G+ZBS#13eIA94Mz|MueQR_G^55!465<%?Z) zJNlYjmRl=5HkI4ux3E#5xqM;)r8;G4ZaPF|vO_dcpB$2(+dDxYASo>j@-Mxy$YeMF zqAe0Mp>b1AD@cc*$XyOqjX^i)z(=mP9wsO9veiM?V7i1%*H2#H9jq^7KV;(y(}o)5 zP!^3=iJKOmIyzQ^bO+z1n!z_L1^|_Rvu#>lst^=hFLGLkT-w1}|eICcX*IhCI^6D!7VX@FDjOnEAw*`La&D$QDf<49#rLbEw81}JPZHRiH_nkII73&VufZP7C4_ZbC(Cvo~M%t zp;XSw1Z{opd%V4W9j>iFf}sfq8jwz9fP*7v_$dXjDQMS;Y1dZ323Y)tpXBbJ!RQO1 zqpC8Y_rCD)-lFe_k=No>v-|qMvuSRp&n);xSj7f)pUdIEH5{LEDJZA~$hU&Jnvw!> zxORy??-RYswLkUs^=t*1?Q^nPwBjU502$T~>Tf)N>@)UY!v3Rp#sld6?FPEk4JI(F zqJ6?b-^afm}F*<$JIxwTZ5vr&FlAk8x>s$y@m5YFr zq)d^eG-+J`B`83El!==eI6kQ%cr?Zzv4EPeCBI#c)y?d}68xk%@yoNgdpbc*+>HBwv=Q}SVAcvU zQ?n|g!2?lfC)I4beC*@dyqvgMU zfRP-ifLrv6X zzFZOebuB=dX9P|{XUlH+@EQ^nUseDeRjhx)x+7?(EYQx8zu`4-~;ehi2o zS>VZL#5z?E?rAU?{}00k>EBK9Q4@@TzQ(57_&?guvv1%)E55Q&Hp&i6~DV*@Fy3?*8e^UNej^g zo-HW;_`bEI>@HbJ;(r_^#e4D+(IRQ=y}WF{^OW>|R3yny_hXqL(#O-eADiNTRIq%& zE&@*u|7Ab@^4^_}^Yf|t-zu#bfsH^#7kzK&vQNXO75||emV79Js-eRLnue$|7W1*PtD!PIwV@4eNmVsRfwY+2 zl7YqW4myqwH`+8T)~MCxmd%pN2e+c`-)#=eSKOhNN^nGj6HUY#i#@R7#2OhtCasXf z&cFemcG7nx#FAu0`7N2VD#%EJVa+Yu@58KBD{iWewY{uS1#K4w-z)H5lYBi7XoyXL z)vpQiVO+5PNZxX$?gCvx9tm6j8ZNfM1!P8JHHAxr#z z+-V!u7+;y4gb6H^qlFKz2o>$BfJ67AISO_)9#oSn!7|qux#_S8mycAgc0I6fSYdVjL}=aK7-}2>)_<^}e6mV8rm- zkl^DZLH|P+fp;T`CLCnXZR8RJ(**qG0fx?D0LKc;vKb5l)HEv3c*<14*(80;t3oZt z1ZWvbz*64{^wD%4~rIO?Et;#zs^kF?g%Pf%C+l z?;cl9e`mjitz39)uGQGBTDI4JbHDP(lkbhzV6aJJZJ7@74Y;;$BIeLm=TJyrTCHg{ zmO+!jqmF84-x(yiD2*}J*i@LSw!6__Kor%r9);kz%rpGl6V@?eA077ADs9=`2y*wk zi^y@`8f{U}v+_;fzdM>qXS{7ySI=3Bop7G*l5`66{7vfZJ!G1Euwk85mv`L$JHGN{ zcP3}BJ{kNsF_hgSBaf2it2tJ8*ZqC93)|ul{+#8>nJE%CWrg zRiu&-xlj-BmwVLI(%kD4oQaq8r%_B_FSqnYvT~zuTO(m}BrV>Cx>YBHLzhv&ee>@& zwFxJdHTOYHIG2%^rX*LQ+umQ-8SZO1f|I{2@lo0?Tj#@8#-fekC`z3*IYQH|*xpa; z@xdmyY{^wtXS0$fW%Td79=0-w`8R2#1vtOIzG}sceRXHmWY%p?Hd7NXEaXrTSD*FP zyLFl^ja4BxJYjp^pJ43Ge7*a}10W%NkW1X-K4Loy z_-WN}+4z|5>08mAt1gK{%b9=;s%-_VjRqZzV=1#1CPv}|3aH9gV5eBM<3QD0*3j_F z&{rXydo?AH%83GvvKj3qg78TzKeAB1z5V+=lDk@qKDpYbs6Rk`^!4FXLd1ku&*P_W zIwN|xpY1l39-jTR;9gswu{uf}ybfsaeTN{}P3f=aUs6GV`~7%bU?gYXTNCSRKOK$z zh_kPUM8WbhXz%dXv{8(R&R&#C>qsKcL*(DQ0aLl6n;E+VgqOX`(6|&vhSJ z$}cN#EPw4)O!T!EVTtvrc?2oka#~+&5Kvg3{r2u~B6M@DlecKCN8O4c0P&>Zo1|Ux zY?V>w&P1LHXBcxN_wDX_Er*`7<3L0vtK)h8 zOe&OPwB7#FY$!cv=WaD{un;J^mHfh%E}$m*#v!;mFd#-)x9#J+&$3QaKxTynQjy;1 zOLwmm8NzIImL4w``pBB!mTWHbbuJf z3wiB1XqsybUk6l9`8Bhryf8eEa^!b>`jlQ|hJD{{_TN<{4Dt`@2(-wI9rP zc6i?F1HL)H6l(4j>nm74_+wY>21!>E5}k9bmOcxJpi!=m6ns&V?dJcXUqWe>anUNV ze}}V`R>#;#cA6uZxo%lU%3k=#gj194ew--Pdal8s+!UIU($cA(Gyki%G@XlAIky2B z=>Hhx;(4AdeAX3ylzXn4dVxA4=nWeQZv{+Zc@S={0p?eXVFO`rHwp%vE;T=9VqnqI z%H%Q-=m1_^TD>*rwi~O+yWplCyMA_I1@N2M-V_DuZ3VB2-4dG*_H5KM4sbEMsg~~Y z!UJ-Hj|0r$eywgLy@^7xv3dQ&inJS!wz; zaGgv2h{G^y`=+VCQ>Esip~SZ@enut}iqgobVoZ@Wd*;SV^*!Kp4(Srengmu#F`e47 z%HUDO^?bdO9cKC)!(k-Y9^7jAn^cd_zq!J?nv6$!4D84%w6hrO%~6HF^MivuGl@*P zP?7ab!G6tx<*s^vS0ZE2T~9e&^z=LGADVxv-$Q?>VM_oKA~Ao$~X&30kCYjEh7+QV(x z{@v4!=YLoL7PBLiVl`l+pUOO-j*8w*m5X&Al}rAlg>!(Ei^uE0SoCNpA($wHVsQ1R zzps^T5%Z8pL+OwUq9mYcuhMLt&|-MC0Xp{v?ZW88&sfFlrTous+@~iI8~fGmw^yBB zOI-M~{vBbJ_Im)#;XL*&@6Y8m{c2h%#qzkHEUvSf35(e2d(C`3&@tdC%LUd$Zu;Xg z33Oc3`Ky4-<(b@oYR+DghGBG%^o1XdaE={_>ORqx^Ao%P1yV}br^O^F#o3UQ2 zUqd(rzjEv4Z`S@4-oKq>v?voJQHq*!m>YJLzZ6<`->u`o7WGc(^n~rQ-Mo&|j|v_2 zTGSt^P(NK{Zhg{rQ*N+ie6HRxIAi49wNUTduzKoUD(6%eJ6}M=yr68YOKtq7Gz=%D zZbDb#wg2h2aJ>dKZtDRyqn!oLz}w4M;U78a#BDdq{W|&OmczFyj*rKP2l^8e%a0hH z*a;OY>tkH;{OeX(pM!2oH`uEKyC)rkG5f#8d#sFdjEOv`o+;=`z4?JWq8O^H%Q+ym zt-I>n{>fEin;R^4pm~`qx<*3YwIOq|IRC@vu|CP4;@9E5X|nb&&acl*nUK@5FZMgm zB-d^sdq0H*+TRRP&J9XF{Q1tbG^{jkj=JHFjYc(gRZGjx8Ik>W z-*FvscIuPOJJHg}PTqcmd+4|f)O`FqQxxD?hA-RKS2r)3sP3f|cVsg9#HWES7^i*aRy@J5_MVitdknl3En?6;0;T8w8CbO>eI zcUq%CKQv#592c7m>;8IfGt9JGxI}kj;-}Oj{CxsOTk4gE4(FQU{LLC z!i<3EP-LB7T~;-elc*KbkE^;#v3FT6K_>RmX!k={@uPNU&vT!1Karzg#La;bF7D)Zp z`P!Q5hh`7r``vYSdNzWw@efIcu_rZPg7{l|>z@^h7T>KeC_DFlraXO-eB!JsvFBHw z;CN?S6>ii(_p^wU|F}_Sb8tXFV}0u-seU->^U{6QRb{O8HG{*?SRaii6j|!CY@8RY zA7;N;tUHo^z=e%g%-Y}BU*3FuKK!8J*MOh9R4df|7$Lg7SS}4UoR>>^{i1|(=`i(K zhHnRh#Z|!K1giUW-%p0ssTgwBk+wS_vU3jwu9?zD(dcjc5$nb?cx<=f_d=d_CbanV zzmFu@$y(Q(1S$j5k6pB9>Q7rQP2YK2k9-xOe~x|K(aH6NjWnJ#pfBJ=c^qOo1y*Y^9#@z34NFULG zi&1TARrOFw^mn;oQ<2xm!d+U&{;Uy7B4@yz7Ab`tjJWxv;`ekZ5{Xdh|G26xU&(+Dj}p zF+_|xXTQOuwE2=ed7&vQ+^|u)aoQgiWT1o5Rmj(Dq_L{zD!!7-pTHE9P6Yj^)kQUQ z^@U{oD&VHSej`FE;6%GU1%pdFFtg#}MYXE3|JSkWi36MU%Txt2-RiLC3pLmZ3>?-r zIOW08bI8{p9{)A=+xX@?jGoW=w+A3`RE>^8c~GxwQ5yLmq|HE0z!G%*JVYRW+$_Y` zhu);+`w@_P6*nc`&d|63RlylazlfvY%fF3NhljK6+-6hO$YFeDB?uCYJ^1g#^^LQI z)`fW-Y8%=y-iiU2`Gg2+=I26m8=RW6x=0nL$hyafm2aR zt&{s3fEDKcu|c_VT@*))#7>9oHZ@Xcma?s|Q zo*LyVCfF+)uMa*h*3n8iBYVs^u;?^*c2u|Ahp6u*VuOR$rH(mGuYX?l&fzWSE6_Fy ziP4JxHN>CkgVH?YuXrq2Kn#)>pym1G)V)m#kXZRd!fHA4MW7O7v)>18qv4Xvf*w|D z+j)1GICW297&!fs>tPvbOssD+-Hr|?L<9GVKPp_AZSp*d5t zs+H9h)S?s3C78CojGs6zJm+N7}SPBj#bfQ&P7Fsy8Zw4ak+xuID7<9>t(QeTK zuehB-M#!&UEPSSX>(h;&F4c8<^6zD+e=sZq?U9I^9jrHmL?PVae8b%B~JK7s-A=$w`|^C4cFyTn|-ir zl8BDZNL|S)^ZvszC(Qh=m)eg=FX9wdys{-wN_kht zv^_j3pJGEm2rCwg6*IxRn2kxf6FXb%DJ$(0BnLaFd^fgYE=SyD%NzQD$Cay|%eUmX zR>&vOyV9oiAgM^5r!Vr+yNA>L4V>HT$!gN}{>phyfz2peic95by@wXMnBuhrR05Wt zv|na+B@NToF^$ATV3Q9({shvCoZnEN+3z9pD14+T=sxct<+_0C<17yF*aGza6P;h6 zblTvEJ5^>IgGQi*Yw?;>fjXM;2Jk$7*kV^_a0+q#wfXy2_5k59d@qOFqipBFgRRzN%z zu^TXOnZLjyRqwS(zK(Aa@av|>yaP|oys)OGH)ExmyarD~0r*_sm90Wpk_k&d`X15# zZ0?8lJ8I8Q@R4?<;*LX*l8LC6*RL%PUSY2KYlO8q@7YC7SYnU`%i`ZNHZpHxCug4u zva@+ZK$^-pAeCZo$U5#~Y${nd77(#sc>i*5ng>%{h~JH4*v91Qk0A{qA}>)w*4Vo) z<&@fF%(0D8^lJ2@i~*&n6k*=;h%r$vefYEoEMSP@*@5)@C<#&ZGBMA2z*T{m8@R&kjh}JUC#Rf@_ ze48YggncXyx!lT#!YUwgR`5z*Uhog`U?lbaiRx7Lq$~DX+ zuVw2l@D5EeD0aO^YSn00`(3BFDsy%Y-^ljNym!4_abZP$Jsv)o5Bq7}C};CggQdp1gOGE(*rvgTb$^T@fmydx+fOFk$;d^fvjeFR7NZYB)^(+Nlb<&h~QnxXc zu(D7sKsT#9UOPn*zFte=X0$Uq$186#VRmL?eI|%~m)BS$GxEdO7$QX`)en6MNd(s;9B(`2VXHwnG8`V+z%fL53ijXtCh)3wp zQQmkTw-$SB2fdanuAF3@bSn4cWZU9OUy5)v|1CPD-V>7*n;WQ`<05y~>2@tCc#Y-9 zyr(>9{KTC%vYhe6g;{a-ih50rit%izqKn`{_QyJox;=Q!A|4B<^lGk4=7f?c;%LdW zE(MlMklfP+YPcjqZ`^9=F7*C%GEy1-M3#nBX|m{h8NiUei2bB_?%u16o`;$F2?NzL zaz+ZhuNBqIM~teS^ddHIIfAqd2AyVX8c!xvI&$y>v6L?!>}=ogq}rMby`1h(Ngl9` z(!{6-@sQy+()8F9L3^Q+4%VbCG!R~}dF=j8QBm2E*Qd_EFPV9S$7>^i(V}LY9;GNT6m1$=XUFL2CpTeJ)LO5FnoH8d*x12z zm8evzB5Aiz3$$vig|9pN^zuOu&WpUUdK^Kj6a6QOh7@a7oT3vAPX_XsR+`s~Mv@*^ z(OI|*J?nBR@W1T$E_@`ofAzfUZgt`Np=K_-hkDb~p8VGBh~zKPv#=1JBr0bClSy?w|L$N5#aaA6 zU*w~$SD@qol%yzwT}qC=y7by4m3WPwCD}gOw|Rs&c6DTL0Tn^R^F+g;R63Q{{+F#5 z(u52bT@5AF@u`(E#6N){ACc1z?iP@0N7jC=!1;j|X8Pa0=g0IZZ$e9hhksR!P*3JE zjF0L5ydJDQB#7FLhuCZ$|4bipR;(+X`saiaN(X1ub`+ z=xG%j=aa|fO=^pFqGf$v55QC-HfA0shhf3-axeLm-~89 zY@tiPM$b1+HVFMc06}^n&k;&LtbLFNw8VGX#yvo`L<_j|Wt<=F9%!Yh;duXvwDh6qTkzDdM~n@;GvJe&qt3rl zx;j=3xEWdZm^8pKgbpPSc>a}XThInL{(&(5aa^ExZ|K;6{;TVzqjg<&iLZxF;Jnp; z2L30~{y!$A!zpi5@|nOVfIY=94tQk@c#UfiGBPgjzf$&Skjazb8={=%;qmuv>Z)Jw zF2n$Iz?76pgFnI69q=RNc=uRK2p~Z@s#Q3D;GY!0y}i8?fG%=~0#TmHz&Mn`4nU|Q zz)E4f<)`ZT9$bS|G}EmQ0m1Jd8Gu#74{$PF7J;KHqdF&zBh$y|EHfoxViPrv}ngQ5w7V1YAmuq*b8FwIujx)6F@$l@H9!(lY2-Lxu*nydmHPN01G4Yh%#e77-|ym5FEu z4wX>A<@Bo3%GK$4KeEaUekvqHSULs9+-Qt1aO@DdKIl_tBk>^_bM0*vdmi%k+h+WG z4w6VHr{pv<5d38iylTNq6F}F4?pKSBPZ(uS9l=ivIY%~D=TnWQd%l#Z=X&Fqu}sp6 z*7bYs&#iAO0U~Jt7+N)qy7`6!JQX9)$b$5-u8ini)EW3*RP!x! z0*QU!DDMVg8T2UxX(Q&k_R0bPGshoKyY;An%XFcc3d}fiWYEiB$_1*D=;xQ3EjRm< z+d)v=&nG7*A;41_az}YMPbLvzm9=_W%D}P&Luf+SkM~Lwk6}HYX9* zap1|c!O?EAt(N|>H~%Hi3uO~7!rE2)0BMthqoff-GWmZWl+N6JbXeZVh7e%QI%e$) zw8bI1+up};<2{&$vN#Vi{&EH%Z~`9}dRo{e3g25kg&`?;UE;3URqizV;Ulku-WHhmM?i&024u*L*res!Ecj=4Gmm|SQ!0vw^%)alcH5Dd?@%Jjp` z0&VfoyZl=A6zl(ZA`R3@f)Y^RwhVrgC8z`peBP&;(~TYC4dHYWj0XzKdE-n#Zen(v z&&~q;YptR22`z1UdGvI4Tiua37y9VY9GVUZ@dY4D4M5LUe>8`d>os%lIh(ep)L(H; z)BWJm9Q9??d%5_^;7~AAO(ACDOFAg$y6ByCJ(oGR6qxTJW&$_=k^9a-0FH(9vC!Ul z+qK0ypV$t^^oJJ3J}cLM`O6` zC%$}AVBljO9xV=dItN0$(KOQinU0V5$`ST6WH=swFDU?3Fvj>fAq?0e^H?!M7=X$>1XL5#w_L^1Z!+w2@sUha`i zt%{wGd-P9VyT9fMk;S!}EdK%2-_ai?zzG*6WIxdksJqPl=BvJEe=?P7umHjBJD8Vb zfH#&RIsDeg)({FM0LQifDHtxl!-TQ5djUC-74YC9g=f7r2QyUGb&b*RY_F|KIb-i# z*~+D8gNHNK-lr~ll`h|vlf<+gY7cczSJNV(BU5E0dp--n*OI9KOT`GhteiTE%W5=@_b5R~1xz&yr0hWjxiaX-zJvP?!0?v?V|Pf0;MK1z0ylTF=} zj=aX&#irAJjf%7J4W&K}$wlUo?U4xl1=j%eZ-A@fg+*OyuXxS=sP|qw0H+cF&lX*1H z+&-OL-TOXd1QM${*RV>M9g%PLCL?CM62JN|$!*mLSYP2+9%Upv-(2umrqyT;uU*_7 zNm}}WRYGc{i?YV6SUNwuCFONiYUkngeabld#V7K1Ouq{j&K2d4>yA9kzpKlHTxrfa zIWT>JSjzo_1N6VgdeK@9nVh3RXSB^@btPSU?BsUlWBGMvY3O~5M1dL6MdS4&S<@#;=isx55&BT&MD>ZS&b*IbJ zXwqu`Cax@Ygv3#-4PYnEZaom6q_BSHTeq44ATg8&7?;01 z3A>{JHoJ@ElMdDCGZ@nJryCSE#W@q*8s=gXjaCvB{`7qFJ9EnfqH#sbAq|W07oK~4 z6*guQ;o>L960_8!P6ZUk(cZcgpKfj@D1Px&Np}lz!y}1h(6pqQ&VCzeTx5*>P+ND) z3ze*8Kc<}5MVZMMsi=)U9ikSn(6;xQMK;x79=p*SGm&Q#T_DZW;=8K0Fx zygA7UTrZXB+rO;Z*&e4juvJ(1@My0|*yOn*cBfSMJ`V%;iN?{@i@_{SUJt7QrM>mz z>KnKYp61zi&t4V`g>7e%to}@3=r{k(mAB(;#eF&QLH1%B;HyGq7Xf!#&|elx50LuY z09{&DM7j48q#lwEllw!N>aWgh0f4vUbP^Ej*#SDW_F~)bItn;XJKMsjzk}<|;>WTE zyy@-Qx<<@kbs)F|kidF{v^<6=b&z$W8iivrk)zEi>NMy75ODPeK}HG8mXth2j?QOD z`2@|W^^aoLWWlW3@WEd^S|9COG~d4fw;F_dvS&;I+b!NmF<9g%fJSgw$Oy0?JwMtQ z-y2loRREpPJ+&p4JpxXvV&%tM)3!5V2!>O2z=X^@rNTW(r<&t`xvad8lmJb8zi3~j z(thF86Fp=~B$IsTUE$*h#|2y`cAR0kM!svXV=`F!BW}^qqPOR2!+8==3zY%B--x-Q=YjBb%G%U7INSg(y zVIH{%T33VcdUH$y&dW{_XeoQMX0gvBqczYmoi%-h0O47yKSPvwRot*g)jyza#)jXH{U4Eh9=*Jdg z)gId~ktQZ2tfMkIRC7#{{j0e4;;7kS9JQyd_s}D~Xs7HBpW=O0NiGP4s!~Dbk(Q!v z*5`IHz`QO0HG3}YveR;IBXGgZmlLwkNKp8mnM5Uu>5%wPi4{4-vXi9y~8qbH^j zv&ioN1a5X5cLtKCYU14G+T)poejh~rR^7Qnw))pM7@~Xg@jVH`NEfWwwk<}buMPsH373oW|hx-Puewn>YvMn?rI)#QHDw&mbv4FdyK z3v9tNNieU#duQZBpcvE=p1Lolw&Z1Sv0(3?Eak2`V^r0E`dUy~g!m@QziRb0R-rfB z3ijB9{`W+JOdVp$#}_B?4%B(cOt$fh^^dm=c%(wCn0f@iz?O{xAiVhtVH;x>tZpXV z`rl$}FoHol7G(@8h}YEWSR~%50qv7b=h&3LeIAQ~O%=t$N8}wY1Ai!7u{c_0Pt@NErIBy~TA@5W;Ni(wATFp%oO zNBa>Zo)`-NV)W`g%5@g?3(&1WwSJGB502dqHI}f!Mi}72d?8wM)MMYLsRS(e{7XT5 zOyl4mcDg)2^7tP!h7n|>UC}E3B0BKY_+zn#kdfpwXjfWo_|f^qF~|?|;PTo!8^kj| z3NQsR0U3UOSk;#Jwok-`{9PKjvQOj)kS+dZyQP~)qo}VWtNXS}yrJq?w*ah(#sj${ zO{l4y`nG<>zVagpsmM!pUh^WeR*pY?&wM{^MQHPrhyVki#{UXi(}i`W9wq!pRV8}f z&jU#d!0-6nqWMEB+V#W!%A6l05OUDbljQ0FW0A$y&uV6?t?RlBv=x>sUPQXBuI_1@ zn?oD~1P~s2=8T$Ph9g$N)6jIP44^=?BzGfvOMS~ zig7K0-JcSN^cj$TQI-k2$?3H`f3CGu@dhZ&GA$nbOkj!EBIHezJY zYr+p9e~=n_R09z0c&?3A@4knMiBb3=a=!{jZ-bjDWMDr2_CBfsN!?kF=hVo7f3jox zyZdK?WkW0{toTC(;6S&z-mru6!{f`2Du2x^n^P1)N=g&XF)SKf2ENI%sGS8`Ji38< zJVem~n^;F!FWAmbdObY+F1R)Dj;KGPfdMp9yg$*H>rN?ZlxDcvXJ(14gFm*azI4V) z%axvEF2K2z{mdRYMbf@zauJqCr0Oq~tH%VNJ0cdQuGq{P9Z|Tl#qYY{4*)lY85=5G zU#T43m&kT6IvA8woUt99`rZkwe5W-YwZcKIXG#)Y()1RP=f!`f*5bNZ; z2~}&^oR`MB3kob&aC`!qT|LO%B2NU1a|nQbzk+aewq45CH88s_7{g)5j1C6${go3` z6oQcU+LmJ<(AkE!^Umw8Zt*k$neYRG^dNgC$#8{a$|ns?EaVL)jiuxoD@`Ph@n6$8 zVNhv+IWNX*Z1m}Zl1@NdJO;u2WQaVPzbezwTvG_8J2Rcf$|#KfChWA5&FjzLMH7EA zajXh(Z856!FWkc|6T)}eEVuLXj-UAY1JdnIWlPN675`5WDa9-n`Yfd z2oe=Ru1d)h!WzamoTpXsb>qY-N?E^Fd+=HEBTK?H23zvWl4W}}i)d}Ezxa-F8Xq)3dC zN#07=JPxc>!t^NLtkZB>0y!)FML>q+ zFoPk*TN~HHdXiOFsUG#}fTaG#K)6X3fUC4A22GMtIDkj@b70eN+p~yr-JO?)iM)PS z*l8+@sfCb1E_GMkLvpaV?|Ff{r9!3LgqYu|zxKuCK|R!Ky#V;BIEigBw+%L6tmCi8 zgg6U}SG;ZXAyjv91YKJ_j5uqG5{TE0hczWmqzmC~5}{pQV9$cLWjcX*0%1WcK#caD zyOxkbZHW72B~foH>j32*d$Gpm-Fd>8_^aYA6M9es;%>PI9kgz~mauW$$5?y)Gxg?S z!w(e$XEjYfuK3j;ZStPV@aw5VEc?bo`-0}fZQEH)WDBfV{io40&j7gECetEB?X#45 zfN#T|VXh9hU_Rsw)FCO?bJjcESJq703hXO>Ev$EmKjB8!Wu=dTKHQEQNaL~~7;Y(9 z%itFwBYkt9mns)wpf44=Y2vph>f%(NDCIT6^|0eJv+XxVWak0ZnD5iYgO2*8gKW(V z2W3wPb)ohAFXNx}m+VsgLQf`rZbFg9$G-@%p~2TLtE7;Uy11{lJbs!HQ4RA8zVe>n^)U%t2(v&YcC#wHL2@VHT#^Oi%spL(=`9 ztHsZs!L+QSNTHkggm6}8r;$5fv?Sg5@s87|zKRQdm5RJOag615JQTBRB zrEYoxda$9fnMzswiLaCAeX&t>Nq8I?+wY?wBuN}X@f@mkbU;Y{>fwI3V4Il7&fFtR z232^`=}S64)|;$NDcTg!Tx|mS5KL^6*eB(0s0CW>= zHuEn{(y`zk*z~E=={p|%0O5+<8U_jB&Tt;X5r0x27Un2+yj?f{1<6V$!8S zwN2AB(>AI(6G#~+rNfCnn)J#fs|NGI1$(FzOAwuB188(i!(Lj*ezazxFY%y43&2O+O?k#1F$sa1W|d zEVCH;sW^YW&^!8Mo_kwJ!IHUf-Lh^&>F0~dbfLu?KeJ5KB+9kEIwao;c`QO5N0y&= zV8P6l`zERW*e#vXAh+K^hkDYx#%SACyrV)U_?9I#sbk0JdZNe4w~&HE8CIb}%d!GN z4>7s%QE$D|o+7^^J8SpjN&_3!&`b&P$l=yJhYSZd*P?=@>iodtLrKR`cGx><*`CK_ zC!p#Ir@;q;Um!en^z#1W8_11&Kcm^~GB&29ZuFaXksh7DWD#1#(t@Nfs=}e1AplLX zTx7if9gm8%f9`vEsQWUUYci}5I&?KtIbLS_#Lh#yTC}nyX5DAFA=z*tCv*L>&UmG! zkHX0N2WyCJQ1;#X){#ilgTGLuaAfl_dMRRSH;4R9BUt=%^a@t@iKp83p#1Pok0{3rU;A1I-k4S@5=h^ z!mo~JEd|YlOxxmHl6{Zv6D8moyjJJ&8Y`-xvD$*VDop>pv}-5CEu@$Op>a2~oJM$} z`BL9$=&Y9@|nIljq3>*PYF*^xT}dXRva66G~mFM40<#YySnfg zxY$eut;pk?Bo43U0*FJOfPyvOS+OWTx%`BvSqtty-5gGLYEf=-a(Ws#%V=?WT>~=xaYo^&6A=C|P!nTda3KvpjNaWe2D; z6y+yh9mt`l;tB76ZTI@HSH5@Cz>$1022c2nEBd3Yl9lD0ZIJaLU2jj{rN@mN=6<@e z1AT3JJS=~-46BobZYDH2Wffm)k3~f~_}pG=JHbRA-NzSFw7eE!k>(P!Lv;Ik*x?f1 z#kgx%8pK$<_g~ouX<fw)*aC3hfNHYnw#2C~<4o?iWRwVC3v5OL)3dt=wM{fi4aOj9o z(LhP&`dH}1pK!OT5@EYBlLqR|Y+i$flWzpB+?pAol{lAKG3$E$<$nIprbgXbA8eU$ zrJ<}O4h7}*o;tQ+lUuF@ok#mNGZNTEvHG_ghgxG!VFVoD)&F)pumQ%t8z&k(uF~ec zD&-{YRPA$0HLYmp+r9c>vu6Tajv|fq{=m8Q4D_&dC8np~;_v zC)#rwST1gHG=tn$TISmHBv|30_BRK9_tW9R21PJ1yQs;j%H=Azs@A&$Lzr<#XY4Dc zE$6TRQS%mV3*^(H5|pVZ2l8sMH61WL9$^wEQobo8CUFA%UJ>OJgkNDzWi_!ACQKf2 zS%@&BTA&n$zbiM{W!QC8rEfg5;+91GyaTq)b8o#jwlQw!d7#82=%gIDG#hT3%muhMGv)`di6^s!xuGxB*|nZ8O?QVt~SO|u1a1u zyS@PvQ&Yt#{xpci#@Ktaf+L#OK#2ZHg5f!iuGr7tADx!W?3-0W$cBylFl0g~c!kIj zbDv?Tk5W!;sIRkJFahI!%oyI^?`*RvJYu-?1We6cIx|viN?dV3`D8pasba>H6Jvq$ zeFN=^nBdGtHq(J19dm;?>nI-!hSJ^~Zj;F;0R0CX!@oMVFXtRF$Zi>7WzpwCB6JHU z=10t-2_On9_{%;H6iLPMvYHQOOGqwCfXu()Qsyh#$BHe<1*@9*dGiJQ52yupr^L<` z!Su$QjZzngW(v8+%bnMP-?B}`!7(B&Nu!w^NrKkNtTXNsB#&^c<%z2Yx#E*FnpsnP z89NhY=x=MNtnQ_TnVFW78%*th&0;#ih{hULmNT)xVJaM>A{uUTr?A2~1;Irn=uftT zS6az(@OwEN+Ez8YLKU5+&5`;=D|jfB3p#j)b#sdJP5;X38|Z*=@3Aj zl-MVc$Q$0>#IZ*B`%m7HXLRc`k^~8i4*>N}!8=vr896uP@xod=aV}|oM{a&qr?u)i zQu>z8V=hBg+(mu0Q9WG4YPTN)5j9B5Jk$(*e-sad#gnqa&Wz2dDpvoyZxgG!xEki)S~O9$d5`P=30D!5B={ zsuISGE>%1@oOega7DeL3gH@BZ>bB;;#sXY<3_q}4JA&0AWFRtyYyk*3mp&pbkwl)5 z3}e3~u+o4g^pIfvZnWqg6M5uoVQR-VMb)YB&u_bWA8d7!LAj@xTb9wgD9sDxY5k#UWW6a{37gNNX`H;YazPz*isi~(i;`?mIqaU1gE#TR(5aFDCg z-FLT)xLiMrzTPp>bXVg?qO_fRp!2AA!Cx)9OYO!78?vgenq0c1X{MH}iIpc};RmH# zCXOWSu?%!`iN#2rxw}r7O-Oj#?RdWBAVCWxfsQmi85@o~QbLlaP<3y>+^D_f!zXL% zc<7RMy9x73?|$X`0ofJDMgPUET}^|nhk_SgvO^sngj7*`nFUfv~U9TLY`+U z(%1>ei3Toijk$C42mIjA2wv98zruLH8I?bKMs9yrj=(LMWg0L}~d+dDp- z0PG7Yimde~o&FRfd@QeYF3#eiwY=FE!5-IKFzkp=3s}4YHiFj&*oTPtjLOWUTba<-U(^u?}#amH92Jy0FsBC9F z^Z63~@Wyi7bqkQM+zq`!K4?Nl*a{6bStrXs2cF>XdCUJz8#?I4Bqfpq5__|+((Blv zWRD_-eQQyjg`5t<7omrT#RgJ**-9d^Y5<-gN4!+vpEAa z(2)&~2Y4^Ky8;&S`HNgyU1(c{64~l#!R-8fj?n+iLXn351f)I#@tFHn$&rzUOSYom z6X=`R`R~bvPZf}4r9JxhZqtw7ULDH*RRxqh?Q*%7%m$76k>FF9*cwhj=O&L~CP`Mn zU)BbAsr7Kqa6^uE?op0$?b%X?P8KSNzz_zGNnRA|j<7>wEeL0+7XqS`0jRWUO)zCOqoouxX>0SpjEGK)DtKuD|t;=N0v zxVx$@v7F!N3jz&!BoO73Wt;=wG^;B#pMs5N}UPVts2-)%R#_D N1zA-Y;BI{L{{e+~Yq9_U literal 0 HcmV?d00001 diff --git a/versioned_docs/version-0.47/develop/advanced-concepts/baseapp_state-deliver_tx.png b/versioned_docs/version-0.47/develop/advanced-concepts/baseapp_state-deliver_tx.png new file mode 100644 index 0000000000000000000000000000000000000000..f0a54b4ec34bbe282ed6eff81369428d02dec095 GIT binary patch literal 59007 zcmeFZbyU>f_b;sE00J|lbcujcN_P$2pfI!uf=Eg?0z)?_2oj1Qpma#rAP7vz}ltaaD(*S*Vs)R{T&eRiF_U;B055n39Gg!t6>*REY7R91rPT)T$J zdF|TuFbEF#ADwR_sn@PCUQ>q4Jn%H#$iRL1Kz=BcAi?fhJ7ktE`zCMpV?DKeI85rE zDl~$G3_BuGh721H<$Zfo=4B}(ek5dxQ{lmv@No8 z)FqYAmMHtPG?O?LqN)>bQw|M}kdC95xP7tTFXbj^H&%M)f3{iu?%9uztSYbWR8{;W z!B~Yqnyz!BX}UaJkCD1McZncjRVm~!sXHiqCl@BDzMN?&<^zM8cbQJA?h8Z0OMkoY z!x87L2KAQQ7~qHXzK3f+;;NnwWRFRnZRpySG#-63ev)hO7KW&G&b>I_?>D-wkzP}4 zT7AT3lGXKgQp>6W_{%iJ(Zmed&X8WEYQ_A$%68P?Y^#2IoXhAl zr*4DiZqEZ9!w{mt7#g7o^v+GIp8YsSiw4QSAQ3JF5@C(-lN9Ddq2{}|UNDLPrxEVd zkd|aFBb6I8f*ZYU#8T(4UHTm|9cLXM#y2R+GE;H|5dc!gKxQX*I~((a)pGbP_+0Iq<@J|1*v>GFuwr|-n%hY zW>MSoUCGdr0E0y__S|Q6FxPDhtQj(%U2&i$0mLr&`rvLT?RD_z8|D%3WN`~ZHH{8H{Cc3bS9$CLf@ z_=B|{wsR-TSplcJUm3Fg`uWcckC`$`Q_s0yGQl_*83HP*120(^QHjnpp?Uyg=@ks;=Bxf@F3Fc#2!anyYyBu9RPvDEj(nMT6de82eqKXdD{`I^r03vMTZkVe=Pmp0al05vJ@|dT9pj_IC@T7`fZJ zJ-nPQmV?tMpFNjImjdcPvB;s4ZINSqh|IO_&lG(8C4BQmF1OWKsk!@J7uz!4Z-#(# z^I6~h7&@1pdw~KyCC!)5M$G~w1W0S|6VZtdPkgqw72EC+`?#oRe#qUkpA~RfYvOnK z<7nxPX&55cC5tpSg4Y5r!{Q`7cDKhw3D$=>Vw4bQ#8uz?BKhb+9 z8?qS4{)Lp8Gvu0PoG2C?;R?NfJusz*lf2z`y>}yG&xGFY4l41|f(e!AA6+H4#29}E z6_ivDLf7bxp#2T&UnuJy~AJ{yh4Gu=Z8CUvd_0ycwRX8h0W@9J@SZef1;IjpN$ zHKZZd>wUas@3UEz!evnYg<8<=DKPhEjSNxp6=^cPZIpPNMwZ`EYKH5eGDU44*s#66 ziQB8j-3}VBiN|fBgnCWBUhiXbKuE`yHk__~YEsOABk)}h4z#c^TF;_b_920bFvg<0 z;}x`Y=H~i3ZQ-Sbq~^*qkS<9eJm=%ItX@b?V(D<9!BCpe)fM~wRoz#2^#vVVM9+8H zfMuVIH2QeFxn~g?rM5F`J6bGI{Gh|DX)ct8c8*HQzk!gNzq4`f>S)q&v*~QhMT!Se z+7f=P(71MRCg93X=y*s|s_Jlk)F?~RukiUoM=ax#bWN zo>JMGdCrAwB_P~qfi${%RY2!>(FTo5}UOs-TD_cJT@oX#NIdlo{!>IK{b0!+6yTcV@P8U`d6K8<*5<`#zXi?-*8!?*%^C3n$(~ zvHkRYyY{_bf+quEn|1DVg?23j>hcI3xAQ6uL3C83Cf%~}2P}4ew)PEt<=7f6$#Thl z{y>>k^!LwToAYJ*xfrRws+7co)Af@2@aug%SV39O_aZ8J;{*^%Sp{t`rlhYqy)Jko zve(ICVtI|Z?AebyEFlq3H5VDZ<;YgXEaIw~FHgJcTvzAQ*GGzs9EFITk)#Y4K8}OH zt2bzUAu6f&pBQUP=0x%f=@e^7UAP)Gc$TTM%1NdBq@M`bjx4Sb+C+sBFGhvqEC$M~ z8H0+%WD(WIb^lfD3VuJdELGgAJjz#^TOpQqb@4jOl26Tj9+H4XR_Cg(^gcC^Q3LCY zDmg<2PZDjPU$69yha;>zqNx^`xqWe%yjR|ZrC-diKFn2_<2fcV?+R_!S^c4nWNrNY z%q;+|;B-f;E3*VDR*UZ}oLgMxF)SNR%9@5Tq|XfB*p`&0v1P3(eH$!kstjFDcZiZa zpGtVmNDND6G*T?bCJcN4qe%Cr)f$W!be!2>z7r>PS>y6JqO|9YP=DiG9DUBiUA9mkNT4}+QMw~yV|Y9p&>VH2H#~dFd%Z}E z>@cagecP*#22=>6L|?GNvK|z#KnQ(EGt8wkGriXerYbp^sp2Cis%#zeh>66TgG;4z zn7a_-zKq)NC*gZ|CCsHp?SG4V_k_VE5iwe=OA^|rCNgWX8^f4>TM>a`2bZX7FHrFr`H;- zD=HBWM-CU3tX7tDu!9-+fFyZ^9d5~wE)+Zp)Z+1GT3jl~V0bgX_d{pvQ}0Zehi=60 z$*bsOBSR_+X8q54k7fe`^tB{y25&9DNHUba)j<=FA5N}KosE}M@cj8T0hR>JAb1_s zo@_C57hz8HGNWW>60tes^cpBgJz{-tU5~oWnK=WOouAXqhT|zd$lrW-6ynO8t?MxWJ;(`*0$5v({G zZJyY0m+oq)N~3fpsA&hVg4U^zhg zCd`vlWt{AF^SF%4jKU!V`b<8nPkxfbl}bYwR^=@}l*%DJmCdiJx)gyR>w5BrGd%NA6L<@fk^mNtlV%`T#)1XMrECD zUOnX;#lkgpDxcB0Sv|XTuxVq#clD+;xJM2~0+mSA z_ms?Y8WILrnRVgzj3GI%Wxh8^a&D-r6a1FbSQwWe4>LuwlCxVKQ!{gp+h3^-fPW&B z|7SHM=3`8ywR1hrF_oVok&nEoQRWc;!~+=rR7$$-a=CZaTlNVVwY2@t}vDTdEL4utpTVyU{^ zK^wKyFY4S|6}gJr$s9(S1lRGS5)F60@k7fc@L!ThfrQNE8f$W7)pm3*R&Vv{b@GqE{Gmu5Tns*4&y zkuf<+&PzwJm5Xs#BD_tf2`5jCe{^+!S@`w20m zwI5TBI*G(KN-e7+MY62oe-g|Q}QnS zzMTuIIYE~tH4hi+_s+k*xvv%E)!mJI?`XW>z4Bll6u*fUuYN=UdsUr8DV*>^le1+$ z{H!nbv#)z4d6*rh&##d^RgwDLSx>xi4$_3_#UhbY4)@$>#aJIkY1s;%8P0Ei-2X zLfK_cmNC9B=o#Yv*>{|bQY6{MOH*;E&W&52p`8dUd|AXw{quHmec?pZ8~1GP9QF+N z37e5>M>C(()x6DA>&)kbOwV;}^ukGFFx4>?>$>HrJ-apK;LKRUyTQ1`?u0j)c!XQd zHY(!KsEYe{8C;RP6n2bW>eRMLKWh0ze0d9%y56C88O3W*dP`;rS62nFW6oYgcHy{KF zJV&w=nGsK-0FGoQ6em)4@M!xybQH0NZUfcj_S5ua)ok8&(L$JAT5!cdb^R2SYu%Jr z=SP(0UBpa&nGEPom?@`U7le`OHzqe8;a<-8+2zWopX5WNlbPZ<&F6|l5->!E`6Pe; z#5{IXx|T7+#0Di{#uqLG;E{W*Sb;WN-KnoY-k|E)E8CWE7gc27FtbiXxVW@)IQwvs z(WqO%GF3Qc&aajCai29MPris;xz^>~m4IPp(+OX}&77irjy6_ly=gr^qy~7Y&zwNaN!XeN4q0|{LtLJPRvDud29n_iCCFspT(dWMjj3E z*BuquRbn#@a>NqDMRc|S;b#6U^ycQh_bfVu$4mK;iG9aoMB+*;mKy%Qm#dp0s{WAG z{c|WJC-^=1yA{FlGBc-5Sr$aq@X?QKS;m`?TdIg~Y!h3K{MgjmVoVqjYQxOSih*m!-6Jig3U@l^Jd zDz=W&yj4b#zLWe*2s?o`-C(0qNpQ=r>e#%mj?EWVJ{x6WlZmc;nZb}U91b^l@mLg@ zC`6Uhs5Dt9&b8F@j8r~o>X*PgjAAV~9HH$YVf>G`#dyP~y^J2*|g6 zVQ2s@2iqB-U@aekr|?3Ru+86vBA?>GFd;33LQ_ApxrP(9l4R+y<(I+!K1DTfn$!); zYbZ4{+eawjYlsW*2zN609VA4-e~#%G$x7fH!r(Giy=lK@hMPgl#l0DwuQXb0Lic(Y zK3t&tRUQ$~R9>1{oAVNu`XV0Mbpk+3<6iu;2GBmnO2a=0!g?7aFgOGloQR)mh^?kGhZOu!7WF#vL#|)l zDIVI`4zWR%&{u(sT0=oDnkpo>mO%`7#0nxU(V!m?xK7s1ac7??jCLME)OUY?Jo1Ez z9?p{=VlG)=3&mi*3un&1VpNZwAjfHLTRnc}$cP#LUI~Q~A8b%!3I1+3(=fi;VhZ;N zCy`+UP=U4WNa1tKhZ>u7lA~{ZDY1Q8dR$a%$sSzcQMAdt2 zZ%KB%uL@v+Wz!S230iH6!Kwyts>tvAMq#pkIA0=B0gjsfinj^^t}Zo%wsClQ z!-m_-v2&vR*>e`}5o1u;22ktB+J(1x+IS2se~l`Zr<|5cW@h0m+fl;0I&WhAE2r+G zfp;n7f!8-Q+ANaOC#5yuXXpfSMGFsBTH1J{)#v@s+b+#Y^NF11%J8RaDoSp9r_Rvc zop20+o5JTg_%OoV4q&!vx9S{!`Af-?i*RS?_}fgJJ?TcIqG0|2<2RimLxIubwohl_ zrg65fYxPnkB)lv(yG~c2)B4C--;Q1zFNrLOLswy&aX8F#6TnN8T*OVCZJpf|3Hv$) zip+K1E+p+zGil76U2ltO%K)%HP`mR7-j?P@B~l=&@}WEAfv>Feo=?WEGlzHY=oJ|j zvDvdnvy>FC=DdKJuq(NA@;*)|x*t_)`RSK#UNuB@t#nugj~QUhj9Ojl0Ei;u>7~F} zRrtxuH|ZVcFxTPD=ac>Llb(8;3Zf<a9B6r}xec4TgMWTXXoVDlYU#(76lbT$eGuRCIbe!lK&gjHZ2hY6 zku@BgXF<|7hQ?Sr7r3IVTAzqjRUX~gU`$|Y+M3gLo-eFXj^kI^Q)re~k zAH_8ki9y>u>=jdH;GlLJ^8&&3X7r?kV6|sj5y|RePlM=1M?0vZD_iQ^v|-8oK{PLN zF=Y`otkG-k4tU+HcT!al?C`ue0-MLIDlfx*@JTXK`YgT>S{^)z_#w>aJlpWhZIHw4 z<_Lv3Uhu0RE^v~RZYCuRf_lEa5Xctz5Xl--iet6<0-C(vyAk5~*3uC91mLd4ju3r3 zmtehygp~$Y`rFj%f&kt%c~0x~%K0GEn65|NI)dL>Ew4ew*a*oQu7{VR#>_cauCJhU z7if(y5+rLqATEmfHCo)gFD!+~5PwcmHVs!l-J1sv@61^)WHUYI@x*q&keUp20_zw6 z+};jAGw$cRU+d}b1MsGB-GoG>1R%e~VfchppoQ`s{W-9nM1sdCq5Jf=lAOHvS1<(X zA(A-IGAerFYThR~ZASTsb)Fy*8Asx{GPHtSM+Xq$UI6yYn(hLSQvFV;_)jG|| zzQ+{Trlb}Hfc56q;5GmLSN)woa#bnCj;CBQe8sze^zr*ghkX5&V%CHS%Z^j!r{}M| zu?{uI`}8Y_1-P7(U4lR&IFj0jWmq_Ks>rO!j!sY;jcpYwc&Z%ffktXbR=?YG6ui`W zvMMXT0!gK;`)Eh6a=rGKiUWU*TW8sWVn$H3UJlFD|K!Q&quptbSvMPt8S%QBq5MQs zPSTN|sMn>^C zyBuE=0LhM2SZj_tId>(p3i_QMOnJqL?}ejhOMgmA5{362KHH6>35;o)l83{(INCv$ z1214C9eh)XIM3hNEPzoCJ!u?YpD>I5W$zoINdTUalM+K7+zf-L-YlZvOa;x_leofo z1(0d2h^WoSodI+~uB2UOhg*dA0iqhHMwJ!@T-N#{0J9Z|KB&L30vKw|`ZeOY7mv^w zys6hO^1DW#3%Lv{J3&Du3@WhZt0vV}RBPUNwou&d=y-gH^sjHPOym?GIP0TDMnd{{ zN-`OuZnWdAt$7?QSYZMsb!&GNwZ6UNSjeV}p%!p%4)c}1Pr+llL2bm$mOy3sc9qp+ zeN~CL%nQIBwC@;AVpjUW$+p!w^pZoD*6W?jZQB@Hk--F_r62j)ZN04aoD}pc3xo%e zVYo5kZNhK_>S@)ZE>08)r;lX_KRSM0enJTPq-8oj)9y-N*prxZgtNBoM?+Lk?c_bY zbxJ|gXD|X4`z7xU0`V1KeXmS^mW|iA}SQ zl{29Zw#$?e^_1X{t87Plwi8ASuz`b&hefn@SQx*^JhfI07alRBp;XvVItVNaNuIwF z7?|WJIANAn0)eBYzr6F@o#%Fz<-&EGC^%!p57gB}g2~paVt31#1~2Y3SvYbc8GWMT zA4KFsR~el#$`~V^e+J^#<%bKIdatrlwlk8HgNli!+V^=dON&cnzE#XOA+=U;4fr2mura72)O zR`g2^v}2K*D-)oT6HI9Q1XoOd z#gnXnhH1n4?b?)>)HC;D`V)KpIv?COVqQ8uHf?#m)xmKeVIC3vGk$GWQl~FW+$=O{ z#@3u^MAjdsI4AXhN(iTDaoGV3KYs-BDosajJPC3!{rG_6cpP*nOW9oTha)9sj#J6< zfs!oF^jXjSc-?qsmdkRo{c*~rsUI$8o@dH>4}KfFn-EAu*2Z%8DyDFwzaL7SW|rum z+}TMG*SWlpVoC4|;s-~z(g-AvlbI85Y;$tEsVs{6$ArUDLEdorRy9%O)%o%Zas8j; zdPO|d)|vhTroOu(XHS0hkL=YE;ccWHzx2PTpQsqhj22lfQ*_w~U&D4$z~@3>5P(ML zn$Dgsh9*KOrRHEzHN)z?VjM`m@4AIeNk=(|V?t+nQ1{>ddgAW&)j@A_Wr4P=rfe?N z9p07hHk|*-XVB1iU?}^0J)yq6_i7xtpd8Rj#_JMRevzQCTsES@AOBq>4AWLAbITVldhdzz7= zs{J%$3#ov!7!xlG;=2YPEB*G4Yz05siW%)s-l<>fpw~N2(@Wmp5%zJ?B4!aC2pHr) zJKERW*o6h#AM88UKHzoqJzrw>aoOUuow0~7GN>B7eXwm+(wDiUq!Bi$IC(wnLA6=R z)zcw{hS86DQWNq|5iZ{sMD#vPagS7=upV8cWEr(B*-um74LF~nr=1#_@nrhCW;Qv& zy*}3a?IoA>dxyqW4bhU~4Abq$ikVxR<6W^O4<|EIdG8#be5yP6tl_3vmAQ~vdPTo? zC4iM#*j!=^({Ea)_h|w4LaMI>*gEiAErb$|)V5N&51Eh_K0ACrb)TW>bBmQmLqDjB zN;dV(iG3DA435@Zh6*p2&U*@7Iw(?evGqIHOWY6VnKThDYcklLRtKRLALK~y%GsotVawa(+gY8VY zLU@GEy-|a*$F=I2d*Kg1xz`ZZzb|2tuHV#~ncnsvC#RfW_QzPBkC;M>R7+wqk;po`ioH8%?8zy zGTn7!OOM&%Z+$ktAsOR4I`t)*lqvY+Jc;wU7IgloE_da1jia@V)uTm;>d7&$?Xl*7 zt0(sT5;GdYXBhR_Lq$jDNu--$CC!yhqwas(M^Y=<6EVcrmyyn6vrN{R-87^sT4h2$e)?|N9_iv#7ShB`YikI`?#} zA%o6$vFx*Xn|ByYJ7M~0Y$!MC7c0Z-%2lbUXPGYVSe~p5&!Lhs>`bZ0CIT)$JEWLC zV#_r8%H2?2TP0jn$HJax{Jmvs!!_fF_%g;PH*M1Dl4IZgUCoJrPjtzpjc^1>s0wL_ zbRaN32h`463CUW^2UQkj#G837=9nz8`$bOBe=2FD_(DMMqpMAQfs3Zm&NuNlPFL)2 zE;qW5j->*Y6%Z6$X^zc>#^zt?T^gocU2OLu(Dmr1VBkOsgcU@cD+w}_Vot=`jaP=nNQocX|0zt zb=gGPhxkF`!qq}ixT0 ztsbvdm8_c4H(P{sv$UNWo<#c8KP9l(T_>=2jU#gJPZzR#FnYv29d$~wCK?_;+_-f5 z8bf#c{?EGGf>twP+-cWlE)386`w9ah=-khhW0j(PR{bXZ`Xg}y*G3jGs;_1P3d>sU zi_2jm1e;YNd>aFEn05#0LdNPnj(3xd_H~J?cX&REM_`tZZSIi`w+e=xV=-S!Wm!*8rY z^f>yi4L^vAwE4{C99cN=`Zb;Aefh-LT5C@r@7oZv1KbOb z5HBtxfwHCE34>R6aP1Wl{w7s}3E`?dVzZ~mjor_N^H-Hrf^n`Y0M*dF>i+IX?cPUk zL6_6Jv6Y@I6y|dkJk94*o2@l91HVS<-4d;#&|SvUs98PJLr05j3VOq4UFoiNBoNEM-$EEFt61I+m)Ny z_h!V`%+`eLGj<}Bbdjuc7o@2-Z=+CGm|?^W4i{&~{SS)(-w4piARbA2<-s>XI~AfM zB(DI(PjePa#n*9Yw2N~qa_b22kaE}G%kKIW!o2D!M{f`9|H^+K>nwkKp!_b20Q+L< zmI5*5_7blH#(U*OFi4#{zrHPkzhB`721kFxD;Nl1+zM+cTTM;Bo`k?Cp7C9I!>pO= z$=$D64VdP&M`?P34(E_##qDo*4H1nvdA}4avZKymJl+|d?3&^zlndFC+{X_ZsmtLH zv=qQJRYtpr{TIj%w5JIIoLlP_R&oujNk!(Vq7FzH}>y+T+7c)eMi4-)fpAL7fM`>v&BrJ z^1XH)+UI+>GBOOuo>x7qui9hgJf50p{ZYx8ep1=%^*H-5z%uQw(`s z)5CkPl<^8{Hs3eNdG(5jnu!|Y+Ak%C{zv21n`@s++$9WG-po(WxBut_B$%bF-+~tsLR_LCUa(m zCCg&mJlp*aO^&4#n|K#SPhFYqCQIjAFCi$7~jVWsj^^t%r z-=i8(m1yegV{ojxZ?nX{pte<>L}%lpIjce|%D2 zzd@Z+3dQ@T+62cV2>CsH?cIWn8%=F^{|iOy8VJQ+hNmf=SVikd6E!FmE8fs#*$UmD zs*?M{R^pfeShi1HU+=NZ@0_lm^zCrfXp z$y)&>yJFh8o2z&h??NvW%vsZV21w>)jr;U^zbx@h|6;S|CNxb)VZVEK;j7p< z69<&U`y->2H_SdTeFG$R2R|hOBGJ+6p~XQTBCncEDv9sJga3tZ=tB#JgdyiCu&iv;`O z-?Z!Qs#5hogK&;k^BBfo>5oL9)F-J6^0_g44(HvK~2qV*p4v-=yXwOdroJi$h0wI*3f zTNVrzN&O|unSN)vB7!@o-7f7P;;&xruRBs=N2uYk7*;rJHjfm{tQNCpuJlA{N+sWA zOL!?0_iIcN1W6sgX!qsl=crFq1{G`i>srfXw&OnGbZ&c8wf(cZJyBa2f!rRNrI^IC z-kP=oc|`XXsiq43()M}02xYswYVnBQXV8--p`tTf)^C6O z>&V7PQGsIT_-Q(IZI#$bhQPK9n*Q-EfWA+hNRp6x;jnEtO?1yOn+U*jLZ+7A1)2ar z{%7`|wOzk0Y0(#iO|X&f(sxg^Z{d7svCLz8rmw*IJ2}1c_qQ^bqal}hS^mxm>8X6y zqK~z5Rmjm`O4OdGjcI(0|HWyofD&CWyW7^(cu^S9xmpecCF@Pus2A@toUaWA+Ib@7 zGAcLyj2U$SO{-|yebV0j8%JKvMfgYFaC~`5Ts%1`X5LOg%T6eOv<@OVlHq>&4G z*eJb|kZPxa;5v*t{T6Qc%*g!Cwsnr`}r1!mekRh#U_~1mUElb2@hU30PNh@PbY7S zks@fGz(70!cTLNWZ0Ow2LfISP&eEog^xF;lv8pG`Pog^e*s^@*J0aSXgH>oIuaGr> zf!zVGa3V)J$vDg>t`y1<_??%L^IYw#cU);aiC%@3`X5%LOLu2l8sJ5X>c|CfD3J#% z5idrNiEP(yH=Xt6#>fD)b=+H90T5J;B?uR>=7YE5DYEbF9t1%{?88fuy^mXy^pUI~ zf^#aGIxUQ3x!LKFmYh<0tPE*pd4#aphwkjOMn^WA6M-0R`H8 zzQiQKsNL-_@tFRl)2?&~D35ucS;R~UyQgYh?7=k^=YAhJ#-3b;$^oLr>76RM1y?vB z9Cr^Tm8+Wa831eJfRaI#RH~LKJ`T%LLg@e!pm8F`I7qEj6j1hU3VtOD7*pg91DbI6 zd8wB*k+g`xG7^CH#haJA&z><4jWfH+@pPJug+f%vI4Q)v05EQy6rBRP9j@C%wC1am z9_vLqU9tB4*lUiu;O1#IATXETOuc{Yhu;iyOkBBYR+Lkp;VXMgFfg_cOZKV;Ou_7BXcc@mK;fR{X4K%URg&8j@ z#gI~!hgsa5hMCj60xR8GjVc| zOGo9B14v-Fb$yy7ltt>vH!^+rq&k2lo0#BWuMNM8ufwiwS!H_|h2fLQ za$n}T_&@^SIMuoqAduK!vs~{f;bN_Vize0JT27rr!Ta68AvEm2Cd=LsCM;c;&$bKn zuoQ6eD`h&yYB;Y{XwNf&wv)_RN3M<9bQn27;jeJHUeY`RqZ?7Y-HDSxw=JU6_))KD z?ckG9bur65czR9#i^u0mD2&y}Jj(XpaL4>I<)x9zVFQtqS8zn)S2az$IKW2GK>o!> z*n10Ho890+6aWs$_bxZUSUQg|Aj_xgiyGX*04rK#B%;Vm4-NsEOPurLL2%_ zwV@wOMV6R(fHNmtXftw536C`S`5fP<;&EB(d470rctA@Z)yzZzw^3qXIhENYz`Fie z`oU6m6n8n``j1Lz21>ew`%AxMR5yodH8M)xxHC3D?%Mr+U4GM`dpC2C|79WMupt6_Yl41TE*dp`E zWep1EhuBu_jg((Td7w!X7`15T z445sj6b2fI-azJpP4NKAM?HlAIkhaK8sz(H7r?68$0ek8)p)&_T-XYJ%!)Yb#J52Y zVXe@bL61@pm=&%!A>Dv0=sWow+@?TZog(YJa>VU;O>)Z#q6SL+ZczPwUk3B7n>U5$ zZfQM*LKYb$r%5Q%_H`L$K&y&nBOGzQ&n(A5VKQylin* zhhaR20Rf-N18&rDWlyLSRM(?R1;7)FSUG%}ZWWpx~bi4mp4IJW1bL}Z0#Fj+#sd#T`XF)X`p&-iHp zKA7XPshTpSsJI&2Pm8eE_n&;L;{lgXj+o>^r;^Wyyk#N(CCZ#dUjGrMy>%s}Y691I z7nCWDPCfU&4u9Bv7Yc;5U;9xuUU7H z0Ha{EiG+5NVS$O2M73-PzI8RY*XRjwqxKAX+gGqwoWNGV^*LtQ=+e?sawAmNb6;4K4@Sg2}3fQ^+ezs+g8Y z^1B;gmik#a>9#%kqS2)L#@KUNg}a=;d=;gU?H-*~fQxI`2i7)x)H@;niiCoB=onn4 z8w8VDBY*>4O*aBcXFEtv&%lMz8wofh0@08{lll>G^U+EQESOyWq`R2o;m6?~aLdkw zM#1Ek%MM_D;5EhE*N_FC`uYLdC#*KJMKziD{lFy~l@xaEd0{@WI`p;EP%Z2TT5hal z%DZ|S@7>l%8l|4kf2o=yF&PXc1c|!TfD>~O1WFX_*P{>EBZVdpmN{(IdD=r>K%p3| zXqJhmV3%hEIw~IjZJmcIh>47|7(x&MCf!B_;G{`;}YDAoR?ZkZFsMP zx<6hwsE*bF^gj4p)`~X*aB>+LQQ7YkRIpq#bs|2D{E-6^D2t9T_TLAkP{<7oXI@N; z$Y>~hnS-T=o%PS-Qv-p9t;VzsA=gD-i((eQr8&$C;JUVWX#FCk-=UFNGGA{51Pce~ zy5+TO(0@b+Uq-UNdisouNy`;2Io;8O!C!^}ODnMe&D&t+u$5i0hW1W zS-}3sG6djr^RkzVWEfsxXW68Q|7S_gyYV|QHN)P@ueWekFhQy7r*)`*GYb)BPoaM3 zLa=|ZE4}Mw)JnQfKvdAKzK+gcT9+OH)FqM|LwC)@Z@NP&$h=wTt=5&@(Wd(2GmP9o zsiL&9jC{auT{py32>$aCK7e59@R;JM&}U^RU2e#~P6n3jp*My%SCT z{dss4@GoAXFdbBoc^I!M6N==&2n>!~Yp{keScA&pQ32aO`!Iq5f}Rlgyu5@qfgD1lEB4VJ$dyj^Ft6ai7+I`53JBBI~-y zo9jYakS{}2_<;$xz-aOBwd2JxKzPO(h-PZ3AVjr#iv{En<=r!bdJqngWV3&`0RNZ* z#9N}khvaN3G(S0%2C?>6%)Eeh>Vcpv|FJhHHiR|25MaUe8(jAP zsK$~ID9*s*8AsY2+68I?b2Ic(FY*4yJE_$F;!iO=@2 z6%Ur0RRpOWP*spUgYrL?mxho*fy3cLjPdD>Y^`W|H_Z5ax_bKVRSa6`4fd$yKJw#A zFhR?o(wJNHkNkz`f?`F@?^EjGq=J?>$B6yebbL0cs#qBMHc33S#^XPy&7UAaXB(YL zHslJv_A4b6$%)H=O5SuE64>x{A*;bZ%7O$U(agx3A1l?Oqs!Ur0I*bH1z2^3_o~SL zIe_BPa*#DPHnI~SD(@h+nD<@O#UQK|w2hLC8Gf7)jN znLC67zFyhxt-61o31tZUE}RHW?#C5K;gSn&F_&Pt52G-PzKxnE=$U~3yW$QFND0lb z{_+br!k4cG66L66%kqym$+l<$)11S_2*7Q}-CjW6Xp$+4`76z!k6$TtQYYQyoKi)$ z3xT8eH%^t{UuO>5Abk^+(qM8QgRva8yz&#+iXor842k;NWB5K7kzog7cYPR7@!BJCl0Zqvt2`_Wa z{A>vOMW!kIe%G?xGiN|w8`C2C@ZT;pSE~Co7raBF*VUQVFIe=hppFVc@3p~S(xcF| zi|_`SA%{G0qm2JuH*(Xn%XwK^$XoG}41FFTF+u8Z8sn(c0q=~k68&3$u9@Yi9&j9^ zYcF(dhBD9lt^(ds@n&`L(J2mkiT#)4R>_Iz!z$1T91$c$Vj+4e;MZzwxI;qu6^~hR zkxxQWb92y!Vx$Eb1lgwX?iF~agwPN$)c;--0aK{pb>s7?Dx+OQS{Mo;H^;-xNxV-T z_@m7Txs)C<<_+!y3YuP%9|aAY_N~M}QW(MFS*UJwcZ)#&Ju)f9$K5i6tVxw`p^e&U zh)&by-XgfIrE;%xzf<8?90sw~gG2p)@ePpCDh_Ye|LcrUN_6!>^xsthSR}Ob z26)E(wpf_~S?$@k2wCU93(W{{nnOGP77cya|9=v#Pj|BNm_ej6>s1Z!;wm%=mn%aK+ zQ7;@gJ}&U9#=*~id0xz5m4vm>df`-XCzaNy+CSKSs$qPlUc%?%kjGlWHfFgw?@Hfl zbW~;n#3z&&>p)TX5l(`z?AsUMA&Z#C8XA36pv$JJm@A%)Eex2=!9bxR|T<6v{`7hu9y1B(|`FxuK+mrZT-+4k+c@5Nbn+AZ-qhG(RGy9&y=Jj zmql=oZ`&TcUZlvnPtqX@qH0&_E_Nym_){iZVYw>Fl~R<=W;IDvdwDLP+i;MH-~lV$ zMmzV7yLVVQ|ELwLMVidFHd@jg&%w;O8yJZ`HOtA_V9C5!1}`^2Jb+j3fWoab=il0< zz0?%!XBWH^BS2`61(w_pS4;Us+Z7OOdIF%VXy-` z0X6liz^Hl)q>l&&`)tk&g_zHhbd%O@n~`C!!T)8^_5KOt90Cx=u1s&H>Hysuu>EIX z;NSMI?ZE3i^3v1O9fcfcj4uFUcFIS6M;@_vc?w>R)M|LVVR1~j;RqV)&eQEQi0TN# z_3P+}x`tNY3)rn7sM2+?n@Q<(@Y_Dx4(+Ykh0Uw0dYE1!uQHp{DkBH92zFNAP77dID?`j z@GIsa;8&Pf%&$3+5CRC;fFVX$wDWvI)~@S$$z`yW8wm9{Vd|)a!AUg4FxhmdUJgq` z25^0qWZ>CtR8-3j01>kupgToa97XQ+pPR=X*FFK?uKJR9QdtML{C1CMFTU4D(MF;Ifq< z2j*{yB0i?Fw+Wki^be^W7#lI@+4z76Y!@a3(Q}jT+#W z!2VKCu>vPlnZ_(&gR6iqaW)ZvJI377_C3|UBI2M&v7?g(uU)BrtUVMm&T2@G>h0}a zZ33>mN zJKnEt1Zvb^ZucJEm(@?cJ9xn*54y!z^t44#|D7lhWt4fXOBT@R_bmu8ClPUn?;Y#%tccnMwbxn z%WHSv>VfD#d!ql!jW&Uqrvq6!-1RBq+cCihDjt<$cd#rGNvjjjLfrpp~aqN{) zb%u06lUjmIq)iZ)Q~|7zV?dGpbn26LE!YLXFaN9w7yXcbdS^CM81=^IET+cgoOC@< zOKE-lAtA3?WC9h_+b1=`gPB>QGu6Mw!dsXtFS^SP#Fgs zvg==6LqI&!*j3S^r!!tk^RTx0Bf6UdK^f{um*(T8+kNR`N*^q1U0|Yb5KI<2;2B@x zmGs$}4OVa-zvHy>HP6)_1d9;2tN(BRtdmPlnf&5X5^xzhBWhk*cn)}ztDkHKMtLK0LJ}vxl$3Hi3Ht4He4^?} z4~P}AJ^Bh12Ts8KmI$yuVe`3k@rwPyk-`VouRYP=glN++=f4@1g}+4q?}5d#mhCxW zt`n9c|6fb?H?+k_qRAep?pr@jH~A|?X@D-{)=)5TKAcGnKX0T1>v()FT{3pdwdv12 zb}3sdHJ9?})hV!Io|2V^rO-z{Or}c*$LF(n{N&dWmuJ(H*KPuE^tnx+Bttqd&1Rdv zF)LzrY257^Ms+-p{;#J@(U=`n+CKB|jJ>*?$SSiWN0)A&WHe(1b_d#tXXc2n*oenQ zaZF+xAbGDA5VQ?`={|hI*hfy(U(_e+-0Z|nS4SG|z8`&yB455Q+K>I6Zt3D%4qm5{ z(jh~|p=|I5Y4RY5^{Fo-&fWpHm6A190I?x!2_e3ExoAH$pY%YdIo-A zE9d-hV(8kvvO3OU4PN-wM77?L_m+-LN*}BA^XJK58(>Myld|39aK+p2@aFfUYxg_rQ^Jz|y z#UxR>0roO|?B2UBItYDgmwdq~FVkX<56C4qlKx93 z(3XyDA#$mzw4$h0a5dY2hWPmJ-^J1A8`4o8|KUoDF)hIGvvC<$P<{zl8GZ#t zN-j(!MT6(DWp+{Buy#Ik-p@ zho9@%J`aGO6>@|sO#8G0<$k9*3@#E?qfSXWFa}Se_bb)ET!_FLG`x^Iu)qtw*X9mh zp1|**ins=Nb(0u3kaA}350c(CV}!EtARVB$eASG|>1QQK5bU}!cOYLZSne{_uw}6a zOvz(nwUf4&4mgcsuyeXbtkTL{=B)vHI>xi?&YKk8bviu`)W*bnYo*sRjwbK>Nl1vS z?RqH%!I@;;|7g2mUEB$T!kAfhO$fcw(Ui`xP<&smwpLmIbkkukEKp8^Ew7~PHu`0T zK1Ol*^^`M5?t=Y+eYsk4S&ho?L~H>timt%&Z3)l?g}sU+uq#MzKpjND`Ak9XFn%Gg zf;n`vT$@pNlQf?pB2e}f%G77a2wTdbGJb+<-`hcbRjW=Po%WHI2)s~mvr(?oHO z*dGKB>b}%Vf!MX$&N$|Y zOgX2Gx9{FdPuDRqMfqsk0>2XYug{k;VC7m-H1AuTzZV;GW)wL705O%RjEB>z;0=2F z;!B8;=$;vuf9N+*CjfHD%ZNhAReE{vGRckqPhqM_-w~YYajL9}2S`mrf+)=m;Mu6pIs_CB%v9CTix(Qbhic+9kWKO0Y<4h}`#!Q zyb>~}{TctQ`jWUip)$m=Mn)iJN(6K`zwFkQoi}UK z!>y{bjn+(?;PdLsAc)>b1`{l~<`*AuWmX>4fk~f0Wie%WGQjeFpu zD6Q>f5=tgTUmq^`u}ZD3-!lDkBpIiop4GTni3w+|f+Ap92O_ChE3FGJPxhEMzf_JU z7Y4OK4BzCL(stwb^Vbg^Lbs5At7xkkR(fVX=`C)8lnf8Aqo=(fnvhMyV-R-h~B zJc^YRb_eYiHS!SiKpXY+GVe`^d-O6s!fTXArh|GI_v^UJ1f&+qkIV-YY+t50Ietcd zc9du)8fBRH%DxF=l!mHBy%r}me}Koo)@%e$%!GG08w1S_yZidHvOYF--YCkoFapPR z03C$!vX&<0eLe(CT8hFpy@A<)0+N{}m@vUUdZ)3+2ZvH{IG^x9-HzwuBsjkDylvZ7 zZqw8zCL;?YLiui1|C$_!lHn|Rv_U*TQF-vZbeQD;g?NqG1^x^F!tFuQX*?w<5H%7lTHFd9cpj06&~7#zMD{(xua%!rk1l>KxWZP*)0qZrcjrG?IsJDR8N z4CL%=op>MCgMda(jRj2RM%OScY>B#O3bBl{18QaO)jLV;Kunb2GMDfd2hMkzBhmMD zFdP5N#DD=ZKHTz4o1n3BBQ~Cf**mEl$fIyMl#B~)Phd;16rg5X-fcv3*u0V-hr4))@ZPf0TSJPT9L=gdY`Jn7 z_cC?FIQcDJrk|Ba$Yp!czvT;sJ;6Vpla7g;K>XdeKrr++34V6nkX%$ba;#bNA><2) zT@e=nX>Y5b!BS?@E&$NOw`&)@fZgOku_D|HF{-{=HU+xW%N`3je{9k15|b`9C=&>1 z7`kjGKpj#UPOCbKSW!Gzw9-bQ--65-=e388bgb3Aadg+Hw(#1;>Rhb1;LrVJ&0Iz{!7Aag%58`7LsB@wMq%P6Per2uIT8+!G7();EG4u zR4vI0ONz@YHy8%BmBb4w600Ol#&}B^M;9<9S(Dupf z6QN}54~2RN{)m3VlGqY-DemA@1{tKa=d))J`@__&R)WZ(Nk5DHV%0=``F@1O$+UhdDR>IVDg-`BL)nIBVL`k&IJE;Sy;NVGeMirvPw z_Ap9tn0#oCIKd*Z5ehAe{!|>!u|+C+(kEAT1xGQY$5f7K!jQo~4?xJ}ln2g^Lvs4c z{>TJo3uZuL!u^s&n}#F6EHk<#$?UhacngQb9-WvgICF+x!p-M<*bC!ofBI4nnJ$+r z`030?YxPb1S*ZX%_hk>=5td{#CZo?Q(TuJOyaI(mq3kSBH_e+HWECBGgF{>aTp9G8 zL(>ypIK5}avI6efDfH1g2gkcXkykXz^h5VZ7q7C@k;DkX9}X;Q%RQF8!B148REbyn zj9H@7i+*)f#yl0>6(%bI;pP`;nB^X3Hb6$7smt<8{(9hFeyWgMq`ld>KbjfM8@^3! zA0>DB6u46~u!B`}BB&%TefzQ*Ev5?2RiEkEemd5;kD?#~gxkO4H0XDAFlxOYwh3#a z$NeK=uCHR{5au@^pc5XJNlQ)r?z6u%@LBfRDB6_Z_tB=*C6r6Es0)Kz4ruxr)w)d8 zV9t6vyE6nhOL(v(Q7l3)YiG21&{VuI?K?b@+KN2X+DbG)P_r2wqsLPk70oZbxVwN} z2%x*m`#aKuc_hYT1^w9P)6FJI6Om-#X!E3oQcA>zCiIZ*@;YC$nAR6ke1MJk!{fQK zpp!DsdAKrv0fb|_yhU&zztdrpcOG9fd!e5?@12Y#xnaA?95^6%qH$JA9>!?)A#A_z z3QMkwhX1BS{d3 zhRbR~WJLUviNjB5Irbm7rIa@1li%WBHCPPT&*Ixm%)A=S=pOd_GNWwGHb3}gpCEta zxab<1C$W$w#V^tt|4uI(_FZ-%@bmm;&i$v38W-IFPJ;dz-hXb^HXQCGUv6QKeYDh{ z5m@_d%-tUJDq7#Z0UP)0W+tVzYi*TR8TPi`@Xb0a(1Ibj})_hYF`HbzcKRAX9cu1$O4i=7e4%0>{>>108IQ_ugDl@qgVfjhFldqf> z;bzNFK{j}8U!OAn0XE+UtPXWeULnQ0f5$_?IBQ-59A6KU7eA~k7*j0%X+zqZ2~U>* zXEFQGZqcK4PT3K=EWD%V8cj*u`>A43=>v}8AZ$mMCK1|s-BFvE7O@D`^BGN)6Bk$&#Kj|2DKsV&@c_(p)|8Wfm(osU zlp0jH-hHBS9TRiK)NGs0ZOPP9+k%zs>BuI${y35P4_ zAM>V!hI4=U*45hmL4w7#g@9Ficn15J&5Z{ zc8qzbzE|p+M?+8q&10(~SIVG#GRuqZh!)SVbH=LJX4!hKAs z*ED$86f3ox(3wqX{Q7JndXv*q1j_IJPYa+!Od`akqmnRszO|x%cN_0P3yo1CxavFN5y>T_e ztV=an1OXV#Y)k$M=)$44}xe&Z5RL#r*ImxUO>JJX$mmf2TyF*~?pWWvL|E0c$k zQ|n`7-BOkM$|K`FSUY{cdzD#RF+J2>L}j1rtA*?HcrS)*sPnL{bjf_f=m*<54-#PjU}@vH z?Q>E^>j{U31L<4AACo&DdY1RvxT84hzs|7t(70(HKKAAFbPRgC@q3fgRmEfWx!r61 zvW0W5CjEB@OZ2EBCbAUb`b8y8Mv6w2wv?BuyN3pcR$Z?@q~Y)In*a4oqrc}vRTW4w z1Nj0}hKbWpO0pW{08aQ;G7LbNy6>)L^=FtMV`;|v$1@s8VGwN@S+lq+CbCcLpo5L? zlT0?>kJYl>_e`DFJ%~tCg;`9;Kh=o`RhOyd?7yR#tm8l_?h2W`9>1PDU<+C1mu6qLI8A!PI1xJ#96}W$^0`?J!^v$QsMxFmd56T9IEU~;d)U$knRxu#~bDYIY!ar-NZ?2 z0FPGaAO#FWQF(P28&yNoEcei`-%O}pV$qY5a7bJ*(n;t)AOsHJeh+c1I*4CqYLf&_eYYvmiQ@7_3{=_&tp3DZEBE6nI1 zBR?C&j{IQydZEeV2`R+k`$5Ze1Umho`(Vxk-`Ys|sn(jd*f>y9$1?rHZ)S^NBQ69E znxdO|<6eiL#S1=t@%P#TQM5mG51Gkdb27YmNg94YFt_%=uLtcZ5z+H)G1SR_RmN;o z<0ix5uHQ_DrNrfxV=%1usTXoF1$VELMeI%%x@As zB^eK|56i?*Fyb`7Gvkn^xgB{6H zyL9>pR0hb?j{$AGkLY)G5MwACSA0Jwmw}1nS!~McPC}I~ky7UJoT8bsQGu?X*w>ZB zX4nBTB=>7>B0@I%9oX2`xlAys`C?@TIW!G6-(zqWFlD25<$MC!SbcIgm`tqneKu3Q|T#B_SnE>G`1+G+q;^+iEvR}<%MCV4x)CVxer0?H} z_QId9T;?V@@}awS$+X^+BxFa?^pHjV=SeemrE}f6$JIX;6~v~^^_YnzhW-Ay?nLO| z@0BPTkA~%9;l+rSPz+opdXQH^J7i)Q|2c~N*Yci!!@KXL$(WAgwrN?%!r+@4henH* ziGg@adzo7&*zEWXFvQ1tGmRS|xQapE0fCCwj@&T+cYyn8YOE=*WvBix)lf!sVqFg=Q$8gZ;*QtREU_(8F6B|HmnTzT3V2hp{qQ7vOPKq^v>#t9~Q z_(iSQQ7$eRuGtUL*$dMtsW;kXY4ub(az6`KuGrA9$Wch#hDmVS_8N4b_7EUC90E%I zHt+4vcgAs&N5c04i;o5Tv=kSz)SA1Y$3DxG6H(jBj?l0U-(`OWTJAynG7RI;dq83z z+c@{(24+k74FYs|1RNiOl6F6iSz@{wz_K|f@XxLjmr@Q--Div*ZJHht!VuRrYLN2yR{NJ0GV8}?zr3(q(K@FQLsUO=|mns>-HUlDm!#f(DPgdMij*@gBGQ=bk^q#o{{58us!A~}@0mK4by1qY34Wj({9RPOBmZN2x zwKtMdQyKO-G$oZ!cdVlwX*2Kn?fbYv0g8wG&Mq5v(EKmpW-B|)4d4U~`isC{y!Nbf z=fN}Rw>a+$o~4RGgnhdHB=CJrvD$O@uy({T6YcKszP-B6(OLBlB(+_50~Pn|D6A}n zF%#eaN@~GQ#%TtRY9~RF@X~?wX?hI@WHfg0NP!f*I=zZsmI@E>o+o1?go!(d3A=fwX!c0I9oUCH^bt|cR-Fws=5d== z#yy+%(xaVD>8>Pyqn3ny{He2w2rH2J)pxm*5Bbe6w>FCC+cjE+MEopHFGnJ=qtdJL zRHJ2&y#hjc*v5nl*Z0@h;f43&_+ZGG(a<|p$mOI4ShLJ1nVw3v3O-ALcB130%3Pyf zPzlct)O(vmyYNB3(^zE@UknwkP!RX_S*Ox+Vc2dy5iC{}d_7oBz=wso_PA8!Oq7oo z$QR%KxQ^k4auHJ)Bf$&xKNyLn&mHksg+K|=E@qiSaUInv-pJdjj$Ut#YYk4w%A& zSXLTwdje}8JNAsh@b}+N{S#Q}C}3JEQK`D)jC4$9%|8Cd*BDJ`U6TzgWBJjA1XvBAa+&g`e}(Ol2U9f363RqIQ?&l=mE7D;y=^0KATf zN>*4)rpeKh2Z#_qDzvb(N-GE}kj@321|XE{F)umSlf&tb+Ze12n2QioZ6h1={LhgH z6KWTd#%#Rs%e$}YF+t0X%l?C|OXu0%n1yvW z4lxrbRq*lonQSqdwU| z8jI(lt(5FJ(J%fJMoT}XZ$qV51U?1^)tq)?-{rm-)) zN8D*wj|x<7r$#Ik$l7>~J?cs!K=C>dr-T@>EJnIzjr|;ULRDE6k3Qwt zQcV)JP5!H=9P3HDfRSvKqY6Wv=6#fA8i7Y&ak1;j%$3cb9AEOFYyh0vZ6tCdW4D^N zZtX7&3RRk<4lHjsK=Sx8DM;#|qIl9pZg=4%%5;Tipik#RA>$_70sIL(4q>AV!DH*g zT1cK{Xu|=HZ?N)pp!$;|PnrsMWUbg>$>*am8Qar2-IeXeg~P|}_E{L?NvPD*#_m~~ zP~M721=Jh|>i4eqg}(IMmlR0v5`9?k^DjEY{sY@QJ+CAJ6fqr@$Jg~PqD$%1`~Qhi z{(!8}GYRwadE-17m=e2XWUgIXJAL)))owEJYx;Ek@y-4ZavTs!!^XQedITdXP1NPK z?g+0;Z<&v@wUsLq9M&!63PTm+MakkP?xlGLOl7%<%CAh_r;4k}Il>`BZe^M}kk{yu zm*gon0j627hBW1hRLfn8INCs*#^OjDA+OsYt&|3;GX9yqu(mK#co2F2v2Z<9A}r2y z9&%Q+3#Z`glcQki6TmDuXi?D)JtV0dsF!C%I9k(&HEiyiyp%j7B>5%Z(+y-F1J_&Q zsca?>3+|-wJ|`vTb-6-scowx8^}-gs&ZK&5=>mAZg0w2SlCWxOThe5{uha9S20OL1 z9n49}AyQdPh(Sv2?qAoV-SCR)USckFHe*9EouOxAq+Ph$AK=a(1GiQ3#>k4qR%m$>QAn=M@4rvBOZ z$dJ$8oJ^+|3z=jwJDwMcITz>!%%Bi66+dh?*yzUj+`@JsPgno_+ifYwpC5&?@lN$Q zTp8u_humgi^efg?0!jO~ zM2S*bHl;*D>*;jOTiHT~6H*Lr)l77;)V0p(ZQt=jzijJ_iTv^$V~li6;;lZB7CtPr zrO~#7+heha+fY8f#W3H$Y|oHnGq)$OEL_=chgw{4-ZJ)I?5?)UX$sYHewv?o#uRLJ6M~#k-iX}smtgFC+pFThM zU`=jxBK2j3q405W0?{rf6zNpx z?~uoJFYrd$ZGz8Q*|;im>Uh5`<=h`?LNAOWFPSnkze=FPBLvIE3J7hzeJ^50w_}6^ z%#7PE$kFic=>oye`;h!A#$_V z{ddjW15GBuuzyWeZ1tS&V?zioIRPANqO^4OK5KBs_sImO^`g-q-v*a^a&_nl%_tUJ z7&ex&T1ENxOCo5;y7lquSG^~Mr43G2AIh7t-{!{pNr7WPR?Y1o=|2c_<;26MdxjVr2#8z(BnP?u^95%*PN|uHA__0DCtZ&ak+rf zUX8xTYr(g!W|cXE)Nv{8kOtWw+~oK8R*805fc8j1?g5Vk)Yt9L=h||BxTq9w>crvZ zgmI0ESzu~{AJ8Utt+hKQ$pmlT)SdQJZ~|{RY0>O~X&XHU4zmaEbrk01&8vy-kB*OT zx_<3i>`*lVtcUz=UKPk9aa$ODXj|uiSl>TTiasaQwlJk=+*L7T{$m7?lJz4@EOZip!3G7Fjx=4X)bk*2(t{&}gdM-60 zYf&U&76OGgHb=@|zu`)7kEo1;Gxpg{0&YO?=dLgwf(TIu2I)58=pS6XD)`sCEI4)t zm-*fV;+ol>Uu6^A(}lq*9xJ!p#pq8}s-%4w3 z#i;*p5)-3mc2RE8K0emtN-e@ zt(de)^NWkSJmiO8=W_yk7u^roQ3hHF&Y1WPNEJ;_ME)v(n_2K`FL6GIkxZLFqe4Su zs?M$8jq3I~rYEvWQ+_dOo0U6)olqLgyUOz^`krZ9&R)aqX?m;2O$F5YGbRhR-+@|V zfveqEDey8;nNdDXhA|+`=&9O{Tx~Oy)+Nl;!mT_{ILCQP#(enh?yjz> zp0Ae-m*FZftHZ%8HQAwDcsTPLtBSC{?XO{}!h1<#Z1(ZntVCz{kLao)YI$T8O=dMd zw?BU}tQ`bPxa_p*klW5bt4R`;He+FoNX^fEPHC>~lIDk2pX;2W@`f`y7|~38d}25G zf(LUsSMguLl?8bnI>V7K&BrNZn!jne5BqBXK*2&u@nSYB0+Hopuz9BGFs66NMUn+e zOR`FHxYnRGjAZ}$YwAEt#8GX9GPIK-%zem@H>fU3BVTcUWPmyXhaqOFOE@04IbkM^bTC;SCXi( zF)~SqAaPP3H9SXh{E#sYx}GiPbdRFVR?K92o7TRkdHqMs+_Pb3&0Y(HOkM4xLJ?Fi z13AlP12sWc-XrPI#b>BCln<9yg@HbIUC0>LbeakUtsS&ZI`9eY9#( ze{)OcmWRY-?s362F1oa0!iY`Ba1$7pWYdmgD&JwY#GHaN4dJ@gnpg#XDrO-YpMo3o z;p#szpJ*VIGX=ADzt!{XIBRN1Sn^iP+oVBuR6(?@d0sg%i$gEvzr8?U?4lapI5&cg z2s!5QA$BYHVP~#!OsZrx^p{ODx-vchdgUOrJ5gisF=`FHQRn(t-c zvz^XfMB?|o$l;-eCNcNHzeRz; zs5C-8$f?a%`Pp~hVJ=HuH5yEFYCe2s~qdFV54yRht1_|b(Y$z&^P+sIvKa$Pr&1_`7=I_&n^Pv}D>Wlz zP#V2+_tGuV7bRn_Q7)eKowbJLQ&-Z|(}K2#j=@x^d4G1QL>*qa&hG|DNMmj5?>8c4 zgY~b-W`d0(%l4wAX;Hf_pw*YEM7+i*!wn}V?WA(ei>P3~KVBJKZtB(|*N*A14Rv>w z>Kx)$;I;ADmw~I8M2wLB(?Yg%UaRPLvg6_rO~)gRQZd%TMZ&Q^-sk0U9WQfOb zXZ5n;+~0%2q<7VXP!;y{zhCbYq+doOR1j-C_!~t?qj5>H-E5n`vGs5W{*rjmyCvJ` zkeV=2iH$mioVPPJ@@KsFuqs)`oIfP5+`BEvE&{vp13ZMWr%%dxr?;a$ZEmbHe~@UK z-#!o3wrFef!;j9J>4p33HoHwr52xYniL1+eb*y&%G?v=LMF@^$zA5$vRVTv+}j<`s7St@Vi;|$ z?vB^Gx|Z=BbjOC?6?{h?r(jyy$E|QK>_V(*XP}OVdi+A%`b3T3Vo(a#SDK2S)g%&p z5+7wd0fu`lS~@x2La6OWDD-h;^x-JvW3Q{8r{fi?un2<;0l2WUaDN>hWvuz8bG~&z zsZTAwK1L$s{ADo9nHu7AWM+vc578V{!LesVlyhTh|Z!%WPKa93Ho(K8?4zXXk&4mK6& z2Jyx>ZpdO+z*w5d6*P@LI_cg%n5EjJX3`cW5E0m(67^2lk;GfdCZlsWB{WC$f9kPP zrJHEVO4z-LW2lAWue6ogykiW3}o%h~!`PnM_v_=tomBZ=X4E)*#&N6T5G#%FBDD+PPgmtdIXatlEe4>EW;x8*S3K9$}lWj%j$b zWjx{FfaHL~bX!WBvzo?I%@z?86XV_B96Mh869?byZPVf2zKFK?y*RVQDcpOzX>rs= zb`|R@{BYQ~4g>bvdnw74h26&1HwaGFzqI2JIr{Gd$13U0!ysy-IHrW&DG` z<2Ge{hy8n2Km|notu~$PRAxDQ4AUY&V$U+a7BJWlVcyRZaJFC_IeXpudhbYQ^LM;< z)k+e)q;@U{Q_zm~QFK0OpEpavfrv*qZW=ema zn=Ut0YJ?n_&E(TF*4Iah!?G6U=W7s5rP$8jF5rdxuQnj=ZPS!%5P_vEb32J_z)0MB zg;5m~(Us3DBcxaQX|O4s#-a*k!nrlarySml(pSbdbj*Ek=zrQs>z%Rc3Ac?`Q*$G^ zu*mJ^JEg;%!l<6iZGOm98q%P81`q#GJsP|7dV)Y75O^V`@}NX$Km%e5&L1AvAo#!QP<4Hc+kZl3=>AQ zzn9>f6TFOh7%3M|nD!)#vZOpV;UC0DQ+sS#7!R#XBtz zj|0mG^Pmu_S2ILf5f)8_86aQ9$==kt2tBV0ue+5yZ|^`J=TZXVfQ1R?VngWD(Nl;Q zN-#QoL&LsmkY6+pJUY``L{|jh;x{AyXK6o&rhDrw-e@Rp`N#kZ`!@&%^biu2Cgfj! zLKOIfuVXTv71MNLPNYX&WJ`ZsO_>;YW@+5G%`aRZCh zP!eU*N+;?(lcbCso+%QK-r6tio$dVYf6u< zj%4NMrJ9_heS2NL?{uLX=3_uEW-o1;T>bn`uYGX7e(^qL&1!K`H**!t6v<%IG?_G@ zdbkVeIFSK3z!}tPt3T)^U537gdaLm;B30vgnSCL<;6Tmm^l$qc4$mC99V4p`R9|OY z7$T*^A3V(QY{2fy1%G^e7A(kI6dlBcQUvy%GAj=c*<-{Mj_l-?qS;W)7mReSlOyZb zqSRFtkG(srCvbyI?Sp+0v-QZe%BRzlEf?vO-@k>~quvO?TuVqz3&FSh74gidh9-tR zMcqxgQZ%`10=^?YTgdd;fJKgVbI;A}}1F2b=Y$5}hatv!>Nt?Yv*>^Ef zeRYL`f>oTWud?ctc6SB^)9J?k`*ulg)NO>{cJ2@Hi`BDy0I)@5X_DY;3+0#AUgnu& zpEv4QRfeAQ{yxX7btUz&?Q!&jP4v~{b*tDAN@99?dKWbS{zZX5b^1le+mX2%Uq^gH z4E}_OB(%z2d~+J{NiPXvl*!|O#U~L~2miY$Zm|NQ@#lN()Z(24BIs^vaZf@0tXR=L zz-8K>{oO4Vp4ypfHx9fy4u&ZkbCS7Kn{u#*YkD*0b&RWv(YmxpQL(~+*Fxs%`;5yd zrQ#aWK2pQx+IN(FN5EsT2x9K!|L_Vc>N_*Q;ZNw8TngVvd;^1q`1t!3ig?LRm_0{n=k6QmRMi!=1%88cUD60oL z*Cn^KMqn;sv*P7AC|W7};2A=YPV%%&7EEbk^jKu=`pw;WR_dv-X1Vs_mQPCLSy>MI zzk|W$^1uH8%lEG}UL`MyFGBB)Liq3Su$aQmVp0f;jGB$oZIvqB!;l6JMr*7OcwbE% zhO(W_M5}~wa)WscH%EF#e+g((e5e&`I>jQf1H7dLb)f;T`JnvvYDgTlwO91UGY zv^E)+eUK}77q@BCufF$j>#dn{%4#^iHP(t>2fq=qPtCd`BG2B;X>sqc$UaU&6#SUY zOAQn^j^p}_ufqC`edeqj8nE1BajGQ{djdjoa`Hr79i7h3uC5D9l7Vw&uxZ#9{r8#< z@PP8Ov*DhbWg@-yU8l*iTNlC!(VEe)khZwC2zTPpyl9?2iB1Aj`8R6`w(ZVpKR><^ zA5;Y17Rf$FwSs1%SUHlTI@aRh6W}WOonj;|Wyq~frt^KQbS=RwVZQy9u#a%nqrNnQ zRQxT;l(4uY`e<4(v%v*o8g|1}jBEV{Se(>zVcK~Q^A7UT#)B9MwY_ZCB>;w6*#lg6 zQn6ewW-5FnxniAxIw2lLHqGc%c!g(#v#W$n#i>M+f00~sA8@qn^I?^VaW6l3-ipHx znNpea#Uh3@PyPk~TYy7TPiv4VHsyn5_0vZbn#JC#*NP@|t(ibYG}oo-_9=lrZa&Uz zp#I@GRC18oKCa1oVN7EgKR8IRS&aibu2EpYFW7CsxIE!JEk7+FX)k|8zOqyLFZ3Nt}y`Y?X;P>))nUrJQk9;{2^RdZzR6 zG6)tz$d$Nk7^~6M)#ddiSO4;)D*2zyxf{xqCIP2;t>7w8LArYd$;bnrd{*$IfH6=1 zc3vjCeHt5tJXWHQt&iPBNcfsW(?N=9iZ7SWZ(xs6K#on^XB6!E-Nm_16MKC~x~3|x zP~$Q1&zTi$@RAuKhKe7d3_y{-XWDuW^1GSfgisoYF3{mT0y~3l{cyyNa*>Cd`5LH8BGm9D8jk3(RdZzKgCW?nlQneSQN$Wu{kGW%C~p2`u}wz5Y1j4$_F&rr^1TWWaHuo$+OCZHl!P{F-pD za3Fvvq$uLzm+=do-QDb8C}S1lEv?F~Ph-@Pw;J5?D&i+B6tE=B@-BfD9N+5Xy2HXN zm#9L#8rr_n3b40nN`BsqqTg~ozt>x}XRebXS8!!0Q|^m!Ro$=I2OZasC*>!f-eSp; zMp#edCI4EG#a0TyJCHuXO;3MbD`2!NN;w|2(dV`&Z3~-^w_S5kMZ3ud*M+{2DTcI# zg{@DG>M@#6+nyrqT{4^O{IY~G(a2cW2Jkr}qaL;&9lzN?|uBcW7WguZYZbJv*Ap~+A zkxTk`1+XNm1T6Q+a@X3z&pobjWdF{Q44lT*VHTHWNbBF9C z5jlBf4^`%hIggmqj3yiFM7n=*4TtZw8NX9NwTe9f2DL8tuu2uzX=Tip_`6*WHI=bE zF4sG<9}@6-MZRJJ&p{`x!YAP`5hI(`2jJ#@$OvN;ur&haZ~HU>mv+<43Rwg>mfxM-Q<~_08bF96S<*uI@v^BkzQVBY?MEf z{fI+L*d)x=4-(f&^im*r-}1iJrLji}QOklyA&H}h#y;A? zH7F)r-MqSWfp|wNWZ0ct3!!P=rN$kR%tAh|Sa)8n&RP+SP;Qv5F*3*YzNmKsPGKLlT6~0jqXNMzKv$>SG7OC0MwEvXgyE+p zAH1`Xf}nIb{gAlL_5Vu;dICVME6K~(I15I(slEqi$1AWOks4aJxr?JfXF3;)t&F%! zDBT+0I0%!RIhh#kU5^+UO&O78qOx!@<+ypH03v&GX?3q_j52JoOjyV|856;Xo?4f> z+hKLkc5SBvg`GHF^JeX3xpWvJ+?Fezku@5rj~) z_*z;ZqamZoyggdM&RF&}EA`&IF>*MQ_Uswo^p#pMo4UD%PG9sES%vUH2`W!ZK04LA zy)9~;lRrw4*^0(AzZKfaMYz(z03+o^&EV?nR;zr_q!qKrnKQ@Al|G5CzZc+RyF53A z|904o24Wct7M0lV5%~}D$V`j-FuC@Gvjez=vf~w&TE4utb7G)=Sy}0J$bxR<&(y%Y zU6)GL_3JBv4-nlrIdRSn|HKHAlr8J1&gT7qEr+as2u5+WTmRAJ#Skn3AvnNYQvMIL zQnW-4e~JL~6nZwqH073`bNhhfOmpB8#>(JUalNyN=qc?`?peMvq8roK886YNDlQ=F z@_wozo`+f7P}Zsz_r^Da+5AaQXf??@3MYQc7caWUhGtHh+&okl&SlcHc0w6>6JP%+ ztf5)v%H^MsLo5qC3AuZHYNP)3@o?LKKNnnLwp+E>Q+%>#UVt2hg zH*eaTa-r&~St~7v-od|Gm$*VVg+VJ-h9cxF^OFp!X z?;P}+1RZR)R=#S&B&Ft1{Y2%q=*WPpUcd`1DC^dm3_$H3nHN5(B6#-WH(^240Kj)8 zu$}n!E1QZ<0c;hy$p9z0vu9l_mp$KDXcPcf<@Vsq?0A25JXLAxczoEtK33lD9AP)Q z3qm*V3p_thjeVS-wx(uXZoF2CD$#J;rV%;6QckeKYfkp&CFmi7hr+v&lJEh+!NF6< zn`29rKmyqEGj(+vv#~=&B@V%ocuYE%VyLi?v`XeJ|B!22i-)=Rl*)LsREwgslL0?H zB(L!+9xT5Mo>wcAI6f}L$cDx7wO1D(ONS~b44R24*q@9p!_KdO7(&|MiKaMXMyhQb zlZJd^S=ye>V$YS0m~L^XjY+{9hSzvHUy(zE z#i(?}STasZbS9aP47S{}$H!DwS6BA|K#C<~8Yp-L0!xE?#MCx5n+!gZi)GJK`?YyH zx~~zk$B(2hfMM8ZyQYOei6}f^*ol%rL#aojOi%E2cfv%&yjr4xV5?3E#F!ePY7X5Z z*P^&Xicc=pdXqkcyVin=pba@Sv0~cu1=IK=SzP`^u~Mm*HinCMOfFB+Q>Pz$DUl?t zD;m!~ICo|<69GZW=}pgsRNi?Qo6L@)N|JfAucgCabQubq4xp#Lwhy`H8I^f&gPi2{ zRNc>sD+SjcHRc>t_Y0gx<%S|pqRAE=zr3j%7R_0_0#lTbYrh=1Kv|o82rvZ#wzjrL zBoGzB{OJJm2WimCTzz+tIFlx%;zPBFX)ij6S7TO#m>ec#^A?dqD2rMpvE^AT^Rb+w zVvF%>RY2$;ogj~amSmHiH;RZrdULvM`aV-laSd2d^F&fxg&6vrX}v~|Hwl=qqsHL0 z(oTPdhSIb9?MiapYZfr|E$o^rIjKlp_*(FN6%lPpF}-Gs3_ET4Yo+7TKVeVsRhiBfjs{FGXT7*?B!(ZuR?%Jjf&u`*IQoIUNK;b{sfJ^p5S3szyy?Epd_5T(EsTZ;RPW&n`7oU%3W$~> z_@NbHSnoLdc4W!%%>KIBWnMN3j$zU1x+hzD_)Q}rbG!Ic>17sOoor@Yb&gEVRMvXA zGk!agihs=s)BDh-!!uo}T0pt!_Jl4HE+bRwMwr{o9N?&uw|1tnL&Qx?O#T2^8^%n- zJCG>s1n8WXYLkPXCzE*uq*0A$YOPb%zo~nxJFATsUB;NSfMR{V(lM{r99x`>ci9=cuQ;6{lnqd zw9%^(#|T&AR+56NUU(fqhvL)S5d(xto#|3IN@J^7ot%QE_W?@&w%*P*^3|vwB z>h6Z{iEkhw5Sr-iE4s50*7dXm(3MR} zqVOEnTmJgaIrW_A?Aw7fdSPJx0$#wxW4bv%F(IKXIx0%&wThtEC$OE{TV86e3crPh$eK$YnWWytnA5X|o$Pwl;6l7+rjBWi4AQ~w-HOeu}GP7?L3zMHAw z#r0nvdjQZ81qRMiRhf|mClmSew3vUUiwH0SB>9qb+XYt0 zy`>`X@F8R^#H7}61O&(>3moT|Avr$Ahtt-`garvAYgZv?gd|--jtYi;H}KmPyPKKR z7eH_%W{vp6ak6`OF%pdhMLNEd@^^)ZD8C*lCnob3(oM7n7QDOkv+);BkyLt1QcNEMXuO#svJkId{9?4vIQCJh564>3uIJMKOvO-0P7I zC7o;l8dqt)SUQUs=Mk+|Q)O9KWF|l8LoQzG-(QV<0NXKfs0yVf{3sQOabz^)1VPEm zhR+lv(bo|Hq>h~F9?NBmU+oJfDb3aKx=Y0S(R~6y79;NtiMo?LlF54uyw4kbWOO=c zx@?QJa!XCZ%!B6~=1MYfBk2ay>7P$lb=YzQBUuNMKU+`JeTQdvNNUGQI7s-agXIhh z!Op7{1#OTgGMC39n2SnmURz2o4gn{S`yDB}1XCdv3!Ww8OeGft8mtz1wYci95mVdI z><|?*glQ^aLj{V5_r?-|WRj?$wy3v2B?@Y=x|v$z)THOu^V8Ej83-5&AtoPr1MY$* zX4>K;56>!PqcKucgtHE8Mr%Eql`Ai>MC|5lr6M-GHaA@#9E9j*{1bBplO20aV=Jjv zzHC_MfU~nTy~k6p4Pip2xlC5eHE)ys&OZa9Yr+{tprCmofD+{vh&UNkg-M+&K~zFN zwAAP@7&qxrM@On*jEgA1wY*>+YpWEOwG=_U8R0645uX9B%hLJw}*6)N%D8V*JGoOz?`^;jGnBkD~4k&SMDu6rFmup zmY##n20h+nclRsY*H7~NZK$4&IjoIgaE*x*Y)J*7e<0mchEicMEk~~mUv^(WaiO%q zp|!a`O;9=jKyFM~V3N$5t&_zcA;4uBCv^SE`h+~RBF#uz+&BE$5%2tb5N(d}ey2#Z zASRgrl~Io;H3{Dk@vHE&=~{`c@XaG>XbT$zn$>_&&pj6ulYrW3ivD3k@R~EM)@FLn z!z5&D4KyErV5%uI;9wXdWim404Bm0Tld8>C8OjwN8_-ep)eafW`fsgj9QD_b9?E#} zfpuY=)J}m+)lnn|4k!i0q6lFDMEcv*kmZ<=9??T(A_4pR(HPvNno%AHNofBxlHUBg zN4qS+-Mwc7^omcif(LL2VBLc~9`pubXwOD_fZ_NEF&#npNu+dWsLOZ2ix~*+Df@lK zF@f%i&IIIQ1RQ@GSYY}2K!&lmINcfA^3x41CN6kAL`7L|^!tJ&LO|G;Hg*N5 z_aUMJJ%1?^tieqJQEdV+32pQgG9zEscQAdujlIF0Oa*dTq=C-_E4V<;WA(aw6Mo!D zD#|g6yN6BG>GP8n*HE}I_l7Uaz*KU6?=y7uJlG^O0~;POUF~}-sG@%lrind6q9;c9 zh}YgAkNskpjpyl3f50A-HIsM4d+gl~C%$E(Mh7pc=Z3)u=9q4eu01FrA8R=oxez8r zFjDDP8NzW*M3_ELx}Xdpr9dWSN}dn05j=ra!eeuXWG)X7X&W;V1RTcawF-<3?~HXpwJKrJ~FOocP842e&y5O2CIjUx4!tI)tA4A=vTelKo%U(P7%gzehd}qryssw}SEXlR;NE`USgCS6R12 zTR~kQRVONpqpM5sDJ}ow!DdgSQdl6h8N2JgxNIt$W7R!Sc*1sQXAb;P>eY z0oiA>-HI3Xi}Pl!lH0O*HSmKB*dGoc0Vhl=-3&9Eaw$*JYi9bl>`@An`+5)m^7!pK zj{a!#C!eW!mx+svJ<~yzy=+(6Z4%~aqrX_7}F*~&e8;`U~&TIHruTT`-DV{x!i+w=CTNK6IxLdbOpPTb^@ekbED~BHw zqT!Gw#C2qgUfntukp7DWz}`Gh?cHbZMjm<++2UsI+UqZn%QR!TXEVHB=O_|Mw#F0c zR_K)^F2t{mV%KXMgYO$!6^+w7HvhsdCqBbtTz50%h?;HQrg~!{Tek8Q_J!Rr#wgQ1 z)AvQ6%&|(*4HMPr>WNQtE&;r-9#YHsiVk9vEdoM&oxAQ zjo{xdoa~O)8z)A2#OhH9J7#T9QWCiYgcfhM?1k%hompeseL97XYfGjP1Ya z!pXiNU@A(kfJYse=<6H_*VQBCSlNr=4R9{ED-J`FHOZ33R)d$s2QxOWiHGG4lnUVB zA$8kgk}Ti@e9)36Kz%;MY-jC5^+zx4^oo{Jyau0mlGFx5+em+qY$yl;sfHS?@f=pT zqQ_hRtZ@k>hA~!;-DDY{C^EP)3{!$eY><9iWrcg(b-*R7b$Wzkav+yb5NUxUQBG|2 z0B_agL^jp|4;ugE?Q>5sRL^IX^cB>wsZ>Hu0$&`u$K|5pbR}ZnydsO|;dMZcBIWzc zY>bjosv#kT4O(7=O902oGk)(tsSeP%e^1k2fEs=R!z=8$01`GJCO38*E!*~l0fDPW zur*5C({ci}cOz~a)lGE#j|N>_o%6OvqQwl~2O3;05NvTnG%Sw3RM7Eie&DF#4QL6; z<3rgll%I&xu4ay?x1BrBDXXJ;|9+-|N%WBefm@;S)>=1+q15AS(~1^6o^3S9!YmVl zW+^~xo-1D71p-`xuNMI%qG(Uq(?A!-0X^Zy3=TQ%;1em&%5ZKsQ_BBoQ9(lIuVmVO ze_cHAR;I~NgYNZI@Qb0_%%qlyg}gR&1QDKb?x+i3^k@dOQNPGwS)~_IsScW&F}^0p z=#qZ>zCK1W7udU@tK){A_VJk#)aq7bU%of%$^VG4oiq@t4Sf7yp9JkTCw=d+!v(sI zZzylpYt0V_7k!YFu3L9mk`kMD<{^MkJaF!GyuVTExOa)tct3mm5O3aBCQ@ZS=h_Hc zMO)utReado%<(xZCA&ZQrZaZ6nU%Qnwn0$mVdeogdu;yj`(n$m5B8g*J${!(j~*D$ zGW=Ot5sU5DEfz~s7Q3ZGINnUOE@x-0pDJO$I?ifziGY0xmPUyJ80!Z_0f*bPSJLYV zEmy~d4=YcE^MdK0P=)@&n%EIfFZ@e)rdVNwb*hTszB8;QjKeKHLa^iaA@O5EB#jb@ zj&5}@38A-Yp2WO%Yl;6mK(LhYJ@7BY9sk!*tioH%4*=9@^M2Ifr1sy|LF zw@TA8*sjw9vo)J#eIwxmk?2A`vBbgo$`~tt|2h}SF7Z?r)`=sv>m=(mx+y z1V6oPeQo@^FUPxW6saKCC;uG{eD|b|gxx6mZZ2kRL8-_Ld^7;vap1wadFOpUlXbvdy#J)q6^%v%Ccu=3I z^GWq?wury2b8B}dePIxKaX@FTn3{x8-p-8aOiZ<2)}Ys>)5Lf{vM63OsDnDktO-+QOig?#A>jJFwD+~ z5u%Dkz8K^SdHBYq-t20dANTstJd9CqP7{pMg+QR$Xn9wVD$_^_lx-a{ zBt`L@kqv+la!gOy&Y7k}{mJF5dXksk4=Nu#V=@r?#|QZhk7Z)9vNY#U=TE#Qn~31| zBlO-!JM*N{1!4&aAUTre62yE1#{dl=B85Z9GtL4y(xO3TD zQ}2%Ck!+T|7vk2CcQR+X*?V)<;6NGeOs_x$?`K<@ka z`q-_|G)KMaEWc0zT6G4G@|0GG;37VtkY3Ofiu{VMmD%sbCGAKI5x?#wCm|#)VJj5X zm|5ctQP6j_0DWs*K6~ruy%<(7tFfT#Y51w#TSMR3(^~Yb9IE8^6WrFO?Y$zCGK+@i zq0SUX(G%A9Mu>F_542vcw=}AC@2FnC@nL9m+KjiWtXEjFIw^GDu6mlqSlS8py%4q0 zYr#lBKu0}fI@Y}IjSMso0hY>dUl&rWlW+%`1h1k=biOw(uADopd?F5IP|19EU$1pY z&B4^%peO;Mf@f+~!3l7T(ZwbR1JGI0D%0Xp9?^C}=9+CfNOy%d5G4HaUN~kcJuU~x z(vyA;)+LA(HIy=*)(uhTeCS2+o9jVwFR*V|`3ZzQ`IU#62ljjux zL6CgzZ_`QTJp6sL=ygck^80ae-L!y{^;n4)nV}SWXXY8GYmQ`6TgO!9R34O+!R1sh zLYImoh`PAlZy5V9a+rOy_X+ zen9_1jOF3RH7ed^#F__|aagag$tVk2gn-ewL*eIF6?pX1G{|gmb$#PTb;i+O8-A$J?ej zXIjn(b#AVQ@jOnEVls@|+SevYVUxZ4!zaJo=4r~6NaI;TPcvQuA^X3#PU|<6ekt~R z_Q|PVpQnnQQzqr%W+z&1LS7V9S!ZmFFQ4<&ljY4%bS3N@6aeGjyp@fZ3;|@+GGuth z)r;M`Az@AAp%(rWxv8(AgFs+r#N%+O(G+zxfjrp!uv}<;1fjZ6^9q&QT8`3VCxqYZ zjFe;OhfgR8J(5PnUJvoc&4W*aitqis?$u4VgNMW3YmI7S)9n}D39z9YLkfGxFlxvz z%wENtfc%l`=leHOP4g~^WVdSo$D3B#vETCQyI`$M6lS$j$tG>hv4a zIPVDqDp&i^<>GzjlD!I?@n-j1|3FcIt$?``+Y8zn!a82Y2oaAI$%z4Xf!;2E);aT3 z{S+n9y=uO2GJ4YDx+_v)m+$fTI7omH0%fC8cU2ztIT_)jm&pLWN_FLP=OLC}$;IT0CK($4?xyf3CbyEr9h5wn}4^xVMDE?QW0k67y6r`|ld#}QlF^2OQ6^ZcLh8YvX?I8hl3VidtD)BtFJ{0WNH;0mG{3`kd<)6Vh}No4f{%8 zyV|lTlT5}}6)KQ8n$NlE)(y1odyy(p*_Gh7+!{l-Ke4X=x;Mq(GFIWVo~o+Uw7<-~ z^?-4t3*Vx6JS1|AWMZWg#Ozug1X~{cR)A_C2p||&ZgZj-be9I|j-lW(5M4a8ck=j# zMWF4rtz6%~cy}`*d9pc_s-)Lc?*WYzd+_+F-{pFDn(thqt2NsCm&U`a-@UPB0-rn2 z63OGGaVZMk!qJ)q@y$EZlRH^^#=$gpO!Z7_Rzmct>-Tz zd@ixmMJrOh>sM%r+s$e-g&pRxG6S3plJmnb6>}`k%r6xqG|p#Pj-k%V!~!>3%my0@ zL7U}bw#oOH-GeZEO2tk|OOuVjUtP%+r~9A}fsD0+2ca=KqQ#1E7(ceSJj0~_C0ddS zo@0_Wp0f!@2^@yRN??zLXV+)AbCB7B|6uAumHl)Gt<3Otly(s=mB~c5V*F=+7cY<{ z&mkcAO4dMf1R3O-#4KTJkX`u#%fdh_kJ#FJhwJp?`rTy0k3&PflnRJZ>2g<48WA$` z(r-#Mv~3Udb800%(IAKL^^U^l$3Rr}Fl|YUfHfS4ix~q(kDO!#`xg2JJN(9FVV#HVH;!&|eHdI+>;>~| z%CN?xXXwnvx9>6DrdJw#;vN=`9r}Zm<4bQpOu@Q(D@|xcHIvvU- zAO`x!%(?UH{EVbN^;#x>lpWL1Am1oK7u-zR{lTW=VhAA$yoK{-m|37@mbyUZl3zm? zEr%)zb7G2*k?)dsg?B`WL6w@P@+Y=f-WDASzYPx$k8vieOL3vbwsZ1h%?z(XhdK7+ zKi9R6>XoY+wJJUl<@)l7V?GNFG32ukVYfcV1hL z!`?e6#4ju>lUk};Zm&NVrkfU2~i7>B^Rr;U%GcRL9J<&eS&~XV^nRA-SGU1iYOB;NtV)Q!fZwI zYMp@sAxGTH?i7WL(GG5%tQbvVs^Hwk+IXdv)-Gtt2`XR{C&FwWA0Vi9PEF7qVMKp~ z?~JJ<{`{OmGGsoEe783Q?yyE!;Fp9Bqw$kUZY(mhKFNS&lzI-m5hw==3YBUDFEtVu z@g%qDLT&|1C50SCrD%7kk@+&QUVdDq_ti1OIl>T}DNgYk5bwdUI0CNcbxS_fy`g87 z&yh)vai+Smxx}n*0ZsR|sceN{Lshio)#!kJ9NBA^QmM;WZErzt5G~y5I zG|wfatLYF;P@Z->hU}RS-tLYc-s8!-j)6+B6pP>JQE&+1^(aBs`siDJu(jS_#NzQ& zm~E~;u$&#FZZe`Lyyd^MZu>#=B;MU)kh78c+IX8{i97vLoaoE2KHVYYlSL8&o-dv& zqw$sFx}rv7S2`7BRT`YxXB!fJWsbR#3W%mxU^%VPJx{6dZZm1C*}5!n=-K(bZfq*} zUE_$w%Ei7$&p?Dh3M9WV$Ad{ToeXXw#r1qIt(v`$d-#t}hY`L|mRXIVd(E5a|Im-& z-5kwg)k05yh8{Qb*3X@Qzw*~z6AAjjD?Z~%#opDfG%ItFq0uRUZe&GQ$rbAZJOYBl z=U9aI0>@!-89bE1^i=H`-Y6;AUGXYtiU2Y)28A{`CmodPDn>NUm>O^Y-YYXJ4hO)+ z_gvpkfEYMakwe4Gk&k!BOhJscgL*5%QGKel8 zD7PAkkQZ=y8C5HwTI$|@a^@UAj6 zvrN0(Q+r^7&_J01qB6w_B!nhWdua^1i%NuYRDo_fVhK@qQ*@^Ao5f5q`Lb`nrlD>h zes|HVjdiWkX@JZ%1mfxgbdNvf#n>2^7lkV(!3!NRle;$DrvNi1d3y}xK2CjPb5 zU|c8-^;At~BqU(7C?RWzysL9+K6Ur}qO`lT(A_`Ldf_YBU|+5WJ=K`G8{*Tcbq}z) zzQt{9m-Pdu3)$mL6||v{RK53bJ12w?rgobdIv&I`?lN=UgUH0bjEUs!LmRoe3UMe! zRGV~fTOG?5LCVsqz4Ki$-BG;uxY^m}(<|L=PYp_PSzzK*2S}N%HlG%TqYK9(E1&;t zVXezw)-C2BOa}$27Yg5bPP9Fb*7zvup%B`|HKQ}CHM|E6YhWG13qxL?u?ms#U`Xb4 zplc)Pyu!k_L`SQd-m~v;47>7Fpd0OVdT(9GnX(BP z(x&m|o|E6dwrg!}Md9pQ`0n{5OzCz|YQ#i|Fv)3^>%&DAyKyHSMEj_(3(k1vxO2Da zupT5yO%{o$->Rj{CbS9nNg^7HX! z+jP(EnEGh6jKm5mQvRO}`By)F_U;JClhS?c@J&F2b_H6KKfP-B8&c&JheL1?j3BlG z?5bwx6IR}L#GvT>V0zihrpJVnLZfA$WZD-y-bq&hS_pv&wx&+9M+SFO0E~_H;Ehf+njY36Kra^9dofF=V^z7E(g>< zvjv|##q+WI+gRJjHqb=l!GW=h6ZwMOXyS9{Y*%SJJ*VK4$T(==NPlP{f{8*&;z%?B z4qRv@7O;^K@Y$QLYytt0+`4YDd<%1=oYBR8y(Zy&=F4+(^D2jx@gB?hb6lZ#&I_wV zTkG>7#loq$h-39ty&~v+#up@emlhcL0VpZ zNy+*fDaYGt)lrU2To3)s0ZQp&Yy(mM)@BK`m2e3Xx!vX)V7W@!-O(TI>)h6t)ha7W zydR!5o)A3D>{KOI47*=AF+(qHoQjTb`|qoq&xr{`SZa3^vRkgujXi)US(W|RfuDZY zq8^KNDtiJ2u7&)e*RK4O`WVTZlGsH9hSxW4JV*4K2GDN!&D2uo)``}yg-VnYuNQsS zLtrrsPk=CVoJb1AEIvLf>1S@!v((-y?p!U}nKtvpE1h_g9`n;;d(tkcLD*bI%?p$# z?+pEJ+ra&b4D@XrjVJKs?)D8hDPfep4dR`F2oGfZc6tYDcUj*Y5ip-Z+PgR77z9fp znhjAB8Wq0Fy|1Dp>pE!t5s(P$sz+ZA-R6r%f!y`aYRj?Tez!-mo#9lF4g?7aLB?mv zwoFG694egK;Z~Y1v3}kSEmf!cFwue?+r@9$&~e;{js<2DsDWO~F#KS?GkER18)c1^ z8}bwoBK&eAh$)96eC`M0Un_CGr1O6wylO{9kLPf^AA84;Pc+llUltOwc0YP&{v-0r z@ve3~akmZ{g-%y;O#VRN<5gpeR?VOYtq8=rRJ9qI#pLg|y>RBN)yLWRm|DfZl(jc5 zJsv;}GB4O;nFFPEq*h^JqQBIsRLxk5y=4`zcBdV#B06qbJZ??;PmG>8R5}QITd*0q z-iBrL4c5f_NY0X@>i~kqbyPoC>)L;Et*qTIm#1le!%C^~9kBqZ1;*bwNSJcjEgpp( zIz`RN1+@%@Vq)G#?U};9N~k$*ZLlFj@wBLpTT;7r#p8`JdlTsFqK105ZvC$Y*A*El zbp?`1d~5n1{rzoajY;+f;Xr9_m1%cNTwTM7#K2_?H1cAU7yrq}LD9l|Df9x0IR<+_4r z|XlUT^#nM*| z;T!{WhcThsO?4hVr(h|71@!G&wJ-!?5faQd*I3m!eseAwd7c`#mXv<-_LzzwB|%f}|- zx0^o#W;9dj0uHNT*s@T^)6t#PKtNR{poefczcgiwsd4=q+j`vNb=W^zDkisWUB*k? z-J*ZvZ5-%g0n%Y~egW0dH`55xL5JMfqrlifHkxRqNV7;oDeEP5a*y!1!BhQmPzW{S zg2RK}0Z);X^X=b#6Lg>w+2gc>E&AzGnT ztc~z2BlHsNn_M9B`yB9Q9CH$YynF)AeX9V0&g&nU?wtj8&*^SEdgw=R}$WCy*DDxF`IuSs@7e0WEK?~S>&CLMILobyX2K`6q`ztIs z_-Wvpc%TMUQQpUr3!N((D!M5`pGP8F;T^G3u8YLsq#(c4YML;6#IkQ1gVO9j1#%}6 z_^YrqUSO{uc|Nn5z=?Puq1Oo@gfnfpD^cRE{NGFuU6M zYa8dm^7krOV=#$U1t80>H}g^8$uxMS)2rjc2^*pWTga9RGT*M zE0z6)=6YxCk)kygIMAqN%m6fwmcL(t9gYk>yWVA(WC*Gcumt@Q0*W5@CLnvsxbQh; zl4He9nyz+7lkpX7{qpiMEUBU)MDJ!D@1O2h0otI!n>$)Nr!-g}gXvqXC+`1w+~AjR zfHpnfZbJzGiq=0KY5qsUSOj=t0Jv6x-9MZztxXT{oS{DX}V7{$^v?wS0Z1l{Nk-BtSEk?COj zhaP`J`ic$W+0lgou3o7#4M+rX1IrcB!SR6J)y2L`@+eU-f&D=ds-YhSh#gB7$z!D8 z(s(b1#jSCMBE4oXxY}wkrJ3N2{lR<1IZcPp_4jcu34h5G zT?I7cF+uPe+cOdlXMU>j+RRf+eY1{64u7C?A}F0$%ltS*U{S&aY?>+*_bfiIM?^&H zrDfki2$G#A{1#xddjK}OTuMhK zSs5%L|8$fZ{4IDhrB!8LJ*p;h*Db6am8dExG>HLKG+nb2=$oQ{KNKbm1{&5P@&~_B zTpT3|Ev~Bth%pMLCnY&s1F1||<2F2e!+$?E{2e^arwTGL2MyuFJJq(iI$cL;Y59oH zn~Hm-$*@2tH1lh<+op?Ln_J_r6Qu?Qj+>*&2S@ky=3%!Ef5VeFTq5vT9ql4F<8Sg~ z=IB%p^c;WJnvat`{LJwi*j##`;bl!tZt-yZN`xlJ|Ii|9*H~tAEHK=u#TFmjRHOOqKS#_uq z*H5wj2+iF6Yp+HftcQE5+Tg9&S>Wx_=PF=;1XPBWTbjk0Ts+ZE|)FY5XAp7|Z) zUdV4+)DJBAYQwXwU{GjU*88)Ps?SDhHsLuMj;Cr7f<(k{i7l!k9hG9+ZR{~ckx z03%wg_~7;FqeREGANgh%lt}BPmK4b>>l{1{rnc`UoW9>WEUR95u23;UsSHCeOpk;} z3r@CD&2_twr9#K&D9CRjg_}RrCNUelYV-8)#}h3UKgN3Ym9hWlW(slC&j$mFI0g_{ z4N)`}Ep|j{7>I`Q# z>}wnCY)f``T8Mpp3hjItbYo(6It|enX?2>5cY9t|uCiL&u7>(W(7FcVdeCWRzg4|p z3#$ABVPhA3Wri>2o4?PC4MRgA#+BNM*ja}utO|N&*QGOmTT2!yq!DYZnZyn*7qC)l zdAt-(+Qv}W4WX8k!&}U8{QYuElNhkng_~&ljo*Yf3bob>^lO2mBZ*hbSf_wb#;%|M`(r4_fjJ`+G*Y9)fTZD z-pIOf3KZ6z8?}5?fCdIQ{@nnu{UJa{L+tD6@gZr^abfu9i1E+*fQ$%-4Qyf|cjDJ7 z9#VBJqMD=3dOtZvh5Y6?=t<7wzqn~8KUcO(zG%NyM;trtU;RZ6%Wj$)!kqIhk5vp!PmBN3YWb=1>uHdQ4e&=H4)B_@C%Z}+CMj~fRIS^ewKjp4=n@?mja-i=v5)NZ!=#I2 z{+Nxm{dk}z;V8d+^@YuVvH0snT&d6)R!VI4p>24N-dLE0vMGfv&F(|JR+CsOQ^;AN zXNbmechFhE?4MM{h^R4D253W&geXPM=_hL8D4E`&7<@%W-C_&jEB`$q_gAyeeSSgT zS)6-yV6k$3=51*FthDn->0a1V_)jg;+A^y#3gTdA1}!r)GYj~`?9Q|EKby)wD>4=Y zp5|i(9X-8#1~o^T|2h5IO9ov9@2AhHiUgJVC%&%s8lxT-`p!= z)2a7jqurzE`_pnCP-wSA>a^*%U!LP%x&AUTZC!RUYphk!iJ%l+!is4{x=(UcM*LC{ zEuQ(Mtx0AveNtqmYtk1@- z#q(l%O?>61;Zqru-fS3@UXyV(+z(JUZQt9{iCy7=IF1kEd}G0*I8N5|C&HCdMWrG{ zVTLG*oNA-9g2EJI4S<+#pd%FZvFzW?g$ZsZM!XxF;0fhjmu}VGUHSTg)k0z^(rApo zJ8UeY@788+wDtJFG9y}XDuLIKBH3FRp8?n1rQ%I0i(KXk(X9#C<g$_^4{;B76|WcXw{+9%+)LvRZ>B=~%~SQL zv~)34KN?fN^V@5wUoTEYq%(~`dppy6hY|3y{)2?+LZyKJJ_crtlFL5v!1t6zLU|NL zPi(Z(`-kpgrP!DlAJH1R*H-_#4}%|6KLM1*xbldeX?c-3$X14JRpx^}%_PDFW8iSH zo|Z=Fh>jfu(jfdNk}}oC_GppF@Kpy+%A3&oL=xNHwA_bLW&1=^MwL%bEE;*A}xLd zXSd?Gk!uGL3e_8M^yc6-px>>WB>wlw0@TE*Xi$cx#P*V`bGuxi$89@ecwbrMCHb>$AI(_a+dhB5K!(4z-FKf9Y^PS_zg&~%q7{WPmT%B(3KItB^^qD-PP zh&3@O_>?}hzhaeBHW6zQ(sWq{O6U&<{H;)`uFj}?HCCcAj8zmreAxEfNOmji3w}fI zU_#hfWMY+A6qS|~{8dQargV@Qd8kcFwotOV^LVc92Lr?U`Of-lECQ3a;aNp4cgbJc zQ0??4w5?n%wLCoBoAJ0H-91Us2c~9rIuD3C=bgP~f({b2;@Nwq<*^>GA`RR>${z_k z9_TWpKiN($XV+JHUq?>Mug%2vY)+PR>P7a`KE}BhoWws&npL@uxJrH_-U{vZC_yV& z9#_UfpxKF@^o&2OZ!P^3h(jWN{rZ*hjQ{(`g8yFq6@T%!!Rz|iMTvjVB4T4xiI23Z zJwM^CnTB+jNBX;3>Izh~zG$xgbk#q}5y145X*E2=KiYtD*jLi7%sYhmnRTe`NmyO{ z4e317kk~X6xeSDJk~kw`FT&CwaliRuDA3pzcDhYR{NlGMD(|ceU!{uj*aTl^mm~%r zx2?pNG+N_@hlFRhxRbv0S$!>;w<5uxb#i!g20j=!uZ0$`|NUj!d%aduk?EuTbZtY1 z#A5Qp@>sr%itbp*i&3^45la&n8`GA?Ac_=3Ue-^sG9x~U*DAhJp)NLbce8vi;3Hu0 zb@727+m|05j}SKLOtsOCr9RbAZvg-dG+dfEAv30G! zX9HTm@;r!r%{#lrufsZdf>fX-WOW~CmJHqPjG5!a>`}2%!u!_0t99No_-D#23oOma z*e12BX7RDBFOGdhK-)$Z^yM}Yb2q)@MTKWcZb zYzb4YOiw+5(ap}(>c~zwN9au%%%cN4({VGBTbgO1M!alc#CufqQQ!r7ergD`EqXwy zs$FkQs|v|4OY7e=88QMqO?E|a7sEI7PFawQ_{*g_77cWLLctTN0^iAVt^b}d^O4@3 z*;wB6{l%l$dXsGT+L4lqg2G!uLc)3`=R(baf7cMOIzk^q8G`Ybs&bFvZ$TZc4iQj$ zU}I*sG6exhdX4++|G9YeQTy#kmWul+`1$DuM7_t>fckc6`%dAj#{b4t|C1a8pCzO= zC0I=kVz`+$1eM~!*2>DtC@EQ*=|IO*VQ1Oq{kZg=*I)@+Sd7!h z|M~N1%p<2i?x_pbf9J0Lcw`t;7fqO7@^rByOmzG6y#$p*wVVbx>92TGX_p)5=c;7A z>;sU!w>1F6?A7JL#?t&xjQP(pWG3<$EmD|fQTso38dcg1rzVL1NU^Utf%!+XO`5@1 z&HqM$^A#8-BD=SAQ6+%V@Ai1w%K@1 zuN~oma4|9>Dk>x1R&uNR|15$jkKa6G8>N?*ToF9AI46)S9YwGX)ZJ$y{w5d{{-0T( z1_DY&roF(yWfIWIWqE_=AHfa@n}Qh4wBfTnM!)}ajG9D-52+~8yQrMk*_CM*cOepf zZPEQ^1TU_DcM@Wp9>@uy01|)%b9BJM!4Eh%Fvq+>iM`Wc1_AqH&I~U=O@@joczxcn zcKtE}m%G6dY5Vut%EK}MrzgeAy&C|61~unDa$bPATG`aZ!~g@+N=xDYJij@7pd{1) zn#7cK{V@RunR=>Wr;kD#8;1Epd63mc;E?>N7q@(K& zmoo*u(AugV@$btKkm)b}6FKU4SHjp^Xj45Q1fnl14ERornO~?%Bv2Hw#8o!&hEmvy z3CPLsbY4>aKKO4?bCDY)K^OM)R*-@GFl;PG7170>!-vu~3zFMg(J;%pPe%h{?KL7G z*f#gBjo)6BARKuxMG^{@>k9aNE+4gScNyDc?HFFF#TE2joxP!fO0bA1CEu0JO?X zegNpXVvM^d?=2u@>HpjP;dGDR3(3usfws-H8K!ujCc;MX=@}nH*<4r&Q!@q$G5YVz zZ?4}ks~5y2HNrBTW8Jp4P_AzKS{=3Tg*EO5qm*QLE$6CsbN8mbUMUcY=qlig2#p-^ z-~MgZQxj-UI;S3z%{Z6)b%M(9u=n>D?(yWNklF8#&ornE?HbRI(O~BasS0f^jlVM) ziO7>G;Gda4IDw9$0n3e7^&8axnyLm*gAx!<4|$#9L#zMA&*;2K;!ncyM(F;=u0?%P zJYmxk1H$q8z+XWD$Grm0ohIl@-V!R2!?L6U2P(8TZhB_fH|8pe%pU41FfNrGm4vrG zIIy6@^Zo`t{zeipi+){=W)m)t7J2jZYRAMq5$9oVpVP}FjfU+L?!AEbLrYyzr_lLLiNOcT=metz$|?mjaQMX+T1)32{)<_1*X(e=W5``_~{%b&saTr$bK0| zA=tR>gW`c`{ly*Q$(0(LEcct%rDB0!+G8pTqz-)UJbU;NBp!T59#-X#c= zXh(!0wVl=%yE`y`B2q~Sf06KmrFt*-pPt!{l9%ll;oO6g&p`m6Jgi|XPDu);`UT#;oHGkab1}kD$l5G6urn(p z@P2D?&-U1&bJCn=k=2$!HD<&%sbYWyqkGwW_Q_#D(E(2p+ex@(NY-ZMe}X%YXpq zE0c_1nN3M?TzY0uKyrJ11>sswvLx<-dVLlueGa~lWf~ZmyZG|fb1E1B9}Cs|&g(xv z1Gk&}A`sIAz7wPuSjFwzr}X$kwrsTQ<9L?n=xCNxjMDte1rkF1_dzWpY+x{_??(vR zd970d+CQ@VFIo0#8EUH-!G*t5jg9(Cwl&I{=P#{{N+{=!X;n_r@Xotc>C^qHDuzNl z^4>I_Fr!NXR)}lt65sK)rL-GLywX%q{#qU6&E-dQAVz+mAv0UnHssQex21nistwJs zo?K`gXWEsW?ni~p4+P%a9v>D7{;|+pc}Bghxb0EJrItJ&nZ&~_PeJCQ+v8ul#6^}e zf<|g9AN1=3o8=uZ z+j5MLhG3m8^l^^zS#7hvcist*GO0JMpO>0P8~OKkwCBw>SuD#|mo#$syw~IK2sKgX zSR(3pKCIDHyRNYtn9St%L|WarK-$5}s^r82ReS9@IV??7S{7Yk+mxoLtnJOCY@5~L z;JqATR(5q}OS(OOu4|rlkv6ue5{3?Cg6`?-(9wh0U_eux3VY82bqF^+_*v>Vu-qTN ze|~aJ*Y-w}R@oOes+XY95oHjp#;uq}1B*qd#0(hBD01Vu4Gmn<})l zb0A~#!Q)~3vNc^LUT=$vpxl7}vc(3=egNv1F5fHnDB)e-hPM$46$<&*Rr4vTfi3Zw zXVzzIs!;7a!EtSes3$`ma<^yCxq7Ca!1ik%2uQ6ov7hF*iCwa|&owA+Lm9!P72+*%Xc%Hh}gKM3VlEZ{Gs z?ELwf|BTokV{XNOxmN7#lsP}m6xAAqRQU^4Uxo*~JZqwJHvbHDzwd$S%h9va zr)nq~lW5;%Dn!vCBb`JNSyLE#@NGxxcAaVll8=nK-pJvC?97$P@e=;m@ zVWPRA1?C}b+;Dv3pUK#DMnCRBDytCKvT=i7{Vr=e=Emn6@M9>V zT1$nsLtYcVifkgjGiO=coQa?E_7JrtP@ZjEPQHGb_6eRTIXAYo{E(p)e}PxxbScU@ z^qq!jq~nM-^TW~G1S1bhG*^k|&Qn$$Gh(eJH3293##F@y*!Nz+wtuq9FD{+%&+9Fd zY8m@@)tXXgwVzqyv4b|LeFb6B%K;I3aN`0fwPVBD@gDbgvz5!B1V?|8b@PzJ`NR;( zf##HindW@2_|(-Zd-qbxX43=T6ZyEHTK62%0P)8mzI&SStrunM+-x)Pc4|{dJI`n4 zgUzu}_kGh}qhVhWjQxDr6DGA(3b$rsj<{=sYj}+Q%nlXrXOlW!K&}Nsam-ZIZP*qDB>Ahx+c!@yABjxf}6y z)o-ljJ^Twj@0t*|%Td)^ZXRjM-S^geC>B(au+uQ=2WNFTHTV5%d4jBQUYFLh-o0N+ zkMkRj^ZCNO7to4}%zrpxah*opsMz>eEn+#Jvne82nc8TDeh{Je=~IA*XmeY_pkXa$ zsNgI5p!}2vdiy0pGk`opii&CbFqQBy$71?Gvh&JR4-bEM<=3)$&X(dUwahD5@w+e) z(xJ;zQWS&AXFf|dw9m?4lV2Qq4AL8JCf%5Sn3a;!-&Oe(>4%A7sTxd;v$luG#%Ia-wY%J$YFVCA_ zRl&cWa*E!dFc_1&d;Ihm*%0g&0lcE02$a{KZ6@v>XZ1BOBQ(XWJ+npYQNvAz&qm22 znP;MOxqzKj7Mp-4bxP=ChLiub#>me`M-MWl6N!>uKEq%BoYFh4)L}A07{OBRmTDg* zlO)j_MVS2XszsMC-}acfz3$#E{uX9k{8#!d!*#g@4th|GnaE@BV;56|0JsaV|#t?Sw7p1c6WlL^WsPCdK>GM=An3K*T3xW9w#ar}t;-2smt9RhA2q;rH?#?oQ( zrxOgky_YK@A|f31^17$IMhD-LauIZg9*9Saq`j z%X)>a0i%Hv_k;DbMG`v%j=Jz9KMbi%2Q|G;qQkfh@;bY@6-H|3M28fauNC6>j%mC? z4`R6#31hO{ZkX&Zd1}~1p!hJzhdkgq;y~;PEQJ|5wCmXlYY^7rV9e(eoal>W3ZPNV zcV+$VyWa6S#U~7`fssh9*U6_mol+Vpf{VZ5n)_X5!fvsNrOMdiaJX(=(q2kq`f|xX z&VNR>a4_CMM(O8?V_ozl%%W6}i_+$E{N+OEKYnPjgCCzo@HSQt5GdV7$Vu!`2f}(F zj8G#yNafin3_qC5-rUzdsN(5Hg;$uBY{m!CBgH+t2Pm%6?Ga5>kDn1k4j2uBw(@+Y z-AYEE_4S=T``ir{sh-x0RHsfpTZ@AcjOX| zrU9`2qXzaDMY(x1;^U1Cm9-8t-S?H$NNSDOY>$0?2KcI#rA~ElrLTu@HToWK#p$Oy zJ3B+A*0Vpb9Z~%1F^I$jz14-iylcmw7<6*JYhzz4ilihfDq3hB8cN;PD9jBzw%G$l zok1iignGxqK%l5!zBM9%MZ;&A!_#1jAI=^d?E!(Y66$rQN(CV7Owjl#=zHj56yPC2 zfMz&yY_02;hj=Y2UJg@v0-KSM5t?ZD^2!R_Xt>YU={FmU&*(71uw*^>zVQ8Q4B0mW z*rKg-V^HkJ=_9tseSqOvKlk_8E@B)8ikVWX*_0e4PzJ-*glZy>2-`7z)G%2qo};66 zM$8N8YrhR?t#k!6dG3j<0yXLwr3au=aoLwJ9001hy;eu82aYr;MIUL~exWgSGJLk-M+mxpwiVjz_i@vJwA zCGlrtgwHa^y@h%jEAcL;{w00i_(*=)EiBJ%kwt4aPqAU@zzcmvf*u|obw%)rJj@XX zmKm^WFgALTPfBpy5%Vjj0Bhc4Hhfs;xsQ5<4TU*mxO~(7E97qF5FKzC>6z-5Y9k;2 E2iU8KRR910 literal 0 HcmV?d00001 diff --git a/versioned_docs/version-0.47/develop/advanced-concepts/baseapp_state-initchain.png b/versioned_docs/version-0.47/develop/advanced-concepts/baseapp_state-initchain.png new file mode 100644 index 0000000000000000000000000000000000000000..167b4fad9ed05c2fc28884d7ab6bb1c9762eb87a GIT binary patch literal 243455 zcmYhj$IkOiwWJ)L|JQ%}U;m%K{>T6LKX0FC>#wruiogDWa(}=22LjdO zy8Q#?|A8RsH2w42q}7u4>pzEL1Bbxp{rGLlruhDS4gw+Qe}UltfxBO4)pD_CO zC)+(0e;@u9N0WmqzHLt6rq{m@WA73414j7Yh7x={q@ZhmhB!;t0u1xt-)jDCOgS@? z=iXMU%$AK~z!}Z^b2aosN{_VeE3xiT1Z&LC`B0`C&&7BY9^Wla0n6?|Vk{ZKI~<{~ zdCW%9*~79EA@N~b<)=k%OvO5m^A3X9@*Fg_ITIN~SPnX)jw zC&%2XO(^~${i%G1kHAk6-Sefa$g&)vuh$tzscrW#e?c=D_$w%hLfZUBA8FTXUeWgtXZ@`4S z4@PW+_;JM{Jg=S%sxIP*x zUmumWMYYCAa2gn5*1>58GQns?&R6(-(_;D9i63s3AJ~5Nvt(Bk`XYw;9gGf(YbJ9j zEtm+_C(QHSX(>Owb7V8})bqUhJ&;RL>ThM#JkMz)*@xEZf9daVY`Ds#1I#wN@$2?* z+h}Xg#e53>Wa0ueRNL6AWaQ$YF+djzqlzAQDDQYmu$TFl=p;1Et@9ifO~V-ErKirp~-(n zL;cXL^*RF+{#73Me|PnO%hp1nVksW69F*JTukVcPykn?c=T^yQH2VnwtDN14Z`WsH zAX@mdUV4uit%B0AiJIk%yV;GY3*Gav?mg2j##r^#KDBc#nO3%tLemX#`5VBNA5Tb*KfCKrM<`#m<@C*Vygldc?M_v;)n zl*`d89J$<^-aecBF-8W zE%!?oqpZ;*_XEhhDpiA&H1{kBXX1F^(C=q1+^RGYamBa~W(i;RgHjo)y-pH)S3l+W zNSwypAz5{|gqu+0-!;puS{9nsF8ww^)HUX(qnG$AVip<%Uc}28P@7dGdQbUv$^u{#v3Hw~*IN)Xn^o zjod8^J}|e*w~OxBrMjti`GB696moo}h24X^uNa88&DCwo;JZ^m?^agL&0*^)vY<_o|)sP%7||yfapGPoXdb{{z03&DeSlc6>4N zIY9B)MYgUvwvr6(A0v0fZ&mo#PO$|KoQ47CMFbmP&PCD4gn z4H{Op&-0C`{^=!L@a4Woc&yNlGCf_VCiS^Mf4xlBI{sAYeu9>Lue`pm2oK(#Q)J2s~xxDs+YKZ?qWOFt;cDr3f6IT3l54Ox{ieC55 zvTiauC+>$O?vGxCAdRC}CfKwt+*2cISowniPgY*uudq zu1wnfA|EL%9OgPnl$Hpf<8qeBI5-oIOD#xRK5f?!H`^|o#^pr803y=aL_;mjl0cXP zPPBT_fm2sQCxOFC-gU@d(Ia{~n;Y_+FPO;qF1Bjps;}I^@NXkZ-F7*gOb3MzOgHjZ~H|9_P?XwwOQ@48vj$I*gx6GERsNJSdNY!&U-!K=< z1R(TMvB>iI4-0*SiZz^!iWiBHS&+3<^;~zLw2-J|X`4gv16(rZ%@nc=JtZSM!j*oOr)o8|cy+ zEj6@0;X0%dkNYefn%y58o`oDhEj0H&FuRobWkmF z$GsNV8th+g7?=-Y@y7BQr5&vW0);EiO+Fs;`R&j5Sv^~D1Q2lsPC8J&!nnyR4xUoe z4-$VZ<8hk?5?$Ty1X7|(zGsTLMKz`Yj+xcq=yjU|V$9L%{nT7H^@GhhCCk9gu;@1Q ztRr~gN^YH8cx=yNM7!Qih$CN4dtLhmPV;N3>;1|N*G+B%hxE;8X9~-GKlkJxSURD1 zXqMDcx8>0tq-**(Vw!zCnUm`NAVa~HUHtCbl zhCK!$h;|rGTPor!1o~m0Wv3c(Z!FTbHO?1m*zu?KKxe6-`Dm%nPE`%MDW5 zi~0oS2~`X)#TkwecN4NA$K^*?xw-Z+zuAE(qnS0J6e<73lxF)&aD@TV#TI8e$6V|FUy4J2B;0~U!@a`R# z0l*Qs>S6+e%=pW*=PkQuTxlW=*Bl|jbt5O#Z*0bo3Zb;iR5fWgOG3B-(`tJ%@yW;j zQi_pps3-!9{Nh;Vs#K6QzuwFoZh-94u1^G!It`I)Du3)3u40%5vR*dIuU*RV9UU>YsY6pBELv7q}QmI|T7MK!A4e5B~-XLG0~1 zad5`6;CUu(ki3%X%f_Zng@mZhfU;muPWN`xKsQPi+$@xw-wjKEW@94ljIu+MYEQFf z{bBUaqN2Y>1>f-lXVPoO6U&r%z2vK=EFIx!e!qs@Hp?$@6L#uT+O8ZG8Z zGwKcH=IPcsrgg!StL40weMOKtmNY9E;Nu?$ATONhkoQ{DbNnp={aX&ViqV0#! zNe8UX5^z-CEl+HWc1iTXF*BZp;yH&hykO)aa;nh|Zlitia~vpEY+7}k=U1()CNO)p2pD_5 zKJTh*LP9#8bp3}Q?Y|%&O0Xx=Vd;% zgZ1m{1Fwtp_O92L@9{hrU>R2AvhMnPg1i-X9UJdZaTKs96y@(NgNDPY++9VKWr$+PAT9g`Q^RkUrTY1r0dkdNEOQ=p3Bd?A&#+Po*D@t z++*vI_v`6-HuVf5VbG2_$!#k-0Ljq1K7_zwHWyJ^3AhKLaZY* zl?JVSm#gPn<$UO37}(C|&CixK{iTONjBZ#WIs?JVZ%`udCZ@hCBkn^wQ24xN<2#o! zzz{npaLRFfPThjWVvTB~gVYQJDvrqZWvZ`RZi*Hwo?)asoaRL5O@>WNE>ITtomHPIh)BJVS75R3 zXFzmD!xmxBx*hP|jl6AwV2p_E(vX)Y6amD10bMOnv&=^w%5Xow>%?(VIP$Dblw|Ay zPhcU>#}wDoo`FKK%aY7~9+8Zzc@x|c$1 z^B$@cv?~G#^)*6lPLJjJlwxha=IKhmahbiA@eZ{KGjThmeATrc<7VAqoW)L&z$gpC zv?4RK<+EwB55JSgws%bw@T+9Dy54*$_2{Wpi|wDzQ%^O?Rmv4#TJNq0#wYnV>nTS@ zmfiMxGnAF(uV1k8WOE(R6v}Jl3a2k=mkA@b1^@`)z75pXSn~*`qzs# zG$@D|`GFMvBPPkju|{k9ETWR;Yl%`(tSAj*ssLrx5!3m&DD$WR_Oe<*N4Zc!g!@1>r23NnZv z*q!3^0VD)UK0loHYlwQnAvZxZq&~lO27ZFImmRyGUpFn)lK}_J?>{$th9{2j`$JYr zBZ0T=2VMlMy0UMwU3$XsOku`0REyJR5@0RN{e4Ro(1ZL;-1_`cEBi*>pBkewOVl+V ztBFxBMeBqchKgj2eZ{?W0sC4DfMR2*#5&ZIYM`wMs-o?q2nBdeKOKOwpw_&u92cIz zCt%_vNjwoBL1RW+0tb7P^dxddrw3R{1R;eGl;E)1DvGupOAP zljE?yoYU7|mT#Qo>kIM-;*bFCL(qIPc=Oh#{CvGdehfN(lN4(Q$-9QG9}w*#=6UTh z*TN@aU{enzsxvOqNc87Yd?IUgflr4LNjd!21;c{SqLMp4?IVMtAs(bQs>_MkG6U=Mqvmwrt5x0KBxY zdRvhXL}a|>7xHp&e7q-0ITnsei}h3=QAQnwqE%cPxx;vYHB_|kO<;H*GFQ@E(g_Yq z+&3^GRK!7IAS~zk!dS!C9c_dedm0+kKd6eS0rgMgUCQgaAF82mdHn=DJi(;m%yND4 z1Qo#-kN+`1a1yK=5DY@is=sd|7aL8X1Hva_y@W|Ja+V~n$nDS#?x>QchTj2-QFf-hUW_=uH`brf3!N4KGuW@$(;0O57&Gb4;IvEw0Wd@@snUp zs>*2{uZyPs*r&)q4NC~?P4Fo;&(Z$d$~MPMP(NL zs$0M)28;`B`&56JwOJnk%44QS0^}$RyNTZkL@(K0a%$Snq&()85O;c@EW`iuvviDT z4NmdbC)Q)~QOY=h6D_(W6|hPDz>JkdG-8H+v${?bmuqZj0zP9~YZawi0E2`T#LzEd z%iWk)wA6z2IhVtWf{njazYYd|7}w58j10qveFCW#9o$s?TL{2`G$T<2=-Tu?mBSiXZ>%Ef}n%_-wNCB|8Myh=WhelsmaJ z=vQQxm|i}X^CTQpy^flElVZhwRA88tg@v9*&)xyij4xsO_ySt#=ZHfG@@Lm#A1%LOwEi5%x#Hk_;%>c)C0 zGL~FF>t)1m5S!5k9vDvOuk4d?R$Mj~eIVxQdvG}r?#R==%`Numcv2NT@h$nfPzS;a zpu$u*br>BF7Va(o04$3Xic8b`WO|w>nK4=N=0i5j3mOzrPP<+8U6v&esEP8-dtfNP z;`6pZ#nqc=+`Of%BSUsi!-%WU_FDyA8becNn_^O@m|CHhOwzYuSb4>OS(X!nWVc=yk{LODlxMlmU;{X>p6pKI;ir z#o|ZtFkj07H39K*dofIlxbtCjIL1B9>HDBa_jR(m^VpF3NCC>LH??t5Xi<*?bMbbF zQVLB8KBr^TxF%Kpq{8}L7NgMhJ11aBpfGbUd31O<=@U%w3z&vJES`#{cTmlb4m+KHB z<>n40<9^mw8R%)#wNZ7J&zppK{Pz5cn$(|I@OYa}u`G%Ajm)&b$I-U2;Y8~xAXDF3#p@Z$^ z>?yiM_wp-ydQe0W`ju;ySjw_O@Qx(e_XIX~rYVD?Q(b+Y;VUyjy&Gh-O15 zvb_D0J%8NKS+YNL)gEQr9D1r7F+*pzU_; znF#vAATaap8XC;67uB@XJ}2j(B1c$AE{HG1(Mt)zg7IEnl)Mr&dOS=f&F`|_+KLT% zN;u`tJf0~3wmbnqde$ZiR9X@lA%=e(k3|;MC6+e`_rf|YtS+>OgboavwGd6|dIqmL zpCh2eqZot_04_@h)du|$zIaa1gOQf8P~&~+Uh946&ovI0Ym>Am&X!Tb)@~aHM_LN@-@h*5AaM&a}S`i>^<{ogV90dam zUMvGvK*Y${J^L64o3S|S zVm7qd;yhd#sgy6Wn^*?@y@5#>v4C<#N;x}WUnfxPt(pb-?xxPpSbFC4Gv+x6_-yV< z@}kyy)5xy&9dcH(0HHwPW6?9@g4Vb6GCF*wJfLVvg~mT@5!9B(9}_^nxwViYs0_q7A7%+rIc5{H`r8b1=wO{GO64I@^M83KnpDJfdx? z>}d{;H8fifAj)D>dbrhoITS!8%Qt!*&P%ochbZ)7R(sw3rTS7+<}RdX#Irw~5FSvb z4=-TO*i>q@q`ln}v+(QXjM^%=h17$ufjn3I&FfiS!%<*0SMbS>3;I#)OU=svX;)b+=qvbxA&!JFFjm<5>7*=;+@cL~O~KAmgnC%M4iUkoZmMk_oU3FSU(crHS8O#IdGgr)u1&T^J2-!@=- z_!8eJM{>!A`=~X@2k0Aeih(X!&s7;ZYa87(1?d!_q$94Gbg=%%u~5?}BK?a8)&jb- z1kdEZ;9wJf31bG$`+mMiQ`Cw~hd zkcBc)GVV*8!oJk`b(CQ{qCia%KN(8twDs}7hJgb|f5PgHy@p|wTBQI|Ju>Hx5!%5y z^16y%OIGXNzLM8k&A}VDejaGJbg870OG1Z^MD^uyBgL*aw|d#74Wz{~C}8cfr2N}?fgESAd6ZlRedTZZD3$CD0 zC%V+WzfoE>+^Q{nrTo>^2}~AKSM=JZ9!cgclsdovsjL%{_3CoI=m%Re8{}!;eY}zN#c3G=vXAhdE-bV?H0Iu*3^S9 zUXPdK(#-tCepr!K+!} z`(_YQyDazP1#kEAh5jWwup~CHdc24L7x#rKg?Z=gC>b8F_7j-8klmg2mQi4Y$6oG> zAdH3)Q46&`Gah1L6MnS1J!~LjH9f$12!Wi>nP1)sgh3VWrjpCO^Ev2EaJE!L`c0-_JTAUgr3Zr+V zF!2}-Xhvh3UTKuA}St*bF_{u1!sU~%tgX#JFRtcV zd|+(Ce7yiq;&I~)5!-&Sf=4O5Cr`YHJ;IljpKp&GWb7~Um+&6Y9Bye`V$^gA$avUv zLxBiTjHBdtdHn?w6uuD&$ap6EQRVg7=@;%5zBa8muY7JvT6$UEGIv@(0G9~>Tb(R_ zQ7->W!~Cv7K$n-5vise4(#TPzSWm7u~%H&8k6J zy>4uCh%$%L-J7)wi0N!E4%;Of=Hr_Mh3>=g+Rc0GIN&&?T0IXujj*|+-(1rjA!G98 zTTr9}2Oq$>K+4-Vc!VZHm5#w5;|Y|bBM`sO6WOMy<$}B(#6M_wJ&!saMaQadOebG+ ze(zCn4w*XpZQ0yRvxdrcKT)99&U=;sblkSxo{?L=013G1&GqnV$u1iA2uIz3_Nh0D zym*JvhDmkRqp!{S+;40id8}P|{N?O@?mLd08o)?Q{jydD+Cr?;8&p;^+nz_aGv-~>$JQkD%+&ahsjJ=!R9Fu~L56&%1 z@FK1Q?tFLa6==CWkglWF!Cr-KG?!MoEqy8)M3KW3>ozlF;!dJG8$X*hHKIms6*Iyk z^4e;MnmADG16HWgtr#YNm|`K9QdZrV-hhsBEP1g5Ol$CZR`zF@Q2NI8pD(B~qXUiC zpCTsiUjrKiOBKF1ma@w;FMy`Hg?Ak&A~tc?=v2J~0WNhssRN)1#l|V^hPG9Qo&r*X z-Z{=F(!&gVqa2`wOTF0waRxLC>b$9dPk&TQ_Vwe;hxjc*rpYM!*t>pnq(@bBIJdE- zU6U1~?k9=C@`yhA2iBQ=MRMY4)ImDG>dd?@d?Lu^h6Dkg_Y8kcN4Y;4^lJ&W11aXY ze2<#y$Hi5|w55HKU@HVcJH?Y4lj$`1Gl9B++&Rt<_f3Nh{Oo*$T@k7u#aXi$SFhW>C@ zd8(+NxB<5hzNLdYhr=xh2^mfe^xbI|fwm>PdSos=zy083jFE)fRfv2ub8%suKdqfm zPv@t27TiC8XYZ7VAutwD>0vU-2NO9mu>k4eX+|KbFCma5>`Yp|?C7d2O<5Iu11|n? zhw%Z)#66GX3RuHS2YR@}>zLaRC9t8R)3(R@*Fp^pfmMJWd|o*w+UTe_eGuZoK@&qj zO|6MCqeeYO8L~+A7G>!oIBL`9gWF=H*^`ZFpp>O`<8I)f1TFeeyyGb?eIdLu&vNYh z@M!3-+;b+U^4h_4p2Ro>M*T>{)>V-s!KI{LPV`xI`K5A|G8)pnb9b=+#ntn0k%h;8 zk+<@oWiOF9ftq^)5BEBquBO#~U3SU2eSkKo+6e}~cvPtnz$_?JRFo>aiz~>!$;t49 znGqiAwO&i6$^Z_9k9-1t1$5xa#odlk{fr^>!qKyp3iP_@Zx+Kfn5Kofe0xd+JscS% z;Iy~TUjb-Ibyob&vy>fjSQHuJm`6I1eXFd)1ZpJ00v*yN5k(4@OaddM`botC@_+(C zz2j7h_Zc&NRdS-bSY36P6&UUwc$;sae*r>i(8APpxHOn?*ZLd414PB^gF$L`8->@= zRdQsTu9`q})CI4LZCvX);Hd}mCzOqSfPdgCd#-(I%%VG?1_Mz0gCQRfe`o|;c*VGSV=>300q@O9^SLmgCXT1# zCA3cm>EjOW}9X}i5 zz~;fX`*4)^_0r#L1Kv;A3y4QEAn8cXm}{uf_)R%DoVl6816>X)37G#4q+bJnr(X!E zFxcZz)7tDk>*3RFs&#!~(@?D4=aoA102Jgupg*|xjL`~xpG9#V6@FM-xC1?+n~oRG z=*dAY{*HcBQxyfsb%*uhm1Xr-s(@9qIn2+C>pzyS4&*#9oUOBVXvgN4Tt%?grXc$P z@DnE3zSge4ZHsRTe8B<4Jlm{x|}$P(Xv%K?ryQ$J7P^ z2HWPY54HtB&q_+8i4O7af@pG{J|)m#wc=L=zJ?`CS|hZ2dr{<*%~xc_KrynOGKh@7 z&xgT2ax5qPnF;CVox{16_0D84_FIt(VAa<UC3 zp=rQSW7r?YS}0or?7y4n2eKoUXQfz@CPIsDYe9iir6hh z{LSH3lvX>#f|bVvt(bWZf(Y0pRY5=$7X%LN^)oLNT@^1X`^IV#16IstfdukE*oy#5 zn{^Mfl#U7<6cDE1tEmL6lwDdoda_O;*QBDFPJ)`{&jK-qcnHx9=Jn*mgmEv=LPJq>8`c)WLZJ-{f~+ z94N~<_{`Jes+8#-*enMvNDWH&{N43OJDv0w58;Ql)~dHZ#Zl_fC^ipjk`ujC6j zy(Cm9lzZX-MVoyN)|IgA-BefNABL?sy)K=sZ6`#LUMDa&EWkVX^hLwdx5h53N+wwN z1YglSUjS1BOT;-eo&K}X3OL|l-o6I)uD<2v@W4YyYVaI%)eh#3qYXG&f##$J5z_wU z6(9kG@j2|`Gtgu%nJ!+hoTMm_aWlh24Hg2KW;^VBq>4UXn7qYz z(0-yup#k#q`?)5H3C(o*ZATZps|$X30kqp?1zZ-p zx)g|f{s5(e1J2Tr)9;%}X1vK-l~kPLrf^_)rw?GD!eJbQ{q|7-Tsdz$tua8KKIZ9| z4=tBamccE}GK3x(>^5oEW!F%FlY)uXu5WW0e}y(=at?w}uF-Z1hJ>K71b*;-&^j)&P5EHG9yb%z~VG&(t&>m?KO z3?NIXVtIHgFd-dHvzj%VMtMLm&_bnDtBCy-xccbl$?YM6BdA8t zB9VmUQvZ1%Tm$PA=$>?O3%vL)z^w{9Ee1$RJ{p&RT^(0c89;`QP4$bq%;~v+`1qk$ z+srQF^ZW6c?7=nDTGRBU*H0T!oey!K_^UA^i!BgO*0|~89?LsY?L7HA?4UUX zAbKmiP7Z8ygy)RdANvd|NviD>T}AV?gDrTM45&wM0T7M48#p9_L1QuI#UyaWuQVT3 zAYrLdu#eCd;RY-NiZ|k90(-;Wl$d%v9Ia2L1%*XaN*K+TmR~QSApGJmiuq;5Z+Ty^ zY1r&zv1ZdCrXmvf4{m=Y4(!nYdpvK6ToT84LSDlt77ZV0dQ<-e&geM+m2z+$0RkoT z{VcN(yapw0>cM3Svjb7*zi08a9@rZYdC-_UUcnxW#QLo^Qhj%32Rj#;F;z|)iHchP z4hY->rJ_I!hWD7FqaS4Z> zj?jSg;3Eog8v#nI4NyPPnOE&#^Du}JLWp=cNCj2|$xnM);j zDfjj5>zUH!zKevhm4zI#g?j^m%q<)rp%tkFN|Ug()KZ}@qWFAA=GPcg9rr;h!iS$V zl5By>#GZHLEw`MjDhVzlgSCx<+CTVB94EXG*i)l_L@Q>N)*f?KK~eW zGz{*6k_NhP=K)xi1=7`*n#;i6P|so>#-tfN*8E=o_;1-W185SNPh+_FbL{xE`!X~K zwk3gYg2!#A;vS_qeQj^_Wg15Da`;q7Ibj|f`y#l4O|S&NU~q1OYwQ7K!Db~URtmd? zQ!qSWQL??)lCOIeP`Kf-8iY<(ut9tIQM?OpZE*R=LCxC`seHmOUrUYAudmyL6;ZIIQ zKqZ8cIoIfkof#l!21_i&YkG@10{%M&vn>3`s{8RbWQ?(BqTJ( z7nVQb!Bm#L(+~&1jewS8nKM7Fn}9YC0(+FnWPZoU2Rg*xPfPe9(JnAvEZ~q>=pwMY zd`>;4SoeIEMciUO17$@~ejM@l4)+F_coxB1pjH7BBfLw$iNP;s2%h2q%1Q_xD!1zT zMHoiSTZ-M?$y($mxDF;)-8HhaU?cg9@Z?X7Fa&5%5HuaM3SO`sRa`eAr7|9NeZW@! zf*Pom4@Do^C^M*Hx7sTFIz_-BLSR`&_)ETIA7efy$pHz-p5D%(1ZGhsSMp4I~Jx0WRXR!q~#f9L+{$cFuhps9bG9~%q z#E5oM`iod6Bq|O0UNLhTO8-<-OB5p4eI(i6=n;91N_(e;S$Wx?DL?CdOxtj zI%x~9AzZ3zr3;KVxZ&M_u?&O)AvJE#2&IeU&JT`5R)-aQ#jMRg*w^-LzKno4L)Ok@ z)oLgP;>fJ^e?%(|92@?r4}m@o#xYsNB)xH_%)kw^;?@TrN_ff|H@8*ol90nBn~UDa zJ^UWq5#jw1mn zn`(u=-{PeA-UJZ4L2YD&ED(ZXRBUNp{bfY0S{7C8;v#ehh4eU9=0WDSb0VbiFayc0 z)DZp2k!UXQB%79V8iQ)cm60?Le&b}~*6N#*18O*Z9w;+Ne}pM0(;U__T4A=wF^Byo z6+rXL;D-wmq4(qx?C$$qdWtD+1cd>wys1hh04yrxX?WcTUVpIWU5y*qPp)({5d1Oi zfu>%ERt4D2omcJPSJlwN_PFu4g%;DXXw%L^h&t-g!b6O`JZGPHW~mR~_%YVuyo>Nr zYSr_r5iDpH$bVmxI($@)IHG5?#2|D~QGL4t7O*g+$9aItkfBEqzT)3?JZM<$^@03= zjmNWG#J-prNs|0C(Twj4!b=r57O zBba0|Ci7-Y4km-)>qqpQ(>vSkfH72+RMHJV%oZH1v~4^7ks3aL!>>Ti@H-zJyO+Ar67p zEmwp>D(554xq)!@v|>@>R_Wcze!}y(!)^8ZE+O7$pFcGqfT9LYUEI^*Q#Wqm3g3^2 zCC@v&emvx3&*7q{w9VH~g8wmi$5L0K4Bp!OghGGg#e%Jhap8D{y*ZXl*JQ_`8CxM0 z(4)PPIOyL=Kn1nll{~pLV9@0nscv~m0QLcTnG1^3NT+n(Al=D+41AqW(fNIfPs(xC zz~}#&c(*vI{27zU$4>mSg8}{cM&PF3rJq8B4iNv|7x8Oe z4KI{q)K60RJ+J=Qd^}_X7SN$Yx_pixoBzQ!41afz-eQffY-mK?wti5A!*BgOS#K@Y zXnMa2&*#!w`z4$DZM)1mDz!ZF;Gqbn$3EUW%ICet;SXXs%m=VW0I$v;_|oAOe6pqF zTU3&(0?3tzR<*|vzerFU_=GPMdlVmDClx1I~nl0Q4;!^B3C~V z?%_eQE4{?uLUp`SEm85Ko;md?s_n&wU*9wJ8xt|{FlGNWHXUgMMkCw-{wy_(*>@YfU^OgPd4!=3;Zv2 z-m?PR=iP$dXWVe6a9;0wM@#vkG!+)x^@9ur-kU`aG60IyJ5b+&`#8JDM`qrqW#F#~ z2tIH$+AYai-l1VVw4y3PbzAAtwQ!HQ?ym-55wMWc3$tX0il zckosob5=1*_YA*;#je=JO?u=#qx45>ZplQFHf_tpHl%wo8O3V03{R4 zaIyie1;6ljPMsi}#QZho&^Y)#qS-gkCx$!Z*zX|GBX1@i#Kj9@zm$(eGV|)dGn^ET z?W1;$c|PQ@l6Dq2oyQz|cF~(syt8=JWOLbz5H^)H7TH{9;wpcu?c(ek~}B zMUHqY>PV5Rz@7&v4!DQa?7R(3(G_TQZQnaqz|8_RkJEAGRH|NoECar&xC(*`lq+UX zB*0il_1sYFiYtkQ{0OO%gpdAmI?h2z8EH$`bWjmOA>xC;5#2sI;$D%UhQk9)yj1$~ znLjFMQr(fC((YxJ{Z;Olegwf`c|%$h$vw>0OsmU}$6%o{F((vLY$e7+y2!$q*~N^u ze_|2zDU%8j3I~_+yck)wx+j1PYtATO3s!aTOD;s@|xQ(2`N0(8tF-Hda9&c64TC`-o7cAsJh1dOKwASkw>H=G*r8If@Nd&wL>#qY#d z8k&B@NjF@01~>WM6d7u9EsY(Jo^nxhA_y*`D zRQR2f-`AHtjr=adj_~_RKOWNd3by-8vG$8>?7P}2?StpSBV`Sx%!Fh=dFUM{&wn`M zluRg)+IN(T_H6s%?2Y=6;{C6-xeBH~{NF!I6maioc$6&-_L~bB_#H5IF0L&gWMbZ4ZE=8gB)U>)!~j4_w^!gbw6qSD&##K z3ee@L&^d~P-xIoGks>saZQhrKCRum6%+Hza12N7vJoI<;Tm!22eOdz}F!z;z{%PU? z*9d-xlWPw9nwjRfFUP>#Z=>w{j0eM>LJ!S`rUGd$cmPs~#~6!I{?bb^ywf)i1hKds z6n^}9{sKkr&1oFlDECW<@sJM=~5iO7a?g| z!asKN{Y`TJ1VC_=Eydih8G-Bh););qa+RRFFEku7=~qH}6BY2z4`&udK9N)ai{s_d zT=kZSmLEVSBI)cF^2xA+q z2G~-waylqP?m9eev<&>4F`rnLm2IsVq&8{6qU7O^xN%W$r7(&^%Pj0#fs-oU=lMN< zQm@og$UnS%F={AG-)q}f5|PXS?$T3Q?#uI_^t^*oGW#iPbtz|kiir{)hXKT6F(p6? zD7WX&v#=qvgfR#=8025->&|MSX;Q{#_k{*o&*HY+^Q&PU~f^W#8cC+RAd+W*Aeg=%r zy2ed=!LsKq;%Dc1U+}VQfn<)$>OmHLLEB~rmOoYjJ2;V(c2+yQ6L4{4;Xo35(hNoA zUgW5lHU3E}!RG3IhClYzSe}l8Lt`3+Ww_JGXPaed@ZdC4BCsueY=FV;U!Z@Pt&e+h zU#Em(S!XC(34H3h6q0t~@6oPu<+AX5yubJrcf!b8a9y8mz!GZAswScmQFfonDZ#lyLSQ?z{s}=686h-?){LujMO>@=8Or z!ii}&>n(;C{PL-A=HR&y+}vaEKFKvodKrVi@&&KAiqysSvHnKPp-xglMS)IX&Ei8K z(eoct)BN2cjVZ#;{4QnGMt41WlNq9{ycRz%qOPsJJjej>Xi-4uS?-1^0^Ih(;7HYs zVVkd}fdSaC6v}HH0}y{5J>e5zjp}shVDjf1nIjC=Et>B2WODpjr=*wZUhUp3<$D+^YoLhc4+i+ibpP#DuT=XiS|f>Yk=@6dprA^kpf=?A6)9E)Y9G zzETPA>wTw+NKq{*^y6ogDK%U&N$ObNcR}0>&UD1ajbZoFD+rF}ph5eCN-38>kK(w$ z*-pN=SEeRmkn(5)cY|{*8@6M2FaQAsK+nK01zETiXNR1*w|xIn>IG{z4w=2d3XOYC z)`2TwEs+HvDq~1HG)gA~KLzyQm_ec5hNaGQvFu(s&ghA!VxIwd_&!t1eaqh{zZYAd zeTn;0&P5?H00$PR8dOw4Qeh5F-4$SFwcAjnAfB0`bNG(N`W`50Qg+TmwRn|IV{sXg&0CBg_la0y~NM?Wy&n^q53ggP~fg=cGo|~ z^B8Yj=)FV=Ve*LfgpKt(V=I3{z26tr(p+@rKUZ1B{_D!7W-lU6a4~oXgB%%UR01?k z2MTSK2ZgVOduJg}coxr#qLS?=dfy}XkwK}I=#rFu3Qar#x=#9_lWRaJ^9eJJC*p=q zC?w*ear+q|@&4Ug;~#yGcsB4rp9SU}pMM(2j_6l7X#K0YH1p}#3+z^; z+50p|0?g&mAHNAZ?#gJwL7*Ml^IQVG-%X&zCukJV{n}@w=0geO@=SPz;nN>$GgRyO zB_Fqtv4n>=XGLle=i^+<06S}V*?KPNQs^L>VZXmUJ0AQ|G&#X)nTaJA8?7Hkr!VVC zEA&NVP{zfmY<3w(;I{hZ9^4@Sj2(`8e?P?!l{McExB;+aat{%RD0d&Q1Hp;{sn;__$8HH*T(WVur#Dht*xc$06SxAJ>c9pR(B$o+N0s{uFd%39vlokn3M!s=Z`3_yfy7U+Oj ztDIaz0%DS~9;U~=m(5IL*V=FGGSG?zWXBbU5dj=w!4oz84&41qFJ$^Sz55RhDw_4*3+qG-I3;XERBkU~`Q8AB~4a_)v(gENG+&k#D&-*^}d=KDa8?sA!=zt;+n!X0ugX+LPk4pAV z!0fVLK(na#odV|d1o{;^q!Mmb{cWWuZ)dTd2Z2I%si-> zhWg<%S!n*n;&fFlZbHPW7U_GjtU1-F`g3s^dc2}z^Xu8x;Lt!u$NkmQKTNKxDU&nz z^n+Rj(9I}2vyo$?1?2O1gF2)i&m^;6?`}r`Dnr25$|vj{Ck%V#t&@( zQKmzlWALOujlhkB56|6k{md@bDVq1Xs_6Ayo?+Svq9Lc2L<>;EHB-u;AUP>^07%Xt z4$eIa8GS7cW0a1KK5|d&4?bJ32~}AJtJB@tKmtt8tjA_a zXLOi44&^tO&Ju1o?+`Q`_7qoAlOI;5I0)Lh6(BroJ|lM{8!~%4XpMvIvn4%a@Sx@ZRlA@873 zsAiZzRrHT05*r|OTwGUS-HQ*S;=%Pv0?LvNh=mXOx8iu@uR%EgyPPOPb*)*tE}k6; zaGsAVxbgAH_^)6o8r5mA239a1Bz`sLd}ebGKyR+@FX3_D!vxZ131nw}R#nyjS%b&y zX;Y-nvTqGAkP{S?WtNIe?v!{5n8Gge(UGV1k==rF;xN-6Nj#+8%SK=;rAjuwKkvyQ zVN3n^NEJs2l5x4!p>m#*`Pf3rgPNM3`T{K{6p{)u1$Eh#(s$6PXOB^S|Du6{s-7A* z78Fa_nV>xK)!a!sD6Bzoaz)TC9PbF>)~is{`x6v00FnxMVLV|4+tTfi>mzC(owQdi zNDX&H?WC_>ATyAlTQ{4q1DX;ogf6F_f75!>{Y3!XRN6q!-+tqyB(~gZ`}*FSDzqaE zX0NO%6edVN`vTwH8QeTVTNE)CG+2cn+Y-26SF@Iss{Sy69}GKgX&aB@@+6*%z@p((>cp1O zDBSq)4?p8Qr6fy1QL30`MUeA4X-ejTxu|CJJ*PDc( z!IP+_gR&yZ%hi7GcdrAg8u0(j?^{_jeHxhEH@cP=bJh2ORB{4Ki_lH7$GW&L4(?-q z@8RPy_W=E5SC<~K$cq|bxqBkq_{K`{?|&!Xq;;CcqsJboTbLUn0uc_L`81Drn62 zJF>iqg^FlynTEXpbKUB2!i0GVDMn_OSr#Vz3j7MIB`8=rr5QB~Zo|UXcM)S9K_)>s zYC7R&U*&{(?c#wZv0TR!YIE5Q6+X+eugoN%ezoa5QZ>gb3wv<27i z9nJ94LfO2+x3>tYlI@+demm=VK^#6Mnt7lgi42cf6iN6%5(np<8r9DT!1~{?)R*G@zF6T) zc{uaM2Xo8g+`-ti`l;%x7fJR&hLvBfyS6mJ>1_L{yFxNNa-a|M3x5<>KZ%;xm>`0hqHUoz{P3un~6G9L-6QU$%YrCd92=3p!ehs$|ufr zNB}<3KlOV)_+a+)?KUkjT7le~~hQ-GWg?u-11Y%o{GkMA=D_I#T6z|-HK@C}l{ z0HpmWKt`m~d4PxKMWcEYv;rM$%6ma(w*xTkAhI$ait`aDQ+$f}49bnn$JnuMJ-g^$ zXngS#1#`L>@ytWHqDGL;ecp>Yoi$%J+s!8_2%XF3R@kOITJw$-s^)TI{DmssQL17)ZP~X zFkC$}Fp)sI$8Nozm8ys*P+IP^lL8s=ZSx#dDqOttS%bhHcj=_}uLnSpPDVxqQESdt zS4zJhLb)9+h33~2cmOlNPqMt2<`+`F*VFk?XP-I zGoAUd5I)uz39P+86vc6DQYOM*b! zln@6ca{O|2>;+2Hrv9ME)S~STV5<+0I8+z8%gTXs?1x=*n zR3Z1URSqaKD)bNdo($Y2a*5bIyk|#iqKK+p;#l;sSy8SJ((mWDPIeC_`7*Ua()*_} z1suD>tKoGCut^nwWj(Az#kPDhl=n_G@3MMaw6MOqv*FD*R7E7f^iMOp8|wmcKJW#T zdr*KhieQ6>M*gQA3oF|*^!K*JvP6wGMCFy}B(rF$FzrSm)j{#Dr-I6~}f-M{A z*INV72!SK{y3=J4xBgxy_$nHPk_Y};zUff3=!;(itRUTM8vFn zJ}SU~L_e1uw5T+SGVF~9(JtV$%}eK@lo}5<2ss+XRH|oeA!CbThZw-x=0U~X3z;(P zE}jbSXcJ>9<)=GhaR!j0oPkCVUEX!P+w3n~PM}YKlw#}rF22)=Fsiwn6k{EETahS6 zf6Y|DR(2^pl#tH+`XmhiZBUjJV~IH6C{W484-L4+cUCn>CT*ZT*akdnnv@|%dw>^M zEO4fR)`623O}~IL6$hpj3S&<{Vk#lE(a8EaJ%SA{8B667X!9aJcT!^wn_f}Wy%q91 zgR+-I?zHOJCl%g9413G&9p{6r=-iqKg9Cf0n_7@}7@o_r1|g}^F|O^S5U3f;q33dM zP%m!+fMO=77sn1;Rfh6c>bRQ%Kj z#j-wQH-Zo&RUyxyh@wXGUWssw`f~5Z{fo;h7ZD%PSU4{uZCsj;?0gmJ^t^4dz(%LS z`h0bM24&d}~>CK%E#m`1*^JHCSR1A2me7(uu6)HKdx*eY=f13DWL zaI*p59$086PLA~_6mCB$7x^IEQGB{Mu>4x88?uB&K#BpnP&E7S1LWzyn4o zpj30d`s1{Kvb*_{r~2i1FBXGLEg&pk`}0<{{+%L3~9Q_%*Ah;d*yL7;v){c2?QI4NsAIM|D)nhE7zr#e>-ltTQixdIo#tf!9-*J9J=T|9yvv3I-qGyRDugBpR`201UP9N8uJE6=wsxU|MuZ@|qTl`ud|JhD z1l0e^dyhC2KNJjK;5U-zj^*k=Hzmc-ip=jw`y8eD^3i*)3?E(i8f7Y8naj19F0rm7 z7)3IR>iU|4wk@lD>ySv74YWc|@mqKh1n&XfiIy{|MU{cBTgK}cfYneaW`2_pu|%cy zMriA2o4kENG`gVcJUO~ZoN2H5MxP~sR&rsDws0#>@s_%_+MSvkWw}=)zZH%(2#{~! z@0FmEYW{t;C9E?8!R$BF={*#8m8|Rcfe|1 zAM8hMl&%=#Pt6bw&n>AQ-iQ9e9trIVzio3Yx-$d1t2zUiim3%OUW~aTkNbq9lA`1T zFfQ_`DH>jZoH%@vVYe*jSfSdLSBJl1$`977-^6kY0!qN3TzpX$;k&kd?ckb;%K}T@EdVYy#?TPM#|={ z&Ra4;n9J2~l}R4i=M@|V>qd%ULXh4!J>uI@8B_p=0zSm_(kZvEBUXR$J%;#BEP&Ym z>M)(?!JW_UfX)g_(TasoaQYMTOAZM&8;i5CM?j>1^9WS7*&d{^!Tah2CGI=@1x4AG zOSsq?5=1-QbAGT{VlwyG^hX}t^aEPBX|w?7UPyb-sPh5;$vj!|;BwL|n-H29;gsD|jD+oxYfLFYm&r3IwR&+zYjrsY9%7pbs6w zhQj!*Z}8#kzkL)xlA+N}0ybM)%WL>YldSB6wlQg`Fag zh;ve|*#LN1InwwhGoqnhFi z0zMWWJoA%==5Vh`zX<#v z2r?e>3<@a<__Oh_@8>u7l&hz3;p-ue7;+-$tT7Dl@hUi_P65iuC2EIDI;iD;l|8S z5;De363?(_4s(rlv zkwO=<`iWJ{cwc&%k17Ot@yztcxARg@&|iDArphFrr#%b{Mm@8Rc@4@5>-rgVn4fzCy#OgP{vf2nbYqMjT4GbuW zthg@YPeTCp{&nVTSG!*gKU@cASVyj(n8O5gW^8+rm3IBb?qDsFWtalIA08e)CJ6YhHy@;lP zGA=wgbqEDbufT|$2pkIhB!zJd6}ORiW}m`J1?80eYyGHV4Fvf;zO-Wv)@tG381;ZfXg;qZi&|Y^Fl(Ro~f-V#!pG^ zAMontP~$nhvQ?d4bQ`g56UwVLqA#Uj&kSH3_SX$ms9P}GJc6LQG-D4blh3R7iQhT< z)M^c{Tl`VlG;n^i2lQAi%2(X!H7wdp`P)3fM#B5qjkGnXfLh@JaF+<&MQrHuf8T~j zI0>-EWU#Q!s^H$v1q^8lF{!@70x76Yy%#a9)W5;E2Z2n>l@7O7vhAgVNIVXsS@PIk zj|{WieJeq_cP{HO4xZGXtc(*kd-71tf$}a0U47CO=d+_Mh*R7Ur5_~Nn*bEFb1_8W z0DI1eXQCwj&^pk93th2ze}!DcI_JK}L5jvEh#8WJW!1Xxrc;KTZ`ta^*3QXUAuQm)~QfYr=qUz_{}GJn6*%;;a#7yr{C;Zu| zZdqBWp^)I+{t&N?)`-DaZ%z>SB25;ZF)0{`Z==abB3+1)_;`2_Bup%I?5E(QLlAca zmnB+(W6Ct+-O3?w$@~!_58`ES;v$NE0FH9>;E;B*+~*X4M6G#Q(1EzX0N5kK$py;g zL(DyjdM>sE{?1@}sR58E1c|`ce!c}@%fj_3cs4=jPA$JH1r*>joy|~uj#yjJ8`2N= z#4Wq$Y0V(jv`%aE)gU=s^%0(s7WCQGXmq{TSpk^Q1eUvPLz!<91vF1H#tF`QK=^td z%7aZV>V(Os~%Xp1Cj<$V(t|(!Ja@BEQlQFi)#)XiEd(n8!;q z*XpfEI?jWG^60*Y`6`?C1F9ZE@q!)nDlz9v3q1kk1pln_(4Es~2z|su@+Y8zB=xr@ z%{76&Dz8opS8G^yXm>jn;XuQk=PPfyWq?Am$~zknHZ<@h;X2htRuG^g4dSbbbZM2D z;O+{DjE2P;xipEF3!L!yS&*Bkd!Q;b3eC@dRMrIT8mL>NYY0ZEGasdL0sd$pAa1@f zV>Uo0KV=4#{kuuF1@_i(Uhr|~!|k=#lUU*R63G5mz=2+^>-BOO%K&tAD$q8*+>HU_ zo8GmIh9aVj!@5oyhwE3*(a@r*eCWKR8(*l$5M9Y&gzI>HOkV0>cNYl>q;LzMi4EA3|hrXQvP3Ylz@UpOMXe<;nI={5fF_^RCBlCI0Kpuv?)`b*Z>c}Hy1fB5mlEql zA9w|}4aY@jw+_66UeF+cubIBE=rQrt_N;2yV1Zx-OUb}CxXL93H|ijSN>|0ee#M%SD*t1Rt2Zq;H(4ET3!aE??eBU?-S%h(v)}S0cd*3 zF}ptyT{ypuqz)j}3Q|e7G_=zqmIUSb~gLpdYXa#$!1PTx}a>2xT61K;St^!bm_h2*T0Lt{W zqAi>oIQ{c15fSl)RY!xIc^rg`481d%|{fP(Uc)Bw%} z3Y`qx+C5l{U$-4+4^QxrK0w8aFCE;?0nJ0Pq4T%nOW%+a*Nbn9Nor1m4fc~u54FunBV77Nvw|;O)Xk6YlKP&VLg4@TH3d41fmA!I}Pt+~t6yUsBgt&e_;RKsP0z zQZv@oRMb1L$Kj3NbZn0VjO19M3>Tm?hKvD4bDuYI4faLA3aZ@;_L0{oZn_n-uARTP z*4ggphz1FSex~f)iGMO>_bBz-l_rwTq?qgj6fDj9VnD7HfoO>>{Hncl(5T{?l4X7h zYWgjy83Nl0_YlsQDBlI_+WpYHGNDc~?MDqGj4}>G0HUl1?=h`NX zDF9aZT^AlAu+Tdb$qUO_l6EVNXDv?O!8fo3g1L#sKboE2ujCsiUI5v^&x7FFQg1DK z*i+&^i;6x~xdO>s#7r|>k*x{yqitR!c6_}C8C=Jv6VBImdUBab@LE*Z^aV=4obxbxH`LHD+`*6W zMl^^FxU#YKt>wW3efZr{&d;X6?$Ezo4a+&4nYU#yCK-GLR7Aq>FE|{a1Q$hu#`4U}%@^#ByzE69X8SZi^rsk0QJ`RBQ)-tY$k7GCN;CIC~r^ro?Zafas&AG#pJd! zLe(^0u9|KTj=3vt^P>YA35GHX`LZ9Y+QDObzV>~zO|-ql75!TNWVpP^FeeN2)5xgM z+-FB|V+w`3}d|Fo*EO@(srRK>kWW@3>*uluJAYakMts zFmS^aQq%0-|}y_yj{K>(IwSpcFAM+?GJGr)D1#61ng@e=|X?=F1>{XIoJ zSyFrEe)|<9rhxh|Z?pJMk4QD?pm}w{Ba$W8^D_YG-rYG;WSIg*L5TcP3-V;R9NfWR z)(#iSj#Xp~=woQ`Usry&bpKX!{Me19Jl$3SLFIvj=Bo#Pzp;M+znv@gY9$yIn`S3A!ACS77y@8FG@^(!DJXs>3C4!b7 z*yuHJ;6qcEk8&;S-b?(eO6dXmkbR>_cU|#`6tGCL>Kni5UWC&Gn1`bHha(nO&X43GMHFbVqQUx{c>(M>NRi+_kS=e$f&#P(=*T)A|155IM3Ln9b zMKRadP*5&m@bjVoL$@4v+1i}sntH$D+;;Cp0)EUi7#26vqr9iZc5L(%xE}DzVn)iu znwjfPXNr3&fba+H0u5UToli!g7ml^~uhsv|+rH402nWmjTMNE3_gGNBYX^YVf;SQz z;Op=TMk_|fF|R4VOgwR}tkUWyTA~(W;LR}b?^uin_^dz5tf<-3{LZF0gZ304BOe8V zPcu~+yniohK&|zmXt#+t@rFP5vwo&^$^)ep@=oclsAPhF4VpBz0E<3w@{5x2VCh!f z*QvC{uNct+hj`3`qB4Nwq)zj@rD0AE>tD%hTKc4^Ujs-Qa(fImA{9}5TX$z#tUt?x zMZ)ZuK}0;kpXyvBEyg37Yy`w3443DOx)e)2|E%W0D{WjO2{d?amk~8?WbXjRKWQj*K1~{wL*P#` z7^u&7q+pvC3G?)RPsKa>A@Wyq_&k#i1>7p)7uZ|88970%+F zv>vn`fHAPhlMAKzQxSt3QBN44kT|_i^~*qWn*~+=^%p&hhb5+ip1Dsbi)C3By+t#} zjR%AIE0jWt5`z?;*DtLAMY|U%8HoT3A@7(Q`XSkE_J0_VC4Z#ErU~py_)7=WEkOcb z8d>)42aT)#M|~+FpeyHtet9d*X-N~okr%EQv~0+(OTnwb{wNpoG*Dvn12MP5U!%#! z#lp5`pKNI)8yqYr*GHJd_Yhdim?TnDP|~+tqHc(*pJN=4w-(5n+rdcUSDPf~Yv|y* z!2FaNv#h?v`Ir`S_}qos*V@1u#CN68H`ezw!MSZM0x;`fOQ`nWo&82AK7(12L!$a2 z(!ULYEaUDRE zB*kmle8&#H_;%+Mbo-ZYpDEfe2=K3LXRmXm0WD2yUeMKK0YI4$eeNgAQ>8(Swx7%Q zv`}N}86{rD)B5X9xqSA+ltLWRm^$F78JY~o`Stom1e(;Bisy%0P$HrXf`SDK1A@Hy z5B)|c(Rx7Y>@&vnLnidnU+@TQ6iAq^1z2sU;en>?>yow4T1k=tILx(%X@LffW|X9%dY{w$`LU3KkPM1{LjmZg#je>6Nq%Mr~nw| z-m-XB4^P7CH?n<5E2&qlLlkTO8oOIKPR~T3z<3f> zVj2FXDpk|0;GwAg6!z@ovB3?3F;<83KOeohHf&18loQRyRix)Okm5oDu>xc+JT2GE z34LA4nqsKnQ*n~G3_Ab{0yfx>1-cu~fM$l&e|ZBCuC#1?Ve7bh_VUUhRfjqt7@2-G zNv;?`j&JRrfw}6&&A3iJ`tWyXTg*SCwqX#EUT!!DhkM(s!C^m?P|DlwV(s3Bg%%Vl ztoT*bAcbbPpb=1QG8<&E$1_U195lEVL=wDB=gk`_C2`%oPvC?v|J*L<9>uZ4#DR04NLwL-@B+J!?Y%JjsvhK~&|b75$Jrc4 zQ_8)eJoY}fXi-Dc;3g?8cB!nEZ!}xn3iiVtTRFUk3Ke4WAT$)`M4(XnplXAuf4iU+ ziU$?~E{a)0=!}AOW3H9T2Yrd=3Ge{;G8hbopH&~8NXDZwdEOd~pwLjtnE447nC9>&;PpI$-rwg8$~AskaJm0w z`@*GpP-Q&sMSbd`YQ;cg_NAv0_PXIUs+71EDImWit881Hkg&a1t};GR#su>JujD#I z-8lLF{xjHxU5Q~ETR3xrC;?J3;lbn)4h`DH7W#qZzeBs#i9C>2bzw5{Jf!AI;{I(T zen8!B3kL&C!T}`i=Rj+7O76px9{70V zWDkNp_y`%N$bsVSDEC1Ey=M3z>0hP41OJWMIWMCSv{#+6J-m zR8!~tOV>FnS_WuxCO-FghM1fdgpv+&>)aUC!1qv_np=@ep|};?n)}? zL3vQ98^Kn?P4;(^#xMQF5Gu&>muV4F2q15a0lZK_^tzwWU5u}7DXp5!5x;$`m@*?oA0s)!ItcAztG#|bIDRc8fVUN@G!g_yGe*8Tog*-7l*LTmas4Q3aOk-T^fIQ1`dKWeRArvG3a3rg0J;mrJ=wR z7YLn&mvQbpVCttD}yo4-d0QpDBKhqJw(O6}cjnud- z?$`k;K$7t>K_DKEr{&;b?;|GO=kezUiW;%~A&9U4Ok(#Fx|?_kCX^JXQIE8_^`*Bi zo&kQOXJzPLV9v+3tp1Srp->-a=UZgd>c6$2P*c}3L?O%h{4Jq65-C($GwV#4@tvOY zeV1kEKaCSt9bZoNLONWU-Q`7g5<# z1T?&X$25XcZwzwTcOnKq)s4P(a|Zky&XXIS4$e5!8~cG>T8zAvPGtc>dQrKNz1)k4Qb5zldY*bI9M2UQah;j;9pXvgp1s=aE?%ZN!V z;LYcw_4zrEN_TNALAIG}8LKbgkNfTbn=hHmOO%Dk$UI41Y5sJ6yqfV%m)+bc53SyL z6ioB%b6;2`f#8a_^=y6(n>|vHo|0sKATEzuQn!n-VS1S3zNaTh^>XRxOGKZ&ZyPQ6 zUF&i|0GOqZ2Tn(Qg>f=jP2;}D#OK@HAq9$AM7WCr`3;Uld%|VRTR?6wo!z)2$dTFw z!2#D@^$D_R@yPM9+1G6TF;x6kn0?*;cBl?ky;L zb8F^}Ub`X_{5T{NlB^~mO0BLTdl>JEr}T5TRjd7yN5jpX?xLo*?ip+wiv2-pKZ! zaO@^tgFi~XAwcC2&!bM0e+Mb3buRI+4MO6 zP`>O(IP*gi2oY9zJ;;Il<^FiQdBtouS$o;L$5W{_!KebydA8q5rjg<&`!dwbAK;rtemu;yqF zS%O@{@L$>yB+?p(3S5k*{Q`qnCS=O_IDdp83LRlU(9iKIiJ7cR&(;9@uWG(z2vqSx z2=(Ao+J0V8trL#*?{zN94bJEEXklt##uj_8IcfYY$?eW)bQp~EUvv2>$s~o6Q0CT~ z7*4cNU48~09oM_pw~Zrl=u35=VuYD%w;A_eUZF970{PnzziD_-N9k@&`eN5)asg%I zvGm3MSxy&EdXd8#I#g9uA&20j{rwiyQ{1@h>+x6luOIF*K1~{+(Afbl3pW@y(@1XU zZ);*f=`*?xpZ5OF)+S8jV~ILT&fj-r4cWJA@<2L+v(T1vi0UJ*JF$KbAaKHM+^ZE( z`<8l=5OL$-et#FH!09I+9vQfGr`10U22K2UjI9I$XVhESMB5_1t7I2e)TYz~5z0@! z;ZPSu{gHl)(H%a|7Zd$LIc?tK(Ud5So|=Qvi{6*>m`0;l9b#T7x#!33Mx8Dk~@VJov zw@+W=#R4|&1M2T2B8m+Ya8#{St~{oR22~9hm6z8_Q3w+^-yF=nCXH#tH#PJ3J6ix8 zWaq8XTm2N6VD-X)o7)8swcNw=FYUb`o9j=n&-PvAG>*W`?H=CYeL%t}4YxPRe6aKg z&2ZV+G+TTwz9aH=zaV#FJ>=7)Jt$k55)pso$Ar#=9@`-Ld+4%J|EUs4H-zBo~8J zM6mq+rX)F?s)0nlJpRR+uTrnA_28Ueht3!rGTn~>-PS*?A@)T*Z7q{;fmS0dT46>f zfnzY`v@?zAmg%wQYD$7dLY*e#scVbu_Q&8$To4{E1#5i%wI6Ears%nBxkfvk}Z+@n{u!C zAa^Y0gv>Zp_z;4kHjbu4);y&Z2i{9O-_4G6AjgM_!&>S*GWG(hVy#;?U3F4kE{~-)TJoU$kH_ zi|d12)~|0aL6rkHsA&z~8?Aq5`bWQEDT>5xUSU|&t_qSfX#yBaqUE3SxKWkvjLsZ% zqJkN+YNt1qdsgiV3QmH+HT#$ySn$R^-~bp+O*g??d7eIEa8DBExTJ`W^at|;P;mXJ zj!18fuG6)Y;{EtvC#ySsNUx_LuP?0jhTW5Fv~-yS_yXo)MrmdG`=+y=>B6;RBq4i% zad-=7`7X4KWBV)v44jIUh2H$vl|vm>IK0r>q9@@5 z^*qFhQ*a!fGbWSgkKpEfEAeeHi@#U>^IpdX|3%FpceR*SkJk^D74z1UuTY9a?B3iv zb)FwDTg*(@0vQO@KEa!nNR8!E@Fbh%vcDF7-(?zWxQD#RF+YB@+H|VmxOvq8zIAgB zkNshO*1fhd?fb0;B5B$>bt3grb_dXD80k3V3b6OX2+j$zoVEI33mp?+BOoK20uFmE zj4tg(IRnWMe%iex9v>io9eji*!_u$VBf?EBC^#gH_3I|Zj69thsa1OE^@;q~*Ed9l z1xxCAkWi$_xP$F2VH)>~$j;gjz`1j9S>nZ=cm(uP+om&TFuQO&B|LW5mK19a`!nK~ z7$?G%Z-lLT_e;n`)4}*etTUU9d7>C^y!i(;;$vzvXLu|NB+g!>B-|_Up}A4YD_3+s z>UiL01z-e^x`YBoK0-TyTihBQ-MgDHBRV#Gn1Cio`{nWSmx=f?CwjZbFx=fSnAG35 zoIWr==fN9$wV{@m%T=S8(>O#7dqZ{Z;!rjsd zIZlXKjNJW%lc*zoC_c)7uQyPtO=@nwh8~*yPs5HzR0Mst`t#$}Ga=}3;>8 zW%!yq9B<)HqY&sL6n6ZqTb7w{YG{bpM)}zd^Tak-vMgfV!x){@`2joJCX79mj(P9=(wViFEcMB6)-_ z;Kj}mog#n_Ar6Y-J|<6siF|1vDH{B2O&I(~El)B7CQtAL?~uL?*tIhEssfnxbQ2W3 z2ZRyuG8KPFGBG3QlL*~^mLK(|8jF0jDCPnuJJh4>W8b~~rPo-5yJEO-J1;x0=3w4X z>>+#Y;vwP|)waS)iMi*A0h#FzDJdNcG~zFX!R{qhh=)vM?NPwol=3)jpKI65w-{3_ zTegc=Te;D{YfUOa?eatVYX<3FHD#qt}u3g#8 z1?>rIjs5-{&qiRLIW{#O#lBVk46h*?j*w^JW* zw%+2yW?mAFjPLhm?%s#FvW|F2X}%KW-pg4@Ppx?oMpHzPHEc(Vov=z#V^p zqI%!Us*hUA&Bo^~&BW&qcWa(nQBn_=drzbYB3-t3J>4n)-aU}nbTr7hbNn`}!|RZC zQtnMrNg#E=V4bIrEAfIk%o^e}l(~mrRUQeYQ~q_&z%+D% z<+CELYNT7>h`Z0((Kj1!gm!W55RBJoybw~kfTRZ^911lb+0uJEtP67mrF%lW zaIMNT@wf>yM+Tki`rfjTSJPU0-LDfhf7Ck*tEcl!ihy8M=5Vq#uO zINIwUZJ}|C0CK36u84TsAf9Qy{;?pamNHD&Anb$;2J<--FJ$PkL2Np^)>=q!9jC*I zbs3fFZ6Q|oTL}BcWduq2fnn=|^*X{K$g*K+d|T+>*DmM>v^`sCkiB>6saKQfk-)A( zk;I%>^tOM;X^z7tcv9&sAAg_g7p{TR@QYh+L5Jvx7S9}iI24e^Qy2)VBT#&N*sL)z zLpgYQ5k2>*Yg-y?r55CuxJtl#K?qWWXFO+F=m>}Mr{t2&wf-vRASxC;(82a;_huAp*?l-=egT>|K{kHh~qs*Y!VEfO#n9pk%ZPf_pw zEdH2Y)sIzmpvPQ7wE9@q6j%n!`QVcJ#4we4M1Cw7R5a(~ZWi_fG$fS5%%c%PV!N>> zJ`PbWdqT()M*ew`I8Bl5eu@HUbDJ2|QJ zN4&O!h2H=EzDSo*{N4obZoHSbZDy1oKe0Vrx^gthc%EP*EW@jI*lZRq=eRz#Z6wdD zbP2y|6lA6jz{Tf*XMoJ4AHf|IE}`~*Qr0V%5WI@(5%~{{q$CBgyoaLVe^uU)>kq$i z7s!YXZ4>}o1BEim+787Z za@yyiB$f7wk3$#^ce-(9dyk~CPHvOvYU8+fgpYf11wajT0IYvmUk9S-v%VfPV*KHV zu*w#}SrhA?HWctV;adCh+Fl|RFGY~RT&zwxAoYmCsGk;|j^o_risL9e;4R7n`HyX7pph$d%x@XFs8Mrk2276K&FS0}~D0(t|wiRrf@pq0SI(4Y+ zHXT}M{vONv2{P?x%G_tR?R`c03v)1otiRB#ecW3=@y}VWlMN;>@*g@^eS0xuNEc6E z;Ni#55d>$eM3lxwS7DtLx?p=Nj!+^>?MJ$1iW)YNm`YLiQ|=xemct8Jkv4}mwx|}u z|0UvYU$?zs45+L4rGJr)_5IY3qf}_6eZ46M@BqHME(clg!8n)7;Sm2_sK+cSCt#cQ z68}kkWAhD}wP&R(Xaqb=ex)`csfbFeUSlOKgc-AYU8Q(YqV7sAjgM&U+qHJQ>n&pM zFhKDhJZeyTz)-qSGy5eS(D1w4wXr%*@scm+ItKT+b-ckR`vUU<4&ft(C_G2archQB?~ouMPif9R`?~iuF8mbSAhl7wCR6kIa*mpKJ6i70 z8qTR-t~hq(fdx$W1(v*@@4wWQhqQqF4%$Nei@cnieyqT~L_qT|v+@@kdI#?LDjS;x zxHN3w{WnW$<=Xpkj7ps!RzjQbo6Gb5JLJ|>#%Cb>V+mc+;hD9M)nV^nlsXNuZVhyH zgnLX=k4C!Yli&mO9h6BC7&P_NV=Q|5=laL#JP)2N2HAcBj&GvA1g|q?TD9AC$>Voj zZ@+Ae*sfk7F`Uj+MQq~fe7osp55Rd)6Y(v}KNlAT5jdcGLlUE@GjThfEOFnJRi_Uv zJJ&it%up`^NA%_c3T4+#@)^y(|x+_h|nO?Z?F)pH5^jyoN;2KnX< z?5zZy>&qWQff%x85 z(IzfilHgl1CJER0C|~sjw{KnlJoX!A8uqPjK_k4q{Sw}kRae-CE%`MgY3B>x403TY76}rD2sxug^<3;#9 zM&_!h;1^`S`IB$QT<+sc=WfX+vHL1F`ZNB{ATyEQ=543pqGKeO;4JmS76JWK)9h$g1k{5sXa$M--{(X1}; zAJEkR=sIOfet59cWv%nCnO$ldkh2@8>qZ_$uo-E63$2O6%&ve8S@}+e@#9!nBp8ut zzi#I{(1@NjZ0?E=6L~IT*8$&px*}0r_a-gOi@{B zwi1fhig;CF@;D5_Y& zr6P}RtR(1_r7)8oyoH%|r0X-pr38NY?tu1&&T6my!h7&al~1kBLq{dWd1v*EPgvO+ zSw>PXx?Fs^TBGbWX)E`LE7@AK#u8M>Y4c>aeHoW7dP4qK0=!&Xl>^5v?(~_Ho?mVk zBntA=u<>{5`%E6xxB3P6439oAV5&QrR!m)bBMn!D?U!V4mSS>sFu&sLhUn$<`d_Y{ z_{du0@SPpAaNoA~c9bCzz5`f#xMaz&?Z~pUEdo;!R{e3$Fd-xDyYg=YR4n-6kXnv@ zzQ_Gh`}>ej&xnC+6>*&`h>S{Cj5-{w$EOvb?TeCc``O6-Os<9d;7QUbvq(S;WM+g- ztFpxjJXPRs{T{pb9|UCI&b_$QwLge!2%JPoe~(81YRow*a=UsRC57SN|mA-xy`1d=LB#>-=2{Zrj3!HQ=ZngR4m!KdKw+g#J;b2f_ zckDCjPy{FTZK%4TZG)|kJU)E|_uBy%`(>qRoZ9lXzcY!opWIjTwQYEp#tn9zkJdX6 zNx5-7{eirg9* z9slv4z42~O-rkBBJS1$K2Jh4&YRWtts{VWd?#vY~CW{W6vHbbD8C+}FbyL+kYju7a z>=(_fxzE?Iy8v*%*Qn&a9OB#KqXcyDN|^;KJQ2_1C(E%fkomt$f!#ni5sp|NaNnMz?e*wMtOB%KCoHsbPKs1U zYi^V^Eq3SJa-;r6r7XgCUP!a%zaWLeCR=g>)X?l9&rT`axq8cj4zH?7tr*JY}XkO#GNR8A<8@b*6Q$8 zB1gAA`-o4__D6B{$1XQaeDj(-&5@5QC;v*;{K>;rR+-K^>?R#y&!V*z@u^LAOEb}C=?CyKrwqFdIE7_YND@TlyGv2dDHXU(`-_nF=he{l?76%ZWD1zH^H^iw z!NxH_=d42P#_8-eZiyBTZEhcIN6DNGzOr&Cx5gP$fjB({41nEPs38b;1>^1pnoWK( zJW8Av1t;F#o@+_W@O&6BmJH^}3=h`^BP><%5bf0NXIHbOW>sg6Mb%HGMt<(SZ;%h7 zVC|5b$>NY|P1;CP?v~GTzc@!>-=KFfzo-&TKkxeyagD>1p^=aGk@a3TopS}@O1xyW ze_xDxc>0!33aG$v%YFBw31t;|`^hwxRG$vQ8)B{T56La)hZMvE1lkwV{{X&!hMLfI7co!w%1fa>Q5+tg7j`AP|^idTY%1!&6fU&F&>%O0GhRpfO?I z?)6~QF3J7H<)xR?{d-cTfw-$uLa%AodqGZkhK5uHM1?gX4k>{X^BG&PBgyvE2(nvr zsb0`cG$O*|_ZOpnh1r=8SDEmb^J71AuFd?DA?y3hS4;IC2Mk!gh<01}=l)Sq9b(`Q zm~s$9Bo($S&zyXEP;5&lelVe}kH;ia{frSljBwxDHi(8*jfc}ych9JLW&;i5^?nDRTv?jEhB-W@bBlNAM>HQq z`cC_6@ki|pSA8}VDH zEaeb=k(zn~sG2@`1V(69F%R*32J33xX9Bbl&q_>k_4%4HCPSUj!vA%$O$#=H=viS3 znsZ;cmSAs%8-7F3<3$C}$Sw^$F&Q(kG{bF^E@@-+eR$$$-~?8uG`$b1>>ie%e|bJ% z-NO%gA3tj$puxc*h~^zj4o|!zDjya5p-^+agzdXtGJqm>(4H`DAeEDeVI~E2fW&?6 z{duOs#2l$Yi>Dg)Dj-895>?oaW0zy(wQ-b1~S4@HY**JpbE_}s{h z-mLHQGdw24Nl{d_`?C4$kqQ@1C&uUO;(mT%upm_HvEF{!6$4Gy_Ae$*f3vLTW0PilEU7HcYtgHrH`) zr&-tES=6A=`#rlbJeR8mGy5EE>{rO*QE^|(7-7N0!zdAh)IInJIjf=01#a!gWaqD* zCIR1S|K2-;!IC*Y8ymImLHKf&ApW_x68hLiVm%!CV zFz{d9Kef*RDH^zFW4u40o00zFn#WkG-{1C=+0Q?LoXIF~vVDW_{+Q)BC>7NEB7z4B zOuW=JdmICv(yOQxF-g`2-a$y)2WI>M8;sHZT28IaTmL!a!m4i5*o+$A}^ zIwp6_x3!)aCYr;OxG(R7Ilo-suK)6<#|?-U~|T^7kO{xyG*bby`3-guPvW z(Jk1@_)0UjhDSbl=LrBU6?VD8VIDZjMkO;`1gPfo?~4lx!e%+*HPqk_I9u+FWG0Qt zEBsCsRV<&#lRs{9@O<9Lu8W;OEo}^+ySE%AQXM37vu}_7M>oiZ`ePTEpP-ZjG_$fevuw2Yc(=>^JE7D zV=qn3;n@y*?MxZUehs|H!Oe+BLml7r&Ae*fc|YQWm-dFeNxvs$Kv2VcEJZYEaWBu& z*sB2L@ueQbILrKtNeOpj4(a>V2U0Mx`>FdRJ2|veOS-m-mQ4(wOYaW9cF04gKPUJK zf8K6Wk^bmBQYO8;PG}GRMMKX*K(0f09Q%z@{6AW7UxO4p!Uk3cfOB?Q&R(H6{K~Oj z@GS*_Pn|u7^rA$zL*Q&Mf2X1my(C9N-D7EGzJUM+1g*shoG~9*p`rb{ZltrEn=wNW zZUQ2Zhr>~(FGf=U8$u(W>U?<3ASn~Y7br-lEW(^%-vygIh*i~r&QWlkkiR)N3ZQ6D z@Hq`|IXSkp(8U0s181BU5$~9w3>+~YfwX4sAG^)O@h!%_Vw_B8CrZkv$heVD^rsR8 z5RtR9Na@ErF$z)br{bZ1sSW$(f~5i6%teYadzvc~*7#GqI0#5MvyW}~sONAQCfQ5u z7x__O+o4yaIvKQ3ulz~7&feQztat&LVS?`h-R93dTt8kesn7F$enea3ZF^ZvoQmJ+ znl~KRjC^s93` znYkL4bRsX~>&#EWxL43u)L-B42aHCaHzT5Dp{@Stoz6gZW13s*E2i~fj&x!H=pt4} zUcEP@O2MW1?d#T{#s(5rY^hm+^~!v^Fr?4Hk!TxMz|ae|9x@mrNVSE;eJTOHIiufm zJT6GyRX=_7owp9KBsZ~f7>C;1y3V$9J7J&#&_C>Q2;YcJu4;(dO_m40bZv*63Z;D) zw(pxzU?nu!@E{<)Qq;Zs%f6QK*P?Hl)95(ZnM{~Z-?w8tC+X0VU=V!C=m2=`bm_m$ zk$=nyI=*-t$kJf2eff#!O1~}JUUguH;ds2fm`r@V2U>t{#SiMDo!`9wYp9QTe;})2 z|472}>|7o`q|4g6Zwq21l5h7#La-Qul+@%PU%p)K&FXvK!(OP+xg>JAoDmBjm>zLr zuD@ZwhP-^Ht@oM}v*_>T;M)=26XNdku4#pZ#|#^Tpvry6Iysn_o_1MLNCcc34`n zXEN71A&FWxN(cho7?xA>Jbi<0a~$Fh!AR{F*XyvKtv9tpf<@`SsPT-!{fJIhy0`DI z&wbBcM#F5Hyc4@h`%AEfe{!~qQ(7XdPwfh(Qk`@`YLO??#@HyB20}Xbb@m6DFhXQ- zSLp^ma96?CkLkwo^QM5^&kdJ7vEO zHgNQboAd#6?|=j{x^R1JcCS~D@+|-z{PvlGjLQG^=XL(Mr;t*}QC$-2m(s_OT}+g9 zvRAA(v?7{>#&blmeVL5(RosaHeo#EKeaW#ku|C95IlZogw0I(W9dQAYY4%7R^Tmy6 z(z`vNi)+d_^5MQ>f6;`WOU}@LhZ*kIVN&o}HdL$Q^bqK#{Ol!?P-}U-?jKJFs%Bd^c--mw?8G5282EG`M;lGQtVz8$FOGBb}~MbA?>_EU6byBj+{(eE}npOaB++ zLf=~MY6FnduvBK=oxT)GNv`79Ja!c30HAvQQmC-to%I@qN={ z5OeTvD05z49pe1o>QWQzA#>TxIe>vO{<0W z0x@9ZUAn}5ed|T*iwBJyREwe{0plG11gwu?;Mfxmn}dNJWfR=B2#9bZMqONBGp-k< zwx!;K|4oc-k*OcZ84A}{fW9)sc1iB&(`Fy*GAS)%I=h7szt7nhHM9&GSL#@um+hY0(j@FFw9i2P#SmzS^ zD%h}gkllPyVc{nGeZHfvC;f3 z=JItao~|@$vo~YP(+@^8`ZRpSu{r7vqzV>}Q~6g|hyGHjzCPf6zAXHF+^X9LRQ}-Y zm&1ApKoU|eX!z{6K2mujz#`9#a|^8chzem6&Qq^3D`2CZc@D+ZvFR6Qn_s-qXpk0W zgM8wzftlB$b@Ju#P8f3fOU!;1L+?iYA#E7M1H`90xH8%*7;uu7c&woJ7o?%RO9HR- zc=HYF=B+S{&pGFQj;sSpED*8NUW0XMtozK-->Qj}k^Mkd$3fG+G>td(1P z<@7P4?Ec(a2OxQWIG1%rl73PkEf!`aNa5=-ZcpA{AMYD~J@|a!nWu`6H9Z>`xO?lE=A|iJfS4qKO;66*%WZ!NM)2d*&W&oC|f2Qyq(`oY{ zz4K>M*weUrK~f%&yb~&f@C|(T;f?ndYqjhJ2Y0{NYws)Q;ulm&o}O(q)MU3{cxCZ1 zSk5b%JCt&7^|rbN1+Zv;2Di{{F%ou6=cGsIlWoQ5waJFeRozC*Hrq7q8z3>xJ(dNP zy3U1s3mLPa20k2AggY|E4~4#z)tKN{&TGS zI%^}rOY=>q+R&#ORAJPIYFBzM&G+rgYzm=2O$4lv5dy## zWad!7kM5H{i+Dy{3Ya-v94gZk$d;jMBv>!#j0SY+N1HoBnL;s8yT-V?v^)bxQL2r9 zA+b+=M2gP1RM&lFB9xg{vKS!?>QFxxP_3DGPBW0{_cYABE1bX;z~GIyU&P(uA#{jt z*>}m8DM{A{F~21t#(n#B%UG8Rq%V74-;Uy59v#f#q7mx(w6F~vM%yPV83K~hky6~O_KEuV-G~#of z0G|oh=e_wG$O9;o#pK>DkT%Bd*@{lYU2PAo2T-oxC%*z^M|HK}DQIm|!&d9fo4Up= zjD!fAN5vnnf!8%FL7jW@-VSNPLawtvzdP}k`iLaBYCn{%2)vq#Kc0p5z4=cO>ZK=A zwt9p5GZE3~_}BYyxxab)dJ*X6n2y%1NSo)AxV(2DhkQuLgF8rwhrt|oJBMo7KW^`EFxo2nFxI;ugX&vV%#lNw5F}iclvcj%-hhPF-w6ldG7KRTXy{i% zIvz8_R3vIIYWdU<@6C$nolmxuX18UN&KpbA(fecexpf|-nQ}p!?LQ7K`;mR(5Gi7N zi%6n#ybyKyo67gKSUhcfn1TLtzq6n4q6&Szy8?jlRIIM-*`G*I6#^ODz#ojWTY=~m z+34HLAcW!X*TFHP$tiwsMY(T!Cyr3MYdqVH#k-4AgWlg^^2da9*M=NPoGsHT92v^C zbVNln#}ZPPPnw_*_kb;#fm-ON(APRgIGJNoxI9U)3MBjuy z78g(8uBW#u5F|9+a4KA1?Pfc)YarT5Zq4!=bw% z@lc19-;;R&)O2^0ejIiNLX`~X#?>U)s?-Mzz7*0b&c}!3By$=l4_f_IS3*_V#ffAah!;BVoTz2aCN7Au~T%vqfcnP4DMfYF8WC_BcLp%Vm&0 z-{T{HJ80r4+AbI}Hg>tSvs=wc#n_Od>M!q8etSB7;h2OmX$x;mupxzrU*fCERY-gg z7qKqmkY>}g#JDQeqEC~7F9iw3mTia`4P|IZ71C&Rw$DuMk_IBQoRtK~zppG8Umapr ziY|_#Vjilw%Bh(-9|PlHDE1-#PU@*%?)(GCs6bYTh=we_{cYmBq^&x9aA5jYU}qEb zi)fs^wt84b-dXYVDU1`6%(0+j3xx0Iv~*Xkf(0EWa8P-F6;23+!}~hM^V4pINy|H_ z0L>(xuXpPnil2QXk4u(@&FbO&V}KAn7A0bAlex_;KnIFIe?6r4=rC+^2>)z&&@`cj16gdT7S2Wzg~mp`%WwU8N6UG#d6FO}RsCS9s6V6_VVBT6e{4akTHM2Y!!{F4 zrB~{l2l0f}dcqoxSkfZF4}?%H_rYRzPl60qDJGVc>sr&lnw!@3@p@(iu+QI9XIG1@ z-QKA=aj9Xu-@^rD;}^_RB!{w^OZPLE#!N^+TG&F6aHV5a6XxQ0O`~F8uKSC09nKCD zNVeu5uWDL{OR=kWPA`2yl+q1pV2M8=N-jJqt;4$eGPK2di!wq#Hn!r#oJ=1s=@S8| z$IBB-Dnyob9Y2vS-(akHK3&jzGLhAqeQ9|=2=`0jC-%g$pA3!WaryAh#1r_^p6K@D z+QlOTWIHni(gi(451fw0m1e)T_Jz`#t~4%nsrcN?j{_yL2ml*3ow9eP0?7R7Wc|AH-)I}Di8OsZbSA5i{8hKO(P*M{5*8`ZGy4Q6|IS-6!oob-5 zVF*t1z;V{=!Y{)mBV#-}f!2}q@D%Bv3Gx5Od>s6rK9zbpApw&|K+VjHR-wz9;7%@IszZ|LXL$UkY|C+gnb2|i6)q392`t79w)eAdm z`xkcV)`d_pp4I63+n?_ICh_-!Au*xn_N%g);BfCUg(ObvCGok-6xUCtIp9_U_9))& z0>p-J5atI|6$+Fnd#_M^p5FEf<+}X)rbJrFb+Eqc{n%BFS`Ld{)GnVtTDeXqKT*_Z z>$-PKe(N1BA%jE3!w`&?lm-Cw&$`A${H)$gucaevPM}b_?H# zZJy8}xs5~j2slv7c24HcC1E8@j$T@ewV7^wm*&z9m6L3ar&u4G@T%5b%AX!xj<)WM z8K#uX(q1m)&NOiQ*h7fy9)>Z13T)+@q{kowdlhU~A}-}37Jr$)+-?KIv2c?^>T^@b z?09|5@eAZJ$HL}baLZSJIH0SC=vGSSdlAkzR~!e*mZ?`C)AlQ?iu4%-^Nf-76PC{7 zzDM{Jdxt@|*;Q#|j#%X~u((N}>dx&$W8LS}5M6 znBn<9QMI$0PN^hAX8R?^?2;?{ z2cR+lb~26qnWZF@dxucaVX4;CewoSisJs}&1Y3!adFdY_RFYGuNQT&m?{Aj%f#xg- zbiSV;$GSdG;BFLu@QzpWC}40ZOi;oGI7;PTT6UR3J*Lx4e;88Qs+jc!cASwZI8!I~ zQ$^emU-NJ;F_1rRZaIxvoNEU=z6l4mkmephjgFH6k9ZM zHg@XSyrKiwc74Di=KgpN^ArK@4Y{AqvG*g|Iqmi%Q328h`yI6O|*!$*2^M(FN|N)IUfOperM?6Q1o^S1*#t|jJgiuW1t<$-c7K!b=dfQE@MqsG z6>r3-J69?+_K&O>h{W<|fxO-%{m$m5vkY-EX)lLHH%&2sfQe4S__5E`f%q1B5?qBA z!SwSLy>pc>N%&3>?X+Dj=Xd1cfLI%3TW0db{NTl08Ax-V zYu(~cF_=&x#M=~rV5S;;rnEw|k%Ssph_d3w6SE%lgQe=HSbB%ygm~L_JaiL0Vtgk9 zv77Ekc63hnlO%31@nwKm#l-=fvcIP&G%|z1O*$wm>h6z}47UUzv6Lb)_l=K3&9TIx z@JQ(WKV8d*;DqjnpGm}oQ7{Lc%}m%vhetWT-YtB~jnEB~6K+3_sGj}T1StsY!ikHMMx1t+(9kJ+Yr95v*alHy~}%#vAFp0JF;An<{=4@a$lzIS_5 zKd1Cd2;S^s6bi-z>tUV^k<{VI8P>dT!~8c?Oj5VPwrau$IxZ9GW=B5*Q^i!y#rP2J zw8a<^``VAQPy_(!MQ9R%mvu%)^gaDK@v}P&cW|UA=DqJcn#0)SXnjD^{b6ZxUo`aJ zs;cx^JqQP|6|bMLutCjdl#W+lPgEiBz|!~qgvrYMFQ!QmM8JZn z>%7JV1=4|FJti-?n0y`gjAD!ifO0v)Z?rZ$3xy(1|uG<|9 zDDX>e6#K)s`Pyfv>8e`hzWW!*Ti4Ny2=ir;I|`Cde{S#>65iD6(3WE3ZpW(Hn#7wg z&A=msmnqz4YwPd5X;w>Y3^;0W$EkmFThh3AbNBAO7yv-`0Au1kjeOMMUWXR zKsb$s3%l$UXX(Cw2mViq*rI?j=FwTL(neIc$eWGW5fn{|`$v->k!lF0RL5Yiu4(?f z3Mdrvdk}oA`!<&h|Cy@CnU;7~AuptV+LF_VjTPN_-~H^WE@BwyNTzLJWULC^LfqvV zng_=~8^gy9gct$eSSE!QY(~h(&h!KP!*`ev!xuz*f6npEBM#?h<1|w zmUxyguF&qASj2%=T3VMgvnmznQSWbD$BN{5bB{J>h>)~3<=rMb=~b`AQh9j zm%F3hmLH_Tbz`5)bAt@~T-dP4Jq0Z( z5n$Z@y;2r}^GTMFkAeZUOP$6lQq1~PZ%0k;T+V_7Ynw7ieju~Yq9-K(&b*+4{f-HR zfrKglY05tKZg#q%fmJCq{|rIo)J>NMG!&FE*gr>OWjS0QkIRY;8^r2MP=(7!+7|k` zr-Dy`ov8DbUj42`Oi*tSSpHoZlvK4N@wqCXH=Z)odiSmdS(k(U#HuHlmmeQtR+ix&G#EyP1rTLy03<$w;QW02sa_T!IG$iU zvqy_FU3{^AeyQ=Bu37i~!95$!3(X;KL3T|D^y8UL2E zsYy?d^EB_tqCcxROK#6S(Y;oO@h{oP*b?ra!C^G#nQ*U2Ay-GMqZiD5%-1e(RKCdz z9$o2Z^Lb>9A@`PUXDd>!MkU|Dw2C>SWmxk0Qv`X3Yl>G)l+Zr~*jp$dq%kQR-cEf_ z&ZPlvlEs5|Bk@w@_D8VQ_KSkQsf8LS%@eRfXBh6hz6m|Z*AXUR&GGxewpV2&rHT}YqS>{ z#P+4~5SYd*`m~DeFxBS>UalyqlF?g~^N#KfM?&f9O?XAI_Z=%|jYhMNP;4}88?k8_ zd_#ZlH;sn|?T07tbAX!V7hB>Kq`i6m;}AFu7o15m{L}!Vh41wOf9C%Bpw6O8?%kQxP4$)%u0Ly#MwanQ3QL zxRfv0eEIR=ECH}!A-3RO&EYV-<{w>jcXmn7vDG@981sio1f!T^bUi)eL%9Nej+e}~ zGq`|GB&U*(Z1t_w4}V#VZV$x62Uy6LlnDLL-5baEONi1MREFCYkiW3L!xr$BL92)A zPDmZk0ZJ}+Z$8hYCKg|qgyZ6gC&~bV_uk!tTBDFN9$GM%=b~LD`k=>fc+14WD6Brb z^roKVJH%Z)6Hg32Q8D+yKEva%sAR<_3$B)BE{i|6{Wd+zSC;7^>ks#P9Zy`64|_si zuDY!%4C%dD8;9Hvsp~5H`{82AulL~@YpK==x@o#N!i`!pngbWakOYatAe2`C2j zb~3&Yq>$AIz1m_|YFSrPyHE`Ou(&A}^Tz-9ci!WWwOf?&vEM}gXNV_3|H{`er!?FG z*o)P}_$kWPL`mhl?wh;c;r>uRqZ4k&h(V||C-~7QpMdv;;2V&1(^zQ%6|5eHlt@7digWuq>mImm2@f|&d!t$fZ6`sq zsTdIcQI~VC^Dz)oP#I4BEoy|B;VbQ{h10%lRVq9c z8?J|!mAkwWyiii(qp*=Y1?zNH9yY(Mw*tIPLe*x!*^K^br1>;cjBbC5-mgN57VcVq zLxJ6ff|3TY*TlMcsE-LXJ^@^bKk%%!Nap(c!IIv`OBmXi)wxw3XqD^iK`f5Za~p(I zM&_2L?zMc^-Rj#02(}bw`^KkZMLy9@NQ~!q&qx3l+9ww!tL^k|nb!aq+%wMTZgqso zxC)Pf+2i^$QwM5{BAsB=?OT4hgluldsJj&wPu)F@CJ(jwwb(&JkDwAC>g|5!Nx!J7fjLx|CuUAz9 zbQst932ilk0>Y!G#xut9eW}nq@Q~S0Qk}T%hcvW#r}`N+Z|x-Mmn6aCdt85~{RbSrnX5;SJ@h9WH?Sy(ABrglHttgzD_8ZUPg?{F`L<;L{`qS}-fic^488E2kb2y~q#I6A*DDxC z{bjm0dO>c)v-#U7BKwd+Um``50y{H<-}v&-89z(|=IHM?UxcplqyDY7*`eO;8syM3 zw@>rQgQZma%+=dh$Z@lM?cjkv(Ffr2HQ?cE*oUKE*j}F*_h$&V%h~qHt~`^1(^q2% z34Z|*w9%YzTb3nnboaD;bbQERK}9>p5;cw~xDAu1_jRtwm1c>+;b$cUrG-N47UVfWzt0Xg?0$Js^V# zdKX)75ykv2DeG5rw63%ad=HXB*S=7jewctVaaec6YdE>F2ZMCoz}W0y&Bhp9sV_Nr zBT|BQiS&~OgX&LZy4+g_$-cj=hvl?~08Phx$I7?aM674xdKb?yJq`1@b_}7#%proo zMiS`ahL%L8mtzh8xN^R-E+6bKdUES;^DS8Wl0NrXiG|bj$bTkbUss$UZS0^bgaqMtyGkAy?s2;A`4^KCjS4{L!&7|JKMU!f&NaX=`9S zF9OLl!RS9v8P^6(CL9exCG#KP6ZKjDF2(e*_IP8~FFAVCKRSAI#k=QbR8Tw} z{-QjuGJ&qXZ!&LR$l7vpgW~+Gl#04Utv0BL<^fsr97NRzjVWlIi*5oWSH*8(EV*r& z7WcMj7$hxffQ}wErZ}V$>1M@#&sRkdl$pb|NBCIp>G}003KXZX$s^2e$+JO=U^E>T93{d3n~kI@(RxxTOfB%4Jf4Q_@BRcuH*Nz5dXTfh)Av-}{ru z{82#9?qu#%b`x=0> z>jzb038oLv<&Y<+F0m6r(Q6vJ{_|*AgcG>dZI6V=;`w$EzAMN}K|`dAdxi<6R_8;C zGLzF8u5Y7E1K7y;40wXP~Ejgzg@BINzm_zwYs(t*-zVQ6*Qiqw|x} zT>%V*XTX<W^Ay>;*_jqdTCoZZZ?obuuq+g)vSoEF zfCr(PNaw`Jmy_|i-Xd!CVkiV3KLWJXC0X~_Ovl8gU>XrQVP&!G=q$UR7&a;B4B(d2 zar*9igKiOioZJLj&Qx138~LXs4ve^hAH1U_l>*AUGdx#LFX^<$zz>F`|9GzC0@82* z+t^-`;<!3}xuS)x1MBkkQKsYILjiH1es4~&j-Ttal`^^z`1ek-LdA!Mf!Lb>w?K;mvOT5Ia}gW%Th zp`Q}xS4MjdSadJaIwpSvn&>{P zST4&QwPBag{iQ1^uvsql{(?v;@c;@%%`4zP7Q`MtXEVFJvImF=B9u>hoJXN7A5AgC zcSUn7D+ACqb=3V%;swyU*ar1$(d`lUipK%Fg%jc!@k$=Q<^stKKRz0eRoBH7xaFCn z@kWIY>GIfDHo(NY>(R_VCpxwc)Sb9`vP0RYpN>gZbO17+`akFN0^V0Z9vb{NuJlJ2 zK=Qw|*6Gp;?#y0Lga^gtaKGYHtx6W4>_DCZ-Bq}K;XgTU%;UFaJo4)7 z=>{@t3d2qeP(T;(diwKq0Axwto~`(hUZ<0uTv1hmMWYv3$?1YvSII9_n6hMeJ&ci# z>Ji(RhBDbUdg;~M+C--o?@7Z z2gcrtY`Yfhr4CKelZ~D-6h<2VuOAkb~ z>SrNUQf++IUx`^0EZ?3c9AP%1p?rOg9HtHYtW;pnNfIZ9YO{Pg=i+?BvyJ&q3@WmI zW|XB1$~xajel|YXCL7iESpLQ>$y(2KpT_XqX&eu}7i}^#y?)RuC#Sh*iOyd7?}Lz1 zaOBGE)AyJI+PB!M-x>~={ZVu9IR=kLDFq)GZeb!8t&g^0=cY?i@?!fi8Dx*aJs?FQB720g{83q6-T!Xe>o& zXLN3bBIuJta>F1}`wISG)qaz~y(qGA+(KyHGLwyml+Ex`U9o2)muhyTfuv z4Zw`h=mvZcZb*d{_am~lM#oFRRIPLTW^j3UqR}CWueYZkUzb8eX))15{Q_5jJy_Pq zJRJ}^fOvV{z9}vt{E5&5=dK&vnI*Tn2NWm5?MV>Q>AIJ&6d|IX`v9X}2^|kcdlZiQ zfv`#_HF+GYE5R9PJWihdSrvbeESec;{Lc02c;gKw5G83jHS{kBnQoigho^ff)qC?o zYr6iWVVb2>57AaQU!`~z-BIL85%eFltUUKxA_o>l_lXj!MKN@N91Z#UL8tc~Z5+RU zorS}Gy+2RkrQsg?06?o;-my(TB4i+4neSe(NG-7TCet)r7E_D%>?c-H_}YsHR8?ID z%N<`iY?-EVgME@%`}Q=otPyefVm=%f+7mr0_pMhDis%P*rdd57&eK66MmIH1%L)Bw zp-E&SakMu; zHTOH9l`~O%)X{#S*_vec8xQq41NOPwOK#lCexW<8k6$3_n*%v{N+;J79IK4kL!38#3f%Ed)VgVFt^Io$~3F-l&Y3d?~MS-SA% zIY^P=WYoC}U&uDtd*m^ipXjSCeEnRb)A^7J=&G*MpheM#F%_ori)-F5JgFXebPnPV z;_h#fmc}23zQ}l|A?;o<*`F7ix88ex+~PCC`?b%mdLTXpIN%)h5VSt^3`Pj|&zYt6 ztmVz6r(}BGsQsdeuHg!gZ=RoHk=Pe%ZLGTv=H&am^S!~v($61EM+yJ zrz_seg!GxF8J)Qh1e4cIXs#nEp8DaBD}J5>0l>8NedK<*4AkIDOivGfxLHFd9sR#q z=TZ;6N;wsiz~dLMz2!IjiNv?SH`<=j69EGWWMnkS*^Y#^C}F-_tZ4A7t{b z+(pHw2$!1e0ONAu&GiLzc`@9^aIhIRJ`2o8roCZLH>IEd;}}xEeJl@(Cik)3pn(yN z%ffiZux7pV6jm)#n1jm$3anKh$La*MKOdaierk(H+~9S=#XT$6=PO@B;BoT6rT^U? zD4QfFS~je+1Rni^Ivh1vvgAF^Ehx!-S5t@hY!{0BUYp&31I29k4383Aecqn%g&Tt} zm-pk+1pL__9%yw4@TB99{i6m*z|`~Thjw4Ud6;Wvoz))Pku_$h;UiXw@a*-9tbk5F6E@Hr{o)V`x9vUO`QW5&^#=qe;%=cZj+ig9Qhbiegj z1N1Ww0iWs-EVXSR&CvbHw}J*u%?m8_*vVENB0XQF=d+?~!QV>p^2eZ&iF5e1N_AN+ z4iNERSNQ`(uz%RnvcYv!2~8dptxL2Cr_X3j9UJXWK@0r`oWp`Ha3ixWw*Q#YdpCs} zPlG4-1&B4BAdxgOlop_-`IR*H8QCa`G_rQ#6N_FiS$|EiJlJj>L!O{=n4xDRu`_$K z9-4I-k$S$oZ&UXWqZ?-YTvxM{SGCfqhjotZFKeoiu-x6;7M$pK4^+drI%_$d&=Nk- zRcXM82{CX-20F$)IPSlzX+N#l1&o_GJ zv+YAOG*nt{<7tVQMiu(fQoCH~D(%kB#t}@H**dIRo;t zRr=vfzK(_jbIa2eWMpNj3GE}l$J@hhuiQn^;EFyK?3!^LOO~~nMisu-PB%|h(ULqvvQXgui}D> z`=&jJJiwjdykNCoTBI{N8?;Y%vPzkda6IV?Ic10EttZe^D8wry(Kpk>E`3H+avy7wH?hC>_Oi_97=+%P_m*azk2;7-Z#wuy!y->Sn*yGk$TqNgt+A7HRI6M6HcjZoI zVkJY>Uh;N3zoR1~OSc#qdo;g2uFiX0C;DLf><=yCmK0UYM1`$HVi-KsD-yS-2mQO; z0^}`|q?;u74aXw*Ra0>d4+WYb_v;0_i{mB%a#G`miy+41!x>?8i0dfcf7wxTU*M0f z#rp+4Eh!KFS>EF|_2WMV;);Q)2n2QxT_Cw1FHurVUh1AxG5glU2W3zZYC zpcb<&STdAg+zm$+u5w>4P`dOCZ#e0qgv>Bdk#UnBck%V0j{718V>eJm;e__xw%{#k z_iLSr@=e<6RN4~uL9qP{YJaUSNq2}N4-!-m++~NPw5>e@@x*O|{KHa*AdbE{jQuu( zZhx=Ie)NLG^&_{@vH6Qf zjMhqjxwd?on`sS?$LmCf=y)W-`t!2r^?rfB%N*Z-tUs7q=_}8R$Bt)-**Mwj#@bY2 z%qx%cP-y^Hhrewn5knOA@lY7HxR@ioE$c~gPc1`h7Fbs|?~DQf-lOT8kZzr+stw-A z0lRGT=o0d$J%Qs+eU+pLFMg!WZ+f~(6xT_ZB<%6Mpg8+e?%CJUJbi%_@B29<%kc|t zaf~?avJJ$qVNQD>R;!G1+u4<(Rfh_D+x$nXb;@#`9@h6eV7mwv^K~Zi)EI=O8%rw% z3`$|L-kGmt8SwaUYd#l^QJBd{LOEX6=k+6gO`8g~k@#wGiBEm*2)mtgAA1ROHgXVL z&ssw>YjzGVQBA@wZ#(^tarKn!3{4@1ucjad;WdMIQ54otT|#8pJZnw%t7pC*Sc3K| z%IRHtiIg(#V?S$v|o`w+^c zd&ZNie~{#4(|urkuor$A-GZHcdmg_@q@DHUwQdA798Jp?p>`95iT!efS>~_J1}bGE)Z6W$wnu`fs#G?Afp6URm7&yi zXTIf%8&!uXo?sCZANiOM-R+IG%Paa0J0R36op~l_P>?h8`m_S{SHDNXNNV?n=HNR1 zZk0!qecV2Lqxteb{dzF8-)*BNNedFwsNd_48~2Ofo|5bEv#$|Lm!GiRta?VT%i&~K zS0;1>Z_g4Fd%hw1HM#ZXkB+fdJm>=l^&=j$@L7s)IFP-#MMfN!05hmOX{tF`RWuCF z*FNR<2NUGmpMB*tB5P*`P!hf0t~b>;bc6-#&x1wFuerVj7#4a+GNrk99$wBZ0Gii! z+aaPKe7HlsHk9U`iP7HTecrTT;v2(iX z!|?Br_I2<3o0wiJrD$xhhwEqQleIoLSm~gj$A=8vdNR(KR{FDcdE_vHoXJs!=0?f`&VBL@bqTEtkqIB?LIV85N<}5fF)y4(LGTAo0<6ISV+F>5Y z&ic8wM%#Bfa-_`7@3QqajizzV%X0NkXwkq(qd^AEX}T6=m}sGVc7G;hi=?i^>mCgY z-Qc?@&+Z6ZnwK)aK`{;Y=Z`rS2E7W z#D?)joAJSu;Q!!qZ+@U^+!7~io?u+$|H{`Gt>|&02x@%*$a-LYtl3~Q1Sw(Je*SXg z`Jk}vX$e|yynfrP-;Ea|I15!_si!3R8kw{O(|rt|@N8ZTNb$|EPl=CwwF9)t!AG}7 zgdhSH?sF7sIYQ+)htwe-TFmk($SptG57Sq@&w_YiI0zg!rqY_KV-kXs(X#sg0rpQ% zqGEK5{;+F9SKl(^>j^BxV;HaAw_K+oF^(L z*$U2a+3^ZI`}o+GiX=N6uF6@FjWhOVp2c3COI&+5q>C4j@AKayq@=_ozN=x^Amh82 zMYX>#ivvvlu_%{dA33E0&nThJ(8Sp$?7-iOQR`ghioR| ze!krI`FWn(YJdAzIGX+)$K8A=e7%G&&G`&ex>VBMwVv@9%V{r+$1H6Vl5J~ZZ>T1& z(S0jI!{b)-GVWKLf=6q>#@t7N7N25P`d}O-`4EbnF{)r<#H4?PZ^&sApob(6+LN>3 z+160WzW2ZBoE&ndl!jA_a_xbn{rY+W{orLkzK?Oe@QanjZD7tnG$n~=59lw$7M&Wc z+wb#bPxk1NeAzWx%5m+<3vsROkZz@I_vg;c&5geMTF3dtf=`(-0HaKg-jZc#uB{QTg|gJ_7T% z`r8FOh(~dnk7RqK7P7gn7UO^^R@r5G9+wb(0t{oS4EP&XLBwNFEw|)z{y^J$$@vp? zVlzoUt-qBE08SruFGi==3Rv-eJ}yDo#mcX?YewK8$*EBP_>3dbdrxGvmGJSHn&uiO zAhKXM;S&7dd5dN(>u1NRpgK6l*H0AU(ceq(neW_UoC8SGp~8aR0*`{^vqVu-7e)*0 zC_1#s4%tBgM*`FT);u42TdoysP5%n=-W^~t)amjQR&DzmBjQn9Cj3e&X<7sk5oVWH zA97}R$AwAUizfsr$eH!U^aAo&ZK@=hms^gUT`^x~NBDnzkUhsyPSE5&U%~<5i#fRP zOYZa>T@(&f4YxEV_(%P|W-#lD*;76t7DXlEeoTk{>COSP0{i){`<^G8-evc_hYN=^ zK%jUA4*8}|%;ESm6S^rY4suk%+_rO-tjD(jp43fIWsoYNSeXt$Ty(#| zUSWboYs@MBcOuL4M{oe|XJGoqsX}}q3FF2^$Mr=Kw@&R|@Lj}3J{tF`BTpI)$NiD&Iia1?zz z&*wO&r){`$XH@x~9T3{&(6^l)G%$+J=(i@jJSH3T9#@xo39!H`j1isDMdv@S_4+mW zlNA=u>7d`-FC@=U!I#fQq;=y73+!~CqxqgVqJ@$;kAEG2p$GHf_~sQe%G)>`o`L^Q zspFugN)keHPo3g;F7nISpMMt#QO!x;!=3EWk<10PYp{AKdtYF#JRKJO;ZNBI$2|(Z zvZwH)T^4{@hwph`3-EU%T*i-h*NPd{KHJfoLMB{52M3H={cM{3_lhuF#BR@jk-Wao zge>;PF~7XI;B?+zLv(-j5142?J@00KJWZarbP#}G^)F>#j>VZ$fuHvs=Xuy`m_!ZK z&JS4`yJ|atE2R06>&G8K*sNLf3*%5OAfUEnCYNbJ(w$X4k*BzLT`7p}utsT_?E~iR zB!%Yw#vh~CduPv#g`6!B-Y7{w5*_!ZiC%%-;6PaT)9CY@Q`r1@cYzytlwlMZTN?FB ze;%fABe?aZWLLlElc&Iv_2r8;cMkT;E*vCuxqDhsqI)?ibB~n0RWn3N+V|!bw>tqJ zoznEgSI1R82Y&_Qu=osoZ8oSD{d;gGhGCBS$#))5nq^AXd@uJFOnsceA1h>y_PIUy z&Jz{;uNtZfwBo1>i=ezte|h2>A1Rg9DzppK-|F{ ziOhttz}u_b%I_R;wrkzs-$#Bxv+%b(Y(1<7ZsqK8dL^sBl#MMOuN~?J=zd;P19-iU zWqrTLMz-PEjAmCPT%vhn^ zhfUyN60uzG@%x>XdpP*0n#rdpBe~2+DZ%*ZuHLia?BDb%4)48*%h_kfkHB!aK1y#f zEHXl;?LK9b$-k=CBFc82ku2+)QX3JC-aeA^=b|L$ud2@Dm3h7!5`Cq_(+^&b`(gCY zLW)!I$2WR@KI`V=w7!NhK`GBbejKis%)nZ+YM2p}eFviuj0^}x`&rN-16;DNee>{x zZc~TmO(NOU#~8AH{kq8Z zzLKTJ_PK=1&)Yud0>ENR?W4}V++S=}?g2;x1LY#p&pHOZ_$7^7Rw1=@uco~71`06L zU&B)Q{RgfV;+;4RdOp(RkkGrsxxE8c)uNuG52 z$w_*@Od}ED|5sHcXgcsM9m)IoxQ0P#1QAhP+Ei=~tiLW+daCx@63-5X*=y|IeVyx{@y=;Ybg)5`xy4!@m+aGHYvuagn+!=1#xJN z5b#O%J}F#FbQsrGvCaKezOvW`aZR*g27#CRlQ;&J#~|+*!$H&Md0S- zg!y|OSLgA-y(K=CNwx|)oXt*gVxSSZ?<)fbC3Lf`Sj{Elsx?7>#B^NT@stuhGK3E%5!M3fqMn z^j)Z+Ked8j0_)QLVEqi25Buwd7bJ+>^MGC`SPSE2?cp-jk5}S@b(xeo3Qt(KV<*M9 zRDx!>mHQ3@Fx>Z{^jotU9zP2?ND%@yP@@?{$79amF2zN4jvjRgki<{x7b<=e?ujm3 zs$Te(swHSP5+F;vv5@%1NPf=7r6s>L{r#gL&?-f0CkQ|&lbx>#USQxK`-sNoeG4xy zLK=dff5XMxFPemRErOA^mer;sy@*e@qR|LPUZF~&z8|IDPdc`l!w+=6C9z#t(^t19 zxr>U%kgP-9PChSRiVGW3Q}A&-d}7K2`NUW^(I)*>U|ycYANLlz9DifvJNn*_UB>=V zSh|QQ>8eHiMC24K&JX6Hvh0!Qxq}-(1mICI+@c&xTViC$iOfo-`E%{J!7%Js(oy+xUbq*t3mig7= zgr^>@CCeXUIxj%mE$AQg;m`UBTU>c{T&xb4(*+;iv%SB55R!c(eZTcvjC8SXR)3fM zpt4hN-X5Y#Pwje)G=f!cwxJzR?6Kht?i^mJVuHV)Jt1bJnS|SinZJit;P45^n0*=P+&bGgld{QaysV)o3Rgre%wE#1;sFHC_rTV@QS7cDy%!zA_F z`zipTxJk`k;xE6eoJA2kJi_>-qw?02>#&dAu1aS}7%HmV8^X7rE4UVXC2=C1)am<3 zML$3d17YUQnEDZ7mKXVL%@?4IYTA&LQ6=uL{J`<@Gn60y+U|2nIo{jiJ$yZdWB@2U zS_F>s6o^c<@r@%tneQD1h)F+D+I)W!reC}8%{aqFUCLEyw$Or&GV+tv*mEuMq@zD@ z)Mk%r!#9kyC;J!RNN8=yRgKGGT@2YpOj*yim z*KYS_#T=?=wS3OZh0NN^;KURV4GsHh`cp{x#J9SA3G>VTUfkwZ>56ra_wHVHY4#xd znH*{W>DqWeSFE0LoDoxGx{=9#2NoPK*V_HkW11lHpwG}(-oe7Hs+Lkfj3K zfQsb8qrA#Qmv-dGv=0hd1gy{XGV3;?Z~pTv=AQ@y@dXcke@y&%7rrR(!8CSMzYBgF z@OOPgAB`685jAtn*6ze23EWhgx6kwk8ZPXUH|e1$-yKrp04o@n?m_kbiTKVOojmJhqKj0TNEKn6BgtM;PtY%URwp z%Sbc_IPGJWACdjbLkC1wU-Yz#pvAp$|Mb`*Z!m?d{e#XOdLOw`%^mO}3bbb*G(BOV z!0tNL4n{mV>O9Z~GsYBj{OsYHA&C~uX%4q2B&1ejx^^zM(+To?pYP00J@B2|6#%Yo z516{+57cLp6n2NeO2lB+(wi3oF?^qmXZW(VI<%fUx}*~ZIk7$=~ z1~ZI8e&fsHq1wjl_ah&ad&IzhoMAd0lYI>U<)+=gUK2B&=KH)q9#+{ViR)|+y#>n! zNgFnx@X@*{*OGJ3S^YgPfo&L;rZisyBM7+_m)U%qIrDW-fXc+fh4npA>$`-9If)Am zBqw#6B#ES0?Q^k59jTyw78GobQnL|)l1V$>Mb1-TY1V!?PQ6V>nNMP<^Alr&cy6C@ zgY8u|a83Me67HzWzB7HD_%V7N&mUvEqprA5i59%VF`kv*rQlWaOaHL03MX?mJ^T7f z4Kb-%MW|o1XckVvj!69;H|VK<`<5Z?6My>>9yDZH{n!J2LL~C0DP;ZG5Q&%?Rd{Z-q25^aeRy)yvp)7Z2jMDwvNm3250cjrv`F<{FOWP;LAeR1@*y~s83nO zyY3~+{YW3&PxQ&z6f)e~*9Gf*pQFC{F?^2b_#XH5X1`*=(z`Cc?sM8z%?$R@8T0%L zm6U-`M2ZCP`{mKLPA5I7PHP^h0nct4>r9K>1BjqHv>)N9&E0M({eLBbjW(3|ViuJeKbor6{N>_I<@lsmNtH5T;?2NFWk7wwW(Sl*)PT8OefZ>2)0vvljWXA8Kg0) zpB9)r;zf@4;&6DC9LxLD(JWvrtN!*--ds3i5VS8^@ed5hO-sxc0XpnJs`$>@-0Wu5G+w7Ek1jPP{$6oG@WkB1uHvUP1D+=bf zNmt{&C-*Dj)P6SS!)C?ET^>$9+Bk3~49r2%Aoq7h@XcSEI+Dq+uxOax_Rk4TRQSK$ zSL1EOe>De0FVDgL5kK6K`3pUt+LsYhXbqegDGl?+8NWb2eXHVjv=n+^nf)*EkDo2n z5N9-Z-1k5ZwCXMI-R-CH`*5KQr3dcGDO~b4B}2Y9UXuA;n&Rf0iaOQ;=WPT$pWce81U^UPq?dm$|9-Gu>vVP zXp10cl0K#9=rFE@51L34d%7QpdViZEm!ABAi760FkXD$k_mP8tPWXUjeUHb1A3xO% z%vT~zAEUYsIruFA^Yf%2@>C5E4t_t$SX}Pqeo@X8XS@5>mcwkT_%uEsk!4TK{CE1l&%ZX)>5E`WN;nah&?&c?r%I_ z;~%{r)9-&FPf3n_lem0EvP7#;0Amh%2!} zwzSgk_;MQ!G=OolNtPL1<>&9q#0iUzzu#MqLrhF%l^syVxwm7v&=b=c@SA26cGrGN z#X%h5%jfs+?6SX6Iv9C@YlYjJD7^`9l%Lbj=I)QkBXiI)fYqdV;4Bw!3R7r$V&L0(GciKleNze>{N8zPauHMI}~}X1-DhmAeBqI#l!eaE=|oxd0}xk z{ci4=l5E;XDfll1k4ZcW`ROwm`>GoHl4R_w_TX{C;;gU)K@3*comnYl&OOzfkq>%~`NG_dn zA|^RvzqB^ZlgwEs#b-?-MT;{C#8^Fo)NPq0y{7GxgiSDT#9}eyV}oE$q>I=3fQ@%A zK=&>>c5f`0em&qi58SBYm=vXvMd7WKhr>OodWE&3m!G0nWApG4a{636%OQ+pUXs)i z&FR72Hp3*CP>JsQ&~gNWRLuw`sfKfR<^1Lg32>#t8#u?`d#$7$BQBo&_yv;x9&AA~ z2LvkP;=I1ER|emk`4%r5ld6%+-FQoj4Ji0PN*b9)F3_+Mj)01?1 zKX-^9AJV6k0Z!vH{OrCKcl>?pzIsbn6?RcswtQs!67d9Ktg?2~f^%yCnZOYOI_6$9 z55mREBr^iX7p;qA-@W3r9)8|}z(e`Dr@9#tCTW`~Bs?N3~?%}$|2?m*uc9sDnV;8(}zVRNO5R&640Fhf_UQkuL13@96L=t z=!a)Q>d(+jI9hUT$bp~uc;CiZb=w?4`IH6YugJrNrDY8Zd;hc(L!6TM4I3=`} zmR^@h>1%)4TH_ss@fi@ts!^YsbudoVtZnNZe+<@<@A=$a^ralj1A)fYeM0)cOX{08 zUjELJI8wpPEe=E=|I$710T=DkyyKVT&KA}_q%ai4N~8OpXBtr2za&O>QonzVsb`u{(){)n#AGM5oR@b$g!MuzOvCMiAvf^RX&P~%Fa_TD{U$OF z-SM@VEc`<-A~Qex$RR&kLvv)eFN?g!tBjW{0}XkCKkAiTCvvjj*XlwP&xK=t zY+yT#g8?uDUnqPd^{bry>{^>cHGi-#8T0k8XDeI!(a24fQiqw61|t&XAqNoJyNyIj zozTHX!QJ>lsHQXeJy%SxeqY2a>J`>YsDk*rd2+0M8mF&y5CY)^NKOGC8`{ApN_4I*T=nKt zm=(S>-=uSI!N`U90_zStgoL_2U*!Ipx_Vgc2US1qu7|knEgDgGLfWk1O!#Wv`|D4d z9%q8wSj+-Suir$UTPqamAcZ6>?63NS4PWQW5)yCJVelO1%cW?>v2M<7Q%Rc5oFmSs zA+f6`?1~Ag^njf5XE@det1YmJ-EQAQQunr`oF)DgxOXl&)tTetuhQaCSU2RIaa?ms z21<7J2uQdz%lCa9ClCYBiu1(8RFh%;oAyf=Ot;)deJ33_WH0r_;JjCU1ZW`5(UV@M z4PWhRcRaB}#NxV0-aWlOocE2jfoeC8p&w2coHD8%p|T8lRHr5q9^r+q*uxzFAtB?B z$@{ijb}$XQgo<;$j#wyuzaLq|czi5|r+@=wk3OqIAfNDZ%i%%_!1C_F!p3~Lo_#(z zmhtz%`+)@zpiPR#7j9VV{l&3N3F`Hh=GvNTTLN!0=M`u$Z>w+06^|zi9VPzZyS}7; z{EjN@3mo>{=YG4^cZougKghib9}C>fS|l#x8=T+E?x<>9@GU~{B^CxOOZHj3NCvMP z3Exu{bL*NYTeDC2FQjWs*L7oY*rTq9{9be+@Lw7J6cyvr1E;6(Q#9cww<*sO*84T; z7(PVR{4D)=J%ouZb)BsplFGQ8o%syL9f>o4_a&(3m5|{3ptI0qa1-8x8N<;Q2D>Ta7p8$H;b$gT_+piufXL^t8 z`RV>{hu4UvJ1eaAi1JO|^R}ZGWfxhAVkwnM_(@&qFV&Ve4s(4EGzWop&@}P=H?*Id zIfx!EJCdBd9>4|O=-YET!0^uV%n52O3@mh_5XMGGhc5f{Cql9!R3|A3)l4MxOwe9z zDz$rW`iM`5-FTcwk|#XH`Y3uYd(e%o6cx zo*w~iY}^@@)%Z}1=`_YvuUB{MEIvl@(!fd6a5MbQ4!yr^bVD?E-NUUZ#+V`s{*e|Z zW@JKjg|1g?-@g2nWdzd-g))#a#iCzGjdjS-)PbF=D7c>U(f2c&yjB#C#J*P8??zPd zsM5W~r!iIRKa#F%OHpl${*oktM~NaqGRm7MC`p3kukT6q9d%Dv84zKI6=ranX?n?k zl(o01@AZ2lckA$2yyHHtb(kPmYAIfhr+uy3^&HXq>}RfuFFmd%Iu)<))E!Q=@p9tj zYrf|XBTfg=0oCA3nRaZA?^Z4k25f!HV4p)D;`#G<-M*uieaTLTNN_`OUC6fx!MWSU z0D2psU$B3=J*b4ed5~sK^0k`C%j+Nk-qWWWDL=Gk<@%NnY5fe((uOauF-OAQIF%J8~SEi>|a^^m_b6DN^L_w@@E@si{wd$1_EpQpCXF~mv`PM1gq5JY?X!g_9$9aUKkTL8J9SV_ zD4&yhL82tUDII+>uxUU+3BPcfUO+=>NbF&q<_Tt#8v_an+!n zemVuM{YUHdC8>Fa)GWXn-4qgjOgD)-e6&?RqMVz%MS&d$REhIP0Tw9)sE|A##0rHP z>!kZ|i2NOI;e)JUh1e~MbroAMODr^>_?!GRuKNa$AMl+!Nq!jR_alpN09bnE51FA; z_Vz=qJPyM{F#8o30y-~L-RJS{LFqoZ>}z)p6TTFn51mA|2evbz@Mz22u|N5K_)fD_ z+1Of2+m&>^5=HNg`o8y-@;l$TM_%m9@qS5~oudzW3{6O+QpdP|xn=M;)!85x(UvA+2}|kew2=GrIgYjCxR5Ht$R<)$TtG1b-8woJ>yjw{SnrHxj_J!BmcN%(h z=hk5ewm66OBozM5az8#T56!`AshRgbsd4g8TgP9LF1RMkwU<{*#(yE6rJ zm7we|9im{&NZU1q40?7vg|omP(R=uvh*A%n!GXe3`aR$8Ei5tK=7HRY(|V%Hl8FS7 z+N2CaY|I@O+}rH{yPt1$XT#~E@a0Q*F!?F#3ZNyW08xmtMd}awm=y3rEo@J%4B*(& z?wgxm!!C4Lp=Ned}$JdXQ7+*7X4X-xfNn>W9tR21Yo6I&VnIHs@1d%#?7JmO%3Ur=?^>(>EeCOZm4O)usF4bX6#xqR zrR=j}GTGl*Io`Uui%*&p+aP^cP6x9CH1NsDD|j6!g=t&x+Sg-Sjja)mTm9ZsdK{{x z6A&}Mu+`4A0h87~GZ6dWb5#pN$sQHs{ZRL6nLyi)R4P9CgWC_D-Nr+dI^@hvDynA(o%TzF*gEhczgNn`$+L zl2|b->zhi7VtL*clg|dOb=u>5ksm}qzkvf`8hI@mmMF-DeOzb`q8E7o4-jg!%J|#n ze=Yu_W3yTaJ_(NV$CvwQ>yyFxl*)=sqMbSr5mW(h6Pyr)rg2=x_#u7!r9OsaN)(G| zlcEtGz1Exqq;Eo(WC`e_=2X-XnH`bwJm5D(Fe%(QbC^DPDLHBnXp#=eHQIhLH(e%} zj>h)zT?pzv64;u7U8GBb?Heq4xK{h+>TW+3agG3HCYwO|B+`s;Yuj!USMyQNoc!}N z^kO=HYS|BQ=~{=GfJZ z3lo%DnJ?w-cil%|YjprnY!^HJaJ}()9k>m!u|Fx^m>`MRT_#tl)&#}6{%FX1DCQ1K zCjRah!h%CNM<3sNssO;X(-N)ZY*!B}if~Vj^J>N8EI8EQ2$UXLSf z*q1$;eE9|Q$^`7gjC%M;d(*@7rjdye?OdlsgFYQLS@M?QQ<}WsiCwJgw9DGoJDLAuk;v{cQ&7#>9huRRIq(+Y^u!xcYDmGf?Em;;0b9)IaEH zHKuGyY!h7czP1H^o*f9lfA#T`L#HkJuesXJVZ;P`>Ms=5 zuft+LM2uGW{zq4q<%UemKj$lrw%d_>f~XFf$m~JOqExBs`v3{77Se;wSdW-$uKJ!w z%CT9?$5ra~73w67Z)k^8vEcr!_%%Km^4s*qkfMJ_+ZGWqscn9e-;o1i^F{>z??(VO zCcYpk1ttSuw9PPA2}M;i)PR}cex3ID16xhN^nXa=lsbHq=hx_S9P(+!qG*WliT+d^ zB2;Ddr*!3r$I8IV0&>(Cq>6;lMhL$729ACXtlS=+YL0!YnVB>aSJ;(B{nIwCr!8PYW zBnrthc+U*?_(K71LZzE-y*>wToU-$mYTN56$ZG_1dkxH;ceS5fG1zu6nrwBN^r zbMxcebKh}4#=BZs&NwRhDe!E#xW62n+fQP`L$`0+dqF^v&s7R3e+U_@=-t2Id)rRq zyLt3y*m*wrO-iW4E=#-5&7BKWAO%x4W-Y3hc7O2FJ_Glm!q?>?m*gTT@9)|&E?SBR z`J8USn_Inl@LuE3vpJ|A-Z$^G&(VzoYeN(hMc!Imc%hDuK~GM1w5t0{+1cFWfyEi( zna2ta&*8OSQ?413yw8`rwCwk!=C7d#37U`af~OQY$%>BEMDS%&Z8S6x(>+U(yy$NB z*fjS&QMrGUlW}F>SgPj|tWaHbQ}=y`^obt|R9M2{ny^1t;VmTCQkxR>c+jpT<$jLb$@l+8Ip$zw9r=n{r%urN6+6TRTuFZCB&ACt~k8=wAz#O$GY& z#PrRDh%QIzc0QFs=e&qpC0nVj0L)))C~etx_hKI`WpQ^`Sv~J|@a)7xUMf5(YaIbx zsM?D$aa|k`9S$nxj7h~`2ms47{#=JKk>4mi*0!B~cjTr3MO!>UphIzGXd-=;=>-E( zxV?@RkvzkFGk)=`WQ!@ht$6FZr!w4#&_(I#zd|Q|Lt$1(?-Vu64;S2&4$j;i=qhLM zQ?bzP=nUvxE5zS>N_?Df8*d(E?424zA#TPJ>?6!sjC~3eLU^#@r-I`0XJGv3Z_20> zuzfEAfOC$nrz^(^0l`0m-R407-)N~E9%Zg)BcV5gqu#@aMqc!gE4I-QfZE{-2^LQRlrnmoSQV9GBY`|;M-OGks+PzhQ`Z&k+4~tZ$bh!&{wpV z1UVmto3c67@{{)7VB*bi>Ul3*v&)-cGv)d5DJg%eT)qaTvnO4@`CXD#OwncO-7jW< zX-kg$Wb z-?@rKU+F(YB~4AiFS#XMjW95>I^l#)Ld2Xr%`wh9@=A(PC zt2&J3+CA~!S65bx_|T(#AK6#gXeSLFxhsbkell6-Dv91hqv37c@eq+}-hK}}LG&|y zi;q2Ls?&aY*Ww1PjCkJ<4k2|OsW2vQ7rs`Up72>gbwtWLH@;we51A&&>X5&;MG}j@ zVl#J3zEC;%;dRnYX_45+8}wY=mXlHA^j4l}Z;jY)WcJZySdosh z&LHJ+{rYv{5vc~;6sp;!KB1s_l~J#QodK*zARvPS{nwxC$AjyjtsPAy3>kD7(;VbBr5nJXjtG*4Q;yUy+3^VrfIoebABLQJ!t*LZCy^_=iu=#TAx!{{RV zA+3krx9oKlql#e%FVGx%ZGZhq&d91N0?LH`%?D3nt%qy#()$_?_xvF=``V+Vp0vQeM8z!iiXE7P!p6*h|YF9W|e^v>XUw}X( zLn#8f8OK6cS)ndFh3g|1=D6^=y^GNr5wC{4MsZnf=`?kb&qVvMJwW%+f4|S+_vpDa zHcgOxz>fV=)N?9s5wol~`aFI2x#W#N-WJE?-sX?nL5^Od)tKMg<9MJ-;`ou~6}TK} zuOr^?A<3xqwTGIc!HCz>VnJ2SzQ}XFABgokryH>OgNwr6pb>O>`5LTY@BkQe5A-c` zb&KW1X?8lWK<-mcgA9gw4M4-3P>a6Z89SwpNF9|sS$TID!i75ih@rMrQNIf`aKKb( zp1{%>_ak^;T{6-`3)mWJwjo%tZGVE`j+*_ky+VNih3k8P1dCmc@nuIUgS2H9ynwuESpavlqjAJ#RH_5rpKLh6 zhVJzEEcE59%8J>i)blIBQnIQZ-M4GrD%gYA&4slwR{I*@bLT(!V#=E)#pG>Nxpa(#LQn9T6i;4|KY1vLJOsYX=5b+!w4Enr*V%u=%ssc*)D4P7j2c*XO z>Nvl>s}J=)yyhTqqYPP+khwR~6-+1(IZ?I@t z?bjKF6Ofy58u&3Skz8JKncuPqiCXTe+FX3}T}DGOp-mkPi3NMoQ!aDP_v#0)lEt^- z*6*qUk@?xL36KAuei}Osz+-x>-XRPVp8o5qJ2l9ZFkViGM!nd8?A8NRR@RKQBp*gU z!9}!xZ2Mz3F1w2qAx>`2bf02wf{U)Y$cbatR9pQN*t%=_-0Nwm`zDo6XdXK9NmEQe zo8O21B&N?rLWCm_FEo1{SCj>%G7axEcLbb30ue0#R$?rE4U)&)Y$dPDkkXFmP*5$RvAJkjbM< zWM0Hl&|m-q8{mJ)fX(X|-IwFrmqae2O6 zUNPo_$aW|HJP&d@@wik3%(3ZE~-(FXAK#%Eu zU+tl8>WwI8GTTf3i}f>7F5*p5{BcSdgYp>t0hsZAGR`xs>G;0oQZ)~VGK7=0UWf3l zT+iR2S5%5uCNAFt?YgJ7w_KY5{MK8dZD3O;9w^!#z5ipsd)H(SW7PaLjvBxV)F zYVK_WFyZ8y*iqW);rBS9?6Ez&}j5#Xn;G>FjV+ zsUu=kg$ctdjDqS70qH6i zPoJWrZPc6NuIc7l(S7!nwUwFX6jn87sb*z?>@v9MR~H)~TRg z&w~l2#QsO&&7AxplH4~jRl(b?`{oE?K12ZuwC~)jpji+Z9ivs-2!x|xhN{MPc_^HD zIKl&iFkvfvyy&tHLwLOB{xNwveNwG%j2xZJshUlu*nPGh0W*jCvrkb+e^HCN+!%Ov z;`WLQlCaLQ{ghs|ZE9IE*ZR-=DRrpK_)xe%>lcW&J#J%skNi(4 z?+fg8^q`7{U&`_IW(jMR>TsMdanZio0GvHx(1p(){?gLE`wj00#JK!pb2%NQw_$M* zPl(JOAvsFe=ND*^Kj+7P=t$gY27>;mS&5JOKjY#UQi0ov^jj#fG5OfUe$gb(T>mT% z0)(k*!wv$R*b2IGNn?(I*WJpvbsy)ATo(S^!qCV@gt+S2g&5@`diLi_nb5#8b7+jh zcqU}N_5#}-k-_DIB#$dj=3$!KOaB)PL}SbgoI^EFPJt5z>yq;1pSs(VKfrW&(Zh(6 z9*>i&+D3ODphem=&3=1lV>_h!-;Q9>SKsWfbp`Yyomumir_plo#(gSZo8LtrPP=aC zq1v>YO}}e_C67vZ(5`Avob2$#7+?W=U%B#SuJRijI^L>qDblb0hE$%0DHjVx%9IiQ zcSBiQ3vTQN^ogQ-J*0ebGSV3hXa*sE``RbLP-cn(M-K4=ZWBg~utyQ-B1|%;QM9N= z@ZxGoN3Hl<^kSZG2l|`L!Tg~3ANI^4PABlv;jFn`pL*0b>@-K_=^<&vdvn(mer{Iq zG;P>-m~($^w5G%1RThfJh&(L4Rp{5DXB&eQ4>Q)5CGM4%_jvmS$OunTwyMV?vX6Hf zTJ(&o1G3Isqs_a^@3Xuoivy!LAuN6C$*ppb81=s+Q*{;?2j4r!%w!=Qb= zm^HfWaWBDr=HDxqzKXteCY#hd*I^QZC@@-%Lv0ZV|<-x#wBH^sfux`ePjp**nj3<7ESvF(Jl8@#`cHlsv~x%>TKtz}++(_2F(E zsa|^Dg0P+eb~-S_^~X5}=uUhl2tQ!G(Ph6_INMkWevtqf8v%8*edJgc01aNx>Id4` z*Y*~HhOI&5fAxsqy-J6xS^_Sjl>=zXD^(p&6;y3<=v;^*nv&05^j{J5aS2HEPN4YY ztFFpVtaF|RrE_(J)cke79Ss9*`7OO3GAL^f3|1Ae?9u1NW{g20Y_|e8N=Yh0*Y?ERgbX%`4mEMa7U<~2E z#r?-Ux|6V%Q;c&E1%ws$ABFb>WCZ|cf+=cu0$(XKw8;E^iEx(JvC}>Urb_Xa7}Z z!+wKoMT6BY8#5>WEPilGzwZ&~nI{wuUmYLNt=hZD;T;PBh-u|t-uc*s{axq+Ec^f?ZASzS6{$eSkF2$4b7{`w7ut&(^bkA9*kuz1$8E z{rN!j_An*HW5360bx>ZvY|XYPi=n0xM%klRr7-D;ShrT0NGZc*q}l^9g)=S4OgH0j zIW*V(q>>xqcg7g_9X8*~z|$H{DH_!ft-O36Z4@U%twzJ$d%pmez5T#Fp(<~4q2snd zDJgNE%yXhi7~o0#?0IDc1WsWMpb`$z zN9I-yrl78$75e#Kul&92hRa=8qJ}kN_p&3mg@j&(#XC(^FI~a=wOf3h`ikFi34rZ* z4(GEErh5yQ#x%%sWpThl!m0Rad0J0G2|awP=R~{N-o*Q70zDW!Zk-o^?=#~}3G;P& zqanzs1^$H1*Pnm2_5$*@BbM%((h0~Q-M#JxfXJW}L9g;j*>oelITD)s?e0`47#EWx zwXVA+q+9R#uxRDq89RjlXl>{xw_cd&2IRUkx|sOX$)jNd{-ao-e9@)Dt5s7%QN(5I zNPn9}8NEJGp;hf_aH>Ex6gO=3;{Yvr3QNK>c$}BvA~jodf58^&lB{(Kf{k}k?ys0R zlVI@Oz03NQKYS=SUNEakPo1M0}-$Y)14`{UKy;f%Bd&g;Ik4?$6+D@bE*W*#`S z`D+vz)eLA`r|T5bPadzl>B8aO(UE)BxdVv@?$8^Rwuf;}mkW(uq)lI4zE^)nB{^jK zecR(~xH)?_n&?#U&Vrhn@5|v^XI$c*rE9`=kiQ)Z9g=;Ik%PxmZm~SWz;&9pgB2dp zU(vaIQXA$7LCZieL3V=HB!Hs)VzemsRio2A1^d%mFsh+T$L82ads1;S9g@!GrIP@z zjH9{~dbNQJ>LY*(z`o{^wmCZW(d7>De$q_R$2l;FOz6e8sQ=UII}B}($V(wsv4Ja@ z_Vz`gond+hjk5P8oc$uNcM`vV>jMWpE+XRYdGvL3^}lP~Us4wi?06~{D$j5S9*TvY zAgNvfWoThJD$e7v>bLv%`kkYepXQOprM2somCm`NEqeT+_EW1RYGu8*_cM_We8WL_ zEN72zRP%f=7xc7b&4;)7#L>$73g7+(5KZzc=kGBJ>^$WTiU(oQ-!r_wQQ$5P>$L;9 zRCP|#iEAI z`4e=@LiJTyrsqfUIS%i%gfMrxRhQZMh`|k`RypTwbtv+L-sVSJwv^}t`V-=x#oa$qtID$HfRe9qkSoDd463+XUFSgg`n7Q)IIbS*hjQrGJ7*Ua>H0kL-ecCr(?KY=@{dy6AW(HzU43l! zO^BX%Fui4tL>Bd?DHq2r3nyGD{`hs?{Phcf{4Zdf^-hVoZvIpjXyNU2zn3PtN+KZ{ z?0&!YxI3=C@2vO=#34;-01-^6R9L*Suov&{<9WS92e;Fubp`m0_kRpkaYg)`+2CwT zx9l%&GMsA3OaBXxB?Dn3?P=QFz`9VAGAxC{wf?o0oFBfZ$!*I^(PFfG1nJUXT>VJW z9vtNjmy2BqqqnlVd5WfU2&pY~l~KLDML@SP@V|U8>=(K4a}CE6q}{6(+5B{vp()!*cnNe)^oy$CAP;dfYsMhO6FiOsK{M2Ql+NnpPBn-vtc*zgcpTkCRw8nEN z-J;sPc*3ujJ4t)Yd*6p`UhWb<%jfki5z0HU<|dZAngL(7<4wqGJ;k7mh&_NvfT3A` zPb2)Tx}OXBHRQ(1;v{>hOo$1PE0w1&Y$XC+>K=4xYW*GoP{_g~F1qtV$ZvHd>(FOeT-?yEV+aQXWK8_SUTk(B0PDk`sg$sp@}d^d$E^4neKA7 z_Jsuvq}QAo&(IMbeX&9{E+gv=o)*H)x+wE$jL!Fx$ zAiCaC`|i|ag#6qGAw)mYk6LT)U3h%C+X~$6_1K9|{((~2l-ccxHLCl6_hmeso-Kx? zo)EWkFUjKrEUC*p2i_d--w+wVNr)5p1*hcz-P;81UqvmYADm~9M-wM9CF805@ejBW z?Q6XzeP2vdtC{u`{P5zX17lb^%}{lFelUYNCL;#9639p-kD3J!!t8s*jk+opAX(e5 zy*%cFyO_o44}S3ct6hjFeAnn^9%`cgeBz9aZ8~`!mTI_bE)_u?>U!aS4V=$Vk`b+q zVgsmH<71p;0*Eb%PL(cb-Q|7GvJa{`if%={80)Kn>kl=Hz1}7`>K85-=?#8Ib?m_e z2{4`GLDgT}OEK>=X-~IPp|gPQgaqK&Fa}TecjM=XQH$@se;}ME>~_a_3MXYxVp}*x zo(ojvm19QFQ5W+sx!c$H{;d7>?b=FYxtqU^uBMNfDT!ypUQYF4n@$AX!w<%qVK3e* zcu{BH?(|h&g6y_JA@O=cadV9wK_hN;32Uj|7M~Ib4JYbP7Loq=J*!=_;GG0wOmNh` z{^JZ;siMoPLIw#K1oic>$8(U+Uby>rU-my110F`*-mFitGL9u1_@cq33WSTMsd3_p z&@@?!w3Nrk0b)J-ibXrn#l?FYI1s?L^mK*UwP{a@jN%U-K0Te}_p__#p+YCGMaO-d zo!s|I>6OdRgG?^=cY`nVXtrZbY23r|{9RHBMRNg^_DMIrXnv*a*M&2UH^FWK@p*cx z?otY~gPD_wQfP-%FFMok3IEs{V7k* zp!Sa4`?Ik42MMS`nJc7vw%q2zCVM~I^ZQd4(3Qk-wU?`0;-_Ww=7GMAIbxRBuF>L@ zbkTVBL?Xpo(mOZCaOpxF!p(|^v+1$Mt}-MPpkgyBELEbDF+7e}XLA5C(Nc7Wh4HM> zk5jzYNKJ-%^|BhS89X2&($YAOYaMrN@-%**L!e^8(|%8fkhb5 ztJv3*J>&0!C{K5Il|q)0;f{#-=Hg&mmm}auo5iPYb^GI*Sb`#Rk9sjb1+nZ`k`d(i zyVril^%;ft^Ghv=Gi>=3&HME4SLJ>^ULxSKPLt(c5Wpx$DFlKe*8m(f_>i;-J!Bul zPX?`y9?m5f7MQ){HPM0MwMQ&7-1F`O??SALI0UE2u#{v z;+D#VtM@F@;k^eTN*KWuN_}}vTCcOoJuZga<{l67+ZTopuVr6Fr_f|_sPKI=$8xXy z?Y-?6x93y!1iT>hZBPAScwiXeQR{OQAY^xGd4loZ*P@zZj97wWz!t*OyIiesJmKU1 z2u)oTI-Pq!un*v+iOt60lNbCGkFMtcQ5M6T-cD9lEJr}xBthV>LC(JVQy;t^y>(6uzdBHCJW~8bsArQf?cZ4k zC&Pwe`|We$a2CvT4a7a8)}LhyM0{$lnkK#?OQP8DooO9QeIGIO7RM)L_nL7IA=v`U zZc(o5gDgSD_qz`|-S1H{12%5zDRC38?DyxvHFJ|Gdvey?4M$cB5t9{8 z;gKDfqN<@(8x?-hmPGhexV=- z|E-TOgMU^|mzYxB6SE%1*XvD^k0vC!D?j1&H?Exfa&aGj3UUqKH_r0H^n?b4cdwQO z4xg78tKtj=cpYWI6WRnEvr_%u)#EhL^UI}~g|@Yn;n)y84C^!8E?g;aICUF2wgNM`n#_vmSxnj@K-S`@> zXS@F03p#EFcbVT%3#n&frcL2Q2CXdff(`U zG+N#!@XsV(A`0YRB+{>}Vn5W^HivTn*(ofxhb$!|TBDp-THmAwhxthHrG?*1*DTcs zl`$Whv8vF)*Q5Lek0!T`51Unq3M zeMOOA!p~a_jb)UN;8gv#`8yxY-f{D=Vj#O{md~p7nr>QLPh91r_)z=KUpsSsvMEw= z?Oj@Zd{CeTJ{C8h#Cg`_4dPo_j9ISm96nB|4b6Oue5LQE#{oV+nv~B>Y?C+fzts#- zq-PP5Ua)uzA@NNYhqbJnr-nw*Zj62(fSic-Jo&osWuOp0=A0@rjT+r2e{_@Zr=K5T z5TCi-B|(`)^L*NmwN>L$X+gv(*wo#=720L*39!k0B-SR2&()>to`Z6<(T8rD>T>=8 zsNTgrY~oXmHlkYA_$wgc0AYL~lqPuBK!#G?J^`!fBV=qS*AmgR9o<2`V=CS!=sly{ zc**Il%&wqk@)Q8h{>#BZ3Fr_08ID_z&3M!oPwlhQi|_+AiEj4!r0s~V`tkt& z&Ho|J!gu)iKXVN}hhh3@kmh!$4;OBf1%p80mZR1*RYSEV5R|Uea}s_$v+Jrmeo`MRqM`-b28&dWbO^ zX0H=6_5fI`KRbw~dRessc=QVf8(xWNtT3mS`q0{+z1=#jJ6a0n%--4Yt)Fd@LmETR3JZxI z*9=bdp9fW7eRXl>35;^p{GEU-4#Zz|-G|Wpis%@qg!eJ$739t4U3PohFVuCm9^%Ss zYk%_GZ}2;BA+?4_=6Ana_t%(x01iphGY^C0AxKRj-ml*+1awh@Dvb;6rByKG!ws~f z^5~4`RoNq70%}#EIUx2j^0ph{c*pvvc3s(IejGAma(BTOA&6ZvG43xD`5YQHhhGh$=!_j$Bc_oKikC7iu>vwugeVjskdwIB>ZC@rdkWMEfk8_F# zIjqcqFqReLw|;-cow1~yPYQ7mUwmZLO(ZpVqYQa@91J9cp%ix{4>{>$!ibxZr_*~Q z`W5|C%uq#>4UfqAh^Z<*O@jb#tr))#as!9s%EFxMvjTN%%MJl$lqbv*7YRTO?ka9E zQ+x=ug@8BFKq7Vzp0hBiMPfY@T$d@2W-#ox#$SjPPszeuAL~6urKh=TdVXIa=|pMl zARX_oNS$0y;7XozlgD1#x!?&gbu8vysBOng9sl)fZYPD!p?{&jC zq0gOuxFUwoZa@071?>t;kOK3CV8O<2)g_fmREq6dJIM5}reOMHdj3^w`0;dqtiXYrW4C`DjfdD*cjS`-EGfwIvje^#(rm=Ng;bMh|NYr*J>QaZ+~BM;3n`|yk4!r38XqlS;I zW%?zd~}W|yFT1=nl{Z^3wS`k?SHRs%nKC#rPja3)gu3#jMI zW+u-uVjpq@knO3n>l`F06x-moWKvdJRB=kxFo(7FrBpV|=}&O4(tlUqc*P`DLQr>o z|6Bv-EMPF0F`)aUNvRE>75@2+(#8}a!GJ?fm3%*@OPx|;fktIEtnk_q;a|TSN5iaz ztmAUfc0G1QYMT&n5B!#9#?{8t&tCY58@6J(bwk=e+wxBDE<{dWxDc;X;4lShICi>S zeo?rohu-e4d3j?*;tw;FLT|}AkNZX1*N?|ukF*!)r5#uM`%Sw$bTRPUEf2Yj@RQ)J zFU1#F#^Zja55G2dh>rq=^K7h%7fvU>MA=Nw?Dw&H z`gA%x)e0>^9BD50eSb7OF_{fcdv2u#|K&E0pWPXv>pUWkAo`}-*M=$Gs;MEXe&VY^ z#~!GWSV&M@yJ02UiD?Sha`y*BILq$|AgnWTTp_Jn!|<}|b~zoK?G}h5Y9h0hsrW4gJ}0QPK3R??I@ur;M)oZph11Uk>K4$Xz923LJ;QqoIaab%#eJ{ zTa%_Z;_a9MF!qA8PxCWp29LW8!v$PV*xK1ohy@9|iOPBXjU#aJ5nWXt3g3(ocJl>Pze9qE|8j$WL@RT2$?6<)J|O|$FIDhf^5 z<|C_H^s8fG0O82~L_*!tvn*ZbCs{6yM7rgi+w#6?2e zAw1dR?GM@ugKzon?vY0fyIG%Hoj4L-HXH|u$K&&{%ExiE=itu6o~tLnl~>5UvED)w zz&5hI7U%QB;&`3Sj3N&&+v<|AN}x`*-AJ!lakcb*jeJfj6^`AWPEB`{&Q?2gO_IuxkYg5V7;<-ZXZ5S^j~+$wGDd z72ZEh{HL9kb42K$#F#?0NZfu-guOPQIc{;&uMjZ1N`%s}7Q2SOuiBe&q6Lfl1YR`$ z(;tTz4qlM`v2ShJEJx=$vtiS|!tgXAcos0^Y#-Hl<%7oS`A@yq4mFPSRpERcqEyA6 zL`yeiSY`c6rgwPQ|C;?)QU#G(KhjLn`B@t?6F;1Y+B&bcq5U;o-A^(2_wdkU`V36R zbJRPUEWng#vQH~s^8it5A_WigWs+doM%3#Fp0oZ#g;B7OKhgp8i6^Jh5SBg9o#_xF;vhT^sR_?j7e%>C!W;2-6pOW0&^37Y`qksGf7ryhOlG@<<8m?zoJq&bja> zkRm=_98p67^hsl0=&&nlV`;h%ojelG;+gao-r?_Dz?tPC_9OkxTAoamYm{_GGk#C(#Y(Jlw>A;3bLEv& zm#kh>a5DtQ4z&S`SBK6D!o5T+42zN|wFG7zgoywGhJo4h9vWTdo;8Yg6;5`;^u7Sa zlgE2L)7MA|jdgw>`S49>85UH9E^HFi2dz$62D#t9{eq-d24Vy2aP8O%!-j^fA16IK z7-v*Oj%XFYVcE(&elkWcIi6j-N4+?0U5KoAH3Z{EQ%oCz9@0Ah^=jParQn-GkMeK7 z`xP8@DRVBHA%>Q!-!Ddu((cm$5Y0XU43RK<1>O&Q6#hQJD%;|KNy~T-@Z~|p^!NQ5 z#?4XdjLU0g&yP7sw zZ{*+O4+NOgZUFf@(u3#O<`%C{o8u({LvL(VBv5bRH(uK!jzq8hk>1Y=3>3cM15v>J z4{T8>K_$0ccSyu~59dxRyLZ5d(jFcS6J*^sU#|0I5>F@4t10Dg+NKxU!x?dQ) z5~BHgD`U|5_pzV>c-YREKZ476A06^%y=WVYOY@7Ov(JgZGxDuZGMiwi%&A!I{)YC| zWv=}GA&U?C>8Y(HG}AN7^WbSYpJ` z!oN5t_&slaG>R{1`=-1yN_O)?*pZxu{245dJt-%Xl-lKb6)OYQbCsFx;}?TC*DE-V zNA5gKJn!Vv_)`yxU#2&*l9?9`6h7=ztSBk>nj4XyyFh2saU@DKu-?xaWa6Ov8prS5 zSeVQ`O0eBI-25CfMWJfQoa1J))gIn_3H|BV?P@&us(WnvlBsHgH_tvqREQ0QU4~;< z52+8HiMfEBtHVZYB@D&<3rPKKr=2G0Qhi9abhsxCbKY}VF$fqFSfuXlCh$Z|>JBup zUIG)6os=sHx1)*XHNG%8h&ktUui7P z88gySyIy7zCO_a0{{^d%+dZ~Ty>5_I%u_4p$w-jKEL;Y5+L z=p;u}>!Rg&V>D|)N_@IJ>XeNg?=9 zF*=JHe!$X#P2ip&X|d=O0&Hlu^K9L>roG(#{zQ&9C7~~N57nh=KFIeb8=kOPZo;#h z1Qf|Vrt3}F!*Mt@cUcanTYSi~xdFmHvLzh|%qb28qx_MdHbG$P6N1~E8(89K{0oS_ zbIk|<{UF|S(!u{+&m@GYPZY#xgp!;c=djK=_)y+xct1hDgU4S_m0cVC1p|yqqYtXM z#{nL_$ho2p_XO(IH-w5*a%NJvo(WcQ0tgu3nfu&Zt^ZR{E?Bepo*w7|BUd>gZBU0N zt25R4T_$MgsGmC#Nxp8ZpNB(smw2hxY(A|F`MA|g-#)%q>J!l9Z5O&ni6oDiW^pB* zpwI7mqAO7ujVAGXxLX3^xSlD4tll5@z8weFRUP}%tl<~#K^csW)x0<>!R7QLoxr$d zx|6ToGCASx=Gw^hVY=h%oB;*pGrRJ4Y1cAJo)EA57Crom&UGajmsLBf_d!4KdmtHs zMOU4B=VyGPvp)CVhw<7k+P6M*>OgA7Blw`tzOU5XZBDjIg_*=~MjR^qao83S^HtEl zJp8Hx!nQN6)-*Z^lhHCGo9kayT37~&Anf#umOW0w4`PF#=)~{jyUd^k-E;AwJ^9mG zLhkO>sgig<%8?<>@HVDF;(RMxX)wSW26!*iqpM`ZTjcL|WBREQS_55SZ7PJhNYIp7@1#3FDbhMpEZLB}^Q2AgH-T@nJ#^&*j9qg!~cS z#jrK0Wi` zk?a$n(74+BG#pXP(;%+`EOoy7baR=1JD}&T+`WlPvIi7P5q=5g@haPPFwo@m!R0y* zunx!SEF_CQ+Fs4b@SH?uM*e2nbJj8{TDUjzmS+$Ues^oXB2zKR@=vKh8cC@+c6hyu zZJi|YrMk!vzQ5T$;uZ6QV|2y4t}KeNGSKXZvoN1A**ZU60tbyIm+Lr+XE-L!@7LtO z+JQ-;Zat&>1#i;a!QP_$|HzEILvmKBds|MLZ#q8@HI*P94-O z{dG$wbLhvidxh58gR{hmZGjT<)L9K?SOqO-1+!0x>gkaF`Gbg${d;9YfAK))@V|kk zaiUi-@*!;CEes8y{<=!j?WUG=%Xy?cqg_%6e++p{tkv`^&8sO(&@cGp@?#k?+Vvo6 z5%k!=3~<_zwA`ZrcOlDYO~LfJYjk;Mc%Tf6?L)-cz|)g#1SHz!#cc#@5Cr>4JxR-n zWk5ft;V&uF*Ew%FK8KMpSS)?}a7U;j?wwtNtOP^F#FAJ;n5x#P=X{)QA-)p+NKiv6 zc7WX6@wI$JFP+zwrFD3C?uiiI|_cdwW za*In&E#Y3F+(?)PrtVfzOGavn(wLV|Q)K&TIuHRO|g zi@#hVARM%&<-;sB!XEjz2fN&G{wd1utb#E5EX-I}+a@Z!Z8ZGTM+x0V*QDc1j;J|> zkZHW;KrxfGW1dziOshKfR%FlFPjh_lg=bUJgZy`yuAjv^4SNA|$h|i_m#~(6Z!?jO z5aYbpHY_zv9F1@EK7FjrVYsNe2;esT4ai!hPDF96Bq#z5c2nZp$0~p;*cAJ{?nww? zKYK8HAlu=y{wg#<7mx(QK%P{d&)33ZTO#AK5ni{K!d-#$pzJZnt{bBa!u023On*Z6 zIJDqO-Rl({oYWs*#tXAb-4}}pcw;!pH!qw!%xI4q>@B=>d*^YN6g3WtCo3QU&NknB61a1|}KWOH+#hgQM%WHC$8r6o)JK z6_V)BhEi=SRJPSRhfB3~MXJtFQto&yQ;q+$OG3Q*t6(S6u{Mh#kQ&J)@zortamB_V z4*Ky z@OZ-SgMPdHw)K>S-*~-08B8N1s1y_ILt{F3bM<>}r9MTn`M8OLz<^$D^8iB{c>_cY3pKw_1X?A8a;1G?o+gO%9enp zg60=#Fi?Cjrcom?05pL9`BA9~JM`a(jio%JG3oSdre2WDNMZ04{4uC`hzI+9C{+dx z=1D2~k)+u69!rjBFYU3L&cpUH@bPNU`BMZW@EYZhD3Z9N*d3gD@NU5bBj77~eXYW} z->kP_t_hmN(KGybA+*0DJ}IGt#vzH2ewnP#BZY-q$F=a(+q|gWx%(8Q)wHK?9G1%A zz0YWCFw1rvCZCv`euHZ-`G!-^|n~-+13Ui8z{d23NAK%>rQY1QneQJ-? z7c%Owz+djubk*CI`&{niT7!Qz>C!Lfi}*FyFF&sH6$)!k8R(YscwtYN7z#h zaDnch-F=uFVnLCoTV%MvP*(N=gGqf}Ps8K;8gjjH#7W*;FWDdKP*m_!ys|vflOskA zk=EZ5?s%XU8of$)NA!{a2J&j)IlWJLpts5AF{mciS>RHixpqlAseMZeW(fuG`Dv^sfIitAr-KK|uiUw@-ap#RdNi}Sl zci(+&_cY9~hmpH?m6q{qpD;G}Ya<^3=f>nJJ*l0PDZCEJ>qa%7_w={K?{8jcjnPd( zyKS!jqAz^;t)AH#Hk}#7303XY67!zoD`_jay4OfL(JalrwgjSbBwz1osT1 zefru_>c55gJm|f%=G_TS3Ar&;{EdKq7yKy@n8QZcd>AXPI&n93g7`iz2PPiX^L3~p zo?F~4%dU@`>bZKc1jGJ=P4ClpBXk$2ANvRbiuC>n`LE=eqnzBsubDhW*Kslw#c#cw z>@;P8ExbdrHsTwYl{&Y<^?Qu2o*GJR zJhMG+R~B)=aygTr<%wK(0mk_34&BB*&#}H0(-TR!6RWIrl~PaQt4Y@>IOy}^yP2zw zNeV~7?6}sek~eW0s_5Ko9_zC&y^Z)lG2rg1Q-DzJ$J_UHr-HF)=Aiy;t52uQnW}pF z_}#b58v$R_|TJzCqCynT+X1(8MUZj<=cp`RJiTzFK7M=`sYx^9p3r_BZvUW%&X zVLSj8%C&MB>45+c8mIkppXse?>~{ni*R=I_T@)Wp;#GdZ{kHz`yt{Y3LCu;CTfJPU z57Fq4UWHcPBqGE@lc zy`mYna?UW7v>29{n(y;@5n0KyyZNj6QE~G3MHR5k^3vwyL(4Ju3TwbNkB&UR{J!>Y z36Z+l=iSr+zn#v&eZ5mAvuxzf8)>5rJ|24-5tDpU$d{>)A2mJD*XP?fsZLFJqQXH9 z0W0{$qa4V_Bf7b;FYkpV8|3+W5b z;V2jclKEZx#-tJOI48mBOa7G+q>L$J)`AkbZD-}aO87Wi%((9yBMPuIbD1adk@sFy z@vS|e%;&zl=s;%c&4DQbg;PU!-3A(jd8m;J^RNf_~e{WC;-maKxSRJZaLSCxP zEO1Ru=q9^o4o5a!|x_1u<&`8 zKMPm2t_8#BeZaMTK1jCAeSX&2T7R>0@(Sl!Kl}{xYY)xGK1RpUiYV`)P#2H)4fxq5 zshS=B)J`I%H2DCbc|}X!yGlHwdh|)aVNU(P!=ViVfIMM=UK8BMg+0;{UnGW6$z$vf z+QPIw(>UAuJ`iY+sEI++9sUQ#5*VZXM~aqI)K-t8;vOZjE!7 z7QhVFFE+RZGsev!V+dUe&6)aH$$cj5d>Vw9$w4ne0P}x@5pi8+ojk%!p|qJ-el#v^#elD$4&aW&uzq_32H0M{9}F6 zh(`lI8wnN^=$QY-Cs-1nvjg#m6>FxI^M33FOO8AZ_z8WP@gD~IGx~c#xE8JdsjWvu zi^r>%D3o+b3@d*OXcf_jm><~(2hI^x%6m2+%G+cigpZ* zz+bJ;?e&`uG;#xH(fb`h)e_Ii#pm4pDr-=G^$xntvDAJ#P1tatC$A{pN2DJKoAByC zet;8Y`AB|i-#Pj-a5Vde596C2i3`kOyyMo##p60u$~#mJdikIRtvT0=aJr#3#As42 ziBJb2C2J377V{^Whi~-3T~1H;g}&=|Oeu#-)L%1XWw+no)TsC2iR2M^2#?L_-!B^V zgz?RvZd+M1;_)^7ZbWG3F%(?PhsV=SNIcz53i#(0TL085(k zXa6)yiU2s{-DHvT?16OM6Madrrq7R??%mi;UMf%t&D48f@n7FYAq6D_DI))S=&$eL z*HGQwDK7X;c7XiR2ck?=&S}UOXHPfhAwPk%LQGHJ0JO*9Ksu${*WzM7E=wrrk=)_~ zUbq*{gii3q+)nsJqnDUtNY{M8_!=OlJz)k*^o_J^_j<1$GqAGsORDsJseUrTp94Rd zLB}-q0$E42FYNoV$GEWcgSzPUk1cM4HW>q;e(LZwQgVdm_FTWNd8gO+l3utCO-wuy z9&W^z+1(zL6NlfBjE!43(*ga7i3=;0Wfvt0_9alN=7zUeD8(wIVj}I8+36+L53RZVw>+ethX646)vn;*Y9U^K^YN-qAJnV1e9~@d&b>lq+Ls6KD z@Pa_BT2oO_ZW4D;&cyH1!B)Qe%Pux?_xRY*SR83n`Eq*-8o4q9-_J6h9sgdS=g6;` z9`t)8&rTN`E1Ga@%;=6Nl1m-Itu6E{`iM9%Uo*y4^iRrY7r&_EzSF^wn$Ahcv)YMo5RTB_-#D zCzxqof5EVP!1V0GW>`Y%atVzn$y{*6G%J6pcgz+PS z=ZHHT#SgFF1_kn|s+Qtyx{ccHFvVxS%TjY7-5d``D_dZ*5R}Ws zs#J86+Uo~6YPbeN%Sqn-K?&64)A{b%t`Xe|CW1FT%yLeP&F zSQQZC7qK~Dzsj<1eEw`3Ro1{6wtJx!MHZgfFVW?`kNagMZz@BuW_^E)aEAF#UY{Wn z(2xx5S?U9eEiOBK&%(pfLAgm`A_wtWx+vCU&m(j+(2hNs$B}e!OyQZu{FRyRUfn* z9y&wU)|quVFnJL+gfLnijB&Ofh0iWioC?z4pIY5ZK&yaXx3R)*t9aE(_K7k&LS9aY zk5P-Mn18bDebT8PfYzVKjbcs|*|<*2d;15+(cC#WpH5MGC5V;7pjo*4@r^E`Se6^= zA(HuKc4stXBdfPRJ(MoAw7mSwHQkU>#E?N|apC1&=-vamXAD9_!AqeWI1qCph<|hY zdme71$j&$m@^N{f6V8yUq*M=SroL0UeZw~T#nYn08vBW)0L5w}_g$WAVVq937(H=~ z3h!xqK3a6q7W5%)4>f};73A>IhMVV^+mDTv0kW3hL?qgghKVSXaMW_Y{g5N^1(|uM zrsjLTT&&hzN2i@cuy+>H;9-{1J%{q`h88-N1?Ij|Ysgu3x69WjT7*CKj_Us`w!$Te z$s_#@FK0*qE0rvuDim~53)Q}h$D^n7K|>k*mVb5ngauMQ=MOC<{ZLNFOC7>WpU%+3 zIqKsJ-~^FWE@Ns0imKJe^{T5|tnZJ!$0yxw9IV}HI9}AL85g1@vv6bw)8Zh*zpj5Sp0FQ%($k8`ZmSP z0nUB_)hrC16m?STQ8N1`>vNPwPsJ7%I|$JmR|RIurp4TEBHjHanr4s-H0#^he0Fqx zaEIjUX5F0wdkvc;S$FD%r0%5ly|FEEZ8H()L@*a$T^=TVFYq-(LK*V8agpo0o>A~E z^gNmB6ht!S<-xoNxf~UK8P)PfF75kDDqr-#^}o0=bUY0!Y#Nde_T&vY zgeUaV_?}O_Kz;W2H^w^K7Yc3qagR*M6>m9((I>kTCxcqgd6gheIdZL@4|hyL61qbo z>mcptho$tw_Xt&1FJTs*Hz+x@7|>^!CE5_jQE@j1lo((91KfmPmOPwfSQPA)`0Mvx zImLrT_Y14{&~Cv#u$Yu@zPuk&AaP`Ue(tMfU4BCO2$1;|eOJ0vinZ+SyQ1s2xcK99 zz9+E!#Pg>6me37Y)gK*K!6i#B=z~ZP<^wf8D$K-Ye;u+8iUoZ`zwaYn>%F9QxNu; zgZ0wS@I1-UCa_RLb0;ce3ws#sTMzRF{2~D+F-=`8!R#^{z~1 zpz?6{V@%*_FPLy3b*IARs-a_BGft0*052FTkPyDj4KT#2q<%!Oddq8riD5t9Dvq~d z`|0U~d|@3q`bDz&V0+^ro}qT}xjjg4_e{YGim1^o^esezvNFPxQeAP0CO<{wxt2!Q zjUsbi?}MaXAsOIetP{jI9K4C_&2Bs7Oh_lUFAp~R)-)-Aa$|@d+Ddw06#- zB{}k?y3`vub~9^w`4JyL7Si7MB^Vv@Kj4dUwzqI?70!K$_mm9>L}g%XoFb4buDWQr zR`f!?fa0cRe27QV>r}Nwam5l~q3sLUy`fDpg<)X1hcMd1vwB)aw|@FChC@z;`)NRA zkD{!Fr@r^uiphrywrRg>S%lqf=*|Z2jN!b4+Tw2#-ExvR*n-lWaQ!}th4Pb&I=d4* zop_3XK8|2Lya0db%)Rgc@+yR!Nh$ORNWb zIAegmqwmr83XT}G@6R8X-?pR2wbq9C01u2wLP%2_V++vA`<4w|*U-26mrC8UEaY%h z$#mqAPeOa|hth(=xyXUlG?VNorMZVVb~3zbl@n+C`!zG=_l&>fHT^Pph>NuM^+?2@ z4{Sq{BZj? zwC|0{&qr*!KZf0OeEa8T|HN*X+Xukt1$F}Pz#XI=hCP7~*U-Y3YQaO%_QeTFz$+o4 z6Wh2j-w~k^jCyB6_tkU_apV+a#5ZLd!G%5ZYI#^RZki+CLS~RZdY5ovEq^CD%WY|2 zK7-)A20vi(-P70(U!Qrt%r-ZkBl#Q3yvGvz+MGfLhT$jP!&q*sk@)vjrMJID2?b)fR#SVqI$8Xcq7F12aqlza3-`m;SV@7AEN;jJ7` z)3N%9zz>|Ad)a&+V*9xKo`ikVv-{03C|X4uDs_03$EW}gBLNNEk66V6xAly%C#2T! zw@nQoHWpS%8Z|Qjz8xi~eU{5k$L#!xg2zn@1udMwN!8Fs*r4$m&kP@q$5;wC^$;x8ydIQJ6 zxXD}fdBNIPsRw+npy$o2kIpJ@&9f#MpzFOJB*XohLxYFE2B&k9h#pm26-S^l*x$jF zX+{czyyIVQQrdigaK{JZ)F*wqVQVJ%2PG{c`~pN<@b#}y*UM}0mgH{LwW0fZ7Jk&q zHR{-ZRzc{~AJs15(`;%pUwY41v7(v$R%WXGhF{i_;Xu<9mS`+|}t{@sSedi_y7ibZ)f!_`(|?qwIJGjX1?1DB+0rdP2L`Qx`wK{ewk` zrJ5c3=Ax}RKLwW0VH?_Y?TzQ&paNI1(5&_id88kdsQ|9M2IC6wWF`jiGQkG|kcK+; z`qPC9KY|YnTZIhUcBj~Y;S~8DIv;Tkynx*@E=^xlH8;&#>O;d0qqOJVF3v^RYoLcE z{6d{fdI=`w(B@2ETK9EH%+`@+DX;h6;?7PIA6}^FVS$k>%VQ}XRV2^DEx`7GBd_o3 zt1%1-QJa`uZ3<`8JPLuWI&~8 z&WueEY+OP_B!K=f?~m3SVMp$t1_+&fxfB==rO$mvlq1!VY$dQpX+cB&k=_DT!%!)NVE_16;MbTv12AO4(*I zY53kEtFQ_8RqhZB#IfcdEwdE4d8LBwmT}s}KGRJ^k{N<4$3-s89r!xs5pB0(2X^GI z<8+mKer~Pvw`zR%823g5I3WIk6r;AM+U{#K#@Q~N5-#`S;chAR3M*~PnXL+iZX&;j z5XGq-GzvZYT)N5xlb7)<;M2<*6frl}I_!Z~hfd_50q=H|qP+_cSGk z9W(F57pI`1e#@!$cu+lZSVStTRtBxyc#dC$7p3^ecUB9akbJn$FZdIl zGel&dCk5nST;R(W@7FBj(n7YP$bI$nJ4#ijcW(M*Y#w0G3%qK@1uq&_`}y;Y2~F## ziC3AuPcuNo9_8MPz|Z|2uD^w_bDA?!7stGh5we9PAxRflAD*4ucYH|%t;)^$_4R&f z?7DIbk-b@TYIZpxGJ0m?!^j^1Hc7oZM*>)<5Co+3R02K4*k^v(ZnjnFNwn;s*jI6`aVUt#{IPKXKimRUi3Ra=$hAnaeU9Wc$Uc zA?%U>ieNh>=Aoqil>R-FLWzY-^vS!vapjPo{X5y;mW^u<9WHs$4vqh~YT46xH+T0J zrq8^&D)SV&A`e>n=NQ0QXo;OSwaDcBiE};vK=j58Pqu04R{puiEI@6@?UQ9#!l- z7v83cmHQ39yj%`2vDsHK8G;_T#UGH@dWbAc{^o*3xlgds5^x|L>3+Fx`XnCNeFsqd zid#-?3S=rIBldS_0RjI!49%|zpe^AJ?i(Wc{N}j7eNQBV9Nx<=@s*RHI-+snzHH)t zb#L%KFn{b>uzSDHRFpyYJ6j;m)vULFK}k!G@_wX$HOgJbl~STJ_w{Z|`>an4Z>aI- z&UVeAD<;>x3BJ!>1@o33%I$`wLZI(48hl!ZekCw3?6-HvVCxxfJ-2oPtg)Yv1U;g; zn-G;`&9q;X_DARE{+OCk0^GS%tgTyRu$SGmEkDbCesrKR$n%iT(OiAX?wtGi%@9|K zpE6dyFF}x8vDwRLvUs)oRbQ{l!Ie@1dic2klIYme*iOp4f7_mBL<4?x(>}+G#2c`c z{jd)j4=N|u!CzLtpBDV%z|*7Ts)eNck?vhbG`qT|o2&=gxB00=W}FQlEND~G{Z3&)i|C^0^<5(bCE2TLTNXC-}$9N_M3Xf zT-zsCw`S|*6nMjFU_0gu|Lt;P6~6RbU=FWYJgYpe~vye-WbG@ ztUM9ezW#`mpr4t-)YXdW#ddoJO{6~`Fw zHB}oN6P|Ih%un21z~dF3OYBBgga{t{O?rM$3Ve4!>CIGm;*SXvIX$PoDyqLQ$7?XX zFDSh_S_OIf`twjjocHg55%~(;nAp<|qq|@*G4{ok>8W_x_n&jMIpQ0Ei6T4BBpnvE zRN-FE&Q~8c1H)JmYNEV4wHp$3#m8dU=}VoTM}+_I!>c}fPK;aj^NH>(g~f(leTPz2 zeaexB2%Ee-&ar>&i9EgBUhva9M6hq%oPE`5Qn(F0m#4P#Pc1=c7P^0CXEEIVI4`VaDF z{pJ`{030RW?Bh{Wo%dx?yh?%#-tr7@Gdu;EQ_I*ewNZOCfc1BFK@6Mxkw5VR5zy0w znesx;cxVku7gl6si`H*S|LU(d5m>}^c*zsqVWYE@yE*ggh5nHSh%rp}_3d~|yEp&H z`a27Ybi44eIv-0z9V?7T_+zM>L9JXh3XOXPOjvoRKuu>lwRFY))4s7x$CdR%XL zaSDr71m|xfgdTyl>yAw)Gfa2H5AN( ztd=imxri8D>(?%6#&?$>On-7Xm~AH?(gg%`!p|Z^JID)o7%?=M{$){5h!eWHdrPoW zM`Ga_jt}ry`>;34sGA~rFu^q`62qUrJ8DRNlvH3c2BBA@FYQSBTHsCqoX4k3f%ZPw(wZX3!kXNOzEtjAENkykA=r7@?sH4 z@A_a~ac71!S}G0Xp~2E9_>~NCYE+3=9$n@f&&d;Hp{pGdNWq#LPgAR@m$!+%M0p&iLC+3x94eE5N?l(%@D}|wK>g@+ z%_gtBKEdZ;zu*pC9UT8KvyO6pE!aC?9u;1Gu+;24ifv;E#-o}}{Dlw5%=Z` zYXIgJT)tn_J)s7x%jNe}t&_)Gt74C;Ph>4><+&%mVN?|mu>sWy(s+l$*ZDAoX5jK^ zip}(&50bXT#D4LP@@vIPjipG2_~CEDY|5SYY(N-9&niIavX148x+ zZj=5#B4TSQ_O(&IqSH`Ve)r=18Rzc%fTHHIZ>MG{QKO!^CDikR`d5#47=`SzHb|{I z!PV(rO55u%GO>hD{)cBQFDRegE;`jytoXL>b?P4XQJ~%R*HK$J_`HcKs9o!qfG9o zCx!j8Q(>A1=U0ZzBF#*Bkv3Mh5*YltHZ2Bt3^kD_upAVPm3+68zr@F(?j_rf zD^P7yCxR+}DQ?om+%KWiAY-F}E@^?_QSH`vngzcq4= zFRJBnmRMla&K`d-OPtW1z9{F^{sZwPQQ67_62*dM^02+Vv*IWcReHhtE7%Pmzrw`A_1&|s_+@i!T|GiUFwH@zIuoDcYN;w0p3Ec2dff#x4DN?l%^PRj%EL( zr`Z*x&Byzq8wvZhN8EyAT32%&AKKM=EI3Ez%|ZJXj{eezzn)9{a}Z&b0UsCi8yY7z z_m97AydK_$ZFbtB{sWvg?Awg@A2VdJTGRooNPpxac7yu@it_NgAO5YP&>7)?^#j3i zQ=X3n2Ol#=`)LtOl`*ynWXl8uu!HSRTL6C#XP<@VfN`P-R3@l4|9YQn&y$5YM zJJR2}Vcv^av={36T-kwFl^NNXSt$8aD;Pi8;$gHOPrn7VJlAt0gw;N%gl!dw{R@eE z9Orj>Vtf4FS0toN&*&FIGf|4GN(KuVclxXb7kyWU7X_>!aJ%G zBu+UxT3?3Dy2z#CvHHlX@;*Xt{9Cn!v(S~wvuwzWzhCiA=C%j7U$w zNBXIcUk6s9o5#1sv0Ab_?%ye+u`M>L@$UzJruPO?t5$@Jq&po7FY3Yf`0|wpKXWoe zcN|`FIPNHEx!J9A&Bw5^YF(JxKrIo+d z`&b~rK6U~a2Ifo^YEo$n7fw&|)59#&>EOZem*hHZno-rq;~pN)CihxdxjCZ8UL%d; z9m8A*WL{Se6HX#IJ`gffR)Nr)Bs*&VeEUZ&_cLK)O=azS#X=1b;Ai|RQ0#->eod2` z`FOSfHepcc!12Z^WZo!f!j4K<6gr%tnqW-%)2#@BUM=lGmN&-6>fX(Rgl!|3LiE!T zrGB}pozn_uuRFK<)(v4AU^B^!EO@%yL%;Eiw)P&WyR4zx^~D~a)67O?+_vYbb9^N= z;hsWW>aX=a^~%ds@7vJt@FSUz$15r;-tADn3LBkYFZ*gi zJrz#jgE&ozaO%B_Djkmdg=XCqROgS>e90A(KMw(axi1B9+YdE)VV8@tT6t~->iUhT zB!#hk`^)qR#zbV-|ISV12Py)9asMq02_FsJ*>M=Ly+}V6Ogwhyq}1XO_dOt^J;Xx& z$)c2F{JbUE7QFeGtl-N4!Iv-=v09Adz8pCWxND^ji7t3umsvLKmU+CzTNNvjKb+C@ zrMYIfBsUa)&ii#Vo7o)t`o0dp3Q?Sc%e?(5#pd7giK4cGN@zl>4JHlW()0&k^%Ot@YKK>~`i( z1bXKg{OdFMpM~^Pd|z-4xrKN=@K7d`|O{H^~{Iw{_F_ROTHb)>mL8!ns$W@ z(AUIN79-A9n>SH4%y2|}M*jl#EmPy~MK2q9jIs;ow3)r9MRt2^c|CqWQ&Zpq?0Kkt zeXIkLxwxN=e!9TbsfKFR^ixB)e_y+G`2iCmqquM5>mF~l%2(S@I@2ye|3HsCv6Uz5 z^1aQ1(Gy_giCGM@i|oeM1Aje;dYXkd6QI~V>zuq0WRs19K^yQHBB}H^Tq*rDChA$_ zn`?8vzF%+uhj(g)Dm|XXZta1A{PqYcdq|Ov@h8b`PWHwOQH&MB`Q5?0+_-M7-h@}Y z_qW!eQruTj0@Ze2byTI>?D*k`r4LKpEf7Eu?{aM3bQb$!jSu?W<8(ZBPGB6KK9`GKJGK1 zrup|xhw0nU?{zaN(WHC(MiIqC(6rm$3vCq(8&es!`j0q?X5Z=^sC- zs3I=52kO1JU3>^0$$cLPE9qS}kpWnaz;n4W>-dg61}8(TR#3~&P_ZSCRew}vPay#O zwbjK`URBcG69$gg8glX?k5O?sp6e$bmdpJQHj}-x9`nIv0vNl@yU0_JUkWlgsNZ zb;&g@CwQZXHq+~D1X>rM)ALpY6H1^88Mlc+0ng>0Y zeBw543T5S@l{1_tHtq43AA*Th%+kz_5GtKB7hZ4AUi!}V3M0)AJIdU9+m6B?9(q4R zlGUR_ZVV^c{O(!S>m__6xlTFNM{6&qjw`=8rDgVlyteGh^FiOiLm&}6y~sWH#sWra z@)LXx$08bFoleX!anPac69oJ7An*q2;=-21KGkEC2tb(z+552PT4W@adA+jojVY3-EYZ zatQ9~9->eceWRT8+rhdoOtK4V6nPfUY4zRiKxVdK$g(1yH@O0B`=acbe|p~2JUWw* zRVO5ya>P<&UtjHesMb&to=;GcU8#Y;)+QBj#1O3Tf@$80Qu6%Eck1iAn|T@AIys9> z+v~K-lk`#K&JgE!^fXyTB*Bm^?8D^LD!UF-uFQ0_!s$|FR#oU}6W_rC^-5dygMk7h zGU>NtEIU6SGd)KNJM1^Q59SI_)b0l_(H%7ZRR@g~PR^r#KdI*OHgCcA&BJAF3m@Gr zYq@fJPwa`12yF_eCtrB(%2tlx!9?DF!QC`v#ag)`heNzC_xcCxa1z$0ZBhq^LsC6Y zkp$Oe{8Zn{YY12**3rBk;4D7F=A#T$d@x!lZ1IL^3LF-{e?%e*vgR!u82P1Uj^PUg zLrvY4g{UIN3d`S})ehoS95L0{IlLjh&lolnqPVFks;kO>jd8sN7Cr?$f zA-`k(b?aBV2NA!&R5J_+Iq8sPhC8h|^eh*@EGy5NoZt85@9M*D3?0X3<-6G}yHSVS zM$^hS!!G~Mpo647pWBkSRM0L~PiF2;h7z8B}PA`K63Q+2_pR*J=HMt6I@0xMypYVM+<7!*$D| zv2LD&XC=O<`Qw+dfYQl>llr>1dfyWgn2h%2Rtdy!j^HNOzH)v4Y0I!w9VVC)@4YT( z_5>aFY>8O%_}(;N3Oo}fWe)Cg4R4)3lUZAZaQ*?Sfod!n1|Rz*?5taCj$|x+_=RZ_ zG^@doNO}4RfM-{-<_M&#xNxxPdt_0yseMN8K9cvw>nF+oB-`a0-we8fL3Kmi1HT0` zWxbpri@P9~Ap~5Dc}u7-kURBb zacPtTYaLocRR&=6ZZ9fJ@zmPEYYG*C2J&hmNN>{@X0229 zR@r`!h}>(;SCX7Kd&Fx%HKD_XayYd=DAM*ICF~iJwj*R{sg}^b&*A|i5`~%e{ZYNV zIO5b@w;i}E&nK@AVM=#?D2BFA$0zrP-FnsTi?{lHF<32NAN?1_+NWT6mY*xEZyJ)H za=1(nXKTgWFCe56YH{Qpzj$lSk^kJiRI$*ahxU!{vLR|Y@tU&?r^@jUZ28oZ7B;Sm z{u9%ty$BRnjEm$6_9SZBbA08n*ZT!&!|+}LX-FU<#C$V-^{(5p9vOHt@xgbaFCzWi z{8y=l*%!^G706h0QgeIch0ntuEjvP+b|H#<_nDf~@|_SSpfc@V-yt6-59cH9iC=0% zv+XTNeJ-!>lv1@&*lPhKTZvp^cg>|d%-S3CMe&K)=6#n) z{6iOu3b=r+|8ty+UcEjFS9hpK_p?P^GQ?F;`yQlkdW8p?OqSnImX-o|# z26^mmlXL%m6_FWvnHI) z`rD4g-8L0|_3%kJQDX37ndaUEJV-BStot6cW<2wxLQaF||JE$gDlm1n$5dWz(C==D zy7o0sUDRv5?7a!XX?%n4LcZKTgBg_KPIVz4Fpmkxw>kO9q2{yXHn4|TPJ3Pi4~+IZ zpJ-!m-AGkZoy=;PU#No5nTs(Rdln5w1-Zj^v(gUly)SC^3q zf%jbJV8cC*xH57i<~-p}c35%{nO}_Sl$r2dFiBs$&;na#Vw;?)TX(lQl+%Rmaq!}& zg@6rWUQOJ8#m{jxCafS5&z3Ovvzrw_gVBAL?7?GA11}8K2Sp)2pWF8QFHnIcj z=AwU70^nEdvD+AJ!&f4?&1qDJ=c@Gf8#`XVKGg0t)`j{vN8P-~sm@k<-RZJa`g-g; zItmbg`1nq#UST|+3JI8*{$B4JpIb|4TKDc1Ie=~el7%OS$YYi;3EVRYhP5j7O&ML` zL4SS56vId3P`03bqpGqc^GEiybTTu0@Csm`ZeUA6?>Idb-(y{v5sGXzWh&5KU@~qyyWj`JF_tn}9(rg( zk>JX3W4U5`fWA`6%I!yPeE?#b0Fk^xd;&t(qYgyaPB01IjOpJ0KEB5Q|2JT%HFZE^n?u(Cgo_(XMP$^RP zEA~~pO(|iIN!2F>xQr+7_u<|t)TWbjmMTKJt1litod1z@U0aGOQS_HY zqK}{?0g<36Z)BC6!`IKIXRW?Ln?@{(suOmI+K0VyAr}JY!Z;_O*?ia%KyvJ%ly6m& z;eaSxOgl*~z@&yBWg=XgW#%W`L=ImZdSdY->YUqzU2lKz1Gj!pu`|TCXy0RR6ujA@ zu#t-o1kBh9LOA3YT7U4<1^SD2oBItxb;*1`grPchuPyvC3ASWF1HSXC`c5|ST&i|b zzUIWBtgSxL$w52EKAJi68yvXJq1rIR3gHReAEWMcA}8Y`)O4O9MLhrf+qL#m6jZV= z<{95z;j{51nCAQz&c|8weV!q>{TX#pb8A%RoKhQ7iCN-JqR>UO=sgdEYx-b=NC=Oq)t6_M3ftsJPyNBvb7PNNr1OD& zhFLj2=aV@@2t{jryK%crD2WF#><_9B@t-4WM{N3B;Bk+Ki7+6p9|qHx8-B)p#b=jq zce%N7yB9V+O22^;aenp<2;OVqP&UjvJ7%yERZ9FV4);J;-&TpUOS!-oJ(+~5v^R18 z>sWpr0=Z$pT+(|*efZ@)0`lYykwOuk>G1#u2{q0``}LP8=F!bQ<=0xWwc@P&(4D8T zUZEl24jLJuP7K14hrR)VUJXF1LSr;`F_^GYw|Bjd+D6QbPxyz!3cI&9!Ks zV$pm)l2$kna9Ji=rur#;x!VKb)^rj5402oN{s?0&=Zk8iR4L4?zCTdYZL;G&s(E7H z64grD`qPSgvNwdvm!^!*q6CfO)#4(o!qOeizi;$;pEPiTPt3Qyze9*89?ft&jQr%j z6AzNXTUE>7RtaHQO#&9n-XNvwod$;Dtvh`dFYfIQ|1gi!$P@kejgZ?R z0i|Su%{vaMiA(TVcs$?(J4Z%K3DWGo<#0%r| z`FTW_VBg*y3356N;YNEPb$);1l>yQ{*|#eSQlvP#w(_K2wCutT1+?*W(Q(1I|4GNG zh0HZ1Aku)}j+evrOuahGVL<#&<4oJHxh5@LVPbo`oJW)@(t;^aQ!_So-@E3`P}XnX zQ}*`&Gi;;f%GdX7?2CmQlrg%Yyd$fDWPgX&0h+?igWsFy<4byvET)vLmfBuioXm@I z1_EI-P+|OCVP*0>HKEnQS0wy4RBK7`6D#y7g!Pa{)r~ZXt>D~!6k{_F^Wh6Wi73p8)4R`(vdbs9;F>Dx9yj~* zaN|=KQb*OE8%URk52HWy>zo!@Pd6*5e&7A? zd-{##P_bRd!dWcWpNrhj^YRg=cn|;oeuO<)IM~*{Q*fI7c^rB2rM4$z6<)UVrNbPY zC$=bQv8O0A09AT(bpE}swQ{;NNGbp!Co@pTm#%vq2XD~IWV&Tn9e*-V^q0MUpbDRU z$mXpMBRVeSX@3F^a&@+0YKEi6l>sL${$!`-LY~4voZ(A0lG>c{AT&!z1*2E+d)`*8 z^a6L5f2H|4bvV_%D%e%k?huK&z>&w$JY=mOM_~6*w=5pPuV<{x|2d7LdgmyZ>q~|F z!PDu0Ky1;(#naD;V;qfs44Fhnu zw8JMi3s_nlgTH=fwf=4ct737Iyg%LP*ZUbx4WPR0HHP+b49%Y)CJYf_KM4RiKIWI8&iOud$o&?a@DFTvCiH6m z76!cEWaN+#?@VI^>FM`mTPTML(r|SBf|Ant#p3bqG+%c=Si)cp^1;U*H7f^>eeJp7 zmc9*iS*D9VZavfSXK~%ExUm7wdVMdDaLZZwwo+-p-oWC=;`^C9OF6aV(En_;%`p~~}PiG)|UonB58 z0%A?w2JUnYd6KU8nXR%T$Vl>^Rn7bkwaZ<*f3G024Dv6t+$&d}nD9<LUIA z0c`Mtq#GJF8iPdcHEUdV=l$zG`mV`~em{K5Yc#`k@3u$~$to(c8egcu@zHgG6LJ@* z=Y@E659I|_{PAmcF$}z`X|i~m{)z%4TcYuS8Gw46`iZ(d&%q>5vb}o|08e>fYe*ne?f6s!>O8&Y?Et6T!fW*!Kyl`S?ppKs~kQs{3$_ukQrV z{Qhc#SajKjbACDJMq$?bNT^RoTlhLIE=O-Q!f#OEuKIMRQ+64lq~%+C`r%;)6)xRJ> zDq=mE=i{{pWQwGzNbelRsE{5B?miu*s{_Vn`cxu5uYX|Nw<9edy!lTZYM?_R_-5cj zKge0V!yXmBW=Z0HFv7rFhCJNj*iUmq1(ccr^sS}_BFR0Pe4ddZ&L>6Uh0nba&Q^B9 zdemVK3HHOi9swf@QnLbBt}}txs58 zA*`o|yrrV+vL5}|f=!}0KF1)uD-=Rl!Km(%+!k7ncDd|ME^@sE(Cv;=uFQgku(KaE zRKtx2;B`|n#yNrkp|fth_^eJA`{n@uCjm`>y8NBeB$N##(7dfb8uD~@vUB1;221>* zHJHFH?o~rNUY(BT$0_>(HmbeHR5T^_+xStPI?1p99m{vt%6<@Qv`b6fbIyr7E9>`Y zo)NSP;y!nT--#HjBc0{^fOte$(+2@~C?|l%dCzs(ldZFLt2Xh-gii(%SZ*rA+v37I zaqqv0#n_k3W$x~k_EAUoHhk%$6FDc7Vb?R+V7v3&GhT{peFco65x-7~Dmjzus2Df4|>|9)r$$z$B-BI=Ghy0472E(qyTJXJ5=`zruyWk6%_K8Mc(E z)2AP5#P@Az?!@y=>KXAZ<=Y*NKm{k3jCb6f#8TJlLlDV)bvq9W(MDy(1FgN`vn7*f z^M~1+keB#+MXj#C_@tb`FL-Py3j05S=>er>WD>{5au??#)8!%mE496XC#{AUPrvE` zzg>hM5O_O-KYI?d?ah}UBnqNQS=B)Lv1)ryq^ieyA#|dA*YLmr)E5Dq8j&ShY}qP%<0oPHs^$X&@@#BlKPXEj% z1pz&lD@d$}2&2Y}h~IwxD+>Cn;YTWm#iGt_HS|2#pSp#{4Tl*Fs;zYeanZAd;D1Nbg zPUWqdVPOevG8h!m*u`9ZD8-jzgId9+K)2PYtz6g$Vh1X4U(wTRNCoP*kg8IOH}egF z>2$m|#BlayKeiOQd7TY}UDDLlSs6J5wdp!&ym@nH4p%C^K$MGF-xp0h?0cJZYfjSA z@H|Iwsle2BL4e|OF3bD5^}_Pjkn;@%^oXNo=4gG8&kM`@P(uZG?0>$W4h|-)VBDaGMyr*;d%)`q6dN=en8?96+dIpYKG>SJF?2Kq+O zs!5+t#c&9=T77ANC!u z4#ym1@3w@7$4mp7+d;08 zMrdqlw12JZQy3FL2ku6jY3^^+QgrTc`%DH&z4I0dMq+)X16y=ocTjI5{Gkb5JqhuTr_D21>*5-4gPyE zLn<2gO<}Jo9FNfU%g)Zxxi-h(ijF&4v@bv}Gv)YwJf`pX(U_7qG&+h7Zz30$^zasc zS=urvbKVNjfu7G-8xEFmzKPeW*lWh#&j9;nB=^NmS<1+U=FuyQGuuNgkfA}Xs9HR9 z?d|b26*`vOla;YazTPDH!iyY4oWSkbD*=o9)}ZiGB%_*amAB9mL+tBbu3X}?(zT_( zeg{Cu!TuuJZ{=4M%n7+e8!S?$@^?iOl7j7Yrs)Gcbl#?OOoHxPIIXr9Wo#R^rmbuY z&G5v_z3zwYJJz*9TG-t zEqssjAm&OFfWe^cAQ5S}TVN4#rwMKt^2pyrn|XKLb=S<7dQbTLfQAT#UuAb{lV<>< zcVe%Gg1_Rl*8=~Reo;E5vK{Z6J8{vD@DFP2882XVeL}N3u9*31Yy^yE>U|)@5K`+u z)ZUM^036s+_fEv~bOm(}h8QgBG3Hh^1bJ9KLEWz2PN)f*^lrqH)qOZL+^8zuJ+I?eFp2ey6ucsOz9$bF z>sZRnGN6KFA(B0mKz1SA`s4oP;`6l`j=zlMiD`j#C8WdVM_4D$!t37?EZY#t!GMGW zKf6;@n6Y28R5(Me?Q(aSOJ+M!od-DcTO; zQjQaPd8x2tfLBpNwelm@hi-057-H``q8SiZ$TuM80kZSTz}h{AUAPfGOk>}&R&5Dx z{j)MZ;!6@D2j^aT6tH%*SlPpyz+=CD~SE zI4t#DhO=htWA}hAZx%&R0EDq-Qn_*D_R2_s_I>R4G}x9`KSuMDtNr08E0xjy zXiZweDNdX{!Y#_q()C3;zvJN3uWMC<1#~D?NGh^0e?ROa^u|BTNiW>h_FW z+;FP;9x_8!`rV3K%4*Oa4#cAd(Kf@K-`8RIX&3b%!tnRL#;oN!zs)buUt{|;8tWlF zg808L_I&|P(cO^%oI+$LjI6RmZ_2-X!Wmy|PaD~q zekSMwo*wY7JYOiN6TPJ>+4qH?ULVI43Z6HE=qgXEssQ3G$5Rz=JV9u;H%tBm6Ho5L z(jVAV#~HTD#yx`NNSl3IC;S2fYw(dv9Rp4Jsa948Z*&p1Ob*mhgy0mRSbe>LkW`nD z%;<}93wLgskY8RP0CMs#c%DjAC`(9zO9k{AIta%pjyr4*W3rcJNy$M^y?th0;NVaP zSa1N~F8{QW1enDg9$DkA#9#A-CqF6CqTYf6$>V)IeFYdvp6&cdgPF3yWDM=zv^J{s z3LhmNCc+^csf+iO64_7u%=H`wV}n|L(=|_=F`NcT2ir|NS6LWK7F6QN_Kqx{E z&MKLRG$rmg-xoB#os|zW`*EE6Al{sudk3GwfjH#kgzNddsQoLP5LL=DcY-E3LGfaY zv7jW^Em*k5t|Vc|aMivr75V|E;&mIj^L0U>chc?LQKE+JMTf5I;yU0n*F)B<6Y%=% zmA(ZZC;FCplf9*SAKh$}o>Cr7(bc!kF)%373f{UHM>VUIdAB0tLUZXJS0rD`ie}Q;sNuxUSMAZYmy6Xpq-t!k z&XHqM^B7Laes(CR=Lo-~>P_96*M&pS{Yt?^g%Jtf#n1D4j}PrwWY_8Vl`G0viSKRD z&QDcQa(b^52OdIJ4E~$oNH+kQ$CTLm91PnIT*T5?0@w9QtzNyXOG;`$w?u6#QUdujMlUbGN zi%L^7Jc0N(oM)3dI%S?RyR$OVXK8NR%b>E{ZSQ$98<{skF} zKP7eFsRNzt+G)dBI*1- zpEYIK9}PME`xkoKIrekqn@d;7Ej%6cB@PIaB)F4jPaJUNCi4jh8Fc5h>=eQ2nZxE- zuDUd>aG>iC{Ntjk{hUIX>}M&3eukMu#CF_)Jz`bkg0j`AEBZPbdkj__BqQ~bG$7AxR z&wzuraEc!4x-q|OBA)t%+o1D+#g3Tt%8W|~hrq_pg^V#{fLwhczlY=;Jz)%y3MTpE zsdMb^nh!#1UxgRSq4)3F^#u%RKdwbD_=UmcLI1Y4WVad-R8c`&1Jc%42X?lMv3%Zg zy7&nJeMR#!wF)!JFD~ORj6{ZcaeWrAqs+G8`Qb{u&vd$<2l(m~_V%EE7wmM>WSP=8 zPaY;)!u0he?F%7(WSc(-V=>Y#h@&T=|D-{1F=;9SKG=Db^8Q4GvD$PxmltobD*X2P z7Y5X%55ZQP_@r$pW5aRWX?#VBu!-#}+5Q^Db^2Bx~(=R8K-fVhxnK=Br$YF@k5h zWygvDJ>IfPfA*O^Pm#-ym%4VAR7#2QyamA!Luv&z)9Lr8P151gz`p9kvg4TSVt!jf zQU5R=Pp$Tz0+1P?7JNhRa3k{GK5+Z-Y)MASBtI?rm8w$HRM=q8PkjvM_^j5tNL`0I z=t`rzRJxzbg;`EtBR`^KA3XWbdJd2I`=RA`qZ9RVLUB%Ff<)v#f8LbG7dl#`KY&If zE~Fx&n2fp?$o$;NDGx&bSUjr%^AUE85rK;tY`>Fql_RH8q@X*9w;Cde+`G(0cDKCO zbD;%&ocHeyzcL^RWR%NltR}jrxln=C&59|VVpVwXDU1w{>%MZzI5t|lul3h7f5cGk zq&x7tY93u!vGF$smZmt43{HTWWvtsyK@1Jfe!Cr*pMSm@Hr8-NlBYobzoW2-^D*QSLMLh(N zQdCElNNcVwBdC1|4(*!OyhqdfgLCo06+|R$56NJ@KCM@^%QT3T(cGneg;||t&>x7y za`N5P{N~j%8}ooOhBQKX44}W`P-WA7%rqZasq_tL_ugGp6CClaj@Gn|M7tklTn4=2 zK1-DE6VPp`|I8?5)@8(&U4MrCRHLkb$M4sKg&P0H4`dx)z-S?7;L^`o&R(zjJf6YB z64O2FOuJ8KofdeROt9?(?lPch`s_2A-K9fI6K1_78S6v+d*rFiZvnWkQ2K5uQZ4D< zue!b1+w}q?PG6=Cm>=zHn23r$3qz_pJn7jdI0kZA9?7MR-sc`bxaON4;DCIvr&@}i zRw!a3(lcQ&hl3si@z>5rt+u=rkMHU#z0O6%ZB3xmJ@gyN+WK7Q5aYix1{s~hs7wgxvyBt49X z?fdi{hS@ z`O#D(`5x%3#6gE*TGn^2I`H^D;h6oo$Iq#Qs~~4fAjpeMULm`d+|M|L<1rlAJ(Byx zzlBWH`Q2ncj>dv0X~7!NZ!bFIGy-!=-ShWgchQ&rrZmhB1+#@5^(bztegv8#xCkl{h~Kl?^@0~z0#hst@b*7?s9m;0Ut zz1>p^m>fhnzbkYwIc7Ycqk2#O`WQ-E<#o=%2-&y9Riqz9 z2pRCLcyNXdxMnq#i@;Lp6K9nSn0POH=SPHGP250axou4+c8GpBjy@G2-vV*jLI1g#i1v-!}zdJ>mX!D-q!t z)MbvyE+aO$9Y4^!IzmbB2+TqDW+!7g!LGJB^@6g4d9mIJB@tg?>-66xfuNP z!#`ujiVvnZ=xH&emU<{PX$SzU7AuD90W9lJr;+6dr6JF7pv?; ztUIX=+@e1*I`b(kc#s|E@xmjQ|0EmFKsx~1X1L<&dWH&qvqkaE)L5O-`tzf@$ReMg z(%L3*eK~+Du|G2SF!{$A%^Xu=kbZY z)%ti}$Y=0sqHeCT@l$G_e0>ory`ZxmqO+4u$3FP-=964?@=SQAam0Cr=%UW*rz?nA zu$EM?fj2q0cvQiKNk3g`i?)Y4I4dN~a93AY`z=k0L4gm+t{5aFCy2AU9Vn8aJr3jx z&f-0k%JKI^<^Ni?p;VUqQz3OEhJ~4z)5-SA3%FhWAj0aN*+1*iWuDkGo~FD#=;DyM zOoOLnPIo20A?%BkiUKaa?O*rrnF_Bb)L`~IUl~xbxX5`1w|nY4aXRQx2l7rAMaLfY zqN21vd$;}v9k?(1Wlp!7KrYXkng*S00OY_CxiUA`Hk>$E|+7A>U$+LRvwwPF%FuD0>ESb5GMMI-|SCdgd@rn*;FvMayYTdF}jRL4G z9%t;>_dVpH(An8gaHJL(cE@Gx@>k|VO*v*m`yC6DNcpkq+NuBDn^*icVg~%WUkHr) zb<6sGGQ%LZU(?jw$MKJeh7Df$3G($}4)xu}rSrSLxg>U~J{WlgVdHsmCn%oWl7xH< z1%5|e1co~wwy}&%sBR@Lzbyyt9a16diWGYS!Tsp6>qnz6zbF>je(CSR9=MIq!$47J z4X$bFT*t;=i3r#&LGAd1lHP7~re_;`dLM^W|H+o>7!C&_3L~}EhjMPagFD=Fj-*Oa&sLRE-`>|3K1*UGY#D4_i!`^I zzo?3e1^55nK)fJd@5A>4;%QW$0~Fw7_r!i-i6B7JF@qtA$!Cdoem*AJZKDAnb_0B1 z-)6WYz=mzyzxAhVgy5{M?+7Y~$HZfwAmx9x>lH+OjDOz!j58S7_#63hA0uFC-xwI_ zejrXf2%+ZW^tZd84@WqNz!}EvDa6*=@pagjdnsJ(NBANVVQQ)$+qYdgEu~yJTQQ%G zHfTPOYN3iJt=^!|+pqF{Zf9)S*cb)o{t(!?frp6K(TB@R-q%q`Eheu0qPi|;pxHy> zE%gk!GJ*V+5fvDRbY4!6V<#D_FDduM6`)^%^99iXh{_~@pKXz;i{>LZ5pIV#KinHJ z<$=faSs}>9mVi2FQ9)7;j5$!ZChqUy_*K0=2T!J%U%_4q2)Q)nwz%kw#&GvW&%P`O zpem>*C;~Lk*GCRB*JT_ZhS=8+CQhfZzw}`35bS zg*{hfGB8yvQX_e-XSZ5S4$x!n#J=w!-XX>)=ARC`u8 zCwum20fZqG+AqI-V+C|6?uMUYSel{#_|D7zC`0@{0u6+!FRyTyLo|@G64m^vBc}Sq zme{!Y>S=*7ohLJfi6@lBthD)+-=_fD@PnTq8!yfj$7jzp+%6Y};vm=QoCydXD_{2W zZu(X|1W9@8Fr5hUN3Kv|o%rXGU)O>cq}$nkU4e>mm1nV`M`!`wLTWMmyl~OR%U!C1 zLMcJ;mGiwb_suw0xgU^g)7N6X2Vru3(L19rCVFcVV$w5obf1s`1cUBYa9xi510ZPW z8RD7`J!L;f!#cwG=)&!je62_}(?Y}m(rDVPRyO{mCR2mga{Zx@jvYFqZ?P6iE6D}p z7i76mICtM&s%?L;?lGjERSULhcx~p+;o4*>S+<+l+BSK*zBcaC7BFf4VCNpWhMurn zeM3F(-PG9=*A^$)+PW+U`yStzzlRmJeglmaPyAL%$S2IZfUE}h*U5eajpPI;c<`pp zP=3DB>rtd{NKnAfgO<59jm5n5!^bsxvXG}}!mqFhm;LeMtz;xsy|{k2=ItHzZ?S&O z<*vMd=cewZWU76--8V)yT`bH(D!2V}eT0|Wv)#hNe=++SG=b{Bwg)LW@@nzipY{+i z@BUThFDM^*OO2$749PQ9@cS4(l)?A&4|5EUcqy3Q>J-mwSRSODp}ijBrgeY)ftB!s zBt?-xD+@*eAj(J$BnS4j&I)ytoIyo=$D)!h5a)v-z&_M0IQwl|2>x$o$&Y|66mN?0 z0a9tyFL2#E$@Wu*w#|MleJ%AIXY-Y|o&qnczx)c$<@5Q5gBPAcY58^tfrXW876k&s z@Vr*aa=z&LZ~0j@TPAmuq_pa6KoX4E*Y&jDg!#>zNzRJN`Y!61(^nMuX>a>d{WQ1? zEk`Pk2`azrYYv&8_FM3Gzh@cV1Wy@dHX%{LIo}E~H^bzGJ`04pK&vOj5AVC`XpGum zru!F2%TD2BW*O~~-lQS(lm~NxyvUM>E8$YWv3>7Pix0-vQAd7C-SsZ!p$XKc`=`+K zDY`-)=A{H4G^P28?vmxQM)mz$#Mlo6n`g_(07HEEkg*Uj`fK0%>^DNleW-u*2tm3K zfLfE8xX{B$LTAN1TWU+co-aY?VX?Qz+x+1Hb|sX9Q?aE>^v%G7g=dVJ>dKK@i?(M; zjDU22G62L-oci9rLbN1j9fe&-wuJk#jY{ zAMr<6Y92xwY_$dP`9#mtNlGx7&LZDD9m|#=dgFP^%s#iz5G0MAY?~yWvz~_bOLM|E z0D~3(1^`HVh2XG{$M-4x>x7i2`{U^D`{eXdSaXh&;C13Tkml=!+joWihNeIcOdcG{ zzguER7hLAL&-b$;M^Da%fR+I__cklUZYj+EkEzEsGnTv3DaMWN0HC)1gz|nqOas`b z>`e^YiT79#Ppw!mO*nCP*hM~1k2GjBfN}Xd>ft=Z^R_X45{@n7HeeK8+$Nu zgH1b&VoAeda&+e7_tmjc%HDkR-%bmunWOYz#&GBM2;8p14TvxAlCe`?|((FNfgn=1{Zd(>u%?Fi2pE(pQLAKZ>fBKu1OCjiSc^|R(ufU)II%}@;z)%t%|Ta2-+zs zb)3E~%oi)cM7lR?|DGNo~)@>p*Q5z!)rx*!`1S9ecn}AKS8hUgq2?K z09Dqf+ylYmb1ys5ZG`^llcy6!EgMSlzc7{P!r0U4Tzbsuer=Mvt`6n;4RbRW(0mRQ z+-)-g=<##zy}&rrt?+rCGcBlrykX8rxpqOQp<$R7B!`YCH^XRu)jY{DFSX zl(}vnaeVp1PAzP((mO(CK4)AG+PFzKm(}<#Y3DpYe){7zolkS0_CNYEVW0(Crqd{{ z#_lvd0Km}h+kUFU6)Hg1ZYUJ&WBsM?!>wtAeVBt*qfLd6ZlBweZawpv#MjVJcpE!o zAMJ5%zklz{z!cbIBF?Jq`6I@-zj_)#fI2QR$TO};3=!*MG5 zk$ii-GxTL1O#EiE*i&AxzGd;-`B~C?c)&r}Ti4>pr1-!L+*X;>ndefTFRR*Bg#Nnd zp&;Ggj(S+j(1OL9#j2PkQubZm)t=f(sR^I1lr`b^ce%rta#hF@ftuu5yM%)L?rE+} zmVFYgS<|?u2j|$qW&F(V8#{hqj4{87!VBKWaFYuh>+R+mngs^}D;V0*?GTYvsg(Am z)0*=>KcC)^!tzL~QVxlYa59cR8$Fceu*9$Dz9ASChnY)z?x%ttgLTr+_HAYLWJBi& zzcxeYLU`r=)KeZ9HK*J8c7&wPzB0Z?RTgx(DjqJ1JWCi5_V*cS$3Bp+#8f-?z%uM${+QDTXbe9V zwSo9bd-WCFu<;63hJ8Qil)f?4hr8D>smhfCHe)}sJ`(8>HTW16n(Ho-EveEm8ON%) z5q+EA^i3t?<8AJg!qC>iv0O!Q;peGjBX{#d4mG z0(O^@nztHG!^Lc5?`=L=Lmhc4B1tC@-W74=YwmzQ#nqko`uYN(HU7-d71>xJr7D@R zuzGy_{SYy}(TSsxnoR7^S4OBXWgV_ty{BHxK4Sd_`>@(g@2khSC&}F_zVyCkzF$>@ zK2@ca9QZe6!rs$wvft?kauF+iv$KmTgqwwg4N&Q~N zeKnuobfU1u$Qj9Z#uW;R`~0-@c$=78BrIu1H=FzmV;I=Y{P9~CFiP()$%&~?C3>m# zJEgf^lFtH7o@s=$60bvweJ~~{0Z6(s9FIg0Zu^qPk=&P1{+v{V*DOl13}C}v_;;*x z_|OwtZ%0TV9V3USrP`Y18)SIvSF#SD%l3I|Wxc3D?*~ zqdG|{17|5~Fda^t7m)U!q6igSn>Tdr*e@V7n}qyAO)Rj1(NI zm>SxY@N)`g1!96YHuu1^PcZQXB}|6o_384`V*!DqlMpz#TO7NA?C#qr7G`qc3nTIP zpbx4Y(O$Y_YE-Epx?j0j|Fw_DZJqBfaLw%S@x$`u<#Ahot=jP~2l=ft*{YU*bSkLp zQ&-jMbEhp5`yfAoTn`nV7L{^e+4m(00Y){h!5tQH(vFP~j?=VXepe1p8v7C0ur^?o zL=kb0_BmU=ukTMn=h!UW^pLRILvFRp+`7%EHxL~QS}tAcNwAd1I;d7ebflevKyMY7qrW0X8e$l)DR$ zGm+APT&ONwSe0vr&>Oip&M+~uGw-x{2^5;Me&s4ZAT9)XCnEOne$<~N{*=`xdcB%A z?x2)sO66_)Y^HWO0wI_f`@Jtu?L2(nMpbjnb3ZOc{h+`KBy+5_oYEJ!r4_Gbd3qWu zW!)s-p&;Uk`ie)|01xd>t`cGpLG&sB*I8ztPi1lYb-{ikDL1>r;LGEprUJJ#{n#xo zL7JxLPMU#hOetTeFvt$j4;S6zVbZliME*zF!Fr5GHP33k;p`Ig;w7vi=fp zCcNsL=i%Mq!kjc9;HF2eujlJ?;^6(>T0b!{fA&7ZgC0m$8P4)=K5jRb?a-Ji(QCS+ zXmb$EZvUvca|qST`$>if4niWq=rM5oDg$d(pT-+1fJY!z_thIeoCRP7blIN45!%0f z6V1U7Tu=o{did?37Qa@Z_L}>$NVV?q)D=?gGNGP2dwpuVL`w*2G+kfe=Va zr}DXi$q6O!7sy#PLP*Hm6SGc$tkxCv=j6%&N%rB9Me;^k7i*P?bplNs&SwZpG6Grn zMJHBr~!vG#evNdfk?l%!WP0G==-Lwz!Y8c+oDF}UD+t-XsLYw|) zxoFdVbD-v#9tjZTT&o^`Zl{dg7`dRqM!=bVU!~z*4hydDPfwKIa|`?|aZL_~I7aK- zg4blTIRz|Y@rxR1l!UXU>jAG`&$`c7zvp<@P={lZgAk=$SLkvJ`}hd8aiYGi59o|< zI1hR?!}a!=p`!(lp}gy|Reya;!ms|YInb6UYpmgy`bvn0IkR34OMmW%ZTIi^V6%=YuB8>2c?4jkM;8SnZSf(hIG@K?&(uVMPg&Rl2pho(^b8HVIz7y3_b9sKlLdnswj%`=e%seQ}VO_eN)y?GCLR2clHv-<2&Zk zM1FtpKKeUj-r4gDF8OuuGYZKyx-d{0m-q|{=w4Wf`%_tU%U^jcAiIcnHED)%=%a!l zFi!pxT2_HNw^JRL0`9SY)>3F!T))i|{1K^ddCGXe+HdiMXX+U%<3mT)>|VUu(97c; z)p6HZ!5ImeFc2mzIL@u^E6NY8uI;+mRyUlUErj1Tnz)q`Neo?8(;}srv-2IieL7{* z=}VsBWgYm7`Wz-cM#DKcjeppfIXaMRo;DYls22Qz&3`XQBCNy`8jc(aO?rIf?ctp( z8<(lS<@h7b+GJn64!zwOIvIrm-|p}`z>wR0{@4)TA6fi4+c5|NlIMsD#;K(fA}w(KDWE;yQ+>Fj z3D(wokOq&9njX0N$DRfNr&a3hT&6B>TtHtIxCdJBQGAl!tE8!qtzU?gd9>+1a2HXs zu5EF--XQG{HgD-p?eQp!QN1|dma4tw#P-k6R9a6ea}x_fK>{T|EN?@K5SCAcafn$p ziK^9a$*~n<iP38C5Q{qLZ>Iy-yD`L|c4I zvO>=ZQp(pnIqLwj)?#*J-#HlqEd^jJ!Zm>dS$vEO%-({IZ=AHr!asq|D4e9UT>%$a6@~dc18vln7+=fby z{AY>1TJzV;sUna+I><)B-B+L`bZjL%eXsXOH|AlIEyG~<;H9xUFAm4nRS!)MHY7#B zXt8*km-p#+Ptc_RE%S-zRqmm4=H{GWHh5x2{N;BdZK=c~E%+4s8mm@ryYL-fz4T3KZp3d^`7g!Z5_AyDiPHPvs;tc}9M@)EnNfpvmh>z3{C`cnpGs$h)s}toToK+d{ANoymQC^$calzPEF@Qx-u13zoz8nHgv{( zFR!CuRs(kopRt_{Dab5vGDR5$d>q`mYT|}Yc&8Aov0^QMSdMbwet`6C?RY~d?X(V0 z2&aobxhN=05-gc<4v<5dVw&_oB&@Xot>rcADH3i9Q}-3btcdMAto!fjb9S{!ACA5Q z(9bk+>+|FjrnvB5pK1yx{)F0<<_fRYN+8r9x1#}!=aT?~aB|^q>y%6toyzq&7$>w1 z@X2qHDi+Fcp~0D>E(}~bg<_|9spL#o!V3Nk$JK1yRyvKAAH0kc|58RL--ki!5D5rW z+1`0$dYoE11`u9s`=Tj+e;yS~+e;reV_~jxJsd#fd+qbA%?&+MuRd@Y7ywpe)=Bt2 ziI@CE|JCeY&uX7ZrW_Io?1g)?9;?0>(BH$+1~v!brI`o*ZM$oG4(SQn_q;rImihVI zbAOLfg~_F;L)}Q{NAtc_UYfMOj8YRT4algdzwSHIg7=n0iZEYna{fF*m;vSgSUR&V zMUf~7|0R+AQA9u%5!rcT7etUvgkL{F^_ElzSeVmtBXO=-DA>E;dpXtus$V>D({wVC2`~+gJZh!Wn%dk#}9Q8iJ|AzPf zY$8!RX>n_ zpKY)&5aaoH?-LsNMnA#fY@ET%fGBK2(8#Kc#*4Lfr{gRX3;e0a#Q3USKsOYH)amIgJ zK3AL3qf=SRu9vb|UtKV*zlJBaA*G9UVB+E@qSXWVp4wBzI|*Sc_`Z3;ga>qV1NDs% zAJ>`|`cIg_plie*3@$&*?M8yTIl~m+d%wD7bj{~Z0Ta&EaU^WsW(bn(oiP=5s?hOf zWyg>tCpzcfAiCoKP4L|E9E~6|D=EKEqdZ$w`-xM{e7D0vk{7vg;J5R*^H;VfEfG?) z^$H^`DLnabO_1OLo1Nov;-!Lw^TvbBvr6$-3sS9=q{8y~!Jj!H&K?YwI~{`J`MdR2 zK8HhYhmgL!m-%bTl<-WD;K_Jrl;477&$xFa)AfX7?>yIJXxHDB z!A&SAC?1|(C;o)02`%-g%CPhDAS9!)mLMIOew1&@bZ__CN0ak{9r2NxFmP4eSI0DZ zjmm(f@jAzO%ELP{Oc#fa&iPyc)JAm3<`MD3=Bb*Ptq@dx>9;C&MT(Hs{ca86xdMN) zheHX}?naigwL8Nf5lHEALsU~{H@7G6o%7oeW3{a@R91?<-#v{PgQ)b<@9u5L=<;i1 zYOHmyHAl?v=kn8Sj_z)i^xzN}8qb@OaCt71#Amb(5|;MQ9_J2PsPifI&-HsU`~T>D z^cN3tcfP*N-lLljyjc4{qVx>&xQZ@z^~amoKQB+&`5?C@-(98x(q|@%6r007?+h0o zsn|W$B5Z7nu~#;cgm=EVQu%g=T-(n~kW@#OWF5m~a%XpL4Up$ARc>hHlK@l{?i%iN zJtjyL$VKQu-h}ZTZine2etntgkR8>;6^}VwH0DM#s{qmOr}OACS)85^`>jel;OU%) z?=h~LbP(!e)i-G@CGFn(aYC{)9}&<%Ci<+daXKm5KXS+k37MzOEb?typ8gm-L)YC z<-RC!OGu+t>r7o=Z#a~gQfYQihy*|?>;idOll`2!$wj$SuTi#CLPDa!<-R7ym6Z=(53OtevY1V!ZDRL#r1bFhFqlw<9R&+$zJ#hY=RnNT7 zO5BM}gEv{5P-08G&4CC-oW7ldjHA;^GsgP*}(NHl_~)b*Vg5%*gz&k!Y@2ME`txrFWwNki+`JHirfv}Y3m zU;7pJK8LpP!#~zr`>4)m^Ct)Sv9*Qtdn_^NC5QyN+uVksBXW!-LdOeR00fVir5`h@&4 zUr%kg6reC%tbDxIkHyG16Jp8p^PAd7BDjQV9D4h(-g@%ko{st^I4w_J3Rl0nePoke z`Bhuw+qKL-9pwiEa3EU4B55*~a_-)DhEbnuW7Yi8YkxMxb<)aSlWFU%JR zd!In1>wTi`Lt$I$KL~qazR4xERj(0j^k@Hm$er-TsJK3H21h<`ep|Zc0(bqTZ|M=m zEPE<(FeG+5Xb@dI?rchQj9)C8u3b7b9>)7;>GSfy9r37eYqVci+G|V1WnCt^cH>Gtdm%7P+_nN{kKnnKLAv!&+O_s-~np_ut7o`cy`ZBkr; zh(U&H2i3Oph*#>4!kM%`obZ4*R{X5^IdK~92_J>xcGL_La&`GY`I+w>c^-?<#TLWPg2)exwgn6~ zz!##+CYT0^b1Z-rdV9UT7;KdCduC)`5V^2Wq6JV=Qrx?6-^h;(+qxUgK!=dg$@P^y zt4^ADY~@ppvuNuF@~iJzSsztCu@j4z&D^!B0iIKy1=^tW>tg6#@tR^TTP~^TcDj(WB?(lCds@VHmQ|H!$?anq4Q& z@FaqTyk_42fF0Xb=x z68)Wg`-r@!4d&}TO3(xGP`MlgH+80rx^pG=v(8gk$V7ET5{H?D}wR!iZMyDxY%)HCwV?qkFfQyY-v9e3LgWdg1X zbXak$SpwTJ)`DKieSRIe*UTfPhpRn=eemfBq>R76=*OIk8@C`p8eg2Ry-lB`=kYV( zt9Arvnp`Z(Y-9%0gkR_Apz-QVu3lq;8}1PqtC|HrCTrPFUM zxX7fvKn84WE(WHpgz|dcGR~j?n9<)88ys6!FKZjyD{(0dx6@h8yLZ#=2ctt$&7zGh zai^43ygy$K5`PKyS%sf-fSMF+&1VIb&IJdIi|oR=7~k9H3JPnsMVW>>RKR{Qe>YAR zkL*M}RSwQW?A1GuHByaT3qR9;XWvn8=o>;Xa5(RG4a#a+uiF9{9j84)W^@sq8ywFy z#=b6-HtkTfHeb*$Ic{XCN^h<{WltFE4`m z`fv%YHiIs(FXGv#Wb56VI>6h)J-@~svLG1edTC4zgZup%s!qlxPxaaoMbV{JJmyy| zBJzxTlnLCSJWxIH!P~@rK0dwFvW2D}L|8Uq0yAcU3S^eNb0B;zubWWj<#K5JA2wd* zZ;QmyCn7%7A;h&Ui2Pm_(7g3D`Z%<$uWe}TzA6;yHforsxW@5~g@907BP>$tch=D{ z3Z0f!MQib}-=SFKvEZ|Vr9BPn>&MR@ThPY9hkaemIdhl`4PXwS?kR$By1!sOD|Cxj zd9*M7gpW{rrVuu4Mwr{faS6f~y1KjxLcfhsrHZO8ERq*5^z&PdweI41WUToDpA?~|B%QypkWEv#xkK2$ncZ8-0}HaLa(`9>kkBTq4#e3UzX zt1;5N?{P*vCE&+LeP4;jmz+@fRDF?C%Y;F@&wT!F79FZ8}QJzmDX^Aws8 zHulwDJ%Hqw$AdGS{c>Tc?{SiYZJcJ4v@8K&tp!Ct(iBVQH86Mtw&o9o7@m&b>AjLe zE8iYj!@M7{v>{Wkm<|XSdN*gy|K#GLvtSG>OS?#4!S8wVHyzGFaBitZJ6&L;h3#wp z?SV(qMQmOI@BFfT@)9HR0>==j{hLm7uZgpcI?(5q{X;|+QZp^YxH>D^wW(Gkl6dfP zW)4aU)@7F>cfE)7hrvRm)PDT%hhz)5C0UJ-oUO;#r3{@dvONKKwm&Sne*h=B#!mIf ztUJt?Cn|q6*Be5v&+MffQfV3-W4_)WMjrCndLe6m*F#HZ+PfoO+LJ&Im~aO&_4A5U z-kgX4pE2>OJfQuy2s+!Feq{iXo)M^O1+win`nCr z!C$KEnT>- z{O6MWe35?6vchUXMn~^15!A~`t6bFE19swG@M)Z?r8M14LV^IY%);Ig+#k$|k0xkU z0R1)?pd(*?_G-LI-afjQkJpe*Jt{?^!C@Etan4EfF*4*cilb6Q&UZYFCxUaRGq!^~ zB+rI;8oF=?R_i3a$US_y7kt_x_)A9p0wJ&;^*+)dI)H$quDh1l#yXAfw@L3YQ<91R zioJOI_BZ$}o^V+AVj$b>o6OwSw&A5`XMQ?Q|9i{s9aos!RbzB2iL7_8?+pln(uuXZ?^pOE?00>r6S+QGIAf&rXPk3 z;nK>GWE0eCzaM{tJ;Lyg^XCjD`Q3D=FO5fzc-)FpjsGES2#z1|fq;c(IPKPPsY0vt zbeCS_+7+thH-h*9)A1#i^U#$^P}*9EV&>6FaZ(x|sx$-*<%VGOi?HlsX34XC;kJP$Ek`Yu zs#0sX^`-1d8j75C)xyV_N#1hg8Jv4ECS-|=1@ZZP+CH?dryrm1EFL9N4-s{34H@=d zSer(J?>qSGRGqBEgQL~&^|MYh;&`6p7tK-aha)T9`=MI3;RR$vyZ3&!EBd=)Vkc9G zD}%P!#)FMeUfq{aIYH`~adP7#UE}x57V|!oQ}^kN7^6}RY`(cJ&XCjlEN6>K`mFV) zy4Otsd$ydU(RMd^gBy~uOI~PhmCiEcS5wQrtOX#70nkytuH6F`3#fsG2Xo&lNNPdi z{K6wmZIiJl{YlT0jM5o= zC*o^Z>P_y{q>H$ZTd!PMvlmd2N~!#ji08}ex7sl_nY&1-1b-k8lX@imy@ZA-HdWYp zh20IdqT@AtcONl1K?>^L>3(}&Uk2}3`ym*8?x?Nqb*vf zfN$6kLe+m=yv^GS1AJbge4jGuwr5-lTDcFgMC6lSU%6!IP9>4#*LwK$ZB>K;Fu^~e zB^NJ7o=$T4hEZ2aQJe4mI>8Je=S=4_9ltH1I%k9T_kjikJHpmJ&VVaClk)bse?R?n zW-!Z*LM)gWkXu^N`}+Cq8@4;lEBTA(wn{Id1NB zFa?A3f*s`9sogq9peRB@xq zfxKW)739tFAi;Ooe6d!=N?nLls>|rwOg5g|3xr>yJk%pMnEZaw5ypnbl zqo4~SIlFSNW!MMKR}$*<@eT=dQA-$8L2Y>#4J2&rQFBTC2{E+Rnzhf%=y6HioJGx* z#mM4a$@<4%)#^Ha&wR;l86U4H+;oe0WKy{ z!9XhQGa?TxDl_w*+V0X`>D)_MWamg4hw#QXI$9f}D{(=nX&4pVr(@6)V~8UtG=GtwYi`AG{G*T=2{|MVXF#dr=OPk=jc`e>hb&z5*> zOTvjqPho!ns^^p47wT@QOYt~~Kuw2nhld!TuHb)4$y5GYJC(Qc<>AG&DwJE`>n9dBWR-@1xm>R|KQ>v5!#Lk~C+}zJ+9F)>p4U0`Y-*#Lv#*%ukpocQ|BOlg8?~e!LF9 zA5z^xUR;t=d7nE#^6q?fK`9T}}v8 z{Z7XVxgro^Q`m#fW@80A+Bzzpdq5V+%QAyTn6#ETB{+Whe7lD;cv%P%{DijB4Gx)} zpSD8a9qfDGS0A&w)ZCvuz#C3Kl4An|ZC%;uI8f-eqVXn1P)gxnpf5b0ImuiWPvZQ% z71dI6HWb3=uQG4gF>fgPCimDRlB)Wp6(8N7d@} ztO(+5&6FmJljLC&=V5PUdo;uq!AfZamR>^W9?IA%TDndrbcD;s;S1Zx=8pyE z{G-=GdFYN5w*f9WpVS7l*YC<)hp(~^C|hCkV7X3j@?4X)8u+@~VsoA>k~obMw{T9U zgZ$7tfCU9NUs;DTn<5G}IBsBg*m_uet_Zg&YtU_QBp7nAUX9_!;=&_>7(uLl^et~! zo{qCqPggQPMF!A|+!IWfHXn8=lh}HU@l9#^l%M){kxIU^n97xM`36g$5afaGy*vj~ zuGShP6oBOv3EI-rLXccaza@JwB;GIMUM0?!-e^RE)%^Ooy8h;<;pey4Y^PTgDSBTa z6*$gJ{v6N4_8pqJqWlVh;KeIxXxq3|HrpTuGF2i zIgB;d(w5?=TS#ive(mT_L0xR?W{Q>0MW-7xg^HvW`E(V4I4fT&maV6m{DpOEr1M2w zCV6irmPd^z1R4T>=GomuLwx&DUnr04Oubg&z=Ioz{2%rYut*mB85^uCHg_EWd-iYI-!oo^jeX#q5z(EV<1PUFnAVEvZFIeB8 zo469SMhSyq1lLnIg+DdQZZbcOX(D0Bm5gMsT403@Y~%s@Ok4J@YIrMD8(HB^W&9$9 zJz_!#flAM>Zwik_pS@5oqgLXm+sWC0_Mk|rqBTkj(DLWIeS_o9XulSbgyLCpg3{rR>$f7Q4%xJw}$ zdLr3z(yhK7O-fqF0iYDjdTkp9CG=8d{B@46MZRi~CKP+@C@-!#X&t{K#W*5cTbJJy z-LDxSvn|KR)c2%7#HE4GlFV+q)$^Y=We;u=xOP3L--Us--^C$6>zSrNA8#wM^bJX>kS;wH}zx?VD z+;ZkFD^GIhz|tPtYL(bt?ecsM4LXvC=_&!<@reKL3?@Z+cK$AE_SzuRr7}JslWM1s z$ZzbIPs!Oa7pdN>gUI@f`XTjUoFkJV*-|7CW`!V$!DGY1l z0WbJ#J>{1ZdLHk61Z=2(E0 zLdoJp4MTMAmEgbu>)fv_vAr-7!tvT3p7+F<*A}ff7@nQE{9zSjVS1HX{8IJORx7zr zltzLr?&@n%i|&uesXWQ5gL$y;nhrQ}1$4d)>ubFWXk7yyA4gWgR&TSC1 zWZ$0psL}7;Kl2y{7(AK!ZZOSuTjWn-1ZT`Gd4%1`03YkN&u%8vOLyWr?x!fG`|p>R z7JXQ+0iiiL(?OB6-=Xl)*(tx*Rx1A6Yjow9S$o}q?!(BYCHY=7;F3g%hiDPJU-8Ex z2l#Ye4aomWCSAgw_;IJl8?OKGf&9V17`x>nmyrjkmv_8>K5Mo$22k>>!L^vHC73qW z;kh3&{f~u-I`zB!F(TOm+MimvY9cE4RTwXq;kaLCk5}@&v}cY+MsAo`gwb$6tX_?+ z{o?8~gBw!n38fD4lB>CB3Ug2It&#Z{4DN}{8GcagYs7^z{IASBzQBU}SB0f~y!Lt+ z4Ft|x#8Oqq_oN-Zppg0!{SBs=zOx_Lp6<>}uvKJ5mO?;@az^l&IlM7hj23=x&({;uD$wvl;N}y^TTHc6H>25kb zmG9)G>?44oRFRG!OrYpnzGGy<_Z-H!Yc54LT#|ylPZoWcuBX1=hv8!wROLNOA_SG| zP`^1Tr<36>NfX|$`Id!`{jvs>oc}1)C;asJn)FzPNhph@N<$ znHX=dIPUwvvyWl;6HlH97*KP;PUO##8of+u)HBj0Xb zeOpgur9}E@rk|=yZu{uWa4Id@M;;pC>M$rIe+M2O-!GQK{ANg~9^Uxg4H88Y_nHu- z%KQ191b)8U6sp)bXH~b&a5ivmZYPAh*DBUt((-&lOG=@45%-`9@yCGaf>4F^Y1Ya5 z`IZ{eYKC~fbALnm6RvNz#lPXWEmQ4WAWIhugoDsYCX8PA0eoH+`wl#7t@tytWt{!N zJTIX_ub&Ec$pY;p_43G7?{4A3L&M;!#Wz#!nIge$l`=;x%pbJ=G<8i&rrAI(d)I)v zuyj9TW*8*%UO!{m{LaHzTqvP{$6@8Lo5}}6f){S$lzHqE)TS}2*!9pw|D7Mle`Hy9 zg+7@qUKIctihFW>sgGa1n5q2Xcrv#|+}FD&vOjt7wno?Pa6!b@D|#fM>%1$ww)@Y+ zI-UlueI{aQ@hs*L!66vM-%VJ^J~d68RplJFEVnYOM*|?$Z0$*SZ`b4?N#BNOaD53p z3@7a3vS@bKc6TVP;~d%F7G4yCqFe<6sWgP;QNImEw>_KO^rIff3T>(muF#L zLJFLwDT_fHQ~S<6B*>z**~e%Ewe?JGAKW65RGapd<(UNz>06VT=wbf z7VW>XLT#nFS33y=j0DnUD&(oYz%n>|1s0fu7vm8I4T#ixxc1Vl@<^S13zi1uG0HCq zlmU*`$>r8}+c^`TwWNfG0YV)$t%``C_U7SLr_)CY|ScqVxYcP~5WXub3 zCbg>#dAvAPHTA=&BY@MO#t#~t`|8x`joiRZzxYqla=RgY=*D^Pj|Dz9WFqfw^|-@= z(V(f?!A*|0ZhGMIRA#Pgt_xBk4Q|Gu_~je;~K zWzzQ0cFBQJ<#cL}$(^vT7msIPD1^rL2bBx}srz6|d?hKoeR0Q1=T|a({x~#8{;CMC za+t-d+FOF5*{G?6K}w%MrJ4t)W-M%}HL`RFaPmR48Vu>oJlBO)9}I;ITPr?Z9&}L? zu)sF|SoR;yl|gC^eC4_Hp${%z z(7EO!X)!c{ATL(>a)#Shff^D5Swki;5tsvizW`yT-+%Ur&P2gvtyz6U;nV(6``iu1 z+88d?DkJC!fKFCUpdA@=f>pG>GIUn|xw>`92D(_t{f!GQ#f730N=f;B-{rW-f)kZ<{Y=3z=&w#yP0aAG>RS1C; zy@9`d9-HDOEm;ft;5GCfi$Y?4xK@G3m~pz1^O4A+Z$};=ciKyaBI;z#eewGZUmF+L zjEx6z9OW~1)e5EpPvC1Tu(TehyX#ixuf9(yV1c4GmvYST`tjW((;7If?KHoeQ*jMr zhIbEM{%tPfFNTn zOhn1Y=QFRrhNN>9;4)Xa+gsMZO%s%Auj$jl^p%LXXhCrx_9={#aTJ zKTihc5ZSA&0cs*w!MM}& z-(knGy3$pd8!bk2z*NwOyHm_NT`0djVRzzpjoOd-YJDuFnq%;K*VpTQjrr$hrOrp# z3(nxoKhQ#AQ+awrM1vH2BS=ZO9534=Jstug>rA4vIw_A*keuU}iXKSM4%;a2QaCg! zPPkTt3w&eZIJNe-wdH>#{su)-3 zfWwM4`C02OdV2qMC;H_k6YnLBt=PZ9MJ$MqUT=T$J7GLZ$M39zGNB5mom zq)FO%bq)E;YAD&XkG28w>AdP3XU<@Dc{f=n6J*bRv6oAv8;}Z ztf!(|mUGIul(r7VU0J@UTXFw21X>JLNG;Zjk@8`4nj=Z?MbGgOH2bLnBTYNRf{7ma z zg~VdpwVv0gk#BQgEM3|^7tVM6hw4CM3`tm&HSajYZ)qjCL5h(HgY)+n?Q6wU-l+zDd91k$Ybk|1$-!XbK1y`Mkr{{voLDJc&X6ds#pIJe?j}ft}t`nzD=R zyHwiK>*{3(2Y$HQC3^aj_xNGCK#NFX*&$bEcp%Q+EA|--6%AL@pPc#175{L*4A$?G z#>9cx!`c>!>9=r(XQ$ak*xiC4p6lEDXz@yNFEmv@a-gsgt*RQEHnA(2cBk?0%;{_X6N?LGVZ>{cdj3oCX&z}Vg`hp`YhC=H!eNY zRz*E~eSP;c6|nC!qNXotjC{pn>*3%wT>Dd#689WZFM5%NTLS+=&q#g9$e4NxWpS{4 z48q4wduI7HRKWY~vKxTD4>R~BhkAB}#rA~((HdFey}_5TFsb_}s)X1PX1koYMj0np zJN(|s5qKYvWbiZTSqa9&l~U}GP6r|z!I-AU&+TMB5M_YHJwn!q5`{3GI#`fwQHuAz3r1llMLHKU+b$?j? z1LXCGAVH>ZOt6s;W^(rm)b7O3IRa~p8%HrK#iit0&x5#|GMz}c=N0im(kik$k*#f9 zlmw;()ST`K7bD&h;R&BX*bB3c*pKdGpJ;Ec7PHIpDZG9DP@oS;ERwzF4?htSA>haN zNBgGy7$Q~x8zt$$O_RcR>2<$X#^~62*0_IgrP0oSk3uY+RU_8+&iUhPkas!aGsN-- z#BeRg4Qy@|DJAn&lpmgD7T^oon2(n4-dK??_1-g?fgHb+vQ$6Rh(CS*^cefc4N6k2 zgIPHtVphC^vT zW&L%}IjmoyHnD&Ec+pqx_!Q!2w2I?BNMxIb`HQ4!1c(fh*Uq1ts*#5;k7(8N z6BV`(aNwMfeYzo4{);w@!NfPJNc`@XR=~7Dcz1Bz<&gxUO#8I?n+sOn`)52o9b1Yy z2aj@-mREfVqw6`|UKnIYD0|~Ap+RqsLZQ}HhAXTSB~dEt`97j2)#QG7FsZ9x6MlVK z7gcm;m3U)cAXTnjClTK&1^jtqqgiNgQzE;MUV^tl`*^N~7-;m%0g;+)+I7@Knc?{g zE(2BDf85J;m@PLQ2fByhHSPIya5sTJ6UtJu9!RV6tazJ%XcWE*kLKCX?PR+A-Rco9 zx!_)3O04ft1dG(ucU8UcBG8mc>2*v=*Bv74hwMEIg~eZC$)O>g3m|l|(HJ0yF44lc znk8%_Y=!wmv<;TL=0S`vD!}=2T8qZ>4Y|5~awR-*SWg{dh)>6+GR})|$EJ?;9&Z;}RpQIRl7||CMhE69{E)oM zM16Ncq~Y4?ioH>!U~bpTphE#@yY-c3*yemNUnk}C2J~5-wy(kI_qZ`Gh!pbi3iPY{ zowx0|Qo^J@-^MNil7e;AnWj^r1_=EK8;R#*;&ZrMmv>BCwl;+Cta{ABw-=<}L)>Tg z^l=HEhUyiqYQjpFDF6o4)OmCJamy<6DTek<^5)kEDt{~2xMp+B=XV?56L7W$dYacL zbA|aOj12j@ix2PZ{O$o4mvK>~8M$s$}b#sSmG#2y-@8ESI`}Oq|-glgveREgxFz zoP)Z-?{0ds|Uw43>-Zvcql~M&;3NNtw6d#M?tA0X=XS>lqLF0h227nIei}n@ph2QJ1^DHDj z-#_=N%r50<(#BJ?$%DSv0J z;A8W`NLn)GUqOGRWvUF->>|A^`J>VmJ`?1p%o5@!H$QdPt}D^;^CD zSXX&(6T^aY!9f{u{ zBvaiyShh6LqmQu`e9 z`5g9@;y%o7$36*)F#!1KEe|O(!hV~Tu!1HtK{L|wY&SVVG|mveDBoYI&g zODx=yh;+!qi|jA#XELF8*%#bH;}QVGW%*B-E;e<#L}SATCboMWL}EUa2;%eI-@QLp zYi|}A)853#0lR_~g-xFN6UVX)1z7cdzHae8_J7LNKaPLVg%G@z1dK4R$}Ogkq3b&0 zre2}eMy!;(62Td-Uv!_Y@M9&`^IhI$03hNYJJE^jvU{+CG$z=^q!_`Z5HA4P?;dCP zrIHPr>;CKBU~32S90+J8jBXRL_YR8rJm~z>)zp09DITGk--Crf$0skb20?J@gSg;f zr-$;J2Ix`YV?Qb5eLBeROtkP5nS8LFv?`M6Gw-<-h5e@M#C*b}bMlo0UmXwjYcJH_ zj6Z5u_5I)moHarDeH6j&CeBmZqEzH!o2vLkrMo+0eRzP zRyibU!+yuIj(zA!>p2r(K4#$H#)I!t@u0ri`T1}tXX{SydxRUf{0h?H85pguZJIy8 zP)L7w1?%0TieDNqknD9UMb`5Dkr!^Tgowp#2)<#?aB!Y{o3K56w&Ts^Pf!0gf9}P~ z9rAqRMPQBC;};SX!A?~PFp6`3 zqucV#ddW~Z2bB;k6l|THLk! zyc~NUCsw84$5LhX3c^y5Zr=T_j}*C3d!5l%uYF~kt^i$JpNk{gXBAHpJnc2yA89he z*iU}wk#ddsyWh^I!*NZZ=}RY>;98}mxP3~!El{^Q@^9~Vl9(xl$eVw(9b8mwmd-!( zV?JKCy2P|hv?2W80)zNvao;so-FNh|{Sy5x)0jBvKAu(XtysxA9`ex6u==kfq8Lae4y+&W6x;TAQdCMi{u1pnO$qFjz@Z#K-7+aU1V0fefSx}#^e5bt zNf40h+mdBq)ZY&(!n&*OVEo|7jI~G|r<1$Ch_B#@WO z%04~psgH{&k_r?f+JM9PxZUPW4j~D9!>sE_CYcnPga_f zds)!wi(Zb@XSH7CltEd$a^fv9(E!zTLWTDjkJ0x#mtAm*rKG;DP7l;Sn{4TF3Epr1 zMOhd3FzgC6_>egKUArKj+|J{z{z7~muuI{cAMqZfEr0WsW>JEF11t4nJAHiS^S(MlID?T}I|bx+#5&WKa#GrT{Sff|D`hfXiO0jif_h}nGnBz z-`2jab~G#oHT4IO4I)F9#%h&u1F zUjoK<`4_JhbTAx+z3sDR1Qd6N>I?Ef_-GeBdRQBHar9e;?Jxim^7ytM8{kw@A6}gn) zpI4Q#&Ew@oT;OMz!+7Lrtc^+b;TeRC5c67fC|n95bE-qDBag2wEB{L&Y7e~V%zDC> z?)m(foKbMic~_hh@0W88H0CqGSoUqQd3X(W9aX-cFwd-2-z0Kh>8Nqw)8Z)9E3I-U ze;(TjBwwd&xD#X>#f}Jc$P&4D<&v54H*{6zmkV}d$a~sHc$Nc%Qo#inbt=_-jJdh9 zH;ts>{eG)2urHQN z_-(Es_RJXL|t66^u!$-Y&WOq#i zU}W%R%YPh*?7AKAR#u&jbt{lJ?(==B&f@9@+Fjg&+DhN<=tH4-NS_CF<<eKg1;{Gb40s|T*T(2(QhgmP2w$M$wNxT+4K|$0)Bk^#=2g$zQh{ce< zl1n$;e*qFI@hFo^sVRxnu!KKiHB-sfk+%Jv$}hApH-~E0{Ik;Cx0%W`Ks5_aL@=Yr z0lIotV66FOl=>>1s`Djhj+4vW{A=}a$M4V70@kYQ+$C`EAy6iq8?d9NKF-~KVaAxJ z9V>oF&9y&O$#Zg&BC}viJ;wEGI)Vr&x`oDa+n%Hv_308Xo(`K5h<_zIfS|gsy6 z8WaX2ruk6S75!e@8zWr>UECvZIF`ONsog>unF3G;W_D*_Q!_*E0rqB&J*~f~y zk2gHG7c)pDxEsUiygWHzGYILM%)$Jc=DzjTCzd(*!$V|!r~x#tg|+6u(L#RQI%?rG zAcN4gcP(}DV&}oO^1bbAo)tY0?2Y^7=`?Pt>Ln{0mCaa2*N5{IzOD^scRuPziR0j9 zSC#Kng{7piUTJh?dwyN{U{Z#cJ|!|?Mwp_8*`!-*qad{x2DO%Z?q^?j z^>b$(MP^(%w?rTH+PbB28b!SaKx1~;{4Aa+{e3zQ(9-gVIn&kDf~8|{K}IjaEdow+ zpOez6AuZ`ZIIn6XD{?viGg>MrVG- zK>=L4>ohJoUze;np z`Ch6R{e_anb}+fYs=Y;pj6F>TH_`uigyjp{6OlH&RFL38sS%gbN~bReo{M#dgN3CJ z>1>Lf!J@MGUywBh1rk{4{bSySBN0Vp`_`ITgl zCSbjSv?nS_#(1`jf`Y0Z>JoOucx36bu4}yw^sz}6Qk#EK3{q>t`*2IcW~6K z0``-(TKR=CkM_N2sU7$?1=Ks^x1S{^}=@sm__P0$^>3%?wr->ts2R8@@r z5ex^m_E1NFmMozlxmBxWKGL`RN?QCHJ}_Zm(m3mn=%Kyo`e+y0erv>i;kk90n=lBO z^3M;uSafJu8M;?IOwSXWe67nFZUvQbh4=uam&h<{QAwIMly%)NtB<*dr>Ux-$9!_$ zDrf`ToplJ;tEBZf=WF!4zkCH8(Kigy3r}{DTZ$*?AvWPauni2sKht`nAmbhD{k&%w zDD7>L4<=?t-)@&UJR@xM;L+P`Tq2!Y|5+c5>zMq8K@PoPD&X|Xp`}3Gz00}=jh`++ z4<^79>}PT`gFY($B8op%Eo~bZ75Pl{;P&H8Pe70LekeUwBdUvdh`tx<_8AQMZQs6t zMtminP3Mqa(jwX{*xR44!-*LTI)7JB5dM}W*2wcIZ4m8ZYf>*|N|45?!ZK2isgivV zp7~Do?3PJ(F@YTqi^vdubblhXckz1rI(dj#?D4v7UV=C19}T-WP;6+_^5;h;V3`Ld zRxF~GBpZ?6-JI!{EI?|&WND&@U=d_8++sfIMXi2jE2-u$caRME@)=LgD)#`BQnuZ8 zky@|M04lw(>2tn4U*$1$r6KL3o=cf)h%We+A6lQnYW7kuheQ^Sk^#v?HRFH{b~4%e z08D%6wMw#`Og0iRXgkIjISfFQl#72lrFzAN6o!VEHdkI@=ZV#B9^U^A=>~a&>XMKc5(^E?TWp*y7MZ1mTH7O8iTzRG z7{oB(DB^8Q=IJHjn+m=TtL-@=o>*c*fF)0Gi!PZkUwC**!;rFodSS23AKsDw4pYHA z-_^vRX>NW;)ydw${m>1H&F*XY@}9UO{UORXx)!ziU0tzJ*&lz}&+I|wGS5S)|5N14 zd37}4BYI%cxzvlySG#jCZ%;m&d7>uGe95klq7ctX$1|f+0#hm~FyA|3?w#&touv9( zW`D8l9+BvXiz)i;dhO)CIK|HC5bc8k#-yi*v0w1LDW^Zjq;bcSNbJukw6Ri+=LDWCi0 z3n%EJqOQf@>ZnbaXWg-Rpw4b7>7k5&2k5_e(mO*P+Rx*VvFiPPj!});^1Um;X}30h zn)3N*(;P!jP(2`;S2x&adG?6!Hk>UuzTBJV*SdCBAL_LUz7&LJCOVPGn=AYz#fF-_ zk-8t&s(|<7$l~kBuOP7A1Uk)oX@WP)bIr9S0LIx75coYJ6Ad!*=6S&V6;mBtXJHxk zL@C$NqnABs_*%9UGY$RxJeqU-h3!p_@SmjPIit$-q#YJMgoMWVOqwfk4vc5(7uLQb z(PQg@l+k~<@Ch1xf9{6LT@e};n@gO4o6=uDXa@PgunMPR3sk;%yC~tMK~5>=@*xgi zkMG#E(4xq=f&Vn0P0fBr0HdDOh6u9P(P(mFqr>o3Nzez+LdZ;y(}vyzH1GFKi$ByJ?V&1;zj*ipvdt>4n$g@O z-6uZWx7_EC@N2Jh#5={2UHCLxuM8lRh6ztFZst*sf;;p)7ikzM8EGW2tH`pNfW z&YQ1G!BfYuEeR=F9sw86gSZ!nqf7;T!DqjB?JQK#OC0v7@qeH$XUs!RtDK=2NoHTb%XlV5GcB`S#N6e1BfN^8r2?SI{zYCU8*|3tKS?PqThQX zqUSol-pETIflB)O8qpJwm^$tv!Bs?D;pXKw6aSmjrrD!<)t=b>ezDu|k}tQtUvW?2 z(u_27e*IKM(HHG=o3M=JZ_|5j=^l03+fHH?+5Nw;f>(N=hy7kI;|>~Mey2id1?vifp9-FWm<9VN~+%@6?*` z)(nKH`;%7zH^#u%QO$V3|BGtNy`R9tcM*RX09Zp_zMjfqrbyrnxD3q9_E$o^!%+5N zlrQ^KF`ljxyA06Ix)Vjls4{i@jQO^OFwKa8F7eP66p)$W*$uX zNAG8R}#UBhyIPz4= z+x|W(<`kXB=P~Yjyx5fF)17`z&2>-<73xjLeL2a?d)FkNKW-C8@x?xuA63 z&r`n%b27T-kzzr-3eMbMQYL@O@&r&!1}9rD#-F?69*I<>jE|{aHxJk*{IX@*Q#)ms zZ5X)a*6^@Y3R^;`qYhGj4^&V!sATu+Y>Sk0_%k&x3BmI#XimBS8lQjYO}vEz-l>`L ztg;+gyq#1yc@OX?iy8Nhj%Db6-R0&&%iv3)-rSCFmu8JQd-sQy{T&H3>C;ahi@LyK(OZ(BV5sX z*V==-KSJseN;O$m%S_L~b;k7K8-b_DXb4x(fqa2MMP9b9MAq#^p7rYiYLL_wP6YW? z$8doLt_BmCJ@Bu`YYNO*N?C4yAsw0d@dqWcjhEh(vuxS5t`KH>G&3^Cf&-#8{wE=9 z-j3emYXv!Gj`%%otbFhs@?pMvA02^vl5io+(jAk~bvAnD&Lp|f14G>gf?#!tbXLSK zE4(9mn3Fi(qanz;jAxfGP!$ji6gzF@N-tn0<;9IibFK`=ua)F?;|(#QrGHk_o}J)(|>~}G3;6JNK*pTr~3!o;lZ36Zu|V>UX1jk z4=+Fr6eFYV;pqY^T0U)vUKMZ<&+ifpJ4rXD#Xwf9`AKH*x5HaPcF&{rIOl+v zZZuz-7@?wbf4?XW-d&{I;nk_7^ZIR(K^;1%Ccl1g5}D^%?>?;t4;bA}ZIyz^H4cBS z4LzL>x!|v2@}0E`2w!yBs*a%_IZz4q$_W;;vv*Z~Si^=-``4Laq)RH_{d|syB+pV} zSm@WMkco=hSHr=$tH+52?lB;5F;W|K%uxKkbsT*$D!}cAmi{5@nwg&x_O3y9tMYqA z46C_U*u&&3*H$te*sua}iu?T>{K_YTtVN#3`}eLxTRuiaoqOYTQJ?)MA)*>h;wUtR zJIZ$A)5|`e!wp)8sCw347w@ zDh-;4KyOf*<&F`V*+1{YpN);%@AS6~U*3e1K$K~GE%i@_b@c#)NA|dX^VicmG?0Q? zz0X&d;AgJvlleGbG=_S|rc(XLeav9zFiMwc%GJ2~*F;t0flJQsxw}s+cG)~y z|Fop6E8QLHPhnfF`p%@I^*u?>{rvpS3*J+&y1AHuQ9@-kDVxxI=hMC_^mBY}=yG37Z&&W>#~hs5zS(+taf?gP0P}pk&o7HXUcW;c7%%jc`P|B! za?*vK%;7`N*O<`!caNoR?ILuohBpgZ{B+Rv#)RWWmVMp`M~2h zv2p?3$cIyrKLJ&{zbQj&SaSHP#fc)jFx!KS3tx6Q$?Q?Ua2%flqDbr|Q^#v?bGsdG zGwdTYvvJwCx)9UBCF8ilU=nG4K;?6+pQtrW*8_jhBKhY%&S`p|k0>)8_XZgslet}O zpXZGxlUkc46(PQju=Gzc=VX+hd_S@A^R*me7+rezHa7rq_GZ8il@$Jn$=CD|^sRp36N9=3gXua1xBIQWwmE6t@8lNywS969w z8Ub@Aq|QW0|Ke~6ejf5`pP26=+4iva<`;uEF+tmnLn(IYmuxg64?V8}@%S=Q;s9zg*aoz2WKSeaVl^Anqge5QAE#g9$`6 zpmbhJ-s&nynp{vEqNb@3$u{A0GTS!+vt(B|T$c=t)P|XTOc4Kkc8;Y*E_2vEWVP|f zo4Ak2LgTp`415?TKPu8`K4mk(t;f+%A}1c%UWOP^5f0LtfY7ej+D4r>amsw!FKjw)2{9UKgvfW7_42T zf}|CNY-{`WANY6~{vEP|8Xzg4TCivwRfWJ5*%CFn)WV=p%i=iH7L(wf5ZlUtNz(TbKrCSgPS?j2Ketn+u z8-HVQeb2Ri;2#V+#IMVji?PZK#bds&9s?Z!bkdW=iXmY%a2FH}Q!`XQ^_%n~U;qHN zC|6ymNC2vF_Qb6BkO2Vcc$j72=5G5k`<`5s6`$cgh}GkD>Ewtu&gukfgddbQ`?u5P z(*3)AY-c&_J8r4)B^Hx?)Zr(2eUdJKt<0M^xfxpyaCxYWgIRmyIR#TtR?pL0wRy!g zk`u?(>8nopeXt{BVN3`9)Q5X>cIUtGwxG+Kw&B+&E@bPXciO67iQZ!-{RU^q5GNGz z)S7ah^2)4lQyL`skabHd?_jRJjG+-BeHlVFbGJTeNBZiGd?mBY&O}#xZ1)&nb12f# zi*u_R$p3deIw0g01JdthPSTA%1TnMoj~syX%Uz(Q&f1-RlbZWFC<81`E?Kge@#KF& zVIzDIYHkBtWaz8jPsa&2FL&J>GA)(`wA#;#@4=(kw7%D^EIwUcnJvcIYny)rsPJKp zND4?<;SQIMGsF{33b+C>`;_<)nG&f_<>9Z5!kC?Lnx10~g(v<6;|9A)3!PTFbG{i* zF@t>22X6K+Uat79ew3#${)y!68n9xH0@X~&;AnVW&{nhxHRWOfj9Kx#ufmik=Nl{| z@C$JIwZn<_Irr<`Q$x_2k~mU}b}B~*`aKzOfC>GK>h!|jj&86*KI;q-yHjE9+te!S z7xf68G&ze@`vjd(=rKY7tZ!>=v7q{nC0Wg>=as7x$Z63PB{y})`vud~>!GC%PLJ(b zJiVlSJx?9{4}Z4jekwYND1&rgiHUc1K3?-i#+I)>$)W=q-+%uVLhZN#tHHJ-LJA5n z^|9`#`cWf-2e1%KSLzncuF%G+$rvouaF_%bN?9_TF72&BON%)THn zSIpiU1`4izF!D}y?k28W&QL$R`P>+=WE>U0@KVWFI+ekB%T}+}#q+s7W{%Yza?*xa}QCmaV z>puI31bgl%#zJhl?za)mZ?AlKQfTH$6j|nNGMC|p?n@mj9!qwD^JyEjp#-VDM%|1S z>%(LoD|B}0{P5|(e zi6xe#3oAs$0ANW)S}jWAQtX4F(~747uQN?+Zc<;-kz7mnOTz%ce>=$Em<5O^CO=M~e)5=HgaS zgh?M^hz5`4;sp~8Xud1w4$a6V3rT%L66&tO+E2hS0b?^oqZkQIT2Ya#zEBiZjTIkb zgZAMBO#F|x`TIfNG7F}RYsekXll2>}zT!ixvYuD1Fihq|ykN@W`0)|@wpyI6FaBBA zI>qL6`U&~^z9PmAGEkJ$0IZX@g(5C1YS=^wvq#H#5$uBuP0|V7wV+m8U zr074lx_Kd)B4ixv2UWdEe&rR$^D}Quyz^ASbhplfZ_PdiEf|nEuxKiqK&! z0G!l;zQYvca6bLM({%+2hb{U7jzln?_WSCr_8&*5?)KBxD5R{a7$*e&u?qEfg>NQ4 zw|pI%zb@EQ2EirV2U+y^QvSyA-NDeJJ+%gx3Q@zA@Gj zPTHKMDl`d96Z9|rxdRFs@8JM^HLISb{^z~J%=MLRr)Kp4!PRj z0omW~?X6hfh*Hq<>bwd3w$BLDNRj2zynOpd=k+*nPl;5{K%nJ4FhcN$?OxEs!8zWv z{;hSrGO|WdFxACFw$gFzs}r0C?b0H3x~`}F0?e3XD%%VGPdQ06ey>7EFT#BCM@I+z znZ{rCKtuAAN7ApNI2MMp|Ko)VY=&+?KRH+P^AqQ=Lht-A6)>?8D`CcBs5S-MNQhia zLh#Lo^%Q~J2_0!q{>X0H!?1kwcGeY`I_z~O56mtFhwVMTVobUpu*^jWM=mf*Y%Z(e zYUyL;wm1mx_2WwYnv>ELXEXT~=mtJ|M}-*&2%(yFijEpV^0(8k-=~ttUA`+l({>iJgpB-Z zm4ic0BkDj1L!0Tfdze>ZJ}zHT`6ITP&{)Py0bl1#vIwEpZH#)@!lc zEblyBAW4QZaP>FQAhyfUd?5v_RD|?QLigd+g;;FWClpihL5sMiXp$hafRfn*1U>N- ztP#m4`liiKMD`@Mh^~A}RF50Ce{%GW5@6ky9iJp>mtO|`k&K|Qecn?YB*~2X?3euU zc+f60Ac5O%!@h1J0}wl2Ck@)&W0f2Qe0MYX8^C({51x``=!05vyVfH`Ou~a%-jMUJ z3y>REBP`r8hZ&N(zU0ZW2WiPKyplOmj$*NX_N&uskORWSTb>-{@OFcGpL=-8N~33c zEJOgCCDeG=J5>6Q6=)avF%Ch*i&&VmXAMs@F`(68W3!=%g=;+fg07yHQIoe9T zC$&b^0xm@+7l=oE7D9>-6!SV{Qmv$)EA$9;co>Otvw~b1=$OaSr3+t}UZ8~F)SjO6m8K@8!# zdk3IQ+vm(T?kH?PX$r>mjgjUm_3vMk_U8KWJ6(8`LkNa7q^gHa9i82-{=VYCDPE29 zehc4St_+8T{An+X-EYs$froq~vJXr`l@DDXo!*ii$}9$pnPkTk+HerK$A}gC1dGEL z%y?#Qn5K!-(c86OBwSljANMxvbTTd!)eOsIw$od8)N0S|Mj&w2{977n6=fkET_vZ1 zDPpz>tcs~-8Q~6*7R#F|-XILp9AA%Tscyy59rZuIH`on}A4C1_p$2{LiI#^iK;#m9 zOdOcJxuxq5m_58jCI&)Ykh*gDWFQBkiFklVU7PXXq7l~~0xW6R&u*Cl>@H{Xh@cvM4!AA9yt1X00AngDY

v$N=pCa=dvkBF_0HaHgVKN9U2`&ip=Ph6w{$%(hn3UqG~s?) z;^48L=db54`4$%-po)So4t?CJ)+}z;zVH3SvZ>k<@ z-rSGqr8aep>YJ!3TX0-%;}#XjjZb!?-hWb#=I-0n=;vVehUzzSN9{So${NjOZ-4Z} zU|W&({{0KR^^$+*D8ia_<-79qQIx4o`|sKHvulzKm)DWbJ$uHge{zwq!|?VIzrb^D zj2b2oD-v{kFOOi^Hp6MvgqK;`Mj!I0({EH+>&wAwyYFZ z-eYjCS^FJPZ0R}sgK>WMq3iP+p1*ze^x!+j@>i$P!DsB~ryq-U_nON$4i3-o6&Q|t zqTegmH6B&K&J(sjosr*ZMWaJg|Jj^A)Zf20eu*xtP5)`z?`%`-V20Rmu%p5+7@?*-Et^hn{YJa#)XA@X}_~rn@g1i z_Ubk-?yZ^Kkrbg{ST@ud{0TSl6`Aeo+-`J^_1@OWKj!YsW-M=;yg2F3-p*3*_EEdm za?nL{3T)TAEkZjp&n-KwDUMVvy*@YD*<e$eo8A+M&zL$2%^~ zMApa-+@_1>i_3EZFRny+us}Kw9pCTWqvESi8uwzwP460heOtbcB&eQ>-mvJ2%sx<5 z?`8jt^+nOIl<}+;^yNeLZ_s7dcdX*z92fnvRPKzA*)n4aF8<)1AP5Zdc1%X{Zs^1)u^q^zg?Y68L z@%`uSt;PWZq4ZoJYqAoC8tu>nDAG7b?WJzCp!`_ND6J^%x>cpe3 zIlsI0O&OeL9XIgoiJ>m`3U%L)184<=l%+{emh8?c3id61gh^+8$+%xxy?HIS>-oR3 z;tsVUjtv2T;1j_Y|Zx z=rmyWuTHwV1xDwsBX1`C8e4j4R6*qQtBb0X(chNzQx9MkeeH2*ebSnxq_Gs+_2k5! zS>@SJ&bHk+f5_O+v=%3Y-P7+Le%-U=#*N<}U+7!wSp&wOrXLL4-QVEHw_2#8(9fBT zI}-&*@-RwHJK~tFKi+e-KlkNF%kucs<(c8vgSPd4(5t`ZMqXySU1!#Dk8roDylbi7 zM|}(G{RLAS;aMLosI~sGr@qQ-s7}--KU$1DkTob05%%E4_jpOzIzJ<>Tje;M9q&`4 zwvXDj{>OOlz7yj|jsN!jwjB1;?i~*^*xCTj8G39R@`_+0UBZ=~FW9+eh!s zNbSv*vh5@1CNi7yZ~dM-l(lJEeEOHS$9A;y^c}u;t0Qal&21;+B?Hq9>9-Ep@>dY^ zte36`GoN)S+}`_qub-9j`LZFml0wH%PWt#Vzr*L3Wlc`wy5F8q3)T77-c{!Y`{+lo z+uS`HwC=O}+8Y$>cM~#w{?|)4J{4%Ic3)iYxVwIGL3)KPnpVAccjqDMBlmZYX|t(( z)0`h8_D`AV+@d2HzJ8sK)(=zW`qqwJGh#qgHbCC1JOA74`Az&A&Q9q+{YT{+$qVId z-sk~Q+UiqTeLo#cue><@$gjCGH&v8w#1%e1S>|cg zOum^BzhtI&%%>GZuc{as%sTpf@qY4}Gm?$NP@6^^*gI-(;MSmWRpXzNDSL?p5Z_Kx@RiB!(LNuxz#T!{LTF%%0(x-4FA>n(w_2zLH|J1 zy~AVowd$u59iP(R13i6a>%KkqxyrAYn^77s@2}Z?DR`>)w5|TWsO6-UOGXR`$_8Y8 z%3b)b<(Zv%!S3Rj^T+E3jjL`qBe!eLh2Zs%4b}-3jBoL-uoP|g2>Fv4sBYV&;pKCQ zGva?sPIf5*P{4}Ar%Mj=bgJAEM3;~T+Xj1eNG>rx9{;w(W)OM zm(8CWj@*@2@k9M$kazoy*FA5y?R=*4MMdwDs`u&k&-4B^=v`F}_V0=BGH5?@F@8rv z5hia_Ou}Q_U%$H^M z~StPvt3%C<#u~n^2_bz&fB=`E|RtL8BK=2{A*P7 z!@7CJjR>bto<5N@{t)fTI{(meL*r`Yj(fw}6Kp4Bwt?g4AHwCvZWS1>?9@`DU*E6e zcxSiA1(taqot%-ox^Nq+>i)_C#)J-^I?tXK4^S%uhX}n!?DMDwf*V5{tINARaYy&%?4J@xQa!X zo~55UD2)#$pl&yn>{x=`lAzq4#;HBMbWWFnT?7>mUlaawI*So!cjOsIRI=Nzdx4>{aK7zTV!6 zq-lJ5>5iT2an*|sON_W^<;OnfR4ayWqBDD!ZQQf{{<53f_DuQNanByvv ze|8^!O!uqXp_`?R;vS48Y`1lK9-i}p+gj`|Kmn@320XR9WhYT@aP+PeT9nlk>|#~Ix@3u(uvHQI1} zSY{&qn;>!BmmxR$ENQc~c=nHxtr~P0GAS+cd(^%3$d0mlvRa$(FE9G_{SC9cdE?&O z^Yy2$?m2z4Ya`tu_r*8wpPuiVd&~2%=$-Os#i?evKABBU@h&n;%Bt=aCN^l<{f0Nb zZjR~hc%Zw*T<<{jHW?-&QTdmd;bu zt$zJd+2_3W$k&e_>g7y1spG#}Q@AfFH0k8~>%Y64H>D`=P7jS96z%t}MbCMuzkf%K z&T%($+xNaF*Mx4wbS2;K7yY%db|HUg)FXVhj@K666=&9N z-!in3(dX0ZtKpCR#$459yvvZUDBzA*6|WnyMekNV&${{z(jDz%c;3J7sm|P^`r^p% zU&~tH9mIF=gJ zfPbZFsOyIa<0`UO6)QR-X-CWIt#kf1#S{J~|K|=@w9*$|e#fZS9C9c%x^4Lx9wUunYs^V?P;xyw$qs=EGhP~uasO|9_XJuJ#BANN;z;qO-Z>g7W}FaP%!kI1Q! zShAhicht3>%C;3n# z)`U+yXuq$pjEf3Yw+p=aCCw}!`|IY|f1kdG4jCuq($*=JEsJjs?%6>%qNL}#v7zOM zLt|@gnKLT;Sz_hEpG0Dfe?r!>1h_`a4!k|H9FEn0d%9!ri{+id`J<{|UscAcy}z%; z%wt|lh-)y5jZ6MHoX$v6cvZ`n$tPCF7oO$iuQ*12uw_Tl`;7B9Crxhhvim<7yNTJ| zhoPFXZ#!OMkW5&sdywFIb$-{y{C~2h`&&S6w(t3AZ9h-dy_!1jLc(`A)eqW#roU^= zvaWE1v!icskAf>5sw8>hR>gln{omd&6LQ-BoL~!2JNW7aiyFRpRloS=z-PEuI)~&*-=(SH7S|NF4<7z30w4JD=`XpT!p#D+ahb3^>KD zC4ebItVm;I1=aia3VJhAe=#p{j^p0WlES~vU!HrkZHq5^B34q`n2T+19KQp}{H;*% z*qhgCN24~iz?D9BhEqNTzLVc$X88{tjP$+v_#a=y?#8YA%pceKZSsPIw-<;0W<9^O z%30a0_-2n0hZfc;T3Dm_%dEJ9NhxrT{Av+9R8|gC2RHPsbbEuF-AW3>Z}J$k+n-*? zUGVs3zP=XeTwebrd-!#u<=;NNObS+Bn~Swx>AE9WQg{8&4roKh-NLZ2WOkzi{ImCt zq^F!+kg~w{e{I}pfXsEjsDI0zg1~|Ci^IKOAr*Kl80>jHW?vt- zE`IpznQiAzpw<^4+`#Iu;|}{HKD80|_phIy?w_8UG|zT@GyD8vobl31GFo@C{*1OM%Ngx< znJ*?!uGcINXTQOET$;1acs8$nZ(K^s=%V?_BM+8NYto@RBQyTWdVYsZ@-2CdJK%Yv z4#$#e|CM%|^yN|UtSg72e)R$0x~}hMj{W@R{*JiHA>+QW4hCL4KDP*iwq5IWdMRmF zzmW%JpR3AWmMx9`ZrXWJuML7_bL+=-vkZnT{{qNZJzv;maIDpspBo*oZsw!Yf2BpM ztCk_j=&uhkr&|oY`YsRl_0O;GY#7IQ9RI5F`j(z8d+;s|xPK_R=ELM7sXtZkks-tL^tCM+SzgN>5C0_URxjr(w6X}!F9DsRP*k%ARNw$+*} zyVHZec%y|}+4XMrGq_i_l#*vAY)k+3b;HarxA)kSl-o!AdRp5_xp}$Sh%$&T)cLxp zhsJ$Z)NS{E@@{>`gY6>=>%1tc+o+A~)-Ba+L1i+)zScirKKEG+Q03vTD@ zrxy()j{mX${oXyJA0D6jfja3~iu3mFZ}00mA57(*ncq9uI6m=dy_8{Z9go^)9+qwp z%K0g&v;J(kN$EWAvY~jzZ)U(G^YV0zd-z?T-^sUph*0fse6Gtje&DmkkO^1X_?ukLs z_Zc}ehZh*wx&2v<42{-7#NTIE^UiCA6@fk4+AY(P(D3%Gc+_e}(&fLpEzc&=1aYX6 z0TNcy>IJM-^u6^?Hn?ot-2hec&6+VUiW07yCUf83%}$|WTeoOBai8or7>F&CX1se^ znnOJ`2cM9i_oaAd>$5vLtlxBPf3y3wmG%2Htn4k@n0=vUw@ul`t&^vHArFfyuG^u0 z>bIJt>8ZLy8S5w2-ahrqBMog{!qSbkuQY2{as<`0q*1-nH%m!=q#7~)!*p5XT+1Tm zDoWi=s{GY^>&{@-4A&==jIkf#l_@6I>-Ib{YWbk(>Xf0)Kb=~-avbeP!tY+$rp!(L zXBQq-R3yT}%Xxlz&C5@bzxLHwr~exZ&<@q~w6N1&dab=sD8F+dGfaef`^|}|>RfJ| zXLsp`jhP1y%Q`;wBS)VZSsV);coECq+ z(dvsuMMdLBPm54f6CSZ@GbT1ChuS2M*q9@u#V2gZPN0z!hGkPeOtSPkxf6DXKHi$G z{itb{c1ySkbvqQy&e*>0+p!us*Xgs`Z0fGqF>2)07Gf{=NAsFE&M;lt^GgX|A5QP` zaqc3F**5>80JSC=wDf7~T3b zA~EX3$Bo`P2RA!Dv2w;n^kcmH-XTp-T9X$?*5{1adX+AV&mnIuq)(i0D$OQeU3@1B<%m8Vxc1;yyB4X5 zV|K(R2IJ$%G*6RTQ#OwI+2ck$bz}3^j6T~EN^Tan*G&#?Vx<>P<7ZTE*X-fcjel`T zHOsN~H6<&@*XS#y6YG0%HJ=OV9IPhud5_i8hW`GsYi9e$@sqMX9se?b*31c;ri|Xg zJ~zRy8r{fyLNkJ9sNGV3_1B^|9A^gVn|;&x-BW`{Fs5_aZ;HMPzSll|@>BfiVLx~m z%Zh<8_e{faKVcWc<=$?tcNnJ5_inud-?e#t;|h9>QN4yu>EEE&mxt?W;ZN1-`Ia*D zT|w=3O;faxSWFzg&vpIW#0e+kUtLb`S9e%?bM17jH1q3aR;}$w zSa|zG#k<36;>Z4IHTHFl+AY;vnJ50j-R%C?kq3$ATp(v9B=l;|+*(cRgSwHB*f6tx(v=18f@$eDwyOK2 zWXnpMG#sCtaHn~ftF=%k+bdX|8r~*%$`GuMx85sRtV(OrE$gFp&9J$*_d2)yoG?Po zS%-h!rQ5crar(8MM4NTfcv|oLU-8x2AI&AS;)H^{FN=m6Sk#h*`O7E2ChmeMi1z{wt#kelt-|4ez>2t8{-rxI@ct#ui#y7(JToH9jUk=n{ocg(%? zAMcpyAL>oL zO+H|px3RM`*L1z!A;r_&h%acm_3N>xq>>w=N4V|}h~QqI$~W*s5K7;vIeXv!x)YDm z+8pVq-yqeOcl|YsRWGYkzN}Y?3-$Wd+Pa7r5p8|*N5f4;C4ytkTWxjIWgnKfi}Fi5 zULH*I$Gw|!>0xL6yxwWeF3U3dXEmTSOvYy(|0d?vjpJ_JK<`wdsaV;g<3Ls7>KSXs z?R;6Vr+9bz#B%+n@mpun3oTaz`u^99{f9bc8aG{x)U0v21SNSe>2r2LXVtMmkBl{* zHmPn`x0*5}U)^TNvr9v-%|1YGkIg!9e6jwjZbq}!<;~?=_4x8(XP1v(bZ_#rdKc?| z%XmKE+Y~c;=d)(jiT)a8tA~E>_>hU(`?=?|vYZL}`Wxd1uJ3b$QtNY^s-R%UIKunn z79MS_i8K0LY5tB&k`To^hcrFXQD+{Gtf%Ai&Tp^Fe!x9REIkvg*&xyj?(yk@e$$^6 z)G7MbY{xOxzW`tzIY-;)(7V@sag9}easbgmq@qI4u{+Uik=Q+F#u&ognXn&iTR&^r zry4N#%@)#{POQT^`l)`Mq!QKiX=`}RaieyQnOJqQy{f_HA!Uh2JLeqz4gSMdZ1#lL z;N$JZRCMb8HVJ+kO_@_Y7eG=I>LQ1X*PdQJxUfn!Gb2BLVzc6fbLJsHl(CiPd?Svr zAq-d=P!k%Y2_QeR;SZQ*(!^n7AZaw*^Q%{AG_K*}_`)JhpUn7rC%WgKX%10bQ`EJI z_$lX0&xP;q-C(}?sa*%*qRt--!oi1ndf>Q+By?|H00)t9cFDG!8Vw>1kY&Tn8c~#X ztIG_;hF7g?rB8_tJLFi{N*}kBoVnsVxZ^i*--&tkneh*ACfXa}Kb`P$o}9_OI{eY8 zIVq}=iMuAh?tfF>iom>Mcw1K}T?k=1e2>WmN0*S(hz+<6ctZR$9D zxM!>Q{o~Vh2R^JIu1jgHr!DmcT6~-IVO9TJh*m1UUTS_TrPIF4e`T#Wjtcjdtlb&< z;!5vSeDn2&?AjhAGeTIB8d?CCY;b*|#?Wcxim@U?%HXLJ3TM7s!<@60yCAuJC;qYl zdp^Fn%Dl3U+Y^GN%e@@yIJtqDo@-z(?#N;U*WHcc^WfHUiqgKW1%E!4m7kD-xW;pn zxRvY2LSjB=pZh*%lVqI%cKQ~HjLaHurZ>;)KU{H9T(SoOD+Re^NL@?M^j|;Fo(D%S zUQm|o`TqI!)uI&5Zr1mE2mEIB;n<$eab>Hh^)@NCEzUZ&_#4D%N#N)&fa7}U`bMnX zKDcy1kTW$1G27h!!}0muOEMPL3ycHvzPk%}d-GcNRg^-cWPE*l&*JT~>jx*+s$1t- zpNg&304w1_sdpVr=b3gDM{&f@O^p!bv|m?pIEgbq8ywYHJ9g|C{;QWbv)p(4rj>vI zsVYwE%OKDnv0%a)`VF{5$)wNcS~l3fCcXlDc2eC&wzYeLFK-l#t#(bkc5lCz3c+EI zw#g&1bNebQ1LR@;Cufqt@6Oq6y~;V2)hWsU^c<2C=M$#wZm$~z5hr_Y_Zg!(A0V(w zvR+x+{`%}T{WTM+tDj${N_W1i*P`j=62a%2J8C%RbRY;u9U0%h1K#nr`pYW_uFfn- zNdb>C_wE6|ePBk{>dNcfsqMaZyn7^l^rd?C%7MPe8CC0>^`4gb?A#)$WF2SSlKNFQ z^QqtK#ZBG1gqeA2PM00LS_g|p9~lpcQk8KED&c1bv9&(2WMh8%miUn_lhDem*FWk}W{`uS!Ua$*aT z{^fWjH_GbtfmN%jS4qYs%CEQgp(4yt{wuVuv~LwZQA z++IN4CIFtV#0{v6K2O~ji(-`02j%&38bm&k*C+;lhfz{Dno){tA{gsfr|6k%-XMT9 z#+}Wgs*1rkpyv~Kcec#w=YyzkM^eMau1uexrz|`#S^*fjP+B#(jR6@4K6N$&kg=Wz zODVE6Z^KpZ)n=*^`70%Om>1M&yzyR1cvL}bvb_SURbMI;IUq;B>!88Lg40SnJhN3}IoIa?|n6i&>^K$7Mx>^^yRdqHZu#Y%lv#F-3Els8hD~ zVOqp4C{BfzXlzClIrVFb6e|TSy8fm?R=VQ8|2ah3E-Yc=G=Zmvb_m@Yk`r*HC(0wQ z@VYA&deuGwxjm)m23dF*@Ye;KbBCjl^VjxC@FTcKrye5b7Y1<4vWoEos?k?^|Ecs= zs^=%*F|6~^=Jxqe7X5Ie1&zO+NWL*_7ByOlM=X00!j(jHBBO_&b>BwTnCELDc=?Cl z+>C(GnZHHu!CEeI%~2J44Rczks$@^_pieOph;+!=dZJM@!fcZqK@QE9Txi`vJ2k&T zbJVD1X|1BIcyxxm0>f7$L}SskWKzS^tOs{1lxpaPOd9WfBYQ>~P&ya}rl+cT$`GaI zIWE!;Y23{<1G!JcjRo7GT-@iyQhU!sgPE~9F?!={PP>0_Vl^i>w^mp-54aH=z$!#3 z^X0bb9!KDDD*Of2H|;N>kh}X>#T|-+%;57`fhJ1{eo%XZ z;b>%k(<_qoZ|LXA+e!?)26c&`k}%p(N~AK+1m$y7k@+uJvz1R>WtBgTpJGPgSIvwF zP#eXRl?-a3qTHM3gZn>y`vAbAbmQnmYghO!x>7>oRi6VI7;S7=6jFluP`OyK1$FSs zt{t+_dFI$9KHNTZJO8z7RF#CkZRH><=^iF>4QBHG6F$jJDN{+_d?p3!4LxHj<#>5^ zcv*=5^&#T6McxVc^XTzzEhrLJ2YPf(P{Z$JZ~m$zY`Z-qG5|*xYLH4%cF}p{he7gm z8(KizYY;j4y3_o8w>``-;lA3iZ!CG#=sKv^Umqz$n`kzis`wz};1zU4@GuL+xUJp# zcOTov8~p1J3A_PxG3fLcfz?AtN$eFxA zYUTso1qc64N@jFDi9poR-}oDvQNn+8JyD42nJWIIDF&-3KMyMqtUR-&j7g9HtfLlea@Eln7xI)&4U)XlaTTt?S`?bX_oMSiXtUV zoKLx5ti8q`)sstN*4Zx>3E#i(A|d1W!LX7zy!XAO83Uz;|C4 z9doVT;(bf9S#|tkRteh}WKNq&BLlLSqp`u!+= z{14m*8DUoEES3JzefX`NR@LNQLbA2t+63--D<u3P#tS((=jRSOhMzcrsdMpjl_Ax7!^bZWo<(Nm}if0u2=I_=nHn z)_EM(9^RrH0q2OQ>V3j1@kbFe_Ck7_T;Mva00HDX_Im08trI1JUrzsUibZK@G|6u7 z&!L?`)vgcuUuA3!=11{&IOA1|OQk(NsAs$Zyv!n^O%@l-r!)V}mxmZ`$21)5nO}2= zoTv~x+3wNVIC5b(I>ao*K2Z$#+E6-;F$_q#zZB=ggkezCdz^9-j1g<1f~jEK>{t~bqd8h%TbbVi->;*f z$IvGCf?$BexYB&H?I+VQ(XB%|N&+wwd;+H5ZrA|yy)!D~CIMhHQq^yP#rX;h@@;Cpv5jtU@!67J>FL15 ztCD$Lp4BSEFdE6dCFTXX>evtJIVymWS_GQpJ;0Bwwy->kSk&};Y4s)sjOEEh^-J=< z9$;jg03@+rWKNRf zyZ>7Q)nwl$Zb*(Ni%q)V<8Isio27Gcxhw-HqjR7W4>Fjs##u<=<~Wam?#H4x{ZYh~ zz5+R$%84F3C%RnJX_E}x>st!`C|VZ%nK}mpBhS7+Mqn6bh3Dvb@k1zsG`MwoOD=Ec zYju;y_p?W`swHbRM?v8E=~fb~^YJ*djegvs<#Vy$m14RJ)eQ0#!p(=v)wlxyMe}uW zwCXuneA!RF3EB2pSFsPe%_9J;uruSj$Vy6&lim25E$d}}T>Bh*iqGMOW?1k|fsF$^ z>{yFAJ=evtG6@0ut{dTGEMd`+=9^?Ay|Tb`P)~=Y5LKlr?D2ki%G@(Us`DVld=nB~ z3M8WQ6hS@+v}!W_WPxpxiUQECnBoRKicIOLT43++L{mmoQ8jwuV|aZWLhvISqs1&B z(O;hWV+!3oOVUIc1w>EClfR)$T5-#O#^7&v<|g-y@|7tO zJE@M*@i_E=5ZlzvF6|cq3u@ZSd*mlrm+21UbRR#pL+m0qgi2u`*f~pafcdY-3IYSs zz4?U@JkI<&o6Pw2^q9w4EnLSPX}+mF;xJ;$i5B_&r-S(ZJP&+eu9$A5h(R)?bl@wV z^#k``x4=o$J))Cw=rPnVn2Zi-aMJU7@9#$7q^XwU40)g0#lSvY?fsp09QS*6Tp%4O zhM#2V!S(7g%Ft~+e>+llFt@5xWG75 za&CFD{M~7}Cb$YAW|;cb;OHIzxFnXj*ZXR*hn{HS=%gkdlV(F;oM8X`{q5(5 z=);Y1)%DS0OvUqJjzW_f)O|{Tvx9=2BpGZ1s(Ff0o687?9EMf|NbIUzSDvOxc$Rm( z+{%L4b^f+C2B35jApBHnZGYxFOxFom4bV@v1hnKoNfY?Nr-3TVf*UJ=-4yH|sU#tS zU=s)~REHC%lU3ZqQlj{K7cTAf_nlU`p&sBt9jM!Ynq3vt)k~nnA!mO||8b)$OX9QJ z>JQnak)J)FW-I`x9#<#KxG@$}_$Hfn&A=Hxvv}#UppOPpYF!ttjjaYUHpZVso6S*FWxxW9b+l*Xj5OQee&cS7w$sj3IPl?_tO`3{8Fw^uqRAs-T1~P>Nxk zs*}1D$kuaZ{Nl1iP|1)_nsK+1QTlbg;wB(EizMOKs~ezh#Lm2Jw?ZiQ;9pjC;O2z+ z!0-ok*#2^V0$2@z)K<$6xV~}$m~B)^@Nstn`=wXV2-xnIzyQ*Aqnp4NFiJXPfz`yt zNvJ8s(7hS= zh_N3omhdoExd><$CZ83u8+$TVZuD`eU%%ECIC4CN%V>r{Amf{?Gz$iaJYERl+*=N( z={hxHda--T1)%5|#-l0MDvoDvYniUG$QD5iIo$zo9%O9r4f*ML;P&f?ylGdx#azB-5-|v`c=2 znb_>jGYkuy?)cTT6+6lP!1r+dXZ(FNT8z%@VdXty^iX^2yag3E!S$DJs?RapbpF)BYp$*so;@!2gTeFmVz>=IFb}9_b$mL%K1lM@J2+7Ok>I~yX42)`y%DOo)|%Sq!>sF z9o7Z>Yru2I^app=vP2xxG4y=%)tTLw*QeD4oCVmF1KUZC|V*mtyQ$fClE-ru7-?PLlVE&3Rz;?VH& z?)X9sv8IEd z$X!4V3OyhsCN*CuAgreR`{pKnlodId5njVCGnRQHP@nt3gWsf(>$XH$jSmZ=e4j)@ z(NtVoKR9ICr2(KO>;D>T`3miXAVQ{)iW7?nlRe(xqt%n9Psc`?JepGvQlgbcpLg z!927x*EFJv_OLDaV^pT*dFdIV9JiQ(N9JI=-?~LNTr6jnR=1JZe>^oBdy}sa5}9Z_ z{1r&2SKJdThtFpAia>Gf)Y^@++Kv{{+Q=UeYe*w;HA92R5lG=&KP1EegUmpS zVxRA0?+RZxe1XVYKsz~NVO_HT&t05$YWZ0q`4ZPpcQXnSV~Zr!a8e?H&&Q&gPTpHS9CN`Zz@@Myo$o`4;bNk-L*g z^FzkjFKp^evm+1EiRf99*IWFSa-RT`REEOHgorgMeHNQ+pgI|?!~V~ zLj@imr2jmh*J-M-iqee#V1di2bvi<4p~DLZiv_X5O`DOP2($03j(w?Dh1~pbG^|b+ z@s>#2P!IKerLTBne`>r4`fGhGNtrCze{vz*e5OesU)<9x=Vcz{$H`|N<%T>)_xqDL z;O5un-#t0hm(#${ zUw-*0NLlU%+2k~k$Ed&+$aBL|UMgEE9#CyaKow&xk-87fXMmtG||k#HD5Wd#_2>tfs#yaggg}j5*MSq%2?+a!tUTA8gmqfC-4{4K9EQ4%8|lw zNTFfvPy&?CUq1y+&&`SVoIjOw6kigxL&!7~;>o0x^gcUgRr{U%H3NE2JdP_N>mLs* zIwSG&jaXdn!0QT36y3&6&3nFUO00gi2@?8K5IPi)uPvY5+B+;6LO|7{j=Grv%U8&V zglBWI*b>2sDej|8YNp~L3p7A(l<6@|ifA;%+oTa;Vi913!0XQQP@*6cpOE|Zvjal5 zP!_qOJgZ5?hRDW_7uX*pXCL|?M0*kQ74ZcdV^Gm7*RaDlVM|j5^zUXj7PJ8sKn##I zpZ)w;G&CF19gtX+mHs%6tG2)}PefD3lXkb;M1df&f{*({OcKWsq9pK-57K^!mPo6R zZdr|8b@12tfzpMXSitCwEfUQJnZ|4GZ)ebb-iQmH-2^`v#*Vo0Qtj@6W#5@PIny&Z zHNr61M3Rgxr~VMhLo1;R40N#IyAH9!%?XPKK}MRN{M5y(d^3)0PD9_4-?tY_o2`hv z!rok8i={-wxiCodlw?Uq@6(|eoZbV6S=lbhG9V5h;F zkytYQ#3hB}1M?kc#zu>T&FMt#w(M0 zTLM2VU5BGGm)lBhrGofEq>` z=TH28y21TpGly=SeVR)f;q81=`L5kRH;UVIKcm#zQFt67#N+Z4WZsIl@Ua8)J9S5d z?)rbsiW&I%c@?jRnEGy_GXM|g$H&uub2zRn4OU6O2SsSV-W< zNO&$w3vU+p?a!qNg13)XQw0}$K4>I?#;O|)b8BA*l}mAQ#sq&390d!liE84GgB!ko z^~?OPS5v@r^=Y;FIt1gWB`AY7BC(zHBn@ocH_KY`L4tE)dDq;wR3{8lks+wPOy9t2 z;&)lATN3c?qE-`T#g*oJP@)ihSDtaEnG<+rEA>$D^5#RXuB~3`#kF8xfwj+h^ROia4PZ4CY z#?tnw?J#|zE?1P15ekl8#U<$almc^aH2WT+A?s++)X;%f%^p$Z%_Z#r@~akCZkz$0 zb1yVUlNgFVb~H|aIR804AF>m4DQSNitJ~rA?Tvf<(aOx;_7+`nJYP_=*mRXkT)7%! zqgTSLr_VK?_v;;!F9913nNl@6VZeXda@ASeJKXr{MOxKyCJ#jTVRPhNqjmT5L~`+Z z8=_06f@KEm%h#b0^+{*BKlh1Wdrr)sZQ^bF80n#)_OW*r7M|U+iern7l(CMBKtp9 zw#IAt9Bmfs@h;8EXl_Gs52 z5wcJcE^}1W;NQIwp`o-1OQO>k05EdXK`1WK)x^nPFIh=S~U3p9$n^EOk zQpd?$3=_tky)@mWktjX(n{l>I_IU!KPBE{{%fCZ4=KI4n*Bp-%nG13tqP(e(wtv;H z?^ORKYe{M_I`3Uiqp;koL*)E4<3h(ixo8tN|4H0LZ2o#>oelK2YPg!#yd-r~c!@fT ztJVen-;5531El34b&1x9`d?`GcY~iJCLs%~PnZkVg(>U@f?d3(6={Bz$NjP^m0x%6 zgyp~##|Vp;XX+R(%;|Kiv{6R53aLNd7g%IVrpq}RH_D>m%d@q;J;i{NbFlqFo?Rt6 zH)kNhNZ7B@P|{g9#aws)be(H3KJWZ@53o}IDT3xJE1@77c`0L*3P`BM#Jin}mMcvg zp}B+`CceO@*B(K&@rmo^SEfm>30Yd)Aszam;MM%y+Q75hyJ4@Ho5ma8F_CKJubP|S zAbHP#M-$yte|sxeZRBcUpQ7{`^;n0wD{sCbT_=<5EGnu2)$olPg%Tb>kCSOA(bY2v zpqg>Dc@BFoq@Od6)dl;TH;LsBHC6=m2TSc!jfy#3HcJgw);c^xm9ceffFj_6?3E?F z+4nL+hgz0Sb|73noVSC-KzL5qxd2qlN*b~2wm!E_? ze;^2DRU6Cn-$Wm=8bLAC7E`R})T*A!U`|={KnLl;*^QR{> zKDy+r*BW_$3{v`bBT2ukBLUtSJ5{d$af^IBfT7=Kn0#gor5mi8;9 z3;yEr9um-uo=|>&R3nTwVt*1FbKQa#tE9AD@IGuu!p9C@^rq^{WW{wqUYEHx zZ;cz|xjh25bt>Kzk}sraWZKx5YCMhOOHh3Jiicd}NG=2i*W@iF`^A+~nrLp$Hu<#8 zh5c^#^~XYn=xMiS0> z>1AGO<{HjQpjxFENC)veuFYLYIjdGGnD#rW!H zZt95Llr0s9K3)%kj_8ldK?=6!rX4h$!p=JD*ZoLmMd#4_4wl~=*V3`xu%x0r?767b z88Jp%<(TyXY{^bYj-P|#6QXCRDnTLX9JHs+`>%_6rYUCw3oFX2m1dR}8MhjOrKDkh z%_~<9I^voAUU~x{4%6J@lf$!0iGYb$zYhe5(+72Qu3n$UH*26;LKs2Mr~lB2G6w8e zpVytKLkD6X0#!^8St5dk9P+*BIAfAM3hEAJ z<2T&ZQBkLDgGB{{T)xYr7mPd=-&XE=Y>M)p(E9+FrN6Q1DN^Gv&H4NoQTSbn^0`Qn z1wd~$Kgb;{fALl{9Da2jDqN-;K&Oejq3YaDd4=OCYk(C+B=LfdE*aO8iC$YqZ!R+@4*a$Ij+Mi!DF|Pz!#2p7g}{eH>9fhkbYg)oS_ zC^TPR`F?cjwfIQ@r6 zc(g`ac`q=)ct*^N>7)7w<%od=VPF8D^gr{;?0EqMpURynZtvin51Agh?#~e2h zh^VUlgvNxQnK0nQbQIKPoYVk6I|3-+|56baaG>dG!oa_AwN7)!0v28G;s$AjZMy*c za`41d!PNQb&i{}EQd7mii=EDYrKU{3c6i@a?O6QV)$Jm?={kog z;;U#pPEep4WVS}ih<&I78ZRGuiUFbRAMb-P+PMN}pq-E92|#+ zh5%&=0kCtqPqg5`O-2#>)Xm9H?B9^iK;dz~V|nle+^{CV4$J8NyiK`HYLXcv`D*@Q z_+8%gmd-m?>whFI6r6_Mo*(aQXgo!(7OLkM0|!oi=ff7o)xqiT)`AV+8>p5$}U6a1Ltuce+$6Yhd57tU0$jY=)(9l>>1$7CJ zO%Bo{z#VMlXccQd2Ee8T5ON7v_E3rgKTf8!pZ-*h4NI&;B2X5UK){R1I>dl}BA!Q2 zpjhuy;cTP_PdI!LREb)4NO}wU;-4~?2MH=nIIn=YYVYjO4#NnvRHYR%lh6n#(7cnW zr(OU^VRJK2AZxHZ;KM8~PIkF^y<|<1@Q{(=`WNMf#dGparqQQ2dc|Frl`$-l<)e+U zGGQOWFKF+6QmdNDdS}F?6X0l;0D2cxsA;e+V@wZO0xU!iML;s25f@U-z{l|~GmZet z2czS*nQi%jK7;HK07$!~gN`$zn&}pYJxm z^J2Mplr$5#H{_WWkne_m`5dm>Sdfz6CKDLL7Im1?vMdE84aOfB6(KhYgl>F9v_j8l zgm_~|>BU{FeF1AYj>pq{3qAmpegsSy@o9~kf&%x8(pC1E6UN++q}DZbi4ac!8oqx0 z8Z;%~CYSPY1NV!%*z1Me1vrW0!A%%8@TlYt*(mcf{{c$EpHUBnRsd7i11L7_mr>?? zXy4=Q!vw3pt%SEdrfcq=+=ik*p0QkNU9*uSLmi4DtRmw)8hpcqWB+?UjgmThA zze$DYqd5x}@H=zEO8EvH5T-ZRuYuU}qW^<8m;1v(BID$Fwj0?Djam=&fH*qh9FQ&y zmwB|NVAx1o`xKSGVFWQ!PEUW?D1c$JA~fGz-2?P&boub_L+5?ow=9;SBBXzT*yWeP z`j7YWnx&vAJC@?&SR>FGE57#g6BfR^kx1tJD3N-+Gn}GxZYfNX**tue2Zw0rITFs? zK*~Wmir=bOvIP{eOY^P4{)hAW3XX9v9JtWPy`$Bk?;vAUrW3)rLx+M2&uF$!c+mu+ zW0{G=!`kKU_Y-O+gT=XaZ0QPDG{P7RcUatMG#tCQS*H#0)W#t|N2=C|yY?sxB13Q$ zo#>*l5!YjHOe(GvLJuPgBW5U>Qk|hvm^E zDFUha1_xiL1EQf#smwA~#;i?K9q!&8`wK|&tRre|yaD4}&V<%CFFnr!8!+{76gL;I?(zU5OIeay~(^IHS6y{ z?szD}0ViJlA}gUt&=mI|s>Uw=FCxoZnKHsz`PoZ4*7+bnB{PZ@I|{J^QN(?q-VjSJ z4abo*LRGz>ic?YW@Asq@X`dja?}BTlLEU5Fr8#AQhA$@yyNCG2KWq^tWU{ap1YzkR zgobgvXHW=-)*%Pd8OJS<@byO#B4g6>E};Ka0l7DzOPgTeapEeC)m2Cx3Io#A+=%|B z*oLU{s%`3c+sCM?Tab-1=1_UZb%Bf5-T*!-0j8la1x1l&< zHI(&J`OOaIbXibcyko!9ccxG~i0@^?FkTx>$l zN3wHq`cX$uRG*onjB=_BgmcT02f6pwQ9jUX@O|BBdmBS!^_wU%wobxZc=y*sz0%9q z(7iYCIL1^LEZ>l|c3v=RI(>xDU5YXY8b{yrz46rxA@!+XWqGML|nVcCJdd-H*%0Qj59|i8Y{et+IQV5L5ao%Vxkknoy4EO@&Vw;*uYxwB#p)YaR<~< z5ZNngxMB?rXKTyV*+)mm4ms>{1u&E0~lbhI!cGQS>hnX7cx!h`$K-EZgEc7 zhyy_E%CTctMa-k?0`<~&-E&b&jH?9rh_6c8eRcpPyPnonuKQ|JE0loh;Pu)(ABfcV z`_6!w;UDcBP=&&oh`@y_VH{LSyFdr+gBFPPsy?=6qc5hE@qdkBS}X=K^#;|@r!5Q; z9*H0YR*j(K+}tqapRq*lg2;IYVWpoAaSe5r7B(i<_2qfN@78agM7jW^2&%wWAKauD z;ath`^5(zyPs)#x8r}Klq*Aa!zovZ~YKe~Dv7xze4W1gsu~L-WAuZLL6q z9rfVVOrpjeI9S}U9*hgw3W{-L0BMh{@MqBQpa=MP7C}1gaAb^$=H04HqCn*A?B!0$zUnkZE=S{hRpleCo-ZbhEXCQY2gjHzWl6Js;l91 zu=?IgZyfXkFyT5mJF}I#dFxIr@bItB@jBnJZ~j5Nd;@m(8OcBcF=#yjR{k!2>jTWJ zV?>i3;88Go{boXn{1pW@6pALT2I(tC0aXBu9>77U-Q@`UI|r}L@kYQc=D+&g7B6V^ zl#0EJ)4~bZXD~+bpv3-ExcsX^c)J&nWayKGNC30YFfhSS0_Qo<-8_nBlHmioDxIK5 zMqqYyG(tw-GvEmh$cL3W%rzTzTwGnAb9u*_8J+{ZkqQv&2$y{UIuC!r2uf=_CLDTm zqSFv-=CXRjFD_hjt1P)Kq`sp>r*C7^3mNFl8*P7bC7CLi4Sg1InCb%aw+Qy97p|D* z4}Iyvs-g6-+kb~|yv`7^VV0Jbj_20lW4L`5nL>>8$|JH{=^$MI?F=~N`#Qjeg|Ywi zcmoCK7210NO=L;f+Bx$M_OnF$IVYNs81I2Gt0^()A$cEUDSWD0z;=u}VR-KZXi~jpy&8vcp?mzGXIX_-VK7>ia;|Zwe3fl;WWZfvpOn|W_ zOnKzds0a{K(5eBqeWO2#CQ2rj3n@&Xzz>8{T)M!Itbe-o8FX(10-5|=N*2XCN%y-9 z+mU42fzYS*ch`DWNd^?d3_&)w!Xp39naP3ym&`<&DYvo^7yB1b`bW_o@64Hm(%N)z z0K54R9zSz6SnnFUUtj%xW0L=~s1w97AF`iert;BI)C6O%`0j6;T zPYNQ7+BH$wzCPcP@v91=rb=Z}rHB5;>Ze}5J7h5$1piIb+M5J={sLPp98;QOKC_r+ z*+ifE;PDUtQs8mI%MHI&&)wIKO$HMiAW{$HTD?H)CDd>NbU;bQhJ-^PhuI^*m#2~O zZ&aisbIyL?UZRq(@rtO~QGp9u!2t$VW7q#^Gfjn(6(R?GC0*7)RVUmK!I5th^eV%t z5|~bao@u1UCLbpcl3@$=A)1swk5$|^N5XUGA>1k;yJUTm%75mG>ehEGx(OpkNk3$6 zC8CFRAz2r8ARC~>zigkFI)lSV5u=2y;O(-&{d*aP0~cXnH-380#RR13O=zSTi#DS< zikeZ`Oi4C`G0wb^qpBVLqEr`afLe1L{<1NU-xzhT2S^jI28rwb6Cpq!AlX3ki2_cO z|7rm?$w$6DjSZZpcoha=!KG=d_rLU6dMjLnRA$Bwchg5wT!D)Zp%4hgvj>Jlt=wn# z26dlD6gdDLAWrdDU7ZL#3qWTJyAbS#u>SU^1U3F;J#jor=L>OJ@CrpiKO#Q~xM?x@05iEH2_Ov72qU#gfM3)*h z>a0q?YltIc0vvHe)>oij)*g)`3%qj!7##wHoNxRaFiaUhOmxrmq5?X~d7Mlr8hK#; z8PvASt+8xKB28bYFsZqM1es-fbQ`H^7nkM-ol@QR84hMdoSLasj#PFjRmN1Ed!`Ir z%=M(43hzKNSssc+Ab3j=iVXGCer@R{_RAr7tYhou<2DD~@eqXTM~stE3gbpU!nOH5 z(cWtaQQN??-Y@&sK0z*O{|1-L5YVL2G-OtI%(>r@ZxAeeT|T2l8ix<;6~dIc7e}>F zH$O5RP60;XZk`PAj|WB7&H`cU3-~RaF3I7>xTz@NLC~J^bJx)DYuROJpYn*vGS*PQ zXumM};sB$^$9!O*9o5mB$IGOT@8RHugg{uxBb6&`9teoMl%u4;-LM6@<*&@Dt9nqg zo(Usan8RZw@r1_k<*_v?yQ#`Uapd&Leus9+xx~FR0*D5covJws31jV7ZV6S8{ZVCe zcYtj6lT}Pzur*I^yt1)+M=2h->$~Dw%eWTz8&kK^zVJ3vIjq-w2fkGM|C` z!MexaTroFqkQ-VvbB)-M{FcepEaH!YwZ>4OgH^yWEK8}7uM=mS%%`lh))aX#n=*?l zixtPEnU6mV{*~btwB!ADXE}$cdt2@3{+DjQ6>qP=%_hN>ivj!i<7`1e-Q#r7Wq{ub z3v|9QNIC;ASK3NtMLsD_=$IpY27)&62rmxrwrnzGo0j_brxT$|gpg@*~X7;bU?xC#eip*bkZpPubkrv7L7e9l1y%ic& z_RKbFA$!7@J@8XF0)(99ObbC5IYowzXpP~hCoYvj1Pi9&te5{udhvh{AB}#CYMbyX z+|-c43cz0&eBhCkCivlT=0w#YT`xBXi}pBIet#dXi(2zIH7bxv0~g4@S-3j>GYDNw z#{V1~#?q;*oS+DL?s{CJ_f)|3(t#w9xCf=@%83$Z|L+Q6!r?$geRyhSFZukaC?~Kb zWH;aBMQ_tYRlalHt+S}5B(Q&oU_bvb80+P{pb2q(`rk9k;DIx$XZ_C^UB}BGcm0Ut z`7p-BW&9W%Rf2kuU)7f?9om+<|KHa)T*wB3L)O8q3R=dT;h(5NzPJ5W4TuMLj_Sr3 z?;%|u<~}VBCU$K-w~ibPoGu&mk>w>@mOjnr51&|4K(~$F@ya=WY%%U|&(9 zD=F-v_9?kIgzdCkJME2Cv6I>O16r9Uo2)9HkS0~Bh1j%Cx zH27Q7Reqjfc-IAvKpN-l~R@r?nHEvP_DRf@Xhpmhy0W^LKQSC+h zy&F5E^-_snWqscA__ARPN?^$umhqt~OeA5Q*Rw34y;=m++j9n@-NW5^7IVo_>kY>) z)UmJ@M|N)+ZqAd*N)I)Qu>lJ7ZH_Kqp-BE)%NJ!+kH5$IR3la##a)k3l3suLyVgde z$nkO>f+kt4MpJI_GA4|iMkV?Aj}y*n>3BFX3%u=%Ja!oQGo~;~beMpp6)Wi`X6?jO z{tVqMKWyn4_0O^#F7)I3E$w}vTwCC2k51W&cxg;S`Hjel7!X{oAL)zA1S)qL)q*`Q`XBK=&g#Lxa)ADcp3a3FyVmt z4ZeqTYrO`4xn#Pj4@!K+ZzgT^z$>#fIo{tXOdky^!Lsua3L)+7VJ_ zS*I}vd&}oIp;e-5)lTGprLhPQJA%u2ckh7(6m)Oo5jlSQ&X$uG^z1x&likwiY7L5X+zY zig#j_NUoBeF1#$R?X;urPX?)YbKQp9_qH9?0(2Rx!}76x8-%$*HENg~W@f%7Z5gBx zPODwDty>#nF{m@~;=$!klZ4C4nRa*TrTp_gvH%)cvrX6@eF_c=3dZw}(vi6{xY)Zn zH{5b?B=60un_(p6oWL2=LpumwK7z5|l;7?W(uDYuS}@I3`!3MZ{3|Py((C?Cm7hj(o}X0H1q9&C|zFjn0g&$Sn8~2y(KPoM;{f8 zZrP64IiM{MHP;PvDwL=99YMi#lZcG1Rc4fou2 zNz_j%9?>lkadMLA^g7#$ig+v--hT@H(fr*MRCtyNW^MfSxg(J!Nk9aykj z$^WMCJ5JRUgBLew6+THbzj@OcW0g;N*T;<75}m82ZcqRHf*L&^c=%n+A3ts8FRk>T zbItS831?QDo>9l^_<1}Ii-H^}KW5HhE6t6RvRMvPne@%ofOiz{_=$hu+0xlQnLYU2 znDwBH59Vmx#6v{bw6Zs~#J*F1G1=m|(-p$FWzpMXS!d_sr)j89!pI&z>#sC^5>5U4 z`@!*2WP$P**w2?t+jU*DJKJ8rjnvKTS=EjnVUOLLhnZ!vson*wofo7Fz)Mu6;vPTy z?xDO56NLR?*psRR3lF0i9oVtR2o`Q+;b!A4P!HzxX3>o&b$*Cpe6|s;STa#^FCB)i0W6dK~T{lOy;bYreG zy@?W3B2mdUXDjeHcZ}!Ib16=i`Z8)i^2pLTN6MS$r@njQACoanzpNAAm?uo5Mts?4 zO44Wf^+M|+&;HzhVzGa;*y=ajY_5@3yTKHm!x8S|hn~-NS=f8D#%~_+@D7Q?w6efb z7h9T47t1f(q@-Ot&&NG?cBan6JpUAxrcrabOB}_o4k5bY!@n<$d%w3;dp;Cl@;HlF zO529YqlQQCQxH#%$kWMi;U{b*;|Y$nJ>9Jg2CPP7_QRe>ED)sV}RC8@%A<*R;+SC^rjU-54JqwvOIpDwS{oiz%}l@NDdi_V550jI@x!jzH`kw6X+`Ye7QpKlc zwCCf8L1+QCjF16peyclK1fwn#<7c$#C=rX`WaZR+(OonP#brds4UY^@1cw z7Cx)$|0VpY#hejU=kc2-O~$8^e5{hXf`=p zc2X>ghl^0c?U&?l$^jy-ymQF_$ONr=7!Sc-GBy~Y6CX$e z3X*d%F4EAlTQNy(mRzAUG;DpYVTTD(y>}-(;!8*ClUSdmKk-i&*%sC)DT8O%|Asxz z776B(M^_QB1WYo60H!&K=oIle^mv?c`g7T!Jfvz27VY>Wyl`pQ`WaNbkcfz0mh1#^fYtX?%Z6mBxa?P;W^rUsShX9SiMy; z_@%2?)MG#E@|#E_M0WF{?qd+;EeJx1P^Mm_pQ9;XJC%!7f=fykecRwHS!OV5rY!#(cil zy0DweWm<@N-4CBSW4gYIyH55*8R0Kby{E94MPhM%iWI~*+gM|{UEuH~M!VZJ2-Y)+ zlx+ucOWpAQN7`G5Rkd~P!vb4jBSAd z^TsN5Hs5%Diuh||WZ(j29VD+xf27OAAdw8%a~(^+G`3oPBl@m~1M5a|b8=>c?Ip{J z5wBNbk$#Z@666G@kU;)Y{J+Uz8Nm#aAO_xZW@`xx_gcAE?0pv<9moT%`^=x}5G=yuM1?s%V{O{p=zRyMnq8}aGoRh;xU z{;`)ACk*J{g?d$Sk{t4Xb4p1jBsNtmPnpno^p$!*^=h_3LEhk+yx)OZ{Xa5a^Mu+n z%p!Y&HjKL7Nh>7ST~Y1o9=XEqxlhJk)Src(;RVfS+4bsYEu96or@o^N=AsiEY#%TW z=r9aFA5?w*KEqsl=~#15VoxJkTjl$)tW7Za_C!pEfO^7n-Nn4qDTPez&Y@Lj+q?Ah zQ%tKrb*EV#CxNAb#y45&FX1+`Dj8k%{Iq$NGYbn2{Wh)8{W*zC&t?1hUCCFmtkm98 z0k4HCGK4BJ8vGv((0yI}ot%14&bki0cf>Nh|9r%Sm1FPN$1+X2S>K=eNA4%){FP7k z-CV@9;!iLVEH9Q=xzLJi|2sb|mSD+;6S-<-yjH-E=BmN8r2UeV##Lpre-3Rz?jLK( z*%6C8tB&%^>CVx+jit};@N&-eKb12!7lDSDhvqo|AA;7Y4g@!ra9{6fW?e;(W}Q?h zxx087v;ET2WSJ{^vk{_Vy{B@Qnpi&F{)j2Z85}NpZ8x-MdDAcH)p7a2%J8+P4Vx)n zAzFU025-lar6pmnoZ54|F<0Pu9H}n|bhYFJQLQt6{l7VukR7!2Z6R zoX$ujH-rvY{beX}rk+w({H0_~M{4~v{yZ9BfJHH-@y^6cxJs)Fn-R^%g4`DK#JES4 z?ZlU2;$_1KHF{~j)J`$%vjsh2{U0Cz?8xl?wo}*EC^*q&iR)$0b*>hONn{6~sPbJ5 zZ;j5@r5_0uuNb!CwJtTvbol95#W+v-TrE@SXlcCz8kQ}z?O zeSVwGCbJZSBrW)I#F;T|53&`_AM%}-z-S(L-yU-&+q4b{xG;2YaULT3@%4_v!|VLw zgRW)qib4=$NXS3@4-Rq#lY4&;`Xqj;@zOjzwSnL@)Nnu|Xi5miW53z%S^_dv@htqv$nhB-al)o)|jl9EXH74*V2l zv-k>|x`|Bt-jo}Xo)}*9cyC^CDEC>qJ|0Q`pLNx%HP)csR7gEjXYGn-edope(F4-< z|6)z7O>vb8fyg=O#u4&`0ksp(b7_qVUK;`N^Hpr5W+?f^;bgmkrgQrDW^8a@X4NR! z5ZW+$%->Sd_&eIO?Mi#6ZS^X-u>3SWHCni*C^{!zK02tmUENeyDntH;GDzQ!S08hY z_xrEGYp4TuY~5_E$^LB7fPFO4@_HzIGv|O02{6U1ICafCkov7px1E0Q^VUnXC**!d z2h}2SP}Lc$RcA%>wm{4k3?Egt>o=NIR1ds6!CSi3J*t5B%%nK_H|CykZ_ux$-6IwBLaoLTq5v zz(bjcx)Q9Z)`1D*DY+3URI&1b6pwi6I~ZgekccwHM9)`BK&0C)5|2lZwgmC5wi7-7IPBv+z8U{3x=5`N1gU_MQ6KE@S zH`5%1hep)(KsCRAdNB(1)E>A!5w~$!uihAX8C&3YL~PoL9KY3+gN^$YfPr&Db-)|Z zcCs;OeQ89L8ybQkrGHRv&&f67I#l!s@kjuNcV6&7j58^-udZdx`v|@U=OT9y8wrr= zp}aSNqtnm7>{xcrh8QZOff3GWM-0Ca#|D^Ob}*huCXwG!wBx2=*I)w@^2*_qmu(tk z+OJ(I-C_>Sp>i8$>v`!%xBA`uQrdt<#34TsFee`WsokifOVKoWBEMo8$aBsodnd~^fztn2P=CIGMZs=f(U`e*kRkiFehmiL*#x-do5q3=Zmjn9)D_X}w0 zqv*88l;Zk5jhZ_vMP?r7@O>NH74|x$z%9X`0&aMSUC`kO8m+#cmF*7|p3C&BCCx@S zdJqr3JP198St6vM*x$uH7O<@61NVg3FHJz-FuK5O(FLO7A7TSTfAXztjrxyG(5ZdyAZKM-{@h@T9PEr$Ka>%cd zrd3(+=6QP^L*aU%NEE3&sRmax(k`rK``ev~@)1HMbiWxuUXBAV;t_5;dI+#E_IvT> zUqXM(X9oy?Y|<#0e72f&AB>C)iyeDQ6bMQ{FWBjj?U(^Gk#`-IiOLv2i!N7h8 zo;Sm%jLI~H%sp#0?PMg>Orh={;JGcf=t%RyOm!Dkj^BGfCmHHfYTLyIUMinT?KB++ z3)4Y^+Quy?bbIat=uOS~D6}w8!zz5acJ4#ApxUj*Enw$)Cz$U8&Tn1TTc1R84kuD@ z&JtW#&dIdWAC6XnJHJM2xY>CD_Bezo(VTp@z;xKe1Sp=G_a!QGBi zr-ne}Rp|K@$@(i>YPhbXRpz2DhM%IZ$<>RoSQkE+2GyrJ(5@}mT(k{AKM}P^XN}il z^SSm;Pp4)SE}1eo1HIIU;|Hr4^j8o%7(w%Z+))13k~$%8Z-qT>-6w(F&s4!T>cK67 zYnQBvTIe+kn4f_+`Rn`5cb1WHeDTB`{Q~Ea=*_y7MXi9D%btL^r+5!q0{d6x|si`5bDjnDXo6|T({~aZ}Hfx!K zOA@9tG&D3kUw-@--_;5mZ-&Ufqi_U3?bDD%u}i?v$baX zn|%k+UQjW#dAKBrrkQes$i%W0Z>_C`bia3!E^Li4;D8x?EUx-bTjLIz=UVR1@c^st zrQbX}lBFV!7go~YCOudi&(fOVE?GA8HF>nBKj-E@kg0m78n+IqU_Q9$u}`1AdlKyv z6!?y=15|&6%Vmp}WbE~+2xc&%`)~|X>e@|w& zPdxR-YQ7APufGUv2-uT2b930}SXSWVzk0o|L}}-Iy{q8c<)QXzi%6Fw4?(jkT|1-x z`rSENaFCr7ENvw1>x`LZc%x)brA&L+q9ZG%DD4A=KFLDiK8&LFSX0TH6H7ywvD2z% zvHoBQk}J^hA#NnRu4p-8SO=4PmCj@s zP|gD1enF8(rtQP&4P0MT9fd?%N$+;z<}$7Zc0%QO2v33P?k_lqAvxxj5$WQ}QQhC2 z&t?ai%)^k1-IO}3)(o42{#N=y4wW<(42bw9;{R#^e0oTdtXnLS)SRcy_W3=|wr{O@v185K)G6Bg=IFvoj<&@uc8^hohWWIS zK@M14VW+q0C<`R)^5=jl`3-!K5;bF-ZJ8xp$)&FNH(Y# z4QTbGDcWDqwYXp5a`yh3Y)aAo13$0j2mXjtp>tc!cd%UIwsxLa+V|+e%rFp0Cvk%j z)PzPY%likH3wUuJ-gdP8R$?Iq$n^q)ZE%S?C2VoA9Z=6MOeup!(g2NX5+&Fv8Qb?| zaf9sOD*G_$cTSzhNzhXReLa}yb;{k25JEGOrZYi=_K_56J}lVyFL&BbFJDxa+XQIY*@vXcw!2r2cP8z>}&PQlC>92hvs(c!huwHEQf{sRgvP2sbTgzef(dZ zd245oxG$Uh-_SM99HXM^G-A=qYrC|XVW<%;a_xXIyOQhV(f33h)S|r{SvzTvv5vE) z#3w^3g8#vd05*_JMFq(lTS`rL^?01~4WvSoE@{+EF679^ocyrub9T z=LxgT1LCI1(-!z1k#1i@dW1#VkX8{o3WrzGE`_m!QrA0f+WIsR^21L{!Ij6WSk#*6 zomIr(Tm6McGIulpULAN3yNA!=h>2pw>G5zj)DTgbc*wGS?EXaN&>{MQmAu_5W@l8= z$X%IRVNe{>kpPmJWH!=|s6r0x>p3??9c>y$W{4pP$g2Ht!b-+EeL{jzkS(*$(4fe? zudAxRsic*t3ib(6Y}HeivLKvoe}mJ(AuVBR#!UH$zS<^$zqD9t0bk~33zZRn?Ge)r zX5Eq^stF|~7ZBiK{u!>qpSgZ{>8McL1vmV*`>&G?Z>lMGoMcp0E<4kDjYJKDwZ~ZN zv#s+|)hsa-mIlBy?qVS2x(SV{E_|Rj;4mlfQAk z^HHNIzv|icx$MNZx(W~u9~SVGPtotfVgoM7Do6{JyQJJ1Hab+%t%Ul{j3^ zJa?#Dl%+89YmQlSPy+7u(98yjWn*XMI z=vqR_{{iT`V5Z=WN7;dQZ?b_hr9{2rg;(!v4o zd0ydyeXi}hHB#E0^-~8^;Hz`(bwFRLVD=FG+sc;iW*=bskh-2R;p?g)&xIs1UYy*s zNiW(BaVf_D`4XW0N%;^KY_sf>Z{E4EwLNx^*@fM*+Zzk)$pv9Thuh=y1zWv$2*Icub`~0qbMJ;zLe^87V+S)=W!w(fQSLaz~ zT*i?k!ye?NjDEl3&o@xbkAtF4AOX)rPl z)iW=T5%UyCT$rJWuC4>VPMVMsgRIXJiS^(gUVM+j7=d9ma3E@-{2Fz1%lpmXq(W)c z8wv-Er1Kyj5&jOgej8d?8H1~t?sDOBOu(pd)zJ8vNR?kvHqnhF5|^{2^xDWf*raEi z7|+seT&-|1*#YVN)0OnWc+X)?L zLxy(NX1P#q0s2v2iw!eP#2bb9}dq;p~`GQF6?M#WA1INr~bW6cIP*cfq4bq)tg0}Putqd`} z>-e~Y^J~h+Q|Aecvsjmg-?)B0Iv?4|WAIW9ip#$Ekm`VI(^VNAl~n`qP#lSDU>?5Z zFWky(3JEGwV$|(TH#-15(7p_jC>$`s{xG;+4|K4`ucrglTlpHv8jw6QlZN`xQyUSy zg~U}AeIIK*vFZ`YMR3b3HUhM(;t9|rZcJdT+T%IWz7(YF9AIN!{Y)!!upNhl5D}in zq&R`z7m9F{&_i;*Tb)3ad+p*27l{+d`N}Z0GEaV#WZ(!?S5u2DrK*scc{ubIik(=! z+J!NS7g{2qPKb-r=cC?pZTd}9$WP6-o=a+T`GNMfWPz4Wc;)GZ2TvKEB5Gpv6y#t$ zhH06QukJAwAGV^%QUUAjC3PqD(8)OxgSiZ=b+qQHQ9XG zoG?7PtTE)s2ZYqQxg)nrT8S*P^cn)c^+G zq|J=Dbzu{EZe{lYr-FI^0iP@b&66e_ z+e^ar4986WEN9wqi^F=NX4Krg{kpSY0GLiuHoG z?TqJa_c?ZKd`UEz+?G<{QU;{*8fhbq+d}1N=9n3pq3EEST|rjp77zgw^{-py4r<+J z!ZR|{PFscgTraW`c%meh4OOe>y%yLY4KeV*Cy~1)$8bZ)hE8pzh~v!{C%YOB#eXW$ z*m#JM@X%@D2%nPk#;JYhK%wK=VI()Y#*C@HZ|m)j1MkT#6CZqz+{^1bwQDaS=L-UE*u?0<`U_JvGaZM|Z~c?8-@% zARs3a6$s@;<@jw}#W)`|RY1&&?)EPazwK$;RNiyr!cmUc*LujK2xMe`D5^M$Fo--k zJABS)e@NWA7W!ed(XIu4$f&ELB;i@*EOif7Ys14KxFWVZb&BDJRSdJ{wfxJ}o1&3^ zvSNV>MLT{wQxV!>!VFifj-Dt$-B5Mhc`v6-p?c7(-wO;mH5I)iS30v(xn+gQ`vwEa z6O!27=k8_2sYDy|zxrTa@a-{6ZBr`}cafY4TjRCHCd>`0wDUINWq#35w|Jd&Z#}8(&&{>DX-i?o7Jb zFOvS~^7b1$lA%3NqHwi=wEPBXJ5Y3GXe%vDZW8s7V(3$5)`PVU#xaq^&I>GMk?SV+ zFDZ5jhw4JZzMFZUq5MwI`N34wpXrC3ODmZ;SB&lw4>M~_p^V7LWI;zmWT^09h;zD| z7KT-zsEXyvYjOU3uGk3kqEKNTLKa$10-Gca=d}Tm{m!?Q&=*sVPf?ZnCV+hl%)}xG zMLSBh=ig&&EM}C>FkqQjqwnI3Lq7XBl>;j*z<_I=j>AwtX^l6?C~D(Ue&@y>?XSOS z!bcseC>b@74Wgb1QJRQ5yyVM1Z@AZIQ6w?tWI1((`^xi@j^>>P2OS{nbiNf%=O4(P@;BCQVXfBiTfEBUI2 z0ng$qXvabmRc}o5Ic0)ia%F?qTdf%;NxcH#S~wC?&s0=WO-WNaL;7Wy=<<7l>8TUl z5$+@+ZN?$k=*Rimj~4WS(V%mFT@pT2FU^}b7%I$g-pXtk<-JO>7*lc=Bl7Fs0g`un zOZ}tq8f{~1Z|?p@f+d9HUYKyGjqMD|8tdOkN5Zb#ABnLV588*ynlG{!!l_2CCmGG$ zGddvEbZEwmcw8l)#5vRbvV?<{b*Mx4bJ;Qs? zUds5P%A&WX)t!~oCFgK-IBvt2p=dYbx5pUmSluxQExn3>SpU~`c zAXI&8y{h}uQ}YH-rSpE9VP9)+tJ^({r`Jwp&(yS*b(%FSPb?p#(<~@CEq?SQ^t@~H z1(Ah!bGJQL1gOjIW%6apnu1h-Z6f-NL1ng_x3Os|H=Dwt$FZDT~kGiOYA7O z%$bo^lgi)dOqrp(UPxBqMyhXGAfiz+<$UADjWpKGHzO1pZ{xk%R1LT2K2lwvlDHFm zb27Z}KC}Sx+K>3;xNq-2pi=MI}l!;+TRgt~8tBE1{;+!4G;U#{Bl4%<6g`dEJ|H zChBtDEO_Xg*wPz!XhNk>)Gi@HSeMVv5oBh|H={2H_}mI|5n#wr?0M=*OIzzmoY$X* z_d=)<@6^6e)q4^WC*As(+rCMv6VQZsleS;>(n-9ci&yS8KMY;@L|$p zxwpl@!d4``9=d9p(j&-fcpw0b=w=-=2ZpS9r|(TTgUP!6z>9U4jx(|U^#0}AE^Xht zO)(ff4g}@0eUBK5)kc)4U8LC8BV~N_j`qUbqBVy_`6r;|s zlGFTyE!HZj;GY`4Z#R@pZG&=v@^1a5#p2ninGSL}Q!%BIqB>-7KhGM5$bo*?+s%xX zx-5W6ve+!eWw)6@Va7M=K=Qh+NV}BB*Uz~h@AG31FTs9IJ~3Eiga2bSW<%uFat0)` z_OYbPtU&|>e_m$0ykwV=VTh*;Pf^TkTpu#dB6(nLZZ2Ls|I2lBpx8RC{(4x}yW4H{ zcqkFmx>7qk^>#v$vWq*5&kmhr@kyLO$Dl-Sah~csybwcV8$AVg(8gMrYrPYb*-e96 zA7Q`fHJV;-GUh~F!7m43wGBgU~QTzm=?YVYMX6W#r0`&1$Z&fDzkFL;+bk4em2 z=PoBp8i{xgW07O0s@k?@<>J$9;?Q+L6j@SlX6C&Xxs_|-A*oUie5d~ojZMwWK%SNu zU8Q`?eAcukeT-$3y_rO81QPtXZk&nf@4_Eta z|MM+@S>@CRnJ?~~eZKASa>I4k+*(>xToesUuD1=v*nJv{s4Oa*|52qP!4P`AMr2f)iRWZslwbzPbCXLsc>5O@5gpHS-{-%k?@1?4WzX6WlW<`uF#yj zR(^VoSnEkZG(J2(6~onBq5)PdhL;u|9sKuOZSN%lPT>l%xWw!kfhPzrR z6i&R85W2zSUeDFHf_<^;YqapM7%-y?>wbak`-eL9Mkja@9?582on9J^mEThXvyt3B zrH<;i{~`pUpWNB#Bz9Y6FeqR z^Hj0)GKQd$<$=b&34q6UBU#F=|2QU(`95aUA zZb1vyR!}UQBnM+)>LP5~~%EP~;qXnPwK9iIK!;;xYw8L8!u%FY`qM zr?eToXYb%br1Fn4EK5wM1>sC2!P@*dn-v5qO(@}rIy6%!Q>*v#C_9iYsnAY}M;Mhu z82`K46=_Gu{;88lg>LFzmILkF1sV01Y-pUoZCx}HK}^IPY+38W3=S%~mp>}F^d+!I-QVbyT)

kV~nocoZJ@&Isg-y|s8A&T_; zLE7%t+MWJrd92cCWM9gCS`8AjSs*P_AOd=YPq2#TK-JO#K`gpHTRIB5W*t5c6`i{P zHHrf&#IjN*pz<~g>wYJu>0ct`PH z9>a>=`aX0TM-1ta?h=UOG-ByxDwtGGTNi%ABa6zT1#2GN zbgkD(G}GsXMo!xlE?#7WzJf+3riIDCq5xEF*gg%Sm)g1_>hryKx7(;_=ItXV8@AOU{dK-b}g3dH7(V`Y%$LEAfn}Wb% zfFlxsF@hnIUtvpPG$;o^=GbfXowP72wPX9s-P*E+fkNRsgMFOg7y-Sfp_BWVR{mBI z2A9d8pt2oin==y-UU*NpqQw=EPVx*7r8a0yZUu;e3PqRXiLeRa-c~062lqx>!+Y+C z?bf^eMUTdovc+gwaNnk%*r;^kY$!7O=Sn3g0(cP0lUifHyl`}}vz|CMnH}c*~X$#I!>aG9sDt9%Ye~`70SR|oYbJ1%{!+(e-&so@7GG{E)?kF0o z1U?0*M+3T8G3_if&RM>wv~KePe)1bpRqEC* z@rs|d$UiDEeT0Om2g3Z(3J%KI7E&!hCz9Yi)3w7bsh}dBK2xlusN9+3Ni||GCfAH% z?=&48)WfJeaSSG3ykBC88_Iow{lYzPwD=;mBe_&==@B)w940*2HBB#qeu=?1}w z&gPJJkSy0N>FSu|*DDSFes-dzZNRx3;xd|O-CPzL>=>0yI$7!TMFYJ4pGj=rX2&++ zRao#OYSpFer6?&&g8b=1L{6 zOjC;m#)itZ@NRgOR+>Hdu zY%wLdq867_IH*`irn}OG220;d$)DL)4zx~nPBOE3{TfgN5wj!%6*KGm1Wqm)VVf1C z&q%vW7oiY?JU@nb@vb#(D7(Z1<#5ViD<ng2rzYm&I;QytyLbeY;)z$hdL|P`*U& zNY|u?&WFrpnSh`Ygb9}}be7hv-6?3@w>>^b7||BWnmyPldv5NF7KY zlGg5MKNT-zZ`->6^yp6BpohgFGUAWtdd<9tUV=+7Je9kJDk*qaZ#a+}Gg`iCi)%ErQ(<`G=$m_<=1Ast{g!=%Xlr;Iw+k;l~`*NfwC}Ix4g=N|*M?XnjC0b6a)Q zmHZ9YZ(Z*mG0l5gLA|Ses{bv>i3{8YX@PGnzb{9SA}cAi_19b9F=)q6YPY|4GTdk3~Upt$5ZMr>AXe*H3jTz_jUrI02exaZA5wY9Jf3*O3h{)kYym_2r94Xv} z{GH{DP$K%S+Y3zTr#)LLQCF$G)NIm){Rlz9*zX}mE|e1ZCA8$rfw*_Y8_6<+8@zVm z1_^p6R?#+8xR9a#7iTr2T+Lh8Z=V9RZ`qO)DB|XJ#H3ca&uHvdyynK@3Hi&5rrXuX zt1Pc6{>}$Fu7pWu#KGBv4pB~2Yt%up@M5hc25IKGuj)DtzL?__l;T69D1&xSQ+E9$ z=WDk&@SyvaYyCOnwT*)Ev&`~sy-l8^lSKpPnbr~lp;C)ZDCcPo+oTt+D!~lxofY+t zkLd{#S5zH`U*Oy+*t$0$rTBzgarf7+kLkC!mhMuER5h@vCxkXj>4yB|eFws^iy1Re zGi4kPBRZF>ovq#|jl&A!d(rNfsW-oIoa;_aJh;1|wny}nJ3)GlPv^w-onHl?OKpZ+ zq2+LN60ebJvd);KJ(gcV%M9<0X}T+u_Q`fG(p=R{^~rOv75h+dzD5VeHyhVAymjIv zR$1tZdGv0!XGC;;vPq?x14onM|ElHn8`?vfhd*5j?ZZF+=VA1E^1*o24GJvMHjwt& znaw^O6}>31{FyujUm|I>rcW+J`zPvguGm%e#Ue$ed^%gIxIvd2X{l|X>gX}q+iyq# z^r4cRV!JIcnRs^p50g0!q&`yS8Y0*HOOO;c3chmEfi3IB$m~WB<5W}?uQ=x=A=mL5Pb8cEO$E1g=cwG4n1VrSREP zngzs=E%PBVJzS-&fs3z_f8Oiv%H9@MJ$m+`**rl#=*k+O$Hj zy3u>5P?{WF1&Y9)>Zybia0)0$7gDnNy9*s>Jq!DD!G96jM ziDw~PX-dEy!V6r=x|eQ?=ON7h`Hf zuWs-+;;C(f1cPK&H?&_y`_1Jc8MEl6FHXYKRQRk8B>T{i5pF@~G>(6LIy?E>mTtJ< zYq~>%`}3J%oDm}gw~U<1E{1OXxets|;6yd{NvFIT({1=1Ylq;AmAOn$-H6n_zlKxQ0a@JI)Ss^t@WgrELs^-<;jdJ2BurWz9;@+=ULuOcdo zS92%jXNJOkIA0p1(hz3;_d4Nh!-Vwu+1G}kuyFpni1jlq#JYj~Ll2XC7|46nnSMgM zNmwyO4DLZ+8;H)2;Ot*I#-t76)n66e{j68H#6aW(&-=QPe=q%Tt4 zaw^BHMTNwdMfm+$h_tX13KKo#=uvAsxS(N-KdOF1DY+5f2qA0 zvypnay?>q+Hd3hk5_UkLcR@PKNOuv@6$jw98q=Jhz=WRUl?JiMnZ>3RUcX8!Xe z@56-5$%~FF;i|&^kjS_}y4fN5lZntiuBsX2H*9g9z>^}&MTFx&KOM@1a||Eb3Lv`d zj5F~}ibuGDYP| z?%QE&)l>bT9qte26V|e27thJ1uG5eUWhox6X@)fq-zr>+L-DD@E=;g~{<%rH(Mcx_ z9^E%RW_y6e!AZ)U5j1}~%zd&AOPLsG0&|clF7h@Cj5FT+u75e7e?pKMrvVwIF9F|8 zn995soq6>}U6}gtX`-S&M5E;MAC1z-d&uKTA%>JkETlTlv ztV=7ktOdeKxSJJOf!;=5I2SQLLk<3*j+U?bocHLBQ4oMbQ!9&@J)L_iHq+&oA$G;-J9(-MyWXx5dU+5#xbfR(uU87t^f& zpt(phlt~3}VWPl32aYpLQH5dcxAhde8rP}y_ieue8q0iYeD1raA(!pHnTmP$o*SnUnSxU1= zRzF`mQD_U%{#352wo{q7ztyA9)cka|;F;l=>%wu#bbE5;^)~OHi_>c@-}^S5KRp}T zzCHWZ@u%_T>GWDh%c^Z3R9|l<7xo*f{XM)@%|HS?_x+Zf^tg|TpS2Y$P8kwF**`!n zGX))!0Tv|>RkfFYe%5ofY~Z-aYmj&)Vq3GN2oGfTNw=q0UnNQrItPWd}FyYM?VV{#_MHT4$e{lO459O&sKY>4Gx{sk`*dVhqmHf-1dZp>?_sJM&(c>)fQ^vO% z%nHpOtU<1ZC{$AS9_^`xZ+moOo8)HyI$dn0%e=kG+Lgqbx-{}uqUSKAzKHeiL%*E8 zJ1#%Q(*4|2qd4earNn(Ir|l}`wt2SrtU7_kT-D3>I3F7RjS_u&Gp4v1VEY1J>=irX z*}bcFF>dB{EGnj9YP}MV*d3a5p3Ox#+D--=blbmW@Z#y@oPEV(c{l=5lzO&JBGRf@ z=uD9h%>r?mNBFd@19F~`CLtjFSQ0-Ub(tU2uDl?tCTDDdjqjbVstIq6tR3{T|54Yw zH_{TYqQ3GmZ+!!cE@kly<~bei^H}nBT+is;X1n|T*MzR*lPqy;)-SRMOTUpQeXa98nS57Z^`dmYcZik4pW=O&OWO7%Z3)SD9O}M{tQ9iwFK56tUAW&OA%QIRjY}kk zxRlLR$6vGAF9orz|7dE^2dRv>|9=aC7d@UI)LSOxY2=EukS<$p)905Cl6G+!s5%ci zq@8_bW}cO-pDle)mz-mNBE!M9~nU7&4 zd-J9Ahwt(56I9t@ONc?)^A~*5-Tj9nwanN}0+TxV#dEdyia*N;6oZr3-|2ub6nF#( z1xt9vy9@e3y~G2Zy{;b5Eq-s@ootwhLeb~H@1Zm}Sg)^gA5q?w_N*ncTzf}zyt{Fn zL>ek&4h(x?miVstJJsTGfuX+aa`cRX|E^wmg(I8CR#r+CntZhAQrBk2uITrT;sv!t zo!e^frV`nY=j{eQ#IIeHmJoSC+D;*Pz~1%QURU8&ns5;Iz%Ghsb`W}IeCA7Hmyw7Z z)i0-c>DBOqb4`ZZMR`13$lE}JSooiw`n(Re1BF=n1Rk3dz%B%&N*y9RiwyNOuD;^s z$B)+ARz$fOpSKJb7_(Zm>8LRfdFpq?4eKSN1G+3!@Ixes4NL4Zj{cp2 zPHP6JGm#SPh}zWJ&FWK+<(2cO$B>J^{95mApiF45*Nl--UOBX>BTB1WPrh-qlAa~! ze_^~gU31HI+=`+d6qHF7v+{=QOz~0_@(#sT=ULe-f0c&nXCp4#BYNyQ$)kC?=er#SZwEb@1mXO^OS`NQ05ktR&$ap zB_i4`Pm{9u4-Ny=CsZv9J~BR$YYprK*vd)>+^JQjpC1 z8oRrxqaMdrFwmQ*hv*LBkw+|-J{7xrZI=BIzOME^YKV8e#y#x<{!`~`W#nW;ZDX{R z{CcRB-x`Zgtnk+Lg~p2x@0;Ok@YIkmH-PA2cO5qnFaaJX*0??%n_l@FBhLKe^% z?>=-7uF(?P3o08w`epHajLZV!$w??vw5g0YnLkypevNbRR}vEH$+Ckn3sI&XVYF8> z`06CYzBe>=_Tp~-oym#StYTyB}!V9T;- zsk#J`Gb>WS+n_rvvEzHD;JW5J>%?ce1rOH^D(;}{emIIYJU0uJTbbv7AtAZp;K7as zT_i73Y^M@&rVFw3ffk)LJp&ux=10q&$;ruCz?m~1%Jjp=iXR_+3>shblx~VbW(28v zBa?9c+A8Vj+?s9yUH_0odgls8r6*^pQt?6QLeCUP#Wizd%g}>^EEHJp?Lp$r^D!I` zDOtmN4GJ&$Lnt&_V&aS#dyPpJb&VB#s`r)n(g`{~7q&3`P2XiHQiMrSUO zAgbqto#pQpLoClY`J^Ivw2?Yl83lmB>;E=(BZ z4t(n@)K;y7xDqKh1IEQr$7msAwSHd~dMhC91AsOp$3mqWJ#-hA4=Zu4sf|PRAj$IA zwY67Xe4jUY{mnx}|0vdf472#DkO-ci8kC-YEwUE^}=TW{D%~wr(VR2ObD1#y6 zhHp8yg{j}!M~q?@M?ODaz}f^zYGIDI#@sYWS!E6;oA5GCs07SDKH`soLeCmcb(m<* zO1BAM>hDZS%R|)^yr-z1lxmW%p2M-<{EHk_vHaeFMdnhRGLnTU?;W%?!(F8FZsa*t zxCrOk^98BMR2I1Gt~K1zte>{Cc>j`CCZm3w39E4EP<^nsSPX*7L?KCb?JQ&YgVh$H zVrlz5`s3Kkw=Q&u(@Wh_ygk=bAY%jOkt4TmHj)JF&ZZJ{e7O{A1bLs222975+qJQ% z%Lt-^QhI`BvvNnIK9n79cek0b&#APTz{~g^|FtaW!Hgy*_S3p`o}zx#+4BC{#ZcTY z=GL{qr4roavaG)!I%6t7j8eq4K=N0+#-OiqNCqa?-gzMWH0(dH(A?Gs|L8SnqVBR7 zrKe3VXdw$2X#UlgSJf*i?lDNcktZ{W3rOYV6XxCPuR7VXjVzJSZNN&{z` zHeo6X$@jXNFzE`aZ{z-?vbP8@{JNW4&$nwDnbkGbnO2cB$)e}Jz3{{{zwiva{~|Gg zf&CMHzu=SSDVUz3*+}0a38=)|_&Zp)Pw@_&VD$d`iqPFS;@?mHpKHGN^a~%I0i)d5 z{x#JgckVyQvNe8q0keIJ~YAckKzKSVD!Y7y3eRLB5ruDtTX@mwv(ozc4lRS zW>jB=WS)w+IcrHGrsSoaj|!wZ&&6Mc|is zRZK1Ys@8cQ8_f?e^@ZwzB(krm@7%lT4~Uf=45#_;0Jnx!>eYR*F-ViwKdTWJ=n9|7 zqdh0chEohXc#CGVaRrLV8e^H|{@eomDTKgr8y%69r{FI$ld-~b$PGILO@OHGzt7B#4-|z_Wl;&Bg~}Scl>S0+@WtZ@ zkmuJ<7ldMgi_noVAN?`H3`7MZ>vjsDKh=-O`A`%0DFVAV+b53IwY`&lO&HTqci91GMyF57J4f5_vE(Z=KlwAo=se8HT^eAWSU*f<~T0 zSPdmWaHJwbXibLFOd|P|#&!OCgJb|1#iWrHGvT-);E{y&*1x~xU~a^J%z;MrGT|Vu zuUX`5lL7GmqgWjN-wO+?mrXjE>XvOa$ArXGN3J!|Sjm5PF^w#}NExYY$umx5CQiWW z_1=Xx*=&syS|06Th9*()pp;K9r&Qig{0kN_;e4i;#MAj45qZiq3GU8BY}Iq@D(o6K z_dKXuBpp54LI(eC$rET4Cm?f#eN~@cH6jaRytZCY-ov+ZRucbT4`U$GU{6M!dhD7B z89+%vvy#oHAS74zf45WJOh(u4%J;Z;FnBoR?l24|tbdrBRWSgYNJ^1$PjM0_`?mzHm@{UMp zE1J!G+lH%s2X}H-^WABU=R7CBN@Z&Z0Ks-`Yay zGw3RK8~2R-yRj*m8wDpQ(PH0-q+rNIRdM~3Ot5!dN}o(e$48?I)h0jXX-?J9_phkF zIi|Z6{H;TA`vZ~i!yk1ami4SGt=Wlz0R-^0DtwjZK@Y>ekr=tJ>xNDB&g|jIK)}~k z)rYd{P<9~{B6T#;9~|i)v&dQ#u0ZlW3u~D@fApA@taoNT`K1OJS9=`?TgV1z15}l} ze-FZQd-gXrWAz1WjFA6k~s4Yp*rN(rjGqQp=gwZ>X6_1p&J7a`d z?<)vhV#84&M?6lzLreGsT?Q&R36``A7sPs{fgkCzVNJHs_GidLVNZn!z3}8#hUq6` znLY_~%7FaxM24hWj?fl|`PNNC_!Z)VA|iuxC(J#&D>2XLbH4qZsI7R#|Dd3?$N@xq zm9?KU%$;p=Z7>ipXSz2zxl{felSM-QtU3&Lt26hFccfkDj0bvS!h^^39HJx9$=7$m&l&_je{ZR67kEWM0npf z58HYmf8gXu%fkV^MA1XXMu4v3#hPf)hbA@#3+Q343H|U)N8LwaNc^~O)WKi~ZCWc~ zjKmq5Y(FE4kxzphpqRCF?eE-;aKe^_HJbaqP|6l29ZHYdPJo8Tz6eF!fzgz`#RUz1|_dvog^ z{RPEnvE>ScLfJ)*WMY`2@h3D75cW(bak^Z)*z6tmkn2~d3!B#LzLQY5wZY1%{l3iMSUvw&L9*qPxLL&F zBlG?5Kd(q{eHal^@Lih@a~Z3%)XqB3S#YJEHEhG5NqFL+b=C~dR|?T~96DM0{8!uM zse)c+U7BCnVY_%&27vV@;&rS=rvE{Dapjx&2VhlFB#F%ENh>d$(n@27njq6bL zax!kUN9R_yO3N_1>A<^BaKJg>NJM2lAW6JzW>&6fRNuQf`#}z$%{8l-ozC@NEr9XMiT{tSuYiiW>-rT$ zC8Pxhq!Ey2=i%hcE68dq{KbJGG^WhmMyiDV`Te*%Eh) zP^F8OVj|ypCu{nJ*Ee?xT9pR=(anikgod@g3&um$j+$`QIZXkiNlq&Qw4n=%ZY{<; zk(~`b>r&jV-{ag?cb9%`=SOyadn9aDH;^dJm8Y6{k^p~S_e?Fj{iE#02M%@}E0S{Q zt7FaMgSb00>wM{T%2k~{`Ohy3xh*c)^lJm7^Hr0KhOCwXs8SO8~3is?Ar}Z2J~&(k(pyoh4HZ{O}h0=zHGh` zXWRCRd%MaL)}PsYGs}&z7ubDE%{ZtzmB^y|H0;QZNwsa8Gw(crRiC>sDUOx@-Ijp! z*B?tMPk~r>FsJj&0LF+e`>uoY_ z$Y1*U?KZD7MBSx?aUtv?*TPTU^Askn9hJ;F2+U~Xo8!HydY>mVH>d){7~HrxCA-Dk zD#gZ-fcT%P@gn$KtoE@P8-Wj<3Ls$34IvF z?B_n+WOz0`eN6Q)Io9tbTdXM@jE&XS8t<3uRPFjB#JA;G3$l3Xvf&xrrswz5%aEAG zCMIhf#^s@|A)BjrV4fpsLM7SC&nuM&j0%!IY=5&31sRy1Vm6jE4EW0mD-2J1)tEI} z-xw|2q>Fl=PBX%(MSUMrUc~6W|GDG%h&dgpTr7eQ$-@vqmg_Vo615-WlfIqV5%G^= z)4NVrAs^GR(`8|Z4m5eh(KXTd^&_`uqLtS9yeWIRFvAqB1pxsAy-cQCSE_{s7|H#r_{SmH>fXgJX_4OHQIZ@Qb?X zjWVA7O9}SV_yPaiocZ(Z42FD-Atj}j-0Zl6fG4GEa9xSYi4P%crU%VN^UVfH)&Rwn zO`?_%t<|xF({hJlYK(diQ=)5l<8Za(`aOmTgu2p6WXVwz*a~ z(-@*EQFsi~*b|6gdFG=|A)Z!i0+3zh0+f~(1gpa}Dc$PV-M?uNkDA zT4HE4^x9GUc_NYEdRwIUk9B!c$)wU1@r)IwxrI=3t?fq>`|qwFSj?{duKbUJ94y}O zeHFlWe%Aa{1|oAvHy(9YL$Ah-nIUa+n>Vu`5OXc#HZC?I0{Z_)j_Pq`Jv;xI#c{f`Svhndx62&UY`#PTw^o-N zHz2dsWwn;CM*{$mi2J`GXZ;&JRH@KoIwN9_Ax{5A9P~F;sK~$y7MD3Pjd_VFCfgaL z$oyN|n$y(T(+nO{{|W8kKw_0o^7l_Bf?7FBN)52*YY_%du)H zK8CTk(Bpb8`8EEanR6E9%aws6x2-*SA(z8!u1<(2U0xYwPUz9VlSWSkNKmR+&Cgev zMYYHZM7d5qEw}qVXC>B3(MXnD-!~12c}VrDJ%4{@UixFD#OIIv%Z=*ghBMk9FY$WU z%FmX8S|4Q~Ly;p{^HJBRKIaa$InX?uq(~tc(2>AM9U(FSNhS2a?2&vo449b5{^1W>HcqD4#S)Ntk znRcAS^_{zN`Wv=o@ANGkdpNB_l`h$PSRzloou0A$$&K1El_;q^+6>MadJs|!TIcYIm(xJel$59;Mq>MRnCe%67d-^ zsaD#o-6@8w4rJ+UenwJp$bfQLgz%boRio2WM{S8iK|4v#O?bK@T0u8A4C{>PJN)iI z1d)@?T6&@rVy&3DuPdGGuUNW#O&%+>QXTayxEAtwJ$RlIH{rBo%);kn>nUJs`WBe% zg=id6*uHT3O0&F&jb-``5FSSoeM|IVGS%3LFVqSMQmW0tbc`N&Hfrf+Y4&*QTt zM<&+FO40BDf+1mIRr$H&vy&y^YN-m7pjrednAK#P$ugE_Z2mGJol3@XyiTmL92$1Y zu322=uy9mANHzXkEknFAHvRP{x$%K^fh$3MN76#96-riXr8c7(hvsK11`alF%+nDg zdTdj8Wl8t&sTI#JNh~f#ayB6)mZbtpN%BjICBOO;1;d6!o)0CqP+KL;fsDiG;gHFS zaf6HYzNI%Sj_1bUl$g&p2CgT$CQb?zlt9@JDjH zQ@q>ag~~5}*XdwlVX3{N?MV&ys^WIG7xj-0cbOqCJ*OTdiynN>ZGcp4=c9cXNg0^{H3A>4(P`pOJ9nUOt*QmwqPR>j&(jQ#gCFkTZe#Bknf-joZ*M#sh?s)(&!R%e$A?NrVV zv{%e@y+W-TS1CJV5kzD@^oF_zc@tduq158O=sxc2vOiv*QDhb>R3GJeMXRO;7y1)S#>3^a zq3IGGR(|JB_y^CeVVgzk)UDTABVm#%9=y5cxr7i%A|u_6Q7ih|_IYh-Ulx;d+WDV} zp+!2x{>U@eyPVf^G{uZi&%2gKwCJ|T*7_rp#|BiGgzwZ`7!JjQHdN^nSpciB^8e@-v81o>Bhp<6|b%nu-d>%+Cn!7F-=P@(u5vF7Tdg zltb-F8ieUhLC~HMmIeBPARVG*sLjryq^Dds$7ktB1UzM1YiocrGEo-3ZhE#02bDl9hqv@$Y*5d|@%${=jx&tMh+*qAn>f(GTpApB zc~)s6cAr9!OG+vk(hQ{~AK(TTBrCo_-{(e;je-{SlhwKT zm;-7LLq3kShz;nJ$Hc9x_8hfW!jKpCszJofwQc2Y*F%38ymMhBHHpFnD|6?T3{9>l zuOi^^j$EuR)r`7=i3cleUKYx{6{|cM~f-k_7+T1arqn;q#n>*$p((-E2g#B|7m z^|;@05+fPi!86J&n~_NnWq9l6E1ge)3X(A7S|VtLMhNP>NI!c<019`;N`>5Apz9kZ zHOCH5!)$mhIk-WowxtV0@+NNfjbP@>!u9!vX9}4}EA=Ab`b4IU77U?@Q@yO(XgBSy zb5o`JR+YzkRl5|&+tYU4ry-_l?^nB<`2$0+j15vPM~{_@nfq9m(qik|m+V2OmR|(I zVmBCzXFqNQE*!TKuJmRHTqiTv?6Oqy3cxbb_KOa8g3E;5awj`R3zw=W)6;HhAFddK zN}}Xb0@NG`>)qj=W(f+(rr=vO67LU8K3_dE%CILL=`C^|QSoeSNOJ4f^Ou9CaGJ)F zuO5IvspnIWR4WtkrBB|p9+VQ}+8<}c-%C)!M@--|&M;TU8(%&(3i049=V5^pt=H{W z-ein{e;nsU>jG--Iv+cD&0X6tt$6u*wb39zWOUnL;z5h1IM4Bz8=VX zv_$4b68xLbFy`ff*q5KUyhlCv$?T@}Pv>!KcUwEC7Y7RTiaJ?fa~pz2jr-pXorR1A zA0up4s-4OzNXqN2XFVkp>&}-CNbwYx!w%%f|~VAG5fs` z^{?fOa0MsT2nY#Zz2~t;ta+`efMcZS09jN{te|hdP1%U(+8E!XTRs3>Y^wqdipQlE zHv)5yZCYr?dB^|LAb>m9L+ z*O1-0dVEj|ST0BU&HWs!p)^`iQ3_CKG^cy|&Ir8e0h$-lTS!s7r&0>7 zD(1p2ry6U1n;h6$4Ex@*3aYt{gSgLq;X1R^_x@39QCrMU%WNsPU8s|gi$@8f-Q$`f zjJGs~IQ%3Xs;uLWM!PYdck=m8eM>J8z^8VF3GLLfafOP%4+QJ-4WS(J83M{`@=Qxv!d|BMu5s!ZWn)%u#Yqeh;&rP@Z z@PK|&Oi(p;mjxztQd%0Qr#l@IAGCpi8A5*^vTq_WBvC?+L&IgV+G7}OuMe13gSoO06=jPA7%y$tHXC5BJL1|7%c z^~DPW8QsUi-Lx@s4?C8&siUwNb0@fNb0c%i;t10>-Ia`OIn(5QsBQ{q;NV3A6z3tV zr|IQ1mlp^2T7QDY$1Kv7g=Vjno`KDLN?Hm+P1U`g}T-x5tD${1)$wZK1jpT4Sz#KTcCwe0Ko>~mN{ql4_ zK`xqcE`_NF)iP_kJxF40BugMcdWVh%-Ifm6Uc};phs-aO z!T|M#CRZFi01~&T&u_iq{9g9fA7G_X8Xh4*Jaxsly|OcRvZ^RlE5fndrOn?)r!-k6 zWZ3k8VYbe8<6CWUV?=lfqwbG@-#Otfd&^%8n{aV)@0?IDeRsH5%SfWEXCSE{7gLO z^STEoCnrZ-6k@J;8#1r=m&NWlHQ)T2k#OA@kSM&F7pi8QySb)kieHI+_N(9L;<|1r zP$JT3rUr3DOi3A1-h8sMM{TX~BuFjMuMCshDk6X{rCuPis^0or>%PdvNxolR{jm*^ zx&6Ar=z>zm!)`%7p(IFASlSLD+6gg=uN!MpFn#kNoW@6#2FK}6Pe}(;h>M0zcum!R zpRhF5e|#_BDLJe;#8s_e?qR3N*Aq}acg|B%M{c$w(tc%ZfivWbJKv;M18UV*60^q3V$)@tkrHc66rNcoY5;tGkFt@G&wPuDkN~Y0 zumz>{YBFo9D*So*T&%A#;|J%t6s}KNVt~G=f{f1|IdkZ}**_3RjP;8>Yqu*CEUXh! zhA)vVk;K@G5kI_J+TK&@B@m<*0}Q66&ql<2 zm0yX!*yUB;X`lZ5sCG66@!Ldov`Ce*rSKq_6CHEz$;SV5Df@nTFmHV#r$-W**w|1tL%VSIAqjl7^}H1hqOc(S)zC{{>h zxZC6Qd%O-0cz0%{kd(kfsb77hQR?gWBcffA8F72p>*+3kkaG7owU@L3ly@wio0|vC z^)q)j_Lj{r7HnT^CCuVD!gL^6+3QPBy*w^jOJh+_>8KX)%W)m)|9ArvYSAvZ&%#Rv z#|bj-87VEI;i92&8XT>8{^3Oyg%z`B9294ed$))x2(qiXVHxWCCF*5rqXlkkrfA$d zx!sUO1io**@_+{PGNgk8+n1X7+0u^L6-ta+h z`_ojI_|8Mt7m!E6%BC+N!K*|1Dy!mgUp!;6*GR@}cyc;R+;hc#maK4iIRl%^VcH8-W|wqxu6IibZEhE!^5o2st~ zQa`84nHYHr%kcGV8o$CIA~rV!O#n<4YzkHS?-mwJ^wW)@Byceekid6%FAOuTu(H8& zwskQ*%eBI95y^Q(KIt#4_-;X=HKsaF%mU-B<9Y7nZ$8f)efi6a{TlDnHyo+L`MART zfuooHhh?jJpWSZb`SXoqGBNlL&B+XoIDD;-b4tC3&B)qBJ%S7;9}zPP6hB%R8MU4l zY4{XC=y~Zoed)hGpja3sVk@cq+51fB5}e^s`o0sHEuM|O!&Apz;HeE~F5FMioZE#K zK0ATb-olYEc-Xu8su|~la*dshaXYv4>kubHCF9@4-@VTx6;zJi$NU-Dtu1?wMSM}u z1skmM+UBjXSkT2)ci8a?WxR=to)Et#TA6rvFmjP`*rCQv-+6X6PiFN>eV zx2_*YmqF+RhEJ-tGM;(5O=O;ua|BMGg2^+{7Px5=t!TdZ}ebK+NtDAkiO!|o;cm)W3F&kWMrwb7jM>;fM3yWyUvYkgqOt(}cSJbdJpUeLop z)p&26)8tE8fqe{QPOVnFIuH-Eetl^uv5&v>({|W$^N0`D;=gTG!=&QL}qq+Kk$ z`IEoD0etuSAF^K}kxL1IVVwONh4SzobqrC(WzD>wwp5FgBrCl4Qls!5BZ`9y4P`s} zfu*2!H|_gQiz?h_c_OOT5bm%xk}2kNURT0Vn$DNaYN-}fXUd|QlQ*pa7r1VCn3Rs+ z6-5@HQ971Th)*TiQ?gsHEWdc%#OMcI)3n|Bx^OU)?n=~j^37E%erL3VKXBTeMh%X$ zHe|~(FG>-8;pKQT9SvP~KO2y6{aQD5vxoDfX#WJl#DK_5*Of{Bi96IkUbk6+dp{+S z)1>hSKQuO?#dgQc(%)g%YRye|hKIzjr=`$tVEMc2MY<6GqZC^vzLP<+@uDMFmBT+Wwc}zX1+FDYod{Z6fGLK4Tii>Y-NlV5MY{yVFC3e?sKd@Z&(%L6SSXx+weUx zsF8k!A$$1s|{ZKnV*ppbK+?P_4res!8*-fYW9W| zmR?^3G{Vz{OyE9tyy}I4_A1s7{Ps9LQ}PnGQ=HOEL9I;Fy>@yZ;)MMizHD?7@-LNZ zw_SUw$`e-06CQR4BfqPOy*>5XAv|h^Wz{exPC)1I`GrbPm}C3T8lR9oV6_d2I|O=n zWJ{PJ+vd8bb%)d(b}IZoGaxGROWWi+T!EJF)!$HB0ygk*rjZ>Z-3tbEq7`1Nt{G(v zV2?!ZUSzhvA6U&XFIutDXN7 z#4AI0Z{$nStC=h{z|*={FSSFVPfTLIL%SwEJGtf6O&Qwb$J|Oigp8&;A#GBHJMI!u zeXpgxd(~|H{+&RZv-_cqK2EQ?X~zM3So+kHDpv_E{DW$pn#PfO<#D^h>WdA5xo0=E z0)ye`3R5F|z&ahfwO}~WT~HddQaiPtu2tk1b6_Rs|1+3$ZI3NhW3ym!?e=S#r9o*I z7Xp(FVZymUj-E%z|H%aqhIqvVBrOCw%-vBO5{rrRd{?gwH&&cFIrlu?Ra~M^JSS6x zYmKOR`Emj?{bWroJ~}uF7;NLIl-9dg`|?mmX(|@i&3UDBV%r3SJ&=}I z2QCdL+x5qWo}D)cnvdnYm-rQ+=4XtigZw%CjzBx z??aeWWMN2*h|SI|RQQ0y5?c?WC^9#Z~Y!vwx_RoY5pf-tMVTTmFz5d1V zdnuImv+fWyqq8Mk0f8z{X^c&23{7>EAS`auhh?xhG${gKi464saXOTz^gnO?*FWr@ z0si4#I5FcpU1(svmNAoT4hPD&GRZuGK1STQj_>v-O2{Em)dQ9|wHZN!0&4a+~6WPl;x*7dN{U(#@so&^Z#J@)i(R}M1 zm;XpIAUG7t&}2Jk!HR`*ZP4Km?cIf{DOqSm@e1v$?yNIYs!v7#XIQ?71@U0zHV;pu zhtuYKEko#XHCx0N8oQ^9#ykb99Nzbd*Y1lHqPqmUS{%vJ(Wv0e@C7QEM5)}A-R&KyIQJ#KSI`Zx! zn5!|nng0=ZxNI@UwFzB_07WNA8sw+Upztdded(3J^U--`Jzg`x*>-Wl$+SAx^X2h#PwC<)&Sk_=&|dGWRvSK- z&*QzHl*0FWrWw1PIgF#yM@PMzWU*S(2myXtdl0W5^JW)e)|VtZF4V zU~eakkMB#Q4T=BB6ir&24^fblqotv_1*!)k)`rqYK}B}|tD~upMvc|o(=7O@KM7uG z696L)J&n~l9@6}-!uf<9pj(%|2guK|-(JonK$ZrM``WUr{MTef^>QEZmtEeXR8T`i z2|2^|T26-Ev~SOc>EKx9E)B|^y3I%%iTd4LSG#@%Ag!LO9;FX+-7^jJ3LMYiI1;B^ zZmXP_1JJqm60sk;+!`e=U~zXgw;G(GMuIS}}oLUW0D*)rY0u<5mldre6;SH&Ea5^#4iy`E>qm5K?E zT5?2Sy?F=i&x?`&i3*jfK6n5#WX<5D24!TEY&;I8{3Gie4Vrk*!I`OahHb@KusG(R zQ5+^NZqLb5P#mZ%$Ha_4@>H$$d2?ib5`KtA_>IcERO~j`Ov`S+pYaes^@>Y&&B&@P zZVqT$(smnlJxsEzCg$xtpy$sO zAWH5<9W1iT`C6#UH_x|*-+Q$-P#*rsb35*h`Ms5^Y;`*GH8#Do@AoOreTw2YtnJ$1 zMRpT%HJT@6uETB${A>^&%#le)_-wgINYd&>lz0>q>+`POgTkL3JJisF((Q)8Z5H`j z`%o$OrLHrrUR4MBhe1*Ir~)X;2P9rQ5nKHj{X?QsX4rmtU+co7+pqaXQu4)zEh;+v zBP0$?#RD90l1yM!B_Jb<1Wmk(4B$R1pUk>M6LE1_(di`7OCW|wAz&7=(V75#G#&kJ z)jG$Hxps?)1FEJ6U-xguIooY|DAIl*tO&hc4Ud6bTpNt{|BR$}`7wc|l~VvYdEZ8W z(|cbk&*^H&ZF7-REIeh_laB-zwNIQ>k~=is^UY}*L%U=OV~WF6T6P-OqA!swvs5&a zK_o7K$G?9Cg(j)H^w{^niYhG61S8|?kK#y0Ec20C}xzHkA{{VzWor!HWu+Ql9 zEVuF0;R{j_dc8Go>p>Zo%HAEs-GvxDU9Ws#VPr?8OpddwI zid2-WDV-a6;iCaRjkNtYk_182?pFe2;-he(|8;A;{*L|{t&w9GoG;wtCArug_2-q* za?UNWwaQEUuok~@VdUk`qrn1Y*+$Y1^FLiTUhB4-qcV@$uP$EMyZ-E|SG|HMU9%oRvSM&F=m&2!^*%^TYM{4v zLZLoQs;QB549e!?>(pjF$o{oSHFcdJtfk6p4EL#B{;&CdAa5bsT0Px+hePvz$Qrwh zO&t<4_BlEJ*TYBk+`pcTHw#pBbu{k!1m|ystEj;fqB^i)8Jg1PVyT+2CKHT#bznOO zt|`VoLD_aKPe6*wLx!&-(vuRH#wmN<-KP_02Oqz+iEZkXguY@oq~mo*w&`4~MZ+>6 z8_Exd$=ZC(qTj>iD~+-Mu(~01-X)h>B0=HVXj1E6~ovE8W7Dz zqR8r4@INKNpPFYNALb>NdI`*^D!|WSw&tD`8rtv0e5|`Y#1=uo-m+Xi&eAW~`6Epx zdis0C`*eS7Ewjf<>=4uBkpO)^7c4h#wDJp%&1g`*Pvw5|O1K&Fp8e2N+w@~ZTdK~G zB1TI(%Bnd__z%fj@Jy~l5#t@v%69v8R1~G~vacQl#Jr?hs~=hb6YJeuNr82Bs@`Mg zsh@*Yc@6b8u0WY~Xh$d5i)N;gSham;^4k$zOVVna1usd{9|CSZ%I|uaprvBnYdPYL!UuY>2ReKukDIZWfASL@iSZ8x`z^5W^0g?V~Uw>ye$ zehr?RN{m7~j%7wquN-)>*Hpr}@iFK^4(cm~E<=^zl=1~QVv;nqKYO1sj8$PNM}%}w z-^Q;A^T0*}NlQg46BWc27|)2&2tRS4d@VO~Iq3C^1J%#j#AZ)P`r`45ZlbPw#G70( zg`cYi+UmJQ;MBIh%E5g-x^tFzQfub?U=xlbAae;7px^29DE*eaK^=Bglnbra;4&#C zHDp#S5gXgSJNq0H9cnrFpz{vAsm zL9jfw1Wj#QV`K~>jl7dNp10HfGu41#m}sSuQhHD6?B-Y6JY=MnsxMh6v$(sim?E?$1@>tt<;i>sCuLYW z(Q9se1V_x8+eZ9X`n{nMji=NZc$`Uiyg$hvU{13j)aR*R{Ji||ysW!g^^%u}wNC!W zuO7&uA9G(f&syG7S-IOXo4vZOUC!t)5pT?%wh|<=65TTF5fmj#tvfGlEOgty)pB6q z`#FO!Hbv>)`)N}OvM`BC#EZF8IOb==FJfkvkFhP{jH4Eu6)|Enjm z-P@ZYB{;f2bc>-uzSBV9ndLo)F51k55t;1@E8pHj%E;e}_c!(ic`zVIFTR$!$adgj z95yiuNPZ{aK%ul)x-VJK>E7N&x#%74J>|MYE38xIF3&F>xsrU#U$Za$;8{s%aeSa= zKoZHcgWr7_Tb1r)IC5V=b8vO4tTXoFG0{*KZs#FCEig^)pPeb(j=4W__NS0=BjJGO z^_*)-3|<#!P&Xugjc66D-Ds000b?y@B(eFi$nRE6iuakLnB0cN;sW3HifP~mgk;a5 zPU7qo^N(8c4a+3mGcL<3(

Ca5F$kg?&u`bYMrO4@tVd8s38KN3l9cMxc zR908fVi^Ka@S~-cln#TYQpmooU4n#48z^Y(F-t~JIyhwNz+g`?zS`pZmI=@whEhr? zQ}PWhhg~T@E#1(76$d_-j9;r}F&nzK>$1*|>!^vr<0~c%YlgS-5Doa4wjBCyJ;BGG zOysfq_U<@7v)a^~<*64YKKC?Q?mfk~4P6w>m3@BzeJ{@h&E_T8lM*m*sK6x#=3Mfk zlnJB*5J2G4p2Do??Hy!G@UX4diYFG^;YdNTRZpFTK5sj}jIV(2Xj?xMIa5_({I%qx zwFuTiLA-pF^Nyu(!B6|TYm8aWFbZChSmQIz7>{U?$=5cLHtt~6#@QR>)r%LLej5I< zahoyIV#y4dVfbeLr;mg8pu%?__l|!zU4RSmr2RSG*itpQefz{-1- zdcbqI5*p0r8c1n}V;e|f)8CfhV@@tcHT;Q#JgoNg1>JSTC^9LUgvt>M&9P6-kNdb{ zP4d4gp5JD46FW6iFa%Mn2+2LLy(^05o%)YO-OL86gJRAWf|wvOyCxl^^~6^^kFQEyd)~ZJNd}Ia|vTVnXmMB#rm{9 z5&CH>{LE!?8I>8X)Evu88QQ3sOU|BV+3`}_&`XBY0mUX{#CmeU#diC=o6KhnpJvZ+ zA#&Sg{pBa!FmzlNoiANpi*>)nH)ZO_@lE)_)Z&vc6J>#n9tkh$LFa zPPNCb+eWqAliZ4T3rScL9Kn5iJIk8^v@36ckF4pA>Q;c`~JYgUW=CER{ z7Sm&BPDaB8Blt(W04JV}W-FaCVhT#|Eia6F*Ey+Za`^Y(S02w?LU1jE*!=iua+b~@ z({k74EjCX=>*`_UX2>2{G_ImI2ND;VX27dN4vHh53pQ@Hh`yP#4@kalZXoZn9Z`^c zVj9^!^+5L?7cx5pml9GSZ+Qd!Px@c{51tYf$*2fVnblwds8s|8REhfx#)5(m`g2Jun&!fqM)k zJP{L6aTXV|v5Qzpt9FK*qfp>EMtqcVG z2^&M8McIl$0{|@`>~Ok!s8YRT*fGvw!nKol^9JPO`{y1!4wi zqG)kt!~b{N3Xt-g0;4{bPGg*dUtyV}rWmQ*T0VMheQ71t@Pjh>H6b|Lv zJ<$wNHVBO0={g=49btMvZ!i*MlKwR`bVV0n0cQlVHs^3rPP8#8X-+AIvn#MYd1hom z)%O^BKu+3kaTq?cDg{{I!a2-G@$NVPf?KIJf6U+L(^=9{h9Ey4uCX(@04W{G#W+av zw8(F6uB>a8;WEoV@(SS~=664!OQLYt8htB$3m_J*3oxT+furlPHi95SFg)L1CKpEN!5F>(vBvwJWNL!0SNT;yN9s&;6GsE#meuD$GJRoHw9eUW) zF#b89-sV@@>(W8NE2$9tp?hBEOGssgvG(Cr-0ob8iXREdm zZ(x<<`Z5eUHKnh(7mz1Ba*{+ zJ8?P5vX5`Ab8Nakj$*z!#F+3{OExM}uP|^t1WIx%aUAA`O+HwY+mqQC_+9=0IGqC^ z!d%I_^NqTfhBrw(hvC;$F=x{D=bO!u+$c_Z2+NQ}I-N9Ui|2PPrJ@I9lD0cdKud_-a`IKqzU@p0 zfzEdH)O*!8v1~f55LyRGWR>c*p-95W01~IK!AZfRRcjyVgT*Ta2^&o~gBC!@&X6Rf zHDGg|eD06u23R0%0k*@9l(y7vYXdwSNkzmKu2Y@#fD1i5IrKa`{}}NhPURreMxK1n&hB-MCi0y zgp`oOu$bSy^G>e&_=4>gMke*BKEM0+Q$mhqkD9%T+{1o4@?K)LMvArRU!8ikGC5eK zwi}9s*FRrfm@i4xR|Ej3-f?)ay_n_4Hgh3n0_udR?CserQyfRZOT~04%r0HPvO4LGrTv`7A)QI~OEUQvfVx@>-ZI zlvw6T*18ueSp;BE=P@EP$Mm%TSCq@? zdt0vW_wJfOCCT19Y5Ky#)bX??195vA;yk>aWS70gf|&M}S*Y6@v{=b!emiK!L@;Zk z@%B)uMFGN)3VGXrZE zBlw8f$FJtrCueigO=WyCH9J*KhFC`3d*-|^dOIqiY2p35x3HV@CF~sj^y3mcvfMP^ zvZ!#8o?RZ;OLXcU;<{P-Wcm(zYx*O4U%)%-Gj&(;f#ij#8m8S0fSHq?1$3ZfKPI5S zs|E|{9&m|Lt&80|BTz(6qt>sx|5f?b8W%4+<@&AM}j2RW(72f*$eN|DWf`W=FRYRZ)gu*w-EZ)jr+ zF9NQj?M$Q32lm5kkC62{+(aBl!kI`|ZTN{JV1d)%+REZ;>mx}Lg%91;C1WZS%exw65B zie~kW0IOP*@%^k;%DQKs8|RVMhP|aV52BUqaB$AEx9sep{jRJ~kv5Cmj7MV9c%x5} z$AUQf)gS3Yu_le|%NB=~VOLb?KbwEFv<%3f($ZCK&3iPR_DPKmnv;9H$1=6eKeq6I zzt2;6Cz#0bZa4MN*z0N}V^AoHNtSm=%hfO>cG#}#x!QB5FK>unPO1q}5Jd;c39{C` zpM3j;d&5vcad`KKwk?7%r*02hpfUHDgjaL5{)LiBO_@LwZ?CUjo0hW4`=rR>Du=d8tSe7=o9-PF8ZK zP`lE`zI8cnFUvY>NnkeWd^E@dJk`UcGFA2VkHDpxbz4>Tvz&xzz(qfjo|gVboDrzV z+3#xBYV?2Mg5ko(z+Kg3{j8oxJ!g@UWDGzo&mout9lwX=ETG2fKd=#xpCwqgwYIoA zmX)}r{TljqdA#K42sUJR;mb_M2gd~ZnRT-_YIg%MVJz!t0MOAVQSHzs!5-sU zKI^7OdpufGs<>8;iD5*xkZdwWC~@z-QKaaNvH{*+HDgC0{FGCFWnyvt5};oZkK1Ke z0nu$y5+v3pHC6aUzn--=>joh8S+_GS>yNm6gZKF6+n)0&&d3r z!(|k&RxV7Ek@&9*2(1Ey)DKt~1+1EWtI7Lo{&|;BX-OxrTP6<)zojKQmxgzw)g+A_1@uZy#e328WlSt_DT>m?>|zUZ zE}2=%_5xB4t?J*iIG{)Noq`0OfK?^47~*NaFpI&mN2pOO+o|2L?~kLU&nB)t+w8#e zrauN`sw^EH4yR9i99Ee2qgP*CPn9H`uz0~f4XM70B0OkmcsKQ>v}M)hg#c%hjEdjq z^z9!V@qe}S9Uexm)>@?I9)zN3+|V_O7sU*7vICfEIL&gWS;=$ml(KmAFsH`$>M z1#=P0<}$!iWz?7!h0fFJV-ny=1d->{G(&&}J18Hu6%DQqgr$cGHm;h&5RDzhwg90& zhBCuJ0s}g2mmfhKvKBW001zsKh&XvjQBdF$SW@~oCp2vFYtY9n1G))xhfijQVJsvA zlE&V9$q&pkXnGLuG1gyPG++B+Ipt9Va~qh2Ucac`MDK%{oTOQg8Y17s`KOYvaPEo~Xtodm|A#8K!;tEzBoXZiPb8T&k6M>*!Z zd7?ElSK0Op9LKcs<4P80+$25E%ggzG5^Ypw$FC zB*2&9b!;kJwlh3!4;BVy2hnI#nSI)~@%bJ@IQS}ULi|*IxU<|Mrw?6%xU#-TzK^*6 z4%gx!3N#pz&L#`QbVf*SC&ST()SIzh>L~cXeZ`>h5ZHosCiH(xSsBqp_fexE&cc);M%!q1xyVm^tTl$0`Yt{P^)c-`DCZ#2BAI@!`wYFUpS?C{^M zEN{94ySc1TAr)T8^Ses>(BgdQQ4cIVG-wt%CPWD4c0E{s(|jK(^z6L9WktZvqJlrb z{LqZUXHxcNMB)esuCZ4;Z4+w~C{x84*R>j}4jw~5S?k;X9zy^^`$QszP%-xkz+CSi zlH&XouqI#IyDcC8@ag4rvpbH_iL&!4da$W_rse6=PU$fCu-L~80K3fwnmD|sFI~?9 zWTq2n!((4f4YHbLg=u@!rxFYQ?u(pCN9P5v95@IA zQ71RIgqT&8&mS~LuGkdqGprI&y^e^b{5>NcZ(~RxR9MDD%!&3KcZK7En9ywXFy1Nl zqL3wSJt(p_-gh=XiH2H;o^IBDNnt$qyw^Aj0;095(f>2-CT;ej91 zD0cL2Y}211fBkUM;fI}izePj0_GmKN6|Rile)8OMP~YG=uHoT48UP#^>$@3wFAH8T zm>bj}q<}vc#V$0u-4K+s=~h#;T@MW~Y!8@@{P)r}_<^t-btpZD)a5wxLIrPqOg$$kk5|`5FZOBl4Yw6e9rAGpkHpsoz5M34gvjC0Uwk`ZAMk;8`|pt)WSaNHJ7nkSM2eK_UYRa~NGW$VNELafq1g^U74+^P#5pyU2~UE|+|pIfQu+r)un+ z6^OT_t0kT|4K~Xq-L#z*zch34XQRDuLcAQ(=1SF-xFi|reRvqyr<<}VCf8?%?<2Jp z`;oRZMf&B0W1$9rKp&%&qcF%B&FLLKz|>1MFX7PEDtrYj_U#TMI9NY9gVV#2bVyA% z$2bV|Y4f9FaXYpE@HiOoWE z<8)}|qLlF_hGP=+W||+WUL>f&{+--U)R%zVLt&iJrET#YT?G#H!~7yFHikrCyfb@S z)KC5$Kdn7peYN;GZ=?BC?b{oZ=y+j#nRcJqu$dVY6|!1ZQ|sTA;$b z$jtWc)uno`4SmQmhL8lb&wspuBSc-`5E`5S;*C!LgYeZdBcnXO?}nd_{@y-2Iy>TD zHUe&VA^6kHosiMUuRcxt2|vyLM$(4IzP(P1D!IW-R~mP(5E8hGA!FK14}f^{WTRPS zX718r$R0bV2$TD2%l$()L!arC{cF86DTw|j&D+JjwYRR**=R#sf{#*b2e?c{!aWqi z<3Sn%Fa>0JTUp#$`wN?fd+T8ov_q%{kBPu#W<>(O_{;_CZM!s>ls1W|5oelYc@azv zja2QNyQLAfFCiVhM*ZV?jJJJOwYeBBgRKg4th5mokfKB}*vseFk)axW;XM~`BT$jdecPGzA!~B0%OE3S7myVs|qZg}F-yNGtD$gng-6^pfdO^=Y zYoEe5R(LhAUif0sK(L;`+oo5HPflO^-zNGX|E+L*VgTHbZz?RZ@T$*m1}$U8`iUIe z2*t)|r;`#}`3H@BU$!kmHjjQv%09l2!lW`kF7`0-KwS#_Mb7*87!P@CC4t~0zgxzq zx_;`bIC7`Kc5H!5&oCxDp77G)jd3-fY!!u@Q26XcKu9l{xNydKXq24S{1R2; zlEe7XWd8FI&hX3gvZcztVViVD;vt46st1BKGOz1IZTK26|g>_`@dQMv_JHxK4RoFhF0Cx zKGPDaK=_A^_kiMal`8NksslLOfcGFB#Jtw?D0~id!LF0=_kMjE% zV%M|#Oww_w>wLe&x!SrCT7{`XZDAAYdvSa|+FC(ef__@6PZefOuhIT!cU$!`R8C89 z2yO73B9HJ7Pd7jKtr;G$?ArYF66cSAH&;}CyK+81SjzZQw)*mfbf|Qu?)pm76O2>y z`VR8;3)fXygji>At66lb?^Q6Edy+&xEJ)7bUA_n5BUE4EgjWUeSe=lF{o8MLANA;^ zXQ=~du-C`OKY%O!h~V0c+!be7S8r@J^%<&h1_7kZHTAxav0_}0B?et*ALnF{-&TGA z?y=_r=+1K_pW18<%F3}n%X=UB;ICz;0It-gUi@IK^Y`b)rHr%4=y4TNo9+Iu`E^r; zS-(WP&~(Paqi3meWgKZA*SVo1;i<>)HZeAD*ZUa)mNNoNE%#sk`+GC!?kTXM3bOu@ zjO{AfVt!klW!@4H6k>I7gIY{n5M20n@6{r6tBY^cgO@h12Tn{B=UAz{{m1F(ogU^$ z9Y1@&J-6@jXXT6EVPt-DjgRr|wM{3Qzot?nUF$8!XUkd@nLC2ZKOWSj5_Goy^;_d} z1S5v6i|fIYslGmimy#|_+->6mrE%OC_2;TK|3XX9IVF{Fy?uUW+%B5vKo4yJ8TS ztB@OjiZdy3r*k*4*D5XAm&4MB;UM(0sN3Hpi(ftYmM=(SR%LwlSt|^C*G*}Lw4i?lL6Up9o%N6UCKhB-A)9&23&|rcr0%nAW!G9hp}$^p_3pKM6Vvo< z-vF@oaCPI|VvkbY;x_thX$jC0oI4Q=08Jr@gnJVhe$G$C1Mu_Ji$5jaowOOlgd0N`e|<4;e){EGfV$=St%G+ii(R9|5r6U$auS3@(Z%dq z8mu$NG;|=;?`uJiymyrpI*x}3%Yd!E*)6JplkS{JlVXhKJ73M+q4&#q$h5E#d7Aa| z&9~=Z?vbCOPY6Cq`AH@`pOONT=Cnw}2mJQsH-to3y^^0YAIv?{$h@m#1ETqOA&{9@ z3Xmn$kz%{DMZM*<(Lz%)-d9Cdc6RDarDzGUCn)dGuD3&(&Q?>`I)3UAB!ryYN8d^B zyHnn9O?qNRl64;yv2M6$IqIs%8;8`jx4CRp^-IW%l}@rCUb-JBe|m6uH%UcTUGa)w znlA0ur7O}(fl02q59EkVtUA{jFr6U8^#{tb^>X`7dJN0YK=3N>)W(N+Wkf-jzQMJT z*RKJy3BXGx!2icw z)%|NYq7?YiwSbjIk)XJKgdlaaCaAy&YekStf|P{NO&T5i&`vF4eX4JeAKIaw#J6Tb z^x{~K==gKqBnZZc8LK+2M-#w>R&pN_n|e%O28z@AG)jI2MXl1;e~eVa`$XdMeR>yG zG?Xq~uU`5*LVA>3&$?%?d7`O(mn}x~*PRZ;zsX6sNTdBWcatrQ57&6E(eNY2`*g-# z6y23ovToc1n6bdWa-4Y#04y3fw05rK8~KducKY|^R{-FE(ivVi`Oj?@P5c5l(a!zF zvKpYSUz%Ki1Si%{_vb}=dPqxSyVeX+PrF*EC~gCyV-JF`I?JF(gkMoAHvrmFe|ii+ z-rWX%yc2Us{>U3^^jdsNg9WQABJW}@+c;HsI&0xufeyh&>S!?GTm*XUD@OE%JUkMG z`~-BSJ(!?jI1y4-2-iT1yrMQ(0~Pcu9%lI3hAd`FDrn;fclUf%(*`aay{K+}Uaan@ zX?34qP<6>w@g0yXD6|A`U%co{lP44+Fxi692GZN>PfLSK7c`%m+Oz-yK7AMI6gDsU zdt>^0r_&*qPu>A|kmR&Z>_w)h^7LURPm#zs+KHO4)AE{P%Banf0Jw3+U=Wh6Za~pz zp!xP~=zidYhG;uDK95fr+HocJu)1Y^rOJ502@Z#yJ%VMuKG||aX`p)U#p^_!^)0R6 zqPn7d?W>$yy|lx*Hc?-mgLfJ~cZ&jUhdd0+%*I8;s!p!LEgd`eon8rZ3nfb$MD^_y zH-(b(!N$4E(Y9)7$s6pv-9!HLSsnBh27-N}EF-WS#*&D3bB3X1Ak%L4sItj8SkhpV z%d0gGo^VW-l;*7YppEzVis;ifz>?OQ|DRPXL4)UZV;S8V=bYR#fbujc&mC2ZG*4>O@l(>j*kA2nItLR+_PWk2Me4IF-GHf% zX{phzmoxQpxf-&a0C6QLm-pQxVGc7i%*YI!JXE_kabx{iKjKgrW`%rVXliOv+IPw3 z3}aI>=Lk15qd|de5ICBX*!QNpk-gw;p=p{%yfoOaqY=}O={DHbmxd(q`OW_X0PZfk zo**1mFD(ajrChC-i8|Bt4YGHNssz>#O=)Znh*sF&p>ond(|Yvs8!80L3iLv$<9)L} z$2RT#E-z}{IIg+p+((qn)vEd}MM_@CKE81^XsP1$tNBs!zhMf#bJ`R4YoC2qJ4p-R zcV*fh+DS+Y9tTk|zHa1&-~}`X_)I&J!W2K!9L{ieeT)4PiyG(2~BnK6Pj+^`ObVG=!tkfgJ_CYHMgp0A6S*!lg^YKwIfH zEuW4cBJ)2TC}9FSQ4{)cl0uyC93JRrH)JEx>d+%@JnF3ZKIj(4VzBv-AsUTx&Ea#_ z2zQ;)J)FO87*Ee`oA4kB)URadiXp`{*CgGIROF0q&>WH(=A3$NYL7W?aEzYy?*(%& zPqypHBv$y^i5wP7>#eGDut3caxS7=J?GsWp`gGMHD=Tq-8LKLIS7{#$({o%IBorrU zfqO4!>cmkhxfs{@XWC{drBrRS#XB?Q>D)o~W8pAMxjO?saX4V}NDiy`o@Eo`gV1g- z=O4UYp+jwbNc!-`=g?oHMq_VEYfh7&(-pj}<3$I` zhDj5-Ih|frk^NEMz;7bp#mitoJc1JN4$Oh$e9wh1idk_hrogx9ACnaX$|terOxs6m z$muOwpd2JQb`|hHun;a2SO``K>ao5IReC-{R6l<}u?P{nqC|~Q`Se5~$W6o9E-^sI zfG%R^NZ~J074IpjBIf@ zddq5+`mY#@j-I`YE2vg~yM4O@EBsebXCEk_4xo;Lq?=weNEW~)g5b2`806OTq*!>$ zo9Rf`s__f9gD{SW_7qCrC=HbLra>RTY>GxL_07<+t^(#rX`*<{lg`VhwZ4)UoW|(~HK?u^6wOS@!kd0C1OK>uR|9TxBl}GLbxcXbGd!-P( zN3T3dbPQLZrU!q$pHtvE9+_dxBa}xNQGKFC*#pt%GV74M=B)bK5u*TYxJcTSJj;ilJ^qr0=vt#jb9p|jgp%= zqiMa0E&Mp*f7}b~5bmSB4RttkJcElN8`^GJT``OC8#rXBf~N_}(npK{Ul1EU;?gyQ zO5;#Ew_Gq0M-z{4Q8xzZP%JcZAOSn z?mmWCR^@$u{$7s7$2|tjB%tz@RedlkiiQT!dh?b2pc!SQl}hYR-z9|FBq+2%{b~}I zm5goe`^+6l?6)wnBFL@Y39?fseU*pd?)%KTTQ+2ox$5{;4mUHHWG~+wr&p^dJraev zF5D;Y38n;8l~(uusqurLsRWDQz^7Gjf9F5gl`8WhgX<~)gOuNeX#V?cT2^nw){e4z z8-X~Q82f|JP8j1E6l-+e^?@2ETcq<-_KSjSk3}7yX1ps+C%h?hcgti%eTnlXfQ?;xG1C0 z$}=4F2r$aTy=8*jaP3jz7_4%X(Lg6q&&ELefHS92gLoie*jgCh{;l2VzK>R(&iVkS z?Xb^{m?=O=j(w$=_Nf5}Y@W9z5P*|p9^;%4Pi5^?Ksm3!>~`gd!)4|=L%;e0+nW2M zf8+yn^?T}7=5h5xns+B;SK+mQUWzv|3(VCkwa-X&Q(Tu0if@`KnzEcu%_ou)#{7~5 zUWg{nbMsR3=gH*2!m&0m;V=QO)+)Md4i?>63n>gvxq#oD(J=7FbKv$4{Q1RyV8w(D zxONwKCM zQaiH4X1kqMu+g6l`J(aqY)d92S#zz0>=?cEud@Mp1Wm7nqNFZLUIhzCU=fPbW`r;< zf6^)Kj{>p}+-TZRL;2~Gs5mon2JEJ)hJXkHC&HYsr2(_!Lzeqg@Z5wGTwJ3m`=bNt zl~0lHu@846s(9N~5Qf1u$4>*st=H|<-SjZ?TfVW{U~f)m18SLf6$r+T=Q`Qpy`tg8 z{GZyjB*8wN{QdXU^{*bQNDQd<3Skr98q;0$FAV8D-cq23G2>LlEe1mAhq#wLcHh6v zNR+e0Dv=M|qj%v7`YCwzBo2T0x8T^Fcr_hhVKt=pd7S#V* z66rpdN|WLqg7iMJ7)rL(GI-_jM0FFsjkd5JyW5G8;wQ@;v zPly-galptj>!3v5*>N&3ka;oG`~3?QCP{^o{Z_B7{wpz zCL(R)#=5>m#WTKn?P&a1`tPKC<@vVpo==0#JfIQ zy!++9>)s}P&^LJf$$IrZ^juT8Jl1>joJFj)=cQ~qcQ;HCJYJ{wpTDi=le%#SVT6)A zZ5m;Lpy(x?pkZ~6n22>f_AdZbQqd%8a|N}D-zpz+R`OoD%sJkbrn7ne-T3ASLPDXA zKr$Nb^SZ=O60s2g>uN$ph0dS>&xENEz#1`}}F!&2G^VNF|%n+XwdEIdq+ zH4I|?vwWIVeipGH{ZpwcJ14VT&|SQ+&GlmgV1w5&Yx*%%kB8WE2!`)w8HLsV9lw>M zSc@nqcLmJEqs;*xoP+qTB66}eV#Kr%@W8%EH5~;K-S&w$t_B`}9_>23qI^ZH(B>>Zb#_GMxzZ9hTdE(m_COxn$9WCbm)38z6JS z401=*^{4!Az>gT(u76!yOLO*>dAYHL52*8di56`R89}6!^eg0kW-BKR9CUe=b+2P$CsY~^8tMbcH2TuYXwZc6MvkaaJ zE?vZQV{g$J@DKP2ti6FG?)~}RBD0v+TkX z_W)oRUP)eXiySpH1o`V7C~I1Fw1+M*qSh({Y1^c)$elT?7L!ON#&kdF6Lf)XPooLfRk{<$0 zZqD95I$SO?0(QszORk_(z#%$iTx4RH#A@QKbfjAqwjNy!_HP5w`RW#2{<$OXwvOnX z$mYd6K*mI!s47rtVwgMRx~f}QjBANYTUH5L+r@v@tSi_Fd&CeYPqT<$j`q<1+T9%M ztUt(H9Zjm6|75#t1J%=PAyyFM@a1qWRl4oLYw`gr7CCZpVekcErCHckD)*97EI7>y-GHixtZw~6Of3Uty*`zP|rbM4f}sagM9pnnFx`L zEm^f2)Rm-#bAEo?RX8II23_J0#(RijV}fNRuT}xtx=VV!y+xF5*tCwhzLxBL*b_&v zz?qWsDc&>dP=)&|?mC#MUuhctlp>B(^|5w3_gP3(t^=I&L zyP#Zu>-60&(Hs%wgDEesecgJWHJp5~Dy|vFXZzYS&nP8cRzJZa@Oo0^P-=`$9H)4y zBnxV5ZgS+#$b!>ys6D-tA(xq^rj$T%6_2=(xUTrK)(^qlqXN^PSs;Y1?K|S)5o_YI z97o;qU}g?=!o}LHZOU7KQI>ZCpiBPLuGLCgR@*i?`d+GJ=Q0hdtuZ(2FjklCAhvUz z(B#wL;|t?)By*g|`YIr3Zb_sm>dMkK3F}EU%|1?MyL4^Rv21g`IHGHo;?+hNMH7dW+LLjLa0oqg1F=SdfubAHg)TrT$Wed>+=Mw5h5{k@!*ps8Mz2 z^WOZl(O5C2A&B)-c5&6MH-j&;kv+DZ3G71%dd}&Zi=!-UWRvnAIjXuyd`{<8qov(6GotgzEy}j5OVM&B zrUxBvFG|AgF()>)uF0MGq{O(9c%<{l#c9Ae{?luPyj}w*#s`V?w`3IE5c1Ip>Gu1e zqVdcXAGw%)bBfF0N}n!dRjH`%=Mk{a^Ew=<#U{d?C2Z<_=s4l^ILJ>Lu#W6wEzb}= zP94Kt`=7k`P)<}Ct^BPnzlERVrcqJGQ3Bhm#M4m@{|mPZgIJ$9^v2528qn2hsSP{< zCQEja#D$ZUc`has@_fWDPtvs^5d3AHVCzuF3|-ceP2r6tUcUvUjvrvaWmd?h!mBbt zMa%pkj(WSJRc9aV=Ge9^zGLj_Ez+4jtZ%UNmUp{G4+TdwwveUCpxWncn-YoCsfz>hY+T7E{OEj4A>HJalJ9fRVXKAac)*2r$ zfJ%OIVMd$zSeLv*QnX^*b7`if25xcy#z^IxNZmBH)%Z*C@`@wB#KN$}R z^uZv3o#Ncmr6GDl<{|ng!fWfLzc$lcvbzwvb#F@f&`|7<=~{4G2*=m#JN|TC_#5Kq$n6xI+*6e_bxs4iTTGxlV;~M&N$9d_!fX6oAxjlLw=GqMimNW#@WZO zff6pafsx}FedZI_>uFm+euIB_r%mS_=G8^O^8XaVV32CX^2Y<7critCUANW6)CW$9 zZ15Z(tFrzaFLuXko=3Xu6icFxXVbYh8k}{Lv~_qwj0AK3bZcd4F9;nI>I_Zz%XxVC z7)YAHK6sxUz>Fx`=QI>wNRj8hozsxoafg>0C$G$iLJxX&lauv%Tm8QrQCNX*>T6-v zBSr=ZWNYoW`7Z@p-KqQrz72)VyiF4iKC6Z6EAI-X<>pKYiXdz=uUijcj(i{KKGP{+ z+TMyQ-Wr^!yXje7GQVl;rk2poHbsbvsnHdj?uXR%17wK`xiyNcLardkb`n2S({Nnm;J5dCs8)=OP5?&cFW*~^tUY`~ z3|tMw-Dtg3B)6DY#DH}SD?j@-^cu{vx*-Gixk$Wh-Qs3kisS*NfA z_(Kc{>g#6idLQXd#+7PUjDFPom`-i{QX+R!U6@to2;sO(pr7Wa|9rJYxm81m z-5y!9MB#1T3n@$Dlz9jDS^HHJwNo1pj&EW%i`R+sz}!_V)ry4Mg9Ye!m^j(P+qbz- z_mEU;gXlo_Oisy`5d>Vp@_I}z4| zxGD<@y0~9!KWvf&8LIFOlosfvesUA(j+Hf?EB(U82#e9o7}Zmr>fz~RR;RD54&RLp zbk2e>fr?2Yio)Ddk2Ce>8TO1`N+JPy+`Ug*zGVW_@frK&8G>cm`_C?qtOO=(r>g9( z5%*Yybf2{8h~UfOf>;|hzJ3+aKI}n-JVa__p1*RdH9Ul8LXl(PkSedP%%~c zF{ntZ8|Qvhsbg?M#EcUD0pI&nyR9`dR(l{PFY}T=gL98=VSm&r*h>qr_RZcs(ivgVc zT?L8B@kT>A8fvC{!Qew<7NgbZ%^63yLaU0Yv}L7hc^pkg5NFCoGXPy;czik^QJhG0 z&rvG{IqI}Gcew&7lc6FyIGv{0UZJj zD%upS_BAV(qVoPV*$+M6r5;LB=ZHgTdO2DYT0LuEhqOJ`u9Z2Qr4BG>@l7xX^xs{7 z3IuxS8CmYbI%}<|Uj@lzap+@H#VUb7&Rv~eYg@?!+h4_2z=p7igr{3(8d;8<+z#QV z3F0?aAOBx1fOP3`cHGp1AUVZXK=N!e-{XOkJ{V%a9e}hPF|`d-ZRKKjbAM|h*Jc=bYo-MSpdLs&Fnb}J<&+QH{S2GU2~>CYm!^8^>Cei32D z_(R=*F2}fS68o}N@Kua)h&nmC^IHrhAoFztU#ybFE{C+0ekmOn$iDiuCZZ-{e!Q=R z-bm$4Ywqh6mwAR9GT`aIU!`94X(nEik=sIu)x8zjoz=~`mV<|k+g3^5LlsZoLtS8T z_^p>bzO{-DI+_vNX?$1nTFy9$=HyOmFLi38gHQnq6NLWx1=)o*>p1Z=+lpYsi@x)Y zWWJpIWup@hu`S8_-ntV~Br}ocfZYT>=eQ?`omaWlp@xrxUH^U0=SxU6RCMr`Hz>Be z-{Sk&G6<4-i)SbK6HWJr(5!TQvZEaMg}@GU`}xM*Zr*w_dl0*vnVIdvTAQm7up*2Z zP1fw`7^uFcy!aF~tB|T7#Txh)3zlDl#{#Ph<-mjR%P6PBq^`sQCTNfVHn4R|=C+JZ zvNmQhJ}xHhJL|Hlb2fk`MAR|pg}3Y9FfjMD<2fVhm7J-8ja9W=w-2zN)pqx9dBSV;7W>T}KJn6=e)OCn z^6;<1@97;s_wREA3wez5U(r}XF_~;7T@;cLA`s#oavJb|+Cp(K#U9>A8ZAVE6}c@Xy;=4*2Kx-Un)hKZ zrighc-s6N z8pA6AfY4+U(p8X@gQ&JytF4>Yr{=ad#tI*##pCTR54>%cL*T@06HLP<|3-^wRC6h~ zrp-|FePH%$|2TE?*Q88oX6qGc}=eQUpQcdxk^zU2(i&nFC z49Q|ur7ojD6unN#r`p1&lS$M?ZsI0sAK(0}{3sZ{*mV(YF`)^)pju8Mr7u^AEO3PR zuI#jizv5lodh1+NM&CmDSj^li@KwFX*N^5AKQ73h2C(!s;2F&*MZuKx^qh%>@|Ph` zU;qwl2*lVsl~T+_3w`949CxAjkP{L571+`I-dn0a%i(};(T;&$ez`lh4y%e;Y9Qye z=Ya!yFmGg_4p5PCB>fQokci80gfnVbKG6dP_jD$YbRL96C`~{r1;km}V>)_5X;#&M z^-{(W#t>Cy4Hg(@7+3zOu*=zM8i#5m61hAmqVCS8Uu|=IcZHJEMX$2_#<&B0ZM@>e z(xS?aPX}=El$`r0r&wC?aL-_eXdta9ols8A0Aa08={Jwjc@iXd;<7GH8%sStgoqJZ z&nYew`KE~dC_l%us^DhX&eYN0VzI2SW4xTB%QAn``K+|?EnHti`f^3)r3KnaR3#1X z1HM5=c#d>1$6vlJ?=dBQl}Du|d2kF4`b~2JWlR{jy9(r%+lJP;E(Zf62wM@7RpX+C zp47ddjqbS@RXb=*X!iMiNXG$=zbon-F(EU+@juU3p0cI+?gFqx{Rb~bcEl^Mi1x5IY&!1H&0+#NC`EjutM-F zegF4EB^}JHDfq%avwWbhT94=6X1xCD6fc54&ee+ml#<531ylHU(m3Vgn68tzWg<_$ z9{zrOt3IT_bN?lFC^Ni>j~cIIi2uy%+cJ&xu5xmkay$uy%OI;7V~E)2%Fpd%%Xn`h zp^=0acjMK39!JI0a{q=&DNj`?jK#*Ry=nie^2TWeMXzx5zAgi=KW&{Dd-9AWtS1zO zC8jHQzJuvqrdoHp;cSbxJqdI-?-BGcChwS>s72JQ_tkH-7YRx`O<{i#y{3kProO{I zx0)+bJs%NHe!z~hL|@x-HU2EHt^b%tq^cF*fpz+;jS%O{lLuITt4#%EyHlh1oNUQ8 z+aAd)43SlgORWP~l6BZI?c<{dHIkR9oxr`)BoTqlNeL%CLkBK#>9r1k?6^+XBHr3a zkaowaNABacqG^?{H;Pj`MD=w`4jcsgVq&(@XtxP{mMwoKhRasc4t>l1E5mYf=nk$S zKG5fB>4{-csZt`eRQm5P`8=2cko2rC?qB^0=o|sbdh(ECU%44VDnA0YbbLC+hWHZl zvES76@P)5y9c4K)R}O6foV9LO&TS0^IPm2@{8BZzib@{C7Xb;%_aXc&B-7lQs|$GWQ~reKZA*a|datZGzvk z2|szMRrwwWqQ7j~aBUul*6LF~`;cmFJK>_*{wcW?f##$p=FY4nWFxu4MXGfTXPj*x zlbOL-jXtQ`L+tKhk^hypRCBrqG8_58rzsE`LIA%ZWB@h(-&}$JLU|wIuY+sVKE*|Kay+9d!TR~Q57<8@qwgxA{>{qQCl&gZG03e$hm-wn+M$N@Q&-n} zEZ^^+w@1~ko=2BLfM|}V4pu?`pYQ`X9-=?`I_O?j8j%%e^Tzv+t$JS*1f}gE`^`|7 zAB?1I1amXSKj}Pa7YTDc({*PS6=8gBl8f!2)9Vi|N^85L$**QVa>RCiOhc`36td)Z ztmJT4W#%yqY~UK5D%&0a%CVgymW0u{U-uCZiri8d=>TmQS?Db_F9{1%Fu0~%p^u9Z zCHOT1wC;HjEfh$k1rBsCZUF?4R<-81N+AUGB$w*L`j0Qr1SP1VUmosHzV`h%(Mu?S z6!|9Y-q80-GTWXwxfJQ;xC6u$|E**_tT@u$d2DQ<&OhZ&K!5W6r9 z;}N76?B^VhavWwsAQq;-0%kNjern3(K(0KWRoA6w#n&4=Cr7_~;8A zf-Xk*K6^-IlAi%6@DrNSx5~DumVw>mMQs|IgI^(xp+o&qT`Dpc z4Dwr-7FZH-6|y-Cvjr+(WHnw2lF}#$iKXnBMy4WfO{JP8+~VlxbHc{blZeSJj3UuQ172bH z%XQ=W9v_=8MR|g&&)XdVV$_ z3KDc*TAu)cs)w~TqtV6{Y;zQCI8+jd{>pruBg{y1#rejtZ?tf`Esn}dmIJb&Ns;H) zOVbLIPRnj~7gTzrkrx`y$9;=**r#%yL}?_#xOLlG?yR>=2X8L{C<0Lyf*%kZ)oE;a z9sP)-Ymuj66Y8};wO+$E7Zl)hBK{&~XZl3GWCBb}y;*eUK9D&O$V=VJ;KzcBeya5g z=AI@|2&GM~HvE5zygMivBLmr`tS?y?&KWZbIJA@jxEO0onxdPTdePch&dWJJ?4c5} zaW1SS#lxD{zS8I!#Ndh@(G;dI%VeRZ%YA#M_BCl5hNchu1O|;&Y4+I&zgdNKfz&cB z`ftn1Q2Qj7luC!q#U5u0?idjIsXozY@DkKZB8^V=gJkQSM{Yg&$0o;;&jqoL>>qB&CIJFS^m#&Kr9~y){2^T0^){`T1p4}WZUlQw zvjaldBC1r~*xZb+7CE17i%@%IX_r6F* zJHH4AUlQGk4Z9gv)HB-gHFo`0S35fcUwF(Wup$lq)r6|@e9Go5jy)Fo%QDBAK#&$B zTgeJ^_a9&CyFzpGjic_qv$&Y=G%%ri_pT*C0XG3aFw#HEwzP%-7XU>!#&+L-I5(%P zrz{6ykBQ?kg<&Wr19b9Sa+-kXTH{L1-}?;fC@e)7f@M00@E5QoHX32ZVTz3`XhWYS zwDs+rCw89nDbj|r>pE-TI)16@FF{S8BP#Jc?&!~! z9cd``r1-{EmT94HW(W|YQ1DmR&hyu55SYJH}8ce%O+kVp%YSYO`6X{<5Mj9aaStOb|z0(PyU2nTYkF{y7BL4kj=l4hmHG% zbwfX=8}^i@H|#w&ZjeN?R$;A|4GBK96NCd|+-j-M@IN>aY^Uy({yHlrk?EMApiS2S zN~;H}q6x4@0_g>kuK6Mnqr)G`;M}ocku(VOJ~y;WY4?+*D(!I|4dnvHy$!apcFFm} z0-KtOjDl)Y$=vjnUiF;laz&Uk@pz|kKEvOcGg5TBSQF`a!@$7jub1vZ#@%dhi{c1P zX!_W5@>ZwZNmA0rt)tLm{_m`l?o*95tLhQ78PHSXGewj5U)QY*91L!{GoK0{B*kZc2<(cbAeZfs~|eS$IOh6-GtfEIaAXC%n+N& z!*r8-2I?`4a$=umE5JdcUb(mR2pVy$Fj4?ut@TbqzOV?9tI7P5TbiKtCOqs`>k zKcG&^oHnN&fk-s(QI9@%UOac=hZ7}|>$T_{lkzY0Adt5)9mnk%oVt+318hQwSy;K$myT zZV{G>ZLvrt=NB)AXI#AN)~`bG>RoP3hw}ro`mpGZ=`j;9J!p%(#Wpnt^SnW~S_9tC zm*j>bR8lJ#M_v|l-S`p;$Fi`R662dC#qEY_9x_GGfu%8KGsHL+7ODGUO_{(Mo~obq zcbR@{xBp$;E7b-LR4ZnQ#wd=A@!h#&Ft6E&8`YwRh)i%Ig!M8WETlD1@g*2Oh=%g9 zBQ8IH731WE__S|a>4mOCY+TWO-X4U`3 z6yhQiDD+3)!c*iS|Ay&i1t4|Gf{GQ50Y;QFAgdosjw+OAs`7fTrY(PLA;#|Om~eNv z>jaRn24sPzBW7Yhv5MAb20#ujknGJrSP(Wtg;+rV-Qw&Ig!V|>~dxgxS<4 z_f=Yr2hUaAIo)s7Q$^E{=!hH<mzbSFuc zsFS4PbBU)k3lhiAD$4(A?7})p{Mieb3M=`bfL#mr2t?2)tVP9)! zL4--eQrds?TZs5DEj+zT$3TMr1K(*7j4Zkq@SKgyreiQ_$CRu4Dj8+ zuV(-79dU|G-yV6ue%NfHHbv+=BH=%A4_~IPR`9mZ%=g9|NuP;aBl7b5NbO5t$;J9d z#cJPQv6y8_qnK|7Ue_xA95lXmuuOn4lTk5A4~gHFGrP$ChS(vkeCJkwLvVR>C-*6u z)X%wH8PQdPy5Nxy_OSx8v4l*43irN?-|Ng%H4fkI=U9GzXW&(4^#q7J6G?kt6|!@C zq5M&q-M>A$b7U)z?#|w|d#iSZv8GO2Qt^bM3aTF!sU5^$cxbN_C2h=&4`q#-Pzrp% z4dXk)YyK`(g|!XwW7-}I=%#2_a@%30M|<;cb(GybWg&L<%N8In%CGo99r~MGuP+-W zC4if@SHIAIp`B|;_OQMmr?H@fiO{jDr<+}Qb1BJ%5V_5`uE*6S77?C2XZZF&@qqIt zgj>DqOBPe4n;$xe;$y-dmY1IM0vjUUBXq)_4MDR`F@BOJO!oV7`S;#eHpy+rE^se3 zW&T4z4`0!!iDdJtb9*Lu;m5;#=nXNT*@aaagE!c%o0$|ftbGp}kBiZpsg$`7jHe=7 zk)d}pXc>xr#tW)~u@5RNbi(?pw)Tq6;O`#~RdqS*T?3x~?ELxe46X-4Q^@$0^*Om{$$*7uCD^WS^l8)UfUr0Ut%(zGKgX|VjQ-)RsUNy zeD?mjqw;xnog;|Edm-?q^5%Q0#U$Yj{r%D^AomOoOz|Sr=BM_qM3G1@57m#V)JK^S zcFgKWT$Mm(^Sb;`8&BXnq7+NfQd{$#%Z<_+D5;2mZLmEqxR)N%CWNA0fui0%Z|^pQn=5 zk%>|g_pIofy zcYZcRpU|BNUdlYQ!98+!id6SJ5oD2kA z_ouLnod>ejM1Fa3lT*1;^~Hc|dU7mqh?GGr|1&PbwTd;sTt8lyU5NO$4O1dV8z zBax)R==I|Y5N!8U2N+U=`I7QX3K%>O-%F13`T}oY#JIi*uL}6@JpT#sc-$E*r6kfibnSD305pk*0C+O>uk`{CW0=8b@Q%_R$-wtg_ZjfEakIel z`|Pi^xBtzzhqo35TH8j`*5H6miv94ou0LbS4~^6T8o5%msXpRJ!dTco^bXKM4A_wY zp6@!{qigxlyAN-D{;%^;#{Ts`@Hj|ljs3&G4Zwg#S}Lccg#sN<5c4Jy8uuF;Kv<~o zPZ$T;+M7;ITOb*BLDT5}-h<^a@XHF1jP~XMVeE4|D-kXX(f|sv-^l{4>~Rlfh}nR7 z23`N%N3nZDCcQU>uw(L@cjCZ&dx+^LX!6ik#kzbt4bH#?KwX+mtAt(8wmd|$SoigV zBFv;sX>-E2?{$&NNu*(~vhHW$@>x_94JqT;MFzDhqS>NSUk9@2jee&+E59FU9vZzzVzH}PhS97 zSH1vviU*?%b=ehQ%mzaR)GC2N;7a5h25A!o943D4%^$Job)9zLa1v0*EfjTOPFpkkX}Be0ai5b@3^?80cc*yTeM5Lw;X%rr@e<7~r(= zzu|op)CPQ!`9WlDv{2c4LX>9N75&cW6?(^X-WTaCg{g~&! z$i@!{lwL@+%!+>y52&@tDlmwp zP)wZuNMQXiKyg4aaI+tuu>sv>qr0t5NZ*Ev=$yM3FWI$X)f2Flv1#}>1w;MAPzv>d zg)l<@ttk*tv%o?hAmr~Nwhb~)DdxDPO>Eq+XWpK&AOOro{^$6k5Yz^k7BB;cNrKtr zez?4K-0vVS<)oDWa50`oNL$-bsp9R2fog-Aqo3c#DE`+XRFJV&$%}b!4FG>xNeg*s zhU|aQUx|xKD3ejW;wDfk9a;1)h3~(<|F^4fHXQ^4zz&TE4;0wzG#2^C9Rj+s;R)1y z8GJ&V;Ek&dl+EGdbQ%D7F;=beUtsyS0fLvTMVyP&B&`pN-2H!x+#n@Jw{jY+wRBpX zlHWdq&yLMb>OpEvOZrE|WAof-el|N79iMw((KZ97ih7H;2OthF`KIvRWXUKREf zU<Ca6#t{2$gM_#IQ@=Q78qEMel=b zqhbn2^y_JWyH}?t(d~6N0m#k(?ih)HwGQW^1q}3XQ?gijknSwhuXoy+1B5n}0176< zY@=Jsh>Fm&ih=qM>p%I%_345C6x{#;TVe5=vQW4B+YO-5=QN`HqEACrgz>>92=H$= z%yM4}*A@Z(YS9N)g&6jDvEp;anF~^VxqH1@`)7a}idB4zM)mw1;5Ni~TLr+s3~Odx zr<2Chouwk`q2DqO?a^xieZgOoZh%gP+&B3PJm0%NQbfsC)Xb-4_pKMeEKUZLL%Cg_ zx|*DMoX@&(%Dbp1l%FjG5jBK|DRMTCiX?KoU9P6|OOqRrQW+Vem)PPp0y3H@1$OP} z4t^(6G(aoN6Cn}3Kt=memGgX4@`{=Rm)+RX3orgC6UWL9-W z`)t(eyO*13>jC6YSAbPE0U&!act4fgjd)rTH(6=f4~zomgYLvR3}#=yN(Kmhy5#{b zA;X^~f_ep^>RLuV)xrRu@CZ1}2$}*qhl)A?bdvt;WEJ>giY%=M{OV+L8F6)UdAtfN z@*e@wt^x4Z7jy3Pu0|cvs_h|c3Lr%UeXBU7^*ta8sf}cI0Zy6VfdvUGQ4Yp$FMqs{ zuI8D03sFD_+_(VND)Qf?FYwS%%XP^}(AmjafX>bY0iIDGNm_GdV_jiafO0AOkk@C1 zx6$Rijtk<?J@%^VtKL zjCmciA9(YX2Pw=4_*^`b9Bc5}gC$6cFEFQ^fR2tB5Cvp2C->5T86;iOe5UL6`)#ZU z6Bf0jKeg9RIR~0JM&K?@ve_T9tqI%8-!ry3Mxpo=u!jvf0{{>`2Tq4Cf{5b%FW&D0 zTD$8UbbuJp$SN)5EikbKTL<~_;V$j%tz-I{F z03(B2tT4jw4BQt(I3j{r0G(Ei3@Zt5u1Xx0tK$Sl#hHB%GKS<1SqgkB5}r_7J9!}x zL>Ckeh!`3aIe0$!U<9)eR~`UXO_dpdA<}S-o!)q9j#OBKCZ-%C-6kNTA9nWiR|)7< z7gpVf=&l&g$VJD497v~6OsY&11>kkYZilOIC*o{&IZV|$Z~_>(auO3`WtBQH z`u%am`-^KpdU&SUxDJ3|7p z{Sk+5fSh!ZlX6n_l7sMfz!J#b+myZ}Y=I=8lN>Z&HP4B#?-B!y$=rf*-o{zc#AmT; ze66eT=UfimSmd9!)j*cZL}+R^^5RN*0kLiKLZ;mbu&ODSC%(aMN82Qvas|Zxa_qX? zKCNg2betwY@-+tkt=rrSvAc`hPC7kqdlx{=b=o>VGs5_XdzW7s(S8>E=J}3DaGj|) z48n53R>NdYqE-PM;RTJx!|~zr6JE(146d@mM?`)yuMR~Q4OYoZ@Tleiy8f*oawk+( z<}~c8{R|MAbbgy@)ol_+vv$>28ye2kjj^u{n_vvD89I;(7$$=ULj@aTOAt z&{0u)$}a@oxOgSDIr%-swxW+o{sm|WTg?-QGV`Ub@D3$r9z=U=@YgS81L#YgvNZ3} za+akC>i_Agz7OUdFEyI~VtCLV41Yz3hHCnI-UD#1naO3fR7m>t%mS0AsK}skOe8YZ z02?OH4STBVc1r#+k07J4y9%r!=fdcJlzdcF!odGuW7&tv`T^JE_9(8;u z3NkwmL+;rtQeee!5nS|l#D%=bO4!U%Bo;v`{Gax@E|FxisP z1pmmnuX;QjThPe~i2;JE3|ed{uA%D*CK|QVlwcc+nj|0hhaAQ)qB`^1-%?z6)>%`T)aB zi12UcuS!27QR}q)s+zrLE9A7&Tjz`Gip|D_{&wyWz#GcZfTAppBlGlc1#OEq8v_m_ z#P9(Z36s3#7pdi#{1dPu1B8=zbdnrKqfFYTF8?Z?u}hj|+V+KMvKh#-iCtGI#rXx+ z>5-vHEtBJ-NSNxZV<$m*FLt3cqRv=>X*}?euM%CvvEm$&$pqKO1Dh@mNo*nREDys^ zEa9G|fjAvt(?NF=+vhQzu-YHd`(@|#VoYFKHCL$v>C-T`N6Y@@F+|5aONet`wD|Hb zi6|1N*}r7*+c9FIo<)QwnEmPRv;huqIcmj<0wHZt*=s*P^%?cP-knM=n0?zF6%W|% z4EhLvA_!S|;8zy=97IMCBZ9tq9=u;!4&0b{_r2J(^0i#QOZbdNRwl`OI; z3<79N54Krh~Zc+CtSXz&`>Owv~8Ujg0Xw&DJtgFN|@+mXN3X??!v2yFsuE3&$Ed zDoK>r6H9mt9{~3O0o0$BhyBK$AXqGg`3?0VmX75a-C+bm^FAnVSS1*?OV~+rO^*q( zxyZ%c{!DaC4HsBKONa3uXmpbVhKoY-JP6e&$uj7Pp-Tw+l1RW`Ifnp2$<@VtfVI=@ z-cA^0<2baGPbTvPXVC~@h{1I#J|NHBWd!o?i{eA_U07%~jt;uhah=tvXpmEQU7)oF zO^g^-+i6l25<%sYq%|AXH%O<_M%;m}j8oMKUB z1LKaynDSpQbACsZ;~otcg+M74TElsPbPbrGH#;4;e8)a3X08u!)64c|O5b_)ddoAI zekhB@#N_L5P7@yc_K?9AfBzev>s4}#!pn=}7g^}#4{m5QLkmH;@oQ3B`3fwlZvt1x zv2y&MaE)x{%QzAYnp#i}W7gwwa9JEa!%!vvCaDfah08k6BJSBOzJWEowdL3SK|I?E zTey-TzK6mHZzM9fig9YNXM&tDj?FP3t^$vEaH&%Sp#R7&fum-^K&CQrq$0QePYn^z zdpYRLMF)Jhbjpm3OX68GpRIfRdZW>XsRyHm7=!3<)3eV@kPNtDW9Y9^N^lOQC8*k< zbzi%B9=%63QNM;^hNoRz-XSpQVp%$rh1@O5xTF+Ult)@m_60wD-wpP*W-|h*j@>~J zuZ_Pc2ihn&cT=?c@ACmBk-ur_4cnZ6l>2~es)^QNQ3t9TS~*iP*H6{g7_8y=XM8We z>NH|p66pyA{*hV$ME6BL2IiicXifDu1GAu;7s>F=KsfPzbTq|N;hO|b zZpi2ei&`LEaI=<&1GpIy@hwnYI(j}E-d$^N2Ihm34rU_+!%nfl+xgv>{Fc9#t|`k2 zY}}CZoXvX=)%qblmq^c0ZA^7)dDV*5CRle2~Gd>o*(lQQ9^s2!zbJ9P>&xaFK<*I} zBq%zEO+4)I>6DQ%LJn^b#;B0{JWkf&L=Gd++pgCi7maZaB!$3Ri6A9}aSCHqU>-7t z;G%X!aaC>z2Tl5IEnRu-H;)(V0BeUANHz}AOWyG#Hc7lH333TW4JJ~<8GC01#mZWj z5WKl=BT~}T-&87)QP50c;l|xgY1K|iB9*I9RpL`e3uo+D-EUbPTr;J^mM8U1qy54! z;|-MyCyetXR!xH7)@7&q?qGsf+}bti587g#MF<(9QhjdFPz%SU*uZuR!QyMQM}OM! zIux&ntc~D;b+LZGjK8y>^6Zd?GW*8tR%aiQHIPh7AV8@SqcHup5I*4(=o1MI;^IJ| ztn6EqpqIz+&3n9fq$B?q?bUrIMR^#$ELf!GLFeIrQeIGAa;`v*E)ZNAO z&0qm>@Re%~U!EU4ds z-H)%t$kfl94WDYO=Nxnd?>L~ag*ThT6FU-ll^%(9(DCVFSiq^>=`L^OExcvJ6Ws5D zwF$S05(VMOh|kO0OsZbLx;8 z|0kPEtEYX~fyFRP32`CF>$nfIU_`9wO7QyO`?Yff^%UM_i01L46iS>YI!^FHXgG22 z$A25>iznS;rb96$g|Ne=jCJp1=zPiEJ3JCxcWLE0#;O>%w(c%^1{cu2x9TJ zaQ;8O!)a}(evnK8Dk#P!XFOXkDO%{Ym6(k#@*v16u_PE}@xDAK0+2z~gpHA3#uG8F z8p{dE_d^&TJ;$+^P(zddTD%b84{i7{MM(DTx^lBBGgYq(T{JpdyrDfyRN_;4p?&Q4 zLGw2$u1k2oPQn)ZYyt0=)b|)X7$5IKR{Nw54h+;U4tREof+;)57!?lQW2nFPjfhiM zQ}Sz1@%Ein(9$>=y=%B83&a$nKPdnHbqf5Y6YEf8I2tsVM>3?v1WTZ>G46AZc$boJ z30!&mL{vv)DRM7f!lXtePyBHpc28lx+CEjb%tx)8d$$W9( z?o`DEelgsjvn;1L&KZM6jdPBw3D3iD0x0+0mYsjIPiTWvEsLpxg@*#n%|O$b;&+lRoVk3>cO`KYPq3`VaCj4xIBOJ zo|H9$A9W}%=H@hNfxjShe+|gugFmk)adqP5_$NW_<(@5}t1hBr1u#bk%uD%d8yETo znen7=WovW{0v>*k2mOBsn2>$^eS>IbE1pm+d-snL%RL1;I~U~lmr8mo43NNvF--#A<|EOWH!V)-;U01$>1potT_ud=X3 zn>>`pZ&5Hnn9T1(#z9&JgB|k+%Ehq-G%JW2md#~K_@g0W*ArAr7!@|d6i#7uhXy&n z1{NC85XHxq+#wtULp(|s6O2Utw>D0e22u@Gj^kYB()vK3w2Sg~TvFkQnV_~a=5$Z0 zj{ObkVLQenSYVPQ?k*FoZ~wr{8E+&ir4dSZUR}T zmLI>jLo%SY9bFQWFkadkZ0m7A{?yOE9d7O+;2?mENUIvF{wVx|Kr4^yz9(@Lc)nS^ zpgtpi9)5yX1dbeiY$22-JN4;|fEXop%!Sk#bV@B!NISGK4SJ6=cZmDRNz64m>?xQ- z;eAc6XxWM&U9IswC<3T9aKe2V&i%)-Mcdv)LCh4~G`mlwl?6=QRRH zHi85X$I|cwVJ@T#)DpbV={b%kwc5a8;8a62b}%D}BGC~gvZ>zwsJ;F#iH%(g{i_-I z9XM(@41CLgl-1;8^Gx5@UiG|3n35Rqt0ioIWH-N7PD&ycZ=40OFrsOld;E!)0!pGf zkhUF8R{p%yxTUv1?ez_YoPlYmSRGaNyrKGroY<=Fuu2ek(snn!`a27nQc@hIC6J01 z0ZNqrQqju~wVyhiBGmu#>J)GwgO1rg_*FKYrH{!*TMriuEChWznS5vsm{23jt4UV* zaZ|HS-P{#+Gc5qrDvrc1vky{cjnI3MWaU%unHip-U#%Z84NRFI{<D07&y3Vq9IDWV`^w9Y=33bJfAgjwpNc7%0wJ7~gFNB*X;&QkU^b2fKkGO{>0 z*OiyedbY5Rh`4`}F)DtEUqSB2vATh*V@gHBSZwCYCzZVU;mpT7a38)QK^H8J?hnXi z#-Rp9Cj-Z@?u1dbVK1emB+`1}#zCNrL^0Zs_~D_=i%J---8flSG=t)YgeA+~1ZPL< z!DcGap&6BJkDY#npJ9KlV0*BAA%O{#1O!?wWZ>51uR8L>aRP&%@marM)}YVes9Qi| zW_gJv)&I1#X-Q5P3*SkbTJOn+SCG>WWN7QAjxA{Gs%6#edd@J!uz@?_6OvR@Ft<+t z##?%ovUO_o8vZeZk}45+Im7|G2(Ew}PwC1g_VAtH^IXF)d$F?P_QOQHwUCSN|?DGsb$*=Fd39pfrmY=9o zsftN31ZGrT@9Lxvlfu!j&tsVxQjkm}hGbv+Tiet=4+2|}KH94t)j`)X+v>hc3U81A zc~B+Y#Ve-)OoliL?*WiWzsx}G=L<2Z4uPVm`S+h`)&m{)dV#$4N>={5BUgH#goEvM z?>=OXx>t5+UGhZ0G4>cQ5NrI4I> z3sgU{G^rghM+UhB#-kk6OUv(S7znZfkA)e6sX{E~id|MX`?ps3bJsZ!OXjJUil|X- z$@jx=VAOzn!+0S%VTuH@O@G+U&5D0zsMaO1_kS2vdBI2V67erWV|up!x(x?Z?E zYg>Q59*|N=99B_zn!o{$Iiv zX+%%*^PZNEWuI1ASX@D6GD`4SgTjGlJ#>ztxZbNx5u~_BW z6`IA}u^+L`d7E4OV7s!Sb*-xBK?crW!WAWrBHMrlo?r<{Re)QK`#gxL149YGI@C*j zAKcF#oYM@`a9x)@55k0D)QVfG#sye1ri#Pc2l4~q3lw?%3t?4>EFk9kV|Jtfr=0P~FQyc%bEPhj@0oiq zDMrcrG7)3Dn(UfY1fApYxA8~G!yoTcb>rWE$;Ou5LZ@>i>GNVNDzu8Mfw=l(!Qo8Q*4BKLGlT)9;fD*V(_-G(=qNd3*rP8pDQc@nt zEcLf(xI7_6e_C1!c2WonbPF{gBuQfIQ(q9i^%XipNURW@y-Jrw=;Mw~oK6rGHW&?Ko;k8+1rZ+~X-}C{mKnoot0j4GV|0q!mP-CG7`(G(kx$ z7cdhav6LS#O;7^l8I=E)@}{BXSh%K58X~ztbTGXP8Nztk;78#lUyqDmOled4NkaZ` zct>b7zfO9Kz9S`69*c`&@wYvBp2S1EN~#LHEukiffrl3MdxM_gV{uc^Evjrck!Y0h ztBxq_;0Y5V1o!QawUbl=D$NovVSiuyn>omENH1ERgv`~0}JHH)aXS5taOSHd* z?Fdmci^m+AzY3Gc>q}V3cFQ2F7??OeF<~q({QuyKg{qM#VMtUDe&-D z$O1@yON#4NQk0aFT%Z3Rt`7tImz;&fC($~RaFi~(BI0^ND3Dtts=pHpemsme>97Bs zB=!~Thcq5f0!TL)+cd_eAQtV=Y%Dp|1skM>F|4bNG3dj7V)+}lE5KLglzbRN2i@(e z-zD$kWr!R;oPq6Bt~8pMvBl_eT->P*C0$bdb<(0AwgE;$w&+SEvBj|BvMM~(Ta8M; zZo8JGbySmK_o-<2leY69Bu2S{0#kr zf3Kp6?uX?UOozt$&Rc@x&}X&`C4KoryTSGi>C=0GyC-In=&c$sDpG*P4R;1OKpgO% zwLIU=C3{~P$018!@=z?bH;AW&N`f}~tqwP5TxU;STtLv0t=J3g)m{cL`Yd0vQI{)% zUcd$}_zMdWa*wTqr}xooqL1FTW@4Mn6~kQ*rVFmhc9rRf&P}K~gJ%SfA3rNtY@;5Y>SDbX>79k!gqmpinV_N#}rK8$L z$kfw5@r7)Z%VkWuTRde2VGlb&$Uu~j3E33tu#VOviH!glF#ya(h?jGqm`I6Tat=c6 zG6nu?#PwPYx&0o*2Jf;W zhY{WQ3{&ux0cpL{?_6qV9!yx-IvxmeWW+q{;mG=>Xn60BQiUzmmD%e;i$ge0OPFzp zxD%ZX+=@=E68QX^I5`ZM8mcXs4DlwpuM#Cb!zVfXe_(Po+#TRWuarm=5yaMhc@{(b zuJ@*Av`&gY2`i`JM;H0X;In0PwdF__D!+9@B-u%F1MgNLoOes0#g7Xd;4kAo;&+26 zm*&Mp(vGQ&r42DJ6S@AsSb%6WsO`a9pk;iSQP{*+T*3&lA=PM$Kdw7nf^nZ|5NI$s z$XGZioM_Gs81(oE7#zok00?PJpC77qS6Qfm z)0r;618$ha)!ZXaWH3C}S{68tt{AAL#RBlE;m;|Z=N!5faG59?&J=#3@zV}+Mpb+o zCd)A)wVG+qZR))ozFAQ3GmHv}B(6llMgNVXMf0!mIwr#*+VH-x%o7~!7iMV`4(e4M za2$q!Sav$atw0QJy*}CG6C6>0Yz*~A$h2?@g(Tu-UThL_LDKE96o^3dDlbZW5Al*^ zk@3iJuYSFO z%l^mWO|}cq%I0-Q65O@NbS92AsFmmY?=udkkAqJ^?r%2)ie=@F9c+q-axUQ@x4EO6t?gt`ayJSRX;s zEkUZHWC(nSfUUz(Lk%ezRxW22ZS~lvlOyiReg6lSTA+xPjiyfnmHq_BTgF2=CMS2l zV_K6BxJXrahKJEn3~*c4qlV?{3As%17J3bMsMo7AZqBX>*5}y}c`TJoe^K1`S{($O zE`v;hzKpfp>qRAxWL9@mp$Yhl>qHWZIw~L_@^JZ!0zbftbg%QYXvBR! zx>heR5@^ydga-4KNoT=$9jM`fuefb!qWsHTgFLM{8Mr35HI2phHnaUyaCZI8BrzZ?8`j8{; z+@3lQe%%&Z9&JP?8tMq=UC0%Vz4JGB+_t$ksOL=46ATSJrQRC)0r&ep>EyNf`7Q1*wu`(rGaQ%0QoDXmzT%8v3k+W%T#pNCZ+wx68OTdrki2U$LiGsP$m zL_F4lpvO^K_;#u|GY59;aCSXStsy&~arawa&iqM|T1^!9$C$1?Y0`XG@A<9yw#HQ7 z(ozN6#2eLo&fQeX@GA|VH%h^?7ks|*LhXD%9YBn~ev!<+4SRuG$Ok$uICd|{zPdRi z9TUaCV6>vz>zRw7X(_hsWC+Ca8Et?bsjUZgdBw~d`jG#@^t0`0%yz?Kq_~z{Z1)O0 zB(mn%yom86dUTzNZ9giF<3-N66?W&sSX|0*7u0&Zht@xwL9UVDi@DFOmVit8p^6a6 z*pulOaMOH~txd#cUz4ijz9hY*h0`bzh#oCQcq1-XdjJ|v}BZq6M4gKXkIprbo6dqaC{ zs=AO2lg0!#QaJ#aIPcXnhg+3LXhr76#aP=^&c)JfTfe^wR>k&}Z2tTzstp*Ey91Bn zzK`2)xi^fl9o7`}wl3JI?b!=O00>Pp6d<)lfig?0^A)@7Pby9N#B;vX4wcs#A&Ycd zh3APXKUB0EuEDLAZk(>JPdCvv%%;AMSCr%dPFnV|>|}Y@w`TcFHHLqs4}kUbTA%E` zvY-6cG@s8e2&<-S&Dp_K&Qwic{KCg9Ot?nZ!sPk%QUy;EEt7V_*|bQgI6nX>XTW(n zBVuhxtTp{*GFW_F@bAwifi+HZEDxrg^sTv67I{A88>1R%n@K7)DGsWtMG74pM~`ot zY;1~CggTao^JP$|!IzhA7#)KikUIhD&F;V;;?}z>8#feKWBTRo$>4X$Q~=1NCl?hR z^Ck631_2@K-@v#<2kI`_Rxp#TmJ%sqy^N7_J*KQCB;?%on!5T}tKr)IlnSj-637D* z%h{h_Fb@~RWX{H8nCZOV{GRx=ucM!c^SI_yYZAdqYK6l$FH0oDUxcoY8n)w0Doe+* z;^$axV4a0OA_K(Gqc%V26{$#3?EN`CD1%Y0*51JF+e>M`wFB`1#RZTI5;J2`lHu(G zS9KkFz!N5-PA;SkeN~qdgevetdN5(Z%o^|(d-Xz2)LN%q4hL&`$QOxYOHdrb(%BVG zGRp(Pqu%L}KeO$L6#uM}_1nakx}!%x5Ki$jHxON_FtO6%B}#0LSHx)*%WA-Cs&;R4iS#c2{QeeL%sB_&DXnOZ+P^ zd|CeuA1NC30k%MxGd&szFHTp5h&c_lZ@o>Z*XMk1mL{CB8gb8Tju;sZ%748*IEod% z)`WrJ#F~YwfF4m_^zb*_(8i;oE;f-)wdZ6i#DOuXKld&Mz_C3~HlPoJZ(dA=YPyi! zQ4&sA;O9?VCV@gbF}vOZIuD3Ja>9|k%)D1>oG?TX-X>Kb?vS`3*`V?X;2&&!aXVv~ z?K4ve_UH^FA}3st3NBABBO|<^hoSLLpbp8+m!odWZlGgbfe98tzu*1+);Ff-uxl@y zz_pb#4QBxuVumxGZM6qU_AK<@+9uHdX)Bl+Z0w; z7p>RMV#!D=SblRPUlpu|bOEudIjJa+2B&YJ4}mRi}Ek>yZpDdKWzJ$8K9ABy(V0gw#}Q*`k@p z<6wlSE!khdgN+6;SHOa^6uV*j=W_r7trUbFSbycwTBKkR`7G;4rh;V1n%64;@k)!~OM8UeSsCvW%z z@dGLz=rF_xsy-#OBK8Jejl91%Uu-iV8fVHb`@lX(srJ2;7a44YE$NRy$NQyo9Uuq2 zLMdc=-m(Ab*3yj~@j}fXK>7(hSMTVs$B=FHy`^4cf}wDiXq9FuWsA;Ab3m3s_DBKt z1(^eJO;^C;@RY1!drvR#Sv-dfZ$LF`6#;UfAsir#*CWujxyd*UchqY@4D1(Y^n!(? zj1S27QxYgx-%kpc3@s*PH}99)Sc$>*Ri7ZOn688_mHR%xmF9@(fO#PGXS{xK_tcSc zD!0D9#dDWA)uMj`S8(R`d2)x~9h-^ ziDSL~+Tg~dpdMZDmplX|IGdE&0J4|wu$e{-$Em!yQ6B6ura_O#L2$Fee>G_!VnEU+ zZp>pQz)=-M6=#Kfd_!>9#(od*8kW_6RF!?ceejcfR!}BqfEO6x!h*o8QIu%||As0Pb;$;j z)M93H+#FO^qOs27iLFl?Q6<0Ss+t*_IVJ`Z#z?w?Jli8q>3vPOn@rP`{FWE9Blz`b zLdBo|3#VuQKjHKrPh*AnVTUSv17kSOHutNaOe5&GV|o0dGy%R_@3C1S=IbWVn(lBo z59@Fyx9~Tc71XKpOtw|e*-%m&t>lr`B{?K-{T;F<)*4=ES0Bx<@H6_k z`FtK_YTFNh>x0tA0WiQGm@B<{4}?jRDR+kBc|Mz!)w}cl0Z2H=B zzX2r=Ku&t36#99nR_F6?xXOI*0;((WUe;e?WcW5CZaAb#D8{BNUEgi7M0@G8TjC0 zeZ{@WkNx~C*5R}QmOjjRwZ_^#*K}&989zKuOO;I6IG?B*t+yTW81*MsX>6Q?kEi_n zxLAVbNuRk=tTuU@;9>~-&`N)qB{z_|#yt9T*^@E&01i`wFo=Sc=uN=SgC|dhE9jTMYdvw~Vy}l&L2>r4b3&vMo>3?cZ=OzLBKd zZ@H2zYyo7n7dFDn*9S8B3`#^#9hqsbqHo#NHx6c8^J$>tVkb%TNaeH1H-5!`xO|P+L+ne$+ct>d$0H8 zzR%D2QeUpUX8z=xd7kJjw(q?8!al*a!aAg`_G?g8%k5B)(?Ig>%D}deeEQmYh^QD? zE#X;@!|vRLQm$5U>}AEpeSQaMzF zv+LA}W1elX(M5T@CKRp7()aAltT3pijJe46l9u&Y3=qkPOq_VJy9!4&FNlJ3~zYw)MNNN7oLKt2OJgeXTZc`cEyhSKxTC({+K$ zmDqW*zM|4rQuvPxlOV}kuV0@7)O{0`S8sAKozDQ#q~i1I|IXn=Ii6SMz+j zt~KRng9%}V_XXPJg)*usK8fypc`NE9jI04eZ2z}bsQp_j>R1vk_YgTp-I1z7OJvEe zXcUc?9o&?sQ#dTR3NYzR0vQMl~Al2((X8uzxrC%2W6b zN&RNuxxTiO(P<+*|L1#xbirfmycopWXpwVyE9bBMEjS{=A>_dI1^Vet^8c8O;sXz) zX`Dpqc%|OMPwQ9;rRy@?DwYIq`tc7c=2L#|@!1GG7hM<|sOUk(>Ib5E+aiz7%PT@} zy}jd*oUTbRt-8^$A=}7kYIbs5noXO;>33>R-RPHWzfZeek9eloaSe~QIi23m`m7$} z82v0N6-|kqqh=)FtXJ6EcCT-=xZ6o}T2FrVrN2|PU%8mF2i`XNH75(*512Ivx_r6i@qU8M9jYo;zGSW1#b$05C zTA)UPWHSG3F$Uw@&nv>V{IsV06xZYy7I@S}GaG4q(|O{sau;K_(h|SlZ4iWFEn+^U zD6cJesMw>D!2QohnP(}0|I^L_L&Yu7>~(Hw;$IO=GhN7rx--WT8!oA`E6xaaR- zH=gRxJe;?g6MHV!8qBs7c%-MX$J1^uzS(l}`99Ukr(3kF#e>SiU)bYau}Zns)QLxT zX#dNWcs~%ni9bdWGt#x5rr|e~YQ^(WYxbk9;n0Wv%wf)A`u^r-c{l-*qdPU@6suXJ zFFogHSLeKc?+up7wNcokJPOsE^h}??e{LfJ@&BccrI@WX|K8dluM=W8m93^_4`}*$ z->k8)wr+lPnvl;|%$H#fjYv3`XKTqAv+L#&;0yZQev=ib*@Vx&G8s``UCE72$nl|zqrvojQv{%u<|UrQ5!ZGO zH1;AdKbW82+SFrrr*n!vi}cNU`uM2>bO$tcGqpDm>jPC`GyLR7udrwBSI*l~;>j2fUtO89WT;$<&*|bs{RmC-YAtIv(`Z%#pbG&& zUM7A1+np}`A9kmrCyWXpoD@2@&%#_+w-cUN-)`-Xm^s)EE`*Hgdb?ZiOX4FN&YY&# z2|X_CWw*ZXme=Y<<_ra_`rWcF8+k~?I80~)QLbQn{>%?m5F^vMJZrFJ>*!|u?z;5X zo$I$9p97Pl%{uNF_Bnp5Bw@dKJC38H%j@OUugszK&$LR#8nZ}HHRh<+#|n9yw*55XG?Oss858Geo(9ov(b!ZE@`@w!Yc!*woENLCaIMQP1;dWoZ-JeUUyZ zBA#bElf})g-te1!Yi1Bb{7JFx5lz?Ey*Zg{m*}JtuSK_J%;+TaSYcNYwZPrZ8!8it zh&Q)yQiQxTcz5@5^kjxiYkEb4~1YEM86;X$gw3H2f2pj}uuTPr7Ta+VS@E%y6jptuq8B|J0Y)2+EB zy+x{D#$mDZ%Viep*;`kEoI{V{qd&6-F(Q!@vZ9lNUw+TLFb!1vGW0CKN3CKpbT!ZG z_{wQKZhSWCNT?I5U&C#V1${1^Epg75hd=1H)6J;A+LC5F7!7H;*p!{8IHK`3o|x>< z{PB_d<=Z~fTAuObS`i3yhL0h;&-bZ4uX;Y(yvbK#G72v>0;?ZY-B*zn&w9qB8mYK$ zT8Ly*LA~fSnO*6&r8xvm_a`U=OGUFb##qWY0!|=3bpn2WGF1MW&PLphTlk zi5@K0*?4d{2*PpTEbJ&Hr&?$6Z(!*~rWR%UjNMd`NJLg@6RLT*0_pbdKoQl;VAdGvV{4O!E;Mx2+ zQ|8jW`)BHw&wlO>#=365hHTMiZLPy_^P*e?&NWTSxg)puW()5x`s{0q^f&~kGo{;a zU)M}c*&TYRk9?FKV6D%!!>e^{o}Z8(&h@zcBzJXlTRVH}YyDxn*-7_!%wCqQ*^~CpoItToBrs><$w=8%Ub!$!1?SoMavQlE2>|zxF$eb@obR z{U()^9j4b{^G5jIVq74&hHPNpdj1+*Yl7zT>vGSgzQ9KH+;WVqTHw&Qb|MQFg!+ z&^6&GUD5Y`>u=F+LB@#y%V_83MwMHoLV8bg_N2`f2|HZyPWLL^R=Xr)+vb4sUi2#L z0^nN}XtQ!`soheZp5y}i)EAB^xUO!blxuvxSk|7!-g2^Y;#h$t^AhJ>bNz~tiBHUt z!&nlp^|YGnlpT@I>HS^l`FEP^OXsiCJ8iY^ky1RfXVr4@$d6_J35fvWAPEnddz_sF z##DJtyA&pW6xiO;GLe&w+smSOq#ot}!`@#;MHTho|FFU!LkKf8A}~Xjq)PW74T4BW zH!9NIF~A^5iy);qfG8k{BHb+=f^*R_KyMp(*IHt z0CeOU!9rFBsuvLb=aoq<8)*O%6BUrkSGD0QV+UbBUcNr}qW5*@5yUIL<9g!;Wn%$t zk3Wy*#1s}7wC#?EoH%6Y2(td?j0OJ`zx?lN0?zn9FFF(dQ!^X}USzYBwrc$HS5LC~ zQ+w$4--m3Y%=HO)fKnqw-@xs8rSjLvgswZ{lZOwq5)9792LJnggt*tM(ml(NmnOHJYb5b<)-}rM2~`!!B^9ARII;~@3~g( zzvVME0VJHqT=L(HDh4v1m+rLEz5Bud;y~N+AT+`+{}jZl%Xt)ag&i8w-40g!PjO*L zJ&EN%n#}+G6+~J|1^Oj&*Kh;xm7I4Lt%as_wML-b9uPjx@72HsuUnwkLA!s6FX+to z{_C?=m}AlMTF|!V?sLGXQ%SekoTzZ=elXHr+AGBkIvDb+K?kGD{2O7hoy5-XPP1}~ z{9kno-*>)vVnXe;zd30LQ|%i39~XeZXZfSH`8EI(bY6#p+Gcv&bdJ+}YveVqY{#QE zLV%8OnN%s^VbZgmHpU$5-^t$r_n`e6rf|&{IbgOpr~#0MoZYh$%eGF(x(l|YjH9~J z=7B$>6uMyE)F}Za`Cr9SW@6`C?!4l~tEcV&7oY-+Zq}gFTV3@cr!dL6)Aw+HQ1jjY zFbhA-wZ_WWeCnXn%9F$$3|@;?|3;s0y*=?xa79J!3Y`lbBl&I6SVkvON-@Dw$WL}n6jVm&LL z@q+9azzy276{7C;cP-*DU<5Hv*-OS@2cR+f|F-T6Zfr)=3f(OkbNPMm_kKlw0FB&D z)9S6-GovJd427(x+I4~87g_=Nlubo0+HJ2}SQW_PuhojNgUKC#x*^RVoO`pCGvqQm zinsIG&9`>bK&E+}1YTC+00(+d{n_=bo?0n${1}-4U>04G;WNZ67M}n(VHfoOR{j;q zM#f6)VyZ#o@BmhsykfhN$Qn!omr3`L4pQlJ1UT8E>lAGlP{ZlGh7{bsbKfbZ@!&c_ z?kl%``BfOTNgOaK4!{Q)Bz@XJ^EO-H)y1!uq=DlA1c0?{i*f1X%u{-tRDHVo)#d8q zsH#jB$_~&D5ez<`jRG$YzJq3Y3h%ptX~K?~JjRteph=k5bHX{o543S#qX#;{IP$(T za*0d_0D|3r?@TN0i18BSencDsb5HNZCcwPJTu8VrKmP07MsK~p-0uQv`r;BWccaka z=YzR#m;+_|lkDrfH-U`LE$Msc=8qQ$?Eq7M~*v`q)szS%Aqw=&NSrW(>;kS zJMyc~L}&c+YF8JH?$?GR;yd>_4uww*sytprh~vQh%6qOvS1V+z?S3O8?lN7=l-cf3 z!)Bh|^10XCM*FwccVf+(!bKSy^qQEsyDrHELVj$4n`dc&QT&53b+i)zeK-YZ z?5t^G86}9Mo4*x%?k#p(#uKkHk3n0Z`({_7#I$KOfE^4PIkH5YHPd_!R{x#Wqi+Nr z5nVi~vz40#sDLCu$7y^+etyu-9P9Q@adtL}tjK#N7=IyJsK+V$VP`Mks%$p@Io_G4 z&or*`a4$WWXj-@tpnL`JDSj2lb5Yg+WpZy|@$-(Fskf9Rm3g->T8h!NOJFm=k0A}f z7ykV9n<#hw7@tsFqLrgUnF?Z#>8PVq$u&e|0Yily4Dp*Lk@Xtf6?PT5topx3Iu#l(vd|S}*^@-|VnM{W> zs`nhh5MGn&Q3X{Fl-h9{;8-dIpOZZ>3nyu;S4>vIVf54fj41L80+C_1iYmwDdsh_b z8}7`42#o;qGHSVK85xdkAr>N>QxGg%<&!e}FCeqwltNk?aNp3Lt3%2$l85@Dr^}y= z3GYDoQXb)U1pNT)4(B4qAq6og3&l-WaQz54Ut;-X85$sSR{%XD9)drcEwj3Bi@EVi z=0gS`!{B(&+paQg+(zC~4mL~9orcM^^B%~)M-)nsX18?lUbRR8+DT;-oJkneg!(R# zW-u-opM5z0+H_srSHm!D+1qK&6#j;IjiQKh=F$4d!yti>w+Hg4LWd+xZx8WyvIF>U zF}4#d5SpI>^hqn`?pzFpur9CghjlXsu8_?w!H9D`C&VO*A6$kwYG#Q2#7w>%{z55) zcVz7G*E$9}_i`UDDC)Is#;!xY(x#%{ek`4) zo0V(4OHbl7AhaVfAa8iqr|GsZMP$fHHe|X{>IePq>)Y@MfQ*W64wV|1zD6+d*6eEw zJ1n!Kr8|4`ufTIBF@iB*bn-XLO{wOECIj1yf2S&yZ1Y5Q#JMjAdWv_d0f0yJ{0fkT zmZGo?vrnqIz3R4kWrt?>P!P_B4)XJR_VzQMMng-W4AoD(-faubGq2Z#DzVSCh|99e z+nr7MZqct~?Hfj&lFt!F*HZ=F-g|kDb`zNT`1>87=f%Q>qT8Lj@b?%G{{F1gZNQ)P zv6}}hi^c85t(Kar&c(I#^Cw^l4gNcsxX9}4zG+nXV)%u($FWnz4}-yp=WYr2HjMI~ zC3q%X?)n|P8(>a6y)*E9T8@mh>yPZMU=MjncmMRH9z-W7v?%^NdvM|Vyl}-tB;0mSm{b} zs36>61Au~8;d>G%B-F`MWr}e95p3Is4@E$NpacrGPoInT(__elCK}wRuWZ}ztZCfu z=3cjjQZ^UfzpybTd4%)~Z2lx7&7O^yNr4vbmti8sxU=2bCTb-vYYGoQCcqzNJ{QhLE90HV`aTyA zkn%mW7q0kV0dbkC^*=j65o~=eE(xxGltMoI$>cPm{-1v^4UzBGjPwiAv0ibU20sA* zQaEKV`;(mwk!_Sjd3-v5zf4*-IHcT6nMjI}I_>g(T~fsP{=6Wb?3`E@_wWZbag^^> z&LwyH`#aaLzP9wDoB}01jZmvMeEN{i7k);QOR~aWQ&;3(kTA(VNru5;+EOuo`#MQ7 zh|sV)B*i{+C;okszzrnpi@9&5 z+qNkuqwU5V%!_NBk#pN-+mQbx z7vMuzN3_O>C1#SjuN3L8FMd(EF9xj5T01D^A=d^<`20L21*_~;i2k6XAAW*LFjT(& z+<3AWF0=!4SMS#Tj!*l?EpH|q%9RV#=E^>hvibh$oOzV=AU^yy9Tj}+$4Hxi7vp8f zR@{3Ed(}QuO1cZlhp2K{?9YwLDTrLm=m9cI0qp)Ld^kD@2?f2k96kj}ij@dh5_CvyY~f^nAD+7wOUowU-$Y(OLR14UPuKXUpU<4Y?q@&1 zdL!kIYjUx1CgG#OJa`?|niPK8^NI+S0Y`fj-GeWo#V6oB#j5V&(6yf^Q1__(%(0u?n?#OL^It8*`jCSLcwWARt;a+UQ+$bx@5a8tCdX-GY?S5qCfLqDzhYc z?AA6>U7~R3(+`-j=_m1I{v$J*)t=XP6+P-wbF9FF3o@3A2i?2{ah$-0BtU4HS$|L8j;ICw^^^A$6?K(QZ!1Sc58i6WCwgNbE&KX0 z|FHZH(gpTM`p+jb)qz(qb}V&#j~up(niZo7eVFfmPXAqb(g=TQB5E>aC+z-?1b?g# zZ+QaSzxj_|C1p24)T>4x2e}Jiu`(k0X)WWh04h3WpB-V-q|bd%Le#k!HdyG1#ZNts zrkzw$3~W(>KVng&`OMb?zx|2$2W>nmDP%~%USZ(|&-{t1U^e;^mSNUv+D6*1p?$JV zZnFYEH}~T2(Qy(Y_<+MOOZRUHL)Vau2Yj>m}_4E$8E*HD^l z>4JL%zE?ZER(|B&oZXv#D^_@HDg%)YF+;|>SZ>9cVw*cS3NWRXWBngik#9L87d+u)gZcStA~eO!=3z>0 z&It2&w~yC1q^qLcs5k&yAYfu`rPfbd)hsZi$C=4OF~6{f9_+?4d3q(4~|CD zp*Tb%4iBqf2w;(AfU2ODo`(ui=!z^ z!_Rwh@Zvm^1D43#P||SxhniAh>bxaBjKOx_+-3=#mXWUYUidsg8 ze8$DUR5e{D4;vD2Y9-aL`gGYe4PT#-$Fi@p-38g3=z|`-&?2M zZFx6`>8r{kXrDrn3pZVw74g3}clqhhnqcm-x1aS|CBt_e zSFEGoPYwCJOLT!6>eGD19FM4*&Y_iLT@e=1(jJyZ-R5-PImK=)h@m;OZcFw;y1+8A z5!v{F!NyD@t^O}HJxnbiRvJn8iSQ7gx!KYw?^m%ecuByCG&{LmjE&^K;^;ZVl4;*p zC@No5J@s6dhmg|U@)t3X$UaZUP!aV-N(C8gi;mtIM^f@uonLfDGrP~BS*hBSVP0-JmDT@>a^%qM8kJiK z?+HGAB3tS5A?*)J{sRh%ec_kxZeZv=Uvrc*V3XFt_V4#Mc8%{^NlDP+diD2pJq6;Z z5Q+r1ESHSe9)|QS%rb<;Q9aBQH&LyQoLv0S;l(! z!|$4fTx;+Ha-mGQ!qxC;gGwH;1~>Ct4>(sA^j_H3{^`C*D&6kA@$Id&yT>>=dtr|Q z%f_ZJ2e-#G*Hd<82b<*BC$q}`W*Ldh3m2qtu-XD^1-5+)KC$}3^3M<}k5;52CEt}W z;YA+Yei-BW_x0bu9ss5M{GH&dw~+~gVdD(RmQdIW$G`cdYT%iy{mbt}nj3w<8o*h% z)B1gXuXkZA;`Co32j>GP-QfS0N~f+h&n})nQiC!Cxv-X_Jos2h#hP1}MLr#NurmIgw9u~9zhvy4S%zVIB@_po?^&dfUR_j|oB|po+Q?_^5UH<&jYk%Ix zKpqth`3Nl5A9~CuAO0V;(FuILfFg{XbrBLSa|%xpa?D(RR`_fo6g&>6ZyiGZD{=lu zV?7+p?RsXDjqUnShEEHQ)P?{5YOpY%S*953W1Ibe{|5)cqn&{FsF>}4r$v12tqzs) zWw4J=ST70tiFE=tG41lQUzyiQSm08Pz9-we36Dxjp$2I2>-rfFf5?M||FVHCq54>m zlxN!;dQUq+vaC3nf)^Z|aOCih>wooe@QtlaT{uS`wV}rwy?co|ev5*26@aFXe1T6ah{qE>%1^EB#vHx@W@(Awh z0tlr|@uUC!Zs^UZBrE8#y-$GxsNdiDlPq^FRa+!q0X#G?;<#&zW32@B|UxbzA{`b%)Uh0$9`kF#|K$N~I}wO&28UxWza>btZe9c2$y@=yeGxZYhU!|xt_5i$ z+p;G|(}DlyqWF>tDY@D~^2j}UagQV*e`&4`<&*0rr2`>F(58##I_!sIr+lMq{2C4K z(kpq?-hj`@1IVe``87e6fOsrd@h{mh9aaJ4#%rNil@5N8^$RGU6ypI<@$!wjt4m&$ zq#kgssVkPVqpW~zd~cTqO5cbD+gN8tM)$z#v?;Io+t+B^A0Xf>G68^h`y;cwvL9s7 z*iCY&+#?iyL?~FO7(sPS9@>uoxSpKo}$wFd$cHfbr{X#7G{Z&}-`*ptR-W$+d z>do3>6Uy{nOpQL%RX%%Pcm$yMy1$dmt3dUTxS>pu76%S)*GP}slw|Z`ZgD_YYva8Z zKdsL;e!XLkmC#md3t^D}O2M_T`I{1qAgT?3Us)Y%4wBb_sHqX8_Wr(dYYaU%hRmk# zni~7-_I20ay)=i)=kbpUp8ZrY@tVa8)_(=A%)lo_QqlF|rUfwU9u}c>0!>jOV%IFy z83J-vY&tU2>+oX)0~Z*88t^HSHFvMpXj%u4WP?$m9uavEA;5jjbR}kx&<7FP;wQ)R zv3PTnx$1PHTh)6;Izda5fJL|4ugEBxZ2)=!^!WNecuxE46;-Z&q2a_z^VJ?_r~7VJ zgox0HxqXg8z=N{`p>;roQUG(3ddx(7ati$a=mF|WeWnkft2(ojFnZ106kP@3V894o zq;Yz!h_;=o+@A*meR8gPTIEv2!CKBclLP?xW$_3+SRFR5%JP~ch!DQ`R}pZnS4OF6 z9gCNa&iFOpQMUt-@<#SU|I>Zvi>Ot_K19b@)>+`$hA?%;HBLCaaQv6!mc2UUP1%g< z=sS*>!{DryEkIM}Q-6Qo`C-dugB;@u(MXn4Bf&tCu{fZezghsgZX%!)iwAnGm$Xex z7gcSF{RO|la^nO{W+NSVR*P;e$H%OTvm?*BbPt$<{Np`|G2g?#w!h!%nQ;F5{m!#i zwmG6q8$U&;taxpEwkf0V>~LePmEM2h63~t-ub74+hw_zl0_{OyQBxOV9%gaIYYL!N zCS14gWrj`*YTS8fzuXE<@!Xs+xO3lb#$Li_-%fauGupV-?(v5&H6h3LKZkV%r19`i z)qf;A{{-mK6Ht5km+so*>@VllM(26huX-0ON0F9qf9Zj$l;PmBHWw)P!_FJL=b(%2 zEQa5l%@q_OJcMOsj#J_V@w`s~1=|vROR&GxR#R~R5ea5t6>}(z;x%EU_*V53z~3KX zdJ}||KSW9cGrK32-i4SmL|?u#na6+$!;0$G5a0Nb$q}qCn*i3c{|KyrDMk2<-=82m zvM)%dUmAK0rp?mnO>_Amq(0`*>2`C%;TPz8z%+}d6YlvLuXBIwmU#_eT3h(<4q9Jh z$gd+YnnIQb+vA!4LOY+H!Q-s~9M-yPRcg~c-r&7zm#+XEr| zv5gV7U$bh#K}gTl? zJTWT%LB_|~7ljUG0MS!!0aq5X5@9F!l~{I1AtcvPb_{U>R3MilCK?!`>-02i|9eLw zdsPxMA(|io|0LJ6ATg*~8?gkvx%xy4@S-Ud(W!;uk5_6gUC)2s#*jJ5Sjn;=J7K>* zA2OAfXQl?KzY9$XmTZiuLnN!_Rb{vP9NW(DTn)p0z<#Qc6dWMH3!6hBVJsN+ zy5r0CX}5I2-0kV&9kqS(Dkd2?awe$VcH($Nk8AzM#<6fb!xZVWA6e$dX40!xUF6OX z!%IdwfdKfzxkEz;UQ3MlStV->7|7<5&T($QSt)#8Xeo*Ye>iRp*_YwvjN_(~6C(0y zM@EQ{5k?YF*$jbKl7&$wODL5bvr;GG1RKhKwnk2c!IG)fIiTSE)a{YUW($p`Pa26O z7ve&0$UtQOBt2&K`W#!E4jz1)Vyv&@q@XmVjg?ZNhoEUXQyXY2DICEZ2`ae3><9P) zIVinx8VXjGN+ruDWCRVwFZqNPUgNo#c+k9slAWB6!a47RQwPdM6BI2(r>*|;^tvj`4vcQk`Q2$ig)rCk3&SL&S95*7?Ju=sb6(?GN>?b7&Sx%lan& z&pWnS5{fR^KqH$0hMT3cOw5KQvH0M<2E+512qBhzffPrnz*w;(GA|GZ&r;q-3?0Xl zslP++%IH95Z#0O`1mR8)b1?;nRdmrLj`v>6k60Rb3-P_?c-jD{tp zVQ_lNP*fG@2ak?y1i@ue-XKI$BRnH@g?+<*u`88V;rDd(4V*WmuJm4|WjCdn6hM67 z%qNhe7WI?;#YbN!&tinfs$)T(#a*T%jP`)3_P=Zt=t6qHg+kL92C#rn_bC>)jWo6j zrJP!fQD;jP6(E_oP69VF@ROb@{0WQAhG;dQMJ-VZE%#sFgtYN2r^pB}+puB?7kM5% zrl54~A$f#iNl{dw?J|&&RY2j%5?`HmUhPx7qpmVNBC2_LkE+k#aX8=DeQUC+NA#&g z7CJnbu9thSo9LtceoGs7D|;G8q^HO4!-==`OF8yxaU7g!AHPV-|KrS;w0~L(Yp1*! znXs=UONF=}C(vk#QMC=D{Vso3DssFaM9#`%!nv(@Kof&+70NO%LQKTeMJR-dm($k= zErjxR>eXK~U3leixA2;yiYd{g3pC&G88zjaV2|Qh5`2*h9VkyFewNhf(#|z=ZDlP% zhlz3+p?uNJg_J&8)F^mYwDzJ%SfKAEF`;yfEz3|EI7cODp7ac3_-kBLpsBq&R9&y@TVw_tal* zG36W7O~S&T8w5Y^KNulihU9%QbkTG1-L zDn8%%$ijkK?*8PS+OZCAHo8ynR8@n>o!Mg>(VE?y^-kxQMS&nwblT(&-<@OTW17$f z*ESqTg{4`h-!0b*hM|!)7M0btcEyWij(!#xPK%;UHp?E3%p!p}QfrKed(}&7)aLD5 zOQm?~YUF|u!tPi&8z-TiMAu8pZ#enb9phe2w&f1XRIsm!crM$C{2M0-CBU1z>1}0u zuUBu|Ri!v0j!w6N;K3fwa~n!=wlyyX7}t<&q-RmchqhV6<__i$Fx>#&*Gn}rVsK(u z;ljr_WliPkv9(M{BUUM0!!DgF>nKbtOQx~Ymdhl!c(1cmTDZYds z^JfI(A>~546cCu4fOi>jBgx0+Q6~L?1Jb+N2h5Rrwe!8l@yBXjnXyQJxq{}UB$i$x zWd6iXYbpMTdS-A#(G#;7SNO*_dQn;MKTrXW#%{ko`o-;Zfh$g^c=P)uYrE9i^+RlQU zm4zcJ`%zE2pHMb77o$^Wqb)h=Vc(KsPBJ`0=kpxAw z)w2MqEp5taMZ-8hH0hD=EJHg6^a?t>T_Gm)cxW+hvA*l8eURdV)WanBX}(t+o#{4z zmrL(4iWHU^G5v8l&RhIgG=!fvu?m z=z=AmM}%IM;wibM^oA*nU5?v%^hMo&^uCD?KWrMNrE?M4mfAiy7c$9N*wfAMNpxi! z+)G!zmfqFKU zCqn&^9t{o|tGnmI!E7Un->Weavzf5eXe?={qY=} zJek%8X((j_lCFEpJ{OB?nUkwwe@RXgnJ|X> zrM8;P!I>DGkV^SRrYL&>e0_16W9?rDP@~+QMWakXOv~(aUZ&3r*lkS2rx>wLAZ&?@ z1CQHRr}-u0O1Bb2$C_a(11tF1LZW5?@BxbY2LaQYgW-$(oJRaJAf*8>UL~cK1e->> z-8BPm61ck#PuISUrwCZCcM0_pU$o~$Gf0XVZCL|P+^?w`-|^kwd|5k(pkzCgY+yrc z2%?yp+ygI9@-o1FeRc}?&DzC0*6o0tyIf%RYCA(f!+(>w$V{ALpdI;=Jt`A?0-4_RM zYcFapfF#lg_8$e?8Wvhe-Zv+sCR`t=|I$5B)AKu32Ar+EtqLBeQ)xg{VB z{37Bluh%uOetRbtkI`tg^$-+>2N}RScc_dN6UP*X$F&CM0R*lHsqS>q!CRyZ_CSmZ zcx(3?AkcV7VQ2Wt$5#GLof(~hS}GJ+#UuIgtab(e4d+|Nt{QkY~{hF`JO<^*si?h(k_ zyBcMIT?yi`mxpRe^WklfCLI8_q~1ynul^DvAEnqAH{7C4lMyM#Jf5t0>u?UAjG*_> z*RKz*pT}F2bZe!xMSChg1c4o@l_zt($9*5=n|$MUW-p>Rt}TeS1zbmrJ-hdM_O>9> zd77zHi9m=b{8Po8TN6?Z_mAIvNSN-AfZ9MsURSjNPB6-G82744jw2=ifjc zXoI-ixU$wRumk;ls%LCH-}72Z0nImM$x`iXANLIWrv(uDVvNDP zbqH3DF}UJga}W*Ssc%pXjA1wp6}z3>O{)(M_CB_`qCS!qbe6pwaj2D&i_@R9e(Ddd z%WZ}TAoYz0UhXl1iQC)w`WR%%H`aKWPyt=>WL3$U8qG|vp|cHKTzG1B@1ANkH-a0Q zLf6|s!6qHyaLr^>2?mKfMBiZkbOIJASSU=W9XTHW?8&;_@4!W5!$jjvh9XYod>6!vJ?}B-x?yYP*DjiWv`;{l|dH;uVCZnnVt{Bj+TLD zO}0K~oUtj{;SY4rEZeEQo&!&>3DepK)mg_E!2UQwAM?ZS-1zwK$ONVq#~{^Q(6ytr z5K1iYaq>^0VMHuD3kG&yt}FmZ>)sNqermlSO>O2P_%oT{t&a^~6NzbEH3=9sFf8aB zjq5uzae5G33rirQ6UkZpn)E0IBDB=GJy4FzfPWkv%X5rqH#!E~4Nt$~`KPYXdsq_L zKR~4J6F%yaaVeopAi5cvgjh)Uy0@~v3UvNrVM>irrDgh!xyfK`2mw0&>^SYIm##XJ zxWlQ)OCjY&9nvA*LctN)l(q=ZRz8cIGZM%~th>l6eFmUM;tE=%v-5G9lsms{~bEf!#RR*$k7V)BCdgK#{t_j}n3H3I2PE*dnR+_Xi(YBT7u=!9Ra9I^>U2%89{7xlWAGWq` zd@`nn?}+S>H10t+CGvj!w!p=SJPFnh3lg;TqVkSOVKj^U{HV*k2|#G*(KH)D^!`f1 zb%^fjURXL*cFM8q-l8MeQF_LTc9zy>t9~J?8?<{@VjHtvL?a#GR~+xjW)W1jLOmZk z^5$gCJio$7k;eMVN#k8y+}0p(LaKdEDm}9f3G5(SMa{TguJzKr8;bc(MBR zo5=x*=7{N3mV`8qRZd#l@WmsQBpvDs!b;6-Y{;!A#+-(bT{vr;snlFSD>F_Hc!X~w zL%fOwZ#9HJeg&#*!RtGLx(p}vWIio~d=@wZa`Z40DH#T`#hvyzGpOK*?36_0-NyP} z1iSNH={fuaA5gb~XxDQ|F*-?|dr>0_;sP$a3HcdcVeIbK;;jVNZ###j_u&^cu%Y$8 z%V>j2$d1fHwT!*~EV}O=h;o!o*MiCW4XqGiUq93jYi0mgm=0yu133vvtH!l(8nUTb zECWw{jBkdTub%{@Rqw6k_xC-#W2c}kLwgQlZa#r@8Vc(k4Hm}TZSQmd!u4VYWn|l} zkgm?E@i&EDB}O0tedj~VUYL~7ue*7pLSc#+0kj(ur-GDN|H0yPL4tfAj1a0_6pFCi z0$M)B48*eaG&jwGkb4*e?Gf(1DX|Glt7TG2RirpooYJZc;D0yxM%V(U|Fyca29?~+ z-EhTVoLS3r#L!AnlL_kG5w3j)XXFy8`;Mzq7|r}!3x@gBj{AHi=#vZTS zlE_22X*8H_bH^d3JOdU+ele#ZcwWp>?V^@&_ErKqT70zQUEOxq_rKkFNU-nu%$mhp ziCla4pcl5A^z24Nq>Nh*650~dmjyY#n&128_A-~=+X_AjJZatTvVGrX_9TNzOPhX( zYn>r7fspR8dmazGT`}nxzn7f;BuHif!4GqRGT?*`+XXB#PUa8U#C#gxxH`)4{(VG zW>qG6RhFN8pOKVNs@j0<=#0qj5@eWHOEPj!inL|3Tzcm2*rp@A{d}4>U_)AYG_Y^_z zg;`7THYZdPC7H$%ybTk)p%tVg*9FzHu;ta&Kk1v#jwN`+<1iOX%Kh=jnt14}0^-&k zM|^H9Ol((4zng`EIU^53)*0aj_AMmlu!4bv4_RtKOY<7X5x#Qu8O0A)**594<@F!s zX=LC~{U8zz+HSE*qqHk}qgQD#do9cH_H`bFFDgof zzl%j>qBaHAHh0Il{+wBY;2Zm1@KWNDLbWo^7CDvZgyAFlP0rcBK-YrhdUe7wYnybd z_2Z&AW{q3D1i!(Ft0TO!g1svP_KXlk^YmBC)bpz4+{oyK+VW-3UW&T;8kqFfjyUVv z<)g_imkQoYzM(MK;w0f8uej}`AcN}1q54d*B*->#Iy%n3Q;F40{!{bA$|I)L6D1rS z_hY~A-Ch8<_$rg0?2&SkPM_HqZtEx+scf{y?#)LWGBX6UPP_H^vBT1hzY=B%1UiCe zyj_Hyr;JDq5S~FPE~_)2V)!HFmF(CjV-#x>V${(zuskXI(PG#wJX$2`*2kL$b4xJ2 zMxKN!M{f>NM&kq@P8yxLhQu*c8<1 zQymo6E)de>s&YPsg)z~-ed*Fiw}`1cpXz9@>bh8J7ruWxe_93KJ8xR%2ja&uIP?tMM!Vu$c;3G;ur`s*>BeXp6wHT{UH4DrQ_aYlCksKAjhi2Z#x;fp6p z$6ko!c`2c#?U(_@smRO`#R1X1C{LTa&(gr{KbqF-yQ(o_y52DU@8reGlx4N40Y7s8 z_LjPo_+RCuq9b_4VNKc(2!dCc;=Xar$~Q$2&dyX&)lwEaTCaRmD8S0sCy288 zjUE^8!r37B-)CC(1pTaG1GC(YuqV1&YDV zj}qIcwUV?Qi`vI9p=jnS#r=}X4N+Dp({kQc0zL>TY1qDq)ejO&WVt+5vXDwxA~_V% zj!bVkt3NmM#9}#QDcU@mkMq{>53qEOV+~(%l`TwyOM9u6sOF%=#i36S$sdIm}e+@m*IRo?bZP89We7J(bAVF^|F~FYkpqMb@FGc_vzfk{_+gNlXrAraAS+n% z+b=UEL64DQb58|#6}S6jMC_s{ht&w;je6bVzN(Fs3@ou%%5x-ey9Q_rSqbqvPb1~f z-?jygj@L!B?*G*+`WX8|Z*nke@b6m!b|^3jvK7^uo~J5#(!2MQHd-Gis(zGQ%>DH)Dx+d(ZDfdI1nZwV zmV1xC^L}hSe2eo!UCK9q)kc_m>UQltVdUFUG&|c!V^xIo5Bxu1J!!=^^q0`Ck^h`% zOL{g(kMH{PtJugtA%=>ftQE=B^rMsgUvYc-*(~qk3$|YZdD<^%xaPae2k;karwPMG zE+H25<8XU+{v~ZkPUHCsWI+eNO#HnyEB=-rQ62Nzd zcU9JG-OuEsMU-bjc1ic|LG8&yH`5FGpo~w@s3s!iWvU7>t^<6an4b#$dG5=lm930` zypEO0k4l(hW&yr&Af3v6NVpdF7y7$P9LZQkadLj6W$qzmyoOkhB+P2g4hwUrbPBIO zCj*5B4?GIm`!vdL5nOl7bs6aW!=G;aB3xW`+{HleTBj$xmBU4bGyG^~s6l=`I^aS+ zp+aR6F@xV*!u&{`Lyyrvj3YlLC;YZ zTJEo*ek6o+DJgkaWbVn}QTzH=QclJ~kMo1)X%OpH5$|I*_r=$G>SMibj>t1*@fMm9 zH-EEBSwYd1guM)^bOx2unP{|?7YZi{>vB=uE`p#O-r_fPBHGcdIL>_ZfK zBl38G`+M3)l(IShz2DDRR61Qot=z(pP7NELhQEL=2zqyG8+~-gCe7EhA&|h*xBQGK zYMk`D3|Y;Yh3s*rXafA5e};2H)^^fTzmZv$BA)Z$-HK=&ogmWX@WOulJ&%1BVZOW{ zWhqu%8ppilusXdkLEDZliCSnXE}`{wqb?t>w9^xbtna zYylp(#ud*z1_Jm$9tDfmmlywZ^V3je3bP1)W?Mo3M8uEU3fp(Ri4i!R*e59YlHMigkgsAprN;Z9b z!O~dzMb*5@N`j=I(lrPqfNxMY6X%7vF4KkSKi3U95w&G=GJ%Ah?&!k`X7ci@IA(+7 z$IQ|!G>YM&T6Sxw(Ym1vJ428?B9Q@J>^P2x{(Z|y_X_S-i$&!3eOVyvcN)EHO{l0)BJ5^<8TGa403Yx-AD<4E0nR};oQ=~~Q!j*=1x=wfz? zA&?Z;$Z6tqqKXyxpBLcWVM$Bd+dU5vqOd)mQO?*)*U$8}`Yc3r68ya>duDI!X71kg zFq{vP05qcXTRyZ_Q(tN1CucFbe* zO&|dtB=hw`9TFc%&$}DGMZ@dj^UjXoH>SInEoPc)5=J+@ml&yL2s@L4?ZVFU6eBH$Z zAAKi;_+%dK5YWmseJ%P1zl8Y(;GfLN6U{E(!O-IiGfACeUqDT@lVG)Y%Ax1-UnJDR zD*;zlh*1T`Ptv#mdDTq9=)Jjgf8$=+C{x^nGWW&$2d2*#c_2_^1jOYJ5tg2bK1()q z3D1!z1ZojcE@vjgBYKi4e@k?x2!K6XAH!$1?1ATyf%q zWn`9TI%I$B_@eL{@zo@C1gN!eGI8{^O2y{>!+w$bR-B^CR9x&T)O_ z%O~CN)`$wMwh<)75m2mQ*z|-sl1BoD?>IQwPG1;8&)?KeKfu|02_K^HXY0S*SAGw3X})z8(X6F!t+?(~DT#c# zAdJ8P>5tY*PqaZ}CUQu4!bu)6TJVfKJc)AzvPF!du!xNd!JMWFeo~Aj!NGA3fd%t0 znHAsc?FQlzgKqj?!oQkjZ5|kIf7E>^7(;nn>73||IQ3?#g}BQn(BYM_pI?mufums_ z0?(`AABiCSc3Kxjh9;iEg)*6t_8ut{639tF@tE{(&Z0~WI`aI-=3#2~N83mxfeSfQ zki4KDH+40ldjACIwgu1b2k8g}KoNXhc#C+Why)l}!RXP}v^4ZShR^UhvkA2KljA5= zRDzC(`{slwG}?Z{G9uB3n)O>{DU1FPml)m+?78L7S9eAZ50!5<-7|tk(bd}R&$&E>!rK^(2s^@O+>FkQlI7`AJe;~_9an^xRVZ}MKg_WL1xL&y>B1xB80f9@6Z$lE{_nMQ*7DWto{2qcm6aW2&epe@|QYBXjXOQJf7W(8M3 zY+g{A!Se_ic{@v{bTk*+Im;dSxsoioG?+CyB#KN)ATu763I&aT)$cL8reWR|OkaW( zrsg7`|0b7LHydt&5te()u{j((6Y@%}Y#!oA&06rDxf+oSGpUnKeS-76!7?;18x{k} zUm9{iDSw}-2u>2>HSzRQ=k+Q{i1j4aqM@!fj9X6m0BouAKf>DO+L4){Qc;7@nOCRW zuCyj&jUfj{BXFaXaF}P3C5O@UBvp|`&<;pXF9h>fc}>inBq}GxmB+Ai@GkHnor=RM z_JMsJ{W9exuSvO-o)($uyB|>}U3+BIr_CZEmS05YqVN^G4nB8WDVl+#>)DIYxVIen zZG&>zSO(JCN)v79{vEfP4A;#H^A_zK2e=Ze3e-DT|2vcTi=odlQ<68wI~a83w&5(G zXh*m}{k=m)1k&DA09CKYz1h!FfR`{1nhIo^3Fbq(@^+IDHxQ+9dX0h5-j1XRq7F8V zEdJyar#y02kg^7q3l%*AwJH4gVBz+fJ5q!T(Be)tDToQq|5MmkheiE-;nFN1urx?6 zAtj)qbS{kwf|L@{NQv|!A>aawpdcY2un1q2?(Qx{KjGM7H479tri}*jhTez1|u78JF6v*Ob$CGxfxl#Sh-TQzT0B338u9S+1cYEYECwSm^-40pk6i?NP&>xpPEec8^+BswIvfAAnGv- zRB~^!GNm#I{4h8r8U#MtCWE!L!{DyPb z5xnq!Rb5bJpB#6LCux{L2Fe!#I@H@7$`52mO%XHv>k@JO7XI3-bhbli={4BLgcf zbnCEtPbbHipj&8Ryt7X217D8uS;Wl58*OEMO;9Dg z%e8zk*dW5)yu(h zc-C+h=3BlcXjVd_0WiWU(-C3C~-31ZA@fGoGj3p4x$5?mw z%eSDjdloBbhWybXL1i0^X(Nldxnu*a>`2*3 zO-c&Q6$XyEwPlW`;5~`He;Vys{AJquh@LatYaxYtng5s`C7PCnP){^O zb!PJI9LHXp-K|YZHs3gAeg81`9T&m?`p)%2H+Mi#OkVv}jUTb_vH>zcVIz@sSGtN^{y;UQMR~f5x-4Avrqya(L}cvBYz?cZD^LLU`^H zx-Hl6kl-x|)q=IW2QEDa(o(dB?jm2-jlitaALpP@v)-_L(HKT`= zjDLr$j=r^J$(eKw-Opz($Ox-mIIzce4e9=7&0xl{5k)zAe^~Cojdk7`B_VPa`I2=a z{I%BU84M}>WVeMZMvFD6Q-;;doTfiPZxKzN^{G6~o~4CGn`w_$CUNq1z;SO-Z7u!I z2M3u3|Fl6FJ68>Hwe@c=Dnv!_Kp89bCg)L|8t~hFF#(1qHux@eZOdl|#`@dI!oS)J zCCi#TC+i-|Dl41P18}1GQu3nH1pDhJSq+E6jko`f;Xx>mp$N@|N37hc=>Nek`mjTZljcKfHq;F43SKH$*?dViHAQ{F*b=Vs#%a` zrY!2~xw&aAo8FGUK5@vuN8Eb2vB&E1Iu9ZgXDI zO4Yr=lJGvhR2c%ny#k)R#`oSQW%;8j31j38DG4j7wI<*M zKA}AKJ?HV}3`3_;(Tu-C8Pl-Pe}CQwHD6Kad(LTBWS(JN#b8!3`qj_SF7=TTIJ#S_ znScNNv4nThIsP1OszVQ{-`zSDv)C2)TD@c!(5F}Zu8ti%b{zcBxid6?{PZTMQ9pYs zq}}uDkfKcb{pyVYU=%(WK`nVhTciBTDC$!6uS2v!hrACf8D=lLDTdSE-V4z^B>UG2 zAE0y5?V!v&2EanGKk>q2ILV_w(cy)t0<_)$>Z7VZ;(=;Znt8(sUtHc@Rb_+!7_Sfl zEv*2OI^zb$Hc?B_d_8pfro052EFgtJ&Hnj%;^FX6j@Pj)r4cwNR0tZ9zZ@#SCMIxU zkHjIx-$wu|#R1gttKtow@@J{?Xu1V!FpvcO0_fSy{jTgA^reEM&cJz-f4XVu>#=Sf zA<~F=m^;|;Zxb8@r0;Qvxd3+{Hho5K^1{~PQAXxmTRLfof-4jN>L|86r`H{~8(pHB zj$)jrYAZH>=9CGQ55PU0gC}V4{%zzIB_6;F)sZuc^>#+FyI|2KoyY@^0gbrlx+FoQ zieMygqB~tL>M{E_1`9Mh67@gv z0Jp>yfE&%ch70vFGCvLcNEPk65M7W=-tXzEY{ny-(ETprlI*?lJmTK7j8FG2wkt*C z5wo`apKSg(O?-Xo>A!Q~d$6~^R=My=$hpTRAvKF);{xQXMm{Uz8~YB5&2K;WJsD23 znYA`p@LQGnhxd4Ulw9fTa&O5!@u}i<@AC7$u@bSB(I+E*N%WO1@)s6@`HiX-C+W$% zN&ucLUoSAf4p2VdXD*Itm@n5>4raCG%jiBD_lZqAi5gd1v_WTvLHvgC2Ksk`>2>RG z{>>`U;szy&+D!o5jJ2q3FXVN9s`O~*J7zm9#;pPz)y~GPV;?#=B`Is%<3MJodCmoh z{r)cET=93LO7-EVu`rhgCI_j@3u5QCf~p+Vg3CIa<`P+_UEZ`YI&Jx6{kxeCsMBZH z4_y9CEgDH@KD+c0PQt7Uj=Y}r&maGFf6`MV5_os<{^x&I)!0kI3R#~UQof$C^}B2! zmpycnUL9(zoXX7`_aXMK$f4n#`269Y;8aTT>(9MSy~6K3@z61L*%R6*U{DRMt$X$| zeG_QP9dvCsO|mkWK4-3Qc66TDHsS(8cxMpxxaS6bckE03FaC;)*_=d)SuHmP~FQFoa~_H8HZ|~ zT~v*iZ4SwLSFO$ZJKD|qR27u8%$fzWf7Pmph?3|HxNxmC6}8N~=U{Sv>uqx1y34FK z+9_+=FG8re8PDhG^UibanO6})RqMH4!)09g8s(a=`hVkZ1UVL#e);&UrI1OEGmp<_ zE!^T@pS5bz=TH{vwBGplqt~!#oAX}-<}nfZi|0-Ksg6Gqo^;wiNVW}gs!wP29{)Wu zABg{E+CAWW_=W7HiSO^VET=gXL;l)A#3aA8ce!aTE4A`l&HrF^(U_^(&|5(a?QXsg}6vD;o=3HTcsVQdwDtESx0b@IuWXMd`;<-9r`_amdf zM0GaUM9sWxXxJT!g|*ukZOP_uqJ77M$%GlVd>4u*v?h1%gQ%-VLbI`?zc8JB(eNZQ2yYx`RA*&46d z#TSOnUtMAPAwfS*j_v-`eAjAeTg*UW%5ii@w27U~%Chfih>53_FHCKC&AtpC zt~ssDxEGzDer0w(lJyRoP4yZacqHGtd;uoLLVT81=BDYZGzV$+DIsK<-{p@{v5n>A zg1?oM6YtLZi{(aV8DI7e9m<52We6wmb9xWPfss>rh%p(skCSJ!^*#fb>oixa#jrN zJ_tw&eCnF)O8z4TGkSOm#zWyEO5)VS*LQ=F`MCKUtfl_(^*>d2oT@9mMJBg1A3Oc7 z7%5He2X%C%DM2^qG&4oL2dPK#LgSX>xlmzv6%mVj`KH&Z#lezuRVb#w+l<9g96j!W zepD#>E~W9QYVSF%K1`=L8D2SoRUULE>-nU2D< zBkt^sq zFX8gRpa?N_PWkg?<6IfGoZO@3i2lu~H??EHQMBb=0xr3||KZg1#AaR5=Fo2r>4rTs zSp9mO;%LaL8~(c*n7h|r1;oj^kFp-Di}oXL<#Z&N+(Bq+Z4C6)rv99L>Rh7_iCy>H zG@tY;(n_~yP_Uc!sdBDWs++S<5_SCOJmbn+w*$1eH@kIO$Xfato>r$9G9`gIxUqfC-v`;J@;0yD^It%7tswMq4a`_F29(hDI(r;$-?iczw#9>_O)NuQxO zzBYee>60cb8Qf_WK3FE>dUNo672(REeIrJ#d?-5M`AC-*9xs0hTqz@O#r9MwX-RN!^KxC;Vf_sFPP zx4#Dbjeqz0m?wGvr`o{;#tuG4t1&CRab5&f_3Y(Ic=D%m(qLMPk6vR>qcnWxEx>jlB+?ru!G=OtFCIFu@ob5v#n^2+yJXL~>Q82p%=>XsyU-~b zcs!KGv3#PLjRo-#6X!J2s08uUTz*!~pQPN=IqA%f#I?|MQk1bfaKaur?wMug6abab zf=SylALSo(UF^)e#$w|yeCx`)bi|gv7&=d_>Ugy=WqqOJd7~{oYydKi$1*&iE#Af1 z5|J5S5ro15a-vB7^5$3s`OZ6M8r=j8Fqc(xilh4tkYZbFFPJH`GcXgv-Bsx`B=jojaq z-j=15>>{9Ur4m5UqH8xtd|ERswZkJ~j0T|ee+NE0I-T~Nj+N%+--+V$v1)hs`bqVA z+oR%7df1c0J(0V}_%J7*qmL`yb8C_XgJ|GD3++|HS1Q{V>^A_nKV1~DA5p0sL9d_P zSy?sf{rXQ?S0OHbJDJxt*+Uj)nO9C2sE*t#-;~tat{3|A#t6-r4DSE$L$C`o!7Qs)n2 zSxAWiTYd>w)mZO)=9eMPqd9{zUIEfOd2{pThDC!fYR5l`G(?`uoD=&V)jBG%8d9=b z2v(Q~F8#`{=($mO*(2*b(k~z4+r0CvD~-`>w-$p@0xo-$#Gm)4EIkjZ$jQH`^QA$r z5H$~-XxzHG5C`ytWS?_2uTDI;*a9L^B0^;T&^r+NZ>p27IG)~m1DstG7l`Y@phw(b7e7(RdQcv$40*Qb1Zlv#kwOevwbUHY;+LMsNg{a5r1iPUuUK z$$hPhjX|G!CJ~vlN05?}KmGDb>JvyqGYbFDePddc3XQwSMfg@E!-?lYyrFTj*JfK3 zl;7LT?Stp$;OK$uPG+>X+m<4+foVVgK^A4hFfd%XWathoDuC@lZKI);gy8Z=O?sZe z*B9eA{7+LKp04qpdLE>_WfJw|7AN?0*TMR}xTCFLg;D1xk;>;U#CZy1_;To-YBjD- zDRyAf7{YNtU5bbXT)Q_{@_ej%N2cNf@?wut-sm3{dJ%-}B5Z zC|`Ix;s%%^2OHxyx31qQiH6*LF*PQ4fl*49@hL5+J#+JV)OAp)zTlr+AR8Xz1X(-0 z3MLjf!D28u8?J@&G2+GF&}>ADO&2y^DoWR?Q5xIC>yw7Y3JACmG#)LG)wy;<{|wu_ zHhvMlEa|P9!EKlAk$$zC@&Uup5_;VeARvuW-~r;#jTfD4*H24Rf8`m@2kE|}3u>mr zCmIU^k&=Fbu~^mx*nA0Mg{iT}E?RQ1;bbTlg@yq3S2nlKufr4O&GNziVikr0vkL`_ z5BknuP*`z9>jcW`USYYD?v&nGz8;brrrZSB)WCJ%uT|cdk&^|raz5hESQ;NSt5OyE zSmj)KKHCCR$TTbTN%5@IqAKOT`rENqjooxi;MOdKXZ~A2S5X0Hx@=6IE9{X3fq+V! z$>ms+^PdA&r}Mv~A}kWQIh<73doUZs)(QXow2#U^2VIkX5WcFY(_(418LdT~Aqw-* zY+4<+&gk@!GH(~4p8jOMS?3{LcyknpunnL2gqV(AzA@@0f z)}P5yVfjY25usrazP!4g?G7xZhl4jv&0{PpJtB8Jzr82Elcd5F!&};&NPpQ5+{;$ms#!hs%^OQAmq8{0g^Xlk6U4%Ja1qQ>wZps;% zweD(%@mPK!j~K_DEG=-*{+D5iO^A#D#{x2Oe>J`mtrG!D4M_mKm;^6C|IRx54WQS~ z45l6*gsSI)B`K+S-==wvJn;g;A5Q_vz^yTgY^68JN{!W1ueu3v3A}(X^&}8Owg42d zA9?87M#MsUxEHAZOaR&2z1CdejX1s>vbf>UtJQe$Z^!3PzS6G~U^~7A>gAJPwNf3x z!M+^u6#B5L>C%8Q)z)$51jf|w=obK_Y?Q9pI6l)W8B5Vh6eaF`lDv=)fO#^5C2Cf6i8g~XPw=yhY4oDfW)d9I7;6y$a2b`ab0~U*gs9oPR%Qv$^rQMwAjj3J}{Mb#A zK%0E@@AmBMr@Qvl>+PXH-9x%OEjKey-e(igNSi^MPd11K&Lrj{Lc5AR)7E#QULf*={-Qwx=Xn6$kHle2IzNkj-iVf_)k~AG=kDl zZTFho)jnbmKg+MK;QiUuq5=uV}Rh&ELMm`z=g00dyD2KU>}uR zy_f9d_=^;30RMsIXiWkD07F1%meuM&y4PmK=meHg1aFo*!zk4)e{u{?^Z{$<&CB^2 zAga)!CAG#4Xe*OW9dw2%+HpW7XpBMz(>$4NUoi%XIM_7J2oS`ltFWZs0`4-*7Pdt9hWFbBfOub}G}_Daj8QMv(!z?+376w+h8S)2fP8K`-_NQv7R zqJdYmCceq9i7{aTv>UHh65cTYTz6>jJ;ZW22sq!X;TJUvMn{00Q}7w!taJ2gCN0S4IPne{`VMSRr-K?V0H*FSeOf)sP<`z=VlYDhHPrphNpXZ0 zScG}yteS?eZ)#@mfx2|>cR6L^1*a(4<>{x_x5?A((Nq1Gvh1O0vS%1@0j4J3&uhTrrZE5h?V0xsVO#boV|XPouefVlA_~j*95QD%X_JYPL zaAGf@SB2JoR?d(bfI^5ODk5YH!j`0$QZc@6T9|6E|4Se&fmUf8My@?iv5&}F?(uHj z_FR1Kg;5+wxs>--N`gN?@Z_EYi6(tB%3@f%GuZVg(abW6h)0$>@BoTLkM$w`DJ(;l zSesO0u3#so{}gtrez8p&9^*IgtKw=k{8IU>r9#4;lxU;w#J?f-_(cZ6ZDPe|0E4g@ z&Wna9I~-x=iCiy%zMM0lqLFilbL+!-Z-7jeU5cw}i|s79=z+b}nBxfg7t51C+=XnL z+epp^Cxju5y5&7*JV#Ao6se6^Kd7juH~`^Ef6YC*Y+Rg_67*1PoO{Li2|w=|V@t^Z zoGfJe6Xco2-^79I>P)W>*N49Y3Tbo#CCT?)oB9^A6K4P1ndL&9o zMHVTF#$D#yCRZk|;hhSz3$lI*FC1G)00k-{YbGisH`!52a3{l3WagxQMD5O3mY2=A zUVy_uwEY8I(?Ns&kT~FLWRQE}qlP#JhRSRG09jU&te_fKi$_n9(B znWRQ&X(F2Wjo})g4^wUv%E)_`JWf#7IPfVFyxLWN2Pzbxs12?io722`U@=VT*8Po( z-K>?GW7O~Y6XzwXsxixmkSIx#nEc(nphc^0wKQc-gWtykWdc2Kx$;KxwMqrLNZB;9 zu{HFjm5m@1&2*I>Al`@P14FZ%jw#v!>Y|v;H82gPtD;EWaLUnA6@Hk}esa9N+^*9z zQj)+&3NZkTZ%uu@#X$~^gS$Yuy9dPd2!s1cg+g96%N;0~GcdxdTi&sHFctwVHJ)f# z-^0%jF`53INVqJD#c~7OnZmqrMIwY7LYW}fWF&?<#&pHcS5_Khq5jHor2-r1YX+7~ zE|x#7v`LUu)N1Nvf<-&^Z(Z@(W8NM!d5QJ|<}~AktvGilQ3>vvH3Q6xNYh3{uyKnJ zhDNuW-Xb#Y{3ws&TIN~okl|KzJE-u$~QJ2*QwSuC^Yy(>B% zBOLG8f)G*EaB#;Uyd|XC$Kdr25evAR0@tehwiVIw4Fk4dMF`R1jwrQX$-9!dR{_NK zhjb=L`pVtcC)#Hca3t$1D0}|Fua9Brir=WTw)_>rI(UZ@Li<$!Rqjy@qexUUSCL@6 z?5YbUFAw2Uf>>}h@$L)6H|&$#>DW%n>NTyu8Lf}xdd-n^cC9pY;O&Zlg;^v%-YNU# zks601)DXq%de}=@FF%Jmvb;uR8N&CQLsPYJH+R!Vk8;vGA$7BKP`koLcj?;jS3Zp} z(QO!-q5VdO3W+;w6#lkwzmUd=VmCE#19Ak@WZR8LaxyGQ@I*)~r*dRXC`vJ!3yDDM z`h0XRXp%bc(K4)+%W9>fl=vdHt9nP49boJczS$I4LC_9WHl5BcAgG5uB8F2M*}sY2 z`(QJiG=-xM6C8GWMxwKPos=XN$+cqvbXQUy%Yh~MU3$^|T%<8QRTfeFd)K##p0+vG>Baz{st6`z};y-@Ok1ylEf z7`YUTm_i_RS;*P>FXsAm_54s@WmYtGp<2o#-c2s$v0t&l>WVm=(MO*}DG&-Kw~Bx8 ziamk`jzL^QSCudg9Hir%ajgO(OJ{jSjiedWa1{gt8-+S63>L}mY(?g5RRlm}ILflI ze7J3T)v#V@5QGxRjMuX#52b*J8D#M@z`^l~{0a@PC%@*HUXV8=n11{EHU%kOuxYu2pro{9A$MX~GD8IZO@&8@epo(L zi@+L){(o*<9nkcM@G3YpArV1CB@5a?9%Tak4rxUPW%}HLi_uS>5i0vBph*5f8UC2Y z|A1t1Re~^(e1zbV3J#`-K#PpNGUvi0s13TPG$DMNDb^3=Q$1pr-q|6CpNOP*2L=Xa z(wHrU&%P%y<5iA~pmvku*xkpq49OzFle6tjgjy0P+J&H8!dZM1Mg))Q3VbAXNKwsaks!389xn~QAYvmq zNhTF1pxq<12pk9}vugHh9#m4?|4G5dpsXR_TSJr{R)Erk2+jx-(AANYxIKJ9&Pg_9 zb(=2igU>WN0xuLLfDT)dSmMkmYjFFf5+`#o1(9CvEpwjOXIDyyS;!PtAz5HbM@7Gn zZ9kTrH;{3!slQ+P?qTKZp0H9o^~76m6&`PJnsMvWG`!Mi(PRpG3h1d8yL71duxiQi zWfx@0#ksJ%pt3SE})G_Rs=ya zdy7&NiEk^tj6UiCimryvv9QKgA}Wu=6 zo3?wLBQvrla2jIST80@yxCPwQH0jPPO*p`OJL zG*NUGCdkzwrum5c(5?(Rs*tSk;#9v@>t79zKCyYG6v!>t=myM!TfV2u**7Nb2bW7c z(}~EPI;CAE`0hVdY0B}WUgUE%JNFQGR%l`*|@=|Oy5nc{;`+WT>H zsT@O*1AH>%`y@XD83F@1CNPmuF%<~Oyc2-EpUOz`K*Zry9CcV70w@Q!E0-#i6>3g! z?eBsj?B;tvves3j8a0o(0tFlnS}J@rL-6Wn;nrS=d#f2d)A9phAxa)ez=pG7J%#ab zWtDcjjUIyoq#OT`O14qGmA*;Vc4Nq9B)>oWWic7mp}Cd7)YuLm`aU88Ab)7x06Y_U z5wjB0W7aNm%nh+ZMv&3=x9rFy1NP46+l5m~MleY(2#<^*>b{t-xhNjI4Z+4piB5pW zb)2TUSY4Fpz;bhkr5aC89RIx1bUC#d$sf>a3t^z(Jm_7Fs+dt@wcs_81aJTYwa=vj zprn?+qvrzRt?VYq&|AJ1<7Umfg5PK>^KHH`yQ%U~W_}pp{sbGR>Zir%W?Iu&TX*2I?bo zP0kB~>(sUvzupUq7soOvO1GPg;vy)u6V;ZoV6{-cYa0jD5!8n-k0jj5&w0zqQyBL= zs^{OeyjZ5_@MgU~!E(qTqAKN^gFheU{oZR$p3p*()phKtj3J4Rl0qHpPz!te_29P` zh;(g;v$73Lvj*w1>ApcCwsHJn5A{KA`f`Oe?>nXdK4%sywGjI=wr2yO`=s82S6bxe ze(^xFbnqF2d<1ezwExHA(@V*1nwg5TG;ak@(rr7LI0V=I67{&ah3xJdSDWF*m3glL zNHr%v9-YcK`J{+=*=;c^3;=q8_KqD!&~NyObTJK`*Df-1dQ0A!{LPnhV4R`3lko!WSHE5{OXv>9c6qFH;nSA+B>X7LZO`C}*LTQ;4rcG&A*FJm6a z8p-9~f=?iZF!looc=X~Uij1X2k;d|ehpYRCPuRQI9ZMKp0i*LmHCPBi@_PUA&&54G z8E$%5Kb#^sA+@&tD3o+#se==`S5ljSB){K{zj!TO_a;aHNC=c(C5@xy@hWa;?uvie z+U5hX$EdNJEC*9hnE_NN+6N*$NeHSC!?JG26{xBp))0v|LG9iz)vT%9RI;y|m5)uv zKimB6evjY-3*Rgxec)rl8@{BwHgBgdF#n8fS6lt^YPyj@@bi9litl2#3fHsnnowwa zn*xekI)loryOR-7+Pwy2iLr|)mV@K%$h@TVf#38hmZqOkZ)Ms!p$^qV2plVMcf<;Y z8n&&7vl+J@LtMG5zIRBNsms`HXofkfI`+%I@TGT5F6 zPlGN&=uWgzH{ihoKLCrGx)II zr)5x*K*-Vc>Y1W%%^3GgS~%FgemXF~kp zzq^MmCr#lPNDg;Y1UW~yuhQyb{M-~*E1Kgt+Nbi@jjkNysuvdSB=AEh0andtEa@Ev zF7skYMVOw96lw#u3K0qU9zs&|9c4mm^bfA$keCR*^oM8$v3JdX6pbOga4stLr8_@~ zy8^|05|%hMq3UCi2rd>XnCkPJ8Sh>%{VA3{cY90r?3cR4cJdT(<}eK01|4tmKm9d$BIG;(jcuwUr!mW=ay;IpytPc zft@4Z96KoJF7~1)>(&g80ptT}w{9&r6zvv_1=^4DoA{uzB_SdLIsfom}gED zfmh$63^QdN{K4D~a-)tBHjCf?P)sK{j1~r$BayT!*M5;2=A?MACUVK^L8cSJH*Z&i zqL#lIlOiuxpfE7c(^B__mzV`JHm7fi52+mbT75`_8zzD8c(V2Pr}*p)%Qcdw$hKb6 zonDPNT0E6u*j0*N?kXqNkrq<=nFHj+&d9keabP$lq1CZ8En0R?q7NX{$(+TXC|eH7 zG&p7u*X!rPJ#<=asiy7+e2jHAI3FJiPT?!UzukQB6P2iU%z!j2ITy9dKm>HPhtsqz zQ;sW>NJCHT_g-+-yh3nd?kspJuW~4_axue;t=M@0i`NsWdvb$yKh5+H=2NsuR2M{> z*9;A$qc|X3nojZ={cS&*NfcL^<*I*-h4_caM1Z_5M-ip|6}FF0>T2{VX~;XDZ(&FO zjw|ml+OAK-(i1I1rDe;zPx7m878}Iii4X~%BXq~CgC6lP@GRlzL`6_<@n{FnF3NI< zAcOf}%GVTw1388wSSZ~djA;zWiXmmGNL5>ygY0->`C#JsxFLxx5kcaRU)t)|ktt{7 z4EK>q03u!e?S5=t0-+coLV!XxY3=C=lVeB7UM?_ZU#WI!Cpt@&2`bjVE+1j)zDT9Dg$`%6C2P%U9f z>rc@_ltOP+NML$rDbATY84ATzw^5|6@4ES0q!k(o<#~NrKftMF(UdX0_B8!?%2PDG zB&M8cAttvbRG}qgtY-9;7?sT89ei}8M+S1b3M0(%V3lkV$2Z--@>!Qsu(_qTc+8Id z;Oou`gjDw*xIz#Kp{v65R!MUJLH}pPH*hmjIQh;z$X;K&%-V*~D>F%oauyQ!?kpQtB^mA;A*ybZd2JP|G+*Z zdnkAMV~$qtggWnkfPAvP8KDe05~esLsZQ&v04pcm#<9@JftPgu0XhWj5Y7&=1>Bgv zgQ>-?C`yYbW|&Ha6WAXVD*z+k&zLaF%LE^Yi=RqM7pPqW#X|=u_2MJiGn`2X=U!0t0l6$j;-Ieu;Q-b zVg&alwGt5wt)T^+7EV6VhsS*4%s#!suYL)-swdd@DnHS&0yF181nZef;Z+(N#i~^% z(xM?=@tokaw3AXMA~&7syiD5}ZsUB2uTyvRu1AgE$?DGb#Jb|98BX#bH|+ z9uK&)gVXftSA5v?ze>oncK}Emtvq+q6*@k$>3z-4JR1`90P+A_t!c(A`|Z_6g|ETq z|6>)BgCGWS?e#gioT%8%;27|73%nknm)4mkkT;#qyX4?O* zyr1{AvtU7aOhLm|t(fn@hRKWJdvr(zpbEFyb~sz50VDxG2^N?WdrtklF7A|QNXetQ z8+@PP3ZuM^1r^wi5=`q*^};K`lf z%ebAn9uKfK)(OEB|FujU*1#?lg>x(>Iv}d)l?eE-hQ*kjSaFm62Z0_6em4YFm=?ZT zQ8w7On8{op{3RBu-GK!*A6apbU42RdMU$UrS3V39^cMToLYNUNEm*w0z>V?m;l>^R zJD6xzFt!cGHPWl@Z)3l_Vklk}A+PG4QbAANU46>MPI*Q8;Jg1k2KJ?m`>x)jg?$V` z>|=N?4ZB>mBa0PcWh1Yw6#$R%1d9py*mmQee;7x?U-M_Q`Kxm^js3t_IV&^@(_nO;m#~&QhQ$Q^$2gC%v-9@z*44;| zgh4A65k(IFc@Ao9#fyMQ@y3;1?*ITz#@bbE1I42QbzhAR$`UC)V7Vl$F_!W9_Wolz zY}ht_``5o^GfU1}X?*-&Zv#5%RWnEhXV`$xQgVfU#X9g(SbJUPycNZlV_{kgMvr~C iD`WgSz-V#2OJd4~i?gpLjs7^`pN5K-av|J2_ 1000uatom --from --gas auto --ga #### 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](../advanced-concepts/09-grpc_rest.md) or some other entry point 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). +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/06-grpc_rest.md) or some other entry point defined by the application developer. From the user's perspective, the interaction depends on the web interface or wallet they are using (e.g. creating `Tx` using [Lunie.io](https://lunie.io/#/) and signing it with a Ledger Nano S). ## Addition to Mempool @@ -74,7 +72,7 @@ are not empty, enforcing nonnegative numbers, and other logic specified in the d **_Stateful_** checks validate transactions and messages based on a committed state. Examples include checking that the relevant values exist and can 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](../advanced-concepts/00-baseapp.md#state-updates) +At any given moment, full-nodes typically have [multiple versions](../core/00-baseapp.md#state-updates) of the application's internal state for different purposes. For example, nodes 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. @@ -85,31 +83,26 @@ through several steps, beginning with decoding `Tx`. ### Decoding -When `Tx` is received by the application from the underlying consensus engine (e.g. CometBFT ), it is still in its [encoded](../advanced-concepts/06-encoding.md) `[]byte` form and needs to be unmarshaled in order to be processed. Then, the [`runTx`](../advanced-concepts/00-baseapp.md#runtx-antehandler-runmsgs-posthandler) function is called to run in `runTxModeCheck` mode, meaning the function runs all checks but exits before executing messages and writing state changes. +When `Tx` is received by the application from the underlying consensus engine (e.g. CometBFT ), it is still in its [encoded](../core/05-encoding.md) `[]byte` form and needs to be unmarshaled in order to be processed. Then, the [`runTx`](../core/00-baseapp.md#runtx-antehandler-runmsgs-posthandler) function is called to run in `runTxModeCheck` mode, meaning the function runs all checks but exits before executing messages and writing state changes. -### ValidateBasic (deprecated) +### ValidateBasic -Messages ([`sdk.Msg`](../advanced-concepts/01-transactions.md#messages)) are extracted from transactions (`Tx`). The `ValidateBasic` method of the `sdk.Msg` interface implemented by the module developer is run for each transaction. -To discard obviously invalid messages, the `BaseApp` type calls the `ValidateBasic` method very early in the processing of the message in the [`CheckTx`](../advanced-concepts/00-baseapp.md#checktx) and [`DeliverTx`](../advanced-concepts/00-baseapp.md#delivertx) transactions. +Messages ([`sdk.Msg`](../core/01-transactions.md#messages)) are extracted from transactions (`Tx`). The `ValidateBasic` method of the `sdk.Msg` interface implemented by the module developer is run for each transaction. +To discard obviously invalid messages, the `BaseApp` type calls the `ValidateBasic` method very early in the processing of the message in the [`CheckTx`](../core/00-baseapp.md#checktx) and [`DeliverTx`](../core/00-baseapp.md#delivertx) transactions. `ValidateBasic` can include only **stateless** checks (the checks that do not require access to the state). -:::warning -The `ValidateBasic` method on messages has been deprecated in the newest versions in favor of validating messages directly in their respective [`Msg` services](../../integrate/building-modules/03-msg-services.md#Validation). +#### Guideline -Read [RFC 001](https://docs.cosmos.network/main/rfc/rfc-001-tx-validation) for more details. -::: +Gas is not charged when `ValidateBasic` is executed, so we recommend only performing all necessary stateless checks to enable middleware operations (for example, parsing the required signer accounts to validate a signature by a middleware) and stateless sanity checks not impacting performance of the `CheckTx` phase. +Other validation operations must be performed when [handling a message](../building-modules/msg-services#Validation) in a module Msg Server. -:::note -`BaseApp` still calls `ValidateBasic` on messages that implements that method for backwards compatibility. -::: - -#### Guideline +For example, if the message is to send coins from one address to another, `ValidateBasic` likely checks for non-empty addresses and a non-negative coin amount, but does not require knowledge of state such as the account balance of an address. -`ValidateBasic` should not be used anymore. Message validation should be performed in the `Msg` service when [handling a message](../../integrate/building-modules/03-msg-services#Validation) in a module Msg Server. +See also [Msg Service Validation](../building-modules/03-msg-services.md#Validation). ### 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. +After the `ValidateBasic` checks, the `AnteHandler`s are run. Technically, they are optional, but in practice, they are very often present to perform signature verification, gas calculation, fee deduction, and other core operations related to blockchain transactions. A copy of the cached context is provided to the `AnteHandler`, which performs limited checks specified for the transaction type. Using a copy allows the `AnteHandler` to do stateful checks for `Tx` without modifying the last committed state, and revert back to the original if the execution fails. @@ -117,7 +110,7 @@ For example, the [`auth`](https://github.com/cosmos/cosmos-sdk/tree/main/x/auth/ ### Gas -The [`Context`](../advanced-concepts/02-context.md), which keeps a `GasMeter` that tracks how much gas is 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 during execution, ever exceeds `GasWanted`, the execution stops and the changes made to the cached copy of the state are not 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`. +The [`Context`](../core/02-context.md), which keeps a `GasMeter` that tracks how much gas is 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 during execution, ever exceeds `GasWanted`, the execution stops and the changes made to the cached copy of the state are not 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`. ### Discard or Addition to Mempool @@ -159,8 +152,8 @@ must be in this proposer's mempool. 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`](00-overview-app.md#beginblocker-and-endblocker), `DeliverTx` for each transaction, -and [`EndBlock`](00-overview-app.md#beginblocker-and-endblocker). While each full-node runs everything +[`BeginBlock`](./00-app-anatomy.md#beginblocker-and-endblocker), `DeliverTx` for each transaction, +and [`EndBlock`](./00-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. @@ -203,14 +196,14 @@ explicitly ordered in the block proposal. ### DeliverTx -The `DeliverTx` ABCI function defined in [`BaseApp`](../advanced-concepts/00-baseapp.md) does the bulk of the +The `DeliverTx` ABCI function defined in [`BaseApp`](../core/00-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`](../advanced-concepts/00-baseapp.md#runtx) function in deliver mode instead of check mode. +[`runTx`](../core/00-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`](00-overview-app#register-codec) defined in the app, then call `runTx` in `runTxModeDeliver`, which is very similar to `CheckTx` but also executes and writes state changes. + 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 and `AnteHandler`:** Full-nodes call `validateBasicMsgs` and `AnteHandler` again. This second check happens because they may not have seen the same transactions during the addition to Mempool stage @@ -219,14 +212,14 @@ Instead of using their `checkState`, full-nodes use `deliverState`: to each node - differing values across nodes yield nondeterministic results. * **`MsgServiceRouter`:** After `CheckTx` exits, `DeliverTx` continues to run - [`runMsgs`](../advanced-concepts/00-baseapp.md#runtx-antehandler-runmsgs-posthandler) to fully execute each `Msg` within the transaction. + [`runMsgs`](../core/00-baseapp.md#runtx-antehandler-runmsgs-posthandler) 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](../../integrate/building-modules/03-msg-services.md). - For `LegacyMsg` routing, the `Route` function is called via the [module manager](../../integrate/building-modules/01-module-manager.md) to retrieve the route name and find the legacy [`Handler`](../../integrate/building-modules/03-msg-services.md#handler-type) within the 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/03-msg-services.md). + For `LegacyMsg` routing, the `Route` function is called via the [module manager](../building-modules/01-module-manager.md) to retrieve the route name and find the legacy [`Handler`](../building-modules/03-msg-services.md#handler-type) within the module. * **`Msg` service:** Protobuf `Msg` service is responsible for executing each message in the `Tx` and causes state transitions to persist in `deliverTxState`. -* **PostHandlers:** [`PostHandler`](../advanced-concepts/00-baseapp.md#posthandler)s run after the execution of the message. If they fail, the state change of `runMsgs`, as well of `PostHandlers`, are both reverted. +* **PostHandlers:** [`PostHandler`](../core/00-baseapp.md#posthandler)s run after the execution of the message. If they fail, the state change of `runMsgs`, as well of `PostHandlers`, are both reverted. * **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 @@ -247,8 +240,8 @@ 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`](../advanced-concepts/00-baseapp.md#commit) -ABCI method inherited from [Baseapp](../advanced-concepts/00-baseapp.md); it syncs all the state transitions by +a merkle proof for the state transitions. Applications use the [`Commit`](../core/00-baseapp.md#commit) +ABCI method inherited from [Baseapp](../core/00-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` starts afresh from the most recently committed state and `deliverState` resets to `nil` in order to be consistent and reflect the changes. diff --git a/versioned_docs/version-0.47/develop/high-level-concepts/02-query-lifecycle.md b/versioned_docs/version-0.47/develop/high-level-concepts/02-query-lifecycle.md new file mode 100644 index 000000000..27db1caf4 --- /dev/null +++ b/versioned_docs/version-0.47/develop/high-level-concepts/02-query-lifecycle.md @@ -0,0 +1,149 @@ +--- +sidebar_position: 1 +--- + +# Query Lifecycle + +:::note Synopsis +This document describes the lifecycle of a query in a Cosmos SDK application, from the user interface to application stores and back. The query is referred to as `MyQuery`. +::: + +:::note + +### Pre-requisite Readings + +* [Transaction Lifecycle](./01-tx-lifecycle.md) +::: + +## Query Creation + +A [**query**](../building-modules/02-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/01-transactions.md) (view the lifecycle [here](./01-tx-lifecycle.md)), particularly in that they do not require consensus to be processed (as they do not trigger state-transitions); they can be fully handled by one full-node. + +For the purpose of explaining the query lifecycle, let's say the query, `MyQuery`, is requesting a list of delegations made by a certain delegator address in the application called `simapp`. As is to be expected, the [`staking`](../modules/staking/README.md) module handles this query. But first, there are a few ways `MyQuery` can be created by users. + +### CLI + +The main interface for an application is the command-line interface. Users connect to a full-node and run the CLI directly from their machines - the CLI interacts directly with the full-node. To create `MyQuery` from their terminal, users type the following command: + +```bash +simd query staking delegations +``` + +This query command was defined by the [`staking`](../modules/staking/README.md) module developer and added to the list of subcommands by the application developer when creating the CLI. + +Note that the general format is as follows: + +```bash +simd query [moduleName] [command] --flag +``` + +To provide values such as `--node` (the full-node the CLI connects to), the user can use the [`app.toml`](../run-node/02-interact-node.md#configuring-the-node-using-apptoml) config file to set them or provide them as flags. + +The CLI understands a specific set of commands, defined in a hierarchical structure by the application developer: from the [root command](../core/07-cli.md#root-command) (`simd`), the type of command (`Myquery`), the module that contains the command (`staking`), and command itself (`delegations`). Thus, the CLI knows exactly which module handles this command and directly passes the call there. + +### gRPC + +Another interface through which users can make queries is [gRPC](https://grpc.io) requests to a [gRPC server](../core/06-grpc_rest.md#grpc-server). The endpoints are defined as [Protocol Buffers](https://developers.google.com/protocol-buffers) service methods inside `.proto` files, written in Protobuf's own language-agnostic interface definition language (IDL). The Protobuf ecosystem developed tools for code-generation from `*.proto` files into various languages. These tools allow to build gRPC clients easily. + +One such tool is [grpcurl](https://github.com/fullstorydev/grpcurl), and a gRPC request for `MyQuery` using this client looks like: + +```bash +grpcurl \ + -plaintext # We want results in plain test + -import-path ./proto \ # Import these .proto files + -proto ./proto/cosmos/staking/v1beta1/query.proto \ # Look into this .proto file for the Query protobuf service + -d '{"address":"$MY_DELEGATOR"}' \ # Query arguments + localhost:9090 \ # gRPC server endpoint + cosmos.staking.v1beta1.Query/Delegations # Fully-qualified service method name +``` + +### REST + +Another interface through which users can make queries is through HTTP Requests to a [REST server](../core/06-grpc_rest.md#rest-server). The REST server is fully auto-generated from Protobuf services, using [gRPC-gateway](https://github.com/grpc-ecosystem/grpc-gateway). + +An example HTTP request for `MyQuery` looks like: + +```bash +GET http://localhost:1317/cosmos/staking/v1beta1/delegators/{delegatorAddr}/delegations +``` + +## How Queries are Handled by the CLI + +The preceding examples show how an external user can interact with a node by querying its state. To understand in more detail the exact lifecycle of a query, let's dig into how the CLI prepares the query, and how the node handles it. The interactions from the users' perspective are a bit different, but the underlying functions are almost identical because they are implementations of the same command defined by the module developer. This step of processing happens within the CLI, gRPC, or REST server, and heavily involves a `client.Context`. + +### Context + +The first thing that is created in the execution of a CLI command is a `client.Context`. A `client.Context` is an object that stores all the data needed to process a request on the user side. In particular, a `client.Context` stores the following: + +* **Codec**: The [encoder/decoder](../core/05-encoding.md) used by the application, used to marshal the parameters and query before making the CometBFT 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`](../modules/auth/README.md) module, which translates `[]byte`s into accounts. +* **RPC Client**: The CometBFT RPC Client, or node, to which requests are relayed. +* **Keyring**: A [Key Manager](../basics/03-accounts.md#keyring) used to sign transactions and handle other operations with keys. +* **Output Writer**: A [Writer](https://pkg.go.dev/io/#Writer) used to output the response. +* **Configurations**: The flags configured by the user for this command, including `--height`, specifying the height of the blockchain to query, and `--indent`, which indicates to add an indent to the JSON response. + +The `client.Context` also contains various functions such as `Query()`, which retrieves the RPC Client and makes an ABCI call to relay a query to a full-node. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/client/context.go#L24-L64 +``` + +The `client.Context`'s primary role is to store data used during interactions with the end-user and provide methods to interact with this data - it is used before and after the query is processed by the full-node. Specifically, in handling `MyQuery`, the `client.Context` is utilized to encode the query parameters, retrieve the full-node, and write the output. Prior to being relayed to a full-node, the query needs to be encoded into a `[]byte` form, as full-nodes are application-agnostic and do not understand specific types. The full-node (RPC Client) itself is retrieved using the `client.Context`, which knows which node the user CLI is connected to. The query is relayed to this full-node to be processed. Finally, the `client.Context` contains a `Writer` to write output when the response is returned. These steps are further described in later sections. + +### Arguments and Route Creation + +At this point in the lifecycle, the user has created a CLI command with all of the data they wish to include in their query. A `client.Context` exists to assist in the rest of the `MyQuery`'s journey. Now, the next step is to parse the command or request, extract the arguments, and encode everything. These steps all happen on the user side within the interface they are interacting with. + +#### Encoding + +In our case (querying an address's delegations), `MyQuery` contains an [address](./03-accounts.md#addresses) `delegatorAddress` as its only argument. However, the request can only contain `[]byte`s, as it is ultimately relayed to a consensus engine (e.g. CometBFT) of a full-node that has no inherent knowledge of the application types. Thus, the `codec` of `client.Context` is used to marshal the address. + +Here is what the code looks like for the CLI command: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/staking/client/cli/query.go#L323-L326 +``` + +#### gRPC Query Client Creation + +The Cosmos SDK leverages code generated from Protobuf services to make queries. The `staking` module's `MyQuery` service generates a `queryClient`, which the CLI uses to make queries. Here is the relevant code: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/staking/client/cli/query.go#L317-L343 +``` + +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/03-node.md)) configured by the user to relay this query to, and creates the `ABCIQueryOptions` (parameters formatted for the ABCI call). The node is then used to make the ABCI call, `ABCIQueryWithOptions()`. + +Here is what the code looks like: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/client/query.go#L79-L113 +``` + +## RPC + +With a call to `ABCIQueryWithOptions()`, `MyQuery` is received by a [full-node](../core/05-encoding.md) which then processes the request. Note that, while the RPC is made to the consensus engine (e.g. CometBFT) of a full-node, queries are not part of consensus and so are not broadcasted to the rest of the network, as they do not require anything the network needs to agree upon. + +Read more about ABCI Clients and CometBFT RPC in the [CometBFT documentation](https://docs.cometbft.com/v0.37/spec/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 at that point being handled within an environment that understands application-specific types and has a copy of the state. [`baseapp`](../core/00-baseapp.md) implements the ABCI [`Query()`](../core/00-baseapp.md#query) function and handles gRPC queries. The query route is parsed, and it matches the fully-qualified service method name of an existing service method (most likely in one of the modules), then `baseapp` relays the request to the relevant module. + +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/04-query-services.md). + +Once a result is received from the querier, `baseapp` begins the process of returning a response to the user. + +## Response + +Since `Query()` is an ABCI function, `baseapp` returns the response as an [`abci.ResponseQuery`](https://docs.cometbft.com/master/spec/abci/abci.html#query-2) type. The `client.Context` `Query()` routine receives the response and. + +### CLI Response + +The application [`codec`](../core/05-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). + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/client/context.go#L330-L358 +``` + +And that's a wrap! The result of the query is outputted to the console by the CLI. diff --git a/versioned_docs/version-0.47/develop/high-level-concepts/03-accounts.md b/versioned_docs/version-0.47/develop/high-level-concepts/03-accounts.md new file mode 100644 index 000000000..a9f8733ae --- /dev/null +++ b/versioned_docs/version-0.47/develop/high-level-concepts/03-accounts.md @@ -0,0 +1,281 @@ +--- +sidebar_position: 1 +--- + +# Accounts + +:::note Synopsis +This document describes the in-built account and public key system of the Cosmos SDK. +::: + +:::note + +### Pre-requisite Readings + +* [Anatomy of a Cosmos SDK Application](./00-app-anatomy.md) + +::: + +## 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/02-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. + +```text + Account 0 Account 1 Account 2 + ++------------------+ +------------------+ +------------------+ +| | | | | | +| Address 0 | | Address 1 | | Address 2 | +| ^ | | ^ | | ^ | +| | | | | | | | | +| | | | | | | | | +| | | | | | | | | +| + | | + | | + | +| Public key 0 | | Public key 1 | | Public key 2 | +| ^ | | ^ | | ^ | +| | | | | | | | | +| | | | | | | | | +| | | | | | | | | +| + | | + | | + | +| Private key 0 | | Private key 1 | | Private key 2 | +| ^ | | ^ | | ^ | ++------------------+ +------------------+ +------------------+ + | | | + | | | + | | | + +--------------------------------------------------------------------+ + | + | + +---------+---------+ + | | + | Master PrivKey | + | | + +-------------------+ + | + | + +---------+---------+ + | | + | Mnemonic (Seed) | + | | + +-------------------+ +``` + +In the Cosmos SDK, keys are stored and managed by using an object called a [`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). + +In the node, all data is stored using Protocol Buffers serialization. + +The Cosmos SDK supports the following digital key schemes for creating digital signatures: + +* `secp256k1`, as implemented in the [Cosmos SDK's `crypto/keys/secp256k1` package](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/crypto/keys/secp256k1/secp256k1.go). +* `secp256r1`, as implemented in the [Cosmos SDK's `crypto/keys/secp256r1` package](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/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.47.0-rc1/crypto/keys/ed25519/ed25519.go). This scheme is supported only for the consensus validation. + +| | Address length in bytes | Public key length in bytes | Used for transaction authentication | Used for consensus (cometbft) | +| :----------: | :---------------------: | :------------------------: | :---------------------------------: | :-----------------------------: | +| `secp256k1` | 20 | 33 | yes | no | +| `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. + +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: + +* `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. + +These types implement the `Address` interface: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/types/address.go#L108-L124 +``` + +Address construction algorithm is defined in [ADR-28](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-028-public-key-addresses.md). +Here is the standard way to obtain an account address from a `pub` public key: + +```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. + +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: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/types/address.go#L281-L295 +``` + +| | Address Bech32 Prefix | +| ------------------ | --------------------- | +| Accounts | cosmos | +| 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: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/crypto/types/types.go#L8-L17 +``` + +A compressed format is used for `secp256k1` and `secp256r1` serialization. + +* The first byte is a `0x02` byte if the `y`-coordinate is the lexicographically largest of the two associated with the `x`-coordinate. +* Otherwise the first byte is a `0x03`. + +This prefix is followed by the `x`-coordinate. + +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/v0.47.0-rc1/codec/json.go#L14-L34) function). Example: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/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: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/crypto/keyring/keyring.go#L54-L101 +``` + +The default implementation of `Keyring` comes from the third-party [`99designs/keyring`](https://github.com/99designs/keyring) library. + +A few notes on the `Keyring` methods: + +* `Sign(uid string, msg []byte) ([]byte, types.PubKey, error)` strictly deals with the signature of the `msg` 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](../architecture/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/00-baseapp.md#antehandler). + +```protobuf reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/tx/v1beta1/tx.proto#L48-L65 +``` + +* `NewAccount(uid, mnemonic, bip39Passphrase, hdPath string, algo SignatureAlgo) (*Record, 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.47.0-rc1/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: + +* `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. + +### Create New Key Type + +To create a new key type for using in keyring, `keyring.SignatureAlgo` interface must be fulfilled. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/crypto/keyring/signing_algorithms.go#L10-L15 +``` + +The interface consists in three methods where `Name()` returns the name of the algorithm as a `hd.PubKeyType` and `Derive()` and `Generate()` must return the following functions respectively: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/crypto/hd/algo.go#L28-L31 +``` +Once the `keyring.SignatureAlgo` has been implemented it must be added to the [list of supported algos](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/crypto/keyring/keyring.go#L217) of the keyring. + +For simplicity the implementation of a new key type should be done inside the `crypto/hd` package. +There is an example of a working `secp256k1` implementation in [algo.go](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/crypto/hd/algo.go#L38). + + +#### Implementing secp256r1 algo + +Here is an example of how secp256r1 could be implemented. + +First a new function to create a private key from a secret number is needed in the secp256r1 package. This function could look like this: + +```go +// cosmos-sdk/crypto/keys/secp256r1/privkey.go + +// NewPrivKeyFromSecret creates a private key derived for the secret number +// represented in big-endian. The `secret` must be a valid ECDSA field element. +func NewPrivKeyFromSecret(secret []byte) (*PrivKey, error) { + var d = new(big.Int).SetBytes(secret) + if d.Cmp(secp256r1.Params().N) >= 1 { + return nil, sdkerrors.Wrap(errors.ErrInvalidRequest, "secret not in the curve base field") + } + sk := new(ecdsa.PrivKey) + return &PrivKey{&ecdsaSK{*sk}}, nil +} +``` + +After that `secp256r1Algo` can be implemented. + +```go +// cosmos-sdk/crypto/hd/secp256r1Algo.go + +package hd + +import ( + "github.com/cosmos/go-bip39" + + "github.com/cosmos/cosmos-sdk/crypto/keys/secp256r1" + "github.com/cosmos/cosmos-sdk/crypto/types" +) + +// Secp256r1Type uses the secp256r1 ECDSA parameters. +const Secp256r1Type = PubKeyType("secp256r1") + +var Secp256r1 = secp256r1Algo{} + +type secp256r1Algo struct{} + +func (s secp256r1Algo) Name() PubKeyType { + return Secp256r1Type +} + +// Derive derives and returns the secp256r1 private key for the given seed and HD path. +func (s secp256r1Algo) Derive() DeriveFn { + return func(mnemonic string, bip39Passphrase, hdPath string) ([]byte, error) { + seed, err := bip39.NewSeedWithErrorChecking(mnemonic, bip39Passphrase) + if err != nil { + return nil, err + } + + masterPriv, ch := ComputeMastersFromSeed(seed) + if len(hdPath) == 0 { + return masterPriv[:], nil + } + derivedKey, err := DerivePrivateKeyForPath(masterPriv, ch, hdPath) + + return derivedKey, err + } +} + +// Generate generates a secp256r1 private key from the given bytes. +func (s secp256r1Algo) Generate() GenerateFn { + return func(bz []byte) types.PrivKey { + key, err := secp256r1.NewPrivKeyFromSecret(bz) + if err != nil { + panic(err) + } + return key + } +} +``` + +Finally, the algo must be added to the list of [supported algos](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/crypto/keyring/keyring.go#L217) by the keyring. + +```go +// cosmos-sdk/crypto/keyring/keyring.go + +func newKeystore(kr keyring.Keyring, cdc codec.Codec, backend string, opts ...Option) keystore { + // Default options for keybase, these can be overwritten using the + // Option function + options := Options{ + SupportedAlgos: SigningAlgoList{hd.Secp256k1, hd.Secp256r1}, // added here + SupportedAlgosLedger: SigningAlgoList{hd.Secp256k1}, + } +... +``` + +Hereafter to create new keys using your algo, you must specify it with the flag `--algo` : + +`simd keys add myKey --algo secp256r1` \ No newline at end of file diff --git a/versioned_docs/version-0.47/develop/high-level-concepts/04-gas-fees.md b/versioned_docs/version-0.47/develop/high-level-concepts/04-gas-fees.md new file mode 100644 index 000000000..821fe9711 --- /dev/null +++ b/versioned_docs/version-0.47/develop/high-level-concepts/04-gas-fees.md @@ -0,0 +1,99 @@ +--- +sidebar_position: 1 +--- + +# Gas and Fees + +:::note Synopsis +This document describes the default strategies to handle gas and fees within a Cosmos SDK application. +::: + +:::note + +### Pre-requisite Readings + +* [Anatomy of a Cosmos SDK Application](./00-app-anatomy.md) + +::: + +## Introduction to `Gas` and `Fees` + +In the Cosmos SDK, `gas` is a special unit that is used to track the consumption of resources during execution. `gas` is typically consumed whenever read and writes are made to the store, but it can also be consumed if expensive computation needs to be done. It serves two main purposes: + +* Make sure blocks are not consuming too many resources and are 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/02-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 implement `fee` mechanisms to prevent spam by using the [`AnteHandler`](#antehandler). + +## Gas Meter + +In the Cosmos SDK, `gas` is a simple alias for `uint64`, and is managed by an object called a _gas meter_. Gas meters implement the `GasMeter` interface + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/store/types/gas.go#L40-L51 +``` + +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. +* `GasRemaining()` returns the gas left in the GasMeter. +* `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. +* `RefundGas()` deducts the given amount from the gas consumed. This functionality enables refunding gas to the transaction or block gas pools so that EVM-compatible chains can fully support the go-ethereum StateDB interface. +* `IsPastLimit()` returns `true` if the amount of gas consumed by the gas meter instance is strictly above the limit, `false` otherwise. +* `IsOutOfGas()` returns `true` if the amount of gas consumed by the gas meter instance is above or equal to the limit, `false` otherwise. + +The gas meter is generally held in [`ctx`](../core/02-context.md), and consuming gas is done with the following pattern: + +```go +ctx.GasMeter().ConsumeGas(amount, "description") +``` + +By default, the Cosmos SDK makes use of two different gas meters, the [main gas meter](#main-gas-metter) and the [block gas meter](#block-gas-meter). + +### Main Gas Meter + +`ctx.GasMeter()` is the main gas meter of the application. The main gas meter is initialized in `BeginBlock` via `setDeliverState`, and then tracks gas consumption during execution sequences that lead to state-transitions, i.e. those originally triggered by [`BeginBlock`](../core/00-baseapp.md#beginblock), [`DeliverTx`](../core/00-baseapp.md#delivertx) and [`EndBlock`](../core/00-baseapp.md#endblock). At the beginning of each `DeliverTx`, the main gas meter **must be set to 0** in the [`AnteHandler`](#antehandler), so that it can track gas consumption per-transaction. + +Gas consumption can be done manually, generally by the module developer in the [`BeginBlocker`, `EndBlocker`](../building-modules/05-beginblock-endblock.md) or [`Msg` service](../building-modules/03-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/04-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/00-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 CometBFT: + +```go reference +https://github.com/cometbft/cometbft/blob/v0.37.0/types/params.go#L66-L105 +``` + +When a new [transaction](../core/01-transactions.md) is being processed via `DeliverTx`, the current value of `BlockGasMeter` is checked to see if it is above the limit. If it is, `DeliverTx` returns immediately. This can happen even with the first transaction in a block, as `BeginBlock` itself can consume gas. If not, the transaction is processed normally. At the end of `DeliverTx`, the gas tracked by `ctx.BlockGasMeter()` is increased by the amount consumed to process the transaction: + +```go +ctx.BlockGasMeter().ConsumeGas( + ctx.GasMeter().GasConsumedToLimit(), + "block gas meter", +) +``` + +## AnteHandler + +The `AnteHandler` is run for every transaction during `CheckTx` and `DeliverTx`, before a Protobuf `Msg` service method for each `sdk.Msg` in the transaction. + +The anteHandler is not implemented in the core Cosmos SDK but in a module. That said, most applications today use the default implementation defined in the [`auth` module](https://github.com/cosmos/cosmos-sdk/tree/main/x/auth). Here is what the `anteHandler` is intended to do in a normal Cosmos SDK application: + +* Verify that the transactions are of the correct type. Transaction types are defined in the module that implements the `anteHandler`, and they follow the transaction interface: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/types/tx_msg.go#L42-L50 +``` + + 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`: + +```protobuf reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/tx/v1beta1/tx.proto#L13-L26 +``` + +* Verify signatures for each [`message`](../building-modules/02-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 ensures 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 crucial**, as it not only makes sure the transaction cannot consume infinite gas, but also that `ctx.GasMeter` is reset in-between each `DeliverTx` (`ctx` is set to `newCtx` after `anteHandler` is run, and the `anteHandler` is run each time `DeliverTx` is called). + +As explained above, the `anteHandler` returns a maximum limit of `gas` the transaction can consume during execution called `GasWanted`. The actual amount consumed in the end is denominated `GasUsed`, and we must therefore have `GasUsed =< GasWanted`. Both `GasWanted` and `GasUsed` are relayed to the underlying consensus engine when [`DeliverTx`](../core/00-baseapp.md#delivertx) returns. diff --git a/versioned_docs/version-0.47/develop/high-level-concepts/_category_.json b/versioned_docs/version-0.47/develop/high-level-concepts/_category_.json new file mode 100644 index 000000000..1f2b57293 --- /dev/null +++ b/versioned_docs/version-0.47/develop/high-level-concepts/_category_.json @@ -0,0 +1,5 @@ +{ + "label": "Basics", + "position": 1, + "link": null +} \ No newline at end of file diff --git a/versioned_docs/version-0.47/develop/intro/00-what-is-sdk.md b/versioned_docs/version-0.47/develop/intro/00-what-is-sdk.md new file mode 100644 index 000000000..cb14ee46a --- /dev/null +++ b/versioned_docs/version-0.47/develop/intro/00-what-is-sdk.md @@ -0,0 +1,31 @@ +--- +sidebar_position: 0 +dislayed_sidebar: developSidebar +--- +# What is the 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**. + +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 [CometBFT](https://github.com/cometbft/cometbft). SDK-based blockchains are built out of composable [modules](../building-modules/01-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/10-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 decentralized 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 decentralized platforms. More generally, smart contracts can be limiting in terms of flexibility, sovereignty and performance. + +Application-specific blockchains offer a radically different development paradigm than virtual-machine blockchains. An application-specific blockchain is a blockchain customized to operate a single application: developers have all the freedom to make the design decisions required for the application to run optimally. They can also provide better sovereignty, security and performance. + +Learn more about [application-specific blockchains](./01-why-app-specific.md). + +## Why the Cosmos SDK + +The Cosmos SDK is the most advanced framework for building custom application-specific blockchains today. Here are a few reasons why you might want to consider building your decentralized application with the Cosmos SDK: + +* The default consensus engine available within the Cosmos SDK is [CometBFT](https://github.com/cometbft/cometbft). CometBFT 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](../modules). As the ecosystem of open-source Cosmos SDK modules grows, it will become increasingly easier to build complex decentralized 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. + +## Getting started with the Cosmos SDK + +* Learn more about the [architecture of a Cosmos SDK application](./02-sdk-app-architecture.md) +* Learn how to build an application-specific blockchain from scratch with the [Cosmos SDK Tutorial](https://cosmos.network/docs/tutorial) diff --git a/versioned_docs/version-0.47/develop/intro/01-why-app-specific.md b/versioned_docs/version-0.47/develop/intro/01-why-app-specific.md new file mode 100644 index 000000000..97a2d9a8d --- /dev/null +++ b/versioned_docs/version-0.47/develop/intro/01-why-app-specific.md @@ -0,0 +1,80 @@ +--- +sidebar_position: 0 +dislayed_sidebar: developSidebar +--- + +# Application-Specific Blockchains + +:::note Synopsis +This document explains what application-specific blockchains are, and why developers would want to build one as opposed to writing Smart Contracts. +::: + +## What are application-specific blockchains + +Application-specific blockchains are blockchains customized to operate a single application. Instead of building a decentralized 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. + +```text + ^ +-------------------------------+ ^ + | | | | Built with Cosmos SDK + | | State-machine = Application | | + | | | v + | +-------------------------------+ + | | | ^ +Blockchain node | | Consensus | | + | | | | + | +-------------------------------+ | CometBFT + | | | | + | | Networking | | + | | | | + v +-------------------------------+ v +``` + +## What are the shortcomings of Smart Contracts + +Virtual-machine blockchains like Ethereum addressed the demand for more programmability back in 2014. At the time, the options available for building decentralized applications were quite limited. Most developers would build on top of the complex and limited Bitcoin scripting language, or fork the Bitcoin codebase which was hard to work with and customize. + +Virtual-machine blockchains came in with a new value proposition. Their state-machine incorporates a virtual-machine that is able to interpret turing-complete programs called Smart Contracts. These Smart Contracts are very good for use cases like one-time events (e.g. ICOs), but they can fall short for building complex decentralized platforms. Here is why: + +* Smart Contracts are generally developed with specific programming languages that can be interpreted by the underlying virtual-machine. These programming languages are often immature and inherently limited by the constraints of the virtual-machine itself. For example, the Ethereum Virtual Machine does not allow developers to implement automatic execution of code. Developers are also limited to the account-based system of the EVM, and they can only choose from a limited set of functions for their cryptographic operations. These are examples, but they hint at the lack of **flexibility** that a smart contract environment often entails. +* Smart Contracts are all run by the same virtual machine. This means that they compete for resources, which can 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 interpreted 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 decentralized application is an ecosystem that involves multiple players. If the application is built on a general-purpose virtual-machine blockchain, stakeholders have very limited sovereignty over their application, and are ultimately superseded by the governance of the underlying blockchain. If there is a bug in the application, very little can be done about it. + +Application-Specific Blockchains are designed to address these shortcomings. + +## Application-Specific Blockchains Benefits + +### Flexibility + +Application-specific blockchains give maximum flexibility to developers: + +* In Cosmos blockchains, the state-machine is typically connected to the underlying consensus engine via an interface called the [ABCI](https://docs.cometbft.com/v0.37/spec/abci/). This interface can be wrapped in any programming language, meaning developers can build their state-machine in the programming language of their choice. + +* Developers can choose among multiple frameworks to build their state-machine. The most widely used today is the Cosmos SDK, but others exist (e.g. [Lotion](https://github.com/nomic-io/lotion), [Weave](https://github.com/iov-one/weave), ...). 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 CometBFT is production-ready, but in the future other consensus engines are expected to emerge. +* Even when they settle for a framework and consensus engine, developers still have the freedom to tweak them if they don't perfectly match their requirements in their pristine forms. +* Developers are free to explore the full spectrum of tradeoffs (e.g. number of validators vs transaction throughput, safety vs availability in asynchrony, ...) and design choices (DB or IAVL tree for storage, UTXO or account model, ...). +* Developers can implement automatic execution of code. In the Cosmos SDK, logic can be automatically triggered at the beginning and the end of each block. They are also free to choose the cryptographic library used in their application, as opposed to being constrained by what is made available by the underlying environment in the case of virtual-machine blockchains. + +The list above contains a few examples that show how much flexibility application-specific blockchains give to developers. The goal of Cosmos and the Cosmos SDK is to make developer tooling as generic and composable as possible, so that each part of the stack can be forked, tweaked and improved without losing compatibility. As the community grows, more alternatives for each of the core building blocks will emerge, giving more options to developers. + +### Performance + +decentralized applications built with Smart Contracts are inherently capped in performance by the underlying environment. For a decentralized application to optimise performance, it needs to be built as an application-specific blockchain. Next are some of the benefits an application-specific blockchain brings in terms of performance: + +* Developers of application-specific blockchains can choose to operate with a novel consensus engine such as CometBFT BFT. Compared to Proof-of-Work (used by most virtual-machine blockchains today), it offers significant gains in throughput. +* An application-specific blockchain only operates a single application, so that the application does not compete with others for computation and storage. This is the opposite of most non-sharded virtual-machine blockchains today, where smart contracts all compete for computation and storage. +* Even if a virtual-machine blockchain offered application-based sharding coupled with an efficient consensus algorithm, performance would still be limited by the virtual-machine itself. The real throughput bottleneck is the state-machine, and requiring transactions to be interpreted by a virtual-machine significantly increases the computational complexity of processing them. + +### Security + +Security is hard to quantify, and greatly varies from platform to platform. That said here are some important benefits an application-specific blockchain can bring in terms of security: + +* Developers can choose proven programming languages like Go when building their application-specific blockchains, as opposed to smart contract programming languages that are often more immature. +* Developers are not constrained by the cryptographic functions made available by the underlying virtual-machines. They can use their own custom cryptography, and rely on well-audited crypto libraries. +* Developers do not have to worry about potential bugs or exploitable mechanisms in the underlying virtual-machine, making it easier to reason about the security of the application. + +### Sovereignty + +One of the major benefits of application-specific blockchains is sovereignty. A decentralized application is an ecosystem that involves many actors: users, developers, third-party services, and more. When developers build on virtual-machine blockchain where many decentralized 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. diff --git a/versioned_docs/version-0.47/develop/intro/02-sdk-app-architecture.md b/versioned_docs/version-0.47/develop/intro/02-sdk-app-architecture.md new file mode 100644 index 000000000..a7ef4fa7a --- /dev/null +++ b/versioned_docs/version-0.47/develop/intro/02-sdk-app-architecture.md @@ -0,0 +1,94 @@ +--- +sidebar_position: 0 +dislayed_sidebar: developSidebar +--- + +# Blockchain Architecture + +## State machine + +At its core, a blockchain is a [replicated deterministic state machine](https://en.wikipedia.org/wiki/State_machine_replication). + +A state machine is a computer science concept whereby a machine can have multiple states, but only one at any given time. There is a `state`, which describes the current state of the system, and `transactions`, that trigger state transitions. + +Given a state S and a transaction T, the state machine will return a new state S'. + +```text ++--------+ +--------+ +| | | | +| S +---------------->+ S' | +| | apply(T) | | ++--------+ +--------+ +``` + +In practice, the transactions are bundled in blocks to make the process more efficient. Given a state S and a block of transactions B, the state machine will return a new state S'. + +```text ++--------+ +--------+ +| | | | +| S +----------------------------> | S' | +| | For each T in B: apply(T) | | ++--------+ +--------+ +``` + +In a blockchain context, the state machine is deterministic. This means that if a node is started at a given state and replays the same sequence of transactions, it will always end up with the same final state. + +The Cosmos SDK gives developers maximum flexibility to define the state of their application, transaction types and state transition functions. The process of building state-machines with the Cosmos SDK will be described more in depth in the following sections. But first, let us see how the state-machine is replicated using **CometBFT**. + +## CometBFT + +Thanks to the Cosmos SDK, developers just have to define the state machine, and [*CometBFT*](https://docs.cometbft.com/v0.37/introduction/what-is-cometbft) will handle replication over the network for them. + +```text + ^ +-------------------------------+ ^ + | | | | Built with Cosmos SDK + | | State-machine = Application | | + | | | v + | +-------------------------------+ + | | | ^ +Blockchain node | | Consensus | | + | | | | + | +-------------------------------+ | CometBFT + | | | | + | | Networking | | + | | | | + v +-------------------------------+ v +``` + +[CometBFT](https://docs.cometbft.com/v0.37/introduction/what-is-cometbft) is an application-agnostic engine that is responsible for handling the *networking* and *consensus* layers of a blockchain. In practice, this means that CometBFT is responsible for propagating and ordering transaction bytes. CometBFT relies on an eponymous Byzantine-Fault-Tolerant (BFT) algorithm to reach consensus on the order of transactions. + +The CometBFT [consensus algorithm](https://docs.cometbft.com/v0.37/introduction/what-is-cometbft#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` and a `precommit` on it, and if all the transactions that it contains are valid. The validator set can be changed by rules written in the state-machine. + +## ABCI + +CometBFT passes transactions to the application through an interface called the [ABCI](https://docs.cometbft.com/v0.37/spec/abci/), which the application must implement. + +```text + +---------------------+ + | | + | Application | + | | + +--------+---+--------+ + ^ | + | | ABCI + | v + +--------+---+--------+ + | | + | | + | CometBFT | + | | + | | + +---------------------+ +``` + +Note that **CometBFT only handles transaction bytes**. It has no knowledge of what these bytes mean. All CometBFT does is order these transaction bytes deterministically. CometBFT passes the bytes to the application via the ABCI, and expects a return code to inform it if the messages contained in the transactions were successfully processed or not. + +Here are the most important messages of the ABCI: + +* `CheckTx`: When a transaction is received by CometBFT, 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/04-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.cometbft.com/v0.37/spec/p2p/messages/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.cometbft.com/v0.37/spec/core/data_structures#block) is received by CometBFT, 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/03-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 transactions or not. It is useful to trigger automatic execution of logic. Proceed with caution though, as computationally expensive loops could slow down your blockchain, or even freeze it if the loop is infinite. + +Find a more detailed view of the ABCI methods from the [CometBFT docs](https://docs.cometbft.com/v0.37/spec/abci/). + +Any application built on CometBFT needs to implement the ABCI interface in order to communicate with the underlying local CometBFT 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](./03-sdk-design.md#baseapp). diff --git a/versioned_docs/version-0.47/develop/intro/03-sdk-design.md b/versioned_docs/version-0.47/develop/intro/03-sdk-design.md new file mode 100644 index 000000000..6a8bc52de --- /dev/null +++ b/versioned_docs/version-0.47/develop/intro/03-sdk-design.md @@ -0,0 +1,96 @@ +--- +sidebar_position: 0 +dislayed_sidebar: developSidebar +--- + +# Main Components of the Cosmos SDK + +The Cosmos SDK is a framework that facilitates the development of secure state-machines on top of CometBFT. At its core, the Cosmos SDK is a boilerplate implementation of the [ABCI](./02-sdk-app-architecture.md#abci) in Golang. It comes with a [`multistore`](../core/04-store.md#multistore) to persist data and a [`router`](../core/00-baseapp.md#routing) to handle transactions. + +Here is a simplified view of how transactions are handled by an application built on top of the Cosmos SDK when transferred from CometBFT via `DeliverTx`: + +1. Decode `transactions` received from the CometBFT consensus engine (remember that CometBFT only deals with `[]bytes`). +2. Extract `messages` from `transactions` and do basic sanity checks. +3. Route each message to the appropriate module so that it can be processed. +4. Commit state changes. + +## `baseapp` + +`baseapp` is the boilerplate implementation of a Cosmos SDK application. It comes with an implementation of the ABCI to handle the connection with the underlying consensus engine. Typically, a Cosmos SDK application extends `baseapp` by embedding it in [`app.go`](../basics/00-app-anatomy.md#core-application-file). + +Here is an example of this from `simapp`, the Cosmos SDK demonstration app: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/simapp/app.go#L164-L203 +``` + +The goal of `baseapp` is to provide a secure interface between the store and the extensible state machine while defining as little about the state machine as possible (staying true to the ABCI). + +For more on `baseapp`, please click [here](../core/00-baseapp.md). + +## Multistore + +The Cosmos SDK provides a [`multistore`](../core/04-store.md#multistore) for persisting state. The multistore allows developers to declare any number of [`KVStores`](../core/04-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/05-encoding.md) before being stored. + +The multistore abstraction is used to divide the state in distinct compartments, each managed by its own module. For more on the multistore, click [here](../core/04-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. + +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: + +```text + + + | + | Transaction relayed from the full-node's + | CometBFT engine to the node's application + | via DeliverTx + | + | + +---------------------v--------------------------+ + | APPLICATION | + | | + | Using baseapp's methods: Decode the Tx, | + | extract and route the message(s) | + | | + +---------------------+--------------------------+ + | + | + | + +---------------------------+ + | + | + | Message routed to + | the correct module + | to be processed + | + | ++----------------+ +---------------+ +----------------+ +------v----------+ +| | | | | | | | +| AUTH MODULE | | BANK MODULE | | STAKING MODULE | | GOV MODULE | +| | | | | | | | +| | | | | | | Handles message,| +| | | | | | | Updates state | +| | | | | | | | ++----------------+ +---------------+ +----------------+ +------+----------+ + | + | + | + | + +--------------------------+ + | + | Return result to CometBFT + | (0=Ok, 1=Err) + v +``` + +Each module can be seen as a little state-machine. Developers need to define the subset of the state handled by the module, as well as custom message types that modify the state (*Note:* `messages` are extracted from `transactions` by `baseapp`). In general, each module declares its own `KVStore` in the `multistore` to persist the subset of the state it defines. Most developers will need to access other 3rd party modules when building their own modules. Given that the Cosmos SDK is an open framework, some of the modules may be malicious, which means there is a need for security principles to reason about inter-module interactions. These principles are based on [object-capabilities](../core/10-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. + +Cosmos SDK modules are defined in the `x/` folder of the Cosmos SDK. Some core modules include: + +* `x/auth`: Used to manage accounts and signatures. +* `x/bank`: Used to enable tokens and token transfers. +* `x/staking` + `x/slashing`: Used to build Proof-Of-Stake blockchains. + +In addition to the already existing modules in `x/`, that anyone can use in their app, the Cosmos SDK lets you build your own custom modules. You can check an [example of that in the tutorial](https://tutorials.cosmos.network/). diff --git a/versioned_docs/version-0.47/develop/intro/_category_.json b/versioned_docs/version-0.47/develop/intro/_category_.json new file mode 100644 index 000000000..b218fe9be --- /dev/null +++ b/versioned_docs/version-0.47/develop/intro/_category_.json @@ -0,0 +1,5 @@ +{ + "label": "Introduction", + "position": 0, + "link": null +} \ No newline at end of file diff --git a/versioned_docs/version-0.47/integrate/architecture/PROCESS.md b/versioned_docs/version-0.47/integrate/architecture/PROCESS.md new file mode 100644 index 000000000..c5140bbe4 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/PROCESS.md @@ -0,0 +1,56 @@ +# ADR Creation Process + +1. Copy the `adr-template.md` file. Use the following filename pattern: `adr-next_number-title.md` +2. Create a draft Pull Request if you want to get an early feedback. +3. Make sure the context and a solution is clear and well documented. +4. Add an entry to a list in the [README](./README.md) file. +5. Create a Pull Request to propose a new ADR. + +## ADR life cycle + +ADR creation is an **iterative** process. Instead of trying to solve all decisions in a single ADR pull request, we MUST firstly understand the problem and collect feedback through a GitHub Issue. + +1. Every proposal SHOULD start with a new GitHub Issue or be a result of existing Issues. The Issue should contain just a brief proposal summary. + +2. Once the motivation is validated, a GitHub Pull Request (PR) is created with a new document based on the `adr-template.md`. + +3. An ADR doesn't have to arrive to `main` with an _accepted_ status in a single PR. If the motivation is clear and the solution is sound, we SHOULD be able to merge it and keep a _proposed_ status. It's preferable to have an iterative approach rather than long, not merged Pull Requests. + +4. If a _proposed_ ADR is merged, then it should clearly document outstanding issues either in ADR document notes or in a GitHub Issue. + +5. The PR SHOULD always be merged. In the case of a faulty ADR, we still prefer to merge it with a _rejected_ status. The only time the ADR SHOULD NOT be merged is if the author abandons it. + +6. Merged ADRs SHOULD NOT be pruned. + +### ADR status + +Status has two components: + +```text +{CONSENSUS STATUS} {IMPLEMENTATION STATUS} +``` + +IMPLEMENTATION STATUS is either `Implemented` or `Not Implemented`. + +#### Consensus Status + +```text +DRAFT -> PROPOSED -> LAST CALL yyyy-mm-dd -> ACCEPTED | REJECTED -> SUPERSEDED by ADR-xxx + \ | + \ | + v v + ABANDONED +``` + +* `DRAFT`: [optional] an ADR which is work in progress, not being ready for a general review. This is to present an early work and get an early feedback in a Draft Pull Request form. +* `PROPOSED`: an ADR covering a full solution architecture and still in the review - project stakeholders haven't reached an agreed yet. +* `LAST CALL `: [optional] clear notify that we are close to accept updates. Changing a status to `LAST CALL` means that social consensus (of Cosmos SDK maintainers) has been reached and we still want to give it a time to let the community react or analyze. +* `ACCEPTED`: ADR which will represent a currently implemented or to be implemented architecture design. +* `REJECTED`: ADR can go from PROPOSED or ACCEPTED to rejected if the consensus among project stakeholders will decide so. +* `SUPERSEEDED by ADR-xxx`: ADR which has been superseded by a new ADR. +* `ABANDONED`: the ADR is no longer pursued by the original authors. + +## Language used in ADR + +* The context/background should be written in the present tense. +* Avoid using a first, personal form. diff --git a/versioned_docs/version-0.47/integrate/architecture/README.md b/versioned_docs/version-0.47/integrate/architecture/README.md new file mode 100644 index 000000000..ee65454da --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/README.md @@ -0,0 +1,89 @@ +--- +sidebar_position: 1 +--- + +# Architecture Decision Records (ADR) + +This is a location to record all high-level architecture decisions in the Cosmos-SDK. + +An Architectural Decision (**AD**) is a software design choice that addresses a functional or non-functional requirement that is architecturally significant. +An Architecturally Significant Requirement (**ASR**) is a requirement that has a measurable effect on a software system’s architecture and quality. +An Architectural Decision Record (**ADR**) captures a single AD, such as often done when writing personal notes or meeting minutes; the collection of ADRs created and maintained in a project constitute its decision log. All these are within the topic of Architectural Knowledge Management (AKM). + +You can read more about the ADR concept in this [blog post](https://product.reverb.com/documenting-architecture-decisions-the-reverb-way-a3563bb24bd0#.78xhdix6t). + +## Rationale + +ADRs are intended to be the primary mechanism for proposing new feature designs and new processes, for collecting community input on an issue, and for documenting the design decisions. +An ADR should provide: + +* Context on the relevant goals and the current state +* Proposed changes to achieve the goals +* Summary of pros and cons +* References +* Changelog + +Note the distinction between an ADR and a spec. The ADR provides the context, intuition, reasoning, and +justification for a change in architecture, or for the architecture of something +new. The spec is much more compressed and streamlined summary of everything as +it stands today. + +If recorded decisions turned out to be lacking, convene a discussion, record the new decisions here, and then modify the code to match. + +## Creating new ADR + +Read about the [PROCESS](./PROCESS.md). + +### Use RFC 2119 Keywords + +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 Table of Contents + +### 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 055: ORM](./adr-055-orm.md) +* [ADR 058: Auto-Generated CLI](./adr-058-auto-generated-cli.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 057: App Wiring](./adr-057-app-wiring.md) +* [ADR 059: Test Scopes](./adr-059-test-scopes.md) +* [ADR 060: ABCI 1.0](adr-060-abci-1.0.md) + +### Draft + +* [ADR 044: Guidelines for Updating Protobuf Definitions](./adr-044-protobuf-updates-guidelines.md) +* [ADR 047: Extend Upgrade Plan](./adr-047-extend-upgrade-plan.md) +* [ADR 053: Go Module Refactoring](./adr-053-go-module-refactoring.md) diff --git a/versioned_docs/version-0.47/integrate/architecture/_category_.json b/versioned_docs/version-0.47/integrate/architecture/_category_.json new file mode 100644 index 000000000..d138de900 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/_category_.json @@ -0,0 +1,5 @@ +{ + "label": "ADRs", + "position": 10, + "link": null +} diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-002-docs-structure.md b/versioned_docs/version-0.47/integrate/architecture/adr-002-docs-structure.md new file mode 100644 index 000000000..5819151fc --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-002-docs-structure.md @@ -0,0 +1,86 @@ +# ADR 002: SDK Documentation Structure + +## 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. + +Ideally, we would have: + +* All docs related to dev frameworks or tools live in their respective github repos (sdk repo would contain sdk docs, hub repo would contain hub docs, lotion repo would contain lotion docs, etc.) +* All other docs (faqs, whitepaper, high-level material about Cosmos) would live on the website. + +## Decision + +Re-structure the `/docs` folder of the Cosmos SDK github repo as follows: + +```text +docs/ +├── README +├── intro/ +├── concepts/ +│ ├── baseapp +│ ├── types +│ ├── store +│ ├── server +│ ├── modules/ +│ │ ├── keeper +│ │ ├── handler +│ │ ├── cli +│ ├── gas +│ └── commands +├── clients/ +│ ├── lite/ +│ ├── service-providers +├── modules/ +├── spec/ +├── translations/ +└── architecture/ +``` + +The files in each sub-folders do not matter and will likely change. What matters is the sectioning: + +* `README`: Landing page of the docs. +* `intro`: Introductory material. Goal is to have a short explainer of the 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. + +Website docs sidebar will only include the following sections: + +* `README` +* `intro` +* `concepts` +* `clients` + +`architecture` need not be displayed on the website. + +## Status + +Accepted + +## Consequences + +### Positive + +* Much clearer organisation of the 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) + +### Neutral + +* We need to move a bunch of deprecated stuff to `/_attic` folder. +* We need to integrate content in `docs/sdk/docs/core` in `concepts`. +* We need to move all the content that currently lives in `docs` and does not fit in new structure (like `lotion`, intro material, whitepaper) to the website repository. +* Update `DOCS_README.md` + +## References + +* https://github.com/cosmos/cosmos-sdk/issues/1460 +* https://github.com/cosmos/cosmos-sdk/pull/2695 +* https://github.com/cosmos/cosmos-sdk/issues/2611 diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-003-dynamic-capability-store.md b/versioned_docs/version-0.47/integrate/architecture/adr-003-dynamic-capability-store.md new file mode 100644 index 000000000..f9ddd3643 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-003-dynamic-capability-store.md @@ -0,0 +1,344 @@ +# ADR 3: Dynamic Capability Store + +## Changelog + +* 12 December 2019: Initial version +* 02 April 2020: Memory Store Revisions + +## Context + +Full implementation of the [IBC specification](https://github.com/cosmos/ibc) 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. + +At present, the Cosmos SDK does not have the ability to do this. Object-capability keys are currently pointers (memory addresses) of `StoreKey` structs created at application initialisation in `app.go` ([example](https://github.com/cosmos/gaia/blob/dcbddd9f04b3086c0ad07ee65de16e7adedc7da4/app/app.go#L132)) +and passed to Keepers as fixed arguments ([example](https://github.com/cosmos/gaia/blob/dcbddd9f04b3086c0ad07ee65de16e7adedc7da4/app/app.go#L160)). Keepers cannot create or store capability keys during transaction execution — although they could call `NewKVStoreKey` and take the memory address +of the returned struct, storing this in the Merklised store would result in a consensus fault, since the memory address will be different on each machine (this is intentional — were this not the case, the keys would be predictable and couldn't serve as object capabilities). + +Keepers need a way to keep a private map of store keys which can be altered during transaction execution, along with a suitable mechanism for regenerating the unique memory addresses (capability keys) in this map whenever the application is started or restarted, along with a mechanism to revert capability creation on tx failure. +This ADR proposes such an interface & mechanism. + +## Decision + +The 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. + +When the initial state is loaded from disk, the `CapabilityKeeper`'s `Initialise` function will create +new capability keys for all previously allocated capability identifiers (allocated during execution of +past transactions and assigned to particular modes), and keep them in a memory-only store while the +chain is running. + +The `CapabilityKeeper` will include a persistent `KVStore`, a `MemoryStore`, and an in-memory map. +The persistent `KVStore` tracks which capability is owned by which modules. +The `MemoryStore` stores a forward mapping that map from module name, capability tuples to capability names and +a reverse mapping that map from module name, capability name to the capability index. +Since we cannot marshal the capability into a `KVStore` and unmarshal without changing the memory location of the capability, +the reverse mapping in the KVStore will simply map to an index. This index can then be used as a key in the ephemeral +go-map to retrieve the capability at the original memory location. + +The `CapabilityKeeper` will define the following types & functions: + +The `Capability` is similar to `StoreKey`, but has a globally unique `Index()` instead of +a name. A `String()` method is provided for debugging. + +A `Capability` is simply a struct, the address of which is taken for the actual capability. + +```go +type Capability struct { + index uint64 +} +``` + +A `CapabilityKeeper` contains a persistent store key, memory store key, and mapping of allocated module names. + +```go +type CapabilityKeeper struct { + persistentKey StoreKey + memKey StoreKey + capMap map[uint64]*Capability + moduleNames map[string]interface{} + sealed bool +} +``` + +The `CapabilityKeeper` provides the ability to create *scoped* sub-keepers which are tied to a +particular module name. These `ScopedCapabilityKeeper`s must be created at application initialisation +and passed to modules, which can then use them to claim capabilities they receive and retrieve +capabilities which they own by name, in addition to creating new capabilities & authenticating capabilities +passed by other modules. + +```go +type ScopedCapabilityKeeper struct { + persistentKey StoreKey + memKey StoreKey + capMap map[uint64]*Capability + moduleName string +} +``` + +`ScopeToModule` is used to create a scoped sub-keeper with a particular name, which must be unique. +It MUST be called before `InitialiseAndSeal`. + +```go +func (ck CapabilityKeeper) ScopeToModule(moduleName string) ScopedCapabilityKeeper { + if k.sealed { + panic("cannot scope to module via a sealed capability keeper") + } + + if _, ok := k.scopedModules[moduleName]; ok { + panic(fmt.Sprintf("cannot create multiple scoped keepers for the same module name: %s", moduleName)) + } + + k.scopedModules[moduleName] = struct{}{} + + return ScopedKeeper{ + cdc: k.cdc, + storeKey: k.storeKey, + memKey: k.memKey, + capMap: k.capMap, + module: moduleName, + } +} +``` + +`InitialiseAndSeal` MUST be called exactly once, after loading the initial state and creating all +necessary `ScopedCapabilityKeeper`s, in order to populate the memory store with newly-created +capability keys in accordance with the keys previously claimed by particular modules and prevent the +creation of any new `ScopedCapabilityKeeper`s. + +```go +func (ck CapabilityKeeper) InitialiseAndSeal(ctx Context) { + if ck.sealed { + panic("capability keeper is sealed") + } + + persistentStore := ctx.KVStore(ck.persistentKey) + map := ctx.KVStore(ck.memKey) + + // initialise memory store for all names in persistent store + for index, value := range persistentStore.Iter() { + capability = &CapabilityKey{index: index} + + for moduleAndCapability := range value { + moduleName, capabilityName := moduleAndCapability.Split("/") + memStore.Set(moduleName + "/fwd/" + capability, capabilityName) + memStore.Set(moduleName + "/rev/" + capabilityName, index) + + ck.capMap[index] = capability + } + } + + ck.sealed = true +} +``` + +`NewCapability` can be called by any module to create a new unique, unforgeable object-capability +reference. The newly created capability is automatically persisted; the calling module need not +call `ClaimCapability`. + +```go +func (sck ScopedCapabilityKeeper) NewCapability(ctx Context, name string) (Capability, error) { + // check name not taken in memory store + if capStore.Get("rev/" + name) != nil { + return nil, errors.New("name already taken") + } + + // fetch the current index + index := persistentStore.Get("index") + + // create a new capability + capability := &CapabilityKey{index: index} + + // set persistent store + persistentStore.Set(index, Set.singleton(sck.moduleName + "/" + name)) + + // update the index + index++ + persistentStore.Set("index", index) + + // set forward mapping in memory store from capability to name + memStore.Set(sck.moduleName + "/fwd/" + capability, name) + + // set reverse mapping in memory store from name to index + memStore.Set(sck.moduleName + "/rev/" + name, index) + + // set the in-memory mapping from index to capability pointer + capMap[index] = capability + + // return the newly created capability + return capability +} +``` + +`AuthenticateCapability` can be called by any module to check that a capability +does in fact correspond to a particular name (the name can be untrusted user input) +with which the calling module previously associated it. + +```go +func (sck ScopedCapabilityKeeper) AuthenticateCapability(name string, capability Capability) bool { + // return whether forward mapping in memory store matches name + return memStore.Get(sck.moduleName + "/fwd/" + capability) === name +} +``` + +`ClaimCapability` allows a module to claim a capability key which it has received from another module +so that future `GetCapability` calls will succeed. + +`ClaimCapability` MUST be called if a module which receives a capability wishes to access it by name +in the future. Capabilities are multi-owner, so if multiple modules have a single `Capability` reference, +they will all own it. + +```go +func (sck ScopedCapabilityKeeper) ClaimCapability(ctx Context, capability Capability, name string) error { + persistentStore := ctx.KVStore(sck.persistentKey) + + // set forward mapping in memory store from capability to name + memStore.Set(sck.moduleName + "/fwd/" + capability, name) + + // set reverse mapping in memory store from name to capability + memStore.Set(sck.moduleName + "/rev/" + name, capability) + + // update owner set in persistent store + owners := persistentStore.Get(capability.Index()) + owners.add(sck.moduleName + "/" + name) + persistentStore.Set(capability.Index(), owners) +} +``` + +`GetCapability` allows a module to fetch a capability which it has previously claimed by name. +The module is not allowed to retrieve capabilities which it does not own. + +```go +func (sck ScopedCapabilityKeeper) GetCapability(ctx Context, name string) (Capability, error) { + // fetch the index of capability using reverse mapping in memstore + index := memStore.Get(sck.moduleName + "/rev/" + name) + + // fetch capability from go-map using index + capability := capMap[index] + + // return the capability + return capability +} +``` + +`ReleaseCapability` allows a module to release a capability which it had previously claimed. If no +more owners exist, the capability will be deleted globally. + +```go +func (sck ScopedCapabilityKeeper) ReleaseCapability(ctx Context, capability Capability) err { + persistentStore := ctx.KVStore(sck.persistentKey) + + name := capStore.Get(sck.moduleName + "/fwd/" + capability) + if name == nil { + return error("capability not owned by module") + } + + // delete forward mapping in memory store + memoryStore.Delete(sck.moduleName + "/fwd/" + capability, name) + + // delete reverse mapping in memory store + memoryStore.Delete(sck.moduleName + "/rev/" + name, capability) + + // update owner set in persistent store + owners := persistentStore.Get(capability.Index()) + owners.remove(sck.moduleName + "/" + name) + if owners.size() > 0 { + // there are still other owners, keep the capability around + persistentStore.Set(capability.Index(), owners) + } else { + // no more owners, delete the capability + persistentStore.Delete(capability.Index()) + delete(capMap[capability.Index()]) + } +} +``` + +### Usage patterns + +#### Initialisation + +Any modules which use dynamic capabilities must be provided a `ScopedCapabilityKeeper` in `app.go`: + +```go +ck := NewCapabilityKeeper(persistentKey, memoryKey) +mod1Keeper := NewMod1Keeper(ck.ScopeToModule("mod1"), ....) +mod2Keeper := NewMod2Keeper(ck.ScopeToModule("mod2"), ....) + +// other initialisation logic ... + +// load initial state... + +ck.InitialiseAndSeal(initialContext) +``` + +#### Creating, passing, claiming and using capabilities + +Consider the case where `mod1` wants to create a capability, associate it with a resource (e.g. an IBC channel) by name, then pass it to `mod2` which will use it later: + +Module 1 would have the following code: + +```go +capability := scopedCapabilityKeeper.NewCapability(ctx, "resourceABC") +mod2Keeper.SomeFunction(ctx, capability, args...) +``` + +`SomeFunction`, running in module 2, could then claim the capability: + +```go +func (k Mod2Keeper) SomeFunction(ctx Context, capability Capability) { + k.sck.ClaimCapability(ctx, capability, "resourceABC") + // other logic... +} +``` + +Later on, module 2 can retrieve that capability by name and pass it to module 1, which will authenticate it against the resource: + +```go +func (k Mod2Keeper) SomeOtherFunction(ctx Context, name string) { + capability := k.sck.GetCapability(ctx, name) + mod1.UseResource(ctx, capability, "resourceABC") +} +``` + +Module 1 will then check that this capability key is authenticated to use the resource before allowing module 2 to use it: + +```go +func (k Mod1Keeper) UseResource(ctx Context, capability Capability, resource string) { + if !k.sck.AuthenticateCapability(name, capability) { + return errors.New("unauthenticated") + } + // do something with the resource +} +``` + +If module 2 passed the capability key to module 3, module 3 could then claim it and call module 1 just like module 2 did +(in which case module 1, module 2, and module 3 would all be able to use this capability). + +## Status + +Proposed. + +## Consequences + +### Positive + +* Dynamic capability support. +* Allows CapabilityKeeper to return same capability pointer from go-map while reverting any writes to the persistent `KVStore` and in-memory `MemoryStore` on tx failure. + +### Negative + +* Requires an additional keeper. +* Some overlap with existing `StoreKey` system (in the future they could be combined, since this is a superset functionality-wise). +* Requires an extra level of indirection in the reverse mapping, since MemoryStore must map to index which must then be used as key in a go map to retrieve the actual capability + +### Neutral + +(none known) + +## References + +* [Original discussion](https://github.com/cosmos/cosmos-sdk/pull/5230#discussion_r343978513) diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-004-split-denomination-keys.md b/versioned_docs/version-0.47/integrate/architecture/adr-004-split-denomination-keys.md new file mode 100644 index 000000000..8abf25fda --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-004-split-denomination-keys.md @@ -0,0 +1,120 @@ +# ADR 004: Split Denomination Keys + +## Changelog + +* 2020-01-08: Initial version +* 2020-01-09: Alterations to handle vesting accounts +* 2020-01-14: Updates from review feedback +* 2020-01-30: Updates from implementation + +### Glossary + +* denom / denomination key -- unique token identifier. + +## Context + +With permissionless IBC, anyone will be able to send arbitrary denominations to any other account. Currently, all non-zero balances are stored along with the account in an `sdk.Coins` struct, which creates a potential denial-of-service concern, as too many denominations will become expensive to load & store each time the account is modified. See issues [5467](https://github.com/cosmos/cosmos-sdk/issues/5467) and [4982](https://github.com/cosmos/cosmos-sdk/issues/4982) for additional context. + +Simply rejecting incoming deposits after a denomination count limit doesn't work, since it opens up a griefing vector: someone could send a user lots of nonsensical coins over IBC, and then prevent the user from receiving real denominations (such as staking rewards). + +## Decision + +Balances shall be stored per-account & per-denomination under a denomination- and account-unique key, thus enabling O(1) read & write access to the balance of a particular account in a particular denomination. + +### Account interface (x/auth) + +`GetCoins()` and `SetCoins()` will be removed from the account interface, since coin balances will +now be stored in & managed by the bank module. + +The vesting account interface will replace `SpendableCoins` in favor of `LockedCoins` which does +not require the account balance anymore. In addition, `TrackDelegation()` will now accept the +account balance of all tokens denominated in the vesting balance instead of loading the entire +account balance. + +Vesting accounts will continue to store original vesting, delegated free, and delegated +vesting coins (which is safe since these cannot contain arbitrary denominations). + +### Bank keeper (x/bank) + +The following APIs will be added to the `x/bank` keeper: + +* `GetAllBalances(ctx Context, addr AccAddress) Coins` +* `GetBalance(ctx Context, addr AccAddress, denom string) Coin` +* `SetBalance(ctx Context, addr AccAddress, coin Coin)` +* `LockedCoins(ctx Context, addr AccAddress) Coins` +* `SpendableCoins(ctx Context, addr AccAddress) Coins` + +Additional APIs may be added to facilitate iteration and auxiliary functionality not essential to +core functionality or persistence. + +Balances will be stored first by the address, then by the denomination (the reverse is also possible, +but retrieval of all balances for a single account is presumed to be more frequent): + +```go +var BalancesPrefix = []byte("balances") + +func (k Keeper) SetBalance(ctx Context, addr AccAddress, balance Coin) error { + if !balance.IsValid() { + return err + } + + store := ctx.KVStore(k.storeKey) + balancesStore := prefix.NewStore(store, BalancesPrefix) + accountStore := prefix.NewStore(balancesStore, addr.Bytes()) + + bz := Marshal(balance) + accountStore.Set([]byte(balance.Denom), bz) + + return nil +} +``` + +This will result in the balances being indexed by the byte representation of +`balances/{address}/{denom}`. + +`DelegateCoins()` and `UndelegateCoins()` will be altered to only load each individual +account balance by denomination found in the (un)delegation amount. As a result, +any mutations to the account balance by will made by denomination. + +`SubtractCoins()` and `AddCoins()` will be altered to read & write the balances +directly instead of calling `GetCoins()` / `SetCoins()` (which no longer exist). + +`trackDelegation()` and `trackUndelegation()` will be altered to no longer update +account balances. + +External APIs will need to scan all balances under an account to retain backwards-compatibility. It +is advised that these APIs use `GetBalance` and `SetBalance` instead of `GetAllBalances` when +possible as to not load the entire account balance. + +### Supply module + +The supply module, in order to implement the total supply invariant, will now need +to scan all accounts & call `GetAllBalances` using the `x/bank` Keeper, then sum +the balances and check that they match the expected total supply. + +## Status + +Accepted. + +## Consequences + +### Positive + +* O(1) reads & writes of balances (with respect to the number of denominations for +which an account has non-zero balances). Note, this does not relate to the actual +I/O cost, rather the total number of direct reads needed. + +### Negative + +* Slightly less efficient reads/writes when reading & writing all balances of a +single account in a transaction. + +### Neutral + +None in particular. + +## References + +* Ref: https://github.com/cosmos/cosmos-sdk/issues/4982 +* Ref: https://github.com/cosmos/cosmos-sdk/issues/5467 +* Ref: https://github.com/cosmos/cosmos-sdk/issues/5492 diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-006-secret-store-replacement.md b/versioned_docs/version-0.47/integrate/architecture/adr-006-secret-store-replacement.md new file mode 100644 index 000000000..fe2e25467 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-006-secret-store-replacement.md @@ -0,0 +1,54 @@ +# ADR 006: Secret Store Replacement + +## 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 + +## 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. + +This is not desirable for a number of reasons. Perhaps the biggest reason is insufficient security protection of key material and metadata. Leaking the plain text allows an attacker to surveil what keys a given computer controls via a number of techniques, like compromised dependencies without any privilege execution. This could be followed by a more targeted attack on a particular user/computer. + +All modern desktop computers OS (Ubuntu, Debian, MacOS, Windows) provide a built-in secret store that is designed to allow applications to store information that is isolated from all other applications and requires passphrase entry to access the data. + +We are seeking solution that provides a common abstraction layer to the many different backends and reasonable fallback for minimal platforms that don’t provide a native secret store. + +## Decision + +We recommend replacing the current Keybase backend based on LevelDB with [Keyring](https://github.com/99designs/keyring) by 99 designs. This application is designed to provide a common abstraction and uniform interface between many secret stores and is used by AWS Vault application by 99-designs application. + +This appears to fulfill the requirement of protecting both key material and metadata from rouge software on a user’s machine. + +## Status + +Accepted + +## Consequences + +### Positive + +Increased safety for users. + +### Negative + +Users must manually migrate. + +Testing against all supported backends is difficult. + +Running tests locally on a Mac require numerous repetitive password entries. + +### Neutral + +{neutral consequences} + +## References + +* #4754 Switch secret store to the keyring secret store (original PR by @poldsam) [__CLOSED__] +* #5029 Add support for github.com/99designs/keyring-backed keybases [__MERGED__] +* #5097 Add keys migrate command [__MERGED__] +* #5180 Drop on-disk keybase in favor of keyring [_PENDING_REVIEW_] +* cosmos/gaia#164 Drop on-disk keybase in favor of keyring (gaia's changes) [_PENDING_REVIEW_] diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-007-specialization-groups.md b/versioned_docs/version-0.47/integrate/architecture/adr-007-specialization-groups.md new file mode 100644 index 000000000..58f78abf5 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-007-specialization-groups.md @@ -0,0 +1,177 @@ +# ADR 007: Specialization Groups + +## Changelog + +* 2019 Jul 31: Initial Draft + +## Context + +This idea was first conceived of in order to fulfill the use case of the +creation of a decentralized Computer Emergency Response Team (dCERT), whose +members would be elected by a governing community and would fulfill the role of +coordinating the community under emergency situations. This thinking +can be further abstracted into the conception of "blockchain specialization +groups". + +The creation of these groups are the beginning of specialization capabilities +within a wider blockchain community which could be used to enable a certain +level of delegated responsibilities. Examples of specialization which could be +beneficial to a blockchain community include: code auditing, emergency response, +code development etc. This type of community organization paves the way for +individual stakeholders to delegate votes by issue type, if in the future +governance proposals include a field for issue type. + +## Decision + +A specialization group can be broadly broken down into the following functions +(herein containing examples): + +* Membership Admittance +* Membership Acceptance +* Membership Revocation + * (probably) Without Penalty + * member steps down (self-Revocation) + * replaced by new member from governance + * (probably) With Penalty + * due to breach of soft-agreement (determined through governance) + * due to breach of hard-agreement (determined by code) +* Execution of Duties + * Special transactions which only execute for members of a specialization + group (for example, dCERT members voting to turn off transaction routes in + an emergency scenario) +* Compensation + * Group compensation (further distribution decided by the specialization group) + * Individual compensation for all constituents of a group from the + greater community + +Membership admittance to a specialization group could take place over a wide +variety of mechanisms. The most obvious example is through a general vote among +the entire community, however in certain systems a community may want to allow +the members already in a specialization group to internally elect new members, +or maybe the community may assign a permission to a particular specialization +group to appoint members to other 3rd party groups. The sky is really the limit +as to how membership admittance can be structured. We attempt to capture +some of these possiblities in a common interface dubbed the `Electionator`. For +its initial implementation as a part of this ADR we recommend that the general +election abstraction (`Electionator`) is provided as well as a basic +implementation of that abstraction which allows for a continuous election of +members of a specialization group. + +``` golang +// The Electionator abstraction covers the concept space for +// a wide variety of election kinds. +type Electionator interface { + + // is the election object accepting votes. + Active() bool + + // functionality to execute for when a vote is cast in this election, here + // the vote field is anticipated to be marshalled into a vote type used + // by an election. + // + // NOTE There are no explicit ids here. Just votes which pertain specifically + // to one electionator. Anyone can create and send a vote to the electionator item + // which will presumably attempt to marshal those bytes into a particular struct + // and apply the vote information in some arbitrary way. There can be multiple + // Electionators within the Cosmos-Hub for multiple specialization groups, votes + // would need to be routed to the Electionator upstream of here. + Vote(addr sdk.AccAddress, vote []byte) + + // here lies all functionality to authenticate and execute changes for + // when a member accepts being elected + AcceptElection(sdk.AccAddress) + + // Register a revoker object + RegisterRevoker(Revoker) + + // No more revokers may be registered after this function is called + SealRevokers() + + // register hooks to call when an election actions occur + RegisterHooks(ElectionatorHooks) + + // query for the current winner(s) of this election based on arbitrary + // election ruleset + QueryElected() []sdk.AccAddress + + // query metadata for an address in the election this + // could include for example position that an address + // is being elected for within a group + // + // this metadata may be directly related to + // voting information and/or privileges enabled + // to members within a group. + QueryMetadata(sdk.AccAddress) []byte +} + +// ElectionatorHooks, once registered with an Electionator, +// trigger execution of relevant interface functions when +// Electionator events occur. +type ElectionatorHooks interface { + AfterVoteCast(addr sdk.AccAddress, vote []byte) + AfterMemberAccepted(addr sdk.AccAddress) + AfterMemberRevoked(addr sdk.AccAddress, cause []byte) +} + +// Revoker defines the function required for a membership revocation rule-set +// used by a specialization group. This could be used to create self revoking, +// and evidence based revoking, etc. Revokers types may be created and +// reused for different election types. +// +// When revoking the "cause" bytes may be arbitrarily marshalled into evidence, +// memos, etc. +type Revoker interface { + RevokeName() string // identifier for this revoker type + RevokeMember(addr sdk.AccAddress, cause []byte) error +} +``` + +Certain level of commonality likely exists between the existing code within +`x/governance` and required functionality of elections. This common +functionality should be abstracted during implementation. Similarly for each +vote implementation client CLI/REST functionality should be abstracted +to be reused for multiple elections. + +The specialization group abstraction firstly extends the `Electionator` +but also further defines traits of the group. + +``` golang +type SpecializationGroup interface { + Electionator + GetName() string + GetDescription() string + + // general soft contract the group is expected + // to fulfill with the greater community + GetContract() string + + // messages which can be executed by the members of the group + Handler(ctx sdk.Context, msg sdk.Msg) sdk.Result + + // logic to be executed at endblock, this may for instance + // include payment of a stipend to the group members + // for participation in the security group. + EndBlocker(ctx sdk.Context) +} +``` + +## Status + +> Proposed + +## Consequences + +### Positive + +* increases specialization capabilities of a blockchain +* improve abstractions in `x/gov/` such that they can be used with specialization groups + +### Negative + +* could be used to increase centralization within a community + +### Neutral + +## References + +* [dCERT ADR](./adr-008-dCERT-group.md) diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-008-dCERT-group.md b/versioned_docs/version-0.47/integrate/architecture/adr-008-dCERT-group.md new file mode 100644 index 000000000..2b2d2b826 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-008-dCERT-group.md @@ -0,0 +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) diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-009-evidence-module.md b/versioned_docs/version-0.47/integrate/architecture/adr-009-evidence-module.md new file mode 100644 index 000000000..ded04a142 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-009-evidence-module.md @@ -0,0 +1,182 @@ +# ADR 009: Evidence Module + +## Changelog + +* 2019 July 31: Initial draft +* 2019 October 24: Initial implementation + +## Status + +Accepted + +## Context + +In order to support building highly secure, robust and interoperable blockchain +applications, it is vital for the Cosmos SDK to expose a mechanism in which arbitrary +evidence can be submitted, evaluated and verified resulting in some agreed upon +penalty for any misbehavior committed by a validator, such as equivocation (double-voting), +signing when unbonded, signing an incorrect state transition (in the future), etc. +Furthermore, such a mechanism is paramount for any +[IBC](https://github.com/cosmos/ics/blob/master/ibc/2_IBC_ARCHITECTURE.md) or +cross-chain validation protocol implementation in order to support the ability +for any misbehavior to be relayed back from a collateralized chain to a primary +chain so that the equivocating validator(s) can be slashed. + +## Decision + +We will implement an evidence module in the Cosmos SDK supporting the following +functionality: + +* Provide developers with the abstractions and interfaces necessary to define + custom evidence messages, message handlers, and methods to slash and penalize + accordingly for misbehavior. +* Support the ability to route evidence messages to handlers in any module to + determine the validity of submitted misbehavior. +* Support the ability, through governance, to modify slashing penalties of any + evidence type. +* Querier implementation to support querying params, evidence types, params, and + all submitted valid misbehavior. + +### Types + +First, we define the `Evidence` interface type. The `x/evidence` module may implement +its own types that can be used by many chains (e.g. `CounterFactualEvidence`). +In addition, other modules may implement their own `Evidence` types in a similar +manner in which governance is extensible. It is important to note any concrete +type implementing the `Evidence` interface may include arbitrary fields such as +an infraction time. We want the `Evidence` type to remain as flexible as possible. + +When submitting evidence to the `x/evidence` module, the concrete type must provide +the validator's consensus address, which should be known by the `x/slashing` +module (assuming the infraction is valid), the height at which the infraction +occurred and the validator's power at same height in which the infraction occurred. + +```go +type Evidence interface { + Route() string + Type() string + String() string + Hash() HexBytes + ValidateBasic() error + + // The consensus address of the malicious validator at time of infraction + GetConsensusAddress() ConsAddress + + // Height at which the infraction occurred + GetHeight() int64 + + // The total power of the malicious validator at time of infraction + GetValidatorPower() int64 + + // The total validator set power at time of infraction + GetTotalPower() int64 +} +``` + +### Routing & Handling + +Each `Evidence` type must map to a specific unique route and be registered with +the `x/evidence` module. It accomplishes this through the `Router` implementation. + +```go +type Router interface { + AddRoute(r string, h Handler) Router + HasRoute(r string) bool + GetRoute(path string) Handler + Seal() +} +``` + +Upon successful routing through the `x/evidence` module, the `Evidence` type +is passed through a `Handler`. This `Handler` is responsible for executing all +corresponding business logic necessary for verifying the evidence as valid. In +addition, the `Handler` may execute any necessary slashing and potential jailing. +Since slashing fractions will typically result from some form of static functions, +allow the `Handler` to do this provides the greatest flexibility. An example could +be `k * evidence.GetValidatorPower()` where `k` is an on-chain parameter controlled +by governance. The `Evidence` type should provide all the external information +necessary in order for the `Handler` to make the necessary state transitions. +If no error is returned, the `Evidence` is considered valid. + +```go +type Handler func(Context, Evidence) error +``` + +### Submission + +`Evidence` is submitted through a `MsgSubmitEvidence` message type which is internally +handled by the `x/evidence` module's `SubmitEvidence`. + +```go +type MsgSubmitEvidence struct { + Evidence +} + +func handleMsgSubmitEvidence(ctx Context, keeper Keeper, msg MsgSubmitEvidence) Result { + if err := keeper.SubmitEvidence(ctx, msg.Evidence); err != nil { + return err.Result() + } + + // emit events... + + return Result{ + // ... + } +} +``` + +The `x/evidence` module's keeper is responsible for matching the `Evidence` against +the module's router and invoking the corresponding `Handler` which may include +slashing and jailing the validator. Upon success, the submitted evidence is persisted. + +```go +func (k Keeper) SubmitEvidence(ctx Context, evidence Evidence) error { + handler := keeper.router.GetRoute(evidence.Route()) + if err := handler(ctx, evidence); err != nil { + return ErrInvalidEvidence(keeper.codespace, err) + } + + keeper.setEvidence(ctx, evidence) + return nil +} +``` + +### Genesis + +Finally, we need to represent the genesis state of the `x/evidence` module. The +module only needs a list of all submitted valid infractions and any necessary params +for which the module needs in order to handle submitted evidence. The `x/evidence` +module will naturally define and route native evidence types for which it'll most +likely need slashing penalty constants for. + +```go +type GenesisState struct { + Params Params + Infractions []Evidence +} +``` + +## Consequences + +### Positive + +* Allows the state machine to process misbehavior submitted on-chain and penalize + validators based on agreed upon slashing parameters. +* Allows evidence types to be defined and handled by any module. This further allows + slashing and jailing to be defined by more complex mechanisms. +* Does not solely rely on Tendermint to submit evidence. + +### Negative + +* No easy way to introduce new evidence types through governance on a live chain + due to the inability to introduce the new evidence type's corresponding handler + +### Neutral + +* Should we persist infractions indefinitely? Or should we rather rely on events? + +## References + +* [ICS](https://github.com/cosmos/ics) +* [IBC Architecture](https://github.com/cosmos/ics/blob/master/ibc/1_IBC_ARCHITECTURE.md) +* [Tendermint Fork Accountability](https://github.com/tendermint/spec/blob/7b3138e69490f410768d9b1ffc7a17abc23ea397/spec/consensus/fork-accountability.md) diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-010-modular-antehandler.md b/versioned_docs/version-0.47/integrate/architecture/adr-010-modular-antehandler.md new file mode 100644 index 000000000..386af1a77 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-010-modular-antehandler.md @@ -0,0 +1,290 @@ +# ADR 010: Modular AnteHandler + +## Changelog + +* 2019 Aug 31: Initial draft +* 2021 Sep 14: Superseded by ADR-045 + +## Status + +SUPERSEDED by 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. + +For example, let's say a user wants to implement some custom signature verification logic. In the current codebase, the user would have to write their own Antehandler from scratch largely reimplementing much of the same code and then set their own custom, monolithic antehandler in the baseapp. Instead, we would like to allow users to specify custom behavior when necessary and combine them with default ante-handler functionality in a way that is as modular and flexible as possible. + +## Proposals + +### Per-Module AnteHandler + +One approach is to use the [ModuleManager](https://pkg.go.dev/github.com/cosmos/cosmos-sdk/types/module) and have each module implement its own antehandler if it requires custom antehandler logic. The ModuleManager can then be passed in an AnteHandler order in the same way it has an order for BeginBlockers and EndBlockers. The ModuleManager returns a single AnteHandler function that will take in a tx and run each module's `AnteHandle` in the specified order. The module manager's AnteHandler is set as the baseapp's AnteHandler. + +Pros: + +1. Simple to implement +2. Utilizes the existing ModuleManager architecture + +Cons: + +1. Improves granularity but still cannot get more granular than a per-module basis. e.g. If auth's `AnteHandle` function is in charge of validating memo and signatures, users cannot swap the signature-checking functionality while keeping the rest of auth's `AnteHandle` functionality. +2. Module AnteHandler are run one after the other. There is no way for one AnteHandler to wrap or "decorate" another. + +### Decorator Pattern + +The [weave project](https://github.com/iov-one/weave) achieves AnteHandler modularity through the use of a decorator pattern. The interface is designed as follows: + +```go +// Decorator wraps a Handler to provide common functionality +// like authentication, or fee-handling, to many Handlers +type Decorator interface { + Check(ctx Context, store KVStore, tx Tx, next Checker) (*CheckResult, error) + Deliver(ctx Context, store KVStore, tx Tx, next Deliverer) (*DeliverResult, error) +} +``` + +Each decorator works like a modularized 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. + +A key benefit of this approach is that one Decorator can wrap its internal logic around the next Checker/Deliverer. A weave Decorator may do the following: + +```go +// Example Decorator's Deliver function +func (example Decorator) Deliver(ctx Context, store KVStore, tx Tx, next Deliverer) { + // Do some pre-processing logic + + res, err := next.Deliver(ctx, store, tx) + + // Do some post-processing logic given the result and error +} +``` + +Pros: + +1. Weave Decorators can wrap over the next decorator/handler in the chain. The ability to both pre-process and post-process may be useful in certain settings. +2. Provides a nested modular structure that isn't possible in the solution above, while also allowing for a linear one-after-the-other structure like the solution above. + +Cons: + +1. It is hard to understand at first glance the state updates that would occur after a Decorator runs given the `ctx`, `store`, and `tx`. A Decorator can have an arbitrary number of nested Decorators being called within its function body, each possibly doing some pre- and post-processing before calling the next decorator on the chain. Thus to understand what a Decorator is doing, one must also understand what every other decorator further along the chain is also doing. This can get quite complicated to understand. A linear, one-after-the-other approach while less powerful, may be much easier to reason about. + +### Chained Micro-Functions + +The benefit of Weave's approach is that the Decorators can be very concise, which when chained together allows for maximum customizability. However, the nested structure can get quite complex and thus hard to reason about. + +Another approach is to split the AnteHandler functionality into tightly scoped "micro-functions", while preserving the one-after-the-other ordering that would come from the ModuleManager approach. + +We can then have a way to chain these micro-functions so that they run one after the other. Modules may define multiple ante micro-functions and then also provide a default per-module AnteHandler that implements a default, suggested order for these micro-functions. + +Users can order the AnteHandlers easily by simply using the ModuleManager. The ModuleManager will take in a list of AnteHandlers and return a single AnteHandler that runs each AnteHandler in the order of the list provided. If the user is comfortable with the default ordering of each module, this is as simple as providing a list with each module's antehandler (exactly the same as BeginBlocker and EndBlocker). + +If however, users wish to change the order or add, modify, or delete ante micro-functions in anyway; they can always define their own ante micro-functions and add them explicitly to the list that gets passed into module manager. + +#### Default Workflow + +This is an example of a user's AnteHandler if they choose not to make any custom micro-functions. + +##### Cosmos SDK code + +```go +// Chains together a list of AnteHandler micro-functions that get run one after the other. +// Returned AnteHandler will abort on first error. +func Chainer(order []AnteHandler) AnteHandler { + return func(ctx Context, tx Tx, simulate bool) (newCtx Context, err error) { + for _, ante := range order { + ctx, err := ante(ctx, tx, simulate) + if err != nil { + return ctx, err + } + } + return ctx, err + } +} +``` + +```go +// AnteHandler micro-function to verify signatures +func VerifySignatures(ctx Context, tx Tx, simulate bool) (newCtx Context, err error) { + // verify signatures + // Returns InvalidSignature Result and abort=true if sigs invalid + // Return OK result and abort=false if sigs are valid +} + +// AnteHandler micro-function to validate memo +func ValidateMemo(ctx Context, tx Tx, simulate bool) (newCtx Context, err error) { + // validate memo +} + +// Auth defines its own default ante-handler by chaining its micro-functions in a recommended order +AuthModuleAnteHandler := Chainer([]AnteHandler{VerifySignatures, ValidateMemo}) +``` + +```go +// Distribution micro-function to deduct fees from tx +func DeductFees(ctx Context, tx Tx, simulate bool) (newCtx Context, err error) { + // Deduct fees from tx + // Abort if insufficient funds in account to pay for fees +} + +// Distribution micro-function to check if fees > mempool parameter +func CheckMempoolFees(ctx Context, tx Tx, simulate bool) (newCtx Context, err error) { + // If CheckTx: Abort if the fees are less than the mempool's minFee parameter +} + +// Distribution defines its own default ante-handler by chaining its micro-functions in a recommended order +DistrModuleAnteHandler := Chainer([]AnteHandler{CheckMempoolFees, DeductFees}) +``` + +```go +type ModuleManager struct { + // other fields + AnteHandlerOrder []AnteHandler +} + +func (mm ModuleManager) GetAnteHandler() AnteHandler { + retun Chainer(mm.AnteHandlerOrder) +} +``` + +##### User Code + +```go +// Note: Since user is not making any custom modifications, we can just SetAnteHandlerOrder with the default AnteHandlers provided by each module in our preferred order +moduleManager.SetAnteHandlerOrder([]AnteHandler(AuthModuleAnteHandler, DistrModuleAnteHandler)) + +app.SetAnteHandler(mm.GetAnteHandler()) +``` + +#### Custom Workflow + +This is an example workflow for a user that wants to implement custom antehandler logic. In this example, the user wants to implement custom signature verification and change the order of antehandler so that validate memo runs before signature verification. + +##### User Code + +```go +// User can implement their own custom signature verification antehandler micro-function +func CustomSigVerify(ctx Context, tx Tx, simulate bool) (newCtx Context, err error) { + // do some custom signature verification logic +} +``` + +```go +// Micro-functions allow users to change order of when they get executed, and swap out default ante-functionality with their own custom logic. +// Note that users can still chain the default distribution module handler, and auth micro-function along with their custom ante function +moduleManager.SetAnteHandlerOrder([]AnteHandler(ValidateMemo, CustomSigVerify, DistrModuleAnteHandler)) +``` + +Pros: + +1. Allows for ante functionality to be as modular as possible. +2. For users that do not need custom ante-functionality, there is little difference between how antehandlers work and how BeginBlock and EndBlock work in ModuleManager. +3. Still easy to understand + +Cons: + +1. Cannot wrap antehandlers with decorators like you can with Weave. + +### Simple Decorators + +This approach takes inspiration from Weave's decorator design while trying to minimize the number of breaking changes to the 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`. + +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. + +Allow Decorator interface that can be chained together to create a Cosmos SDK AnteHandler. + +This allows users to choose between implementing an AnteHandler by themselves and setting it in the baseapp, or use the decorator pattern to chain their custom decorators with the Cosmos SDK provided decorators in the order they wish. + +```go +// An AnteDecorator wraps an AnteHandler, and can do pre- and post-processing on the next AnteHandler +type AnteDecorator interface { + AnteHandle(ctx Context, tx Tx, simulate bool, next AnteHandler) (newCtx Context, err error) +} +``` + +```go +// ChainAnteDecorators will recursively link all of the AnteDecorators in the chain and return a final AnteHandler function +// This is done to preserve the ability to set a single AnteHandler function in the baseapp. +func ChainAnteDecorators(chain ...AnteDecorator) AnteHandler { + if len(chain) == 1 { + return func(ctx Context, tx Tx, simulate bool) { + chain[0].AnteHandle(ctx, tx, simulate, nil) + } + } + return func(ctx Context, tx Tx, simulate bool) { + chain[0].AnteHandle(ctx, tx, simulate, ChainAnteDecorators(chain[1:])) + } +} +``` + +#### Example Code + +Define AnteDecorator functions + +```go +// Setup GasMeter, catch OutOfGasPanic and handle appropriately +type SetUpContextDecorator struct{} + +func (sud SetUpContextDecorator) AnteHandle(ctx Context, tx Tx, simulate bool, next AnteHandler) (newCtx Context, err error) { + ctx.GasMeter = NewGasMeter(tx.Gas) + + defer func() { + // recover from OutOfGas panic and handle appropriately + } + + return next(ctx, tx, simulate) +} + +// Signature Verification decorator. Verify Signatures and move on +type SigVerifyDecorator struct{} + +func (svd SigVerifyDecorator) AnteHandle(ctx Context, tx Tx, simulate bool, next AnteHandler) (newCtx Context, err error) { + // verify sigs. Return error if invalid + + // call next antehandler if sigs ok + return next(ctx, tx, simulate) +} + +// User-defined Decorator. Can choose to pre- and post-process on AnteHandler +type UserDefinedDecorator struct{ + // custom fields +} + +func (udd UserDefinedDecorator) AnteHandle(ctx Context, tx Tx, simulate bool, next AnteHandler) (newCtx Context, err error) { + // pre-processing logic + + ctx, err = next(ctx, tx, simulate) + + // post-processing logic +} +``` + +Link AnteDecorators to create a final AnteHandler. Set this AnteHandler in baseapp. + +```go +// Create final antehandler by chaining the decorators together +antehandler := ChainAnteDecorators(NewSetUpContextDecorator(), NewSigVerifyDecorator(), NewUserDefinedDecorator()) + +// Set chained Antehandler in the baseapp +bapp.SetAnteHandler(antehandler) +``` + +Pros: + +1. Allows one decorator to pre- and post-process the next AnteHandler, similar to the Weave design. +2. Do not need to break baseapp API. Users can still set a single AnteHandler if they choose. + +Cons: + +1. Decorator pattern may have a deeply nested structure that is hard to understand, this is mitigated by having the decorator order explicitly listed in the `ChainAnteDecorators` function. +2. Does not make use of the ModuleManager design. Since this is already being used for BeginBlocker/EndBlocker, this proposal seems unaligned with that design pattern. + +## Consequences + +Since pros and cons are written for each approach, it is omitted from this section + +## References + +* [#4572](https://github.com/cosmos/cosmos-sdk/issues/4572): Modular AnteHandler Issue +* [#4582](https://github.com/cosmos/cosmos-sdk/pull/4583): Initial Implementation of Per-Module AnteHandler Approach +* [Weave Decorator Code](https://github.com/iov-one/weave/blob/master/handler.go#L35) +* [Weave Design Videos](https://vimeo.com/showcase/6189877) diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-011-generalize-genesis-accounts.md b/versioned_docs/version-0.47/integrate/architecture/adr-011-generalize-genesis-accounts.md new file mode 100644 index 000000000..92a704ba6 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-011-generalize-genesis-accounts.md @@ -0,0 +1,170 @@ +# ADR 011: Generalize Genesis Accounts + +## Changelog + +* 2019-08-30: initial draft + +## 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`). + +Projects desiring to use custom accounts (say custom vesting accounts) need to fork and modify `genaccounts`. + +## Decision + +In summary, we will (un)marshal all accounts (interface types) directly using amino, rather than converting to `genaccounts`’s `GenesisAccount` type. Since doing this removes the majority of `genaccounts`'s code, we will merge `genaccounts` into `auth`. Marshalled accounts will be stored in `auth`'s genesis state. + +Detailed changes: + +### 1) (Un)Marshal accounts directly using amino + +The `auth` module's `GenesisState` gains a new field `Accounts`. Note these aren't of type `exported.Account` for reasons outlined in section 3. + +```go +// GenesisState - all auth state that must be provided at genesis +type GenesisState struct { + Params Params `json:"params" yaml:"params"` + Accounts []GenesisAccount `json:"accounts" yaml:"accounts"` +} +``` + +Now `auth`'s `InitGenesis` and `ExportGenesis` (un)marshal accounts as well as the defined params. + +```go +// InitGenesis - Init store state from genesis data +func InitGenesis(ctx sdk.Context, ak AccountKeeper, data GenesisState) { + ak.SetParams(ctx, data.Params) + // load the accounts + for _, a := range data.Accounts { + acc := ak.NewAccount(ctx, a) // set account number + ak.SetAccount(ctx, acc) + } +} + +// ExportGenesis returns a GenesisState for a given context and keeper +func ExportGenesis(ctx sdk.Context, ak AccountKeeper) GenesisState { + params := ak.GetParams(ctx) + + var genAccounts []exported.GenesisAccount + ak.IterateAccounts(ctx, func(account exported.Account) bool { + genAccount := account.(exported.GenesisAccount) + genAccounts = append(genAccounts, genAccount) + return false + }) + + return NewGenesisState(params, genAccounts) +} +``` + +### 2) Register custom account types on the `auth` codec + +The `auth` codec must have all custom account types registered to marshal them. We will follow the pattern established in `gov` for proposals. + +An example custom account definition: + +```go +import authtypes "github.com/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 +func init() { + authtypes.RegisterAccountTypeCodec(ModuleAccount{}, "cosmos-sdk/ModuleAccount") +} + +type ModuleAccount struct { + ... +``` + +The `auth` codec definition: + +```go +var ModuleCdc *codec.LegacyAmino + +func init() { + ModuleCdc = codec.NewLegacyAmino() + // register module msg's and Account interface + ... + // leave the codec unsealed +} + +// RegisterAccountTypeCodec registers an external account type defined in another module for the internal ModuleCdc. +func RegisterAccountTypeCodec(o interface{}, name string) { + ModuleCdc.RegisterConcrete(o, name, nil) +} +``` + +### 3) Genesis validation for custom account types + +Modules implement a `ValidateGenesis` method. As `auth` does not know of account implementations, accounts will need to validate themselves. + +We will unmarshal accounts into a `GenesisAccount` interface that includes a `Validate` method. + +```go +type GenesisAccount interface { + exported.Account + Validate() error +} +``` + +Then the `auth` `ValidateGenesis` function becomes: + +```go +// ValidateGenesis performs basic validation of auth genesis data returning an +// error for any failed validation criteria. +func ValidateGenesis(data GenesisState) error { + // Validate params + ... + + // Validate accounts + addrMap := make(map[string]bool, len(data.Accounts)) + for _, acc := range data.Accounts { + + // check for duplicated accounts + addrStr := acc.GetAddress().String() + if _, ok := addrMap[addrStr]; ok { + return fmt.Errorf("duplicate account found in genesis state; address: %s", addrStr) + } + addrMap[addrStr] = true + + // check account specific validation + if err := acc.Validate(); err != nil { + return fmt.Errorf("invalid account found in genesis state; address: %s, error: %s", addrStr, err.Error()) + } + + } + return nil +} +``` + +### 4) Move add-genesis-account cli to `auth` + +The `genaccounts` module contains a cli command to add base or vesting accounts to a genesis file. + +This will be moved to `auth`. We will leave it to projects to write their own commands to add custom accounts. An extensible cli handler, similar to `gov`, could be created but it is not worth the complexity for this minor use case. + +### 5) Update module and vesting accounts + +Under the new scheme, module and vesting account types need some minor updates: + +* Type registration on `auth`'s codec (shown above) +* A `Validate` method for each `Account` concrete type + +## Status + +Proposed + +## Consequences + +### Positive + +* custom accounts can be used without needing to fork `genaccounts` +* reduction in lines of code + +### Negative + +### Neutral + +* `genaccounts` module no longer exists +* accounts in genesis files are stored under `accounts` in `auth` rather than in the `genaccounts` module. +-`add-genesis-account` cli command now in `auth` + +## References diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-012-state-accessors.md b/versioned_docs/version-0.47/integrate/architecture/adr-012-state-accessors.md new file mode 100644 index 000000000..93600000f --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-012-state-accessors.md @@ -0,0 +1,155 @@ +# ADR 012: State Accessors + +## Changelog + +* 2019 Sep 04: Initial draft + +## 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. + +First, each time a module tries to access the state, it has to marshal the value and set or get the +value and finally unmarshal. Usually this is done by declaring `Keeper.GetXXX` and `Keeper.SetXXX` functions, +which are repetitive and hard to maintain. + +Second, this makes it harder to align with the object capability theorem: the right to access the +state is defined as a `StoreKey`, which gives full access on the entire Merkle tree, so a module cannot +send the access right to a specific key-value pair (or a set of key-value pairs) to another module safely. + +Finally, because the getter/setter functions are defined as methods of a module's `Keeper`, the reviewers +have to consider the whole Merkle tree space when they reviewing a function accessing any part of the state. +There is no static way to know which part of the state that the function is accessing (and which is not). + +## Decision + +We will define a type named `Value`: + +```go +type Value struct { + m Mapping + key []byte +} +``` + +The `Value` works as a reference for a key-value pair in the state, where `Value.m` defines the key-value +space it will access and `Value.key` defines the exact key for the reference. + +We will define a type named `Mapping`: + +```go +type Mapping struct { + storeKey sdk.StoreKey + cdc *codec.LegacyAmino + prefix []byte +} +``` + +The `Mapping` works as a reference for a key-value space in the state, where `Mapping.storeKey` defines +the IAVL (sub-)tree and `Mapping.prefix` defines the optional subspace prefix. + +We will define the following core methods for the `Value` type: + +```go +// Get and unmarshal stored data, noop if not exists, panic if cannot unmarshal +func (Value) Get(ctx Context, ptr interface{}) {} + +// Get and unmarshal stored data, return error if not exists or cannot unmarshal +func (Value) GetSafe(ctx Context, ptr interface{}) {} + +// Get stored data as raw byte slice +func (Value) GetRaw(ctx Context) []byte {} + +// Marshal and set a raw value +func (Value) Set(ctx Context, o interface{}) {} + +// Check if a raw value exists +func (Value) Exists(ctx Context) bool {} + +// Delete a raw value value +func (Value) Delete(ctx Context) {} +``` + +We will define the following core methods for the `Mapping` type: + +```go +// Constructs key-value pair reference corresponding to the key argument in the Mapping space +func (Mapping) Value(key []byte) Value {} + +// Get and unmarshal stored data, noop if not exists, panic if cannot unmarshal +func (Mapping) Get(ctx Context, key []byte, ptr interface{}) {} + +// Get and unmarshal stored data, return error if not exists or cannot unmarshal +func (Mapping) GetSafe(ctx Context, key []byte, ptr interface{}) + +// Get stored data as raw byte slice +func (Mapping) GetRaw(ctx Context, key []byte) []byte {} + +// Marshal and set a raw value +func (Mapping) Set(ctx Context, key []byte, o interface{}) {} + +// Check if a raw value exists +func (Mapping) Has(ctx Context, key []byte) bool {} + +// Delete a raw value value +func (Mapping) Delete(ctx Context, key []byte) {} +``` + +Each method of the `Mapping` type that is passed the arguments `ctx`, `key`, and `args...` will proxy +the call to `Mapping.Value(key)` with arguments `ctx` and `args...`. + +In addition, we will define and provide a common set of types derived from the `Value` type: + +```go +type Boolean struct { Value } +type Enum struct { Value } +type Integer struct { Value; enc IntEncoding } +type String struct { Value } +// ... +``` + +Where the encoding schemes can be different, `o` arguments in core methods are typed, and `ptr` arguments +in core methods are replaced by explicit return types. + +Finally, we will define a family of types derived from the `Mapping` type: + +```go +type Indexer struct { + m Mapping + enc IntEncoding +} +``` + +Where the `key` argument in core method is typed. + +Some of the properties of the accessor types are: + +* State access happens only when a function which takes a `Context` as an argument is invoked +* Accessor type structs give rights to access the state only that the struct is referring, no other +* Marshalling/Unmarshalling happens implicitly within the core methods + +## Status + +Proposed + +## Consequences + +### Positive + +* Serialization will be done automatically +* Shorter code size, less boilerplate, better UX +* References to the state can be transferred safely +* Explicit scope of accessing + +### Negative + +* Serialization format will be hidden +* Different architecture from the current, but the use of accessor types can be opt-in +* Type-specific types (e.g. `Boolean` and `Integer`) have to be defined manually + +### Neutral + +## References + +* [#4554](https://github.com/cosmos/cosmos-sdk/issues/4554) diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-013-metrics.md b/versioned_docs/version-0.47/integrate/architecture/adr-013-metrics.md new file mode 100644 index 000000000..33849b56c --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-013-metrics.md @@ -0,0 +1,157 @@ +# ADR 013: Observability + +## Changelog + +* 20-01-2020: Initial Draft + +## Status + +Proposed + +## Context + +Telemetry is paramount into debugging and understanding what the application is doing and how it is +performing. We aim to expose metrics from modules and other core parts of the Cosmos SDK. + +In addition, we should aim to support multiple configurable sinks that an operator may choose from. +By default, when telemetry is enabled, the application should track and expose metrics that are +stored in-memory. The operator may choose to enable additional sinks, where we support only +[Prometheus](https://prometheus.io/) for now, as it's battle-tested, simple to setup, open source, +and is rich with ecosystem tooling. + +We must also aim to integrate metrics into the Cosmos SDK in the most seamless way possible such that +metrics may be added or removed at will and without much friction. To do this, we will use the +[go-metrics](https://github.com/armon/go-metrics) library. + +Finally, operators may enable telemetry along with specific configuration options. If enabled, metrics +will be exposed via `/metrics?format={text|prometheus}` via the API server. + +## Decision + +We will add an additional configuration block to `app.toml` that defines telemetry settings: + +```toml +############################################################################### +### Telemetry Configuration ### +############################################################################### + +[telemetry] + +# Prefixed with keys to separate services +service-name = {{ .Telemetry.ServiceName }} + +# Enabled enables the application telemetry functionality. When enabled, +# an in-memory sink is also enabled by default. Operators may also enabled +# other sinks such as Prometheus. +enabled = {{ .Telemetry.Enabled }} + +# Enable prefixing gauge values with hostname +enable-hostname = {{ .Telemetry.EnableHostname }} + +# Enable adding hostname to labels +enable-hostname-label = {{ .Telemetry.EnableHostnameLabel }} + +# Enable adding service to labels +enable-service-label = {{ .Telemetry.EnableServiceLabel }} + +# PrometheusRetentionTime, when positive, enables a Prometheus metrics sink. +prometheus-retention-time = {{ .Telemetry.PrometheusRetentionTime }} +``` + +The given configuration allows for two sinks -- in-memory and Prometheus. We create a `Metrics` +type that performs all the bootstrapping for the operator, so capturing metrics becomes seamless. + +```go +// Metrics defines a wrapper around application telemetry functionality. It allows +// metrics to be gathered at any point in time. When creating a Metrics object, +// internally, a global metrics is registered with a set of sinks as configured +// by the operator. In addition to the sinks, when a process gets a SIGUSR1, a +// dump of formatted recent metrics will be sent to STDERR. +type Metrics struct { + memSink *metrics.InmemSink + prometheusEnabled bool +} + +// Gather collects all registered metrics and returns a GatherResponse where the +// metrics are encoded depending on the type. Metrics are either encoded via +// Prometheus or JSON if in-memory. +func (m *Metrics) Gather(format string) (GatherResponse, error) { + switch format { + case FormatPrometheus: + return m.gatherPrometheus() + + case FormatText: + return m.gatherGeneric() + + case FormatDefault: + return m.gatherGeneric() + + default: + return GatherResponse{}, fmt.Errorf("unsupported metrics format: %s", format) + } +} +``` + +In addition, `Metrics` allows us to gather the current set of metrics at any given point in time. An +operator may also choose to send a signal, SIGUSR1, to dump and print formatted metrics to STDERR. + +During an application's bootstrapping and construction phase, if `Telemetry.Enabled` is `true`, the +API server will create an instance of a reference to `Metrics` object and will register a metrics +handler accordingly. + +```go +func (s *Server) Start(cfg config.Config) error { + // ... + + if cfg.Telemetry.Enabled { + m, err := telemetry.New(cfg.Telemetry) + if err != nil { + return err + } + + s.metrics = m + s.registerMetrics() + } + + // ... +} + +func (s *Server) registerMetrics() { + metricsHandler := func(w http.ResponseWriter, r *http.Request) { + format := strings.TrimSpace(r.FormValue("format")) + + gr, err := s.metrics.Gather(format) + if err != nil { + rest.WriteErrorResponse(w, http.StatusBadRequest, fmt.Sprintf("failed to gather metrics: %s", err)) + return + } + + w.Header().Set("Content-Type", gr.ContentType) + _, _ = w.Write(gr.Metrics) + } + + s.Router.HandleFunc("/metrics", metricsHandler).Methods("GET") +} +``` + +Application developers may track counters, gauges, summaries, and key/value metrics. There is no +additional lifting required by modules to leverage profiling metrics. To do so, it's as simple as: + +```go +func (k BaseKeeper) MintCoins(ctx sdk.Context, moduleName string, amt sdk.Coins) error { + defer metrics.MeasureSince(time.Now(), "MintCoins") + // ... +} +``` + +## Consequences + +### Positive + +* Exposure into the performance and behavior of an application + +### Negative + +### Neutral + +## References diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-014-proportional-slashing.md b/versioned_docs/version-0.47/integrate/architecture/adr-014-proportional-slashing.md new file mode 100644 index 000000000..63cd04dee --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-014-proportional-slashing.md @@ -0,0 +1,85 @@ +# ADR 14: Proportional Slashing + +## Changelog + +* 2019-10-15: Initial draft +* 2020-05-25: Removed correlation root slashing +* 2020-07-01: Updated to include S-curve function instead of linear + +## Context + +In Proof of Stake-based chains, centralization of consensus power amongst a small set of validators can cause harm to the network due to increased risk of censorship, liveness failure, fork attacks, etc. However, while this centralization causes a negative externality to the network, it is not directly felt by the delegators contributing towards delegating towards already large validators. We would like a way to pass on the negative externality cost of centralization onto those large validators and their delegators. + +## Decision + +### Design + +To solve this problem, we will implement a procedure called Proportional Slashing. The desire is that the larger a validator is, the more they should be slashed. The first naive attempt is to make a validator's slash percent proportional to their share of consensus voting power. + +```text +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. + +```text +slash_amount = k * (power_1 + power_2 + ... + power_n) // where power_i is the voting power of the ith validator faulting in the specified time frame and k is some on-chain constant +``` + +Now, if someone splits a validator of 10% into two validators of 5% each which both fault, then they both fault in the same time frame, they both will get slashed at the sum 10% amount. + +However in practice, we likely don't want a linear relation between amount of stake at fault, and the percentage of stake to slash. In particular, solely 5% of stake double signing effectively did nothing to majorly threaten security, whereas 30% of stake being at fault clearly merits a large slashing factor, due to being very close to the point at which Tendermint security is threatened. A linear relation would require a factor of 6 gap between these two, whereas the difference in risk posed to the network is much larger. We propose using S-curves (formally [logistic functions](https://en.wikipedia.org/wiki/Logistic_function) to solve this). S-Curves capture the desired criterion quite well. They allow the slashing factor to be minimal for small values, and then grow very rapidly near some threshold point where the risk posed becomes notable. + +#### Parameterization + +This requires parameterizing a logistic function. It is very well understood how to parameterize this. It has four parameters: + +1) A minimum slashing factor +2) A maximum slashing factor +3) The inflection point of the S-curve (essentially where do you want to center the S) +4) The rate of growth of the S-curve (How elongated is the S) + +#### Correlation across non-sybil validators + +One will note, that this model doesn't differentiate between multiple validators run by the same operators vs validators run by different operators. This can be seen as an additional benefit in fact. It incentivizes validators to differentiate their setups from other validators, to avoid having correlated faults with them or else they risk a higher slash. So for example, operators should avoid using the same popular cloud hosting platforms or using the same Staking as a Service providers. This will lead to a more resilient and decentralized network. + +#### Griefing + +Griefing, the act of intentionally getting oneself slashed in order to make another's slash worse, could be a concern here. However, using the protocol described here, the attacker also gets equally impacted by the grief as the victim, so it would not provide much benefit to the griefer. + +### Implementation + +In the slashing module, we will add two queues that will track all of the recent slash events. For double sign faults, we will define "recent slashes" as ones that have occurred within the last `unbonding period`. For liveness faults, we will define "recent slashes" as ones that have occurred withing the last `jail period`. + +```go +type SlashEvent struct { + Address sdk.ValAddress + ValidatorVotingPercent sdk.Dec + SlashedSoFar sdk.Dec +} +``` + +These slash events will be pruned from the queue once they are older than their respective "recent slash period". + +Whenever a new slash occurs, a `SlashEvent` struct is created with the faulting validator's voting percent and a `SlashedSoFar` of 0. Because recent slash events are pruned before the unbonding period and unjail period expires, it should not be possible for the same validator to have multiple SlashEvents in the same Queue at the same time. + +We then will iterate over all the SlashEvents in the queue, adding their `ValidatorVotingPercent` to calculate the new percent to slash all the validators in the queue at, using the "Square of Sum of Roots" formula introduced above. + +Once we have the `NewSlashPercent`, we then iterate over all the `SlashEvent`s in the queue once again, and if `NewSlashPercent > SlashedSoFar` for that SlashEvent, we call the `staking.Slash(slashEvent.Address, slashEvent.Power, Math.Min(Math.Max(minSlashPercent, NewSlashPercent - SlashedSoFar), maxSlashPercent)` (we pass in the power of the validator before any slashes occurred, so that we slash the right amount of tokens). We then set `SlashEvent.SlashedSoFar` amount to `NewSlashPercent`. + +## Status + +Proposed + +## Consequences + +### Positive + +* Increases decentralization by disincentivizing delegating to large validators +* Incentivizes Decorrelation of Validators +* More severely punishes attacks than accidental faults +* More flexibility in slashing rates parameterization + +### Negative + +* More computationally expensive than current implementation. Will require more data about "recent slashing events" to be stored on chain. diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-016-validator-consensus-key-rotation.md b/versioned_docs/version-0.47/integrate/architecture/adr-016-validator-consensus-key-rotation.md new file mode 100644 index 000000000..0510c2b9b --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-016-validator-consensus-key-rotation.md @@ -0,0 +1,125 @@ +# ADR 016: Validator Consensus Key Rotation + +## Changelog + +* 2019 Oct 23: Initial draft +* 2019 Nov 28: Add key rotation fee + +## Context + +Validator consensus key rotation feature has been discussed and requested for a long time, for the sake of safer validator key management policy (e.g. https://github.com/tendermint/tendermint/issues/1136). So, we suggest one of the simplest form of validator consensus key rotation implementation mostly onto Cosmos SDK. + +We don't need to make any update on consensus logic in Tendermint because Tendermint does not have any mapping information of consensus key and validator operator key, meaning that from Tendermint point of view, a consensus key rotation of a validator is simply a replacement of a consensus key to another. + +Also, it should be noted that this ADR includes only the simplest form of consensus key rotation without considering multiple consensus keys concept. Such multiple consensus keys concept shall remain a long term goal of Tendermint and Cosmos SDK. + +## Decision + +### Pseudo procedure for consensus key rotation + +* create new random consensus key. +* create and broadcast a transaction with a `MsgRotateConsPubKey` that states the new consensus key is now coupled with the validator operator with signature from the validator's operator key. +* old consensus key becomes unable to participate on consensus immediately after the update of key mapping state on-chain. +* start validating with new consensus key. +* validators using HSM and KMS should update the consensus key in HSM to use the new rotated key after the height `h` when `MsgRotateConsPubKey` committed to the blockchain. + +### Considerations + +* consensus key mapping information management strategy + * store history of each key mapping changes in the kvstore. + * the state machine can search corresponding consensus key paired with given validator operator for any arbitrary height in a recent unbonding period. + * the state machine does not need any historical mapping information which is past more than unbonding period. +* key rotation costs related to LCD and IBC + * LCD and IBC will have traffic/computation burden when there exists frequent power changes + * In current Tendermint design, consensus key rotations are seen as power changes from LCD or IBC perspective + * Therefore, to minimize unnecessary frequent key rotation behavior, we limited maximum number of rotation in recent unbonding period and also applied exponentially increasing rotation fee +* limits + * a validator cannot rotate its consensus key more than `MaxConsPubKeyRotations` time for any unbonding period, to prevent spam. + * parameters can be decided by governance and stored in genesis file. +* key rotation fee + * a validator should pay `KeyRotationFee` to rotate the consensus key which is calculated as below + * `KeyRotationFee` = (max(`VotingPowerPercentage` *100, 1)* `InitialKeyRotationFee`) * 2^(number of rotations in `ConsPubKeyRotationHistory` in recent unbonding period) +* evidence module + * evidence module can search corresponding consensus key for any height from slashing keeper so that it can decide which consensus key is supposed to be used for given height. +* abci.ValidatorUpdate + * tendermint already has ability to change a consensus key by ABCI communication(`ValidatorUpdate`). + * validator consensus key update can be done via creating new + delete old by change the power to zero. + * therefore, we expect we even do not need to change tendermint codebase at all to implement this feature. +* new genesis parameters in `staking` module + * `MaxConsPubKeyRotations` : maximum number of rotation can be executed by a validator in recent unbonding period. default value 10 is suggested(11th key rotation will be rejected) + * `InitialKeyRotationFee` : the initial key rotation fee when no key rotation has happened in recent unbonding period. default value 1atom is suggested(1atom fee for the first key rotation in recent unbonding period) + +### Workflow + +1. The validator generates a new consensus keypair. +2. The validator generates and signs a `MsgRotateConsPubKey` tx with their operator key and new ConsPubKey + + ```go + type MsgRotateConsPubKey struct { + ValidatorAddress sdk.ValAddress + NewPubKey crypto.PubKey + } + ``` + +3. `handleMsgRotateConsPubKey` gets `MsgRotateConsPubKey`, calls `RotateConsPubKey` with emits event +4. `RotateConsPubKey` + * checks if `NewPubKey` is not duplicated on `ValidatorsByConsAddr` + * checks if the validator is does not exceed parameter `MaxConsPubKeyRotations` by iterating `ConsPubKeyRotationHistory` + * checks if the signing account has enough balance to pay `KeyRotationFee` + * pays `KeyRotationFee` to community fund + * overwrites `NewPubKey` in `validator.ConsPubKey` + * deletes old `ValidatorByConsAddr` + * `SetValidatorByConsAddr` for `NewPubKey` + * Add `ConsPubKeyRotationHistory` for tracking rotation + + ```go + type ConsPubKeyRotationHistory struct { + OperatorAddress sdk.ValAddress + OldConsPubKey crypto.PubKey + NewConsPubKey crypto.PubKey + RotatedHeight int64 + } + ``` + +5. `ApplyAndReturnValidatorSetUpdates` checks if there is `ConsPubKeyRotationHistory` with `ConsPubKeyRotationHistory.RotatedHeight == ctx.BlockHeight()` and if so, generates 2 `ValidatorUpdate` , one for a remove validator and one for create new validator + + ```go + abci.ValidatorUpdate{ + PubKey: tmtypes.TM2PB.PubKey(OldConsPubKey), + Power: 0, + } + + abci.ValidatorUpdate{ + PubKey: tmtypes.TM2PB.PubKey(NewConsPubKey), + Power: v.ConsensusPower(), + } + ``` + +6. at `previousVotes` Iteration logic of `AllocateTokens`, `previousVote` using `OldConsPubKey` match up with `ConsPubKeyRotationHistory`, and replace validator for token allocation +7. Migrate `ValidatorSigningInfo` and `ValidatorMissedBlockBitArray` from `OldConsPubKey` to `NewConsPubKey` + +* Note : All above features shall be implemented in `staking` module. + +## Status + +Proposed + +## Consequences + +### Positive + +* Validators can immediately or periodically rotate their consensus key to have better security policy +* improved security against Long-Range attacks (https://nearprotocol.com/blog/long-range-attacks-and-a-new-fork-choice-rule) given a validator throws away the old consensus key(s) + +### Negative + +* Slash module needs more computation because it needs to lookup corresponding consensus key of validators for each height +* frequent key rotations will make light client bisection less efficient + +### Neutral + +## References + +* on tendermint repo : https://github.com/tendermint/tendermint/issues/1136 +* on cosmos-sdk repo : https://github.com/cosmos/cosmos-sdk/issues/5231 +* about multiple consensus keys : https://github.com/tendermint/tendermint/issues/1758#issuecomment-545291698 diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-017-historical-header-module.md b/versioned_docs/version-0.47/integrate/architecture/adr-017-historical-header-module.md new file mode 100644 index 000000000..573c632c2 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-017-historical-header-module.md @@ -0,0 +1,61 @@ +# ADR 17: Historical Header Module + +## Changelog + +* 26 November 2019: Start of first version +* 2 December 2019: Final draft of first version + +## Context + +In order for the Cosmos SDK to implement the [IBC specification](https://github.com/cosmos/ics), modules within the 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. + +## Decision + +The application MUST store the most recent `n` headers in a persistent store. At first, this store MAY be the current Merklised store. A non-Merklised store MAY be used later as no proofs are necessary. + +The application MUST store this information by storing new headers immediately when handling `abci.RequestBeginBlock`: + +```go +func BeginBlock(ctx sdk.Context, keeper HistoricalHeaderKeeper, req abci.RequestBeginBlock) abci.ResponseBeginBlock { + info := HistoricalInfo{ + Header: ctx.BlockHeader(), + ValSet: keeper.StakingKeeper.GetAllValidators(ctx), // note that this must be stored in a canonical order + } + keeper.SetHistoricalInfo(ctx, ctx.BlockHeight(), info) + n := keeper.GetParamRecentHeadersToStore() + keeper.PruneHistoricalInfo(ctx, ctx.BlockHeight() - n) + // continue handling request +} +``` + +Alternatively, the application MAY store only the hash of the validator set. + +The application MUST make these past `n` committed headers available for querying by 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` MAY be configured as a parameter store parameter, in which case it could be changed by `ParameterChangeProposal`s, although it will take some blocks for the stored information to catch up if `n` is increased. + +## Status + +Proposed. + +## Consequences + +Implementation of this ADR will require changes to the Cosmos SDK. It will not require changes to Tendermint. + +### Positive + +* Easy retrieval of headers & state roots for recent past heights by modules anywhere in the Cosmos SDK. +* No RPC calls to Tendermint required. +* No ABCI alterations required. + +### Negative + +* Duplicates `n` headers data in Tendermint & the application (additional disk usage) - in the long term, an approach such as [this](https://github.com/tendermint/tendermint/issues/4210) might be preferable. + +### Neutral + +(none known) + +## References + +* [ICS 2: "Consensus state introspection"](https://github.com/cosmos/ibc/tree/master/spec/core/ics-002-client-semantics#consensus-state-introspection) diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-018-extendable-voting-period.md b/versioned_docs/version-0.47/integrate/architecture/adr-018-extendable-voting-period.md new file mode 100644 index 000000000..ee238fc35 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-018-extendable-voting-period.md @@ -0,0 +1,66 @@ +# ADR 18: Extendable Voting Periods + +## Changelog + +* 1 January 2020: Start of first version + +## Context + +Currently the voting period for all governance proposals is the same. However, this is suboptimal as all governance proposals do not require the same time period. For more non-contentious proposals, they can be dealt with more efficently with a faster period, while more contentious or complex proposals may need a longer period for extended discussion/consideration. + +## Decision + +We would like to design a mechanism for making the voting period of a governance proposal variable based on the demand of voters. We would like it to be based on the view of the governance participants, rather than just the proposer of a governance proposal (thus, allowing the proposer to select the voting period length is not sufficient). + +However, we would like to avoid the creation of an entire second voting process to determine the length of the voting period, as it just pushed the problem to determining the length of that first voting period. + +Thus, we propose the following mechanism: + +### Params + +* The current gov param `VotingPeriod` is to be replaced by a `MinVotingPeriod` param. This is the default voting period that all governance proposal voting periods start with. +* There is a new gov param called `MaxVotingPeriodExtension`. + +### Mechanism + +There is a new `Msg` type called `MsgExtendVotingPeriod`, which can be sent by any staked account during a proposal's voting period. It allows the sender to unilaterally extend the length of the voting period by `MaxVotingPeriodExtension * sender's share of voting power`. Every address can only call `MsgExtendVotingPeriod` once per proposal. + +So for example, if the `MaxVotingPeriodExtension` is set to 100 Days, then anyone with 1% of voting power can extend the voting power by 1 day. If 33% of voting power has sent the message, the voting period will be extended by 33 days. Thus, if absolutely everyone chooses to extend the voting period, the absolute maximum voting period will be `MinVotingPeriod + MaxVotingPeriodExtension`. + +This system acts as a sort of distributed coordination, where individual stakers choosing to extend or not, allows the system the guage the conentiousness/complexity of the proposal. It is extremely unlikely that many stakers will choose to extend at the exact same time, it allows stakers to view how long others have already extended thus far, to decide whether or not to extend further. + +### Dealing with Unbonding/Redelegation + +There is one thing that needs to be addressed. How to deal with redelegation/unbonding during the voting period. If a staker of 5% calls `MsgExtendVotingPeriod` and then unbonds, does the voting period then decrease by 5 days again? This is not good as it can give people a false sense of how long they have to make their decision. For this reason, we want to design it such that the voting period length can only be extended, not shortened. To do this, the current extension amount is based on the highest percent that voted extension at any time. This is best explained by example: + +1. Let's say 2 stakers of voting power 4% and 3% respectively vote to extend. The voting period will be extended by 7 days. +2. Now the staker of 3% decides to unbond before the end of the voting period. The voting period extension remains 7 days. +3. Now, let's say another staker of 2% voting power decides to extend voting period. There is now 6% of active voting power choosing the extend. The voting power remains 7 days. +4. If a fourth staker of 10% chooses to extend now, there is a total of 16% of active voting power wishing to extend. The voting period will be extended to 16 days. + +### Delegators + +Just like votes in the actual voting period, delegators automatically inherit the extension of their validators. If their validator chooses to extend, their voting power will be used in the validator's extension. However, the delegator is unable to override their validator and "unextend" as that would contradict the "voting power length can only be ratcheted up" principle described in the previous section. However, a delegator may choose the extend using their personal voting power, if their validator has not done so. + +## Status + +Proposed + +## Consequences + +### Positive + +* More complex/contentious governance proposals will have more time to properly digest and deliberate + +### Negative + +* Governance process becomes more complex and requires more understanding to interact with effectively +* Can no longer predict when a governance proposal will end. Can't assume order in which governance proposals will end. + +### Neutral + +* The minimum voting period can be made shorter + +## References + +* [Cosmos Forum post where idea first originated](https://forum.cosmos.network/t/proposal-draft-reduce-governance-voting-period-to-7-days/3032/9) diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-019-protobuf-state-encoding.md b/versioned_docs/version-0.47/integrate/architecture/adr-019-protobuf-state-encoding.md new file mode 100644 index 000000000..5ad1b953e --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-019-protobuf-state-encoding.md @@ -0,0 +1,379 @@ +# ADR 019: Protocol Buffer State Encoding + +## Changelog + +* 2020 Feb 15: Initial Draft +* 2020 Feb 24: Updates to handle messages with interface fields +* 2020 Apr 27: Convert usages of `oneof` for interfaces to `Any` +* 2020 May 15: Describe `cosmos_proto` extensions and amino compatibility +* 2020 Dec 4: Move and rename `MarshalAny` and `UnmarshalAny` into the `codec.Codec` interface. +* 2021 Feb 24: Remove mentions of `HybridCodec`, which has been abandoned in [#6843](https://github.com/cosmos/cosmos-sdk/pull/6843). + +## Status + +Accepted + +## Context + +Currently, the Cosmos SDK utilizes [go-amino](https://github.com/tendermint/go-amino/) for binary +and JSON object encoding over the wire bringing parity between logical objects and persistence objects. + +From the Amino docs: + +> Amino is an object encoding specification. It is a subset of Proto3 with an extension for interface +> support. See the [Proto3 spec](https://developers.google.com/protocol-buffers/docs/proto3) for more +> information on Proto3, which Amino is largely compatible with (but not with Proto2). +> +> The goal of the Amino encoding protocol is to bring parity into logic objects and persistence objects. + +Amino also aims to have the following goals (not a complete list): + +* Binary bytes must be decode-able with a schema. +* Schema must be upgradeable. +* The encoder and decoder logic must be reasonably simple. + +However, we believe that Amino does not fulfill these goals completely and does not fully meet the +needs of a truly flexible cross-language and multi-client compatible encoding protocol in the Cosmos SDK. +Namely, Amino has proven to be a big pain-point in regards to supporting object serialization across +clients written in various languages while providing virtually little in the way of true backwards +compatibility and upgradeability. Furthermore, through profiling and various benchmarks, Amino has +been shown to be an extremely large performance bottleneck in the Cosmos SDK 1. This is +largely reflected in the performance of simulations and application transaction throughput. + +Thus, we need to adopt an encoding protocol that meets the following criteria for state serialization: + +* Language agnostic +* Platform agnostic +* Rich client support and thriving ecosystem +* High performance +* Minimal encoded message size +* Codegen-based over reflection-based +* Supports backward and forward compatibility + +Note, migrating away from Amino should be viewed as a two-pronged approach, state and client encoding. +This ADR focuses on state serialization in the Cosmos SDK state machine. A corresponding ADR will be +made to address client-side encoding. + +## Decision + +We will adopt [Protocol Buffers](https://developers.google.com/protocol-buffers) for serializing +persisted structured data in the Cosmos SDK while providing a clean mechanism and developer UX for +applications wishing to continue to use Amino. We will provide this mechanism by updating modules to +accept a codec interface, `Marshaler`, instead of a concrete Amino codec. Furthermore, the Cosmos SDK +will provide two concrete implementations of the `Marshaler` interface: `AminoCodec` and `ProtoCodec`. + +* `AminoCodec`: Uses Amino for both binary and JSON encoding. +* `ProtoCodec`: Uses Protobuf for both binary and JSON encoding. + +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. + +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. + +### 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. + +Note, any business logic that needs to encode primitive types like `bool` or `int64` should use +[gogoprotobuf](https://github.com/cosmos/gogoproto) Value types. + +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. + +Example: + +```go +// x/auth/types/codec.go + +type Codec interface { + codec.Codec + + MarshalAccount(acc exported.Account) ([]byte, error) + UnmarshalAccount(bz []byte) (exported.Account, error) + + MarshalAccountJSON(acc exported.Account) ([]byte, error) + UnmarshalAccountJSON(bz []byte) (exported.Account, error) +} +``` + +### Usage of `Any` to encode interfaces + +In general, module-level .proto files should define messages which encode interfaces +using [`google.protobuf.Any`](https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/any.proto). +After [extension discussion](https://github.com/cosmos/cosmos-sdk/issues/6030), +this was chosen as the preferred alternative to application-level `oneof`s +as in our original protobuf design. The arguments in favor of `Any` can be +summarized as follows: + +* `Any` provides a simpler, more consistent client UX for dealing with +interfaces than app-level `oneof`s that will need to be coordinated more +carefully across applications. Creating a generic transaction +signing library using `oneof`s may be cumbersome and critical logic may need +to be reimplemented for each chain +* `Any` provides more resistance against human error than `oneof` +* `Any` is generally simpler to implement for both modules and apps + +The main counter-argument to using `Any` centers around its additional space +and possibly performance overhead. The space overhead could be dealt with using +compression at the persistence layer in the future and the performance impact +is likely to be small. Thus, not using `Any` is seem as a pre-mature optimization, +with user experience as the higher order concern. + +Note, that given the 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://pkg.go.dev/github.com/cosmos/gogoproto/types) +uses [global type registration]( https://github.com/cosmos/gogoproto/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 register a type with the global protobuf registry +and cause it to be loaded and unmarshaled by a transaction that referenced +it in the `type_url` field. + +To prevent this, we introduce a type registration mechanism for decoding `Any` +values into concrete types through the `InterfaceRegistry` interface which +bears some similarity to type registration with Amino: + +```go +type InterfaceRegistry interface { + // RegisterInterface associates protoName as the public name for the + // interface passed in as iface + // Ex: + // registry.RegisterInterface("cosmos_sdk.Msg", (*sdk.Msg)(nil)) + RegisterInterface(protoName string, iface interface{}) + + // RegisterImplementations registers impls as a concrete implementations of + // the interface iface + // Ex: + // registry.RegisterImplementations((*sdk.Msg)(nil), &MsgSend{}, &MsgMultiSend{}) + RegisterImplementations(iface interface{}, impls ...proto.Message) + +} +``` + +In addition to serving as a whitelist, `InterfaceRegistry` can also serve +to communicate the list of concrete types that satisfy an interface to clients. + +In .proto files: + +* fields which accept interfaces should be annotated with `cosmos_proto.accepts_interface` +using the same full-qualified name passed as `protoName` to `InterfaceRegistry.RegisterInterface` +* interface implementations should be annotated with `cosmos_proto.implements_interface` +using the same full-qualified name passed as `protoName` to `InterfaceRegistry.RegisterInterface` + +In the future, `protoName`, `cosmos_proto.accepts_interface`, `cosmos_proto.implements_interface` +may be used via code generation, reflection &/or static linting. + +The same struct that implements `InterfaceRegistry` will also implement an +interface `InterfaceUnpacker` to be used for unpacking `Any`s: + +```go +type InterfaceUnpacker interface { + // UnpackAny unpacks the value in any to the interface pointer passed in as + // iface. Note that the type in any must have been registered with + // RegisterImplementations as a concrete type for that interface + // Ex: + // var msg sdk.Msg + // err := ctx.UnpackAny(any, &msg) + // ... + UnpackAny(any *Any, iface interface{}) error +} +``` + +Note that `InterfaceRegistry` usage does not deviate from standard protobuf +usage of `Any`, it just introduces a security and introspection layer for +golang usage. + +`InterfaceRegistry` will be a member of `ProtoCodec` +described above. In order for modules to register interface types, app modules +can optionally implement the following interface: + +```go +type InterfaceModule interface { + RegisterInterfaceTypes(InterfaceRegistry) +} +``` + +The module manager will include a method to call `RegisterInterfaceTypes` on +every module that implements it in order to populate the `InterfaceRegistry`. + +### Using `Any` to encode state + +The Cosmos SDK will provide support methods `MarshalInterface` and `UnmarshalInterface` to hide a complexity of wrapping interface types into `Any` and allow easy serialization. + +```go +import "github.com/cosmos/cosmos-sdk/codec" + +// note: eviexported.Evidence is an interface type +func MarshalEvidence(cdc codec.BinaryCodec, e eviexported.Evidence) ([]byte, error) { + return cdc.MarshalInterface(e) +} + +func UnmarshalEvidence(cdc codec.BinaryCodec, bz []byte) (eviexported.Evidence, error) { + var evi eviexported.Evidence + err := cdc.UnmarshalInterface(&evi, bz) + return err, nil +} +``` + +### Using `Any` in `sdk.Msg`s + +A similar concept is to be applied for messages that contain interfaces fields. +For example, we can define `MsgSubmitEvidence` as follows where `Evidence` is +an interface: + +```protobuf +// x/evidence/types/types.proto + +message MsgSubmitEvidence { + bytes submitter = 1 + [ + (gogoproto.casttype) = "github.com/cosmos/cosmos-sdk/types.AccAddress" + ]; + google.protobuf.Any evidence = 2; +} +``` + +Note that in order to unpack the evidence from `Any` we do need a reference to +`InterfaceRegistry`. In order to reference evidence in methods like +`ValidateBasic` which shouldn't have to know about the `InterfaceRegistry`, we +introduce an `UnpackInterfaces` phase to deserialization which unpacks +interfaces before they're needed. + +### Unpacking Interfaces + +To implement the `UnpackInterfaces` phase of deserialization which unpacks +interfaces wrapped in `Any` before they're needed, we create an interface +that `sdk.Msg`s and other types can implement: + +```go +type UnpackInterfacesMessage interface { + UnpackInterfaces(InterfaceUnpacker) error +} +``` + +We also introduce a private `cachedValue interface{}` field onto the `Any` +struct itself with a public getter `GetCachedValue() interface{}`. + +The `UnpackInterfaces` method is to be invoked during message deserialization right +after `Unmarshal` and any interface values packed in `Any`s will be decoded +and stored in `cachedValue` for reference later. + +Then unpacked interface values can safely be used in any code afterwards +without knowledge of the `InterfaceRegistry` +and messages can introduce a simple getter to cast the cached value to the +correct interface type. + +This has the added benefit that unmarshaling of `Any` values only happens once +during initial deserialization rather than every time the value is read. Also, +when `Any` values are first packed (for instance in a call to +`NewMsgSubmitEvidence`), the original interface value is cached so that +unmarshaling isn't needed to read it again. + +`MsgSubmitEvidence` could implement `UnpackInterfaces`, plus a convenience getter +`GetEvidence` as follows: + +```go +func (msg MsgSubmitEvidence) UnpackInterfaces(ctx sdk.InterfaceRegistry) error { + var evi eviexported.Evidence + return ctx.UnpackAny(msg.Evidence, *evi) +} + +func (msg MsgSubmitEvidence) GetEvidence() eviexported.Evidence { + return msg.Evidence.GetCachedValue().(eviexported.Evidence) +} +``` + +### Amino Compatibility + +Our custom implementation of `Any` can be used transparently with Amino if used +with the proper codec instance. What this means is that interfaces packed within +`Any`s will be amino marshaled like regular Amino interfaces (assuming they +have been registered properly with Amino). + +In order for this functionality to work: + +* **all legacy code must use `*codec.LegacyAmino` instead of `*amino.Codec` which is + now a wrapper which properly handles `Any`** +* **all new code should use `Marshaler` which is compatible with both amino and + protobuf** +* Also, before v0.39, `codec.LegacyAmino` will be renamed to `codec.LegacyAmino`. + +### Why Wasn't X Chosen Instead + +For a more complete comparison to alternative protocols, see [here](https://codeburst.io/json-vs-protocol-buffers-vs-flatbuffers-a4247f8bda6f). + +### Cap'n Proto + +While [Cap’n Proto](https://capnproto.org/) does seem like an advantageous alternative to Protobuf +due to it's native support for interfaces/generics and built in canonicalization, it does lack the +rich client ecosystem compared to Protobuf and is a bit less mature. + +### FlatBuffers + +[FlatBuffers](https://google.github.io/flatbuffers/) is also a potentially viable alternative, with the +primary difference being that FlatBuffers does not need a parsing/unpacking step to a secondary +representation before you can access data, often coupled with per-object memory allocation. + +However, it would require great efforts into research and full understanding the scope of the migration +and path forward -- which isn't immediately clear. In addition, FlatBuffers aren't designed for +untrusted inputs. + +## Future Improvements & Roadmap + +In the future we may consider a compression layer right above the persistence +layer which doesn't change tx or merkle tree hashes, but reduces the storage +overhead of `Any`. In addition, we may adopt protobuf naming conventions which +make type URLs a bit more concise while remaining descriptive. + +Additional code generation support around the usage of `Any` is something that +could also be explored in the future to make the UX for go developers more +seamless. + +## Consequences + +### Positive + +* Significant performance gains. +* Supports backward and forward type compatibility. +* Better support for cross-language clients. + +### Negative + +* Learning curve required to understand and implement Protobuf messages. +* Slightly larger message size due to use of `Any`, although this could be offset + by a compression layer in the future + +### Neutral + +## References + +1. https://github.com/cosmos/cosmos-sdk/issues/4977 +2. https://github.com/cosmos/cosmos-sdk/issues/5444 diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-020-protobuf-transaction-encoding.md b/versioned_docs/version-0.47/integrate/architecture/adr-020-protobuf-transaction-encoding.md new file mode 100644 index 000000000..4c30bb9eb --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-020-protobuf-transaction-encoding.md @@ -0,0 +1,464 @@ +# ADR 020: Protocol Buffer Transaction Encoding + +## Changelog + +* 2020 March 06: Initial Draft +* 2020 March 12: API Updates +* 2020 April 13: Added details on interface `oneof` handling +* 2020 April 30: Switch to `Any` +* 2020 May 14: Describe public key encoding +* 2020 June 08: Store `TxBody` and `AuthInfo` as bytes in `SignDoc`; Document `TxRaw` as broadcast and storage type. +* 2020 August 07: Use ADR 027 for serializing `SignDoc`. +* 2020 August 19: Move sequence field from `SignDoc` to `SignerInfo`, as discussed in [#6966](https://github.com/cosmos/cosmos-sdk/issues/6966). +* 2020 September 25: Remove `PublicKey` type in favor of `secp256k1.PubKey`, `ed25519.PubKey` and `multisig.LegacyAminoPubKey`. +* 2020 October 15: Add `GetAccount` and `GetAccountWithHeight` methods to the `AccountRetriever` interface. +* 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`. + +## Status + +Accepted + +## Context + +This ADR is a continuation of the motivation, design, and context established in +[ADR 019](./adr-019-protobuf-state-encoding.md), namely, we aim to design the +Protocol Buffer migration path for the client-side of the Cosmos SDK. + +Specifically, the client-side migration path primarily includes tx generation and +signing, message construction and routing, in addition to CLI & REST handlers and +business logic (i.e. queriers). + +With this in mind, we will tackle the migration path via two main areas, txs and +querying. However, this ADR solely focuses on transactions. Querying should be +addressed in a future ADR, but it should build off of these proposals. + +Based on detailed discussions ([\#6030](https://github.com/cosmos/cosmos-sdk/issues/6030) +and [\#6078](https://github.com/cosmos/cosmos-sdk/issues/6078)), the original +design for transactions was changed substantially from an `oneof` /JSON-signing +approach to the approach described below. + +## Decision + +### Transactions + +Since interface values are encoded with `google.protobuf.Any` in state (see [ADR 019](adr-019-protobuf-state-encoding.md)), +`sdk.Msg`s are encoding with `Any` in transactions. + +One of the main goals of using `Any` to encode interface values is to have a +core set of types which is reused by apps so that +clients can safely be compatible with as many chains as possible. + +It is one of the goals of this specification to provide a flexible cross-chain transaction +format that can serve a wide variety of use cases without breaking client +compatibility. + +In order to facilitate signing, transactions are separated into `TxBody`, +which will be re-used by `SignDoc` below, and `signatures`: + +```protobuf +// types/types.proto +package cosmos_sdk.v1; + +message Tx { + TxBody body = 1; + AuthInfo auth_info = 2; + // A list of signatures that matches the length and order of AuthInfo's signer_infos to + // allow connecting signature meta information like public key and signing mode by position. + repeated bytes signatures = 3; +} + +// A variant of Tx that pins the signer's exact binary represenation of body and +// auth_info. This is used for signing, broadcasting and verification. The binary +// `serialize(tx: TxRaw)` is stored in Tendermint and the hash `sha256(serialize(tx: TxRaw))` +// becomes the "txhash", commonly used as the transaction ID. +message TxRaw { + // A protobuf serialization of a TxBody that matches the representation in SignDoc. + bytes body = 1; + // A protobuf serialization of an AuthInfo that matches the representation in SignDoc. + bytes auth_info = 2; + // A list of signatures that matches the length and order of AuthInfo's signer_infos to + // allow connecting signature meta information like public key and signing mode by position. + repeated bytes signatures = 3; +} + +message TxBody { + // A list of messages to be executed. The required signers of those messages define + // the number and order of elements in AuthInfo's signer_infos and Tx's signatures. + // Each required signer address is added to the list only the first time it occurs. + // + // By convention, the first required signer (usually from the first message) is referred + // to as the primary signer and pays the fee for the whole transaction. + repeated google.protobuf.Any messages = 1; + string memo = 2; + int64 timeout_height = 3; + repeated google.protobuf.Any extension_options = 1023; +} + +message AuthInfo { + // This list defines the signing modes for the required signers. The number + // and order of elements must match the required signers from TxBody's messages. + // The first element is the primary signer and the one which pays the fee. + repeated SignerInfo signer_infos = 1; + // The fee can be calculated based on the cost of evaluating the body and doing signature verification of the signers. This can be estimated via simulation. + Fee fee = 2; +} + +message SignerInfo { + // The public key is optional for accounts that already exist in state. If unset, the + // verifier can use the required signer address for this position and lookup the public key. + google.protobuf.Any public_key = 1; + // ModeInfo describes the signing mode of the signer and is a nested + // structure to support nested multisig pubkey's + ModeInfo mode_info = 2; + // sequence is the sequence of the account, which describes the + // number of committed transactions signed by a given address. It is used to prevent + // replay attacks. + uint64 sequence = 3; +} + +message ModeInfo { + oneof sum { + Single single = 1; + Multi multi = 2; + } + + // Single is the mode info for a single signer. It is structured as a message + // to allow for additional fields such as locale for SIGN_MODE_TEXTUAL in the future + message Single { + SignMode mode = 1; + } + + // Multi is the mode info for a multisig public key + message Multi { + // bitarray specifies which keys within the multisig are signing + CompactBitArray bitarray = 1; + // mode_infos is the corresponding modes of the signers of the multisig + // which could include nested multisig public keys + repeated ModeInfo mode_infos = 2; + } +} + +enum SignMode { + SIGN_MODE_UNSPECIFIED = 0; + + SIGN_MODE_DIRECT = 1; + + SIGN_MODE_TEXTUAL = 2; + + SIGN_MODE_LEGACY_AMINO_JSON = 127; +} +``` + +As will be discussed below, in order to include as much of the `Tx` as possible +in the `SignDoc`, `SignerInfo` is separated from signatures so that only the +raw signatures themselves live outside of what is signed over. + +Because we are aiming for a flexible, extensible cross-chain transaction +format, new transaction processing options should be added to `TxBody` as soon +those use cases are discovered, even if they can't be implemented yet. + +Because there is coordination overhead in this, `TxBody` includes an +`extension_options` field which can be used for any transaction processing +options that are not already covered. App developers should, nevertheless, +attempt to upstream important improvements to `Tx`. + +### Signing + +All of the signing modes below aim to provide the following guarantees: + +* **No Malleability**: `TxBody` and `AuthInfo` cannot change once the transaction + is signed +* **Predictable Gas**: if I am signing a transaction where I am paying a fee, + the final gas is fully dependent on what I am signing + +These guarantees give the maximum amount confidence to message signers that +manipulation of `Tx`s by intermediaries can't result in any meaningful changes. + +#### `SIGN_MODE_DIRECT` + +The "direct" signing behavior is to sign the raw `TxBody` bytes as broadcast over +the wire. This has the advantages of: + +* requiring the minimum additional client capabilities beyond a standard protocol + buffers implementation +* leaving effectively zero holes for transaction malleability (i.e. there are no + subtle differences between the signing and encoding formats which could + potentially be exploited by an attacker) + +Signatures are structured using the `SignDoc` below which reuses the serialization of +`TxBody` and `AuthInfo` and only adds the fields which are needed for signatures: + +```protobuf +// types/types.proto +message SignDoc { + // A protobuf serialization of a TxBody that matches the representation in TxRaw. + bytes body = 1; + // A protobuf serialization of an AuthInfo that matches the representation in TxRaw. + bytes auth_info = 2; + string chain_id = 3; + uint64 account_number = 4; +} +``` + +In order to sign in the default mode, clients take the following steps: + +1. Serialize `TxBody` and `AuthInfo` using any valid protobuf implementation. +2. Create a `SignDoc` and serialize it using [ADR 027](./adr-027-deterministic-protobuf-serialization.md). +3. Sign the encoded `SignDoc` bytes. +4. Build a `TxRaw` and serialize it for broadcasting. + +Signature verification is based on comparing the raw `TxBody` and `AuthInfo` +bytes encoded in `TxRaw` not based on any ["canonicalization"](https://github.com/regen-network/canonical-proto3) +algorithm which creates added complexity for clients in addition to preventing +some forms of upgradeability (to be addressed later in this document). + +Signature verifiers do: + +1. Deserialize a `TxRaw` and pull out `body` and `auth_info`. +2. Create a list of required signer addresses from the messages. +3. For each required signer: + * Pull account number and sequence from the state. + * Obtain the public key either from state or `AuthInfo`'s `signer_infos`. + * Create a `SignDoc` and serialize it using [ADR 027](./adr-027-deterministic-protobuf-serialization.md). + * Verify the signature at the same list position against the serialized `SignDoc`. + +#### `SIGN_MODE_LEGACY_AMINO` + +In order to support legacy wallets and exchanges, Amino JSON will be temporarily +supported transaction signing. Once wallets and exchanges have had a +chance to upgrade to protobuf based signing, this option will be disabled. In +the meantime, it is foreseen that disabling the current Amino signing would cause +too much breakage to be feasible. Note that this is mainly a requirement of the +Cosmos Hub and other chains may choose to disable Amino signing immediately. + +Legacy clients will be able to sign a transaction using the current Amino +JSON format and have it encoded to protobuf using the REST `/tx/encode` +endpoint before broadcasting. + +#### `SIGN_MODE_TEXTUAL` + +As was discussed extensively in [\#6078](https://github.com/cosmos/cosmos-sdk/issues/6078), +there is a desire for a human-readable signing encoding, especially for hardware +wallets like the [Ledger](https://www.ledger.com) which display +transaction contents to users before signing. JSON was an attempt at this but +falls short of the ideal. + +`SIGN_MODE_TEXTUAL` is intended as a placeholder for a human-readable +encoding which will replace Amino JSON. This new encoding should be even more +focused on readability than JSON, possibly based on formatting strings like +[MessageFormat](http://userguide.icu-project.org/formatparse/messages). + +In order to ensure that the new human-readable format does not suffer from +transaction malleability issues, `SIGN_MODE_TEXTUAL` +requires that the _human-readable bytes are concatenated with the raw `SignDoc`_ +to generate sign bytes. + +Multiple human-readable formats (maybe even localized messages) may be supported +by `SIGN_MODE_TEXTUAL` when it is implemented. + +### Unknown Field Filtering + +Unknown fields in protobuf messages should generally be rejected by transaction +processors because: + +* important data may be present in the unknown fields, that if ignored, will + cause unexpected behavior for clients +* they present a malleability vulnerability where attackers can bloat tx size + by adding random uninterpreted data to unsigned content (i.e. the master `Tx`, + not `TxBody`) + +There are also scenarios where we may choose to safely ignore unknown fields +(https://github.com/cosmos/cosmos-sdk/issues/6078#issuecomment-624400188) to +provide graceful forwards compatibility with newer clients. + +We propose that field numbers with bit 11 set (for most use cases this is +the range of 1024-2047) be considered non-critical fields that can safely be +ignored if unknown. + +To handle this we will need a unknown field filter that: + +* always rejects unknown fields in unsigned content (i.e. top-level `Tx` and + unsigned parts of `AuthInfo` if present based on the signing mode) +* rejects unknown fields in all messages (including nested `Any`s) other than + fields with bit 11 set + +This will likely need to be a custom protobuf parser pass that takes message bytes +and `FileDescriptor`s and returns a boolean result. + +### Public Key Encoding + +Public keys in the Cosmos SDK implement 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: + +```protobuf +message PubKey { + bytes key = 1; +} +``` + +`multisig.LegacyAminoPubKey` has an array of `Any`'s member to support any +protobuf public key type. + +Apps should only attempt to handle a registered set of public keys that they +have tested. The provided signature verification ante handler decorators will +enforce this. + +### CLI & REST + +Currently, the REST and CLI handlers encode and decode types and txs via Amino +JSON encoding using a concrete Amino codec. Being that some of the types dealt with +in the client can be interfaces, similar to how we described in [ADR 019](./adr-019-protobuf-state-encoding.md), +the client logic will now need to take a codec interface that knows not only how +to handle all the types, but also knows how to generate transactions, signatures, +and messages. + +```go +type AccountRetriever interface { + GetAccount(clientCtx Context, addr sdk.AccAddress) (client.Account, error) + GetAccountWithHeight(clientCtx Context, addr sdk.AccAddress) (client.Account, int64, error) + EnsureExists(clientCtx client.Context, addr sdk.AccAddress) error + GetAccountNumberSequence(clientCtx client.Context, addr sdk.AccAddress) (uint64, uint64, error) +} + +type Generator interface { + NewTx() TxBuilder + NewFee() ClientFee + NewSignature() ClientSignature + MarshalTx(tx types.Tx) ([]byte, error) +} + +type TxBuilder interface { + GetTx() sdk.Tx + + SetMsgs(...sdk.Msg) error + GetSignatures() []sdk.Signature + SetSignatures(...sdk.Signature) + GetFee() sdk.Fee + SetFee(sdk.Fee) + GetMemo() string + SetMemo(string) +} +``` + +We then update `Context` to have new fields: `Codec`, `TxGenerator`, +and `AccountRetriever`, and we update `AppModuleBasic.GetTxCmd` to take +a `Context` which should have all of these fields pre-populated. + +Each client method should then use one of the `Init` methods to re-initialize +the pre-populated `Context`. `tx.GenerateOrBroadcastTx` can be used to +generate or broadcast a transaction. For example: + +```go +import "github.com/spf13/cobra" +import "github.com/cosmos/cosmos-sdk/client" +import "github.com/cosmos/cosmos-sdk/client/tx" + +func NewCmdDoSomething(clientCtx client.Context) *cobra.Command { + return &cobra.Command{ + RunE: func(cmd *cobra.Command, args []string) error { + clientCtx := ctx.InitWithInput(cmd.InOrStdin()) + msg := NewSomeMsg{...} + tx.GenerateOrBroadcastTx(clientCtx, msg) + }, + } +} +``` + +## Future Improvements + +### `SIGN_MODE_TEXTUAL` specification + +A concrete specification and implementation of `SIGN_MODE_TEXTUAL` is intended +as a near-term future improvement so that the ledger app and other wallets +can gracefully transition away from Amino JSON. + +### `SIGN_MODE_DIRECT_AUX` + +(\*Documented as option (3) in https://github.com/cosmos/cosmos-sdk/issues/6078#issuecomment-628026933) + +We could add a mode `SIGN_MODE_DIRECT_AUX` +to support scenarios where multiple signatures +are being gathered into a single transaction but the message composer does not +yet know which signatures will be included in the final transaction. For instance, +I may have a 3/5 multisig wallet and want to send a `TxBody` to all 5 +signers to see who signs first. As soon as I have 3 signatures then I will go +ahead and build the full transaction. + +With `SIGN_MODE_DIRECT`, each signer needs +to sign the full `AuthInfo` which includes the full list of all signers and +their signing modes, making the above scenario very hard. + +`SIGN_MODE_DIRECT_AUX` would allow "auxiliary" signers to create their signature +using only `TxBody` and their own `PublicKey`. This allows the full list of +signers in `AuthInfo` to be delayed until signatures have been collected. + +An "auxiliary" signer is any signer besides the primary signer who is paying +the fee. For the primary signer, the full `AuthInfo` is actually needed to calculate gas and fees +because that is dependent on how many signers and which key types and signing +modes they are using. Auxiliary signers, however, do not need to worry about +fees or gas and thus can just sign `TxBody`. + +To generate a signature in `SIGN_MODE_DIRECT_AUX` these steps would be followed: + +1. Encode `SignDocAux` (with the same requirement that fields must be serialized + in order): + + ```protobuf + // types/types.proto + message SignDocAux { + bytes body_bytes = 1; + // PublicKey is included in SignDocAux : + // 1. as a special case for multisig public keys. For multisig public keys, + // the signer should use the top-level multisig public key they are signing + // against, not their own public key. This is to prevent against a form + // of malleability where a signature could be taken out of context of the + // multisig key that was intended to be signed for + // 2. to guard against scenario where configuration information is encoded + // in public keys (it has been proposed) such that two keys can generate + // the same signature but have different security properties + // + // By including it here, the composer of AuthInfo cannot reference the + // a public key variant the signer did not intend to use + PublicKey public_key = 2; + string chain_id = 3; + uint64 account_number = 4; + } + ``` + +2. Sign the encoded `SignDocAux` bytes +3. Send their signature and `SignerInfo` to primary signer who will then + sign and broadcast the final transaction (with `SIGN_MODE_DIRECT` and `AuthInfo` + added) once enough signatures have been collected + +### `SIGN_MODE_DIRECT_RELAXED` + +(_Documented as option (1)(a) in https://github.com/cosmos/cosmos-sdk/issues/6078#issuecomment-628026933_) + +This is a variation of `SIGN_MODE_DIRECT` where multiple signers wouldn't need to +coordinate public keys and signing modes in advance. It would involve an alternate +`SignDoc` similar to `SignDocAux` above with fee. This could be added in the future +if client developers found the burden of collecting public keys and modes in advance +too burdensome. + +## Consequences + +### Positive + +* Significant performance gains. +* Supports backward and forward type compatibility. +* Better support for cross-language clients. +* Multiple signing modes allow for greater protocol evolution + +### Negative + +* `google.protobuf.Any` type URLs increase transaction size although the effect + may be negligible or compression may be able to mitigate it. + +### Neutral + +## References diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-021-protobuf-query-encoding.md b/versioned_docs/version-0.47/integrate/architecture/adr-021-protobuf-query-encoding.md new file mode 100644 index 000000000..a90e807d5 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-021-protobuf-query-encoding.md @@ -0,0 +1,256 @@ +# ADR 021: Protocol Buffer Query Encoding + +## Changelog + +* 2020 March 27: Initial Draft + +## Status + +Accepted + +## Context + +This ADR is a continuation of the motivation, design, and context established in +[ADR 019](./adr-019-protobuf-state-encoding.md) and +[ADR 020](./adr-020-protobuf-transaction-encoding.md), namely, we aim to design the +Protocol Buffer migration path for the client-side of the Cosmos SDK. + +This ADR continues from [ADD 020](./adr-020-protobuf-transaction-encoding.md) +to specify the encoding of queries. + +## Decision + +### Custom Query Definition + +Modules define custom queries through a protocol buffers `service` definition. +These `service` definitions are generally associated with and used by the +GRPC protocol. However, the protocol buffers specification indicates that +they can be used more generically by any request/response protocol that uses +protocol buffer encoding. Thus, we can use `service` definitions for specifying +custom ABCI queries and even reuse a substantial amount of the GRPC infrastructure. + +Each module with custom queries should define a service canonically named `Query`: + +```protobuf +// x/bank/types/types.proto + +service Query { + rpc QueryBalance(QueryBalanceParams) returns (cosmos_sdk.v1.Coin) { } + rpc QueryAllBalances(QueryAllBalancesParams) returns (QueryAllBalancesResponse) { } +} +``` + +#### Handling of Interface Types + +Modules that use interface types and need true polymorphism generally force a +`oneof` up to the app-level that provides the set of concrete implementations of +that interface that the app supports. While app's are welcome to do the same for +queries and implement an app-level query service, it is recommended that modules +provide query methods that expose these interfaces via `google.protobuf.Any`. +There is a concern on the transaction level that the overhead of `Any` is too +high to justify its usage. However for queries this is not a concern, and +providing generic module-level queries that use `Any` does not preclude apps +from also providing app-level queries that return use the app-level `oneof`s. + +A hypothetical example for the `gov` module would look something like: + +```protobuf +// x/gov/types/types.proto + +import "google/protobuf/any.proto"; + +service Query { + rpc GetProposal(GetProposalParams) returns (AnyProposal) { } +} + +message AnyProposal { + ProposalBase base = 1; + google.protobuf.Any content = 2; +} +``` + +### Custom Query Implementation + +In order to implement the query service, we can reuse the existing [gogo protobuf](https://github.com/cosmos/gogoproto) +grpc plugin, which for a service named `Query` generates an interface named +`QueryServer` as below: + +```go +type QueryServer interface { + QueryBalance(context.Context, *QueryBalanceParams) (*types.Coin, error) + QueryAllBalances(context.Context, *QueryAllBalancesParams) (*QueryAllBalancesResponse, error) +} +``` + +The custom queries for our module are implemented by implementing this interface. + +The first parameter in this generated interface is a generic `context.Context`, +whereas querier methods generally need an instance of `sdk.Context` to read +from the store. Since arbitrary values can be attached to `context.Context` +using the `WithValue` and `Value` methods, the Cosmos SDK should provide a function +`sdk.UnwrapSDKContext` to retrieve the `sdk.Context` from the provided +`context.Context`. + +An example implementation of `QueryBalance` for the bank module as above would +look something like: + +```go +type Querier struct { + Keeper +} + +func (q Querier) QueryBalance(ctx context.Context, params *types.QueryBalanceParams) (*sdk.Coin, error) { + balance := q.GetBalance(sdk.UnwrapSDKContext(ctx), params.Address, params.Denom) + return &balance, nil +} +``` + +### Custom Query Registration and Routing + +Query server implementations as above would be registered with `AppModule`s using +a new method `RegisterQueryService(grpc.Server)` which could be implemented simply +as below: + +```go +// x/bank/module.go +func (am AppModule) RegisterQueryService(server grpc.Server) { + types.RegisterQueryServer(server, keeper.Querier{am.keeper}) +} +``` + +Underneath the hood, a new method `RegisterService(sd *grpc.ServiceDesc, handler interface{})` +will be added to the existing `baseapp.QueryRouter` to add the queries to the custom +query routing table (with the routing method being described below). +The signature for this method matches the existing +`RegisterServer` method on the GRPC `Server` type where `handler` is the custom +query server implementation described above. + +GRPC-like requests are routed by the service name (ex. `cosmos_sdk.x.bank.v1.Query`) +and method name (ex. `QueryBalance`) combined with `/`s to form a full +method name (ex. `/cosmos_sdk.x.bank.v1.Query/QueryBalance`). This gets translated +into an ABCI query as `custom/cosmos_sdk.x.bank.v1.Query/QueryBalance`. Service handlers +registered with `QueryRouter.RegisterService` will be routed this way. + +Beyond the method name, GRPC requests carry a protobuf encoded payload, which maps naturally +to `RequestQuery.Data`, and receive a protobuf encoded response or error. Thus +there is a quite natural mapping of GRPC-like rpc methods to the existing +`sdk.Query` and `QueryRouter` infrastructure. + +This basic specification allows us to reuse protocol buffer `service` definitions +for ABCI custom queries substantially reducing the need for manual decoding and +encoding in query methods. + +### GRPC Protocol Support + +In addition to providing an ABCI query pathway, we can easily provide a GRPC +proxy server that routes requests in the GRPC protocol to ABCI query requests +under the hood. In this way, clients could use their host languages' existing +GRPC implementations to make direct queries against Cosmos SDK app's using +these `service` definitions. In order for this server to work, the `QueryRouter` +on `BaseApp` will need to expose the service handlers registered with +`QueryRouter.RegisterService` to the proxy server implementation. Nodes could +launch the proxy server on a separate port in the same process as the ABCI app +with a command-line flag. + +### REST Queries and Swagger Generation + +[grpc-gateway](https://github.com/grpc-ecosystem/grpc-gateway) is a project that +translates REST calls into GRPC calls using special annotations on service +methods. Modules that want to expose REST queries should add `google.api.http` +annotations to their `rpc` methods as in this example below. + +```protobuf +// x/bank/types/types.proto + +service Query { + rpc QueryBalance(QueryBalanceParams) returns (cosmos_sdk.v1.Coin) { + option (google.api.http) = { + get: "/x/bank/v1/balance/{address}/{denom}" + }; + } + rpc QueryAllBalances(QueryAllBalancesParams) returns (QueryAllBalancesResponse) { + option (google.api.http) = { + get: "/x/bank/v1/balances/{address}" + }; + } +} +``` + +grpc-gateway will work direcly against the GRPC proxy described above which will +translate requests to ABCI queries under the hood. grpc-gateway can also +generate Swagger definitions automatically. + +In the current implementation of REST queries, each module needs to implement +REST queries manually in addition to ABCI querier methods. Using the grpc-gateway +approach, there will be no need to generate separate REST query handlers, just +query servers as described above as grpc-gateway handles the translation of protobuf +to REST as well as Swagger definitions. + +The 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. + +### Client Usage + +The gogo protobuf grpc plugin generates client interfaces in addition to server +interfaces. For the `Query` service defined above we would get a `QueryClient` +interface like: + +```go +type QueryClient interface { + QueryBalance(ctx context.Context, in *QueryBalanceParams, opts ...grpc.CallOption) (*types.Coin, error) + QueryAllBalances(ctx context.Context, in *QueryAllBalancesParams, opts ...grpc.CallOption) (*QueryAllBalancesResponse, error) +} +``` + +Via a small patch to gogo protobuf ([gogo/protobuf#675](https://github.com/gogo/protobuf/pull/675)) +we have tweaked the grpc codegen to use an interface rather than concrete type +for the generated client struct. This allows us to also reuse the GRPC infrastructure +for ABCI client queries. + +1Context`will receive a new method`QueryConn`that returns a`ClientConn` +that routes calls to ABCI queries + +Clients (such as CLI methods) will then be able to call query methods like this: + +```go +clientCtx := client.NewContext() +queryClient := types.NewQueryClient(clientCtx.QueryConn()) +params := &types.QueryBalanceParams{addr, denom} +result, err := queryClient.QueryBalance(gocontext.Background(), params) +``` + +### Testing + +Tests would be able to create a query client directly from keeper and `sdk.Context` +references using a `QueryServerTestHelper` as below: + +```go +queryHelper := baseapp.NewQueryServerTestHelper(ctx) +types.RegisterQueryServer(queryHelper, keeper.Querier{app.BankKeeper}) +queryClient := types.NewQueryClient(queryHelper) +``` + +## Future Improvements + +## Consequences + +### Positive + +* greatly simplified querier implementation (no manual encoding/decoding) +* easy query client generation (can use existing grpc and swagger tools) +* no need for REST query implementations +* type safe query methods (generated via grpc plugin) +* going forward, there will be less breakage of query methods because of the +backwards compatibility guarantees provided by buf + +### Negative + +* all clients using the existing ABCI/REST queries will need to be refactored +for both the new GRPC/REST query paths as well as protobuf/proto-json encoded +data, but this is more or less unavoidable in the protobuf refactoring + +### Neutral + +## References diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-022-custom-panic-handling.md b/versioned_docs/version-0.47/integrate/architecture/adr-022-custom-panic-handling.md new file mode 100644 index 000000000..6ed7b6246 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-022-custom-panic-handling.md @@ -0,0 +1,218 @@ +# ADR 022: Custom BaseApp panic handling + +## Changelog + +* 2020 Apr 24: Initial Draft +* 2021 Sep 14: Superseded by ADR-045 + +## Status + +SUPERSEDED by ADR-045 + +## Context + +The current implementation of BaseApp does not allow developers to write custom error handlers during panic recovery +[runTx()](https://github.com/cosmos/cosmos-sdk/blob/bad4ca75f58b182f600396ca350ad844c18fc80b/baseapp/baseapp.go#L539) +method. We think that this method can be more flexible and can give 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. + +We propose middleware-solution, which could help developers implement the following cases: + +* add external logging (let's say sending reports to external services like [Sentry](https://sentry.io)); +* call panic for specific error cases; + +It will also make `OutOfGas` case and `default` case one of the middlewares. +`Default` case wraps recovery object to an error and logs it ([example middleware implementation](#Recovery-middleware)). + +Our project has a sidecar service running alongside the blockchain node (smart contracts virtual machine). It is +essential that node <-> sidecar connectivity stays stable for TXs processing. So when the communication breaks we need +to crash the node and reboot it once the problem is solved. That behaviour makes node's state machine execution +deterministic. As all keeper panics are caught by runTx's `defer()` handler, we have to adjust the BaseApp code +in order to customize it. + +## Decision + +### Design + +#### Overview + +Instead of hardcoding custom error handling into BaseApp we suggest using set of middlewares which can be customized +externally and will allow developers use as many custom error handlers as they want. Implementation with tests +can be found [here](https://github.com/cosmos/cosmos-sdk/pull/6053). + +#### Implementation details + +##### Recovery handler + +New `RecoveryHandler` type added. `recoveryObj` input argument is an object returned by the standard Go function +`recover()` from the `builtin` package. + +```go +type RecoveryHandler func(recoveryObj interface{}) error +``` + +Handler should type assert (or other methods) an object to define if object should be handled. +`nil` should be returned if input object can't be handled by that `RecoveryHandler` (not a handler's target type). +Not `nil` error should be returned if input object was handled and middleware chain execution should be stopped. + +An example: + +```go +func exampleErrHandler(recoveryObj interface{}) error { + err, ok := recoveryObj.(error) + if !ok { return nil } + + if someSpecificError.Is(err) { + panic(customPanicMsg) + } else { + return nil + } +} +``` + +This example breaks the application execution, but it also might enrich the error's context like the `OutOfGas` handler. + +##### Recovery middleware + +We also add a middleware type (decorator). That function type wraps `RecoveryHandler` and returns the next middleware in +execution chain and handler's `error`. Type is used to separate actual `recovery()` object handling from middleware +chain processing. + +```go +type recoveryMiddleware func(recoveryObj interface{}) (recoveryMiddleware, error) + +func newRecoveryMiddleware(handler RecoveryHandler, next recoveryMiddleware) recoveryMiddleware { + return func(recoveryObj interface{}) (recoveryMiddleware, error) { + if err := handler(recoveryObj); err != nil { + return nil, err + } + return next, nil + } +} +``` + +Function receives a `recoveryObj` object and returns: + +* (next `recoveryMiddleware`, `nil`) if object wasn't handled (not a target type) by `RecoveryHandler`; +* (`nil`, not nil `error`) if input object was handled and other middlewares in the chain should not be executed; +* (`nil`, `nil`) in case of invalid behavior. Panic recovery might not have been properly handled; +this can be avoided by always using a `default` as a rightmost middleware in the chain (always returns an `error`'); + +`OutOfGas` middleware example: + +```go +func newOutOfGasRecoveryMiddleware(gasWanted uint64, ctx sdk.Context, next recoveryMiddleware) recoveryMiddleware { + handler := func(recoveryObj interface{}) error { + err, ok := recoveryObj.(sdk.ErrorOutOfGas) + if !ok { return nil } + + return sdkerrors.Wrap( + sdkerrors.ErrOutOfGas, fmt.Sprintf( + "out of gas in location: %v; gasWanted: %d, gasUsed: %d", err.Descriptor, gasWanted, ctx.GasMeter().GasConsumed(), + ), + ) + } + + return newRecoveryMiddleware(handler, next) +} +``` + +`Default` middleware example: + +```go +func newDefaultRecoveryMiddleware() recoveryMiddleware { + handler := func(recoveryObj interface{}) error { + return sdkerrors.Wrap( + sdkerrors.ErrPanic, fmt.Sprintf("recovered: %v\nstack:\n%v", recoveryObj, string(debug.Stack())), + ) + } + + return newRecoveryMiddleware(handler, nil) +} +``` + +##### Recovery processing + +Basic chain of middlewares processing would look like: + +```go +func processRecovery(recoveryObj interface{}, middleware recoveryMiddleware) error { + if middleware == nil { return nil } + + next, err := middleware(recoveryObj) + if err != nil { return err } + if next == nil { return nil } + + return processRecovery(recoveryObj, next) +} +``` + +That way we can create a middleware chain which is executed from left to right, the rightmost middleware is a +`default` handler which must return an `error`. + +##### BaseApp changes + +The `default` middleware chain must exist in a `BaseApp` object. `Baseapp` modifications: + +```go +type BaseApp struct { + // ... + runTxRecoveryMiddleware recoveryMiddleware +} + +func NewBaseApp(...) { + // ... + app.runTxRecoveryMiddleware = newDefaultRecoveryMiddleware() +} + +func (app *BaseApp) runTx(...) { + // ... + defer func() { + if r := recover(); r != nil { + recoveryMW := newOutOfGasRecoveryMiddleware(gasWanted, ctx, app.runTxRecoveryMiddleware) + err, result = processRecovery(r, recoveryMW), nil + } + + gInfo = sdk.GasInfo{GasWanted: gasWanted, GasUsed: ctx.GasMeter().GasConsumed()} + }() + // ... +} +``` + +Developers can add their custom `RecoveryHandler`s by providing `AddRunTxRecoveryHandler` as a BaseApp option parameter to the `NewBaseapp` constructor: + +```go +func (app *BaseApp) AddRunTxRecoveryHandler(handlers ...RecoveryHandler) { + for _, h := range handlers { + app.runTxRecoveryMiddleware = newRecoveryMiddleware(h, app.runTxRecoveryMiddleware) + } +} +``` + +This method would prepend handlers to an existing chain. + +## Consequences + +### Positive + +* Developers of Cosmos SDK based projects can add custom panic handlers to: + * add error context for custom panic sources (panic inside of custom keepers); + * emit `panic()`: passthrough recovery object to the Tendermint core; + * other necessary handling; +* Developers can use standard Cosmos SDK `BaseApp` implementation, rather that rewriting it in their projects; +* Proposed solution doesn't break the current "standard" `runTx()` flow; + +### Negative + +* Introduces changes to the execution model design. + +### Neutral + +* `OutOfGas` error handler becomes one of the middlewares; +* Default panic handler becomes one of the middlewares; + +## References + +* [PR-6053 with proposed solution](https://github.com/cosmos/cosmos-sdk/pull/6053) +* [Similar solution. ADR-010 Modular AnteHandler](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-010-modular-antehandler.md) diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-023-protobuf-naming.md b/versioned_docs/version-0.47/integrate/architecture/adr-023-protobuf-naming.md new file mode 100644 index 000000000..4360befde --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-023-protobuf-naming.md @@ -0,0 +1,263 @@ +# ADR 023: Protocol Buffer Naming and Versioning Conventions + +## Changelog + +* 2020 April 27: Initial Draft +* 2020 August 5: Update guidelines + +## Status + +Accepted + +## Context + +Protocol Buffers provide a basic [style guide](https://developers.google.com/protocol-buffers/docs/style) +and [Buf](https://buf.build/docs/style-guide) builds upon that. To the +extent possible, we want to follow industry accepted guidelines and wisdom for +the effective usage of protobuf, deviating from those only when there is clear +rationale for our use case. + +### Adoption of `Any` + +The adoption of `google.protobuf.Any` as the recommended approach for encoding +interface types (as opposed to `oneof`) makes package naming a central part +of the encoding as fully-qualified message names now appear in encoded +messages. + +### Current Directory Organization + +Thus far we have mostly followed [Buf's](https://buf.build) [DEFAULT](https://buf.build/docs/lint-checkers#default) +recommendations, with the minor deviation of disabling [`PACKAGE_DIRECTORY_MATCH`](https://buf.build/docs/lint-checkers#file_layout) +which although being convenient for developing code comes with the warning +from Buf that: + +> you will have a very bad time with many Protobuf plugins across various languages if you do not do this + +### Adoption of gRPC Queries + +In [ADR 021](adr-021-protobuf-query-encoding.md), gRPC was adopted for Protobuf +native queries. The full gRPC service path thus becomes a key part of ABCI query +path. In the future, gRPC queries may be allowed from within persistent scripts +by technologies such as CosmWasm and these query routes would be stored within +script binaries. + +## Decision + +The goal of this ADR is to provide thoughtful naming conventions that: + +* encourage a good user experience for when users interact directly with +.proto files and fully-qualified protobuf names +* balance conciseness against the possibility of either over-optimizing (making +names too short and cryptic) or under-optimizing (just accepting bloated names +with lots of redundant information) + +These guidelines are meant to act as a style guide for both the Cosmos SDK and +third-party modules. + +As a starting point, we should adopt all of the [DEFAULT](https://buf.build/docs/lint-checkers#default) +checkers in [Buf's](https://buf.build) including [`PACKAGE_DIRECTORY_MATCH`](https://buf.build/docs/lint-checkers#file_layout), +except: + +* [PACKAGE_VERSION_SUFFIX](https://buf.build/docs/lint-checkers#package_version_suffix) +* [SERVICE_SUFFIX](https://buf.build/docs/lint-checkers#service_suffix) + +Further guidelines to be described below. + +### Principles + +#### Concise and Descriptive Names + +Names should be descriptive enough to convey their meaning and distinguish +them from other names. + +Given that we are using fully-qualifed names within +`google.protobuf.Any` as well as within gRPC query routes, we should aim to +keep names concise, without going overboard. The general rule of thumb should +be if a shorter name would convey more or else the same thing, pick the shorter +name. + +For instance, `cosmos.bank.MsgSend` (19 bytes) conveys roughly the same information +as `cosmos_sdk.x.bank.v1.MsgSend` (28 bytes) but is more concise. + +Such conciseness makes names both more pleasant to work with and take up less +space within transactions and on the wire. + +We should also resist the temptation to over-optimize, by making names +cryptically short with abbreviations. For instance, we shouldn't try to +reduce `cosmos.bank.MsgSend` to `csm.bk.MSnd` just to save a few bytes. + +The goal is to make names **_concise but not cryptic_**. + +#### Names are for Clients First + +Package and type names should be chosen for the benefit of users, not +necessarily because of legacy concerns related to the go code-base. + +#### Plan for Longevity + +In the interests of long-term support, we should plan on the names we do +choose to be in usage for a long time, so now is the opportunity to make +the best choices for the future. + +### Versioning + +#### Guidelines on Stable Package Versions + +In general, schema evolution is the way to update protobuf schemas. That means that new fields, +messages, and RPC methods are _added_ to existing schemas and old fields, messages and RPC methods +are maintained as long as possible. + +Breaking things is often unacceptable in a blockchain scenario. For instance, immutable smart contracts +may depend on certain data schemas on the host chain. If the host chain breaks those schemas, the smart +contract may be irreparably broken. Even when things can be fixed (for instance in client software), +this often comes at a high cost. + +Instead of breaking things, we should make every effort to evolve schemas rather than just breaking them. +[Buf](https://buf.build) breaking change detection should be used on all stable (non-alpha or beta) packages +to prevent such breakage. + +With that in mind, different stable versions (i.e. `v1` or `v2`) of a package should more or less be considered +different packages and this should be last resort approach for upgrading protobuf schemas. Scenarios where creating +a `v2` may make sense are: + +* we want to create a new module with similar functionality to an existing module and adding `v2` is the most natural +way to do this. In that case, there are really just two different, but similar modules with different APIs. +* we want to add a new revamped API for an existing module and it's just too cumbersome to add it to the existing package, +so putting it in `v2` is cleaner for users. In this case, care should be made to not deprecate support for +`v1` if it is actively used in immutable smart contracts. + +#### Guidelines on unstable (alpha and beta) package versions + +The following guidelines are recommended for marking packages as alpha or beta: + +* marking something as `alpha` or `beta` should be a last resort and just putting something in the +stable package (i.e. `v1` or `v2`) should be preferred +* a package _should_ be marked as `alpha` _if and only if_ there are active discussions to remove +or significantly alter the package in the near future +* a package _should_ be marked as `beta` _if and only if_ there is an active discussion to +significantly refactor/rework the functionality in the near future but not remove it +* modules _can and should_ have types in both stable (i.e. `v1` or `v2`) and unstable (`alpha` or `beta`) packages. + +_`alpha` and `beta` should not be used to avoid responsibility for maintaining compatibility._ +Whenever code is released into the wild, especially on a blockchain, there is a high cost to changing things. In some +cases, for instance with immutable smart contracts, a breaking change may be impossible to fix. + +When marking something as `alpha` or `beta`, maintainers should ask the questions: + +* what is the cost of asking others to change their code vs the benefit of us maintaining the optionality to change it? +* what is the plan for moving this to `v1` and how will that affect users? + +`alpha` or `beta` should really be used to communicate "changes are planned". + +As a case study, gRPC reflection is in the package `grpc.reflection.v1alpha`. It hasn't been changed since +2017 and it is now used in other widely used software like gRPCurl. Some folks probably use it in production services +and so if they actually went and changed the package to `grpc.reflection.v1`, some software would break and +they probably don't want to do that... So now the `v1alpha` package is more or less the de-facto `v1`. Let's not do that. + +The following are guidelines for working with non-stable packages: + +* [Buf's recommended version suffix](https://buf.build/docs/lint-checkers#package_version_suffix) +(ex. `v1alpha1`) _should_ be used for non-stable packages +* non-stable packages should generally be excluded from breaking change detection +* immutable smart contract modules (i.e. CosmWasm) _should_ block smart contracts/persistent +scripts from interacting with `alpha`/`beta` packages + +#### Omit v1 suffix + +Instead of using [Buf's recommended version suffix](https://buf.build/docs/lint-checkers#package_version_suffix), +we can omit `v1` for packages that don't actually have a second version. This +allows for more concise names for common use cases like `cosmos.bank.Send`. +Packages that do have a second or third version can indicate that with `.v2` +or `.v3`. + +### Package Naming + +#### Adopt a short, unique top-level package name + +Top-level packages should adopt a short name that is known to not collide with +other names in common usage within the Cosmos ecosystem. In the near future, a +registry should be created to reserve and index top-level package names used +within the Cosmos ecosystem. Because the Cosmos SDK is intended to provide +the top-level types for the Cosmos project, the top-level package name `cosmos` +is recommended for usage within the Cosmos SDK instead of the longer `cosmos_sdk`. +[ICS](https://github.com/cosmos/ics) specifications could consider a +short top-level package like `ics23` based upon the standard number. + +#### Limit sub-package depth + +Sub-package depth should be increased with caution. Generally a single +sub-package is needed for a module or a library. Even though `x` or `modules` +is used in source code to denote modules, this is often unnecessary for .proto +files as modules are the primary thing sub-packages are used for. Only items which +are known to be used infrequently should have deep sub-package depths. + +For the Cosmos SDK, it is recommended that that we simply write `cosmos.bank`, +`cosmos.gov`, etc. rather than `cosmos.x.bank`. In practice, most non-module +types can go straight in the `cosmos` package or we can introduce a +`cosmos.base` package if needed. Note that this naming _will not_ change +go package names, i.e. the `cosmos.bank` protobuf package will still live in +`x/bank`. + +### Message Naming + +Message type names should be as concise possible without losing clarity. `sdk.Msg` +types which are used in transactions will retain the `Msg` prefix as that provides +helpful context. + +### Service and RPC Naming + +[ADR 021](adr-021-protobuf-query-encoding.md) specifies that modules should +implement a gRPC query service. We should consider the principle of conciseness +for query service and RPC names as these may be called from persistent script +modules such as CosmWasm. Also, users may use these query paths from tools like +[gRPCurl](https://github.com/fullstorydev/grpcurl). As an example, we can shorten +`/cosmos_sdk.x.bank.v1.QueryService/QueryBalance` to +`/cosmos.bank.Query/Balance` without losing much useful information. + +RPC request and response types _should_ follow the `ServiceNameMethodNameRequest`/ +`ServiceNameMethodNameResponse` naming convention. i.e. for an RPC method named `Balance` +on the `Query` service, the request and response types would be `QueryBalanceRequest` +and `QueryBalanceResponse`. This will be more self-explanatory than `BalanceRequest` +and `BalanceResponse`. + +#### Use just `Query` for the query service + +Instead of [Buf's default service suffix recommendation](https://github.com/cosmos/cosmos-sdk/pull/6033), +we should simply use the shorter `Query` for query services. + +For other types of gRPC services, we should consider sticking with Buf's +default recommendation. + +#### Omit `Get` and `Query` from query service RPC names + +`Get` and `Query` should be omitted from `Query` service names because they are +redundant in the fully-qualified name. For instance, `/cosmos.bank.Query/QueryBalance` +just says `Query` twice without any new information. + +## Future Improvements + +A registry of top-level package names should be created to coordinate naming +across the ecosystem, prevent collisions, and also help developers discover +useful schemas. A simple starting point would be a git repository with +community-based governance. + +## Consequences + +### Positive + +* names will be more concise and easier to read and type +* all transactions using `Any` will be at shorter (`_sdk.x` and `.v1` will be removed) +* `.proto` file imports will be more standard (without `"third_party/proto"` in +the path) +* code generation will be easier for clients because .proto files will be +in a single `proto/` directory which can be copied rather than scattered +throughout the Cosmos SDK + +### Negative + +### Neutral + +* `.proto` files will need to be reorganized and refactored +* some modules may need to be marked as alpha or beta + +## References diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-024-coin-metadata.md b/versioned_docs/version-0.47/integrate/architecture/adr-024-coin-metadata.md new file mode 100644 index 000000000..3c55f80f0 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-024-coin-metadata.md @@ -0,0 +1,139 @@ +# ADR 024: Coin Metadata + +## Changelog + +* 05/19/2020: Initial draft + +## Status + +Proposed + +## Context + +Assets in the Cosmos SDK are represented via a `Coins` type that consists of an `amount` and a `denom`, +where the `amount` can be any arbitrarily large or small value. In addition, the Cosmos SDK uses an +account-based model where there are two types of primary accounts -- basic accounts and module accounts. +All account types have a set of balances that are composed of `Coins`. The `x/bank` module keeps +track of all balances for all accounts and also keeps track of the total supply of balances in an +application. + +With regards to a balance `amount`, the Cosmos SDK assumes a static and fixed unit of denomination, +regardless of the denomination itself. In other words, clients and apps built atop a Cosmos-SDK-based +chain may choose to define and use arbitrary units of denomination to provide a richer UX, however, by +the time a tx or operation reaches the Cosmos SDK state machine, the `amount` is treated as a single +unit. For example, for the Cosmos Hub (Gaia), clients assume 1 ATOM = 10^6 uatom, and so all txs and +operations in the Cosmos SDK work off of units of 10^6. + +This clearly provides a poor and limited UX especially as interoperability of networks increases and +as a result the total amount of asset types increases. We propose to have `x/bank` additionally keep +track of metadata per `denom` in order to help clients, wallet providers, and explorers improve their +UX and remove the requirement for making any assumptions on the unit of denomination. + +## Decision + +The `x/bank` module will be updated to store and index metadata by `denom`, specifically the "base" or +smallest unit -- the unit the Cosmos SDK state-machine works with. + +Metadata may also include a non-zero length list of denominations. Each entry contains the name of +the denomination `denom`, the exponent to the base and a list of aliases. An entry is to be +interpreted as `1 denom = 10^exponent base_denom` (e.g. `1 ETH = 10^18 wei` and `1 uatom = 10^0 uatom`). + +There are two denominations that are of high importance for clients: the `base`, which is the smallest +possible unit and the `display`, which is the unit that is commonly referred to in human communication +and on exchanges. The values in those fields link to an entry in the list of denominations. + +The list in `denom_units` and the `display` entry may be changed via governance. + +As a result, we can define the type as follows: + +```protobuf +message DenomUnit { + string denom = 1; + uint32 exponent = 2; + repeated string aliases = 3; +} + +message Metadata { + string description = 1; + repeated DenomUnit denom_units = 2; + string base = 3; + string display = 4; +} +``` + +As an example, the ATOM's metadata can be defined as follows: + +```json +{ + "description": "The native staking token of the Cosmos Hub.", + "denom_units": [ + { + "denom": "uatom", + "exponent": 0, + "aliases": [ + "microatom" + ], + }, + { + "denom": "matom", + "exponent": 3, + "aliases": [ + "milliatom" + ] + }, + { + "denom": "atom", + "exponent": 6, + } + ], + "base": "uatom", + "display": "atom", +} +``` + +Given the above metadata, a client may infer the following things: + +* 4.3atom = 4.3 * (10^6) = 4,300,000uatom +* The string "atom" can be used as a display name in a list of tokens. +* The balance 4300000 can be displayed as 4,300,000uatom or 4,300matom or 4.3atom. + The `display` denomination 4.3atom is a good default if the authors of the client don't make + an explicit decision to choose a different representation. + +A client should be able to query for metadata by denom both via the CLI and REST interfaces. In +addition, we will add handlers to these interfaces to convert from any unit to another given unit, +as the base framework for this already exists in the Cosmos SDK. + +Finally, we need to ensure metadata exists in the `GenesisState` of the `x/bank` module which is also +indexed by the base `denom`. + +```go +type GenesisState struct { + SendEnabled bool `json:"send_enabled" yaml:"send_enabled"` + Balances []Balance `json:"balances" yaml:"balances"` + Supply sdk.Coins `json:"supply" yaml:"supply"` + DenomMetadata []Metadata `json:"denom_metadata" yaml:"denom_metadata"` +} +``` + +## Future Work + +In order for clients to avoid having to convert assets to the base denomination -- either manually or +via an endpoint, we may consider supporting automatic conversion of a given unit input. + +## Consequences + +### Positive + +* Provides clients, wallet providers and block explorers with additional data on + asset denomination to improve UX and remove any need to make assumptions on + denomination units. + +### Negative + +* A small amount of required additional storage in the `x/bank` module. The amount + of additional storage should be minimal as the amount of total assets should not + be large. + +### Neutral + +## References diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-027-deterministic-protobuf-serialization.md b/versioned_docs/version-0.47/integrate/architecture/adr-027-deterministic-protobuf-serialization.md new file mode 100644 index 000000000..66ce6e2b7 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-027-deterministic-protobuf-serialization.md @@ -0,0 +1,314 @@ +# ADR 027: Deterministic Protobuf Serialization + +## Changelog + +* 2020-08-07: Initial Draft +* 2020-09-01: Further clarify rules + +## Status + +Proposed + +## Abstract + +Fully deterministic structure serialization, which works across many languages and clients, +is needed when signing messages. We need to be sure that whenever we serialize +a data structure, no matter in which supported language, the raw bytes +will stay the same. +[Protobuf](https://developers.google.com/protocol-buffers/docs/proto3) +serialization is not bijective (i.e. there exist a practically unlimited number of +valid binary representations for a given protobuf document)1. + +This document describes a deterministic serialization scheme for +a subset of protobuf documents, that covers this use case but can be reused in +other cases as well. + +### Context + +For signature verification in Cosmos SDK, the signer and verifier need to agree on +the same serialization of a `SignDoc` as defined in +[ADR-020](./adr-020-protobuf-transaction-encoding.md) without transmitting the +serialization. + +Currently, for block signatures we are using a workaround: we create a new [TxRaw](https://github.com/cosmos/cosmos-sdk/blob/9e85e81e0e8140067dd893421290c191529c148c/proto/cosmos/tx/v1beta1/tx.proto#L30) +instance (as defined in [adr-020-protobuf-transaction-encoding](https://github.com/cosmos/cosmos-sdk/blob/main/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/cosmos/gogoproto/gogoproto) is known to + be compliant by in most cases, but not when certain annotations such as + `nullable = false` are used. It might also be an option to configure an + existing serializer accordingly. +* **Normalize default values before encoding them.** If your serializer follows + rule 1. and 2. and allows you to explicitly unset fields for serialization, + you can normalize default values to unset. This can be done when working with + [protobuf.js](https://www.npmjs.com/package/protobufjs): + + ```js + const bytes = SignDoc.encode({ + bodyBytes: body.length > 0 ? body : null, // normalize empty bytes to unset + authInfoBytes: authInfo.length > 0 ? authInfo : null, // normalize empty bytes to unset + chainId: chainId || null, // normalize "" to unset + accountNumber: accountNumber || null, // normalize 0 to unset + accountSequence: accountSequence || null, // normalize 0 to unset + }).finish(); + ``` + +* **Use a hand-written serializer for the types you need.** If none of the above + ways works for you, you can write a serializer yourself. For SignDoc this + would look something like this in Go, building on existing protobuf utilities: + + ```go + if !signDoc.body_bytes.empty() { + buf.WriteUVarInt64(0xA) // wire type and field number for body_bytes + buf.WriteUVarInt64(signDoc.body_bytes.length()) + buf.WriteBytes(signDoc.body_bytes) + } + + if !signDoc.auth_info.empty() { + buf.WriteUVarInt64(0x12) // wire type and field number for auth_info + buf.WriteUVarInt64(signDoc.auth_info.length()) + buf.WriteBytes(signDoc.auth_info) + } + + if !signDoc.chain_id.empty() { + buf.WriteUVarInt64(0x1a) // wire type and field number for chain_id + buf.WriteUVarInt64(signDoc.chain_id.length()) + buf.WriteBytes(signDoc.chain_id) + } + + if signDoc.account_number != 0 { + buf.WriteUVarInt64(0x20) // wire type and field number for account_number + buf.WriteUVarInt(signDoc.account_number) + } + + if signDoc.account_sequence != 0 { + buf.WriteUVarInt64(0x28) // wire type and field number for account_sequence + buf.WriteUVarInt(signDoc.account_sequence) + } + ``` + +### Test vectors + +Given the protobuf definition `Article.proto` + +```protobuf +package blog; +syntax = "proto3"; + +enum Type { + UNSPECIFIED = 0; + IMAGES = 1; + NEWS = 2; +}; + +enum Review { + UNSPECIFIED = 0; + ACCEPTED = 1; + REJECTED = 2; +}; + +message Article { + string title = 1; + string description = 2; + uint64 created = 3; + uint64 updated = 4; + bool public = 5; + bool promoted = 6; + Type type = 7; + Review review = 8; + repeated string comments = 9; + repeated string backlinks = 10; +}; +``` + +serializing the values + +```yaml +title: "The world needs change 🌳" +description: "" +created: 1596806111080 +updated: 0 +public: true +promoted: false +type: Type.NEWS +review: Review.UNSPECIFIED +comments: ["Nice one", "Thank you"] +backlinks: [] +``` + +must result in the serialization + +```text +0a1b54686520776f726c64206e65656473206368616e676520f09f8cb318e8bebec8bc2e280138024a084e696365206f6e654a095468616e6b20796f75 +``` + +When inspecting the serialized document, you see that every second field is +omitted: + +```shell +$ echo 0a1b54686520776f726c64206e65656473206368616e676520f09f8cb318e8bebec8bc2e280138024a084e696365206f6e654a095468616e6b20796f75 | xxd -r -p | protoc --decode_raw +1: "The world needs change \360\237\214\263" +3: 1596806111080 +5: 1 +7: 2 +9: "Nice one" +9: "Thank you" +``` + +## Consequences + +Having such an encoding available allows us to get deterministic serialization +for all protobuf documents we need in the context of Cosmos SDK signing. + +### Positive + +* Well defined rules that can be verified independent of a reference + implementation +* Simple enough to keep the barrier to implement transaction signing low +* It allows us to continue to use 0 and other empty values in SignDoc, avoiding + the need to work around 0 sequences. This does not imply the change from + https://github.com/cosmos/cosmos-sdk/pull/6949 should not be merged, but not + too important anymore. + +### Negative + +* When implementing transaction signing, the encoding rules above must be + understood and implemented. +* The need for rule number 3. adds some complexity to implementations. +* Some data structures may require custom code for serialization. Thus + the code is not very portable - it will require additional work for each + client implementing serialization to properly handle custom data structures. + +### Neutral + +### Usage in Cosmos SDK + +For the reasons mentioned above ("Negative" section) we prefer to keep workarounds +for shared data structure. Example: the aforementioned `TxRaw` is using raw bytes +as a workaround. This allows them to use any valid Protobuf library without +the need of implementing a custom serializer that adheres to this standard (and related risks of bugs). + +## References + +* 1 _When a message is serialized, there is no guaranteed order for + how its known or unknown fields should be written. Serialization order is an + implementation detail and the details of any particular implementation may + change in the future. Therefore, protocol buffer parsers must be able to parse + fields in any order._ from + https://developers.google.com/protocol-buffers/docs/encoding#order +* 2 https://developers.google.com/protocol-buffers/docs/encoding#signed_integers +* 3 _Note that for scalar message fields, once a message is parsed + there's no way of telling whether a field was explicitly set to the default + value (for example whether a boolean was set to false) or just not set at all: + you should bear this in mind when defining your message types. For example, + don't have a boolean that switches on some behavior when set to false if you + don't want that behavior to also happen by default._ from + https://developers.google.com/protocol-buffers/docs/proto3#default +* 4 _When a message is parsed, if the encoded message does not + contain a particular singular element, the corresponding field in the parsed + object is set to the default value for that field._ from + https://developers.google.com/protocol-buffers/docs/proto3#default +* 5 _Also note that if a scalar message field is set to its default, + the value will not be serialized on the wire._ from + https://developers.google.com/protocol-buffers/docs/proto3#default +* 6 _For enums, the default value is the first defined enum value, + which must be 0._ from + https://developers.google.com/protocol-buffers/docs/proto3#default +* 7 _For message fields, the field is not set. Its exact value is + language-dependent._ from + https://developers.google.com/protocol-buffers/docs/proto3#default +* Encoding rules and parts of the reasoning taken from + [canonical-proto3 Aaron Craelius](https://github.com/regen-network/canonical-proto3) diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-028-public-key-addresses.md b/versioned_docs/version-0.47/integrate/architecture/adr-028-public-key-addresses.md new file mode 100644 index 000000000..9f394f7a2 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-028-public-key-addresses.md @@ -0,0 +1,342 @@ +# ADR 028: Public Key Addresses + +## Changelog + +* 2020/08/18: Initial version +* 2021/01/15: Analysis and algorithm update + +## 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. + +## 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. + +### 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. + +### 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: + +> I spent quite a bit of time thinking about this issue while building weave... The other cosmos Sdk. +> Basically I define a condition to be a type and format as human readable string with some binary data appended. This condition is hashed into an Address (again at 20 bytes). The use of this prefix makes it impossible to find a preimage for a given address with a different condition (eg ed25519 vs secp256k1). +> This is explained in depth here https://weave.readthedocs.io/en/latest/design/permissions.html +> And the code is here, look mainly at the top where we process conditions. https://github.com/iov-one/weave/blob/master/conditions.go + +And explained how this approach should be sufficiently collision resistant: + +> Yeah, AFAIK, 20 bytes should be collision resistance when the preimages are unique and not malleable. A space of 2^160 would expect some collision to be likely around 2^80 elements (birthday paradox). And if you want to find a collision for some existing element in the database, it is still 2^160. 2^80 only is if all these elements are written to state. +> The good example you brought up was eg. a public key bytes being a valid public key on two algorithms supported by the codec. Meaning if either was broken, you would break accounts even if they were secured with the safer variant. This is only as the issue when no differentiating type info is present in the preimage (before hashing into an address). +> I would like to hear an argument if the 20 bytes space is an actual issue for security, as I would be happy to increase my address sizes in weave. I just figured cosmos and ethereum and bitcoin all use 20 bytes, it should be good enough. And the arguments above which made me feel it was secure. But I have not done a deeper analysis. + +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]`. + +### 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. + +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. + +### 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. + +### 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. + +## 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 + +### 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: + +* secp256k1: `ripemd160(sha256(pk_bytes))[:20]` +* legacy amino multisig: `sha256(aminoCdc.Marshal(pk))[:20]` + +We don't want to change existing addresses. So the addresses for these two key types will remain the same. + +The current multisig public keys use amino serialization to generate the address. We will retain +those public keys and their address formatting, and call them "legacy amino" multisig public keys +in protobuf. We will also create multisig public keys without amino addresses to be described below. + +### Hash Function Choice + +As in other parts of the Cosmos SDK, we will use `sha256`. + +### Basic Address + +We start with defining a base algorithm for generating addresses which we will call `Hash`. 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, explained in the next section. `hash` is the cryptographic hash function defined in the previous section. + +```go +const A_LEN = 32 + +func Hash(typ string, key []byte) []byte { + return hash(hash(typ) + key)[:A_LEN] +} +``` + +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. + +`address.Hash` is a low level function to generate _base_ addresses for new key types. Example: + +* BLS: `address.Hash("bls", pubkey)` + +### Composed Addresses + +For simple composed accounts (like a 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. + +```go +// We don't need a PubKey interface - we need anything which is addressable. +type Addressable interface { + Address() []byte +} + +func Composed(typ string, subaccounts []Addressable) []byte { + addresses = map(subaccounts, \a -> LengthPrefix(a.Address())) + addresses = sort(addresses) + return address.Hash(typ, addresses[0] + ... + addresses[n]) +} +``` + +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))` if `as = bs`. + +Implementation Tip: account implementations should cache addresses. + +#### Multisig Addresses + +For a 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. + +Example: + +```protobuf +package cosmos.crypto.multisig; + +message PubKey { + uint32 threshold = 1; + repeated google.protobuf.Any pubkeys = 2; +} +``` + +```go +func (multisig PubKey) Address() { + // 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 + prefix := fmt.Sprintf("%s/%d", proto.MessageName(multisig), multisig.Threshold) + + // use the Composed function defined above + return address.Composed(prefix, keys) +} +``` + + +### 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: + +```go +func Derive(address, derivationKey []byte) []byte { + return Hash(addres, derivationKey) +} +``` + +### Module Account Addresses + +A module account will have `"module"` type. Module accounts can have sub accounts. The submodule account will be created based on module name, and sequence of derivation keys. Typically, the first derivation key should be a class of the derived accounts. The derivation process has a defined order: module name, submodule key, subsubmodule key... An example module account is created using: + +```go +address.Module(moduleName, key) +``` + +An example sub-module account is created using: + +```go +groupPolicyAddresses := []byte{1} +address.Module(moduleName, groupPolicyAddresses, policyID) +``` + +The `address.Module` function is using `address.Hash` with `"module"` as the type argument, and byte representation of the module name concatenated with submodule key. The two last component must be uniquely separated to avoid potential clashes (example: modulename="ab" & submodulekey="bc" will have the same derivation key as modulename="a" & submodulekey="bbc"). +We use a null byte (`'\x00'`) to separate module name from the submodule key. This works, because null byte is not a part of a valid module name. Finally, the sub-submodule accounts are created by applying the `Derive` function recursively. +We could use `Derive` function also in the first step (rather than concatenating module name with zero byte and the submodule key). We decided to do concatenation to avoid one level of derivation and speed up computation. + +For backward compatibility with the existing `authtypes.NewModuleAddress`, we add a special case in `Module` function: when no derivation key is provided, we fallback to the "legacy" implementation. + +```go +func Module(moduleName string, derivationKeys ...[]byte) []byte{ + if len(derivationKeys) == 0 { + return authtypes.NewModuleAddress(modulenName) // legacy case + } + submoduleAddress := Hash("module", []byte(moduleName) + 0 + key) + return fold((a, k) => Derive(a, k), subsubKeys, submoduleAddress) +} +``` + +**Example 1** A lending BTC pool address would be: + +```go +btcPool := address.Module("lending", btc.Address()}) +``` + +If we want to create an address for a module account depending on more than one key, we can concatenate them: + +```go +btcAtomAMM := address.Module("amm", btc.Address() + atom.Address()}) +``` + +**Example 2** a smart-contract address could be constructed by: + +```go +smartContractAddr = Module("mySmartContractVM", smartContractsNamespace, smartContractKey}) + +// which equals to: +smartContractAddr = Derived( + Module("mySmartContractVM", 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. + +Example: all public key types have a unique protobuf message type similar to: + +```protobuf +package cosmos.crypto.sr25519; + +message PubKey { + bytes key = 1; +} +``` + +All protobuf messages have unique fully qualified names, in this example `cosmos.crypto.sr25519.PubKey`. +These names are derived directly from .proto files in a standardized way and used +in other places such as the type URL in `Any`s. We can easily obtain the name using +`proto.MessageName(msg)`. + +## Consequences + +### Backwards Compatibility + +This ADR is compatible with what was committed and directly supported in the Cosmos SDK repository. + +### 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. + +### 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 + +### Neutral + +* protobuf message names are used as key type prefixes + +## 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. + +## 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. + +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 + +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. + +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. + +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). + +Discssion about arithmetic hash function for 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. + +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. + +### References + +* [Notes](https://hackmd.io/_NGWI4xZSbKzj1BkCqyZMw) diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-029-fee-grant-module.md b/versioned_docs/version-0.47/integrate/architecture/adr-029-fee-grant-module.md new file mode 100644 index 000000000..6b52556ff --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-029-fee-grant-module.md @@ -0,0 +1,153 @@ +# ADR 029: Fee Grant Module + +## Changelog + +* 2020/08/18: Initial Draft +* 2021/05/05: Removed height based expiration support and simplified naming. + +## Status + +Accepted + +## Context + +In order to make blockchain transactions, the signing account must possess a sufficient balance of the right denomination +in order to pay fees. There are classes of transactions where needing to maintain a wallet with sufficient fees is a +barrier to adoption. + +For instance, when proper permissions are setup, someone may temporarily delegate the ability to vote on proposals to +a "burner" account that is stored on a mobile phone with only minimal security. + +Other use cases include workers tracking items in a supply chain or farmers submitting field data for analytics +or compliance purposes. + +For all of these use cases, UX would be significantly enhanced by obviating the need for these accounts to always +maintain the appropriate fee balance. This is especially true if we wanted to achieve enterprise adoption for something +like supply chain tracking. + +While one solution would be to have a service that fills up these accounts automatically with the appropriate fees, a better UX +would be provided by allowing these accounts to pull from a common fee pool account with proper spending limits. +A single pool would reduce the churn of making lots of small "fill up" transactions and also more effectively leverages +the resources of the organization setting up the pool. + +## Decision + +As a solution we propose a module, `x/feegrant` which allows one account, the "granter" to grant another account, the "grantee" +an allowance to spend the granter's account balance for fees within certain well-defined limits. + +Fee allowances are defined by the extensible `FeeAllowanceI` interface: + +```go +type FeeAllowanceI { + // Accept can use fee payment requested as well as timestamp 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() error +} +``` + +Two basic fee allowance types, `BasicAllowance` and `PeriodicAllowance` are defined to support known use cases: + +```protobuf +// 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. + repeated cosmos_sdk.v1.Coin spend_limit = 1; + + // 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. +message PeriodicAllowance { + BasicAllowance basic = 1; + + // 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 + repeated cosmos_sdk.v1.Coin period_spend_limit = 3; + + // period_can_spend is the number of coins left to be spent before the period_reset time + repeated cosmos_sdk.v1.Coin period_can_spend = 4; + + // period_reset is the time at which this period resets and a new one begins, + // it is calculated from the start time of the first transaction after the + // last period ended + google.protobuf.Timestamp period_reset = 5; +} + +``` + +Allowances can be granted and revoked using `MsgGrantAllowance` and `MsgRevokeAllowance`: + +```protobuf +// 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. + message MsgRevokeAllowance { + string granter = 1; + string grantee = 2; + } +``` + +In order to use allowances in transactions, we add a new field `granter` to the transaction `Fee` type: + +```protobuf +package cosmos.tx.v1beta1; + +message Fee { + repeated cosmos.base.v1beta1.Coin amount = 1; + uint64 gas_limit = 2; + string payer = 3; + string granter = 4; +} +``` + +`granter` must either be left empty or must correspond to an account which has granted +a fee allowance to fee payer (either the first signer or the value of the `payer` field). + +A new `AnteDecorator` named `DeductGrantedFeeDecorator` will be created in order to process transactions with `fee_payer` +set and correctly deduct fees based on fee allowances. + +## Consequences + +### Positive + +* improved UX for use cases where it is cumbersome to maintain an account balance just for fees + +### Negative + +### Neutral + +* a new field must be added to the transaction `Fee` message and a new `AnteDecorator` must be +created to use it + +## References + +* Blog article describing initial work: https://medium.com/regen-network/hacking-the-cosmos-cosmwasm-and-key-management-a08b9f561d1b +* Initial public specification: https://gist.github.com/aaronc/b60628017352df5983791cad30babe56 +* Original subkeys proposal from B-harvest which influenced this design: https://github.com/cosmos/cosmos-sdk/issues/4480 diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-030-authz-module.md b/versioned_docs/version-0.47/integrate/architecture/adr-030-authz-module.md new file mode 100644 index 000000000..5aab72c5c --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-030-authz-module.md @@ -0,0 +1,258 @@ +# ADR 030: Authorization Module + +## 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) +* 2022-04-20: Updated the `SendAuthorization` proto docs to clarify the `SpendLimit` is a required field. (Generic authorization can be used with bank msg type url to create limit less bank authorization) + +## 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. + +## 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/cosmos/cosmos-sdk/tree/main/x/group). + +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). + +## 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. + +### 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. + +#### 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() string + + // 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() error +} + +// 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. + Accept bool + // 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. + Updated Authorization +} +``` + +For example a `SendAuthorization` like this is defined for `MsgSend` that takes +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. This field is required. (Generic authorization + // can be used with bank msg type url to create limit less bank authorization). + SpendLimit sdk.Coins +} + +func (a SendAuthorization) MsgTypeURL() string { + return sdk.MsgTypeURL(&MsgSend{}) +} + +func (a SendAuthorization) Accept(ctx sdk.Context, msg sdk.Msg) (authz.AcceptResponse, error) { + mSend, ok := msg.(*MsgSend) + if !ok { + return authz.AcceptResponse{}, sdkerrors.ErrInvalidType.Wrap("type mismatch") + } + limitLeft, isNegative := a.SpendLimit.SafeSub(mSend.Amount) + if isNegative { + return authz.AcceptResponse{}, sdkerrors.ErrInsufficientFunds.Wrapf("requested amount is more than spend limit") + } + if limitLeft.IsZero() { + return authz.AcceptResponse{Accept: true, Delete: true}, nil + } + + return authz.AcceptResponse{Accept: true, Delete: false, Updated: &SendAuthorization{SpendLimit: limitLeft}}, nil +} +``` + +A different type of capability for `MsgSend` could be implemented +using the `Authorization` interface with no need to change the underlying +`bank` module. + +##### Small notes on `AcceptResponse` + +* The `AcceptResponse.Accept` field will be set to `true` if the authorization is accepted. +However, if it is rejected, the function `Accept` will raise an error (without setting `AcceptResponse.Accept` to `false`). + +* The `AcceptResponse.Updated` field will be set to a non-nil value only if there is a real change to the authorization. +If authorization remains the same (as is, for instance, always the case for a [`GenericAuthorization`](#genericauthorization)), +the field will be `nil`. + +### `Msg` Service + +```protobuf +service Msg { + // 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. + 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. + rpc Revoke(MsgRevoke) returns (MsgRevokeResponse); +} + +// Grant gives permissions to execute +// the provided method with expiration time. +message Grant { + google.protobuf.Any authorization = 1 [(cosmos_proto.accepts_interface) = "cosmos.authz.v1beta1.Authorization"]; + google.protobuf.Timestamp expiration = 2 [(gogoproto.stdtime) = true, (gogoproto.nullable) = false]; +} + +message MsgGrant { + string granter = 1; + string grantee = 2; + + Grant grant = 3 [(gogoproto.nullable) = false]; +} + +message MsgExecResponse { + cosmos.base.abci.v1beta1.Result result = 1; +} + +message MsgExec { + string grantee = 1; + // Authorization Msg requests to execute. Each msg must implement Authorization interface + repeated google.protobuf.Any msgs = 2 [(cosmos_proto.accepts_interface) = "cosmos.base.v1beta1.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: + +```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(ctx sdk.Context, grantee sdk.AccAddress, msgs []sdk.Msg) sdk.Result` +} +``` + +### CLI + +#### `tx exec` Method + +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: + +```go +MsgExec { + Grantee: mykey, + Msgs: []sdk.Msg{ + MsgVote { + ProposalID: 1, + Voter: cosmos3thsdgh983egh823 + Option: Yes + } + } +} +``` + +#### `tx grant --from ` + +This CLI command will send a `MsgGrant` transaction. `authorization` should be encoded as +JSON on the CLI. + +#### `tx revoke --from ` + +This CLI command will send a `MsgRevoke` transaction. + +### Built-in Authorizations + +#### `SendAuthorization` + +```protobuf +// 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; +} +``` + +#### `GenericAuthorization` + +```protobuf +// 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 + 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 + +### 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 diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-031-msg-service.md b/versioned_docs/version-0.47/integrate/architecture/adr-031-msg-service.md new file mode 100644 index 000000000..861f4b3f3 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-031-msg-service.md @@ -0,0 +1,202 @@ +# ADR 031: Protobuf Msg Services + +## 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). + +## Status + +Accepted + +## Abstract + +We want to leverage protobuf `service` definitions for defining `Msg`s which will give us significant developer UX +improvements in terms of the code that is generated and the fact that return types will now be well defined. + +## Context + +Currently `Msg` handlers in the Cosmos SDK do have return values that are placed in the `data` field of the response. +These return values, however, are not specified anywhere except in the golang handler code. + +In early conversations [it was proposed](https://docs.google.com/document/d/1eEgYgvgZqLE45vETjhwIw4VOqK-5hwQtZtjVbiXnIGc/edit) +that `Msg` return types be captured using a protobuf extension field, ex: + +```protobuf +package cosmos.gov; + +message MsgSubmitProposal + option (cosmos_proto.msg_return) = “uint64”; + string delegator_address = 1; + string validator_address = 2; + repeated sdk.Coin amount = 3; +} +``` + +This was never adopted, however. + +Having a well-specified return value for `Msg`s would improve client UX. For instance, +in `x/gov`, `MsgSubmitProposal` returns the proposal ID as a big-endian `uint64`. +This isn’t really documented anywhere and clients would need to know the internals +of the Cosmos SDK to parse that value and return it to users. + +Also, there may be cases where we want to use these return values programatically. +For instance, https://github.com/cosmos/cosmos-sdk/issues/7093 proposes a method for +doing inter-module Ocaps using the `Msg` router. A well-defined return type would +improve the developer UX for this approach. + +In addition, handler registration of `Msg` types tends to add a bit of +boilerplate on top of keepers and is usually done through manual type switches. +This isn't necessarily bad, but it does add overhead to creating modules. + +## Decision + +We decide to use protobuf `service` definitions for defining `Msg`s as well as +the code generated by them as a replacement for `Msg` handlers. + +Below we define how this will look for the `SubmitProposal` message from `x/gov` module. +We start with a `Msg` `service` definition: + +```protobuf +package cosmos.gov; + +service Msg { + rpc SubmitProposal(MsgSubmitProposal) returns (MsgSubmitProposalResponse); +} + +// Note that for backwards compatibility this uses MsgSubmitProposal as the request +// type instead of the more canonical MsgSubmitProposalRequest +message MsgSubmitProposal { + google.protobuf.Any content = 1; + string proposer = 2; +} + +message MsgSubmitProposalResponse { + uint64 proposal_id; +} +``` + +While this is most commonly used for gRPC, overloading protobuf `service` definitions like this does not violate +the intent of the [protobuf spec](https://developers.google.com/protocol-buffers/docs/proto3#services) which says: +> If you don’t want to use gRPC, it’s also possible to use protocol buffers with your own RPC implementation. +With this approach, we would get an auto-generated `MsgServer` interface: + +In addition to clearly specifying return types, this has the benefit of generating client and server code. On the server +side, this is almost like an automatically generated keeper method and could maybe be used intead of keepers eventually +(see [\#7093](https://github.com/cosmos/cosmos-sdk/issues/7093)): + +```go +package gov + +type MsgServer interface { + SubmitProposal(context.Context, *MsgSubmitProposal) (*MsgSubmitProposalResponse, error) +} +``` + +On the client side, developers could take advantage of this by creating RPC implementations that encapsulate transaction +logic. Protobuf libraries that use asynchronous callbacks, like [protobuf.js](https://github.com/protobufjs/protobuf.js#using-services) +could use this to register callbacks for specific messages even for transactions that include multiple `Msg`s. + +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. + +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`. + +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. + +### 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. + +### 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). + +### 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. + +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. + +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. + +### Module Configuration + +In [ADR 021](./adr-021-protobuf-query-encoding.md), we introduced a method `RegisterQueryService` +to `AppModule` which allows for modules to register gRPC queriers. + +To register `Msg` services, we attempt a more extensible approach by converting `RegisterQueryService` +to a more generic `RegisterServices` method: + +```go +type AppModule interface { + RegisterServices(Configurator) + ... +} + +type Configurator interface { + QueryServer() grpc.Server + MsgServer() grpc.Server +} + +// example module: +func (am AppModule) RegisterServices(cfg Configurator) { + types.RegisterQueryServer(cfg.QueryServer(), keeper) + types.RegisterMsgServer(cfg.MsgServer(), keeper) +} +``` + +The `RegisterServices` method and the `Configurator` interface are intended to +evolve to satisfy the use cases discussed in [\#7093](https://github.com/cosmos/cosmos-sdk/issues/7093) +and [\#7122](https://github.com/cosmos/cosmos-sdk/issues/7421). + +When `Msg` services are registered, the framework _should_ verify that all `Msg` types +implement the `sdk.Msg` interface and throw an error during initialization rather +than later when transactions are processed. + +### `Msg` Service Implementation + +Just like query services, `Msg` service methods can retrieve the `sdk.Context` +from the `context.Context` parameter method using the `sdk.UnwrapSDKContext` +method: + +```go +package gov + +func (k Keeper) SubmitProposal(goCtx context.Context, params *types.MsgSubmitProposal) (*MsgSubmitProposalResponse, error) { + ctx := sdk.UnwrapSDKContext(goCtx) + ... +} +``` + +The `sdk.Context` should have an `EventManager` already attached by BaseApp's `msg_service_router`. + +Separate handler definition is no longer needed with this approach. + +## Consequences + +This design changes how a module functionality is exposed and accessed. It deprecates the existing `Handler` interface and `AppModule.Route` in favor of [Protocol Buffer Services](https://developers.google.com/protocol-buffers/docs/proto3#services) and Service Routing described above. This dramatically simplifies the code. We don't need to create handlers and keepers any more. Use of Protocol Buffer auto-generated clients clearly separates the communication interfaces between the module and a modules user. The control logic (aka handlers and keepers) is not exposed any more. A module interface can be seen as a black box accessible through a client API. It's worth to note that the client interfaces are also generated by Protocol Buffers. + +This also allows us to change how we perform functional tests. Instead of mocking AppModules and Router, we will mock a client (server will stay hidden). More specifically: we will never mock `moduleA.MsgServer` in `moduleB`, but rather `moduleA.MsgClient`. One can think about it as working with external services (eg DBs, or online servers...). We assume that the transmission between clients and servers is correctly handled by generated Protocol Buffers. + +Finally, closing a module to client API opens desirable OCAP patterns discussed in ADR-033. Since server implementation and interface is hidden, nobody can hold "keepers"/servers and will be forced to relay on the client interface, which will drive developers for correct encapsulation and software engineering patterns. + +### Pros + +* communicates return type clearly +* manual handler registration and return type marshaling is no longer needed, just implement the interface and register it +* communication interface is automatically generated, the developer can now focus only on the state transition methods - this would improve the UX of [\#7093](https://github.com/cosmos/cosmos-sdk/issues/7093) approach (1) if we chose to adopt that +* generated client code could be useful for clients and tests +* dramatically reduces and simplifies the code + +### Cons + +* using `service` definitions outside the context of gRPC could be confusing (but doesn’t violate the proto3 spec) + +## References + +* [Initial Github Issue \#7122](https://github.com/cosmos/cosmos-sdk/issues/7122) +* [proto 3 Language Guide: Defining Services](https://developers.google.com/protocol-buffers/docs/proto3#services) +* [Initial pre-`Any` `Msg` designs](https://docs.google.com/document/d/1eEgYgvgZqLE45vETjhwIw4VOqK-5hwQtZtjVbiXnIGc) +* [ADR 020](./adr-020-protobuf-transaction-encoding.md) +* [ADR 021](./adr-021-protobuf-query-encoding.md) diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-032-typed-events.md b/versioned_docs/version-0.47/integrate/architecture/adr-032-typed-events.md new file mode 100644 index 000000000..1e769f450 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-032-typed-events.md @@ -0,0 +1,319 @@ +# ADR 032: Typed Events + +## Changelog + +* 28-Sept-2020: Initial Draft + +## Authors + +* Anil Kumar (@anilcse) +* Jack Zampolin (@jackzampolin) +* Adam Bozanich (@boz) + +## Status + +Proposed + +## Abstract + +Currently in the 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. + +## 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. + +[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. + +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. + +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. + +The end of this proposal contains a detailed example of how to consume events after this refactor. + +This proposal is specifically about how to consume these events as a client of the blockchain, not for intermodule communication. + +## Decision + +**Step-1**: Implement additional functionality in the `types` package: `EmitTypedEvent` and `ParseTypedEvent` functions + +```go +// types/events.go + +// EmitTypedEvent takes typed event and emits converting it into sdk.Event +func (em *EventManager) EmitTypedEvent(event proto.Message) error { + evtType := proto.MessageName(event) + evtJSON, err := codec.ProtoMarshalJSON(event) + if err != nil { + return err + } + + var attrMap map[string]json.RawMessage + err = json.Unmarshal(evtJSON, &attrMap) + if err != nil { + return err + } + + var attrs []abci.EventAttribute + for k, v := range attrMap { + attrs = append(attrs, abci.EventAttribute{ + Key: []byte(k), + Value: v, + }) + } + + em.EmitEvent(Event{ + Type: evtType, + Attributes: attrs, + }) + + return nil +} + +// ParseTypedEvent converts abci.Event back to typed event +func ParseTypedEvent(event abci.Event) (proto.Message, error) { + concreteGoType := proto.MessageType(event.Type) + if concreteGoType == nil { + return nil, fmt.Errorf("failed to retrieve the message of type %q", event.Type) + } + + var value reflect.Value + if concreteGoType.Kind() == reflect.Ptr { + value = reflect.New(concreteGoType.Elem()) + } else { + value = reflect.Zero(concreteGoType) + } + + protoMsg, ok := value.Interface().(proto.Message) + if !ok { + return nil, fmt.Errorf("%q does not implement proto.Message", event.Type) + } + + attrMap := make(map[string]json.RawMessage) + for _, attr := range event.Attributes { + attrMap[string(attr.Key)] = attr.Value + } + + attrBytes, err := json.Marshal(attrMap) + if err != nil { + return nil, err + } + + err = jsonpb.Unmarshal(strings.NewReader(string(attrBytes)), protoMsg) + if err != nil { + return nil, err + } + + return protoMsg, nil +} +``` + +Here, the `EmitTypedEvent` is a method on `EventManager` which takes typed event as input and apply json serialization on it. Then it maps the JSON key/value pairs to `event.Attributes` and emits it in form of `sdk.Event`. `Event.Type` will be the type URL of the proto message. + +When we subscribe to emitted events on the tendermint websocket, they are emitted in the form of an `abci.Event`. `ParseTypedEvent` parses the event back to it's original proto message. + +**Step-2**: Add proto definitions for typed events for msgs in each module: + +For example, let's take `MsgSubmitProposal` of `gov` module and implement this event's type. + +```protobuf +// proto/cosmos/gov/v1beta1/gov.proto +// Add typed event definition + +package cosmos.gov.v1beta1; + +message EventSubmitProposal { + string from_address = 1; + uint64 proposal_id = 2; + TextProposal proposal = 3; +} +``` + +**Step-3**: Refactor event emission to use the typed event created and emit using `sdk.EmitTypedEvent`: + +```go +// x/gov/handler.go +func handleMsgSubmitProposal(ctx sdk.Context, keeper keeper.Keeper, msg types.MsgSubmitProposalI) (*sdk.Result, error) { + ... + types.Context.EventManager().EmitTypedEvent( + &EventSubmitProposal{ + FromAddress: fromAddress, + ProposalId: id, + Proposal: proposal, + }, + ) + ... +} +``` + +### How to subscribe to these typed events in `Client` + +> NOTE: Full code example below + +Users will be able to subscribe using `client.Context.Client.Subscribe` and consume events which are emitted using `EventHandler`s. + +Akash Network has built a simple [`pubsub`](https://github.com/ovrclk/akash/blob/90d258caeb933b611d575355b8df281208a214f8/pubsub/bus.go#L20). This can be used to subscribe to `abci.Events` and [publish](https://github.com/ovrclk/akash/blob/90d258caeb933b611d575355b8df281208a214f8/events/publish.go#L21) them as typed events. + +Please see the below code sample for more detail on this flow looks for clients. + +## Consequences + +### Positive + +* Improves consistency of implementation for the events currently in the 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 + +### Negative + +## Detailed code example of publishing events + +This ADR also proposes adding affordances to emit and consume these events. This way developers will only need to write +`EventHandler`s which define the actions they desire to take. + +```go +// EventEmitter is a type that describes event emitter functions +// This should be defined in `types/events.go` +type EventEmitter func(context.Context, client.Context, ...EventHandler) error + +// EventHandler is a type of function that handles events coming out of the event bus +// This should be defined in `types/events.go` +type EventHandler func(proto.Message) error + +// Sample use of the functions below +func main() { + ctx, cancel := context.WithCancel(context.Background()) + + if err := TxEmitter(ctx, client.Context{}.WithNodeURI("tcp://localhost:26657"), SubmitProposalEventHandler); err != nil { + cancel() + panic(err) + } + + return +} + +// SubmitProposalEventHandler is an example of an event handler that prints proposal details +// when any EventSubmitProposal is emitted. +func SubmitProposalEventHandler(ev proto.Message) (err error) { + switch event := ev.(type) { + // Handle governance proposal events creation events + case govtypes.EventSubmitProposal: + // Users define business logic here e.g. + fmt.Println(ev.FromAddress, ev.ProposalId, ev.Proposal) + return nil + default: + return nil + } +} + +// TxEmitter is an example of an event emitter that emits just transaction events. This can and +// should be implemented somewhere in the 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 + client, err := cliCtx.GetNode() + if err != nil { + return err + } + + if err = client.Start(); err != nil { + return err + } + + // Start the pubsub bus + bus := pubsub.NewBus() + defer bus.Close() + + // Initialize a new error group + eg, ctx := errgroup.WithContext(ctx) + + // Publish chain events to the pubsub bus + eg.Go(func() error { + return PublishChainTxEvents(ctx, client, bus, simapp.ModuleBasics) + }) + + // Subscribe to the bus events + subscriber, err := bus.Subscribe() + if err != nil { + return err + } + + // Handle all the events coming out of the bus + eg.Go(func() error { + var err error + for { + select { + case <-ctx.Done(): + return nil + case <-subscriber.Done(): + return nil + case ev := <-subscriber.Events(): + for _, eh := range ehs { + if err = eh(ev); err != nil { + break + } + } + } + } + return nil + }) + + return group.Wait() +} + +// PublishChainTxEvents events using 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 + txch, err := client.Subscribe(ctx, "txevents", "tm.event='Tx'", 100) + if err != nil { + return err + } + + // Unsubscribe from transaction events on function exit + defer func() { + err = client.UnsubscribeAll(ctx, "txevents") + }() + + // Use errgroup to manage concurrency + g, ctx := errgroup.WithContext(ctx) + + // Publish transaction events in a goroutine + g.Go(func() error { + var err error + for { + select { + case <-ctx.Done(): + break + case ed := <-ch: + switch evt := ed.Data.(type) { + case tmtypes.EventDataTx: + if !evt.Result.IsOK() { + continue + } + // range over events, parse them using the basic manager and + // send them to the pubsub bus + for _, abciEv := range events { + typedEvent, err := sdk.ParseTypedEvent(abciEv) + if err != nil { + return er + } + if err := bus.Publish(typedEvent); err != nil { + bus.Close() + return + } + continue + } + } + } + } + return err + }) + + // Exit on error or context cancelation + return g.Wait() +} +``` + +## References + +* [Publish Custom Events via a bus](https://github.com/ovrclk/akash/blob/90d258caeb933b611d575355b8df281208a214f8/events/publish.go#L19-L58) +* [Consuming the events in `Client`](https://github.com/ovrclk/deploy/blob/bf6c633ab6c68f3026df59efd9982d6ca1bf0561/cmd/event-handlers.go#L57) diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-033-protobuf-inter-module-comm.md b/versioned_docs/version-0.47/integrate/architecture/adr-033-protobuf-inter-module-comm.md new file mode 100644 index 000000000..ea634dac9 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-033-protobuf-inter-module-comm.md @@ -0,0 +1,400 @@ +# ADR 033: Protobuf-based Inter-Module Communication + +## Changelog + +* 2020-10-05: Initial Draft + +## 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: + +* 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 + +## Context + +In the current Cosmos SDK documentation on the [Object-Capability Model](../core/10-ocap.md), it is stated that: + +> 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. + +There is currently not a thriving ecosystem of Cosmos SDK modules. We hypothesize that this is in part due to: + +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. + +### `x/bank` Case Study + +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. + +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. + +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. + +## 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. + +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. + +### 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: + +```go +package bank + +type MsgClient interface { + Send(context.Context, *MsgSend, opts ...grpc.CallOption) (*MsgSendResponse, error) +} + +type MsgServer interface { + Send(context.Context, *MsgSend) (*MsgSendResponse, error) +} +``` + +[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. + +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. + +Using this `QueryClient`/`MsgClient` approach has the following key benefits over exposing keepers to external modules: + +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 + +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 + +### Inter-module Communication + +To use the `Client` generated by the protobuf compiler we need a `grpc.ClientConn` [interface](https://github.com/grpc/grpc-go/blob/v1.49.x/clientconn.go#L441-L450) +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. + +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`. + +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. + +Here's an example of a hypothetical module `foo` interacting with `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), + } +} + +func (foo *FooMsgServer) Bar(ctx context.Context, req *MsgBarRequest) (*MsgBarResponse, error) { + balance, err := foo.bankQuery.Balance(&bank.QueryBalanceRequest{Address: fooMsgServer.moduleKey.Address(), Denom: "foo"}) + + ... + + res, err := foo.bankMsg.Send(ctx, &bank.MsgSendRequest{FromAddress: fooMsgServer.moduleKey.Address(), ...}) + + ... +} +``` + +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)). + +### `ModuleKey`s and `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/main/docs/architecture/adr-028-public-key-addresses.md): + +```go +type ModuleID struct { + ModuleName string + Path []byte +} + +func (key ModuleID) Address() []byte { + return AddressHash(key.ModuleName, key.Path) +} +``` + +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. + +The two `ModuleKey` types are `RootModuleKey` and `DerivedModuleKey`: + +```go +type Invoker func(callInfo CallInfo) func(ctx context.Context, request, response interface{}, opts ...interface{}) error + +type CallInfo { + Method string + Caller ModuleID +} + +type RootModuleKey struct { + moduleName string + invoker Invoker +} + +func (rm RootModuleKey) Derive(path []byte) DerivedModuleKey { /* ... */} + +type DerivedModuleKey struct { + moduleName string + path []byte + invoker Invoker +} +``` + +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: + +```go +package foo + +func (fooMsgServer *MsgServer) Bar(ctx context.Context, req *MsgBar) (*MsgBarResponse, error) { + derivedKey := fooMsgServer.moduleKey.Derive(req.SomePath) + bankMsgClient := bank.NewMsgClient(derivedKey) + res, err := bankMsgClient.Balance(ctx, &bank.MsgSend{FromAddress: derivedKey.Address(), ...}) + ... +} +``` + +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. + +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. + +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`: + +```go +func (key RootModuleKey) Invoke(ctx context.Context, method string, args, reply interface{}, opts ...grpc.CallOption) error { + f := key.invoker(CallInfo {Method: method, Caller: ModuleID {ModuleName: key.moduleName}}) + return f(ctx, args, reply) +} +``` + +### `AppModule` Wiring and Requirements + +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()`: + +```go +type Configurator interface { + MsgServer() grpc.Server + QueryServer() grpc.Server + + ModuleKey() ModuleKey + RequireServer(msgServer 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. + +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: + +```go +package foo + +func (am AppModule) RegisterServices(cfg Configurator) { + cfg.RequireServer((*bank.QueryServer)(nil)) + cfg.RequireServer((*bank.MsgServer)(nil)) +} +``` + +### Security Considerations + +In addition to checking for `ModuleKey` permissions, a few additional security precautions will need to be taken by +the underlying router infrastructure. + +#### 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. + +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. + +#### 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. + +### 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`: + +```go +type Configurator interface { + MsgServer() grpc.Server + QueryServer() grpc.Server + InternalServer() grpc.Server +} +``` + +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. + +Services registered against `InternalServer` will be callable from other modules but not by external clients. + +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. + +### Authorization + +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/main/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 + +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 + +### 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). + +The advantages of the approach described in this ADR are mostly around how it integrates with other parts of the Cosmos SDK, +specifically: + +* 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` + +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. + +## Consequences + +### 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 + +* 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 + +### 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](https://docs.network.com/main/core/ocap) diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-034-account-rekeying.md b/versioned_docs/version-0.47/integrate/architecture/adr-034-account-rekeying.md new file mode 100644 index 000000000..cd9b91469 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-034-account-rekeying.md @@ -0,0 +1,76 @@ +# ADR 034: Account Rekeying + +## Changelog + +* 30-09-2020: Initial Draft + +## Status + +PROPOSED + +## Abstract + +Account rekeying is a process hat allows an account to replace its authentication pubkey with a new one. + +## Context + +Currently, in the Cosmos SDK, the address of an auth `BaseAccount` is based on the hash of the public key. Once an account is created, the public key for the account is set in stone, and cannot be changed. This can be a problem for users, as key rotation is a useful security practice, but is not possible currently. Furthermore, as multisigs are a type of pubkey, once a multisig for an account is set, it can not be updated. This is problematic, as multisigs are often used by organizations or companies, who may need to change their set of multisig signers for internal reasons. + +Transferring all the assets of an account to a new account with the updated pubkey is not sufficient, because some "engagements" of an account are not easily transferable. For example, in staking, to transfer bonded Atoms, an account would have to unbond all delegations and wait the three week unbonding period. Even more significantly, for validator operators, ownership over a validator is not transferrable at all, meaning that the operator key for a validator can never be updated, leading to poor operational security for validators. + +## Decision + +We propose the addition of a new feature to `x/auth` that allows accounts to update the public key associated with their account, while keeping the address the same. + +This is possible because the Cosmos SDK `BaseAccount` stores the public key for an account in state, instead of making the assumption that the public key is included in the transaction (whether explicitly or implicitly through the signature) as in other blockchains such as Bitcoin and Ethereum. Because the public key is stored on chain, it is okay for the public key to not hash to the address of an account, as the address is not pertinent to the signature checking process. + +To build this system, we design a new Msg type as follows: + +```protobuf +service Msg { + rpc ChangePubKey(MsgChangePubKey) returns (MsgChangePubKeyResponse); +} + +message MsgChangePubKey { + string address = 1; + google.protobuf.Any pub_key = 2; +} + +message MsgChangePubKeyResponse {} +``` + +The MsgChangePubKey transaction needs to be signed by the existing pubkey in state. + +Once, approved, the handler for this message type, which takes in the AccountKeeper, will update the in-state pubkey for the account and replace it with the pubkey from the Msg. + +An account that has had its pubkey changed cannot be automatically pruned from state. This is because if pruned, the original pubkey of the account would be needed to recreate the same address, but the owner of the address may not have the original pubkey anymore. Currently, we do not automatically prune any accounts anyways, but we would like to keep this option open the road (this is the purpose of account numbers). To resolve this, we charge an additional gas fee for this operation to compensate for this this externality (this bound gas amount is configured as parameter `PubKeyChangeCost`). The bonus gas is charged inside the handler, using the `ConsumeGas` function. Furthermore, in the future, we can allow accounts that have rekeyed manually prune themselves using a new Msg type such as `MsgDeleteAccount`. Manually pruning accounts can give a gas refund as an incentive for performing the action. + +```go + amount := ak.GetParams(ctx).PubKeyChangeCost + ctx.GasMeter().ConsumeGas(amount, "pubkey change fee") +``` + +Everytime a key for an address is changed, we will store a log of this change in the state of the chain, thus creating a stack of all previous keys for an address and the time intervals for which they were active. This allows dapps and clients to easily query past keys for an account which may be useful for features such as verifying timestamped off-chain signed messages. + +## Consequences + +### Positive + +* Will allow users and validator operators to employ better operational security practices with key rotation. +* Will allow organizations or groups to easily change and add/remove multisig signers. + +### Negative + +Breaks the current assumed relationship between address and pubkeys as H(pubkey) = address. This has a couple of consequences. + +* This makes wallets that support this feature more complicated. For example, if an address on chain was updated, the corresponding key in the CLI wallet also needs to be updated. +* Cannot automatically prune accounts with 0 balance that have had their pubkey changed. + +### Neutral + +* While the purpose of this is intended to allow the owner of an account to update to a new pubkey they own, this could technically also be used to transfer ownership of an account to a new owner. For example, this could be use used to sell a staked position without unbonding or an account that has vesting tokens. However, the friction of this is very high as this would essentially have to be done as a very specific OTC trade. Furthermore, additional constraints could be added to prevent accouns with Vesting tokens to use this feature. +* Will require that PubKeys for an account are included in the genesis exports. + +## References + +* https://www.algorand.com/resources/blog/announcing-rekeying diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-035-rosetta-api-support.md b/versioned_docs/version-0.47/integrate/architecture/adr-035-rosetta-api-support.md new file mode 100644 index 000000000..01a81048b --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-035-rosetta-api-support.md @@ -0,0 +1,211 @@ +# ADR 035: Rosetta API Support + +## Authors + +* Jonathan Gimeno (@jgimeno) +* David Grierson (@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. + +## Context + +[Rosetta API](https://www.rosetta-api.org/) is an open-source specification and set of tools developed by Coinbase to +standardise blockchain interactions. + +Through the use of a standard API for integrating blockchain applications it will + +* Be easier for a user to interact with a given blockchain +* Allow exchanges to integrate new blockchains quickly and easily +* Enable application developers to build cross-blockchain applications such as block explorers, wallets and dApps at + considerably lower cost and effort. + +## Decision + +It is clear that adding Rosetta API support to the Cosmos SDK will bring value to all the developers and +Cosmos SDK based chains in the ecosystem. How it is implemented is key. + +The driving principles of the proposed design are: + +1. **Extensibility:** it must be as riskless and painless as possible for application developers to set-up network + configurations to expose Rosetta API-compliant services. +2. **Long term support:** This proposal aims to provide support for all the supported Cosmos SDK release series. +3. **Cost-efficiency:** Backporting changes to Rosetta API specifications from `master` to the various stable + branches of Cosmos SDK is a cost that needs to be reduced. + +We will achieve these delivering on these principles by the following: + +1. There will be 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. + +## 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. + +The constructor follows: + +`func NewServer(settings Settings) (Server, error)` + +`Settings`, which are used to construct a new server, are the following: + +```go +// Settings define the rosetta server settings +type Settings struct { + // Network contains the information regarding the network + Network *types.NetworkIdentifier + // Client is the online API handler + Client crgtypes.Client + // Listen is the address the handler will listen at + Listen string + // 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 int + // 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. + +Each Cosmos SDK release series will have their own `Client` implementations. +Developers can implement their own custom `Client`s as required. + +```go +// Client defines the API the client implementation should provide. +type Client interface { + // 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() error + + // 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(ctx context.Context, addr string, height *int64) ([]*types.Amount, error) + // 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 + BlockByHeight(ctx context.Context, height *int64) (BlockResponse, error) + // 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. + BlockTransactionsByHeight(ctx context.Context, height *int64) (BlockTransactionsResponse, error) + // 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(ctx context.Context, hash string) (*types.Transaction, error) + // 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(ctx context.Context) ([]*types.Peer, error) + // Status returns the node status, such as sync data, version etc + Status(ctx context.Context) (*types.SyncStatus, error) + + // Construction API + + // 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(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 +type OfflineClient interface { + NetworkInformationProvider + // 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(signed bool, hexBytes []byte) (ops []*types.Operation, signers []*types.AccountIdentifier, err error) + // 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(ctx context.Context, req *types.ConstructionPreprocessRequest) (options map[string]interface{}, err error) + // AccountIdentifierFromPublicKey returns the account identifier given the public key + AccountIdentifierFromPublicKey(pubKey *types.PublicKey) (*types.AccountIdentifier, error) +} +``` + +### 2. Cosmos SDK Implementation + +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. + +The rosetta.Msg interface follows: + +```go +// 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 + FromOperations(ops []*types.Operation) (sdk.Msg, error) +} +``` + +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. + +### 3. API service invocation + +As stated at the start, application developers will have two methods for invocation of the Rosetta API service: + +1. Shared process for both application and API +2. Standalone API service + +#### Shared Process (Only Stargate) + +Rosetta API service could run within the same execution process as the application. 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). + +#### Separate API service + +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. + +## Status + +Proposed + +## Consequences + +### Positive + +* Out-of-the-box Rosetta API support within Cosmos SDK. +* Blockchain interface standardisation + +## References + +* https://www.rosetta-api.org/ diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-036-arbitrary-signature.md b/versioned_docs/version-0.47/integrate/architecture/adr-036-arbitrary-signature.md new file mode 100644 index 000000000..fe9dada54 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-036-arbitrary-signature.md @@ -0,0 +1,132 @@ +# ADR 036: Arbitrary Message Signature Specification + +## Changelog + +* 28/10/2020 - Initial draft + +## Authors + +* Antoine Herzog (@antoineherzog) +* Zaki Manian (@zmanian) +* Aleksandr 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. + +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. + +## 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. + +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. + +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 0.40 also introduces a concept of “auth_info” this can specify SIGN_MODES. + +A spec should include an `auth_info` that supports SIGN_MODE_DIRECT and SIGN_MODE_LEGACY_AMINO. + +Create the `offchain` proto definitions, we extend the auth module with `offchain` package to offer functionalities to verify and sign offline messages. + +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 + +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`. + +`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. + +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: + +```protobuf +// MsgSignData defines an arbitrary, general-purpose, off-chain message +message MsgSignData { + // 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) + bytes Data = 2 [(gogoproto.jsontag) = "data"]; +} +``` + +Signed MsgSignData json example: + +```json +{ + "type": "cosmos-sdk/StdTx", + "value": { + "msg": [ + { + "type": "sign/MsgSignData", + "value": { + "signer": "cosmos1hftz5ugqmpg9243xeegsqqav62f8hnywsjr4xr", + "data": "cmFuZG9t" + } + } + ], + "fee": { + "amount": [], + "gas": "0" + }, + "signatures": [ + { + "pub_key": { + "type": "tendermint/PubKeySecp256k1", + "value": "AqnDSiRoFmTPfq97xxEb2VkQ/Hm28cPsqsZm9jEVsYK9" + }, + "signature": "8y8i34qJakkjse9pOD2De+dnlc4KvFgh0wQpes4eydN66D9kv7cmCEouRrkka9tlW9cAkIL52ErB+6ye7X5aEg==" + } + ], + "memo": "" + } +} +``` + +## 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]. + +### Negative + +* Current proposal requires a fixed relationship between an account address and a public key. +* Doesn't work with multisig accounts. + +## Further discussion + +* 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 diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-037-gov-split-vote.md b/versioned_docs/version-0.47/integrate/architecture/adr-037-gov-split-vote.md new file mode 100644 index 000000000..0a3b9bc43 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-037-gov-split-vote.md @@ -0,0 +1,111 @@ +# ADR 037: Governance split votes + +## Changelog + +* 2020/10/28: Intial draft + +## Status + +Accepted + +## Abstract + +This ADR defines a modification to the governance module that would allow a staker to split their votes into several voting options. For example, it could use 70% of its voting power to vote Yes and 30% of its voting power to vote No. + +## Context + +Currently, an address can cast a vote with only one options (Yes/No/Abstain/NoWithVeto) and use their full voting power behind that choice. + +However, often times the entity owning that address might not be a single individual. For example, a company might have different stakeholders who want to vote differently, and so it makes sense to allow them to split their voting power. Another example use case is exchanges. Many centralized exchanges often stake a portion of their users' tokens in their custody. Currently, it is not possible for them to do "passthrough voting" and giving their users voting rights over their tokens. However, with this system, exchanges can poll their users for voting preferences, and then vote on-chain proportionally to the results of the poll. + +## Decision + +We modify the vote structs to be + +```go +type WeightedVoteOption struct { + Option string + Weight sdk.Dec +} + +type Vote struct { + ProposalID int64 + Voter sdk.Address + Options []WeightedVoteOption +} +``` + +And for backwards compatibility, we introduce `MsgVoteWeighted` while keeping `MsgVote`. + +```go +type MsgVote struct { + ProposalID int64 + Voter sdk.Address + Option Option +} + +type MsgVoteWeighted struct { + ProposalID int64 + Voter sdk.Address + Options []WeightedVoteOption +} +``` + +The `ValidateBasic` of a `MsgVoteWeighted` struct would require that + +1. The sum of all the Rates is equal to 1.0 +2. No Option is repeated + +The governance tally function will iterate over all the options in a vote and add to the tally the result of the voter's voting power * the rate for that option. + +```go +tally() { + results := map[types.VoteOption]sdk.Dec + + for _, vote := range votes { + for i, weightedOption := range vote.Options { + results[weightedOption.Option] += getVotingPower(vote.voter) * weightedOption.Weight + } + } +} +``` + +The CLI command for creating a multi-option vote would be as such: + +```shell +simd tx gov vote 1 "yes=0.6,no=0.3,abstain=0.05,no_with_veto=0.05" --from mykey +``` + +To create a single-option vote a user can do either + +```shell +simd tx gov vote 1 "yes=1" --from mykey +``` + +or + +```shell +simd tx gov vote 1 yes --from mykey +``` + +to maintain backwards compatibility. + +## Consequences + +### Backwards Compatibility + +* Previous VoteMsg types will remain the same and so clients will not have to update their procedure unless they want to support the WeightedVoteMsg feature. +* When querying a Vote struct from state, its structure will be different, and so clients wanting to display all voters and their respective votes will have to handle the new format and the fact that a single voter can have split votes. +* The result of querying the tally function should have the same API for clients. + +### Positive + +* Can make the voting process more accurate for addresses representing multiple stakeholders, often some of the largest addresses. + +### Negative + +* Is more complex than simple voting, and so may be harder to explain to users. However, this is mostly mitigated because the feature is opt-in. + +### Neutral + +* Relatively minor change to governance tally function. diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-038-state-listening.md b/versioned_docs/version-0.47/integrate/architecture/adr-038-state-listening.md new file mode 100644 index 000000000..74f92d2f6 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-038-state-listening.md @@ -0,0 +1,569 @@ +# ADR 038: KVStore state listening + +## Changelog + +* 11/23/2020: Initial draft +* 10/14/2022: + * Add `ListenCommit`, flatten the state writes in a block to a single batch. + * Remove listeners from cache stores, should only listen to `rootmulti.Store`. + * Remove `HaltAppOnDeliveryError()`, the errors are propogated by default, the implementations should return nil if don't want to propogate errors. + + +## 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. + +## 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. + +## Decision + +We will modify the `CommitMultiStore` interface and its concrete (`rootmulti`) implementations and introduce a new `listenkv.Store` to allow listening to state changes in underlying KVStores. We don't need to listen to cache stores, because we can't be sure that the writes will be committed eventually, and the writes are duplicated in `rootmulti.Store` eventually, so we should only listen to `rootmulti.Store`. +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. + +### Listening interface + +In a new file, `store/types/listening.go`, we will create a `WriteListener` interface for streaming out state changes from a KVStore. + +```go +// 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 + OnWrite(storeKey StoreKey, key []byte, value []byte, delete bool) error +} +``` + +### Listener type + +We will create two concrete implementations of the `WriteListener` interface in `store/types/listening.go`, that writes out protobuf +encoded KV pairs to an underlying `io.Writer`, and simply accumulate them in memory. + +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. + +```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 + 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 +type StoreKVPairWriteListener struct { + writer io.Writer + marshaller 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, + marshaller: m, + } +} + +// 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() + kvPair.Delete = Delete + kvPair.Key = key + kvPair.Value = value + by, err := wl.marshaller.MarshalBinaryLengthPrefixed(kvPair) + if err != nil { + return err + } + if _, err := wl.writer.Write(by); err != nil { + return err + } + return nil +} +``` + +```golang +// MemoryListener listens to the state writes and accumulate the records in memory. +type MemoryListener struct { + key StoreKey + stateCache []StoreKVPair +} + +// NewMemoryListener creates a listener that accumulate the state writes in memory. +func NewMemoryListener(key StoreKey) *MemoryListener { + return &MemoryListener{key: key} +} + +// OnWrite implements WriteListener interface +func (fl *MemoryListener) OnWrite(storeKey StoreKey, key []byte, value []byte, delete bool) error { + fl.stateCache = append(fl.stateCache, StoreKVPair{ + StoreKey: storeKey.Name(), + Delete: delete, + Key: key, + Value: value, + }) + return nil +} + +// PopStateCache returns the current state caches and set to nil +func (fl *MemoryListener) PopStateCache() []StoreKVPair { + res := fl.stateCache + fl.stateCache = nil + return res +} + +// StoreKey returns the storeKey it listens to +func (fl *MemoryListener) StoreKey() StoreKey { + return fl.key +} +``` + +### 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. + +```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 +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. +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. +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. +func (s *Store) Delete(key []byte) { + s.parent.Delete(key) + s.onWrite(true, key, nil) +} + +// 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 + } + } +} +``` + +### MultiStore interface updates + +We will update the `CommitMultiStore` interface to allow us to wrap a set of listeners around a specific `KVStore`. + +```go +type CommitMultiStore interface { + ... + + // 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(key StoreKey, listeners []WriteListener) +} +``` + +### MultiStore implementation updates + +We will modify all of the `CommitMultiStore` 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`. + +```go +func (rs *Store) GetKVStore(key types.StoreKey) types.KVStore { + store := rs.stores[key].(types.KVStore) + + if rs.TracingEnabled() { + store = tracekv.NewStore(store, rs.traceWriter, rs.traceContext) + } + if rs.ListeningEnabled(key) { + store = listenkv.NewStore(key, store, rs.listeners[key]) + } + + return store +} +``` + +We will also adjust the `rootmulti` `CacheMultiStore` method to wrap the stores with `listenkv.Store` to enable listening when the cache layer writes. + +```go +func (rs *Store) CacheMultiStore() types.CacheMultiStore { + stores := make(map[types.StoreKey]types.CacheWrapper) + for k, v := range rs.stores { + store := v.(types.KVStore) + // Wire the listenkv.Store to allow listeners to observe the writes from the cache store, + // set same listeners on cache store will observe duplicated writes. + if rs.ListeningEnabled(k) { + store = listenkv.NewStore(store, k, rs.listeners[k]) + } + stores[k] = store + } + return cachemulti.NewStore(rs.db, stores, rs.keysByName, rs.traceWriter, rs.getTracingContext()) +} +``` + +### Exposing the data + +#### 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 observe those block metadatas as well. + +The `WriteListener`s of `StreamingService` listens to the `rootmulti.Store`, which is only written into at commit event by the cache store of `deliverState`. + +```go +// 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(ctx types.Context, req abci.RequestBeginBlock, res abci.ResponseBeginBlock) error + // 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(ctx types.Context, req abci.RequestDeliverTx, res abci.ResponseDeliverTx) error + // ListenCommit updates the steaming service with the latest Commit message, + // All the state writes of current block should have notified before this message. + ListenCommit(ctx types.Context, res abci.ResponseCommit) error +} + +// 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(wg *sync.WaitGroup) error + // 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 + // Closer interface + io.Closer +} +``` + +#### BaseApp registration + +We will add a new method to the `BaseApp` to enable the registration of `StreamingService`s: + +```go +// 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 + 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 + app.abciListeners = append(app.abciListeners, s) +} +``` + +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`. + +```go +func (app *BaseApp) BeginBlock(req abci.RequestBeginBlock) (res abci.ResponseBeginBlock) { + + ... + + defer func() { + // call the hooks with the BeginBlock messages + for _, streamingListener := range app.abciListeners { + if err := streamingListener.ListenBeginBlock(app.deliverState.ctx, req, res); err != nil { + panic(sdkerrors.Wrapf(err, "BeginBlock listening hook failed, height: %d", req.Header.Height)) + } + } + }() + + return res +} +``` + +```go +func (app *BaseApp) EndBlock(req abci.RequestEndBlock) (res abci.ResponseEndBlock) { + + ... + + defer func() { + // Call the streaming service hooks with the EndBlock messages + for _, streamingListener := range app.abciListeners { + if err := streamingListener.ListenEndBlock(app.deliverState.ctx, req, res); err != nil { + panic(sdkerrors.Wrapf(err, "EndBlock listening hook failed, height: %d", req.Height)) + } + } + }() + + return res +} +``` + +```go +func (app *BaseApp) DeliverTx(req abci.RequestDeliverTx) (res abci.ResponseDeliverTx) { + + defer func() { + // call the hooks with the DeliverTx messages + for _, streamingListener := range app.abciListeners { + if err := streamingListener.ListenDeliverTx(app.deliverState.ctx, req, res); err != nil { + panic(sdkerrors.Wrap(err, "DeliverTx listening hook failed")) + } + } + }() + + ... + + return res +} +``` + +```golang +func (app *BaseApp) Commit() abci.ResponseCommit { + header := app.deliverState.ctx.BlockHeader() + retainHeight := app.GetBlockRetentionHeight(header.Height) + + // Write the DeliverTx state into branched storage and commit the MultiStore. + // The write to the DeliverTx state writes all state transitions to the root + // MultiStore (app.cms) so when Commit() is called is persists those values. + app.deliverState.ms.Write() + commitID := app.cms.Commit() + + res := abci.ResponseCommit{ + Data: commitID.Hash, + RetainHeight: retainHeight, + } + + // call the hooks with the Commit message + for _, streamingListener := range app.abciListeners { + if err := streamingListener.ListenCommit(app.deliverState.ctx, res); err != nil { + panic(sdkerrors.Wrapf(err, "Commit listening hook failed, height: %d", header.Height)) + } + } + + app.logger.Info("commit synced", "commit", fmt.Sprintf("%X", commitID)) + ... +} +``` + +#### Error Handling And Async Consumers + +`ABCIListener`s are called synchronously inside the consensus state machine, the returned error causes panic which in turn halt the consensus state machine. The implementer should be careful not to break consensus unexpectedly or slow down it too much. + +For some async use cases, one can spawn a go-routine internanlly to avoid slow down consensus state machine, and handle the errors internally and always returns `nil` to avoid halting consensus state machine on error. + +Furthermore, for most of the cases, we only need to use the builtin file streamer to listen to state changes directly inside cosmos-sdk, the other consumers should subscribe to the file streamer output externally. + +#### File Streamer + +We provide a minimal filesystem based implementation inside cosmos-sdk, and provides options to write output files reliably, the output files can be further consumed by external consumers, so most of the state listeners actually don't need to live inside the sdk and node, which improves the node robustness and simplify sdk internals. + +The file streamer can be wired in app like this: +```golang +exposeStoreKeys := ... // decide the key list to listen +service, err := file.NewStreamingService(streamingDir, "", exposeStoreKeys, appCodec, logger) +bApp.SetStreamingService(service) +``` + +#### 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: + +```go +// 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() string + + // 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(env serverTypes.AppOptions) error + + // 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. + +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. + +```go +// 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(bApp *baseapp.BaseApp, marshaller codec.BinaryCodec, keys map[string]*types.KVStoreKey) error + + // Start starts the background streaming process of the plugin streaming service + Start(wg *sync.WaitGroup) error + + // 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. + +e.g. in `NewSimApp`: + +```go +func NewSimApp( + logger log.Logger, + db dbm.DB, + traceStore io.Writer, + loadLatest bool, + appOpts servertypes.AppOptions, + baseAppOptions ...func(*baseapp.BaseApp), +) *SimApp { + + ... + + keys := sdk.NewKVStoreKeys( + authtypes.StoreKey, banktypes.StoreKey, stakingtypes.StoreKey, + minttypes.StoreKey, distrtypes.StoreKey, slashingtypes.StoreKey, + govtypes.StoreKey, paramstypes.StoreKey, ibchost.StoreKey, upgradetypes.StoreKey, + evidencetypes.StoreKey, ibctransfertypes.StoreKey, capabilitytypes.StoreKey, + ) + + pluginsOnKey := fmt.Sprintf("%s.%s", plugin.PLUGINS_TOML_KEY, plugin.PLUGINS_ON_TOML_KEY) + if cast.ToBool(appOpts.Get(pluginsOnKey)) { + // this loads the preloaded and any plugins found in `plugins.dir` + pluginLoader, err := loader.NewPluginLoader(appOpts, logger) + if err != nil { + // handle error + } + + // initialize the loaded plugins + if err := pluginLoader.Initialize(); err != nil { + // handle error + } + + // register the plugin(s) with the BaseApp + if err := pluginLoader.Inject(bApp, appCodec, keys); err != nil { + // handle error + } + + // 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 + } + } + + ... + + return app +} +``` + + +#### Configuration + +The plugin system will be configured within an app's app.toml file. + +```toml +[plugins] + on = false # turn the plugin system, as a whole, on or off + enabled = ["list", "of", "plugin", "names", "to", "enable"] + 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.enabled` 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.enabled` provides `opt-in` semantics to plugin names to enable (including preloaded plugins). + +Configuration of a given plugin is ultimately specific to the plugin, but we will introduce some standards here: + +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 flag (e.g. `plugins.streaming.file.halt_app_on_delivery_error`) +that signifies whether the service operates in a fire-and-forget capacity, or stop the BaseApp when an error occurs in +any of `ListenBeginBlock`, `ListenEndBlock` and `ListenDeliverTx`. + +e.g. + +```toml +[plugins] + on = false # turn the plugin system, as a whole, on or off + enabled = ["list", "of", "plugin", "names", "to", "enable"] + dir = "the directory to load non-preloaded plugins from; defaults to " + [plugins.streaming] # a mapping of plugin-specific streaming service parameters, mapped to their plugin name + [plugins.streaming.file] # the specific parameters for the file streaming service plugin + keys = ["list", "of", "store", "keys", "we", "want", "to", "expose", "for", "this", "streaming", "service"] + write_dir = "path to the write directory" + prefix = "optional prefix to prepend to the generated file names" + halt_app_on_delivery_error = "false" # false == fire-and-forget; true == stop the application + [plugins.streaming.kafka] + keys = [] + topic_prefix = "block" # Optional prefix for topic names where data will be stored. + flush_timeout_ms = 5000 # Flush and wait for outstanding messages and requests to complete delivery when calling `StreamingService.Close(). (milliseconds) + halt_app_on_delivery_error = true # Whether or not to halt the application when plugin fails to deliver message(s). + ... +``` + +#### 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 + +These changes will provide a means of subscribing to KVStore state changes in real time. + +### Backwards Compatibility + +* This ADR changes the `CommitMultiStore` interface, implementations supporting the previous version of these interfaces will not support the new ones + +### Positive + +* Ability to listen to KVStore state changes in real time and expose these events to external consumers + +### Negative + +* Changes `CommitMultiStore`interface + +### 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 diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-039-epoched-staking.md b/versioned_docs/version-0.47/integrate/architecture/adr-039-epoched-staking.md new file mode 100644 index 000000000..29418fc89 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-039-epoched-staking.md @@ -0,0 +1,122 @@ +# ADR 039: Epoched Staking + +## Changelog + +* 10-Feb-2021: Initial Draft + +## Authors + +* Dev Ojha (@valardragon) +* Sunny Aggarwal (@sunnya97) + +## 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. + +## 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. + +* 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. + +* 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) + +* 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. + +## 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. + +### 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 + +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. + +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. + +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**: Implement buffering of all staking and slashing messages. + +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**: 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**: 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**: 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**: 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) + +**Step-3**: Adjust gas + +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. diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-040-storage-and-smt-state-commitments.md b/versioned_docs/version-0.47/integrate/architecture/adr-040-storage-and-smt-state-commitments.md new file mode 100644 index 000000000..f60e3adcf --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-040-storage-and-smt-state-commitments.md @@ -0,0 +1,289 @@ +# ADR 040: Storage and SMT State Commitments + +## Changelog + +* 2020-01-15: Draft + +## 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. + +## Context + +Currently, Cosmos SDK uses IAVL for both state [commitments](https://cryptography.fandom.com/wiki/Commitment_scheme) and data storage. + +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: + +* 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 +). + +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. + +## 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. + +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. + +`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`). + +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). + +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)): + +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. + +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. + +### 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) + +### SMT for State Commitment + +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: + +* 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. + +### 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). + +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. + +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. + +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). + +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. + +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. + +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. + +#### 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. + +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. + +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. + +### 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)`. + +### 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. + +### 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. + +### 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)). + +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. + +```go +// 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. +type CommitRootStore interface { + BasicRootStore + Committer + Snapshotter + + GetVersion(uint64) (BasicRootStore, error) + SetInitialVersion(uint64) error + + ... // Trace and Listen methods +} + +// Replaces CacheMultiStore for branched state. +type CacheRootStore interface { + BasicRootStore + Write() + + ... // Trace and Listen methods +} + +// Example of constructor parameters for the concrete type. +type RootStoreConfig struct { + Upgrades *StoreUpgrades + InitialVersion uint64 + + ReservePrefix(StoreKey, StoreType) +} +``` + + + + +In contrast to `MultiStore`, `RootStore` doesn't allow to dynamically mount sub-stores or provide an arbitrary backing DB for individual sub-stores. + +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. + +#### 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`. + +The new `RootStore` and supporting types can be implemented in a `store/v2alpha1` package to avoid breaking existing code. + +#### Merkle Proofs and 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. + +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. + +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"`. + +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. + +The presented workaround can be used until the IBC module is fully upgraded to supports single-element commitment proofs. + +### 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: + +* 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`. + +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. + +TODO: need to make decision about the key compression. + +## Optimization: SS key compression + +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: finalize this or move to another ADR. + +## Migration + +Using the new store will require a migration. 2 Migrations are proposed: + +1. Genesis export -- it will reset the blockchain history. +2. In place migration: we can reuse `UpgradeKeeper.SetUpgradeHandler` to provide the migration logic: + +```go +app.UpgradeKeeper.SetUpgradeHandler("adr-40", func(ctx sdk.Context, plan upgradetypes.Plan, vm module.VersionMap) (module.VersionMap, error) { + + storev2.Migrate(iavlstore, v2.store) + + // RunMigrations returns the VersionMap + // with the updated module ConsensusVersions + return app.mm.RunMigrations(ctx, vm) +}) +``` + +The `Migrate` function will read all entries from a store/v1 DB and save them to the AD-40 combined KV store. +Cache layer should not be used and the operation must finish with a single Commit call. + +Inserting records to the `SC` (SMT) component is the bottleneck. Unfortunately SMT doesn't support batch transactions. +Adding batch transactions to `SC` layer is considered as a feature after the main release. + +## Consequences + +### Backwards Compatibility + +This ADR doesn't introduce any Cosmos SDK level API changes. + +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 + +* 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 + +* 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 + +* Deprecating IAVL, which is one of the core proposals of Cosmos Whitepaper. + +## Alternative designs + +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). + +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 + +### Evaluated KV Databases + +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 + +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) diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-041-in-place-store-migrations.md b/versioned_docs/version-0.47/integrate/architecture/adr-041-in-place-store-migrations.md new file mode 100644 index 000000000..2237b610d --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-041-in-place-store-migrations.md @@ -0,0 +1,167 @@ +# ADR 041: In-Place Store Migrations + +## Changelog + +* 17.02.2021: Initial Draft + +## Status + +Accepted + +## Abstract + +This ADR introduces a mechanism to perform in-place state store migrations during chain software upgrades. + +## 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 genesis 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). + +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)). + +## Decision + +We propose a migration procedure based on modifying the KV store in-place without involving the JSON export-process-import flow described above. + +### Module `ConsensusVersion` + +We introduce a new method on the `AppModule` interface: + +```go +type AppModule interface { + // --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. + +### 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. + +```go +func (am AppModule) RegisterServices(cfg module.Configurator) { + // --snip-- + cfg.RegisterMigration(types.ModuleName, 1, func(ctx sdk.Context) error { + // 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. + }) + // etc. +} +``` + +For example, if the new ConsensusVersion of a module is `N` , then `N-1` migration functions MUST be registered in the configurator. + +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: + +```go +// 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. + +```go +// Migrate1to2 migrates from version 1 to 2. +func (m Migrator) Migrate1to2(ctx sdk.Context) error { + return v2bank.MigrateStore(ctx, m.keeper.storeKey) // v043bank is package `x/bank/migrations/v2`. +} +``` + +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). + +### Tracking Module Versions in `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: + +```text +0x2 | {bytes(module_name)} => BigEndian(module_consensus_version) +``` + +The initial state of the store is set from `app.go`'s `InitChainer` method. + +The UpgradeHandler signature needs to be updated to take a `VersionMap`, as well as return an upgraded `VersionMap` and an error: + +```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. + +```diff +func (k UpgradeKeeper) ApplyUpgrade(ctx sdk.Context, plan types.Plan) { + // --snip-- +- handler(ctx, plan) ++ 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 ++ 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. + +### 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: + +* 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. + +If a required migration is missing (e.g. if it has not been registered in the `Configurator`), then the `RunMigrations` function will error. + +In practice, the `RunMigrations` method should be called from inside an `UpgradeHandler`. + +```go +app.UpgradeKeeper.SetUpgradeHandler("my-plan", func(ctx sdk.Context, plan upgradetypes.Plan, vm module.VersionMap) (module.VersionMap, error) { + return app.mm.RunMigrations(ctx, vm) +}) +``` + +Assuming a chain upgrades at block `n`, the procedure should run as follows: + +* 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. + +## 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. + +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. + +### 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. + +### 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. + +### Neutral + +* The Cosmos SDK will continue to support JSON migrations via the existing `simd export` and `simd genesis 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. + +## 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 diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-042-group-module.md b/versioned_docs/version-0.47/integrate/architecture/adr-042-group-module.md new file mode 100644 index 000000000..52e94327d --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-042-group-module.md @@ -0,0 +1,279 @@ +# ADR 042: Group Module + +## Changelog + +* 2020/04/09: Initial Draft + +## 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. + +## Context + +The legacy amino multi-signature mechanism of the Cosmos SDK has certain limitations: + +* 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)). + +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. + +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. + +## 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. + +### 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. + +```protobuf +message GroupInfo { + + // group_id is the unique ID of this group. + uint64 group_id = 1; + + // admin is the account address of the group's admin. + string admin = 2; + + // 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. + uint64 version = 4; + + // total_weight is the sum of the group members' weights. + string total_weight = 5; +} +``` + +```protobuf +message GroupMember { + + // group_id is the unique ID of the group. + uint64 group_id = 1; + + // member is the member data. + Member member = 2; +} + +// Member represents a group member with an account address, +// non-zero weight and metadata. +message Member { + + // address is the member's account address. + string address = 1; + + // 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. + 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). + +```protobuf +message GroupAccountInfo { + + // address is the group account address. + string address = 1; + + // 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. + string admin = 3; + + // 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. + uint64 version = 5; + + // decision_policy specifies the group account's decision policy. + google.protobuf.Any decision_policy = 6 [(cosmos_proto.accepts_interface) = "cosmos.group.v1.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. + +We define the `DecisionPolicy` interface that all decision policies must implement: + +```go +type DecisionPolicy interface { + codec.ProtoMarshaler + + ValidateBasic() error + GetTimeout() types.Duration + Allow(tally Tally, totalPower string, votingDuration time.Duration) (DecisionPolicyResult, error) + Validate(g GroupInfo) error +} + +type DecisionPolicyResult struct { + Allow bool + Final bool +} +``` + +#### 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_). + +```protobuf +message ThresholdDecisionPolicy { + + // 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. + 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. + +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. + +```protobuf +// Tally represents the sum of weighted votes. +message Tally { + option (gogoproto.goproto_getters) = false; + + // yes_count is the weighted sum of yes votes. + string yes_count = 1; + + // no_count is the weighted sum of no votes. + string no_count = 2; + + // abstain_count is the weighted sum of abstainers. + string abstain_count = 3; + + // 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. + +Voting internally updates the proposal `VoteState` as well as `Status` and `Result` if needed. + +### 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. + +#### 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. + +### 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. + +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`. + +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`. + +Proposals are stored as part of the `proposalTable` using the `Proposal` type. The `proposal_id` is an auto-increment integer. + +Votes are stored in the `voteTable`. The primary key is based on the vote's `proposal_id` and `voter` account address. + +#### ADR-033 to route proposal messages + +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. + +## Consequences + +### Positive + +* Improved UX for multi-signature accounts allowing key rotation and custom decision policies. + +### 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. + +## 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 + +## 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) diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-043-nft-module.md b/versioned_docs/version-0.47/integrate/architecture/adr-043-nft-module.md new file mode 100644 index 000000000..87b4dbb5e --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-043-nft-module.md @@ -0,0 +1,349 @@ +# ADR 43: NFT Module + +## Changelog + +* 2021-05-01: Initial Draft +* 2021-07-02: Review updates +* 2022-06-15: Add batch operation +* 2022-11-11: Remove strict validation of classID and tokenID + +## 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**: + +* `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. + +## 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. + +As discussed in [#9065](https://github.com/cosmos/cosmos-sdk/discussions/9065), several potential solutions can be considered: + +* irismod/nft and modules/incubator/nft +* CW721 +* DID NFTs +* interNFT + +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. + +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. + +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). + +## Decision + +We create a `x/nft` module, which contains the following functionality: + +* 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. + +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). + +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. + +### 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. + +#### 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. + +```protobuf +message Class { + string id = 1; + string name = 2; + string symbol = 3; + string description = 4; + string uri = 5; + string uri_hash = 6; + google.protobuf.Any data = 7; +} +``` + +* `id` 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_ + +#### NFT + +We define a general model for `NFT` as follows. + +```protobuf +message NFT { + string class_id = 1; + string id = 2; + string uri = 3; + string uri_hash = 4; + google.protobuf.Any data = 10; +} +``` + +* `class_id` is the identifier of the NFT class where the NFT belongs; _required_ +* `id` is an 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_ + + ```text + {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_ + +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. + +### `Keeper` Interface + +```go +type Keeper interface { + NewClass(ctx sdk.Context,class Class) + UpdateClass(ctx sdk.Context,class Class) + + Mint(ctx sdk.Context,nft NFT，receiver sdk.AccAddress) // updates totalSupply + BatchMint(ctx sdk.Context, tokens []NFT,receiver sdk.AccAddress) error + + Burn(ctx sdk.Context, classId string, nftId string) // updates totalSupply + BatchBurn(ctx sdk.Context, classID string, nftIDs []string) error + + Update(ctx sdk.Context, nft NFT) + BatchUpdate(ctx sdk.Context, tokens []NFT) error + + Transfer(ctx sdk.Context, classId string, nftId string, receiver sdk.AccAddress) + BatchTransfer(ctx sdk.Context, classID string, nftIDs []string, receiver sdk.AccAddress) error + + GetClass(ctx sdk.Context, classId string) Class + GetClasses(ctx sdk.Context) []Class + + GetNFT(ctx sdk.Context, classId string, nftId string) NFT + GetNFTsOfClassByOwner(ctx sdk.Context, classId string, owner sdk.AccAddress) []NFT + GetNFTsOfClass(ctx sdk.Context, classId string) []NFT + + GetOwner(ctx sdk.Context, classId string, nftId string) sdk.AccAddress + GetBalance(ctx sdk.Context, classId string, owner sdk.AccAddress) uint64 + GetTotalSupply(ctx sdk.Context, classId string) uint64 +} +``` + +Other business logic implementations should be defined in composing modules that import `x/nft` and use its `Keeper`. + +### `Msg` Service + +```protobuf +service Msg { + rpc Send(MsgSend) returns (MsgSendResponse); +} + +message MsgSend { + string class_id = 1; + string id = 2; + string sender = 3; + string reveiver = 4; +} +message MsgSendResponse {} +``` + +`MsgSend` can be used to transfer the ownership of an NFT to another address. + +The implementation outline of the server is as follows: + +```go +type msgServer struct{ + k Keeper +} + +func (m msgServer) Send(ctx context.Context, msg *types.MsgSend) (*types.MsgSendResponse, error) { + // check current ownership + assertEqual(msg.Sender, m.k.GetOwner(msg.ClassId, msg.Id)) + + // 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: + +```protobuf +service Query { + // 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/{owner}/{class_id}"; + } + + // 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 from the given class, same as totalSupply of ERC721. + rpc Supply(QuerySupplyRequest) returns (QuerySupplyResponse) { + option (google.api.http).get = "/cosmos/nft/v1beta1/supply/{class_id}"; + } + + // NFTs queries all NFTs of a given class or owner,choose at least one of the two, similar to tokenByIndex in ERC721Enumerable + rpc NFTs(QueryNFTsRequest) returns (QueryNFTsResponse) { + option (google.api.http).get = "/cosmos/nft/v1beta1/nfts"; + } + + // 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 + rpc Class(QueryClassRequest) returns (QueryClassResponse) { + option (google.api.http).get = "/cosmos/nft/v1beta1/classes/{class_id}"; + } + + // 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 +message QueryBalanceRequest { + string class_id = 1; + string owner = 2; +} + +// 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 +message QueryOwnerRequest { + string class_id = 1; + string id = 2; +} + +// 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 +message QuerySupplyRequest { + string class_id = 1; +} + +// QuerySupplyResponse is the response type for the Query/Supply RPC method +message QuerySupplyResponse { + uint64 amount = 1; +} + +// QueryNFTstRequest is the request type for the Query/NFTs RPC method +message QueryNFTsRequest { + string class_id = 1; + string owner = 2; + cosmos.base.query.v1beta1.PageRequest pagination = 3; +} + +// QueryNFTsResponse is the response type for the Query/NFTs 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 +message QueryNFTRequest { + string class_id = 1; + string id = 2; +} + +// 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 +message QueryClassRequest { + string class_id = 1; +} + +// 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 +message QueryClassesRequest { + // 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 +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. + +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. + +## 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 + +### 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 + +### Negative + +* New IBC app is required for x/nft +* CW721 adapter is required + +### Neutral + +* 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 + +For other kinds of applications on the Hub, more app-specific modules can be developed in the future: + +* `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/main/docs/architecture/adr-033-protobuf-inter-module-comm.md) diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-044-protobuf-updates-guidelines.md b/versioned_docs/version-0.47/integrate/architecture/adr-044-protobuf-updates-guidelines.md new file mode 100644 index 000000000..a5ea31316 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-044-protobuf-updates-guidelines.md @@ -0,0 +1,129 @@ +# ADR 044: Guidelines for Updating Protobuf Definitions + +## Changelog + +* 28.06.2021: Initial Draft +* 02.12.2021: Add `Since:` comment for new fields +* 21.07.2022: Remove the rule of no new `Msg` in the same proto version. + +## Status + +Draft + +## Abstract + +This ADR provides guidelines and recommended practices when updating Protobuf definitions. These guidelines are targeting module developers. + +## Context + +The Cosmos SDK maintains a set of [Protobuf definitions](https://github.com/cosmos/cosmos-sdk/tree/main/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. + +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: + +* 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. + +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. + +## Decision + +We decide to keep [Buf's](https://docs.buf.build/) recommendations with the following exceptions: + +* `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. + +On top of Buf's recommendations we add the following guidelines that are specific to the Cosmos SDK. + +### Updating Protobuf Definition Without Bumping Version + +#### 1. Module developers MAY add new Protobuf definitions + +Module developers MAY add new `message`s, new `Service`s, new `rpc` endpoints, and new fields to existing messages. This recommendation follows the Protobuf specification, but is added in this document for clarity, as the SDK requires one additional change. + +The SDK requires the Protobuf comment of the new addition to contain one line with the following format: + +```protobuf +// 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. + +As examples, the following comments are valid: + +```protobuf +// Since: cosmos-sdk 0.44 + +// 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 0.44 + +// Since: cosmos-sdk 0.42.11 0.44.5 + +// Since: Cosmos SDK 0.42.11, 0.44.5 +``` + +#### 2. Fields MAY be marked as `deprecated`, and nodes MAY implement a protocol-breaking change for handling these fields + +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). + +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: + +* 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`. + +#### 3. Fields MUST NOT be renamed + +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. + +### Incrementing Protobuf Package Version + +TODO, needs architecture review. Some topics: + +* 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 + +## 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 + +* less pain to tool developers +* more compatibility in the ecosystem +* ... + +### Negative + +{negative consequences} + +### Neutral + +* more rigor in Protobuf review + +## 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. + +## 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 + +* [#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 diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-045-check-delivertx-middlewares.md b/versioned_docs/version-0.47/integrate/architecture/adr-045-check-delivertx-middlewares.md new file mode 100644 index 000000000..60172977c --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-045-check-delivertx-middlewares.md @@ -0,0 +1,312 @@ +# ADR 045: BaseApp `{Check,Deliver}Tx` as Middlewares + +## Changelog + +* 20.08.2021: Initial draft. +* 07.12.2021: Update `tx.Handler` interface ([\#10693](https://github.com/cosmos/cosmos-sdk/pull/10693)). +* 17.05.2022: ADR is abandoned, as middlewares are deemed too hard to reason about. + +## Status + +ABANDONED. Replacement is being discussed in [#11955](https://github.com/cosmos/cosmos-sdk/issues/11955). + +## Abstract + +This ADR replaces the current BaseApp `runTx` and antehandlers design with a middleware-based design. + +## 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. + +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. + +## 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`: + +```go +type Handler interface { + CheckTx(ctx context.Context, req Request, checkReq RequestCheckTx) (Response, ResponseCheckTx, error) + DeliverTx(ctx context.Context, req Request) (Response, error) + SimulateTx(ctx context.Context, req Request (Response, error) +} + +type Middleware func(Handler) Handler +``` + +where we define the following arguments and return types: + +```go +type Request struct { + Tx sdk.Tx + TxBytes []byte +} + +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 []*codectypes.Any + Log string + Events []abci.Event +} + +type RequestCheckTx struct { + Type abci.CheckTxType +} + +type ResponseCheckTx struct { + Priority int64 +} +``` + +Please note that because CheckTx handles separate logic related to mempool priotization, its signature is different than DeliverTx and SimulateTx. + +BaseApp holds a reference to a `tx.Handler`: + +```go +type BaseApp struct { + // 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`: + +```go +func (app *BaseApp) DeliverTx(req abci.RequestDeliverTx) abci.ResponseDeliverTx { + var abciRes abci.ResponseDeliverTx + ctx := app.getContextForTx(runTxModeDeliver, req.Tx) + res, err := app.txHandler.DeliverTx(ctx, tx.Request{TxBytes: req.Tx}) + if err != nil { + abciRes = sdkerrors.ResponseDeliverTx(err, uint64(res.GasUsed), uint64(res.GasWanted), app.trace) + return abciRes + } + + abciRes, err = convertTxResponseToDeliverTx(res) + if err != nil { + return sdkerrors.ResponseDeliverTx(err, uint64(res.GasUsed), uint64(res.GasWanted), app.trace) + } + + return abciRes +} + +// convertTxResponseToDeliverTx converts a tx.Response into a abci.ResponseDeliverTx. +func convertTxResponseToDeliverTx(txRes tx.Response) (abci.ResponseDeliverTx, error) { + data, err := makeABCIData(txRes) + if err != nil { + return abci.ResponseDeliverTx{}, nil + } + + return abci.ResponseDeliverTx{ + Data: data, + Log: txRes.Log, + Events: txRes.Events, + }, nil +} + +// 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.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. + +### 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`. + +For example, for creating an arbitrary `MyMiddleware`, we can implement: + +```go +// 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 tx.Handler + // some other fields that are relevant to the middleware can be added here +} + +// 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 + } + } +} + +// 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 + + // run the next middleware + res, checkRes, err := txh.next.CheckTx(ctx, req, checkReq) + + // 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 + + // run the next middleware + res, err := txh.next.DeliverTx(ctx, tx, req) + + // DeliverTx specific post-processing logic + + return res, err +} + +func (h myTxHandler) SimulateTx(ctx context.Context, req Request) (Response, error) { + // SimulateTx specific pre-processing logic + + // run the next middleware + res, err := txh.next.SimulateTx(ctx, tx, req) + + // 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. + +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: + +```text +A.pre + B.pre + C.pre + H # The base tx.handler, for example `RunMsgsTxHandler` + C.post + B.post +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: + +```go +txHandler := middleware.ComposeMiddlewares(H, A, B, C) +``` + +The middleware is set in BaseApp via its `SetTxHandler` setter: + +```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()`. + +### Middlewares Maintained by the Cosmos SDK + +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: + +| Middleware | Description | +| ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| RunMsgsTxHandler | This is the base `tx.Handler`. It replaces the old baseapp's `runMsgs`, and executes a transaction's `Msg`s. | +| TxDecoderMiddleware | This middleware takes in transaction raw bytes, and decodes them into a `sdk.Tx`. It replaces the `baseapp.txDecoder` field, so that BaseApp stays as thin as possible. Since most middlewares read the contents of the `sdk.Tx`, the TxDecoderMiddleware should be run first in the middleware stack. | +| {Antehandlers} | Each antehandler is converted to its own middleware. These middlewares perform signature verification, fee deductions and other validations on the incoming transaction. | +| IndexEventsTxMiddleware | This is a simple middleware that chooses which events to index in Tendermint. Replaces `baseapp.indexEvents` (which unfortunately still exists in baseapp too, because it's used to index Begin/EndBlock events) | +| 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). + +#### 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. + +#### 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`. + +## 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: + +```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, ++}) +if err != nil { + panic(err) +} +- 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. + +### Positive + +* 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 + +* 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. + +### 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. + +## 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. + +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) diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-046-module-params.md b/versioned_docs/version-0.47/integrate/architecture/adr-046-module-params.md new file mode 100644 index 000000000..369cd043d --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-046-module-params.md @@ -0,0 +1,184 @@ +# ADR 046: Module Params + +## Changelog + +* Sep 22, 2021: Initial Draft + +## Status + +Proposed + +## 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 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 + +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. + +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, `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. + +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: + +```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 { + // ... +} +``` + +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 +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 [event 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 + +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. + +### 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. + + + +## 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 diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-047-extend-upgrade-plan.md b/versioned_docs/version-0.47/integrate/architecture/adr-047-extend-upgrade-plan.md new file mode 100644 index 000000000..0df030062 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-047-extend-upgrade-plan.md @@ -0,0 +1,245 @@ +# ADR 047: Extend Upgrade Plan + +## Changelog + +- Nov, 23, 2021: Initial Draft + +## Status + +PROPOSED Not Implemented + +## Abstract + +This ADR expands the existing x/upgrade `Plan` proto message to include new fields for defining pre-run and post-run processes within upgrade tooling. +It also defines a structure for providing downloadable artifacts involved in an upgrade. + +## Context + +The `upgrade` module in conjunction with Cosmovisor are designed to facilitate and automate a blockchain's transition from one version to another. + +Users submit a software upgrade governance proposal containing an upgrade `Plan`. +The [Plan](https://github.com/cosmos/cosmos-sdk/blob/v0.44.5/proto/cosmos/upgrade/v1beta1/upgrade.proto#L12) currently contains the following fields: +- `name`: A short string identifying the new version. +- `height`: The chain height at which the upgrade is to be performed. +- `info`: A string containing information about the upgrade. + +The `info` string can be anything. +However, Cosmovisor will try to use the `info` field to automatically download a new version of the blockchain executable. +For the auto-download to work, Cosmovisor expects it to be either a stringified JSON object (with a specific structure defined through documentation), or a URL that will return such JSON. +The JSON object identifies URLs used to download the new blockchain executable for different platforms (OS and Architecture, e.g. "linux/amd64"). +Such a URL can either return the executable file directly or can return an archive containing the executable and possibly other assets. + +If the URL returns an archive, it is decompressed into `{DAEMON_HOME}/cosmovisor/{upgrade name}`. +Then, if `{DAEMON_HOME}/cosmovisor/{upgrade name}/bin/{DAEMON_NAME}` does not exist, but `{DAEMON_HOME}/cosmovisor/{upgrade name}/{DAEMON_NAME}` does, the latter is copied to the former. +If the URL returns something other than an archive, it is downloaded to `{DAEMON_HOME}/cosmovisor/{upgrade name}/bin/{DAEMON_NAME}`. + +If an upgrade height is reached and the new version of the executable version isn't available, Cosmovisor will stop running. + +Both `DAEMON_HOME` and `DAEMON_NAME` are [environment variables used to configure Cosmovisor](https://github.com/cosmos/cosmos-sdk/blob/cosmovisor/v1.0.0/cosmovisor/README.md#command-line-arguments-and-environment-variables). + +Currently, there is no mechanism that makes Cosmovisor run a command after the upgraded chain has been restarted. + +The current upgrade process has this timeline: +1. An upgrade governance proposal is submitted and approved. +1. The upgrade height is reached. +1. The `x/upgrade` module writes the `upgrade_info.json` file. +1. The chain halts. +1. Cosmovisor backs up the data directory (if set up to do so). +1. Cosmovisor downloads the new executable (if not already in place). +1. Cosmovisor executes the `${DAEMON_NAME} pre-upgrade`. +1. Cosmovisor restarts the app using the new version and same args originally provided. + +## Decision + +### Protobuf Updates + +We will update the `x/upgrade.Plan` message for providing upgrade instructions. +The upgrade instructions will contain a list of artifacts available for each platform. +It allows for the definition of a pre-run and post-run commands. +These commands are not consensus guaranteed; they will be executed by Cosmosvisor (or other) during its upgrade handling. + +```protobuf +message Plan { + // ... (existing fields) + + UpgradeInstructions instructions = 6; +} +``` + +The new `UpgradeInstructions instructions` field MUST be optional. + +```protobuf +message UpgradeInstructions { + string pre_run = 1; + string post_run = 2; + repeated Artifact artifacts = 3; + string description = 4; +} +``` + +All fields in the `UpgradeInstructions` are optional. +- `pre_run` is a command to run prior to the upgraded chain restarting. + If defined, it will be executed after halting and downloading the new artifact but before restarting the upgraded chain. + The working directory this command runs from MUST be `{DAEMON_HOME}/cosmovisor/{upgrade name}`. + This command MUST behave the same as the current [pre-upgrade](https://github.com/cosmos/cosmos-sdk/blob/v0.44.5/docs/migrations/pre-upgrade.md) command. + It does not take in any command-line arguments and is expected to terminate with the following exit codes: + + | Exit status code | How it is handled in Cosmosvisor | + |------------------|---------------------------------------------------------------------------------------------------------------------| + | `0` | Assumes `pre-upgrade` command executed successfully and continues the upgrade. | + | `1` | Default exit code when `pre-upgrade` command has not been implemented. | + | `30` | `pre-upgrade` command was executed but failed. This fails the entire upgrade. | + | `31` | `pre-upgrade` command was executed but failed. But the command is retried until exit code `1` or `30` are returned. | + If defined, then the app supervisors (e.g. Cosmovisor) MUST NOT run `app pre-run`. +- `post_run` is a command to run after the upgraded chain has been started. If defined, this command MUST be only executed at most once by an upgrading node. + The output and exit code SHOULD be logged but SHOULD NOT affect the running of the upgraded chain. + The working directory this command runs from MUST be `{DAEMON_HOME}/cosmovisor/{upgrade name}`. +- `artifacts` define items to be downloaded. + It SHOULD have only one entry per platform. +- `description` contains human-readable information about the upgrade and might contain references to external resources. + It SHOULD NOT be used for structured processing information. + +```protobuf +message Artifact { + string platform = 1; + string url = 2; + string checksum = 3; + string checksum_algo = 4; +} +``` + +- `platform` is a required string that SHOULD be in the format `{OS}/{CPU}`, e.g. `"linux/amd64"`. + The string `"any"` SHOULD also be allowed. + An `Artifact` with a `platform` of `"any"` SHOULD be used as a fallback when a specific `{OS}/{CPU}` entry is not found. + That is, if an `Artifact` exists with a `platform` that matches the system's OS and CPU, that should be used; + otherwise, if an `Artifact` exists with a `platform` of `any`, that should be used; + otherwise no artifact should be downloaded. +- `url` is a required URL string that MUST conform to [RFC 1738: Uniform Resource Locators](https://www.ietf.org/rfc/rfc1738.txt). + A request to this `url` MUST return either an executable file or an archive containing either `bin/{DAEMON_NAME}` or `{DAEMON_NAME}`. + The URL should not contain checksum - it should be specified by the `checksum` attribute. +- `checksum` is a checksum of the expected result of a request to the `url`. + It is not required, but is recommended. + If provided, it MUST be a hex encoded checksum string. + Tools utilizing these `UpgradeInstructions` MUST fail if a `checksum` is provided but is different from the checksum of the result returned by the `url`. +- `checksum_algo` is a string identify the algorithm used to generate the `checksum`. + Recommended algorithms: `sha256`, `sha512`. + Algorithms also supported (but not recommended): `sha1`, `md5`. + If a `checksum` is provided, a `checksum_algo` MUST also be provided. + +A `url` is not required to contain a `checksum` query parameter. +If the `url` does contain a `checksum` query parameter, the `checksum` and `checksum_algo` fields MUST also be populated, and their values MUST match the value of the query parameter. +For example, if the `url` is `"https://example.com?checksum=md5:d41d8cd98f00b204e9800998ecf8427e"`, then the `checksum` field must be `"d41d8cd98f00b204e9800998ecf8427e"` and the `checksum_algo` field must be `"md5"`. + +### Upgrade Module Updates + +If an upgrade `Plan` does not use the new `UpgradeInstructions` field, existing functionality will be maintained. +The parsing of the `info` field as either a URL or `binaries` JSON will be deprecated. +During validation, if the `info` field is used as such, a warning will be issued, but not an error. + +We will update the creation of the `upgrade-info.json` file to include the `UpgradeInstructions`. + +We will update the optional validation available via CLI to account for the new `Plan` structure. +We will add the following validation: +1. If `UpgradeInstructions` are provided: + 1. There MUST be at least one entry in `artifacts`. + 1. All of the `artifacts` MUST have a unique `platform`. + 1. For each `Artifact`, if the `url` contains a `checksum` query parameter: + 1. The `checksum` query parameter value MUST be in the format of `{checksum_algo}:{checksum}`. + 1. The `{checksum}` from the query parameter MUST equal the `checksum` provided in the `Artifact`. + 1. The `{checksum_algo}` from the query parameter MUST equal the `checksum_algo` provided in the `Artifact`. +1. The following validation is currently done using the `info` field. We will apply similar validation to the `UpgradeInstructions`. + For each `Artifact`: + 1. The `platform` MUST have the format `{OS}/{CPU}` or be `"any"`. + 1. The `url` field MUST NOT be empty. + 1. The `url` field MUST be a proper URL. + 1. A `checksum` MUST be provided either in the `checksum` field or as a query parameter in the `url`. + 1. If the `checksum` field has a value and the `url` also has a `checksum` query parameter, the two values MUST be equal. + 1. The `url` MUST return either a file or an archive containing either `bin/{DAEMON_NAME}` or `{DAEMON_NAME}`. + 1. If a `checksum` is provided (in the field or as a query param), the checksum of the result of the `url` MUST equal the provided checksum. + +Downloading of an `Artifact` will happen the same way that URLs from `info` are currently downloaded. + +### Cosmovisor Updates + +If the `upgrade-info.json` file does not contain any `UpgradeInstructions`, existing functionality will be maintained. + +We will update Cosmovisor to look for and handle the new `UpgradeInstructions` in `upgrade-info.json`. +If the `UpgradeInstructions` are provided, we will do the following: +1. The `info` field will be ignored. +1. The `artifacts` field will be used to identify the artifact to download based on the `platform` that Cosmovisor is running in. +1. If a `checksum` is provided (either in the field or as a query param in the `url`), and the downloaded artifact has a different checksum, the upgrade process will be interrupted and Cosmovisor will exit with an error. +1. If a `pre_run` command is defined, it will be executed at the same point in the process where the `app pre-upgrade` command would have been executed. + It will be executed using the same environment as other commands run by Cosmovisor. +1. If a `post_run` command is defined, it will be executed after executing the command that restarts the chain. + It will be executed in a background process using the same environment as the other commands. + Any output generated by the command will be logged. + Once complete, the exit code will be logged. + +We will deprecate the use of the `info` field for anything other than human readable information. +A warning will be logged if the `info` field is used to define the assets (either by URL or JSON). + +The new upgrade timeline is very similar to the current one. Changes are in bold: +1. An upgrade governance proposal is submitted and approved. +1. The upgrade height is reached. +1. The `x/upgrade` module writes the `upgrade_info.json` file **(now possibly with `UpgradeInstructions`)**. +1. The chain halts. +1. Cosmovisor backs up the data directory (if set up to do so). +1. Cosmovisor downloads the new executable (if not already in place). +1. Cosmovisor executes **the `pre_run` command if provided**, or else the `${DAEMON_NAME} pre-upgrade` command. +1. Cosmovisor restarts the app using the new version and same args originally provided. +1. **Cosmovisor immediately runs the `post_run` command in a detached process.** + +## Consequences + +### Backwards Compatibility + +Since the only change to existing definitions is the addition of the `instructions` field to the `Plan` message, and that field is optional, there are no backwards incompatibilities with respects to the proto messages. +Additionally, current behavior will be maintained when no `UpgradeInstructions` are provided, so there are no backwards incompatibilities with respects to either the upgrade module or Cosmovisor. + +### Forwards Compatibility + +In order to utilize the `UpgradeInstructions` as part of a software upgrade, both of the following must be true: +1. The chain must already be using a sufficiently advanced version of the Cosmos SDK. +1. The chain's nodes must be using a sufficiently advanced version of Cosmovisor. + +### Positive + +1. The structure for defining artifacts is clearer since it is now defined in the proto instead of in documentation. +1. Availability of a pre-run command becomes more obvious. +1. A post-run command becomes possible. + +### Negative + +1. The `Plan` message becomes larger. This is negligible because A) the `x/upgrades` module only stores at most one upgrade plan, and B) upgrades are rare enough that the increased gas cost isn't a concern. +1. There is no option for providing a URL that will return the `UpgradeInstructions`. +1. The only way to provide multiple assets (executables and other files) for a platform is to use an archive as the platform's artifact. + +### Neutral + +1. Existing functionality of the `info` field is maintained when the `UpgradeInstructions` aren't provided. + +## Further Discussions + +1. [Draft PR #10032 Comment](https://github.com/cosmos/cosmos-sdk/pull/10032/files?authenticity_token=pLtzpnXJJB%2Fif2UWiTp9Td3MvRrBF04DvjSuEjf1azoWdLF%2BSNymVYw9Ic7VkqHgNLhNj6iq9bHQYnVLzMXd4g%3D%3D&file-filters%5B%5D=.go&file-filters%5B%5D=.proto#r698708349): + Consider different names for `UpgradeInstructions instructions` (either the message type or field name). +1. [Draft PR #10032 Comment](https://github.com/cosmos/cosmos-sdk/pull/10032/files?authenticity_token=pLtzpnXJJB%2Fif2UWiTp9Td3MvRrBF04DvjSuEjf1azoWdLF%2BSNymVYw9Ic7VkqHgNLhNj6iq9bHQYnVLzMXd4g%3D%3D&file-filters%5B%5D=.go&file-filters%5B%5D=.proto#r754655072): + 1. Consider putting the `string platform` field inside `UpgradeInstructions` and make `UpgradeInstructions` a repeated field in `Plan`. + 1. Consider using a `oneof` field in the `Plan` which could either be `UpgradeInstructions` or else a URL that should return the `UpgradeInstructions`. + 1. Consider allowing `info` to either be a JSON serialized version of `UpgradeInstructions` or else a URL that returns that. +1. [Draft PR #10032 Comment](https://github.com/cosmos/cosmos-sdk/pull/10032/files?authenticity_token=pLtzpnXJJB%2Fif2UWiTp9Td3MvRrBF04DvjSuEjf1azoWdLF%2BSNymVYw9Ic7VkqHgNLhNj6iq9bHQYnVLzMXd4g%3D%3D&file-filters%5B%5D=.go&file-filters%5B%5D=.proto#r755462876): + Consider not including the `UpgradeInstructions.description` field, using the `info` field for that purpose instead. +1. [Draft PR #10032 Comment](https://github.com/cosmos/cosmos-sdk/pull/10032/files?authenticity_token=pLtzpnXJJB%2Fif2UWiTp9Td3MvRrBF04DvjSuEjf1azoWdLF%2BSNymVYw9Ic7VkqHgNLhNj6iq9bHQYnVLzMXd4g%3D%3D&file-filters%5B%5D=.go&file-filters%5B%5D=.proto#r754643691): + Consider allowing multiple artifacts to be downloaded for any given `platform` by adding a `name` field to the `Artifact` message. +1. [PR #10502 Comment](https://github.com/cosmos/cosmos-sdk/pull/10602#discussion_r781438288) + Allow the new `UpgradeInstructions` to be provided via URL. +1. [PR #10502 Comment](https://github.com/cosmos/cosmos-sdk/pull/10602#discussion_r781438288) + Allow definition of a `signer` for assets (as an alternative to using a `checksum`). + +## References + +- [Current upgrade.proto](https://github.com/cosmos/cosmos-sdk/blob/v0.44.5/proto/cosmos/upgrade/v1beta1/upgrade.proto) +- [Upgrade Module README](https://github.com/cosmos/cosmos-sdk/blob/v0.44.5/x/upgrade/spec/README.md) +- [Cosmovisor README](https://github.com/cosmos/cosmos-sdk/blob/cosmovisor/v1.0.0/cosmovisor/README.md) +- [Pre-upgrade README](https://github.com/cosmos/cosmos-sdk/blob/v0.44.5/docs/migrations/pre-upgrade.md) +- [Draft/POC PR #10032](https://github.com/cosmos/cosmos-sdk/pull/10032) +- [RFC 1738: Uniform Resource Locators](https://www.ietf.org/rfc/rfc1738.txt) diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-048-consensus-fees.md b/versioned_docs/version-0.47/integrate/architecture/adr-048-consensus-fees.md new file mode 100644 index 000000000..f1c6065cd --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-048-consensus-fees.md @@ -0,0 +1,204 @@ +# ADR 048: Multi Tire Gas Price System + +## Changelog + +* Dec 1, 2021: Initial Draft + +## Status + +Rejected + +## Abstract + +This ADR describes a flexible mechanism to maintain a consensus level gas prices, in which one can choose a multi-tier gas price system or EIP-1559 like one through configuration. + +## Context + +Currently, each validator configures it's own `minimal-gas-prices` in `app.yaml`. But setting a proper minimal gas price is critical to protect network from dos attack, and it's hard for all the validators to pick a sensible value, so we propose to maintain a gas price in consensus level. + +Since tendermint 0.34.20 has supported mempool prioritization, we can take advantage of that to implement more sophisticated gas fee system. + +## Multi-Tier Price System + +We propose a multi-tier price system on consensus to provide maximum flexibility: + +* Tier 1: a constant gas price, which could only be modified occasionally through governance proposal. +* Tier 2: a dynamic gas price which is adjusted according to previous block load. +* Tier 3: a dynamic gas price which is adjusted according to previous block load at a higher speed. + +The gas price of higher tier should bigger than the lower tier. + +The transaction fees are charged with the exact gas price calculated on consensus. + +The parameter schema is like this: + +```protobuf +message TierParams { + uint32 priority = 1 // priority in tendermint mempool + Coin initial_gas_price = 2 // + uint32 parent_gas_target = 3 // the target saturation of block + uint32 change_denominator = 4 // decides the change speed + Coin min_gas_price = 5 // optional lower bound of the price adjustment + Coin max_gas_price = 6 // optional upper bound of the price adjustment +} + +message Params { + repeated TierParams tiers = 1; +} +``` + +### Extension Options + +We need to allow user to specify the tier of service for the transaction, to support it in an extensible way, we add an extension option in `AuthInfo`: + +```protobuf +message ExtensionOptionsTieredTx { + uint32 fee_tier = 1 +} +``` + +The value of `fee_tier` is just the index to the `tiers` parameter list. + +We also change the semantic of existing `fee` field of `Tx`, instead of charging user the exact `fee` amount, we treat it as a fee cap, while the actual amount of fee charged is decided dynamically. If the `fee` is smaller than dynamic one, the transaction won't be included in current block and ideally should stay in the mempool until the consensus gas price drop. The mempool can eventually prune old transactions. + +### Tx Prioritization + +Transactions are prioritized based on the tier, the higher the tier, the higher the priority. + +Within the same tier, follow the default Tendermint order (currently FIFO). Be aware of that the mempool tx ordering logic is not part of consensus and can be modified by malicious validator. + +This mechanism can be easily composed with prioritization mechanisms: + +* we can add extra tiers out of a user control: + * Example 1: user can set tier 0, 10 or 20, but the protocol will create tiers 0, 1, 2 ... 29. For example IBC transactions will go to tier `user_tier + 5`: if user selected tier 1, then the transaction will go to tier 15. + * Example 2: we can reserve tier 4, 5, ... only for special transaction types. For example, tier 5 is reserved for evidence tx. So if submits a bank.Send transaction and set tier 5, it will be delegated to tier 3 (the max tier level available for any transaction). + * Example 3: we can enforce that all transactions of a sepecific type will go to specific tier. For example, tier 100 will be reserved for evidence transactions and all evidence transactions will always go to that tier. + +### `min-gas-prices` + +Deprecate the current per-validator `min-gas-prices` configuration, since it would confusing for it to work together with the consensus gas price. + +### Adjust For Block Load + +For tier 2 and tier 3 transactions, the gas price is adjusted according to previous block load, the logic could be similar to EIP-1559: + +```python +def adjust_gas_price(gas_price, parent_gas_used, tier): + if parent_gas_used == tier.parent_gas_target: + return gas_price + elif parent_gas_used > tier.parent_gas_target: + gas_used_delta = parent_gas_used - tier.parent_gas_target + gas_price_delta = max(gas_price * gas_used_delta // tier.parent_gas_target // tier.change_speed, 1) + return gas_price + gas_price_delta + else: + gas_used_delta = parent_gas_target - parent_gas_used + gas_price_delta = gas_price * gas_used_delta // parent_gas_target // tier.change_speed + return gas_price - gas_price_delta +``` + +### Block Segment Reservation + +Ideally we should reserve block segments for each tier, so the lower tiered transactions won't be completely squeezed out by higher tier transactions, which will force user to use higher tier, and the system degraded to a single tier. + +We need help from tendermint to implement this. + +## Implementation + +We can make each tier's gas price strategy fully configurable in protocol parameters, while providing a sensible default one. + +Pseudocode in python-like syntax: + +```python +interface TieredTx: + def tier(self) -> int: + pass + +def tx_tier(tx): + if isinstance(tx, TieredTx): + return tx.tier() + else: + # default tier for custom transactions + return 0 + # NOTE: we can add more rules here per "Tx Prioritization" section + +class TierParams: + 'gas price strategy parameters of one tier' + priority: int # priority in tendermint mempool + initial_gas_price: Coin + parent_gas_target: int + change_speed: Decimal # 0 means don't adjust for block load. + +class Params: + 'protocol parameters' + tiers: List[TierParams] + +class State: + 'consensus state' + # total gas used in last block, None when it's the first block + parent_gas_used: Optional[int] + # gas prices of last block for all tiers + gas_prices: List[Coin] + +def begin_block(): + 'Adjust gas prices' + for i, tier in enumerate(Params.tiers): + if State.parent_gas_used is None: + # initialized gas price for the first block + State.gas_prices[i] = tier.initial_gas_price + else: + # adjust gas price according to gas used in previous block + State.gas_prices[i] = adjust_gas_price(State.gas_prices[i], State.parent_gas_used, tier) + +def mempoolFeeTxHandler_checkTx(ctx, tx): + # the minimal-gas-price configured by validator, zero in deliver_tx context + validator_price = ctx.MinGasPrice() + consensus_price = State.gas_prices[tx_tier(tx)] + min_price = max(validator_price, consensus_price) + + # zero means infinity for gas price cap + if tx.gas_price() > 0 and tx.gas_price() < min_price: + return 'insufficient fees' + return next_CheckTx(ctx, tx) + +def txPriorityHandler_checkTx(ctx, tx): + res, err := next_CheckTx(ctx, tx) + # pass priority to tendermint + res.Priority = Params.tiers[tx_tier(tx)].priority + return res, err + +def end_block(): + 'Update block gas used' + State.parent_gas_used = block_gas_meter.consumed() +``` + +### Dos attack protection + +To fully saturate the blocks and prevent other transactions from executing, attacker need to use transactions of highest tier, the cost would be significantly higher than the default tier. + +If attacker spam with lower tier transactions, user can mitigate by sending higher tier transactions. + +## Consequences + +### Backwards Compatibility + +* New protocol parameters. +* New consensus states. +* New/changed fields in transaction body. + +### Positive + +* The default tier keeps the same predictable gas price experience for client. +* The higher tier's gas price can adapt to block load. +* No priority conflict with custom priority based on transaction types, since this proposal only occupy three priority levels. +* Possibility to compose different priority rules with tiers + +### Negative + +* Wallets & tools need to update to support the new `tier` parameter, and semantic of `fee` field is changed. + +### Neutral + +## References + +* https://eips.ethereum.org/EIPS/eip-1559 +* https://iohk.io/en/blog/posts/2021/11/26/network-traffic-and-tiered-pricing/ diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-049-state-sync-hooks.md b/versioned_docs/version-0.47/integrate/architecture/adr-049-state-sync-hooks.md new file mode 100644 index 000000000..f1df759e2 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-049-state-sync-hooks.md @@ -0,0 +1,174 @@ +# ADR 049: State Sync Hooks + +## Changelog + +- Jan 19, 2022: Initial Draft +- Apr 29, 2022: Safer extension snapshotter interface + +## Status + +Implemented + +## Abstract + +This ADR outlines a hooks-based mechanism for application modules to provide additional state (outside of the IAVL tree) to be used +during state sync. + +## Context + +New clients use state-sync to download snapshots of module state from peers. Currently, the snapshot consists of a +stream of `SnapshotStoreItem` and `SnapshotIAVLItem`, which means that application modules that define their state outside of the IAVL +tree cannot include their state as part of the state-sync process. + +Note, Even though the module state data is outside of the tree, for determinism we require that the hash of the external data should +be posted in the IAVL tree. + +## Decision + +A simple proposal based on our existing implementation is that, we can add two new message types: `SnapshotExtensionMeta` +and `SnapshotExtensionPayload`, and they are appended to the existing multi-store stream with `SnapshotExtensionMeta` +acting as a delimiter between extensions. As the chunk hashes should be able to ensure data integrity, we don't need +a delimiter to mark the end of the snapshot stream. + +Besides, we provide `Snapshotter` and `ExtensionSnapshotter` interface for modules to implement snapshotters, which will handle both taking +snapshot and the restoration. Each module could have mutiple snapshotters, and for modules with additional state, they should +implement `ExtensionSnapshotter` as extension snapshotters. When setting up the application, the snapshot `Manager` should call +`RegisterExtensions([]ExtensionSnapshotter…)` to register all the extension snapshotters. + +```protobuf +// SnapshotItem is an item contained in a rootmulti.Store snapshot. +// On top of the exsiting SnapshotStoreItem and SnapshotIAVLItem, we add two new options for the item. +message SnapshotItem { + // item is the specific type of snapshot item. + oneof item { + SnapshotStoreItem store = 1; + SnapshotIAVLItem iavl = 2 [(gogoproto.customname) = "IAVL"]; + SnapshotExtensionMeta extension = 3; + SnapshotExtensionPayload extension_payload = 4; + } +} + +// SnapshotExtensionMeta contains metadata about an external snapshotter. +// One module may need multiple snapshotters, so each module may have multiple SnapshotExtensionMeta. +message SnapshotExtensionMeta { + // the name of the ExtensionSnapshotter, and it is registered to snapshotter manager when setting up the application + // name should be unique for each ExtensionSnapshotter as we need to alphabetically order their snapshots to get + // deterministic snapshot stream. + string name = 1; + // this is used by each ExtensionSnapshotter to decide the format of payloads included in SnapshotExtensionPayload message + // it is used within the snapshotter/namespace, not global one for all modules + uint32 format = 2; +} + +// SnapshotExtensionPayload contains payloads of an external snapshotter. +message SnapshotExtensionPayload { + bytes payload = 1; +} +``` + +When we create a snapshot stream, the `multistore` snapshot is always placed at the beginning of the binary stream, and other extension snapshots are alphabetically ordered by the name of the corresponding `ExtensionSnapshotter`. + +The snapshot stream would look like as follows: + +```go +// multi-store snapshot +{SnapshotStoreItem | SnapshotIAVLItem, ...} +// extension1 snapshot +SnapshotExtensionMeta +{SnapshotExtensionPayload, ...} +// extension2 snapshot +SnapshotExtensionMeta +{SnapshotExtensionPayload, ...} +``` + +We add an `extensions` field to snapshot `Manager` for extension snapshotters. The `multistore` snapshotter is a special one and it doesn't need a name because it is always placed at the beginning of the binary stream. + +```go +type Manager struct { + store *Store + multistore types.Snapshotter + extensions map[string]types.ExtensionSnapshotter + mtx sync.Mutex + operation operation + chRestore chan<- io.ReadCloser + chRestoreDone <-chan restoreDone + restoreChunkHashes [][]byte + restoreChunkIndex uint32 +} +``` + +For extension snapshotters that implement the `ExtensionSnapshotter` interface, their names should be registered to the snapshot `Manager` by +calling `RegisterExtensions` when setting up the application. The snapshotters will handle both taking snapshot and restoration. + +```go +// RegisterExtensions register extension snapshotters to manager +func (m *Manager) RegisterExtensions(extensions ...types.ExtensionSnapshotter) error +``` + +On top of the existing `Snapshotter` interface for the `multistore`, we add `ExtensionSnapshotter` interface for the extension snapshotters. Three more function signatures: `SnapshotFormat()`, `SupportedFormats()` and `SnapshotName()` are added to `ExtensionSnapshotter`. + +```go +// ExtensionPayloadReader read extension payloads, +// it returns io.EOF when reached either end of stream or the extension boundaries. +type ExtensionPayloadReader = func() ([]byte, error) + +// ExtensionPayloadWriter is a helper to write extension payloads to underlying stream. +type ExtensionPayloadWriter = func([]byte) error + +// ExtensionSnapshotter is an extension Snapshotter that is appended to the snapshot stream. +// ExtensionSnapshotter has an unique name and manages it's own internal formats. +type ExtensionSnapshotter interface { + // SnapshotName returns the name of snapshotter, it should be unique in the manager. + SnapshotName() string + + // SnapshotFormat returns the default format used to take a snapshot. + SnapshotFormat() uint32 + + // SupportedFormats returns a list of formats it can restore from. + SupportedFormats() []uint32 + + // SnapshotExtension writes extension payloads into the underlying protobuf stream. + SnapshotExtension(height uint64, payloadWriter ExtensionPayloadWriter) error + + // RestoreExtension restores an extension state snapshot, + // the payload reader returns `io.EOF` when reached the extension boundaries. + RestoreExtension(height uint64, format uint32, payloadReader ExtensionPayloadReader) error + +} +``` + +## Consequences + +As a result of this implementation, we are able to create snapshots of binary chunk stream for the state that we maintain outside of the IAVL Tree, CosmWasm blobs for example. And new clients are able to fetch sanpshots of state for all modules that have implemented the corresponding interface from peer nodes. + + +### Backwards Compatibility + +This ADR introduces new proto message types, add an `extensions` field in snapshot `Manager`, and add new `ExtensionSnapshotter` interface, so this is not backwards compatible if we have extensions. + +But for applications that does not have the state data outside of the IAVL tree for any module, the snapshot stream is backwards-compatible. + +### Positive + +- State maintained outside of IAVL tree like CosmWasm blobs can create snapshots by implementing extension snapshotters, and being fetched by new clients via state-sync. + +### Negative + +### Neutral + +- All modules that maintain state outside of IAVL tree need to implement `ExtensionSnapshotter` and the snapshot `Manager` need to call `RegisterExtensions` when setting up the application. + +## 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 + +- https://github.com/cosmos/cosmos-sdk/pull/10961 +- https://github.com/cosmos/cosmos-sdk/issues/7340 +- https://hackmd.io/gJoyev6DSmqqkO667WQlGw diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-050-sign-mode-textual-annex1.md b/versioned_docs/version-0.47/integrate/architecture/adr-050-sign-mode-textual-annex1.md new file mode 100644 index 000000000..db2d3d67c --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-050-sign-mode-textual-annex1.md @@ -0,0 +1,322 @@ +# ADR 050: SIGN_MODE_TEXTUAL: Annex 1 Value Renderers + +## Changelog + +- Dec 06, 2021: Initial Draft +- Feb 07, 2022: Draft read and concept-ACKed by the Ledger team. + +## Status + +Accepted. Implementation started. Small value renderers details still need to be polished. + +## Abstract + +This Annex describes value renderers, which are used for displaying Protobuf values in a human-friendly way using a string array. + +## Value Renderers + +Value Renderers describe how values of different Protobuf types should be encoded as a string array. Value renderers can be formalized as a set of bijective functions `func renderT(value T) []string`, where `T` is one of the below Protobuf types for which this spec is defined. + +### Protobuf `number` + +- Applies to: + - protobuf numeric integer types (`int{32,64}`, `uint{32,64}`, `sint{32,64}`, `fixed{32,64}`, `sfixed{32,64}`) + - strings whose `customtype` is `github.com/cosmos/cosmos-sdk/types.Int` or `github.com/cosmos/cosmos-sdk/types.Dec` + - bytes whose `customtype` is `github.com/cosmos/cosmos-sdk/types.Int` or `github.com/cosmos/cosmos-sdk/types.Dec` +- Trailing decimal zeroes are always removed +- Formatting with `'`s for every three integral digits. +- Usage of `.` to denote the decimal delimiter. + +#### Examples + +- `1000` (uint64) -> `1'000` +- `"1000000.00"` (string representing a Dec) -> `1'000'000` +- `"1000000.10"` (string representing a Dec) -> `1'000'000.1` + +### `coin` + +- Applies to `cosmos.base.v1beta1.Coin`. +- Denoms are converted to `display` denoms using `Metadata` (if available). **This requires a state query**. The definition of `Metadata` can be found in the [bank Protobuf definition](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/bank/v1beta1/bank.proto#L79-L108). If the `display` field is empty or nil, then we do not perform any denom conversion. +- Amounts are converted to `display` denom amounts and rendered as `number`s above + - We do not change the capitalization of the denom. In practice, `display` denoms are stored in lowercase in state (e.g. `10 atom`), however they are often showed in UPPERCASE in everyday life (e.g. `10 ATOM`). Value renderers keep the case used in state, but we may recommend chains changing the denom metadata to be uppercase for better user display. +- One space between the denom and amount (e.g. `10 atom`). +- In the future, IBC denoms could maybe be converted to DID/IIDs, if we can find a robust way for doing this (ex. `cosmos:cosmos:hub:bank:denom:atom`) + +#### Examples + +- `1000000000uatom` -> `["1'000 atom"]`, because atom is the metadata's display denom. + +### `coins` + +- an array of `coin` is display as the concatenation of each `coin` encoded as the specification above, the joined together with the delimiter `", "` (a comma and a space, no quotes around). +- the list of coins is ordered by unicode code point of the display denom: `A-Z` < `a-z`. For example, the string `aAbBcC` would be sorted `ABCabc`. + +### Example + +- `["3cosm", "2000000uatom"]` -> `2 atom, 3 COSM` (assuming the display denoms are `atom` and `COSM`) +- `["10atom", "20Acoin"]` -> `20 Acoin, 10 atom` (assuming the display denoms are `atom` and `Acoin`) + +### `repeated` + +- Applies to all `repeated` fields, except `cosmos.tx.v1beta1.TxBody#Messages`, which has a particular encoding (see [ADR-050](./adr-050-sign-mode-textual.md)). +- A repeated type has the following template: + +``` + has + (/): + + (/): + +End of . +``` + +where: + +- `message_name` is the name of the Protobuf message which holds the `repeated` field, +- `int` is the length of the array, +- `field_name` is the Protobuf field name of the repeated field, + - add an optional `s` at the end if ` > 1` and the `field_name` doesn't already end with `s`. + +#### Examples + +Given the proto definition: + +```protobuf +message AllowedMsgAllowance { + repeated string allowed_messages = 1; +} +``` + +and initializing with: + +```go +x := []AllowedMsgAllowance{"cosmos.bank.v1beta1.MsgSend", "cosmos.gov.v1.MsgVote"} +``` + +we have the following value-rendered encoding: + +``` +Allowed messages: 2 strings +Allowed messages (1/2): cosmos.bank.v1beta1.MsgSend +Allowed messages (2/2): cosmos.gov.v1.MsgVote +End of Allowed messages +``` + +### `message` + +- Applies to Protobuf messages whose name does not start with `Msg` + - For `sdk.Msg`s, please see [ADR-050](./adr-050-sign-mode-textual.md) + - alternatively, we can decide to add a protobuf option to denote messages that are `sdk.Msg`s. +- Field names follow [sentence case](https://en.wiktionary.org/wiki/sentence_case) + - replace `_` with a spaces + - capitalize first letter of the setence +- Field names are ordered by their Protobuf field number +- Nesting: + - if a field contains a nested message, we value-render the underlying message using the template: + ``` + : <1st line of value-rendered message> + > // Notice the `>` prefix. + ``` + - `>` character is used to denote nesting. For each additional level of nesting, add `>`. + +#### Examples + +Given the following Protobuf messages: + +```protobuf +enum VoteOption { + VOTE_OPTION_UNSPECIFIED = 0; + VOTE_OPTION_YES = 1; + VOTE_OPTION_ABSTAIN = 2; + VOTE_OPTION_NO = 3; + VOTE_OPTION_NO_WITH_VETO = 4; +} + +message WeightedVoteOption { + VoteOption option = 1; + string weight = 2 [(cosmos_proto.scalar) = "cosmos.Dec"]; +} + +message Vote { + uint64 proposal_id = 1; + string voter = 2 [(cosmos_proto.scalar) = "cosmos.AddressString"]; + reserved 3; + repeated WeightedVoteOption options = 4; +} +``` + +we get the following encoding for the `Vote` message: + +``` +Vote object +> Proposal id: 4 +> Vote: cosmos1abc...def +> Options: 2 WeightedVoteOptions +> Options (1/2): WeightedVoteOption object +>> Option: Yes +>> Weight: 0.7 +> Options (2/2): WeightedVoteOption object +>> Option: No +>> Weight: 0.3 +> End of Options +``` + +### Enums + +- String case convention: snake case to sentence case +- Allow optional annotation for textual name (TBD) +- Algorithm: + - convert enum name (`VoteOption`) to snake_case (`VOTE_OPTION`) + - truncate that prefix + `_` from the enum name if it exists (`VOTE_OPTION_` gets stripped from `VOTE_OPTION_YES` -> `YES`) + - convert rest to sentence case: `YES` -> `Yes` + - in summary: `VOTE_OPTION_YES` -> `Yes` + +#### Examples + +See example above with `message Vote{}`. + +### `google.protobuf.Any` + +- Applies to `google.protobuf.Any` +- Rendered as: + +``` +Object: +> +``` + +#### Examples + +``` +Object: /cosmos.gov.v1.Vote +> Proposal id: 4 +> Vote: cosmos1abc...def +> Options: 2 WeightedVoteOptions +> Options (1/2): WeightedVoteOption object +>> Option: Yes +>> Weight: 0.7 +> Options (2/2): WeightedVoteOption object +>> Option: No +>> Weight: 0.3 +> End of Options +``` + +### `google.protobuf.Timestamp` + +Rendered using [RFC 3339](https://www.rfc-editor.org/rfc/rfc3339) (a +simplification of ISO 8601), which is the current recommendation for portable +time values. The rendering always uses "Z" (UTC) as the timezone. It uses only +the necessary fractional digits of a second, omitting the fractional part +entirely if the timestamp has no fractional seconds. (The resulting timestamps +are not automatically sortable by standard lexicographic order, but we favor +the legibility of the shorter string.) + +#### Examples + +The timestamp with 1136214245 seconds and 700000000 nanoseconds is rendered +as `2006-01-02T15:04:05.7Z`. +The timestamp with 1136214245 seconds and zero nanoseconds is rendered +as `2006-01-02T15:04:05Z`. + +### `google.protobuf.Duration` + +The duration proto expresses a raw number of seconds and nanoseconds. +This will be rendered as longer time units of days, hours, and minutes, +plus any remaining seconds, in that order. +Leading and trailing zero-quantity units will be omitted, but all +units in between nonzero units will be shown, e.g. ` 3 days, 0 hours, 0 minutes, 5 seconds`. + +Even longer time units such as months or years are imprecise. +Weeks are precise, but not commonly used - `91 days` is more immediately +legible than `13 weeks`. Although `days` can be problematic, +e.g. noon to noon on subsequent days can be 23 or 25 hours depending on +daylight savings transitions, there is significant advantage in using +strict 24-hour days over using only hours (e.g. `91 days` vs `2184 hours`). + +When nanoseconds are nonzero, they will be shown as fractional seconds, +with only the minimum number of digits, e.g `0.5 seconds`. + +A duration of exactly zero is shown as `0 seconds`. + +Units will be given as singular (no trailing `s`) when the quantity is exactly one, +and will be shown in plural otherwise. + +Negative durations will be indicated with a leading minus sign (`-`). + +Examples: + +- `1 day` +- `30 days` +- `-1 day, 12 hours` +- `3 hours, 0 minutes, 53.025 seconds` + +### bytes + +- Bytes are rendered in hexadecimal, all capital letters, without the `0x` prefix. + +### address bytes + +We currently use `string` types in protobuf for addresses so this may not be needed, but if any address bytes are used in sign mode textual they should be rendered with bech32 formatting + +### strings + +Strings are rendered as-is. + +### Default Values + +- Default Protobuf values for each field are skipped. + +#### Example + +```protobuf +message TestData { + string signer = 1; + string metadata = 2; +} +``` + +```go +myTestData := TestData{ + Signer: "cosmos1abc" +} +``` + +We get the following encoding for the `TestData` message: + +``` +TestData object +> Signer: cosmos1abc +``` + +### [ABANDONED] Custom `msg_title` instead of Msg `type_url` + +_This paragraph is in the Annex for informational purposes only, and will be removed in a next update of the ADR._ + +
+ Click to see abandoned idea. + +- all protobuf messages to be used with `SIGN_MODE_TEXTUAL` CAN have a short title associated with them that can be used in format strings whenever the type URL is explicitly referenced via the `cosmos.msg.v1.textual.msg_title` Protobuf message option. +- if this option is not specified for a Msg, then the Protobuf fully qualified name will be used. + +```protobuf +message MsgSend { + option (cosmos.msg.v1.textual.msg_title) = "bank send coins"; +} +``` + +- they MUST be unique per message, per chain + +#### Examples + +- `cosmos.gov.v1.MsgVote` -> `governance v1 vote` + +#### Best Pratices + +We recommend to use this option only for `Msg`s whose Protobuf fully qualified name can be hard to understand. As such, the two examples above (`MsgSend` and `MsgVote`) are not good examples to be used with `msg_title`. We still allow `msg_title` for chains who might have `Msg`s with complex or non-obvious names. + +In those cases, we recommend to drop the version (e.g. `v1`) in the string if there's only one version of the module on chain. This way, the bijective mapping can figure out which message each string corresponds to. If multiple Protobuf versions of the same module exist on the same chain, we recommend keeping the first `msg_title` with version, and the second `msg_title` with version (e.g. `v2`): + +- `mychain.mymodule.v1.MsgDo` -> `mymodule do something` +- `mychain.mymodule.v2.MsgDo` -> `mymodule v2 do something` + +
diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-050-sign-mode-textual-annex2.md b/versioned_docs/version-0.47/integrate/architecture/adr-050-sign-mode-textual-annex2.md new file mode 100644 index 000000000..d4037a50e --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-050-sign-mode-textual-annex2.md @@ -0,0 +1,122 @@ +# ADR 050: SIGN_MODE_TEXTUAL: Annex 2 XXX + +## Changelog + +- Oct 3, 2022: Initial Draft + +## Status + +DRAFT + +## Abstract + +This annex provides normative guidance on how devices should render a +`SIGN_MODE_TEXTUAL` document. + +## Context + +`SIGN_MODE_TEXTUAL` allows a legible version of a transaction to be signed +on a hardware security device, such as a Ledger. Early versions of the +design rendered transactions directly to lines of ASCII text, but this +proved awkward from its in-band signaling, and for the need to display +Unicode text within the transaction. + +## Decision + +`SIGN_MODE_TEXTUAL` renders to an abstract representation, leaving it +up to device-specific software how to present this representation given the +capabilities, limitations, and conventions of the deivce. + +We offer the following normative guidance: + +1. The presentation should be as legible as possible to the user, given +the capabilities of the device. If legibility could be sacrificed for other +properties, we would recommend just using some other signing mode. +Legibility should focus on the common case - it is okay for unusual cases +to be less legible. + +2. The presentation should be invertible if possible without substantial +sacrifice of legibility. Any change to the rendered data should result +in a visible change to the presentation. This extends the integrity of the +signing to user-visible presentation. + +3. The presentation should follow normal conventions of the device, +without sacrificing legibility or invertibility. + +As an illustration of these principles, here is an example algorithm +for presentation on a device which can display a single 80-character +line of printable ASCII characters: + +- The presentation is broken into lines, and each line is presented in +sequence, with user controls for going forward or backward a line. + +- Expert mode screens are only presented if the device is in expert mode. + +- Each line of the screen starts with a number of `>` characters equal +to the screen's indentation level, followed by a `+` character if this +isn't the first line of the screen, followed by a space if either a +`>` or a `+` has been emitted, +or if this header is followed by a `>`, `+`, or space. + +- If the line ends with whitespace or an `@` character, an additional `@` +character is appended to the line. + +- The following ASCII control characters or backslash (`\`) are converted +to a backslash followed by a letter code, in the manner of string literals +in many languages: + + - a: U+0007 alert or bell + - b: U+0008 backspace + - f: U+000C form feed + - n: U+000A line feed + - r: U+000D carriage return + - t: U+0009 horizontal tab + - v: U+000B vertical tab + - `\`: U+005C backslash + +- All other ASCII control characters, plus non-ASCII Unicode code points, +are shown as either: + + - `\u` followed by 4 uppercase hex chacters for code points + in the basic multilingual plane (BMP). + + - `\U` followed by 8 uppercase hex characters for other code points. + +- The screen will be broken into multiple lines to fit the 80-character +limit, considering the above transformations in a way that attempts to +minimize the number of lines generated. Expanded control or Unicode characters +are never split across lines. + +Example output: + +``` +An introductory line. +key1: 123456 +key2: a string that ends in whitespace @ +key3: a string that ends in a single ampersand - @@ + >tricky key4<: note the leading space in the presentation +introducing an aggregate +> key5: false +> key6: a very long line of text, please co\u00F6perate and break into +>+ multiple lines. +> Can we do further nesting? +>> You bet we can! +``` + +The inverse mapping gives us the only input which could have +generated this output (JSON notation for string data): + +``` +Indent Text +------ ---- +0 "An introductory line." +0 "key1: 123456" +0 "key2: a string that ends in whitespace " +0 "key3: a string that ends in a single ampersand - @" +0 ">tricky key4<: note the leading space in the presentation" +0 "introducing an aggregate" +1 "key5: false" +1 "key6: a very long line of text, please coöperate and break into multiple lines." +1 "Can we do further nesting?" +2 "You bet we can!" +``` diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-050-sign-mode-textual.md b/versioned_docs/version-0.47/integrate/architecture/adr-050-sign-mode-textual.md new file mode 100644 index 000000000..4fa83852e --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-050-sign-mode-textual.md @@ -0,0 +1,592 @@ +# ADR 050: SIGN_MODE_TEXTUAL + +## Changelog + +- Dec 06, 2021: Initial Draft. +- Feb 07, 2022: Draft read and concept-ACKed by the Ledger team. +- May 16, 2022: Change status to Accepted. +- Aug 11, 2022: Require signing over tx raw bytes. +- Sep 07, 2022: Add custom `Msg`-renderers. +- Sep 18, 2022: Structured format instead of lines of text + +## Status + +Accepted. Implementation started. Small value renderers details still need to be polished. + +## Abstract + +This ADR specifies SIGN_MODE_TEXTUAL, a new string-based sign mode that is targetted at signing with hardware devices. + +## Context + +Protobuf-based SIGN_MODE_DIRECT was introduced in [ADR-020](./adr-020-protobuf-transaction-encoding.md) and is intended to replace SIGN_MODE_LEGACY_AMINO_JSON in most situations, such as mobile wallets and CLI keyrings. However, the [Ledger](https://www.ledger.com/) hardware wallet is still using SIGN_MODE_LEGACY_AMINO_JSON for displaying the sign bytes to the user. Hardware wallets cannot transition to SIGN_MODE_DIRECT as: + +- SIGN_MODE_DIRECT is binary-based and thus not suitable for display to end-users. Technically, hardware wallets could simply display the sign bytes to the user. But this would be considered as blind signing, and is a security concern. +- hardware cannot decode the protobuf sign bytes due to memory constraints, as the Protobuf definitions would need to be embedded on the hardware device. + +In an effort to remove Amino from the SDK, a new sign mode needs to be created for hardware devices. [Initial discussions](https://github.com/cosmos/cosmos-sdk/issues/6513) propose a text-based sign mode, which this ADR formally specifies. + +## Decision + +In SIGN_MODE_TEXTUAL, a transaction is rendered into a textual representation, +which is then sent to a secure device or subsystem for the user to review and sign. +Unlike `SIGN_MODE_DIRECT`, the transmitted data can be simply decoded into legible text +even on devices with limited processing and display. + +The textual representation is a sequence of _screens_. +Each screen is meant to be displayed in its entirety (if possible) even on a small device like a Ledger. +A screen is roughly equivalent to a short line of text. +Large screens can be displayed in several pieces, +much as long lines of text are wrapped, +so no hard guidance is given, though 40 characters is a good target. +A screen is used to display a single key/value pair for scalar values +(or composite values with a compact notation, such as `Coins`) +or to introduce or conclude a larger grouping. + +The text can contain the full range of Unicode code points, including control characters and nul. +The device is responsible for deciding how to display characters it cannot render natively. +See [annex 2](./adr-050-sign-mode-textual-annex2.md) for guidance. + +Screens have a non-negative indentation level to signal composite or nested structures. +Indentation level zero is the top level. +Indentation is displayed via some device-specific mechanism. +Message quotation notation is an appropriate model, such as +leading `>` characters or vertical bars on more capable displays. + +Some screens are marked as _expert_ screens, +meant to be displayed only if the viewer chooses to opt in for the extra detail. +Expert screens are meant for information that is rarely useful, +or needs to be present only for signature integrity (see below). + +### Invertible Rendering + +We require that the rendering of the transaction be invertible: +there must be a parsing function such that for every transaction, +when rendered to the textual representation, +parsing that representation yeilds a proto message equivalent +to the original under proto equality. + +Note that this inverse function does not need to perform correct +parsing or error signaling for the whole domain of textual data. +Merely that the range of valid transactions be invertible under +the composition of rendering and parsing. + +Note that the existence of an inverse function ensures that the +rendered text contains the full information of the original transaction, +not a hash or subset. + +### Chain State + +The rendering function (and parsing function) may depend on the current chain state. +This is useful for reading parameters, such as coin display metadata, +or for reading user-specific preferences such as language or address aliases. +Note that if the observed state changes between signature generation +and the transaction's inclusion in a block, the delivery-time rendering +might differ. If so, the signature will be invalid and the transaction +will be rejected. + +### Signature and Security + +For security, transaction signatures should have three properties: + +1. Given the transaction, signatures, and chain state, it must be possible to validate that the signatures matches the transaction, +to verify that the signers must have known their respective secret keys. + +2. It must be computationally infeasible to find a substantially different transaction for which the given signatures are valid, given the same chain state. + +3. The user should be able to give informed consent to the signed data via a simple, secure device with limited display capabilities. + +The correctness and security of `SIGN_MODE_TEXTUAL` is guaranteed by demonstrating an inverse function from the rendering to transaction protos. +This means that it is impossible for a different protocol buffer message to render to the same text. + +### Transaction Hash Malleability + +When client software forms a transaction, the "raw" transaction (`TxRaw`) is serialized as a proto +and a hash of the resulting byte sequence is computed. +This is the `TxHash`, and is used by various services to track the submitted transaction through its lifecycle. +Various misbehavior is possible if one can generate a modified transaction with a different TxHash +but for which the signature still checks out. + +SIGN_MODE_TEXTUAL prevents this transaction malleability by including the TxHash as an expert screen +in the rendering. + +### SignDoc + +The SignDoc for `SIGN_MODE_TEXTUAL` is formed from a data structure like: + +``` +type Screen struct { + Text string text // possibly size limited to, e.g. 255 characters + Indent uint8 // size limited to something small like 16 or 32 + Expert bool +} + +type SignDocTextual = []Screen +``` + +We do not plan to use protobuf serialization to form the sequence of bytes +that will be tranmitted and signed, in order to keep the decoder simple. +We will use [CBOR](https://cbor.io) ([RFC 8949](https://www.rfc-editor.org/rfc/rfc8949.html)) instead. + +TODO: specify the details of the CBOR encoding. + +## Details + +In the examples that follow, screens will be shown as lines of text, +indentation is indicated with a leading '>', +and expert screens are marked with a leading `*`. + +### Encoding of the Transaction Envelope + +We define "transaction envelope" as all data in a transaction that is not in the `TxBody.Messages` field. Transaction envelope includes fee, signer infos and memo, but don't include `Msg`s. `//` denotes comments and are not shown on the Ledger device. + +``` +Chain ID: +Account number: +*Public Key: +Sequence: + // See #8. +Fee: // See value renderers for coins encoding. +*Fee payer: // Skipped if no fee_payer set +*Fee granter: // Skipped if no fee_granter set +Memo: // Skipped if no memo set +*Gas Limit: +*Timeout Height: // Skipped if no timeout_height set +Tipper: // If there's a tip +Tip: +*This transaction has body extension: // Skipped if no body extension options +* +*This transaction has body non-critical extensions: // Skipped if no body non-critical extension options +* // See value renderers for Any and array encoding. +*This transaction has body auth info extensions: // Skipped if no auth info extension options +* +*This transaction has other signers: // Skipped if there is only one signer +*Signer (/): +*Public Key: +*Sequence: +*End of other signers +*Hash of raw bytes: // Hex encoding of bytes defined in #10, to prevent tx hash malleability. +``` + +### Encoding of the Transaction Body + +Transaction Body is the `Tx.TxBody.Messages` field, which is an array of `Any`s, where each `Any` packs a `sdk.Msg`. Since `sdk.Msg`s are widely used, they have a slightly different encoding than usual array of `Any`s (Protobuf: `repeated google.protobuf.Any`) described in Annex 1. + +``` +This transaction has message: // Optional 's' for "message" if there's is >1 sdk.Msgs. +// For each Msg, print the following 2 lines: +Msg (/): // E.g. Msg (1/2): bank v1beta1 send coins + +End of transaction messages +``` + +#### Example + +Given the following Protobuf message: + +```protobuf +message Grant { + google.protobuf.Any authorization = 1 [(cosmos_proto.accepts_interface) = "cosmos.authz.v1beta1.Authorization"]; + google.protobuf.Timestamp expiration = 2 [(gogoproto.stdtime) = true, (gogoproto.nullable) = false]; +} + +message MsgGrant { + option (cosmos.msg.v1.signer) = "granter"; + option (cosmos.msg.v1.textual.type_url) = "authz v1beta1 grant"; + + string granter = 1 [(cosmos_proto.scalar) = "cosmos.AddressString"]; + string grantee = 2 [(cosmos_proto.scalar) = "cosmos.AddressString"]; +} +``` + +and a transaction containing 1 such `sdk.Msg`, we get the following encoding: + +``` +This transaction has 1 message: +Msg (1/1): authz v1beta1 grant +Granter: cosmos1abc...def +Grantee: cosmos1ghi...jkl +End of transaction messages +``` + +### Custom `Msg` Renderers + +Application developers may choose to not follow default renderer value output for their own `Msg`s. In this case, they can implement their own custom `Msg` renderer. This is similar to [EIP4430](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-4430.md), where the smart contract developer chooses the description string to be shown to the end user. + +This is done by setting the `cosmos.msg.v1.textual.expert_custom_renderer` Protobuf option to a non-empty string. This option CAN ONLY be set on a Protobuf message representing transaction message object (implementing `sdk.Msg` interface). + +```protobuf +message MsgFooBar { + // Optional comments to describe in human-readable language the formatting + // rules of the custom renderer. + option (cosmos.msg.v1.textual.expert_custom_renderer) = ""; + + // proto fields +} +``` + +When this option is set on a `Msg`, a registered function will transform the `Msg` into an array of one or more strings, which MAY use the key/value format (described in point #3) with the expert field prefix (described in point #5) and arbitrary indentation (point #6). These strings MAY be rendered from a `Msg` field using a default value renderer, or they may be generated from several fields using custom logic. + +The `` is a string convention chosen by the application developer and is used to identify the custom `Msg` renderer. For example, the documentation or specification of this custom algorithm can reference this identifier. This identifier CAN have a versioned suffix (e.g. `_v1`) to adapt for future changes (which would be consensus-breaking). We also recommend adding Protobuf comments to describe in human language the custom logic used. + +Moreover, the renderer must provide 2 functions: one for formatting from Protobuf to string, and one for parsing string to Protobuf. These 2 functions are provided by the application developer. To satisfy point #1, the parse function MUST be the inverse of the formatting function. This property will not be checked by the SDK at runtime. However, we strongly recommend the application developer to include a comprehensive suite in their app repo to test invertibility, as to not introduce security bugs. + +### Require signing over the `TxBody` and `AuthInfo` raw bytes + +Recall that the transaction bytes merklelized on chain are the Protobuf binary serialization of [TxRaw](hhttps://buf.build/cosmos/cosmos-sdk/docs/main:cosmos.tx.v1beta1#cosmos.tx.v1beta1.TxRaw), which contains the `body_bytes` and `auth_info_bytes`. Moreover, the transaction hash is defined as the SHA256 hash of the `TxRaw` bytes. We require that the user signs over these bytes in SIGN_MODE_TEXTUAL, more specifically over the following string: + +``` +*Hash of raw bytes: +``` + +where: +- `++` denotes concatenation, +- `HEX` is the hexadecimal representation of the bytes, all in capital letters, no `0x` prefix, +- and `len()` is encoded as a Big-Endian uint64. + +This is to prevent transaction hash malleability. The point #1 about invertiblity assures that transaction `body` and `auth_info` values are not malleable, but the transaction hash still might be malleable with point #1 only, because the SIGN_MODE_TEXTUAL strings don't follow the byte ordering defined in `body_bytes` and `auth_info_bytes`. Without this hash, a malicious validator or exchange could intercept a transaction, modify its transaction hash _after_ the user signed it using SIGN_MODE_TEXTUAL (by tweaking the byte ordering inside `body_bytes` or `auth_info_bytes`), and then submit it to Tendermint. + +By including this hash in the SIGN_MODE_TEXTUAL signing payload, we keep the same level of guarantees as [SIGN_MODE_DIRECT](./adr-020-protobuf-transaction-encoding.md). + +These bytes are only shown in expert mode, hence the leading `*`. + +## Additional Formatting by the Hardware Device + +See [annex 2](./adr-050-sign-mode-textual-annex2.md). + +## Examples + +#### Example 1: Simple `MsgSend` + +JSON: + +```json +{ + "body": { + "messages": [ + { + "@type": "/cosmos.bank.v1beta1.MsgSend", + "from": "cosmos1...abc", + "to": "cosmos1...def", + "amount": [ + { + "denom": "uatom", + "amount": 10000000 + } + ] + } + ] + }, + "auth_info": { + "signer_infos": [ + { + "public_key": "iQ...==", + "mode_info": { "single": { "mode": "SIGN_MODE_TEXTUAL" } }, + "sequence": 2 + } + ], + "fee": { + "amount": [ + { + "denom": "atom", + "amount": 0.002 + } + ], + "gas_limit": 100000 + } + }, + // Additional SignerData. + "chain_id": "simapp-1", + "account_number": 10 +} +``` + +SIGN_MODE_TEXTUAL: + +``` +Chain ID: simapp-1 +Account number: 10 +*Public Key: iQ...== // Hex pubkey +Sequence: 2 +This transaction has 1 message: +Message (1/1): bank v1beta1 send coins +From: cosmos1...abc +To: cosmos1...def +Amount: 10 atom // Conversion from uatom to atom using value renderers +End of transaction messages +Fee: 0.002 atom +*Gas: 100'000 +*Hash of raw bytes: +``` + +#### Example 2: Multi-Msg Transaction with 3 signers + +#### Example 3: Legacy Multisig + +#### Example 4: Fee Payer with Tips + +```json +{ + "body": { + "messages": [ + { + "@type": "/cosmos.bank.v1beta1.MsgSend", + "from": "cosmos1...tipper", + "to": "cosmos1...abc", + "amount": [ + { + "denom": "uatom", + "amount": 10000000 + } + ] + } + ] + }, + "auth_info": { + "signer_infos": [ + { + "public_key": "iQ...==", + "mode_info": { "single": { "mode": "SIGN_MODE_DIRECT_AUX" } }, + "sequence": 42 + }, + { + "public_key": "iR...==", + "mode_info": { "single": { "mode": "SIGN_MODE_TEXTUAL" } }, + "sequence": 2 + } + ], + "fee": { + "amount": [ + { + "denom": "atom", + "amount": 0.002 + } + ], + "gas_limit": 100000, + "payer": "cosmos1...feepayer" + }, + "tip": { + "amount": [ + { + "denom": "ibc/CDC4587874B85BEA4FCEC3CEA5A1195139799A1FEE711A07D972537E18FDA39D", + "amount": 200 + } + ], + "tipper": "cosmos1...tipper" + } + }, + // Additional SignerData. + "chain_id": "simapp-1", + "account_number": 10 +} +``` + +SIGN_MODE_TEXTUAL for the feepayer: + +``` +Chain ID: simapp-1 +Account number: 10 +*Public Key: iR...== +Sequence: 2 +This transaction has 1 message: +Message (1/1): bank v1beta1 send coins +From: cosmos1...abc +To: cosmos1...def +Amount: 10 atom +End of transaction messages +Fee: 0.002 atom +Fee Payer: cosmos1...feepayer +Tipper: cosmos1...tipper +Tip: 200 ibc/CDC4587874B85BEA4FCEC3CEA5A1195139799A1FEE711A07D972537E18FDA39D +*Gas: 100'000 +*This transaction has 1 other signer: +*Signer (1/2): +*Public Key: iQ...== +*Sign mode: Direct Aux +*Sequence: 42 +*End of other signers +*Hash of raw bytes: +``` + +#### Example 5: Complex Transaction with Nested Messages + +JSON: + +```json +{ + "body": { + "messages": [ + { + "@type": "/cosmos.bank.v1beta1.MsgSend", + "from": "cosmos1...abc", + "to": "cosmos1...def", + "amount": [ + { + "denom": "uatom", + "amount": 10000000 + } + ] + }, + { + "@type": "/cosmos.gov.v1.MsgSubmitProposal", + "proposer": "cosmos1...ghi", + "messages": [ + { + "@type": "/cosmos.bank.v1beta1.MsgSend", + "from": "cosmos1...jkl", + "to": "cosmos1...mno", + "amount": [ + { + "denom": "uatom", + "amount": 20000000 + } + ] + }, + { + "@type": "/cosmos.authz.v1beta1.MsgExec", + "grantee": "cosmos1...pqr", + "msgs": [ + { + "@type": "/cosmos.bank.v1beta1.MsgSend", + "from": "cosmos1...stu", + "to": "cosmos1...vwx", + "amount": [ + { + "denom": "uatom", + "amount": 30000000 + } + ] + }, + { + "@type": "/cosmos.bank.v1beta1.MsgSend", + "from": "cosmos1...abc", + "to": "cosmos1...def", + "amount": [ + { + "denom": "uatom", + "amount": 40000000 + } + ] + } + ] + } + ], + "initial_deposit": [ + { + "denom": "atom", + "amount": 100.01 + } + ] + } + ] + }, + "auth_info": { + "signer_infos": [ + { + "public_key": "iQ...==", + "mode_info": { "single": { "mode": "SIGN_MODE_TEXTUAL" } }, + "sequence": 2 + }, + { + "public_key": "iR...==", + "mode_info": { "single": { "mode": "SIGN_MODE_DIRECT" } }, + "sequence": 42 + } + ], + "fee": { + "amount": [ + { + "denom": "atom", + "amount": 0.002 + } + ], + "gas_limit": 100000 + } + }, + // Additional SignerData. + "chain_id": "simapp-1", + "account_number": 10 +} +} +``` + +SIGN_MODE_TEXTUAL for 1st signer `cosmos1...abc`: + +``` +Chain ID: simapp-1 +Account number: 10 +*Public Key: iQ...== +Sequence: 2 +This transaction has 2 messages: +Message (1/2): bank v1beta1 send coins +From: cosmos1...abc +To: cosmos1...def +Amount: 10 atom +Message (2/2): gov v1 submit proposal +Messages: 2 Messages +> Message (1/2): bank v1beta1 send coins +> From: cosmos1...jkl +> To: cosmos1...mno +> Amount: 20 atom +> Message (2/2): authz v1beta exec +> Grantee: cosmos1...pqr +> Msgs: 2 Msgs +>> Msg (1/2): bank v1beta1 send coins +>> From: cosmos1...stu +>> To: cosmos1...vwx +>> Amount: 30 atom +>> Msg (2/2): bank v1beta1 send coins +>> From: cosmos1...abc +>> To: cosmos1...def +>> Amount: 40 atom +> End of Msgs +End of transaction messages +Proposer: cosmos1...ghi +Initial Deposit: 100.01 atom +End of transaction messages +Fee: 0.002 atom +*Gas: 100'000 +*This transaction has 1 other signer: +*Signer (2/2): +*Public Key: iR...== +*Sign mode: Direct +*Sequence: 42 +*End of other signers +*Hash of raw bytes: +``` + +## Consequences + +### Backwards Compatibility + +SIGN_MODE_TEXTUAL is purely additive, and doesn't break any backwards compatibility with other sign modes. + +### Positive + +- Human-friendly way of signing in hardware devices. +- Once SIGN_MODE_TEXTUAL is shipped, SIGN_MODE_LEGACY_AMINO_JSON can be deprecated and removed. On the longer term, once the ecosystem has totally migrated, Amino can be totally removed. + +### Negative + +- Some fields are still encoded in non-human-readable ways, such as public keys in hexadecimal. +- New ledger app needs to be released, still unclear + +### Neutral + +- If the transaction is complex, the string array can be arbitrarily long, and some users might just skip some screens and blind sign. + +## Further Discussions + +- Some details on value renderers need to be polished, see [Annex 1](./adr-050-sign-mode-textual-annex1.md). +- Are ledger apps able to support both SIGN_MODE_LEGACY_AMINO_JSON and SIGN_MODE_TEXTUAL at the same time? +- Open question: should we add a Protobuf field option to allow app developers to overwrite the textual representation of certain Protobuf fields and message? This would be similar to Ethereum's [EIP4430](https://github.com/ethereum/EIPs/pull/4430), where the contract developer decides on the textual representation. +- Internationalization. + +## References + +- [Annex 1](./adr-050-sign-mode-textual-annex1.md) + +- Initial discussion: https://github.com/cosmos/cosmos-sdk/issues/6513 +- Living document used in the working group: https://hackmd.io/fsZAO-TfT0CKmLDtfMcKeA?both +- Working group meeting notes: https://hackmd.io/7RkGfv_rQAaZzEigUYhcXw +- Ethereum's "Described Transactions" https://github.com/ethereum/EIPs/pull/4430 diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-053-go-module-refactoring.md b/versioned_docs/version-0.47/integrate/architecture/adr-053-go-module-refactoring.md new file mode 100644 index 000000000..9093ae9d9 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-053-go-module-refactoring.md @@ -0,0 +1,109 @@ +# ADR 053: Go Module Refactoring + +## Changelog + +* 2022-04-27: First Draft + +## Status + +PROPOSED + +## Abstract + +The current SDK is built as a single monolithic go module. This ADR describes +how we refactor the SDK into smaller independently versioned go modules +for ease of maintenance. + +## Context + +Go modules impose certain requirements on software projects with respect to +stable version numbers (anything above 0.x) in that [any API breaking changes +necessitate a major version](https://go.dev/doc/modules/release-workflow#breaking) +increase which technically creates a new go module +(with a v2, v3, etc. suffix). + +[Keeping modules API compatible](https://go.dev/blog/module-compatibility) in +this way requires a fair amount of fair thought and discipline. + +The Cosmos SDK is a fairly large project which originated before go modules +came into existence and has always been under a v0.x release even though +it has been used in production for years now, not because it isn't production +quality software, but rather because the API compatibility guarantees required +by go modules are fairly complex to adhere to with such a large project. +Up to now, it has generally been deemed more important to be able to break the +API if needed rather than require all users update all package import paths +to accommodate breaking changes causing v2, v3, etc. releases. This is in +addition to the other complexities related to protobuf generated code that will +be addressed in a separate ADR. + +Nevertheless, the desire for semantic versioning has been [strong in the +community](https://github.com/cosmos/cosmos-sdk/discussions/10162) and the +single go module release process has made it very hard to +release small changes to isolated features in a timely manner. Release cycles +often exceed six months which means small improvements done in a day or +two get bottle-necked by everything else in the monolithic release cycle. + +## Decision + +To improve the current situation, the SDK is being refactored into multiple +go modules within the current repository. There has been a [fair amount of +debate](https://github.com/cosmos/cosmos-sdk/discussions/10582#discussioncomment-1813377) +as to how to do this, with some developers arguing for larger vs smaller +module scopes. There are pros and cons to both approaches (which will be +discussed below in the [Consequences](#consequences) section), but the +approach being adopted is the following: +* a go module should generally be scoped to a specific coherent set of +functionality (such as math, errors, store, etc.) +* when code is removed from the core SDK and moved to a new module path, every +effort should be made to avoid API breaking changes in the existing code using +aliases and wrapper types (as done in https://github.com/cosmos/cosmos-sdk/pull/10779 +and https://github.com/cosmos/cosmos-sdk/pull/11788) +* new go modules should be moved to a standalone domain (`cosmossdk.io`) before +being tagged as `v1.0.0` to accommodate the possibility that they may be +better served by a standalone repository in the future +* all go modules should follow the guidelines in https://go.dev/blog/module-compatibility +before `v1.0.0` is tagged and should make use of `internal` packages to limit +the exposed API surface +* the new go module's API may deviate from the existing code where there are +clear improvements to be made or to remove legacy dependencies (for instance on +amino or gogo proto), as long the old package attempts +to avoid API breakage with aliases and wrappers +* care should be taken when simply trying to turn an existing package into a +new go module: https://github.com/golang/go/wiki/Modules#is-it-possible-to-add-a-module-to-a-multi-module-repository. +In general, it seems safer to just create a new module path (appending v2, v3, etc. +if necessary), rather than trying to make an old package a new module. + +## Consequences + +### Backwards Compatibility + +If the above guidelines are followed to use aliases or wrapper types pointing +in existing APIs that point back to the new go modules, there should be no or +very limited breaking changes to existing APIs. + +### Positive + +* standalone pieces of software will reach `v1.0.0` sooner +* new features to specific functionality will be released sooner + +### Negative + +* there will be more go module versions to update in the SDK itself and +per-project, although most of these will hopefully be indirect + +### Neutral + +## Further Discussions + +Further discussions are occurring in primarily in +https://github.com/cosmos/cosmos-sdk/discussions/10582 and within +the Cosmos SDK Framework Working Group. + +## References + +* https://go.dev/doc/modules/release-workflow +* https://go.dev/blog/module-compatibility +* https://github.com/cosmos/cosmos-sdk/discussions/10162 +* https://github.com/cosmos/cosmos-sdk/discussions/10582 +* https://github.com/cosmos/cosmos-sdk/pull/10779 +* https://github.com/cosmos/cosmos-sdk/pull/11788 \ No newline at end of file diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-055-orm.md b/versioned_docs/version-0.47/integrate/architecture/adr-055-orm.md new file mode 100644 index 000000000..71a759526 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-055-orm.md @@ -0,0 +1,111 @@ +# ADR 055: ORM + +## Changelog + +* 2022-04-27: First draft + +## Status + +ACCEPTED Implemented + +## Abstract + +In order to make it easier for developers to build Cosmos SDK modules and for clients to query, index and verify proofs +against state data, we have implemented an ORM (object-relational mapping) layer for the Cosmos SDK. + +## Context + +Historically modules in the Cosmos SDK have always used the key-value store directly and created various handwritten +functions for managing key format as well as constructing secondary indexes. This consumes a significant amount of +time when building a module and is error-prone. Because key formats are non-standard, sometimes poorly documented, +and subject to change, it is hard for clients to generically index, query and verify merkle proofs against state data. + +The known first instance of an "ORM" in the Cosmos ecosystem was in [weave](https://github.com/iov-one/weave/tree/master/orm). +A later version was built for [regen-ledger](https://github.com/regen-network/regen-ledger/tree/157181f955823149e1825263a317ad8e16096da4/orm) for +use in the group module and later [ported to the SDK](https://github.com/cosmos/cosmos-sdk/tree/35d3312c3be306591fcba39892223f1244c8d108/x/group/internal/orm) +just for that purpose. + +While these earlier designs made it significantly easier to write state machines, they still required a lot of manual +configuration, didn't expose state format directly to clients, and were limited in their support of different types +of index keys, composite keys, and range queries. + +Discussions about the design continued in https://github.com/cosmos/cosmos-sdk/discussions/9156 and more +sophisticated proofs of concept were created in https://github.com/allinbits/cosmos-sdk-poc/tree/master/runtime/orm +and https://github.com/cosmos/cosmos-sdk/pull/10454. + +## Decision + +These prior efforts culminated in the creation of the Cosmos SDK `orm` go module which uses protobuf annotations +for specifying ORM table definitions. This ORM is based on the new `google.golang.org/protobuf/reflect/protoreflect` +API and supports: +* sorted indexes for all simple protobuf types (except `bytes`, `enum`, `float`, `double`) as well as `Timestamp` and `Duration` +* unsorted `bytes` and `enum` indexes +* composite primary and secondary keys +* unique indexes +* auto-incrementing `uint64` primary keys +* complex prefix and range queries +* paginated queries +* complete logical decoding of KV-store data + +Almost all the information needed to decode state directly is specified in .proto files. Each table definition specifies +an ID which is unique per .proto file and each index within a table is unique within that table. Clients then only need +to know the name of a module and the prefix ORM data for a specific .proto file within that module in order to decode +state data directly. This additional information will be exposed directly through app configs which will be explained +in a future ADR related to app wiring. + +The ORM makes optimizations around storage space by not repeating values in the primary key in the key value +when storing primary key records. For example, if the object `{"a":0,"b":1}` has the primary key `a`, it will +be stored in the key value store as `Key: '0', Value: {"b":1}` (with more efficient protobuf binary encoding). +Also, the generated code from https://github.com/cosmos/cosmos-proto does optimizations around the +`google.golang.org/protobuf/reflect/protoreflect` API to improve performance. + +A code generator is included with the ORM which creates type safe wrappers around the ORM's dynamic `Table` +implementation and is the recommended way for modules to use the ORM. + +The ORM tests provide a simplified bank module demonstration which illustrates: +- [ORM proto options](https://github.com/cosmos/cosmos-sdk/blob/0d846ae2f0424b2eb640f6679a703b52d407813d/orm/internal/testpb/bank.proto) +- [Generated Code](https://github.com/cosmos/cosmos-sdk/blob/0d846ae2f0424b2eb640f6679a703b52d407813d/orm/internal/testpb/bank.cosmos_orm.go) +- [Example Usage in a Module Keeper](https://github.com/cosmos/cosmos-sdk/blob/0d846ae2f0424b2eb640f6679a703b52d407813d/orm/model/ormdb/module_test.go) + +## Consequences + +### Backwards Compatibility + +State machine code that adopts the ORM will need migrations as the state layout is generally backwards incompatible. +These state machines will also need to migrate to https://github.com/cosmos/cosmos-proto at least for state data. + +### Positive + +* easier to build modules +* easier to add secondary indexes to state +* possible to write a generic indexer for ORM state +* easier to write clients that do state proofs +* possible to automatically write query layers rather than needing to manually implement gRPC queries + +### Negative + +* worse performance than handwritten keys (for now). See [Further Discussions](#further-discussions) +for potential improvements + +### Neutral + +## Further Discussions + +Further discussions will happen within the Cosmos SDK Framework Working Group. Current planned and ongoing work includes: +* automatically generate client-facing query layer +* client-side query libraries that transparently verify light client proofs +* index ORM data to SQL databases +* improve performance by: + * optimizing existing reflection based code to avoid unnecessary gets when doing deletes & updates of simple tables + * more sophisticated code generation such as making fast path reflection even faster (avoiding `switch` statements), + or even fully generating code that equals handwritten performance + + +## References + +* https://github.com/iov-one/weave/tree/master/orm). +* https://github.com/regen-network/regen-ledger/tree/157181f955823149e1825263a317ad8e16096da4/orm +* https://github.com/cosmos/cosmos-sdk/tree/35d3312c3be306591fcba39892223f1244c8d108/x/group/internal/orm +* https://github.com/cosmos/cosmos-sdk/discussions/9156 +* https://github.com/allinbits/cosmos-sdk-poc/tree/master/runtime/orm +* https://github.com/cosmos/cosmos-sdk/pull/10454 \ No newline at end of file diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-057-app-wiring.md b/versioned_docs/version-0.47/integrate/architecture/adr-057-app-wiring.md new file mode 100644 index 000000000..341aec9f0 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-057-app-wiring.md @@ -0,0 +1,331 @@ +# ADR 057: App Wiring + +## Changelog + +* 2022-05-04: Initial Draft +* 2022-08-19: Updates + +## Status + +PROPOSED Implemented + +## Abstract + +In order to make it easier to build Cosmos SDK modules and apps, we propose a new app wiring system based on +dependency injection and declarative app configurations to replace the current `app.go` code. + +## Context + +A number of factors have made the SDK and SDK apps in their current state hard to maintain. A symptom of the current +state of complexity is [`simapp/app.go`](https://github.com/cosmos/cosmos-sdk/blob/c3edbb22cab8678c35e21fe0253919996b780c01/simapp/app.go) +which contains almost 100 lines of imports and is otherwise over 600 lines of mostly boilerplate code that is +generally copied to each new project. (Not to mention the additional boilerplate which gets copied in `simapp/simd`.) + +The large amount of boilerplate needed to bootstrap an app has made it hard to release independently versioned go +modules for Cosmos SDK modules as described in [ADR 053: Go Module Refactoring](./adr-053-go-module-refactoring.md). + +In addition to being very verbose and repetitive, `app.go` also exposes a large surface area for breaking changes +as most modules instantiate themselves with positional parameters which forces breaking changes anytime a new parameter +(even an optional one) is needed. + +Several attempts were made to improve the current situation including [ADR 033: Internal-Module Communication](./adr-033-protobuf-inter-module-comm.md) +and [a proof-of-concept of a new SDK](https://github.com/allinbits/cosmos-sdk-poc). The discussions around these +designs led to the current solution described here. + +## Decision + +In order to improve the current situation, a new "app wiring" paradigm has been designed to replace `app.go` which +involves: + +* declaration configuration of the modules in an app which can be serialized to JSON or YAML +* a dependency-injection (DI) framework for instantiating apps from the that configuration + +### Dependency Injection + +When examining the code in `app.go` most of the code simply instantiates modules with dependencies provided either +by the framework (such as store keys) or by other modules (such as keepers). It is generally pretty obvious given +the context what the correct dependencies actually should be, so dependency-injection is an obvious solution. Rather +than making developers manually resolve dependencies, a module will tell the DI container what dependency it needs +and the container will figure out how to provide it. + +We explored several existing DI solutions in golang and felt that the reflection-based approach in [uber/dig](https://github.com/uber-go/dig) +was closest to what we needed but not quite there. Assessing what we needed for the SDK, we designed and built +the Cosmos SDK [depinject module](https://pkg.go.dev/github.com/cosmos/cosmos-sdk/depinject), which has the following +features: + +* dependency resolution and provision through functional constructors, ex: `func(need SomeDep) (AnotherDep, error)` +* dependency injection `In` and `Out` structs which support `optional` dependencies +* grouped-dependencies (many-per-container) through the `ManyPerContainerType` tag interface +* module-scoped dependencies via `ModuleKey`s (where each module gets a unique dependency) +* one-per-module dependencies through the `OnePerModuleType` tag interface +* sophisticated debugging information and container visualization via GraphViz + +Here are some examples of how these would be used in an SDK module: + +* `StoreKey` could be a module-scoped dependency which is unique per module +* a module's `AppModule` instance (or the equivalent) could be a `OnePerModuleType` +* CLI commands could be provided with `ManyPerContainerType`s + +Note that even though dependency resolution is dynamic and based on reflection, which could be considered a pitfall +of this approach, the entire dependency graph should be resolved immediately on app startup and only gets resolved +once (except in the case of dynamic config reloading which is a separate topic). This means that if there are any +errors in the dependency graph, they will get reported immediately on startup so this approach is only slightly worse +than fully static resolution in terms of error reporting and much better in terms of code complexity. + +### Declarative App Config + +In order to compose modules into an app, a declarative app configuration will be used. This configuration is based off +of protobuf and its basic structure is very simple: + +```protobuf +package cosmos.app.v1; + +message Config { + repeated ModuleConfig modules = 1; +} + +message ModuleConfig { + string name = 1; + google.protobuf.Any config = 2; +} +``` + +(See also https://github.com/cosmos/cosmos-sdk/blob/6e18f582bf69e3926a1e22a6de3c35ea327aadce/proto/cosmos/app/v1alpha1/config.proto) + +The configuration for every module is itself a protobuf message and modules will be identified and loaded based +on the protobuf type URL of their config object (ex. `cosmos.bank.module.v1.Module`). Modules are given a unique short `name` +to share resources across different versions of the same module which might have a different protobuf package +versions (ex. `cosmos.bank.module.v2.Module`). All module config objects should define the `cosmos.app.v1alpha1.module` +descriptor option which will provide additional useful metadata for the framework and which can also be indexed +in module registries. + +An example app config in YAML might look like this: + +```yaml +modules: + - name: baseapp + config: + "@type": cosmos.baseapp.module.v1.Module + begin_blockers: [staking, auth, bank] + end_blockers: [bank, auth, staking] + init_genesis: [bank, auth, staking] + - name: auth + config: + "@type": cosmos.auth.module.v1.Module + bech32_prefix: "foo" + - name: bank + config: + "@type": cosmos.bank.module.v1.Module + - name: staking + config: + "@type": cosmos.staking.module.v1.Module +``` + +In the above example, there is a hypothetical `baseapp` module which contains the information around ordering of +begin blockers, end blockers, and init genesis. Rather than lifting these concerns up to the module config layer, +they are themselves handled by a module which could allow a convenient way of swapping out different versions of +baseapp (for instance to target different versions of tendermint), without needing to change the rest of the config. +The `baseapp` module would then provide to the server framework (which sort of sits outside the ABCI app) an instance +of `abci.Application`. + +In this model, an app is *modules all the way down* and the dependency injection/app config layer is very much +protocol-agnostic and can adapt to even major breaking changes at the protocol layer. + +### Module & Protobuf Registration + +In order for the two components of dependency injection and declarative configuration to work together as described, +we need a way for modules to actually register themselves and provide dependencies to the container. + +One additional complexity that needs to be handled at this layer is protobuf registry initialization. Recall that +in both the current SDK `codec` and the proposed [ADR 054: Protobuf Semver Compatible Codegen](https://github.com/cosmos/cosmos-sdk/pull/11802), +protobuf types need to be explicitly registered. Given that the app config itself is based on protobuf and +uses protobuf `Any` types, protobuf registration needs to happen before the app config itself can be decoded. Because +we don't know which protobuf `Any` types will be needed a priori and modules themselves define those types, we need +to decode the app config in separate phases: + +1. parse app config JSON/YAML as raw JSON and collect required module type URLs (without doing proto JSON decoding) +2. build a [protobuf type registry](https://pkg.go.dev/google.golang.org/protobuf@v1.28.0/reflect/protoregistry) based + on file descriptors and types provided by each required module +3. decode the app config as proto JSON using the protobuf type registry + +Because in [ADR 054: Protobuf Semver Compatible Codegen](https://github.com/cosmos/cosmos-sdk/pull/11802), each module +should use `internal` generated code which is not registered with the global protobuf registry, this code should provide +an alternate way to register protobuf types with a type registry. In the same way that `.pb.go` files currently have a +`var File_foo_proto protoreflect.FileDescriptor` for the file `foo.proto`, generated code should have a new member +`var Types_foo_proto TypeInfo` where `TypeInfo` is an interface or struct with all the necessary info to register both +the protobuf generated types and file descriptor. + +So a module must provide dependency injection providers and protobuf types, and takes as input its module +config object which uniquely identifies the module based on its type URL. + +With this in mind, we define a global module register which allows module implementations to register themselves +with the following API: + +```go +// Register registers a module with the provided type name (ex. cosmos.bank.module.v1.Module) +// and the provided options. +func Register(configTypeName protoreflect.FullName, option ...Option) { ... } + +type Option { /* private methods */ } + +// Provide registers dependency injection provider functions which work with the +// cosmos-sdk container module. These functions can also accept an additional +// parameter for the module's config object. +func Provide(providers ...interface{}) Option { ... } + +// Types registers protobuf TypeInfo's with the protobuf registry. +func Types(types ...TypeInfo) Option { ... } +``` + +Ex: + +```go +func init() { + appmodule.Register("cosmos.bank.module.v1.Module", + appmodule.Types( + types.Types_tx_proto, + types.Types_query_proto, + types.Types_types_proto, + ), + appmodule.Provide( + provideBankModule, + ) + ) +} + +type Inputs struct { + container.In + + AuthKeeper auth.Keeper + DB ormdb.ModuleDB +} + +type Outputs struct { + Keeper bank.Keeper + AppModule appmodule.AppModule +} + +func ProvideBankModule(config *bankmodulev1.Module, Inputs) (Outputs, error) { ... } +``` + +Note that in this module, a module configuration object *cannot* register different dependency providers at runtime +based on the configuration. This is intentional because it allows us to know globally which modules provide which +dependencies, and it will also allow us to do code generation of the whole app initialization. This +can help us figure out issues with missing dependencies in an app config if the needed modules are loaded at runtime. +In cases where required modules are not loaded at runtime, it may be possible to guide users to the correct module if +through a global Cosmos SDK module registry. + +### New `app.go` + +With this setup, `app.go` might now look something like this: + +```go +package main + +import ( + // Each go package which registers a module must be imported just for side-effects + // so that module implementations are registered. + _ "github.com/cosmos/cosmos-sdk/x/auth/module" + _ "github.com/cosmos/cosmos-sdk/x/bank/module" + _ "github.com/cosmos/cosmos-sdk/x/staking/module" + "github.com/cosmos/cosmos-sdk/core/app" +) + +// go:embed app.yaml +var appConfigYAML []byte + +func main() { + app.Run(app.LoadYAML(appConfigYAML)) +} +``` + +### Application to existing SDK modules + +So far we have described a system which is largely agnostic to the specifics of the SDK such as store keys, `AppModule`, +`BaseApp`, etc. A second app wiring ADR will be created which outlines the details of how this app wiring system will +be applied to the existing SDK in a way that: + +### Registration of Inter-Module Hooks + +Some modules define a hooks interface (ex. `StakingHooks`) which allows one module to call back into another module +when certain events happen. + +With the app wiring framework, these hooks interfaces can be defined as a `OnePerModuleType`s and then the module +which consumes these hooks can collect these hooks as a map of module name to hook type (ex. `map[string]FooHooks`). Ex: +```go +func init() { + appmodule.Register( + &foomodulev1.Module{}, + appmodule.Invoke(InvokeSetFooHooks), + ... + ) +} +func InvokeSetFooHooks( + keeper *keeper.Keeper, + fooHooks map[string]FooHooks, +) error { + for k in sort.Strings(maps.Keys(fooHooks)) { + keeper.AddFooHooks(fooHooks[k]) + } +} +``` + +Optionally, the module consuming hooks can allow app's to define an order for calling these hooks based on module name +in its config object. + +An alternative way for registering hooks via reflection was considered where all keeper types are inspected to see if +they implement the hook interface by the modules exposing hooks. This has the downsides of: +* needing to expose all the keepers of all modules to the module providing hooks, +* not allowing for encapsulating hooks on a different type which doesn't expose all keeper methods, +* harder to know statically which module expose hooks or are checking for them. + +With the approach proposed here, hooks registration will be obviously observable in `app.go` if `depinject` codegen +(described below) is used. + +### Code Generation + +The `depinject` framework will optionally allow the app configuration and dependency injection wiring to be code +generated. This will allow: +* dependency injection wiring to be inspected as regular go code just like the existing `app.go`, +* dependency injection to be opt-in with manual wiring 100% still possible. + +Code generation requires that all providers and invokers and their parameters are exported and in non-internal packages. + +## Consequences + +### Backwards Compatibility + +Modules which work with the new app wiring system do not need to drop their existing `AppModule` and `NewKeeper` +registration paradigms. These two methods can live side-by-side for as long as is needed. + +### Positive + +* wiring up new apps will be simpler, more succinct and less error-prone +* it will be easier to develop and test standalone SDK modules without needing to replicate all of simapp +* it may be possible to dynamically load modules and upgrade chains without needing to do a coordinated stop and binary + upgrade using this mechanism +* easier plugin integration +* dependency injection framework provides more automated reasoning about dependencies in the project, with a graph visualization. + +### Negative + +* it may be confusing when a dependency is missing although error messages, the GraphViz visualization, and global + module registration may help with that + +### Neutral + +* it will require work and education + +## Further Discussions + +The protobuf type registration system described in this ADR has not been implemented and may need to be reconsidered in +light of code generation. It may be better to do this type registration with a DI provider. + +## References + +* https://github.com/cosmos/cosmos-sdk/blob/c3edbb22cab8678c35e21fe0253919996b780c01/simapp/app.go +* https://github.com/allinbits/cosmos-sdk-poc +* https://github.com/uber-go/dig +* https://github.com/google/wire +* https://pkg.go.dev/github.com/cosmos/cosmos-sdk/container +* https://github.com/cosmos/cosmos-sdk/pull/11802 diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-058-auto-generated-cli.md b/versioned_docs/version-0.47/integrate/architecture/adr-058-auto-generated-cli.md new file mode 100644 index 000000000..1301466e1 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-058-auto-generated-cli.md @@ -0,0 +1,95 @@ +# ADR 058: Auto-Generated CLI + +## Changelog + +* 2022-05-04: Initial Draft + +## Status + +ACCEPTED Partially Implemented + +## Abstract + +In order to make it easier for developers to write Cosmos SDK modules, we provide infrastructure which automatically +generates CLI commands based on protobuf definitions. + +## Context + +Current Cosmos SDK modules generally implement a CLI command for every transaction and every query supported by the +module. These are handwritten for each command and essentially amount to providing some CLI flags or positional +arguments for specific fields in protobuf messages. + +In order to make sure CLI commands are correctly implemented as well as to make sure that the application works +in end-to-end scenarios, we do integration tests using CLI commands. While these tests are valuable on some-level, +they can be hard to write and maintain, and run slowly. [Some teams have contemplated](https://github.com/regen-network/regen-ledger/issues/1041) +moving away from CLI-style integration tests (which are really end-to-end tests) towards narrower integration tests +which exercise `MsgClient` and `QueryClient` directly. This might involve replacing the current end-to-end CLI +tests with unit tests as there still needs to be some way to test these CLI commands for full quality assurance. + +## Decision + +To make module development simpler, we provide infrastructure - in the new [`client/v2`](https://github.com/cosmos/cosmos-sdk/tree/main/client/v2) +go module - for automatically generating CLI commands based on protobuf definitions to either replace or complement +handwritten CLI commands. This will mean that when developing a module, it will be possible to skip both writing and +testing CLI commands as that can all be taken care of by the framework. + +The basic design for automatically generating CLI commands is to: + +* create one CLI command for each `rpc` method in a protobuf `Query` or `Msg` service +* create a CLI flag for each field in the `rpc` request type +* for `query` commands call gRPC and print the response as protobuf JSON or YAML (via the `-o`/`--output` flag) +* for `tx` commands, create a transaction and apply common transaction flags + +In order to make the auto-generated CLI as easy to use (or easier) than handwritten CLI, we need to do custom handling +of specific protobuf field types so that the input format is easy for humans: +* `Coin`, `Coins`, `DecCoin`, and `DecCoins` should be input using the existing format (i.e. `1000uatom`) +* it should be possible to specify an address using either the bech32 address string or a named key in the keyring +* `Timestamp` and `Duration` should accept strings like `2001-01-01T00:00:00Z` and `1h3m` respectively +* pagination should be handled with flags like `--page-limit`, `--page-offset`, etc. +* it should be possible to customize any other protobuf type either via its message name or a `cosmos_proto.scalar` annotation + +At a basic level it should be possible to generate a command for a single `rpc` method as well as all the commands for +a whole protobuf `service` definition. It should be possible to mix and match auto-generated and handwritten commands. + +## Consequences + +### Backwards Compatibility + +Existing modules can mix and match auto-generated and handwritten CLI commands so it is up to them as to whether they +make breaking changes by replacing handwritten commands with slightly different auto-generated ones. + +For now the SDK will maintain the existing set of CLI commands for backwards compatibility but new commands will use +this functionality. + +### Positive + +* module developers will not need to write CLI commands +* module developers will not need to test CLI commands +* [lens](https://github.com/strangelove-ventures/lens) may benefit from this + +### Negative + +### Neutral + +## Further Discussions + +We would like to be able to customize: +* short and long usage strings for commands +* aliases for flags (ex. `-a` for `--amount`) +* which fields are positional parameters rather than flags + +It is an [open discussion](https://github.com/cosmos/cosmos-sdk/pull/11725#issuecomment-1108676129) +as to whether these customizations options should line in: +* the .proto files themselves, +* separate config files (ex. YAML), or +* directly in code + +Providing the options in .proto files would allow a dynamic client to automatically generate +CLI commands on the fly. However, that may pollute the .proto files themselves with information that is only relevant +for a small subset of users. + +## References + +* https://github.com/regen-network/regen-ledger/issues/1041 +* https://github.com/cosmos/cosmos-sdk/tree/main/client/v2 +* https://github.com/cosmos/cosmos-sdk/pull/11725#issuecomment-1108676129 diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-059-test-scopes.md b/versioned_docs/version-0.47/integrate/architecture/adr-059-test-scopes.md new file mode 100644 index 000000000..51f06621c --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-059-test-scopes.md @@ -0,0 +1,253 @@ +# ADR 059: Test Scopes + +## Changelog + +* 2022-08-02: Initial Draft + +## Status + +PROPOSED Partially Implemented + +## Abstract + +Recent work in the SDK aimed at breaking apart the monolithic root go module has highlighted +shortcomings and inconsistencies in our testing paradigm. This ADR clarifies a common +language for talking about test scopes and proposes an ideal state of tests at each scope. + +## Context + +[ADR-053: Go Module Refactoring](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-053-go-module-refactoring.md) expresses our desire for an SDK composed of many +independently versioned Go modules, and [ADR-057: App Wiring](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-057-app-wiring.md) offers a methodology +for breaking apart inter-module dependencies through the use of dependency injection. As +described in [EPIC: Separate all SDK modules into standalone go modules](https://github.com/cosmos/cosmos-sdk/issues/11899), module +dependencies are particularly complected in the test phase, where simapp is used as +the key test fixture in setting up and running tests. It is clear that the successful +completion of Phases 3 and 4 in that EPIC require the resolution of this dependency problem. + +In [EPIC: Unit Testing of Modules via Mocks](https://github.com/cosmos/cosmos-sdk/issues/12398) it was thought this Gordian knot could be +unwound by mocking all dependencies in the test phase for each module, but seeing how these +refactors were complete rewrites of test suites discussions began around the fate of the +existing integration tests. One perspective is that they ought to be thrown out, another is +that integration tests have some utility of their own and a place in the SDK's testing story. + +Another point of confusion has been the current state of CLI test suites, [x/auth](https://github.com/cosmos/cosmos-sdk/blob/0f7e56c6f9102cda0ca9aba5b6f091dbca976b5a/x/auth/client/testutil/suite.go#L44-L49) for +example. In code these are called integration tests, but in reality function as end to end +tests by starting up a tendermint node and full application. [EPIC: Rewrite and simplify +CLI tests](https://github.com/cosmos/cosmos-sdk/issues/12696) identifies the ideal state of CLI tests using mocks, but does not address the +place end to end tests may have in the SDK. + +From here we identify three scopes of testing, **unit**, **integration**, **e2e** (end to +end), seek to define the boundaries of each, their shortcomings (real and imposed), and their +ideal state in the SDK. + +### Unit tests + +Unit tests exercise the code contained in a single module (e.g. `/x/bank`) or package +(e.g. `/client`) in isolation from the rest of the code base. Within this we identify two +levels of unit tests, *illustrative* and *journey*. The definitions below lean heavily on +[The BDD Books - Formulation](https://leanpub.com/bddbooks-formulation) section 1.3. + +*Illustrative* tests exercise an atomic part of a module in isolation - in this case we +might do fixture setup/mocking of other parts of the module. + +Tests which exercise a whole module's function with dependencies mocked, are *journeys*. +These are almost like integration tests in that they exercise many things together but still +use mocks. + +Example 1 journey vs illustrative tests - [depinject's BDD style tests](https://github.com/cosmos/cosmos-sdk/blob/main/depinject/features/bindings.feature), show how we can +rapidly build up many illustrative cases demonstrating behavioral rules without [very much +code](https://github.com/cosmos/cosmos-sdk/blob/main/depinject/binding_test.go) while maintaining high level readability. + +Example 2 [depinject table driven tests](https://github.com/cosmos/cosmos-sdk/blob/main/depinject/provider_desc_test.go) + +Example 3 [Bank keeper tests](https://github.com/cosmos/cosmos-sdk/blob/2bec9d2021918650d3938c3ab242f84289daef80/x/bank/keeper/keeper_test.go#L94-L105) - A mock implementation of `AccountKeeper` is +supplied to the keeper constructor. + +#### Limitations + +Certain modules are tightly coupled beyond the test phase. A recent dependency report for +`bank -> auth` found 274 total usages of `auth` in `bank`, 50 of which are in +production code and 224 in test. This tight coupling may suggest that either the modules +should be merged, or refactoring is required to abstract references to the core types tying +the modules together. It could also indicate that these modules should be tested together +in integration tests beyond mocked unit tests. + +In some cases setting up a test case for a module with many mocked dependencies can be quite +cumbersome and the resulting test may only show that the mocking framework works as expected +rather than working as a functional test of interdependent module behavior. + +### Integration tests + +Integration tests define and exercise relationships between an arbitrary number of modules +and/or application subsystems. + +Wiring for integration tests is provided by `depinject` and some [helper code](https://github.com/cosmos/cosmos-sdk/blob/2bec9d2021918650d3938c3ab242f84289daef80/testutil/sims/app_helpers.go#L95) starts up +a running application. A section of the running application may then be tested. Certain +inputs during different phases of the application life cycle are expected to produce +invariant outputs without too much concern for component internals. This type of black box +testing has a larger scope than unit testing. + +Example 1 [client/grpc_query_test/TestGRPCQuery](https://github.com/cosmos/cosmos-sdk/blob/2bec9d2021918650d3938c3ab242f84289daef80/client/grpc_query_test.go#L111-L129) - This test is misplaced in `/client`, +but tests the life cycle of (at least) `runtime` and `bank` as they progress through +startup, genesis and query time. It also exercises the fitness of the client and query +server without putting bytes on the wire through the use of [QueryServiceTestHelper](https://github.com/cosmos/cosmos-sdk/blob/2bec9d2021918650d3938c3ab242f84289daef80/baseapp/grpcrouter_helpers.go#L31). + +Example 2 `x/evidence` Keeper integration tests - Starts up an application composed of [8 +modules](https://github.com/cosmos/cosmos-sdk/blob/2bec9d2021918650d3938c3ab242f84289daef80/x/evidence/testutil/app.yaml#L1) with [5 keepers](https://github.com/cosmos/cosmos-sdk/blob/2bec9d2021918650d3938c3ab242f84289daef80/x/evidence/keeper/keeper_test.go#L101-L106) used in the integration test suite. One test in the suite +exercises [HandleEquivocationEvidence](https://github.com/cosmos/cosmos-sdk/blob/2bec9d2021918650d3938c3ab242f84289daef80/x/evidence/keeper/infraction_test.go#L42) which contains many interactions with the staking +keeper. + +Example 3 - Integration suite app configurations may also be specified via golang (not +YAML as above) [statically](https://github.com/cosmos/cosmos-sdk/blob/main/x/nft/testutil/app_config.go) or [dynamically](https://github.com/cosmos/cosmos-sdk/blob/8c23f6f957d1c0bedd314806d1ac65bea59b084c/tests/integration/bank/keeper/keeper_test.go#L129-L134). + +#### Limitations + +Setting up a particular input state may be more challenging since the application is +starting from a zero state. Some of this may be addressed by good test fixture +abstractions with testing of their own. Tests may also be more brittle, and larger +refactors could impact application initialization in unexpected ways with harder to +understand errors. This could also be seen as a benefit, and indeed the SDK's current +integration tests were helpful in tracking down logic errors during earlier stages +of app-wiring refactors. + +### Simulations + +Simulations (also called generative testing) are a special case of integration tests where +deterministically random module operations are executed against a running simapp, building +blocks on the chain until a specified height is reached. No *specific* assertions are +made for the state transitions resulting from module operations but any error will halt and +fail the simulation. Since `crisis` is included in simapp and the simulation runs +EndBlockers at the end of each block any module invariant violations will also fail +the simulation. + +Modules must implement [AppModuleSimulation.WeightedOperations](https://github.com/cosmos/cosmos-sdk/blob/2bec9d2021918650d3938c3ab242f84289daef80/types/module/simulation.go#L31) to define their +simulation operations. Note that not all modules implement this which may indicate a +gap in current simulation test coverage. + +Modules not returning simulation operations: + +* `auth` +* `capability` +* `evidence` +* `mint` +* `params` + +A separate binary, [runsim](https://github.com/cosmos/tools/tree/master/cmd/runsim), is responsible for kicking off some of these tests and +managing their life cycle. + +#### Limitations + +* [A success](https://github.com/cosmos/cosmos-sdk/runs/7606931983?check_suite_focus=true) may take a long time to run, 7-10 minutes per simulation in CI. +* [Timeouts](https://github.com/cosmos/cosmos-sdk/runs/7606932295?check_suite_focus=true) sometimes occur on apparent successes without any indication why. +* Useful error messages not provided on [failure](https://github.com/cosmos/cosmos-sdk/runs/7606932548?check_suite_focus=true) from CI, requiring a developer to run + the simulation locally to reproduce. + +### E2E tests + +End to end tests exercise the entire system as we understand it in as close an approximation +to a production environment as is practical. Presently these tests are located at +[tests/e2e](https://github.com/cosmos/cosmos-sdk/tree/main/tests/e2e) and rely on [testutil/network](https://github.com/cosmos/cosmos-sdk/tree/main/testutil/network) to start up an in-process Tendermint node. + +#### Limitations + +In general the limitations of end to end tests are orchestration and compute cost. +Scaffolding is required to start up and run a prod-like environment and the this +process takes much longer to start and run than unit or integration tests. + +Global locks present in Tendermint code cause stateful starting/stopping to sometimes hang +or fail intermittently when run in a CI environment. + +The scope of e2e tests has been complected with command line interface testing. + +## Decision + +We accept these test scopes and identify the following decisions points for each. + +| Scope | App Fixture | Mocks? | +| ----------- | ----------- | ------ | +| Unit | None | Yes | +| Integration | depinject | Some | +| Simulation | depinject | No | +| E2E | simapp | No | + +### Unit Tests + +All modules must have mocked unit test coverage. + +Illustrative tests should outnumber journeys in unit tests. + +~BDD feature tests are recommended when building up illustrative and journey scenarios.~ + +Unit tests should outnumber integration tests. + +Unit tests must not introduce additional dependencies beyond those already present in +production code. + +When module unit test introduction as per [EPIC: Unit testing of modules via mocks](https://github.com/cosmos/cosmos-sdk/issues/12398) +results in a near complete rewrite of an integration test suite the test suite should be +retained and moved to `/tests/integration`. We accept the resulting test logic +duplication but recommend improving the unit test suite through the addition of +illustrative tests. + +### Integration Tests + +All integration tests shall be located in `/tests/integration`, even those which do not +introduce extra module dependencies. + +To help limit scope and complexity, it is recommended to use the smallest possible number of +modules in application startup, i.e. don't depend on simapp. + +Integration tests should outnumber e2e tests. + +### Simulations + +Simulations shall use `depinject`. They are located under `/x/{moduleName}/simulation`. + +### E2E Tests + +Existing e2e tests shall be migrated to integration tests by removing the dependency on the +test network and in-process Tendermint node to ensure we do not lose test coverage. + +The e2e rest runner shall transition from in process Tendermint to a runner powered by +Docker via [dockertest](https://github.com/ory/dockertest). + +E2E tests exercising a full network upgrade shall be written. + +The CLI testing aspect of existing e2e tests shall be rewritten using the network mocking +demonstrated in [PR#12706](https://github.com/cosmos/cosmos-sdk/pull/12706). + +## Consequences + +### Positive + +* test coverage is increased +* test organization is improved +* reduced dependency graph size in modules +* simapp removed as a dependency from modules +* inter-module dependencies introduced in test code are removed +* reduced CI run time after transitioning away from in process Tendermint + +### Negative + +* some test logic duplication between unit and integration tests during transition +* test written using dockertest DX may be a bit worse + +### Neutral + +* learning curve for BDD style tests +* some discovery required for e2e transition to dockertest + +## Further Discussions + +It may be useful if test suites could be run in integration mode (with mocked tendermint) or +with e2e fixtures (with real tendermint and many nodes). Integration fixtures could be used +for quicker runs, e2e fixures could be used for more battle hardening. + +A PoC `x/gov` was completed in PR [#12847](https://github.com/cosmos/cosmos-sdk/pull/12847) +is in progress for unit tests demonstrating BDD [Rejected]. +Observing that a strength of BDD specifications is their readability, and a con is the +cognitive load while writing and maintaining, current consensus is to reserve BDD use +for places in the SDK where complex rules and module interactions are demonstrated. +More straightforward or low level test cases will continue to rely on go table tests. + +Levels are network mocking in integration and e2e tests are still being worked on and formalized. diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-060-abci-1.0.md b/versioned_docs/version-0.47/integrate/architecture/adr-060-abci-1.0.md new file mode 100644 index 000000000..d988f7d50 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-060-abci-1.0.md @@ -0,0 +1,249 @@ +# ADR 60: ABCI 1.0 Integration + +## Changelog + +* 2022-08-10: Initial Draft (@alexanderbez, @tac0turtle) + +## Status + +PROPOSED + +## Abstract + +This ADR describes the initial adoption of [ABCI 1.0](https://github.com/tendermint/tendermint/blob/master/spec/abci%2B%2B/README.md), +the next evolution of ABCI, within the Cosmos SDK. ABCI 1.0 aims to provide +application developers with more flexibility and control over application and +consensus semantics, e.g. in-application mempools, in-process oracles, and +order-book style matching engines. + +## Context + +Tendermint will release ABCI 1.0. Notably, at the time of this writing, +Tendermint is releasing v0.37.0 which will include `PrepareProposal` and `ProcessProposal`. + +The `PrepareProposal` ABCI method is concerned with a block proposer requesting +the application to evaluate a series of transactions to be included in the next +block, defined as a slice of `TxRecord` objects. The application can either +accept, reject, or completely ignore some or all of these transactions. This is +an important consideration to make as the application can essentially define and +control its own mempool allowing it to define sophisticated transaction priority +and filtering mechanisms, by completely ignoring the `TxRecords` Tendermint +sends it, favoring its own transactions. This essentially means that the Tendermint +mempool acts more like a gossip data structure. + +The second ABCI method, `ProcessProposal`, is used to process the block proposer's +proposal as defined by `PrepareProposal`. This ABCI method requests that the +application evaluate the entire proposed block for validity. + +It is important to note that in ABCI 1.0 integration, the application +is NOT responsible for locking semantics -- Tendermint will still be responsible +for that. In the future, however, the application will be responsible for locking, +which allows for parallel execution possibilities. + +## Decision + +We will integrate ABCI 1.0, which will be introduced in Tendermint +v0.37.0, in the next major release of the Cosmos SDK. We will integrate ABCI 1.0 +methods on the `BaseApp` type. We describe the implementations +of the two methods individually below. + +Prior to describing the implementation of the two new methods, it is important to +note that the existing ABCI methods, `CheckTx`, `DeliverTx`, etc, still exist and +serve the same functions as they do now. + +### `PrepareProposal` + +Prior to evaluating the decision for how to implement `PrepareProposal`, it is +important to note that `CheckTx` will still be executed and will be responsible +for evaluating transaction validity as it does now, with one very important +_additive_ distinction. + +When executing transactions in `CheckTx`, the application will now add valid +transactions, i.e. passing the AnteHandler, to its own mempool data structure. +In order to provide a flexible approach to meet the varying needs of application +developers, we will define both a mempool interface and a data structure utilizing +Golang generics, allowing developers to focus only on transaction +ordering. Developers requiring absolute full control can implement their own +custom mempool implementation. + +We define the general mempool interface as follows (subject to change): + +```go +// MempoolTx we define an app-side mempool transaction interface that is as +// minimal as possible, only requiring applications to define the size of the +// transaction to be used when reaping and getting the transaction itself. +// Interface type casting can be used in the actual app-side mempool implementation. +type MempoolTx interface { + // Size returns the size of the transaction in bytes. + Size(codec.Codec) int + Tx() sdk.Tx +} + +// PrepareTxRecord defines a wrapper around a MempoolTx that is returned from +// PrepareProposal which includes an Action to inform Tendermint what to do with +// the transaction. +type PrepareTxRecord[T MempoolTx] struct { + Tx T + Action abci.TxAction +} + +type Mempool[T MempoolTx] interface { + // Insert attempts to insert a MempoolTx into the app-side mempool returning + // an error upon failure. + Insert(sdk.Context, T) error + // ReapMaxBytes returns the next set of available transactions from the app-side + // mempool, up to maxBytes or until the mempool is empty. The application can + // decide to return transactions from its own mempool or from the incoming + // TxRecords or some combination of both. The notion of 'available' or 'next' + // is defined by the application's mempool implementation. + ReapMaxBytes(ctx sdk.Context, txRecords abci.TxRecords, maxBytes int) ([]PrepareTxRecord[T], error) + // NumTxs returns the number of transactions currently in the mempool. + NumTxs() int + // Remove attempts to remove a transaction from the mempool, returning an error + // upon failure. + Remove(sdk.Context, T) error +} +``` + +We will define an implementation of `Mempool[T MempoolTx]` that will cover a +majority of application use cases. Namely, it will prioritize transactions by +priority and transaction sender, allowing for multiple prioritized transactions +from the same sender. The app-side mempool will be defined as a wrapper around a +simple priority queue using a max binary heap, along with additional indexes/metadata +to store senders and their nonces, allowing for simple multi-dimensional +prioritization (2-ary). + +Transaction reaping will essentially happen via a two-phase approach: + +1. Reap one or more transactions from the priority queue and collect them into + one of two buffers -- _valid_ and _invalid_. +2. For transactions that DO NOT violate the nonce validation, they are included + in the _valid_ buffer. +3. For transactions that DO violate the nonce validation, they are included in + the _invalid_ buffer. +4. Continue this process until the desired number of valid transactions are + reaped or until the mempool is empty. +5. Provide Tendermint the list of all transactions from the _valid_ buffer. +6. Re-insert all transactions, from both buffers, back into app-side mempool. + This is to ensure we do not discard transactions from the app-side mempool in + case `ProcessProposal` fails or in case that the proposal, while passing + `ProcessProposal` is not the one decided for that height, i.e. the height took + more than one round. + +```go +type PriorityMempool[T MempoolTx] struct { + queue *PriorityQueue[MempoolTx] + + // senders will contain a mapping from tx sender account addresses to all + // sequence numbers (nonces) or txs that they have in the app-side mempool. + senders map[string][]int64 + + // ... +} +``` + +> The `PriorityMempool[T MempoolTx]` implementation will support Options such as +> limiting the mempool size by a fixed number of bytes. + +Previous discussions1 have come to the agreement that Tendermint will +perform a request to the application, via `RequestPrepareProposal`, with a certain +amount of transactions reaped from Tendermint's local mempool. The exact amount +of transactions reaped will be determined by a local operator configuration. +This is referred to as the "one-shot approach" seen in discussions. + +When Tendermint reaps transactions from the local mempool and sends them to the +application via `RequestPrepareProposal`, the application will have to evaluate +the transactions. Specifically, it will need to inform Tendermint if it should +reject and or include each transaction. Note, the application can even _replace_ +transactions entirely with other transactions. + +When evaluating transactions from `RequestPrepareProposal`, the application will +ignore _all_ transactions sent to it in the request and instead reap up to +`RequestPrepareProposal.max_tx_bytes` from it's own mempool. There is no need to +execute the transactions for validity as they have already passed CheckTx. + +### `ProcessProposal` + +The `ProcessProposal` ABCI method is relatively straightforward. It is responsible +for ensuring validity of the proposed block containing transactions that were +selected from the `PrepareProposal` step. However, how an application determines +validity of a proposed block depends on the application and its varying use cases. +For most applications, simply calling the `AnteHandler` chain would suffice, but +there could easily be other applications that need more control over the validation +process of the proposed block, such as ensuring txs are in a certain order or +that certain transactions are included. While this theoretically could be achieved +with a custom `AnteHandler` implementation, it's not the cleanest UX or the most +efficient solution. + +Instead, we will define an additional ABCI interface method on the existing +`Application` interface, similar to the existing ABCI methods such as `BeginBlock` +or `EndBlock`. This new interface method will be defined as follows: + +```go +ProcessProposal(sdk.Context, abci.RequestProcessProposal) error {} +``` + +Note, we must call `ProcessProposal` with a new internal branched state on the +`Context` argument as we cannot simply just use the existing `checkState` because +`BaseApp` already has a modified `checkState` at this point. So when executing +`ProcessProposal`, we create a similar branched state, `processProposalState`, +off of `deliverState`. Note, the `processProposalState` is never committed and +is completely discarded after `ProcessProposal` finishes execution. + +We will only populate the `Status` field of the `ResponseProcessProposal` with +`ACCEPT` if ALL the transactions were accepted as valid, otherwise we will +populate with `REJECT`. + +### `DeliverTx` + +Since transactions are not truly removed from the app-side mempool during +`PrepareProposal`, since `ProcessProposal` can fail or take multiple rounds and +we do not want to lose transactions, we need to finally remove the transaction +from the app-side mempool during `DeliverTx` since during this phase, the +transactions are being included in the proposed block. + +Alternatively, we can keep the transactions as truly being removed during the +reaping phase in `PrepareProposal` and add them back to the app-side mempool in +case `ProcessProposal` fails. + +## Consequences + +### Backwards Compatibility + +ABCI 1.0 is naturally not backwards compatible with prior versions of the Cosmos SDK +and Tendermint. For example, an application that requests `RequestPrepareProposal` +to the same application that does not speak ABCI 1.0 will naturally fail. + +However, in the first phase of the integration, the existing ABCI methods as we +know them today will still exist and function as they currently do. + +### Positive + +* Applications now have full control over transaction ordering and priority. +* Lays the groundwork for the full integration of ABCI 1.0, which will unlock more + app-side use cases around block construction and integration with the Tendermint + consensus engine. + +### Negative + +* Requires that the "mempool", as a general data structure that collects and stores + uncommitted transactions will be duplicated between both Tendermint and the + Cosmos SDK. +* Additional requests between Tendermint and the Cosmos SDK in the context of + block execution. Albeit, the overhead should be negligible. +* Not backwards compatible with previous versions of Tendermint and the Cosmos SDK. + +## Further Discussions + +It is possible to design the app-side implementation of the `Mempool[T MempoolTx]` +in many different ways using different data structures and implementations. All +of which have different tradeoffs. The proposed solution keeps things simple +and covers cases that would be required for most basic applications. There are +tradeoffs that can be made to improve performance of reaping and inserting into +the provided mempool implementation. + +## References + +* https://github.com/tendermint/tendermint/blob/master/spec/abci%2B%2B/README.md +* [1] https://github.com/tendermint/tendermint/issues/7750#issuecomment-1076806155 +* [2] https://github.com/tendermint/tendermint/issues/7750#issuecomment-1075717151 diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-061-liquid-staking.md b/versioned_docs/version-0.47/integrate/architecture/adr-061-liquid-staking.md new file mode 100644 index 000000000..56e3f9b0c --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-061-liquid-staking.md @@ -0,0 +1,82 @@ +# ADR ADR-061: Liquid Staking + +## Changelog + +* 2022-09-10: Initial Draft (@zmanian) + +## Status + +PROPOSED + +## Abstract + +Add a semi-fungible liquid staking primitive to the default Cosmos SDK staking module. This upgrades proof of stake to enable safe designs with lower overall monetary issuance and integration with numerous liquid staking protocols like Stride, Persistence, Quicksilver, Lido etc. + +## Context + +The original release of the Cosmos Hub featured the implementation of a ground breaking proof of stake mechanism featuring delegation, slashing, in protocol reward distribution and adaptive issuance. This design was state of the art for 2016 and has been deployed without major changes by many L1 blockchains. + +As both Proof of Stake and blockchain use cases have matured, this design has aged poorly and should no longer be considered a good baseline Proof of Stake issuance. In the world of application specific blockchains, there cannot be a one size fits all blockchain but the Cosmos SDK does endeavour to provide a good baseline implementation and one that is suitable for the Cosmos Hub. + +The most important deficiency of the legacy staking design is that it composes poorly with on chain protocols for trading, lending, derivatives that are referred to collectively as DeFi. The legacy staking implementation starves these applications of liquidity by increasing the risk free rate adaptively. It basically makes DeFi and staking security somewhat incompatible. + +The Osmosis team has adopted the idea of Superfluid and Interfluid staking where assets that are participating in DeFi appliactions can also be used in proof of stake. This requires tight integration with an enshrined set of DeFi applications and thus is unsuitable for the Cosmos SDK. + +It's also important to note that Interchain Accounts are available in the default IBC implementation and can be used to [rehypothecate](https://www.investopedia.com/terms/h/hypothecation.asp#toc-what-is-rehypothecation) delegations. Thus liquid staking is already possible and these changes merely improve the UX of liquid staking. Centralized exchanges also rehypothecate staked assets, posing challenges for decentralization. This ADR takes the position that adoption of in-protocol liquid staking is the preferable outcome and provides new levers to incentivize decentralization of stake. + +These changes to the staking module have been in development for more than a year and have seen substantial industry adoption who plan to build staking UX. The internal economics at Informal team has also done a review of the impacts of these changes and this review led to the development of the exempt delegation system. This system provides governance with a tuneable parameter for modulating the risks of principal agent problem called the exemption factor. + +## Decision + +We implement the semi-fungible liquid staking system and exemption factor system within the cosmos sdk. Though registered as fungible assets, these tokenized shares have extremely limited fungibility, only among the specific delegation record that was created when shares were tokenized. These assets can be used for OTC trades but composability with DeFi is limited. The primary expected use case is improving the user experience of liquid staking providers. + +A new governance parameter is introduced that defines the ratio of exempt to issued tokenized shares. This is called the exemption factor. A larger exemption factor allows more tokenized shares to be issued for a smaller amount of exempt delegations. If governance is comfortable with how the liquid staking market is evolving, it makes sense to increase this value. + +Min self delegation is removed from the staking system with the expectation that it will be replaced by the exempt delegations system. The exempt delegation system allows multiple accounts to demonstrate economic alignment with the validator operator as team members, partners etc. without co-mingling funds. Delegation exemption will likely be required to grow the validators' business under widespread adoption of liquid staking once governance has adjusted the exemption factor. + +When shares are tokenized, the underlying shares are transfered to a module account and rewards go to the module account for the TokenizedShareRecord. + +There is no longer a mechanism to override the validators vote for TokenizedShares. + + +### `MsgTokenizeShares` + +The MsgTokenizeShares message is used to create tokenize delegated tokens. This message can be executed by any delegator who has positive amount of delegation and after execution the specific amount of delegation disappear from the account and share tokens are provided. Share tokens are denominated in the validator and record id of the underlying delegation. + +A user may tokenize some or all of their delegation. + +They will receive shares with the denom of `cosmosvaloper1xxxx/5` where 5 is the record id for the validator operator. + +MsgTokenizeShares fails if the account is a VestingAccount. Users will have to move vested tokens to a new account and endure the unbonding period. We view this as an acceptable tradeoff vs. the complex book keeping required to track vested tokens. + +The total amount of outstanding tokenized shares for the validator is checked against the sum of exempt delegations multiplied by the exemption factor. If the tokenized shares exceeds this limit, execution fails. + +MsgTokenizeSharesResponse provides the number of tokens generated and their denom. + + +### `MsgRedeemTokensforShares` + +The MsgRedeemTokensforShares message is used to redeem the delegation from share tokens. This message can be executed by any user who owns share tokens. After execution delegations will appear to the user. + +### `MsgTransferTokenizeShareRecord` + +The MsgTransferTokenizeShareRecord message is used to transfer the ownership of rewards generated from the tokenized amount of delegation. The tokenize share record is created when a user tokenize his/her delegation and deleted when the full amount of share tokens are redeemed. + +This is designed to work with liquid staking designs that do not redeem the tokenized shares and may instead want to keep the shares tokenized. + + +### `MsgExemptDelegation` + +The MsgExemptDelegation message is used to exempt a delegation to a validator. If the exemption factor is greater than 0, this will allow more delegation shares to be issued from the validator. + +This design allows the chain to force an amount of self-delegation by validators participating in liquid staking schemes. + +## Consequences + +### Backwards Compatibility + +By setting the exemption factor to zero, this module works like legacy staking. The only substantial change is the removal of min-self-bond and without any tokenized shares, there is no incentive to exempt delegation. + +### Positive + +This approach should enable integration with liquid staking providers and improved user experience. It provides a pathway to security under non-exponential issuance policies in the baseline staking module. \ No newline at end of file diff --git a/versioned_docs/version-0.47/integrate/architecture/adr-template.md b/versioned_docs/version-0.47/integrate/architecture/adr-template.md new file mode 100644 index 000000000..dae4dfd44 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/architecture/adr-template.md @@ -0,0 +1,60 @@ +# ADR {ADR-NUMBER}: {TITLE} + +## Changelog + +* {date}: {changelog} + +## Status + +{DRAFT | PROPOSED} Not Implemented + +> Please have a look at the [PROCESS](./PROCESS.md#adr-status) page. +> Use DRAFT if the ADR is in a draft stage (draft PR) or PROPOSED if it's in review. + +## Abstract + +> "If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the ADR. +> A short (~200 word) description of the issue being addressed. + +## Context + +> This section describes the forces at play, including technological, political, social, and project local. These forces are probably in tension, and should be called out as such. The language in this section is value-neutral. It is simply describing facts. It should clearly explain the problem and motivation that the proposal aims to resolve. +> {context body} + +## Decision + +> This section describes our response to these forces. It is stated in full sentences, with active voice. "We will ..." +> {decision body} + +## Consequences + +> This section describes the resulting context, after applying the decision. All consequences should be listed here, not just the "positive" ones. A particular decision may have positive, negative, and neutral consequences, but all of them affect the team and project in the future. + +### Backwards Compatibility + +> All ADRs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The ADR must explain how the author proposes to deal with these incompatibilities. ADR submissions without a sufficient backwards compatibility treatise may be rejected outright. + +### Positive + +{positive consequences} + +### Negative + +{negative consequences} + +### Neutral + +{neutral consequences} + +## Further Discussions + +While an ADR is in the DRAFT or PROPOSED stage, this section should contain a summary of issues to be solved in future iterations (usually referencing comments from a pull-request discussion). +Later, this section can optionally list ideas or improvements the author or reviewers found during the analysis of this ADR. + +## Test Cases [optional] + +Test cases for an implementation are mandatory for ADRs that are affecting consensus changes. Other ADRs can choose to include links to test cases if applicable. + +## References + +* {reference link} diff --git a/versioned_docs/version-0.47/integrate/building-apps/00-app-go.md b/versioned_docs/version-0.47/integrate/building-apps/00-app-go.md new file mode 100644 index 000000000..f4af6dcfc --- /dev/null +++ b/versioned_docs/version-0.47/integrate/building-apps/00-app-go.md @@ -0,0 +1,14 @@ +--- +sidebar_position: 1 +--- + +# Overview of `app.go` + +This section is intended to provide an overview of the `SimApp` `app.go` file and is still a work in progress. +For now please instead read the [tutorials](https://tutorials.cosmos.network) for a deep dive on how to build a chain. + +## Complete `app.go` + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/simapp/app.go#L107-L738 +``` diff --git a/versioned_docs/version-0.47/integrate/building-apps/01-app-go-v2.md b/versioned_docs/version-0.47/integrate/building-apps/01-app-go-v2.md new file mode 100644 index 000000000..926d86dbb --- /dev/null +++ b/versioned_docs/version-0.47/integrate/building-apps/01-app-go-v2.md @@ -0,0 +1,130 @@ +--- +sidebar_position: 1 +--- + +# Overview of `app_v2.go` + +:::note Synopsis + +The Cosmos SDK allows much easier wiring of an `app.go` thanks to App Wiring and [`depinject`](../tooling/02-depinject.md). +Learn more about the rationale of App Wiring in [ADR-057](../architecture/adr-057-app-wiring.md). + +::: + +:::note + +### Pre-requisite Readings + +* [ADR 057: App Wiring](../architecture/adr-057-app-wiring.md) +* [Depinject Documentation](../tooling/02-depinject.md) + +::: + +This section is intended to provide an overview of the `SimApp` `app_v2.go` file with App Wiring. + +## `app_config.go` + +The `app_config.go` file is the single place to configure all modules parameters. + +1. Create the `AppConfig` variable: + + ```go reference + https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/simapp/app_config.go#L91-L93 + ``` + +2. Configure the `runtime` module: + + ```go reference + https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/simapp/app_config.go#L94-L158 + ``` + +3. Configure the modules defined in the `BeginBlocker` and `EndBlocker` and the `tx` module: + + ```go reference + https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/simapp/app_config.go#L159-L177 + ``` + + ```go reference + https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/simapp/app_config.go#L192-L194 + ``` + +### Complete `app_config.go` + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/simapp/app_config.go#L52-L254 +``` + +### Alternative formats + +:::tip +The example above shows how to create an `AppConfig` using Go. However, it is also possible to create an `AppConfig` using YAML, or JSON. +The configuration can then be embed with `go:embed` and read with [`appconfig.LoadYAML`](https://pkg.go.dev/cosmossdk.io/core/appconfig#LoadYAML), or [`appconfig.LoadJSON`](https://pkg.go.dev/cosmossdk.io/core/appconfig#LoadJSON), in `app_v2.go`. + +```go +//go:embed app_config.yaml +var ( + appConfigYaml []byte + appConfig = appconfig.LoadYAML(appConfigYaml) +) +``` + +::: + +```yaml +modules: + - name: runtime + config: + "@type": cosmos.app.runtime.v1alpha1.Module + app_name: SimApp + begin_blockers: [staking, auth, bank] + end_blockers: [bank, auth, staking] + init_genesis: [bank, auth, staking] + - name: auth + config: + "@type": cosmos.auth.module.v1.Module + bech32_prefix: cosmos + - name: bank + config: + "@type": cosmos.bank.module.v1.Module + - name: staking + config: + "@type": cosmos.staking.module.v1.Module + - name: tx + config: + "@type": cosmos.tx.module.v1.Module +``` + +A more complete example of `app.yaml` can be found [here](https://github.com/cosmos/cosmos-sdk/blob/91b1d83f1339e235a1dfa929ecc00084101a19e3/simapp/app.yaml). + +## `app_v2.go` + +`app_v2.go` is the place where `SimApp` is constructed. `depinject.Inject` facilitates that by automatically wiring the app modules and keepers, provided an application configuration `AppConfig` is provided. `SimApp` is constructed, when calling the injected `*runtime.AppBuilder`, with `appBuilder.Build(...)`. +In short `depinject` and the [`runtime` package](https://pkg.go.dev/github.com/cosmos/cosmos-sdk/runtime) abstract the wiring of the app, and the `AppBuilder` is the place where the app is constructed. [`runtime`](https://pkg.go.dev/github.com/cosmos/cosmos-sdk/runtime) takes care of registering the codecs, KV store, subspaces and instantiating `baseapp`. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/simapp/app_v2.go#L158-L291 +``` + +:::warning +When using `depinject.Inject`, the injected types must be pointers. +::: + +### Advanced Configuration + +In advanced cases, it is possible to inject extra (module) configuration in a way that is not (yet) supported by `AppConfig`. +In this case, use `depinject.Configs` for combining the extra configuration and `AppConfig`, and `depinject.Supply` to providing that extra configuration. +More information on how work `depinject.Configs` and `depinject.Supply` can be found in the [`depinject` documentation](https://pkg.go.dev/cosmossdk.io/depinject). + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/simapp/app_v2.go#L186-L216 +``` + +### Complete `app_v2.go` + +:::tip +Note that in the complete `SimApp` `app_v2.go` file, testing utilities are also defined, but they could as well be defined in a separate file. +::: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/simapp/app_v2.go#L75-L395 +``` diff --git a/versioned_docs/version-0.47/integrate/building-apps/02-app-mempool.md b/versioned_docs/version-0.47/integrate/building-apps/02-app-mempool.md new file mode 100644 index 000000000..b32b96547 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/building-apps/02-app-mempool.md @@ -0,0 +1,168 @@ +--- +sidebar_position: 1 +--- + +# Application mempool + +:::note Synopsis +This sections describes how the app-side mempool can be used and replaced. +::: + +Since `v0.47` the application has its own mempool to allow much more granular +block building than previous versions. This change was enabled by +[ABCI 1.0](https://github.com/cometbft/cometbft/blob/v0.37.0/spec/abci). +Notably it introduces the `PrepareProposal` and `ProcessProposal` steps of ABCI++. + +:::note + +### Pre-requisite Readings + +* [BaseApp](../core/00-baseapp.md) + +::: + +## Prepare Proposal + +`PrepareProposal` handles construction of the block, meaning that when a proposer +is preparing to propose a block, it requests the application to evaluate a +`RequestPrepareProposal`, which contains a series of transactions from CometBFT's +mempool. At this point, the application has complete control over the proposal. +It can modify, delete, and inject transactions from it's own app-side mempool into +the proposal or even ignore all the transactions altogether. What the application +does with the transactions provided to it by `RequestPrepareProposal` have no +effect on CometBFT's mempool. + +Note, that the application defines the semantics of the `PrepareProposal` and it +MAY be non-deterministic and is only executed by the current block proposer. + +Now, reading mempool twice in the previous sentence is confusing, lets break it down. +CometBFT has a mempool that handles gossiping transactions to other nodes +in the network. How these transactions are ordered is determined by CometBFT's +mempool, typically FIFO. However, since the application is able to fully inspect +all transactions, it can provide greater control over transaction ordering. +Allowing the application to handle ordering enables the application to define how +it would like the block constructed. + +The Cosmos SDK defines the `DefaultProposalHandler` type, which provides applications with +`PrepareProposal` and `ProcessProposal` handlers. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/baseapp/baseapp.go#L868-L916 +``` + +This default implementation can be overridden by the application developer in +favor of a custom implementation in [`app.go`](./01-app-go-v2.md): + +```go +prepareOpt := func(app *baseapp.BaseApp) { + abciPropHandler := baseapp.NewDefaultProposalHandler(mempool, app) + app.SetPrepareProposal(abciPropHandler.PrepareProposalHandler()) +} + +baseAppOptions = append(baseAppOptions, prepareOpt) +``` + +## Process Proposal + +`ProcessProposal` handles the validation of a proposal from `PrepareProposal`, +which also includes a block header. Meaning, that after a block has been proposed +the other validators have the right to vote on a block. The validator in the +default implementation of `PrepareProposal` runs basic validity checks on each +transaction. + +Note, `ProcessProposal` MAY NOT be non-deterministic, i.e. it must be deterministic. +This means if `ProcessProposal` panics or fails and we reject, all honest validator +processes will prevote nil and the CometBFT round will proceed again until a valid +proposal is proposed. + +Here is the implementation of the default implementation: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/baseapp/baseapp.go#L927-L942 +``` + +Like `PrepareProposal` this implementation is the default and can be modified by the application developer in [`app.go`](./01-app-go-v2.md): + +```go +processOpt := func(app *baseapp.BaseApp) { + abciPropHandler := baseapp.NewDefaultProposalHandler(mempool, app) + app.SetProcessProposal(abciPropHandler.ProcessProposalHandler()) +} + +baseAppOptions = append(baseAppOptions, processOpt) +``` + +## Mempool + +Now that we have walked through the `PrepareProposal` & `ProcessProposal`, we can move on to walking through the mempool. + +There are countless designs that an application developer can write for a mempool, the SDK opted to provide only simple mempool implementations. +Namely, the SDK provides the following mempools: + +* [No-op Mempool](#no-op-mempool) +* [Sender Nonce Mempool](#sender-nonce-mempool) +* [Priority Nonce Mempool](#priority-nonce-mempool) + +The default SDK is a [No-op Mempool](#no-op-mempool), but it can be replaced by the application developer in [`app.go`](./01-app-go-v2.md): + +```go +nonceMempool := mempool.NewSenderNonceMempool() +mempoolOpt := baseapp.SetMempool(nonceMempool) +baseAppOptions = append(baseAppOptions, mempoolOpt) +``` + +### No-op Mempool + +A no-op mempool is a mempool where transactions are completely discarded and ignored when BaseApp interacts with the mempool. +When this mempool is used, it assumed that an application will rely on CometBFT's transaction ordering defined in `RequestPrepareProposal`, +which is FIFO-ordered by default. + +> Note: If a NoOp mempool is used, PrepareProposal and ProcessProposal both should be aware of this as +> PrepareProposal could include transactions that could fail verification in ProcessProposal. + +### Sender Nonce Mempool + +The nonce mempool is a mempool that keeps transactions from an sorted by nonce in order to avoid the issues with nonces. +It works by storing the transaction in a list sorted by the transaction nonce. When the proposer asks for transactions to be included in a block it randomly selects a sender and gets the first transaction in the list. It repeats this until the mempool is empty or the block is full. + +It is configurable with the following parameters: + +#### MaxTxs + +It is an integer value that sets the mempool in one of three modes, *bounded*, *unbounded*, or *disabled*. + +* **negative**: Disabled, mempool does not insert new transaction and return early. +* **zero**: Unbounded mempool has no transaction limit and will never fail with `ErrMempoolTxMaxCapacity`. +* **positive**: Bounded, it fails with `ErrMempoolTxMaxCapacity` when `maxTx` value is the same as `CountTx()` + +#### Seed + +Set the seed for the random number generator used to select transactions from the mempool. + +### Priority Nonce Mempool + +The [priority nonce mempool](https://github.com/cosmos/cosmos-sdk/blob/main/types/mempool/priority_nonce_spec.md) is a mempool implementation that stores txs in a partially ordered set by 2 dimensions: + +* priority +* sender-nonce (sequence number) + +Internally it uses one priority ordered [skip list](https://pkg.go.dev/github.com/huandu/skiplist) and one skip list per sender ordered by sender-nonce (sequence number). When there are multiple txs from the same sender, they are not always comparable by priority to other sender txs and must be partially ordered by both sender-nonce and priority. + +It is configurable with the following parameters: + +#### MaxTxs + +It is an integer value that sets the mempool in one of three modes, *bounded*, *unbounded*, or *disabled*. + +* **negative**: Disabled, mempool does not insert new transaction and return early. +* **zero**: Unbounded mempool has no transaction limit and will never fail with `ErrMempoolTxMaxCapacity`. +* **positive**: Bounded, it fails with `ErrMempoolTxMaxCapacity` when `maxTx` value is the same as `CountTx()` + +#### Callback + +The priority nonce mempool provides mempool options allowing the application sets callback(s). + +* **OnRead**: Set a callback to be called when a transaction is read from the mempool. +* **TxReplacement**: Sets a callback to be called when duplicated transaction nonce detected during mempool insert. Application can define a transaction replacement rule based on tx priority or certain transaction fields. + +More information on the SDK mempool implementation can be found in the [godocs](https://pkg.go.dev/github.com/cosmos/cosmos-sdk/types/mempool). diff --git a/versioned_docs/version-0.47/integrate/building-apps/03-app-upgrade.md b/versioned_docs/version-0.47/integrate/building-apps/03-app-upgrade.md new file mode 100644 index 000000000..d60e78117 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/building-apps/03-app-upgrade.md @@ -0,0 +1,69 @@ +--- +sidebar_position: 1 +--- + +# Application upgrade + +:::note +This document describes how to upgrade your application. If you are looking specifically for the changes to perform between SDK versions, see the [SDK migrations documentation](https://docs.cosmos.network/main/migrations/intro). +::: + +:::warning +This section is currently incomplete. Track the progress of this document [here](https://github.com/cosmos/cosmos-sdk/issues/11504). +::: + +## 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. + +Using Cosmovisor pre-upgrade handling is optional. If pre-upgrade handling is not implemented, the upgrade continues. + +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. + +Before the application binary is upgraded, Cosmovisor calls a `pre-upgrade` command that can be implemented by the application. + +The `pre-upgrade` command does not take in any command-line arguments and is expected to terminate with the following exit codes: + +| Exit status code | How it is handled in Cosmosvisor | +|------------------|---------------------------------------------------------------------------------------------------------------------| +| `0` | Assumes `pre-upgrade` command executed successfully and continues the upgrade. | +| `1` | Default exit code when `pre-upgrade` command has not been implemented. | +| `30` | `pre-upgrade` command was executed but failed. This fails the entire upgrade. | +| `31` | `pre-upgrade` command was executed but failed. But the command is retried until exit code `1` or `30` are returned. | + +## Sample + +Here is a sample structure of the `pre-upgrade` command: + +```go +func preUpgradeCommand() *cobra.Command { + cmd := &cobra.Command{ + Use: "pre-upgrade", + Short: "Pre-upgrade command", + Long: "Pre-upgrade command to implement custom pre-upgrade handling", + Run: func(cmd *cobra.Command, args []string) { + + err := HandlePreUpgrade() + + if err != nil { + os.Exit(30) + } + + os.Exit(0) + + }, + } + + return cmd +} +``` + +Ensure that the pre-upgrade command has been registered in the application: + +```go +rootCmd.AddCommand( + // .. + preUpgradeCommand(), + // .. + ) +``` diff --git a/versioned_docs/version-0.47/integrate/building-apps/_category_.json b/versioned_docs/version-0.47/integrate/building-apps/_category_.json new file mode 100644 index 000000000..de6617ddc --- /dev/null +++ b/versioned_docs/version-0.47/integrate/building-apps/_category_.json @@ -0,0 +1,5 @@ +{ + "label": "Building Apps", + "position": 4, + "link": null +} \ No newline at end of file diff --git a/versioned_docs/version-0.47/integrate/building-modules/01-intro.md b/versioned_docs/version-0.47/integrate/building-modules/01-intro.md new file mode 100644 index 000000000..bb45d5d13 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/building-modules/01-intro.md @@ -0,0 +1,94 @@ +--- +sidebar_position: 1 +--- + +# Introduction to Cosmos SDK Modules + +:::note Synopsis +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. +::: + +:::note + +### Pre-requisite Readings + +* [Anatomy of a Cosmos SDK application](../basics/00-app-anatomy.md) +* [Lifecycle of a Cosmos SDK transaction](../basics/01-tx-lifecycle.md) + +::: + +## Role of Modules in a Cosmos SDK Application + +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/00-baseapp.md) to communicate with the underlying consensus engine, a [`multistore`](../core/04-store.md#multistore) to persist state, a [server](../core/03-node.md) to form a full-node and [interfaces](./09-module-interfaces.md) to handle queries. + +On top of this core, the Cosmos SDK enables developers to build modules that implement the business logic of their application. In other words, SDK modules implement the bulk of the logic of applications, while the core does the wiring and enables modules to be composed together. The end goal is to build a robust ecosystem of open-source Cosmos SDK modules, making it increasingly easier to build complex blockchain applications. + +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/04-store.md), as well as a subset of [message types](./02-messages-and-queries.md#messages). These messages are routed by one of the main components of Cosmos SDK core, [`BaseApp`](../core/00-baseapp.md), to a module Protobuf [`Msg` service](./03-msg-services.md) that defines them. + +```text + + + | + | Transaction relayed from the full-node's consensus engine + | to the node's application via DeliverTx + | + | + | + +---------------------v--------------------------+ + | APPLICATION | + | | + | Using baseapp's methods: Decode the Tx, | + | extract and route the message(s) | + | | + +---------------------+--------------------------+ + | + | + | + +---------------------------+ + | + | + | + | Message routed to the correct + | module to be processed + | + | ++----------------+ +---------------+ +----------------+ +------v----------+ +| | | | | | | | +| AUTH MODULE | | BANK MODULE | | STAKING MODULE | | GOV MODULE | +| | | | | | | | +| | | | | | | Handles message,| +| | | | | | | Updates state | +| | | | | | | | ++----------------+ +---------------+ +----------------+ +------+----------+ + | + | + | + | + +--------------------------+ + | + | Return result to the underlying consensus engine (e.g. CometBFT) + | (0=Ok, 1=Err) + 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. + +## 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`](./06-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/10-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`](./06-keeper.md). This `keeper` defines how to access the store(s) and under what conditions. Access to the module's store(s) is done by passing a reference to the module's `keeper`. + +## Main Components of Cosmos SDK Modules + +Modules are by convention defined in the `./x/` subfolder (e.g. the `bank` module will be defined in the `./x/bank` folder). They generally share the same core components: + +* A [`keeper`](./06-keeper.md), used to access the module's store(s) and update the state. +* A [`Msg` service](./02-messages-and-queries.md#messages), used to process messages when they are routed to the module by [`BaseApp`](../core/00-baseapp.md#message-routing) and trigger state-transitions. +* A [query service](./04-query-services.md), used to process user queries when they are routed to the module by [`BaseApp`](../core/00-baseapp.md#query-routing). +* Interfaces, for end users to query the subset of the state defined by the module and create `message`s of the custom types defined in the module. + +In addition to these components, modules implement the `AppModule` interface in order to be managed by the [`module manager`](./01-module-manager.md). + +Please refer to the [structure document](./11-structure.md) to learn about the recommended structure of a module's directory. diff --git a/versioned_docs/version-0.47/integrate/building-modules/01-module-manager.md b/versioned_docs/version-0.47/integrate/building-modules/01-module-manager.md new file mode 100644 index 000000000..8003e37dd --- /dev/null +++ b/versioned_docs/version-0.47/integrate/building-modules/01-module-manager.md @@ -0,0 +1,255 @@ +--- +sidebar_position: 1 +--- + +# Module Manager + +:::note Synopsis +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/00-baseapp.md#routing), and allows application developers to set the order of execution of a variety of functions like [`BeginBlocker` and `EndBlocker`](../basics/00-app-anatomy.md#begingblocker-and-endblocker). +::: + +:::note + +### Pre-requisite Readings + +* [Introduction to Cosmos SDK Modules](./01-intro.md) + +::: + +## Application Module Interfaces + +Application module interfaces exist to facilitate the composition of modules together to form a functional Cosmos SDK application. +There are 4 main application module interfaces: + +* [`AppModuleBasic`](#appmodulebasic) for independent module functionalities. +* [`AppModule`](#appmodule) for inter-dependent module functionalities (except genesis-related functionalities). +* [`AppModuleGenesis`](#appmodulegenesis) for inter-dependent genesis-related module functionalities. +* `GenesisOnlyAppModule`: Defines an `AppModule` that only has import/export functionality + +The above interfaces are mostly embedding smaller interfaces (extension interfaces), that defines specific functionalities: + +* `HasName`: Allows the module to provide its own name for legacy purposes. +* [`HasGenesisBasics`](#hasgenesisbasics): The legacy interface for stateless genesis methods. +* [`HasGenesis`](#hasgenesis): The extension interface for stateful genesis methods. +* [`HasInvariants`](#hasinvariants): The extension interface for registering invariants. +* [`HasServices`](#hasservices): The extension interface for modules to register services. +* [`HasConsensusVersion`](#hasconsensusversion): The extension interface for declaring a module consensus version. +* [`BeginBlockAppModule`](#beginblockappmodule): The extension interface that contains information about the `AppModule` and `BeginBlock`. +* [`EndBlockAppModule`](#endblockappmodule): The extension interface that contains information about the `AppModule` and `EndBlock`. + +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/00-app-anatomy.md#core-application-file). + +The `AppModule` interface exists to define inter-dependent module methods. Many modules need to interact with other modules, typically through [`keeper`s](./06-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 extension, such as `BeginBlockAppModule` and `EndBlockAppModule`, 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. + +The usage of extension interfaces allows modules to define only the functionalities they need. For example, a module that does not need an `EndBlock` does not need to define the `EndBlockAppModule` interface and thus the `EndBlock` method. `AppModule` and `AppModuleGenesis` are voluntarily small interfaces, that can take advantage of the `Module` patterns without having to define many placeholder functions. + +### `AppModuleBasic` + +The `AppModuleBasic` interface defines the independent methods modules need to implement. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/types/module/module.go#L49-L59 +``` + +Let us go through the methods: + +* `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`. +* `RegisterGRPCGatewayRoutes(client.Context, *runtime.ServeMux)`: Registers gRPC routes for the module. +* `GetTxCmd()`: Returns the root [`Tx` command](./09-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](./02-messages-and-queries.md#queries) defined in the module. +* `GetQueryCmd()`: Return the root [`query` command](./09-module-interfaces.md#query) for the module. The subcommands of this root command are used by end-users to generate new queries to the subset of the state defined by the module. + +All the `AppModuleBasic` of an application are managed by the [`BasicManager`](#basicmanager). + +### `HasName` + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/types/module/module.go#L61-L66 +``` + +* `HasName` is an interface that has a method `Name()`. This method returns the name of the module as a `string`. + +### `HasGenesisBasics` + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/types/module/module.go#L68-L72 +``` + +Let us go through the methods: + +* `DefaultGenesis(codec.JSONCodec)`: Returns a default [`GenesisState`](./08-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`](./08-genesis.md#validategenesis) function defined by the module developer. + +### `AppModuleGenesis` + +The `AppModuleGenesis` interface is a simple embedding of the `AppModuleBasic` and `HasGenesis` interfaces. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/types/module/module.go#L156-L160 +``` + +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. + +### `HasGenesis` + +The `HasGenesis` interface is an extension interface of `HasGenesisBasics`. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/types/module/module.go#L162-L167 +``` + +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. + +### `AppModule` + +The `AppModule` interface defines a module. Modules can declare their functionalities by implementing extensions interfaces. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/types/module/module.go#L169-L173 +``` + +`AppModule`s are managed by the [module manager](#manager), which checks which extension interfaces are implemented by the module. + +:::note +Previously the `AppModule` interface was containing all the methods that are defined in the extensions interfaces. This was leading to much boilerplate for modules that did not need all the functionalities. +::: + +### `HasInvariants` + +This interface defines one method. It allows to checks if a module can register invariants. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/types/module/module.go#L175-L179 +``` + +* `RegisterInvariants(sdk.InvariantRegistry)`: Registers the [`invariants`](./07-invariants.md) of the module. If an invariant deviates from its predicted value, the [`InvariantRegistry`](./07-invariants.md#registry) triggers appropriate logic (most often the chain will be halted). + +### `HasServices` + +This interface defines one method. It allows to checks if a module can register invariants. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/types/module/module.go#L181-L185 +``` + +* `RegisterServices(Configurator)`: Allows a module to register services. + +### `HasConsensusVersion` + +This interface defines one method for checking a module consensus version. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/types/module/module.go#L187-L194 +``` + +* `ConsensusVersion() uint64`: Returns the consensus version of the module. + +### `BeginBlockAppModule` + +The `BeginBlockAppModule` is an extension interface from `AppModule`. All modules that have an `BeginBlock` method implement this interface. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/types/module/module.go#L196-L200 +``` + +* `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. + +### `EndBlockAppModule` + +The `EndBlockAppModule` is an extension interface from `AppModule`. All modules that have an `EndBlock` method implement this interface. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/types/module/module.go#L202-L206 +``` + +* `EndBlock(sdk.Context, abci.RequestEndBlock)`: This method gives module developers the option to implement logic that is automatically triggered at the end of each block. This is also where the module can inform the underlying consensus engine of validator set changes (e.g. the `staking` module). Implement empty if no logic needs to be triggered at the end of each block for this module. + +### Implementing the Application Module Interfaces + +Typically, the various application module interfaces are implemented in a file called `module.go`, located in the module's folder (e.g. `./x/module/module.go`). + +Almost every module needs to implement the `AppModuleBasic` and `AppModule` interfaces. If the module is only used for genesis, it will implement `AppModuleGenesis` instead of `AppModule`. The concrete type that implements the interface can add parameters that are required for the implementation of the various methods of the interface. For example, the `Route()` function often calls a `NewMsgServerImpl(k keeper)` function defined in `keeper/msg_server.go` and therefore needs to pass the module's [`keeper`](./06-keeper.md) as a parameter. + +```go +// example +type AppModule struct { + AppModuleBasic + keeper Keeper +} +``` + +In the example above, you can see that the `AppModule` concrete type references an `AppModuleBasic`, and not an `AppModuleGenesis`. That is because `AppModuleGenesis` only needs to be implemented in modules that focus on genesis-related functionalities. In most modules, the concrete `AppModule` type will have a reference to an `AppModuleBasic` and implement the two added methods of `AppModuleGenesis` directly in the `AppModule` type. + +If no parameter is required (which is often the case for `AppModuleBasic`), just declare an empty concrete type like so: + +```go +type AppModuleBasic struct{} +``` + +## Module Managers + +Module managers are used to manage collections of `AppModuleBasic` and `AppModule`. + +### `BasicManager` + +The `BasicManager` is a structure that lists all the `AppModuleBasic` of an application: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/types/module/module.go#L74-L84 +``` + +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/00-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/main/app/app.go#L59-L74) to see an example). +* `RegisterLegacyAminoCodec(cdc *codec.LegacyAmino)`: Registers the [`codec.LegacyAmino`s](../core/05-encoding.md#amino) of each of the application's `AppModuleBasic`. This function is usually called early on in the [application's construction](../basics/00-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)`](./08-genesis.md#defaultgenesis) function of each module. It only calls the modules that implements the `HasGenesisBasics` interfaces. +* `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)`](./08-genesis.md#validategenesis) function of modules implementing the `HasGenesisBasics` interface. +* `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/07-cli.md#transaction-commands). This function is usually called function from the `main.go` function of the [application's command-line interface](../core/07-cli.md). +* `AddQueryCommands(rootQueryCmd *cobra.Command)`: Adds modules' query commands to the application's [`rootQueryCommand`](../core/07-cli.md#query-commands). This function is usually called function from the `main.go` function of the [application's command-line interface](../core/07-cli.md). + +### `Manager` + +The `Manager` is a structure that holds all the `AppModule` of an application, and defines the order of execution between several key components of these modules: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/types/module/module.go#L246-L273 +``` + +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/00-app-anatomy.md#constructor-function). +* `SetOrderInitGenesis(moduleNames ...string)`: Sets the order in which the [`InitGenesis`](./08-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/00-app-anatomy.md#constructor-function). + To initialize modules successfully, module dependencies should be considered. For example, the `genutil` module must occur after `staking` module so that the pools are properly initialized with tokens from genesis accounts, the `genutils` module must also occur after `auth` so that it can access the params from auth, `capability` module should be initialized before all other modules so that it can initialize any capabilities. +* `SetOrderExportGenesis(moduleNames ...string)`: Sets the order in which the [`ExportGenesis`](./08-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/00-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/00-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/00-app-anatomy.md#constructor-function). +* `SetOrderMigrations(moduleNames ...string)`: Sets the order of migrations to be run. If not set then migrations will be run with an order defined in `DefaultMigrationsOrder`. +* `RegisterInvariants(ir sdk.InvariantRegistry)`: Registers the [invariants](./07-invariants.md) of module implementing the `HasInvariants` interface. +* `RegisterRoutes(router sdk.Router, queryRouter sdk.QueryRouter, legacyQuerierCdc *codec.LegacyAmino)`: Registers legacy [`Msg`](./02-messages-and-queries.md#messages) and [`querier`](./04-query-services.md#legacy-queriers) routes. +* `RegisterServices(cfg Configurator)`: Registers the services of modules implementing the `HasServices` interface. +* `InitGenesis(ctx sdk.Context, cdc codec.JSONCodec, genesisData map[string]json.RawMessage)`: Calls the [`InitGenesis`](./08-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`](./08-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. +* `ExportGenesisForModules(ctx sdk.Context, cdc codec.JSONCodec, modulesToExport []string)`: Behaves the same as `ExportGenesis`, except takes a list of modules to export. +* `BeginBlock(ctx sdk.Context, req abci.RequestBeginBlock)`: At the beginning of each block, this function is called from [`BaseApp`](../core/00-baseapp.md#beginblock) and, in turn, calls the [`BeginBlock`](./05-beginblock-endblock.md) function of each modules implementing the `BeginBlockAppModule` interface, in the order defined in `OrderBeginBlockers`. It creates a child [context](../core/02-context.md) with an event manager to aggregate [events](../core/08-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/00-baseapp.md#endblock) and, in turn, calls the [`EndBlock`](./05-beginblock-endblock.md) function of each modules implementing the `EndBlockAppModule` interface, in the order defined in `OrderEndBlockers`. It creates a child [context](../core/02-context.md) with an event manager to aggregate [events](../core/08-events.md) emitted from all modules. The function returns an `abci.ResponseEndBlock` which contains the aforementioned events, as well as validator set updates (if any). + +Here's an example of a concrete integration within an `simapp`: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/simapp/app.go#L386-L432 +``` + +This is the same example from `runtime` (the package that powers app v2): + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/runtime/module.go#L77 +``` + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/runtime/module.go#L87 +``` diff --git a/versioned_docs/version-0.47/integrate/building-modules/02-messages-and-queries.md b/versioned_docs/version-0.47/integrate/building-modules/02-messages-and-queries.md new file mode 100644 index 000000000..2021c7e96 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/building-modules/02-messages-and-queries.md @@ -0,0 +1,129 @@ +--- +sidebar_position: 1 +--- + +# Messages and Queries + +:::note Synopsis +`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`. +::: + +:::note + +### Pre-requisite Readings + +* [Introduction to Cosmos SDK Modules](./01-intro.md) + +::: + +## Messages + +`Msg`s are objects whose end-goal is to trigger state-transitions. They are wrapped in [transactions](../core/01-transactions.md), which may contain one or more of them. + +When a transaction is relayed from the underlying consensus engine to the Cosmos SDK application, it is first decoded by [`BaseApp`](../core/00-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](./03-msg-services.md). For a more detailed explanation of the lifecycle of a transaction, click [here](../basics/01-tx-lifecycle.md). + +### `Msg` Services + +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/05-encoding.md#faq)). It must have an RPC service method defined for each message in the module. + +See an example of a `Msg` service definition from `x/bank` module: + +```protobuf reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/bank/v1beta1/tx.proto#L13-L36 +``` + +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: + +```protobuf + 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. + +The Cosmos SDK uses Protobuf definitions to generate client and server code: + +* `MsgServer` interface defines the server API for the `Msg` service and its implementation is described as part of the [`Msg` services](./03-msg-services.md) documentation. +* Structures are generated for all RPC request and response types. + +A `RegisterMsgServer` method is also generated and should be used to register the module's `MsgServer` implementation in `RegisterServices` method from the [`AppModule` interface](./01-module-manager.md#appmodule). + +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`](01-module-manager.md#appmodulebasic) method, using the proto-generated `&_Msg_serviceDesc` as `*grpc.ServiceDesc` argument. + +### Legacy Amino `LegacyMsg`s + +The following way of defining messages is deprecated and using [`Msg` services](#msg-services) is preferred. + +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. + +A `LegacyMsg` is typically accompanied by a standard constructor function, that is called from one of the [module's interface](./09-module-interfaces.md). `message`s also need to implement the `sdk.Msg` interface: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/types/tx_msg.go#L14-L26 +``` + +It extends `proto.Message` and contains the following methods: + +* `Route() string`: Name of the route for this message. Typically all `message`s in a module have the same route, which is most often the module's name. +* `Type() string`: Type of the message, used primarily in [events](../core/08-events.md). This should return a message-specific `string`, typically the denomination of the message itself. +* [`ValidateBasic() error`](../basics/01-tx-lifecycle.md#ValidateBasic). +* `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. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/auth/migrations/legacytx/stdsign.go#L20-L36 +``` + +See an example implementation of a `message` from the `gov` module: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/gov/types/v1/msgs.go#L121-L153 +``` + +## 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 (./04-query-services.md). For a deeper look at the lifecycle of a `query`, click [here](../basics/02-query-lifecycle.md). + +### gRPC Queries + +Queries should be defined using [Protobuf services](https://developers.google.com/protocol-buffers/docs/proto#services). A `Query` service should be created per module in `query.proto`. This service lists endpoints starting with `rpc`. + +Here's an example of such a `Query` service definition: + +```protobuf reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/auth/v1beta1/query.proto#L14-L89 +``` + +As `proto.Message`s, generated `Response` types implement by default `String()` method of [`fmt.Stringer`](https://pkg.go.dev/fmt#Stringer). + +A `RegisterQueryServer` method is also generated and should be used to register the module's query server in the `RegisterServices` method from the [`AppModule` interface](./01-module-manager.md#appmodule). + +### 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 to process it. For most module queries, the `path` should look like the following: + +```text +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/00-baseapp.md#query). +* `queryRoute` is used by `BaseApp`'s [`queryRouter`](../core/00-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`](./04-query-services.md#legacy-queriers) to map the `query` to the appropriate `querier function` within the module. +* `args` are the actual arguments needed to process the `query`. They are filled out by the end-user. Note that for bigger queries, you might prefer passing arguments in the `Data` field of the request `req` instead of the `path`. + +The `path` for each `query` must be defined by the module developer in the module's [command-line interface file](./09-module-interfaces.md#query-commands).Overall, there are 3 mains components module developers need to implement in order to make the subset of the state defined by their module queryable: + +* A [`querier`](./04-query-services.md#legacy-queriers), to process the `query` once it has been [routed to the module](../core/00-baseapp.md#query-routing). +* [Query commands](./09-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://pkg.go.dev/fmt#Stringer). + +### Store Queries + +Store queries query directly for store keys. They use `clientCtx.QueryABCI(req abci.RequestQuery)` to return the full `abci.ResponseQuery` with inclusion Merkle proofs. + +See following examples: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/baseapp/abci.go#L881-L902 +``` diff --git a/versioned_docs/version-0.47/integrate/building-modules/03-msg-services.md b/versioned_docs/version-0.47/integrate/building-modules/03-msg-services.md new file mode 100644 index 000000000..b1e9a54d3 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/building-modules/03-msg-services.md @@ -0,0 +1,114 @@ +--- +sidebar_position: 1 +--- + +# `Msg` Services + +:::note Synopsis +A Protobuf `Msg` service processes [messages](./02-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/00-baseapp.md#delivertx). +::: + +:::note + +### Pre-requisite Readings + +* [Module Manager](./01-module-manager.md) +* [Messages and Queries](./02-messages-and-queries.md) + +::: + +## Implementation of a module `Msg` service + +Each module should define a Protobuf `Msg` service, which will be responsible for processing requests (implementing `sdk.Msg`) and returning responses. + +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. + +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: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/bank/types/tx.pb.go#L550-L568 +``` + +When possible, the existing module's [`Keeper`](./06-keeper.md) should implement `MsgServer`, otherwise a `msgServer` struct that embeds the `Keeper` can be created, typically in `./keeper/msg_server.go`: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/bank/keeper/msg_server.go#L15-L17 +``` + +`msgServer` methods can retrieve the `sdk.Context` from the `context.Context` parameter method using the `sdk.UnwrapSDKContext`: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/bank/keeper/msg_server.go#L28 +``` + +`sdk.Msg` processing usually follows these 3 steps: + +### Validation + +Before a `msgServer` method is executed, the message's [`ValidateBasic()`](../basics/01-tx-lifecycle.md#ValidateBasic) method has already been called. Since `msg.ValidateBasic()` performs only the most basic checks, this stage must perform all other validation (both *stateful* and *stateless*) to make sure the `message` is valid. Checks performed in the `msgServer` method can be more expensive and the signer is charged gas for these operations. +For example, a `msgServer` method for a `transfer` message might check that the sending account has enough funds to actually perform the transfer. + +It is recommended to implement all validation checks in a separate function that passes state values as arguments. This implementation simplifies testing. As expected, expensive validation functions charge additional gas. Example: + +```go +ValidateMsgA(msg MsgA, now Time, gm GasMeter) error { + if now.Before(msg.Expire) { + return sdkerrrors.ErrInvalidRequest.Wrap("msg expired") + } + gm.ConsumeGas(1000, "signature verification") + return signatureVerificaton(msg.Prover, msg.Data) +} +``` + +### State Transition + +After the validation is successful, the `msgServer` method uses the [`keeper`](./06-keeper.md) functions to access the state and perform a state transition. + +### Events + +Before returning, `msgServer` methods generally emit one or more [events](../core/08-events.md) by using the `EventManager` held in the `ctx`. Use the new `EmitTypedEvent` function that uses protobuf-based event types: + +```go +ctx.EventManager().EmitTypedEvent( + &group.EventABC{Key1: Value1, Key2, Value2}) +``` + +or the older `EmitEvent` function: + +```go +ctx.EventManager().EmitEvent( + sdk.NewEvent( + eventType, // e.g. sdk.EventTypeMessage for a message, types.CustomEventType for a custom event defined in the module + sdk.NewAttribute(key1, value1), + sdk.NewAttribute(key2, value2), + ), +) +``` + +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/08-events.md) to learn more about events. + +The invoked `msgServer` method returns a `proto.Message` response and an `error`. These return values are then wrapped into an `*sdk.Result` or an `error` using `sdk.WrapServiceResult(ctx sdk.Context, res proto.Message, err error)`: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/baseapp/msg_service_router.go#L131 +``` + +This method takes care of marshaling the `res` parameter to protobuf and attaching any events on the `ctx.EventManager()` to the `sdk.Result`. + +```protobuf reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/base/abci/v1beta1/abci.proto#L88-L109 +``` + +This diagram shows a typical structure of a Protobuf `Msg` service, and how the message propagates through the module. + +![Transaction flow](https://raw.githubusercontent.com/cosmos/cosmos-sdk/release/v0.46.x/docs/uml/svg/transaction_flow.svg) + +## Telemetry + +New [telemetry metrics](../core/09-telemetry.md) can be created from `msgServer` methods when handling messages. + +This is an example from the `x/auth/vesting` module: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/auth/vesting/msg_server.go#L68-L80 +``` diff --git a/versioned_docs/version-0.47/integrate/building-modules/04-query-services.md b/versioned_docs/version-0.47/integrate/building-modules/04-query-services.md new file mode 100644 index 000000000..cedeb0928 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/building-modules/04-query-services.md @@ -0,0 +1,59 @@ +--- +sidebar_position: 1 +--- + +# Query Services + +:::note Synopsis +A Protobuf Query service processes [`queries`](./02-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/00-baseapp.md#query). +::: + +:::note + +### Pre-requisite Readings + +* [Module Manager](./01-module-manager.md) +* [Messages and Queries](./02-messages-and-queries.md) + +::: + +## Implementation of a module query service + +### gRPC Service + +When defining a Protobuf `Query` service, a `QueryServer` interface is generated for each module with all the service methods: + +```go +type QueryServer interface { + QueryBalance(context.Context, *QueryBalanceParams) (*types.Coin, error) + QueryAllBalances(context.Context, *QueryAllBalancesParams) (*QueryAllBalancesResponse, error) +} +``` + +These custom queries methods should be implemented by a module's keeper, typically in `./keeper/grpc_query.go`. The first parameter of these methods is a generic `context.Context`. Therefore, the Cosmos SDK provides a function `sdk.UnwrapSDKContext` to retrieve the `sdk.Context` from the provided +`context.Context`. + +Here's an example implementation for the bank module: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/bank/keeper/grpc_query.go +``` + +### Calling queries from the State Machine + +The Cosmos SDK v0.47 introduces a new `cosmos.query.v1.module_query_safe` Protobuf annotation which is used to state that a query that is safe to be called from within the state machine, for example: + +* a Keeper's query function can be called from another module's Keeper, +* ADR-033 intermodule query calls, +* CosmWasm contracts can also directly interact with these queries. + +If the `module_query_safe` annotation set to `true`, it means: + +* The query is deterministic: given a block height it will return the same response upon multiple calls, and doesn't introduce any state-machine breaking changes across SDK patch versions. +* Gas consumption never fluctuates across calls and across patch versions. + +If you are a module developer and want to use `module_query_safe` annotation for your own query, you have to ensure the following things: + +* the query is deterministic and won't introduce state-machine-breaking changes without coordinated upgrades +* it has its gas tracked, to avoid the attack vector where no gas is accounted for + on potentially high-computation queries. diff --git a/versioned_docs/version-0.47/integrate/building-modules/05-beginblock-endblock.md b/versioned_docs/version-0.47/integrate/building-modules/05-beginblock-endblock.md new file mode 100644 index 000000000..4cfdda370 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/building-modules/05-beginblock-endblock.md @@ -0,0 +1,45 @@ +--- +sidebar_position: 1 +--- + +# BeginBlocker and EndBlocker + +:::note Synopsis +`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/00-baseapp.md#beginblock) and [`EndBlock`](../core/00-baseapp.md#endblock) ABCI messages are received from the underlying consensus engine. +::: + +:::note + +### Pre-requisite Readings + +* [Module Manager](./01-module-manager.md) + +::: + +## BeginBlocker and EndBlocker + +`BeginBlocker` and `EndBlocker` are a way for module developers to add automatic execution of logic to their module. This is a powerful tool that should be used carefully, as complex automatic functions can slow down or even halt the chain. + +When needed, `BeginBlocker` and `EndBlocker` are implemented as part of the [`BeginBlockAppModule` and `BeginBlockAppModule` interfaces](./01-module-manager.md#appmodule). This means either can be left-out if not required. 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`. + +The actual implementation of `BeginBlocker` and `EndBlocker` in `abci.go` are very similar to that of a [`Msg` service](./03-msg-services.md): + +* They generally use the [`keeper`](./06-keeper.md) and [`ctx`](../core/02-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/08-events.md) via the `ctx`'s `EventManager`. + +A specificity of the `EndBlocker` is that it can return validator updates to the underlying consensus engine in the form of an [`[]abci.ValidatorUpdates`](https://docs.cometbft.com/v0.37/spec/abci/abci++_methods#endblock). This is the preferred way to implement custom validator changes. + +It is possible for developers to define the order of execution between the `BeginBlocker`/`EndBlocker` functions of each of their application's modules via the module's manager `SetOrderBeginBlocker`/`SetOrderEndBlocker` methods. For more on the module manager, click [here](./01-module-manager.md#manager). + +See an example implementation of `BeginBlocker` from the `distribution` module: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/distribution/abci.go#L14-L38 +``` + +and an example implementation of `EndBlocker` from the `staking` module: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/staking/abci.go#L22-L27 +``` diff --git a/versioned_docs/version-0.47/integrate/building-modules/06-keeper.md b/versioned_docs/version-0.47/integrate/building-modules/06-keeper.md new file mode 100644 index 000000000..946eff6ff --- /dev/null +++ b/versioned_docs/version-0.47/integrate/building-modules/06-keeper.md @@ -0,0 +1,93 @@ +--- +sidebar_position: 1 +--- + +# Keepers + +:::note Synopsis +`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. +::: + +:::note + +### Pre-requisite Readings + +* [Introduction to Cosmos SDK Modules](./01-intro.md) + +::: + +## Motivation + +The Cosmos SDK is a framework that makes it easy for developers to build complex decentralized applications from scratch, mainly by composing modules together. As the ecosystem of open-source modules for the Cosmos SDK expands, it will become increasingly likely that some of these modules contain vulnerabilities, as a result of the negligence or malice of their developer. + +The Cosmos SDK adopts an [object-capabilities-based approach](../core/10-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 considered quite literally to be the gatekeeper of a module's store(s). Each store (typically an [`IAVL` Store](../core/04-store.md#iavl-store)) defined within a module comes with a `storeKey`, which grants unlimited access to it. The module's `keeper` holds this `storeKey` (which should otherwise remain unexposed), and defines [methods](#implementing-methods) for reading and writing to the store(s). + +The core idea behind the object-capabilities approach is to only reveal what is necessary to get the work done. In practice, this means that instead of handling permissions of modules through access-control lists, module `keeper`s are passed a reference to the specific instance of the other modules' `keeper`s that they need to access (this is done in the [application's constructor function](../basics/00-app-anatomy.md#constructor-function)). As a consequence, a module can only interact with the subset of state defined in another module via the methods exposed by the instance of the other module's `keeper`. This is a great way for developers to control the interactions that their own module can have with modules developed by external developers. + +## Type Definition + +`keeper`s are generally implemented in a `/keeper/keeper.go` file located in the module's folder. By convention, the type `keeper` of a module is simply named `Keeper` and usually follows the following structure: + +```go +type Keeper struct { + // External keepers, if any + + // Store key(s) + + // codec + + // authority +} +``` + +For example, here is the type definition of the `keeper` from the `staking` module: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/staking/keeper/keeper.go#L23-L31 +``` + +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/04-store.md) managed by the module. They should always remain unexposed to external modules. +* `cdc` is the [codec](../core/05-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. The authority listed is a module account or user account that has the right to change module level parameters. Previously this was handled by the param module, which has been deprecated. + +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/00-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. + +## 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`](./02-messages-and-queries.md#messages) and the [`Msg` server](./03-msg-services.md) when `keeper`s' methods are called. + +Typically, a *getter* method will have the following signature + +```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 preferred to use the `prefix.Store` to access only the desired limited subset of the store for convenience and safety. +2. If it exists, get the `[]byte` value stored at location `[]byte(key)` using the `Get(key []byte)` method of the store. +3. Unmarshall the retrieved value from `[]byte` to `returnType` using the codec `cdc`. Return the value. + +Similarly, a *setter* method will have the following signature + +```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. + +For more, see an example of `keeper`'s [methods implementation from the `staking` module](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/staking/keeper/keeper.go). + +The [module `KVStore`](../core/04-store.md#kvstore-and-commitkvstore-interfaces) also provides an `Iterator()` method which returns an `Iterator` object to iterate over a domain of keys. + +This is an example from the `auth` module to iterate accounts: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/auth/keeper/account.go#L94-L108 +``` diff --git a/versioned_docs/version-0.47/integrate/building-modules/07-invariants.md b/versioned_docs/version-0.47/integrate/building-modules/07-invariants.md new file mode 100644 index 000000000..4c53169d4 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/building-modules/07-invariants.md @@ -0,0 +1,92 @@ +--- +sidebar_position: 1 +--- + +# Invariants + +:::note Synopsis +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. +::: + +:::note + +### Pre-requisite Readings + +* [Keepers](./06-keeper.md) + +::: + +## Implementing `Invariant`s + +An `Invariant` is a function that checks for a particular invariant within a module. Module `Invariant`s must follow the `Invariant` type: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/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. + +In practice, each module implements `Invariant`s in a `keeper/invariants.go` file within the module's folder. The standard is to implement one `Invariant` function per logical grouping of invariants with the following model: + +```go +// Example for an Invariant that checks balance-related invariants + +func BalanceInvariants(k Keeper) sdk.Invariant { + return func(ctx sdk.Context) (string, bool) { + // Implement checks for balance-related invariants + } +} +``` + +Additionally, module developers should generally implement an `AllInvariants` function that runs all the `Invariant`s functions of the module: + +```go +// AllInvariants runs all invariants of the module. +// In this example, the module implements two Invariants: BalanceInvariants and DepositsInvariants + +func AllInvariants(k Keeper) sdk.Invariant { + + return func(ctx sdk.Context) (string, bool) { + res, stop := BalanceInvariants(k)(ctx) + if stop { + return res, stop + } + + return DepositsInvariant(k)(ctx) + } +} +``` + +Finally, module developers need to implement the `RegisterInvariants` method as part of the [`AppModule` interface](./01-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): + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/staking/keeper/invariants.go#L12-L22 +``` + +For more, see an example of [`Invariant`s implementation from the `staking` module](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/staking/keeper/invariants.go). + +## Invariant Registry + +The `InvariantRegistry` is a registry where the `Invariant`s of all the modules of an application are registered. There is only one `InvariantRegistry` per **application**, meaning module developers need not implement their own `InvariantRegistry` when building a module. **All module developers need to do is to register their modules' invariants in the `InvariantRegistry`, as explained in the section above**. The rest of this section gives more information on the `InvariantRegistry` itself, and does not contain anything directly relevant to module developers. + +At its core, the `InvariantRegistry` is defined in the Cosmos SDK as an interface: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/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: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/crisis/keeper/keeper.go#L57-L61 +``` + +The `InvariantRegistry` is therefore typically instantiated by instantiating the `keeper` of the `crisis` module in the [application's constructor function](../basics/00-app-anatomy.md#constructor-function). + +`Invariant`s can be checked manually via [`message`s](./02-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: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/crisis/abci.go#L12-L21 +``` + +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). diff --git a/versioned_docs/version-0.47/integrate/building-modules/08-genesis.md b/versioned_docs/version-0.47/integrate/building-modules/08-genesis.md new file mode 100644 index 000000000..a63c8b119 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/building-modules/08-genesis.md @@ -0,0 +1,72 @@ +--- +sidebar_position: 1 +--- + +# Module Genesis + +:::note Synopsis +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. +::: + +:::note + +### Pre-requisite Readings + +* [Module Manager](./01-module-manager.md) +* [Keepers](./06-keeper.md) + +::: + +## Type Definition + +The subset of the genesis state defined from a given module is generally defined in a `genesis.proto` file ([more info](../core/05-encoding.md#gogoproto) on how to define protobuf messages). The struct defining the module's subset of the genesis state is usually called `GenesisState` and contains all the module-related values that need to be initialized during the genesis process. + +See an example of `GenesisState` protobuf message definition from the `auth` module: + +```protobuf reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/auth/v1beta1/genesis.proto +``` + +Next we present the main genesis-related methods that need to be implemented by module developers in order for their module to be used in Cosmos SDK applications. + +### `DefaultGenesis` + +The `DefaultGenesis()` method is a simple method that calls the constructor function for `GenesisState` with the default value for each parameter. See an example from the `auth` module: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/auth/module.go#L55-L59 +``` + +### `ValidateGenesis` + +The `ValidateGenesis(data 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: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/auth/types/genesis.go#L61-L74 +``` + +## 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](./01-module-manager.md#appmodulegenesis) (only if the module needs to initialize a subset of state in genesis). These methods are [`InitGenesis`](#initgenesis) and [`ExportGenesis`](#exportgenesis). + +### `InitGenesis` + +The `InitGenesis` method is executed during [`InitChain`](../core/00-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`](./06-keeper.md) setter function on each parameter within the `GenesisState`. + +The [module manager](./01-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/00-app-anatomy.md#constructor-function). + +See an example of `InitGenesis` from the `auth` module: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/auth/keeper/genesis.go#L8-L35 +``` + +### `ExportGenesis` + +The `ExportGenesis` method is executed whenever an export of the state is made. It takes the latest known version of the subset of the state managed by the module and creates a new `GenesisState` out of it. This is mainly used when the chain needs to be upgraded via a hard fork. + +See an example of `ExportGenesis` from the `auth` module. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/auth/keeper/genesis.go#L37-L49 +``` diff --git a/versioned_docs/version-0.47/integrate/building-modules/09-module-interfaces.md b/versioned_docs/version-0.47/integrate/building-modules/09-module-interfaces.md new file mode 100644 index 000000000..12f290183 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/building-modules/09-module-interfaces.md @@ -0,0 +1,161 @@ +--- +sidebar_position: 1 +--- + +# Module Interfaces + +:::note Synopsis +This document details how to build CLI and REST interfaces for a module. Examples from various Cosmos SDK modules are included. +::: + +:::note + +### Pre-requisite Readings + +* [Building Modules Intro](./01-intro.md) + +::: + +## CLI + +One of the main interfaces for an application is the [command-line interface](../core/07-cli.md). This entrypoint adds commands from the application's modules enabling end-users to create [**messages**](./02-messages-and-queries.md#messages) wrapped in transactions and [**queries**](./02-messages-and-queries.md#queries). The CLI files are typically found in the module's `./client/cli` folder. + +### Transaction Commands + +In order to create messages that trigger state changes, end-users must create [transactions](../core/01-transactions.md) that wrap and deliver the messages. A transaction command creates a transaction that includes one or more messages. + +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. + +Here is an example from the `x/bank` module: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/bank/client/cli/tx.go#L35-L71 +``` + +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. + +In general, the getter function does the following: + +* **Constructs the command:** Read the [Cobra Documentation](https://pkg.go.dev/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](./02-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()`](../basics/01-tx-lifecycle.md#ValidateBasic) and other validation methods before broadcasting the message. + * 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: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/bank/client/cli/tx.go#L17-L33 +``` + +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: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/bank/module.go#L79-L82 +``` + +### Query Commands + +[Queries](./02-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: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/auth/client/cli/query.go#L86-L128 +``` + +In the example, `GetAccountCmd()` creates and returns a query command that returns the state of an account based on the provided account address. + +In general, the getter function does the following: + +* **Constructs the command:** Read the [Cobra Documentation](https://pkg.go.dev/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](./02-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. + +Each module must implement `GetQueryCmd()`, which aggregates all of the query commands of the module. Here is an example from the `x/auth` module: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/auth/client/cli/query.go#L33-L53 +``` + +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: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/bank/module.go#L84-L87 +``` + +### Flags + +[Flags](../core/07-cli.md#flags) allow users to customize commands. `--fees` and `--gas-prices` are examples of flags that allow users to set the [fees](../basics/04-gas-fees.md) and gas prices for their transactions. + +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. + +Here is an example that adds the `--from` flag to a command: + +```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. + +Here is an example that marks the `--from` flag as _required_: + +```go +cmd.MarkFlagRequired(FlagFrom) +``` + +For more detailed information on creating flags, visit the [Cobra Documentation](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. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/client/flags/flags.go#L108-L138 +``` + +Since `AddTxFlagsToCmd(cmd *cobra.Command)` includes all of the basic flags required for a transaction command, module developers may choose not to add any of their own (specifying arguments instead may often be more appropriate). + +Similarly, there is a `AddQueryFlagsToCmd(cmd *cobra.Command)` to add common flags to a module query command. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/client/flags/flags.go#L95-L106 +``` + +## 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. + +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. + +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. + +Here's an example from the `x/auth` module: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/auth/module.go#L71-L76 +``` + +## gRPC-gateway REST + +Applications need to support web services that use HTTP requests (e.g. a web wallet like [Keplr](https://keplr.app)). [grpc-gateway](https://github.com/grpc-ecosystem/grpc-gateway) translates REST calls into gRPC calls, which might be useful for clients that do not use gRPC. + +Modules that want to expose REST queries should add `google.api.http` annotations to their `rpc` methods, such as in the example below from the `x/auth` module: + +```protobuf reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/auth/v1beta1/query.proto#L14-L89 +``` + +gRPC gateway is started in-process along with the application and CometBFT. It can be enabled or disabled by setting gRPC Configuration `enable` in [`app.toml`](../run-node/02-interact-node.md#configuring-the-node-using-apptoml). + +The Cosmos SDK provides a command for generating [Swagger](https://swagger.io/) documentation (`protoc-gen-swagger`). Setting `swagger` in [`app.toml`](../run-node/02-interact-node.md#configuring-the-node-using-apptoml) defines if swagger documentation should be automatically registered. diff --git a/versioned_docs/version-0.47/integrate/building-modules/10-autocli.md b/versioned_docs/version-0.47/integrate/building-modules/10-autocli.md new file mode 100644 index 000000000..1629e3d65 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/building-modules/10-autocli.md @@ -0,0 +1,157 @@ +--- +sidebar_position: 1 +--- + + +# AutoCLI + +:::note Synopsis +This document details how to build CLI and REST interfaces for a module. Examples from various Cosmos SDK modules are included. +::: + +:::note + +## Pre-requisite Readings + +* [Building Modules Intro](./01-intro.md) + +::: + +The `autocli` package is a [Go library](https://pkg.go.dev/cosmossdk.io/client/v2/autocli) for generating CLI (command line interface) interfaces for Cosmos SDK-based applications. It provides a simple way to add CLI commands to your application by generating them automatically based on your gRPC service definitions. Autocli generates CLI commands and flags directly from your protobuf messages, including options, input parameters, and output parameters. This means that you can easily add a CLI interface to your application without having to manually create and manage commands. + +## Getting Started + +Here are the steps to use the `autocli` package: + +1. Define your app's modules that implement the `appmodule.AppModule` interface. +2. (optional) When willing to configure how behave `autocli` command generation, implement the `func (am AppModule) AutoCLIOptions() *autocliv1.ModuleOptions` method on the module. Learn more [here](#advanced-usage). +3. Use the `autocli.AppOptions` struct to specifies the modules you defined. If you are using the `depinject` package to manage your app's dependencies, it can automatically create an instance of `autocli.AppOptions` based on your app's configuration. +4. Use the `EnhanceRootCommand()` method provided by `autocli` to add the CLI commands for the specified modules to your root command and can also be found in the `client/v2/autocli/app.go` file. Additionally, this method adds the `autocli` functionality to your app's root command. This method is additive only, meaning that it does not create commands if they are already registered for a module. Instead, it adds any missing commands to the root command. + +Here's an example of how to use `autocli`: + +``` go +// Define your app's modules +testModules := map[string]appmodule.AppModule{ + "testModule": &TestModule{}, +} + +// Define the autocli AppOptions +autoCliOpts := autocli.AppOptions{ + Modules: testModules, +} + +// Get the root command +rootCmd := &cobra.Command{ + Use: "app", +} + +// Enhance the root command with autocli +autocli.EnhanceRootCommand(rootCmd, autoCliOpts) + +// Run the root command +if err := rootCmd.Execute(); err != nil { + fmt.Println(err) +} +``` + +## Flags + +`autocli` generates flags for each field in a protobuf message. By default, the names of the flags are generated based on the names of the fields in the message. You can customise the flag names using the `namingOptions` parameter of the `Builder.AddMessageFlags()` method. + +To define flags for a message, you can use the `Builder.AddMessageFlags()` method. This method takes the `cobra.Command` instance and the message type as input, and generates flags for each field in the message. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/1ac260cb1c6f05666f47e67f8b2cfd6229a55c3b/client/v2/autocli/common.go#L44-L49 +``` + +The `binder` variable returned by the `AddMessageFlags()` method is used to bind the command-line arguments to the fields in the message. + +You can also customise the behavior of the flags using the `namingOptions` parameter of the `Builder.AddMessageFlags()` method. This parameter allows you to specify a custom prefix for the flags, and to specify whether to generate flags for repeated fields and whether to generate flags for fields with default values. + +## Commands and Queries + +The `autocli` package generates CLI commands and flags for each method defined in your gRPC service. By default, it generates commands for each RPC method that does not return a stream of messages. The commands are named based on the name of the service method. + +For example, given the following protobuf definition for a service: + +```protobuf +service MyService { + rpc MyMethod(MyRequest) returns (MyResponse) {} +} +``` + +`autocli` will generate a command named `my-method` for the `MyMethod` method. The command will have flags for each field in the `MyRequest` message. + +If you want to customise the behavior of a command, you can define a custom command by implementing the `autocli.Command` interface. You can then register the command with the `autocli.Builder` instance for your application. + +Similarly, you can define a custom query by implementing the `autocli.Query` interface. You can then register the query with the `autocli.Builder` instance for your application. + +To add a custom command or query, you can use the `Builder.AddCustomCommand` or `Builder.AddCustomQuery` methods, respectively. These methods take a `cobra.Command` or `cobra.Command` instance, respectively, which can be used to define the behavior of the command or query. + +## Advanced Usage + +### Specifying Subcommands + +By default, `autocli` generates a command for each method in your gRPC service. However, you can specify subcommands to group related commands together. To specify subcommands, you can use the `autocliv1.ServiceCommandDescriptor` struct. + +This example shows how to use the `autocliv1.ServiceCommandDescriptor` struct to group related commands together and specify subcommands in your gRPC service by defining an instance of `autocliv1.ModuleOptions` in your `autocli.go` file. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/bcdf81cbaf8d70c4e4fa763f51292d54aed689fd/x/gov/autocli.go#L9-L27 +``` + +The `AutoCLIOptions()` method in the autocli package allows you to specify the services and sub-commands to be mapped for your app. In the example code, an instance of the `autocliv1.ModuleOptions` struct is defined in the `appmodule.AppModule` implementation located in the `x/gov/autocli.go` file. This configuration groups related commands together and specifies subcommands for each service. + +### Positional Arguments + +Positional arguments are arguments that are passed to a command without being specified as a flag. They are typically used for providing additional context to a command, such as a filename or search query. + +To add positional arguments to a command, you can use the `autocliv1.PositionalArgDescriptor` struct, as seen in the example below. You need to specify the `ProtoField` parameter, which is the name of the protobuf field that should be used as the positional argument. In addition, if the parameter is a variable-length argument, you can specify the `Varargs` parameter as `true`. This can only be applied to the last positional parameter, and the `ProtoField` must be a repeated field. + +Here's an example of how to define a positional argument for the `Account` method of the `auth` service: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/bcdf81cbaf8d70c4e4fa763f51292d54aed689fd/x/auth/autocli.go#L8-L32 +``` + +Here are some example commands that use the positional arguments we defined above: + +To query an account by address: + +```bash + query auth account cosmos1abcd...xyz +``` + +To query an account address by account number: + +```bash + query auth address-by-acc-num 1 +``` + +In both of these commands, the `auth` service is being queried with the `query` subcommand, followed by the specific method being called (`account` or `address-by-acc-num`). The positional argument is included at the end of the command (`cosmos1abcd...xyz` or `1`) to specify the address or account number, respectively. + +### Customising Flag Names + +By default, `autocli` generates flag names based on the names of the fields in your protobuf message. However, you can customise the flag names by providing a `FlagOptions` parameter to the `Builder.AddMessageFlags()` method. This parameter allows you to specify custom names for flags based on the names of the message fields. For example, if you have a message with the fields `test` and `test1`, you can use the following naming options to customise the flags + +``` go +options := autocliv1.RpcCommandOptions{ + FlagOptions: map[string]*autocliv1.FlagOptions{ + "test": { Name: "custom_name", }, + "test1": { Name: "other_name", }, + }, +} + +builder.AddMessageFlags(message, options) +``` + +Note that `autocliv1.RpcCommandOptions` is a field of the `autocliv1.ServiceCommandDescriptor` struct, which is defined in the `autocliv1` package. To use this option, you can define an instance of `autocliv1.ModuleOptions` in your `appmodule.AppModule` implementation and specify the `FlagOptions` for the relevant service command descriptor. + +## Conclusion + +`autocli` is a powerful tool for adding CLI interfaces to your Cosmos SDK-based applications. It allows you to easily generate CLI commands and flags from your protobuf messages, and provides many options for customising the behavior of your CLI application. + +To further enhance your CLI experience with Cosmos SDK-based blockchains, you can use `Hubl`. `Hubl` is a tool that allows you to query any Cosmos SDK-based blockchain using the new AutoCLI feature of the Cosmos SDK. With hubl, you can easily configure a new chain and query modules with just a few simple commands. + +For more information on `Hubl`, including how to configure a new chain and query a module, see the [Hubl documentation](https://docs.cosmos.network/main/tooling/hubl). diff --git a/versioned_docs/version-0.47/integrate/building-modules/11-structure.md b/versioned_docs/version-0.47/integrate/building-modules/11-structure.md new file mode 100644 index 000000000..255893257 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/building-modules/11-structure.md @@ -0,0 +1,95 @@ +--- +sidebar_position: 1 +--- + +# Recommended Folder Structure + +:::note Synopsis +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. +::: + +## Structure + +A typical Cosmos SDK module can be structured as follows: + +```shell +proto +└── {project_name} + └── {module_name} + └── {proto_version} + ├── {module_name}.proto + ├── event.proto + ├── genesis.proto + ├── query.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. + +```shell +x/{module_name} +├── client +│ ├── cli +│ │ ├── query.go +│ │ └── tx.go +│ └── testutil +│ ├── cli_test.go +│ └── suite.go +├── exported +│ └── exported.go +├── keeper +│ ├── genesis.go +│ ├── grpc_query.go +│ ├── hooks.go +│ ├── invariants.go +│ ├── keeper.go +│ ├── keys.go +│ ├── msg_server.go +│ └── querier.go +├── module +│ └── module.go +│ └── abci.go +├── simulation +│ ├── decoder.go +│ ├── genesis.go +│ ├── operations.go +│ └── params.go +├── {module_name}.pb.go +├── autocli.go +├── codec.go +├── errors.go +├── events.go +├── events.pb.go +├── expected_keepers.go +├── genesis.go +├── genesis.pb.go +├── keys.go +├── msgs.go +├── params.go +├── query.pb.go +├── tx.pb.go +└── README.md +``` + +* `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. + * `abci.go`: The module's `BeginBlocker` and `EndBlocker` implementations (this file is only required if `BeginBlocker` and/or `EndBlocker` need to be defined). +* `simulation/`: The module's [simulation](./14-simulator.md) package defines functions used by the blockchain simulator application (`simapp`). +* `REAMDE.md`: The module's specification documents outlining important concepts, state storage structure, and message and event type definitions. Learn more how to write module specs in the [spec guidelines](../spec/SPEC-SPEC.md). +* The root directory includes type definitions for messages, events, and genesis state, including the type definitions generated by Protocol Buffers. + * `autocli.go`: The module [autocli](./10-autocli.md) options. + * `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](./06-keeper.md#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). \ No newline at end of file diff --git a/versioned_docs/version-0.47/integrate/building-modules/12-errors.md b/versioned_docs/version-0.47/integrate/building-modules/12-errors.md new file mode 100644 index 000000000..969ce6e75 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/building-modules/12-errors.md @@ -0,0 +1,56 @@ +--- +sidebar_position: 1 +--- + +# Errors + +:::note Synopsis +This document outlines the recommended usage and APIs for error handling in Cosmos SDK modules. +::: + +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 [`errors` package](https://github.com/cosmos/cosmos-sdk/blob/main/errors/errors.go). + +Example: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/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: + +* Must be greater than one, as a code value of one is reserved for internal errors. +* Must be unique within the module. + +Note, the Cosmos SDK provides a core set of *common* errors. These errors are defined in [`types/errors/errors.go`](https://github.com/cosmos/cosmos-sdk/blob/main/types/errors/errors.go). + +## Wrapping + +The custom module errors can be returned as their concrete type as they already fulfill the `error` +interface. However, module errors can be wrapped to provide further context and meaning to failed +execution. + +Example: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/bank/keeper/keeper.go#L141-L182 +``` + +Regardless if an error is wrapped or not, the Cosmos SDK's `errors` package provides a function to determine if +an error is of a particular kind via `Is`. + +## ABCI + +If a module error is registered, the Cosmos SDK `errors` package allows ABCI information to be extracted +through the `ABCIInfo` function. The package also provides `ResponseCheckTx` and `ResponseDeliverTx` as +auxiliary functions to automatically get `CheckTx` and `DeliverTx` responses from an error. diff --git a/versioned_docs/version-0.47/integrate/building-modules/13-upgrade.md b/versioned_docs/version-0.47/integrate/building-modules/13-upgrade.md new file mode 100644 index 000000000..18484c68c --- /dev/null +++ b/versioned_docs/version-0.47/integrate/building-modules/13-upgrade.md @@ -0,0 +1,65 @@ +--- +sidebar_position: 1 +--- + +# Upgrading Modules + +:::note Synopsis +[In-Place Store Migrations](../core/15-upgrade.md) 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. +::: + +:::note + +### Pre-requisite Readings + +* [In-Place Store Migration](../core/15-upgrade.md) + +::: + +## Consensus Version + +Successful upgrades of existing modules require each `AppModule` to implement the function `ConsensusVersion() uint64`. + +* The versions must be hard-coded by the module developer. +* The initial version **must** be set to 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. + +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: + +```go +func (am AppModule) RegisterServices(cfg module.Configurator) { + // --snip-- + cfg.RegisterMigration(types.ModuleName, 1, func(ctx sdk.Context) error { + // 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. + }) +} +``` + +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: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/bank/keeper/migrations.go#L11-L35 +``` + +## 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, `v2bank` is the script that migrates the package `x/bank/migrations/v2`: + +```go +// Migrating bank module from version 1 to 2 +func (m Migrator) Migrate1to2(ctx sdk.Context) error { + return v2bank.MigrateStore(ctx, m.keeper.storeKey) // v2bank is package `x/bank/migrations/v2`. +} +``` + +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/v0.47.0-rc1/x/bank/migrations/v2/store.go#L52-L73). 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). diff --git a/versioned_docs/version-0.47/integrate/building-modules/14-simulator.md b/versioned_docs/version-0.47/integrate/building-modules/14-simulator.md new file mode 100644 index 000000000..d3483cec6 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/building-modules/14-simulator.md @@ -0,0 +1,134 @@ +--- +sidebar_position: 1 +--- + +# Module Simulation + +:::note +### Pre-requisite Readings + +* [Cosmos Blockchain Simulator](../core/12-simulation.md) +::: + +## Synopsis + +This document details how to define each module simulation functions to be +integrated with the application `SimulationManager`. + +* [Simulation package](#simulation-package) + * [Store decoders](#store-decoders) + * [Randomized genesis](#randomized-genesis) + * [Randomized parameter changes](#randomized-parameter-changes) + * [Random weighted operations](#random-weighted-operations) + * [Random proposal contents](#random-proposal-contents) +* [Registering simulation functions](#registering-simulation-functions) +* [App Simulator manager](#app-simulator-manager) + +## 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. + +### Store decoders + +Registering the store decoders is required for the `AppImportExport`. This allows +for the key-value pairs from the stores to be decoded (_i.e_ unmarshalled) +to their corresponding types. In particular, it matches the key to a concrete type +and then unmarshals the value from the `KVPair` to the type provided. + +You can use the example [here](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/distribution/simulation/decoder.go) from the distribution module to implement your store decoders. + +### Randomized genesis + +The simulator tests different scenarios and values for genesis parameters +in order to fully test the edge cases of specific modules. The `simulator` package from each module must expose a `RandomizedGenState` function to generate the initial random `GenesisState` from a given seed. + +Once the module genesis parameter are generated randomly (or with the key and +values defined in a `params` file), they are marshaled to JSON format and added +to the app genesis JSON to use it on the simulations. + +You can check an example on how to create the randomized genesis [here](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/staking/simulation/genesis.go). + +### Randomized parameter changes + +The simulator is able to test parameter changes at random. The simulator package from each module must contain a `RandomizedParams` func that will simulate parameter changes of the module throughout the simulations lifespan. + +You can see how an example of what is needed to fully test parameter changes [here](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/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. + +Operations on the simulation are simulated using the full [transaction cycle](../core/01-transactions.md) of a +`ABCI` application that exposes the `BaseApp`. + +Shown below is how weights are set: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/staking/simulation/operations.go#L19-L86 +``` + +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. + +Here is how one can override the above package `simappparams`. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/Makefile#L293-L299 +``` + +For the last test a tool called [runsim](https://github.com/cosmos/tools/tree/master/cmd/runsim) is used, this is used to parallelize go test instances, provide info to Github and slack integrations to provide information to your team on how the simulations are running. + +### Random proposal contents + +Randomized governance proposals are also supported on the Cosmos SDK simulator. Each +module must define the governance proposal `Content`s that they expose and register +them to be used on the parameters. + +## Registering simulation functions + +Now that all the required functions are defined, we need to integrate them into the module pattern within the `module.go`: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/distribution/module.go#L180-L203 +``` + +## App Simulator manager + +The following step is setting up the `SimulatorManager` at the app level. This +is required for the simulation test files on the next step. + +```go +type CustomApp struct { + ... + sm *module.SimulationManager +} +``` + +Then at the instantiation of the application, we create the `SimulationManager` +instance in the same way we create the `ModuleManager` but this time we only pass +the modules that implement the simulation functions from the `AppModuleSimulation` +interface described above. + +```go +func NewCustomApp(...) { + // create the simulation manager and define the order of the modules for deterministic simulations + app.sm = module.NewSimulationManager( + auth.NewAppModule(app.accountKeeper), + bank.NewAppModule(app.bankKeeper, app.accountKeeper), + supply.NewAppModule(app.supplyKeeper, app.accountKeeper), + gov.NewAppModule(app.govKeeper, app.accountKeeper, app.supplyKeeper), + mint.NewAppModule(app.mintKeeper), + distr.NewAppModule(app.distrKeeper, app.accountKeeper, app.supplyKeeper, app.stakingKeeper), + staking.NewAppModule(app.stakingKeeper, app.accountKeeper, app.supplyKeeper), + slashing.NewAppModule(app.slashingKeeper, app.accountKeeper, app.stakingKeeper), + ) + + // register the store decoders for simulation tests + app.sm.RegisterStoreDecoders() + ... +} +``` diff --git a/versioned_docs/version-0.47/integrate/building-modules/15-depinject.md b/versioned_docs/version-0.47/integrate/building-modules/15-depinject.md new file mode 100644 index 000000000..96dd5dc39 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/building-modules/15-depinject.md @@ -0,0 +1,126 @@ +--- +sidebar_position: 1 +--- + +# Dependency Injection + +:::note + +### Pre-requisite Readings + +* [Cosmos SDK Dependency Injection Framework](../tooling/02-depinject.md) + +::: + +[`depinject`](../tooling/02-depinject.md) is used to wire any module in `app.go`. +All core modules are already configured to support dependency injection. + +To work with `depinject` a module must define its configuration and requirements so that `depinject` can provide the right dependencies. + +In brief, as a module developer, the following steps are required: + +1. Define the module configuration using Protobuf +2. Define the module dependencies in `x/{moduleName}/module.go` + +A chain developer can then use the module by following these two steps: + +1. Configure the module in `app_config.go` or `app.yaml` +2. Inject the module in `app.go` + +## Module Configuration + +The module available configuration is defined in a Protobuf file, located at `{moduleName}/module/v1/module.proto`. + +```protobuf reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/group/module/v1/module.proto +``` + +* `go_import` must point to the Go package of the custom module. +* Message fields define the module configuration. + That configuration can be set in the `app_config.go` / `app.yaml` file for a chain developer to configure the module. + Taking `group` as example, a chain developer is able to decide, thanks to `uint64 max_metadata_len`, what the maximum metatada length allowed for a group porposal is. + + ```go reference + https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/simapp/app_config.go#L226-L230 + ``` + +That message is generated using [`pulsar`](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/scripts/protocgen-pulsar.sh) (by running `make proto-gen`). +In the case of the `group` module, this file is generated here: https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/api/cosmos/group/module/v1/module.pulsar.go. + +The part that is relevant for the module configuration is: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/api/cosmos/group/module/v1/module.pulsar.go#L515-L527 +``` + +:::note +Pulsar is optional. The official [`protoc-gen-go`](https://developers.google.com/protocol-buffers/docs/reference/go-generated) can be used as well. +::: + +## Dependency Definition + +Once the configuration proto is defined, the module's `module.go` must define what dependencies are required by the module. +The boilerplate is similar for all modules. + +:::warning +All methods, structs and their fields must be public for `depinject`. +::: + +1. Import the module configuration generated package: + + ```go reference + https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/group/module/module.go#L12-L14 + ``` + + Define an `init()` function for defining the `providers` of the module configuration: + This registers the module configuration message and the wiring of the module. + + ```go reference + https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/group/module/module.go#L199-L204 + ``` + +2. Ensure that the module implements the `appmodule.AppModule` interface: + + ```go reference + https://github.com/cosmos/cosmos-sdk/blob/v0.47.0/x/group/module/module.go#L58-L64 + ``` + +3. Define a struct that inherits `depinject.In` and define the module inputs (i.e. module dependencies): + * `depinject` provides the right dependencies to the module. + * `depinject` also checks that all dependencies are provided. + + :::tip + For making a dependency optional, add the `optional:"true"` struct tag. + ::: + + ```go reference + https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/group/module/module.go#L206-L216 + ``` + +4. Define the module outputs with a public struct that inherits `depinject.Out`: + The module outputs are the dependencies that the module provides to other modules. It is usually the module itself and its keeper. + + ```go reference + https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/group/module/module.go#L218-L223 + ``` + +5. Create a function named `ProvideModule` (as called in 1.) and use the inputs for instantiating the module outputs. + + ```go reference + https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/group/module/module.go#L225-L235 + ``` + +The `ProvideModule` function should return an instance of `cosmossdk.io/core/appmodule.AppModule` which implements +one or more app module extension interfaces for initializing the module. + +Following is the complete app wiring configuration for `group`: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/group/module/module.go#L195-L235 +``` + +The module is now ready to be used with `depinject` by a chain developer. + +## App Wiring + +The App Wiring is done in `app_config.go` / `app.yaml` and `app_v2.go` and is explained in detail in the [overview of `app_v2.go`](../building-apps/01-app-go-v2.md). diff --git a/versioned_docs/version-0.47/integrate/building-modules/16-testing.md b/versioned_docs/version-0.47/integrate/building-modules/16-testing.md new file mode 100644 index 000000000..7de77ec89 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/building-modules/16-testing.md @@ -0,0 +1,142 @@ +--- +sidebar_position: 1 +--- + +# Testing + +The Cosmos SDK contains different types of [tests](https://martinfowler.com/articles/practical-test-pyramid.html). +These tests have different goals and are used at different stages of the development cycle. +We advice, as a general rule, to use tests at all stages of the development cycle. +It is adviced, as a chain developer, to test your application and modules in a similar way than the SDK. + +The rationale behind testing can be found in [ADR-59](https://docs.cosmos.network/main/architecture/adr-059-test-scopes.html). + +## Unit Tests + +Unit tests are the lowest test category of the [test pyramid](https://martinfowler.com/articles/practical-test-pyramid.html). +All packages and modules should have unit test coverage. Modules should have their dependencies mocked: this means mocking keepers. + +The SDK uses `mockgen` to generate mocks for keepers: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/scripts/mockgen.sh#L3-L6 +``` + +You can read more about mockgen [here](https://github.com/golang/mock). + +### Example + +As an example, we will walkthrough the [keeper tests](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/gov/keeper/keeper_test.go) of the `x/gov` module. + +The `x/gov` module has a `Keeper` type requires a few external dependencies (ie. imports outside `x/gov` to work properly). + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/gov/keeper/keeper.go#L61-L65 +``` + +In order to only test `x/gov`, we mock the [expected keepers](https://docs.cosmos.network/v0.46/building-modules/keeper.html#type-definition) and instantiate the `Keeper` with the mocked dependencies. Note that we may need to configure the mocked dependencies to return the expected values: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/gov/keeper/common_test.go#L67-L81 +``` + +This allows us to test the `x/gov` module without having to import other modules. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/gov/keeper/keeper_test.go#L3-L35 +``` + +We can test then create unit tests using the newly created `Keeper` instance. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/gov/keeper/keeper_test.go#L73-L91 +``` + +## Integration Tests + +Integration tests are at the second level of the [test pyramid](https://martinfowler.com/articles/practical-test-pyramid.html). +In the SDK, we locate our integration tests under [`/tests/integrations`](https://github.com/cosmos/cosmos-sdk/tree/main/tests/integration). + +The goal of these integration tests is to test a component with a minimal application (i.e. not `simapp`). The minimal application is defined with the help of [`depinject`](../tooling/02-depinject.md) – the SDK dependency injection framework, and includes all necessary modules to test the component. With the helps of the SDK testing package, we can easily create a minimal application and start the application with a set of genesis transactions: . + +### Example + +Here, we will walkthrough the integration tests of the `x/distribution` module. The `x/distribution` module has, in addition to keeper unit tests, integration tests that test the `x/distribution` module with a minimal application. This is expected as you may want to test the `x/distribution` module with actual application logic, instead of only mocked dependencies. + +For creating a minimal application, we use [`simtestutil.Setup`](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/testutil/sims/app_helpers.go#L95-L99) and an [`AppConfig`](../tooling/02-depinject.md) of the `x/distribution` minimal dependencies. + +For instance, the `AppConfig` of `x/distribution` is defined as: + +* https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/distribution/testutil/app_config.go + +This is a stripped down version of the `simapp` `AppConfig`: + +* https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/simapp/app_config.go + +:::note +You can as well use the `AppConfig` `configurator` for creating an `AppConfig` [inline](https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/slashing/app_test.go#L54-L62). There no difference between those two ways, use whichever you prefer. +::: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/tests/integration/distribution/keeper/keeper_test.go#L28-L33 +``` + +Now the types are injected and we can use them for our tests: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/tests/integration/distribution/keeper/keeper_test.go#L21-L53 +``` + +## Deterministic and Regression tests + +Tests are written for queries in the Cosmos SDK which have `module_query_safe` Protobuf annotation. + +Each query is tested using 2 methods: + +* Use property-based testing with the [`rapid`](https://pkg.go.dev/pgregory.net/rapid@v0.5.3) library. The property that is tested is that the query response and gas consumption are the same upon 1000 query calls. +* Regression tests are written with hardcoded responses and gas, and verify they don't change upon 1000 calls and between SDK patch versions. + +Here's an example of regression tests: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/tests/integration/bank/keeper/deterministic_test.go#L102-L115 +``` + +## Simulations + +Simulations uses as well a minimal application, built with [`depinject`](../tooling/02-depinject.md): + +Following is an example for `x/gov/` simulations: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/gov/simulation/operations_test.go#L292-L310 +``` + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/gov/simulation/operations_test.go#L69-L111 +``` + +## End-to-end Tests + +End-to-end tests are at the top of the [test pyramid](https://martinfowler.com/articles/practical-test-pyramid.html). +They must test the whole application flow, from the user perspective (for instance, CLI tests). They are located under [`/tests/e2e`](https://github.com/cosmos/cosmos-sdk/tree/main/tests/e2e). + +For that, the SDK is using `simapp` but you should use your own application (`appd`). +Here are some examples: + +* SDK E2E tests: . +* Cosmos Hub E2E tests: . +* Osmosis E2E tests: . + +:::note warning +The SDK is in the process of creating its E2E tests, as defined in [ADR-59](https://docs.cosmos.network/main/architecture/adr-059-test-scopes.html). This page will eventually be updated with better examples. +::: + +## Summary + +| Scope | App Fixture | Mocks? | +| ----------- | ----------- | ------ | +| Unit | None | Yes | +| Integration | `depinject` | Some | +| Simulation | `depinject` | No | +| E2E | `appd` | No | diff --git a/versioned_docs/version-0.47/integrate/building-modules/_category_.json b/versioned_docs/version-0.47/integrate/building-modules/_category_.json new file mode 100644 index 000000000..8dc3f9a94 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/building-modules/_category_.json @@ -0,0 +1,5 @@ +{ + "label": "Building Modules", + "position": 3, + "link": null +} \ No newline at end of file diff --git a/versioned_docs/version-0.47/integrate/migrations/01-intro.md b/versioned_docs/version-0.47/integrate/migrations/01-intro.md new file mode 100644 index 000000000..b27b294ea --- /dev/null +++ b/versioned_docs/version-0.47/integrate/migrations/01-intro.md @@ -0,0 +1,15 @@ +--- +sidebar_position: 1 +--- + +# SDK Migrations + +To smoothen the update to the latest stable release, the SDK includes a CLI command for hard-fork migrations (under the ` genesis migrate` subcommand). +Additionally, the SDK includes in-place migrations for its core modules. These in-place migrations are useful to migrate between major releases. + +* Hard-fork migrations are supported from the last major release to the current one. +* In-place module migrations are supported from the last two major releases to the current one. + +Migration from a version older than the last two major releases is not supported. + +When migrating from a previous version, refer to the [`UPGRADING.md`](./02-upgrading.md) and the `CHANGELOG.md` of the version you are migrating to. diff --git a/versioned_docs/version-0.47/integrate/migrations/_category_.json b/versioned_docs/version-0.47/integrate/migrations/_category_.json new file mode 100644 index 000000000..add3887b8 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/migrations/_category_.json @@ -0,0 +1,5 @@ +{ + "label": "SDK Migrations", + "position": 6, + "link": null +} \ No newline at end of file diff --git a/versioned_docs/version-0.47/integrate/modules/_category_.json b/versioned_docs/version-0.47/integrate/modules/_category_.json new file mode 100644 index 000000000..6038c7662 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/modules/_category_.json @@ -0,0 +1,5 @@ +{ + "label": "SDK Modules", + "position": 7, + "link": null +} \ No newline at end of file diff --git a/versioned_docs/version-0.47/integrate/spec/README.md b/versioned_docs/version-0.47/integrate/spec/README.md new file mode 100644 index 000000000..3aec92297 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/spec/README.md @@ -0,0 +1,25 @@ +--- +sidebar_position: 1 +--- + +# Specifications + +This directory contains specifications for the modules of the Cosmos SDK as well as Interchain Standards (ICS) and other specifications. + +Cosmos SDK applications hold this state in a Merkle store. Updates to +the store may be made during transactions and at the beginning and end of every +block. + +## Cosmos SDK specifications + +* [Store](./store) - The core Merkle store that holds the state. +* [Bech32](./addresses/bech32.md) - Address format for Cosmos SDK applications. + +## Modules specifications + +Go the [module directory](https://github.com/cosmos/cosmos-sdk/blob/main/x/README.md) + +## CometBFT + +For details on the underlying blockchain and p2p protocols, see +the [CometBFT specification](https://github.com/cometbft/cometbft/tree/main/spec). diff --git a/versioned_docs/version-0.47/integrate/spec/SPEC-SPEC.md b/versioned_docs/version-0.47/integrate/spec/SPEC-SPEC.md new file mode 100644 index 000000000..b9d90bc47 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/spec/SPEC-SPEC.md @@ -0,0 +1,60 @@ +# Specification of Specifications + +This file intends to outline the common structure for specifications within +this directory. + +## Tense + +For consistency, specs should be written in passive present tense. + +## Pseudo-Code + +Generally, pseudo-code should be minimized throughout the spec. Often, simple +bulleted-lists which describe a function's operations are sufficient and should +be considered preferable. In certain instances, due to the complex nature of +the functionality being described pseudo-code may the most suitable form of +specification. In these cases use of pseudo-code is permissible, but should be +presented in a concise manner, ideally restricted to only the complex +element as a part of a larger description. + +## Common Layout + +The following generalized `README` structure should be used to breakdown +specifications for modules. The following list is nonbinding and all sections are optional. + +* `# {Module Name}` - overview of the module +* `## Concepts` - describe specialized concepts and definitions used throughout the spec +* `## State` - specify and describe structures expected to marshalled into the store, and their keys +* `## State Transitions` - standard state transition operations triggered by hooks, messages, etc. +* `## Messages` - specify message structure(s) and expected state machine behaviour(s) +* `## Begin Block` - specify any begin-block operations +* `## End Block` - specify any end-block operations +* `## Hooks` - describe available hooks to be called by/from this module +* `## Events` - list and describe event tags used +* `## Client` - list and describe CLI commands and gRPC and REST endpoints +* `## Params` - list all module parameters, their types (in JSON) and examples +* `## Future Improvements` - describe future improvements of this module +* `## Tests` - acceptance tests +* `## Appendix` - supplementary details referenced elsewhere within the spec + +### Notation for key-value mapping + +Within `## State` the following notation `->` should be used to describe key to +value mapping: + +```text +key -> value +``` + +to represent byte concatenation the `|` may be used. In addition, encoding +type may be specified, for example: + +```text +0x00 | addressBytes | address2Bytes -> amino(value_object) +``` + +Additionally, index mappings may be specified by mapping to the `nil` value, for example: + +```text +0x01 | address2Bytes | addressBytes -> nil +``` diff --git a/versioned_docs/version-0.47/integrate/spec/_category_.json b/versioned_docs/version-0.47/integrate/spec/_category_.json new file mode 100644 index 000000000..e77f62999 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/spec/_category_.json @@ -0,0 +1,5 @@ +{ + "label": "Specifications", + "position": 11, + "link": null +} diff --git a/versioned_docs/version-0.47/integrate/spec/_ics/README.md b/versioned_docs/version-0.47/integrate/spec/_ics/README.md new file mode 100644 index 000000000..803e0c89c --- /dev/null +++ b/versioned_docs/version-0.47/integrate/spec/_ics/README.md @@ -0,0 +1,3 @@ +# Cosmos ICS + +* [ICS030 - Signed Messages](./ics-030-signed-messages.md) diff --git a/versioned_docs/version-0.47/integrate/spec/_ics/ics-030-signed-messages.md b/versioned_docs/version-0.47/integrate/spec/_ics/ics-030-signed-messages.md new file mode 100644 index 000000000..991314905 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/spec/_ics/ics-030-signed-messages.md @@ -0,0 +1,192 @@ +# ICS 030: Cosmos Signed Messages + +>TODO: Replace with valid ICS number and possibly move to new location. + +* [Changelog](#changelog) +* [Abstract](#abstract) +* [Preliminary](#preliminary) +* [Specification](#specification) +* [Future Adaptations](#future-adaptations) +* [API](#api) +* [References](#references) + +## Status + +Proposed. + +## Changelog + +## Abstract + +Having the ability to sign messages off-chain has proven to be a fundamental aspect +of nearly any blockchain. The notion of signing messages off-chain has many +added benefits such as saving on computational costs and reducing transaction +throughput and overhead. Within the context of the Cosmos, some of the major +applications of signing such data includes, but is not limited to, providing a +cryptographic secure and verifiable means of proving validator identity and +possibly associating it with some other framework or organization. In addition, +having the ability to sign Cosmos messages with a Ledger or similar HSM device. + +A standardized protocol for hashing, signing, and verifying messages that can be +implemented by the Cosmos SDK and other third-party organizations is needed. Such a +standardized protocol subscribes to the following: + +* Contains a specification of human-readable and machine-verifiable typed structured data +* Contains a framework for deterministic and injective encoding of structured data +* Utilizes cryptographic secure hashing and signing algorithms +* A framework for supporting extensions and domain separation +* Is invulnerable to chosen ciphertext attacks +* Has protection against potentially signing transactions a user did not intend to + +This specification is only concerned with the rationale and the standardized +implementation of Cosmos signed messages. It does **not** concern itself with the +concept of replay attacks as that will be left up to the higher-level application +implementation. If you view signed messages in the means of authorizing some +action or data, then such an application would have to either treat this as +idempotent or have mechanisms in place to reject known signed messages. + +## Preliminary + +The Cosmos message signing protocol will be parameterized with a cryptographic +secure hashing algorithm `SHA-256` and a signing algorithm `S` that contains +the operations `sign` and `verify` which provide a digital signature over a set +of bytes and verification of a signature respectively. + +Note, our goal here is not to provide context and reasoning about why necessarily +these algorithms were chosen apart from the fact they are the defacto algorithms +used in CometBFT and the Cosmos SDK and that they satisfy our needs for such +cryptographic algorithms such as having resistance to collision and second +pre-image attacks, as well as being [deterministic](https://en.wikipedia.org/wiki/Hash_function#Determinism) and [uniform](https://en.wikipedia.org/wiki/Hash_function#Uniformity). + +## Specification + +CometBFT has a well established protocol for signing messages using a canonical +JSON representation as defined [here](https://github.com/cometbft/cometbft/blob/master/types/canonical.go). + +An example of such a canonical JSON structure is CometBFT's vote structure: + +```go +type CanonicalJSONVote struct { + ChainID string `json:"@chain_id"` + Type string `json:"@type"` + BlockID CanonicalJSONBlockID `json:"block_id"` + Height int64 `json:"height"` + Round int `json:"round"` + Timestamp string `json:"timestamp"` + VoteType byte `json:"type"` +} +``` + +With such canonical JSON structures, the specification requires that they include +meta fields: `@chain_id` and `@type`. These meta fields are reserved and must be +included. They are both of type `string`. In addition, fields must be ordered +in lexicographically ascending order. + +For the purposes of signing Cosmos messages, the `@chain_id` field must correspond +to the Cosmos chain identifier. The user-agent should **refuse** signing if the +`@chain_id` field does not match the currently active chain! The `@type` field +must equal the constant `"message"`. The `@type` field corresponds to the type of +structure the user will be signing in an application. For now, a user is only +allowed to sign bytes of valid ASCII text ([see here](https://github.com/cometbft/cometbft/blob/v0.37.0/libs/strings/string.go#L35-L64)). +However, this will change and evolve to support additional application-specific +structures that are human-readable and machine-verifiable ([see Future Adaptations](#futureadaptations)). + +Thus, we can have a canonical JSON structure for signing Cosmos messages using +the [JSON schema](http://json-schema.org/) specification as such: + +```json +{ + "$schema": "http://json-schema.org/draft-04/schema#", + "$id": "cosmos/signing/typeData/schema", + "title": "The Cosmos signed message typed data schema.", + "type": "object", + "properties": { + "@chain_id": { + "type": "string", + "description": "The corresponding Cosmos chain identifier.", + "minLength": 1 + }, + "@type": { + "type": "string", + "description": "The message type. It must be 'message'.", + "enum": [ + "message" + ] + }, + "text": { + "type": "string", + "description": "The valid ASCII text to sign.", + "pattern": "^[\\x20-\\x7E]+$", + "minLength": 1 + } + }, + "required": [ + "@chain_id", + "@type", + "text" + ] +} +``` + +e.g. + +```json +{ + "@chain_id": "1", + "@type": "message", + "text": "Hello, you can identify me as XYZ on keybase." +} +``` + +## Future Adaptations + +As applications can vary greatly in domain, it will be vital to support both +domain separation and human-readable and machine-verifiable structures. + +Domain separation will allow for application developers to prevent collisions of +otherwise identical structures. It should be designed to be unique per application +use and should directly be used in the signature encoding itself. + +Human-readable and machine-verifiable structures will allow end users to sign +more complex structures, apart from just string messages, and still be able to +know exactly what they are signing (opposed to signing a bunch of arbitrary bytes). + +Thus, in the future, the Cosmos signing message specification will be expected +to expand upon it's canonical JSON structure to include such functionality. + +## API + +Application developers and designers should formalize a standard set of APIs that +adhere to the following specification: + +----- + +### **cosmosSignBytes** + +Params: + +* `data`: the Cosmos signed message canonical JSON structure +* `address`: the Bech32 Cosmos account address to sign data with + +Returns: + +* `signature`: the Cosmos signature derived using signing algorithm `S` + +----- + +### Examples + +Using the `secp256k1` as the DSA, `S`: + +```javascript +data = { + "@chain_id": "1", + "@type": "message", + "text": "I hereby claim I am ABC on Keybase!" +} + +cosmosSignBytes(data, "cosmos1pvsch6cddahhrn5e8ekw0us50dpnugwnlfngt3") +> "0x7fc4a495473045022100dec81a9820df0102381cdbf7e8b0f1e2cb64c58e0ecda1324543742e0388e41a02200df37905a6505c1b56a404e23b7473d2c0bc5bcda96771d2dda59df6ed2b98f8" +``` + +## References diff --git a/versioned_docs/version-0.47/integrate/spec/addresses/README.md b/versioned_docs/version-0.47/integrate/spec/addresses/README.md new file mode 100644 index 000000000..61db3aa93 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/spec/addresses/README.md @@ -0,0 +1,3 @@ +# Addresses spec + +* [Bech32](./bech32.md) diff --git a/versioned_docs/version-0.47/integrate/spec/addresses/bech32.md b/versioned_docs/version-0.47/integrate/spec/addresses/bech32.md new file mode 100644 index 000000000..2c15bac68 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/spec/addresses/bech32.md @@ -0,0 +1,21 @@ +# Bech32 on Cosmos + +The Cosmos network prefers to use the Bech32 address format wherever users must handle binary data. Bech32 encoding provides robust integrity checks on data and the human readable part (HRP) provides contextual hints that can assist UI developers with providing informative error messages. + +In the Cosmos network, keys and addresses may refer to a number of different roles in the network like accounts, validators etc. + +## HRP table + +| HRP | Definition | +| ---------------- | ------------------------------------- | +| cosmos | Cosmos Account Address | +| cosmosvalcons | Cosmos Validator Consensus Address | +| cosmosvaloper | Cosmos Validator Operator Address | + +## Encoding + +While all user facing interfaces to Cosmos software should exposed Bech32 interfaces, many internal interfaces encode binary value in hex or base64 encoded form. + +To covert between other binary representation of addresses and keys, it is important to first apply the Amino encoding process before Bech32 encoding. + +A complete implementation of the Amino serialization format is unnecessary in most cases. Simply prepending bytes from this [table](https://github.com/cometbft/cometbft/blob/main/spec/blockchain/encoding.md) to the byte string payload before Bech32 encoding will sufficient for compatible representation. diff --git a/versioned_docs/version-0.47/integrate/spec/circuit-breaker/README.md b/versioned_docs/version-0.47/integrate/spec/circuit-breaker/README.md new file mode 100644 index 000000000..1956704bd --- /dev/null +++ b/versioned_docs/version-0.47/integrate/spec/circuit-breaker/README.md @@ -0,0 +1,16 @@ +# Concepts + +The intention of the circuit breaker is to have a contingency plan for a +running network which maintains network liveness. This can be achieved through +selectively "pausing" functionality of specific modules on a running network. +The circuit breaker is intended to be enabled through either: + +* governance +* for emergencies a special subset of accounts selected by the state machine +* a transaction which proves the expected behaviour is broken + +## Pause state + +The basic pause state of any module simply disables all message routes to +that module. Beyond that, it may be a appropriate for different modules to +process begin-block/end-block in an altered "safe" way. diff --git a/versioned_docs/version-0.47/integrate/spec/fee_distribution/f1_fee_distr.pdf b/versioned_docs/version-0.47/integrate/spec/fee_distribution/f1_fee_distr.pdf new file mode 100644 index 0000000000000000000000000000000000000000..b9995386957cb1be5fe5c21551b0645009063045 GIT binary patch literal 185175 zcma&sQn3}=x^TW8fI-42U!FX=@Y09J=ww8$~idyB}M3W`R z=G`Jx?A{G!m=b1l!uMa#&{)1g|78A@xvgyW?^L*-r?G5pP{*!(2Otgzxi!foSI$4B zs%B`Z-VV1$S92rx4X`?Breh2V{B~+;H^ZioL|=gzQ!qy%H|^UFD9jw#Paq<56qv~# zm!{_}8*7NUDV<{%&zANq3QADW{Jet5+&C#;_!8q&Na3iF6<}T0N&KKgPDj%y zi%U_6Gjm}aHXtP4iZHW7das7MC56Lo7};FZs!qLjjyu2KYCe$0*u(en#%z%DF`7%| z9S3V@$L~SRD)1#qIvgcpTzqegqk80yQx8vL{5=Zw!t>^6Tj{%)N|bux&~q_QkT5NS zM#wlbnGyEkjrVwU4?1p>H@|+%{<RWHV~%3?+^)f8c>ss-2ysY?m{@lo#!h9?reBcV%`O}A;n9;X zAxG?kl|b-EX`1jlWNfyeT|jWPOgUS|SDpvX%3Zeu#-miSt*05X;*B-PtH%@1(tO>I zK-u-eGCEh2Y|nF*GP>{f`L#$ZykJj~=T}@wxZMM+HXM1?=^Rn-%|=0I@>QyMN`@v!zKhmw*6#Tk~EQ@(>#(q z4mcvaYU=YBfBr+I?Sq>`>RjWd7*Wb7i~kkl2dKWC0IpJFO1RWJ)yG}u)?7_8 zOcp>;Ad{E=@y_804n%{bpsk2$wV`;-!r+Bw>+^f4)-cPULm8gByfEh2o~;TqfV*)x z0+SCFBV;zn608Ht`b`k3XK*$_nOzgcqpTS}3-CyNmZF*$iQQ7E#LmXz2(jnLz;KTD zI52Oy7@KlFnMV6w&iAU0hqO6QYeMUB5-%_hU%a+bTtFB%-Uki+$58denPI!T=`><& z=imyj!izCY&E2W%Yf^k(8Nm8o_`4y+k7vh78;AmQS=yw@PO_Kti>SOSKO{p~mAJX%ie$CvD$wULu&o9AY$U^$?1{-AQUv z=vmeNL})5$zQBe^p~_QLjyf}%G{V#$-9XgTipnslz#?mDlcW{VV)DpW z#(B5b^p5ki@Jmj$J4cO1dpXQNRqmS_jvRrLC6LJ~FadAYxYRZYlmH%%6j_3Uh$VQ= z9hPZtyAlSUrui7JyyZxM)n`dDsI(@qgCP$WhkPM29r9uxs3Ss42MN2S_tGGP)kK ze>8(|&(WJbwE9KH=8h5LoARTRS8QK1E3=@nW#^d_T_f%4C$_c(fh+?CjI%V(9UmWD^QXuw1&uK=8! z4XqnS{QQ;4w9ll<@}kLIZ4E5)2uWQ2JXJZq-ieqbWd28l_P9DUkdn3-{sC)OTC71JF!BGTs=MlEZ@uFzplFA{%DjO zujBnI7ASs5l?)pBt+s%k!&t}1Rd>?ttq3IJX}WgL4Wx^Gw(ClG8*;>16<)58L0$7i zVlZEixF3Duya;LE5}y=6$wMNX+swZBiJPW(Rf#^`+{HpSaM(KFc4QclxD`%&esFSK8=+VVf*Apylv)eo9R z8VdP7DfEU1&WQR-Qk4@=(p4ojwV%Eqg@Pad_vZkH(rFnOGkeqjZ-@VR{a<%*u>Nm= zurPCS{G!;x_~X8)IOaHxZSEs8D`RSJA&6<|qiD;8aVep$OffgG ze@C8`imgzd!uM>fyj$N15+UE>gNA45}9+a9w$CybrKb%ojPn#F#4Na1(D3VK)+@$H)5p0zZ5IxqIvBSF-Eu1}`vRvB5FleY&uHHaNq^|Lp8n zmkyu56&Ld9&FKyj41|Yxr9Thndyepm;>x(#5YY2|u}zo?Be}S45w;$an>27tPn;xH zuE$kB06Mu|P+9dRL7cjufD6_L@Y!U+pu-Cf#M;d?q7<9m)xBm)y2wf9W3w$UNlC6YMVtzm~ z1(Xi@dibTnW4oajm&yM^#u(>Q;MHcMF300+1tvmb0!GTbe$&v!EVqHDKDnY>;(GyI z;hoJ){zL>8 z@H=agJ`Vm~^m^0|B=h}nyp>8 zz1c5-3}fY|$lhZR`Ixl|+M(9WWOrBKHV4^5_fH@)2s1Q)N9Tw_uMxGHp*AAoE;8}g z(yfgUcDr3S1o|coY9h!s8zYM`--6wPa_cFjKG_iIx!X5U2TT%YSC4@EHSH@e=r-!R z{ndzfge}0li~IJ?Zl49EFdyIh#G`lp?$Uq8I;6od`mGhRF*KQ4c_wyF=M#LtXbjvE zQeMGSN?BPtW9H798C?UWJ@PWkN6^>LoQD64w6J_?fuxA@GRy8RabJ2>SG}FI;~mVK zgYTau-dEwfmxSlRc_?JxUW`a$O?LLqPWnDb-sr}ntg?3#2DtT*ykeB7|2x^N<8!Os z1g>Y1*N^$!@g(0Nm`&3rCIW(6tG-F2U=|e6JvNXC!xn3^jWYw)0N56=h~jlH&9tAT zBHuc%LiSvTN3Z^!doOEK)!(->RG6}h{0}w+qEZ1^HB&XE(MaEgMWruGOhJvADd7ka z;=uLA2Ftr7;CG~o?Rs#?+!$S)eBgc8&O1nbyNI9Dk|sj2e{BVL1Yt2yK1&~i6WD4D zZ*qR;UYtPxbh7sFJa~>yP_edr;E+!rkB>nm21)-!(@=2)&K1e<_ObiXq*1#Fiy2=N zR$*NanLm*=mzG!f1W~&iOCL4k>ZxZvu{`)m?^Y>rCTXAkJbi>Z0qDj}wp|*{&dN_? zp8^9|LGtXtA&lsly~vlgB}yYcCFBHMQ1VBpT_@cZjx&Kgh#SBRG_5$udH6{Jgm_;=WgC$Jx^1;Y&Yx(=8S(dEHzu+BJ z;X#1}&=(A{82NKdMU~EmI57lcrSqhXiK^g{9z=;+JeR0C#m*gARzIXjyAF#G-Xgvc=Yl6pQpA6-A~-fVN@+Y%AAMFBNQYR z+-kMFBiqSSQG~P2?WVT%Ctfk)%?*LQ7nLQLC+-zdZw4taS*9K*meCmk5G_igcIOXi z>p|Uaom9jMM}E96EXvqQEPSSLZ{Ka#I9IU1`(T^GWFB-+s#Pp|h)DznlX8UNa-LhS zARiOufsxPJ;h-$Rt9wg4&#DYV{mQOw5dl`VH8UD}G)*?WlM@m)64!$xx@10rzo+?06C09A~KqD{($W z(!xrY(vR+fSE`=JxGD|h>bSBm$Ma6~>EVi$%%_-CBUJ`r$JvN+b>ry^_26*>PnShr zN4tomSZ$>UG1vUNz<^t!aq6WA>0=^b`?t8*&gO8X6SqjWPTATLqfEkK8zK>AKX}^| z2JR8FW43vvIwZ zIGkh%o{L!#W*PT0bT_4>EG=(bF_K9KKeQ+U!IlU_) z3~yO7e&%+n(Ru%Bj8sw72Dz+{6Lrq;UjX3sF=w#EaMrQ`L;l1vZ(3XqJ{vV^Z<69A zV;Yuz=4@4?Qx<#wV2kOCfS8Te^eZzw;V;zG^ecb;+_m$uB0ZaN!+ zF&>Msp;@p=;g$A0EF)aNgalkL%@?s~U5S}c6O**D=pXUonnSzQ45;>L?t9nFAXp>X zd}FHz8Utp$M+WNm?gQeyLuRBz>ICo64OAQ~5qm?6ASjc4zF(*VkTJ>wnsaA| z%IVrir?W!pfa0b@j8KGWC}SU&A-OL>@#9*7--GQKK^xa*wj4p@ft`zRBMsIzaXmRT zAp5`CF7KIN9cSLjPfrZY@d>O2L!yM3-l{WIAu{GKSA|7}RQkmo6s7xnRV(8gg~vWx zkh8sQz`1qd%_NA?N=?FtFI~sAGG2Ga-ZjEP%g>aYw%8EyPYNmsDhUMW$cLflAPhX7 z=~PnPZh0XBk6=>E{pZw{UPPcke-8wAXYhJ5uD4(nF*!bShNK&B00E1M)WUq>b8-x- zmf;TJz<#(PfAu9T$4S3Cld?Mf*$*4h+2o~{D5)ZH#pCgnK4MP#`J=;Jk{4_jSNd*z}!kTt~D(q+_1n%JjI zp^_W%KbE;dKD~>A`F>3%cQ7K@t?Fx-+!cQ~6fI%alpP_+x+=sPR!NPTZqA2hP0w=UsCyRyM5C5&^nq zLooWJ#@{r^8X016r_S|zlA~#mYHtoCN6@Rdk(lHogZsnc{TfS90ePzXQf}&Xc;&+mR1oSMZ}y z3?N?mMj_CJ(Jxm?!N0)Qj{w^L-ASDPp_7=o*x3KuPHNNEaoAzU@PBK_WI(EoU8i&C z2G^w9vWG1lB-xA$(kr|O;VtH~Wlg5FLg^XsUkF>3WQo3F{}W;A$wh{^5cikov10?% z;8)RBTFIPyTX)|+m5F2_S}y%eILFmR&%s~%r^ThO=j-F&L_>h0wYY8T;)OW#k{eNC zj%;cdbs`aZ*m@2vxvf>!WqQ?_1V%B{thxAc#0+gpj_D4U{SLQf<%#S2w^=s1+VPe3 zwKu_*ny6`tbAq3zp57&|(+>GZmc^99sWw`bm$rX<>{D=-dRCCySn`EUZ(*C*<4{6RcSGU=V#es8 z0c3ua-tleqk_Y`;PtFW2(m10%&m+(uQ10DDVw^-QP)ET=JNZS;r0h?Cfn%#^3za1ye$IhRo9){_}CpxHm#YBt{Jf zGG%D(M&(LjCR{{Xgz7(DFXJT0HgzcqzeM9MRFXe7B82Fh8Ty3Q>|w7j_KCM z03yqOE#3^Ki^Do&VU-HDo&{o0v`_i-z`!G7%(QuQ3GcdRJ zR^=pO_H0_w5IUauWs`1Vf3w8I6llIyqSv!fm_O;F^V|QqMCUt%@td)8qf@|&8i0}X zthOe@ylPh}Pd|NEx|Kh+O#&@POa{s8Wri{4SN4G2HW2xvov!?2Us(2d`1~g?kkAi5 z-v8Wk?z46Ibgskr@;%n|83Ls2TG&NUfDas<0tFaT_I2J!HdH!6oqJ0RK$GHmeKr=T zAB)nhw59&uMo$S#Ar794G=KHBZahnoH}IMtvM$pn$gj@S55A6pD{wBFzIW}%Ve)89 z&Aud&Ymck(Cg{HD;p?DM8rFKd3Q}$-j@K};9fQB6o%cT&xJ5F5vyY*^sJH$`YTwbw zZ_#*4L|KoAB$C0!XFS(ai!k9t4Pnycbj&Bqz~kvR zz1t;Puk}1lUU2!`ZX?r3H?Q{&#w`=mIz%i}y(L(!LFta8UI7~QHrQp2pMqi8A1l?ASPeCi z3!5HU4`O-C<{S%ZIyMkM=#6waVK_%k@eQJBN!&~xJ9`xcYvra3Z}I8yu(kHoI)hO( z;oNsp-xjF9_$fc^%@rKw>GVvOTLjwXSrm!jWnzZWdDtP~i2xF?B$LF@7HZb=rqIHQ z?qc6*JwtX^=Jp*znj~(c@!B2N!{<0-*6Tu--aKJ8*6a#>1WkCrXqkC|>UeTK>VxZ5 z2#1V0nl&=KXRK%ugtd)%aw)Old!%7No1C&Of_~GF`Uod{{i_a*^#!!W>7q)94;Uw) zcwP}7W$9!RcF#|Z&CuY>4>dNMUqgX)s(u9pi^~xioB+7(dk9s7rUN-r)mPtc*<%6M zE-UjQNq7vMXO&ucV&J1ga;^%6#E~da2@l|AM#sfryxtx^biUs4T}We?vcJy+V%iH_ zHm1=|VWeJdj0EZbQhm5g8}*+uhF6e4#~Cz-qZx17Vpp7c_B6iHTc5xn3@K_`+}&A zIfWkoTRkK(0w3#Cal2)BsHW+%%?2M4ad;{*vP`?F5dxgoYeGxR21>>z<=>GWlQE|1 zU*oxv0s}yp6XmPLQvrHpSd%)?FO>>hd?H8CG8>;3Q^R&AJ)U7Se($rkPxQk*iFwN{?LlgmHE*UcIRmHN33Yu(6Fg}@=^?j(9P#;1i&v!KT zjoe(-<^z)7_=CJrM?wn}Auf@9!<3q*A%1YqTe3(}05Po#;aLnQW)-bKX$O(I)FdDe z3lqJB`+Mmdudu<81MTyb5A4B4>oEt;4-_ET@@CV>lyaflqFIyv&fDWYcML2=FaX9& zZe&6~n0(|Cxw)x3N#dhC3j1Ki^-J&^kY+$^TRz{Y0c_P86BSN*T)~vU*%5Vy=piuZl95I%$1~S_feS;?xosC}RM4SMEz3P-*)O3fgQ5-{V^hAYU)R{SDM`CICNK5?fDE7=d6 zg`QrF0EDjLq!#3nDGVsm`56VB4C)uIb?hl&9(z_2RuLN_Di>(gneTSGe}|9kW-`Oh zWG{yXpdMhuE#tzH_V)?IW>NxenpOg(>>7nGNlt~rp%)7MnV?3dG7kIJG=uI0y`6QC z@O%K}0QN8ZI0Us&fvM5wy!>-=2#&hzrs9q3V%WLm?+6bYxs0Fb>&rC3YMx#K7Q7EK zG*@KN!VA&9&`1h=m-W!)&_Ny7*-m<=D>qxQ}l73;f+Hjxk(?riuK z#RYH!*%7)iJ~WpR%T?s=5fMAHO6rBq0P?2s8)7{5T?b3Gj3!Gx_{X!yrEpsf7%2kA z0i8~5wPT^ftsA5yIYdlJ^laaqv}0)Hx^)&l>6><@8&NDXIk-SPoN?RC z$E9DBs{G@6qqoD7dS5s;mTdm~Hs?)zR^o-+D@Wl6qMRyRQzhEdn=WO-1vhMeBV;lD z62BTqsv0jjx1)>3UtLwoL+ejum@qWv81mU^1bYyK+8;Dg-I#d1!zjye?2r6en;3%-LgYUU7=a+i? z8W0ovn@6m!4wF)*`xGmDa;vVVcW5+g9{ zWV@{Ls@b5R?I;8a7`rXv5t#n}47vGM_cdjmiP!l71wB=n-K__RDU~Oxq_Jw_HI1>K zv%}k%yJkItvnVNdLFYHvxBj!=XtE1bRYxAFViLo&;IIp*!&m z+ZYk-YTY%0?a%A|+phjLpaa9-Epx&-9P!Nw1x-#5eGszIh6S8%2;=aZe+DkU>2!&u zW0{w8Lw6qoeL zp2&VJdqE<7Try{QVl+;Q*T8%V*!2L34|+PAlWHqkLQkg)CO#bp^@}%8o@~qB5f@gq z-f1C>4wxCot13;qS;ny6p=k)Nf!$9jSjZNy+@q{U%a4i|omb8dd?tqs zG5_D~WXQ%i&wb+&VK1VjL#NKF#UbVkhh?)?f7#tgcL)tBb1>zwMCJx4t3 zQP{IA-F)IhmU|p*S{A)YlLMm@+Ll=gSNh*pd|W~|3Z&P-?arX6{c26Co$HvpRy}Wo zlyE2WAn>h!b;{C}&%rdXPdlF3m=v1-3OHHUb=M=>Uh@!x8kA>7Bo2A^5 z2Cg^`J}QdACa_T!bbekOTuTO*y@_gNwA^?VEdw81c3F3+{<(HU) zd}>^k*X!xSE)^3TLPgW_J{*+td_lBo{z9u#Dl_=qnuij}t8BiM=w2qDCW_;27+wyO zyQ2Ljk_CyoWRSzgnMmLSu5&*J;*Uz9d_D2UI3m>!MUa)^BZm3DT$c{TYWT11*?G}o zG)M{cj&Z)wX@U~6o;*8&h^oEqpk*xV6t?_kM-9=gneEDfrT`x^F~uWzTzd~7G)K}K zDp6fIInJRn9)0W{JZiS`C+pnDza)LT&FA;#WJg~Y>K9>rgt4y~2moUUPsMNo!NAs^LSw~ST@5cIB~(nc?|rO_Zf zeS`Fj1C7EeAu1-Ln}jCDtWIzsBUx+%nUT0JQb~qK5CgssWj@*&<9|q*(edcsFX;eF z7#krbl;9lt^=w8w&noo-2ssNx4gLw6x5A@C;A%N_QF3&~+hx8H|hXoCjQ7)C3iV3D9{ zw4LO}!BZ_@WnFrn4RNmWt-r%yXz6~QRi3ri)_)SvAO>P%I_FRd9S(T{TXm$dc=Vgd zo6Jb2V(V$!mG2*RUG5-)z=>@#Q@{#&X1Iz zd?1yq#3l(!2oZH8h){#bjI1NVd^trPB0$?w)4=xYos%ZQophs`0}?bfs8M{TjsJ?8 zcbRfCPBG<4Aso#xqhOfSSGnpKie~|0W@#Ns5SQpM9fz;%2(18fv;D>VK>DuMGcz|`!)j8Qo7fv` z^yi8r8c6G`rSjVz^IL!^mfyJ##f9lm#=d;Avm9O+x#|Yq`N@ot3OtNtkp3dT@OmP6 z>$wj>$W_@AAHnz9I3uKhN4B_ZcQM&}#5PC*#A~~fH@SA5yHsX{(l`|7lu}vI93P;I z&jW{oW|!X5+annF!rTFPXLiC7M6euu#!v?1P71@QV(!k9X^s>B;;)0qI=MXCyNqRRrL z{an%&PRisy3HqxeME7@H7c%G-`nu8M+V~UEG<^Xxojuoh*ZE#dc4NcEP)oSm6x-NQ zxE^xu9?~Cz2+ez}sW1<+oY?5V_Kws0B@IZF8-#s6*Qvx~^tMQo2t>QYKl|_!HUTgC zawRPp0Tv$wPP+h8ubC$pB>9<_XHc~507NR{a{RAQesoJ&ere2{P_UNH8iAE=&e0W@ z(k%->cC?31vYmyPE$7VvF_^s4qJ5Z}@`t}JWCR|Ouu{T4pFjybN z9;AV`mSO9hsZ~AlCK+a8CX{4o&?)$GJl@^yc6)y9VRIY}4Q#taac!(7iWm*u*DSh4fcc~@;A zf_Se|VD92Hoo2LxL7-D87qPO+toXZGu_;LG6`Tk+Zdm*a8x844f=fX5b^2dn82W`b zTKfhChbwQ6JQy~C?-|^43b?`wBb*;1MWEJ8Q_ANt%Hgk2>N1{@&s%Kbu~g@8Fm|@Y zWZ+O!zV-*DqLWCqe;PRzgR`Wz~ zMyca=fUJ}Jh~l9x?nXa>rx;8KlUegHxIE2a_3zMBI**}I2`lzxJ`$*NrkKX)6R6qS zfipyFr`njjNR+Mr!LIk!!@%jI*&O!Qx?c+y8wy(iDj~9JdT0yK-GMD~~s|q34m(2Ia?1~fPos|dPl6{F5 zK|ON|C0RfJY#%q~Mhz>+)-BhgVPtI{|YfwG-=_KRd|c))@2e%jpbyO% zEEqPbS;6t(DHpHa&liri8bcJ#aJ}Z;EXjmPz4Swmx!b=zgm?Wz6U#3zfo;x>W~k&v z(NDi~Ss>hjy*$7fkXoAgSEt*wWJ{XB$Gz!zdCAIn?BP-Da(vNcQ--*bjZlykk`g7!fxJ;FL0`O8fb0QDpIHWPV~A}J$MpTio;jWTz(U6DArwC;{T zOr$tGDr?N%b;z?hq`rfHo!fmcS*Gy}=-O_S4mYbh&9CcUUkwe9@nl9uACahcbfpj} zJ1r4dGJZJ@?g43KxZz#iQD{2Jv82L_P{5L=?{$r9%1!73rE^u{;EP4+aRRGj>uWVS zqDRVFKvLhq2_(-)QiyQ$9Yhysi9^S#(32<7!BC|TKynj{an?Yz#$M3ED8J?ssd0+M zeXtj<$wj!GJ~;<5brSE7e@fSw3xHa;5vcXDvC{O{yo=3ry~Z`TPoIyx@f>EANhRk~ z8^2waw=BlVqd6_R{WE-r9nD)eiV%;frjeMtWS_
(w`o4Ytm1lYA76?R0$v(9S0DXBH~N+}MaOrH>-A@NWd5|js$K_H|Yh;rg5&4n<8 zvEd#8-TNNip_H&lahhS5h+3|bN+pasmZB@ib6yG8{gzV6MjfrAX0~YFRm`D7H)}6! zk9v*T1^bN-s4Ldyjk6(7q}qLcIvA@*TS8WZAYZ6D$oru%TO{osj*b(fqJ8;k>r;_B z=9JnQ8M~l_Q`LE=+?)2lubhrCV#19VVb7F~T2;!9)MGKUEWM1q2`t;f5gO4n_OSQ7 zs5Ll^)Q-8gTz`*sVBRT8oy);~I%7=AqqD~5FexNMcE6ye^nKsiL+3gWu{<-M09xE_ zU{`@kTZODgQl=U()TB9iio1M)QjOUD<(KUV8*G)Au}CQxCPLnN!P@qE! za=$M(vc0oXU$#@V4>DDA`y;4m&YJXG_y%Slk@T}E#RUEpn1I;OH2PzQP;v}Ab2ViQ zl(#!Sa`lZD-L0?xsn(8al~r4UzW%0t*qX&~23=JS6xq66hBzGoUSjm>&(bB^#D4JS zyGho#g{^#o7n(N(Z0WjR`ce}S9*^N18sMvT_kq~qEz6-ZY2=Y4f@&w0LC^rw*|NKp z2~^Ac&&sN(~QYX|-4vJaAsfGpi23>}q~{(_3a(v#=n(|gN>*H%|vc0PP|K5u&4im^Dqu~> z+GAHxNeY^|`vt5ll!|=3TSW2G?b(3U=%8lIwq5Y%xV`@k$1hD3K1c$DjRJD@tOB5} zFmd~7Oqz(f%dBU<6BX;~!iivx9SgDE*HpnmvgUtq(#>w2$h!KF)*w!14)Zue zgdOYXgPpUD90?1X4S{DM2i*~YoukV++y+h->{9mzOw@)RD0mA(P~7RUJ?6PO`}QOh zwLmh~!Ng{ZfYrD#x>`7fH7`H6YQQVW^lCS!JnX6QGHJR9QnciUSBxcN(l^NIPC!em3MA(eg{#d9xmNGe8Y#a7Fo>B z{wjauKUJ`NOMB2!p_c*CgH8K20+@E1&^0_%eVJ)NAiiGP80Mc7h}JGrVRI4JbKTV`Tp4WBApB`mJVAdhziO%p*JiJd&UEU|$iDHiG)D z5+@Swb!|H*;scBeTxYzgU*Y~SN5KCH9natF@rtAnq2CIKF@bejRJRGZ?O>*+y%P_E z-~Zi6J-k>;YolnsA}C@PD`9jLaCWHkgycBRja*i=Yp1poT5&4(z8dn<|uR$yNCi)W4zJ&f~EH72i1+D{r9fzxzZYx&tlUHu-q za;2I~lo;)#b;wN}*;rU*7-sc9HTZ%iszsvPeFmTQq1M)kAh@q&dCyjha5B}2Amv3} z{l)i;-hD~&TZi)G&5H=KNWDPbE4KfH4CzA&I>mT&5aZ-#J|(DYDU2>V0^|{l;*}YI z;U;&k;!><_v8qxw)EBb;`p1~XC0IrH!$iTzF{f$1iK`wHipZQ+WGU1@1a)4HQGgko zM^Wa1;5s*+8mZ;r0?mIh!i}tDAbxcOU4%^FEZrX&Wnu=)kIu&#ez(U28hX=N7Ue?8 z6H+9X*6#+w&&X+**CKbASI=@vqLhs{amZScd8!189@-C3lR(-UE({~!yAbMy*&tY3 z!91B(V8&O&>@5-f`Z$wKSgzJQqt-3z5bhFu2s`%NkjzOVnJdb{)0u|HB*h~2C>mZ88aZ=P z-zXIs-@RPVvdds8CDOD#5)AMkeusMW>o{fOHV)hEGIF#IRWU2z@UC=Aby5-))SPd_m~Y5M_6lnc&{pJrV5EV9m=9*|Vl@F0yln!|-HA$0m9hq^)rTfuc? z^ZQ3_l&lHtbowpZM{5a9o-c>IO{8k?Em^&v&SEo=Kvc=&VLv85XE=h;4k^b42Hwx? zQ1P`8^|;!GN}tR4MLF5T)!#>pld;eoo3DZtbH;@MHm2iFg>OHDrdu;Ulv9shrFyXJ zinEnx!;}x9l8a&D`)A-!@;1@j6(4u_D#hA4W*f5@xhMnk?62Y~bGC@z8y3l$Q!yfLg>P=vFO@(=a5&Hf7$p0a!ES{y86VW7+N z%DjDhMAw*SW0VM)miSqO7rM``qlwksVOJmG*ux@*@r62Z6A6bbZJ+sK2}vMJXmg!m z^iXso55B7o{^NuA{kpFp;QuRC^#}N9C)BEx9l2%?N~Tq6gk*)QnG8U~&Vz0)Hm_Ug z3|SDIz~aMxtnP(XH9GT2E?tbC#H}jrlRwgjv`9T?&WzSFOJ5L1GtJIYhM?yo-aaQk z!OiLgM^n=%d6r>ZOtsk|=aA!nP3SqlZrySJ6n)l#ztWH)v?3BC!2pAF;!V+Kn?goq zqY;!eQ*?7Mu51!q5jFISNQuTa4R>4BVxbdb_$gDm+?TSj1YKNqiPLW=mgZVFq5YAmB{aQ_W~Je;9y26K(3ik zt}{mH5UmCYR$mdMVo-3@fYBoI=a1`(rZ z!E|(0y;BJ7)fFU}nDKM%`P=i#M1g+-FE-b=#QZQ8s^k$|-rtTe-1O^!3Fm{}m{|HJ zc*^NPK`sMY;6-F&B_qaVAd!4a%Bl`8@&3?XWBGg_(29~Z#UJOYU4q_&x#O-VQau8> ziJ^&CZN7U;C^l%dLt~Sw>XAr!U>mBQQA@F6Dq=iSB&^mvo^FWiUNJ=S<=Itzyqv-$ z#I(qKvj7W3Qs;VZIoie97vC;hwbE-F9rplF%o4sN*ebAIpj+A?SZiF0!HrjcbD);w zQ>P#y%2SifkNjW@8O!%bQK}}nF=2CnbFzvFTNP4oGy&vK2je!j!&HFjyN8p`#;ZEg zJtAa+54a0s0whs)2}sN6r11GnOP-K@@MJN(grZ3W{v7KiZ#Uy9Y>EX*8`{#r?~8R2 z*ZPf%)^VN@j5W2#SQw*6F}|`dpQ~y(Ydfl*#pevjA0krn(vNu=O25rcLeHp2u-e($ z6_X=o?sp^e#x%u09_zR)9L{IFLTv}!2EN?D)1kwT#(p&{z#XVOoSi^2#dOfWZZZ>@ zROf|*+ykPeFLNV3abtRGJn@_M98p zClJSm>VZGk4e>m>#%#IXuOcB$LT)Hgsj71*mVB3&M%*K0vs-8qahotpqsPG%4Nh$8FYxnv1#0sg`W9=7-L@LPxtsqyl#h7j6K z!_&$_U(f1f4MvJ+8b=!&&3$#_^Y!J^=j;*`$)vxW2+0ryRY}>ss8p-Fe)Jd6@~kv4 z{9Hh;fX90zs~b)tIAE)Q@kUGVQDW5A9P(?~=&!A|qx7Z@-o&rU@-HlK3m&!UW~cA0 z4VjP3fWx|rDR*={{)Eu9l|N5VvOg@Z!Vn66iHFy05Ej96z(EEO9_|CtZ^U86?x$=V z%SNUBuh}`rCiT?5virEa@M_TxHK>S2lIvD=*TQRZkJmZ<-k+hozrMA?dE@_wv2zF# z1!%H$+qP}nwr$&X-?nYrwr|_EZQIt|iFmV`KjO`1rs5*Hn^UKFu_g1=gidz@} zG71EL86EP1ID2)4l%`F0_*!iBC4;_|-@LlggDQMm*?=?ZXAi<0>WM%4kBfc|V%5dh z3tZ27tM}EJ(yQyT_!*Mi3EQd7mO1h%+da394rkn0zkSTN^Xi2e+`;J+)IYdlBXNwW zZBp@>A@fi77@hU%crBNgoUcX5D>DgFzF|{zZgVf)GMVz>0cqYel<$CM{ww z?6bg5Y6K|@_^CX)JH2GLMq!9Qw`f;3_rrXi-|~P)#Q=-|*;sXAk<$1-4^R7k`WAbl z|66`BGBEuI{l&=ee=Y-U`KP}&*${e8)oq+3V5++dcWxSNfk@H-Vghh7@hl=**HcK< z3*C}_K4zj4yQ+#gi_x=i;KGik*y+C;y&PZ3sO*wAY!+EM)^Y7raO@wd|Bf$sBM+ZX z*LJ)UhqJv~)u<$c-8R?QI_uON^1$A_*~9x$F%ZA+q*4=X9mZ9pufWNHf&aLZ4+e#) zqJej`rnuRT7VrFB&g*n{w~x%aHp>#l)T8OrtTIAI*X~)kG4a}yOEReQ(!S{U30&kj zo7xS!j;3LwRi0E;0U_VUnKo;Y8)Wg=WC)t?B572kDmR2y@XsE^ws=K1u>?P{#P&;e zEnS>}!1Tns8+DP{CqLL1ZW{rg$CgmhmL|B%F}Pc3kz4H&OfzM_%W!mH$nOl9o>+dpiuc(n^@{L*M4qhHJS&+ltV7KX zCU}TieUW&qSK~$42K-F%%*MJjZ8D|JnC{J4&t(;~xxO+yX(XlW zqYZxwtEhut)DTR6qH;QLXjAJI>fLMxd^mzc(KQ-@o4<8ZK>}3ljKZnvCPRjhery4J z#jI=`&t5P>lHgZh!LZ=GOcFJ!Ls3VZDbya%yCoZL3MtvIpA?ap^^S( z1*g>#P3OP>aoC@Hp=ruaxG(yQn~Uh@z~e6A#>3Hd8l*X%U@6qy-#ushP(%O(IfXXd z$LM8bZEEN=mD~!+Sb_w}JtDXzyp>_alS`{&EN8vwx(*KCB_j0)cTHeiG;43YRrF1=PJdo4nQ;?0>H9(=TZg}|=d1sVs>M__Tk0~(Qq z%pFW!+GDZu5rkU@)Dik0Ww=xlz{P+76YE?jmmt73ww!%)BV5=8<`id2IIDyJvk_qq zbHx>T6zxuo8rrb+SoB`CxY_TXbsE*OeO28|3EdAgtdIs2RuB#fMZXXQV`>|7inA~E zfPW;G&Ck4bRm0QZcOEIY{k(21z1PYj62S{OYu^BVxfsT1eu?+z}lZy87x}9F&mes|7ih$wrzD9MAS;q~vBjeB~I& zoPJ?dKQNH11Ic@Xwki9gGfM)U!90|jwh=qElCW4OB<|T`QgAoF~wjo%U4C<3&R7x z&fIZy8dURWkr}?=PaP`5{qYZ*fn24tu*R~YV|{QGlH+Rl<0m*N;(jZ@}K zK%pMoK8cX$_vVrv!rM%r>ui&9MqD0kW~Bbp^$(BwSpQ=66VPbdJWS`c$n=Gmtq(;+ zY4rg1rNV=P*Xk#f_+WjRD`49Tzv{rUTd=Dj)3R;5ISWW6*d(>vDUA zoJU6Uj|8Xp_t?H|z3rdrX;Ir&>gdl#ei}!nO&ce}g|)3!M#{7=+XwRZo;mhSy)XRR zJ~nhRjxCzi<0iXRHtp*+!CkYdqQp92{BfEMs5EgD9utXBASD(hq_R;1dK*PVA;#^+ zar1E&eNt>IHjl-|@=%u&g~I778j64Em9&-mCUJU(H<>?atqIVIxG{51!?zjwIRC^h zO_mQ-RhPqDxJKe;P)>~VH#Inp^Q`lB>0g!Ag78L*wQ(7VzbUxy%{*lW!K0L6txZyF zHb{-;!*CbVQ5mo0d`6J_mx-DtBSr!D>&AHR7R`fbqq|O@qPspHcrQIAqCz>c1~7f-^+Lfj?M0M9T3@y8=f9psi)pet9MqG{#{O+ zr#|Cu*U}KW7(U^DCAkh6Ng^q2MG3JWzg=JBNrG_0ItL2@K|?UqY^|X2zckf6IdBi; zJtMI{`eGXHJ_&DM&}%{5Oo|GUlBE?X6Mp*ejl`-HhX}O=Gmi_9rR34zF;jg8`e=us z+DV**!H(w?J`X|v0bPQgS$L5!8oRvDhOU(@pftLD=h z6B-$BS~ct`(hCba?x)^)fk^HzR$%FKs*=@2_s}Oulm)CgK~wjy>M9@lL4LEPz8@@e zIOdw!qj*qNKCp8<4QL=1V$g6`2_Y!aY%-B!=TVsQT z$dDSYaF2x9VdFLsqX_>|#iL!)cvvXEdLQvaz`E!Dl%$HjiFu`|^;|Cn&~N*0QHLmD zQB6yUprEe6tO~H#<(I7Hmje#eb*Cq-7yx;N`}3S6@Y4BS)0a&2-l6X36pa|!lXlO25};1C2_mQ?`7 z`L1)-UNP3?>bYC(wHxnY^^PM0!GM$-M?a}Dm=!572yC?!GD7i6!(#@BAid`x{ntM) zlacYv#b^xi;&)|AFoesaXq;G)2WDKAwHf?+Ib>oER%J(~{>&7D$g*a*Ed^`AOR#Q2W zh1$SBrK-`&AW(JMYFgG#!S(U*=R{uvgC^rYTvtr2|0{N4{0H%4W%(bX9}@v1GbaP% z|4jd-e*DjnfRUB)|0R9=|5<-AFQ5uKn=7DDhX`A`Sb?3LAn-RxT>&Enj<7cYdk91eEnT%*fcx)cgWE zf-+e#xP227{ZkVYu@a&scIP(0A8|MdQpiVVCXlU%ziAO6lQ zA@W%Zfa~w??-_oM;SgFtIkhqYt^uF~%%S72t;LY@VFh4qj3Av}-trKd1JPz?UcP8( z?Ck8O1hmP`>WkVLaEbe-7uJFDp`3s?I|5|@dntiY0$TI^${C530GDWKa(>jx1E#aL z{bLFGs`^G2Kuk`bE)I;$p`1Xv%)raX$AFWs1l|0wCx31GAl}M20ocr1e?vbb{a?*2XY<-S_rW4&t4-B-m<8zvj4{kq5XmAC|>U>@e z-cKEBuKVoV^nL}+Qr$|;dM(pC)|xEVG`arzn~?l8c%l;iBxD3-1L{;)SMzLn1H=OZ z9N8K5KX3L;?2=%?yJX7$5Ed-#Ih@b^Wr(GR-~YacTU%O{`@E z0DAkSeQuQfCSQHb!p!|N5xDsO#*{$#=I9{!zs%-eHaIn8cKJ4Z`{BLz>iqo5zTZ;( z)&>3eQ71YzG`vg8f424i#^G65TOQuW4PPF0aP-;*0KK`QU;Wfopq})R`BeziO+NNgl3vU7mG-tp=R{!xxVV7)A^3L?NZjb?eNor0xUzybezJ`I zA?t8gUl%|gq^Gd|%zUCBK1Dk^fT%P3`Q32rKB5=!djO50UjjXVs3AW@cxr#q3-|+o z`mry;Yyh-%{&4ud!YBQqNjL+=?;ySJrJsCt{%8I(*3K0_#9eBjAHlj7j9uI##knFnc z=DYefk8ajqjjjorUr_xBjbG>z`EhzD6CEE5;?!}UonDJKgIn&tnPohQ-8AdQzDaK=f)58 z3H6e=ejPn(R@Vm*pUOs78O2xGV=fq%OI*bpHaKd_eE)M=%TMw+<^S)^O4Qe;MtTCUb^9-vYA z5^AY<4F>PkSRDU?``C&nzMO1BttYK2I^%j? ze&^=&yHIS+xkxrdOtYkH-sZ$;tAO#DJ5$RnP9mlm;O8YvjDI0lnG22Rwiy*n`ZnH0 zGI&`^*k?jn&O+5dY7YsX2rLu4A_&~`^JdLMOX+TgUv;mLIvr!1?Ap-haF2_DBTsJz zyquIa;0TppwY~=<>OW9G?(eksAhJL`QvtH)B}-T41V~S!S{O(a$4@OOII9{mVb|s4 zm(uixr-+jT5>SEryFcB>6tbe=E;{K1rAtdX^3TgvsD0P%xYHHe!{qJPm;cc>kz+rY zhoTupMzch9YSA6y3Z{YFJ8 z{@yctJ@W~~-X$=ri|SkcZuq9gv=ma~coJ-hgZ!GRw8f+TMPCx!TmhIK$Q79PH%+Pi zNbOX~n$R4R2cNNc(^-S?yu%xpKY7&eK)-qbk8M0;2vwMJd_Q46`_(T{cWrv*kENXQ zvUr93>1ELJyd-hMw?!a098^ujJw9Cgd=sowB%cZSD<&6Y+t4Loe5c7_6bB& zGeFYXN!`-xK~VjJ?H37EO(8Tak`@3{xLdH9Y24JWbepCu!342%K*UO#K*Ui$d7zQr zSYLvEC2;c}i(x@pWQ}$PpGoGNin!#LQ;qv0WfT%?b?=shN&rH<9O>J{rxpyKP-1xn zh90smyNNMuA&$*IrEniHIkmDgLN*h}AhM9SrIp1u6Um%4sO==5A5=$+Tcx2m_^xSr zpr_DM;w?5D4aY~XKSO+dELM0kUwuAnV}mUjGrk^T1!$r3O8@kI5^t<;?1f^Wpx&h~ zNtChh8Zt+gTDFhkKOY^|;KI&F;IPJMm0&`L{MS=1!4B%!BbD+uxdd`XC~`UJEePn- zy@-)+ROmCz|`nUW+EPjH%y#^sv zcSCwa%0?n|S9CAho_PNmM9`9eVeBBUZwFb!7=Zv9in-^tf`tM*a0#LIp}$Y(wIFDJ zP&#qOXn+mIC_NiGrn9CR*wPCD z_;m%1q`;duM+;|UTL>k~VOIT&%7k#;v|N^Z4-vW0BMnA=Qe2}s&U~VUAicA8S`%t> zB19C=C$^e47fhX2lFAEPb!9%hwvDB%E+;5vH&H}OJ>%uCjqolDyV%fgz~9_|n;G z(gLUGEH^U0UR-e(u%ZysnbC$cb;DVm{1S26l+$i%nIh$S9gPbO_Nq&C=n--)XXMfT zXhZ%X7q0_dCd1S_hB4-tBH7Gk2se>oNX2X4y)Pzl-}WWn zfb3u>($w0q*R1FhdZV&N`+EQLLea?)R1a+=s~;b z3X0wCH+)*?!P@!x^@E$&mgfV@cqaTL$#nTlGdu2hV>(K^D2^kRWNQlO)B@1-a>W4u zr^QP`<#y9S+EUhz-GG>62d(6K6+vClMIING2>AWoM{O9t60V}{sOpJlknTas7FlSd z=a8=~E_ByqmnQ;zEF8i~7p0G=g4l}-bvehQa}1l5lIA_dP2tXD!gY#BFz;u}zWWRB zA!bz=5@Fxf6Eo?TadSC5wmD3bC^$Wx*xZv|F_tL-fcth&RtnocVer-3YGI1KYzGFi zYh_wy7EfR~#OaH-rm@wdYm(lqzrYgc)bLwj>G$@A>av zA>`c~n$CkWFu(NbqQUjil+Ri<0|A{=XQQ&`me2MqZ11;isUxq03 zqTjf2<6>JAd@sa)WphIHYy%3o9&h>wQCB(vUZ2@A|25FxKJ9P(cy zobQIOml|FgQ1`Mea}`e})9ZOydE=!4njD0rjJzHCA95EJj|XWdGpQ?!U8?UkcEILH zXICsnRTM?0_ljTOUI0;v4Y@L0y%;~yYd9#Go_fp_=q_Z1td>t!2>H)3XoQW*m z49V#Rln8=j!Dv$ddGZmMfWxD8Yl=-H{_JOa9^j{q`vrr^Rb&-SB^=JjIJj5`R9{r` z{Tbn6TB-JTxSW8$7KKmrK9?>X$)l3jVFX2J=-5!WRU)Cu#{PnX7RV3xEHZN<-{DDQ z92g~t*8H5s-Ox*fkS~@>>Q05%9XoKC5W=FfCiHVA%q6V-Z#ADalH0C-DJd#ORU|pa z$>J&zT9&>q;GP2g9`|-@dv@kMru8Z$5wt7Lni-Lw9U@LP1xeBV8XmY!tfZGj4=(g`>ruQyJkS4ArYnWIRz)K8hXUEC?vMQW(l0KVt$Du`K_KrxO;*CDfO@eYK_qar7gla@(fyO{zLji0IKaQR;qNV)^HM6swFrzgl;_;f|M=)CYrQVC|5cg`( zF5F=%_L!u3*+L_xJ) zJ)NPA^`X3s4(|t1fj=&I`O@urRlGKR@3X`7bm{70bdWTFM^qsdIv8JXo2}1)|K5gd z9ZmY$#QGexhGoVwdmDoZOeu8Sr&L`!!YDA1Y8;r>Q0>YrXBpJsbjhJr_r2rz!zvP- z{Bi2)Ll$pyn8;{&P#*Ey1tBN9a+p4RCr=JG6``{$-wOtFnX|wIzSMJIiWAQOloQ2E zLugG`I*OB*RdGRA!U2IdJrCUowL)C(jM|l^78SJA)og=C z%5=p6J1PhwjVV`_uCYr|IxV`Du#S2Bzw;}d*nE|dfiG_O4 zjJb`Hq8qf*rP6@}4blqqCsI7*mf>ZqXEr5P_)~HmDx*ZkuAbl2F!inc4_3FAfo1QH z@VPJ2Hfx3{8c8v8nVeQ4*-&=RwcS5D8;!_Sn=cuDAiPOpC?v*J20Vp*1EgWK`kU#g^=GUOY|i18k?nP@IQG-_bs^I@Ao=E;3C znziUxo$x+-6JcLOuw0`&SoZ9Hmeqh#cd-v&w(#XzKIp*}{z0f@MoV@<{K}2AYJAw` z39o@+`a}Xdl(--?1`C%wH(M(6E=2T9OwOi66-%nlcyb%TrVn z-n}GrGX^Q-=pcxGeCho-AzsC$ZVy0{ZKIh^w4R%q4P;~nS!p6BHch?nbm!8Q>4d=h z2zh5-FcU0?-F5pgRDjA^86{6`7vnGon6sw6kvPU?HePycb1NKiI68hyTMV-gB+5AqvwA-c_PIS$M7Kes5Np19uvU+gOp-TdB z7f)79nO}leDqz6L+{ksAj>-mf$1cKnx0LdorVL(hAIa68GvNk^w9B9Lj~Y-+vK#1G zDX}KY;h|IFm?X=~edk!8=E5ecupueyec;6}N3iaaXDorlZ~BE7Ti8g9Szi zux)JkqYDnsjw<$k=%I0xxJn*Vp%Zeoch?dD$6MtjpT>dfDobnUsjIDq^w+uTUt6XP zmre`r|>_dw%?ip!(149y()^9g99x#=1Elhaxcr2Rsh(rYEuEw>iX#RNXMBA1b&KUgNlx_9eYhRxg~Feu*0FqUYtr zeocKBZL+twjewmOp0;1ObzB7PnP=rw_k&N8`|88;%bKt%>Wd&J5D00)!B`thXorSd zjM7rLpX$AAr_E$*)-Y;!w?+htyd_m~cz~&q>&(ce^743Q*P&MQD3b&5Qzv3=!A4sP zpW*Vt;zkk0al)k=WsJ{j?26MHi8~0a=j8qUUIesLYJ)*E*w`sZG&kfN(hiRCe%Z+e zwlIXFIuk{3PmgW3qEuV1s2sp;kYDxzh~0XYONponU+pVG0L^#8g;6R-4F{QG8F8Qy z;hKDp)RwAdPNbC#fB9nUJJj9)!iGuJh*g3ey*nJUj3A7MEtkMdAVj_?bpl z^A2qjk!bu9yJL;ngo+>GNg@fWwqE8%S8x3kW6MMlY!`RCX2>osMMEQj-3_BuB`QuU z@5D<)j)&MOv`c%AZ<|Zv{+=}t`lrd*IQ;42*=+cYGXRc?K?dHP*0+_(&au$Io>ZE7Izxi3 z&)lffZ}M;|T#9+>vX(;z<(E6}{XSpZP*Svh1qwt7VtNv|Urro11q#eZ4h1)w-^FtO zhG%_IqgHHne4Ei2U&QA4u+vp^#ifD_ikBfO(^}q4)Zy9OjhL?8ZDiLwEr9CpzT`Z} z+&WJ&a~>2HjXEi<7085>jqA}GBlVNoCG0~mdB(K$U?!Y(;O^ZNxeN zkK+gZY1Xho_7dX)5ATt%Yi;1n+c%0jY`-9O5}}yNW5#g!)ye#_OjzF))GIroZlbK) zQ3*%Ci`pjk9|r=2?s2J&Y)2!L+5Nk)teEc;Mg7%b);Y|~6!-2btc=j0j16 zMh^(D{c1um(Wu#-F7;hCzO0Xmt{ad-gN@rT#auzOI562zkH0?U&Aqd;UeNk*t@uUS zO{Yth_==SIpdI=zd~!*;DDCmjoCe_imnsU8R3GTm9!MNgdqX&iy7awg7DDHBq9`Co z@rqXF%A}Mc=^hk3HODQ5Rop!|?bY@kF@1=ZZo+CQ>x0(Lw5C9AVcr(7Kn{rsgSJZd1z|X4 zMA>4ljW|osEo(K*2X=?0_KerA+az2m?;PsxYS03JRmb(!$pqzA0%o(T9W+ph04-Kg z#iFA2rg)~#H9Uhn6+EECAQF}KmYC|T=DhKx+`#pYrA8!IPd><|gvkh^ryd=hw!7^$ z+jS(t-Nh9jfO99iIoYz$h;@!iAJKgd-hEIo65+pSvhDP1bA3<^gcA+j0&UKlM0o1o zP?Up&3b;xZDB8(RGun%X`cDv#(MtccJbf3O|PQG~cL;^e) z4D-q_C+A%79@%Q2|LF39epQGK3N%&L+%L$#FL~)awFy5(q=rgh%+J-NBiKt~Z9mW9>8@9$5 z&_zU?O`kw&2(gaQ#k8HbYfeT8>rWLY0gdh+sO*O><47!n`N&ocK|LO_<4|}YfRst2 zwIWOHns^MQf-_gVxW$${6VPwEeY2Xi6Py|J4n?^Y$k2M*stR~HL zlHtuyBhF#jr){1;J^Rn@}74}Mb_Ikx{A-d`Ew#HsxS?GgwSf@h2uaE74T*# z-N~G_lHOzr?8csVJ~lrw@r2Rq*ZtzeV@TFA+r63)xMhkbaxZ8!LMoFMX7mf_7xEL|Fz5exzEn=h;jXYAx}F}}EGYZ$ z`DjZ-v%^eNONkH}HpVam54|AXyEF$eVp^w|pDkuVKk#jjTD~G^oKGw~3d60wR?0r5 zA2yySjuo>88QtHM2viy@g{jZMcGGae8`DteLb%L1ev6bE*Zcg(lt$ic$cAG3nVqT+ ztnSxm>J%RhzuoKMFlZ{uQ;F?5f1|W}XTBtzoPL}N0!nBYiilkn3GOrK89a_?T6G0U zp=ica>@)w@B!Vn^g&B1_zXqSQx=R|^wf7u>HzI;&=aR3HnSk%um>Dp~f4`3n?kBW8 z<_S5*vt@#_Q6n+H16hf^2q5pKnyjW;w09qi;N7Uyk$C;Ld1kbqU`Vvz6g7v^muq=i&VJ zN;oshM0b|oJCyD#HKlp)YN#6vE`Rru!zig`2zGQXc|~&vfdo(+1XTt)oUvTVD-f2d zt#!g;s8JGo(JpR<0d9gWyJ){_{dLpM?Tgj(i4^ZGQ8wtiW{CZ6t!)fk{Jgx}gFt)x z%d|Q|9u))ivKp@dhg7Yxip_--i2goZz5}sSB|Td{wf@F8(n1D4r0tolD!0QQrg9hiE2CA`}^G$wq+ zHg6;$;i}Npd4KMMdxHHXK-}pJ5cEE4NhV^JufVJ;1piyYe2j&Z^&rO`VnEfB+R1=d z8+ueT3cEbwnE&%^nKy(y-KB@J!04ORf=AOo%%Cc4L8&yIPb!&|VhCl+5uFB#@kj{3 zh-U)3^wvEbWrQRI-T@9So{cPynSFu3%c*73Du!}mKcEpac~C@=eCn6=awHcqIzgYg zh_n*uCO4HU65f^8{61SlCtmYGfW(*S-Qg)JTZ7b@Pv%p|F{q?R+k8w=$}cjgHf&K_ zTNHa(G@7~;(>c{b9toG3N3dv!8c0QQP1&GPnUY`+X_Vtfk`K0oZsWQ$EiqNfcW3}` zpk8uq!j{>m!2{!kN)OZ%Tqen&c+2GG8xVzpNagx&RAs*wQVgo!j2DE@D<0k)A-Kb< zle*xUB(9f_QYv`Bi5x#Ww{F4$XUFmKnT)a4%q3ya*RevxVuL7v9~(=>nMilAOk8LP zblay#@!(Kw%>`(r4*&aIjwbIcakZfZqp0NpP|u>nYm9JT=zwoG?=*POCZY(97_A7< ztrX@)wVVU=y{XAY^p5Jfq>~2c2w_I!CpcBac2*?jXmHMc6vy(x_3eE>|e!T2Sk6jW*g zJ3R?eDU_$|7CpGVEECjJ`2~8uG;_(Ax2SU}(243vI#f~gj4$42+6P~oZ(x6_PGZw@ zLM680SWJ1@pXj(7yjMzb#`)CM45t8Jia~$208hCJr5~yI{h5R}R9f52s$BAw1qq*` z<8Y9Ik7imu9ZY5!b<>`9S8ZDR(Aj^y4}uY+-t$e!mL`VZ)1XSPaXOn}TuCjIw`Vk5 zZ;q#yY_kf3el?JDjF5>GhW;-aniIP;%n(l#<2pN_t|4@VB)NOD6*PUy+~wb}qcw#d znWEf>C?5R$erKl-JHc(jt2#dd^24SgpWq>n4OIX7zdy@Tt+~U!TbMtz|8m^QmrZee z;A%3G?6sbBaSn1lu1$ec6etuuL;9%Zz3GXaGake4xtz>LU{ghn)`xn%R4{9Uh+ zW}++Ea*pA~yjjX(J1ZVBKSgO6CvT_3Acw=ck+KM8I2}eE`*1o?$uoqX}jg+dLxynoJQLSmnksB8t7Sj4!p9;JbWSzv59`Q&M#W2vo)Tr6bm-*#G7 zV|M}XCT?^_@5+uSjEgBXR{qsUAS*MwD5llg(J&xXcAl**bL(F;;2rNur&Yl_@yG

J&~cnA5tbZ)11zsq74WfTi9b=OlE{M?6pnVE|@`Dm1~{{X`#cjaZR+{!v} zZg(ajuBmW2QnP-P^r}-lupm^zl+|@+aqiUat{{3`T`!=S7*k*t?JSX6aIEAyYktvN z7%`=fl}a{3z@dsZK{^5tRv+Roe>J(4NL^ilAY`j6%kR3cG}CKuOpvUdVDiN3K5!}z zEA3$^g^MqG&?dO(E8soyCyadM;KrtisFY|u>E4QT@0$5*4Bv?%4S~LHh5EwbbUFKL2Fe z4=aZ$Wl>^A_>I(D;$hR;@xoRO=2xNcf*o;9btNAe7n(s6J};GHb|!^lIROeD}JLfX4|k7Y^`Mu;i(RsxHtPsoR8I~4Bg zs(UvHonPF2D@F#+-MAi`+sEC)b4k9!#|++^IxDfdz+CJ~pc#g6$n)It{Hz7_$a~0m zMcec;*s}CdQ1?x4b<09^YlFWPh#Xc*d7;!8D7^JOh`Rsz2pFr=}&duztSCf+H<4aR*oYQG=VdLS5O z$q%aKIlLp83r1U;O~jz0@16YghIT!)t4?t~3XOUBC3>Vx4Wk?;q?Hz?LgxdVd@L^a;~m) zrt+Ibxbvw0A;NW}lv{L*7NDvuYj_6U?W11=lMv`Bu@0uenQ;}^?w!q-;C-%g?!!^= zmw3b&8T<%1CaS1E(OLSaCtVMOSjvab00BTV`OTAnux`KWxoq5#7|-=-j3TB$hhJE- z-g65+4xIF>tZQ8^YGl%fcG6>&u7p9IMpXB^+D#<4uf+uHz+F^PySSWqiUziQ1@1>E z1G!#e`{C_O9nA5WhDQN4KBza8e0U<(!|7koqYtOXqe~9<2u|98v|$+<2&_26phs(| z!y?39xP$&p+(V%H89Bx)>7o(3xTmp08OkSvUR`Pa=o!N&z)|1@(|m8bW83mO$yy%Y)I>T_+iwNQVqE70Rpm~!hy`f_W+14E4N|m z*nJPal1O^~+Ew%l4XMy3q$ify&bloD+Fp-@G@|pYN0J22O0$yQ!8`Sn=S#GjONKE3 zBl=K!IniQ?mFLO0wPrL(3(9mJFEvjaP1j!g&o$8{F)YzJsM!^RPNVcYg_H#Bf_+yb zQOG!UkNAGl^4UTkzjnNJ)471(`>r-v$#q_zzn^YAkb5~sRc=4O;U-$CErdb#t%~_S56=adx zWenslD~QX9#EX9I)WyUUgw72PIA(|pGrDxp$MEsa{6DG(f>r^mD5+d8Yng9xe9jl=OXd4)vJf-yP~K$uZjTS?dVrVTuEKZrjJ_?*wc8!rUt z5Tfu@m3W5}zKePV>rKdDO53S+geH9*ogHz;#iCo+uC>|GP8{B^T{;b$jPefNjxG;I zMJ_p>D=;dtil~r4Ig}pq((rWY%eVnspFxj$Mp9MjWT`U2PF)$IJPLY=oHg#nfFLUfdS^LS)>~hiYziQVJn2 z^mH!Tt1?=+#n2J;FU=_1;nR6ye5OwYY`F&jWrWuD;?g_DOl9Y?eTCzrD?l|Y-#wp_ zHb=m08QTd_Rb9`>uR=qipe;0d4hE}@Ed3~X&;+yk6$Hu3bfT439kzcUqb z9`T(SU98hIi|%C773OE6ct1~T7?QO7oHPnP=)qCnA;4;?SEdtnipbeIFk_SAgjmzD z9w6VF@JIwTm_^d6O-!C>OT1Gb1yO$%Q|rV#IINi2P_=f`iS6ERM5?}QWZ);$>oRqrk zLs%Zpwl4hq9U=<`z}@C${gu@xUWu3&$85})hhfU0OPl}2+pdqPk)ZeK36tTkiIzqp z7mIa$Xfh_I+gdioCRZjn0D1QJu};(ijxoq*~qmUF9lOp?jp`du7KH)qWce zU#_Y0f*)%`JC*kxVh|qDfBG$U=zt`PLWF~Ux<;qE9EwS4#YTTc-r)o4c+#5Y<?o?RmULv)z0e&jM=y)!9LZE7l`7s zkFFd$eq8xE476b)I~a}H(A`uY!Q?)^xw!nZ(57(-r{XyN`5JvtP%fx?!45$UqHf@Q zNU1(K5* zSkA1!*B{aGp(1-Opve73^(7&qUDL;(k}n?(LR*@9@|UJc+%u|~>Z5!CRL_@pc`U8# zvFdwCl$%#5@Uc7x`NFPq*M>TivRl7(xhR_T4)ZG80)kv_5T+yDq0Z{U2L;RvIsTro?(w-(XJ>ur46)CLM%Jq}SqVT#HQSONWb%-V;VF`16<-Y!;}G49&=Bss3wU}Ac^UI|Pd z9&J+tA#?MpXWgP666RrFp7+5ej0}}ApqIrNw0FWGm(J{bI#Wxk^97EEd75^39b832^0ryBFgbF={KZJ!^*x2M!`vLDoJD7P|}WG)t=3V=lh!D&$IQLx=}wzQnw2+Y6K_ zVxc!k)h_PeWI%2`7DmNE4S#7Bq6-7Fl|`!%U4y8)^nheA?-0ilQtr@^M`qZ{zYDgm zAIFyo^4fW~^{WUah~8p`N{w*#{m}G~PE@N4FH!DIvOX4HydDl!LM#g_G+tl+7h~tp zoLd*D+t{{k?%1|%+jidAwr$(C?d;e)wtc_OsXC3*xXoGX2dr5&<`|DW2%oRKNzg2p zSrr9O)!sZDmx=(2kar8Dc?UtPkR+=)4u%81`O+6r9)mCbq96MB3wB03H^^KalW#il zDPemWrSg(w-ydT3NP%BdeC$iBQDRO?R2x0s&p*mx7NqvwO3t;==R+ZM{plhg2xF9| z#qeFBW8we!4WgPw1lAMJpAL)~pvavd2Ls-q!sw3%?9rQ5gGv5yhelF{hlvwq<}d$e zFA;n>RW)2Kf4?l#K~pl9rRG@nu9PwqEN{^859ckxTk1yYuK^tKyu?IM;*#EH%+I8U zif+No|5DBLVV$!fAVW+Wkr@XZb6rR^di}UD^jhYR1BR!Ag2V&5NRxg0WSEd+brx|S z233?!#CY4;K@n3*5Dk#;mGm&5b>+LdP*&76;a%>cM@8Y#3MoyZHI`mE+$0?wRAd#S zI8LP@*7DiywS5!f%2vIl0OZ1sgaO!1PQ=RImw;Mj5?|ldOKei z$F+|i|H*%mp+*KjQ)?VgBiWWcs)9TF)lO}s9EMBK8O0W9Z5S`E3e9meOk|+3nx$y2 z0c&}{tJTI*jbHO(J>(sfYPzqu#UHQCkbW;BR`|}e9rl!OMv}jTG!2JlfaU7kIOxc} zdX4k@2E0mF7%eh@81qG2nt(5c-t3K4$jGVRg39_=R#?9T$K1Q`Rn}v`2_el)An=9K z(#ee$<3_$9kUEsW-t76;j``oLTGb#UrTV?5y@kExg6Rw&r0;IfM}3x6Je%MjOhbRZ z9+fDCip!*fkkE3X@QH_zg@rBH)$W>UHI}yz&w|a1+Qm{2Ke~?f#ozW}PP^z{#<3x~z z@LU{(8nHBu{6)%TlinFTT(pNC#VGFqp-oi}&cx z;(`g(%+1}tdG`*zOeZ-G0sVJ?SH)vSg&h7xIe(G~$LnmmX9l*}kd*JNP{puua-qxv z)ze0EWJIV+SqyTIXihEL&m^KDRU%Pa;;@bLvDylm7nR7yrQ&pGl%0zMpfG$+XT;WaBsOr2Xv(5=h=I z4uPqqjJ-$H!k@`Eu~Xb%*!6P^iNEt-zAm#J|q|kj@5+2`K%}3da7>UbT`~hdxZaNTb&xc#} z^r6EIf>3JiJ0azTt9avU#OoKrMrESDd003R3ba&R-oGny^25X1G;}tBD+9HJnUk&;?A{Q=slW2k2u;m0Hv;tMAO!f` z=#W?Fgt5nyD9*TI6uY1KQ_UN>!xu!;(_Hj$hiKSCrnA4~8$>0?pEp?knN!{Nw%Uxk zlil7EN`k0JCfptsEA>AxAGLMUCLBRD+*fG75AZ*)$w8%w02aD&Xr}BFSPEYP+>Toz zO&4lfk1_(RXy)=c5Y-fEcZk{)rRm);OD{f9Ni=MIi8yBY$;XCC^Aq_`L5(7Uv6lj3 zJ_kg%v_;J){p^V&Hkx{>jO@F(og0>w0=_x^!q+4;=d=j2d8n%1*=a0M{#B+8b0=8e z6>wvg5g~=q;Wr0iftl94VUW_Me5x*fo5h3;VUGsvXr~Zwwem6omDNyG$j2c(P5AT{ zsT^OYmC}6q{CL}xcpp5q-7J*F)Q$oO=KlK$b*Y8Xlp(i#_iW z44EKMdLNuC?^;eU7_C$Xl~akosV;88N<&|^HiwjJMA>(l0W^z{PI|~3>OOG+^1BNX z+7W0}%mMrQNa3-;hEP&oAdXf!@WI;tB6shJi;z{K(U&Th6E!{nEk0vFb7`v5nOKl> zk$TAUby(+(VMTOMShtdCXE%t#h5L5$sJlz&-)ypvyoZ9Kcvv1SR*n+`Dmu5C7f1w}97yKgq9tAzzpr`Ts9bm*f8sb(vUM zIsZq;WhP?h6Cs7@2^#P^qTC!$c!~!vjHJ zVBE!~(FW@*dF04I3jRSr-a!Msg^a$7jtCI}2|$s(Fp7{#;}t-;hYJB^^#HMvfm{d= zlm)mx2oKs`>n?76*+B0%`~$m-jEr>rb%&hb5?1=o3v3N|A! zuHYWRzXyrB@D`_MpyC3c79fP?FcRGb0(&SZG;l!&gawsVAYS(%k{>LaFQ$EnuT@+i zLdL!R;qQ}gS|qspEo@u6SXWmN(jG%7od9?^1aMyUwSBi|*As{U|~neS?!u&0<6OI))yGKX3IYf&D`T-8CTrR7Cjrg-{xpK?d*C zLyC$vu3NnU{_<OU*NWeP!Y5BBt-V|f}mhC8}LA0DRm1 zeEI}RLxjb%v3C5ZemUg!@Ghb550jF?>>pr)0KdJBgaDD8h3*LqTLv5XmjZumX`mYg zgGGE#V(gUpn_c~20(1W0Ajl60m{<`n)`Ws^{!nycOG25({v3P?sC>6i|HdEm7kxR9 z{oaP8?Cjs|S;y^t{7S&PhYa@qFbgKH&7$)GWl26^5&dkfAbnU^o+LU>_+P5(4W2P2 zi2NP;-4V@*W}ZQXSq$sc-ugb6BJ3Qj#||DwQnV|9y;?5?**^dc{E-PKptFH|8a)W2 zICelsKiVXqc_c@aa5#;k%!2&uKBhp)B0CIKm z1HvVX+F$pAfdvk5?icM(%zy%d`oWC^2~hVZWdd6G*o%l)Kmro|h7=uldPk&!1M2z- z`<+clQ-6^;1LPH4ASb#^7-H4rbQ*yzJ5bAEW6 zDcsy^d^ghBhCs z_z*y|onC!m+FyP=o3?-ZaeeVcISyEj*(e-KJG!EfF3FYf`?pwqsI{fREr7@VC}#2B zB5&?pm1_{?8qpYCg=ZA~I*m)#KmIye#Nq33)6cvSm2t{s(+xuVj1_%H(l{1<(?^;3`Y60=gaLZbn03S0t<*Tmnf8u9PN@)9a}db+NOutDQ8rLI`4D>}{L zZ6->skDuWwK$e3-Fq(Aa`q=Pcjhp($@t$w+rCIxO!pTY$n!?vHAWLDtXu0n_d5WjY zQ$ezeq)IXDVzme1d@N8jr{V$7uMU$dYe4V}W#6AFN5^YrCl*9*RG3*^0yz3fL*fQC zVo+fzytkM;9-Mku!e(hD^Q?!l5x7s>bJdnyVG@AyD;mzB*GiwK(KS`5$)EnQ8rz2! zUmAs+0TQ$LrI8`+22Li1Lkx}z?atl`Gj$mvsc~2Mt6L3uJ(&^#WHI`v&qkbpPYs(72^h*Bdg_~C z0&0vaEg*C6DmHe=jNA^?|Bxo;Y?-D+RNFkKM za1jL1KSos&oU+luG!9QiLHHm>;X2}j)Ra{8T#+WrFS!p^36y*) z13o$VF<`W>rv4lptL^v}@JmGf-HaS)#6$h6NT$I+k)8mY?u=qB-1$g;niWKFTPSD_s8?sLVsl1O5hS$nNm6UYeZb6& zXvUpktj5Mrp+P8b~{ zQ-Y%R2JBM`{1>)qS8!KOCNyLI^AgxJLk%$Om}o0dS9VfMe$JtbNtB=v@VT5`4~=NP zW`5@(mn-n*AfuFY_)C=Rf3wxjD#hDXQ>z%k<9L%f<$4QD^rzB?E)PW}VIa2- zcf}CtK@k2D9CnE-ILL>&>D%TumPvJER8s4 z^4pJTs;PDWsQGNnNa@H&m*zNGRjc$jc?|$2{`@YI1_lbDc{Ae8G0#gTdY;5+$xFjW zz;{yDaChs(z+$3pBwK}y#e5yy98L4CCaq}?nVjK6b7bnNCbOOKHWBg!pk0JXplT3# zp3{sE34jdTv9d*_&Es3(DKP`L9Q;m6WV)nZMyvfV1cdNAYtEIJK@h&`RX%n(!L7$b zXH4tH`|&r2GmAv=W${r;852LndNVAOcKxuxQ3g_4E5OObYsn3?a+%L8CYbg_6hx8NgSj4FV zTx`6PZET2cGBUTPqd$To@w6eh423kmf79tA>?rvyOQ?cm*J`Vz?^uydGNFQGCCQ0K zvio;+9e@K>2W=ZJ4SC{oG(jgQ`F_QtR378JSi!yMh-Ze*XE^cD0y~uup>Up<@)Wq# z;k>DXp*LYjdbsrOSv((u-aS#dzdaVBd;qDmoZb!Z7ZX?>q}-a^lJEiR?7^_3?G7Y6ChBZMdjF+##oGsyBQ=|vbApX6qr!=Q9n28j^I@9}xM?R(cU`&wZQt)aArj@&>a)3ZL~lW4Ryim2ib`+K$2W{4`ugEhd zD3>?9mCFY%L>4jaZDtCp)e#>#KDj6l8%JT`{{9v>yST-(RTzeiL=#ME@p3-3w;>-) z;-IG^PnS%jZ!cyZ2jOt%8h^&HwoWmVln7?!Q>rDs{btWUzqK$AwPLClq`j6T$kPA7 zdg;cX3;V=ZYo3rlFlI3LJkS$D&`xsX40VAQrhxk>A>KuEv0YAqgvRRbIDs(p;q)&oB**4Z>Zgji8^tr{0&#o`}&^J}Iw+?a5(_mOu3G)>*W<5pG($p(9h7 za2jnwybhc@-KEyQ73$T`A!Lp&To2kZL@3AFuZ))~29v+VyojxQm;`Zv>(Oi? zk@4$-t)KP|60ghTaeWD1^IZAcrFNKD(;QQeFtq zqlc~)EV43JmrId0BNe_z9z7~QZEtr90pCmd9&;gEEX9Q$aBNj{RrsWn zg?K)u@14_x4g(D)s8Ac$s)93cB^_mP)`u*>0^;#| zj3J2KKyHt}32a< z5Ga(iaj91koqH0jgG?|e@ea0ckHh9%%jycmyrbY}ZD3sx3;%QTI6;wi<4P;@Y$Rdi z%q7@tzh5eqSh{8Jgl{(TNN~i@%L2s+f++f1p5%S%R`1l{AG&mz&B0c^c9A^$j9RtgwH^EYJiNBjeqIxR$E2Njov->Iy$2cD8H>+w3t1M;G6f~!O6C9MBs-KJ zt@t%YJ!EBAUmOB!GuL@)fifu~`;DAG&Yc`F*Z-*V>B!<=t>8zv|G9chbFdr1zfNnZ z7lH33W!Muhl$QM$bTRGFh4*R7>*n2C+}g*4mMl*zg+l;dhO7-Tjdv>8gWwGsYs``C zrF88_V6~H8U$b^P0nb6uXIA&)nvh7cyu%TnFmrKipcBjn)59>)^?I)7c+U|q)7Ax0 z1;Ot>F4Zj(ClU=WZ(}|l^rmZIF>D97?9}bA4&9b|cq{_~H9}`lw9VQJZajRo!DMMp(>0 zUgT%v+<$(hd?AQ|SWSPgvP%{+m|%K3x9&Nl%tU*qZA7J+eTF(}C6`pSmw4^y(daOF zQ3}bdid}!IXte@8a_uzrOlGm*_0jQOUoc{wS06TeXCPc4qDVfc9|&&TGqED~*1^v{ zyO)W7`-5tl?ey2JhoiOPTJfccO2FVk=}rkOa&jZmiRYZ&Lx{+cD&k0#3@RrV?eUlQa>%Y7pLiGdq`&MZF(y4gTK zbSo%?#Ll z6+idLduJ(%#Es_9t{Y`oQoxL9P1skp_pBBOLZeyLzG&@1&X^uldAgJz5L?OKjFYE0 zuSGdimeU0JA2?PEg#{pNuh$+3-hFQyF?MIe2lVHsWZtrt4^(xx2AN?tjMI~;pVJH#&yg`@XaEZ}D zG<*0b`QGVvu9|3at!SYY}vgfbD&Sw*6Sbw*)vsptU2wJ@Xj=MhZMP$U25_)ah_)M3lh!LGi0f==@;*dbCQLs5-3>*$8(E~@dX-|} zjJtp_o($mRDjVufUb+b}XgO9SKc(^^<8_f@w$pa4X~}NM>Fp;u+QI?W(Go$x6XtGu zD^j;t>Mj;Al~{h^Y%G5&eDl-Vcs)qPEbNGiJ7jB^)#2pdQ6;b^`&Bcwm}27WN3pvR z?-P-%2SQ}wOcf3WR5)BtC$g&6+}c(K$tucv+r)cPolZ5-J@rlos?@Yk9@lcw{ZB`G zx-_*xn#u9&ocx{+38}JDvWDFDCoXt?fp#LB^@rjN$S%!2}Sc z2{ys?pch7%#KoE{8Qz>|zKSuBCVe~jLNgoR9(nWy4~zYs>>d0^%N6C$9$tI)4|2hn z<>`eIWDb^svMM|Q@;pibzkfxtN^HGSO{JGlsUgbF@6R3_gHz7cc30W2ZKh2PehUYQ z(gM)}?IRg){`%>}pXXTs^CEMfh#Wz7pU+Y5(Y*PN_exdxJzWyYt4xcj>N3d648tt8 zu)p@3QT#vlwhdHJrqMQ=(ddb8_tWS3jMSA%nh9Z=Yt&-jSeK5MXz}WDjlBG-OxrSP zy!>~ZD`Pb6KOIb1)Rdbp3$9kSaK@guk$sP{`w>cUSh3A!*RaDs%!f4%cbu|6C#s!; zX<`k)7~lumuj?Ck+efTYC_m<*da|AaN2h!cXZ|QHaFqH?qI6L&jJNy+%T6@l1TAk> z>k*h)7$baJ;r!^xM6!rXR8)lJ7e4yDNR#InoXBx*UQyajqb)JJj*F%~vCXUS3E`wxyS#a5|R}vd$%M zTtr9b$YWsTrqTdT^7toH^B~q9J1616{$BnS^v{nhC@6C^p?^~^|22K}CJwnT43cRT z&{SI4JNnwkb@Tks(>Xg+eH@}2NoY5uQjcq=zH#(|Cl7|N(dRb2**2!;mpSa|O^o*R zYjn&_B(VLd=sRm2rO(4kU%o>JH6#`_5XD4LotH{a8liRZ-;!`(%p{y~Bx4$#9T_(7 z_rop;!@%{k7;agmvSB#b5E>bgZVg|#^!`x8Rb!$Zznrc!h;Gs~*r)~irDfqxu3Vlj za*0{(F%fV@LPOb~zIZR+`8IPilKSxms3c4jxGzW@v)lhS#3P&09Nv6VVh`eGSd8Z4U5P2THmLgUS0hj5gFRk12L8~q zIk1wEXxpn$dutR8QP4MrY4urL<8M&YcGs~ZlBK0Bvyd~cz`Pybl)$Lqb8%zp*n19yml1 z)ZCR0S7iGRk2swvH>`J#Nsl%*Xa9)upqTl(Lc^97XVQz6d)cLT7Pgz>l;;2&bQUG8ieH#G0e!#$L(2zm&sJd$7Z6gUy{}A0!5{&8;`5R zvLS&0A#=RF(%hYu{PHaNmuGp-056LQrz9-VJvmAe(sFpE0?)McqQy7ECc%#wFJQ$)UM7O#VM1W|^2;MM4-QX6xjc8u=7)4) zl420=idu>ZsLbQ*ZUFC3+{jg1nfR4`8h7O6B?o*jx@-CnTM)iz%^QTP)A6&o@-V-E ziC}r&-8dHNPXhSme*c47iRcH)ihQq7UxU@C?`;(D& zxK|cdE(IGCrn(P_z>kyHSUm-1T|&f<#SWa>bUst&tX<9}J5q-)X%=8|gUw=cH6fln zwk*(SoZm{_j&kyq^7V;PA~e@{Fk6wcXpFi`Lx|1wH}$ZR+V_ob%rR#;Q#oB)JH+O4 zH3F4O7p#+(m@*%QXm^I++TBhPotJY1=h1o(b)YCy-M550H>8O8GDW>h`r>@e1Ui(m zq;0YC3d@<_A^?ZTe- z&g99AHBtMA0{TdTL9#2QIjehiz@pt(31#KoXZ6~3I?jLq?APW=@H!7JufwCvGosA@}}Z`nn+1@1$b+QdYfyHyrdAiF>1>L( zT%rHYM6h&L(4As{1ZXT-Z`)OLYB@#u02UkqweLt7(@vMzK(1E-m~HTNsYihp@q>z>cQHeZw7<+Qm#Y zB>0rOL*Hv(x@het08DIk@7V)`%_oWN;XAF`yZ;NmDGfxP`+nlk^TN$Vf_UK%>Kqlc zDRUc|OK7<_ox?LEuQCe$*7ahpMNeFLz@#_Fr5NZqr_s$4_3;i`h>HUVym082cnRpv zofUb>HmydnBpLG~Q_w5cG?(&Fa}YU2{$n)Ke@k8BTB?MSgH?~){~T=TBq^-V9WAD@ z+#R&k6j2ysMd2VgOiX$Bx|-oTA?* zW?7di@t^_osT0Z!Ys9(cN``wp>tm;*qyS{wBn*e%6lEx3%NVgVkH&aFH(1Va8@u>W z?iWdL0pt~Du?!<`FC+7Z9Q=6aCHhTX>*9!DI|6i9rfv%*v>%?)X$g1}_6peN7aKQh z?5F%Qule6pBlmyq`;H;`DhminZI(iB{+T2K=i@>JjT`f|NFUSa998{7a*`v?{a@sq z>;EF>?Ck9S!^)Y7IM|uk{^#_+$vG!G`~UZ`x6tIx?ISLw5$gqMky>j3)uCDJUo` zFB=tLQin)xN38w6cpe}!5THnzV6u`x!GJ$VRL_JYc*O9Ez@NhSz}!IrpN?1~*#RQh zH`oCI+}%VDk6)*Z0b7BPKuJkS`@h!+icbMV1qg;%f{-z;fu7suu0Y+OG5ZLLP|W)V z#2vStM2UGz!oq%jenEza4nmwmT5;io`;cN?KybvnNFj_P$amFd0StdZA1rKw!0>=f zFe_dO1CY0&&mqMHf!ZNFDnP;h`CcA^x`Yq`wQm56XKe!UDL`EzHoXvn`3>X`0|$T! z`GUA43P9R$8PfDQu}G@1jVtl$AFC@-Urc#?Pk9r!bDAllH)@wG;H1sm2C zeC+_;F9Qj>f(8$?zlHF7HNOQ6{4DAX>n*b5|4j8nJ9C|(W)wH&h=>RUcP@8V&5uq6 za_GqO3REb-xDF5T8eI6};v6)Dm+RMhaCSs(3KH!7F376(bG)4e_0z^Bk^sb1kkSy+ z!3lH-9`MG~0rf3yh_?^@4j<%~=>UKd_8Q^?mT$Kc3@VUM*dhc;;rNRQB1qyxBvj!K z^2?7LAP6K;0g7UX=oB^t^%Li36UO=N)Yt0|wnAtK-IGcP1@!g&ewqJVJA`-e=QW`J zyuV&^Vn%R&MKJSrKJ6DIHD&(?C?%kQN>ET!8V?F6GAa^;j4T9L=og^`G3-ZcLLi6D zNZv7Eh46V7;X;7z^M@MbMt~y(^6pl%>rUrf7--v{b_a$E!nNZYi90gdVI4Pr4IAmZQ400fML^k(q)I*6-d zr;lj2z3B^H$o}>7mCL((nd}vIJ%29rFVh3HgWPj)R2Z1961lJzY=rfzZ9= z)WAJqB>!d4_)P;L@mKgKQS>T*L7-Xk8}&^BXVL%&Zbi7N8Js!v!Ve$Gg8H*#hoPom!+o>w!zAfMNAe!bia)>gGcEujR zVlO*x5s^v*fO$L#oh*UQ^QNa^?@mg-N<&*@b;MIQ+@lUEu zUPe3yH{qarCA>!lyC#oJDWp>mNuDnU#jK7E?KN21DQzw=8{#GQ7Z{9G-kj=DctloH zYExw%&AK}FDrRu-vc?N@eVjZ&DPAL8feh%2)r482=~bKhs}cmdED^DrJ#>$-YBnU@ z_l|zWoTEy6$!UGSY%K1gorzog*S9*7cNe6~QFWAzdnGtM8tQ#Wj1F?TC{LO!3htkh zjLXLvh8At@!CrX64mE!7OYhk!#V=kou@j+OvZkB@)Yfc}1oly;&flYfD#{)dGejSs z@4P+|X}bJqewTkaQWfl-yamT9l}svhxVl<-*2cRQ+PGP3^N;D&2MyxKiPR}|1xLGN zmuI+$`*}A8wjHniQ;KpQq4m2g z-AjN5!6*ZvYi#QuG^9utg=-DgCnvQ7rZSN=7Y4bi$nU58-s4eVJ0tjDUKw}(EOOH* zY}AgqJ3fSMRLy_hFg)Yr^zm(edbNMtu3$f%xA?R#=`yH)SLO-PVvu+0(o|G&VpZhI zl(?MX1>m+J=BHDJj2`aCP=^)0Yy(dh)$OVI{~q4MGC z4%5{|IghAYbFz%zvV!_sit^PXc4VvhUy~CMHxlVGKWsAsm6($=;31CmQRwR zGzZYn@xAp(MGNU?x{1nMIVKU)+(T*sr}>rB!RcJ zz5ftb%>%0`FL+#01_g`O(iKP26mRU|d z+1$f-sL4CW2de{YFHYyh+UJU;3KbofIIxHaZ= zgPb1P{Y6}_zL3>S{EqDE&UwvF7ZEGPbZpgqsA8L>MXhH&8(_~|+gZMFi6)$U>vr+d z-x*Hg`rk1p;TqtUYm#?6vP=fjn0Ioz6TPd1Cu_C0zK=E*ypHsKcq!<85It%o(|rS3&cWEtZQ2$CY;QBaV6e< ztjw>ow!sC5?m+doE7V&>4{6k2##2;#BDJ#kO_Vb^o^=3hK50dj(tBQuSS;T6J)*&8 zWH8yPK*kwL<_}on0^D2zQKqW0bog4<^|$#N|3MwcLKMblFWEf~NKESc(|`bsHQ6yt zspYAm6eMh|P(&1&hJ3d}FvN2h`LayRH?_$j7#+W`M|cnC72kGpbrPKGg#CY=sJ_T2 z3Z>*fWZz5G{sa3L2}8b0S!Ec%8#+Ao-<1LN3qiMS-sF6mC|fD{ZY`RC(TmPr56j#e z_-c@QZnm#9I`@;D>}i8o%l#B3+yG72|M2R%8QCqBkG3BPKDYX8Cuzb^EebGL8@@Uo zcPBN=fwFcO`ieQj+cG(W^W=xbYi6jW55Nx+M|NLMmq0<@P3;=fB`-yFsYGKF-?~c$ z7Z-dsvx~5{SNQXQQbHR7-xxGO`7i~^XpCD!g`bEK~)$K}gP{XSH;LdV3J&8Wu0WaBY_+5sXBAJJ} z7A|~i&5{Qh;CZOB$H)G4hl%&dJ^$H=wmf1{@9J1*^{zznw_5P-Xf5|a%C_t7Xd3f|NK3sht#P)(8`--n_oYqNR z4W^n)!N)>CW86STceQhOQO&v~j;fd!4bBsoj|mmKV*pcRl%lV5I!v5+xZ!*8YpIK7 zqb>m*hFe&Von2FOZCH}PPog@GmF@7g7S#aji;ffQrQ`Ds7V;!#d*t}km*5ELWOsIk znxidAf`l%`U_Tb7CyavdJ=tQ!Wc`MzA^IiyaD)7#x`*E<6d_$bS7?r<*p*~-qtv9S z$R=O=(~jXJ|Cowa{hx(nr#9xKzOH5Dm@y#>egzG}L>haHbpP^VHb{ToF^lir+QT#p z;75!C@ea=cz-zY|(V?0q=F|J^Xl0>cJ2K48^Y4JkOZoz=ah~N;u>6nG;n8 z?=fZ}YXDQ0Zx4cLMyQEDG$7#=`al`z65-_@_bDFLVXnXUKfAhkp|9z%pBCB&Fb{GK zmPZ%SLa6L~Q6Ru-sRunrc*9tCno+|Z<7+8a0k(R$dcp~}YerHhydm$rIe)@Ke8W^n z{AcKvIUpBKg%Gj#W8*E7h@hORUjs(aF+7+2UF?&|czef|Bc-c)7)~s?9O3o`KFIi8pCyTblHdafpI5O%Ks=IE z*YUQBngyPj^_P{`m5f2mh2A>o?0rh2YGlOC2Cqz^<=OWu!+OtOa@_`PwrsW|8@1BR z8Y>h}Q3!jFw&@-%s6M=Abx9K`0W`WA-8I0n3jCw32A-_YN#Rzg4*h zWqD&HJ2s&g*=~RlS+l8raW_s9n1GT;69A|8q}w=ORB>N4SLgy zCg3V~nTbHV*ln~oY>ZVJ0KW3sUK&Mr z79`#%>X3Vka=@t2Dx;4XX#q`d|5Ansr+j9$B8;XXW6}^7C$S+_s)x7+okf0=(u?Lm zY{Y5+;IcP4n+~zuO&hl_Tja}T%3aCHfCX#ieQcjx*4QS)`fDJKC-FSF4EB>A$RfZ*kot~GB{sZ zSRKD7iI*YozU7T0<;HI6?^O=swvgE#Ss3LR((CzsUar}HS@f`-IZAcHaO*g+0t$5) zCKa0HEoSIjA*NQQSyxInx0C4mn>H@bf39~sr4J6kLSy4(LiDUAJdfFof4suVg01gM zs)k2$k4YZ&MrM*;w-Qcr3Q+^w*vswxT8pE=t{nixYxJ4f1wWIKt2r_j3~29>XNr56 z_gI67-tW@7?q5O-&q&aX8t z>gug^GEoE5pcyo6D7fOeR*K|ht)9YUHd(nwSW5Xz1lUvs@j!KIiROt=rEr@l7YOYU z4Y=-|xVm^R8)#j~0mSv9N~rD7X>(8w#m~`RkQ7l^T@yu9u^Ej%F1+@9+A`;(Z%G?t zgLsd#xY~^rBdGQT%7l9BbvL+JSDd{t3I1ALBNzX>j)rec@?cf%IUrQZQ*yZ%Vb@`n z9WH`_D69RAj4zjU|A(scbcNyy?}aHLCF404>2Qhc9((Mm8T7vpiX(9105>2IbVh za?Z0$DY?Sy+vg8;n$mZzt))6ys^XN}2S4XVRm96vK}@;LrD*;eqf=UV&m8JGb_NSe zDnW|bpO-*(iFz-7HKz-mRL=1#9KUJuoau|rO{`YqquimT2F+6sM7*JKT<`8une%;R z5hiT)ir|T?;cNy>1cORc1~RsrBIsrmGcA|QK|=_O5rtOV`N7JjcWOVW=8)%|nzd!U z))%JMpoXh)MsPT3wb`yQHC0?t%8{PO4e(eeRl$<5fr-(#3yAaR?r0$&WT@S1oaU#5 zuN;-Dg;H(Q&s|+wn^hPChwX6ChfVvtu_e>q&8144vjlBr-5&ojsCH9bBFpETDJJ9n z@)AOZK0|`2iJjwOJw?K)h^9={%rC}6t zDE-w1h012Zw!^j1zd$pZMpt`O_vz@GgR0zgi!XbsxB(JuzFb(z9TX34>H%ti$0fv_ zZYBX%Qfa=hW_hs5@T;%$zWZ6_5CM#rri3x)@1;9iT&psXExmd*>PPLSn`f3$UEy0k z`Fa`J4h=Dhrb^m2-~do<+Cz-AFn3J%hwqTIXlFrorPN%HfPtBnl!k6a7qLA-=XCa` zw`ugU?G&93kM2eCA^F zP9+AhmUIV&eKCU7S*WkpZ~iM&>0v&agt!^eG4qyIrof8*MEAJsJi8C+mC*Dx;8(RC0IyvUJMQRpj*Bnu3$U~)@33$KGQf4~TPc)N| zN!7k?ebG?1Jzh{SLTjU(_y~)E@j2R5S0Z(5OLr>=xD<|e1m6BvJWY01u=(8p#SOYQ zJe<#={)claED|%LR5fiovoFzcir(gM>hFoyAX8kA10wl*9EZdu`P#B!G|V{Z%EPlL2i_3#81ie6xkC zs3LcV4})Xp1&`pB;<-TavzFrHdWx3sU9Ckj0jJgKrDPH9~E0~p;2k=Rd;1) z>J^4B67ktyGbUntS+7hDEUjYRz2`*fY-{E0QR+ZwTiix(r|XqqTE8Hp`2tsXthmV5 zVN?~IBKoG8Mh28V9Z_(ygn^}!i69!bAZ_TL)mHupD<#?piQ9m{_TG*VVBe9{k!bH! z@KjvBr;72XgjRGZ?!;Uc%{X8z@%P`T*J9SrmFMX~L1j-t;^6M05v>dyxb~>HcW>74 zGGK0z=e1m5J!6SvPMLzDR?p8zTTh$;a2fp-u=W2KJBR2@y0Bfxwr$(!*tYGYV|Q%Z z&KujdZQC8&=IL|R`p@Va{F7R{X0>)zO`d(<*Og+B5S~UCQIrQ;rSS(9z+Mm3X%S|U zN+#ObRO{MfUOgA!e&jx=x}-BC%q~eN>(uk?dl$ZP1AjBGrLLs?)5(q<3ShUt&LsQe zQ`}DA537qfj_fB;>eUD0 zCdv8>fVbWj4KJ)k@N+boB$ z*HGULrqh{HUQKoXsV(zyYZ7!yWS-WN5Qcn_5XMlv`w8xELtiP=N)OMU9Kg(o@1Eon zc*Mn{m=?*$RUiIM`Q5_xf~<2$MbQe8tRb)Tx$>Fd=e5I%>Kot6>*3c5Bdtio84E3P zlXyRZN1rj14b(XGQoB|<|BIcb?4B(eSC^Q0uxF%c?vzU>bO=OrRN;iiW2JwwgnJHkv{ny2Z zOUn$e79CZkAeeIPel@1NHORHsdjh|`i3gU&X9~+vLd86_Ps4q8Nags|5JG2(+-K?7 z0Z+Zg_-81LnUA8B^etZ^4DObS<-6kXC5jz7P3ew=CM!e45{XTSTU_~h7zMdmzKnhY z{DVMY?4UDQ^KY=Nvt9@pN}*H)fnF&FQFvc+N&EpUe))gRs&2b3xO^Y9{X)Zy0y4{7 zU*CcGk8h$00rrK*TlYnqiR1q4PokZ9Qrt~Il95o5?$tvRwTQs6=a+>R#ocpOCaseZ z^mTTTY>QoX4q0xSIm{Zg=v?a+%|-b+PcMQ}IT`~&5qEMB@*vcmM3|~unR`1l1t!5S zz*TNo(3b@RPrAglUlsoC*a98GxL5r`6H*b#44_eY`}y%Jld;EC_q;|t`*=vI z+gSuK4v@VsR|%bn&S98SRkY&G^LAFQBAkas@i121&nxkZD29(ECEQd}&pT76$BG)f z+XOlY3u$YaOr=EWa_XWaz;dwidRtI@!lGUlOp+$cK?6vCUnWL)I5QriRC)DO#%W$r zU3NYimX-NAf&H`$$=Y#?*3{)zeC@prQI3E);s9P;IKO4u`kFGS#L|-?Ng=o0-$VzI zF182S7h|z_S>Z#_G6&V-`Qv`0wK`0nG=3;(rnu_8@1k18=?^?sIEr1j5`qc%ey`D# zf6JaW#%GOfI31)rJ$41o=qO?mgxzh6F3vD%^N}x7exPm*#+7EYp8!3e+_}D^b9mX3 zKv!1bX~|mORfK*X@W~DWY2^AyKEUbZnfIuDQcf9LVOrQy$eEu7pl|=;hwd>g&Q(6o z&WPH~ngCwKKge}>9<09{Se@T}jY2$n)+03>-=9qEnzr=k7tfUgEuOo;(>C_n*iw-^ z%GnY67V9v`qAK^=>%@0U@Ki{pdT&y4uk6_9yv^rf7+|cz(SPC#oNj?b9BK+v#nw1z zC3Mk>lbW`3*?)hZpVvSeH<)@Z$2l_4)DyR^n+tXUfL7o{{Qqt(!>8bE>TZ zt?zQn28~^eidi)N_YXIuNU`IxC{-+*DR|Mw1v0O@!m*fY@%uc zeeeu_NMT~v(gTOb9*?x$d3nDMPldE$+Z!wj+l0X7fX0wWlOa7j50k(0tUiko{BkU4PCR#9ES#xSI2pX)+6nXaH;(=>G~&i=7Wi`3C(q zIWGs%rUXIA)+=;`K!dVc(43*a(!Svz4)HXZjD46rt@rn-lrQWpOqKiBdd39saC(It znGt#_{kNRxQuY0jWz};5gjwNbDiUI!w*ZgV1g%o5uwmAZFvuFdOvR*iTYAkKw{Vly ziv0J)s0^*!8h-)z)$N|13hOgwmE?~0;;-|UqjHk1XY?DLHrMK68#+|AUnZOWxqsY4 zCb#wxK`7+8glFxO$s~SJ9cU2n9b`#hPa;jGP+_L!+b>2iCA>EjndTbbHU%}`N-i`+ zWFMGruJx$(J?F^YBtAI)ib_SkUqxeg-i(yZkTPi;^Tiy#0vyVVX@?#>ZZ~^P+-ha< zWwVC{md3M#yQNZwwXz_6BwEt|F8yEaaJ~fxeQ3Th0ky;uN?ByG;H>Tpx9>2nm0I<1 zi^F!>Cwp4Hz0(AxqS{N5@pTr~_fUNPJOn#hO zHFZ>`Rv?2*S*Y%x=i0u3z>DXn(_{eo{F<;9WzBQ*+Zc-J@YZRn^7ShuzT~dbK7w`u zM5@kd;ypsiD&B$ld*j&SALl+eqmJi#l9i4hLz^FrJ#szh2tGXpLZM^Ey(+-gRc2CO zKpr&q`75u{g4@hZt)aijfpRlsI>mN8CE{)qSkC#@1xL91lM)k!Q33kG`W!sc3Q^r_ zv%d*vPO$ewicI;SdO}G>p_1V+Rd%AVi=tI-)iY(DW?Ma9!0}qC&Cmgr8WAh5V-Su` zmRH9vy1jM#yjzi(1b+vmWG^L@vLA7}92r+~M&K*6Hrh92rCcZH=~dV{*EO?|n1i8= zkhAgs{kd% z_yOLC+<*L!Gzly7f2Bz{Isd;Q{hu(MnTdntzv3j!EX-V-|BuA*zYwOsfGcKQtU$o2 zRJqqHXYc*fqhBks3HloXqv%G;IJ!~m=e1$JU_{EmqPbBuwLQ#tzi@Y+eEnqHWKEIH zHhXVhXut607cb43r!)m>`X3U>GpWmSAQ1aERaB5rLiz^&`)Nvc2Kv`gX22mmo0h>if>5<{197zjXL}20e+uK_0WlyT^#5Q9>xKZa z2)fmw3#P#5fjNQ*&HpYYp3$!{#MN0-$@$?0!J@+k&JGOxr1NVBCBql0F_g(e6-0+> z1n1^AYXbWP)I^+Wh%|NKC(IPSHefg-e0fPgKwu*%L4`ZCEFPTzz6Tt-4$>s37+=XV z26NkK=8rRn{HS1U^ScQMUx(?@K7?Zk=NR~(K0F5u!B8e1^>KW7dK~5u#(e@|PF)qa zj3+4jn?wC=(;xhH_Ae0EI@b^GHQ~)}K%cxHHz++laqNsBC1YI@d>_sw5J=f%d0juR z5gkxo(z3ls9w^%VA)*UpAih6_0)$@*0@#?86^OqA{`Vr`(gOM=Tu_5hKSHmU=@0(# zS-KgZs)#r?mWUDy?aIxE#ZV*uXtCX^{)bi9i!wYcY1S{EeQkW=-3?dWZsxK>-Vl>B zzFe6UYhJpO@Zt-H&qa&I#hH`0$h7_q>006nh`8&esa` z5V8e=?J6$h{Aíw? zSI+4u^xo^&+fC9q>R=U-Jc9mD<`28^A8dAV*WuNvpQcZP;$*a;e=LTHX>h}%{Uaa; zr&}nX*Ia_nZ_Zcg5XL;W$jUNJJhOZVPSinEHvheq!dPx3% z4N7pGZ=E#xeH_32jz0_-etv#`^Gy8EF8AP_Mu$wmv4A z&0fogR^6AE0d9YQAPy4M>kInB;c)+*pNoQyx#f>bj9_ltTPqBdk2d$3LC|N6kb=xp zuj|+^E#WF(dqPY`LZH)gm`7nRoNv^9@K*=^>T>k42gX03YwOuWb(ENWDzm;o*5R}p zH$o54AZuoRQQyKKx*6qM+GqTKxoORK+D-`z?t z)%^tJfp|_4Uz1nfd*g4Q*FSsob15Eb$5rTC`~>xZcwP}-RkOYbZ_ByD1ol+;Vt)oG za~gTRfOD+^K7n%^cz%F$@4uBGPE_}o?%b7+=NpEpbD zzMZT%(`z2&MP5KHQnzf$6-Yja4yF@VZEM0@FzY#l(MNB0l??IMCkwZ4@!X&0nd{63 z8*~t5q3%IfddH;M&?szutSK(W84F0pyXROX4zKUR*VLuj*bk8D((X!jWJ6?yWrc-c0m}7kmEFb4RA3va6 zXhjicyIXOZRd?zt&SkSfPE{s<1jgr>qq{UsolH-El(<5&(bH}Ww?$oA)bBb4N@rl9 zO^O<#8EvXHTWei*4;8)rkZMBO9TE{bbEKYQhg*GPU6;-lko^?ozEe^7w()9vOG;x4AS{z0kQe&DxvE);vx*bH2cn&AvR7L5NC~((iV*FeW zJm*qKe^O`}6-y*B>UUgqo4ht(!7{&Zx;he1+8xhNL_>NKlVN(`@^@i=>f*JlTAds= zh7)F~n1ywVGWXnS*CI#B(muRNT$s^qeK9hAnBM*DFHkPuT3TGTE*Bk=tK&J4Uqzh0 zZ8L~fDjzG(B|v*u+1MLE5ukCcJ3D7JNh@bom>F7dk_8<(&^w!)?8IV(Q!8{_6IeXS z3FPP{_?;j}1aVP~vlh%TEs|58XM78hAfklON6bmWJ8PpN19~0!c%6TF&2x17GJK!+ z6?^MrFB)0NbdEVXNl@|^RW2K!x`e-CkV7J3FU8{YN>*-l{Qey4JWk66`Usl;dUk^h zkh2de7Cq@`?5e^8m+qb{7ObS0C;>8}%?T6+>|^e_hiG!xZQYgAryQiG9tUT1j~eiE zhS!WdjWj`a(JW-^-(ewvcED-h+B%Lb%f zwyoj_IzI_N{gldP=l%=@ow!$xLa}=zCyC2hlZ7Mb%y)uaA=40m&)UIwQu?^5Gj`%8 zhkH833uc@TXe-lA25d`2;(*nwI1IYp_)mwm=RhGL2V8W&z6e-4)8+S(T3k0TmW+A| zSs*1H>kXpe3-lUEj;4S~2C?lXANn@LFD!6Q$FO>CcO&UwF*FqtHOeMAbpLE*X!xo=LWIXm((lCaigh4F4sd4xk6Z&r@ zza^K@904F3Sp-eHU+>iQ(>3B1%P5+5Ym@No%GTUMEq~Urq-t5|F^zJMbK-tttA@MB zfMRH^ky3qL?IFj+JCmlz8aMUGQ{$!xywh%zu`1Q<>LvMLMMc^@fy*aZDXJDIbK zX6*mCi?G!*gS8xzLIK@55zprHB*XmW?=y8Pu>0KerW&rv$6A`D+X=CTm&;?PkJ4TA z8upx$eO&)64*Tk{$L+C9Ni==*G=HzmgqE+>51LD| zw12PE6{3j2WMwsZUi7dXQrhP?OmtCACgxp?X=WE@h`kFGz3M;X+lc#>BO)}T7&{-# z65%Vf`wdB%RIu`~7L3a@lq%a0Doz-GuX0k&#)^7(Iym91F++H<;a|8|192N8o3DNI z%+|t{o5_TA%(a*T?u=)?@nV})ug-gqN83rzyPZJk#JY7{Hri=bai{qtM!5 zuvl$|PWQABY4PBQ?-l1Ys6e`MbnmB&+9@u3n9?skpi@G`og}M9q6p`a2*|>`+!?7E zxGHyUCNSGFUTgd?pQ%zou9cWkzF%8nR}>Wv$?3)vYl1$B` zxocVFEv5w58ZZ5X(~H<$nMB*b012 zbr3!6oX44pAYy(Ut6}Zbv#-3wzf0{t{E6Q;V$unf>PQl_(R7+{0sPeI#)$4*_gVe z6wQ&PyKvFB?3MId7bc@O2t~dVlSVUj6tKZ7YwFq?TYXmA|z&1CQ zN;yG2#5KTN)1}R@FJ2K`{o6L65$`wGZ@w$)n_|{r5U`g&QzM!J@9Q6xveK8IWtYQv z37A)$)pcJTv%d`h%P`{Tb?NeLiT;^A9rww8rZP|>9*%-#zSya6zs|>MJVg);EXsXA zl0qQd@nox-HJw45D83Ouqg%hp~oW$sD>2q`RQ{X)@K%Z6PNS6M zhC8*kw_I2IQ?{tp9m_7y2DUZ2-pAq8rJsqd8GQ%bl>Krz0t+2fU355v3OeXBuF@x6 zmYaJtsp0};g{n}RI`f#{yM4vm-tRBwK0A>FB)%^BRt#b)tP@Rk6rIaL47}|gTR-@J zM}hTdq5M-f@zcABFci=phIkg(*o$QjDlIis*LSrKH^LIN3o4nj!Vlh$*OfDH>Nm@n z4^F+^jg+&Ys0|l-X{b)NZ-XM}M!S3NOfQ6!t-CyMFzR5dmMxlwi)sc`(liyyZ{=6! z&!7;xJpjuWzTQWp1S_|-&B7c+e@)0w@h2M+qogJ_x!C(n_8c_^c5!CFjpIy?!bW_s zgx5K0(h(^{p`P)se4iQCX+5RQxlF_?`Y^^6|LFsUW;F9Kw!@W}*!*{xq&Tre@gs-5 zWN8I#6wP@fk3*o4A8zVV^1)ufu^<48f&U#Lia(Cf zDRRTJeU#)o%V>|fnd$o#A$mI8oLojU{q|rW0vXJvB|Gg6eZo1|Qo}ey9i&7pm@?2w zstK&}4r*hj{+)J@h}UptZBphSHu;_xs>DK zo>4W0ZNVtiu8S8(Fyy@6gF(x=tqb*$oqN%A4`vkRdh#@qQh|;)YgkL-wn13+tW)jz zOtmo)i2$A^j+RB1*#_c*()q=-8H*NV=V$8ZLs?NULWdwR<-SJ9BwQ^ek|o#V()nVw zybRN1AQtZDNox6tC#8HxUPnte)VeKbLSayA;%_wT<>9nDKiW;&q5waV%=u2ch=MCm zQTQjB3wc`>%UqywDl?^VRzzG!dn1@kc4)EA z33G-RI1R(EA{X_O*3*g6Z}tQXT#K#b0=tINOs{cEDmX|Ml7Xi`>|eQA_Ub*UQL~HUo!AJ!O`N-OYH1neEnDZo_7-p|y$*dOVM~p6u>5r&%pJ`mjINuv_Xay6ygu`aF zttnCs4X5WB3Z$@lF_vwLmeI$B>wG8K?L2=GR^VNC)jGgP*;)FtPC7w$45SPEBp1-J z@NoQxSh+=*C2N_@q8RZmW$4MW*)kL)LYh$u08Xf+?Oh{-70|*x>~9HvTWUKW6;-9E zvUVaIm1k7X67`T!O=3F*w2p z3gMg24{rsUObtZ~huayKHNDPj8LEmn@(=pw%`g~TJ5GEWOZ=``E|!4rIRF_pyd^t< z*+Iz-<>r3FQg2gs34==6^Xg@J?+Jih`uEB1D@{Hte-1SkX(G|VKaZP2`$gnrI1@y4 z5kVH3*)}GAvG-?&W_wQ;r2upAVp1^JYIeCuV`Z6V{V_Ut8ns~GV2$*#&f=CBfYNG4 zf;Sv2E*WTW2p6^PM;3u$O$?*HO@4gF+9$LnK?18^mVquZBZR8=^*E*#h@-cql2uO= zU#{ru?HDrxK6xbZkt)whP}KgM*86!jr%|zsy3+3FLScrSS@Qew6Ie>$vHh+O@x$NvcCHufq%rcw(CGe0=hLxdkqN*5gl=TJyGZ#3p7p83eD@7Jn6IgqP@^J z0^7Af4DFVAc{K=GV&3~{IE3>5cv{yA`U|F79|%qt6z#VWWw&T^Rg z=6?0(_nA)}27PT65|KmeoYMk}s`YE+aJTz|S6}wfYKfgxY*vfqgQ{r5SA$qjXIi)v znv8PXcMheST)wv0h=$dk(}IKK#k(Z-x8<2HyJFR>)MWYQVcL>8#SSX$<$ce>VzN+d zwS|LXC*ln=NdHF>VGgT&x?PHlpdRZsD3;m5lyeJKV^lymoZq|4i&cY;qZ}h!=ki>{ zRzdS2C*SE=PZfJA&009I1^lmYE)R*F??EoE+x0jy8qOi3Pu5|=!wdtrxI-zi)tauW z4NO}hqXJy`rN6aEw|=Mu3IP7*Uu#G43$%iF4G{%)d4%VbMVmO02 z-P_#D3wA0{fOVeb7OpHh_&@V%$AXH*H0)Ki*N3=qdKzc!=zeF(nDl|)b^5!oL_tZ5 z(M8S!07kCUlPc^?_&%-=Obg|?yf)`KY&j7*JY2oTwQ$i4zr!F{ zkOjKnHoS9hWcP^p##&NXL0O>IMaXiy_cb8T-f(Q4t26>cQeZ@>t6p)MEMc!DM?(0I z4o-fg$QP!#`Agyaa{f8jhRf_xg=o0fo^>y4%w7)=3hn=UkedED$b4BWGOqGb%OP3j5f~pl|T9 zY+C%X$GP=s0HzCd092RqhUf&ga-v`*m~i3?vQ3=kw>~{X8NBkg9GefyqbPFj+cVV@ zqWb*EzP+gd2Ruy+!Gm7?7R~wNT<|Dww1=4wtbnvpitsg{ks$!2I%um~f{(}~m2mMkeekAnAX>8X%@v0g7(coEi=*f_^eHUM!dPF+~ zwJQ23g;*BnojCU|A+yspKDOJ1rtTMI`c{2qX9@!?zjR2~bH*{p2=af^#$3b|MW>=x z8cCDC+WT7a~ik?x|5XiOd&$1ewITHd?v`nVT(a#POa~Dg3kt zGNfXhlUJr`DeTL)!!k>lK9H7_@D7E-3}B|}JY24b5v=b1Fl1KDtMts- zWX^3!+dprAio?O+NPs#)E&Uhd>&FV6J5W$?%Uha$MhF|HsZC++*MXUR502+QzTNvP zw1p=W z?jq0oH~+(*+8y>}Do(Y2SB3kjz|SrxpzVX!8`s53^T#^!Q1cK*^))8i%EGj#eqGP% z^aE;1T;)(1`Q_q7o7K#O?kxLS=h6g;#V}x~6s|Srrn7*#H%^XZVCdbi8pD zj`lu+g(PIQ>28MSPHm7Her^?beJ)a4w{yPs1$%G`f06pqccz8vWB;!(GdrpwZ5VY=SCkN2=^^6y8Pla^ zy2|5Kj<-a5tzJT}Lwu-r@3*fj*sfHCXOD9%h(W+0i%IiLPM{yx9%VjQJud8D&}2>W ztI=_rfmx)&+fnTWmV9!uW)BK4%@9aVMu%|V>te{7p4qev{Li%KswUJbkgzMDQB`h< zlp$_+%H0L7gK;Y_`MQcbt!K>8KwTJ%c?oGq^`1DXZBc1S)k%nqXZ6+a%+X5Xo=)D9 z2pfUjBk=XeyNFChS#STjnv9*QLS0KH5(cx846-NT(l%(DE=C*VDwk6lIIfmf`n!+A0WPIZbgJ~vqZyXFDgbR?*n z_5nNPIM$I^EQ%!S&H|m|uzAj|-S!enQt_fk^d|Jgb0YJQ0-pRcc;O0Io>kVJ2Ns(l ztb(Ox52T)G6|Hut*urVPiFB9}A6|WvfhD@r=Lg`0{I+fuW|bsHqdNZwV%fF`{DBu) zQndkfm!h}JK}ETc?}Ndu%kpKR%~5y^g9|N9Lmo`&InjSdgmmHjMDN79*6PWEb#W@e z{T?3(5Wp!-%A$_N98V{zFVa%=3E~J*T4Y+vPuSNN=MR+}UChmSM2a8{FF8v29W5R?b10)JU}bp>Nf z=lcB@brm4e$VUGp(nH)2JY#NL+F5_-*y=taIt*DC$e=9d>;`@u+D1wz6IZl$gIMRD z=En4FQ5xj2XT_&UwA@cMe7x!Zi_9TY*C`foO|bMh<@gG{Xa&rX4I|%ZZRg4JN6P&T zOEZ%!g6jT+3-97@_^#<%vwtIP^jgg`#s;CA$0eK}!G_O_(O6Cy4>MR{rS%_ItU*11 z-<~YYlDM7HEGi2;riDSl8}o&~|5&Uqz`*`Hb(9Bz2k7EP$64Q?6*^t`a6H2GV)G!U zqJ3r;-`j3!Ngl^cOQ$k6#~8Rc;wna2Ylr}D;T5ELArNXbhX1P=XV`m(cH%q=AvD#e zla#3(xTaI9IC8FJM=umi3Oi-QtZc@N>1fV;?q ztD{uD{znan5*gaUd2;Q&Xmm&>uEyS7)l2cWm#FsO6Rqeo7_KcCv6DV`)jF`!GK!n_ z5miiCGObe5y{5}|G?s~mq88pdJcSDqd_DRX8D|{5)R8?UQBc*ro%mnRooYt9T8Ew}q#5$lSafO7yG%)io3^5|23KXz`W0$FtlHwD)r` z@m;c<3d!E$J+g8YByRIR;ZVF?KiD2?uX=pCYl^4zfbBPzRqI1G|ApfPGw7sXDDOvD zg6Lqt*6~e2%4M&%Q-nh6<_u6v*zK8cW+JEM9B~w?_?Y3~USqbG3}*WW$uE*mbQ3KM zip6->l!bfyO%q~gPy%&iZ^%N%CJ7Nol5mi!VrjCGU;eQ!H7&SnAZ5*|3CAC_x&bo!rhKq^W)uR!nlx}H*y zoQ*eR+jBZf9Nn{PX?d#zeDn>Ake{QtyQM^tW;m@(zo+tYMPkFYp5V|rHqDfCqVuF2 z@j5YUteR$&HYW*jy8bZGWAb8yyyA4?og{h;QEIzxE$I{BFi81V9{pmV8-t@e9fpF2P(9iMS) zS}1vL{wOo24^kkxf1<}xWl|m{RY|WpI9+uVm!*2(atZ>|3p7KDxcsHe?Nq)Hreno% zPlHnTd@`fgpaLgF(P|NXBQ8W(yo(xz3E2-Mca%A#%tLmeZ{76Kv1%KLEnY0E?u6-rA@3((YOEG zL7!ChwC!mVuhfTOfvUz4f3apB^-li9JZ_3HG#{bDCxoA>VGEA9HpmmJt@h5*sSnEH zr$l}52^lv@B(5-IaG^)mz#n(4_W;>9X|lK{laF8Mff>qJtM|dq;G=OSI2~H!#y(1LB-A8Z8>M8%Ud z-sG&I>oF&Cr$)K>VXV*~HVyWwP8N=Z2=ncpo-~t>=T*sGhGmnQb<_{`PeJb+mAoOSM}Ea!}FxQ#KsiePKS6{8iUf z-pFJ$+<7-{|q!N?AB{ z41fL6zzHCkG*;^w$A~u@90oZzs3>Zljp-#rBy$WXyFYN+LsY&Y(M^M)?FA>VtYzpy z(}1-S^D}F8Lx${$=Tq=(=?TJk3My4q=Up82QOqJ%##bZ2_tk_b= z&VLP5$T+qsI3PUy+eAZj+i2@#NmQlY#L)kUvyI50CyZ*KTVtuNXxRtD>`ehjJaH1= zK6ifKsNZViG1nrADvHoqbEc}PjjKN3Jhe0b!J#jQad&*F_#`v@-B2Aq!HF@G(j2!t ze}6i!pL76DaODbHx9rEVqyN-~lF+qsaz7vj2q{B;Nv*J>S0ND`E-v;CE(Y=8}+9r5YU*V2q4Y%#+R3%H!g#)H9UCF`zWvPW7Qw7Fb@l<97Q* zR^GkmErzp&I8BGV4pz5R<(d}Th%~?L+`-+H{YU%h6WeJ%`FM)T!2R!zy{DBN&1d`hj zCSKiXy-uE!AlWTJ(YZI8?I+xX?~%~{bz@C48hd%4&H$XX3=|5x zt?OnS#f=PC8zlVZp)Lh0idc-eupVaoGh2?f#0WAO@j;(yAjWL33EANrdfbQsA2;?= zEWG_YzU?ANe6vw_%~|0+z1gxbRH}hm(+zF|{-$R!&69=ugh+Qmv8Dsj1oF*H*(5dj zB7#jquLhRRVnx~hl{-^V+Rq2C>)<%K9ZMXjx1P6WN_0qcfYu#Z?bB0~6L`44{~k7X zW#~Mi;-OaJay`?FfP!B5w~$m;#5l)>{(Lc`^>+`$fKHj++|~l?Tl8_gZp6Xx_sW+ zF#><37cGIfBc>p@FMNXTA&(;6gg#Td%pj;b-l>t5mN6!t1IKL5ZF0Uuaw;F+;g+F2 zNs|`bmAq;UA`1cf+cSpgUNgj|qD8vMzx(VBd5+b5XjaDVZ7?QdM09&L{3wW)gtxA? z_QD(K}3^ITnQA?;s`TWH7opiY6 zNMRi%dkW|^Qa4pfnuR-OOBm}wbbFnSzR=|q=;Am1WKYaS2yxY@W&PI&#a2}OTszFO zJUtgeBfTH$R;$%E{jC`JY1W<{oqRxxA(*38$s3Mx5#8d@>i|`-xxR2&ZTR(A=|}vl z;DVSqyeiz_mX02b5D*zIFZ1jX6v#4}dy6P)*=@U{i5xo=%V_SYF+^yTRT5wu1S-MR zU}1tqnn8OkwfGYUKdcFqhOh$_LaW+~gzc;b;!ONDaYk`CdYO^vUkBS1b@!uqY-WCvz|M1E$0dF2smEt=)Sa zlBDllSkbpj_}V&901Ps(Gfd0`g1Gx7BgJ4yK)o46 zZO@52Se1FVxsRHLj8tPd+Z#=*@gkN%;E*tc;h%PIO`OC1d+iO!<2KldH2qL)<8-NZ ziTYS_lvJwU2X8UiO7%{PsrIH(uLpd)D3iL(F!X;iKa1n6F#|p@C3r?(avgtr-5`zX z%O<6E;LBFs2x36V*&np-@m3X=7fF;n(DZEK@Ikq)tGg=S8U~?N?k12m%}bXJ9-JX; zfbQC|D9YK=lHa}|6<+5viK`_er_o|$O@Hs-4h}0pln%0w)ll4*(0@V7`AI*Za#^WIj7vy~X?yF;%b8 z_fzvvyLYw^jP?0&7Q9UJajQf9JAOMg$KTOZCZ(s{lVBPA^ z?Ikj7_sSM)kqyuXJp9d~I-}-%u{8qRsSOk07~`*UF54=uY3RffnTc?LHvv6U3kz`& z8OOxXJ8ftW(hi~&nasxael4S)A)FK4S_b^nE-SnW}@ ziy1S!G3)7eq2lp@QmY$Q>okx}v57Gh%vEB%wgRNnw2@rI-3~3KSrXiBa8xZXoXK5j zH1%jmOT763MG3VB{Z}X8A2X83-q;F;m-l~S|I9?pZ0y|sbN7!h$;|qnZbq(uoq+$f zoADoEa%ua$#wG0#5(HFob#8kbK9Qvlh?GeLjwr@OiW6jk1b-piCCEim+Ko!jZ|UZ< z*LkMfdb`uSdiV0A`m4uFV78=me#t1UAyCWz$Vick2NO~ei>R=qWC#)n#DmLU&`#FV zQx9s3;IkDwNuTiY5+pz<B=ZVcWST=4*iYB0|bQ`QqZy)cY*XawWCZMruVh(g93C@nr7X!FL!KN)ll z+ZZ|!WJ%CLr*7~dHkHWBA7KgwB-HCu0-8cehigkIJ!x@!8vuH^HvsJ1f^1<9+9tBs z0%ThUyS5H*1OCd+B#3_q^v#M5Nx>($im`t`S_9e`+8LDH?=KO=H-rM`>M`XIq8$JL zj>`gdNmd2Mi8VaUHCz?|w(;+sh3FgZf9gH@p7~aT0{H^KH8cfta|PxRAeH^=0~jMh z{2r@x>N6Nz2O=t4t`&^$hP`AaJcI~b3!)sr48I!RD7K{V^=F5pHW*tJl9{3AV z|HDplQp*xoN(b4T7{JZtpYMPd|G9ou2p%5>uM5;10LC!Hg+hDCJ&!Z5dm{XF zf18P41v1$qeQ5*gGwA)%%iv#_gn?*&d8Pb(`Eru3q_L8=Z1~Q2_48R+s9ObMBmf5D z;Uv6GsOb_03K$KU^;4e*6Z*aec~z)DS;B$X1NlCCzDxgJuHW1RGkn*!m%_ZFNSMO^*iT=pyd+{OB?ocM`4{MnB0s_g!<=UlY^`S}aMEqKZIjo?mJ zP5Y??WK}1DE%?K;1oSDL(u5o_jAv8KDlsx_vPSmctnUfcBEu;ySw@d8$@{Y znCmkpL~o?t>oPh$iU`Eb6U56zSo@892i(<00B!~D`<1m0B#%G^_ni*np1lrf2=6@d z={hY80wh1jxM)B0Z=)Twe{c^$9fZH(VL-U9egfiL{sw>J9zr?{_znJ?&Mhpjzc~i) z4td)A7`(o)0z>pd=ort)4bq7P>Z?IE>#9pDwKdvDhZo=#>-X%L6OMC=gt<+|^ykU|w~dE$3iC^iIT>hqqPm{U&o1=2k&A8~pgv zYdwfd|L(&1>YK=H?&lT`tsBJxt)Qe(s)qdK9fEzMAJDtNGuJ9OC$>)TCcaK@c<|~0 zl`SY=bdy2Hs2%bx%y4b{Ct*|nU4;=ATzH(X@;cG%_;AwdNoDhCkxvB&qqL^Vvw`99 z3q&o%efKf@G{AlQZ`%Z+BgJBI{v3J1sxGN5${ew2X8j$mK60QOyQl#@V%4+#ff8<) z1m;yz4fhE-YiZa3;S(lhn&MzkV8I0_8`^aS9t5=U+=3PV?V-jY;0;Bzh$|#dR5m#9 z#jRyx4saqvv3eN?KePg;?;16Haz_w^HIsYY(|mitAWe7L{)wZsu>K}RGoBIH?kBc) zJmR%AKO`tRqGM7Fclriex2Innq8?MvRSg(J`|Xg;*x#+#j)9Emhbi-n0v>VgT{Qm!L3;B@4+*L+WkK$qOV_MZmvqY5)Rh}! z2ToMX1Gq)8(lN?il?;!WRLeeWldIJp*<4YH3?)&BVRl2ivet#}LRVGon1?;+9a=ZD zPtYgEW!)nsh~;7idLiq@`cB3zR~6*FQVU;7=a2Yc)1)6q?J^f2NyRl4rO6d<$$F!3 zCfl=>>$vg966u4&$2>@B)AiN=E2M?XM5#3D>gHqcFSA6 zn7zWlHzsWlGX(B<-ww6oCV|b$*%Yr@v9MOCq&D+2rCAa`u-KVY1*ZU7kCV5(YK4b{CK8E4b2%&4AI3oJK7j2^Cim|`3=hnE`>E-`HCrY z{}?84!>!sqPVdGG50evkmvM8-%uAv)%}}E9H&oO3pzR$c2aM~!esFslKe!_>yFCLBfT_*b~eY%GSZNtcDNs zcBZKaN14eww0#}pa3%T@0D->bXQyf266OC0ZGtEM)rfABNlq`)o;Gss`W-~12pA9? z{aPGeQ3%#TYKcV|fS-ANkKb1+pl3nam9#eHcuDyvV@N9JjXnkc$MU$Hw~8O(1*n54 zSHPS2f#L{z`WUHJw6q*R`lvc%m3Eb{g)9hU%8CKGTfKoD`PcT}Kb4;KK~SjiB&~Qz zSj>Qn8Y$}|UiS2eky>?YF4=R$v_Zri^p>79_)@yjccLCKbRDUtx=z;f7KFtzN<;w4 zSYwJL3t8t@&`L5#Z?>AP3GEn7lQ19esL)R7kr5lhTUgJ4ywn@lN1e*ehG&eAbGd7~%1X>tk6MIvgq>yh*M7 zZ@syF^t2QR4u(XyyR0eb@>YnkcDU&L6M&K@-uA*1e4F-mi$A_QhB5TcpwVn2{7vq7 zE-#?;l9daojjwmN#)-Eb-$>U=+coPylNotUm+!I9Kfu|HU{!?Rh+oJ+{6t>ZcQq>u zbB09d*L_K8jA3d!Y(P`yb-0;FD`<>Fv_KE|PB<~kx#VFGF9E^0%@&w2TzT9Ua@l@% z^Sb#DU_^JpLocYCpSJr8?MyDYOXkh{PM10L42SRgk0zI_A5EO8VL;nI5h=co{S*Lu zAs#)&w@0S)O}hbqW=!UTv+_hSx`*SjNL`U!AuZBi(goOmYSDgNZ+{pM3xJaQ^5z{) z6vs$r4Hj1SIllbP9WZ%-@$2!!e9u13UIw}tAH#-^;fiP1q1Nwbu@;Rjr=n;oF&jS0 z#8q@=nRDXiK&KN8)_Q8}jX<8;Ruc|frAf#}z~<@i?Uro4LX#ci3p#w-BeZWLhdo_dq0+muMs(C>T%9b&h0 z5dOOKGHglz8;Lq-->c+!g}bGv3XOaq`L4WbhRao$aYiHi$752|?PQOizs|9HCJ7GV zDiZU<(W?J5eZ6afUu~FSd{w;0eG6S!&^}(Oyj>=>dyS8rGt8omN9yB2&rvA}PEqwl z%w@G`#%lp0iYxUCAgnt+o>H|ma$&)?ThDDn+ftXk4qlLrsCa}>)MN#HYI~?)aq8_x zh&4ZkLulfrTefsIOI-kU_bR6vJap-gK#2*lyUMMjf&e5$1(^qG`LEL6Czl*VaMu~E zu(@smmSQFb2Q@5B`C86YT}TQo$wZDHTx|fG@l-5v^{r)i;5u zpbtbie`7^Uh@a(PE%kBcdS9f9NSI7N?&nmqg{nmle0T6g$`~sx34>Bpj^bA8y9Kvh z{3Y9NG&#vs*KHFA5k_=7f~DUrEE=+y_G*Fg<-9B4c3J%)j`Aji%_)C3B$(*nOih0A1!cFVvQf(d-+Ete=L5ZAnS%yZoYL` zRh%aBC@A5nD^rMxQKM-}HWI4h?dgWq7=Q;Z?(ep3E{1=sf0veJX)96s>>+e09Vj@? zI%4|;3pWq$E0;%oZc;%kS0cLuF2j<6wP=OGpK)Ed9O1O0^%V$J<=YF?=uR4++D{Pc zS`m+3bQAq)}Dfos>8*%m)BjOAxP7(^lKE=XV;6J zS*sd)#p({xxEIgvepTau z(!C&!p?<3C4a4~9>g7Vf`l1TJLoZ_>U>^PbFxN%dFBO|!)wL?E2PSp4)cMw<{KgHf z2Ujh!C}z)j0APv$SRj>D3(O*+izj9K&4`re^n`|n%jX%9pZS(O<7j)@$}t?mPE4J-a^{1Sx}6I^${&kX639Tu%57ptfDWhHpkt55#~B1htSV)C z`vofzaw|n1$|-Yx?@+Q=P<$e(F{q;HI99sswLEXk6oX|juufyRF5x@d`|+K2Me&E| z(wGpHapScrazAQ%+}D?kMglliKFUH%8o1)JsfH!!|IGZBIio7D0XSH>2Ss8zznNgs zX1AzbT&;y1Ecxj(BAlADylE!&|EnJa)GyDLz5Dm0Sb2K=8U^zlL?zwlO0_JU1+UFP zRl`FxzH@UPvQmbu#G4!l7+ zs;(_J?hiu@+@yA`>-%|cVn$)0otnX*iFWl|S)2v}5MtSlmN}{rB|3{5@5LDwV)!Hr zGX%-N%cn1)Kj#g2hZc(efLXGh^%zc>U{|w&S1;Sehgi4LGI>r^-b?rZs~+v3DO*vV zl+Wj?&fj|Ctd=3f`_T!pGH-)cfoXVAebSn~i_hAQ=U;)wcSw_hsawMlFX2Osj$K0J2{e&Ey5?UuZm>)SdzY90aFxAim6!+^ zz=DidypH#rd4@GPmqYY93vXJe2Tj*hH;P-Yzc)9}a(ej3GL@F_Cdj;-Bn@jPUlh1A zm^D(;EO0)KYn*(muu`C&CWbw_&|*MZD?KD-&X+*yV2K;{^VOg*MfAbLi>J1AE{mrC znH=mJ9PmxQtbcYiHZ{vPCqY(O@YO;#3wD0tb{N+pOc~W*R9sF|Fz!CkT}i;%C3&H< ziVClCIOnkqiCVEl?2j?5lpt->IPhf*Y zhzYz^Ah29hty2xO70uTIJkBLp6&0a40jK@*6=T{>#C!P2i4R5YCWc97_Y|?` zb1M8Q)=%CFLCpyI1}o3ytuRiY94F&W&l588>s>0e4u>S}VWLX$_Vx-oRx>a1Rnsy? z`t%WPMy3dXrF}R#c-9p9ZuIg(xekI~e6fIFg!758d(3i4QcYR0^S?x;)ME;n&0Bxa z#wEh@e4hLd{ zRgbAGQJabXY}_H9Hp4Pl#QbrEUbeeGJ#= za11Epr9RRL`UuV8Wjr21AKfH|uA)L{^l zBGsCKT1m?L3F}4fZZ(c1*g^{7-F~4O`KD`dl4If^PO6OPF%WkyzFRha%DItdPkiMs z%g)(}0Z(bgDp!+?fjMUy&*=mKloyxt>Sx5eh1u|DJoaTi{_rc>3P3TP13syS74tMN zuZML1VDz}h_7;<%w0p?G(J&m1`ha?Xjscw%(MN54Oi>I+tJA;%5mXSfMQmAo7HC!# z5y^JS0HZtm?{56VR%0ATY}BQ*H8`f!EtjU+b-w9p{@i$>hxor&VJj3UnV!GF13n7K zbX~+>PK0sSwCY%KO-~N zUk@d28Q_CUGW8|w4$&p)9X-_q`c@(b@P|ye7SRyTs%Xvx%UO=FpltH2Wo*>rY`fDw2U*%57Q3@chyxTNUx%8D^x|j9X;!o2P zdyljjSo&V4c`TH$7P@Bs#^fJd>S~D}9{M|Q5HE3tkSALo6V9{Ay)s*!G8o9Uo~BJt zzTTw;LwFD>H5tmmxeERms^ixZmM7`Ow0cog+?KDTLy_z)m03f63H#&OzPz5TKts)3 zMS(Es#RifEysbnPR+=`xcm@Bk}ufT|tkRQ6z07)ITcUgFRXvoRE= z$8#>hG!!0LERM{ZUWxUw982~JI{!+`&4`iodavZX%h*TBDWb?U96)8qnrERHs^e%p zSaD*5aP?V_H!mx>XCMNTh_XwNq|wzDx8;GB$5a4RiqUo9R&6bw0d9GELbx7Lt`FBr zs-6hS)Hl=dUnK(?^IQaW(M%rvQ&=4G#B^FG7B}T)-&mLu!jfiob9k4g=UgvdlW5CF zFo(n=^$%jO`{TKw)re8^5ZySgS$cijps|~}pa8raSHQkxtcwi;zwiut$O|(2a0VW?f?pXUL2GUy52|h2{h${8=f3hZ9`fk6;WQot;u)*LrjR_6) zzf_=axwEQJY(=d%9Eqx`Sc9T}O&Xeq-0`SPVC#^edt$HNXio?Hn(@BBC0@8(_W zro&kQ{+z--R^Pn`lYFHU((!W~XHfYZ&|rrRH74ZcGi%M7At57i!Hcvj5o~ zjkGNrLn@6*Cqz)41*7vu@_`7t9s zWv^s3o~W~q|N6dTO%HJlyxXJY4H{!r8*mo#Ex8AR>DAlERto2UBOeH!UHe+8e z@|L1sGtU3az{n<8Gr0c}X-Jc<>vg8{jAob6+tehENRGO%jajdK!zACpEajHx?`3c@>rqZi5k5!G5d8m>+)ZsZ@_)j>$h=?XzqO2 zOkRNOaI}ciL<@>AOe_dTUGnuKnHU&c0TkhecbESY>IK|I`k)?7rb{4+*=-`_>CIZE zR21%FTtqt8Ta=t*OdUJ}fya2(QVkbmX7s_h-uz+@-F@JdbDhX{K951kn2-K<%-OY;v<%J#rb@++5jkPVN@2}`gPHk8P);F3* zH7E_3Byxr-UOL9LYaen`0&vc@T2ffn!TUbfTN5lA>0=g{8?C3xNN2zhtRtp|!uWqY zblUPi`q_53D9Rp$C7mdQHf$c(=c&)A_Nv8|AOB`+MkR9Y=_l*ZOc>5ZpOhw+`bQr2 zZ0Yo(v>F<1+bH(s^4jF52<6Qki)gxY@5uzjaqtsDbI$Mk9oHX6!M8oFPma264TCO& zkuU41L<|*xr9}eg-0KkiLPS=rdal7 z`87QX*$o~xY0mP!EW62?NraTaeS=mc2u%pxt26qDSdwkSLq%ns~0upD874l zr#_Am*^r1$%_8631PSP6EyXk!IXp_1_f~=XGVmG>Yz`S^E@y5Z2AP;Fa#9SM8m(bA z|GswHXs4KjtXpRsq#3Bto>mvgL*q(c6A0{>@^t?@n|yx<)-N25T>eJwk3N3KZ}3Vc z(lw?!`q#}26>DBg2$(TbQB_p)*TK_lhZWoifwA!iT&;)NioT>U{xaIaudkP(vfZ?| z@4r}DaqLHBQ?IaSdj9M!6{X!Wyu2D;A>m|%odccX!(mjCzy)A(>%Dx}7Pk`BJQ8sf zd1yG>iRm+R^e*JK0nj6rHEVzZ=_@yt2R>;DRsD~EC(P+Uk4?!2Xsx;VWkk-iv@ z_3T8NTDQq~9k{7Z5GY+^Fi%nca(1IAw65TemWBP1rZO2)(0Zg}Sr>q8i%o-!q;AKRF2jqTz zBE2i}4zbe9z2KT!Z5@*WBKf$Y^59@A9QqBX@5r|QTc%Ew9$Ou;$FeYlLi{e=hYOGr zp>YMNPmXTgk&zM)Xb{Hz^Rp~n8=jh-(P$h_JxR?JeQAbLMQxhKG$u@wbs5HW7y6cS zm8WB5l$!VFU6n}uGWvGW{clH)&NFCzZu#;u0YQHICNsR?^Cm22-9~a&0kwmS)@UVr z?2>&X{yS@6m&lUpl+ic0Qmn$Pi=~f&@TqzeX(ppHcyBw}b1K?cH(dFu=k7ziJ>05jO|d|HcRY?@3B#CQf#)|6fC}3H(p44hDU!=-eJc zTxTbkhX*tRJllfi;SEDSJ6OaXL%&{d=pGW0r6UwrhU85*Yf9E{y?1@b#U-HS7O*P7 zhGv~jcaR=`B7`l;6dD$iriVoIw}x&O($M16*v#Toth{I*MEEM`H!{h}HISi>NU~v% z5F(jDh;=MRZUXMXxZ(;5f~svDl&cL0uPYeOH~8ubNWtAbC;*$M0}7;cYD+jB$V@#j zm=xHr)QsLl@u z8^FWO_ny;*6LdW%s~77_tsPrPLKolgWnoY7x?Q_1Fqf#VrjF=ym%i~E;n8_=!BAFO z5)zUK>md58Q-C@VcJAPKqkHWqzXpG89`x!Fu>mBAzSf`9==@};93FzZ6Zp97huI66 z_*c>#J`~7v?ft#&jT>0V0%&e=ApF|Hlb(@s&p;-A_aFn|%QqJ<4@jL+9_U+0y)Q%1 zlu(1!g9zy00OINKUFCikDk}uk5V|oCXewxhi0L7qxHmFLJ>W27zcY{z7~+a?>kz2n z_vic5^htzKR>HlR%u_#;ThX?kkZ z>iO>YC8+YvnDHwZ{u}=gK>GfRL3U{F@SBnS!}$FxX?FtD`1&!r7uIB-m;wIB-B%0r z?l=1a&i1E#YS;OC zx7r*L1auisPq=qC9h1@h<#)dODkE%r@^k-VV6s=uypC}a;@u{;m-)^t@23;Nsv)f8 z__q7-XdgVYy)Dy=xHt9({2s`cOCMtiY(?l%w*h+~g15w*|!8S)6ELF*UTU}5bG*bB(EP>_f* zaQX%DO*w3v@U9H*^S2K(xiRQBkkO3m2iRc3@dLEy$nE`qp6~yjurFY6AX|cf{@)H` zSWe804D7FFY{u7L#;;XgNHA{@`oxSAeELukyGv1Cd+XsSeoc3Zuzf{V`zJ0fikR3W zqL2kviro}87ngK&!3jEe$1$u;_i8Dw-7W*2w!3wEB8R7g9%JH+cO!ZGe6C+#aQ>Vt z7kLrxgn5{>`Wy;j3e5`^s4@wh$Bxsq%ChG|3ixnFJ-=V$Mo4;vEVu#@%?KF{MLVr{ z6oRP0nfY>v(rI5Yn~2loKn90JVq#O;6($-z@)%{Mwo44|@sgA0k-N1qniC)^2f4&x zpSu}sH!d(0ZOc%xXxx7i7R^B4#Pv)6oiHaybun~A;`Ed*`il-{x23E~E01nAQz`q;RPsHif;E)(7Q+LPjkGYAYE>G7BGuaq>% zF~6M=E;{6W)w-XwaPe$^++C-nllNGb5RwX~4ux#5HX`FB^)V(NVi*-@kqpD8reSWz zydldSIBu+gfi3O1uxpPgUCq|QTxv4V#|6(Ds0q|*NZTNy2qI+q_P@4%NaXvBd0P0y zsknV2T#KgmTJd&o^J@Gfe3H_N`f#2WoX8>R^nIBW_tv$*oQ!?|!&#}TSXe$+w)}{W zHBl;`$SFRnYH&Bq+qK#6$yWOyzmKP=!C*#lt+Pq+*`OZcQ!ORqD>Mh`%kc|AmRCm= zaQe*G147&9)%+>ZNJ!9?FOf>TxdeJauDkO#P+iDrvUkOPba}c>+wziHrx_G@c>RL` zgb&*F4;5Zi)!z4e&H8;AtDFbVpveu0KSC_F1ESW%%*Ha%>{xPeDzV&+@UOat1CXl` z@J6zH?>c@nel;n_AmqbunsP0KBaVNJ7b|KIFvg#AiZdndZ?GdfF0y`vGA>_h~LvzY9y;kUTr1nW^xua zY&_Qwqcy@FG$4Hh5+6_|o@}^3KpuWjO0y$K@POzUhfk->fM|6p*lj#PprD6Qa{&iW z#ngu!=G`}SkMD+rqOW1Dli$kWOI>;S)9&P&_R!u)5Yo><8X(baB6w5e zyHY|;TL7|#flj&<*hWqBnI7ZP>kqgl3qyC(4+HBS(24@bVj;Cg;5 zlmasTO3HwN`H(uP%BS$MzjTJb*^R8)f%xr-9FdR#8?p?}6T2qHJwoSjY#WQ>KuDVQ zNnc@U!(W3Z+LE)wk?Cp9QH{ao*PZ0HB>kfRs=fEh;g>+lhqr?qU)vre=zAjSz&l)3 zSw#3*{Rx~gLH|Y8Tk&`gp>2)>Mx|**#JKF?Ga}aDx}pKhVvC009t?l?ooI_LpSmi#r$)>V#`&BLHLI(p zW!1=;s4XGE;+^DWg|bOemY|uuBFPBQv(J~@F$4$x@4SCl*h7$%62p^q`$8_Mb%!pbV zLGjnMEQR+lm_Q}Je$o;ek|E+~O3iPVoFuUk{&0;bZ2E@J)r&-v+6Ppkx_Sak5n!B7 z+v*`iTDJ0Ml-ANbow8~T%{QP@7`IUuXC_#>7iT`jG~T#mM1hD>5I}k+mWPtKpM_UQ zjIn#Z4y7M+hOkF#N4TA7_upA{7kTnm9~sz7!YDhAF)pF%?zTs0m*qs_b11feSsGg= z4Y=I$;!BOM?wD?uTzXn_G-2lT%vn@mM`9^>R2HdRg>2=b;%l#u!B@(=5atiq&0Jb= z)t9kC6q;1~lIo)BuB;>X!3hHXSvIdA>wTe*f5`p9h>kNl@~D=ESs1f}eOz*3gX+lj zt*WYS;B%<0)I_>?EX9k-d`~j9n!CD821rik)hmwL}Jbq z$TctKHDWK1bgf*UIOb>>Uz>7vwrlOU^Q7x)vc4W`W*-D7k6Ia#eIK0?hg?^dK{@J% z4G+koWXp>ZBIxS7FITgmUy60KU)2kaKfXVWC&nCXI{s#h_6IEQ3kqsU5SeC%m(tD+5}fv;&JTLyG;XR z`{=e9zkOs3KToEkQ+)=3;y-Slwh(Uh^MhiI;Q4>Zg&oZ`b_JtHP=LfKox+@+d3?Pn zA#+NILtmeYKP2`564x5@xh32l7My5!2KVV<9Jen!GQtD)ap46)V` zwR|S~lt4;Pw z;bW6n`wtbz1*gz#cbh`xPZ(s3d3=dmrhe!u!r3;j43U+KUA`-O+z9Bvf`6bIjR+jQ z;K$E3wJ=u>EY=F7ssroVozdT!vbKEGP8@_$0DfaXFP2FcDPHDNc`A9ZMeG`t^jR`I z*m_9uj;(*P)o&h7gjk%$e9{@c$rDEdy|AO#8W<|gOy@NY!69;wME&LHtf`J(dtVY# z)xk{N$HNUdYh8PW4KUrD5aWK1AkM&DDOXt7ODZ)&6ed}6OyY~nNP5B_UW#|qV~93Z$C-AOJgpYbWR!VCe3aS( zpunf-a&D6EDWee-d2DT9W(uT$pimtlMt(G}<-ylJ$z7gm@)r3lu#ALODQYYno*Ts5 zSVqRZnJNQe1HTu1Dhp{R?Wa_Jf4;EVzQ{>&IHWSst(bo|FZx4(dPdp!Hf~ra;p&wEz=WN7^5j{h=XI+owfIZaB>!VlU*nJlP5Fr#{X_pq^qPEB;rLe_bRD(-A= z&-D=M_wkEc*MIBIJZAw)#yD>d$tH70E1g3jnD33San{1HNtwDrex+u!_p_V4Nw)f- z>Jk=XkR+UQGb6m^(t;s37oY!SpTEy>oWBj_8Qb#ryk7%m7H;ibRHy0_KVPqXX06wv zeYV=va_&`xRY$Dz9u@a{3o{@vm3qVVW#Rk1D*k4()<)|%61~(_@s^*X-nU><{6!r7 zH)S|%G1T;f6mDsPJzOXx2)>eI#k|05?-2WJ7GIZ2Pt9PB#Vc|`^a4QH+PR|e0(kki zeZdTzZQ`ILd+aM%?=I`Cih!$kXY<&$#2{0ZHmi$3rS_m|#HwU@E-)-#)f-|o$N z`l(VA4s{PM;h2UYW@E>+3GqIkkpN7noL$CBgtO{t^)QWJC$W$|* z3%UdCh<&|7sGGllzeY!WI54aVCiYd8*o*)t{Ku!JJnUAwWJ`>EA%D;eovAJR1u(Zr z(n^uCBqWC_J>48|m!qrNXFo8oaOtQvgkPVmF|$coY_|7#zloO?Mb|fCbV3$PTsfcQ z@@Kkcb#@kymxz%mJ8#3=zSmC@xjYDqr~1(5&UR`_dcY_jovY~i{u4bc?WW50BkQBN z#@Rb%C7yhW?51tERD7L;%m>D?)WS_%U%WIh8pJ3>;(%QS$C#Zu*{xZ&sB>wZcD$uH z{Pt?-38LGUtRNmtTNP3ly*cTXVlR9p<*Iea1Mwy=FGu&26#uVP^*HW;1I`U{Kx{eu z@r^mOGd!$GdeSQU=2}CMZ7BNu0&+gbHE??%kY`Ae#6F1YVy2x-mz(UblDi)xF2u(_ z{vsF9qNc{!mJLQkK&FrW)B^5lE3OOAYsexg46xD}>S_pPq{n6zU9}vMwhtH-HdL}u zx2E7b+DmjM5urmm_kzP~m%iuWjG=YTMvN<$LwhcDc#r_}&SI9{{i^%iPv7B1Mwo(> z+7hIcyR)%0$3HZRGg>~#g_3VTpG)7L?&yaI$VXqVI@ zw0X|T2+>eWeGVm)f%4RD2rMj7Hl-}n$yF$a)DGC2YP9$?B;(PiQ zy&SWW^My8QcoH+J6;0E+IYcgNa)Z9FxR#wbtJ4|9L7VC?2_1b=k4((K7OVQ1-c)Hs zB+U|-E0aa|2n?Vprb`88Ypnz`%Y{^<0Zx1*Pi$|Maxs7CLSGl-!m`Ybc@PO^^D~vV zlZYeR@2et;8ynwBk!UQA(J3xUbk)B+H^Vv%_s@Kk@sGqX5459sY1U<#D!>Dh z3sJw&#BM);nCLeo8^TuhHzpibJh&>HORQtmS@i6b!WhthshpwF#3=HRT7A^94@U&; z88ou`cu6f=0e{?jqRL_sPAD15%n}U*q)=q5zL0ccuY`Wfrvh^}+sXUh>9aQ15IVD= zH#^G~MCZ+9T8~-|8%}0Oi2tog2u&Yt9oXx;YNM5LGj_{-0Sd|x=+C0xc#+{r;T6FZ zh*>XZ^o8Ws+Z2*Zmen%BtN$q7K1tiK!9=ao>&V5SPLJsa`mINtrfJ05r-Drs*x7rr zX0{T_M3y*uLas(Hi`&*RurtX9AX`1>Q(faDrZbdq8qa6t4?O&adDph;KWLcKemN^i1|LKha}*MuOw9(9lUu zBC-Wes}pkCvzAGNQZ)2)R${bC&@(ufI3d)mG`+_Kl<_{1wpf*htzRXDw%cY^`b9ot zueB9U76t6Vj;T1~5{`-xr^251B-w*G=DLv5)q7aVqL|>SbE8}2MvR?@-c^tKgiJ4J zI%UdHP;>lnSJFS;l+s)>2xdT>zpYwEk29c6wnYEa&c0T^E=j}mP}X$N&OiYF|Lqdt2l}! z26raZcRu$;m=|FegN}s=98*WLhL2e=@rUG^q`tILqF|Vm+D&vGG zW93&)mCgt-NZ@zLy4i((s?y-lf8e3Y)B|r5ijzWC2DA zo;kKH4j(llC?)p1QA2nTxLbh`&EIEAc)&H@>?^!U#ukJx{;BJKC#Ne7FJ1Be?z)X; zTg7EPir!MSs#CvlC-H#8_5Qey4T&koB5tg1-K;cqqoQWcvVEDyx%9Ut*CBa%(6A&F zkc+^f{$O1DZ^_XxAG-dlv*OU7@ytd)sLNPPJ+`jl4$p*C z(?~wpy#E^Dp~O*)6633j7!e&t^=G{HgLi?4p9P*qK1Td!SoYt6szWTok8NA7K=o%+ zKl}>E+D^˾_D-i^RkP!Ip-Hg-uf{(57>MVxu}v}=`*8zI}d7!L08AX!vMY+hB^ zMn%J8vf3|}NpjvX+&M1C+@=I_iz*>qrJvvB%;fAXNygzCa7^pld(h+Qj`v%7%iVd$ zfSQ^c_Q>7dDPuQ!L<}wvMEx>|Ml54vql3@T%pd&OY!G0CRBGc+_NK?+oPvJvA2$b3(zHD)0f$(5c~*|Zb0 z3gg$?lMbgWY!~Pvhns8zloAVfzOx5X928Xz`d*ZNMdCX9(?)}ia5Ozqm`^I-`SqcG z*qek5n&F=$MJ5|}+YMIl0MbjH9bMM$OK*#u>i#vQaakNcl$bh_H$(>STz?-BIEt@o z&`mN=HZ-^^1S;n3tKV;9vnc!P!ftXspfDgd?=0!gkvcnIX>403=Y$CDyp%TQ30Zd> z8vk=yVST>}Uh7Xc25ZqF)ls%VTAAfZPN?K_d_a5l_k&)eD*vGbnS{GSwWPH_rrywc zoxch8vkUpq`^kW_sQm6YKuzW3AJEHv87*gdPLWeTy=wfWOU( zyRoYdHq;!}c2C0Ag8~Io;qK-Lwzg+tH~}&664e45f#wttZT@YM4vRWt&E?{a{AVuQ(rPq*%@B55%&{HjYp8+`^bKE zr?kc|Up)$Cb4?(o?y=2WI?maozlc>A`x`E}I-sBb7EVNl#qf+iu0HCy;6eTnl#k9< z<`FLI%jvJ(NG}3hYtdn>nlHb2 zZcoLi6q+5a$4juIeDK(SDOm19i%tr5upUj%#WN4~EmN zP{u{x7puHqKu%tDx(F|PyhJF=A3jPul(rKN=QYYdwfWkl;158i%oG&7%gvkh>T20I z@HKAR7-;-Ga-_O>glaAvKd(A^s~T+LHZ)o{@IcXWiIu&G8S1yCVpEu944(~qiGq0b z+qZ?A>%P9ytz6En%M%q%e%vTK)_z7|?cP=UU{@@iUGD)-TRX;K=1MRreN}Vxq5J0C z@A3LC-`eqqwPPu6ucIrV?AYV?O^EV~d0WTOKk9Lz_#rJS;!dOYzn=1>GYOxY`N{!$ zNcnUOBL|b;(1tl}x1np)fEQWgtV|n0`e7wgQH&R`iG}`6=O3{5vdYVF=a-2k_c4f7 z8)n=SHt6Z3f$e4X6sV$<8ZD$G=_KoR0Ha40LGjM5X=)Y8yse89Nly1DgDfB1;Xk)M zL1^Kmbbv3*P+|(b2vae>-HuX2R-As`D$?51z5A_jpvY8B5G2vqtaW!jMwJK2o0t8B z`d{*is2*$%D_q99s76lsGR#Unx72;Nz4xrtfR3E;dr^#4+P3CggG1M;OJ>aXq@K`W z_=(A--~%_$)GD*iKnE9vOb#~xoZS6rNha^F7T<;A+4d|I$tOeAr#{o^svBr@JM8zftGBkLT# zzh`4{Nf~XF3*`QQDU>~DPpN_8|2Kxk%zW+B&~ei`&Y_HYJx|d3$?-D7MsI`2D=&5U zU^WNR!SMj*;tKyDhjLKak?k!TJmJ>r;cS32Ei`-jUuVgApMwNo^T^a#>|^0`LP>X& zd;^O&2Z4|tmzdNv|J`KF!E%yQU1MA!$@k$1N5UXdQNqOYgW+z}B(_r*^i5&Zf&Om} za;f!?bh-K!WcuuR6dz1WyrLBB$?biyuaDqSbCOrSmJ4={*<3~Go66%$_Yb&t2+36a zI@_e>pnq;vgEd+mZL`R^0$8{v<~3!?qD5jv^@Q3KrD#Y6VqthLRBdO8VG4I6o=r1N zS7Gt83a5Bd{w9eJm>`a9$G{W<^HnG$QJu<2=yEH}KZ5-)Ean#8FL!r|U%K#x?gsNo zgqJK>F8l4p|tm^b^Cf`L}D?%6W&#*$(tKC=zy?zx`2)11a%j*FYJ?6jw{ z!VbwyEv<#!az-&T46Wt*7>_qzR*8~WGm!opxA)a9){lu|O{f1V*C(PVHQ7!&D9KbG z;UhUDo_K?sUx~<9n$#wx)>#(B34f<9vrrcxt-)~<$s^Vzm>hB{5i$Zu+w&R<`c*K9 z`&n;p%sBApwC$6xG!8qpGuSX{o3V@`@hcUL2EF!Se(wFd+0D*zaBuJ`n5!YQ9u2;% zM8fk9_eOQJTP$Kqpc3>5V8cWBjB~WlQPEw@&^D9h{{SxIF6rB^Ady8y^YmN3DiENCCVY z>B-XJr>=)lN62YSEHf53r`J0x@S|2PDEK;Jv|YzK&i+|PU;2d}j%MVg^9umu)oS`X zQE5M2th_Ymn+TJk(zw|Pc>5-E+2{DP(d-oglx~T_ zC&Im8Y$$6n;RM|`w>ESJs{nG6xYo&PZWoT}C#xc`z0)We@QRI#6MT}k6X5wz&AbK(%M9Qa zDN`0PpsYZTOV&buzAavlCrL-8m&o8MDx48SLIG4O=MLfmg1+%YdTs|R* z%q13PJ?NDP^d0*xKX;}t4xDMUepekl=* z=1g$A{&`9~WK0o`iP&d0w;PG*cW`#NKF;>p8Nsgm@R+WWudu??*!u%M3s2@F9U{;b z!Cg-Axg!-bn;Bb#7-2mO$>G+ad&;~4?`VBQJ&5ke?e1cJYzv(VZ|dLf^0zRNoV@KZ zUPO31m_9FRzjGWE-uq+vNM!?}HicuH9%p2vxU4*-Cn3awfNqGopWqn(Et@>P;k`6) zO+3=L5~UB?R+2i}&es3X$Ob2|#ExfOoA;>tFhrL59^!86y@2kED<>)X?!?UuLCIBu z*a!E5{AmCx@M9rQ0an(SwvZ@g65Nd%VLMHIIo)V>z_wd-!-gAK>}4D!aKzbRH@Z%}><@ zl1|f75CDx5U)1>PA<$s9d9tC3zGOovXO8CCY;NCD z%lX&Gmg<=|sXZI40Qu!xyGYCc|M}i!6TZJrLg~P&p8L=WEh7M7iiVC7RdU_d*n||v z5FCcb2J4P@dakQ8{-cFn*l}f6Y6*Sr8h$YORh1YqLe0b-{?yt(raCrS1pIMz)O)eq zF=^hk1Xb=Z(R~ReVqqv9A?e-VUZSq*lt{B?lTXvJKc!B1qc^y{UKN}f|c3ud5iR3j2Q~GG`icX&&yJviVwA)x0TTh4pz+{&V-Gf1_oCXgC zgrDxI4@TCo5SekZ0+S2jZ?=Bm%PYs!|66^^`d{kPzs$@m|KY0s{-ys6w{{#~60LNyJlg z3%z3yxxWrAfE@lr>Z$AiOnhj~d@eaZc6TD9!&_TwzDY|H6A?p`b5Wp&<}^|>Ah-2S zEr6xKTfWuV|J$DW|Awp4y*^6A{zAaBjde~RDVo5BN7qKjP$0gbaLs6ZWURG8Aqgb2 zr~q(qv$6j`O4)$3zJ--P(fuHAZ?*we)mDElu6LGuaMn1!3@nZH0PP)F9PaC!>cLdk zH~;`C=fkP5x38rD7|AAfgc!kD5mvV+7bchcCb6Yn$s8Dc8&ffRVKjGpCL9`Uo1C0o z4D1@5UbP4>Y*=?`CE3*^e6ex-WUj5ndL9xQoj}!nH?9ZXYsS_&{W>#0zhNsav#6`Q z(e=*uCd-cuFZKZw6Fyl%sRiDN8o=6tTh~@sUEhA|Q*?mYjsD=L77uAWlU-hk=N)}p zP(bf#d=p>PRtR0+DpZ6|__3L(Nn{9HmnQ(Q*RQHqoxs6qxZ1`hTkuriDyyv6Z&&aL zKjokP-Mx-=cVL*+-i{GC-H)%A9UGC|r+N@}_Set6A4VNzNNEaCC-z|B z-I2*5Fx}%_W8m5!?Z4W$DZW2W1?I*dH%#C4Ne=ZufUiGEG_BGn9zyR+#>(A+r&!Ta3 zGaSzksc*{i0FEbs1pX}s+m}u`+^vpi1xRD#lkM;LYIYaKTY^w_HO|kLsAlW==50Pn zB@Gwo3?HkBo7gD2Or1Xh5A}>UXIOPs<#*@i0;fESc)S< z!1_-wee6vx07exRMm*x%*uK!;XN2n(mdt(Om4wkXvIA-hkOtVj2Le#WS1H^g1!S#9s0r7zLojn_XJQL;|;~@rF_yEoB-2J`VLqHto-YPK<2A-4G$zL_ZiTO znD~uv3v$E@fz5x^6B+~DTmB91=VkuMuL+<$#S5Vsw~Pl8UGfF)cX0N}zw6rWgTR)( z?SsghYW587mv-!fkZN|PGYGq^=8N46{23D%anUk3cNg<@Gghzu4cdnT^nC{~eWzpb zqyq%r%6D5iwQ2e7`1@)iz+VNviS|CF@0)Gu9X=-*TV<7f@K=Y==|-Qh*1u7~B7gX- zr*~!_Wc4q5Kz;V@eu@LQG=IXuNL7D8`@VmOCqZ!oqhcChXV2)sRG(EmS!|D-efVt` zu73P?r#U`B`>cK{6mA)#pXg?KBtgHzV2}NG+I-6T+BkpY1FW+8Zn(+7bC+_e9qN8G z&fj?lc0o*zU>revcE0oPKZzPZzc47#ThXWCaIJlYKqNK4CvRBq0ouPDE`GE~qIU#h zIcMiL_k8U44&Mu2dCzWtG#+~NpLYhnESN5LWq!tjK3IX=znP(|>9=4%!{2P)cPY29 zzqQ$%oo(ZMfP8bdDz90pdwZVIHicd2W_7@H@o;_kZ$G(y?|!iBd!4(s=|uWO!T7aCsWws-T#P0$binD;ej2a7M4br#6X4A+q0kFg5gvYiT< z$mLKc=bdx1vC0WDcf(G+Mac*-rYDq_mGWrtMU?8e7~SxB^J0d@oYB2WPXS%j?afB~ z(mLK(jug^TiOWVDTFEUKSw!?8CYTtacq+57&pU6&s|EOmppV}trEJ20WTnhQ;W(vGj-m(FGaUc(4PAJr9R;s zI)S0Xwo)mxipf9JAJ}P4&F6D6G+sH}BgyTnF82xmdX9qutDIvw6B@QsniNX578}y} zbz8g+>%ihK9hHMC9M+8}>`bOuVWeb zk#k2`;Y6sgVA7_w&y65c$$JsSwfNpDQcQKh+q0fWXUE}KM45n0d~mg^xEbFb-)YxR z{9L}F-LEejOTHa)k&GYxE|b*3ia@UR$HIUh-bTEvW=?1FQla=5d z&3L$lqFdVL-v_%QRX@0mN*!WKfi(1*0k|G{*hTX|j`5t2g5ap4gF=?kYRRN}Z85G^iR+ zi`6P{@h$=iq%x;awx@?MG7^_z4N{#cv(k7rqHx=h=49h<1Gu4nrg%bdkZ+TKOqj`v zt9_S86b9wJb^-{rkJLE`gbjh6Guz;cgMTwibxQ0-_Z0o9pgacide+@iVR>T(EA_p! zPb-q6vV5Z*DtxogZ+HD9x1J*TP|Mlp8RtCjJaivfY;S+ln>%jiLBOvWQo}Ff7hS~9Xefn7d~u!~X}pYas)ZUkD)MJP(p3RgL*ZV6 zXU1TtBO%l_W4K1uUoSl^Gyt;lfEYf|`Jovy1!K{c@CRF2@wO?pa#6tim9{=whdP(R zGS9IE_fZ!@uCt0&)+Qg@p*lLRQ;Hh$c)znm@XTcGya48FJ8q9Ol(R?b?h5)&tzs`I z>8&s4vt<+583?3fEZ;RjqsXJ9O;`vM5;hg`uwBEkpNCER~BB7)9bQDM8SRY zg$*w#!YK%O&PQi{^houy5>^iz_bm_<EU8tRXaWiq$dZ%hPTI*^JH8 zkJOnda7a-y@Lmrudn5Mx$O)i~$z1J^Up{ina1go``@@{2mQ{4*jTXiaLEna6dtnx< z!3>VQEXz22)PpxCr7A$9?B#5DHrfu3ot{;OM7voCMN%|8&WEsuW4EXxGKvysb^1ar zjhDZXEBzFk|ILi-wwQ5K`}KtLX`y`5{wO;B0$RZef{Ni6g`%HJf0PzM9FcOXUB(r@ z>cLAD)*GzSMm}w20+S{Zi2&0eStvaZ?~||`lCf+L>30SWauy@GLtTms)HgnfA@b$h z8WYZB6ngxijA9N>(U(eg?s(_Sa8`@)HTxk%KINt8Tjd(U{K+9+2D{g2>3j>#Y*Hdx zu_4%F&I(K}PKEY{Cz(OvP9K3jyW*yb!t*%v3V{8vW`dv8ZMv*~CE)|DTgW5AEs$OwG=Z®cJ;^V-pd>T?lQ>;=Q>%vyx5? zx8TEdoNs}Y_%z*wP+s+oWjvmG0{87Sa=*S52F_&N=Kf5aQkL0p4r zsVXxiH6?pSvlNb}XVQaV-iR0C-g27_?2dJ~f`knZx!8``aR#rq#N|9(w1ew`uGT_A zmnF|XoDPw>cAY!!rw`TvyqOncP4mlFCj&oUiEkS8tNrEqI(@$QjJmHHAl8XiDKe&= zL0pj6^ZqVEKR2WyY#o6Dw#f!4mBZ3~|8O~3qp@mJ5)5r`b9Uhk^mW5JVT*k{88|MU z*qbB7gCeDL+CUTpml(y72*v%uK?o6UqWGPv88(#JYv!%9D_W*`8fm^$YT2vcd1v%m zP$~dz2s=hqD@3alV=ja#htS^$_BHt3YsfI7=fqxs@U2$!&!L;on!1At`a@~;sE8d} zh9Sc)<)Z2#{mc8PDWEMK9fv#^65?vCSoBg20lZxCzgW;~MX0~`99U>>Zpiv)R%7@W zHFlCqku}$32l{b`>6PB%NoMU|cFqWo!BQ|od7vKefm@DAGXY2Q0e6NTVfT9qs<)A6 zSvO(_Ot46$UCu-^SnjD;2^tW`pY#ODa2<^=hhv-G>tMa_LktYfV;UPL?PeGb92xV! zLmXo9s}|QD^1+!imArzo`ta5jz%zyr^u7U`e*Ql)994D|ZJ%HRbsCC_16gq6t(N3NR;j>g3Vn^SZR z&cmQqG^e|s)O`$(`(jBZ2#_qy=0m_@PJtb`#{HbzJ~n>bTSP z`bN)05R(thwM6{N*Lc;jq=f`cg;3FSI{MSbr~(~51rx)wORSKB=M`Zxxf3*2?F%T^ zoyEpZSc!8F&kN4nM{81SMg^XvT(bok8Vna!%a@!b3r=3FEpgN5hWm*?G&QL)A(6MF zN+@OCbT=D{UScypdRdx4D)GN3<6KBkF^ z%3VA zVxlVCCHmAp3{7mm&;H$#3IoE0+>3Tm!IYO>6dfSH<>Er8?0Vk@B-3)>? zZ+;z4FxmuD4*(rqDtn7^wKXNe!}c;iwaS1f;1Y$qbhmN*5ns#p0Dih)rAd zO|+$7pqVo-Mb2>FQ#&-}oxt}y_HL*p-HA`~BV<~Ws>}Y6s*K1~^mRd$YEjB=TtP+`*a4^x9GM?8BsjsNok2(f>SB*B!wT`EJNMC5U!05-eTBVo8(l z3uD@LVr0vv?rRoqQ|3-F5`yr8;t*>O z;o#n3)X)|P#q@zTq|j6~Vi=QVGn6uX7#SMCw7Y5psF>1VmC9mj0A`LD&VuSb*+Jlk zSxv`dya_;}#GQ73^UvS#lfI5vg#KvZ)g8fgZZCh6U)%y~!6r2Jx*jPguHi#KLxkAq zY8zeGvSY7(KiIXVnDEQ+3{^Wjy{2mFcj#Y*n)4}op>$Od(z?cUX$Ju5tcLWB*oSd? zGfYz`isghFU#R)$d@)p4zcX=GF93HI{%dVOLy@2uOiL55iY=UGx>AJv>#L(Bbmq+8 z{X4#_T97M zvLdCL9*X5Z?55U!!`7am0?ijp>cY>cdWKxln}^-(>b5^#UxPy(gEVi-GoFp_x&=y< z#OEZhP>-k_kXUiL*N%Dgu>L0V&pJEj?$g2v6_E9ajFaV<0jYNLL)&UX!q{xSj`&zf z+nR#|Z32yn3RS7JQtW4MYgMWC@0@&Y@yn^rb7Sm>+&vqgQgs`zi9XyF>zwYFFLeMi z<QYOwTGwumyjGxwbocFw{U0jZi>Uxg{_tW&O&!{r#k;qG6dsTSZf+|sMLE|j`f{{ zW%{yW)Bp(IxNGOp354YRL?Z zvsDcWusqURahLnMuQG;T?Jh;+tpJSaU#F6bPNG6e zu{~;78KVjlS+Qs&e1bU?;nqN4dVqXFi3jSXex*Yl8MiNTYA+LwO;P57X~=EQ4blqc z1@X|^+bHO8UedRsN>UxR)1(7^T8*}sA$yUu)HacNAa|}m>0@x_R6K%`%DlXjMS#_> z_GmM)cWMARBg6BjyKjaGAifPK;v^hQ*N9xR8pB}HJs{-N9=}TQrl)5e86?3Jh+r(r z2j6l_5Rc&A)dQnHN!~StSiTZv}EWtqI z@me|S(%2+pAp>LLZBz$G{IcJfI8BtVG~HX~?$$Y+o(x}T90-b;ErBZT2Ur;Xo36dE z=%3J3Lu8FgXqCOQ4ju)Y!$VKJH_clS^-cbdr3K1F^Xya|egaUQaF{m9oWS{2Mn@e_ zJtpI7ki?Zq;zYUx`bqDC=e4p)Sy7swo8FNRR%55rKJ3)~&l9O_(wK21x*@Hm;hz_& zHgX{TC$*eLZ!NI=O*AqR={qRA1$Z>A;t39tL%yaYrHDHP+*fgtQs_GSR$eMt7_F_2 zt7H)F^@oWwZ4x!qWD{vYn=Tn1-oN^ENv9GxDaHCQ4cOngr`hKPhOs(xyTTX0U#dbF ze=UT&NrRuHC`%1#BSloN@)P6jNs<$2`S0?^h2qhtmO1W>J1n6z_awX`6$o>J8bX32>qv{&%T3`OO_LGIN!p*6+fCaFL+x;uC^d}%aeX!Yz>zk*s za?b(ci7jDyHXA=xjI_27iHQ7u=SKk!mSRo`oVflPXi%aWKVILAo<@?Ro{y5Irn7u- zsT7G;5!eHGbGQiD8zK!vEeT4fE1y!hSf)#O{-meW12-is*X(zpl&WENOWITEB}~z2H}Pr)QaL@7=r@a? z;w3E}#B3#3CY_@v;)q2h5AN2K*^Sa`Xw4A%uVpi9*#!Am!DntJ)>7yJT{<5Lb%X%% zwB|^-jb^U#+lG4en9ZQe&DSLqx0cZ2Ub;Eqvwxr5M=FM{uv^*8%`*Z@k5?=i91pgA zS(?f^g(Mo5`zoqvSWJ1RQOvp}X=D9aoj}=Xu|!Wv8b!7x#P~JlHgQj}21|N=(%oGS ztR|T_jKN}45!XH1+K=A08N&yX;OU0$FN47X7Dun53umOvuwC#8h{7xBBfD{eEX1<# z8ya1R-bjDuSlj|J5x=$jXYfbRd|5XP#m-tnBW%aZnl3qAdG_mwvW!5vn-x*KtJ>vR zBn0D6I=&J0}qA?UX~XAd=o9Op)S& z8ewccS&W)`))zfWb5P+s0KTAgSbuI~efzzKZlW+(<%fXyl~H$aI3+xW*klh*W|(5x z-*=Emr?Hq+o2f~8$4oG)S$5-;5;S+!u<4LNxVH*E2D}_@>J4&mCs8&Wyu$jc&a$iB z2(S}gE{zoMUqXaBO<{7R=6*oE->Fw?%qxYEdRg9fgIVEdWvj4nX|K%5BB~==-XJVlogq;(%){ z5aV8dx=h`0wfUoKlxh%+mMO3H&pEL7z~W@;BE`slVkM;wyf@7nT^CLk;<5V~A~i+P zAZS6P-W|L~+oCFh$O$%+fVqyhHRyL>Gs8E3vlqRy=1aA0=r7JaQ$M(7!4Zkl|J?T+ ziyhc|lm2_`_T=z`##eOU^uDTm?3u1}7hXEu7miulq)Fe%DPX=-166LWAsR{+G~#GC z#+*<-yep{Di@_it^OGC&FkLAOjUV%6sqXF8S$Q=FGqQ?2%{7 ze6+VdEDe7t+Ndub_JAz}Kze56B=heSKX{Ide zEu6Ck9JT9;;wfQg-*?610P%C;*>Q#p(g3(fo(;dG2Xqx;_xL%3__Z4#E*c|j6{0?qs3;vS2j=BQ2n0;y@g-d(kvTJ)W->`X4mkb6hkbP|0rxv z>KiJQ_%pU`%EbBGqPR9lbGGJ}AO~(a_5ss4~L4g!77_e_K^7QSz6lOubA~SsA{0G9&depXMp5I9v__dl#oBP&?JYM`Z@2 zjck@KW$K;VP1eJuY%BOO7M29CJ7h5FOc@5IAPOPuI&A!{vg*ZtY7iCX$Gh*`7uKwU$2d!vHA(Gv*DPDUt z8G$JY@6+n+19Zz_<B|GB7Uh z86<&WuLaloP*W+y+JG?HDv_tDHq#b_Dkvl)tPQzLFm`B)W;nQBp9e##*}Cp3Ug(5o zskFi3mj8C!6!1ZUCK$7`!|hB1vn9Z}8JI=z1B4b;&tFn**4#y?{<+IH;~Ag_C4LZ< z$ZY!l(8*K-Zk%k4i6MAg=v27-8_1M2E~pFgJ5Zd|r(rFr#)k54|8xo99c_(@u1uzq zfxrmyu?p$RBz#psOJJLgb0+G!Ms#s4T1Y2hxnGMxxlA}`z(wHUzCE$9uuJ$N9_7va zW5+Q`YqjYK#k1|v{;z}l3_p=0cRL^LjFbl!CCJ!R!bAM*A7$GaT~3YLBKCux4ay<^4DI6D@UI2NU|eUgCPsy34nxuowjrWvs7zI7V4Z88R1G74gp*V z2PtYc9F&kHFW#8pXjU08f;MB%NnNLVTB7+o3h zpSCWv%krB)cI61mT$_xt*6bS!Vd35@HMFwsiI*xZzay!LevVYZYqPa7UPis@Hch>W zW1m%};2l4$H0AiZ+043P*dn&DGFS~oNIm`%JbZ8364wusG4qI;cbr#smfTn2C{I#8 z&lZWq`RfTr4KmW^J7}2>gx>n)wVqZTz8kW9_+1}uni47m8k7d z3Ywx;t^f8WG@e)4_~h?Ta`4 zOQ{e*6|JUZ%%0LuLXC6_Z7$HtBN+bV8FUdz+31G5%o8<@b&G4Q8FSm@jNS8+=Jx5? zSO*b0XotMB%=jaa_?4IS=y6wn5zXqPo;a1)3y$#;o9KhJI!esLz-ID9iQY=SAYtq@= z&_?r-N`uie886rE6s?rE{7ZJrpF>q+V87Fkw(L*^i@%Cm2-y_Zgu+XgMF0dh>kG<> z(O5(sjJtZ~SG9{wFbp*t>FJgW*~>J<9G{82K|VItZ1){3l78NmP~-3N`5sl)QB*6* zRw$J&@=S86q#5CWsADKaHZJTGj1mw!cIUf)(u-Vb3yO0$-zi>}WOK!bFxg>}Nf3#L z@4Pd_xcn6IpJ#Nt$?&DD#Da5EdyKD_o4f>{2kBb#`zni)eii>mq$h-#6 zptm{Ab>7E6QhgSZV;i2@ex)-{VkJyD6j7cX{Ici9;>+}?%b>ty=bL}_O|n?x8(ElX zQf^p(>wa|X^Jy-PFF`NY(S*MQ!`JBK){2kJ`;uR9|BRu>h&RP|8Xi&yyo+g_NK@Zk zC7(=>wNBG6X$J=Pwu7j8r*Nc-ZcWy`9Tct0v`Ys3cZPL;D${QF#u(v~v~g0&4%{L- zlaFFsg1*Aef!+CO$7oK^jM)Vg?@`XFMtg0kKS`DkNGW6S^3*>J6%geO?_)*S&z=B= zH&pD0@btw!(S2Q`y!8FlRT>F@=dK!nTe8{{b=lx}-TJE4!saImi3mOCFbvK_ZXx5uTg^ zG>Q&K2^~K|>T;K=CF(3_D#u&>UU0d_TMDwP@<`<17;;QEFjg%_r)d;_a$7%b7W*_T zOvJ(A626Q-UfE@-QSyTDo}P;fZ*0jgs{qe%wf2$NTipa=r?>9DqT)MMAeXlsbz8$B zPEN=+s~2fCo)6LcVF<|j`(d@cHNELZw=eO>#iHTe*E^bT8$i5C=kw;V9W#zLNst1- z+#YuU&`wO%F>s_KMzXX#h!=!5t$nqqYg$26E-M3Ka~11z{sfJSqlTPQ04qa`5!d_v zpk-X$cq^AQ5F;qKJ)4pue(vgOrj%IGU}5zxpWg|43x8GP{4aMlCSmDGD)P>3{wZDR z*Cs+ccyZ@=)eQ6JxdQvC!IHrr%!|TY^kHWI)|w>`3TG7IC<3L^w#3h7!Rgyg=crCs z04QQSm?r`Apl0Td9ISBe0oy6gSSEv|n}@gPgCfR?3s z&J_clumUqC4U;E1k&=AjEL`+bAZMqNbPEARCMnXhzYIzJu(7y$wYNyL=T~KIUpVVh z9wn+lP{B#PvI}RAe+#5YUQuo)!JkFEcnnzS5E6n{B#0ApeiW1@zrj3dTD0pNClp>R z9>=0ry!3o1a27HzGd73TX5Od?img95phEVqDVz^r`2_aUE1nWvs)$NN96Xwp}=!=Kw%E&vC_5YvuWykupXOC>nANFj(-^L#kpS@ zJ*MIVNfNgAlRQID1`v1q zwawb;P&U;Yg&+@Q2<9V1v%8p;339)}Xu&7OzuU6HlG5tw;x_TWHEkf<&yMaM2qw9&>HKqU~Bk_F#2lxTz>>mR_c0 zZ7pU$q+t^^^hDx6DVNaZE8nr`8{AC<*A9`$jaYY0ce!>AuVPlAo4IR!lsKy|cgu;) z-p8p0bLPRs|I{ooJt|oH9NSdP_%EDtcFDE?sT|9j{J-EuuI_X4>vmS1`@r*l4bv?pDxRpb} z6cskV<2Vi6Kvby^+8SF_q8f)F>Ci-Ydq!dc33u0oL+`qVRENG*Bi6N8^a4Nl7YgD= zA(XyXsGYgX=gUaH%Q;LAiV4kNrN&%fp^Cu0yDG*x9>|WX4k7OSF#B~Srqo(JXK;wf z7lc#f3YJf@C1Ee)R6pir%iHShbX>00xqIg-8l(`N*tJd}L<^~o2pR3VGY1*UiyL~r z$#bHrDYg_AbV5g$Gc@Lk4u(j8Dk!%@ObD7JFuWICLo$^0?~mC@FDrIDTNKAvz+KHQ zP|t+*m0Nj#bMrwG9H~o`QR*i_9hnGPk9Xi#@EJ-7^t=S5?B$P4qgz_`O2!xLZVaWn zq(AaK$92m9;)Wp<4-154Hw*0Xg9!rh;2=o<42)d7n2Q$1xL%=E*V{vLeSHDi*LTZ@GG-B*pheX;D5ycJs#HFNL_)a2-&&iEves*X_< z;u}kCaYWqLdeTz(gH5Ja`&Ej{eAuxlvNSSTREtSF)Ja|12O?Z>TCwHj{er?pk?B$d z2TS#hn(A}P!39(^MC#vGSkCu>oV6BV##E#c^&_y9sU~TVFQuLJ2e(NaJwn>%aK>02 z@1>soU~TUwFFN(VL)u-3GJaP~My)l2nRa*F9?4c-CCkW2?~+{FLY03aP8AX5I%~4f zLkq@k)fRLP$ma@-3?SBxswBHbeAF=2#ELmo(Rny|FtnPR+yzYG=d*9jgr&}_4i{Zy zMrL_xJBr^Bg>*WNU)b>lL94R(+4GkZd&p_OxCZqFmcr}fT87SQ?OxwLa)l8-D0|G? zg0~e}H-yJl9J`AN1|3H_;Gm429hH_E&tmj9u&i;(1r_EAI=9J^Rznyu-5qquQZ)k7 z*QBJT6A+juF?Tt(9d=+KZjDg>p~|`oI{vi6EYq>95bd=*Rg!*xbE~wSlTMg*c4~ko z)XqftP3<~>9p`?txp31Q>7kGPn}Sz?OILvQA6dhr&^tj-Ful2ges2QM*h;iNVaN0Z zs%{aI6x|@jCpkOxMSae-#R-W*p#$t$mBBFomlwk;;iaxUC_GoZr9ARZu-J&6cr;1x zmYxWMMJd0>C|bj$hc(amhG3D4kF{}QXCxZMC_e)JkgVpQzkl5ZDa(g{x6>g}Cx zUhd%w>tuB)aCNB+2+qE5dZt_p<9jAp-8E1+NPetNyd6r`dWP_nn2-&hCNDeWPG}E6 z3*!Vj<{-xjedkPR5}9wWSJv+tBlx=}vnxYCk7hhFRk^inc+fz7DAmhLCdbOpgyj+B zeYi!@?D+kFZg8qBh^)0;CnEE#4N(`zaXGEOHDv~-Ju4cPeZt6X2T)iHsqI$WNfFOe z&9b=|mtVzhsXe+s|B{urN3N8IP!8r<#4S4(9(@V8IH$qR5$qqO((nL7Hi7Few)`SG z{z(YKxpyGC4#2B` zIH{5TjpK3pvcta@-7P$3GJGHcN55F0+tTjg9${4N7kDa9tWWTdw+G<;BkGaly!KK+4ZYRSP_jgYlhcldF7zl? z*j$Yr44#ejGfI6ma9_@Nn%6{J2BbA4zV_o)lL1EMEZ$&?`n_ik^`H5jotFyk{(g#} zF8z9uBUK=AsbN^CUgCTnDzb*N8?L5$Xq(o$S&zEVyF2_Gd+@40;&NK$^O6o*5=b<0 zU_*+fuxnQ)0lnK#CoGJ5zH@H+kpk~Yk8v#C4VQt%FV zeFWZTT^PPfG+(Psv-&7uxx{eAT09#|3NL0+)6A7Vz-HKfGr^;C^#mX0FR+*vz~vnT4DY!(OdBY;_g1!h~+n`0&rVY`cj}3su)4Hb^)dT#Y z!&q^jeXRtQ4E;Z5jmn#yI`L{?&`CgIA|>`@4xufSe6@d#n(+z zO5Vr~{W-B^Lw#_Uh-ptvOoW7814 znj*B8c{_hpvIkL0C6uFgy(-AOyHSQw>7mB)p<{+X^e+89F7!XJ)FAwiM`jkm@g9by z9qvN~a`yOq6f)8foO#-LB+gsBJ_OWDd28Ob#y`SP9*ZW5?zj(#{7Rj*yu18B^8$k9!fWTyT?jwomA>AE0*bZ(I6rn-)ng>=d^U z9|2Wu(pE~4;vg7pYmc{UJZ`2xZB?K`qGjj2(PWG*q8}ik7Ar<;JiXI9ughwKd!j4H z_5%6KBKy~nF zSsY+YQsCzu@8@LaxB%>X!DbFQBwU^GS&*O!UPY4>wI5C<(8IM*|0o`Dr6UOEZhNJ& z)6;9CbN~KZ9aQMW(P|+nDNM4+$wqI5^l}CJ36}jyL$-L(m?%P$6>hy-R4@={1@!M0 z3fMl9MFYda^P%&}+B+y9h1>RA>^E&)8c21B)FiieQ0-w&f&>}b(8~Q{UBJe4BGl>D zNU=4>Q#w;tz!Bh&)AU4)>r#HZQ=9Fu5TFFR))KINJ5rjW*75|)r(!@_7Gqp+r4Z>x zv@V?Sq<>od_e?FR4`L-XoUZy4KnCN}^EX*F7^R~~}grwgnw;xTdJ zI)sOnwKQj@jWtg=Ije*{hW~E1Dbn*)i#UgS5^r*BFS89bk^!-u?3d`?T4b?`{(X9M zK~^M!L^(o?7fq87kGBm!zhVLSmj!7LbP+vjxyh8_qG{>ak1NOBLIT}>?wOH=BMzT^ z_1{Anmbe2KL`J37x-kRpW}Q68=-EQ~0_o`X)n6DzvNmRf*RRmhwv#D-nz57{Pq9FY z!!Wj2uD+c_$S=17?N!%`btHcl1`Ix}c^xv+xmZ&clm<^)mg&Z8*k8~M{7K-rji+`r z-JyniebeEC#htr86}U&(M)ATT@`!#4)cvKQn`uMS-vl>fEYhnN+SkBsc3}Z>-yqLZ zh*N63zfU2$6Xr^-9HT@fkJC!p)cM83k@oron}sD~6RZ!%W#^$~7VCXor2+SP#x`Gu z%^+96J25nPHhZ6i*(GngJdHU6_%si?vU$NeJ8gqSEzJ@IuI#)<0LVhfj*ys4@F_fr zoxPH=I%gHjXYeD5y|LJ0r8ID>{|eOe_pL%1fpTuNLGecvuOQ z`z$sBFAry&Oke8*+0S~IfjBzJV+VhS6eC0mUe5Uo0rdjj7iMK`aHe8k7UNT)f?)B=F8wuP@LeZOI=|bVf~r8)U!o>$KB61<=@s zw3s&|+uy`;529vx;;Y3l79MN1A7XLd2Wv5C)RS;au%ZNJkpLl0EN+b`C|8U_*X-#y zI!h9rAS~0V0!&kH4K4NcWz^a*TgztoqN)CCJhy_W7d@{gggXd&uSWho_n^ z%T^8CzJo|KGx=aK2$|Z~xR0n>THG!DnJzf(8$dOt36mK;E`SYk=U;lU!eu_TravdI zq6ZzHy#>x)qyl*_+(R8#s7M7GC|r$gIU#-K;5f4%|01OhwNIKK!2&Z|koum6VkcSTW0C)L*~oWLEpMMGluJ#@l-0joQjQT@A}xmV zhf}`2dI;8B>_~t2hmn7p2_itHe%QCkx+RJsI6DUQVFEojO&-FLCmD_db9{dchYQ}Y zn$##N^lXga{8J**f)mTF=`M5n3}j}^&1P$;Hywnb!kA~5wx9!PPH1n ztL1yN9a+nV@L?4HEQoamETt)+mTs5zZ3R!vz~8t}$b+T)kVMxxwlc1;R{pOOkXM5< zUDoAc#?Y{=fnKKNKE>~v1ZX?j=<(rm-FgX^8P{&=F;AHl5s}rCsiUYso$iZ@-1)); z4iIwAs{l_zIE6gc({zI!6o>+=DDvwAs)D_RY}mk?R^W&xOr>bSKy4V{7jCt+;(P}C zgv{!CgYbF!T&KKQ&dl+zg(fQV>#-~vMcG8aWvR%Kt;2+IH9xI57d|PJxy1?W3FkPn z=B8$NSuo`4X`-Pr-GNFQL7ipp%}{L8a1o;@Ks;exnL*1pFAQ#)MY1-36oj+~d)1I; zChK~A7#o_`vmI2r%w(xRgwRyIdWI=9$kx3j*wb`jnzvAcdz2n;fU=tEo60pPHb~#rvO3(uER;)r z+uPy-cJki$*PVSKOdV9A1KRwDN&clyxh?H27mbfQdYj;F53w1<#UCxB?VD!$;2ib1 zKhmm}d1=fDI&AR6U*}sYO7`8L5BSW?9I}k9W)hcU4)eBU@+EX#?QX-q5(}y_dIJe+ zek#Ut@N2{8a_epnJ|lyZ+j71~Jlb>HJrmSBufiaDrj*D#B&yf$hZfJJz*O;lJ7*5n z_xzw@z#7|MFcH#@H&}7MH8bqVwI*WtbszX~?)sUi2X1porgoIfGj8>~yI;s!#T zl_BXbsfz|5YM(6)v=)p2?pfn>$J(MF{1qn9>FYp>2$Vg0DD;JpaCn0mCU|q~kZ%Fh zW8Q~v2wo-xO>D=5fo^lPS^py_QAI#WHS?+@nFVEGuWW#wT|`GNjutxFYVtnAqa92H z0fBHHE(n#i*vIj_5CCE_X!S{*%pVyef#o4!Ho(MWd#g4FNH8O!Ct-@wx_Df}%bt

#-Q)Qd~0k!|-IzD88Bl zj8oGUFWaKYu;<}6`F#yxqKwjx7ItUVY3LT-T!#}`;sgM+GW`JjnXW{5D&$75I6O=&kw;qXsFQW7A7qeWkshE>Bhx7PY|bV>sg1_TZfi1c)J7(jvzy8CQvGyAZRbp-)2mG~L!@$`K|C zjp4zD*I~i#39%4`Gd=97)!jK+GTu(LE0Z$+a=Jv@+K-jY-AX4@2<0$^LClv`ei}2S zx!1$uY<8iv&#+eN7Qu+>#~E5xK6*<+JbuPnk~*Iqcc2~=CWgZP;g30dPwf%UQ`&rS z0cbY5uv8`05jx+umoo~~9UmGGx&<6tQsPT!jYR8E5+e`suxJMP0-Yww?3i62O^I$G z468GJz)ZIBbj5h6Q5vPew9Np3dNu@SoP#gnd%5TbMG>s`UESYKMVDtIcE%%1tR`&L z*nR$!@m*EP>@zMIS{F|+WNYJ;f{)@Gy&k#jq1wzD-|b(HotJDmo4xWsjNL<%AW*Ue z;IeI-UGB1N+qP}nwrzIVwr$%sr#3HQ7PEN&;BInpGxB_=s8(V`JW$5Q+o;&#gLtIg zACA_;&YU?SN>Vov^F{+_e=Cs>h6iyWpbYEpSZTMs|8T?5heqs1Nosa}BX-dzSY%`Y zQYYF&Ixz|=TjR#URcG23fnvAIdN+l^6yQ4R6YzMN5A|kSvSK`8v z2k+usk)1C=zU_*bk?A{9T9n04KNIw3y@LB^9)#JJY3kzrSn%-PLs->2KzID-hxp2|dJp$-AYef70)+2^c%S(-xujD#et>PpHH7D&1aiIbzfDmX6$HM( z1s0GUiAL>@C$q-4dIR%g-VacDrbzZSEON110BrggLf)ujlK0D; z8e!S4ZGJ2|FY?cT`N5Qyr#aL=gjzd8#Nda48QDIq%bc~zpqc1I#^76U-3PDo6EMrb zu2fZuGS{dznC(GKF_f&i$Zde*M9u$x2{4Gf%QZR|-`VvoFOuh=$Ks%WHGPa>6$ZUU z@PxHicFf)}UgPs%sV)|wuz2^4NO6{OYeG72Leyd%_tU+dQ|&DD<Y|0TZ5(kInAJ^R~r<*3V1yx%xmE0FxaYv1M~gsa7oqh%xCj6gWe?aKFSe= zj|c8D<=O7XezdaV>vh6@>CPr_Zhd;JSyD;|rpN^#1Ab?cztQ_O;%~ ze0o;`r7Pc{(BudKe78G7!pMc|v8i-n+n-MW=TJS^skr{C@pG9iG&Gi#+V@GOI85UE z{z8k?4$+hG8OGj0-Uaq&6=4aU)9l;bh`(KoD@eqWT_`OI%<4kxV6aG7(er?M!k!MZT+j|J-G#OW5J|LtXAktcSQkga`3qQzkSa(MNrtjjGP_l%0 zJ1uRaknsn~9W#C55H{u(_ zZ|Qj_HfuFGJ5c!sEs>7q15TnUfL-Pw_YIl6#@8 z#{!8^ASq4LvL8rLq>^PMnsk#4$$Np>EJ?a<0#x5(z@R-Qe2SM=dEB$EzR~pNCo-_v z3}EX3mxmwWXP1|5i9Mui=SB6#{+w8#ma=4gV8s~NU}`MObTX;6LZaW`*wQ~^H>@;M z6yQkd_(zYzzEP{zfDh{lZoG|p%`Fva31DO>Gnx+LVsi$264GT1(#MRhg+eYPaWnI? z3jEwfdV*1K*Y^%22xv4=+95fZ4yaBFMZv3d?tS|YN@qLg`Gnbu-&g6(MVG1TB%T9t z|2$yfQ3((CIrkoFYH~90x1xW9l;<7?&e&j5Y%Rx6UT`wNe~@ZLJJ2T&Y^S0yHzfpN zTTnK4upA#^!?<8rf>1$_j~&)fESqNxxWEDK9sWB6qmKMs5-U=;ugw6zTE$m4HRA<- zANse*COYdUNH+DVH71$rw-f=7omKUGWptwVEjm8*Hu9}Y6+z9U;^}~|6lxYuQe4Qg z)Vums;xU}Zlz$bEGbe5EF=$nD5OJSm-Mez3r=F_?tqRkIE7WmciBqRo6RxEzoS9n@ zQ7`2I!u~q2`!ez@-N!H?cZhJaB^K3-#?AYg#~BwDT8}je zsWj?zztT`nqG zdFx2#fR*^blX+92@xd^*JoYZ*6lXD?l^tU?I6bIaXuR6ad(w>seLhBft^*u+Jcs+c&@$y-n)rj7STpJfK{%DO8<*cnme=C}Ev>t5ev zIv|cp|8U{a!iUDQu8-*9;c5Sx$uwd_k z_GKN&$HjX_MT&L=_PyNqgf)gn94UcnGyjJO;2U=q2d|GK;B%VQj&iur5QEtlD>iFV zps+7N01zRoc26P8OFyA5!V}V@=I*O|8=~c{)!qxJU!)*zj;N=%w)2ywbCi;8=+P-j z(M!-;2PT38#)-<3Gw^+u)L3QtP;oScOEo(_91{g{MDAbY zdH7IxL@+@-Cp#)vs@YIvs+!_B)6JWYA}s1=0^N_sB#%$UYS_M+U0m;&#=)4Py0_1e zmQ{dZAUR}>_q@)9bvqdR9K~d_&INrmgqo0IMszT_eH#u^NAAiIw~WC(B(@OOh7Adg zy%qG|E;^rC_|bGvq$?~d5>f-vF(TY+MJA`@Pje{tS)xK)Zxgw}WGqI$CXu zwAf;7H4*ina%%D0oh#Q#G43w6cL{L~#y=l!sNWCUz>Yc&aW?`ZgPF~XwUP`8N26I| z@5#shs;o*IUudiZLxJ;|98d7+SDHZi*eK6#1rui^9urn2R+Q4tT`_c7#NUAVe2!>n z?lq$yDwT8wCCPU}-8}?qJp?*1B3i&ifWot;yDY?2#>i#w1f~-hwIRYR#sxr)Jo%ka zsFk)bH=HRpjZx8*GKSfsjQ`*t>Qo&8_eV@T!4iI!AKX&!9u2Q%%X<;oFVE3Yt@E-F zU^m|$2dYi??HSf19!NIG^Yxfg4r*H`fXfnJpR5uzvv)z{odNNvG0c_UmySwDkRsL8 zpbM8nu45sC?`X1mPH&ZG^5b5r&l7;+=sdnyMW&AXO%(@k3~|8Z_1w}69vBg#3eI=&q(+((Hj57dZbcPBE|;Ygr>AVB8<{{tD_HnHI>- zeD!d}fO}5&b&$OADQ;Xy$`KM`I#GFF)i;o1nqxZjUE8uU7ZM0a@yC?>T*kw?ynXRF z{>-mI3d4Nmy?@5HHX}5eS%PZe1M`E{N6y{I6@E;fl*m&hSpxB|1Mf8?F?!|ajZ@<7 zYf*>agK70P%c+qu5<>33%7zdNz!GD3iil(_fvP^S*5@#3;H|cXfT77_V<~_?8XEpQ z@1n7K{$A)z;A4)jHb}oI_k>q_C~xrwc7B*ur(Sj?QvPV^RT5bbOp1oGtE+@Nq-moD z-t&WnC*u&_O85I$6w|#}v3&xqbSbb9%?|_gr!*`q1vL-OejAxVsKF-0Js>d}t-q!< zAf*kS7)Bh+_c=zk)&Rxni~BLjo)vL4_Zx&JSeZvoJF`04|$hal_Gg{`A?vffF5^y>?Z^dwuT zg9Xd^YxDPVH}dRs9sOC<6idF~Uk}IqpA#s4o+DI_1WPMpKXf*IAsK~fiuDA>0kzS0X5 zBQJS!e*)EiG}I1n0lXuac&~eckqFE>2oVm7lX^nr!m(wwt)X!c)_Hg3f_w!FbE&9B zQqDNy^kUfrE<=NhjL&|L-TEU=fFYMsSkTy$7wbxgm=OykN5u7rW=WHuB&l}Z!?M;g zJe9VqV`gdeWH;r{Prl<}b(p)WNxUvBSU;D3Q4P@yztOYX)xE@{MuGEnTJ)IQ<>oX( zv7d>w9&?+kJ59!X~<=aa7_&7ICm4(y;p4w!dqP_K~*Ly@g$(3ovE? z=p=9vk`8JTS&-7A#vMWz`P-K9-&$0J0?BfO0CzZ4>8Yoyzqwb8GYv&eUbb4-B^y4) z7$UV@7i=f#%cC;Urq-F}A!?SFoGk>%n5qk!9UY1V?`&3e->kxnRKoDiyj5zCBK5e( zFkk}`DxMc-3*e98N3l^K01nayjoL$k8#;Tl@m`0Dcw7D?^Vo#XB5CP_O1g8Iqz)MQ zGBHWK_}?WMY3-$5rs?qc`Wn22nX16f^MoArwr|NxPR6;?@8x0%O$qnYnhV=MFlF z*V{nXYGfQ(J^06}+Y-xUc&%}aMHkF3-hUqtwwy+uotisFAX)%zr4DMhadA!sGNblJ zAkQv#J%EVLJS~IxSF{HOVA(K&gmGi45@ZwLD(HbosJ&SC{+lPp4pX@_6EU8KO5hgh z4L*uVvVKkpYpo7(dAMfVIXb#5I0QS=RVy@7vDA-=77a#Wh4c*w z@b1-p#l^Uwgd1d_&d7_pJk`uQl3WDm-4+4qEkW!eLyblAaGVw}uuu&fcQEaf@bC9u zjmL2^Bc3!6VN}g*W!pD|dgf}!VBe0k+H{R_I`ZV7#3n^mFRU8;(U?6F>XHR;B%+Q) zMq-{AdTPqENKi7sU-W4cDBNaGUs_1oMa>Z$?}D!9*T3-9+P`KU z?6edNrMIcx~ac#t7?OHX|e&CY`^7_k>08KxxSMo=vgOpgulaT|JI<;@SkX>6O*QMey!i!=17PT0#qyf#rWVwtngb2ukRc{n&2+1 zZT87)p6|S>r{JSvhV{=0sSl={AUuPN;Kl5-iGGa5F%C-KDFSwmg@a z@!$396IM_hWdn^lb+}EI!!E@*8d_GB-_ne#fkZ61e0eYljH@&-n7A`ygjk z!*)IkEkGEtwQe@zpjyaYPFhi3&@Z((o6DZ!k5;5LZoTU3h>t%{^Lp6CE`>OearRJO z6-GH+V{@T^XAJ;=pw0$_SQ|Nj^-0uoCQKBM;ezCMIh8R~B)t84^zkgkr?-^)zA~av zV{LdG8g|({)nVQn{%LxwTH{6f3owY^yM!il4keuzyZ17c+OD#2gkT$Yua^9G>_Gcu zfh>{)TFRs*0BZh=7OAWXM27MhKu)VOlsm0`QRg&oKWYs30s}lApy97d0E*n}&CY&W5}H=|a=S)CrkPF8%`>$_?fAvMW2KWd8*A zW^ADH&1y!o)<5~D>d>Q2FO!+6eL}?*rD!DPD}b+yegB6XjZR;8>m2yF{UWc4hcy{( zI7R~m?HiZNCnG2kiTXX(0Yg~JMB9I&Uq|*#<&lfVc+{HB8?kgChLIvY@zcK3bg+A@ z!Z<(9GPi7xPjgAhGo)(~!%?(Ce2NI^Y-OD>%;5&8|Gf0iP&h9E0L;I&ox;mVO{4DQ ze(m;XR40Tv^C>+dRMI!gN970k{W|3<=Y5O6(%fJqZ^C>X9b4WukW?K7X!-}i+V;g_ zs%>OSozS(PxZTp{RQXlz(H2@0;r?v5+B8H!rW28?V}` zg?|D1Y9-w4ah8A|kRdbqQLRIXcx_nQ!m8h2J0gBeNV@Qdho#2f^Hvsp$C_jS3&9)x zMFf$jdo?f3vV!N@v+R@9A`}Z^OUOWW9HjW-3O9ZEAFrH=%o&V)RTxJjOE^W=9Y(2k zLZpg0f763-ePP>$2#m+#T;R|Wpz>4{>kNL=225-lzTj9zq`osFpwJw=1ezGh(Tv+d zp9cuF(Vnaju%F7nYC#Ksvx;T|-?A-{Gyw4w6NLDK4&2_qa$QQ839O_u5$aQlu*i;KjmD;32hEf{VR1FWHpTd#zxoix<47u^;LDb8 zJN2PA+Ei*XF2{Mk8P9|d$c|Kl$&!2(mGt*L)jlnLpp(;GZaFtPz*1xf1S$h)V?XDO z04yYl5cI!8^B14j&+u`(iwXO8kuBpX+nw{t-gn)fxmRPkh=ey}d<=+E-ZxzdgfFmT zzWuS6DC*}6 zcIwMn);4>Tann^8i@Zl_DoZS?P#LzF(P9$hq>u_$+RpEOkrZeq9zk;a)QIN)Z6m1kw%qSy~H zKG28nFXS63=D~#$_sFV$QYrlD0VCQ4LmRXgP?(sh9odTpylyw+5u-3lW9|r8gGL8q zGB%x%OtL$aGg(&`pwyq(r+Q1(BLiSd&r^NpBrCbGgDqmS9K_}BtyOR_BhHpS!S_?$ zj*syko8Z|IrdKI3(EmPKbe;8kbo8r;W#=#vLff3XH0YIFP)^)Kzao(_ycVb5& z8q2Aj#q$kf@n|IOa=`nkXcN%;eoO^3)Y@%ZGtB)M0xD+Yy@8SwM>WFxsE8xC6UJA= ze1*De1{!LcXCMd6>5J%3`Z?w{ocQCgN^to29QJqxITMeXBx1BJle%VhM7%6v5l{Ci}i2w^h)2;5@9UgzSdY zW|a<>nS4GK%DKY-^k0R{tyt;lF+3}5j!F(TY@Lm<>r@>_zv)bQz~bTr>gd8 zQjvueqMKwP^L?OX^&p<_obl3GkzEGXMv$!q5;y|lnO9O--a~1h&Y>LK(i+|ntNcSz zc>;qH!7<-j+v-wJ3Yj3&V`SXJ|IA)gOH&m0tiL&WbZ1aTai8KmQbNu52{VMnd%;mw zpWFQUOrToeC&{4pMc)YlKRbspibgl9rWaE{adlqn(s*#0C#5}FV3PwQq6 zXywm^6raX)U{ZV>e@RL;z=-GZhPrKWeS{Pnk6}{CDK%63vDLF98iQ=im(oj;Ao= ze1klK-%#W!+Qy(#RV^qqmN5Nb8R6V}Ts~O%yJZ%@diZuJ89j{-rfbB=_v?Jh0rpx& zVvZHJuSp6_jEBM3ZcfuhPR~`qc8nQKo=K=%sT;N0#5g(y&NvpzI&RRA#4@ITOCzHG zedDuZ4NsMfitkL1nlt-68TH<7+wt@S6fEkWg1(l`S62Mpb5ip;m#B3c_5Jq@yfwkjCZ{28%{Vmy+6kyKbXf;X^axbVLPYCZW5=xuFr{DkJ!hB4cOi3Pt z1AepmD2wuQkuWU57Li!877%aT&7r)sWSrxxtTI$b2&1s?6*VuJyIyWVgs=G+<<^ub z@JLW;DhTQq$gF{m;|4R;U`$nwSU}!-DzHc##3UUoHUOx`6e}~^SX*9j?7xL4^&}XN z*o&jqz?0Ftd(E=_CZsh`4rIRK-(M1@E_loMO^<4FF9T>$~ zJJl;nz>hG>G$svb(tGL%er`?saotAL_26#|s-96S;*42U86*RZ2M51wdadS%`($dbgbST>Z5C}v7h>#6sW&fI%MsBkhC6!1xqD3vA4|HYz{*?VB$MO2> zr)gVLoobBrVQMmGZO2N*L>pKK)U%aF4HZuC9_kj56i`Cr9Vh^RKrRd(0%g$Hm^p|b zf466{wQ5)|2pj}1@e`dN5)h2=#(JFKkXsfS4%o~?01!w308m~WkU^XPfdB$T;xiON zR17GIUkAa{4-KCW84lQUxBgGxmKP#|DEXmx`p+k*-Ksqh2norc+cyL_MQZ>e0w)4Y z9;g6^zxEB)x_=%3a4RlI)ZSi0eFb}rl?#0WgkSZx4obL zFtT3^HpVmg+gL6LUaxKgAjB=?XZCgN=}tI79d7{tFH5Y-iZF=|59QUm`-Wh42lg7wuGJO@ z2f`j;=V$lb)337^fTSN8=k&*R#FtnL5YUf%5Du~qlv6;j^~b1(H4yiE@Fg|Y?-d{i z=%$Gr0O0%k^K0f_N9WlNWAO$59sgybR^O)JPA&CgCg$gv@=w1vz;~xWKY$KDBA{PT zD;u8_2n59E4Rt%gsBS61H*y7_qaQHIH`nD?(zl~tZO?V?LG9Kq$fql<^=p?|A3%&R zlMNsW;QE#?rHS8Uu5um8{Vz3;;751!Z(GSt_=)LrP$&jDDQKwh^m;x+R{c;`wF z+NTe+-j5_R;7?nFhMs3w>BWx+b6nmBx11llzz-hrpdji#aPvwq!By5b%0#Y9;f^F& zaBpwB9sKBxDrhei0LXXjjZed+*0nBNtf%nz9?%Zmv~Q}C|61RbuWedh7zIEOpP!e# z|BC<;3L@Yu^k!`V_v#5eEb!}_p5380#BO&NpC2%e|Hp@j@DSkVc#pI%0fRn3&oQqU zP;c!6YXSoBZQ!>^|I6gZlgrl#kzK8f&uz~x_rRI197^xaCp-!O(5t?$VEo5s-G|SQ zxUVkOHyt&BT`ue${7*N^JS59q#o#(5B3v%{GS4j|v_C=}cEs36mJ-5t7Kn z6<^G`19!o&>}mB>^!AumIWhbTa-9v8J+@R`{r9t<;zCT$3P$DH3(?+c=lbtS8T9LU z&hfpodO9d+K^V5j&XD^KK;A9jC_$}RPB~9z^~g=`AxLM*(V9;1C9jN-3Keo9beBh$ z3nBc2EtRSJVeBFGAf@RBw2kAQQlGHkLu0pIVUI&WCSM;0Q4Kclk)rg;XzW*JowCgx zFG2df_pY5#EJ6NQRwinu<3*U$lOkkBtM3R;%nYT-Z@TdnMC9}vN>4IY?FEoLPaGf4 z^>@{NG`gW%g`$Lvr-f1XoEA$Tjkmd?0 zh~*CqE_a`1jC=Gp;RilU`pB}E2=j3)^Os3s*K6CJRMIjy-fyqp|X_%I}4- zmD13Z;!ZyE?mwcy!bD!yW?1R&{xb8418w^th#XYm$AI^`3CXdXZS=t1mHQzfJ8$rV z04fCmm1s(C%jQr%t*(XgW6x~B)qlOajhN11zYJJ$SAWnN@evnb^ZW1<3+|Zl7q~^6 z4Xsl1IhHKh#a$oA_ zg{>q#8=z6#gR(TtsXUXLhfxtu?#f|VuzTCRC*gZii{;*@j=py%Slx0eoQDT7+x~Db zqrGfhlwM~k-V&PwMvHPRbK>ETw}Xi))8TSofH(KZuiLQIIuQROs=ZcFjEMC?Kxsc$ zaeS}au_CXBjCkK@Wv6CC9Fo(P*+DWK5v2Fwz+*I1meq7JH(bd=!ee9^#XRXuE51*k zVg~hXDRc}}isBu%hqBW!OgA`DRm zLfX++ofgb=A2oua=Ek#~X*=dgYyQzIZ_VZBktASE*jIzRx8_zVGt2t-zNlgxnCwQ& zpHAH00xy077wK6Yex?{ox2D?O!QyR(R`%n*Zf_*IufEmceaN$T8qy!zHlDx@Mff5Z zGvROk^@rf>YY0X(d^}xa$F7#k1f2(RlJq5g2k&)5;!>`BI{318#Cj^Al`L3bI-tDj zysY#$kgLsn$POdI0Q{Gi!5jXdTzHytb3SJM2|Ai~Lw0mk#BVE`ZZtt)jnR$OL6;>W zv3Q1n`5MKml}tjNC4B`a{c)~*DG*lfw6gf|BTByex2eoG*)T+9(2{0l5`rV)?6Uek zUK9f^qF7<4(L=Tr%zoTCFO`a0jc%O2nH0TY-C>Nz&AoKI!`#FSlg z)@BPpMdl#hMPQ|Hdg$B>OhEy&*#_bI1Z$jeDhM#P%FZ%mK72UIN@^!4&v+fc_iHx6 zZLaUPUPfwYQi#DcT2kW@p`vVej=E23Jy)9GK5aun<+Fp@ok5@LjT0pTSU(2k-G&Eq z@y1V_EHglz+@&RB&Dti{saAZUcT}Y91ewGFT7YC6CLujvr8=Bu$T3)4%L=!D#6~iV zCiiti8j+sEP`)4;S-vLn^Pm5dP(NHE(&9LjC6Qfm@`|=Vx1$NJ*9)R(cm9PcsEfQN zUsa0=HPKRxmVtI^z=5KFW276pOSY0n@@g1|uZ4N0UCDO@hjZ%ag{otp8Z@T}4N4?e z#Uo&%mZiS^-l-AuKY|k677T%NdTZcMSK0J69sLB-xf_^&AfTN+PR7EC%$Mmd8o|)b4X|5j9KoLknDd!eiF`y8|X$XbOU1s?8(eIL45a1v8;1) zJi8IM#uYT&rX@IyOx&hxe9>41F1R8UAaoJ*W-9_fdESyoqaBj|ls{Ak`}Q9z@LWD< z?P>MHfkF+X*?9^$Hj&Zlw-S9ngv+N`FwTB>I78tC9}j2L0 z2>m-*O5q(NKG>2bJ}_b(LE2&})A_gTNS~48UL1Q90Sd(=nI}+*dX87S2v+zvJSCB9 zbhJ+DiuicCZOzP&ELS~JA*A+Tv4(o5<=SGn*H-qbpyea)21O-0Pxt4gi$UEzD-iOjvxlSkny$LU`Y zFALXhDW})IdI--#V(lcIMb6gDTiVhe7-Z*Ie?v#(Hv0!{HV(n5NQ5XEvGzeqc0%z! zhr|23dOGZE3zmkK$6(F{!o8MvT4kPUb^+h>)Jz3-D8AKbYl-Tt6@v8iXOtF`<69Tp zwKxh*#EF$neDQg=?jrEm%`n>1i#h#9ebebDuaMmNJGtq?vX|8g@q$6uW9Toeko%?G zIV4-MV|)$yu6DR(a$4eta434yW-KC)t7;$(C$qFKo@Frmu8Bx=w336C>ZR_FahXhS z|8KV@U9-~A!&jpo!Xk|ka}7m(63)_c&E<*&rT$7g+OgC~xJ>N<)HNPeD)ZW}Q+mcm zrmHcWEn2aiQZqmH{pFlCQG9r28deI9(%_3$2&$rcUxWd5tTdhYazc>wDO8p*Hd zyE`$XWYoWcY_sAZS)cOSoLCHH-x7scqNT8!N#2E7CXN{(8uNoF>56i`k%iIf4aHNRO|@qnGBeO76C6E5%x}Wo%e$#7D6d322683t$co9i zOp$8DDNC-;x^0{xD$93_L_De?NH^><%V+f^JTHKYtN4#5op+QOs;}lR#uS#Fj_s|7 z%ah;0qHL)~eW+a9+hpxULi`sZD=b{J3Fs;*I8C~tgJS=@78URqVVsSyGl6?Xy@VT6 z^{EVGSq6#=1BerZX7!9todh2M&zGp?giWWyJ-B5V`}RwcG8sRE{nI=H3bm;KPrP3u zuHg?(C^>9~4v57#Ni(Nkgf)9NgZhSdHSFWD7(rtQpTCmK0H<)cWW3fn>Kob9?bEU% zGzI#}Mzf1ZmJ6=m{jwjbn{NLOT=b5Z3^{MoJVV#3xZp?UM#3cmDNlyRa~1NAjhV4o z5}=>%68OO>E>yM&AYzDv;tFZWAEK{Z+qsp@fK`d+l*=B0XVhP3TbUxJ1#2C6Jyj}m zTD`$S%v4FF>{ql79?gkVw`k>V^qM?u8J+jeNE=D=kPe(-j7tHnio&oS0 zXOcUsd=DmgmNU1JtC%N`)*j%9?8p9tU;MF9+W2^7i^&PS@*W-M!By-6y}GR|YLdN? z0Lh_PR+UZUng3i2TX%Roeq8Cb=M2O~MU68+;*0rfjFm4gk?^TD`5AsMC};kjK2Q_V z3+>V7Zh8ptk=9DWE1D(ZuVKFj#ez2O7HM_~0Vb`4=I?~zYJVU(2)g@crd02jx~-OS za+K3f6}pMp@f)@@iHg`$0fAJL?pRUUkR~J(#F!Wzm{%ERz)WVyc?mx}X_fSe$Vgs? zWc@p8>v1|TbV}wVKEf2;lLhk`1Dzm>9mDw22$qS?*H^w95T>74p3uGA4rY9>7GB=b_ zTSY_EOF9r5$wt!mw4$Fs(k2g|@RV4Pz-T{&fJmEv@yMnRCM+ZqS|UNMe7mtZuq>2rWuzgvi!h^ zc`ZoAk6vtVk7KgYXkRT4v`LZ;C(#Kk85 zHX&6RW(-7B`-yO#4fP9x5P{V0Z~}p`a6n~z6wgGpiXSf%GPs9f3rK=yx#9_zA9Zh7 z&luX*q&Xbd2BI&9?>s>)-?rWj8JE}R1SrM+#6|mP&B1u2S6s}DhaolDf`Dd$nB7ae zeJki$Pp4{Qz!bBw26!ebcK%)gugqf(8y+~#01uz$4$)AvE;CsRhCC}hbQmpRh;dMe z4&*XHqE7$h2?o)}i7yP%x*6=knK!WM4k#yV@HGC~>%bQ)a#>LJi;0;@O>_rYOWc{N zqmYFyTJ<{ALGh&Oqd8_|?a)yStN2@@x>T)!vu~w_%2buY#>gs0j__d}F&c!3^b^{e z3&b>cb=XlZt4%&AxOoijV5lix{<(U(b+Ms$30>%lMD@9T?_Xgf{4gZ>-x|m?98O(B z!vcY5n?0Q)UPI_M@eI84fA3>3^_}zr{7*?Xg|jG2suP_UwmO+%_YPmL<>3)epB{OY zb>=CX^&%pwl=Po2QyO;GM%zax?Ch8usrpQv-jsHM8LI|RCT$|a%3APpGx@PSjBh~X z&)~>Y@A@`?X={2^eDs9MPuWVJ0!UFrYGU_VQ|y%I2@mO#9@B&MXdV3z(t zG?l&B6Jj6a5jj^l+vxQ8CpW254EuS{(y&`5xVq0|HsLnidZ>SvOpUIwOQ!4pF{zR12C&oo@EgcglLgGXzgW4hdL z1`Q_kzk{fWPkAWUnUfF4Pa^X85B* zPPFv*8!=T-QW#G4;OjhMe3eelb3q0>2xpba*I&9d2F7{mVP1#n3^OKdwpt#_iM!^t zg(B0MO*(=Vy8`zOH9^acX@AQuCauO?AkY45$E%2BCzG7+(IWI(SDKX=v^fQX$0zd; zzA}4pP#zMAYen(0k^(^?MCosIurDYktFRyPC()^X88;lnGGV6}!I^gZA>9XB5^6l5 zN2!DfU3(Cpsp9VFwPL2pfxm+b}PXIe!_iED-c!TYa zgHdbTh3{H73^A6HOaJz4yW9~KI4HpV4obu&$L8@#z?V4Fe7S1gjob8KMLeX$3RpA_?ae0F= z+13_if-M2i&ngV%m#YH$gC@|5dX-*{PfnT#&$!1EipUPlGjwbW_}a2GU@IqsG@rY) zB?g$1NSncGraelNFAx1}jrlD~>-hf~54NG<(!(!cY=;k_uzPIEx8@3fU7SR9(C9Rz zV!rzW;2EoP$gQVOQu-_POhnu?7AeE!?IYCi|h3DIAQH)b}1FW3LfHqqU zFB|A1d2M7MuNDesV4do%@NRR#CN0i(8t>Kz=d2g^dXkW~mf9gP{@~boxgdF&gWXnn ztOIcG`MJ{V=ud^R&71rVTenAPbJGh=kR$jAXj}GLEmOL{7;>^SclxL#)Z#4%hBau@ zY;P@ui$QB|WTff^!k4ll{vBL!mlSFmpm}>Rk1&Huylu(&CYijL4X=lbFGlvmV|9KI zz*D}B1!+Nz^V{S+y`J4La@tjkegUfGt$GO$CF&Q7Na(vii`6pe3&+cf-Y4*_7uSr= z=k5m;S@1mQ(kE%EiH~OF!&R3ET{L`ZhoPCZ+v$);5x%(WgM2dfF}#d#tCqV_65Ckw z@v0CBdceN!`LZLIqsdZrv=u&XB5A+1JfnXJFJyYW;KX$7`=W!Bw!Qxy;Tx%@ZdKw5 zJCr7TA&>}3k3{7bj~!J*X?MujNSjbA1| zj*4@xf}&x32Z;?udr%PkD%^yE@AQsrIUsk1;1P`}4f>#*s<`B$wl)5b%)B zjjLAbEmL|Tc59I(_A4yboXE$VQ6m`%kThma%{jF7HU)%(W$2o(d+Skf!Jmjihn)Mz zxY#l`i)k%QPNno1{f-~TL}X@REpq_mv$=zrdZLDzHz77W+ikhYF$Y7@5PN9Xx9(J5 z{yRiQ-o5Poj~m&kwDpdKX?qI{H)|X5{dvRrgjn*#^a(0=V4a)`Y)e8R`%87PtOL5r zF3Y~g;OyG{9{alcwOj2h1cIHS{dGC~STJGqOKm3deh`-|03rIGbmcmqZ;@N#)us#b z`&f=Avz`><@~)3AXRfwJ(HaPCIj>8DhlZOd$&(Kfi^Y$vp$pKF@e=W%7|9YD8MMId zlbqzByI_n%J^NUNu?EDaK{8F4X|?XL7G`xi6WY0Nwd-anK&)3dDSNTY5HcS>=c&C4 zijf1>4*eTSLXy}ESxhmPX^mzsV1&>gE?{Ik z&qy+^s;c2!O;d1?ZgVnVvLY963$gk}Ze7;SKvCqM?hY0?H@dj+#oJx8m0Scgi}{3u zf!xK@)Y&tQZC&fl;YLwN^s?>_rtxp6x6*b$4FTuv6C_lR2*uvz;4}vNA&s1m;qH1KHfl-h%mknE%`K6z%!Iy*?({Pzsw^YZH04~SAbD3`9Qr>ji#u7Cj z0%1>`jtp+r1ABB-nGoC)eiR^3cV6S{Lx4*(BXId6I<5*+0hI{gDvj#XLY!Ft{RVdd z{+;s#c)XwPFmOZ5dkL-a8e72%rP*~N_&80jz8IE8gPr*J5@Uulk)@$^g~$3?#4WRpLQ4A-Ob{e z1ehjGs{upZffgnkNNydt2X7>)j&%M=0F;U;JSzjURm1ElFXOPuP22n3(I7rblJaiB zPzy`njA}eCMcq~j28j9H&u-{}9UG2y)CbDsVykRWoK7Ku$^M}@hpSDHVZ{z$wn3ss zy*;HJUK#0c2T`L=XCppe}i_!OHwSxMe{$(;P4!PaDH!GhF}6M?JdAjuDSuO)!$69qeidpOaVX3N;* zP1)VzCBZ-s)f2HGxY#NeXePto8Uh*rFg|3Zu|V}YD2j4I;+Dp@dD8?y?-#bVez%8m zXT~vTT8H*=yt&QF)wg2&err$6A=Gm>a=_=bT-dHKk$TsJs%m`aF`lBMmU_QJ>v(H< zM+-#qq%z_ei;p%TmavEMBoZ9Tk5V4lVhIc1yDnzP>WnVW<=jJd?rTgmTCMhuQQk&> zadi;-vTCVX7J9}R`sC*9>a8M=7Rs^#@{9y3e3eJJ=GMCMv@iQ6ahHI2*3R;~k;rV? zOC_~caK^E6W=q%;DsOxkl~6~ah5Z-7Q){ohj{+?s@6!?%R{qB(=CPPP)pBOrAb(Q} zs$s6RKO(mvkVh9TnP;zscIHokvOcv%YVccbvTc7illv;3gl6KIWz&dWF?|Z;+BVQ- zc!wkrf5zMr4Mxl<2b6!&Lu3W@0M$ro45QRH?|$4Ek?cB|#_Ed5#4?r2faBq5ljd)E zJVh8N)-sGC64A4~vzT2Z#-gSB;h$tJulzlu1h@<3I5$%eW0`}bMR;l=t3(X#qFTGI zLAR5ZB0z2#%FVE&BQvlhfPD zc%{%z>V#y~gvi42CEKCU{PdUfkKd&r^kWuSa|te+v%wB1}kYK zQaDeOPtMHWu_dm0DjH9mk9)9R!p~yk^va3zvy#B~owPqQqyX9v;LM z!Ka_+j;XvOxKXVZwTlZFug~OQ7ewJ;{gLoW_O)S-c4|-EJE7UR4ZV4ay9Ncu<_qW) z9KarmMkgOO--*0_p*00F+0CY#Og2m5A<4c3V@STKtl?{Q-9L%Z_k=_>24)yn!+qiM z-*|S2N|y7F9xyx_Gb*n?MiNTw6OR9ixA*2PM~7>>l5Kd%rtoF%tJ|%2&c`3C_*gBv zQ6!OjFE<^gNX4!&es7t|OSdxP-k3#+I{fA;RwJpebbH$8UhU8hf=E8wVbuBi#G<3p zv+Zz(=>Z*Zz^}z6XE3FGo4pIN&_lhmu>=;dS}h3p>5oV~Tcyr6k%};!{1XZD;%R=i zV3!L*AaPs|tnd%i*ks~$l8GaTvIE}I=A#)*%3YM$dU!4f(0|6 zXqK=_&oak|ud+{FD~+Vt4Pd=0J7L(f9FgBv6u>+`Rt3Le%X@uzV)(t(-?vBplItg9Y^Jg=7+zd0)>< zZ}1r+2oH7so3(_C2Vbmxo>L^~Vzsgw)#9B2;h&fd`2Df|Qp#yxd4R{;)hb6AI^y5t z5^Th$T&~xxt;MhbDKj-O{T*pu8n2y)DpuREu)?0x6c#yPamBg!P`O{$ScWHgZlS+;$K@L%WJ zL!gAY&34h=JEO=*QC}LpCYR(ZS}T=G*o6B3#;|K=Nq%*dI8cDJSPeyBQD+{$6A

Z_eF*iBN_ZbQUbl_9G*%`jcU4qH2|n5y_LXI({VD zR;sX>&|chheswJb{OeX1Vn7MKSe4yP(>Q9`cm`&3QS$C(vE|M6bn#60mr1b?-1l+U zR~`7Vq+QO7X;6?*2Y4kP4h(!CNGamy)_AI35+|}rYZCHOh%0O%@kR5ty(grn& zBb0FnzgGN1%hT{zSA2^j9%?Vg2yLd64Qbxfpk-RP!-6Kga750q;K9bu&!Ago$5)1yX&y?QyBtJZP>thdS79bRE{w^o8D^y zlSs;g^cqd>`W2fxxaNnszWr#V`2IQSMziP59>OM5(;@BbOa(! z_W6>weZ-Sm`2 z{j*EUz-qlS4`(A#>)V=)wNeQ_lqIztht*{!OUE%=(=MS%QdR<{{2&Lzem@N`6;pYm00*K_2G6YKA> zEP3dD0Ww4|`)O`9*I7SSMhfD>_H+14lj;Eg9O+Kc8U1XbEoAR7=U#7k#ndi*gu|QR z1CJzb>Nfv7yqjoN!-@?Qv98Yn8C}|God%~j=6LbTxPpqT1YK&w8g(#Z|3Uo@#D?yL zLUVPY2*u=W{`ng&>EiGUyZ>?xH=B77C5M|#`{dnVmUwoF)^^sirS=$KkJl^Ate~^0 ziqVpi9bvdtGLzVv!a3zHO_WZU>6sN++8Jtr&A)ZLM%6aaf<#RW=CBNFaC{B2%?kWJ z-ri+lA|;g7baqH56z#2VSf}V2Sxd$X7XAs&e4J>pE%>n+oL8*5z{0lBv4=zlVyb*P!kSAtobESD1zETsKX6GlgYy0gk?B8x(?+oW3RpaF8 zYjTpKLxT}YP6s%z%_g#c(ef4h`&$IWd30uN)4ryyEHFqR)CLEu$-B7igJUXp$EK>d zWiI;~Qen>=myJu|hvEj)=wf3!w(~X?MlYNrNy9-0dmO!XQbY|-xd@vu=G3@DlR0Ks zd5#pyGNV~{IJaIUo@5$GBZ~F_Scb%xTP8el*{#|`s8sj@4cy#0g>+pa>(kQ3%WY*M z8isXFVevj)%mCQVb*N zg?|FT>gw4XfyKr1aAY9wU)==b9|PR~5*Zhh1qT9DAH?7NOE8H225>M+3(w@wO~sE2 z2Fg{q5IJzQg@ccpDjPTTb&AAqHwmDBczkU7g98iS0LsNL9a8|{VMHcXe|;EPI?4*5 zl1}ljU*|`U;!IDAlVklJFrc=!wtBQRwwfONj{umdKh^LAVm^>72v@uR3_u?g7&-c8 z;IHy%r05^{reOA;hN{8o9PJpKet)qbm|5M(98fFfVe1NWs@BM)mPhfo`lTWT~y@ftRf&9Lp7#SIZR@YH^H;82*eb@#-U}Tcrdd?0G2H@xd)4uRg z*4X+ncOx{T@R)`PqW#y|7{ElrNr1yKpkK$c{e5}- z{Lc9%r=Y=F9Dc)oKD`4bFA^y=9i{y!e>TY|p`3u-8}01@)Ym%r0d!?)0ocgs`ak=c z$T5U|HbBqv5QOoIULb~}*u;|f86&wdx$al`)@f4mL7 z{8m5h68!oB{igg&W!?X7#}_xn%-FGg+x`BI*;xN+aQKb7E7ve96Z@VT!Yu>%=u?)t z%gaas&l1SC`CX+tH2z`-CzSt_)wc=ZkR03|Fq4cgTbk-O{4iGgV>ND#FJF&1jqq@( z3Rqts!2f&bl})X5IhHkauaMBEvo|*IeoI1*j` z3BdXFhxf$s3(Xr8fb$y$PYcx9G30ydTRrTNuLJM$4uI?H{#T7oCI<%_*Dh(-($D(I z@9wth540{wPnyoU8RV)wnpn1sHu4yixRpzHyRFSwjF&gDWkFpNHvFc zI5F(AK8>B^eBK{Ag)Og}mSsK|n;13QuIEmsXqAi&TcJ;8iFrPSdNRdTu~5m$Lej6l zmpeOBL%Wy-pg%#>HnBZSaG{F0Hz`(i$yz#k=cfzt?>5JEDs@Nmw~}QVJC$PR?`SiN zCz-~x2nqyT4eaKLs!W#WR!qRZiG#$(kdhPD$~- z3-+|oAJ-E7P0;s56sb_Hc_w*Z+#KAMwav+4q_$;?p*Ae**yaY7~qCKs)$9F|lj3|VfqfM5h%12DQrhBeqlARW zz^w`%`8jv~-fw%_wj9u7)0~|kQyaer>UerAd}MY73b~O#bb@4hESet==N2oR=D1fu)~<#`m2(Rc zK344xmeEp_hT>aAr+|jseKzyP;mR=ArF-jyPQ9Na;ej^Mb_(Uo_=Mc`)p>oaX)p50 z!LHFDSuemNRN`@15p(>8@}hLyT1asu6v%`SOGr@jbOGc5XjY-2O8@2W!qMHppGujN&JloWxWSE*M|Q_M=*FCxM$F0O*YsOD5OIa4pp*Ro1i$emOs3)B?$9ZwA=|&Z8cJhGrw0jso0#lkpgKad%fJTB zbqb02q3eehvTc6x_@~2XW?sI@)hp1GICZ`Jfn*Ry+Uzwy;K^|};mv^0^kJ{uFvGHO zs1jGg>c=dN(pdXZYVnxMQDt@(_}uzEdtEmQ+ei^(PwGds=~x6A=(H$+9zsk zdr8u^HAmww>`~X79-#-RzvhtT@Y@y+r9dISS+`lOn&#C{8gJ$hW&(@<3V)E4l*9Oq zh0iOvJy-~)U&DLQ9{q}>p25oJlrSTs)kQ;QrKNRPY^^gpnziv@XZBowz)zlq} zb*m8yqu~rg9vj0ZYG^Lfyno*%XF3rmd#$;IAs}!smTq>D)yHo7wBXl$Zho3G{zc`7 z_!nI{wDEuG!v}v)PM|m{$!9#1pAXJlwZ3?G%G1q5l+>mA?IMSsny(E)%3Og9m{Rf7QRO)t?C+^c=ceU~i9vl$+jWdP z+Ad(C$p?I=vru||*swGy9(vx06d=IR%Fh=q1bZ=D=FVPZK{GHqvBMZ+wGMf3wX82q zbTTtd>h|MTYb3~(oO}P6LRC8HH^%mh=hSF>rbic~z|fJ|Z+FHgT)pOW4e$$7-~ZG-IV^ zD{(R@p2cZYqY6;Jj+t(lJt9qvwfmhAE#4wRfL~?B%h`ezBc5Xc5QHmdBEOHR@s$mzc0k;e}fEtQTJ(QcGw|hyX|mih^V1 zO?EkASjvH}p%FXFYiA8YsPTblWi(exx5%I$6Q?P}cwHim$m@@RinOCRS1i&rcA4Sr zikLVFmc7YQQdp_e$yZtx#l{NbP|-l z>;BCjiUcx^L7B!>Ag*p`AxJUA#Ajx{|Ih?Is_7cc;Z2gd(0UfBE7?KOUe0h8 zIgR>2bEVK8#@I~|$go3>d^z0+h=@X&5*;{G`$AW;V5MVJ?D(UH(Kz+T9I-d~vE)8e zJKx9xON*KZIe1FGB7oywzX(@|yyhxCy)~1!p0KsIcH+XjpgZgZa@h&Bl<-c$G_gv# zO=R0O&!_5bkp#*er>ZIi8{vURWmJTN7bT2jE`J}(3QfqX+dnr%QB=S~a4CXo$QKxu zz>?^&iJo9vHVUpe={}FBVo(lHig%9CdX!Jiy?a0g-Fk$*=P^~_1^F>uL4 zp4e2g4tv`W8ThmWL(vS9)2j^sf%Z|;mttQ_L_!nHdA2Am(YmS=3; za}Otrf`HWVy&AW2I1b6aUOL_T8)-YorRx)NrTYC(%vT56_{^oXh&jX$phr}*-gpy> z(e{h4Sqi`X_Rcz^=)F)X2RIAkQ{b#w78|rAZfo<~q4AYYp1QjbO&* z2vJndLy4RFFfDbK6qpL*-k=3)Vj0Ab%!HueGv?gRMzX}YqDgGT{gU(h2`W(x06H91yWy<#%V_v&0uM`sw3fysug%Gkx#zfaLXyk~l<~}*pf_&+aJyvBW z{54O8U#;=_QBl__e7Ia^aLa@IVzbL}Mw6VF?IGQHdi$eN;NF%A7;_qfO6IQN%bcTu zh%OkW?(~eCZ9N%O><&0C-F|oFl=Lnqop0bZ2POa%uiezLpN3d=az4V55-;y|iA}3? zHGatDTmZX2utdM5iCqkryPC=B%Chlly>>3ARWhzruX+QSKRZd=dx-|}shBn>a)w&3 z+lkeNK>@~v_bpYB4^p7bU97501J^B!3)t6ktPMM(giS{<_F8=_xmY#!9Ya=0B<^gQ zth2{64lA|NsZAo&Gk4qJKTu}On>2Xf=+YN#0vL>!_+hh{dVd6hy6qxgcq6%hSM8Fa z(XJ)^jl_x_QltQ~G&}_*X50*dobWlY$7#Zx^35Z_f;XreXMw=5(&j;jrRH?kJt&pl zH9p?BzE8mhy0IPfFEN8drJzShm-D&{jcp zL#;q@O2x=1@2N1Q@Rj?5T-@B&)!=0cNp9^4?I9+Q+?!^qwSZ26uLMMn^H!C&teFXU z@`BZ6;lW50=U+Y~tolSA8MfOOk2P*eTAa1euka?tlayQ&A>1XO65*^975@$+V)Vj5 z<@;aA`e(^b3j5rsc1FvXsz}?15eS-wtwpqXp;aoY%U1Xe97kXrbb!7m5a1iV+bWby z8+mg&okh*a|`r-M~_kE3y>s0spY|C zP{xNf?Lo{W=beuNd8P{WrR0#p{0w*J_SlnoTMJAZi%E${s_ZZR?3ReAo9@-mT$`yX3;9*h!7pAByG0CA?^t+)yjRBs1q^ zDp3~lv$Qsk6q@vmV4+5iQqTLMcSY`ga?cb`8e@RjrtpD%Yf?Pin2s}xg5F6CV}rBI>h6N+=F`o z{$BG5u^hCT+eK)w*-qz$m=*k^La7F{`XZT|aDGRYhl8K?7IVx`fe5qjrSZ0D4QSG@ zQ6}fpVPS<9?womqP4VvW71Ggyu-mMzW%Jgm;iJ>3)CO@$-fk;GZSkyy{wP6%i(#E%T|OAuNW%$vLo#8$I9qrX4lMp5bj zYROs3V6*OKWc-`NLWL&Sw|!8!>}jh2d%O7R{9??fDZ>z|$l5E6f2^~&_C?;qk@t#1 zYHShNWxA}HJLFy*|GHgyo(^+ zRzFF^eTI%Bja8)4XEFM>4yHGL4&Q$ctHqeF}|+wr&r{TwJH<%tT!$ zauQ4NvFW8LE=~2KlnUMDULmj}law)cav89X-!l8%seuey?{)?M_BTV-)rCCB1ooMs z%&yVms50|196@A4zM@IhVUF4F#v&J4Q{8qdovUm|Cl1gB zuh>@u=nJ=)K`2?^43EBF7bz4?VjEC_LFDL;P9{Du=+TVuoG_(C7R-?q$7rCY^w)NJ zY4S5t$h-3;NVY?lhy?dkqO;AbZwT`y%Ztw-3S`Muwa8E9UAns}N_jsgc2~(d z=`Ih7y}pBC;m4z`qu3@DC~i(YHYD|?rgHLp!_x5Ax}hm>KK)}_9En>95gI7^v2Cqm zBIB2F07uyR+|PNa^`ddl&Q%0n4}YkTCN*mYMnqDEM2q`;sIq_uLcp?N-Hpf4bZV>Z z&Ct_rJ*8?@XGcmsGaIZXMdwaO=L`VYbY^L|MmOY`DD_q-80j8l_=?G+#6~2tk)UG3 za@kAzdG4ejvco0bPHh{eusfebtC4$T`c&z%UT!d9$KZ>0`boTN9~qjn2A4`- z(yn!yg#<^-0EYc$tg@~|d5Fic{s=9q`4T?+OVe-uy3 zOqg&G^u;uf$pmcrSkNPRpUPt^CBAdaR+ir4sx^L|M(Z=@@vs7p0PUh_%fcbRL!I@Z zsjA>3YLS7NhV}d9;BOY>*|&zF+(3?1C|w8h^U>1O#lInq3Hm z8eamnFK6Z3)1J9v+UG<}3Fw#T+%BgQt5QSQoDEM)$uPAZc&z_m0Mi~Ea@^Ax(i^T$CCnM zOAe#eE7ovl5;c3VKPc%cz}Yg(xutf?A~ST|g88Y!eYaTRkKCW&7p7ryWSDS_VcM<* z+c_ID-%(K(Hd;=4qgp(u76!!a>0}5qqRqx#459}#&GhlN55Jm7YnpO%AM!cia-4F& z-x14<3*!8#-;>&j4-hxrfP=O*bH!Njty)9TnpR)x@qHx-n>&31jsz(W-rG5e_!DW# z&FAFet8Rw4@>?0gP0l1t6zGLcYI2#rWcrQIR;k>qc8jV4meST8OPa`jU@OrTvU_fo z6-YDZz|}yYEtAS@?hPf4hOJ)A*btPq+tfm%*i`{Pxl25CNJ68!HyCs6$p_&lR@osr2 z-?m?LMn4Gk2n(TLYLV6N5;KtuN2~Tw&~hHe*QTRUKw_WZMTx2CU3%+o8D<~Xt1inm zVU>arGDBl6!jXW3y-zY}lx|gCO&c-i_0y0Q4d|17T0#J6v3sNvUnUDIT7i?XmPrxI z{*(v_ioHka1)CO9QSb`rYGBQ|Q)7!R9O74(KX~#Iyae+=ijp5h{$5yr15NRYjrd3sT5k-w;#nnCdz;ewnhr^8e<`v|6}C&+ z5PpE6x>#MKa5EiFw}iRh7PnE}`e-T@$K#9Z5q6R3NuAs&b++dYT$FKpEH>DP$hsoNYH$^xZ(3vDQkn8=E+iI+ku6wd-P!DHPhC?z;iVBB$+NN2B zavXjI90qpctR}7d2NCAkHTg%#P&E-i~m8(;Ynq6n}ag1XVK2G5q#=k|K5SoXR0D#y_ z!`H%Q7!_ncY1mc`50*7B2O={Ib~P9M2(`M)A|r_ev#?X`p63}&6!hmTs0Y>(i}Xcv zSE}QxTiMRZ+vNGdi$V9;a}l9l|2=ooR_`1(3+sod{~X zUHU#-_S+hjW1U|4Uc4uKv5=!QrU4iw$!g~^f~=5B#~Ib|q4E}DUpKWFqWTRBv1QJ{ zer0*Y&YUU9hC^6PmVt_V%6>~s) zSLT<%1fkB5T54ENs05N;Pj1o{BHqK(ij)Ubv3ZTDX^wLLO1XkBu#~lND~j5_qxv~_ zQaR9&DAQp5VDBmDDmUS$n}Q0~-}DisT9b02(|W;vy-j!0znv+vr=`RD`R+nXc9taY zDDKpuDPZ4vxi)I=o`pKn(RTi`ZQM=%!+rr`qF_Xj*v@*qWBQjhteg8~snt#7J;NFN`+90bevJOo4 zWP6`C$*=@TyRo*L#Z^60@0PAYkKw2R-UJGJUsvKsnBRkhnike7jDihTmLgW9!q})= zlDz0x#4&e=x<2tD3gE2-K13!mSGXzX;_R(Tw0u1+A7sM>XNMl?&>*(crY6VjUtWqE zN1kW8@HWw zE7d~2RcQh@jxeZ-GdtP$IA;Lww}(Vt+}GgIX4LybvM1;EOPGA(F^NazQ`;jd3tlJ3 zaR*uVQf)U|$0*`BdaN-dRDutdX;j8)L*8!t!>YO*9bkmhkCZfbh&5~;nRsv#3eYDL zRG~NtqD-m9WabiTV_EJyS%*+&76L*v8z6lXJX3vq5%NHF3(6MaSU|j9=5bCm8g=&? z2G$%{+q+Ly9HN)0P5yaGjHTpACW39-%KyTOY{Jq!Pm;y}uXB3y4`^p)~=z@eBk?MAGl9~lkH z4xnvEVQH)tk3beuzl@07XMNjNk`Jdpy6HDx4FOAlQVqVxukDmcjV6k$ zm7uL3pEL1F`Q!rD<(7Zq6P$=Lb%NrWy%tUq0`MBGE&I|8yesJl5aUk@byCF>jZg_s)z_xI6?jz(pxYDh8(1(y0rSx4?F%VGAml(Q`hwTT5s=SCTDXL)bzMdF>TD1{a!tRhRa0j2SF z6)cgG?bN@Y4gKQ#!6gl+VMIKxn|mL`D1JZOP8V!Q+O_x0 zuK%hW(;J!=$)r(Awpin*y$P$~ryKPs#RMtw`SLR31BR{T9Q<}**(e&J2Do4=Gm@It zoe^ffQ04iYr~XbO`(i<}52G4ac*z!^=FtCiUgE;@lunK)X2sxvZ74t%;l$u(W=Cc8 zwx|)aDhNw`cXK85N@3HJ4{_o*UfK?_$=NALEq_4$;#2(4Q#>JX339y%hK3TZp-}sGdy_>` z<5t!%R2f%z-u~F?LKct)g3D0f==>XT#Ao-_U2`Uh{UC44 z*bug{`1L z)b+ADH?$}4Hl|o+ESRu7dH4UdIpwdHuwWa~tjyiE49N0*C*W$Wn-q=uDHf<(g6@^u zO2zV5Ys#ztbGs^E#BO!s~uWW8$e&!y*L=2`E< z{FMI@3pU1byZw{q{-@rQ`FK-OX~q+q7n|lp3xh#I{kOFeWo& z4=bohOu}QG@~u1Ou}G8h&{8fy70JP#6V1K=zYsD;P6w578c^B)bjN}fm#)40!87Vk zY5Pym);|mj-_Fnyiktg?Ff9gr1}2vOb*C}nvv4r~M`(+corB^3iq!sppe( z2GIC6>$-YzoTQ6My_~c}e-CKMALM#x- zCh#FZPW^v3Ba~+W_X>($cx?#ZeAlmdFEyla;bt)~aA#)+NS`ek0O;H~E(~rDMo0({ z3?3Qe9Ml2e%M$Gl;0o-0I~{-mULPc+;3pjhA=ccE9ucS?Q`_JLo*fEn57NyaA8@S+ zFcfnGK*tT@E3WAU51hAOPYoCz5&pxiv#-#PByhkFJm~rw!S+VKoeug2#6Gw~5TLVi z1IQeY84m#3?d=%CRfM4aUZ0MB8pS%y<8+*=?*nIJ=>i zKgb|9!5UfxAJi2nV17bwJpb=6?3a@mB{7J-|9TOiD?Ax`_S5Z^I@9p|94?m!@ie$T z;2@$L1i;7hmzPP%aVjv-&BbTi=j}e!#V(t|>iquq_FW$V2}v+qf1Vx$$Q~Lhut5hD zBB;1NTEOpgA$aJw3h3FbI!rqe5dL$S`W4N0)jyM3>D+f3y*t3~^fN$!2{lOnKk}VM zz!2Z-DsKKa>!eTUht2hO^1%=Oi|1s7aYnpsN>@&#OVDZV$@L&JU|8D zi%&;}!0)IM*umeU^P8+P0L+LbAHvP?`;}x+zLFjYR^p(~B@cUFSQO`(@4V z+Aj(n=ssXAX;zlt%49I7YDi0#3Pq#)olW$J7l=(-@9yq%j!=t-0a;_*ZiT8~Ua>Y0f+UE>~t-k^0h*q+`;q_`Xwr zh?u`b_#a;)+b&Z2%^{^kLAtP)BZp@y}5{x-1%r_QM;@w?uk+=8t;$6dv1p3OLbJ!#f zBB~#RnR)cGzD3hW(xGNQg&)D&Xt^TmpBlB*cSW?f3J}&1J=K2b+=0to6%Ux1R!E;o zS+HQIhNnee$!f~lvL=DX%bjxbRu9prT11C{dfQeG%9#Z%OzCY@arVi{U604!7*srQ zOtX0;G@3W=JFo1ly(Be`$jACq62hd%=uN=m5Zia&4BzunIhfKN#!;b@op`r8&KYVA zLR$_1R!H7jufM6ht3?XRJe=2HhLPftkF_;E-0bXl_Ya$7m^cFZXToQPZ(8IlePQAu zIVcQVt!mTgCm07-^*)ST1)-4_gElH|gN`f1!0FCthh-WgBO>Wt3vyLbTX_z=bk?py0Q2&6BA-%==&jHwgxZxVDIdIS1{3iyp25F(%U`;}o)FeflHSyKF06%ViC zTuXs~_QfCpyKr0oKH=0lIoe^OJZHqg;f=yjW{qs=aNrCn&sC$zcXh&)haSBvkJ65= zmUuasf@qS)G037!QGzISx;wgX+Si%R4@`!;xlfDwW{8Lm_=3h1q(0h`_;7=E3&?rBts8wnl#@vRRWodgqhX9d$hFF zK-8!4GEdCD08T(9DY$!u1vAxXj-MCz#twPptkFLmobmpS=_)$?yf#)hh-G4s-Y>C0 zeuI;mh8OmLUfLnak|g)mWmDcMMTi#NG!1Lk{tb?Z7E!Q-!@IAApSg3~hik3WL8EDZ zPVC!bY%T67kzx$pig8o*D>`g9PNoTnfRVDX_}qBWLgPu zyQnGdRe!h@L78*)^CQnp*KIYAPum1{-Q3* z^piAlFRNv$IVTy)K%x)fGw1-!9WvY+0%Wx-2f84$<;RG^y#Gjp8dlD&ck(;TGGJ5o z$i3q(!V?x%|3N)%GP5AQfy=-7oK&oW!@{7sYSMXCFk47LwY9YR6I8K$Xbb-elBCN} zn7;unI@##+VtxO*D#U7K*osOQr@^?mtqJ)M9$mb9d-T%d#+6J#SFZ|tXpm@YMQ9oD z$;t=gM0DD^xVB)3)l(pJ9RKGhmjWFQi~HYL`+N(4vZ%4Xbp;vxPd zOKKDxDy2okyrEd>gKMGZu7$avY+Qg*kuV)8a{TkTxg zq=TG?vPtEH7{yby?q=wJLTXpul2H>iWDwhPq)Dh265q76>v;<1MtlWqU$ z#d4H4Lu=B(;Mn*)<)62d1R<`a#KQ=g=qU0Giorp$t!Tw94vwJ7sZ5)AJWM7}&TbYx z-m;KG!Jq1Uq~o~tRWj_m_RJe6r7$gZhJ5$-wb?bjEJwdicSDQ6!dW1fmeF+0sh~a@ z=e849gG}e%ZJ;aS=&}Z}NEhI`Zlg1j=^&rSMt4^r0p_|c(5I0lk2jrn{>LpNIIp80 z^0s$`KJw7K0~s`detMtIbfSl;-RHLGQF2QLqY4!(K1WhZ*!%c_WU!Vo<1PE~Z>{R{ z0WcjAq5ojF*{MUqK)R;U6qbJz=+?kM#&8e{qemttPqtyoYjUvOUoFRTYSloBCnAHJ zj*8QXFUXGEjcJj78B@lQvVH8=@=Hp4T7xJ_E(jf+V-aOOCG5oWX3v;wP|DJZ(gC^C ziI~hWG3bN$?646H-?x27g9UKJ32zu(=6`hLEqSQ0#+Tf_FYzBX+w9^l$t*F$k3Aee)sJvY0fiSLE8Mc54vQjnW)+3_ zk!wO$;*INQ?MK&{rTw#xqBDvJX`YuFw4B57gipY8lNe;>7mQJ6IJ{{DNN(;Bpv&3h zF?0E$c4wO8MLf}}!*(e<*E)+fWi0L+$zR7ojjkS#keuk3V zmN=6)aQJv>F{eHzWAW`oo&%3FN_ta4PYW3{UN1vRHu}^ouZlF;qEdYyC76c4WkuC% zydbN^%c&}D=R}-lI&Dc!jb9U|V`(>+CwN4pcFQ~k_2JElyRVlwz5A<7?unf0RMm0Sk2}kD&noeYVqetPzPQyA4T)9x#ml`T&o|<= zyR1P8crBuU9n>f0Y9sUiIFJuap`?!_!-xN~tFR)F1@5yT9 z$)b-ptG2k;K^e-e4}qb`7+RLJA7zBwY@}p$7F)@%XfWv3WGAvA1$%H|TRu1K=B$<- z6t7_q?hRVqMp#9KiTZ!LVR&RgNUmjlByx8yq%PiDImg}3RNO<_I2`6}7w|B%bAs~S zmA-$jdtjH*TrXareyI@qoR>gAZB&C~>CE3-#OBE{QWhq$q$x&~6Rw>sr6YWJ5M`{e z*#8xsMizo^T_|l;V?F<+l?fPvQE=Oq@o5CBk)9L62oQYC zqD9P^Sgf8w;riUNb@PkNK(G={JHgBd-D{P%?pCek@h}RSgtB92H4c%i5ckkAo!t&J zZTEc#t%e~!It}kBL0MkhAvp6?`GjQKEl$%yl?{{e)dO%0oXX4O#gXP6P9D&!CFe;>3L>QP7nyi7E$^v`bmRjE7u}i>F&3S<)>p_?{a9<7O4V+S z;3pBZO=agFi%^dWpX?9r93%T#OP<3G8MKLoM~_x~mZnOp%6nnqa*#O*OKv(oo#J{$ z+*sdXciu#Lhf(t@!2b1UXeKF>QKuhfI}rshs^=ab65*{nisr**k)fo&E}x)zk)2Yk+q@*(1F1^prW|_O>*`kxj7L&v-;O^^8pN)!L`{P9 zs^o;O`~^;R*3JycwIb2~DjQ8}`~bVoUrGhLaaSitY@k zpu)kcT~ZY7MdG*TetLTVgEGYs=({K7x$T$EaicTW8`#IR;YjXaAo0}=w{%p;3^v-r zdhJ1=nW>%7pZ+Wfqp3+ev)UmKt*7m=C6Ah2Z9zHEZ%}XJe7*bJ9;xC>ATdr78;?kO z#}lMvP#r6Sh=f+^Xzp}gH{UcxL4&1Q)v^uM5p=cP1TS5$8f!fTtIj^UO&?koTH+I9 zcP9u%%CNOJAM!Ydrob5vAJTj7d=EdsmYlSo-O+(HcX>!~=yn5)R zV+Co$U53DGIZh_~t#<<$$|OsA#*=%6TfBs#?YtJ|Yf!}-Ds0jwd$_Ha0%}Z>Nn+D_ zmmXI_jA-x}5|U9&Sc=$nIn3$ z*6c^FUHB1ujjY+9tqKE=j4ke#Ubc&s`Ua|V7Z|%@0zVkfJaLlppYn3i7Fb=e0>r{CLXWf`}TN6v~+oQN}uATUY@ahv~R&RVnA`# zC?VtLY6T5h9M+*4NK1N4=MSm6o=okGwcL2a7QFqbr28bi>#b?<(1`A{B=MPiX5#4C znf>6dQ7lUDYZM91`+6I;^~+!)7nFEx|E85^BrUY0w{&&gu4n1=tF#Ja+Q?wH)cid$ zKvIUhx|jsal+O{>(o~O8@T+;cW4D>z77J+?XUB zFSud8VRq6@{Cy!jn??WB6c?d#7^+u9353Zz%}lk6K_c)fNL}|Hhg29}-K#i-VGzU6zTQ0gs(Zg9Sb!GA1OQw8B#nN59XKd6P%?&@sS!%NnJRj&0SWk<| zgL>U$aP9gizIS5+4E?;lL5#qs;(kCnPq*k1~Js(WT!CXnSrfgw6P{gK8o~a5B zKnl(5Axg)2S5A)abgZ~9BBW;E*+m_ETDXP~=3{vkpbIFYgNWm;z5+lgBPld?Xm;}{ z`p9Z*m3^_iwSim9*2@6Cm6ZQ<0;^g*HMp`VoH22_buF#|sg7sI zOp&rOdC9X=tX@x<$^6sz(3R!f=xPCdrOq2ZQ)Hue)b{+O0saKJHn z^Ua3SkcYa_x5-t$bMHOXmFBi;e;_pL zdNwwd=6 zSXBI^)OkBOvzFJR;AGEycV3dndquBeBz#)|*Vjw$bn$(|5!=edD5n%7-xNxlpq$eLc3g7<;_l~+5ozmKQH~&iZj}m*Ft;o3- zaRPn@{w?$h#ch^z(~F2^od*ZZxh+eypc*i=4D+m0R2NoUg(znEO=)guP@_@&i*Bem zyeV8%@aV58qV7V}`e3^}r-u))g%_SRSRl3g#k@(U*UsgG1?1XltW(wnl+jDn0vcV^qW+=$s0-il zn}G)RI`7|ONKR9xY&kt|oLM!8+Oqx624@jE9r$w+|Dd7p^tgXH!(G5yEGA=#gfuMpbjvDZ)C zU-=C8@*LgV*W(AWkZ@h&wh@5VAoT~%#}U4Ix=mYo`Tkcz>VasOnAh(y$eQ9cpT#xh z6N@rx10vy{f|e!25Mf-$qp7D5^*Rr96+p+bQ%bCazD?R!zvoo;= z%8(g)4su?Dw`O~UN-%gnJZ*w&h*_uFR#aR{n}zC&c$Hc*Z@02o)x<5-eDjhxSqd%z z)N}9{g1%Kz*<6PCp|&G-{fozJ3C_7gsIL;2&ia9T3L;s+cb~GUW)HTFF>$Mb-$vA) zFL9^S87VTEv2R#tsnf?dL=;&4B^JEN<>>0uuNOxbeI_Ob=ak{W7VWgkJ9iDe9J_y~HoevDN{`GZ$u&+QLZa(ZzKNzYQJ`4< zlb^vm9y!`(t*0D2qF0_0Ru%V{-JNS+`PPefbST8!Ah>=WG8m0arNZMLqFP^oI?C&x zb=Q=^Y$xqP>6`$iTU+uaQGIaEuM?7z*F50@4h6^K5(X=L2V}NXWHhv#8_1zwbhG@? zwn!k=K&51KJr#In0Kl3{=9m8ov9bLp#P)9>_kV#KGa)-0^M6Ea9BfSgf5henuA*YQ zK~KiyA~_);!NO9M?;`1b!U)IM3&!{xp0FUfjIf-NsyduFoDd#_n2d-hM~a$gO5psX z>*mMrq{?-A-TLZ_cLi?-Z{@3s&SPy*M|cYU3T8#Dunq-DvW{3`U{(en3PM^suulm{ zNC*~e8S)zv97?P2>l4``dH*NT`n9h>1Ed6c2xSp&jxryA8WJi2LiiAs=swbbQ2_={ z?KO^gT^_j%8eXs!7@jP^%K~+ifUqoJ80>?Hm-lb5@^=Fm%z%hL5;(Z$-OjNf8|fw@ zaL^zBP=zWATuDx3h$rC8LPID{_E&xS;975^znG#(l#GlDD3On8A|IZVQQ@GV$Qttb zSepdb7(niz-~S@3V50p13UX*9Ff9+_&!6673wImBMMMNrAbu!J+#`9$-h$0tKf(Sr zL1$gid?tw4_d=UnaUtASbxVIF$KwZfwKM`{7j+V zk3tnp=#sM_up@#C>%RTFLn34^byPa{!1#rM;RiAB$DMbblOS(LX-|Lu=Qqqh0ZZUd;;+}p0hCtzaB>--^B&de zJ;3l1(sgJr(T{dTR0xWhApFtZgF76>vy`-+d~|-_X%~px-&^!^py8?BMpLp7&riQ zP-wB*q^(zL*Tqw&asZR8ajuMwqEkPOn$R2f!L}QFN;xm0#~Yh@x1lb5VQ2bUpHJ3V z%H8K3sqg)fN!(07)cDQ$ILNhT<4}&z$nJ3G`?J8-RDpm`Z3hjzbTq5HqfjYfKi@Ja z>lN76-CF5F{x%62aK$a8if5WcU@VpB|P z-Krgb!`w%5&!w*pw1!geU797KQ111VH|6umK;(WYjas)TEsgKkujU`Eea;_r-KQp> z&!f+aOxvmIjUT12&GvtBYPVyy*%$X5Pq)&$W6R-9S>g2fig(qc=NFFqVJ=Oa&sCtl zY2L|+0Ma{x*2~e2eT|U_I$FXM_|6Y@*ANn^${F}!NED9P^7OQSTb_l&Mp2;sy7@^39s+7B3ahl zRU2MP%Tp=B`{}Wa2iY;07O1qwaE|jgRvLLsPLiN)U}AG}ZREF>i0euRoi7*Bl<7gu z)&obmZT{BBu}tIQ*`F?I%cVmO!vfT(a_MC}{L|sXslx^2X+*SI9c?6azP)eAn3R&o z@Ivh^S7zdM&#|yc;3k4+0@3tY4O{vY9b9RvVZzQNYu(Ofv1Sb2%!Uf>#&J5)+2pL9 zit3i~uEm(mn?@P-6|pQAZPM6;6*S*KZde;%QxCa~m<1Q(2&|-TbE&qxf@wqZYy9Y> z0?jFUXsaB$imWUwR_;!})FddZgLl?EbC#1F@)`D`tS2?i_zM#@n^STF84IVe{k=8` zOU_FF8iSp-n@iANy5H2$ze|$8RVxW^_}iEBV_lcd+y|24GOo-X4|z$Nb7$l!Ju75Y zrXPJt)lDq+<%K(9Ar@sD{w<^-ly-JJdg2ULd*bo#CSNbXdNU?roD;nwO#8SK7iR=v zb4c{JQ00gVzp{^>n5nk#Pu&{e^bE63!5DWGp;X(AeHSrESyS}~%8|hnQdJ&nu_vsH zO;hafySmWB%-Glyww!ZrUT{*1p8tuX>aP|)RLW5FGbAI63i@NZTyR}?uG2(dZ@@p(ekmQEpn1_!;pzl zZ&Kp^w2}MI?=}H?ISDF`d)d;OZ6%+DNGRdIpRiXUi|!SG6~;aVqde&HbB1FrI`{<#`2{s zN0=(JWR%5Yo7oYQSG`9>~ollZ}U(nZV^WFG;lXGwpT@RD%6iAQm@GwTg~xh z6TiUmo9sBWyX^T(g@cW`Ni!`MnMxt0bd3;v~en^f2G@S+^B<5;iiZ>Qe)2 zp8*ApkuKqp(Nfm^Oz)g$9@wsTu?dy^65D7~JV}DDcoqI@~`Iw_)P>oQ& z#574nwA2=fT8iph8$+#>CVZm+*}8A>>Yd+2qzHM%O$06UTvq78tciPN54oD?W<)S1 z(_R-O@a()Mlq9y}89KSnv&2%nW%r=jwTYd%1wO4|TwA9@c3|>~j??)ZrzwcQgRlE6 zWzNG<9LFD1bf!SwQ(;GmXIZO4y2CPV)diul`}pS`BcmPHc;Yl_JJe!IzROPt2@-yKi~$1x}WK--dy1bO4~x$?$L6hO=C zQ0JxQnU0)!*P>F1K_CB%@chZ9EOsu*PK84;Tx?gk@I07UNr@TaFpEed^bWW}+`rWV zZ?lJf@6jNQ8T<6nIklO1 z5V@fBLrOb(CLEZNanRG5ZkhhqSVBRlD%%aB?#|7OkX$5{YN}=v%MM}7G#gfW$~Ur? zOk$J}KiI<(2D?`KSnZ;Z-Qj6{Oa0ikR1$4Jd*|%;EaowX(yz~DcHWjeTf70yg;^VP<)Uqe$^#I?z_ zuw*QeB;vi@_m`UxqXU@8RNfd}Rd% zI`H!pmD+tiYj?@kwVkg++$TI8xcIUA%3jL$5T(`0#asxivp58(j&cxIeFO%S)v@le zzXKSAG*-gj=q4tilbYi_pK+`q$FYa9e%vk^>UN1j4$1 z?&Cg@xgCbiGarG=?SV8yi`+t3;$pPCa@|(H@ieWU3@A`S>qM-N_K3=n4p?_g>-YDw zx>M%BBXoS$dN<7d+PC($^gX~MQ@+xuN;sZjMj8BRY*nQZF50C`;-u8Ews&1|u457? zSpaa|btq3TeED}?R(zT2vQp)mUkauTySlJ>nz+Vf`9lM3+Ps~|ucfs`YLrMJ->Z3s zMDFkfMoGKxisW8a9B?1Ma<_cM#^soK9lwY32~fJ-$cB2SYB+4vsfWENq73C8qVzlpDt~Gx*N8~Mp&s*tnX!<{TaN!TnD21J}F%uLW z$t3{1^Cus2M3Y#=hX&t#V0rwfFSh37C8U`pkOEW4F1z-K*0W09`}uxlc|(p(8_Cs7 z&J*8}Iz|hyzTrF(s%e_I)p8qCO7~4Ct-b1 zksJOKo&nD%Aa6To*ezTD2%mJ%^5|Cota*40D1vyk!BmWP3!ZZ({=>x}RZ#U3(N+RI zFt*zAu^FbMlSfCcu$PsHb2QhhEz754SztPimzLhLW}av@)AwpLa;}bFYQGWTH8RL25rrF zvur;0I@32HMewi9w35ia^?>h7(2EzcZQLEOL}GUKB&W(vHU*OvUDA)a)JQy<_C^Q>h|=}Y}qIW<~Dbq8aoE)6#-b6?i*Vz2S@)hpjL zmfcB50O1Z~*V%5x<;f<#{Il}#$r2W5VpFOqBrnMr+#mJlv;&cPApg8{BH_dEXDGa$ z^7*82ugkRc9jq%&FCg>l5-H@0-j~AKGsxL!?_6GXn?tSk-F4GMdj*J0?~>HLq*M3X z)nSjBMRuSXGh93?4EA=4V&w+I%Hd3fZRA1C&LXO1`bZ0eX^5#;h#ZtBrb%MO-lYM~ z_a$jnH1f^S{5Ei@Tr*O2?&1wj;y#v<{{BJQ@Xozvr_uWhLiokzg>Xu-o7@<<$?JpF zwk<*~LWtfE0FUk$v2(wjSbZ`?z66L$^@hB z3qudjle!UTTK-K-oG$+*P#Vw9G$Eg`;%+rI@&KkQB9_M~jC@CC?uQ(@z z%{82y?aM`8y1=+IJ<=Nc49Di0!{hRFaDc$GT0BU^0*$l7=M+H;Z(v}$SU(1Or>TU2>p`3pT+f2Cqh_3j1ILhk@eGDNgR-=mwt6y|5S;~X@ ze_IX_{*efABXep}W(FTOEKr13=Rpb)p3~$#kMwsJ=L+^*2i#su{hN)7A6+FAgOi4L zIjkQLW4ZA+C%N0$+J7*~k&+P|#z}^D1!h9r<;Mi;(B9RtIxfwwH@$@jCJv`)>Fdcg&gM zGScv&%=*N8&|&9wPY>Zwzc|1%eLCZ^cP&r&4Qv?GKYSFSl$pyVpkK>%_|;EOBmKFioWqEu!c!x|=S( z_`-5Iu!0|??0b*{nR&VFEp3=I)Q4(}I4_=i zB<}%E4pZ~}M^2sMwtr#yr;BX(P-jvUeg5kbpl|Ih8Zz;AepQ=%aF5m@ zDw+4n*KaHJs6<9-nyT{fW?5GF$tTwOY;P-Y{e;PVD&9p+w*ZsTdi`Eei!0Uj3zr$6 zXNGL}G4eLf8GruA!~>;>E-A6G9jowB?HcRdbd05$AWUBTl-gr6%sWRp(Pl-fmz_fj z+?0910P2$W+r05pQmU5qkh0Ku2oZJlCUXkZCeE+^1nY@V`H1Db!K2|xkAsdirm zg6*uIhE;#6+PLeG5D>BWK$miqkDh>A*vf4MTKU%qd0<7V=kZtC5^zRQO{D*a{1|Lf5rR*SAA9r;T1FfXtPD$ zyK!sEx*~67V8O20-|5dEjJ1S?U3A+@Z)YsBcZNHJ$h$~dzWxM~#g8+ZgUlr{O^?uB z>$G3vPbH)$n-~vkSa*40^g{SH98cBu=ODF5%AF!GO4V9IFUc$?;-ahQo?&WZ1LBf6{4O<&@lXJE-2|@%3so3b*8_jM7h6l7 zZ^J%nI+#_|l!JuwRj#i(1bXW)HnlwO&BBAYkbtBAgDKy7pV@u!5X$vDoi zDV+XZQcw+p5So8MWpaQ&aXn%;1J3HIWPBoM62A7x?8jA!Ju6ms6TA5;o2}KfyxZM0auv+=+vDbj5LTjEj$ABWqr zS_ZFyseLQmWO_4zr>W=LQA?J>VQs%3NK2@CiIO?iOBBS<9~@`TuXy^3!M<;?Iqs!I zz!R`yO8Gb{cG`*>fB1gAqOqrzQnj=d#8LZTWrpZy^D49MpQil%9XWD9k)w)rvphMf zBlA?-edx-$x}7Z%o@tvynwT>|*8-QT z$ja4lT7iQ|EG-KS7tP-7#qlv9dnZvO; zuH8_!WO~u=e6JhMWzFso;lzlxt;LSu(J}FnKRlWgvjIo~VN_IMh1xvC0nFC``$DH5 z{?QYm{s08BW`eerIb2^bGBm|7w`H4MYIvpN=GaPfu)H1TXxeM`NbC-NTJz}D zoyAB8DJ#h!Uafl#>7bC?_Vc+^CJw&~qg-gurqOSuLgh+M3=Xw7fKMjtglw0mN@PN# z{$``k*bUmWd@V>lni{DqE?!0g8s|I8%ud4^2wFUk|6dM_S7{T38iICx7Tvq;h8Pz$ zYu9sL0~)jmvuQ;!n3QxqE?R-Gin{%TrDfEWD!QE!(uWyq$>r?cP+mWB^ip5rBaw*? zEqz?7Gh|v#g1@eshlJ<_4l&tn!dqt>Op&r+ONlp4)D$`bykDP5qD$k6m4i)dyvuK~ z%v49S9SKBpE$nZa91_H(dG;xKXnH2;RYXmnZvU{nG^tjTqJ+2G+XMA}P#?#nbzaW- zu`u{IF~K=~OFG|pL1&=Ch+BtQfaus>g(KeL$BW26d(Xr%*YaVe{Lbc`{ zP?RcLU9(2T6b6T<$(bB4!;xvafhC*%@rn1%HjZ`mSg2BeaCfO4d2s_NyDhtJs#RA9 zt>Sx(Po&S$Y9_Lx@Ok;lYgb39noCg-SNUiSlUkak75VqIyL+K}`mhT=&2q{%R@~W= z1=CC>ME{PqMbrt>iLJW!uQ>YORZs_BfI-`-gRQ-{jfspPrfl(mdn@UTm!k(^E@HYN zb5GQwf2BnN6&UNX>^v5}NdJ*gZ2WRZsDAm1aUvlB z^qG7~r-nH5*4|7$s4g`@YLTkpQ=rX=e>yYl1C(Vd@F{)t)<93;l$NbY*O3BW5jl4s zvj-YT^5?1Wr;LTAl(1Jp?0m!QCrku~B%1<&)T)+)i>rRT+FV`)|E!47#ngDw@XX_xp|5_!dxnY+pw64Qr8*8|e2mcXh%*iir@xR%@ zkhyuOEjsuob8n`wDnEz>NPZ;$3FmVBC!EX0_ndV|L@K{6Dt=N>;H5n z{~tT|jo=D7+Rb#)+79mQ*Z=)Y53jXq$M4Gd@755tLIg@XtnBt}>Ed&3walD-{HWfb zsb<;BXggQ29T$I6bZcOyqfX9ts#g2&X}T5F>0>?{sRp&Z`=KMG@DX^aR) zDNV)L=Gn#sBqM|l0Fk}Y#oKw1<&&|!l%3iJ{kGafB_ykWVe~zDv3ILEre~M4tC6W; ze+FPO|4=>njU^JoI*LO=5{^!x?a2dB*y#lyUbJ7#zArSd1Y>gvcL2WH>;AN~KMHjY z?ncXCYn&aRrexoEcXq8?*eQ zp4*R!j#UrfN6qb!5g3EFhnGBt0e4$X&cMsAAB3L^#|%?aR+B^5(;wnbg0%GXLX6(D zgdB|C(cv)=15?8j5QiSX>yJAcnsOGvz3<+=hIVuwx%Z>iY{&i#fc^aXaayw*CZf@!U`@_gFYR%M-iz=a1^UH&*nu-7QD>j}c5 z;cz%#03?s}-KGRU&Fn!zDmdHMKQ$?V#MIDJe~!HKsGU1riuc}YMtXF5UkcuCNXUea zW6=R6Q87ud2Iu=m=P|e6gE!&7b|>EXL(v6mdr;vF%s{x>yGnt!&)z_3@pO^CJ1IC| z{WZ_y&h*3adTBp6_JJ8`z98>9#VbBzIDsaye}pTlqknda|~U(@b~ zS0-QGYu~XREnkJW6FhVsfL?dKpQ>-U$vuLcu7y|ea)BJ~Z{Jn#%a7-uu#Yb1(w;4y zn^Rv@+#g3oz$oVrWH%y1Lqo?w2jkED&W_?uw$8u9pmDXt_O?EwI>3-}u!n zmfV}LmUFOILW4IDz;gZnBEHeqOcfnx;LMT!6orvXjWlK|Ddq&@EmKU$?iD zq`Hy&nH%$Ksl;s^37z6EBza`4$i+v*E;JUKh})N5_E%%zC82g7&k^NA_LgV7Dh%T_ z-$zl``3H?(Oz6~2*|nPU7{H?@-7I=3nhAO>-F;OE4Z9@^$b@Pd;X2mE7wwGnEXnNN=yOUxd;c{pQ#^xmJi7ciV-O=Q~6&ulo zOq*6~SN!5iMeJP{{BfC zWT?MiZO)QU^;ndcY|j2rY!J8;*r0r%9{~TjxreNoGfZTmcBW>zfWmF|upY z-eLRt%eGi>A2a#4J2fGs3%f90b)FERHx{Bs*rC!*LrHBP6h9Z?*Q-l58@Ty`$}4T-(C|DnZwW``kI% z>>LqJ7!!IXA?zW@9HNmD(;#+2s-kwd-nHe-EX4 z%OU#AXiz6$d$2h@4mAo~!+Y-1o%nsHRa6)p zli1!_BuWD@VcV1u)803QW8ta237RoJimXRpy3FUim18Ta(}@AJkSJ9m!6PN^@G;V; zeRfN0eMz@GWnoGcfhFX&qK1q!V~?lAuN2YJNtx93rvj|Ln3TMJ{@0UJ95N*VLVCdW zSOl+rbayYn@XdH*fe-yj&{j7hvt3b-={b5_!nobCb#Y1vo>o>|&<)RSfR35V$y(jh z;*{F#sCIfbQj{r^N>i9xBLTm0b8E+VgY-KgI!pi6$Guauk5UWw^|~OCq&)0P+DwYc zCI${+=e-;D%guKUwB)<-eCIKM+*HF-$MpNsZ(C**YI@`FI!^^o#wPhGG}j^1(y5p* zvSF3vy)D0JoR@1rn@TV}ir3a@ImW~WCG)zsXL2vsz$zB@=;%JC(HTun2u`uHlCLiZ zjtduFU2mUJ4t$BpwPNeDPrO%dpqoVvlfil+{?U@ncP~xB`C|QMMQDF@s6?T1b|!=+ z&jvgMO4AxtV1oOWKQWW{O!3J2xX`ft!mK=&6J*ZKZ@G`b<(i~kA`J>y&x$4FEjEMR z4Hg(u3LW$OyvZrUq_R_y0o zzKm;YS?6*VEI0@F@|FKke9-C-ZYFT1^?CE_@-TbS{la86J89afJfr4pcR*C8_GxFJ zIbceqw~jTnC)J*tOV=kN$rz+1F6K$#>W*C7t?Znbja;Api8-s=d0%B7P^|pmCi@}d zIA}iXqr?C*D~o}b3JC7MZKBoILVWGlW&7;}`2*BKl`OiUE7t(U9~mB1zK%$+W;!Uk zNKMB+Cqffzoxx`C@5K@^r=|xG`h(IAhKA-Rp5bf+?r-Ls1x1~Omsb^WDV(g8WCCp7 zUYxMY=XohXxf6Y6W>%;)e0vV57JhU}ot>b@Pckgz(~>oA9p=GixzZ7xb?F|j_b z4CsD>F(XeAYwv;H10(L`L;bnx7#yocbMuxR~jR!eKBypZ`c}E#P)aylHY{O}YVdGyflDV$XqJDOP zj&+JTeR#;@iXJo*dh~zt#x}i=*ISi1UZz{%ppLtHTHn3gw=V z2dC3Hpa}nNUv%p`H3|7*0(%x3Q#Xu=>lQ0}DSnN_uXm?qdnyT$XR$j(PkkPJcM{2W zS+ezH0{XL>il)d`8kw*qz*ih^A_@wuyp=PDgb{g-yET|rz!Wc5X<2W}5NFaAY`9if z(7=%#ob2bOH&b_*c^oVQiE6j-TNCfTO~w6IN>ZV}BV|hjcm$6;5)V+|dg$49MQ&BQ z?voJ5;voTw)X3&8CA#onm@JkSfpsEQt31KLotdlcLcN+-2-18;(!cO7M6)jzlNbZspd4ySuv`^O6A&RG7+|+x_?mA8?Mk|YMsL{VfGI015?gHlV|X#w?(?;F#Mj`|lvx}!>IwSM8K{We-NvYJ)6Www ze)vou%IP97Q3JmOGXvFFP#Ql12F_va^x;rInL=y{?Q4qh=D1Ee86TC#&P+^}2Ea=< zdShE42*xK^ou*SBX(P!V3Rc||R0n!5uW9E5dd^wqUaH!Il|pmXBv9#acv^PjUp>CMp>iy*X!~-IS$1i!13l zvY{98&2>y<6Uuk;xO6B+7XyW)u--iy*&AK2MyW2L(8QTzT)B<9Vy+(J1>XA>(eQV( z!ra)i48KOh9`OnFcX2kxN8QA>T$~U}b@*-B)oWU4y)0?fVb@<4IqS&`tTJ90-NmEA zUr#ZFXW-#T{*~{_K>sfF9MPPi+H@YIqK$gg(R~G$$PGh6hQ&)hMJ_G_I6H_5d$)kkG5_=xx}xXa_;DsP!sG6;?qC!pN2tarTL>&KvbK_W~Mczu)u7Y`_fp zs7~5Hw^{nsVpkERi+8N^)(LG$m~5Z5;G%jg1BB49=tjJ;-hfL|31 zd+RO{VrnmGVm(fPTXFFJDXBh4z09`KqniN`X9_B+o6pfUC0%{01TLvj;+ zb$eTGe}!f)*g2E4*h!ui%Oid7aCaM4=+8@_PsNOZ%SeF{S7!L$2XZihg0s)(h%Xi` z4sb{p;vpAvMb0fB8Ho`(8z+#Lhv81AM)%ZYaT3D}-1Do5rfPj$OAf8yMHUcI)~Rjb z`98Q6DGsH`6&XnCmob_Ai1|VF<pRxS-!@$!Qu^(-EmqtFmXSw`x&5NO|y%~?_AIx zH{EQw9y=iNj3dxZqLe?TXzOnLDb6O^roe8^GGyOD)55`6*1$hjiK5;5&TFswqXv?R z2%9HfjmWD1RSW27WEH|@qF$d9kEspJ_^NS-sryMe9UBYY)SR%6thfWE*E7j&KDB0G z^1`=-toRGg#_*|w$5BI-C`9;z(?*zQa)>3*dDgPdQ6O}pmVxBHQV}9(<@TN1mlQl$ zlz`i$OU8k%5Qqc6%Ewgr;@kPlZRy%)}{>|H*vLA9n4uW{}T>G`|e z?_t@ozzw3gReU5j4(u9V-4TZEEp|$TUas$unl%ottNy9VH;PECWuKQuJ`v`WWgjO0 zM*XHk!sGtZYZ&eDWcDp-fl3G4l%#X_6`BO#HmG{ba#fH+7I5wp&JZ@6QLrE0hyiig zS|_cZ$8WqQ6bfk%Zr$<(R4lk?dUX?@VI(k=_T8>nKcUbWRNPs9ah_4P0yDRhVEle$ zC+tLi+6(SswR00|?8=-(yoNF3)XKpbczu@zexwTHyv$p(f)ctFj5gt3F%qt>tt{9_ z#56h>X&LY-JsdTGO|#418y6$<&IouZSmTwuc(!=()Hc}%sqM;x`EQZDYmANOeP`A! z-cOS@M0Gqmp%gP2!dt1JLEnee^5hD^uNxnu z=J`zzzv?j%j4LUOjx3%c&z|0zkfJA?R&m6JoUkG+kI8hwm`kw9yN3KQg3P71cT?5M zf9w7B5&TFwUA&;Z8tcltY<5?3G;oFpfI<)!>d&GywSj;gMTf%JCPf;d7cvM}3Xnmf zlOP4~YZsiz)0j214MKYAj{}Bs5fR30Jkk$@|Ng-|Dvym*O1Q!4r)!)Wo!$D{n4Z&zNu3?*qtPi@+UwA||g?4^fl;GT5M1Oba;{ zXz#CouHMCF+6_>mHoO*Tg?e|0%fuc(?C209$y5v% z=X7{8fvA1lDy3oFG@Q5UX!(Y4u^=&esLg zF9+F@EIIJA3=kTNhH6WBUfmT z$dLs+T4IBN4v6uoiBS1c+rF50MNz%Lth8gDYExpp)$~H4o6+NW?%Y)2YU&9JtKvZ9 z@$1OmpwT>cLh&Sh(Q$<`if0X|W4<7FTa0DBh@`?F7@)%RERpuy-AM)Uk|32J@u!6; z?av&tG7nwN7h`)JycPR?OoDK6P3Q1-?ppGLx5%P`O4^E-?7oSb6w1RY>U;trn3|1l zqv`g6&}I*+nAF;KqX~L(M@5PPjx=_>Ruc7WSGjX0M*WVVi;Mg0H>5x!PtPv@W5!S` zmTvz2rue;`kgk-T${Cicd3%faEZ&JZHn4>hRjQ6?x?5iZ(<<>~D(&a>QqfFHuZZyU{@DRT=TG;0iyiHL51{i}B3qWrru?AWojw7KxW@ z10!E~R?QKbZZ>~1gn3kgiNsthKRm4Xl><{P5+KVPU(}laRE{m`?U@--qk}Bj3$sT&qJ#$F;}h#eO?A2so)+xtq{%s6c2a5QI3n%q8d4hG#>$z z4}mjyCKUmOgA)b#3rmYoX@vwIJIvz-u`y^$X5+xVbo}JQow+k3lEnNTkgdhS@!4sE za|@@u<%-~};kkM2lx(h5^wWxpzaHRy$dC)iShQrM4o?Q7{))`+D~a{o=?;gP-e)a+c6|;wkIOXI57A@h#g+;unz`lxK{yF66Tfb3pQQG z#2w~ChS^TC9bt#B6f^3~;LDr3a~Jn{oA59)Jd|BNa#Z)P*=1~_52t+C&e1gM#&*LOkp%nOo0{>nD*HJ&!xbh$go4g#ElUgU^Ew7nKd$4hJ zpe|&~0+opJHymEB?qi?c2ZK#r#Db?`q@qkAFl56Z;v-$VaBV#XEPj=@doTiFKQn6T zbE?9w7Obb?sq)X`GR^Fq4J0%6rwfrPmxSMSB&@+1Fa^52BW{a3K3QO}QQUx0O`}Nu z_}}(~rPlr%se40H^|KFKTcb!cfPo#|AoI}O$3azPz!aou18)NU--W2Z4wM4iwHTf& zc!pA!oVEh%Ld1}*7D7W-(NsA5;BWD%AgBh^t$ z)J3)YR7%!6z52^uCPBQ}No|fxew$A2h4^U!xY;fW#@0!?vG~$G;`cJjDeD2hj%u`? zDa$5CRVTUifb_XeH+TxPTVDvv3xN;qSDsgZ^L(=DCF@PY_+i{+d*`oyI_s^EJi9PL z0k4DORPo3wZ7(!5pd)Lm6$h`}TXic6)PGq~eS{K~*?BR_KhoPmdzU%SF&5p~h7NX= zY6N&!i~Uxe)v)sW=v&9JC8Ao={26#S)GrO+g?Id(rV2jjW_7Okc?c`=%9S6KwL#hn zW3nhADo_tAw=Vq%*0^(1yk>mApZ(>B#?a#o4mIwcI?USC5-D|@?wt!XJM28iDPYZ8qZyM~{|Fbt4oYkjIA+(<*b%Zk| zO5f2iG>CLmR7QdNUMt;c64cZAo)YNQ+@Uz|4*p~WlSiG}yc$f+-+9`N&}uWkG^Y&e zIgCI#w*V8^S`hLgqYw%b%e&>NYt-Pn!t9t^9;HgF#8)cmr4MO!!_Nfmm3>%**4j>S zc=Uk-BM!+3UrHcq;Ol!=rtLNOWje9h7-@Lq4xB{*+SP$OXnhs`ZDTdm{vv?r&02;n z#Z&tNqgp6^cyzgBs7iSvW9LJk|8fzmv)cU|aUAKXlTro;WZ5fz5GN6-}IIa&<2>4J=6}alK#6G?e4(#4%l7G-R$H*q-q2LGg#kLP=nU=@(s2`Vl&T zSdV^y;2$m1A5jcDL$5WFdrKJ?+m(_+LC;cWI1L4-%)^1rGp5by2Mlui#6mjCg?(FF zMVGsa0I?N9zHXi~xQ;@WOyRk4z6%AEDCNB4ymITS}%J zJR$u)vzfls{orR8z8d{dcJov|Vth-G92>KNdsoC>BeMsI$*gmTRxpqNx0rOQxHN$d zLnXBTV(c9jE8)U!-PpEWv9)5`wr$(CS+Q-~cEz@B>wKrN(fAwtD&~C0GmyJ8>W$c* z3WuG=c)AhL(6%pJawFa97eo3u7xd#-rDxk{>|JDFZT$eQo&A-HIb{44xLgyhdt`WM z*Q9S5u2j&VCgUK)IyCQxLtd>sd8iC83Mn0cXz0Vl~f^s3$5IkI(A7n zb*4Ga*8I~svk;ZQ^yN^#=y=qOMM-aFJ`j83lZE5?bI{JPKeM9vd3ht_jV>(d05Snu z?LGmNX`&^*&GDjDMret2i8X4_3g#I%ak*9_-_aOq@qS$2$!d`cJD!fySK`6H`#A&e zV|mB;hDVGT-0^!xbE0g9JNEojlw4=^&Vbo`WXR3P6j=zqDK`{p`7WMGYgE8Vn<4F4 z$bHBpw(Z1vK8WP@FUe?5I&B}h5Tl@PYCZL{oTPemk+#x)RQ$ju6q&^4R?gnX+QUY& zHPlg!x@_w)0V5$?U{t%$$D+!7U1JKF_fw4d=rtBs!fTdQ^VtFOL&nsc#&y^pvlZT* zDQllPBA=PwLk7YMp?h=RI9i>obpBpaQM+nMwH-SyAN7-Ny(P8q3o{lMOs0{SE1t}h zDO#~4L-66v#cA#HeRE@lV|ruWR`3}`o_BVx3ox7!TbI|tGE)?MzhVS;XHeocXocn@ z!p$}_vDTGwQu2z)L9bk(0lDzK;z113!{CXBw;_dut2h@6<_xD5bI&x)(vnQaWuWQ9 zo)TMiS#)8Beth+UiU4eh<-`q(udO%f2_(^AFRk!dRIuoQ(1)!Kh%6 zO*q-^RWFia-xu;=Td2Lg{ENKm4PI4zL>uYX43zyr_BpFn#DX>?c+lemLpLa*%Z7IL zo3h|D3!KB z)1iyy?DWnn2?ng@!#HQ(aC@4VG;b$$0?jIeFyd7oF9FJePQx$TuM*S0>XV)n($PK` zXGMOPR~iBLx(=#q>DD@mOs3mWKE8II=#R-n#_WRLA6NHycQ2-}d0>7&vBFx>TxC2( z>n_$$BlwPZXpCjP5(Br)W>MgZIG94N*aP!kFvmimdam9O)D}yDBe=pQlf^?O?suWr z9l84pQ1|mVRRhy82Jfm~Bg3bTPiaxCL;}S2f44b9-J}nR10L!6@{1R`$P!#|4Cl{r z6ui34Vw#9;%>R{tXUMN&LDarLHks3XVU;|#Kwp=@eeki<1-ftiBY->^JUpXDQ0zHG1;6>J`@RpyAW+HcKzD0il=ttS6VQ$9_AuKi!vJCX|VZ~Gq|GL*^L zZuh@V?I3&IpFfFFDXB!I)@p*sYT)z0;4EXWM~jdxB)qTS^R-zFDrV67b>FYM*)1Mj zwl>SK?0&)VWT}YF+NBMT)@vXz$lsA$FC|oKYM~~foGUya_C2&fGaX*`UZ%UJN&E(x zMPP+2paNWMBtcX^ea1`K%6TX#9I4w<%1!C6CSvDs>)zoMf8am`Mw-_O4ULLAcS9d@ zQv){^g+=v1pO>(qy72?0p|>2#M_)Uy>;|7CpnE%6FA=_9A<4*mO{kNgu50pxw@H^x zmH&bU5A3xq2xQLV#feDkk?l_wFCtCv3o^5Wv;j%MEV`i6YPp$7*>AF@*O-H?ptI@xSisEL8B(m^G-7PWTv^em-%OjfZy?wp9#}6T) z`;+AMs6603uu06qR0r7)Wy>A?o653l}b_(1f{ zXQsSrML|q{{NjQpf36uqd`lNcwrx1m8ENCh^D(@xf1i78rgqKj?PrgxP`5(EoFM^7 zYSRs5WWti#gq)jLggWJsBr#(bQU0lpXjF$ZC{5>-PsP1xpjajKFn)Lj^5tp)DEGXh zZ5X0o4D#C;^`S$i4O>#Ac~Z`FW8K-m>vBd87&%WN#}_gwzLo zqaDuU7M~6&Cw3IlpgJWZe3sJ$O3;#nwfGzGdLMW$Cw3b$jF7&O!Y?BvE?@ z1-9dv*OOpVbby7(Zay_{?Opsdtuy^(B^Ar}Ex-V+`Xi>B)i>FPD6sNLZ?%vAEg~IF z=2|{no`5bMl>BAS@LNBL2Kt%FoKE~z54TNzhe2iy96o&7y-*1+Y*2EnunS>DEm*I& z66u@5<13zC#lub=E!<2a&Rs0vD$;byk}Je?d9u~?&TDr3!P0gLbDnh(Ev8z<2^vEG zChos54E={ZWn}QacvYa@f|Pnc%#Sbb|D|ogbbNDYk5+KP1GWvd9^cJ?zKr?CY`){W z`wWv>Nhx%Cvl@QkLh`TF-ht0=!Q&s2pkWrEx)-R;KvL6Lrz}m|-oUu?2YHUN*fz$k zo!7)WQ-FS0ld#D?Qwswn(WW~hXj7N$xK#boQb0N8J;F=t92gQeRY<85{S%k|yDVPC z`G+}*a{AD2Q&=_$S;1Ey6{0&uL^|H6oc=BtyWXjly;^C&ncymOsyY9f^Q0)+(1)fB zHm!nROF1WGgWPnVo~`@e2F~B-Ugn_cAkwmk);UN+l!5ez_s>a3prq&r^$66@sE7dU=I+0pXCFsqo{c~Et07KHXaIS8y#&C zZe4ofEB%(3iE{2C3y{Bb|5?{DiL1D9M=jWCOLer&?9ac6yQ^Cf+~m(%a0e7t&G^4y z@1U+c4A9w6)*xz(EL5L}nKO0z+jZgl?6&$IHYb=A`A^;HBkNY?TDGdM-mzZeZG85Q4Sz5hP4x9fFO}Os2UTgiiXDXvaWXm;ilCbT8z1<_Kg<1{lzMZe0#qd@EjgorE%)^M_wwr@1d#8hp~b3{<4JAP4AiR;HQMzg|Nm-b#9EnSipB699IbEv%) z-taJHRRE#T$@_>QsRd>S!WrQwduXz|&AqZb0q?$g^gW?VtLzAUw zCApcPA;x@zfh%-9uwGTrxI;eq3B_r3<#$_;oN!NKx17H^@Trc?Z`zP0%c;u<+l9-M zm~CR=91WobmbYDGWy#j?S*(}A zH)|>fbkzxhC5L=^QnK$G4rwTVayVyQnp z_kkahrZdL-^u38L2w%P4R2sU3Er2K9WVg{t=qx21WJMZZ)1KttC@MJOZ)`d@Yuy{@ zFh%N$B)m4rF9I?Du4)leStGYSpHwlls47aRVtRx26X||t>d?=d$1kN>gl7BfI3n5M zkY=SC3q0p`HK9+K{eRY`HoOnkbDF9&*Fh&Fq^>wYeGXCV*MXAy6fm2&JlDUCQ-cb` z=3N>LCQD$wsqC&Z3^USkf=>7G1!Iq&Zf3mBrXH{P?QMHGazdyXs0cfoJck>Tc9Y%9 zEwN=O|Gg-vL_m*H)YDy{#;0Zci^BPo*W4NkEZ zEii*&-0uc4fj8?( za|tp8Fs>=a8&_a-Ps=!7iH0((giep(f{rUU$Ci$bknG7;i2p!+emFm;s+(w^M;X0R z+|YgSA|%v(7x7hB@@A$1V!Q51rq1&Hg4Y=fAn0!Ei_t8h`PWvQ0?s;7hfJ*Wc~)6) zVD)TwTlc7_-3&7AG2J=Z9x{B7ldm{}q*t)&WppA|EhN})L3eH&ScW#p8?=#&(qO#K zg$K+^qH-QP?8f5BT#!UjLKYBo*ox{VpyT`O>fB){KV!BlQpvX9oFM;x)xEaE+>sT{ zOKOt%0^|N@tXzYI*ANZdF~siKQb4IHEZAQy9~xM0?oCixA=VH?ylpo%Vu1;whm0QV zu2Q5fgD#>5S^S}}pdjO*UCBsfAa|17RWPPRcL1?(4)L9>URgd``cm1q{xb$DfhWV- zlecVdhRDQbpbt;jR$KcqD4}x=dI2d?1UrOicC=PjQRj9hr6G1hdtnffIU)YJ=9yea zdv)6^K{mhdAGRv_`uYePyF}lht3>!ogOhy67Dn^lz06)~xEDS<0KXxu9_5~f)XWlg zz;PZ*I~!5CmF_(gQS2$H*8$GU!8mJd2+ANh5U(;i^xzm*o_6D@7n$jK})`bSg{17)xK^hOhy; zp4B?M>DyM>!~lNNT)s}9Fj}ihYnq%~L{{tejgtww&%)}wHEx$^5=#@=>Rwlp_z0x*7MHGl7uQ#(=!H6^-%>(cNr3bEgOnnjGFGI=@& z@}`z-qQRNC;w=KlkGXV!w&etH($Iv#Nj7!n29cKe>Y?goVV^ExGO}zO6xOE=w%(1` z>N1WwvLilvh4cXZa1S+%Yd4XlzCq+EhO1ahmM2afsW151LpHv=a|!{}a<0~I9)oT(?q9yC%BG&iEt<`Niwf}WhMOyUgG zLo-@;q~PJN<(^~S%Z>|vZ-sM3$FGe!amQ${62eq^_RSa)_p#lgn{M>bz-lZlcQ-?u z*&HuaU8=anwMywy9Cz)&^wI?MOGgil9Jj5Z5SXV`AAKr8NH+yV#VJ!37dj~lgOo46 z7i-KiBA@3Bg;-AYvJ)GAq{vtQI_ZwGB-W6``M?=_l148}F?EdX&N?f)eP3 zkH&4I`#P-1%cxm0`q3(~MwQ0YQ~Qk5HnVPQqmHTRT~C~l+m~tl9#%T8yPuS~Gi$<1 z9JW52knY{{Uc@b{*?)bx2Ft8|Iy8eBzb3W_81+*HI_-=dn`WpVMC(yRHcI8q{6;8z zr?B+swmVlaC@$*_`9R}@Xt}uf@7 zA8*xaTJjAh_$>wpWaCudm%17EU*{Df0hiA?$3>>>$ z#%wxey2@SuGLjH()un8^x(2<{^8ussI=YpFfy~ef%aVUG?K0J_+XpOAYB_stDs}%Q zj>AzR2_I=N10S}HD5b?;iqniYD+xR#s5B*9P@b#>&^puG=hS<*);Q+mynml=nCM`Z zk?i_CX@;c$3&A)IqrfpB3-)a)**eF%wJu#?H`5A#qBm^b7;bigg1wqW(NFMX8^h4L z&8cP;kH(&gv+%s@P44(O;|Ybv9sDU5tgN7GR#Z(yI}e-&lsZCNo@`jZ&`?INf&xkC z%|oug%k^uQ>U{oS=G?|_HNvo;B$f^9;T+D7)@&xwfD~gJafe5z`GhGLP?(trlCl_c za8gK$&1uV#-KEUxFe3+#;Ijw9t>*YK$0>sY}i#>B|wR;rvSqD|Y>ph<`&1hsuPgmLHK z7*BjzM~*GR&Z6B{7NsZCtr$Mc6sZqzl_SHacm-nnFeRG!PuGBZzO|nIQ*LdcEmoA* zp?Rn|(GFbwn1VuRhcLz#vhC3GNP{=K7$HJt4_8+y zysA~EbcLLK&8;$Z7xg294kV1m^k>1h(~d|fC7PBq9ty(Og$MzV2Ee$?;4BG6O3Q`! z#-=f1z~Qi3hbvkkiV@=Gcc1bp0bSx)U?~6Y+C(j0jtky>gF5Ul*enA+J{$>97uRLF z7_2pk5)g86EGTgd$y%)P;O5!=d8hqq_>=9d`P-X>TPL5Fe{&Wa_;a$N)vQfc0JOh! zsQcL1J+D`*Ge)B_FvCFTF}iGfz>qexd0vDMleoopv(f4{0;3DXif9nXjcauLRXKl9NHU(8Z@jAH}s<4MgPHm{%#1}+?e8@$oB|D zXO7u{9vw^r*MVNDPIP4!J7`i@^oE~Cq+Tm~8o`j&Kr`^PH0-lq>NkXb+HcB)tbr=6 z#pa*T`pdq#zi1j1LUz`E%XXD$1mn*oi_OT$E;kPP?DHOLx|OFY5r+LWefCUdbq!xB zCNkzCe7b+=ViGQp9-d8&=qd8MMMEL}&L zJ%b2$V15J>1{T@6dhbp~!*4Hn-qU_Nm_TNIBa!Nc--jHDa%j*+0k&UcHyEYGD#rsC4N%cDu-lV{#jl(KMOG%(5; z)d{-dJ7I==Pd%<|vcz@_=FKR~k>WuM34nqbU~frY%TU7nb8+2du}}NwsXdO5z#=#b zJ`FRd1Va9J9V3N6)QlGG6*L%Neki80Tup;sgf6B5NWwvj?)?vl7m7AR;!1sw{LAOk zidi<|ZWm87LdgJBvAvTL6YJy@kL)PBY4p&L_O-i%0RJoi+Zp~hRdt!SN2~8Ie>I!M z1iLx+At+c=O6rZ=x0P4Fwk+~7`nd#4d>vO}nyY-@}#YBXonZ3G~z*tSXggd0NR9X1^KAA!&fcJQHuWen|s@Ja-PPvsuPuIOuOz2fX8k zVPgJ3Cvmw;1qZKWWn<1TrxVvY)5xE4zNtX)PfUfeRR!JJK<%F@@Qz%`9%giQ?y>kl z;zVP|LGJ}cG&^KD>k))pVm`HYdULFrx2q@x(5GrX-?h6LJvcRS73v4a;%fKDcHt~7 zUiiOx@zAH;e!Fgc3E3<{ET-i&MHhAy7MoWVoGubtQ+aGdylJ9UGf>`4Ur)1{7*#FP>FvElU1D zlP|h`#UD$lCf7SHj>CGy`IaOkD$|bFtAo^<9m=I9naS=bNTbD2T^?SruM{LW`66IV zVm#*Waj2^YaC1T%x^i>s?3X7fT7MQV|j<7hC#|OS$RV~#| zX+^=L{RzC;Qhk;tup-RAkKLgG5pWDDt5wB!iV{dCr!#wvZZ=_B`_p#2fEjX`R|u&6 z>@OqW0Q`tJ`I6Zp2OGmsSPE4vZ4&7%lePJQ#*?{|?6f-$_^i8z<-g^LVHS zq)PJU0y_u@NsknwL>+Lk^lcBIf*2fx7#M|1qHe((73@4B;Hg&STowsTFe(VG0tDkJ znqaQyb?aCE@>6X^YUg{JrOEt-rzsho-i=h5*c56Kx-wA6C`2SQun|brSJ_&T2nY%d z69Qx;qN9C!4-4$cKKt(!$VF&aQ9|SIfWmW75Tk|+e8>RGv!X;m8~}uf8UZOa1wAzh z90b@%Ab)ySBqg0z0R9Lx9Ox+&n2VAOO?J8@>f!D+h`Y<6{`2b_Y7hJoSj5z%7|g#5 zG-bO$&w&vN`X8jBPX5gr{s0kJKN@(LFw@U3)PVOYc<_A!I`aMVGde^^QK+KcER0VO zkUqyKxB-Z$aF0(uQh!|%Fa(kNS>8fOWCxHLy~C3}gfbf3A?!mCNIeh;LKw-s2Btk3 z*adk14Fcox3MiJBK%#%*^A8CW$PXTZfQrVG{{D~0FASLYj~hhb0Hr%3(gIX%x({;; z(ExOKQXUQH>-l3f8DGs12@Pfc*Z$)cBie%M^0FKk`itsaUkn{Rg^)-=LI#3}j1(Fy zBI>_6&EjG*pn=~QW3Zs#i9>#$mPAH0fs;CyhSMkaNj`tp{!ep(H=y4b(||#0Oqjjz zwtu#PC<2TxvQNLXueaj)W6>ca0{*RK?ppwC2zC6h z{SOOKfRHJ!)(t~{0b~$h5k&PJ0=zv9+aI_iK{pP?fDe5jc6elavafWNpMO7zjBA@y zu-rX;si8F|x6ij#ATZCtL6PYg3I-h#tLBNi>Cclgy+XGXP%A6m2TIkD#(x;M>IlI* z&yY_nXT2&pgslFniNU2)6P=?4W4ib6%zkR}RYYpdEKv;^P$b+^;Y6V(cz603#GZr^ zWa5&SG##^5A}GaaO5onu+q^5*ruT_Yx z+UKh`JJlJB(b`lZQ}kRv^2oBxlGokm3!u;~clpEUbHCdxIf?K4`C>Zo&!F{9GSbdJ z$HbPE4OBJ&!Fyk0gAvr$Do~CFCtO?fK&OS8B{aBTnm5xMeNNHpc~fUX!Th4W-My(P z&}vO~=<|?nCzdi2{C%)@8PzPj#;1vaq_}Nk;XnuMvWZi*{ep<&w1_j@^&q0q&xcD5 zNYHrhLH?UlMf5ndh2SPD4Q%ie`QU}H)Lxg1{G=o*YTa~_v^ad1S1plMsNO4PfOglX zFAF-~?5L1^VU)$dUH6rsi;nW^{hp|MG>Q)2vvu*M(Yl%81Zw0xGSrQocBGQq-rfMv zqN;uHgq)}-Bf-}#%csnR=Hc)8ah92R@5d}UbRv7$%dmQ_oZTHK zG8}Q`8trw{!J&qAcV=)?+^_wj)O%a5F&Bm}Nmq?g@x_Sfm|xp%uMH;smG>Y7o(Ye@+pFqbSq@x2?uk)kG7PYO z7VaFGb3uC?AfISof)T>w@(KMD^Nr|J$zM_0OLkW z=6a1vz6;uUKj7W018!nw@W8T0<+(PIc%^huG3U#waYE(Bj$4!mK$xJEmZiA`JlCBF z85GHy5N!z1iGi{@RrCAY`&Y1h0u@Xk9_vP(d@5TInLHl`YBzYjq7Tr!NtD_)98B0F zbwAApn>x&QTkU<>3%>RPGMZARuJQS2v0u~*Ae^AK>7c^xu(@LC7^{>NpNI!9-m(K}{EAfk1kul0guT1me2ESQHdPm{d zJ7R($-W$-t2gVC#qB04z<1!iOGCZGH$RSsKWmH%&r|w{5mUSYq$4^r5z+l7AM`6ah zw#&~@attDDO|PX%y|*q#b#_a5E}SA>BGdwK8Qz3=25+@ttiL4Ide6%{65U8?72F%G zKxVK+A1ntuYpdP_Om!Pj7oZRY9h{DD!Z!0cqF;v$I^s-lup6J zIkGr(rfHtg=Wt%pRu_5SFiA>$#`PAb7;qyCg8^(4i>XrZ3uIUE!z_o>I{>L6u0r6L zpV4C`MA>5b03~NavySmXI}xj-6hB!OXb%}*FPKj(EEZe&ijzhsH}@(sMu5BU zA7>kP;>f)>izFqT%8=vXEBzs?S3qstI)S+@v+~9$V`ogav9>cuf7E+Bc9OQzbDE{&PQE4>+O`|j5>~Trf+v% zI7%IdCs8OmlBge2rvC7aAL}&97H(`Eg;mhUm1jg#TX7=?K^G+K^{-_VAeR(&&;~+I zdpa~)tE(FPD~5D3@ociZ+4eDDs}NM>m@RNa~z>bdkJ&{%h;w=8luA2*FtABr8wXNas;r=HvrkCn4Oc%dfTOga#0G17UPpjf^h z+4d?2lva{Js(Tg(iM9w3ehOfA-=WW-$iFGC~*)!av2zul`_1&7H zSlJVMQiYKYvO?`~$-%^FUYJU0=oC;m5=K{cz2-RPi^R)#UA(U=k$7A+d%}n|g?y6n z>C0DLsfOQ7u3JhI>(81C%?SmrP8nGLP7g%RHWq$a4=*8n973zd2}#9<2vEZY(U9jh z1yzKdKT^k79!pShirm``u$CN7Fee0y(Dk>0ft=yB(0pB>9Vgb%^Jm=-sGq8#4Os3ToqOUi~I;QS!dWBH}I= z^na%;kgNp4J)1c!RGCYASbhk5*NIxqX`a0>Mk{*kw&Z)xON&*?68ggN**aTDK_sW# zCi{`lQa4*;(5aQmd*&t(BQ@*JbuHU5`FCT~X}*IIqu0V3Hx@%{JX1SyB>a|6Adf5i zn$vDb5h~1XdROr`5q~5Q3z(ENm{J+2)&1(3D0pXYu&oqu3mxgN1YSTA(A~$p%JjA7 zP$Slj@eoJZ`gF|Jua$PE&i@qR2A^5}UFxK69bkfe6qdh8uNT1{xd-qD2~{Oc86NX; z^xD}Q*)`}{MLtL(tCA0KqLh6i4siz3M)MD5T7A%=?f0mtI0Bb#E(iw;_L#yX3s?^O}5N_3A|=+%(b)&zl9ME43`8XTYL{T87KK&`-Eif6x{Rj+}B5A zkP?$!R9_Zno!&INzTyC@Sm>)9CD9g0P}2tL>mInVlby7q{dXi-lxfxUzk|vjiUqKI zy3qa_t3b|fxvsvc3qkA-B9Kp#TPad3OayoKj?UVn^1{4{URO*EhGHHV6Ux0@vn8Bq z4sY{&zdwGKa8tp9uu58ui8e7zE8hHF&^*3dYDb^N8*D$m|MFpsbWKS>$_b;{XRtv} zj2YwMzE8P*19gtnya$$h=M+(CD<7^YHRIWNwv~{DMn*-!640-CPchAzVX0;FL{u@g z{7R%Da=J;IZF&){QW{O-bBt-_cgR0&VEoy-ZWqjY+AN_(wrX3}4=wZbShBoZRq?aa zn7QYCV$KehAt^}!NK={L8!#h(xypR1HRgG@qK9=on7mV{J!=@WqeeD=Gh1%uv#N6f zrwMGx8BD|Xo&zQ=XTP62zq$<7I(^%xFz9%IrC;U7QZ;w(wgvpS@;cW!>{n6+*YmO( zs{tKirA_W05A%BPdY-1req_#-l-bmfcc z_o8o`1RwZOAL{$eKgi&MV?LnW{&_Nwp;t=|Xx}crM{0s)^QH)cUxMq8Lw2l0NGepu zg-9R!=Tb;=Pgh#c>Y0>6A^%VoDozZuF7QFnP7MAd zWc>H)l>^!l@+O)wN^#n;Gs=yq`ro(Z;Wd@Ux_qUJH%}HnHnFLOS3jp?Q3h)cM>&)E zTk@#_`D&#KS6&VrQwB1cY>vIFmWBU;x~5*z_j7RU9$!-3d8kd~qiF}J4_0n>U zO-IK&4od{y=1TL7>tNkwj@j#5Z7}k)z>Dg|Q^^{cPulb~!DL-f+2Z`J@R5r9?Q`+m z^^*<`u~VE6H@Mw6c_X<0P#~-mBdEMCKr3{GEt>V;gq|)OVb9MWPl;&DiSWD?P3dv7 z(K`{4psgd%8!5j}vb24b+*^Y`cn`7KyB*r%K{vIs2x(^ePxZ5m1WU@_Te_7P<3P#F zVXa$qy|;6Rz45(S);~-#qruw+kZptQmoukyxlX}8Go?e%mz*#r?ZK(2bGp}=58kJISIwIk%75Sax2|1c+v}B+=yOc6PWgkCrAyIh03lu7mI3cz#BKLF&*;wODXMVjdSZ zPN>O%8IjeKo?XSZiHqm$&iZ{8+7FGR{#Y^Xj&1s})qjS;y0@ZkS8!_!OY(yAXlPpr z;8oE1qPGQ9CVETIIlnqR&dr#Lu)WNr>Tjv?CLnNTXsg=r9()B6J9m;UhL_WsJUNwW_5}`3HFa?dg$%bIfz&8gX(_M5|F& zp0GySx`89I6kzXS1rOQ!E(VviragDWlmLywf3Q^UlUh>J>S8ode4#-F?`XWTql zLcEK;1K=q}5q9Wx(W|cLvN&4s*v+3Ph1d69G6b-zq@In(&>Og7xEX(rZg*72gxngg z;@ukbr7nwNx_ETfuIxH-L1b+a5g}6epc-joOLZ6$oj}k4=M;9k77r7KDO|DVyj9=6 zI&WJE-*^?nXm7-}!_Zuq7#6wO za*mL=H7#fa+|8)5Zu9MQbZoCIMzFqPSG^Ge>K4c{bH~EHLNAQbzK$;o-vL9}D)(MD zo5^m*5E&^wI8n$vbm_sz8N2dz>$$qL7_p3(q5C(YXt*WL(uRyj?Wa4Lz)qdB?mOAD zWQ~(8UXPAGHYuN-MwuDQr;EI9Pv1=!-(n+rIT3P+tndhu&ih{ZgY3XJ8U0bU_c~+= zfyOSiW@3H}S6JVU&qRZWCB|((oteH{uU*Ca+WUKup#^_?8jzqTi%_Ct8!E*DDN;;p zSS;fOod3DQi9(Misxf0|o)Kc=P?{ycaJcqIk0)&jRSvbkL1G&rjIywNk zXMQKzGZ!_Y=Yvdxxt6RyZO0tQ^Xk>#VY}wWtdEuOuN1av@!22iS^nk1VQjziN+;Pa@m2 zTm-%FH1DX~&z1w4WA2uPL{D2$i{fE4h(vnS1rkj}3VG6SiJi@s?TQ&=UHG~RY8vRO z*1{(=WQZBr0NG%Oi5*cDotr5=RZJ;LP|i(X7iwxs%dy;Ms$;14SE$mQy1<;aySk52 z=5_FCCC>^-tENxZ%#Kl5;7MDXGBIPCELa3pGEg-!0i7yCi31qGiu7cHTn_(k$Od}8 z3nbu%W(tg>24`0#n@y3#2*V&(+ULPmG*9{0d=v?m%n6;>otGhF2&6123+-g#+i?=7 zY_gY}j`|$r)Fb`>GIF+?JW-v?$c^l9tk+ZP{>)3W_{+ z(;0U~ES|{xM)rn6TvI9>oE8UUy?8T8V}om`IjGVE7=1Y9AIspOE-F1X6|J>!b$0Vd z6cwHit(T>M|Cgac#@*oT@kl4xBD1F65bG8FuYU#idL#a6Q-?T2%d(XtNdAjFc=n&G zMPD#;&0rT!XG)efQ}ikYf)2G^>uz#(FM8-9eLL5o5w(eDJaq<~z0xU$y!H1;xzF)R zRNcU5cr1}fiw)jsNx^XDyjrn+-;hf-7h|rjyDE>JSIp4Q_cW&Y93gW*#NQ93x@^es zuXshQw-$%qEb2F+HD$D9^~DR@Eg_; zHkzW+I*vRXf8!j*Wo{ZyS=*w=sr#P$+Oq6FQbo3Gzg&QG-?(wQXP3~(vwRFrai0f4 zlstQ#bQ}ANX&Z!oSTMKneT6L#gc%!WvDM)goFIwcH`18+-R^3@Fh}a_XKo+p3=0dC zxYx5WMc_4N*t}bG1XrIsPf{;MR+8GB3YFKgizYlYw%&06gJ({v&$YoZMu)L4dl&KR zD~bqPua8L!g*wKor<1YA5aX_SYg~uuRVE^|WB=-_nQfK+Sb(&>Wwu@3seaQ0;$5Cp z*6DC~6rZMBR{D6@U&>qV2Lv%H@X~Sp*EW?i-l%P*w@j_J>$)eyJM*sh5B0)bf2t?z z3HV^prnsArDh^3i;?5b1I_X1B+$`wP2Ch@{_o?l&zP>+GEAHvO>UpXBLZwLl66CSpj|2}3 zTYnqrfg!U`N9R*_=3$yf6TmT!i&geO$-tn3K-cj$Bs?*qw4mp} zdA7^8Oykfz#$5cl6snSBb--Bw2Gkg+01*^n#OiF+m)_878%P^8^Wbg#`Zf#G<)SMj zC`$phK~u`p*9(n}FjnC&g2&o{Zp9UC(R^yP;O^8bvLsQaY?azhfb4AqD6ITv#*PB%)CkyS)#Mhxh{v!smARu~w`s zNR@{5*=r5EROPL(uA*=Eku#MK<%m$zTpY)NzCie?IdUvjp^>F))@ z;U?FPO&%YmvGhUHvvTIJ-w-`x>a+jIbF+myF+`6`2=)ry^_OReRI&W zqKOYzF=!#vE-VD9v(wVi793Zho8dCk3$fC^VY6?_@8~u9Qvy4xfTzI?!=T^o~ zMu6t7q|WoBJbF5Z?tD?C-Z&eH-DhZTDt$~oz1Cj4_MNb}#LxbwiI-(ewHHiI7>1l| zwaoq$mTmVg2I0&8f71p_|{#ol{rc3Aggu@64#@2F*U5I zsyoWzT1JAyHrVw$aJ1fP-^?!KQz2Et4k$5y(+!q(IO3vR!thfXg6!fv;Bm&4J%bWk z2aR)%#TL+{N`}^4SoBCwP~;Hh{!zmCn#tJt??KUzg}KGTm`N|8ghJ{Fp;wHW^>l=K zN;;fC_ReGk1y4|~;r_tbGN`4$#dOs~L!eq0Ao_%lNcfm_b=nrFFBJeQyq>F6cz)$q z1*lwiFV6{LVVthe~9@u^mNik5GYD}u_{Kx~-YefJw z;u7;FnM>=Nxc~$BhuK|z$#+Oi7sl%=^{crn&-RnMJh;j2!akcRju_>9=$ds)*Vd*A z)iq1;M*EqhVChU1Gx@FpQ*M8T;*aG^RFFrGVfHzA?=q#(vKuUdr`1Mj|K1rlgPp%Fbz91ph4r33tM+fMF;d%0aIl&qBj>vc%w{Byyd*+Z8X0hsUW zKa~S|`0#S*iDL{O5?0YW*Cd0rRRiR5T%2NrS(_w5CX$mC+9<36U!v^xp3(#(=FxeR zYI2y;=YUl>>;g6w?mng~UGpvIYvClTf-YXrb4vmSDQU*-<1;K%s%X^)U%ZgavL51} zVB9`!>J{O>QCw&CRkgqo1eet93@tkqhOVmZQKHaNrGO9S}To&vbyZ*48iR zNqGIq|A2|vnEoeB%mQHgKbV+}lktDg;r`#4n4N=_qeuOetpBlk$nthBAOR4dgnBFqk(hYI{<*Q&Gkp;-B{(8Tw_r`+ zB~M^#D2}Dj2w9B%qsWl;wZea!Uzh0p!24hU1iUDoZ`}Aq*HEH^LyF7EE9;M|>eBnj+E*@(b5j45;ikQX4Loq{z$eGm{9 z0r&;}lJP$AlYHHPr=fn>qi^im)%h=JhRK19K| z+ll_Y8vq!mfo&qmzi#m06cSb-0_H(~@aMpTLO2U_Jai2Z`ozF~sDt@TJ=;@h2j`Jt z#5<6_FXR!zLWKT}-9UdiH@!H7aBqFy4&p$xHU6-Lq*kHcQQ@6j!KkKvN(%~${0`XU zQwAXIk{TKcDgrHG13d?KIy`xZaC25}1p zQIJqCuY3JP_;MBn0|Bl!Ktk(Bu>uW7{VwCe3Df%3EMg#pegyh^SI`0pa`*l5{W$|i z$3O$NHSoy)wEGIX#GIn2qICGfa^Gjn%nXGX06>(0>VK4g0t31)A|xsN0^0RYn+F;C zX&rdY(=lyl1GzhsZ#y&oP#?4N2k*aM#mf%xUs({ySA_+4_!2)V^%3$xdIEj=rF-6` z`UQmkRzCcqy!!)+_b&GCxTo*AfBZuR;us<4`oNkkbQLW?%Sr#S2mAt-fj-8XFBEA0 zRvr3_rz#pWBNy+pTQEHafO)=y{q8Yhg8zkFl7bBjTKh?yCj2^QsN(G3Q=kihy;^Mp z&lwqe)n{t%BYHWz4TsfA?-N#N_WkLo6WXdd!|1?su(Tj{%o z3-uBp7FkS&8b3tpnoJnIJzjvj;kgv{h@P66JB;Zh2~oIGuIsj4zFR~e%Qnr`Ox?nk znE!ZSw{ckr54_y_tPi);Hro?wR6>9e?zL7uiJ)k^J+RJ#Pg#c%v}Ykndhkj8V${nz ze_=tzONNYuNahz7-2i8o20YYd>axcYUW4EPhwhGRBw;HsEv(OUX()=(R!^1tkt#Q8 zz!XbXR^>h{Cel<>YFu^57_)ANo>ofQX#IZq*qgblNA*uwFUK+OCoxKKQ8S>YT?K{^ za9zB~q-tTpxnURBH`*s3+{~kMgf%c2aI47$U}0+-bDzKA0gJ}CfiBcTO@kGm*rq04 zgpJM%`n~8mrse77dep6vh1s!@JSVXZXzb}BYd}MqY&Mni_j(q+zjYWre;lYJZ94SR zuSKxYD7BrQ&G!3ohuh2s8KyiYF3`cxOpTY!v^H~;K|rt7uj^hb5qBsaVsC4#(9)`m4++SVZ(Wt(qmzxN%|YvJ;D$B>d=qJMA5F+!@KnxMW)rD;~r^0`?P__ z@%p?N2?F|U-6F#ehQxox#1DE@WD){(JK7s#+9b!S7Wz8)(FNo=EoG!zDYtVW-puiX z_Wjt8<@4H!8U{6@==kx;wz)2le9t<-059sMC#yFrT{MkonR1^5V+9dp_F&QNHp!D# z2hBvM?CEDg*^{3yTYS!641_6}IOT*ck~s5e{FUtkI#ih}sM8x6@QJ` zW)lM$dul8l{sE3%G@)f2FR+ARhqqNyc?Ia#7UJIGQl>KC>fgi+M`|nnn(5Bbv3E|F zFR49$O<`mW#ZfLtY=65)+}T=d=j-689$zA&&YxNwT{pwAcf}=mlk zlSC&Rf01v!iWLKe+9D>xXatehD1!^wkTJbG%uX=sx;#ExZH7gX30ZPs;AwO>l{zx_RfMOHA88$=A?QE&xe=3SLf8SCTz#(a~D%a z7W_^rq$hnQd4n+4GqXpfy)ynJ*-o3;n7kCGRBX--NVCkiNnjZ`D-Z<%h;rsV$0N4# z@IVhm>ShqOckKH_G4|PV{ALJdrVj5U;Hd_LX#0 z+@F~1REgL0@N+0@jU5+*Z#qPr>qN}^g&hs@Z~ad?!sxn&x|Ycaar&oGd#G$A_#>U( zj-0~~C7|SYhbEF-(_c68Sv5jckQCH>l8eYkV+7ahz8~`lY&G9Zt279JW-9upooS;( zV(jZj*!SGZ1_gkIX#)obeQ`5Qu7#cJXlgQs$xZAkosM@*AW3UJTioJeem0>aEFW=mb>;%I3aaykun}DRXPz4XgoE*pMa~$ zV?1`vhfmtp#x)4yTf3r4I84aYF}Q}fQL1c61nb60{CpD~P^>vwzSYR0dbt?KIxvGQUVh$xIhyPX)DZb->(&H?mTn7Pc- zd}@dBeh=eFd($b&C9qw+cYu<>c$w$A5goF5!$t&wY^_@-2APICy;-Q9(K#8dUN!0S z{7PTNGIsspI5*6t5gdkP_e+y(6dpThJVqg%pO~qr>Xy|~)2dNIGptYa&_QRfH9TsR z+*e?J5QJ1*GqIW~Qz-U%ILW+3IiXmkPRV z^{-&^#*h48%6f1qu(~913?*5G@82#OZ6TH_JWgiUkbQC4raJpb~@$*NK>kx18sbEqkgXRmQX$B^sZ2tvn`P(@W9)dv`!Py=omwY}3aX8+= zJ-?e_vVaE@AImQHXwAd6m00}^KKT1y|J-$l(3OHe2jHvAti5MEyruY^^(zjG%43nO zdz~~)B#TD-WFVFiy$Alaq704>@u4$oqUKR`lY6?&&63?&j}r)%7-QRUS?Hx=9wpT> zh}&7XKVM-;-_ddxepaJ3L-g$jWqASK{l`r3CD4aLg<6(LXQYFGmYDvr0vZ5vuFo`)Bx!Sa=G7%i4U8`i-4&cyl$E3HKpJ>#jS#qctewrnK66Aa~9Ed z>P!$Xge}zGp?Z5h{9wtAmMGj1WdD{#n1VXn8~YJM)m~*^VWMdA z^{_1z*1y8F=On#lUmELdQbZ#~F(gf$Y#MJ?j?$M~=lO|q`cg{4_Rk80sQuH0CVR%E z8yUewA;K};O|nN(hCnh(!xD;G);^FYE1=$~U2U!D9b`F+xn zOl!r@5&t)q_D-?^J>62NIs9V*#j>84>|X^U6ie4>D@Y@K`&e6TdedNWGo0%i`dht^ zX`&Gp`p$A1#UeT_*mTeCKWvePxN(uUhDks%vwM#m1T59&Q2AZSw!59SVO^(u7erSF z_J!aX2{j1j)=3_2cFD3^#TVW@rrzf+<494gwPOeu$eh1>xM1kB!w|!F7^}1(*%8$3 zYlkR`MxH^GA*4j6h~m@-+4LQiPF=F#m*zHZF&MkfmT^hOWQw%039f5$VYnnFS3oVsi z#VnN7_`c$MQb3jV73M{OxzR}=&1bDrw~I__n{>F=MuGQKyZ|(BQ;d&T`=#!a3w5lW z9S*EE3W+t7W0@HQ2niYDnL0eT4Eg3{y=X7wA{831;ouWUzSFOO!DP-LS}Sgd(C56~ z@_bs_{{qnHYSUviu=#O6OCs342{f%x+3tPhlMqXe55WYbb7N;Fcw>}qZWCqN*7u zPZTDDWXPU_2v)c6u@xCGc3N-i;dZ~ro3$8CHSm9#oG|oVPyDE`a>#n*Stj9Urx5iV zqpy%*wyY1(+HuR03Z`Bpp`3aar;?bhDYVB1UF&v4@0>sKvhQj=V>#=(Z)BO$O8W}R!jiP#dW?bk(&1ZVC@iUkM zK2z%_zntZhQ}k#E>7F%}E7L{lI>OO9ME(bI2x}yMZ}uaTPbUAmVJ=z@RWkAzWg(N> zF)?ZtFg;$)V<43S+33ZUSLjwGhS^6EinJ*x)S0IPru8c9$@83%yy5C(SyI*H`Q#OGNOG;5<0wsWN6!{YQb`w4oe7E5EUUPAsAalqxV_JX>QE8FRX)kLZH++Iux?m=eZu|j<*-JYVN`%$*kGD;b&k$VqE8tgeNAIv zn64_bQgS)rjqeEdI#!ZD6=E8ywWsAP$nrcQio~P%D!fpmo`sL-SwcXn<@Je~A11YV#J9T-$cqGfZF!t#i$u~=u zXW-9x%eZbmeVCqFn1z!jSXgC~C7gclTOlj37G++GtAB>hcc6|q0;*i+d6!`UJi ze1_W3`&VLd0znrw$JMWbbi$6UXhVg^e5S0QbYl?4H)%NPkLS!bgSuMf&ustE|{ z{F*<(SJ~Z>wGbO<_7)mC1C2Wfx4k`%ezC3~hU93pK{t0gmoGGQO7_k*^ZV$0v`ikG zleFH>WPbqFk!bTHLx%s^p(8|*h)=I_vQ2UMyR@C_g$ct#$H>am0L0!4pqbXa`R*P67^6yufm$ze@?;LG%*3gm2ypH13 zqw8^i8?VkFLAG(Tj}if6HZR)fKAxYm0csbq6!A4X4YgFjP1%&qiqoR$^+Na%Fvk$a zX+^9LOL`rz{;jIV@3m?y?x~61Vk+hOOKO(pz0HgW4w~ z&N_2{+RB>~#@UO-e2|eDa|XB+|~L%v&cr2ln*xAsS*>wYL3~*E8@GAgOL`n zlBCL8VjbCn3S@OV zf_0`HQf5(WTy*irH)N~;5gwSj8~VE<1r)gHzBh6GF(FNv%c*=F225%JQ{Ongxj~o1 z%ObqM(qYe>UDms~=u@+h)KEr z{uj_90qGMy*}aCOi2#)`#xYuDON=xgtm1T27Ry3ETB=QBl!! z#hTu+nmr2&*E%wm+omD6v5>p;Kb8fQC&_axdFteqT~p}%`oeRO3!kpbO|B!l!FGV& zfMS+72q448EObyxf9;8t?5drg_g4io1)l9$0eS0dup|kk5NSOImlpZH2<3iJ0 z9mFbCtlqroF&s@`(&6xq|9(E*;}2lMmoW)Ag0QW(qK*y^Snp~0mhEN(MyM>^X)~Hu zOyi3Ks=}Qa8k#v<_>3vT<(ybGp6_*XV*(5IBz}eJ*@nUcrl(Z0U!5?0Qfma>jh`uw zLVrndfs8IU)>PVCVDYFs>f<{I1rMH2>S|UK$QJ~D`rH@Q$ThDgA&}$wXS*s=CQ6Cb zNy0mPeawja_98@}Ar5uS^`%kP*Yz0?boscV|9eRn`YmAo5b5Q$DekSR4u-wj`NEb*#&{=zHWa7sX-1a z9S4Guh2aR3^U6X?$C>Ji4 zIBH+e-7f38zm2~YOq}r@L zZrKfgszI6FT>A*S0Y2u1-PgDouJg9yNovE{t7Xjb#Fd=0#qoUlETTwUd{$W=t1B*j zUc|qkW@pb;g8cwlw(gC(O>j?z;$HKl$hrz=`?&N0Y!J@YWJzwTOz}*wz2iaq}Qg6 z--5fBH)yJj#>8xqFm3h77r`iT^#9_`ewi?QJ3~uIZtnkL${6q&m^c{!YxFCxWME|b zuhDzKVPYIC(dv zia?QDJgrDYU>qo(;(=E^Iedaa4BqN=Bv6ZdPXI;M`G31JMLP$*;K5HUcto z>`#Sf$wmR8|KGo9b$`Lrk}@}u0~|uWuE~yB!#oNQ$cv`@@RfNC;GtJaLHqRsJjsde zHz!fxQGkT)#{WuA{Qdh!9|7UKH-KCYgCFJ~+8+2RIAD{U7+PkcI>PbwQJ9^>sLtox z7vwGPpMP0XQ_88Hg`IA6S3`Xq16@S}EHU!do+A9-KqamxfGQ5*EFSXxr`_Q6!p^mB74BX5Smf4~>+(cljvL=7GZcHo1lh5(@6csPOQw;0R~mPD+#oRvk|+xz3tna^wAm*8{g$zQg<`2A>CLBbydK>ykF zBZ!N=)v{oBZwZ)+2Zy0aYhA;EUJ`z_&O(F&5DNCg;9qGgdO~j2hAhcq5pGu4gv-FHrvNXqo|@6d4e{5HP($KL-omj5l_ zmopPHNQVM?`<8LGLV!RZe} z#RE=h*F~>_e3DnE!T-Us1o)Kd@T3QaE<@WT}g2q&MJQ-8$K!w2-0{#?Zf{J}n!__#C_sgD96 z@O%GGEBFKcy!lTIt1PvYOx3CP-9LNZ?z6SefL;$h$=MPRBpIex4QIz)x!imD^rTgw z?rr%dJB`OMlElUI)}&BgrTtK+zH3e5c%}Zfe)N&~a_?Z06HN*f0d12m;Jls@TB#Nb zVh=V_Fkq1Rf$Y*;hwjcTJ0*qd#ZX*~EOfecR$$s(C|zE|`<+#B}X7ik2Wabr_zs9Te3 z%0W|f_KxNA)S+APe&r0`{#FK=g75xi-{-QbYMw~-o6eMSghfDa8nB&(mqt2ibr&dv z#wl_5$XM*1{1ae)5A=qnP~x_~Tmg}MLeCogtb1^r@LaK>pP=nm$_*=myL(Ol_sZXl+I z!1JvIqQE7)3f2@4P7K+48N~edjcjC(I@fgB48+3A*{KS=qn(bd8+gyS#KrUhVTpF> z@x~bbl}7Gv5@SCRPjeJ!#quPhbE%o?1QQ>&T{d=-T+fNW%xd%8!7y zDRGzSjRx^fZ};u03cMV6Ayri7q(cNVC=}1KCq@$dijrH^&#!5^2!>V}%?c?ltFG7f z1gjT#mMrbfWzbl0r`-Bp`rq%7y!L3i76IttRZ=%{r^-cgtkxErIi9f6wF_Tu2f``U zX60~~^7&Va9gYec=+jYT_}&04Ggsm5B&tRrR*hvtbi!(N>OXbQIHr;E!5p_}(~lz& z3(i0DvaKt%2`LW6W`qf$iwg>GmDo{v*0!oqb}Kc z$!Iy2M(BZMHG`smQP15oQbUqptYXQdUt4|8KF0wF7CfOM2Pdg2>?_cT^kmDn3X9I^ zUZ1n|hV3J*H{`@Bx<6Ry&@pc7>v^JyQ)T|x;HmeF)6OgndV~qxIE~gL611$_;%0tl zE5$|18D?N;ryKP*1!$aP1olzt;@_HVK-YuBE4LsgA z8s)G`@NN|}ASjt8x>^g(b&-Oa?v6UGY0!Ac>dOYanhqWL{_Xdbc+ae);vRoFt(0QnFziKV4guZjRtL>WV=5}NMJsmVQWyb)s`Y-#KDXh?~l`)R~a^On!xlj zv-YM<;X*0`gK4nam5>?Z^NXv|P&9yX#1-(|kbe7xc74-=^gB?J=r;$PzV%BIuFa*# zef7p`-u)$AEyS}G>IPDIX9@*x`k=bGjond;EJUSd@00L^QQzJdUKTSSSRiedfScMp z#nI`%DPaGqocs+ffU>+@D*o`zkZFic@OtH4#|sLxM$QRubeegvH@DhKj15s`1j~Eu z{8_y|+~XzAk3rjNeqY~u?$6ve5q>VDyG+csK|6V1Ju*d(QhfacOGQ06^H0wvx)+xX zgbz1azwCsjd2VwIz;q!%;K-)99*lsyC0i(3h!8^9PQPi_TY~mPD#wZb*@>Ws~4_sGCTp+ z2}KG}g)$pRifojqLp-m;#fi@L;D>UIoPx?(sRr}8IcLr~Up(oiS9QzrSq<`=7}+2M}-C5P8t$4=^ybAOM)!;$PKIJnMbI# zq0n($!hR>a!oXEljX;WXRR}a_(KxWAETc%kQ;GF17bZAGspc-bE0YW}C?JtP428dh zx?>R8U@2Qr0|HP_9Dwwxa<+#hsVcyFQ50udWi0$w(6ju}?sK(kSrXObD!Ex0Pm#r1 zkuAs*xS@gUz~vw{?^C{m(nts6Li&B+H_xguoTzvQF0Kai^~!!E#I(9Aw9Davj^-!O z5Z7~}7}O?Y1L*fWSU?Ekv?J&=R=LGn7dy zsbPy@!iM<*$lPwlW=m)&CHf5$=S%ZKC<|#*C)xxNA30*hy-gw+^*B`%Xl+cJNZ6k2 z`{|ifmPq_u-BF^F_ZG^@gYFX_y z_L{_@iB{dmt5 zfZFu8_U2_ThljJ?1By{9%<^|o0L!eJ2)8IjuJ8@3Srqx@I(JyCmakgXbF)FD$P!+$ z->zT=MV2-1SoZPv-Ak5T(Xui_00*@Xf7%VDu<~of-EUf=FEH`JzFD=J30h?soAROU z2G@8aJ!10U>6?U1V#P8GQJ@?Vh5^Qg?uD}fxk$8?tZ^aYxsCbxLhxuU1-sx&C`&ar zmtZ@oV-HX!ovTZ#W@pSZjJQrUm&z=u(22=|A}X%Q1LzL6NZ1EYQEpsc2+d15 z3Q6N&ncQ+=7-+?C$s#!Q{u?u?NN&mwU`;T_n-a=X;>i6}s(h zD$GFJe5;&sLnP>B5wS!NX?Xm{W>_USY zDKr{4Jq~d{_s@6r-L@g7u7ETx;V={5Mltt#hVQT-(EZQ>PVnV;AlTT%NV+ZTl8+3*u#MKbAD$tHqwFwJr z-Om~Lgn^+SJ8NRk-mGBm&90Kk(~lyncm$bEdrXE*P8zsMW}6=MR$T25Vq?o#)X|2| zM2V@=>4Vv5pG`=TzTg5hHT9DLCh8@KN6P;Gv2W10D55Khy#8+TrpYAMym(nj&~*nZ z5{sD|YCcseoxR0%SeiEIgBys@WlhkI^;;FHSDgd-&c}1}5Q}3QPK5uVtKLsD5uXsd zn5d(rfn?Bse#7DnO5AxZ5XB=B*-P!2ldZBqSuXkzzizs$GrUBrjky_tEII^xrf<#) zG@?bGt!ydFG1`laV_VT5%YM>31~x*Pg6=~&te3>GDSKe``_x5;UiCyy*z0LmI`%K2 z1gUg_bfil{^T=}19Q#1W*S+xUXbe~_R~xN}A51UA_VW_>RFCn$%+K8c(dk@zJ6AkC zMIF8v(p2}&?@~Glq~2Y#V}-r{PL)5zWYEs``Ugb$eNiR!hDH~9Jjixy5 zR7_4$YHTHW!?F1+K+0WAC@7XNi_LcxctuRkKhMsv6X8H_$CJBJP>dE68he?e4rx}% z(mL~wb-HnQ;g0tYB%VQ4dvEJ(8xCRDKGd}f`vwnZD`bRo+w~+291M4i9Rul=Vm6s) zk+KFcWR5&*QIo`X+G^YVS`t7K!!AJ;U4a7m-cJ>j>or;~Ucg+6T`C(lcEXvZR#}PJ zg!Yy=qgevaLa|wXtm!>FBlF%0TxGQDY*^abIX*I@0vQ?CzJ`#Q8J<%{9~gbBTJ>qo zMwoTQ$CBGg{;2o?u88haij{Db@|P%@EV`1Px@}< zL^3?{cO`xVCpeS4=7?HJF0vvGMG~~MHL>Hp+qZC^4O0^A&4tJf5&M+UPMXy`fWSUZ zx3?^|@*l=cZa>oM=ZdA4YnFx>{*Uujv$-&9L-s{2E; zREah2svy3!;0v;cmalP5S#c%1TGe9D|L)wVskNmkG<0`HoT<-+={OSx)rN#92VA@y z#<$=v!xjFq+w)WN;YqcV_iZaY&2IC4Hou%5%Pu?m5bvlZ`N*QLb8owe`tRhPkT}OC zYl%C1ZE&T!p;QkJ^7!9{_bN_rcKV9Q$=!QSArHWpmz^38+Ci-QXOAmQpeK((GA;y`yy~ z6gd(iSw?IVr*9T0l~e7vJ5`JaF>JA|Qj;>APT7;_m-wwc3i>qeRg4y!Xti*o1kR{R zmW2{QOn>cWX=|@CA9i$)iylyddB;?|RN2;vL+7jH@KXZ(!=0wLk?xG#$wJ?8@lEa1 zCo0Ycbc%9ef{^KJrtbA-GXlEZLr?2&f2NAxdGT^~Wpnu^&yl+XJxm%aNr662nHv^Y zPG|q^6^NRGoBXwOFnfl8;kP!9&>}>=%IuPi9Pj0)9%Jz)Y?m5wU4-L-V%jrt0i=p9 zpQ6W^only|dZvumSu38XzA3+BDU+5G!z7H~QL*jp$nis|ji8!PYXsO*b8se8@r|T7 zLGPZc>izHGk2AszSURoVR}`B@RHXrD3jAF(lH!58H(eB*-t{_h94*GWh}M^9eXsuU zq8emK=*>C!1`$E@?3fN8R$Iz;dvz6WNN$P-A%OV}C>h`88_5aHeu=$=p11_ns66NZ z*~Y5}lxo|^Up!eU_uRGoRL@4Gz3zXL=n z?X5f(sB$(u9lk2sdc{kT?ximCa6%kcc8A{$-#!YAW&++7b%tJk2jau%<|{5QHJ8|O zCyY2yGEMhiqo}-;*dAWtVWr}kwiE(35O`ErGA ztwU~%grO(EC*WMK$3Qp6U-X^N=p<#6JoIFKx*ovXrxs=RH!y`Skd%-7YN0KtP#8Yd zOJ(xRwkys-#)wVW(}X7)Jv?epM6X<0Zs3nNp_vR9ydKs9HqL3a!WaguUXQ9A)}}5M z-`RPrLNacUrjdhyGgph<3a2GiySwNGopr71v3|a0Tb9CZBl?~6KXbP)Qia66E2=`; z-t@4kStfFYOtqBZ09wb%2Br~HFfWsspe9E;1M%SLE5V})eWpE95lA!-Tnj-qJkj_S zQA--fE2h!c-5<*qs=H!^kgyT?%Nuk^Ft`zgV|=$hENwbnE@^)9PW9NQ>8z|3p?EY% z^F+fZihcm9QO1liy$uA;hRWv6(giwx9hka>1wE4Xo#~^E_c1^agJF_DiMH$YpSYL{ zbFXYMkdt|H%qMP0=hHDAJnyiC+vPqqOZBt7TyER%O)56nqHdjKVDj+ji_|2G?%cy& z==hZrP)^ICnjHX3g6WCzt&U_19z7=&oyFIL>9s=;SXQ*Uu;gNW6;gu^o*fTr{pYBw zKoTy-ixqz*Mg1QtA>VrBbaNfC7f(lC)?s zFPv|gfxmoYxd0z5Rl}gGq)s4Vc^{F}CSHu{ppx@IcN+%fJLDZ)6ZF19^`GVxT zhf+;0a9?LziB$PIH`rXLXOKkP7!P<$X;1yDwCN?M*9R8*5xGWr9dShez^==bLHOG5 ziFlgBr(u^4OitZ6@HMqH9-=(L*!mJyx9F^=GFoL;*lM0nHQNm>Vd|dfTDeJe6rmq* zk)SI9||E}@LQ=@gT$aU8S7-}iqRSW@it{l{ckqgJm;kl+O>X4~P z(~_tnDEIPN7BH+3{?AFK6|=8y%rleeLCxm#`YL~tpMC34QI6Nq!&T#!KoWE@d3i0= zS23BZ#(FTl-MQUGvfWm7uuyp3T)f~3eW0ypewAM zw1IPn&XYhm+`D#N580=?cX?(~=@8#XVwGbp-qly7p+B7ivuDQvUE^!eU0%;@kdS;I zO1ukoQII;Z4~`G1h4R@nozH@Ze2p@P%URsTP1BDi`FR3p8mGvDN*#)1gQ9hJgG_vu5ktmwSua$2 zZXbivX3?C{xe$cu=_5A;IIa^x`b)jIX`c7Bg|Rv@dB!@w5NLKJ6`FY39ExsXj(XfR zjD44`JCzzXO$NFv-W$0*#0=h5U>8k|p|7?TX4sy)Buh4@>T|=^Uk|ni3>c;;QnH#1 zUba0%l$r4-bK-)p--gX3iF8*SF}%r24$Hj(D%?Zor&CLH^iGe>Ix!V^rvvonyB*}&ZHpSE1qxd11JTW81P<1dBgb#>uT z?Z|3Qy?32x@8RnwFp-SHF)(|1J^nE^LsQsXAker78+a@nqY!)YC@QV^lM8Uen@8m^ zr6z5v%)xhCZ>l@-g4Dlw{hi&J<|zF7LnYK5gv1gl1@}P-e=)TPwb>^$k6C_Ova=Jt z;6-md>`};c-`0eIp|`q_X(qH|`M__IU=8iSMy+Y|8&O!gZUQ5^KVTtJb^LYESJUfg zVkzTu#_OG*UdbcM*7`QloP0xZr@ypKev}a|-13xu{^dsX40=WkYh72NYtF zXwjpfYVXAdxQMV{P^d>l%I@k2{S%=G-MI_E)As64C!YIQ4Oe&m8rL_8BMiZdi0xBx z2aRawD?1aC=Q}?Tvi~*Z=DZKK$5)We)CJBSCB#<=FfKJ4z#oV6w3ZuI4;R-l7X}3R zlm&(+4#?9K5s|m7)`3%Mu1CN^+Aws2IMbjGytahXN2-HD(HHXbNA%BuUCR~lBle`m zAc(0zCcyTr0IYzQQTH@70n{W3R6>_Q6o3;of{MeU#19DXeU@ibK13!61i{vXggK19 zq1e;!BH^wBgR4Wa?jy#p)CVC2nF2&@A;eNpS4mVMUnnnxv|y1Z=})R-DK^lYPtOVL z_Wy+^P$)+#{xs@bPFH z7*fHTa6QxKac_2v*X7!S-kn&x1T@D@`MK5~9pv6V8#QUoelP60#G_=8WXrF^=ecfHw z%BmMv=Co|MQL|S0OlcqXZ*I&j$i$mX>2F-XTv@Q+kYH~iohULx_S(`ZLFt|qC5FOh zyX`8fIqDN62X2g9#KGC;>P7FI7PZ)m#;%it2WKd2!JJoTdhB^gMeNn5e~jGkin$Tv zhP0%)!~eQa^}q@V&}H$(cy3p$1#Yjgts>c;dn5Ooddfy0HC~ef_x6X6|4Lk*OZQ!v z4lV-j!Z<-`iqQ@4Ov*IGvQs9z6CHiqe}{wneO8mj`f9HT_F!f$^Nf!~PeauHts~oA zY8*H8RGb~daGH($aAsf2_C~`i9~?aH8}_{j=tpMSCrPWiv!!|8uk9Ttcmk3&FVn`e zweCWX=5QI;Ulc8n!ge97D&4u)FD(fsoG=Mk8s49f$eEq z5z#A?*w{rG~>?kpA~~l zYl@|sytkL@(ZQZ=|MF)4UP$arq_~R2sFZu)$DJ6(v+#TlcXb4WXp;MaO!s&2UnhVR z$ONsQ&%=wycIGmK>TUe3C){0OUXf^o%!c|p<5Fo;24XIYbJs4U7>b)ShbNX{TSzh` zJtl_%Km>he@{GpvjQ;R7qqK$7?gC}kGJp(xXKf;V^9@{R&0p@g811|`bj86B3(wr> ztVLW1MI7KshHq69>=K2Tf0lvX%v(tqB_5x>)6)aFmEcd#hQZr zQvD4k1Njx*85x*zu$YOD0J zUl)_9{^@0ebL0Qaa&lgE?PbNK)RJOkPS9X8^mfM0h`crAu=u(3d1kcy>K^J(47BP= z>9nn~ENYX9sH%CN)G4zWNP)Kc%6eJtsX0{HLRK#2K~rAhMk{^p!G+Pk=n9)RIuH7OgcNy4NDZONv0_+`O@RcY+|5M#gOExub4k{ z$i!btrPw(mnlv?@f1Nt0a^>4T4Px*CT;f@XVzaT!fSFa&_!#(3w7h{QRm`|Km6841 zs&OeEYnsK#8QG;}vd@eq$ zeF1_Hsfe>X#t2GQUXPV^bTCCX^krJJ9GOTLmz7DuxB}J`%1H?YL$+Z_$WGS5LqS{6 zr>#{{HKuF^3#dKCLWf=6DHCCW}Q9|jX+GRK|Oj$9MKyA42v+X6FFSYunPMA-dVG| zxQ*Yap8>}>0688rI`Nkp09nO-_HK+y!;`ta^Pl<$7jpYqx8*-h= z?niYiuT`6>OF6qMLZ|64`cx9`_;i){m!x4sr3L#phGsvM|Z4y&-R7ETq zAm*b{#WHcVgyhm^Y{d%3@goVPdBP(uDbBh&J5X6z?>;v$)9lodu=$EBN#CKZCx5CZ zBGNfm)s#~Z-Q825lw=>YJHT`sO62NyIQxSc--eV%!F2GX7x}<00o0LBo#NxfF@iZ)X3MHgo^v}dQLirGZf*qwq;1+sdW^% z{O)lQ#}uHL8P9`KLN3e8RL|9>oU$n%4JvLsiOkXJLLc?1zamnV^-=Jv9FYcG5D`BG zkHjFUoSZx5G+~XE(0@Uj3do>lcv9x&%6F$^ILQjINz1sHW=%-PBU>(QBoh(w2xFQ& z;$O%!MKd>Nldiju8Ec1Y9VOGf8qNs7=Bb^5m$*gGDW~cUCDLMiPYdZw+*v`irwJ6; zydS!zI8rf?rl_`q;>_GZTc=qwjA24QA}`K zp9;-HJR}sB9f_ghF11q$0Cw*viTHsW88IutVy z3#6417bt0!lw?f^ut{){Z|uCVVkXw80q5yQqoG!77{LLKOJgPaou5c)VXAI zi{U%$&X}U3y(J!sNG{{s?Nh*b6h_F(R2_43$-|`{ z(cJx#t~L};a6b%o$r_(Z`yJI^jDvQJ%`DO)cFfHus@zLX$g$5y{d&k){yj_$WHK>t zePZp9`ic8L&C+4TAhjj;T{f#kuBi(}Xe=}5wl1^J?(vp#gE_Fz^Tt>P*DTvGYk|)NY29Cb# zOWrp7#&bEU@uqk=>fuh5J`{Ts?M@KA>%tz@bH|r9q~so-?yGT&K0F#TB%3{G=lryB z*N!@p_m0JP#TjwLCpys39h>mr$jTn~I#QZBs``Po4+qwLx6^S(cRO`gtTj4cHi5o4cU#vb8glt-dDYwuhDcI!Go*!S8eRJ>P zIP~u_Fb7S> z{4AbUZ0+o2OhfoBG}+hd>Fiw z_c1<(6I#A5ZqKgK&)osNcCGeu8`wl7o^V+iXUK#n&4;nf_h5&$)x%~-o7-)QVA}&1;iS{M;CFo#t>1*(UwXVFJt-|bnGu>u zvy=whT*albA024XhHqa+Ol^7U0zaYgpN@hBzD$SmdwH5#q5cSA>%f&`a|WTK4>yI` zvGzR1^wrW)qMQ}x2Wi{miRR^&Xed`%)#VEK! zgVpkVo*7h75i6FxA29dWF#k;aT-|`ZQI>(-agE+@r=RICGivWq2UgNew+81^DJ`g5 z&S19^8t-P>f4rHrI48x+EGsFqj;P*3=3Zo@|32Au(A!s1t5C#2TD@E(?%*Fij%2sjq589%9d?0O#TFZH*_n{lqX+&_Y~H#d7Z z8+H4JCFpz-a09jaL9TAlYOY~8#-f6=d;|(SXk*d90i8H1%o?rP(FPfyjTuCNGiE>w zUHWg2R&;&VzP|Q2pmvgr*~esB1stykF2dqEKlSU3tsdIAJgUsN=-k|5@Mjg=WUo_B zw|M1uj*UwB>-Jn6II~nQfz&R5;XcrF`Owze8fztHe+mQm9MDH9JjJ4a(Datg@*dnXG!TVVrd6MS-EPDXkL4tfT9rr(x@k&T9)m5iRA z?024wo$>!~in61Dy}gMsKAot6wUY@XoxHM$I<4scY2?a-nohDX1`^ybh`<0Mhd)G= z(~y%>FaiOF2%?gpA`(adIg&uaeV<`Kt_g<+qH-*PT!M&*0xBSvBc~8i5o16|!_j{&~5`vxYTt+V9a_i|B@o-zNvMavC6zPEepEPL!yu zD@sD>Lw-JS9oY}U>ge~x=DAhH;X>DFST7}R+iojV zVoILPF-M&3o7kacccPMeWd)`dchC^qZ}8`s1BxlE?|qEi3R zc5O&?DHlxD%s^4HHF7)~AU!?z*j`xu5>(O7IVod&9I8}0vCpP*svT$6FViKnTdnHc zE}h>p_pq0jTFaCNpYxyYwS^VN$VY#OzgWWR^`G+u4z=7bbSRr=)jzqSyU4Nrx)NL; zuKhx3(6f7kky?WpcVG2wQY&UN?^i-njBRU(Assb(yufSUW`%d*CL~livsCsN)4YJ(R(R&U2=ZiZUJHnRmy6{ za!pzuePPdxE_MYxm4D-F)D5Dl%wZbLzkK)*h-wOWmCdlx+(=H!gw(S=M(GOY zJl3njRTQdSl1$bmS%P;{3-bfRY->Maq=JFO&58b5_M`7~y6tfOfGnZA}8ohi5485uDPN9 zNfJA;Bc{DJD4pc=Yids4wKUd9@vWs6A!o<{`^?HXpp$OBQxkVmZJ!bG@lfg*>2qgq zidMX~pp<+6!pRs6zg94{i8+1R5OFJD_M>t~Ih7ARP-I;JVKoLYHCa~Lx2r2@+0Lcg z!8RP0bb9`gx!6fHyk)v~q?{mVm+DLHy?2*73DqHOT|4)`)26xbOk8-nv6C3kkn@Fr zwBDYSTVwZ9n~hN})_ia3ov+W1O%QmVt8T_F>7U2$xx6#x={YV#mb{l#28{@q8-%B|Yqfq?{z*eT@IEJM zX3|u#?Py|BtR-Gf&;F)Ofj|b{uv|et=WmT|EXj5`8&&bZ^7ehwYufPAug#}t(Z|+M z*IkCQX$6yY&SsVK>?O0Prg(lcV$ACeez@pO@|UlEQTb)W@$WqMtLD5+(HfDH46*N0 zJ0B9%|5szc{G~DcfoRUhDV|W6EtO0O1HNe3w4KPSE z;QyNlwwppLiFr@#bIb%JYMpa7x?cIfWW#}0XsFZ*n( zdgbuX@n!nM5&cVq7iqrMFMSfO$d&JJz#h%6!rk4YXz9Noii0_R^A>vs@ba3A!Bk}F zYn!Xtb?TB<+8GrkDtGSXs?27X{B&|mG%MI{&WA3=jN8%3JaX!Q0$*h9aN`+T66BDZ zh-t9W%M&Y!Y2}A1rls{iU@i?Zx0{N?+BA2Ga@|1q_c#e&zEOzegWK^85xqPVo3GK{YCDy{62K9KGf}IX#3|nXO%f*Uu4kXeqEcSy8Gg zpHdUCdXxJPB~?r&dEQj8nfveyJ+k5nS0XKv=-3+9@(q#&QuY{bLWiw3L@hoqh`h^C hEwLT^?}N!;k^-5b!fOWIAe*u0V5q|&x literal 0 HcmV?d00001 diff --git a/versioned_docs/version-0.47/integrate/spec/fee_distribution/f1_fee_distr.tex b/versioned_docs/version-0.47/integrate/spec/fee_distribution/f1_fee_distr.tex new file mode 100644 index 000000000..b6bb6b326 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/spec/fee_distribution/f1_fee_distr.tex @@ -0,0 +1,245 @@ +\documentclass[]{article} +\usepackage{hyperref} + +%opening +\title{F1 Fee Distribution Draft-02} +\author{Dev Ojha} + +\begin{document} + +\maketitle + +\begin{abstract} + In a proof of stake blockchain, validators need to split the rewards gained from transaction fees each block. Furthermore, these fees must be fairly distributed to each of a validator's constituent delegators. They accrue this reward throughout the entire time they are delegated, and they have a special operation to withdraw accrued rewards. + + The F1 fee distribution scheme works for any algorithm to split funds between validators each block, with minimal iteration, and the only approximations being due to finite decimal precision. Per block there is a single iteration over the validator set, to enable reward algorithms that differ by validator. No iteration is required to delegate, or withdraw. The state usage is one state update per validator per block, and one state entry per active delegation. It can optionally handle arbitrary inflation schemes, and auto-bonding of rewards. +\end{abstract} + +\section{F1 Fee Distribution} + +\subsection{Context} +In a proof of stake blockchain, each validator has an associated stake. +Transaction fees get rewarded to validators based on the incentive scheme of the underlying proof of stake model. +The fee distribution problem occurs in proof of stake blockchains supporting delegation, as there is a need to distribute a validator's fee rewards to its delegators. +The trivial solution of just giving the rewards to each delegator every block is too expensive to perform on-chain. +So instead fee distribution algorithms have delegators perform a withdraw action, which when performed yields the same total amount of fees as if they had received them at every block. + +This details F1, an approximation-free, slash-tolerant fee distribution algorithm which allows validator commission-rates, inflation rates, and fee proportions, which can all efficiently change per validator, every block. +The algorithm requires iterating over the bonded validators every block, and withdraws require no iteration. +This is cheap, due to staking logic already requiring iteration over all validators, which causes the expensive state-reads to be cached. + +The key point of how F1 works is that it tracks how much rewards a delegator with 1 stake for a given validator would be entitled to if it had bonded at block 0 until the latest block. +When a delegator bonds at block $b$, the amount of rewards a delegator with 1 stake would have if bonded at block 0 until block $b$ is also persisted to state. +When the delegator withdraws, they receive the difference of these two values. +Since rewards are distributed according to stake-weighting, this amount of rewards can be scaled by the amount of stake a delegator had. +Section 1.2 describes this in more detail, with an argument for it being approximation free. +Section 2 details how to adapt this algorithm to handle commission rates, slashing, and inflation. + +\subsection{Base algorithm} +In this section, we show that the F1 base algorithm gives each delegator rewards identical to that which they'd receive in the naive and correct fee distribution algorithm that iterated over all delegators every block. + +Even distribution of a validators rewards amongst its validators weighted by stake means the following: +Suppose a delegator delegates $x$ stake to a validator $v$ at block $h$. +Let the amount of stake the validator has at block $i$ be $s_i$ and the amount of fees they receive at this height be $f_i$. +Then if a delegator contributing $x$ stake decides to withdraw at block $n$, the rewards they receive are +$$\sum_{i = h}^{n} \frac{x}{s_i}f_i = x \sum_{i = h}^{n} \frac{f_i}{s_i}$$ + +Note that $s_i$ does not change every block, +it only changes if the validator gets slashed, +or if any delegator alters the amount they have delegated. +We'll relegate handling of slashes to \autoref{ssec:slashing}, +and only consider the case with no slashing here. +We can change the iteration from being over every block, to instead being over the set of blocks between two changes in validator $v$'s total stake. +Let each of these set of blocks be called a period. +A new period begins every time that validator's total stake changes. +Let the total amount of stake for the validator in period $p$ be $n_p$. +Let $T_p$ be the total fees that validator $v$ accrued in period $p$. +Let $h$ be the start of period $p_{init}$, and height $n$ be the end of $p_{final}$. +It follows that +$$x \sum_{i = h}^{n} \frac{f_i}{s_i} = x \sum_{p = p_{init}}^{p_{final}} \frac{T_p}{n_p}$$ + +Let $p_0$ represent the period which begins when the validator first bonds. +The central idea to the F1 model is that at the end of the $k$th period, +the following is stored at a state location indexable by $k$: $\sum_{i=0}^{k}\frac{T_i}{n_i}$. +Let the index of the current period be $f$. +When a delegator wants to delegate or withdraw their reward, they first create a new entry in state to end the current period. +Then this entry is created using the previous entry as follows: +$$Entry_f = \sum_{i=0}^{f}\frac{T_i}{n_i} = \sum_{i=0}^{f-1}\frac{T_i}{n_i} + \frac{T_f}{n_f} = Entry_{f-1} + \frac{T_f}{n_f}$$ +Where $T_f$ is the fees the validator has accrued in period $f$, and $n_f$ is the validators total amount of stake in period $f$. + +The withdrawer's delegation object has the index $k$ for the period which they ended by bonding. (They start receiving rewards for period $k + 1$) +The reward they should receive when withdrawing is: + +$$x \sum_{i = k + 1}^{f} \frac{T_i}{n_i} = x\left(\left(\sum_{i=0}^{f}\frac{T_i}{n_i}\right) - \left(\sum_{i=0}^{k}\frac{T_i}{n_i}\right)\right) = x\left(Entry_f - Entry_k\right)$$ + +It is clear from the equations that this payout mechanism maintains correctness, and requires no iterations. It just needed the two state reads for these entries. + +$T_f$ is a separate variable in state for the amount of fees this validator has accrued since the last update to its power. +This variable is incremented at every block by however much fees this validator received that block. +On the update to the validators power, this variable is used to create the entry in state at $f$, and is then reset to 0. + +This fee distribution proposal is agnostic to how all of the blocks fees are divied up between validators. +This creates many nice properties, for example it is possible to only rewarding validators who signed that block. + +\section{Additional add-ons} +\subsection{Commission Rates} +Commission rates are the idea that a validator can take a fixed $x\%$ cut of all of their received fees, before redistributing evenly to the constituent delegators. +This can easily be done as follows: + +In block $h$ a validator receives $f_h$ fees. +Instead of incrementing that validators ``total accrued fees this period variable" by $f_h$, it is instead incremented by $(1 - commission\_rate) * f_p$. +Then $commission\_rate * f_p$ is deposited directly to the validator's account. +This allows for efficient updates to a validator's commission rate every block if desired. +More generally, each validator could have a function which takes their fees as input, and outputs a set of outputs to pay these fees too. (i.e. x\% going to themselves, y\% to delegators, z\% burnt) + +\subsection{Slashing} +\label{ssec:slashing} +Slashing is distinct from withdrawals, since it lowers the stake of all of the delegator's by a fixed percentage. +Since no one is charged gas for slashes, a slash cannot iterate over all delegators. +Thus we can no longer just multiply by $x$ over the difference in stake. +This section describes a simple solution that should suffice for most chains needs. An asymptotically optimal solution is provided in section 2.4. +TODO: Consider removing this section in favor of just using the current section 2.4? + +The solution here is to instead store each period created by a slash in the validators state. +Then when withdrawing, you must iterate over all slashes between when you started and ended. +Suppose you delegated at period $0$, a y\% slash occured at period $2$, and your withdrawal creates period $4$. +Then you receive funds from periods $0$ to $2$ as normal. +The equations for funds you receive for periods $2$ to $4$ now uses $(1 - y)x$ for your stake instead of just $x$ stake. +When there are multiple slashes, you just account for the accumulated slash factor. + +In practice this will not really be an efficiency hit, as the number of slashes is expected to be 0 or 1 for most validators. +Validators that get slashed more will naturally lose their delegators. +A malicious validator that gets itself slashed many times would increase the gas to withdraw linearly, but the economic loss of funds due to the slashes is expected to far out-weigh the extra overhead the honest withdrawer must pay for due to the gas. +(TODO: frame that above sentence in terms of griefing factors, as thats more correct) + +\subsection{Inflation} +Inflation is the idea that we want every staked coin to create more staking tokens as time progresses. +The purpose being to drive down the relative worth of unstaked tokens. +Each block, every staked token should produce $x$ staking tokens as inflation, where $x$ is calculated from a function $inflation$ which takes state and the block information as input. +Let $x_i$ represent the evaluation of $inflation$ in the $i$th block. +The goal of this section is to auto-bond inflation in the fee distribution model without iteration. +This is done by preserving the invariant that every state entry contains the rewards one would have if they had bonded one stake at genesis until that corresponding block. + +In state a variable should be kept for the number of tokens one would have now due to inflation, +given that they bonded one token at genesis. +This is $\prod_{0}^{now} (1 + x_i)$. +Each period now stores this total inflation product along with what it already stores per-period. + +Let $R_i$ be the fee rewards in block $i$, and $n_i$ be the total amount bonded to that validator in that block. +The correct amount of rewards which 1 token at genesis should have now is: +$$Reward(now) = \sum_{i = 0}^{now}\left(\prod_{j = 0}^{i} 1 + x_j \right) * \frac{R_i}{n_i}$$ +The term in the sum is the amount of stake one stake becomes due to inflation, multiplied by the amount of fees per stake. + +Now we cast this into the period frame of view. +Recall that we build the rewards by creating a state entry for the rewards of the previous period, and keeping track of the rewards within this period. +Thus we first define the correct amount of rewards for each successive period, proving correctness of this via induction. +We then show that the state entry that gets efficiently built up block by block is equal to this value for the latest period. + +Let $start, end$ denote the start/end of a period. + +Suppose that $\forall f > 0$, $Reward(end(f))$ is correctly constructed as +$$Reward(end(f)) = Reward(end(f-1)) + \sum_{i = start(f)}^{end(f)}\left(\prod_{j = 0}^{i} 1 + x_j \right) \frac{R_i}{n_i}$$ +and that for $f = 0$, $Reward(end(0)) = 0$. +(With period 1 being defined as the period that has the first bond into it) +It must be shown that assuming the supposition $\forall f \leq f_0$, $$Reward(end(f_0 + 1)) = Reward(end(f_0)) + \sum_{i = start(f_0 + 1)}^{end(f_0 + 1)}\left(\prod_{j = 0}^{i} 1 + x_j \right) \frac{R_i}{n_i}$$ +Using the definition of $Reward$, it follows that: +$$\sum_{i = 0}^{end(f_0 + 1)}\left(\prod_{j = 0}^{i} 1 + x_j \right) * \frac{R_i}{n_i} = \sum_{i = 0}^{end(f_0)}\left(\prod_{j = 0}^{i} 1 + x_j \right) * \frac{R_i}{n_i} + \sum_{i = start(f_0 + 1)}^{end(f_0 + 1)}\left(\prod_{j = 0}^{i} 1 + x_j \right) \frac{R_i}{n_i}$$ + +Since the first summation on the right hand side is $Reward(end(f_0))$, the supposition is proven true. +Consequently, the reward for just period $f$ adjusted for the amount of inflation 1 token at genesis would produce, is: +$$\sum_{i = start(f)}^{end(f)}\left(\prod_{j = 0}^{i} 1 + x_j \right) \frac{R_i}{n_i}$$ + +TODO: make this proof + pre-amble less verbose, and just wrap up into a lemma. +Maybe just leave this proof or the last part to the reader, since it easily follows from summation bounds. + +Now note that +$$\sum_{i = start(f)}^{end(f)}\left(\prod_{j = 0}^{i} 1 + x_j \right) \frac{R_i}{n_i} = \left(\prod_{j = 0}^{end(f - 1)} 1 + x_j \right)\sum_{i = start(f)}^{end(f)}\left(\prod_{j = start(f)}^{i} 1 + x_j \right) \frac{R_i}{n_i}$$ +By definition of period, and inflation being applied every block, \\ +$n_i = n_{start(f)}\left(\prod_{j = start(f)}^{i} 1 + x_j \right)$. This cancels out the product in the summation, therefore +$$\sum_{i = start(f)}^{end(f)}\left(\prod_{j = 0}^{i} 1 + x_j \right) \frac{R_i}{n_i} = \left(\prod_{j = 0}^{end(f - 1)} 1 + x_j \right)\frac{\sum_{i = start(f)}^{end(f)}R_i}{n_{start(f)}}$$ + +Thus every block, each validator just has to add the total amount of fees (The $R_i$ term) that goes to delegates to some per-period term. +When creating a new period, $n_{start(f)}$ can be cached in state, and the product is already stored in the previous periods state entry. +You then get the next period's $n_{start(f)}$ from the consensus' power entry for this validator. +This is thus extremely efficient per block. + +When withdrawing, you take the difference as before, +which yields the amount of rewards you would have obtained with $(\prod_0^{begin\ bonding\ period}1 + x)$ stake from the block you began bonding at until now. +$(\prod_0^{begin\ bonding\ period}1 + x)$ is known, since its included in the state entry for when you bonded. +You then divide the entitled fees by $(\prod_0^{begin\ bonding\ period}1 + x)$ to normalize it to being the amount of rewards you're entitled to from 1 stake at that block to now. +Then as before, you multiply by the amount of stake you had initially bonded. +\\TODO: (Does the difference equating to that make sense, or should it be shown explicitly) +\\TODO: Does this need to explain how the originally bonded tokens are refunded, or is that clear? + +The inflation function could vary per block, +and per validator if ever a need rose. +If the inflation rate is the same for everyone then there can be a single global store for the entries corresponding to the product of inflations. +Inflation creation can trivially be epoched as long as inflation isn't required within the epoch, through changes to the $inflation$ function. + +\subsection{Withdrawing with no iteration over slashes} +Notice that a slash is the same as a negative inflation rate for a validator in one block. +For example a $20\%$ slash is equivalent to a $-20\%$ inflation for a validator in a block. +Given correctness of auto-bonding inflation with different inflation rates per-validator, +it follows that handling slashes can be correctly done by simply subtracting the validators inflation factor in that block to be the negative of the slash factor. +This significantly simplifies the withdrawal procedure. + +\subsection{Auto bonding fees} +TODO: Fill this out. +Core idea: you use the same mechanism as previously, but you just don't take that optimization with $n_{i}$ and the $n_{start}$ relation. +Fairly simple to do. + +\subsection{Delegation updates} +Updating your delegation amount is equivalent to withdrawing earned rewards and a fully independent new delegation occurring in the same block. +The same applies for redelegation. +From the view of fee distribution, partial redelegation is the same as a delegation update + a new delegation. + +\subsection{Jailing / being kicked out of the validator set} +This basically requires no change. +In each block you only iterate over the currently bonded validators. +So you simply don't update the "total accrued fees this period" variable for jailed / non-bonded validators. +Withdrawing requires \textit{no} special casing here! + +\section{State Requirements} +State entries can be pruned quite effectively. +Suppose for the sake of exposition that there is at most one delegation / withdrawal to a particular validator in any given block. +Then each delegation is responsible for one addition to state. +Only the next period, and this delegator's withdrawal could depend on this entry. Thus once this delegator withdraws, this state entry can be pruned. +For the entry created by the delegator's withdrawal, that is only required by the creation of the next period. +Thus once the next period is created, that withdrawal's period can be deleted. + +This can be easily adapted to the case where there are multiple delegations / withdrawals per block, by maintaining a reference count in each period starting state entry. + +The slash entries for a validator can only be pruned when all of that validator's delegators have their bonding period starting after the slash. +This seems ineffective to keep track of, thus it is not worth it. +Each slash should instead remain in state until the validator unbonds and all delegators have their fees withdrawn. + +\section{Implementers Considerations} +TODO: Convert this section into a proper conclusion + +This is an extremely simple scheme with many nice benefits. +\begin{itemize} + \item The overhead per block is a simple iteration over the bonded validator set, which occurs anyway. (Thus it can be implemented ``for-free" with an optimized code-base) + \item Withdrawing earned fees only requires iterating over slashes since when you bonded. (Which is a negligible iteration) + \item There are no approximations in any of the calculations. (modulo minor errata resulting from fixed precision decimals used in divisions) + \item Supports arbitrary inflation models. (Thus could even vary upon block signers) + \item Supports arbitrary fee distribution amongst the validator set. (Thus can account for things like only online validators get fees, which has important incentivization impacts) + \item The above two can change on a live chain with no issues. + \item Validator commission rates can be changed every block + \item The simplicity of this scheme lends itself well to implementation +\end{itemize} + +Thus this scheme has efficiency improvements, simplicity improvements, and expressiveness improvements over the currently proposed schemes. With a correct fee distribution amongst the validator set, this solves the existing problem where one could withhold their signature for risk-free gain. + +\section{TO DOs} + +\begin{itemize} + \item A global fee pool can be described. + \item Mention storage optimization for how to prune slashing entries in the uniform inflation and iteration over slashing case + \item Add equation numbers + \item perhaps re-organize so that the no iteration + \item Section on decimal precision considerations (would unums help?), and mitigating errors in calculation with floats and decimals. -- This probably belongs in a corrollary markdown file in the implementation + \item Consider indicating that the withdraw action need not be a tx type and could instead happen 'transparently' when more coins are needed, if a chain desired this for UX / p2p efficiency. +\end{itemize} + + +\end{document} diff --git a/versioned_docs/version-0.47/integrate/spec/reserve-pool/README.md b/versioned_docs/version-0.47/integrate/spec/reserve-pool/README.md new file mode 100644 index 000000000..6912ab0c4 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/spec/reserve-pool/README.md @@ -0,0 +1,4 @@ +# Reserve Pool + +The reserve pool is the pool of collected funds for use by governance taken via the `CommunityTax`. +Currently with the Cosmos SDK, tokens collected by the CommunityTax are accounted for but unspendable. diff --git a/versioned_docs/version-0.47/integrate/spec/store/README.md b/versioned_docs/version-0.47/integrate/spec/store/README.md new file mode 100644 index 000000000..c53d69c67 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/spec/store/README.md @@ -0,0 +1,235 @@ +# Store + +The store package defines the interfaces, types and abstractions for Cosmos SDK +modules to read and write to Merkleized state within a Cosmos SDK application. +The store package provides many primitives for developers to use in order to +work with both state storage and state commitment. Below we describe the various +abstractions. + +## Types + +### `Store` + +The bulk of the store interfaces are defined [here](https://github.com/cosmos/cosmos-sdk/blob/main/store/types/store.go), +where the base primitive interface, for which other interfaces build off of, is +the `Store` type. The `Store` interface defines the ability to tell the type of +the implementing store and the ability to cache wrap via the `CacheWrapper` interface. + +### `CacheWrapper` & `CacheWrap` + +One of the most important features a store has the ability to perform is the +ability to cache wrap. Cache wrapping is essentially the underlying store wrapping +itself within another store type that performs caching for both reads and writes +with the ability to flush writes via `Write()`. + +### `KVStore` & `CacheKVStore` + +One of the most important interfaces that both developers and modules interface +with, which also provides the basis of most state storage and commitment operations, +is the `KVStore`. The `KVStore` interface provides basic CRUD abilities and +prefix-based iteration, including reverse iteration. + +Typically, each module has it's own dedicated `KVStore` instance, which it can +get access to via the `sdk.Context` and the use of a pointer-based named key -- +`KVStoreKey`. The `KVStoreKey` provides pseudo-OCAP. How a exactly a `KVStoreKey` +maps to a `KVStore` will be illustrated below through the `CommitMultiStore`. + +Note, a `KVStore` cannot directly commit state. Instead, a `KVStore` can be wrapped +by a `CacheKVStore` which extends a `KVStore` and provides the ability for the +caller to execute `Write()` which commits state to the underlying state storage. +Note, this doesn't actually flush writes to disk as writes are held in memory +until `Commit()` is called on the `CommitMultiStore`. + +### `CommitMultiStore` + +The `CommitMultiStore` interface exposes the the top-level interface that is used +to manage state commitment and storage by an SDK application and abstracts the +concept of multiple `KVStore`s which are used by multiple modules. Specifically, +it supports the following high-level primitives: + +* Allows for a caller to retrieve a `KVStore` by providing a `KVStoreKey`. +* Exposes pruning mechanisms to remove state pinned against a specific height/version + in the past. +* Allows for loading state storage at a particular height/version in the past to + provide current head and historical queries. +* Provides the ability to rollback state to a previous height/version. +* Provides the ability to to load state storage at a particular height/version + while also performing store upgrades, which are used during live hard-fork + application state migrations. +* Provides the ability to commit all current accumulated state to disk and performs + Merkle commitment. + +## Implementation Details + +While there are many interfaces that the `store` package provides, there is +typically a core implementation for each main interface that modules and +developers interact with that are defined in the Cosmos SDK. + +### `iavl.Store` + +The `iavl.Store` provides the core implementation for state storage and commitment +by implementing the following interfaces: + +* `KVStore` +* `CommitStore` +* `CommitKVStore` +* `Queryable` +* `StoreWithInitialVersion` + +It allows for all CRUD operations to be performed along with allowing current +and historical state queries, prefix iteration, and state commitment along with +Merkle proof operations. The `iavl.Store` also provides the ability to remove +historical state from the state commitment layer. + +An overview of the IAVL implementation can be found [here](https://github.com/cosmos/iavl/blob/master/docs/overview.md). +It is important to note that the IAVL store provides both state commitment and +logical storage operations, which comes with drawbacks as there are various +performance impacts, some of which are very drastic, when it comes to the +operations mentioned above. + +When dealing with state management in modules and clients, the Cosmos SDK provides +various layers of abstractions or "store wrapping", where the `iavl.Store` is the +bottom most layer. When requesting a store to perform reads or writes in a module, +the typical abstraction layer in order is defined as follows: + +```text +iavl.Store <- cachekv.Store <- gaskv.Store <- cachemulti.Store <- rootmulti.Store +``` + +### Concurrent use of IAVL store + +The tree under `iavl.Store` is not safe for concurrent use. It is the +responsibility of the caller to ensure that concurrent access to the store is +not performed. + +The main issue with concurrent use is when data is written at the same time as +it's being iterated over. Doing so will cause a irrecoverable fatal error because +of concurrent reads and writes to an internal map. + +Although it's not recommended, you can iterate through values while writing to +it by disabling "FastNode" **without guarantees that the values being written will +be returned during the iteration** (if you need this, you might want to reconsider +the design of your application). This is done by setting `iavl-disable-fastnode` +to `true` in the config TOML file. + +### `cachekv.Store` + +The `cachekv.Store` store wraps an underlying `KVStore`, typically a `iavl.Store` +and contains an in-memory cache for storing pending writes to underlying `KVStore`. +`Set` and `Delete` calls are executed on the in-memory cache, whereas `Has` calls +are proxied to the underlying `KVStore`. + +One of the most important calls to a `cachekv.Store` is `Write()`, which ensures +that key-value pairs are written to the underlying `KVStore` in a deterministic +and ordered manner by sorting the keys first. The store keeps track of "dirty" +keys and uses these to determine what keys to sort. In addition, it also keeps +track of deleted keys and ensures these are also removed from the underlying +`KVStore`. + +The `cachekv.Store` also provides the ability to perform iteration and reverse +iteration. Iteration is performed through the `cacheMergeIterator` type and uses +both the dirty cache and underlying `KVStore` to iterate over key-value pairs. + +Note, all calls to CRUD and iteration operations on a `cachekv.Store` are thread-safe. + +### `gaskv.Store` + +The `gaskv.Store` store provides a simple implementation of a `KVStore`. +Specifically, it just wraps an existing `KVStore`, such as a cache-wrapped +`iavl.Store`, and incurs configurable gas costs for CRUD operations via +`ConsumeGas()` calls defined on the `GasMeter` which exists in a `sdk.Context` +and then proxies the underlying CRUD call to the underlying store. Note, the +`GasMeter` is reset on each block. + +### `cachemulti.Store` & `rootmulti.Store` + +The `rootmulti.Store` acts as an abstraction around a series of stores. Namely, +it implements the `CommitMultiStore` an `Queryable` interfaces. Through the +`rootmulti.Store`, an SDK module can request access to a `KVStore` to perform +state CRUD operations and queries by holding access to a unique `KVStoreKey`. + +The `rootmulti.Store` ensures these queries and state operations are performed +through cached-wrapped instances of `cachekv.Store` which is described above. The +`rootmulti.Store` implementation is also responsible for committing all accumulated +state from each `KVStore` to disk and returning an application state Merkle root. + +Queries can be performed to return state data along with associated state +commitment proofs for both previous heights/versions and the current state root. +Queries are routed based on store name, i.e. a module, along with other parameters +which are defined in `abci.RequestQuery`. + +The `rootmulti.Store` also provides primitives for pruning data at a given +height/version from state storage. When a height is committed, the `rootmulti.Store` +will determine if other previous heights should be considered for removal based +on the operator's pruning settings defined by `PruningOptions`, which defines +how many recent versions to keep on disk and the interval at which to remove +"staged" pruned heights from disk. During each interval, the staged heights are +removed from each `KVStore`. Note, it is up to the underlying `KVStore` +implementation to determine how pruning is actually performed. The `PruningOptions` +are defined as follows: + +```go +type PruningOptions struct { + // KeepRecent defines how many recent heights to keep on disk. + KeepRecent uint64 + + // Interval defines when the pruned heights are removed from disk. + Interval uint64 + + // Strategy defines the kind of pruning strategy. See below for more information on each. + Strategy PruningStrategy +} +``` + +The Cosmos SDK defines a preset number of pruning "strategies": `default`, `everything` +`nothing`, and `custom`. + +It is important to note that the `rootmulti.Store` considers each `KVStore` as a +separate logical store. In other words, they do not share a Merkle tree or +comparable data structure. This means that when state is committed via +`rootmulti.Store`, each store is committed in sequence and thus is not atomic. + +In terms of store construction and wiring, each Cosmos SDK application contains +a `BaseApp` instance which internally has a reference to a `CommitMultiStore` +that is implemented by a `rootmulti.Store`. The application then registers one or +more `KVStoreKey` that pertain to a unique module and thus a `KVStore`. Through +the use of an `sdk.Context` and a `KVStoreKey`, each module can get direct access +to it's respective `KVStore` instance. + +Example: + +```go +func NewApp(...) Application { + // ... + + bApp := baseapp.NewBaseApp(appName, logger, db, txConfig.TxDecoder(), baseAppOptions...) + bApp.SetCommitMultiStoreTracer(traceStore) + bApp.SetVersion(version.Version) + bApp.SetInterfaceRegistry(interfaceRegistry) + + // ... + + keys := sdk.NewKVStoreKeys(...) + transientKeys := sdk.NewTransientStoreKeys(...) + memKeys := sdk.NewMemoryStoreKeys(...) + + // ... + + // initialize stores + app.MountKVStores(keys) + app.MountTransientStores(transientKeys) + app.MountMemoryStores(memKeys) + + // ... +} +``` + +The `rootmulti.Store` itself can be cache-wrapped which returns an instance of a +`cachemulti.Store`. For each block, `BaseApp` ensures that the proper abstractions +are created on the `CommitMultiStore`, i.e. ensuring that the `rootmulti.Store` +is cached-wrapped and uses the resulting `cachemulti.Store` to be set on the +`sdk.Context` which is then used for block and transaction execution. As a result, +all state mutations due to block and transaction execution are actually held +ephemerally until `Commit()` is called by the ABCI client. This concept is further +expanded upon when the AnteHandler is executed per transaction to ensure state +is not committed for transactions that failed CheckTx. diff --git a/versioned_docs/version-0.47/integrate/tooling/00-protobuf.md b/versioned_docs/version-0.47/integrate/tooling/00-protobuf.md new file mode 100644 index 000000000..42e9d3bf0 --- /dev/null +++ b/versioned_docs/version-0.47/integrate/tooling/00-protobuf.md @@ -0,0 +1,113 @@ +--- +sidebar_position: 1 +--- + +# Protocol Buffers + +It is known that Cosmos SDK uses protocol buffers extensively, this docuemnt is meant to provide a guide on how it is used in the cosmos-sdk. + +To generate the proto file, the Cosmos SDK uses a docker image, this image is provided to all to use as well. The latest version is `ghcr.io/cosmos/proto-builder:0.11.2` + +Below is the example of the Cosmos SDK's commands for generating, linting, and formatting protobuf files that can be reused in any applications makefile. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/Makefile#L411-L432 +``` + +The script used to generate the protobuf files can be found in the `scripts/` directory. + +```shell reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/scripts/protocgen.sh#L1-L37 +``` + +## Buf + +[Buf](https://buf.build) is a protobuf tool that abstracts the needs to use the complicated `protoc` toolchain on top of various other things that ensure you are using protobuf in accordance with the majority of the ecosystem. Within the cosmos-sdk repository there are a few files that have a buf prefix. Lets start with the top level and then dive into the various directories. + +### Workspace + +At the root level directory a workspace is defined using [buf workspaces](https://docs.buf.build/configuration/v1/buf-work-yaml). This helps if there are one or more protobuf containing directories in your project. + +Cosmos SDK example: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/main/buf.work.yaml#L6-L9 +``` + +### Proto Directory + +Next is the `proto/` directory where all of our protobuf files live. In here there are many different buf files defined each serving a different purpose. + +```bash +├── README.md +├── buf.gen.gogo.yaml +├── buf.gen.pulsar.yaml +├── buf.gen.swagger.yaml +├── buf.lock +├── buf.md +├── buf.yaml +├── cosmos +└── tendermint +``` + +The above diagram all the files and directories within the Cosmos SDK `proto/` directory. + +#### `buf.gen.gogo.yaml` + +`buf.gen.gogo.yaml` defines how the protobuf files should be generated for use with in the module. This file uses [gogoproto](https://github.com/gogo/protobuf), a separate generator from the google go-proto generator that makes working with various objects more ergonomic, and it has more performant encode and decode steps + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/main/proto/buf.gen.gogo.yaml#L1-L9 +``` + +:::tip +Example of how to define `gen` files can be found [here](https://docs.buf.build/tour/generate-go-code) +::: + +#### `buf.gen.pulsar.yaml` + +`buf.gen.pulsar.yaml` defines how protobuf files should be generated using the [new golang apiv2 of protobuf](https://go.dev/blog/protobuf-apiv2). This generator is used instead of the google go-proto generator because it has some extra helpers for Cosmos SDK applications and will have more performant encode and decode than the google go-proto generator. You can follow the development of this generator [here](https://github.com/cosmos/cosmos-proto). + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/main/proto/buf.gen.pulsar.yaml#L1-L18 +``` + +:::tip +Example of how to define `gen` files can be found [here](https://docs.buf.build/tour/generate-go-code) +::: + +#### `buf.gen.swagger.yaml` + +`buf.gen.swagger.yaml` generates the swagger documentation for the query and messages of the chain. This will only define the REST API end points that were defined in the query and msg servers. You can find examples of this [here](https://github.com/cosmos/cosmos-sdk/blob/main/proto/cosmos/bank/v1beta1/query.proto#L19) + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/main/proto/buf.gen.swagger.yaml#L1-L6 +``` + +:::tip +Example of how to define `gen` files can be found [here](https://docs.buf.build/tour/generate-go-code) +::: + +#### `buf.lock` + +This is a autogenerated file based off the dependencies required by the `.gen` files. There is no need to copy the current one. If you depend on cosmos-sdk proto definitions a new entry for the Cosmos SDK will need to be provided. The dependency you will need to use is `buf.build/cosmos/cosmos-sdk`. + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/main/proto/buf.lock#L1-L16 +``` + +#### `buf.yaml` + +`buf.yaml` defines the [name of your package](https://github.com/cosmos/cosmos-sdk/blob/main/proto/buf.yaml#L3), which [breakage checker](https://docs.buf.build/tour/detect-breaking-changes) to use and how to [lint your protobuf files](https://docs.buf.build/tour/lint-your-api). + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/main/proto/buf.yaml#L1-L24 +``` + +We use a variety of linters for the Cosmos SDK protobuf files. The repo also checks this in ci. + +A reference to the github actions can be found [here](https://github.com/cosmos/cosmos-sdk/blob/main/.github/workflows/proto.yml#L1-L32) + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/main/.github/workflows/proto.yml#L1-L32 +``` diff --git a/versioned_docs/version-0.47/integrate/tooling/README.md b/versioned_docs/version-0.47/integrate/tooling/README.md new file mode 100644 index 000000000..c8b3af88d --- /dev/null +++ b/versioned_docs/version-0.47/integrate/tooling/README.md @@ -0,0 +1,11 @@ +--- +sidebar_position: 0 +--- + +# Tools + +This section provides documentation on various tooling used in development of a Cosmos SDK chain, operating a node and testing. + +* [Protocol Buffers](./00-protobuf.md) +* [Cosmovisor](./01-cosmovisor.md) +* [Depinject](./02-depinject.md) diff --git a/versioned_docs/version-0.47/integrate/tooling/_category_.json b/versioned_docs/version-0.47/integrate/tooling/_category_.json new file mode 100644 index 000000000..d91e08b5a --- /dev/null +++ b/versioned_docs/version-0.47/integrate/tooling/_category_.json @@ -0,0 +1,5 @@ +{ + "label": "Tooling", + "position": 9, + "link": null +} \ No newline at end of file diff --git a/versioned_docs/version-0.47/user/run-node/00-keyring.md b/versioned_docs/version-0.47/user/run-node/00-keyring.md new file mode 100644 index 000000000..2cb15b115 --- /dev/null +++ b/versioned_docs/version-0.47/user/run-node/00-keyring.md @@ -0,0 +1,134 @@ +--- +sidebar_position: 1 +--- + +# Setting up the keyring + +:::note Synopsis +This document describes how to configure and use the keyring and its various backends for an [**application**](../basics/00-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. + +### The `os` backend + +The `os` backend relies on operating system-specific defaults to handle key storage +securely. Typically, an operating system's credential sub-system handles password prompts, +private keys storage, and user sessions according to the user's password policies. Here +is a list of the most popular operating systems and their respective passwords manager: + +* macOS: [Keychain](https://support.apple.com/en-gb/guide/keychain-access/welcome/mac) +* Windows: [Credentials Management API](https://docs.microsoft.com/en-us/windows/win32/secauthn/credentials-management) +* GNU/Linux: + * [libsecret](https://gitlab.gnome.org/GNOME/libsecret) + * [kwallet](https://api.kde.org/frameworks/kwallet/html/index.html) + +GNU/Linux distributions that use GNOME as default desktop environment typically come with +[Seahorse](https://wiki.gnome.org/Apps/Seahorse). Users of KDE based distributions are +commonly provided with [KDE Wallet Manager](https://userbase.kde.org/KDE_Wallet_Manager). +Whilst the former is in fact a `libsecret` convenient frontend, the latter is a `kwallet` +client. + +`os` is the default option since operating system's default credentials managers are +designed to meet users' most common needs and provide them with a comfortable +experience without compromising on security. + +The recommended backends for headless environments are `file` and `pass`. + +### The `file` backend + +The `file` backend more closely resembles the keybase implementation used prior to +v0.38.1. It stores the keyring encrypted within the app's configuration directory. This +keyring will request a password each time it is accessed, which may occur multiple +times in a single command resulting in repeated password prompts. If using bash scripts +to execute commands using the `file` option you may want to utilize the following format +for multiple prompts: + +```shell +# assuming that KEYPASSWD is set in the environment +$ gaiacli config keyring-backend file # use file backend +$ (echo $KEYPASSWD; echo $KEYPASSWD) | gaiacli keys add me # multiple prompts +$ echo $KEYPASSWD | gaiacli keys show me # single prompt +``` + +:::tip +The first time you add a key to an empty keyring, you will be prompted to type the password twice. +::: + +### The `pass` backend + +The `pass` backend uses the [pass](https://www.passwordstore.org/) utility to manage on-disk +encryption of keys' sensitive data and metadata. Keys are stored inside `gpg` encrypted files +within app-specific directories. `pass` is available for the most popular UNIX +operating systems as well as GNU/Linux distributions. Please refer to its manual page for +information on how to download and install it. + +:::tip +**pass** uses [GnuPG](https://gnupg.org/) for encryption. `gpg` automatically invokes the `gpg-agent` +daemon upon execution, which handles the caching of GnuPG credentials. Please refer to `gpg-agent` +man page for more information on how to configure cache parameters such as credentials TTL and +passphrase expiration. +::: + +The password store must be set up prior to first use: + +```shell +pass init +``` + +Replace `` with your GPG key ID. You can use your personal GPG key or an alternative +one you may want to use specifically to encrypt the password store. + +### The `kwallet` backend + +The `kwallet` backend uses `KDE Wallet Manager`, which comes installed by default on the +GNU/Linux distributions that ships KDE as default desktop environment. Please refer to +[KWallet Handbook](https://docs.kde.org/stable5/en/kdeutils/kwallet5/index.html) for more +information. + +### The `test` backend + +The `test` backend is a password-less variation of the `file` backend. Keys are stored +unencrypted on disk. + +**Provided for testing purposes only. The `test` backend is not recommended for use in production environments**. + +### The `memory` backend + +The `memory` backend stores keys in memory. The keys are immediately deleted after the program has exited. + +**Provided for testing purposes only. The `memory` backend is not recommended for use in production environments**. + +### Setting backend using the env variable + +You can set the keyring-backend using env variable: `BINNAME_KEYRING_BACKEND`. For example, if you binary name is `gaia-v5` then set: `export GAIA_V5_KEYRING_BACKEND=pass` + +## Adding keys to the keyring + +:::warning +Make sure you can build your own binary, and replace `simd` with the name of your binary in the snippets. +::: + +Applications developed using the Cosmos SDK come with the `keys` subcommand. For the purpose of this tutorial, we're running the `simd` CLI, which is an application built using the Cosmos SDK for testing and educational purposes. For more information, see [`simapp`](https://github.com/cosmos/cosmos-sdk/tree/main/simapp). + +You can use `simd keys` for help about the keys command and `simd keys [command] --help` for more information about a particular subcommand. + +To create a new key in the keyring, run the `add` subcommand with a `` argument. For the purpose of this tutorial, we will solely use the `test` backend, and call our new key `my_validator`. This key will be used in the next section. + +```bash +$ simd keys add my_validator --keyring-backend test + +# Put the generated address in a variable for later use. +MY_VALIDATOR_ADDRESS=$(simd keys show my_validator -a --keyring-backend test) +``` + +This command generates a new 24-word mnemonic phrase, persists it to the relevant backend, and outputs information about the keypair. If this keypair will be used to hold value-bearing tokens, be sure to write down the mnemonic phrase somewhere safe! + +By default, the keyring generates a `secp256k1` keypair. The keyring also supports `ed25519` keys, which may be created by passing the `--algo ed25519` flag. A keyring can of course hold both types of keys simultaneously, and the Cosmos SDK's `x/auth` module supports natively these two public key algorithms. diff --git a/versioned_docs/version-0.47/user/run-node/01-run-node.md b/versioned_docs/version-0.47/user/run-node/01-run-node.md new file mode 100644 index 000000000..a04038027 --- /dev/null +++ b/versioned_docs/version-0.47/user/run-node/01-run-node.md @@ -0,0 +1,192 @@ +--- +sidebar_position: 1 +--- + +# Running a Node + +:::note Synopsis +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/main/simapp), and its corresponding CLI binary `simd`. +::: + +:::note + +### Pre-requisite Readings + +* [Anatomy of a Cosmos SDK Application](../basics/00-app-anatomy.md) +* [Setting up the keyring](./00-keyring.md) + +::: + +## Initialize the Chain + +:::warning +Make sure you can build your own binary, and replace `simd` with the name of your binary in the snippets. +::: + +Before actually running the node, we need to initialize the chain, and most importantly its genesis file. This is done with the `init` subcommand: + +```bash +# The argument is the custom username of your node, it should be human-readable. +simd init --chain-id my-test-chain +``` + +The command above creates all the configuration files needed for your node to run, as well as a default genesis file, which defines the initial state of the network. All these configuration files are in `~/.simapp` by default, but you can overwrite the location of this folder by passing the `--home` flag. + +The `~/.simapp` folder has the following structure: + +```bash +. # ~/.simapp + |- data # Contains the databases used by the node. + |- config/ + |- app.toml # Application-related configuration file. + |- config.toml # CometBFT-related configuration file. + |- genesis.json # The genesis file. + |- node_key.json # Private key to use for node authentication in the p2p protocol. + |- priv_validator_key.json # Private key to use as a validator in the consensus protocol. +``` + +## 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. + +```bash +# to change the chain-id +jq '.chain_id = "testing"' genesis.json > temp.json && mv temp.json genesis.json + +# to enable the api server +sed -i '/\[api\]/,+3 s/enable = false/enable = true/' app.toml + +# to change the voting_period +jq '.app_state.gov.voting_params.voting_period = "600s"' genesis.json > temp.json && mv temp.json genesis.json + +# to change the inflation +jq '.app_state.mint.minter.inflation = "0.300000000000000000"' genesis.json > temp.json && mv temp.json genesis.json +``` + +### Client Interaction + +When instantiating a node, GRPC and REST are defaulted to localhost to avoid unknown exposure of your node to the public. It is recommended to not expose these endpoints without a proxy that can handle load balancing or authentication is setup between your node and the public. + +:::tip +A commonly used tool for this is [nginx](https://nginx.org). +::: + + +## 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](./00-keyring.md#adding-keys-to-the-keyring) named `my_validator` under the `test` keyring backend (feel free to choose another name and another backend). + +Now that you have created a local account, go ahead and grant it some `stake` tokens in your chain's genesis file. Doing so will also make sure your chain is aware of this account's existence: + +```bash +simd genesis 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](./00-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/main/simapp). For your own chain with its own staking denom, that token identifier should be used instead. + +Now that your account has some tokens, you need to add a validator to your chain. Validators are special full-nodes that participate in the consensus process (implemented in the [underlying consensus engine](../intro/02-sdk-app-architecture.md#cometbft)) in order to add new blocks to the chain. Any account can declare its intention to become a validator operator, but only those with sufficient delegation get to enter the active set (for example, only the top 125 validator candidates with the most delegation get to be validators in the Cosmos Hub). For this guide, you will add your local node (created via the `init` command above) as a validator of your chain. Validators can be declared before a chain is first started via a special transaction included in the genesis file called a `gentx`: + +```bash +# Create a gentx. +simd genesis gentx my_validator 100000000stake --chain-id my-test-chain --keyring-backend test + +# Add the gentx to the genesis file. +simd genesis collect-gentxs +``` + +A `gentx` does three things: + +1. Registers the `validator` account you created as a validator operator account (i.e. the account that controls the validator). +2. Self-delegates the provided `amount` of staking tokens. +3. Link the operator account with a CometBFT node pubkey that will be used for signing blocks. If no `--pubkey` flag is provided, it defaults to the local node pubkey created via the `simd init` command above. + +For more information on `gentx`, use the following command: + +```bash +simd genesis gentx --help +``` + +## Configuring the Node Using `app.toml` and `config.toml` + +The Cosmos SDK automatically generates two configuration files inside `~/.simapp/config`: + +* `config.toml`: used to configure the CometBFT, learn more on [CometBFT's documentation](https://docs.cometbft.com/v0.37/core/configuration), +* `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... + +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: + +```toml + # The minimum gas prices a validator is willing to accept for processing a + # transaction. A transaction's fees must meet the minimum of any denomination + # specified in this config (e.g. 0.25token1;0.0001token2). + minimum-gas-prices = "0stake" +``` + +## Run a Localnet + +Now that everything is set up, you can finally start your node: + +```bash +simd start +``` + +You should see blocks come in. + +The previous command allow you to run a single node. This is enough for the next section on interacting with this node, but you may wish to run multiple nodes at the same time, and see how consensus happens between them. + +The naive way would be to run the same commands again in separate terminal windows. This is possible, however in the 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.47.0-rc1/docker-compose.yml). + +## Logging + +Logging provides a way to see what is going on with a node. By default the info level is set. This is a global level and all info logs will be outputted to the terminal. If you would like to filter specific logs to the terminal instead of all, then setting `module:log_level` is how this can work. + +Example: + +In config.toml: + +```toml +log_level: "state:info,p2p:info,consensus:info,x/staking:info,x/ibc:info,*error" +``` + +## State Sync + +State sync is the act in which a node syncs the latest or close to the latest state of a blockchain. This is useful for users who don't want to sync all the blocks in history. Read more in [CometBFT documentation](https://docs.cometbft.com/v0.37/core/state-sync). + +State sync works thanks to snapshots. Read how the SDK handles snapshots [here](https://github.com/cosmos/cosmos-sdk/blob/825245d/store/snapshots/README.md). + +### Local State Sync + +Local state sync work similar to normal state sync except that it works off a local snapshot of state instead of one provided via the p2p network. The steps to start local state sync are similar to normal state sync with a few different designs. + +1. As mentioned in https://docs.cometbft.com/v0.37/core/state-sync, one must set a height and hash in the config.toml along with a few rpc servers (the afromentioned link has instructions on how to do this). +2. Run ` ` to restore a local snapshot (note: first load it from a file with the *load* command). +3. Bootsrapping Comet state in order to start the node after the snapshot has been ingested. This can be done with the bootstrap command ` comet bootstrap-state` + +### Snapshots Commands + +The Cosmos SDK provides commands for managing snapshots. +These commands can be added in an app with the following snippet in `cmd//root.go`: + +```go +import ( + "github.com/cosmos/cosmos-sdk/client/snapshot" +) + +func initRootCmd(/* ... */) { + // ... + rootCmd.AddCommand( + snapshot.Cmd(appCreator), + ) +} +``` + +Then following commands are available at ` snapshots [command]`: + +* **list**: list local snapshots +* **load**: Load a snapshot archive file into snapshot store +* **restore**: Restore app state from local snapshot +* **export**: Export app state to snapshot store +* **dump**: Dump the snapshot as portable archive format +* **delete**: Delete a local snapshot diff --git a/versioned_docs/version-0.47/user/run-node/02-interact-node.md b/versioned_docs/version-0.47/user/run-node/02-interact-node.md new file mode 100644 index 000000000..aaade7bce --- /dev/null +++ b/versioned_docs/version-0.47/user/run-node/02-interact-node.md @@ -0,0 +1,291 @@ +--- +sidebar_position: 1 +--- + +# Interacting with the Node + +:::note Synopsis +There are multiple ways to interact with a node: using the CLI, using gRPC or using the REST endpoints. +::: + +:::note + +### Pre-requisite Readings + +* [gRPC, REST and CometBFT Endpoints](../core/06-grpc_rest.md) +* [Running a Node](./01-run-node.md) + +::: + +## Using the CLI + +Now that your chain is running, it is time to try sending tokens from the first account you created to a second account. In a new terminal window, start by running the following query command: + +```bash +simd query bank balances $MY_VALIDATOR_ADDRESS +``` + +You should see the current balance of the account you created, equal to the original balance of `stake` you granted it minus the amount you delegated via the `gentx`. Now, create a second account: + +```bash +simd keys add recipient --keyring-backend test + +# Put the generated address in a variable for later use. +RECIPIENT=$(simd keys show recipient -a --keyring-backend test) +``` + +The command above creates a local key-pair that is not yet registered on the chain. An account is created the first time it receives tokens from another account. Now, run the following command to send tokens to the `recipient` account: + +```bash +simd tx bank send $MY_VALIDATOR_ADDRESS $RECIPIENT 1000000stake --chain-id my-test-chain --keyring-backend test + +# Check that the recipient account did receive the tokens. +simd query bank balances $RECIPIENT +``` + +Finally, delegate some of the stake tokens sent to the `recipient` account to the validator: + +```bash +simd tx staking delegate $(simd keys show my_validator --bech val -a --keyring-backend test) 500stake --from recipient --chain-id my-test-chain --keyring-backend test + +# Query the total delegations to `validator`. +simd query staking delegations-to $(simd keys show my_validator --bech val -a --keyring-backend test) +``` + +You should see two delegations, the first one made from the `gentx`, and the second one you just performed from the `recipient` account. + +## Using gRPC + +The Protobuf ecosystem developed tools for different use cases, including code-generation from `*.proto` files into various languages. These tools allow 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/06-grpc_rest.md). + +Since the code generation library largely depends on your own tech stack, we will only present three alternatives: + +* `grpcurl` for generic debugging and testing, +* programmatically via Go, +* CosmJS for JavaScript/TypeScript developers. + +### grpcurl + +[grpcurl](https://github.com/fullstorydev/grpcurl) is like `curl` but for gRPC. It is also available as a Go library, but we will use it only as a CLI command for debugging and testing purposes. Follow the instructions in the previous link to install it. + +Assuming you have a local node running (either a localnet, or connected a live network), you should be able to run the following command to list the Protobuf services available (you can replace `localhost:9000` by the gRPC server endpoint of another node, which is configured under the `grpc.address` field inside [`app.toml`](../run-node/01-run-node.md#configuring-the-node-using-apptoml)): + +```bash +grpcurl -plaintext localhost:9090 list +``` + +You should see a list of gRPC services, like `cosmos.bank.v1beta1.Query`. This is called reflection, which is a Protobuf endpoint returning a description of all available endpoints. Each of these represents a different Protobuf service, and each service exposes multiple RPC methods you can query against. + +In order to get a description of the service you can run the following command: + +```bash +grpcurl -plaintext \ + localhost:9090 \ + describe cosmos.bank.v1beta1.Query # Service we want to inspect +``` + +It's also possible to execute an RPC call to query the node for information: + +```bash +grpcurl \ + -plaintext \ + -d "{\"address\":\"$MY_VALIDATOR_ADDRESS\"}" \ + localhost:9090 \ + cosmos.bank.v1beta1.Query/AllBalances +``` + +The list of all available gRPC query endpoints is [coming soon](https://github.com/cosmos/cosmos-sdk/issues/7786). + +#### Query for historical state using grpcurl + +You may also query for historical data by passing some [gRPC metadata](https://github.com/grpc/grpc-go/blob/master/Documentation/grpc-metadata.md) to the query: the `x-cosmos-block-height` metadata should contain the block to query. Using grpcurl as above, the command looks like: + +```bash +grpcurl \ + -plaintext \ + -H "x-cosmos-block-height: 123" \ + -d "{\"address\":\"$MY_VALIDATOR_ADDRESS\"}" \ + localhost:9090 \ + cosmos.bank.v1beta1.Query/AllBalances +``` + +Assuming the state at that block has not yet been pruned by the node, this query should return a non-empty response. + +### Programmatically via Go + +The following snippet shows how to query the state using gRPC inside a Go program. The idea is to create a gRPC connection, and use the Protobuf-generated client code to query the gRPC server. + +#### Install Cosmos SDK + + +```bash +go get github.com/cosmos/cosmos-sdk@main +``` + +```go +package main + +import ( + "context" + "fmt" + + "google.golang.org/grpc" + + "github.com/cosmos/cosmos-sdk/codec" + sdk "github.com/cosmos/cosmos-sdk/types" + banktypes "github.com/cosmos/cosmos-sdk/x/bank/types" +) + +func queryState() error { + myAddress, err := sdk.AccAddressFromBech32("cosmos1...") // the my_validator or recipient address. + if err != nil { + return err + } + + // Create a connection to the gRPC server. + grpcConn, err := grpc.Dial( + "127.0.0.1:9090", // your gRPC server address. + grpc.WithInsecure(), // The Cosmos SDK doesn't support any transport security mechanism. + // This instantiates a general gRPC codec which handles proto bytes. We pass in a nil interface registry + // if the request/response types contain interface instead of 'nil' you should pass the application specific codec. + grpc.WithDefaultCallOptions(grpc.ForceCodec(codec.NewProtoCodec(nil).GRPCCodec())), + ) + if err != nil { + return err + } + defer grpcConn.Close() + + // This creates a gRPC client to query the x/bank service. + bankClient := banktypes.NewQueryClient(grpcConn) + bankRes, err := bankClient.Balance( + context.Background(), + &banktypes.QueryBalanceRequest{Address: myAddress.String(), Denom: "stake"}, + ) + if err != nil { + return err + } + + fmt.Println(bankRes.GetBalance()) // Prints the account balance + + return nil +} + +func main() { + if err := queryState(); err != nil { + panic(err) + } +} +``` + +You can replace the query client (here we are using `x/bank`'s) with one generated from any other Protobuf service. The list of all available gRPC query endpoints is [coming soon](https://github.com/cosmos/cosmos-sdk/issues/7786). + +#### Query for historical state using Go + +Querying for historical blocks is done by adding the block height metadata in the gRPC request. + +```go +package main + +import ( + "context" + "fmt" + + "google.golang.org/grpc" + "google.golang.org/grpc/metadata" + + "github.com/cosmos/cosmos-sdk/codec" + sdk "github.com/cosmos/cosmos-sdk/types" + grpctypes "github.com/cosmos/cosmos-sdk/types/grpc" + banktypes "github.com/cosmos/cosmos-sdk/x/bank/types" +) + +func queryState() error { + myAddress, err := sdk.AccAddressFromBech32("cosmos1yerherx4d43gj5wa3zl5vflj9d4pln42n7kuzu") // the my_validator or recipient address. + if err != nil { + return err + } + + // Create a connection to the gRPC server. + grpcConn, err := grpc.Dial( + "127.0.0.1:9090", // your gRPC server address. + grpc.WithInsecure(), // The Cosmos SDK doesn't support any transport security mechanism. + // This instantiates a general gRPC codec which handles proto bytes. We pass in a nil interface registry + // if the request/response types contain interface instead of 'nil' you should pass the application specific codec. + grpc.WithDefaultCallOptions(grpc.ForceCodec(codec.NewProtoCodec(nil).GRPCCodec())), + ) + if err != nil { + return err + } + defer grpcConn.Close() + + // This creates a gRPC client to query the x/bank service. + bankClient := banktypes.NewQueryClient(grpcConn) + + var header metadata.MD + _, err = bankClient.Balance( + metadata.AppendToOutgoingContext(context.Background(), grpctypes.GRPCBlockHeightHeader, "12"), // Add metadata to request + &banktypes.QueryBalanceRequest{Address: myAddress.String(), Denom: "stake"}, + grpc.Header(&header), // Retrieve header from response + ) + if err != nil { + return err + } + blockHeight := header.Get(grpctypes.GRPCBlockHeightHeader) + + fmt.Println(blockHeight) // Prints the block height (12) + + return nil +} + +func main() { + if err := queryState(); err != nil { + panic(err) + } +} +``` + +### CosmJS + +CosmJS documentation can be found at [https://cosmos.github.io/cosmjs](https://cosmos.github.io/cosmjs). As of January 2021, CosmJS documentation is still work in progress. + +## Using the REST Endpoints + +As described in the [gRPC guide](../core/06-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. + +Note that the REST endpoints are not enabled by default. To enable them, edit the `api` section of your `~/.simapp/config/app.toml` file: + +```toml +# Enable defines if the API server should be enabled. +enable = true +``` + +As a concrete example, the `curl` command to make balances request is: + +```bash +curl \ + -X GET \ + -H "Content-Type: application/json" \ + http://localhost:1317/cosmos/bank/v1beta1/balances/$MY_VALIDATOR_ADDRESS +``` + +Make sure to replace `localhost:1317` with the REST endpoint of your node, configured under the `api.address` field. + +The list of all available REST endpoints is available as a Swagger specification file, it can be viewed at `localhost:1317/swagger`. Make sure that the `api.swagger` field is set to true in your [`app.toml`](../run-node/01-run-node.md#configuring-the-node-using-apptoml) file. + +### Query for historical state using REST + +Querying for historical state is done using the HTTP header `x-cosmos-block-height`. For example, a curl command would look like: + +```bash +curl \ + -X GET \ + -H "Content-Type: application/json" \ + -H "x-cosmos-block-height: 123" \ + http://localhost:1317/cosmos/bank/v1beta1/balances/$MY_VALIDATOR_ADDRESS +``` + +Assuming the state at that block has not yet been pruned by the node, this query should return a non-empty response. + +### Cross-Origin Resource Sharing (CORS) + +[CORS policies](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) are not enabled by default to help with security. If you would like to use the rest-server in a public environment we recommend you provide a reverse proxy, this can be done with [nginx](https://www.nginx.com/). For testing and development purposes there is an `enabled-unsafe-cors` field inside [`app.toml`](../run-node/01-run-node.md#configuring-the-node-using-apptoml). diff --git a/versioned_docs/version-0.47/user/run-node/03-txs.md b/versioned_docs/version-0.47/user/run-node/03-txs.md new file mode 100644 index 000000000..c8d2b610b --- /dev/null +++ b/versioned_docs/version-0.47/user/run-node/03-txs.md @@ -0,0 +1,387 @@ +--- +sidebar_position: 1 +--- + +# Generating, Signing and Broadcasting Transactions + +:::note Synopsis +This document describes how to generate an (unsigned) transaction, signing it (with one or multiple keys), and broadcasting it to the network. +::: + +## Using the CLI + +The easiest way to send transactions is using the CLI, as we have seen in the previous page when [interacting with a node](./02-interact-node.md#using-the-cli). For example, running the following command + +```bash +simd tx bank send $MY_VALIDATOR_ADDRESS $RECIPIENT 1000stake --chain-id my-test-chain --keyring-backend test +``` + +will run the following steps: + +* generate a transaction with one `Msg` (`x/bank`'s `MsgSend`), and print the generated transaction to the console. +* ask the user for confirmation to send the transaction from the `$MY_VALIDATOR_ADDRESS` account. +* fetch `$MY_VALIDATOR_ADDRESS` from the keyring. This is possible because we have [set up the CLI's keyring](./00-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 CometBFT RPC endpoint. + +The CLI bundles all the necessary steps into a simple-to-use user experience. However, it's possible to run all the steps individually too. + +### Generating a Transaction + +Generating a transaction can simply be done by appending the `--generate-only` flag on any `tx` command, e.g.: + +```bash +simd tx bank send $MY_VALIDATOR_ADDRESS $RECIPIENT 1000stake --chain-id my-test-chain --generate-only +``` + +This will output the unsigned transaction as JSON in the console. We can also save the unsigned transaction to a file (to be passed around between signers more easily) by appending `> unsigned_tx.json` to the above command. + +### Signing a Transaction + +Signing a transaction using the CLI requires the unsigned transaction to be saved in a file. Let's assume the unsigned transaction is in a file called `unsigned_tx.json` in the current directory (see previous paragraph on how to do that). Then, simply run the following command: + +```bash +simd tx sign unsigned_tx.json --chain-id my-test-chain --keyring-backend test --from $MY_VALIDATOR_ADDRESS +``` + +This command will decode the unsigned transaction and sign it with `SIGN_MODE_DIRECT` with `$MY_VALIDATOR_ADDRESS`'s key, which we already set up in the keyring. The signed transaction will be output as JSON to the console, and, as above, we can save it to a file by appending `--output-document signed_tx.json`. + +Some useful flags to consider in the `tx sign` command: + +* `--sign-mode`: you may use `amino-json` to sign the transaction using `SIGN_MODE_LEGACY_AMINO_JSON`, +* `--offline`: sign in offline mode. This means that the `tx sign` command doesn't connect to the node to retrieve the signer's account number and sequence, both needed for signing. In this case, you must manually supply the `--account-number` and `--sequence` flags. This is useful for offline signing, i.e. signing in a secure environment which doesn't have access to the internet. + +#### Signing with Multiple Signers + +:::warning +Please note that signing a transaction with multiple signers or with a multisig account, where at least one signer uses `SIGN_MODE_DIRECT`, is not yet possible. You may follow [this Github issue](https://github.com/cosmos/cosmos-sdk/issues/8141) for more info. +::: + +Signing with multiple signers is done with the `tx multisign` command. This command assumes that all signers use `SIGN_MODE_LEGACY_AMINO_JSON`. The flow is similar to the `tx sign` command flow, but instead of signing an unsigned transaction file, each signer signs the file signed by previous signer(s). The `tx multisign` command will append signatures to the existing transactions. It is important that signers sign the transaction **in the same order** as given by the transaction, which is retrievable using the `GetSigners()` method. + +For example, starting with the `unsigned_tx.json`, and assuming the transaction has 4 signers, we would run: + +```bash +# Let signer1 sign the unsigned tx. +simd tx multisign unsigned_tx.json signer_key_1 --chain-id my-test-chain --keyring-backend test > partial_tx_1.json +# Now signer1 will send the partial_tx_1.json to the signer2. +# Signer2 appends their signature: +simd tx multisign partial_tx_1.json signer_key_2 --chain-id my-test-chain --keyring-backend test > partial_tx_2.json +# Signer2 sends the partial_tx_2.json file to signer3, and signer3 can append his signature: +simd tx multisign partial_tx_2.json signer_key_3 --chain-id my-test-chain --keyring-backend test > partial_tx_3.json +``` + +### Broadcasting a Transaction + +Broadcasting a transaction is done using the following command: + +```bash +simd tx broadcast tx_signed.json +``` + +You may optionally pass the `--broadcast-mode` flag to specify which response to receive from the node: + +* `sync`: the CLI waits for a CheckTx execution response only. +* `async`: the CLI returns immediately (transaction might fail). + +### 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. + +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. + +### Decoding a Transaction + +The CLI can also be used to decode transaction bytes. + +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. + +## Programmatically with Go + +It is possible to manipulate transactions programmatically via Go using the Cosmos SDK's `TxBuilder` interface. + +### Generating a Transaction + +Before generating a transaction, a new instance of a `TxBuilder` needs to be created. Since the 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. + +```go +import ( + "github.com/cosmos/cosmos-sdk/simapp" +) + +func sendTx() error { + // Choose your codec: Amino or Protobuf. Here, we use Protobuf, given by the following function. + app := simapp.NewSimApp(...) + + // Create a new TxBuilder. + txBuilder := app.TxConfig().NewTxBuilder() + + // --snip-- +} +``` + +We can also set up some keys and addresses that will send and receive the transactions. Here, for the purpose of the tutorial, we will be using some dummy data to create keys. + +```go +import ( + "github.com/cosmos/cosmos-sdk/testutil/testdata" +) + +priv1, _, addr1 := testdata.KeyTestPubAddr() +priv2, _, addr2 := testdata.KeyTestPubAddr() +priv3, _, addr3 := testdata.KeyTestPubAddr() +``` + +Populating the `TxBuilder` can be done via its methods: + +```go reference +https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/client/tx_config.go#L33-L50 +``` + +```go +import ( + banktypes "github.com/cosmos/cosmos-sdk/x/bank/types" +) + +func sendTx() error { + // --snip-- + + // Define two x/bank MsgSend messages: + // - from addr1 to addr3, + // - from addr2 to addr3. + // This means that the transactions needs two signers: addr1 and addr2. + msg1 := banktypes.NewMsgSend(addr1, addr3, types.NewCoins(types.NewInt64Coin("atom", 12))) + msg2 := banktypes.NewMsgSend(addr2, addr3, types.NewCoins(types.NewInt64Coin("atom", 34))) + + err := txBuilder.SetMsgs(msg1, msg2) + if err != nil { + return err + } + + txBuilder.SetGasLimit(...) + txBuilder.SetFeeAmount(...) + txBuilder.SetMemo(...) + txBuilder.SetTimeoutHeight(...) +} +``` + +At this point, `TxBuilder`'s underlying transaction is ready to be signed. + +### Signing a Transaction + +We 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/main/docs/architecture/adr-020-protobuf-transaction-encoding.md), each signer needs to sign the `SignerInfo`s of all other signers. This means that we need to perform two steps sequentially: + +* for each signer, populate the signer's `SignerInfo` inside `TxBuilder`, +* once all `SignerInfo`s are populated, for each signer, sign the `SignDoc` (the payload to be signed). + +In the current `TxBuilder`'s API, both steps are done using the same method: `SetSignatures()`. The current API requires us to first perform a round of `SetSignatures()` _with empty signatures_, only to populate `SignerInfo`s, and a second round of `SetSignatures()` to actually sign the correct payload. + +```go +import ( + cryptotypes "github.com/cosmos/cosmos-sdk/crypto/types" + "github.com/cosmos/cosmos-sdk/types/tx/signing" + xauthsigning "github.com/cosmos/cosmos-sdk/x/auth/signing" +) + +func sendTx() error { + // --snip-- + + privs := []cryptotypes.PrivKey{priv1, priv2} + accNums:= []uint64{..., ...} // The accounts' account numbers + accSeqs:= []uint64{..., ...} // The accounts' sequence numbers + + // First round: we gather all the signer infos. We use the "set empty + // signature" hack to do that. + var sigsV2 []signing.SignatureV2 + for i, priv := range privs { + sigV2 := signing.SignatureV2{ + PubKey: priv.PubKey(), + Data: &signing.SingleSignatureData{ + SignMode: encCfg.TxConfig.SignModeHandler().DefaultMode(), + Signature: nil, + }, + Sequence: accSeqs[i], + } + + sigsV2 = append(sigsV2, sigV2) + } + err := txBuilder.SetSignatures(sigsV2...) + if err != nil { + return err + } + + // Second round: all signer infos are set, so each signer can sign. + sigsV2 = []signing.SignatureV2{} + for i, priv := range privs { + signerData := xauthsigning.SignerData{ + ChainID: chainID, + AccountNumber: accNums[i], + Sequence: accSeqs[i], + } + sigV2, err := tx.SignWithPrivKey( + encCfg.TxConfig.SignModeHandler().DefaultMode(), signerData, + txBuilder, priv, encCfg.TxConfig, accSeqs[i]) + if err != nil { + return nil, err + } + + sigsV2 = append(sigsV2, sigV2) + } + err = txBuilder.SetSignatures(sigsV2...) + if err != nil { + return err + } +} +``` + +The `TxBuilder` is now correctly populated. To print it, you can use the `TxConfig` interface from the initial encoding config `encCfg`: + +```go +func sendTx() error { + // --snip-- + + // Generated Protobuf-encoded bytes. + txBytes, err := encCfg.TxConfig.TxEncoder()(txBuilder.GetTx()) + if err != nil { + return err + } + + // Generate a JSON string. + txJSONBytes, err := encCfg.TxConfig.TxJSONEncoder()(txBuilder.GetTx()) + if err != nil { + return err + } + txJSON := string(txJSONBytes) +} +``` + +### Broadcasting a Transaction + +The preferred way to broadcast a transaction is to use gRPC, though using REST (via `gRPC-gateway`) or the CometBFT RPC is also posible. An overview of the differences between these methods is exposed [here](../core/06-grpc_rest.md). For this tutorial, we will only describe the gRPC method. + +```go +import ( + "context" + "fmt" + + "google.golang.org/grpc" + + "github.com/cosmos/cosmos-sdk/types/tx" +) + +func sendTx(ctx context.Context) error { + // --snip-- + + // Create a connection to the gRPC server. + grpcConn := grpc.Dial( + "127.0.0.1:9090", // Or your gRPC server address. + grpc.WithInsecure(), // The Cosmos SDK doesn't support any transport security mechanism. + ) + defer grpcConn.Close() + + // Broadcast the tx via gRPC. We create a new client for the Protobuf Tx + // service. + txClient := tx.NewServiceClient(grpcConn) + // We then call the BroadcastTx method on this client. + grpcRes, err := txClient.BroadcastTx( + ctx, + &tx.BroadcastTxRequest{ + Mode: tx.BroadcastMode_BROADCAST_MODE_SYNC, + TxBytes: txBytes, // Proto-binary of the signed transaction, see previous step. + }, + ) + if err != nil { + return err + } + + fmt.Println(grpcRes.TxResponse.Code) // Should be `0` if the tx is successful + + return nil +} +``` + +#### Simulating a Transaction + +Before broadcasting a transaction, we sometimes may want to dry-run the transaction, to estimate some information about the transaction without actually committing it. This is called simulating a transaction, and can be done as follows: + +```go +import ( + "context" + "fmt" + "testing" + + "github.com/cosmos/cosmos-sdk/client" + "github.com/cosmos/cosmos-sdk/types/tx" + authtx "github.com/cosmos/cosmos-sdk/x/auth/tx" +) + +func simulateTx() error { + // --snip-- + + // Simulate the tx via gRPC. We create a new client for the Protobuf Tx + // service. + txClient := tx.NewServiceClient(grpcConn) + txBytes := /* Fill in with your signed transaction bytes. */ + + // We then call the Simulate method on this client. + grpcRes, err := txClient.Simulate( + context.Background(), + &tx.SimulateRequest{ + TxBytes: txBytes, + }, + ) + if err != nil { + return err + } + + fmt.Println(grpcRes.GasInfo) // Prints estimated gas used. + + return nil +} +``` + +## 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. + +### 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: + +```bash +grpcurl -plaintext \ + -d '{"tx_bytes":"{{txBytes}}","mode":"BROADCAST_MODE_SYNC"}' \ + localhost:9090 \ + cosmos.tx.v1beta1.Service/BroadcastTx +``` + +## Using 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. + +### Broadcasting a Transaction + +Broadcasting a transaction using the REST endpoint (served by `gRPC-gateway`) can be done by sending a POST request as follows, where the `txBytes` are the protobuf-encoded bytes of a signed transaction: + +```bash +curl -X POST \ + -H "Content-Type: application/json" \ + -d'{"tx_bytes":"{{txBytes}}","mode":"BROADCAST_MODE_SYNC"}' \ + localhost:1317/cosmos/tx/v1beta1/txs +``` + +## Using CosmJS (JavaScript & TypeScript) + +CosmJS aims to build client libraries in JavaScript that can be embedded in web applications. Please see [https://cosmos.github.io/cosmjs](https://cosmos.github.io/cosmjs) for more information. As of January 2021, CosmJS documentation is still work in progress. diff --git a/versioned_docs/version-0.47/validate/05-run-testnet.md b/versioned_docs/version-0.47/user/run-node/05-run-testnet.md similarity index 92% rename from versioned_docs/version-0.47/validate/05-run-testnet.md rename to versioned_docs/version-0.47/user/run-node/05-run-testnet.md index e9a06ed34..c2b5da598 100644 --- a/versioned_docs/version-0.47/validate/05-run-testnet.md +++ b/versioned_docs/version-0.47/user/run-node/05-run-testnet.md @@ -8,7 +8,7 @@ sidebar_position: 1 The `simd testnet` subcommand makes it easy to initialize and start a simulated test network for testing purposes. ::: -In addition to the commands for [running a node](../user/run-node/01-run-node.md), 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. +In addition to the commands for [running a node](./01-run-node.md), 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. ## Initialize Files diff --git a/versioned_docs/version-0.47/user/run-node/06-run-production.md b/versioned_docs/version-0.47/user/run-node/06-run-production.md new file mode 100644 index 000000000..9af61725b --- /dev/null +++ b/versioned_docs/version-0.47/user/run-node/06-run-production.md @@ -0,0 +1,266 @@ +--- +sidebar_position: 1 +--- + +# Running in Production + +:::note Synopsis +This section describes how to securely run a node in a public setting and/or on a mainnet on one of the many Cosmos SDK public blockchains. +::: + +When operating a node, full node or validator, in production it is important to set your server up securely. + +:::note +There are many different ways to secure a server and your node, the described steps here is one way. To see another way of setting up a server see the [run in production tutorial](https://tutorials.cosmos.network/hands-on-exercise/5-run-in-prod/1-overview.html). +::: + +:::note +This walkthrough assumes the underlying operating system is Ubuntu. +::: + +## Sever Setup + +### User + +When creating a server most times it is created as user `root`. This user has heightened privileges on the server. When operating a node, it is recommended to not run your node as the root user. + +1. Create a new user + +```bash +sudo adduser change_me +``` + +2. We want to allow this user to perform sudo tasks + +```bash +sudo usermod -aG sudo change_me +``` + +Now when logging into the server, the non `root` user can be used. + +### Go + +1. Install the [Go](https://go.dev/doc/install) version preconized by the application. + +:::warning +In the past, validators [have had issues](https://github.com/cosmos/cosmos-sdk/issues/13976) when using different versions of Go. It is recommended that the whole validator set uses the version of Go that is preconized by the application. +::: + +### Firewall + +Nodes should not have all ports open to the public, this is a simple way to get DDOS'd. Secondly it is recommended by [CometBFT](github.com/cometbft/cometbft) to never expose ports that are not required to operate a node. + +When setting up a firewall there are a few ports that can be open when operating a Cosmos SDK node. There is the CometBFT json-RPC, prometheus, p2p, remote signer and Cosmos SDK GRPC and REST. If the node is being operated as a node that does not offer endpoints to be used for submission or querying then a max of three endpoints are needed. + +Most, if not all servers come equipped with [ufw](https://help.ubuntu.com/community/UFW). Ufw will be used in this tutorial. + +1. Reset UFW to disallow all incoming connections and allow outgoing + +```bash +sudo ufw default deny incoming +sudo ufw default allow outgoing +``` + +2. Lets make sure that port 22 (ssh) stays open. + +```bash +sudo ufw allow ssh +``` + +or + +```bash +sudo ufw allow 22 +``` +Both of the above commands are the same. + +3. Allow Port 26656 (cometbft p2p port). If the node has a modified p2p port then that port must be used here. + +```bash +sudo ufw allow 26656/tcp +``` + +4. Allow port 26660 (cometbft [prometheus](https://prometheus.io)). This acts as the applications monitoring port as well. + +```bash +sudo ufw allow 26660/tcp +``` + +5. IF the node which is being setup would like to expose CometBFTs jsonRPC and Cosmos SDK GRPC and REST then follow this step. (Optional) + +##### CometBFT JsonRPC + +```bash +sudo ufw allow 26657/tcp +``` + +##### Cosmos SDK GRPC + +```bash +sudo ufw allow 9090/tcp +``` + +##### Cosmos SDK REST + +```bash +sudo ufw allow 1317/tcp +``` + +6. Lastly, enable ufw + +```bash +sudo ufw enable +``` + +### Signing + +If the node that is being started is a validator there are multiple ways a validator could sign blocks. + +#### File + +File based signing is the simplest and default approach. This approach works by storing the consensus key, generated on initialization, to sign blocks. This approach is only as safe as your server setup as if the server is compromised so is your key. This key is located in the `config/priv_val_key.json` directory generated on initialization. + +A second file exists that user must be aware of, the file is located in the data directory `data/priv_val_state.json`. This file protects your node from double signing. It keeps track of the consensus keys last sign height, round and latest signature. If the node crashes and needs to be recovered this file must be kept in order to ensure that the consensus key will not be used for signing a block that was previously signed. + +#### Remote Signer + +A remote signer is a secondary server that is separate from the running node that signs blocks with the consensus key. This means that the consensus key does not live on the node itself. This increases security because your full node which is connected to the remote signer can be swapped without missing blocks. + +The two most used remote signers are [tmkms](https://github.com/iqlusioninc/tmkms) from [Iqlusion](https://www.iqlusion.io) and [horcrux](https://github.com/strangelove-ventures/horcrux) from [Strangelove](https://strange.love). + +##### TMKMS + +###### Dependencies + +1. Update server dependencies and install extras needed. + +```sh +sudo apt update -y && sudo apt install build-essential curl jq -y +``` + +2. Install Rust: + +```sh +curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh +``` + +3. Install Libusb: + +```sh +sudo apt install libusb-1.0-0-dev +``` + +###### Setup + +There are two ways to install tmkms, from source or `cargo install`. In the examples we will cover downloading or building from source and using softsign. Softsign stands for software signing, but you could use a [yubihsm](https://www.yubico.com/products/hardware-security-module/) as your signing key if you wish. + +1. Build: + +From source: + +```bash +cd $HOME +git clone https://github.com/iqlusioninc/tmkms.git +cd $HOME/tmkms +cargo install tmkms --features=softsign +tmkms init config +tmkms softsign keygen ./config/secrets/secret_connection_key +``` +or + +Cargo install: + +```bash +cargo install tmkms --features=softsign +tmkms init config +tmkms softsign keygen ./config/secrets/secret_connection_key +``` + +:::note +To use tmkms with a yubikey install the binary with `--features=yubihsm`. +::: + +2. Migrate the validator key from the full node to the new tmkms instance. + +```bash +scp user@123.456.32.123:~/.simd/config/priv_validator_key.json ~/tmkms/config/secrets +``` + +3. Import the validator key into tmkms. + +```bash +tmkms softsign import $HOME/tmkms/config/secrets/priv_validator_key.json $HOME/tmkms/config/secrets/priv_validator_key +``` + +At this point, it is necessary to delete the `priv_validator_key.json` from the validator node and the tmkms node. Since the key has been imported into tmkms (above) it is no longer necessary on the nodes. The key can be safely stored offline. + +4. Modifiy the `tmkms.toml`. + +```bash +vim $HOME/tmkms/config/tmkms.toml +``` + +This example shows a configuration that could be used for soft signing. The example has an IP of `123.456.12.345` with a port of `26659` a chain_id of `test-chain-waSDSe`. These are items that most be modified for the usecase of tmkms and the network. + +```toml +# CometBFT KMS configuration file + +## Chain Configuration + +[[chain]] +id = "osmosis-1" +key_format = { type = "bech32", account_key_prefix = "cosmospub", consensus_key_prefix = "cosmosvalconspub" } +state_file = "/root/tmkms/config/state/priv_validator_state.json" + +## Signing Provider Configuration + +### Software-based Signer Configuration + +[[providers.softsign]] +chain_ids = ["test-chain-waSDSe"] +key_type = "consensus" +path = "/root/tmkms/config/secrets/priv_validator_key" + +## Validator Configuration + +[[validator]] +chain_id = "test-chain-waSDSe" +addr = "tcp://123.456.12.345:26659" +secret_key = "/root/tmkms/config/secrets/secret_connection_key" +protocol_version = "v0.34" +reconnect = true +``` + +5. Set the address of the tmkms instance. + +```bash +vim $HOME/.simd/config/config.toml + +priv_validator_laddr = "tcp://0.0.0.0:26659" +``` + +:::tip +The above address it set to `0.0.0.0` but it is recommended to set the tmkms server to secure the startup +::: + +:::tip +It is recommended to comment or delete the lines that specify the path of the validator key and validator: + +```toml +# Path to the JSON file containing the private key to use as a validator in the consensus protocol +# priv_validator_key_file = "config/priv_validator_key.json" + +# Path to the JSON file containing the last sign state of a validator +# priv_validator_state_file = "data/priv_validator_state.json" +``` +::: + +6. Start the two processes. + +```bash +tmkms start -c $HOME/tmkms/config/tmkms.toml +``` + +```bash +simd start +``` diff --git a/versioned_docs/version-0.47/user/run-node/_category_.json b/versioned_docs/version-0.47/user/run-node/_category_.json new file mode 100644 index 000000000..375a7c423 --- /dev/null +++ b/versioned_docs/version-0.47/user/run-node/_category_.json @@ -0,0 +1,5 @@ +{ + "label": "Running a Node, API and CLI", + "position": 5, + "link": null +} \ No newline at end of file

!kU*Fa3_Exo-%jYIq;`x&AV&jt7poI}Pw&O2{_)9g zEDD^Vp>Ov=9zU%y5c`qvlxLl}Tzc>-+abEs-dQen)32%%&D(iJ^+2klB9hG2dC|kl zfkSJ3%)t$*!z$R{2t4F{foB0x!Cr(J#G?Fp6Yt_zW(~Q-A%tuA{jxL52ehv z4@P4bK^GiR9SQgtjv=kf5v+JL3vkq`2zMUe!d^!)Ge#v{hp5ANGfkWR3 zt+3@v6MqyMz?7@u^a4^B^EG(vs!Nj%F>g*0#9VttWsc3a-g4SJUBW$gbvBlBh4aO` zR{E{beYR`O&3nR2l4o>Plje1wFqf}~1-`XN(;#@UpaA|jh=E)6HE9+om<04AUEM+t-JgRPFz^k}Nzn+O;sQ(1?qlO#)~{|s78dgNyMEX$ zP965_-#}7rs8xT4jVuTlNmTYMU#kglmA}MHd;Zh_?kxX>LicFA%7#LW+Of?l4-(WU zf?cT+n>3Z{wHWBe`=-V)hUT!Cvbn|QWYk8Rg50X&<~ZfaeSOkMJe}8XX&=`S`6K;# zb)Dimlc8iT*LHA1b6w*`kMqF-2>tYf-Bm*;SnngU`0|;TMIfz1aMg1?-p2pN@WJAO z%ec0`{!HQT*=XpA<{ntKKHkMgXJ2~6<*nC#i8F)^JV!ks~$39aB{m92p@#WRce?lO}jn0E1$6sxk{#p*xj!-TPF?sL5?omYRs@e%qr;`>n9wO9gk_ zR{KZ=NJ2cS;LW9#mwer1Oc6Xdw7w`9dmtP|+2eh1ZKF+18CI|`o_D@d z^)<)m*5tspK$WM0dwxov8&1Xi;;rF&xM3St$78?7} zrY11>LvPoyiOegm72+d9OSp7Y*Q(|zP{Nyxkq7=At1+^iIY zF1KHOj;MOnIZi;gOavl-DKB)2=$23ZM!7I3NLIqLi{q}s;}(fP-*Z~;V!JzR>3j%V zm_M*xqCDHp7EK3B_5*yz&2EYz9sweq$dCmw<`AKds0(ZT%xz6}ObH6O{MLIy0GSXU zaHl2Y>$4AKy$`@xvEu#ap@gxSh}R7d!e3HS0f333HA@qxIB7)AQOMBPhLke>P~^l? z%;3L>NlHE4r(ezKR_&ZA8Z|S~Q1zI#{)w8|H_P$TXum}z(EZe9nVuk!Tj94g^kyV( zW3R%+#O98v%-g2kC++pKOAqFlp>4oUFlr>`a$t2zXXk`u&n_!&eNLy01?yUstL`iM zR^nDoJN#-dSRx3Sb)(i@m{>DYG7~u@cAduxBD1DeZ|KpT0D$ay+XB~22rSmu0$H@k zV0931GGvR1jdI}t3QuX?0UHHt+_uFN&VJmwx zse%S1(LGA#j<$!>ar8rNCj18_xhb!|B&1Wby~SH<%R)opC`WHfs{;0tl*_o*v13Sv zL%UP`A{yh8D}(KLSamJvls=;ZbR7pEa#x{l$FwUy<`0i}kGFyFlYlTXfeNLsVon|JfvCuxkXnGh{sQ;XE* z$k&IWPNxfL*JN(T?oWK+B0d>$wvv5H^Uc9PFi@0&@;?w0V_?#>w_qz^h)Mzn2kkfc z*a{#VD)m?BK;k||S;hvGgezn?60+IxT7;A&F~PwekZ-jlzFszI%gmF*1m<)#hwI{%zG52{mHDFKAY$qmt&uBXS!X_!i56#~)*$Z1dWyDiruf!ip-3$Kp#f#|Re^C?JZkmhs%D2_f1|S`^ zV<>+t|DM-@s%;bJT*!9#0Y%v=;1wl$1O{JhT_hqWi9rOCTk59Ae?&kIv^PKPVIJ;G z-w$c3mDYWjspJUd#byFHfw>qR-Et7P=Q_oG2=W%P#Y})k=yC@L5!R1|IqE?1ZW@05 z7V!IVcgA8o^6791gh}Kr$DSa#pjYd|E!mE3aIcd>1sXe8J%?A1pI{K~p+J*phDk!G zRo?>>z@zWhe}G^wm0EDvLo|FqXMVSu!VdrM6PW($cwL2_(<8+LuCnLN7J1Km1odUb z-CuQ2TWc0aMg(_(m*C}%y%9%2J2L$f+Oi$e;9sOlVZ|6l%InVN0smqKtV*L;mycp}dbkno}Gw+5JTC)ZbnH2(f3b?IE&$1tv!N^tChr+C8ji zzK)%bOg+y60^@Epe9ufJB_-#l_HU5OZ<_}DF$Ql;4*~-1P%@eZT^vN69jbVRSrEeh zUty6ol7d9$IFF@hBW^9tTstQT6x(r1F)%dqpOHM;64$UuQ$%Ut z0(Gn-2#@df6v5Nq1gvx7CVpg|7Pd9{Q+z^y5GD+W#ZNjvGVrZf-I3>Om7rW*M$`!(ej^A1U3Goi4(C%kAAq`*{RI(z3~Ldh15GfIk55V z0HUbVYoa7EXD_JJ`^iQC0<7qYd;0_q7d{ETmV`mc^8gjOE{P1TN0Er%U6OXxd*%TR zI#e-%gB6~<4w*{ZPndVx)nLdgp~GMI--&cb>AWyW06U;q$yD>PY5_P`NVQpVWz>=w zp?1O-!Avd%%b+uAnvMlfQk)D71IgMFspIG447>1lkx`@gK{`oRa|3FfA}lAVDMCyZx6_XEdM{r*3`@(@n%(ezjen zOtuHvo_y_M8sagXYa1z;kZI!W=p&;}+dbH#&3u$vsW5!WwR7Q9V{kvTQ<3Bql_U8F z>$&O6rs_AMM)=SoFF{94_W@rO`1tujQtX&pL{h*}O8fH(Fs%$_FfF63O;yw!MFGSJ zk`KEdE&W{|g%gO#Y<2}P8Y(4vTj(j0fc0XNGewlC{;6bV3h%JDC zHx2rC0LRtosr^NEqJgp!Q<=Z)}L|Z)^xa zUUl>zWXcX70{Wxbp?{r5Hz=%AuL3xF$`PIWSkO9&ZWbuoT4@B*R5|h6g)c+vISws49RPf@ z(EdJJ74_&KKL=#gBt7$AJn`H`bfaUnOP{PX_#*1^H)SbBvdbL(-pLKcpy48|oY8Qzq;+y@+~`WJZLb^yBV@IkB`RyP&w zXm@PwW00kQNr8Z{Fr%8ow%myX8Xm8Nx++Kp{hN?Wxc3;)J=2E018OH+#KDJy_l3m@ zk*;Zb8*3Pt&ummJPfYh?3^yGvcuo!w-83{bx(?f{&HJpa73koA5sCg0pt@xiFqP-= zIzS+R4=DXP;-c=M4U`-aY~KZmUv<8lBzJt_n|CWens{-#VCV+xlVfpB5q=d&D7ci; z@&@8pH?O+-~w;>3Ap5l3$RN>urnB@AzLPcBRpYmK%C1%Zyd*q}zDQWs{E4vOGqI}*UKvhuS#rvIN;N|Iw5 zHGATM?&Y!oAps4CLZcsY(kaAJG`OzZby{q(y`~^1PYWaTC7yzdm1#B;M|!UNFHzcfVn^bVSCjNxaSS6+)g3VzXAU)1aWj*A2}u2hnq$A6!; zoPrT}_L5V#Qa_qf#Pi4Dd!C4>s6WbhX`eA0(j;HJpuzq%5~o?9lRDRh{EKL;Qg5PVY7xST!(=Ds_Cdy1m)I~M0-(Zu1P5BU{Vp8(}O@O$;hXjeSLb~Hy3cbE{fhY`5#38v$Uo}zh_$?f>tWA!;~UV!>;~d zeajb941Oo-eoS$BG{vBj&fTAoV}oK@e4rKl2-?CxwBzrrb)&jEJHKt$4!;Hxc3BEt zt7t?v>^_;c(D4gA-p`oc@4&DV4*BZ-eG&0;*3VZV;bvbhg-RY=93_0{H+*%AwYPlM zvm;fb(tf0hgeVsx+c5-4(CKc)4-`G3NK!s{@+WA%ofp{J^qLL`GBotB&;8-;9LAcH z)98)QFzJ?^z@B*#PyM?*bbFkyd~wOmzjXvQTvT+z{<)|3S}=Ch9AVxQzN=3|{st`M zvKs2PvG02StSa3Lg%9)NB>Nk^Uu)q8>TfXhLT{yLO;s3D8}gUeKb6In0b?-+W80xC zcl~#4G*qv~RMs4;TNVS1y3Lo}I$$U;sztTzdBNMQ}Bu{p#m zOqvLh{WT;+XsJN;xeeTURYpfF@Tp;H^uo0@7gC6Iutfr=lxB$J*+iZKAF>+3{qIq z#ge%zlR0@nW2t&FJ52NXkbag)#C{NP#V&6wOTit>g|>@`wScas-0##<%Iln$pT8#X zOXb)ZGg1PxfCDae*1~+YE>ZsA$T>ubU7;8_<~<;xC==XQ>e>o~?~+p09rh_UP1vCKs zSbS&(v)VebVa1W_2)I+#5fE;b5}D`CHi*zUg*mu4K;YZEg(wleJa@%tX$UKAeES&a zNg8wR@$vMq+rPdGFCsjc(AuTXVH074RsPLW0~Op(!&$d)?+PgI&b}2B6@8PJY=YPJ z>Wq5w3b%fHVGE*iP%2wp4?rvM{KE2`ay}(B3#B@MJ z^;N3uspxdkZ@p9pYpdos$Z60E)%09312@+sa&55c=tNgevY@c28<6{zMz{-sOS$Wn z9m*gy%@!)dd4-ww??C_AT<}z0Ogrk7u~KpSQ{HLFG2ahUX$^m3z~_KCBD=pf3CpR~ z2G)d~sdr!o$j+Sr>WYCNWc_n?csM)4}~Lmi#o2_$;6P$Qky5GOHQ46 z8foIN81%l_vFB(5f2(OKK4I1v3|^&KCJ0LW-rDA*1ZVbfHrHn(zkaT(X$o7Ma#XZ~ znu{Xt7J+KCYkeh;#V^2{>uyeGq&x<;j4Z0GGzacnO0sL@dhgGLUI$m1x9;*FPee=0 zx`+~ps#m?gX26^2DTMIT46e3+xIR>UB|mZVe5_+T<Qwq>r} ze$u*jm-KS90P^6-JAX#=hRMp1{P9$g!y8{84BTP&tCsF$8x~cAAhZo~{r#C0AiN24OC zftbO4Bz}NeU+hyc-vv2((b^M%_bVji^Rr~$G8qoC{fY8bI zZlDxLcI;&IWc@$r{*@*H2XWi%Q0w-GO6-RLytIp(YjboHv5@u4!0_CE$q)yk8vsG7 z%i~XN8Pnt))lLLjYd;zRgf`2I_6NhXsCCZnYzxd9b{zpDYj5MXNhr zp^TKfpWRs>_$9_sjiodM#aJj(o1rE=&xY21P=76tkKIWy&jCiAl+) zXgDkj%t}Owk=v<7H&eSM7Jiao1O!eDc>A&Q)bS40b*L!2r}3!~x7 z5%AJ;PeG-Ms(JUh1rJ9dU1@C@E{sdMgQ?sTIB>Pxk#_+>BV z;Zn}!cl&jG$j`1{Y9YsLeDp0%ucuiJ)Pqwm^!L`Hz8bRZIGJAauC zRHMGBO_H>mNf?)NvhV}SqSoUNdwt>Bl!NnTlj9wvOb_POraM)tocn0de;+7E?T=!s-j*-VyIiOm*gY zYUHnt+;LtudZE_ogIG9c(z%DzvO1~dmr#at0<^T6@5FM+*Gc-1HMA&>cq1rNP2|4Npw(L&+-^a?}d0dPUWS<6j>1hYM~EP(Qia-lymD zsw0}98lZ4U7c+6iwW_Cz-zvwMPExU zt2yH{@)3A-(^6G1PXZpbq@=;&8j?^t29W0?zy!>TjIaur(aep&AX`gmL2S(j$~aioyj+F70KH8#Y2nMsYE zAa>V<7f8$=3Sl0HXkb0D|7^k%?A@~@F1#Mc$Cr@~T>xF= zZvZr3sAwPeKhZNEGmqQ{>zhJOoZmpp36mVpzif0C)hG6JkdD(LBn|=qj38avQY>~@&(~O-L z&lB?U@|refjnAmD_q>nZaS>EMfK2Q2`U)e;-~{!eKWP3(H$Wn`B%NF;KkA$Dp~U4! z;2TD=e8A<>76*laR{*><)%vv8bB(LRB_)OnI_z@m$|3-2op7mNOvH}<$XQPEQr8)z zQv47pksLY(jF8Cr8aV5nMLKH{gimRF~rJHPJTDjdKU`I|tZd_SVZHdpZV z&1s)}l6?FzpZ9G$^d}#y*vRo&24Izl7?y8)Qtuic(f}UQ)cM#jajuZaYmDBWcndVm z`P_!gNp9HOIKVgDE1I!owu>u=1ap+iF*Ejv#jfGFjLIFiGQf7xBh$USwMpPC8y~q_ z$>4yV3mfHzo>o4z~ic$G-$Lhc|@CPeqWMdKts=tlr0`}_j>@`t4>6QPWt|De<;z^U@52)|$@lQ6!9@)fn6#92G zO;6H&^jZtzQO>aH+N4n{0gox7uP)PMJe_Mxpb6DnC_;H|5Z%xLuqFV3jeUTsa!aOt zIQ;D7=YZ3^$y&}VVqzKUhKn*iM3KfCF{-bBI&SAt_;lXOZ>$BcCzDS!q|$+E_^}nt zxG|uP_Y@miz3$1IXlk&I-p!(kiHW62^QHsLteu67_|Xl=js2j)hVMK|-gyf}a4hrq z1==X=s^-nqSSx){W)w@HKJ;H4FEHYE0a;lj*y<0TY6KX$}X`z zYW$of*cVm*-I>^|^vNjp2riF|UD2a{n@WDurqluagI+@ggq-rz2A-IIvhCe?41=;K z=Ma=5T5`JRG+KTg*r`rM8OY;}AnZ|TUBu1&NKrVQTn=_h-=4^sAsQ#YFU^U;9k~O^ zQ2Gk!wGMT=U*b}Qd$wM{XDD_u*n1+%KE%YUn6UJtuj@hzY<>G5e`?Ct23`+eJj}qY zb=cZT3G4!nDG-zrJ+U=PNFatnpgE_O19pC-A}jqJ!{V7WfyPSX`3?X&?*1&DXbCU% z6n@m}p$q@Zvv;;bqrnPA;7=RQF?*CHItBjV_v}USxeBhY=)on)3I$mS3HLF){dch6 z$rR-stk~av^K18^3XwD}Di9V_>{lK%3|Aj1mbD|$rg$YaGg`=s1OzEap)Dft&s$~h5>j*8w;FZfZ)8KC1KJ6q2yF-S4Fg6+i_`;J zF_iD#gBWlrv{z~NJ~QhD4}v0(Qt{50tr2b=Ec+Vv3RTKANT zN4V^x)YF$cE?(U2CHZikIo@mJr-ndyj%(!xNlO(xc4rkdIRC-M8HiCCFma5W8(msP zo1VSkDg1bWa%{c}YNj<2CzgdQ$a>Po)Q5a?S4w}^#=I5IJy#q#e=cEmu1u?x{qQ#AIi)#!I0FOl4~MnznGFBodb+(Hc?d zY{9wV5Q#SN=iVX5kqmMH;#KH8032RN>f4mT}mJBRjq9GZN+h z2z1pVrMTAKdYil9$PO_hq>E&KXP-*&@W^CU$7aqm!B)3O3|7&WtEO8Z8z$7Y;T|-N zFJy^8pd5W?1JixsmzTc?96iRquOxtbG!X|9ILKpMJcg9Z?p z)3!$}jK>o!1N}>_M!RUq=}VfrOwFZjDt!|BTW><>L_u7a@zT&dvuJFUu!+STElGGMXwWZ%>$8sU)**K7QC+%W9=^&A77`Y|v=vJTT=0bY^gT~Ln)zYZJ@7j@!0Wkz*)u!41AkKPR-W zcnhr`G3Cd3+ER=SzxPpnqpv|@cEmT%OUiRfElJ%C0Rc@QtT3kyMh*@<@ll%+K-VbzIkJ&|3oUL ztMH`wvWx&4@70-or(xrDthb%=%D~j`F*pD?Q?~HdV2JY%m82K2BA`QcpzpOI{+$~m ztkk}*?f&23J|KR1RCw-7t9-~vMX&GqdS@AXe1vvyM(PfIz|p2O)m;8>B&0;C(YTe` zS4>a(t0r)jC1Yl8PP=LP3oeMWIH;+)M|ghnbP-DFeBCAcY1m@Vq-oDSfiS^M5e=&h V%Q37BX&ZQ)H9u!o^0!;e{{f1NA8Y^s literal 0 HcmV?d00001 diff --git a/versioned_docs/version-0.46/develop/advanced-concepts/baseapp_state-processproposal.png b/versioned_docs/version-0.47/develop/advanced-concepts/baseapp_state-processproposal.png similarity index 100% rename from versioned_docs/version-0.46/develop/advanced-concepts/baseapp_state-processproposal.png rename to versioned_docs/version-0.47/develop/advanced-concepts/baseapp_state-processproposal.png diff --git a/versioned_docs/version-0.47/develop/advanced-concepts/baseapp_state.png b/versioned_docs/version-0.47/develop/advanced-concepts/baseapp_state.png new file mode 100644 index 0000000000000000000000000000000000000000..5cf54fdb4afa95f4d57ffd6479b2aede91d5b10d GIT binary patch literal 338941 zcmYhjNzU_3vmN*s3>bwA*ki-+us*;w@DKLQkd4^)Jvq4`DRyGtH#_h`JgueFKD-Mj z-|reQ9!ZZxkx4Q$GUCLEllt$LA^wMd`Op9IkAM8*KgbgA{No@0?l18CAOH8i2V2(v zM-sum|7&$b_8|Nme9=Rf}4fBa9|C))a}Y`Wqff1%vp@BTuddR(`^Q2s9jNvG+b z-zKe=v|s-@6dTwCzVF9xQ#Qr-?|l#mLH`>B|2Gu!VC*lHfeG+}6aOSBDEWK;v?_*w zYY_h@1RD6SdYU)GHm>zwC<{Kz!&Y?QKiCXjO&7dG;0Z(j3giDu{=eWYGfiC)7Ma?B zYY=dh{3l9)&Hq)EJYD+>;lTT@X$$aAEb?}I58>)%?7gDQ9N#+}moE*|KpAIHP%g z&W3(S>5o-buZmgNY2z0NpFZM%p03!2Hmv!EmjY4aO>!0resKv7yoDCkXgnGW(;a&lV1 zH#f>4L_r@k_`(ox^(Zmioh{!2y(VZ$X}&v=uHI_YSK4IoK>$ziKoa%v;$flhThPJ5 zOerq33C37J&kP-�DEBy3G%(EP#m!cyW~)nTBt}?{jxWD`;@=?yy582=}#wS|={w z4d4kL5!vz9_M<5id?3m9N{;r&lzahBC_E`I&`ur}I9WkTlOMB)Dy%p{>|DdhWH=e7f4)%SznAgn+t9)IQX|TQIkDhtZ@GC0Hu6S(Tp6Xj-y@$K%xB?| zlOYEGxk!9yQpV)NgR_zKwv#e{m>@j}Kl0GU8Wb*-gHvS8~6?|Y@i`}gpRxD=Y$rB6!YoI^yh0PD(wdFm9W?_@KJ{l@tACF;oCxXPphj5fRR>-KQlXlu{KgOO$vOowGk zVm^+aV8p%-z-ey_dzu;O~@$HN9 z7!i%)rP9JEXR#6iee_c$4b7NWh_2ABlMbR_G>jKl<{=7YIomC>d~M#jiq-RNFfa@~ zKqs^K#|M`@?BVyl-KRW5IBvts+x*0A%*_F(drv8Q$OlW9Ah<3_yWCYL+~%N(9PzSj zAI_@X-G_*f(;+2hoj+ng^_TeCb0XUEJ3vf_q~HVxuG{+=uJS$37ZJgzE7soj(K!`^ zG&R7fbvhm_m-V+wJY?_<{?#*4d2(l1_CjS`?^+UJT>kLfzS9#$7 z-PHpwTMLDXrFg`0P;QsMz9X{pj-hs)TP2^->?Z`wa&{xWU7v}8XyMO#={;t&3QET& zYL+wZW;doTbkE1S_e>|bd%4y{0do@yO-d8&7x7PG^5C<;^W+6Z$x*pajVXMEncwN< z9hzSzEp7yA@}`Iu%KWlSNXhWr>Dtfd__i)*8kMJK{0h4dRfBq$4jG0KgHY2F$0P(} zOKwkwB;RTN#GZO_E4!aUOctNlKL#1+JBSnqQ_g~LAh6D(5XHhe6Nw>IxY-k*CU;Ga zkT$n0@cx2YR;pxydCO94b&BDcTnN(a_tvPO^G4Zac51FqDhkmD;Y>>lKO#X!7;c8EnL88SUtHQT-iY<8HGz{1u=f=kv$`9siq!Q{N$^8;{N`fllOV(6Fj~o^MR`PcPwu zFZVsdV}*8<>FGK(sm}$j*UMzB<4=|DCurICy6euK=w}E(BSG#*t}p-|qvWyi969eE zp$k26$VuwS+_Jq!tanFh{o)@jPdhC5glzDwx|mpt!TWjsYc!5j5F2iOe#oS1+Sabj z?v#VWN!4sXT~zs$%WFTVhWH;uHfN(_x7$TDVZ}f9V9T7Q=ymTb>n5Xf;(l1-{^&&r z(m2|b7<2HI^`FvUKs(WScEkt6Zg%is8#rWWckUNW3PT}m;b0b5ChdNaj}#UTbDbng zO9aqyIZI?5oC(LJ79=g7wrhx+ZI?~sa-yIE5$SBAp_XPzAj|7H}WYg zkNM^|wh{P5NO{XDo2_v2u6*kW*;^D76nFc#B^nq9-dfy!Fie%GWG;)8r03IG2Uxff z6_x%d4BCV6yk1)oidg%_MfU0P8Oy40?hFew1HP!gzlSSi)A_a^utkSH-QF8MW|j*d zjZ;4uTr?ih&<)f&lCPHIs7bO;XD#mMYnt#tsUK){Doq%mG+^rc66KCKDiRpw}Wb{u0gm#Jtt=}64E zp5@I!DT?14b0~oJ*^I8K+dTxwt`NCfW=mDnZqp~E>baY5m}bQ* zkZdnXav94OyHBB2wTJ0MDLzfa_jctx|*?Z^Vw|j8Guo_#@Ni!#kc&wM|bsem=9v{ z#_}1Z9jyfdg)7cYJ|6S=?a%jFJzH=D5OD@hI#9mCxXCLHo>J2f5`Qh@ahnDbUES^k zQld(}XNtK+HKqZMnbqLvb(;fX%+c!o)Lb|9gUvZ5%fQXB=r;7MBY5FTZXk*C*q+6R zcD6_8c6qfsb@5w(fbwcmZEUBe#%cDC;*Yt73 zH2ZimC)NEyhJr1-_}#ZD)&0OPVmmT62_OQx4XDr;zU=u_q3^O%a-ZR`-+_2_o}C|D zxCp85C!6%}n{NSTEY{(>qOOJMyma#huoSjXDOGL>Z&vOCwj$S5dXG}JYt5coo>z6; z^rd$j>*;S*fzoA*x+j(Zikwcr4``ie)6V~3s_UM^Xt8EJcNrMSIJ%H1wW7l|H_`}6Ha5PX1uI$V#b-}N3b78x9H?rcL)0vXDBg@ zB^aFlbleHJh>KzPNpXetV97*b9fE*)vr{odbjF1c!^ar?j*@9yKZ{rloSv;TBLo#Q zP16z@n18xH;#_f$W51Wru5}4c&s<`LK4v)WMS??;IHHnsmcEaZXwlQ_t(34Nyl&8C zN=Y{_R#j+KM<9p+$qpMqN6K1M*#<}Tb<(; zJ5;bUeC`$U7@okzo7L;xx(VEG_H2-dDfBXgd1H!O?$m)`Z`L{Rh7d1at@d^yXoqMr zsceX9d6NBDy#rMOzx;Ym8_YcC?OxF~00IEL3|?e9;J(+2v5VSBrHD5Q;_&yrow(X? z7ztL@3eCm;JuDMr4bq6jSVi({Fq zQbE@IdNXsl0kTWGJ`qIfG(@hc{IOrSieVbadf6zyb}7e`M?*+LOyB#rM0ouVo{2MR?vA65Q!5Pbf=b5xY5<6)< zp3L<`;JRnK$v5~Rr1+*mI9MvKFITnw2Zb!*rzXr{_xzNk zRDihH+Wba-B}O)A@CW1W_WeZ_G6+uEAOt*R#Z9Dq`A!}QHtoG*l2jDb26b1XoShHxzR1lIVkD zW;_eUa}H&A!N^7ARHGf-M*HIDI8dzEwCXs|uUc76VD@YgF!p?X-dWj%gmgUX3f^|S z!?&9MR9=>TlL4liC`4XIGnk$Dr3T+o{Aci|Vh7utcT5z{%Y14F^Vio0UKi=@ov$z7 z<9RN?GOWmD-Szndc`NQZHr}D)C}2`5u=FQZ{oM4T1ml_=M!1fKoyGd6d4S}TI2feZ z!kz?v*ieq0Qov90%X`bemf{{s*QtY%Dwab$m!Ek<9Am{iH4;F$$JQb5*VFTC>KR1B zpdE9P+g5Y{lA(8f2!X?FE~2y&a1TPsRU^C;xrh}S`OY@fVL=ir4O;t7SI@V~`Ow8M zu$|AFpDk-LOP-27;B}phVtHOnp~I+=q0a@OjO~cP?dsA$CsSl;ilEx&@8J z8r4V#sTl}V9FsYg5cx2<$0X3leBoR8^dK)AF2nWe4goMt{Z&vbAMBXY6m-v*-PV-D zzr#h!RA0B;6fIUf!$^5J&56#N44al*pe*h?t3Fi_k$NGoz+&Ccfar{dEyA94JK((= zdD{fR7!lj0AumrT0*Ltnx>}%SnU6Y@;eLMCiQ}Yjp+X<`F&z7joe^_L`&52MRm|x1;1&cO%z9Z%Q9v zqu~IOL=5K82>&2%`0J}N@Iyia@p%1G(g+xq@AIJ(clo{auNQ4-P!KWl11bDROp=LX zjn?#8L?zAF5~ZS8Q5wcn0m`Z)rt@)8=1~LeYw7O$z4%@Y z?Mkb~-XJZ}to7$uErVUIP)Y}_AN$@8k{uo;bqq4_PUV1U|MOcoDGb%D%~V z=?TL#g&EsWEl!_FfVD99_bpk#7362)*5{8}**EI`)EJdnqOSQ^O^kXeS|{8vR3u~U zEAFKW*wT3yD8Os_=>U`kwdQr@xbOr%0TU-l;)(bmGDwz% zZ!0YX%MU(@l0|eh1L?G~&}Br_TgD`@%5MSbdw?&W_WYQJ?ZA|s9EbJgoWB0DeB&fv zUyw%-hXiOJg65mSo3}RQ=j$!t7CsRJn|dfwopF&y zqCc176IrVZd^(g!%Hh8*7#4&Uz4TVm9uIV9=CRTrcIvwsH^6#AxhSM;9~l%4@gTKP zT~5T78Ca(uHK(H&lf#|F?4Is;S5|U4C~%8FdtjR&iK2pNw97} zFbFlP{=SV|Y&3-q2%m`c5+=#WS(3OSw?j9$qe_|@eq)^LzM7wOFaX0x@)l7p>y^S_NCm*B!5fq%}a_Ypfuv(D73FGcU` z_BJ6iJYO(zEteVoqt&VOu_jDN=A=J+xaPZfu%J$(%_G%|p9E`CRZi=Gbzgb{CA7yh zp@4z=%xzr9kQQoFHRi2Ug$$GlmG8f37yA$vzsq6W%jJAV*=?P5cfZddcpRQ`2@PxYGk=8UB}_rDH^Eu#3Mwu^y9;QpO3K zXwfaHfKBQLW~?Nl5i|6g)peS(97$mG9hJF!S?hdsoVeUh#qPiov z)Fth8pk36NHt|_gS+;{~9f~{zES7+!3=hZeEs7^%?&%9bHKuGc_;seU<2PYx3sEOE zmplVrj{pp(FweIU+gm`>{0NC(0}?4D7u8_2A%M|@wmIsq2UtoT?Z>8RV1@-qy}A~2 z0Xd+3dR5+46J~xWC_OQN{9g8|wOjyARR)RG6Ql#66^t718}_tCguR*$V!*vv*Nguf z5Sh|?`KW&Ee4mXWa`K@>#?g1`_MfIE!IiU;F#}wLwf?DCAjwryU|E6*om|5fs8pf) zuX&tPT7M+XLJU&1k~xj7`0>x)g27CR&n7!xvO{oE&ZNPr^af z>!`^$DfW!_RmHeq2_OXI21-K!uo`(s09Ph=#Gi{S?akhCR-~;JH=6fQr~j$UsM&Fg zt({EDP430WebmCtLYW`1F$*Ud`XGH;E|^hB6{f0pSJ}nuHHoB<}GC% z8M1pCMqGuq-zw&cb?3NzHkU zqdy4lIj$#PS2N~O_mO`Uw*6*CuRC^MS|Kc^40yCoi(6#&Sx>ks7C(xI`C1OB35b{5 zi(y*Coe!hKG45eb-v>pyuaniC$A;8L3Q%6Xsf~+5i+UWGi?>6RQfNx>IUSqEHL3C^ z71r;v7=^CyY0l8_jdMTJgQnkS{5pfocgU}PEsr;TVH#ijNA#|*VT!O8(X)VR(0q}D z7Bb4?ylE)(BLWqbaTid^@bT#>X-Ya~yimSJm06vLUuX@qBCi+oR@RB2Rg_YS%Mjsz z*f}d-*pR9hq5gCRbx1j+eqY#(qV(jgi{4qiVcFw#Yevu1U(s*NZ}F(8Q38e*kPdZW zT&qnpp|F7wNcrXiTxl9i2vhxrr!@)&<}s_%n$Yp%5_kx@T!#=TH+Lu*_p`RjKu?>l zjjFSJ-XzT9x93;Xr2fQ$$J=y@Wl6kmWTpi^j+S56VOAPMQ^|K-C3>x&M@J``Bi?Lq zEPahx+ESl5#A@oM2m>UuRt^dhY2W0C!|A7gu3W*!^}K&B;+7A-2fW*mGP&vt{0ZC{ z^wMnzt0Jr2o{uu{;ufirSO6p*9#kYeVGCi*13&PyM%^p6e8M|xs67j-jKu?O>fXRYL3D)k|_#7lta5iUk|SATrv5h9c6Vs81rIjzj2yj zRwE%ewl5e#ddI!e246(dh82jbjvRuCQeU%+XG3I|Qv`tSz%If^&6qg_xY@4fthHNb>Qf06^{VtvEDaNSy% z@^pgdjJ6hSWV>5QOkg~Yb&m!uQ@VgOX-rL#ccV9c(XWPth&9mtWb_gCdI1 zuUxCdQkE5he+=zP1v5<&XXt6|a0wsu6s!Rl{0;0;khQcFL6|?vGAlKtcS}i#w@;<3 zGnJwsNG?j~mhkrC-QwFrG#f&Z$8wA0K0%9#{@S_hb{fI;2KigUpxr{ZMSRBM9>!ofsuFD&|rSO zsHUa%IXMRvIl@A6L3}BWUP=fS^!M_jUVyVi~XkN?u?CdTLd$ z3x?q$duy(5IvguG-wxB4Qw(wPD54J?R31#}jq`Qr*~dWGjKx_Ov!Trv=i$morF@ay z#4_mb4NSs_1(YjN%Gn9~I)P$u)hx(&H+6Q#(le)@G0#E3XLDDQ7q!-#Ms~IDkh78n z2n7lsi=H7Dw7#X6(cv@Y0YytHG;V4R{H^W_^D3hqF*u?`xL!!6;wxiGBWwIx{z{#w zv#XyDF<1sKfQQAp^|OB&ofqJYYLa{(l2Ue_J}H?sv9q(oZ=-{$18VQ@Y`BpiaV-s` z7i@V}T=CiwZAk6e_QmJmcWrr@gF&|9cb8nz*%llrSite|h_PtictDvxyns1lQ>oRG_I6Lq z!mpPzYOCNDQV+fc@?7yZuV;A;M}gH`!6!R180aQI4$9{FU82Kq<=&U^;Nf$`ufsg* zT;2Sm`_x)c*B^(<>LP~)Z)($H7GOeWx9uq7sk35bieDoExdl7+T%haB!qtG+? zbgreJ4mVxd_oQ@mIqWmiA*i%UP;?+koxiOMIgo$t4@^qt+lF zpl`@22D)TDS7qp|ZFJKVq*H{Fj<{yh!TcY`LQSKH^e-M*3%Hymcqab^2b=g~I3NV- z-(g#znh;T9X@~>S4QHD~)+Az^&-C%hQGLRj<1N~=Tw!NA`C9;iER>0oabMaL_NC6R zqYT>-1!{`;$xuqCt&jgT3>-N66IOTZH4LNFDg}`0kvVsa&<@U#*H!ddvRe1{mAuw! z4&J!+^FYI;OC^*$AwYLDbWfSgXI(qX*d&;| z18+ez%^YIHOepdfY^wJ{Rs`ww&0Py#G^oY5a$4*?tMYDHoqrE|<7&|W2!POTHCf9< zb(G+zFz2uaYlG^jL`U+EYB>H--!U~9q;E-td{V@8r6R{>$Uw^5y0r`_42|o2MnD zEkGF)LS0`f#sW6|>;wd%UJV(PB%b$+jzv{fh&CE~ihZSkX zo$(b_APIaJE7tlVlI`Lcib^74w&-j?^a46v{4HMnH5Zw4W?%W^+n@LpcN z(7$8{mc#~Dj~5Z(;=WL&Fz>h>CBx&@egab$vb(e1G760F*vowpgwZe}YN6I=#zQP@ z!jD$BhYe(`rUw`gA&~Pq^NiQu9Y8R5!-G)&+7slQySBZafKx zkOAxcd5IOoNqla((r@lv{cSA+F1#{8Hv4@E+)bH5 zS(8l2CNCO-q&@>6p{_tX79~hf3UoXIuc-%Nc z#I_%-;86OUxGM>qPRC#@N`h|OiuT3k?E1z4EmR{Dk%$?Q`z-0o!Rwv6}l#734d1+IY9XlhI zsLhGRuawcxJ2M}JdgE(OY-d|?cgOz@U+C)-)B&yYMR#vPvuaRQuN&JOqRgRm_h#(^ zVmjN4!*+>=`S@l*q5E*WcJtmk4%kkqR?h=ZBW&*IH`jDW$e4Wj78L2g#s_dNkn%PT z9-+xlrDO2Ncmn0<2*mI6M7Akvxgf6x@edka&!bL9(Xr|q)5+JI-+NS?L#EDtTQ)b- ztf8{qPZa32^X?@89k*?_XXKVIKmu-hb3MFTvWvz&!cjM%ed>)OFWzpnVNzZ7=xeh+ z_Zyo>9&1+~e>r=f`;H@L`9XiA>-p(X36h?zFKjrOTW*?U^HoCDpFX7-IRu4~Wcv)C z0#j?*dtE2A$R!r+z(yACDZ6pV!F*!z`9{j5{*_vmrhIIr>>ok02#qLl9#bV`1v(Hg zT*5Cx%&E9)*Vkd$rD!2Gf+x{W^Qr)EWge_j|F7`w+?auWAElS$E0B6gLBIgyol?7JKx=U1zN5T zr0b}4uveiQ&83xYOP`7cQRFbiy3GukxRWT)#?NL=ji^yu#fHug$v2jYfp>5Tnr-0O;caAfP^e_WQlmnD- zsW)37&VXh?oi`Qm>5q!ZzJ8qf5WhvpG#N!7d)IG{^r(ss=Qg&qYqDb0{UkA%9??ht zz&f+9NKQPBI!NbNotf8#PXyWAkRZVGp5d?QDEB9Wel5XvAjLeF?@?3zxVVa#wzMx2 zY=t0br+89hGMy%WCQvt!JIDEfDWdn?v+@jB?(iHyX9q~d7gxkAY9c$`WFm5dkD%cE z&g*6Aul7xPcn#Lpx)<{3n-d>W{pQEk^8+*V@hlb^4Qdd@&>!w9PZjkOH{kZcQ97t| zINXAekm1xo-<@U=Xj`(YN9NM=+Ye607)iKYg~&HE7Z=9))7lC3bbg9w!Tkex_D+cy z0%HM{9ww7~Fp(n@3y>b3W(1=85&}uW&ZOnbj;_kmlvTku;N%~77$1;K-1A7TfHk~y zpocrWj=2p{0t-4iZF{Ug?(ZNJ*}_O53LCzg?4b?u;tr_FiM}cYz+eju%wUb1oaxI1 znZ*M#<5>GJEd<004JyWbE!4meSOw_8=aplkjgE@b2O%D8G%*C!)S4(WYSd$tA&XRR zQI;-(qc(j$xGhGSJ=vHBN?BSr?gkD@(4rs3JD$?g7s4y^EXTeNkB0urJ!f(%uN_S1 zNsLoq)Q?1LT@^VJoJ#8DM4wfcUn*BAqan>ZcL(cVTs;pLS$OOhc`FZE_7aH`sJSQb zaIe$pYFh2rWtW`W2WW$;onY{bN0kZz%z`pSMX9p8xPt7PoD5Hx8R4;B>$PO64B$}s z$S2@ezy&J!ha-aooc3PxR{&a4ofW_H zEMLp>ea1{*m7J(9 zR#zQn1%|r^-sT(VUw}{=v@mrYE)8bfwf+Y108#P!V33;KM&WgIl^ofot0oW~b;0Xm z8`pXcc}XG*uA zH_8TtohvROB<=ims%B36K(R^}Ch0qQtTz>^Db&`#5iCG#$Ipg1uzB$9J{;wJz4SNR zfcF#j0^-pONIH@;<{D}=ep3!MXKtqOK$pWx0_J}M>DR#D=@&vO4AwZ*v^IOsdiZpk zYF%I0G!$$1d8N)g00sFE=nw8aW3)owXHlF-g&)=y?!Xn%O~(so^yDBHe|tZwsfq&R zy2E<$%CdSZRlus*9Omc6^&iVu2XdYl&emBwv}5y2t|C}#Q;_`t_z4q-_;&qmTl9-+ zrEO}V`Z`g&nTF<^+FPy?#t=XAgu#*1Oh`ZP z7|yM%cP4|e--=WKtG?bz8We35fyG~7Ot2L~c0&4@fHKH;z{^C-G~lasDW^Qr67*1b zHt_owJ;F@=(qLiE&@mi_fGq3aKb8avD(^}o!Iq#OngV6LzBLu}Bw0bczSoLt?0c7IWaPrOwyD~wmnn{AAQ64hLOT`Z8N z$AgFuGtd;$LL|^1sB?N?exMo+UcjQgosFe1WIskN6aX7Zd*f*jO#_A+!~QVVLfH~v z{oO=AkR7o+E5(vTIY=1@KpjoS_rn9ZD5kwp#@g*h4LnWDuuo~B+zC|Fk3Lw~r9#BM3#Zw|MjwAvXKtUM-Y z#msXMM8GPk3Id|IAaH1}pLwC^s(4Y^H&&Avuwpg~B#;NfUIbX$tb3THbX4G=fG`DL zO(kHZ?9$rNlXVigCKc6m64Wez7Kkw{$Eo?$TMnnn-=ySA67aBt-pa0UkJO&F%v>Zh z2V|gP26D?hRYe59eb>;yvJ2{?jiACORs0R74$d3+CcgtaWI9*mKv~Wq54bvz|LH%l zpu@JCndA*hc2l&-0J;4W`z22R?!S|hw_n#-SrXHrnB430O1^;8OG1T0xflLlwAtri zUJ1+IO?4&yVc3e(>(a^Ec0v^Cbpm6<0=$DyUo<>@YwWVBWP*iH@D|0(A4?J|F2CqR^?O@zE+JKW4XijPnA?;sY0TMtMpTjOb15M_V z>EiXuNs0m)H#1E10D_!QK%tyMNb-8BFT(>Rio0_}d?9>{SSyr8Rv9gu$c@ zN)7(3k3ZSOfK*EPXm`0}2v{};+RE)%kFEi@T$b^R6qjKO@w+eYjyKfQ-W@%X_W}HK zV5UD32ri19X<$Ztd0vH~O;Y=5d)HZz?*9yHw!_Xxs_5f|$yc>j5lzr zcf|z79rOdt8%91t{Q?3lTMLZL@i4oB3C4=1?yy6PMkhyey<}pZ0c0sv?C)}>Gs-^w zIvTfK5?+jx46w^OxryN4Q?B-ak%JJ)m#)n5u)XOT*JYhaxM z-IFeEfj8d;xK&}N#Q;gkN8=K(s^f|(1IX~PseVzHIXxE;A3yYJo7qKtem_2wJ-B9C zYns0F`e`Go^C1ote>G-gu?6BOJ8WJ*oy;J?V|hoaohN_09Wt}Y5Bq_lJM+Zg)(oe^eKqQ`C>TUxKh4#CIPLr`5uGAHrgL(#LTs(} zMUIdF$;1j49)qg`NA3vezvH2~KTS3Sv3-`zs9?rGr zWg&-b;od+Xa|_2uXhkZ4(j+V`wN&VfC_dkj`8CE=$9<5B@Zo2TBwL^|vF9Cm%Pr@s zN`lMCU~QwI_78p&#|bY4_SEPf(TbU+wa1(ld31mQCyW@E`iJHo4TF22q=7Enc>q>r zfpqny<}$E0)U%j}F=e-$DKV;T%Y^N8$gNgs7d3EtX-e~_CqB|sGz0dc-Ar=k1hS1tbZ|W) zcRNy(QBdwwKqi2tAR^In>;^w~paik(xei-LpWRJ^&Pl+JgoMWU!tzHvn98zu8sY%B z5zulhbLOXY6VT>CV2v`F%x@q0K!^DIX$c=B+6DTH1soC!T?BTQ&#A{0>z>cDh+E8O zpsXm$k0bux?%n_s&mwpW)GAyUG5Ey{!BZSSSqZ^I8F3 zR$GN%rwABC2u#Zef615ZW6Z}SIUoVq)7v?ez$~gHYnk|lfLCXi7w17ytsy1_PLpJO zZuRYJAIJXPAfPqKDC+pL#)!D@EVjU+xDf2vKa5@d&{ai4rX*jS_)*>9+_<{+sBC|F z0^?vOU;{Q`i{m`KTY25HL0vzm!fZisfd5)QT!Q(TeI8U%?*~>`CvD+1giBSebb;{( zH@rJAmVr&bl`N46>>ac>Zn6>!_``W(Emk|(W$l95#S`EcO9GSKLk7&h# zW5Yl7A#ja@aZFY*NpGAfGjPMKxb?w@5}vZg&23e?B;+v3=At)p55LEDM0h_0`5}B9 z2Lx_@<|Ghu*Y{TyQzO|I5gEZ^A5GekHwUT@+S$%QpOyA0zaUesYWbn@?_HqvSf6@} zZint;`i)Ur_RZ`X{JMyeKz=n??_i8UUoKI3;ty&CeRY#4eLT>2p@VrJ#UIIkz#Ih2 zqKi1|3`aUEb)38XJ_)PP^w0ZqIRdH{`HVl~+G@?8!m3a!as&Hvz7$!R+#N^%wfMt1mxW0E-HF8eTVo*B`8TXX6IelPet!1b<9>psClPRRLCW=T$rS zRW`apibg|c)77T(m;=-Qx2 zPr@ozqi|1*9EPQ&A9ok1)f%P5F}q&s;FnFRH39vQ=wmNWG#J-prL0Ead$V6}YtjMbdR`If}&4Um}M`Fv(<0 z=FONKOa{Z(kLWq4cedLBW2h>rq#N$B4`}o|B!91h3FjPEwe`KN?MwLN72*(h-Eu`Jq;fvuoEr#d zPb(HBZk67h>?b^rJKR>k?-JsD_W4r-0w`+W)Wtm=K6T?3uJHYcSn|BX>&HVr_8cyH zO51$>B={eLcPw=!%HXZdPbl;^UM$$E7#EIL*qdX?bWL^~nz0p90X^CqiG%)~1XNJ# zUCEP60|s5Lk?NM01YjSam${%gjdV)q4bq+L$H3S56rJCv_@o?H4ZOEn{cVf;+8DHE z(fbR)%YGMhgm;UR%AYZreC)(OI~dT9Zv<}oUHU0B=m7EWeG$Lr)$l?&M*Sp}-}CB^ z&BsGVU;!OUq|4_BviTou!|-?a=q=Xx%7#YNZR-a`IQ-Vnll9hOji&dj@O&<X}oYqS{_;`1MV*f)Wak;MRUmrl8rG>=`zIx0`H}5RUhFc|=fuho75=1*>NF zRfiw1zVk*l#DDoKOg0l~Rb*s}@NNE-GhN`S2{;?@`D7E1vcUgR=RGU1ecmnTeZ~!E z3g`8{ceIorN>gF6T|dZB;JsP&AOoOCy#w_fxR0}Yd}QW*S_b}_fZzj1qur9M;7s076A)6&7cqwgx3K5Zt)j&L-ch?*1>7u9^Ee$>PNnMg$1>oXimM>FK)GTDMFNa2yuDFs| z$d8aJN%-h5r{f%il##Y{O$QYr6e2zd9MSEgBkmOmYB)T=#7m_wpZTMLCeP8mN%qDk=(;<&9u7wcnlUQ6LUf_#a3cGq>C(!nO)3i`zIDbpE9Wsp>S|1 z&x?^|t9t^-u;z>cMlO(eek?14qd9+c9ezubj00}lu>}Vns`^Jr*o4X4nZAE`VeNfp36bLWSQs`F(xa)5z~K z>UqWL4hSRtXImo@i->?fiKFA^FSsm^;abGX;R`-+EuR`9_p#WW;3Z0`!_&uR3 z7AZm#+2(y&Xp(i8%lw?#J`m$Cx}%a4O{yDtX&0T%PaMk}k#Zdl8bhCH!MI-`^znPXGj0 z*;336n-RF4Z{35)E>{V<`$EGZlYS+nH&Fra{BUMb7Re@DC0GJ*DKcJoP$_Lb}YGU4F2tLZ$Yk(~^E2o1(vCy5^S#S zXZT}ZjpgYmI5ehFScW@|e70GZ1`kd%B?8;h#|9Ye{ssD%+4{IA_jO7rmUV`rmB6R2 zOCf0&{vPcrS1t>`$NP(4aVLzd1=sc22JE*&PyYEzmVq&^7o0v&;DW?h`q`$utE0$s zecqe6*p>vIjRz1$+UW%;O9^N1;m$koWPXR2`i)x|`C7iBD6cd`E1Z~iv)*EO!7rZ* zXAYhV!OcAe?~`1kq?a-HD_`(>t4LjJAM0<#9O@(`R21kG)+{~*5(&JlZmPo!RiJhi}pYjU{DGG`-u(c z^j%2*Rj>q}EB{L6x3m&3g1#IkYnZM;QvSrz2eq#R@sm*H1jSUS=M0yy0PFIt+1XNS zIJAaE=Ux;m*ynD=4!;rmJ|Op1x0`|nOjg{!I{68+Txu!&0kj#0UpM6i6Oacq@4o2( z3vS)5d8x{a(wE(lvALEKq%QT0+s*m)+q`Y9D0Mq6;kb9C{ z+PlD1Sj67S!= zHU81}h-U*2^jTou@%g8L?1+AagVw*QOEaH-&4BQran7)@y&jLsmc37dB*0t_{qdWy zbtd`o z;1^t|8f>ai7`gt9dm*JY>>ivOxr~+dVSgyjdhH(8+R<=Eu|#di6xpv(V1HyW1O=ab z?q3l2fnQSDRqoS?9uXnbB@@hC?b1MBM)T!PO}~wGEY@>N+2YZZm?vOjPnJ71qOxH9 zf;agFdMm$I)e%10i`-u~yc%%RuB_!<-DwnNBCOt3!~jINW`PcfwaUpgBp@a!>tTA_ zd)dr1cCG!^E(5JtKz3Yl7!kk`7CceY@4(%^^g^bO)4Tt$f;*W<{fe6j?{`+1zj#mt z{si{IL`&CtUCY|Cf)xU-B`bL`=cRD;?;3Jmm~{c92He@(riXrC=aU>4cZQ>)n_<6_ zd*RcvNa)|6Bl?(Y|Cd$5Z@g=O-Yfh9Z>Xf%Zatl9)*WdMtYg~(imZ*QLyC&WFV2)&4Nan5c#%iW$ROB7-fIlH$`bbgu^!a@WT$5j_<`2yT9l-%~||YrH6f- zN3+S*qexf-bg(k$7xGR@tDyv~=9xChwjsNuhYlzLq3LUYJ*W=+^QdI+1k5h`1vHC#-zi{T zPoQ6+Ln`4`)!$Zn@^%*Mc@QXMmx{U*VOSG+;ayxpQ;~i`NBu3N4!pvy1U9Ujf*^F^ z?%ye<8JW1(olgK7CfHcYFVUvQSBgLv`*Q-GORx@^F2xVXSBa&BW~d)NlZEDAEKXO| z;wD6_YLUJd%bHV-sy`Q(p~ovaHou;24Gs-tblhJ({lnzCnld?aPd}(t0NsqTGaETJ zT0lOJH>gAU@k}!7_3m~ApfZGA8KocqDa;EX81W7l!M}I;VEoVq5M?^#IR;Pq(+J#1 z`0(5v*U#)?ouYZKtBPLVC4Wh$UKG8HqGBRaaPBZ@)6fm2+(m7gm2I2>Xj+%^sCW#*4rmPK=gt4a zne>Wtyad6@_hMy%{{|))4r?F@RjTOz@@@hDN`~mH3ZF%P?OW+cV!j)mzBA+OVrK!U z9lp4D#igAZj&~l2*=hipgyxNKQ*~gPONW)b>a1AV7{jQvikc$=F{eYEIJ&-IW+E7B zS@h3OyvA><=STg9I7aE%=p*;U{@}CqnoyNxusYqH4J5$i%zA8=bVi4%<4}Hc=`7)f z^A177VNY=-HThv>ii4o7TLHqe<}-3PvLUm#gVs3MK3mc=Mjj7b5SZ5+-E*Cpw0O$F*f*T*7jQ91u_E( zx^=S&JD@4iLg;e(`8Ta6-CqRIO{ERw{OvbRN@B~swy*EKsX{x#VD`$ILScgRvoG-7 zox#l`v_%nPK?7Fxx0Xe5rFk6leW8OsuZ1`cy7ejmu2jUOD1s>mN|(wMk3GKAnE3;- z%-o_iih%DSu`Pl7bv0{Asp=0C_`$H_mbURYE>GgQ2rL>trA}-ajlzu&|L`;3Q%bTF z6eSy$?NWk&UkgEgYe61zVIJ6clYV!B$kI>7sTOHqL~K@lF0CwMUjM$6jh?-*9a17NYs8mg_cV7cJCb(e*uL_$N!$7 z??T9Y2^>B3)Rv~NEgkmnNZvoU09yBl3gN>kz=h+Z$06zW8UZ}QdzcdtVYl9f760?| z9`XgyfD7TNk-WzSlTMQO?GC8RCUJ1ysZsrm0IdHFOMNNc?~4__l!r54d@#2>&K-Wh(^>Onv)z1>g3!5aPW~)tbxpM$E-!{)drNYHKpEU^VahFbd|9Suv>11R?5VhuPb*1$CA(Y$ELQd!y z;WccH z;2$$C*vX0Ag*dhF{g58{_5*duMqFT2^5K0dvx2uWYP_2#h^v0TU0pXH>ElgKSty#}k}p#$B)xwsQ^2u1yc%AY0Gm_+ zSk}WjRBX#9LwWC1^De8$MGNbzI~(47LsdiqO#d{qyRj}H=L26bxd#PEqX;&5Xykv| zv9Pi|Lw|2eEKAgALsVXgPBM$83e!&Y4$}ZT?V#m*K0x%6;XBG3LWh6AG$1L`@!V#5 zImWl~*Vq+Sgc#Bhz{}>>3+AaCxB-pZ%e!VpSjSx7JuRC1^ zaqI7Og3ki{E_JGtQC2c;74r_#>Wn;EU`uyvX_zAXn}*02c!Be$?-kUyhW`Z}gl>X> zlI5VurV*~_lAeQyUu1EpA82CrWxq1h{2Hs!A-e|7E-xzV{&u)RaET~?Nt|coC1IBV zmSTQTWZ{dJADm9TQvd@8&Bi|~C?622MAgH@MN%AM*P}h-XPVUS5&J1`ux)@98k8;z`=(<9jMlCe}Sfi^Glb0;;{u;~>=-CH5QGbnpWFgUP>x~Ttu9plYatD z8XQMD;h*4MxVIF0pDi>L|6tkBtQUhC+9Z}LgK5}nZ)m{0OvO)qP%P^+b|VNeQWf$H ziYRI{@0AG0s4w?k+`qWIauM+njfL|v(#ECf$j(=hPS4vW3v6^Mtj|~HH(qJFj5sW7 z!!dO(;0*14W`ZH@f@$OnyW=Z3KcFYrhY@s3Pfg=IhOH8(Frc#`0XG})?SX}M;^bI= zLgDt4a*+?h9mS`M1Iw?ax*`V9yr8j4`_Rmxt}br=Yhj3<%AL|f0Rl2(czL%EZT z$VKBHKl^GabGky=BU|#@bn^;w!SikI1(?v~da5ig3TKSoDT_>rfj;khY3x%|Xa*gJ z-Gh=^eZ;a9x~7t%NUB{TB-kr_9jO*ENZG{;2T7Gqnjl+}4m@Cl0!lUKt3OT)D7%|K zd8%KI_hK=~)B?hy2WC2Z6+J_piLuyuCQz%9yey!uKNW3|h?rN9UN-UY_xoNilY{4> zFW!OFp0@vC;QcpL1_!hiVhRsf)3I^b%1zKn2Elb@Z047}tzp_?!yaIN6$I*+)2~K$ zkCU?2gM+qQqNECs)axXu^z2x1Y2>gt=<^IAHzblf$R4 zvS^5QC%uNms^nW8?xCA9NFG1*0$V8ZtB*9UfT+X#{>gmMvvhu3U* z!MkiY;2q5_twLy$VD%pE;w5zb=nDT?Yik!eXhaCYEBfuvz^7FVM?n3ry!VJh@k7Dz z1%4xW?pUr4bW>9NtjPS1w9iqRFCV?<%J9*JuTiGrmAPDt=@RQYf>9*1sIIR$Xxp;d zw+@MP*+47g6u*TBLGT{nooG3eT2vY6x@EkM0ay)%V&*pq5ld8BZ-lmfw#nNUM57D3 z&Xc2y#F_S*Z}eFLXeAfcXbZRE6mO|(tKF%&QI>l(@>}6pg8=yk{$2?xspj8jTf#a+ zREu7K#S8LKKpM(xjlLfEmCYi#0Tqi-h7yNa3g@=$x%&8Ke<|2&)ZaDC`+|ihblc(| zLfW*pen6|N%g!%>x0in)SNJN79Zp<()7aR;pC^}&ABM(K(%{?rW7 z@Z6H>;eF^Y?2*u}@Y^=WqB}F7yQ(vQshCbxZrgt=V(R+;3H zeO|#~ux_LnCIsny(<8nel|cn?DBwd(FP(DxI%4$~-(!gH!~%%@uMX3R9^Cot4(P0~ z6s=eY1*bnTzvPfmv#~fEdjv%KH;+JNo9#gw8@#VhP~yJRUr>~7xrB?YAwjg$J?96T zB_?x^O}`|!U)+M9sE0iS7Lq?v0L?)RLqDK}n??(O4puO>h_pKr1F~7Lq?axypt>n8 zP8EP=Cj zHw^C=OT>lDZ&2BFzJm8L*y)Q|_wp``sz87W&b?53nL5PU2Kvw;Y$%N1`UW4q{@X|K zBN-aqBw(`zMucElq=h;JdKE17=1U&&4mLFKezd&+PNj2SEZBqj%>|3c8JWs~N;k-U zCmqNrrH!FidZb~WgyRm zx7^A-Zf#3mh`=-81;4zYam^WzXKJ>a=+X=StgS);_%j-o4D(5bsH9FGiEMXoVOPU{ zxunb`%K*0Zv0roij7T7#PetD>L@lu_ApHV1o2S^>u z)q3e}c;`f_7dI#xl7O%675!~flPaN>;0v4MjD*vdUj7v1b^dhkIpDxX)%cY^ckKjP z#OyQw5dLou@Ab-(-Vs-YHi z0NDj?j}Q#7PKE&$?cv$P%h^$C8}!@rs9prU;@WEKpE81m6>iKNB_U(nB=HOz_Is5L zR8Jq*WaYNB+{oR=Um*GW$r`tRGcgN71MnJlU+-Si1?xP2$J@3zKuZLBK)r(@9*p6q z`33U%P~J5hTq|Ke!zbm`qluKJFx_}-Y@iZP7*DI3J6kbM^ZolUB@hwf(MRpXFTsBf zMYGTHx|dxd$&B-7s*>f+Q~HQrwE}o8=n6YW02G)`dgo%*rP{~qA1QP(tDjiKjQ6FN z`KUsW7tc(8d^<1o1pT!)YpP80dD_FUVAM0~nAf13u&$p$hxz$;pldwP0lCEQnZY8{ z7vct}SVNO>5Sjzc>Y7YCm9&lW_aw`%25MRQynu(c?{u8SzzOVwRNdQOP%Q69|G=_- zOYs!>SV43r@>S`g}sRGUN|RZM67=EE31v5vo<@X*}#C3$cpPS{xk$o?_X!m zcD4J}@WVABBfLpPUj~GRERXjLICJRVK$%G6K9|H`a>HX=(=)V%b<_%JgF?fexR%;0^ICQeGC&^ zHMx2BTn5L@l;B`V<*!Z?Cby1(DNWyJ-lMTYLoxLN`XIPW+D2-Z2QYv^T%Ba@7f8@( z1KojBFSgnRmr-o`K0n}6oABRPEUNVD!Fu;#4e(?Kzmo;N*^6izDC5F|Q-@H{^a_l~ ziNK-2Pf{4iP;ncHXZ9%!sFFtCq{8_Tgo&wRE(ZVj9yL<}xI1eI$mq@`k1NG#K@-52 z@hYvHco$vqGo1o1!`Wp~yMd53h=lgLGLP6aq@M%jHZXBbQ|P)V>MWB_*pY!!_du_p zu3TxxJ*m{>PQ7x2R$6(rkKT9}W&P*?Ksdv*_nkrodz676!@lmnKrCW{YIo7wsiQ=| zBG4)l8WB7h*;mJG?Pqk1HYS_0h+62jA%zM=hzAPCLWa*_;E+v8#=J%S{FXpG%8^;< zS9R|ddEJ{Ti&5&FIyL5J?{MrN>z7z7KwDYn_ z+LxRE4Yqj%DL&N7H2WP@odBBq3%G2<<(6pOKQAOC>Y3V_V*Hfk{sFIU4mF_Hle&~Bl=Pb_RIjrVSn8~g}Mc^%_9h^OEdP6GWooEpZJ}#Pp#JQy2T%*O#|mQ zdq9uXqI|`jUc;izl)udrY$Uv&-AG%L3aAwx0C$PNUBrei|MzWpgp&YkOa=?vtP1Y! zT)>c~5R>XFERcfg)O!)rO8pyrdl1O9TIOz=Xwz28VU*C?GN$V zXpI<*_2vYDFVbYu8Iyv6_%@o1B+`W#iI0Z|LBhmR$9@VKE&LksOMr!;O`8k zml^TS_5&-D5X;F$|!fxHAVC*8|kBl0T^0rRx#hPE^ij(NN^bFJQrq~km|D39)Y zn6I*FKcMO%6ff98uM%^6C&*}t1) zTVQVu=LH{!KHOe=J&6^5FM;fD1sv$rx?V4ru?#>*rvh!`%iS0-zUf`dXec7eIIQcW zakzf<91Sh1%7@N7y77g24AGSgM!0^by;&9NtW8H4dv`DXPX!7B&-c`U5n+hT$qWXm zVD&U&=6s5pRNA z?c z3k)xN|{g(QJtJ@o3b1AV-^nq7k+i+ZjcI&`9 z=miZD_?qbpiyjkSZO^KP4HgJiu#^mJgR5LpaH9@FsAP5B4#q>7&?r_W^B&cTgT(ZI zRSnL0)hDlLbOkzKU{!Fs4bD0st>tAv`abku`948DBu#mD9)PBo9JBia(S`HdNa_Gm ztss?TOH(JyqJMYpIWN#r*v;)NW5(S}r)S#T_eamx-@PMCDjm)Nzgt7>H_D(;8M~1D zIQBl>;eN5r1JG~Z4QpVIzFhFKVsOmQem(j5&;o2cKoY%qI)^b+N-4Hh*aIvPncGq> z{fm2(fhEX@1^NM-U_6$yFy5Y@ATr=>5y<=uB>@+DFa=8@mV3v~GHc!^&YXrVNaFOK*=@$N;u$>G>rotA{R`YCt-WM=qdn3cn>yX4xmh5OUk$RSaTsQ{FtJ^ zC%z*SzVGR)jppVqHQ_9QLmO~6UY~ffx%t@(_|n1M9MC)z8#;eGzVr<_alQDqn55=3*kC`o^uVh^*W=|F>q53W+8SGMoa5bE$2Ad$KZBa^i z2Hq}wG~v!p?ffT!4_~@izyN5#9GvNY$XyON`XzOZ<(!R81awmZDm7zWO+~!}dmP^Q zO~>{~z(|f2%5VWXW5^g#H1~NU*I-`+tf1PxU>|vX;-*_M>)QEyYn|w;gzdAgS|Si%w} zk-V^+C26nKwc8Y&*=i3F*}$Q$1IiU&mH_2Z$yL0fGZno-&!6# z(1+hG<@{_4><<0g)v%nynR#0VW0Ju~Kt&|{{({2+N^tR%cZ2S>pK@p5jh9)WF71yb zX?;H*sS9k_Fbm)^Vyjb$R9_piV#0)j;WXUJpRg zy@E`rgS8f?nmS7nntz^)>J5J&VBw|iV*)Vsd<01@=nOJ@3jjTn{1XG4nbm|Z_+9kT zjhP^J%u`a07m#TnS-*1-KULY{Io&)%etMkB7j}6gm;w_SpcKKtQSa$id-#~r7v_uB zfP&+ANZpcXLyTkD@`4LUKd5A94LMDB&15D^*)nxEjNH~UrZj12NI^^0Y|#e2y$^LrP#8oEL2V7<*Mlh;h4MP zHa|L`kzgpJkT3hOsvSJ0=WE|b+eF(-T+y%PPln5z40EzTKaGqE&CO?Xk2|In^)RR- zhbO}WHl5Jzj14Ffk^Aw^A1q@abB zqg({q)TmIWZ{aI_#iH3M9CN!-&=96uqT@$S-B(BD(klO?rh?zdk-VhX4a z^EQkB^oUfG4w_dNJR(_gJwF40?%kauMV2X06okkxwIEN1%fTHCX6{vy{fIfx> z|8?beOZRUz$B*4u%F}HX5L6yWXuf*z`dF=^X#81v0x~*=-T6r=`rfCmTotZvCb`?4 zD)W~yQT52ypXtxoS^~bDlcpTlda$YGSk2wue36$bXl)FPWjMVs$JBU&w}K`T_gQ&2 zmLy8f@#FF>hO0{i1ZDix_dxl-?A2&33+B0a<^hsck1x$z_28^)T-_gDLC@RAOCR8W zGE&h)gqI0=$+*{{B-NNt$eC9b+K_cZYfW6%C&y-#*_xvPa2rn;f~WWAGiQ|8eK)uQ zj#(f*NZ*ow?$upVP!6=H%Uu~_9lEV2*k7xBb|z5Pkd{HjNaIBi4t6)?rT8&;dbX|} zornjxgwOOL0HTCS?^R@$z|4}HJ`Jc(v89z_ZJe_vD5&Nn8Z5?FG>m0h*g;mA76FS~ z>Xi2m6FOzeq)9pP?eUcWkPjbo_W`NP*&Eo1DR0*lz>_5cS|VuafsI}h2R<}q`6$=I z?!Cmns+1m}57{@0bk{|HD%AqA7HqJ=DZqkW>zI_B=}zmPR$NXl#P<&W0tA~Bqr!Kj zL&KT45~88OjN*4r4=ktxSUYqV+PepMq)@s)B*p9T(3|{aEO2&zEk1s&(v7NP8#1n7 zzj~{D45UCtOomYPX5fJ2EVl>mU?vT3SySf+CRI@5z8>9UTxCi|jOViTv4$M>(C*7+ z1nKg|D=0v#fR3!=@y}9tgEyP*>?nsWK9`Q~G`L1QnEHW1h4W3{M|Xc6)jQ;<0q7Gb z6AK#hU-x(!!<5`>jkLZ>`ghLqRFsIDk`%-pUT>qyv2Gpzsm=SQK-O4F%;A20t$f zFm%gtm#xi7uBrDc&TaQzB;dzPgJE$qJ<5ApY{y1Vf$IUUEM}xkteLs)bf&nc0tkQ5 zF3_-r(D`H(df`}$|62XeyzL83iEyyYzqQ~ybB_h}yLJF*EqEir0lp5eV6u%u>O_2rln7s`Za*0A-Bh1BT^B?w{>@>#rm^6SR~Aj8AQYrOnxly zdlYfptCzp0{7pNM+&xSkuXp1 z_f)*2A0mG>htD(VP!4bT0eZJ1=<`~bA84?De9^kl`*sdzS>Y_+N$WxD0T=^|Jh@Pc zKNT^!5%q)t3W?JTRlf{0w^>l-Uw_fFcvxaO=$ZS3vRIa7(OWcg+;}jUzd|XbC^1Ok zdHvD~P_%oIl933o5b}<>p&ydnX8(r)S@K6pY?{EXguiq^-4Z15rIBUte$cq;f7F)} z0=jZO=$E&`oR%~Z9C_i2LCc2hx)i(`?2mFWPXi@JKM->}{56_vTr6yB_Q{q;vcbV} za(#qJd=G)Oj7cIj1topUCF+K_`Z>n&cx!>IxgCroezi$*zJ?C23(QZcG0W;poR4WS zhtFN8eXR|wL3~#VePex36P(-DA^@`vwuEZ`-Pv!1;xm{PIV7qdB0UVcp>I#xIC&rx<`wGl7A9(kIiel7TtLs&2Ps8rK0tNm9I)&3EkJi*I*M zLAQVT_L-vnf&l-@cJ?|~8qm^&SGHJ^Och^vN|0C3Rsl_-i05s6|DjA;+lxd5037e8 zFO(fo|4D*`#=MKA2T{w8P=|=I=LKC&766n9(dT}$JXIRRX#2T*PYX4so>AgeJgvX( zl*?y7Oew@6jj02UnxV;XoL{eBM4(B1sd#?41tlWNAShU%Fd)dA|IlxQ60HZM&OT#I zKV(8L{RNM}MuCLsT7cDt8XjoMzAjn&td%4gfWv%?g^qg<>$lI)B>W65WSy5q6C~Jy z+|$PrySx`y3}`%)v-}#+s~iDi|HEFR#Q(gkSQtQ3KY>UGiwb~Y?k!sg+s=EFysywV z^QX=~Me_v@DWJn!4)>ZQlMUDpXl=O~vEb_wKMNM}x`Vk8`@ii&Z6tjMSw3{YmN@O? zw^HHNXkIGl+&;eC_V6UEek0q5w32$&Iz+Mdud%y@s7-Mxf|MStCYs02gOgYhPTt#|r11T;f5Gz3D!qalioY2>$tSN>HJ{2d4 z%di8WAYg<2SfIP%3}|LZ{g*cY;Y!QK7q*V8XD_cDQgx^Uf|2Q0ljMp4GnwqYrE(ulaJaY48XWdR38lQNGP^IN)Y-IiQj_lm?(b*z~jk8tK;W1eXwX)qv$HHpqKF~!!Ezj$sN#$bO{@09920hPrlWGK%{CAgl zbsIh`hNuwVJ6cRCJ_3-j%8D;Qw5V%sAxJ%l(nZt5PC&Du*FZp$uZHJSmR>IfEQ7&d z_*wPgiDWz~ljp6$2nr3QjG3QcfoTqZ0$$G}=>2`ppj_jp1(*9@wl7?o2UW)7Ueu>9 zs#Xj{W?y<5VXqrrqe_Wukpl8NvdXsA2?^VK~cG*p(Qz zv4t}?h!P+r6CO++;n1L6Y@r`m{yVf=oyY@eRTm~B&qHdiB<|lf;)i6AwcC;LBgmtP zE>w8+w`eAaL9|XId8ZCNCGcB}y>KwVBpg8Eeh#!Yr{q37>4A?&PWB+!gO8ALiX15J zj&dI)&})Vd!kz$pL=)2;z?#4T6m|m~-Q->wLh03d7xl!)!h>riR}diJ&@n$kGs?dqFE?Os^bP4W!m^9 zBryBRx8k{OQ*}Fuk-#Y4u}|jm^$2qLm&a_wS9%#AkiPLijB>@3dVYYeCt-f~*#|?< zMF;!#gX%veaLvh9l@IBapAxPh&8{J+0sTH z6ie|M)U@NNq+Vk3BpXF#eDWo$!Ar)pr{esAAcD_YMt^QjZ3N>{tLlm-{&)*WNBauS2HM7oy8QEMhry|EwIrNziw>10N~NDvK#TDoh3x3-DW^4p2Oppm3^ z8pj5WbRS{I+eeMiHsq$L4eHPE5Z?l{ANirjfaia`^Mmo(^oW!+8}%!$H|v{9JS(=V z#(BJzrS&fZ9^F5Z&aBHZHj2W32_d))VhSQ6hTI{>AZCeQ-&^%s{q^G~xjo%FgrnKXFIpR6a51V0c;izgNB3#xX747&PT(wujc^NT_1-$uu^nKRnN$D?+ zCCE0DtyA>@{BhqMVDlw&d5N+R8JQ=kFU_CMPggU(>9U(U<)PDikAi8QeeMgZBoJKj zww~>;WwS>L(o>Qw55(nBYwGqfHcSt5+V}JXsa`HUeTnF^_vxY)ziVAC2mrJ6>A>lz zuP{y~t9jb@nD~7AJETA{iwJj7AV0y8=uWtdc`L{brn4J&1UXXsAUNQ$pOZ@;wk;y?W;9@N%F{B&P7C(u(xY1#60)73}v1@Oqe(3?kx{@*WM0v znuF+>{1xawMTYaNfX(s?`(s4=*4OG0pekKD7nU-N)dUU8qkU|LRsRCn92kXv9BzBZ z2a^sm!2j>TcAa@|d~Go<+JXZC=fnkQ^$MS>DBft)=e-f{rH=Vh90RNJL!_FcWV^$W z+q8W*T(MZhI&`CNgz%s{KN*5^#hcok`9Ik~&^$rlUAEzEr@e_C>Tv33UV}eMz9B&6 z5HFKXlYa*(?(CXJ6<4FgoATr7^x3RReX8Wz@k;Q=IO`LFhmxmUixQGxau!nhyjQ>{ znBvF4C8!lz^g8RkrC8W@>z}kCoW{r7MEUF_??174eGR?-dTI6#jF(_OAFCYG-1U(Z z)d(saO@i%Sbv8XtKa?-~5zhRO1VV%r zUJr60f4M&$Z(gz3ZPs1(?(tk|Z7`|8bDr(Dl4+#4fp4LTbfvJ*12lHu12=*)>?y4@ z0FT`Bw3S#V*6cMIqsi1HKv1__`N-7rf_}>NLX{Uhb%#^VfZiY2oh<7 zLj^9z(|&`meeClw^`ZNhovQn;6ctQC)rp9v#=a z*QbjkaU4o@q+*1bYqtgWUtXaxfCBl`62EzTP)F%*&H8FLWO4yz z&c1D!#>WzMmYl!u$QrV5*W`h824|%$=MXhVTz6vq9zfuP+qhRNp!O~GEFt2?!~Om) zOo7u+K0GpT>rP+)Fd8)R<1w}p2%J%GWfN_S_J5jwAnK3wQ%vqy zKVMAr3+1$ZPe)UtGRk7_~$!s!h7=1eqg6`n^3TESSF~BS2eVTM~asiJE>3{q5HC`=X<7!ZU zXAx0sn1G{drE=vl&oroNz^J^uPKrX9xcT;A?loylBfhC!KA*(`;2=A1t={RUzyzxo z2He~(c&Ozbo`31?1=(JIdULk#DyMM-W^VWJ4(|gJMrpXcNv6iqBedgXW7BN)x%iIA z*ZqRri_MtNkM5vsWlBW+k)IMqThr=y-;bl;t-lg5vA<=LPS+%=gFY=PA=KJEE?@jgnjpQW3%O`W7jT_Q6yD4}+NWP{#DA+>5=$=rHFAwRSAQkX>0XZya`UiO2^}Erpi&`{COrf@8(wsn<8?wsP>%gG#P6M`YEj ztm=C{xxXp*iVt$fVou16Lxm3^ zD0(B=ItrDp|K;sqWX+pF@Kdt>xgCyHNu1E@em$kz`oiz;eG6hu=$Upsd4{ojil3rIbsS#ZB;#jez8{{*PR;l%7Ggm@zP%Tq0C1SSS?;w$IA?H-ikggX0LkgG8L z2sAAa zWcLuL=CVS5rz8H*tQo?l6koTwvmKIvPz)mRE2~Oy{=YE%LYN-mIkqWK8#=sI6ZDc+C& z?`-v_n)C(=^7_K+ZrDA^Mn{)PfG=P!W|U5*KW{o4m_GdWj3i_aFb;1awbyHCb8yMm z`fM}83R=!dt2ud=NWKd#&vl;DjZ&DZPBxEf_fg}#5p*Q&jpjo zb1k?z-${H|EaLCg{Jhuk!GBOQ$bBQG)#LSpWyQP=%N8>ewm=2~ zwK{mS5~;CV3Z7)UUiR0*@4HOn8}1=5a?DSktTCM`IBs4wf^XfP!{cyRp3R_bO!t1P zfk>LRPMt`-l-&_@8b&&fxdQC{IDvD5EN87b*h0?)*a*nTrhvm<3!_VSQO-azgmt%< z#M1-huY-^9WLWwYdqTLW1qFwMv3}F0n31P*D|N~sz3Rw+eSAY?Sg@p?2MI-*j62xg z5~gv#i0rKm0h~JrmnB}@iAO*$wQV|c2D1ydQ^I3^?MSiVusUtXnsB#tMvfC=79)2*;Uwxv zABtKT@%08uwMi}Q$IwHQ|7qCKh>D;u)^L8j1||d@j@&D+i*vbMPNhEKY)(>5a44*q zZ16Cd^&b7PTLuK*H@Z1~EGWwF6Z!$>YDwMeDLM@`ejBR#1fR!4R~f$H4#!)#(HNb0WWrj=oA5b2ysvp z_c41COyq0#NYUVD8^YjgwLHlTm^{G~yhHjnV%N&ts|sM&(@jwD9uP*r%T!#GWMW3p zClR{;ENk_q8moM@DCPnuJJh4>W8b~~rPo-5`^9kKc3yX0&B45(*hBW(#Y4m`s%?dp z5_8WJ12WScQ&Kt@XvAL%gWXH25D%Hi+M|HEDdln6KEHjt++s|zY}qbek-y#giR^4h z|MT1+nEKkt+ry2Y9*0lw{xI-)09zw&`xp8GP7qlm=HTJtco|7(% zx@%&wH|Y8bekf7=b@$+ElHD&n675lB{Es9|N5YEC3A3JjZ>K)sY`w*Y&AcQU8Q<^i z(!UQ&WgGh*zUDUMF2X}%KW-pgk4AFH?oMpHKDS5x=+5U4;Eq2)QN7RQt4~_WEk^y8 z7NY*c-I}LPl+?rJJ`gE_NZ0M%%y-Ja_YY(?9Sw5n9lr~k@H(cwlzVej5=b2|Sm){E zO1xqY^9^wt%G|@RDvyNHDgU@bVC@+%jjkz@%lRk33>AH#Zzn1}WT#;XVR&Lgzv zY`^q#%~?rJ&SOx*iJ7!rP!e@u(Q2M)DO8Nf?D6br45#!=c#}&g^%rqf6Wswv+}CGE z-)y`Q+Qqd)Ox8ZiPt}9+LP+Hbk{*a~DAaspOYiNlKFk%A?g{b2wJOuZ<0dQ|8T78} zd+&ZfuX5+B^^`OV%Q1nR)r$w9xU+Y9eSX<<7)l!ut~fgOo4)R3zL~1=K1vb_4Nt2m z7%=gJH+GnNHLa!B{W>u>-%`DNZfA}pMaGSpvvoSq`C&9+|ENSvZdb#vCgAq~@~BzO zQy~^VgqPbB8jz{|-tWxiw*@p3d<0XPJVZ`uwzhCscM+N)h5OZ3I30FihJazgIPXtx zKdPl;cG@Be@NihXyrNy0~rpB|xQ7FsJQWJLla z*`gdEmSmo7tf^8MS$E11%0QA6|O0NnVCP5Y+eNep;-L3uzxd+-_* zZ4wv+3+%2bIfFWUQaj#S+*>VZwtfw+6Tjkwr3}eviD9s^=dK$64+HJl9&^V-uCY}FLBrg zPbyvHf#RcPv)056<>2W>^xUVeU1@wP zwIDylRRZ1%LXaXn<2lR1(1afsksJFie~6HzR!aH(C7xm=kNNwR57noT$KtrQYI~@B zwpImEiFGrJn<1ee>-8N`uM|HMBJ?YxR1 zgZ#wF*5f;vSpMZXKv4Gah8FDPxU460;*8O!#Ur3@UtfngrR=Ul8Ve|OwD{{3zcWv* zl)OP2w)NR{YF2WL6Lt1fkP8qlw$C_aE`EuuNH*IrU49JUbAm-{H`hc(1blsZofqlu z7_c5Ef_+4kDb3fLF+6_xb@)1OnA{WX`QV?AN9-6M61jsb)sT7gteu5bL}tQR^8?FQ zpY0Du&wJCR3eI>Ex8<}hew{PU4z>`4=w1FT5-=AXg)+*<4#gjG+Ly5;mF|g;Ll_Tt zx^-oHkEF3qZky<8>$rD>k9%^urNhl^ue!X4XAzDByF# zwf5z;yF@BpiXefxSeJf#}JS{vO$GP*x{FoZFQ1MbD&Q4;Dx3siSleM*4-qz1= zG-_Euk@yUC&zwCoaB21p_N+2qWQkl*3}pK3D%dvT&k{*=>QLKlK6KFhJ=Sj>WZKV^ zxq7kfeMR{Tb1;K!xX`S9+*?2K&-q?w8%$p0KlHBp_F~46E}p)^!;haM2+mfCD2rsm7#9JTRwwA`^XoYSygaqP+?3z+T; zEO|fQf2l7IX#x2iw1xN=c{w@5RDpYmfaYIj+Z)X zDs_JR655R4T%Y&fA-Co-J_F$&OX!M@&#ZfV9rpe~snZhQt%c5xaF1!~(MZ>P5`3V( zgEA=sgQlK(j73kcuYa7*^XS=PknJbn^d_21@H$hb)wq41Jbu^j?Uzjv+c#fG4Cgad z5u12A-)_1&0B{~OM10Hg`r@J>0ta+&NMbZ~CT_=*CGNYj>QvLRb8Yg&0`($rRPWp8 zCL%b7_syP5J@#Ecz3uRHasv!Iaj9DI84Yo2GEm4ODt)iZ-^GALXDasrFf8|@e2Me- z<^=YT2d}-2ujrQVM=FxeYvb{_*3y_7MDEzH?Q~}M5Bjkv&95Yfm*rq@CC6|6Jea}p z8^h@?%<}K0ljsLrg^)BBg;+=vrFQt8J_o<94afxVT&`g+^doeh3ZFmZXqmUCJ~xp2 z$ct{{a@XH@ASXkr4t}$9KW+6=<@C|pOHHS<)%ezVADV;=K$t$tX_arAwwzB`!B}ss z`OTuLa>6e0hULB{VZx1GLq(grmhG?!k5ZuqE@9tsufx_L-@K8%m7sHd_+uzAlM#S% zoRZ&6_C|!euD_=NA))a6R_wm*4i-79^yAfod@?_7^OrA8{m7CL2);u?IM}>CiXW#D zT!RQX>Y<=9c+{-b#qWyll$dPwCE)MkjMsVofzGloP_c~Gh5N9hODlyMq&N7^!Fj#w9f(?3#0byqd3BXGds9UZJ=i}@#yZF2_F>i$D+)knF1~M z_z5~1MH%bV0Sk~sivhvuUF!3dnaJB)5eZ^TNF_QV^>hoOH)jCtRye^~-H&%p+U~nx zR%oHxoR4s6;WZ|C$sUfu`Tcvostt}>am6h>0C@H(C$hHqBPW1m_I*3S1HOyVDuE%( z;=}nuj*ie=ze$}Xm;!&Zpd2_qZX2aG(l~is{@@=N&*N_DP!)qGKRb^RPw$7=`z-j$ zVs3OIX85d@QOG`G~a)1N$)57^wKb^=Fl`qX!Lh-1uK zPyJpZ*sAsyof@nqu88F3XlJhre(=4u$3h5Q40`eJ)Gj*|RjlArkw>>y5)8^(n8^U% z!a_UJ^%>$)0>6BJKzl=Hwby>(J$R+cr`G17qmtshvj)Z|tn3?EM$)XhT-1G|QT8|K zD))#h*|+G7HK>r&=E-jNGA@1eg#57tc)77E2aa9b=`$xizuYcJ6y)b|f4O$zBkPRAXK~EJecRsK zQN~30j9}^Ek|o2oBg@jZ3QR> zL&C;s^iCb3rp&XU>dzP8&RpSQvgoiG%b%Z{!F7h+v{j?CR_~|5e$mX@`*IEY3jp_f zjY{szA-+95N(P@~1!%X$)Knln0kSV*VzspB>h@QSL*j!uoEJad8i&N=lkTnaMMB^N5Pzf{M;A|v5 z44}ac-RVhBxPl0|n4@yW7ssm$X!=FAn+yozUX(r%<(+=t>hMt_N4M&I#3yL`qd5Cx zmm4O&c|)F-$j6nFea53(dlL=c zHh7G}7QTx?2;{kSU(!1Qf7Ku+gPT{-TEJjmitoJs#9l$m9 zFWHOwyVJj35IK3^(jV~+!~g9|JjsvLRpJ>FU$e3oiaV|WKmLn7zBWe)@DEF8>`$Fw zj_BmSnEL?l+O1gmlf|X%bl#V!*Zw&+^$YTrCsabH%VhbgCi$I5eAV{8$1?y{`;P8; zEKC+W!2C$|(AtPvB0`4(t8f3LCNKcza^JMNiXHqrh@j)C|@BW!J&a6%MIJJV+A2k_{P42jbnh$S%uh*)7fj? z5-lFu+-ht`$(#*7vT`W5)|pa)I6VanfZauCAP9B^a%ny1nrKleVg$OlodcF65)aY(f$ZKNsp zYrWnt&QaJm=zYwuszlSz`+h`R?qr2b*UMXN={5KB=)FIn z&VR9Chv!2%Vk`z$)%;u$2+T2qHD&zasi}l!50Wn>S0P2vn6Pa3W;7a?#LWmrFxG81}q;$yRH0l|EQ=QG4KaWIfyZm3R{*JPCh*- zwxbh2n9wH06Cskv#Q zow%@dXx1mH&dwT*DXPHL;>GLreg~giS=+saIXvcbhj-{lv^64q=Y7}6Gy5^DGU3l( zpkg`cD+{JKQsR=UB;7rOAn&&jlh5bbc1(G?)sgZdhxfro{1z%pIYeKiq22(hrcWM$ z5t>yjWBgvgx?1*`0ByvJ5|dnWzGjTcP$#tTf4ywef{h@0R+xkKJQS`a*jwR-pAhtT zQNc5^O9M|##tbaYaNDF$x>$W5p7HZ@1rWahxO-Qp3hhR@I&6m&pHTbaBv8s zdB>8&6Yq%1C&hj!)RM1Z_iokjX_Qh4cpP;B&}s2r0s&&+r;bv#Mmj@`z~^Zsnuf zzfgIUnt;-f@yPvd8e%&4r+7W!0xAISq29=cqQ$c7GXsBoZe&Jp*5_G|kJ)fi6jj~6 zY(591!iDpR@j1J=pI;a(2-Wx4Y`^S^fhKGFmlPXp1avU6MXpRWkMcvY^3s$luX3#X z>v&Xr+ST&M3L}zcjzaT38m9o!^~~=WB5mxIKMvSc8@~|GEZwhO$?40erFy#7Hf7$( z*v;!>wt@wli)oZ7(@4O$hZ-A2PR$=ih}_Et^PdWpICciAcK^u%EY72~e{eX;^~dU^ zx9>zjR`NMqK{(V4!VsdQ0*=LGzDRmPYATnCpwS98Ot|j0H1S}kSwGxa)S%G&J^L^` zmtPHL_9fcbkC4Ta;=a}?!h(s1Q6dJZd+-r*R!f}=+}e@J-v4@<1bnNFs~W|Bot1ri zuQODqyuINqS1adGS3Qj4bFdT;W_=NlqY|Y8CmRDrn7=gtQQ@>t}^Z8q8M}|T6nmo7~SlH7h!W=q=C-0|S z_DKsA1-K)8kyBN-a>N-OP;%K9$}&z3(zwS-e@548j$y%el=T*0hN{(o`@9c-ihy2q zJ-a{Z9J^td?UAt=&fYT;noZsUNvM|Mbi9A@0AVvENF{)5e+ZlaAR6$kFR&LMQ8W6E z^L!ch!x6#`T9cBm#oO!6es0PKujoM*QkPwLi-D_6=?0@#vLs)pTs51XZDMd#s@0~Yhg9&!{Mtu*c(d7yDHW$fvb&R;J;>gYV`pr8n|d< zyg#Cwk^bU_$5?9E-}aL^EI)x<$S82KeS`3>&2k!*3hI3k!2<;*Ug|e{90Q)xtEdz) zN!CW*K}cH-GyaGT#$w99DXbDf^ zzPuCW@^XQ@{>z`9Hkd5Es#5#?m8-M<_;s#MTyOu>pU;*>YzhGigd*;b*R>Vyz=juHEF| z`Mi-`S37}P+8FD*w;m-@9VK(KZ;#hz{>=2i2~`w=I+v^VTc`aLNFf*O}&DWXA(dwEXAUIi$R5A`6XMdn{j zO1K+yNZ+p^kb;@rPu(Zk%b}%O(zR2xY-adediVIXLmoQAIl))>^LE>c^e5+$GU?@Y zLVNfx8hQ}|@;ipdY1k;m|Dy#D4M@QgY+y|QIA^cr>=k;$j~wd--%$|wG}&`ZFG^%P z1kMKYcPd)ZOL8>SJ(gCM8wg-P&{~|p8OwncTH0@#RyxbM88ZaoCLjWNI2>jAVzdRY zAvE%-&WG0mk}^?zfP!?&BFqW)U9ic6_^LY4ISQ^5@+SvJ0Tk^SKBo~bC&!jnx)|Ye z;EeMs;vEx|kt3!fkk-t-w!2K6-eT-4#>sScqNIF^j2rnxe=0!$5xF?4l-AyfQHW|k z6%WHpZP^bOtS#VXE>e`)(^8qR#-F;?K|sQpeQaZ`p2KyVWiPQ`WUauqLw}L#WY9wM zDt@PH-f~2q)-+J+S{^h$jX84MAm+Ckzzmw?`!(eF7PS0wMM^$>lQtp_a0 zO>7*-q4u_}i|yP_7^ndB54#+~H)4~kTB322^}(-w*CVGw>E4Cy`z91v2~D;<2uQCK zb?^SNuciF4=$q!WIu3Rw6PDBG?HJElI&>r$1RpXw0G>Nvh7WV(A4`IcFWv^SG#G4O ze&V^(Z|k;K9oS(w9xtyZ6JPIv7T{a)gSu$vH}C&isy6QrWHsy`Nm!np%fp9sS^MtW zf*6V9+kKS~EQTN@H95$a50`t3`rh}j7bc7*o?x>```l-m}*i{gHY@Aa9}3qT-dsp<2Ed+g73(%$_btBoikP^8LUFsn+7 z7#_3^fX#g=rQy&5dUv6YQMcs#3l8oMRwtbD59xM3?pNaz-wcfSUUjG6Q=0{(;XZ+2KJ#O*VGi@N|4wDTIGji~eJo}B%So(Arx)FgYex=D=2|BtQOiaNL7*GM za%!IEPq1x{L);-4Y5d}P9rv^KruIm%DE${ToiVtd(8)^o_Wkv_@7c>}TuhU9Vpr*Y z3D)pBXZtv%CBmv3S1^_8qzh7qJee-WM!_@?(z&m*Kgfg;B7-BxKg#sY`=$3Ij@~9| zUOfK`OJw|#O$dZDe?=BAs8o2Y4I2|V>%oP%b?w1Q=9^=)k4d?|qo;8bS|}ba-j$B0 zyUigypiB1KYZt%j=BlUCHaWvFSOS!CFP>bZUMePSW<}g~rz3StkZlslzQj;A9*frC zZR)=LQ#Ou0VLX64V@*}~6dO)&S5v0mp59u0>U5kQ0^OGNULpyNmdD@y~`PW#R&2_w7Goc{G<>iZdfwYMDGCA2|-*zLFJUe(0 zy?v&^)$5TFPDr2Vfjk-MbdB08QhlzZe(#)^S%GfSi`4GV|^X zrBE6-4Y?vG%&|*sy?)vRKgXriTRokY+;mv?gX#77 zVqi~FH=NivY%uqe+NP}gqYDRG?x91^1Alox#x$miD(aHUhkg`C{#H!5<=3r1C@jr) zap8SdpTBW*T)TT!e75~F>H%5T5joQx&H>a1lPC8%$L>Q(lV%w)sO9`;6aYd+ zKoE&c^`#Sdbs!iYpoM0_}d#gJk3{5;=7%x5CpW(iyH9~iR7%=iKed4}8&8iK> zgGLUjMNyJ~agKii*2ge#>!N88P3GP}1L^u=Xv(%`}WCdRhNG!Ntq zh2KtqzB0siN$%;>W*?g}DJ^3@yM++H&)EkxvR7#(@aiED1*}tH8wN zWIGRER!}xy=B~6Tq=XQmdx@~okuZkUqn3Y;)=u&rojdc`H4}_EH2p0hp(KD7N-YOmtKV1>GG_P`tBhG()2ne3 z?khn5xhvoY-qvKR)@6Tt#ZLdVq#Vhs{4x<>Hs6?bfdXPDU1`=9Z^4vj z7>#K1Y50m`bJ8716)YU5@~^NC!=+MveZ>2GS^4F-Rks>c{^0GG@Y!#D zr1DmPMV^_K4p{XG6~Zi>=Rsq>fQ@?QITXK+O}{wX{NRm7gS0SPB=Aa)H{YOc-WP`PCFk7w z$U2}@UbJU2o9ekkMp1JN!xf@+oEx3zw~KcwoN-y0e)iw*1`u_rqdF#ft?*og8xXw| zl`TPxd@c8cZ8K28#jg=taI=g4<4Er{MfoLbWO5w}=)$hWw{jb=oNFV>?$5n-0Frmj zxvVRa^pgT62{Vw<@?&^8$L%03{zU~@X5Mn$ z5k=t9lqbCyOb~?|n(y0}#S}t+o(WhXBLsl0$jqUDAKfQ^7V(U@ z6fkqTI8>%7kR3xcNU&bf84c*tk2ZILGKFHGc8zg&X?X^YqEuV|LSmo#h!mZ1slNZn zL?|%w~$_zV|Q(}?;!13nXepZE4}AP=BS z7L$9sK-w64U@JNiceOpV9zeN%p8OXmJF0I4PeE&&8n;Go-_$kkU?fD?JSzV98+d*D zC8+a2-n%hPSjctu=XWRG(h!jZSM7(g6@gb%@yD~!y*K|ULcR1v%GO{|eud2mMw5mB$<{Y;$q~#W$z#2c%lO# zHpWn515;H3HliSv!g0&sj`h7X9$B{sgM)PgQL0Y{cJ+CZYu0PM!2>>l!=>O;$;yCD zgxeQeL5_CG^Ps&Dd+>{B!z|WMa^dN8tiVjjQfQg@?BHQ7gm`x7WIamua_3O3`^W7a z4n|jHHDkRCGN?XP#T+?=2|>bDNonQF?hQy-{he?SF2fKqgNA-Jq~kF&OhuyhqLxn$ z@!ozBy;EmvY4%$->%6f>J-t8XkXz?bS|}H^*`aoD*^lfKhe#3ITSXF`SlyT-HqRJ{8rHR$~vCVxyw_g%=5#Mv^f!jYkDOD9w`ODrLE`J@R7 zaSzxs+V0zS{zME4mzz8V`_ccvf5{-80;0fYA;Sm1iL(X4K=euIV{!2W?s|Hw0zpF4 z4X48O^?q`XG|jcWroE<4?RIa%3xdil?rF=R?zdV|OyLOFIwVHA-GzT^(pSj&w%7}1 zDLkEJzgRKpI7z=An2YaH_SX5X1~`*XNK-%EACH&zy;j?E^l<2|NIcXb<@aPB05#p6 zq#uW!flwvmxpg%Owkq`jgD-`&iu3UyImwa+%7a#aRaW$h07bvX3jlfuRl$cJZ)k2x zlD&Q02gsb(>qywI)4^gdW5_HI*6dJOU(@?}k-D#qYA=-wv8Mina@e zjE!Ay-QreDQZY89sQSyR%g;ckFC3FFCT-!32{xn<@oRilxeAF7;wm;}9MWu>mKay1 zT2!|g_)?HiY}tmG(NKnlR3VK{XNSzxE@>b_%UMZ){QJs!@zpVArRd@)D(0b@tDM?} z^D!_E#$q4h@1&mU-+n+YhOWJC}2M4Ba1$H(;zlhe^YpaK4Qo zbzz*4WR3+LTOfQtr=`1U6)fm5frHBXqi{kf9NyO{UY>S4&RX6}1!yMma=lykP^|Zn zJT6%pHoKSmec&(Mm(QWJ0;X{}YKru@WU=Vou=varXQ}a9e?)0c!n;{_kGt6D9)zh4 z(;t-YSoiYr3)m7@>-t$Q<2<&nb8s?=pST~lRoCd4?Q32)=#s@E!tV#X%cS1S6)Wy| zfXAbFM)lPy3K7I+>-#(rOKY5)Uv8Rnfvb|u@tInh*K+AudM74zW4)JAIM@$wQw<# zC^R$jnQ4L5(kkJmFJfPMa)db?U}?ev(pUK(aOecvaITT#H@3 zb9(73qLgk(155lFQF7r?=^WPGm!U1zJCqUnv9%Q^=4ASCNuLNvJzkzzQX#Tzn)r!y z`4(f%^XY=#lZmX>>_f}@LAYNE>(~>^VKy|H$K}I26Hnkv2cqAPYZs3Ykln%%NEh@F zJ#ab}SDO9U+6PK&y3)ARrQ&nDJPwq|A^>a}eCaAgIW+NK?aWQ&=Y}+`ddQxZvG3;h z<@M-TQ6E{DW~?tLUhz?*YUEKFKuJmH9}i%1>fSUd`8fDLeJ=HMMgk^}fSQGeg?(btQ@X!KP7e2^b}c;Io}USm z=PLW%vW4?jMtDv4@nXFBO5HEsO0yqV+YS(sWwxyN_Kwd^=3t)adU@GAsWnI#Z%@GZ zBW^44KyP_2OXDLP6}Pj!h{kAnKW6YRh?5nk@B=SfR314LAvjLI0^6Ky#12fJ`zNB% zVsuOwe;8LrF=BkOemPNLO|kpi|5~_*b2|ic)p_39`Q4=j)eAdm`xo}=)`w6rp4I63 z+n?_8Ch_-!Au*xn_N%g);BfCVg(ObjOX72vIc}azd%&$m>`}bk1&9sdC@c@CDikPD z_Fkd-JiYBNlmSV=@jcz8(!6>Px;fM&(YRhFvFCRMcT`S+?hvi zAA1OqJ-{#qP=T#{lJpp4V6TGhO2nmH#NsdW*V}DmI2LYlNPTV!nH{f>C4PZC=2+O= z3vT%u4hMAg5Zy}Y{2;>l=8Dru*)sJSV%mOXRgpe}U|BGde!|ju-1i7|v3D4Rn_ZPg zMjosu9I^N|h1*q--@MUB?uoBl1{U`@-#JHnIGsJA!c17W7HL#4Ofg^YK z%)Z9Xn6~#@ooZ&2fnIUl!ql;473QQ@uC|{u_e;K-;dJY;*N`4ZeC*fV$>fwjKQIe& zZVsMOagh*_c-5sBksQ+-F*Mj6@1QKX&Gg`KOi7gB%ehhSR}00P6f->kC#rV7CX`*4 z7s}Qxcf*BTGk8YK&L4AUeKb)rQtn3#hCZm=FZG$mYP0)Mm z%DqD<=&)34>aZ?kdQ@HvVuGzi$h`Cq5h}?kR3u|;#P>JL`ap9Q1UlbOkYin+CvZ24 zKYGWjc@!`>6=o=5101FDFD?7bp&s*Tp=*Yewkl?Qft?m)3NF-%t*eL|<7*!7B?j{6 zt=wc_nvdPSB&|RlK8QP^nlHxl4XE?kxBCgi7M;n{e&;oGuKWMb7qMk%gIEr8#za{f zA#Oy@82H#2a<68O7)o)|zPc&)-Ym?hHM*WG=4HcCT$AoonPZDa&c;qXTfXSPb^Q>q zh`B$W!#qWRdrR(TbL{>8G z%kd3~!t8>Fi07|SJg^859qg9nDBi>ZAoNS0w$eV)cyMYDc}j_(^V3Gv61orF5AInI z71{Yg54O?T@iD}8qC1oDli!RNu01lL+zt3Pw)^kQ2|otzwc%S*`&CH{@Z*CYPsbfT z_w()m0e_GtnvcmkNYB4cMRRc11Lc+QgD2elAaBb@8xOpH-_Kra!?3PVbtlvP<+Wcp zc3rU$_=#v%DZAPOzV)(*-wWf{bjc?Gq2C#LI264d4%`0uBpK=BSbnj1Om@5}0%u22MH4zJFd9agxEqoxgYCmn+GpWp%S%0^n zh;z&S`~2&+r=dd&Ljm^8k!*q`S02Aui3KPNWOjd(@aM2!7Vu}^EfsIXs5@6GH1?0I z7>UI47lFLqB>m3jrn8Q5GHWk~MmJ3{fPjfk<5b({>Og!7JqfNthhX~Uir%@(mn3{A zh<4hpmh(IEa6uq}3f_Woc{fWhtCz!%q_byz`Qou)Mb6%k%>j`>ZP=&bb?z4^|INSM zT*#BBM{w`oU85Q!Ks1a7MgsHy!#J9x=X`f!Iy=BRe{$`$-bF znD{b4tm5JTPTAj66k3_V;3gfFFY4}EO2%6PkXTBQnES@ZvEf+aPagNS-dR`Cn zF}Z#ts7`Vhpwt_R?NoHpGtgPlo=mNhnd%ka#21dwhTo5|O}bDfS`4drGwrB2eijMm zO>JXIcn3#{V&41CqdiP*j@Abx-8D;-`=X)$zN$)})q`*VTk%?l zg$-&xqx8J`dZG$}2bR9?Crtj0KHNJ~hIBv3Go%?E@nYH(K?E$Ax=tK{eai34A|J4h zP!F&1Z*gO<+!t>*!~?`s`nBEr`L-3~GQ=DpSZZ|GuN5zgI|EktUbLs**m*$5)jhr+ zOJR*BF~)(!?zODl4sr0>u>dkF{^%?>RFZ`Ta9`tJ?Pa-1cirw`K!IO!qu3w5%{M+f z&sWtl_uaoh-uj+qM3^s&+)BBx#mw=A@F9Ad}Q#0~|Fu}sd_Ds4oCi@e#2Jwef=xPLVH5vhh?O7#r(>YC;+Ujc1^(BV$$Q7UC|yp?Po&v@v|#K!_3W zjb&2kz-EMe>`XtvKYS;OUmAx4((N^8yvw4R2xVxB0I1@ocW}3-@*#?e{-T0tdY@G) zb=1f6Z<)0*!9v1trbWy5re6MduL=_+E^E5$i@!`JgaP>-xTz&a8;FxQkOp`2r(lVb z%RhfF;7(ii^^c_U+Ex?@qUbN7Da3|~KoJ8R9F8}uS#(_LLvXCL`^ z7_uI}-Y2lLAY>RJBFySpBR7CIpia_HquEl9V{DjMycPUweMCFSeoH*d7guQaO)TO- zD=n?dnOT(z^r-hYu46@Vytzl4Gek(*nsREj#meO^*k3Dnuy78*3{A(0ai^ncVYBN( zSrqkRP|+9i>%z&!U9s)6-Z0Bwllw1LWj!uLlX+A3?#FCX*iyqWtWxjYesMmJdt+*7 zU5sR;|COF=6CggRkeh`!RMbBq;tWO&bq)%JVS2Di=wBH3c#_npjr#s{t>nY#oZH(j z{@w@DZzw(A`NEmkhGxsT`>(R59cV%4V<3g%rteql*ShX@GLVYN+{@ijZ_5u-;kvQU z<+(wIeJ*TR46U^G@ZYguSOn@HQvUQ=E@CYz&|6VBz!TBUh z$Vb6|+NDlo6)9$Ys<)#icP?i^g0)Qt`ntz5Ma_Xkb0~!j-80?>;v9cVlkH=-jh7Dr%C8)yXBW(-)+*84)z)sZpO0Ry` zA||Le2rU1u3`(lnk@#E{&>KmHHHWbNKJc+Hx8mWlG|QErQ&Z)j{llLYCs7DfW!)X* zyTrA)Cd~@&$nJTf{HeF+N+lnRE${*C8$IfiE|l`zgNX!AH~!Lx#^T$?Ti4IS;Oz_K zvW)8qc(${&T4V<*`6FpSu!si3(z^{eRpTu{*C!z9tqB}%H0)3fbjAm2i ze6Au>zhOa8U~1^XeNIFe^C`|5#fvs1^N9A8;xs9Q^e!HJ|BQdj+0>+`$9bCfWYM2h zoF%vCp6Fhy!}ynMWNZod&)_hc^Gvu`q>!tl)zJ&)KIUr|I4a-d1&^+DwD~+T#*lkU zx3d)~SEG{eU|PkT(K0Og{3(LG!!^Y#CQ9g^0_-gm5Ym_w4sWNvC+E@tH_75byODUQ za{D9LYWqdO-_$}4l;#Oop)(A3Uf+Zs!nr9|sxHZ}f4PyIJc?eA76@6O8 zc9`mO1TR;VRLSTq%6Uikh9jYL^(MTc*!zx^vqq!YM<_NLwvE`d48Ebi_nXE;gZ9Id z_c=h#@{28T3ew&@fAL#CY)Q=yV@qY@-@&*q4YKWzH!`D#mwRA;Fb;*XekG=k+}Em; zZkSxKu!yWI9pMMCyxJ{4K4sOrVWofX*QtmO-)j9rU*3QFjm)&ODqPAJY`*;XaFzgA zun=4DujX(VUh|JGx;wk1=h$i;PK^1(B!W@QF}j|f@u6G+KgUaE+ZkLyCz4aiN4EM_ z>W9B9Mz;sz;R7t>OGws-(d^*%AnOlbtj~b=Kv*_yEmU_ zQWJ|WOu}*T#1mxz!F%s+L9J2984oQO%yZGM5`EBPIJ{-zU=&s#UV2kc@*UzXo{1+0 zpQxDoV4vY}SX8p&lLc4HGMB}l+kTs#s+~tYJ6~Dj-*d{?G!*8<6IMJ8-y1c&(|qMW#;o;D?ge zd`^up=N~3T?dIePFJsvj=kY<-9SV8a$HYuNXO!(|Rh)RJfDnY5?@twpAvlEu2rW@e zt-Ki&C_Szq+?I(J-Y12Q`K&#ydiVtPk}^_BlAVib+xrk^Y^LcCk%az@V%UE!%@h1+ zluy9>Lhubpx@oMmfC^R*LrSEe1jV_1ople~wuFZpq`gtCg0_>O*;EV&|ESBk*ZCL- zDX0vm{uVXDOmW(kv<{3XR9$d`>xE~i*Qdy+XZ656-@<8Mwkj2#iVfGp%gS9|30^3v z@ln`Fo`Q8cD-WAr)>{GICZTGx-)u&IHPU>VDMq(HMekRkL<@JVzoEcxLqSP{*lS|l zJk-a88lM2J#2u&XJ z0|Z-&vwh>!u_B-7CM3r5yJsYT3+h>)^TtYUtW7ORWi>L0MMw5ry{95dwp+``O4|R6LdbLM0>D()GX7W>LJRkAt z`OdqBCWm|Qe5fzFgZ?9S=MFXN?@C$$bQ{;YTUva|j@HaHERU+lmyeMy1^0&XP2W9Qi}x(X zi!MmLL;K`VBe`6-#dptU1ZOy2*2swUU-qr^$J}gIbVg^~``4=~0XmH9{Dig|K>^{> zQ{x$9`My+W9{Hi+BuUaEEN=m4qC%bZj?XhJ;)Ag932mygoF5&jX5NP-c4VYbMg4X; z^Y{S1^sSDTb~;IWoT61&2t;HE73~WUg8W9_cV?jB75B@@YGQao9~>s506T#*x~mYl zUoKE~(lT=M52cao`fgq*IJi4KeF;@suPh2qsPKmJ)eaXxgnP~nJ$d+U7IqUH(GSIx z0~_}#jg_nV(x)wgg?wAGfB*b7BJZ|yVuoILPDnlOVA2hzsOuFBqy9488@(Vm;@SLd z6p?*Mp)Zl5Nr9c2!Ebzd=!_qx0dw^Cn=eAw_)-5>+w4&9b`5gqncJuNHSELDFKn;RjQcZ$+vRNgWLKU^!Rf0pgoM9<2-;}Qw=K(( zH@bUTJ~}?+u%MzHV+kJ$qT4TTo%8$Ke?!uha5JUVBoyzauG&YGw}+R-$e5H5(aFlj z=+R)#7OPd&q3^TA-Hj2H_4+1Rn%iA~z=t;1%r)}u^qy9ye@fiXz9YOPiIbQ6MBbFC z(_-1#{M*M}F4rd&q}C!Q@^$%Woja{pxFg$}AHd=CXtW=P?;eoB1ig!`w}@hXmz4FZ zIa*g*2EGSLp=)2LO+QRPnK-OF;x(My*n>g3ZeVP7ux4WnuGE(tyb&qEyF~g)gF*GD zGF|SigJj=d*28kzLx85^y<_FuY$Db(alMOYn4X6DTswx)V&)LRU?T~1aYIWY)621j ze_T0VS(gv?7d^T4xA_*VeMz5tti-};dgMQou&*mlkhjYuK4FG^*(fE@V33)Py#;G1 zj4Euj#Col?4;q<1MGDh8$q!%EaT(_yQ4#XRC`lv>@kFA{+nqc≀SQF zJG*nQ@9VgKaEZb6Hw4lNQ6}?PJGXrb%;T1k@u04+X$&+t51&%I^<@6|B=%uVOQ^Nt z@e`h|HfS8Q?@UVr3{=Qvcqr0Pkf7IE(au9=@C?H<(H%AUUV6xb8-)P1|CJE_7!8>d zRUT4%G!`b?xRUt~@QM1Yf0ttVSbMxN>z5q8=^q`vx#Hb(Gb$*a4u4UeSD8Rp-#3}J zFJx^wxj}J$R!T)(qE;JJMDu{Gc@CoLgT@rJ&P6u?lB?pkFqYi5OpAM4Gz^j!H9$uX z8&e!oiFC7KzvrtW2+GXi+9Q0d_w@XF69tM>*yIsrx8&KNMKBr;FVa2JM|KYK-~PF4 zu*c|&`&?gG0Fuojk_I+k(ZWPe+tu@SW4+p|}z zlJF$=sulal)!TDK^i^!ReetCp3)p-4(|_6XEsTC_*-`J`#(fPy+Vz7fu>{kH=W@ss zRF~KZq3AV@UH^HsEW!y~>$XQiWbu4E2;UXtrJy0w#XZA>QmgYJMVU!+Gu$7b_gUe< zYS&2^6}Hgrzo4dJ`?01A+79&!W=qYlF5xt5tR6B2=t#GjJ5s6HXTlbg+ye(ID8dc8 za2I}d1q&tm*j}j~p)=6aK0+$Y1w((biXhi>Q*T+0pq)>8=2V!ZYB@#3(#K zw(WR%T}6^2#|tZM53vKx*S=*}?Sz}=ug>i^A^GGntp--vW-(fa%pXNK`Y^GykQ!tH)oUpQ3c665APYjzBbOvzC={SA&y+OAKKTd7} zEoZ8&myP^W5(h?H!4KZil1c&P-5H)MrLfNg9qN%7o4S&B#Z zh%}@|j=P`@`PSjW$G+DaK+2>ko2MZ!qFjF%~K=|vdcKx`J63rK3}_*-S4mH9GT+j@IErp3)Xc8U-ia#;LuNr^DCo02Q0c5 zX&sY40!?%uR&tx&F@y#}bB~9yBZl9&YCa~Br0X`(QwF`k;jqu=_tUR%ZDq=S zVbOSdK#S+b(5l41T8t^06@kZDAyYl62f&2!_zgHQF0b z71%5ndw)Tslz0GzqUIIw9}8j+pR<`=UfBag1QE(7J?v~PyL^BdI9e%AP)`x8&~?H3n2MlTI+Oa1$SmI zD8hr{a=2gdsa7QmP<9|sf$l2YzVM$MH*#F(iIrg*oDH;Kw!UbQEyLQftq7b3`CQpk z82sHOci~B)Kz7I0oBEND@4nzbAiuPYrHj}+f(k>QIOg$NGah+$_H+XoHHBd(1}LBl zcs>33IsmdHZ_ieINUzgLPp+sc!J^R%tmJe-tgGY~Doj~2ydK6#NA-wpOhcJ$8@>do z+K`)HwKr){9*4997o%VN=MW}rK9}LVx(TI!$ZzMKw7d>P_i0AjEL7=}o?3-Gmp`Fw z)|@dP>^sAT095d8H19}jp%Hgq&kr!MdR#}(AE18o>>~nWMNcuz!~!gh2buBx|;eM^$a z3vGHpiw2?-klfZi6RlA02_M4YBgeD(E892e|Bg|k!zO#+nWYD!TJ^J#DycTU>aWDC z36^h96OJ$&(NMlVM-I~lepV{5=Ol>}L$z5xopW)%;n~J~Ck7Q+KQqeG1!bLYBtIJ; zY?F;@dn|wBmSnBxx=&+x?lg`E--|YxnO;BWm6OxlvqWbv{r5pgDL8WF_UU`f0qt9C z)o%@lOL9>6EUQ3Y`12pupH`2H@>Lf%lmo6jk89qV1GFXPN9`WLWbtMVf7eMds7LdP zDe9IBhTt5aOnKZ<6nBoL^FWuoH0*&RzZcNaoB+u|OVNb|7&Mk5v@<%lLK61R&{Dps zww{tF1cMhC)+=5CT;TFMV3`)@on5FHeqOtkSKUEKT!h`u2%#oSc(u)&wYSVuY`^Vqdf}8{XkeHl$tya)|KE4 zG#)3<{;Z0>M;6TtG=ArLb-eKg6Nr+uoErLK#qod{h-r(k2a3qzs|y8zuupx@X~OP zeE^_UF7Mc;9}zN;uFQ8YSfmzMdy{DzE{mx}d-fBnD17b31FEVngXNB|9JWkTxxqe3 ztbKc$TGoiTd@&!63+;&>mHXB!2u1XRI@7G459jG15u=+Lr{#qHv(P7R5?anR?Ot6I z<^4ApxDF{T#WC=wDeIlST!W|BL&vMc(6rxKZN|e`Z(Gfpql#~(8`%8KI&+{ z&}>bz`;CYCoB{jX?IkyEWxvoJ*2gap_055tJf)NC3651pdK?^^lW7{>kHQ&NKuP-q z{|f5B<1R~3@^<@r%}?~z7QTM2(dm3h1$0%{Y0#qR!6y$< zNGD+dR*sQ%pV5PN`UxCz6TJCGtI)Jq0e!f^HFjT_pFQ<$Yw>fBXYu;Z3RE1rVPjA9 z%0G#S8rYJd7-7Cd=d_iJpLTKN>71X6#5=!IT7ZsuoUW(0%n}+q-4Gk2Ps?hSf!dg? zx?|HwT6ap3+2b+@5+z(O(98}$dF1cKop?{*RR5ZBW}s9h8=nQ{Bh%inr<>Bx|8Wed-#(THMU(s3ZqUF8$7NwWV_36ZdJ3x+ zDa^s;0R`5ok7IQL+Mf^3Z9lceBX01z;NqT@>+_YbA@DeP;L`tY50p)k6D=FoSptv# zK^=}7ELrj%=N6RYzN@K2e6|Zkey`1Lz=2{me1=B}u0C&1_`;3Bm&^NcX#)Q24-d3D z1bEW%$No_RBw*@!^h3KZ;5^JVv(9P{?#LQ5)bNopQ;2-G`m^;p3Wvd~g`0I`5x8Qs4~@&&e!Eu2?Q^=`M#GEd@EtEblI`;APj$=9 zgKVXf>_@0AY51HJZ))Gs6WO}8m@(sMOmr2JuXEEbEyXxA4!YlZtO5F&hk#G@2$tHm zkY?!qAjo6jiY(er-P{Y%H*1d6vN+h$6b9 zt)G0b;mfY51cCI;efC}qt(|U0a0-gmgh50^tFR3w(E$d8)*X13Q|Ybhe7o>1by94h z9Wwej8A~2ipcllznjHM*yoYYNaUIL@XogRigRQV!d}*QhIWW9%MFVc2LicfB-OY)= zqT2oO!-`{C-0E>(NN+WHV4h6}Lz_mqcb_J;>?p98qoi5Am+oi)1-RjGbEcIF2zOs! zz;F9@2V!5EMNF@I`-Lb|T~!cnsRO*UUL}1Ni@r1X4_OBS|18$SB;)u-CPSfyZ}!=Smfg<( ze0+Fj;-^JGGJd=+EE??B?eX}^qxS#}2E8EM6~Uoyh9IF4zpz=D$Kk}ET5O4!bX*g= z?w+rEkjd@qr|NLeFsAWsz%aF#o#=dS+?#wo^~XkdO?aL3vz!5W*(&{TCSONGg1P1C z3No^?)P(kt-{b9Jw^#0>XmCZJig%J@cdFc>?2MIjxOT?hN&RMz3i&t^M#eLHrL>}PIa9*(5 zFD=p;oekQjJ6WYnNI0JKg`Bd(^VSpSDHP%rlJRV#eE9kO+mm^ThNBLf;tv)Bq`nz%`GqIAPYA<=ao!`-s zk)>OVj6Is)9#`i*t`mK*efEbIaZ8FSW}?DYA~6ge>J^FG(}Vt9ZUOR^NzzS{`-Wo? z{Hm$AhKB;pko)z5-NkW}06D4g!$lC|@!^axI>dDp@4xIQxi9cX*W&$xo|cpc|19ru zoBHt|198PbRfKaspB_0O%7Yo4!;`x0A=ns^=m9|BHNrH(f`!V7R#1!C7AzS`Fz$w< z3Rk%=7bsnNhBusaQ9@=IsK~gq{wEMNrMENFdbt-KM z`ykkU2DQJ|m!vzykp~GX2=1~&Qrgy@fq3G!LH=Q>Ll8&b9L9bdLASrxWIuXA;`))> z=-B+lBl4$r1%gE@;Y3RZuWca1eSm{k2?Wi!HA(@25l9^Dw5706DMo9hzg$~B&CRri z$K!P(Lv%cnVEuVn^m@O*-(`;PKh_^it@M@W#bd{_#B7}Gbz^O+Fy@uVd8jmitHa;6 zlZYV-`*3<~KdvB#P@KOcM6^UQnFU0%Z)jDOlP7mw*9k5-5iupQ|cxntn(~YH-0tTfpS?|nOvJ7~9 zxHX@P#wg5WB%vHH>+|{%zotzE+emyhxWuPEcZA)}xsSaBIvY6%u4k>GnKe6ym#8LT zm$#jM$GCb*c7~=9!&g%fgYcTcyC@24s4gM0Y@W3y`_(gF4=h3Z6=nCmY53ld1AvTo zzR56$#|`b@(-!-$_Khv^R7iJz97j4!E~?YDszQ{^*DOBK+(|n8jhyri%`1>!bE@3d`OEM{Z|oF?fKsy? z=HA=)#KV8JT5rxFxP<$jUW7CNC1l1zsKeZ-x$sfCsbkq+4Tw$-psLdzz$j3gpEu>U zHqJrD;Gd0-CeN!*pe*y(W&@S75$f&sP}?IxR8=aQzrZ){`^r%2x-;K$#f_@N6i={- ziI05Dhwk=9+vOE~haC{=mCihqGbqTJd3{;|`m5g~VI;MCLvwH)f49n`$v$o$zR`U7 zpME_U+V8eelcWWSY1Hra$Bp~NZ%@f}_}SNprOQv)ZdN^`*X3}st1A;ag12Xhi9O#C z{hHi*^GCxux?ZF4fCEEjFuLiDV1u6j^>WO>2f#m-+#k zn*1K$$n3J#EPwa}GmyniL-p4HMhmtVg~z+gMkj_lE4-J=+SobW^Xth2Hg zCjn;XC$MhF08wr!E>Svou^bZHR&y4djB4WoWSMN6-f^x9I_)rzV`u$bTchne9XV3w z=6Bh8n?}<(=ViJ2C$wl_q|qRQ<}_W4GEB5kKD$2?vPDu?;&qRPh3`#hns2_o#zUy7 zRmwFjTy9@mkIj*20P0$kh5gl-IeCK;Nw?cwF}P!ZGPXej$}1V?V`9VjqRsf=N$`Jg zxi>#hHExNMHBT@u@_*%Pj8^nGQ3SO<0AxKdKh|up8G@9sY(IZF@_bO(_Ot}8H(tMO z*6+rP5uAmpu+&o$eT_`og6TenPk1&j2Bi3A*r&utzS;rWx zoI~o64=rZ-6y%m4?T6{B-e*C)FdPJq8&hdb)iDXd$!J;q{{Z`^Cs8rFMSoa7#|fe1 z*`6c+eGkg-ieK+SFhzNqmT>%JRY(?lA_-9%TUF1ZTTJ|PAvZ=ow)~-d`R_2{Q^xwF z-S?#5hWaWsndR$e_)BF&pk@P@+KvRMyL!5&Dcs(Kr;wty4$c#mlWYa&xa@cZo_&1m zOGT0$4p-%@$i^A_GtXi#&n2$C8`8xK$oKj05mHiO65rLZYmo8X%c9!fm&E}l|5%hu zu#cQlfoGIZ=kZm20djYC7syJG`+quzj`io!lw|cA^`+62vqLr$aX(+~`}{o5ZMDDs zD;!P#j^l1V6uw?Um*#v1DqSjR?^@4zjODZ!#$%SY3CXrKu{Tr`*XX_#q2Y0>c^UUB zPQjx!U}Ns1K#NZ?D}6AIl6(k7&KOlNF=Eoc!Z+l!3D8552kpsO@N8?SWZ(PWbWRRA zQ%b|BMY;As(tdqCfqw9^AK%BgUiihz;x;hnADWWHvj_B-VT(?U*6sKCvL}0VNxtkF zE#Y z{o+X5qmTN18SRKW9zzodA3e2E#EYy*{Ijygjg-@@a^P>!0Q6OgzY+gsA-cNFRauTm9_<9>k+K%}265 zQVZE!SBr7L6sznqJ&#L>J^_X?RR;VGt03YrsFqvuIe(ySz2y9fI|*6t+chI_kmOXTe|*M~=)EU0+DiC%Oigo*6A)Q2oNx(#@VrH{ zmi4n^RZtxq!y&sSBe8b`%}jWQXjafFptF ze`}r(y)D-Ywx)jtdG8J|80vKS39GjKjS=xEE)#wwl{77ahzPUGs}DIdyyL#q24c5R0M`aX+R*|8(a7T7mt1*L}~EP4BY%-ou4M8X!@rA|P^?S`ATGM!V6QO2qBZ6e|2vW8 z`6D=h_cJhk<5VHOkc4sLqT~9ah+C(2FZeFvq8@1|Lyw?Lw5rb~=4mp*g}wq`6WU9e zr3^Aj*GH+J!xag4h4#+XI`kN$U>=ftlyj+4_1PunvwAV&ehs;zfUh%w8XRaCOC?|o#%6$)6+IwxihMK z&khJ}a_HMm4;mOnXY^Z>T^^GSdXKA1y#!d`6~>6p=%VwV*LwY${K*On=XB6-?iZ40 zsNl`Ugxjo}PCzK%OSgTRI3pu=FUR6csld%FsQ z#zM}P2yc|6ABm28(?qYpZg3zh{Au)g&M9pEyt}{+JjyVNj4h3Nr9Tf-xDniXQ?jey z^T|_S$@=m|n>z>lWfu+-y4*djDABzfmAOaC-l`cQCGC52i`$)mk4|ZN;;Z8-pM$@G zaaeo?zBU_Fi~c=06T>h^{p33jD9th@YrdCz3#LBK;ExruM*G|zeCLUZ{Z|cD1zK^` zg+)+ar@uULjgOSd>J<>Fm3VmKgCl||*^?ZyH4~ip8P()VJ|OPkjzng{Sm5ndZsm85 zINP;u@b4o(pjr4^9=0A<1GjSaIK7h9U&_W7kJk=$19U&HsR6v+$FjcPVIcN&T4Xix&nW2IMZ|W+F?uTbxy8Q=Avo~`$h94VcEzm!40~^_L zfuJ?v%RQ*Xs1-kO9FSCLEs>do?&`1o6C%T&KIRL$hmlaXBJqm*F$bXV_LarSR|6^HlU#O3TW<40gPTpy*k7#10!({`V-$>d+v zYY}BT&q$VaO{tBDMsFX<`EyYc^H){p@ya~k4T-)|;^_x3$Nez+XCcL@_~RQrKc98; zaav!)n4pwrAU_V*OJ-oLSvAZE%D#h92u22kqWvuBkO3~)*S>l9K{u%?GjBjp*d4~Bd`z^=IMcqEKYDpTIl`gRDRSF zJ%N{n`^sKt3Olu}A<8(gzteo~lh@lp9*^9u!W7Ku+G7k^zkXe0dtb>?WBXjf<>zgm za{*wnrS?&0U+yoqD)#`Sfq`-n>1Q2-Ui^~AEvt~)x>r-)c>@I)>aSs`{Qd)1Aj95( zAYxl#5=_MaZjSDJ*(c>a5u%Km1n?GW#n2L{;2Gci{1tCNtRzo5{p2LQU#5|W@c*kS z5;Pt7mX758d|bnzG=hkzE^fWg9R<=K`$t$O*s62Cpx=H@X(QIX9`;ND{&7WlJTR|{ z)OmQUsm)iir;k^NpZR6l!Wv_{Ika{2eCGKU6&-C$uLDpXvD?L^FZHZ?G!|XNo@4n9}kDJ!O7x6cHN|*+s z&4w3{WkB{i{GlEaOMmYlz_pYI+kFiC?)a{}BbyXsR6;=B?t(b9MhN&Md!H1pB{~f6 zlZO6%)&1Ed^OD#QkE`=|;NB9S z$|PF_9nNMaNSPZ-_rQviBEI1+_tHfgXEupRloaXOnd$VY9<*Cf zN%iyiD=fEr7{GQWEkVJD^OmMt4U9%JAtY2Dh1Y0d-xm0OQibip4f-xr(4SgCFoAVx zf3SXr%ZL5-!V3~a?s-5j6s(2uvi5M9>c=bb!MaS!9EB&W+p&{kTq;2`+{%520T}N4 zQ2MP|4UeCN9Ha;V8>rC?qT?}VaF^nuI!BK>1W4ki^$Qih3HL-7E>$mlOVtuI8wrr5 z-B?KcVkAFjvo@*REe$1Y?4C@fvXlyuc1ej;)T z7Uu`^P+9g!^xVM>AOi5H7;aGxr7bZsM}KDi zK4;rsNZ5sB&V!ZY z`DnlaF2!JD?@Mq@BC~dw!3Dd7#_-35pqAumCG+SuFMj83ZYV5g|c+$}yIBK&;wc#5^+LQeY za3r)g3{d~5)tAg&1j(62NSVzc8lWVtovtkZav|2uA z=0axeWpH8&h=zuJHT@~1eBxW(zJ&Q@e=lxxt8~S>$9s1#yEJ={{Y(xufOKso=3FHH-i~QA;0lu@lb8! z_4|Kh7|nj>*0TfO6CBU$2RoPV;@<9}lZ+lf-qlhu(taf}{-_Q21!wlxxYk z=dAvom%ug*OH-OJff0nH~_xYQX0L;$JjwNg>**OxOTi}A#dm> z(l|cG4_;;Y8@B%MHe1K#c!M)|=TieYKmN*{dhlf->w@~=OVp<<<6ZZX<$k0O?kD=> zYzi6f?dyVdzRywL{1`q*bbOEddb3}#VCh{KU-vofs%8fJ=!|*(g-Xi6Cn7}x`2F%| zTc?wrRPr!Ccln5BUA>SOQ<{h_C%)E}^k@wx?}2+nN?vb$@T23ZZyxi)P}fQ+_%~g= zzqehnh2hj(PWmA@l<`4wUFWFbm)?)j?yvCue^M~P-G)bWRWNfgBRf1SuHHHQzM{?Q#x;BRPgE3tVIrPMb2@C(W#Vt*Uy2(j@9DsLWFroT$#Ia1Y-(mQ{ayC~q#DF$mfht@sB9Xps9mBlzYoO&!VPS6DPmZ~NzjCMx{j?yK=O;=h^$qL=4j z|A-&%$oz$#PwmSHDYOPojFg6Xs2u>STe`E)4kglPBC&K4plBm2IeafrjJowhaCJC zfcbe+5P7PG2M52OWGpWCa=$2NinHB)Ys+D_ReTyBkjS#9W_~;gOzUuc?Sv;!cMion z`|^Q~iPE5q;>Z*3seON3RwegqSmd+HU6T2dA&Sa(bT@vfa;L~Hp^A~iaSu=6n}@qu zK31QakkK{H?UByLJ+iOl@T^HyUrN^nX=^D^Lo&DyZp5CPX!kdsuknxGkLmZnkf$Wa zzDZoZB3YtUD1b2sK`2d5lzwRGE(mA82{K5w^A0{Z7-gHRi5RaeCpBkR+25--6p>T> z(bqDT6a|3_!#%LT9~L<-7TT{i0Kn~iD12%G9p-w6Ol;B<`*q%@Nvz_r5dO_bh*H_FfHXLI*Qqr9-Vn|?R3vNav4l1 z@vTYjXL8(;APVJtl6l{)RKfYpmtGxGr=m}dCTzpoBFPEh%hu(WZ67Ky)l-*U$_5Sz zm&;e>efj~xAr2B&L392qAwHn9GxG{v}Ee7}7`u2qc$IIT4c_v0qx7=1JzP zlj5@`k)p*J1Y)cnLF%?ll3vsHNx~)=IAXDw@v%WLC(^}heZa=M7od9=9lJLcOurs* zod<4IaZHNR$fEF8%ERHFRK3Dl(aTTKtFd|b2swQ&p5+imGA~K$i01U*Zku5eOsGWn zeP}s?L8@j1lT^dGyK;W>g#@@#;SHSQ@4Z&iju976e*6N-e-E~xnF9iqadBSX*DHhX z&3ucOjY-wWB0UdKMng`+HWs(_zZd17~!q9FCB%mEK>4`yxHc#%}YM)463OG5oAo0E_pj-HuG}%$HIR zo8&kUhw4}-5b`HyN7z4Yv=0Q~76QR`MfPG@65RmjJ-7bWctBcg;tOq^#RQ}Js#_g) zafUdRRpk(K1Z?1489x_3aCyemEJYlRp!xY z?B+=%2N%udLpOqNwan^+OHkdhsPNs@RYjDyWutF?eP@2?Acash7)_Dm`QU~X`g0t+ z0dWjR@mM{8m4o$@--G1j_U}!dY{8@p0%H3MSaG}bx>^6`wW5KZ0OX+m+0$c5Y_Dw19M|;82U=TPfM@Mr1Z7FY_0K* z!uSjbW7Vin%{myTYSy;(jz0$L$oG8iF8WfA<$*wB>pmfU;3f4<8!vz7NF1qP<`xGc zkbmhO_<)OcY2NWma%T%`A5s{KVx`f2&od1u?cb7%!3u`MtWW#Cz_6vmGrFecQhqtA zY9gT+mF<(Es9dKMuwbzlKKRMLKv@ATIj>?DPwT8MG^yXe z#?&)SC~1EC3SzPoTF%S6AHsT}6{g|#!H^sH=roPEP?!R5{C*P|hwk{=Ocwqj7?GKu zedLfIt)V%x+m}UN<5k8>lElj;@_~jt!5{U?t`j*~@N0D;is!;HKQ^!(#=!uXfiD!k zk@{86es- zYJ0+DHv*G6h+Dbkd}zXG>;9-5J6avC`Xe$SURuijUeNfc*y2xIQDohA0FDeviK1ll z%ln$_5l?XX`0_hWq~gVO^XFMHsqYb3l$my{Pw%C8l@Js zkgoa{d-V$IB~(HD-8?zgK8@4YItYRA0wkw^j}7f$6D2y=7Or~pDa;CAns3s%w_xN# ze1Ua`9YR7~pD%KMOa3*{;@BQ^BO^-7{ZY*X2rPptw z&#e^-b&x_57WP+t!iKN&WeJHl>M(eY^W{=B<5)N6wy7k|X3i1k(~#KJ6L!UfRC+*8 z`7<2rgVh$;#BR6mA*p*?QqB^83fw!Foa)T+@mFc_D6AXu&N!|)B?Bcpdjuq0n&tbx zjuVIhXvKMAVyek7|4sX)3#MCcqrQ_49I}`CVsPFoKLRw6=IBYU(}u71wL6~JA!2b| zB=4SHAI|&6+Ca6N$IuU_3r-o;j!;>KJgQR@36JnXSM1>qfRK>!$K-w6EjyToT|&jV zUPmkxzu%86Vmv+;!&ATkvPYlQA&^gax#e&n1z>siU}0mvT+coq9LxB7;Qhb?2+$@) z;|n*e_5R{mrUdnROLJ|_wJm|Snez%Xn77q8<%-9Xg^m*c@LgY0KYm9Q_5}|6?sLCg z>$^mu$RFfhg^vYpW-Stz@eR)JWp`9HF8CH9_!0{PmL>ZvUL=FpjfC&1in(=7l&#q( z{1?(Srt7+~IP6hZM1C*25csbQe~OB6>4DQz_$iujliQSM3G4kDbqpV(YJQe}ydJ{D zmb%W?4oPKP&dz)W|M`YCCr| zJZly`#8hZZ!}lz>uBWtEvHKZ?B*ZS_`i+M7ZSZ`fR3C>z_)sv~v$UsFE#Z~a(T~m{ zDB35jx*W-d`0IW^!WLVg9h+IP7Sn=)|2Q2@TShCk?zfZU1ZV;I{OpG-?6bcp9}#9P z^W}DbAK9YgjZL!opvGj4!^rvobrdPlMBxZ?tHP4TLHa6~z%4&Ql z#&jBEs@JPKb`~F_cxm9IX}B4FXNTV3Ho762yYAuE6k|*g1^-Bk6EiZQx~|xocvR`$;?tNa*8NOV z_K&3N+EP^8qQ4|b;8CJTkc{#s3QCe7`RjX9eMjBXRR%=ZVTBoFK+4+N)c5+mk-K$x zEZ%XS);dg(E436a$J4%6?Rt)AefBd~#g`se6P=3Jcj^u&+ITtf@-^S{hY_cP=zwbQ zrA#}v#&;{12LragWw6ho5ApnYyl&r7%f4i%LnOGNxGv;dgy7t5V*tGk&@b3O-5ylJ z-aJS%C;3`UD6Aq8 z|32-wY+c~W6e4-%L`ito7UlfzN5MsRkYHuIF=D7+YY&FvP=@cjV`E0B+ zFZhpCIscUJQTwXpVv|N3BHASXEW%1q-uBr-6pySo#vk@l@SQp+CzQ`gy&zE%;FOL& z{s@68vug-ezm>;~JMKs#kz_um?ajPPy9`O8rOY;#}D|s2T=um)hY4Q_(1%VU+XLH~PQi>c1P6aHAAIsweE|=Jt9~fdr?|S%9w9b7!U*q5RV3TUA?9Mz z0iUuFaW{;UE8Svn4~T~S(_zVsG?TomGF(~bM#}b|Nx^2*a(oiT>xVgY?$0)UQ%oD^ zNv^$&4tTOaf^aH9cT+)P!d2T$(2WEbd)}=i2u(DAKl{S#?K=%Ux^wF=1Y4X#dlCx& zX1O1qmWSrxwbab}pYi;eS>XZ$O!`Gb^_o!|rpeIG;*3N)$}Hh=A>z<@-!DoI$NlR_ zq940L84`cO1HpZMd5+_aI3pDDdjCmHvhpZ9AL&;()R6!*m~`*u=}J)cmkv=dW~A+! zLIyoMp2At+kLW%8PDH5(&fq{{DgB=B_ZF5IZ}ULz!)ZNHWywT>NNrMvAvWfY3-0Z9 zfZflxy0hW*QTXyDJed5Hbp_CpQh+E#*&_7^eM|~?p%%8MRt9kFX!p%cyx4%6)e^r7 z^Q488HXg@)AnqyG=QO7NvCSLmV;P?^enE*89)FR^1lDnYz|X@mmH_}GXu!3a;w#Dn zqO22YMyRpY=T~vamdA1R-0^!I2(caI8=t>)b~);R`%TzCFL%cq<5{=|CWQezRJK11k^}{!wLX}{ZjT>F`4Y|tQ>D$ z-Nh%(iEWU+E2o3m0UG#Zr|lhT+r#j8!4S*OV&AXpw!<2f!%ejsLP@NcmGw;}MX@|@ zi^*pL*E;R-y~q!upWncNFpazx4NDZ{!agoE2hj_>{|5*)T4nrg^S>7V(Xm-A1fK-Q z`Qyv|wDrm0d`e|SCecnEhzP2Hw+T)NLen@dWBic5{Zb!8G9`*dv`Ntjk6vre0n#_2 zOR@y?QFAKlh|G@2cpmT@BA68JoH9|>&D zz%J4y!S)T7JY1{&a&@<#ia19AGm}jqeG+NLx3z7ziL3djXHNck8hSAu6zQ^(y4pY2 z*m!za%LLOe;cEG&LNFbpaL2g_>4knX&V^4hbMtVyi;)^mE_3Ya#)Sz=t<0D5_Pg#Q zu(dh>D7K3of4JWGybjz3*w~*GZ%mLx>@Jh5RBM7_U4Jy>Jrr{XCKG@63t_>boTHEL zJyihU+G&Yaa<;376-BtG#(A~kaTXkEa0E&ZEpniI(1&|bJeIeM5bVnyO}_ks`DAD0 zOlPlMxtzN}t)i^88+lWQ{tK&?{UeROi1%%@PF|O*Sg$5?GhuK?d7rD-(c18fi9JHc z)-hfTdJ}bZK*}8i`l!}9r}j2~cQJb8kNj$)9JW2)+qtZxo}eT(JT3%;Kw|4VDG9mj zItVaxQ`up!JR`fm(~ifYf+~E1ACb{C-+I3%F*ab6U8gEgGOMJY_vfG6o3cke5T4fQ z{29;q{g9WAkp4CUbz|Z|zp8+Tne7Qk3S50Sh8ZaGV{udnVd@|Bv>H>kB(@1IdSBZD zKhF*X;J^C#Ng{-O)LB(})7u#{imhhU?Cavk`hFKG*q4xA4wu0FHLqxUbC5W@08pBA zaw2Y<_W_=z`!;iQX{&L7JaTc{n#*(^niA0kF8eE*{> z%W^{|=AZMGM%(R3K0#CmO=R|M-K`wDfE z#y7OXsaSA-R{R>D4Eb&PVo1@yqiu_bnAA2u$?wPkv3Vl`|Mw#R8xvoUlme51FWP39 ztAwJe8EU}HaKBFb{DG||VER8KaY`M&$@6RUIS%=>Vo@|i_(Xpy4iT!d`ct}c#A9XP zWdS*A3{pixXd?vQ{Brk9>Q+`j%|!_whe6T{)wHE?Uwb8C-xKzKgC}hgH7tZKA0dyW zsJ>Tr^4>nrkvY385}9M0!RdqDMIUJ|ONP{alw@8Mp>QXkq%m~o8igwnR8@RP_)E|6 z-T+0VR~XR0)8Rf?Ou=Rg1j!{%ttRywnQ^bWVINEBZ|arcCT7j{Z-qcl zaaYvuY+A5d*$kEMz(5_*V-vBf_BFs8@A&T&_~s25e_~w7p?+vkXAu_R2=!Ksn7A$uhzk_MF9d+)8Go+Bn8GBlCC%JhPPDBNC0i%6c~z8SxG zR_^DXvc60{xt`*|% zJtaO)xQ#cDGWJf5p%6D?3HA}@EXFYF{c0=Q3zew1u%{L)|8t5z9OM;w_!cEy6YWYcf zZ!qy@IQ6_2uG!^Hu$l7w_>`2tRW4rx)7g`*-~2AgDyHbN^zIikz_cYt{&JtVe7B>l zrtvqoIEiigQrG<>k7QPT+7T=~f}r~NP3^I)#}}tfYxhgiAgvsH%t7u{~WYt^R!9 zq56pzmWoNzAOf*;v1qne4mr&83f(zRwh$DBpKI&4=KY4;Z}ZVT*i{|Ia_ydY@2e}T zMSSQ{zK`syY_yYxj@*^Q3qP5xbCpEzq0#WR?s$kuHE+KMo*?>}zQxC$Gu3H7y=!rU zRz|$<2ZxY4k5m|ww+mk@PEYu(pgJPuof}^;zK2W`WOc~j+aig@U$L3HC0{6=7!bH(AJJ75{3*qjOmic2JMoa8qM`n;xOol z;LMege3~b%-(BbS?|E$Lj!uSa8X>0H&uhH4lzLA1FZ9RuzhQI{{gBo}?_2h|ic!U| zgBNHHy|%ypBxht*6#->J|K@`yvDU-2dFg!(hkO1IntjX|S7&tWn4jSI0sRTw3xSM= z_6-x%%d?n_a8GxsV{(MlkFkB(u>-tSGNI`wzxI%8++QFBLrBP;w<|q_%M1&FNpRn= zb>3szEq_SzZ~bBI5e#P&sxP~}9N-P7*RVhDXV23of?=WWBrFdlM)Fk34K!_RID?$c zEx0HgM-K0}5kgdSUw@{O2u+lqbEdey{*LK|x*rs5hj~HE`7jsn_Wg2t9D5|cS1i)P z#2hyzaF&CL8pXC!H{&Q;tUQTu-P&rpJ;hK_KD8?xtUs%S%P&Bnk)ad;-Hc-)tgKL% zox=5z3v*of+}_1#jfhu6UZc3Iwse}h$Y-K`*dCyJ=)d3R@O$)J8k;6aK48awDe5^D zw}@F*9DSa?`&{xyAa9Ffa&Pm;?I1_5(Q3@^?QuL%C2{;n^9o#!wAT^u_mE`N`r1Ry z(O|^uX|bTHW?$qv-w(w4ozo52{J}+GZ_o%jy?hPUFn9nAx(E6ey1K=3;xs!QSRnT) zr$Gk8yau3QPN+rS?u?yMN2HF*ovge&4BGS7^{5^@VWCJd@<$Cl@b2do0-b@vD0tpkvX1kcf}@u z;jQ`l?ZMdlqqpRK-|BOqrX*iH3}WUl3@yAF=^oUy>Rg%JG%ei~_ZaJl9{rGx`zhup z#>GtRLdrZ(1N_lB*F3xKZ;Zki1{e*Ym$v`l1F|>F=UrPQ0gV^D@6S7-5kKwgyzkLB z?Kp;K^L2lZ+O%vZ7ADo8Gl+N&4hDVRK(TGOb5#MQdlXH6;R8}*eRZ7Q-qnYCpI)wH zPD8b?a$^~xRm1OVN2lF@$x|=s?GCQ&OpDwk?nCx)t#3T~w>Ma{toG}S!U@PtI1T)m zmPjryxy)}_ghVZORc$Ul`YxlPn9!z>oSIOeraO-zffyn&q*M!Ia zPd|;F2H-J0R__po2~YoZ)twq-N*FIEM5A78Kz8c^Dl2QoT9OZ=pWq_eKeqj`8<*Wh ziV!C^XSz=@H^D_$UF5_uYpSh&3T)jqeeU%%)P0jmCo~To`J^ePpUv;XeiGB?A|b*N zh!>i@jw{N7QkjN#nmYncAOQ;M3In^I0RK92zIN81*4Fqs;5`&4g&@_&MU>C3`fKSi zohV|F;E!x!_;;tAErF;t@zOPt+~@6}N2eq7dl>-OvQq6=!BeM7xDf;UdH_;MxXb%_JWGkZ)aY7_<64A6_qaS?F0UB#L1eoU2JI|~ zMAsS4y*jg(OU_XF4bgoDbZm%Ixx)e>=zgh^Yy7-?d~%=4kyI5j6r#f{s7E)KN;s4)^vQ|a;cgJL>a=#TCYR+R<7r7&?_oX`}c%G%0Ia|)}PvsAOPKz5o%^{^4I&oNZ?;w_~P0bn(6?OZM8let8P-=!kSMA&=S z`y@QPif(=tnS6cShT!Uvt=6U$1#3^0J_G)qe$Y`&E{Q&Z3MzmFhf;iyF3)mJRISHL71==K3;TL zhao)PbN`q;oj$2nH%5+5=2XolQ|vxlkARs&{n@9eqra#{U2Y6KJ8^r(1xojxrf%Em zP(Fs~A=O`-!nDTWE*HCU@u~QgO2V)1bjORPHi!05QlIbHH>i{wn5Qt521_R+m`y4$ zvF!Twuk>drhki;g+cvc z$e;7$KXfGSGy_3@)U3ou{hx7h45`5FMEWfh*qD55V!vn-XRd!12LZxVwP6PVPHY8T zxuh}2!0T>h+`5nRMlK6~ZeeI-BSKvD>_Uuk5k33!rA%mGnK?8@VLTHuUweV=j>zEh zL6XN6C-X4P?WO+<2BINsq_LRc)iY56~iQ znr6Sfv#}jg{clIG=&Nt`*SZ3Fk^iXZu&8FYAz>-I$ zJZM+7Cr);FVhpf=y{}yPGFSPH4IOV)xD@GEe?uxy!<37KB4x@5|GS~AtpzuB1NubK zy&h7&I2q}T1~h{ZzkThKU??+1fg^|b0k;VwM%beWbP*<*(2TKEu1`H`8+Mu_^YoB3;=Q?R3O_e1c$zlsJIuMiHd@o+ z@G1+%V?-X7-YWF#(6fy}iia6%%M$m>%X_^20%U|IDO=U!5!uH(4J~@c)d5-OH!SH+ z3cCR*Z0ZNC-DHWA*3)njd*=dp;oRU0g|F8KUHqLH*{d6_SYol6Bk>t zsZ-V_%6k+4a?SDY93=PpNuxSBQRfq%r9;UikV-ml zJT?wvP@Qj;4*9mP|Jbg$=RJReU$*aLtJ%ji|f#j9?^_GNw9$rzJt%&deJ=RoTO9(GgVG4||lG*PvT1c;o z*EjtWC$=94FfXredcQ3<`JS?W83++-$7|u6wf6|VMjbs@oT_?gPh}JJvGrF{ zX!_R$aQ(54hU}f^x$&}r%a{;jqWE=^2TGpfCg%TKSm17&jrwr6j#MwbZ$Vhk06QI+ z;rip819T@o6NDeI-srMlESznu1iwgtjE#W0**}z|AK*QD`^1pgS z@Lr|ERV@J*(aHfd<&~W5lzYGF8Z$s`nUw7dM8kP@>N&mC)PR7gVMP= zLTdiH-;RcXw)~b}4;hp-2L`W(JW;>)SGq5LXK-8NeQ)wD$QI#WgerpZ8Q&hqj)}1; z&oOI`cr4NEpFqudF_*)dFSm358Oi{pCk#KM z6flXz;gUOn+SyZSbud#^4o0nL^$PQ!enn^sU`86;S#1!?r$p4b{GJjLu0ur&SxA}P zZ@cJ1qVzH|OOFQ0hW^LnJN#&4nDandKDJ4*4!W(^mrC!&12Bg0-{St`9^FaU%PGb= zh=OOrNAc;#zFqSZx9Z@JALg;0c@bqeVUyD&Uhcwu`{d}yJwPrk6&g0m6u<8aDY>A0 z*8d)U^H7EGb-YAn-B2rJ7LW6Ny2YO4d9Ti0HyQq1gt~{J_&FuLj-Y`&hgN#eX3guQ z=5XZ(Uy$gwK6g^B-r461mH7I&pEI}i7ne7N$mkadb@e=QgR}oCvthqMwxYpmmyMZ| ze-|K#VS>(B;~HAf2WF4(z$4@6$RXGB-eD*nFSPh*k%|fqVOUpPd13(o1l%eR5)z*` zv(Z;Cy*yewek|AM9-hB~tQU_`q*(wr(_#8TS7O*#`Y9^!t_AnFDs?4?yWjT+^vn|q zhp&zg=vM7r>0_%MvQN&YXuQdEC0Px)yQ39>UV_+Q+XiY!i6ry=KqD^Xd*GAYuj|8Vt{DN;dr%ar~)( za6nJyu0AZSw{)H$AzJR+!=vuo&wZ6BIsLK`K*|!- z9Luk2YEmvhX2Gr|cVB5@%057v=VK+`>ivXhuxIO8zmGf^jb3gCi2i&adV81>;<4Xj zwK^!TU$$mjl*Ld}38U=Mt5TSBM66q@Or(_IGE(hvp;n{e?!8}t%iezAo=}yyxzKT2pp=xjPv$w%Bn+?zh?W}yD$Gci_0Ltw282xS#_&qp z{8_vpJ`&2_jrXh3oO%L6!R4j=fDe5`nP)NQw6oy5Dgvjl22cry=p%Eh22)Vi&kFtg zuUGzFcEjZ^EK$Rnv3uE(+d@LG!s4B#s+X?d{n{j zxw1H5A>mZ~v^=dRp@bg3)pMfVY;WTIGl3oq9=Fa5!1tMPriA%Az0nY4)B=CP=IhVD zT6+O`+Yw85P3Z(=knUc013+X@ilA5dq-?s8-W&-{{dRXM6pV|>ky_VX6Vk2sd|0&d z?~I*70JJvrlUpxLbOUnT8C^_#>g3U|0sm2~P`>EW;nk`sp(x_Ab)>(|qKsZ2sL-l* zH8@qE8j2gX`f-4kJcT9U89dI*aFLoVy1!rxbxGDb1;NI{YYD-#B-#H zx;WZIQzE`nLN=%Ok}A#D{3)AX+U@(8i37RdpuO?8eo=?Bte-EpE2q9T(I(V`S_u6q zB)HZns>=(;3MO3aa@2wH8SNrL&YlLDC5@;xoFRHJlTsj_JaL&E*aQx;cnSbH5d49s zq-bj=@2#BQ??HJ}(|)TRy8ZF$?Qlj~0_SyK+J~Sh(iNmJH!}|$+Wa+&jA{n7t)e6F19#|+O54LYr^|)LF4Cs2F5jy^qmmr5{l4vSHr$-O8%=a7 zcxORP&G+T-turoh&(bwvJILRTg$~KS$H>9sDYsajVc@erYZ5?Felc1U`>N6Do`U`9Eg03%rDJpKqdloOnGQ*3^U_HGSH@9Y3ccDu2K5m@ z1z=xuN!uKq`si|pct2?->Ej$2L?-m&Th#w)^&N&bN93gttJuJmOndvH(9STugGSl= z63%{+*E@+{!1aNH9v2aD_dNPKy87R>?k}ke2X;J_3zcWM0}sVQPmolvfHJhO92MvB zSoPced;QK)%TM#j;?mmn%1Y!C)m+`bgTbVk7Yvo$rdzc2^f129 zhBS6Y&kHQ1{LNqUp{BWdLRJ0U#LtkpubSQ+F{0tQuFuC8;S zeEr%u5gbz%WUigbORdG9f6imn&U&ZBTsMCz3$*Zdy5CEaTqTi^40gX?d)ysY-*;Ag z1>%sVG=K;uR4Oc9S=ftr_wl^mp@ZA$(z*hC#``~ps<DT2~uuq@TsT9m4C7aherN{8tXAc;}T1T zfD$dZcrBxg9CW&+bkOsF7V=gaDedtDB}FWZ5SxHNPI1e}MFyg4K#hDP|LFrNSRT88 zdW3Hj1vGTgEuAHv1Zq`}MbP6R=jPyWIWX@%0ErJ%_H(?ly{^X>rNBFA$s)M-K_D>6 z>K6raOS7)WL2c!Id(_D>{!;;#r9Ee`o?ie2j;7b?YvdCP^Bjvbg7fiDc%EMRYOVQ@ zS)T)6ba%BcbKbR3u*qMS>cm8EJiQlFTSJ z`_5$^GAKBKFI4OGA{Zs-I)3UhQSHd#@LI9lU5lx|V&UOeH~%blb> z=DqL3HZOOHpXKxVmI&pYSaTE0UCn?m+wmskwVq;7M#LUKB*4(Dzo!xYR^879{Tgy( zWpR={R3^j($d$^|7q$|CE_Dw&G_`(@04QYP5f|NgA>_BiVx62g%f}CKq&;Xs$4=~; zcK_KM(c&q(|Ax|j-OmuA0@m|{-Q*3`P}__j-r)-+kWEKF1aX<*M`kR7@W$-p(e3vA zB|Z-~vOdN%WR_gQg0t-xZY-U05D}idRef|CkI+OIq`lb7pGO-2GVQJjA!Tw zkG@!;8kZh6(IXySznlRL{4AZZT{{RvpKUIlUh9qJzU_9k(V@=G3=my!seN~9GD3dt zgAk%0=|`UUe?D=>#x|Y24ofxMHJ6H@4t2fozXr}{D9MP{MzH}@tno2UG6BSv zM5js@wC?ggXW0kU97VUHUX1nC!1afk#a?d{9Q6yAi}VJ+qdN9rf&`e(@u2E2?xmRb znY5?dsnA(KcR~ViY#4*5`@8XT#Hhu0-#-w}6L!1fJcX08C$TM@BF_b?^2#xz=ctSM zm)z}Ze1Fz{`*v+5vfRyIM_1Fw%#_5lVK1lpuuUg|?%@Yx&9E2m6}+gkZ+H4CFF|%& zp^$jJp}4umj-U~@x`ee}?Ao-aL`Lxk51*b+^84A<^H8Ca*P`P-&Q9)orS!_>=RqbH z`@6vxdNkXyrZnzhdHyb`grd0sO8canUNpZ__Upo##+zU_f%rT*kQvoh!9L-skF*o~8GNOrREc(%U{DwO66r{b$y~ z47I;gFw?P`>DH!Pec!B+Y^YnlU~e|dJdwl?kt^%-NbPZbG0lz z5G9OY3Z=fhCau@mH1?`u)bF-9!GF<=Yf>0Pc?IG*rve}ty43Z2e9AlL`+ z(!^%t@W~7QiAP#M(bvB9_aQ!LS=3pF3&e)lW9>yfaM3am@l^TH#)CG2F9dxokSL2` zPH!hGE0!Z5ZjvDI*C1zK{izS$kKQ^bhF={hHXbQ{BGj`JNqaX1TR zx(4E&QR~mL1tLB*S4|UNktI=V_|CMBrM{0CdW++evU|-qhmdT6Ww$8T^+A>(WIk-r|`%QOi|TPstrp$ z|K9uQv2*eTwZTS$i>n|Av@aAWNTrG0M>tZPFYY%H-VM$B+#3|>A=A3wF9v&u1OV;K zAja+Jt?lm8-aQBDyrbt&e+cg-bo+@=k+s7ewwO2=xA92mS!T)rYA)5mSRn z6@EFH+^YMy>~(M3Ym}RQ19yaZK9e|rroqE$e&hG0w_LGj>27?D*Rx&!?gbq;gS*Uc zsB!3f>N}xKLJ?UBy=a$L`Sus6&OYhSO9Js(nLImccKmJ7J0BGHw8E7+66@$z{iGnh z)Y+1g1k0Njh{o&8gE@{?8_Ld>yncGm==8pSm_S31ZK(W8&OnU#a~dsg6ZmHmFA)Xu zFB0ijR0= zM{ufs+x(r6X79LpSTT@YG|OkzdQCSit|zYYQGBR<=dYc)KG_thxb`lsK0YYW0w0T; zPvSgl@&@s(EXFKXcn%+@)P`ohMZVH^)8hc2A5F?8B zi^E!0&Qn7pXg5Z`4?s>td!BsV_cBn3A9GF>nMRH7lRvsi_|wmiFo@6G?vkKPqIo{; z$J(m#sI(yB6m05l-wN%r_XOBvJ`!t_#pmkMbM6ZD=@ZoK4ubvgV_Xl7T? zGkFRCXaD8kpak>>{|v{i$7Ve0i>LP4=|%W~nnXAIeA0GASABT^|K|S?XW=`1{GYi7 zpTjWyG)Qy1(}xQ;%7Q_laLZA5g=}k2u$H!0(iRG!M;##);EJWMD&K?%ycC*}X$X7! zQ+|Cm2!Dx?!YhU!`lz70GRJtoX?ncW>F1u`05egOer+^)Z}COq4gWPhu3_a`Azmmk zT%%?@8?=#+`U2CBeHK}(V=w8tNBotBaMM=b^CG*JGw&f_T0O)V4YSt?8G8V%)t?Xa6ROJJ=tE%UAJH-i;q=Q0PiF7z_}0%h$svuQXN84Ck81`e`p<(Zu)exD z^8`k@YW_|@76;<5y6!`0enoT)RKok1^9u52^Deu+?HB4gTMuz%wY5Ka?l<_Iw~$)H zBlEl8t@~@tJ^+WL>6wQ?@(`q^5bxLT76Q7cL6ydZ_R=aC^5F*BQF(O6^Q!ETF9Efx z&>RqZ8F|}{aJ*xERJ*QhGCvNPF}b_oix9*vnHcw%iF^(Xo5QaQN_6UBlJovNca2Wr z4g~&H_u=TgsJxQHt;fiZru92Lran#~zP&u$&bBWT8c3&;k;gg3gB(`oKp4x4@ms&Y z;?7vo&L@R9h%Y`e>L!vJyita{JPrmD!cdAkl82o1F=52b$kXY)5&eq(DQ2jm$%aSd ze8f~0pQb?ow^oeb2f2a6ab;o7^;v81qTjMXpil<~@u8;MeqSDjcH9fztkaVInc94$uSENp^Cvc~I z{5_Lyk~1n4NA=2C{lODtx#3&W0ar(@`4JF@+tlIvUbR}Zs`t8KoY3b^KU@(*Xty8z z*@AY3B}jq!La<{G+nbRRz&P~C4ToLzo-H2-_zh~M#}#5!s?Pr zB`U>stsP|gS5q*3GClvQHT-zGKUUzt&9U3Rj>bdmt2^>Z0hX4cU1^jkC$fSz>=?d; zYeLP8*QVqnCR!gB0#BJT^+m=k?~WN{u!Tx~D@PU7%=^ay2D~7@gb2CTytsqOOG&|S z|3KO3lRqoiEKG>>g*kbb>$PBXMJXNQ)scthn0@#~aN+Ebu~EavRx==dewq*SQRy~RHVLSEs>!jh<8Y&&Hn7@*YfuXh_|XQ371laezUl6kP^IpAi#hfKCo~({lw(*6pC$dTQVuDEvh)BYM8@X`%)?!=JY4HSLwg2Z@glXDj}%5zJIQPa~3cd%ox!9 z(xlV|&1Qu|#0^`q+`1v{pKW=kcNZe3FI582qWpuG4%@%y9=iiU!rWLXZHJ8J$*VIo@#}bAdWN_ z`@TOKo|w!Ar#-jQg8yBlw`0-ZAK^53x2P0}4_BOG+JRd8`Ukx6P z3tmESJEB6d=Oh&O8_*y~4o!PIm&IjT02Kpj9S^(Rx3=fgDb&K-NXsVFI*U{Llp!v; zB8=g`5z@Hs#NYiYsIUhtfL87`St#ucPk4{x5Qq^oF9c=bC*8^J{Si(e-z=6+((hQ; z_}ndFvc5!u4H>7HOJBF$)Uch52ieU6>P}yXAw}o0$ZjGZ@Wt-~^4Zjct!{Jge{^cI> zxprJu=!?Q{bS*v#xCbVDs+$7^+le56aa{Z9RNP9|moH@Y@KBq@%9Jpg~7Lc zclXF6hTW`Bu1*|@FB^`7#N+Y#Smon5+H-K{Vb9f*-^wfG-dJxT31A!9UW@bjVR5|9 zW=4^Rmu+=PSS3&=+is-SthicwK@shI%2b$>lvt^hePXF@aFy9lr3O~jDvDG0*kPJV zdk2Mr9`HbJ;|(ALlAFMjVO;f!^6y}s4uSlBk%vdKv&B&M(otB5Gy4M-4-<8+%jeL4 z;dS#oj=-B)N023H=Kb^M_JiWBblA0m1c=yqbZ;8Fy)6I0;AEjX{R;1&CjQe-%Q+(S zPhw1=S|n~iC&FHv&>Xk8=~oDtT_r;4Sc_f5-&gI;IMIT|eF85U|LKoI3HMsXnTa1xL~Wf{+tB`+uI{H8{Cjw4GJOW7<2mXbO%`BEG})&W zuX%tdHIagc`7%kcY$NJ*1kYLjp~5Iw$RFtd`oxn{X$VW7hmcXb+;^|1z?sDcQ{hg$ zyQmK+EMZ6s?~A;?3cq&}U|68EsCjO&K+YR22Yb8R+)VvKb>_$3*mPQFM%&;CwZiVb$47wRp(sz6G#ysFOI080Q#gc zFLc-ywXrnahfW>|XYovW3-9oEF5t}a5c`q-W-U*q%C$+u#@aHN0#=6)(Bfk1u8MRe zFG*t^)8{q0umSVF^$&E0zn}Z*Xut;Z@#Mq9WjUL$=#lDE@l(2g&C5iBjty;` z7oV*Al1WL}bp&I1B#%pjzGH0Yag0Yi%^ANZ_F^Sgxm%kE*SYe_sY_O`DYzMeV~5&+ z#j8VS1>s&I7KTMhlv)C_4#GqL0mH!Tc@K>)bI%$@y9y_}VR~PH;>qJZpXqC)gvL6* zk9_zhvVsA%EQ8!{-+n>TD+95Cb+~qHg<(U(){m2(9gH(7B1g0e;IM3E z9zPkQmmJS7-lJZewk|~0yBdOVqba5hK@Vx2|9UlU^HT85p-1_*-~9@Xx|BJW%@9LN z)$bRhMrrqH0ElKE0ftDJy#ntCJ_>)IV3logz@%lo2l(=!V*2}j4ddphb;jj2v**XB z8y4>c{a+$V>1HAf*chSHg%g`pPnT%_Y1F4A4?cn7n=X({C~GNml{fP5@dpCTX*Ym; z9qGaIY;%j(r_J#afuT3HDiWx-@Efmf5l5oe{z&g<1qKS=@PR1c{s*?Gl%SH^t~(@R zy@z#yD|KgZCZW%}A4Ww*ij;XQZfbVcjnbUJ23sy_GR&{rgzZ z06c7G%pbvJypIm~vtG1~#ijX0(b?xj;2HVWCz(w!ROVEyc7H?r>M~b;|B%H8{q)q< z5}N6m<@zt|x1v|Gpa06F;raVgf0a?KKmJt(Up3bz^@pYRLM$<2XyIR+6a1bxKN`gs zw0%=v86~@UA?!#_L;ehw$DWjvNlNW$%Fz_VJ5Boa+@F$0K(hCZ2b4Y5b`N z#V^wvS;@?c1_~ecDOQw}d(Dl=&t0H1={OQ48d&dV4Ki`ieU0PyZY)gZ9wpfB9BzJ& znW9iNWX^Fj*=i4OzJ&gC>~=LCeAPX+eaTd{!JB6vA}Yj&!Y;$HtB2GF&%|6n&edTf zwi1S7{spA|w$o0Nbg4chTRPm6hB@!KtQZ802`p0gb`y9aCUplISTBJI$xh0Zgxk@@ zmXq96lbe5Ofa+ibLABTizz@J-K-<4Mz6z*f;xngv9}T}Y!>=?J=ZqO?sok${=j_Sm z-U0<$?e{oZGod>D?PyfvTDI?01RP<2BgB4j_2S?>qG~h_@!YYj_DP;+ipg856@-vo ziN>p(-YJ?NEVy=UOhs-K;r;lykvUU(~|U?1v~)>e3*+CN<={(hO$K+$) z5ii>(#G5DhY2Eub(0h-w6#9~q^EZCTQ3*QwvwHjy6mQ7d_i&;}S#**ks&&zFyfK=! zASFIs9(Bsbj`x=JvAc0Dksb9RlxU)awzCdZC491H?@g(F5xy?R#u%MN4L@LM!6tA| zkhEBI3IR4W+j+L`Thm_det#mzo08BMyNBvhH6P@AlMPSUEH~lVO#+JK9@F)v?BO_^ zn!7BA(=9&a+1vnOAK8))1m+Y6f>Hj+Pn#gH^$Edk&J8SaH2wud-??T4fPN5fI_cnl zu4fX$)F%pJG(t(vj&oRN9DFEmG`yc6-@)Urr^>F4{(=EUrO^jf+~WX`UgTU+hkF9` z>Kj5uDmgPLT+alnH~|C<@XUSgt=9i3C>N|*d`}N_fsw16kT$5plhv8({4NtTbkxtC zh$LS(*3ZKsyGy)OYc`)&hJ4&=rf(nLEAPSEFfJ<*k@j7F3A zJ=`q;aa_-oL00dNd*6-&>#B}@Y1Z%y_n-_$$7)`jmEdyvkxpRTGTq5nZ<(C%c5`jy z`Y_$`bT=B~OUgeTyD`Md!MbjLWK>)%&0y_&tz}z@n?pz4J3Z(OIAS z@56ZQ7wuagI&~m5;}Lw&XWv)q?lvb|rNT^NI3o@f{y1!li1{k$Umku{0b$!2S8E!b zgvn@`kQqU*ALYo9 zW_TOZAaTBxtuz?m4FkNF>Csg(;w|#`yD|M#39W&yF!D=$p_dWcQc2tA_4EJ)Xr9@x zHc$M*yM*z~C!?&mEhY2iW5tgl%Z>VM{C8p~b?TS4YZOE&C-zZtWVMueg_G zdj{R7%kLdu2kSk<{uZCT?osSDzx}F>1<>)GLRSDtEIc?*taiJBGJirneR#cZkRx_& zu^q-CL>u6$H()Q;-0yhxMsMRE*DaWFFu_PT7(uGx-2npOA4_MpwI~t<;a36yflC2d zMfUYh6a*DyM|k=P{+=^^rrQk{imI&4jQG^tqWCZ&hv#zQTtfZ`Z(~{eS7S7Z&Hm10 zU{G>II$Ui2*<+o4Xkj^#@F<+`w8aV82&cBYlTcH6{KB=wGM}D#@JRNFPiS22eHxA^ z=4p^u0hT)7eY&~Kza7wXSMJ_KCD{Xtr3k+S^LUkQI~Ztk`rvXM2Uv$=brzCEA8oH@ zWOz;@Gb4X9?Kx{16)oHwdCM~h2*10vUy-SpWcjDmAC08c96P+;#kNio`BGhE2;blA z9`TC#!7;kxT~`*xSQ%(`#95fnm~5S&E`ftalgo7+#WNg}=J#uIVC}#pQMaDa{em}X z?(xB9{!|Zc!FT(7YK%swXZ#l50Tvx85uZ|M`68Z>$cT$q82J!3@D_#! zP=8&e>2^~~y5&4lp3yETgg=HnCe~_tmgd!zCFmD?a`~|g8SQ!ywFr7_UwqGdxg+#r7d$ZQ$uiHUbju^5QmvH3)+Jq@JYZ#4@0t)9{xR>g$}h z9G}C;7%Y~)eYhi35%Z@I-Kr5fBbq)AC`K z8exz8+k;(hIR6yocUD0deHLb{t8Eh%-ZmQk>7#^hqifRfB}depLdY~;bD)^X+A&Y7 z6sA=jdn>Z%?58=t_rkL&=|TRxOxMq1orb-DIpp3Oo=aFuzPFi3M~HFWYa5mtCXU88 zdY?X4<}h4TT?BBO{sv^NQYWG~RuU8e2D>To?PC?d6>N(AUiTz~u%A7cJ&^72S$`Fp zpbJQXVIWT`&*y95u`Q8t*$A)OOX04-c~JJ4W7myQ24VX1F{VGEdmLJDrSA2L4o>Qi zFXM$-rS6MG1iUevc7u6nbzwyeFX2%-dp`WPB9Zs z8EZ|B4-=8?UbOG`g5E{eM;=fX# ze`5kcE45H>jIv5EDyahWAn+9e@g{Z+6N=~$b^5J-*WlK5&4)VN~fkn#1nfF}Uc{nk0M zmiMqz^v~3{7ADulS&L%nwesQ+z!O2202hNZ8qE^20|(bYW1nBzGl9Ot0gL{@7ybvG z`_VlZ-NwqSeXdS>uYNAM-8mfDQd;ZlxCdaM%ce+0fm_Jj8?jK9nkh2J@s8{YX-5dygeY zw3qhSP3K{I8TfcL==>=H5_paBM-)liQS1&*J$ScZf)Vf)y}njq-EY=gFxLc4;^-NE zyb#)75ucRMLF14_NWVapF>TOY7sBj*I6+2Flo>9F->E8EYCisLHztBm z7dTs-JT2KwdjIme76HR`-Z$lB^i#Plx_5vvcj_X#Me#zkoaQB}ivY}9`ii5LGVA`iDhAsBtI)9}1)%*7KWZB?sjHwX5PC0jX`fK(|_JtgYN-nn! zfco6vD(GF6iN4IQpxw8&`V~qF_h)<+d2gDRHNWYp8snKJl6KrEyV{oo3?11Y3R?5t zr6S~i7Guj1V^TI8Gta?PJl~9R9I)flSl}=BX}aod z%Y80)a;-tfQwp{Bl?X4Qg9B;aPoE(;tob$%Mx4=kxv#U#NWBpf3Ae|0G^auaJsarF zPhlbx6(d^0rZFXn&9;32GO@9Ja&luZVwTUm>C9?<_yn<@)9Y|n&o(k`FksjhETl8! zFigi^oE|?R`T?kv8JvUjl0w2UY+{A0Zgbac_dvrqLP%_EzKY;X4m_kuwv-063yT8O zmdsRDkLX4;DDEp>p|j>j+Zf*;Bnt-irNo+dO^*q16~Vu<7XuM&aZ&dK$=flzZ5u*bG<%~ZF==_Bl^2Dm`?&+b0V4Y8oe z(=9SwU??klfx)CcuczVheGR$ZIN~Jlt(WYNbto$MDPCC~>B$kJhDhsg33ohD3yof- zyCZr@00Vh7@SNVKJkZ$7$Go$1F_#@0S+f5uO$;82VB^g3xt?z)qduK zPxY*5Jy6Ybvp%EdoalZKFqO!~o19Tx`fk(1Kt%&K`ndB(prjhM%)9TtwtE_8*u%)( zyGqOWwNDtE`?Zk|fOBJVm7dg2$`oFQ>x;_%PYQ*TSEzFC+hQ=PDH( zTeCO{;vH%ixWyIRb)jJ~$BB=w%fa)U4$dMir1X|Fr2KbJbj6vL*-@pm7~E?wy#+Kp z2^M}m8X(LR0cDD~gMd>-`P zS@Z4$r-a-XD*i@5zYG2p2+Uz4Y(9(?SDm<iIg<5YH{{mSxw+P4!&8 zSb|~y!KU}=yAiqz)Q^1x0Y!R$g#1_X%u!D6;nz%_qU$&risH9kPIj8Iz!u&iSsU>U z%*vg@n7bo8g&)e0mxO}E+x|wdv*2v|NOaB+oEz2ny81mvS5FP4HlEoYw=0V{V7Z)0 z(DFpCy8vT+c86}`p66KKis^|Y+=*3Ix=N`h@ztd36dd&V@!iZ-$0UWLV0K*VRmqz; z4OMh*Hjnk$m)=Hvpcrs>)hR$I_v7vRx>LbeG;>gYw$-Oo=1f&Ref;j*<&6Nh@bX+{ zk%?wA{r=DpttkjP<3x*!;ku90MWC7Zm-xAT<@u#JJR5iT2~7UDOE3M%2$n_WPK{kd zdMP|iQ`M%yXiBeE@sLBSW5ZAGmX1Xd?=OXf8Y|#G{y9OkKA}`qO5E2`@!e@h~2M3guckjPyVN z2#wSJxzF@gHTFA#jBDEZyDo~4Ch;o2;C@^Gc;4N+-k@g9hOJ&M)Q4#FM=%6EsM;&& zX>T4qsB3UXzrkIaPq(9B9WuB|(zgbnlZae%&1{!zAe$xDEg32V_FmD9TRCT#N?Hs{ zOwITCyoju1+1>or{HQqj`=SciW_f9I@}cFJdxbS%n@2|;V18fww}eRD?DKBwfZtAM z;J)4|lUX)$=Z&<{1|N?-jfhD;Ddfx4$B&vG=>>4o%#=WrAZ0?GWYePhxH zc$|~q^d67I+_tlFUnP8;EoR(zju8b|nz_sq`N(@Os`%C(Q08;rU34I` z_2$47fx@YwyYEZxv!xsBIq})bMq3H4A%SKOZD_Tp6iOng}{Ca$DV!2E&9Z> zfHd}+0Lz8p+plIeXRvOn&uh}BP#JDBwdv@_qZjIpqX3jD_DG+j7{G4n&Eeo6Il4X%b$g-TGxVM^giHP zKOZDp<~~2`Y^}dpIeCTitRH>``L&1UV;`gAXhoFwP^gQ?`v&~%l2pwOe`+TYQ<{8$ z(7d80?_DJxQ9b%3;4r6t;Nj2)0YILxK(7hz4h%XYusN^yB2W?^6o@tzI{T}8V zEIHVgr{BO~q1-KzZgQMB#PgwTs9x)M_j#oY4v1z}IB*ibvA z3&-lW-y`PI^x!@T7`CrQ2kx$>peY(XIk%2lYi`f*IrH zkTHZVh2~8CtmMD|((P*S$(1lZh}WhX8y50X~d&}pN#|y3Uti> z;u9>1&)I?a!-_T2%6UKbf+a_u2KYO;4Y`9`$FIKJEoLFCF-vkva;LnZ)(*0@I>;6JcP&Q^zRpqdcyeTPq(eC8S(fU zem5et^B4*)=ELJ@CnTQkCI$R+FELDI@Juog`@Z?sQh6z1F@Pma`LlnTB}D+7@ouun zdGCNCAJgl6hJu=uZUqmY6Uf)tVeJ@nW2@N1}U?-UpOCObg> z=mSwED(5uhi?gSj^N^oFS|O&VZvfika3G!1?Q3zdAD1N*^hj>;0WaK(W<$sNC$-cCbsqLN@(&KJtGe-?f}to(MR-9VR;{ThC^v~a zC}-k#>0m40{bd)MxO;qTXe^GjseHLT1&v&pf$wJ-&yIgD&~xNhO%M7#l4qxjjTKEe zHfD6a%D>|$rzsDPD|n#DGchv4EBhC!UAW%AK~qicSbk|D+P0M^UG2+J!L;K z!R|{=PnXA)7LT%#dEM@wB2$y~M0+dqLi*~p=|dV|C?ll9*pia-!V}CiufJeeK45xw zVKXctb-9E_ASCC@KI*S~?(g>1NF6tXIPx^Wt`5imNV_qX4AYEBB?phzhguPMzA_|Z zIrsej&Eb!(ve&79ALh*~R%NsafjFwhh;od;#w%Yln-JUx#Cwv&6c>W+AGbY4WS^~t zU-F{A%U%(Ls?Q%%cvQOLAH^!#j5K+;)He{^``*@Ha%FhCdBXS+!E?kNj^c;c?{b7o z(Qr?%PUW<-CWZB*W zy6M2_-cwUQ+s(b~l-8`SU^{MIGhLw!-=Hn6^ab`y9W{!aE*bgc7t8^&{#*3F_##Vb zhySF3X-y!HU7_g4qnuO(cQo+;gSDq^q@p`euJcx>#-m?+uDhpA*uLcYw6ZjR?c>nX z+zySEQ59w7jhYG)W;%E!e8CH1F#bT-wASkCwdBWHT9Lz%jhV52Roa#Mr7r6)$(=r# z6=(Z^d#f5;v~S7R0r${D1MYWR^J!JT*#TJ*H zzGvZK>7d-CFp-0JEnO6AvgZ*x8feF!%;QKpIHvH-V*biZck(bIPO;b=9J#l4x>s+$ zY+fIMeigynqYj_Tg$Z9V>vDm^KSz&6Uqxy!$IT``+2@s@Aa%S-CJ&vVYwOIq9GJWa z8$uYZ4#qg!kHTk{DNY6H?@z7nC7@NnuiIE*w^h9AB>O}e9U(6##K)+`RLnnF_CD#< z4?yeB<3=$jifmk`<-Prb<7n<2oKL5yy%NOAVbCnx{rE-~Q7p?1^$^K?GrKbyvXRx> zpB_pVT3TNI<(h6tDPqVVv$*hbFLdt#-7^LuqTr=a4jhO%5yZc_{XGx2QDkSF1^Ku< z&7GORc0&uD$^vs=sWs%Ry4&UJ6D`7@dPntt7F*$x#N?6whL96Q0#b!KP>(@RAyXLLw%cK<^X5EfNBs;nTF=^Mol7gjTlDQF_2#;VHU91nIAT^k*nGNx)a&(h&Y)WwS3zV|?Es zv*DS8uh>T#BUR>%!HjD8BbWAlC6zCF;QC+O7&@MY6*djY2Yd2{9KsX&X?)M8UZ6hv z`x|4O?F)rA{kTUa{ zA6QJvH(%ZlDUdj_K0o)>vMxWNd<4k+ioPpdD#coM_g&HTTU`9{Io}gle&Tu4eM{&D ztm==BtKgC)7jk9%PdF0w=l6(M6t_w_K1qW0g4Wf5dnT6DNuR1`!Oc)v=>Y` zkh)Xha@EkWtr@4sM1U8J6-Wr*<^~vIRZ>49SiR-7!Njm1ZxzSeu>JIOLcXw$9Q`8M ze6YQ75YJG%_}m_(w|k~w1x3{87Wx*VKv@~#NvW>5M3bK)@?1+J>_(9}ulGSxuaFFI zG1duU91h+@_GY&oawepc+m{EMeQTQ3&_%*E=m(UKhbQeEl|9J`q{ zz5Iv|APZ@4{1S`~`5*8_Ion&fwhHII#Cyty1EMl8Hck=96<1v}Tq}AZUqEqFGd{#4 z>2<1FqPSuSu+a7e?B39(n8Gly+(Q`c;aNQ`qgy|H7{ei_!u>QLvPV(Y!c*V-Y{lfm z1>3aWwJgH!HgsnLcgAquL2dCjiEcSb9Be^pPPl#_#X|YXMV;LVo=!YPKp#i29$tVy zbmm@o0C^R{(@XiI@Aq}=$jsPRpN*qTECX8fsu#;Pw)okooTtgXY*WG~dvv}R!vO+V zTEfyjYuh@Y!f-_iHzdj&@f z+V|&=%WvD!<63J&e1HeWBq5|JjfOxF&vN_ZE|4MJ%y?2f)On%E3Vy4N;q4y{1APE9#{y=E{m*{3ha@zG zdL%m^_P8FLoi4p)UTlN!cVm&=NVw`_rF(~gmuT%i(4O{nAKUBsbrQCLOKMo?&qYHANdPBgrbu}7md;A?J#II{Nv%QGw=#{&M}M6 zr!a=)jQyv*yG_qvXyDbyOQ$Zc*(M@*?qItPd8bX*U4C7_zL z9+J2gvEGE2*}QW|XYC8)=`_IT+lu051J%b*(GfCHi-Utz0OJA@{5uEocshYTBf?Z4 zsLtdL6mG^t*g8;oa4e(YZjFvnYnR$IbILt>A^q8&nRjc@*YH-3r|DRIMBoR`&b@5D z53zk*eow-_>Dm2e7!<9d4V5~)%41Z3hmn8=?nkWRf!lh<*b`D~_}iui5E~1tB#oLG z0N;)h)IQ5)r(<^hM8V^xg@WbIXXO?g>LvS*`_Jq9%YxSGXVl`UP+18S3%7&k1&~V? zLYS^#&0IPRJaU=hX{}u|mi)))(&0sx7BIVEygc|}m!K~;)oZj}yBepe!qe~l9E}^v zu}mR)E#xySUlPEtqgU2`iC~&(=u!%aWk`utPKle@sAOfacfEmQVBF-b`n+ImtkeTO zSJ3n3)kkNQx8_-s4AAvn50c@2&7r}=UxU**NkosTt%@U18SL+1$}}T|LEiDNHz{pC zK)Be|qKJqtf-5poc z@M$)+nJ>NPt60%Yek(K8e#0+o$#9_Q3G(Jxr);yk-TC&L{JHue6v->rxjpKIfawF! zldCY5E6Xd0R-;!OjO8*97v}uoc@I3824_XKx}G+HaM6;-Hes0n=fg4ZO@$s%>nHkr zstO&GD9ZTydWyZ!fs5<@L%g`S;u0+xY)Eb0RAVwCJwNmaOdwFP=2Ik|y7wK#Bkt<- zulPs_^Tp^~H99xieSF~!kWqHLgGQWU5R`Dldp)7u>#2*M-~Pd(#8S-;eRI*)oSy>A z=dca!y7tC%Z%~1&SZG%JhCI>_%2WW?UW0K3crp_Mc$we>0Z2m~d;RG`g&)C(g{?w{ zZM#!!z;KHE4xNuU2VTH#8JDIns+yZ-E%l*chf&&dZx`nx>^0EC5`LjhCcOlca%gj= zFRlB!BxdVKvy|8SZ*gZQi4QMS^svB4mgTV&k1CSq;TB+fz>(K?_0<@Lgs4r-t~boE zi;gB_yz<#~$1W|sWPG;pQM?;kngA$!2$CfUFPc(gq#3Ft3MR@xc>XyQE0;}fA`GfD ziHTI#b1YIZNbe&&Q{Fm*?Kx3D%JjdHJsyQX>mS$cd1DH$G%}!4G-t*p2sSPuA`(D< znDR9^l}XV5ZRkTs{>kDxvlHZORJnIuNIDlTi74<6$CGauVxFbfXHymi|rU! zD`M-E+T#>tu#uS3?r%-yiFIW{ij>5(J8CzZl>x3=U9PC3U!`m_nKXQFkyY4)`zm(` z2I5%rkCs`A+`Ll3cFQ>JVxQ?IBFPNFmE$58<_>(F@`$!uu>(8u*KxYaJwLbB`CB!< zdyIP{0vr(kK#Eb@Q*HM(8slu2P6?O$@o={kdxe#@<;+%vLN}4$Lvo>d4%_Q1=ta|- zep0iKTsIVi<_KQdZR?|>`0~^d!Ahi@=r{igr}}+w=Nt8X>3f=z!;YDE;)_$zP`~9= zdpxKfIV>WTRV#y5Zal}i-LKQa5f532c^{HIX~~bs>$82mCnHYYcvp|^xjG&8`IaJ(>phPGByve=LKH1;(`|qtNr}>#)PKz)5NRH-lrKLVvlm~ zMd0Ut57*y9*g4G^sf%OY#|YWNl8~eetPjsl?mNCDf>!0`{Q7#oG^^L_n9IR8Ejgm5> zfIbHg_*;GjvCtkNE#IG)&N_*j!~UA3cstHw7!1Mz@+3Jb8}b%)ijLLcB;v`^p_Fs^gQNRTse&>rVqFg`bh&Z)%QVGm3|!&!R+-f8J{!4 zyxHid)=UCPEAayXlL}7c(bhX@yPvr3(5jF8E4kmA`^;q-4zm4X)ev?`07bB!67x_} ze@g$JNuk8TCHmxD-?(zf&;Fh4Z_CEDhYpuKXotpsT(#_JyqmlG3)5%bT$OnWU6BVZ z{c{Z9EVRVVn_6UY{=~T+e;|5eh9_G=EO$OncG29SS^st@crttL5@<^keX2%m36VUx zJhymvhDMedv<5ti`9wB~efcjpd1G4;Vc>f(nilscULo;&Q^ZGq?F(S1?7jmie#I@PHU%;jk`enm zw19wr9){-E1kjdn2low;e13D>-@Yf3K@RU_m-xy_P#w`YabGrZzq&VgADBP(EZDu@ zXDZ5|`<*Qi=W5p5zo4Y0M|nTezZ&JP<4P&fnfrRTrG3^XhBwssb7#Be&=r$w-UQ!g zuY!3?59M~lQX$ay7!5wHL%$N37xvq`W3crMx1L+O0oK@0NP-^G+)ao|vS!*ZO8cYp zbAL?DC;{%=Dc07lGT6&*+LoVXKR-H98RU7$=V-1zWp~c~{AP%`M3-2ED-oI^6Gok^%x@n)|MdA(E%6`}fjR%#J>)|KE!B6(fy!m)`z8AkY%K{Q|ZsdZQ zJF$4AD0s3-;f>BQdiV=VJbNq-9~V)kO^lcJLz^hisZPF6N!GJMivuP(p?s27 z@GOx!tQM35NeA!KWAYX}6P^c=n@0&kx)V6To!SBdh)4b=yAWM~`!c$Jh2f#jdQ{AS z_H{!0_VYP1ElJ^x9Gc;njA|TDCINB%vAIYVOQEzIzwi7~A^S}|W3KHJ%E0dQEa-v$ zeR08PiW9#|HtY7a)0gH=^VpwgZ6}2}QaT_#cs0N)_&-OV7;g;XNLHQ*Y~Vf?=PvW) z=yAxO<9(rZ_O`#j7ZL)hUFWqFUgP`LIfp(m8Z?g`A1 zF5vMB&n0#vD?$X1{U$xXCk4Jcp!8;{Jn_ebiJYEOUlr9~nBz5=-WQZ!9j$^qef@c; zAZcOayhS6Oxm>B!w%Jfvc?EBBT+8ptXz(kQ9XOa#JTdHs`XXmRAn}K1h z2sKe&o!SkFy5eIo?DVD1&m+Qr_~BKbJtxL3`}st7mcnAguD(O5sy^jNLxfFU9_QFU z_C%guZZG)h9U|B_ZqB}HH7VR-Pr_~EVZw&nCjS)+mTcqAEczOk1MXun+v2a!Z(j?t zu`IvyufcKm$4JW3mdm~*jLMOm+Knq8N9pSCgZ#B!Z{~R)BCrW>vp+x-ZhR!ZJgUv@ z489!WrOCDBZqKuDf-3_$=jZ{gvW79Ku>xz93i;UOPL`do9{mUTvwm|7DgcfWZ}#!1 zsm}YdC|)JO1#fwVw;7&-%&BE;nA)g48o>HHyC8;5{>Y#Bfe7en!c2J~XFRk9r3))E zvPJ7RrGNF;n+Po8I=tiw@37HX%H5p#^+Nwh1H>4n`}%ggrQMr<nBmAU&?Pyf}r$DuVO35kil^ z=T~hIdJc-tIxqc8VdTipm$COl3b(l6xhTG|efu0f%TL++oq#jG>oAjbuHO&!iwNo< zuKOIsMMZc9%@I~`o(_fSS^Zkq*B-FKz)6eN`N{xhYw8x?^%@FhK~~Ebv|L1tuJvn| zG~>HV5T-vl9L%umX1mjUnC;mc;w}^Z5g*5Yh-8 z)#dVgs@BP4u2r!|)hDtRwes8(-!Q5Qh}eMY1ZliO;p=>uLNjprG{t86&j(3cVq(8| zNBOm4rN&YuL;UbJ|4G_DAMW3E`@xv$%5rPTcf|(X^Xrsdi^Dpq&G@8s{>PYqzJU9y z?_`+6oX?@Q>PO<`O1=jMN#Qik;Wtya5eQ6TKqZwa-^58nlmQ`o1-D6m9}%%N75myK zU(snOEWdkk{)}_?eLzuj*|$@(l&Dcp-4g0~LH(=8JB&hhSsSF*o#5(pFQx7E7nxYX zC;!7UmKT)IZWo>EDOP-2_d00`sWRrf2zapPL|^hTLaYe>O;Lmow4%AuGkb93O@KaG)Bw)lnvQ)RV$~*{LwigYzpx zW|3y5yht0XTL}z)U7HpIJca|+Om-ddcUTUJ#!9~1$zS5*Q1_B;#}%lysS`n!zZ5s= zV(ypF>G9W2b-CP3l)LOREM$yJso&mD!Bo8aM0lQNzOUh?jg6`Cn8Jlm#JY7~4hRWj zESJB_*9f5iQWAmagx-ikBC3R9*u&1=pKd=ywE94;&l_y%_}?12#uwG{I7=)rYG;o> zm?ci=PG6LBYX5=wlBjHD0*PWlGkMtF-dS-Ji7LHd{T1v6oLct+T`GT;N7VzHjSo(J zh==YO{`YK8PwxR+tj*I4m4sp0pwoTX2JH_@*VBh*w!!0%3spx-Rv@K3}~<`#Zk(fBJrC0Y!QE-4Fj(QRs|t!1{sUxGB%af`gA4qy4l9 zCdzj$A+F6%iI@Fw-&gs2&b?0d3%<_5>3Gv748Z0Z3mhI0xyjv6gsAU3hM77X%J&qn z$)?QTh6mdPD-<4n>@>1HX60OWAAGP!@n~aq7TkrKXk;w51XxY@VdClrlexS`wM}(B z+^3Rps=cgWk}eC_Wfz{v2Rbn7hmffTsmk(gxo-thkS~V*+dY?@F(asjEZNfqyaS9y zQb@d?0F2fjLOnKc$u%-9*EY;Og*Y{bRQ{{CzuJ zc{DRV_F%=w^&rT>WvD*KJ0-w38wM6J9klyw)+WwkTO0B)TAu5<5yEO8RKm6j#QufEJ&yA`J+VE0?<*2g zrf2jEp_wSfRV9Okj5~c+gNwea!;1n|5INbv@-^Box@+#kxn4MnWfG?x9jz}zW?ke` z@mPK2Re2vFH~y{K!dd7_8BzPqQH0WX>;o_ z!3hs;icm9MRaXc86FX zY9Yvn+mgMk!}4}E`Nv3;^2?S9iH+B$1dV=r-ZL52c=>cGLK#k41b}`o|2C};`#qz# zhB~1CESI*`Yn0)Ohv1EHK$Bec3&J-@8`)En$L_#x&u@KhZ$_ji;3NIi$FBpc(9Pr9 z;#e)&9ry2)(byIn)%f>=Kht{ysZ}dNM$(-Qg%|bUdwluIgP%E>p*s#QIUIMCwA}30 zIdZ>bOI=(N$2?kV8h=M&F}VG36d;sxtI`Trqaq^>wPQ`U>`dH32&a5_)BsfHqEH&<8coUXOnxatlS*YW3Q3M@s43G1TwEHhY2T< z93KdoDXT!}O_Ck8f4=>rmiw77v8J;2y<(vT2=Fuh6)5(>Z@;F=&3rst0Glu!v)7&5 zed~rW4X~NyMHW0=?xEj!Mq7K2)Lqul?fPPm&uM0(GH%=R)H%MAns899eM*ALZKW%bv3pL*qGs`qW^cleRa$Kw^174LQ^Uxkg%ua|wbpq>h+@IjoWL^$={ zMU@W6{X(wo7a@&gqCz_|YwhJ=rX?(8^>*j}U`3nm`Bb5d&Yi2ELp(H>%<{$x?gF@D~XYzy9e zOjht^fZ$6Qi&!njabJ!c2Hdq$heQ{=uFEVNcFR28;;o96$REyV`qEr8T#_4#Kj-~A zn$2tueSKdCV1+2o!DZh5lw$L5`9x7$L8Y`tm4kuzmJV#Cqn#cYk(-=q2Bd<8_aJZ%w;G2Iy;IDvJ?ktIeCJ z8fG{mKBIpD`QqCuYWk@m+`q5gy8M6%kx|^Y@pX^4TIH+lC!J}Rpnsr8p4iHhb@|?A!RQGv^298L z*+q6^>w&)>L_N*In+Z_to^?)M2(rn>!JrNJ43SiN9Iljp8WZ&_^3An5U*E5{|HC`A zLX{rRVz>6dKz@4!l|7_L$M}=vHYa;yhA74g;r#C4U2a^rR&T;9-uqkYP$}-KsBvI8 zr5LU3m)(a{82P}BVTro;4Y==YU# zW1kiqa$NxM4r_{MttPh{Q9rvtkZ;DNx%NhpHD@vmFGcWLRg{*%e zH*+VJCu1oBWw`LpP3#Fng zIjxC>SZ|dU;jCv2YM3LY8DUc|r4~l6>7V2wV4svXoLn7>ONI~|4&4A5d1}wWr4iDz z%U!0whi9)@s;p6H1ro-uBr=IE6xa$UDve5V)U@@uK9@MCKpXZPK*!1{4 zA3~g?>NLGB7WX@b1>``UE1n59p>GLeJe>>0ol1&G4SPW@rOD;>mb&B`6%})Qxj(A4 zq0koUu8NMqckEq5_}Vtjep0d*-7@8kzA*o>Z7%nQ^%FxoYFFTL0(&S<@uoR;31F*o?hghdt(73HTelXhhq^9uudmt zm^kQA_6dUhc@TI5b#Y-!VxQ_UN(7)xgY13Sb1gCw%e-D$`No!U!@s{y0DTC2Hi%Pc z-VE(?Akk(yd#P#`{-wLI;={VKZ2dgl_VD@Q$5Z}-JpMJajy8 z)RQkfcV#O_@L(eEzu<0~vSO{=ki#L~mwWw#bvOxY(>AGt!y&1jr$~b9GJdLW z66>S<@-)9V)2~pfsqE18NqzJzm=yU1g&ggK-fj3*7*_Ken6v%rWAa|pUER|ij*dSiJDrVGJ=B!*l6lN!j|sgq z&*!62XS4T?*;Kve+bIh(O5Un!Lt%y)coSqZhE$pptuLVv~C~6CaFqU&bzSBND5_ZoZBhJjk8;vA8tKfwc~;p(+C~ zdbbyqrFd#}+l=V;wSIZZYHbniR4@7E%{7IJKm&O-5u~^23$xZKd#h}}M?~&5<||1~ zoIT<-pqkKOLphw<9~5bOkP`L`N!t-Jv{XxI-)HfF5sAV~`~Ik2UL0}iuG4&);A5wPdQwshqJX}?iUbJ z3AH%#j$gdB=E#5UUaDAV(L?*jci9lNoOsPyhEwJE2ey1_NedfSMgNIu(_RFME5=3g z1bY%S?K!@3*z5g*v|)HJfixr#5n{fXzIxYfS&s}nnfTzl(HD_^ZvLxO!|aP@(+XrP zI;pum^1|ogkCq*wO}h|9zWYo~Y57hF6Hu9UukVnLlZW#W_rx!?q1pBpq&}C|cS@;R zDD1TWlC4B8vAgC{9%k*0`679yQhDz7>WPoS+Icd88B6xGe+6pgeP=tSzHS@kpB>tg`MFm{I*8e%q zMXz2Tg{wQ%qx;#SE*avgsC^I8H@(6GO(x6lCre8KJmcG~Yw3mwEQ36Dx5>GGzlz9= zyiAT{%c~Tvzma#Di0}^nEPsBa{5}?z^HyN5KSL!ez2-L-f0@MH-CSSNJF24m-l2pA zu|oWuB~O$h7B}mU`3sfk}F-+S{R0AV7wmDQ%bdUiRJu z;WWO%cOhTypTP`Dai_YF517Y<jSYU}Qv6tyFBlPiX%%rjjSXDi4K}=Os1UE`RwL#{SyQ|B{gur{QbFkqaM_d^> z5_6t#Cp#=Th|Dj>b;?ZmE|{b*UTA?WGqFw1)UCT)9m;9K_BeR)(?Y-oF|Q_fP95Q& z0Zgj->bSysfL`@ExnE)8MlkN94va`k3xksx`>X+WN-_@!J{#GAb#u|bDFN^+_SkKV zw&5$0+~zc@!*f-7`;8s1Umt4s8tX#+o1<>t<5XuWz3y~bDt$fn9UTP-Kzw|sRIf0e zPlW``OnU0Lj9WL*y|_m;~;b1jAaD`lgJo@SwjwV~XLUaVT5R zzEM@#lKCThS~{7TJ$MDMPdBiopm&^}itn*5%m_%@-2CA(sY-w72en$Jgn!!GS31?t zEK-6G1KBb5!(X^SrMd0-K zE0Dy#R*<6aevXN)4|x-sDhNEtoOE z2=Tgj%C)TRW|5rgeI`aZj}`lMcLVn>ikJGbefP!3I?uk*Rj3rH`xSes1%f@^&*j-e z>!y^j$E50$0$j$E_xo_~6l&ASIZG8G-PIQlAI^IhxZ8guUDuYPN)-Jik?12RNkAkh z${SfF=kWEj=~=69(54ZKqUwYlxR48hb77nl&}=?z2_QN4P|CNe$#6iFEvB6$7hqDu zk1`Ri%`)>7ZX$;-4n48>5p~XO!mhVJ_<>u$r`Q?dTeR=7HwxZtQP{}E2Lfhn1tA=A z46Q%-=>q*lyUqQEpt@wfAHqIo^i^iCJ$4HzJ{D@bf%A_4FHkkVz6|FsWYT8=C5gO1 zv?)I8nbBXwx{VSf*VGrpLg_(}`zUV+xewEsh3XaaM6(RtIEcLl3xCW6xNSt^%!)Ou zbyBAuy76#xF3WP4%CO&lc!I29MCZ$D$h7z4@5~e6uiU{MVlTu4yOdz&wAn-fiRrN@ zy+F-R+1*2RCJS1-d4ht($#Bb*3f$v@UUyuyX2isuc5%td*}=^w&q&2PqAn|A4w}52)Ha0 zEmQrJzTEABaBI4Veg?U%bAN=fmh(lmQK}SXR^K0}={DJMAJsguZ;5IpZT)G*J=q&V zXHkO2@oI4qR$=K5=ifK_yiXdq!6)Y1-rpg_6OU%N9Y%g~--!pw;H|3VZ>xl` ztR?}AWp9vDb%poQNRyTtXqGM z(_3>vrI(+_`J-x?EpjanOZ8{ImDZg;ix>BHhkuyIY2=B1{6@&_kbqJ$!R8%@)I=sq z!gnCs$sTi`n`Q^FJD=;sN9ES(Kv>G+4$9#|7`IfRMm#`*y*cnH+n)#cUry(nGODTW zB<}^%HF)!=Hm2mDVI4AXSmliRqV;HcWL2^k>V{ySr4-ON2;znD`TRVhOR#V6js!U! zhH#@jkUGCV@yY<{p6uHd1u0S-U0ZolFIskChXUGoy6Cvz+yA8F)I#PO5)f&?Z^z5w zdZu2T~o?rL zHul9r4$2taP~MT%K(fC>>i|vR=E3jH^YJCUM;24cR!eO!E>7k}IRk;P8K^M+uCOwB zo|@2V;VTnS%pH1~QTyRYlb&s3KNw1aq*MxE(52*=Xv>vQ@n@&e?P*WEF5fW-zhlF{ydI6`BK{xvI;L-`qE(z&J$adwAfRW8GtIi zIXeH|*IGGU8YC5fkdqmx<4f1Qj)OO7Wis8etByYzDEiA@KTw5FKVco3Q;q=L~a_&skcR(gRu%fHfmojRQA zUKQ-BYIlglT;RxKXdbfGk0Y>qs9P3~;MX%&=Kq|=QN42%%=M*0{^03!Kp?hg;^OJ& z#4(OWzw(~<+v?tvI)B|>H~Da~Q4|!EEd;w&$vik`n0MGqiUnHho`1(BjD~9{8I>xu zdgWW?{CL#jLx%o%!SP8M#3$kb|2|#azQ3;iKF#Cg;u3k%_=W+vTiW51n*}T_j=^8Q zvs!<*fmN|MN#39C^y~c$rv^}6_8LQbIfmv>5EF`fe+vWNZ!&U7hFE#pf55~)9uk|ZE!$<;PGLkW0_Wf=?wK`0H_m`nd%EjUfN&n{>#BWKYQ| zCUtM{_e}a!Jk_Y9H|J2B@`+$zMeO?o)qMOVC7_;KbJcyg#@BZOXnudSK`gp#!#Tg4 zbE7cpeI(SUqb+G4?vg$+snRfRr$zPY@{PCd^vyY>??{#7T)#_gmAQiEm%=7Wu12RR@ zRHSzfV^m0w1b3f~($xWDGkq!%pVvPy?%R=;58nKz4mHpr5qvXnp&#U|-eHdlU$Z1} zKNw-)Ekhn|aqOqLp#nj8RHzm zfY4btUVK(3i+yu||C4|wKwbV$X%fl?5@_Dm9}RgrJJ~t$AA=?S&>BqO7Wb+l9j{Ku z^W&8L02|fbV=9^w`)&NFPMze}|BmH5Yh^!(HQJ@6?m6egot5=_G|vcH1#zD{!tX?k z)sfC}en31Ttm%UQJd_hacKaWWpx{2`o32;cao@ow)bk#A57A<}!Ep zO8cmzdmFy=(TN}A25RkQC%2M22~UQCz+&5Ae^5-wG=PciOCu=vQIz#noW0fO{cW64 z3C&tiXOF2i;iS}~Uv5vvS2>{R@2Ub8K=KncD3Dmf;l??2A;Y~{Q@p?j-g{}+So1~R z89PAX9;-?_+{f$o66qz@2-0d+?N_7Pa?@PDz1(VGc#O&W0+U>Buo1}y_Dgu5<74aL z1kfB$nQ_j^LSO@SK^?-O*H}LKuCAM2UOb3%c z+4km35E2E^q^xQn{aCfVCsNg8y%0K4zH4~k0P2eXPI7%>tb=A$BRh%5N~t7@kV1R$ znCV75gE|$fW9^NoWb;Mx$Hc9V>)~C=df!`OdpR9i!$k=%H5T=toQt{K72>2jRmKqd zO0M&+Ng!QhsWvd;ysX;F!5PKIgCU&z1PD@sWJL?n8Wa_!aws3o_rfz8mq9t`*tz((EqLV9BBvVwpf%M~P6M1)b} zMZ|AE{}l!O)p5`OlbePd_0cykyb9axHlKg~6+L@*Il}vD^7b|NQ`B8{i(Da3EH&#Tvi!L5A@4{@U2pG@DwUKGDrKBw|l&9Jb9HW>_x zXzXIHK9u51u|ch1Q=r@G)K)HR1hE4ZxUcBxHKYRdTS!$Y#hdwtz;rs^8)7*7vL9Ot z-Mr2Q!Y*lQ>a2_$g4%Q)G~T?qGlwe`Um(iGtnZ5^9`?OWx-}rgRU_ZL`~V3RVrM7-YDw8!V;7Xj8EAbZW5e0pa6(y?PCw z6FeIduS2o=w?exDNOyhDz7BxI7@WlrzEjXQL9n&oy$Y&L3_}+hl)u^A6AjPbUG!fM ziCh+!Ils%3L3LMxq*J>EVQWLvW~HQRPj==#&YbaqclEKaBm;dTXw{@or(!q+Tdh7n zG`1aL&qKs-0uKWQQ%TJN{l&5Suyf9@Q(_m?jeRgM)g^As?+^QqSBGN`vUgiT!*NF& zko$cHEa|7iq_DUXw*z&OHC?@aYL9nc(~zu`@^XIf#Y$5fgxH!$a^Al54)C+l>Ts7% zA8ja|B<^@m*ehGC5n&wp-{R3jI>vBbA1jTCD#9J84!S6fDNyb}l2YsKmKa52zt?iT07jbo+(&Fvu9NFy}1G}^z`^(l;r zpaXZK%{2G7X(>8)xP2yrq~3W81tYP((t$0yuREx>5r0}c65^io;T(J zqWHnHi3hdT7o-CfESBF0Ydoa&PGu6aTfg9rX5%ALsN9{#!ydpyM`iv_Isbui=RiEr zW#3}<4(!VNjyWit;LlfDVb2C;%BJb@u6J|5F|{Af(c8yX!&hc}UnOL};VzbtJTlsRt&=s?fs zs|^QBIN!u;RqQom?`MGhGLrjZrz~Y;L-XjB#hLA)7Rb<`R#Yt>y7u;XnhG6D?#as7 zBwufmeBnh7B2M7;?3IAUeQQv7DUwl5w#r**i6QoNFIO({S?Su+U%vyO<6wUg?YHtP z3g(2|p$!%(Q~A512}!|rI@9!l9y)K+IVM5(Eu2={i!!ziThmrHhGux;`x$KoY;hEulGg{dL;$`K->c!B(MQ(i6drpaG)Anp$~<&VFH ze9MN_&vGo9K`J* zTR$i$<4RdD)M}S}&l_YCA=cs@)f8c`{sQ$XKq32fc=o>N9=?N4!8C`iV&i==V5hsF z=XwIT66alBhAvSvHo4M=dkeuw{?E@`Lqu9*vIdlV%hdNTD@;g+U)n1Hd^j!9-h)5C z?da_BCs2=9?YXY_Zoku8Bvo4q>8Q)wKAhtlClA&%!Q?AJ{Qxe-w&O65{uO^X`CB~g z8B+4|))|78sp~O^3P1Ne#_9eAQ(dQw{VJ#5#=sDvZ0b|db*XaI;^!}JdCqtq^3T@? zYz2xSc%0-M`>zl{K5>fSdU5zI^IiA`20S%omm^+3j-xCO0^gGdjdd(#W*JaHvJlB0 zN+7!sZvAopa`E}v498!_^2D^jx)Rc1^CPSiXW{kl36^b$q9rUB@D6m9nlPkE94uH^8nd-Wnk?d!!FziAEvQyS*x}LxBgj~AMqs#kppvR z{piI2ZQL)C*2k%Ke@KNEGR=?ZU-|@Z%un~dE2{TCE0>1(K``?KccZM9w)U-T3iUNEFXm%5VbJqG_L6L?F&viqF2h-~^|5I%Sdm3!Zs~@BJ$<_Ywlac zXX*MPo!@cr>DRTY!2&vzDkK$In7<$P5qjev=A;+yYWuE`_~ebwIc_*reGi$TD*bN7 zEoC)m4+r8=gJ_%K&hP6m{IrXD5MlUxUt`vCo!{mc=&!MT8jbak9zp!y7yG^dr|9lT z08SyY6Gm29qPIya^7$t`Wbo7iTMr~chVd)QSs^bh>W#b;f za-_|^trLEMfi?KZrH+9n{ZuQfgEzVeTP6qUC_-?GP^`Y*KuD@fNM`g!xrIA7O~@}V z5CA#(7d%g;DU>Coz@-9u4IPBz6vrL5hcVg9vZUmor`|p@FK}?E11vZIaF>5tNdnB` z4v(yHSK_aE!jqqrXi;xLf#mT%p1uN%B+qt!q`^$tU^0ewZ(1AGdWDY?4-?@Kj?~5b zN{Q?ze&%`(gRwy^zv-GM&KOREq=W4yo-F4Ei;1~8F&FdlR3H=~2WOQ`M4A%!o9_!6 z-_FX1nf*A&b@Dg|Uex{-PKYXHnL9xfoS=9y##m62>lQ3rV^@+e zWVmWym2I)(Loh_DbJ^j}v`My~*BE zy^n4-N>3?|rs(Qh=NK3iX@-HNVc6%dD33<>(2UI9JnQ)p9IF_v7(HPU0y&P>L)jU1 ztMTqA$9c<`tNPSiAxO!!eLmDzMeQ4+-TyURnQgxfFiV!YmaR~#2|mS}wLQZ_tRjKH zjMEm($rIJ#gUwTDIS&59oSiE$UlR&bvc>)gGT2`V^O$pf8Yg|}#S(30^N2;%`OJV9 zgd-FnPgXVyBY$83^-oHJcfBwDSEZ;A|Ja<|8*f6m4sW<1&9e zy*SknljIhDU-bAyXbV+be;Ev*&6QaS!um98aNrLbVC^xv_UA(|eFAD8!t*z{m-*93 zZguhn@S~bl%Dh{VaiO_%k1LWdWkoaTY}9aK=d1SU+RMdi9a1$mS?9P@C^@~?354}c zJsiEQuX?@^LX00WZ%^0aGJSt0e3?4U$12!tjVm(^hKqqnI7ooNm=k? zd{QtS#6Fn zZW(jV+&`dsW_aEn@!a0+hJ3&lW0-E=5ZZRBF9oIm{Oe0}9zHClP<--o^t4#~Su`Fu zp3bn12)18bRNZQF2uzFTx9OiD7dyDXG&G$GI2crCpjO!^5Rr6#pU;}I?2m?={{0KR z?Hv2L^3A0yCnr9!~@vEL#!b;b?&Y}!8iciJ!phBI2&tybmfy_XcuvYez#&>lcA_(`ev zh7k{oy+H^a_;|5h+_GlZMS|nFvKpU7}0rT9Spxe9mZdych8O74(Dr6=8n~0Z8X7D$(QfiQ_T((`UdzTR24zb={a> zHW5$#!fnubz+y*CdS%9?gF|3r=R(GqF+i@qkl#acj-D`vNClJp@zgnXcg+VOwXebp z<(@^7yQED@}PfPTe4e?2&$-{tpRE4s{=b*##laYIbHmOfWD%6nOcPz z-of@B!LfU3=I1d_G(JE|w4A+ZKZUGr5g#2CRd-LhjvfF5sIr9b;j zpQp&>$4gy1ODd(rc;13wh#|Ftn(6fW($%W^KF<61hF=+w z1TxBHHC7Yd(_E;)>So21PO&OH_!LHl$8}#hWgHu=-PihSnm=MFchVjBT{Vv`tl0P) z14~mJM+PTA%`(<)ryzy~XTRMJ%+Ehxi>z7rJNsIA>T@VMlpmynW5Z@$Pqm>YY>NFX zK7c3H*?G@P?Z-MjEf!Pc{4H4SzEYhf*O5N&UQS<(LKS|UgrXh-NGYl#OQbc|mJ!sx z1c!D_Yu=;j{lU5T;0hv=wufXeU!T^i+GQF<%4qIVzrw7}GUyM)VLAEkYJT%-nT>hC z8ABSOJO)PH7_ zGV3y8%dS7eeyUMcz~lF8!a|LI;|H=1FJQEgGjQqWEN8D*eIC!?VTtLUb*9~?vrY@V zOeWa&0e2bDG=27&%UM(=YEAYAiJ4{$&}*i$XVPb(BL5$TyQn8QJj zf%t3ZqgGp9ipO_#m0sr};K^)yWNm$}bBJ-|=Q(oyQklgiFvrZVeg6|cf%-#v zZSq5WaV{r6k;Mz-jFS5`6Fw&JPj}JFzY!!Y@YM}@QCou>B$6IR#P-8or&iprF>m=`-B~u0InOUU-8yc8TJmOEgiU!9=Y_t%o}*)@;Y%?; zHl;_e^)NTuJ*FoOs!ityKaBU-y`IKaZiq7%M02?B|I=xcJ*T4N%$`fRhDfXc#~w8A z%A+DWBcGbZn~t56p8VE$u+!lMpUv-b#!F_906+C>rM>#o!NB$fL$PVI3x4kDofJJf7%KT`mk$ewyR^p&T zF)iymR~>kKpK#3n+~eoe!Bvp6B@pCACa;iPOYUc!!todm>>kN|;@?6h>ill9A4g+B zl(b-t=(iW0aTe^VM}rm$_$IPnyZcN-YXVI~&sLkIgu7VJY($++RF zAGVb!9E>8W=Wp4>J)l5Oq|WfsJjX#JoM9ZgJ*QE(HsRGTx-2>DcZh4S)U8)i;&Y+K z-fz@tN@Htok2R0R~+20j9m>e^n&r!Xne|-$4t@1kOV1(>j;wsXQB7_Y1Ry;Vv23)h6 z%0*zQ^og@d228w{z4IeNt|o3EGV-&!el}}#6(B+TdQN*tQj?dYH!=3`A8XFJ1yjMB zTC44WdIWzp;|BvB;7^T4*ckEmV(cqrgF=A)+wYqKu%2-Lx|N9V4C*pRWS0>e+>RgU zT^*sMcLe4jd$W_VoM2bmyN?geEtnU%#Aps;7da&n`_V3=RUC!XAr5z`dkK-iuZCA=aH#2X4`y7@heP z7Cgv~^LXKr%YTxMXP_MbZ8KbPbv;7`zuBVrW@@a?X#M$7U1X8ZPibwFxW5vRKeht> zO0Mw-TTVr&y{>KOvoEu1A6eE|UV1LUd7Q_0tu^ELck_*ua|{Ts*4a z!la)rwME-Q9h?;sX1J>>to@dz#Gt^3WLFFlk`u&P-3}DV&>jc!1!wUdO6B-_qVj(& z+fXV?{;7~U62rpG%jsl$e-L4H&+MP|=rT|28BbH*9&~ZYT&BTOGN-$e-w^gi zN<{$|-}bNj_e_P?6KXK~ov#e2SX|^hgWEmzoj4uzr~`SYi=tx>dr?u^pS@fEgAUx6 z{W7Q9O(2(NO-+MNHUM(qh+LVQ>+&(y7Z?If5>zxye+QFNxc)v@c}EY-dleEhviGA6 zo#*YF{rhpMS5xtk>RYSl)dQ@a>GFKiyhj6wBzeLN0|?cAb@^%0)I0ym*T{0+I_(Dv zkmOmtbz4lVOqksKGnUL;$fBXqy{pM6pm;?GG#Fwr9kp&*tVRLU7LPM_?E4<_Q0VMz zC^%9J47=kpcKIvwp{5+Oq5Y19Nu>N(b?wyu?#(NH8!-cZ-7f@2{kmm+Kbc{W+plSA z?&J8!M8gIz`~>;>Fo*hXO(oV-N7C1Img=F+bF^mY;*EC)pVGH zTZ_%&gEzxuqf4D`{8>Srk@fxShi9uwsc-M=3!f!161EJsu0@(#&0kbS#e(~PZy;Wf zulM2m0r51d&jAW>vU_5`utX4`>6pQg#N@NYJ3k*2?Y7Z?54!*&MfCGYDfq!ts`eo~$FY-))t8j};tJ5O!1;pc07PXHz|XeG)J5|VoCvo=oFDFunDW45`m7M-VoN|B zw5T8{2gV$zTNC&9aQv!XpMxjU%&%ZC1%zCha$8(Er0J&2#HWLo&Kvi-^E_1N2O&9-+=V)Z4HT#B;5B^79Lz`? zY|PgFesCUPCDGME($Q_zqc*ZFZz?$2(fbVAmyNo*XF%`+^?ZYt%)*{4G8vdE7O9cE z*0Wo!CI{#-cVgdn5bqGhLvfJnbj}0>kCiX`c{hEl9)hI2b(l^B z`6E}TuulB*$ggX`3)1auzpg;VxXQEG&?B?}Zy~i9eqOj}j>GdemHzX+F z=RwQdn#N*Y`r+dmJz2<8G~riRgvJBn=Te+A(h+yxjw?n?b&W&;lG%D4VpmpU)zI}9C@{P?oWFNn0Nmw^B0tlyro9c zM26&DanriL{=iE3L6V|Kpp^xq01#!Q z29g8&T4#m2NzR}mzGG2I7l`x05MUo_7M%UIEd>8Jv*brW7K%5;_yDOi>KC}~on-qd zL)&IQmcEvHjW;NHXsSc?CW~kZ^HcM%_L{VWPKO)%jqi${Is`yseT$n8Fw^}Dq-CdYGP8{K zNN>`RdCG&iKwe}?#FcO<;Ml(Rr^N^3>!>3?rS5tc^Uwrp)BRIu`V?Iu5A#w251P{a zM0d$@S)=;?En@5kg3Yt#WPl+)e8^Y`82z(!Kv8NCHiLI!NN1fOm*eRtwr0jBt}3wKp6mHC{BHE zUm;qOv+>b}m5^BX9b{)z<0XlLq$JNp7LMLi6WROlOgAo{nWp5WVrdWoDn-X9$wUPPR=F&sk4H`=vSI8-T%ze**xdy+Ux< z$K(4H{&hmi)BSOD_kD8uD6Bb0N$@)H97yx^!tJ}lenV3r2PO{=<=-taqzf){-RJvR zk)tPPLqN-bn|qrTVz(4#|HsthnihMB?2SE`xWT5KMX{t|F*!Q( z@%!r7C}nRx`fsO&)XY(OFk?7=$WBY{7Yh$7tw#}kh0&Mcahs^g?)Mk#p{_;4Mgmu2 z(ytBeSwoIq03yeW`GF!M0T65c*!RDpS0$g=la<^l$$M*BzKQmYArLu28ysLg`it$p zh4_N9R)2`m&jQl_HoRdaK#y2~VB#ea6lxM&1m$WA3I(kJ$-C9MGxhJ{T!Ra{*LAn^ zJH&q&#ZS^Rw6|0~Ki8xOlf?Kv11mm=a_XLbO!*$Rr&dMS9R%$Zl{!ve7v_tVV4_|L z?mp3j+&pk^jZvg?-+KcC?>%ml#ZfLOCS_w_tt^#j*tqKI2lARX8%M_Buv7GhwbveS z>g86Fit3N~xcusOrR*p5)bT~^nS}VwCj6(X!MA65e|Wf|gniFf4 zgZnZ(IS45$vG+V6VNcdntI!*A>fyDbz2RzkzCQ0Nte>FQcEU<8cz`PFQ|^J_@wu0s z=r%%s^vTnSqLvM%_+OYxbYbl2bS^#SbiX!9T~~*4{f4=j3urzE3huTU0rdDe_g-L} z=~nnW&l#FNe>!hB7)@^8ZrTP3hsK$8N;*72S+(}-$CYA9HZ2iq!kVW$>0 zSm_-hGoLdq2W{M>o6Bl^m$Y-9A3y!^n$D-WPx~KznJ~}-Ez@ZfS7UdY9spoy_iaDb z;R+QXYc~`M_Obrb_u3_dpfQ9#j?njYo1?T5OQL?mJ9B@H_lJp8}R$CYGY< zQade#NLy%I zS?nnCAH}&zDv0Dnfr<^iYuQZ$~|>WoW@- z&0VkHI?WXZyCYda|K&gkPH>bRoQQf9fd@ zjGEK!d^bhtv|}I0S7NFi`jg%zg(}8FL9oDB5ehXp zPp7#aG%1DR9YKtQ%m)#UAO+fgJ;?jP?<}vwTVNS>Fn`SH12l#oi`qbZrM>!!ZrFGQ zE5p7YbV}bC>cib@m{jFT0h_TOSs#h?h#Gv13e9yF$(B^d$aMTBYnRwYd|J8y`j3TCiVV2u;6jzhnY7Xxnem_M*+J_NzGdgr{Q8Y zviCNhtf7uP6_KP92=9tG@-=tBpW^CHe0_ZZ&>DYc=!$HtkW!V*SXezi{(guU-{{2A zNKGd8=PM&rn6eJnt=>~FW*@PBgMC=-ruWrj+>_+)6<>N^GvBW&LZ7PAN)G%RGGXuO zH`(v>1G$KmzS-GD74im2;HMTn`ZqMnlS2o#w_DGxL|QG?G^YZE71 z8=QuG4IKlF!n7&J+06|Rx&&qLz4+Lw6{Jk z%?n8TPf>&luFV^|_VH6Qcq4I_ZXe57t{?#G8n9g!%iRaXVnzxMRZI9K&o(Mbp#+$|2~mmZ)%B6H$a4xx40$A#}^Uxirevrlrz zotUSNWDBi_dvMTB7n@4YuhM(SUrZn2a%q=}BzE_06bm!C@P(0he9#Bgj%Y7kGBv7H z5Z$lbtpD1_u4OZhA=A?IE|?Wp3SO)EkJ5!-yQf-Lma4nI9UDlW@7yw}AvBqrry?Gn8&c6d5u{ zdI)E%hUq;Z!B}_`SS6%=rzOn0MogCj^No3aK36GCs#UempXR9SqbM90rJHET&mo=N zt9~h{)|WClg};MNCkM|+l&KXQwAiP{NlrVuPIB=N?P&~f z|My_*lWihccK}y!z zDv9h$S52&N5JkKZ#H{ako4m2q`U{~;biYQEakYp7r2w0iZpz(-$C*g!KrU1lF09Hm zL+FiM9A}sq*_n6RyaWo(S-*0X9}pLUyb}?7ct7e-5`W6-6TM!|8+TC3Go|vjeKu3O z9Dxu_jQ!r1r* z`j>n%;ZSPu0B9|*q-eGW%CIca9av5_I|lcYglx-a;`qv6Orkj!+RWM{npk&sORD`$ zVRd-Iz^&O!NaSO(XbSZh`N{1M2H&p)2M7~4uLXuq_#8>~QdxhAHxpiU&hzl@aA8gw z5OC8Y*Vps)IdSlQZ>^u0m_K`;;Xw~1s|;uPHy^hf%XVl?mFP9yQM5S-X19OT+&P5m z<^3c>1P39JVDuO`ewBf>s!!t$6~H5qs{87VAI<`>0=jI^;0W#CzKQ1G2QH`rB|ZH1 zP>WxyPYv_cfY- z{q+4h{9ynOBiWiZ7x$Y8pC;w#+HTs1cr^@f=oExLukCBbC816Kvs|=kzd2CzOpgSJ za;{a6KetmxZj4;eU?bp6zpv78FNX!!_opXH@3{qjmbfN|LmZ=ZZozA^*_;9vvG_%e zG)lr*)AfK?uV>xotKW0HYpBC9$w7!xt}Ar8g?)U4+Bi{P*9UaQH=GB(n&Eo;%+S$- z$57sN*{Z+3CE-_p*c@m}lr`4yOMNB8!<<Z;lCTW%EjUnj;3@gp|Gp{fCz+iK={tJ~3I2%Gw>)J$VC}bf!ZY=ZmGPmYYIZMPZRq9kj_SDUtl*4GUPf@Ujm4MSTtv zAEV(MoW?(F%p4s^Hcy)iOjHa0z~;XfBoS6(2@OXMg(f{d^7in~m5s~P-*WtsW^J-B zUWeZ944sTZfp2&C9bm}qK7VY8?~g40ob4C{0m^rgHr;2QI|E<19iDF;In;B~F!@tj z_Q^93CBLDIah3RqVMl$cSYjzpqdWdmz@MHdgePhC%Se@mOHpojXV!L|DeWxybVkyl z+l*~6m}f2!wv2PAsO!Ep?x68?HbUeAVveNePHs z-OoCx{laGV@142=8!YaNCi^S6XLW-GGvn0K36T~!{}j-k@2NiA(FAMjJxGJcMokY~ z{bNr9fYU1Vb}mzwH!h$r3)}-O_$WTf?p4y%$JQ@I$~@Y1AGnJsS=Y9>TyK!}2b;Ha zr}lW1#i(AKZ%ftQa$@`EXDY2HmAQ!pp&)^hAC|WvMF`8M!Z^gNnncy=x8&H0vGMCm z|6RY65Bf}X+jDoQqm&=L_bvoo_GEwc)XM_v=UFp$*w!0vD#O0eKc1csG==l3rw-AS z@G52At)Rv;iNo=kLbT8&e0E<;`LP>e{fsIXTG2__l-{QY8lo+}C0U{81S#cfo}6_6 zS!*%7vG1G=ftCWW72%q|fh@nMzt-&U-wPc-$337ydTZSNBI?aNNVc3)g_Gs7stnIQYJsFtJ;g=XxL)3x5Lt(}%7JxzS9}|-75uo+qZwuy54z0CXY+)}b z)@c6ZN=1`mbTvNbYP<5Js1LiH40^A+B61^Cyhb)8ryKfymuqt`Srpky)E~a~@9K#- z$%i>WD#B#Q2OE+iV6<4g&CC1ryC>*U zfR_2h^D6hyIdgMPFdIBEBmVL`k+xLgkrsT4eT`Ksw_dPt>SxvI5^m#zdNoTW&IZAk z2Ty1D_Y16w75kVZU8l7RUGWBi;3FnHy(A2rLXMDY{_GffdNhQkoHmA>C{X!My=~gO z6n@6`0oi}$t+l6zok3_lL&%-O?|yDRuK^P$v5c1b9%6%3TYQcf$LCs}xLFVvNCqbY zIn62(Ys4nVJyHYKP*Q%a6dr$wsyQBly+K&Cxp|*pIj7_B?*?y zI0wifO)*V+AQINvfY$Pw^%My=g{k`rVpha<9@hQ$^f|lQqz^~m0qAF%xb=DR2~%A7 zuTM3F6MsVON^^x*Yb6lskK54z#`8&lK{&baw{=RUicaPF9E=m%2KeN+NEHiZxX|Ft zQ5OcToI!mqCCi-Mr4_3&!A}B&0jk@H5@H8+nOd#~+0qlb=BB)$PwdbQ#tOk)z&6_}}pUpG_ocr~F;S99tFX z)w4qI=XxY}E5Fk;%B~V)-~zzDQOaqp+r3zT?CDAJ${1+T&#=#K{d!fj{T|VX#SihK z&lI6iwzlUB2>Vs+?3f{e^F#;{cvHAIG4Op2N*y!q^|KB31!6oO?|nie z-{>beoQ*Sh84!g{2pU6Hx3+RTTkUD*z?kC%m;vkS%HPE;x zlDp{P1cVV4rq0KGsFpM+uT>QuC67c1q1QW*%p#)6O2+O5;LWr@)#qw6dUPsF+4WL3 z>#GZ<_1EykHl%dX4oqD9M6`MU-&1?4cqbuj1>ZL>nDBs(ZlJyq;^SJ=LjMUf7<7&J zgTduzx!p)`H)ojQd+%4*jIR0IDPY36I*x?R+YCXHy)&l5P8B-dtn3(); zpb4H^o}&?DW+mnKX_RM+YCmzRneTQuNb({#4*Yf=cmB%uq$NUXwq9YRC50y+t_c!6 zV6$^PPP|l*aNc;3c~&X@YC)=%l2lkeKln2z#My(va;HO3Jb$;|%I9#%?GVzJ_cH%Z zJ3C(xZ&0%C-r&7tljb0sWh|P&-x@jAXkTUU8PI(FsPjB+=|vO8z166m@LNcurGfKi zY)vdJ0lLr8f^VjK%K$-jWjod1edCr!1NVDLlZWCHN(X=3HOJC8{W0`LsG02royIdK zm;jxF`zIlJZ-95C^PTZPRnh%@(KJuQ7hZR2xNqa-H(VTJ#U{NcSMyf2l~^ro3~lxC zaokrUTCvZo`losuTJLEeOc8yy9zSpbbVyPVk4izA6hNr&5lPTojoEfvV8^WNp0vwJ zLn4K9#KxTQ@YU>2ltWV)Vk?49SD4DI^6GPnr^1;xYD>%^Z> zHKC;*RT*|(9)x5x))J&6(~t5^neOdg`)G1rup>TF69%q|`|6lRuTdGWG+yU8PkDGp zhUwza(K(+hfZB)-**qeC*gRDevlW8MFa1`osWVyw0`hRRCO_q(StV-S^I`rW+^8C`yjOpUefwdRQV{ak*! z&C%Vhk{%oaL*sc<5-!hWlK70aLBi7h+2hEyNkz#Y$=bho=BNe-+T7->lG4{$P zlJL$qS1RA`kZb#y36ko_lB{ExOz!N?tpW1} z!|gC##IG+i9kQdExZ*K~i^kk&W)&d%{d68(CX3VaVZT*r2Rxng@IA&=lMX_CjQk=- z!p`nhyPD!kWqzQ!35w36TIugy9ds{v+9}mS&2KbY49d%6H07} zw>c1@h|{-okWp1vw;n?$zTa<6_?BNOx)2gX*py65qPHG!)U@`XW#=+GO@6?7Is_Te zZtyeM3yDThmAbz3BI16_p&F1y+=lQ)R73xJ?=^KRpMm;U_swe8XG2nZ`NO%?GNKSMQb|RU6=_YkNA~lKz3}#A z?^u1-TzgYqh$g_(x#f*$E=oDw@8ETRT=~Ssm&f(`>#p)$JUo|Y#CJEui4XcU+3W7n z$bYB3-Z`>5Jv_}HogLR*moJ>*NM~;#_x$cR4BJ?hN?kAsU!Ra)=If~qmjV=qi}_L+|yCt1gGW6OX2EQw~uVHE5B-se7ly}r=$Gf z2RAf<1?*y8hy~S}K*EEs>H93Ohz=eyV$H1E5BE&ToBG`M>4o_MVeb>DbiGg1eJE^8 z{Rd$$%s08Dw(2#4jsEQ454jV*7!}ti&fv)B&2LNBT;Q(1^esK2m}O5T4u-@|2MwZ& z$DK`yj`52{)3r;7#>063EPY-cxFa4FZjJWqN_%aIxU7o>)3oR2s(watMs*hs9Q(Lf zD77z=S*(VLyf=@Duh*Q3UZypyt9bf8E187cC2k~nkT@Nk-5A({J?2W7rdv}#H>Y%E zNvmk6zN%~q`oraF0{ZdWM{zHB9&6tj4#zDOlAn{@W6FK5^#_Lu_@rJCj2K$%(n#+IYHegUvYByj(ERkDlLf!=2P{>oBklEzIIz;1}WT0izD!dSgX zyge!vb*ygc5BiIN81&S|_o;nEn;F=0Gx4?@kpQR<7Ykm?*sz2JXvZ^>Dt=pXXWdMF zI^CYVfxIb4{9c$`_1NPuP;U%=MOQrzPxl@Coa?=l`7K~nWp$9sc%2tn$&@1itec|VimY@egw9iXa{{_=@nwGw0arA>+}5HZMb?V#G09`Q=u zQ8<(KhZ7#~#)_X6KPOJZJ>jEJ+>V;z2*#uu{3M6PnuV_HiCI0R+S@?jAaW!2D;jwP zHVmmmR3S`5M8biZKUV`anlNQ(hM+5cjb9KJmOY`bLdKL%Gwzq3%+v21p1~smq7Sk^YA@msgE`REVcO-+3fbaLZ?F)BxW|njC(_SL^a+R}g{r-av_A zsmmd#<1tad+OI;6+WoK6SZ0KNJ;IFv|MvNA#xmO7X?{p^1-R+_SaS3%Cf?2DhAIEj z9hc_Iwi4)62V<_id%=&F&-bKX-r#^=PRk>;mQ$&@*H=4O*8}4@C@1A~^T*VPgS(Lq zH-8X_YMXxJ_B)q@SE%q&wOWEi2t*xvVd^o1L1zlUW9s1lDoi>R*Z5!X+OD3 zCtHn1ybu!iT9coyjO`apGYD9e>m=a-VQgTt_#_67SGAF5B#cwDgF z<4*J>n7EQSlTtNkA_Kb0&+|C4e1rQ@+Se9}`#hhNuz%bTc5NlFSpXAtXZM1WH6L1J zUsU;avA{I2|3L2~$|kAru*w{7RiH|SQSzfu+H>J=(BI%`T=)?YQgZx?qu)vA^RF_m zNIzyHO)uf=!qYL75B zcR?@wv`@+3Ku#SCh)bOs30>)2$H)M>6>!y6TM8mduU?)uE+8lEQlh_;Zy%BOw84D6 zha4}6zC^4uf;7{w`HC@_O053LQs;JFZ|wRdn|ETT_Psbn#FKK#V?*zUR~nj^Hs~ik zIULl{kT_hNXvdO=Yx+mllmE8S z@JLJime<)kQKkm7&wjbn)93X)Q=eX?Zp7W}5eA*w_JazxFrpy?iKJ8JFAO}e=94M2 zS3?f`z{1IZ=f)Lr*=i|Va`y#qhI&Tc*?o*yVrm1DyyI^Bp-jMafetHSb+XdnGP~;dVN!dG~I*{a|!Rs#&zLCGM26iudQsLETTtQ*YwkXqZhYHv)=I_SI;*p)Gr^>;3h`oB} zu|}$~YvE`5@9aD34Shoh1`g-_u0dHX>vdZoqvNzk$c!$cbA#i##@N?o(xx4X*5(WP zCC80SRq4&ur|b!1{h{oGU&W}neUIb^kT2?^@5Oqa9M-S#)(h^aMjtMr)n?EI_C-7! zm2ACxQwMlkxaZfnLly+%TrZ8OVQ{}cL)FRHLRXhJLFl(Js#H<6g+=n>g*@ooslHqtu0fh|*A!MD0@v|!))`3~9LMCo zgDXO!=6w=VZ>j_BsD)MS$A?NMs}1M9*9NCBKi?>XdE_Z(laF%eZ#72R{SI8etbN_9 z&%LO4 z%Ac?y1rWPxth=HsKl$(_@WJljcIkwIO|eja))s5~bm)E8JY4pQbYoFrz);Qa>k0a8 zhuG)1#?zrPH(Nl#2SUemeyAIgU4Qdh+;I;IbZc@+C}t=VG0Au`*W)G<)O~OtheH77 z%8b~{Z66)r#Nbt_<;aFuIi{}516-4io-6Rxu4wSUuz?lp1NQ3v|mvVVxkLTaXk7*}USyEfHoL=q2P&dfnc!Mf~H(rhZZEt>G^NN9KIEZHR-VJiDLuzkne^1+% zeR&N=?X~zaWN>^C4?&+WR0^Nlfm=fVv)>ee{wONKA)PIOc@u4KA^1y`eY0fZgA+gF zZj`K0`Fwp3W)9z66&jY6mAjU89rwv09OFcaR5ANB+*mJ(KfKZlOh>(KZ$AWKJ`W>I zZKrk>`Giqt`A%0)QquVE6XjsZ@R*uOcdrF=_RF4x>%Oq@F$>(&jsIM-pD)tSSyosr z$mrUmyhbquxgvLEF-(HX$)EPq%>FC!GCh@qXXE{(4a-sWy9K zAC-&iFF4)F?BKe!ZG)BrQ}ewq&oip6=3%T)RTG{6-Kz zU^>3Uavr)e2})ZFQOrC#DNah`LzRZ0q1+Ixei4>k%q)3U_bDmE+e_VSn%5q2HIA_4 zUC33nRG%NpQ+{dlESb|-3%YE4IGGA&P~eZ^aa(OUq|^Pr?0>4}Od@;QFWxYK(n4AR z#6_?4f-J(&#QfLW6@c?)2CAp2t90|YkLl7Nohw1*B-}R8q~)l^QdMdVx4x7;Nkfsd zu3GpwGs#LbPuqvq_4MQOoyDU>>LH@8ts%qy3v1J8@O=k=ovM?S zcyP4(y?)kdMjX#`{GvIk{cvQZdp}gGHoSmrX!qXFc13?zOzdO|ab?gJ+jy`M%B%Yl zDkn%iGfr+?q-*?s*<#*@a_T;v5o1)Ufz3D9#TjyXpXF>(NuRaeRQI|mV9%D5G}`Va zZ*W60cF7CPtQ6e9r3fx)vRw-AlpdaGi1q!S+U{1hHQ$c!w zX3}X>xGQg+&4YIR_Hcdw&M;e1!EgKVQ2pZIq-`?xq(A9-l2JN???ikJOTEdRnsgEO zaqE>UYxV*vQYn=`67hU_{Z>21CUX}lmEaHLVN#Ezzn9Q3#ij~7udutpR&=~(@9rZe zCrClvJKb;3>&t;QGdV04I`FWoE*@+O=_MVBlOd^`c0<-(YqUiR74QukLa6$$i??}u zVSvvolnoQm-Kiv!{8|s6zO9Nd04De+wB+K&$kRzK-!SS* zDQfe*UniIW6#~E;iXHwoC_wT2l&I~B$dSLdT5(fo^ zt<~~K70}I54)H+T_=gxUR7g!m#}hNp>vI7p>2GJ#))xDem+8s8+FKHx|p z0rSlvdZQZ`JkZ9whh< zn=jU?Sg9*>(i|SeZvs@>QH_-+w+#+fR@$) zBfwkU;U$+LGF%ZA{+f|c>9AXZxWr~3;as8!ZbU}217`ItHS1QysL#KgCg~nNR8}w6 zK8ns;aC_iO9!-Dsz_fAS^A@j_bArEgzrZ4O^7{Q0jyZ--;U)LPekFa>{d-WRV3n9M zm&Y%otP%py!os(It2I29o;^&4T`-(WD0h+4G13sTnq~V4j91c*Via^iBxhIdwG8{f z`AR~aKHec=E@}y5DyS{*qJe~sJ!&qgKOu(JTC?_f89gqko3p67vKU#sD_Q^et6E*h zk38NA;!P31>2`l`<>Pw?T_j+OII7n=MR@Al=UIG%rx9{;ceVCpwPBaR08F7UvM^-` z%0sfJq!5xhU*0o%rO{0r%x91hw*0oA`!Pe6EaV>XnpzELlW`e=7z60E5OAhDi}zmeMaPgMP+8* zQ`=qIE1i2Oi|iap;}G8XMn`L7bR{kb_=#t_J0=ZefSPQA=XiZ4&Ve?U%Y%3w*_?%5KLZAm!s=qc`6iF(TC!*$4=in6DRaXTdC^79_|qZxHucOY!ohfjDM<$W|8@rq#7 zKK2m`TaxDN*|(6)%=+pTNFY8?kNDX+ocRe8q{X5{(m|E_oIrD85_zsm`Ms^95&Ay))KYzlkO z*=(#}M_Wh5a}UTOd0A%A2$R+_rv%3@pKteY1}_Uif}hY zmzw*N2YAEjM{;a{psgz#9R~{CRy5wk2udmZ3-pD@GbfqL;z^vJx1w5V&W1wx{8i=+ zJLU~V-{c;fL{e41wBn;XJc>tbH^!Xo&a3%yUyy+ibrPJ7PaV;qe0tG^gR!{hYA6FC#pvB~z{=3D5wZIJ`0R zNzp~{(+uF?+Xv0{4DGx`p6}-kq-QygP})d0Hlc)0XbSp{cEt3#t=3|(*&PnV>N(!D z2i0eLuNkX-GVORlpZ5cnYQN8+|60-=zobwFRXc^Ea)aC;W~1d>*+Y6A5VW=w@(DJo zPE*@w)$_O;9v8R;_Yns^=;3jJWxC71_W2MrlDUpY#lTO*99x*c{eHjq3m{wO>0Ve4 zd6GPA;ymoFY>$SxB3LPnz|u+n_f0c9&}9xT`CO`dDgRs&ymTWrpgMG~iR;ug;7bdVo<2e6>v<}2$^ zW>ZAL2FDEy4_gn5&lTY|WevIwjs!yv)~hkRSX_8S5F?1ykG|#Y%F}Un>gh@bsK@|% zk$Zya(&oc1WfEJDF}^8HpYl`xE>g*N7E`%WF5h736M{U@y_e@;%GFwfgaWXfB0*bv zS_qO$>9=I>g~a=1+^fXd(i@FPu$o^#SJ&ShHT?Ycn(g$8B1P{jqyop8$)DqS*uFzE zSCn5N5WILL4Q(5@%4QqHK&EPC8%9woKf=Ee{^g5I0v?~U0T+a^^M^L^*Ys?EVIG{2 z;{Kgo_7k#d6VDK!|8+I>TN9;U<*O@)?3Ab()ds(P$f+c^jf_^iShsFz>vgcj=66HH zrzvA^6A!?jxXkmf2Ldriagq0MZRZUhSiqmF6E(Kh7i(b6BQCsOJBP8xTG~<^bqh(Y z+OHk`DX5EW-Au94x#)Cbrcja8BA>1T5NG8}#j^D@lfSTTjdZ?<%Ovm3#PX=|gg`?8 z&^)`FXozn=>I>zOovGI<9C&a8ksm}E@5%MhllR_3cyk0eW656$M;C7guRO}oZaujB zs+HC3NaBqarf||!!W(hiR9IN4s}FX+5IAVToIs%i79?nC`3376bQ4#i)+k{xjNp0- zr|_pn*-hrBF-;^4xss9WRST@JfsH&spJ~h9RSj>2Y9lMWsf=HQut!V?AyDc0^-bZ? z=(88bvrp5&>j>?RkTKF0b2fi_wPg()&%=WrZtg}9rEm%^711@ASyrlkJle1 zFVt&sFwr1qJYwPlxqWd)iWVYq_nEIX+ zh`2P+S(4dpw|f55rtHB@0@tnw^}Fy8ybso?ulA#qiJ-|T1!AiARo4_i(`cTXBUTqF z4BCj&o$Mcv8g*5ffjPo`j7Q-QZNiN~Bckfv8KGwT@C{Fh%Hf?LkqW#vf@9a!2! zTdfk?t6iSYp+QITFkL0UJ09`>ox!9i&(7aP&0ZU1x>UvoWK!)E68Vk&@+mnx<|5U5 zbr4yfu^c3L#*LzHwHHxF>E!HJz)1fH0TxXaM`R+cy~UEEwUzij zA8g5622aMH9G?ra$Gx6TRJBu7_bhn(8iwm0_&eR7bw8$lBZXmYJm3X?t*88QLeB#~ zQ42P|cUQfz9f3gse2O1uvwG5GKOnhxA2jf1xTjHYI?XJ!iPBS!?7mp`n6EKILbi(jf<+G-{DiPA{0#a(?ZYSH}> zIh7|_mHhYxbL#uK@VC)a<9*S6hY2ZK!ri=df4Z8Q^2x_SwyZdg)GF$Ndz=bpQSG(xMORH6S!6XF4d7 z_B#|lIy>d}+DgTLdyTFfGi$Fq(0v%$v?Sk)23(RT@enP7_bdKbF zKSm^bK>JfGS4~9az6#^zG935o?D0yzm-fuj$jA*7i!d7Qht;dGwO?F)W^hAFJ)zVg zUUD@TO=0foy)`l)gTXzKIl~W%eT}$KhX0kB#}`;||EjQ*kJnxgqk+JAi&(1a_@1=G z7Zg%oqQAiu(|7g*+tb~d3AT!?$WjO>QO*b+Glw@Oi_v4HY6ZS53-C%;Cq)7=54FSI z^UPbFW<>S0=)d0#b#bJjHUI#>;f2EmIM51O8o<_HSOwa1JkLaqds=yYro3Q}t5qv# zeGKl#YOPzhA6L(3cSDcwz{r}CY=lzjv+lq%Bk zg9#LU%Xf@S_@2WUcg>~9hD%bg_sOCU)AiK%`!IYAgQ~n|Nra$s9qKnH<#aOKC27L@ zHQ%!Ev0v7JlJg&h`h=f8Uy~loFbQR`REY><Jrm;%7RP-bc=j<2 zf8xm#0Rw6-*oj=amN(V2cc!f{|GnA$#t9HwXB{@?LGT2RXyn_?t8eS6tdvL}&Gb`s z$!#B<8BV1|`^ZBhTpb35fJ3|cxV`WwfJVLJyRsOty1QQh53WlpQf&9$ut|NW$zkL7nbg4%nXBM-s@*9 zo8NgDiwh+b@Hng-c2oIaNbtfU~huFxlw#j64!Lvc^8 zFZJ=O7c-SV98c!9i2Hi?MD`~S-qz^a9WIF2dPR>Ube(r)*LMGTSjW@Awa-K>EuO_3 zA~*!2_`3-U*{7z7v#OlqmgQE4^=JU3nyozv@9ml#BTo%pl+U^de zb(|yn+ro=taQt>QW_^hJoC5Xs34FhBq~%sbtf^7Q_YW5J_wp?4OGts!G-WYpV`|^I zhXh%)Hv1Tjpthc=?Snf<;M=28Mx=h{WR2gpD`#jUVx~J8K5<@2Ur@r4W|RLcr-6$( zz&?^HVqry3&%b?$$|292#v3pv=-PZ`^Zgg*>oi5n*kQ%kS6^sY-`%8%Z^EmBm)hI_ z2%s@}1xHR!ZDgqp`~*JnBrVY^s!vln+kN&*?Fo4U8=7ekVn}= zyjve%ZA|?-LhW8w@iAdjxD>1PDwh^F5u#CTg>Rvj5Lodom&-nV-J<|ufPJ6@M1i|paGG357%CrRUWCcZ^6=_JVyB?fil3+IvL#p`TMNJ z+c^C7l?-O;0dw5v)I07+kQ-E*S~h@t&D%aat$R5!@pZThY#~Nzu4&o`BvctpSX)nx z&%PcFgsf9O&?FcinHW%HAZBQ!KA#k1=?}X%eXUo~RoQhxTGcC!8-9bDc|7Y1Rd>i; zW1WdGG4Dg~gpBQ!TWwwzx|t@1ql;5$6o2V(8w(MPbPa}5g^YP2&ZKs=A&(cQs-}Jz zbp&u4)c8Szb6=f0y^$NZ=@Rebvt*96QV>`f2b0uBhhT z@`Jt~{StA0>7}rcg1pzYyfK#GH*9Hgsj_5r^I5CY_&BxqmS*h8ZB?xhN!m*&F>(B> zY=aCmjK&!uwg?Ej(s+pjoE*S|vL2Zk@1Sc{Ol%JW>)-R0J>G`Nb2=KBz1Q6fN9mf} z0JDAB_m@y7tql5iiezEL=?O~~d?cMGq5PxXhzdN_KK;Hzwo#C#q)gf#+AcXTs+>;E zF}V}=_2Tgi4296x{-BZpAax&%iLWGuw=eEk>HJED&mV{8$X^xVRSvUwReMV?G#fRQ zFi7bWs8sXd)Qp8KwMLc>0Zu-MR)Zm(ndiE&>Vu(>VQa<5%Y!az0v6cjAItuuxsnJR zMmH8fHShs`n}B+>bRv<-4fI~_R(FQwu}|f35dYvg_(-Ahy;(`dm-cAho6j}TxHi|O zdFJQg*v?0f=Jkt~Bqyok%oAcMlj3G1b5l?e=k((j0+Q9AU$j~zM2`Eb=G%RasFsP^ zPeqIA>^Iz^8^%^dwe5c~6P+b%tz1mP!-^uEryss8?jvUzni&09t(c&}J=Yl~KNH&Auqb~-R(xXqr)Y9M9J)ibmajaQKJ>xG3p&?aBrS$U5ah*5 zU(RsbDo{g0AZy43CIWNd?-wA<^!v{~(U~ZitTn5TD16#KYM;BISR2EoT4e+s0no|H z3A7_)POyrWmydUJqn{TBiB+TE>@)tyR!UjyoQy#5GkL3YqXMMn*&LsEE$74D^0tQ- zOXa=mB@kNy=5M;i^4xf^qF+DAz1k>fp6xGB=NYgUEI=wRr3xXCqBroj&tp^Eq$O)X zAH0U%V^K)V57#R27&A^cay}AS^zFz4?KOQmn7$Gb7cD5x1!z65Fr{>jbe%B|%O6XN;pfS~93p#_H9$?| zDj0Wqo}3X~sWSW77_*cS=|caBw|2dW`+3BUwcZJ)Hxg}^{hoGmdS4NP{x-Vnu*GMY zmfuTaPZPntY)miQr{pwiloG?TFn36oO~TH%wYWamzuK9T-rN#s2@h^DaO7d%OY={xK=R#&vZv-g`m*Zu7q{l-*WSvQLRww0A3X*gDQqcqH*{451M?8-&UP>ZT5@y0rUg(-bp15BDk?vLQ49O*7CfZ$TbPH z;rJ2Ydjo4oKeTuE;F|4#?SXr`ADht`AlH@i>*rYMA3Ji!@UTPx$;hLp>krI>Kgi^{NMl>j>1*s?@t~=$CMly8 z(To--=iO(wssv9q~d~KXB1SKKfWX` z*BRTP9i=Ym{h&T=-1L&9ovUW7Hv#1O+48FqQS;sVLtWtTP!;0}9dKB&CO>Q4h3|kI z_0NMu7C}T9_Qv@|D02r->M5dL;<#R;=)4LhQzo)NGy!&$Or$N{mNZEludX3~Sq&wd z_R%&#KAl&cEtb`Bk@Zw`%W_T`m(tdu zxGT#Sbt~?_hCqv<3aQ0STNBezufD>WR4lBK-TbG zr6^e!syi)D-#Loc3<+iR;N+)y)^B~up!bDc%`14z;=4g0-P)UOxsX_FyVmm>HS%o^ zjHOHa=fe4}|4g@`eV0mmdR@Kj;J^=e zyF^c4@*Y1d7ibYlEIZ`N3=hQFd&NG3p`zhx`jazXx#A!0m%;j7(wI09dsy2dG5r?K z@a#0Z2)kPl#B+UnA1z)P0Woa7*A{=ozUG85vVgp)3xTk3sm@Y0oUbh6;GU zU3LS|_hAOV(( zJuAU@xKfH8l6+NyL6Hzqr!wttpL)H_Rp6#*+r9;Yn+*WJOHDCS(5M@m07)gsW|>Jb zesJE{a5F-5aU$?11Q!%fSAdH_u+3jA?NGIg(er0y9aZO&wHV*_AeRh)V?PZqvU{SEs>JD9xhfLK=%V* zqoohmLkd09O9;fFI?PkZ$m8K>zwcE3M(5`FF3x$I?8+WvUQ(am=lQtj{7Hjemx44L zUuTo~Q`!$w~Cg4Di3HwfQNzU~jpe}KIH5G2SHjtMsM z!A$O6f!dw;IY(fPapNdvrMQ$_>v<4&Q>GIM_q-xLNLod9C$hDTi;}>UfSS`i;bO#F zB0S+U2zz1H5&O}7>=W(H)nay8K83f>9}4sViAA#a{NX1;A_V;S{%GHnA49|nV51}* zxM@=OF1_ye$`~Cx&l>j+t~A;i@KK1RvuecJ-Z_7q4e~BWe1=&5fEcdjxPi^BBBf-$ zit@v=%mREt8}rff-5V>?rQUlcGmztVQkLq68u6#^pB`iXxIsy(mE4u`lc>#ZF%tOu z6Pl#wt8Nj}^%Fjf`qHbzc*)ApVU!E%%(TPOX87Ds(#frB*l;NAr>wv3IfwNtlw3In zZ$Q=ySDcK;s7|Hoeug}IoUC^y-Gy7z&DQO0k=P584_cW`Dw6CdPkRIPgbFDsUWfDP z*(UaHA20gK9iKw{j8<{H2Z?O+Fn^IWjR28B^4j@xQ#JDNN(4q?+6h4<>aLY{IWk>!OP8tP*eR3#7`` z>m=e^rGP(gY%~k)ZAxVK(M#|)Xdlnj5Ce^VIUrJ#O}mboC^I}?!DXOo`;U9M4zuN^ z<3RT?yrw;$4(=xKXF^#@)&psEo)vEs5RJlD;n6%Bx}8jyzgs=xB^TW5ONsRzieQm? z`mU-MUIdylDZP#<>AFLN{gAz9p|JQXEIBl!a{+`-HW~xu&?QvMFlutPHS=6EG?%H9D1%dgq)oO+l+hNePP31MeJbqRR`$PIpEc zk4+givR1FZy=;Ue#hU1*8{FuELOH#qZE(=;vNgHptFu7P&5YiL-n^zb01k0gG|`q> zj0q3l3j{dCzFnT=%1RHdn&&Gd%f{{eLa#~UmY%5f9jGIX7bfruSaL2zoGYXt{AF1+ zpcUzr9<`T{DKGpetr>Nb8lW%q4+}-jg_=;24VilfWeuqfBT{one8|>qp2!x%NBN-n z!GX>KP5B@4qK8n0jSC%&wh_d0&V=XF;EyvgB{j4j`Bb#nmU+Mz#rawx@JKeqr`x+z zs9%JA6l|S4x=F=iAst zKvJ-dI@5G2)BvF$VI%Q;OneTP>++6i%hrbQomG!H`1XSIdx-n&o<1(Y(@?#lRZUpw zG6leZnmTW8KW`c8rN*D`TTC7ise%GkBL)zcapiNuH{2(opVq(_}xx0o#6Kx zji-3=&Wb+A#N$AV2I^aBg{F@^=ZrN-#dE)JJ_-`|j6(;fs25msFMLVu^*uG`BgqbW z^#tnz@hm_k0j8r$~sn0$!0hJUq^(#NKAhF0Qr{XCG>i9Y*%^Ily8 zq7=69@VrDX?nOEAhrb;l1Z(6Pyi%%QYuxZq9HjG6mkOr;%`DCy=ViweeD{Wd2;*%3 z&6VUch}fOK_hOAeOG5w6kaM~dlF@0pZUnk9!{0tOb;Ma#S@U!yS43jt8{Q|@u*%i6 z*8ci)iDR2zTGf9b91D)OWPlM?@7Mt;GsvQ#0E#|Us=yzLyR|<0!-p>u1lngmf)6>{ z2>a&wzI;&@_)Cu$k18|-O_K4ClzLW9&pQ0%eP7nNE6F?b2q%Dp^-jvHJQN7bmRIG?+c!K{cN`{7R3{YA8Tuy{)R#&V1Tv{ z>&Cy_xY`&i1~Hsp9+Y?Ie5#tKpF<`qj@emBR{b*Xt1ILFxg+r#gdDRMI`(in16$og?I1Wp5EAlq ze{R$FxwQ%N5aQ@@ON+Harp7FPY9KgWl&DL$9E(T}^KvdOhf^9;WQm1a5|Ivhc#-{u z{Y)nGF8hLeXj}q-xGet()5WGvmuPJGz{Ga1gGkJW5 zqOi$Rf8tn{p#ZDi&(|&9$No>b`p5Avx)6f5l7JEBRk_9VF?3x=+|(=7+K82MS0Xs$ z^^5M)6@IM5dcMoM3;;y@V<$RsU3L#vkj4bNm=q(J6ygOS``zOVzf`h8bKQU48*J@h zo&y2Rgwbsx_TE7;p9h_Px|*6VJjEka^Lwxm==kI%)*uK@eGnHs?DSB6(*QjxeC#J> zyiW)DorxBHB9jlclU7ACeday4qOjj|otRIUbWXmK;H%@oe(i<&oAF2Os=goGfU_nj zzmFoge)by?x50gD{fR_QB8#0*^SV9bDvnun6ol258hb?=CJKVj47xaF&Gb4P(x|wg z>9QWUi-BDx;r>hfTMdFuNY1xW2WiX>f8NKI>Lb4m*upN6?9g5ZQFn*mF?z&&ck+5~ zR#)Ph=XQxCiB;(&8VliTmIgWLY7B#8ifrqPU-&*-kn6sth6_L_4T=0Ue4^5C)s@Uq zGcdVJ*THM4;VT$>@Rcill<5kF{xWb0+I(-okL>vM5r`>f(gf~UQP`y)+882iZ&JyNbQfA`z@ zbU3aFG=1qL6I`p56t_>Qw*~4}NB-^oP7*Vv5P9>Dwu6g`&C>a2e$2bL1e44uyFE!$G-*Z z{CL~gwj~=bvUYzeywmN3EL6#PtKT0bY2L|spbi1-6z{Y2@q!%^{(@Xj*8QFcL=*$5 z#DVn#o?_b`Pl`%u$6umdrYV7)5;&9ts9PpQhu|k71<>=yhW>*`vwd$v#Minpc_2G3Yq`mqPN~4WC{l21v zqlGD|&V&B+zFgB?-o{yjn2FQ97+)B%FN&Z{AAc&FQwJ6-CV!>&_<2<++dN)g#07qa zIgCf1#@d)0GN(GUI`a71vhu$aqV~Xx&a5YF>7LJz$r%OLoOi`J z@qRhiKw~}=jAh>@n}^q6*HPvB3G>Wa^-Uu8m5v$*J}r(yz0xX&^5?OgK=O6UhC4yF zQS697hb)ncS1y?ue?wPgez{;bhP30QQKwSP$C#Ttd(%i7-tV{iQjTy# zKfP~Q9d9K>pS?g~)k|6?&K+Kc&Ph_l=;8HepS&~n=KjT`WMTw9z#1!ONVgPlbRGcMnG4{m`}|nC z{UG@mN}_R|_pmxXDIUZ*U~TQbv=$Q@b05}`qg|PvR$VG82>W8Wgx}^Gg8z4P5u996 zBX-~4Np(wW-WrX)U1RS`QE~ttgXN8uuT^Q2;VK$UJ%ZDJZ&A%QF1uQo2;H4^)u`f# zy5!BEr8Y3gX9>l}@kGSnq=FMX8qpxwnSsIBzvjy@EchxB<+S6;1OeKx>i^T$Y==Dpl?sXl$L zB<`;wDlnj7!u9I%eVFyaX$#$?o5X9;6BI-(G!hR-e30z>jaUr%E4g&j{TCpi5|1*u zl$w%A4NLeVRx_1s9ckO&sr*9wa&xF=%|9#MeVeIF15~r%L9H6Ub1;(0hMyapD zsXAYB<~X^`&A(O;cl`cLEnuy>&Rqfr9|C2f_w)7iNrk+Ogt?)Li>hl{_aW zDKZPT)MH$~rXz@eqFZPzx9v%)QJ*gH;_0v{f%sRV0|=`7+WW<6cEp!AdS47E==K!Z z({~r1VF&94%7FZ%A~=)J^*R4jem&c|NyDN_{GcUjX}{l}9-!H~a%{Xfb~TCohOMfA zFQQN#M>M)Ac=zD^Tza?spL}&$(~%@de%DSSuBmUgRL1n7m`Gh-0Gdd}zfGY&$)miI zGA&bP)USB?cVXP=nMZ7KyR*-C$CTX5Zy5+>!Ty+rYZfY%{9?|eh|C|_*2*liz>D?o90E;g~P6ScB(qA-Da7f0W_KJ++WZdnjEE!I|q) zQ~Z3DUGH#O%6kP_i-+$@+t1-#=~axxC9O`JID>9ZaQ8dsJdz|gf5W2NvoCf1@XCIC zAAxt)muB12PC*d)HDYFLoYm zE8p9`=2_A6z}~oDo=)SYs$R09QQ3@TbbUBa;p^I9cITshlsFDvc2)UKRaiy<`V zw&&NC4<==J=~E&TW`rqfm`%F1HVRUEVNh$iSAOlT~nebI-aMA^;KDo4;KyVNok3dmKKcv&Xp5uKupy`KvTnoA0HH(O)Q8YzLDY ztlC>t$k@|la1;HHM_9hFJrQZcO9crolp1j4m!LQ#K1aj#ql18u_XVkRMH?<|CV9b@n>EEP9)N<=o?l4@X#&;B^k4!!!G0!3Gw7q@ zFQWKU)zY?sQIXG74{krs^aS)+?}yT3HKMwRhv<8uZlA%B-}dbbXvA0I*>n!+B`u=O zg1!CuI-Honp!0Y21mSO4VvRhX(gx8kwkGvbrUYrMDl8-Qm@3%^;hFDL&u*Dy7Zcd= zu!s!dNB1XEdl#>_uak#}#U8KQ<|TN8{?V|D1I30$Eq{Jw0+xATV#Oj_NwN|7-OZVP z$pWMXOqM2k2o^ym!!72MUexMmwvuZ8atFzfFQ4(`ta1-9DP`Mj7pe9744~2rn?C2; z^Hm;0R~phj>baD;hUkKC`JweGtY$Cua!6$HC>fAUR5K3PU?-EU55TmCUaKT)N%}B= zcvt6H;EMP3LHFn}-nc@iI7pqyW&rRwmogyVDz(2Z!@8HE_od{0IKss{n~UEb(n4NW z*-m!?p3&6SqOA?{RCavOl!Q?ribMnf=lT!#Oor`BDr@5v7IPXrU>GuX=YsyO&J(yY zjBc^0%K)aEcAgxrlvKZHRki%fZI6mR`?j*MJ+CqNB`R;WJ3v+Q* zjr6l33RHrs!N5^RIJk)b;y>(<_tPLsuMK3_wNN5((kSzv)fERBw;!k2&A!xAlXxyj zo|Bp&`9j*NeQ-ae{!tG%2A2Qwq_bTyPs}zwJa0i(E;sA@d?u~(l{Q8WrMC1$_jQ9@ zG~QRs^9GX6b0owsp;XZ~eAY*3G(EKhP-f?HTD03ZUar*(ik+gq$9*t}#tRkpgmEM$ zgcINI&_&pATH^zQ>O4AQ5;#(kL?2m%z^!^27n54vlCHmhlGq;=jzJ6qjw0U1WS(9U zzNz5ru-cv@;)x{|1X%I}x9E}y^M!|}Gz=*Vs2BFi{NWw>?=Th2^Ic60n&#$rRGsV{ z+z;KL*zCTRFYk#v(jTIHqia#C-_;cxmHqLj{mdR@F7rH;`aea!oL5H!KB5OEolCvQ ze6>3V^Y-MUnI~$}%$Mx?C<^hMbUZUEB`~F;0`t8i=HBUU)=8?rW%d`#?h%QOxR|2f zuGdcPi&N~J4$(d+U`%>?82bg^n{xVdOd5AQiNyY#a%(c>C`M+#0riBQz&w!Mop{3} z{ru1(&iQCJ9Oh|n;FOhkPGR|&$Y{&fjQrUPaB4S0TV?t|n)10{zHovrD(YGcu8!J- zdDb192kPvWk{-(VcYywjC%rS&q5V7#8LQs!=NQ$fE#JEmoOWyDrzxM0Hq9~g1l0qg zd3A$*mS>OnZo}Dv#zYtqOQQjx4^8 z{0ai=O`y}fmnL|#Jl9-X0$`jS0fFBmGSMI-Z=MI-Uoq9ebrzOkPn2>UJ$l)LhOcEy zG1Jh`&!aiVU)bK{2>(eso-?XUPugMOLr7?x&!o8$=fHTjeqrr9598swB>E+69X_4tlm3oVL_8~9K2 z+0^W31TgAZZHORy9gQX@HaZMnl>~k8EQHMTIBn=nK<=t(P}|?D#U%Ibn%IAU*30bQ zGO`y>Ilyo0s5j%DzozbHNb`Q*wD?2q(H^Se_=|@xAlt0ssu|5q(tYB?ean6R2*379 zN4!%U*@aKD^~wN3X_)W?<7OTuy1NPwRW}wyKhXG5AD3TijnwU?=8oN`#!en#%NMem zufdH!C}ye=OsoJVyB|d;p<6I1xVZXh9InnQ8rfAoE<-f4JcxUNILcJe7ku`6*Umx(y~JUUN-h`@zf6KM22`7H)Vv=l%PwORft;0mYGsg} zc3_baSvRO(4S}L7oAstfKY&;wuTkwWrt>eN)upNfy!y?-A^N>HB6_a#>y5nh5vZiU zuMs@~iK*i*5?n>Z6>eT`Gx5JUZJIr*SM7=2?-#obFZpuY`xW;TF3m_Y=hshF6n)V? zw+YKg{x-emmhMrfz3n7ck=_3bD|n>`df4yfGVY-9<##HSR>1Bo)-x3hqazggkJd7h zg%mO#%~b^a{)EvlqF0ko=-RR-^J0%z@;!dAHi-2#Qi;sAWeFdS8ST0f05+&W{L#PfXl$lY=0%xI}BwXM)|T&731kDvC9DM ztUFO;j2Z)}nxR;Zey&;6lGadD9na%uzx2b_k`afvC6T@`Zsx(He^ejaF3IljGpaTG za=1+D44HyIJ4cwyu45$h(K#n8QPGR`VdW@2&%vkn53a6NX@8#$VeMa_t`6h-*#=@6_Q_p(H|X4y5b88>Db~8YtUPefko(6z4+jnP38XET8Z4gr9Ck^wCOVs&k{+MiTl~SWgd-Sj z$BRu#KHcfp)LaL(P@&#*+?SKQymw9V`QtWm6kqIvigWB0x{mhi{yg=YFejsH9w`>Y ztKiHHCS~%cEKdN%WN@do!=c4^j_vv+@J+27IZ-fD9M05HYp`#krV^Sgj4uhV6@ z&)szurddLFC`z^cD#c8@fAVK?@)BYF#882(bNJ>F4Fr2$F~SwCcdb3R`y-?tp;VJ~ zwaoM!TxU!#z7cqejD~Op9mp3LRODsrN@U$$k47EM>8XHEI1%q<9`yu=I!V`zE+T9=7`_Z z#>xlJAs^tgdX7me6N~%Km9j&62qPak2EDfeY$_Z9UjcN;kM5|?!`zy`tSn8Kru4v9-b~> za_2ljujSK*=v4s+@%%2qu#=P-WcNH;k8=))=|=OVi4iI~_xFq9 z;N3;K9bTPUI!V{Mp#J{Z4<|@a0W72}GI3*HZsU!zo;ZTC0GMp65na{1vDJNa%$s9iPe2ods zfA?7G)-FQVYIw5%SoY}iW8mbA$MIu8%kaRy9@&^eb+m}&$iDfYqV*tn@Od9L@!FDT z-;xxPBM)-JU%g*?c~Ad19ZGIhKLH@Dm2Hp4zbGaHwEs|zt5 zTr!R;3?`A*2UI@C`iWZ8bUp9~Es}rUd@hq<_Um^_Tn%8SG8ctRlg6oJAZ4}5Z~V1V-AZon`!`Bd&Iu>jn;eJBT|l(Udipupz#R71^I+#FI14`$mBLyQP6i2{BTn_WT=-KbzgzfX zogU0Pv8?rlEp*PB=`t6VM$oV9(uK{bnmmh}OczwtK~*Y{lO2mZmJ zL;SjYxfrX=P(0@Q>M_s(Kqoy(tQZnT19w5uFf~KMRdW%WG0Rhw5_BRO$goxbXn-v>KF z7RGeoPkp#IXLtS^ZwtD-X&Zih;zG7AdZ(@WmFPWY(r<8v3~@pcPpv8EDX+}>Hl;z5 z4_UXg@($+e%NQCF(w8A*Gk5EgcBHS~$X7DU>`ZjE$99kLHHRV%y*RhJf&72hqXR;2 zF(Cb3<|N(NLl84N|HuJIzuW~{>a5-AH>tU=gEGM4PLAB1#KUpt&=pL4(7 zJv9WaDTyPsXs2?7px=`b2bj>$s7^2Z?dS$8FmNt3fkwNKCq zg&rdW!1}h<77MEHSd!J8dS1CIft(gyQF2pvyk9U)y&hWX;Plv@#nVgL*YniD|L|vf z?x&)Yh%!j`m6&*E=i@bRWNi8BlPo%*@%{H-A=Hi=uo`STBBY=IQy=S&svk8XcyQ~! zFmfgEhs5c8S@6d_`@6|-s=Up{JWJ!`f-i%D?}5%TjX(aqp@=HZz~3BKX)chN60VB6}B~a6R7GR@aKdk6xnZzRzQQIRrDS z8CU!Pg|Pk+hHsOq7%G(SG1M8%C}|ln#Tj4slkI(i*su=$DS@p$NGy1`OwkI_srI}t zNG*y(6S_eMy=Kb5H`^1<%)&Vd%nvIZX~DSSdW0%e1cmaBLfcLH8V$9w`Tmv8CW)&F zdcCh_L31-@7wc7SLf-OMy^SwX*2{PxO+CxvF7M3H6QCUY5n=)Tmk;<02WIG?sb8%mJcYt+qXu|7=Zu|j8;&JUk% z4C%M{i(z}NVYW-%81i#Qzsp2OiHn)e>((Xd95L%Wt|W)3A>ZJb#9ygLdMF z6HKDAT9t0+^LeIDFP7$$Yz(iT-!6|OY7m4;T>Ef!m#umeH#>LCU6T6!Y6C@jDmbJm zUY*9JM1COY4}hzIpzkYQ6|21a*v$J$rRI-Hu}?rOk2WiO?Sy*mnpk2o? zq}8G%F2z0=I<0sb@H*4v2GVa#y4lOnAyQPyMxfg6Jf8^n1+Soe-t-Ime8%7UQ9UkU z-=$&7->+QoI}tvNgQ6#i7Qd`M)Z1^=UIOtamDGI(CnXcy5p{g;(abk+o}|Kr%V}SV z4xFkJT6>z_yzbt+B|gfWaA~qTylkq3bDRo{(u8=+d$h=~XD)6PMVRyvhG_6uE?zLv zfabe$?$C@}vXIm_B%$sato;NW6EHSYG>VbXq!ks(>I+3t)mZT{HfSGCz{LM}o4+6Q zEwfMK69D(iXG3d3Yh#0#b@jvpVfZ>z=G`r@B;ty64HN8U<$*ln|0 z@V@nmL>hdxIpXjg;h2RG@VdWbgJ;BNj&L!9Jz8dt%DZh2y~3~cu7V&QJ*Jh5+x{iD z^R+DY$^qX4*8nt0>DWf=sQe74(HSF zJ6%_haM+?R;7A1HX}_<|YX5O`>TW-6jY7(*ig7~VAFEJ*SNLY)bIaGE`Rjr`We{A# zeUL?uFXe9>PYzf4cTKjZNw2rO+2{E8c%&mi(uZQ7Pk22ryWGc9gzL)-rkD!jVJ{z zug;smZ~KfejTBif&C9ocbY71G_moKG3)%?}DTk{c_jTR zieq6o`#)Z|z-H(M^pkTnKRBn01VSWgkiozRi? zjsB6+-VGs062Y$cT(!o$0 zC-YGg&J7K?Sp%?VO+*B;UvTsMxkeyc(EB2pTJ4(>?Z2W}HsS$xp9$pcE>l`hqVYT3 z@u)a6>WcMA4dfEiio)R+s_3W@B!4^o`h6;S+~vE{Gi_%fOUTHtRyjE2G@=fKFtnLo zyN7ut=Hv1el|N#u3B5qEFrf(`Lq3~)^Ryq-R1o))-V(<^X}uQ9&GOFE1(IYq16O|& z4Pv_t%@r0+2dytm=!Yi30Kx^|2#3rh&ElE;)q!pD?7lnPGowDwx zBjJQ0j{e)}p)8AE`;44I`w>s(zTdT9w;-A~hf(@NJF(^f1}j6ZRvkj9bwCBTnjeGtc2lE=#11nzIAtoxi^*7XPfv@YtO zA=OIyxk8Unhli0UH!H{$*6Y?`&jb)pyp7#mzLB3W#Yiqc8pIH;yLSM}w0+KeYC{zte?BIfP(XL#le%)X~}P>hCKKoZ{6u@3-*X<;rka$e;GI z*!}k09C*k_BKyE3RQb^L(djMOq0C~im`Qd#p$!LtdyH7IPp~+A!Hj3-hH08O9lc%q zMZ&ce^>J^rPAB6+QO&SSW;?xgN3HhUZUh2X&A+9QR#6tx(N%I9m?CDIz^a&PmJ#j{ zX|cSi;tj$e&GGekmg-g<-BJJZdxPDu_%YP)9%|6{o@jaa0z@vs$Haljn_Ig6fZ4-a zWMUxX1*t2SPX=-znurH@)U_E8E*f#|A;1D?vT$eWbZ=ZjJ)3rYpPb({cPWZ9mCe@o zYQA2~BER$%mde69zI6ZbI)T}Gz5Hek)af00ijAz8>Tr8tEQy2rxE1=LxN#M9Td4Q_ zG=AP@aWItpW8PsPj89G6ZaDJk)9AC{7l9sUJi2`$jJOYOhJ^>UU}}=^|v3pb_pzj4bDy;Cvb1rQ9D=Zauf=}gG&4nh$VTVS*g{sZj)Oh`+hf0 zCt>GDO(!80$O~*%;+nnJkaxDnmnIK;E-@30I`qj5K+=AL(A@bf2_9dr&i%cfBtbSB zsWO87Ls_BU*(r6NAq8cP=JeRtKl{BGUe)n;cSfz~dg5!KB%0e0BULo&Jqq&?#H z@x0%d@2ejnx%9a-v?G;vL!emt4qNDqYC=k`kA369VYAmE2La^U zLQfn00~U80oes3D#POM_qs1pgFYn?CQkyU#H;QREv6riOSom zbW(vTBaYkRrumzcBU|z=9!Mbv_=F~)aXXATUFYJWC8)^94@2DqgibbJLSxP1_7|U` z!~4OP$nSYT!#?DLO=cR4|MU1IBKxxMo0cD}Z#UhSWobN9DrwFpGs5hSj9{xmR!YV9 zfN4$2`L8AM0f8QH=$Yk`lL_x#A1H|P9`NwDNy^{YbKz&8vyG|f?ZUqcXS2&XKRjur z&7R8$9#;A*npgQ}j*8N)1-d>I04zot?`zw$Ed>J{%pH;ck{fN9zdV4S`75EQkR{E5 zB~Fl*E6(-h3|>g1#S7o0p!ROZ6&3LSt6Bx7d17@(dI(l^xsQYQ1?IVb90$yf{zJd^ zC?;WjWzQ$>%KdmwL$Yb_#1phaJoRgGoTrRdxC|%;EX{lMb@$h;LM-^1*NGcO%sRCz zrg)8qgK3mo7FrbbKGq92B4Xc1X|$-SbCGrpx%+XTZiF4&d@;$f10aO0qmaIEDoQ%S zi90QuLj=qZJyh$B&01C5K0o2ki2K5Xf1>aeiaWwZjkESE9X)d`3cyaO8HJ`Z>6za=a_yEbWgYXu%{9zjMm z6geSK4x_b<#xW)jFXzOzktRQ~x-&cnDGotOJg4yF_tV`Y*q4RM_XBy|peZ5?rC3!#YYPX$m&C(P`pBWYh}-)6u!_l`%;u+ z++bwapH}c$CR_2jd756qVH~IqJ`nupR$YhX4U*M=#RKEbLA9^OyeVLj`CD*)K`&YH z8KwaQ`CyE*en@(`>4&gCBoGR~2B7Ync=L-+8xN)5!!Q5^k3xncyitdtc^q&)TiOy) zHA-lm`4i;#W3=xu<(180Q@i~wSbI&YENeU{b6fkj_Cvbfgd;>nE|3<+39i6(&gs6* z(7cd9f?zglW}Ln(`Am46v>qYM{FEWA2C}wY7h}^tR;;%QI~p_2%G1 zyx^O#gy1ePfQaosCZBR|UyEE)fcjT*D@FEa1)JF2WH&j!v8nzf!b|o+P4r*ZJGp!t zpu)=YfSHzW4UJIcr@!JQT%2Cw^;Ze!$R8QL_Hayg)kIuoz(fQehH=6V%Ae#rsag%H zkVE&0Im){4*aY}Wf5lBu<)i|xQL@H2@N?t(-pG(ao2Ho7+atP&gSQ7Bn!HyePRbE| zfoUxlIzP_e-+{Os6P{a%zKVo>Q`xXs?h~4>=jQgj!v*1m-TrD%2C=`M1UsS;pa8)f zR)%g3+;mY6dAZx1eSiw>R5v%!$)fVNvB~$a_<|j3*q?_%FP|{4fmcZfpX=V;o>wZY zx2v~F++EkQO$3jINskXz@lOE3`*#x6;Sjjmgv?b#vnU zn6?bMf0|Zhf17T~n51&Dt1q=ukDJATELK8Y52_kNKDTvyM=qwebY3-)`_=>PVGi7U z&)~#y6~7!EEgID2&a15Lt3+}wJe4id$JM*&4h`)gVf<3g61tF*^i~tGp9oamnm?e; zT3a$Lu&u>FTPZLvX;GZiFsb7`g<4d&GjzmwcaG7#IHs#ak9F&0i|K}gH8<}1gf`5V zZT&l|Qcwr()jJt`2nIw6yn)C020+N%FUu`NJ^5TTw_i(Ct`4tQ>3Q0Esi)NfpudUk z@e=hW&5D~Oq0l641Z^=8a?GXUunV1`ItKlpA(7Q?NFJcC3kwPWhgqg-otRL8glgdT zNMeqGR^KFbAriG5-rev4pp3Yi#NY&2gKEBh@y}pU9SAumf=IO*eWw@{=yUSL?tDk_ zdGT)RNKFJ^yX0c1y?wT1C4xzm#8-)?7JcO7W~^{IjxYWBb8NGkjx$-LJjtFruqs^6<@E`^guC~q#pvReDLgqW zH#akj1*?E_hmWj@42t(wvrpSX-qRJjUi?fX%RQCG&mfqeUMFMG6%LJjbYJ>KzuQx+ za-UmsI~xZtys3smOno7w)isg&jtLSeR}9?c@2yCOgExx>wpLY{Uw5-CZ_47XGc_{i z*8(I<-xIXbQbfyA9`Ic{tiMq@Jd&87SF}bTbB*T_oyO$83^@>V-@h9Q8MpQvSKVy` zdTwjjL3<&bz>a<(qHd3w^t|SsU+}Pm7WdfFywZlMJpf8|i}QnP)Z{8N@pwM}rBe?W zilA)QmoF|{)+fBJ5m|ud6Mp+LsveaBE}wU#%N|9b!(mF2R1KhUexDCOVK01L5f}6K zA>C_hO|R{^Ez>V-_Z9Nt$R}+9z$cel=@c&t_q|1CLv`WA%Xzs<=n02>@_S6~Ac3x1T^`bXUPv)JBoE_et!{fK|kh{L1RB7Ch$;)BDx4 z2sC4s)AOP_CKA|?qwF=wwG`r?))ullOpNYtu6eSPh+Yx}0PyV{-1LH=LKsv&YV*|+ zX@YtZz?7szu3^lBl;GToS>h#XFM~e!BFW7*&ZjPm{nC^V&FMTtmXU{82?5Ufi>Sh5 zQ9j)Cs$&PRn<{gU`^^lX#tfLGT}%1xcSX7Ivj?di^Lu~1bYMSMa`xKa7(mE-g%8Qa zW}YsN5YKo0V}!mMubvbhs83PC?dq@MneR2H3UvxPtJnRnY5 z=@KV7_|HoUOU`32<8F%Z89k`3`FXs*`-K_akauqGHy``1dS^7frM}M-L<@%IJj;?# zlF-Ai72fHA3(c0RYrY*|UhqbNY-nU>An9X53BHGU`Sa9N$Mh5T72%r$;NYoG_&=|A zVCUgZyf0(y#FVZTYp(+HQ|#}_>Gz1MZxg?c^V9OP9wLq-{up5EY>V%pyr}aGwCnS8 z|1(yGuu=PaP0kzD>yTx&>&zT{fto?YJ&TmjAJ?FL-=+kmg@aF&(+nc@Z7Xg5aICYV zWQ4uauP^l|aFu%Ya;okizclw`sg?;j&)Hr-Xk|(R81j-F9we6EMUhiCJ zWxNaFgDut@2!f!1B*=DaZ!KS7_Ql#0Dx0VZzsQV;5?=n!1tFQ;-F#Y7=cRVC&Uf4~ zQGIku7(aq#Qg&SyvE4tU>hD#8dlxyRF5X8?2%O)onI>n6<}iM*t-W?>g`iCfN#BN1 z&2OCqL4|%nBvb5;wt-KfV;A@H_Is2seVbq6@6SPuOa)YXKLeD^wDM8D7yop0f9Jd_ zI5qQ??7O_~;9y;}wj2S~yQ7qR&Iseg((t%@-p~6W!v~}m+aj@^(Qq6m-{P^aZtx|c z@eJo)DosB5W`^AjNG!|~aiUqx^pS3l5a*BT*zo&KT0S?AkJzP`2 zwlC=8=8|BZKEkh>@5zAJ;I-nt*Wh|69JD99ecGj%PHO%<7jPcJZ+|$Rmom;M=zX00 z;vKQsrX+BM@Gl_uWB0{?Ju1FrBV_;F%ZUiQ(we}%(`c#$$23yTY+ zx4od<`AX!pPF{IhoUccyFj?)xs6Oouom2Y@h%#hGKcU(w4to;%iz0=((?5FlA7P+E zQXR6{?t4ACS?N-VuS%CdEcN3j){UUh0AzgOCeX*Tb=a4xo>t4X^- zml7Abk&&gk+#+m+U8{fUKh)(1*mZaMD}=w-@Mj3X+qVfA5dH=l>Vs{TA-P<59J`s);bdcaht!UnRj^s zj(RYTGadFMdPMEkYmnEbDdzlu5j&JMK&1r20KY z$qIa|yzCb#1xW-E*$J+>Rn58X$d z4}JX-G^K(JO#l8FNVxwDcsa0-enEKjA3}i&+0`}=ZIE;wYngBw7>0{A4n+P)5Yoyp zV-S{yCoj&2lYL%!-g;|edv5jRmz7yj?sL2eDyHzb)@KN#wR(B>!ZViDKAj*wef4DR zB=mw(9k%CJ{2tPrF798sI;zZ_+&Dnbc#2P8J!ixOS#dN#Cd1D$<(Y1dH4sQ07xiDm|$@D2z|+te~DoC$C+0Yek# z6fn26tjeW~CK>LwQez8D`9+ai_(j#_6i{!**xrO^2ZT#s?j7-})r7l3g=xQanf-=% zCG|vEax$Nsd)T7;@-gFbbAOXL8Ar2!KmpS{wvkXK5pz~0bjTG?W0LMlEZMIEMP@YT z%FiI{19iGc1M8qK7uoqhDCT(t;sYGhT2wh?GV-dh&(*N)AGd9EEGt!F zKWAI_Sz!za4^qk5dH818m>n>6`xtTZlCE$s#SSex2U30u!}|!uvfJ~iTcml9jK+f} zSHlcW7j@=bf5vaAvl*-%1%`I;Rew!94BtBy`e9s2`5YJkqq7lbjI!yc>G++(R!I?? zY|a}3+mEZhMme1r68oZw$O@>h90C0yaMX$m`i zpcK)&KrpF}`%*Yfa`C(zo>2T|;){8d>CgFbp<#H5&sDq?nCKjChsw(O>fv$n;leFY zfyqP|h{kOdQbzSIm(_`5Fe0sR;?AFQeNNy-`}m23|6KMZLhgSsrSz-NhDZ(hu9)z} zi}7&PehG(a&VB(%IE*`bmTaLVv?=i7w@`eABU8$-zML!}Gn|dEQ*9!8pAIS4f3T?X9z-I6q5(Q0K%C}pIFX3P6x&3D-maY8uak_< zSsM~Y2S2N)M-%U~F3%I)xb`3mFSxp#LS{}9$@dTUc(0f1&1H(T9;$DXdS0I>^n@d8 ze&3Ax#+>FldXhow>upE{E#`%WAb@7C4SZ>@2NEBkd? z7Rq|jxxajSBHPPjlmqG;GMy{4-zKQEBCEidqH^#O0}$bMd-yIfzk&O1axM$w#exd-p}HiYrn^q5+K)fx{1HPx@HGD z&lf7`Jy$C6&Y+WQ7h(K?(wrm^u=DfeXjMJG>pM zBlH}?LxE;agEoPk$`WN;Sy51jb$~9vs*tYwD8+qcl~I)|?BfBycKN-2ebS0CgLt0g z_|=9_Cv@m=N#8GZq5(yz$?7v5{z@oh8Z4>p`tOjfwhZ%>E1@(KnJYV8x zzCK$L`(%n{kNjmnnf5plo~g$;Y*g!hkM|Cy`V}r^&LrR9?!3;YT9$uuQvysA$ftc? zhekzl0XU9w#wFa>iq}CZ>F-u?W%{}s%wF%1SoiM1H-1XA;pT>xa~giiJfg+a#2Pap z1U@S5>T?uAtDZ{iOaAD`Aoexd)>J(`W{;5n>%Q&laLxuP7TTptYa|5#vJ#9(8~o9LB?2I$c& z1fUHG2c85fE^}JNNAHH2O7>nVo{rm#c$hR0ji`sIApCx=ldWkb1Fm!kc0pWa@0ZsS zX07rTGj7r!sEaEmA~2hau@DPwNDMch>c;%^`7%!fAvlQS!SZZjH$W0 zK0hcRK6^d_GW8c&5OX>@LB1vZg%1{i^C8v`d(cWX@N`R^ifOdq}{SlrO=d;)R|F$s|_`%2DAhxrt5=k zy@E4f{%!OG`mMVGO9DTKyYV^L6Dgk3%XKM3in1UV6Yo`pT_c2 zoxAr&U#~s+I->8p&>ve*sos6Xva?0A2TkEHe|y~l)sk8nV1iWrbU*yakNFmQOP`SH zlwj%OuY1|se1Wa<&D(BNJ$d$*_ci-y#A#~55##o_A-HLN?{#_Ni;?L%% zULZJyNV+~y)gIc70~ZV@JL;Or!001r8;WSod+gwIfj6qwxe4ZS+n0!Mos6ZPG{{(O zJ3ORtT!bZ_Q`gBOtH^$oD%#jTCPz4|S9YNL#1&|SA~=`PrwufOssJZk;KyNQ=*S%M zy1ridw|hyLvnf4~i+fh{Q-oSg+2eFgb33Re$|BrD2%T@Cyy7p|wrO?O6R5RXk(Mz6 z+O`C=0Q|8n-?@PD*m5Dv8>7&0&-?AU+R7MKs?77!oS-u*i^5=$cwF4&FTn`+BOD|0 z>9TJ#=cNSRuRQaxu^9j=z(XxeJWq<&f)=D}!}(hsK+gsG%h;9T+P@ZRa_q&&ymM<`nvh+-O~getj*8?q%W z!BCUb>w51}PIT+`xHhF=%mki=S>*8p@v5iPplPz!`h_uyxccmy`Lo}@Rm!194vPdp zLKG`FMKX+lMdx^nzt>S~!oyJ*6;waG%lk?kfQd!C0?a5PV{b#Ye%)MfVeKE~I6D2h z34h$Kzwyx5I>*M1l68D-+$~( zdCZxPuWxRb>rsCb^WF%;ygrO2!KD``&3&e)sYT74?9k+Q2$P&17s5y!2>s#!>-q?z zapA0ejeK73jDmz=lq8RKiW0lZ2P=Sr)?~rlP?GB5ADU(Grmjx7`ImE8!;8fk z3%nH#&pZ<>zlZ#f*M<++dh*%0!UN6pIj2-!R-b#*p4fS9+`&}N?{w^gJ(R;M>)z^ez%c~3mvmyG?arv+-kE~r(%5FG7^ zz8Vax5Mck$Y-T1{jMPtK?!Y-wMr~%eO=1?XFrIbMiDs(DhOw*Ol{s(qD?c*q=r&QZ zdp`aMDANe_9f+6xn{)XLi1a5JGjlCO8~NKxID4f>SmJ>DhGEEew3m$~qW-C97}q^A4R&&Y-#9j)to zlh=p2P^iW{c?hhN{B|)9J;nCzi-)GOIKxQrrk_FQBKX`!CXSDkzO^#aiYx*!gwMyw zzb$dNXM5Wx`*W$+)NH>sW*k2fSILJAYQ+BbvSG3FIekAn(g%jx*({Ii{Z%HV5RG5Z zZl&Hk{UrE!Gik~einuI8t8Z?3G1k~iZp+2p4v*pdFd>7$bU?}(Ctk>*)}my7`g|yU z3w-{{9trLOUauowvuFYssYp;-rd=)_B`{t845yF#xA4?@Z}RSS%G+Jl+x{ft%3zFJLN^9Fk;B=bC)8XV<46nVpKpRXDb|HymqsHo1jT{xCR zj8Or5M-;KdIK7B%dhdN~ncjOJ1jPy(JH`f@AjT4F>|(`&73^X|tXM$oh*-|O{pCIH zTIW0GkMFN1K5%*Eje10=qRCNc{pVUdg!;W{y7h0#V9QP?3DnV^a*&?FXFL*p?C;Gp1TB({wt zU;;xLm|&%l5yz?{h8RzccQe7Zfp~n7>9=7VrZ5E)wTOA3b&JJBL}FRc%Q3KMVVjI5 z&_kh35wUBPQaR8W!dTE;E^@!5W)X%6T_K*32HC$6RS8gXqe$rtp;-d0G+YuE2MBsd z!86GwkslyZIup<;(3B_u|8U_vB0M^Zba(?hB4m^X}8KaOct^TJpt4Z~-kHy6mG8PMV^NJH<;K!MKN`6OP``#P&MdWuqkOxNPB+F8HV`QgC>tUi zUqH(DgJ3w7L*ZfJVE8fH=wW+QC-MNX6LLP0${ayPPl`E_fx;g^ezJ*J6Waz&-SA3? z5{eM0G!+4_52`g1u7!zJ8>1vO1%pF^IkQCUQ3qX!bq56`Jw_7efUYzn48Ax;%LQ3j zn>px_ar|UD8(A*`BOb|w%McztrU-Edz)S&%*o+0)Cmn{Op+pf;J8192o7~XdMIwda zQ+DW1gBOA0E9k=b!{R8JXJ=ty;fcd;Cm+hc@TMoCB}*}?kU6AvF_~sSX_yf+?S?;E zhs{brYzm7Irim>k50MtcimehqIb@aD`5Y$?mLrn!7cnt19oi8Rc*qv9;~N2*JII&# zp_kj|F`Lx0=#1?Erq8-DbBR+tu+hGhs-JJYW=BK`GL zg2#>X>y$(cz=3ISU#Y~f!fqu|I2s~Z?+9akBsxy5QNv_rdX09nQb91XQ8eVC*$qK7 ziUThIWU^Y8#La2}#E2okU! z97Ft#>JgSB$wFr{N%RPd!P6PNK~w;R#p=Z&1qYJhP*DjgqZ)wlnZrN?LKOl{tb)N2 znSe;2qN~H204**jise=r%I}f|`CicF zwtx>o<$Aq3wZ#n$K0#pHM_Jra1CuLZa-vcYb+LhRD=_|{r4Cro7`@CRbm>qcmJei) zBT_6s#8LXx@C^(Hi6IO6ptz$ZQDTT=<=~(L#;}Se!ApRIK>-LRzD7th#r#n}hN}Yc zADCTCE0M|tGF7)W?6do^K6u5WR>TB2lr>-ou$6cM!AuwEfz?At4@cr=7MMtwPfUPU z_;@&%MjHvU*uE$*lLGL@EYw;>cBR7Zx9F){yb2UXJbbkxq+$f9K9DxDk~KEIgT+9B zaY8dJ5+8^G8Mw%bcc9JgI7AiH7)s}N#8vD7Htsg?@OlmK9_x+LfCL>DLcS4)*J>RE z3=qens2IDN9HwMj2988W|!Z@6^k)&6=Yz&c93K-8de5mSBP81 z)as~sxsB=KQn}oCm}g{i0B~YwsNg-Ipkwj0b|-YUs-X8M>f-uXL^ogLMU0@tEwdqJ zMG@tIAd`d!;@N->vUghFwjvfN`bz z1n~%%a-p9G?5Psq33i3!at05o{C>0q-q%2F4M0h9znshyI*Ax4Z@^c_*eb6CBLxO} z8&5~T25D{@9p?>5*&3j(gZB+u9Y{YheQ24>Wu?Ue1Qb`NglxAUrVp@VYAKtDmIZ(< zh@sYbflO0^%zLSnPP5AZQf{E?1qLjN0pKkeC+gNJf&x>-z}B!tQ6xO1x)>a)%Ye1g zolrmnLVATe=%+AsQ3sh}r?~Yx9|Z-x79LQdwW6`Ch#nZEsS*%wB0&b3+KwmT7i^*rHA& z_fm*Hk(us|d6`f!^Gmr@kyMBrpzyd}6!UhN})Lf+!jzE-?onNMaM6pf~I? zQ8WS)!x+W$6h?fU$!D-pPO4CakI2~~wp1jdqrEXXnF`cVc;Hp%(qwM4ixRYI>{v6@ zj07y7h;2io<+vzVWv0_5pFOP9DU1?t1Qmr8O;mx!V7ML(ijK##=wWEqMnO0iibI*F6c1)hhfNP}!uI=3@Qu|PKs z)oqE3wJxA9gjeBsr-shus+|UE*l%D1v$dCj3(KI5h($!6qA{pPtQdz6R1ac_(Q8Du zMG4s!l9*i@8J*#Z`y_Ipf?^PD8aF@UrEmantdj{G6gUn*5DF381gh7j;5(xjf>s8t zh3Y6(=ZWBH7$sCttPnK0VXLNsa!(L=e&rUX!iN^neL)P6J^KR`p1hGnvIYKm|6;NITyqbg?R5?(=u$bnDt~;_6^oTU3Z(h2RM>VRoN_32c z5A)%}V!X_c{0m>l2UJ|e42n5|kh?9yZ;4IXTz@hR-0st5%T3I{=Fu;4% zFzJ}o7>;hk5EW_^ObKdGi?$<<0ZjyncrBX&3~dDH>Bn2tHg{AF8VDfd1@o8+0xn#+ zC}P0Lqijx$kBaE{6mZ?Byof+SWQIsY3zgJ8)UW`{(-|UBSa(!t*QXFEbOST$L$;Ba6*N9rY6h$=sx{`s#&qAR`EE04 zjR75ML>4CE$l!PSfpJM~MaN<$4{)l>)7vmxp*UgUE`6y7jjVbxMK*()n ziA)RP>T zVLgEaBF!;@furRFbaFLG=^{}bdQp_952H;Owoqxnaiq{ss}?b$5s)MIxa4SK6rwz! znGaLxHpD;%y>y0K7pMk7jv`a{ey4_4g*v6zetspf*gNhhN zAEH^97#y;LTf|s2PD~@Sbb=scg?&KPFQqvkQ;c;=*^rj-LfQ#sP$I=NDn!jBu>wj* zP`hC9z{Mf+BrYN#{7GVOScu|M91Mz2ZPW${Dz4Bam3nzLx<%?W@y#T-!Z9F6 zA&CNRk{BY zgR6uyQA92|MFCP*UWv zNO6l)|4AiA`8>1I3={-5@QPJhhuGu<;$4#29yhB%vw$tY&_KZkANHyd=ZzG`fmF0N z44t7sGG#W2k*`ttF`(c|cQMooH^mdhx~M*AY9wL^Y7nWxk%0RNzEo}!20=antPay= z=c+*0UaD0Hv~i)|E>gr*Rt+c)Tg-m7-NXWbJdYcs$|y0Nlt$&tIP#Fu=!0+K>CiR> zpt%5_X%u1NL5{=7v)G}FpN2S9Wd`Lip!;hqC%znBj91r@mHiuIi0@(l_pe8sdq8X&NtuhYi z5YSlEfKq@MT&s;H!ST@!K*W%u9G{)z@PgbgNf$8U{2CTsD;G1!c2gLr%n;d1yMu10 zVnMRWAL6-;DBz01c>(L=7lR}foGj>pdH|XbQxlmA8OWT5oDn`A*~D3PI?-*QgveT_ z9?QXtHA;pLr7?yhG9t=JLTd$Ron6FW1eqXk?gQ}&g9hjH;-rvF$4Q`0A@QthQMskkM8J zl_mjC!t^ z0okS10XA5!mxfegpBin)2Y5j7jA4hZY7(9kvkJ6ohb#&*&{jVHIiRj4py`zc1EgkL zAth59gNX^UK4fSN3p zT?Rr9nQkFa-E`oRjwt!+xC*$+X&e?<|EQ6{hW$`Y2VG9Yzaw&^K0k~`iqT_CJkV{7 zqx}vg^yy3W0b|Te!huo%Fv3QIJPOSvj?>)?9fQv%%G7AH6fX#(Og5kn;o0H_chnP& z3yctQgrpFnhbShahHfV#lNc0axlV_KjDhAS=t%VOLO!j-$(8wW7%kC*QRrO6kV9?3 z37iH(+@Mo|{%{PwIIa@FY*%UkU;*#9J^6n2YHPHYQ39Pk1Wowj^ zSJjvFE|(O4^% z=TSL?3J5Lq20fc^lZTm7v^8KxlhG&#$bExcIfY8p057hCq>e*FT|}qgiZ~RKQA~qI zEF2SYV&KHl2$oAA@@OHu+sFZ-X{$zw383*NyVME?fYGOFBv=bpj&jE2SQ^#kc6$xb zw~r=>1v)E=PqBn!2D#4&@KcFJt@JCc!C=6_4eC`gI!H|bx?gDmQ9=)o7*R(eDiVcZ zV5od{o=7I*Ye;w@TB_6-HHt{w&tr($DzMaOuP^4}1oc5a83Z$teb6tXQp5lnG;!>D ziyUgAIFJBDF5kwGn8*7R`9MI>2)9vp=c zAp5t~Dj^^lT((N8;ge!k5)OkigLV?y0}c7;7#+gD!vzWjjhb_Q&^8Y4Q z@BnR7;C~-0$hCN)jlv;FhBDAY1M#7HIRbA-Vg)>s`Gi;jGM{L%%Z%m79UOxiEnxEu zWKcj9azidm9AHQkKi6u*Gt_vB-i;s16TJ;ny~0|u)jhy(CGB&fa4sM*YmqLemAgaZOg zQLMwQLShko*Es!3VC7L8EG9z$Z>G@<3T=c()8RB?yw?)ZkhBgv%MnA;9_Fap64Tr9 z>TmtFfiP(6P#~l1v(a4+6^?5+vh*IC-DEWIwR!;}pu;q%072$d0-?7{MhJrpJWC7R z4@?SFAx%c1fU1ePBQC9hf|Ny~TDeF>(RyS+M#2GoaIIKp#G=Uxb4aFC5Jf&Ugcr6b z5GYwiRJjc56-*@N6oUzeZfFu{pPQo)lnE3niO$5gGSxgK2x1`x7bXpA(ik*XCIJ~3 zISH)>rZp9n9OC=c7Be=krBV$@r~M4V9!Fko*`YSrklbWJn@TU$^JfHb`xW#_0} z;E_?K7`UfmkbTwYRnYLnaDSV25sq8S(fXB98i=d&{bWN7j|G$?kS3#4QoC3kGZ8^X z&8;wV1rj{lqe!amZGX<>@5>aBqpsZf- z$v6@rKTKhJLJ9{mEI0)bdhd~kNGD2AC?+Kc!s~1e*W$9r{BEXC4{|VVBcJ<(dOHuUvx?s^fZrnXZb892}|0uJKEG zR)bF(lZm}7oKI@UXo4~Z^g&t3fdAoR-Bdo`FX!oDlIn>8x{87UAyT?N7;^<^DgniY z#G8r;N2j64l{P9K>Y(y(&_qec87_i z6d~>cf#K$Z@K@C2Vnk^U08xwC7!ni7MMJweBmguPxmm-)d;>~w2r(BODwZk|sH$QZ zz_G)$@IB}-F9g_Vk0VTF>kzd?_^5}W4nkufbPKD|USRHXS*7sM10HJ(IOL?dFj^xM zp?xu{D}*=;v=Gr3b=lZ-@Mg?FYNGN&x0Qfk^HTLn6o4ueSYONzayuNS&4x^C8wPPS z5#9hQpKahpU1(51S963Iyn|qs^GE?N-^r80yH27s0Pa3?g)k^;r!0W%`hEaYqYW6A z5*@aqurUQSER+DhBU%PpKA^G9q{$3GZf6FYsslDJqgx*gXr&CGymExd9-Bq%7GYT^ ztvn3M3BfQ=$B8R(Y7oW)-A1^(WV%McjKs;_2$FllI)K(A430E`LL?%^JQNVD64*gB zTS4JKo0e4pbY(uFmW`D=BMKbPh8RMH7~D`9ktp>=;dFRSz{|$t0C^Rb()?a|*bQME zFo!AxL600wW}EP+xQhs-9=t+@ReL-fLDT@YN>7ua@CLYQ7fTK2R8i$>I*|g|9fbnS zgu@WJnb)d`Tl~&| zMyQc0G)lQL7=rVOJT$b+0h;tq0*B95VQ>N>@Km4~I;YEH#6tU$R>mgBZR$A5L)Mv8 zOr=Sul8Urk0RzCFOraT25izWWFJ?JFGo9=YYjKD;wpy-m2T&}a@-dqc(@wI3SO@`H zKr~U3kgZTNl-#&gDo`1P49J|plXuuHK>>pp7f1aLeB4cjD-(-20xHoN@iWZ;>ml&C zhM*nmQfa(myfYTneM8F##1yiaC)V)2RH(S~R2q)P3e+-Tyu-+L@sxDDTV&@M2uwGe z&kQ{yZb(35<8mvCV`U1!0_*KEwTz|@>s4d{Mh!(_Q`oC_fDAocGYheP|J#~1yzYvc zZB8ggGl(m{Px|h=lZ4qWbchg4p;E$6J)gOHRDYEXM=y}1e@+!yX&zYn9^eNnN zJwB`c&6ccHcbi7kmwZA0HGbv0zfzm0ru_ReBcW%8bNaH}DG9k_lnI|&NG=t#wr;}x z#iWmE`JbQrlwV6XX9_uefX#z<-1vOjmxuZ+2rf8VAKNRcFC#ESIhsp9_4@{$FK zNr}zA{p8F|VCP$_#-^y*>EN{`WuG~8vbEYRQ7|6-(i~s50w-S&; zm*Esk6LOFI1)q1$UNEZ5zvmm#KSi==7W4W7M#?O>3V*^x!5p}5+4=OVm}g59 z`XeX6)NPdH{rgr*^W?Ogmru<}i8=b@1p@~SK#l+9-@!MI8B^51&!$c2*<*qUA3CRH z%$t-k{Gd_<1NRH7XI(r0PgSd|_NHF@y7LD%8(p!L&Y{lTs>>TgZ{3lXKjO{?8hzHE zZulPK;xV%*qLqEt4X7Q}m-}{PM}p$&QcufIqYfvhH4?D62}!4h!iaCbRy|Km@zzekZWaOR{_y^y1}tInn-j{VP31ONYh)G*1}`a_=<-MPH>4YNU6 zW$JS4@V(J>n;e6!6Tbzub!B< z=+cfHd*^0JmCIlroim@vI5zXPK&4BGO@fswfJr6h-5a+=)2|5Y4h#+y5SSuO}%bj zI6126x4At&PW`;in^QNwA;ppT)TAsq`sa;qzpmPIzoBu-z|(K?itf!B^Ly)o(nY3f z%E~wN*6o@J533G+eck5y?VWi|uXZQ(+kCC>EYfz&+p3bf9jE(L&Y#m|?B@78*WsCM zH=D|YyBj-?-Rl?~ZyMSo`|Ed2FXmLZ*4eLaD!<24FJ63e-<6+!{Cj1^o!G4NlfGt+ zJ@_nA!{1qd`-Hu>_s9>lKV2Wk6q}z$-rTWVA4NFzB{pu()aM^3`WJ52ZZFL(I#=-F zkYIAd_*-k^AxEaBW~zMH=<6*_>zk%^c=`NFOONeX_x{|{0sDPfvb))5KZZx#%9^4c zGew-(;p+RUvfeLzn?Jw0<#`cly7spxYgG^Zx~o-XpU>&1H*~w(H*#>)wf(){3~LIP z_iP~F9oyy3rHanyS6V7=ho3X&X5JmYcJ!G~?xXc@hDa9OeM4Wmk~+m)%-;bjJ?!*yZPmd$J3M-<;){7rMT!=Ha>%bM71#?SCkJ z?j0{`sy%l4+KxM%@5{e0JsudiYE|QgIsS1si+xA4HjF>~`KqM6@1N&ZXO!*7eO=lV zsW>XS@qqX?T>9{(GQCpKex%g9a%t(pc1Jf4o9mrgR)KGp^z3~iGMlJY`?SIT-iG<_ zUYNGF%`R=1acFI5U()?9CT z5m`7tvn05?^{~Sa3ntUQvvobzs;a)IN7lri?j?g&;SHS~*EeksFAeR!A^WTHk5LB; zFLWb)898L)hD9BQJI(3Msr{#y4p0^i9oO*oH_iJ?En3vg$b9j!-m<#f*B}{j^yo9k z{PZ7gP2GCPzwc@8+Bl22t4cKb`STUamjAr)&b#MVrjLx~E!vjn9(VV+q+eY*@0YR|A$(h7xs{Z@Gd!o))A#w4GBS4`Y(C}cx_j7vC4u80L=Jz3cat03C z(b(C&ecGizGyzr3KQr3YKG*CR*FO#4eB8%1=PNq@XEPy>#@Uljb%JeT+`?hHk_|-< zrykm~S9|SC@TMkUknnAyebX+9f-TOSxoA~tC8EONhy71t&x2^V0Xu zR)1Qr_?nnmclzjynqZN!ZpE%^pFbGx)U@iIef)=BV~!-c6obb9Yom8fvx8Sqx!{|P zrvEiEjm{L_0G`nm9m+HA3ZKSjjK8ygZHLrNqppqqIC1y=n$^x{d-t@VpZ<9G>+bnw zhYedtzcc3i@yeUnt(#vpxvAobM3~=m+2iQl=RdTCDKctjZ`aqtg{i_a!LS2QMm4l# z?P=DcZvEu1MAvWYf86(|>cGJvG?_SPJ6zx10tsnn9aMEUDoX+yh-EpR*)^6!7zLix~ z|422LeeS-e=7wtZB>gSD95-B2dgk#% zv|-cN6J7Q{%a|~ETHUyV``=~Mk88j-(FVH@AG~wr9zT850e0)DQ+Bp48r%v$>eAZr zFWYr2>b)-f{Kbp3wrwP@AMRZKOWSFRi;aPr{rQ`iL&xqDY&EQk-5h^*fO_ku505OW z_NEK0%bQ-8XLQL;7C!Df{-?fIo31P#U$`pziq4Vz?@eYxJLyjLbEjWAcI?N`kr$Rr zztneqw_@!2l!J3-OutrGzGvu}-*=_EpBXZ*Y;m#nWZXD8s)0|Dhffs@yWLPWV^*KX zshir)Ctnjjy>@44)O+d&R|<8&!BID}CKiOwhh9{-S#l}uo1qvqK4X0t{JXZ`1s-=Y zopw>{V=?0;p<2wkB(kv*>P3 zbv*oP;n%EYsSUN`vf9@y5LdoDvv75=a*}Q4~yNwilE>e|MycbKEnRn`v9{461UXXtmV~RoG|kCy>1gI zQ{HyPRSva&`lq&4$?o%cLgUM(W}br&E{!?ZVfTu{_==`g)i++edw4l~>hOvixwHE0 zT<3oJeB<+Y{dap3Umv-u8m_zFN%-hN$jBt(owkXKmoZ(XjtI zkZUepG~sAY3`-NTkA&89Pz=^fHkw=GAUN+^(aD+l32c4axp;V`RglJ$J5!Z@Y+wY5P^|&*K`OZ+($bnsI7s zE_a4&&yLMQd)M`{c^HcXw?Z_4FPqpv^gSF(QY4OsQz!<`1TUb+6+S=N6(F{z+e z_ZB*l2=YmiH+T3-%7r<_~*xg?_Rlxh@x(%R+8`%YGYch+PjC->&=SlgvJWZIkZLV=OL z@bbKG9(pmIgDQ$=PkY5XbLZPd7puoTNX&^sK%6(LF!eGIE*i}cX52?Edh!2v7mabQ zGvC=CB6zAs3{h<I^6;JTEmO%;{hpfZ8wQ0>tlUc} z>fiO^w$*n_4>mT|tad%Uv{t!Uiyt!a(4@SKvnAFqAD<7qHR;WH-Z&P){pm|ny{oKO zWamGov*tDXF5LV!%csvA*9ija4=E{<`z;pz(m1)fj*QP;nEm;qroQT6o55Q(JN_E^ z<{b9gddZqisr8rF&ChD8+w=b6V$sdqq<*zWTD0Fevf=jS-kG)NlIp2#eyi~8y*G2} zsL!v;`s{vpZS2??KX!7SnBA#c)0wV&D)ntvW<<8sZ7=Kn{&t|^#)fsPo^82nUg@em zJM8ezgYR#it;%k4l{}c2QM-9hm49`w><{|5k3Utr-3F=e_d@Yoy;oKX~LY z@KrGIWg|0p7ly8B2(Ftur_TT7@F#!CoAQi1Sn=&r?8WT{*0HCi;X4!jJ zw!Y?Qt3J4s0`jZl9qM-9a_`XYvb($!eIHkycYHxwszM0$%49vxz13TwzD_GIP zbKv48i4a4hEUeR|} z&->5D{E@=-{;sy2ymvJ3{@p9}cUb)g4L*U`%*koosYz|0Hwx-b%pd*b$*Ls!X}G7) z9%IWt`O11(#+QV5t#t3-P+8b+Fn7YFSB!?AGH29$Tr3*3J*P#hn`@U&Sh0O{{o${N zb~$fc8cO)BJO0eO)t0YICuVPl2XXsLW5wkCmOZ`)CkgJ`q>R_6`nj%c(u6<1yMC+v z=ug!r3*!^Fw_3Hf$2VVEgUMZy)GWyhi}PH8;r0%TsOjDHiFNrhp|4%)?!Lr`F3}lwff7LcTX-J+w9%(Z9+^6Yo}LHQcFD(k$f# zPe0QCte}q`AX-&RZ;{%3-Hb!BC+UXTs)HqC)0p|=CcQdA(3Q4Sl|A2j*uAbWykg|n zPj9xIKiE)pt14F0E92vnHFrMK_3Du6m+ix!-$W{cct6^tjZi`G<|&g zRCopNth}%)>%Hds#Gb`NwjQ`dmX-C++*Hyzrvvj9ggh6O_Fnrsr=jM)X`ptk@aR@n z!J-x(d2^tc$(WG!PSH^N@}~|I%C_paZ^p;Z0L%LuDltM zNnN#mz?(*x`#Z1|BQEDPmmbWWS9|#DmtV4e(ouB_r&)fp%s-WWci0HW)&s9+^SZ5V zcWB~-%sPC-xHor>zPY?fgC!0~O{Z&~e1+9oo4RpQt8LcmwOW6ly1wV6^#RSE98+v-_#OE9X zz9jbM@r(A!)JOlE{UtC&*HD$Y^+Dd4qngLzz^={@_<`w81Vm2Wz<=;MqjQ^>+L&8K!8SP)ebIs0B`_9}0t ze+_qh&yI>wx5!^eDGAbo$(J@++b2=RUYUDr{=lO;%Fo`RGgfo@{yBQpz{VFP^#!Ou zggsLWx=mNi?T&Ze&1wiWZ^LR;lY3QFaU=HTJh9D-V>fPi4u8HqiP3X@uZ(NEaxTw! zS$!z${f)9M`=1T&a$46e^5XW5o4Xt}(+Phcu0Pl?Vc?rfuq?TTK}#NL^Itm48Z-O; zRF3=v(fR%^iA< zm^^9g%LA{-cYEX}cODeo{o&BMku7tV9y-y`xuV4W<;Zp*gS{SG79*vf~B)sX+CbCO!BPc&6b{vxa1bT3#v=Eb3=7v+t= zo>)10@21LoAGS{|>r;jS2e+jD(DO_4)EgS8jik$pjq>f|!#C0vVu$^-?uV*k=c`$h zVX1J>wqDnx)x&A+M|oH8NX~0PT}52jHfm_|V<;un%gjyLwqn2eeD^&?bq&Mmr!R{} zAC!FT{P)sadBG30^QTQ6^Qhrm`@=>3@mXzV<#y~sZ%tiBrr)BIaxX~shn_!v{mQrO zz}umt92bjbbm&4F+pz%kaVqH;`StYPegD=Q7E?tO`0sH zbH*L+QX0)}bL-(U!#rQbfb!^HQxlKg`zx!nH+NuSQvbO-*4Ixg>N;Y`h)8aq$D`(q z86m1l{VqvWboHEX)vP~hv-W@AqVq8JJ$+8XpTe)7W-lszI(9}we#&3grB6;x{l3lZ zH|*&*;-|GHXIB+{16zFc_K>IH1tcdIv+PM)sz4LDvt zyRhb`2!`|RY6^hYg9 zI_zVobGPih|KlE38eY1HlYb=VV0smYk$^84Iz6$x$Nlpi(q5M49qs%2$JHHL_dS2% z?2H=h;~_%nz0$7jNYzu0$Vy?V@BNe7iB8Ecc1P#k`qyeLT0yd1>c8}LzE=H5U;F8) z&6>&*Q|K#iOs3{fwdAiaUR^)Y)2CHMkBW?`qjp7S38O{RgJ}AQyKQ#P+FR2I7nSS( zXF-1VL4&yYDfu79j_EkP^bMQdIj6Mwu~~hx)!VwvI6Mrj(8=GrJ-Bp>^xd(h-e>>U zDLh8f^7W{!Iim-BYDW82JPOS7)FoT5T%PD1#Xj+>!1(2Zul+h)((ank(|`K=$)*d7 zg$s@+&y>-M^Q_JEzJMCKTlAmg3K9I>6t&3*9{iT3<1{V7G{XaE+8tdL?s^0Jv+|=9R zmJCk8zjHNzq+(Kir+Je~^Y(?o!6>O&F{4M(8B&#V1S@}m@<~k-QIWr3@QI=+5r3bG z7OsBhMoLQG&{p)Lo*H{<%#n4olZS0QmAxtc?pb5!G&-=Eg>lUlBptO~o#z?H5pAh?0+-gA;b#U|M(}P_{m$xd% zG_>o6IZn=fC|Hac(~I*n_>}EOzFjbuVhSzX*-qN^gF!U7v%Wp+``?{EmMu>?Kd%#~ zsDH7ou~U!it&q2#*EUmLX)J#{Ub-eR?byt=fp(qVOwAui_$#w$y5d*q+QhXa_LZZR zQby}RvWJ`d{p6hhYyEihOiS*OZTHXp__MzGfZ|p6evUQtot-%Fb5lcP>b%d`+_cws zI00U#w5kamr9UO5-k$d6iECrq;l$7XF8_|HX}&KL62NEL)nU4-+kT+?;mJn>@ z`z*8ADHlbLd%sy)&rB`4JxliD+igwR+gMdyl9SN7Vn{vtenw@7v|@5Rsgtx{qx%)T zb;W?YSAYKDLYMbRsi+@W+{zE-*`2fJ?`=pmjyqc!9o0DRemApZdVQMb?(dO47gzA_ z8tBtx436Z%k4@y)NC-MzFyS3I=j{BBlqrhLo+E~J%57Wv>F9&`)qfSVzvQTlp6mU? zu&tFDcsuyyBG?+wZa69d*0v#QC+Oz?5W7kGLT@G<{W(~3yEq@7P?jL%<2)_Ih`#nSThw9dnWcwzI5Wl$kZ7fwk>P%w%5g@gEyyh zE89<-HeE*lG9szHa^Aru+KSV!Na9xWI#7SRe`i+Uc&1#vWM=D?Pxp0cmD@Ob0Vm7z z=s1Lt(xyrZzvt)h$b;JJYdaqOG_SQLU^RuiGO<)*uKlm|yT(a5SRh1PB zzlDv?*BeDpUM)Ia*0b7mv-tSSR_pi9_}tq2#YxK(Nv+AyRwQVIozPA-; zE+$W|_8sCZK6~v}Vcv+8G0WO#x4Hkjwf%#E&q&tPK~GP%ZuK}(zXsM)5B$n_pYk@% zbH{-TKK{OZnDkg8WkS0HchQ|1PrRBxx$>D!c5MAdbqL&nj_Y}Br<_A)Hsno7O1<#? zVaNfDUox;YQ(oagWpno3`j%hmILFa5HL*RIf>+yQ#`vIh12BJ`vaygTEh2>|O)~QE z(GO{l+~52N>CanyxnoAaj6Qx$xbW%Pf)%HhrLOCR__%jCd5eCfzx(vVgQfW;-{LCH z_Pr$7v#$QYQ_Ef{{g79%9yh%sGo2zen{5Dbg;ytod`k%PpeOAKpX>ida zYCA5U02lq+ApgxI%Be10@h|B?ymHApUp34m;okUW)!u7a2c)eD}q1ZAo7LKbBmhuh>;N?RCi|ZSCyP zG?*hscq)*Od6t{-@OwzQ96$x4)8NL=-PNK*ia~#1T+#d66RYL#Y;F*{Hq`i4;;lM$z(pT#zBIzXrL6HELnDREb6$a;n z!#gfjubMbavZ$s*_2gqq2VNYJnDY=4SDZt0@zkW;B6Bye^d{_^qc3pmf*XYuNsR<)2y*m+}zrKCbQ;uXCF(g~X&wk1sdGHE5o zG<%ol?x9noJ{?vESmhfR4Lsc~j{mv2rXM^2{1rR9CH=^`{@mHiez-m%bMxl0d&*xNcvIeX z%L&r-Oa0qAaj(OzWna0+x0&PfYc-b+vGeou3tn`{`G6$W z=5M|tOJXFkz0O0D3GPFU=3Alb%-;OppRaEI!@WSvf1T8RWzsJ{P{hKiqz{PgnJ?z@oF^WI_g z$$FS=7GB#j{#Ks)anhTV){LV5t(8~0(*Ll6p;*xuyvZB=6M2%UJLVs2XsSPa3nsqn z&ExX{Vd~UolF|vyda|T}-FL!cYbMR>hCRs`0-S99NS?E7AsQl>LGnUm^X3>aO(*yc0KdXQ3G+6F!zWzT!*u77}WvHXV z;ZOS`DWW^U%K}2y$6&wje}=F!Y4L{1xf|B!7w0Z29kIMi!X3D%yRFC9zK29rC49MK zgH3ZTZTgVr9ZLFf6MrGz_8$A;I(l8=8OXQobKZ zgC+Jto;w|dgwAt&j_|C>Soj-~`gBRt$D1K^DJRo$9e*j#!P~E#`k`(2oflU%yR^sK ze^7dXck0}pf~Wq==2=fppII_weD}n1k4{2u znJ)X9yPLkYzasxg7YRGw=lee?&#qQw)*sBNtlqh6)yT}7kO+D(ec+7sT%Ba*bK>Dhw9;aA_4bx5m~rEp8@+Yf(|vNZYqr#BUz{@mQx#%Fz8 z3}hIe-d+~{(ww^SPBCY3!Kv!IU;uCbP*gm2kDCyCZQRrTdtdDJ>GYD|fl>$@53QLu zd}GQ-<{jSeKX3o|?m6p3e$L0flH`Qd?#?;tMDa)E&*zGTv&ZNYj!W~maSGZ#rK3;1 zv#ebq?=kO*U}Q2$k)L?<*FY1J%9x(eBqm*3+P0#&cAKx8j>he}u(fhuQm?9~V^!mP zGhpGIV^}IP{Ya#6dCv-*?S9L4Sx3?D-ft+#e6eqfTY6}{83@&7OsF3C493XWbEJaiW~cm zT8^z6nIKLzZMfbSlUJ~?IeYr_rn5_i)I1g@&!%&dH?2qKPDxE$(E?V|#lEnTnjeBB z;yH4>BmIZ;UP#j2#(>f^yVd;}JBR()_=S{9A4fXVW&4!Hc`Z1{r$0$}Iu7Ma60<6pYTb%s;gDMqhBX1kJa1PP@@^?d~tUl&3}X@caMi7x@s7 zrsesD`qaeHh)cXfBh36+vPkx6p>14If6QNE7X6Pa;N0YQ*D8L7GtHbr&-;t99bW0! zMx`J2`#{bnphZj?2u^R&X|NXXRZw6kE}XKvKR5Z;(D0waYB2NxOVc6|$W`3L41YL_(bKi_Etxnt&m>-4blJNtx|uMtmc zRksmOyx@H&^G|+GPCLDA4YO}^24W~afuT4x0K6jSCE=K{a7ieA0&T&-*3F7GCg$WK z6~etaS4JkWyTT#UyY1XLtDi)AbNU0xVZ>uEo-lh%B8-Fbdh>c2dEbv-?03Eca~i04ay5gHeVo8MeCkTWHT z)^#eKlaQ#Gkw7ni@g8qm{335mDLkS6=l)nbvL|?b1A5N?m-|xKN_wBXUUgw{)&slq|_Yc=Q!_4#C&mGtAir>he zK9LNFrtK%BQI`idyfALeLmwgl#wj}GlJ$G0=oDsVL2|QHfnEaJOI!p}VA`bE5I*;% z=@AE`;Cp*B_YJ7DG(}ksv{HHBB%FzW)2k|iN2UVCBNIHS3JsaljvA@FtynG!AOga$ z#mX>l=uYQ|4Gu6!E10#2CO8xAGM$@!2l}^<52nWxWY+C(y?fN}YoS?5NQ-)^At~>v zmDeXs4o0K-v+V%_%lueu^lou5$Jy}NmGb?yai-Bn z0I4pyv}yt@ajn$Y%DHLpk&s#a$bjt56&sFQXL&Bil@U_QzK4`S?xpWd!nvf}t_>Is zFzPy3#UjX1Y}8n63d7_gLK+b$08nD-CMdt`S1cyIp=wE|k~!rc*pm9eUlK%i5pR)0CDZ)K;-3oXFXuI@s5Ccrjp zBZj(F0IFQ%VTU=tGH;R)6h1a*3T1IKkHBaQXy;OaD*-c0(6i$%aBU+a6jw35g*icY z!BJOEM9zq|+kTemRKX&C8~6y7XWpKB^%_#k66E%c8-UtV>h|UBVsr|mXg!v6b^x|sqqJ$Oixs;4TcvhDhk|rqlUkQNEfz?!Dz)iO*xwmc7zfDn>v9H= zQJW6uV!b}yu)9%tyMGlt=kjXD@v+U>H)|iSTU0fy*T37_fJkhbhu}PM@GyJkim_Vc zQ%$v0317Ho;&@A>aWfQ>Vz3?*%%ZLGCxv?1yrCA8ZsL$)Xj;1sj@3da{tGgq~st%SzrAUg$;*BYB*^BgH?PDm1X1d%UN*V zcrZAmf)@easPSAL=>@WiJfs}VV|oWHNV|&Rsg=Wte7l&LU0!!M9*ho07Qe7)Mg0M&i;k8 zsqnu4Iiy|uuaNfg!UzOuKZ8dzJ*x0O2DRq^d_}-of$r`Q#qL$MG+bx`Dkq!(i$YLi zta1R5A|u~mE`|oOqmzLg>9%A7xGrfbg`X}=UywILa=G4y1Pc^%;I1rBI8^rIvJes& zOPAZxQ&*qswY@0w{`TG~Y*%P3L)0oX%VS96H3-8ePMsx*?Z^0f7~C~i`=0VAPuudX(E^~in877uUbyrmPE0%IE4-vAp=V^V zwA{kzyn?Bj05_34GMJkZM%04l^h0j;IYwT(xkw3wfJ5%d<{N7AzYw-5>Uj?YVN)aa z$zxOU$N0xmR#L9&6I|~=F5RaOCoZ~<`2twq!qUCf(cv{+ejoR6m6k9Po&RhV}EArSsP-5q&u zWmu?F1@IgLmUbUZ-Pr>Yc8??((zqs}2*Ba44PSeyWuV#%`8K$b1$gbp7ki^APU2qx zf*0(m4%-X8PMl=<+hF7Iy5kd}N_r7QWw7Y((M1k5V>ASqjiTY0 z$H7B2+>RWcIxt!_3PTM@7dDI&q*Wx>2gAc|Hdu zEx40px{h6Yayi}<6HixzV0n1f$c;o$56?V!+iU0;Ar1;fq1pt)DYPeLvIdv6+C^uu zUK2xE2oJ!yE2?aSBuIv!m@i#X7@CB&F|=9{QDM$=QW3S?eZSNW z>&~L65w@Xfb<|D*@&4EX-gv*X>}GS&vERXOsM^MieN+~j?ZG;1z4gJCRHprZ4F^*Wr_EOjBlq4DM;f#|fR5fd7K&!SUO^oHdCwn9N5(ZJ2u z4}3)SndbLpD9wx1802?=H&UE!;`LzpfGX$J{Df7q0O<+Kg7Y5w`Ml&wAH(4bP=+Ic zGIvoGIS7{CLPlE{6|m?CwAoGo!i_@aE+fXq@qH2@e6;JSMG)?lwu`YES)B1K`* zDF|dS84VTe5n7a(r~zZWfPM;5&s}Ah z+ZAvh-Nbr3+(~xe=C=E0l%fDrnreArJxxF(lKm1HjX(^94x|28(IJQ_@j9%YNdWIZ z1@W+yE;UZz8nM#g8lRh}AJc`{(f~*c*rLFS%dbArXM#$t^YWt}R(e5=f*Y3vXz;<{ z`}o5DSHJK7V`vl;WLHmB3tqSQ*SCZummHKwHK%zt{S-iYBE07m^i{UYKmpH-dmALgpiqENxlOfbmXU{+h-7WKRiv(`b<>$`n6 z^Bx7~sw3c+_QBq69Lp$#+lhmt0kB*JV5=G&ki+J_Ul>aC@?I%>BhT9LND(BI$1vmS~e$`;!~h_!soO2Rs$Vgz zBO`VCV}tibsNex$D#nyZ*cZYzrkexJrirOJ901j=^{xbv&a7rpHaeUTfMpVEy#XlN zesP_Z0*of3u&F)7iPQP?)ku3T*V@zVFpgK<8SWa*^nD~$?Rq4fED-&mYUDbN01KFg zDXzn2(5}gYh!IfoKq6h{5H#osV3DhH&xgE@{Fs-G+nNV5IHz#nDYsY)hf^JjwEVON z2Ut0{)c&Uip5NZLLHKtZ!gWa*pjdH#eWQQMsbS6ZV(`8WdKNal=L`{Ln@JU6r<9my z!f8X0XSU`O6{PtezJ6Zvvi_}EC8*L&KEE`Z)I0*pg9F4DLxr1;M*-`GDwCP5|5{a= zyNf>nz@UPt0!-Xs^U?CTOiAbLDyPXY(j*AYRQ&+(PDWoJT5%Ex%!FD4Jfb~01)`52 z`B-KjZ?lHwNho`K>7H~6&+P<-6CW91O){Hi6fws=Vp0~_t51|a>N$?%F>mm4T)~$= zna?>JK&D#)YODP(NF-1WoFN*2u0ZqQS%~tlm-^J?@7+yz8YfhZ@(*`+Ps3<9)s`6j zLm*r;0Rx*CO$&yODB|H)$j3)|3PW0Q07QZWlMwlZBo$m3L~r2%v*-9V%Uj~wPmMz5 z)Kc>%5b_aP$)^L8v*8%5eMnp3H+2~U%+QJ&%>g1#I`~U_VeP!}-(8 zX)j4H6+Cblt+?eitSvdZyEGh+)hQMTd6%mcwhACkwfB^7_s7XbUw0<6_97i^_V!Vo z?v>y8S{g%30fFo5oce6}Qdry-lwf|r<{`vtmzX!zPXaE^=_U6~d{lVP0OL41kX<9S zqxa@=2|N{IVR~zqgrQoU2Cki27LB9leY?>6!0aYN!o_p%(KF~>2-zg~&Ta$AgrPt` zSwfYosu<8*I`m0z!%tbgsrkBEnX(4t;XS%QrPP^@%C@Y~Z%QM22o#(hM)U=;X0A;E z59GR?^OK(=MTS{)IZln(bNQ-Z|Gd$Lh_-(XDmQ8Gbq7EJR}^OZy^Rlf4x5VL-ht&h;ZtfRB?NOAaH_LDRs7 zp1C|1G`F1tzD%!@&v15bQPbEmuFhUMRM4_o(x%07cFNTqCPoyTXupSoQ+~qiG8s#u z3D;}&B~3|l%yqDro2C+!EAc)zc&aHJ8s5rvw*7vABe1dE(uo7RCY7*eD4y$K>~k`H zho^uVFT&>#kc-@kmCpiC9AX=4n?yhr_f1#Y9AJAON?(B;H>NA!o5`bK;7FTjjXHWfHG0o`supYQ42Z}0PT@MTN2m*daq;I3p! z^h2a{`00WA>7%+9bbiOZs1wAR0!8-T3(#_UDR zUkn{Y~r1pf$c*O^T^qAi^DwO_978lH0_ z=eW-oDC#3FImq&9lNHkNkLwmevOaC7)z(Mq;JjMQS8Gqy;wjSw%ZM+Dy(l!1(7xbyjU(xBv zxyFN3#CJ4M)F8@55PP8t2#b!j{73B^%tLJm7Hqahqf71VhFNzu{qpAi^Q2FgZLzPb z1L#n3Ok&!vV}0LQQLIMHwT3yA#}9u_h8z}8n`6KO29$7I<~q200hW;W7*ZX!WOCd} zKJI3H@1mzf%!8qYwFj-=?S2u{5a<+IKg}7gY1{^gW-MPdc7oWKjeBeq9Lr{pug<2t zJV}`q`^+~NnnvrV_JvzB=8Q<82ba9Dt8SnbkB#D0(c2P-{zRuScNuM-P)=njy@qk6 z-b7QeNQ}JU$hs+W%c88y zD~L@=az#~3N2hc=zD7tFLIAM(V<3$|(qD{#)hk$`13OTcQR_1Pya-;l?lXI|T|Q6b zyRIBR5Qr}M(!N%M(WsR*%7kN*!6r!mB40jQ(Ty~mTQenAjprOd^%(cxANl`Q8SuXo zERO*M{-{_LZ{n?bW*nmlcy!3U0i% zo!2k;v+?}306`Pgs6a z~C*)rviTGpr%6oe@}^6isIsLrOuJ(tGCaC0+vV))nHe*Y_%$H4@D; z!^@4DRL-wEd#I(d`7R`Xs=9Yw^3iX$T6$T)|L0cs3&3w>+9s`$Pu>3&cyF}g>8v7; z-Wf?Jhxx8}cboM8#;i-e1O#AxkJAxUr@*{)<-ZpQSu{`R$n9PA2l*Cpw-S?@mwU?} z?>z_|-0&RDR(tv(8`Oh(Mp@hlAuxg;Dx&;&2sHQ+#;G&(H2_~gvb_JdyePI;5StBB zH@5)$Tmww7oo6H*>>PKqOJx3qS|`nt$|&Cu>H!f`GcfK zBo+Hzz}TkWI{=jRYv4@j+*?Y~5_a9Ai_fJ7mg8DFVwFe=*AEYw%zfGbgjVoBoQ-k> zd4Vd(_5+})U83wZ_Qj3Lt^xEsMR%@gog2%KOF-sr0D=l7%@C+r8x|km!<_=Bqv$sP zn~#C!4LlCxb@GE*GM}Mbj?7AFCGe=+hHOQ(J#YW=`<`BkK2Yr=oUeSJ%pxkcZu{-I zNl$=>OId9|Oh|m-$DeZMTgN2e`oB0B7wTla-d~z-X~|6M`_L9fA`^s9``-7{Qr=ZN zM?O%ZUU;}syFKk68CmfIwAxgDuQp_vz>PA?5QsIG8b;eeggk^z_W`&Y1(-8yz6LxA zywP>DTfp>G0ZP5;7vCzS13^k+9L$Ghob$EfI^y5SA=d;69f^bk$SKmH2AJ3^n;_ux zktx@Es>$#*b-uuRV`_3h{)fW~5QWF4EnGVpA_eXMY4{$=RxmSqHk=N(qtj&KP#$3f zh;OMSCNq!ZkFPAIrAp-dcFTbOU2Di?_*pefLW?{cnVpNy;&Uwd&E6wj5OAnrk`)unWG5eOMtjRHy&5CQQv zO=JVZJjXj35UQ|~Sl5X&Y4jT{h^a&-_j2r<{3h@+3Ix{BzmEi&B0V zA^eDT48s>tFPA~(`x?n}P)yJ%qL0xT_kV6h#i|$lkW08fD~B3UvxV8Qi-ij0O^-<4 z?qi0M67ECa)Rk8CK0qM3i*ZrSn(&w_7L4sK;sKIeU}W-`=EG{>NL)30j2KbAbJYyl~s_vBtibj zp7o;r`^&yRu+bvTht`DF==qUo7455Gp*HHvAE2UR>tL6}E``CF%(|P7tzZtRiN_@9 zDF-03l;A!QKWKE(s~BZGr>c};8* z@-7+EehI>{mtVi#SbUV<$N{P7zrVWVu-ebgZ3Br4I}*}~_j~=h^$py->J4FY%8E-S zuH~smf&{%t#AAUBP}D;{kAd$muNI|f5pmxV@O;Xt<_lOKr$IuZuW5$ySaj00&LH>@ zP5>|w6|wR&=t`E!*xWMBCfi=x&y2tLwC@ZRXbcE0Ov9r+TJ8guiVS10oJ~6zmn~q0 z!r7k|yn=ChPTn>f9}6cdSuO~k%{5RLQ|T$|#Zm6S(|{{zB(RHvC7<(k&Pxk8dA>Rn zd(47L=HOWvD7P@W)e~-7{1c7aYcB^p5~+~AKh7U~ zrpnDT`V7D04`a+lKCd6@0$D5H=ZXQ-iAJ z&!bL~ySi$d0+B!>ez`)}9=8&`@ZMtRJ%R<}1_khTUfMWQ6y4rv{^8V?jXct2$K2Z1 zNcC~A+zhauLh`12gVQIEt{AQ~MBL<$=jm+JYNBdObDFBKJNrM->y+tG;1G7#Iny38 zZwTy=cWW-_o=r<@R((ASib!uNna^Cp_<0v_?$(c>aCWb#xcR0o`)~`O-_u{)q9MZQ z8$acca7fpBGX`MFWDr7P*zPE>ez-=~&?lKTpQB((&*i<;>A2<;;)o}SD!RYqTrn*) zoET}ecANlJ!U^Cm4c=R@nH;6Rv?zUEIm%J4*w%(B4oSCaiS15|{|?b-{<_iEEp^72 z5-udCfOr_*)pD9@$$gbS4^cI{E5yxbx?%a z{#nHqLA0ymU}Gb@&qYKf7ACs)a)hL zgP%m=1&U`B=NEP^)VH78cHroe($VHr?ki)-ZlcA>N2n|?1P$uftfDl8GJ-5jE5(G5 zFc%|_Md(3hMK+m4Bq9bBW}(5ztaz~`gT=y@f>1|b1zk_K8X7&M4$-eovc_Z+E^wMaq)ulpr(8bZ5Qs&6v9Qpg&rT^+JW3af6e+30k6RY&=z6~`4mgpnjxXaPxMHVO6Qw$l8c8+GedMr zK&8*omgaxM#fp~tv`^cfi#!GHp@LnO?mVLC6tuBMAbp4>zzv~W!;?^L0g$|bthw*~ zDvZXI?r9Rpz4E`a;RtAD!sW6pz#TNm-})<3_z;qKLcUV>tu$bkAApk_)3 zUlv1pCGDSPfbyWm>m@mNFAj3G0t8RPV=;Wr!=1zg!wK}pCf`l^`-xy~ zaJ#IQ(R9|EGeMuEs6qPE1|$=Jc=5FG$KRX(bIFP@0${fxjniWQw4O%!1sJ@?gTHGY#A+|gyQ`BeI|>mtQ5=5u<$l1odfv3&`0rjEN;8wVKhqZW0^Go-Vxx0u1bM&rKn<=< zpgoKM6Sre;3hEQ+M3Of5rBFTfFt6a=--nNc5ft3j2ITzB*Y;Kos})-COTY#J`R(~a zfU!u*RarVMCsjB)#ePh`2~fk}6?NtikTM?w9Wb1L>~gpL^0V3B<9V9^A|m|fA+Cs* z50ppTf7`qY+#-NV_7^}H1M1ziw?ajJzrTSa1XRp7zi)qe0h%wc$bcrPat%dle`YEv zw_}hl-hS#y=7E@{x~1To;K)OSz-fIz(q|&M4N5~1 zHvyhEw|oTk`|3ju>1u%`5{f>J2%2n3KD`X><=i0=E*V@-`7{(YDZ zm|!Lz;8Purre*l^36!L=pn1(TV7rh3njx9IUIC^O^Y_Uq^SOYyG)NCj?pk*w)fG#F ztFc8Kf@%6Y=kv-!0mRYLuRi&6z+lgWP|F{-f|fK<+=}4)nF52&i98Id&Mtd9H)jp@_#28TosQ zG=P_alvcgRk~K&yGcoi_?ePt9?IFub z9jFf+0Mk(pRTXBH)}3TfKb}>b`#?Eps55Z94y=DQkV`S!Z&?uHsn&qksv11ds42;@ zy5s$EM-X&^`VB>x{{nAye$}-9c(&CgRlo-7bU`-ueW@^Kb^6yyjT~?eRs+rlcK6rg zdoNu{=r@HUa=!pppbWT+A1()2a)>TMEm%wr)+fgS?I|*C_VonJy)mev&5!I_^B!41 z{*=fa?+!zv=|lX$dHDeFAQHqy2xYfZ&t3_vw7Y?vU0C zV6O05c~K+n8Z7<`bS+}Oe>kcKb@+jKjSW*$*d@-(<@n4+8_=PE;p-CHYx%&VTG?GK z;kts{b7el@F;1XCF04dx708z4B_RF;#mqvMXBRtTnZ|(?;g0`mx!O$q1*2eQ;K`HA zdX5GHIeX4r0Tu1X67bz!H4bSvyWRD~c6LFR6LFoOn-#Vi(Q9!6N-!vF=hPf{v{YCP zg!^%jKcqQ&u4$bE@stQYkkC^6c1+r!%;;u()gD-MK{pPU-`zOCHhMyfG;jgWGEMVh zzNnE1SvzYA*#1`8wxO-B(RXK}#kF{eI+Tcn<14U}>zva02@-SPrY;U@E(7HV=cCkt zh;D^QYDcq?uRzce!-?Wfo+QeTLCytW25Bdr1kDz}9@-U2!D0>d$^lJ;#++(riEA!s zW=J?bo&?Q=UIs4n)dT>Z)Fme#B(pgDzHxaAk&r-kNgW4>z<%0YKBiq@4C?t zAoEvWw+Q?Q5_5KdloN-Mog3KQfI7Rx3fDh3Hhrd>vuJ6_FmJGnt+0l5K+}B!hFnUF1|Jok(CcT^i{2&vP~yUolwPNw*@1?l zHYkp-2aimgTy4&qGK)*tnscRM4G^>2GOx-UpSf0^YCY_ZXZ`Bn1NEl@b{fc9y8rD- zV!Z&dqakQ%w8Cux^k2KyN^u>rL9!MbQ>d^tdSyO2TI%vES`!-beMq$~7xg;AHwXGl zwutw$Oud8F>KLF^Cnt0QPsrSL?Q(#P88r8sn8z^eaLD*5fEltuOx>{rD5#A^mbmhB zJMxANahYF_zztO&PG4L!ZBoXr%s2scT^QU1wBNHKZcV6lJ?3%@O+BvGb~4vTg32S%zByC zn^mAydMV7OzoGq_xSI~5XVM>(EnK#jL=t3d3SOZ<@BRRxIhXlcad3*|_8VXQ*s371 zJ^m@s#s^5hD2DPRpxdGNW}^u)KWilV7&2*A7qq}RFduPJ?xr$9bu+bdhfv;6$Fks_ z$fc%8KbCW=zd+8u_E=+=j)Yze>(aq>YjrpNVv|Sy0ysW(-i7#vSgNGc>T}gc1~T(_ zX$xhnM!rb*23{3!&%PXmX;+@3q{qz*d#72&ED*VveV1CAM?s4WpBXMW864pgPjN1a z+srpH?IupQMV7bI>9?A0bEB}Nt5=rK5X^!d#>2}GtqNU`c9c}7oBw_=)Kx~LugA!pZr3Q7Wfv^A zIZ=2o?Hlv_v%u9i;=KU^6NN)3+$x7$IM8SS1yVF+MlF9%*b{_h6??MYnYu4a0&^}& z!XVx%&cx7KZpXl=#vYZE3J>bOgtjj|nY*ZO?AguLrlhG&_yZ8~lf_ax6W|%G z?5q$;IB|Y|Ci&}rAJ;}h9+c{6yqx5!nRT{1XSK?zW#vfI`JdVL{lH1HVt~UUO}!^Q zbsAeg4mK)xFkW)vW=F5kvpHXzV4*HKfqw%g<0fQEBr+T@*z5HxR>9x&{_z3`+kFMr zWvQ(LKu5~7bx)n=jvrCV8Q$a6PprLlIyhCRLxJXDG#&qKoVaY%)Xyg^<_jt6>DOm; z8kSbWYWK&ibVQ??a%fO}B3-RNbpttk2ZpO+)4A&xp33?;GD#kbe5;XZydm0Z9+L`t zTJ+;@l|FMH=Hej?x|Wr0S>DQePEc};wne`OTV<6=JnGg85CqQS-Q9p*F$Oq(C)T5FZgiZkXqo?6Ai zxUDl}PvQ%cQ(7u@R}6l}FJAz?ZGKU}^L!k&8gpUtMgGC>mzigc4QnHfoY8Zs<<<#w z(Zef_rw+m?j@y@Z-gJT z6`>70F*MyCYwdiV6Idq$`bu`e5b;%?6OfhKFI1uY^CJbkS*HdrQu$Yto$CdBCN2?V zMBhr)?1q`%$Eg{l37ErL-FM{*;a_b*H@TP7rA`m#ATg*u^(>p5!oU;nBgXHm*$=cc z3xsLREOn!6Tqj~dXPrnwOvCElA%Ig8gTVb$Xwu)kv`JI%u_9fO^GlHHJ9b_G*e zePzEZ&-P_q6>|_N_=ImX5xb~;?M9#;I?2M#hu$J=N|z0t>(xoEMc7I9SITHNUOXQr zrjqfeF#vLb7tb1&ZW>Gj^>7RsjvaRsX@$)-pK$83*RrNI>y!HdC$H`wzf;wAA&#C) z@`}_`a+vj)wXL`x%;3=#%acfWd5n=ehMt$rexDk+us|rLq4~i!=7@gJKq1g3Vw9Rm zHx-fhcEtQ{F((ZQ!|FKaK}(7}Qjuf39bDPpMu>h1XU6q=6gnp}rX>)zGnn{ON$OvM zMKXDAap4tFn5r{M)F0(G_e&>&_2!0DYG5`C&!Y>NWbY9MOY$}&%1U1%q7J? zrGx`rPqlzmK=y;E2VEK_^h5P7JxzwSjUVSmE>hv7*m#Gs(Q@#@tk5?R=~ll8+JlXD zMs|gQqIe!0$XNqh?4z>E!a!-Ms zBr)?kQ)sL|xwFTCK`q%hC6}pjYJtB3S+%7O*Yn2mr0NK`3Jgrh##v46B6qYTV*D&9plM zi1MD@pHJl_RY#-jlhW=+qcJex_j9(mvg{v5R_Odxo}}-bkDkxesEW!}aaIz~f`l8u z#wl4C1Q7^OeH#pONWZZOz$r38MJJrQ1fH&_RX+Pg(};Zjt=AFi zy|&{c^6#k*+Ifux+C>e2(U|v*mwmmWzi&lFBeyI5ET37t8*A(uE@gwvSEm>AREV`; zC2G)avJnsSwmZQ@9m5dEGgYekrpc zjAm)}o6FFC#W5q)xBo@S(VuE}I~&l-Ko>aOLwnjF5wG&4$zk~3qumSU&w7H=J@n(w zdx|jjCp}hMKC@)L%0G`^7YyuIIoARQZN&L3J*s;vU8 zw%!?5{W&AB!T#OhIR~lq^3nVP(&iV`#$vpAUFwexaR>L3p3zA1H=!HRO4#}6Cc`I| zZ67Mw4j%WnFX=XRq|kMu@AOsbE@##@%?C@VMh|zRGvaD;+?ScVnF|;9-3x@e$KB3f z@G5ZHShyfDyECMgkkVhBwd4=rESY(iF&hn3JV*QmQ4@PR< z{&-PX@YywmVPj{u*8G)A4D&|)?1Gez(wlv@rgvh4IO4Ai8wa@cu4t2@!iihU)YV_` z_6Zw%WZjp=z0)Ownn^UJKeZn~0aI{}R)iiL!iqpX2QD{x?(g%w13v_v(R!5{tz_fc z8&q8opj+o{S`=WXJU80ler~$Vfx#cc zOE|?LW*r{;*mih;ZL%-YedCz5b2j!t{QJ45k@(_T)Sl2fn_-;jyueonh7EQx+)Y(0 zS*Wi>eu`9&SO=b@yaRM*c#J={o5hnQRo$@pBlyBz&XZtywZUOE2B6$pMY-P&_*8B65=v>UaazpHk92Z&$ zZ5+_mASQq=nU>%>Y$moa=5DL3=MeD}%&ivdWkgfHTZ9Li1 zp`J2oC#MkKx`l(EHl~XY77>wKh;Vz|dslX2TVTMmae`_#dRVnhUX9H)+<%ayWU_IW zR;j%~9bv|%y3&Mr@X^zmC_4>iKysc&0KQooH7* zlKC&Fl*SDLu88;y!V%R4VyBFl0|G6FPMqalBWPkQ{1ofDDNj9RobW)W_(QGhJTOH} z@wemAM~{4=`qr)nYI}6hAu3|eSsvE&_M$}@xyb7Uvx{)44R(<}3-f$+E0v$XY_ft; zUgmR}x{-3H+5NmQ4b$Rjn|XG{C7kmjYJYF)ZGyn?00 zaTQ-qG~X$o8FPL}c;_kTX1snZfZWq4q z(qkVcXy z(GjME3af(wmZg~KM)`vI=;!TxjT5wAA6?}h6vlnSV4~{Ynfd{C1R_&)c&!v*y!m*o zY3utGzitQdDEcmOTGs=@kmc(;KpKDm#^$2qewocW@+J)xeCn!NwjGs{#Yn){8{yr6 zG0yU_bz+pyC@vG2&1jX63$uGD#=XkII!D;>p3js9F8WgcNu;xWdu5w!xTFK{jjucC z&dMobDV?*$yrU7;3gM_QsaO#`=`dhU{QqaKnza?_j{Y9|Kb2QQw^^din0OaM2iybh36FwS`5^+@VuTRs`rzg=0d{4gAqMfQ;}!zy$cGiWL!q8SLeinJro!4RuL0C+{l** zL0KXl%h9LdY?Ufhr)MoCF;QktSa`vi_BXToWe@VAQ0Tu}&WuPQD+(BPZ$ zcrIC~z^B?C^B@+%Z;Yt$$h(j|JE@W+TS`lIE(1kf@>VP8_`sDCtF3Aj`y=YpGQ(N zVy-`GMcZ%FW7+^aco+0xFM3R#Czd3)8KyVHnX%5bML+Pa>^5^rPFCAK91%0_JNEic z$ij6=3t26eyfxEK?iNdON>|_0?xFEJERFKYTvmX($UU<1XvM`C^G{+CgPR=4 zw`EcsvB2!YRcf|M{oRhTVrol=>tf1EL^Iq!Mh=DN7$n2b5-HRFkeM@=K6-VhDNNFu zd3^IE_}qr__Jr1XP1y|+R?1Qfc@+V_9!6fyklvOD#&*ksR;#A7?{I*`{T__s&e}K? z&So9w89CV++JObF7gU~qy~i1ni0*g>N9jtiyb_u6#N1()N%8f80XQEU{8r>47a4Ls=yZtx<4sz{_4Ehx zp@Cc824jSvzVjgo$jSu_;9YZJ*%mjV|HMN+&e9@aLU&hCbIfw`*Gq z6MZ;l)~xI_l2_;L0^-EYrc!+RpswY~eJSk+#H@l2wW0%8fSZ+1peO->`28$G&O<9q zv0}7;*I`6h6aVoR({QxdLMpp1mc3yL0aJc1&@4`#G4DVYPDG%sPSo(wM;3jt|7*B? z*%Q(mp1K<6HSv^Pu}ah7nSI%EGU1_h0wLilex|9L=LIw%8O;a92K1@iI`1wk`g| zoDCpF#rE1?sZYu09rr_6)+BOzkPwDPa1I=ZpKG2lro)W}_slPCo89Z6tyZUX?6?PP zy^qSoIf|ASSsyqqYCWg*QrbmCUi95wKv-X&RKsR*Wknr&fdMy7lzTao7TcU=9^Sr;8ni+kX^isn1a)TrR&&!95!se!?G-wD10#wwK%zVH>HONL(BWqY-nvHLq3xu4S)6UbL+u#!BQA?o6Zy)3+ThW|Ax7c|z zT2p)oxmr2Tx)I}tWoi!>y)+P2#zU1H`E9$fhO)QauvJ)LA$-zJoiR_Lk3E^-v~~`UFfhXzo@VkdMhFx+*L@qWgtlqp1+C`?$Xy;Rg3(mzSNp}#m3uI-n zu!e?J#bmLNuh1C8G?}WGPqFZ{lhXG2*~R(vu#pc)a`hQcBTT7G+y^469^Y*$;~+hl zE2UW*%8pw9?%5DW-2k-(iT+&kY%e=rz>0m&=#<^!z@=7mp92J?aLTdusj`>|ab-FY zI#z~K6*A)?uhpWNEMK4`h4IsuclviVV3|)pIrI;n=0V_PTgAz;OSv3qr_U^!OJT^E zgb|D}-6VsI^Dv94AH0#x>)*|luv|ejiXS5yG*WH1Td>Q29wRu^P7{n`X-_H-LZeQF zVxz)TW)W}^VPYips=TtEAVNo7prcbo4awHArn1iEORubsOheq4IL#86w)x{f1dP^dsGrvA!@1b8HsYs>RX(epOHNKZzh%m`Pwq)B7UWoo0I;~_t zYP3CwkBDMM?W8IylLqc=rr|w;650lD2Gh;j1s%Id2ar04lztDny|`G%BiljLF!Q~) zn!_gan-%AQu@xN?%7?F&L>WHI8%ORh&e$WX%rziH7xnINqFf3_^I_iWa+0f{Qt{rx ztgLG-Ta8#bl>p8t_deFa)5|NrKLCNj>Kp_eMiAo3#a4)D2h)wkg*D+?`9h6wdRZ@= zxV7Um6A>R}W>%QOfFXg`geXb2t1<4tV%X2Fv6+gE|C8_bS;tSO+eypcomrH_u7$6q z7y470Qhbn~q7x}n{wf=ALB9I}_-TqVM%jxGzHU)$aqt+-ZJeH>oMIhNmCD{FALu=Z z^5nR0cle!G_Ifyrb=1Pc!L1)OuUL<)-NV1qH$M#fb#)~CpM7x*nN%dORn5invpYvt z@m<|%uwy0V)RxJRX+*y6fMJ>4)laoN(H^wdX-a2P?14vX82J!ykOdBLz|ykJJE&*H z0|x9?8x0W5t4@Wqr~n<-@KB|NW0s)7!*r4syYqc%u0QY@GN0c*W3|(+E^<1NHDPbQ zRAn|kX!B#FI{r{<>)KukKSHr8k@MrDvLe*x)SsL@ zS-zFap%_nne35q5*sq6!zy$=qwaLAU_c&e+o8kpI9S^-vN$6T4`JD;^Sg4(y51z*1*mO+4%p0llW2 z3-uom3}Q7pf=B=OYUw4#Fo1JO;FY&A65iRVw8FK#wGA5mBtnb>p1n4*Ghu(8cPaxx z6$5Ib7Bi5DR`JaXnUywkTGr&Kf91rM?ce6S_4amON3na8kneT0dOzjW@WYOpBimtf z$7Q$uVBDFHS)Ma9muf=3KWwa8in1%tWZEx029Z~(mBq@oSkbdDQ&Ie?@+w;w+Nva0 zgovZ|l#RJQGgSuFetEky$g5OJ#pCp2?(Ax<%ae~lIA;2!T7PN4vtuIkOEj7#(W2(v z7g{W@aMaB5#-W2&y=}yT$n2*JQ%YplFS_q!O>=i|)UK^awtUxqdnv{7_%Y+nZHfBF z%b&lvN2k>17TWz87Daf0Vs3SQ_&Mp`v)O$O`sztsDQuTtEn`6W?xkJ4EiY9C#kCgLU`4aYn?$D6{VK;esAR$eH{ypEIP9+$F9@kx}( zGIdvV!fEl0pIj))A$?hO!@0Lg&EP!{_anx$eWK6@Bd;u4o<UbtM>5C>`uq;#IFcG)lHxWY^9jd5@4 z3pGx@lqE~Bpo-LmV`3-hP1m$^lGwfQTnkaTx`TnCpKtGe`(VYCK3z_}Ci6N;2uqhS z%5~+nYK1KP+7&$7rSDMj+#^u>k8ioq_-XNF=9LI0LV$|)GK>)mdYV$lof;xc^; zuPwXLzWo9+ANt5IXe#N=?#*Z#dNtQE#F?IhbF3<_KU|Y|uO5=d7#v-%P+*U)=CE+UkQI#lww^Pm}74*VX*>dYj*TneP~ z^+1p!3^@qhw3Lm@SqOyFHd4ls6OamqwtkRk30oaV7vo9dg3HZ?uMQ=d_sGG-mQ=aV z6StkJQ^hM5BNzMHzG@q@SQ9%uXpb&Ga+1prjoay%x1sZD%20sOv{PRGnJuN9%Pf;8 z&1>xuqHIq;KLvg?tlhZRiJeI|soNO-k-!-%BN4o-r1#@sgA+!7cye;kBAK1%3`2B? zJv=5g3vGOmNI3p~vG<-~O|?<9Af3=d6OfkBdzB_VL*sN(X@;2m}Izj(~zv zMJyEQ0s_*TO0iHvuY%G8QWTK;M*Z&GxzGHVdFJQLFM~Nb=e&LIwfA1DGA8-_>dR+o zR%xnaaw(923aX*1GnNV9oQ{Rg2lvFb5$W`FHztlTpHvBbs{lkH6r#c=ybV=$m4cD% z^9GXw=gD|S;X^m8XQ1W9>yec`*%1R)q!7Mlt}=hfdAr_*VFCSZF8KL3Dv5!4z?-am zK7MX)`lVjRN46}+GncG+-bXtKra;_#m_^R-AJcD91^nbzT;_JrfM_dnsQq*aux|t@ z05ph-#$S+oJ-v@zJX=8i6r4(Y7Zhr?p8lTaCid=PQgo7!Q0U9Y@!aojiW}eswVN5U z4A~yldar(mr-~G_dfe6hZ%?>O22AuTe6XmzS<-3>$2M_dtB7xi7?|j~=`6@jL!0Zg zs3oYVJ`fmK9GZC>LRqZ`&mfH?o`>N%RNv;^=XRn|S-O3#55h49pTv^simQ$%Qt@F^ z=dNF+?m_{I40O(dEn3Uha$;q{Q&|pb-6yg{zD19W@lCHFAt8t7D*HN(&}#-j$spWV z<*v~o$~p2#sGvFnCY*7Zyxr9UYQIcu=fF9X9j?>BZf4WQ4PPw8;2kNke5zfE>D+F* zii?i*9EJNJn}TeMdJoE)dL9y%Gm>rVsw)+3d$YV)unN}DnA^rw{hnU25YtkXyO>xCns~^OLJM_Wm}h^t~Q-c7L&^O6L?y z*gDnxcYgs1F}>wdW=swwE7mj~tL@jXVb+1BHS*|6eNsQE-+p&Rw^4OtT9!7@08au7REuh2{<8FlN%##E zrKSLo*bs;w8q}nQfa+Ru@5ET{?jlBSdNM5Oc81G(3j;L+u^p4f0YaDBKYE*qer3gZ zVf!V@6rTgHNkw=tF{?Mrgk6i+73>$af-(&|m*>c8vA~43*-hAm{rLoX)HRCN$=*<8 zT1L!Ut>UVjA;J0+vv|BhlpBVtR|WAhoh79|<>&b)FOq@&Z?az6V57n7yewX_2MF%v z#4$2eoo|dxTOU6rxW^a`v7#uLR>dav*X+Fh}@a27DII8r5MqzEbhzf2Zg93y*dOi0vz|Orw@1Ta?S0HX)baN{EKRP130J zOa2=c7!6@qQq6SfU1eeLD-abWBGK+9A`^!o<_QSA<4;l zJELJVsT2npfC<$kXoti~SS^a%%!_>?c0X63nsne0a>3D+6-{gs?Is`CEZxH2&;Et` zPHz($+AgmnLfa8-ERVqAh*RSD!h<^U1X8~vsRYi3sv%=!;k2+5jZB+3raq||9xR7y z7gp{U3A0y3M@Sn7Cz~LSoPh#oqO6q0VvVw`v^LmRi9!xo;Wqfnd3Aj@`WSXHPNYPhL04sZ=qO2H zw(Q)eL>l*+#$Qx7Tm@MQjAr-#^9U4Rsc|BXN@w6&$}~&)#teZ`aIUVbU0#hP;uJ`1Ej$@xtYry9 zXJErTokL#d4;w3CcjAZOHK6dVTC=c=oZDi!QAXEpBk^9y-s%ki`rmt?)xAsZ z1tD*CM^%1HuMzCe#M^=bY)3i=*N%pTJtXd7MSfOalZf`Ys)smRVNBBQB`gFhl^6SX zl+#@{R|MYwQHMC#0+R3i)~R%f&JThZ^nwo-U(z;~W9xcF6J*a>X6v!Oq6M+;$|!pmco@z8j{-rW1GX^oLl1s z{ru=mT$;gsQ}zFbmxB)s?-Nns_2b-1wm^1xLQd0MDA7_%M=*u16kk+sP#;lOa>tc( z0*SLa%H#9T4?U4NN@%3^$78Pebi-A+7>;}yrnHn`>k;V2sLkaQBcfF+3ZcQW73CcI z2TqA%?m><6#mf4ER^Z90_Q+WKS0B85b5tX(*akFPx)9(qdCqJ3x zqxc@();({n$2FD1vrPWUAkDsuLbV$gJA^ImjY3$ z;18A67-WBt)aC5yx`zJ>Xl~?EsR0<~qC8(d`nQKR_=gdti%F8f;m2H=W4#GIZ(yS= zc9|}H{9BZ*L7&>2U#^syr>u3<~RJ`zCr4F=$+X9XU5PIklT-}ODU&^aEf;Z12zvntgI^wX*yfv z%)%`fB7@KiaL4b@J9krQTb6SW}x-R(d%d1c%+3rm_rHm@@#JtcrD zcB-D;La_S6=^J$K?ll&_$M_A)*BhB@R(c|r zk`oN5;mR0xU-_$2zgBL-5f2(l&P{f-+skF_hE}7RY_{}&Q?92sM=DMJzFo3apZD{1 zufj;hz{nMja>rNJ-PiRLhZWC#ak`Wh28t(TF?#=3 z@@vhC`=#Z)V8?h>aQ8odN)8Fj6+ur`e;6>-UQ&ukgr3sN!n}#b0@6g)^djIr5ayjs zmPVg@BK1+e+&-Q(953N=@5HZvd40+5%#N2&?ro`GMw#=f=|59j+bd+Q%-mhtNOMT# z;)S|+DZF<@L;M1KcS^=>_TN3|E*^!ioy*)U;_bTKxaMg#5GT7$8>g*~c9UAk8>(wa z%d(MN%Ezx2zPXr17pvUM;GP!>TY@gUcPtNFj*-w+9lIG~+xqzt=WxS>s;K_A58lJO zLknAJhw2~h%y`K7Xp>kZzOWX4RQI4v*u>O&=||3gAmBO3FiXolw zudK_{fXfZ^T1r_Xj>*Fcb)rQjZO!*`z8!*?u`n zLH+v_F>KyvoQ2eAq=|pZz`nX%yp(t!$7q`DBm68SsItF*rya(pM;D(&h1KG znnS0iM^R4hUP+A-7CooaB@1xe=-WpGKh zEL$-zHEH7(B6 zXRbqa;DG+b*wP+#bo;K7`U_h3=%0XjRO0KwRZy$(d7`56^qheH5Brk;hM9}sI95@>n&<3uf2=j3U5J^! z(&d z4GMP1BGkTt??RIgk?T9OdW!IuSdLK@&ju}cEfoVlJHNpdm9H78!CXW1MZDH<7fbu& z&X`A{p}vKMGkZCyYP}AGS12?hqNZik|<3^CJ1!sc$0_m7j|;_U~aXL zixyf5k&@|f*FSA$>nEMu4#R^1MQ|{hvDt_ERx-Bg_y`{1G0&QtLNmATwLNwUZQd%o z!N&SK5ASNYwVWYph6pLk1w38RzR#`;gV4UAyJlM9bMgNzgW%;W5RxnhD9=@^ez-K$ zQCGu`6-y(40XEZ|CMwVk{sM1Bv16=d3Wu(r*QtYlNL>W!>oLF#+M!~0>}7L`@finX zsHN2{i^NY11Iu#Rt4Q^AsWx<|IXZ!-=nZ&wAQxkGwJG3fzE7k8v5k&>KTRZ!l~eDG z^YRHt;IZB|1#wj0$m?)6!PH}fdN}mT;Utx3u!b>_(6AeX-gK36VBv5YWBzri-Tn6RFyns_%ah6?0 z%55wtXm7)X@I)|LcIo{hX*E3*7vx!|b%Zb$S*Z7;QBK6=H(W@7Omy;X{@6AZhSSxa(VxdJi$o*tU`xS`dFCDJ? z_Av_Cp|fgb2?InvK0^{~luuS>1yKga>Q844W(+-+*D4yf#K|1Rj`lXEtqYN-7pVW7 zz7bFn76K@L982J=u?Rk!W1yp$s~ZYbD$oKoo%(3VJTZ1i?j!w@8z|AcY@k9vhGzhk zAFLBX$S$he$Izyl)TgBM%CO@J9pmlf%FeaLZC8jzWJIsy6)An#c&fDKddjzmIl-DC z{)f0v(K#!Hr^=z?^uA90>qQ}MMq)PYlT|4zT{SaOc}&7}JkDTvkdrmH zj{t|(n-`=ES!@^s2^ps&#`364jAHZLYptx$3`NrnhDR&kM;(QBUFtcB=NAur1Q5w- zgu;KKe=rbhFf)L=Idab)u5UV?;`>5;Cxc}*Tx9Q`Th1D#<#|Cb zt>_uEU@EGQdF3MPc8)DpPmC<~FdRccUie{C+Kx(>-BAP-bkzVFXz}B0V|obJ;(ljm zj(vefks|B6n4(X=!STVV#*k`6AH8Vk5TqfcA+2_Poua1n1XL+ve4*E34zVI3N~5%}SqW+84Sckyyvo`}Y??tYO;z+q#*1I!!JDFJ0|Z&S zc%72!{QAQe)x3qtuZgO@8ZbW5fSPsjKMBogYFmssfhOScjq@8)Ji6HGD4Yj*Q4djJ znS*AL#&~%XDSaE<+#AQTGEucilqkggjtQcVBTuLG!Qfjt^^kqq`M4?&5mw*n<98fD zvt=3Nsi_PnkgGe--P3R3$7#mhlh8-?Ld{T&khlIrmrOHY0&bIIX(0;GuFdGUXui6+ z+0dSlfu<-!M%^+78T}aK8xifkxs9?b8HXV~jUSe#6I-8tzGwet&hSR-s#FtzB(qNW z6ioj5Utp%cVG-mSzA?szc>jnA32|kGt*?9eU5u1T$|~Yhd`bBPejGh*fj~lDpfeC> zAYbQIu*y74x&lj?t}wAwaV)FvK`{{Sh(U#QWGZ_ja5Sn*YMHdwzB?pT7_J=&By^`& zd(pg*to?$Ax^WYI-=9BIJ3k}EQ~X#> z@X1zEHiDC7sT4Dsf6v5bK!R!h1FCrL2wO7x6=kL*DM-1zNpr?sOM+ zy|uy2!qbYQUcH?QUYz~0=6HRoKicPO?v=c_`8OWOxK>w;%gr4xzW%neO)|^oDClzL zU>HwY)@qYwVUh8vPBHJl?&l=KE?$Xg?n?iF1i3Ic?j!~y;jNR{Ik+P3#{Tr(K@1Gp zT)Akd+7%z-*vno`e*gI#D{P9okV2OKOg@SBjm$^0jMs?gzxqg$R}*u@2vjAkcA&#+ z%o0-PVUozm$zl7>O7shX@*#zGXy;*@;+~34avK_>{c>%hbrE8G*aL;6tPJB-aul)-CE`;sSR9OeDjfdZEp`Mq zW+YHUmI~Uw{voRp+yBeb@^cE7TbQA9?R=7zyeQ&xt49e7>?zT*6%1pmnlz3 zEd_PXG??r-)P&2cr|JDv!=vOaR<&6C)m{(k2pU9B_?DwBHr#7g|DkyyW{XqPY++Uq zViG=7=_$1Je73DSn>7KI zVANFp2O;-h#gi`@CyT|7$v>ikNK7*6EqeMH{QEDwb7}t3Yv_XO=q!-?uKM7lQdYB; zbY^`peg$yp!bRB2^xYXBMB=9)oU{lp2vWJAZFJ9?6GT1Dyr|P zly%Q@vY_<)o_09id9Y6KNO|Pd;eXvrM8R!WZV}v#;TQpW~>c|i> ze2hWe^E!a5HX`+G8Ao@!V~AYIpi?2M1hA#=bgN4&WJy26CqUv2 zZNppPGyL?GNWE_9*NMd2v`b5keYIU2Gx+O8VoP7=-hW+98@Vwt3yP^(%ku<Xv**60gcqyn z>Fdvhh}ee;+C29GMro|hO6`X&=-Jc|vJOyWYb~fxaFRYUZ1|130N!!<3ktg&z>c7p zcmpI3C<3LVk6t@v)MG~rxlb6R^KRts3IN+Oke#204|#?UGx@F0Ix-Ur^6AS_Jecy= zZlCxPb9aDZ2f1uCd#RL_(_m6DMFI&xn+j#3DE@5+(OLkbf{IvNnaj@MC&+ZUliuK_QB70{80!ugsk zIK5LpkMdC_jU1zp?!NB+inWnj(Zdo_#aAYFM$jehlEAjksCP$A9w3L9`>Gvk47I^N z2h=NKs4EMK$5RG?+A=eXGWIwY#QnN5R7j)Pgda`6mAeL}mFfR!T7d?{%LUm9uYuH* z0{CZWP)9Os7zAiYNGsYveLu4r84E;pMY1ty%L@q1hQju-Q2NAhkdZeEswenW?*ep9 z88BbW&7I7J#xehTjHH@j8EoPT#5vY|y2u$_1v}TLpZ6mJDs-{oVaU0cO(^^VlqUv? z(1MjKUy96xY$b)nsdcI%sD|{^7$&~X9k-!Lqi~M^8wsP>^5VNv;t|v*LW0p9p-&Ni zl8+EDdoXL3XvW{W2hB7GYtw4=9|1;NAh+zi4K)|mS8meQ9R+fCXY&LFs7-tp;)G)q zp$d@nmU~Arq#HTp@QgT}B@_$nWK%Tm)R6tmivD(@4^Omdx(K|P2H!OVlswNg^P-GR zb47!{KCnpKmc~%>aMLgOA95Q}-t*^VTflI>fx-#A8rvN|Hm6lFF0z^(pBso^JW3>A z?N5JMppv1rpqPR$$FqI6bHHw{(~4{Q+f|M&ASQ7GXH~=UXA38;$@wZ;Ol81*r-JIq z&S8#>SfA#zODQ~PB)>i|GvYOf;WsLL~Xv?mh7U>OCz`>-c*r}AV-^a-fBv0rK6`8 z{SgJUs5&L>>|PGNVL?*+KT83uC=?7-yPANJrgT-#JME#+O1l-uL?~cK)|uWLv)6FYoQv z6}5aLg6{$aHQCmNC?8F%T@ndzQ1TOwf|n?CZq%xrG3b%35brUQx*){*R+q0 z%`F-@5+h%l6#wtrJh0o9(=$&nTOjHOJ>R44uO>ClGMGBo4f_$V21gkxe_7xY%&s%H zfD8lcIIWTI<;uUjG#7A$igK9UD&XL23ub8M48V_l$0B7Wd!TFU`d|K$S2PidXa`)lSb(S!Gzax8xM=T+W- zrwe4dl}P?G^=^Y7#!sl7C7`UV1l105PJ6RI5Wo3Z!uEXAcfbOe9H!dfJ7`K6x-_FZBX$35HCAx(g&XvA7YP>|M*|_MGyk#$ z&1u0`tj@O$frWu)(gBa|qJ2L9?>#pN@2MVm_iyJK5#BSdeB#Vs!>JHaz=C`SC?&iI zJlO=Am^#4WLUGIk2ymMKMN#LFzW6Jaupm$%6w_J(Fspq)2s=SIPRuRGRvZY*p#;Ik zliAagd`ZBKr5LbkZta>Iu%l4~_^f&eQau}!^+OF61P-L@^(uG$0vlnnH6h*YTxkh!(PpppqQ<6k1=1V9wC!78kUimzde>gM)C}%zdVrbN{|a8 z5OLRieP}%al+Qb_J|fV{o@{uB*8rLMG1xSOE$pQxP<%R?-U_o|QWWWe!OejNU$SRq zI|apkHNb@v*=K$8(T$ynlh)IdEv>B6?O08hDTb~e1yS_XAhAk%(RCq=aQxKn=byV} z3RN2b6_qbH2xMk;fINHxP{ckkIkB;b@6D#q1W9pXWv5cMjsI7z0+LFykaRkwsgHi@ zLk7K)CTXIkCBkHX=8s^CmME462XU`rBLHEFD z&W?ifwPXk<7*u!wxNjx^zszlU*Fjom9AHeMBT)!F-2NB{*yTH~hz$`$Nk>7`GEO8c zD`Ajgf-pUh{d5lh^(8;@$DF3I@Wb8g1ayNOh2KhP}7Pf9L* zP;2KTg@@NC=dRcj6q5h}tuoFL)UdVFq*3#R1rg4nVN*Qy4_hR<(*Tj(&p$mD#wBV1gFWErgZ*!& zQDkp2cV`VD0fv1I2>WI+Wdf~u%6^*|D$3fwfoy$W?&wXXh_BpkVZk_Y-OkO&PQI!KMueZP{5mg(h-LE%;Uv zYu&5&26+Zw1~U(;K|!#h*HnYn_P9%1x?Ynn{^tVY*AoYNl$d1&0nE;Ft}d$n08)=y zk*|Sxnh=1ry&bjyXB`DCs?{DG^xIMgYhy!zByJ>@bEFq@P1|^{RHu& zM%!h*ajo33p7XOdCm{T{f)ONS>i`{60J`7=WCSu`*i8RO7z04P! zl{wufigVdawbz{nnq6nGOpA8`qkWPO4~DX9=tvt1(}J=>uT3DK0UHwvP$}dH&}-w? zeL=$_gYUSawxQkAjt71yeOEr7kHmC7N;xWY2&77)G%DdsDPgEH+C)@IZ_hZ;52|j| zn!)0*HJ~|)bLedXOPbE?bW>2pSxy)E%@r_3b=|{3^cm7dx9~yDN*bh~E(Hrs3G0lB4q309q!uqrWnyc-2(=sKb9orXs8k%El3Cfso~c|* zHw1O(0I>{?%Rn8#16S#&7ef4;90wi!P5_se(GDpqo9@!L zGL_5H_kV`9jpArh;E`nBaK~WmxzRnLY!9XuQp=P%Y#*7w2l+z{qn@E0OUlsj&q7-Q z8%iEHnHRHwGgc+qEa~5AFUxN%R!D}3w~PoyC_{;%cLSfojX>GYxn^2uxn-MH4^V%2 zqm>8COO=IC@sLq3g@PQ$_9kK~Ckr0aj!kg^9wstvz=MAQNB2TYcO1TKrN)nD{IA`!rGwFqG8x&B|>0asSU6z@^fXf!F(f8#gmjXN5?d z6xC=hWYpbCxAoLL2AeQPpURM2kY>#ibC5}7MEha z%L_<(d2yY;+Hw|u_&JHchubgTi(6oYro5lZW^v)9K?JyhW|7b?#T;^k!1iXy{K5Bi zrV4Q~=6hA+ZCT?U4rb_mtKQlVcS$sn9J@peUFzBN9xPpJAIL?wc%8^4@D#E<%~dR; z(ku0=rULq_k$HLlET1$)fjKg6Ynb^uSyfB{L2v;`iwtW?LCK)E5RR~GSa!`r8ojUn z&HQQ%ph$Jz78(d)BqQS^hHFE$&cnAbx4OyaJ6xgeSji#yIVd%j1RGQm2HU@~yjUse z&1n)zNi6qWa3oodkA#E_?*Z6GA#skGXQfGYwT3Hcw&oo{F`13Z_%9%o93`T6Ca}7F zgr<7ej}6Sj9-6NzdC60PBakFJsvKY;ezFwWNVexoDgy+!&&&d#>pVi-(>) zBuDv2Z=4EY%y11N#35>isW+&%h*5%6;an}`kGd7@Lg`>k@aDvX^H{wuS!aV-8h2c0 zN6AqKwp;7?;P4S@6QYP!jK<@`<`m+{r@+C%i%7BDMg4dgyMnFM!jL#=<|%nT=H^|Rn|YgQz)op# zIJg~@=jv>N;B85^ib|BX+8(Zc{uVZxt>}6E#VG?A60&@re@31uVMwU5syPRwgj5?^ zoEeA(HMpFjWgI9qg!Het!11>7Si_a!bg)3XiG3mGRQtIKW7~Y5 zllvt@+szQC>#4hH9sE}{Q(NyWz1Incd1HQ5@-w`f7Z!DZrT!rHrKIT-6u{!EoQLv9 z;+S;dP2EswtfsT@IZ6rWbqB84t8am=6bL*p^JtRpJf=Z(Q75H!|6>JlOe4^7KrhqM zEYQqHv55s2OveEYYTcrcippmp`juCkX}Ay42Y*+IwC{Fosw^ZaLa4^o(}pry>*!D527d}4^&9L_Z<=?!*>^D`0#C?vtfwSN($YRBq>~pq z;H2XbVR+n+nf1v`67fCaJN!JLB>K`%P=EW!vzp7FNn?|$q-Plc@aYcibI|S+nx(;C zM1uUjU6*_FzK-fuvTaR@AVJgzmKPoZ53MM_P*_wBSq=W@R&bE%>t$4~(Z@L{<>b0i zBS{t-LA9wx_njB~&$?o268h;C=C4AT5Dy@%k;X;Lf>1+*JfzpLm&b3gCdU=s1yW}z zFk!GOp%#i)HL*!|3cKPokYp(gj;@Ju+?EK-g$1QF?d|ceU#DoY4%yRGKUBTINf52F`5S`r!tA7_+-?hfL z+|>+!o%-v}p|aJb46VD2e0EUo^=tlp8d71TY)A%12yvGe%Q9eHpP67e=)8i;c_CD% zX{VrO0=bARnarqrL`otem6P7K)=uXJ4JIQZk4(~ySzq*BuwinK@aJx!XH5L=gAZgR z4bvuBd1jhhfv)o~BKdLw+ToFdW3{i1Eb8J-#xyT!$rZJ%{^875N zzsrfEJ@RVf&z_+#c3?|N7+W;ZlM59e3DG$n85i7t{xgW2=OSVl$`PiZxK*9N)Lez4 z`&l0@?BmtF61U-;gTGcyv2*|6QlU$61^fi@*SmesiZ*2ud{axT`W;KBS(>UhnbTe1 z!Ypi;9R^`W8~ns=$1m}*2;}iEV0mQD0}UksD05)NROADWlcRoHS-9bTcOMP{rh8+G{4 zMYU-a0U=k%xZc~>mBRSX@H9MTy4cfDl+B+>H5cb(GhVi3Ap6u#Em>ewVL&N6Ozu_o zpwuIce7(0zYCydh?OX0Wy@S`yaB<=o`4@z!)+zw}ZC30R5$Rg&RXU0FQKfhBPCf%N zE4FEN2_*ETB8@wpUu~ET-K^@UL{;27Ii8rSD91ZRo<+VTfFs@?OaI^)0K7N{9Qf#q z&3BIYF{^}BC`U<5-hGCr;POL z7QY~Zs+l5cdoI-t%0T^ww=YinH!IVzZ$w^E(vl@yUY&|xbP1@zL)(}{q$S3fsf z2v1MPING0JB2wwRq8VL#g%;triJ_N7}?L#!3KTd z?N_^w-@S4c=oZiBGs_?rgvKtpr;wiq$};iw!M5t|EX91x^H%#q!I_jRn+2 z0{o98vT9~zgxY;n|JLAm_*#qGDmg^^e?RL9e>joMkdi{%=!{4Y_syk?=U((BoPR_`Jh){l0 z*jLva--~_cj0&|n-oWN;Bn`NmnNgIm4FOkykn_={f$#$eNi!>isJgVb5R+OdKcps) zEdXAic!+cV3- zz1%^Vy2bt45;0}~`@OGix+zJRy)Sjis0H==t_@tN)&I#KfrF9JRB89PBl`f-0&QmC z3Uxi0y+8^Qi8zmWWQnbWDXF6alhyZeFbH5-elLim>Tuk8dq5ws-QVzWF7-sJX`QK= zB{b%x@>~QdA_U8@1yTjLuqkW7lh}9^t&3joWrV8T6*YVpOn<@ECIdD3mlw2!R?d89WT|_}5qezAb{9*p| z0%Eq!yyv<2M6vb~o`pb|dbLo1RrC_1LD#YwnFi+;DD+LVy_RzZFBsf zm5rbz{nY8YNf)OsX!hKo3i!oR*hi~KD$0e$yS^_iCG?f+J2>vcbz&^PJU5KG6eT0o z(VjMcqrX+i#1D}2lW#HZ7TPw;I8=iO2Kg}nO9SKBTpVg{4p2J+T0Q}NYLYkS|80rC zkOjttgzyrY3lsx9(RfkXLK8u>A_N(8%4GYTH)uvg+-nwrYWLTMoQWO8-vzp@%9tCB zV$qiE%<(0p*SP;^Us8PSIewnf?z@|SE- zZR3D>Uy}LX-Wfue6|lUn??;a!swwLtg&}blv2%uV#;UGjPDWIx`|^UAD{v90Ak?p` z_Yl8GdKZ8uVGZ9)0O|33CHg@(Ln_L( zwbi$CH>IdOOCZFTA`%z?OE-@i8X)#;fA<07eZo_;xW@PR>!aeKeXJx{5;gb|<9wZj z8X;e)7BFHel18w9o+_!v$&9oJSuT%h$rP?|A6xuC|CxLkpLI;>~k4V zA!7YIfVxRUD^GfoI4uIM=@%l!FZ{DLc+iOWGy)MAh~`{-z*Vu{K0@~AO z`r~>=YU~0C2-O3n#!U6P#|4Cw0A@|5`~FS$8EZ>GtPiwZ$&L2@1zhehiqwh_7XwLz zkNdOX;qCyd`%d!W{-1cZU!qoyjI7u7yfiM-SIhredBvymNa>%`2@7plD{t~3 zMB<-VzvDB~W8~1+`L|?`VaE1_m~lc4v_Qio*kE_%RbGn`c1#gsG9Z19Pfc+dQa>Y?qPg(|=`eFe) zl4_g4#+4%vlrc|DW7WiQYL6QUrVf^<-UIB=&Z94kcqah>>z?xjsh0#TjwCc1gjdc3 z2_yZs`_^v&_#Fu3318E(%fK+_Uj7+!5UgV2Pv%nj+;XySO^}_CYdK?ESY&f8f)KtU za5vmy6afxKltB9emXW_h@*F`$9SpbqnLnmgh6KsfIc1=95&~2abY5Od;Zd)CoB(up zeTu99J)e)HTST9$7eu}}NTN?a5>j9%QHx2Q(X7`huU@lyw)%oab}Wk!yfPvKF#V0= zW3V|WhW`!?AqZUp!iFk3MI6kdn!wTj`f1`N!xi4ltb>u8h zaJu~yob0a*AD=7Em>abu+}ex`0Q8;!7kCULO^1QP!%c40z*-P{0P?HT9RaNYqD+DT z+D1eF!bN&8W9q^pfrw$)pJ^LR(6BOUE3x{wUGe~PAinp^**HQIVT6#>|FS~>9pATc z3fkaOeJ*hHGAR|r{4*RC2r^^x7fb&1>`OurYL)rk-k)0tCB7ujbarzx|U+ z2VQNw;8`Q#Pjm<2@u>chr+){Ag&o|JgtUC~&oEmN;%tHrB~pJ!{aGxy>-TX3et@17 zR1>0g5+Uw&e{K^`i0bhTltYm5MI-wAC7iSN3L6-B1!X)P*cjgQ;f&FAfB&;^i4)6LIy(GqjzLfGSN-x8_=)1yqTCmjKK}D`Ig9YM6nAmih>R>5r-6E{AiTy9%b_qV{ zZ`o@MV8UfRLdHErgGu>-5Ly?sw)Y<*1J5xqHsuCyuuAyPT(~(YxH3ZqOj1D)HM+Mj za8nktn*jt97#TN8*o*(4|2o2T6!Bj!!2i2D{r$Dx&sS(YGmZLp_Mui`%wG~QT6B=I z>8hw#U*4EqQwD@uySbkYP&jaSwer?1*b`K{;D3AUpJ<&VyNt*ph+65O^FQ}G~2x3lfsSvnRW4VgW06oV=-FMVRG~5hVCmG zG#_H_ldCYU@F$(1ete(MS^Z!b=yaaIVF`@ZCqn=K5PE+%f=SRy=Q-tjBGA!tGKJ5L zGYB2}%<7y7+&Bz;%*Zzs)PFzp{ISUZ_-i=v{%r_)f^Z+s;U9^hv#r35(iB`SoPxpm zl&wqJ{}(B^YDi5ipDyxA4(u=mf5&J!G7!kz8aIqs-6#BBAm*dYdqT2BwS2LV09ic2 z0b8iOYztaw%J$=jM=@dlE_wK+A%Pow<5Zv8BTV+5FdgJ%UCz;gO2wMuo96PM;}o2W z&LRpF32*n8K|yO2e0HI;`lR`%jh~5jBf!h?Xk7)l60Z8S6kyJRq;&wIAR2v6GU7#k z{@5+v@3xr5$x*pAmXCB_f9>|rzioN&=$&2gqV1$hRQc$g2M_#b!fZK1!*_)DKepz- zruZP`t|@KfcJIi;QN79AeC%fDu5<6(o7|JHs}!!SWu@=OS22Ruu8r?8r-$^JnbKby z=E7)E5n4`i@x31w1V1-<@C|et`^_0OoV#t3`;#;3)j7d?BeN%S{FB@DM>raW*_&?_ zw;tB*bVSo^Bqmfa6gp(Kyj@d^!B@O>uAkNXTz(;!EGEa{3)}n$UN%zvbKK*Lsb(7~!n|ItJpK+NIa?uzRFgq{+w#$RkHPvZu#{v zHyFRS-y!Zjv7GJUP=EYWV$$PjfM-vT{Kii9W-Xj@^M>vD*Yzv*Va~;OIVPmGsBKx%E==|iJrvaHL#gSt~?$5m{dHBq}o+c&Szy1;o9>lDU&?Aq|E zX8CsDuM1=3pDwh{1>;0@I@uY|S#RD=eY-ca1gnGw>Quau#MUy{hst1!R+m@miYH6@ zPron;{_M3>2W)Y`8^0Aaa2>)zuzDkP@($=PU&zo}hIi&s9Pk8PvhYh0m%X03U7b#`M47Bq#C*5KOzlh)?{z^8 zdn^q`v_kFnqJ6kh|KiWs-(GL)ab4R!+uj{rP)YuLcK6u)z^Z$4zZtD%8Iu+9okmf{ zk7a(9&kYoptEv4`;oLnI58U`@rt`X@^^xO-;<#vkYy$DMS-<*-FHep(cr;e}2Onil zIaFx+W_s4F+^?H&be~XHvU35{=`veEpLh8^e$~%fsJ33=o>;y&uv|zAEQ^AdikP;~ zU>kS4O7Ib(U`wJV@z+)r6*P%_38Q@zXw?Wo@R+(XsJq`4x-wFszwEFuyvF`NVAXe8Db`p4!RaY zLk@?Jm^%8mF+RG@Cnc{sgELMO!>12VF7uyCPr-WBgj!`fuHD*Mdu506(KuNU581B! zu+iR|PnRE}e7%|7#!^jb!TYMCC4Qx!gCT`CHGg~b2!3ZRmqDZ2dXtN%girsW_f+5A zjlh?Ncf%T9dwwY?p;|`h<%z~s9lE?9zP*xJ%GtJa!t@tGw=V`QH!u0B;0-q>=r2># zqKF&CSxpvP^%u5ZvGYI_95302@4n*p{|Gy}^*a(~cg=IUW1`l>>u9|tiaTue!euN| z-f7sfL{s=u`u>pP(~h6??{Spgba3lU(eIx;PiprRx9Y-Rcq#psUGaPX zLXwzTN>hHE?b*8bu&z^4-7{(AJZ_6#RUMn=eKXXXGXIXY{(L%%)g7jUG$YMZF;w8^ zfeM`_MRLp60b7W|qD}S^a(F7RCz)Q+04t9=5}eiA4pMHy&xG{TD5ts0%v~N2ZJyN- zgCvGodvgpLcIBn5{15itGOo(5dlywiK#&j-q(QnBrBj-PQc8DAOG`_)z@nsEM7p~{ z8U&Hf<7!`0` z72Ur0x{%r)`f+Y<5VR_Fm>10EniWJ;86qrECNK$7tx$JfQiKMz9eVPdoy!OCv-w&y z94re^GBe|Ay2;W{Nqg4zXuDs_ZoS;!r?Gl06Aa&6joT$!@@Cz9$P2C;+@S_{P%5A^ zsrYFd&~2eou){*_+82xnvVBA|?{+e`TN!n0Um@VK#xZJFhH2TpG&ue!N6R97+9L*Y zTyHB|?7?#5Ex9b(N!3Na@##>G&N$W;sri`Zr{I(EPYsNVUrZ>q8X7LoFin^%r|o?{ zeoq=U&fKy5_1VL*|9;N+Hu>84tYq>NelBZ4=Wv0`ks}$f(SEb`F2`@bfG&mD z@##wg7#WF^O^Y6auc)qhR4Y%W`mM!$OO9{bY2cSpmP9{|+Q}+Q(x1&d5%*-dg-En> zwCd?T#o*9Y>9{u{xSdjV*w1}Gen*treZlaiZCvEWrY}FgR~i)#z58{YDK4{)0`u)Z z28;M_vp&8X_pPG!cQiq8cV6Buw150f;K$^1ySI5%U>X%;xg`)@Oog(i;Lt{(Z&{#y z&u4z4vW5500GnLztF?Yu^fJkCIp)prk!B+2R>=N^$($^@r^n?Es?5mQT#lJxMeG*y z!4@k^oxkVRo{Cm>CQH-wZQ%gxbl=E3Mi3jyS)t`D8kkq^d)1^RgXL^D3LgJGl1tiD zN!kUm5lQ4%R^^&ca^?Q$IGo^cV-hiI#PIpvz3pS!(qQ$+uaO_#?P> zltsp6MuVZ9pjNi#JI(y*`3HjVFoV`6&#xy2`#(Qc3nePXT^RkAYup4C$51OPGI1ws z?<^-5#P)Q04R0a?>Xw!&8-{tDJ9zEro+`QIpoW{MPA81WjL=g5@TD_gKRqmi8%O`$ zD+*ah)oIeZesg_^nb`DkRxzwfy~h1qYfFjOUnsF)4aYj4izs>+ni|9}nCj1%Zw`D^IhI$GcT z9kGn8w2ygZ&mi<@*Z+Kb3VXYMP)8jW_)4oJhC?g8fjm+ ze$Q!$q~T0ftZcgbpo-H7f#|=CssaJ4!q6?5Lk(P9niZ3G{ojp2cbfgASGzaZ)n+}d zC)9Vv=~k|vNn5F&cVba7N{r`+Bh5vH++*^4uA=+*Y_VSmzOUI^l@F$M*0yQQLgWab=OA?~nu%s)Rd1&c;h}(sZGR-=+fZ<|8t!6zQR)$p@;V|~{lens z)#+^9lEtp~gx>m8{>$b{ZIdy@L9#yHO zpgghG;5$BWh%P9deJIRW!uZdjc`iE8){%!)0TZd8&OFS=(;|0K~o-?)}3Q&bYt=lip5leG6EL;9-ElUa^_-KY2nA52l2KJQ>e^Fdd_SE zohGT<`RE!Wu^TBS;D(XBb5afR^>|7^mgTi9dvgrnz&;ACANYpm1+2v5tPSXPUtg(Y zv>VG++?_G6GS`y%eyn<*YJc6gXgiK}2V4axM@dP3HJp-q{N2H-BIQKY{fhrYk-xw3 zu>0}pMQG5dNwSvZlmiOhU^DC^HR$&buQ1i1{r&i0xDmmdN3RRAy(l$8h#cVbxilUw z`Rve5j-up%2A7bA+mo%z!^3`y&M>SlYZLKbm+Mt~<>a0Trdt(zR<4$gVvj<<+XsN$ zxwi6mm!GgS@Nl@NopkgvxxtD2C1l5A{&MwBsbRODLOE2wrDJZ}*n9Bht&Mtu!|Sde zTf3ZXahsFbGKO;b2LV�g% zGk>fq4%JY{?v@cIG0EQhs$9oI%}}GTrp&>j#LQGDvq(?##R4N>hTX%K$l16Z7)fF3#Qh z7!K7+Jr6!M;jIt?w(_wYev?#LPp;$9!U>|&KYigeFx$^SR2xh9{bPWfjX)?`|If&WFig2}Oo;R`uV#tDF=V)Hq-uxl)e@B+^ZM8N52^zHcc z{W4LuM8}B%5B2@b2B8z9AUMf9s{;HU&L44pV1_Ap%Rl z^0a<$CmWl*Y(mJLfY+*0-&~^z5lcfO`)%O5Yxc_4txHnGv{ob!CwA1(ZxsqT;6Oon z7Wjdjl>qjj(p;diY7zlI!b@D}-J$=?+p_2nW(6--3xu}`n3D)RDtZoC^55k-6uj## ztW?Zglu6+=X|cGvp2D{12@O*6{-MzJ#KPx`fGBqY0l4Z@K=;4y`v7`xw_tb`t*4$` z!*yeSd{y&grDjLvPUDw?8RtLV6FxTtEb11Cg;UN!f^#?fGKnvaB)5hOvkPX^m1aAs z6yQ#Qe_j**Z7|h0pru&*;b4$+V{2^3r-;_K$+g9GIK5+Xw9?eXyiz~$8ml;A)MNnh zv+-u(<<(&ww&m*dh7t!cb6rxwRAXI1!{)c2b4%dNJRfA|STYsVU^)PcYMGmZ>SVj$ zqN9e{D+O{@725{{a}P4B7mg9zUmL0_fRg$I;aGTaqei}Y-SN%bt}<&_#h{vJSx~BM z+1M^`C($ca&R2->BkQR`x>;Rw`wvD-d)&S192z`vTHh=H1@#_Io)0@%v{E-o00xLp zgGU4dWrIyu&5hTmqKOAfBiSe;`q`DE_8p_6`q`Y7J;5wKD%pBI5PFKqjGZ- z`89KsPIiqY^bVGbHSo;pidv1@M=?JdEgZ+p$ink zN3&%J>ee$t6c;0~<+_jeOf(XAyjP2+=^5RE>^;Ub+PK_Mq zr5To`xAJ^0MV3BN-I6>vhn^ETI_~D!+Je-9xCGRQD+|LjEtl$oa*-uB`?~juHTd9M zgNKo1l6xVk=dZh!y_HkUf9AdubWW6p5lnuztQ&Ljph`{F<#hdlxjx%CYPtTJ@<01S zG43;O#H6Pgk&HI`!YwzQ$S1kV8jCxcm|+tewwOdyu&~6*o?fns7-BBWXMW`T1ekG_ zA25lT39Qc4%hydbsz2$Sw-Ec>Sui=hCbt-n6Bs0S94pPgI*^lsr>qll3%6J^TcmmmWC&nUR|)z!oGIB(}LwsO+@ns@OB>FTuFI z`Ko0%_`9Wz{rLNgMVI!JYUT>jB*E{-D)U|U$xF+ULeir(*Bvh*a?`|usR^_W-o4cT z%f3AF@mWOeRM6E)1?Jc$&ZL9F;eL$d6qUhTxmV7#h0mo!6(1Y-c&zockcww5r$obk zWf;j-td_$tg@)dRj?=x)rlX*lkGC%!5vErtdNI=774+$Yh3-z})+Phxl?56TIs^Rf z4{U(x2PwVJ8UGvi#7m#h$b_!O=~%4RZ*aPw#&P9P}$He zNVG?r1%?uze+lw0^g=Txng93>BbgU;nQ65z-k_JQsU86ofMo)s+yZgiJ2&f+4HB(? zb;t_oqHdMUnvIscwKE?teqDS&T>~xjcOj{jrTVLqD>i}F%IS{|Q-^82+gsM2#Z4&! zaHSbW)<+Meib zsc&^g|IpHGnbRJhXOQC$4Z{l@np?6fa=!hMm)lq59>w_m32J$({Xg1+07XF4A^48fhAC>J~0O#5^;E}3= z?xFFoEkdVxDtDvWEXFi$)GS@SmRY~TmFU9*U>%s`r5e_J9&>Z*RSvup;98yK?>QZd z&YdF-J_}uP*K0o~i@3*yRpDf{U8C#cy!@xj=VulH28Ec<3~Kx_Es_OpKTs73{&bu% zTiSPC5bvd5HU^NaUGus*tRJ1NHR&hxp~I7SA666>$5iD)Sc3kpL9nSF%mUz-5Gg-Y@NVjcGbz|^2K<5Kn!%3v2U3<*wL}r}- zfr&bWhQaLlq({Pu=(ljg_j?O;sg=2NZts+;hHQH$GCD#4iY%#Cq)jXnZRnf9_yhwa zJ{J|f!1@kY)<(hB(L`-RBF^`FNPsdUM$2U*8yvt$4b?CmD@=AroD^|=rI4ru;^NSy zHOnxL(PB4W>xSzAy3^HVHg8nq!#$(JXw#Od7EDcFqmGQ_zAedd*HpJBt$DFpr(=nw zg4frHIHgZQ;6ZJy#jAPwhC=en&4z20Z6C9-L0LGbo|1z2p!UY^~CE zzp|V$s$XyqX7I zyc9r)qz1YyIPZg9DG^4*LMh>f20YhENO0C)(=q%lkw&c{J11weWk#`D z-(aEVX+TPwJ)Du?0W@eF|C>RZ2!`LihvGY1*l;>IPbeJ=;^o;#d(DcPu=8GpO0!<2 z?WuU7$?U4zDY8#yBHUvovzt4ul!q)_ssg?$i2bGd`6rb1!AHc??Hu!2#FjoBQ>cUO zojS7E3mUAjubqFKgpBBP5T6BH`b$Rb+WxdTv`K2Zsl?DNe-)ZDNR_+tcrfTsZgD2M z=j)_2hJwIRcig}4ue`#p6g`_|`Xm9*9v1Jet`e%m2d1!< zUuhUfl~T)=Gg#hV>xf198PC_a4W(E8>_k}uT@r3Rka$~WS@JsWWA9X}c!=mz-EY~A zQ31xh1NyljZtBSVZ^skRD>$M}z*G(?0Z;ah=fGTBftohONmZ(6#Ll#9+kRfJ)ooR> zLz|D|P{hnmlBm;zHCadg)5#x~0$l2CWR13g6&IeT1IW`oxgkp-zjT$Q6@S7W(4;@~ zJE!-f@BfCvF5@2|&u%Cc3ocyreFB#8GLeWuBQx9CpC5ZDgwwNNKT%5sDA5LlmDnJZT-vT$98QQ zU+Tz>za*y&&=e-or@>yC?bJ?L7!W(zbknEg>Qp`K|FahsouynV0aFaIW*xK2qK?Zp zH+YGRD@>uSh?|%DJ`#6wCGE;7&m$IGLKLZFRO(TC<86fS4^uSjWx>FziZXm8UN91? zfrhU4Risn`t2T-&tNOvCkRLv6m#!7-4QjJ7&)t`ZsA%*eVb{EK;=km2E+)o$SDGuU zs!`NQ?Bu;pwr9edZ1C$guuq~5uyPfC-R;8I^`pDUJo)!5K-6xNn5@}*lb0&Z87@S$ z&h&*oGuE!^jXDj=U71U%4KNbF?fe!g=|$T_z`8L4uIesIynm`Vyw)Q)T>Flgr+BuB zSTdJ>>sFJkK+b~739ISd>8ul*=~#YpUusoaTJGVKp57U3%xIJ_qUyofgu__P@e;}O zLK64uA={(oM#Ws)C}^IG0dLH z3gL*Br~HJG1+N%gPTwD18TAykIolZ(vDzN)t9dRVLx%3$7m(`Ob@v#s z4D>v1OO3E5V2$mR6r#<&h#gyWT`t)(dA=WV4P#rlqca zq#G2iPK^eLR3qz)~w>1dTR4c zl-op|XZbc!Qe2HqG~M|em*Oc+R=sxD*>qBd9dWX8IQ@9Ad&z)|?c8Hk<7M`o17c-m zgRNUxLww-YFpK)&0{n1(s{YnrSoWE27WGxTSr)ZBdx#k9Ti=a{x)uUlZR1A!nOC-2 z^L&tc<^5P;Zd*~r645pr(Mg#6NWkbUla=CP6qe_*$DzC+ogqh|mjS9aebgMHzH2%C z>V59Il=RlOla+6UIn_tcOW*i>nW{-3NzLMz7&Sd z1P6p=L-us#O4d&Ij^QtZGwGNgO3T5lDpGl;1QRt--+vwJxgy+s z@s%Q6F#f*ugPtqrD*g@4loaw`N{-`|q0_h1iR>FQgUgvFRuMkt@1I~^X%-oCthM@W zjlO$q%rmTb>ba1+R1&@ZAp}MSGkjhUwQei-Hc83w@E7lua^$_qV+SBowc?p8cCq- z`g$^H{9CiTOaZMRgIfK^5__|Wn$OXiLnp9YcX>;d!Ja+kp71=+=p&aTrZ^qXni}gT zo(aB-af{O>a1owmc+_s5KJuYx~ z)}sAw#RIrU@OQavPQ>dn-UMKNc%r4Ix7+vQ4UXCI7*}d0vyBpYLIffk(8UBUY9wT5} z@~yi9Z`HOYHG|su9}%9lV>?oY_>)oQwZ@b2^-gqfpiw=6!;CdE=SwUC`#a$yZtzSK zL4}Y=__CfU2O$!V-{(m9_T!vL_;EM06pVs+>>(Kyxqw~f`%_$JZN5*Tp-I;%eXi+6 z9}5j8dN>p-E-DmVQ+sx&QKb11{B$^hG)x}0g~}z-i09p+lr#yF0qYu>b6+(K59Oz; z++?K7?;$)6e;uc%B*lVo^(8ZfVWQf`;4a}pGhkiarqCOVwy#-s%XQE#5J@H!a;dN1 z9|<{J#|ZEG`IdNPujwY1O%NfnNv5t+IqAYw^TU-b_ubhYLN2qUX^v~wiK^Ac;Vo}% z+x>J@nJK%;9-YJ+T+QZKHZ9f)?0nLrHxFXtf(+YEk`7;Y-B_$UYl9d|TN{Dmw3#sz8}$08#VSyF|U<=(LfTN z+_Zh=yqVJb!(U;EH;iJi4?@cSqf4lUs=mo4GXm0M2h?dwD)rU~ToEL4+fVM2&pEBe z*R5EzzLoPa*`98!b-gPJjYz04?_pwVe0I;eQA6AHR*B(VW$4HKdYQz+QtL2xqdwxy znT4aZR5xuh^3&?jr02upcd0T)*~~p7>-^^!ayWPj}Np`PCW*RNlJ&$_e4?B)Xe8!{G23e*4R$`@>mRGXuOw-DU2En^!s#Z^?cbZpC}7)!99dR_zx3 z9pGZC&JL#6FUt(MN_onZ?6}wrLCd!HUwqQE+OQu0G?^9+0v6?o>qo+>OI z0lzO3+oRGOyN35=gY3M%+OH-f@Rb z&I-Ik=RHuON5mjqAPmMCe@?S-MoOAhX6&ai8ue!oJdm4vqcp;zmxI#mEWU#EE0a7G zO>PHQoH>^wymz>wgb?Wg1@N)E`-jWQR5Z@d)=7xJMZ!nWM?eJ+`d2^&mrLy}E&PR% z&_E;Z)brQ;k&;e9c-GEH(~>OK|C1QXv@4P}HP2uE3Xvq|6i)v^p*t}hhJda!uBf-s*Q zJ^I>oO^~Zl_O1MbVv}kzsgUKD>k1Dh)6w<7>Rocr*K|CHFdmzks4xPy8=J<^ug>Ay zs)gRK1k&6&u_y}#;+a)CM*Mf*vyy{5J)sj1@)teHsb^aevZUVd|HAd zg~AZuw9cotzvEPrP`ZcdmGw;CplBw0b+(QmPnL?NM6b@l&B;k&385kFw{sTgE*h&{ zaye$ij_7?+c*d1-s2ls`nO&`A7PXzBp1=!ac4$RUNb@Ch`wehs39LR|BQ!iO;B(`@ zMYXCc87snG75si(Ib(b^&Sf<5q{;eR>6;s;A}6AvMY9S{%|}HejWqn@1+pzBD5r*Y zXgR!7O8W3c1<^}#@WO)O@%2@kVM|YV_B1D-R2xyhQBLWTwwbT@RS?&mjPW(P-uYAe zAtT@Ii*&08qvW@^AY`=Oy;%F{a0oQV z3=iaVYKYBLctp&0JXEU_U!MP9Yjl-cWl3Fesa|9Kll|6*OwoADmT-D$dm{lXK_X*L zMsTEQ_JEeCGMxOMJ09Kqp?^tjV{9(1rLAXv=y-``R zgRkwIuybdhAv`01CH|r17 zt~%v*jRz7&#&>XXmD80aQn?nUyWoFxy1bv*%}hM%`C{Z0`EDzP$~Cr#Pzc9SG7^NR zk_Y-|PmvxydakJd7~FD^fay~j&aFKIe+08Bb#)(KETL=GCc$+Iy|Y;L>+B!HRlUj6q!Znf`y8SmRR13IJn* z4h@O!S&-C5K@Y5dW)n8^12Zf%OB44Q=+Zl-9C~PmRNyhC3T7KSWnj6tXjx!{0$zYK zp$2xxF$qqFrhQ<7y>Ue7=(m#gDo0pWGHU$_$_T{p747wZyJfUPeyc9%ac-1*wc}Yd z#_(vuv#Rz>gsL<-C}TLFqQVf(@Cj5tOp|6<4YG|o4)siGFl|I-M-jUF zM7tpnxVbe>n_A552JNF5qQZtZ87rkaD`vy_Lyv4)Ufg)g+FladE!K9j;Iot`y zn6^giy$stzPaBG8i!5Fw35*@qh_h?=DOI^3+N~m09?T~MhEcYx*8m(11(+EjRdDD| zmp6^fN}kcJQ+U_-7xm7EUer|b?%|AzAV)>F8rRRFW>$36YJ^sbIyBZxoXGlMZfpM* zNU00#qFb~XxL0v`g6(5aTn&Q?aSUa|bI>Qa{=XQXBR{+=nsx`g!AbbgD+4m2m+d&u zk)MIG+G+j&4-05!rr|_==oJC_^}&N^En~E0Vo?6!+eJ=o5QwB`kibfXrdHXB6;z9w zAnSv{b7VzmlE(XNrbL9~FFXs?+*;iF9(E9TH9~m8$X~dT61+A?ZMDRK{Lt$?^nsXl z^_d#zYnl-mVJ$dPcfm6h@BC0Q1&wqL0k79TX~5*C2Cs@B8O0GIUHA(#N=Y~BeSnI% zE7~mC%w9X?_8d6_j9|NQ0BD<-7{x?ZyDsP7w?V7HrznWP_bsfRBKbqn^Pd0bzg+-+ z$!CDpF({lD*oactJ$f!9z1s8B#TY#L??;xQui3uM;3N~JkcP|)H$pk=->>STwTpo< zcoVpdBuXI!`WT*STctq!&o`eU(LfOZE<7{&3b_;-2{j7pt&D%a8$kt1>wffl^7%tA zL&)?d0@dCBTPqwWhH`R26^H!YLjOPY0l$Q6p;Z@aRspFfMKAQH5mMPM=mWtCctPPtQW%c7qB7L-5cm5HzbKNbkQ-+zR2xz0 z_|S_Pve?)MeYNKQzHRsd)TdPS)2M?eMGVxvz?!Q5?IK;YbEvQj$k_i0f^GkO;xLp+ z+EZHYJVjCiLkeep{MBLX-?zK;L46EM_Vc%ZsX*fbvoEj$7W<#p?nCZy)B^tfpYHIt z1G6wdJ2yloCto0!K7^V~`+TeL-wH)^Kx3xApf-m2U(5aPn9W1>x9S5vEe6aY=CBmzvYR74l*RD-mgYjKNwfv@Bfk&0Mju z&Hv$P&|J?+{(lYk|I~2%aK|rCwv0B0vr9i6=$|E~+OG6;d*8=k&&wPo1|vfM2pJI6 zQ34)~s2@ssunMz3)7YMI0P7UHGzcR?I)EamcKf!AD1{sp3<$k%mcoS$m%Adth3{0U z7)B*@4{-Au`>g88-{HmcTIr4J1>oTHpwpZ?-L)s+sD$OnCT9U486}!BVh9@V4+pAi z553@!yLRgpu`~gKS$4A#`i;?o#BIQyPBTZj#kQ6Bdp9LO3<{~w~yTxn@M2ALC z=6I8YpfbqSrlc^vszIG_2{fe}&H*_kT(8Z)8?Zz$Sx!~HHJee62W5c8$RPhw=se0~ zrX==+ehACqV`O3n3CMIaI}DOvBEztNLDBdK2rj5-Im9G6%{nXAIqtwWd@IaAT;K_6 z2IPmd;X*gnfaYF6vC?89i6j$~(G_y3hSIVWVk8D}&&?#s zanK!I#K?d%1V$+6R;~8tP-1c71;{2RDCxGcDI**q*CMqglC&?%97yb#wY4>MeRtpw|2`X#s9Le&NO_rGzbJj@0nEMb-r$_uQP}%@)fa_4kCiKLsu$y<^tQt7lZEKc zfGn%G%vSjD}W*7 zao_`w)dPIIW+1LM#n4>k?wjW!S|D$v|J)9nKCRvH$hj7Vw;6_*!+t zX=E4HLgjevI-q?Tv?&)rsN4mPd(2N?%EwY-0^X3QEexo4Is82l5Z$VeSNY?GoHUN0nEelHGtK488G!SPzaRlhpoAKYHlccAb4tS zZ?5WghrO*-!1rb1op{BR?bw&r)&qo$$nE%(Z30yN6iTY#^ZX{9G7>h^j~=uxMP03d4qF*OuGQXC~G z#@++Mo2GjxCe33SMY|fYO(uia7wxwD?T_WUN;=85qV4t%FqT)qpLWzeDqkmFdjjiD zIt*sVumbGY-?xO2y*w#2pd+kyC4%0Sb+Zy@d7*_@{iVD4TwZ2cO^RO8;<#uh2{03U<-9!^fu1 z2)j{FwM&Mc3LuaW@h$$2>M)SRvm38gW*kOUUVa3aHwjuD0dY{w#_t@y3&oLVXP`vB zt+(~#wB;WIyVi#?LG2iA0W~d+dd!S98nrJ7Qoi$LiI`r~P*8O-3{fm!OL65jVvQ`d z-xwAd4Pt9NZ)G?(EBJKO&*fLfL@z)eMjy1Dktvq0DF~>fc3(!n!P^5qs8ZN;<8nrd z&f3Gw_e0YMkko{TBi|1tHNj_C`R7rQp5Pqd=ugwuiq0v>jS1 zBcCW`a5N2jNt%tY4?F4=yfYl$HSINW00O1-B28@5We+^3%l!NI1rqA#T=xV5IG&0= z1k~9Bfwo~{ux1qVM^9f`qdt5(A85(E?Z%{3zJ^C29LP8L&|r-W&mHYs_zu|hU0mfD zd;Rr-n1J`PjUb7IG-#M9V~faI~hRp%1VWOq@1u+ZyA)JEYr*-PI*+$W+(QhA>XlzW zIoa0FHlP%%yKU23oOJOr;NPFBj5vs>j7Q=O%Bz)4}U0CvZ%43URC|3NLIi;kYqW zYtqGd-q@p0x)hkV!Ny4!-GbR3>g0K`&d zQ!U~)h9>wc5y_t%3=}&E%`vl(nb3ln>*{Xq>TR}ngzPCGSENaaQ_*aH`pwz%id9*a zZ6uk2+gRx#C7VY}&u7IzzS!ER0|CA*dfSMvQtm6lFN2>g<@_>XenGN%5~C9BzB#;A zZdvRDROTtHHi>c^UeI=tQtNg_P!?h>e=ZGi2;hv~|BPK7(14}rtr)`p(P6ljA`<6K zz8DU3Mev8z$QKt@#S#m(+34JJ@8$q&`Z}xlYe~Xyw>ZRx--Ee!O?8PZ>qA8gxL`2v z(sp>3Z|q)#WrRg;66F9;g`G4;EpU(HkKxKP9L-ld{4FQ+M71)bn?nlrvGX25)5l_R z?|YPt=ylJtkSBCIyqOhMMJMj)-mD`cTr_L1FMbTNvfmH+RPxq-XWnC#*yMXY$hV;+ z2QD@@$%)JkrK=l{ud4c zH!kjJ8ly#pWQ1Q~h@synz(BLoR7HA5YHvbE^vtW`j-pq#aHiz_&itWvtLg<5lSi++ zH5%P&%5ZUNV`rSAT^!F!M(3@(MS>F5vl>OxTIq|Dh`qjEz_{I)JRRq4TD*%t(u!z> zjwpH`_TROO=G_;=di|_rw;B%rROlmij*Qw7d&D;q@Z`R2=LPcQJ9zfdXVR+&k7>Ct zK9klh%%d_)0d*Jjv`!afe>2iH5$``pTax7m8SnEJ`$zy^X3|&GF7)2c-MT&PE>b2b z*!sO#VrEWVH0jedzf&&yy+t_g>SOnx=I6 zRe#h=)}Iw2dO+K3mt*y%3#-QF3$ltB`trjnJ~YlbaAY*Y9QDlSE_<;)S~LX3z;NBo zrvTmV-&GNJE;Wru7Ny&o4WR--E+F};Bh`qeMMDelP@q>zm!K3s_<0h1?>7!{G!qbb zwDqC6ZxqZcpCv1VIQ~9VWgkE!9+T{@>BQ~Y!t+=l3v+T4=D+AKgBQ%jH&u@LNN

*+C=tzxRK^$2yy)hl?2*N_Yidruu#RT( z0}_eup0REt;X@^{45Tot-WOC~fBUg(m%tL(;Oyja0{4a;wR4p&N1-4*sKg(ESdu52 zm0B(9Hn}yj?|0*L5_W#nbP`g5yufB9uGxDHd1rfkY4Wh=5;M`LL!Zn5B<(i{&7IGZ z;PK_^+~4a-5@e&1DkIoGlok4&ol@r+Qc%`tPLF;4v)_B+RULnKXVi+WC%y(sa_$=v zV29m2B%@0}+9Pfs&-;z}zWNc8OP@%*Kwr%8&$QXqT8*iW>u-VI?;9CGOW9c4|Kv&x z%1M6Y!JRZoB;#dt9c(u^A*jR$_a}-WTvtBKaXD`vM>9-Y5BqWcGG=Xmc}!slICnO zBh2o|2(~I@rBr+mnAW76|5_3s5a?wAneg8Afr2>i0S|whr2LIN7k&mh+n9>p zF8sT2HoL6z!;@Cp?758KVWq#Kd6j?Ws3_f9pzA{cz+$BFzP3HvQZT^5+!6UNxzUFC z%LDkCzY>ZHS<)O>;sj~A;#^5+>hrpB%Ah5JV7hOQ@=Y*+@2IW8y`q(zgC9m~rSSq$mE_D-$ghJwW+3p@C;ooq$NeJD?Hn^KiHRTf*YA zYm=6@R^ZX*5oAKixfoeOah{ zKakfAnu7E9ZRZ3=3Qp4{`81+P=11SV%2AJ?@V=_}>MZK$p7v!}e6)~&tUeS9#VfS8 zR`xtf;R|iEFGV@V4MukTX$7BUvK613r|A_O#)0bK1Hpf8)pc0jAX)uaJTTrIRQqbo zn*tV@zXj(P^pX{yVH!Y?55_p_hoqOAehB+R0-*qG0P4PpH^1n#@lg6b38K;0j#lobKBU%?k-62xhZp#_7vK?$e(0GKR2%LjSLyIX^LsRJ)(;^ zczfWX$$LfOq#V%~nAUQk^W*&e9f->@;klLQt4P>4l?{vKKB4J)Zf?&zTo7K^?XUJ^ z5c}&%up=4)3J}a;W$4zxO&8^mm%Gi`2dL0ab#nuqEGmB+n|u$8FW8}m{dpMl@(J@A zc$IYUx$fQVd8NX7yLy|%-E}S7MDS>s^!QK}{}gcWQi^GU5sOMU3GPTaRtJfh{#UMf zD}Aipm`n{)Hz&@IY0IGdr)gF8x9O&gNh&A1`cf+mU7R5;olRDm0s6~Z4Lr08v=NQe4W4cQ8Shr5L zm~J>&bK|a0Xv2Kj*1xkV1$E$Fy_2zrU_g|>8+e>=0EEo_vfM({lg~wS`?W;n>hOw{ zo~NysdRi?2`kUw;FHvvOthh-M3Qf{R&=vzB$6PuNyU-b`W6=K@5?Sqr}~^dn4e4@qF3*Y4> zvLQg8?ICqp>{)^H#L?57d>v)Sh z^`*(*AI{agIk$i_(HMGWuDO`%M$9K{Q3cwyI0a`8=r??T-=C_2`|4jG)w5{wYPy7k zhnmsu!c4~xGr!@Otb2GD8unIVL_{f^bpm=XJ`?M|OJzb&e#m_{t+*4`%41)RTbut!R z;n2uO_oZL-yFJA!_qjE`jI#lT(u-imZMc(YhwYgLu` zbvMiMrY!C{QzK)3EkLsLJwYoiMYJsC0pF#=`WvOgBZ>KWMQa2y*LWV$X-w|RkOM*Y z{kx%%acj?U)!jCr=eC9&v=_n&?C1v~>h_pf{=W60%7@Rj8>_3iri6BTNYwh50E<3W zO7*QhfT~s@^;5LdHMwq&vjl;fvo#x}y~L3~&uiZK1rJMTagQy{D{ZLS1E5s5I6t^X zO|CK%kLUAWI`x2|2+DSS`QpN5eZt!skp*Zz;kPfN>QO1+@_9$P>`??d9Ht~m)c_jj z_xS)6_QKZ{aWQ`%(!I9U^xBTwGX27KUm+ike9{&Gd~&IkPVu5}-&uh zO)m&4ghAz_HeW4~Ca5O?Oi4QA8pb?G3C^vUC0?TTGU#(JlH6?LeCo2;FHQN-oX#_3 z8F`465a6u8h$=i5<-<*{I(7iNsWSJt-^>7N%z#PSwUpm}SCk7sdyv{OzxT&W2ljI% zXRrN@0ff9)_>f#|=IP=H@qE`mM(C^Y>Pg{&`V=MHuKp^X`CfCXP^X~w3k%7ImaWVI zmJpOq2U&2FJ%h=EFlSl9!|tF?J}A$%*X&tV85$4!ExNk;Q4!=`&L`5(%>v=G1X&nB z!%|M}+b4Whn|>~xE^(5B|GcEIiaxFv|wn?vn=@}2|fH;;hi41&}_N7=Gy`01#c9{hDLSugVj{&yM zw)hUpi#pFhyFNenKVxMG8@0dJss&)mksOmPOn8 zGJ!lX@3E+dfI-_0EM>#=8(c*kZkbAP5Rbf^4_;*75~rU#vZ$vWcqji_C~9;pOjK5R%#5 z&8H=GUTP=ne8(LV)kmj<@grC!W!Gg9+x*pX>yim4&(RQ z+H03q2->ue^lcc`{MJbjROlB(GR5v_8~7ADc5y#%zeoAfxA`Uh{v5=}R6w=&GeF5q zD<9>1@lQwhch0+lQ!`)5zRT+l4%S6$%Mnn$J4(stj4)0t4UfC${k#t{d_ZckEfVV) z4aafvEgt*o244~y&v5Rg(&UqGX4oY)rl*x=^`Ae;Zc{%+W8ns@SkSxrSzDtgr}*db zds?R+;9!i^!!`A5`+`1hE(zx8BmAoQo(zZ$UMt>v4X%g6L3^^>r(KHaq~_0a0p}t7 z_J`wnDdUWS-p9!=-VvK^N&;61{{nJ9c3%wGBlCKlVPWNO^PUJl;0k|&A17wzWgp%9 zS2%o#7b&x`u(&{a+Y8#AuS8DkeKGfIkmrlC_`rS6RMr!uqUCv zC{n09{iA395e6zG)ghbhzSm7PoW1)53wP!6(e zturAIxA|+Dd6yU9s0ZUX(_v4dN7Qb;26=6oV$Kg3u|rt{R7xN$;F_5Im@j{FH*3x* zm>3>QdYLZouCy(dtiZ?0%YKnkkVFuXo#2{l^_u;0b<6_Q=c$`5f6YNviQk(+!2y5+ zsfO0_>GbFJ(0$bT(AO_PQ!2>7^zWa6g!|8cmjnCg7lcRuArz>PU2XHw21(bkmI8wfQcsj6C-cdU zyFH(}MVj}>XgqjwHO%02QD@HeXZ)5ro59*qU}y(l_1DD1@V!%^AI6oG&w&9jIva7u zD4Twoj^8P4l@zhb=DZ=W{kZCDl+%eJu`im4tbqE;5zrq3N3FQ9ule;5`b!W=%H9!?>eo$rf5dn*uL>3&mGBGNlab%lTsYRLrl* zxQNSGj&P*98x+WS)fj&=!`TQs)h43%>5y{$2a782K_n6=8W3*%fYSsF#A*J96NzX{ zu}w7S?aJBxI?3pqwIN}2@Uwb)H1SUB@;uRvYY(#Uf~(6ZWacE1eE)Ed_j(7y3i=2)*6SnvR|iVp{y63`^&c{vb{V;IiS8lj?^({DXM9=91SSs2T$5c@&fNxAMnPG?B^A_%k^dJyh9{p6wNu8 zd+^>408lepT;eEk3JJ?GeQ=`AzhF*Ub~?vm7z4x||=e_Iqq8 z0dh^JoA~>yYj&XXe4&!wbEOjR3_8hn5yl@V%}D|Qt6#}oZ_sai{3QPJQSv5Sw-()` z2>wyZwBeht&|8xUp1xN7J~(J||2XIkh+crD#X4;kv)tUlA>uY^LT!IIjp{|?z|%P>#55=t|X zxw7M#)b6{UQ1}9;Fp=7dXcHoBWAe0KCG-zRR=xwK>vAx?No70UFJbk^FG#8DW#5en zt8FGz%N%a~WRS<^>$4@XPo`-0$Y1u8X^#`(nR<-FMz!wuc<*4UU*S^bO!5ux&g*=t zW%(yJCBQU+eA?%AXjBvzfa54Z!!O1S^0NRjn;7Oq3GN)C1^lq4`WbdWo>A1a!he-p`h02v;&$SS|=3HaL~TwuY#trwLta}Bu&^v_{J2n}X%f}!8L*rR$j+H1Vcj3NN`_$lz*cg^v?>P_l zSML;%WhM&Dn3}8W^MeB7v*#lqQ-6U4F{h&wwt@-$qZM-?|&HB=B>%8=r$ck>V-6T$eJWsEhH9<;dNbxH=Pu z`mt@c_$k~=o&rI;fdS@=9*Lrrh$1PhlvGtaL=JGj6si$N=@}>kJH_y}ihYm<4p!CM z(S}?H2D_2>X)Hh0xqEN)_1crKBl^Az{jv3w>fKi?J6kk+&=d~yx7Qs|Evc0OCP>v! z_rs6;m~WxC^a-g>36?(ox|hAp7uYJ_yzORqE0l<1OO|%m_I=9L#jk@e-|9&hZa=-` zNO(X&U0_Ie8ClUTmO2>D&GoBImfw~41L}2!VL_UYqF||nTzNcw_pQz!LihY>j1`*H ztvCng-&LV2{%n5g1%gwEr0WA!?V;T`aKUi0qpq0@j6Q<4p@`+6+&yO)GHo6_^RxMwv#MX1%3JxPPF$xX$yx*Ryt&Cx%$~-U42|A;)C=3>f z$HiU#5{z&^!Z9MBF8elfUP|Eo$}Fd?_BLee z*UbeN*8WkBqtmaO@W<^+ek{*NO$p)SkQ@YI#ZDcQPt$&Uh|e%Pr~OXBFF@w90tn;| zsv2G0jKKNead$g;%T>8tI6X{YHI50x69;_jh@W6>EJU}K7mo(LO}*Sb*Ug;l@QF5? z{h;w`;*mgl!So!?G34#}R3WDQ(PEvoS@k#U!7E7L>Y9M`OQSq2Qah&Us%3 z@$(r?Q0@8i{m0If$DHZ-`sQ}I9`!dd?~NeL>%&+QTzYZR+-G{4TGY(R4o!ZCFv;n0 zA&kU<&@T?Ku8%Mp7tY$($mjLWC`cGaN%Cl?D6y-2umUJ(O%}`zC8-|%p;-oR>gt4> ze>sOWj9FoPi8tb~xOc&|yvVL3&+XbZsCSGL3s|Z+HL5`Wr#_K zX_?8I04jSJe*aTQo*MdNrXMo$DegV`&%BGIsG@#wTSdxab$UYvyn4`__r&9U$=J_& zTA&u}f?D+p!O@=RtHH1e0rvmQW@duLNc}YC4xAHZ)Mkd;BxV5%<5?G-Xr_8>7`y6S zne$e^@*~5JZWATD=i`rnGL2B*fq2=!IhW6XNPm(sGuJ}2k-x2kvsZeAB@T$UzYhjV z+m2s39uko2+rk+kOHiGN_Y*ifQ*7V9cxXC{GmHdp`WbXCg3oPa;`m7E zTPq{2$RYqk_F z;)NV)ElTF6&xhi-z~`^*k>D=i^*Z7;iza}PiUg%)+U3$w0@L-+aQe7^3s0^0ChuNH z9^&((K~Sv%Lpi*mwqATc3OnQ?6I5{pn#3Y&XgnqX92C5a z#I}(HOkhX@6RZ?6;#hUW5aX%wZYJ0^5RVTs{Wgrl6sBOJ7BLUBZn2n%NGuC_IR+Lj zY?ILhdMLChB6h7(DhE14xE3^*i_DkQEW!|>E5sAhAp19>DgjDv6e*n{G)thBhD*ZY z06`BacqZ8-@&iOlX98LUni2)zA1;g|!lR=|hc~c8!rnoRyB#Fpy|&Wapkv4g$AEmy zOy*PRYLA#oqIx-E0!hF%=>29VEvf=Y1YmhWVJw#Apd+T#Efsl!I1@z`4%>Nhzn_YR z0)y9$=of%%p+HlBdBbS+esNvnWgq{ly4W(>Bcz11|kIl zWkZDH3rP8X5DcesC_F5D8UC1U^sqgu6M2Bx2^mkMGDncBC&iq|g~DGzezJ*J6Waz& z-SAF`5{eM0G!+4_52`g1u7!zJ8>1vO1%pF^IkQCUQ3qX!bq56`Jw_7efUYzn48Ax; z%LQ3jn>px_ar|UD8+l#?Mm&-UmmxfQOcCM^fSCdiu^9`pPdW@mLy01ycF^93H@Ts^ zi$n^;Z`q+c4c-Kfub>O#4~wH@o}Gn-2TvS!JNZ!lg%3RuEm?|Dh0GzXi^((tO2dqp zX*c}UI&4+~VpCXzFimVRd5E+iR&15{$sw!E&gVFJ@HiqFe-RTS)1e(9fro4nJN_X+ za|ihnKlF0@JZ3XnZ#2gd%4lFN;)2r}l0(Mm6aNk3`3*HELMQOs~;SRw@WaHj0Ma zG`k^)MiBua3?Es@ShAc(bt|z-x*uxrT=`YaDAgvCbU8t4_laDj%F>$8jaRwvu1L6j<)R2N+x)&yvAIZ-UP%20ln zEXenQF1H1I2rAd>)u}CRXz&RF+dj(TjvAO;36m3*f~boPlv{!E4=r`T1C7zkJVKWa zC1UwN_BbNN@FPKFyi5>6(JQPK=pyNk(I2m z@f|D%3XBt)VUhSi49LJmo_Gh^?2bcJL5-nwen(uz4q)SM0}rp)0PnHhC=E!^VIkxj zad@rPLBIfUtjia)!o*VT{y6*#d3~E1gN)>g5{MucjKD#~GQUTKvy&7$u{uCyvjH?< zVynNMQtVSdXl0x)?7aP|YsCi7OUk;4H|%dhH;|Vl=D_ z$gU8#imBC6@p2o}#ieq&@i5QGi06(PA5NTaXFp1NX#Ad#R4Xv z;N^mVI4}^#!wOLQBhjFfN`MG>N{Iw$D=d_N=cAy2*TMrzv{p2h710BOG*tq^O(aNy*r+sy zl;!YYP=0QZuGOJUao~J2xx_pN%@Rg|2)ta#ASnn2hR7DT)1!PA10pk!W~QRTYKs%u zjtE?j9tYJ_wh6~zh{GXBOt>fxjTu^aktke3F@qqXPZrkb2@aDJuOSFRXl@7r+A_^f z5L?t~hLiXe){h)c`?2$I-D zC+H2kOcafP#4twjJcSV-XYv_rl#?n{;UjXkh%FU~=xA?DPNo8N6drihxip#E?4ks% z8avhuHTeMGQ1K!Y79#=6Ct};sXgMwlR+(vZ5QvJnj~I$!EPSGjsu58@<>(&*0~ML3 zwP8h3C1M#to6jCr>J&zaH-d^niYBVSVlZ3}21Uo?S@bY8Ya>^pjR-;723|-+E(yjE za>XbTK*|y9z%|cu;3#pUK;<=a=w`qyQM@sJ)XqjMqycQ6QRmkH>8x0!RK`qp8&4}h zHcy=@8jQ#_Xbn+rVG;c}hQLMiB96AbAjg}D$*cZmCo&q zQY_F-Lv>r?Vyz443*lY(zEeZza@9@)HS9OAf!W&2z=dVdM#Lf_chMNsBUX&V2dW3L z#OO65+oFVQ3rWl_jf~E4#eEVvP(d+>HjSGf@lrSdIM&Go4hnn^KoANMOaj$wQ}CTp z3_&Y{)j4|C{_rX+^|(sLAfUgJil@aQ{h7k=)NEZ$e#THicqdo0I+~y z#&b*%jC)l^xdxdA2~W<_Yc&MGLINtzZ$@G^R-7G=T11XOFo2Y1pOej;S zGLxggnX9Hdh@iC+*Fk59Qe%z@-53u8i{^6BQnQ7w>@eO;RJPbawH7Qk}{LZ;D8x1*$7O%5gQRoktbIVOy~%EV?e0Tp~(V2;MYxn8;i;T z2^t9dNT971cA4mr5De;689@q0M9^WO@7k|)z*{f^S`*U9jV`_12}Bkl7gHN06ErL` z$s>y!)LOI#S)i&QA&6CS%n_myt$^|(;MFADpvr*?hQ%~Lbls7qphu)J{o|!8c~qlX zt3=0G_%I)SS&WzYk^kXve4rI1up@~3f&76h{eSXf{!cFjgdM#)`0Ix@k$?^?9OA_M z*UeGs#UQf8mS}`1zT9kJxuX=gQ~!E1QN01QOqgOEARUow;M>!l8C;$OGHR=`v00;!#M2M4$C*Um9kienxM*;vCCt6uN z1u(#S)UfE7)EJI#!w?l}6f6m9P>Z%BjsZ;siFhrW0Ss*f=;_B>)HZii4H^g_d=d#M12@-!mx!(1CAqwep0~A0nL1vO1B{fGU&AvcwqG7TpN+YWRN5DpjdA-k@yVc`9-^gq^R4?RD^9zn$rqW zBQ&UpVe}!Ig^9r-JGe!RMdQRYGD{~2LRQ!ZRQ*z#12V-}r<4t82`{9bPzEJZOrt{7 zOcE=gbOf~v77tt;GEd?n0>Ymp_J)NhF2%v1_|!&ikf7oUT~eu+XQNxBUK8I;q6@@M zv?3e>aukv%;3kRjVyjby@(1YzNHtM(%s>!M7mguTDsfSe(q#w#iG5WNAo86KztN#( zgn2HL1Q5k4sKFcX1SdS=Qn}scCjp-=N)9MGARq+YQ#m}kDzApa(9ty-;NIha`INHw zekqe?cMut3t!blX6OHNUM)RkA_a@pumOJ!IEVO0QbpMr%P8gbr8 zVH`+Bd&AHf3M5lzlNdRS%8vmBSGtR#R=6piDAq;wK~p0ULr{ZA4UPodPjFDVNf-qA z1h6_xo1LoyU3;lkA<)K!e!EB!S6MZnIBYTd)pipL0P;L;kSe3ZbW$3XFXPBVMxzgo z#M7Z|3P5uKKGP_|#Dg4%k!P_(7e5Vgs?36*%*+YIv})*f^2;qmCz}(J$|6!38k%!S zILJ6ys5k>TYQW(mbWzY}3~1CM;Q5e%28SO>)0q8qPdFa*X>AUtHUzQ(JU~rwP((9G zZChm=&>^6)r~#z_F}PM6O@ia29e{`-ML9k@$KeIJUy?3h#Q8NWyjCt|knN^0P?;gJ zm39Z+PQ`*`lRw0B8BxF$h4TW|$1es+Di|#2fqDR%5K|MG3K__phMW;T9@)fMb~@2* zpoGX;ryk3}i#1Ay52Z1NBQhe&NkVG{Xq{ceU<8>UaP9-~34;db^x~wDOvg!}P9gEK zP<}qB35h_l4X5_2WJE$#%?AbRxQiqXMFY|Zhc6Zcg6MzZHiHsq(s+@G*n|=T?K0WU zibQoW3oGX10!sq$nH&8vKUFW+gQ&$nYNWEW7*I7k3(7UJ=2meQ%l%PAf^ z2?dsi8TAnQYh#;~x%=un4bJ|`KSDbvU^)KMtcMdN2x| zix_gKEjWSGK!_W3D$pN}!GYr{p-+pX0wpZG8(8uKL8BlHy*Wl~fC29LTTD^Wwm#BHNd7-o$a$Q`j%kA|p3I}yK$?#G1UMm5famZ6MP4uLK5_yNlr z<6EgDu1ZBBpxyeYHLO#TxnYxmMHLx^?1(Bxb}~qKgOg3MLoY7L4J_~e5K|KkFpdBt4)L5i85}DIKPm0S#)yah+F=!+{<+*%-or4+eCkkd6xm z(L#Y-t%vvQ(9R%%@qlMXh!MtuVkknej0{kJAOq<*kwhT5d@3S8N|W0NW&xL}4M-7} z#cWrGBLLAb@w73fSgr$e=s^?MXsaCUr-O?Jtax6M5BL&HL`BpKKl|}Sol~t0iger% ziHXKqu{@8;AyhzUp*QH+e49MXl%lNxGn$M>IY90k~13mgr=<;B_@Ezo9t36d;yF;RU^S#uyT|$CdbmK zF1OojfWCb+K`hW&QGALe95cv$Mu4A6ENZ1+X$=Mg4sKAdlF>nG0?_?R6NnOec*KZ0 z5>b&T3uv-3nU5nn^X3(-=g#;8$5;(i`O%vOP=MtglR7bmC>^2s2WiR^=Z8I>Xi z(4dK9*IVRJ6UBi9AaeRPhQvgs6Byu``fH2|LTBJM_1qv3cp$i1eAV=f}e z3iRM8i~!lctyT#E$>6e8QVpLJvyyNaoEfx}&>m>WN5{Z}1CpbN&5zdl=on3aCo_97 z<}efEL;>#6Z$$aSQM5?nS2N==&>RNwX8{2Zu8kI>M=5*+o!3K<({)-8OKr6Ybb7zr zM{p?}K_1Z8!og+G_D-?62vj{$4&Vatxiut5mq>gB-R1 z-^u@%Siu9dO@aS?tRUCoi8cy{AQ{3y4++GF=;a8!9f=k2Nahn_1;~7&#V#|JBX@8N zYP5jOGmt?6QOFIsFmZq(QT$x14bM>HDS9`W0DZKO8Nia5B88s}WF-iI5?L@T4VnRd zJcMQ#je#N8aQwKC2xz3iN28)W0<~C)Vn^6=t(uHO;B)~3S0ePp z5L5$xLQRxLVRBo&nH@57d|{cK zK!)}#=;$UA?4Ywngz-dSZ$zvQgQ$&P%-5?3T6&BP=m!i|M-T_#b4XBool&!y7ey&; zjtBH!E0Wn-B{JzHNR{|@K+F&sm0(dixW>9D&Jem%t5#zm$@24o~0&rr-&+65jNRf>T*6@%=nMz4Z~Cx-iD?O+Y?eakjsK0h|qhF+(bH2fTyhD5k&#ygbll#HY(Q~zf{4F&jf-BDrX2H-`j(#v(UsSeSo+5*$LzMTd%| ziUg{v7zS|cFfDu!I?M|JHrnF|Q`tI1Z4rLe!%zpIF%Y_i)o3p;_qnW6xak3pH3l4V zQe7CWk%`d0nAH_RoCR8l=!?2+Y&v)|W*{|Dd7;}%K(KkKdL;@#6$-2`W(T<)j?-pC zmbDFoIGPA=0F}=+@S-j>D4?r3LJZzPu*!L)fS2#&N#Ro`Q5pbuAG$&q6tza)+fmqHq11y{sIY2}ha-p@z*gyLG8EnbXYFFCVN4ZOuBHImfE3^5Cczgrk|Dof^rZyD`CvMds?BtR7H(`m3kGZC}XL9kaS4H>AM z7_>$@lo~0Q2o9yjZ=`aAA(@31)VTE_9hD)CBKt@bEsyYHL_iO+k#Zqb&$Iz`BXU_v zs!@cp@LhtKhGJ(pRoWmOPnP-I*Z|oc(FMIyfq*Epat&ld7~%7x#t2a60wHII&H`uz zgU!!!sDx}t>Y`#GIV@&E{V+lc7~Dd%(9R=jY{2RmkO3wxj68g1g$u>OAjT{P^?E$u zW;j~7MBsc6S_MwP0rJgk7T<{0kOTp+qETl+L;%Wguig^(7`-N<%WIc-0Z<$85`eDI z#PTwgHauHFLNLQr7X-P;$U1}3;&aF;0TkT;8qPY3Oay5!_yqVeT||yp3xzP7p2`Qr ztD6*Kv5>HtXBUa1@IOibN`(}@-EN8l84yLOWI4|`@>osB95(=E8GDT3#fd|X2i6U z>>w6GfEExBD*zS%6VPQP>pr>K!0M59iE6tl$5( zW)1JVqGp>DiqVWt6657Mb$Zp|&?)lhxKHasW8`U_W)$rncl`MAkB{TuJ}CC5HK#Ke z`^62M6b9pbodz8`)crnw_mJ1`C!rmUG&DV z(r0fM_8c|o=VY8@bo*J#DZ%>n8Hw=n=9YSUN4UO`RyXh0bXL91lWRLv)1IgO-h6e| zg)MbXSJj)qD{i9h(;;D=dddy#{n5`0XSEx!X)b(`*|c%G7tMBK&#H^PL>{aHHzhCm_{4sT>c>0Pq{*?j;>H_a(E#~_d9UTN8 zXRlfjyEwC6y`u6>$L0-$kAEmfKTj)~b2ZA`HaS06vW+(t?@wruH-Gq)ws`}3HMMSq zcbS;WlsB31;;4Dto9;c~EH2LcfY}Zoze|H7O-vqIoVX0eWG)-pNTN267{;l-QPu~m`u0lmt)_sqPy68YEzNBWj^WS&LdbY++HjGD?0y<2_m z&ADx4Zy+bvvKLLRpp-uTQTwZF+a&(h6+i#VsGS$_jO$BV?(~i9aec_w^VqFd|L%9= z;+(y82khN{{pm+bZ}y5u`*3Zl7wk=DU+9oPuR9U0I!koOG30b?&xv(@kCZ0a}e|1%szkO8EfxeE={Z{6VcE3kOFDAVjqOGS1ysa^HTit`T z?$g-g-H10fFk9tv$^xNtEB2vCu^ZCDjE6f!)-+64a|wC=yhr{4p{?!OZ?IflI=!~{$}g;f)uulmU2XEMFeK@b@$okKtEV!hhF?n zn?q=5m|hy$wD;Ej^pOpE9G&x3b3p(7?(ByLqC;o=7((CQRB@y&f6)=kH)(b0h-t@F zDet@Gb=q)jn%s7WadX-870*x9T$;^Z`^UfqrO)OJtRFu!1l9Pp{q7V)vE5o|X`P9; zmtS>I?-V~f)nxkEZ%fJwV^ep3x-*mfoEIfc+kdRGxF#}YWa7N3+phE({^_9fVsI5E zdDM=sT|%y98~XQna$-iU?9I==O4l#g>G@TZe5XU%$+B~Tt(*;#{ts$P^Q-REL{LXU zBd$G*bmT1Eag)>Sakx)eR@PKMvSvF^gT;1XQNP*f8|~Q_6fZoTQGeDMGiJ=@(MLAr zL(vm%$@H{N1)I4ilis22m?b;-(;pPjP!A>!7}}uc%S_AL-dh%*irS7G_Dr37v8AuW zqfn(kxL4BjSJIEun?sGZEtkI-`?6%g%$!G4c5vo^c=-}3KC)xuT7TGZ=5 zZ}htgi+Ant`iB*Bx9p$aeNVR;1By4UnfmiQ@5SA`vFi84#KZ&UnZ;WZt9NS!+4oD+ za+f4mb#UCHt=RNg{U){d72k)Kg$JxHZ*+gOP>1bQ5zQ<+IZ@MV+{lSj7tO5lzIooG z{a{VQ1?#bz2aDHf|J+zGJX%${>8|h92}N1(!-Wm9c^AX3)5nh9DSKBb_&aM{*L4jS z>hl*4NiQNrn%3=c_UHybe(=rfq2bbPyn=Ej@ppqJ?Os0nmb^06+<4sZiPuC#C4Wuh z4T4d7>xO=nwA7wizGX%4h2+TJMQysT*~Gkaf2ZT#z#Ee;>hJ8&k2voxF)->%^3{l~ zxPOiFWSAuX!Glh;nJv#(l@^s>?3s~&`Erx&>}+mhVuR{QH9z_}2er?CZmW27p$+O; zheJaOw`f!onjgp+J?F0N&qrq$_YQp9Gf*9W(<6IB>U7E2!HL7LZ?7f1-TwQ)eCoQf zQ=R=AtZh&kdi)S&U7A$9+q~y@ zv)-%gcvFqZiG&iX+U1F!UC2yaPs%ZMPf92;HfyBFiwqt=Ib+Qs%A+nF2PpHJ9(Z%( z>e2LIO~Zw<{Y{tBvqC)uh}nKwENG+jV~_V_Q$d6#$`#Eo-Kp ze`e4`4t)PRQ`$Xnq51i_{aY;~_8<0r+wINmrg(;&TPj0to3%aMw$*aZM&Gv4Gnyxs zeYltWd8F^+%I>=wv@4pIqj@p<} zv3ljf-@`F)uU(&;)Z|2bez|_1^r3L)fz%w=#KEL+cN^BcAk0rl-+QFGGiPZ(%k%Z0 z{+#>zZBM;(VYvCdi6gd`A3d%da>1U_^WprmKi`dwl{cxm(nOw{vSH!Z^TM_w(LsqYfQe&A&HJk$U-T+Jn)D7oW*c)Tx_% zny7eC_^oT(7o<@6^(UdW_0#T~7v);-jnr1>wN9T*S<$8L*9umvo0gyQe(5{7YsT&B z`}Ea-jcZ5l=-({kfoBeJ@3=qD=Wvcpd_O#C&y$V`dF}q-{^cChqq53F^Oam{GQ;!b zwd`B^vrWA8r?*7~DXIix>7Rx^+nFYrf&&)ZKS8=V#uOA5}aQcIWt*}CqK&b zi&Kex*RB}M;67{_xOgl!sn;ciYfi$7IRz)~mzZj-kDkDq+MRyHpq&%_+Y$47)9(Ro-RHU(B-Z zAMV|2O}#~$A=$z_ef_$ixcK#G@Y7m@Q}VhCYGA_7IJ?91hdJ{Su`gd=U6DSgw=%Ej za^`f*8$W%xQu)YJ#qSTOQ9gN2MasBx zPo+IMxWj&O?0jkSBG%z-RbkQNN3t#X#1ZEo?$_5XoZ5U-V%qBo;9v}1lb_pr%!szr z2K+f3e8sM!>_4O}+Rqx2zVz*chx>FV-bwGdH$VJ!uJ!PuoYWb+Lxvg2Us$s9%R7#{ zU61)?>YYC4wvUa!{Iuz$H}~L~9M|a+WqT(+8ve5steyVjlGsYTzfR4Cs}C|~J}6lK zWoTbxe_#3dE~ecSMfJFsBU;Wpyk~k^{-Es9HAhK(e7B9>FKcHncwJG^NAzXm(oX9> zp>mea)}QY8YeVK|`TQN{*XBGwz(2J5-RsZSn{~CR7VQr!)B94yg0!-Gxu4G*pLTQ1 zfmc_~hPzI0c->iY>)E4zXJDi4`YyGVdtKUQ_9L!+L=pNlaYzrvyOsScJxq+B=RUh0 z9`(0L&+T@m=H`RWuEH*}+x9olnty#N??C3w7I&*nY2uwh@}70YbFa^R)2HlRhk2!s zdO!Z2Tavmcl$%Ie^6UGnv>ja=9UE!w)HU=gYt`#^33;5<_y@||lop$sq<5uu{G%Zf zSvX*w{$m05Ha*udZ@wwFUFMG-&knS-VT>;mmM>WPGn(<4w&uZ~{!_nu+-bMy(C4Qc z@I4$S*3CX#``4qzuU0j$&8$hk(?|UH{-X5rqSB{Ras!d!6TK>1zg>?vCdL=8n>wmp ze_av2q>Msra#^c0eNfV?Gqg?-Wq=QJgZlF)#HB6S9iJeOT6dn z)Si#+i`@D?XREGP?0E6&eNWve&-4Yg6K-s_lweMH@toVQoL76FA|7HAp2qekQ$7`{ zQu=fyh9Z=j;>F{OmTPN{vJCm@~4FOo7cak;l{fSsTXeQg^yk4GgnGZ z9G`!zR$kRpHKu-Wtfb$%j_F;f?WzfX4Q4loIHdIhB&0cX=Ju&^9blPuy)&}Nm{R?v zU$;jU9cOKP|5ns9w!bgM^J>N8n^PJ03NBd$%~0=4mM>oTOR@RVm9xb&XO_y>%vMFI3F6p#86ZgK_l6i60 z+=cqEwVIg1RXB^PQac%q-FLO>vUE>s`>v1N>}m9jB<9Pl9K(nP*OR}V4;TxU_RL7) zY##nwRk35N*LrR6(J#zPjn?hS9(6Cj{e+DL4`WNJrV{^3`q$;B*Om0j1{Z6AWBRs? zlY?5PRWBGwqU~FEuKkvuKOZy|L>x>|8?Apt5aZ|%BbMtdgZ>832 zlR%$Bl8=6#+VcFe>~DJ^`m4ngzqZ+h$?%s}b}m|NdslHYl-`J##q2kic|x#t6At#E z%YU8g4MC-E7sRJyGLt8M91A-)190y}rq^_p|E7r7(jc>Q&Sa3A`9J?CJoRsXC3* zuPS=M@1NQ-IlroOXVTlwdtgQyuIbW*-yTJVDH9CchUqOCodPrZkzr1xk4IkcY>BM@ z>~yW+Mi;?|H4*vJKyxL`;WWYg21!j=Jkam z)+_S2fJ8=qDTJ86QZp};8}5dia(X+nUb_Uo5XM=`+r?+Mzd0Aa8DFevcxwf`_#xF^ zfTabW9&HHg^LeCwb^ZK>MP$j1HVMIP`3rjyCIPWbIS1MU!l)j}fbrg-ZT z620z0@#t|Wo{qNVoH_N(S#X}39iwXddzzP>%zuWdoxY?oy)IU~v0@$`7U4Ad)%Gxu z3I@8CGP!zv9wb{Vqc3zyXwHJeoV`4q-UlwL0v2y)M@gRy)&vcB$_0x!DE z`eWv-dgjf@A^*^BAJ}x|QFzxpsqVR|uL*g@sr4~=1O6l-51nx6A8nD{BNfIf7N)(| z)Q1=N)|{5Nv{T9oHk5z9?l4|jBKVl6|1kO4!!AEwCf+t(X?tfAv!=pRl-EahhQ5E! z?{5cNZ@v1{A!v|i=(nreV3-Uhk{()|bVGiI(5bq%ZI2n?es78|RkD{1PMmSrH92|5 z)Md77i}0y~wV~0wpWR@u9(?rl))gBM31;tU^Kzj4Sho+F5c6bsU5g~)z0u0+WoN)Q zfAQ({!cL+dx))m|4^Qbj^jtDxJms$KPMfUwu=3y2B2MbF&HWbPBYER*FzyuZTnZ6( z@rCbq-n}3+nUuYtx^2gX{R=eqnpQPmo49!9vwKGDSd30<`8q`HKVW3R^8TkDS18^V z9yBMaEB(}8;jw>TEIJl!`D@Luxs3jv-l1d7hh5ejzfFFzU*GjhhvZ$p3|XVXE!>ma zcglBcdK`dBTP|za9#(Q+$e$jCNAcfF8=}=Qtw~-UbO;-$DxOe=imk)1TFN<_- ze5(7!#Ro_0rp;Egxin~$X!wy>i(fmg>8gKKe;#sd;o4c}I7?nuf6iKo+1UR{y=mfX zW_J=Hd&c334L51GbUd|o=JtyxGukyh{-NKC+=>ROM>|>t@>i63^V*0XOiKT~;A;PA zl6`W`Uo$5v$Mt^?EF_bJMCXUqAJP-^CJfu0cgWSgdR+8n((SDUJC~;aYMDOjWJaTD zX%EhRnrK;!i_NhXgMH@2x3+^th4LZ`bU0;uk8$Z|BL|F^%SsA~%{!y&3>`XD(rZlj zbXmV(@lVZ>Q2F4@yN; zsFv>L)FsA&Uhf_It3m1pm4+R?Shdt>)sGGxV+$x{H?Ch=pIc|J_7H3AZeew8$(jql zlAlii9{~b+%th8d>)0gXuoiyWtuMyaO^V^h4Uf&bo$+9F z!L9Whuhc@qr2PHa2~Uou_fQqA9sNDyyxP*4O#S8C~Q$GSh$JUhT+- zhwSJxBPY_QRUWn)MzzlPS>9+t$>XUImX*)vJ^FCymaS|+!*PnvCGuUZyA(b=eML7* z`gX|Nw|z3orKCfiPRbvGHxIk@zn(w-p1qHCJFzk=t;qp}e2=2l*crzRt4jYGaIs|E z$@X3A{Ve-_w$abRGfkB(r#+mp-*l^+SUBVQm}|wm&Qw*JrbNGgZ9?tw?Ch#(6U6(B ziKO_ASKk+Yx?8XQ#5bppXS8|^sGDblqQgSP1p}FaH@lnsHv^=}{eQ^-dH$OL^8J$m zn!2b_RT<_L+F=-Vqfy^s1ls)VS>K1v%Wjgs<_9tFnh0zl8*JRsmM;}ks%Ln{k00N> z`>^&!r!p)X1AhP1-Me?UJ+oz6Y3|DdvyfEsetb!uSK^+Y zJ+%1GTifdoZe}q)cRzYsS1_zK>>G!sk z*m&bh{?XzepI(f}u9m(YA-FKFOVx&V1?QX-J0J9RpR;`TynO{d+nku#PWAV%aJRFC zs=cT^V`+y2>Tu~r)U(`4Cfvb8tZzxn)#!x~d_uB=CJ!=hgX5a7;UZA1vOJ-obc%-HN^6S-GA+ z`40#?pI+(GBK7f<;g|b5S8pkZj^D~(*Rfqq_)XWuW1A!+77Xt9_4j9YyT!Xlx2bM< znDr~XF7f|0Rn?{7$;3HtcOMaQe~s;4a`n}V0_@vM+is;d$qRHCdZj|1vqIF>v{kU-O;w|Cj`aq3oln(Z1qSxdi}V$_q&f?z6AEXvhT%>zIw*B3si1ky;*zo zk&yc5ZO6P$(^$sB*_m(GT-eTyT&&x7(O?sIM)9PjX78cZnWsPe_*MC>+1bd=Wvzd% zA~l(?_V_PZz2uaUrw<+MzX%c)m2H-`ID6FA;z-J~{BS2hP0DZ2*oL%w%adqHxKjH< z<;k_a@8=|t6G~p1vZ_}#WPA8cA79?FsOp&LBzNV6vOX%st`Dh$y!hYq27N1B-f*)b zrT@IcuKADz`_iHj{s3OQ?e9U`mv%cgpm>tExJz39w*7?HI=npfk$8TMDrKMk@gGm} zf<4+P-E->{y~=%d)Zcr7yJ!~Vue=a4(e4>DD>EN+cK#6luk2T3y7t?x?4m`DFU~Ky z)zXGF>gTq`XI_zoCcVjC+WFxD!nEP9=dZTEUh^DMQ*|4TwQs%mKeA!5bvFfT>s@&t z5WL|nTH8y~$0#e`cPgXn9EU}SO22cgeq4(xz1c7C#`}in^4yGTt@38H^3b-d%b0J@ zx>dOO#BJ=PnlG`u<&E(5yQ;EUCX)^*UJl`pN{(dvz=fK;r#k^!RBx2OQ-jNbXP0JWM+p4sVh=Y z1DNiUPftp+Bv%KN33_~Bb}y;+*3%|Lm%N_xeC434l$gTocWVS>Nb!1Ueut-aO{xI zyPa@!!;rL5$Br#{`#ZU#GrqTIX7}WdU-Yuf&$7O~{+Q6>>00MFQlmS$zjNy>8(uD7 z<+{DA(e@T4b4NIq?;qJQEA_zBev~r})a0j2lV2H4o4%WFEKaQlLHEUlkQl$y#BSU~ zKJ37%p1kMOJ-?}GQLy;H!>j8$@dx>Dow?DwX?j(*tnR|nC-WAWhpor`H?2nKY+wAM z=6rFZbQxp*AGQcO6-Z@0NlH#|1*P@v#lxl=@@a}Lh02riJkM_ zUto^SxEOIO`Iic!Z32a5-vFGyJ1$~}&;z1z`6y(nh}ly!epku~f4sOs9I8yEkCM{h)iaa6q#%wABS z8#z{DTYt0$HzQ&_GwExkaHvzWzc#s3p``sX&-tmB$A8;^(==^JQxxQ89$x%n&G5Uy zc9?UX-aVPh8I$H``c0FvYf$2C<0R;3NA6*JjZkcG`m*cW(glq-&M43KR`1h zxpD++!X_nexAjGh;*#O@&wulDvweB1^Q*RhuLV>L@xqX&*UBX$FBOd48Pp73NgDL{ zd#AnC#0iHUjLA4H>a$bpQEh2|wrX+K$9t8z;mW(P&P7ead(<1#F>Sl2pQ`-n*>81D zT3B5CPB3F&VTNIE0%YeRbqd- z^2M~DXN~=PIc62VO8k_tgAo@T|9b8bZNdw;WxB0!>d`Jw@|-8y zTyVgOR)^0%k?hE7@saT8bVuHeC#E$}-8ud+iMmX)qH=!Bvcxk!PyhA`qwJ}_aVc&5 zLD%$N>ju?Aw)*c@g_-9i+qHtPe$82H#ecB?Rd1%xH=as#Sk4o<4esS6jGy>%=!w+E zuLtq6hdcXAuT4Agv1HxYKHYN9P3YFrrD>KsSuv(}|DN%eTQ66?uM?}7`*+sX`xV{W zr7zva^sO6^)4!l<_R~WB+Pz6-g8SW$E$({C*=*Ehb?U`VYdT$LJinFPx#%D*r@~Vh z={0P5L8~=W`bu`pZ&7pq{e>yn8IKFbjLmSEztg99ZhwYiqjTV#?8G%C^yh_t)Hc8T z2fgk|$e(0IE}KRxkZms`lH0Bx>%g={WBaWDCZgdbLKG-;>fp)8LYua(v#R?$guHH<*>vdPzt9xRJ5HH!XJ# zS^ahIzWF<|(l<1}urhnpug7rAblmZCsrSWO5;kn@?ZUH(Hn4kdzTfeF`MPl5hTNCK%8LRW zM>tmKMonC@^)h~S>0W35ITQ12Q&8WtcisBNBen>hyxFdGsNz)cB`W3lHs)M%>9~`Z zL^NwvkI=7OpGRd^uiNo){h;?b&t=ckYC9q@j{m?ah>Kzn{y7d75Jyb<{iWa9+;W*~ z!>Ea`#wPE4oK@B}d6KZ%k3JdOZG$#{T+wUA=sAP(a=JEF@H)&b+&Ny`oO^$2P9hfD zx!uM)r?xmw%}Kk{xx>YiO=ELJJ)iY59;S6E|T&eB+3y18&G|x62FIyz@RB;q9p5^CIz0hF!NTEnED4!^oXeQlsD9 zy?f86q0R5p@reuHbolX-eBkZng`<}KF?-{oW8d$zYkQl-%RX`C`yiqG!3O)_IU{ab zJ`KN298<4owUN63N%qJfk676LAYh;7c&Zn028}&w?7!VNsp@Uh>dG<4-$st#EQ~d+ z-kz{@`;(okg(-_|hEe%{?@0W3^w!e)$Lbykcgw6Cvwz(=?S1uz(M7h~u=kIikdUL< z05$)UwYR5r1mDlmyGP2q6Bj1TNw`SOH{{+wtY)T}Tpc zV@Xfk#H+e_&4woAeVe%KQgr*y$%l&+^@_Gf6`gOb1;ESzP20=?tuHpU)-)Qj;OyMn zC-ZajI;<$C*F7u#cg(Ywwmf3?E^{5;wPN<%dXn}xD_gD3>(}95?9PBcJHu~|?N{dN z9K#h3XpncE@D1aGbWm!K?7DF2)81jWUPe-Z{(<^e5kEt*HzM#=96MHEnVhdkM?c>_DttRYEzv^Vv-Iac^ z6c35mQ$Mc0+m2ke?bR)(<$s+k{NhYU{@>5nJp0k5@_pY^cexwpSANN;tsW`eQ7{Vu zq~LKUr;xx8I`pA$wrCQB+NTn$BSkm56;{7+B# z>}q*w^ZzCew@lt%mKB|tJGB0el+P$6s9O%anry|JjlsI3J{@b_u0&*ctT)#6~)I@yx}>8+$gm-kBw(g}Hn84PM&@8(u#eVuk$~zXr)Yx92R}5k=5E z&e)gYCod*K^w`PLs^s;C4$0#avf|_|04b<$+hhCi6u=yHx!B{*6x__(>kb4nb2a_K ze{xDX{tnyM3Mg*sOIN>sM}FLnaYcFeUAIu9Ch3lT8`gF!YI?3=9)5~R@Ro+!d$ktV zUA3ScJX&|a4SrErd5Nyl_f;4M>3B|RO3 z|74w6wP`Pse%Mo4b$ZF2$oJA6FHaO5Ef;rsl9@QJ@xYk zbp=Yd`C(`P3vhHp>mdm!Wx};KdAnZzcym4wOnkH8S;yD=%c@&6B-!POKLm&q~?;PnjXL;6NjB%fz zu!s+QJH@*v<@i)N*48f$Y~`ME)La-d4t+weu0V5WL>R$Fb^64_czMr+O0go#a&y6ZN;U$dB_%W+vc;eA7 zf-(Vm?C|icn$BcThvDmv=>R7LnL*~>$FEW0%S?cUtSi`&8N9h?p!H8zvlL6}>zJWq z*2UuwQqX~Ob)FoHc7!mBnfsy#l1y`tAGuI5Y5jmP+v_z>A2=>l@dH2sd#=8^Q2jb> z5df@uEOj5S<6QHPDc1$R;LCrO(;g~PzW*Q0y=7RHU%U28cZqb1C`bxOw+JYRbax3z zcTKvKRB1^;Ksu$FbSoj9lWv%kZg>aJ|5^K4YaQ>gkNt6fQ3SmE9^)G4^*hfwkor&& zgZO+xGWWYZ>H{*muxE6mV{|uLN6aJ~neIwF2|^WGE{A;xRi@s3PnBCw%0S^S5{mIFEV!OWbdQ{lGLE=XnG-s2_Xzv>S zrHftdLh)O&rq>0}nVhxT_X~%llYSWc^l-hi$&0PAhZ@xUmRB7;XAVmh5H@H?=y#xZ zYP;_v1JJDNGwmifP}(+tNt1Fou7n2M$F2zLhbC*!(I~6lTNYu=v$)a=1(uMI2NOE2 z2{zOPmxe43b-syrnXP$&q~I%h{$ASPaVwq4D2;FT6{E#=b@Eg#?{3dKDIh&&>z#bH zo%}bv#K_UZ{b@(Y2bZXT{Q@}q6p3X+bv-*A@E_Ori+mt$cfcs6@ z{aU$Wt^G|7;`Bt}_(tMt_)fytld$p2!+3<^bK%0sCqP1sQuWu8yW;VB?sE35rfo`3 zy){*f%Xp;WvAkAEATenXt1ry_N+s<~3pCW#%7_oio&`>vqB^d(+7IU5E$~8CUI1Y% zBgf**FDsSG?TAr9?aW`nY^{q~SzBj4iZTL-{mzgEtJTNMt+8pasZ$O_NuX)49D$^# zCk5o`TP>d#VzMGmmxA(1*SIDoCg(*TxM^TM7&<(bp+k6F?E3ulRgm>;(|UQ&gF~Ub ziz`N}8+n>JcM`2qgBU(YQH)%GL#g88tUfQ-5!w9;)g{=W@Y^N9ZkL};kRTlY>f#f8 zXXBB6+fxM`4Fg&+%SRsHv+JC6X+1 zg?k|kX@x85^G{P5bVPS|G&|>l$?Jo>t&XTlvsJ0@#S;!G7Cw|Uee}rXxi2@OHSMOu z1*(r;Y+Ln+TNe(0t@Zr#Ya@9_oPDNFqxrY`$kXJ^`kfy$xMx5{#=8r>D+~Y<8ZUsl z8i$S6o&#|0iF%l59VUuZ5j2<*+QY7oiK2~8p(=BE95_ER=!5N1eO3y8kN@Fbv;(*H;DdCjfIA^Tcd|1`mcqU*FL5x5)~x!AZ5b?fdr4rI#PK zZldXt-SSi&)vdMdr^I<$Pm>Ke=nCVjtA)a!u#qoW_dXQ$bfw26fXfvS=Prr)v8v|2 z4JB~5<90iID~P`px%f~{x!BR^_laJ>2RAm;!>MOhMavvH{lD_zXw~-Cp-EguS+GTM ztI0yK30v(@pz*bvjhV-D9+1mz2w1XC*y~4^!JzHgvb1%0RG$FD@~j8f>y*T0edy&< zkW9JlxT(1Rt|MXm&5os8TYM_#($#d8<>ud9+@PSK&!S$3M*UAS9MqtN=JweEek9KY z&htY3iYyh|LNsP8fXwo!NqNh;SF4x=l>>QW)z83bP5t@RmsGc3mRI4d>Z32kDnBY) z#3PAIPwe&rHi_gsLky%#20pI6oTw43_YiqnHjQ5x!zKwjF%@*-$D&l|YNAHP@Xh2cB>j9VR8PZ=Xd_EY@!7Op2waWy;)=5T*;ZBYx zMq#F;g)B=~of#!lf-w5gT1+-KN&u2bRIq4Q;&r>)j1m;RgfgKPqnQ^3%TLhVAl#b+f6DFg+J|t8EJrdt$yk5KHeIf0z`Dde-x>MndV0 z)0$0_*;G5`s~Vc_U^znL(PrBBR~QVIG5S_x4V<$oW7E>T?tj|`aqzcaywX#!`EBq# zmHbC>atoDKnUU0$y&bp7vH6cT>1566jU63!#2>EJ)PxptdI%FXW~+CCp7~|$G8_GJ zOvk9=-IsPnh5=5$^BbQ{x#QBy-MRXQ-@ku<9rrZ4wbsdqiny7@7=e>a4T%MMD7r$T z#qd){nz;r7Ew&!6*&yPC!h8DFRx7Jy3v_X!gmS`L9eTJ$>wV;OE(jJXu<4pb+I?=s z!%po6P@IgVl}XN@_KN&l!yx{&?9V`r6rDfV9r3NnQqJjTz33xt%%GWvK1iwD z=scL8MX;_`{B@T?%v{i3> z*!r6XhF+{rJvZAhHO#@sD|h4xujo{fVOsANULKnFRlpbNrU*Ab4fHrHuJ2KM9`Tb{ z$R~A-<||P^ZSM3i#TsYi0^tM9_KY%zBvT$%T)S6ii${vhTPRTQ0N`0#S~mIJ=q}EV zaZ#jXvKUL=-}N~E%c(&QikrLk&qJ+-`k_xhT2D9AcNl<{GnlNg=wU6Ef~l1UNQR-J zZDWsoA9x<)@c%jM8BB;=Y+NIPXGyt-zWVf#S6{^_Vr7tCs5QeB#iy{e>>ujOnZ6nk zYl~mRDJBExo{C4t7YAY*7yY~!3r5sh!If(>R5soZwEPtk(5 z^vDM*Ytv#{oNiwP=bAQ3dx)@wozvOJIRb+~9r&DKUOk`cJrN?>fekr8v8&8hilKBj zGF~4sA5*QAkU_D(fyyvI9T^s0Tf9<-RoIs;jjI6IdW!@7;!F|RYKE_5hNr-1Fl(>A zl)6|2sJrAE4hkLTb(NWSP~V&W#%aLYN_G&;pXV(dx6RvTIvF(u?!AgQa$aQ%AXqzW zb59o8uKr~rabu3DcY0+c;>(BvVQX3*SxX=@C9qbL2--+BzP{J7OuW4BIQ8sFE|hOr z8K{XhZX>m>sjDq=86B!6F4jX`l>4$D!Ig77XUdnC%?uf?8Wk7yP}cw?w!$2{C^Q&8 zlqTdLJeVPYpZUper2XuSUP3w7T?p;BHddtnjx2?p&ai3NhtR#%<2KxDm&2Ia8tWLJ zq>M#wv9P0))^GSyuMhmW)MGiDvs(qGHAyxyg?&&GX}=v@(c?J{ zbXj5Fa9DfpNgPca3Pwn#m=Bpnf4qtamz`mybmYFnlK zDVaYTxSxuD&6oc}x4Ff6GbNj21^St$Y`F7iET?oEo}-qpE_6?(gkSO#qbTSi-bC9! z?ZuIHrylo(k^+64;OX|d(kXo*Mx0nMJBhkQ&F)gKqY}5z@pdaee*ffW{*x(!SB~!l zFsfO=%NCKY*UR`)^UU(;aZx_#dMZrP&M&eYe)s;O#@@xI zzLf5wek3cPSbcWU8=%pINGO$=EtCOZV+r))g{Tk@M8fx!B(B@@V4AzlBQGjNrBePu zwT(se7wKD{l-6cU50#uYm|*1*+WuT4tw~!hDX zeuP6kV|IZkFvN7XC;l>W-4-Ke6+Jpa_H)Wp>28?rt9;J=%}S}7ZW{)(teKpOqV~opx z-KY7jSMfx2=KEULXwU9h>{ge^_PUIKN5S8`ja26C)Ee}(iX*0$&dr@9$EZCM{Mvvl zqro+;8KTxWk2@`{M}J@G6+mpVRBe|;q%WgbG;*=rOJO}(O;#5ucpmf-lnYfVMPcX} zVuXRC%9!T;pRrx?&}FATD3e0%_Ut~h$=OFa(S}DRab?+&E4Wr|5nSyPJg{X(fwjCd zhqT{2+wecFL#=Lsn37H$$C`LuRN%lD@Hxa z#o*4_dwMFrZc4Lfv*`2e9kP6(65+nl9&x7Jctw6sk*dfCSTxG-ZH&Q)VH=CId0mF89i<6 zX9q+cy5G?${@)+B4wHB@hKRO~tERKs?G5e|dOEt8&l^f#czrni)DI8G6@DnDl3_n& zirP|-yQ}9U(`S7Z!8ZFz9jbWC6OT>x@t-4mfdwU`6-Eovlm1Y>qUOp0EE}))pW_~; zzkfabRXa)r*{-DsD4EGZ`Tt0xPd(mHOoq5(!zxnh|I71p!*Z{r-n_bi zv2>e?d`C~dI)hunYe`6s|G$Z#z)xR}XD@wj9PoS}~FYy?tERx@Awu-Q2 zD$_L)PNT{k2VVzizR<8NFUqRZrt*D2>M8U?nte;1dS|No z+K&^bv-qEj#BIYa*ZCb~9R)Tym<9k&m`X9k!f$}Od0+F_$WGYKKUCa`@*ZqQ_W;MF zYx+3CBvO-hxUkkGL}2R15Z)jWX=o|hwt#^f3tJrAlEK#_8|ny7)w;Ml{$TBm?lg!J zdT>30sxRRYVH9^$l(*$HhPhS?EI5w1cqqW73V43yrf!{iiUA1o;&g}4b^q2PZ7OiS zU;}W3urRYoM9U2t&R^DcY;u#`)NBVCI=vSQL5F+t(;^@f5JlDDfAou;{O_dhldC^&c^6HF&DkO#^T8UM z1V9A0&UE+w%;IlLp~D+P!}E5GE$Ku;Up=pGX`EQD1SKc=m^TuJ@-3j~vln(t`>2d1ePZV@1r2p4R3+LEOy# z?fcZAEU9)r;mWR9OEgw3;f83QfnfsklI&D|tkv)WncXhtA#VI8zAo_CQ7R9NmrDvv z9@M!mV?i)Zmmkd@Q+|A!?#%;H(ymWuTN>NshPtK9-3vN016thx1|;EBLk5~@0DQee z5Ng9l_Kq$Zh$x3e@z~1+C^xr?ETBLM0JV8=;YOlZx^j)T9pr{M1~^_<5Q%P}WrVML zx)~1Kum{@eI`e}5WcCK4k*p`*vU+~@z0TlCm>I%`vW*pnPc&b#S)>A0{my52OcKxD zfE-`MwPOb8Zp$rbuomC0-w#mh{Db=JJH$LQfPmK17A*zPPjoC|7gBbVd+*z0|3?t8 zFqNums<5+Wfcjkoefu+;wG!~wTju{w1GG6Nd2QyZ~Z3($M$6}&2V4o1!GBz8s?=I= zVN&J7Ly0+hsf_~P#^-jkD*8f{#l>JX?1S6P(O;E_cKn1@!))paOh7C!YwBL9jePyz zlv)AtNYNe!kME|Ng2t~xR41jlUy01xALTZjYOMv z>7E$x@DK#EbDW3$t_*(+BPz+@LkElE70;Yh|JtP$9ixW9S&{n1fh0%vv= zzivj>YVXjf7@?7wAn2HlsS znKuLm@tR?n0;P`>FQWv(!=|OULEF%&fdH&u>pzTDccxrT`p>7&6~o?IEsWEFUX;sP zVwS~3#%OOMvxM|w=wfg(Nwu0z{T`5O^XzcLq=Q*08qFWeYZMT87q@iUuv1OD%GLVI zw@wex^XX|H2%*8Aspd*W?h}+384`=lJ-v5C4>Q&QjPA3bb)}UA=nj|<37p6!*a!VJ z2bCSSuu@5A; zF}O$r3bpC<7v?j^b*z~!{O zHrhi&u90T*%a**&{iUwHs5{pG#g(}v806;W1@$>0?)i>LmBWOwaf-hDyZTJK=#6h< zxh4(}X*7SO|MV;EgODN&Zea}%p!A%Xq7mMj=?I6Tnq9fffBRPX85_QA@^wd+J#stB z-(hyU#FKBS0iL=!|52c#1MD5g1VM1`CI3X_0X!EA2!<)Ia5{MZ%EGR zHbr9hh{t#=hCYRSx?S}z@=n~ki@TaWH1q2+73vC7EHoTdlwAB$^g45`1w9Se2-|Bu zjIcP}H=t%;P5enGILuNjQZ5qzS(yT4-(Q&kQV~cm{57^ID}_9Pc8vy8uNczF!m8oI z?d-m|O@@kT3yG&IDWL!hKvY)Bf^E)sz)g{b{ykC*1wZ+{SuWG9RnQ;207jXm7%7rgr`6J;W_=w1e+m10<5c%+=DnCBM;ZVOUZNE=r zA0Q6AH17fCh65R*6VtZK;Gz}joJ7CqE076u;M&-if8OGKNfB0EFysPM5xx`$upDNz zU_0P@SbySvww}rj?f~^qzlS%1v17fauMQ@yW_0cRkH;jJnzf?NKsUqh>-RcC#vZAE z89skP5C2W7QEB`pE;a%DjNR15h>R-=tU+1j^4tzR>H*YxBNB)=E+?m;nTw$3!=k++ z>;c%Q)B2))lwL#1$vI#@_YGQtUgi!sp9njz>5U(iuo|16KP5z@50FpAy^W^ZII~eF zjZ~VK?K!+yYBrGoErdvuM5O4#HZhxoCG_;%qT7Lu&su48NBMxjg~P%a&1z`sye|b4 zFQer0Y=uUAS39jFm>uk0GaO`^?%K|VLbH=%=mQ%K^m0oASc@k7*V=zx6zOD2#y-$L z`60VtQ@D5q7aI`Z9jD^oC=~luqOe|Z=N)jCX0`GGz8jSBtG|+VB~zB;U~^EhltM1d zq3|X1<&l!$+vL)CZRAd1GYzy?C&A_H!&M?RxD++2P@Sq_C&J`MlL>UtEid34TIJ5q zEGmLr5!7f6O7J7*OJPLO>(mb+NhKE#|*HcZqBct;_5sj0ILrwsX@ zP*m>20d9(3F3uji*bei)kUh`q-vnsa^I=Om)gSWs|DwAhXfANLKSmkVgtE=pY@C}O zW!GbgdWY^YJR*cUt?5+Ee#%2A;_m5}P@9=c5=ChJY{%t-!|K`{#cJe4YMO@I2XjRD zO+KAz{}ytj>nNsj=9~8`CNvcD=})j=3vXl5E@VGjtJ)%R5R)U-(xrIwoO*ua@p|b; zQphO2T)6XvvB+;)x0#tm;8slr9`z@d`^&u(C$=J#l;t>2*ls$YCY9Tt#j9x-Z%>Mz z4+|hsR$265rLLbh`tdG&XKJYHO%faa8&q^#@HZD#Bd1T`9U0lT*z9F_TuNZmFpea; z=xFh~3F5mI7j>xg(HHikPzyg^qX0_dMrbTlk6_7n)23!x$a1g;O8G+ zj?Nz+YJ`VspCaa4rdxhG%%h)_*d>r2bo0;ieRFt=P!xw0ih59P#{i$Lv)|la@l^Y( zTZr2cjOckV`5nPGvX5L#OB4&=pK)dH@h)iD`TsCk?H909dM%(ELH!)~!*0D37nk1v z|B@%MVQdEuWJkr8lC==!03QZlXqGNimtYGR`L*dTg6(?{*)m+7% zNQ}v$qm|O$45pwXoh^yGT-De$AcdMiPE~wcrp`e{Xt#q)VXp+#=-oI!TB~8x9{1qeQhvh_ zUjd|O-%OD~Q3;hrGa|BZ&~3(5opUDVypQ!|4MCxPoOrbv#(bUf+}P%NXltfv6enk; zQq4Kr$Czbx9N#+AhfZoUxzS&%Ho9HhQTHU( zQ}5-Wk6I3^D2FUli+7hUetZuI5Ky(tAWdYbq#8ka=PjQ-wUH{i-x37hh}}ODhaJa< z>jR_NPU4FAO66V~Q<(SN>BR(^5V+ zNNBL5(?~qZdJl&b_VFXp1io6~Or65_b+-7wNAa z()eB?2y~8CBN6YVD*c9sdgWgl%|ys%O4R$LJ`y}!<_~%~^DC%np-^#tqar%V-OTIY znA@j<)WPdVDrN)scX^&YVvyWGcm0JSu+j#_!dqC3u!GWpa#%T34eN%P=P$5keUz(Py#TdGz_2|B4M67J;yLsi6(5vMt zmg$R9>FsTL>R!K5(qM#R0W!^u>gXsxwn>4Y5hsc-1dz0Yw}2|!v~8&g@96qyLc_F)Ac0y@!;uRamC{gXcOfI(l2 zYnpqLY4e#NI)shv@wT;gGvU#t4i-jrap=};?7{8UUq4pIwJ~n?rH2&UPV?Ac| znE5(9M$I9byX^~Dq_@6>R70`0EY&Occ9{jhG-Jb_Ph-^%NVil+=Q{~LaP&hJQbW%< z7k$Qle&nL~^akinNOLXzMqU(Bg1_FS3qN8})L<{KjVi#ssK1YDy0;n9eq=GAxOdFT zX0}r>1L7;^m9wNih)AMM+Lni92RPj$X8IRjtyX03pQn-W&)%fx{6B1yP1v1)G-E<=!Cb>5^}~dS6sO>FN3ecHqQVJ!$5Eu<>}lRkGt-)~m-j$#p1)VG0kG z%HMLy-Y=@zyOGzB{zXFPt{y66=LQIi8%$m>oEsWD6s)l1iro8M-~AJ+rdNvZq9r-$ z-}Bo*Njj~iwKh@bixDvg`q;r%!(e!8ZOlWa`A;Y<%D`aFNvMJ}d;;Sh8AAY{$pjDc ze>M&N=@j$>YtFT}RR#}{H^yvNk2$lGWe8_5F+zJRC zd7UXPChmI~0^Fd7cWSxv7S9jl8D{R8@7%D4Ffon}?yFI^bV9&+w)}X7BzB*5_OETJ z8iSw>#ObN5r)M2cY3HYhIsSLI2n6E!PwgiZd-s-lRcV8cjKrnnn}5!G+DMf#fbRYW zIa56GQqLsE;cruT9krQNw}VdA!#qJaPxaM38Vtvbf31r)*z8eH41FOIr)?3|}>9A4f(nOgsOGEJfodw}7&hXb=bU9V)H zNRD=a0HZg%+Vx1x?hYNtdp#h@>cOwc-)j%$xbyU=*(L6XKyDv5$p*W!_KrYzhqKr#9P(2mi!MecIH~gQ-xk6gF!KO`gOb)@OtZ7)$L*VUbPjC-% zu<0@RIXfY1cL#@s1T9v-o{lJ<)Ia-tlzErl0x+C{+AEW9RB!wp`zXtI=OzGd0RXQzZdLk&h1NPls~~kJ=QAz6cv&xYCK@ zkaAEtW&l(w0w3A${CWxX*3JZ-EnG@_U*rMX&C|z#{&7rufeHu#v-22zeA>ANPA!uw z@3$QQEyGI$Al@URim#iZ<}b9mG?sjTGX)Ez|B!_eI>54uc06O2ZljB`A`UmvZ645_ z3eEWaH;NKCegnVrl6}|ObN;tTGk9~KiI}CMHrzTxW;p16@0mtjN|xC(5x-My{)LCn?do*wA`+^OGi-FV=?*dGh-QET=1vu?)?=)AGonl8X{ zofDr@miV0Ad!*~Umhd$HAYN)EIZ;@T(kRi-$pGt4-AkoR!qocYD;$uZ=)0pCR5<_d zG`jOZdi{$Se283dv{OK>l6waQ;Kk{qDc%w0w9z(Q>&Uu2x|^O7_B5n?8X}QxbZ8@tH>k=LVDUaRds+ zkJc+fddH1ZS{e~2Vo>AC0dQv+R**T!NCL(X`TvX|a*z%I7I6(=igoXq@(Y{fhq)_U?225)$CK;&iqm1*&D(!MpvDN>jv@rk6}LF<@P~mUKh3 z_C~^MkyZg>*dF{^tfilC^Y&W_1QeD(1teP6$6+<+0!S|_k_CRaL3=h*#0dnWh z$x>ceNZL#-?r06|niFYHLYWRZSfR>_5PqX>Bhm-P9Xn>=XT{Vg5I`FY(K9B}+9q`;`D+!T=yFU6kBl!EH8q6|meY%bI(%mA z@BrM%k3aD`7b4zUQzrN7HybSf6duK&sYxI`-1sikYU6Gh;JM>0p-#Eg z3UFoeLW*|Ee%&C&L>3+Z$=C5$s{J=%Elxa;1Ly!$DBor9fF|1uj7k&OMi}p~1)Qi(n zgTVv@=xH5T{%M@)aG%m{^1pf-lpYe$2>IiE-M?lgB47sONW324@=>QdySz~QwUPvK z6ZhmdqMk#u4@&|ZWJqs8P#J_>qu5B?w>ZRB1Wqk=;9fRsgO0h%j*#R z@qU4enYjFGIES0kKFlPOukCD#Zf|T|ZT_0j7Oy?5l@c)zNj}L*8>ACUUeYu0e?itY z?(i2+yZS@fHT2%+iE%k-mgx)O4|KRGfQ^@uv&M7b?zr2X2>gs{GKO zdhU@pQFTB6zx-cs$o#*7Mqnz61n&B2VX5(9;P{m770}@A%Phf$U`DyL%}$mnSGc3T zb>1XiYuMV`j|Q1sKpz4I0$bh--Z!dY`}fHG`50}QM5R%VpB2N5TL?SVo47kjwPH;Y z=(L!AIuis&c4-hW%Gi3A*ySRX;9a==6~p}QBOdHWY=ajGhgJ%oj?>Z?=ij}E5^pm} z26>Ie+A_mVAd!C30Zj@4;s{!4-6^40xUiN($Q^6u_PWG;F1^-efvM6Su(nc+6%usR zHrytr)nDDE2ATEhEK0OU%)jER+WVtKzFhSH67KC5Jw#+GcKTB#XK{U*9WKz~!enueRst z31o-DM={;oER7vN>f?ZhS7kU$F(dbh^i5oe*_RE91({dB9uPgOoA@yO4jZ;)k~v(Z zsY7&pH~RAl-F$uD5tstcN{uu{V!F_I+oK)Jtu+cfHd#{n23CmoBHLu_!QeSOseetqY;ytGr#IyUB%=02{v2ySv+!&rb_S zpS@b&vXb2DjeivSndH0IXX4y=o>i7l@ddA5yk?~Os7mmN%JtRbl&`8^mF1qLJ-*vH zI@X)r-ZStiJ1ISzhug#9E(QjB3pY_P%f0!H`pKI)4^97YEGRG69fDbQN-0%9uaUnI zdeDEpNhO7|dy5lAaT1@vsnIX2Kg+q+g#}ehw3q8}?J)ekMRKvOau%#r*7OpGbvg{5 z3vb>*8gQ`|yvZI&%M^GZ_tCVyO94kk63Ju{yNKt(b8iB#{?j>|GJ|D^i*@Cj{C)S~ zCAs>Vs(eNFQVv6FKNouPgJ1;2clL#QDf>CZLAz0yc~F2TDz?JofX7y1fkL|_{1p1g z@@;mN{#0=~b<*FRh|9t8_hV^m{JW>6`_3%r<>@DfXhnXyv^%GZaY82nN3rC;6&na< z=0|pk$-OIX$3-SmlGdmtKFsMiMJ7m;-c2+ZLc&~*>h?>egfh(zTHu#tr9(IUx8v`` zuORsYsA}(ZY88h1`37qx#*BykZchS&clS>f<4Wlj_!3X+c@5oHCWYZIQ}4Qq2%y22 zk6m-f{pV)=IinXqq`A*lWc2=-4u9mL$kF!7&U|4PpJuMSJJ;lUzg%!}&1C~~6_Tda zlwu>-t~kzP>IGCxxYiv%WQ3!roSN;;{L;*SM{6@zS26FsQ}X7K=q%!oGdB78{I_w< zibE4kTiCJ?j-$}mRjy9hQ{8a-w2y%X+3H)v-&e~0hzA<=Ls3mF0;2vB9zYLZoQByy zT&7>M>zg0*7%l4=IN$Nu-<(H1{EkYLcfNxjJ%k)=^#qj}nsGQpb8<9@-K*GE|yfPvcN|F?MfuFOh9q= zt|PKHVoj&UsQyrAQU;NJ!SPe$>TN2wo%}lHUo6!uA~xl_Yz4d9Ia-GdwP!(ab@iiP zpK!oF)s93-J~q(b-JZ4JBf%QniuRh%7WSX7g*&!+EP1U?lwAJh_ibs55vkW)(oz4N z0BQ8jy+P~=UtK->Wp)~$u^t3J-b~ixN(q7A-N5~8dgy%WBv@6mp0hEW4<7EzhBmV+ z)eaL5`4L^R$y4%u0IA8%!ui-l@2p3%Llx)BYNEHsSmZql+0cJTM&N+=iG=fIl_0|R z=#Kz(3s+o1<9@?{q3?-?&3wZz11Fj7iVi}dRifES3xz=68XH&E0|UyXy^!8oOEkN!ri41*%UxjKbQx-1dilph7Y6 zsmxEd$E%F|Z^n`MTYWB%w=|11-!JHLZ=~>A>aO)Cq*I%w9hUju3}pCSTKlZ0fKN58 zGVdcUQvM!v^-x`qCW{v-V{5tX46I4_e&)FA_YW1NIdxOo#~upPgp?#rdZI5~1;N?j zL5m^-)I=`l=Jw12^R8-x=x^&mmZA2aTuC%^G}wbq`HBxT=ck09a!(N*gdP*7WyW1% zOCb+;N0lVp`~wc4zE?9DKKs@%-?MaZzys^QQ&x(9G<`4D{k6?m)OvU`WfnUvLvFAN zm1{JM6`OdfXjjS1{a-A=w^e;KP|Dg8il1lwNfj7+CwlN|=WlLgy7zWLjrHi$MmY2e zZ@^``(!yXl=kjEyQ9Q%$^p)*GU#PLXZy{Cy-vE`>TJ!dxzr;ZqgA}f4o`TXw>4jZ-;)>>sNUT@Yrc@knLNck@U(DZs~0aJumI@oH-|0ceY(vGqi83hGcWfpBk(;4&8G78mq9 z8&&QSt&ZOR+R0}rlzcAm$!mr6zJ?*84VrvjOxjBnQK8mydb`;gH=7M!0v;Mwq|=?! z#zFDhb2H5Kx^yO8sE$_UiQ}TA(S$7Q4Ce3u*U#z6;UsDlvIBw1T>Y{lPN{GYt%p9# z{NXqMzOPS8Ts8*nhlcs@FL}Pwf4}70&K}r&$x6;v6wf}pfwv_E7WB5`Ovf^Ptu+Sa zw`pJ}6%LUpGDazOFgBhkck}sjq(`8`oCJa3A`&Ko-uL*+%^H`#({r3_q#ix%=C zj^U5FXE7rC<>r{;G>gp+!lBbI7h zw^S!35YeGm-P8`QZjB!B{q@iUiu3NSAF|O@_F}F4k~)p2F#`iO6U9zhQG6Mf)B^U^ zMt&C-X3Sz!VOU>GTV~cvw}RW0?k|c-KtMX0r|9C+{x|wg z&~3qMgLZ=-4RMqhRNlzdeEc=lpXYqgPR!5aYnETdqR+{c%V`K|sE0(BSx*eXXXN$g z4QqV$MD{h`kn3 ztg+>9fw>eO5uH4qh(!Z&C07yT*1(@RvEnoJbx|}ze|200Y^RLF>AZis^dLc-uv zHN-L3XKEeb>}#z>Eyko>GXoot%!>pTm3E!_z=cU8|M|8Ti0CJjl6goQ+V#jHi&v3c zP)ANq5(Z*i2?yooAifOgK+KEdP>We3;-yqnGOX(MnWR7Bgv zb-?Bp-h7tf^WJ%sEhWap9|av|lF+X#*5(lw!oe`#zxN}+HY87li3Cg-eyP0puv^?D zItXf7l96A%?_nRakoXY97tw|(g8Q?Dsa*ip!H10dbe~<4d&2G#BLi8Y^#M5<`#KT} znNu+wi6U`q^qmMt&mS}x;$&x14-Ct+ohw6oEk9$aF;0+u7gPO2ci6=jX)w;|5PP+& zy!LS0DF|FQbPP%eG!thw zvq<;`!C5|7WR)(8pk|Y0aiYV}t$1G~yetasJAAD}g6B~yl|d~p z$Q;;5yCO(kh@yN@y=Z5C*(C9z>p!Za=|xxQ?)VcjkWuG~lvHPr6x%A`i(FRMzIeNA zM0h(^$7fvMO-u+u-C600g;_V7EK&!ozhu<>02vCd?rdfnIZVfc>WFBXuwVTCBINX1 zikX0}Z|7JCZ3uE3LDTYwBi1Y&`xshCQ;#+{-2u<12#~O+#^A7xsUDdHh05skRt_mOOI5}nwgt*pjaXliv#pF$~E)|{U(7*&{drFkuN z2X&=h@JP(51Q_CwpM5k98o)(FpOCUxyv>3g;hzb2;KaJIdp!UOs8(8HK}lt#+gIm#{+x~|%`{BOA};OQzf(~NXr-K> z!4uLF$Kf*Rr+t@Qe|n5!v3Ru%y>e6OLxb@-Wp-31+b0OHFmz%7T0I4>p)%ovKtEb3dQ}R|Kb|V zM`ZY2( zfsQg{H+)7>mBe`+2vK23MWl1#zFlFUgRE>XbJ0OuJ~M<>%a5pm+HOsZ{J!dY(FD#2 z{CbF{B!X6#bt9uqMvCk5<0NsWvp$of&or1fJ3M}V3zY=}Ut+E5eYH4@xZgbTGa_B^ zJ*xtB6&y6y`>MF(5%>ec%JUh+{dK}Bk@Ra7fHoOko(@06)p5Ey-RsU&zwBvA!S!v_ zYokv^co!54rP@SSX%!4or?Z@ASXP1sYJvSnC_3!XD^=2eHp4=Mvx*6MSP`NQ4wolB{)Lwovu#cA^psQ10RH zKDKQxk7GbviBl5aYL|IR22!k@CL*QiYLvFu_=h^NxKu8qRki-FH##e;Rp2|urv<0G zn=?7x{6&$k`lUQ7QXdb$QfP8lhc4>AaxKV^C}VoAKx6uu==>xBdDVA00f#)9Iu zJ^g_FuN%RbEoqNXeA*3Wf?f-{AD;`;>n8L?nS=-uZHtow)WQj9^=WKx3H70n`pAyx zCvoP_LN*?k@}E=$JcNBy-(}Ky6wLH&P{eI}wR>}+xzTOwZ;#Ea$br(9NP=H6NL{$jUp6AXDCzf|OLFs*oamS*{hJ>6=6x9^GWX~sDs-n?Or z?5k=boc*qyim%eAcV=t z=18>056++BntiB+fl^>$os4U+}JbC>6qO4$dr*DB6X4mCeI^LBlV;uV~WrI zaAba@kUfi?rDTM}R`55_frl9-B$`^lUDIgJq#WsNYqY10n)AWVM2X7|HkChOv2CBB zH4sS|Z6;8H0iJ9YtzzG%w7xq~!Wb|45;vSG;IGK@ENV>riJtFRe|p*bDEhjYAOF;fWzQft z^!y%~IoROjyYyUI-(LI($Gf~1e6UWF+s?$F1;~-&8QybpVze*D*f%K>SN*)5pk0?G zwJ(W!Ox({sEeMfFp`#JM-Z_v{8!ewKD^?2`lh#)_$h~YA57}NP%;TPxjfC4>!^K8En?rw@y9RKS4y|{iJ z(;v~{*IxVe8*}H{>lJl8^z1F>k)4%qXFLdSS{;VZK_%x_u(=h?{#lYLQFBO(au{8{ zPjri`ejK$fP;VlFlne{)MWF0@$M;|qM5#_ycdm(?CA2$x05V%`y@K@Ds5kG8`|E&4 z_q`d;aZwlacQ^LTQY&U0XWLGWORa57q0+cX;zC(Se|Gb=-Vdf(n=@E&8lo_4o9S5k zw$_pproa7endTIB5Ed#xS)AgA7A?&`XzpF!B4z)gRiMGkZ=Gf$z~=O`B{7E=!Eo3H zNr|J`n>^}px;BqXf6Uxmxi$}7b9Lr_M%K@SI3V?{m57{R=r9^R*>#g-POu!}@`-RK z7c)~oyORfdb1^7jjY5GX(Mn&|5%*1qgT7SxOJ=e;jP3CvOYm7rZe&h4MyL*-5I6m7 zWrCi~OJUS=O-L5S``V@zO(;>4eA4?x{z}u7nmQq2h9*bB0$WOi4T18oY1Y$}$I+s35W4g4<$0X3hyd{b; zqT%5VS>z0g?7R7QF8aPJ+f(wZza(O-_I;8W}|hF*8ug)3Z-fv$z-xH`1)f|KHP#AtIVO z6w?cd8L`?XP`2lkn}rnIN-}{6!>1N*F}Th^rq@>qaL6K7;6uX0Lj9mE`f!Pw-h}<9 zTK+pX-xb54T*}P%*9jNFZplGx=));kFo^r=7rBOp^TdZA2yhRY#-|HlV z)j6O=4?XH2gk{Xi4rPeVL-_4x%y%ZsJpBIL5~~xQ;mo}NyIprhU9G@C4bmR<;th~^ zfj)nc#{TWridhN~eR{Q96t8X2cV^z1XZGx8@8`99tfB~adXljC`(v1}BcxYB z^l_yEpm<_d78+kX*lp#-(;Q#n7e5C>C;iZDd`LvtSCtOVeWOOo*Fd;fd|$%DHRbYxfdX2 z`bXCO>V*~EAy8Bh1;b?1=2^1h+U^9QAug?F`sYd$p_w`vx@1~oU)2MB@a@Fx*A=Wb zTcyZg`r3x>GcXH-g@M-uE+SGK*$xcW4$MlrR7#YSCf!kSD7^`v3LCmzH(SVU_&?;zA~cOi-8D(|)NP>cNqnOPd* z5CP}&iarf48`>Oq>f0*Dk$0ktYrQm0M8@0v@g?OZ{G7s<&qqtcnvS4aLt9>z3?uRX+jOoh#i zC|W7H_Kq*%!J`%JW=}|6%Rcfm9W+lt!sJe+pfA~I-VU54L9?BC+j9200pYE7d)a$LD)|D6S)=>Fs7%18;8h9BV<3l%3F$S)MRhW=PDu%<#*F=t4vheIK{USg;j^bMmxUuCL)-L5QqlI zm<}?OvXv+V>r{$4zj<2>l4{K+9LF~pc)ZtF0V0LW(}$$!hDTt<*3O~6-9S9`v!b^< zYk!w=;1MpZjj&v=;)OF=vtK{>GvQFeltH0e)L&=vW+E^7-@Q;E={xrvqH{=PGS{FI zenMw6)W++t;*Q8w5Ah+od?^_xQB2Rs#jf1?rE{;bB@2>CTHc`IoisY0xyjIB`Uv4} zEYQBf$`~VDHNd7vjQqATbfJ zc909`s^|L;IQ#|IW92oe^p^4CCD`m`zXI9~fgnBA_|(g4=>4BsxHO}OWZ~TZ>o@G4 z5X}$7ca;eETT1u;5&nJ>Z1*wE{y|LG$Iyhkx5M^)&()SL8nA_rOE#@IJ&1nAQEL#> zT~f=~?m&Xpoz^5=K&e&bZ-96Odv^iOa5fvPFyYuNZSpJk^HhD`)|C?Ty%9Py@m^<| zhx}5plyAeW9ES3%d|ffi*oiKh2d?0X{7t~A(7*bO0qZwNct_dgI3SFA1 z>bmM>HY#y$9t@)p7D-@qGiUx8%Sz(A6i5o*`(j+Trq0Huin<%YH-lAfK8|4*8FqQK z+3gz2%u#){3>6yP!`2WUS?RqFD&J1pJv6Puo8ul8+KQ=qp68&5y;x z=75#*ou`h93~mIXBduy{-GsLxJhD7gzv&OvGlar;HZT4F?4^)d(cUdwwDnt-QJyiP zN`JeB>t4Io33nFv7c<;K-+c->m$tqBG*8t*U{wHq&oo=B=y@$bzH;;vq8xKV04u&o z;<>^f?-(->rT_N&_EHNxaQNIo^A&Rt+;ykb|MLdY!+{EX{DsDLxfve=1q!)V-o@rO z$2nE!V#RvHy;P;y5YWM7Q+^Vv7lv@(lCg?kcs&L)D zl=XTrPX^z<6U4a4bM_K9k8yVsk%u2U3+d4VonO2eGw7gsR#9Um8h8l-S*7PIa;2P1 z`<{9i=+~BaO)8gjiK+f>1PsR_-n(gMSWjksW$3fnDZWE-4L=v@W-DWd+|QF^g9Gkp z1EWOgHmv;S0S(X1Rmx+`x$<{lw%C38-?N3ta-aa3cN1119{;ki!Ti7Tt*^ zts%5E9$O3Zs(S%c!uCvu04z?#X&Wx1QUhKnyfPrL$x9X`qMC$LloVk~{m)g>XgwyD z5XS(SpUu^7kL0w2lF>NF8%)YW)}p!Z*ImAZNW+*C(HVIz=h7H=w%`HnG2SK8WDPPV zZt)AjRLrtcw2JVpV~`md2So*@)Pr~kN8b7~`;$(6gvpf+3b^-@u}jg88%OW9?g2oh zf1T-J#mgSH%n*M&r8q^9B)HbMbFm?CdQHuXdR7_Xwh=E%gR6Ucy$aclyW(7D+Y-n)%g@=*< zP%c%P%a(uDpQ(f=P2OxHMLw2Y=2@(v9-5o=pC1df6TTxRGAU>Oq}g(#S!$;YF*h6_ z*A2+&^-Br(8CGrDqlU%awAF=;+BAEU?V+cSUE*ya8MmRxNkpH$3?rv&2|JVh3FbX9 zh9NmhQb{J{tRmbCIomlLTq2ht-tm!SHUQh-p!g?L4xJ+if&N4c@G$wx=^H}4 zXCoKm-1#@^KCY-otx|yt%KhgBHSsi8qXZxN(}Aq)?YAE~1p~0EUkZ@_Y(r__-NDa! z2ZCR~i;9M=|M+$4(;8&NdHI%yCq~kB{nVOI01uXriqG(^jxU-RODQ?^h~)Zm{S-?( z+x01@5U|BBmWR{{Tp1Vax30hBdU1u;)#5TiO|@@}(GsbQm)R(V4C=bmJv~z+E^NAg zr=o}F3r)R$6M#)5{!;t*PX9_FZp~mZQM8%1ULUXgUUN+%it)1Q{}gPzpa6mmH5~g> zS&4r}7OrKyvruS3|%t$313RT$wRnu3|> zLg;I-XHI_^w{O}o4)>+A%vJ~Oy=lK)^r`t^u5K`n^RnF!;{;z!)t#JIk&lxASA5bl zat~Zn>A$Y24MAfs@MpZzmT0_$?ilvdFm`)}sofMA4WMOe|Gl$24CD{{B;-gl%1;ab zplB>*lxVI+$wZOkd|=U|)%bTlF<7}wA~$B3y~KG5&+ww>J5|&Td$tJ_61HdI9naMN z`vnUH{HVSUeJ&Y?F%MNdm#`W&3E||U>l?Ryg$eiwK{fvFijzD&hDmxKSPf@32bUQ< zIu2ql~k9!pM?&Nm>?MX+MdRr^(vxH z2|=65N(ibuji>PqI*yt%z_Ds_TJ8&!&WhJeKiEvw{p^*Ub1u-TdZ+p2S?4=ubPY~O z<4QC!Ovk@SuVxI?X|&#q$(3B48q;cUcc`y6NXelS24bq{KcUjYUjt+>?Bqz$o7+!U zhZtEvf*RTg*-48yyIK$r1cug{0H8gGXbgprn|9%gvbQP@UZ;8Z;N4V@MuT$d!!=f)P z8_ov3(x4GBRDZ%6>>*g}4eKBh3_dQ(7QhXB(6(;L>6Elr@~us{6RTF0tArHrlY7`V zU85V@#j4w?BH}tni8T8zf`8A?b&y+s1fGDtyixvb8>FCXe*SHXJIrSi@#BJot>xa- zVBdR%gHJeW&8LJ6k2VIVs%rFX8(aAvv)R4q`T%0&6llQ>*kF-S-CfapRHAEEvyE)cd+hxH$L_{V z;YXd5 zGVQ2@b zXQj-Kn;W)ML`?!7rAq(sIX!l(U-?q723+FT%avhq4F_RT6D??2awKz~#{?;QXgd95 zZ_)n}WKcWR-cSByA!K(1N>i@;lyCGrwXoYxV;}7&IKpPXkI!rEeTwyNC9~6k>}I#q zdb<~ARrxu=@d{e%QqB=yvox|Z6j$97_k%aOwKt>F(+bGccPC1kbSh$LD}FdBmWj=u#&7LUx4j!H(l&VIYkk^UN8>pu$l>^D)lIpC z)%tK3ZG-tb@-zS|x)pYiQyy+#rG{%5pn596_)1Pgow z0br3C&yBEi?a};vU7Ho$`SKi;_*}XZ=^X<^cr8&tqdW0J9{Q2glzG$fZi@WDQnoGK z$p$F7Uu4vzV6VP@f8(&3R^IMxog3B`9KctF={QKxMnVR!7~W7qt``}&E zii|40Ga(Q2*gbB!tcopNyJA@WVdwRaep{bcIr9DM&-EmItJyu*&_#XUC?r2w>Fw>; zXv0VYTLLRP1~I#WTiWI;())XzLl3coRWeDru`@$9=Hlc+BBCNiqC8zJ3ii zS1_KyDN;reNmHI(Fj87$|I%kwUA^`E|jzZ_R#+l$~wU$w5IQu7xT9%lN_KS)jp~+3Qs;MU5T3l>6=8ZJp5V9ES?eT6~Z32p3n(+IRQxhvjQ{%-5WQfa+ zk~f;4UFy=%mAQ>_E-~J?T~v!60;OCdo0B7BgQHje{@+W8%^NK*QWe^MZQ9Ry`b&@|X`0LdlZD^mFWJR< znLc0dWcks?z(+^!jouB$(`vXhYoCPb#_2kP=N;*(RbNlEmg(F=%U={_uh$_1ZB8BM z+2L~~?~M+sGir1Ozr;D7^xV)AHhO8mnrfT90JokONZjC)MJh%!pFa*Z85DiZI6+pizsm(4HeXT;BGNbfU)6u+$>t-ACL`sMR zISh^V-Kv_BwohDrF@OtMtGG*5I01dUK!HZYo>>_fPTx1qjT>)L?G>uF9kVWx-}{g@ zl9SZ&x=jX`dAIhNM>)9uz z9MFMN>86{#=4elch6rE0p~Y*Tjp#$ycdoO|ZmZMBg{@=!bz#Z*M(#;P2K&L#U*_>x z^Q{737uH2e@s}qS)pnum%xX<1vkX^!`+ZN@TrI1r;t3S(U?5;W{+!D|~v;M4R zK}{+BQ?(Gf}q8;LL(b7askc(SaQ?PUl=bd{prVf5cqB_}b}PZw8^CIzD5<2`?jT;0n6>{9aQV8+Yje>z9?w{z%g9c;j$ zv^%B-g@oe$$j%Xhd9-C^?41nk9mKII@L0I?}3zN~&istRV;xG=6iP#4?d z=@Fo*SoA(^0-vluld?bcdudS8Yuvp4v|VxPRx*0Bp>^jSFWLH zt|qrzP1TYVY;&%{E%K&hk8}Z!<2+0Q04O_50RO%?>AA9hKqffSKdR>wozi^4lOi<|3;%53#8);2HY#{JfG2zh877cj=UQhq0c&94gS8 z+gm!HV54VnJ>Kyg4S6c7H_?hnq)&GnN4|X`qVSknt6<}90JhXL(_U*uGe2&xl;#H@aZx8Nrnp3s^aM6oSQZJPx@*<;~dh0JPr(DDmbftf$#O98-_EK@J`av1dBU1FXG6xy-gNOgY*3N^#J3$9NJ|=w308arz z`O}KV-SI1R?!gUhzNd#q+|Gp$4;V))U&pRD`8w`(e#$0CW((#WoPVMej}8Bp?3f>b z{gCTK4MYFfVF1k&5(1`?MvzC7blcFsqE(p4y0q1&SOXqeH}*xdz)@_1FQplXByBi- z@L2|cXZ*pRIKu=UELcNO67uWn49yG|8(4uOL>W*N5{w2fK`YSfrL8n!&`!6RzP;GH; zQei)>3y|d+ZBabgj7&rJY^g5IP>D43PkUkIt;Wi8y$_c2qZgI>-vH6_5c24EmwwiT zB_u$V;iVmGw`IYdVi)`pISLksnM&d?4LGm-Vg%g=YF&eh%eY39R?>taoo5 zzQk*-RZtYw^H3_Z(odk~+`t@%i}%`(Gk(2I>a`7Ydt*=Tv!Am}|J>qc>qQNxy>R^- zA^T6j0dgdnBiqY^Qx}EfW{tGfy)u(;a8fY|iI$5wL0CkM{p3M5x_t(C74Evu$7$!0 zv~j>objn)3f7llv)0@?ou9SS$&-L4cPwEi~`tyxzma(odvFK>AG=*QUjqHiAfQ7LO z1ULQfJ)?v}ANAeX3MVK(d+Soj(Mr$INN@K3RF8!uNuXbDb(#5BlRlaO;`H~M(pnur zAKlUmq|mGArlz>7dXo0PX>Z{CpdE&dp0(HHT-RO!#dA}d^T31M?ZL+r;QZ%^QBZ9H zQu%UuJSMPr{QHegUC52t3ctQ2?k$4ka0)C5TSI08=jbZisd3%+L>(!%b)Cslb{qOy zrLJZ&Frl&qjm5%>-tpJ+;bSF6ip-P-0`Z*~LOe;ZJ&iU7S<2lFFUjCa7SpWyIZx=2>?VSj6p zFjHQ-O}UH+d#y7Q;qy42YakCd}ZktM%DDGMV8^ta-7A~UP`o&R*p;e#(t1!%#Cwq9% z`kNY#twH;!aSu0(V`|snAP=C%yx;%?&|_d;(jlrIeWP#1cL7J+!Rb0ys5_I|=ZB?bXYS#>SW4 zp}3yW?ONb*0WyG0NkUTY;(1Y+@z@A(AjqJ|-pgQ&%g8olavV_E@=@Opbea2J_H%4{ zJ1?MGE(SoULs)miuK}T40u+6-50X@-OWWTge$D(F9oaO&x&vg#54&e_6AT?U?svCc zX*&8H#)<`YlroSDl4CB)^veTy2t z;WyO{E(@Z;ap^U5Y?IQsC+b&^ohaRo zhK7wvSu`ZxtUcU8Hj~QkE~vkP*}at1r+7G7Y#?WGys&<^AL-N&pAF>?hw2&n;L73m zPrdV*G&1{v;Z-KN_pK;b7cu@_ zunpS$44=A+257L!YA!LFjs6|8$i@PSHA2>91yMr`R5XIUtbwA06eZAZ-=}dXr1g6w z#3sCyAVq=5Qa_3ZRtYd{5Cy_Fnhy->U2QCiUW&+PU^6ZJJl9}k*L*kO$i_aPU|SYC z3~i%D*RIR06FEa}lw891s$BFoqGY@YaK@&j0oaoi346bWzui$uC|$rg1_bGf{Z*m> zk4Cjkhy%zj^*(9=5}14lsW2I1VY1FXgsCv*Cd|l|3m+jhZGST7C+h@B_1i2xCPwMV zmkB*B)tU_;hHo9=$f$T>ZuBU6Drw*c`5^HW0CU@m4Mezh5%Y51+>$ZzH)mD@ zX%$9m;~`!6^ryHCEO1b1)Wn*5eK><$CR22x5m!Qx5mxEe+@-50lXz37Omhyzd6WHx zMMB}6jR@MlC9pJW2ea2g?9xXvy*Xu_LGt;a6pP&+aGnpvWBumy>o)&q$^@}T3)v0g&7jW8C zg44qUC;~La@mnT=%E7>dmdNq?>?M92C@TJSbXg}(=FT+*ExY#lsOIMI#=ETPtnl?Q z22}jzi($+nu68$ohKuU5c!;?Iy0%%$jzRjmNzp3er$J6;FYr{PGtPm*vMa`n>oIfib}7+oZhAY}Xs{x@-~&a2}Y z((?>&cRmIVf&3;r*DgrXD)q!POEJ?Vm7Esc5~K1^m+zBrQ+&KDkhB0K^V2QC%9Kp- zX-Y^hUJ?53RqOOMevF($$?-UU*cP=jbdRkXcl^?>k@%C-Slp)lAtb(*EzC~ZPQ>q- zv#EhjY~U_=ms`0sTBkx+&H<@QE6TZj2AArY;N55uXu)#o;+twW>6durxqGzcr^q*m z8z!6W8S+aO!PSTkd-87u-`06Vg15c@$;u(Xp1njL5{xaChZ^ZClPDj>KZa1MTr9n} z51eT1$__F;DzgD{R0=4aw@<0rQwq`MPGprVQkyaSSqsvtKpLq(RcwSN_z z(mZ|s!;{OUa<6E@x0nKgZXhCz*E{54+R-2NNziva_NrV7y;K6vcEz!Kb5qj8?`JeV zXFLa!=CO}H+a+!*jE`X6xr7&9dF(g*N4Iks0x)#89dL!#y(A!-05CcMrBum*grsTa zTS5a)AmAHTc_83(UFO0Ilhl=OVv` zB_$c2zcvzjCT8PSCG!c-8xGYyX^)+bU?bsV$D|5T#%4E@(Yr-A2|X=MAzTOPzYjwP zvGJT?J*hh({=nc6#JKtO$@}NZWYZNEj|%_`m;NZU_?9EfKmdcOi1oz}>?TMn!iHv>YB%>WO?&_&m%E&;OD-{#Sgb zG)|z*63R1C1e>ivOx&m7Ft?m|epgp@A|V0*Wv)mW9qOEYyC^B#soQWS?a4yIL%CT^ zCpwd2ueGxKA7(C%?DUBMqr*743D?sxPQG(6qz4VT0gFY$or`s@>nqbdbPTDun8K9A ziJ;0~xO**Jmp=b;L4daWzLzr!Sh|n)mVEzc!-4sP-Jt6z2n#SHIyasyNZA>R!zl84bdH1}? zNlXgXY@YWC-Np5dhAp*(_H@+*h+H4D6Zh?lTd7iZ=~Vt5`fBn!&l2!tVOJ?E?Hy3> z*6l*(Kh#F6rCs0TDcaQdEUx|0!#Ig7h+wdYq4YSODJM!KTfR-tXCqXSMY=~jkWGMR;kdayFjXdL)dzQe z1E~f#^ADrwj4Hh@E;)8<%t;8XB%ymTA0VqqOXUv$@N*|9cX-jbGqFTkN1H3<3a{qV zxFnhNBum8Z-VV1-7f%<_s1kRhXNYbHk>WADXz~~s6eeZ+<77-Cuyp*x4q9`lRtFa=u6MTjpzgZ>Bl_RX*j2((a4Sob#3*WNTaxmP3~9vEz#gJjft zY{`LC0H8@@{7=lyb0Pt_lELh03_`2((_E8P1ZYcR)hVttHf2%_FA&a--p%uY;Cx{O z9n5*npG6aLX7~XyJ5~m@9<=$XbtdHcc9rGNav7%uMCBTrvW|-Faa4C`RRwKfNExu3 zuI;`llm4WxjJfTqvP-PA*pHfd7sx!1gRoCR{A?(-^n`vWd4O)Rui;iWsV=LpG|LP>6iU@; z^smSSKyYvAM=O(%4yN!cC^1kNsB7#sT&ODtpmqWQMkd@ZixRUdoYGM%vlcNzPS%Fw zr)0qw%m`=4)fuJcHpRlZP%X2<8J)tAGv{X^gJ{lioo@~YR>F;L#=d!iNN5y4 z3hjglMXibeA7Dc(RlFtS9Q6&BJkEn6gZk>|1NJ5lOkCelE>Jyb0Uw>4`bT@^EZnf) zhgFComr9l}ll=-`i`1OS@=IDj6B;2l%xFf#!A$Kf3rg87IBvmT3d&eHi|b&eX_BKr zFJ^wd8MM7KwB@|LvKbDlPRxk?&mrT&tIdf=W#Fh)Jv*P2=9zYWwOqN$Y)p|j!>2^# z=@5bXat24#2eeF+uXnaXa$|_2piZA#q#zMH3>cCd%VAxSp~wk@5TsKdlfzNE+AM`4 z6@5xSLA0oJ1x6*d)i$su5{g^LVxw-;JorMZdlPt>xglzk*6vP96TmJ!0ZRX*`ies~ zL^?4ktz;Wa2)lkJ7T9x8KijJ%E2L`95xQ2ve)-1@< zUaJ(-DFKLq)7vloC!-^G@a>eG*A<>GYM+HKCJbD-|99gA{2rY2Hv_Uv-?TFaLl4OT zbKojj9ZrCBl%Snlfr$ChGugmHLKFSZF=m)T5~&<>SUTRlOCc&guk=*?a&3bUTBoqA z6j~7;HbFucvKs0JTuza|_%^0%{wJFTB0wQY4d3k4GTp=UmbKetfsY|MgTc$hrly@P`F#Ho-19=;AV|6s?f7 zI%Y0kSE%Vs{M$cm&COoo3feh`wnHvxm_+Sd6T$Nxv0Yq5ym}icqV*b% z^4Aq6CEitu7jiKBp`9f5VsaGE0F8#!qBVNv)l1lI9JEm}XGn#FKy@)Edev6V( zR+`ZCEAO>S!0Ps2#ciyfF z7PbWnJH93}^Am*CkV44!$S#FI=9I1(tL0EYD7ac~Jpxeku3vwqN`j76t6{|{TugJo>B$-+K?_eVKO{z#IA=;E=P@1!FPDO{p9wo6h^!u(XoxDvw3;FF} zDwvk8FA;K+)a05oR_1+0_Dciu;?gi?t7n?Hu|Xiy9x+=QeA=+bmYFZb;nE*| z%|3Q>n{qI6@o{7qCFZ?XR87rMF{HiLP05*o2CDyN{wmpN9*3Dp+~PV}g2?gClH8cA zI}~MT|CvE?=YI`Zv)kn)*DoK8aO>3H@7^wq_R}g4Xgep(H!Lo?)b}>Do(PqQ_t@4X zt3fHU^tS{UHn?x5z6Z-&$jJackEw%dgD5KOHzslPy zqRP2;5eM(S)JD96Z{nW{8DX#|+xz4HN)y}=b{89G4gGNxVGQJ2PYJ59oY>k?JL z>3Lp8zLWLot(6ky7e~)V67}T3U4EvS@y}g;0O)z1TK)N>H`pcdXH;Mtj{%3KVW*3K zL6okx60UKT$^HS&9<1-NRM{IKd5A3HyPnZL;$QGHv4BpG%_KAnd*Ts`={4=1)@j^ zsS>&;27drQLA7HCV_fHHIyd63!6gr_HJF|43C!$&gnLmX;EgR!TcC3s$OD_Xjm8)5 zzXK9Qyq^!=IISF3*5LYA85;BN&mL2TUyyGnP@n{b#$#?v7VxWqEYzS`hwf*M+_lqV zz;F8IWZ&NTw~0!W=7#hsm6fn z!(W9km^2&wVN4=rhVpfKwT>^SR>i7>1xobXn~gWZf7_$dPVc>q9yJ zwscM14}oUjYkXxhQCaEKSIn&o8VL@K-SAZ#RvF81iP|GEtHHW?HF0`4vmf;UBlsAc z9F-`)KEWKrI7b<{?~M%?>8%%vtJPR)7U%#B`|CaZ{byBi#Ag{%jphKLSG#v=r0i^1 zUje>wo^=|JVNo zZ28Z^|Mh=@KmXI}i0ohg&;R#-{QrObyZ`O)?GtVNRW@Dm*S}EipHKfnpn6=lf1&)p z5G0+ZzrRgdEos00Jro<*1orpiw<(+A`_C~5grNTgg8vH&c`)%WltHNX4f-2F;pCs= z)2bN$twH>62sH4Y^fYgVZCvYrp)B|=4_ncJzhEelK&ZeWTvSr z!Xi@}a1R2Gl7FKF*!-VV$|xo7 zkod5z^3x)>@lGB)OLSAy=Lml4y8H`aCGfx53X9@*&_5LKIN~SPnX)jwC&%2XO(^~$ z{i%GrkHAk6-Sefa$g&)vuh$tzscrW#e?c>#&)9;JD5TAA^Z|z>qyR-}8KF1WvrGqh zEIB!?V9yO~g(&EQ20IM#R*w?H-P!Uj&})L0l;(R7>FTXUeWgtXUj*2Nk|(ZsiV;O zGZPw|#CoTRjdDKhymt)y2K^WxoJoIm^{KyI=aAsBg@(3b>*%@HR`cm*WPmT5Nza){J1hodG{lq z9L#6ok&__?f4N9}Xi~=H!-KPt^|q5Tf0!UW2tV@B#TpbYm4j6;WQ*~~JA%$doyktt zGx#ia7wdEzI23$gTZ`ST99Ar5u*2pD@ZR#CLbI?*TptaUua8RGqFQ4l zI1F?#>)Um!M9>}FA^|vx=p64`@>_cnyzw~!FHe6-W0Y;nM_;q`@ZM3!L;=xF> z38up`B{3hzPq5<>+%o{4#-KWOb}cbq+RZ+6K-?R zM2>h_whw33?(RcG$mx(0v(6tep!!RE?Ku%``5hppLsD>o1J~{S3|ILc=ZlD7)D>%Q z`{vaYu z{Hr|h_wMQem#u|D#Zo+CIViWwU*8egdB;$@&aINqX!a8VW;weN->%QZK(z2@z4RV4 zS_P$J6E({jce5K)7rN(T-Fv2!+`U}uqJX&xg(js5_KWx@F?sM=;Cb?bqU5ODr^Xb% z!p!gV@(#@}lNL7uHF;A+3uS&;CZuF|?sVDO ziDMFiu_d=BLz3?_e_~I)xRu>cAtsB@>mP%R^BqKrgDGc0I1pIpQHWw;or%N{D%|Xe zPm{YQM@XAn7I=R_Eh|;Bz`SKCwmQY|OfCdz_Iqr)Pr#d0CS5ti?$a_Uo!pNt)M!B0DD|-x*w!+z=plzgI)?MVvJ%TJD!FMp>gr z?gx;0RjLLlY3^AN&cyM+q2JG3xK(K);)-z}%o4ur2czUZ#Q{k23ZZXvIksGIpE8@XE;d|+;q zZx`LMOLbH4^Z|EjQpoX@7IqKvzG5KWLOaAFlMI<9I)#x@DV?NoMwiXc{+(Eny}4Jn z*h)cq)9ckz4dzwL)z9Rc+^crhL#e<=@{U;1J%z#${15nAHe>5K*zv{4=K#fH7umYz z*h(_Ae~jD_zg6K|JH-|}a2f_2k8|T=4CM!Q&h@P5ld10z(v3%FmOv+RHE3AXKF>F% z`lpw0!I%3U;juzH%Jg)dn$+h4_v>Y{*72uG_Y<`2d);+sPxLbcpphW=BUcy{lu+{6 zc#fQRkI;plIOHVtWNz7BBi6ekwSMuBmZu#Sd_p$(R$WZ2#o+xs|1}y%Du@j?KR;wr zHEnBGW_QZL;iPIdpf0L>%H_2mR73m^BAc_(vD@t;ny})Zd$46rQ}nubmUWZSIdMNM zaewq81Zf;?N{l)9%KA@fFrc02JUilpVK+N?uninCv^zHh(4;UF!WIr@ab?o(7x_qG z;V{=pqO?Q+9hb92#=)6zTxvnm@@cz5uG%hC!IuMc0CK_sKmIT5aaH7?V4jj4~ zItd(B^3Fs4iXPF^+1!xle8EJbA?_Bwr4}_>8^s3A@3+jllDE z=6NHZ!t$7Jeq$SfPlS}Wtg_h(C-2I)o{+soF+p*+e_Nt~ap0}R-3P-|iAv_ONJ)A= zt#yEf8&Of|kHVlm2+!-a6`_c=UtDCLE}yZi3g^zSKr>)R{rx>$A)C&({eUex^y&8A z@G-Mo_-LH^!Qi6th=y*U){&%r2bHo(LuoQnZg6C!Gbw^Ze0+xGqL!2WzbZCbSD%Nl^DqbW)Wt2KS3mX<0~O=NJ+KT#M6`*WBYqhJaLbK?Ep+CZ1qXsMy~3D+Tw zc-&{<(Cq%$@caP|9{?Q~H0>~5D#6w>$vUX)z`|JdvONjXcmjmh&)fEHI#xUZf4&%p@V9XJMOi>)?oi~ z!@ztHi#L|fDD7x15GY)6Zu0S%&u@Re&+6HNBY=oAaMFSD6~;|oaqyIyevtTU8IRjE zkm%}mCy)|V@;y_`EvhjMaLlX*N3Yu)5Mz#3@2BRvsUK|4DOm;{hDEobXC1){S90s* z!ee_DBii+DLLB*W+UwdkaF}0HUGGy!cU&MA~Y!W~ObQ@5iFMQeasY2gnrQ|-tW4{CO z>O4C?xNs3t-%mE_;Wys`%vh|$cST(b(|PIU4PYs3p;D^c65g!b1#CsGsq`MDY}cAS zwLGutxamvpHrCVMssg3U7IjZ70Tel%ejm^}(WagM!Bp2@`TTtPNzU3j8TJ^2AlhL# zZK;T_5a@?}lIPcZ;dlraKdzFy&I^7*iT}!;=@U+4sb;*aaAL-p#dZq zB)o3WWlBjmFIH7(RYxF*0m%*U~kqr@P-gCUaj_a zA!vtaGO28cYI&0VSiJ*P0>AuvP8-ZT=j~q6HUI(uy$s%DI^e$7im{8@NTrB33gYnh zzMZ(*aOLb;%-nMp`3srU$2G|XryLy?X_1p2OjxVZ=vupifG2pu!n=1|1^`Fks*4E> zGUG4Lp116taixhgTyum7*NvP|zp)uVDumK5Q`My1ED7NTOsnn5#3vv7ODRUap`r*Z z@{41ct5QMM{CYEUxB;?DyFL*_>NG^Isr<2DxQbyK$a>i*zji6dlSe~HLQLQ1x8y+% z3}l?#1OD~~7Y<^pB4EeO)j#!CKQAhTFK{uCb_n8ifB@~_AN~y(g4o-2;^2&B!ShVo zAc>u{9#7_aB5>Wa-Q*km5K?^mCF^lgkH1*bL&*BjtWG43=|vpGT6aJx(;5KagheUx z+Zasx%1~%AWuD>oE^aIreWS%;J}!pLkh(Q&7c^7lHyQS2@T^Wl9r77Xu7;oUO6U&r%z2vK=EFIx!e!qs@Hp?$@6L#uT+O8ZG8ZGwKcH=IPcs zrgg!StL40weMOKtmNY9E;Nu?$ATONhkoQ{DbNnp={aX&ViqV0#!Ne9f%5^z-C zEl+HW zc1iTXF*BZp;yH&hykO)aa;nh|Zlitia~vpEY+7}k=U1()CNO)p2pD_5KJTn-LP9#8 zbp;3}Q?Y|>&O0Uw=Vd;%gZb<01Fwtp z_RiOr@9{hrU>R2AvhMnPg1i-X9UJdZaTG8q6y@( zNgNDPY++9VKWr$+PAT9g`Q?4&UrTY1r0dkdNEOQ=p3Bd?A&#+Po*D@t++*vI_v`6- zHuVf5VbG2_$!#k-0Ljq1K7_zwHWyJ^33vvfaZY*l?JVSr>o~% z<$UO37}(C|&CixK{iTONjBZ#WIs?JVZ%`udCZ@hCBkn^wQ24xN<2#o!zz{npaLRFf zPThjWVvTB~gVYQJDvrqWNE>ITtomHPIh)BJVS75R3XFzmD!xmxB zx*hP|jl6AwV2p_E(vX)Y6amD10bMOnv&=^w%5Xow>%?(VIP$Dblw|AyPhcU>#}wDo zo`FKK%aY7~9+8Zzc@x|c$1^B$@cv?~G# z^)*6lPLJjJlwxha=IKhmahbiA@eZ{KGjThmeATrc<7VAqoW)L&z$gpCv?4RK<+EwB z55JSgws%bw@T+9Dy54*$_2{Wpi|wDzQ%^O?Rmv4#TJNq0#wYnV>nTS@mfiMxGnAF( zuU|0pWOE(R6v}Jl3a2k=mkA@b1^@`)xee6SSn~*`qzs#G$@D|`GFMv zBPPkju|{k9ETWR;Yl%`(tSAj*ssLrx5!3m&DD$WR_OUAkhxY~t#8hMbjL_EH4Cw2I zJ}4_lK;MMgm{k54;Fi zb!FdVyYz(NnZk^1s1~QsB*0pj`}>wG;12RLaqII(t?V0he`<`%EK%2dtR_ai6s;3( z7%Gx6_7(Ti1?+1r0E&&J66;V;s)4p5sEW3aA{5{?{d54zf?D&sa$I-MdiESmn2X^gY0rPkVk$!**cGPL9L+a!y}= zS-x?SuP?|Wh(iLj4?*+I;LTf`^7Hi;`7!ADO;W5KB<~u!en7N~nCG?2TnnFwflWP> zsLr@ZBhjBr@rkU}1wI{0B<1j57YqwRi(Y!GXpaZFGxJ#K4?FeUj2mD*p55}hB-gaaEpaWB*P}8Y0C;I(^|m4(h{$-$ zFXZLm_;^p0ax5H`7VD`#qKrBUMXR_pa)T6g|UXOJK6{{_B1r6e^3=u1L~i~yOh^;KU72C^7;vQc!EjAndSQ82`Yjw9{*#2 z;3QZ#AQ*(2Re#?`E;gD%2ZT?=dI^(cCk=vmg+)*V>4ZktYbzjX-Iv9ZABY7dc z)@FSGD36&Q36P^O>?VE(5WQq~$*E~Olk%8XLfq+rvJC&r&(blXH8{jypIDE{ zM=9e3PPFKjRKOla+3}mO zw1udXnoFJmuSWoeQ<&%5i0v()X?}#nuK|e^l8b6E+7Q5KLfag5*8?mikM?8JG%&*g zq+VT%xquwdKD{dMstGec6qKGAKz=WK)mkoqrYeKP>Iu>T&y?j(ZcD~QX5IOl!BID>gb^A|KliUGrQn-qJ-`>tYKumlhSas#Cy09cK@BY-QDJL1npmiA`vI4jcDiW|*)s?+~e zX4LGs#nw(HrvByyZ{*>JL6s2l60$XIgytd|kL zL2O1Fcwji8zp_upS#jA|^nsYG@4@9jxFb*dHn-TL<4INY#JA+@LLCSzfC^LL)M0cy zSh% zrljV)#?c=H_Z-)gud5mJsQbvj3fq1&qt_j~FRc(3QwBU*r^PKY`>ZEi6^kFm!+b3V z)C9!K?Zq%H;?9TB;TZQYr|*Lz-Pg(L&SOLBBLyh0-qglLp+!9o%*ERwN+~oY_?(VS zx<~!t9zm~@vzc7t2{v&$V*Dys`i|AQE zHE6!bK?@n>ao#i(`VoPO%D4+CW%&5?lr$wBGhQg)qspvK#4of4T9Ma_c`NHg&?-tP z#bt=_KkS^9FKkHFi%@?$gF2)fQok>3Mp1h5)aXax<+pfL)F=T% z3rL5$Fs{|6nNZlk2&8=T0j@L+CWNVe!_yiC1M`?wX-(+(aS1#GU9Lljl$$%0jQd$z zWuT``*GAP@K5r7{@!Rt&YEpko6+~qN(J&t`fc0&!eLg z%@J=lIF`P~EN!Vz9AY(fQ-lGMSt|zxiL`HW#NqVQKUc0`<9gmd7jer6-vi!lNSR#q z1^xu?40`D{gjJE%ZqG*61tS<~t15YW;o7?MM zDZBySK<))-*Y5{y)H>RK$`^2&p~69vwm!T;evaZz?PwR2$$Kw9U=1*#(x2pjxme$@ zFI=}4raYbCIisyb8`N+*;90j?&VkZ z^q`0$^efjYv6N+n;2%S~Qo&4<#2I>8J6ysCJq2q327d#46l5(eMG)qXvdl^i>D^Ki z;_XxE>P)35h>{P2Y$=TzQOt;XqwSya(~L)!S9-n=wn9*ZohODt~??uB()SY2ol2^|zISK|CyjTXTfRY#3 zfSy_v?1Evq$ljXkn-0fH&bPz#g?*LLkyO|3*cd~ZvE_EM&|`Mqnae&hoqF9r%y^|P3-LK@Z0EM>VVq&I~#5! zNL)(;=>=P!6<54=L>p3jwtewA_+49G=3tPm_&p?7bhZU&3KnpDJfdx?>}d{;H8fif zAj)D>dbrhoITS!8%Qt!*&P%ochbZ)7R(sw3rTS7+<}RdX#Irw~5FSvb4=-TO*i>q@ zq`ln}v+(QXjM^%=h17$ufjn3I&FfiS!%<*0SMbS>3;I#)OU=svX;)b+=qvbxA&!JFFjm<5>7*=;+@cL~O~KAmgnC%M4iUkoZmMk_oU3FSU(crHS8O#IdGgr)u1&T^J2-!@=-_!8eJM{>!A z`=~X@2k0Aeih(X!&s7;ZYa87(1?d!_q$94GbTI$Nu~5?}BK?a8)&g#437*M+!NDf} z7!C-5`ghnCs3t^|SQ_F$bi>&uku{0f<}-bKa#Wx2=6H+tELYf>PW~1^APZ%pWZaiF zg?*{>>nOu^M1h(jelnEOY3t*E4Fd;`{)E*Xdkw=VwMqe`dSuQWBea8a88nu9lP{XEcc=~780mxK--iR#PaMv7f;ZuPQD8%T>~P{7({O9iSbz{@H4C`xij zo^Aesf>T(H96m1;Z_(qXVVs}cXw3ZvQl`y(XKor^!=x=*7Y%Cht(+En&#JszR_EWt-nd#c00JPi zTTRw7Q5_}tDa<*n!P=lYD$$YrqZ*Ds)OSn`25BB@C-9v{^wz$Q7F(%9a(GRv{HptVw%e#s=A&%QZFt>$Y zLwrZT;n1i_>fn-ZOp8}a`Q=su;v+z2!YClifvp(OVah;-K_DucDH^~LL3Dlqv&bs; zKtQnp`u96(Fkm?Y&hh$iDkDvw8`WJnQzO^#JC~R_nm2rA?K`>dqW|(ZxP7@f$i6ep z)aGdkX$w%sgizO)im`xAKRW?Is8>SVy50gA-35wkJ3#!?I-Y1iYk(%?Y; zyTlAIY5|Seo3+rk)1rhJi~=J@?Tu7|7wyDypV|+3n_n*vyLEwF&!o*M zksD9KAtXZdbKTB_NMC~{C`{+}X%xRSYAFqU-8nsnu^R$6rp2j2qA+?#3KNgffMztd z31-lp9vXh!R0{0Ykd-E5F7Z>J&8P8mE2832NM2$EaT1?fuJoIGSASc}fD5k-kj;Ky z0(VnpP}U?9vdN2vAgRv)NT{n(&6Q*WjvHU18j~qOB3wTC%G%lt^x|r+#RtYF%-0L> zBpx@;5V7qCD|nQ`d-BAK*du&d`T6$9LB{?fe+lma&Eb~DB}Pq`fQ*MtHx!5f#W+fS zm)Bn~LE#&bfQ)CdA5~tToqpk7;cL^1^UCLzq@|bjEpw;!18|uDu+_=(7v z-Mv}6fSAtq;;>z!VLrZDQ0P7!uid=2jsvz+s@3zr(+Hb8`pq@n5i%xUz6C`(u<-$$ z3#7b_gI8!WROuM}F`hsck;mGV$6wCg=f2~}S$@zT>3V*8RDz^u>kAuB=9Zf#*?g6d^`}p1Mh-z? zB-uX0r@+)&_FmTsEpmwkJFt<3d&+JcaxkA*e7=z~seh%Gr70gr|EJ7nnoX1oN zS%D4&443eW5OXT7+VyqYK!JYMON}Fn4axnau5SR5;Hra*?KK)Eoncu%d6$vc2(_vm zo&fk{Sga6l8#S5YEWw}&lU_t1vzy>V3@$`FLg`ip8#-zU+Dx^f1R!zL%f&>Ks|Lgh z>v^$Q=9n}7e)5Es^9+>IpqX1-Kg+N4&tpMZz^#KEz}UO_%`qw1_~6{K1TW$`;Ldlq zUV)bD1L-Smv2HU%ChjE4v+=W8QzL5BRxu+yBCoB6sEGr` zK466^-HKrXh$$9wDP`4-=?&;8$C4L2z_bRhXJvne38imb|M`L{Gdj?C{V8JN{xz^c zuvFpuU@5yi^8#q9TX^SzB4QJFjZW1|5a3eBlR5yJP;8viZfIL|=qVsI=$+$?B0bE& z8RY;aTJ}i<-zzH<^gs z;43INzw>%o`m24D9$tgBweE#H`sT!kRKNML_58pLeLRbWMuQqeG4zMK%2P%C#0|K8 zaF!1091gc2BxE=>(08X<1lpGD>XEth{Pu&BF-8(@S0VDv%*BOq{Hn9mWSF6Zbrl zD_{*T9q8c>uVZdQl)!?HPTL;qkNZ0aMYb>!h{A^NCVOZ@yto6Za-y$F0WjDC12b6T zCTIFGL1yuQ%sAFQObY?ALW7DiUkf!b1Xclh@OkB!XrrUz^g)OR8%+!WHMJ(nj2iVA zWym7cTa=}X;HXWX4{nQ*W=}Szfl`*%jk|$^613QBkVwF0LT^CMUxaW=43d*Lp3P zDg!taKJp3p6>tMjF79@W>Sqk07ml8-RG`;If3p~_!7we%<=ayt=;6p90jIt9{1t$f zRAcdZ$s{mBs-ILWAP*=I)H_b4c%L!T zS0yK^i`7+!S%Km1fw%bv`WGOS1}#iohf9MQcdfqxJU~>uJ{Y8Cw^4W8c4t zM_ur`*v7S<1D<*?enQ#U2lxZFMmY7l6=GM22gU@xb~Y0oH%k?8A_L+nKS&e?`B{(^ z&2+9Zu;<#R#w@xMYA^t`KN#`>@rOphg;$KLHx_d|8t~q%G@lC-YT|e*UPAkHkUs9< zJ}zsP+wdlSGi0U)!tgf*w~+M(JWW*uK@CSbScet_zeQc!6C5{6-IsDbGuuhVM<9%y z5m*C|{Ee~!VdsiV2uVA?ovNABK2WUEg-QBO9_vkoY6`XWZv+bv+wrp@4s0HLyAMZs zUoZX5HsJk)y?}T$1Coy9jJbvyjo*}m&6%4iJkaH^l7RW&K>9WCclw2p3WGHcHLcCw zvmQR(rdrn*HVwtveO{?E4?scw1Nwt|&ls)H_gNI@QQ?QRg*$LZbkp&|89h13#oykK zYO10Dx$dxDyt1s`N)@nbHi!9nas9{g)q$Mng|l_m4(-_dlB)>T+7x6z0Di*6A--LI z+ZO$zT4|eFsJ>3rZl<9*r}mbsgfYa=JfSe@6HeFA;Y9yIL1w_S2z&D9?6)Enz^bozk_JT^MPTt47!z!Tke!fzCZG)R9q=;IG7b1@UCJqs zv;;jAo(()$=y!yf`lZ3boS|bl3;|iz!GA0X6ja`oMuIItKQsl(ddG!})7=YX+aZ|m zp6{D7nd1u@!HWYGqT7i$8Ax~}Fo)Qna|68kDLA>h{p|jt4xf0dU{)Bfm^a%P2_>qz z{JK~mPmc!?A7-E_q=iVJKTzlN!2Ccp8oYr;dpjFTVaR@rS||WElJ>^a9-0OWHHQ6R ztc9{A!1}w1ejqzyc~*)giE@xK5P&+GjPHjBa#2isql~rNjT(5GmSLaLLb(&Ds2_c> zuun4+V_6+teEE|zRG==)Hk{0L-fxvK$-{#yVaPXcw%o=Y3zM4wFO4+5gqbKVma!o3#=_IIG{wxqoxwQHpd6W z7#3M`4U`)ESs#D0i2c$q=w?4z!iqu^wFmaJekw7bz~o7UFkb-W_kKsl7XT zB<}_bZ z0pv60{f#ytXUy0Y(c+N?QY;(5!1uI+ETNe$zwPLPZ*{>BFMxKttbog6SC;~j&mW+4 zaKKp_a{7HU$&5EytCEUy+!PM1?(_i+R5*--u-`r^fGg*1r!@xX)5km=^P%Mu$}+g6 zS%%OfgViR@y6hS%a8fYQ8umTI`vaFZSQCLrVHAcmC}U-{>wh%8NR;KaGir-bC62TF zjiDa}Gke;(zWuC1I^Bn`j)KBS<#0dhz4_oZH^5`iu%Omp-Hr?ck%cd88i|fYAwTEf z;Z*;enRJc>Afn!&Ia{@9Oxl^k*m_i2HG!=y_aj0p?RKn^Du>n;-l z9Ty`=yt(pYb-jbPpgOco@~mdfrcoXc475-w)hc3t1+G5&d2)M*;0UVGvq&Uixzv9i z2-m`22o+ zCVOzrwAM6z>Gjh_ROdq+DE?~9$YKk`Q+C+Aema>!g2(cXR69@pb~|WJ0f^qpu9E}H z9N{@5_QyWMN|I_jMOV>$?O+SuDFf=!TL46(?gloApwn24c`*rG@hilZfirpzK&2d9M}R;HeLu@A1fM}k zn|g4W!t6lQ`R`eLtq1l7L>@Hej#sb-Be8y~ja1*A*}=+1W=xfnMxvtDzXJmIKxt^G z&y!38SU*tv^HCg?Cgth`#UAzpMR(?j!J`>Yhx=;OWl=DQ!hV{o{czg(TOv9|fK2D) zWQEvT?TZ{C0g{OoEIbBx2hQ9P(tpQ8bAOs_2x9vznNh)v^Q7?Bi_@Cn+!CXN$c2<)lRKcW>gOKXogEAr?715Ow*F7*%1JsJl0KuH5# zxbpz4$^z-?OU-3qZK!844`b4d9&3KDfBd)XnE^D3%%?G2{5f`f+I<xHn3Qbq zwdCtw1r%<0tOlWz6>QL6eiZM-TN_;dad|>xezas;4ZLoA{2s5IU(rD#x|5vWJy<>W zu~o;>j|`x~w8px9+hoP2ulBi#SrvH<)d`?sS6>F#iYdX?;U37TaQKr`5l{(XWX?5u zVrK@(nZXnbF`Jz_v(n(y_ETb1+m;F2>5yBk(k^P?^wN~(PfvWLr)UQ3MZ1~g%n4*0 zk?7!hMDBK^CZnL-senuXOF=}U<=72=?m!7**>fGXjy}7a2Az|D9|;MK@rC7&crcY^ z?=-{#a3i4QSmw-6>n5PhgTNYPGMV2#@_`QV_tO$SNVE&|7YjHf7P<)RE}v76Db_uo zWf8ZS&p=sGlpja@z1_V5CZ0v`7N}LgzzFZuZ({I^8G@%cfU**Thsv$Gei4RI^OjrvVM^aRGiPQV6i!WPGQdbjerXM?(aPKDWm-~j)%ez*klGy6QKqTUazuuj^-YY3OB zTImAg4Q_aMU@QZnKuC?-GeYSix$}eLkkw%YUomU*5B9Zvn=d0E&XBb;S+yF9fjBa2 z{U6ba1ILDc>O#;ud7Tpfr$MhScw(OhPHTZQAC4u~Eu-?HKgT7p%^28t13i|3MQTlkG??MOjK8in* z|A09NmPHqF))|g;R_Zu+`+X8tq3NIZ=W+y8E%F(E#+|%UEnE&N|Rae zYYr5DGNI{$fB_u{1%AIGWmrG@!XSvU61LTl)MUB3fMI5Re&p_Y`xeBW$xXFF-*0i! zdv5}W-JmuyLKX-?F)Fq+ul_QkRxOJvc5xB9gF<>7EAt@p+c^=^c$k6YR%(d;^UlT%tS47G8VLTF_CQmwL#qO; z=FY2j@T+R*VSC*8+d_-!ShQ*9Aw(VZXyGBoUY@g0JhRk?Z~PeRaNb4uD7EVO)d(gu z3*^7ANgX~aM;y^JT4E47sHncT0w%C9q{n%H%8;Q)5WeEybv$TT?e&5DfE#7$3M{;- zr_r@Rk)DKAtVZFU7�}Nk8r`P^&dciDP!X)WI*CRBHnIA<@h3TiT-Knu~&M8-9^gP;c>?6cYk`s+Z1S zvtjW-$>@vVmm5fI04a{Ztf{Cn`L1M-XOVhEE4-O2DOkw+A^sal*R|y+5<`E993H_W zlQEe$V{$MV3|~K@=bYZzZU>B^s-%)`DB;xZu@7kUJLK(${JB;VUEQ4=Lvkin`Jvi? z7)yS@v*M`lyFdoVq<5=nLcRYQSWiPgc_e?Yf(hpwR<-rLt?f(re z;+z`@XHP2@C2p18o$Mz(k2~B}zwZ*_efIfN0|F>&;MB!E9X@sA7OwF9h*`T{UrDwgLf=-CCcEf%}*%wH(o5*su&lJSJ<0l$#hM29GbBeQUN{M8;OJd zodi@+>s`r{O9KX7u951NmjqxRpqIIzIE{2l=MB=G?8m^@`4pYsr}(5CR}H+kTK#Q{ z``Q?^X3_f#z{`FYbcA<{lgghlnSAWTKRX!Ek8cES`d#`dH0S{F?|l)!=GE{*IY#{? zmEZH~kIlzJMqmLQN~Fu@2(tMfY{T$(_vkIw_{xSx)NShrML7J{&y)4mVvVNvtMGg- zt+ijWso%ECtfNxPBM%;mV0!H1y`y~IYaIR{hQoXSYXtD>{DChWUco0@O1?!UxhjBM zd1zI84DpKuwSiCgLa|5j;dNqR%zdIOhH`*Bf*g!Od%KeXuNx(yuPJi%6X6~nB)if} z{4G?+E7cMeKkAuNpQ74cZ20v}vw{)|kKopRPo|*Rnd})hfVZ1$lMs&gczHxne}|u& zhXt!<_f>}4P9$gFfnCt#(02ToYInAID5ro$O{ciCWd@e6VWXoFB{B;L!UUUz!sG@z(nv4 z$S59$6+Oj!Qye;uWDg9z!!3RHhHpM!?_Rg{px1x>| zxeDxgfZ~9ASk2Dcz!Y79R@e5uV+GtSQ1dt)S5Bqs^~W;cn~JL-xInpL21NplbyUv{ zwXV35Sjdl%DoOb0FQ?-igp`rCbWH~pArvA$2prMvqa*GW32Hbzz{E?XFQ56Nf+p1+ z`6=yQX4zlme(6UL9F{kvMUmXYY|XT~{CEr&Did=;F~wG5Jfw>(jG0}`X!|D?L7y_I z5TS5zDbI_MWvhDv$gt*&0!A*7cz!G^gQGcrbRB+6lZ*py+pz@)9;*6BNZ5qQ+?l?T z;^jo*0jX_Zth&j{m@aeK6>cV$Hb%g_2JwNWWlJ2fyT^Bya8C%Cg?&H#e14 zsv$tf9Ma7=2k7j3e~GeW%xw25hCsl0Dgc6F8+ya35uXtWx4)On@l*Uxe5Il3N1SxS zg=cV+?@f`R7T40)0qH3hH5bw>MZyCT1fH4g0Wuef-KslZur7dP1c7gWUP6W6Ir)8k z+0)4HGVBPyuk_;~ZLeUvzZ7e~$i}{_ozgydE<94!P|8e5_LGO+aq|3!Gfv5b0;zpR zxoFR}AI{#W4=LXNYMZNI`osVIvqS;+j)tf1D5l&~4`{rgMD-l=bo_r$?yZ2eLBh;u zs};i^@Wa?P_J!5VLhP5q+2)-$z)!>z=I`DG{ATfQ)(%bNt(@s1k#_1Hma zX@xH-?fCsn2wy^C|Ay1J4mrrZ!QZe8J3h!E=2;!?IB{Pu@>chg)~`a|)1d%eo(i3# zNccUWD;6n26WQi{S!j}Vm&^Q|***~CY{Nr;N6$5&df%rtFamR5`RAV|9&nA|cR0D` zu&6dXzR!3t>?!onY-lQw=7I+xm3WM?809a$6vI1x^FR=b+fmVVh-Zr& zhL28iV7z}hA0V*ZbmgD_`xL{A+UCuhiMAToLM5h{7xD_oxM)sim7@p}=Hwk7;yH{ahR z_fG%>SJ_g`4Vw|To^RcQ$Szk2y8A-IA(MV3q&HCk@BDCPQREXz1+X|?9?ey6iD>x& zWFnHzZXurxYxo}U^^R|0_Kg_mcvXQ_H2|0%0Y9Lf@X80&tZHK3V+cOV*=v9;H7los zLgcQ)(?-j{zZvt1Wm(zQnn7xl7A#60{)ihF^;Qa_IJC^dt`#_`;(eaq^C$I6J%#+k z%NL`D!t}kieI*ge9N;cJrRBan4@%EFC?&I>!d91Z)~A>#;c*y1JQh;|w19GZ{yYmC zGD{ePaDzeqrM~X07Mdny9OvE$f;ysR@!R6%%8j>>V7~-l!CXr@L92IneVk`DM8SA& z!5X4zMg!(4L-m-CXqSy70VnCvNN_EM4ml;|`!4u~ENVAfp1-%AjO}N@=&Wnpv==OU z-XeZ>p7#YW%N9uHxU3#z(HFFBc3}Bq6|jR7IcaCL!#e>NM-~nwu_w(?RPIHNido~I zv=VHt?q~R8UybGIC^$5xQCNmMjeNFQmIe<_GbIAs(#HlE?EVG%m)ZKbC--$qD3*1G zqLsj>u1g_l7ycgYDpxKGzsLKFUvVdltOeKg*#_*lLQnqrN|u2!uNRy?P~d{ZSo+zf zysM+gbA8^MxY(8io{a|(M%w8GDN6}w@8Qln@MM06m->xc8TneiqA0I4L@S(_cC+4M zc)>593TF}AvMk4 zEz+1G?9A^{Ms0N0qc@o$%F1i;^CIfn>dS)+0FM?0gr4PYs3O2^FAR=U%^0@%Y8n`T z4NIZC#xVf#*U=L`0oJHahYluxzL7b?VBMnm&V$FjJ9z>6os)^G6~XETBa8Mx6<|;b z0Q-pz==5Dk|5dOAo-6-K<+rpFFM_@tCTp0kKvMq1(Fe7!1o4wl5{vs`K^`~kEXhF>@31rv}5 zH1EFY01Iy2t$C|Jo|)if1(RqxU;O&-sQq5ckkU1C?krG!by`Bv)|cJkPHG=y(xMAQ zXbJY1lEl4A(0%BVezVQydqzz7x{t=x$)fIQDo5cl^g~~kV$5Eh9qaC6lC%^?et_z2HnoY}^=jFTH}`Xbu{*Kd6*)3G^tA`TOu+Oc%@UmE(+_cq;Z8kcaOxwcNM-jq-c3_1TxWFXdbm z5(98xfvQ186(kkr(9~T4W>&imMGE2>+uOYJ3JM3{SW-E!;w=o5kV?fR0-~>Vtxo42 zTz)>$7}~qQROFQ4@zLj51<-iWF>erm`yL&r*TUt2-3S~@McSekKFA*4`?Cb8?Wu3% zJERnN!wP`Ub$q$k#+Sn~-BXAmv{HDfgxO2{oL{EQ5+AA`!vzKIs%CfnV?2-X#)aNX zq!1>LXiwN!zcaS-H`M!mQ7z3yXZ~}QRqVg6Y-;u*;sh6icQDA2QAQ;|<8+|VR(VkP zYPfe6@`PvcyeKN!exmn1f*%=_T8S=6*{9IN6QJv)4?4L9lro<%(|96o=!8NdJ{q^5 z5fbm;y*2*P_lRc$5A<1J-tqaTf$WHWg@e|=s!KDUe$9aJpmENyvArIT%9g!PgCxLQ z4*l_)u;Z?bCL9FXp*_zf(EHs4N_>Jw0o|{CMruBkKrYXOR~SD1u{J}so?r5D3mHpz zcym^y7I8k#wG6PchL^49k}ib~q8ax4+q2`rA4QWBtd^NraIeesQ33%{7_l*?SLBqOD6XafrxS^Lhy5BA_2{2-#Vj$*86v# zjddpZ@!%I+s2XglP#C%Xje8-bHS8Xo8@Y^?^(i*;Ve-i5?Ll)Fl(lT9xMqP4h_%YeH6$P= zDeGZ++X1pWl}!bD5gdR@!fvVs)?ttBgYG3TXl^zRySUYKtK<%gi%d~kqC#sQk5QA|H;@p7`NE4$ zyqy{#wBUE3W@ph*lXupAp9?O$@Mv;iEFVLXK)>i-+6d+(pv7D`$vv03y8fxH|JRLS z0#Ae8j^uNI%~#&!oy;Df(>cQ4G7%N?c-g>=!$)3NQ;L6<{y1s{jM&=Jq~!y=6Ba7Y z)cJl1HtHry=42p|*v*1Qnh^Q6Yh~+GW*B9E+&4vOKZL_J`tZXJmyYkn6T83YIL%r7 zQ>BM}oJX_C)uTvQ19Y%5=oj)%N~@s+t>&3F$>W!d&=wwl_z4oJP*kJ11rF2a->YJK zw&iK#c|wMBsb*bhYKc@!d0`;c!dg^%Sw;6t$FwH^ z5rD<&sl!l)*Wva3YSsDzkMg|lGtc(`F18`Nq=ybD0-@<^fIX-V{PU<}?*z;)`vo+M zdfzEvUQeK3p+hR+R@L8Ddh&J_>v<3;WS5G%6Jb~rdEs4LLQ|1`LPz~Aqz=5ot^_u$ zn}Q&8;qKolrWu*I*PTxQ8Yb9S$}iET$5)C#7yEMpo=dO}nJ&c-$XAJ_gl4E8K9hy! zUo1{n)#4^ZtZI?I7t5McjjBHvm!ZciIyS$aZ4C|$WOUqLJ^jPvx|%XMb5B30RRG-Fw-1fVj6T^Xey04dB1AQn(l*WCH*r?SlkySQR0z;<5`=Hh=<1az?DVVAch=h{KS1<> z_j0jReVO!%bG!t>%J*Vrf&T_37!GS73011-{_<`C|4N4FtO}n+f9+f8NMgPlp1w2V z>|$pDs2#qzc*Uii8jg1!h}miYnS|zza8q?)noEb3yy~o2*%-s9w2GP|0x_pUoH)9^ zU}hp1YFYHpPrSx&tLI1khB!v)*ytno#Qxy3^_ozXWw1Kkoedi!ZQ_dQG?ZI(cG=4Vx94Ujc>%$_zy`Yij_ z00TKeL0M+0$mC9mmw+kkG9MjzS|8ahC?^gx{gK2&+P!Q9woP;N7PRG z>IE_b3A%N&2|J)E(L(5Q`uR7lC*5BJ&`qTckV?hH}^|zKqaiw`2^L?R%KCgv14!ZR!0IpQTr6__a2TGU96puZ= z)0p`KvCQ0}HHv`mA+ari`*k&INvY}&6ZpZfBzvrj`{Lj}=Jy^x9&-=S zPj+?b5sSR25vEHd&W&2;&3z7SM|N@deSo^sy_9`h5Ll!q3(A2b^t4kl)r@WD)7^Nr zX!>Ft%qHei&&XpsrV;r7FSw7+Un@K^^I`(r@jz#9FZ(5;oNccOnW%!se7_^hn^>rb z=9X#L3ozHM4kt{Qmylv)c9~^i!mq%uuv&tGrBj+wv*0!?Y<(9o))8b9grlYtZuV79 znAa{IXcEhHJfSw1-B97PJPYg2;wWSraDj0FSfZtZY6EZHX^mB3mWK>cn*g0SvgWIj zzK1K|kwLqS!J%Q)QmL8hvViX8h-o^FA{=z^9?uDvy3IMBjjWE2I73@-{oc_GFD;bK zD|~y4peotkIqSExo)^U7Q=*v%3X;h1m_?C*(a6@LMR zNyq=5pzlJ+d~}c32Mt`DCcl}eLp21CZk23!L7K(;Z2?uEt|KT$BJ zixJNpRo4%FQ7vi&>D=eNsMA^VWwYIUl7i5=Y)<|xXmw4s9WFv9eqtyF-rpqHKXYi| z+Hd5%G(31K_nP94f{b<{%b>}h&e00LZHERM>VlP|7mm~f7oY0)|E36gy6kCNTQR^t%sT~A4lzd5dg#0Ljw~D zqshIacmk#6PCF@(0pB*yL8ZdQJD)WO>~WV)djEO=6zODSL=d&+Y;~pd`yrIu z(Lzq>7~;2G5pNS52oEoje{bVzeA?9q43v-Zn5sW9Spzzft?soChOBlAuaI(KG*sG4 z7V3)npx_@fF4)P5-Gw-{@cob;`St^K$VOaXRPy0{Dzk#OGHSe=Cy1+lzg=B7AL-*) zpGbg@-ZP0xd`<~*P$I`K zSI1tUL~ZI1dQ2_a-T=1x@Q6cok-Mzy*vT2(^^k`Pg3LnRhTdE9?2HKAs|T%n3U($E z%Yq>WV|rKcB1)heTg?xe6wnF4o0AW=erl^ceSLJPh+!kI>SKJ&5?RnhN=_AW4_oDc zGNVHOfbYq`T_Tr=-NSo!v?hwE+9i%f51SR``XK#&e(PlSV3IFWDfR zmjIho0a(_NTUcg zcxdE*+Oe>*JwtzQODs#&XhT$9iB2+$rV7(e^$ybjJMEz5dplTlVOZWZ$m(&~&nT3}0eYiXDw{F{cz7kGj5r|%Wiw}$@( z9fWRzfRg2)$)*vm=#rj;hhJoIs2^xz^<}>@)BGB%&>_19&Mq%1?EZGRLU4&Fe@UEY zy;A@K2hGMmD<~fjszlYp#6?mZV%MWR<7b-G?-BbcZ?J8E z735CQtP-$Rc3^|lDj$q`te40*oVJcK&{ST0m7S`|Q5M|4?g5k!}F9q%^#3zrk<6CkD7I=_qWbRvvuE+@rUN8VN>iqT&)6|j|E zN)IKZGrvAb13(*;CB;}G4mb)_a`8h0uJN5!4U$P4s1LRQ&zdG>h|wP41r`gOsi1Y> z4blRd*R+v?0vS-Q2c{sL$h8CYG{*Kstl%Kuf3rG^D-4b^+B<$&)AJ1 z#7I@hGbo~{(Y#k89HYM6dvX8b^2$ZTM>H1B%SaoSrXxFFMLIoin=G)=sjxm@o!@w+ z=`!N5tPRK1xqvgY``=%Ej=}j^BA^DoWg+4h6LPfz_$k$ z+KH26{RxHJPs&9;2zL~pE)FcemgnTJBG)Dr+5YvcB@`cV%V z>*}GFi~PxSF&Wn(Q1OJ`J(@}uxbDD7-|06XlxQe|(N`&ZQP*K0R5G4K5)*AbuS!}e zehlSKG9nj^fBfvLrOfFHWshvhZ_~{y$OX^0xfftUm+PsrxG0=4dZ#QhB?kJu@1?O% zO`#cd9Ci;%YV{GzQs|mWiXy3YiI8Bg@O7kG#2{rCFB~LQI%$GzNjmU=5eg{PoUi^k zEuidf{^Y5CIo^xKAX5tniyoNi>{av(btcAQ=b1pQM)I?;^e`~J5MKJ5>qrbU9C#UwfdTvLl~J;^hy{ zskl+m7v6ya;_K`A7i5iJ)F4p=?#jLV2=|hAha&JZ;+FdhGugEB;d27vEFVCz!YDz# z7ETVIzRIE@+MV0C&j*}X%%Zx! z=AdoMYTr5}(q#j!kW>5?9t6RAfOn$hOlnbOpzD_LItE}h6pESOBt$GxX}uBJ`q?IL zUl5Hh=sHi1E)r+jYrfHE380l+Sfef6ic`F$uB~>b=0;iW)yQv!V+{i28~A%AsHB>I zpKS^23{fq50TwUFLjh?huQmF5;8!+_c%6~5xvTS*Oc3UB z^;>0EAp8m2I{MX>9PmIzfs1PJcmBw&fBowuS`J zPWPN2Y?heJJvRN4+Pw#j@eSYvN-CK{AFpV_?pi4t&0p^&jB$5?W*YK=ja4^7L)N zH2?W<1`>#~y%q6`)nG|Bb)T17ZhsL2V}erL0j{oc9EK_{n8~#KErd*UHQ-?vmYpix zT7Ca!;N-nU%9qhz|IlVZgat3<=gh6=)V!7bcc0*;o){21xSrUBvV{@Hv zpR)wc+TAd`Un~(9GQUA(*ZB(G$6%)~X5GuXFscFpDmeE-?Pcl^Ya8f8hp?eAe(M{2 z`1)@j#gAlYbd!M178ntNWsw%@5a?B~)SEAP#5>r~!28km0yvesZdRllLtrc1P{d2=J(;_=12d4J%@? zyqAGI7v6F!_qeq!c_9MNfEWDog2pvxJf5l9ZlX&s{Ij+S1>nzUSTf8f8KROpeI&Bo zy@g#3|K*Z0mn;Xcm_7++g1MlKOkO+z;xj*oudas&QU=)L@LOQ>4Eg1u(#1=4_I*a7 zxE&yMELZELyWyP^sb1WmXh;ISwpaAGO--tVT7oZZjx!QYUwZjdkk|Rsz2|@f8&%_1 z{@k?_Xc4o|{6qM^J-pW|OL|9Om86)bei3X#ob~`Bd>d<;kpxy<3pCNd8M5Nds5mv^ zH*oe}!}tq9hHu{`%vI?RBE|qF4S>mz!U5|99xN>=7jE(FXsR(G*8%+M-~_$~mTus% zME;ugv5mEOuQQ~*Kw@M3)gUKuqx(*82|O}hmp6$O>j%1SHon_s#D)i50ZaG1q2iis z$%A2^&vI?B8P$eap47XDL%r!96ot_OST&8c-}X9Yy*|(Uq@g+7Ytk{WJ2o1n%*nPcwO&6^5{2g!G;s7lX>;d%- zhIlZBpXL|H=RZI_aH@RhMcXuYaV_#jJi} z6*JzKUgo0;L0&vF{qgO*)D!gA-mIxI$>(Vg!-7%ItYcn-a>BZP1|8<--+`|2KnLU! zzh?%EOkao_pkfV8#zANfG^=Ye=~U7-%HNYLyBerv>GJ{}+P>3q76T`+4^nk+e?hUl zAN>Q%`Ypv%-7spN~q{UjG{$3{eBopxVxMF1OD)nt9nZMzp5Z#A&C z{0uCHsvOx)rTTuEI!08doT(F(Z-&`?Vo#iX+UpN(bfD|Xc`buJzVoEA1p9%qo(OQW zJM}S4aMk4I-E$cnH&cRxC6&KAO_HGYEOKrk`U$LmtuLtYhgEhdD9sEuf_+~GnX`qY?4^ACI zLDMTRA}0ce0zXM%97DxzB%ax)FrZ2reUl33M-V2aj=328<9pOh3E=LmAt0kWmprZ% zrv*&_U&gDna^hWd#m{sKxD02PMePPc)*uqv@5(%4(~y1+l-t0>HBF)GqNuY>K4C`& zO5Fp!g1U008TX`8lRNdw4O(gC)joRTU6l2s0|4O+&)#NqD0gFJZNN7axWMp3*v$dbmG1{1H$|7o^+lCY>5Fs8Y919sfhk-*jB^mP;_48W- z@hC@Tp5v2G~E7R*BYl`txlKTg|x;fN% zPOofLrx)EutlNb0s*UJNDcCau7>E6J0~P8P%r=i8s4mUeL(1gy>V4vO&OWtT!|N7* zlr{~V-|PWBR*Ui#cX|zrHdFpKPq2~jes&{mO)8*PcmUib0(TJ`y8Pd_;So*(tT7oZ zY_lr3w{rnQnnFyfudqN0s#EVpOe^(o@a;h$({iQ5t(9zh=^zr1!)TT~w$~%WEO*~Z zknWw!dW?f7^(QOi#Lb>ORCA!b3qn_)bjA7XC=22gH$>?N3HBxc1?^l6Q8>V!Gvb*j zi9fUswBSNlEZ$!s7qQN{?{Sc#u?b>^WMWyh?z`!fA?I7R`Y%`-0Q}0*j^a)7muX(3 zxdJ&K;Kua#Mau&ce4Zb1DS_?yxig^Y5$YLj8rgQ`FYBp;zCmV!{_p2-MRkX@?I3#( z+Tq#p+2G~(*yx%t;2SWmJU&l+NtzNgq``PJc^R}ENa+VQiqi!g0WiTs4N%GWWbb#L zg_rhzo$K#29qP&uy~OL5{?mT7+phi(hTX!-ze;>q*nT!fxjiw{JJbn(cB)%eR%$3D zc(*^qYoj${FxHzB1inaRZR^XU2 z&3LzR2wXCMgvf(<*_*hCq91^x96dOsoh zNHwj~8htfL4p)7IC!_^^b~PGZ?{!uHW;B82Zrf1in?wQ4(~NO~^Bxeso`>>alZ!fG z_IQ3rpXPl^cg}Q@sRups31xGtx0oDV6V!n z)56snmL1yNjzu`oaOe5TTW%SkkgW2~280a_d`Y-Yb&(YW=tzV3Y9d`)WhS`00wSYf zu|_UU;^hJ-Jbo7BCh8uj3XMYZ^BV`sa$|R8VHD+Z_JntkjYP( z0cHPgl5K&#HJlfG9Qts3?e!#9_`L+OzZGzxSL=GcT*fj09i0lajW2g&!1$(jEu*1` zDC4lMlg8ot)pInos45>i@94%C>M=xDG8p0do%Uu`sIxX5VeH+#_&*gW2t40Y2S$V; zGAA<_q=MB89Ww7^+TJ$cSqQNGIF6y!IWw$#Re3?07(g=+Q-Y!H1LV_R2%xm~HGL_= z7)HDaaBR8a7xUSiw>Em=II>9Oev+#1Cd&p%x*JVwd9S5nvZftWIvMJCw z1ICxG&ASbnI+hH+vGC&RNkqR|j1HD}9>?$m!6lm7h{E{B&(&u8Heh-m}Ia^5yI7Qq8e<1 zoVG@jJGJwl1U`J}VgUo70dsJs{~>od;OLjsHI{QWHWAQG38>VJbu|_B z4(xGw<2N1KBLO2hRw%;-=!_v_K+)Xija-9$5wL=4_kw-o^@*Eq#jI=R@2z#VJ3694 z0->KNJ9pxrOxZn3{dT2^q%$cd`v3(?v%VORYegVhVhg`&FC8?hxTa*8pMsixOX~P8 zS>Xag-#A9dKKGXx@h^Nhf$LG1WNn;9t6@J%+ zhX^e6&P4LUa+ajsO5<6J(|7O6*hf>`O;JNa`45;Hx{rn z4awVM2|kITnEl!Mz?@fxBFIb|jMkwOw&-nimh;23z!=v}iyAr@?&hDXGhGJ1^zE3+ z0444`HA#>^(gABg%SVsFqujRMBe6^(`T%)J7(b^AaK`LlRvfcbrayP^W4sX!A_J~$ ztbJ>F@IW7ax0LgeS_#lYlz?L{|f) z+j%_zMfVCap$^tsoNDSUMQHwcE~+>Dfq;dVx{nFK)bkM}xu7%1>@5KFO!7|*Y-Uyy zzTkJ!M>l4I*fCE@HC{lbfn@#8LHtx@i|2In4EgDCDqq;;jbI8)WPnlx14q55TkYXv zN?({SS_2A>;~{lRq75;QWy=dLApM|{oi*e%-8GY$ER9P_EjE$jrVA-rt6L1*p{=JEfVJEJzI`!yFdj&ljt3m+J|oD*rIcdJuCh=yjhCyY z8-!!-irf6?fJTC$j6%Nb$EtSln4YhFA8iwDFL6b`mOmLTZ!*lu0{t{HDl|8r%{}gz zR@B3wjv(IgUwk4H_&`ZdCwacZ@iojLJh6O(u|JT%QqVhY7&he+k3k%*O*RbNaD@~# zHIafAR*rHJXj89dL{AWarC1h#sKe2M@YD=&-6e5PLvj3sfX2H^UqOFQQBRiCp1I$C z1&Jx3KFr%J{?j8;O*&{^UGRux$@TmU0J?W~jucs@Kv57Pztn;}87>ERFqpN&g|cH6 z83Xzl8vNIl-!0w0)f_)|V<}I!RX|XAAffr{!RuqSilXsn=?Tc_7iM3Em2t zNZe=T-B^++ImeI7w-~N25fGH|Q{MyS|FT!3wJezD;+Y3XT0OorZ`Fgdu5opLcm+Lg zA1{4?|H(*24-sA_=q2M`hmurdJ|SmbS!hGn39U78S)Ux6QD$q72Ec7RVF;eypU<38 zV)xzP3OHtg^dNmp{<&9oNkKW#qAqu3h;`_;o?w5i^4Xa{SwmU|5hINkK{(jml$YYi z;OW`AdUPTl;1WL5hX9BYD!o^cSpqXlZu&H!KE;++inVdhnxLSXlW4FQU(qm@X<-Lh zWm*I*a;a0^J51=5DU&AU#J9&+0zf`|%-sj1E@y9GBc{AvQvgqv2xy6*r3W^8O&s{p zl;xvb3%mCc|Ef}YfIej3DAHXQ{i#$7$Xc+$2B!cEdaYwpa;7`2e_C-lxe(tw{0k6l zQj7}Ukq!-K;!22y1~ZD^IX$qT3SjNfU1;wf;E_V<{*V-}$3t)Om$AUv{k8b`wMsXt zj%~=eg8k~P@-dJC88I0`)ti9>lC#_%yn~rEyk$+DADC1@jr)3Zk8zbL88M#A*2fxh z*h9N7ml34P8?T@MtpYl-j>kVs;SJtwy0fDky7*i=zSH0u@nGr)1{KaXeIMQZbyV+= zqXwW)piC@i$ba4AWeihtuQk&8D(T-j%TrMzZc0)RcX+vF+L8|Nt%Jfx@MBTTH8vEK zOBnpTD8SGy$6dBIC%LBHuQ<2edy#-2GYy8t&GabmX|Wv}Jq4}@yt0^)GO=dny3?8B zo(drRLAyZ17DDHfQRszZE&gluKl8RPG$q2pGXK_s@60_G)bH8>ptazQ1PAy!yn@k+ zk#Wpx$}ba7oGYue`iYjPg&24<4E#G5;{iVFk1{K2_B6kBs^HURrhr&ZSgBc zw7?-A^Ps2`ihT$yjdNIEryn%)Sdpejf+$UPO z=`e53fM4%uN*=?b>1cHXB}>cvI6}Y8HE93dH;d#9{`U=h#bJ!Tyy%fq?)6n!$v6@b z9DrvWG|*)?4fB|5vTWS+WSz=!!VOS1Kprs_J|>Vj)ak}CCCUoRC-?^B;(VVOjw&$< zN3$C6`7G8HD&-(emZ?_aVX*OAcf3d=(*?;FVLRD7fbmZn3Y|}r2IUa=lMDvxvmGhe zrbWU$z28&uj(&*z)f_(0q(eEp&{_#cYLhsu-oMnZxcqgp~tp{KX zEb`<+DgIQ%;6~IF1}G#>FI4?9(A;K0m4E$3&*EW;>7Zxs6Ut&)mPK#T%yHwvVEziF zkfOvOh3EB4D?riiMM_2@z(UA7=7xSqcANbl24u+}DY0n+yAuA=0d-4|z?Vjrz57Aq zs{c`6N(ku6`Ji9k3UgZ0L~!JVD+Vnavg=atYOp`b#XJp^82v!Z?eN!VvT?Dnt=T7A z8p#F+%gOZ-Chlumize)z?9ILwBmT6oE5G6_RS~lOY zgD<|_IR)MR<=bb9_6q|1E8E%YTxmc{6JFV3NitP@;VD60L0bhhi6Wl2_5Fu3X>BhO z5dd(!o4!zXMExfT5*qU^mL5bcJ3<{I#-0~+HCX^qCPbh6$?{Zb5Totq@;xoon0iKu zSMjv|x>GKn{V=5vhcu=RIBJF_!*PDSei4Bt^`+wZ;TDvLD1)G2fx>_wZ~jBS5lXZk zkUIN}G5wGUz4RA60viPqrfUIK8)|r~2XapzOYHJqTrr^WOwRIaK(BHHjQtOLjS~O!vSMKXN&N&O9V{vUhPk(FA#6ME zP4d1%-^`yn{}jy^JfwgQZ#mp+l1w&WKcKbcYQ%!CNBk^U$m9c1~? z0bAmEzo|;q zG%I*0sy~H2J9%tygJ6u+;r!1>Z>|lSQZeO3vvC#axecVakU*>enF~+LHFH8=m$If9 zD)>~KBrd}afP#Px_G5wWhBKgo4b;!qlZ{$SJ7256*PzY|boUqmaVlA;I|L4d$38Snt1HgB=U2rTah^{j@x1|ujmlrm<1f(52I{0VqHkD&MWIfHVIpB7y1f7!lpX&zJ= zk9$#{x~N()5Se}HX@tFQc#SG0u0;yS@5n0KRwpEE@0F{JPn0o%{QoPt&QLc_zQ6wr zc41dy*v1yl+#pJTluURqd4xlQcCm$iVEOORZgnCLq*Yy*j64sixstel+lU{MLDp_Z z#*ZM6Cc04J)!(9-AO_JojpUs=^pwDFG4{g20F!V4iTgRw+MJU6@T3Pm9y!^AU=Kb* z#wl{3xI4;ykU*~)J_vgP@DWW+cK~Yw2T<4zaCDP z)o_#jouu(ge=&p#vixOQgcJhE8)E=3R1m%HCv+F%Yg1!ysJP!rZQ{c@j1 z6Hs$cg(Me+QuxIoY_lco3%)`sCsUWkAD)4OAWff~`fLn(*n{9}eOGBH@Wh1!7a-RB zR%S~Zc~C6HYf#gUr;>V!$&+jpmGQ}!tOhS33mHKEQS#4p1aLG~nPnq2E{i*MfC`Xg zd`u9ChvR8Ec-Z@hiT8Q@`GKNFY<~#i>pzp&{e5tN{USj$5NheJ3EtW!O3QC2 z{(?r5-f0{gG}3*99d92sLfep=qBf{M!$W)v(0=5H9s{2L_0A8*XVW86(rnbPxZbR9 zD)Fq?t{Ug@R+iSk40v?^NIJ7F$Ji(e|0RUrGKeXNh!}E*7=xH4etmD%YxUP(byX@O zuk)U>_p{%u0ylm)6qwSE>*a{&I6rKLy@jKyiHLAnhg7uVcW~8S4d-RVEEe$Q^U?QN zpC_fiIF=yWOtwzd2k^&zcYw{8%;hD@LS$r~q`owNIzL^__@>Kl?v#g4?>!2pdG@(4 ztdc-*#oKzezn0A&DM(LAvOEx%N3E&b$Jj7E%xT}#6Qp{%^z#q6) z*|d1%_}J`gw)_|>ek;trZhv~zhNAMshz$UE?aCLCNq+(W*|zfz9k13?~14NbGNV7_$A3BZ#fqcRl?q`wGi{%<1&0DUKFjf;ZERXiF9ajAdWOHB? z{&BeN9Un|O$N>Mp2itY#z45ihxM&Lw1e_BWpw%mUuA+FOQJ?olyq7xWOK}XW$`6rh zj*{&TM{d*h-EhTX5$n*6z7fKM?)+p3&J}NJbLRhK2SM`$fp^)4x1IJTcBsRtpLq@b zDEWo}l|#HtI!*o^q`0$d9#ve85^u_nr_*P%D)p(7YsV|WALFb~2p&qFaxF?og2`D( z>GNIzpJ0j~1DBvyXwmDe_m*N|+pT}nhHx4mZxiLSlf3`L;`KH3`s=0HKQLZ``FyN$ zOmo*qQk1g~c8~1rJJTWOQd1nFA{bnQ`h2!QNu4lSlS*?KS<(pKmETw|P99 z{?mDhD1kNkR}JVV2)B;|5msRjAFUKWC$visSL{hY1jXLDcQ*;Pd)3+WIQ>w*>_<5B zLlOuPR(L(gf&AtEbi8@RVz*g$*}KPcskOnR0?&E2-%6&D;s(BjD$6rkB1rQrAWpqaw?Eg)gd(H^n{xrX7t zv?EBQ4GtB!7*G2J2C+=Yl=E@^2xAmF!ib=s<5dzfS(l!j0rp?je#j80;*}7Z(WkWi zyr4QKoSNV3T$CG}&*{;^)WD1__TF&P^jnkLozdtpnCQRe@>7yY3MHY;eQ#no(?)gq z8F+MD?_QrSj>K^&)sc!3X0F{9+<$q6#sCWBPfPsf@j)G>yEW^p-H^!zl#Rza6#Hj6 zUp(nWj^EIss-g-x1Rw41x1gTl)@5IhzsmnxbC>C9(g1}n4scnx!L*r1azlSx6AMaT z&~>Q0`#bx#VHzJx)LC-=z9VbMzFm_C(ixnUwwy!M9C6)=^?Lw;6K>;Pt$^CM)U$+$ z8xQyUyD$Y#Kl$*;z^yxd{ljR`#E-|=N+57Xy_HS0E#mW)?81t=l$s$z`KdP?>Vl|0 z(oZqDWBq(F(Jz$K_B|ar*)mO!~e$2`-ZssW?&@;WIBVdCc7gSpqFF^%}9cKLi33xI>{ytR6# zp8^xCUKnt5yWpXgdwBk(yBB18{prowzN?(Z5tzB%!#lhWNEoHz_9mGcOOMcwmyJ!c z)#u_nB476laxXSxK0msHvXvV1^|)>>?cS8Sios zyWiWlg%3wY%oq2;k|)rg*Qp}Y8w-lB-=7z}`!e4jtDmP#zwC&*0yj!>F-S!O%kOVW zlGCXgNaV}oU#$5m^~U-hob&6@8>2&}`!S%~dfge~P&D(_G5Ho~4Z@-oW^xiZ22)Nu z)0l3V9(%5~#JDY{a@~s;L^p0o*X*X?`5^h4@}OV~1*3aHIlerkdxBKJ>y>MTv-(MA zs#}Wpo4C`*eX%$5jG&g!W1*l8-M?|z#U&yiJhc>B;_ruVn+T2-kEdSWpxes9M-M8w z(j1XhueM4L4Hn#tvG?*3MYTJuouUpMeX7+k z13gAdt7`=JBIVjhmg8owp6Wh&_ovR&+wq-?g$e56|I0VfW{Kb%8C7bci(`Vu? zRPgLBb=wePtiS4YKOfgx+>=MHw&tkK?Z(DexZPbSkwansSFX%46e*c9h z9HcTQA>8CzdXLuUrOKg@v`1r!TJBf@C#vjgy-1a7(79; zcy>9@he-`>jzhNng#BKS)u&7-XBxlkDFqTBeKbL8vD&3i!CFn&3Gi23H zZz}h!x-Td=2?E#bV|HM{8>_(qFxrN0gSYZL)naf@66Uz3h>!F~vj!-*sjDN>TchiI zEv0xr{=c);pK8(@D9GyztGi+MBpV%FCIP;HxtLKpnf|=#Y+(BE+cT1oJ-|4;h16cJ zq0PZ1U+c5Y2rFngC#~k>St9u^w2Wi-ECURjiZ2Vj`L8d>CaQ3Fp|wTN!U^hmh!f}F zI6fClCeO9t=6omdU9pJ2SM&2;#|QsG%^>%Um{yP150(}4HjuASibU+*+>%9xq$W zOxOY$2-ND}%}S)kaw&L{?Rwc?3%~C&jc>SzyvQ*>eX_=Ms^GYJ)d;?Idk&AoVR<%# zwlUrNtp*}#+B$V2^-^|6&}kUyIOYnl_u~Z439_8E=3omw6JR4CBbx#ado7GE-9E+|Ml?=kzv7-dLASc zX)^9$drO$c{UWlrHUx0)99))oaVH)Dz0|hp%o)rs+)fFP{k0>-hQt1h_$9`PFy$Lz z>)!nmGSPf6>WFm~vo%i?<4rgJphkR5ZRP@xWr4)miU*=42_ZWt|I|h^b` z{e+XKBYh}pWyIGTDAgvlv>!tcP5!50MJxk(4_#&WhC3W@ z;ZCCv=pz(%{GwZynQ&@oh}Ty6*)8+PN%JAD66cnMx)=T&vK}uhTKQS6Al=q?KW%du zs>;No8hg&?UEU4?5|XVSU4JSuEb`p^-org0U4BQG+knk(B3saal{dVYQ&BG|xR28S zuL-rh$WI*+hO?fbi9GUmPZm%Yb=DtzD_*i_F8bqi(7>ZN@*t7UK13vs@CCfs8KP4J z@FB!OQQXJuNidPG-6KVVpKS<(uhsG-Ghp%rPw)=u+lXB&bFV6ZSx+}X!Fxa$0WVW= zO_GTjL7znE{nF0aA^p#DgJ9}wBX18ketH}}z5Bz!=K*Yuxb0(pK~2jt>`^g3zvsr4&0Nr)u-4e` z`gl&dEb6X_#onOnEBK*A@z>pht4Vgh@JO^rk?}v0FdYdiGAGP>^1Yqi9w@d#%ER}8Sd-$5$kh=&EiT${Na6KByA-g-V@%r2z^`kqVKY%;_07dmam#;o) zDYqE)TUvp6>rFZ-;Y{Ki9_EPT6QAr?m zz+j!Hk1O$tIm|c2X()3Kzp6YEN~iqeo`GrT15+P`W3?3)iYl6OWs) zaAeTCuJ673{k+PZuhvu2EG)+aa#k-Mfa1>H>Gk<#&tWKSK)B-Q*l+r}llf+<#``Eq zC^S5+qF}(p58l{e?$xxGUia(7+K<9_ig#DuuF}Yn0znXyG z1IVLhHBW_D{19GlPiR1<_ItlGm){o9NbnI%Y4Q*`rP?Lwx&5e?j@fC8D8R#s;T}JJWp}m=z)n{iL^0}P@7J%~#YpIPeu>m`;QPKw`pZv{ zUR}LxWAu1Et`+F!`Y{QV2vM=M1m>k!`O@>4AUgnH=;XJS^Qy-uk|YTqF@Ac4mRV@6 zq>vQ}jAV;)fLM}wwy~y4VPxGYLns5CCfJP^Hux;=4xTE82lRN%hSl{G;S1r;r9*NJ z$!4X(I;=_-`XdV#<8;!^!=3+2b-Yl%HzoRW7V=}bb*1NK6$5bNFE;I)iYGDP2+SDyJNt5oCx+2QKmFsZ^rQW<=5fsykT-rwC96=J|3}Sd`RRDu2e(j(X)0IRuP#A zW6cjNUwyVe7(MSzn<_ZtN!*sxy7+a@I6K%v5TbYaw@AQTbd2wsJx7E4v-o3rRcov2 zL65nFX!WtIDXsnPDpPi2PVEsA$f|-K=a4G$fS5%%c@TV!N>>qZbKTl4`}J0^PRQ@>!`n>y@8qP?wRr7D3%&pS zeUUDc__+z*-FUBW+sr6GeqwvL_T^-f@iN0kScX^au-PnJ&T(_3;J8#@$#$Z223l2p1U zJ`Q0#-09Yp?LCslI=OA4tF7bS5kBt46#zBV0kHn{`#KQCkPXe05z`MxgjIG3&YD^G zw4s2{3D??}*X|OjcqxJe=3;fq0jWn6M)S1rbR6f-7xQCk&_cyajW|1rHQv(FLQU4z zYI$2fztN~=0Y&07)ID?d%)q7DH`uevc#$P?K{1f&v#Vg+j6X{x(WygixB1XP^Y>W4 zb&zR4Q|9W$w)Yj~FU-LVvf)Cr_Hl3h#6RbIooz6Ak^j)U>f4JML%MkS3J*VijvzQ& zC89Jg`U>l$&5K{x1=K`?~Fo zQ$StC5B-a5tna5`nxsN2?dwfBfCuo|bvej_52mG54u|;fLOo?sIRo3Ym-tWW6Ps_y ztUW9Jf=0l@C zBf`ZX2*Av5p+4T*^bQFE@|2dW-q*dSapC9S2C0qewV9ePmvhv{+tG5z&Tvk{dd0CT zk1SxiFRNBV@k?kkesg`^e}~+f%lHh0e=MOZIzF@R@pahy2c=F+e76=lJHkDtsYfGS z^GWc5`VPvZ2n?Ef>M<5Qy}tf&I?tnLi$S)ZfYY03F2U3qBC<^aHX&=B!0%j=7af(RVYy&;Lw)S0*)PnNjv%BoXM%g(jQ4-3?b zz)`(#pPPu_7~VH~F7?=V{q(lO)5#4m?8K#N#b-3csmVYgi>UOyE`JvT5}m2s2f(o0 zkMbqX-%tw#2c3TnuG~AdJPqA?pn6PCOk@o8n}dg$Gr|)gM9Nw_Ev(<_2G}9 zz)VH}#&Jr1Guayv?z;Y-284vd^INg|wmVqltkREH5AwI7Z)t7+3i!)y5`3E}7zCgt?S{Lrajy7@Kk_6w9 zF-f?_NAc1Z8#Z)m>$WQ!!70J_m76KcwmgAn1FkiO`y*kd+}@i*B@*?>6dAe!N*|eA zf(bnNGa{v>_@~Qw|G;OcvZQSH#SD(qjiqPPcah%UI|t|Wu6H16VG$!dv-2T9^BZ?_ zaC!qA!GV0p{qqgFW)tbC#|2guH@8&pClKpH0(@vSR_Nh&sLo)tP8XqmOw3hL!7s>u zOPz1WTpr>~=WfX+vHL1F`3wHeATXLUc` zIcdA^f?1)3YI8oqrG?j+!U8UCJB5zG@^iqKPRszs^li`yMDNn$-vX1G*XjUFU4g z4-a;}e4G4ZW|zhW&`%5JQ~h)zQ&he*TM5PMi+EL= zbFR~i?LGB-iD0YRUvz4)mbfC4o1>k*F8IOs)*cHXbTR0~zf-&HP*kykOGO^tT1hY{ zYhfk>cnb^dNY`hGO9}k){Q>O_oz-6Zh4T*%{ zjYiquq^sN`u4Lb$GuEI&PMasY-OIT2(G&8=65!>=svJ0Wai`Cm^!#$WAW@K?$Bn;J zpJ(!*KGiS4XL$610aM-Cv|{Qq7-{%b*kMifW+^6D2lFE?Zirq!um9!RiI1!^4xhy_ z3-@h%Z$}vu;WL7zhf9_W+m0+t+bS>>VKudTh6x#I-<5wOpkl!f$JBE4^F1Dp+TVwK zdPWRntBC7lL1a|=V$$JYJwB}fZC{jp+s{VsXL2pv2TzhlnMDF(ATuLuJC!X?;Hd(4 z>krty{~#dy^zOx_uERn6hQLXb^yhd4pvGLHBDbs8QBoNGUH%T0)beK|SHECH>%TYm zv5xmwpFh8c^h;lB1^)fsBnc#&U&72k`~oLkid$oT_%$d<#I3?EP&gRW***J=dKAHl zeH*KO?7CnZB9BjB!Tol?#eV(LG)`@K+uxbQ+E4DQ`Pw$TOVb9sPOS~jLsD+sK-ZA> zwk8~PWh1h=J-5?BgXOa!DC}AAVyKbzzRA2c2B-VL^;g(|e81qh8)9pJ@NV^?=>p9FNgT{^e6!xyi#UCskwg0gHZK?xCk*7FyYW($db57Q*a^V>D7N0yIwWI zVTSt0E;I2w)>)2yfz1D13hWlTiEzUDfcy3wZLdd9Vilm>I%A=gb5f)-T63eU?XWxN z)*JOVDrFJA^Fo?6{{bl+w?n4vrv5G;;URkZzF>20*|QW$5iL%on?cqrXcCQctU)Er zc!RT%_%MJ5H*}{bJ>d!>8DAW)E}-cb*={l*hexpm<(=SL2ChneJQ^4`Wxq-(A)Xne?-cz1X$@g z1$F?})W2je>hDhfdO_smflGhHHw^!`FYzQlQdfy*OnlACUMTLk2K@Lh_W0TyA;3Q@ zov}Z4f;pm-|6=X~ylb~&5${y zkoV77cHP%+F&Aj)TE23fqy91&<@~+Ig8!82Wbe3VcG*Px8#xBz6OFL7X~GFnEbUC2 zr60h{oHFb-;uMxqAxRLG?=D3-r&QoF?GHlQpI1ZIv*-F&kSSo&&f^>V4mOSfI%gGP zH%@1-bxX8(XmhKv9VK%%_{hqk+*)T!1>*D+FaUNJp@AUS6^y$ZXf|1Ac$7FT3QoMe zJ=c<$@%b=dEE&y{86K`JMp&xiA=;_i&#rb$&8o>-i)x-qgZ$k4&>|m1!P+6Wv&A9R znzWIo+^_X|zc@!>-=Oy~zp4^VKkxeyagD>1p^=aGk@a3TopS}@O1xyWe_xDxc>0!3 z3aG$v%YFBw31t;|`^hww)R2zC8)B{L56La)hZMvE1lkwWZhG z&!hMLfI9!hh8>;{<%qEuSXJ|LMIbQ84AzwKho`0znmtIqlw5@rL1V(Q-J8*9T$1~X z%S$h(`{$(0BXL)yg#M=4-~~D185&X*5Ea&nIHUwl%ol9IjwCx!6Uc7SrFua((TWI< z-(QUS5f*1TTxG&z&X4`fxwgwshODn%u9oUO4j8a}5bd_|&;6sKdc?pVFy$b|NGfbu zUO4&mpxBO1{9r~~ACF0<`WYj97~wvRZ4fQ18V_fn?yP;)_KSg&vfrCT=RLb`aMV_O zg{S7GiFV?`)}dLSs5(1qG^VHmSBn>~*ZUoOa%FAz8s_kr&mG>OAJNu`^qu!zBhT!| zu*!r#e}RhSq^~TP-bjf{u99^341&DhLQFoNXWKF5=~hR|iyYnu8}VDHEaeb=k%oE$ zsG2@`1V(69v5fJ10qbhnX9BblFG@^u&H0)!CPSUj!vFQMO$#=H=viS7+VfDjmSAs% z8-7C2<3$C}$Sw^$F&Q(kG{bF^KIvlheR$$$-~?8uG`)|i>>k#ie|bJ%{lgD=A3y6L zpuxc*h~^zj4o|!zDxVblp-@Y{hTXeaGk_v?(4H`FAeEDeVI~E2fW-Yf_{&0ti8)b) z7S9d#L1%1KLYL!N`%1Mc%a z{3!x@)%EQDsB`RwVYWxcW;lD#NN6^B3nZahiqrA_#RG)RkRX)+vi%`&0)S}1x4yt$ zd_>LYJI?cE*bhetJ7`Txz7}t~Rcu zO0S|)#3Wf8c?ThFHO%-UHW-urv7AO*wxK@c!dKnqshu>w&HEQgJ>Ab2Rpggtn0>zi z{%EAPR={6{H(r6j0KUVQr;=^g(LK1lyF!s>#b|DC2mCmpsdaUGxogTh)ib$czOCxcUG~$Q<)H%pU}fzBJgizD_IXhOoB_FuDa>8DD9} z*6_#&?>qybrNS;(ILre_*`#EKivZPp`F(IfLD(!uyv7Fn0cXpdiOi%ad4-?3qKdVS zJh^t0gXi-`c3tfRYH4Gv@7{WpNOhFV&AvT`AKfAwj+654PI#r!U{GwR?}zpN`spu> zi|4zEKVkI?(*_2YcV|okCr_u1Vel$0vZiJ}w=X+i<`?Oa@~tKYZ=UR6VC9TF)870%prZhhCm8tc0YBWWG{!7YDw2l(XyH0bLrjV*A98;4Ce%2;m_M`E7G5w zN6Ms^*9q<6zi8-12*~dk9;acW6#tJFJTxE$Pq2YC0pOgyma|vr4L@?M7ko!S;L~K! zF})~}?GQK{%-^YKMK8(GQ1@6`S#BVJ0YPhV0%t4-R%mIzX5I`8z=qJsr#c^A3rNaD@c|0bDT^>C*muDu58|upK<6m9PRO4e90gFcXZV~(xSSkY zTIphh&w(?}tB7|@P)3fJjzC&7_uB3*FSTVqT(Gu)o4H6)W=~6H!Ww_-RtEtIXZEp;wR#TMahAQrev!2T+YbFj zs*^zr&6huE*Ts9=s}-*xGtBT^pxa#E!*A{7lKMQ~mq)Zk-nN&;#Hsk5u6fIG?X;Ke zwfjU)3G)eMHBhNLk&^*gr3tWuaI;zTEC>6Mgg=g~PC;1x-PbJJ7J&#&_C>Q2;YcJu4;+KP1Xm$_Fa#h3Z;7&w(pxzU?nu! z@*p6+Qq;Zs%f6QK$D(hV)9N_bnM_ztpSNQ?XX((9U=V!B=m2=`d>KB>k$)@+I=*-t z$kJf2eff#!O24h!UUguH;ds2fnoNAX2U>t{#SiMDo!`9wYpL42Kakb1eJAo)HTlm>zLruD@}=hP-^H zYxbHGv*^#|;M)=26Xp~n5CxA8}6|`*GYT#gRC~9h(M7l zd%>(KEn;}kIsi8JrIdz43+Ua2I!4`+?=LvGJ6N4?%0Hyr`M6(=Pkb{l;(OJdeot){ zkcJDrx)E4U=uPMFHT%quy@ol=&;C1=`QmUQ-Sn}P?Jp;>BAs4zH?AEyFqvzekVGvT zB?N(P49lr`ovi1E)|=WR!J_nE)O5z+enKZJ-P`xq=e}nzqj51! z-ickM`z2Vz>zwW5l$HpqZd}1ss*^5A9r9$l7#juCKuG7l&i)`1Mu-fK9RDcOH}99; zk2rdpq@PIDaZ?9eas++5xO55ZN$6yIi%Ds4Uje4n=w3!ug+ntWoF+sLTB>NIW z*?25kgSV;s_D|V3_Jr{O?u<26;ZtllyG~d7XdmDWnu~QrE=#rSvgmR}*EO>=oY|S`lqR z<2j<(zRX7YD(*x8KPaBrzU0`N*c@W0oL*N#T0N1yPPhQcG<&3u`Rc|r>D?aC#kFM| z`EXyczi7tKC1)Hy;{x~VI4k%pTdLD>dI)q|)_aL0G+G{i_m8Is^5%yS%yNUvKRa_` zc@l)G%lhbY2p6WkX!o8XbGy+R<IKpw;>+Y@i+$UT zRPyZLLG<>S23M~~MmQmTq6hM1q|-HOuaGOBCH3NIOQb+1_D>2O{Gu5;62 z-4CYM|{lPimX8?vE}UXt{?DJrDfl{TS1jDypbUE+6_)9Qj)@;g(;w z0->-p-^GRZS$+P-(Q)nWRq@&O&!`7vT}SYY3HN7Ws_8VIu#IB&Yxr=lb8uO?fXIJ3 zm%i!hc`lxl|By)c#4UKLC?$vTtnc>|3y+OV`zvZ*S*VU6?|9|q_`c~eh&lK-lsT`D z4srf(afInPw1MECwDn@Xrb4pMqLn=5Zn=B|rH|pTbvp-8A55Oy=N!8aB~6-T#Gsb* zpHTn^6#+pcGS!z(;MGC@YN|GY7jS~L`0cIkgfKMmd||xwaDRsTn$`&21!BO+yYz|s z`ZTLH6b~9Xs1`*@0>(N130NP)z_BMBHU|Sc$|ksL5fI@_OuD$jX56ewV@rbv|C<=w zBGWvOGZcP10s6`i+aTB3 zw5KTZXpPH2m|w#_fRMT#w^{u)t$bl`5T z`g(=`RmfoAjqyP7;;V#{xnDybs_iYDAk|DT=Fs%FgoKg+S}3&~aIJo0NywPtQ>-#( zaZRtrNw}{7{pYTLA9!1nty-7;?G-!y*OGE1uky=8fZ2Rw+64-Tjg6L1v6Qb<@pPqG zTf7BRo?$ei$*18fj?GDTAXTt%oXWq#It-Ue_4N_&^JV3i<5t~jQ2B$mUyk2H0Fsb$ zLBnUi^^wY30Ty{?S~_6WCsYWtaGnQ^`2sfTndeaaIyU{{Z1aOR8V%CIY>`j=F);I5 zwO+m)-U&m_e~H3I?2{B_1mn{1s_v?~=ePJ>GnSx_Mt1 z#+RIP>m%!cQhCvy$!x0U4jDzwF$`CT)^Tohp5HFssc^<+VfxvBzZ*c*rH<;D=(WOg z5pF>AQdG7CG4i$C6SmDj1sA_YY{AVg`i~>M*A(TKtdYreD4+|w7T?NkymGFMD7!!R z)&WS~HRrOfNYYOVq{YIl1SxzyrtQi5-^csLU(drZ_&M^&B_zy1M$3=klqF<8%EGIuED z-sxR+3kqP-{tRxR+hHW^n9fO$&?no9$?K90nX9^umTk6a+9yC_oO>(_Ds`O;`4%!} zLk)a5s0eptj2{YpL7N&6#gXhF!-4s|5x;xP-yfsUzC21A)jKp(w@#_l?;SPgh|79U zp0zCPzA@DH$9=*5)Q&n#!S{yM3P};82NhnZb?XXDL}aFp)2K--*%DBgT#G^dpM@{IaJ{&D;WA5jKrx2Dpb7Hcwd#$qr0C4&nw zSEk-eN9sw+9QUI0YC$rGji3M*ovSc_u+v!g64?%JKSW347BrkcHJu@}0|o@nqLqT4 zR%pA-^T+4`AQo>F$5X6ygreu+J=s+l7nkzW3zSzRoBKL)u0NaYO4FvduhIJUlvmc{dp!}g^UmYwjwi!0)BL# z{8_{^;!?oO>EckCra*QK)gZxoMQ1diOF!D&3Ca|Tf!a03-KFIjIEqqj{R@eG>LXHg z#-;lHBNL&_bdtpgSAK=*B#+v7y#?{eGJf_)i{iqRAT zeQ??WGw+29RY=D#$Fy8>XO<1gs11S>Q8VOid%|^9=Y*_g?U$g=19|VpG+`mv*`ME?cuPY>5?r+(%2otkO~oJ2LigVMrwH}Z6DeDRLH(JC zXmtFW{kPoTvVFV=baPBcn@*(7^GRIaJCH*@B;>&zB}7EMhWq0J(VgZaHHwRo|CYUf zh~tS4gxDBEi49Cu3D}5&R0_u}gFDvu(s*Ru9t;lF4MeFv8Q9h5Nv>J1^#%|41P+&i zPbDh@HW6-LYy~;mCC`KQLhQjWq7AcHKgors)3E|GAxoiU;$mi1~>3WDT&M-petvVD8xNr%V@iA+xZhQC|qvx6zoU;1OFw1cnXLDpM?w`{3gy81Ow40p^wGI6S(W? ztqKGQO*fnh*Vp^WJ<>GS_L}yZImLv$&@%hq~WtMKOgVVC#?=>2??Xtw~=Y z=i6d0n5FP^mi=PIq~j$0dSEWTOW9lJyBgq3J|Rv0bbmZv+V@&*&(Xu7yCU&Whm_xw zc>vUOcanY_b_PO~jOW(XB-pCd2MoRx(kjl!hvXzn8YmB1{Z(1fD*_b#8ZQ9oAyfq) ze!QW%DM|MBaUURaTCXEvzfK2>y^JBVJXo_sWqnQW=SAwiHnQz;eBhSrDAk|iBY!(+ z;waiK7&10?y>*LQElI`LkfQ1@uP#3WoxX5P!kDy$HzwGSLd37}RplxqK8UN>lyOM2 zX%~{cn3bZ7qo|mN zYOZo>7tY7PI2en4h`*D1s+YU`z%eS26(XV`i*JA0I4^0d2_GDoz7^Qn1pOjfXRoau zmXY^XJlBPBLXtTabZmj}{hXHWs#UO{!vqd0?~lR>p>TL#r+9hV?Ko?BFBPDf#LM+= z-9xe7NAkF2Y1r&u?)QPebYDJ)(h8Wy<)|srt|3mXV7;=k zSD9dX%%Q&ib@zQ2fYs5zASL#pl+v+Om6St2&?H>_MxP54U9|$2E}62HgZSbPV0|Eq zE!D!sNTSf#sCW5k>UXrBXPYMpa#qzEQ$_tD#R$8E=DD^7t?FHP5FDdQT>@TC)!=?+4+2DXe2pEQi_9Xdagj?@T;_FCB<}KdxOoLO^y4 zLm*wyL-fGuSX^oLV{0EMt?5eRQkRO)?eaKKB8vd9Y4D}15arOsf3-6=k)IpVwCW*y zTE@Pc-u-O$%bUdC4~E2qp4+d=W`e`L&lHk4eJ_d6UFNuXGVKAk8nH+5b{8Nvgrl%L zpsG-yMA>_V>hturzfi8rzfVe}mD~j1ce5Y6s?o?{v5VT}bFG!%`Q#^x8f|_5?#NHG z!zE;JsCXEH(UQ^tfc{z6xXr%ynggnC1!H#4Ps{f`#0F$od@jGH(@(pFZ^Smw=#bo| zv3~>{sAW4R^XHPV5++A4ZN$b*H@;7E>4wTlHm6gpPi=Trn?B`Fk3L6Rcfkx(N)~A^ z7jkDFxqa**MD_r~7(fNK@=4NTkb%7lwkr{rauJKa%wKP}k>Oal$szT*DP(rMK9=|e z@|a^`b1%5%Yd9Rx)kAbErSpRb=bI}|BW26fYlvz4l~qOh41#6BNcss&=W*X7)WzOm z5N>u=8X0-8o^ZtC+Z1kBL4NZ_AGs&Kav50M=X~cJ?TrhTQ9j&ZAkPr9W!n{nr`5nR zmIjX8-81_dJ7e13Z*{7fO$K_!bqiC+mQ|ROUb)(S&fG8gYKGIT!(Kyr9PzPVcPEom z{`|l!$hkRqO2tJ&MB-JKUPN+CZ^Y1Gcf5nL)4Rg3eDHRZHkT zbU(OfK~!Yt2R+zEYsbeB*NN^-!cTrPUbyzigmO3F+t}{EGbj8QxYvenN$po9F~E-x zemos__}tIC0|fj*nrJ>I>mWVLf|K&S*7f15BS#0B7QH7U(+R@0EB*L=;2WGb~tSN=aXclk7N18;*FEP z*Y%N7cb;92F@EQQ6I1>{BY2U-3pOzV_hGJFlrSr`?$<;tpyk0%_O`|tCw+n$CFEer+NGe@!smRx!KVkH)!ERfm#O~RkUep$eueYaG+5u@&0 zsnFOzvSK6>%U=ZYdXw}!o14x$#>uR`92(s;#Q*{(I*n6ppQ{7$DfA?`3LS#!mn(Yb zDqoWDogmt2yIRig$ioGJ1S)t7#^v2Cy{ujiKa$R#_2rAlf)zP?LpBFQ0<~eEhS#}Y zp!_%gc5@+5mU|lT9{U;))3&WD3vM+#1?(SxVk6ZD8d!+3;-(YxJ?IBZ)laeX4#OGow%v5-XL!W;UIt<}-H+_( zobD${++yO(0I`aT12|=WPf=)P27{Y)RKBRYYbhCT2|!{gMPlw7AIFAci9_L$(EHbY z$A{pA?uVaA#Dq~W2c6AK*ha@kxxC&Te9NuSkFyhQKaQxL!^Z?E2<*a)iXihV?Zi1c znfe7Mw|bA+wt5^jbKzb3HMBrtekr91Qe@^`D591viDT;aTJCF7-wK-ZJkaX89P40_^{`;ybeO3>` z0c^!<9TqmI`Ha%@>g$Or1RhxWzMnApH~MhzOc~PsAkUCybi|8kQv?yPVCp(?1okPv zFN=J@Izm0X#=pgly>ef?-4G8DQ|Z@s@8{cAjLQ&nfMBW7VZT^xsp%iMSW0(t9unh{~XEOJLd^6AeF{zAgrMjg9SY~AfxRa={Q%cUK8gpk}B zqC>}%7=_`hqusQ@(~b;f)Q>{8y=(hc!{?emX@$U>Me>o&e+LWng2l2wd*+F}{^8g2 zs_0yVq;}zUgA-!?_%hAC?Wrt%o&E)QsscoB?of$7cNAZ}bObUPzpV%|g9Qkuv2bD6 zz2Yq0_wT^}DG@sqFvc=DU#qkc6)y5-EA|9Mlj8o--oay?{Gy+1Edk&TCsyAc&&BgpwaYvPcjm_(nzrR5E=19PX?&Yi`hsh)s8O zRh@n0<6+2p{Cc0j&VrC(gorS!XN}wd-hetuKaFNfIgYVmV)0h+uk{h_B>OG#EMHuq z-8Zp_1Ff{QE@x&{D$t|e-?)wy$?@hMZO#xOX=}=<)fOw4w_ty*;K9N<05dclC&rzQ zriIO}3uRH%i$O(S$gc}07k9;8mk^WbDu1$dWq(W{M-cV8hgora3HPksM6o%=+DxrU2+~Y}7qc-aM)3uTh zqjPR=yZCz_NWY=iUK^S%=kCACns%TCosWSOikrS)tzYZ9+sQyGCUY-$N4+gS zNQLXhK9}bP8TPrbVUc^DU)S}Tu?5m-JW|E=S57c%pSz{Z?J@y+WXsltX2K)Dxcz&j zEClD1EFm8S18SE#ja8(W^{L*Dn%udZ1qs$RWsv+pW}ih*NdBF9K?VCA6AA+fQ~uMG zeeB)rbVCEHQfU4eg2<_xE)QrZC}XgHj>gJzxIP}26&p5))t8_Omyfh9^m9)Ip8`8k z=PSMXU5l8Y-XO62yD})LYDeO8RX}ef8P*)a`uo7g!rY37%hD`Yeojr5gZ2-9TAV~7 zOqF$akna-L;+ixoxFfsgiSno3o-37nFt)%4uy6FJPr6Xba}OpGINkV59~z5q8*g1d z4}-TakjpZzC*ax6?kWv5tIKdQX@QJ*o>qf+tAA$GH+X&RcvHZHu8c<^Y!bupz)#pI zgxvM+T@A7>2mOgvPcSb(KEkXl!#!v)j0_7P%Gdx%d<4Py`S?@4EI@EP!FXnm7H7Kn zV*UO^a4`#vNms@Fz1(HEx8K7QXf|-t#!vK6p$nf6r~|(iK7SJ5`JRNz?}_dZ5ef8V zhB2B=mGilZO#OxhL4m2E3->t@Va%sEXB02mkjx|6Q;O515YoGN@clFXEoW1co*w6E z-jhXtR&kcxo_nHutq$W~vXQYR+&_cEXwEa?UXensj#fu6nERNoUErvElNUU?($VJg z$QVQJE#1ymq+E?kzJqBMb4JUs>w+7%u+kw7jgbMP1hc7iylFjN#U3FEohlOXVRj zjaT$(729E|&k?*_QBozNwhr?}nBByL#S>4I0R->8y9KpIA!j_aU@*@`yGryykKyo^iGxvCeR%0jJ;`^7 zyLcv^7<{5)?t^`X$6-;)icc0?Ez4XMe{TD2dX}#&(?ixD?)N&LxFjF;guYyLTU8j+ zd$TqUxgS#3RrdG8#gbp|!!y=WtrNQ~Ab}CUByR(MjIH-VJ75YO9Aa6jL5AML>9^tj7<`$Vc z-Gd)WUh_FM!kmAY6t$a^E4++lTb#!SS$8PpVILDS`J7RYQ8^JB!=J= z5+JlhF}3n$P@wd8w0#epzn?c$~P{nbeGX{H$6{uI4mg%T~?wf=?zyA1^; z4Pvi}b@Nak6KZ?{xDtQhS#6Qb_4k7%y^ohLv@xr5t31#u*V%(u9HZwp2&s(BElu5P z`L4Uww+#?%DbDtdPsfUUqMMKy&+nd*04}soE=pG0>D@A~0Wi2{oYCFt2$OLY9s{$- z^<}0G)EGrN!KmA}{BQ}`+>TLqD=eP6dm2q1YV&KcgN7bKB|g;I5$n|+&7^a$%$dng zq49jgr{_EG8k!vL!SkWM=nndi*quAntiLO11<-9=>uzcBDLYy-)37|MB40j6x)j_e z=8VD?j%j}%7j!UJA-yIcd3UD@7Tl1(2A}@Ua$&=Qoy!gxV2Rm7Z@`JmTVYV(?>Bw- zXf58e7%#dY^$zWmLyhEe;TGRLn-QGhcv&MO)_>Wz(jRlPSokFdN2oQVo`);m7Wu!s-B#wWC?&T@Wqq?&mjme`Sz zLKXGf<;>#)_|msJTH5I(?Qx1$VIdHaAyl+4KnU_1dEc3VhF9D#C##9!34L&wi~{Tg z&giZ};C{J4*-6XD%|DbzuIsybq2S=|^zPw%t2o~~f$^QNG*ND8^&WRa%;W;7oxPwVIoT9E*FpT=kbZ_*6 z+=yrMw^2m)A%(s~iY5hiW(L3U<)Jfvm2^qIa{n&RfoRM5_dO7P}b|4WNB`90RkV|Tr=0mx6^xCo&G6tKl_gGmLyJI z?h|=arcR4xXY+3#cez}jRFGPWoXFSZqjm1IUg3^xZ+-xW)1%RT9KL%%1{3ryw%#I& z`CU@hujXi7X&Lw)B!#Yhp*H<60cGN_?ugfLa$^q$>AHcj*}YnllX)g_GP1#K!ZVM zI`$Tm)yXRmWwVe?&#d7o#MREW{Iu77N3d_O{!VwS*3; ziDNg#Nrelrz-1bAR!ll61wE28qp^NyVV`KiUkyC`Fn&zy}qyG{=p>%)87zCCq$XdW9{7bDKL*)M#h7>zNRtI;5>Xv?beg|hF?a^46Y~xDiKfovIv;JL*>0|Bj#;jj*^rnAw^yZ3p&&{Zycsl$=d0u4# zU47qV-oB8v<>Us%`B^Cyb%|PSP!Y`ovgSF6st+1d&^j001W2xm-@;gO+cGWgZP74D zTGRj?J#0*INF~zEiv6CiiXbR6hii}UvEI}3>rE6WPGOTrnB9_RgBHPPIJ`*rOdr`f z$bb9iuE8FoFYa@FVF5@si%1&W2$`?ZhKVcW*!b|2*v@BjZ zAD+u0Pf%TACxoKcGcxBr5ghV93iE@(T{E0`@czq*9etg(8?6rdyBX6{I(W}gXLP;w6( zte^-t=)zt2*%d65=wo}OdW6nEPx}bnJ@RnAOCx{X<3(Fv0WP9Su4YH)C#Aar7z)pT zFB7Bi0NJ+V<#iQFiX1Pjv^~TQFkkzYU9}T#n!h@?--P6o$Fv$)Wt+ul9Wsy57I80s zf42&3#w#p#?3gFb7KvRXz0QneG;roAvUjsHEs(Tg6&l`V#bsbwC{Sg~>R12|LN$@j ziIFcS<8!@5)au1h2tIxUXsb)I?y;GUiA}*YB67mYV%gDIc0Vy}QqUQ|EvMu3-S-CF zBK$bH3ACK4wq7>!Pe~jYaRonkM@uRNly_%%uAE-dX^(*)3`zg-T*(Eb;Q+R=y(GnR z2W2T9-6PVF8aV=c1M;GmdRjU?TYL`dzrcGx{n4^&gBO&CcFt-RyYOQFZycFb9SKe z4M3S!CL{Ay?28Y8wpWjcv z!nKtt`-Mg0?Ex*G8$+uS18Xs+XjTLsXN64lq#ghh#^X2O#Ec&o2gk%eqnNQ=mOE<0 zE}{ENS5#oLTer&%BkmQC19l51#4+NPJbujuk{Nz{G$5<4iz#r+Ge_f%3Lnzt zv9D}^iFendnSV}nY#pdOarI<}vQIx9ldR|fWIpwO&glibuYf!>_-|b4k1l}Ze`&4L zr4`(ny`TsWip$}C#iv@8EI`?TJO#R|aQni4a@@#qohMd?X>c~sg4z0_MYarU%eEqL z8su|jPhs$Pm)wOXg#y_fTW{(|KEC^c1A+X~HkK}8^9U*oed3tMZ_Rk*)!EYxWYiRf zofx2iF5va_=j#B-lDs`z@gcoVCq22MssxKhFR+r+1+lJ@U#Ku;$?$p@BOTQvwlNK5 zvTgVhq-sNMe%0QjL3td~5?qXa@t;GOu=!ku^Xev){vp4ed(!ec5Z$L4X|qtJPkL$< z@?8FevRQM+e6a5f8v;#bI%f;z4YG)A*JBRmD{K9 zF$c77u~ok{94^U0-LtF$ec{i4SbthQF3MM3+)xg<@;t72YYxzsm>;!!1e3*^HT+#C z#h@O|E2gMhE*OGyfHLKAM^W54md*oR?$WRaj{IIgM{@!s2Q5Vx7GTg=iqOvJ+zLt9 zKSN9TrrLT+o)8RPU|6qs1#p4O?|@}moOgDiV)%LOR$g@nA#o9QJCk>Z<&GMF8KKb) z_#oVn3M=kMWNnR(mx8HU=lIRw^6*5XLlj?cPd~mcg^1E(qKEngt^j+mtdDs*Aanrn z^1OXhTtfI0p$E=gH@GuPZgmeRPK4W&Af(fEFJUP{L_PNbM!ga`9*p)V9QOlZl~8K( zI9OMLGthXPJo~dM{vKI0Gtl^*>(%kb8%!Wd(sF9(Uk)*W$e*ZcPhy8kg zp2ADRJ@x^BR=K=mn|?&dK)N#Dy7Z0eax(t>(zH-T?F{bGMh=xRw1vcUT|4K-4z}a`Kc;t|vHF8R>CwY)+Ca}S6le{xkjh+Ar;V7U8g~dq7P##Oyw8XykB@yJ@V)r#2>`n-y|)K zKMZ}5@lHe9y<)OIFE($z_x!lUXNLD{pI!Apdd_$A;ntF1!FZb{8oc_$W=nJ%Az<`AaXNC47g5>T zU!-R;J0YEf1z0&o)_q0~-svZB$W8F(8?8dqVg>Z!2G`hqWq$V5x2?s`J)XtuJ1bCe z=!T6w(JTKXB5GhuhGK;I5}nglE`Hj@k*9NhDiZJfN@)Q)=5e~7-ZD#Q>~uqHj6N-^ zSq5rjvg(daBWc|!MP`r7AV`#Oy+AWN{N$0p7kA=4eN+8w#+ix6HPlLBK$m>>I9ueA zzZ)&6d1q_i5Cps{ye)E8%ZJwTBI-smj@JBt3Hm^321*lIJf=O7LT~W>w=4WR<6%izJ|c#d&C2461k$E6AQ zvp+o0>JZ>b#~=Gg4UmAT=g|-CzJT*E*UUPrJ-8!l%uvHe#!Mmd-RjTQ=O`QouNH!R z+I?yo@SjllwHS7zLsL|W@Y}-8EV3g()6QoN~sM^9wy)?&ttqcPD{NWRWZyR;PJ&^YLR>#+vtXC4AR z)gxGH+d`V5`;%`44Vs!4Sm?2ntvp0}zDmz$Mc0DAmEz@(K_e6A@N1RovRWJ<;=!)+ z2Z&(*u%%^#>!=c%JSbY1XcJDK(V99o+Mj|J`VBaT1zq4qW?gLmF{Srz3OAkxPwop4 zYdS$9X=ErZKuz;2Y3?(!Q50!p?ZPJ(yoOws ze0krd?jc4u%=o#kW+|^~rBe^<9NAyiR3l-zySXhm(eWOrhH-V)ayp?Ue4wk+qW=tF z4yRtfDjqK9p|vEE64L z_njro8b85!>H@-oHlZ<{(m1NzNd9mvfLpvv7j^+AX_K9(H6657qp6;6^vq}5hh}J~ zwA{wm6wStMUJm0%C;aPkPaoLcG3R~s3TEBN8Nn$iRucvh5v{^Dm_!E{5L$QOSx%+5s`Kr_ zx710og?7m3<76y(P=Q_$18Z{doAVyJ<;Ha^%cB`SVGg#!a`B~w;^)Bd!W9j;fePKn zeRVe{{)%e%#}6xxX>qH^eIdQoi2H50i}J8<`A+8ot?Q z8(MZd|MT(TnTekk0m=CBy0B=lU$@8OE05j-G#K=Pa90F}x*39mM*PBNVIGGQe`>KM zV$yL? z4GHF!rz^5=_is<;B^r)8Y>Gcv z1Pv9f<19hTjs+9=KPPqXIiwATHo6xvH^coZS*bMS)jNY21P29DmN$Pl__A}3x_`VV zUdx*1@I}$92OBQO2MH0lGoOrA(#CtCcF(ZKt*^L9&hxZYkneGJ`0MY=oy^2ahN`{f z?RI`gM@E)zF*5dOetTS<_qa~l7TEs0Ws+friTZzOlc&Jw-Zch*Tcew?~TP8_2 zN$wktMewVp;u;p>m&MGVGnpo+o??YnKkThi{=Iuqra zwAHD!CG3M>`x(^!T3?dx5Jw&)s35q@4oPWSdj{f(+XnfEr4B(HeRCN5Z3Nx^UX%Uk z1&QlNZlh!K7mvuF-W3QIt%MUT9lW-I4EF&JUL_DTEdAI#X2}ypaQT+2+wD zKB%)!-7J`rHwAJLf+366kE?Ah@2jhGy36 z9A2WDgk9ct`W@ryDcKpCLJVI`K@7rc2JfOMtf9Ju$g+9Xn(SB4d_AxP?N^lD_om@{ zLk<8k-uWiO93D5ce@|QNzuGsp#8V;N`EeZSEV-yo*QyFpGGDX!M058clu7rDCs+R< z$;qbs!1!P<{4%-)JNx!Lev?Q$>&t812xvH(mM=o>CI}P#MUOW#ToN#{ROBzi7rn7l z7y?SoZkT&--xCl2)oQ&thu{+KdwLPl0F;m!3!x5kqvpa#>86fle>EUFIe@B8djO+A zZGPUA+uAq>8H0Z|I+{GMI)SpxUz-h7%0{TS+e2-S1W{F~Z2kh@xbG`Nsq4;s%M~}O z4pThAA|^iaF(10y8*P_Y^c{9Us8>4kOwOPnXXf>31?aDSkA#ub?hVbsb^P5bk0$%L zefUQ6<$wD1U}(SFMop3yB&Jcn*B>|T7r#9v*WqVhBbF{dVY^xNj9!<+$*!(U=m_4P zB_{TKL-cEM>&+h>W3PD72M+2-JZ9mu6yIcy{u$0~muf%=`#aOIZHm$+0f`?T1sZY7c}q*G-1(KM|Y zR$b}`Xln9%d?T~VTC@D&6U;ysHx1Qa0~jsXUKAehE*qT~?yT@$Dr;lsbk~RB-y!Ym z-uE{#y;e%m*kBLW&(bGreQ>bSK|hZV8M^gkoH4HgJY0K!QtaoETgDHuz5CPA*U?<^ zwzJO4UYrD&ou9zEAp=CYrMN`t;Kg!CY+KD)a5Acm3y@{9ZFunlMYvb}fssao44Tt)Ey^&_Liz0eOvn~VU5VE{8Wz4cp=rMP z`Wg?RrdBD}v~an7Z9O(eq5-IDO&0c7W9H-yN+jKGcg5h20m|404JfZa*a@xpKrIBra(HC4wX1Sg|q_5TCxpPod;=obB9 z{TwHRj%Rz0{P#U5zbk&d3&9lSX~qX>3(Ji*7OT(}mm^`PlM@^5wt7 zgijgklXl;eejDnm)MS>gpW!c+4S|{sU}`%OpziAFnx=4j6P`kf+B!H-R8F!Loa3_N z6?pdXu`d-#b~s#>vmzU3?9V)ly*!t=_HIZQFCgFNzeh+(iAj7{!>&QbcQ1=-e_s{{ znEYc=F2O!>N(G)#LY>D~^##b?*U_OEa>{X34k`B3$IiuQ&yd)_{$F z(a&s8iJk^O}P6Ca!;$r!(;&e-fhd?<0K#=5O`43wRKZ z;xr%0_DC&cb6qXQ0aL89%k(@hA^HRu##9;bH>`q)$Dmqn$>;omw)K+pC+fszl73o$ zD;EHqKI&eKPOlZP;{AMFg0hR1Uv1Znz(JBzq5kn1N22$h$Y?9!<1sbOHBLZe!EnMQ z_`&lQ&05yaj#WW*aEz~?D8!?`m*6wsxy3jKkfcL}1-%6x1<7ZLqNXm47T8gAXpO+E7+R;7394;z+kA;x=0HI^Ii8nPd2^F?t2dx4rzcu@eCaD zO`Vv-@n)6_(BrKjf;-!iz05F+P&brh>Lopp$t8OGSR9&mzbx?2p9Sa zd`)OCWtK9?BwZh+ehyb8+!fk8SL@JYjDmSc?orOAO4VnV_)oe4KrVQHjNwV&`VX}A zulNxspl;&t1}dFsmR`Om1@aO5(ppYO=xIjA2RK)2&;35VV9^rK+MD1g`gWeraZXR$ zaOKXZ@;y5sw8^1wJ3VM%6rIs;O?G)qHt0RBF7*;%fmawKI-`rue_reLYw{;6ES%Fp zzqwyXo}q#-pN&ZC#uFCU={`sEJ#j<}C2=1AIsiit=EL#LD`u3paX35!|DRIFK~0q; zgyfz&#qnI^m$N_rE)t@elfH*L*`p(w3u@P3^-%V{z+8DcEc(NrvJZ}X6nte*;YYhH z0J9F?^S&0~??$+cAMvggGpc>Iqc??2xPT507`6J@H2d!rVYrChp8q0weV++g?2Ti7 zd2_+(yuF6#{^}nv(Rg~^%>a3tJa6eB0Kw{C%Dxo-(u-7n&8mOHgvNCqn zb^upM^CQ=fKZ3AXv*;JbpXrUHOyNdw z>rKh7e$OXQfhFt97j5nw?3Z0QNa%9+w4y}!a#ZFXDSNACh?KPN%`I+s0zNvW>4~q7 zt9%ar3dUja8Ti_4P%ZlR;7km|9QBj$JfJkol&tw)?k$-5IDBy1~DX{D5ZRZ+X~ySPk6D+2iy|R(~lQTRdJn)D6)6yru^5dLPUBevgf8 z!?PLFGH`<3d=u?BH_RDg>Q!HSRWLHec7sBWv=2_#zpiwD-1m`$ctO*SE!}~?Wzg=P zN`eIS%j-}zTTkd*^CnfEz2=}P7&ox;*k^_c4!o(WD7qh>b?NpWD9zr?-57psl(j(r z#0_j@%LRhggfI7?5~Ei9z;QrQrL{z661uCu_D_fmd-|+@Xz|uP4#JqRLb(r{z{4bB zx!&XVJ1h5a@KH6BPftd2nU7L}@zY(sXT{mS=~W!wdlQ$l&x{{|;c$JF-eOo}gihOi z$|jS4Rj);q?K~q{)-|OzA{xDYBc^xS$N3BGoZQi55>_iD11Hb74+HTkT{~D;%lN@3QV0#N?2`b zBA+91E+C$oGc4b`UCP`-?1(2N+r2wP^*+PU(csAgeud^t?Tx@fRG6m+GO{?qA!(ua zqf_}&OY{U@7Vay1ohj_pwuUI)MYU^H2dFKrjV5q-_rSkg^ zT!9RG1A>Tcg-I|K1GqW5^JSlu_e6*?Y7)R(s1-v?pn_+7^Yd4{0kM)i>GYG6^nRH} zBEtW#sz}gu;9EM9_w#WLgVG2hqPn>CK6eyIf9xM&onWiZ{eph`Ii-zQ_j=ef1^CAm zQZ72Z51ciuD4%VK?vUyh&CHuK$Zd7>+pwqNG$!me*o7~9&Gn9?7QQ;@{Vj$j8O>zdAkeZ&>A7&lk9y` zxR&TJyiXeX_f_|2lgwwnnG^kHB@Fd_YF7n=yVRdg+jiupZQV;3X`I<4CQ(wPYiFj@ zr+UzCK_%7C?8nWvU;q#0Tp#DRUH_ux`grigBp~&2TIC z9R^^y??dUgW;Hy17IKgx1Z<#2Gl-7IoWWg+i|QOb>JT7_pVlu_{3hHJUAR=e@GVtK z&}<|?mUd$y@r#lCoQ+FMerx*sM?s)fiquXJfKVnoUlY8*z(4j8jm`TOUS5PW1V8_V zi@9Gk3GZ42BX2FMO-FhWpKe8?5sthjW{y&t=b{iCpS5mVAt zi};DiDOj8z%tK|_BhhmQH-HGhqhh#4Ih3}<$dD76l~D5l>A!jIVPR$Q({nDLf`3Uf zk@9G9w-v7PdkHNzD>S=s`tdE1!>K9tQ!ZQbq2e%9%HcYf>(lBSMz}2VtH%jXJz7ha zKgM)kfVNxEKj_1s^%J(Z^6I!)9WJK}KD=jpfBhgN`$qbH>$e!`V%@C%F8e`cr{KIj zM3tV}^%!XctKMuwJD}KO!x`K;yi&yke?NOd%tkW_w+}Oa53RuA6Ob|cG9D>R_@($H zX&(KV`TLx0e<}H-QruHr7L=y*EHq3@e>CGw!lh#+`>H;imwd8 zRmiDk!exkJb{v=GlcHx_GhKstCtI}+t1si4LC#$jNTH;AZf8eOi9@U0# z7->)TFTjz|+K{Uny{Sl&Sc!s?tYz|qzO?Gp>h|;5_O1%LJ38J~?_eDvD^0H5?#+rh zRMBeroS6%mwU@z(DIgje_SN*Kkn)Ldb^8+Lm;JrC&8^ZE>mKjjz3kHLLH08_)Bw`8 z@qn&aJ>@tfrpR<7ll=}XIAE@|`=!S;LF7T7p|8Ayv1@T^t_>{M^4lRx1-1bd$%RLG zm5DCx$d73s6tW0dpX+7TZA9Pv=UL1@5eDK59{T>6`0*}$QQm`T?5KVh{5Ih4`iMRn zE#4z)=9sPBiA55)sWfk&=?^w4@rpN$^qJc~7yJoP+;_Jc1qV3(Cc1lE_IZYqPCwBS z&^?|44EOj7fk=U1NQper@L}!&NmhQoBuyF9c%vJ{!;QWo>n6J$H0TCs-`;9U7y@a)48bcY7YuF5e7h7=`@C zm&HT1jo0r-J}CEyf&VzebUG&c8UV^oyMMhVW;)IHd4D{tvP}}#*&ccemJ5z)9WiH8g8d!p8N2@i7;7aB-T>NH6b zNwM1JVvjmfLHjHy*c_#1BLpRrcD#$6r@+#z{cxOmn~pM{#8Bra#su-)KH~=4t8Cz! z_}e7hQI~yZ`a1Dr^g5nD#&$lc{ycr^!lD}{JvXeWU_3}FaMKxHfzD; zx}x9QW2F8o$vsh|!3e&7K3R!eF0A|GQ1)fCbhUE|vE zo`t-jpGf2Q7(aNG5{M_XunsxO;UQB5sx}5l0ThgO7n7jw>5h;1S^}&yhtG;>63qxHi zrQqLm@&4X+#TJHBb2;gU;84Z~$#tEhhF^L=M!Ubl_y0-31a})A(N)3B#fNo?1(M_X1Ri%I%)kOj;LyjK+KZ@204Blnep-e;jj)VO5-X4|;%n`F$T zB#xgPN|Z*~Dy?T4tWD{>jZwj;PqP*|xD`3a8Ahj4@?Ad%5<6Cly9*KK9dTvu%8{>O zy@3470X&8SjaL>f+5zlQi>K#^|2FQ`%-w^t zQjf>)^|;WF_tbYaJIDK0#p~X+X3FOl9`I)*$EVU-W(Up_MjDfOdcDqZ{5zRjto(Iq z<@+sd{K&Y>ImBMLag}RRwLr38ipQBwtXC0ir}!qzJ&(q1kH9`nY@IVmV^lvaFnPp_ z9Ph>9@G3c$_ot&-z*tuO?V-H6aK<2LU$o*M7?7Kmm~;A&y_9dA?@C7%0s-aq!_T^+ zqimrhbJ@^@-8OFsVzZ)`3hZuh7%P@G(W`3AY#BGF`-VZ!NP1qLLByi{R60~&Z0FP% zbJuIq9omEY2qe%T-f4i^7+lc>a z4v1c!gZ(3ZxFhoydOo!;Bc#w8I5AQh=8ZFcfqeQ_#qDS*^uRLvU*aD>Tc{z2mhS#0n7Rxj{`q`svDTEM3_EC zbsci>TL9+gNkQbP8Xg?{ev+}c+{^uIZ^tdrMn=U{U*pD+0Hxo;9!((vL<4@vYgbMU1fi- z-cUqN@kd|FSW*-ODh&6)0)JTKxL9bv+5iBz_o48q1$3C}9Wt>=PwdxukH&0irQh-8 zHX3LE<7SgAGrG#p-IKr3D z@88*Ff1`9T@&eZiw>MFG6W%C4r=QK;ACX7qpk)B7N%O>M(ez@pKZ3!8K*6)$4$^}U zcwmr~@I9j;(32)>pC8z%=(wLi0HJp%@>&aStB^q|mv)PX@tItjnve3r;%@rg+%qNF zw2xBoUkV0XEOFxHS{IP*jMeru33>sg*OlCuPANz_Fw-RpRNV zlgVW;rNp-;xu3~#M}jDn^GW7?w^9Y?H(z>nNS%s4HJY#uZ;K=+fG=B@U$%Xyz*J9N zb}1V;BwQ|EmG|if1cx|CSOv}buY~xZCM(}>U1Kg!w)vMRJzz*96(EpYI^{%6a>RaV zZJH;UvrdZ7nna2gXAp?7dIYK4GD&((+b0Q|VBmNjpYdJo)hpB>z3wf@Tf~RK~@5 zeP6E(zBltNUN$CGBbU4JmKGaO@PU*xGM8rd7HV%A+!IR9GXc?5I;Vo zPbmYO#%K81eJ$?z`__H+maZ!7qOxrH$o3`T3Bp)q?WP6i)&MerBLsBJy=WeUiy)YUry(imBjF~UI8rLr*=Cs zy)$1*J#3QWKpd)Loj}N+oE>5Rw9!5ggj)y%+ZEZ1Wl3}cocG-NTjK#~v57CVbruth z>Z@*b*u@#*R92Nk%n`7GcWqRH)?%g)i%O8<(CQ?hI{^go#PweT+FdzzntIR=&xF*U zp_y>B=oFzQC#94UT5J zCRdq9r?HzSksMq!mk-?tzST0T4=zD<$D+b_S63BL-j;}X!9K~bx09FpxPks-QliR;Hb+QGME{t<#0D6V_N(>2Ayk_sUqn_^h`QmI- z{@q(lXMrwYTBeIV@E7$NC)Yu-P46=VezT!d8(*TYlR;FsM-0r3xnbxl{XQ+dE|b#N z{<5{kI|}17AdFR`J~iuLoT^#d);ssT|BL` zy3nM4{~A-zG@+#V?JJ1MPG~tV?|umDg;tn`+Xq8#;G@$t;zD5xyz%=@WE{HVYcpB+ zhhRize)f?=ezb<>$ZlU2d5u>YFG&(Fm&gYi@&td>E4xnQWWlf1g(#j2$Nbp9b{Gc( zUtD}Sw)CTsn=GXcGbIg1B+5e$AhdTIiIh5_gN=f_ z@qEp}qIFX7M*Ug`2#iYJ>%*CF2A?8#Rwf-IR^FB1O#V%B62=LqQ z#%h#W)Iz%IU+mQ@td~#)@ptp&So<_iU+W+Q!V8d`0zNjhgH4p^TwA#6&8ILcd}+Q( z=iY*m3-JZk9d-x_b$!0b{WW#=9CPS?CcSc zaA}tB`#Me_2A~z^iHWHu!~8exmoAuYxsCcxI&jEd>Wjg7ulxwmK$@c`y-pjx+Sl%Q zVuy&ub&a4=XxEnQ2c&BvWW5cSPV}A2gn|MR);`7;pLXYg%p70-GhaV`Eot`d~ht|?}7IN z3m`z76pb(3u-5yFW0?}v>n+W-HP^NT-e%4#&|uzH-;^sJPZl~#{KI#BN&Wa8RoE9e z?7PqXcCGIcg(82DdlfzwxS6#`T*fyzzn9%n)wtkWgy2go3|N-zvv`pVUN;iHrz+;w zHBq)^pYUHu*O;#B#^SI?T@m@c=tAJXGW;nj#-#^NPvNI%!cA^do+YgJYt%7(h^qNn z`tf=Q6I<#!TRS9`aXCBl8H_s;Xa4R>P|qtN!S_LDp~>JT=HZw7M3>_9$rff&=I+O0 zeX8x;)$puY^bk{_F%93d;JTjDV#V%f6p|3Ti0d~R-nYT?jZ%Fa3gJV+XwTA~QniFv zQb#{JhoESmwCZvs8{)6~0SQ}dfp%{e5JMjyE>R=7So$Em(PrZKR1mOnadD(t{>)SIr3pLw$uH_=xvQ0pRZp zhhU^k9@0McR>-?>)cw8~t@ruXzmOmaZ>Uyil(|0v^swvpC_lDeJyg#09@q2J{oM|) z5lweiSnUzzo4n_3M=#1QvJ%BoDwXh)y3${&EpHs=`W|Qw0_~t_;`?uCKR0s_JzRDq zIe9&R3%t>{=X8MKo#&Yo)LIx==tLomjgSsq_UTWAWJRb>QWC0}Na&fMz1UQ0_uljo zpANh6IFBSxc#8F5PQFiZCx>8N^?CkQv}ICBO9Nvq(9-osU-vYf$^V50rDR-Gh>DNr z_zD!=SJ)CtK5CbS2Fpp+VdP5qzDAvaoW~!XuUlUkDA1p}y_sGC3y_#4;?+Dq0@~QP zGb*d`p%~L?jHzC)?$}v;jN+w%lcwQj_?;bkf7|GWXzsd)TT_fNMHKuaEl$kHgz5@i zuhzbO`76r^rWFchAY+O}zmOX1kfEsqJ6BO~J?EqEXEb@OC?1J@t+3yXsNzwjdy7wF zs#y0kP1!$^u4_wCZHxYrB!NeXB0)0BnTupQ;Uf-!ZoM_|a#LL%w&mTsd z4x$69!Iv`a*c#uhTpkSA`j){yhd#vf=kdCIM=kr3oeq)UhT^)AZxMoXw~YbxHbB2% z|8#p$348M(&79ljRW-`dte=1{8eQPx!No^~3PE%R(k3Vj)aZ{~dM(N@c(EtKA*%fQFXK z0hrzyIEG?@R3Bb#M-|X%&~D-rvN?%&FfQs`4|+-FA4YfGn)fTSzmcE9$mtAxsa+9S zVU!xy1?p2en^~)$qklN-%Fu}q`4L)*xb16&X#5q7LZcqW{X(CvHh(j(=E^6`&ct3r z?l-%Yt$Sh|_J^-bPp{<6eQxKly7P&GRO>IIvwu-c>OzR|`m4Qt0GsD3h_Ka2=ciMg z{IduvL3!I}3sF3>-WY$_OTl;Qpqx-XC-s6v zNq|#2`uHORs?4q-Sp8NWGw!$}u>`)(v+wVIdrr{*fgzrgNWWU&roG~-K|TF+3R?S* z*6T}B^9-q3fHk@)B>b3e5_R}!tA0c|H+PEyI}WH4=Z^v`QV38Xc|M303N_YA_u&xv zJKn+vS;GpkTNLXmwqTZ6Xg={b`DtAD4IV$>J9m=&Fv{;o7U2M}^vWMHL#OQRhgx|Y zhKFGGD=q|dUZ}dy3SuK-W&CO?%@99~Jc zpHrY-l#41BcOKF}=Wg2Wd#F#@8511*#eDF|TlEDz6t4QAP@m%JLVJYR@CYNkD^-zf zBZruaNe6t&M#SAPPOfx|!95@v_D_c;Gtx}*uF7y_of|3Je&qi3wM2GeI{JVC;Ffk{~qE0RHR?uea|s^ytp5!w_t7 z4(&-O{F~)|d|DowgV$0s?|;VgXJ&;93^3^z4b^K#ZI~uQJBu?C?I^Q^$AySP<9)v< zIUM(|BZ+?O3S~(A2@eGK`QQrdVN_kp;lT%XgJ`o}hJsE=iQ%J>B(Qh5ADCKFi40Rle{$5;jcjGzJ6 zYKpHY4~Vi(s2QQgTAyFVAzL2D)pN)1bs)rcly8Kx3N&?HL~lY?iO*OlCeb_5!!n{6 zDqB4c5~SBWv%SQEd{W;-Ra@D2OO%wmT$0|kR{vWL;`%BBGZ0WC6%H!^6!uHmXT@Z) zzq4|@b#)h?G$*z}`mUS~W(R2ClaW{OI#3GJw&1m|$F>?7KV~ND#rVv?$t7Z$oJts!A=i%Wdv-~QRW@%raFu-r)rc0H8VQlDF)gK%cgEsBI6!-vvV~KZ||8uGTcB@cthl)M%CQx6S`r{71)T zwGey~9OsWO_tVxVgYzks6`4dkbs!?B0^TM#AqY+5xQy{b`u0nG49S!z7SSd}BRqPo zIR{AJgf7Vv&_~Uws3S5vBI9|$Z-`)0xO3((eezOr)E>|z9g=Ib{bFvqOfVgd?cuu+ z)O{qdH3Pdymjv54Sn_bK_RH1Xek$S|0nAJ`f%HkF8Q<2n-6pQ)qnX{kHFUI0HD||cKqRbluu428K%*}+s9p!zlUPo)g zFDCW~9b3nEG3ZUy)d4AY5a^>?=bYNx{N2Uqkw5aQiE`NXcyH&jj(UQU)bO|v5CVy< z@1!K;uInJc%uQv7z4DCg{!Tj{iwdgn34TOI(|qgwp2XOIO?I8CK*_9#6*^<~M zxafUt3;aAg5P<*c<0pv__EBe5=}m8E%qX^+QM0d$AM5*Fs9;}0dO2JI_t(6l?ae{r z>;gb((#eUqZQciXmhRik(WR}%0rJSjZEG&qeaF^USD;>VwVlI=3HH=qD6C(H#eRqw zt?>Pit}M$9nV5ghR~l`%Bl!eT9W;^IgO)|9Qq}hX5?C#y2b-}TG1Xl4J&%-QvzCvm z)a@(ONgChK4yR(l{aNvAd@|&>>5Cyn|BkjTB4Se8{3O342gK%$2>joV0BlTrK~f4# z2EJ&UVXhL2s%EGGGsFEl?ehn=ntl7Q$9n@5m0n>$|4xVdU@--oEtFFv)ZJIDB@dgUIa}$>0@6F&vLaEeB}*fj1>a}c zw1Tx_3Q5qM|87U%Z%z0nzIr*ndZ#9p{ELFRhMmF2?ZSGFW_fV6Dbs_1uvV$E?> zxAz_;miy3QC@X}%;1jn3ot$LES+@kjsDoL9 z5EjtVczkUz5o0z~x$oEeNOix9yxop|3xjA_e;aXgzOAmJ(BFQuH>zpBj|b=G$GPXe z<9>{HwX&RXRPs~c*>G`xIXJhU#Ds@#-?sOHfFhr(6jJ^WGFZ{Of5G>*oyK?b=+Ch8 zeDa%=P={TXcAuL&7pOoArfkewR4?uR;H7;A?n8yI%R?^7MN;11wPjqi6cO?{-GVo_ zdiCJF#-C?%P(QqH-f5qs8wb{gC?<-$wYcy?9Up_9obG5<_m{G>xyb{IGsH8G6&#+! zYrm#kGbDMRFL!C#?@7&HLk|)(AK?X0DRPn(9jl4p%cR<9XdtG0mLhr4-R!Yx?t7wg z|0XBn%D}Ny&m~x)y6UFx`wr<7KNP62gu^vquW|?r=3KD&`Qa<*5c)$~a z{60fEzY0^OC?P?$jOJ+UU-!=&?FY-?s|)iL_+CoSKlv;Uyf@OFfrPANKfkG0f}5B% z+rJe8J;hy7zq4t5w}XVQdyrO`YO{42BL6#9W5ex zhWlpx;#tWSQ+QkP)^|^3xDla?($jy1PW*<#tdQO*YM37`xG5c+xjWER&fuqFq1(|J z(7RTMzxR~*IN>(lJj&QRHHJdmj3wAdn6nuB6exu7V8c%Z#pTby_|e~#Q72&gUIYN= z99>UWjuQfce+IkFg95(MQaL=zT+c>AZw5!bhY^ju=pk2Zqay@;h;5E>8HmTz(Z4Sw zA?91hWpKI)R>Z1+so*#_X*gwOa%RD|tNJ5DI@t}4m;EAPvo_y^1ZtqKXfFwJJ_+UbtqLH^FAg^W#%e{#Lns4NPZGx_lj8ai@U4ln#O4|mOx`YhtvEg5vx4e~ly`1?!T26BO_0?ge{YK<7JtQN?v{L^ zbYeg#PotsJ>37BK=#s+gq?^(rv5z%=2c4Y(;(vrBzKLGvo3UI#k^SdTzJ1_%1DKi7{3*Fjr5nn)Nj=rE>B9vievc4{=& zPl>~zBZ4zmM)GN%w0?J;+rQ_rr8_zqu4#mrWncVS!wz1cIrQ58`jecIRaFF(3H_T7p2S)Y*XE`7H5~5wLumFfV_colv15LM;|KI7 za4!Th8rnBZP%qD7GQvIGrH;uFQa{G_WycQiR>_2>pZwZGu5o{X5DXz9d)}_}5H2$; z1SY|K!`69^X}A0#$-ni7wMQ_VO{l)?_HuwXoL2d6l z{9dt03lnqPl)zaIDrywlO5Kd3XtDAn!gXt_>Gl*uMfudOaIpTY5-z_0fkuW>1avcw zg|MLQ)~vAGd=Xy+*4szqiNnK$XPtBh4#tInrK7yx&8T zQR{0DHAjOHucyU=s+xU~=X^g9>vv8!VDkqTg}p%|==Ab6Si|4}Fz6oWTj=T*%ZbzM zbYOwprfaq=y!;HPmcFuwvW(1i>9O`(t~B0s#uw_W}tPyJ8_TSk)qL-z;l3U{3Qc#Ilao z^iSO|ao%rKmQ$)4{r zU$(DiNQzjajl33?0YKFLd^!^D0qX=ToV+-F`^=6Y)%)oFLrTKap7$pXWY_a%;fPDj zvmsXquBD+EkV18~v+jTa8FS3m5b!3(<8OHZdDF50?q)~hh|8!{2f9DmaDolp>G4_U z%UP8bvrnn#SAwNvRXw_I*SuA*2eF$AYh$eTHNfZ2fAGbWH&;gZTW@A6-^WhBp-1L; zzTFj@{DrsX>$eAE?~mS+`+cj=ftr$h@i2&)zc94$W~6&i)2ef2a?`YQSKMQ)BYN~h zI_{^KpBNW2u?s2lJPq(i=Unsby1y|BV;EpGgkIYIgAd5wFrRmAkpwhe@V-Cqghu?d zuk*e~-?ZZxp3T?&J!;dkomiMugU%r0IXD>fc>~3^;m%bBlV0~-k~t04zRHbdgjNl|uN|Fs113+sq_;b`vNJ7mleiDr!?nKg=-=L8(X!gFGYTgl zH{mq!V_G7)yyP;!Wf2m!+*P%?_~^TghGIgSIvNrS_N1p==A7@<4_+mUZ^NzMRRtpR zvtJV)|3CdSb{c@k^jN(^7$!XZ*Hw3FkSSrjoDhwAu>skw2dJ#98EZ*CjDCWPX#d#u z$8KD97b!xV+??q?#oPoJU3HNY$E>Ng`YEt=*Yvs9(@^(KDxJ_gbmWt!n0_|D5Bo_> zpNoVDM<8Bk_ByU83rb}g-f8X#IDrHxs4EQYdIJ3G$obk?e_C7P>wx!AoD_mo8y8VN zyXvo{$8@5IMS?%Fh2h_wa<&Ab*2GKKNOGUIgC3oZ(C=a3)|`+@_NpM0N0-cex=$=* zEWgGVj%Ag43yul&y3fyxOJW>F2d>VGr*|UHZ*QP(sNrod=%}DAZ@<62uIPXs)BV2ML*3LH zQO;zxm;4v&XQW)jo1*yRlrje8G5P~A+Cu_Y9;aj<$zd^64 zK#|iQ*AG5k(bWdQQiFf;Ld|>+}x&txf#_F@xnJe9)ip&oPn?Qcv69Xm~e}K#QM|O;iyta#Hb1r zhE*5^)f)oRftIjBa=j-j9E=)f$lWpY50J1WPq&Asr`FaqH;;+xcYH6nR~er^MMvAH zH^*Jm&9$QY>?><4GtDWiYR*#4$^zMG7S+Q>ygtWJ*^9T7Is|~#ytQ++luzao9e$UJ zBokrpVegah@G83bRb=w@bsK`KN48pdmvShCHpZQbjP?_5N&(h#`qrjpHSWx*z4#) z6%D_Xs zl(5e)&?0}%kN?n-xYG;-{ZX?LAN7C6#WAD;w-f2NP+(*7v5EbnNu0UF}b55hXnyCs(zN z?mj?^v}v0C_Rhw3NcF!R!J@Ce*nDxsepKm`gwRoX|^K52lQA|eJvrpNQEgdzDj1l z%V;6JDqi38Pn_6(9KgK1y6OG4+~j-8{$(IUs2#6`Z`R%;_!@QeTydrXmwapW=?+kT z^f|A7r11-77ct-CDG^qn&P%4#yEMx6g`tGwu^Btb+;PL1Y5dZ-QOg3T(`T87AU~B& z)W_CeNulXq7r^z$IvTQfp6ABP1}bOb76tIX*TM^-8xde^u7gQ zJp=4?V210Da}Lm*_)HLfzSp`Mu`B=@yq?t$w6U-4EdmW& zgUJ8t5y5+v4p+4VTtq7e(3DrII-V-1+T_r=5Jfa4pS$S4BIx51km{X4@ySIkX%>wY^L2HNsldOc)N)*KkT8uCQ_+F$9u_?^LRjrYCDw;)@De-Ww(#%Fwc z96Kh)raZ^2IpVQIvws3L=fzwOYrfph{bw|@a8oN1mY8Jc0CQNVpCa zEo32OcE9bS3yIRp%q%?`Bpdo4kMHoKjbY9MY5CYD#X9J=USBG`7Z1P~!hehVk9%|{ zVK1i`=O7B62_MC$8~b+6Pu!}5KYp0UcIHKt;e<_2lX$rc_wAFTANK&cv{Y!=C{z5t zFQnvx@>&0T_{~EV!q@Q)c#01$Ai zKuAb@-poc{z4Y>E?f9`=qkDM%3bI~2N|9y(+)Rh*3tfp}U+Jf)yt@|M*{zKA>B*cag(876K5{%D=qxu?hRT+{an!V1x_9?EnL7NsOSaj4n_h?eFr} zA5%~#Px-uG#gv!L8Mp9OUki!Pjo*`w{iLmbe!p+#$D;^EKqjg_6Wi`b1R%e?sLp43 z!(8COz*we*OtshU>ys6{B#!e>W!`Q-aaQt+YMrO98~6PNV!$VpJDzYs6)v`lcP~q* z@#mp5$@s%IaFg0ec8b!)qVEzOYT;o%fnO56`PRjDUz4d}uH{vnkp1 zW5n^N0>S}3nU7zJFV#y=EfR5hzo2VyR;uAB&$#-qwBFKrf`n+fZx4^UZ$I}{qU7|; zMgS>GP;)H5s;No20GS25n%sS*i7ER4X`YXje5>~pqQRc6XZ=3%U^IHU9U%Jif#~gF zN{GjPkJaj+ynfl5ZBZ6OO(l%7N3Tj@(h;$4tum2PhRaB`2Vx3mT9BD;#^G{kuKP(P zH^T3XG4MNVzL$ZgHJVa1sv%l=`99hxPKH{IhP(HE0WN#{fqOz#-sVEbZGlo!;y#(@ zM3XSUlla;5$_mOQYPlNvq1ltx*Fii$XSi&&sk}XfOUB5Vbt77C2&gb4UDiKWB^wYj zy&J0 zT|X=I^S@sCd)W<_yRbwJYsT(nM{WxVy$XwWnyOy9g7<5;_&W6!zvB`B+wmOEXCF-W z7A}oxkmbtafQ5up@ze6Oo`e#5_*Tz}cC)>S_s;}+FnHWLF96?X#+ef4>-0uLkWmZ# z37fA!|7z_8<&(1MMtXB3H1*rvsZcO3CP!*rcTGsQ z-t%G6%D*#q3IWjC&`)l?FwqUjb!T)j@u`zX!v_3Eu|oNxONUphri7x1%hr+pHj6TP zeV{_C+STAxfodpj*y_gtTJjW@glF(LFT+J@w&?zXEz~7h>l6eV@1opaF>@xt;JbU5 z^(%h@Gt361ZyK&Y?sxWy{syv4{6=Zgr%-+j6m=U|rlKu74NVtoIA!K}`X*%yLG~kU zl@ia9ChFp76HSTuN(tGV-b<=9U-PGIerdPwV*(r#*Sf!?E*#kLR4!DW;SM|$3q3(ny#mV6 z!g5rc$79uR_wV&PM=d|iBa2IG*DEWXb4OeB_(ScdR!h{%dT;M%A|3dKgYa0+9^a_u z`Cu;SX~~)oZ}W+xmGu?A{R<$Ph7T^!bH2Xd+EoT3*k zkBEHZy~fS{9`&mWjqO+RS#S+rI5!_$UCIa`$SPGVgoZ`8uT&Icw3tXbqO<*b6LvtrGS7W> z*Egc0%zUI5gF<2{JVy_WZao^xek7CXrSz%`Z1dWb#HlYv`0Rx6M6*^4)na9kLkSpE zak;wAf%5fh<3w;=J=727(64vSE-KRXdFH*xtc|CGP;TWPrM5w!>aM!_*zB7SJ?~(8 z%N&U;>P=HFj$0N^xKjM_>%95v7XbNRz&Puj5_8@BsVvaK+v$EUO>&h)LNeI>e(iC0 zTz%hJ@fCom_&Kw|*_LkEU)*Fk z)smO~7amIn!bsZFw7G$Gp(bTm3WaO^Yb!ZFd{L9zmY1T%X!!`zrNOxRk)%C1${Q{h zyAnokWq0!wP3I6&Tk0yKdV7n2Ze!qo`C!;Da^dG1jweXDsllh78dv_w9vm9^6Kbr- z5RFSL83IbQ;NrE6E^^T6meN7b16s&iX{5Br6O~JuEX;E((g@DSKjC?L z>8rKoLuP#re9_(2zRY>oLcu0~U5>{yNrmY!Ow{mwbU+0Qu`@p52r#%82^P|o>u03( zy-6~o*z7x(dB~vP1inzM*Nb43oa^|h%S5$Pk3>lrir4XyAE-ZvjpAsH=TN#uwR`b| zUoUr(_L%p+58J%lC4QFA>sum}cVf*=EO#{nzHG;vkk@*OK^YNy0FeMgv;Lk&_*->9 z7xZh$jg`eo_E4D+6ChVAPhZ$d1iI8c=+M;qJp!PRg-2X;=Y^2p4vTei;w&FO#F6%( z1syxFYuf#1Z$yiy=>8i@`*lAccHX*@y`VUYG>FMl%K3mQnT zIWwN2BRu+Ig=$=S*hG(bc>Qt)H1M-@#&+!>41Kn_czUfjmixBb)kcRpH#0zVy`}cu zsmTcWxer2!exx6@*4(@B_;R-uxZCTo6QBG8rLrlr+Y@V4_y6w8csM;<3`sp9ZslH* z#|Kzamw67nIo`h^GJum1C-4hS%K^H#3EIDkT1r1S&mfN`PGm~PQ~Bc`a3k8+dQJMi zn5I@U?J4--#Y+dquymTC>h}C#26aqE400uqkw_jj3m$~o_lO&HRV+ZVwqJXB%m;Td zi_;(c;Q3d(5K;K9(ak*6ME&{185`Sl@;WTlaMxTaf;!ao!v7jLpP?ipS{ua%P_f3x zILQPMTN0frUC_GA`opNTrScZ{Eq6_g9#E~I>&>m zzqprT-e=ODZl^+L0o@4+z_DQrp6>6)&k>^*-+li;I8WH^j`I{w%AUlwaEd$^sLCtH zjGm(|=3jERukrm^`|aDcmB?~8e;r*-A2U-D&xXC6>ccjj2)c(Kj5WhvyjSp|&c5C0 ztGoo+ZG}SO^@if+8askU-0Bk6QoSucB@h};)SoOO{qcKNyJo>V3B;J-sD1s%8M0DE zmsf=h5-tT=QAfLT(_wT;!e=G((jJmy9pJHVkOE&ODgG&_%7fn;+#1)}wvJ`14 zkBgW1Xo}5AL9lQ5u zVeti?JL?>f-9Iwvi0Aix0=nf0xS)(7VmS-Ko zA9Pr7DyOg|p0CwL!>*e{R(Gz{26>;WPkNT#7c!O7#ImpV;1oB)I@|(_FrZhluP1xP z-vv>g?(iywEF;4m5%JB%!L}|(z>hYIPu=SF$2GA8Mdlv$Vtxu@*{>uc$nkft{f_H1 z3h(EaS`cU0@+q44>EEx){d&Aaz-65#%e^3gQI1jw1V^p`IBM`AX%l+LK8BwRS{*%{ zOD-%hd&z5}1I25PSZ28A-3Q)hMf+>{x@|v_>XOnwe47trc9^|(#3?E+0zKTwv$>dPs`(}>iUisU5+b?d< zr|JoKLFn6_`or+RFv6qO=O{qP?$YuE{RtgKj$fVfG5z+Z!$ef6h4ct3jUoEUy}pxAh%_=!-@CSlsYvkp#%4a4@^ z=fvSGnCTjbdq%B4%NB_E)Lb=9d_|T-vEe(@I+prAV(2Z7Ps;8!;~YY=1(w~ST-OI# zf{gEXA9T9kqhtnb+|*OzCSKX^&x32`CR6t0thpPG!el$nwJJj+S*s%^E1be3J1|96 zL#Z|__56G9r^n987t{tD2`;XJAke;0pdghdb|2wLalW|UM0hte?{jZZq=!uFe!m#( z9TEVvGlLknqqnxZOMCYmr1OrRKm8%Rm(cAeLPgdNci3X$VCW7VyKnqLK@R>~A7KXn zteh?}rMf3(J&do{nNs8oqCw<%Q`94G8aEEejkzFELid z84B<^%7Q1f2{>k@`n{{iX`<(sOEU{?YbnFAF*Wy^KT++v=H9KS*FibaEgkp+1XmxX z_C!n#CRO<5WOA$S=J`zG0Gb95r}>TFm)>&4o~66-HD1ql{ks=* z+zjqAzoEvV@2T&EG6_XwCG?_QUgg_gpgQ}cKQ9TyXJzv2sM+ziLGOG}+|vqI=18og zTlJHI^ipR_P7*9{ULYE;GY{rCT5TvhTk`tpJ)_h6{$T(x(;?HTcyiMSr zNxVc9$iGOWUs=U|sIP4f=K!)(SZohjN=URuIj^+7NevG3k>X1Wzn89Ast?K;t`@$F zA-eP&tY8N43Lx3?V&XU3K2Fv-XdDm2!-%XoXxscoyyN#T!D_uHBu~Cj=!pA@BEf{8 zw-_4BC?CP8`fc-fKAOGb=3&J^cF`=KRqHj~w78zQ%17~`_MN|W=K5q)q~hAUwEFm< zKnr{Mb>GWCA%4s`Rb(19x=;S-CgD#%Kf)kBbGu7| zGKuE-v>$7$#-q}Lh*PksyL~IP%ia@Ulle%jO%|W4OV>RIz2gM7zSyid@3M!E5l_toX_ zJE56fLC@qV0G$1ogM$*#AN(^Mw;r4Es4t${XQvn82Wk@C?DI+65nc7=0sNc)L!5>0 z@bQ1<8hj4J^wS{C?M@#q+$akMfx<0E-4(K}J;7SqUP)UhfF5;(P=G6zzN&l^BJfgZ zN~R&~?N9mj*&zHSLJF@Ke(0lu?#dkF{if;hQm3DLegn)zP5QObmKn}8p2Imeb0;RTF$(OfNAv*V>HZOCuHma zuvUL|5KZ;6Y6bA<7YsJM64O{=PA~PLwLg2iby$0#$58VK)_ec=VuP=)heE_CM9?hx zu*~VtG-|YkdnYSe=1iz6f1?k9nSVsfB!ts1BRrYCv*TMo+a!lHhMpA`5;5m<*NBR0a+Y~zv{XVq4^cjF;EHbW6mqco6WoI_O@TB>uf#5mDSe%>}BL_H^T9b^-=A*vdR27WX9y~f-gc4yJTYAUncT7G;9vPE-2Bdhe^)+ z^V~H$g*y=VSKWuB^P=)f4!0g7KbqF>^qBfMh4}XJa68++OlTmTPDUQ*6c2J(nFC=g zE5>jA{)#(eNjsku;vl~G$f%o0YVbxG^71$sNC-nI?noYT(#M1mHzQA{_eS(9`lpzo ziY6N#k@FE#ReYKT0o+eiMW0?H^)m?bU}fEwIY++wEq5NZnn zZ=!)j>>fO4VN#34dM3CoQy$G=*l&%$5G$UNg}FY~dx}a=bJz6zzCzN8(%3;d-d~YA zxt_qC_VM>jx=GHcP#o1OXY~h9kmZJNO$S^ZwdO}a9BxyG?|ap1(W>6-hH*llJN7s~IW# z(+jIhDwU`d+qHI(>0eF3^vU%6tJd)2>Hb)O12@NR|2i5Ev9IpPCk0qqigu+@qMXPI z+OT8z60Qj~GhUmLkC{z{1PJMTJz!# zCNCug!~Fwgqfh>|OyobRf64&u8@8A8*_JT{F62)#o`K&~q{Z zPDGuza_S7rkWi8OlC?yJiXh%0kv99YqhHJ4Cm`Ocz9d{q8T!rQ!a+*#`hfrgcKE=; z<@6f^dXIT>RG8dv*VfH0LH!D@*%01>@#OSD;a{uCE9wr1BR~&zH?io@2y5 zbbPEzOLpji;Zz@DVp`#d7P0w12kco!(uDoW5`&UZ=oe3e<4ybi4eba8nPx z-CgtY#)!lpW+;W;l5-ySi?pvFkG&pgFVIUnuJ-qvc6aDv;JI5Kav9+#!CPO7FR+Zq z{YoExZSD{s1q$oOc>XdoFLgy{xO>G|df)HbzHlY2MP4luv8hto_S<=$+-Tn(_bxi%O|`ELQ@T}CLstF7SA&i{P$RLB zptyF!O12Zz6tLy)4~TG<-xEMsXXLm-TDOMbW!3F+Iyl=c5YK9AF*BQ9)whQg1fd|D ze{K$yWmE>y?roe1dw1JWLQ%lC6%Igy`g|k7yNl4$Z}Ej7%=I~aHnW%^`IxsRO>xBA zF$G}k1!te;XU+^BcNvBYxSp`Jv!4(P5_S`n^ZFY{;Nr(yAqQ1phaHTlY1rGu^74GF zB!4w{I4*bz!R?3&#h#N;+;2dGAUQPc?OYa@X#rFWsC7K-cHi2bPp41|ZzC<6Q0pvC z?Nf%hvcolVRl=_SlBPz7rw8oA6j?$D_~@h*$;)R>)1JFCtF?$`oIESkw8U!o6W&xXK*Pm4sny}4BR=4O^ z$HD-@k^PB;x}|9qYExg3nmwWwQqOD;d4qkEkHW6^trz);w1G_P_?L-`gtkL?vd7yW zv=;{7^4;Adj~I5dKDjz^B))7o4ib;Y=VO(R<7m&porgVFPkt+}kb7gjg(QG&WP2^n z=ZD4dI-40q9$vQ9C1I67oou_2UbEtA=>TE6Trvbvgv{`$Zle&CV7>*-J-ZAhvqTf13DD zJ1ysk&_9VWg=&$w{hSDUZ9;S0;-+6AV0M)VrDH924S!#?H{(PL7WWCfX#A%?4lx|O zAp2wA+Ok=W&UI$PrhSFsX+-cWV941%s`1JPjo0&^daoU79Omu3BDH>`nWXcxHfAP%I1#mVUTs7BYr49hV({_an2zVDcQjdm zDbZw~R=nl`qSQnR9_Gs=!Lp60*AYBt{f7#pU?G2`1LzY^PNg9%eI7za?Q-9}o&skU z8%%{e@$RBNps<7?Exa%C`YQb1Nq}L2(xT?M#R55Rv>fd1a&t5F3)Pt)dt=jSof&aY zPMo_o;vd~R&YRMuXIc@aFZ9MP?RPI8J|u8C9Kg;ZGn%e7rcK zh63o5#=OvBSJcMRbRRl-B%H-F=`Fm&-?@M@%R}r(`kS>pnJU*N4I69AUmVb>9i<&iut4f>9;p~o>E@ib@rp4f|(SmkbQB3$RnE2l15y{6!1 z2#y_U0~W6iofU+8iC7pGB~fY#%sL1Y0R#*Kv*$fDy39Rm6zwXU?1t%m0g5M&_k54>dUi0*sE8cV zDuBbXm3jPRj9zj)yLgX!aoV~NS?_8H#*LQ9 zp!M%#K?CrxoiTp|m+?M2>i8<4iiyvh?tL`;+6=$aSe!Fvq@{Mh zzMZotn|lisXtm$tXw8J`^tYo?jceJyQxR~40ge#+#np?0^N6a^IK*?uvf3wko+&18 zsa6m|b|o6Ga(bs|ez4%$wJ{aBQH1*kP{Cl?1G!JLU0glTR;>J{yumO64+>fTGg(rC z=1QwkoKenmB65kXvD*!eyUvVeZCUhBcexqq)!XBqU#@59=Xl|*l!ASzQ(9}Ch|LjR z`p*6SohUEe!i5^V(T=(&_}mY`oAJ&}!)Ot}hTxLRfQ&);1JKiPe#0)iUuFkQY^3v4 z#~qW8c}Ki#pAc`J;HP!(-$3s@&Qj=0O3vT-Ax9RF&|_p1n7v_C@%*92;YF7B&2U zr3IV7Jwei9(J2Jj&}`?~x^GQ;x%>Tz9B)cOU+f;LOVxak?@cy5VYA$XXEzBbl6y?o zo3e-FaBA+d98S0RkY{rPgneX7IuMvs90*4FBR_3|z}6=Ow>dYk#L@T{5Pj#G5diu@ zyy>Ka|GAz?2veUZh|vfoIXli_opJD?ywUJ}f_w*$zn&_)Hu?(&7?nmJRB?|3JbICH zMIG)5)T?g@6{+ORq;NeGtl|U^Fu*hSxwl&Xr=VQ0X7N2e&;>@Wazfgm4o_BRs`I-{ z(9lsocOsH}-B>>lhwLu#Qmxs1S{d?jtC_xie6Q3epvl`VbdM5A9y872N;*NG-}OXS zqB0sy;`ea31jKPYQwCYRKkj`y4y>y>_N7_FFWiGN7#*v5aaMxM=|?(&am#ckU%h2= z!rRTYk?X^B$JaRn3d(18-^q8GK?}O);zN7#r?rIK-K$e2 z@qUyeLz>}jOoPPvR<_b$fHw^AUZzJ^$%wbe-|xosQzf(py28jW@r7PSY)d6=pV!j^ z5TJQxzuG+U3-1!fGoOsI;yR!4EtMr_PR&0*ZlUYHWom~cM4qrAhGb^Jh9sC2Fm;i_4MKO zzCn)IwZ(QAhY)RmtKNXUSaZMQ)f>Hye_Xd<#=!(5;a~)*hIa=DgnulZ+18>+5QJX| z1OzSxWEI)hJ5dl+kR9RaC-{5L^qFoqTqvrtGBe^+bBp4`gdCpBiE|10BfO1e?O%=2 zBsTjylYv3W5$SNT`Dc%H`k{s8M8czRzS9;bWFwr~?oL8Y8ci|D^M*;3ameHDm>2ufU^3L!;85Y}zh_!*IC)o%{w9AXz2-YA7_LF*&mJ`c>eon(* zQmC(U-g0~nBV({w`u5?DP(|E3y98MYhKh+Lv4${Jty9nWINd^gCH#?~hE(hTxw+$O z`G{URuPaOI@bKIjk#do+#jLa%IR)jm{+-`jJq^OMTU4FT?J(!Avsmz-L{ zy+XN>Fbz!It)iBU)D)#LFQ2B!_S1AA0z}9U6>e{z6M@OLiSgU7F6+kTNnZVwZ)5Qic!++U5#_}Qe?#OTPGIq5VVjXnt2^yO(uh0HUE#zmI}a2* z`3DmEw>^IG0`$=`5awKk$35j=W_Iqr%+J^Q8K@%W@`mH~X|X6*$nyw0+lm%{xkNxX zXidw9S!#qm@^24zx#9d%l;2qeVf0y;v97jFRCwEH_@|E&x{a<$$Cn&Ya|$8Tc+G)g zCTqt$tx}j)b?mLkp0l6k_}&Z8rlbe??=oFKi**|I0_Ko=Z+I?YE&1MNA{`;dd9Q6) zYM3}0-{^h%See6cQFRf(ZTcIKwMw0c;#f&g1Q_h5#J7)C09UXn_Iurv5W;@;VD><^ z!)N_fXo4;v35J0@sXU*rg~zr;#$_YCZZCzq0_Q>5V~$-nMj3?Z&&Qblgzj-@!Iiq# zD>^u-Kfa6?W|g`x77_5qaFTCcICq%Q9yQooc z4vGIteg2IJ1g+FUy)nuvy{M!L(1$R)N4^bAGPIYb76S%H*KcdMrt~QeSMDn$(Vq>a z+E%D+t91^SYVC?touQ=M@mi)D|7n+mc=cDoPNZXP7DFI4l1t*NIZ)$@jYG!Q;{u)l zO!r&o$XedRPSHP8-&&Yl7iTSsrPs=fLjX?%T>@MT&S*4C$POG_1C4!tY0m`u4hJmy z2VeLfbnZv@V00TRv-Y_fh=9 zG+-7fsRuUg{Ga>ugwq%MhE&niTQ!#;x%0x@*+x{E*un3S1$QLL&)I`P7d0*kY~ntY zYC=_Xe+So@7_m0X{w{|!Ps>)EGDZ94Xzi3O0Zj$XFVbM3 z_+U(>Df%ZAeoWE;3@cHQ1cKE_WMw(3>wUnQuHH9 zvF$yU9MN9dV>g|L?PcKO)u8jI2uR>H${$fAaYwN`IQ8J&f(b^zSM>T?g>}DKZ^2v> zG>M~U`0+w$e?@#!LI;gQ5+VIES)WG=3%8DI;iska1*LmNRlhIG*w&>mg#@wlk=oZBb(Q=xXs4fC9Z|OI7 zUtkI8l16k_7H|dAGpgSc_kwAksu;G|hwJ>2-dFG2*OO&~voWSZ_&Vj>-RZB{E7=!v zBr3VwIsoc(gR7u-RVMl}zk+t(+Ui#*Dcqm&Rph;CUe^4kr)rF6nn>DlqwH#55-@aR ze<*0pdzXrk|5=PJM~q3?aLhahQ}KK=%6YifbhGbq#)W^`=ztj8!+6|{BobOidSFMz zYaHE17Sl7lp4IPxu`XP}kw$1LZ2C4K?Pe9`6czjDR!Kj;y9cC5bO8I*9;q*6)M0_Y z+^6ZPw=MU%+{v{D9ZxCL-d7^Lhz<^}I-_e{3 z8T4$RH$R1mOjL|$37f{0BsSaj0m#J0_Q}bO!H8Kt^QJSa_2Co5dQPvySv}jxw84O3 zU$BtQki#$?e{p*Jgy;vLQf6=t&Pxgj$FPYNuDZ=#v)uy?;|L+KvH2>3Gdb{(CfQON z&@LH~*q0J(-ZecYz*PkQ%3cgau*F5)6C`iz zthf$}bsGiTO%LmDa_@JOUxx$626eh!dd|7-;RwIf=o~qZ!3ua5f6*2`C&D~n?$n*I z_iy7*&%?CZ>KU9sQ%1?==SG1SspkW2oDp|>%&cojT*4mPzBN;(ps`n;Zo$M-eldgF+bytiJmKh~kB;HP+Hd88*tj2a@Xza`x9 zKrJ+SmF|w{B>@cN)xdLlpYlL&lh4Oz9RX|#2*@wQyCZD=zyPN|Jg6E1dW|9FQhVIZ zPbWiC$%7)B?q^AmshRNJ0p}!XG+aX;O&>?;2w{Z41P;W0j|DiKki3>mfE;jPV=fS4 zs#W`$4?fkiqV+&E)6M#fnscK2LBLcZ7jJS#ap}8F4+9kq*y!WV8-bE)*fQ_F``Yel zm|+hicke1K*$yIt%J1J9m9g^3LYCiAjZ;9XEywDn>n}T-RT>nL1 z`0`slvomZuGl&za_F1Z6v}~3W%-}^$(}S%?Ijvx9h0WJ~4GLWDp?3t?ID5fHr{_gz zUtmQ!3F@MMOyWgG2lsb*x@~cE*te8AHjN4i!IAFgl2UHIObx#(edEJq2VV<+w!Vz~ z%blxKaBR)uD2R8cUEmg1aMy)~#T+L-x-JLLb2>PSw2;zU(vb4sJ<%0sT4qO;(qeG0 zz4R8)@F1Wg%)IJ-wG=jg#v0Dp#bka%Wp^64mT~~Q=1?eS>@uJ)A5d;+J{SoqC$umbexrbjfd5W&%WGIT?dO6u?$^u(> zhh%NUH!v%A3S;h$>=b?|LtYXJ5^wt(!OnuS?IY1SLvU_XTh-X_2r{l|>+iZKKAOa<{DS*!{o{Fe?|OrpH5;~ixlkXX(I3GO z^q^|5pr^fg^q{W69sLG(X+GVKf_2E?DoNiOfKDQE%{8-Ku7PZpShr-T5ZHS~Gj8Ra zVJc}cEHO3T=kp@6l4W=ESM#Id@QX(| zkc~%lb75cJ3rjZGMHd!!V+SU*yhL@p;atWD;UB3E*9|5y!#+y%S*I7$7oNjWFbE{` zyY`JqBj9mPg437$D2xg8U9Yq2z1(L1TUOHBXXpc1@YG1bV|IeLvRhd3%as*FT- z80LMJ?NVd5=Ep@!Oa8brH88X9Yq2zUvf!9;W7t0vQOFWtyh)7&`g^V`8W#flDI9zD zA-Cug&jQleYXU46hHt-`*_^@pVPEOjrL}xOF_RPa?;U(vRKT!0RI`MoXkkC1d#+T7!oM1p2+v9Dn9Z8A1_*K3B~O-^9p^DciDu4-Ki zhSB?gYyEtXY?=G~th2TLX657+&a-~_8RXXqj-wS(-b0}-9`76QvrAGnJN&7g zL`-S&0YdYNmb`bBctrK+lYqmV`hkZ-8w3D(!UDY}xQ`2aq$9pa45O0A*dMfoX?vz| zw)K0MbFk!KTb_OchlO&tM7qgw;teD*{L&f_ZxVLD6n3ey z^)QShoh%%y-+qsnOVfk5>>${ut0Qj{d^(rA{RK363A~bM0Z+3AENSl3-1rA2;2*v75Y9pc0y?_rT)6zKuc(N(fR!{`b&d-@~t=y1i3e z@SE%a`J)d+nW&u8kT1@jZq7q~0%?Vqp1uKSkHdjHAXsWQ0Elel&xQY3v2E zj%Z)l_hXN7Vd)2T(d{2w+y-qj20;DP;cKMi2+i%eeqHlUukR(ja2uMKcp^O9h%K|b zJt!v*zabeLw{WHd`V$iuRw~ObN)qf#pj6EbZ?RB{pMT{ij|+-+{AZag)hGYapC38^ zX|3Go+DG{sOfS=hvw2+S_V(ASMamx^ zFvt@s4Qmvv?!?yLpZ?9tj|*p6db2x3)SlE*7u0#!-^f2Ww65yLdkTi4FcskifmpSs zqM+O)?x38B-=%}CeD{}KY~t?mv7xaz(x&p|_7pU7Wd^>VWjs6ny+F^AUo}1G_eh?d zE;d#);nQ;!0tyS9{eFbEOWqmb9IO<~$;~fI z(e#x4$OOADIXzt-S6V#EM&@<9dx}g=))Vcm%nRwO*QO6?fT4_#4r5D7&I?a4)4cwI zVfldR*@expgw*8{8iA0UFZ-y!?zz9)S0i=Y5aP(w0J}OM10e0jSTamACY2mKS|4gf z;Q7jsjOE<(`!|O_y2@Us{(YD?uUM7QCIsTB8Y9Xv0voS<&1^z&BM|RN5>s3Vwtw9A z6p?+l7JkW#{w{k(5UM_ZNa0cGihmTVXfx8};Zol~aPNCtf60~M?dA#NM+DCicQ}e4 zUcbu`E=9vVy+YY7$1j2TV-lCo5{>!;^@MO?A&aw{GXYtkJLe94x$OSVdOVq9_nP5h zIsdGJ6BCBi>Qy`VG7<(-` z`jBON59p=?r+ZIL{cJb)vQt{Kx`OSvb(k28 z{I!omPjfpoRz_8nl{acCNSNv1mGA{Gh{5;+UDH~ttJjhrXK6(aM>b~0`c-LH>X*8# zza)41WLBK*1MaPAaM8XcUkBVn4-L5Aam}Yy{gRiZ=0LhR9*$PFz-A#Rmy1=Y=p?n* z4{+3Q4ThGJy!(R^sL7}E-LqXIx)n?WZ+e*5b8OKf)sc_8+o93f2TkwKj(Up`o5`9tjV57=xCrFdoqtB>EM{cGmH5vGu_FvCZ7B5Vj@v^p5$Y(EO0U8Xn{q`yD4x|e`f0l#izh22*1s*~&!WpsqRoDd(Q7E>|* zWZC%e~OO2XxOEgouKdLOF0C=0p(x=JxkI+(wa| zaTes`@<1n?Ay-MM9@0#Gr*!*OA?bu`Ws%( zkN{RHSwK}N=%f~^eHV{MPv?V%GWae3>huWp@(zS#}~i} zBB@-))Cd$+tB>ndSGQQ-L-k+?H6bgt*mY7X+W{#A^x!V<4~D#O%3&JikSnP{Q|04 z7&AQx!Xx3l@|==|Ug$=A)g zI|ud}Hc7JX)C)=7N$q=MTjJVgBF>3mF21@vO!{8nYleg}=z;5habxIs8dlgeBp>X_8*&Iw=%?{L zpL&7%?C)=kb+#`Q+VtZdnUE{qatfnQb|+2-wVv}TL7Z~rT0I}`n1m#BheXyv+RqP5 z>4onRs;pkZEIe;ea%eH2&oE20A&#TsZVo6hzW4{Y3BN3PILWXm*emhZ@4a%02aE0( zR_~$Rf_-2yDc^i~Kcqn7$ol-;SIfHmgz^y}^DFwUbg2|;+1+@f%HrJvz> zlA}#vp@!y8RK^zeFxa;q<_-8o0!(6>x>$nQWhRPLFxjQ>($q4VCE@Lz^6r2HcF38KPHtZwZ1$~bQbQLB*O0rF9^c~=Hq2=4oJC7=#Xz;X{^w1;Q)w2W^3^kEE#oC^2TfXE(2Sqo2n z@3R$?4;O6He%G=HyW7y64cr;Sc?Y${-z2)_Byq3>r8(jHeH07jCl_^gCwMyX6ajr4 z!FqTB{?M6w;Q{1T2v0BNkG|j6u_H5MUwt-?GO-M3(W_o8+t}h~qjH`m_p(h1pX|~3 zUJM5aU}*_U_pEK}fC|IeLDSt1gckNlNzh&L%?DbsvViqT$MB8*S|9AFY`*STOF#v} z7wy71jqwTR7b8p)hEs=&eJwo-6CV#1P+9e`I7zky558_`-Uio2>CTr}5B6}z0DVW_ zqwf_QF=*ePKQ6y*M~`c*4e?hReLP96DabdnA zLL(UU&V=r(=^En5DaeR#$~J-vd*;>huxQ*gN4|y3Ab<2O;lf(}PI8vp(!P8K!FdgS zz~sB9u^qlX^L&|YZahcwH># zm7@ijUSG|#RXnl*ROmZu!Et`Cr5Cv_gS(%TR(|9!@DPel4qY@xqqoDL+3=5tv(CUP z;5o-EKA*xEmNWLB_U<-4gQ0;}A1|G{yp|&vsyv}$Ivh>raN@Zh{v0u-GU*%~rqgjf zuRsoC)Nbv6*$m8h* z`iuxueV{s%J5ab84`J&-<-xIxhPyR7My*|H)66ON=!NuWduHCPL0`jLIi99t^$~#| zI6L>U`98$^iU)4%8DmdKt>JH*8bE9; ztdcZpW&nIUN>KYOmz|E;`4a_?n-&U|JD-(XaHyB;JMKTP?=K5ltDjMer$S{VP%PXI zo)j)8HLx9anP zwXsqU_*_BHn^zy5RoMCU!ks-*WfM5-KuLt_w_9NsFiEfvHz@s z(5FADUBai?)Mmc)p08p>Gx@E|RQnCTtR=&NrYFdoW1X_i?sn(fZ}R8rhfpN1Sm*Yr z7XqdaKu@m1RIV(qAX<%HaWIz4JY1Obhvz-;U>cki+3I@Q1j0p29@~Uv0-O)Wz&90o zK&_wX^QkIyOrj{`>+31@LI*Cc`w#Kr;)+YOWUwK%byJPWi1hr>BQSwL#hOo%c)CCnG2bJghFX!r4jH$X<&@eUesia}7q5%2YccCV){et!E0ixNvUJM_&( zTXTL2ET6+RwCma%&%Hqfu418C?Hlq)KPXcHTzd`172wHC4B%yg4+J0$b?o)03l)9@ z9~QO>8Mf_Cu>r#=@;h`s;v9GZyJcLOzNl($nzhu2h8;#}&%Iroi?G)~4@>xkI+^qm zOv<6nnZC5{>yntQBh6A?@4v;Jog_ZIP|?EzBUzTmQaq|io`+k2?Eyz#-_=)R7!sm3 zF}vO{!!A0SknzfA*B!gG^pf$}!bkCLXlVkV>>)^&B)n)!jge-kk|>xc1L67SP^?@w zxrs2S(j+EQUC*&d#UQKvI{R`dFdj;u`-~_@sw3G-etF3$c(H!LL$ig<=3~5wcXIh0 zE#7H(mG)K?I^7`~b zEiblXT&;+$Q)-V>kikY`O1r-`l_%Df2`N$%)9$Fy+u}G z6Yi_rAsC2b%|BXZDRT2l1=}s-w2OVFn}{Sc1XqrWT$nrXb;={!Zp9Al$Y00lD);={ zTIX-o`0g?8jRN#w$ zub>xAYx+seK62eq5Sk-+Ww))5j^fKxM+7U8a-!e-E1c^0y`68=_oeS?N)9__-ia?x zK|}qPQ|qZ1u`H0E7CM{!R*v7Fa)ZkF$?7C<5SaGziBCp>3}$UsjD z$icY4moMJ0S;nP>Y(gjiss!s3R^vT#fz@8U))rt#VG_3aX=Nl86)=v|!GJBt9 zfQUWHy%&L>`#oHL3t{IpXQVEUc^@NW3rj+hF0ej4JGt-pk_cLroAc}I{nFTV@z{ zc1p}cN&PAPdnSbv3zz7VcYWi^AwTa^3VvJhJ-^p!gNHoZ1w~ zR7ghb@6ZAQ{&^UhUlTxE!X4ZYK%A>tZ~ualmLBE(NdIb-yN)ZRL}%{n-In%QpBUaycZHKPQ$bEjBax5{8IyJ=f~mi_$bKxL5UA)lkU`jp){_w$<}t`a|GtbAXB zAh}|*m(gVLYWJ(YUX_C@r3Ccwa|0yNv8S<}lzIQQJabc+4kR7CPmjr4@Jx6fL~b4>2o~#zYp@)cD@9csYHu)oe;s+w2rwKFVg`Dxw z8k8=q$jBD0-<1BM0-s;CLFhRsI_tdjFNKjKJ731$4=LQ@g6E?6#`f)V_$)tV?{@;u_^!iD*13K^ z)Gs2agShT<5Em8U88k;&!Ff6qrf2nQU0-{^3IiuCTIVYRn60T>eAjCzm<3raU(j+9 zF}l{TUDAy2EbJKYw@Bko+jAz^crEf^+csB+ZVEu88?ms`m^dSpKq;aca37 zF6iu@REgk8g5XA$%x*?UM=}(+@pEk9v6dG;QHPn*SwBBS@dFFP*?AP(#t@80HJ$hiDVAf=VcsI{%@@`H%q_Tl zzo>gc4OW-S@2OfRkGWRG9#x;nTGYyOPkh6uDj;G5suQH~4u!AtVG7N_<CEpbrbkDC-b}bI;s5ax1*7+Y} z{`ms#ufCIE4s$+-+NvLkmn-=m7$k+$IEUX%-9{iVi2;>VrhF484N(S!>=oQ5{e48l z)>Q0kqkKiDp|Je!#rZSN-S+`S&1K(C%~GO9J#|Z{=LPkz9`7&;*=22zT6co0)4i0o z*I#5}37`BA&sbhiKD%9Xs;5}-ZQbjnDWuAn?;_yAo)dk^#}E}HJVOl?TO|P^`E~>- z{V&^SU3YzgY*7!Ge6`R;-YFKz!|VBFeeLnLUtcfd9qTPNhUKC0L797^uc=yw3Yn{K z@Pge=*w0Av3VQ(;Mce7Uk0v-r;s4nnv0ctY=ZCBm_i}s`_QQc{xX zG!M?N44FlmnerlStZpSR_;qbs4Dc8ZR5RIi#NS~#C>ksIZYO_H&IG4#$yT>J`wBI zeK{Z`jImt)E?*;r0!T>&q7!-}3W=x^ieV2sdw;t95Yg%bwLWjKrQ?5V^FH{nSWrI%lWgE0VC|yqg7{52q+iG2|S}{z*@>D@dD< z_eD1n_G^#01;@0m<~lyKtMyoLj?9~b_AMO!r4N5Sm-y!(!YTtkF6cKjPHgTUf7^IH zybaszv_t&|IBnRs8Sg)4$YQmq16Yy%$VKc1_XQN?;dej$TScKW!U5|Cg5#z<9}5mX zW{mdJBA6)OwS>4fJ0)KB!+l@n?>YB6*)RAy2dCprn=k;IYbt@L*;#NGZlaN~*b-nh;fIN<8%*Z% z8r3${^>Cj`#;NwQf=Rk8V3%EZA|L3$s2@V68l)=Ax8=SSNI||B`fvAKa>k6H7P4ed z7w`@+7D*xTegZIBe+c#1z$M!tQ0Yk4f&91N4(N^9N0sEAPoOIv8Fmv5M}n)vm-Ua` z;_&zFbmh^^_}GILAJ>B*2bZDx9Pg9>-)tCI#B|W^vss%si*0Sl*WgAmBO-T&Q>A(d zC6(^cI=9dL%pQ5Rc^x@JkWC|C!-AdQTI-37N$)#^Xb8q{om*CfE;xD*+H!WJzjedB z7qMtB)bqKr1FtGGvN5wz@~2iXeze8IXg{8Q3u<|;=SB#teNYM8DiHe@68AXH@ASm> z_`R=4NSU6|FN9{I6jzlD7BcSiSq(1wt`08>SV81u1IyQFzv!;H59fN}ES5=}a&)x5 z44HM2OT}aLkyqt?gxvVIY71wfE0t&2kQsl!;+@dpby3Pp&SmWi>r3hs>X%PVWz5Ls> zKJ535-WuwF{Yo`8?^Qy;$$ ztU@=BZ;NBKWOv-ZQ$}N3Y*gdl5B^N=4Ww4B2pLItIuu^igYWU>D-V9=WQOiIyyS4) zQPOg=Tj$9Ak}Y-RT*0V*-0H=)PbZz{4}cASOEkaRZzV{wxaDF(l$lB^f35eiK!APh z1TYNDnJUzz(iSe9p5&*8S*Fv$gW)g9b=Wkcs*lG#Je*DLwX$+^M322j8pk_^xe&;_ zt{f(uL~?u}WTvbFp*Kl()c*PQk6P|$!o-@&+V_fu8X&;W_*bCV2fzKACO7l(YyoV- zpwNNijaA6JQP6}Pm9QvuI72nTnDVDv5dyth+Jh`_jE&X3n+FNoMlglwrzJ}La#cI0 z70zCFZuhMl!Zg5Uk{4OxTxrL3I zl)m-OuZkVo3XRbs-#q1aISbMlBlxSfY5$&DnDg57+0Phm%`Bw4r5_a3u+MSwvE2e# zyW?L{%-r^~ai#0V_m$OO>wW5#m#N;jq2J+0G9QmuR93v(p?noKI=^1_)q;8|oWcij zniApEdlywY9QO;&x+|#8AF270D`7{`4%au{&eN*xki@VYLuY}hUHc#F3xRw92mqv=a?&2UL> zDE^%H>u5H!IrQ~?9e@?0I0u(``%{X|zvUA}Z3UIm8kMh|HX`qf5B_SX*g1dHZQ}PI z)Z{9SQm&bCxZV!S<@@r!=x4;!PF~OkTt+GPM`b48W<8%H=7(DAt2No}%$*9Bf#um4 z9d8Ox0mF=@vJ0Pn6kQxZqu0|VKEn3dKN0Jh58wUS5u%rTJC4^q{=GHr3K^iUiK#3` zoUJx*qH37oi1>{D1?*d<#@~xxHu4x{7tU!jdryn(_So`z{D7vWzy;XzQ2Y8=2PAWG zKO6mYfvZyu)vD>IhH(GBcI)y3CPYSY-^SNH-fESvwx4vSU4s6B9(iIbPuAson+2mM zz{nG`7-kpQjjad%dJy$A3vVVsv3u4zc_GLq8wZ0n;4?&0>2bJH`e{tmv&c8s=6rp> z-u@5o)CyI4Jd54h0|WW(5mfe&A|2yTlG~i@jTxdCD}?jAgLk=c-CDf~uXyiotwW`_ zucF3*;gn*uvR`%|GOgx|=U837<`#N+e++l;FrhlU7&W_|ffjz79uApo{!kkj)TCqNS`gYv2vb`xbc`j=hJg+E;+Rwbe z%N4Tzh1|@YSe}ff2$bQ%JC{$G7tck7m|ZSo2`ET^hO1Shw);pekL%Jueo|3ITx<{2 zdvUw?5ImCmJ`h&YyKEu@upEKsa%I->9eWH;hFGnjmY<bV- zrZ1F=vgEWT7Gk|sT7(%r7#5HNd9HXS*o3|%jPZ0X6n82qA~oyeugBgM~B=P zPO|ykv#i%k_(pP_a;lHkUQQiXesfC8>;-vk*_G#mzJrHAB6xa{d+v<|jMU^O_#BQ! zG{8EYm|^0eL)j+?_UA$14b;VjEs1@q$0!kiG7Yl#Vb8V5NG$VuW#t=N#tr}eIsx<{ z@Yx_vrFk>7&w)gn7ES}TqyWN4zY{QUcMLchE1={vS*)#w2yr+3|CLya%NH*n& zrN+L#+V@bcp(H$?pd`Ce1AnbeD&UAASm6cJycMP7`Iqn1*LOGbGPZSc7MZr!X_Y7G zqsW~h&hO}HvWiH8AzRpo$*EO#9j08F>1c)1rOK?T(9X#T4X8Y`TfNBw?M&E;+0g72G$%i0z`x?9$A<@TP~ z6Cn}W6i`pT@Z6QH9KnN$y#Io`Y08SVazhS>cwg@I57yx%tWDdb4i1N;dY&Q)uFLqT zzLnPyut=<vs-qf4!Mn{m2ZY! z{+&SwNqs)IC2^^sU98G){IYV4@D8-5vLa~_%f1YT0d;wEhflNI+Bm)65o28U_wU{r zOH1`2=Mi*43n|OWx;(exF`RWS{!YAlh&qz^uoey-5Oz=8hvU*vFBGSmWP4#Sf zbu?O*_Uy?p7_(d4!xnP16MDDdS7BJqZ(z>$tB=WhO?P!qcQ`u!l;uyml1~ zUm>5ge#;`m@A449`C2ll&=T`Y8HcjZnZvKs`U6+BqET?q)-1!65>AKfmPKRTJO|H8 zd{OhqFJl3vlLsgDb#L{)CnPW#?aQqah~FH+O|E_A`u@|FVW~PyFel!7UC!(YI_%jJ zvE=c+X}}bCCQ8a2+~peHI(;UywhH0=16BjoSTYPg_DR@Tx7ZxXSorV@(4!ij}YVaU;>c`^JCkY)onAP+t>Q#DXXmy z*O;#)IdS%g*MMq5hYjU$YJX6q?LkV|GbC+C$k0+Pp?#ml14bkYGwu7MdU;ZJ&-$?hm{5s@)fF_4{J5TEIT~FN(EK!SF0US6JUPBtPYFnI6v8 zin(7vNF~(b$UA=V)|w;#xqGQ%p+yhv8{cI^)N#0!X$Jxy0_8OL>^JH|C4vnM&ok+p8x&zN2Kf_zLbM*|eA`6T(B!1){)^zv5o;^Fq(Kq>P1el&E|K_$E*2GV z0bBp)I2XNoeH5=3si@IcptD^QjNZ<4d4>Xx9zn?5E1@Me-x2~ldCa?_h*xe@Q z{{1Q9XcSf3dV!Sds?*VQS(;a*RlOUX z+4uA{*6m|+?v<@8=K0)*-loIw^kplmKh$6)Y}EHooob|k*6=miV_H>gP0#eV9f`Yb zD*WoTHjxyxO4O-4J!{Yo5BO z*Lc}`6NJO9voVv(CSXvfIa9apZgnW93ESh~#ZLj8Sz=j48ci5tPVk2)|SEiDXAX6&;D*eS_8Aoy%#2iDC+|E2`M zuh?U^G1`W&L~@(cs1DCn>FqamyncPC-D|81^>2>4d5=?_t@OInWvTS_*mrakAOP|4 zol?ERcs>;pFf;wV-ZwtCme92B-79hc-2fyDPY#jCEMXG3XA%r+RqC5Ey26A0`iv=t zkH(>FLHkBkWlQFd>}ly_X7=C}z&_o;mV(}KdMduhx-cUkX>;?3%cLs(p&!(0nG*hK zZ(r$DKeI>)J`7~X*bjf<0+s3-tlX}#uyJ2We99Wim51{~bc1vj4qJCmtyP43j=RNY zDv!Q_hrQ%+VFdc}O5Gz}QPlGjR%-zjH&n#W-{ShMoU3jBT!L~$gu=Z~{2ZqAYJ2We zwv~hTKCVC#`&vPYzWX^Qwm#%dXp)=S9FogapuNCk+;(=s4~SzdWwJc<(1aqvmEp#6 z#r6PwrIMA~kKF!5n(^M3*_RxckL{`7rx0Dd z+_YfE1S7=j;wjg%wwpzAs`r@~KiYig`mqenE zpdL3zBu&6;z!guw+Xx6{@@30{hnfHh;Pxp$KEJ-vqfPe7as_i zu@!`H$T773;HL}p7wtCp8-nVR`F;pPb?RPQ_+=7o$$$oY=U4TeY~s08?WBCoi9uOg zeWH_tc8+~CbLKZVaGOK5VTKjL6S_Y}-RVS5#z&~>JVT0j{`t3S?WHKFWM9lPzPrL_ z<4G{h`7NA}v*`OgLvZ^u>Z0b>sLna1Hlz}>#G6E+i)hC|!Q?aiEyVKUU^ejln$P9u zVg+NIB_R(Qp9y4RqtI8G!S>iKr1)5=+xXBMhg%oEKrbmJiQ8Z7)V6X3QH zjWa9Otky}Ldg#W(&ABYgT`I$V`{4<)h7p}Ft0B|gkH0fdfWLAFcZj_Z5A0HcnbT$y z1tg}&qVxhaKV^3h)tM}4?dAyz5+}ngQz~?0`{aB2RT|9g2~C&zu=hoT@BkQnOs3J> zbC_!OVN`KZ4$Er7*aAmu^%aCDwkY=*kr&zU0#>fo{6j>G6)a(XeP@ljA0VuzjEqkZ zya{*ir+bVldr_fXtn6I9^3EZ@ih8?9>26CSbz8r$o3iCUY~~}1+OnO_TD}aka(vDw zbA}L#*7$bgc9~ET4`SFKR3G9$N7jzm^tr&}9uE^?KwLizrY|@AjQfhuF5m8QbK`a| zY>Cig*TSJ}n0I!}U?ZxO_*)$Afv&!-5@(lkfiHS82~%lr;{MmM{5k}3 z!+^P@_lo-P%XS^1$mPh-78L%GdLOlom>Hk&4~NICVMk#3_@~ee`VqDekn%`j z*|=JK@l$E2C%a&80liFs8*0G81E}elV!^|%Rqv8_Hob-dKkuP4%-EW1(LTkZ`Ftd; za3J8aOteh(Q~GkZ2g0rCBKjHRw$A+###+u7)kdjOm|1;)pr+eo$9+`u#J(k}m9+Jz z758Ls2$e5Q8J|T78po@}MOcNUJDh*t=<_~l;0B+VZ+m}-5Klas;dU7L$$cjtB!joA zmcOkM!m^qKES9}NO4U7s>X#78I|-k*;xvW)^%N2whaH#smsdO~pR#D*3POVbtwsSq zM6quDIZkiQ1(jZY9_Np$Wwyw*JS^3p`BqwY`Yc}D+a3O49;cBf`tchfw?hI-$po8s z98wdRC<)(zY$toneQuf^!0vpm6CagZrvqUri#sTX3t`++g&Oey3HIi|r)+;7;D0%t zZ_22qx|6&YNY~)aquQ8~gNAj;z+sg$>WkK+>5)~*UZ@*_eU?%{-ynz=#^>|%h%Ujt zy*m=*bQr>o_CV_V{=_Q-q|v$Ob%nH}Cj`)jO~^%+{ra(=#s<=6Q`w7^5jcxPsl2~Z0SpfIXF*jQPN^h zQDy+D^ycXNdtYnibZL-O076b?ppGwH_c{*Vpq0sV%dR^9WT5CTd;LHaKK+o*TOCGp zT*}k_1RUh*Y{S$HM~y23PFnoQPR)fpg@HK3muw`pIpaZSmXHcYui*E*tyt*=?kxXG z^L6TQs(V$itE$~05_5qgkD+T3+c4UU}|k(3o&)0>sBJg>2`k-0CIfHFF~F2ed>_=EjZyH*zQc|)&4CEc)!WW zAtBzG#t72W@5#1M4i%)~==udErSpr$<2!1Dy5xULfI?v+`}F(ty2z?ek}UQUGc7n7n3>SfB5>h(8m&OL$IV zZvzTb%oW7X)dHT;gqI2-(y{`uzjg;0H-J zG-@;kiQH?}xbDvT*M0O|lNbGd_>|XZhU?yKksy*)RAe>2P=Vv4>jEd_E>O=4@#-GR z3#$0z*X&{#cvsV8@izSx1xB_+;{!7Q^*Hqtb$gzJN7!4RKhEn!$@)LCy#k`ZZ#L4aA{5OL9r*G0B zACf&KtC-Zi!QV6KQ}I-zj^3O@ZOSKtffcdu6IAo@mz02dYRy&m;Tm7x384A?)dsQX zvJL0_a?XvytoM;npN_WhbzEGI-fD#3puk=A=}xEYGD1nqxAyeKedgu9=bY!l;Jo_FqFuSLN3iQEuVnw| zXulDlThv2+aN0-E2T=0Id&sH}{b$b}>B0aUAhL4Z`mdNR+) zYY)g2NmG&DIgC*uJrdk~I!adujLr0^M0{TVz_@QmT0VI5pE}e)heYtrz=eL0vwDX; zDtyh7#Qk7|fwv5KxW%!b=7tI=H3R5dO$|hndo=kxBSV}|io^?_dn25!?1c5G!-n{n zFXPV_eAeT$dGwa&5rld-j&|&51;L15Q!UgjNP(G>qWc8Pc8%v4+sa#?u)0E6PY-!Z zMb~9L`mqI@L~(qML3mdvgs_59-6gp#v>fen*_~YEdJCZ29i?2E1q)$kKWeCk8xO$i zreutB1Oq~6-FWd?ohFi|Z#D5Hy_(N+jfm__G zhIG6-9nX(b_5*BGdylDTO6<4sqdIkxU;jIn@2r*mAl7J?mb&Mh6L(hD@6kLXXcfeL z?g+mVF;+)9%lQHEh_I#)0`O2y0FCpW>#`?XXX{pN;*klT3?#7JRED?3g?HlKe-n$b zFPY2S-7D>*j_z&v(nlwLkQ=DAo1NTB?j$@J3IdC5gZ)7CMjTaHW{rp!H^jF70159oja@0rPyznY)x7&RF`B(Jp-Q@`HtI6Bf+)rUT@CCZv zoUD?qdb1}DUoCQlJh9Zc?^P28&yTe}aICWi@&>o|Ej+}DdVex~4|`GkV)>lPTQ$SN z653=iD59~8x%yCwFU1D6f=z*Lt5aLKuo1)#RN%g%r`M1Q)NdhGr4(=G8v@hmcyEZ| z?8|;^DRlEX8wk6ksj0IvatLbEb_jBuo<*gy-8w%(VN6pO9`XHYdmiM8C3hvndd_Nr=OjyCVS@+fQevYBe zbu$^?mb@MoMZPA$u_{LC@clk}9-GoVJh#nm-ziu%pkk2WzHYFT5~EGQ%G0UAwg-fd z^Y!XAd`|FeNW2ck>fZ|O3LxF}J^MNU5@T={L-MxzX?1H7)&KK3-lMq?!(SGzfOr=P&f9$z*LvGF~2|TJ6;`*Imq5^ z2@S^`Z9wk#9k8UI4wJ&-PTUUEN!E1r`l&tMeN98MQp(Huy%#G@Z4hE>BFTCC(mTM< zMytbJI(@XEbdtE^Jz=kGu||Y(n>sXy$Kp1WMkh;pKyAC9p$=rYuM3E z4tU;}2Z-Va&n6z!T3?V3RIpfnBdqa|);pC+%x?XHJDQD;NTG6f8V`E_6CIWLJLUWb z#+?K4K$m@s**mZ+?>pw8aDqQyX@xx-m?@j4$Gi4jA*8uz(hv&7cjceH3pRYC?Ea7|;uT`O<7p~% zEV(BuW0QQnN%DmkIfyuc+p|{!7Wb_|;iX7MHQ6d}p(Tdc*S%c1#Al^zOMm?ifR2Ox zMYP|_uPB%ka)&lpq)g@SiY6ol+v!Zx2YTqdP3M>d-M4UBZ7<5$Hf&8>*%+GPiI;ob z58Hc|eL@0?;hvCK*=O;tGUZoXa!IZk`+0t|bM6ym@T|fsYAV6iNaCC2ozG3y?O%8D z{SAOYD!al1(PvB^Q1LG*eVgx4MEi!~UihJE02cK0o1U?z-!)nJ@L8@c97^5emP`?$jpF07mb`UJV6* z#c8hv{w@8YbV_AA-ZyvRq8;HM)Yvm#!0h^jW_4UK^VQf07|qoCK!_ov)_K+U+Skz<8t!fDJuzZ5LUA>)96Ex}Fh$pN2aA?YDj)f{IM@*R=73-TU z+{pGH^ZJ1RfQ^9SBkpmO|2_Jea2$)5;2BQYQWvI%+$%?jh~fqE(@lA`$eSjA(Sf)> z*pxs18uBe0RzKsx(bnoaDsic#w9uctcG9e~zVCmvBafwe`!sYRBceRrMs%YwOCubIt9}lx{8hW z#ekjef}ZOM;7Xi#c^SGy&Di8hAMPy#ANfB&a}5z`jma8N@-0)}zpOAJ8GdQ61n}Xs zM0*eZ{I;XB$DcqwUbW}C;=BD$Z;@1ODWsz=Z~JhLZ=5_>(*%>R1oZ>B6x)u&Jo;Ds z;pA`ev}Z`k&s%2*R;I4U94h?W^BAZ57ff}XGWM&Sej5WrgtDnmMc1XuRg0g$xaB$H zdB{IsAFvfDg5YtIbL_uD0QtlzhU>-Qx6F6p8yN7^lwFQ^{Wy-YJP3SG9yHdml$m8f z1<67rdnkeILb&zE{maGYYcm{w8OsyX0_#dhhs}?$PMn3;zb9C>A(Ddu2?>67r>HPv zzhi6J>CFr*q^vi`6K+U zMZ!r5l!vO^3cu(lKVl*>gxl?YdpaxSC>%*%B5(!D@ieWl>m|?GMj*zG4yv9l)g=C-m}C zVaEWkqK0baN30Ls+?FuJ-giVZAg+*aK+XeX=aqrAdknj9BYc>~zGbc265RS{Wq!n$ zBt#C(q4lE|1GI6!NLnAK+WjFFTF5j%qJQZVyfHuB_pYek`>b3V<_E#d6WoomTHcaG z{KM}ii^mtQ%k6;k^IU~Cl~!xxeV<;aeXno#wJ6lrxV)H;*@QvQ|JX~it;TRz>bneQ z&DO{60bSlKil6`pW6h*+mpA;IFZ=D4kpk`e*zakuEw6rz<|kMC!%tQ!qy5pEw1iWf zID3R!l%1vPi*$a+!KYu>ss;<_P^yqrWMTe(*hlD%f0&bAxU22ELgJG*I_J3IRP{Y% zhN|?t6}ObtpgkOjM-8HFhC9En!|>BC>Oq9z?|qF~%XNO6U!cFn_GvWMLwW@9e_!nT z0-U0|BLO&t$W9npWr^Mj_ z;9YsXP*5j&OI5P(3qQR+jwuv8ZwAp-o>o->#9NN1D&Ba4&~9&*{0SzW+=rz>A7=LBIQK!kIXU+ZK7|8u$jJ%U^LbJGS2!W6lx6M&O>lzZ#Ta8jNv>P4 zaE)C_!jR#rePJr}15U;3Hgf0dfRPr!sV4XoZ`Sq< z53z~_0y9oqFegt`hYvPSq2)OE3v+g^zQe`DvW=r58)ImCYj- zQRg!QUJ#B@fI#87ntp1p4iHl8dRw?stMaG5Z(mk$7zLXWsq_a`OiJh<7qiZi0t93}#*kqj}$E4;l zoRaR+Of#4)A1`;l(7=u+n}AFs-ood zUMCRNH}!Dzwvw0mHZHJqfhocFV!ut!HY)|**-YE9>X9RE3U-T0E0-5pQ8op&`PSTa014eM4y5rM?uH0`RXd(Rui=m_qT%%hA(f z@n_L^+;}>}HX_)5aZz=v$ssT;p5LZ_hFt960@KiRD&SyHoq<|qqd-K``F%cX%CbKi za{Bi#^tN;C=gK#iu8>=JI_OIr5GF}*C(oWZ;L1(r6A&`!&TH8zg3~jH&9Pi{XatCDD9n?b)k2>xWa!)^w|SJ^6d+j;uTpQuy{EjUmb#b9Z!Le%xn)^Y1Rc zeGY#yRU(J*VF@C3A0BC`34}Juc$*xfZB zgw(zYFO);?-?i%t7}9=Ri(c>xgUf^dZEeYJH6o~@g0=>vt*;L3Y#C$uyybN969W2* z=4EOXW|UuC#$OnT4D;gpEM7;MZNc-ym3W`&bUzR9)hX=lLH{n;>7>arrEi`*OtysS z>r2`fLj1@!e-OrEq+1Y2PeT7mgWzJ)R0Mpm^C;#0i3nr0>2xkH-eOhw?e#AVs7W7! ztvK;X+fc@a6?JTL3661Lbf+2>~3Tmd)?@ybg!=-_J)rV!rG1ug9yuoWul)$bJ62DUUC7v`BvdjYeEZMMN=+{g7cq1;J#;CIzL zy0Bv7ZwxF=aU2<(05!{4x1E9*8l3%hJ1{^0d@ZtO;qUBg;i=D|=um!;4vr0*bv@OF zny@MMv-kj>RA=WsFSQ@*^t4z^k@L4;x%*0WmRv{ryn8u)F$z`qbrOnt2q2}Xjx3SZ zTw6v^`w|@5HLZD%ruPTu;)5%QNZKBf!F+vMuWFZR5GkX%OZ^J7I?JFx5QpXDyQ}%l zt7SIk0cQ+pgz^|bf5)N9ru&#_KC)8j8`AE*yQn5O;#(c9X&Z@lKgzfac*T8|DBmZb z+fx6TQOc~#h%LMR4Ew1@SpkpVuL%n^{*52VI=q0hn6PHdP_3ahx+%(Q<>iaa9^SH-BP4l(!XDId$G6c z1xB2{OdBvi+Sf1<6@M0nRCRdLvrljg)m3_(i-_BrK&gA^HK`Fk+#0&cl3_3#FuwaJke*s`zs9`fgLP-wNaj4h>~!n61!~EgX%RN%O`I3{{(6p% zorW*P{MeKpz1G9rX!n?&G^jS6AN(-hWA}O*Te%_5ToBFSzW-0BP4=9Mk~4cQLsPI~fN`&@xYSr*F7ib20qjGa!v{-8A zpZ;v#^;F)1*FLGbhml5(>IV0%RaNlt@gC*m5FYt+ARs%4C*Ag*009=oJuCC0sYdcW z&{>It4#l*r?_71@@qNNE`*V+==PjO-P(j#zv!~$u-_rB!BV$g zNr}&e8hgJ{rzwrCxjpK@(tl%D5%(a&gX(|wjqC<8zA+D#^IWa-pC>N&JqvofrxY+b zoI;BHtb(TT{w>^Ghp1n%mt=oe=wNcpcs@t$FGYAP3jrP3$PDj6{GUiQw92)UZLfyl_u>iXHN(N%y1?dv)1AxTYMlHSDF!+)$f z=N3!_Z)&Z!2kH_0)r=nubbvoK8ewC^-;1%Ylnn|2_HVy$3cz~8{p(gD!ZWDL9Fbi{ zY;Ze%pm%kIlHL)RgY3;t#&UvPZSOulG>=O>UM=t+KHlBfY0JP0;#ntr;75rw4;+v_lI-~XHM|F`!K0l?kP2&Da zK>pYY^eef>A8a`lq4v7Aq0hd|s(oZxW0kMZ*K6&4;VwSX5y>CqkJZ}{#dUUHW*#*5D(a$j1*MJZGeA=9p831mVH+eOdg6Md`o@xGAH z;MGLkTxH{@)IRz8B2;=oXFWt`C!LOc@a4@Xx$5MZ@J{21^9s>Loz+iQ5VK${sbB+d za&Ymef(w&=y3`hJ4|Q->NSNWSuCVr7ni7KoACg@$NJvf)XLUPJBtv@~$QPW&dnlFT z?}^I)wQNJFEcvHG>PQR=GcTu;?UfgByZk|f)jhL+)}zZjv1dF@d3(^sA#<4qPsyC_ zN`6Dw7bz75TzuQV?%y*NUQejO?03F0pki^6^9*kH)OX@^(4!9Ioi2)wJ?uqAX@B-^ z{SP{DU-rwKZa0Bko;5WMI@tiofg^HdZm!G6SYKcWG)Yj=F#R1&O5ytZT;&}-Fz;1J z%*fu4Hgul1Z}#uUsa{RRN2+hFo>vdBdZx?sN%I~JAd=(>GYlY9`_<*AMN{wmD_ z$U~vCv!UQfEimkk%h=_w%!itC%!c+m7ABGMW7V}&|GPJ@_-(`t_;tS!81?Ix_5Eaq zL2kdMskx8i9}^85yzmp`>%$!CyNyfdcYkw9>{NX)@(RMn^WsiWJh>$a`4$TNj=Bg8 zcRp-m8JSSsN?d+h4%$1ULe>>2_5_0a(Ph_!K@dqWn-RMluHu&^D4ypc=E!8m`4n!12YO4?B+;#_dxaS;ecWIMI^%1R6n+FyK-7expKB*J{@h)d?3|A z6;E2dL7%r@<@?;u*s`%P3e5c>uyX?s5wD{UmzTV+qmWumT>C|JUCuzWhs0az8FFO; z`70wTFb?UwoF2zcGFD$w?u#oxzXInAq5}|>NdQ0FB2yR5M{pwC4sm|CH)6^IkLj~Q zkc%w=b(28~ogakcKynxA7&cIxvV+&~ zC37$%ZLl$0`}@Ipgq1{B2T4b_Rgc=pw!Ep}Xh-ieXkRw!>Yf3?57hGwS~3fJuE=Cy zs#v5(@>ckH2^>yazp1JAtZq*B?9l=U zLnyRge*4A>=u+GbKgF;#L;vxem;F(O_NIk0-Y}4@C%$>uv$yBmzH?g&C@^pP|+@&pG()_{BJ#q~_VYm8*dfvOK zvnQ@CPO`OiSq}C+zA=9fD{TD+8Y`aot&)&Wn0EnL4eqa#{RkS#2~P0fO`D&K& z-Al<-`*gc+jBL7Cn1xhs`{()yFSlpAg@ylO_BCh%)qiadQgYNEks3%2>}#DB>LxjZiujI2C0!uS2Sb2;s9A9K+qMw=-^`L90a+;C6ypP=(x_kH zx_6T8rwnbI{aE^1>N(ElD{VamURHnk6`afG^9=_tJcZKo?GOSBE7vRv1cu>xt(4__ z(e>Z*vud_X?kGuV)!Bd~7_+bIX}<~cn>Ul36_fQ{)Gw#6DDczX_NDr1a2Z;TR2~yl ze%aR?GC%FN;O~CVGQ0_%GRka1qJne26=H6N$qRiJ2z7y0PlzAhch%7twZTmHFOZg< z!pY1s+9SP5L*^+D<^p+@^Ap`A%Vmw~`?rX(9|$(jmXiU7`0ycPAz<{^zV+E}gpm7C|L75dbRht>CNpuN zhmnNNig~uwmVP~7g3iNYZ;!Y6!vpL}CoE7&FzCBexc9&ypAc=>TN_ zh@m+3y?upfNzTSc8&*PM-FJ|kQH_@*3X+mM7g;!ZPfchu%sij<0pug+YJxxFkFeA{ zgf!S{3*z&Mo~M(PU@)CUzIi&9EkX3g^Ol)?Zl57Y8avrGNjzsg4egiagl_-_EB*}t zkoF3}VIPn0Q~1{jDNpyu(cSmS>7%gb93{c)#B(6c*9*7r3i}OBfgG4TIFx_4#E>qy z%ypmdXGM;loDBgj18(kZR*2nFnEfA9k85TuccoK|8{GjwZT$)5{d|}Puus{W7`7Ad zu^^sWv0$2T;_k4Ee4ZX@&}abV4Db*GjjMVaY9rB+ozcl;K+RO8iYWvlFL2>vHA|0H z7Co0#jw^6=>~T^<=q&FydF6Fe8&di6B8d1lJSpCYNst**>tQU`$gnr|VB!Xwb{55w zhQ;LQ%*XGmW22P4`RKo$7E&`u>A{TQ_#rzjxnC?ith63Q^c6;5hR1E9CcEEXtcSW5 z4I2quiAldUv}X-DdI5+WFXjh|j08Ze`D5Szie8m`Voz3brzG#KY56AFH-j|r1%io}L{O+na1oTNEhrSU1|;uR>(11_i*pSw z>|WR1&hHTaVH7_}&(Pjd`TSgy9!wJB_YAD~Aj+wG`Z48u*q&MyVRsO;Q&j3WeO;I@ zR)UFoCAj-U4|4Osy){OW&VBC<47~TaO%_MFpqP}6fwi(!qG98zs~^Z~-fSEhhr>?M zAJ$%bz^Rv8Nh+#8=Hv3K-<7hT)KkY7v1bzEH=FREt_I(p<^AE|h7$IPi)P*2eYfy2 zE7pC-@(=FI@Z=z*ti;~)fP_6+Q>{X8$f<|diuQ)9<@x%&tFV58UfT&Pz2E_=tWUWI zg2(4xcB0z|{m~~+CyH7&l;VG3D$#|pr_;IgnA82*Bz0XK%Jm!OW-g%l94NTkW(3gV z=iGaNai&}0^E_v0`uyp<-C#7idAn&FBpe!N)+y=m1ZCCQuOC;6CE2t@s109|nR+D( zg}0%<#EEc9a)nPls@YC0685E*4}~Wy$HNXpVs@yA#Q)TI7~HHZpmg~I{hTRt-9F;@ z@`s&T*kGl1gv@--xE!=`lWs1n@mpPOW%iE(+K-82dze%3Lo7*wxqTF6S0?=H`g7@6|5U+qYNCa@177DoX^PilIU-?ks>4zIQ5B9PZV0lDum{lM?=|9lEq zc9~d;rc3R#5Gn-`t>$5#DUGPf&LpMxLRHdK!)V2oA};N361gJ6&YhI0;VnjGA<`lkxGRQj!i{c&VFwQGkczRP-bH_IhXN z%RHF)&1SKuykLFH;W0BB@d-?MtUM=Y4)Y zy&;9=kyfP~5*y)U9Dg=?D9d4qU(bC*FenZ)m-gIG1w97qq@V5E%Ie96&JliXhR}uZ z%KfRQJTPibxAW}?Nu7OVe2=Ou=x|j$ToiehFd*#jGt!QIAYX~8cIZ!fmlUcP4+X&j zV?`*`;5?n?deEd4igyGt5;7k|ID!;t|Mej62fwqt4sU^F*unfUrw`B=ek^JO@s;-K zE4pFh6|4;Ve$Xj>W2g^zuVGS^D+O%Eeq?c;t%ZJRJq>E+sW@ zHJpZv*~s48e6of*@>E2UP9VH1;>g$B0e_0CJMs1P1wd>3nV~DPu|i5!GGk%&`1t!F zVtk_$M_iPd zQ>{&$Y;ABF@-=h}FbdPA9A`H-MCcNf!S~{0t5%R!QFk$F<10qt(G8ROy^Q;6KELTi zVT+M7lJATw6cqRQY3cDcF}Fxq(vEI6`4`48u$%egw=Q6m-d~avQ=dxoQtNk0bG;;= z1)4n52xlc;hZOr@Oi%)lbY(ami6GqeC5^`T1O>G^tkAK7X2{vX7#0V3cm6 zAwP$7cCY%Spjuzb3Dpot)zUDTj&$t*Hj`xLiIlRdMh#FmBTxMc_z!nC zK9(wo=x|^B&r7|=c&LON4>K|JqP7J_e&87U{>E>ylEk!m&`_pUaL{6(8YemJ=sL;8 zKeVSY!2REYu}{Kb87aAV&~*fHVxi`6d=+1v^_R3%PP0yV) z0~0w3g6m)M$%I3x!2_VRypp2X9w@`IM0a30+3XnHPZF{%pNZoue=&*XSZFhAlW1by z*)6H|GlkXR2?MugFCmeS$)YLLW8^2dKNx(!5*#2*+`JYTI^lC9)k|glCEiSU)j7|@ zyTgS!X+XeDk6d5R*XP8+`@OY(Vq*U6eTD};kgPJC<==eVZYw6M!y}92jkGS-DiiAjnmC-#5R_yDvha&q5C!k3 z@!i*G{`J%M>+pvGJd9*(+FaakB7B;ZqiefqAL7+8yrEMN`nvXHC}wUcH`mpRaz;@vfl`$0P?KO1ZAk%jUJ6%+d2}vZW zkXxp!djG;k^m-V2;7xz(Q&3b<6y?u(*@CC!XaD=Ate<3dE~M}5C5*>+%%zF^{@{J| zcgDQ4=NDY^>)vM+l52EfpfoP=85GdHuoCyDvg($<@>oE25$|f!4CBy81wmk({3o=m z0(EYuIxYp=WB;tB(5|?CnROjvN7TisWbA6i}8b+N5(I6Yekzil*eDn5CkaSMcQvXb zNyFq%Y1t>wJe2%~F2+^jCx#vMsbYzxJdN)7O96j+q7a^>*)Jni8ZJe--JMz6b*8kl z;L{mNhi)^r!C;=bK-e3y3+Ao|Eqp7)qz8vzB)@A?Km6*LX6Z z)zItgMP!yem>voVKFGqgNu^Vr9lL}K@A<8I{%n7Zi^lvj6;Lu3p}*{|k%#rYs1_DE z6k#OZ$aX*Lp!N%!-M@G03T&{rFPiMH;GWeD7R-!OOD9BH;QUiSd%maoa7PoYt@j`e z9vd}1aP^Np4FFE7)Z4jCUEa8WzASJLwBV!oB)eBhQy*Ku5GnI$(|zDBqGVm$;&Qz~ z+8=D*(w*AlQ5K_malS28d&`OKpP#9;o>b;07KDNXN`6@0h7=(zp9r)l)AEtedPqOtK;AzXjn7O@I< z7hV{O=6-IsBHV0$h9Ub~e>=srrM5K!fcNzpRYy3ycFpzvei?lFx${<_5gp5zd)lM5 zzncVy%hQUWWavXQ1KeskeqJl`(3Why<|~jD^Y*= z+P|wO;v^sD0IiH@LQ22OGKtJR1sLQ63VR#U-@(_1DTL%#(VjH^4l^prc5_`4g zubERtAb)g_je@(cKuhS@N_P5Q?~!iI!z5dV!S2CJV|QL0j;*U6njUOOih$8#@is5- z)9;?3O95Ku6VI#ML+8xRIl*l3#EkgM??l>CiAP%SDfTs1t=xLS!l|ECr%Skv59-w{ zl{gy&UmiT2<=-!`Dpu@cl60NcE_B5k1cHy4@br=}a0)p>uKBZL=;_fAmU7w{a-u-x zJN33{^HTU3+XrO-mABTO9(D$y^$a0*4!`@k`Md^9oWwF(>U)R{Qf=`$VjQ1qdE#b4 zTp$^o2;?-YNURZ?Aon;=Ywq}<#0GfhkO7brmz12E&VzJiDy)7@$;)l%jQL((N5QNH z?ifB}I~!7vS>R-fG79)OxOLUU4V~~#Ay{L@TK=#c<-q*_>D$`zhEUpR9i9+Q7k_e5 zP?jWEGUFT|hcv}B>48XCYXe%#Yt~aF+!UtnD~MSU+j&^`-_z&pYLh-3eFvbQY2w!B z$tO&4;lDoB6i)mJwJXgPUagfts6TE;0~pUI0S4jZ!r#^@nJPM!>vJ$pXdB>@-y&5k zl;J{yGe=z*xN-``PV-X9nXZHt{2Pv|*|@EA8ZAF~87Kawj847}gVZ4s5U8@f^TzZz zwR8+1yx8_dQ~drsDwwvHK5oXsT;+N=fXMgS=UJN@dZu1|;4&}(tjMgB@O=_5`HTLm z*}tCEK9fv2BoNpO_hvm-eKDZFhocQ_4#G<_5B%G9*Y+IJ6SVJndF(9n^SS5#9-|7A zOHqfqk&c5uBHI$=F$>rvv5i51fxYy4%*cXWL ze7yGwjeMh@;BYq1;AKD*HX&$aRYv2*TD#M67K#P_)MH|NRWG0$ibCr2eY&4)Pl|&; zV%0$7o=EPZhZ7J+RG2y+_n}(SpuAR9c$7R6A%tGl z7jzoWoL~ZU4(^|XyyGu%VCP?sPyfeyg!Ln!EJCf;o!m)RrYcjO!@5 zPp=byLe+$pdQ@fDd3g|$(O656j!ZwwH)XoFd+npidBKkONKF{HD(cz9T}#JLr3R)t^jHyI%M;R_+j%@P0UsZD!=qw6}uuu$m)K#hVWd0zuCi~1ZsC9 z%h}qU;g1NU^td6aDYKi~llRW~ZHTej))*=)Mc?n9#*9H!dg*ufHe_`9H8M5Uy4RW` z=J#{?={84qw@P|&2n>zqO-Z;smr3F?+6DM~^gjBFhqyam zUuN&o%?DnreIQYKhIw2?7rXl7P3)hSr|f)?Ta)iDQvvBSlSPWnVV`$~i;q<7o@x;` zw#C>hn@GYt-(0DDyF;$+XC_FhBTKT5VKTY1JGTbN^Oq_&H1bIRDhhWEce)-EBnspr z^dN7-_zt(jbP>P4%yh_(YT}B=94;DjqnTBJ==alkbeSwp&xie1r5*5e&cpW@S4}zy z^)d2`7zsPOSM6$wmxZmwqEl9yOV&LG78bIxK!S#;CRXx2=)(A*gW~wVl8Wf%Yr|=H=>z3i3ogA@9XyC8SMo=m;Mb*@XCK~1`Ofaz5P@=El(;3N z(W-T(uCF&7N=&IVyC*~fAQg6jJgv!oPTl09+$r*gGl5QswXcbUw%T{QN@I$$`MND{ zr*J1D>Y8rz)ZmHzswD*;$%Qm)zlRjLl4Jrr`Oncr?^7!}BJ3VG|IVss-e)E5#HPWU ztW7AfCEn&hgd$Gg&Ot_1UEO*No%nvgHQ`%+rRYLP5Mfg?Es5TGz){oMgO;7k>@@iS z>*)|=K)b=uU@s&ZK~?Jd&WniqEthAAlFkE!>(X38_lBgQ_3IsB2{+oaiGZ*DihG|! z+xX!h>#coM=d<~fgZ$XqLi#QV)6x7bMq<;O@U=x-^^D!=LB(nvjcm^)*BApx3lsmw+TJF$wP|3wMX; z@ymz`NSv|he+xZH`YC(~S46;_JMZ;14~r2w#uB09g)IPr&ds}x>s|Wu-`BQ(MN+o@K|BN|}j(3PLeB$s#%;CNCWKzbt)rC_6 zU+;k{DDK*r=g*=XdghB3!-41Xb092xA;haQ_xdORJ-y}ZezEbbZn?(E@=-pn;6jkb z3)vvvevnRD_m|eaDKblw6SM9cuR#CIHWQp<=!#7HF-Nmisa-5%M` zGxoyUlf7g0S##}8c_EqrPv@35qPZyLbiaew{c+_J7hfLN>#w`Yck%FCo)O>O5GOw9 z*JQ7|Mh$n5e{^^JC2#6;-=`Pm3xvH-pwjg| zQTL&+E%hISy)fV8lG>`*2sZk&e?R0-_+nICpE!dfpEtiPU2}oE{?fPfh+>vKl{gp@ zI~_ELE*^I_B|6407ERYK9U2eg{j>CWdEkzCRJb+TuPg1fCE~I!7EIHgo2&X6$r;sM zIB@LaVxiQ&NM^AbBJ$omCca*CCVH9Hu&(0i`>bRVa+kP~As|o1GZy&|I;CZZlXE+?UR7ieKa*rwZxz-;XCXh31zB0o( z($#&bQ#bcyq?BrwZv$m!^&4A`>iPx19+ANP=T*rrS_gWY@%t-Fokcku0X^f!?lBI zTYAJRbw}Y$+8<7Mz#A)mR{Wee4flkPLUB84h9el0YVeaB7Hbx|vL|NslxlASfrH46 z*so~h71%JO5>bUP4G{?kYW`de)M&z#p&5d%_%(h(SXlOiz6u#rI?cFWdNNPHZ+QNG zpN=mAVbM&pmcA6wj04eMA$>FR{aBhjdowHX{2iBT!#@Ba2?9~Ghfv_uuWe#HhMlO4 zY~KeRDQTAw z+Is^fhNUitppM5x0c*bsIcoR6N@JN3`t=Am2K?LSyBW)9cc=Lw%@yFL^JB@;vzT}{ zlN+Y|OLttFFWX9>Qyq-C_U;8gUOwNGetClfemO0V)LKrZ=3ZazU|kQ4=b)UF)6E}K zBM$CHI^6t0AgXQpjoa^B4qlp zsm58f^#l3U_pGdsDxcVi#mi>yTGas0DbE6JQ2KQrSqx^~b&)FC3V|=JS zLE~}3dXGENlVIXX;!H}_pot9VDnHNT$np*DM`>SMDDLxoQo{amL)f*Iz-9qV)ScZ6 zPS$*Ak$q9++rW3o(d)LKrP8adDiAK5%dquk>kk^l~TW0P; zBlm3}|DsN507UaMbtk_GCR86OSr0MVKl-#ELcjhhV*K*i?~*w=j4HVGxR0N3y=+&g z8E_Lz*xWq~I4x4vlGzG@1OEBpwC;K0vEAs=^K!{pm%=a%S?C)W`eV(mlV*4l!PsAB znp5u2$J_!q&Ir;>zve5(WGb=xCrh2%dA+ggmu%jNo!a-}5D`zxC65igA6{u_ zUfQ6a^yF|*C-+)(_c>m_Ylc9?GZs1%SXCwHfq1A~4uYFHQ$}*cA3)-8aiSed9PBObOchy-(U1&&c%&e5Fm{&&ez_i&(ibw8Sqs*0yJ_t z$gfts-)9cjGd6kE1uO#mi*QXY7G*XvgK5IAb9D00iujnp{dkID+G5v!j>ql$Jo+~5 zx6|SACWmM6)Q|~6f9`q?{L@?kJo4Q%J^Ai$_f^W3OH%@d%iRBC)vD6zw-#Jv(q13~ zwl)_7(^f)xJ#QIjPyo#6?}-hLEvuKcjqR1V6o%XBtmfUj>Gp%sA*p83#+JBK$|~NU zF9(Ug1pBPQ&pAL%3by96f=cIt1I9&m;arUG?Q;c%HQS<0!yPJMznH%pCyPgRqMj-T z=OOm$oyQuf#;%2*>A$n@s5kTtAs9HE_qzsVwXD}|fsBsR9w9Tjh|Ud;=Ne;Qmr0v; zC|a8@=$9NfGF7EFSD&&cjP-}I4}KM+;`Tj~A3(mSkG>b{d2(34##=AAqZ)mP?#y!de z?ob}6p7`Kx;yxdrUTWDw(+?snn=pYHGeHG1OWrvUzLwWbDD!eTH2x18FY~uW;^-3* zAL_J*}>ADhV}L1=Z`IDW8lNSuI8LM%!LLp2T=DEK{(xCu$~pV#j8Bp7k|P> zs6A5%8#W`%?cult;R{_|-UOlF#;8(7)fN`Xix={sbEo=pb+`s;%3V`ffe2j3%UNe6 zZEzfu`wp%MiJJFGOueZNw4)YQwI3fUovb#T_g)*E!u))r5ayAmm`y&)oxjx>Y4 zwLkZw;wgW^h7>^TsaQL^ z^2_7Fna+N>u+;ZB$-y>Gvq@T(0I=4Aq919BrSlpXJOW$uhe8Zb$M5uB$)S~RkE~(d zk67A}saH$~1Pr~Kv*v$tanV^YhLxpVq_5!jy!o3B=O8$@)S{g(Fw(;IHUIX&Bk3YG zFM)S{**BOXMo7-q)^*$`hj5G&DN@Dk({N+GB>wP9FEAbTw!Qrj zg!w#-Ftwf9Rpb*!o#i`SJxNL9zfY8dCBtKCCf&Uj%-Jt{60ZBg#>XshPdEN^$$q{_ zKWABCwIHLTcb5q2<)l?E>g@qLaWD8ZPSsMHZYCi?09j^X?+ES>=EO%6v?_pp8w}8q zFF$)V-Xw1y-OI;o$fh2ZqR`;53;sCgB>ET`@)^ZZDI(`P9>x>FIn){3K^~H4Lp%*# zxC5(ol3wHqke%9*pGT2X%HPiz){y-OKfAE#`oK#_n0Y3MF7QKynTBf zkx`(n=;)hMNJmdNta~w#ZT3xOZfo1{(z7!^ou_|4``d)Xz&zaoa-VSar^Wky_xkHa zouu0AjeS%uuD{@PC$od=*0v2=4ouDWzKl0petMTHxT;c-?_(Lck7?5nLxyl^Wk|9K zYPH{wzrh}1c*ps3hLZelI@FiOBS$=L#i_>skTwLzkN7~qLNlCp>$p^*ReHKhFLLb) z)$$ub{DA5B63cn$$|NXlEkrT%=%hF)jSp2Cf`)QKu=+(30k3~w)WvuR#? z#ML;$l6N6j)lz+aC{OvN&9h`qV=d^i@!@1Dm_dO*ipOoW<&aMI`?CM3nlp*)X}@^G z07?sK1rQg#(hIT(Llg5~Z&v`$ml>#@rmoV><36TKgLJM0m6LGWK$DiE7E4vBHQf4A z_9P8O&bn&hi7Ctrx|fP&+&`qsP@B=mG1pet=jMcvZ393Kid`kT`{qfDa4gQTWsUO zMkufDOQ@V6^~^ZAagna^`(=xHAIhowbViI(sRlORTo-4^>3x>7MJ0XKdQ;u&rhq+L zPSR+*o4mmd$=D??G`C7;8S<;CWnb0;5XAuKC|}p^0gDCHz`}#MZxtl9AaVa%+qqb7 zgV3?VcYSu_4;zyaNY}h=8aTY|kvh7GN>FrnMns8xh$?Vr;ajC#wSs<#dlx9M)_^$y zGff5Q0h&ptP2sM*bv6&$_1nYs{X4^KMFqd@$3yjtgOj$&*pvRG=SfEC489ZbH7xZe zcWTl_+{dj~uB_P$s7R$${z%00<@H)g;apNCiz)&GI868i|Jg?6MprpT@O^AhSSgp7)X)v%SBT)Xil#zX8MsuL(4JdHKE>`TG`@{ebnMn+vMAQRP5hFsKUh z=6I0cJ8ZsKt74_D%t>>26u${jVFxWu;itl`Vq0GCLCd?;K@@aM=07zFu&P7(;cU-a zegj%s2aEu3d54!=hRAS5RQPK~LZ!oQ3E~o)eS~v~BDfJ5%?_B=x74g#5u-l;a+;)j z_)uBBSoFL^Zm)dSPUea~CGR?Z3j()|L9)XD4jQ#j@rI)#_q6Z@6)QTOjb znSxbf%3L15jIv4yKnn}s{;k&VSbFv_8Fs;NE}`5-O2lERsZ=YxJ4W35G$=%i3lhuY@1_LmK z!pOpuAt(>Yo{~aH=71qsP-R$impo2t|7O<;ZfynKkp}BR(QnvgA83n;ZyAq<$k0&g zY`++C3-uQ^C-mRvCJ&)~^69>+-S!s$=|rtk_ui6a#S6j|jaM_9LwdZRn|w=johE++ z32N3`@F-bXl{3d+{G2{n%pb;^@ry*<_Dsk;*`oF3V-HEhgPR+^;;aA{lc-=ImG&8t z2Nso?c~5P3X|Htdr7W^@B#lFO;~O2VjnS33AmAsS>F$^`kO6A437+HinK%d9TrLmd zb!3MrJm2?eR!5D2t&d6|ZQX&eVIMx>ag_Jb zY{V;qQTy0OC~QfZvuEEzGBfL|S0I7-Kt1AT=WymHOq4quvaCsC^;|z*hu;sW?jSEN zNvXWg9UyskzPg|k52tD$q4@_N(4L3T^SuDEDw>h!tN**+t(S_qxcx3C1gd_gUeOwUhSA@C0N zz3;1!SzT)GPafb6ryt3&0fM%!Y;+tbbX(DQ6C)_4@GsC89?zU)E{i8|e%^{|sW}@8 z;qzCSH|&@<6n&F>Y!XRT{nCn$?(ircvE3MRvOBNl%Y8uxLeyQBmWcn}4}0fw>&yVUu+6Mx_sq=4R_=)X2!+QFEYO^WSNC(m>b{KdsFqB*jwC<> zc;fKJ&?iL~!A~=QgKr-+*E6*95_!I#H;|s?JVI$B-PnW@I-x1(JK7P`=eAml#b$Rn z5Ub~S(;ifx?Y(BK_Q|y41%2KRSgQR#hyH6xcl?q<6;$mMipmXggP4t$Z)FeZbwJSC zQphLRs5(t;pH#)(@vr_(`x=pDd< zf}5|bLzztx1sfbUFg$EMEIwC++mtovHaHRtIasg8@M3Y{5kZU~RzLcdw<}M_*{P>1 z8K5Eq=tb@crc0X-yOc?6J;wN^G=0iX{kupd-&suMO1XT4rB4X*K=)prgDF>Q4H62# za*70P>1iQIE~Vd+y%!SimvOHWXG?E1BEf2Y{ajstbJXzj+iSMdD~c4ouaF8HXC{A+ z=VAK}&0JA_g+TD)l{B<%+$x)G5CfU2m2DVBsr(54M);R6G6{Hm&IVi%#?Bww#9!01 z{e^jOLW=u$cG*wJs!cpYfd1Fj)Nf6cewDAT9I{iQW>g#e_93T|+%_^=?PA@!rLEV& z7MtG<5uc`vy-hp-f8sLFza9w09K}W6!?m3^cwhm4u1?h0T3@VzHIKOPe(fB_8f$4w zanvm&wQ9e1^rxUMwskYbO6Q`}jhRA4Qj2`L3P7BdFBQwy(@g%tx;4`IA}*7>HxtXF z#uEY!0YLNYZlWQ+{irXLM|P%Ot8n1K4MctrWxOZXLr>m&58=%b;EW}IB^+J69lY`= zL%a3h?yFW-vm=Q&TA0E~QweXxaZ_PorLI2M{X*cN1#<$04p@+&rR5i_Z_rI#iCUwC z!7zgBDV)Ne8f7<`pT;ziFyu-`vR5sz!Ui_-0DYz{dsj8Q6{?M_@TM|;5yBoZA%sAs z=hrudN2AYPsFzVIan$YPY(RTZBvsKGr3GmD^WDD_U04(BCz;knLUzcrXUfZu5P_)t z=s#Y6l)O-{#lb{_@BtxgKw0`6xW0Q)!;48HaOTb{pa+!@@ZkPSVN>^SLG z-;O3Ft>XYt3TC~w4TBPTsWSdL$JZiXHAoYRJ$95A*POJD-;rV*k*%%EZ;I~M43OED z<74W3QXt~eKxav2x83UbPn)s_Hwj$39@Ou`L-0OWr@q>cQYL~Xrxb{(-d9~y08OKL zZjM-8q%deBN_VnBQOBK!O<~&Y1a=_(|XE@5v1u_pmwYdd;k3Q1f4YbqH=bbC;DT zIdouY4{fzdY_E2CK8FS!$-{J&0PlFj|91wHqC7i)7d3lrkm*txACO74Q%K}D_RFW_ z?3jyG@6|zMea3Q-;2AfHzSUkt8Ksl6UjZZiBLrA9RUDCtwDuNDir$*IVa4{@sDHJ^ z1~`bFdEs#{f`)z06}=Owcsm$S?keDTMbIu6d_QPoZ81OZZ&Se1W}5k3UmwNwgp?xM zc7VI3m-4j{S!(Xp+x~>UkiZ0OQtbCEMSq8luW;EBD|vZeEN|D*$8fZlX7b}+t~kE% z=&I`-|9`M0Zy7upe{y^-$R784I#Jb5QQfoP?Q0mWd*JVMf7bn&`i&HZwef%#{I#C) z%LzRX{6sC-{N7#l!gd4(1@I|;oXzSe=fdAcQ;qjU_aWkOFr+icGi9b{2T$7zwey?K^ay*U^W<-h zRF`E;cki-AZu+WSmHiEbBDSI0DV@V!b(7;dghtz0z`mHR4;m&hj_`=Tr`Ebr}x&#d<+KnMCJ@XDE2ktLK*&7W*%Q)!TqbkQa)aLJ&Xnd=PhEX zs^fdo4qs46eTn`CQ%v944{T3&XC~MxvLZ_%phP(%c+4E$m@Gz*m8uo^vMj(WU7ZvO z#5~jvd(Sg(b(#^?)1v==Gt|YAhS~rC{Dv0}7vMlEXlVdje_<79&+$AHIqqrY^_lX5 zJ+4-*p!G>S_v@=2%x_8VH!T4)X8QC$ocigy;{N0#14AWHwGJ(B#HVyOou0~f@>2E@ zz)-44#}6h@^ex{pGU0m;W85{DA{#DA!QLl}K1|nB-|xflF$}8mo+S~2%5|vUoRrha zaF?VB@7H|G!pDAD14_<+6zUUx`g~1#EW;#}#Zo0AjFIC4>9iNg*p<&f*`Z-{03{&o zF8eU@?@vK!dp`mjlwWtT4&g@||FRs;u|Q)$73QIMz}Aa(h$QDS2qsNYIcl7cBEq7P zn2Gm7<;hjWEaH?RkPOT%N0H};{?-)1u^!Gg1hvCQCqP`lgY5UK{HzGy>-J2HH&`6^ zec;*0F#L%pPXr98xnL)9=~~`Y&)%7~!uV!umApWc_?g4QVw) zyx+OMq5KKgH{0UhaNL%ub}o>miv_|#=p++HFZ=*LuZn#Kp0!r|8QC(<{$QS$P@&gP zg}Y>dc9ME|McBNpZlT7R0lrX|yCpq9OBKwVh6pD{BG zl6kM6v21?lVJt3`P{8A`a@bAfgCW5SH*v~5_6cg!7**_g=%WA5kK;eGEW1LVOct*S zfDFYwxxUoLuU^bl{%|~*+am7k-4ofLJa}89Yj?OHV(S$>lF)VDm0jEY=V2XB1J^zi zv9x#=bBN#&jN~9M%iox;Q*_ibq?sE#%+b8h-!jYC+5wWI59p67#)ZfdqurDD6PScdd zppB`0=N=Md(c0`|G=kcCrnV369D#3-N*R&*os%_w+pe6Ujfk1j<@bS;fbMP2p0k)~j4v+(d{*wH3aFT0&sOw_Gm!^mU8&Us<8H z(%h?^1Oi3^=`t1aR9|2j9KHezOu~!t2!jSh>OEY0X;yip&b|dpgYp>VmjucHN9$yC z3*_&!7H{M5*HR3?lo`w@U-sb#KhO(F0h3drMaeQBal#K zFkx*yH9q@#G!U{*`9PCkd}Lxkk%5?@k@|d6kflHD-t@IzMOS6l1!+~UG;a6}YUc5* zD^%Sfca3!>!o<7}y%RFFQ*O0+S?Fe(7>+JZp;7#$!)+`?Fw!*`N)hwl#;HF>vr)as|kUn(dy!Xcf9~&}}cei@nVZmt7RPEp< z$6Gf&aCs^-U$r4hhO#CJwbnMk(T@87`(2Sg6mYzi8JlYLzx{6XUiVc$i*W2PpXjH- z1Gu7^d&>{{e)LPk`K6b_LJIO;*Yd_#g5R*E$)(DY(amSAPUGX$-dmcnBezwxLL_M~ zp~S@Tud)p?&@dWjgxDe=>`LP$4sdb+56XIEX1s&0RWY$W46J|8SN3=tCeP_;VD?^j zFC3+7as$lvW#3;yowPFO-zk!X5vM0CS@4l`o`mv`dLt_ERQvS%3fV?MnvybUduY4l zz^HOMHOJ&m*w>54GcXiFWBY?j27uIkFebi|6yCnLW2N&e89sj;nj?QzgjYGt;#KV} z!O(2fRKg&oPoPrGgHtmWw$vI~Is`cRAX*KEbY`CG!m1C3LWZpsA1@EOs0mnLn}00( zkLF4ua2VZK0M)<;_-z8}(b9=TCO6P~xm(>Cmd8Go$3gsq=inoS%J*g^8DH9?d2c?~ zMC00Ao93CHhhsY*J(|}qT9TZkjx$e)rA&&Ok<3j&MV!-*UkFH6e}2(wkq|lVubOZ7 zIigx7YCjb%rnBF0i*6WO5!JT;#Y}XTthI762@flZbe?|rwz!X+WoTmbW3^&}2KO*~ z@ZP*26cD_75@`y3Yp_#%c>hdjbHk$i5n1tx`JbZ6`EckC)mpytT>8)l7cb~sbCI+d z8bOd3D}6b`ZL2^H34yF36PO6hfxlmXFw^fp`$T7=V6xV%KBDkx|EPWLhGK0Dmui&} zbOb;rD<{y7j5)z7T3$Zh(T#py7$jDWg0s)~A6qG9v2!v4!O!Ha(v1p`nrCx-;90KmS|@nw)+gb$raucfUlp=V;c}GSXic4c?JR_I+b1-I#O7M8x;S zKi0gN8eR`GQ$Jb?+oIKB9%7Fe3v3qc)eZlX-nS=kH26GQKYmP-c$|SHJT)ew))mcO10PY>0tUwL|n9>I2WMxyuy^yHPUs)JS=}KEry>b19OP% zRn`DCk*i?b>3MQSbfwDdXJgD#Mx+b+>vW)-ZJ)+Y&hOg*a;=fq>Ch;W@g|Y?+#s65ieK;~6{hd7<5*qk zs?3cRqd8zI=)>J9=AAB--=45L@w-Ot$9%OumQu|zc)jcEb-%{^bF)(CBkTodaONLq zA+f1Ey&Pyq-Te1ly@l{8Wks8E5e07 z6q@(RBTgZ3KK8}@{*lm4zXv};-#lpYF@9Th-nH2;+6T}N(0eD9G>G8FUI{7bLt4x8 zaw69x(1znjfbR{gA^p(a-Gghk1GWe5>3(cRXMkK+&aaEo_`x``g-eP>_lXew|TJ zW&Ze*xLjv!hjx^@r1yjRv~kl*l6J0|vEBrb>u1ZaMnuhb?+!$Vb!D|EnN#hU!A zbr-$^a@0Q$5?KThVb~kz7op4@JgKLMdWqwDjiU1^m`s_-0?`E6Q8JOXbX(FSZM?dM z{AD$iY}!ZL0Qq!Yb&fM%~aC4=4oRCk`lApgCrpMIWBkFCH?Zz)aLMfP1P?df&( zvV#LZ-0c!QeaUFP0XYUpJ42Ft^tLab9eC3LNxL*eAcS&R7KIK#8k>>})LK@iXN?R~U(B{_1{MX%f|6~NP#o<_;iW0QXm#Lww?JvbgFYR>n% z<#BYM{FJZ^|Cve&6QO~a43~Z8kVRR)^{NrX8`$O~s4RmxCG~<#%r6%Du*Khk`~5jE zz%#5HHz4kVP4BMhfVd-L86ceRJgj=3VJ3(8{8F!17s-JovTgK{2HXZ{Bj*#pWe#BB zE1DS>rc7@t|6UekxYM)aK5o9#=jktx+7a*f#04mX&K-ZNqy{w6i9!RPy~;&K!Et*u zHtY;^%bqYVk}w=0Y}XIu2?7UGucq+&i2&P2RJVVRy{AcqO!mpGrPMEh-`(`|g#!3? z5=25==P{O<{PY7)vr2)qk~Fh(`)3(d_mQ9%`$ip1r=l z`e z9Ghh(#rVN_W5dk|(Zz|tpAcM7JY4}U2EjIev9v?gE=JFvk#$s^OV(n1+k;#(0FM1M zywD~bg7oMz3@xExM8aS6)Qx{2bk`7P_RXI>f8Jm7>-7jeGBjcg%T43V$F)RC?s~Xb zbpYKDe2tbqTn{PqOfMl2hw3m-AtR56pZ&g5`5T>^=es!PZL%wSjCo0YexK*#p7SRS zdR+?AaD1Ij=1*^y7SKe*CpXTV1xmd>gXYkTMXaW=@i9Pt@q`2%9Omg5FC zw~CaK`6|i}&oT?}1#Qen%Xe?ANSAu=nan_r-$_}jA8N#(zJGd*{o@8DsaA4V%1@#; zyTwT0?@wrwp0Bz^NY_vJFzQRM4&x;&Lx)i=s58?JOPk?yKS?LIu3^KWw4bv6y5}6$ zuTXO39J~QpFI;gl9-}&ys{0x8>~XT*nRFL!O*dP&w?$$vNIqy~HmOLmqde^m)DtSC zq<9_9r)QhkzkR&uD|dVf@iSV*@g5|y&BOdf(li1@2FYvZ&rQ|H!iLNZ+Xpys zPRKspkShO08^&Pb8&xEJ_e(2a+913;IPUUD0#T-Y+WgH0EARa?o}P{^#himjxk<~b zzJ$^B9B(fSvLlqe@s`k_H%FmRYb(PQ)`^lRmGyid(UWR&KRlS!Rj>)aKCO!?y0c2W zu`iG+SFe+ZZgl_xUU(5`%B1ub@zo0dlj*R*;gH)Pm_-qTDZ|u z6RRh{us$|r*vMMF{`RsFk`!yAn{IHU3kv1*mbSq`yUW((ny=0RIX5$U8+!Aa;s7|r zRnbISW-%r_d@m5-5c_s{k}E4cv}&HOkSrUw^9#KuiCcQ2)_0(eG+vm%D`3gF5OJ=M zg7BAR)qqx{S9;W5LZ-a%qqJt!O=^I?&_65`H5Y0^MK)ya9h5bsHjGHkA@Lzww|OF4 z3?Jo#<_8Bl3pC|_$cr9A6*ew(Fxo~C&p8vGPlG?s#FW&~dgN2lVq4|`UliwSg}@`( z5T9=EPN9Ag_ED^P{*-qgJ$V`DMYv;A$9j*qi>xZ~t)cP0JPouN;7P8KA5kQa(V;$tWMk4;PiXk7#Bne`FI8T)&0)f_FO4p zQlD>Q7XeAZI_gZ*sZaxieuRz0^D*%`T&~MIrY&0=!gp3Z=HS~4((fVevwQlu1W!Zt zidHpYrOOlm18VBLx&63hmH8Ay`zCqw>jRa)m1|tHx#sh`jqeFKTLV4KYm~Xd{1Qfn zeBH%NIz|K5MBwwafOx_B&3y)A+DserZhT@vzK^!Oz*b-X{7&eSTIm5SLy z7@ZxxL*l25^7u{O;d^#B_j*;b^~}_V*Fc0h8!MJe-9IKy?cGV{qPmt3t#!^p-QagS z!E}P(Yc!tX#XBqd921WNEgGnAr4^b!_M9`;AQjL3zWFFf+%paxoT6S}&Asp?wb%F5 zoR1_s=+zUf3&gVkm5^6Di^=nRK~w|l?_3Xw7^N7EK7^Hh+x|Svs`(Vy+xPS@ALXw* zKu_-*l*a~%1t19XLr2v0?_@Xo)_TrOId6o&_YByFhNUtX2xDyR-JHi`pP0Z4H}g&3 zY=XK?54Zy5uE%UG?Gx)3+50x_CI1|-m1u0+&tvi--WvYZN=hG_&KX*X*Y)#2Rww%G z_sx5C4Tw_M!o%|ty|@?U#2@~4fDo*aYw${`f~|4GLvfJKM_nqI{x`EYdz_aYPw?Fv z1|p2J{Wn*V&mdxV{@#l<0xb#sH$%?pPDnADf<#teV^*whhcS!K=Bm0S^tjc<6L zSi>q;(^~uM&n1p+erZ+zfp9E1-jV@ESiNHhq|6|Tf&wV|RH*`gDDKw!=no&hOb}?F z{RlqfY$NQO=lk+SS>P`{UOcMM5Hv}~KT_&hIX&y}llOgD(3VQiVTFVK;>rSbd6*Me$WXA;h!Y=%1i*z*qx72lPez3i!hB_1Ae85})s%dsSwa zax`hh-hTzE~7bAd=^z-5ZaVI*!swLre*A z3+z+RX*!F>_Kf{=NQhH7?^UY7h(=?b3-@>6CBahb_ZR;qXb_etA&do%5+`o_-FQtT<+8C0X^$ysxf|`{$0tZxC|KUg+4v z=?rjbzdSOxXP-9-@;6WTd7J#o;%I?>W5Jrli*%0IPrJBM&^bebay6-aj`@5J`$};i zX18OX1jQHt{PdQGlo?^a&C2n5exZg3T%{xJGuYf)K;X;$wFt?iNz%LvmrGf=9;y$_ zMnXu))BU+k-{;mQ%tMHy$1N?^3Yi+S{HcN9bWx%%-Eu4|#=kU{Z(|fb4gVGyGD?2F-Q< zb#Jh>gLw`FG!sU*iP(Dw#e5!g{^@FJzVH-}P|febLZIW5mso=!IQ2nX@UYWE`Aq}# zsPM6$l<__tTkv$wX6Dm za0AYop!`0H;QHBbMBE1Vt@S4oIf*QGKF#a)jH@_i(NPdqTWahTX_zPoJ~Qazlr_`q za7d%#f~L!Q;4TJsnS}c<@ozNr}sU=4P1T&>F^AUR@XMoA7Ch?zq^9< z?oq`r4H!uFx|Jep`TocYH&{Z%Vm1WdFlRV8Prgmq9zNUg=JKbff15w|V&x9`!SMWm zP{&`c;~00o%;BiuaWW{&aw?JvqCVE9#g!xIy~84~M(ptm35sB+sstFtxxdkEd1k$2 zsGNgJh$Fq7-Vu+rxu4BpPR*NsiyMmk8o@}QrBmSeA1gb~kJ?vMtIlk-!(WiFurO(M zjShhxYLKr=A=@6u5>3j0%yMUB2{8@ffuG%ZQ~Pa61KNF>=fHJ^Q(7(V+I?P*y^j;C zQt)G`GJ6GKDM&Z(e%D8eT&TUyXsg%0vQ1ZjF0RkTk?pgJCkdYR8t#uY8DZ=vKlDhs z#{AuH=hNZ1CeZYylT2`}Qc~PLrQQ~(TOIkg_d7|oOB=0D)&~bWE~HAXlGdc*Aemt-UgAa%EH3Q z{~iAptn=e-W80Q&xX9Z5sqjv>6S7bx=dFH!l%#nl=Ycu|uv5Ix(#H#SNcanKJz4jA zA`npwq!I_#4|s}gdps#Br5%5XcA2IGc1qw-4xnzC6di(}h!jB29~=4;?#Uzw$n|Z> zGBE1z2Nhx6Rd+CcaAd|>q>j_c-QRMI#Lmm64z8|0R%&D4m!HJwIGwB5GMi$A$2q_|UiMcl)-pMK(;gDY%VlMs9`@A7 zMU+Tq@;xMST|RI#pN=K;zmHx!*fYTqs@$jgUE#6a5oM1ie<%AO8IC6_&B?ti==4P| zN9wa$uX4(utX(N=sqdyL2E`<=@!IK@&@UstCG>Yq)vbh!lYH~*rni+dP$ z1sZ%v9R99d5KnIB@m7B!z7E)>@Xn8T4^r~&F5ilt@M+w4_z^ zKJ$5B9U+{-$Ss}O-tS@9gbD7ABOt)W0hJi|SR=dFE8hm=Mad_nE{+z$;0%uz#!84ERtI0d54d+e8hv0eVf zYXuz)M`3UKtQi5t-J$w|JP9Lk@^b^^)Q zDI4wt*+#J=0v)nME?&80X8a9ZmHFj@-5Bzo_7R@t0HIWH0Y;rlH6LSc?(9t?X?VZi z>PtDo4gK`KVRgKf5PkLng;g(UnK*ZN89FCP5u=CKpOpvX1=P27J>C+v@Kg59|AI?l znF`~4e>0W2M(tmF)Lsp%1Gp%|TE14LO@^yzH1!Bh|Gh;u+qmp%VIp*Q z)>Wg5BkGbjgO=LBAfF`^AIB3BgOdu9h-k&`x!{jNdT#n8clYp7ZywoQ(*PJ5eA)6J z2O_&}$GeqPXJg$8$b!Xdcq%L0x&Ze)ZV^i_IS+ZJPIT z*QNUOy^^@Uim1SVh6&fJ%lBc{3#Tn~lWr2PMNd!=wa`dB9PvT2?>AyG2p8Gqr%V>N-vD~&NsYZRe#EYlHrUc?&i4GvB?rZNCr`Zu--spWX zprG4RWKZ8+c!nLU7bpYrkBZ<-KG)~`Pxn070D)EDssHOdWe|mss@5-_9;@H(B z@*B3Q0=|esbsW*?rr_O!^K!o575_Gc z`XrC?O3JiMnNh#u<==&Ir)M6q#qG{M-yKtOFTZ6Vlm+`^8m?KWRPu{ClOi&IXj?0@ z%#tU`LXfJWE<(U#t5u=ab)39!MvwKMvf;+%mC1Si8r{9YY!mzQ%lkow5WWV5ff`vJ zU|fgT^8OHAxInYGJ`%>fdg#(>^%TyX3Ai({mxp7%#9|Ge!-d@T7yeO(BlpxoD(#_k zH3Vm_OHJ|fRd&6@X({g&WGx=PD{ViAbEQ`?5|^|(apDZRIl+b4@b0!s{M2WaOAHM~o*udlt6p4Kq61A!@YLr(UwqVD4j&+Www zQVH(Ha5^tf4%iGr`X+NQzoxlwz4eJ@4*u{ESs!WujcZ}8IdHU)AGeNLI1R`kbnRVB zoxIq2u&sP=` zSI#ZbN4>UgX`Dt;?*Y)59X3CUXG(vc&I7cxJYvptHML;r7+jFii*Sp8)73@TdDRo6?t5Rzj-@4kq20W+r8)$XnZg?|&{TYb6AWsKr$n!d z(7*B#{8_O7&P-Op<;^|oVu%1lWN-dru z&49#E{W&x;99)9pkoX)8*N+YYLf#jo(iLsExS8YyTW;1Aw|D>wPJ4bO8KenVuORJ- zN|G_2Eu)~Is)xFS9Wfqz#_W{pa%3HgAII$#f%?Sg`J2y|-i&JnGRz$uHLHOAq^(wd zq0FOwFIxGG1VeU|+Y81?uP9It1hSS#5M=x$Rb3Nwhwj2J$LM#fZ!J|7qkja$fvr8% z5uhbYC`fMAYMGDpEx(c$zlIM?7??E9`XhR1Z@NC(g|^=sabI|DUFIeXLZwD(EqvoVNzhRI=Zn2PPkK?SpV>;P`O6(7L%w{*le5Y_z@(IIw_T*x>ob5# zFKqgpZ_ihG3|(nR`>5wq<{F|4zU7D3r?8s6)XO1}#iL|EGEvPqV1u1ZwmtyU9(t{k ztR?Bg0ODPpXMro;(+Az7$9Urko#G&MBAWrg<6O#se5=&{x(w@Hir$x!_u&W^?`$r9 zdq@j;U1dAn33x_RTZ^_f%v0I%K~oY&fhZCY1f1(X+%p-rE2*rFS6Iwx@PJ{+*qsad zyE;$c$}qacqAmlNZrXWrxKdL6qE*%MFSk7^`s~}v!uGtz;FqYp+3o;Yi3r*u{=}hD zoiUmB`!>?giYQPCss;l`9pT_60*L>xKi*G+D7`k2Vb?;5z)7Rbe^yrz6WpRpCd?Nep3*R+ETCT4EAxkU!T>dbJFq5sFc8ziVDp4j+lF=yICix{+8KaEW1Y} zI^trAe!E^fxi3z!b2>!(pnx&y>0#^_d~eF>&oOD-@gx%abIPsBl%p7#{RY$%dIIx6 zc6Z_pll1dLi#X?_-Ef$vy@69!;yH!oV1&OIApAPzn^1NqqcnSN^sh(ji07`KH43GhlGCgUBg%2U2aXypgN}L1Z+4_aG?@096dLU)= zA1-`?2H&5%p>kJ*M#bh5C*Y>^*AJROelV=U>DU65FWxRncxjMRin)AQXSE@M>~%DnoY?3vd{q+k!LtxD)8n+EHvze;ra^6guNITsw`*em z0a`D!f6K^TJmmntt)t$Id;Xfbn<35nebeF(wMToXisLUHzJP4AimPTcH%a%25BDwi z`6K+=D;@Dpaby=h&DJXe2&G}d6O5aAl<4j%JXGCS5dA>oM}1s=tu<1&o0>azpBg)P zge_mlYQ6?H{-BttMli7gnCyNOp@eS1q~PM}r*XJCuV`df`M3=IoSlC1{h0IS>r(L4 zF>Fghik3&f#q%KU1>z`EL0|CM?_E0!74#B^Ju10iNc=Jh${0{>!cp^nq%6CPO$2gQ z@~M?UcG`hOMr7Tfel-M&u58wu8vOubiM&R&$C%E)h*p=X4)E$X2Z!kQ-iYYA&aXG} z(np|@{=P=^1SF=8yGU>q5m&f*xy{7?=Co<{s9v=vcE4ZjHoWA^ZSPmyQ@AuE&75C9 zRZ;Xs``jihBl+9(o?E&{o%XhqSVeaKFRb8|9_V4em&>?=#+TozP+9@IvslkmFpQ2+ zM)H+jjvlNY{PJ@9oSUk*vFFfWqtg!&bIk8OnHR0al$fe z=h+!^@s=8m`%L&Ey1-z{DywF{6=|xW9V7gxX}=;{DZop&L46pNeEU1KCcHHRVe0{_GrKF1wDA&`0N-tVBgG+J}{+^gIWj-aoh!vp(LNhgaxggc`Y$ zg`e~V=>c>P<_vv~y-pZ{jTwJ!Q^>V@a3iicA-q$EPlb{QxjB%o`)-iJT}p7&6?mGZW~kBT`( z=ka-ryB;q#CHZuxUsH1()Ix=N({W!;^77s_$>)#T#8G^)4=T>FSLiz0ulw`VZ^E36 zu6d+b5U+wWH<*;kpRzmw6qCWp){F7y?zl%H6)EFms@Kf}wh6y%nfBC9*<~9BZn-r) zES18R5bCIdl-~mtR1GTG{W{wsxzIBBQm8k##?f%K1$;nHE^%Fw{vd-a~M>G)ZdBq4u* zdW2F<*3~l8b8ww8z4%7pDKZ+u6?7n9U{H~ltt*jrdy!}TdVm@vb%hf_e$_Etpn+zZbGnP`8+h0gWW`6uZiEQJgH{~o_cC9Of*&fY|%(38rXpR3#2%EQ~_xM^t zj+rBVPa7*AJcoRk@7_m8;GQI02(xs@By^pPp1CtgZuG!Vw}Bv7T_T+o@yiPDh#ux7 zj`wH?vM%G<AM=wz84sA>BUp4&;jB|SODR`@uwb3O3z`;K3)sr~_?y5AS59`5trc?ce3czd{Z zd+ggGZU{t1^AUQ42k^aW>izWJ;7JU77Ch3F0QKqq0e5&X=Z4!p|F{<;{piCB5Cg@? zsC#(2fXSWn1ih9|8=_YQ9K`dx1jA0!jcGBE6>ENy8T{?=mXO`^Xg$t3Af_A5mnKH2 z=-l5gii39->2`Q^YU#XwTVzm&4ywtoADl$yIo7*RtHA?Cw^LiCAaaevpKC);r$a9I ztC)OetpdUqUAC%Y=tmAzg1vHr#q8`|l^@oy;nV(gW*F&`%6C7XBO=MOlo%HJ^(kbc z;`Y^WFz)JcVu5=M$XkrmMjbO0zi%B!UyKTHyP>6j$hv0cr-Z$0(A}#1UJ=7;?iKbh zIm@+`Ob0fsfSlrfKL@|^$slWy=kfl%>(G{u5mD#fcwN+I|4E3bMw2)Sjp2^6o%r;! z&*$(1t}cB)vl6!OoK=I8^=(>eJ4Ph^i#v1d{)BB?W4pcY-qkd@3u?lic)3c0<{{7< zlxDeOL}vES`|xLDp65o)ahK8A8NuKqPq)p+2N^Ly^@6N_CokJdjeDeFpi zhx$|4R;#`<>1cgVl5;;lzw?6k)T?eTCSa6MSxrjklDr{CJfDWc@O$&OpD^NMtNr=3 zuL}JfpBuW|7t`C7yZSK)XSQ#)US8bd5;VX(U+?qFVvyJGkOsyJJ!L+(GN+t$p(k_r z(DOAWH2>XWsav}UU8~{E0$|yr&yRtVFCNE_0WHG=`+8(!3f0jfk|X=(gNoK4E*?Ws zi)8HZr>FlQZX5+opW?qIfrQer55nht z*u-l~qJ2wJNRB+n4S)51>EWrz9p%RXT4*;`di9&P9{=p?+kIITHGV$u_)V-_KsWN? zROC-U)$VV~&>EH;zG`uz$S%zGAmhT9T~0E46fhje=YS{@d&$)C8rZrCSKH@#qsgS! zW=TbeZzC-IQ_MLTtP0bed1uOmORQ^i%mmFDE!70;H381eCs&;+THvC#Mr*^*R|Oc#b&L<8t9o zo&0X$i*c01XwQ{Q5!huKhc3x->$yf3g&twHG)1VYw2>YiVpr~Jm>SX|$8 ztsnRYgAVcQ^5tTzGDGp0@2kf^2LPS)B(Y*h7!BM7MZ?q#)ldB<{RkKUfGx^Z7b+5f zYMebW>pf%uKsp{~8MwLIzRbQS7iGm~xDR6WcwIUw7GQuZXerO z4*QNWFK|-NnW3%3t%hrCQfd~mIGWKYU5zm-gr*I6qMET^j2+NagF4}adrBt zQ+^-p2w51@fj{-(-kja}Z@ew&@}_P0^@$7Fy6By@>Q|!om`T6E88XBPMLe~poTt1p z>)VtDNj_xV(#kuSt1n|{L`YwTkj>n!Puh{bdLv)SEVDDw)gIeD#@8H*H1y)!>IU-v zU5^e3xy69=dzq7TV-G>h?EE7KApLR|XsNSyr{ARJz7EO&i<3*1EM`3UUr^WxUxb?5 zz!n+$s`t}z!p+NFH-}7%WdW`Bv*LU3C^oI{bt{Wcmse(sarWBg9|0Qj06Yojn`XPl^76EZj&o)@$gtwK$?SO8;IJnyS8<;nR5%Lx1eoPOSo=1$%KAk;LMKhm zBGo=YClq>&5CH4jT3alrzGF#NbLx5JsswUcbVbQc-SK|GH1&FDse{vFdlpYGXRH%8}lrUlMB8K3cd$A%QONhus^de2+S3;_lALj zs~?QKQ=PksE0;6W4{ts<1}qsz#V@>6@)bEXhk2p0h$XIxaHCf}5w;lAs1BgCJI*OT zjxcX`uFYSc`GeW2KG=KlImf-L`q<2Tl8WGC%NUC4?TPGNe8Tm3V_RJ-4nKN{p8GzJ z_2m%EtY%#C2Nc5kM;N|Ms$!^6zQ<5!Fr%bp#1v1#C9%I5o5 zI-4Y}Cg}CPo(0X#lwGV>xe0m8U-dT93}qLSC=w~y_m01sddWM%;dRv3Q1-gd{vpAh zJBqOoTdw=Y18aq5rg(K4mlFAbq(1qqstgngHWDSy9m!S6))Fb;~IBwGBk`cQAbQF{r*pHx!!8Jv_%a7Wbfy+;M;M~P zW4U<2L<5@d%DF=`a>+tc-;jj5Yq0hca7@71OwlMtLX%chB&#nJMO90!6cZo&K3D-vn&)#ix9cZ6dWLcr_(k`0~_pE<(C4EAW5IV$hAIrIv@*1HOVc=VW7 zE^hmm+|Jjs*eeHo4_pgS-)~OSLOZl6`b8Eu=q>3+5kT@w4$r_qwbxj})GR6b&#i7= zNTvuG$NE84Z<1emh4K8%8x!w5RWRMH^Wa;vk3kCtBo3@w09Ec?B7q`w7z+R=b)fGs z1v#8gzwdNiLBe5+zJMbUjHms+I;;K1(W$%rv^5GTt189`fq$$*{axXkiO(%xhvu&f z_LMsf@b%c{PXQ>KJ z0@DQjOMmWwf(AK{v1u2S931z&Iy`$zRn)wcgqxiQd124tNK2Le%B@4L_IE(`w|jdl z);FRQw7fcR0>AAu!ZcE3xil}|{?U0o4%|~Bl`{}%c@K;b{9(Hn^l)&FH?4nbU9XI+ zQ4~yd@sO=_9Q*17r$M{4NS&_hX}$bP}i^XD3YY(ejfWNNiNg)AW>zgp$skkg1d z5W>)AdhH(Om6(sqS5*FpttRvW#lnOpfDHL;^3BtJP*XwNOL|Kj1Euv^EH}$LPZvm% z;S5~;O*Dw@GBjUE0V@?DJ(JLVICUWwTlERWRD94Pt|^)%$Sj~__5eXoJOyh+@`=7_ z^AnLhi7lclpAyyM#_gXRy`uzJw`IpCiQ46tL4PD8C~TkiR0l~i<39T(e>@(v%M3{1 zw%f3;o5%pfj@LV{vg|=x@(ZtIj+CQVte^erv>N1qaPgKWM>)LRpx);mUb52Y*&YiK05+eD zQ{@0@nB(LPx35uWS=Gv)6Zq#OP2a+m=upkz))hs*jEwdf@A9OtS>pLY-+)Jc)^iwq zh>HTLX?z=1f7~!9MD;4>RLLK`9}n`%K8Eq!_4RlhpaZSVHxQesvbH2i?U7bgN?jE8 zfp*Hen~sDNhB*3fr-!mEe(f`I3hhTcnfrd%e%*p-vMf6K^a}vej%ALvlJ7~aQMG_e zk;w((5ub&S;zLDNa8D~;XG~kMNHPAznL-*z?w0^RiuFMpUr8P-Zxgt`owDw8dRf;W z{L{Lqe}+^m>E{YPLLDAPqTH+?S6HuGhdmQOJn=Smclkzs!W1L9{AdtExbEHoDAV>i z^Nl+S8&H~paeZT?xk~-}*QC9`riwQRgEYt2<5{X(adb!h&+iR(!{WzKzk8@b-+Q9v;R_JC1RoOzCU0)( z`U7SUZ;^?CkQbz`Ts|4dfoLKg;8E9RJh*7YwTA!;pvl6Wsnfl23H5B+^?h=F*W9Hj z&QvyA->dn0F^l}tS6C_w>-f_B$Lj=U>-F-RHBhH_p-;EdI~qmx%1kzHeH7u)f`NUzVluOsS+fo6HEaJ2HZ; z3Rx)?-vg#KDd)eI#0La=z@cZBOHL-dcYUBB&U?Va-zF)4W6y=3fzCFjqPGkGE}YFS z>-_Mfl{R}WBY0TpuV`N7pE)W@w-)I7PynzPX}qs(&$bi{a4>g7{!4DOVgB*}e&(-) zqC%E52bMTNTCO|6 z7%}VAu9)IA9uB5aZdqti)caU3+=z&MAEnWvs?J5)HRSHcfw~cPaP!3^#}0rHwvIyj z!l@|f2q*5eYz`4HKlD(oH#Tckar^v)J0tE36aI<9S19fX7d6h>uaG|<5Nenpv~V_( z4cVA@5vsJU{|aUtdJ5@@fA-2mOGOV*zD;Q0nN%krQt%FFg!??)t^by=`0U!G<*gNX zw0Q&>)llSwKsk)oG8)I2JiMF}+eVuF$m-7U9Hck|De;`bliyEwk6>RGD&G&}b%Unh z{C(RwfsumKbV)vqD3bZn_pWl(BPhJDD!w|4I=ZKQ85SQcBp|B~g+lQP?X8tPk5c$T z+w4nGj&XyLU4L4^XPIop=jLg81&48>fy-;dG0!<1JxhfVGFw_xoxt+K4~pv-OU-`Wr9dJ~Qi6}doK7$>*_ z*Ey&AHbe750ttfIteJ88vXJ|<=lr;&w|IZw%8$7tj?~uv_0rpxGc3=v zanzfG5AlL;!V-eJzyKn)|CoHry?rfmNdf9#$*mOGpA~Fkcaz=Z_{OIClL#-_2Q|@u zS?}cXZGZ|Z&jV&!zBM#Lm7o5KmvC`Fw6lTCUJLN%Qg`_8YVqHRK-699K4ibnqb7D(oKRpQjXO@Vy6FBP1mHlnHDPxk#$*#WCNwR4EfyF?H#$8+R}N|MDAM; zw1+ux^F4zT$5s4tbhKztmpiYrwyzS&weVE7NFP`4qB}IShlKGl4~AU$*t{tV%&0xL5CF>>(HsCGZ9w=NkYabH6ON5cTA9(cFG5QMo$2Vx{M4>!qGn z3xNJ6y2ne@n=~tKl7vE&v=Ow$K*%wdj>9f=hUysfe}+U>yCHdizAh{%032qSs&!&Q z1rn-(-y?}R23mcS)P+dYa(H*c2Y@o-ZW4nNU=6DI`o%wkMRg$LoCqS-YV@6AP@vDr z7rXNv#plJlts^xNeC?8pq4xIKl9dQ1Q4(Jznp*UckDIZ=a?*X>W{gfpA%(hmIyliNcQSb2Lqv8IqN5h?=s^Gr**GKg%n!K7WA>pBBw7W3V z@x#n-I3~H*I+`WPxFsJbZaB<3UgngyPfX(b#WD1rC+^2N_S#q+Bs@m%q0n9S+_s7T8)9GDr>F`KmeqPZUfy_0YM|2vK`!eJ}(0%`IC}iB) zb6j<|4d}V8VF&GnZ~{B}frz?2W|qHieW>!`bM40JYOX1v-5wIP{w2VokCjq=YY(8R zRY?65?Q~79+v6-jpyq7N25B#GB+&DkcYeXc5?b72OY=$_s`daV)h*5su2GY#%*5mQ z{FhEWU?_sJU0=Sqa9N-5wnk(Dnos!c%cy!(3b=gUkuG}_fewc$Nm4a{#`%3d0ENBq zbwymv--mRstu?*2Rm$=_7WOP&bD1dsyjFpd^S5 zF0DN>+U6mCQI6FIHmKqrsU`rxHC6ng72kdWjnQ2NTTvTD+TJIzHv?7?L-H%Dw_5O= zJ529a&mz!_Sx(Q3>X=AiLyof7B-c`ie_C6}>M$|7zq#hgP9l0q6ac`tcW~1Sf(l_! z`KZlTOQZ?vNdQxl4!MRg4^o12D`tt8sJ#sO+>0bP+c=-PEcQ!NJ~XHE3|U4VVkHDP z>o1}Tk45=#)2oghz;3F{J?=L%fEqJkl6EcSx8D`z!p|P0cFgbn@zR0)T*=vMe`5e4 z?-f2I7n^yyI6^$%^^XzyYP@<ko-hrKmJMq4Zu@h6eR;;}W%ulhuC#T;duD(tDI?hka&w7YBj`(AMt+Oq@gYu%z zGtjQj&;8F>8Nx>G?=?AZRIfvp)vhyh@C9lH5%(-oK7U+;_I;ZYlok#?QBE_6)VHm) z`NOf!j*=1fO259;qrg?_*~_WAgZ$FmlcicFNu8J4 z$vWS0$3*qfDPjBwmPy%lS;Th#kgC5|3GQ9wkh*vuH6d_*w`Q80C7Q$dy|(t+r4@oU zEhK##Mm4{65(E|c1(8g#JK6?5g^pd^&)e@&zVvN=iN8MwF)|fU?fnc;GSkXO`Ck0f z(fytCuHe+nSF-Q&x`Tst(b{qZRPT;b@;M`n6HCM6?s-4&gA5;#T5OBNdPc)>oP3MN zzPiDegvK+Rd#N<}WWi?DlDwVmhh$^IX7r2*3T|cwWjl zqoDV3@{4!GW}A}06~e!O+>hNC1NO+gUT0WX`P;lF!VkE@pWw%dS$Ww<_x=?QAL2#I zY%DA;klyx!cIPXR(>i(OX>qQ4XY z*?)wA3Q2XyX1nk8*axTU83*7eh0`F~4J)zq_9)BNAs)q6V0zW5h5TM=FQ(bN>%zI% zg03d*23<;AT-*)6?U!ussB)yA7Izr>5mhByJ}uG=)ePtzmq5{adh)8%J*8x z-s9y6b1Xr|UEKE#M-D57CZ~7DuYB`b>!b-)pMF4brBM2(QfPr@(ms@fEL-bL2*hpv znr7bR1vu)#IL>s~ljsq(TdzT0o2Hoa14isn)&P|f2n)C-W9bd;6SROwR}4L zxjl3rbw2d#9-h27A5Qjp<$3F^jqSPBmtR(9MY+%MCa9Rg<655~jMnPq*$dBDR{L~< z`1IA2wUf{bN_E(tU-5fLbGo>Hcf>ud>Wr@s?RwO3 z;l!RvR;USUK&c2N&>fK2a4$-9x$D``vJG_h>7`vm9i!fl+9#SBe8M{*ENxTEsBk90 z!2}FVoKwKu(y}U-GMZ$#+e(csFy$9TZs8YIms3E!8Do1Bo*fV_eYtnUt5y^43KgdP z)@Ak^;+51BWy#5Wa_(V^?#suF%gy~w=42er{s9F{^Vmj0nMBN4mCzwqJdH`ZE3st1 z4iuTuoGU+rtPj*RYxt^sAOYa@77eU}zFcJI1EHAb5r_|POlwi)kjcoa!ai5Swtw8V z(Xp&liT#{y-Dia{AUsGVXXoLYWn*^0)a_%$$xFJzy%amN=p0D-Ee!7?6w7YUr*4tv zJu(^(o?HzxI9=44bNv~=rOsxsb`%)e!B_n?@i2VvROp9sCFOHq0F2H?oH5F#pQht? z3R@*bY_d6T2y8#D`WoeQVo2#K*y z$%hNKKm{ffVIUf}RY)1tyIfW$j=_ku!ihV7&h}9mk7E4!IaXkLK`AA zrtM%6kxr1d0ZPTR-450RwTGzu`n88dGc&4SKtB zcE3(CI%jQ27#;kqo*qrS)4DuQbmQ8CEWF_AatfI_NhIGt+~d7ot~Zw{(t4=AP3n1l zqRKk*K>*z@at*^Hs6||Ta8iD|tv4_HLq6C{PfHz|UDlrnAj z<}38pWP+!!Rlg4o+T1@5dIO>tU}>>Vn+3VSsyHB_NNqHyD_+;jZ|`Y4G*Yb%=Ux(- z&%KKai4c>lTkmfLvo%X7gxHIuueV;JJ35$v#fEQY8SV5UpX~2)fszHdtiMew`v)!@ z2k-E9td7ug2oD9CIStwbb}CDhZDmD49o7N5{Hj8_>Z26*l~qPnuCR{>{MzOB`t?aG z#thU!CCW5Q~i$<#83 zTR$1(vHALJN$is;nmzKD{bbtXM0lni#2jBQ9(T1BFTFzi5$X}Ocs_4!iNn`<*=iYbkfcWhB2*}i5U_s33=mhze^cOx@1kQ(8KkQM1^i7&jrMzn=^ETW&KVaF5 z@3cRBCLoos6Wv{@;0Xomx8BD(abaVL9TQ0O(i~NAhu=v+^p&~H^WEz_TfZMcb@-;( zTGY)HDC1VP;RgHgU>&~nZ8@@Oq`juTU8Mysk<&*lsgrigK9xdKN>XP=0j@UGpc>E; zoS3c;w)G0mfcdx46X>_@1}q8u9PY;FU{9oYN-x)?3@Pejd}BFsHzuym#G!s{n=O6{ z_mZbT&~9LW`JzXnXeFXZ3M(a5)eeyZ+%JV{#8G+%%D_%Byscs%q=AD~^>(x&*MY%q zR%^oy`!~E@a2UJUHWq=7%_0#?EBR}R_ z=q-Ihs#AickH79^Z}SDV$~SMj8Quyd;@Fa<-L-w6a&__R;LEpq(uLbkFF6t(P*4{b z(p^SYw2P$kE|m5QL1QT|Ck)%uwL1L?h{v_5sKhkMxQp&5UK*4aDg9( zm7ybZ$m{xg<=^flVa}%XJTC58%})_(HD!;}HO=jynkb8K4daK$fwJ`&77AKc)#+@!^UO+r~nVOF!4MoS_@i`t_|mJbpSmV=r3ch-ax#!)SrJf ze#PHaO+dlxB|M{6hYWt3ShmE>B)c;16}kgm(RkPN(2?<{A2^7fp0o#fX3$RnDeuMP z5Oz!BW2IhQ3LnUfNHS9nzYGngS0*0sZ~9PGilxi`@xyzktCR8^b048>Wgv=akP@oo z9&X5%v;;#X1r+4^;J!G*Pd zl;i01>n8khyOJNv^HEbm_&6j7L0GX<$K=zrA0Of~%+6`QQ}7FrxvT&Jxr3@kS2rVY zK6u>SPTq1=E*DM@6IhL7!tlfa-#X$aSQ`t`t>wj|L2pwpch7Y*Cp&zi&1OGnyqb6< zkX|r7hjR>hdp=c&X@9g>XKhyf4$tixfOIj*C!qzUuG7)jFIOn|=B;zymqGk|MiW$f z{(S$jGvzU7I=;TSU9Ly{P0V{E2=n?dmIRkxoHX~Do~9NxbFxE|-yuwLdRz!2aUk@I z1FY*KjK+nt_BHZ(y)z0DhEb9{+9^uxDj%!>3R;r|b3;k0hkt06!JE1|;pSh?VGUze z7+>OzI4tg6a4j#gE6H=ab`2`uV!yPpmKF5jcp;$iz6ix9Mqg)-O{T#IK!^P_LKo&d z1h4xGS}gEZG(7W6u>2nKKVBO?VC%_e;|dQn)90L0d0Bn#O?zVJwQ&biIlq@sji(5> zLG9njPJ;w29FJDNBnG&qv$zY;IKAvUTT+2gyEJgHB~wtI!>e{1dU6?J(qUR=vL=Aa z9){ol6q2Wg{+Q{9jC_iFkNz|7A}OkreTkO8kAH0M3>cwaL1vz`{H1-qbD z{X%fGC;DnItU`eOKeL&cU@=lZjkyEoL>aZ2;Wmj`z`}UeMJJl69vjB4dROMW)vx@> zu%p{V$?p01BcMzp)OR3W_HWMRGa%BRWX#O95N+gdE8*;w9$|?C;_dH)fzr0)SB{4S ztor~ae8<{vhQu@})NGq}k zzz{wkBmcI<;hybnpX|@2UQ@IE)|hepNL(c!GN=*z+slT<&gb;~>_{INYG<=NuJ>1& zltMIqLA#ZD@AQ-4w>%Gal*O7<#{AdtV ztH4kWZ>X&o-%t68P@oi>^G2ewd_rFR3Fa|;jVBUnkcZnoUco1JTR9kYGGH4HGw)ZnuHT!BcZOt3(p^(h;Xlihj_fX^ww|%~9MEv9Kt>dCv z+jntu+kuHKBDTQvj6L1mV@`MXh+>P12rAg!E!d)%Aa;v|g^7wSw!eG%zI%V)b3X4m zpY!)`e?~S;JhRrbo^?NWT=#W(Y!oD?N`W^TB(!G z75IrfB~@q=h(kgtG0btGNpgdgBqXzfP7+=jlcR`ClA6k8;K4z`Nr@~gkFMh4oRc3g=>gZ3FT60K;cR+l?VII${=aLF*QS4hu!nfQPMTQbSfLm9K+Bn>=jO zC?qnVGlX+NaX83)NlZdC0lGrmK{c{}BdQXhFadkb-BBj6xqk zq_jq$RiG+T0sO;(afCQj1nKYwc1YMeC^46v2)x%8sta@s>7gi)kC{k33Qgq}QHT@| zTZAX_IeMMX1N~@Z3ZQ-sTbxN^3q^P~0gYyeA#5NLAW+ta*L2@vRr%;u6 zoGzeJi#cWnMrDW)Rb(_43Fb^*1dMUvC2|wYX<1s_jkR&8UnA#aWl>zCmr{LW#tWT>T zpaBj{g?XhALUNmhNM@@EB%M8k@e*lRm0AUhnc*?mND4XLz)Gbe7tN**pi&8d5Qdk` zBn(MLrMMIr1~LnE)|rH%!{2}Z0Zxq}3GtWE z3gAwn5Pi5%#K@OGj7SZbVS3>fOm%5tDg1el)nyInfpZ=%02;<2C;}h>>&DVWf2bbe zb|jiXA6x$q|bB{ zgBVOWriNY-GzVyCIbNHPXK}E+YDB4$L2=SlA+?_xlMzHRi!{~elm>Vn(B(FR4?*F0 zJX)361r0s{VB1eMyCQl9N6cVHBp~Wy1?5&?{6k6Xa6_YYQn$dVO%*b|AbT8^V0b~c z!mEOBpxcRbX}}A`9TkxrMI0+T8|62IlvFWJ3?vM4Krr#t0;)0Ui}=tSC5ZpP>S9<3 z6b_K7x-=oL&4=;AGj5eU%EzW!{CYo2fy3iXG`3s z;SiJMjQ}$#0B=kJjYViv$ZbBej>5qyL1DzrQ^|u$x}V|&X(J0sZROdS^i(iTD7snf z1u-B!2f5?zD3dD&Q3WNMs`c4pN|qlJbLqJ_of>$Lbq0xFj0y=L--yL&G%0A@jmCAXR1o*9lDvjPX2^9c32Ejbug8DAux+F!8B$fy1DW z0y&)BZ9(o(j$Q&Ih(bDKUDHH3A)aD#`ivZr2n|O;0@iCgQ5vOUq(F9sxK#{|mV%R6 z8BPv`!-<8s1_m1dCpNkgUIPj`CRbx~KxeBGdXFMbj+aSr@q`}42#Q@&D`HmU5jF@i ziK!r-4ag9gR!yP**}^12CsT%p>Z{K~XE_|afZ6GAV8c;Yz#H`&fr6I<0^-0x7z@ck z?T<)>PAWbk;3*;Cp{)pSRvBUvot=pC5P?wxzAxf+Kz}Cu0^cd+6Z8%MtCE-+g-~SG zq!Mgg720Btq(WPlUnK+Da++PM@aVaCojhVSyRjhIE7XYW1YpCksfcDUt`sjn76wx; z@Nt1XRSZ1A&QMH7=R%d=hZ4inS?E9+OH3@RpPvacSfMzA>z4shPqE5*|{VbT-AQ$5?0%D4+o$ zz1$V>kr~>EokX{hT{^9ooC>@aZcw7NpfJp^4j7~qWCqgAl+=*Q>_E07JjboWLN%3T z#M0@aP!JLmPO@EXf)-vR3Kx@2AV}zyhSWN|-RQun@%$i)6GVWv43h)I7PV@bhfMGa zO*Bu`!+?UBPr{)HB?9CPa<@~-m6=SyUPi*HIjVp>kV>V;#3nxkNi2c`^oE^AvYJn% z8zMNa+<=QQcyv~(gCbDk!ZMbSB@qf~C{I*Iq5yRi4tUi$RH@74BnK>N8^#1Rc|YJ# zaY7>oEe6XcWLZ%t88!k|nPITw3G$ei5R9VDJc5*>7Lq~b=nsK`l0?;5F~W!fv5cV2 zXA3E`a)a0tPK`i{CL+h6(Hu8Am4?GHX(4FVM$SYN7J#%3{2~@Q#b|xd86}GWDTlWK z*F4jXCC3bWrN_jknEpO=T9+e2HbXZJ#bu6( zG)|x|glFOX4mFL#Q91OKkWbG7W@`@}8fW{L0J>xfjK!c>`!5d-nOs0-070zyiDp$2LMR?ok?K zYGfM3Tp3fRQR4v%38*-q35nU5F;*;M7TWy*KT?{JaXoIe9UyWrp$vu6M2Y}su8L+S zfYwS(3!NbfwJ9oaq1|*0io-@pOlF#bi}Q$yB!h})KwGuYQ;HZxu3Bld31wWn1Juz; z;SexON{vdr9cIL6#WQpUOjsa6?pz%(p(E^#et}$zBJq8IUpE47EFuFWs6XT-g0@!3 zX{3dNFsMUm04W$DUWy9J=JtDR7kC(3CQVc4M0u^QALOl4e z2q*O+|A(*R0j(gO6-L|-x%k$U-1Xb@-9EMvMkp1t6P2A@f4wNNh?d z3+v4aqF)#EfdG(&of-@UK;o26h+#o0k^(yu2nNt;qzIpZCvseLOi<6}MqQAUwMKAQ zv`I)bS)yST2_Ny%e0m`_jE`6)0*SzghkkyNSq_937@te4W^=Vt8UqvuJTf6xj|Igq zaTLtGoEJ97B7O^Om;fQfN*q39bx9~rMDUNn5^(7J7$+?d7Q<{Y zup|mr7B|%)ft)xa zY>Wl9RF#nd1u?RNO{7Icbi{cD78DS<#|hP(uQ}MK~f1855=t)YoQMq+T@VpKAjwea=n}bfM=60 z7zN%JD$xdqC+7(qD78mxw)j|1EQ%Z^`GwG^5`_VnG=WEN2Yzci5AvNr5zh>GfsB?y zqzl=IvmbSe>~6IH3*}80n6sFbg*Kw`B&?Dj1CS*lViQrQJ`lo^4{xe`aQlQozq_;vufCqNT` z0$#_62*AVxPccn+BaLeSCUI9PI2O?MMTDTkWN=}je_16qprGPwHJW&KIZvX}m|b+x zi^D-(FT~NS30jAo9*d}DRv%Vkjbdd$CBZT5!QfR*lz7;s^M2FyuTcNaw0;WTIPuM5IvzU^W#NYXG|L6ns(;U|uBO zAJJZ^-iFY6P|RW_+~EvlOimDx#JD&Ivi;~NQa+N;kU{4@g9@@d91RZ&Q5b0LhG$(Yo5;w*1B)r} zUoz1|xq%mEYI!`a!z$!J6CsI_8u4?y-mos>#rf@QqQOpQq`JsHhQJ)Q=$RU*g^+YK z0bU@0E>;rCiMA4Oc!x|0(G9Ts0u-B%xR_?QJ*ap4>=8n$#;=LdQl)H-p6l_(z`Tno zp0Jx16Vk9DA{j@)P|+fQ4mmMFxm(I0Ndhzs9$at0X95&d?cpeOA$8CimT0X2YKxIV zDmR@*WP z;K!1Aeu>9OiUk#^kem%L9V#L{h~k=1N-;|52W*W6c!47HMG zH>-s)8;l+{4<4`h|b4wYx!Y02!KgQ zI=wn10zXGhVMo!P5R=EJGN`x!TSbwo)i|j2>SQ6Qo#-;gXb^+{k#2?T5OlAbtxma# z5wQT9fl1Cc0RX~i@h}BEh7KAtsA?em6WgRxBj}9dc~GF`aDq`I)y&k3AxUd>Q%zJ% zh#PikobnJu!V-hLEQ(=Pc=f;*V7K~+6ik$rDrVD2o=`L(ka^5190;8IBw>jNF%LpN z!=j{fEa9kEz#)S0G*K)A;Al9YRr&E?Dxk(kg7S7yg78Q(w0e$+jR9O&j7z2Xyb&@J zr*?u7i3H#z337Z4n!a30+8>7qx|ROWo68(rlg3DN7(mz8Lw9%#B9$OD6)y~>N>Fx& zGL;)}fbNJ%FQU4gV8@a4j8@LpYk3Bu4M_HI1P>8{0=iAcvl+qD)c=uSppir%fWb#h zon0sK%aII@&EX=V)nYM|MHcvke6`l*^PolcpoYv!HESax6HbIT$*B?|h#PvSv7ieb z4aP8rpavRVxjvpEXi;;>mOudfON4!!5`!*q_?5smD&>Dx6g%t}`ZYc-5F&Am9wG}i zK?>yQ&03~C2xO-+mQMw+03VeM4Mz&A8nFn#swM*J09ZOwMI=H{)A2&QBILs1Jzj|% z)EEOE8&LXc@CsuT3e|qELghm{K;hPo;l<=UiUEbQNJ(au6G#KOIBQr*;YE#F6ZD7^ z4C<&(sKe{cscb&7?}n@{MkFjH(_Q8W6-AS?F$%ScCG@CuQfRLuv0&UNE0hZ2)zP3O z{6~|=?r@t3px34#@sL{x%Zvfhr-LO`85kC|-boXXfU;F7H8SNMkUk>_0I00SBA$mz zjnSc_HZ@;JqzM^evkk!17NE$K`M4T`Tdlxjpo3H@huzF>0Tv0BH&tqiNvHtmqXiry zWY(lo_-PM{&?2!YB9jEsDkZ2fMrZ^I-Gf0a1TQrJ5i)KVxLm-X1A7^o!%|WiDm(!S>nOdCLh?wMXs**` z2r58j6YpmNg%bu3;sF6Q*{+gtNhqIR58}5(lU*SoMN|MqlG=n}FJDe30|6(+po<{m z`?NkvNDO4BL>@otGXn?~mH~rCV3E|I=Wdqag_01&Hx!?MVO42JE(;=aLopF`1Pcum z)P+zt0U;b(YRE{$dGSuKT&2a>#6k+0ug3#8T+HGF3=HI5Y_L(gy=s(R&Lv_3It&%I zABvi4QmZg(pM}g2(%521vH=vut_N}xuU1X<64c^I0Px!$A^^AW7Oz0AjPNxijwuMz zIS!Oo!=?bYsV-vI8OeB#GQ?3LeMJm2-6{z9OwcnKfbYN%Sdk#Ks^Mr1CJDN*IW&ua zL&k(9$ZINtoefx9Ce9X0rE^(g5jrU4NlZ>T^bNu5Km)I^+b9GN8U%NVOu1iRSLl5K zu|DSTaAh<>3>0h7Xdw3y=>jf;gz1Yiq*@hZ$dLPupcO|=&M-+0BBHRAJYJVW!{$RE zp{1zUF~o%dX<)BRDMk7fC#vg`P3bf;K~5uahL^;o-QG=z&nlkBX}b4@#C>LpI=A9hPja-S&Nek+)?li zfy@?w-9&IQBv?E~mdZDH#5l5)9$d5aaMVwVf^#cz{@gO7{y4 z5j?PoYeH^-V~VUXgUSb2oe>ez-ChnB^jD2Qc%W7AAt+*6!KVfMJeEsFJn^vI5}-x} zexLw?bhpB2cY#WR&}BpG&?uEtD{^5CCYjxY5t&^YrBQ_@g<)6XQq?4&1Oe83l9VV1 z3IZ4i9t@ku$KXKDQyW3du0R-|V2LIO(5*qDGYaaHBFGo3m8lefk^3niRxV}oxH>V- zZIq$;ZX2E>1?xdk14ATy8g#Zn6`N=gseAxY2ztmQ90xppAa2LHV`ecO6%LzXG=?SM zj&Ya*fjtrg!Y7Ft&58ywY813in}8?))R=GzGE1Nix;bW=)nc=14Fo7)TLWPel8Lk! zQ39#Jq}AX}Y_C*lAp?U1GgV2G7z0?kI?9THbP>k_Z={%HLMLAhav%Y3V}@4%fnI)XbBkE zK!eDEJ_jl|xD0P9L!pCaG#l^|nPNJVjzR)RDaLO=!;VSuGf}A~&?qy6EKtkxN-e2M zl+8_yn3-n32n6YnXa!|)%lrnT1_Y@zLc|iYQI>!X@Gnvzs8^A#2D`->fFtoafFK(c zBr9U6d=YS1Aw8-L;Ohi$54=yXYv77Qdc+9=1b#7xM{+T^I;91+ zb_!2p1Eo(60L|Dyh@|5{Qb;OPib-q?T?$5(ftQ<26gkt43qtcek)sh9H8P=yKmf@` zZI}x3CuXeyOsiRnve3zdm{UTNlBq_&Sj5(H@p>$jb8L2zO3foiB{JBvJSe}!NEF2& z6X&rhtrnp;DA31ZR?nYCWeW~ZB#OjJPXur^C^Oqe!G%Bw0@*!6f2gz3(9!3lghDJ( zm?nZGTR;pHzf8U$0##s%ng(n%VV_xx=6Xb7iPNG3r~;mXB7kzM&jyG(oeJagxa|s$ z%qQgO%`|DMGelC_U4AXx(mpFl1HczW0Ss=5VtHm2L8V7|^~yhj;eNN+i8C-%zzm_a z`#^72#!zpgjOixX_>o=p6)=-;^3rJ6#}s1eG#^6VhZV98h;D^j?xv=d0`lS*pk= zMqC`kwe#>*F{_P0QlQ9GIvYf2f!x<#0g20{Z;1qFy`Ku8r6FhDAax{zwZn{1Et>| z22>_Zt_y*#utg4JBr3X8i*w?*9E?~C8n1q;&k0u2T_F0 zWT0rROyB~ugIB@{3L;V#3GyZil_&;c>AtWQuA3R3>QzDWEnVw^UTj#8dyYOIwMez#o2M0i<-p7{48^fJ0Te$J;o{jr0}@6s+*GV7 zECNhOp|=8#Dga7(z&2x)fSRV)r64M>S_RO= zfR;s!Cqnxi7EpC^$aPLBjRVbcphn6eiTKD-QDYJh&+i98H?)?AMp*$V#~=tSe>y8% zu~dSM92jaVqS}yrR7FAsvtSw^81Wv16S(@_S$eDro==@ zGBT7h7-Zsq&j7%GV0Z`x&fK8Y+86$>t4m>t9BRT zM28~4Fo68mtg1?Kw|v&X;&RTabwA4rzq*S~XR}Sy*d_ONwb_z=ckE*l;p(998~+7m z?wQZugeun28FliuzIu7`#w~1v>>B^^n6R(qmxj8#+sw7y&yKzuIOFKbUzjPnSKYrj z^6IcA{KsQh15xJJuEg9L#Wy#7xkdbsA&}vU7hasO3*ND8aBatm|M(O#LY#g`Z9&p7 zRH)B*yr5S1VgKj!!-y&QLaXVd?=s3Mr!A@%>gDhoTzxvkBc z|Bh{~{&^^;PSKR3m228Q{+e-cw50Bvr2m=xbePw)uK!+=AwpBs@~c~ymREmZwD{7Z z)}Ef**2bqd7uD2(#+S4Qyn@DgVk3fW9y{9SM<>?$lK~~ zXaRvk)t!AiPJI1XRetATa9Ut$tBUL%7e4clJ8#fGcP()-EW^t*^$LES5hF8?e5>sH z;_8Mue0{@Lx@({Ar~f8x9b%T#P@y)_y^WBwtoP57%tCG$toVkxWzBGNJ#%J1+MS$F zx9Z%P*jAd^ss23qE#3s31B1Tz&mG#l4svL5|IcTDEUo{`i3W?m{QQ2T`|!_Qegsp4 zl^-QV4ta0o_QhO&`NPET>%8+e|N1tcAS7=RAD;N-%VW=`qScr#L&wiQH-v5cbY|Jy z?rh(J7hQ^P8rL6RpC!t49)D8MHf0G`@@s!ceLHJuWx=?{8}+U9`xYmM{x)8BCr#ke zGk<@3x$MW%3TC^3CCV%7Pj~(OCN8EE8%ZB{rP@Y zqZ_k}##Rf~UyScL_Oolj{k*T-`H z(WK(Y-Zz}n*$K1e{;s~Co)lhw?aF3jTlR_}v(7CfjanD|St2iRoNhx3SIy6CKX{ny z-oa#2!LyvEonqYirD9{%A?y2RE8I^Wt-Jr^+@h9q`#wv#azHwCM*O?s2Rsj#p8L40 zYfnLEIMl1`@&V_&OG~!;-aUGwD064Lo1rH>dAZ}rjiOOSK5`#$b7ZtTMew|tOJscc2f39J^ZA$y`WzLt!eftFueq2zN zvix-R(>>kC=12;x$9SF0hh4Rcd#1;c#*NwcYUI8V$EVKeHMVR=_LTd-d!7F)Gw;i3 z$(IW6laF3C+Pgn(MUOR(k!Yr5?b+_@D)IB8iQi5iUQ)K!@VZ2jAFX$|UfH*%RSDr8 zqjP!DhOD1ele*Txcm;mSMj6Wfyn!fh6}?*?LT+!5mz+3d-{mN?(@d(U0{DEU{88Hl=ZXo#cdlJD>Rl&X?kM%W&)-ypG74%{>@gd}i4|g7NXj zUwyvxmi*{GvT)yANm5_V)c4odu`W9%&3_ki9z1)DI@WM`wYp$znfk!E@6+aQ5e?g{ z+>vsmO>)vzQ)X`2j?t&LF6t}$ad~>1{sT@=tX;T!TjKQXXSUrb1N&jSvgK6suT_Pm zS5`@-FD{SEetce