16

Serenity

Ethereum 1.0 is the current version of Ethereum, with Berlin being the latest release, or update. The public Ethereum mainnet available today runs the Ethereum 1.0 protocol. Serenity is the name given to Ethereum version 2.0. The vision behind Ethereum 2.0 is to ultimately transition into a more scalable, performant, and secure version of Ethereum that will serve as the World Computer, which is Ethereum's original vision. The concept of a world computer was introduced with Ethereum 1.0, in which a global, decentralized network of interconnected nodes runs peer-to-peer contracts without the limitation of shutting down, or being censored or hacked. This vision started with Ethereum 1.0 and gained a lot of traction; however, challenges such as scalability, privacy, and performance somewhat hindered mass adoption. Ethereum 2.0 is expected to address these issues in pursuit of becoming a world computer.

In Chapter 11, Ethereum 101, we saw that Ethereum is being released in a number of phases, with the first version being called Frontier and with Serenity being the projected final version. Currently, we are at Metropolitan, with the latest hard fork upgrade of Ethereum being called Istanbul. All these upgrades are taking Ethereum closer to Ethereum 2.0, which is currently being built, with Phase 0 expected to be launched by late 2020.

In this chapter, we will cover Serenity, the update that will introduce Ethereum version 2.0. We will explore the theoretical foundations and understand many concepts behind the need for and development of Ethereum 2.0. In the book's bonus content pages, which we strongly encourage readers to utilize, we will also explore how Ethereum 2.0 clients can be set up. The topics that we cover are listed as follows:

• Ethereum 2.0—an overview
• Development phases
• Architecture

Before we delve into the Ethereum 2.0 architecture and other technical details, it is important to understand the vision and motivation behind its development. We'll describe these in the next section.

Ethereum 2.0—an overview

Based on the problem presented by Vitalik Buterin, an Ethereum co-founder, in 2015, it is understood that only two of the three main core properties of a blockchain can be utilized at a time. These three core properties are the following:

• Decentralization
• Scalability
• Security (or consistency)

This is known as the Scalability Trilemma and is seen as a fundamental problem that needs to be addressed before global adoption of the Ethereum blockchain.

This concept is visualized in the following diagram:

Figure 16.1: Blockchain trilemma

Intensive research is underway with Phase 0 already near release. The aim is to address this trilemma and find the right balance between all three properties, instead of compromising and only choosing two of the three.

With the release of Proof of Stake (PoS), Sharding, and ewasm, a balanced combination of all these three properties, that is, decentralization, scalability, and security (consistency) can be achieved.

Having now discussed the high-level problem facing Ethereum, we can go on to look at some fundamental elements of Ethereum 2.0, starting with some specific goals.

Goals

The major goals behind the development of Serenity can be divided into the following different dimensions:

• Reduced complexity: One of the main aims of Ethereum 2.0 is simplicity, even if there are some tradeoffs with efficiency.
• Resiliency: The goal of resiliency ensures that the liveness of the network can be maintained even in the event of major network partitions.
• Increased security: With the advent of quantum cryptography and in order to mitigate the threats faced by cryptography in the post-quantum world, it is envisaged that in Ethereum 2.0, quantum-resistant cryptography (or at least easy pluggability of quantum-resistant elements) will be introduced, so that the blockchain remains secure even in a post-quantum world.
• Increased participation: It is also expected that greater participation of validators will help with improved security and overall participation.
• Increased performance: Instead of requiring specialist hardware or high-end CPUs and GPUs for performing validation activities, in Ethereum 2.0 it is expected that validation activities will be performed by using typical consumer computers with the usual resources. With the introduction of PoS, faster block time is expected. This also results in increased performance.

Now that we have covered the main goals of Ethereum 2.0, we can dive into its more specific features.

Main features

The main features of Serenity include a switch from a Proof of Work (PoW)-based chain to a PoS-based chain, which will make the network more decentralized, efficient, and faster. Secondly, ewasm, an improved version of the Ethereum Virtual Machine (EVM) is envisaged, which will make code execution faster, hence resulting in an overall performance gain.

Another feature is sharding, which introduces the concept of shard chains and allows increased transaction throughput and immediate finality. Finally, sidechains will be used to enhance privacy, permissions, and governance.

We touched briefly earlier on the roadmap of Ethereum, and next, we describe the roadmap in detail so that readers can understand the past, present, and future of Ethereum.

