From 77a2f186ee67a2a09527d7eedaa233b377ae2146 Mon Sep 17 00:00:00 2001 From: Greg Fitzgerald Date: Fri, 11 Jan 2019 12:28:55 -0700 Subject: [PATCH] Add block confirmation proposal --- book/src/block-confirmation.md | 78 ++++++++++++++++++++++++++++++++++ 1 file changed, 78 insertions(+) create mode 100644 book/src/block-confirmation.md diff --git a/book/src/block-confirmation.md b/book/src/block-confirmation.md new file mode 100644 index 0000000000..8b79c39d5e --- /dev/null +++ b/book/src/block-confirmation.md @@ -0,0 +1,78 @@ +# Block Confirmation + +A validator votes on a PoH hash for two purposes. First, the vote indicates it +believes the ledger is valid up until that point in time. Second, since many +valid forks may exist at a given height, the vote also indicates exclusive +support for the fork. This document describes only the former. The latter is +described in [fork selection](fork-selection.md). + +## Current Design + +To start voting, a validator first registers an account to which it will send +its votes. It then sends votes to that account. The vote contains the tick +height of the block it is voting on. The account stores the 32 highest heights. + +### Problems + +* Only the validator knows how to find its own votes directly. + + Other components, such as the one that calculates confirmation time, needs to + be baked into the fullnode code. The fullnode code queries the bank for all + accounts owned by the vote program. + +* Voting ballets do not contain a PoH hash. The validator is only voting that + it has observed an arbitrary block at some height. + +* Voting ballets do not contain a hash of the bank state. Without that hash, + there is no evidence that the validator executed the transactions and + verified there were no double spends. + +## Proposed Design + +### No Cross-block State Initially + +At the moment a block is produced, the leader shall add a NewBlock transaction +to the ledger with a number of tokens that represents the validation reward. +It is effectively an incremental multisig transaction that sends tokens from +the mining pool to the validators. The account should allocate just enough +space to collect the votes required to achieve a supermajority. When a +validator observes the NewBlock transaction, it has the option to submit a vote +that includes a hash of its ledger state (the bank state). Once the account has +sufficient votes, the vote program should disperse the tokens to the +validators, which causes the account to be deleted. + +#### Logging Confirmation Time + +The bank will need to be aware of the vote program. After each transaction, it +should check if it is a vote transaction and if so, check the state of that +account. If the transaction caused the supermajority to be achieved, it should +log the time since the NewBlock transaction was submitted. + +### Finality and Payouts + +Locktower is the proposed [fork selection](fork-selection.md) algorithm. It +proposes that payment to miners be postponed until the *stack* of validator +votes reaches a certain depth, at which point rollback is not economically +feasible. As it affects this proposal, it means that the vote program would +likely implement locktower. Vote instructions would need to reference a global +locktower account so that it can track cross-block state. + +## Challenges + +### On-chain governance + +Using programs and accounts to implement this is a bit tedious. The hardest +part is figuring out how much space to allocate in NewBlock. The two variables +are the *active set* and the stakes of those validators. If we calculate the +active set at the time NewBlock is submitted, the number of validators to +allocate space for is known upfront. If, however, we allow new validators to +vote on old blocks, then we'd need a way to allocate space dynamically. + +Similar in spirit, if the leader caches stakes at the time of NewBlock, the +vote program doesn't need to interact with the bank when it processes votes. If +we don't, then we have the option to allow stakes to float until a vote is +submitted. A validator could conceivably reference its own staking account, but +that'd be the current account value instead of the account value of the most +recently finalized bank state. The bank currently doesn't offer a means to +referencing accounts from particular points in time. +