2

In this article about the sharded blockchains, (Link to article) we read:

The core idea in sharded blockchains is that most participants operating or using the network cannot validate blocks in all the shards. As such, whenever any participant needs to interact with a particular shard they generally cannot download and validate the entire history of the shard.

What reason does cause that a validator in shard A cannot download and validate the correctness of the entire history of the shard B ?

From my point of view, that validator is able to download the entire historical transactions in any arbitrary shard (exactly similar to a non-sharded blockchain) and then verify the history of all transactions by tracing each transaction.

What is the problem? (Where typically all the shards use the same consensus algorithms and all of them have the same block structure.)

Improve this question

2 Answers 2

Reset to default
2

A validator in ShardA cannot download and validate all of ShardB because the validator already has too many shards.

The main scalability problem with blockchains is that all validators have to validate every single transaction. The idea behind sharding is that transactions will be split across shards, and each validator will validate a small number of shards. This is also important for decentralization because a system where only supercomputers can download and validate all shards, would not be decentralized. Long term, even supercomputers would not be able to download and validate all shards.

Improve this answer
2
  • If I understood correctly, the problem is limitation of space and processing. If so, my question was about a situation in which a validator from shard#A wants to download and process only the chain of another shard#B, (and not all of other shards). So, in this case, if validator of shard#A has enough space, is he able to verify validity of the chain of shard#B ? I mean there is not any other limitation such as lack of required information for validation etc? Thank you
    – Questioner
    Commented Jul 5, 2019 at 9:18
  • 1
    My answer is general like your question. To your comment, Yes. It also seems to be Yes for an Ethereum 2.0 super-full node which "downloads the full data of the beacon chain and every shard block referenced in the beacon chain". See also ethresear.ch/t/node-types-in-ethereum-2-0/3668 (@alberto's bullets are accurate but I'm not sure about his conclusion given the "super-full nodes" which match closest to what you mean by "validator".)
    – eth ♦
    Commented Jul 25, 2019 at 11:21
1

Maybe this can help.

The following must be taken into account, for validators:

  • Validators can't choose what shard chain they go into.
  • The timeline is divided into epochs (6.4 minutes) and each epoch is divided into slots.
  • Slot time is 6 seconds (shard block time).
  • In each slot of time there is a different set of proposers (block validators).
  • The order of the proposers is known minutes before the assignment.

Answering your question, a validator from shard A cannot verify and download the entire state from shard B due to the time limitations of the protocol.

As @eth answer, the problem is about processing. But, there can be actors like single nodes that simply run for their benefit and can download all data state about a shard chain and choose to verify or not.

References:

Improve this answer
2
  • This proposition: "Validators can't choose what shard chain they go into." is a property of all sharded blockchains? Or is a specific feature of Ethereum 2.0 ? Thanks
    – Questioner
    Commented Jul 5, 2019 at 10:48
  • 1
    @Questioner It's defined in Ethereum 2.0, the validators wait until the beacon chain assigns them to a random shard chain.
    – alberto
    Commented Jul 5, 2019 at 10:57

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.