Efficiency and speed in the processing of payments come from the availability and verifiability of payment data while that payment is in flight. In short, the transaction has the details of the sender and the receiver of the money, the amount of the transaction, verification that the funds being sent exists, and that the receiver’s account exists and can accept funds. In the digital currency or cryptocurrency world, all of this information is readily available on blockchains. The critical element for the transaction to be considered complete is how quickly transactions can be committed to a block and blocks committed and confirmed to the chain.
I continue to be dismayed when supposed experts in the digital currency space point to the transactions per second (TPS) of Bitcoin as a reason why digital currencies cannot support the economic scale required by an entire country. Bitcoin is the first implementation of a decentralized cryptocurrency. You would have to be ignorant of any other cryptocurrency created since Bitcoin, including those with transaction processing ranging from 30,000 to 150,000 TPS.
Let’s examine the Bitcoin block commit model to understand better why the TPS looks low. Transactions get submitted to nodes where they are put into a queue. A node opens a new block and tries to grab as many transactions from the queues on the nodes to fill a block before the block commit timer runs out, or the max number of transactions/block size is filled. The maximum block size is ~2MB after the soft fork of Segwit is applied to Bitcoin. A transaction contains an average of 570 bytes of data. A block can support a maximum of 6000-7000 transactions. Lately, the average bitcoin block size has been around 1.2MB, and the recent average number of transactions per block is ~2300. The average block confirmation time is sitting at about 130 minutes. This is a long-running process because the proof of work needs to be completed by a miner, and then a variety of confirmations need to follow-up to provide more confidence in the block commit. This is the killer for TPS on Bitcoin. These factors leave Bitcoin in the 12-17 transactions per second due to the long delays in getting a block through the proof of work process and added to the chain. Also, in those cases where two blocks are trying to be committed simultaneously, and your transaction is in the block that loses out on the competition to be added to the chain, the timer starts over again to put your transaction in the next block (hopefully).
The tactics and modelling of a first-generation decentralized cryptocurrency like Bitcoin will not be applied to CBDCs. Any Central Bank thinking of issuing a digital currency backed by the ‘proof of work’ model needs to go back to the drawing board. Continuing to reference Bitcoin’s low TPS is also a waste of time and adds no value to the CBDC conversation. For example, EOS is a decentralized cryptocurrency that has been proven to support ~4000 TPS and is estimated to handle upwards of 50,000 TPS. Other proven high-speed examples include:
While these numbers are encouraging, they highlight a couple of essential points:
- The lack of overall transaction volume to prove the limits of many modern cryptocurrencies, and
- There are no silver bullets in the transaction resolution and block commitment models yet.
But these proof and confirmation are all issues in the decentralized world, and these limitations do not apply in the same way to a secure permissioned ledger model. As an example, the proof models are replaced by totally different protocols such as Hyperledger’s Byzantine Fault Tolerance method.
Regardless of payment settlement mechanisms or the ledger style being used, it is vital to have complete remittance information and verification of both the debtor and creditor data for the payment and the funds availability/liquidity details for the accounts involved in the transaction.
In most cases, these transaction participant details are all tokenized, which shortens the overall transaction message. Thus the full detail and validation required for continuous straight-through processing of payment details would come from non-blockchain or alternate blockchain sources going forward. For example, a Central Bank could be the provisioner of interbank liquidity on one ledger to facilitate real-time payment clearance between two participant banks’ ledgers.
Using the independent ledger design, as I suggest in my previous post, the TPS is more influenced by the connectivity between the ledgers attempting to complete a transaction and the ability of both parties to confirm and commit funds using a small block model that would represent only the transaction(s) between those parties. A single centralized ledger or even a dual ledger CBDC model would require a broad dispersion of nodes and capabilities to quickly consolidate transaction requests into blocks and commit those blocks, making it much more difficult to ensure equal transactional priority to all participants in the ecosystem. You don’t want to create a system where transaction friction is due to the concentration of payment volumes in large cities' market centers or create a struggle to commit transactions for people trying to exchange value in sparsely populated rural areas.
Another thing to consider is that the modern payment in a digital currency world is rarely between two parties, and this will be a topic for a future post.