Julia Holmes 
Share and get +16 +16 Samer Falah, Head of Quorum Blockchain Engineering, JPMorgan Chase Bank, N.A. * Imran Bashir, Quorum Engineer, JPMorgan Chase Bank, N.A. *IntroductionQuorum® 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 needsThe 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.Quorum architectureAs compared to public ethereum, Quorum provides several enterprise features which are listed belowTransaction privacyMultiple pluggable consensus mechanisms suitable for enterprise use casesEnterprise-grade permissions management (access control) for network nodes and participantsEnterprise-grade performanceFundamentally, 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 detailDiagram 1 : Quorum high level architectureQuorum nodeThe 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 requiredThe 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.Privacy managerThe 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.Transaction managerIt is a restful and stateless service which is primarily responsible for the following operations.Automatic discovery of the other transaction manager nodes on the networkExchanges encrypted payloads with other nodes’ transaction managersStores and allows access to encrypted transaction dataCurrently, 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. Itcan be used in any application where individually sealed and secure message exchange within a network of participants is required.TesseraTessera 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 clientSynchronises 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).EnclaveDistributed 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 accessPublic keys of extra recipientsDefault identity of attached nodesSpecific operations that an enclave performs are listed below:Fetching the default identity for attached nodes (default public key)Providing forwarding keys for all transactionsReturning all public keys managed by the enclaveEncrypting a payload for given sender and recipient(s)Encrypting raw payloads for a given senderDecrypting transactions for a given recipient (or sender)Adding new recipients for existing payloadsNow that we understand Quorum high level architecture, let’s now see how quorum achieves all the enterprise features we introduced earlier. How Quorum Blockchain worksIn 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.Private transactionsAs 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 & BDiagram 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 databaseParty A’s Transaction Manager then securely transfers (via HTTPS):The encrypted payloadRMK that has been encrypted with the shared key produced by enclave processing from step 4The 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 CDiagram 3: Party CWhen 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 BDiagram 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 belowGenerate 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 2Hash from step 3Encrypted 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 exter
nal 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 QuorumEnterprise-grade performanceQuorum 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 hereThis degree of enhanced performance makes Quorum a suitable choice for enterprise use cases.Enterprise permissioning mechanismA 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 blockchainOrganisation – A set of roles, ethereum accounts and nodes with a set of network access control permissionsSub 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 organisationNode – A geth node which is part of the network and belongs to an organisation or a sub organisationPermission – 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 mechanismQuorum 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 rolesCreate sub organisationsAssign roles to its domain accountsAdd 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.ConsensusSince 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 caseQuorum 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. 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 exampleTools and developmentTher
e 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.Quorum is also available on different cloud platforms, mainly this includesThis is just a small list from a large pool of tools and developer platforms available for Quorum. For new updates, visit hereQuorum Blockchain SummaryIn 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 teamMeetups 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.© 2020 JPMorgan Chase & Co. All Rights Reserved. *The information and viewpoints expressed in this article are those of the authors and not necessarily those of JPMorgan Chase & Co. or its affiliates.
