Merge pull request #2356 from tendermint/master
Merge master back to develop
This commit is contained in:
commit
83a7c04bce
|
@ -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
|
||||
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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