Permission and Privacy For Blockchain Networks under Ethereum and Quorum

Ethereum is a general-purpose blockchain that is more suited to
describing business logic, through advanced scripts, also known as
smart contracts. Ethereum was designed with a broader vision, as a
decentralized or world computer that attempts to marry the power of the
blockchain, as a trust machine, with a Turing-complete contract engine.
Although Ethereum borrows many ideas that were initially introduced by
bitcoin, there are many divergences between the two.


The Ethereum virtual machine and smart contracts are key elements of
Ethereum, and constitute its main attraction. In Ethereum, smart
contracts represent a piece of code written in a high-level language
(Solidity, LLL, Viper) and stored as bytecode in the blockchain, in
order to run reliably in a stack-based virtual machine (Ethereum
Virtual Machine), in each node, once invoked. The interactions with
smart contract functions happen through transactions on the blockchain
network, with their payloads being executed in the Ethereum virtual
machine, and the shared blockchain state being updated accordingly.

If you are not familiar with blockchain technology reading History and Evolution of Blockchain Technology from Bitcoin article is highly recommended.

If you like to learn more Ethereum blockchain development (with Solidity programming),

• Blockchain Developer Guide- Introduction to Ethereum Blockchain Development with DApps and Ethereum VM,
• Building Ethereum Financial Applications with Java and Web3j API through Blockchain Oracles and
• Harness the Power of Distributed Storage IPFS and Swarm in Ethereum Blockchain Applications are highly recommended.

The Ethereum main network, and its corresponding test networks, are
all open for public use. All transactions made on the networks are 100%
transparent, and anybody with access to the network—which is
potentially everybody—can see and access all data.

The users of these networks don't necessarily know each other: they
are mutually distrustful parties who must assume that the other
participants in the network are dishonest. For this reason, public
blockchain networks require a way for such parties to reach an
agreement without needing to trust each other, and this is where
decentralized consensus algorithms, such as proof of work (PoW), come into the picture.

There are cases, however, where transacting parties in a network are
more trusting of each other, and where the use of a blockchain isn't
solely centered on allowing mutually distrustful parties to interact.

In this recipe, we will explore the main types of blockchain
networks available – public and private—before looking in more detail
at how blockchains can be used in business settings, and what options
are currently available for keeping data private. We will then implement
a very basic private network that makes use of certain privacy
features.

Public versus private and permissioned versus permissionless blockchains

The Ethereum main network is public, meaning anyone is free to join
and utilize the network. There are no permissions involved: not only
can users send and receive transactions, they can also take part in a
consensus, as long as they have the appropriate hardware to mine
blocks. All parties in the network are mutually distrustful, but are
incentivized to remain honest by the mechanisms involved in the PoW
consensus. This is an example of a public, permissionless network.
These networks offer high resistance to censorship and good data
persistence, but are less performant due to the decentralized nature of
consensus.

The idea of permission, when applied to blockchains, could take one of
several forms: it could be explicit, as in the case of an access
control list, or implicit, as in a requirement placed on users to
enable them to join a network. An example of a public, permissioned
blockchain, could take the form of a public proof of stake network, in
which permission to participate in the network as a validator is
granted in exchange for a deposit or stake.

Of more concern for this recipe is the idea of networks run by
companies, either for their own internal use, or as a shared resource
used by a group of companies wanting to transact. Such networks are
private: they are not open to the general public, but only to those
companies authorized to join. These are sometimes also referred to as
consortium blockchains, and as such, networks often also impose
different types of permissions for different participants. For example,
different members of the network may have read, write, or access
permissions, while another subset of members may take on the job of
validation.

Such private networks can take advantage of permissioning to be more
performant than their public and permissionless counterparts. If a set
of nodes can be trusted as validators, then consensus can be reached
more quickly. There is, however, a tradeoff: a set of permissioned
validators must be trusted to correctly and honestly validate blocks.
In the world of business, where time is money, such a tradeoff can often
be worth making.

Privacy and anonymity in Ethereum

We have so far discussed the differences between public and private
networks, where it is the network itself, and access to it, which is
either public or private. We now turn our attention to the data—both
transaction and contract data—inside a given network.

The Ethereum main network can be joined by anyone. Furthermore, all
transaction and smart contract data is public, meaning all transactions
between a to and from address can be seen by
everybody using the network. There is no way to hide these
transactions, or the addresses transacting, and as such, there's no way
for a user on Ethereum to be truly anonymous. If a way were found to
link an address with a real-world identity—either at  the present time,
or at a point in the future—then the identity of the transacting party 
would be known. This might seem obvious: on public networks, all data
is public. What is less obvious is that even in a private Ethereum
network, data within the network is visible to all participating nodes.

