8 ms·
So, what happens when one of the shards goes offline, or forks? What are the cascading consequences for validators of other shards, if any? Asking because I d
by jude- 5y ago
So, what happens when one of the shards goes offline, or forks? What are the cascading consequences for validators of other shards, if any?
Asking because I don't think there's a viable strategy for keeping all shard data around indefinitely, without giving up either scalability or durability:
* If the system requires cross-shard state-transitions to be mirrored to on a "central" chain (e.g. the beacon chain) in order to stave off unavailability, then that central chain's capacity is the scalability bottleneck.
* If the system requires cross-shard state-transitions to be mirrored instead to both shards in order to stave off unavailability, then ultimately all shards will host a non-trivial fraction of each others' state, meaning that the scalability bottleneck is the most-loaded shard.
* If the system requires some nodes to store full replicas of all shards in order to avert shard unavailability, then the system is no more scalable than the nodes required to carry this burden.
- ec109685 5y agoWouldn’t each shard itself be made up of thousands of nodes and thus not easily taken down? And there would be incentive to join the hampered shard to repair it given joining nodes would have a larger share of the hashing power than in non-hampered shards.
- jude- 5y agoI don't think shards are powered by hashing? I think nodes participating in Ethereum 2.0 are assigned to shards by the beacon chain, and they work to grow the shard's transactions by deciding on transaction ordering and inclusion in a BFT manner. Also, it's not clear to me that it's "thousands," nor is it clear to me that this even matters. If they're all in the same datacenter, and that datacenter temporarily gets disconnected from the other shards' nodes, then the shard is effectively dead as far as the rest of the network is concerned.
- DennisP 5y agoWhy would they all be in the same datacenter? The beacon chain will periodically select staking nodes at random to go in each shard, and there's an economic incentive for stakers not to use the same infrastructure as everyone else.
- jude- 5y agoWhy is the chain's liveness and resiliency to server failures dependent on where people happen to be keeping their validators? This isn't a problem in Ethereum 1.0.
- DennisP 5y agoI mean, if all the miners were on one datacenter and that datacenter went down, so would Ethereum 1.0. That's the same sort of failure you're worrying about for 2.0.
- jude- 5y agoA blockchain's resiliency in part depends on how many full replicas are available -- if at least one replica exists somewhere, the chain can be resuscitated even if all block producers die. In Ethereum 2.0, nodes don't maintain a full copy of the chainstate -- not even block producers do. Therefore, Ethereum 2.0's resiliency depends on the continued availability of N > 1 partial copies of the chainstate, such that the full chainstate can be reassembled from them. This is strictly less resilient.
- TimJRobinson 5y agoThe shards have thousands of different validators, all of which are staking their Ethereum on being accurate, and if they are malicious, they lose that Ethereum they staked. There are over 100k people signed up to this already (each staking 32+ ETH). So the likelihood of a shard going offline or forking is about as likely as AWS going down. The beacon chain is the central chain, all shards write a hash of what they've done to this one. All nodes validate the shard they've been assigned to as well as the beacon chain.
- jude- 5y agoValidators != separate physical computers. Also, what happens if the nodes for shard S in epoch N fail to replicate the shard data to the nodes assigned to S in epoch N+1?