Introduction To Quorum Blockchain
Quorum® is an enterprise blockchain platform. It is a fork of the public ethereum client ‘geth’ with several protocol level enhancements to support business needs. The primary purpose of the Quorum project is to develop an enterprise ethereum client which empowers businesses to embrace and benefit from blockchain technology.
As Quorum is an open-source project, the code base of the platform is open for anyone to audit, which promotes trust in the platform. Open-sourcing further increases adoption and attracts developers from different industries to participate in the development of this platform.
Blockchain and enterprise needs
The very nature of blockchain or distributed ledger provides a secure, shared platform for decentralised applications (DAPPs) and data thanks to its cryptographically secure, auditable and immutable characteristics. However, there are several enterprise-driven requirements which need to be met for a blockchain to be suitable for enterprises. These requirements primarily include privacy, performance and permissioning.
- ensures the confidentiality of transactions. It is a required feature in many industries such as financial services, health, law and government. For example in the financial industry it is mandated that the transaction details are kept confidential and shared only between the authorised parties involved in the transaction. Similarly in the health industry, patient records are extremely sensitive information and must only be visible to authorised persons.
- ensures that speed and scalability of the network is adequate to handle enterprise use cases.
- ensures that the blockchain network is only accessible to authorised entities.
All the requirements mentioned above are of paramount importance in any enterprise use case.
Now that we have introduced enterprise features briefly, we can now look at how Quorum achieves these features. First we introduce the Quorum architecture.
As compared to public ethereum, Quorum provides several enterprise features which are listed below
- Transaction privacy
- Multiple pluggable consensus mechanisms suitable for enterprise use cases
- Enterprise-grade permissions management (access control) for network nodes and participants
- Enterprise-grade performance
Fundamentally, Quorum is the public ethereum client which is enhanced with enterprise features. It provides privacy features, enterprise permissioning and improved performance in a permissioned network. A component called private transactions manager serves as an off-chain privacy mechanism. Quorum communicates with the private transaction manager using HTTPS and keeps a reference to private transactions with relevant state trees on the blockchain.
This high level architecture is shown below in Diagram 1. We will cover all these aspects in greater detail in the upcoming sections.
Now we look at all these elements in more detail
Diagram 1 : Quorum high level architecture
The Quorum node is a lightweight fork of geth. Since it is a fork of geth, it continues to take advantage of the research and development that is continuously taking place within the ever growing ethereum community and the amazing work of the geth development team. As such, Quorum is regularly updated inline with geth releases to keep up with the latest improvements.
The Quorum node includes the following modifications as compared to public geth client:
- The consensus is achieved with RAFT, PoA or Istanbul BFT consensus algorithms instead of using Proof-of-Work. Availability of all these different protocols allows flexibility to choose any of these algorithms according to business needs.
- The Peer to Peer (P2P) layer has been modified to only allow connections to/from permissioned nodes.
- The block generation logic has been modified to replace the ‘global state root’ check with a new ‘global public state root’.
- The State Patricia trie has been split into two: a public state trie and a private state trie.
- The block validation logic has been modified to replace the ‘global state root’ in the block header with the ‘global public state root’
- Block validation logic has been modified to handle ‘Private Transactions’
- Transaction creation has been modified to allow for Transaction data to be replaced by hashes of the encrypted payloads in order to preserve private data where required
- The pricing of Gas has been removed, although the Gas itself remains.
Quorum supports both public and private transactions. Public transactions work normally as in public ethereum where private transactions are enabled through a separate component called private transaction manager (privacy manager).
Now that we have introduced the Quorum node, let’s look at the privacy manager.
The privacy manager component (private transaction manager) is responsible for providing transaction privacy on the Quorum network. In other words, this component allows Quorum nodes to share transaction payload securely between authorised parties of the transaction. It consists of two sub elements, namely the transaction manager and enclave.
It is a restful and stateless service which is primarily responsible for the following operations.
- Automatic discovery of the other transaction manager nodes on the network
- Exchanges encrypted payloads with other nodes’ transaction managers
- Stores and allows access to encrypted transaction data
Currently, there are two types of transaction managers available, namely Constellation℠ and Tessera℠. Constellation is the original privacy manager developed in Haskell.
It is not being developed further in favour of Tessera, which is a more feature-rich and actively developed project. As such, we only focus on Tessera in this article. Transaction manager provides a general-purpose mechanism for securely exchanging information. It is comparable to a network of MTA (Message Transfer Agents) where PGP provides encryption of messages.
The private transaction manager is not a blockchain-specific technology. It
can be used in any application where individually sealed and secure message exchange within a network of participants is required.
Tessera is an Enterprise transaction manager. It is a java based stateless software used to enable the encryption, decryption, and distribution of private transactions for Quorum.
A Tessera node performs the following functions:
- Generates and hosts multiple public/private key pairs.
- Automatically discovers all nodes on the network (i.e., their public keys) by connecting to as few as only one other node.
- Provides two way SSL using TLS certificates (mutually authenticated TLS)
- Supports various trust models like Trust On First Use (TOFU), IP whitelist and certificate authority.
- Connects to any SQL database which supports the JDBC client
- Synchronises a directory of public keys mapped to recipient hosts with other nodes on the network.
- Exposes a public API which is used for communication between Tessera peer nodes.
- Provides a private API which is used for communication with Quorum node and:
- Allows to send a byte string to one or more public keys, returning a content-addressable identifier. This byte string is encrypted transparently and efficiently (at symmetric encryption speeds) before being transmitted over the wire to the correct recipient nodes (and only those nodes). The identifier is a hash digest of the encrypted payload that every recipient node receives. Each recipient node also receives a small blob encrypted for their public key which contains the Master Key for the encrypted payload.
- Allows to receive a decrypted payload based on an identifier. Payloads which your node has sent or received can be decrypted and retrieved in this way.
- Supports several storage backends including LevelDB, BerkeleyDB, SQLite, and Directory/Maildir style file storage suitable for use with any Filesystem in Userspace – FUSE adapter, e.g., for AWS S3.
Conceptually, one can think of Tessera as a blend of a distributed key server, PGP encryption (using modern cryptography) and Mail Transfer Agents (MTAs).
Distributed Ledger protocols typically leverage cryptographic techniques for transaction authenticity, participant authentication, and historical data preservation (i.e., through a chain of cryptographically linked data). To achieve the “separation of concerns” most of the cryptographic operations, including symmetric key generation and data encryption/decryption is delegated to the Enclave. As a result, this separation enhances security due to modularisation and also allows for performance improvements through parallelisation of certain cryptographic operations.
The Enclave works in conjunction with the Transaction Manager to strengthen privacy by independently managing the cryptography operations. It holds private keys and can be considered a “Virtual HSM” isolated from other elements of the system. An enclave communicates only with its own associated transaction manager.
The enclave handles the following data:
- Public/Private key access
- Public keys of extra recipients
- Default identity of attached nodes
Specific operations that an enclave performs are listed below:
- Fetching the default identity for attached nodes (default public key)
- Providing forwarding keys for all transactions
- Returning all public keys managed by the enclave
- Encrypting a payload for given sender and recipient(s)
- Encrypting raw payloads for a given sender
- Decrypting transactions for a given recipient (or sender)
- Adding new recipients for existing payloads
Now that we understand Quorum high level architecture, let’s now see how quorum achieves all the enterprise features we introduced earlier.
How Quorum Blockchain works
In the section, we will explore how Quorum supports the key enterprise features including privacy, performance and permissioning.
First, we’ll see how private transactions are supported on Quorum.
As introduced earlier, private transactions are supported in Quorum through an off-chain mechanism called Privacy transaction manager.
We now describe, with an end to end example, how privacy transaction manager works to enable private transactions. With this example, it will become clear how all components of Quorum work together to provide privacy features.
Just before we dive into the example, note that Quorum does not only support private transactions, it supports standard public transactions too.
As usual, all transactions need to be signed by the sender. There are two transaction signing mechanisms in Quorum. For public transactions, ethereum EIP-155 based transaction signing mechanism is used, and for private transactions, ethereum Homestead based transaction signing mechanism is used. Also, Quorum supports raw private transactions which means that transactions can also be signed externally without using Quorum’s signing mechanism. This feature allows for greater flexibility and security.
Now back to our example:
Imagine there are three Parties, A, B and C. A & B are privy to a transaction called ‘AB’, but C is not.
We now look at the transaction flow from the view of each of these parties.
View of Parties A & B
Diagram 2: Parties A & B
Looking at the diagram above, we can describe the process step by step as presented below.
- Party A sends a Transaction to their Quorum Node, specifying the Transaction payload and setting privateFor to be the public keys for Party B. It can be set optionally for party A too.
- Party A’s Quorum Node sends the Transaction to its paired transaction Manager with a request to store the transaction payload.
- Party A’s Transaction Manager makes a call to its associated Enclave to validate the sender and encrypt the payload.
- Party A’s Enclave verifies the private key for Party A, if validated, processes the transaction.
- Party A’s Transaction Manager calculates the SHA3-512 hash of the encrypted payload then stores the encrypted payload and encrypted random master keys (RMKs) against the hash in the database
- Party A’s Transaction Manager then securely transfers (via HTTPS):
- The encrypted payload
- RMK that has been encrypted with the shared key produced by enclave processing from step 4
- The nonces to Party B’s Transaction Manager.
Party B’s Transaction Manager responds with an ACK/NACK response.
Note that if Party A does not receive a response/receives a Nack from Party B then the Transaction will not be propagated to the network. It is a prerequisite for the recipients to store the communicated payload.
- Once the data transmission to Party B’s Transaction Manager has been successful, Party A’s Transaction Manager returns the hash to the Quorum Node which then replaces the Transaction’s original payload with that hash. It also changes the transaction’s V value to 37 or 38. This value will indicate to other nodes that this hash represents a private transaction with an associated encrypted payload as opposed to a public transaction with nonsensical bytecode.
- The Transaction is then propagated to the rest of the network using the standard ethereum P2P Protocol.
- A block containing Transaction ‘AB’ is created and distributed to each Party on the network.
View of party C
Diagram 3: Party C
- When processing the block, all Parties will attempt to process the transaction. Each Quorum node will recognise a V value of 37 or 38 which identifies the transaction as a private transaction whose payload requires decryption. The node then makes a call to their associated
Transaction Manager to determine if they hold the Transaction. This lookup is made using the hash as the index.
- Since Party C does not hold the Transaction, it will receive a NotARecipient message and will skip the Transaction – it will not update its Private StateDB. Party A & B will look up the hash in their local Transaction Managers and discover that they do hold the Transaction. Each transaction manager will then make a call to its paired Enclave, passing in the Encrypted Payload, Encrypted symmetric key (RMK) and Signature.
View of Party B
Diagram 4: Party B
- The Enclave validates the signature and then decrypts the symmetric key using the Party’s private key that is held in The Enclave, decrypts the Transaction Payload using the now-revealed symmetric key and returns the decrypted payload to the Transaction Manager.
- The Transaction Managers for Parties A and B then send the decrypted payload to the EVM for contract code execution. This execution will update the state in the Quorum Node’s Private StateDB only.
NOTE: Once the code has been executed it is discarded so it is never available for reading without going through the above process.
What happens inside the enclave?
Now we expand on step 4 from above, which involves enclave processing.
Diagram 5: Enclave processing
“Party A’s Enclave verifies the private key for Party A and, if validated, processes the transaction.”
This processing comprises of several steps shown below
- Generate a random master key (symmetric key) and a random nonce.
- Encryption of transaction payload with the symmetric key generated in step 1. Payload container is produced using xsalsa20poly1305 which is an authenticated encryption algorithm. It is based on Salsa20 stream cipher and a universal hash function called poly1305. The ‘crypto_box’ is produced using a public-key authenticated-encryption scheme which is a combination of three constructs, namely Curve25519, XSalsa20 and Poly1305.
- Calculate the hash (SHA3 – 512 bit) of the encrypted payload from the previous step.
- Encrypting the symmetric key from step 1 with the recipients public key. This process is repeated for all recipients one by one. In our example it is only for Party A and B.
- Enclave returns three objects to the transaction manager.
- Encrypted transaction payload from step 2
- Hash from step 3
- Encrypted symmetric keys for each recipients from step 4
Tessera also supports other Elliptic curves for the creation of public/private key pairs and data encryption and decryption. Also, Tessera supports integration with external hardware security modules(HSMs) or cloud-hosted key management. A notable feature of Tessera is its support for external key vault integration with third-party key vaults such as Azure, Hashicorp, and AWS. This feature allows for fully decoupled and reliable key management.
Now let’s discuss how enterprise-grade performance is achieved in Quorum
Quorum incorporates several suitable consensus mechanisms for enterprise networks. These consensus algorithms provide immediate finality and higher transaction throughput as compared to a typical proof of work mechanism on public blockchains like Bitcoin and ethereum.
In an independent performance evaluation study, the transaction per second (TPS) speed is reported as high as approx. 2500 TPS. This study is available on the link here:
In another study, the transaction throughput of private contract deployments is measured as high as approx. 700 TPS and performance of normal transactions have been measured up to approx. 2000 TPS. This paper is available here
This degree of enhanced performance makes Quorum a suitable choice for enterprise use cases.
Enterprise permissioning mechanism
A common and standard enterprise grade scheme used for providing organisational level access control is Role Based Access Control RBAC mechanism. RBAC is an ANSI standard. The standards document is available from ANSI here
It is a de facto mechanism for providing enterprise systems with a common enterprise grade access control mechanism. It is implemented in many enterprise systems. Operating systems such as Windows, and RedHat also have a RBAC implementation which shows its industry wide acceptance and usability.
Quorum implements a modified subset of the RBAC standard. It works on the same principles as standard RBAC. It allows role based access along with rule-based permissioning, which ensures necessary control over who can join the network and how it can be operated.
To understand permissioning features in Quorum, first we need to define some terminologies that will help us to understand the permissioning model better.
- Network – A set of interconnected nodes representing an enterprise blockchain
- Organisation – A set of roles, ethereum accounts and nodes with a set of network access control permissions
- Sub Organisation – A group within an organisation.
- Account – An ethereum EOA (Externally Owned Account)
- Voter – An account with permissions to vote.
- Role – A named job function in an organisation
- Node – A geth node which is part of the network and belongs to an organisation or a sub organisation
- Permission – A description of the type of actions that an account is authorised to perform. ( e.g. value transfer, deploy smart contract or execute smart contract)
Diagram 6 : Quorum Permissioning mechanism
Quorum permissioning mechanism is implemented using smart contracts and some necessary changes in the client software. As such, this model can be divided into two parts, the first one that deals with the access control decision output, which represents a decision that if an account is allowed to perform a function or not. This part can be considered the ‘enforcement logic’ and is implemented in the Quorum client software.
The other part is responsible for the administration of the underlying rules associated with the permissioning logic. This “rule engine” derives an access control decision based on the roles assigned to an entity. It governs what an object is allowed to do on a blockchain network. This part can be called ‘policy management’. This component is fully implemented using smart contracts written in the solidity language. Both of these elements coupled make up the Quorum permissioning mechanism. Quorum permissioning mechanism currently works with RAFT, IBFT and PoA consensus mechanisms.
As shown in diagram 6, in the Quorum permissions model, the network is composed of different organisations. The network administrator account(s) defined at the network level can propose and approve new organisations requesting to join the network. They can also assign administrative privileges to an account to act as an organisation’s administration account.
The organisation administrator account can perform several functions, which are listed below.
- Create new roles
- Create sub organisations
- Assign roles to its domain accounts
- Add new nodes to the organisation.
In addition, a sub organisation can have its own set of roles, accounts and sub organisations. The organisation administration account manages and controls all activities at the organisation level. The organisation administrator can create an administrator role and assign that to a different account to allow that account to administer the sub organisation.
The access rights of an account are derived from the role assigned to it. For example an administrator role is able to execute a smart contract, whereas as a trainee role is only able to read. An account that exists at an organisation level can transact through any node which is present either in the sub organisations underneath or at top organisations level.
Diagram 7: relationship of different entities in Quorum permissioning model
In diagram 7, we present this architecture, where network is the top level entity, containing an organisation or several organisations, with each organisation containing accounts and nodes and relevant access and status types.
Also note that user is an external entity that exists outside the network. It can be an organisation or an individual user.
The key idea here is that a user is mapped to ethereum accounts in the permissioning mechanism. It can be a 1 to many, many to 1 or 1 to one relationship. For example, a single organisation represented by a username can be mapped to several accounts on the blockchain. Similarly many external entities can be represented by the same account on the chain.
A single user can also be mapped to a single account. The advantage of this approach is that there is no need to maintain on-chain records of users, which not only can result in high storage costs but is also not appropriate to be stored on chain for privacy reasons.
Accounts are assigned roles and statuses depending on their business function and access level whereas nodes are allocated statuses which represent their access level on the network.
Organisations can also be assigned with statuses. This feature is particularly useful when an entire organisation is required to be assigned with a status on the network, for example when an organisation leaves the network, the administrator can simply assign suspended status to the organisation which will apply to all the entities within that organisation including accounts and sub organisations.
Since consortium chains are permissioned there is no need for an expensive Proof of Work consensus mechanism. Moreover, due to performance requirements, slower public chain consensus mechanisms are not appropriate for consortium chains. Therefore, Quorum offers different consensus mechanisms that are more suitable for private blockchains. These mechanisms are listed below.
- RAFT-based Consensus: A Crash fault tolerant (CFT) consensus model for faster block generation, transaction finality, and on-demand block creation.
- Istanbul BFT Consensus: It is a Byzantine Fault Tolerant (BFT) algorithm which is based on Practical byzantine fault tolerant (PBFT)
consensus algorithm. It supports immediate transaction finality. It provides liveness and safety under standard Byzantine fault threshold assumptions of ⌊ n-1 / 3 ⌋ under a partially synchronous network and 3f + 1 network configuration.
- Clique Consensus: Clique is a Proof of Authority (POA) consensus algorithm which is available with public Go ethereum client (geth).
Example use case
Quorum is used in many use cases including, but not limited to logistics, healthcare, Identity, property, payments, capital markets and post trade. We provide a list and brief description of some of the projects below.
- Tokenised cash — Developed by IHS Markit, is a distributed ledger that keeps record of all cash movements. More information can be found on this link here :
- JPM Coin® — Developed by J. P. Morgan, it is designed to enable immediate settlement of transactions between clients of the bank’s wholesale payments business. More information can be found here
- Marketplace for Loans — It is a decentralised marketplace for loans. It is developed by StreamSource technologies. More information can be found here https://cryptoshrink.io/BhlwLHY and here
- Proxy voting — It improves AGM voting transparency between issues and investors.
- Post trade processing platform — A post trade processing platform for oil trading. More information available at here.
- Interbank Information Network® — IIN allows member banks on the network to exchange information simultaneously in real-time to verify payments. More information is available here
- Supply chain tracking — A cryptographic provenance platform which enables proving the authenticity of high priced goods. Developed at https://cryptoshrink.io/zgqj. Another article covering this is available here
- Physical tracking — of gold bars and registration of title deeds. More information here:
- Mediledger — Counterfeit medicine detection is also developed using Quorum.
These are just some of the many use cases that Quorum has been used in. A comprehensive list is being maintained on the official Quorum website under section “Built on Quorum”. Readers are encouraged to refer to the Quorum website
Quorum Blockchain example
- To experiment with Quorum we refer the readers to ‘Quorum 7 nodes’ example available here
- Full instructions on how to run this examples are also available here
Tools and development
There are also many tools available for the Quorum ecosystem, which helps to improve both user and developer experience. These tools mainly include network management, deployment and monitoring utilities. As Quorum is continuously growing and has an active developer community, several user and developer tools have emerged. This trend is only expected to grow. A short list of different tools is shown below, with a link for further details.
This is just a small list from a large pool of tools and developer platforms available for Quorum. For new updates, visit here
Quorum Blockchain Summary
In conclusion, Quorum provides an enterprise grade blockchain platform with high performance, enterprise oriented access control mechanism and privacy. All these features make Quorum an excellent choice for use in any enterprise use case.
If you need technical assistance you can contact Quorum engineering team
Meetups and conferences are also held regularly all around the world you can find more information about these events here
In this article we have covered the core aspects of Quorum. For more in-depth details on development, relevant tools and specific details on various components of Quorum, we refer readers to comprehensive official quorum documentation which is available here.
Share On social Media 👇