High level understanding of Serenity - The Vision of Ethereum 2.0

This article is an effort to provide high level understanding of Serenity (Ethereum 2.0).Serenity - as the name suggest and Ethereum developers hope; Ethereum Blockchain is expected to be more stablized. Vitalik unveiled the next upgrade of Ethereum - Ethereum 2.0 in Devcon4 at Prague. Including lot of new radical ideas, it is several years of work coming together as next release of Ethereum. The Ethereum Serenity upgrade will pay validators to secure the network rather than paying miners. Because this upgrade is going to include Sharding and Casper, many people started calling it as "Shasper", but in the Devcon4 it is now formally named as "Serenity".Features included in next upgrade are:

• Proof of Stake (Casper): Pure PoS consensus
• Scalability (Sharding): ~1000x higher scalability
• VM improvement (EWASM): Fast VM execution via EWASM
• Improvements to cross-contract logic (eg. abstraction): Faster time to synchronous confirmation (8-16 seconds). Under asynchronous model, you should be able to treat 1 block as close to final.
• Improvements to protocol economics: "Economic finality" (10-20 minutes)

Soon not going to be called as 'Shasper'; Serenity begins.

What is Serenity?

It's a realization of all of different strands of research that Ethereum Core Developres have been spending time for last four years. Serenity is
* a new blockchain (in the sense of being a data structure), though with a link to the existing PoW chain, that allows to rapidly develop and iterate. The proof of stake chain would be aware of the block hashes of the proof of work chain. You would be able to move Ether from the PoW to PoS chain.
* a world computer as it is meant to be. It will be completely decentralized.

Ethereum 2.0 (Spec)

According to Vitalik, the roadmap of Ethereum 2.0, at the highest level has an impression that team is supposed to first of all, just keep on upgrading and improving the protocol, getting the proof of stake switch finished, achieving much higher scalability through sharding and from there just keep on adding technical improvements.The Ethereum 2.0 spec has been explicitly split out into two separate documents:1. The Beacon ChainBefore 2017, there was no clear idea on how proof of stake and sharding would look like. Then came up Casper FFG and coredev realized that it would make more sense to do the Proof of Stake and the sharding together in the beacon chain architecture.The Beacon Chain is the system chain at the core of Ethereum 2.0. The beacon chain is the central PoS chain that is the base of the sharding system. The main responsibilities of the beacon chain are:

• Store and maintain the registry of validators
• Process crosslinks
• Process its own block-by-block consensus, as well as the finality gadget

How to become a validator?A Validator is a participant in the Casper/sharding consensus system. As initially proposed in Proof of Stake, a validator a.k.a 'bonded validator' in Casper FFG is very much like the node or the miner of 'Proof of Work' protocol except they will be allowed to engage in the process only when they make security deposit. According to Vitalik, "A validator, is someone who has a pile of ETH and deposits it into a smart contract, and runs a node that basically signs coins with the same key that controls that ETH, in order to participate in Ethereum's consensus algorithm and keep the network running."To become a validator, you need to make a one-way ETH transaction to a deposit contract on Ethereum 1.0. There is only one way for you to become an active validator when you deposit 32 ETH into the Casper mechanism, deposit transaction receipts are processed by the beacon chain, the activation balance is reached, and a queuing process. Validators profitability depends on online availability.You may "exit" either voluntary or forcibly as a penalty for misbehavior.Latest updates to validator deposit contract to fulfill Solidity 0.51 rules and align with the Vyper sample code in spec 2.0. can be found here.The primary source of load on the beacon chain is "attestations". Attestations are availability votes for a shard block, and simultaneously proof of stake votes for a beacon chain block. A sufficient number of attestations for the same shard block create a "crosslink", confirming the shard segment up to that shard block into the beacon chain.Crosslink is a set of signatures from a committee attesting to a block in a shard chain, which can be included into the beacon chain. Crosslinks are the main means by which the beacon chain "learns about" the updated state of shard chains. Crosslinks also serve as infrastructure for asynchronous cross-shard communication.Shard Chain is one of the chains on which user transactions take place and account data is stored.The beacon chain fork choice rule is a hybrid that combines justification and finality with Latest Message Driven (LMD) Greediest Heaviest Observed SubTree (GHOST).Discussion on Casper CBC (Correct by Construction) vs. Casper FFG (Friendly Finality Gadget) is continued since they were first introduced. The major difference is that the CBC fork choice rule can be highly inefficient in time complexity due to the number of validators needing to exchange messages compared to FFG’s model. Recently, Vitalik suggested modifying the fork-choice rule by having it run on a pseudorandomly selected subset of validators to cap the overhead of the fork-choice rule while sacrificing a little fault tolerance. In the end, this could give clients the robustness of CBC while making a trade-off that could be well worth it. See more in the original ETHResearch post  Beacon-chain friendly CBC Casper.The Beacon Chain is a work-in-progress for researchers and implementers. For recent spec changes and implementation, please follow GitHub.2. Shard Data ChainsThis is Phase 1 of Ethereum 2.0 and depends on the implementation of Phase 0 - The Beacon Chain.Phase 1 is primarily concerned with the construction, validity, and consensus on the data of these shard chains. It does not specify shard chain state execution or account balances. This is left for future phases. The Phase 1 spec is beginning to take shape. New additions include:

