The Blockchain Debate Podcast

Discussion: Baseline ("Permission-less Chain" for enterprise) vs. Corda ("Permissioned Chain" for enterprise) (John Wolpert vs. Richard Brown)

April 19, 2020 Richard Yan, John Wolpert, Richard Brown Episode 8
The Blockchain Debate Podcast
Discussion: Baseline ("Permission-less Chain" for enterprise) vs. Corda ("Permissioned Chain" for enterprise) (John Wolpert vs. Richard Brown)
Show Notes Transcript

Guests:

John Wolpert (@jwolpert)
Richard Brown (@gendal)

Host:

Richard Yan (@gentso09)

Today’s session is about enterprise blockchain and features a co-founder of Baseline protocol and CTO of R3. The former is building an enterprise solution on a public blockchain, whereas the latter is doing so on a private blockchain. So you will learn about the two approaches as the two guests compare notes on their respective products. And today’s format is more of a discussion rather than a debate. It is an update to a debate that took place between them a year ago.

To derive the most value from today’s discussion, some familiarity with the state of enterprise blockchains is necessary. If you’re new to enterprise blockchain, it’s probably best to check out that previous debate first. It was hosted on another podcast called Insureblocks. Just google “insureblocks enterprise blockchain debate” and you will find that episode. The relevant link will also be in the show notes.

Note that this episode's format will be a little bit different than usual. This will be a follow-up conversation to the previous debate, even though you will still hear plenty of disagreement from our guests.

Also, be sure to check out our previous episodes too, on Bitcoin’s store of value status, tokenization and smart contracts, DeFi, bitcoin halvening, China’s future in blockchain, POW vs POS, and oligopoly vs multiplicity of public blockchains.

If you would like to debate or want to nominate someone, please DM me at @blockdebate on Twitter.

Please note that nothing in our podcast should be construed as financial advice.


Source of select items discussed in the debate:

Richard Yan:

Welcome to another episode of The Blockchain Debate Podcast, where consensus is optional, but proof of thought is required. I'm your host, Richard Yan. Today's session is about enterprise blockchain and our guests are co-founder of Baseline protocol and CTO of R3. The former is building an enterprise solution on a public blockchain, whereas the latter is doing so on a private blockchain. So you'll learn about the two approaches as the two guests compare notes on their respective products. And today's format is more of a discussion rather than a debate. It is an update to an old debate that took place between them a year ago to derive the most value from today's discussion. Some familiarity with the state of enterprise blockchain is necessary. If you're new to enterprise blockchain, it's probably best to check out that previous debate first. It was hosted on another podcast called InsureBlocks. Just Google InsureBlocks enterprise blockchain debate, and you will find that episode. The relevant link will also be in the show notes. Also, be sure to check out our previous episodes on Bitcoin's store of value status, tokenization and smart contracts, DeFi, Bitcoin havening, China's future in blockchain, POW versus POS, and oligopoly versus multiplicity of public blockchains. If you would like to debate or want to nominate someone, please DM me at@blockdebate on Twitter. Please note that nothing in our podcast should be construed as financial advice. I hope you'll enjoy listening to this debate. Here we go! Welcome to the debate! Consensus optional, proof of thought required. I'm your host Richard Yan. Today's topic is related to enterprise blockchain, but the format will be a little bit different. This will be a reunion of two industry practitioners that had a debate on approaches to enterprise blockchain almost exactly a year ago on a different podcast in short blocks, a program dedicated to blockchain use cases in the insurance industry. The debate topic back then was public versus private blockchain. In today's episode, we'll have the two debaters summarize their previous conversation and discuss evolution in their thinking. Since then, we'll also have them highlight convergence and divergence in their new approaches and challenge the designs and philosophies of each other's respective enterprise blockchain projects. To my metaphorical left is John Wolpert. John is group executive of enterprise maintenance at Consensys and his work includes the newly released Baseline protocol, a joint effort among EY, Microsoft, Consensys and dozens of other companies. The protocol is a new set of tools for deploying procurement and business processes on Ethereum. Prior to consensus, John was a founder of Hyperledger Fabric project and also IBM blockchain. Previously. He also started Flywheel, the original taxi ride hailing service. He maintains a Medium account where he writes informative articles on blockchain in his unique sense of humor. He advocates for the standardization of an always on state machine for the internet, maintained as a public good, the Main Net, and while he currently believes that Ethereum, and ETH2 is a good candidate for that, he says what matters is the specification. To my metaphorical right Is Richard Brown. Richard is chief technology officer at R3, an enterprise software company that builds the open source Corda the platform, an enterprise blockchain originally focused on applications and finance, but has since broadened its mandate to all enterprise use cases. R3 works with hundreds of banks, technology firms, regulators, trade associations and professional services firms. Previously, Richard was executive architect for IBM spanking and financial markets business in the UK. He supports a permission approach in developing enterprise blockchains. Gentlemen, I'm excited to have you join the show. Welcome.

John Wolpert:

Good to be here. Thanks Richard.

Richard Brown:

Hello.

Richard Yan:

Okay, great. Okay, so today's programming consists of three parts. The first part is a summary of the previous debate. I would love to learn about the main points of disagreement. We'll have John go first, followed by Richard. The second part is a brain dump of the respective systems John and Richard's teams have been building. This will also be an opportunity for John and Richard to briefly describe how their thinking has evolved since the last debate and the third part, perhaps the meatiest segment will be a quote unquote cross-examination between John and Richard as they direct questions toward their opponent's system. We'll finish this part with parting thoughts from both parties. Without further ado, let's begin with part one. John, please summarize for us your takeaway from the debate one year ago. What were the key differences in thinking between you two?

John Wolpert:

I should have pulled from the blockchain my memories on what our previous debate was. No, I'm kidding. I mean, I think that it was sort of the tag end of the five years of private versus public thinking, right? Which I think we both... Certainly I remember making the point that I don't want to talk about private versus public anymore. Versus, the word versus, is the problem with that statement, right? For me, it's horses for courses, or a right tool for the right job, and I think that's probably your point of view too, right?

Richard Brown:

Yeah. I mean, it's interesting and maybe this also answers part of the second question, which is how my thinking has evolved. So the debate last year, it was pitched as private versus public. And I've since come to realize that the pitch, the debate should have been, and this isn't what we're going to spend our time today, but the debate should have been permissioned versus permissionless. And I've been guilty of conflating those two and I certainly conflated them in that podcast. And I think it was probably unhelpful because the, suddenly the argument I was trying to make was that, and it's quite, it's quite a subtle argument, but I think it kind of gets to the heart of some of the disagreements that different groups have, is that permissionless-ness is a very specific technical term, and this is my interpretation of it. And it's all to do with who is allowed to validate and confirm transactions specifically who can confirm transactions. And the need for permissionless, at least in my interpretation, comes from the need in some networks, the public, if you like. But in reality the permissionless network comes from their desire or requirements for censorship resistance. So the argument I was trying to layout was, if you have the requirement for an unstoppable world computer, or transactions that cannot be blocked by any given entity, such as essentially you know, the public Ethereum use case, and the Bitcoin use case, then you can't have identifiable validators or the confirmers with those transactions. Because if you do, the feds could shut them down. If you know who they are, you can close them down; and therefore you have censorship resistance as your goal, you can't have an identified confirmer set, which therefore means the set has to consist of people who come and go at will, therefore there can't be permissioning, because if you were permissioning who could come and go, you could be shut down. And therefore censorship resistance implies permissionless-ness. And the argument I was making, based on I guess, evidence in one regard, and prediction and the other, was that if you could have permissionless-ness in a cost-free manner, why wouldn't you want it. Because you can always layer censorship on top if you need to. But the reality right now is permissionless-ness also implies probabilistic finality, which therefore means that you end up in this world where two nice things you want- censorship resistance and transactional finality can't exist in the same world, so you have to choose. My point was to the extent that analysis is correct and I think some people disagree with me that it is. But to the extent it is correct, it's like you can have censorship resistance or you can have transaction finality. Pick one. That was the argument I was trying to make last year, although perhaps less successfully.