Roadmap of Ethereum

In this section, we look at the roadmap of Ethereum. The following list of Ethereum's main releases shows how Ethereum has evolved over time, along with its vision of eventually achieving a world computer—a scalable, decentralized, and secure blockchain network:

• July 2015: Frontier
• March 2016: Homestead
• October 2017: Byzantium
• February 2019: Constantinople
• December 2019: Istanbul
• Late 2020: Berlin
• Late 2020: Beacon chain—Serenity Phase 0
• 2020: Shard chains—Serenity Phase 1
• 2021: Execution environments, ewasm—Serenity Phase 2
• 2022: Further scalability and improvements—Serenity Phase 3

As indicated here, the development of Ethereum 2.0 is divided into phases. In the next section, we will discuss the four major phases of Serenity development, and what is involved in each phase.

Development phases

The four phases in the development of Ethereum 2.0 are focused on various features of the blockchain.

The main work included in Phase 0 is around the management of validators and the staking mechanism. In addition, this phase also includes block proposer selection, consensus mechanism rules, and a reward/penalty mechanism.

Phase 1 includes the development of shard chains and blocks along with the cross-linking (anchoring) of shard blocks to the beacon chain (the core system chain).

Phase 1.5 also known as "the merge" is where ethereum mainnet will transit into Ethereum 2 most likely by becoming a shard chain of Ethereum 2.0.

The next stage, Phase 2, is focused on execution environment upgrades, and includes a VM upgrade to ewasm along with cross-shard communication and access to execution environments. Moreover, Phase 2 introduces the ability to run and interact with smart contracts. Currently, the specification is not final and might be subject to change.

Phase 3 is envisaged to be a continuous improvement and maintenance stage, where a complete Ethereum 2.0 chain will be running and evolving into a more mature and feature-rich blockchain.

Now, we will explain each phase and its features in detail.

Phase 0

Phase 0 is the first phase of Ethereum 2.0 development. This stage involves the creation of a core system chain called the beacon chain, which can be considered the backbone of the entire Ethereum 2.0 chain system. After Phase 0 is complete, there will be two chains in existence: the original Ethereum 1.0 chain and a new chain called the beacon chain. These chains will operate in parallel.

The Phase 0 specification and development can be further divided into multiple categories, the first of which is the beacon chain.

The beacon chain

The beacon chain is the core system chain, and manages the Casper PoS consensus mechanism for itself and all of the shard chains. It is also used to store and maintain the registry of validators. Validators are nodes that participate in the PoS consensus mechanism of Ethereum 2.0. The beacon chain has a number of features, listed as follows:

• Production of good-quality randomness, which will be used for selecting block proposers and attestation committees without bias. Currently, a RANDAO-based scheme is prominent, however other options such as BLS-based and STARK-based schemes have been considered in the past. RANDAO is a pseudorandom process that selects proposers for each slot in every epoch and rearranges the validators in the committees.
• Provision of attestation, which essentially means availability votes for a block in a shard chain. An adequate number of attestations for a shard block will result in the creation of a cross link, which provides confirmation for shard blocks in the beacon chain.
• Validator and stake management.
• Provision of validator sets (committees) for voting on proposed blocks.
• Enforcement of the consensus mechanism and the reward and penalty mechanisms.
• Serving as a central system chain where shards can write their states so that cross-shard transactions can be enabled.

In order to participate in the beacon chain, some beacon chain client (or node) software is required. We will discuss this next.

Beacon nodes

The beacon node is the primary link in the beacon chain that forms the central core of the Ethereum 2.0 blockchain. The beacon node's responsibilities include synchronization of the beacon chain with other peers. It performs attestation of blocks, and runs an RPC server to provide critical information to the validators regarding assignments and block attestation. In addition, it also handles state transition and acts as a source of randomness for the validator assignment process.

The beacon node also serves as a listener for deposit events in the Ethereum 2.0 chain, as well as creating and managing validator sets. A beacon node synchronizes with the shards and it keeps a synchronized clock with other nodes on the beacon chain to ensure the application of penalty rules (slashing). In a beacon node, various services based on the responsibilities mentioned previously are implemented. These include the blockchain service, synchronization service, operations service, Ethereum 2.0 service, public RPC server, and the P2P/networking service.

