The Future of Stuff

Ian Grigg on Crypto, Identity, Community, and Building Positive-Sum Systems

Episode Summary

Ian Grigg is one of the most influential builders in the crypto space, having built digital asset systems since the nineties. We discuss his invention of the Ricardian contract framework, what makes cryptonetworks successful, identity as communal phenomenon, and the importance of building positive-sum systems.

Episode Notes

In this episode, I had the pleasure of talking to financial cryptographer Ian Grigg (@iang_fc). Ian is an unsung hero in the blockchain/cryptocurrency space, having built crypto-based digital asset systems since the nineties using the Ricardian contract, a design framework for binding software with legal agreements that has been the foundation of many crypto projects over the years, including Mattereum. We discuss the invention of the Ricardian framework, its design philosophy, the importance of community in the formation of one's identity and the success of entire cryptonetworks, as well as the critical need to shift our focus from building zero-sum games to crafting positive-sum systems that benefit everyone at the expense of no one. I learned a lot from Ian in this conversation, and I hope you find the insight as enriching as I did.

Track: "Optimist" by Zoe Keating


Episode Transcription


  1. The Origins of the Ricardian Contract [00:01:20]
  2. Ian on the Advent of Cryptocurrencies [00:09:27]
  3. Blockchain is Just Another Tool [00:12:47]
  4. Mattereum's Building on the Ricardian Framework [00:14:46]
  5. The Cost and Necessity of Building Governance [00:16:35]
  6. The Chamapesa Project [00:20:53]
  7. Identity Through Community [00:24:05]
  8. Dissonance Between Identity Frameworks & Societal Expectation [00:26:02]
  9. Reputation & Identity in Cryptosystems [00:28:19]
  10. Zero-Sum vs Positive-Sum Games [00:33:10]
  11. Ian on Encouraging Ricardian Contract Adoption by Devs [00:38:21]
  12. On the Future of Smart Contracts [00:43:04]
  13. Improving Asset Custody in Smart Property Systems [00:47:11]


Welcome to the podcast Ian.

Ian: Good to be here.

The Origins of the Ricardian Contract [00:01:20]

Garrison: A lot of people who are kind of familiar with what Mattereum does and how it approaches building things may be familiar with the concept of the Ricardian contract as this kind of hybrid system for integrating  contractual agreements with software that executes the agreement. That's kind of foundational to what we do. It's also been used in a lot of different projects and inspired a lot of amazing work across smart contracts and formation of entire digital organizations.  Could you kind of describe how the Ricardian contract was formulated?

Ian: It all happened around about 95 to 97. What was happening there was that digital cash was a hot topic, a very hot topic. And it was kind of funny because when the Bitcoin thing started out and that became a hot topic, it was just an echo of the nineties to a lot of us who had already been there, done that and so forth, seeing what would happen.

While the digital cash people over in Amsterdam-- that's DigiCash, David Chaum's company-- were doing digital cash, I was sitting in finance classes and learning about zero coupon bonds and a zero coupon bond is basically like a dollar note, if you like, or a pound note or something like that. And listening to all this, I realized that actually, if you're trying to do digital cash and digital cash is a dollar or a pound or a Euro or whatever it was, and a zero coupon bond is the same thing. The zero coupon bond is actually the atomic element of finance in terms of mathematical modeling.

From that you can build up everything else practically speaking. You can build up derivatives as constructions of zero coupon bonds. And it occurred to me that, well, if we can do digital cash, we can do everything in finance.  This light bulb moment got me thinking. And I started out with a mate and I moved to Amsterdam and we started working on digital cash and digital assets. The ones we chose were bonds and to cut a long story short, the thing about bonds, I did a lot of research into this. It took me six months to figure this all out. Bonds are legal contracts. If we could do a legal contract in a digital form, then we could do bonds. And then a bit later on it transpired that bonds themselves are just the simplest form of financial instrument. And most other things are based on the contractual mechanism.

Most of them. I mean shares are based on government say-so, but even then shares could be based on contracts. So we could do everything if we could do contracts. And I went through a long process of trying to work out how to do contracts. I got stuck on the normal computer science notion: oh gosh, a contract is a bunch of data so we shove it in the database and we get stuck into normalized forms and all this sort of stuff. Which is normally good stuff.

And the world often reduces to that in computer science terms which is why so many databases are built out there in the world. But the contract just didn't work. I discovered that bonds, for example they were lots of lots of words which had very strange meaning, especially to a computer scientist. The bonds didn't have standard words. And every time somebody came out with a new bond, they changed the wording. And it was often just a little bit. So you wondered whether they were responding to new events. There'd been some new crisis or whether it was just the lawyers deciding that they needed to generate fees or something. But either way, didn't really matter to us. The bonds kept changing, so databases just didn't work.

