chore: update abci++ spec

spec/abci++/abci++_app_requirements_002_draft.md

@@ -20,22 +20,22 @@ Process $p$'s prepared proposal can differ in two different rounds where $p$ is
 
 * Requirement 1 [`PrepareProposal`, header-changes] When the blockchain is in same-block execution mode,
  $p$'s Application provides values for the following parameters in `ResponsePrepareProposal`:
- _AppHash_, _TxResults_, _ConsensusParams_, _ValidatorUpdates_. Provided values for
- _ConsensusParams_ and _ValidatorUpdates_ MAY be empty to denote that the Application
+ _AppHash_, _TxResults_, _ConsensusParams_, _ValidatorSetUpdate_. Provided values for
+ _ConsensusParams_ and _ValidatorSetUpdate_ MAY be empty to denote that the Application
  wishes to keep the current values.
 
-Parameters _AppHash_, _TxResults_, _ConsensusParams_, and _ValidatorUpdates_ are used by Tendermint to
+Parameters _AppHash_, _TxResults_, _ConsensusParams_, and _ValidatorSetUpdate_ are used by Tendermint to
 compute various hashes in the block header that will finally be part of the proposal.
 
 * Requirement 2 [`PrepareProposal`, no-header-changes] When the blockchain is in next-block execution
  mode, $p$'s Application does not provide values for the following parameters in `ResponsePrepareProposal`:
- _AppHash_, _TxResults_, _ConsensusParams_, _ValidatorUpdates_.
+ _AppHash_, _TxResults_, _ConsensusParams_, _ValidatorSetUpdate_.
 
 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
+_AppHash_, _TxResults_, _ConsensusParams_, and _ValidatorSetUpdate_, 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).
+_AppHash_, _TxResults_, _ConsensusParams_, or _ValidatorSetUpdate_ (the values provided will be ignored).
 
 * Requirement 3 [`PrepareProposal`, timeliness] If $p$'s Application fully executes prepared blocks in
  `PrepareProposal` and the network is in a synchronous period while processes $p$ and $q$ are in $r_p$, then
@@ -91,8 +91,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$ be the vote extension that the Application of a correct process $p$ returns via `ResponseExtendVote` in round $r$, height $h$.
+is about to broadcast a non-`nil` precommit message, a correct process can produce multiple vote extensions in round $r$, height $h$.
+Let $e^r_p$ be the vote extensions 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 8 [`ExtendVote`, `VerifyVoteExtension`, coherence]: For any two correct processes $p$ and $q$, if $q$ receives $e^r_p$
@@ -107,32 +107,32 @@ we will face the same liveness issues as described for Requirement 5, as Precomm
 extensions will be discarded.
 
 * Requirement 9 [`VerifyVoteExtension`, determinism-1]: `VerifyVoteExtension` is a (deterministic) function of
- the current state, the vote extension received, and the prepared proposal that the extension refers to.
+ the current state, the vote extensions received, and the prepared proposal that the extensions refers to.
  In other words, for any correct process $p$, and any arbitrary vote extension $e$, and any arbitrary
  block $w$, if $p$'s (resp. $q$'s) Tendermint calls `RequestVerifyVoteExtension` on $e$ and $w$ at height $h$,
  then $p$'s Application's acceptance or rejection **exclusively** depends on $e$, $w$ and $s_{p,h-1}$.
 
 * Requirement 10 [`VerifyVoteExtension`, determinism-2]: For any two correct processes $p$ and $q$,
- and any arbitrary vote extension $e$, and any arbitrary block $w$,
+ and any arbitrary vote extensions $e$, and any arbitrary block $w$,
  if $p$'s (resp. $q$'s) Tendermint calls `RequestVerifyVoteExtension` on $e$ and $w$ at height $h$,
  then $p$'s Application accepts $e$ if and only if $q$'s Application accepts $e$.
  Note that this requirement follows from Requirement 9 and the Agreement property of consensus.
 
 Requirements 9 and 10 ensure that the validation of vote extensions will be deterministic at all
 correct processes.
-Requirements 9 and 10 protect against arbitrary vote extension data from Byzantine processes
+Requirements 9 and 10 protect against arbitrary vote extensions data from Byzantine processes
 similarly to Requirements 6 and 7 and proposed blocks.
 Requirements 9 and 10 can be violated by a bug inducing non-determinism in
 `VerifyVoteExtension`. In this case liveness can be compromised.
 Extra care should be put in the implementation of `ExtendVote` and `VerifyVoteExtension` and,
-as a general rule, `VerifyVoteExtension` _should_ always accept the vote extension.
+as a general rule, `VerifyVoteExtension` _should_ always accept the vote extensions.
 
 * Requirement 11 [_all_, no-side-effects]: $p$'s calls to `RequestPrepareProposal`,
  `RequestProcessProposal`, `RequestExtendVote`, and `RequestVerifyVoteExtension` at height $h$ do
  not modify $s_{p,h-1}$.
 
 * Requirement 12 [`ExtendVote`, `FinalizeBlock`, non-dependency]: for any correct process $p$,
