ChihChengLiang on master
deprecate repo Merge pull request #177 from Ch… (compare)
4,882 / 1024 = 4. And it ends up with breaking down validators set to a set of slot-shard committees, each one of size
Set crystallized_state.dynasty += 1 Let next_start_shard = (shard_and_committee_for_slots[ ][ ].shard_id + 1) % SHARD_COUNT Set shard_and_committee_for_slots[CYCLE_LENGTH:] = get_new_shuffling(block.parent_hash, validators, crystallized_state.dynasty, next_start_shard)
I’ve ported the fork choice rule to Nim: https://ethresear.ch/t/beacon-chain-casper-ffg-rpj-mini-spec/2760/13 and https://github.com/status-im/nim-beacon-chain/tree/master/beacon_chain/fork_choice_rule.
This is typed (including different hash types for block hashes and signature hashes).
It’s not v2.1 ready though and completely stand alone from the rest of the beacon chain.
Give this block tree:
Root /\ / \ C'1 C"1 | | C'2 C"2 | | C'3 C"3 | | C'4 C"4
and these super majority votes:
Root -> C'1
Root -> C"2
C'1 -> C'3
C"2 -> C"4
Haven't we finalized checkpoints C'1 and C"2 on disparate forks without violating any of the slashing conditions?
You’re right. This is a common source of confusion and could be made clearer in the paper. Even pointing out that it is a common source of confusion and should be noted!
and you don’t “look dumb”. there’s a lot going on in the paper and you clearly a groking it. Glad you came here to ask