Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Casey Kuhlman: Permissioned Blockchains and Disrupting Industrial Application Design

Episode Date: January 4, 2016

Permissionable blockchains have gained much attention from enterprise this past year, and specifically, the traditional fiance and FinTech sectors. As new protocols emerge and the technology is matures, it is becoming apparent they are simply a new class of database, one which integrates business logic (smart contracts) and a consensus layer (PoS, PoW, etc). is the CEO of Eris Industries, a company which specializes in building permissioned blockchain systems for enterprise. Their aim is to deliver the technologies which enable companies to easily build and deploy applications which make use of blockchain and smart contract technologies. Topics covered in this episode: Casey’s impressive background as an engineer, Marine soldier, lawyer and startup founder Eris Industries and what the company is trying to achieve Permissionable blockchains and their usefulness in industrial applications Smart contracts, how to explain them and legal status How blockchains can be used to revolutionize the way organizations construct business processes The idea of Blockchains-as-a-Service The various use cases for blockchain technologies Episode links: Eris Industries 2Gather This episode is hosted by Meher Roy and Sébastien Couture. Show notes and listening options: epicenter.tv/112

This is Epicenter Bitcoin, episode 112 with guest Casey Coleman. Hi, everyone. Since this episode is about ERIS Industries, I did want to point out that Brian does work there, although most of you probably already know that. In order to stay as unbiased as possible, he decided that he wanted to sit this one out, so I'll be doing it with mayor. Our interest and our desire to interview ERIS is in no way influenced by Brian's position there. We are generally fascinated by what they're doing. And as we do every week, we try to bring you the most informative and interesting interviews with people working on fascinating projects and startups in this Bitcoin, blockchain cryptocurrency space. And this is in no way different than anything we do every other week. So with that, I'd like you to sit back and enjoy the show.

This episode of Epicenter Bitcoin is brought you by high.com. Protect yourself against hackers and safeguard your identity online with a first class VPN. Go to high.combe slash epicenter and sign up for a free account today. Hi, welcome to Epicenter Bitcoin. The show has talks about the technologies, projects, and startups to decentralization and the global cryptocurrency revolution. My name is Sebassi Nkutu. And I'm Meheroy. Today we have a very special guest joining in from Ayrus Industries.

Today we'll be talking to KC Coolman, who is the CEO there. We'll go through, we'll talk about themes such as smart contracts, business process automation, what a business is trying to do, etc. But before we start, perhaps it's best we have an introduction from you, Casey. Tell us a bit about your background. Sure, thanks.

My background began, I'm American, and I did a little bit of engineering in a former life, but instead of building things, which I was sort of destined to do, I decided that it might be more interesting if I went the other way, and so I became an infantry officer in the Marine Corps. After that, then I decided,

instead of a very aggressive background, Maybe I should go explore the other side and became a hippie and a ski bum for quite a while and did a decent amount of riding. After that, I decided that being a ski bum might not be the best career choice. So I ended up going to law school. And then instead of doing the big law firm and big corporate firm, which a lot of folks do, I ended up going to Africa and working in the intersection of legal development, and, sorry, international development and the legal world. So I worked at war crimes tribunal for a little while,

and then afterwards I was in the West Africa, sorry, in East Africa. And there I was responsible for running a project for a while, and then I ran my own law firm in the Horn of Africa for quite a few years. After that, I took a job as the head of legal information systems for the US Open Data Institute, And then we founded Aris. Wow.

So that's that pretty much spans the spectrum of human activity, right? From engineering to the marine to studying in law school to being a lawyer in Somalia and now to the CEO of Eris Industries. So like when and how did you get interested in this in smart contracts for the first time? Sure. I don't actually remember how I stumbled upon it, but it must have been in late January or early February. 2014 I had been researching for a long time the intersection of law and technology, particularly this idea that we could have computable contracts. And so it was in the course of that research that I stumbled upon.

At that time, what was just very theoretical, the idea that eventually Ethereum ended up working on and building. And so they really captured my imagination coming from a legal and tech back to the idea. which I was in at that time. So you're, you're Brian's boss. How is it like working with Brian? I mean,

I know, I know how he is working with him as a colleague, but how is he as an employee, really? As an employee, he's not my worst employee. So that's, no,

I actually love working with Brian, I must say. He has a super strong conception of what this technology can do, particularly in industrial applications, and he's really helped bring Aris to the next level in a lot of ways. I have no doubt. I was just joking about that.

So, yeah, well, let's dive right into Aris. So please describe, I mean, we've had Preston burn on before. That was quite a while ago, and I think things have changed quite a bit since then. Can you tell us about Aris, generally and what the company is trying to achieve? Sure. Generally, what we're trying to achieve is to be able to make this tech usable in an industrial

setting and eventually in a government setting, but we want to start particularly in an industrial setting. The most easy way that I can describe ERIS is as a blockchain operating system. So it's a base platform which allows use of various blockchain. design particularly focused on those which have a smart contract machine in them, but not not exclusive to that. And we really open up this technology on a on a on a on a wider scope than a lot of other blockchains companies.

And so how how has errors evolved since I guess last year when we had press on I mean, back then, you had a specific technology stack, and it seems to have evolved since then. In fact, you were then using Ethereum as a consensus mechanism, and now you've switched over to tendermen. Can you talk about some of the changes that ERIS has been through since its conception? Sure. So we've really been always exploring two things. For those that are unfamiliar with the Genesis story of ERIS Industries, we came out of a bounty in the summer of 2014 when Olivia Janssen's was interested in a suite of software that could replace

the decision-making processes of a foundation. And at that time, there were two technical problems that we really needed to address in order to get at that. Number one was at the smart contract level of what does a suite of smart contracts that work on collective decision-making, what does that look like from an architectural perspective as well as a tactical implementation perspective. So that was one set of challenges which we were working on at that time and we're still exploring this idea of packages of smart contracts is still embedded within the ERIS platform. The other thing that we had been needing to work on at that time and still are chewing on is this idea of being able to merge different distributed protocols and to be able to provide a harmonized interface that one can use in a very simple environment such as your web browser. And so the ERIS platform has evolved significantly.