And at that point I had this second light bulb moment. If you like, when I said, "Okay why don't we flip the problem upside down, give the lawyers what they want, give them a text document. It will make the computer science side work harder than try and pander to the computer programmers. We'll pander to the lawyers.

So we constructed, or I constructed a simple text document, which included the text of the contract. And instead of it being, shall we say, all the words that the legal people wanted to wrote, write, and nothing more. It included some parameters in there. And these parameters were very simple line based things, which said something like name equals 2009 bond from the Pacific railway. And the denomination could be in dollars and so forth. Simple tag equals value. And what that meant was that the program could dive into the document with a very simple parser. We're talking about a line based thing which can be knocked up by any decent programmer. Read down, grab out the tags. And then with that document, the software could then display it to the user. So the software didn't need to be didn't need to know what the contract was beforehand. It got all the information it needed out of the contract, such as the denomination, such as the decimalization, the symbol to display. And then when it came to showing the user what was going on, it could simply use those tags without necessarily understanding them.

Which if you think about it, that's what you want. If you're going to be handling many, many bonds, you don't want to know what the bonds are in advance. You don't want to modify the software for every bond or every asset or every Bitcoin or every Ethereum or whatever. You want a standardized document that tells you what it is.

So out of that process, we added rooting to find out where the actual asset was, was managed. And we added digital signatures, such that the issuer would make this claim as a contract. And that was the method.

The funny thing is we didn't realize that what I'd come up with was much of an invention, but we found every time we were talking about it we were saying, well the way you issued a bond is you write a contract and it's the contract form that's inside Ricardo, the name of our digital cash system. And that got shortened to the Ricardian contract. Hence the name. So eventually after our gosh six or seven years of having these conversations, I realized I had to basically publish a paper on it and did that. So from then of course everybody could just refer to the paper. So that's the foundation of it.

But it's quite interesting because we did discover it was very broad. We could do every sort of financial asset with the Ricardian contract. And not only that other people came along and did other things with it.

Chris Odom turned it into configuration files. The configuration of his software was a set of Ricardian contracts.

And the OpenBazaar people turned it into a trading cycle in that their invoices, for example, would be a Ricardian contract. And that would refer back to a previous author to enter into a contract. And then the receipt, for example, would be pointing back to the invoice and the payment would be pointing back to the receipt. So they had these chains of things where they're basically pointing at each other. And that was very interesting because it created this cycle where everything was available and everything was documented in cryptographic security which allowed a lot of software to work pretty much perfectly. And it removed the problems  that are caused by insufficient information. So yeah, it was interesting.

Garrison: Yeah, it's a really interesting kind of design space. Paper you wrote "The Intersection of Ricardian and Smart Contracts,"  you have this kind of X and Y axis of where the Y axis I believe was like semantic richness. So it's more leaning into the, natural language kind of agreement. What we traditionally think of as a contract document. And then on the X axis you have operational richness, which is basically what's actually  executable by code. And I think that's a great kind of mapping of how to map things that are working in this kind of legal tech.

Ian: Yeah.

Garrison: And it can vary from asset to asset from use case to use case. There's so many possibilities there.

Ian on the Advent of Cryptocurrencies [00:09:27]

Garrison: So when Bitcoin and smart contract platforms like Ethereum emerged. With Bitcoin, we had  I guess you could say like the first digital cash system that kind of persevered or kind of survived and kept going and withstood regulatory friction and a lot of forces of nature kind of working against it. Then we had Ethereum that emerged six years later, or, handful of years later, and it kind of delivered on this, on this promise of the smart contract, which Nick Sabo proposed in like 1994.

So when these cryptocurrencies and smart contract platforms emerged, what was your initial response to them in relation to this digital cash system that you had actually created.

Ian: Mm. Yeah. Well, I was in the cryptography group when Satoshi published and discussed and eventually published his paper.

And I read the paper at the time. I didn't like it.  The key thing was, it was a very clever invention obviously and I realized that at the time, but this notion of having a competition for consensus meant immediately to me, people are going to be burning energy on this thing. And that seemed to me to be an unsustainable expense. But actually the author was clearly a lot cleverer than I was and had managed to constrain it, such that it didn't completely get out of control. It was a stability involved based on the price which we didn't really see it until prices actually started to move from zero upwards. But then, there was a stability in the system based on the number of people who were trading these things which was very clever. And obviously a massive breakthrough.

What was the big issue there was because considering that I had come from the client server world, we had all been thinking that client server was the only way to do it. But what we had entirely missed was that the server was always a weakness. And we had been somewhat blinded by our, if you like, our bias towards client server. So whenever one of these systems failed, we hadn't treated it as a server failure. So for example, I was involved in the e-gold community.  built a thing called Digigold. You could consider it to be e-gold version two or something like that.

