The South African Reserve Bank recently concluded a pilot project called Project Khokha, in which eight banks tested an Ethereum-based interbank payments platform.
Currently, the SARB runs a system called the South African Multiple Option Settlement system (SAMOS) to perform real-time gross settlements between local banks.
ConsenSys and its permissioned Ethereum platform, Quorum, were selected for the project, and the aim was to replicate some of the functionality of SAMOS in a distributed ledger system.
Seven other banks participated in the pilot: Absa, Capitec, Discovery, Investec, FirstRand, Nedbank, and Standard Bank.
The eight banks each had their own node on the Project Khokha network, and every node was configured with four virtual CPUs and 16GB of RAM.
All the Project Khokha design document specified was the minimum specification for an Ubuntu server, which could be hosted as the bank saw fit.
As the diagram below shows, the pilot featured a variety of server types, including public cloud services from Microsoft Azure and Amazon Web Services, Azure private cloud, and physical servers hosted on-premises.
This was not intentional, said ConsenSys, as the banks used the infrastructure for the pilot they wanted to.
“We didn’t actually specify hardware to get a heterogenous system,” said ConSensys.
“We worked with the banks around their existing policies and existing relationships. It just happened to come out a heterogenous network, which was great for the report.”
One participant even containerised Quorum using Docker, even though the Quorum node had not yet been deployed as a Docker container.
Capitec, FirstRand, Standard Bank, and the SARB used Standard D4 V3 virtual machines from Azure. Absa elected for a t2.xlarge Amazon EC2 instance.
The network was then tested in two different ways:
- With only the SARB’s node verifying every transaction between banks.
- With every bank on the network verifying transactions.
Specifications for the servers had to be improved for the final set of distributed tests, as extra computations per transaction were required when each node had to verify every transaction.
No actual transactions were processed on the network, but the SARB said it ensured the tests were as realistic as possible.
ISO 20022 standard messages were used, and the SARB was able to view the detail of all the transactions to allow for regulatory oversight, it said.
By allowing the banks to verify interbank transfers, it also makes it possible for real-time gross settlements to continue in the event that the Reserve Bank’s node goes down.
To validate transactions, the Quorum implementation for Project Khokha used Istanbul Byzantine Fault Tolerance, Pedersen commitments, and range proofs.
According to the bank, this delivered a combination of scalability, resilience, confidentiality, and finality.
Under Istanbul Byzantine Fault Tolerance, validators propose and vote on new blocks, and as long as no more than a third of them are faulty, instant finality is achieved. No forks or invalid blocks can occur.
Each transaction also needed to generate range proofs to show that the amount being transferred was positive and that the balance of the sending bank was still positive after the transaction. These proofs have to be verified by all the nodes on the network, which introduces more computation per transaction.
The Pedersen commitment – a cryptographic function that lets you commit to a secret numerical value, while maintaining the ability to do mathematical operations on the secret value – is part of the technique used in the cryptocurrency Monero to ensure privacy.
Commitment schemes are designed so that a party cannot change a value after they have committed to it – in other words, commitment schemes are binding.
“The specific implementation in Project Khokha is the first time that this has been used with Quorum, and it has delivered significant performance improvements over other confidentiality mechanisms,” said the SARB in its report about the pilot.