We’re joined by Monica Quaintance, Head of Engineering and Adoption at Kadena. While most companies providing enterprise solutions focus primarily on permissioned systems, Kadena is building both a public network protocol and private blockchain infrastructure. Their Chainweb protocol will soon launch as a public network and smart contract platform. The company claims their novel approach to proof of work offers enormous gains on transaction throughput, even at scale, while benefiting from the same security as Bitcoin. Alongside Chainwebs, Kadena is building a permissioned protocol more suited for enterprise applications in insurance and finance.
Topics we discussed in this episode
- Monica’s background at the SEC
- The genesis of Kadena and why the founders left JP Morgan
- Kadena’s unique approach to building both public and permissioned protocols
- The Chainweb protocol and it’s approach to proof of work
- The incentive mechanisms in Chainweb
- How Chainweb protects itself against common attack vectors
- The PACT smart contract language
- Kadena’s enterprise blockchain offering
- The company’s go-to-market strategy and business model
Sebastien Couture: Hi, welcome to Epicenter, the show which talks about the technologies, projects and startups driving decentralization in the global blockchain revolution. My name is Sebastien Couture.
Meher Roy: And I’m Meher Roy.
Sebastien: Hey, Meher. How’s it going?
Meher: It’s going well.
Sebastien: It’s been a while since we’ve done this together.
Sebastien: I think bloXroute was our last episode.
Meher: Yeah. I think we’ve added a couple of new hosts and I guess the veterans are busy trying to do episodes with the new hosts so that they get up to speed. We have a more diversified group of hosts for the future.
Sebastien: Yeah, I’m really excited about it. Our listeners will notice that the format is a little different. We don’t typically have this little discussion between us but we’re experimenting with this new way of doing the show. We just thought it’d be nice to be able to spend a few minutes before the actual interview to discuss about what we’re about to talk about, what you’re about to hear. This is actually being recorded after the interview. It’s a good way to frame the context for what you’re about to hear. 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 like events we might be going to or things that might be happening in and around Epicenter and that sort of thing. Let us know what you think about this new format. It doesn’t change much for you but hit us up on Twitter.
Also we’d love to hear what you think about our new hosts. Sunny’s been here for a while. Most of you are familiar with him but Friederike who just joined us recently, we’re super excited to have her on. We’re already two episodes in with her and I think she’s been great. What do you think, Meher?
Meher: It’s great to have new hosts. Every new person brings a different perspective. I get to learn a lot as a host myself doing these episodes with Friederike and Sunny because their questions are so different from mine. Their curiosities are so different from mine.
Sebastien: Yeah, absolutely. It takes the heat off of us and allows us to do other types of things and also for the listeners to be kept on their feet as to like who’s going to be the next host on the next episode, what can I expect, so the dynamics that that creates. I’m really excited and hopefully we can get some more hosts on at some point.
Today we’re going to be speaking with Monica Quaintance and Monica is lead engineering and adoption strategy at Kadena. Kadena is a company that came out of J.P. Morgan and it’s unique actually because it’s a company that’s building a public network and also private network technologies. Typically if you take a Hyperledger or something like that and companies that are traditionally in the private blockchain space that deal with enterprise clients, they have a stack that they’re looking to deploy in consortium networks or with enterprise players but they’re not typically building a public network with miners and 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.
From that perspective, I thought it was interesting. I think you’ll see that we get into the weeds with Monica because there were some points where we didn’t quite agree about some of the fundamental underlying premises of the public network and the consensus network there, the mining protocol. But I think it was interesting nonetheless. What did you think, Meher?
Meher: This is a unique episode for me because I saw the videos of Kadena and I chatted with Sunny on the Epicenter Slack prior to doing this episode. Sunny and I were like Kadena is claiming a nearly infinitely scalable proof of world blockchain. In one of their videos, somebody asks them, “What’s the limit to the scalability of your public platform?” and their answer is that their limit is something like the limit of global bandwidth that is available in the world is what will limit their platform, like some answer that goes into like the billions or trillions of transactions a second. When Sunny and I looked at it, we felt that the scalability solution can’t work.
I came into this episode hoping my doubts would be cleared and my skepticism would go but it really hasn’t. I guess what I’m 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 YouTube or on Let’s Talk Bitcoin. I want to do this because I realized that people listen to Epicenter episodes and some of them might put their money one way or another based on our episodes. 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 host’s mind.
Sebastien: Yeah, that’s a good way to do it. For myself, I haven’t discussed with Sunny prior to the episode but I did read the whitepapers and there were some things that I also felt, I think it was after the show where we were talking with her, that maybe there were some fundamental differences about how were coming at the problem and we really couldn’t get to really put forth and agree on what we were disagreeing about. Maybe this is something that we can try to follow up with or try to get a better understanding in discussions off the show but on Twitter and social networks and stuff. Here it is, our interview with Monica Quaintance of Kadena.
Sebastien: I forgot to mention two things. First, we are at Web3 this week in Berlin. If you’re in town at the event and you see us, come say hello, we’d be happy to see you. We will be at Devcon 4 in Prague next week, all week long and we are hosting a meetup. It is the Decentralized Pumpkin Meetup. 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. Location is not quite figured out yet but if you go to epicenter.tv/devcon4 and you sign up, we’ll send you a notification when we have a location. See you at Web3 and see you at Devcon.
We’re here with Monica Quaintance and Monica is Head of Engineering and Adoption Strategy at Kadena. Monica, thanks for joining us.
Monica Quaintance: Thanks for having me.
Sebastien : Kadena is a company that came out of J.P. Morgan and we’re going to be talking to Monica today about the work that Kadena is doing in both public and private blockchain ecosystems. They are building a public blockchain network that is based on a new consensus model that they have engineered called Chainweb. They’re also on the other side of that working on private blockchain infrastructure enterprise and so today we’ll be getting into that in detail with Monica. First off, perhaps let’s get a bit of a background. How did you get involved in blockchain technology?
Monica: I love asking people’s crypto origin stories. I worked with Will at the S.E.C. once upon a time. We were both in the group that developed 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 or something that actually got pushed out to a bunch of examiners where they can upload a trade blotter and it teaches examiners how to look for trading fraud. We were working there at the S.E.C. and he was really burned out and I was looking for something new, so we both left at the same time. I went to go be a systems engineer for Rent the Runway which is a fashion company based in New York and he went to J.P. Morgan’s blockchain research group which he was the lead engineer there and was hired by Stu Popejoy.
Will and Stu were working on the team that made Juno which was originally proposed to become part of Hyperledger and then it didn’t and then it eventually morphed into the team that worked on Quorum. Before they were doing that, Will and Stu were like, “We’ve made this really incredible thing, this private blockchain, we should turn that into a company.” They left and they started Kadena to originally make a private blockchain with a smart contract language. Then they were like, “Wait a minute, we have an opportunity here. We could take the smart contract language and we could put it on a public blockchain.” Over time, we’ve evolved into this place where our product is actually just a blockchain that works for both public and private.
Will and Stu 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.” I started in December of last year which I guess it’s 10 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.
Sebastien: Interesting. You mentioned you worked at a fashion company. How has that experienced informed anything that you’re doing now at Kadena?
Monica: I was on the team that was doing data infrastructure and we were taking it from a bare-metal database to a distributed data cluster in the cloud. I was working on this project. I was the tech lead for taking basically the old school cluster in Secaucus, New Jersey and the problem migrating that. It ended up being really useful because I can think about data and how it’s structured and how it’s stored and what atomicity means and being able to replicate transactions. It actually translates pretty well to the idea of a blockchain. 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, it’s just another distributed data store.
Sebastien: I was not expecting that experience to be so informative of the blockchain experience. But more specifically, I think maybe we could talk about your role at the S.E.C., what you were doing there and how that brought you into your trajectory into what you’re doing now.
Monica: The interesting thing about what we were doing at the S.E.C. is that their technology requirements are very high but the talent there needs to be roughly unfettered in order to do what they’re doing. This idea of trying to create a tech incubator inside of a large government organization, we were at the forefront of that and there’s obviously friction there because engineers 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 of that horizon of new technology inside of a government organization that we had a lot of friction there. I actually didn’t last very long. Will was there for almost two years. I was only there for four months before Will left and I was like, “I was just here to work with Will.” We’ve been friends basically since college.
Sebastien: Cool. Shifting into Kadena, can you talk about the main projects that the company is working on?
Monica: Yeah. Our hypothesis is that we only need one blockchain. Instead of going around and trying to cobble together like, “I’m going to launch my token using Ethereum and then I’m going to write it in Solidity but I might want to compile to Wasm and then I might want to have some sort of second layer scalability solution on top,” 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 P.C. stage of computing right now where it’s for hobbyists and it’s for people that get excited about seeing all these weird tool stuff. But we’re not going to see real adoption and usage in blockchain land until we move away from like, “You’re not a real blockchain developer unless you build your own stack.” We are offering a stack that just works. Instead of building your own P.C., you can just go to the Apple Store and you can by a Mac and it’ll just work and you can just do your development on top of it.
Then we have our own smart contract language and we’re building our own public blockchain. 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 I.D.E. 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. The way that we deal with privacy and handling privacy solutions is you can have an Oracle out to our private blockchain, so you can share as much data with the public blockchain as you want to. It’s all designed to work together. You don’t have to go around and find a bunch of third party solutions to try to do the thing that you’re trying to do.
Meher: You mentioned that there should be only one blockchain and so you’re building this blockchain based off this idea called Chainweb. Do you intend to build these permissioned private blockchains using the work that was done at J.P. Morgan? These will be separate blockchains that connect into this system or has your focused entirely shifted to just a public chain?
Monica: We are still working on the private blockchain. We actually have a healthcare insurance consortium that’s using our private blockchain right now. They have an M.V.P. and they’re working on getting the pilot up and running between these different companies. 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 where a doctor is located and what insurance they’re taking. 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.
Phase one of this project is each of them instead can contribute to this ownerless system where they all benefit from the data. Right now there’s a mechanism in it where everybody pays into the system by running their nodes and then they get rewarded for updating pieces of data. 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. Then they can get rewarded directly so the network can actually sustain itself in terms of data update and storage. This is the kind of idea with a private blockchain that connects to a public blockchain, that really it’s just one project. It’s the project where doctors and insurance companies can communicate with better data but it’s connected to all these different pieces which is a private blockchain with our smart contract language on top that connects to a public blockchain interface.
Monica: 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. 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. The onboarding pipeline for becoming a web developer for example is easy. You go to the store and you buy a computer and then you 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.
We want to get to the place where you don’t have to necessarily understand 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, it is too high. You have to have an opinion on validator nodes and what’s the right structure, do you want to use distributed or do you want to use pBFT or all these things. People hear 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 balderdash around stupid stuff about consensus protocols. That stuff does not matter when you just want people to build something.
I want to get the onramp from people learning about blockchain to building things on blockchain to be way easier. I don’t think that we’re going to end up with one blockchain. In fact, I think that continuing 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 Ethereum and you’ll be able to launch your token on Ethereum but have all of your transactions happen on top of Kadena. That’s the goal.
Meher: Of course you want to build this main public network and because you want it to be accessible to developers of all kinds, you want it to be scalable, right? That’s why Kadena is focusing on scalability for its public chain.
Monica: Yeah. The way that our architecture is set up, we actually get both scalability and security. The design for Chainweb was originally proposed by people not . . . probably the first paper that came out with something like that was for BlockRope which came out and suggested a way of scaling bitcoin for security purposes where you could have two bitcoins that share their proofs with each other which would give you an additional security property. 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 realized that we also get the security feature. Yes, the idea is that you can just put something on Chainweb and not have to worry about whether it’s going to scale out or not.
Meher: Let’s talk about Chainweb and this scalability and security solution. Walk us through how it works.
Monica: I usually do this with diagrams because it’s sometimes hard to visualize and I’m a very visual person, but we can talk about it. Imagine bitcoin and the idea that you have a block. Then your new block that you generate on top of that one has a reference back to the original block. This is the idea of hash linking or having a root or a tree like a Merkle tree. 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 their peer chains’ previous block. Not only do they have a reference to their own previous block, they have a reference to their peer chains’ previous block.
You can see for two chains, this is a lot of messages. You have exactly double the number of references as you do chains and that’s a lot. The way that we scale this is by using a fixed graph structure. At this point, people are like, “This makes you a DAG.” My response is, “All blockchains are a DAG.” All of these projects like Hashgraph and IOTA are what I like to call arbitrary DAGs where they’ll just pick some neighbor that’s listening, that’s ready to receive a piece of information. We have a fixed graph structure where peer chains always communicate to the peer that they’re supposed to talk to. 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 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. That’s like the shortest path between two points, what’s the longest one of those, minimize that number. It allows for the fastest propagation of information out to all of the nodes. This is how we get it to be fast and how we get it to basically communicate with each other in effective manner is by picking a fixed graph structure. For each potential size of Chainweb, of which there are many, many different potential sizes, each of them we get to pick the most efficient structure per size.
I talk about the Petersen 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 two and a diameter of two. That’s two messages per node and two block height to receive full information propagation from any node to any other node.
Meher: Okay. Let’s unpack that. The way I’m thinking of it is imagine two chains, let’s say you have the Litecoin chain and you have the Monero chain.
Monica: We don’t have inoperability between different projects.
Meher: Yeah. It’s not interoperability between different projects.
Meher: What I’m trying to do is essentially start with Litecoin and Monero, strip away things we don’t need like two coins. Let’s strip that away and have one coin. Slowly from that starting point, let’s build Kadena. Let’s just imagine you have Litecoin and Monero and you have two chains. These two chains have two different coins today, one is Litecoin, the other is Monero. Somehow later on in Kadena, we are going to remove the two coins and there’s going to be a single coin.
Monica: Can we just talk about cloning bitcoin instead? Like you have bitcoin and then you have another bitcoin, 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. They’re all completely clones of each other. You have bitcoin and then you have like . . .
Meher: Okay, so there are two bitcoins.
Monica: Bitcoin 1 and bitcoin 2.
Meher: Okay, so you have bitcoin 1 and bitcoin 2 and so you have these two blockchains. Both are producing blocks let’s say at 10 minutes. Now let’s say I’m a miner in bitcoin 1. I’m a miner in that chain. I create a block. What happens differently now in Kadena? In bitcoin, when I create a block in bitcoin 1, I would reference only the previous block of bitcoin 1. What would I do differently in Kadena?
Monica: As a miner, we expect that everybody’s best case scenario would be to mine all of the chains all of the time. As a miner, you’re actually mining both bitcoin 1 and bitcoin 2. You’re trying to get a success on both chains, which from 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 to generating the same block, there’s a non-zero possibility that you get a success on two of your threads at the same time, in which case you’ve wasted a bunch of hash power and you have to throw one of them away. Instead, we posit that people are going to try to mine as many chains as possible, all at the same time because then they can have more potential successes all at the same time. You as a miner would mine both bitcoin 1 and bitcoin 2 and you’re just hammering away at both of them at the same time.
Meher: For example if I have 100 ASIC machines, I’m putting 50 ASIC machines on bitcoin 1 and the other 50 on bitcoin 2.
Monica: Sure, yeah. If you’re mining bitcoin 1, your block that you’re attempting to solve has in its header a reference to both the previous block in bitcoin 1 and the previous block on bitcoin 2.
Meher: Okay, so I create a block on bitcoin 1 and it says when this block comes in, it references the previous block in bitcoin 1 and then it also says the last block that I heard of in bitcoin 2 was this, so put that in as well.
Meher: Similarly, some other miner that generates a block in bitcoin 2 would have listened about my block in bitcoin 1 and they would put my hash of this block in bitcoin 1 in their block when they create one in bitcoin 2.
Monica: Yes, exactly.
Meher: Information about each block in bitcoin 2 ends up entering the bitcoin 1 blockchain and information about each block in the bitcoin 1 chain ends up entering bitcoin 2?
Monica: Yes, exactly. The benefit of doing this is twofold. 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 . . . if there are two potential blocks on bitcoin 1 and you’re a miner on bitcoin 2, 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 1 in your next block. It’s a way of forcing forks to recombine faster because if there’s a fork on bitcoin 1, not only do the bitcoin 1 miners have to pick one but also all of the other peer chains, in this case bitcoin 2, have to pick one which forces people to make decisions which is what resolves forks. That’s one reason.
The other reason is this is how we propagate state between chains and which we do through simple payment verification. We’re an account based, not UTXO based. If I have an account on bitcoin 1 and I want to pay you but you’re on bitcoin 2, the way that we do that is we write a smart contract, I hate the term smart contract but we can call it a smart contract, between the two of us on bitcoin 1 in which I say like, “I’m going to pay Meher one token,” and then it is signed to your account on bitcoin 2 and then we put that in on bitcoin 1. The proof of it propagates in the next block to bitcoin 2, at which point you say, “Hey, I’m going to redeem my half of the smart contract on bitcoin 2.” I have destroyed the coins on bitcoin 1 and they’re gone, and then you redeem which consumes the transaction I.D. for your half of the redemption for that smart contract. Then the coins get created on bitcoin 2.
You could potentially have a case in which there is a chain that has no tokens on it because it has no accounts or they’re all empty. Another chain could have all of the tokens and it doesn’t matter because each chain maintains its own idea of state. This is how we pass information from chain to chain.
Sebastien: On that topic, you mentioned earlier that as a miner, you should be mining on many chains. If we stay on this example of bitcoin 1 and bitcoin 2 and we extend that example to now bitcoin N, so presumably there’s hundreds of chains perhaps. As a miner, I’m distributing my hashing power amongst all these chains. Doesn’t that create a bandwidth issue? Because scalability in blockchain is fundamentally a networking issue, it’s an issue of having sufficient bandwidth to propagate blocks quickly enough so that everybody can come to consensus around what is the actual state of the chain. If I’m a miner and I’m mining 100 chains, that not only consumes a lot of bandwidth on a network but it creates congestion even at the entry point of my router or the switch in my networking facility. How does Chainweb address this?
Monica: First we make the assumption that large mining pools exist, which I think that the crypto-anarchist who wants to believe that all bitcoin is mined by individual hackers with a G.P.U. or something in their closet is it’s a fallacy. We need to accept the fact that large mining pools exist and they are going to mine the whole web because they can. They are essentially going to perform the function of coordinating the header stream. The header stream is just these messages that go across the network that say like, “Hey, I found a block and here’s the hash of that block.” The header stream itself is very lightweight because it’s very small hashes that are being passed to each other.
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’re 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 them if they ever put out a hash that’s not valid, then 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.
Sebastien: I don’t know that that actually solves the networking problem at the network level. Potentially small mining operations or individual miners might only mine one chain but the broader issue is that the entire network needs to be able to visualize the state and if those smaller miners or miners in remote areas that don’t have the bandwidth can’t access the information, so how do we secure the chain on that sense?
Monica: 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. They’re only the number of messages going from chain to chain that are the degree number of messages in the network. For the Petersen graph for example, which is 10 chains, for every node, that sends two additional messages. I guess I don’t really understand your question.
Meher: I think Sebastien’s question is, so today we have bitcoin and today bitcoin block size is 1 MB, right? Every 10 minutes, if I’m a bitcoin miner, I must get 1 MB worth of data very quickly and build on top of it. 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, I can scale bitcoin by increasing the block size, so if you increase the block size from 1 MB to 100 MB, now I need to get this 100 MB of data very quickly in order to be competitive. What Sebastien is saying is traditionally when we talk about scaling, we want to reduce this requirement of 100 MB to something much lower.
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 10 MB. But in Kadena, it feels like because if I’m a Kadena miner and let’s say I’m mining bitcoin 1 and bitcoin 2, I would need to get 100 MB for bitcoin 1 and I would need to get 100 MB for bitcoin 2.
Monica: But you don’t need the 100 MB for bitcoin 2. All you need is 1 byte or 64 bytes for the . . .
Meher: But your assumption is each mining pool is mining all of the networks, so they’re mining bitcoin 1 as well as bitcoin 2. If I need to actually mine both those networks, I need to get data from both chains, so it doesn’t solve scaling because all it is equal into is an increase in block size. I could increase bitcoin’s block size from 100 MB to 200 MB or I could split it into two networks, bitcoin 1 and bitcoin 2 of 100 MB each. In both cases, I need to get the 200 MB of data in order to actually run my mining operation.
Monica: 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. You don’t have to mine 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 success, in which case if we’re using 200 as our example, then you would only need 100 megs from the previous block. All of the others, you could just listen in for. If bandwidth is your problem, then you can only subscribe to a subset.
Meher: Yes. Actually, that makes total sense. The tradeoff is if I as a miner need to mine all the chains, then I need to get the data of all the chains. If all miners are forced to get the data of all the chains, Kadena boils down to a single blockchain with an extremely large block size, so that’s not scalable. The point at which Kadena would be scalable is if I . . . if me as a miner is given the choice of needing to mine only one chain and forgetting about the other chain. And then I need to listen to only one chain, listen to a smaller data stream, and other miners can work on that other chain, and then there is scalability. I actually agree that, yeah, that’s the fundamental trade-off, but in order for the system like Kadena to actually scale, really scale, you would need to concentrate miners into certain chains.
Like, hey, miners 35, 39, and 38, focus on blockchain number 23. You, five miners, focus on some other chain and so on. Would you agree with that?
Monica: 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 Markov simulations on 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 receive the last . . . the least attention last round. And with that, as . . . I mean, 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.
Sebastien: But for my perspective, I think bandwidth is due to the fundamental barrier to the scalability at the lowest level. I mean, any solution that we try to build on top of an existing blockchain in to create more efficient watching systems whether it’d be proof of work or proof of stake, what we’re trying to do essentially is minimize the amount of bandwidth that needs to go from validators that maintain the chain. That for me, it’s a fundamental thing in the scalability discussion at a broader sense that most people are not addressing. We’ve had some . . . we had a project done recently, bloXroute, it’s building a content distribution network for blockchains. That addresses this issue at the fundamental network level.
But I haven’t seen any other projects, at least, the ones that we had on that look at scaling from this perspective. Now, you written a whitepaper which describes the different attack vectors possible with Chainweb and the ways to mitigate them. Could you run us through some of these and how you’re mitigating those attack vectors?
Monica: Sure. The first one that we started looking at because it’s like the fundamental, and the first one described in the Bitcoin whitepaper, and all this is about 51% attacks and how 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 2 has the hash of Bitcoin 1 in 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 pure chains that reference it also getting buried.
You start having to not only replace at any given chain, but you also have to replace any pure chains that happen to reference it. 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 [peer] [00:46:48] 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 exponentially fall behind in terms of that attack that that’s not really a feasible situation. Well, that was the first one that we looked at. This is the whole . . . the black rope originally produced this chain sharing each other’s hashes as a security measure, that’s how that really gets exposed.
But that’s how we come up with the term. We use the term “Merkle cone” because it’s like Merkle tree but it has an additional dimension on top of it. Because of the way that the Merkel cone propagates exponentially across all these different peer chains, double-spend attacks are very hard.
Meher: Okay. That sounds like an interesting proposition. Let’s say you have a Kadena network, and you have 10 chains in this Kadena network, right? And the total mining power in this whole network is X, like X[terahashes, or X whatever unit, right? You can think of it like thousand terahashes, some large number. And then you have Kadena chain one K1, you have Kadena chain two, K2, and you have until Kadena chain 10, K10. And the total hashing power is thousand terahashes. Is it the case that Kadena one gets 100 terahash, Kadena 2 gets 200 terahash, and these thousand are distributed equally between the chains? Or how does mining power get distributed across these chains?
Monica: It’s the miner’s 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 model for the network graph and then building the miner graph and then having them run through simulations on how they would mine, we pause it 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 roughly equal because any chain that you think has less hash power becomes an attractive target. 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 stabilize.
There also the fact that you have to wait for the blocks to be finished on your peer chains before you can include their proofs in your header, it’s 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 chain can only fall diameter number of blocks behind before it starts to slow everybody else down, which then causes people to dogpile onto the chain that’s holding them back. This is the balancing network. We’’ve given this event horizon of blocks various names. Our lead chain of engineer calls it the “cut-set” which I think is a weird term.
I was calling it the meniscus for a while, nobody likes that one, nobody liked the meniscus. I’m going with event horizon for now, which is 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.
Meher: That’s an interesting idea. The basic idea is that you somehow you have these 10 chains and you somehow want these chains to progress at similar speeds. If a block is created here, you want the other chains to create blocks. And so what you’re effectively doing is you are somehow incentivizing the miners to switch to the slowest chain so that the whole system can make progress and when the miners switch to the slowest chain automatically the hash power distributes equally. You start with, let’s say, a thousand terahashes and you end up with a system where there’s like 100 terahashes equally across all the chains, right?
Monica: Right. Yeah.
Meher: It won’t be exactly equal, but some might have 80, some might have 120, that but if you will aim to get like somewhat equal distribution. Now, the question becomes that suppose now I’m a miner on chain five, so I’m a miner on chain five and I’m a large miner. And now chain five has 80 terahashes, right? Now I’m a large miner and right now I’m not mining Kadena but my mining capacity is 100 terahashes, right? I can 51% attack chain five, because those guys are 80 and I have 100 pointed waiting to go. What I’d do here is I’d say, okay, let me put those 100 on just chain five and let me just create one invalid 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 five. 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 their next block. And so my block becomes canonical. Do you think this is a problem?
Monica: The way that that would become resolved in Chainweb is like you’re not the only miner on chain five, somebody else will attempt to validate your block as a way of putting the next block on top of chain five and see that your block isn’t actually valid. In which case they will suggest this as an alternative, and since people are mining, like you would mine a subset of chains, mine like chains five, six, and seven, then somebody who is mining five, six, and seven sees that five is actually not a valid block and will suggest an alternative block and include that in six and seven. And then whoever is also mining six and seven will see this other proposed block five and that it’s not included in this other proposed block six, which will then cause them to reject that block five and the block six that includes a reference to the bad block five.
This idea that a bad block would never be validated by another miner is like, I think, the core of why that doesn’t necessarily work.
Meher: What you’re saying is now you’re going to use the other chains as a judiciary of kind, right? I’m the big bad attacker, and let’s say Sebastien represent the honest miners of chain five. I’m the attacker of chain five. And so I was fast because I have more hashing power, I produce the block quickly and broadcast quickly. Now you’re saying like, “Oh, Sebastien will also create a competing block and try to broadcast it.”
Meher: Now, the whole network, chains one to ten, must decide is Meher’s block canonical or Sebastien’s block canonical? The whole network in some senses needs to become a judiciary, right?
Meher: But they can be a judiciary only if they store the whole blockchain of chain five.
Monica: But only if they’re mining a subset of any connected subset of the network. Like five, six, and seven, or three, four, and five, or . . . because . . .
Meher: Let’s say I propagate my hash from one to eight, chains one to eight hear my thing. And Sebastien honest thing goes only to nine and ten. I win.
Monica: Well . . . but then, it’ll go to nine and ten and then nine will have to reconcile with eight. And then you’ll have to go and you’ll pick which one of these, either nine or eight. 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 mined one chain, then we would have a problem, but because it’s designed for people to hop between chains and mine more than one chain it forces them to reconcile with each other.
Meher: I mean, let’s move onto some other topic, but I feel like the fundamental issue with Kadena is exactly this. It is that in order for reconciliation to work you start to need bigger and bigger juries and ultimately you’ll 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.
Monica: I don’t think that everybody needs to mine every chain but that’s a fair critique.
Meher: Yeah. Okay. Let’s move on to the next thing, Sebastien.
Sebastien: I wanted to come back to this earlier in her discussion, but we got sidetracked with these other topics. But there’s one passage in the whitepaper that struck me and I wanted to maybe get you to perhaps explain it in your own words. On page two there’s a section where you talked about proof of stake and proof of work. And you argued that proof of stake validators would be subject to money transmitter regulation at least in the U.S. as it reads here. Can you expand on this logic and what evidence you have to support this claim that proof of stake validators would likely be subject to money transmitter regulations?
Monica: Sure. This is the reason that we take this position is the idea that right now, 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 especially in the United States where these takings take forever and people debate about them for a long time. That trying to pass new laws for blockchain is going to take a while. 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 blockchain 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.
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 miner who doesn’t look like what the law already considers to be a money transmitter.
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. That’s why we’re concerned about validation in general. Like all of these services where a fund is trying to turn their fund into being a validator unlike EOS or something where they then clear a transaction that then causes, I don’t know, something illegal, that they could be held liable for it.
Sebastien: I mean, don’t you think that if this were the case, if regulators really wanted to go after Bitcoin, I mean Bitcoin in the eyes of U.S. regulators, I would say, I mean to some extent, perhaps not everyone, but to some extent, Bitcoin is seen as a currency where a lot of illicit transactions occur or at least have occurred in the past. Don’t you think that regulators could just go after mining pools because we know we’re mining is concentrated where they could force mining pools to do KYC on the miners that access the pool?
Monica: 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 our stance on it, that validating looks really similar to existing legislation and my mining does not.
Sebastien: Meher, I think you’ll have a lot to say about this.
Meher: Yeah, and this is because likely validated is identified with one public key, whereas, a miner is not.
Monica: Yeah, or that a miner 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 staking money in the network. It’s this like staking thing that is the problem, because then it looks like being having a money transmitter license is like 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 to look like.
Sebastien: Yeah, but I would say the obfuscation of identity that you have in Bitcoin mining can be . . . I mean you can replicate that obfuscation in proof is stake as well. I mean you may have a key but you can pretty easily, I would say, change that key for the next round of validations. And the validator that’s taking stake from delegators doesn’t necessarily have the identity unless we’re doing some sort of KYC of the delegators themselves. I mean . . .
Monica: It’s the probabilistic nature of proof of work that really gives it the slipperiness, because as a Bitcoin miner there’s always a nonzero chance that the block that you confirmed might not actually be the real confirmation. It’s this invalidating you actually have to vote and then the vote is confirmed and you 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.
Meher: That’s a very interesting argument I must say. And that’s an entirely new way of looking at it. 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 hundred percent sure it was going to be included in the Bitcoin blockchain. It could have beenorphaned. 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. Let’s say like the voting has happened and I cast the determining vote that finalized that block.
Then what I’m essentially doing is in the process of voting I’m 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.
Meher: That’s super interesting I must say. I don’t know if the regulators are going to look at it like this or not, who knows, but . . .
Monica: I mean that’s our interpreted . . . we just think that proof of work is safer because it has this other dimensional element to it. And I really don’t want to go to jail.
Meher: I’m sure the proof of stake designers, like in Cosmos, so I’m actually building the Cosmos validator, this is a topic that’s actually really close to my heart. In Cosmos, yes, like the validator, it could be doing things that are like casting votes. It’s like in Cosmos, 66% of the network has to cast a yes vote for the block to go in the chain and be final. Let’s say 65% has done, and then my validator casts that decisive vote that switches it over to 66%, and then creates a new block that takes that vote as final, then maybe they could be this element that yes, I did put the deciding vote in there. The validator did put deciding vote in there. But I think if you look at something like Tezos, that argument would be quite weak in Tezos because in Tezos 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. 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 Tezos it’s like Bitcoin where you need 10 things to come on top of yours before it gets considered final. If that’s the argument, then Tezos maker is fine but the Cosmos validator may not be. That will be quite interesting.
Monica: I actually love Cosmos. I think Cosmos is a great project. And I think Zaki is amazing and their whole team is great. Just because we’re not proof of stake doesn’t mean that necessarily we’re fundamentally theologically opposed to proof of stake.
Sebastien: If we look at the blockchain ecosystem at the moment we can start to discern some applications and use cases for each one. Bitcoin is shaping up to be a digital gold, an asset that you keep and that will gain value within the future. Ethereum is shaping up to be, at least, in the initial use case is in project funding, etcetera. What is the used case here for Chainweb? What’s the application that you’re hoping will emerge as the killer application for Chainweb?
Monica: I like to talk about the blockchain as a stack where for example if you’re going to launch a project, and you wanted to do a token sale, and then you wanted 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 run through Chainweb because we pause it 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 Ethereum, you’re 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 ETH 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.
Sebastien: We’re very conscious of your time here and we want to spend some time on Pact, but I think we might have to leave that for a future episode.
Monica: Okay. Give me like two minutes on Pact.
Sebastien: Okay. Sure. Yeah.
Monica: Because it’s really cool and really everybody should go and take a look at it. The developer SDKs are up. You can treat your computer as if it were a tiny node. I’m right Pact right now. We’ve taken basically the completely opposite track from solidity and all of this virtual machine land where we’re trying to replicate an entire computer on a blockchain. It is non-turning-complete on purpose. It’s more sequel for the blockchain instead of sequel for database. We have Pact for blockchain. And it has all the things like key signatures and governance and who owns what and who can change what, all of 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 program what an ERC-20 should look like and give it a bunch of specs. And then if somebody implements it incorrectly it will warn them like, “Oh, your ERC-20 equivalent is actually malformed.” You can’t have like . . . we did the summer a bunch of like bad ERC-20s that come out. All of that stuff all built in already. Pact is, I could spend a whole another hour talking about it, but I can talk about it another time.
Sebastien: Yeah. Well, perhaps we can have you in the future to go more in depth on Pact, because I mean Chainweb did take a while to on unpack here on Pact.
Sebastien: I did want to spend some time on Kadena and your private blockchain offering. How does Kadena interact with Chainweb and what’s the goal here with regards to the types of clients that you’re approaching with this platform?
Monica: Yeah. We have two signed clients right now that we’re working with. One of them is this healthcare insurance project that 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 it’s a way of unlocking existing business value in a new way, new liquidity pipeline. I talked about the health insurance one where you can pay doctors to update their own information. We’ve also talked to a bunch of different companies, some of them are cooler than others. Our other big client right now is a reinsurance company that does insurance products.
They do like home insurance and stuff. And so we’ve been discussing with them something where they can have a broader pipeline for validating their auditor data. Using like 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. 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. 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, 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. We have this idea that there’s not private and public, there’s just one blockchain with different permissions.
Sebastien: To touch on this, in the whitepaper, there’s a part there where it references the scalability benefits of Kadena in a private setting and it makes reference to five to fifteen thousand nodes as being the threshold where it begins to exhibit linear scalability, which is expected at some point that your system is going to stop scaling exponentially and more linearly. But given that a network like Bitcoin as I just looked up earlier has about 10,000 nodes, at what point does a network go from being a private network to just being another public network? Does it preserve the benefits that the initial consortium or set of clients set out to implement? And where’s the line there where you switch from being one to the other?
Monica: Um-hum. 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 our other options for people trying to do private blockchain right now or like Hyperledger that doesn’t scale past four nodes and Corda which isn’t even really a blockchain, and all of these other private blockchain technologies. We fundamentally believe that we have a better private blockchain than 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.
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 permissioned 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 mutual fund portfolios, it’s not treasury bonds but it’s like treasury bonds. They want to create a tokenized representation of one of their funds. That would be a public representation of a private blockchain that represents an asset. If that makes any sense.
Sebastien: I wanted to take some minute o to ask you your thoughts and opinions about where we stand right now with regards to enterprise blockchain, permissioned blockchain, what have you. Previously I co-founded a company that sold, I guess, enterprise blockchain solutions for traceability to do the large insurance companies, companies in the finance sector. And I came out of that with having been confronted with the challenge of implementing blockchain in enterprise, skeptical to where things are going in the space right now. And I could point here a few things. Mainly is that blockchain is orthogonal to a lot of the business models in finance. And most of the financial sector whether it’d be insurance, or banking, or financial services.
And although, a lot of the companies obviously are paying attention to blockchain and experimenting with proof of concepts, etcetera. None of that has really panned out. And we’ve been saying for about three years 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 what they’re going to do next.
Why is Kadena different in a sense? And what’s your go-to-market strategy for bringing customers onboard, consortiums onboard, and then converting them over to this public . . . this more public network as you described it?
Monica: Our vision for Kadena as a whole is that because of how our smart contracts function you can essentially create importable services. Stick with me here and I’m going to tie it back to enterprise, but imagine on the public chain that you have building block services that provide a network that gives you a lot of flexibility. 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 onto the consumers end, which sucks.
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 micro transaction fee you pay the verifier of the background check directly through the smart contract. You would have some 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.
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. Imagine like, I don’t know, Chase Bank. Chase Bank already has a 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.
It’s like applying the sharing economy to the components that already make up very large businesses. This is a way of onboarding Chase Bank onto enterprise blockchain. I’m not saying like, “Dear, 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 than they are to try to rip out 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.
Sebastien: I get that and I think that’s the fundamental issue here and that’s the fundamental problems with the whole premise of enterprise blockchain is that it is orthogonal to try to get Chase Bank to monetize an existing service is really orthogonal to the way that they already do business, especially when you’re opening it up on a public network. And I think that coming away from my experience in my previous company that it’s not so much a technological issue, it’s not so much about the technology. It’s really a change management issue. And that all this evangelism that all of us have been doing for 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 what is the future of identity?
What is the future of payments? What is the future of insurance? What is that going to look like in the future? And currently, I think, most people that are addressing, that are talking to innovation departments like banks and financial services companies, insurance, what have you, are not really doing this. They’re still spending time saying, “Oh, I mean look, you could take this existing thing, plug a blockchain into it, and then start making money in the secret system that doesn’t exist yet.” I guess, my question remains, what is really the go-to-market strategy, have you identified some key industries or types of clients where you can take Kadena and really provide an out-of-the-box solution to generate revenue and to prove these use cases, right? Because the proof is in the pudding.
Monica: 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 some companies, pay people to use POCs. 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,” and 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 consulting.” And if people aren’t ready to go, we’re not going to work with them. But right now, people are coming to us. They say that we have a thing that works. We do.
Sebastien: What’s the road map in the next . . . you mentioned earlier an SDK, where people can already start using the platform. Can you talk more about that?
Monica: Sure. We’ve got two teams right now working on both the language development and tooling for developers and another team that’s working on Chainweb and protocol development. And so we’ve split them into two test nets. We’re right now working on both of them at the same time. The Pact test net is 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 Kadena will be like.
And then meanwhile, we’re working on Chainweb test net which should be up by the end of the year, which it’s basically just a way of testing how blocks get generated and forks get resolved in the consensus mechanism. And then we’re going to merge them to create a unified test net where then the goal is to have the main net launched around the second quarter of next year.
Sebastien: Great. We’ll have links to all that in the show notes. If people are interested they can go to Kadena website, read the whitepapers which you’ve co-written with your co-founders and learn more about how Kadena will be building up this Chainweb network and then also implementing their technologies in enterprise. Thanks, Monica, for coming on the show today.
Monica: Thanks, guys. This is great.