In a nutshell: Ian Grigg’s Ricardian contracts and digital assets prehistory
I enjoyed listening to Episode 151 of the podcast “Epicenter” (previously “Epicenter Bitcoin”) featuring Ian Grigg, inventor of Ricardian Contracts and blogger at Financial Cryptography. Here are my notes – part transcription, with some edits. This one is a goldmine and covers many topics: bonds, contracts, cash, Chaumian e-cash, DigiCash, financial cryptography, Ricardian contracts, digital signatures, smart contracts, dispute resolution, Ethereum, triple entry book-keeping, oh my!
Misunderstandings and paraphrasing errors are entirely mine.
This gets fairly technical; if this is hard to follow, it may be helpful to read my introduction to smart contracts first. Hmm, if it’s still hard to follow, also read about blockchains and bitcoin and Ethereum, and digital tokens.
1:35 How did you get interested in emerging cryptography and finance?
Understand zero coupon bonds, understand finance
I was a systems programmer, and in 1995 I learnt about zero coupon bonds in finance classes of an MBA. My friend Gary Howland was working for a company called DigiCash in Amsterdam. They’d invented a new way to put money on the internet. Netscape had just gone through its IPO in 1994, the web and e-commerce were booming, but everyone was saying “Where’s the money?”.
In finance class, they said if you understand the zero-coupon bond, you can build any financial instrument. Gary was teaching me about DigiCash and I realised that they had invented a zero coupon bond.
I realised DigiCash’s vision was too narrow, and all of finance (shares, bonds, derivatives) could be implemented using this technology.
Gary and I decided to give it a go: to put all of finance on to a ledger arrangement.
4:03 How did DigiCash actually work, how is it different to Bitcoin?
Chaum and the definition of digital cash
David Chaum was a privacy advocate, spending time as a real cryptographer, using cryptography to preserve privacy. His notion of money was based on the metaphor of a digital version of a physical coin or note, in that payments are final, untraceable, and anonymous. His view was that unless we copy these properties, we will be preparing for a world of mass surveillance and control – an Orwellian nightmare.
Back then everyone was thinking client-server, because peer-to-peer wasn’t to be invented for another 5 years.
Chaumian e-cash and blinding formulas
He spent his time figuring out the cryptography so that a server could issue digital cash to you, and when you pass it to me, we run a special blinding formula, which changes the cash to a different form but is still recognisably signed by the issuing server.
So the issuer digitally signs a coin, and the blinding allows the signature to be morphed so that it is different but recognisable. The coin can then be transferred without the server being able to trace it from you to me, then I can deposit the coin back to the issuer and refresh it for a new one.
6:24 So DigiCash issues a coin to you, you give it to Meher without informing DigiCash’s server to update their registry, then Meher has it?
Yes and in the process of handing it over, we refresh the signature.
6:45 And how do you deal with the double spend problem?
You do have the potential for a double spend, but only until the receiving party sends the coin back to the server to refresh it for a new coin.
7:22 This feels a bit like Zcash. With Zcash you have public coins, then you can go through a process to create private coins, and once you send them, the linkages are broken – which address it came from, where it went, and what the amount was. Did DigiCash also conceal the accounts and the amount?
Disincentivising double-spending
The coin has no indication of the accounts that it came from. However if you were to go and double spend the coin that you’d got, then the two merchants would attempt to deposit the same coin. The second one would fail because the server would recognise that the coin was already spent, so the double spend attempt would fail.
Moreover, the two coins together reveals the source account. This was a control mechanism, because in a formal banking world, the original account holder has to be accountable for any attempted double spending.
9:05 What was the advantage of this design vs something like a blockchain or an account based system? Why do you need coins and refreshing?
Bitcoin can be traced
The bitcoin arrangement is that you use a pseudonymous key, and if you want to spread your coins around, you write them to different keys which you control, creating a graph of confusion and security by obscurity. This is what Gary and I used in the 90s, we created a pseudonymous system whereby if you wanted to preserve some sense of privacy you would swap coins back and forth to obfuscate the trail.
So why wouldn’t you do that? Unfortunately in the long run someone can always analyse your activity.
DigiCash was theoretically fine but didn’t work out
In theory the DigiCash system gave you a perfect out. However in practice, two things went wrong:
- Firstly the money was tranched into coins, denominated as a number which didn’t change. Eg if you want to send 9.99, you needed an exact set of coins to match. So you can track those specific numbers and see who is moving money around.
- Secondly people weren’t really set up to hold their coins on their own wallets because of the difficulties with backups, so people would just use an account at the mint, and withdraw when they want to send to a merchant, then the merchant would cash them in.
So there’s a time and coin based tracking mechanism. You needed a lot of traffic before you could get privacy.
11:49 Why did the excitement fizzle out?
DigiCash was constrained by the central bank
The problem started when DigiCash issued 750k cyberbucks as a test currency. Although this concept had been discussed in academic papers and in cypherpunk forums for a while, this was the first announcement that the open media picked up on. There was a Wall Street Journal article.
The central bank in Amsterdam summoned David Chaum and told him to stop doing it. The meeting wasn’t a happy one. The compromise coming out of the meeting was DigiCash agreed to only ever sell to commercial, regulated banks. So for 5 years DigiCash was sold only to banks, who didn’t want it. The banks dabbled, then backed off.
Strategically, the banks set up a project called “SET” – Secure Electronic Transactions, which was essentially similar to the credit card system, and designed to do digital cash. This meant the banks would wait for SET, which was in their control, instead of pursuing DigiCash.
This sapped the energy out of the field.
15:03 Were there other projects or was DigiCash dominant?
Clones, clones, everywhere
DigiCash was dominant because it had the patent for the cryptography. It took a few years before was there alternative cryptography that would bypass DigiCash’s patents.
When I started in May 1995, I did 2 weeks of market research in Amsterdam and found 20 companies doing something similar. So I stopped, and from then on for the next 5-6 years until the dot-com crash there were at least 100 companies every year doing the same thing over and over again. A lot of competition and repetition – everyone making the same mistakes.
7 areas of expertise are needed
From this I came out with the “Financial Cryptography in 7 layers” concept listing all the things you needed to understand to make this work. The message is that to do this right you need specialism in 7 different fields, which is too much for one mind to conquer.
18:13 I read that DigiCash failed because it was outcompeted by credit cards. In the internet’s infancy there wasn’t a good way to use credit cards on the internet because the merchant could clone your card. So there were two competing technologies – credit cards and digital coins. And out of these the credit cards outcompeted the digital coins (later reincarnated as bitcoin).
Institutional clout can beat technology
Both DigiCash and credit cards have flaws. My opinion is that it wasn’t the technology, but the institutional clout – the credit card companies and surrounding companies had the institutional mass to make it work.
One of the keys was Netscape and the RSA-DSI partnership which started out in 94 (before DigiCash built up) with the SSL concept to protect the credit card details from being snaffled over the net. That morphed into Verisign, which became a very rich company based on its ability to control the cryptography used in everyone’s browser.
Shttp was in competition with https to secure the credit cards. The ones who won were the ones with institutional clout. All DigiCash had was David Chaum and a patent.
21:30 So SSL was invented to solve this credit card issue?
SSL was literally invented to stop credit card details from being snaffled as they travelled across http. That was the point of it.
21:49 If I’m the merchant and Ian is the buyer, and Ian sends his credit card details to me over regular unencrypted http, then anyone who can sniff and listen to Ian’s packets can learn the credit card details and use them to clone the card. So you needed an encrypted channel between the merchant and the buyer, so the details can only be read by the merchant.
Yes.
22:36 You mentioned 100 companies working on the problem, making the same mistakes. Do you see the same mistakes being made again today by all the crypto companies? What are they?
The failure of single entry bookkeeping
Yes, lots of them build up their accounting mechanism to manage their coins or tokens. They start off with a “single entry” system ie a list of values stored in a database. To move a money from person A to person B, I have to subtract an amount from A and add the amount to B, at the same time, with a guarantee that they can’t be sliced up. They should either both succeed or both fail (roll forward or roll back).
But typically the financial crypto companies install a database using something like mySQL and end up moving the money in 2 operations – one to add, one to subtract. An attacker can find ways to chop the transaction in half and cause the money just to go up and up. We saw this in The DAO: Ethereum is single entry, with the weakness that a transaction can always be sliced.
The smarter companies quickly discover they’re always losing money due to hacks, crashes, failures, and bugs. They then do more research and discover the solution is to implement double entry accounting. Ethereum is going through this right now.
25:18 We saw technical flaws with The DAO and Mt Gox, but what about the business side? One of the big issues is that companies struggle to find business models that work. What are your takeaways from back then and how do those apply today?
Technology cannot succeed in a vacuum
This is a standard problem: engineers have a good idea but don’t know what to build. Sometimes they get lucky that their inspiration finds demand, but for the most part standard engineers have no view / feeling about business development and what products make it in the market.
So you end up in a lottery, with odds stacked against the entrepreneur. Mostly the companies with big ideas don’t have the use case firmly in mind – they don’t have business development people who can put together a strategy. Often they employ business development people but the engineers won’t talk to them and communicate with them and listen to what’s out there and what can possibly work.
In 1995 a big company that got a lot of money to do something similar to DigiCash. The venture capitalists came in and switched from DigiCash to credit cards. They morphed into a payment processing operation in the end. That’s an example of engineers being forced into listen.
Paypal morphed to success
Paypal was originally doing transfers from palm pilot to palm pilot – moble money. Within a year they morphed off mobile money to basic website transactions, and with another year they stopped doing that and did credit card facilitation. That’s an example of a company which morphs to find where the demand is.
28:21 Do you have any intuition about where these companies need to morph? Or where demand might emerge?
Loads of ideas, that’s the startup process! You have to look closely: what’s the skill base of this company, what’s the country, user group they’re looking at? Finding a business product that works is as hard as finding a new cryptographic invention.
28:53 Do you feel there’s a class of problem that will open a lot of opportunities for companies to become successful? To me Bitcoin has become somewhat successful, and could possibly become very successful. It’s not clear what else. Ethereum? It’s hard to see the business models.
Blockchains are not suitable for FIs
This is where I drift into R3-style thinking. If you have a context of regulated financial institutions and companies doing regulated business then you can find a way forward. It’s not blockchain – it’s establishing consensus about a set of facts. This is what Corda is trying to do.
We started in the middle of last year with a whiteboard saying “What’s a blockchain?”. Then you chop away and the end result is something that companies actually want to do: workflow and establishing facts, but in the process you’ve knocked out most of the things that make a blockchain a blockchain.
Context matters
But what context are you talking about? Bitcoin is popular among a disparate bunch of people, but for different reasons. For example, libertarians want money to trade back and forth for their libertarian deals, but this is never going to be ultra successful as the group is too small, and it has other flaws as well.
Remittances work between poor people sending low value amounts from country to country. That could be very successful but the problem is remittance is a regulated market, so you only get so far before getting clobbered by a regulator.
So consequently it’s hard to say where the killer app is – if I knew I’d be building it!
32:23 You run a blog and have written the 7 layers paper, and you wrote an article saying that Bitcoin has managed to unite the financial cryptography community behind a single codebase. I’d like to get your definition of financial cryptography.
Financial cryptography is cryptography for finance
Financial cryptography was a term invented by Robert Hettinga, a long-time cypherpunk looking at the potential for DigiCash, Zcash, and other interesting ideas.
He put to two together – financial cryptography is what happens when you use cryptography in a financial context, as opposed to using cryptography in national security or in privacy. So the notion from the beginning was to put money into the field of cryptography.
Bringing in the rest of finance wasn’t so well discussed: we were in the formative period trying to solve for money. If you can’t get money working, can you get anything else going? That was my field. Everyone could understand cash, so we wanted to get that working first.
My notion was that you have finance on the left, and crypto on the right, but there’s lots of stuff in between, for example, accounting is a killer – you end up doing single entry if you don’t understand it properly.
Then the notion of rights, which is complicated and much discussed but not well understood. It was only well developed by the Capability School[?], and the concepts didn’t flow into the rest of the field.
Then there’s software engineering. Most people think cryptographers and programmers are interchangeable. They are not! They are very different fields and very few people understand both. Zooko is one – he’s both a cryptographer now, and a programmer. Programming is such a unique field, and unless you have seriously good engineers putting together seriously complicated code you’re going to end up with a mess.
That’s what happened with a lot of systems, eg e-gold which I was partially involved in. The guy putting it together was an oncologist who taught himself to program and wrote the whole thing in SQL server. He got it up and running, which is amazing for a non-programmer, but the mess in there took them ages to clean up – I’m not sure they ever did.
36:48 What are the 7 skillsets you describe in your paper?
The 7 layers necessary for success
- Someone who understands cryptography – you don’t need a lot of it, but you need to understand it.
- A programming or software engineering department.
- Someone who understands rights and ownership, who understands the law.
- Someone who understands accounting.
- Governance – once you have value, you have to preserve it from attack. For example, Mt Gox didn’t have governance – it had one person who had control of the database, so when he got confused, the money started disappearing. This has happened ever since value was invented. So you need to have the pots of value guarded. You need to worry about a person going rogue, about when a laptop is hacked, or when someone puts a gun to their head etc – these are all governance questions, and the history is long and involved.
- Someone who understands what value is – what money is. Very few people understand this. The banks don’t understand is, but the central banks do, but they’ve forgotten how to issue it. Need someone who understands the economics of how it all works, and who understands what people perceive as value.
- Finally the Finance layer. What’s the business use case, the product, how does it react to users, why would the uses use it? This is standard business strategy.
40:10 Tell me about Ricardian contracts. How did you start to work on this? What was the problem you were trying to solve?
Bonds are contracts
This goes back to that finance class where I learnt about zero coupon bonds. I agreed with Gary Howland that we’d try to issue bonds on the net.
So I had to learn what bonds were. I can say a row in a database is a bond, but actually what is a bond? So I did a deep dive into what bonds were.
In those days they were paper bonds which you could hold in your hand, so I got some bonds and I read them. I found parameters (name, interest rate, value, coupons etc) – this was clear to me and I could program that up. Bu the problem was the script – lots of legal prose assigning rights and jurisdiction.
Bonds were written on A4 paper that you could hold in your hand, so fortunately there was only so much text that would fit. The sales brochure was written on the product!
42:19 Ha, today the termsheet of a bond is like 200 pages!
Yes, this exploded once bonds went digital.
Back in the day pre-digitisation, I was able to understand a bond as a coupling of parameters with legal prose – in effect a contract.
Once I understood this, I asked myself what a contract was, and that took me on a different journey. I learnt that there were two parties, an offer and acceptance, some clauses, terms and conditions. Goods go one way; value goes the other way.
The interesting thing is that my answer to how I issue bonds on the net is exactly the same as how I issue a contract onto the net.
Contracts are generic!
And once I’ve worked out how to issue a contract onto the net, I can construct anything else including money! So when we started, we thought we’d need money separate from bonds, but actually we just needed a contract system, with a contract for money and a contract for bonds.
This was a huge discovery which most people haven’t made yet.
Once you’ve understood that issuance of anything is just a contract which describes what it is, then your system is about building contracts. That’s how the Ricardian contract came up as a conceptual device.
44:38 Today our listeners understand the notion of smart contracts: code running on a blockchain. Back then there was no blockchain, so what do you mean issue a contract digitally? What are the mechanics?
The first thing is you have to describe the contract. This means writing legal prose: I’m going to commit myself to managing this particular instrument and I will redeem the instrument when you come up with the units.
Ricardian contracts
The invention called Ricardian Contract became a document that captures the legal prose, with some metacode in the markup language for the parameterisation (eg names, amounts etc). Fundamentally it was a contract that described what you were going to issue.
Having described it, you have to get it out there on the net. You have to build an accounting system that accounts for the units of this contract. In the accounting system you create 1,000 of these, negative in one account and positive in another account, and end up with a liability over here and an asset over here. This is standard double entry bookkeeping.
After you have created the assets and liabilities, you can carve them up and send them bit by bit to other people. You need a system to manage those units.
The problem is accounting systems are good with numbers but terrible at concept. They don’t understand what it was moving around – a bond, a USD, a castle, an aeroplane, are all accounted in the same way – numbers.
Hash the prose and account the hashes
So we need a way to link the contract claim to the accounting. That’s where cryptography came in. We took the contract document and hashed it (we were using SHA-1) and the hash became the unit which was accounted for. The accounting system just kept the numbers good and balanced and fair, and every time it moved a number around, it would move a number of these hashes. So we elegantly sliced the world of law from the world of accounting, using a hash in the middle!
The fantastic thing was although they are sliced, the lawyers didn’t need to know any accounting, and the accountants didn’t need to know any law, but they were logically coupled so you’d never be confused about what the value was.
That was the Ricardian contract – the document being hashed, and then being accounted for as a hash. This brought the whole thing together and made it end to end secure.
49:58 How would the accounting system work? If we don’t have a shared server or a traditional client-server model, how do you manage?
What about dodgy issuers?
This is where the accounting starts to get interesting. The obvious answer is a client-server model, and when a button is pressed that says pay Alice from Bob, and this gets reflected in the back end. The problem is that the issuer is as much a threat as much as any other crook, and the issuer can futz with the numbers, and can make numbers up, reject transactions, and steal money etc.
These are real problems today. Eg in the stock exchange world, shares are often over issued, contrary to the policy of the shareholders, so that people can short sell the shares. There are cases of 200% of the nominal shares out there trading, because the issuer (the registry) has made some money by adding extra shares and lending them to short sellers. This is ongoing today, not some blip or scandal, and literally how they do things.
Then you have events like Cyprus and the bail-in problem: you think your money is in the bank but suddenly it’s not because they’ve taken it away. Chaum tried to solve that and so did we.
Digital signatures form part of the solution
So we changed the payment request so it would be cryptographically signed. Your pseudonym would digitally sign the request, creating the authorisation to move the money. That meant the issuer couldn’t just wave their hands and change the numbers. The issuer was bound by the signed requests that it received. The issuer would then sign a receipt including the request, and send that receipt back to the two parties concerned, so you never lost the information.
Accounting became collecting the receipts and counting them up. Most of the issuance servers I built revolved around that – I counted the receipts and add them to the set.
Bob’s balance is a sum of the signed receipts involving Bob. Alice’s balance is the sum of the signed receipts involving Alice.
This leads to a scaling problem, but with small systems this doesn’t really matter. We invented a way to control the issuance server from being able to invent money or move money without permission.
Triple entry
From this concept came the notion of triple entry. The receipt itself was shared between the payer, payee, and the issuance server. If you only had 2 parties and one of them lost their copy, then there’s potential for abuse: you need all 3. This is how we established “consensus” (in today’s terms) about a single transaction, and about a set of transactions.
We were building this in 1995-97 and back then I didn’t really understand what I was talking about. Later in 2004 I figured that this actually looked different to double entry – it turned out to be triple entry. Oddly enough triple entry turned up in 2 different places at the same time.
So I wrote this paper and sent it to Todd Boyle who said that he’d invented this ages ago – and it was on his website. So I had absorbed the term into my head and felt that I’d invented it, but actually he invented the term and concept 5 years before me.
55:53 What you have described is very simple design pattern which occurs in many kinds of tech, for example the shipping industry created the shipping container in the 60s to interface between the land transport and sea transport. The container is a lubricant between the diverse groups. This echoes what you were saying about Ricardian contracts – interfacing between lawyers and accountants. Lawyers want to write the terms and governance of financial instruments, the software engineers care about the accounting system and atomic transactions, prevention of hacks. What the Ricardian contract does is use the hash as lubricant.
Ricardian contracts, shipping containers, and smart contracts
Yes, you could say the Ricardian contract is the shipping container of the financial digital world. It has become a design pattern. Ricardo was the name of the system we were trying to sell and this was the contract system within Ricardo, hence the term Ricardian contract.
You could say that putting the hash of a human readable document into an accounting system has become a design pattern.
Before Bitcoin, smart contracts were just abstract concepts whereas Ricardian contracts actually existed as an implementation. But as demand for smart contracts has increased, the Ricardian contract has become one way to implement notion of a smart contract.
1:00:22 Does Bitcoin need Ricardian contracts? Why aren’t they in Bitcoin?
The issuer is the point of failure
Good question – this took me some years to figure out. The thing about Ricardian contracts is that it you want to issue something of value (eg USD, GBP, EUR, shares, lollipops etc) and assumes you’re an upstanding person who will redeem them, when someone comes to you with the digital unit.
In one contract Sylvia Berndt says I will give you pressed flowers if you give me the digital token, but you need to give me some time because I need to borrow the flower press from my daughter. That’s still a contract, that’s still legit.
So this assumes that someone is standing behind the contract as an issuer. The problem with Bitcoin is that Satoshi started from a different frame of mind. In the 90s everyone was thinking client server, I was thinking contracts. In the 2000s we had a different philosophy. Things had changed: p2p turned up. We had seen the morphing of Paypal, the failure of e-gold, liberty dollar, and liberty reserve – and all of these systems had failed.
When Satoshi (the team) were building Bitcoin, they looked at why the systems had failed – they found that it was because behind the contract there was an issuer, something to be attacked. It didn’t have to be a government; sometimes the systems collapsed due to an insider, sometimes it was a thief, but you couldn’t always tell. You know Mt Gox was an issuer, and you know it collapsed but you didn’t know if it was an insider or outsider.
The problem was there was an issuer, there was a contract. Satoshi figured out there needed to be an instrument without a contract, without an issuer, so after lots of thinking they came up with the notion where they just invent the number – they swept away the law and just kept the accounting, which just dealt with numbers. And they deliberately said nothing about what the numbers meant.
They didn’t need a Ricardian contract – in fact they couldn’t have a Ricardian contract because if they had one, it would point to who to attack.
There can only be one
As we found out in time, you can only have one “Bitcoin” in the technical space. As soon as someone tried to copy it, it was by definition an inferior copy. The network effects kicked in very strongly. And so all the altcoins drift away. There became the situation where Bitcoin had to be dominating by the nature of the space in which it operates.
Then what you found was people started to think about issuances and shares, and they came up with concepts like colored coins. This didn’t go anywhere because Bitcoin, although was Wild West, was an unregulated place, where the regulations didn’t exist. If you tried to issue shares in there it was like a red flag.
Legal prose helps to prevent scams
The other thing was they weren’t using Ricardian contracts so they couldn’t describe the obligations, so the users didn’t understand what they were talking about and the space ended up being dominated by scams.
So Bitcoin is the exception that proves the rule that you need a contract if you’re issuing something. Or you’re issuing something without a contract, there can only be one in the space. This is why you get this angst in the Bitcoin community vs the Ethereum people: the notion about issuing another contractless token is attacking the “one true” coin.
So Bitcoin can never use the Ricardian contract.
1:06:03 We also have other blockchains now: Ethereum, permissioned chains etc. How do you think that the existence of blockchains and smart contracts has changed the relevance of Ricardian contracts? Will there be important ways they will work together synergistically, or was Ricardian contracts a precursor, and less relevant now?
Ethereum doesn’t understand issuance
They will merge. The Ethereum people are going through a learning curve and haven’t really understood how to issue an instrument yet. Part of the problem with The DAO is they weren’t clear what the contract was.
When it became a mess, they changed the contract arbitrarily: they used this process they called consensus which they invented on the fly and also labelled as democracy. It was basically arbitrary, and they did what they had to at the time. Essentially they haven’t clarified what The DAO was: it was text on a web page, which they hadn’t linked to the contract on the Ethereum blockchain.
This will continue to happen until they get the idea to lock these things together so people can actually understand what they’re investing in and can guarantee this won’t change arbitrarily the moment any trouble comes up.
The other issue with the term smart contracts is that the public demand is for contracts, not for the issuance of instruments. People want actual contracts that automate themselves.
Automating contracts
If you look at a contract there are parts that can be automated and there are parts that can’t. For example it was impossible to automate the response to the DAO hack because we didn’t know what was going to happen.
If they did it again, they could write in “if we’re hacked, we do this” but what happens if something else goes wrong?
Dispute resolution
So have to say “In the event of (something which we can’t predict), we have to do X”, but the X can’t be automated because we don’t know what is going to happen.
In real life this is called “dispute resolution”, which means in the event of an unforeseen circumstance, go to the court and get a ruling which says do something precise, having been informed about the specific circumstance.
So there’s this area of contracts which can’t be automated for very solid real world circumstances.
Consequently, when you build a smart contract you need:
- Code to do the automation, and
- The legal process that goes alongside it to answer what happens in those other cases
You can’t have one without the other, as we found with The DAO. In the future we will take the two and merge them together.
The Ricardian triple
The Ricardian Contract had parametrisation, and was always possible to add some automation code there, but we never saw the demand.
Now we’ll put them together into a single object so the running code on your Ethereum blockchain will point back to your legal prose on the external document. In this way you lock in the terms & conditions.
You end up with a triple – the automating code, the legal prose, the specific contract parameters. Then we can start doing finance much more easily by taking a boiler plate contract, and adding automation code and parameters. Wrap it up and we have a “Ricardian triple”.
In the future all smart contracts will be implemented this way – prose, code, parameters, wrapped into an object and unleashed onto a chain and run until something goes wrong or it terminates.
So yes, Ricardian contracts are still relevant and are morphing as time goes on.
1:12:15 Another example opens up a big industry: Loans. The total outstanding value of loans is much greater than total outstanding value of shares. A loan represented as a smart contract needs to account for default. However the smart contract can’t impact anything outside the ledger, eg influence other systems like reduce the borrow’s credit rating or go after the borrowers’s other assets.
So if you want to represent a loan as a pure smart contract it would fail, but if you represent a loan as a smart contract plus an Ricardian contract then this combination could open up trillions of dollars in financial assets. You could sell these loan agreements easily on smart contract platforms by securitising and packaging and also get the benefit of law enforcement.
Sometimes you just need to pause the code
When you’re dealing with issues like default it’s practically to impossible to automate the situation, especially as we’re entering the domains of bankruptcy and courts which have very particular rules.
So any attempt to code that up has the potential to make the matters worse. You need to write your smart contract so that when it detects a condition like this it goes into some sort of halt condition (“I can do no more, I have to stop here and pass it to outside world.”). You need the prose to determine how it’s going to happen.
When you have many smart contracts on the same fabric, you can also hand your Dispute Resolution across to a specialised dispute resolution smart contract, that can handle dispute resolution in a much more refined fashion, and can be updated over time.
We are inching your way up the chimney – once you have the issuance of assets on there, you can have other smart contract working to assist the dispute process and gradually you can get the entire financial systems into this space, but that’s years ahead.
1:16:44 At Eris/Monax one of our engineers who is also a lawyer pointed out that it would be quite easy to code in exceptions that trigger other process, eg the bankruptcy process. But then it gets hard once it has been triggered to go back into the automation part. This is a big challenge – potentially years in court, and then trying to return to a smart contract.
Do we need blockchains or just consensus?
Yes, this going to be where Ethereum and blockchain-style design gets into trouble because they’re incapable of easily migrating in that fashion.
This is one reason why Corda goes in a different direction – it only shares the contract between the parties. If the three of us have a contract, we’re the only ones that see it. We can still go into default, a state where it’s stopped. Assuming we’ve written in a dispute resolution clause, the dispute resolution forum can come up with a ruling which is binding on all of us (because we’ve agreed that up front), and the ruling can say “Make these payments back and forth then restart the contract at this point”. The three of us need to work out what the point is, sign it, come to consensus, then carry on as if nothing else has happened.
We can do that because (a) it’s only the three of us, and (b) there’s a ruling that binds us. In fact, we have to, else we’re in breach of contract.
You can do that on Corda, but not in Ethereum, as you don’t know how many Sybils are in Ethereum, and they might not agree to anything. Ethereum is trying to go for maximum flexibility but in fact they’re highly limited in how they can deal with unforeseen circumstances until they can deal with dispute resolution.
1:19:30 Final question – for any new technology, there’s the engineering side and there’s the business side. I’m comfortable that we have the right skillsets to build technology to represent any financial game we want to play with each other, that’s both legally enforceable and automatable.
But there’s the business side: any game changing technology faces a lot of hurdles: legal; regulatory; industry intertia; education. People don’t want to adopt new technology. Keeping keys safe is hard and I sympathise. New technologies only break through into society when we find something that improves some aspect of life for hundreds of millions of people by a factor of 10. That’s a high bar on business side. Does this technology of representing contracts like this clear that bar? In other words, is there a killer app for this technology?
I knew what the killer app was, I’d build it myself and we wouldn’t have time for this podcast!
Inter-entity reconciliation at scale
There are some applications that are attractive, eg the reconciliation problem that causes banks a lot of grief. In a bank’s systems there’s this cancer of differing records disagreeing slightly. 99.9% will agree but the 0.1% that disagrees causes a lot of human labour, and some never get resolved, just swept under the carpet and you have problems with audits later.
If you could use this technology to guarantee that everyone’s looking at the same data, we have the possibility of massive cost savings throughout the banking system.
This is not really an advantage to the rest of the world, because outside we resolve problems by picking up the phone and talking to people and agreeing to change the numbers. But when it comes to corporations communicating with each other at scale, there’s a massive problem when the numbers don’t match up.
The magic of triple entry accounting
That is why triple entry is quite interesting: it takes the magic of double entry that allowed the building of great trading houses in Italy in the 1300s-1400s, and allowed the creation of the enterprise because it could now manage its internal accounts.
It’s a truism if you can’t manage your accounts, your firm will get to about 25 people and will fail, because you don’t know where your money is. Double entry enables you to go beyond that barrier.
Triple entry now lets you do the same but now between the firms so it can now even reverse the process where the size of the firm is related to by the costs of internal transactions. (See Coase’s Transaction Cost Theory)
If you can cheapen transactions between firms by reducing the reconciliation problem, you can start to reduce the size of firms, or you’d expect to see a reduction of the size of firms. So replacing manual reconciliation with cryptography is a very important thing.
The long and tortured path
But the path to making that happen is long and tortured: it’s not one person downloading a tool and starting to use it; we’ve all got to download the same tool and start using it for all our transactions. So it’s not a killer app by itself. Triple entry never really took off, but it may be taking off on the back of other things, without being known about.
A killer app ahead of its time?
The other work I did was in Kenya which involved taking the accounting for social savings and placing that on the phone as issuances of value – that in my view was a killer app. Unfortunately we were way too far ahead of our time.
It’s certainly the case that if you can replace all their accounting with shared accounting, then you can make a huge difference to their lives. This difference can be made across all of Africa, most of Asia, pretty much of LatAm, etc. That’s pretty huge and it will happen at some point.
1:25:58 Thanks for sharing. It will be fascinating to see when it will happen, how it happens, and what unexpected things will happen. Thanks for joining us, Ian.
Thank you.
You could break this long post into smaller posts and schedule their release, so you get more content for the blog and readers like myself can get access to the info within this interview.
Thanks for sharing. One thing makes me confused. What accounting mechanism(single-entry, double-entry, triple-entry)should be built to manage coins or tokens? He said” Ethereum is single entry, with the weakness that a transaction can always be sliced. They then do more research and discover the solution is to implement double entry accounting. ” And then he introduced the triple-entry accounting…..
Thank you SO MUCH for transcripting this! This must have taken you quite some time. I just watched the full interview and followed along on your transcript, which made the whole concept a lot easier to understand. Again, Thank you SO much!