And one of the things that we've really been, has been our overall design goal, is to build these systems so that they are much, much more modularized. A lot of blockchain designs, in our opinion, are very monolithic in how they in the software stack they're dealing with. And we think that a more Unixie modular approach is more beneficial. So in the early designs, when Preston was on last, we had a little bit more rigid than we would have liked stack that, but it did get at these two ideas of moving information across distributed protocols and or whole. harmonizing information that you get from various distributed protocols along with working at the

smart contract level. So you mentioned that one of the two ideas that you were pursuing is you wanted like a harmonized for lack of a better word, harmonized user interface to a lot of different distributed protocols. Like some system where I code basically interact with a lot of different protocols and achieve some goal. Now, the question is, what are the kind of protocols that you're looking to harmonize with, and what are the kind of components that you think are needed to achieve this? Great. So I think that there's two main protocols, two types of protocols in which it's interesting to explore in this area, one of which is a distributed file storage system.

And there are numerous options for what one might use there. Of course, there's IPFS, there's BitTorrent, and other distributed file storage systems that can be used. On the one hand, on the other hand, you have a smart contract and blockchain protocols. And for us, those are the two main ones in which we have focused. Others have focused on the peer-to-peer messaging layer as a third major component. And I think that that is viable for many applications as well. So can you go into a bit more detail as to what the ERIS stack look like? What are the different components of the ARIS OpenStores technology stack?

So ERIS platform is really about Docker orchestration. And we feel that Docker has been able to provide a base framework. on which a lot of different distributed computing can be built. And so within the components of ERIS, we have the idea first off of services. And services are something that you turn on or off in the ERIS platform. These would typically be if you needed to connect to a public blockchain or a public blockchain-backed service, you can do that with one command in the ERIS platform. platform. And then also we have the idea of ERIS chains, which are sort of our gateway into the

relatively complex world of permissionable blockchain designs, as well as we have smart contract management functions built in, as well as a capability and wrappers around working with IPFS, which we think is one of the most exciting distributed file source protocol. that's come in the last few years. And you mentioned that you had components there that would allow you to interoperate with other blockchains. So this is a topic that perhaps we'll cover a bit later when we talk about permission blockchains.

But can you talk about how that works and why it could be useful for an ERIS blockchain to interoperate with, say, a public blockchain like Bitcoin? Sure. And what specific use case? you might see there. Yeah, interesting. Yeah, so a lot of folks are interested in being able to build process-based logic,

which can be then used with a payment system. And so the way that you would interact with that is you would have a middleware, which would be capable of talking to both designs via their APIs. And then when something happened either in Bitcoin, where you would set up watchers, for example, someone makes a payment into a specific account, then what could happen to the smart contract layer is that then a file could be released to them. I mean, essentially this is very similar in nature to one of the things that Ethereum has explored with, or well, consensus systems has explored with Ujo music or Uji music.

I'm not sure. Okay. I think another interesting use case would probably be for document and orderization where you'd want to have a public record on the blockchain of documents or data existing, time stamping basically. Yep. That would be another very valid use case. So when you started building ERIS last year, I remember distinctly that you had the approach of trying to build your own blockchain. You had forked Ethereum at that time and you had this, had like a blockchain design that you called Heolanus. And over the past year, I've seen that you have kind of moved away from that direction of like building and perfecting your own blockchain design into the direction of using tendament and their consensus system as your blockchain design. Now, what was the motivation behind this switch?

and how did that go? The motivation behind the switch, as Ethan once said, was do we want to rely on 30 geniuses or one genius for upstream? And at that time, we had been, Ethereum was a very, very fast-moving code base at that time. And it was a real challenge for us to maintain an upstream project that was being significantly redesigned on a weekly or even monthly basis. Our goal with what we are trying to do is to be able to bring

permissible smart contract machines to the market. Now, this requires a few different modules when you're looking at building a blockchain design. You have, on the one hand, the virtual machine, which is tied to the base blockchain. Then you have the consensus mechanism or module, which then make sure that all of the clients are looking at the same thing. And then you have the signing component of a blockchain design. And what we've always been interested in is having as much modularity here as possible. And so we felt that, number one, the tenderness consensus mechanism made a lot more sense in a permission.

environment than what Ethereum had been working on at that time, which was just a fairly base proof of work algorithm. And when you're in the land of permission blockchains, proof of work does not really make hardly any sense, not nearly as much as proof of stake does on that side. Tenderman is pretty much the fastest and most widely regarded, proof of stake 2.0 system, we could call And so in that regard, we felt it was a good base consensus mechanism. On that hand, and we also felt that the Ethereum virtual machine had a lot of community support behind it as a virtual machine smart contract interpreter.

And so what we've tried to do and I think, you know, is to harmonize those two strands. Let's take a short break and talk about hide.me. Have you ever tried watching streaming TV from abroad? If you have, you've probably been greeted with an annoying error message written by some idiot lawyer telling you that you have no rights and you can't watch this program from outside the country. This used to happen to Sebastian all the time when he was in lonely France trying to watch his favorite moose hockey game in Canada. And you wouldn't believe how angry he got. That's where most of his gray hair comes from. With hide.combe, this painful phase of my life is now over.

When I want to watch American television or my favorite moose hockey game from Europe, I just changed my IP address and nobody ever knows where I came from. And with gigabit connections, I have zero lag. You can give Haithomi a try with their free plan. Their free plan includes two gigabytes of data at unthruddled bandwidth. You can use any of their free exit nodes, which are in Amsterdam, in Singapore, and in Montreal. And you can sign up for that at Haithomi slash epicenter. Now, if you use URL, and if you decide to go premium down the line, it's going to get you 35% off.

And the premium plan gives you a lot. It gives you unlimited data. You can use as much as you want. You can connect up to five devices. So your whole household fits on the plan. And you can use any of their exit nodes all over the world. And they've got like 30 of them. And of course, you can pay with Bitcoin.

