Blockchain Transactions
Guest post: David Pinski, Chief Strategist for Financial Innovation at Hitachi’s Global Center for Social Innovation
As with any new technology, those developing blockchain and distributed ledger technologies (DLT) are developing a new vocabulary to define and describe the relevant components and systems. This new vocabulary matters to more than the people that are deeply involved in the project. It also matters to business people and consumers that are deciding whether or not to adopt this technology. Sometimes those involved in a project lose sight of how others might perceive it.
Since DLT is still in its early phases of adoption, perception is still quite important. Business leaders are making decisions about adoption that will impact the level of investment and the types of use cases that will be served. It is with this in mind that I address the use of the term ‘transaction’ when describing blockchain events.
My observation is that people tend to think of a transaction as a discrete event like paying someone in Bitcoin. And when a business person hears that Bitcoin performs seven transactions a second, they develop the notion that blockchain technologies are slow. And they are, when compared to a relational database, so this just reinforces this understanding. In business terms, seven transactions a second could be a useless technology. Except that those that work with Bitcoin understand that the seven transactions a second refers to the transaction of a block, not a single exchange of Bitcoins.
In fact, there are about 2, 000 exchange events* typically written to a single block. Thus, Bitcoin can support about 14, 000 transactions a second (defined later). This is adequate capacity to be useful for many business purposes, but would not support payment card volumes. Moving to Hyperledger, the ‘business version of DLT’, there is even more capability to process the blocks that make up the blockchain.
Hyperledger is designed to support 280 blocks per second. If it were handling Bitcoin type transactions, it could record about 560, 000 transactions per second. This is a fairly robust capacity, able to handle all but the largest tasks. But once again, we need to define what a transaction is. In the DLT world, smart contracts, not just financial transactions, can be supported. As a simple definition of a smart contract for the purpose of this article, is any transaction between parties. A smart contract can describe a transaction with dozens of fields of data. Like the terms of sale, an insurance policy, status of an IoT device, or anything you can think of.
Smart contracts are defined when a distributed ledger (DL) is designed and deployed. Subsequently, the size of these transactions can vary. There could be one smart contract (transaction) per block or thousands. Expectation of capacity and speed can only be set after understanding and designing the business process underlying the smart contract(s).
To further clarify system performance and speed, one should also explain latencies when processing ‘blocks per second’. There is a queuing and commitment process associated with submitting a transaction to a distributed ledger. This process can take anywhere from a few minutes, to more than a half an hour for some Bitcoin transactions. Once again, the speed will be determined by the blockchain technology used, its configuration and load. So, while a system may be recording 560k transactions into 280 blocks per second, the cycle time for processing an individual transaction will take minutes not sub-seconds. As technology companies work with clients, they need to be realistic and careful about performance expectations and service level commitments.
To overcome these challenges, I would like to propose some simple language adjustments when discussing blockchain processing. Since the world outside blockchain considers a ‘transaction’ as a business interaction, such as exchange of currencies like Bitcoin, I would suggest not using that term to discuss the processing of a block into a blockchain. For that, I would suggest using the term ‘blocks per second’ or just ‘blocks processed.’
I am curious what others in the community think, tweet @dapinski or @Hyperledger with your thoughts.
