Anything that affects how the ledger is interpreted needs to be
in the genesis block or someplace on the ledger before later
parts of the ledger are interpreted. We currently don't have an
on-chain program for cluster parameters, so that leaves only
the genesis block option.
Making `solana_vote_program` is not an option because
then vote_program's entrypoint conflicts with reward_program's
entrypoint.
This unfortunately turns the SDK into a dumping ground for all
things shared between vote_program and other programs. Better
would be to create a solana-vote-api crate similar to the
solana-rewards-api crate.
And add a new 'staker_id' VoteState member variable to offer a path to
work our way out. Update leader scheduler to use staker_id, but
continue setting it to 'from_id' for the moment.
No functional changes here.
* Allow chained BudgetExpr via indirection
Change `And`, `Or`, and `After` expressions to contain
`Box<BudgetExpr>`s instead of directly holding payments
* run cargo fmt
* Use vote signer service in fullnode
* Use native types for signature and pubkey, and address other review comments
* Start local vote signer if a remote service address is not provided
* Rebased to master
* Fixes after rebase
* Also implement more storage contract logic
* Add transactions for proof validation,
* Move storage state members into system storage account userdata
* Remove logging init from storage program: saw a crash in a test
indicating the logger being init'ed twice.
* Add entry_height mining proof to indicate which segment the result is
for
* Add an interface to get storage miner pubkeys for a given entry_height
* Add an interface to get the current storage mining entry_height
* Set the tvu socket to 0.0.0.0:0 in replicator to stop getting entries
after the desired ledger segment is downloaded.
* Use signature of PoH height to determine which block to download for
replicator.