John Wolpert:

No, I think that's well said. In fact, I think that's why I have a hard time imagining what we talk about Richard as a debate because within a certain context, I can't disagree with anything you said within the context of a requirement that says, I don't want any chance of a group or an individual or a group of parties taking over a state machine causing me to not be able to do valid transactions or changing history. Some people pack that up and call it decentralization. Also conflated with permissionless-ness you give up a lot for that and we both agree it. Yeah, you give up a lot. So you better have a pretty good reason for using that particular tool. And for a lot of things that you care about today parochially within the frame of reference of companies that you serve, it would be very valid to questioning utility of that over the things you give up to get it right. So, I mean, how could I disagree with that? It would make no sense within that context. We agree.

Richard Brown:

Yeah, I think so. Yep. Keep going.

John Wolpert:

No, there was no trap there. I mean, you know, I spent a lot of time listening to you and thinking about, I am in some ways a creature of your thinking from five years ago. I've just taken a different path along that circuit, right? We built Fabric because we didn't want to deal with a lot of the things that public networks had issues with at that time. And I remember being focused a lot on not just privacy, the confidentiality, and I might even go so far as to say stealthiness. In other words, and this is not solved in any private or permissioned blockchain to my satisfaction either. I often say, and I'll say it again, even though people have said to stop saying that, I'm going to say it'cause I love it. It's an apt metaphor, I think to say all blockchains, if they deserve the name, are digital nudist colonies, you can have a Fabric channel that you've pushed the digital nudist colony down into a smaller private beach. So private blockchain or permissioned blockchain, or public blockchain are simply distinguished by who gets on the beach. But if you're on the beach, you get to see everybody in their birthday clothes. And if you want to use cryptography to deal with that, it's kind of like wearing a Speedo to Burning Man. Right. You know, you're not leaving a lot to the imagination. I can do a lot of, I can point an AI at that ledger, private or public permission or permission list if I have access to it, I can do an analysis on that set forever and if I can mine out some classifiers. Imagine if you have a supply chain network with companies that maybe start out as partners, but they were always really competitors too. You're giving away a lot of information unless the information might as well be public, at which point I have to ask: Put it behind an API and make it public. Right? Why go through the complexity and expensive of private blockchain in that situation? So we want confidentiality, we want stealthiness. I don't want to give away anything to any other counterparty that they shouldn't know about for that particular workflow step. I'm a shipper of a product that I also compete with. You can think of some shippers that have that property. It wouldn't it be nice if I couldn't know anything about my competitor, even though I'm delivering their product, but their competitor needs to have my delivery date in order for them to calculate the invoice. Right. Well, how would we do that in such a way that everyone can be sure the workflow has integrity but parties don't know about anything beyond their own parochial step. So that's what I've been thinking about a lot. The first attempt at that was Fabric channels. You guys went a long way and maybe a better way with Corda. And I think that's one of the strengths of Corda is the compartmentalization. Well, why don't I stop talking? Could you describe that with Corda?

Richard Brown:

Yeah. Thank you. You're talking about the digital nudist colony. Yeah. One aspect of that didn't always resonate with me though, because I got into a terrible mess two or three ago. This tweet that went out from a meetup we ran where, we were trying to make a point to developers that one of the reasons Corda works the way it does, or one of the reasons we're able to make the claims we do, is because we don't have a single chain of blocks. We confirm transactions real time and the data just goes to those who need to have it. So that was summarized on charters, you know, and...

John Wolpert:

In a very high level, that's, that was the channel framework for Fabric. I think I've come to the point, and I don't want to make my friends over at Fabric angry, but honestly I would be less than candid to say otherwise. I think that Corda is model for handling that kind of compartmentalization is admirable. I think it's quite good. You're not just pushing the problem down and then you have to deal with the same problem. You have two channels, two different state machines, and I've got to pass a parameter from function on this one to a parameter on a function. On this one, I'm back to the same problem I had before. Right?

Richard Brown:

I mean I felt a little bit guilty because people build things. It's hard. It's a labor of love. You bring it to market. And I still remember the blog post I wrote, where I tried to, clearly it was a competitive situation and I was making the case for Corda. So I wrote a blog post that likened Fabric channels to channels on Slack, chat rooms on Slack. And I've had that characterization play back to me so many times that, you know, I know it resonated and it must've been highly annoying for the IBM team. I think there was something to it because my problem always with Fabric was it started with the assumption of"everybody visible to everybody" blockchain and then iterated from there. Whereas in Corda we were trying to solve a different problem, but we went the other way. But back to the digital nudist colony, the reason that never resonated, of course was we never started with the perspective of ever that you received a copy. And then we try and...

John Wolpert:

and that's why I liked it better. When you controversially said five years ago, the Corda is not a blockchain. I quite agree with that. It's not, it's more of a persistent messaging protocol and highly useful in that regard except for marketing. I don't know why one needs to even call it a blockchain.

Richard Brown:

But it's, it's interesting. We've had this debate internally and this is why I'm not allowed to name things anymore. I called, consensus layer, I called notaries and everybody in continental Europe thinks notaries that they are, they are legally protected term. The whole,[inaudible] for blockchain. And not that. I'm just not allowed to name these things anymore. But the point that I was making now is, we Corda confirm transactions in real times. Like there's millions of blocks, you know, there's a chain of transactions for each individual piece of business. But the question we have to ask ourselves is, are we in the blockchain market category? If people are looking for solutions for automating business processes between firms, with consensus, integrity, determinism, all the things that you expect from a blockchain, is Corda in that category? But of course it is.

John Wolpert:

Well, maybe what we should say is that blockchain is in a category and Corda is in a category and we should name the category, like B2B workflows or something like that.

Richard Brown:

