Chapter 15. Conclusions

You’ve finally reached the end of this book. I’m sure you’ve learned a lot, and you should now feel equipped to continue the journey by yourself. Don’t rest on your laurels, though. Both Ethereum and the landscape around it are constantly changing.

Before I say goodbye, I’d like to give you a heads-up on topics you should particularly keep an eye on if you’re considering building your own Dapp. I’d also like to briefly present you with some alternative forks of mainstream Ethereum, in case you have needs the mainstream implementation can’t fulfill. Finally, I’ll give you a quick view of the current blockchain landscape, in case you want to explore alternative blockchain offerings.

Before I start, I’d like to be clear on one thing: this chapter is only meant to give you ideas for further learning, so I’m not aiming to cover any topic in depth. I’ll only try to stimulate your mind and enthusiasm.

15.1. Evolution of Ethereum

As I’ve repeated various times throughout the book, Ethereum is continuously evolving, and at this stage many of its building blocks are still in flux, such as the EVM, the Solidity language, the Web3.js library, the consensus algorithm, and some elements of the ecosystem. I’ll give you an idea of how these elements are likely to evolve, but I strongly recommend you keep updated through online resources.

15.1.1. Evolution of EVM

The current implementation of the EVM supports dynamic jumps (which means the address is supplied as an argument on the stack), but they make control-flow and data-flow analysis complicated and slow. Ethereum Improvement Proposal 615^[1] aims at a partial redesign of the EVM (version 1.5) targeted at introducing subroutines (through static jumps and return) and disallowing dynamic jumps and other misuses of the stack. This would bring several benefits, including better compilation from Solidity, faster interpretation, improved optimization to native code, and better static analysis and formal verification tools. It would also allow better compilation from and to eWASM.

¹

See EIPs/eip-615.md on GitHub at http://mng.bz/9OMq.

