8

I've had talks with some colleagues of mine about Ethereum 2.0 shards, my problem is the following :

Given the definition of sharding :

sharding is a way of partitioning to spread out the computational and storage workload

And that Ethereum 2.0 shards are not meant to support code execution (at least in the short term, but I'm going to explain below why I have a lot of doubts about the long-term support…), implying that they don't compute and maintain a part of the global Ethereum 2.0 state (They must sync to the beacon chain, periodically providing roll-ups, and the beacon chain runs code execution).

It really feels more like L2 is now part of the core architecture than real sharding... What do you think ? Am I missing something ?


Now, this brings me to my second question:

Is efficient state / computational sharding actually possible with smart contracts ? (Without relying on a beacon / backbone chain as it would be rendered useless if shards were able to execute code and maintain state)

There are two main problems in my opinion :

1. Cross shard transactions

When smart contracts are involved, the "complexity" of transactions is multiplied. It is no longer a relatively simple relation between sender and receiver. The smart contract can internally call many other addresses... Deciding if the contract will issue cross shard transactions (and so if it should be executing in that specific shard) requires executing the contract, which is counterproductive to say the least…

To be profitable, a sharding design must reduce cross shard transactions as much as possible, as they require state synchronization between the concerned shards and the parallelization is lost. Right now, I don't see how it can be done with smart contract...

2. State inconsistency / merging

There is no proper way to decide how to resolve state inconsistency across "real" shards that I'm aware of. As they should be processing mostly independent sets of transactions and therefore holding different states... Plugging a consensus mechanism between shards also partially defeats the very purpose of shards.

1 Answer 1

1

It really feels more like L2 is now part of the core architecture than real sharding... What do you think ? Am I missing something ?

No this is not L2. Syncing the shard chain to the beacon chain in every epoch doesn't make it an L2 solution. L2 solutions are those that do processing off-chain and keeps proof of the processing on-chain. In Ethereum 2.0 sharding, this is not the case. Eth 2.0 Shards are a set of nodes executing consensus separately and each shard behaves as a separate blockchain.

  1. Cross shard transactions

There are several methods of executing cross-shard transactions that invoke a smart contract in one shard and then in turn invokes another contract in another shard. Reading a few research publications would give you an idea. A naive approach would be to assign dependant transactions to the same shard. For example, recently, an approach known as application-based sharding has been proposed. The idea is to assign dependent DApps (smart contracts) to the same shard. Please take note that Ethereum 2.0 at the time of writing is still very much under development and the approaches to process cross-shard transactions may change.

  1. State inconsistency / merging

There is no proper way to decide how to resolve state inconsistency across "real" shards that I'm aware of. As they should be processing mostly independent sets of transactions and therefore holding different states... Plugging a consensus mechanism between shards also partially defeats the very purpose of shards.

Sharding does not aim to have the same state across shards. Each shard will have a different state according to the transactions they process. The global state will only be kept in the beacon chain, which will sync the state from all shard chains every epoch (A period of time that a shard chain committee executes). Note that Ethereum 2.0 will have a fixed number of shards (64 shards) so there will not be a need to merge two shard chains.

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.