Yeah. Quite, quite possibly. Quite possibly. Yeah. So, so one of the things Richard, you asked about knew how our thinking had moved on since last year. And my thinking, there's one thing that I know we didn't prepare for this, but it just triggered a thought. I've made this mistake of conflating the public private discussion with the one, the thing that helped me see that was the backend of last year, and it was from a group called Alastria who are a consortium in Spain, I think, building in the Ethereum ecosystem. And there you got a piece out too. It was initially, I think it was to a small group, and then I think their CTO published it. And they said, we are a public permissioned network. And I looked at that and thought, you guys are nuts, you know, that doesn't make any sense at all. And then I read the definition and realized that's exactly right, so that's what we're trying to build with Corda. It's what we have built with Corda network. And the reason they defined it verse was it's permissioned in the sense that the people on that network, it's just as the people on Corda network who are providing confirmation services are known. You know who they are. If they screw up, you know who to sue. But anybody, any firm, public in other words, can be on the network. It's this hybrid, where anybody can use it, but the people who provide the confirmation services are known and restricted public permission and I thought, yes, Alastria you've got it. Right. That's what I'm feeling.

John Wolpert:

If I may, the flip side, I've been noticing, I can't remember the name of the company that's been talking about this, but the idea of permissioned public, I had to scratch my head because I'm like, well, I think what you just described is a system of record that has a public API for use, but you still have the same problem. You basically have a private blockchain or private state machine or a permissioned private state machine. Those who get to maintain the integrity of the system are the only difference between them and say an SAP system would be, that's a plural group rather than a singular group that's maintaining the integrity of it. You don't really need to use blockchain for that. Of course we know.

Richard Brown:

I'm not convinced I agree with that.'Cause you talk about integrity, you have to unpack that. So there's integrity meaning is this transaction valid? Is it, is it a valid successor to the transactions it consumes? Has it been correctly signed by the right parties to the contracts run? Do they verify it? Has it been mutated? All those things are questions that the participants can answer for themselves and do one thing you cannot do in a sort of bilateral arrangement or a group of people. The one thing you can't do without reference to some other party is know which order did these things happen in, because you know I could cheat, I can give an ordering that suits me. You could cheat and give an order that suits you. So we have to agree, you know, what would we rely on for the ordering? And we could rely on a set of proof of work miners, we will all agree on what ordering they've chosen, but they can change their minds, and hence their lack of finality. Or we could say, you know what, these nine firms over here, who've got no skin in the game, there's no incentive to change the ordering... oh, by the way, if they do, we know who they are. But it would require more than a third of them to get it wrong. You know, that's pretty useful and pretty powerful cause the only thing we're asking them to do is the one thing we can't do collectively, which is give us a canonical ordering.

John Wolpert:

You know, this is a slight digression. I was talking about Ethereum with Brian Behlendorf. I think, quite public and intelligently said, hey, I'm one of the original Apache guys, of course I believe in a public good systems, I just would like to see things like Ethereum and be even more decentralized. He's like, Hey, you know, that's great, but I'm worried about whether or not Dr Evil can get get their hooks into the system and cause mayhem. And that got into my head, I think it was a year later, it started spinning up this story and now people are actually building this where you have mining pools and ultimately again with the two staking pools where you would have instant finality or deterministic finality. So Brian said this thing and I said, what if up to 49% of the Main Net like Ethereum were maintained by known, self-identified miners and ultimately stakers. And the rest are unidentifiable, pseudo-anonymous parties. What you get then is a lot less worry. If I'm a CSO at a company, I worry a lot less about Dr Evil taking over the network. But I also can't sue the ones I know about. It'd be like suing the internet if I don't like an ordering. Whereas if four to 12 or maybe 20 even a hundred companies, knowable companies are running the ordering service and I don't like the way, you know, Hey look, if you give me and Richard both$1 million at the same time and you only had$600,000, a million dollars, even, it kind of matters who got it first, right? I might not like that ordering and I might be in a litigious mood and try to sue those a hundred companies. I can sue a hundred companies just fine, but how would it be interesting case law to see somebody try to sue them, the knowable miners or stakers given that they are not actually responsible for the ordering entirely.

Richard Brown:

That's fair. I mean, a thought experiment I've often done: Let's assume a, you know, a high profile individual bank issued a very high value token onto Ethereum works with the Corda network or whatever it would be. Who would they allow to confirm transactions? They've notarized, confirmed the spend of their money because you could argue, well if you happen to receive a double-spent coin, sucks to be you. But just for pure reputational reasons, let alone any laws that apply. The issuer of that cash has a very strong incentive to ensure that they, that their liability side of their balance sheet hasn't been inappropriately inflated because, sort of double-spend happened on some ledger. You follow the logic down. I see only two stable outcomes. One is they have to be the confirmer of their transaction spending their cash, or a set of identified parties known to, and approved by them, or a system that they know for sure cannot be subverted. And if one of those things existed, we'd all be biased. I think that was actually the end of the podcast last year. You know where we ended and agreed was if the, well one of those things, I would be a buyer of it. I'm not building consensus layers for the fun of it. I'm building it because what currently exists won't do what I need.

John Wolpert:

Our roles have always been that way. You're working on what needs to be done today. And I've always working on what needs to be done within the 18 months. And, but the thing is, I think now what we can talk about is 18 months is here roughly and now there is a today thing that we can about and argue about. By the way, the punchline of that thing with Brian Behlendorf was I told a few mutual friends of ours, Richard, about this. And they're like, yes, but, and I'm like, no, I know what your" but" is. Our corporate treasury department won't let us hold crypto. And they're like, yes. And I said, right, so what you're going to do is mine and stake, and give the proceeds to charity and lights went on. And they're like, Oh my gosh, that's a great idea. These are guys that are corporately disinclined to touch crypto with a 10 foot pole. But yeah, if we took that off the table and said, yeah, you're not going to hold it, you're going to give it to charity. And then a year from now when your corporate treasury realizes how much money you're giving away, you're going to get really okay with crypto.

Richard Brown:

That's the way we should go. Well, and then we, and we should go onto Baseline cause I'd love to hear your pitch. I'll have a debate about it, and contrast that with what we have done and what we might be doing in Corda. But just on that corporate treasury one, another thing that I think about intimately, not a lot is Byzantine fault tolerance. Regardless whether it's staking Ethereum 2.0, Whether it's traditional BFT, all these algorithms, that they're all based on this idea that, okay if you ask one entity to confirm transactions, it would provide an ordering. You know what happens when they go bad? So all of this space is, what happens if you get a collection of them either a known set, so back in the permission world, or an unknown set, so as in the permissionless world and, and we make some assumptions about how many of them are bad. Is it one third in classical BFT? People thought it was less than 50% in the permissionless world. I'm considering these papers. You know the Cornell guys' papers on selfish-mining show it's probably one third. So you end up at this thing that provided no more than one in three are bad, you're okay. So the question I always ask myself is what about the marginal miner, the marginal confirmer? So the network has got to the point where actually the safety margin is almost gone. So almost one third they've gone bad or they'd been hacked or whatever, and there's just one left. This is the difference between the network meeting its promises and not. And then that one flips from good to bad. And we know it was that one that flipped. My suspicion is that guy gets sued.

John Wolpert:

It's very possible. So you've been in my head about this stuff and I think it's fair to say that the Baseline protocol, there's a little bit of unit not to pander, but I believe that's true. And here's why. So the concern, the Main Net has a problem. It's a digital nudist colonies. It's a public beach, right? It's not as some private beach that you can lock the doors on. I still don't like that. Right. Because that means the stupidest admin in your private permission group can make you all by getting hacked by Mr. Robot, right. Because they have a full copy of the ledger and they're maintaining the integrity of ledger along with everybody else...

