From 47dc4e64280cebf4a5da73ab0a02056bfa1ce7ff Mon Sep 17 00:00:00 2001 From: Anton Kaliaev Date: Fri, 7 Sep 2018 11:40:16 +0400 Subject: [PATCH] fix a few typos in spec --- docs/spec/abci/abci.md | 2 +- docs/spec/abci/apps.md | 10 +++++----- docs/spec/abci/client-server.md | 2 +- docs/spec/blockchain/state.md | 4 ++-- docs/spec/p2p/peer.md | 2 +- 5 files changed, 10 insertions(+), 10 deletions(-) diff --git a/docs/spec/abci/abci.md b/docs/spec/abci/abci.md index 17d0a1efa..ccf6bf306 100644 --- a/docs/spec/abci/abci.md +++ b/docs/spec/abci/abci.md @@ -12,7 +12,7 @@ ABCI methods are split across 3 separate ABCI *connections*: - `Info Connection: Info, SetOption, Query` The `Consensus Connection` is driven by a consensus protocol and is responsible -for block exection. +for block execution. The `Mempool Connection` is for validating new transactions, before they're shared or included in a block. The `Info Connection` is for initialization and for queries from the user. diff --git a/docs/spec/abci/apps.md b/docs/spec/abci/apps.md index 84cd34311..2fbfa30c6 100644 --- a/docs/spec/abci/apps.md +++ b/docs/spec/abci/apps.md @@ -18,7 +18,7 @@ Here we cover the following components of ABCI applications: Since Tendermint maintains multiple concurrent ABCI connections, it is typical for an application to maintain a distinct state for each, and for the states to -be sycnronized during `Commit`. +be synchronized during `Commit`. ### Commit @@ -41,7 +41,7 @@ the working state for block execution. It should be updated by the calls to disk as the "latest committed state" during `Commit`. Updates made to the DeliverTxState by each method call must be readable by each subsequent method - -ie. the updates are linearizeable. +ie. the updates are linearizable. ### Mempool Connection @@ -76,7 +76,7 @@ block full of invalid transactions if it wants. The Mempool Connection should maintain a `QueryState` for answering queries from the user, and for initialization when Tendermint first starts up. It should always contain the latest committed state associated with the -latest commited block. +latest committed block. QueryState should be set to the latest `DeliverTxState` at the end of every `Commit`, ie. after the full block has been processed and the state committed to disk. @@ -217,7 +217,7 @@ storeBlockHeight = height of the last block Tendermint saw a commit for stateBlockHeight = height of the last block for which Tendermint completed all block processing and saved all ABCI results to disk appBlockHeight = height of the last block for which ABCI app succesfully - completely Commit + completed Commit ``` Note we always have `storeBlockHeight >= stateBlockHeight` and `storeBlockHeight >= appBlockHeight` @@ -225,7 +225,7 @@ Note also we never call Commit on an ABCI app twice for the same height. The procedure is as follows. -First, some simeple start conditions: +First, some simple start conditions: If `appBlockHeight == 0`, then call InitChain. diff --git a/docs/spec/abci/client-server.md b/docs/spec/abci/client-server.md index 1923b5e08..f88ac6c4c 100644 --- a/docs/spec/abci/client-server.md +++ b/docs/spec/abci/client-server.md @@ -88,7 +88,7 @@ The main ABCI server (ie. non-GRPC) provides ordered asynchronous messages. This is useful for DeliverTx and CheckTx, since it allows Tendermint to forward transactions to the app before it's finished processing previous ones. -Thus, DeliverTx and CheckTx messages are sent asycnhronously, while all other +Thus, DeliverTx and CheckTx messages are sent asynchronously, while all other messages are sent synchronously. ## Client diff --git a/docs/spec/blockchain/state.md b/docs/spec/blockchain/state.md index 3bad68bd1..e9da53b50 100644 --- a/docs/spec/blockchain/state.md +++ b/docs/spec/blockchain/state.md @@ -104,11 +104,11 @@ type EvidenceParams struct { #### BlockSize -The total size of a block is limitted in bytes by the `ConsensusParams.BlockSize.MaxBytes`. +The total size of a block is limited in bytes by the `ConsensusParams.BlockSize.MaxBytes`. Proposed blocks must be less than this size, and will be considered invalid otherwise. -Blocks should additionally be limitted by the amount of "gas" consumed by the +Blocks should additionally be limited by the amount of "gas" consumed by the transactions in the block, though this is not yet implemented. #### TxSize diff --git a/docs/spec/p2p/peer.md b/docs/spec/p2p/peer.md index f9d2d8bce..116fec4f7 100644 --- a/docs/spec/p2p/peer.md +++ b/docs/spec/p2p/peer.md @@ -40,7 +40,7 @@ It goes as follows: - get 96 bytes of output from hkdf-sha256 - if we had the smaller ephemeral pubkey, use the first 32 bytes for the key for receiving, the second 32 bytes for sending; else the opposite - use the last 32 bytes of output for the challenge -- use a seperate nonce for receiving and sending. Both nonces start at 0, and should support the full 96 bit nonce range +- use a separate nonce for receiving and sending. Both nonces start at 0, and should support the full 96 bit nonce range - all communications from now on are encrypted in 1024 byte frames, using the respective secret and nonce. Each nonce is incremented by one after each use. - we now have an encrypted channel, but still need to authenticate