By Natalie Lord
Last week we started exploring Digital Asset Modeling Language (DAML) which is, at its most simplistic, the contract language of distributed ledgers: an open-source programming language for writing distributed applications quickly, concisely, and correctly.
This week we look at how distributed ledgers differ from a centralised reconciliation system, the issue of trust and the problem with blockchain.
To begin with, a distributed ledger is exactly that – distributed. Each institution has a local ledger that’s specific to that institution’s assets. In this sense, the ledger is distributed so that each entity is able to view those shards of data that are relevant to it. At the same time, the integrity of the system provides the assurance that if entity A, entity B, and entity C all have some specific data, their views of that data and the positions they hold with respect to it are consistent.
Another distinction is that most of the distributed ledgers today incorporate blockchains. Over time, it is probable that we’ll see more non-blockchain distributed ledgers that still manage to address these goals of consistency and infrastructure mutualization. What blockchain brings to the equation is complete trust: that is, how does each entity know that its view of the ledger represents the truth, the whole truth, and nothing but the truth?
Shaul Kfir, the man behind DAML says: “Getting the truth from an engineering perspective is easy enough. A hash is a commitment to the veracity of some data. As for “nothing but the truth,” there are signatures to authenticate that the data is correct. But then there’s “the whole truth.” This is where the blockchain structure comes in, with the append-only hash chain providing one means for ensuring that.”
He says it is key that we are able to distinguish between the technical meaning of blockchain, which refers to an immutable data structure that maintains an append-only chain of changes, and the more popular industry usage of blockchain, which can refer to anything having to do with distributed ledgers or, for that matter, anything that might be used to track the history of some distributed service. This is why the term Distributed Ledger Technology (DLT) came into play; it’s to imply this broader view.
But as ever, nothing is as simple as it seems. Kfir says there’s a problem with blockchain. “Say we have two different companies that decide they want to do a swap, where one company lends one asset and gets some other asset in return. Each asset happens to be managed by a different ledger. One way to deal with this would be to use two-phase commits in much the same way cryptocurrencies employ hash locks. But this really puts the onus on the application developer or on whatever middleware you might happen to have in place. An alternative would be to ensure that the distributed ledgers are composable and able, by design, to merge and split seamlessly.”
He goes on to say that there are a number of approaches for accomplishing this. “Conceptually, a blockchain design is just a single chain of hashes and so doesn’t really lend itself nicely to network composability. If you want to use a blockchain without sacrificing network composability, you need to take a completely different approach. I think it’s critical for a distributed-ledger network to have this sort of composability.”
It is because of this that DAML doesn’t use a blockchain data structure per se. At this juncture, blockchains work predominantly with tokens. Whether it’s Bitcoin or Ethereum, we’re talking tokens but that model starts to break down as you add even a small complexity.
Kfir says the problem is that tokens are the digital equivalent of a bearer instrument in the financial world. He says they’re simply unable to capture granular rights. For example, with a stock, the owner has the right to transfer, while the share registry has the right to split or merge. Cryptocurrencies and similar tokens don’t capture these sorts of rights.
“Things become even more complex with corporate actions like voting rights,” Kfir says. “This is how we learned we would need to come up with an abstraction layer that isn’t token based. Which proved to be quite challenging. With that said, one of the Bitcoin elements we did end up keeping is its state-management model where each transaction consumes contracts and then creates new ones.
People often ask me, “Why did you feel the need to build a new contract language or a new abstraction layer?” I tell them we basically were forced to look for a new paradigm.
Just as the REST [representational state transfer] API didn’t exist prior to 2000 for the simple reason that nobody really needed a RESTful architecture until the web came along, we found ourselves in a similar situation. We were tackling a new sort of problem—a workflow problem—and found we needed to come up with a new language and new abstraction layer. And we learned not to be afraid of doing that.”
Next week we look at what happened next for DAML, why it considered blockchain as a solution in the first place and how the pieces came together to complete the puzzle.