Richard Brown:

Which for listeners' benefit, is a critique of Fabric, not of Corda. Yeah.

John Wolpert:

Yeah. That is true. Corda has a different model for that. Although we could argue that I could learn a lot by mining if I was a notary by mining the activities. I'm a notary, especially because it's smaller groups, tractable numbers. So you can do a lot of sparse data analysis. You know, you could learn some things. You might not learn the actual data, but you might learn cadences, you might learn things that you shouldn't know. So having come from Watson before, as you know, I keep on thinking about that. I'm like, Hey, we've got a public ledger that anybody forever can mine for analytics as long as they want with whatever computer they have, when quantum computing comes in and they can do it with it. So its use as a place you put data or run business logic, unique business logic, right? I think Z-cash and that sort of thing... There's only one piece of business logic. Alice gave Bob 50 which turns into somebody gave somebody something and as long as you put some chaff in there, it sounds like a metronome. It looks like noise. Something happened, something happened, something happened. It's all the same thing. So you have this endless sameness. So you really do have very little for analytics package to grab onto and start to generate classifiers on, for example. But in Ethereum or in a business logic situation, you could write a smart contract with a lot of attributes and if I can mine those attributes out. So it's not just about the private hiding the transaction attributes like Alice, Bob and 50 but" gives" becomes important because it might have a unique identifier like, Oh there's clearly a discount function in this business logic and now we're running that on chain, so I didn't even like that idea. I would call that confidentiality, so confidentiality is how you hide the business logic and privacy is how you hide the transactions, but the whole mental model for everything private and public has been the crud layer. Thinking of blockchains as the CRUD layer, the Create, Read, et cetera( Create, Read, Update and Delete) without the D-- the CRU layer. But what if you turn it upside down and said, no, it's not where we do any of that. It's the middleware that makes sure that the record I have in my SAP system, and the record you have in your Oracle app system and your JD Edwards system, is identical. And that the business logic that transforms it or that creates new records from it, where the original record is an input with those business rules, all of that stuff being done completely in traditional systems of record, that the MainNet is simply a consistency machine. It's a two state machine, you're consistent or you are not consistent. If you wash away a lot of other things, that mental model, which is sort of a baseline, baselining... Baseline is not a platform, not a product. Never will be something like Fabric. It's not a Corda, it is not going to be a product. It's not a coin scheme token, nothing. It is simply a way of using state machines in a pattern that allows you to have the last silo of consistency machine. So you and I know from the enterprise world that we've lived in before. What do you have to do when you set up company A's or even in one company, you have a state machine here, you have another state machine here they need to work together without running a muck. You have to either primary one so you have a common frame of reference or you have to put something in the middle that runs as an umpire. So the whole idea of baselining is simply to say you've got messaging, digital signatures, hashing and a little bit of really boringly used ZK and a MainNet, which could be a private blockchain, but then you've created a new silo that you will ultimately need to re silo with another silo, which will ultimately be another silo. And finally you need a MainNet. Well, you could argue that we don't need a MainNet. I'm going to argue that I see a future where it's quite nice to have a final state machine that is the arbiter of consistency for other state machines. Anything below that is a silo.

Richard Brown:

Thank you. I hadn't had it described that way. So that really helped.

John Wolpert:

That eliminates the worry about custodianship. Even the question of finality becomes eliminated because our message that we pass between us directly, maybe by a Corda Flow. This is why I was saying before the recording, that maybe Corda Flows would be a good model for the messaging layer of a MainNet. I'm not worried about finality there because we've made that message happen off chain directly within traditional limits and parameters and systems. So we know how to get deterministic finality there and all we now need to know is that we have a proof that we achieve consistency and that can happen with a good deal of flexibility on latency and processing time and that sort of thing. Do you see where I'm going?

Richard Brown:

I do. The bit I don't get... Two bits. One is an observation, and the second one is the question is that I've heard, Paul Brody... he's amazing... He used to work at IBM. We never worked together, but when he was driving the adept project it was, it was inspiring. But he talks a lot about ZK. You deemphasize it to some extent. So I'm never quite sure what, it seems that you, you each present the need for zero-knowledge-proofs differently.

John Wolpert:

That's a fair comment. I don't think that either one is wrong. I've been on this thing to say, look, I had some role in hyping this blockchain thing and I feel bad about it. So I like to say, actually I got tagged on this the other day. Somebody said, stop saying boring. And I'm like, no, no, I'm not going to stop saying boring. The whole point is that we've got to get to a point. Yeah, after five years of pipe boring is exciting. I want a repeatable, boring use of ZK. And then by the way, a really cool opportunity with the research that E&Y has done that brought to the table is to say, look, I can do a boring consistency machine and run that through the same Zoc circuit or the same DSL over and over and over again. Just basically says, I don't know what you did, but you did it the same. I don't know what you did, but you did it the same. And then you deposit that on the MainNet. And again, it has that sameness thing. Nothing looks different from anything else. So there's nothing for an AI to grab onto. So I don't have any leakage of data. I can even tokenize that Baseline token within a shield contract. I can tokenize it, I can pass it to you. The only two parties that will ever know that that was even a thing as you and me, which is great. So it has a lot of nice attributes. It also means that almost everything is happening is off chain. But you can then say, well now that we have this repeatable thing, I can also then decide as say a standards body, right? Like FRTB is a good example of this. I can say, look, if you want to be in compliance with regulation, without me doing a colonoscopy on you as a regulator, run it through this customized Socrates set of circuits. And I know that your transactions with your counterparties were done in compliance with the regs. Yeah. And so far as that's possible, some regs are like, don't be stupid on TV. Right? You can't fix that one.

Richard Brown:

Yeah. Okay. Here's probably, might be my key question or might, key thing. I don't get. Actually maybe I'll start by showing the listeners the Corda Flow framework, and the problem I think we're fixing there. And then the question or point I wanted to make. So Corda open source blockchain that is used in a permissioned context, but there is Corda network, which is, and that's right, a public permissioned network. So any legal entity can join this. And just so people understand that you run by an independent, not for profit foundation in the Netherlands. And the governing documents say this thing is basically run on a cost-recovery basis. So the more people who join the lower the costs, it's open to any company because Corda is designed to facilitate transactions between firms. Any company can join, apart from ones that are illegal for the foundation to serve, which means you have to be on a sanctions list in the EU or the US. Anyone who is not prohibited by law can join this network. So public, but the confirmation services are provided by identifiable parties. Hence permissioned. Because that's what we do. I've read all three in the Corda ecosystem, but when we were designing Corda, that was all in the future. What we thought we were building was a system that allowed people to write applications that allow participants in the market to form and maintain consensus about agreements that exist between them. So that's quite abstract, but it could be insurance companies trying to record the existence of an insurance contract. You could be a borrower and a lender. You want to have a loan. You record the fact that it exists. I have a copy, you have a copy, and then we set some rules. The small contract, that governs how it evolves over time. We were heavily inspired by previous platforms. What we realized, this was also influenced, it was Mike Hern,[inaudible] engineer who had a lot of experience from the Bitcoin community. What he'd spotted was a lot of people in Bitcoin, someone's buying something, you have to construct a transaction and often it's a multi-party signature or it's a transaction that multiple different people have to sign for different reasons. And what he found was people, again and again we're writing these out of band communication protocols to move these partially signed transactions around and agree which inputs are getting put into them. To use this transactional network, you had to have this overlay network which needed an identity layer to actually move stuff around. So he realized recorded to have any chance of success, we have to build this into the platform. So that led to a sort of set of requirements to said, well given that this system is for recording contracts between new identifiable parties, we had an identity layer. So there's every actor on the Corda network has an identity. So you know who you're talking to. There needs to be a way to get messages to people. So there's a point to point framework based on asynchronous messaging, MQ, that kind of thing. But then if you receive a message, what do you suppose to do with it? You know, if I send a message to you saying, you know, here's an update to your loan, how do you know what to do? You know computers are stupid. So then you can send an email to someone and they figure out what to do. A computer has to be told so than just sending the data to the side. We pre-agreed, you know what business logic will run. So you end up with this decentralized workflow engine, new identity messaging, decentralized workflow, and it was all there in the early days just to make it easier to negotiate the thing that we actually cared about, which was an update to the ledger. So there was the flow framework to negotiate the updates. And then finally you said, yes, this is the transaction we're going to do. I sign it, you sign it. And then we committed. And that's what goes on the ledger. So everything in the float,

John Wolpert:

What I like about the Corda Flows is you can send a message directly to just one other party. Nobody in the middle got any kind of data, even in an encrypted form, right? So you have a nice GDPR compliance thing there. As long as the two parties on the end of that are GDPR compliant. But what about the code? We've been calling it a code book, right? The package. Do they send that in some particular format? How do you send the business logic?

Richard Brown:

So there's two pieces. So firstly, the other thing to point out is when we design Corda, we kind of said, well this is massively successful or it's nothing, I know it's going to be massively successful. It has to be accessible to the world, see a huge numbers of developers. So we picked a community and we went with the Java community. So Corda runs on the JVM, 12 million Java developers in the world so they can write these applications.

John Wolpert:

So I'm sending a Java package.

Richard Brown:

Almost. Because the assumption for the negotiation is, we both already got the application installed and I've integrated my system with, to use your example, I've been, I've integrated my system with SAP. You've integrated yours with, I don't know, your Microsoft dynamics. We've chosen to participate in this workload. We've chosen to do the integration and therefore we've also installed...

John Wolpert:

Oh, so you, so you have to set up the all of the business logic for some kind of relationship in advance.

Richard Brown:

Not all of it. So I am not going to execute code that just arrives over the internet. It's there to negotiate a deal. I'm going to do, you know, that's probably code that I've subclass and specialized to reflect my unique business circumstances. So clearly I have chosen to execute that and allow it to be invoked by people over the network.

John Wolpert:

During the setup phase though, you've got to send a jar file or something, right?

Richard Brown:

Yeah, we could, we can agree amongst ourselves. You know, what business are we trying to transact? Yeah, absolutely. And ultimate a jar file. Yeah, yeah, yeah. So there's this setup, you know, we're communicating with each other and computers and negotiating with each other. And the idea was, and this is what I'm going to get to my question, the idea was with the Flow framework was, the end result of this would always be a transaction. We can sign, get committed to the ledger, that is the loan and now it evolves. Now that has code attached to it which travels with it on the ledger, cause maybe I then sell the loan to somebody else. The loan is used as collateral for something else that party downstream. They may not be using our workflow application. They don't care about how we negotiated the loan, they just care that a loan, that is a type of asset, that is available. But the code that constrains its evolution is called a contract code. You know, that travels with it. That's like a small contract on the Ethereum network. But as I was looking at the Baseline docs, what struck me was, because this is our experience with Corda, I'm seeing a huge number of people using the Flow framework for its own use. Corda identity framework, the messaging and the workflow that's valuable to them itself. So some of these do not end up in transactions committed to the ledger. What I don't get in the positioning of your Baseline, is one, why it's tied to Ethereum, you know, ethereum- oasis or whatever, because it seems the concept transcends that. And why always tying it to the Ethereum public network Main Net, because I suspect a huge number of the use cases you could discover don't need that. So it kind of feels like it's been jammed in where it doesn't need to.

John Wolpert:

I can see how you could read it that way. So let me unpack that. First of all, the Baseline protocol is it's not blockchain agnostic, it's use agnostic in that it's a generalized pattern. It's a design pattern. I'm going to try to keep it to that. I know that, Fabric became a platform and became something people were really, this should stay as primarily as a spec, with some reference code. Things to make it easy for your company to baseline your product. Right? So you could be SAP or Salesforce or somebody and just become Baseline enabled. And yeah, we're trying to make baselining a thing. But as you say, you could use a private blockchain as the MainNet for a common frame of reference, but we agree, right? You have to have a common frame of reference. Otherwise you have a mess.

Richard Brown:

Maybe I don't agree though, cause the workflow piece, back again, to why you have miners in Bitcoin, why'd you have notaries in Corda. When you really net it down, it's for transaction ordering. In the case where a commit to the ledger has happened...

John Wolpert:

it's more about timing. And this is a classic distributed systems problem, and you do have an issue there that you have to have a common frame of reference. Again, you either have to, we used to call it, right, mastering one to the other, or you have to have that common frame. And especially in workflows...

Richard Brown:

But that's what I don't get though because...

John Wolpert:

Maybe I'll give you an example. I'll give you an example. If we have a master service agreement that says I will agree to this rate table for purchase orders. If I get over a hundred units in this particular timeframe, I get 10% off everything over a hundred. Now two PO's come in at the same time trying to calculate from a base of zero, cause that's the starting point. That's why revenue recognition becomes a problem in traditional systems, right? Today even good ones have this issue, and that's why you have to wait for clearing after the invoicing.

Richard Brown:

Ok I think we are using different terms. That thing you've just given, you started with a setup, which was this thing exists...

John Wolpert:

Yeah, I need to lock up that state right now. I don't want to go to locking, because anybody who knows distributed system says, stay away from that stuff. But you do need a sense of temporal relations, right? You need to be able to say, okay, I've got these two things. One's going to fail and one's going to have to calculate from the next level.

Richard Brown:

No, totally. But that is what the blockchain is for. So to play it back, to make sure I've understood what you said. So you've got this agreement between, I say just between you and me, that says if we do a hundred pieces of business with each other, then some discount kicks in or whatever it is. That is an agreement we have negotiated. So if the input is something else, but it's also the conclusion to a previous thing. So there's a negotiation, concluded there, and said we agree to be bound by that. Signed by Richard, signed by John, committed to the ledger. It exists. So it exists on the ledger.

John Wolpert:

