Building a universal ledger. To blockchain or not to blockchain
I spend a lot of time in banks these days and there is a lot of discussion about blockchains. Described another way, there is a lot of discussion about what the appropriate way is to technically store data for the purpose of reducing risk and increasing transaction speed.
It’s interesting to me because most bank business units that are considering various technologies don’t actually care how it works.
They just want it to work and they don’t want it to get them in trouble.
There are 2 separate problems to be solved:
- What the fastest way is to settle and clear payments or trades.
- What the best way is to record something happened without creating new compliance or regulatory problems.
These are 2 separate issues entirely. Something has to move the actual assets and something needs to record that the asset was exchanged and reflect who owns it.
The something in the second example is likely to be a ledger of some type, which is to say a database of some type, with permissions. With a blockchain, the permission is view-all. With something like Dwolla, the permission is view-some until a view-all permission is given.
Dwolla’s ledger is designed to give the data owner control of whom has access to their ledger and grant other parties permission in the form of a token. That token can be revoked but it must be expressly granted by the data owner.
This is a key feature of how the ledger is designed. There are more questions in terms of the best form of storing that information later but that view-some/view-all feature is important.
There are other ways to solve the permission problem but new ledger technologies aren’t at odds with one another as some would argue. They are actually complimentary as a single permission does not solve all issues.
When picking solutions banks learn how each technical product works through diligence and they already know everything I am saying. I’m not saying anything new.
There are key features that banks are looking for and that’s going to ultimately determine the application for various ledger solutions.
This blog is about ledgers and considerations for selecting the right technological solution to the problem that’s being solved through a new ledgers implementation, with consideration for which new problems integrating that technology will create.
When we talk about a blockchain it’s important to mention a few things:
- A blockchain, used for the purpose of recording historical transactions, is a database with a default view-all permission.
- A blockchain, is possible to not be always writable in the desired timeframe because of network traffic.
- A blockchain, is amazing at a lot of things but having reference records which are perfect milliseconds after that records initial introduction is not one of them.
These are realizations any bank has when digging into a bitcoin specific blockchain solution. All are perfectly fine when they are solutions to a problem. All three are not fine at all when the problem isn’t solved or if new problems are created as a result.
In the case of the view-all permission the banks customers could end up with their ownership of a security or asset reflected in a public view-all ledger. Their assets, ownership, or permissions could also be exposed in that view-all state. That’s not good for the bank, customer, or technology provider. That’s an expensive mistake for everyone. This is just one example. It may not always matter but the fact remains that sometimes it does and getting that wrong is a mistake of titanic proportions for a bank.
That doesn’t just apply to the banks customers but to the bank itself. Is it good for the bank to have it’s positions or assets viewable in a view-all state publicly? I don’t know for certain but I’d guess the answer is no.
To apply the wrong ledger in the wrong application that causes something like that to happen by accident would be a self inflicted data breach a bank could never take back. It wouldn’t just be ignorant. Ignorant isn’t a strong enough word to describe a mistake like that. It would violate so many of the fiduciary responsibilities the offending bank has to it’s customers and it’s shareholders that everyone involved would probably never work in banking again.
Banks are smarter than that.
In some situations. This problem could be a solution. In other situations, you can’t make this a solution because it is a problem.
There are solutions to all of these problems but the consideration is whether or not to start with a problem you have to solve or just start with the solution to the problem you have today, by selecting the right ledger.
Which is to say… Selecting the right permission on the database you’re using so that the subsequent applications for the database are well served.
We should give consideration to when a blockchain is the appropriate form of storage. Thinking critically about this is important when deciding the best way to look at building a universal ledger that anyone can make use of.
It’s not likely that there will be one ledger because of considerations just like the ones I’m talking about in this blog that massive organizations can’t gloss over. It’s likely there will be many ledgers which are sometimes, backed up, via other ledgers.
I personally feel that a blockchain as a ledger is the irrefutably best form of storage when:
- A view-all permission is best.
- Speed of the ledger is not a major concern.
- Confirmation of the ledger information is used as the source of truth only after some time has passed.
Blockchains are fascinating but have inherent limitations like any technology.
Blockchains can however be used to wield uncanny reliability when used as long term memory.
As a required redundancy which is applied appropriately, a blockchain is a tremendous solution. The idea that something can not be forgotten is really amazing but it’s still frustrating for practical high frequency applications if it takes a long time to teach the database what it will never forget.
As short term memory where it’s needed. There are other solutions which solve the appropriate problem.
This is a historically real problem in computing. It’s one of the reasons your hard drive is separate from your random access memory and why folders on the Internet and on your computer have permissions.
We’re all after the universal ledger and want it’s benefits but choosing the wrong solution to the problem creates far more problems than solutions.
Some benefits of a universal ledger:
- Everyone maintains access to historical information.
- There is one source of truth.
- Copies can be made to serve as the record in the event that one party becomes unavailable.
- Multiple things (assets, items, ideas) could be recorded in the ledger.
- No single system can remove or modify the ledger, once it’s stored.
- Changes to ownership (or things) tracked in the ledger come in the form of new entries which overwrite old entries by virtue of another system referencing the new entry as the current state. Both entries remain.
I think that many would agree on these basic advantages and some would probably pile on more. That said, there are attributes tied to these advantages that must be thought through because of how organizations actually work in the real world.
Some of those considerations look like:
- How many records does the ledger need to record per second/minute/hour/day?
- Are there any applications where it would be beneficial for records in the ledger to have different permissions?
- What compliance or regulatory ramifications exist for different permissions for market participants, customers of a financial institution, anyone who may not be aware their ownership is represented in a public forum, or to existing contractual relationships?
- How can a organization avoid getting or referencing non-confirmed records in the ledger?
- What is the interface to whatever existing system is being recorded?
Making the wrong choice about the type of ledger to use means very longstanding costs. Which is why questions like these are questions that will be asked by any organization at scale.
Using a blockchain for long term memory where a view-all permission is desirable is valuable but solving for the limitations are likely to result in using all kinds of multiple ledgers as short/long term memory based on whatever permission is required at the time.
In some cases one of the ledgers may end up as the ultimate redundancy where the owner of the data or the asset has given permission to a custodian to reflect their ownership in a view-all state. Permission must be expressly given by the all participants for this to work.
When applying new ledger technologies to banking there are banking specific concerns to deal with and these are just some of them.
Solving for short/long term memory, compliance, and providing the necessary interface to regulated entities are all problems third parties have solved in many cases with different ledgers.
The intricacies of understanding how all this stuff works is kind of confusing but banks are just trying to solve a problem, not create a whole bunch of new ones for themselves.
That’s one of the reasons Dwolla built a ledger optimized for speed and as an interface to regulated entities. The system is built to facilitate the movement of regulated assets that participating banks can share and reference with any party they interact or transact with via permissions.
This is an important differentiator between what Dwolla does and how a lot of other systems hypothetically work. Since it’s also up and running it’s becoming a off-the-shelf solution to a very complex problem. It’s already used by regulated entities facilitating the movement of the assets already held at various financial institutions.
Dwolla’s ledger design is very good for what it was designed to do. That doesn’t mean it’s the solution for all applications. It’s one solution to one of the problems that can be solved through the implementation of a new wave of ledger technologies.
At some point, I’m very excited to see where Dwolla’s ledger actually becomes reflected in another ledger. It’s only a matter of time because the benefits are too great for it not to happen eventually.
There is not a one size fits all solution here. There are many technical solutions to many market problems and there’s bound to be a lot of winners.
For practical purposes I think it’s helpful to think of a ledger as a database. The world has a lot of different database types for a reason. How and why each different database is used is just a question of which one is the appropriate choice to solve a problem.
These ledger technologies aren’t in conflict.
They are a complement to one another.
Originally published at benmilne.com on September 26, 2015.