fix a few typos in spec
This commit is contained in:
parent
22445a5029
commit
47dc4e6428
|
@ -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.
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue