Ian Grigg
On Ricardian contracts, smart contacts, identity solutions, the development of community around blockchain, permissioned versus unpermissioned blockchains, and more.
Transcript:
Jason: I am speaking to Ian Grigg, who is a financial cryptographer and brings with him the incredible reputation of inventing Ricardian contracts and triple-entry accounting, which are technologies that were tremendously influential on Bitcoin and technologies like it. It’s my great honour and privilege to be speaking with him, and we’re going to have a great conversation about his background and how he’s seen the blockchain space develop, from having a much wider perspective on it than probably the average person who is involved in it. Ian, thank you very much for talking to me! Maybe we should start off by talking a little bit about your background and your work.
Ian: Sure, thanks – glad to be here! My background in the work goes back to 1995 when I was sitting in finance classes, learning about zero-coupon bonds and also watching what DigiCash were doing with eCash. I realised that the dollars that they were trying to issue as eCash were very similar, if not the same, to the bonds that we were trying to learn about in finance classes. I got involved with the first venture to issue financial instruments onto the Internet, and out of that came things like the Ricardian contract as the way to describe those issuances as a contract, and also things like triple entry, I think we built the first extant triple-entry system. From there I went through a bunch of different experiments, different migrations of the school up to today, where we’re at the point where we have a lot more knowledge than we had in those days, and we’re trying step by step to implement it and get it all working.
Jason: Can you maybe say a bit about, for those who know yet know, what Ricardian contracts are?
Ian: Sure, yeah. The thing there is that the issuance of digital value comes across a fundamental problem, in that the accounting will just say you’ve got one or 10 or 100 of these things, but the accounting does not tell you what they are, it doesn’t tell you what they mean. It’s best seen with something like a US dollar: a US dollar could be issued by the Federal Reserve, it could be issued by say Bank of America, it could be issued by HSBC, it could be issued by me or you. Now, all of those are fundamentally different, and we don’t have any richness to tell us what the differences are in the term “US dollar”, USD. How do we describe that? It turns out that the best way to describe this is to use the metaphor of a contract, which is to say an agreement between parties. This agreement will be often recorded into a document, and consequently that document can record what the difference is between the Federal Reserve’s US dollar and my US dollar. Therefore, the holder of these things is able to look at the contract and figure out how valuable this is, how reliable this is, whether the claims stand up in any particular court, etc., etc.
Having decided that we should render all this as a contract, the problem then becomes how do you take the contract and place it into the accounting system? The initial knee-jerk reaction of the technologists is to say, “What we do is we render it down into a database form: we read the contract, we identify all the important parts and then create database entries for that.” But that doesn’t work, because it basically destroys the contract in the process. The contract is actually an agreement between parties, and the rendering into words is the best efforts approach of recording that. It also what is going to be adjudicated over. It’s very hard to dispute resolve over a set of database entries, because it doesn’t really capture the richness of the time.
The answer was the flip that on its head, to reduce the geeky tendency to database everything, and go back to the lawyer’s approach, which is to take the document and then mark it upwards with the technical information that we require to make the programs work, because we are dealing with problematic digital cash. The Ricardian contract is basically a system whereby you have a document, it’s got markup in it, and it says things like “The symbol is this, the number of pennies per pound is this, etc., etc.” whatever details you want you put in there. Then we slap a digital signature on it, and we now have a good offering of contract to the holders.
Now, the trick is to tie that into every transaction. We take a cryptographic message digest, or a hash as it’s commonly known, that gives us a unique number for that document. We then put that unique number, that hash, into every transaction that is affected by this contract, so the accounting system then becomes not an accounting system for your USDs but an accounting system for hashes. This has a number of ramifications, the first is that the accounting system itself can’t possibly know, and neither can the user know, what a hash is, what the hash means. There must be a lookup store, you must go to a store or somewhere and say, “Pull out the contract,” and then the program will read through the contract. This gives you the implication that everybody’s got the contract, you can’t actually use the system without having the contract, which solves a lot of legal problems and a lot of dispute problems. It has other ramifications, such that you can now use the contract to bind everybody into a dispute resolution forum, which is very useful because you take it away from the courts and you adjudicate the problem within a community.
It has also got the surprising aspect that it’s decentralised, in that anybody can write this contract, and the hash, the message digest capability, gives you the freedom to come up with a unique number. So we don’t need a registry, we don’t need to have a state-backed official place where contracts are registered; we can simply hash it ourselves and start using it. I guess that’s the Ricardian contract in a nutshell.
Jason: Okay. Do you want to talk a bit about how this influenced smart contracts?
Ian: Smart contracts are a very different thing, the influence is almost orthogonal… Well, it depends on which school of thought you’re thinking about. When Nick Szabo first theorised about smart contracts, he was talking about the holistic nature of a contract, all phases: the negotiation, the recording, the performance and also dispute resolution. But when Bitcoin emerged, and programs or scripts, little programettes if you like, were placed into that architecture, people thought, “Oh gosh, now we can do smart contracts,” but they thought the smart contract was just the code. The code itself had no legal prose, it therefore had no meeting of the minds so it wasn’t a contract.
You now had multiple competing thoughts about what is a smart contract, and what has happened over time is that there’s an emerging consensus that a workable smart contract, we want it to be a contracted law, we want it to be an agreement, a meeting of the minds of the people. Because the “code is law” school has basically failed to make the grade, and this is the very expensive lesson that came out of the Dow: you can’t just have a piece of code, because the problem that occurs is, as we know from programming experience, when we write programs, we write them with bugs, and we can’t get away from that. In fact, we’d all be out of a job if we wrote the programs without bugs, so we’re not even incentivised to do it properly.
What do we do with the bugs? Well, we have to fix them somehow, we have to have an environment and we have to have an understanding of what these contracts mean. What has come out of that is an emerging consensus that we need a wider view than just the computer code; we need to take the computer code, attach the Ricardian contract ideas of the prose, then link it all together and have the hash as being the identifier. So smart contracts have been implemented in a very similar sense to the Ricardian contract, and now what’s happening is that they’re merging together.
The other thing is that once we have that Ricardian prose sitting there, we can also make sure that we have some form of dispute resolution to solve problems like the Dow. Because unfortunately the issue is that unless we do solve these problems in a more formal sense, in a more decisive sense, businesses won’t invest. Businesses are sitting on the sidelines, waiting for a proper form of contract which protects their interests, and also deals, to an extent, with the unexpected.
Jason: Yes – amazing. That said, what would you say the biggest challenges are going to be going forward, in bridging the legal profession as it stands and smart contracts or the blockchain in general?
Ian: The biggest barrier right now is that we don’t have a suitable smart contract framework which is comfortable for people to get in there and use. Things like Bitcoin has shown promise, but it’s not as yet easy enough for the average business to get involved and use it, and that to some extent is just a failure of tools. Ethereum has made a brave effort to move a bit closer to the notion of a more capable programming environment, but they have problems with scalability, they haven’t got a proper dispute resolution framework, and their design is a little bit too theoretic, it’s a little bit too computer sciency. The result is that business keeps its distance, it’s still waiting for it to prove itself. And you can see this in the sense that it’s been going for two-three years now, and what has emerged is a business of ICOs which are proposing projects to finish off what has not yet been done in order to bring in business. If you like, the ICOs are a proof that we haven’t brought in business into the Ethereum blockchain.
So the biggest barrier is literally a platform which allows business to work with smart contracts, I believe, I believe. I mean, that’s controversial, and I work with a company that is trying to build exactly that, so it’s highly biased, but that’s what I think is the biggest barrier.
Jason: Do you think that that’s just law, or is there other business architecture, all kinds of other systems and bits of architecture that need to be validly implemented on the blockchain?
Ian: It’s not law. We have the legal relationships, chief amongst which is the ability to do dispute resolution under arbitration, but we need to build that institution. It’s not that law is the problem; law just needs to be followed, in the sense that we need to build an institution for dispute resolution which gives the contracts some gravity. That we can do, that’s not out of scope, nobody is stopping us and nobody is going to stop us do that, it would be unreasonable for anybody to even try to stop us. So firstly, it’s dispute resolution.
Secondly, if you’re talking about contracts – useful, serious contracts between businesses and persons who want to do serious work – in general, it’s somewhat distinct from the way people think about blockchain. Blockchain at the moment works to the extent that it solves what we call a zero-sum game, which is to say the amount of money coming in is the same as the amount of money going out. Business doesn’t really want to do that though. Certain businesses do, trading is basically an example of that, but that’s not a business where you make money; that’s a business where you take money. The nature of business is that it wants to make money, which is to say we want to do a deal, a trade, some sort of business where both parties walk away with more than they came in. That is not really something the blockchain is very good at at the moment, and the reason for that is the lack of longevity of relationships, which is to say you and I might one deal today and never see each other again. That’s not something where we can do a business trade where we increase the amount of value that is available in the world; all we can do is move one asset from one party to another party, we can buy and sell a house; once you’ve bought a house, you never see the previous owners ever again. You haven’t actually created any actual value between the business parties; you’ve simply moved an existing asset.
So what we need to do is create an environment where there are multiple trades being done by multiple people, and I know that I can come back to you tomorrow and the next day and next week and be able to pick up where we left off. Which is reputation, it’s trust, it’s an ability to be say that I can be a little bit flexible about the terms of the agreement, because I know that if something goes wrong, you’ll be thinking about next week and I’ll be thinking about next week, we’ll smooth it over, and that’s what business needs, they need a blockchain that allows them to do that, which then comes down to identity. We need identity, to the extent that you and I can share sufficient information, such that we can pick up next week. It doesn’t have to be identity as conceived by the state, it doesn’t have to be identity as conceived by the corporation or the bank – in fact, those would be very unsuitable bases – so we need some way to be able to carry on that trade with identity.
Jason: How is that going to be implemented? Obviously there’s issues of cryptography there with identity. How is that going to be implemented?
Ian: Well, that kind of gets to the nub of the problem. Right now there is a lot of discussion, it’s an evolving field, and in essence we’re getting back to a consensus that what we want to do is build a web of trust with individuals participating in the system but also making statements or attributes about each other. The work that’s being done is some fields is to try and come up with a notion of what is an attribute or a statement made from one person to another, and if we can get that framework up and going, then my device can collect all these statements about you, and therefore I can just look at those, make an assessment and say, “Well, you’re a good guy, because 20 other people said you’re a good guy,” and now I’ve got a basis with which to work with you, and you’ve got the same set of information over me, and hopefully that is sufficient. It’s a very opportunistic, it’s a very casual way of approaching the problem, and it is therefore at odds with the authority way of approaching the problem. But the problem with the authority way is that the authorities has vested interest, is part of the scenario. The authority is also set up by one player who wants something in particular, and therefore it’s not general purpose.
If you think about for example a driver’s license, that’s set up by the roads authority. It’s useful to drive on the roads with a driver’s license, but is it useful to go into a bar and show that for drinking of alcohol? Well, only if it’s got an age on it; if it doesn’t have an age on it, it’s not useful for that purpose. You find the same thing causes problems of impedance, mismatch between any form of authority issuance and the usage that you want to put to it. Take the passport for example: I could look at your passport today and say, “I know who you are,” but that might not be the problem I’m trying to solve; the problem I’m trying to solve might be if something goes wrong, can I get recourse? Well, the passport doesn’t tell you that and the passport doesn’t give you any reliance on that, especially if you show me a foreign passport that’s outside Great Britain, which is where we are today, I’ve actually got no surety at all that I can do anything with that information. So have to tear down the custom that says if I know your name and I’ve seen a passport, we can do business. Actually, not necessarily: it depends on the value of the business, it depends on the nature, etc., so we need to find out about that. Identity is a many-faceted issue.
Jason: Amazing. You have a much wider context on blockchain than most of the people working in this space, for obvious reasons. I’m curious what your views have been as you’ve watched blockchain emerge, as you’ve seen it emerge out of the ecosystem of ideas that you were working on and with, and your views of what’s happening with it right now in a wider context and maybe where it’s going.
Ian: Sure. I think the surprising… Well, there are many surprising things about blockchain… Watching it from the very beginning, it emerged as a group of essentially cypherpunks working away to get that blockchain up and going and playing the game of early miner. It then moved across to a predominance of libertarian types, political types who believe in total freedom of contract and keeping to the terms and so forth and so on. But this particular group has a flavour, a species of operation and so forth, and it gradually widened to a group of people who now believe that the value is going to go very high, so therefore they all come in and they hold the value, so you’ve got an evolution of different groups moving through time. A lot of the early players have dropped out for example, and some of them occasionally come back.
Jason: Why is that?
Ian: Well, if you look at something like shall we say the block size debate, which has been very controversial and it has been going on for three years; in fact, it was first discussed around 2010… The people who were in it at the beginning came in for the spirit of the community, and the fact that the community has bifurcated or forked over this particular question is uncomfortable to them. There’s a much more cohesive community around Ethereum, but even then there have been controversial questions that have arisen. So you find that there’s now so many different cultures in there and so many different interests that there are forks of opinion around different issues.
Now, the result has been that gradually, over time, the community of Bitcoin has toxified, and now if you express an opinion, you’re almost forced to take one side or the other, and then the other side will start attacking you and they will do so with a lot of vitriol. It’s an amazing comedown from the lofty ideals of when the blockchain was started, where there was a very principled approach to discussion and finding answers and so forth. Now there is no principled approach at all, it’s one side attacks the other and then the other side attacks and…
Jason: What are those two sides?
Ian: The two sides for the block size debate, one is the core team which subscribes to the notion that it’s technically very difficult to do these things and we should leave that question to the core team to create the solutions and move forward. The other side is the business community that have initially… They had pretty much pinned their hopes on getting a larger use base and more scalability, and this also underpinned their investment plans, but the intransigence of the other side to raise the block size and therefore give them more transactions has caused problems all the way through the business community, and they’ve now backed off and they are waiting, if you like.
Then there’s another bunch of people who believe that they should go forward and cause a fork or cause a change in the software. We saw this right from the beginning, there were people who said, “Okay, let’s just fork the code,” and they tried and failed, tried and failed, tried and failed, and then three or four months ago a group in fact succeeded to fork the code, and now we have another chain called Bitcoin Cash or BCH. Now they’re trying to make that happen with a larger block size, they’ve included a larger block size and that seems to be going okay for them.
Jason: Clearly the Ethereum community has faced similar issues and had a pretty strident debate about whether they should fork after the Dow hack… But you’re more hopeful about the Ethereum community and you think that it’s much more…
Ian: Well, I think it is a community that has not fallen into the vitriol trap that the Bitcoin community has fallen into. But they have their other problems, that they have too much of a central control vision, such that the foundation has outsized power, in the same sense that the core team has outsized power because they make the changes to the code and it has to go through a little group of five people and so forth and so on. Now, is that a problem? It very much depends on what the situation is. For example, with the Ethereum fork of last year, the issue there was not so much that a fork should or shouldn’t have been done; the issue is how was it decided. Was that decision process something that was arbitrary, or was it something that we could repeat or rely upon?
If you think about for example smart contracts, say you want to do a big business, pick Uber or something, we’re going to do Uber on the blockchain, and we can do that, we know how to do that now. Would you go out there and place 100,000 contracts between different parties that are extant and running and working and so forth, knowing that at any time something could go wrong and the whole lot could fork? Imagine you’re doing some sort of delivery system, maybe you’re Amazon and you have contracted to move all your supply onto the smart contract framework, and then it all forks. Do we now have to deliver twice as many purchases? Do we now have to chase twice as many purchases to pay twice? These are real problems, and without a framework that handles that question, businesses are going to hold back, they will continue to hold back from investing in serious businesses on Ethereum until that’s resolved, because it doesn’t make sense.
Jason: So that’s the key, that’s the turning point that needs to be solved.
Ian: Well, I think if you want to be flippant about it, we need a business-friendly smart contract platform. But to be more precise, we need a smart contract platform that isn’t arbitrarily forked, that isn’t subject to arbitrary decisions, that doesn’t cause the business owner to lie awake at night, thinking, “Will it be there in the morning?”
Jason: Here’s a crucial question: is this solution going to be developed by the wider community, or is it going to be developed as a proprietary thing by a business or a consortium of businesses as potentially a private blockchain?
Ian: This is getting into the question of permissioned versus unpermissioned and so forth. Some have tried to create a blockchain for a regulated group or an industry group or a tighter group. There’s a bit of a problem there though, that they tend to assume that we set up what we call a walled garden, and that is a permissioned network where only people who have the permission can come in. But the problem with the wall is that there has to be a gate, and the problem with the gate is that there has to be a gatekeeper, and the gatekeeper sets the rules and charges a fee, so we now have a centralised point of control. This works very well in the early days, if you can get that far, but as time goes on the gatekeeper acquires more power, raises the fees. The second problem that happens is that the incumbents on the inside capture that process and reorganise the process to suit themselves.
Jason: What’s a good example of this happening with prior technologies?
Ian: Banking, for example. If you look at the national markets of many countries, you’ll find that there’s four-five national champion banks and nobody else can get in, and the reason is that those banks have now become so interlinked that they can block other entries from coming in. They also have deep and long-lived relationships with the regulators, such that in many cases the legislation is written by the banks, for example. Consequently, you have a problem… Let’s say you spot a problem with the banking market and you think, “I’ll start another bank to solve that problem.” Well, you can start the bank perhaps, but how far can you get with the combined weight of all those other banks keeping you out? In many circumstances, if you look at for example the notion of Bitcoin credit cards, we’d love to have that, we’d love to have a little card which attaches to our Bitcoin account and we can go into a restaurant and pay with Bitcoin and so forth and so on, but the banks won’t allow that, they will see that as competition. When they figure out this is happening, they’ll do the investigation, find out which bank has issued these cards, phone them up and say, “Do you really want to do that?” It just takes a phone call.
Jason: But couldn’t the banks start co-opting this technology and implementing it? Clearly they already are implementing it into their existing frameworks.
Ian: Well, they could try that. The problem is to whose benefit? Do the banks make a profit doing this? Normally, what happens with this sort of thing is that the banks will look at the use case of how they would integrate with new systems and they can’t find the profit for them. The second thing that happens is they might find some profit from them, but it comes at a cannibalising of some of the business. So it’s only in the outside chance that it’s going to create more profit for the banks will they perceive this as a good thing. To some extent, people would say the whole promise of Bitcoin was cheaper money, money we could use and money that didn’t charge us international wire fees, so it’s… You can come up with a case where it might be that the banks could find this as being profitable, but the only way they would do this is to flip all of our assumptions on their head, and consequently that’s not Bitcoin.
Jason: Certainly I’ve heard people talking about for instance removing costs from bank-to-bank transfers as a use case for how banks could implement it. Do you have a sense of timeline in which big business, big banks and the blockchain could come to a kind of meeting point?
Ian: That’s a topic we did look at very closely with R3, which is the banking consortium, I was there for quite some time. Again, it depends what you’re trying to do. If you’re trying to use blockchain inside banks, you have to ask the question is blockchain the most efficient way to do what the banks are already doing, and to a large extent that’s a square peg in a round hole. The banks don’t have a problem with that level of trust: if they wanted to, they could easily take blockchain, turn off the mining, designate somebody to be the signer of record if you like, and now we’ve got a situation where it’s a blockchain without mining, without proof of work. Is that a blockchain? The other extreme is why not just use a database? Because as you go through these various steps, you end up carving this off and that off and this off and that off.
The only time it makes sense to use a blockchain in its understood form is if you’ve got otherwise adversarial parties who could come to a deal if they could only program it and therefore guarantee each other’s fairness. The banks aren’t that adversarial, they will work together on a trade as long as they can see the profit in it. They will also do things like break trades, but it’s a very different sort of assumption. You need to come up with a notion whereby the banks might for example find themselves unable to work, and this is not the case with banking as it is today. The other problem you’ve got is that when banks deal across borders, you now have multiple regulators involved, so consequently it becomes even messier and blockchain isn’t speaking to that question.
So I think it’s very unlikely that the banks themselves will start using blockchain as it is commonly understood to handle payments. To an extent, this is why for example products like Corda, which is built by R3 and was built when I was there, have stripped out many things and they’ve come up with something that isn’t quite a blockchain. In fact, it’s not a blockchain at all; what it is is an ability for two parties to contract digitally and in a triple-entry fashion, moving data back and forth, such that they reach that state where each party knows that what they see is what the other party sees, I know that what you’re looking at is what I’m looking at. That’s a very different approach to the problem, but it does give banks, especially banks in different countries, something to work with; it’s just not blockchain.
Jason: Okay – interesting times ahead as we resolve these questions. I’m wondering if you want to talk a little bit about the projects that you are working on now.
Ian: Sure. At the moment I’m working with block.one, which is a company that is producing a blockchain software suite, EOS.IO we call it. It’s a software engineering approach to the problem of a highly performant blockchain, that uses many, many techniques which solve a lot of the problems that are out there, and it’s designed from the orientation of small business. What does small business need to get up and going? It needs an environment, it needs dispute resolution, it needs some modicum of identity, and it also needs very, very high performance. This is based along a long line of technologies, starting off with a group called BitShares and then another thing called steemit, which I think remains perhaps the most important example of a blockchain technology.
Jason: Really, steemit?
Ian: Yeah. Let me put it in very simple fashion: it’s the only blockchain where the users don’t need to know that they’re on a blockchain, and it’s busily working away with lots of users writing blog posts to each other back and forth and making money. Where can you see that elsewhere? We don’t have many examples of distributed applications where it’s actually working. What we do have is some oddities like gaming and ICOs, we’ve got trading back and forth of assets, but these are all internal applications… Well, gaming is not an internal application. But again, all three of those things – trading of assets, gaming, ICOs – they’re all zero-sum games. Whereas steemit is showing a net-positive game, it’s actually I write a blog post and you actually get appreciation of that and you pay me money for that, so I’m making money and you’re also achieving appreciation because you’re getting something out of my blog post. It’s a very powerful example of what could be done, and we don’t have many of those examples. If you look at for example the banks and the consortia and so forth and so on, especially the big consultancies and the accountants and so forth, they’ve all gone through these processes where they’ve mapped out all the use cases of where blockchain would work, and the record is pretty slim.
Jason: Okay. What excites you most going forward into the future of blockchain?
Ian: Firstly, I don’t think it’s about blockchain. I think it’s about a wide variety of technologies, that when they come together they create a freedom of contracting and working together. For example, identity has almost nothing to do with blockchain. Of course, everybody thinks blockchain is the hammer so you must find some people with a nail with your identity ideas, but that’s not how it’s going to work. Privacy kills that pretty much completely dead, you can’t put identity information on the blockchain, there’s no point in putting it on the blockchain. What you want is an identity framework where two people can meet and exchange information and then be comfortable about what happens next; blockchain doesn’t add anything to that.
I think it’s about pulling together the identity ideas, the blockchain ideas for mediation of certain problems and various other things together, which allows us to then get a freedom of contracting, of trade, which is resilient to the future. The big danger I think is that we still haven’t got a solution to the GFC. We’ve been doing this for gosh, it’s been 10 years, it’s been a decade, if you go back to 2007 when it first started off with Bear Stearns and so forth and so on… There’s no solution in sight. They’ve just poured a lot of money in, nobody has gone to jail and they haven’t changed the rules to any significant effect. In fact, they’ve made it worse in some respects by bringing in bail-in for example. They have not solved the fundamental problem of bank-created money which is uncontrolled. So we have a… It’s not just exciting: we have a very necessary need to build an alternative framework, because the current framework is going to have a problem.
Jason: If somebody wants to find out more about your work, where can they go on the web?
Ian: financialcryptography.com has a lot of posts, I think there’s about 1,500 posts. Since recent times I’ve been posting more on steemit and Iang is the name there. Also, Iang.org, papers for example, rights and there’s a bunch of older stuff on there. I guess that’s about it.
Jason: Ian Grigg, thanks so much for speaking to me – it was a great pleasure!
Ian: Alright – thank you!