Corda and the Distributed Ledger Technology

Recently I became involved with SCC's committee on "Blockchain and electronic distributed ledger technologies". During one of the discussions, I've learned about a new term that seems to have become very popular in the banking industry - "Distributed Ledger Technology" (DLT). Apparently companies like Deloitte or even the UK government have picked up on this new thing and seem to be abuzz with it.

Instantly this reminded me of 2015 when big companies like NASDAQ and Overstock expressed their interest with "the Bitcoin technology", but they didn't want to be associated with "Bitcoin", therefore decided to rename this whole thing as "blockchain technology". Maybe this was just another way for companies to invent a new five dollar word and charge a hefty sum to consult on it?

After doing some research, I couldn't find much on what exactly DLTs were - there doesn't seem to be a concrete definition floating around yet. However, a few people pointed me to one example of an actual implementation of a DLT - Corda. Lucky enough, someone coincidentally decided to organize a meetup about Corda around the time, so I had some good opportunity to learn what it's about.

Corda

Corda is a Distributed Ledger Technology implementation by the R3 consortium. It is open source, comes with a Slack, a whitepaper and all that.

Corda has been created from the grounds-up for the use by banks and other financial institutions, prioritising their needs first. This dictated a few important design choices:

• Private transactions - transactions in the system are only disclosed to the parties involved. They are not globally broadcast for everyone to verify, instead only circulating in very limited circles as small as two peers.
• No blockchain - since there is no need to let everyone know about every transaction that took place, there is also no need for a blockchain, be it public or permissioned
• Legal smart contracts - much like a Ricardian Contract, the smart contracts executed on the Corda network have explicit legal prose attached to them.
• Optional notaries - if two parties don't trust one another, they can bring in optional notaries to verify various aspects of the transaction (no double-spending, uniqueness of transaction, etc.)

Knowing these features, we can try figuring out what existing cryptocurrency project it resembles most. Looking at this chart comparing various projects in the space (provided funnily enough by Tim Swanson a few years back before he joined R3):

Tim Swanson's "Current Cryptoprotocol Infrastructure" from his "Great Chain of Numbers"

It looks like Corda can fall in only one spot, which is the "Ledgerless Crypto Suite", alongside Open-Transactions. Indeed, the resemblance is quite strong.

The following explanation is based on the "Introduction to Corda" presentation and other materials I managed to come by.

Corda's base building block is a cryptographic transaction. It can be a simple payment, or a more complex smart contract. The transactions specify which inputs they are spending and what outputs they are generating (this works just like Bitcoin and is different from an "account-balance" approach of say, Ripple). Each transaction has a hash of a legal prose attached to it which governs how the transaction should operate. The transaction is then signed by all of the participating parties that agree to execute it - it could only be one entity when it is a simple "send money" transaction, or span multiple parties if it is a more complex swap or financial agreement.

The transaction can also be notarised or verified by third parties as needed. This could be as simple as a server doing a blind signature to verify the transaction is unique, or perhaps the whole transaction could be disclosed to some auditors as needed.

After a transaction is signed, that's about it - every party that knows about the transaction records it in their ledgers and the financial contract is thus binding. There might be some follow-up on the smart contract as it matures or other trigger points execute it, but with no blockchain, block generation or the like, there isn't much else to it.

As it stands, Corda seems to fit in as a common middleware for banks and financial institutions to standardise their interactions with one another, especially in the realm of financial contracts. This puts the project in a similar space to Open Transactions or Interledger, not too far from Ripple or Ethereum.

Corda criticism

Due to its focus on catering to the financial institutions, Corda might be seen as "more of the same", rather than trying to revolutionise the field like Bitcoin. Some people might dismiss it out of principle for not fighting to make the banks more transparent.

A system built on private transactions will be easier to manipulate than a proper blockchain. Unless all of the transactions need to be accounted for by some independent auditor, you loose the option to have "negative proofs". Since the amount of parties involved is so small, they can easily conspire to rewrite or delete the past transactions to suit their present needs. This could be mitigated by using a proof of existence and anchoring the various hashes of transactions into something like Factom.