Which we got up and going, but it got into trouble through the actions of the people involved. I mean, to put it short in short terms, I and Douglas Jackson, the e-gold founder, got into court battles and so forth and so on. And, because I was the guy who was running Digigold and he was the guy running e-gold, these things didn't survive because the founders behind these systems got into distracting arguments.

And it wasn't clear that the problem there was the architectural problem was that there was a founder, there was an owner, there was a contractor party, there was somebody managing the servers. The inspiration of this, of Satoshi, was-- yeah, that's the problem. The people behind the servers or the people behind the center are the problem, not the solution. So let's figure out a way to remove that. And that was the big that the huge breakthrough that changed everything.

Blockchain is Just Another Tool [00:12:47]

Garrison: And was there kind of a moment where there was like Bitcoin or Ethereum that you thought that: finally there's like the infrastructure that we needed to do the things that you had envisioned or was it just another tool that kind of just emerged?

Ian: No. I think it's just another tool that it merged. Obviously did a lot better than what we had done. There was a moment where I decided that actually this thing had passed the test of time and was here to stay. And that was when a fund in America paid me to go and be their dark horse.  They're anti-Bitcoiner.  Through that process where I sat in front of 20 or 30 potential investors into their fund and I argued against Bitcoin and so forth. And when I saw what was happening there, I thought, okay, this is interesting. Regardless of what I think technically, we're now at the point where enough people will believe in this thing such that it will sustain and it's clearly sustained itself in the past. So, well, I kind of flipped at that and realized, well, this thing here is here to stay.

Not that I've ever got over my, if you like, my distaste of the proof of work consensus, load cost, and so forth. So I actually, I was very happy to join the Block One crowd and work on DPoS, delegated proof of stake, because that is a system that gets rid of the expensive proof of work mechanism. Albeit it brings in its own problems. So if you like the proof of work thing gives you open access and open entry, and therefore it is in a theory, it's a fair mechanism, whereas delegated proof of stake encourages the problem of cartelization amongst the block producers. Which eventually causes problems  unless you're very careful to keep that down. There's swings and roundabouts, there's pluses and minuses with all these systems. So you have to be very careful about what it is you're trying to do before you choose one of these mechanisms.

Mattereum's Building on the Ricardian Framework [00:14:46]

Garrison: Yeah, absolutely. So to kind of bring it back to Mattereum, it would be fun to kind of explore  initial conversations you had with Vinay when he was like conceptualizing Mattereum and thinking about it. Could you unpack what was part of those conversations? Those initial conversations.

Ian: To be frank we didn't have that many conversations on it. Vinay has always been very, very solid about saying that basically he's just building on the Ricardian contract and the governance techniques that I did in the nineties. There's a thing called five parties model, which I put together in the nineties. It wasn't so much an invention as take classical governance techniques and lay them out and just slot them into the digital world. This is what we did at e-gold and Gold Money and the various other players. And it's what they should be doing with the stablecoin issues for example, and also ICOs and so forth, but they haven't learned this yet.

These things were all available to Vinay and I think, yeah, he mostly did his own study on it.  He really came back to me and said, what about this? What about that job? He just seemed to drink it up. So it's unusual to find somebody who can actually drink this stuff up just by reading the documentation.

Garrison: Yeah. I remember like when, he was telling me the kind of origin story, if you will. How he was basically like screaming into the void at the rest of the people in crypto. That we have to get the legals right in order to actually properly integrate the system with the real world. If you want this world changing potential of blockchain, you have to be able to connect  these two realms  in an effective way. And most people would just completely ignored him. So then eventually he founded a company that was aiming to do just that.

The Cost and Necessity of Building Governance [00:16:35]

Ian: Yeah. And it's interesting because I faced the same dilemma. We issued gold in around about 2000, the Digigold thing. And we issued physical gold in 2002 thereabouts. We had a kilogram bar, which was our reserves.  The custodian was designated as a person. The mint was designated as a person. Todd Boyle, the accountant, was in fact part of that circle of governance. And we got the whole thing completely right, and issued it and so forth. But it was interesting because some people appreciated that but the vast majority of people didn't really appreciate what we done. It was a if most people would look to other people for validation. And therefore you had this wide open space for scams. All you had to do is generate the sense of validation in some sense, And everybody would pile in because somebody had validated it to them and they'd been validated by somebody else. And it eventually becomes a circle. But to do it properly is actually a bit of work. It took us a month to set up the governance, just the governance of the gold bar, for example, in terms of agreements and contracts and understanding, getting everybody on board for the parts that they play. 

It's quite easy to fall into the trap of saying, "Yeah, let's ignore all that stuff, throw it out there and see what happens." And of course, people start throwing you money. And what, somebody once said to me, or somebody frequently said when there was, if you like, opposition to his ideas,  he kept saying, "People keep sending me money and therefore I know what I'm doing." And he was right until he wasn't right. And it all came crashing down and that's where you need those better mechanisms. So if you're in it for the long run, yeah, you need to do all this stuff.

And actually that's a really good way of figuring out whether something is a fraud or not, or something is  going to be undermined and fail. Or not, it doesn't necessarily have to be a fraud. Do they do the governance? And the governance is fairly simple. It's all standard. It's all documented. You just follow these steps. Did they do it, or did they not? But nobody seems to want to get into that because it's not sexy. It's not tech. It's not

Garrison: Yeah. It's very human.

Ian: Yes. It's not this magical consensus thing. This proof of work and NEMIS keys and all that sort of stuff. 

Garrison: One of the projects that Mattereum is working on currently is launching gold-backed NFTs. Which is kind of like just the recent iteration of the kind of gold digitization that e-gold did and Digigold and. It is true. It's a lot of work to deal with all the humans or wet code that's kind of necessarily involved to do the right governance. And when you're, when you're dealing with physical objects and stuff like that. If we can do that process well enough and perhaps streamline it over time, it opens many use cases in terms of like what kind of assets can be created or managed. Or opening access to certain assets.

If we can get the governance right around digital assets or digital assets that are tethered to physical objects, then it would open up a lot of doors for us. Like just as a society in terms of managing commerce and production and consumption. But you know there's a lot of tough work that you have to do in order to kind of get to that future.

There's a lot of things that you've worked on that I've been very fascinated about. Whether it's governance. Governance of entire blockchain networks, like with the design of EOS, for example, or integrating crypto with like existing social structures, which I find really fascinating with like Chamapesa.  You've explored a lot of the different kind of use cases of these technologies, drawing upon like the foundational work and thinking that you did around the Ricardian contract. Like what, what excites you these days? What actually stands out to you?

The Chamapesa Project [00:20:53]

Ian: The work I do these days is still the old Chamapesa project.  It's working slowly because I'm having to code it up myself. I guess I should say a little bit about that. The notion that you can come together as small groups and you can decide to commit as a group to do savings together is something that can be done completely disconnected from the financial system. So you've actually created, if you like, your own answer to financial inclusion because what you've done is you've excluded the financial system from yourselves. The financial system was already excluding you from their participation. So you have to start again.

But it only works not as individual system and not as a large community, but as a small group. It only works because what you can do is you can choose the members of the group to start from a very high trust level, even in a totally corrupt environment. Enough people very close by and you can select from them who is trustworthy and bring those together as a very small, tight, trustworthy group.

And on top of that, you can do all sorts of things because we're trying to do savings in these groups. That means we're handling each other's money and therefore we're very dependent on each other. And once we get that level of trust, it's possible to do a lot of things. We can interact with other groups. We can do supply chain. We can do organizations of payments, for example. We don't need to worry too much about who the other party is as long as we know which group it is. We can rely on the group to look after its members. We can do things like identity. There's a lot of things that we can do.

So consequently my work these days is trying to build a platform which works with those groups and allows them to, if you like, utilize their capabilities in better ways,  in more powerful ways. As I say, it's slow work cause I'm doing it all myself. 

Garrison: I love that concept of like focusing on smaller groups and then scaling from there. That's just natural to how people organize and cooperate with one another. Something that I pay a lot of attention to is projects, both within crypto and outside of crypto that are kind of founded on more like, principles of cooperation and interdependence rather than absolute independence, assuming that everyone is working in their own selfish interests. I don't really buy into that framework so much. But I really liked that idea of scaling up from existing social structures and trust relationships, because you could apply that to  social savings groups in Africa. But also in other parts of the world, cooperatives  throughout the world. The context could vary from just the community to art co-ops or studios and stuff like that. 

I really like that kind of approach to things. Cause a lot of people try to have this monolithic solution. We cook up some solution in Silicon Valley and then we try to export it to other parts of the world in different cultures. And it's like that doesn't work out.

Identity Through Community [00:24:05]

Ian: That doesn't work out at all. Yeah. It's interesting. You say that it's natural. It's actually more than being natural.  It's who we are. Because if you look into it, try and figure out where all this came from, it traces back to basic anthropology and society in the sense that if you start, for example, with the child or the baby that's born on day zero, they're basically a tabula rasa, an empty slate, blank slate. And there's nothing in there except the ability to cry and suckle basically. But if you shift forward 20 years or so, you've now got a working functioning adult with all the sophistication that is needed to do complex trades to engage in negotiations, to date with a person and start a family of her own.

So how did this happen? Well, actually it turns out the answer is very much in groups. It starts out with the mother of course, bringing the baby up, but pretty soon on the father turns up and upsets the very cozy arrangement that the baby had with the mother. So the baby now needs to learn how to deal with the father, which creates a sense of identity. And then they've got siblings and uncles and aunts and grandmothers and so forth. So actually the child is brought up in the context of a group. And therefore, when it comes time to leave the nest, when the child is booted out, because she's now an adult and she's got to go make her own way, she carries with her, this, this shall we say, groupness, this sense of identity inside a group. So naturally she's quite happy to form another group or to participate in a group or to find a group.