To participate in the beacon chain, a beacon chain client, or node, is required. Based on the Ethereum 2.0 specification, this client is being developed by a number of different teams. In the supplementary resources associated with this chapter, we will look at Prysm. There are, however many other teams that are developing Ethereum 2.0 clients in a variety of languages. A non-exhaustive list is presented as follows:

Client	Language	Team	GitHub
Cortex	.NET	Nethermind	https://github.com/NethermindEth/cortex
Harmony	Java	Harmony	https://github.com/harmony-dev/beacon-chain-java
Lighthouse	Rust	Sigma Prime	https://github.com/sigp/lighthouse
Lodestar	JavaScript	ChainSafe	https://github.com/ChainSafe/lodestar
Nimbus	Nim	Status	https://github.com/status-im/nimbus
Prysm	Go	Prysmatic Labs	https://github.com/prysmaticlabs/prysm
Substrate Shasper	Rust	Parity Technologies	https://github.com/paritytech/shasper
Teku	Java	PegaSys	https://github.com/PegaSysEng/teku
Trinity	Python	Ethereum Foundation	https://github.com/ethereum/trinity

By accessing this book's bonus content pages, here: https://static.packt-cdn.com/downloads/Altcoins_Ethereum_Projects_and_More_Bonus_Content.pdf, we will learn how the Ethereum 2.0 client from Prysmatic Labs can be installed and run. In addition, we will also perform some experiments to explore various features of Ethereum 2.0.

In the next section, we introduce validator nodes, which serve as block proposers and attesters on the network as part of the PoS mechanism in Ethereum 2.0. Validator nodes can be thought of in the same way as the miners in Ethereum 1.0, and are developed as per the specification finalized for Phase 0 of Ethereum 2.0.

Validator nodes

A validator node, also referred to as a validator client, actively participates in the consensus mechanism to propose blocks and provide attestations.

A user can stake a minimum of 32 ETH to get the ability to verify and attest to the validity of blocks. As validators participate in the consensus mechanism to secure the protocol, they are incentivized financially for their effort. The validators earn ether which is valid in Ethereum 2.0 (ETH 2) as a reward if their attestation is accepted.

A validator has to perform a number of configurations before they can deposit ether as a stake to become a validator. Once they are accepted, they become part of the validator registry that is stored and maintained on the beacon chain.

The first step for a node to become a validator is to generate a public/private key pair. For this purpose, the BLS12-381 curve is used, which is a new zk-SNARK curve construction.

A second private/public key pair, called the BLS withdrawal key, is also required. These withdrawal credentials are used to withdraw funds.

After this, the users have to deposit a minimum of 32 ETH (normal Ethereum 1.0 PoW chain ether) to a deposit contract. Once the deposit is made and processed, the validator is activated. At this point, it becomes part of the beacon chain's set of validators.

The key functions that a validator client performs are listed as follows:

• New block proposal
• Attestation provision for blocks proposed by other validators
• Attestation aggregation
• Connection with a trusted beacon node to listen for new validator assignments and shuffling
• Shard chain synchronization with the beacon chain

A validator is assigned a status based on its current state. It can have six statuses: deposited, pending, activated, slashed, exited, and withdrawable. Deposited status means that a validator has made a valid deposit and is registered in the beacon chain state. Pending means that the validator is eligible for activation. Activated means that the activator is active. Slashed means the validator has lost a portion of their stake, exited means the validator has exited from the validator set, and withdrawable indicates that the validator is able to withdraw funds. A withdrawable state occurs after a validator has exited and roughly 27 hours have passed. A validator can be in multiple states simultaneously—for example, a validator can be in both the active and slashed states at the same time.

Honest validator behavior is incentivized as part of the PoS mechanism, and dishonest behavior results in what is referred to as slashing. Slashing results in the removal of a validator from the validator committee (the active validator set) and a burning of a portion of its deposited funds.

Slashing serves two purposes. First, it makes it prohibitively expensive to attack Ethereum 2.0, and secondly, it encourages (enforces) the validators to actively perform their duties (functions). For example, a validator going offline when it is supposed to be actively participating in the consensus is penalized for its inactivity.

There are three scenarios when slashing can occur. First is proposer slashing, which is when a validator signs two different blocks on the beacon chain in the same epoch. The second case where slashing can occur is when a validator signs two conflicting attestations. Thirdly, slashing can also occur when a validator, when attesting, signs an attestation that surrounds another attestation. In other words, it means that this scenario occurs when a validator first attests to one version of the chain and then later attests another version of the chain, resulting in confusion as to which chain the validator actually supports.

