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

Addressed outstanding comments

Browse Source
This commit is contained in:
Sergio Mena
2022-01-12 14:35:45 +01:00
parent af8a1a2ce3
commit f4e1039830
3 changed files with 21 additions and 18 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
spec/abci++/abci++_app_requirements_002_draft.md
View File

@@ -31,7 +31,11 @@ compute various hashes in the block header that will finally be part of the prop
mode, $p$'s Application does not provide values for the following parameters in `ResponsePrepareProposal`:
_AppHash_, _TxResults_, _ConsensusParams_, _ValidatorUpdates_.
In practical terms, Requirement 2 implies that Tendermint will ignore those parameters in `ResponsePrepareProposal`.
In practical terms, Requirements 1 and 2 imply that Tendermint will (a) panic if the Application is in
same-block execution mode and _does not_ provide values for
_AppHash_, _TxResults_, _ConsensusParams_, and _ValidatorUpdates_, or
(b) log an error if the Application is in next-block execution mode and _does_ provide values for
_AppHash_, _TxResults_, _ConsensusParams_, or _ValidatorUpdates_ (the values provided will be ignored).
* Requirement 3 [`PrepareProposal`, `ProcessProposal`, coherence]: For any two correct processes $p$ and $q$,
if $q$'s Tendermint calls `RequestProcessProposal` on $v'_p$,

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

@@ -48,7 +48,7 @@ More details on managing state across connections can be found in the section on
## Errors
The `Query`, and `CheckTx` methods include a `Code` field in their `Response*`.
The `Code` field is also included in type `DeliverTxResult`, used by
The `Code` field is also included in type `TxResult`, used by
method `FinalizeBlock`'s `Response*`.
Field `Code` is meant to contain an application-specific response code.
A response code of `0` indicates no error. Any other response code
@@ -65,7 +65,7 @@ of these methods, the Application must crash to ensure that the error is safely
handled by an operator.
Method `FinalizeBlock` is a special case. It contains a number of
`Code` and `Codespace` fields as part of type `DeliverTxResult`. Each of
`Code` and `Codespace` fields as part of type `TxResult`. Each of
these codes reports errors related to the transaction it is attached to.
However, `FinalizeBlock` does not return errors at the top level, so the
same considerations on critical issues made for `Echo`, `Info`, and
@@ -81,10 +81,10 @@ When Tendermint receives a `ResponseCheckTx` with a non-zero `Code`, the associa
transaction will not be added to Tendermint's mempool or it will be removed if
it is already included.
### `DeliverTxResult` (as part of `FinalizeBlock`)
### `TxResult` (as part of `FinalizeBlock`)
The `DeliverTxResult` type delivers transactions from Tendermint to the Application.
When Tendermint receives a `ResponseFinalizeBlock` containing a `DeliverTxResult`
The `TxResult` type delivers transactions from Tendermint to the Application.
When Tendermint receives a `ResponseFinalizeBlock` containing a `TxResult`
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.

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

@@ -305,7 +305,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 |
| 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 |
| tx_result | repeated [TxResult](#txresult) | 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 |
@@ -572,7 +572,7 @@ from this condition, but not sure), and _p_ receives a Precommit message for rou
| Name | Type | Description | Field Number |
|-------------------------|-------------------------------------------------------------|----------------------------------------------------------------------------------|--------------|
| block_events | repeated [Event](abci++_basic_concepts_002_draft.md#events) | Type & Key-Value events for indexing | 1 |
| tx_result | repeated [DeliverTxResult](#delivertxresult) | List of structures containing the data resulting from executing the transactions | 2 |
| tx_result | repeated [TxResult](#txresult) | 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_hash | bytes | The Merkle root hash of the application state. | 6 |
@@ -591,7 +591,7 @@ from this condition, but not sure), and _p_ receives a Precommit message for rou
* `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_hash`,
`ResponseFinalizeBlock.tx_result`, `ResponseFinalizeBlock.validator_updates`, and
`ResponsePrepareProposal.consensus_param_updates` as a result of executing the block.
`ResponseFinalizeBlock.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.
@@ -603,9 +603,9 @@ from this condition, but not sure), and _p_ receives a Precommit message for rou
* `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`.
* In same-block execution mode, Tendermint will log an error and 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_hash` contains an (optional) Merkle root hash of the application state.
* `ResponseFinalizeBlock.app_hash` is included
@@ -618,11 +618,10 @@ from this condition, but not sure), and _p_ receives a Precommit message for rou
of `RequestFinalizeBlock` and the previous committed state.
* Later calls to `Query` can return proofs about the application state anchored
in this Merkle root hash.
* Use `retain_height` with caution! If all nodes in the network remove historical
blocks then this data is permanently lost, and no new nodes will be able to
join the network and bootstrap. Historical blocks may also be required for
other purposes, e.g. auditing, replay of non-persisted heights, light client
verification, and so on.
* Use `ResponseFinalizeBlock.retain_height` with caution! If all nodes in the network remove historical
blocks then this data is permanently lost, and no new nodes will be able to join the network and
bootstrap. Historical blocks may also be required for other purposes, e.g. auditing, replay of
non-persisted heights, light client verification, and so on.
* Just as `ProcessProposal`, the implementation of `FinalizeBlock` MUST be deterministic, since it is
making the Application's state evolve in the context of state machine replication.
* Currently, Tendermint will fill up all fields in `RequestFinalizeBlock`, even if they were
@@ -780,7 +779,7 @@ Most of the data structures used in ABCI are shared [common data structures](../
## Data types introduced in ABCI++
### DeliverTxResult
### TxResult
* **Fields**: