Kaleido provides full production support for Hyperledger Besu
… but it’s not just Hyperledger Besu that you get on Kaleido when you click to deploy your production ready blockchain infrastructure, you actually get three components:
1. Hyperledger Besu – the core EVM implementation, p2p networking, and other components needed to form a Blockchain, execute transactions, and mine blocks.
2. Ethsigner – A co-located wallet allowing node-local signing of transactions, as required.
3. Orion – A component that allows transactions to be executed privately with data only visible to a subset of the network.
In this article, we’re going to dig a bit deeper into this last component – giving you a walkthrough of how to submit private transactions using Hyperledger Besu + Orion.
Blockchain is a technology that allows businesses to collaborate with new trust models, and lower friction. Removing layers of inefficiency, reconciliation and compensation logic – by recording transactions, data-exchange, and business flows in a shared immutable ledger maintained jointly by the participants in the blockchain network.
However, that does not mean all businesses trust each other to know the details of all of their transactions. Quite the opposite. If trust between organizations was so high as to be able to provide transparent access to internal operations, business models, and infrastructure, there would be no need for a blockchain.
Blockchain also does not remove the need for businesses to conform to regulatory requirements over data and transactions.
So for enterprise blockchain deployments, the reality is that most data must be private to those with a business need-to-know. Not on the “main chain” that is visible to everyone in the network – even when that blockchain is permissioned to only be visible to participants of that business network (as is the case in most enterprise applications today, and all Kaleido blockchain networks).
Private transaction managers conforming to the Enterprise Ethereum Alliance (EEA) Client Specification allow shared business logic in smart contracts (using normal Ethereum semantics) to be made private to a limited number of participants – making all transactions and state associated with those smart contracts private as well.
However, all this activity is pinned immutably to the blockchain visible to all participants. The installation of the contract, and each transaction payload, is recorded on the main blockchain via a hash. Participants execute the private transaction, and update their private data, as the hash is ordered and distributed via the blockchain network.
This means the following are irrefutable using the blockchain:
1. What data was sent – the data itself is not visible, but participants with a copy of the private data can recreate the hash at any time
2. The order in which the transactions are executed – sequencing is a critical part of any transactional system, and one of the most important functions performed by a blockchain
As you’ll discover in this article, the submission of these private transactions is almost identical to a ‘normal’ Ethereum transaction, so this privacy approach is very simple to adopt.
Sometimes, who is participating in a transaction, and the frequency of the interactions, is very sensitive. You might have heard the term “metadata leakage”, to describe how privacy can be compromised by exposing enough information about an activity to allow analysis to work out sensitive details. Clearly being able to see who is trading with who, and on what frequency, is a significant amount of information.
Because each private transaction requires a transaction on the main blockchain network, this “public” transaction must be signed. If you use a private key to sign those transactions that can be traced back you, then that will be visible to the whole network. Combined with other metadata such as the private smart contract identity, and timing of interactions, it is not too difficult to determine else is involved in a business transaction.
So it is common to combine private transaction managers, with one-time keys. By randomly generating a key for each transaction, you can easily hide your identity. If you need to be able to prove later that you are the owner of that randomly generated key, you can use a Heretically Deterministic (HD) Wallet to generate millions of keys efficiently that you can prove ownership of using a private seed phrase.
Permissioned ethereum networks (like Kaleido networks) allow gas-free operation – no “ether” tokens are needed to submit transactions. This addresses a fundamental anonymity challenge in public networks that require gas to maintain healthy operation of the network, as if a one-time key needs to be funded with tokens before submitting a transaction, you can follow those tokens back to find out where they came from and infer identity.
So adding anonymity to private transactions is easy in a permissioned Enterprise Ethereum network.
Private transactions managers are not the only technology in the stack.
Privacy is so important in enterprise blockchain networks, that there are many tools that you can combine together to give the right balance of transaction agreement and private
Learn more about Permissions and Privacy, Core Elements of Enterprise Blockchain, in Jim Zhang’s article.
Private transaction managers trace their lineage back to the original innovation of Constellation (Haskell OSS project, now deprecated), within the Quorum project back in 2016. Constellation was superseded within Quorum by Tessera (Java OSS project) in 2018.
Orion (Java OSS project) was developed in parallel to Tessera by the PegaSys team, starting life at the end of 2017 and released in 2018.
Today both Tessera and Orion are vibrant open source projects, with active core maintainers at Quorum and PegaSys, and strong collaboration together through the EEA.
Kaleido runs both in production, and collaborates actively within both OSS projects.
While the fundamental model is the same for both projects, Orion has a couple of differences in the model that are worth noting.
The most significant difference between the two technologies, is that in Hyperledger Besu + Orion the private payload of the transaction is submitted with a separate Ethereum transaction signing key to the ordering/proof transaction that is sent to the main blockchain.
So three distinct types of keys are involved in each transaction
1. The ethereum key (+ nonce) signing the private transaction
2. The ethereum key (+ nonce) signing the public transaction
3. The key used to encrypt and transfer the payload to remote participants in the transaction
Whereas in Quorum + Tessera, the only ethereum signature is that of the ordering/proof transaction. So only (2) and (3) exist in the model.
The use of a separate key in Orion is designed to provide additional flexibility. It allows a well-known (organizational identity) key to be used for the private transaction, while allowing a one-time key to be used to submit the transaction to the main chain.
In order to have replay protection on this private ethereum payloads, they have their own nonce or “number used once”. Both the nonce used on the main blockchain transaction and the nonce used for the private transaction must be calculated to be a sequentially increasing number for a given key.
As ordering of the execution of the transactions is still governed by the main blockchain network, care must be taken when combining a long-lived keys on private transactions with one-time keys for public transactions. As if more than one transaction is submitted before mining into a block, then the transactions could be re-ordered and fail to be processed by the private transaction manager.
The transactions that appear on the main blockchain network for Besu + Orion private transactions, will all have the same to address. This will be the special address of a special smart contract that records all of these transactions.
Whereas in Quorum + Tessera the transactions are submitted with the to address of the private smart contract (or an empty to address in the case of deploying a new private smart contract). Instead the transactions are marked as being private transactions using a special V value in the transaction signature (37 or 38 in private transactions, as opposed to 27 or 28 in ‘normal’ Ethereum transactions).
When submitting a transaction to Besu + Orion, the private transaction target will always be a privacy group. This group has a lifecycle and identity, and there are a number of JSON/RPC commands that are used to create, list and manage these privacy groups. The existence of privacy groups is broadcast to all participants in those groups.
Each privacy group is a separate isolated piece of state. A separate merkel root, maintained in the Besu node of each participant included in that group.
Two consequences of this are:
1. There can be multiple privacy groups that include the same sets of participants.
2. The privacy group must be specified when reading state (using eth_call, or querying transaction receipts) – as well as when submitting transactions
3. The sequence of JSON/RPC commands to submit private transactions are different, and contain some additional steps to manage the privacy group (as well as managing nonces within that privacy group)
In contrast in Quorum+Tessera today, the privacy group is an implicit function of the list of private participants. When performing read operations the data will be returned for a private smart contract, or transaction hash, as long as it is known to that runtime without any additional parameters.
Management and permissioning of these private state trees is a fast evolving aspect of both the Hyperledger Besu and Quroum projects, so get in touch if you’re designing a solution and interested in the most up to date information.
Your guide to everything from asset tokenization to zero knowledge proofs
Download Now
Learn how Swift, the world’s leading provider of secure financial messaging services, utilizes Kaleido in its CBDC Sandbox project.
Download Now
