Serenity or Ethereum 2.0 is the long-awaited and even longer movement of the Ethereum network from the work test (PoW) to the participation test (PoS), along with some huge improvements on the scalability side. An important milestone in this has been the freezing of the specifications of the first phase of development and now we can begin to see the results of the incredible amount of hard work that was put into research.
When I started looking at Serenity (or Ethereum 2.0) the first thing that made me feel lost was the abundance of completely new terms. What the heck is a cross-link? Is it a slot, a block? [Spoiler, no, it isn’t]. Is a certifier the same as a validator?
The following list tries to describe the most used terms in the Ethereum 2.0 universe for the slightly technical user. Keep in mind that this is not an exhaustive list, but focuses on the most prominent details you might have questions about.
If you notice any inconsistency or wish to contact us for any reason, contact us via Twitter or our new Discord channel.
Among its characteristics, they emphasize that it is a chain for the governance of everything, it works with a proof of participation and includes blocks called Beacon. It is the consensus layer for everything: it manages validators, applies rewards and penalties, it serves as an anchor point for the fragments through cross-links.
There are 1024 of them, semi-independent chains, including fragment blocks. Periodically the state of the fragment blocks is recorded in the beacon chain through cross-links. Once a block in the beacon chain is finalized, the blocks of fragments referred to in the included cross-links are considered finalized and each fragment has a committee of validators that certify blocks.
It is a summary of the state of the fragment and only reference of the fragments in the Beacon chain.
Period of time in which a block proposer proposes a block for certification. The slots may be empty or they may be full of witnessed blocks.
It is a series of slots (currently 64) after which the validators are reorganized into committees.
They are users who have deposited 32 ETH in the validator deposit contract and execute a validator node. They may be inactive (not yet running as a real validator), active (validate), pending (choose to become a validator but stuck in the entry queue) and exit (no longer want to validate and stuck in the exit queue ).
They are random validators chosen by the Beacon Chain to propose blocks for validation/certification. There will be a block-by-slot proposer for the Beacon Chain and one proposer per slot for each of the fragments.
They are votes regarding the validity of a block (Beacon and fragment).
Random groups of validators chosen by the Beacon Chain to certify the validity of the blocks (Beacon and fragment). The objective is a minimum of 128 validators per committee.
ETH2 or BETH
It is the base currency of the Beacon Chain and will be obtained initially from the rewards and blocking ETH1 in the validator’s deposit contract.
Validator Deposit Contract
Smart contract in the PoW chain (in our case, Ethereum Mainnet). Once ETH1 funds are blocked in this smart contract and an event log is issued that the beacon chain should read and the same amount of ETH2 should be allocated to the account, now considered a validator. This mechanism could change in the future. Until phase 2 ends, the transfer of ETH1 to ETH2 is a one-way street, ETH1 cannot be retrieved, but there is an escape hatch to sell its stake once transfers between validators are possible.
Phases of Ethereum 2.0
Phase 0 – Beacon chain
It includes the management of validators and participations as well as how to organize and elect committees and proponents. It is also responsible for applying consensus rules. It can be rewarding and penalizing.
Phase 1 – Fragments
Oriented to the construction of chains and fragment blocks, anchoring (cross-linking) of fragment blocks to the beacon chain and the ability to make BETH transfers between validators (this could happen before since technically it is not linked to fragmentation work).
Phase 2 – runtime environments
An ewasm-based virtual machine for the execution of execution environments. Each fragment has access to all runtime environments. It has the capacity to carry out transactions within execution environments as well as to execute and interact with smart contracts. It has communication between fragments.