If you’re wondering what eWASM is, WASM stands for WebAssembly (https://webassembly.org/), and it’s a new binary instruction format that W3C is designing as an open standard. This standard specifies an instruction set, an intermediate source format (WAST), and a binary encoded format (WASM). Most mainstream JavaScript engines, including those behind Node.js, Chrome, Edge, and Firefox, will provide native support for WebAssembly. eWASM (https://github.com/ewasm) is a subset of WASM designed to support Ethereum smart contracts. The ultimate objective is, among other benefits, to provide a library and instructions to write Ethereum contracts in C and in Rust.

15.1.2. Evolution of Solidity

If you’re among the MEAP readers of this book, you might have noticed Solidity has been changing frequently since you started playing with it. The developers of Solidity have often introduced new keywords and deprecated others. This continuous evolution is making Solidity a more robust language, especially from a security point of view. The biggest change that’s taking place, and you should be aware of, is the deprecation of send() and call(), so I strongly encourage you to use transfer() instead.

15.1.3. Evolution of Web3.js

Although throughout the book I’ve been referencing Web3.js version 0.24 because it works reliably with all the current tools, you should try to move to version 1.0 as soon as you can. This is still in beta at the time of writing, but the candidate release is coming soon.

15.1.4. Evolution of the consensus algorithm

MAINNET, the public production network, is still based on the Proof of Work (PoW) consensus algorithm. As you might recall, the PoW algorithm is designed so that many miners are competing to append a new block to the blockchain by simultaneously trying to solve a cryptographic puzzle. They keep re-hashing the proposed new block until they find a nonce that generates a correct hash (for example, a hash with many leading zeros). The hashing process is CPU-intensive and therefore energy-intensive. The simultaneous re-hashing of a new block performed trillions of times per second throughout the Ethereum network has been widely blamed for being energy-wasteful. Developers are experimenting with a couple of alternative consensus algorithms to overcome this issue, namely Proof of Stake (PoS) and Proof of Authority (PoA).

Proof of Stake

The Proof of Stake algorithm^[2] is designed so that only one miner has the right to append a new block during a certain time slot. A new block is consequently processed only once every few seconds throughout the network, rather than trillions of times per second, which eliminates the problem of electricity consumption. As you can imagine, the term “miner” no longer applies under this algorithm: candidates for appending blocks are called validators instead, as shown in figure 15.1.

²

See “Proof of Stake FAQs” on the Ethereum wiki on GitHub at http://mng.bz/jO48.

Figure 15.1. PoS versus PoW. Whereas under PoW, many miners perform work (and consume electricity) simultaneously to append a block, under PoS only one node, called a validator, proposes a new block during a time slot.

Validators submit a deposit in Ether, which represents their stake in the infrastructure. The chosen validator, selected through a randomizer or round-robin function weighted on the stake, proposes a new block. Then, depending on the specific implementation of the PoS algorithm, the validator submits the proposed block to several secondary validators for approval. They vote on the block (the vote might be weighted on their stake) and, if the outcome is positive, the block is appended to the blockchain and the validator is rewarded in Ether. On the other hand, if the block is found to be incorrect, the initial (main) validator might get blacklisted and lose their deposit. Also, secondary validators are encouraged to be honest: if their vote diverges too much from that of their peers, they might get penalized and lose some of their deposit, as you can see in figure 15.2.

The PoS algorithm, with its incentives and disincentives, might provide various benefits, such as reductions in dependency of the network on advanced hardware, risk of centralized processing by a few miners, and likelihood of a 51% attack (which would become much costlier). The project name for the PoS algorithm is called Casper, and the project released a test network in January 2018.

Figure 15.2. PoS algorithm. First, validators submit a deposit. Then the selected validator proposes a new block and submits it to secondary validators for approval. If they score the block as correct, it’s appended to the blockchain. The main validator or secondary validators might get penalized in Ether if they’re found to be dishonest.

Proof of Authority

Many practitioners and researchers have criticized the nature of PoS’s incentives for being potentially unbalanced because they don’t take into account the total holdings of each validator. A state-sponsored validator, for example, might have committed an amount of Ether considered large by the designers of the algorithm. But if that amount is relatively small with respect to the value of their total assets (including cryptocurrency and conventional assets), they might not be discouraged from acting dishonestly.

Proof of Authority^[3] is an alternative form of consensus algorithm that is still based on a pool of validators, but in this case each validator puts at stake their reputation rather than their Ether. Nodes that want to take part in the validators pool apply through a formal identification process: they disclose their real identity, which is verified through the same checks a conventional notary would perform. Once a node has been approved as a validator, it becomes an Authority (hence the name of the algorithm). The idea is that linking the block verification process to the node’s reputation rather than to the perceived value of their deposit is more robust, as shown in figure 15.3.

³

See the Wikipedia “Proof-of-Authority” page at https://en.wikipedia.org/wiki/Proof-of-authority.

Figure 15.3. PoA versus PoS. When a malicious node loses their Ether deposit under PoS, their sponsor can set up a new node and continue with malicious behavior. Under PoA, once an authority has been detected as malicious, their sponsor (and all associated identities) is prevented from reentering the network.

Currently, two public test networks support different implementations of PoA: Rinkeby and Kovan. In August 2018, Microsoft released Ethereum PoA on Azure, targeting private and consortium permissioned networks. (See section 15.2 for more details on permissioned networks.)

15.1.5. Evolution of the ecosystem

Many of the components of the Ethereum ecosystem I presented in chapter 9 are evolving. For example, on the ENS website (https://ens.domains/), you can find a roadmap that indicates the production ENS registrar, currently based on a commit–reveal auction, will be replaced in the next few months with a simplified version. Also, the Swarm team has published a roadmap^[4] for the future development of the decentralized file system. A more dramatic evolution is that of Zeppelin. What started as an open source Ethereum smart contract library is becoming ZeppelinOS (https://zeppelinos.org/), a full-blown operating system for smart contracts.

⁴

See the Swarm “Roadmap” on GitHub at https://github.com/ethersphere/swarm/wiki/roadmap.

15.2. Alternative Ethereum implementations

Although you might have been fascinated by the technology, if you work in an enterprise, you might think Ethereum would be difficult to adopt. One good reason is that it doesn’t offer out of the box three features most enterprise applications require: scalability, permissioning, and data privacy. The Enterprise Ethereum Alliance is an organization trying to extend the public Ethereum implementation with such features.

15.2.1. Enterprise Ethereum Alliance

The Enterprise Ethereum Alliance (EEA) (https://entethalliance.org/) is a nonprofit consortium of around 500 companies that formed in March 2017 from a core of 30 founding members, including technology corporations (Microsoft, INTEL), research institutes (Toyota Research Institute), consultancies (Deloitte, Accenture, Samsung SDS), and financial institutions (Banco Santander, ING). The mission of the consortium is to propose and drive a roadmap for enterprise features and requirements; to shape a governance model for licensing around the open source technology; and to provide businesses with resources to help them learn Ethereum and address industry use cases that can take advantage of the technology.

The EEA has published the Enterprise Ethereum Architecture Stack (EEAS), which presents a standardized view of the Enterprise Ethereum ecosystem, from the network layer to the application layer. This is illustrated in table 15.1, which compares the public Ethereum building blocks with the corresponding Enterprise Ethereum ones. (A more comprehensive view is available in the official documentation.)

Table 15.1. Public Ethereum versus Enterprise Ethereum building blocks

Level	Public Ethereum	Enterprise Ethereum
Permissioning and credentials	Key management	Permissioning and authentication
Integration and deployment tools	Integration libraries	Enterprise management systems
Privacy	On-chain	Private transactions and off-chain transactions
Storage	On-chain public state and storage; off-chain storage	On-chain private state
Execution	EVM	Trusted execution
Consensus	Public consensus	Private consensus
Network	DevP2P	Enterprise P2P

The first version of the Enterprise Ethereum Client Specification (EECS), detailing extensions to the public Ethereum blockchain to support permissioning, privacy, and scalability required for enterprise deployments, was published in May 2018, and you can download it from the EEA website. The objective of this specification, whose broad requirements are summarized in table 15.2, is to serve as a flexible standard that can allow different vendor implementations. For example, the specification defines various levels of privacy, identified with A, B, and C, that depend on the requirements for connectivity between nodes, permissioning, and transaction privacy. The vendor can decide which level to target and gets certified accordingly.

Table 15.2. Broad requirements of EECS

Requirement	Description
Permissioning	A blockchain system is defined as permissioned when its network isn’t public, but its nodes are owned by a restricted group of known participants.
Privacy	The content of a transaction should be visible only to the parties involved in the transaction.
Scalability	The performance of the blockchain infrastructure shouldn’t degrade with an increasing number of transactions, and it should ideally be equivalent to that of major enterprise systems, such as those handling credit card transactions.

15.2.2. Quorum

One of the first Enterprise Ethereum implementations is Quorum (www.jpmorgan.com/global/Quorum). This is a fork of Ethereum that two members of the EEA—AMIS (a joint venture of Taiwanese financial institutions) and the bank JP Morgan—created in 2016. Quorum extends a shared private Ethereum network with a constellation network that handles permissioning and data privacy, as you can see in figure 15.4. When a transaction takes place between two or more participants, the constellation network deploys the relevant smart contract only across the members of the transaction. The content of the transaction is encrypted and stored off-chain by a transaction manager, and a hash is stored on the shared Ethereum blockchain.

Figure 15.4. A constellation network allows Quorum to handle permissioning and privacy. A smart contract is deployed only across the parties involved in a transaction; the transaction is encrypted and stored off-chain, and its hash is stored on the shared Ethereum blockchain.

Quorum has been one of the first Ethereum-based platforms to

• take advantage of geth’s pluggable consensus interface to allow a configurable consensus algorithm.
• use zk-SNARKs’ cryptographic privacy technology to provide zero-knowledge verification of smart contract transactions, which means verification of the correctness of the execution of a transaction without learning what has been computed. The project’s participants have used this technology to build the zero-knowledge security layer (ZSL), which provides Quorum the ability to transfer digital assets on the blockchain without revealing any information about the sender and recipient assets themselves, therefore guaranteeing complete privacy.

Note

zk-SNARKs is the technology that makes ZCash a truly anonymous cryptocurrency, contrary to Bitcoin, whose transactions can be traced to their owner.

15.3. Beyond the Ethereum blockchain

As you know, blockchain technology is well suited to solving problems related to proving ownership and traceability of assets. But as you learned earlier, public blockchains like Ethereum might not be suitable for enterprise applications designed to solve these problems because of their lack of focus on enterprise needs, such as those listed in table 15.2: permissioning, privacy, and scalability. Although the EEA is trying to fit the Ethereum blockchain to such requirements with various extensions (Quorum is one such example), other organizations have decided to take a completely different approach. Vendors agree that a decentralized database would be the core component of any solution, but they disagree on many implementation aspects of an architecture:

• Decentralized database technology—This isn’t necessarily based on a blockchain structure, so the industry has come up with the more general term of distributed ledger technology (DLT).
• Permissioning—Vendors agree that a distributed ledger can be accessed securely and with acceptable scalability only through a restricted network of known participants.
• Consensus—Consensus in the blockchain space has evolved from PoW, based on a large group of anonymous miners processing the same transactions simultaneously, to PoS, based on a smaller group of participants that have submitted a deposit and process different sets of transactions in a coordinated fashion, to PoA, based on a limited set of known participants. The commonality among these approaches is they involve fundamentally two network roles: transaction submitters (any node) and validators (or miners). Consensus in a distributed ledger, on the other hand, might involve a more complex interaction among many roles to provide better scalability without compromising the integrity of the stored data.
• Cryptocurrency—The consensus algorithm of distributed ledgers not based on a blockchain structure isn’t based on PoW or PoS, so cryptocurrency isn’t needed, but some platforms still allow the generation of cryptocurrency or tokens to facilitate the exchange of monetary value, when needed.

Two distributed ledger initiatives that have gathered considerable traction are Hyperledger and Corda. I’ll briefly sketch what they offer so you can get a better idea of what’s happening with alternative blockchain-based distributed ledgers.

15.3.1. Hyperledger

Around December 2015, the Linux foundation started a project called Hyperledger, whose strategic objective is to stimulate cross-industry collaboration through the development of distributed ledgers. Various distributed ledger frameworks have been tested under this successful project, sponsored by around 250 member organizations that provide funding and technical expertise. Two examples are Hyperledger Burrow, which includes its own implementation of the Ethereum Virtual Machine, and Hyperledger Iroha, whose focus is on mobile applications.

Hyperledger Fabric (www.hyperledger.org/projects/fabric), probably the most popular among the Hyperledger projects, was started with the objective of building a framework for enterprise blockchain applications. Its codebase was seeded with code developed by IBM, Digital Asset, and Blockstream during a hackathon that had taken place a few months earlier. Hyperledger Fabric is based on blockchain technology, but it’s designed on an open plug-and-play framework that allows you to change and customize many components of the architecture and adapt the platform to many industry use cases. For example, the consensus algorithm is pluggable by design, and you can write smart contracts in a variety of mainstream languages, such as Java, Java-Script, and Go. If you have time, the official documentation (https://hyperledger-fabric.readthedocs.io) provides comprehensive information, from the high-level architecture to low-level implementation details of the platform.

Here are the main characteristics of Hyperledger Fabric that differ from traditional blockchain systems, such as Ethereum:

• Up to four roles could take part in a transaction and contribute to the consensus:^[5]

  ⁵

  See “Transaction Flow” in the Hyperledger Fabric documentation at http://mng.bz/Wadl.

  • A submitting client is a node that submits a transaction.
  • An endorser (or endorsing peer) is a node that verifies the electronic signature and endorses a transaction through an endorsing policy before it gets committed on the ledger; endorsers are generally all the parties that have to approve the transaction.
  • An orderer is a node that runs the messaging service that provides ordering and delivery guarantees, when the transaction requires it.
  • A committer (or peer) is a node that commits a transaction and holds a copy of the ledger.
• The details of a transaction are private to only the interested participants. This is achieved through channels, subnetworks that provide isolated and confidential communication only among a number of authorized participants—a little bit like a WhatsApp group.

Another interesting blockchain framework that the Hyperledger project has developed under its umbrella is Hyperledger Sawtooth,^[6] which introduces the following innovative features:

⁶

See “Hyperledger Releases Hyperledger Sawtooth 1.0,” January 30, 2018, http://mng.bz/Ee2X.

• Parallel transaction execution—Most blockchain systems can only process transactions sequentially.
• On-chain governance—Participants can actively configure their network through smart-contract–based voting.
• Ethereum support—As Hyperledger Burrow does, Sawtooth offers a compliant EVM capable of running Solidity contracts.
• Dynamic consensus—This goes beyond Fabric’s plug-in consensus design, as you can change consensus algorithms on the fly.
• Wider smart-contract language choice—On top of the languages that Fabric supports, Sawtooth also supports Python.

The Hyperledger initiative has also coordinated the development of blockchain tools such as Hyperledger Composer, focused on helping users create smart contracts, and Hyperledger Explorer, which allows users to view and analyze block and transaction information.

15.3.2. Corda

R3 is a consortium of companies formed in 2015 that has grown to around 200 members, initially mainly from the financial sector but increasingly from other industries. They started Corda in 2016 as an open source project.

The approach they took for creating Corda was different from that taken in the EEA and Hyperledger initiatives. In the first place, the technical stack is made of standard off-the-shelf parts, such as the Java Virtual Machine, relational databases, and message queues. Second, Corda achieves privacy by sharing data not among a group of participants, such as those interacting in a Hyperledger channel, but only at the level of individual transactions. Specifically, two or more nodes can share one or more facts, and each node maintains its own local copy of such facts. There’s no central database containing all facts, as illustrated in figure 15.5 and described more extensively in the official documentation.^[7] This fine level of data sharing is provided through a notary, a network role that provides transaction ordering and timestamping.

⁷

See “The ledger” in the Corda documentation at https://docs.corda.net/key-concepts-ledger.html.

Figure 15.5. How facts are shared in the Corda network. Each node maintains its own copy of its own facts, but it can share some facts with other nodes. For example, facts 1 and 5 are shared between nodes A and B; fact 4 is only visible to nodes C, D, and E, but not A and B.

As you can see, this is a domain that’s constantly evolving, and there are many different ways to solve problems. Hold tight and expect further innovation!

Summary

• The EVM is being upgraded to a more general version supporting eWASM that ultimately will be able to execute code compiled from Rust and C.
• Continuous improvements in Solidity syntax are resulting in changes such as the deprecation of send() and call() in favor of transfer().
• Web3.js version 1.0, which is in beta at the time of writing, is about to become the official version to be used across the Ethereum ecosystem. I strongly advise you to reference it as soon as it’s released.
• Some alternative Ethereum networks are based on consensus algorithms different from Proof of Work: Kovan and Rinkeby support Proof of Authority, whereas the Casper project is introducing Proof of Stake.
• An Enterprise Ethereum platform, such as Quorum, supports enterprise Dapp requirements such as scalability, permissioning, and privacy.
• Other distributed ledger platforms, such as Hyperledger or Corda, offer alternatives to Enterprise Ethereum.