Full section on Messari's Ethereum trends for 2020 here
ETH 2.0 Research/Governance/Roadmap at a glance
If history is any guide, we’re not going to see ETH 2.0 until 2022 at the earliest, even if the earliest phases of “Serenity” begin getting pushed in mid-2020. ETH 2.0’s rollout breaks down into seven (7!!!) phases and brings with it the promise of staking, sharding, a new virtual machine, and more dancing badgers.
(One of our analysts, Wilson Withiam, put together an excellent overview of both the ETH 2.0 and ETH 1.x roadmaps for this report. They are critical to track and understand at a high-level given how much Ethereum’s performance will affect other competitive projects and most of the DeFi and Web 3 infrastructure. So these next two sections are longer and more technical.)
Here’s what you need to know about the current game plan for crypto’s largest platform.
Phase 0 marks the launch of the “beacon chain”, which will serve as the backbone for a new blockchain. The beacon chain will manage network validators (large early stakers like ConsenSys) and ultimately assign validators to individual shards (slicing the new blockchain into smaller chunks is a key, difficult, controversial scaling decision that’s been made). The new chain will support Ethereum’s new proof-of-stake consensus mechanism, and offer inflation rewards with new ETH2 for those that pony up and lock 32 ETH1 tokens into an irreversible contract. That one way bridge into the new system is also contentious, but it means ETH1 supply will start getting “effectively burned” once token holder begin claiming beacon chain validator slots. Initial reports claimed Jan. 3 as a realistic launch date (lol). It will be amazing to see this launched by end of June.
Phase 1 will introduce 64 individual shard chains (reduced from 1,024!!!) to the network, with the option to increase the total down the road as the design gets tested. The Ethereum elite see sharding as the “key to future scalability” as shards can parallelize transaction processing, something that could improve network performance and reduce individual validator’s costs (good for decentralization). It comes with big risk: this is still theoretical. No network the size of Ethereum has successfully sharded its blockchain. In Phase 1, shard chains will only contain simple data sets (no smart contracts or transaction executions) to test the system’s structure. As with Phase 0, the beacon chain will continue to run in parallel with ETH 1.x throughout the phase. Don’t expect Phase 1 anytime before 2021.
Phase 2 marks the full launch of the ETH2 chain, allowing for on-chain contract execution and introducing the new eWASM virtual machine (dubbed EVM 2.0). At this point, existing dApps can start migrating their contracts from ETH 1.x to a specific shard (one shard per contract) in the new network. Storage rent, charging contract owners for storing data on the network (more on this below), is in the cards as well, which would require mass contract rewrites. Even though Phase 2 intends to replace the original Ethereum blockchain entirely, ETH 1.x may still live on as a shard within ETH2. (How confused are you by now? See why bitcoin will still dominate the macro narrative for a while?) A late 2021 release for Phase 2 is optimistic. Before the end of 2022 would be a win.
The final four phases are less defined, and without an attached timeline:
Phase 3 implements state-minimized clients (because stateless clients are just too much). Phase 4 allows for cross-shard transactions. Phase 5 improves network security and the availability of data proofs. Phase 6 introduces meta-shards, as in “shards within shards within shards,” for near-infinite scaling. If you’re scratching your head and are sadistic enough to read more, the Sharding Wiki page does note, “this may be difficult.”
Scaling and compilation efficiencies aside, the most notable change in Ethereum’s metamorphosis is the transition from proof-of-work to proof-of-stake. PoW is the more battle tested security model for blockchain networks, while PoS may prove to be more efficient but with new and less obvious attack vectors. For the more technical, we recommend reading Bison Trails’ Viktor Bunin on the subject of PoS security threats.
Past research has also shown PoS requires an extra layer of “trust” vs. PoW, to help nodes sync to the network. Most models share specific characteristics to address this trust issue, such as allowing for a dynamic set of validators (rotate your security), promoting token holder participation in consensus, and assessing steep penalties (slashing) for any network participant that violates the protocol guidelines. ETH 2.0 will function similarly, but may be able to learn from other PoS networks (and their R&D) as well as those come live and see real world issues. As Vitalik points out, recent research in PoS resulted in “great theoretical progress,” But...
Listen, we're talking about practice. Not a game. Not a game. Not a game. We're talking about practice. Not a game….Practice? We're talking about practice, man? We're talking about practice. We're talking about practice. We ain't talking about the game. We're talking about practice, man.
Vitalik was eight when this happened, so the clip might help and prove metaphoric.
2 ETH 1.x Research/Governance/Roadmap at a glance.
Ok, one more. Bear with us. Let’s reiterate, ETH 2.0 is a brand new blockchain. It’s going to be a chaotic and high-risk transition. In the meantime, the existing network needs to run existing applications (particularly financial settlements for DeFi transactions). More critical upgrades are needed in the current system.
To that end, ETH 1.x devs have three goals to boost performance and reduce blockchain bloat: (1) introduce client optimizations that increase transaction capacity; (2) cap disk space requirements and prune old, memory-sucking data (so running a node is less expensive and more decentralized); and (3) upgrade the EVM to eWASM, a newer open standard for code compilers that simplifies debugging, and is also used by all the newer smart contract platforms.
ETH 1.x developers have decided to split the major tasks amongst four working groups:
- State Rent: Developers today incur a single payment for deploying contracts and storing data on the network. Thanks to the immutable nature of blockchains, this data occupies the disk space of node operators permanently. As the network’s state grows, so do operating costs, which is where “state rent” comes in. It makes sense to charge for ongoing storage needs since the node operators are on the hook in perpetuity. This is a big change as it could break a bunch of contracts, but also limits state growth and creates economic incentives to run a node. What happens to data that users don’t want to pay for? Boot delinquent user data off the network but keep a stub (a hash) of information on hand in case the user wants to later reinstate it.
- Pruning: Similar goal. Pruning removes old data that is longer useful, but does so in a way that allows clients to prove past transactions. There are a couple of ways developers think this is possible (e.g. maintain a proof of deleted chain segments, which is similar to a “light client” in bitcoin that makes it possible to run a wallet on your phone), but all current strategies would cap annual “state growth” to prevent spikes in storage costs, at the expense of some new complications (e.g., dApps might be unable to access some data, and nodes might be unable to tell if data was deleted or whether it never existed in the first place).
- eWASM: Like ETH 2.0, devs plan to implement eWASM on the flagship Ethereum chain. The eWASM virtual machine, a subset of the well-established WebAssembly compiler, offers improved flexibility for the introduction of “high-performance” smart contracts.
- Simulation and Emulation: This group develops tools to help support and evaluate the other groups because, well, someone has to test everything.
Core developers intend to introduce most of these implementations through a series of hard forks, the latest of which activated just over a week ago (Istanbul, Dec. 7). However, Istanbul’s second phase, tentatively scheduled for Q2 next year, has Ethereans at each other’s throats. The controversy boils down to the fork’s inclusion of ProgPoW, an ASIC-resistant hashing algorithm designed to replace Ethereum’s current algo. ProgPoW aims to even the playing field for GPU miners and ward off the entrance of potential ASIC competitors. The miners like that. But many miners and investors see ProgPoW as a threat to their investments. For miners, the change would shift the power dynamic away from mining farms and render expensive, specialized mining hardware useless. Ethereum (and ERC-20) investors intent on securing their assets might balk because ASIC miners typically prop up hash rates (overall chain security) and their costs “naturally create a price-floor for ASK prices of miners’ sell-orders.”
This saga is far from over. The infighting will likely continue leading up to ProgPoW’s activation date mid-next year, and presents the strongest potential for a network split since “The DAO” fork that spawned Ethereum Classic. The looming transition to ETH 2.0 (and proof-of-stake) will likely deter investor pushback, because it’s a short-term battle in a war the miners are ultimately going to lose, anyway.
Unless the roadmap changes back to supporting a hybrid PoW/PoS system, of course, but...
Oh my god, I’m just kidding. This section is mercifully over.
No comments:
Post a Comment