When any of the three preceding scenarios occur, the offending node is reported by a whistleblowing validator. The whistleblowing node creates a message containing evidence of the offense, sends it to a proposer to include it in a block, and propagates it on the network. In Phase 0, the total slashing reward is taken by the proposer and the whistleblowing validator does not get any reward. This has the potential to change in Phase 1, where both actors might be rewarded.

Also, remember that penalization and slashing are two related but different concepts. Penalization results in a decrease in the balance of a validator as result of, for example, being inactive or going offline. On the other hand, slashing results in a forceful exit from the beacon chain along with the responsible validator's deposit being penalized in every epoch for as long as it has to wait for its turn in the exit queue to leave the chain.

Slashing and penalty calculations are based on several factors with various variables such as the length of validator inactivity and the type of the offense that triggered the slashing. Moreover, a penalty is applied at various points in the slashing process. For example, a minimum penalty of effective balance of slashed validator / 32 is applied when a validator proposer includes the message reporting the offence from the whistleblower in a block. After that, at the beginning of each epoch a penalty calculated as 3 * base reward is applied. Another penalty is applied between the time of inclusion of the whistleblowing message in a block, and the time when the slashed validator is able to withdraw.

Earning rewards by staking ether in the deposit contract also depends on several factors. A simple example is that if someone stakes 32 ETH with a current price of, for example, USD 240 per ETH, with validator uptime of 80%, the annual interest earned will be around 8%. The base reward is calculated as per the following formula from the Phase 0 specification:

base_reward = effective_balance * BASE_REWARD_FACTOR / integer_squareroot(total_balance) / BASE_REWARDS_PER_EPOCH

Here, BASE_REWARD_FACTOR is set at the default value of 64, and the BASE_REWARDS_PER_EPOCH value is 4. The effective balance is used to calculate the proportion of rewards and penalties applied to a validator. It is based on the validator's balance and the previous effective balance. The maximum effective balance can always be only up to 32 ETH. Even if the actual balance is 1000 ETH, the effective balance will still be 32 ETH.

There are various calculators available online that can calculate the expected return of staking ether (from Ethereum 1.0) in the Ethereum 2.0 network.

As these sections have demonstrated, in Ethereum 2.0 Phase 0 there are three main components: the beacon chain, beacon nodes, and validator nodes. In the next section, we highlight some key differences between a beacon node and a validator node.

Beacon and validator node comparison

The key differences between the beacon and validator nodes are listed in the following table. The architecture of Ethereum 2.0 is no longer a single node-based architecture like Ethereum, where there is only a single type of node that can perform all functions, such as mining and securing the chain.

In Ethereum 2.0, there are two distinct types of nodes: beacon chain nodes and validator nodes. The key differences between these node types are presented in the following table.

Feature	Beacon nodes	Validator nodes
Networking	Connected via P2P to other beacon nodes	Dedicated connection with a single beacon node
Staking	No staking requirements to participate in the network	Ether staking required to participate in the network
Block creation	Attest validations and propagate blocks across the beacon chain	Propose and sign blocks
Operation	Read	Write

Being a PoS-based blockchain, Ethereum 2.0 must have the ability to take deposits from users as a stake. This requirement in Phase 0 is addressed by a deposit contract. We will explain the features of a deposit contract next.

Deposit contracts

Deposit contracts were created on the Ethereum 1.0 chain. This kind of smart contract is used for depositing ETH on the beacon chain. Currently, there is a test deposit contract written in Vyper available on the Goerli testnet for curious readers, which can be accessed at the following address:

https://goerli.etherscan.io/address/0x0F0F0fc0530007361933EaB5DB97d09aCDD6C1c8#code

An event is emitted every time a deposit is made. This event is composed of several fields as shown here:

DepositEvent (bytes pubkey, bytes withdrawal_credentials, bytes amount, bytes signature, bytes index)

This log is consumed by the beacon chain.

Another important feature of the Ethereum 2.0 beacon chain is a new rule for deciding which chain to choose in the case of a fork. We will discuss that next.

Fork choice

The fork choice rule in Ethereum 2.0 is called Latest Message Driven Greediest Heaviest Observed SubTree, (or LMD GHOST).

