The Blockchain explained to my VP (and my President-CTO)
Last week I was contracted by my last employer before I retired, a world-class satellite operator in Luxembourg, to do a training on satellite business and #technology — it’s always a pleasure to meet old friends again. I had the opportunity to discuss with 2 VPs who asked me about the #blockchain and how it can be useful for the satellite and space industry. It was a nice opportunity to discuss about what the blockchain is useful for, instead of the usual speech on what the blockchain is.
I made a 1-minute elevator pitch, which proved itself interesting enough that we chained on a 15-minute coffee explanation immediately after that. Note: This has also been checked by my former President 🙂
Executive Summary – 1-minute elevator pitch
- Today’s #financial services bookkeeping and reporting rely heavily on the double-entry ledger.
- This method of bookkeeping is a kind of manual checksum that has been invented in 13th century to support the lucrative wool trade across Europe. Doing this, each of the parties maintain their view of the ledger and the counterpart’s view, and both views must balance (“reconciliation”)
- Mathematically speaking, the number of links among n parties grows as n-square in a peer-to-peer organisation, while it grows much more slowly (only logarithmically) in an hierarchical organisation.
- So the double-entry ledger favoured a centralised model of trade, with layers of intermediairies, but also generated a need for regulations and auditing. Today’s entire financial world actors, regulators and auditors are organised from this double-entry ledger of the 13th century.
- The blockchain brings back the simplicity of the single-entry ledger (journal) and peer-to-peer transactions protected by cryptographic primitives from glitches, from errors in operations sequencing or from deliberate frauds. We take full advantage of the speed of communication and of the calculation accuracy of computers.
- But despite its great promises of simplification and cost reduction, its adoption may be hindered by the threat of disruption of the existing organization (actors, regulators, auditors).
- Outside the finance world, every day-to-day activity that would be essentially peer-to-peer may benefit from the blockchain. The #Bitcoin has the most success currently, but its blockchain is dedicated to crypto-currency transactions, while Ethereum and other blockchain platforms, being Turing-complete, have more potential.
- Some examples of peer-to-peer activity: housing swaps, hotel rooms or airplane seats booking, spare parts tracking in airliners maintenance, tracking freight containers load, individual healthcare history, real estate transactions, proficiency certification of non-commercial pilots, mutuel pension funds, mutuel health funds, micro-insurance, micro-finance etc.
What are the problems that the blockchain solves?
The blockchain is best known through its impact on financial services, so we’ll start with this application before moving to other fields.
The #problem of keeping accurate records of commercial transactions existed since the Egyptians, but was not solved satisfactorily until back in the Middle Age. At that time, Flanders was the center of the wool textile industry. Merchants all over Europe bought the finest wool clothes there and retailed them to the richest families in the rest of Europe. Payment was done partly with various currencies, partly in kind. Some were done cash, some were paid at term.
Let’s take the example of a wool merchant located in Munich, with subsidiaries in Paris, in Frankfurt, in Warsaw, and local representatives and warehouses in Bruges, in Brussels, in London. At that time, communication was done at the speed of a walking man, at best of a galloping horse.
The problems were:
- how to keep track of the amounts owed by customers, as well as owed to suppliers, in different locations?
- how to keep accurately inventory of goods at different warehouses with their delivery status and synchronise the information among locations?
- how to make sure that the same piece of cloth in Bruges warehouse is not sold simultaneously by both the Paris agent and the headquarters in Munich? accessorily how to make sure that the same piece of cloth has not been smuggled out and falsely booked as sold to someone?
One could use a single-entry ledger per location, a journal, to record each operation. But it was very difficult to detect when and where an error would occur, until it would create an inconsistency with the rest. During the 13th century the double-entry ledger started to be used (the Farolfi ledger of 1299 in Nîmes, France). In such a ledger, each transaction would appear twice, once in the column of credit (where the article came from) and once in the column of debit (where it went). With this method, each transaction could be double-checked, making sure that any flow of goods or money has a starting point and an ending point, and that the total of both parties were equal (balanced). We can see it as the ancestor of a checksum :-).
In practice, the journal would still be used to record the transactions and, at the end of the day, the accountant would copy and dispatch the transactions in the double-entry ledgers, identifying the origin and destination of each movement, making sure that all accounts were balanced after each operation and matched the journal (reconciliation).
In 1495, an Italian named Luca Pacioli formalised in a printed book the details of the method and made it popular (Gutenberg’s first book was 1439). So popular that this double-entry ledger is still the basis of today’s accounting practices, of today’s official regulations, and of today’s financial processes. It is so deeply embedded in the commercial practices that the most recent payment settlement automation efforts of the Bank of England, of the Monetary Authority of Singapore and of the Australian New Payment Platform faithfully reproduced this process.
I met concretely the reality of this kind of issues when I accepted to be treasurer of the Luxembourg Air Museum in Mondorf. This non-lucrative association has one bank account, one petty cash box for operations, one petty cash box for the Museum (selling tickets and souvenirs). It has also an inventory of postcards, DVDs, catalogs and wine bottles bearing the logo of the Museum. I use the bank account to receive subsidies and to pay suppliers. I use the cash boxes to feed the bank account, and I track the inventories. Considering the limited activity of the Museum, we do the bookkeeping ourselves instead of hiring an accountant. I discovered thus the mysteries of manipulating double-entry ledgers, inventories and journals.
What are the steps involved in a financial transaction?
To follow the steps of a transaction, let’s imagine I received an SMS from the president of the association “let’s take 100 € from our account to the petty cash box of the Museum“.
- Step1 – submission: the president sent me a transaction request. In this case it is a SMS. For a bank transaction it could be submitted either with a check (in France or in UK), or a money transfer in the other countries. Generated from paper or directly by web banking, a formatted electronic message is sent to the bank’s payment system. For large amounts between #banks, the interbank SWIFT messaging network would be used (Society for Worldwide Interbank Financial Telecommunication).
- Step2 – validation: I checked that the SMS came indeed from the president. A bank would check that the accounts of the payer and beneficiary indeed exist. It would check the syntax, verify that the amount is within some threshold, control an authorised signature etc.
- Step3 – confirmation: I checked that Museum’s bank account had enough balance for me to withdraw 100 €. In real life, the bank would check the account balance, the regulatory status of the transfer (reporting threshold, exchange control etc.)
- Step4 – settlement: I withdrew the amount and fed the Museum petty cash box. For a bank transaction, one account would be credited and the counterpart would be debited.
Now that the payment is settled, comes the serious job: I have to record the operation in my journal, update the double-entry ledgers of the Museum’s account and of the petty cash box (in my case they are simply 3 worksheets of the same Excel file) and make sure that both have their double-entry balanced. At the end of the month, I’d verify that the bank statement carries the same amount as in my journal.
On the bank’s side, in addition to keeping the equivalent books for the Museum’s account (journal, general ledger) it has also to keep an archive of the transaction, add it to the monthly reporting to the authorities for Anti-Money Laundering purposes etc.
- Now what if I, the Museum M, have to pay a supplier S; and if M has an account in Bank A and S has an account in Bank B? In its simplest form, in cascade, Bank A would debit M and credit Bank B, and Bank B would debit Bank A and credit S. The double avalanche of updates and archives and reporting as above would also be unrolled.
- What if between Bank A and Bank B there is no commercial relationship? The #solution would be to involve a Bank C who would have relationship with both Bank A and Bank B. There comes another avalanche of updates and archives and reporting.
- What if Bank B goes bankrupt before S is credited but after having received the credit from Bank A or Bank C? The answer is to involve a Central Bank that would never go bankrupt. We have another avalanche of updates and archives and reporting.
- What if at the end of the day, there has been 200 billions Euros worth of transactions between the nation-wide set of 200 banks? Would all the 20’100 possible pairs of banks proceed to the mutual transfers knowing that the total compensated amounts will be much smaller? The solution is a common Chamber of Compensation (for example Clearstream) that would simply debit each bank of the difference. We have another avalanche of updates and archives and reporting.
All this complexity was progressively built because initially the double-entry ledger was invented to do somehow a manual and medieval version of a checksum.
Side note: all payment services Fintechs actually handle steps 1, 2 and 3, the easiest and most lucrative ones. Step 4 and the actual burden of complexity are still left to banks. This is why the European Payment Directive (PSD2) calls these services “Payment Initiator Services”, not “Payment Services”.
Today the computing power is such that an iPhone 6 has 115 GFLOPs while a Cray-2 (a super computer of 1989) had only 2 GFLOPs. A GFLOP is one billion floating-point operations per second. And with the Internet, information travels at the speed of light, not at the speed of a galloping horse. In the same time we are still doing banking operations as if calculations were done manually, and indeed hundreds of thousands of accountants are still employed to verify manually on the double-entry ledgers the tricky cases generated by manual entry. Let’s go back to the initial questions and see how the blockchain solves them.
How does the blockchain solve these problems?
To start with, by definition the blockchain is a set of data that is shared by all computers (“nodes”) that participate as peers to a blockchain network and use the same blockchain protocol executed by a “client” software.
How to keep track of the amounts owed by customers and owed to suppliers in different locations?
Each participating node receives a copy of all transactions. It executes steps 1, 2, 3 and 4 above and share the result with peers.
- Step1 – submission: this is solved with the blockchain by purely data network transmission.
- Step2 – validation: cryptographic primitives are used to validate signatures; they involve heavy computing. It is part of the blockchain protocol and done by all nodes.
- Step3 – confirmation: checking that there are sufficient funds to pay the transaction is part of the blockchain protocol and done by all nodes.
- Step4 – settlement: the updated balances (or outputs of the transaction) are broadcast over the network to all other participating nodes and a consensus is build to record the settlement.
How to keep accurately inventory of goods at different warehouses and their delivery status and synchronise the information between locations?
Because the computation is now done electronically by the same “client” software, any discrepancy between nodes may come from a computing glitch, or from a difference in the sequence of execution of transactions: some nodes may receive transaction B before transaction A and other nodes in the reverse sequence.
Addressing a computing glitch is easy: the faulty node is isolated and the corresponding result is rejected by peers. Handling a discrepancy in sequence is more subtle because there may be a minority subset of nodes that agree on a diverging sequence.
The blockchain protocol states that if nodes achieve different results, they would all agree to chose randomly one of them to be right. This is called the “consensus”: the others discard their calculations and use the result of the chosen one. There are many ways to achieve consensus, the most widely used is the “proof of work”: the competing nodes try randomly to find a number that satisfies a given property. It may takes billions of billions of trials before finding it. The first node who finds a solution wins the consensus.
How to make sure that the same piece of cloth in Bruges warehouse is not sold simultaneously by both the Paris agent and the headquarters in Munich?
This can happen by coincidence in time, or by deliberate fraud. It is called “double-spending”. The blockchain protocol solves this problem by using a cryptography primitive called a “hash”. A hash of a document proves that it has not been modified. It is very difficult to forge but very easy to verify. We talked above about the “proof of work”: it consists of collecting a number of transactions together in a “block” and calculating a hash of it, as part of the work of finding a random number. If a block is modified, a verification of the hash will reveal it immediately. The blocks are “chained”, i.e. each block contains the hash of the previous block. If this previous one is modified, its hash changes and therefore the content of the next block also is, as well as the hash of this next etc. As a result, the whole (block)chain would reveal this single change.
If the double-spending incident happened by coincidence, the problem is similar to the above: it is a matter of sequencing, so the transaction that gets first its block approved by the general consensus is the only one valid.
If the double-spending was done on purpose for fraud, subsequently to the first spending being approved, the cheater will issue a second spending of the same good and this must also be approved, and at the same time somehow the block containing the first spending needs to be invalidated.
However, because this previous block has already been approved by consensus and chained to other blocks, the cheating node that wants to invalidate that block must build a variant chain faster than the rest of the community. This means it needs more computing power than the rest of the community. It is not impossible, but economically very unrealistic because of the cost versus benefit of such cheating.
As a result, there is a minimal need for auditing and verification from a higher authority because of the consensus is always achieved among all actors.
So is the blockchain only good for financial transactions?
If we take a step back and look at the big picture, the general problems that the blockchain solves are:
- how can we track the inflows and outflows of something (money or token), among a large number of peer actors?
- how can we protect against a quasi-simultaneous commitment (spending) of this “something” by 2 or several actors or by a same fraudulent one?
Does it sound familiar to you?
- have you ever been victim of an airline seat overbooking?
- how can a tour operator makes sure that a hotel room has not been booked twice?
- how can a peer-to-peer Uber reservation avoid that the same taxi be booked to 2 clients?
- how can an air traffic controller be sure that another flight sector has not assigned the same flight level and same route than his, to another plane?
- how to track over the lifetime of an liner aircraft the spare parts replaced gradually and independently by different airlines and repair shops? Airbus has 7000 subcontractors.
- how to simplify registration and declaration of all customised add-ons equipments to homebuilt and kit aircrafts made by passionate “homebuilders“, instead of today’s heavy process of paper work and local inspection made by Civil Aviation delegates or private Quality Control agencies.
- how about letting each private pilot log their hours in a blockchain and letting the doctors log the medical certificates of these pilots, both of which naturally confirms their proficiency for flying, instead of spending time and effort of all national aviation agencies to certify them, controlling an activity that is non-commercial.
- how to track individually the placement of identified satellite parts in subsystems by subcontractors?
- how to make sure that the same KWh from a solar array has not been sold to 2 different clients?
- how to guarantee that a house has not been sold simultaneously by 2 remote real estate agents?
- how to keep track of the loading of a fleet of container ships by peer forwarder stations?
- etc, etc.
All these problems have already been solved today by introducing some central coordination and distributed databases, which may be suited below a certain number of stakeholders and become polynomially complex when this number grows. But such centralisation is a source of failure, is of error-prone complexity and is a target for attacks. Above a certain volume and number of more or less independent actors, these problems would benefit from a peer-to-peer solution, and the resulting system would gain in flexibility, efficiency and resilience.
Why did the financial services become the first application of the blockchain?
- Since beginning of mankind, everybody uses some sort of financial service, every day. It’s an ideal peer-to-peer candidate application.
- The lack of a satisfactory technology to detect and correct distributed mistakes fostered the creation of a multi-layered centralised system.
- Then the centralisation and aggregation of transactions lead to huge movements of funds…
- … and huge financial flows created a need for strict regulations, to detect and punish frauds.
- A transformation into a peer-to-peer model needs significant changes in regulations and may deeply transform the financial industry.
Which one of the above use cases are better candidates than the finance industry for blockchain transformation? Probably none. That’s why the first applications of blockchain were in this field. But all the other examples can at some stage take profit of the blockchain technology.
The Bitcoin, the first well known blockchain platform, has been designed specifically for monetary transactions with a remarkable incentivizing scheme to support its use. This is why it is so successful. The Ripple blockchain platform has also been designed for monetary transactions. The Ethereum blockchain platform is more ambitious and targets to be universal. The task is huge and the product takes time to mature, but ultimately, it would not be limited to financial transactions and support the other use cases cited above.
What else?
If Ethereum succeeds, the question is “would it make sense to store in the same public blockchain the information of all the above use cases, and more (for example trading Pokemon-Go characters)“? Probably not. This is why there would be most certainly in the future
- one public (Bitcoin or Ethereum or other) blockchain that supports public peer-to-peer trading Pokemon tokens, DVD cassettes, antique stamps, collector vynils, house swaps (AirBnB), car transportation services etc.,
- and a number of private and restricted Ethereum-based (or not based) blockchains to manage more confidential matters.
To cite only the current contributions to the open source Hyperledger project, that pave the road for different types of blockchains, we have today:
- Quorum (by JP Morgan ), Ethereum-based
- Corda (by R3 ), Ethereum-based
- Azure-Bletchley (by Microsoft ), Ethereum-based
- and Fabric (IBM ), different code base.
But talking about them will be another discussion, that I’ll have with the same ex-colleagues VPs of the space industry, or with others.
[linkedinbadge URL=”https://www.linkedin.com/in/kvutien” connections=”off” mode=”icon” liname=”Khang Vu Tien”] is Blockchain & Ethereum practitioner and this article was originally published here.
Reply