fluencelabs/tendermint
1
0
Fork 0
mirror of https://github.com/fluencelabs/tendermint synced 2025-06-13 21:31:23 +00:00
Code Issues Projects Releases Wiki Activity

fix a few typos in spec

Browse Source
This commit is contained in:
Anton Kaliaev
2018-09-07 11:40:16 +04:00
parent 22445a5029
commit 47dc4e6428
5 changed files with 10 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/spec/abci/abci.md
View File

@ -12,7 +12,7 @@ ABCI methods are split across 3 separate ABCI *connections*:
- `Info Connection: Info, SetOption, Query` - `Info Connection: Info, SetOption, Query`
The `Consensus Connection` is driven by a consensus protocol and is responsible 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 The `Mempool Connection` is for validating new transactions, before they're
shared or included in a block. shared or included in a block.
The `Info Connection` is for initialization and for queries from the user. The `Info Connection` is for initialization and for queries from the user.

10
docs/spec/abci/apps.md
View File

@ -18,7 +18,7 @@ Here we cover the following components of ABCI applications:
Since Tendermint maintains multiple concurrent ABCI connections, it is typical 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 for an application to maintain a distinct state for each, and for the states to
be sycnronized during `Commit`. be synchronized during `Commit`.
### 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`. disk as the "latest committed state" during `Commit`.
Updates made to the DeliverTxState by each method call must be readable by each subsequent method - 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 ### 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, The Mempool Connection should maintain a `QueryState` for answering queries from the user,
and for initialization when Tendermint first starts up. and for initialization when Tendermint first starts up.
It should always contain the latest committed state associated with the 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`, 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. 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 stateBlockHeight = height of the last block for which Tendermint completed all
block processing and saved all ABCI results to disk block processing and saved all ABCI results to disk
appBlockHeight = height of the last block for which ABCI app succesfully appBlockHeight = height of the last block for which ABCI app succesfully
completely Commit completed Commit
``` ```
Note we always have `storeBlockHeight >= stateBlockHeight` and `storeBlockHeight >= appBlockHeight` 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. The procedure is as follows.
First, some simeple start conditions: First, some simple start conditions:
If `appBlockHeight == 0`, then call InitChain. If `appBlockHeight == 0`, then call InitChain.

2
docs/spec/abci/client-server.md
View File

@ -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 This is useful for DeliverTx and CheckTx, since it allows Tendermint to forward
transactions to the app before it's finished processing previous ones. 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. messages are sent synchronously.
## Client ## Client

4
docs/spec/blockchain/state.md
View File

@ -104,11 +104,11 @@ type EvidenceParams struct {
#### BlockSize #### 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 Proposed blocks must be less than this size, and will be considered invalid
otherwise. 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. transactions in the block, though this is not yet implemented.
#### TxSize #### TxSize

2
docs/spec/p2p/peer.md
View File

@ -40,7 +40,7 @@ It goes as follows:
- get 96 bytes of output from hkdf-sha256 - 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 - 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 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, - 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. 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 - we now have an encrypted channel, but still need to authenticate