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 article is highly recommended. History  and Evolution of Blockchain Technology from Bitcoin 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 and Building Ethereum Financial Applications with Java and  Web3j API through Blockchain Oracles are highly recommended. Harness the Power of Distributed Storage IPFS and Swarm in Ethereum  Blockchain Applications 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 ( ),  come into the picture. proof of work PoW 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 and 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. to from 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 ( ) 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. Zero-Knowledge  Succinct Non-Interactive Argument of Knowledge zk-SNARK 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 ( )  interactions between the companies themselves, it's possible the network would  involve some form of ( ) interaction, meaning  further types of confidentiality and privacy would be required. business-to-business B2B business-to-customer B2C 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 ( ) 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. Enterprise Ethereum  Alliance EEA 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 ( ), 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 ( ) 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. Blockchain-as-a-Service BaaS Software-as-a-Service SaaS 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: : 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. Raft-based  consensus : This is a PBFT-inspired algorithm that again includes short block times and  transaction finality. Istanbul Byzantine fault-tolerance 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: : This is based on the Ethereum  Geth client : This is a general-purpose  system for submitting information in a secure way, and is itself composed of and subcomponents. Quorum Node Constellation Transaction Manager Enclave 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. Quorum Node 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 ( ), 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. mail transfer  agent MTA 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 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 page to  get the outline of our Hyperledger articles. Building  Enterprise Blockchain-as-a-Service Applications Using Ethereum and Quorum Comprehensive Hyperledger Training  Tutorials This article is written by Matt  Zand (founder of , ) in  collaboration with Brian Wu who is a senior Blockchain consultant at . About Authors High  School Technology Services Coding Bootcamps DC  Web Makers

Too Long; Didn't Read

Making security fun one episode at a time

Permission and Privacy For Blockchain Networks under Ethereum and Quorum

Too Long; Didn't Read

Matt Zand

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Permission and Privacy For Blockchain Networks under Ethereum and Quorum

Too Long; Didn't Read

Matt Zand

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES