From 2b5329ae47a092941c18b3663ebedf0d387abce7 Mon Sep 17 00:00:00 2001 From: Sergio Mena Date: Wed, 6 Jul 2022 00:02:29 +0200 Subject: [PATCH] Typos in spec (#8939) --- spec/abci++/abci++_basic_concepts.md | 4 ++-- spec/abci++/abci++_methods.md | 6 +++--- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/spec/abci++/abci++_basic_concepts.md b/spec/abci++/abci++_basic_concepts.md index a467b623e..9b9167865 100644 --- a/spec/abci++/abci++_basic_concepts.md +++ b/spec/abci++/abci++_basic_concepts.md @@ -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 diff --git a/spec/abci++/abci++_methods.md b/spec/abci++/abci++_methods.md index 9d33652dd..4d1e47bef 100644 --- a/spec/abci++/abci++_methods.md +++ b/spec/abci++/abci++_methods.md @@ -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.