So give it a try. We would like to thank Haight up me for their supportive website and Bitcoin. So now one of the big differences, like you mentioned that proof of work doesn't make sense in a permission context, but proof of stake might. And Ethereum is now also moving into a proof of stake concept. And at the DevCon, I saw that there are many other groups that are wanting to build permission, like,

permission blockchains based on Ethereum's design. So, I mean, in the sense that in the future, we might have designs that permission blockchings at a base built off of tendament, and then we have blockchains that are built off of Casper. And could you explain what the difference between these two will be in terms of settlement finality or the main, main differentiating factors between these two ideas? Yeah, so the main, what everybody is going to, seemingly within the smart contract space with their blockchain designs, number one. And this is an important point to bring out, I think, is to move consensus out of process, which means,

not within the main core blockchain client itself. So consensus in the way that ARSDB will be just after the new year, it runs as two separate processes. You have the main ARSDB process, which then talks to a tendermint consensus engine. And the only thing that the tendermint consensus engine is worried about and concerned with is the consensus portion of this. seemingly Ethereum will be moving in this direction as well. We see that the, and maybe I'm not exactly right, but the delegated witness project coming out of Bitcoin is also exploring some of these ideas.

If you look at it from a particular point of view, that's how we see it at least. And so if you have blockchain designs would start to move consensus out of where the application stack is, as we call it, then you have you you open up more modularity and options for folks now one option will be most likely Casper will be built as its own process engine in a very similar design pattern to what we're prototyping and exploring right now with the way that RSDB and tendermint will work together

and so you'll have two different consensus engines that will both be proof of stake 2.0 and both will be very, very interesting. The main difference that we see is that Casper has taken certain design decisions. Vatolic and Vlad have taken these design decisions really around this idea of optimizing for public blockchain. So at ETH DevCon, I wasn't there, but I'm pretty sure I saw from some of the slides at least, that Vlad was very clear that his design choices have been meant for a public blockchain. In other words, he has less, he, Casper comes to finality, but not before blocks are published. And so that's something that seemingly makes a lot of sense if you're in the land of public blockchains.

If you're in the land of permission blockchains, though, in industrial applications, what you don't want to see is a little bit of a unknown period. And so in that context, what makes more sense, at least for us and our clients, is to move essentially the negotiation process among validators to be to during the block creation process rather than ex post when a block is is published. This is the major, as I see it, this is the major difference between these two protocols. So as Jay and Vlad both admit, Jay favors consistency over availability, and Vlad favors availability over consistency. And what that means, essentially, is where do we move the validator negotiation process? Is it before or after blocks are propagated throughout the network? Right. Okay.

Well, what's interesting here is the idea of modularity that you mentioned earlier, where essentially the database part, the ledger part, is completely decoupled from the consensus part. And as more consensus algorithm to start to emerge and more ledger technologies, you know, we have the ability to construct a system that serves specific business needs based on what these different technologies can offer. So I think it's sort of a, it shows that the technology is sort of maturing in that sense. Would you agree? Yes, 100%. And one of the things that we were really exploring with Thelonius, going back to the very early days of what we open source with ERIS, was this idea that consensus is a little bit too rigid in current blockchain designs.

And we wanted to work on opening up more experimentation there as well as more optionality there because, you know, people argue relentlessly about consensus and fair on them. for doing that. But it's a little bit awkward for a blockchain design to have to go all in on a consensus when you could potentially give some optionality to your users as a blockchain designer. Okay, so let's talk about permission blockchains for a little bit. Personally, so I'm working on this new startup project now called Stratum,

which I've mentioned before, and we're using permission blockchains to do certain things. And we're also using the Bitcoin blockchain for other types of things. And one thing that I find very difficult and very challenging is explaining to people what blockchain technologies are and how they're useful without first explaining what Bitcoin is and how Bitcoin sort of changed the way we think about consensus and such. I'd like to get your thoughts on this. Is it possible to explain permission blockchains without having to explain Bitcoin?

Essentially, it's a question of blockchains without Bitcoin, which people seem to be talking about at this time. And I guess my follow question would be how are blockchain technologies, permission blockchained technologies, useful for industry? Great questions. I spend many of my days answering this question. So how I explain it is generally I do not start necessarily with Bitcoin because when you're in the land of permission blockchains, it's actually a little bit easier to start with traditional data and process management solutions rather than starting at Bitcoin. So generally, if we're looking at data management and process management solutions, you'll have a spectrum which will get set up where on the one hand, you have traditional solutions, which are.

are currently maybe distributed, but wholly under the control of one enterprise. And then on the other end, you have fully public, fully decentralized blockchain solutions, and then you have permission blockchains, which are somewhere in the middle. And so I generally start with this idea that what we're really talking about here

with permissionable blockchains and smart contract technology is business process improvement software. Now, there has been a lot of business process improvement software that has come up over the years. One need really only walk down the terminal of any modern airport to see advertisement after advertisement of enterprise software that is really about business process improvement. But the challenge that that software has had from a strategic point of view is that it cannot really be ran on metal,

which is outside the control of one organization in order to have the verifiability that one wants. And with smart contract technology, what we have for the very first time is an ability to build business process automation software that cuts across different stakeholders. And so that's generally where I begin when I'm talking with folks.

That's very valuable. I might use that when I'm explaining the blockchain to people. Okay, so if we're thinking about business process automation, then what is, in your opinion, the greatest value that blockchains can provide specifically on business process automation? And I guess, you know, it's the question regarding industry here is what, how can it improve business process automation when, multiple parties are involved in a process. Well, that is the, that's the sweet spot for really blockchain and smart contract technology.

I know. Yeah, exactly. It's also one of the biggest challenges if you're looking to, to really enable this within enterprise. So it's a double edged sword in that sense. And we can get to some of those challenges later, hopefully. But the winner is right now, business process automation stops, as I say, at the glass doors of the enterprise. In other words, there is a whole bunch of automation that has happened around business processes, but those processes which are internal to a company have been automated.

Now, if you were talking about multiple stakeholders in a deal, so let us talk about a corporate bond scenario, let me say, just to pick a finance use case. Let's go into an example here. I think people need to wrap their heads around really what this looks like when you have the only three or four companies working together and how they can implement this. Yeah, exactly. So when you have a corporate bond, for example, you have multiple, generally you'll have multiple banks which are underwriting the bond or initiating the bond one can think of.