And when you try and do that between traditional systems, right, and we deliberately went to traditional systems of records so that we could get out of the whole blockchain inter-op conversation, right. Blockchains are also state machines. So you can use the method for blockchains too. But we're like, no, let's talk about DB2 and Oracle, and the stuff that you and I grew up on. Right? And say, let's worry about how do I make sure that my record and my table here and your record and your table there are verifiably the same and that we get out of not the Byzantine General's problem. That's for another part of the problem. The two generals problem. I'm going to send you a message, then you're going to send me a message that you got the message, then I'm going to send you a message that I got your message that you got my message, and so on. Well now we can say, Oh no, we're going to look at this common spot that is also tamper resistant and say, ah, the circuit has been completed. We both know without repudiation, that we have both done the job, which is a big... Non-repudiation, a boring problem, trillion dollar problem.

Richard Brown:

But I think you need one more thing on top of that, cause just take that example of we just want to get to a point where you and I agree. We've moved on the deal. So problem is as simple as we just want to both know that the agreement exists because he's actually going to then be just managed physically by two lawyers. You're right. Yeah, I sent it. Did you get it? Did you get the fact that I... I agree there's that problem, but yeah...

John Wolpert:

That's classic problem and it's actually, it's an unsolvable problem.

Richard Brown:

It is, but the assumption is we are not fully trusting, but we trust each other enough to want to do a deal together. We're not actively malicious.

John Wolpert:

Yeah, but if I can say, look, there's this thing that's always on, I can't lock me out. It's just they're running right for its own reasons. Right. And that has to do with tokens and all those things that again, I don't care about you and I have less of an interest in. Those are all valid things. I'm not going to talk about whether they're good or bad. There's simply not in my interest set for me. I'm saying, Hey, that's a state machine I can use that's conveniently always on. It's always there and it can't lock me out of balance.

Richard Brown:

I'm trying to think, cause I think, I think there is a need for that. But yeah, my belief is it's somewhat different because I gave this example of we just turned over to negotiate this discount agreement and then once it exists, we never look at it again. Now...

John Wolpert:

No, we do. Right. Because we need to, we need to hold[inaudible] on it.

Richard Brown:

But we build it up. So let's assume I'm not going to, so the objective first is just to make sure we both got a signed copy of it and of course we both...

John Wolpert:

Yeah, that's the, and that's the consistency machine. So I want, so instead of putting, instead of putting that on a Singleton, I'm going to, you're going to have one and I'm going to have one.

Richard Brown:

Yeah, I'll tell you what I think I can do and then you tell me why, where it's wrong. So we negotiated, I've got a copy of your final offer. I look at it. Yeah. I'm happy with that. I sign it. Send it to you. Nothing on the ledger yet.

John Wolpert:

Yeah, we did EDDSA, right. Yeah. So yeah. Yeah.

Richard Brown:

Eventually you sign it, you send it back. And so I've got a copy and I've got a copy of the both signatures and because I've got a copy I know you have, then maybe you don't send it back. So I had to keep trying. But you know, we both want these deals...

John Wolpert:

Which is what Corda Flows is so good at, by the way...

Richard Brown:

So eventually we both have a copy of it now. And that doesn't require Corda notaries. It doesn't require a MainNet. So, but that's fine.

John Wolpert:

That's just digital signatures.

Richard Brown:

Yeah, that's all. That's all Corda Flow is. And that's what Baseline I think can give. And then the question is, but if we want to go further and say, actually this thing we've agreed to, we actually want it to have some embedded rules. We want this thing to, actually there's two things you can do, one is you can say, you know what, we're not going to have any embedded business logic. It will be updatable even when we both sign it. So I've got a copy. You've got a copy. Every so often I send a request to you say, hey, I'd like to do, here's a proof. And if you agree you send it back. That doesn't require MainNet or Corda...

John Wolpert:

No, no. Here's where the Main Net, or a kind of frame of reference. Let's just call it a common frame of reference, the CFR, whatever you use, right. Whether it's private, public, whatever the CFRs job is one, you do want a place that's easy to get to, by everybody for the storage of those signatures and the proofs that follow from them. But what gets interesting is not that you can say that, it's nice to have a common frame of reference so that you always know where to go for your signatures and your proofs. But that's kind of a weak argument, right? So I mean you and I could set up an agreement and run any kind of messaging, including carrier pigeon with digital signatures and be able to be confident that we both have the same thing. That's not a problem. But what you do then is you run it through the zero knowledge service mainly as a way of making noise and you put that into the shield contract and you put this proof in there and we understand that that proof can't be there without us having some things consistently. But then it gets interesting because then you can use that as a state marker and you can use it as an enforcement layer for downstream workflow steps. So now I can say if I want to be a child of that MSA as a PO, I have to not only do my thing and be consistent with the other parties, I have to be in compliance with whatever was laid down by that previous key. And I can't put my Baseline proof as we call it back onto that bucket unless I comply with it correctly and everybody else has to as well. So now what we have is flow control and a way of avoiding deadlocks and other nasty things and a way of being sure that a workflow has integrity. And this is the thing I like about most without silos. So I can say this workflow step, step number two, it turns out years later after we've been doing this for a long time that that ought to be passing a parameter into workflow, step 33 of somebody I've never even knew before was out there, but now we have to do business with our two different workflows. I don't have to call a network administrator to set up some kind of a system with them now or create a new common frame of reference. All of our Baseline proofs are sitting right there and can govern the integration of those workflows and still maintain absolute compartmentalization. So parties involved in step 34 of the newly connected workflow may have no knowledge of or even awareness of the fact that there is another workflow with a different set of parties. On step number three, this is exciting. You've been hearing me talk about the magic bus, the magic bus. The whole idea of that was it. Wouldn't it be nice to have a bulletin board, where at least we can put keys, in a key-value lookup, and maybe even from time to time we can dead drop values like Boolean True. So I have my Baseline proof just to hash, right? That's my key. I could look up on my database what that key refers to and then run the new calculation. If I've changed something about that data in my database that I'm going to fail the proof and now we have to have tools to deal with the failure, which is an issue, but that's the point of it. Or I could dead drop a value like a date or boolean. True. And I've got to think that in a lot of those cases that's going to not provide a lot of of signal for anybody to pick up on it. Especially if you encrypt that just standard encryption that you've got a key and boolean true, right? Or here's a date. You're not really telling anybody anything, but now you've got a dead drop that allows you to go to the next workflow step without the party that had to dead drop that date or that value. Knowing anything about the rest of the workflow. This gives you the kinds of things that we were struggling with five years ago. You can do it on a public or a private common frame of reference or permissioned or a permissionless common frame of reference. To my mind, I like the idea of, if we can make this work on something that is a complete public beach, nudist colony and we can do it in such a way that nobody on that nudist beach sees anything that's really very interesting to about anything else. Then we've eliminated the final silo problem. You could still have any number of silos for lots of reasons because I mean your common frame of reference is tuned to your special business case and I've said before to Richard that I think Corda and the MainNet or whether that's Ethereum or something else in the future. Yeah, I do believe for lots of reasons Ethereum is a pretty good candidate for that. They coexist pretty well. If that becomes a notary of notaries...

Richard Brown:

