This is epicenter episode 258 with guests, Monica acquaintances. This episode of epicenter is brought to you by Dutch hex, the fair and secure decentralized exchange platform, by kenosis to learn how you can build apps, which leverage Dutch axes, liquidity fool, visit epicenter, .t V, /, Dutch x, and by Microsoft Azure configure and deploy a Consortium Network in just a few clicks with pre-built. Aggregation and enterprise-grade infrastructure. Spend less time on watching
scaffolding and more time. Building your application. Learn more at aka.ms/offweb eccentric. Hi, welcome to epicenter the show ex talked about the Technologies projects and starts driving decentralization and the global blockchain Revolution. My name is Sebastian Cujo and I'm ahead. Roy, I'm here. How's it going? It's going with been a while since we've done this together. Yeah, I can't remember what I think. I think blocks are at was our
last episode. Yeah, I think we've added a couple of new hosts and I guess like the veterans are sort of busy dying to do episodes with the new hosts so that they get up to speed. And, you know, and we have a more Diversified Group of hosts for the future. Yeah, I'm really excited about it and so our listeners will notice that the formats little different. So we don't typically sort of have this little discussion between us but we're works better.
We're experimenting with this new way of doing the show. We just thought it would be nice to be able to, you know, spend a few minutes before the actual interview to discuss about what we're about to talk about what we're about to hear.
So this is actually being recorded after the interview so it's a Good way to sort of frame the context for what you're about to hear and also it gives us the opportunity to maybe talk to you about stuff that we wouldn't normally have the opportunity to talk to you about it like events, we might be going to or things that might be happening in and around epicenter and that sort of thing. So, yeah, let us know what you think about this new new format.
I mean, doesn't change much for you, but yeah, hit us up on Twitter and also would love to hear what you think about our new, our new hosts. I mean son, he's been here for a while. Most of you. Are familiar with him, but for the Eco who just joined us recently, we're super excited to have her on. We're already this two episodes in with her and I think she's been great. Yeah.
What do you think, man? So it's great to have new hosts No, every new person, brings a different perspective and I get to learn a lot as a host myself doing this episodes with frigid Rica and Sonny because they questions are so different from mine their Curiosities are so different from mine. Yeah absolutely and it kind of takes takes the heat off of us and allows allows us to do other types of things and also for the listeners to be sort of kept on their feet as to Like, who's
gonna be the next host on? Like, the next episode? What could I expect in some of the Dynamics that that creates? Yeah, so yeah, I'm really excited and hopefully we can get some more hosts on at some point. So today, we're going to be speaking with Monica acquaintances and Monica is lead engineering and adoption
strategy at kadena. And kadena is a company that came out of JP Morgan. And it's building sort of it's our unique actually because it's a company that's building a public network and also private Network Technologies. Typically if you take like a hyper Ledger or something like that or like well maybe not Cosmos. But yeah something like hyper Ledger sort of companies that are traditionally the private blockchains space that deal with
Enterprise clients. You know, they have a stack that they're looking to deploy and Consortium networks or with Enterprise players. But they're not typically like building a public network with minors and, you know, privacy or sorry censorship resistance and such. But they're actually doing both those things, they're building a public network and they're building Enterprise blockchain, toolkit stack, whatever you want to call it. So from that perspective, I thought it was, it was, it was
interesting. I think you'll see that we sort of get into the weeds with Monica because there's some some points where Where we didn't quite agree about some of the fundamental underlying premises of their, of their public, the public network, and the consensus Network there, the mining protocol, but I think it was interesting. Nonetheless, what do you think mayor?
this kind of a unique episode for me because I saw the videos of kadena, and I chatted with Sonny on the epicenter slack prior to doing this episode, and Sonny. And I were like Cadenas claiming nearly infinite scalable infinitely, scalable proof-of-work blockchain you know in one of the videos. Somebody asks them, what's the limit to the scalability of your public platform? And their answer is, you know, that they limit is something like the limit of global bandwidth.
That is available in the world is what will limit their platform. Like, some some answer that goes into, you know, like the billions or trillions of transactions, a second. And and when I Sonny and I like looked at it, we felt that the scalability solution don't work. So I was actually I came into this episode. Hoping my doubts would be cleared and my skepticism would
go but it really hasn't. So I guess like what I am going to do is you have the episode, you can listen to it, I get into the weeds with Monica. And I'm going to just write what I think, as a comment on on YouTube or on let's talk Bitcoin. So I want to do this because I sort of realize that. People listen to epicenter episodes and they some of them might put their money one way or
another based on our episodes. And if I feel, if I have a critical opinion about something, I just want to put it there and have a discussion about it so our listeners see what's going on in the hosts. Mine. Yeah, yeah. That's a good way to do it.
Yeah, for myself I had discuss with Sonny prior to the episode, but I did read the white papers and yeah, there were some things that I also felt, I think it was after the show, we're talking with her, that maybe we were there were some fundamental differences about how we were coming at the problem, and we really couldn't get to Get to really put forth and agree on
what we were disagreeing about. And yeah, maybe this is something that we can try to follow up with or try to get a better understanding in, you know, discussions sort of off the show but in Twitter and social networks and stuff. So, yeah, here it is our interview with Monica, acquaintance of kadena I forgot to mention two things. First, we are a web three this week in Berlin.
So if you're in town at the event and you see us come, say hello, we be happy to see you and we will be at Defcon 4 in Prague next week, all week long and we are hosting a meet up. It is the decentralized pumpkin meet up. If you think pumpkins are too centralized, you should come. Have drinks with us and discuss this core issue. It is on October 31st, Halloween night, between 7:30 and 9:30. Right before the big Halloween party. So location is not quite figured out yet, but if you go to
epicenter .t V / Defcon 4 and you sign up will send you a notification when we have a location. So, see you at the web 3 and see what they've done. Louis here with Monica acquaintance, and Monica is head of engineering and adoption strategy at kadena Monica. Thanks for joining us. Thanks for having me. So kadena is a company that came out of JPMorgan and we're going to be talking to Monica today about the work that kadena is doing sort of in both public and private blockchain and both both
of those ecosystems. They are building a public blockchain network that is based on a new consensus model that they've engineered called chain web and there, So on the other side of that working on a private blockchain infrastructure for Enterprise. And so today we'll be getting into that in detail with me. So, first off perhaps, let's get a better background. How did you get involved in blockchain technology? That's why I love asking
people's crypto origin stories. So my I actually I worked with Will at the SEC once upon a time, we were both in the group that develops software to try to catch high frequency. Trading fraud, the idea is that you need software products in order to analyze trading blotters. And so, we were working on a team that built will wrote the
first draft of something. That Actually got pushed out to a bunch of examiners where they can like, upload a trade blotter and it teaches examiner's, how to look for trading fraud. So that was we were working there at the SEC and he was really burned out and I was looking for something new.
So we both left at the same time and I went to go be a systems engineer for rent to the runway, which is a fashion company based in New York, and he went to jpmorgan's, blockchain research Group, which was Hughes the lead engineer there and was hired by Stu popejoy. And so, we'll and Stu were working on the team that made Juno, which was originally proposed to become part of hyper Ledger.
And then it didn't. And then it sort of eventually morphed into the team that worked on Quorum before they were doing, that will ensue were like, oh, we've made this really incredible thing. This private blockchain, we should turn that into a company so they left and they started kadena. Originally make a private blockchain with a smart contract language and then they're like, wait a minute, we have an opportunity here.
We could take this from our contract language and we could put it on a public blockchain and then so over time we've evolved into this place where our product is actually just a block chain that works for both public and private. So willens do called me and said, hey we're going to make a public blockchain. Do you want to come? We need a systems engineer and we need somebody who can talk to people about what engineering means.
So yeah, that's I started in December of last year, which has been, I guess that's it. Like, ten months now, it's been the longest 10 months of my life, we do a lot of great stuff. A lot of good research but it's also just like everything moves so fast. Interesting. So you mentioned, you work at a fashion company. How how is that experience, informed anything that you're doing a get enough through?
The I was on the team that was doing data infrastructure and that was a we were taking it from a bare metal database to a distributed data cluster in the cloud. So I was working on this project.
I was the tech lead for taking basically a, the old school cluster in Secaucus New Jersey. And put more at migrating that so that was, it ends up being really useful because I can think about data and how its structured, and how it's stored and like what atomicity means and being able to replicate transactions. And so it actually translates pretty well to the idea of blockchain to, in my mind a blockchain is not necessarily different from the database.
It's just a data store that nobody administers. It has some particular rules about it, but at the end of the day, like it, Just another distributed data store. I was not expecting that experience to be some informative but more specifically, I think maybe we could talk about your role at the SEC what you were doing there and how that sort of that brought you into your trajectory
into what you're doing now. So the interesting thing about what we were doing at the ICC is that the their technology requirements are very high but they have the the talent there needs to be roughly unfettered in order to do what they're
doing. And this idea of trying to create sort of a tech incubator inside of a large government organization, we were at the Forefront of that and it didn't always like there's obviously friction there because engineer is that have that are really brilliant and we had some incredible brilliant people on that team and a lot of them are
still there. The idea of having to push the agenda for new The Event Horizon of new technology inside of a government organization, that we had a lot of friction there. So I actually didn't last very long. Well, was there for almost two years. I was only there for like, four months before will left. And I was like, I was just here to work with Will, who is we've been friends basically, since College?
Cool. So shifting into kadena, can you talk about some of the main projects that the companies working on? Yeah, so the we essentially have our hypothesis is that there is you only need one block chain instead of going around and trying to Cobble together, like, oh, I'm going to launch my token using etherium, and then I'm going to write it in solidity but I might want to compiled a Waze mm. And then I might want to have some sort of second, Scalability Solution on top.
And then under, like, it's too confusing. It's too hard. Nobody wants to develop on that. It's not developer-friendly. We're still at the build, your own PC stage of computing right now.
We're like it's for hobbyists and it's for people that like, get excited about seeing all these weird tool stuff but we're not going to see real adoption and usage and blockchain land until we move away from like, oh well, you know, you're not a real blockchain developer on. Less you build your own stack.
We are offering a stack that just works instead of building your own PC. You can just go to the Apple Store and you can buy a Mac and it'll just work and you can just do your development on top of it. So we have our own smart contract language and we're building our own public blockchain and it already scales. It already has a base layer scaling solution. We're building all of our own
tooling. So right now we're working on a pretty developer IDE that has built-in error messages that has built-in formal verification. We have a bunch of new developments around. How we use formal verification in our stack. And then we also have the way that we deal with privacy and handling privacy Solutions, is we have you can have an oracle out to our private blockchains so you can share as much data with public blockchain as you want to and it just it's all designed to work together.
You don't have to go around and like find a bunch of third-party solutions to try to do the thing that you're trying to do. So you mentioned that there should be only one block chain and so you're building your building this block chain based of this idea called chain web. How does so? Is it like do intend to build these permission private blockchains using the work that was done at JPMorgan?
These will be separate block chains that Connect into this system or has your focus entirely shifted to just a public chain. We are still working on the private blockchain. We're actually have a healthcare insurance Consortium that's using our private blockchain right now. In order to they have an MVP and they're working on getting the pilot up and running between these different companies and right now they're using it for
doctor office information. Sharing the idea is that each of these insurance companies get fined if they don't have correct information about like where a doctor is located and what insurance they're taking. So each of them have people that they spend money on that, call all of the doctor, like every doctor in order to try and figure out what the right information is obviously they spend a ton of money doing this redundant work because they're all trying to do it.
So phase one of this project is each of them, instead can contribute to this ownerless system, where they all benefit from the data. And right now, there's a mechanism in it where they can everybody pays into the system by running their nodes and then They get rewarded for updating
pieces of data. And then eventually, the idea is that this project we will connect to the public blockchain and allow doctors to actually update their own information because then they don't get spammed with calls from every single insurance company and then they can get rewarded directly. So the network can actually sustain itself in terms of data update and storage.
So this is the kind of idea was like a private Block Chain, that connects to a public blockchain but really it's just One project, it's the project where doctors and insurance companies can communicate with better data. But it's connected of all these different pieces which is a private blockchain with our smart contract language on top. That connects to a public blockchain interface. You know the Dutch have given us so much orange.
Carrots, Bluetooth. Artificial hearts, even Donuts were invented by Dutch people, but they also gave us Dutch auctions, which as it turns out are great for decentralized. Exchanges Dutch, X is a decentralized trade. Protocol for ERC, 20 tokens and it's invented designed and built by kenosis current order book based exchanges.
Whether centralized or decentralized have a couple of issues, minors and exchanges can FrontRunner trade when they step in front of a large order to gain an economic Advantage. Not to mention issues with securing funds, High listing fees, lack of liquidity and pricing efficiencies. The Dutch checks. Exchange platform uses a Dutch auction mechanism to determine the fair value for a token and participants in a trade are encouraged to reveal their true
willingness to pay. Say which eliminates front running as a permissionless on chain protocol. It's useful for Bots and other smart contracts needing to exchange tokens and Dutch X also acts as an oracle for dash, requiring, a price feed. So to learn more, check out the documentation at epicenter. Dot TV, / THX, smart contracts are live on a theorem a net. So you can start building today, we'd like to thank gnosis and checks for their support of epicenter. I'd like to come back just to
this thing. You said earlier that that we would only have one block chain as a software developer, I'm sure you can appreciate that. We have multiple programming different programming languages from C++ to Java to JavaScript and things like PHP and node, and all these different programming languages, sort of serve a specific use cases, or specific type of application development.
You know, whether it be for web development or Enterprise or in solidity for smart contracts and such I think that this analogy is sort of overlaps quite well in the blockchain space one because presumably they'll be many types of applications for blockchain but also just because of the sheer nature of Open Source software and how things sort of or can proliferate, and people work on their own projects and build their own
applications in such. Do you do you think that really stands up that there could be a future where potentially we could only have one block chain and everything else just vanishes. So I definitely did not say that. We Should only have one blockchain, what I was trying to say and it may not have come out this way was the idea that you should have the option to just
have a thing that works. And I don't necessarily agree with like, there are multiple operating systems and people write in different languages and we have lots of discussions about languages all of the time but you don't have to build your own computer in order to do development right now like the onboarding pipeline. For becoming a web developer, for example is easy. You just you go to the store and you buy a computer and then you like, write your first app and
it's not that hard. You don't have to understand how a computer works to write a web app, you don't need to. We want to get to the place where you don't have to necessarily understand like how cryptographic hashing Works in order to build an app on a blockchain. That was the point that I was trying to make that right now, the learning curve is too steep. Too high. You have to like have an opinion on validator nodes and like,
what's the right structure? Do you want to use like distributed or do you want to use pbft or like all of these things like people here, all these terms floating around, they get totally bewildered. And we scare away otherwise perfectly good developers who would be great for our community with like Balderdash around stupid stuff about consensus protocols like that stuff does not matter when you just want
people to build something. I Want to get the on-ramp from people learning about blockchain to building things on blockchain to be way easier. And I don't think that we're going to end up with one block chain.
I'm fact I think that continuing to make like we because of the way that interoperability Works inside of our own protocol mean that we are already set up to have interoperability with other projects which means we're going to connect to the cosmos Hub and we're going to connect to a theorem and you'll be able to launch your token on a theory on. But have it the all of your transactions happen on top of kadena? That's that's the goal.
So of course you want to build this main public network and because you want it to be accessible to developers of all kinds, you wanted to be scalable, right? So that's why kadena is focusing on scalability for its public chain. Yeah, we're focused on the way that our architecture setup. We actually get both scalability and security. The the design for chain web was originally proposed by people not us.
It was probably the first paper that came out with something like that was for Block rope, which came out and suggested a way of scaling Bitcoin for security purposes, where you can have two Bitcoins that share their proofs with each other, which would give you an additional security property. And we came up with this separately, and then ended up coming back around to the same place where we've proposed it for scalability and then realize that we also get the security
feature. So yes, the idea is that you can just put something on chain web and not have to worry about whether it's going to scale out or not. Yes, and let's talk about chain web and this scalability and security solution. Through it, how it works. I usually do this with diagrams because it's a sometimes hard to
visualize. I'm a very visual person but we can talk about it. So imagine Bitcoin and the idea that you have a block and then your new block that you generate on top of that one has a reference back to the original block. Right. This is the idea of like hash linking, or having a root or a tree like a Merkle tree. So now, imagine if you had two chains, then they each have their Genesis block and then they each start working on their first block.
The first block for each of these chains would contain the proof, like just the hash of the Year, their peer chains previous block. So, not only do they have a reference to their On previous block, they have a reference to their peer chains, previous block, you can see for Two Chains, this is a lot of messages. Like you have exactly double the number of references as you do
chains, and that's a lot. So the way that we scale this is by using a fixed graph structure and at this point, people are like, oh, this makes you a dag with my response is all blockchains are a dag. So all of these projects like cash graph and Iota are what Like to call arbitrary tags where they'll just pick like, some neighbor. That's listening. That's ready to receive piece of
information. We have a fixed graph structure where peer chains, always communicate to the pier that they're supposed to talk to. And the way this gives us the benefit of always having them communicate in the most efficient manner, specifically, our graph structure with how we braid the chains together. We use solutions to the degree diameter. A problem which is how do you have the largest order graph with a minimum number of messages between nodes the degree and the longest shortest
top is minimized. So that's like the, the shortest path between two points. What's the longest one of those minimize that number? So it allows for the fastest propagation of information out to all of the nodes, now this is how we get it to be fast and how we get it. Basically communicate with each other and effective matter is, by picking a fixed graph structure, and we have for each potential size of chain web over, which there are, you know, many many, many different potential sizes.
Each of them, we get to pick the most efficient structure per size. So, I talked about the Peterson graph a lot because it's easy to visualize in your mind, it's 10 chains, each of those chains, communicating with each other, in a fixed graph structure with a degree of 2 and a diameter of 2. So, Oh, that's to Nessa jizz per node and to block height to receive full information propagation from any node to any other node. Okay? Okay, so let's let's unpack
that. Like so the way I'm thinking of it is so, so imagine Two Chains. Let's say you have the Litecoin chain and you have the Monaro Gene, right? So we don't have interoperability between different projects, it's not, it's not interoperability between Projects. So what I'm trying to do is essentially start with like Litecoin and more narrow strip away things. We don't need like two coins. Let's strip that away and have one coin and then and slowly
from from that starting point. Let's build kadena, right. So, so so imagine like you have this is just imagine you have like Litecoin and more narrow and we have like two chains. And these two, two chains have two different coins today. So one is light going, the other is one arrow and somehow in later on in Cadena, it's like we are going to remove the two coins and there's going to be a single coin.
So can we can we just talk about cloning Bitcoin instead like you have Bitcoin and then you have another Bitcoin and they're both like because the idea is that all of the chains are actually identical. They're completely identical in terms of how they maintain state in terms of how you interact with it in terms. Of what they support. Like they're all completely clones of each other. Okay, so they're going to things Bitcoin and Bitcoin to, okay. So you have Bitcoin and one in Bitcoin to.
And so you have like two these two blockchains, they both are producing blocks else. Let's say, 10 minutes. And now let's say I'm a minor and in Bitcoin one I'm a minor in that chain. So I create a block right. So what happens differently now in kadena, so in in Bitcoin when I create a block in Bitcoin one, I would reference only the previous block of Bitcoin. One, what would I do differently in kadena? Right.
So as a minor, we expect that everybody's best case scenario would be to me. All of the chains, all of the time. So as a minor, you're actually mining both Bitcoin and Bitcoin to you're trying to get a success on both chains which from like a game theory perspective, you want to split your hashing power because you don't want to have a collision where you get a success.
Like if you throw all 100 threads on the same, to generating the same block, there's a nonzero probability that you get a success on to of your threads at the same time which case you've wasted a bunch of hash power and you should have to throw one of them away. So instead we positive that people are going to try to mine as many changes as possible all at the same time because then they can have more potential,
successes all at the same time. So you as a minor would mine both Bitcoin one and Bitcoin to and you're just like hammering away at both of them at the same time. So for example, if I have 100 e-cig machines, I'm putting 50 Asic machines on bitcoin one and the other 50 on bitcoin. Sure. Yeah, all right, let's go.
So if if you're mining Bitcoin one, did your block that you're attempting to solve has in its header, a reference to both the previous Block in Bitcoin one and the previous block on bitcoin to Okay, so I'll create a block on bitcoin one and it says, when this block comes comes in it references, the previous Block in Bitcoin one and then it also says, oh, the last block that I had heard of in Bitcoin to was this. So put that in as well. Yes, right.
And similarly, some other minor that generates a block in Bitcoin to would have listened about my block in Bitcoin one and they would put the my hash of this block in between And one in their block when they create one in Bitcoin to. Yes. Exactly. So information about each block in Bitcoin to ends up, entering the Bitcoin, one blockchain and information about each block in the Bitcoin, one chain ends up entering Bitcoin to. Yes, exactly. And the benefit of doing this is
to fold one. It keeps the network from diverging because if you have to listen to your peer chains, then you have to very quickly come to like if there are two potential blocks on bitcoin one and you're a minor on bitcoin to when you hear about both of these blocks, you must immediately pick one because you can only include one of them as the truth of Bitcoin
one in your next block. So it's a way of forcing Forks to recombine faster because if there's a fork on bitcoin one not only do the Bitcoin one miners, have Pick one, but also, all of the other peer chains in this case, Bitcoin, to have to pick one which forces people to make decisions, which is what resolves Forks. So, that's one reason, the other reason is this allows us to share. This is how we propagate State between chains and which we do through simple payment verification.
So if I want have an account on bitcoin one and we're an account-based, not UT exobase. So I have an account on bitcoin
one. One and I want to pay you, but you're on bitcoin to the way that we do that is we write a smart contract or I hate the terms of our contract, we can call it a smart contract between the two of us on bitcoin one in which I say, like oh I'm going to pay my hair, one token and then it is signed to your account on bitcoin to and then we put that in on bitcoin one, the proof of it propagates in the next block, 2. Point to, at which point you
say, hey, I'm going to redeem my half of the smart contract, on bitcoin to I have destroyed the coins on bitcoin one and they're gone. And then you redeem, which consumes the transaction ID for your half of the Redemption for the smart contract and then they coins get created on bitcoin to. So we're like you could potentially have a case in which there are is a chain that has no tokens on it because it has no
accounts or they're all empty. And then another chain could have all the tokens and it doesn't matter because each chain maintains its own idea of state. And this is how we pass information from chain to chain. If you've listened to previous episodes with Marley gray and Matt koerner, you know, that Microsoft is committed to providing enterprise-grade tools and infrastructure for blockchain developers. Well, the Azure blockchain workbench is perfect for organizations building.
Consortium networks. Take the etherium proof of authority template, for example, it's ideal for permission. Networks were consensus, participants, are known and reputable. A theorem on Azure has on chain Network governance, that leverages parodies extensible, proof of authority. Client, each Consortium member has the power to govern the network or delegate their consensus. Disciplines to a trusted
operator and parodies. Webassembly support allows developers to write smart contracts and for many languages like C C++ and rust as your blockchain workbench was created on the same principles that drive all Production Services in Azure. So, you know you're relying on secure redundant infrastructure, that can scale and we built in services. Like authenticating apis off chain databases and secure Key Management Services.
You can scaffold your infrastructure in just a few hours to learn more about Azure blockchain workbench and how Microsoft is Dancing. Blockchain usability, and Enterprise, check out, aka.ms/offweb the center and start building today. We'd like to thank Microsoft Azure for their support of epicenter on the topic. You mentioned earlier, that as a minor, you should be mining on
many chains. So if we stay on this example, Bitcoin want to be going to, we extend that example to now Bitcoin. And so presumably, you know, there was hundreds of chains, perhaps and as a minor, I'm Distributing. My hashing power amongst all these chains. Not create a bandwidth issue and because I mean scalability and blockchain is fundamentally a
networking issue. I mean, it's an issue of having sufficient bandwidth to propagate blocks quickly enough, so that everybody can come to consensus around. What is actual state of the chain? So, if I'm a minor and I'm mining on 100 blocks are 100 chains, rather that not only consumes a lot of bandwidth on a network, but it creates congestion even sort of like at the entry point of my like, my router like in my, or the switch in my, in my networking facility.
How do you how does get in a sari chain web addresses? Sure. So first, we make the assumption that large mining pools exist which I think that it the crypto Anarchist, who wants to believe that all Bitcoin is mine. To buy like individual hackers with a GPU or something in their closet is like it's a fallacy. We need to accept the fact that like, Bitcoin large, mining pools exist and they are going to mine, the whole web because they can.
And there are essentially going to perform the function of coordinating the header stream and the header stream is just these messages that go across the network. That's say, like, hey, I found a block and here's the hash of that block. And the header stream itself is very lightweight because it's very small hashes there that are being passed to each other. So, if you wanted to Only Mine one chain, you could subscribe to the header stream.
And yes, you'd have to make an assumption that the hashes that you receiving are valid. But given the fact that we assume that there are large mining pools and that people will be penalized by people not believing If they ever put out a passion, that's not valid. Then, you know, we believe that people will be able to Only Mine a small subset of the network, if that's all that they can handle in terms of bandwidth.
But that most of the mining will be taken up by people that are actually capable of handling the bandwidth. I don't know that that actually solves the networking problem at the network level, I mean, so okay potentially small. Mining operations or individual miners might only might want chain, but the broader issue that the entire network needs to
be able to visualize the state. And if those smaller miners or I don't care miners like in remote areas that don't have the bandwidth can access the information. So how do we secure the In that sense. What do you mean the information? Because they should be able to consume the header stream. The header stream is just small hashes being sent around to each other. And they're only the number of messages going from chain to chain that are the degree number
of messages in the network. So it for the Peterson graph, for example, which is 10 chains, then that's there are for every node that sends two additional messages. So it's not I guess I don't really understand your question. Yeah I think the Russians question is so today we have Bitcoin and in today Bitcoin block size is 1 MB. Right. So every 10 minutes, if I'm a Bitcoin miner I must Get one and be worth of data very quickly
and build on top of it, right? So when somebody else creates a block, let's say, Monica, you create a block in New York. I must get that 1. MB of data very quickly because I want to build on top of it. Now, now I can scale Bitcoin by increasing the block size. So if you increase let's say the block size from one end, be to 100 MB. Now I need to get this 100 MB of data very quickly, right?
In order to be competitive. Now, what Sebastian is saying is now, if certain, additionally, traditionally, when we talk about scaling, we we want to reduce this requirement of 100mb to something much lower, right? So so right now, like let's say Bitcoin had a block size of 100 MB and you wanted to scale it using some other mechanism. What you would try to do is you would want to reduce the need for getting 100 MB of data to
something lower like 10mb. but in kadena, it feels like because if I'm a kadena miner and let's have mining Bitcoin one and Bitcoin to I would need to get 100 MB for Bitcoin one and I would need to get 100 MB for Bitcoins and you don't need the 100mb for Bitcoin to all you need. Is the like one bite or like 64? Bytes. No, but or if I would like the other assumption is each mining pool is mining all of the networks.
So if they're mining Bitcoin one as one is, as well as Bitcoin to. And if I need to actually mind both those networks, I need to get data from both chains. So it doesn't solve scaling because All it all it is equivalent to is, is an increase in Block size? Like I could increase Bitcoins block size from 100, MB to 200 MB or I could split it into two networks Bitcoin and Bitcoin to 100 MB each in both cases. I need to get that 200 MB of data in order to actually run my mining operation.
Yes, I agree with the idea that if you wanted to mine, the entire network, you would still need to be able to have all the data, but that's the same problem that we have right now. In terms of people, just wanting to be able to pump out, more Bitcoin, blocks or make bigger Bitcoin blocks. But this is you if you don't you don't have to mind the entire network, you can mine a subset of the network which means you don't have to consume all of the data.
You could mine only one chain and then just listen to the header stream for everybody else's successes in which case you would only need to receive if we're using 200 as our example, and you would only need 100 Meg's from the previous block and all the others. You could just listen in for. So if bandwidth is your problem, then you can only subscribe to a subset. Yes. I actually like that. That makes total sense, right?
So so the trade-off is If I as a minor need to mine all the chains, then I need to get the data of all the chains and if all miners are Force to get the data of all the chains, kadena boils down to like a single block chain with an extremely large block size, right? So that's not scalable. So, the point at which Cadena would be scalable is if I if me as a minor is given the choice of needing to mine.
Only one. And forgetting about the other chain and then I need to listen to only one chain. Listen to a smaller data stream and other minors can work on that other chain. And then, there is scalability. So, I actually agree that. That's the that's the fundamental trade-off that in order for a system like a Dana to actually scale really scale, you would need to concentrate minors into certain chains like, hey, miners, 3539 and 38.
Focus on blockchain number 23, U5 - focus on some other chain and so on. Would you agree with that?
Yes. And I think that it seems like I should build a timing and bandwidth consideration into our mining model right now, because we're doing a bunch of markup simulations on like x, what people's expected value is on mining different chains and that right now at the moment, we have it where the penalty for switching between mining different chains is very low, which causes our model to suggest that people are going to basically hop to mining.
Whichever chain, they think The last, the least attention last round and with that as I could just go in and dial in different assumptions into and right now I don't think we've necessarily considered bandwidth as being a huge lever. But if you think that that's interesting, like totally think that that's a worthwhile suggestion.
From my perspective, I think bank with is but on a mantle I'm barrier to descale ability at the lowest level me any any solution that we try to build on top of the existing blocking him to create more efficient watching systems whether be proof of worker proof of stake. What we're trying to do is essentially is minimize the amount of bandwidth that needs
to go from. Validators that maintain the chain for me. It's sort of a sort of a fundamental thing in in this scalability discussion in a broader sense that most people are not addressing. So we've had some, we had a project on recently blocks route, sort of building a Content distribution Network for her blockchains that addresses. This issue at the fundamental Network level, But I haven't, I haven't seen any other projects at least the ones we had on that sort of look at scaling from
this perspective. But you written a white paper which describes the different attack vectors possible with chain web and the ways you may negate them, could you run us through some of these and how your medicating those detectors?
Sure. So, the first one that we started looking at, because it's like the fundamental Like the first one described in the Bitcoin white paper and all this is about 51% attacks and how like basically everybody screwed, if somebody gets 51% control of your network and fine but if they don't have 51% but they have less percentage of your network. How does that mitigate the potential likelihood of somebody being able to attack your chain?
And so when it comes to double spend attacks because of these shared, References between chains where like Bitcoin to has the hash of Bitcoin one. And it not only does it quickly force you to resolve any potential Forks. But also, as block, depth increases and the block that's being attacked, gets further in the buried, not only by blocks on its own chain, but by Pierre chains, that reference. It also getting buried, you start having to not only replace
at any. Even chain, but you also have to replace any peer chains that happened to reference it. So, when we started looking into strategies, that would require some that somebody would use in order to replace a block and do a double spend attack, they have to honestly, mine the network in order to generate Pier blocks like more than 60% of their, hash power actually has to go to honestly mine the network in order to try to attack the network.
And they just, they Potentially fall behind in terms of that attack. That, that's not really a fusible situation. That was the first one that we looked at this is the whole, like, the block rope originally produce. This chains, sharing each other's hashes as a security measure, that's how that really gets exposed. That's how we come up with the term, we use the term Merkel cone because it's like, Merkle tree, but it has an additional dimension on top of it.
So it's because of the way that that the Merkel cone propagates exponentially across all these different peer chains. Double spend attacks are very hard. Okay. That's that's sounds like an interesting proposition. So like in let's say like you have like a kadena network and you have 10 chains in this
container Network, right? And you know like the total mining power in, this whole network is X like X that I hashes or x x, whatever unit and you can think of it like thousand Tara hashes, some large number, And then you have kadena chain 1, K 1, you have good energy into k 2 and you have approval screen, a chain 10 K, 10. So that the total hashing power is thousand data hashes, is it the case that kadena one gets 100?
Tara, hash kadena to gets 200, Tara hash and these thousand are distributed equally between the chains or how does mining power get distributed across these chains? So, it's the, it's the miners Choice, which chains to mine.
And this is part of what the simulation project that we've been working on, in terms of building the, the model for the network graph, and then building the minor graph and then having them run through simulations on how they would mind that our, we posit obviously, we haven't built it yet, so all of this is
still simulation land. But that the network when actually stabilizes to a point where they're all Be equal because any chain that you think has less hash power becomes an attractive Target. So you want if your chain, if you think the people a lot of people are mining a chain that you're on, then you're competing too much. And you want to hop to a chain where the collective hashing power is lower which actually causes the entire network to, to
stabilize their. Also the fact that you have to wait for that the blocks to be finished on your peer chains before you can include their proofs in your header. It serves to it's sort of like you've tied them all together in this three-legged race where they can't get too far ahead. You can only get diameter number of blocks ahead of the network as a whole, which means that any change can only fall diameter number of blocks behind before it starts to slow.
Everybody else down, which then causes people to dog pile on to the chain, that's holding them back. So this is the, like, the balancing Network. We haven't, we've called it given this event horizon of It's various names are lead chairman of engineer calls it. The cut set, which I think is sort of a weird term. I was calling it the meniscus for a while, nobody like that one. Nobody liked meniscus.
So, I've I'm going with Event Horizon for now, which is the, like, the latest block for all of the chains and where they are. And this is the idea that the hashing power will pool to the lowest chain because that's the one that is the most attractive. So that's an interesting idea. So the basic idea is that you somehow want to have these 10 chains and you somehow want these chains to progress at similar speeds. So if a blocks is created here, you want the other change to create blocks.
And so what you're effectively doing is, you're somehow incentivizing the minors to switch to the slowest chain so that the whole system can make progress and when the miner switch to the slowest, In automatically the highest power, distributes equally. So right? So you start with let's say 1,000 Tara hashes, and you end up with a system where there is like 100 Tara ashes equally
across all the chains, right? So it won't, it won't be exactly equal but like some might have 80 some might have 120, this is easier that but like it you will aim to get like somewhat equal distribution. Now, the question becomes that suppose, now I am a miner on chain five, right. So I'm a miner on chain five and I'm a large minor. And now chain 5 has 80 80 like a tee, Tara hashes.
Right now, I'm a large minor and my mining capacity right now, I'm not mining to Dana, but my mining capacity is 100 Tara hashes. I can 51% attack chain five because those guys are 80 and I have 100 pointed waiting to go. So what I do here is I'll say okay, let me put those 100 on just chain 5 and let me just create one in valid transaction
that creates. I don't know a billion kadena and just gives it to me. And I basically create that block very quickly on chain 5, and because my block appears quickly because I have more hash power than the others that invalid block propagates to change seven eight, two and one and they include my invalid block when they create the next block. And so my block becomes canonical. Do you think this is a problem?
So the way that that would become resolved in chain web is like, you're not the only minor on chain five. Somebody else will attempt to validate your block as a way of putting the next block on top of chain 5 and see that your block isn't actually valid. And which case they will suggest this as an alternative. And since people are mining like you Would mind a subset of chains.
Mine like chains five, six and seven, then somebody who's minding five six and seven seas that like five is actually not a valid block and will suggest an alternative block and include that in 6 and 7. And then whoever is most remaining six and seven. Will see this other proposed block 5 and that it's not included.
In this other proposed block 6, which will then cause them to reject that block 5 and the block 6 that includes a reference to the bad block 5. Like This idea that a bad block would never be validated by another minor is like, I think the core of why that doesn't necessarily work. So what are you saying is now, you're going to use the other chains as a Judiciary of Kinds, right? So I'm the, I'm the big bag, bad attacker.
And let's say, Sebastian represent the honest miners of chain 5, I'm the attacker of chain 5 And so I was passed because I have more hashing power. I produce the black quickly, it broadcast quickly. Now you saying like, oh Sebastian but will also create the competing block and try to broadcast it right now. Now the whole network chains, one two ten must decide his methods block canonical or Sebastian's block canonical.
So, the whole network in some senses needs to become a Judiciary. Yes. But they can be a judiciary. Only if they know if only if they store the whole Block Chain of chain five. But only if they're mining a smaller subset of any connected subset of the network like five, six and seven or three, four and five or so. Because so let's say I propagate my hash tube from 128 blocks change, 1 to it here.
My thing and Sebastian things Sebastian's honest, thing goes only to 9 and 10. I win well but then it'll go to 9 and 10 and then 9 will have to reconcile with eight and then you'll have to go and you'll pick which one of these either 9 or 8. So this is because of the way that it's webbed together you have to make calls very fast. And yes we assume that people are mining more than one chain which allows them to cross check each other.
If everybody only mind one chain then we would have a problem. But because it's designed for people to hop between chains in mind more than one chain, it forces them to reconcile with each other. I mean, let's let's move on to some other topic, but I feel like the fundamental issue with
Cadena is is exactly this. It is, it is that in order for reconciliation to work, you start to need bigger and bigger jewelries and ultimately, you will boil down to the system where everybody needs to mine Every Chain. Which means Everybody needs to get the data from Every Chain, which means actually it will not end up solving scalability. I don't think that everybody needs to mine Every Chain but that's that's a fair critique. Yeah. Okay, so let's move on to the next theme Sebastian.
So there was a, I wanted to come back to this earlier in our discussion but we sort of got sidetracked with these other topics, but there is one passage in the white paper that kind of struck me and I wanted to maybe get you to perhaps, explain it in your own words on page 2. There's a section where you A proof of stake and proof of work. And you argue that proof of stake. Validators would be subject to money, transmitter regulation. At least in the US as it reads here.
Can you expand on this logic and What, what evidence you have to support this? This claim that proof of stake. Validators would likely be subject to money transmitter regulations. Sure. So this is the reason that we take this position is the idea that right now. It's to it takes too long and it's too hard to pass new laws to try to regulate blockchain. And it's going to take a while in order to get new legislation
out there. Are especially in the United States for these things, take forever and people debate about them for a long time that trying to pass new laws for black jeans going to take a while. So the only way that people are going to try to regulate blockchain for at least, the short-term is to try to apply existing legislation to block
chain. And the way that existing legislation works for money transmitters is essentially, if you put money up and we know who you are and then you clear a transaction that sends money to like Al-Qaeda or something. That we should punish you because you are enabling money Transmissions to somebody who's sketchy.
So when it comes to proof-of-work miners because they don't necessarily have any stake in the network and we don't necessarily know who they are, if they clear a transaction by mining that sends money to Al-Qaeda, then it's not their fault because they weren't actually Being a money transmitter because they didn't put any money up and we don't know who they are, but when it comes to proof of stake, part of the argument about making proof of stake, work, is that you had
to prove your identity. And you had to stake some sort of amount of money and because you put up that money and then you sent money to Al Qaeda, you can fall under existing money translator legislation, much easier than a minor who doesn't look like what the law already considers to be a money transmitter. So That's why this area it's that the shape of staking looks a lot like, the shape, of existing money transmitter legislation.
Whereas, the shape of mining doesn't look very similar to existing money transmitter laws. So that's why we're concerned about validation in general. Like, all of these Services were a fund is trying to turn their fund into being a validator on my chios or something where they then clear transaction that then
causes, I don't know. No, something illegal that they could be held liable for it. I mean, so don't you think that if this were the case, if Regulators really wanted to go after, after make what I mean like and I mean Bitcoin in the eyes of us Regulators, I would say I mean, to some extent, perhaps not everyone, but the some extent Bitcoin is seen as a currency where a lot of it listed transactions occur, or at
least have occurred in the past. Don't you think The Regulators could just go after money pools, that it because we know we're mining is concentrated where they could. Could force mining pools to do kyc on the miners that access the pool. I don't think that legally they could make that case right now that mining is money transmission but I do think that they can make the case that validating is money transmission.
That's that's our stance on it. That validating looks really similar to existing legislation and Mining does not Mary I think you'll have a lot to say about this. Yeah and this is because like the validator is identified with one public key, whereas a minor is not. Yeah. Or that a minor may not even be participating in the network necessarily. They could just be mining a block with their hashing power, and then immediately selling all their Bitcoin.
And they don't care about like staking money in the network. It's this, like, staking thing. That is the, that is the problem because then it looks like being having a money transmitter license is like you know you staked a bunch of cash in order for somebody to then be able to use you as a transmitter. That's what that shape starts. Click. Yeah, but I would say that that up, I mean the the obfuscation of identity that you have in Bitcoin.
Mining can be you can wrap your, you can replicate that obfuscation in proof of stake as well. Be okay. You may have a key but I mean, you can pretty easily I would say change that that key for the next round of validations and the the valve later that's taking steak from from Dell Gators doesn't necessarily have the identity on this road. Some sort of kyc, of the delegator themselves. So it's it's the probabilistic nature of proof of work that really gives it the
slipperiness. Because as a Bitcoin miner there is always a nonzero chance that the block that you confirmed might not actually be the real confirmation. It's this like invalidating, you actually have to vote and then the vote is confirmed. And Have finality. It's the finality thing that really makes it a certified transition with your name on it in Bitcoin.
It's like there's always some probability as to whether you did or did not confirm it and it's not really a Line in the Sand, it's this finality issue that actually makes it slippery. That's a very interesting argument.
I was saying like that's something and that's an entirely new way of looking at it. So what you're saying is if I'm a miner in Bitcoin and I created this block, it had a bunch of transactions and I published it. I can argue that I published some data but I wasn't 100% sure. It was going to be included in the Bitcoin blockchain.
It could have been orphaned. So I wasn't processing transactions, I was just publishing data and because I didn't have certainty that that data would go into Bitcoin, I'm not transmitting money. but in proof of stake, if I vote on a block and after my vote the block gets finalized. So let's say like the voting has happened and I cast the determining vote that finalized that block. And what I'm essentially doing is in the process of voting.
I am making the transactions final And that makes me more like a money transmitter because while I was publishing that data, I knew that if I publish it, these transactions would be considered final. Yeah. That's super interesting II. Don't know if The Regulators are going to look at it like this or not, who knows? I mean that's are interpreted. We just think that proof of work is safer because it has this other like dimensional element to it and I really don't want to go to jail.
I'm sure like the proof of stake designers, so you know, like, In Allegan Cosmos. So I'm actually building a cosmos validator. So this is a topic that's really close to my heart in Cosmos. Yes. Like the validator, it could be doing things that are like castingwords. It's like you know or like you know in Cosmo 66% of the network has to cast a cast. A yes, vote for the block to go in the chain and be final.
So let's say, you know, like 65% has done and then My validator costs that decisive vote that switches it over to 66% and then creates a new block that takes that vote as final then maybe they maybe they could be this element that. Yes, I did put the deciding vote in there.
The validated it put the deciding vote in there, but I think if you look at something like this a source, that argument would be quite vka Source because in tells us even if you create a block that block is not final until like 10 or 20 blocks are built on top of your block, it's like Bitcoin so Cosmos is not like Bitcoin. The block is final and you don't need to have more blocks on top of it to be final but in tells us it's like like Bitcoin where you need 10 things to come on
top of yours before it gets considered final. So if that's the argument then there's us Baker is fine but a cosmos validator may not be so that that will be quite interesting. I actually love Cosmos. I think Cosmos is a great project and I think Zaki is amazing and their whole team is great. So just because we're not proof of stake doesn't mean that necessarily were like fundamentally theologically opposed to proof of stake. We look at some of the
blockchain ecosystem. At the moment, we can start to discern some, some, some some applications and use cases for each one. You know, Bitcoin is sort of shaping up to be a digital gold, right? And asset that you keep and that will gain value within the future. Ethereum is shaping up to be at least in the initial use cases in Project funding. Etc. What is what is the use case here for her chain web? What's the application that
you're hoping? Willie marriage is like the killer application for chain with? So I like to talk about the like blockchain as a stack where, for example, if you were going to launch a project and you wanted to do a token sale and then you want to have an application, that would be able to move a bunch of transactions through
your app. And then you would sell your token on ethereum, but you would want to program your app impact and have your transactions from Chain web because we positive that we're going to have much higher throughput and therefore much lower transaction fees and we will be able to handle high volume transactions in a way that right now if they're IAM your sort of struggling to have a high volume of transactions and we would like to have the ability to have interoperability
between all of these other different layers of the blockchain stack. If you wanted to launch your token on eith, we would want to be the computer underneath because we have a super simple, smart contract language that we think is very easy and has really nice tooling on top of a chain, that will be able to handle your throughput. So we're very conscious of your time here. And we want to spend some time on packed, but I think we might have to leave that for a future episode.
Give me like, two minutes on packed. Okay, sure. Because it's really cool and really, everybody should go and take a look at it. We have the developer SDK sir. You can, like, treat your computer as if it were a tiny node, and right packed right now. It's so we've taken like, basically the completely opposite track from solidity and all this like virtual machine land, where we're trying to replicate an entire computer on a blockchain, it is non
turing-complete on purpose. It's more like SQL for the blockchain instead of sequel for database. We have packed for blockchain and it has all the things like key, signatures and governance. And who owns what? And who can change? What? All that is built in automatically. It has a Full formal verification spec. And we have this really awesome thing.
Now that we've just developed called verifiable interfaces, where you can essentially like program, what an ER C20 should look like and give it a bunch of specs. And then if somebody implements it incorrectly, it will warn them like, oh, you're you're C20. Equivalent is actually a malformed. So you can can't have like we did the summer a bunch of, like, bad ERC 20s that come out. So, all of that stuff all built in already packed is like, I could.
And a whole nother hour talking about it, but we'll talk about it another time. Yeah, well we perhaps we can have your own in the future to go more in depth on packed because I mean chain web did take a while to unpack here unpacked. So I did want to spend some time on on kadena and your private blockchain offering. So how does Canada interact with with chain web? And what's the goal here with regards to the types of clients? It's that you're approaching with this with this platform.
Yeah. So we have, we have to signed clients. Right now that we're working with one of them is this health care insurance project that we've already. I've already talked about briefly but in general, the idea is that we want to be a way of onboarding existing businesses and new business applications from private to public in a way that is Safe and secure, and is a way of unlocking, existing business value in a new way, new
liquidity pipeline. So, I talked about the health insurance one where, you know, you can pay doctors to update their own information. We've also talked to a bunch of different companies. Some of them are, some of them are cooler than others. Are other big client right now, is a reinsurance company that does Insurance products. They do like home insurance and stuff. Cough. And so we've been discussing with them something where they can have a broader pipeline for
validating their auditor data. So using a third-party Auditors that can contribute data in a more tightly verified way to their pipelines so that they can have a better less leakage in their insurance flow. Basically.
So we have the side where we deal mostly with private and then we also have a focus on dealing with public and then everything in between So we talked about the idea of connecting Smart TV to the wall and then having a people in public on the public blockchain, get paid like five dollars off their Netflix subscription or something in order to provide their Smart TV data to a private blockchain, that would then use that information which would be better than what we have now
because right now like who knows who's looking at your data and what you're providing them. This would give you control over your own data which you could monetize in public but then they could mine. In private.
So there's we have this idea that there's not private and public, there's just one block chain with different permissions, So to touch on this in the in the white paper you there's a part there where it references, sort of the scalability benefits of kadena in a private setting and it makes reference to sort of five to fifteen thousand nodes as being, you know, the threshold where it begins to exhibit
linear scalability. Let me, which is sort of expect that at some point that your system is going to stop scaling exponentially and more linearly But give it given that, you know, a network like Bitcoin as I just looked up earlier, has about 10,000 nodes. What point does a network, go from being a private Network to just being another public network? Does it preserve the benefits that sort of the initial Consortium or set of clients set out to, to implement? And what where's the line?
They're like, where were you sort of switched from being one to the other? So the our simulations for scalable bft, which is our private consensus mechanism, is we've never run a simulation more than 500 nodes. But given that are other options for people trying to do private blockchain right now or like hyper Ledger, that doesn't scale past four nodes and kurta, which isn't even really a blockchain and all of these like other private blockchain Technologies.
We fundamentally believe that we have a better private blockchain, then anybody else right now. And that the idea is that you would for one of these applications, start it in scalable, bft in the Consortium model. And then, as you see the potential benefits of unlocking, some of these pieces of data into public, you can connect them to the public chain. So it's more about how you want to monetize your data.
If it's still the idea that you want to share in a Consortium model like we can scale that out for some certain amount of time, but it's still a permission model. Whereas, if you wanted to allow exposure to some of these pieces of data to the public, like, we're talking to a fund right now that creates products for people to put in their, like, mutual fund portfolios. It's not treasury bonds, but it's sort of like treasury bonds.
They want to create A tokenized representation of one of their funds so that would be a public representation of a private blockchain that represents an asset. If that makes any sense. So I want to take this opportunity to ask you your thoughts and opinions about where we stand right now, with regards to Enterprise blockchain permission blockchain, what have you?
Previously, I co-founded a company that sold I guess Enterprise blockchains solutions for traceability to do large, insurance, companies companies and finance sector. And I came out of that with haven't been confronted with the the the challenge. Of implementing blockchain in Enterprise, sort of skeptical to like, where things are going in
the space right now. And I could point to a few things namely is that blocked any sort of orthogonal to a lot of the business models in, in finance, most in the financial sector with insurance or banking, or financial services. And although a lot of companies obviously are paying attention to blockchain and experimenting with proof of concept set, None of that has really panned out. And, you know, we've been saying
for about three years. I like that Enterprise is going to start adopting blockchain, but even the largest Consulting companies like IBM have been pumping out, pocs and are struggling to convert those into production systems. I think mostly it's because of this orthogonal nature of what blockchains represent to large companies and just failing to see the ROI I guess. As everybody is joining consortiums and trying to figure out like what they're going to
do next. Why is credit card Anna different in this sense and like what's your what's your go-to-market strategy? For bringing customers on board, consortiums on board and then converting them over. It's a sort of this public is more public network as you described it. So, our vision for kadena is a whole is that we because of how, our smart contracts function, you can essentially create importable services.
So stick with me here, and I'm going to tie back to Enterprise, but imagine on the public chain that you have building block services, that provide a network that You a lot of flexibility. So you have we're going to set up a background, check service that's on the blockchain and a escrow service and a smart contract insurance. And all of these components that we have right now in the economy, they don't function
great and they're expensive. And they essentially push all of the payment on to the consumers, end, which sucks. So instead, if we Have them in an importable smart contract way on a public blockchain. Then you say as entrepreneur want to create a rent, an apartment service on the blockchain. So what you would do is you would have a way of showing your listings. And then when somebody wants to rent an apartment, you would
import the background. Check smart contract and you would use it. And for some sort of micro transaction fee, you pay the verifier of the background check directly. Finish my contract, you would have some sort of escrow service, which you would pay directly, or maybe you just do it built into your smart contract and these building block components would help you
do the part of your real estate. Apartment rental startup that is most interesting to you, which is figuring out how to expose listings without having to deal with all of these other terrible components that are necessary for a company like ensuring your smart contracts and doing background checks. And whatever. So then when we're talking about having these services on a chain, there are a lot of companies that already have these Services.
They just don't know how to effectively monetize them or they're already cost centers from their company that by having an oracle to public blockchain, they could monetize what's already a cost center for them.
So imagine like, I don't chase bank, Chase Bank already has Department that does background checks and if they could have a smart contract on the public blockchain where people could pay them to do background checks, they could run that through their Pipeline and monetize an existing business unit. That right now is only a cost center for them. So this is it's sort of like applying the sharing economy to the components that already make
up very large businesses. So this is a way of onboarding Chase Bank on to Enterprise bok choy. And I'm not saying like Deer Chase Bank. Please go in and rip out all of your existing database because they're never going to do that. But instead we can go to them and say, look, let's create a new product that monetizes an existing cost center in your business. That doesn't have to connect to any of the rest of your network.
That's totally secure, and let's see how it goes, because they're much more likely to try to create a new Revenue stream, that's disconnected from the rest of their business. Then they are to try to like, About the guts of their existing
infrastructure. It's super hard to sell that because nobody wants to touch something that's basically working for something that doesn't necessarily have any major advantages but potential new revenue streams, everybody gets excited for potential new revenue streams I get that and I think that's the fundamental issue here. And that's the sort of fundamental problems with the whole premise of Enterprise blockchain.
Is that It is orthogonal to the like to, to try to, to get Chase Bank to monetize an existing service is real Authority with the way that they already do business, especially when you're opening it up on on a sort of public network. And I think that coming over my experience in my previous company that it's not so much. A technological issue, is not so much about the technology. It's really a change management issue. And that all this is vandalism that all of us have been doing for.
So all these years in large companies and Enterprise about blockchain technology, I think we've been doing it wrong. And it really comes down to like, what is the future of identity? What is the future of payments? What is the future of insurance? Was that going to look like in the future and in currently, I think most people that are addressing their talking to Innovation, departments at Banks and financial services companies Insurance. What have you are not really doing this.
They're still spending time saying oh well I mean, look, you could, you could take this existing thing plug a box and into it and start making money in this ecosystem. That doesn't, that doesn't exist yet. So I guess my question is remains like, what is the, what is really, the go-to-market strategy where have you? I like sort of identified, some key Industries or types of clients where You can take a Dana and really provide an out-of-the-box solution to start generating like generate
revenue. And to prove these use cases because the proof is in the pudding. Sure. I mean, we have two existing clients. We already have a working MVP. I don't know what to tell you other than like, we're doing it. And we don't have to pay like some companies like pay people to use pocs, like, people come to us, they want to use our stuff. Sometimes we have to turn people away because they're like, we have this great idea. We're like great, but we can't execute it for you.
You have to have your own engineering team. We're just going to give you a Consulting, like, if people aren't ready to go, we're not going to work with them. But right now, big people are coming to us, say they say that we have a thing that works. We do. So what's the, what's the roadmap like in the next? So you mentioned earlier and SDK but people can already start using the platform. Can you talk a bit more about
that? Sure. So we've got two teams right now working on both the language development and tooling for developers and another team that's working on chain web and protocol development. And so we've split them into two tests Nets to where we're at right now. Working on both of them, the
same time, The Pact test. Supposed to come up next month, where people can see it's going to use a database to generate blocks, but it's essentially going to have all of the bells and whistles for a development environment, where people can put, their smart contracts up onto our IDE, and have error messages, and it'll hook up to the formal verification system. And this will be more of a simulated experience of what developing on containing will be like.
And then, Meanwhile, we're working on chain web test net, which should be up by the end of the year, which will, it's basically, just a way of testing. Testing how blocks get generated in Forks, get resolved in the consensus mechanism and then we're going to merge them to create a unified test net. When then the goal is to have the main it launched around the second quarter of next year. Great. So we'll have links to all that
and show notes. If people are interested, they can go to do the Canadian website, read the white papers, which you've you've co-written with your co-founders and and learn more about how Canada will be building up. This, this chain web Network and then also implementing their Technologies in Enterprise. So thanks Monica for coming on the show today. Thanks guys, this is great. Thank you for joining us on this week's episode. We release new episodes every week.
You can find And subscribe to the show on iTunes Spotify, YouTube SoundCloud or wherever you listen to podcast. And if you have a Google home or Alexa device, you can tell it to listen to the latest episode of the epicenter podcast, go to epicenter, .t V /, subscribe for a full list of places where you can watch and listen, while you're there, be sure to sign up for the newsletter so you get new episodes in your inbox as
the released. If you want to interact with us, the guests or other podcast listeners you can Follow us on Twitter and please leave us a review on iTunes. It helps people find the show and we're always happy to read them. The thanks so much and we look forward to being back next week.