mithril fork choice #141
Description
tracker issue - @smcio has full context and is working on implementation already
the accountsdb will have "unconfirmed data" if the rpc sends blocks that have not achieved consensus. This doesn't normally happen, and mithril does "catch" it in the sense that there will be a bankhash mismatch causing the validator to halt, but there is a problem here because the accountsdb has already been corrupted since the block is assumed to be confirmed.
we'd like to consume raw "blocks" from the network without relying completely on RPC honesty.
If we consume raw blocks then we don't have a way of knowing if the block is confirmed or skipped.
the simplest design is that we execute a block, hold the bankhash in memory -we don't commit to Accountsdb at this point)
there's a parallel thread (vote analyzer) that just analyzes votes and builds a map of slot->bankhash->%stake_voted
we only commit a block with a certain bankhash to accountsdb if the vote analyzer says that in subsequent blocks this bankhash has achieved threshold of 67% votes
this normally works but there's a special case where not every bankhash is voted on. i.e. we are currently holding bankhash(N) in memory, sub sequent blocks don't show 67% on N, but for some future block N+1 or N+2... or N+k
to address the special case and to generally handle the fact that confirmations might not just be on N, but could be on N+k, we have a slightly more complex algorithm here -
https://gist.github.com/dubbelosix/56ba18135227e7e284b1a298f33ec37a
if the algorithm works as intended, we are verifying fork choice and votes before committing a block to Accoutnsdb.