That's fine. So I think we're agreeing with each other, using different language because the distinction I was trying to make was, negotiation of something that is almost ephemeral, it's transient. There's a process we need to go through to negotiate that discount agreement. The example I like is the option contract. So we negotiate an option contract, with what the strike price is going to be, that requires nobody to be involved. But once the option contract comes to life, there's two things we can do. And that one, is we do the old way, which is stick it in a drawer. And then if I want to exercise, I better hope that you don't play games and refuse to answer the phone just before expiring. There's all I have to deal with. So there's the negotiation of it and then there's, I think that exists. And then, for me, there's almost like a phase change. We say, well, this thing exists. It now moved from the collaborative negotiation phase to a world where we could be adversarial because up to that point, it was mutual agreement. You know, we both signed it. We both agreed the three of us, the five of us, said that's what we're going to be bounded by. Well, we've got a choice at that point. We said, right, anything that happens after that requires complete mutual consent, but that doesn't work in a world of winners and losers. You know the option, there's going to be pay off. Someone's going to be, I think I'm only going to pocket the premium, and we're going to pocket the payoff. So, so should we say at this point, what we've agreed is, this is the statement of our intent. By the way, Richard is the option buyer. You have the unilateral right to exercise this. If you do so with this evidence of a price before this date, and you John, have unilateral right to expire it after this date to be[ inaudible] being exercised.

John Wolpert:

That's standard business logic. Right?

Richard Brown:

Exactly. It's doable. Yeah, but that's what goes onto the ledger because the reason I put it on the ledger isn't because of the shared context or shared frame of reference or... cause I don't quite get that. But what I do get, and this is the Ethereum vision, this is the bit that inspired Corda as well was this is now active. This is a contract with business logic...

John Wolpert:

But it's business logic. Everybody gets to interrogate and that's my problem with it.

Richard Brown:

Oh, that's why I think what you could be sitting on is two separate things. Because you've got the equivalent, it sounds like you're building the... you're putting a spec for the equivalent of Corda Flows, which is a, it's like there's the mutual negotiation. And then there's a completely separate thing, albeit related, but separately, which is once I think exists, there are rules embedded in it, that if I can hit the pinata in that way, this thing will pop out. If you can hit it in that way, that thing pops out...

John Wolpert:

Well, with the Baseline protocol, you could write your business logic in Python. It doesn't matter. Right. And what I like is again, then you optionally can also write as DSL. We used Socrates and maybe that'll be the ultimate thing. You can write a Zocrates circuit to turn that logic into math. And you know what it reminds me of, is a Java interface, right. It's basically saying I'm enforcing a set of conditions on your execution environment. So I'm going to say for example, with the, with the rate table, I'm going to say you can't have any gaps between... now I could just write a Python package, send it to you through the message, right. And we both have to execute that Python package correctly. And that would be a consistency machine. It would still work, but we could have very badly formed Python. Both of us have consistently executed a terribly written business logic, but it would execute consistently with the additional layer of a zero knowledge circuit. You can then enforce some kind of standard on it.

Richard Brown:

Yeah. But what I'm saying is, and maybe I'm, maybe I shouldn't do this because maybe I ended up making your case for you. But I'm saying it feels like you're sitting on two things...

John Wolpert:

Well that would be mutual, cause I'm making the case for Corda, uncomfortably for some of my friends. And they're like, why are you making a case for Corda? I'm like, right tool for the right job. Corda Flows just makes sense. Right? We ought to replace Whisper with Corda Flows. Although I probably just got in trouble for saying that.

Richard Brown:

When I read the Baseline description, it feels like the description conflates both sides of what you're saying cause you're talking about whisper the negotiation and you're talking about once we've created this contract, which is now going to, like, automate our agreement, here's a way to make what it does invisible to anyone. So people could still check that it was executed correctly, but they don't know what it did. The whole sort of cloaking, zero knowledge proof, or...

John Wolpert:

The way we're doing it, you don't even know that there's an'it" there. It looks, you know, an AI would, it would sound like a metronome. Especially if you do it on a cadence, right? It's just tick, tick, tick, nothing there. And also only you and I know that this random bit, this random dot, and this all this randomness. It means something to you and me.

Richard Brown:

Yeah. But the two things you've got are independently valuable. The ability to do that, and the ability to cloak the fact there's an"it," and it's doing something. If that's all you had, that would be useful. And if all you had was, here's a way for different parties to find each other and exchange information in order to make an agreement, that's valuable.

John Wolpert:

Well that's the other thing that you taught us on this, right? I mean there is an org registry and ultimately yes there needs to be an ultimate DID phone book for everybody. So I can look up R3 and know that I'm dealing with R3. Once I have that and if my mixer address in our address for my addresses is verifiable and it's connected also with another attribute, which would be my messaging end point. You know, and I don't have to like as a programmer worry about screwing those two things up so that I think I'm working with you on one thing. And so we need identity and once we have identity, then we can do what you're doing with Corda flows and just go point to point. And I don't have to do things like gossiping and sending my very sensitive data through a whole bunch of people that I can't get control of, which I should think of will always break GDPR. Yes. Yeah. Great. So that's my favorite thing about Corda is, right now, is Flows. I'm really encouraging the community to go look at the open source repo and Corda Flows and learn a thing or two about how you guys did it. I think it's beautiful work. Thank you.

Richard Brown:

Yeah, there's a lot of things I love about the Flow; there might be a lot of things I wish we'd done differently, but I guess that's the same with everything.

Richard Yan:

So John and Richard, sorry to interrupt, I actually have two questions for you and maybe shifting gears a little bit. So question number one is that this common frame of reference that John speaks off, the fact that it's going to be exposed on Ethereum, what are your thoughts regarding the lack of decentralization in terms of either miners or validators, with a large concentration of power within just a few hands? The reason why you want to put certain information on the common frame of reference is, you want good integrity there and then decentralization is key in ensuring that integrity. So I'm curious to hear the thoughts from both of you. And the second question is regarding adoption. So technical details aside, what are you guys seeing in terms of companies adopting either approach or any enterprise blockchain? Is it mostly the CTO is getting excited? Are the business people getting excited? Is there a matter of you paying them to do it or are they paying you, you know, Ripple versus MoneyGram sort of situation?

John Wolpert:

So on the, on the matter of the Main... that I call it a MainNet for a reason, right? I don't want to talk about, yeah, I work on Ethereum a lot, but I want to emphasize that it's the specification that matters. Specification says I want something that is always on, maintained as a public good, that resists being taken over by a group of parties to lock you out from valid activities. I won't say transactions, valid activities and or change history. Now you can conflate that into decentralization, but I think it's important to use those words. That's the specification that matters. And I think that the internet needs a capital, MainNet for the capital I, internet and whatever that is is what we need to, and it's silly to say that we can have a whole bunch of them at the final silo. You need one, not to rule them all, but to serve them all. Otherwise you have balkanization by definition you may want balkanization but that's it. So is Ethereum decentralized enough? No, it's decentralized enough for where we're at today and we should keep on making it more decentralized from that perspective, making it more and more proof against tampering and then having somebody get control of it. If there's another way to do that at that final slow moving last mile of silos, then great, well let's talk about that. But I haven't seen anything like that. And then the other thing I'd like to see is something that has significant critical mass, which means 2015 is an important attribute because that was a critical moment in history to be there. So a lot of great ideas coming out today and I'm like, well, you weren't there in 2015 so you've got an uphill climb for adoption. That doesn't mean it's game over, but it's a significant thing and you also have to stay innovative. A lot of the Coyney type things spend all their time trying to maintain the value of their coin. I think that you can honestly say that the talent and all the team around Ethereum, have remained remarkably innovative and focused on novel approaches in spite of the fact that they do have a token of value. So I think that's the way I would put that