and then you will also have multiple parties which will be involved in the administration of the bond. So you have calculation agents, trustees, and other parties involved in the administration of that bond over its lifetime. You also have the bond holders who generally will have some rights and responsibilities about this financial instrument. And finally, you will have the company which issued the bond involved in. a scenario. So what you're looking at is instantly multiple parties and a big range of stakeholders and various outcomes which might be needed based on what those stakeholders' rights and responsibilities are. The way generally that this works today is that folks are able internal to each of the underwriting banks, let me say, they're able to administer their duties under the term sheet,

which are inherent to them, and they're able to audit, sorry, to automate the duties, which are internal to them, and then the other banks that are underwriting would do similarly. And then there will be a reconciliation process that will be needed between the various stakeholders. And the idea is that that reconciliation process is generally prone, number one, to human error, and number two, it's very slow because at this point, it's mostly humans that are doing that reconciliation. And so this is one of the areas

where you can use blockchain technology to essentially stop making a bunch of API calls, which are really human-level API calls between banks, and to stop doing that and everyone just look at the same core data set, and that's what a blockchain in a permission environment is able to open up

But, I mean, bonds are one area, but there's a whole range. We view this technology as a horizontal. So perhaps I could go through a different example, and you tell me if something like this makes sense. So today in the world, you have a lot of different markets, like Uber is a market, for example, where people who have taxis who can drive around people need to be matched with people that want.

that right you have markets like eBay that allow people want to sell stuff and people want to buy stuff to coordinate so what happens to really like these kinds of markets are formed by one company and there's a lot of automation inside that inside the process of that company itself so if you imagine a market for let's say old mobiles then the company might create the market and have a lot of automation inside the inside the market itself but But what does not exist is if there's a market that's created by one company and a similar market created by another company, then the users of one of these companies cannot interact

with the user of the other company because the automation does not work between companies. Right. So if there's firm A that creates market A and firm B that creates market B. Lift and Uber. Yeah, Lyft and Uber. Then the user of service A cannot really interact with another. service provider in service B because there's no way the flow of automation can go from company A to company B. And what you're essentially saying is if you have an architecture

where there's a blockchain in the middle and both company A and company B can offload some of their automation onto that blockchain, then perhaps you could have a new kind of architecture where user of company A of service A can actually interact with user of service B. or something like that. That's exactly right. We call this participatory architecture. And the big difference here is currently in traditional enterprise software, you have to own the data and you own your data management solution.

And what we see this technology opening up, and we think that this is going to be particularly important for information age organizations, which run on a more distributed environment and in a more distributed context, we think that this paradigm of what I call participatory architecture rather than data ownership is what will really enable information age organizations to be able to succeed moving forward. Yeah, that's like a very, very nice argument for the use of blockchain technology. that what you're trying to say is like this business processes all around the world and

blockchain with blockchains you can make business processes that cut across organizational boundaries now what's also interesting is that the permission blockchain industry today has many subsections like eris is one this digital asset there are a lot of small teams that are trying to make permission blockchains and A lot of the mind share for business process automation across organizations, if you think of that as an industry vertical, a lot of mind share goes into only one type of process, and that is clearing and settlement.

People think out of the universe of business processes that can be automated using blockchain, they're trying to focus on clearing and settlement between financial institutions. So you have ideas like what would happen if all, all the banks in a particular country like England would have shared a common blockchain and be able to do different kinds of movements of money on that single blockchain. A lot of focus goes into just optimizing, clearing and settlement for permission blockchain technology. Whereas you have the view that this actually isn't a very interesting use case. Can you shed light on why that is so?

Sure. There's three reasons that make this a challenge, I think. Number one, you have performance challenges with blockchains. So, blockchains, as we all know, are generally pretty slow vis-a-vis existing traditional solutions. In the very early days when people were trying to understand what we were saying, when we were pretty much the first to market with a permissionable blockchain design and people were trying to wrap their minds around it,

they would constantly love to remind us about the fact that blockchains were slow, which we were always and remain very familiar with, and we understand that. So on the one hand, when you're talking, it a little bit depends on the market. I mean, my hesitancy around this use case mostly is limited to high volume markets.

I can see the use case in low volume markets. The second reason is when you're looking to embed an emerging technology solution within legacy infrastructure and within legacy enterprises or incumbents, you have to always keep a mind on what is the change management calculus that the industry or enterprise is going to have to go through in order to really implement this solution. And one of the things that you will be constantly looking at and keeping an eye on is,

does the benefit actually meet or significantly exceed, in this case, the cost of what the change would be? And when you're talking about infrastructure-level software with which blockchains are, then really what you're talking about is ripping out, a significant portion of a bank's infrastructure. And in order for the board of a bank to approve such a drastic change, they have to see a massive, massive opportunity opening up.

And what we're looking at in most clearing and settlement markets is maybe a marginal improvement over what we currently have. But I am skeptical and I have yet to see a study that shows that there is a, a, a significant amount that can be gained from doing pure clearing and settlement on a blockchain, which is not just simply iterative over what we currently have. And maybe that will come in the short time later. I'm not sure. The third reason that I think this is a real challenge is because of, if we're talking about

these types of markets, you number one have to onboard. an entire industry, which is always much, much, much more difficult than onboarding a single enterprise, number one. And number two, you have a massive challenge around privacy. And as I always say, blockchains are transparency machines, and they're really, really awful at privacy because of that, different sides of the same coin. And so if you have a challenge around privacy, that really gets at and brings down even in the potential benefits that one might have.

Touching on this issue of privacy, this is something actually that mayor, I think you may have told me about one time or opened my mind to this idea of permission blockchain being really bad at privacy, which I hadn't thought of before. And so if you have a blockchain that's behind a firewall, you're trusting your least or the most malicious node to not reveal the data, which is inside that firewall. world blockchain. So essentially, if you have maybe like 100 different nodes controlled by, say, 100 different organizations, one of those could go rogue and publish some private data and you can't do anything about it. How can we address this? This is something that really is really important to the

development of the blockchain space. And is it perhaps a barrier? What do you have thoughts on that? I think it's much more important in a public blockchain context than in a permission blockchain context, because in the permission blockchain context, as you just said, you have other options. And they're not perfect options. But for us, we think that when you're using blockchains appropriately, you should be on the transparency end of the spectrum. and for us, at least, this is where we see. So we like to leverage the advantages rather than trying to hedge against the disadvantages. And a lot of that depends on how do you describe and how do you implement this technology? For example, if you implement a single bond as its own permission blockchain,

and you have everybody onboarded, which is supposed to be onboarded, with respect to all the various stakeholders, then you actually want to have full transparency there within that particular blockchain. If you think of the fact that we're going to have all blockchain, sorry, all bonds in the world are all going to be on a single blockchain, that challenges this notion of who needs to be able to see what in a much more drastic way than if you say we're going to do one bond per blockchain.

So it's sort of the lens in which one looks at this technology differs. Today's magic word is software, S-O-F-T-W-A-R-E. Head over to let's-talk Bitcoin.com to sign in, enter the magic word, and claim your part of the list of award. So, coming back to the topic of clearing and settlement, that was a question. pretty interesting answer so what you're essentially saying is if you if you consider this scenario where like let's say a lot of different banks want to implement one blockchain and do some kind of movement of funds like clearing of exchanges and settlement of exchanges on that single blockchain then there

are essentially a couple of different problems with that approach the first is transaction throughput and scalability which which is a challenge today but which may even be solved in the future. The second thing that you mentioned was the calculus of cost, which means if you want to change the whole financial infrastructure of, let's say a nation, that's a lot of cost to it, and what exactly is the benefit? That is unclear today.

Third thing you pointed out was the privacy aspect, right? that once you have a blockchain for finance, shill transactions, at that scale, it might need to be public, and these are transparency machines, not privacy machines. So is that a good summary of your answer? Yep. Yeah, so let's move on to smart contracts. So similarly to blockchains and the question I asked earlier

about how you explain blockchains to industry professionals, how do you approach the question of smart contracts? with clients or people that you might talk to at conferences, things like that. Exactly the same way. I mean, generally I lump the two together. For us, I mean, the idea of a blockchain alone doesn't really give anybody anything. I mean, essentially you need to have some suite of automation on top of it in order to have any benefit within industry. Sorry, that was a bit, that was a bit exaggerated. certainly in the land of public blockchains, Bitcoin, specifically, yes, you have definitely some value there.

I'm not trying to say that. But in an industrial application where most industries and most enterprises that we have talked to, they don't have a challenge around tracking who owns what when, to the extent that there was a challenge there. And perhaps there's some very interesting applications of only that question. within an insurance context. But outside of that, really what you need to focus on is what is the blockchain doing for me. And to get there, generally you're talking about what is the virtual machine that is tied to the blockchain, whether that is a Ethereum style virtual machine on which you can deploy smart contracts

or whether that is a more shrink-wrapped solution, which some of our competitors build and they prefer to take that style. For us, we think that a virtual machine, which has some capabilities to run scripts, is a very powerful start for beginning to look at this technology. We think down the road that you could probably kind of lock down solutions for particular business problems, and you might be able to get away from this idea of using

an Ethereum virtual machine style of, blockchain because you would have much more clear ideas as to what were all the steps that would need to be taken within a particular business process. But at this point in time, there's a ton of negotiation that is happening within industry as far as how do we track financial objects, how do we properly parameterize and then build interfaces for financial objects, which are dealt with at a blockchain layer. You also have a lot of challenges. around what does this stuff even look like. And so I think it's a little bit early to optimize, for us at least,

it's a little bit too early to optimize and try to lock down into shrink-wrap solutions. So we prefer to tend towards the virtual machine style blockchain design, at least at this point. And so, but really, how do I explain smart contracts? I start with the business process improvement line, which we talked about before. because I view these things together as kind of merged at the hip. Well, I guess it just sort of goes to, it felt the same logic of modularization that you spoke about earlier. And we could think of Bitcoin as one of these lockdown solutions where you have the database and also the business logic and the consensus locked in the one. So the business logic would be the smart contract, the database is the ledger, and the consensus mechanisms is proof of work.

And so what you're saying is that when you explain to people what a smart contract is, it's simply the business logic part, the virtual machine code execution part of what will essentially process data and put it into the ledger, which is the database. Yep, exactly. That's a really interesting way to look at it. I mean, of course, when we think of blockchains, we look at it this way, but to explain it this way to people, potential partners, it really shifts your thinking, especially when you've been in Bitcoin so long and you think of Bitcoin as a currency and then also all of a sudden you have this smart contract

thing comes up and you try, you somewhat tied to this idea of decentralized currency and all the ideas of Bitcoin. And to think about it simply as like software and business logic and database and then the idea of consensus, it's interesting that experiment that's not always that easy to come to when you come from the Bitcoin space? Yeah, I think that's exactly right. When you're coming from a Bitcoin perspective, it does break down things a lot. And we have, our company is not the most popular company on our Bitcoin, let me say. And I think a lot of that is because of challenges around how to explain where we are coming from and our perspective

to somebody that has taken that background and has for the last X months, however many that is and how long they've been in Bitcoin, would be obviously person-specific. But during that time, they have sort of embedded this idea of what a blockchain is and collated it, sorry, not collated, but merged it with Bitcoin as an application. So we view the blockchain as the core base technology, and we view Bitcoin and its blockchain as an application that is built using all of these components, which we just talked about. But to be able to pull those apart a little bit for folks has been a little bit of a challenge for folks that are coming from the Bitcoin side. For folks that are coming from the enterprise side, it makes it a whole lot more approachable than starting all the way at Bitcoin and then having to,

beat down some of those ideas of Bitcoin to get at where the raw technology is, which is for us somewhere in the middle, how we implement solutions. So Casey, perhaps you are the perfect person to ask this question because you have been a lawyer. So we have the idea of a smart contract. And in certain cases, we do see that smart contracts can be a replacement for a traditional legal contract. Or let's say we could say that smart contracts are a subset of legal contracts. So the question is, is this correct? Do you think smart contracts are legal contracts?

