I was going through Ethereum 2.0 specs trying to look for an explanation for the number of shards (64) but I couldn't find any.

For example here:

Shard chains spread the network's load across 64 new chains.

Or the formal specs where there are mentions of the initial number of shards (64) alongside a practical limit of 1024 shards but no explanation neither.

Why is it 64 ? Why not any other number ? Is there a rationale for this ?

Any argument or link to source would be greatly appreciated.

1 Answer 1


Considering the following, I guess the reasons are mostly based on performance and scalability.

The number of shards was redefined based on this proposal, which drastically simplifies communication between shards as they stated here. Also, the block size was increased from from 16kB to 128kB in order to achieve the scalability of the previous proposal.

To support this new proposal, the total shard count to start must be reduced from 1024 to the new estimate of 64, with the intention to scale up the number of shards over time (~10 years) as standard resources available to consumer laptops increases. The following are the primary reasons for the requisite reduction in total shards:

  • Each shard induces an attestation load on the network and beacon chain at each slot rather than at each epoch
  • Each committee must be of a minimum safe number of validators. If there are too many committees per epoch due to high shard count, then there couldn’t possibly be enough 32-ETH validators to safely allocate enough to each committee


From your comment, I've done some research since I'm curious too about why 64 shards and not other number.

First, from the Ethereum 2.0 reddit AMA (Part 2) Justin Drake said (before changing from 1024 to 64 shard chains):

Q: Why 1024 shards?

JD: Because 2048 shards would be stressing the beacon chain and 512 shards would be under-utilising the beacon chain.

From Vitalik’s Annotated Ethereum 2.0 Spec

We plan to have 64 shards at the start. Having fewer shards would lead to insufficient scalability; having more would lead to two undesirable consequences:

  • Overhead of processing beacon chain blocks being too high
  • The minimum amount of ETH needed to reach a full-sized committee for every shard in every slot (now 32 ETH * 128 committee size * 64 shards per slot * 32 slots per epoch = 8,388,608 ETH) to be too high; we’re reasonably confident we can get 8.3m ETH staking, but getting 16.7m ETH staking would be harder, and if we can’t get that much, the system would be forced compromise by making cross-shard transactions take longer.
  • 1
    While it it clearly a much better answer than the 2 previous ones, it's still fuzzy about the number 64... I mean it's obviously linked to performance and scalability, that's the whole point or shards, but 64 shard with a block size of 128KB allows for 1.3-2.7 MB/s bandwithd, but why is this bandwith range the target then ? I feel like that'd be the explanation for the number of shards, that's what I cannot find...
    – hroussille
    Dec 10, 2021 at 8:21
  • I'm not sure about the following, so please correct me if I'm wrong, but I guess the capacity (1.3-2.7 MB/s) based on the slot time (12 seconds) can be calculated from the overhead analysis and shard block size.
    – alberto
    Dec 15, 2021 at 22:06
  • 1
    Thank you for those references ! So it might also be related to the number of available validators.. which makes sense ! I'm still curious about the actual metric used to say "Because 2048 shards would be stressing the beacon chain and 512 shards would be under-utilising the beacon chain." It's just odd to say something so vague if there is a justification... not sure if he means in validators / in bandwidth or possibly both ? I am giving you the bounty anyway, thank you.
    – hroussille
    Dec 16, 2021 at 8:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.