Remember we discussed the Greediest Heaviest Observed SubTree rule, GHOST, in the context of Ethereum mining in Chapter 11, Ethereum 101. LMD GHOST is a variant of GHOST that was implemented in Ethereum with some modifications. More information can also be found at https://ethereum.org/en/whitepaper/#modified-ghost-implementation.

LMD GHOST governs a fork-handling mechanism to ensure that in the case of a fork, the correct and honest chain is automatically chosen. As a general rule, the honest chain is the one that has the most attestations and stake (weight). In the event of a fork, the clients will use this fork choice rule to select the correct, honest chain. Forks may occur due to the actions of colluding participants, however, beacon chains' random selection of validators mitigates that to some extent, because validators do not know in advance when they will be selected.

Another mechanism relevant to chain integrity is finality, which is the assurance that a block, once finalized, will not revert back. To achieve this, a mechanism called Casper the friendly finality gadget (Casper FFG) is implemented in Ethereum 2.0.

In the next section, we introduce another important element that deals with all the networking requirements of Ethereum 2.0: the P2P interface.

P2P interface (networking)

This element deals with the networking interfaces and protocols for the Ethereum 2.0 blockchain. There are three main dimensions addressed in the development of Ethereum P2P/networking elements:

• The gossip domain
• The discovery domain
• The request/response domain

The networking specification also covers the essentials of a test network where multiple clients can run simultaneously, that is, the interoperability of the test network and mainnet launch.

In order to achieve interoperability all Ethereum 2.0 client implementations must support the TCP libp2p transport. This must also be enabled for both incoming and outgoing connections.

Implementors may choose not to implement an IPv4 addressing scheme for the mainnet. Ethereum 2.0 may implement an inbound connectivity feature only for IPv6, but the clients must support both inbound and outbound connections for both IPv4 and IPv6 addresses.

Some further products of Phase 0 development are introduced next.

ETH 2

ETH 2 is the new digital currency for Ethereum 2.0, which is a new asset of validator nodes (stakers) in the consensus mechanism. It will be created as an incentive (reward) for validating the beacon chain and shards, and by purchasing it via the deposit contract using ETH 1 currency (also called a registration contract).

ETH 1 is expected to transition into ETH 2 completely, but ETH 1 may still exist alongside ETH 2. It is speculated that ETH 1 may become a shard chain for the beacon chain, or ETH 1 could be left alone and only new shard chains will be created. Also, due to the current vast ecosystem built around Ethereum 1.0 and the technical complexities of the transition to Ethereum 2.0 as a shard chain, it may result in some insuperable challenges, which could lead to Ethereum 1.0 being left as it is.

Simple Serialize

Simple Serialize, or SSZ for short, is the algorithm standard for providing serialization abilities for all data structures in Ethereum 2.0 client software. SSZ has support for many data types such as Boolean (bool), unsigned integers (uint8, uint16, uint32, and uint64), slices, arrays, structs, and pointers.

BLS cryptography

BLS cryptography (BLS12-381) is used extensively in Ethereum 2.0 to provide security and efficient verification of digital signatures. BLS, short for Boneh-Lynn-Shacham signatures, allows the aggregation of cryptographic signatures to contribute to the scalability of the network. BLS is used by validator clients to sign messages, which are then aggregated and eventually verified efficiently in the distributed network, thus increasing the overall efficiency of the network.

This completes our introduction to phase 0 of Ethereum 2.0. In the next section, we explore features of Phase 1.

Phase 1

The main feature of Phase 1 is shard chains. The specification is not fully complete yet, however, most of the details are complete.

Shard chains

Shard chains are the main scalability feature that will initially consist of 64 chains and will grow over time as required. The main design goals in this phase revolve around creation, validation, and consensus of the data of shard chains. The state of each shard chain will be written periodically to the beacon chain. This is called a crosslink, which is a set of signatures from a set of validators (the committee) that has attested to a block in a shard chain. This crosslink is included in the beacon chain representing the attestation of blocks of shard chains. The state is represented by the combined data Merkle root of the shard chain. The idea behind this mechanism is that when a block in the beacon chain is finalized, the corresponding block in the shard chain is also considered final. This way other shards know that what the finalized block is and they can rely on that for further transactions across different shards (cross-shard transactions).

