From ba3448a44098cd5775e13d958cd4c8bd5d637d36 Mon Sep 17 00:00:00 2001 From: Sukey <35202440+sukey2008@users.noreply.github.com> Date: Fri, 8 Dec 2023 11:22:22 +0100 Subject: [PATCH] chore: fix several minor typos (#18660) --- docs/spec/SPEC_MODULE.md | 2 +- docs/spec/SPEC_STANDARD.md | 2 +- docs/spec/store/README.md | 6 +++--- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/spec/SPEC_MODULE.md b/docs/spec/SPEC_MODULE.md index 1b5e5d5dc65f..275d17a5c42e 100644 --- a/docs/spec/SPEC_MODULE.md +++ b/docs/spec/SPEC_MODULE.md @@ -24,7 +24,7 @@ specifications for modules. The following list is nonbinding and all sections ar * `# {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` - specify and describe structures expected to be 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 diff --git a/docs/spec/SPEC_STANDARD.md b/docs/spec/SPEC_STANDARD.md index 3608b3654c0b..f6dc07b852f5 100644 --- a/docs/spec/SPEC_STANDARD.md +++ b/docs/spec/SPEC_STANDARD.md @@ -42,7 +42,7 @@ This section should include an assumptions sub-section if any, the mandatory pro This is the main section of the document, and should contain protocol documentation, design rationale, required references, and technical details where appropriate. The section may have any or all of the following sub-sections, as appropriate to the particular specification. The API sub-section is especially encouraged when appropriate. -* *API* - A detailed description of the features's API. +* *API* - A detailed description of the feature's API. * *Technical Details* - All technical details including syntax, diagrams, semantics, protocols, data structures, algorithms, and pseudocode as appropriate. The technical specification should be detailed enough such that separate correct implementations of the specification without knowledge of each other are compatible. * *Backwards Compatibility* - A discussion of compatibility (or lack thereof) with previous feature or protocol versions. * *Known Issues* - A list of known issues. This sub-section is specially important for specifications of already in-use features. diff --git a/docs/spec/store/README.md b/docs/spec/store/README.md index c53d69c67d03..d9d35e7d465c 100644 --- a/docs/spec/store/README.md +++ b/docs/spec/store/README.md @@ -29,7 +29,7 @@ with, which also provides the basis of most state storage and commitment operati 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 +Typically, each module has its 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`. @@ -42,7 +42,7 @@ until `Commit()` is called on the `CommitMultiStore`. ### `CommitMultiStore` -The `CommitMultiStore` interface exposes the the top-level interface that is used +The `CommitMultiStore` interface exposes 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: @@ -53,7 +53,7 @@ it supports the following high-level primitives: * 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 +* Provides the ability 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