Other cryptocurrencies, such as Zcash, Monero, and Dash, provide
differing degrees of anonymity, and we will briefly discuss two of the
techniques for doing so in this recipe, and look at how these could be
applied to Ethereum.

Monero uses a type of digital signature called a ring signature,
which helps anonymize the transacting addresses as well as the amount
being sent. It's possible to use a similar technique in Ethereum by
using mixing services based on ring signatures, but these generally
aren't accepted as being robust and scalable methods that could be used
in an enterprise.

Zcash uses a different technique, leveraging Zero-Knowledge Succinct Non-Interactive Argument of Knowledge (zk-SNARK)
proofs. In this scheme, a user is able to prove possession of some
data without needing to reveal what the data is, and without needing to
interact with the user verifying the data. Some work has been done to
incorporate zk- SNARKs with Ethereum, though at the time of writing this
work is still experimental.

So, there is currently no reliable method to make addresses and
transactions anonymous in a guaranteed way – what about the contents of those transactions?

The contents of a transaction, as well as the code and data
associated with a smart contract, are publicly viewable and cannot be
obscured. Though a smart contract's code is compiled to bytecode, it
should not be assumed that an adversary wouldn't be able to decompile
and read the code. As such, sensitive information should neither be
hardcoded into a contract nor sent to it as part of a transaction.

What can be done, however, is to encrypt any sensitive data
off-chain before sending it to the network. Using public-key
cryptography, one method would be as follows:

The sensitive data is encrypted with the recipient's public key, which could have been published either on- or off-chain

The encrypted data is sent either to a smart contract written for
the purpose of receiving it, or in the data field of a normal
transaction
The received data is decrypted using the recipient's private key

Why are privacy and anonymity important?

If we consider the case of a private or consortium blockchain run by
a group of companies, then certain aspects of privacy are clearly
important.

For example, companies A, B, and C create a consortium blockchain.
Although the network is closed to the outside world, any transactions
between A and B are visible to company C, which could be undesirable
for a number of reasons, especially if the three companies are in
competition with each other. In addition to any business-to-business (B2B) interactions between the companies themselves, it's possible the network would involve some form of business-to-customer (B2C) interaction, meaning further types of confidentiality and privacy would be required.

Before we look in detail at this recipe's project, let's take a
look at the currently available Ethereum-based business platforms.

The Ethereum Enterprise Alliance

The Enterprise Ethereum Alliance (EEA)
is a nonprofit working group whose aim is to define an open,
standards-based architecture for business and enterprise use of
Ethereum. Group members include many large companies from the world of
software and finance, such as Microsoft, Accenture, and J.P.Morgan.
The group is currently working toward defining the Ethereum Enterprise
Architecture Stack, which itself will help guide the development of the
EEA's overall standards-based specification.

EEA's specification will help define a standard way in which
Ethereum's blockchain can be used for business purposes. However, given
the opensource nature of Ethereum's codebase, adhering to EEA's
specification won't necessarily be required: Ethereum's codebase can be
used in any way desired.

Ethereum's licensing

According to Ethereum Foundation, different parts of the Ethereum
technology stack are licensed – or will be licensed—in different ways.

The core parts of the stack, including the consensus engine,
networking code, and supporting libraries, haven't yet been licensed,
but are expected to be covered by either the MIT, MPL, or LGPL license.
It's important to understand that the first of these is a permissive
license, while the latter two are more restrictive, and restrict a
user's ability to distribute any modifications under commercial terms,
therefore potentially restricting how businesses can use the code.

Regardless of the potential future restrictions that may appear
once licensing is confirmed, several enterprise-centric implementations
of Ethereum have already been created, with two such implementations
being Quorum, created by J.P.Morgan, and Monax. Later in the recipe we
will be discussing and implementing a project based on Quorum.

Blockchain-as-a-Service

Blockchain-as-a-Service (BaaS),
is a service that allows customers to create and run their own client
nodes on popular public blockchain networks, or to create their own
private networks for their own use and testing. The provisioned
services are based in the cloud, and are analogous to the Software-as-a-Service (SaaS) model. Several of the large cloud computing providers are now offering BaaS, such as the following:

- Microsoft Azure enables users to quickly deploy and manage
applications in the cloud, and has templates available for Ethereum,
Hyperledger, and R3's Corda.
- AWS Blockchain Templates is a very similar offering, and again
provides templates for Ethereum and Hyperledger. Further services are
offered by IBM, HP, and Oracle, all along the same lines.

