One of the most appealing aspects of blockchain for business is the degree of data immutability and decentralization it offers. Blockchain shifts trust from central authorities to a decentralized consensus among the network participants on a shared ledger, increasing trust and security. A shared ledger means that data on the blockchain is shared with each network participant and everyone has a complete copy. In addition, all transactions are performed locally on each node, so transaction payload is also shared with every participant in the network.
With enterprise use cases, privacy is of the utmost concern. For most industries, in particular those with strict regulation such as financial and healthcare, transactional data is too sensitive to be shared on a public blockchain. In addition, the counter parties of the transactions either would like to or be required by regulation to know who are involved in the transaction. These kind of requirements have led most businesses to pick private, or permissioned, blockchains over public ones for their next generation shared IT architecture.
With permissioned networks the entire ledger is guarded against public access and only accessible by specific inclusion. Only participants that have the proper permissions are able to run a blockchain node and join the network, or query a node for information. Moreover, there are circumstances in which data is too sensitive to share with your entire business network. Even with a private and permissioned blockchain, there are many scenarios where the participants may wish to make their data and transactions visible to only a subset of the participants within the business network.
Several approaches exist to address privacy requirements from different layers, and they are applicable to different types of use cases. We’ll touch on those requirements and discuss methods for data control in this article.
What sets enterprise blockchains apart from public blockchains is the permissioning required to participate in the network and interact with it.
In a public blockchain, anyone can run a node using any of the open-source clients and attach to the network. Once the software performs the necessary synchronization with the rest of the network, you would have the complete copy of the ledger in your possession.
Enterprise blockchains, or permissioned blockchains, work differently. A node must be specifically permissioned to join the network. Each node that is already part of the network will evaluate any incoming messages for their signers, and compare the signer’s identity against a permissioning policy. This applies to both the peer-to-peer networking, used by the nodes to propagate transactions and blocks as well as other functional messages such as validator votes for consensus, and remote procedure call (RPC) layer for nodes to take transaction requests from external clients.
The permissioning policy can either be locally maintained, such that it’s up to each node operator/administrator to determine who it wants to interact with, or it can be maintained as a network-wide consistent policy, typically implemented as smart contracts. The two most influential organizations in the enterprise blockchain space, Enterprise Ethereum Alliance and Hyperledger, have both adopted best practices to use smart contracts to enforce a global permissioning policy in a decentralized manner.
Privacy is a broad concept and can have various interpretations. At a high level, privacy encompasses two fundamental concepts: confidentiality and anonymity. In blockchain, confidentiality refers to the need to conceal the transaction details, while anonymity refers to concealing the parties of the transaction. Here are some examples of how these requirements can manifest themselves:
Digitizing paper-based methods and protecting sensitive personal information are popular use cases of blockchain, as it greatly reduces the risks associated with traditional data management. Data protection is commonly mandated by a compliance legislation such as GDPR or HIPAA. In the case of healthcare use cases, the blockchain offers improved access to accurate electronic health records for patients and providers alike, removing third-parties and putting the patient in control of their personal information (PI). Through the use of permissioned chains with privacy features as described below, patient’s PI remains privy only to those who are granted access.
Then there are the cases of a private or consortium blockchain run by a group of organizations, where the participants are in coopetition. Enterprises collaborate in the business network to achieve a mutual objective, while actively competing with each other. Knowledge of details of a business transaction/trade, or the simple fact that an exchange occurred between certain parties in the business network, might provide data that other parties could use to gain a competitive advantage.
Of course, there are many other reasons why privacy is needed, but these serve as a starting point to help you understand the circumstances in which it’s necessary to control who can see what both on and off-chain. Let’s dig into the techniques you can use for blockchain privacy.
This technique works by sending encrypted communications, off-chain point-to-point, to select parties that are allowed to view the full input data for the transactions. These select parties can process the full transaction, and update their state to include the full results. Other parties in the network maintain a commitment that the data was sent, a hash of the payload and the address of the sender, but cannot execute the transaction as they never receive the encrypted payload.
By keeping private data to only the transaction parties, this approach allows only a subset of the blockchain network nodes to be able to execute and validate the private transactions. As a result, the state is fragmented and there is no global consensus on a shared state. This is applicable in use cases where transactions are independent and no global state is required. For instance, in trade finance, each import/export deal is independent of another deal. By sending private transactions only among parties of the finance deal, data privacy is achieved. This is also called off-chain transactions.
A hash of the transaction payload is submitted to the blockchain as a normal transaction for all nodes in the network to execute and validate, as audit trail and security protection. This technique is employed by both Enterprise Ethereum Alliance’s (EEA) private transaction standard, and Hyperledger Fabric private data collections. More information about this can be found in our article: “Enterprise Blockchain Protocols: A Technical Analysis of Ethereum vs Fabric vs Corda”. Private Transaction Manager such as Tessera from Quorum (the successor to the original Constellation project in this space) or Orion from Hyperledger Besu are examples of EEA private transaction implementations.
The idea is that the execution of the transaction is performed by a party, or a group of parties, that can convince the rest of the network’s participants that the computation is done honestly and correctly, and that data has not been maliciously manipulated. Because the transaction data itself is kept off-chain, and only the proof or attestation of the computation is submitted to the chain for verification, privacy is achieved. Because proof is submitted as a regular transaction and verification is performed by all nodes in the network, a shared global state is maintained, making this approach ideal for use cases that require a shared global view of the blockchain state, such as tokens based dApps.
Specific technologies for trusted computation include zero-knowledge proof, trusted execution environment, and multi-party computation. On-chain based privacy methods are executed through cryptographic techniques to shield and hide your data. ZK-snarks, bulletproofs, and Pedersen commitments have proven to achieve confidential transaction. Details on how to use them in blockchains are available in EEA’s Off-chain Trusted Compute Specification.
Of the different technologies for trusted computation, zero-knowledge proof is the most used in production. These are sophisticated cryptographic techniques that can be used to generate mathematical proofs that computation has been performed correctly, without divulging the details or data of that computation.
Although the cryptography theories around ZKPs date back to the ‘80s, practical implementation did not exist until the launch of Zcash in 2016. Based on zkSNARK, it’s by far the largest and most mature deployment of the technology.
Other types of ZKP constructs such as Bulletproof and zkSTARK came later in academia which attempt to solve some drawbacks in zkSNARK, such as proof generation and verification time, and the need for a trust setup where secret keys must be destroyed in order for the system to stay secure.
In early 2019, researchers from Stanford University and Visa jointly published the Zether protocol, a Bulletproof based zero-knowledge proof technology for Ethereum. You can read more about the details of ZKP in this article including how the complex cryptographic system is wrapped inside an easy-to-follow user experience on Kaleido.
A TEE provides evidence of the exact code that is being executed. The TEE is also able to lock sensitive data inside of itself, such as an encryption key generated inside of the TEE, so that it can perform processing on sensitive data without it being available, even in memory, to other processes on the machine. Its offers the ability for shared compute to execute rich and complex off-chain processing with high throughput, and verifiable outcomes.
Intel’s Software Guard Extension, or SGX, is the most well-known TEE technology. The secure enclaves inside an SGX chip allows application developers to minimize the trusted code base, such that even if the rest of the system are hostile, the processing logic loaded inside the enclave can still be guaranteed for integrity and security.
In MPC processing, the computation is distributed between multiple parties, where no individual party has access to the full data. This allows summary calculations to be performed across a large data set, without revealing sensitive data about the individual pieces of data in that data-set. This approach has seen most adoption in cases where individuals have self-sovereign control over their own data and wish to provide limited access to that data for research, analytics, etc.
Watch Kaleido's presentation at the ZKProof Community event in Amsterdam sponsored by Deloitte and QEDIT in Oct. 2019, by Peter Broadhurst, our Head of Engineering
As you can see, the need for privacy and permissioning in a business network is critical to an enterprises’ operations for many reasons. Enterprises can confidently leverage permissioned networks (vs public) to ensure that sensitive information is not shared with unwanted parties and retain the right level of confidentiality and anonymity. Hopefully you now have a better understanding of what methods, tools and technologies make this possible. If you have any questions or want to discuss your needs for a blockchain solution, don’t hesitate to reach out.