As Ethereum 2.0 begins to come online with the recent Testnet release of phase 0 of the Ethereum 2.0 Roadmap by Prysmatic Labs (Congrats, guys!), we are extremely excited and more confident than ever with our bet on Ethereum when we first started developing SKALE. This event marks a huge milestone for ETH 2.0 development and brings us one step closer to the decentralized future.
But there is still plenty of work to be done; sharding is neither trivial to implement nor understand (especially with the constantly evolving specifications for each phase in the roadmap)! And that’s why we’re taking some time to simplify some of the core ideas behind sharding, its benefits, and some of its limitations / challenges.
Sharding Elevator Pitch
Ethereum 1.0 follows the monolith pattern, this means that everything happens in one place with no modularity or compartmentalization - everything is stored and executed on all nodes in the network. With sharding, we appoint nodes in the network to run “shards”, shards are Ethereum equivalents (insofar as functionality), but are only comprised of a few nodes from the entire network.
Securing Each Shard
In decentralized systems, security is a numbers game which is necessary to ensure that one party can’t control a majority of resources in the network. For each shard, this assurance is granted via proof of stake consensus, random sampling, and the assumption of an honest majority of nodes.
To mitigate the possibility of collusion in a shard, nodes are appointed to shards via random selection from a ‘validator pool’. The random selection is buttressed through regular reappointing of nodes to serve as validators within shards.
Consider a validator pool of 100,000 nodes. While each shard might only have 128 validators, one would need to control >67,188 nodes in the validator pool to give themselves a fair chance at having >86 of their nodes randomly appointed to a shard. If this were to happen, that individual would control >⅔ of the validators in the shard and could launch a supermajority attack, but such malicious behavior comes at great cost to the offending party(ies) as a result of the proof of stake consensus.
To join the validator pool for Ethereum 2.0, nodes are required to stake 32 ETH. If validators who are running a shard are found to be attacking it or acting maliciously, peers can record proof of their activity and report it to the beacon chain - causing the offending validator to have his / her stake slashed. While some of the details on slashing are still a bit fuzzy, it’s also likely that whistleblowing will be incentivized, allowing for a self-policing network.
All of this would be impossible without the assumption of an honest majority. If the majority of the resources in a network are controlled by an adversary, the only way to mitigate their control is to lessen their impact on the network. In cases where owners of each resource are identifiable and known, this is straightforward; but when that isn’t the case, the only chance at mitigating their effects on the network is through random sampling.
Something which is important to understand about Ethereum 2.0 is that its scalability comes from the localization of transactions. Once can think of it in this way - Ethereum 1.0 is a blockchain for the entire world while Ethereum 2.0 is a blockchain for each major city with a beacon chain to send money between cities. So, if most transactions are localized whereby individuals are sending transactions within their cities, we will see a throughput increase due to parallelization.
In PoW, miners lose their rewards if they mine a block which is later orphaned. With PoS, validators not only lose their rewards for any blocks that they have built on which are invalid, but the validator who created the block also loses their stake of 32 ETH. So, for an invalid block to be committed and not reverted, all validators who had built on that block would have to be willing to lose their rewards and be unwilling to claim the reward for whistleblowing on the invalid block (which is pretty difficult to imagine happening given the random selection and regular shuffling).
Limitations and Challenges
The challenges of moving to ETH 2.0 are non-trivial. These challenges are not only technical but include communication and alignment issues as a global decentralized organization attempts to come to consensus on a plan, plus the myriad of issues that come with trying to rip out a mature network and start anew. Additionally, sharding is not a silver bullet and will need to be used in tandem with layer two solutions to truly scale Ethereum.
Computation / Storage
One of the main limitations for sharding is the fact that each shard still faces the same constraints as the existing Ethereum mainnet. While this may be updated at a later point in time, developers will still be faced with the same issues relating to high cost and low throughput for smart contracts as well as lacking of any cost-effective decentralized storage solution.
Upgrade vs. Replacement
Many people believe that Ethereum 2.0 is an upgrade to Ethereum. But, as it currently stands, it looks much more like a replacement.
Currently, there is no set plan to migrate over the existing infrastructure from Ethereum 1.0 - and while there are some ideas, the fact that this hasn’t yet been decided is worrisome given that this is one of Ethereum’s greatest advantages over competing chains.
Combining this with the advancement of Layer Two solutions on Ethereum 1.0, it’s possible to see how individuals might care to migrate. And with the amount of money that’s already been invested in Ethereum mining, it’s to miners’ advantage that the network continue as PoW.
Lastly, there has never been a replacement of a blockchain of this magnitude in all of history. In sum, there’s still a lot that needs to be worked out and it’s important that the community aligns itself on an understanding of this process, recognizes the factors working against it, and come to an agreement on how to best address each.
This is just the first phase of Ethereum 2.0 and there is still a lot of work to be done in the next two phases before Ethereum 2.0 is launched. That said, phase 0 needs plenty of testing and we highly advocate you spinning up a node to support the network on the Goerli testnet!
In the meantime, if you are interested in trying out SKALE’s Elastic Sidechains out, make sure to join the SKALE community on Discord and check out the Developer Documentation! Also, feel free to also check out SKALE’s Technical Overview and Consensus Overview for a deeper dive into how SKALE works and is able to provide 20,000 TPS.
SKALE’s mission is to make it quick and easy to set up a cost-effective, high-performance sidechain that runs full-state smart contracts. We aim to deliver a performant experience to developers that offers speed and functionality without giving up security or decentralization. Follow us here on Telegram, Twitter, Discord, and sign up for updates via this form on the SKALE website.