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

Typos in spec (#8939)

Browse Source
This commit is contained in:
Sergio Mena
2022-07-06 00:02:29 +02:00
committed by GitHub
parent 3cde9a0bbc
commit 2b5329ae47
2 changed files with 5 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
spec/abci++/abci++_basic_concepts.md
View File

@@ -32,7 +32,7 @@ now better understood than when ABCI was first written. For example, many ideas
scalability can be boiled down to "make the block proposers do work, so the network does not have
to". This includes optimizations such as transaction level signature aggregation, state transition
proofs, etc. Furthermore, many new security properties cannot be achieved in the current paradigm,
as the Application cannot require validators to do more than execute the transactions contained in
as the Application cannot require validators to do more than executing the transactions contained in
finalized blocks. This includes features such as threshold cryptography, and guaranteed IBC
connection attempts.
@@ -312,7 +312,7 @@ Sources of non-determinism in applications may include:
See [#56](https://github.com/tendermint/abci/issues/56) for the original discussion.
Note that some methods (`Query, CheckTx, FinalizeBlock`) return non-deterministic data in the form
Note that some methods (`Query, FinalizeBlock`) return non-deterministic data in the form
of `Info` and `Log` fields. The `Log` is intended for the literal output from the Application's
logger, while the `Info` is any additional info that should be returned. These are the only fields
that are not included in block header computations, so we don't need agreement

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

@@ -669,7 +669,7 @@ message for round _r_, height _h_ from validator _q_ (_q_ ≠ _p_):
to determine rewards and punishments for the validators.
* The Application executes the transactions in `RequestFinalizeBlock.txs` deterministically,
according to the rules set up by the Application, before returning control to Tendermint.
Alternatively, it can commit the candidate state corresponding to the same block previously
Alternatively, it can apply the candidate state corresponding to the same block previously
executed via `PrepareProposal` or `ProcessProposal`.
* `ResponseFinalizeBlock.tx_results[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`,
@@ -830,8 +830,8 @@ Most of the data structures used in ABCI are shared [common data structures](../
| height | uint64 | The height at which the snapshot was taken (after commit). | 1 |
| format | uint32 | An application-specific snapshot format, allowing applications to version their snapshot data format and make backwards-incompatible changes. Tendermint does not interpret this. | 2 |
| chunks | uint32 | The number of chunks in the snapshot. Must be at least 1 (even if empty). | 3 |
| hash | bytes | TAn arbitrary snapshot hash. Must be equal only for identical snapshots across nodes. Tendermint does not interpret the hash, it only compares them. | 3 |
| metadata | bytes | Arbitrary application metadata, for example chunk hashes or other verification data. | 3 |
| hash | bytes | An arbitrary snapshot hash. Must be equal only for identical snapshots across nodes. Tendermint does not interpret the hash, it only compares them. | 4 |
| metadata | bytes | Arbitrary application metadata, for example chunk hashes or other verification data. | 5 |
* **Usage**:
* Used for state sync snapshots, see the [state sync section](../p2p/messages/state-sync.md) for details.