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.
It should equal the one in the master copy found on beacon chain, except
if the master table doesn't have the shard (shard disowned), the local
leader should acknowledge this and signal the end of the shard by having
a committee proposal with empty leader and zero members.
For now, validators simply wait until the leader proposes something.
Going forward though, validators would have to deal with a leader
intentionally delaying resharding:
- A beacon leader should send resharding proposal as soon as DRand is
finished.
- A regular leader should send a local resharding proposal as soon as it
sees a master proposal from the beacon chain (received via syncing).
In both cases, there should be some sort of grace period to allow for a
short delay inserted by the leader's discretion (so that it can wait for
most nodes to catch up with DRand or beacon chain syncing).
Leo Chen
Rongjian Lan
ak
Minh Doan
Richard Liu
Eugene Kim