Proposers of a shard slot are pseudorandomly chosen like on beacon chain. Every validator does not however have the mempool or the state of every shard there is. So, when assigned to propose a block on a random shard, how does the proposer create a block to propose? Is there another builder of the block that distributes it to the proposer or what is the solution?
1 Answer
This is an area that has changed and continues to change in the spec.
The original idea was that shards would be executable and have their own state. Transactions on shards could be valid or invalid with respect to that state, therefore shard committees would need to sync up the state of a shard to be able to build valid blocks. In that spec there were long-lived shard committees that would have the chance to sync up the state of a shard before they needed to propose blocks, and then remain as a committee for a reasonable period to amortise the cost of having to do the syncing.
When we removed executable shards from the spec and moved solely to data sharding, there was no longer any need to sync up the state of a shard: the proposer just collects the pending transactions for the shard from the mempool and makes them into a block. There are no validity conditions to check; sharded data is just blobs. Other validators would then attest to the availability of that data. Transaction data for particular shards would be broadcast on specific subnets to avoid proposers having to see everything: they just subscribe to the ones they need, which is a fairly quick process.
The latest idea is for normal validators not to monitor the shards at all, but to have specialised block builders that monitor all the shards and then give a fully-formed block to the next beacon block proposer containing all the shard information. All that the normal validators have to do is attest that the sharded data is available, which is done via data availability sampling.
answered Jan 18, 2022 at 22:08
