Ethereum 2.0

  • Published At: 11.04.19 11:38
  • Last Updated At: 01.12.20 12:37
  • Total Views: 1790

Eth 2.0 consists of a set of specifications designed to improve the efficiency and performance of the network; it is a project in continuous evolution, which is modified during the work in progress and sometimes even drastically changed. Currently the idea shared between developers and researchers is to unify two technical specifications that are certainly not new:

Casper: brings a first change to the consensus system: from Proof of Work to Proof of Stake. The Proof of Stake has a very important role to play as it should:

● Improve the purpose by reducing the number of confirmations needed to consider a transaction as having actually taken place.
● Make 51% attack excessively expensive and pointless.
● Make mining pools unnecessary, as they lead to the formation of cartels.
● Allow anyone to secure the network without the need for special equipment.
● Get rid of the proof of work and put an end to a high level of energy consumption.

Sharding: it involves the division of the current chain into a main chain (called Beacon Chain) and several smaller chains (shards). These subchain have the task to process more transactions in parallel communicating them only later to the main chain that acts as a security checkpoint.

Eth2.0 Objectives:

● Reduce network complexity.
● Be constantly online (invulnerability to DDoS attacks) in the different instances (shards) of the network and when a very large portion of the nodes goes offline.
● Create and select different components to ensure resistance to attacks by quantum computers and to ensure that these components can be easily replaced (when necessary) by other quantum-resistant counterparts.
● Allow even a notebook to participate in the consensus of the network.
● Adopt a design that encourages a large number of people to validate the transactions of the network, thus achieving greater decentralization of the system.

Technical specifications

The update (the term, as we will see later, is not suitable) to Ethereum 2.0 is a complex and articulated project that requires several interventions deferred over time, for this reason it can only be divided into several phases. We must specify that the term "update" is not formally correct: Eth2.0/Serenity is the creation of a new network, a new Ethereum. There will be no fork but the update to Serenity will be done by migrating ETHs from the current chain to Ethereum 2.0.

Phase 0 Proof of Stake + Beacon Chain: A chain called the Beacon Chain is created using the Casper FFG consent protocol to ensure the purpose of transactions. This chain will have as its asset BETH, produced by transferring ETHs from Ethereum 1.x to the new chain. This transfer is IRREVERSIBLE.

Phase 1 Sharding without EVM [6]: has the task of testing the consensus between the shard and the Beacon Chain; at this stage there will be no transaction in the shards. What happens is that Beacon Chain and Shards agree on what happened regardless of the events themselves.

Phase 2 EVM: This is probably the most interesting phase of Eth2.0, i.e. the time when the shards will be able to execute contracts. At this point of development there is no communication between the different shards, for example: the CryptoKitties contract will only run on Shard 1 and not on the others because they are unaware of what happens to their neighbouring shards. It is therefore correct to say that scalability is not yet fully unlocked. Also in phase 2 the EVM will be replaced by the eWASM and there will be an important change: the contracts will pay a fee (renting fee) for the data saved on the chain. This implementation should keep the chain "lean" preserving it from a huge amount of useless data, in fact all those contracts that do not pay the renting fee will see their data permanently deleted.

Phase 3 Light Client protocol: the purpose of this update is to allow users with low power devices (smart-phones, browser extensions) to independently check the execution of transactions and the status of Ethereum. [5]

Phase 4 Transactions between the various Shards: In this phase the real scalability potential of Sharding is unlocked: the shards finally become aware of the existence of their neighbours and cooperate with them. .

Phase 5 Tight Coupling: The system now becomes a set of components that cooperate in a dependent manner.

Phase 6 Super-Quadratic or Exponential Sharding: Allows for the possibility of creating shards inside other shards.

Ethereum have a testnet in March that implements phase 0, but presumably, for phase 0 + 1 it will have to wait until the end of the year.

State of development

To understand how complex it is to perform an Ethereum update, one must consider several factors. The improvement of ETH is a process divided into two phases: first we have the research carried out by teams of researchers whose task is to change the specifications of the network, introducing new ideas at the economic, cryptographic, security, scalability level, etc.. Secondly, the team responsible for the implementations comes into play, where the developers have the task of converting the new specifications into code. Consider that Ethereum is a network with a capitalization of $13 billion that companies have just begun to use to do business, so even updating a single line of code involves great responsibilities. If something goes wrong during the update processes it would be an event that would not only disadvantage Ethereum but the whole crypto world.

Technical specifications are constantly changing

As we have already pointed out, the creation of Eth2.0 is the result of the work of two teams: a research team and an implementation team. Following an idea phase guaranteed by the ideas of the researchers, the implementers have the task of translating these ideas into codes. It would seem to be a linear process that follows well-defined tracks, but it is not so: changes and upheavals in the development of the project can occur at any time (until six months ago there was no talk of a beacon chain), sometimes this involves considerable stress on the part of the implementation team that may be forced to a complete reorganization of the work done up to that moment.

In this respect, some improvements have been noticed recently: the changes in specifications and the big technical changes have decreased over time. This is a comforting fact to demonstrate that Ethereum 2.0 is moving towards a definitive form.

Finally, the various teams began to collaborate by defining the parts of the specifications that can be implemented, all while minimizing the risk of reorganization. From this derives another fundamental aspect: each time changes are made to the specifications, it is necessary to simultaneously assess the weight that will fall on the shoulders of the implementation team, which is still guaranteed the opportunity to express its vote (in favor, or not) on the approval of the modification itself.

Development varies from team to team

Implementations are written by different teams in multiple programming languages: Prysmatic Labs' Prysm client is written in GoLang, while Sigma Prime's Lighthouse client is written in Rust. As can be seen, Devs find themselves developing different parts of the specification with only one common goal: the March testnet. Although they remain focused on this common goal, what will result will be different clients (Nodes) that have not implemented the same features. This is a central issue, which we think is very interesting and which could be summarized in the lack of a leader and a standardized process.

The various development and research teams lack a key element that can coordinate them during development. There is one person who gives guidelines and one who, at the same time, takes responsibility in the event of failure in achieving the objectives. This modus operandi can also be considered in line with the idea that the development process should also take place in a decentralized manner; however, the lack of standardization and the need to define a single system, valid for all, in relation to the implementation of technology, is starting to make itself felt.

It's all about expectations

The expectations of the community, users and investors are inevitably very high, but we must always consider the degrees of difficulty that technological changes of this caliber involve. That said, what can we realistically expect in the near future?

To date, the certainties are:

● Phase 0 will be online in March 2019.
● Phase 1 will not allow to execute transactions on the network with a shard but will be used to test the link between Beacon Chain and Shard (cross-linking).
● Smart contracts will not benefit from real scalability until Phase 4. In fact, until this phase, it will be impossible for the shards to communicate with each other and express the full potential of the system.



There are no approved edits.

Table of Contents