And how do you, if in a situation you have a conflict between the results of a smart contract and a legal contract, how would the legal system handle cases like that? Great. I love answering this question. Generally, what you're looking at here is two different things. So if we say a legal contract, let us interpret that for the course of this discussion as a PDF or a piece of paper, which you can take into a court. And a court will not have a problem interpreting what it is. It won't look at you like you're crazy.

It will say, oh, yeah, this is a contract. I know how about to do with this. And let's call those legal contracts for the scope of this discussion. You also have smart contracts, which for us and are simply scripts that are saved onto a blockchain. They don't necessarily have anything to do with the legal system, despite the fact that they're called contracts by default. But what's interesting about this technology is not what smart contracts are able to do and how they are structured by default. It's what you can actually do with them. So let's take the idea that you can build a smart contract so that it can fulfill the requirement of a legal contract.

So in general, what you have with very, very simple legal contracts is you need to really satisfy three criteria in order for a court to say, yes, you have a contract here. The first criteria is has there been offer? The second criteria is has there been acceptance? And the third criteria is, is there consideration? So consideration means, am I just giving you a gift? Or is this a bilateral relationship? In other words, am I giving you something and you're giving me something? And so we do not have a contract, for example, for this taping.

You know, I give up my time and then in response, well, what's the consideration coming back? Well, that's very different from an employment relationship. In an employment relationship, I give ERIS my time and it gives me money. And so there is consideration, which goes back and forth. Now, also, there has been this idea of a contract has been offered by one party and accepted by the other party. Now, you can represent these three ideas without a problem in computer code. There's no challenges from the legal perspective as far as number one, unwritten contracts. So since legal systems have existed, people have been able to have strong contracts which have not been written down.

This is not something that is new. And generally, contract law is written to avoid too many formalities. with the some exceptions depending on what domain you're in. So as you get into more and more specific domains, there are increasing formalities which need to be required in order for the legal system to be able to interpret an agreement, for example, as a corporate bond. Then there are a whole range of formalities and necessities

which need to be fulfilled by the agreement itself. Now, those most legal systems on earth do not interpret those as specific words on a specific sheet of paper. Instead, they offer them, they need to see what is going on here as far as the relationship between the parties. And so since the 80s, for example, in the U.S., sorry, in the 90s, early 90s in the U.S., we have been able to, we've had an Electronic Transactions Act, which allows, for agreements to be comprised completely in computer code since that time. And those generally have been, the computing requirements have been held in kind of a neutral third party, a clearinghouse, a settlement system, or some sort of escrow party. Now we have the capabilities not to have that third party, but instead we can do this

back and forth as long as we meet the legal requirements for the financial instrument or the agreement that we're trying to do, which do not mean necessarily specific words on a paper, but yet a mechanism of interaction between the two. Now, where you to take today an Ethereum smart contract to a court, you would have a hard time getting a court to enforce that. So we prefer when we're working with clients to have this idea of dual integration, where on the one hand, you keep your current contract templates as they as they exist and you add a little clause at the end that says that this agreement is being tracked at a smart contract which has address X on blockchain ID Y whatever those the address of that smart contract is and whatever the idea of that particular

blockchain is and so then you what you end up doing is you are able to pull out the self-administering portion of what the contract is doing and you merge that with a document that a court can interpret in a predictable manner. Because what you don't want to have if you're an organization or an enterprise is to start to have unnecessary, unpredictable outcomes from a court if you need to go there. So do you think that at some point we, so right now we still have to rely on sort of this traditional contract model that can reference a smart contract on a blockchain. Do you think that will ever come a day when we can just write contracts in Ethereum, for example,

and as long as one can prove that this is your private key and that it's linked to your identity through some identity systems that perhaps only exist yet, or government IDs that are linked to a private and public key system, that these would potentially stand up in court? How far away do you think we are from that? It's not really a function of whether it will stand up in court. It's actually getting predictable outcomes from a judge judiciary, which is not versed in being able to read code. So there's potentiality here where it would stand, where these things could potentially stand up in court today.

There's no, as far as I can see, depending on where you are, let's, let's assume that you have, you have accomplished all the legal formalities that you need to do within smart contracts, which are mostly doable. If you've fulfilled those legal requirements, you could take a smart contract to court today because of the way that contract law is written. It's quite loose. But what you won't have, and a court would potentially enforce that contract, but what you don't have is really predictable outcomes on what a court will think that contract is.

one meant to do and number two actually doing. And so that's where it's going to be a real challenge for the next little while, not necessarily around whether a court would enforce it, but how a court would enforce it. So I mean, like with the how question, what kind of seems interesting to me is, so let's say like you mentioned, two of us are entering a contract and we have a legal contract. And in that legal contract, we have an integration with the smart contract. We had a statement that said, okay, part of this logic, part of this contract will be handled by this smart contract ID, this particular ID running on that blockchain.

Now, so we have a legal contract and that's linked to a smart contract running on a blockchain. And when we made the contract, we thought that we had the code right now. Now it turns out that the code actually. actually had a bug and the the the the code did not perform the way either you wanted or I wanted and it ended up doing something else altogether now both of us agree in principle that yeah we should disregard what the smart contract did and the distribution of fun should happen in an in a different way and now

we go to code with it what would happen in a scenario like that who like Like, can the, can the court actually say that no? In your legal contract, you link to a smart contract. And even if it had it had its bug, we have to treat that bug as the real thing. Or the court says, no, we agree that we should disregard the results of the smart contract and have a manual exchange of funds on that permission blockchain by the nodes earning that permission blockchain. What would, what would happen in that case?

What wins? Does the smart contract win? Or does the underlying legal contract win? Generally, the underlying legal contract is going to win in any of these things. A court will most likely, I mean, it's hard to say exactly, but most likely a court would interpret what it knows. So it's going to take the path of least resistance to enforcement here. And most likely the path of least resistance is going to, favor that, the legal contract over the smart contract in that context. Now, that said, I mean, it's very context specific. And these questions, what you're trying to get at, I think, are these questions of what we call factual ambiguity. And factual ambiguity are inherently hard questions. And really what you're talking about is the intent of the parties, which are even

