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

Update spec/abci++/abci++_app_requirements_002_draft.md spec/abci++/abci++_basic_concepts_002_draft.md

Browse Source 
Co-authored-by: William Banfield <4561443+williambanfield@users.noreply.github.com>
This commit is contained in:
Sergio Mena
2021-12-20 14:36:36 +01:00
parent 383d6b1117
commit 7bbbba9acf
2 changed files with 4 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -67,8 +67,8 @@ of `ProcessProposal`. As a general rule `ProcessProposal` _should_ always accept
According to the Tendermint algorithm, a correct process can broadcast at most one precommit message in round $r$, height $h$.
Since, as stated in the [Description](#description) section, `ResponseExtendVote` is only called when Tendermint
is about to broadcast a non-`nil` precommit message, a correct process can only produce one vote extension in round $r$, height $h$.
Let $e^r_p$ the vote extension that the Application of a correct process $p$ returns via `ResponseExtendVote` in round $r$, height $h$.
Let $w^r_p$ the proposed block that $p$'s Tendermint passes to the Application via `RequestExtendVote` in round $r$, height $h$.
Let $e^r_p$ be the vote extension that the Application of a correct process $p$ returns via `ResponseExtendVote` in round $r$, height $h$.
Let $w^r_p$ be the proposed block that $p$'s Tendermint passes to the Application via `RequestExtendVote` in round $r$, height $h$.
* Requirement 6 [`ExtendVote`, `VerifyVoteExtension`, coherence]: For any two correct processes $p$ and $q$, if $q$ receives $e^r_p$
from $p$ in height $h$, $q$'s Application returns Accept in `ResponseVerifyVoteExtension`.

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

@@ -215,7 +215,7 @@ The Application may also choose not to include any vote extension.
When another process receives a precommit message with and vote extension, it calls
method `VerifyVoteExtension` so that the application can validate the data received.
If the validation fails, the precommit message will be deemed invalid and ignored
by Tendermint. This has strong implications on Tendermint's liveness.
by Tendermint. This has negative impact on Tendermint's liveness, i.e., if repeatedly vote extensions by correct validators cannot be verified by correct validators, Tendermint may not be able to finalize a block even if sufficiently many (+2/3) of the validators send precommit votes for that block. Thus, `VerifyVoteExtension` should only be used with special care.
As a general rule, an Application that detects an invalid vote extension SHOULD
accept it in `ResponseVerifyVoteExtension` and ignore it in its own logic.
@@ -261,7 +261,7 @@ Sources of non-determinism in applications may include:
* Library version changes
* Race conditions
* Floating point numbers
* JSON serialization
* JSON or protobuf serialization
* Iterating through hash-tables/maps/dictionaries
* External Sources
* Filesystem