Adhara, a real-time solution for global liquidity management, recently developed a blockchain-based system for a South African exchange ZAR X in conjunction with Nominee Administrator Computershare South Africa.

The solution is the first distributed settlement system in South Africa for unit trusts. Using the Ethereum blockchain, it enables the public to purchase and settle unit trusts directly from fund managers on a regulated, secure exchange called ZAR X.

The Adhara team chose Hyperledger Besu as the Ethereum blockchain client for this production system. This post will dive into the team’s 11 requirements for a blockchain client and ultimately why they chose Hyperledger Besu.

Adhara Requirements

The Adhara team have worked on regulated permissioned blockchain solutions for several years. They were part of the design team for Project Ubin Phase 2 with the Monetary Authority of Singapore (MAS) and were the technical team behind Project Khokha with the South African Reserve Bank (SARB). They have also completed a set of pilot cross border payments that terminate onto the i2i network in the Philippines.

As a result of the work the team has done, they have put together a set of requirements for a blockchain client (with related services) that is suitable for use in a regulated permissioned environment as follows:

A distributed general ledger with ledger-wide transactions Private data channels with routing capabilities Well-tested ledger software Well-established smart contract technology Excellent testing tools Permission layer to ensure counterparties can be authenticated and authorised on the network Ability to whitelist accounts Secure interoperability with well-established key management systems Event streams Enterprise support Strong technical support

Each of these will be unpacked in more detail below.

1. A distributed general ledger with ledger-wide transactions

An essential principle in a distributed ledger system is that stores of value are accessible across the entire ledger. It is important that if a credit is made into any account on the ledger, that credit can be used on any other account on the ledger with a simple debit/credit transaction.

In the case of liquidity management, this prevents fragmentation of liquidity, which is currently a major and costly problem in capital markets with treasurers having liquidity pools on many centralised ledgers. A distributed ledger can solve this problem, but only if the liquidity on that ledger is easily available across the whole ledger.

When dealing with distributed ledger systems, however, ensuring that balances and transaction amounts are private to a select group of counterparties is complicated and raises many interesting questions surrounding privacy in general in distributed systems.

Many ledgers have the concept of “private confidential transactions” where privacy is ensured by putting the transaction onto a private channel that is not visible or accessible by other counterparties on the network. This is problematic for a number of reasons including liquidity fragmentation and scaling out to new institutions joining the network.

There are ledger-wide techniques for shielding balances and transaction amounts (using Pedersen commitments for example) and these techniques do not run into the same problems as private channels.

Maintaining ledger-wide consensus on balances and transaction amounts is a requirement for the Adhara team.

2. Private data channels with routing capability

While consensus on the value of transactions on the ledger needs to be ledger-wide, there are many specific details linked to individual transactions that do not require ledger-wide consensus. Names of counterparties doing the transaction and the reason for the transaction are examples of data that can be communicated via a private channel between the specific nodes involved in the transaction.

In this case, a secure, point-to-point private channel is required, and the private data on this channel needs to be easily linked to its value transaction.

In addition, due to IT compliance rules in most enterprise organisations, the private channels need to have the ability to be routed across the network through relay nodes. This is because most enterprises will not allow multiple point-to-point connections from their data centres. Private channels that require direct connections between the endpoints are therefore not useful. The Adhara solution requires private channels that allow routing through relay nodes to enable scaling of the network and to ensure enterprise compliance.

3. Well-tested ledger software

In our experience, the best testing ground for distributed ledger software are public blockchain networks. Those networks are publicly accessible, and there is a strong incentive for being able to create fraudulent transactions on them, or even to cripple or destroy them. They are permanently under attack and as such have developed robust mechanisms for ensuring the integrity of the networks.

A good example of this were the spam attacks on the public Ethereum network in September/October 2016 which particularly affected the Go Ethereum (Geth) client.

Erik Voorhees said at the time, “Every time someone attacks a blockchain platform and fails to kill it, the platform gets stronger, and more worthy of building upon.”

There are a number of distributed ledger platforms that have no public expression. There are also a number of distributed ledger platforms that are based on public network software but are not consistently updated with the public software.

From Adhara’s perspective, we were looking for a software stack that was very close to the public chain software stack.

4. Well-established contract technology

Everything in the Adhara world is based on contracts. The way that money is tokenised onto a distributed ledger is through a contract. The way that liquidity is locked for a transaction is through a contract. The Adhara stack is heavily reliant on a good contracting environment.

5. Contract layer with well-established test tools

The contracts go hand in hand with good test tools. Building out large interconnected enterprise applications required test tools for both development and continuous integration. Having the ability to test contracts and include those tests in a CI pipeline is critical for any enterprise development team.

The Adhara team have used a number of test tools, but the suite that is head and shoulders above the rest is the Truffle test suite. Truffle supports a number of different blockchain clients and the blockchain clients that can integrate into Truffle test tools have an advantage over others.