Dissonance Between Identity Frameworks & Societal Expectation [00:26:02]

And the reason we don't really treasure this, we in fact avoid it in, if you like, academic discussion is because of the Western tradition for the last 500 years or so of individualism and capitalism.  We treasure the notion of individualism and capitalism and so forth. And you're going out to fight in the markets and become a millionaire by the time you're 50 or whatever it is. These things are inculcated as the way we work in the world, but it's not the way we work in the world. The way we work in the world is inside groups.

So the whole Western economy, if you like, has this dichotomy where we've got this theoretical notion of individualism fighting with our natural sense of community in groups, whereas we go outside the Western world, they don't have the dichotomy. They're much more oriented to the notion of, "Yes, we are naturally in our groups. We have groups, we work with groups, we have extended families. We have community groups, we have this, we have that. That's how we do things." So they don't have that, if you like, collision of ideas.

Garrison: It all comes down to people's framings of identity. Crypto is, in large part although it's certainly changed over the years, tends to be a little more very capitalist driven, libertarian, rugged individualism. It's kind of lacking in the kind of interdependence and kind of cooperative principles that you find a little more in other cultures. Or at least it's more prominent or foundational to other cultures.

I love your example of how an identity is formed because there's like a-- what was it? I don't know if I'm saying that right--concept of like "I am, because we are."

Ian: Yes, indeed.

Garrison: Is that what it is or am I misquoting?

Ian: That's exactly what it is. Yes, yes. Yes. I am because we are. I am the person that my community defines myself, defines me as. I am the person that everybody around me, who I hold close will say that I am. And my position in the community is my future, if you like. I'm not an individual, I'm a member of a community.

Reputation & Identity in Cryptosystems [00:28:19]

Garrison: The paradigm for awhile, at least in the blockchain space, has been. Assuming that the networking question has some sort of protocol token, that the more of that said token that you have, the more power you have or that kind of defines your presence within that ecosystem. Whereas there's other design approach where it's like, okay, well, identity is more about connections between people and your history. So like how do we, how do we build that? And kind of  operationalize that.

And you're starting to see people kind of talk about this more often lately and like the past year or two about like on chain reputation, or kind of being able to aggregate your on chain activity in a way to kind of prove that, oh, you've contributed to this or contributed to that.

It's a little more meritocratic. Rather than kind of this. Identity along the edges that we're talking about, but you're starting to kind of see that shift.

The core principles.

Ian: Yeah, people have been talking about reputation since the beginning of computer time. It was a topic in the nineties and every year or two, somebody would come up with this new concept of putting reputation onto the internet and it never works. It never works. And the reason is that reputation is a very broad group-wise thing whereby in my head, there's something about you and in your head, there's something about me.  It's almost by definition, not quite by definition, but almost by definition, you can't reduce it to a number. You can't reduce it to a database entry. I mean, they do these things with credit scores and so forth, but obviously that's such an approximation that it misses out the richness of what's going on.

And so, consequently, I think anybody who's talking about reputation first hasn't understood the problem at all, and they will waste a lot of time. It turns out that reputation, if you like, comes from groups, comes from identity, comes from trust and so forth and so on. So you have to talk about those things first. And once you've got those things sorted out, reputation not only falls out very simply, it's not particularly important. What's important is what you've built. 

You can see all this in world of, for example, ICOs and token sales and so forth. People looking at the number, the amount of tokens, and they're saying, "Well, this is the power. This is the goal.  This is why we're here." But actually the numbers are just the outcome. And if you go back and you look at the process of say, successful token sales, you've got this situation where some of the ICOs are fluff. There's nothing in them. Then others of the ICOs are actually really good projects and really good people and so forth. But one of the ICOs might make more money than the other, or raise more capital or sell more tokens or whatever it is. And it's not necessarily correlated to how good the project is in a technical sense. You mean, you could look at two white papers and say this one's good this one's bad, but the bad one makes more token sales than the good one. What it's really correlated to is the strength of the network that the founders bring to the table.

So if you look at, for example, the EOS thing, which I had a lot to do with. It sold tokens to something like $4.1 billion or whatever the published number was. I don't know what the real number was.

Garrison: I believe it was the largest of its kind. To this day, it's the largest.

Ian: An order of magnitude. Yes. The only one that came close was the Telegram one, but that had to be wound back because they got in trouble with the SEC. Anyway, the reason that happened was because of the strength of the network and that network was a broad group of people who were already operating the BitShares network and the Steemit network. So there are already thousands of people across the world who were interested in, shall we say, Dan Larimer's next venture. That whole network moved in to purchase the EOS tokens, making it very large. So yeah, the notion of relationships and networks is more or less ignored by the technical community, but it is the key 