harder questions to answer within courts, but this is why we have courts and this is why lawyers and judges exist in order to help adjudicate these disputes should they come to this. And so hard to say in the abstract, indeed impossible to say in the abstract. Before the show, Brian, I talked to Brian and he requested that I specifically asked this question because it seems you have given a lot of thought to this. So what do you think about running governments using smart contracts or in the future converting the entire governance process into a suit of smart contracts running on blockchain, what would that look like and what would be its impact? Yeah, it's quite futuristic for me to think about running entire governments

on blockchains. But I think it might be a little bit more productive to look a little bit closer because that would be probably generations down the road to run entire blockchains on, sorry, entire government's on the blockchain. But so one of the things that's very interesting to me and I've worked in this area in the past is ideas of a budget transparency where you're looking at, for example, new infrastructure development. So oftentimes the way that this happens is, that you'll have multiple public entities which will pool money together and sometimes along with

private sector money, not all the time, but depends on what you're building. And those funds after they're pooled will be then administered by usually an accountancy firm or audit firm. And what they will end up doing is do wholesale distributions down to three or four or five general contractors who then will do not usually the work, but more of the project management, and then they will hire subcontractors and potentially sub-subcontractors that will end up doing the work. So if we're building a new highway, you'll have multiple levels of government, which will typically pool their money,

and then that will be administered by, let's say, an accounting or auditing firm, who will then do wholesale distributions to large contractors, and they will then do subcontracts down. And then on the way back up, there will be a reporting system, which will be put in place. Now, that is actually something that would be very interesting to track in smart contracts because you are able to leverage the notary portion

of what a blockchain can do. You're able to leverage the transparency aspects of what the blockchain can do. And you're able to have the modular business process logic which smart contract-enabled blockchains can provide for you. And so you get around a lot of the limitations that you have in a purely private sector endeavor, such as a bond chain or whatever for the United Kingdom.

And so I think some of these areas in governance, while they will take a little bit of a time to get up and running, will actually be even more powerful than some of the private sector solutions because you're able to leverage the transparency in a positive, way rather than trying to hedge against the privacy limitations which you will be facing on the private side. Oh, that's a very interesting idea. I always like to take examples when I get ideas like that. So when you were describing the idea, the kind of example I got is, let's say the Indian government wants to build a road from the city of Delhi to the city of Mumbai.

And now this whole project is going to cost, I don't know, it's going to cost $10 billion to build a super highway from connecting these two cities. And there are lots of stakeholders in this process. There's the government. And now the government doesn't want to build the old. Multiple state governments. Multiple state governments, city governments, people who have the land. And the government doesn't want to build the road itself. So it's going to announce a tender and somebody's, a lot of people are going to bid, like I'll build this for.

for 10 billion, somebody else will build this for 11 billion, etc. And the government wants to award this to one of them. And then the company that means the tender won't do the job itself, it will have like sub-tenders to other smaller players to build small chunks of it or say, buy the cement, etc. So the kind of imagination I got is

what if all of these parties were on one blockchain and that blockchain basically handled all of the business logic for a complex project like this? that and any citizen can go to the blockchain and see what actions what tenders what bids have already occurred on the system and so there's transparency there's that they know that there's no corruption going on in this system so the transparency there has a lot of benefits itself and the business logic like the like the blockchain helps by automating what all of these parties needs to

do right would that be a would that be a Would that be a nice imagination for what you're saying? Well, ask me that question again in about the middle of next year and it won't be an imagination. It'll be built. We're already working on this with pretty high-level stakeholders. You'll see it pretty soon, actually. Wow, that would be really awesome because like in India, the problem is these types of big projects happen. And transparency is a big issue.

Many people think that the funds are not handled properly and they want continuous updates on this on on on what's going on with that project So something like a blockchain might might really be useful there We think so then the question is you know will it be in the government's in India for instance would it be in the government's interest to actually adopt that and will they Generally it is I mean this is what you see out of the open data movement is that there's not not there's not a strong constituency within many governments on earth of trying to lock down government information coming out. You'll obviously have minorities of folks that will perhaps be bad actors within the system that won't want information to come out. But across the board, we're seeing with the open data movement generally that public sector actors get this for the most part. I mean, unless we're talking, you know, security services or whatever.

Right. So before I wrap up, I'd like to talk about what we may call blockchain as a service. We've seen this term pop up recently, specifically Microsoft announced that they would have Ethereum, ERIS and IPFS nodes in their Azure store. So Azure, for those who don't know, is sort of the equivalent of AWS at Microsoft is their cloud hosting platform. and easily deploy applications there. And they have, I guess, sort of store where now you'll be able to go and simply deploy Ares nodes there.

And this is something that I'm really interesting because at Stratum, we're building a stack, which would enable people to deploy private blockchains very easily, and then with APIs, be able to interact with those blockchains. But the question that I'd like to ask you and something that we've been thinking about is, if as a company, as an organization,

or a group of companies working together, you know, the value of blockchain as a service is not having to implement that infrastructure and maintain it yourself. If as an organization, you delegate that to a company like, say, Stratum, or could be anyone else for that matter, Microsoft, then do you not lose the value of controlling your own data?

And in that case, if the solution is that as that organization, you also have nodes that you know that you know control yourself, aren't you just coming back to the same problem of maintaining that infrastructure? Yeah, that's a really interesting formulation and I quite like that formulation of the question. It hinges really upon one of system design and what you're trying to accomplish. One of the first things that I would consider is, is the blockchain as a service running behind a VPN? And if it is running behind a VPN, where is signing happening? In other words, is signing of things, are the nodes using signing out of process or are they using signing in process?

Wherever the keys are, that's where the real sort of choke point is. And if you're uploading keys to a cloud provider, then you have to understand that you're uploading keys to a cloud provider. and you'll have whatever security arrangements you've built in. And so on the one hand, you have a little bit of a tension there between security and usability. And this is not a new tension within blockchain space, of course. This is an old tension within any publicly infrastructure type of situation. And perhaps even in all the computer science, it's a tension.

