An introduction to distributed ledger technology
Over recent years, the drumbeat of market and media interest in blockchain applications has increased, with ever more reports of the disruptive promises of the new distributed ledger technologies. Trade finance, of which supply chain finance forms a subset, has been a regular target of these promises, threats and opportunities.
To understand better the current landscape and map of future topography, Orbian this year commissioned a report to analyze the current state of DLT vis-a-vis Orbian’s SCF business. In this, the first of a series of planned articles, we will set out an introduction to the history and key concepts of DLT as related to SCF. Subsequent articles will then examine the models by which such technologies might both disrupt/enhance SCF, and the continuing development hurdles DLT faces before enjoying widespread adoption.
Distributed Ledger Technologies (DLT)
In his 2008 “Bitcoin” whitepaper, the enigmatic figure of Satoshi Nakamoto proposed a distributed ledger that could support the exchange of a digital token called ‘Bitcoin’ between individuals without the need of a centralized entity guaranteeing the integrity of the token-exchange system. Conceptually the author was introducing a disintermediation framework for the exchange of value, and technically invented an elegant solution to the “Byzantine General’s Problem”, which in simple terms refers to the achievement of incorruptible consensus over a corruptible communication network.
The bitcoin project stayed relatively obscure and bitcoin was primarily used by cryptocurrency enthusiasts and dark web users until the price peak of 29 November 2013, when it was made widely known to the public through technology and finance related news stories. At the time, the price fluctuations and its connection to illegal activities obscured bitcoin’s dual nature of a distributed ledger technology (blockchain) and an application (bitcoin).
A technical view
Due to the relative youth of the technology and philosophical differences between the various DLT projects and implementations, the classification of parts of the technology can be ambiguous. For simplicity’s and clarity’s sake though, DLT are essentially a software stack. For this reason, it is important to note that, as with other technologies, DLT is not a one-size-fits-all scheme necessarily.
Blockchains are one part of the DLT software stack, and represent the transaction ledger component, at least for bitcoin-styled blockchains. Compared to previous technologies, blockchains are append-only transactional databases, lacking some of the traditional database capabilities but with some novel features. The blockchain ledgers comprise block-bundled transactions between the participating entities of the blockchain where each new block connects and refers to each previous block, effectively creating a chain of ever increasing ‘height’. Obviously, there are different implementations of blockchains with different advantages and disadvantages, but the basic premise is to create a construct that cannot be maliciously manipulated.
In their simplest form, therefore, blockchains are best considered ledgers tracking the ownership of digital assets registered within them by users (“network nodes”). During a transaction the nodes, using their private keys, verify their ownership of specific assets registered within the blockchain and give an order for this ownership to be transferred to another node. That means that in the case of bitcoin for example, a bitcoin wallet doesn’t contain anything other than the key that verifies the ownership of specific bitcoins in the bitcoin blockchain. After each transaction it is digitally signed to prove the sending entity owns the asset (eg bitcoin) they want to send to the receiving entity.
Timestamping of transactions, as well as the consensus protocol employed, means it is impossible for nodes to use the same token in two different transactions and be validated. This provides the key solution to the initial problem of double-spending, but with the crucial requirement that transactions that are part of blockchain at any time aren’t final until enough subsequent blocks are appended and achieve ‘eventual consistency’.
From this follows that – the cornerstone of any DLT –decentralised consensus underpins the transaction validation process and through the network effect secures the network. The consensus systems are the way blockchain validators reach the agreement that keeps the single truth that can be trusted by all participants, validating or not, without necessarily having any underlying basis of trust between them.
The double-spend tolerance of blockchains is possible through the consensus process and the ability for competing branches of the chain to exist until one of them does not follow the timestamped input-output continuity. Once a transaction invalidates the attempt of an entity to use tokens that have already been used and belong to another entity, the branch is abandoned and previous integrity is thereby secured.
In smart contract blockchains, state databases are locked until all timestamped transactions are performed in order by all nodes, then the next transaction begins. This process ensures integrity, albeit at the expense of any possibility for concurrent execution of smart contracts.
The append-only characteristic of blockchains ensures validated and submitted transactions that are referred to by subsequent transactions cannot be changed without validating participants knowing about it and for the diluted branch of the chain to be abandoned. Especially in permissioned blockchains, the validator who mistakenly changes previous transactions can be identified and, if necessary, expelled from the platform.
Due to the peer-to-peer sharing of all the information in a blockchain platform, the immutability principle and the consensus systems used for them, it is possible for an uncompromised, timestamped and structured history of every transaction to be traced for every node participating in a DLT platform. Through different techniques, whether on the cryptographic or the authorization layer, details of transactions can be obscured to unwanted parties. In private permissioned blockchain implementations, there are methods to grant visibility to entities such as regulatory bodies.
The use of cryptographic keys creates ledgers of provable ownership. Via different implementations, this ownership can be pseudonymous or even completely anonymous. Methodologies such as one-time certificated allow for transactions that cannot be tracked based on identity.
Public blockchains provide relative pseudonymity for nodes participating through transactions and/or transaction validation, but don’t hide transactions details, as they are needed for the consensus process. Private blockchains allow only approved participants to have the same visibility, but the existence of relative trust between them mitigates the issue. Zero-knowledge cryptography could potentially give complete privacy on both identities and transaction information, but is still under development.
All transactions performed on blockchain platforms have their details available for at least the interested parties instantly through the validation process. The direct visibility on the local copy of the ledger means there is no need for reconciliation, since the transaction information isn’t stored in siloed databases. Moreover, since the transaction information is shared, mistakes can be identified among trusted parties and amended.
Scalability remains an issue for the prominent blockchain platforms due to an ever increasing size of the ledger itself, which leads through block size and block time to an inefficient transaction throughput rate (variously reported as a current maximum of 7 transactions per second). Although certain privately-developed blockchains claim high scalability, they are yet to be deployed commercially and the scalability is still to be confirmed.
Finally, as we complete this introduction to the technology of DLT, we should consider the fact that since such platforms rely on a peer-to-peer distributed topology in terms of data storage, they should not suffer from outages. With the state of the ledger stored locally on every node, and the possibility of the system to draw that information from whichever node possible allows for high fault tolerance. For public blockchains where the full nodes hold the complete ledger, it is especially dependable; whereas in private and permissioned blockchains, the potentially lower number of participants counteracts this. An emergence of DLT cloud solution though creates a centralization problem. Although cloud computing allows for high availability and fault tolerance, on the authorization level storing the ‘local’ copy of the ledger remotely on a centrally controlled physical server may present some difficulties. But for private and permissioned ledgers, where the rate of decentralization is not of concern, cloud solutions could be a valid option. After here introducing the general concept, and current status of DLT; the next article will explore the opportunities for a DLT-based model of SCF.
To receive a copy of the full report, please contact Sabrina Piquemal.
The original article can be found here.