You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
1. [shard chain fork choice rule] move get_winning_proposal logic to it. Maintain canonical shard chain upon (i) receiving new shard block (ii) new beacon chain block (ii) time tick. (Shard fork choice rule #1773)
2. [shard chain transition] Add shard_transition_digest wrapper. Currently we have hash(hash_tree_root(shard_state) + beacon_parent_root + shard_body_root)
3. [data availability] Inefficiencies in data availability proofs #1194 (outdated???)
4. [data availability] Generating data availability roots from shard block roots #1438
Not sure if this categorize as a beacon chain known issue, I'm curious to know if we should add Shard as a first class citizen in AttestationData, whether to replace CommitteeIndex or be explicit about both
Add an item: move to Dankrad's 0.001 bit proof of custody? Also change the custody duration to 8 weeks to avoid the need for complicated delay handling logic; it would be a more simple "if you don't publish the period N key during period N+1 you get forcibly exited".
A. Phase 1 beacon chain for legacy
B. Phase 1 beacon chain for shards
get_start_shard
logic (get_start_shard
proposal #1858)Shard
field toAttestationData
shard_data_roots
C. Phase 1 shard chain
get_winning_proposal
logic to it. Maintain canonical shard chain upon (i) receiving new shard block (ii) new beacon chain block (ii) time tick. (Shard fork choice rule #1773)shard_transition_digest
wrapper. Currently we havehash(hash_tree_root(shard_state) + beacon_parent_root + shard_body_root)
D. Phase 1 fork choice rule
The text was updated successfully, but these errors were encountered: