Threshold cryptography in distributed trust banking environments

Kyle Redelinghuys -

This post is the first in a series on distributed banking.

Over the last few months I’ve been seriously looking at the current banking landscape - the issues facing current banking institutions in playing catch-up with fintech startups eating revenue, the increasing revenue decline from current accounts and the risk-related incentive to maintain current core banking solutions.

The focus of this post will be the movement of current accounts into a utility offering one possible implementation to this idea. For a background on “utility banking”, I have written a post giving some insight into what this entails.

Distributed trust environments

A distributed trust environment in one where no central authority holds all the keys necessary to make an authenticated transaction. With cases like the Blockchain, this trust is truly distributed as there is no central actor in charge of the network (outside of any bad actors, such as the 51% attack). Working at least somewhat in the current financial environment, this trust can be removed from a distinct central authority (such as a singular bank) and moved into more of a distributed environment (such as a coalition of banks or governments).

While the benefit of moving control of current accounts from that of a single bank to a collection of banks/a government is up for debate, I would argue that this separation of concerns would allow banks to pursue more profitable avenues (e.g. various credit lines) while keeping customer’s money safer (e.g. the avoidance of bail-ins).

Architecture

The distributed core banking system would consist of a few elements:

  • Bank Authorities
  • Core banking deployments
  • Edge nodes
  • Distributed database

Bank Authorities will hold the partial private keys of the system which will sign and verify transactions on behalf of the banking system.

This post will focus on the Bank Authorities element, but it is necessary to describe the flow of transactions to understand the role it will play.

Transactions will enter in to the closest edge node it can find. The edge node will route the transaction to a particular core banking deployment. The core banking deployment will then send the request to the Bank Authorities which will verify the transaction. Once verified, the transaction will leave the system and be approved by the territory’s central bank.

The above is a simplified version of the flow, more detail can be found in the distributed banking whitepaper.

Shamir’s Secret Sharing

By using Threshold Cryptography we can reduce the risk of a bad actor gaining access to the private key of the system. Each Bank Authority will hold a partial of the private key of the system, and transactions will only be processed once a given threshold is reached which will allow decryption of the given transaction, as well as signing to verify the result of the transaction.

Through correct implementation of the above we can allow for a fully autonomous network of transaction validation. The end goal would be to integrate with each territory’s central bank, and as the transaction is verified through the system to be both valid and approved, the central bank would automatically process the transaction. No doubt various limits could be placed on the system to help prevent malicious exploits, but as the system grows in scope and oversight these limits could be relaxed.

One of the implementations of the above workflow is found in Shamir’s Secret Sharing. Currently this is the implementation I will be pursuing in the development of this project.

Size of system and threshold

The goal of this system would be to replace current accounts in numerous markets, controlled by a non-governmental body with direct oversight of various governments and institutions. As a result, the scale of the system is large.

To get an idea of some numbers in an early stage deployment of this system, we can say the following:

  • 50 core banking deployments, each relating to a single territory
  • 1000 edge nodes (lightweight servers used for routing)
  • 5 Bank Authority servers

The number of Bank Authority servers would depend largely on the number of transactions and how each of these transactions are handled on the server. These servers will provide simple functions - partial key issuance and encryption/decryption/signing of transactions. The most requested function (key issuance) is very lightweight and trivial to scale. The second function (cryptographic calculations) is more CPU intensive, but should be able to be scaled using worker servers or a serverless architecture (such as AWS Lambda).

With the size of the system and the weight of each type of transaction, we can give an initial threshold value of 70%. This would require partials from 7 out of every 10 Bank Authority servers (4 confirmations in the example above).

Considerations

This post glossed over numerous issues which will be addressed in later posts. Some of these are:

  • Access and trust of distributed database
  • Access to Bank Authorities
  • Verification of transactions (user -> core bank -> bank authority -> central bank)
  • Security of data

Conclusion

This post introduced a core concept of a distributed banking system, that of the Bank Authority. Building on this idea, we can start to look at the broader implementation of such a system and its possible effects on the current landscape of banking.

Questions or comments? Feel free to get in touch.