Mattereum panel at the Internet of Agreements conference
The Mattereum team introduce themselves, and talk about what Mattereum is trying to achieve.
Transcript
Rob: I’m just going to do a brief introduction, to give you a conceptual background to what Mattereum is and what we’re doing. I’d first like to start by explaining what kind of problem we’re solving. Different people ask me this, and the answer tends to be pretty different, depending on the context that the people have when they ask that question. If you begin with knowledge of blockchain, you start thinking about why do we need these legal contracts on a blockchain? If you begin with knowledge of the law, you think, “What do we need a blockchain for? Why does that come in?” So I’m going to try and do a brief history lesson of the time before blockchains existed and how people thought about how to put contracts on the Internet, and why they thought it was necessary to do so.
I’m going to go back to the late 1990s, which some of you will remember. In the late 1990s people were thinking about how to set up systems of digital cash, how to set up a system pretty similar to Bitcoin, where you could on the Internet send money to other people with reasonably low transaction costs reasonably quickly all around the world. It was pretty obvious at that time that you couldn’t this with dollars, you couldn’t do it with pounds, you couldn’t do it with yen; the system simply hadn’t been built. If we think that bank IT is pretty bad now, it was even worse then. It would take days and days and days for payments even within the same country, and the idea of sending payments internationally with low fees and rapid transaction times was a complete pipe dream.
So, a bunch of people thought about how they would do this, and they came to the conclusion that you could do it if you had an asset of reasonably stable value, such as gold, that you placed in a bank vault, and then you issued essentially entries in a database to people that pretty much represented their share of the gold. At that point you can move those entries around in the database, and that is essentially like paying someone else with money: the entries in the database have this cash-like property, where if I update the database to say that 10 units has gone from me to you, you now have money that you didn’t have before. The problem with this system was how did we know that the entries in the database actually related to real gold in a bank vault somewhere? This was solved using a system which is now known as the Ricardian contract, and there’s a whole history behind that name which you can read on the Wikipedia page.
The Ricardian contract essentially is an ordinary legal contract that closely identifies a particular technical system and the state of that technical system at the beginning, and says, “Anything that happens inside this system when the ledger is updated, when the database changes, those changes have a certain meaning in the real world.” So the numbers in the database refer to units of gold, and everybody who participates in that system signs the contract, which means that we now have an agreement between all the participants as to what the database actually means. That was the only way that the database could have legal force in the real world; you make an update in the database, and it affects the ownership of physical stuff in the real world.
That line of thinking was actually largely forgotten, or largely ignored in fact, once Bitcoin came along. Because with Bitcoin there is no real asset, there is no physical bar of gold somewhere, there is nothing off-chain that Bitcoin refers to. If you have a digital key and a certain quantity of Bitcoin that is controllable by your digital key, there’s no external asset to even worry about. There’s the phrase “Possession is nine-tenths of the law,” and with Bitcoin, if you possess the digital key, that’s it, you have ownership and control, simply by virtue of holding the key. With a system that needs to refer to real assets in the physical world, you might be able to update the ledger, but unless you are sure that updating the ledger actually changes the ownership of the asset in the real world, then you’re just pushing numbers around in a computer system and there’s a risk that it doesn’t actually mean anything.
That Ricardian contract thinking is the building block for what we are doing at Mattereum. We’ve taken those sets of ideas and looked at how do we create a system where on a blockchain we can represent physical assets and move them around with the convenience of a modern computer system, but where you can refer to physical assets, where in fact you can refer to non-physical assets, things like intellectual property or things like future streams of value that might be that might be earned from an investment. It’s this thinking that gives us this notion of the Internet of Agreements, it gives us this idea that we can have, representing on a blockchain, contractual rights that we can move around extremely easily, that we can trade with each other, and that we can structure increasingly complex and increasingly powerful assets, agreements, financial instruments of various different kinds, using a combination of a legal contract and a technical system whose behaviour is in conformance to the terms set out in a legal contract.
That I think is the key background to what Mattereum does. We’ve got that set of thinking about Ricardian contracts, but it’s kind of clunky, it’s kind of difficult. I mean, who really wants to be signing a paper contract? How do you even… It doesn’t sound Internet native, it doesn’t really sound like the way that we do things in 2018, having people printing things out and signing with ink and so on and so forth; it might have been acceptable in the 90s, but it’s not acceptable now. So we look at other innovations that have occurred over the last 20 years, and we’ve moved very much from a society that ran on cash to a society that now is largely cashless. You can buy pretty much anything you want now using a credit card or for that matter Apple Pay, Google Pay, any of the various contactless systems – I can pay for things using my watch, which is pretty cool – and that transition, that move from physical bits of paper to essentially digital systems for payment has made the life of consumers much more convenient.
But if you look at the technologies that back something like a credit card, there’s in fact a whole bundle of different things in there, there’s a whole bunch of things going on that are way more powerful and way more interesting than what you would get with cash. If you buy something, you pay for something online with a credit card and that thing doesn’t turn up, you have a system where you can dispute the payment, you can say, “I paid for something and I didn’t get what I paid for,” so you can actually get a chargeback in the case of a credit card payment, which is something that you wouldn’t be able to get with cash. You get, in some cases, extra warranty or extra insurance on the goods; again, you don’t get that with cash. You also get a form of identity. If I go to an ecommerce site and type in my name and my address, that can be checked by the merchant against the information that’s held by the credit card issuer.
What if we could take those kinds of innovations and bring them to contracts, so we have a situation where when you sign a contract with somebody, you can verify your identity, verify the identity of both parties to the contract, where you can begin to bring in insurance against the possibility that the contract isn’t performed, and where you can start to bring in dispute resolution – which is already commonplace for legal contracts as it is, where you could bring in a form of dispute resolution that is globally accessible all around the world – could we begin to see the same kind of innovation in personal finance, in business-to-business deals, in global trading arrangements that we’ve seen in the consumer world over the last 30 years, beginning with the credit card and going through payment systems such as PayPal and Stripe, that have given rise to the ecommerce era, with Amazon, Netflix, eBay, Uber, Airbnb and so on and so forth? Is there a similar level of innovation, a similar level of change that you could achieve around contracts, so it becomes as easy and as frictionless to sign a mortgage agreement or a rental agreement, or to structure a long-term deal for shipment of goods, or for hedging of risks, or for investment in new businesses? Could we make that as easy to do as buying something with your credit card?
That is ultimately the end state that we want to get to, that’s ultimately what Mattereum is here to do, is to make it easy to facilitate all of those things. When we talk about blockchains and world trade, we really are talking about trying to facilitate trade around the world, where you’re making it possible for people to feel as safe and as comfortable and as convenient, when they’re going anywhere in the world to conduct business with anybody else in the world, as they would if they were doing an ordinary consumer purchase using a credit card. That is I think, as a vision, something that we think about a lot, but as a set of practical steps, it’s something that we’re just starting out on, and we want to talk a little bit more about what we’ve achieved so far and where we’re going with that vision. So I’m going to move over, take my seat, and we’ll begin a panel discussion. Thank you. [applause]
Vinay: Intros for everyone?
Rob: Yep.
Mihai: My name is Mihai Cimpoesu, Chief Engineer at Mattereum.
Chris: Christopher Wray, Chief Legal Officer.
Vinay: Vinay Gupta, Co-Founder.
David: David Salgado, Head of Operations.
Rob: Rob Knight, Co-Founder.
Vinay: I guess it would be worth talking a little bit about how we got here. How we got here is a long and winding path, because, as Rob alluded to, there’s literally been this 20-year process of attempting to get computers properly integrated into trade, and to get the ability to do legal transfer of property using the Internet. There’s been generations and generations of technology deployed on this, but we still don’t have a situation in which you can reliably generate something that looks like a net 90 invoice and pay it using some kind of electronic currency, so it’s still a primitive process.
We’ve come to this from a range of different backgrounds, all attempting to converge on the different things that you need to get right to enable that process to run end to end: you need technology, you need law, you need the actual business processes, you need your concept of operations, and you need all these pieces to slot together. This is basically interdisciplinary research; it’s the hard questions about the boundaries between fields, and the demarcations between fields, that give the company the shape that it has, that’s why we are the shape that we are. Do you want to talk a little bit about the legal side of this, Chris?
Chris: Sure. On this interdisciplinary angle, we touched on it in the panel session. It feels like there’s scope here for lawyers to do more and to start to take on, as I said, not coding, but really starting to think about the architecture of the social system that is being created by a contract, as much as the hard constraints, if someone needs to enforce it with the big stick of nation state violence, ultimately. So I would say already in some of the early work it’s not just law plus code, but there’s some systems engineering, systems design in there, scenario planning… It’s doing what could have been done earlier I think, and maybe should have been, in law, but there are certain misalignments of incentives.
It would be far preferable for all of the legal work to be done upfront, to produce… If you’re going to automate the performance of something, and if you’re going to have a big chunk of software there that helps you carry out your promises, then that chunk of software isn’t going to want to change radically deal to deal, so that’s going to become fairly standardised, which is going to push contracts towards being more standardised, so that’s a constraint on freedom of contract. You can map out the parameters, and there’s still scope for negotiating, depending on the parties’ negotiating positions and all the usual factors, but that standardisation actually now allows, in fact requires, upfront a thought to the system that comprises these parties, and whatever the rights and the various assets are that will be involved in their interaction, and it’s designing that, ideally, to reduce over time the number of disputes that ever arise.
Of course you want robust dispute resolution in place, but if you start to have a virtuous feedback loop, where you continually try and evolve your contracts and your code which are carrying parties through the carrying out of their promises to one another, then this becomes an opportunity, if you do it right, to anticipate the kind of things that can go wrong and to start to plan for them, put it into the code. Of course there will always be exceptions. I don’t take seriously the fact that we will, in general, move beyond having written legal contracts that accompany pieces of code. I think there will be whole classes of smart contracts which become so ubiquitous and so reliable that I would no more have a written contract to use it than I would have a written contract with a vending machine.
So, I do think there’s a new discipline here of the sort of legal systems thinker, where we map out… Just as good commercial lawyers always say, “We help shape the commercial deals,” it’s not just some sort of irritating formality to be added on, there’s input to the structure of relations that depends on the parties’ long-term goals and values and the kind of relationships they want to construct, but I think we’re going to see more of that. I think this whole space is a really exciting opportunity to do a lot more of that, as lawyers; it’s just it’s going to be something that’s done hand in hand with software engineers.
Vinay: Mihai, do you want to talk a little bit about the technical side of this? We literally this week did a very large design charrette, which was really the very detailed collaboration between the legal team and the programming team, literally line-by-line analysis of a contract pair. Do you want to talk a little about that process and about how it’s different from the sort of regular coding environment?
Mihai: Yeah. I’m coming from the programming side, from the guys who write the code, and it’s been a significant mind shift for me, from taking requirements from a clients which are sometimes vague and turning them into code, to then going through this legal process and collaboration with the legal team, it’s a significant mind shift. Because the coders are very eager to finish the work, and I guess we’re seeing a lot of projects like that in the crypto space, but they don’t do the proper diligence to make sure that what they are doing actually makes sense in the real world.
Also, just a view on how Mattereum is constructed as a company. I think a parallel on how Elon Musk is designing his companies is very aligned, in the sense that we are trying to build, as much as possible, in-house, as a collaboration between people coming from different backgrounds, and then the entire process of delivering a client project is much faster and much more efficient, and if we can make it so that at the end we weed out 99% of the bugs instead of 67%, that would be amazing.
Vinay: You had a question?
Question: Would you mind please explaining a bit how lawyers – who are late adopters of technology, not early adopters – are going to be affected by this new technology, whether they want to or not, and how might they need to be able to respond.
Vinay: What was the other question?
Question: Mihai, you mentioned the requirements governing process is different to conventional software development. Please, could you talk a little bit to the process of teasing out your requirements in the Mattereum context?
Question: Chris, you were talking about some of the new or possibly adjusted roles that lawyers might take on. In this country at least, there’s a deep cultural background that lawyers have which doesn’t come from their clients; if anything, what they get from their training is much more rooted in centuries of practice and the culture of the country. What new elements will they require for their new roles? Because obviously if that’s not something one thinks about, then you’ll get defaults that you probably didn’t want.
Chris: Maybe I’ll try and do the first and third questions. When you’re dealing with multiple jurisdictions, which of course you are in world trade, and yes, we have the luxury of deciding on our governing law, if disputes are going to be submitted to arbitration instead of going to a national court, but still you’ve got to engage with all the local regulation. So there’s inevitably, I think forever, are going to be that requirement for specialist legal knowledge within particular jurisdictions, and on interactions between jurisdictions, that will always require that entirely conventional legal knowledge. Yes, I think it’s essential that with this kind of interdisciplinary thing we do both law and software engineering in-house, that’s the only way you tease out some of the interesting overlaps and new areas, but it’s never going to be all-encompassed within house. It would be bizarre to try and become a master of every single jurisdiction, so there’s going to be plenty of work for lawyers, with specialist expertise in specialist jurisdictions, to provide the kind of input that is required in producing these kind of contracts. Of course there’s going to be conventional legal work there, and this is only in one aspect of law, the kind of commercial side, for now.
But yeah, if you’re an early adopter, if you’re a lawyer interested in seeing where there is new space to move to, I think there’s some quite exciting new skills that you could move into. As I said initially, good commercial lawyers will have been doing this anyway. Of course they’ll have had a kind of implicit model of the space that they clients are operating in, the different kind of relationships, the different way those relationships can evolve, and they try and shape those or support the client’s choice of direction, they try and support that as well as possible and build enough around it, to provide the clarity and to manage the risks as best they can.
But I think there will be scope now for a formalisation of this. I think what we’re already developing is more of a methodology that is systemically aware. It’s no longer the case that the contract is fully performed or not, it’s just no longer the case that… And yes, there’s always been a scope for liquidated damaged or for ways of trying to anticipate something that might go wrong and specify a remedy for it in advance, to save the uncertainty and expense of having to determine it later, but now there’s vastly greater scope for this kind of anticipation of different possible future evolutions of a given commercial relationship and to try and start mapping those out.
Vinay: I think it would be worth putting this is a kind of practical context. We have a set of clients, about 10, most of whom are developing some kind of Ethereum-based smart contract application which handles some kind of legal property. You get into a position where at some point there is a transfer of ownership or transfer of status of the legal property, and the intention is that that transfer of legal ownership or legal status will be triggered by an event on the blockchain; typically a payment arrives, or a certain amount of time elapses. You would think that in principle this is a relatively simple process, where the contract says, “In this condition, then when that ownership changes from one key to another key, the legal ownership [~2, 26:46] change,” everybody signs their paper contracts and off you go to the races. But in practice, if you think about the gnarly technical complexity that even a relatively simple smart contract has, there’s an enormous need to have very, very specific domain understanding of what’s happening for the smart contract to be created in a way it represents the actual underlying reality.
Similarly, for those who are on the legal side of the house, if you think about how complex even relatively simple contracts are, because they directly interface with the full complexity of the world – and anything that happens in the real world, there must be some way of managing it inside of the paper contract, or you wind up with a kind of hard crash where the entire thing turns into litigation – what we have is an interdisciplinary space in which all of that complexity is put into a single techno-social system which emits a contract pair. The paper contract and the smart contract basically divide reality between them in a way that hopefully gives you a comprehensive coverage of the set of things which can occur. We talk about this as contract enforceability engineering, but really it’s a new discipline for thinking about the interface between the complex nature of the real world and two different kinds of simplifying abstractions, one of which is law and the second of which is code. It’s been quite a process of really beginning to frame what that discipline looks like, because it asks a lot of very hard questions about the nature of complex systems, and the sort of philosophical underpinnings of how we do things like make decisions.
Mihai: The question about how do we deal with the specs coming from clients: with the clients that we have dealt so far, it was often the case that they come up with a half-page sketch of what they were doing, and they said, “Yes, we want this blockchain thing,” and then I would go in and produce a five-page technical requirements and technical specs out of that, go back to them and they’re like “Whoa… This is what I asked for?!”
Chris: Which became a 10-page legal spec…
Mihai: Yes, and then that become a 10-page legal spec, and this is what we’ve all signed up for in the end. But that whole process of coming from a sketch of an idea to an actual deliverable product that is even enforceable in the real world and is actually legal, this was the bulk of the work for those clients. Then we’ve written the code, and with one of these projects we are now at the end, where we’ve basically spent days together in a meeting room, just going line by line, having the code on the left and the written contract on the right, going line by line between the two of them to see if they match – it was a pretty exhilarating experience.
Dominic: My name is Dominic Cameron, I’ve been building digital businesses in London, not very large scale, for about 30 years. Two related questions, speak to engineering and to operations, about maturity and readiness I guess of the underlying frameworks, the underlying platforms, partly about Ethereum and so on. At lunch ~Liang Tzu~ and I were talking, and he reminded me that we’re in sort of the 1990s phase of the evolution of blockchain… We know it’s going to be faster than that perhaps compared to the Internet, but still early phase. The first question is f we think about companies like DHL or Maersk or Costco, when would you imagine, how many years away would you imagine that at that scale, tens of thousands, perhaps hundreds of thousands of trades per day are impacted by the sort of things we’re talking about today? Are we 3-5 years away, are we 10-15 years away, and why?
Related to that, without getting into the kind of flame wars about ETC and Cardano and all that sort of stuff, given that you guys are I think focused on Ethereum primarily as an underlying platform, what are the things which companies like Tezos, EOS, Cardano are trying to resolve, whether it’s about interoperability, around scalability, around governance, around whatever other themes… What are the themes that you believe Ethereum have to solve to get on that path of delivering tens of thousands per day?
Chris: Can I just say one line on Ricardian contracts first? Because I do think it’s important to realise that with the Ricardian contracts concept, this separation of legal terms and the software that implements it, it doesn’t lock you into a single software platform. I mean, I’m not sure why you would choose to do this, unless there was some compelling underlying reason, but conceivably a Ricardian contract could comprise some little written legal terms and more than one software system on the other side. Again, that would potentially seem perverse is some cases, but I can imagine very complex situations where you would need to do that. I think that’s an inherent flexibility about the Ricardian contract approach, and an argument against a drive towards complete convertibility between code and written language. Not only are they on different levels systemically in terms of what they’re trying to describe, but potentially sometimes the world needs to be dealt with with different systems in different places.
Vinay: At least theoretically, you could rebase a contract so the legal agreement doesn’t change, you just peel out one implementation layer and replace it with a different chunk of software. This would be tricky to do on the fly in large, complex systems, but if the legal agreements haven’t changed, switching the technology can be drafted into the legal contract as one of the things that you could do.
Rob: On the question of maturity, I think there’s two levels that we need to think about maturity for, one is the scalability of the underlying blockchain system. You mentioned the idea of large companies and thousands of trades per day. Right now that’s not possible on public blockchains, the scalability characteristics are just not appropriate for that. So there’s a good amount of engineering work that needs to be done there, if we’re going to do this on public chains. You could do it now on private chains, and IBM will tell you a very good story about Maersk and Hyperledger, and that is very good work that’s being done and we’re not in any sense opposed to that. I think people have their views about public versus private ledgers; our view is you pick the right tool for the right job.
I think the second part of the maturity question is really the engineering culture. Do we actually have enough people out there, do we actually have the capability to deliver these systems? Because if you look at what web development did, web development pulled a large number of people into the software industry, a massive expansion of the number of people writing code. One of my favourite possessions is a book, I think written in 1999, called After the Gold Rush, and it was on the premise that the great gold rush era of software began in the 1980s and it roughly finished sometime in the mid-1990s, and that we should now settle down and professionalise software development because we weren’t going to need to pull in a huge number of new people. This turned out not to be the case.
But, what we’ve never really done is develop a professional code of software engineering. The general attitude that summed up a company like Facebook was move fast and break things. Move fast and break things is great when you’re deploying something to a Web server: you break it in the morning, you look at your logs, you see that errors are being reported, and you push out a fix that afternoon. What you’re really measuring in that instance is not how many bugs did we have, but how long did it take us to fix all the bugs we have, after we’ve found out about them? And this kind of works. You get updates on your phone every single day, you get websites that get updated several times day, it works for those kinds of systems. That approach does not work at all for a smart contract. If you imagine getting a letter from your bank, saying, “We’ve updated the terms of your mortgage contract,” and receiving several letters a day as new updates are being are being… It just doesn’t make any sense at all.
Vinay: “Trust us.” [laughter]
Rob: So, I think what we actually need is a very different engineering culture for these kinds of hybrid legal and technical systems, which is a culture of zero defects, of making sure the thing actually works correctly, and where there absolutely do need to be these kind of exception handling systems where something goes wrong, because the one rule is something always goes wrong, some unexpected aspect of reality occurs.
We’re at an interesting situation now, where for smart contracts… As someone who has worked as a software developer for many years, when I write some code for instance that appears on a website, that’s run on millions of computers around the world that are running different hardware, different versions of operating systems, different web browsers… If it goes wrong, it’s kind of a little bit unfair to hold me personally responsible for the fact that on some particularly weird configuration of system my code turns out not to work entirely as expected. But with smart contracts, they run again on millions of computers all around the world, but those computers compare their results and make sure that they all agreed on what the result of the smart contract was. If it does something, it does it because I programmed it to do it that way, and not because there are kind of weird errors being introduced by different hardware and operating system configurations.
We’ve had cases now of deployed smart contracts on Ethereum that have caused financial losses, where we can directly measure the financial loss. You can then go to GitHub and look at the code, and you can go right down to the individual line and you can look at the commit history, and there’s a lovely command in Git called “git blame” [laughter] which tells you who wrote that line. So you can actually find out directly…
Comment: “It was just a white space change…”
Rob: Exactly. So there is a level of accountability in smart contract engineering which is just not present in web development or mobile app development, and I think the software industry has not yet, at all, begun to internalise the cultural change that you get from that. I think that is going to be a very big driver of a new kinds of maturity for software engineering.
Question: Is that on the way on Ethereum, the cultural change?
Vinay: Well, at this point Ethereum smart contract goofs have cost many hundreds of millions of dollars. I would say that the engineering culture is beginning to get a little warier.
Mihai: We’re kind of obligated now, that’s not down to preference anymore – these guys enforce it!
Vinay: All of this gets into the much more general domain of how you do reliability engineering for big systems, and that is still very much a craft. I think that it would be unsurprising if in five years you saw an enormous influx of expertise from aerospace and satellite into these areas, simply because you wind up with so much value at risk that those kind of engineering practices become a much more sensible way to approach it. I don’t know for sure that’s the way it will go, but it would be an unsurprising future hybridisation.
The governance and fork thing… That’s such a hard question. The fiddly thing with all of this is that the blockchain is extremely poorly defined. I often say to people that cryptocurrency is today’s equivalent of the term “horseless carriage”. These things are no more currencies than early motor cars were horse carriages. But we don’t really know what they are yet, because we are in this awkward transitional period, as we used to be with the Internet, where defining these things is a profession. There was a period in the late 90s where just telling people what the Internet was was a job, and then after a while that job goes way. This was true with social media. There was a period when knowing what social media was was a job, there was a profession called social media consultant; not so much of that anymore.
Similarly, we’re in this thing where we’re in a position where language formation lags behind the technological reality. When we talk about governance on blockchains, we’ve got an established body of practices for governance, and we’ve got this kind of wibbly-wobbly- squeezy thing called the blockchain which constantly changes, because the blockchain isn’t an object; it’s a process. It’s a cultural initiative, it’s a thing, a bit like… If we think of something like sport, sport contains a myriad of things, and blockchain is about as general a term as sport; it’s a not a clearly defined entity. So when we talk about the governance question of blockchain, for some people what they hear is “How do we revert a bad transaction?” and what other people hear is “How do we modify the software systems to choose for example a scaling algorithm we’re going to try?” and then in the middle there’s a whole bunch of questions about identity, and some people want to build these things into blockchains, and other people think that those are applications.
So, right now in terms of getting large-scale systems to run, I think what you’re going to get is the most conservative systems win. The systems which are least like the new and most like the old will be things which look a bit like online transaction processing, they might even come from the old vendors like SAP, and those things will likely be the first systems that begin to carry the first couple of 20-50-100 billion dollars’ worth of real trade transactions. The question then is the equilibrium between the legacy people who add a thin layer of blockchain, and the blockchain people that learn their way back into legacy, and that struggle happened right the way through the Web business for decades. That tension between legacy players requiring Web features and Web features requiring legacy skill, that demarcation has… I mean, half of the advertising money spent for business-to-business Web stuff was probably spent by people fighting down that line, and I think that will be exactly the same way with blockchain. Notably, Facebook, Amazon, Google, Microsoft, they’ve all been very reticent to announce their blockchain strategies; SAP and Oracle, practically nothing heard.
So I really think that the majority of the heavy trade stuff will initially happen when for example Oracle launches a blockchain-shaped thing, and it will be about 15-20% blockchain, it will be a thin layer on top of Oracle, but it’s much more credible to me that you’ll see large value transactions over those kind of systems than a whole-scale flight onto even a very fast version of Ethereum. Because it turns out that the enterprise has a whole bunch of needs which have nothing to do with the technology working. Do you want to say a bit more about that, Rob? I think specifically in terms of the stuff that you did for the BBC, just how you get Web-style technologies into these big institutions.
Rob: A lot of my early thinking about smart contracts in particular came because I was working at the time with the BBC on a large-scale project, to digitise a lot of their rights management for commercial purposes, and this involved going through the BBC archives and basically taking all of these old pieces of footage. The video had been digitised for years, but the contractual rights have never been digitised, and so the challenge there was going through all the filing cabinets and pulling out pieces of paper from the 1970s, and working out what the implications were of this contract that had been drafted and signed with no knowledge of the concepts of streaming and download for streaming and downloading things. What does this actually mean? Who do we need to pay? How much do we need to pay them? How long can we put this thing online for? Those challenges are actually… in many respects, they’re more serious than the straightforward engineering challenges. Building the front end on the thing was not very hard, building a system that could take clean data and serve it up to end customers was not very hard; getting the clean data into the system in the right format and figuring out how to structure that, that was hard.
A lot of my early thinking on smart contracts, when I first came across Ethereum, was wouldn’t this be a great system for doing all of these things that we’ve been doing? Think about splits between actors and directors and production companies and all of these kinds of things. It’s the sort of thing that smart contracts are theoretically very well suited to. And then you realise how many transactions you can do per second on a public blockchain, and you realise that that kind of thing is completely unfeasible right now. But that is a thing that shifts year by year by year, and very, very suddenly you’ll find it becomes possible, and it will become possible almost overnight. The difficulty I think is that you’ve got to start now. Vinay mentions the likes of Oracle and so on. If you’re a large media organisation for instance, then probably is a blockchain, smart contract future for your organisation, at some point you’re going to face that.
The thing is, do you start now, or do you wait for the technologies to be ready? History kind of shows us that waiting until the technology is ready typically is waiting until it’s too late, you get disrupted by someone who comes up underneath you. So there is this kind of interesting period now where of people are kind of circling around these questions, there’s a lot of PoCs, there’s a lot of pilot projects… I think it’s easy to look at that and think, “They’re not putting that much real value over it,” but this really is the forerunner of the thing that’s going to come next. Companies that have survived the Internet, the original disruption of the Web, have done so because they learnt to adapt pretty quickly; those organisations are going to see blockchain coming and are going to adapt in pretty much the same kind of way.
I think their suppliers, their vendors, the big technology companies are themselves going to have to get into that game, because it’s the only way they’re going to be able to keep their own clients in business, once that disruption comes along. If you’re selling the old tools to companies who are being disrupted by the new tools, that’s a doubly bad situation for you to be in.
Vinay: David, do you want to talk a little bit about government adoption and those processes? Because I think that’s also very sharp point here in terms of what those adaptation ~pairs~ look like.
David: Sure. The reason I’m talking about this is that before joining Mattereum I was working at the Ministry of Justice as a technical architect, and certainly our government, and lots of other governments with different degrees of enthusiasm, are very keen that they’re not seen to be on the back foot with these technologies, that blockchain is clearly a very interesting technology, and what nobody wants is in five years’ time for some politician to go, “Why haven’t you been thinking about this?”
On the other hand, the fundamental attributes of distributed ledger technologies that make them useful is distribution of trust. We talked a lot about trustlessness this morning. Blockchain technologies are immensely useful where we have multiple actors who don’t necessarily trust each other terribly much. In the case of nation state governments, the government is the central trusted authority. There isn’t really a lot of point having blockchain tech for many of the things that government does, because the government is trusted. That’s partly why I think there’s potentially less interest in blockchain tech in government than one might expect. On the other hand, for those cases where there is distribution of trust, there’s certainly interest in looking at these technologies. But at the same time, the government moves very, very slowly, as we all know, and I think we will see developments in the private sector much more quickly than we will in government, and then those will sort of backfill into government, as it happens with lots of other technological shifts.
One area that… Let me be very clear that I’m not saying anything that is in any way government policy or that people are planning to roll this out as a live application, but there is a lot of interest, certainly in the MoJ and across other departments in government, about a potential use of blockchain technology as essentially a digital evidence log, such that if you have… A particular case in point at the moment is communication service provider data, where in a criminal case the police might have gone to Vodafone and said, “We’ve arrested this guy, we need to know where he’s been and who he’s been calling,” and the service provider can provide a log of these calls. There is a lot of interest in the idea of using a blockchain to store the hash of that artefact – whatever it is, whether it’s a communications log or a digital image or a piece of digital video – to write the hash to a blockchain, such that you can then go and point at it and say, “In six months’ time when you present the evidence in court, here is this thing, you can compare it against this hash on the blockchain, and it cannot possible have been tampered with.”
And this is actually, oddly enough, not a new idea. There used to be vaguely similar cases, where the proof that the thing was as you said it was is because they’d published certain hash numbers in the times, and you can actually go back to the times and verify it; details of exactly what the artefacts were isn’t that relevant. But it turns out that this concept is quite interesting for government, there’s is some work in exploring how that could be used. It also transpires that exactly the same concept can actually be very useful in contract negotiations, particularly in arbitration, where if the two parties who have a dispute go to a mediator or a qualified arbitrator and both of them have a thick pile of documents to say, “Look, this is exactly what happened,” that that can massively streamline and simplify the whole dispute resolution process, which… Chris is nodding, so I think… I’m sure he’ll correct me in a minute.
So yeah, certainly in government I think the applications of blockchain technology are not perhaps quite as widespread as we might have thought, but there is a lot of interest in particular niches where distribution of trust is an issue.
Chris: Yeah, and this is a wonderful idea to borrow for civil proceedings. I think one of the things that we touched on the legal panel earlier but didn’t say too much about was this gap, where at present you have contracts which are effectively unenforceable, because the cost of effort to enforce it is too great, relative to what you would gain from doing so, and even if some recoverability of your cost is built in, it’s never complete. So there’s this sort of window where you’re well above small claims, retail level kind of disputes, but you’re well below the multimillion-dollar disputes, where of course it makes sense for both parties to have a full-blown arbitration, with all the trimmings.
Now, this is where I think this kind of technological application can be useful in trying to really trim cost and time. I think you will still end up… If you’re at a full arbitration, of course there will still be the traditional witness statements, people swearing an oath, that such and such evidence was indeed the document that they sent at that particular time, that’s still going to happen when you have full hearings. But for lower-value disputes and at earlier stages, this prospect of having a clear chronology of events as they unfolded through the contract and pieces of evidence that were thrown up at the time… It may be a bill of lading, it may be a notice by email from one party to the other, but certain things are hashed and that hash is put on a chain, the idea that you could very quickly have a third-party neutral come in and look at a set of documents which they know are the documents that were recorded at those times… That’s a boring but really meaningful efficiency saving.
Vinay: I think it’s important to put this in the context of risk. Anytime something goes wrong in a piece of trade there are associated costs of recoverability ~that get~ spread across all of the transactions that you’re doing. All of the risk increases friction, the friction reduces the number of trades you can make which are profitable, and it all shrinks the size of global GDP Just getting the barriers to international trade down using mechanisms which don’t rely on international treaties is potentially a much larger counterbalance to the ongoing slowdown that we’re seeing in global trade than almost any other single thing we could do. If you think about how effectively access to information has been transformed by the Internet in the last 20 years, it’s not impractical to imagine that you could see something similar happening for access to goods, and that process is already well underway with for example Amazon. Amazon ~is what the game begins~ to look like when you see this kind of fluidisation of trade; imagine if that was true for everything else at the same time. Peter, you had a question.
Peter: Yeah, I had an observation. I was very pleased to hear Rob bring up the subject of culture, particularly the collision of culture between the legal and technical and entrepreneurial. I had a situation in Italy years ago, where an entrepreneur wanted to use a gigantic Italian company to move shitloads of his product, and we had an informal memorandum of understanding… We negotiated on an A4 scrap of paper, we agreed this, that and the other. Then he brought his lawyer in, and the lawyer had set him up at a Delaware-based corporation, so his focus and mindset was protecting the IP at all costs, and within five minutes he completely destroyed the trust in the deal, because that was the only language that he could see.
Let alone the fact that the legal system there is somewhat Napoleonic law-based, which is different than our system, certainly different from America. Let alone the cultural aspect that the Italians don’t fight black against white. Their language, when they express such things, it uses a special tense where there’s a bit of wiggle room built in for the other side. Because as a macho society, Spain is the same I think, you can’t be seen to fail as a male in that sort of combative environment. So I think culture, Rob, is a fantastic element to look at on the longer term, and to think about what are we going to do with all these other legal jurisdictions and how do they fit in on international trade, which is where we came in.
Vinay: This is the unresolved business that has been all the way through the Internet-based round of globalisation. The formation of a single global Internet culture around things like Wikipedia is very, very far advanced, but in things like international trade, those cultures are going to remain extremely particular and national for a long time. We don’t really know what it means to have a global trade backbone, which technically works more or less the same way everywhere but regionally will be used in completely different ways. I think you could look at what’s happened with Internet messaging, where you see the iconographic cultures give rise to emojis, which eventually get backported into the West. It would be fascinating to see whether trade norms from other cultures came back across these channels, once these channels were opened.
Chris: What I hope we might also be able to do is overcome a cultural failing with human beings generally, which is that we just don’t like to think about what will happen when it goes wrong. Law has been the technology, contract law, that we’ve developed to deal with that failing, you have this class of human beings who are trained to try and constrain those risks, but there are… I think the kind of systems thinking design approaches that I keep referring to are much better ways. Scenario planning, trying to map out how this dynamic system might evolve in various different directions, and then anticipate and allow for what you’d like to see in those different outcomes. That is something that human beings just don’t do, but it would be tremendously good if they did, and I think this space allows us to start imposing that discipline on the planet.
Peter: Yeah, to ~reach their opportunity~.
Vinay: Absolutely. I think on that note, we’ll wind up the panel.
Question: Your idea of ~lateralisation~ of evidence so that you keep track of the chain of events and when it happens and so on, why is that a public blockchain and not a GitHub repository or something like that? Why do you need the overhead?
Chris: Rarely is that, I would say, going to be a public blockchain. Even just the hashes carry valuable metadata that you wouldn’t necessarily want to reveal to a competitor. Just somebody watching the timing of these hashes pop up could give them valuable intelligence. So I think we’re not going to see that kind of thing on a public blockchain.
Vinay: That’s all, folks – thank you very much! [applause]