diff --git a/UPGRADING.md b/UPGRADING.md index 66a78295e..16e397b22 100644 --- a/UPGRADING.md +++ b/UPGRADING.md @@ -53,7 +53,11 @@ the `ValidatorUpdate` type, which contains just the `PubKey`. Validator set updates returned in ResponseEndBlock for height `H` used to take effect immediately at height `H+1`. Now they will be delayed one block, to take effect at height `H+2`. Note this means that the change will be seen by the ABCI -app in the `RequestBeginBlock.LastCommitInfo` at block `H+3`. +app in the `RequestBeginBlock.LastCommitInfo` at block `H+3`. Apps were already +required to maintain a map from validator addresses to pubkeys since v0.23 (when +pubkeys were removed from RequestBeginBlock), but now they may need to track +multiple validator sets at once to accomodate this delay. + ### Block Size diff --git a/docs/spec/abci/abci.md b/docs/spec/abci/abci.md index 17d0a1efa..b4314e3e1 100644 --- a/docs/spec/abci/abci.md +++ b/docs/spec/abci/abci.md @@ -1,4 +1,4 @@ -# ABCI Methods and Types +# Methods and Types ## Overview @@ -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..92a4f49d5 100644 --- a/docs/spec/abci/apps.md +++ b/docs/spec/abci/apps.md @@ -1,4 +1,4 @@ -# ABCI Applications +# Applications Please ensure you've first read the spec for [ABCI Methods and Types](abci.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 @@ -73,10 +73,11 @@ block full of invalid transactions if it wants. ### Info Connection -The Mempool Connection should maintain a `QueryState` for answering queries from the user, -and for initialization when Tendermint first starts up. +The Info Connection should maintain a `QueryState` for answering queries from the user, +and for initialization when Tendermint first starts up (both described further +below). 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. @@ -97,7 +98,7 @@ though see issues [#2310](https://github.com/tendermint/tendermint/issues/2310) for how this may change. -## CheckTx +### CheckTx If `Code != 0`, it will be rejected from the mempool and hence not broadcasted to other peers and not included in a proposal block. @@ -108,7 +109,7 @@ semantically meaningless to Tendermint. `Tags` include any tags for the execution, though since the transaction has not been committed yet, they are effectively ignored by Tendermint. -## DeliverTx +### DeliverTx If DeliverTx returns `Code != 0`, the transaction will be considered invalid, though it is still included in the block. @@ -217,7 +218,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 +226,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..822bfd1fc 100644 --- a/docs/spec/abci/client-server.md +++ b/docs/spec/abci/client-server.md @@ -1,4 +1,4 @@ -# ABCI Client and Server +# Client and Server This section is for those looking to implement their own ABCI Server, perhaps in a new programming language. @@ -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/blockchain.md b/docs/spec/blockchain/blockchain.md index c24d2e10a..795a22926 100644 --- a/docs/spec/blockchain/blockchain.md +++ b/docs/spec/blockchain/blockchain.md @@ -400,7 +400,7 @@ must be greater than 2/3 of the total voting power of the complete validator set ### Vote A vote is a signed message broadcast in the consensus for a particular block at a particular height and round. -When stored in the blockchain or propagated over the network, votes are encoded in TMBIN. +When stored in the blockchain or propagated over the network, votes are encoded in Amino. For signing, votes are encoded in JSON, and the ChainID is included, in the form of the `CanonicalSignBytes`. We define a method `Verify` that returns `true` if the signature verifies against the pubkey for the CanonicalSignBytes 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