And how we see blockchain as a service is, on the one hand, making it much easier to get up and running for prototyping. And then over time, as you need to start locking things down, probably what will be happening is you'll move the keys away to areas which you control, number one. Perhaps that's on a server in your office where you do all the key signing. And the nodes which are running in the cloud, they simply send an API call when they need to sign something.

think to the computers where you have. Now, you have to maintain those computers as well, but if you're going towards production and hardening, then you're going to have the operational faults who would be responsible for that in any production system. And so you're repurposing them from other solutions onto this type of solution, but you're still going to have the operational considerations around security in any event. But if you're just trying to get up and rolling, then you probably don't care. Well, I think that from my perspective and specifically, you know, stratum, we're not holding any keys.

And I think we can assume it's a best practice for industry players not to hold keys or at least have some sort of a multi-signature model where, you know, the organizations deploying those blockchains would have a signing key. And perhaps the clients, I mean, sorry, the clients would have a key and perhaps the company's deploying. these blockchains without a secondary key and a multi-signature scheme. But what I was referring to specifically is the database and consensus mechanisms, I guess specifically the database, if you're trusting a provider to hold all of the database information in the blockchain architecture and that company disappears and you don't have the nodes on your end to also replicate that data and also the smart contract, the business logic layer, if all the business logic layer is implemented with your service provider and that service

private disappears, then you're kind of out of luck there. What do you think? How do you see this remedied in a world where? There's multiple service providers. Right. Okay. Yeah. I mean, unless, of course, that service provider.

has some sort of proprietary technology that they're also adding as a service on top? Yeah, of course. Of course. Yeah. And but the way that at one of the things that's interesting about blockchain technology is that it scales horizontally. And this is very different from traditional architecture solutions, traditional software architecture, which has scaled vertically much more easily. So if you think of a, a, a, giant SQL database that is meant to scale vertically rather than horizontally. If you think of what blockchains are actually really good at from a data management perspective, one of the things is that it scales horizontally. So essentially you fire up a new node on your different cloud service provider,

and either you punch through whatever the VPN is, if you're running behind a VPN or firewall, you would have to, you know, integrate that outer layer of security as well. But let's assume that problem away as a fairly solvable problem and so now you connect into the blockchain network and it downloads the blocks and it syncs back up without a problem on the new service provider or on your laptop or whatever on your grandma's computer if you need it it that's one great thing about blockchains and why I'm not I don't see this as a giant tension at least for us and our users because you can always spin up new nodes on AWS if you're worried about Microsoft going away

I think it might be a little bit different in you guys context, but. Right. I think so too. I guess my last question is before I wrap up. Actually, this is Brian's question, which he sent it into us before we started the show, is we looked at all the technology stack ranging from the consensus layer to the database layer to the VM and the applications that will build on top of that. Which ones are you most interested in? and where you see business opportunities for commonization,

Ruthie Gerrits, all this technology stack? I think that consensus is, I don't see a lot of business value extraction opportunities at the consensus or the database layer. I also don't see them at the outer virtual machine layer. I see them really around what is that business process logic doing. doing if we think of blockchains in terms of infrastructure level software very few very few infrastructure level software has projects have succeeded while being proprietary in fact I can't think of a single major one since since the 90s that has really succeeded I mean things that succeeded before that

have continued to do well but that's more inertia rather than new projects coming on board so I think that the base the base base platform layer, however it's conceptualized of consensus of a virtual machine or many virtual machines as well as the base database for how we think of this, the base ledger components. I think all of that will remain, will be open source and I believe strongly around that. So if you're in the land of open source traditionally over the last maybe five, 10 years, there's been two major business opportunities which have come on, one of which is what I call a pay-per-convenience model.

Basically, this is what most continuous integration software does, for example, that I pay continuous integration services to give them, so they run things for me, which are more convenient than me running my own continuous integration service. And on the other hand, you have the pay-per-privacy model. This is, we can think of this as GitHub's business model in that. that the base GitHub is open and free, sorry, is free if your projects are open source,

but if you need to have some privacy layer, then you pay for that. Now how that actually looks in blockchain land is a little bit of a challenge for me to see exactly. I can really see pay per convenience models develop, and that makes total sense to me where, you know, blockchain technology is a little bit of a challenge to run. It's new, it's fast moving,

And so there's a real business opportunity, I think, around making it easier for four enterprises to get onboarded and run with smart contract technology and blockchain technology. And then the other piece is what's happening at the business process layer. And that is not so, in my mind, does not so clearly need to be open source. In fact, I think there's a strong argument for it to not be open source, but rather to be proprietary. And so if you're thinking along more traditional software development lines to where you keep your secret sauce secret, I think that's where the real opportunities are. Well, I think that's a great note to end on. We're definitely pushing the limits of time here with this episode. It was really interesting to talk to you about permission of blockchain, smart contracts and all these topics, which I personally, and I think may as well think of all the time. and looking forward to seeing what ERIS is going to be releasing

and what type of interesting partnerships we'll be talking about in the near future. Thanks for having me on. You're very welcome. And of course, thanks to our guests for listening. Episinter Bitcoin is part of the LTB network. Of course, you can go to let's top Bitcoin.com to find their amazing catalog of shows about Bitcoin, cryptocurrencies, blockchain technologies, and all that stuff. you can hear new episodes of Epicenter Bitcoin every Monday.

We release them on SoundCloud, iTunes, or whichever podcast app you use to listen to podcasts. You also can watch the videos at YouTube.com slash Epicenter Bitcoin. And if you're a loyal listener, you can always send us a, give us a review on iTunes or Stitcher or wherever you want to give us a review. And if you do so, send us an email at show at EpicenterBitcom. And we will send you a free t-shirt. That's right. new t-shirts have just been made in Switzerland by Brian.

And of course, you can always send us a tip, and the link to our tipping address will be in the show description. So thanks again, and we look forward to being back next week.