-and any vote extension $e$ that $p$ received at height $h$, the computation of
+and any vote extensions $e$ that $p$ received at height $h$, the computation of
 $s_{p,h}$ does not depend on $e$.
 
 The call to correct process $p$'s `RequestFinalizeBlock` at height $h$, with block $v_{p,h}$

spec/abci++/abci++_basic_concepts_002_draft.md

@@ -61,18 +61,20 @@ SHOULD accept a prepared proposal passed via `ProcessProposal`, even if a part o
 the proposal is invalid (e.g., an invalid transaction); the Application can
 ignore the invalid part of the prepared proposal at block execution time.
 
-* [**ExtendVote:**](./abci++_methods_002_draft.md#extendvote) It allows applications to force their validators to do more than just validate within consensus. `ExtendVote` allows applications to include non-deterministic data, opaque to Tendermint, to precommit messages (the final round of voting). 
-The data, called _vote extension_, will also be made available to the
+* [**ExtendVote:**](./abci++_methods_002_draft.md#extendvote) It allows applications to force their validators to do more than just validate within consensus. `ExtendVote` allows applications to include deterministic and non-deterministic data, opaque to Tendermint, to precommit messages (the final round of voting).
+The data, called _vote extensions_, will also be made available to the
 application in the next height, along with the vote it is extending, in the rounds
 where the local process is the proposer.
-If the Application does not have vote extension information to provide, it returns a 0-length byte array as its vote extension.
-Tendermint calls `ExtendVote` when is about to send a non-`nil` precommit message. 
-
-* [**VerifyVoteExtension:**](./abci++_methods_002_draft.md#verifyvoteextension) It allows validators to validate the vote extension data attached to a precommit message. If the validation fails, the precommit message will be deemed invalid and ignored
+Instead of Tendermint where the vote extensions are `ExtendVoteExtension` array.
+ExtendVote call should return the `ExtendVoteExtension` list, where each element is an object with two attributes: a type and
+bytes array.
+If the Application does not have vote extensions to provide, it returns an empty array as its vote extensions.
+Tendermint calls `ExtendVote` when is about to send a non-`nil` precommit message.
+* [**VerifyVoteExtension:**](./abci++_methods_002_draft.md#verifyvoteextension) It allows validators to validate the vote extensions data attached to a precommit message. If the validation fails, the precommit message will be deemed invalid and ignored
 by Tendermint. This has a negative impact on Tendermint's liveness, i.e., if vote extensions repeatedly 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 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. Tendermint calls it when 
-a process receives a precommit message with a (possibly empty) vote extension.
+accept it in `ResponseVerifyVoteExtension` and ignore it in its own logic. Tendermint calls it when
+a process receives a precommit message with a (possibly empty) vote extensions.
 
 * [**FinalizeBlock:**](./abci++_methods_002_draft.md#finalizeblock) It delivers a decided block to the Application. The Application must execute the transactions in the block in order and update its state accordingly. Cryptographic commitments to the block and transaction results, via the corresponding
 parameters in `ResponseFinalizeBlock`, are included in the header of the next block. Tendermint calls it when a new block is decided.
@@ -95,7 +97,7 @@ state machine snapshots instead of replaying historical blocks. For more details
 
 New nodes will discover and request snapshots from other nodes in the P2P network.
 A Tendermint node that receives a request for snapshots from a peer will call
-`ListSnapshots` on its Application. The Application returns the list of locally avaiable snapshots. 
+`ListSnapshots` on its Application. The Application returns the list of locally avaiable snapshots.
 Note that the list does not contain the actual snapshot but metadata about it: height at which the snapshot was taken, application-specific verification data and more (see [snapshot data type](./abci++_methods_002_draft.md#snapshot) for more details). After receiving a list of available snapshots from a peer, the new node can offer any of the snapshots in the list to its local Application via the `OfferSnapshot` method. The Application can check at this point the validity of the snapshot metadata.
 
 Snapshots may be quite large and are thus broken into smaller "chunks" that can be
@@ -106,7 +108,7 @@ the `LoadSnapshotChunk` method.
 
 As the new node receives "chunks" it will apply them sequentially to the local
 application with `ApplySnapshotChunk`. When all chunks have been applied, the
-Application's `AppHash` is retrieved via an `Info` query. 
+Application's `AppHash` is retrieved via an `Info` query.
 To ensure that the sync proceeded correctly, Tendermint compares the local Application's `AppHash` to the `AppHash` stored on the blockchain (verified via
 [light client verification](../light-client/verification/README.md)).