Garrison: And there's a potential risk there as well. if you have a powerful existing network that carries over, especially if it follows like a particular builder or a founder, you do run the risk of cartelization. Because they're like, "Oh, well, we can  put the stakes down, claim our territory right out the gate and it can cause more centralization, cartelization moving forward.

Zero-Sum vs Positive-Sum Games [00:33:10]

That idea of the network, the kind of social ecosystem that surrounds the project is kind of what lends to its success.  It seems interesting that there's this tendency to completely ignore this kind of like what we've been talking about, this kind of more social ,community-driven, interdependent aspect of things, which is  natural to us as human beings. But there's this tendency to think of it as, oh, it's just a flaw that needs to be fixed with some new some new application. So it can be kind of difficult to kind of like steer the blockchain community to like kind of thinking more along these kind of lines of interdependence rather than just everything is competition over cooperation and stuff like that. And that's just. Differences in philosophy, I guess.

Ian: Well, it's differences in economic models, if you like. Those people who are focused on the pure mechanics of a smart contract and the zero sum game, and the notion that we can do these things without having to trust our counter parties. Missing the fact that actually, even if you do these things, there is going to be a large proportion of people who aren't trustworthy coming in to game the system. So you're going to end up with, if you like, a very adversarial community. Which is fine if you get it perfectly right, and your use case just needs that. But the vast majority of use cases do need some form of trust. They need some form of positive engagement such that you can actually do things together.

For example, just the issue of not being able to hack the smart contract is an issue of community in the sense that the hacker is part of your community. Now, what is incentivizing the hacker to not hack? We know what's incentivizing the hacker to hack, that's getting all the value and stealing it, but how would you incentivize that person not to hack and without thinking about that, you're basically creating, if you like, a very technocratic foundation.

We've been doing software since 1943 or thereabouts. And what we have discovered is that software always has a terrible amount of bugs. A huge number of bugs. So when we go forward and say we've got this wonderful machine, the smart contract, that can be written to do a perfect zero sum game such that everybody's happy. Well, that's total bullshit. We just don't know how to write good software either as a discipline or a profession or whatever. It's just not on the table. So we're fooling ourselves. We're representing something that we have never really mastered. There is an exception, and that is  the spacecraft software, software to run the space craft, the shuttle, so forth. But even there they've had quite a few disasters based on program. So yeah,  we just can't prove this. So we are living in a world where we have a cognitive dissonance where we believe two separate things. That software can create this perfect zero sum game, but we know we can't do anything perfect with software.   

Garrison: One of the things I kind of hope for is kind of shift from zero sum thinking to positive sum thinking, like creating systems that by design are intended to encourage positive sum games or outcomes. Cause it's just better. I think it's better if everyone that's interacting within a system they all benefit in some way. And it seems like it's just a design approach. But there's a lot of core philosophies that kind of drive or influence how people think about things much less actually build them or implement them.

Your example of the spacecraft. Or even airplanes. That software that has in the event of a failure it's catastrophic. There's a sense of lives at risk. There's a weight to it.

You don't really see people thinking of smart contract development, building decentralized finance protocols, thinking necessarily with that same kind of weight. Responsibility with what they're trying to build. It's very much kind of experimental. Because ultimately even the so-called mature  DeFi protocols that people will think of as established are still experiments that are like three years old at the most.

I've seen you on Twitter emphasize strongly how like the contract, the thinking of the contract behind these digital assets, is still lacking. Do you have any thoughts on like how to like convince people who operate in this kind of like digital prime thinking, where it's all very technical kind of focused in the digital realm, to  adopt kind of more like the physical prime thinking where like, oh actually the kind of agreements between people, actual people, are really important to building these things.

Ian on Encouraging Ricardian Contract Adoption by Devs [00:38:21]

Ian: I have done some recent thinking on this because it's pretty obvious that people haven't gone in that direction other than exceptions like Mattereum and so forth. The, the vast majority of the market, we're talking 99% or so, has just skipped past that and had lots of fun issuing tokens. NFTs, of course, the recent craze.

So what's going on here? It's relatively easy to convince lawyers because lawyers, of course, their meat and drink is contracts. To almost an exclusionary approach. They can't even think outside the realm of a contract. So they're quite happy with the concept, but lawyers don't program. So they can talk and talk and talk about this. And also lawyers aren't entrepreneurs. They don't act, they respond. So their way of thinking is, "Oh, there's a dispute coming, I need to defend." Yeah. And even if you ask them to write a contract, they're writing in the future as if there's a defense needed, there's a dispute so they're already in court in their mental state. They're responding to an attack.

Whereas your entrepreneur acts into the void and create something in the void. So the lawyers are particularly helpful in this respect. So the other community, if you'd like, that's interested in this is the developers and I've had a look at the whole the development process and I've actually come up with a recent thought and that is: okay, how do we make it easier for the developers to do this?