The agreement on each block's content is achieved by utilizing randomly selected shard validators by the beacon chain for each shard at each slot. A slot is defined as a period of time in which a block proposer proposes a block for attestation. A slot may be empty or "filled" with attested blocks. Slots are 12 seconds apart. A relevant concept is that of an epoch, which represents a number of slots (currently 32) after which validators are reshuffled in their validator sets (committees).

The following diagram presents a process overview showing shards, the beacon chain, validators, the link with ETH 1, and the phases of Ethereum 2.0:

Figure 16.2: Ethereum 2.0 overall view

In Phase 1, there will be enhancements made to the Phase 0 design of the beacon chain to allow shard chains.

Transitioning from Ethereum 1 to Ethereum 2

Eventually, the aim is to transition completely into Ethereum 2.0. There are two options under discussion currently to achieve that: stateless clients and merging.

Stateless clients

This is a proposal where Ethereum 1.0 clients will be transitioned into stateless clients. These rely on proofs from peers rather than stored copies of the chain state to verify blocks. The core idea behind this proposal is to trim the existing chain into digital receipts that prove the authenticity of the PoW transactions. This option appears to be gaining more traction.

Merging

This is a proposal where the Ethereum 1.0 chain will be merged into the Ethereum 2.0 beacon chain "as is". The idea behind this proposal is to build interoperability bridges between ETH 1 and ETH 2 until Ethereum 2.0 is fully developed.

A major feature of any blockchain is that it can run transactions and smart contracts. This feature will come with Phase 2 of Ethereum 2.0, which is responsible for state execution.

Phase 2

Phase 2 is mainly concerned with state execution. Phase 2 will have the ability to run smart contracts and transactions on shard chains. In addition, constructs such as accounts will also be available with this phase. Each shard chain in Phase 2 will have its own ewasm EVM, which will allow for faster running of smart contracts.

There is also a concept of the execution environment, which allows shards in Phase 2 to build custom environments for specific use cases. This gives tremendous flexibility to developers, as it allows them to build fully customized execution environments. It is quite early to say how exactly these execution environments will be designed because of the rapidly evolving research in this space.

Phase 2 of Ethereum 2.0 will also focus on further scalability and continuous improvement of the protocol. There are many ideas, including zk-STARKS, ZK-Rollups, and commit chains.

We will discuss scalability solutions in detail in Chapter 21, Scalability and Other Challenges.

Phase 3

After Phase 2, further improvement and updates will continue. We can call this Phase 3.

Next, let's have a look at the specific high-level architecture of Ethereum 2.0.

Architecture

The following diagram shows the high-level architecture of Ethereum 2.0 clients and how they work together with the beacon chain. After completing the Running Ethereum 2.0 clients exercise in the book's online content repository, we'll be able to see the architecture shown in the following diagram in reality:

Figure 16.3: Ethereum 2.0 high-level architecture (based on Prysmatic clients and spec for Phase 0)

The preceding diagram shows a validator node and a beacon node with their different services running on different ports. The structure of a beacon block is also shown on the left-hand side, including the fields of the block header and body as per the Phase 0 specifications.

Now that we have a good understanding of Ethereum 2.0's design goals, its phases, and architecture, you can put your new knowledge into practice. Doing so is out of the scope of this chapter, but by accessing this book's bonus content pages here: https://static.packt-cdn.com/downloads/Altcoins_Ethereum_Projects_and_More_Bonus_Content.pdf, you can follow a start-to-finish demonstration of how an Ethereum 2.0 client can be installed and run on the Onyx testnet!

Summary

In this chapter, we looked at Ethereum 2.0. We explored various aspects of its architecture and the overall vision behind the development of Ethereum 2.0.

Currently, Ethereum 2.0 is under heavy development and only Phase 0, the beacon chain, is expected to launch in 2020. As the design of Phase 0 is finalized, nothing much is expected to change with the production release of the beacon chain. The techniques and examples used in this chapter can be used for the production chain too, once it's available.

We have also demonstrated in this book's bonus content pages, which we strongly encourage the reader to make use of, how to run Ethereum 2.0 beacon and validator clients. Remember that as the development of Ethereum 2.0 is rapidly evolving, some of the steps mentioned may change slightly, or the testnet that we used may be retracted. However, the steps are essentially the same; you may just have to slightly tweak the commands and run it on a different testnet. Readers are encouraged to keep an eye on https://prylabs.net for further developments.

In the next chapter, we'll introduce Hyperledger, which is a very active and popular blockchain project upon which multiple blockchain projects are being built.