However, if properly maintained, the system can enforce accountability. While the transactions may not be a part of a blockchain, they do form a transaction chain - every transaction spending the previous output. Having any single transaction signed by the various parties could be used against them - they might be compelled to provide the full, unbroken chain of transactions leading up to that transaction. While this might not uncover all of the transaction branches, there is at least some cryptographic trace of what happened.

Linking the legal prose to the smart contract is also asking for trouble. Even now people can have legal disagreements as to which interpretation should take precedent when you have a contract written in two human languages. Woe to anyone who wishes to mix legal prose with a smart contract. This would either require a new profession of some lawyer-programmer, some sort of legalese language interpreter / compiler, or the smart contract will be just a farce that could be overturned so easily it might not even need to exist.

Corda's presentation seems to indicate the legal prose takes precedent over the code. This might mean that there would need to either be some backdoor for third parties to overwrite or amend the contract, or the parties involved would have to work around the code to achieve settlement in the end. All in all, this can lead to a lot of mess in the code down the line. Some might prefer the approach of "code is law", but then we have the story of the DAO as a cautionary tale.

Moreover, the contracts dealing with international law and regulations would be even more complicated. This could lead to fewer transactions taking place between various jurisdictions to avoid the legal hassle.

Beyond that, Corda seems to rely on a few known key actors common to the Crypto 2.0 space. Lack of native currency means the system will need gateways to issue assets. Some design documents mention Smart Oracles, etc.

Distributed Ledger Technologies

Based on the example of Corda and Open Transactions, we can try drawing some conclusions of what the Distributed Ledger Technologies might be as a general term.

• The technology seems to be focused more on transactions and less on grouping them into blocks.
• With the absence of blocks, we necessarily have to do away with any form of distributed, native currency - there is no way for that currency to be objectively generated. The system instead uses IOUs for currencies and assets.
• The system relies on a number of key nodes / entities to operate - auditors, validators, legal authorities, banks, etc. This means the system would be at best "decentralised"
• Cryptography is still used to authorise various transactions and move the money around.

Conclusions

Distributed Ledger Technologies seem to sound more impressive than they are in reality. Some have proposed to use this term to refer to things like Corda as well as the existing Blockchain Technologies, but it seems to be mostly an unnecessary buzzword. The existing DLTs are not really distributed, but decentralised. The word "ledger" correlates more closely to a block of transactions than what we have in Open Transactions (where you can discard old transactions as they are not needed once they are confirmed spent). So perhaps a more accurate term would be "decentralised set of transactions"? DSoTs? DSoTTs if you want to include "technology" at the end as well...

An overview of eCurrency Mint

eCurrency Mint (not to be confused with MintChip) is a new startup backed by an eBay founder that is aiming to create what looks like a Crypto 2.0 network augmented with anonymous transactions. It looks to be aiming to create a digital cash system - allowing central banks to issue tokens that anyone can anonymously transact in, just like with physical cash. Lets have a look and see if the idea is feasible.

Features

Based on an article from Payments Source, the Mint appears to:

• Allow central banks to issue digital currencies
• The issued currency is untraceable ("eCurrency Mint [...] doesn’t let a central authority track the ownership and usage of the digital money"), although "individual countries could implement the technology differently"
• The currency would take a form of "cryptocomplexes", which would either be similar to Bitcoin transactions, or be their own atomic tokens (the text is unclear) ("[I]nstead of printing a billion one-dollar bills, [a central bank] would issue digital objects called cryptocomplexes that it would inject into the financial system much as it does cash today")
• "[E]ach [cryptocomplex] keeps track of itself. Through a unique identifier, each unit is forever associated with the original block from which it came. The central bank would know immediately if the total of all the pieces added up to more or less than a billion. But it wouldn’t know where each piece is, or who owns it."
• "There’s no general ledger like bitcoin's blockchain for eCurrency."