Well, one thing is we need the tool to write the contract. Another issue is what's the tool to share the contract? And if you think about, for example, Google Docs, it's a great tool for sharing documents, but it's a lousy tool tool for exporting.

You can't actually get access to it easily, except by exporting it as a PDF, for example. And that's a useless form. You can imagine trying to teach lawyers to use Google Docs, but they look at it blankly and say, well, hold on, where's Microsoft Word? I can't see it. So you've got this huge difficulty and the same happens with programmers, but there is a tool where programmers do share documents, and that's Git.

So what I've done is I've dived into Git, and specifically GitHub,  the commercial company, and started modeling the Ricardian contract in GitHub as a GitHub posted document in Markdown format. Now that's a document that is accessible and it's shareable by the developers so they can contribute to it by means of pull requests. And they can come to a consensus over what the right version, and it can be exported from because GitHub posts all these different URLs you can use to get access to the document. So I'm now actually reconfiguring all of  my software to do GitHub Markdown as the format. I used to use the old Microsoft INI format from 30 or 40 years ago. And that gave us good service.

We have, if you like, a non-technical, a co-operative requirement, and I'm experimenting with the notion that if we use GitHub, we can show the software and the contract being built up at the same time and therefore attract more developers to the process. And once we get enough developers doing it, there's going to be the sense whereby, okay, gosh, there's these developers over here that are using the Ricardian contract. And then there's the majority of the market, which just don't know don't care don't want it. But if you could compare them, the amount of information available in the Ricardian contract is orders of magnitude better because it's tied to the NFT. It is the NFT and it is the contract. And we can hold that person to account and say, this is the contract you issued, right? You sold me an NFT, a photo with these rights. The right to hang it on my wall. Okay. Where's the picture? When can I hang it on my wall? And you can state that with absolute certainty because it's written in the contract. And once you get that, what you do is you will cause this, if you like, this bifurcation, this forking in the market, such that there's the people who are doing it properly, the contracts, and then there's the rest.

And then will start to spread. Because once you have this very solid difference, like Mattereum is trying to generate now. The Mattereum gold bar is a gold bar, and it's on the net and it can be purchased and it can be traded. And that works because it's based on contracts. Once you get that, enough people know that, you'll start to, if you like, export the proper way of doing things.

On the Future of Smart Contracts [00:43:04]

Garrison: The kind of trends that are going on right now, both social trends and technological trends. Where do you see smart contracts 5, 10 years from now?

Ian: So, I've long predicted smart contracts really won't come into their own until they're incorporated with the legal documentation. And there are a few people that have gone in that direction. So for example, EOS put in the elements of smart contracts and Mattereum of course is doing it with it's NFTs and so forth. But just getting that element together, you also need the governance and the governance is a lot of work. It's a lot of costs.  Getting that right, is something where somebody's basically got to invest in doing it right up front to show that over the long run this thing works because we got the governance up and going in the beginning and that we sustained that governance through the lean years to the point where now it's starting to generate some return for both the customers and for the investors or owners of the system.

So I think we're still in the phase where we're building enough of the building blocks to the point where we can set up, if you like, a foundation, enough foundation, so we can start building the use cases until we've got a smorgasbord of governance techniques to choose from and a smorgasbord of contractual mechanisms and different contracts and a smorgasbord of accounting systems and then a smorgasbord of, shall we say, smart contract coding and so forth. Until we've got that all nicely laid out such that we just pick one of each of them, put it together, and we create our foundation, we are going to be stymied in building a lot of complicated apps.

So it's still a building phase.  And I see that Mattereum for example, but there are others doing this as well, doing the brave work of investing upfront into the uncertain future, because if it can get this right, it will create that cornerstone that couples in with the other cornerstones, which makes the foundation work. Somebody has got to do that. Unfortunately, we hit the HODL problem in that it's far easier to sit there and rely on other people to do the good work and just basically pretend we're innovative, but really the only innovation we've got is bringing more people into the HODL circle, uh, which  locks up so much of the capital.  And makes it very hard, for example, to create reality, to create a substance.  It's good that people like Mattereum people like Vinay and yourself are pushing forward on this because that's where the value is going to come from. And that's where the real value is going to come from, building these building blocks and getting it up and going.

Garrison: Yeah. That's very well said. From what I gather it is a very expensive and time intensive process to kind of get these governance issues right. But it's even just important just to give it due consideration before you just jump into some new venture.

A lot of budding entrepreneurs in the blockchain space. It's really easy to kind of get carried away by the hype and the potential and the narrative. The kind of lasting impact will be in kind of just staying the course and thinking very longterm. Instead of short term potential or gains and stuff like that. I think there's more maturity. more maturing going on in the development space. And people's imaginations are just broader in terms of use cases. So like you get different types of thinkers and builders involved with the technology. So I think that will be hopefully great for all of us. And building better systems, better financial systems, and new ways of cooperating.

