Enterprise Privacy Requirements
One of the reasons enterprise-grade solutions are difficult is the need for compliance with as many regulations as applicable. Gartner predicts that within a few years most of the blockchains will suffer from privacy poisoning, wherein they will be carrying sensitive data that would and be in direct violation of privacy laws. Even if the data does not contain any personally identifiable data, companies may still want to keep certain things private, which is not possible with public blockchains. The very transparency and immutability that we value in public blockchains make them unsuitable for the enterprise.
Moreover, privacy of the network is another important aspect that most enterprises require. Access to the chain in and of itself should be regulated such that, unlike a public chain, the barrier to network entry is not simply computing power but also permission from the network owners or regulators. To put it simply, the network should be permissioned so that access is not given away to just anyone.
Quorum tackles both these aspects of privacy and permissioning, marking itself as the major contender in the enterprise blockchain space.
Two-Pronged Privacy
Privacy is an inherent feature of Quorum that allows you to create private contracts just as easily as a public contract. This is made possible by two components: the Private State and the Private Transaction Processor.
The Private State
Most blockchains have a centralized state — one ledger for all — which is public and eventually consistent for every active node in the network i.e. the Public State, uniform for everyone. Quorum introduces the concept of Private State in addition to the Public State, such that while everyone will maintain the same version of the Public State, their Private State may vary according to what they are privy to, which means that it is highly likely that no two nodes will have the same Private State. What a person is privy to is indicated by an additional privateFor field in the transaction API. We will discuss this further in the next few sections.
The Private Transaction Processor
Quorum developers have made very well-encapsulated changes to the Ethereum core presumably in order to avoid complicating the process of pulling updates from the core. If you wanted to create a private Ethereum network without private transactions, you can use the Quorum gethwith the consensus mechanisms they maintain, namely Raft or IBFT. Such a network would allow you to make public transactions only.
If, however, you choose to use Quorum, you will also have to deploy another component that enables private transactions. The Private Transaction Processor is basically responsible for managing key pairs for nodes — note that these keys are different than the geth keys — and for storing and allowing access to encrypted transactions. The key pairs are generated by this component and while the private key remains in its Crypto Enclave, it shares the public key with others and stores public keys of others as well. You can learn more about the architecture and functionality here.
A few implementations exist, including Constellation (Haskell) and Tesseract (Java), which are official, and Crux (Golang), which is a community contribution.
How Private Transactions Work?
Before we delve into the details, it must be noted that value transactions in Quorum are always public, probably so that there is never a doubt about the native currency in circulation. However, Quorum allows you to deploy private contracts, just as you would deploy a public contract, only with an additional field called privateFor(technically, there’s also a privateFromto represent the sending party’s public key, but it is not too important). The privateFor field constitutes an array of encoded public keys of the parties that this transaction needs to be shared with. Without the privateFor, this transaction is an ordinary, public one. But with this field, it is now apparent to the chain that this is a private transaction and it involves the help of another module that we call the Private Transaction Manager (Constellation/Tesseract, etc.).
Quorum Blockchain
A private transaction is initiated by A, where B’s key is provided in the privateFor field. Note that this is a regular plain text transaction.
Since this is a private transaction, it will be forwarded to the Private Transaction Processor.
The processor will internally share this with the Crypto Enclave, where the public key in privateFor will be used to encrypt the transaction. The encrypted transaction will be returned to the Transaction Manager.
The Transaction Manager stores the encrypted transaction against its hash and also shares it with the intended recipient.
The Transaction Manager returns the transaction hash to the Quorum node so that it can be added to the Public State as evidence of the occurrence of the transaction and disseminated to all the nodes.
When the other nodes process this transaction, they check with their Transaction Managers whether this transaction hash is available to them.
If the transaction is available to them, as is the case for party B, then the Transaction Manager can send it to the Crypto Enclave to decrypt the transaction and receive the transaction in clear text. This transaction is received by the Transaction Manager, it forwards this to the Quorum Node so that it can be executed. When party C asks its Transaction Manager to check if it has the transaction with the given hash, a negative response is returned.
More details regarding this process can be found here.
Permissioned Network
Permissioning is essentially bi-directional access control communication, which enforces the rules that specify which node is trustworthy and can be communicated with. Assume that there are 5 nodes that we can enumerate as A, B, C, D and E. I’m in control of Node A. I permit it to communicate with B, C and D. Now if E were to contact me, its connections will be rejected, since E is not whitelisted.
This whitelisting is done in a file called permissioned-nodes.json which is similar in format to the static-nodes.json file. Theoretically, everyone in the network could have separate files and that is bound to wreak havoc on the network, so it is recommended that every node has the same file. Even though this file can be changed while the node is running and the changes will be picked up by the node at run time, this is a very centralized process. There was talk of implementing an on-chain permissioning solution but an issue reported on their main repository suggests that it is being worked upon.
Conclusion
Despite the limitations discussed regarding the permissioning, Quorum is definitely a solution to consider if you are building a private blockchain network. However, it must be noted that permissioning centralization is not just Quorum-specific — it is a concept common in most, if not all of the enterprise blockchains. Quorum allows storing private data, which is technically stored off-chain on its Transaction Manager, so it doesn’t bloat the chain or amount to privacy poisoning. Making an educated guess here, but it seems that with Quorum, you could technically build a blockchain solution that complies with privacy regulations — if not out of the box, then with very few tweaks.
.jpg)