Analysis

Based on those features, it looks like we are dealing with a ledger-less currency similar to either Open Transactions or what MintChip was supposed to be.

The biggest design challenge of what was described is the anonymous aspect of the currency. While the details of what the author meant by "cryptocomplexes" remains unknown and more details would be needed for a proper analysis of the technology, what is being presented is not beyond the realms of possibility. We can look at Dash's DarkSend, BitShare's TITAN, Confidential Transactions proposed by Greg Maxwell as examples of how this can be achieved, at least in a ledger-based network. For a setup like Open Transactions, you would probably use some scheme based on blind signatures for the notaries.

While what is presented is technologically possible, the scheme could be found illegal under various rulings, such as the 2013 FinCEN guidelines on Virtual Currencies. While it would be feasible to perform full KYC on when the currency enters or exists the system (at least until there is even a need for such transfers before money becomes completely digital), losing the ability to track, freeze, seize and audit the financial records of various people might be seen as helping money laundering and criminal activities.

Conslusions

The information presented about the eCurrency Mint paint a technologically plausible picture of a new anonymous, ledgerless Crypto 2.0 system similar to some of the features described by MintChip. It would be interesting to see more technical explanation of the proposed system, as well as an overview of how such a system could fit into the existing regulatory framework.

Due to the heavy emphasis on anonymous transactions, I doubt the eCurrency Mint will ever be considered for adoption by any government or central bank in its current form.

Related articles:

• Sample bankchain feature set
• BitUSD vs USD IOUs
• The rise of fiat-denominated cryptos

Trust-based currencies - good money, bad money, LETS, Ripple, etc.

This week at Decentral Vancouver we had a discussion with Michael Linton and Dominique Legault from Open Money about the LETS (full recording). LETS, or Local Exchange Trading System is essentially a community-run non-for-profit system for recording transactions, often using a form of a local currency. During the discussion various comparisons to the current Crypto 2.0 systems came up, along with some debate whether local currencies in general are good for us. Let us dive into these topics deeper.

Trust-based systems - explanation

Trust-based systems can be defined as a monetary system based on currencies requiring a trust that other parties won't default on their obligations. Examples of such systems include banks, gift cards, debt, as well as the aforementioned LETS, Ripple (minus the XRP portion) and Open Transactions. Counterexamples are currencies where you directly control the monetary asset transacted in, such as barter, gold or Bitcoin.

All trust-based systems can be boiled down to managing Trust and Debt:

Trust and Debt in Ripple Trade wallet

Trust is the limit of how one person is willing to have the other person owe them, while Debt is the current amount owed. So if I Trust BitStamp for $100, I am willing to hold up to $100 of their Debt before they won't be able to send me any more money. If I hold $10 in balance from BitStamp, they are $10 in Debt.

These simple relations are pretty much how all of the modern banking works. A savings account is you Trusting the bank and them being in Debt to you at your current balance. A credit card is the bank Trusting you, and the amount you charge onto the card is how much in Debt you are to the bank. If I send money from my account to yours, bank's Debt to me is reduced, and it is increased for you.

Based on how Trust is placed, we can have 3 different systems - centralized, decentralized, and distributed:

A centralized system is like a government issuing a currency - everyone in the given country is obliged to trust it and use it. The world economy is a decentralized system - every government issues their own currency, most people use one currency, but there is some connection between the systems. Local network of interpersonal debt ("I owe you $5 for the drink last night") is a distributed system.

All of the trust-based systems can take a form of any of the three systems. Currently, Ripple Classic and LETS are more focused on the distributed model, while Ripple and its gateways are focusing on the decentralized approach.

Decentralized vs Distributed model

As the centralized model is pretty similar with decentralized model, I will omit it and discuss the other two models.

From a practical perspective, you will most likely have some combination of a distributed and decentralized model in your trust-based system.