So we're coming up on an hour into the session here. We've covered some of the work you're currently doing and thinking you're doing. Is there anything else you'd like to plug before we round things up?

Improving Asset Custody in Smart Property Systems [00:47:11]

Ian: So one of the things that I've done is I've looked at a problem that Mattereum had, which was how to do a solid custodial arrangement for some of these physical things.  They have the bare bones but what they needed was something a little bit more, if you like, scalable and professional, and so forth. And I just happened to be working with a company called Hover, which is a specialist in the field of setting up custodial arrangements for physical items. 

And I was able to introduce Hover and Mattereum together. I'm related to both companies, so it was a very easy introduction to make, but of course, I also end up being I'm able to participate in the discussion except to jolly things along a bit, because I'm in a conflict of interest. But that's fine. 

So Hover is a company that is explicitly setting out to create a good custodial arrangement for these assets. And therefore what it does is it solves one of the problems from Mattereum, which is great. How they do it I'm not gonna mention because at the moment they're still in there shall we say their first or their seed round. And they need to get some money and build their MVP, which is going to happen. And then we'll start, we'll be able to talk about how they've actually done this but it's been good because together we've  found that missing piece which allows the full Mattereum puzzle to be solved. At least that's the piece that I've been advised was missing. So now it's not missing so that's good.

It's interesting because if you look at the whole arrangement to do this properly, not only do you need the smart contract, the coding, not only do you do need the legal document, but you also need people to hold assets and you need  dispute resolution You need these different components which all get put together as a sort of Lego building. And until you've got them all there it's not going to last in the long run. It's going to be one of these flash in the pan things that scream up and then get into trouble and spring down again.

Garrison: It puts a lot of pressure to kind of generate  a lot of intellectual and financial capital in the very early days of conceiving of this and having to kind of stay the course to make sure you get it right. Cause if you don't get it right, then there's a lot of legal systems and software systems start  becoming detached from each other and it can be a messy a mess to clean up.

Ian: It gets messy, which creates costs, which drags everything down.

Garrison: Yeah, absolutely.

So where can people follow you and your work?

Ian: These days I tend to use Twitter. But, but that's just rambling on topics of the day. Iang_fc is the handle. I have a blog called Financial Cryptography that was a long standing blog for over a decade, but I don't post much on there. In fact, I don't post anything on there anymore because broken. I haven't got  the wherewithall or the patience to go in and fix it. 

One thing that is happening is that the entire identity cycle has been turned into a book and that book is coming out fairly in the next few months. And that describes, if you  the Chamapesa journey and the relationship of social groups to identity and so forth. It's a long book in terms of an internet read. A 100 or 200 pages. But unfortunately to actually explain why this is so, I had to go very deep and trace through things like the anthropology of the child's upbringing and so forth.  Therefore the description is quite long winded. But without that it's too many jumps and too many leaps of faith. It took me six years to get it all written down. So consequently, it's a long read if you like, which is not useful in today's terms, but anyway, the book will be coming out at some point and hopefully that will be amusing to some people.

Garrison: Yeah, that's fantastic. I I've read a lot of your writing on like identity and not just the Ricardian contract side of things, but also digital identity and your thinking behind that. It'd be great to  have it all kind of both compiled and expanded. The connective tissue of that concept. And actually I would love to have you on the podcast again to kind of dig, really dig into the identity thing. We touched upon it in this conversation, which I'm really glad we did. But it'd be great to kind of focus on that. Get a more kind of overarching view and dive deeper into that particular subject.

Ian: Well, when the book comes out, I guess I'll be happy to talk if you drifted into the book and actually got some questions out of it. That'd be great.

Garrison: Yeah, absolutely.  And for listeners, I highly recommend going to--  it's right that you have some of your papers and--

Ian: Yeah, it's just my stuff really. It's just the stuff site. It's not pushing any particular concept. I've got a section for this, a section for that. I collect everything there so it's more like a CV or resume than a website, but--

Garrison: A lot of the topics we covered a lot of the  papers that kind of articulated these ideas are in there. I highly recommend if users are interested in like Ricardian contract or thinking about like digital identity and the kind of frameworks for building financial cryptography systems. Definitely check it out.  There's a lot that I think people could get out of.

Ian: Yes. And the other one is There's nothing new there, but there are something like 1500 posts over the last decade or so.

Garrison: Excellent.  Thank you very much for coming on the show in Ian. A lot of the work you do is like something that I've paid attention to for three, four years now. So it was great to kind of dive in and get your perspective on things.

Ian: Good to hear. I mean the point of writing it all down is so other people can take from it and maybe learn a bit, but also maybe build on it and do something bigger.  It's encouraging to see Mattereum basically do that. Grab some papers. And race with them. Try and build the future.