Sergio Mena
3 years ago
1 changed files with 186 additions and 0 deletions
Split View
Diff Options
+ 186
- 0
spec/abci++/abci++_properties_001_draft.md
View File
| @ -0,0 +1,186 @@ | |||
| --- | |||
| order: 1 | |||
| title: New Methods | |||
| --- | |||
| # New Methods | |||
| ## Description | |||
| ### PrepareProposal | |||
| #### Parameters and Return values | |||
| TODO | |||
| #### When does Tendermint call it? | |||
| When a validator _p_ enters Tendermint consensus round _r_, height _h_, in which _p_ is the proposer: | |||
| 1. _p_'s Tendermint collects the outstanding transactions from the mempool (TODO: should we limit size & gas?). | |||
| 2. _p_'s Tendermint creates a block header. | |||
| 3. _p_'s Tendermint calls `PrepareProposal` with the newly created block. The call is synchronous (i.e., Tendermint's execution will block until the Application returns). | |||
| 4. The Application checks the block (the header and transactions). It can also: | |||
| * add/remove transactions | |||
| * modify the header hashes | |||
| * if the block is modified, the Application sets it in the return parameters | |||
| 5. The Application signals _Accept_ of _Reject_ in `PrepareProposal`'s return values | |||
| * TODO: Decide if this kind if Accept/Reject is wanted/covered by impl (maybe a panic here makes more sense?) | |||
| * If _Reject_, the proposed block --along with any modification-- is discarded. Tendermint interprets that there is nothing to be proposed for consensus at the moment and _p_ won't send any proposal message in round _r_, height _h_. | |||
| * If _Accept_, _p_'s Tendermint uses the modified block as _p_'s proposal in round _r_, height _h_. | |||
| ### ProcessProposal | |||
| #### Parameters and Return values | |||
| TODO | |||
| #### When does Tendermint call it? | |||
| When a validator _p_ enters Tendermint consensus round _r_, height _h_, in which _q_ is the proposer (possibly _p_ = _q_): | |||
| 1. _p_ sets up timer `ProposeTimeout`. | |||
| 2. If _p_ is the proposer, execute steps 1-6 in _PrepareProposal_. | |||
| 3. Upon reception of `Proposal` message from _q_ for round _r_, height _h_, _p_'s Tendermint calls `ProcessProposal` with the newly received proposal. The call is synchronous. | |||
| 4. The Application checks/processes the proposed block, which is read-only, and returns _Accept_ or _Reject_. | |||
| * Depending on the Application's needs, it may return from `ProcessProposal` | |||
| * either after it has completely processed the block (the simpler case), | |||
| * or immediately (after doing some basic checks), and process the block asynchronously. In this case the Application won't be able to reject the block, or force prevote/precommit `nil` afterwards. | |||
| 5. If the returned value is | |||
| * _Reject_, Tendermint will prevote `nil` for the proposal in round _r_, height _h_ (this can be interpreted as _valid(v)_ returning false in the white paper's pseudocode) | |||
| * _Accept_, Tendermint will follow the normal algorithm to prevote on the proposal in _r_, height _h_ | |||
| ### ExtendVote | |||
| #### Parameters and Return values | |||
| TODO | |||
| #### When does Tendermint call it? | |||
| When a validator _p_ is in Tendermint consensus round _r_, height _h_, state _prevote_, and the other conditions prescribed by the consensus algorithm for sending a _Precommit_ message are fulfilled: | |||
| 1. _p_'s Terndermint updates the consensus state as prescriped by the algorithm (_validValue_, _lockedValue_, etc.) | |||
| 2. _p_'s Tendermint calls `ExtendVote` with the value that is about to be sent as precommit message. The call is synchronous. | |||
| 3. The Application returns an array of bytes, `precommit_extension`, which is not interpreted by Tendermint. | |||
| 4. _p_'s Tendermint includes `precommit_extension` as a new field in the `precommit` message. | |||
| 5. _p_'s Tendermint broadcasts the `precommit` message. | |||
| N.B: In Github discussions, I saw Dev becoming convinced that extending `nil` precommits is quite useless in practice. So I'd simplify the text above to only consider non-`nil` precommits. As it is now, the text is ambiguous when referrring to the "conditions". | |||
| ### VerifyVoteExtension | |||
| #### Parameters and Return values | |||
| TODO | |||
| #### When does Tendermint call it? | |||
| When a validator _p_ is in Tendermint consensus round _r_, height _h_, state _prevote_, and _p_ receives a `Precommit` message for round _r_, height _h_ from _q_: | |||
| 1. _p_'s Tendermint calls `VerifyVoteExtension` | |||
| 2. The Application returns Accept or Reject -- TODO: Can we really reject here? Discuss liveness problems | |||
| 3. _p_'s Tendermint deems the `precommit` message invalid if the Application returned Reject | |||
| ### FinalizeBlock | |||
| #### Parameters and Return values | |||
| TODO | |||
| #### When is it called? | |||
| TODO: Quite simple. Equivalent to BeginBlock, [DeliverTx]*, EndBlock, Commit (?) | |||
| TODO: To discuss: An optimization could be the App setting a config to not send the whole block, just the hash or id | |||
| ### [Unclear/controversial aspects] | |||
| #### Early evidence collecting (output of ProcessProposal in Dev's pseudocode) | |||
| Need to understand the use cases, in order to come up with the properties | |||
| #### Dev's v4 changes (a.k.a. _multithreaded ABCI++_) | |||
| Comments on the "fork-join" mechanism | |||
| * So far, the preferred operation mode for ABCI has been synchronous. The most notable exception is: checkTx (deliverTx is not really async). However, there are no strong properties to be expected from checkTx, relating the transactions it checks and their validity when they make it into a block. | |||
| * The "join" part has two aims in the pseudocode (v4) | |||
| * early collection and treatment of evidences. See above | |||
| * influencing the pre-commit to be sent (whether _id(v)_ or `nil`) | |||
| * TODO: Discuss strong liveness implications. Ask Josef: should I write something here and then discuss, or the other way around? (the latter seems more efficient) | |||
| #### Separation of `VerifyHeader` and `ProcessProposal` | |||
| To discuss. Starting point: it only makes sense if using the "Fork--Join" mechanism | |||
| ##### [From Josef] We should understand the influence equivocation on proposals in ABCI++ | |||
| TODO | |||
| #### Byzantine proposer | |||
| If Byzantine proposer proposes both A and B in the same round, today we might only receive A (proposal) and not B | |||
| #### `ProcessProposal`'s timeout (a.k.a. Zarko's Github comment) | |||
| TODO (to discuss): `PrepareProposal` must be synchronous, `ProcessProposal` may also want to fully process the block synchronously. However, they stand on the Tendermint's critical path, so the propose timeout needs to acknowledge that. | |||
| Idea: Make propose timestamp (current hardcoded to 3 secs in the implementation) part of ConsensusParams, so the App can adjust it with its knowledge of the time it takes | |||
| ## Properties | |||
| [These are a sketch ATM] | |||
| ### From Terndermint's point of view | |||
| `PrepareProposal`'s outcome (i.e., modified block and _Accept_ or _Reject_) | |||
| * it does not need to be deterministic | |||
| -- | |||
| Discuss with Josef `PrepareProposal` in different rounds. Algo in paper allows different. Should we? | |||
| -- | |||
| `ProcessProposal`'s outcome (_Accept_ or _Reject_): | |||
| * MUST be deterministic | |||
| * MUST exclusively depend on the proposal's contents, and the Application's state that resulted from the last committed block | |||
| If this doesn't hold, Tendermint might not terminate (N.B: I'm not sure this is the case -- to discuss) | |||
| -- | |||
| If `ProcessProposal`'s outcome is _Reject_ for some proposed block. Tendermint guarantees that the block will not be the decision. | |||
| TODO: This has implications on the termination mentioned above. | |||
| -- | |||
| The validity of every transaction in a block (from the App's point of view), as well as the hashes in its header can be guaranteed if: | |||
| * `ProcessProposal` *synchronously* handles every proposed block as though Tendermint had already decided on it. | |||
| * All the properties of `ProcessProposal` mentioned above hold. | |||
| -- | |||
| What are the properties we can offer to ExtendVote/VerifyVoteExtension ? | |||
| * Can be many, a different one per round | |||
| * In the same round, they are many as well: one per validator | |||
| * TODO: ask Dev: what properties can/must the App guarantee when replying to ExtendVote (determinism?, same output?, no guarantees?) | |||
| * The guarantees ABCI++ can offer depend on those | |||
| -- | |||
| The two workflows discussed with Callum: App hash on N+1 vs App hash on N. How to capture it in ABCI++ ? | |||
| ### From the Application's point of view | |||
| TODO | |||
| `ProcessProposal` in different rounds | |||
| `ExtendVote` in different rounds | |||