Add block confirmation proposal
This commit is contained in:
parent
526344c9ac
commit
77a2f186ee
|
@ -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.
|
||||
|
Loading…
Reference in New Issue