Quorum

Quorum (https://www.jpmorgan.com/global/Quorum) is an
enterprise-focused fork of the Ethereum codebase, and offers a private
blockchain infrastructure aimed specifically at financial use cases. It
was created by J.P.Morgan, and claims to address three of the topics
that would make a public blockchain network unsuitable for business
use.

Privacy, of both transaction and contract data , Higher performance and throughput Permission and governance.

Privacy

To achieve its headline feature of making transactions and
contract data private, Quorum builds on Ethereum's existing transaction
model, rather than completely redefining it.

Public transactions and public contracts are visible to everyone on
the network, and make use of Ethereum's existing infrastructure—Quorum
doesn't implement anything different in this respect. As well as these
public transactions, Quorum offers the ability to mark transactions as
private, making them visible only to the intended recipients.

This privacy is achieved using public-key cryptography, specifically
by setting the recipient's public key in a new, Quorum-specific
transaction parameter, privateFor. This allows the transaction to be
encrypted, and therefore read-only by the owner of the private key.

Higher performance and throughput

Private and consortium blockchains are only open to certain
authorized parties, rather than completely open to the public. As a
consequence, there is little need for the consensus algorithms that are
usually used between distrustful parties, namely PoW in the case of
the Ethereum main network.

Quorum ultimately aims to offer pluggable and changeable consensus algorithms, and currently there are two to choose from:

Raft-based consensus: This provides a much
faster block time—in the order of milliseconds as opposed to seconds—as
well as transaction finality, meaning once a transaction is placed
into a block, there comes a point where it is impossible to remove it. A
further difference from PoW is that this mechanism only creates blocks
when there are transactions ready to go into them. It doesn't create
empty blocks in the way that the Ethereum main network does.

Istanbul Byzantine fault-tolerance: This is a PBFT-inspired algorithm that again includes short block times and transaction finality.

Permission and governance

The third of Quorum's headline features is its ability to
permission only chosen nodes to join a given network. This is achieved
by each node in the network that has a whitelist specifying the remote
nodes that are permitted for both inbound and outbound connections. We
will later look in detail at a practical implementation of this.

The Quorum client

At a high level, a Quorum client consists of the following components:

Quorum Node: This is based on the Ethereum Geth client
Constellation: This is a general-purpose system for submitting information in a secure way, and is itself composed of Transaction Manager and Enclave subcomponents.

Quorum Node
Quorum Node is based on Ethereum's Geth client, but with a series of changes:
Ethereum's PoW consensus algorithm has been replaced. There is
currently a choice of two alternatives, which were briefly discussed
previously.
The P2P protocol has been modified to allow only authorized nodes to connect, preventing connections from the wider public.
The way Ethereum maintains and records its state has been
changed to allow public and private states to be handled separately in
two different Patricia Merkle trees.
Block validation has been altered to handle private transactions as well as public transactions.
The gas-pricing mechanism has been removed, though the concept of gas is still used.

So far, Geth has been altered in such a way to allow both public and private transactions to occur.

Constellation

Constellation could be considered a P2P system in which each node in the system can act as a distributed key server and mail transfer agent (MTA),
using PGP encryption to encrypt messages. It is this part of Quorum
that allows for transactions to be made private, and is composed of two
parts: the Transaction Manager and Enclave.

The Transaction Manager handles transaction privacy by storing and
making transaction data available, as well as exchanging transaction
payloads with Transaction Manager instances on other nodes. It does not
have access to any of the private keys required for encryption, which
is the job of the Enclave. The Enclave's job is to handle both key-
generation and the encryption of transaction data. As its name
suggests, handling these jobs eparately allows sensitive operations to
be isolated.

Summary

In this article, we learn about private versus public networks for Ethereum blockchain development. We also discussed the differences between permissioned and permissionless blockchain networks as well as privacy versus anonymity in Ethereum networks. At the end, we explored Quorum and demonstrated its high level concepts and features. After this article, we move on to Building Enterprise Blockchain-as-a-Service Applications Using Ethereum and Quorum tutorial. It shows you how to implement a blockchain project based on Quorum step-by-step.

If you like to explore blockchain development with an alternative platform like Hyperledger or learn about the projects of Hyperledger like Sawtooth or Iroha, visit Comprehensive Hyperledger Training Tutorials page to get the outline of our Hyperledger articles.

About Authors
This article is written by Matt Zand (founder of High School Technology Services, Coding Bootcamps) in collaboration with Brian Wu who is a senior Blockchain consultant at DC Web Makers.