mirrors/tendermint
1
0
Fork 0
mirror of https://github.com/tendermint/tendermint.git synced 2026-01-09 22:47:24 +00:00
Code Issues Packages Projects Releases Wiki Activity

Addressed comments from @lklimek

Browse Source
This commit is contained in:
Sergio Mena
2021-12-22 17:06:26 +01:00
parent ddb1eb27c9
commit 0d610258f5
2 changed files with 36 additions and 31 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
spec/abci++/abci++_basic_concepts_002_draft.md
View File

@@ -84,7 +84,7 @@ it is already included.
### `DeliverTxResult` (as part of `FinalizeBlock`)
The `DeliverTxResult` type delivers transactions from Tendermint to the Application.
When Tendermint receives a `ReponseFinalizeBlock` containing a `DeliverTxResult`
When Tendermint receives a `ResponseFinalizeBlock` containing a `DeliverTxResult`
with a non-zero `Code`, the response code is logged.
The transaction was already included in a block, so the `Code` does not influence
Tendermint consensus.

65
spec/abci++/abci++_methods_002_draft.md
View File

@@ -304,7 +304,7 @@ From the App's perspective, they'll probably skip ProcessProposal
|-------------------------|--------------------------------------------------|---------------------------------------------------------------------------------------------|--------------|
| modified_tx | bool | The Application sets it to true to denote it made changes to transactions | 1 |
| tx | repeated [TransactionRecord](#transactionrecord) | Possibly modified list of transactions that have been picked as part of the proposed block. | 2 |
| data | bytes | The Merkle root hash of the application state. | 3 |
| app_hash | bytes | The Merkle root hash of the application state. | 3 |
| tx_result | repeated [DeliverTxResult](#delivertxresult) | List of structures containing the data resulting from executing the transactions | 4 |
| validator_updates | repeated [ValidatorUpdate](#validatorupdate) | Changes to validator set (set voting power to 0 to remove). | 5 |
| consensus_param_updates | [ConsensusParams](#consensusparams) | Changes to consensus-critical gas, size, and other parameters. | 6 |
@@ -319,7 +319,7 @@ From the App's perspective, they'll probably skip ProcessProposal
them in `ResponsePrepareProposal`. In that case, `ResponsePrepareProposal.modified_tx` is set to true.
* If `ResponsePrepareProposal.modified_tx` is false, then Tendermint will ignore the contents of
`ResponsePrepareProposal.tx`.
* In same-block execution mode, the Application must provide values for `ResponsePrepareProposal.data`,
* In same-block execution mode, the Application must provide values for `ResponsePrepareProposal.app_hash`,
`ResponsePrepareProposal.tx_result`, `ResponsePrepareProposal.validator_updates`, and
`ResponsePrepareProposal.consensus_param_updates`, as a result of executing the block.
* The values for `ResponsePrepareProposal.validator_updates`, or
@@ -380,10 +380,10 @@ and _p_'s _validValue_ is `nil`:
2. _p_'s Tendermint calls `RequestPrepareProposal` with the newly generated block.
The call is synchronous: Tendermint's execution will block until the Application returns from the call.
3. The Application checks the block (header, transactions, commit info, evidences). Besides,
* in same-block execution mode, the Application can (and should) provide `ResponsePrepareProposal.data`,
* in same-block execution mode, the Application can (and should) provide `ResponsePrepareProposal.app_hash`,
`ResponsePrepareProposal.validator_updates`, or
`ResponsePrepareProposal.consensus_param_updates`.
* in "next-block execution" mode, _p_'s Tendermint will ignore the values for `ResponsePrepareProposal.data`,
* in "next-block execution" mode, _p_'s Tendermint will ignore the values for `ResponsePrepareProposal.app_hash`,
`ResponsePrepareProposal.validator_updates`, and `ResponsePrepareProposal.consensus_param_updates`.
* in both modes, the Application can manipulate transactions
* leave transactions untouched - `TxAction = UNMODIFIED`
@@ -427,8 +427,14 @@ Note that, if _p_ has a non-`nil` _validValue_, Tendermint will use it as propos
* The Application may fully execute the block as though it was handling `RequestFinalizeBlock`.
However, any resulting state changes must be kept as _canditade state_,
and the Application should be ready to backtrack/discard it in case the decided block is different.
* The header contains the height, timestamp, and more - it exactly matches the
Tendermint block header.
* The header exactly matches the Tendermint header of the proposed block.
* In next-block execution mode, the header hashes _AppHash_, _LastResultHash_, _ValidatorHash_,
and _ConsensusHash_ refer to the **last committed block** (data was provided by the last call to
`ResponseFinalizeBlock`).
* In same-block execution mode, the header hashes _AppHash_, _LastResultHash_, _ValidatorHash_,
and _ConsensusHash_ refer to the **same** block being passed in the `Request*` call to this
method (data was provided by the call to `ResponsePrepareProposal` at the current height that
resulted in the block being passed in the `Request*` call to this method)
* If `ResponseProcessProposal.accept` is _false_, Tendermint assumes the proposal received
is not valid.
* The implementation of `ProcessProposal` MUST be deterministic. Moreover, the value of
@@ -466,10 +472,10 @@ When a validator _p_ enters Tendermint consensus round _r_, height _h_, in which
* **Request**:
| Name | Type | Description | Field Number |
|--------|-------|-----------------------------------------------------------------------|--------------|
| hash | bytes | The hash of the proposed block that the vote extension is to refer to | 1 |
| height | int64 | Height of the proposed block (for sanity check). | 2 |
| Name | Type | Description | Field Number |
|--------|-------|------------------------------------------------------------------------------|--------------|
| hash | bytes | The header hash of the proposed block that the vote extension is to refer to | 1 |
| height | int64 | Height of the proposed block (for sanity check). | 2 |
* **Response**:
@@ -510,7 +516,7 @@ In the cases when _p_'s Tendermint is to broadcast `precommit nil` messages (eit
| Name | Type | Description | Field Number |
|-----------|-------|------------------------------------------------------------------------------------------|--------------|
| extension | bytes | Sender Application's vote extension to be validated | 1 |
| hash | bytes | The hash of the propsed block that the vote extension refers to | 2 |
| hash | bytes | The header hash of the propsed block that the vote extension refers to | 2 |
| address | bytes | [Address](../core/data_structures.md#address) of the validator that signed the extension | 3 |
| height | int64 | Height of the block (for sanity check). | 4 |
@@ -569,46 +575,45 @@ from this condition, but not sure), and _p_ receives a Precommit message for rou
| tx_result | repeated [DeliverTxResult](#delivertxresult) | List of structures containing the data resulting from executing the transactions | 2 |
| validator_updates | repeated [ValidatorUpdate](#validatorupdate) | Changes to validator set (set voting power to 0 to remove). | 3 |
| consensus_param_updates | [ConsensusParams](#consensusparams) | Changes to consensus-critical gas, size, and other parameters. | 4 |
| app_data | bytes | The Merkle root hash of the application state. | 6 |
| app_hash | bytes | The Merkle root hash of the application state. | 6 |
| retain_height | int64 | Blocks below this height may be removed. Defaults to `0` (retain all). | 7 |
* **Usage**:
* Contains a newly decided block.
* This method is equivalent to the call sequence `BeginBlock`, [`DeliverTx`],
`EndBlock`, `Commit` in the previous version of ABCI.
* The header contains the height, timestamp, and more - it exactly matches the
Tendermint block header.
* The header exactly matches the Tendermint header of the proposed block.
* The Application can use `RequestFinalizeBlock.last_commit_info` and `RequestFinalizeBlock.byzantine_validators`
to determine rewards and punishments for the validators.
* The application must execute the transactions in full, in the order they appear in `RequestFinalizeBlock.tx`,
before returning control to Tendermint. Alternatively, it can commit the candidate state corresponding to the same block
previously executed via `PrepareProposal` or `ProcessProposal`.
* `ResponseFinalizeBlock.tx_result[i].Code == 0` only if the _i_-th transaction is fully valid.
* In next-block execution mode, the Application must provide values for `ResponseFinalizeBlock.app_data`,
* In next-block execution mode, the Application must provide values for `ResponseFinalizeBlock.app_hash`,
`ResponseFinalizeBlock.tx_result`, `ResponseFinalizeBlock.validator_updates`, and
`ResponsePrepareProposal.consensus_param_updates` as a result of executing the block.
* The values for `ResponseFinalizeBlock.validator_updates`, or
`ResponseFinalizeBlock.consensus_param_updates` may be empty. In this case, Tendermint will keep
the current values.
* `ResponseFinalizeBlock.validator_updates`, triggered by block `H`, affect validation
for blocks `H+1`, `H+2`, and `H+3`. Heights following a validator update are affected in the following way:
* `H+1`: `NextValidatorsHash` includes the new `validator_updates` value.
* `H+2`: The validator set change takes effect and `ValidatorsHash` is updated.
* `H+3`: `last_commit_info` is changed to include the altered validator set.
* `ResponseFinalizeBlock.consensus_param_updates` returned for block `H` apply to the consensus
params for block `H+1`. For more information on the consensus parameters,
see the [application spec entry on consensus parameters](../abci/apps.md#consensus-parameters).
* In same-block execution mode, Tendermint will ignore values for `ResponseFinalizeBlock.app_data`,
* The values for `ResponseFinalizeBlock.validator_updates`, or
`ResponseFinalizeBlock.consensus_param_updates` may be empty. In this case, Tendermint will keep
the current values.
* `ResponseFinalizeBlock.validator_updates`, triggered by block `H`, affect validation
for blocks `H+1`, `H+2`, and `H+3`. Heights following a validator update are affected in the following way:
* `H+1`: `NextValidatorsHash` includes the new `validator_updates` value.
* `H+2`: The validator set change takes effect and `ValidatorsHash` is updated.
* `H+3`: `last_commit_info` is changed to include the altered validator set.
* `ResponseFinalizeBlock.consensus_param_updates` returned for block `H` apply to the consensus
params for block `H+1`. For more information on the consensus parameters,
see the [application spec entry on consensus parameters](../abci/apps.md#consensus-parameters).
* In same-block execution mode, Tendermint will ignore values for `ResponseFinalizeBlock.app_hash`,
`ResponseFinalizeBlock.tx_result`, `ResponseFinalizeBlock.validator_updates`, and
`ResponsePrepareProposal.consensus_param_updates`, as those data have been provided by `PrepareProposal`.
* Application is expected to persist its state at the end of this call, before calling `ResponseFinalizeBlock`.
* `ResponseFinalizeBlock.app_data` contains an (optional) Merkle root hash of the application state.
* `ResponseFinalizeBlock.app_data` is included
* `ResponseFinalizeBlock.app_hash` contains an (optional) Merkle root hash of the application state.
* `ResponseFinalizeBlock.app_hash` is included
* [in next-block execution mode] as the `Header.AppHash` in the next block.
* [in same-block execution mode] as the `Header.AppHash` in the current block. In this case,
`PrepareProposal` is required to fully execute the block and set the App hash before
returning the proposed block to Tendermint.
* `ResponseFinalizeBlock.app_data` may also be empty or hard-coded, but MUST be
* `ResponseFinalizeBlock.app_hash` may also be empty or hard-coded, but MUST be
**deterministic** - it must not be a function of anything that did not come from the parameters
of `RequestFinalizeBlock` and the previous committed state.
* Later calls to `Query` can return proofs about the application state anchored