Richard Brown:

decentralization. Um, I guess, what would be the dream. The dream would be, I think essentially ship resistance substrate if it could be achieved, would be amazing because as I say, you can build censorship-nonresistance on top...

John Wolpert:

As long as you use it in the right spot.

Richard Brown:

Yeah. Whereas the opposite isn't true. But for all the reasons we rehearsed earlier, I don't think that's possible right now. Now I hear people say, well, it's okay because one mining isn't centralized, but of course we don't know that there was evidence in other blockchains. Not in Ethereum, but there're other blockchains that it is. And then people say, well, that doesn't matter because, you know, 2.0 is coming along and there's proof of stake. And the stakers. Couple of weeks ago there was another blockchain, and I forget which one it was, where a huge number of the tokens, I think they'd been stayed till being held by exchanges. I forget exactly how it works, but someone effectively either bought all the tokens or borrowed them and was able to, you know, force voted the way that one...

Richard Yan:

Tron's purchase of Steem. I think that's what you're referring to.

John Wolpert:

which is, which is why critical mass is kind of an important thing that's never even come close with Ethereum or Bitcoin.

Richard Brown:

Well yeah, we'll see. We look at things like, you know, what was going on with DAI recently. Just because something's never happened doesn't mean it worked. You have to assume anything that can happen will happen, and it will usually happen in the most stressful or stressed times. So my preference...

John Wolpert:

You mean, like the hundred companies that are maintaining a permissioned ledger all getting together and colluding. I dunno. That could never happen.

Richard Brown:

So I don't know what you're referring to there. Cause Corda Network doesn't work like that. But it's very clearly written into the contracts that underpin these kinds of systems. Or these are the parties that are providing network ordering services. This is the assumption you have to make about how many can go bad, and here's what happens if they do including who they are. So the kind of assumption is, you know, bad things can happen, let's prepare for them rather than claim they can't because they haven't already. So then the question about who's using it. Really good question, cause there is a lot of hype. There's a lot of questionable projects out there. I can only talk about my own. But projects that are close to mind right now and then some of these will seem quite obscure but they're really valuable. There's one called HQLAX. It's a high quality liquid assets exchange, Deutsche Boerse, you know, big market infrastructure has invested in this customer's alive on this transacting large volume collateral financing. I don't quite understand it. I'm not deep finance person. There's B3I, big insurance consortium on Ethereum. John Schocks talks about Congo[ inaudible] to the stuff on them on Fabric. We tried large groups of firms doing real business. Now I would like more of these firms to be doing it on large open shared public networks. If I look at who's using Corda network, many of the most interesting Corda projects are on that open shared public network. But some of them are private other than to move to the um, to the shared network. But it works both ways. Different solutions with different people. But yeah, people are paying money to use these products because they are useful to them.

Richard Yan:

Okay, fantastic. Great. Anything to add there, John? Otherwise we'll move on to the next part.

John Wolpert:

I'll only have one thing which is I like the idea of trading Capex in traditional it, 30% of companies, biggest companies in the world have this real interesting problem. Companies that are counterparties to them, either suppliers or buyers or what have you who have no real system of record or really just don't have the volume to justify setting up something like MQ or or Kafka or what have you. As that shared common frame of reference system and systems integrators have been making a lot of profit for a lot of decades on on just doing that job between say a big company A and B, company B would have got a lot of volume. That's a big problem in that you spend billions of dollars on your traditional system of record to know what you know and you have 30% if you're lucky, if you've actually done a good job with the 60% of big companies with high volumes, you know it, you still have 30% where you don't know what your counterparty knows for sure, and that limits the value of your traditional SCM or ERP system, right. And so it wouldn't be nice if you didn't have to resort to capex to set that up for those small volumes. Especially, you could just say, nope, this is this thing, it's always on and I do have to pay some gas, but you know what? And I don't have a treasury department that's good with gas, so I'll just pay somebody else to pay gas and I'll just pay them in fiat, no big deal, no big whoop. But yeah, gas as a way of dealing with the halting problem only, right? So you're not talking about trading tokens or tokenization or crypto assets for anything. You're just saying I need to pay for the cost of the interrupt function and that cost needs to be paid for in some way. I can pay a party to run it and worry about them going out of business or I could pay this thing in this thing called gas just to deal with that. And if I'm very sophisticated, I realized that the reason that for it is to avoid the halting problem. That's a very boring IT way of looking at the issue. And I think that's nice because now you're talking about opex, which you pay as you go. And I think that's a very useful attribute over time.

Richard Yan:

Okay, guys. Well, thank you guys so much for coming on. If you just want to put in one word, maybe a closing remark, that'd be great.

Richard Brown:

Thank you for having me. I love the conversations with John. I would learn something. It's always a bit of fun having a back and forth, and as we discussed before we started, you know I'm on the Baseline Slack kind of. I'm looking forward to learn.

John Wolpert:

Yeah, everybody get on the Baseline Slack, and get onto the Corda stuff. And somebody figure out how the two things can be knitted together so that we can have win-wins.

Richard Yan:

Sounds great. We look forward to having you come on again maybe in the future to see how your thoughts have been evolving over time. Thank you so much. Take care guys. Thanks again to John and Richard for joining the show. My main takeaways from this episode are the following. First, Corda is not really a blockchain because there's no chain of blocks. Finality of transactions is provided by these entities called notaries. There isn't some kind of economic model that incentivizes keeping records on the longest chain. Second, in evaluating B2B system integration solutions. The advantage of a Baseline/Ethereum approach is that there is a common frame of reference maintained as a public good where companies can feel free to leave data there, encrypted or otherwise knowing that the data is incorruptible by anyone. This sort of guarantee isn't provided by Corda. Third, Corda's counter argument against point two is that the notaries are identifiable parties held accountable for tampering. Richard Brown calls this a public, permissioned network, because anyone can become a node, but selected few public identifiable entities serve as the notaries. Plus, Corda dislikes the probabilistic nature of finality provided by Ethereum. What did you learn from this episode? Feel free to say hi or post feedback for our show on Twitter and be sure to check out our other episodes with a variety of debate topics. Bitcoin's store of value status, tokenization and smart contracts, DeFi, Bitcoin havening, China's future in blockchain, POW versus POS, and oligopoly versus multiplicity of public chains. If you like the show, don't hesitate to give us five stars on iTunes or wherever you listen to this. Thanks for joining us on the debate today. I'm your host, Richard Yan, and my Twitter is@ gentso09. Our show's Twitter is@blockeddebate. See you at our next debate!