Out-of-range account index (currently >= 200) translates into a shard ID
(>= 4) not found in the genesis table, so its genesis cannot be
initialized. Since this can be induced by misconfiguration, do not
panic but just crit out.
This error was seen during drum testnet launch.
This is a temporary measure until we can:
- Fix shard state mutation bug, and
- Implement key passphrase recycle across process restart (exec) for
shard migration.
Our consensus differ from Ethereum's: The proposed block header is
incomplete until the preparer/committer bitmaps and signatures are
known, where Ethereum's proposed block is already immutable. Ethereum
code calls, especially from validator logic, block.Hash() liberally
without ill effect, but in our case the validation logic is called
before the finalization of committer bitmap, and the block.Hash() calls
embedded in the validation fixates and finalizes the block hash
prematurely.
Until we have a better logic to deal with this, disable block hash
caching, and always recompute the block hash using the actual header.
* Log the right shard number for wallet/getFreeToken
* Don't try to use empty commit bitmap from genesis block
* Fail hard if block reward or finalization fails
* Log the public key if message sig verification fails
* Extract and save chain state from received blocks in order to
eliminate deep tail recursion
* Properly deep copy chain config (previously ChainID was being shared
among chains)
* Eliminate chain use-before-init window in node.New()
* Save genesis epoch shard state in new blockchain database
* Do not check epoch of the received shard state message (temp
workaround – we should introduce the check elsewhere)
* Propose an empty block if no transactions have been received for 10
seconds
* Manage shard chains as first class citizen
* Bring core.BlockChain's read/write semantics cleaner
* Reimplement the block reward in terms of on-chain committee info, not
hardcoded genesis committee.
Eugene Kim
Leo Chen
Richard Liu
chao