The distributed model appears to be more useful when "liquidity" is scarce and there are more direct interactions on a community level. For example, if you have two people with no cash on hand that are capable of working for $10/hour, under the centralized or decentralized model they wouldn't be able to do anything because they wouldn't be able to pay one another. Under the distributed model, they can still work by tracking how much they each owe one another and settling the difference in kind. Similarly, the debt could be exchanged in a web of trust in the local community for different goods and services.

The decentralized model appears to be more useful when parties don't trust one another, but can trust some third party. For example, a person selling a $100k house might not want to trust a stranger to repay the debt over many years, but would be more willing to trust a bank or similarly large institution. This model is also useful for trade outside of your circle of friends as it reduces complexity. Sending money overseas in a decentralized model means going from you, to your bank, to recipient's bank, and to them, rather than possibly funnelling through a network of many people.

Good money vs bad money

Gresham's law is commonly stated as "bad money drives out good money". It is often mentioned in context of money's nominal value (how much value is printed on the bill or coin) and its commodity value (how much the raw cotton or metal used to make the money is worth). To put it simply, people would value a silver dollar coin more than a dollar bill due to the metal, and as such would first spend the dollar bill.

When talking about trust-based money, the same issue comes up in a more interesting way. Say we have a local community money like SeedStock and a government-backed Canadian Dollar. If we have an inefficient market (it is hard to trade SeedStock for CAD), people might value SeedStock roughly around 1SS=1CAD and use them interchangeably as needed on the local level. The trades would obey Gresham's law and SeedStock should be spent first.

However, if we have an efficient market (trading between the currencies is instant and on the fly), we would discover the true value of SeedStock. Perhaps it would turn out 1SS is only worth 50 cents since too few places accept it, or maybe it's a more optimistic 95 cents. Whatever the value would settle at, that should be an equilibrium at which people would be just as willing to spend SeedStock as they would spend Canadian Dollars.

A practical example of this would be what PurseIO does - as it turns out, Amazon gift cards are worth about 80% of their face value when used to purchase Bitcoin.

Back to our systems - it is very likely that local currencies from the distributed model will turn out to be "bad money" (or at least worse than the alternative), while the money from big, decentralized gateways will act like "good money". The good money will probably also be used as a measurement of value, even when bad money will be used as settlement (I owe you $10 worth of my labour).

If we have an efficient market, no merchant will be interested in taking settlement in any bad money other than the one they issued themselves - if they can receive 10CAD or 10CAD worth of SeedStock, unless they need SeedStock directly, they would rather hold the good money. This would work until the entire market would either dry up or become inefficient, in which case there would still be a use for bad money to facilitate trade.

LETS - how does it fit in?

During our discussion at Decentral Vancouver, Michael Linton was arguing that local currencies in the LETSystem are needed to keep the local economy from drying up. We can illustrate the local trust-debt relations as:

However, no matter what currencies we are using, there will always be a need for transactions between the communities in the modern world. Unless the system is hindered by not being able to trade between the currencies, those currencies will be traded and some exchange rate between them will be established. Just like with the modern world - whether what one community supplies is valued higher or lower will determine the exchange rate until there is some price equilibrium (say, if oil is 10% cheaper to buy and import from US than to buy locally in Canada, the economic system based only on that should value CAD at 10% discount until it is just as cheap to buy and import than to buy locally).

As such, the LETSystem is fine in allowing communities to issue their own currencies, but hearing the technical explanations, it appears inferior to Open Transactions and Ripple. Both Open Transactions and LETS were built for local pockets of transactions between individuals that were checked and validated by a third party (a notary for example). Communicating between the local instances is more of a problem in both systems. If that is an important feature of a system, Ripple is more suited for the task, provided you are willing to sacrifice privacy for transparency.

Conclusions

The LETSystem has definitely influenced many developments in the trust-based currency system for over 30 years of its existence. The decentralized and distributed currencies appear to be complimenting one another - one working better on a local scale and when liquidity is scarce, and the other one when there is less trust between the parties.