• Shard block structure
• Shard block header verification rule
• Shard block fork choice rule
• Shard block body verification rule
• Crosslink verification rule

Shard Data Chain is a work-in-progress for researchers and implementers. It reflects recent spec changes and takes precedence over the Python proof-of-concept implementation. You may follow GitHub to track progress.

EIP processes for Ethereum 2.0

This is a little bit early to go down the EIP process and formalizing it. "The community working on the specifications is ready to go into the real launch and then write an ETH2 genesis EIP. Later on, formalize how to upgrade and build standards. The implementers nowadays are more focused on rapid communication and building, working towards client testnets, rather than the formalization of the next EIPs", suggested Danny Ryan (EF) at Serenity Q&A session at ETHMagicians.

Will EWASM replace EVM?

Ewasm, which stands for Ethereum-flavored WebAssembly, is a deterministic smart contract execution engine built on the modern, standard WebAssembly virtual machine. It may be the future execution engine for smart contracts over Ethereum blockchain, the primary candidate to replace EVM (the Ethereum virtual machine) as part of the Ethereum 2.0 "Serenity" roadmap. Even Vitalik favors the point that EVM should be retired soon and contracts should be on Ewasm with an EVM interpreter. Ewasm is also proposed for adoption on the Ethereum mainnet.There is no consensus as such to replace EVM with EWASM but dev team is working towards the possible and smooth transition. For clients, there are solid tools for EVM and Ewasm is a whole new development and tooling, so concerns are no hype. In the brain storming session, proposal of new compiles to improve the EVM came up that does not force clients to run a Wasm engine, but it gives them the option to use a Wasm engine in the future as a fallback. However, Ewasm in general, is meant to run untrusted code. According to the roadmap, the EVM exists till fork. So, EVM and Ewasm can be developed parallel and then can be coordinated in the next 2 years.As of Dec 2018, Fellowship of Ethereum Magicians came up with roughly explained 7 options for EVM / eWASM. Hopefully, we see more on it soon.Follow ewasm Community calls for updates.

How do current ERC20 contracts fit and migrate to 2.0?

As explained by Vitalik, if you have a contract for simple, short-lived interactions, just copy/paste onto Ewasm and phase one out. Could be via centralized airdrop or a script that burns coins on one side and mints them on another side. Non-financial dApps can just move really quickly. Solidity in many cases will compile to Ewasm.People could stay on 1.0 chain until it eventually folds into 2.0 chain, in which case it will require some client-side work. We could also make a light client for the 2.0 chain that fit into the 1.0 chain. Ultimately, this research is something we’d be interested in giving research grants for.Follow ETH2.0 Implementers Calls for ongoing progress in Ethereum 2.0.

Resources:

• Ethereum 2.0 Devs Handbook and FAQs
• Serenity Q&A and Q&A write-up and resources at ETHMagicians
• Prysmatic Labs

Constantinople mainnet hardfork will be on or around January 16, 2019.

Read more: Constantinople - the winding up of Metropolis phase

EtherWorld's collection of Good Read on Blockchain & Cryptocurrency.For weekly round up on Ethereum and other blockchain news, technology and projects, subscribe EtherWorld's Blockchain Weekly ______________________________________________________________________________
Disclaimer: This is not an investment advice and should NOT be viewed as project endorsement by EtherWorld. Readers are suggested to do their research before investing into any project.Follow us at Twitter, Facebook, Googe+, Medium and Steemit.