Episode 408 - Minimmit, Multimmit and the New Consensus Frontier with Patrick O'Grady

Transcript

Welcome to Zero Knowledge. I'm your host, Anna Rose. In this podcast, we will be exploring the latest in zero knowledge research and the decentralized web, as well as new paradigms that promise to change the way we interact and transact online. This week, GMO and I chat with Patrick O'Grady, founder of Commonwe. Patrick shared with us his path into the space, being introduced early to Bitcoin, then joining Coinbase, and then several years working on protocol at Avalanche, and what led him to start Commonweable primitives for building blockchains. In

this episode, we explore the Commonwe design philosophy that is allowing builders to customize at all layers of the stack. The bulk of our conversation is on the research that the Commonwe team has done on consensus. Patrick walks us through how a shift in the industry's fall tolerance assumptions opened up faster designs and discusses two protocols Commonwe has published in response. That is Minimmit and Multimit. This is very much a catchup for me on consensus research. So, it's very cool to hear what's happened since. I hope you enjoy. Now, here is our episode with Patrick O'Grady from Commonwe.

So, today GMO and I are here with Patrick O'Grady, founder of Commonwear. Welcome to the show, Patrick. >> Thanks for having me. Long long time listener, first- time caller, so this should be uh fun. >> Yeah. >> Nice. Hi, GMO. How are you doing? >> Ah, it's been a hot talk. Doing well. >> Cool. So, this episode came together. I think actually Zucky was the re he recommended I bring you on. He spoke to you and then I mentioned to GMO that I was having you on and GMO you were like, "Yeah, >> yeah, I love Pat." >> And Patrick, you were interviewing GMO last time you guys met or something.

>> Just depends on what side of the table you're on, right? Yeah. No, >> of the turns table, you know. It's uh something. >> Yeah. But no, GMO and Alex were the first guests on our podcast we run. Um, and so had a great time. Enjoyed having my mind blown my mind blown by some of the mathy stuff they were doing at that time. So yeah, hoping hoping to repay the favor at least in small terms. Yeah, we'll see. >> Cool. Cool. So Patrick, let's get to know you a little bit. What were you working on before? What led you to build Commonwe? And then we're going to dive in after that into what is CommonWear.

Yeah. So, I uh I grew up in Wisconsin, so far away from all of this fancy schmancy blockchain consensus stuff. So, I think like Olaf in his origin story talks about how he was like a lumberjack in Minnesota and somehow found out about Bitcoin. Yeah, I was I was not as lucky in Wisconsin. So, I I didn't really know about it much until uh I came out to school in Palo Alto, learned about it out here and got really really nerd sniped in it as pretty much right away as long as I can remember. Actually, funny enough, I first got into it. It had no personal impact on me, but it was during the Greece kind of like debt crisis where they were limiting withdrawals of uh Greek citizens because of like the currency crisis. And then

there was this Bloomberg article I saw that was like, "Yeah, people can still withdraw their money from these Bitcoin ATMs." And I was like, >> I totally get it. This is so wild. I have no need for this at that time. But like, wow, this is sick. What year are we thinking here? >> I first got into it in like 2014 time timeline. >> Pretty early. >> It was a long time ago. You have to give me some credit because I that was when I was 18. So like any earlier I think would have given me like the high school discount or whatever like that. But >> yeah, then I was like, "Oh, this is crazy." So I took all the money I had, which was like $2,000, and like bought some bitcoins. And then it like doubled in price from like >> 300 or 150 to 300 bucks. And I sold it

all. And I was like, "This is crazy." And so, and here we are now at $60,000, whatever. So, >> I'm not a trader. I'm an engineer. And even if I had not sold it, then I there's no way I would have held, you know, but in any case, that's how I got interested originally was actually like learning about how there were people around that had basically couldn't access their owner, like their possessions and stuff like that. And that clicked with me as like a a motivating factor, I think, basically. So went did the whole college thing at Stanford.

>> I think we met not too long after that episode by the way. I I actually don't remember. >> Was it 16 or 17 or something like that? I think when we met >> I think it would have been my sophomore year I think. So it would have been Yeah. So probably 15 or 16. >> 16. Yeah. Yeah. >> Yeah. So did that like learned how to become an engineer. Had a lot of fun at Stanford. But ultimately you know when I was graduating I thought you know I should probably get a real job. I started to like interview at a bunch of like SAS companies and like you know because I like SAS back then even pre AAI was like you know like docu collaborative document editor right like I was like oh it's going to be sick and then I was funny enough I was actually

leaving the engineering school one day and there was like free tacos outside which is often what these like recruiting things do to you know get the get those students attention right so I walked up and yeah >> I don't know I was I literally was like what do I got to do to get some free tacos and it was a A16Z recruit recruit her and she was like, "Well, all you got to do is like, you know, give us your resume on this whatever platform thing they had built." And I was like, "Okay." So, I clicked through some stuff. Literally didn't click anything crypto. And then she called back like a a day later and was like, "Hey, like I know you didn't click anything crypto, but I think you'd be a perfect fit for Coinbase given the stuff you'd been doing."

>> Wow. >> And so I was like, "Ah, I don't know. Like I got to get a real job. Like I got to graduate." And then I I went to Coinbase. Funny enough, I was late for my interview. So, I showed up 15 minutes late. Um, ended up uh, fortunately passing the first few technical interviews there in hilarious fashion, which we can talk about later, but passing it, but then I ended up getting an offer and decided after calling a few people that were like, "Hey, yeah, like cuz it was like Bitcoin was down like 80 90% from that point from whatever."

>> What year is this? Are we talking 2016? No, I this would have been in like 2018ish. Yeah, 2018, 2019. >> Like basically the 2017 runup, I've been like messing around like doing a bunch of random stuff and then yeah, had come down. So like basically this was another case of like Bitcoin is dead, right? >> And so everyone I talked to was like, "Yeah, you probably shouldn't do that." Like half the engineering team at Coinbase had just left. Um, but then ultimately I came to the conclusion that like well, you know, money or like value over bits is like too good of an idea for this not to work. Um, and if if it does work, Coinbase is going to somehow be related to that.

>> Yeah. >> And they have at least somewhat of a reasonable engineering culture so that if it does go belly up, at least I think I'll be able to get another job too. Yeah. Okay. So then I decided to take it, joined Coinbase and so yeah, worked there for just under two years or so on the what was called the crypto engineering team or crypto platform team. And so what we did was oversee anything that touched crypto like the blockchain itself. >> Now you would think from the outside looking in like wow Coinbase that's like what they do that must be like the biggest team at the company. No.

>> So when I joined it was about 20 people and we maintained everything that touched blockchain at Coinbase. So that was like cold storage that was like management of you know >> depinbase at the time roughly do you know >> at that point I think there were 200 engineers left >> okay damn >> so most of them were working on like front end stuff >> well I mean so you have to imagine like Coinbase is a huge product suite right like there's like custody there's like markets trading there's like the wall like and it wasn't meant to be that thin right but like the market had you know a lot of people had given up lately and so it was a wild time to be there. So like my first week my boss quit uh team was reorged >> but you know like I think what they

what's that term from Game of Thrones like chaos is a ladder or whatever like that. So um basically the people that were left were amazing. >> Yeah. >> Like just they were there for the right reasons and they were incredible engineers and fortunately they were generous enough to take me under their wing and really mentor me and teach me. And I mean you think you know crypto and then you go to Coinbase you didn't know crypto. like there's nothing quite like, you know, quite like moving hundreds of millions of dollars on chain. So, and and having confidence that that's not going to be, you know, you're not going to lose the money is a whole different different world.

>> So, yeah, really got deeper into it there. While I was there, I worked on a project that I that I started called Rosetta, which is like a universal read and write abstraction for interacting with blockchains. Um, and so the goal was like, how can we basically accelerate listings on Coinbase by making more of the integration asset issuer driven rather than Coinbase trying to figure out how to integrate your chain and so like automating integration and testing and yeah, Coinbase uses that today. I don't know if they still do, but for a long time for any asset that was listed on Coinbase had to implement the specification I was working on.

>> So that was a great way for me to like really get deep into all these protocols and like talking to them about like how you would actually implement the spec. Some things I'm responsible for that people may not be aware of. I requested that Salana add timestamps. I requested that Cosmos add atomic balance lookups and a number of other protocol breaking changes that got into Hub 3. Yeah, there there's a longer list, but we'll keep that where it is. But ultimately to figure out ways to integrate certain assets that never really were designed for maybe like production grade integration and what it requires from like law enforcement and all these different things. And so it was it was an interesting experience but ultimately left with like well it got to the point where I was like hm you know it's really

cool integrating with these chains but it would be fun to be on the other side. >> So you made you made a leap at one point you headed over to the other side to go deeper. And which chain did you choose? >> So yeah when I was at Coinbase at this time literally I was I literally had told my boss you know the week before like yeah I'm really loving this like the Rosetta stuff. I feel like I have a ton of opportunity and ownership to grow my career and then some people reached out on Twitter from Avalanche and I was like well maybe maybe I should do the protocol thing and um >> so this was right after avalanche launched mainet so this would have been in 2020 and you know I was like oh you know I'll you know I'll spend another

year or two working on this Rosetta thing on Coinbase like try to stay like three or four years and then you know go for maybe moving deeper in the protocol layer and basically when I was talking to professor like Emmanur and then Kevin who was one of the co-founders there they actually made a really compelling case that was like hey actually this is the time to go if you want to do meaningful protocol work because like basically the protocol growth seemed to happen in like waves >> and so at that time was basically when there was a lot of investment into like this whole like >> heterogeneous scaling technique so like you know polka dot was about to come live file coin was about to go live like and so they're like hey if you want to come in like there's not going to be

another chance for like you know a couple more years so like it's now or you wait a while >> there. And there was so much research to do and so much implementation experimentation. I just I like you talk about that time and it's I have nostalgia for that. >> Wild time. It was just >> and there like all those chains you're talking about were also com competing at times brutally with one another. >> There was like camps you're if you were in the AVA camp you maybe weren't as invited to the polka dot camp or what have you. Um, all of this now looking back seems kind of funny, but like at the time it was pretty serious.

>> Well, because that's funny because it's that's around the time I actually met you the first time was at I think we were talking about this like this Polka Dot meetup in San Francisco when I was still at Coinbase cuz I led the integration of Polka Dot. And so I got really deep into that and how that worked. And so I was like learning a bit more about the Polka Dot ecosystem and like what it was. So I came at it from a different perspective which was like I'm not a maxi. I'm like I actually really enjoyed learning about the differences of all these protocols but I just wanted to to actually like do it myself like if someone was to actually go build something. So yeah, long story short, thought like basically Avalanche at that time was super interesting because one proof ofstake protocols were not big.

>> So you're talking like 20 maybe 100 nodes and so Avalanche, you know, proposed a whole different architecture to really scale up the participation which >> yes, I remember it was like 600 nodes or something right? >> I think at one point we got up to a couple thousand validating nodes which was I mean you know if you're coming from proof of work and you're like you know Bitcoin and Ethereum at that time, right? It's like this is the robust thing where you have tons of people. Proof of stake was like oh no Libra 20 nodes like Cosmos 50 >> nodes a different tier. And so I was like if this is going to be taken seriously with like the the properties that proof of stake has we need to be bigger. Obviously we've a lot of research has come out since then of how

to even make it you know scalable with traditional PBFT things but at that time totally crazy. And then the other thing was I thought that you know people don't agree on anything. the idea that somehow blockchain is the place where all of a sudden we agree to have one single Mondo chain, not a realistic outcome. And so in that case, you're going to want to have like native interoperability. And so at that point in time with where cryptography was at, the solution proposed by Avalanche also was something that I thought was really interesting of like having this like heterogeneous zone thing that was kind of connected.

>> Yeah. Yeah. I do want to understand where the kind of initial idea for commonware comes about. Is that in your time in Coinbase or was it already in AVA or Yeah. >> Yeah. Where common comes in is basically after spending like three and a half years at Avalanche like in getting deeper into the protocol building a bunch of different things I started to have different views guess I guess on like what what I thought the best engineers would be doing over the next decade. And so that's where Commerce the idea started. So, you know, if you talk to great folks and you're like, hey, you know, you your job, you know, your your task is to build this like really

compelling product and you're like, "Yeah, except like there's all these constraints that to you probably sound pretty arbitrary, which is like you can't, you know, you can't change execution in that way. You can't like change the pering in a certain way. You can't do storage in a certain way." And like now like do the best you can. Like I don't know any engineers that are just kind of like oh yeah I'm not going to touch and tweak and like try to work around all these things. >> It's not a it's not a thought process you go through if you talk to great engineers. And so usually it's a product of compromise that people would you know deploy things on all these like pretty standard virtual machines that don't touch the layers beneath. And and I think for a while people thought and many people still do that virtual

machines for blockchains can more or less replicate operating systems and like the experience people have deploying on operating systems where like everything beneath it like maybe it's not optimal but it's good enough for you right like we don't have an Excel laptop and a word laptop and like you know we're able to run all these programs on the same you kind of backbone >> and I think for a long time that was pretty clear but then as things scale up you know throughput and as you try to reduce latency. You got to make more compelling tradeoffs where you can't just have general everything all the way up and down the stack. And the problem is today's frameworks or like even at that time like not built for that. In fact, you were pretty much actively encouraged not to do that sort of thing cuz like you know you don't fork the

framework, you're going to introduce your own bugs, you're going to mess this thing up. Like definitely don't do that. And so the idea with commonware was like well what if we did do that? what would we do differently and how would we design like the actual architecture >> to allow you to tune and tweak everything to best showcase your application? And so with what we're doing at Avalanche, like it was pretty it became pretty focused on the EVM and basically running a bunch of EVMs that could communicate with each other. And I think like there's definitely obviously product demand for an EVM, but I thought that the best applications over the next decade would would think more broadly about the problem and uh would would would benefit from more interesting

capabilities. And so with Commonware, the idea was like, could we build a tool kit of Legos that you could actually compose in a bunch of different ways without like going crazy in terms of like complexity or bugs or any of these sort of things to make the best applications better? you described it. I mean, I was reading a bit of the old blog post as like the anti framework, but as you describe it, part of me can't help but wonder, is it similar to like the Cosmos SDK or like the the po because a lot of the networks had these frame like these sort of underlying things that you were supposed to be able to customize, especially if you were launching like a chain.

>> Yeah. So, I think if you look at commonware, you know, on like if you look at 10,000 ft, you could be like, does it help you build your chain? Yes. So like is that the same as like Cosmos or Polka Dot or whatever? Like and I think a lot of people come to us and like that's like the 10,000 foot comp. >> Yeah. >> But if you look at commonware actually what it does >> it diverges sharply from a lot of those other implementations. So like we give you control over everything like how the P2P layer works like how how you even form connections on the network layer, how consensus plugs into that, how you then define execution on top of that consensus or not even define execution at all. How the cryptography works, how you have different like all of those

decisions are not exposed in most other frameworks or it's just one way and then you can like customize at this level. So like the coins SDK, >> you can customize everything at a certain level above execution above the state machine, >> but the state machine tenderint and like what it manages for you, you're not like breaking that thing open like you can you can use different configs maybe, but like it has its own state tree. It has its own like P2P mechanism and like >> the idea, right, is like well this is the best like and this is as good as it could be. So like you're not don't change this. It's the same reason why like most people don't run like a forked Linux kernel if you're running Linux, right? like you it's like you use Linux for that and I think what has been shown

in recent years I mean like obviously com like the stuff that tenderint was pioneering I'm a huge tender cosmos fan just to be clear and wasn't and integrated that at Coinbase as well >> but a lot of research has come out in the subsequent 10 years since tenderment was first released and announced that changes how you would architect something for performance >> so that alone is enough of a motivation for people to be like well maybe we should rebuild this thing >> the second part is well we understand as an industry a lot more of the challenges now we would benefit from having probably more control over this thing in in how we build applications and so I think with any new project there's always a question around timing which is like why now and the the two things are like new mechanisms new algorithms

that's one thing that we do the other one is like actually changing how the whole thing is architected together >> both of those are are new and we think the right time to kind of explore those things >> nice but philosophically ically I think it's like somewhat similar in spirit as in like oh yeah cool you should build your own application on top of the thing but like again like you're mentioning right at the time tender was the thing and but it was like a it was like a solution for a huge problem space people were like oh we can just blackbox this and give you the the right >> I mean you know imagine all the complexity they were hiding inside of Cosmos was incredible like if you were going to build your own chain like most like all these topics were so out there

at that time like you definitely wouldn't want to mess with them. >> Yeah. >> Like the idea that you could somehow define your application as like one participant in a state machine, a replicated state machine and it just worked. >> Crazy. >> Yeah. Yeah. >> People today much more ambitious. >> Yes. Well, I think also what has improved substantially, right, which you mentioned in the research is >> there's been a lot of work in kind of untangling the pieces themselves that make up a replicated state machine, including both >> like you of course, which you will hope I I I really hope you will talk about, you know, consensus, but also the cryptography that goes into it, also like the DKG that goes into it, also the like all these other pieces, right?

>> And and at the time it was kind of annoying, right? when you designed a system, it was this like complicated thing that solved the problem, right? But it wasn't until later that the individual pieces kind of got taken out and cleaned carefully and put back together. And now they have nice abstractions that like how they fit together. And this is one of the things that I I believe you are very good at doing, but Commonware in general has been pretty pioneering on is like designing these very nice interfaces for these like different pieces to fit together. >> That's what I would call like the taste component of this all, which is not papers, it's not whatever. It's like if you were to actually like how would you actually allow people to pull these things together without being too overbearing >> but still helpful.

>> Mhm. >> Like the way we think about product is like you know Cosmos you could whip up a chain in an hour. With Commonware like we target someone whipping up a chain in like 2 to 3 months. >> Okay. >> That's the that's the level of abstraction we're working with here. And the reason why it's interesting is like, well, if you want to do all these crazy things, you know, two to three months is a lot better than two to three years of rebuilding the whole thing from scratch, auditing it, and whatever. >> And often times that additional delay is worth the more control in terms of like maintenance and how you actually integrate it with your application compared to maybe what you could get with Cosmos. So like we're targeting like a slightly different part of the curve. And hilariously with LLMs and AI

and everything that two to three months is now much shorter. Yeah. But that was not necessarily planned let's say when we when I kicked it off. >> Yeah. >> So maybe yeah maybe one of the things to to follow up on you know in the previous discussion is like what is common where the library? What does it look like? Like what what like what is the thing that I touch when I go you know to to commonware.xyz and I'm like I would like to do a common wear. >> What does that mean in practice? First thing you see like a plain text website and then beautiful either you're into that or you're not into that and that's our first gate to make sure that this is the right thing for you.

>> No. So I mean comware today the com we call it the commware library which is all these primitives that you can that you can interact with. Today there's over like 40 different primitives and primitive what we call dialects. So different versions of a primitive for different things. So the way it all started was like after I decided to start Commonwe took no days off so I left Avalanche. Next day started Commonwe next day had money in the bank account so it was all good you know good start right >> and then the first thing was like well obviously P2P like without P2P were nothing and so started building an authenticated P2P network. Once I had that I was like cool this works is consensus obviously next. So actually

cryptography. So it built like some threshold DKG stuff and then I was like okay consensus on top of that and then I was testing it and I was like ah I have no idea if this is right. I need to like take two steps backwards to like actually make sure we can test this stuff. And so that's where we started to like work on deterministic simulation testing and we have our own runtime in Rust that lets you do all sorts of crazy simulation and mocking. That's how we keep this whole thing stable. M >> do that come back to consensus rewrite P2P to use this new runtime build consensus out and then by that point in time like you could run a chain >> so like you have P2P cryptography consensus pretty much all you need >> okay >> we had some basic storage primitives so

like a wall or kind of like a journal that was it >> and so then on top of that you then start to add all sorts of different layers so that's like maybe like if you're building an execution environment you want state so like state management um on like applications and accounts. So we build that. You want more cryptography. So like you want, you know, private mess, you want you know time lock encryption, you want all these different things. So you build that, you build that. >> But really it's like a you know box of Legos. Like the whole idea is that like nothing relies on anything else. They just share types >> and then the testing comes from the runtime. And so they all make a pretty hard requirement on this like core runtime existing that can orchestrate everything but also test it to keep

things somewhat hopefully reliable. >> Is it all built in Rust? Is it just like Rust libraries? >> It's all Rust MIT Apache 2. >> Okay. I just wonder as you talk about and like there is the list of primitives. You have actor broadcast. Like I I checked out your website before, but I wondered like do you then go and audit each of these? Like do you like how do you guarantee that they're not, >> you know, weird when they go when they are used? >> A careful word. You can never you can never guarantee anything. We make a very concerted effort to make sure that they're stable and reliable though. So we do a lot of testing first of all of our own unit testing and everything.

We've been working with asymmetric research for the last, you know, over a year on fuzzing everything. So everything you see is like heavily fuzzed 247. >> Huge. I mean, fuzzing, if you don't fuzz, what are you doing? But like fuzzing is like it's the best engineer you've ever worked with. They find bugs you could have never imagined >> and things LLM would never find. So like fuzzing key. So we run that 24/7. I'm not a huge believer in like point in time audits because the code's always changing, especially with these like sort of stack things. So the first thing for us was like can we actually build like a continuous security framework that we feel like has that we have confidence in. We also work with another team called QED audit which has this like crazy like L bug finding bot that's been incredible to work with. So that's

like our continuous auditing outside of just manual review but then uh we are actually doing a point in time audit right now over a number of different things with ZK security. So, you know, Kobe, uh, so Kobe is looking at stuff, people that, you know, David Wong and stuff. So, >> we're fortunate to be collaborating with them and and working on it. So, yeah. So, we I mean, you use Commonware not because it's just like useful for you, but the whole idea is that we're doing all this like crazy security research and security engineering so that even if you were to like whip up the same thing, you know, maybe it's within 10% of the performance that we're currently getting, but you don't have to maintain it. H would you say though if somebody builds something with your with this

stack would they still should they still be doing their own testing security like or do you just have a security piece that they can just lock in? >> Uh so they they get access to the runtime so they can do all of the simulation testing all the way through their code. >> Okay. So like you can run up like a spin up like infinite virtual clusters that all have like different simulation testing outcomes to like help uncover bugs which is huge in terms of just general reliability. >> But most people building on commonware will also do their own security audits on top of it just like you would if you were building a Cosmos chain like the Cosmos things on top of them will also get audited because it you know it assumes certain things about the core but then you add your own you know logic

and primitives on top of that. So it's there's no silver bullets here that's for sure. The the whole point though is like can we make it better for you or like easier to manage not just at launch but over time >> like I think the the big question that ultimately becomes difficult with frameworks is like how do you keep someone >> building in that world as they like their problem becomes more interesting and more challenging more pointed. Oftenimes people will be like, well the problem that's holding me back here, the thing that's holding me back, not helping me is now the framework. I need to diverge. So I'm going to fork this thing. I'm going to do whatever. And so the grand challenge of commonware is like can we give you enough flexibility >> which and sometimes could lead to you hurt like you know messing things up but

enough flexibility that you can stay on the runtime as you as a you know project evolve >> and that's really interesting. But ultimately the idea is like there's a bunch of great state-of-the-art research that now is at like the theoretical bounds for how good things could perform. So like unlike back in the 2020 days, you're not going to have someone like drop a new paper that like does way better, right? Like we're pretty close to the bounds unless you like change some assumptions, which I think we we're pretty comfortable with a lot of the assumptions we're making, but ZK and prolific, you know, ZK could change a lot of this, but there's my blood for ZK. But um generally we think we're pretty close to that frontier.

>> And so you know you could do this and reimplement what we have but you're not going to be like you know a factor better or something like that. And so we hope that this just lets people save time. It's not a socio kind of ecosystem or whatever. You can just like it's open code you can run. whole whole point being like can we emulate Linux in this way so that we focus as an industry our efforts on the application part instead of continuing to reinvent some >> very slightly modded version of consensus 10 times again that's the dream that's that's the goal fair enough >> it's funny you talk about sort of breaking down the components of this sort of blockchain tech stack into its pieces and then better understanding

them auditing obviously I hear in that like the echoes of what happened in ZK systems where it's like like at first they were just a monolith you know one piece and then slowly and surely everyone started to define what the pieces underneath were and then optimize those. What you're talking about though in the case is more I guess on the engineering front and less on the research front. But you also like are you kind of just said that that you don't feel like there's it's not these kind of breaking research pieces coming out that are really changing things, but you also have like a pretty researchheavy part of your business. So what are you researching if you're not researching sort of things in like to do with these primitives?

>> Yeah. Yeah. So I think the the question there would be if if we're so close to the frontier why do we ourselves also you know employ multiple researchers and do research? >> Great question. So when we started off that was not the goal. So when we started off, I had fallen in love previously with Simplex Consensus and thought I literally I was it was at an IC3 retreat in Switzerland, you know, one of these like 10-minute lightning talks and the author of Simplex, one of them, Ben, was there and he gave this 10-minute talk on Simplex, which I had previously never heard about. And I walked out of that thing and I was like, "This is the first consensus protocol I've ever heard where I feel like I can implement it in a weekend." Obviously,

it was much more complicated than that. >> Is there anything we know that's built with this? >> So, that was the first consensus algorithm we implemented. Okay. Um, and so tempo for example runs on simplex. >> Oh, wow. Okay. >> And it's become much more popular lately especially so like Tom now runs on simplex sana is migrating to like a simplex inspired protocol. Alpenlow >> so it's become much more popular. And the reason and the rationale for that is like for a long time people thought consensus and the dream of it was linear broadcast. And so the idea is that votes would like run through the leader and then the leader would help disseminate everywhere. So this is like hot stuff and some of the ideas there.

>> Turns out everyone just all to all voting not that bad and it ends up simplifying the protocols quite a bit and also improving their performance. So with simplex when I first saw it I was like if you do all the all like these protocols are way simpler and so I saw it and I was like this is incredible. This was like one that was at Avalanche in 2022. So I ended up like building a few derivative protocols off simplex that like allowed you to scale it in different ways, whatever, but basically just got really familiar with Simplex. And so when it came time to like build one for Conware, like there was no other choice. Like simplex was the one to build. And the contribution we made was like figuring out a way to like natively embed threshold consensus into it >> and then also a VRF as part of it

>> which you use for like random leader election. And then yeah, pestered Ben on the side, you know, in the early common war days being like, is this correct? Is this correct? And then, you know, 25 versions of that later, we finally got something correct implementable. >> Cool. >> So that was the plan originally. It was like simplex is what we need. We don't need to do any of this crazy research. And then things changed. So I was at Salana Accelerate in 2025. So I was speaking on some like ordered broadcast stuff. we were doing which was like this kind of like decoupled consensus construction or whatever unrelated and well actually very related we'll get to it later I think with some of the other consensus work we've been doing lately

but the idea was like uh this was the this was the conference where Roger unveiled Alpenlow and the line in the sand that had always been drawn and the one I had always been working around was like BFT you want 3F plus1 as like the the configuration anything less like you know 33% % tolerance was already you know low relative to what people thought >> and now it's like oh 20% Byzantine is now cool that changes everything >> this is Alpenlow >> so Alpenlow is Salana's >> so they had a totally different security model which was what they called 2020 really interesting stuff like and full credit to Roger I think for like reorienting the industry to like kind of

consider this as a reasonable option cuz it the performance implications are huge so the idea was what if we have 20% Byzantine fault tolerance and 20% crash fault tolerance. >> Okay, >> that was the pitch with Alpen glow and so you get this 20 plus 20. >> Wait, so sorry say that again. So 20% business. So normally like so just picture by the way Patrick this is a revisiting of consensus that I have not done in a while. There was a time where I felt very upto-date like I you know we had it Abram on for hot we had hot stuff. We had all these great >> consensus protocols, but >> it is a legend just to be clear.

>> It's been a while. So like I am so out of the loop like Alpenlow clearly totally over my head. But yeah, say this again. So the Byzantine, what was it before? >> So usually no, not the best, but just like what people were comfortable with. >> Okay. >> Like if you were going to ship a BFT system into Prague, like you're not going below 33% tolerance. >> Got it. >> And that 33% is either Byzantine or Crash, not delineated. Crash here means like honest participant shuts down. >> Byzantine here means arbitrary protocol behavior. Like if someone hacking the protocol >> and so those were locked in one bucket.

Yes. >> And it was like okay as long as less than 33% of that sum were good under a certain network. >> Was 33% under 33% had to be malicious or under 33% had to be >> if under 33% was malicious. >> Yeah. So it was 2/3 had to be Yeah. Okay. Got it. >> You're good. >> So it was like Yeah. So two if twothirds were acting appropriately >> you're good. That's what I've always understood. I did not realize that that had evolved. Okay, continue. >> So this so this is exactly why I was like well we're at Simplex takes us to the bounds really in terms of like how good you can do in that world. So I was like well we we're good. We don't need to do any more research. We had simplex.

No one can beat us right like it's as fast as you can go. No problems. All right. >> I'm at this conference and Roger's like well what if we didn't do 33%. and instead we said 20 plus 20. So we treated them as separate 20% Byzantine. We we're we're tolerant to that. >> Okay. >> And we're tolerant up to 20% crash. >> Okay. So this is let let me just articulate this. This is 20% malicious up to 20% malicious actors and up to 20% people just going off nodes going offline.

>> Correct. Like because I guess your assumption but why like how are you able to do this? I mean together it's 20%. But I don't know if that helps. >> Yeah. To be clear it's it's 20% additional could crash. Yes. So like the tolerance you're not talking about is 40%. >> Okay. >> But there's a limit to how much each bucket can be faulted. Okay. >> Okay. I see. >> Now the motivation for that like that's one part of it. Like you could argue that's more robust. We're not going to have that conversation. The thing that's interesting is when you go to 20% Byzantine fault tolerant, a whole new world opens up to you in terms of performance.

>> Okay. >> Because you can get finality in one vote instead of two votes. >> Oh, right. >> Which is huge. >> H. >> So like the best you can do 3F plus one is two votes. So like you have a voting round and then you have a finalization round. >> I see. If you go down and change your fall tolerance such that 20% Byzantine fault, you can go down to one vote. Meaning that I can we can single shot finalize this thing. >> Wow. And I mean, I don't know if we should get into the details of Alpen Glow, but I guess you're giving this as an example of like a new paradigm that created the need for research, right?

>> Basically, the sands shifted. >> Okay. >> And you're like, ah, actually there is research to do. There's a now because now there's a whole new world that people are okay with a different fall tolerant model which opens up a whole new world of like how you could structure consensus to hit certain goals and >> wow >> let's just say the focus for this industry at least had been on the 3F plus one case. So like all the research was done with that assumption. But if you now can change it to 5 F plus one you can or 5 F minus one some people you know that's the bound like you can do totally different things where maybe doing research may be interesting and so immediately I left that thing and I was like shoot we got to do like we don't

have an option for 5 plus one and like the op like the performance is clear like it's a whole round less of voting like >> like what does it mean though like if as a as a user of this does it like double the speed of something beingcept So the finalization the finalization latency is now one delta less. >> Okay. >> So what that means is like you know instead of let's just say like your delta is like your network level like assumption for how long it takes one message to pass to another participant. >> Mhm. >> Let's just say on the modern internet in a globally distributed network that's like 80 milliseconds or 100 milliseconds on average. We'll just call it 100 milliseconds to keep it easy. So like in a traditional simplex world you have proposal goes out

>> 100 milliseconds one round of voting 100 milliseconds one round of finalization voting 100 milliseconds. >> Okay. >> So end to end in one view you're getting finalization in like 300 milliseconds. >> Mhm. >> Now that can shift based on a number of other things but let's just say that that's what we're working with. >> That that's pretty close to like I would say like 50 percentile latency. You get a little faster if you do weird stuff with switches but like that's pretty pretty on the money. Okay. Idea with 5F plus one is like well 100 milliseconds for the proposal. >> Yeah.

>> 100 milliseconds for the vote. That's it. >> Done. >> Yep. >> So it's like a 50% or you know depend on how you do it. Like we're massive reduction finalization latency. >> And what does that open up? Like obviously everyone's trying to get things fast but is it because of this goal of like being visa fast? I think that was often like the the target. I mean our view on things is like if there's a way to go faster in the end people will go faster. >> Like >> but is there a point where like the user doesn't care or like it won't matter?

>> So that's where I mean like you could argue that simplex already achieves that with like 300 milliseconds, right? Cuz like is that faster than users can perceive? >> Maybe. >> But in a world where it's like agents and like you know whatever like and most people interacting with these chains are bots, you know, it may matter. >> Wow. or in trading where like every you know millisecond has its impact on like liquidity and how long like it does matter. So yeah so the idea was like well okay so people are cool with this one round voting is Alpenlow the best you could do and so that's was our first research paper we put out was this thing called minim >> which is a consensus protocol in the 5F+1 setting with very different tradeoffs than Alpenlow. What we said

was like, well, the resilience to the 20% crash on top. What if we just we didn't want that. We only cared about the 20% Byzantine or crash. >> Okay, >> so kind of like what the 3F plus one setting is typically analyzed under. >> And then could you do something differently in terms of performance? And so what Minimate showed is that if you like did reorient the quorums a bit, >> you could get even faster block production with the same finality. So like faster views basically. >> And that's useful because view latency plus finalization latency is what you would call your transaction latency. So that's like if you're a user submitting a transaction, that's what you're going to see in terms of finality. You're not

cuz like your transaction may land right after a block is built and so you have to wait that view and then you get the finalization. So the shorter views you can do the better transaction latency you're going to have minimate. So that was our first one. That was a year ago. >> Okay. And then you started a podcast >> or did that happen before? >> And then it was natural natural to become a podcaster at that point once we were doing research. But no um no I think the podcast came before that. Basically the idea was you know when people try to get more into crypto like I I got so many still get a lot of questions from people that are like hey I want to like get more into this like where did you start? Mhm.

>> And I'm like, I don't remember. Like there's tons of blogs. There's like tons of random things. I don't even know if half of them are up anymore. Trying to understand like conceptually what people are doing and what the goal is. And so we started this podcast called How Things Work. And the idea is just like take big ideas and create like blockchains and like try to break them down and like understand what they're used for. So that if someone was trying to come in to like a blockchain kind of study for the first time >> that we would try to cover like the kind of like the core ideas of like what you would need if you were to build a chain or like why things exist.

>> Yeah. >> So we do it sporadically but yeah that's that's the the GMO episode was on the DA. >> Yeah >> that's right. Speaking of of DA and succinct peruse and ZK and all this stuff, right, and research is like one of one of the natural things that I think a lot of people are converging to >> is kind of an integration of all of these individual I mean obviously you start with the DKG part, right? The distributed key generation and how that applies to consensus, but but it seems like other parts are kind of starting to come in and play nicely or not so nicely with consensus. you know things like like data availability and their weird combination of that and succinct proofs but also like literal zero knowledge right like you want privacy for your

transactions >> I don't know if you guys are doing research on this type of stuff or if you guys have been like implementing some of this type of stuff and you know making all these nice primitive I'm curious what your your thinking is there where you're seeing the future kind of evolve um and I also have a gajillion questions about how AI and all this stuff has been speeding up your workflow and integration all these things but maybe that's a separate one that we'll get to later. >> Yes. So, uh we do uh cryptography research which is also not something I had originally expected us to do. But like basically the way the way it works is like at common we build things. We talk to smart people building with commonware or not and they have needs

and sometimes those needs are not satisfied by the current state-of-the-art. And so if we see an opportunity to improve upon that, you know, we will try to. And so we try to hire people that are capable of that level of research. Not a lot of people uh would fit that definition. So and research itself obviously is like a bit of a crapshoot. So you don't necessarily know, you know, what you're going to get. Like it's a lot easier to say let's beat the state of the art than doing anything like that. So yeah, we did we started cryptography research with so the first person we hired in that domain directly was Lucas uh who had been working at Penumbra.

>> Um and so Lucas who goes online by like chronocy um basically I was I was doing the cryptography >> um and that's a terrifying place to be and so I was like I should not be doing the cryptography. So brought in Lucas to like kind of look over it and like make sure this is good. And so he did that, looked around and prove some things. But Lucas, for those that don't know, wrote his own DKG protocol that is very commonly used in the ECDSA setting. So like Near Intense, for example, uses his DKG protocol.

>> Oh, nice. >> And so or threshold signing protocol for ECDSA with beaver triples. There's he has a ton of stuff online. You can learn about it. But basically, I was like, someone that's like really into threshold stuff, that was awesome as the person to hire. So, brought him in. So, he's been doing that. He's actually working on our implementation of Golden, which I think you've had people on the podcast to talk about. So, like that's Chelsea and like Benedict >> had a new DKG protocol, uh, which is really interesting. And so we've also implemented that that's not yet ready for production use. But like our DKG protocol is like synchronous, partially synchronous, whereas theirs is like fully, you know, safe in like a more challenging network setting, which is

interesting given that this is like the key that secures the network. So there's reason you would want to be as conservative as possible. >> So So we've implemented that and Lucas drove that. But then I was like, well, people are really liking this like encrypted meool stuff. we should work on that transaction privacy in general and so then had the opportunity to work with his name is Vomzy who just graduated from Berkeley got his PhD but has been a co-author on a number of interesting papers uh so like have you heard of like TRX from Aptos >> um and some other stuff but he's super into witness encryption >> okay >> and so he then published a work which is you know we'll see if it gets in a

conference here soon but on a new way to do batch threshold encryption which is useful for encrypted net pools and then we just released some follow-up work on that last week on something called multilabel IBE which is also useful for like this like batched threshold encryption setting or like menpool encryption. Yeah, >> I'll be honest with you. Don't ask me any questions on that cuz that is >> we we hired somebody. >> Yeah, I thought witness encryption is sort of an unsolved problem though. like I don't think is it close to engineering?

>> So he came out of the lab that's like the leader there in Berkeley and so like they he's been working on it for a while and like some of the work we've done is like trying to make it more practical. >> Cool. That's very frontier. But do you feel like I mean with that kind of thing with you know if you were to implement witness encryption like and I guess you'd use it in the threshold encryption like sort of for validator thresholds is that where you would probably put it? >> Yeah. And so the idea with that is like, you know, you got a chain, you're trading. >> Yeah. >> You don't want people to see what's going on until the data is finalized.

>> How do you do that most efficiently? >> Yeah. It's kind of a way to keep the validators honest, right? It's just to make sure that they don't see and and it prevents sandwiching and it prevents like a lot of the ME stuff, I guess. So the the dream right is like you're a user, you encrypt your transaction to like some set of validators. >> They then package all these encrypted transactions in the blocks. So like they don't know what any of them are. Some versions of this problem, they know who you are, but they don't know what you're doing.

>> Full encryption is possible, which is like they don't even know who you are. You just have to figure out how to like pay transaction fees in that setting. We're not going to talk about that for now, but like let's just say it's hidden and then consensus happens over this encrypted data and then after it's finalized or really in our world during finalization you decrypt it. >> And so this is the crazy stuff is like if finalization fails like it doesn't leak anything. So there's a lot of cool stuff that goes into that. >> But let's just say that you're pipelining the decryption so that right when the block is finalized the data is decryptible.

>> Mhm. >> And so then that's the kind of the setting. So validators like they get a bunch of encrypted stuff, they have no idea what it is, but they know it can somehow pay fees. They swap it into the block and then after finalization it's like somehow randomly done and then decrypted it. Yeah. >> Yeah. >> So uh we landed on the same construction for this as Monad did. we had some concurrent work uh that uh went out and then we have further explored like kind of the trade-offs you can make to like minimize the overhead of the DKG or like >> minimize the overhead of the C like CRS like the size of the like there's a ton of different ways you can kind of mess with it. So we did research there because we thought it was interesting and we wanted to see if we could do

better and VMs found a way and then we also have some private payment stuff we've also been working on. Some of that's been released. Some of it is yet to be released. >> And this this would see like the form it would take is like new primitives or like in the primitives you'd add I don't know options like what does that look like when you release this stuff? >> Usually it's new primitives. So if there's a paper out there that we're content with and we're like we couldn't we don't think we could do better than this, we would try to implement that if it's like open and you know useful. If that's not the case then we'll try our hand and seeing if we could do better and then implement that. But often times in our in the comware library, you'll see all of the primitives are like named

what they are. So like consensus is just called simplex. >> So like we'll try to be honest with like what this is rather than like rebranding it as like common wear, you know, special sauce or something like that. >> Like going back to that consens consensus example then do you have simplex and then another one like did you because you implemented the 20% one as well. What is that called by the way? So the minimate one we did we have a open PR that we implemented but then with the work we released over the weekend with multimement >> ah yeah >> which is the more research that I said wasn't necessary uh >> we will we will probably implement that one directly instead and not actually implement minim directly but we'll see >> you had a question about AI and I want

to get to that but I wonder if we should dive into multi wait what did you say it was like commit multimit Multit. There we go. Okay. >> So the idea with minimate is like mini commit >> and so the idea of the fast views is powered by this thing we created called like a mini commit. >> Okay. >> But it's single litered. So like just think a normal consensus. >> The idea with multime was multiple mini commits. >> Okay. >> And it builds on minim. So that's the like kind of the naming topology that gets us to multi. doing the multiple commitments like mini commitments is this the is like valid are validators because I I have seen like the blog post

and there's a nice graph there where it looks I guess this is a bit more of a a dag >> you could thank AI for all those graphs by the way that that was not that was not possible 6 months ago and like I literally was like I want this I want this I want this I want this I want them all to be consistent like >> and it did it >> and it literally that's hard that's like raw JavaScript that's like there's no frameworks like it cooked up raw JavaScript and I was like, "Hey, make some gifts." And so it made gifts of all like it's crazy. Like I mean >> makes my life dramatically easier. Like if you look at the minim blog from a year ago, it's like some really crudely drawn Excala draws or whatever. Like me trying to like make it work. And then

yeah, the blog here is like obviously much better and interactive and like I didn't do any of that. So it's it was faster for me and better which to me is like LLMs in a nutshell. Okay, so >> back up. So the idea with multime to take way back. So I've been obsessed with this like kind of direction and many people have. This is not just me nor was I the first. So in this thing called decoupled state machine replication. So the natural question when you start to work on consensus stuff is like how do we do more consensus throughput? >> Mhm.

>> Reasonable question. So there was a paper released originally by Libra folks in like 2021ish called Narwhal Tusk. >> Mhm. or I don't remember the original name of the paper but this is what I would say like repopularized this idea of decoupled state machine replication it was actually originally proposed by like Barbara Liskoff and all the people back in like04 >> okay >> but like many great ideas was ignored until we needed it so when we needed it the idea that the Libra folks had was and beautiful which is like what if all the validators just send data out at the same time >> oh yeah >> and then you make consensus over that broadcast directly consensus.

>> Beautiful. >> So, this is a DAG. >> Yes. >> This was the whole argument years ago. It's like DAG or not DAG. Avalanche was a DAG, but a different kind of DAG. I've spent years working on DAGs, shutting down DAGs. Like, >> yeah, >> it's a whole it's a whole thing. Okay. I think the first time I heard of a DAG was by I don't remember the name of the company. It was a 2017 era company that had sort of like a fake DAG but was very famous. I hope >> there was a I mean I'm not going to we're not going to name names here cuz I don't want to uh you know draw the >> project that was like sort of not not really functional but like introduced

everyone to DAG. Yeah, that one. >> So the original dream of DAGs was that it was leaderless. >> Yeah. Yeah. >> So like there was no leader in consensus like you kind of like somehow the DAG just like worked. Narwhal Tusk was a little different and that there like was a anchor >> in each wave of consensus. There like was a leader that was kind of determined by a ranking >> but the cool thing was that the consensus like was built on the broadcast in an interesting way. And so like it was just really well articul articulated and for the first time I think people would generally say this like really robust and well defined very cool stuff. I saw for the first time I was like this is crazy because the they were the first people that were like hey

we can hit TPS over 100k >> you find they finally cracked it almost seemed >> seemed like a crazy thing at that time cuz like right like the whole way consensus typically works is you have a transaction go to the leader the leader broadcasts it to everybody else you have sometimes you have memp pools sometimes you have other stuff but like there's all this time during the protocol where like people are just waiting around doing nothing. What if we could find a way to saturate the network and the storage and like the CPU of everybody at the same time? That's the way you maximize throughput. This was like the first in my opinion like real >> like plausible implementable version of that. So I was blown away. I thought that was the coolest thing ever. And then in the preceding years like Aptos and Sooie have taken that idea further.

Um, so like Sue has like misti now >> um, which is like an uncertified DAG which is like a a whole different way to kind of try to make it faster. So instead of like when you send data out instead of having a certificate that 2F plus1 people have the data you use the graph to like kind of infer that people have that which reduces like some of the delta in finalization. >> There are trade-offs there right like if you withhold data you can force people to fetch. So, but the happy path is incredible. And then Aptos had their own ideas, but they've shifted to this whole different thing called prefix consensus with somebody called Raptor. Funny enough, they've like written three or four papers on de consensus, but have not actually run it in prod. They've been using a version of hot stuff and

have now like done a different. So there are reasons that our des are cool, I think, but ultimately I landed somewhere where I'm just not a fan of the properties of a DEG and what it means to deploy one in production and so have instead preferred trying to find a way to have decoupled transaction broadcast with traditional consensus. >> Okay. And is that what multi-mit is? >> So the problem historically has been that if you try to do that, you end up having this latency delay. Mhm. >> So the best paper I think that like kind of summarizes the pros and cons is this paper called Autobomb from a few years ago >> came out of Berkeley from Natasha Krooks and like a handful of other like incredible paper again. But the idea is that you broadcast transaction data out

everyone does. You get back a vote back that says like hey I've got it. like a proof of availability and then you just basically take that proof of availability and put that in consensus >> and you're like okay consensus is over these certificates rather than like the transactions themselves >> and the the note coming back is just from some node heard your broadcast. >> Yeah. Basically you're trying to just show that like if data gets in consensus it's available. >> Okay. because if it's not available, you're deadlocking because you no longer can get the data needed to produce the basically the effects of consensus which is a would be a catastrophic failure of the system. So it's like okay I can convince anyone that like this data is around because I said I have two F+1 people that have said I've got it. So if

I don't have it at least I know I can go get it if it's finalized. Okay. So the problem though is that pre-step adds latency. >> Okay. So like I have to go send this block out or like this mini block out. I then get back a vote back, generate the certificate and then often in autobond you then have that producer then send a certificate out like you don't like broadcast the vote to everybody and then when you have that certificate then you can put it in a block and then run you know two more rounds of consensus. >> Okay. So there's like seven steps here. >> Yes. So like the typical trade-off and like what a dags have always excelled at is like the latency overhead >> of trying to couple this like decoupled broadcast thing with traditional

consensus has just been slower. >> Okay. >> So if you want it usually the best option was a de >> for you care about latency. If you're willing to accept one additional delta you can get a lot more arguably like robustness from like having this approach rather than a dag. >> Okay. >> That's what the autobond paper talks about. >> Okay. So just to orient ourselves here, the whole idea is what if you didn't have to pay that latency penalty. In fact, what if you could even beat a DAG? >> Okay, >> that is multimit. >> Oh, >> so the idea with multimit concurrent broadcast, this decoupled transaction dissemination, but you pay no penalty for this like

pre-step. And if you're not the leader, you can still get your data included in consensus in that view even if the proposer doesn't reference it. >> H >> which sounds crazy, >> but I wait I want you cuz you said miniit comes from multimit and I'm just trying to remember what miniit does. >> So miniit is just like a clean what we think of as a clean construction for this like 5F+1 setting. >> Oh yeah, okay. Okay, that's >> there's like a really really simple consensus algorithm for this like 5F+1 world that makes it really easy to reason about this like oneshot vote thing.

>> Got it. >> It turns out the quorums that came out of that paper ended up unlocking multime. >> Yes. >> So like some really interesting properties of how like the quorums and votes are constructed allows us to do this like really crazy concurrent broadcast thing. >> Okay. And so yeah, is it the like I'm just trying to understand how you're skipping those steps using multimit or using this like multiple version of >> mini? Yeah. >> So the idea in a nutshell is we're okay with bigger certificates. >> Oh, so like less is it less often but bigger? Like what is a bigger certificate?

>> So normally you want a certificate like in simplex for example, we all vote over the same digest. >> Uhhuh. And so with like a threshold signature, we can get the certificate down to like you know maybe 200 bytes, maybe 150 bytes, super small >> and that's what's included in the chain. >> So like when you broadcast like oh like hey I finalized something you'll broadcast a certificate to everybody. This is the thing that you do all to all. So the certificates are not included in the chain in simplex. It's like kind of done asynchronously. >> But every participant when they generate a certificate sends it out.

>> Okay. So if these things were like a gigabyte, you're going to have serious problems in terms of like doing something. >> But in your case, you don't mind if they're bigger. >> A little bigger. >> Okay. A little big enough. Okay. >> So this is almost like the comparison I would get. So, like I I mean I think you guys have had Justin Thaylor on before a few times when he was talking about like Jolt and whatever >> and I was talking about him when he was this was before he released it and he was like yeah I've got this crazy idea for this new thing >> but it's not succinct or like some component of it wasn't succinct and I was like well I'm an engineer like what does that mean cuz cryptographers's version of succinct is very different than engineers >> version of succinct

>> and he's like you know like a graph 16 proof is super small. Yes. >> Like succinct succinct like it's tiny, right? >> What if it was like you know a couple kilobytes though for an engineer like that's succinct as far as right >> but to a cryptographer it's like no no that's huge like we we can't do that. And so for me when we were doing multimit like I would say you could almost say like the traditional simplex certificates and minimate certificates are succinct. They are very small. >> Okay. >> Multimit is like we're talking like a couple kilobytes. So they're bigger but still >> they're bigger but they're not like >> clogging everything up. Okay. How does making it bigger speed everything up though?

>> So the the key part is like when you in multimit you vote on many things at the same time. >> Okay. >> So instead of just voting on the consensus like the one digest of a block like you would think about in consensus, right? Like is this block good or bad? That's consensus, right? >> In multimate it's it's more complicated. It's like I'm actually going to vote on all of the validators tips >> of like what their tip of block might be. These are things going out concurrently >> and I'm going to let you add additional digests on top of what the leader is saying their tip is in consensus.

>> So it's like the leader hasn't even included it and I'm like no no no I saw this actually this tip that even extends further than what you're proposing. I'd also like to include that in my vote. >> Okay. Okay. And so you then send that out to everybody. >> Certificate is constructed and what you'll very quickly say see is like well the certificates can vary like based on what votes you've seen. >> Mhm. >> So like some certificates may have more votes or like more digests or whatever >> and will be bigger. >> They may be bigger. They may you know you as a Byzantine could stuff arbitrary digest in this thing right like you could make it you know within some bound bigger than it is. The crazy leap is with the minimum quorums, the max any two certificates can differ

>> is very limited such that you know that if something is finalized >> Yeah. >> by anyone on the network and the certificate they have locally, the leader of the next round must extend that tip even if they don't see it finalized. >> Oh wow, this is so hard to follow just verbally. I'm trying. I think I got I I've gotten parts of it. >> So, this is a 50-page archive paper to be clear. So, I'm There's like diagrams online to like kind of try to explain it, >> but even kind of scratching his head, which I'm like, "Oh, good."

>> So, to take to take a step back, let's just say like, "Why are we going through this hell for like what are we trying to achieve here, right?" >> Yeah. >> The crazy thing that happens is like you're on a blockchain, >> you got validators all over the world. Mhm. >> You send your transaction to the closest validator to you. >> Yeah. >> Okay. Maybe they're like 20 milliseconds away or something like that. Maybe even less if you're like in the middle of >> a certificate. >> So this is the thing. They send out whatever block include like everyone all the time sends out whatever blocks they have of new transaction data. >> Okay.

>> And while a view is going on the current view, >> that block can be finalized without even being referenced by the leader. >> Okay. The idea essentially like is this idea that like at some point if like I don't know what the threshold three plus one or something like that right the second that like that happens right you know for sure at some point the leader is going to receive that block and therefore sign it ahead of time before the leader has technically confirmed that they have seen it like that's the idea like like you know that like this thing is going to be disseminated to the leader and the leader will for sure end up being end up agreeing >> therefore it's included therefore it's immutable Therefore, >> right, it's fine.

>> Even though they have no confirmation that that has happened yet and therefore that saves you kind of like a round trip because you could just kind of pipeline yourself to the next step while the it's like you're you have overlapping stepsish. It has two properties which are really interesting. The one is the fast finality. So like you as a user, no matter where you are in the world, no matter who the leader is, you're seeing your data finalized in the best case in like two delta, >> three delta from the user. So like we're talking like end to end anywhere in the world like 200 300 millconds. >> Okay.

>> We're talking like a couple hundred milliseconds faster in a global network than any other construction. >> Oh >> okay. The crazy property though that comes out of that is you can override the leader. >> Oh. >> So if everyone says no, we've seen this block from this other person. >> Mhm. >> You can prevent the leader from censoring whoever that person is that's broadcasting data. So, let's just say, right, you know, you're doing some sort of auction or exchange and it's like, well, the leader sees all the blocks and like, well, I'll win if I don't include this guy's stuff because it has like some more transactions in it.

>> Yeah. >> Well, with this property, if the network is honest, they can actually just be like, actually, this block is finalized. You know, I don't care what you say as the tip leader. This is is included. >> Correct. You have a certificate that says like like you have retribution, right? Like so long as somebody has seen that the certificate has been finalized independent of whether or not the leader has signed it, you know for sure that majority has accepted it or enough of the majority has accepted it for it to be fined. >> Any future view must build on it. >> Yeah. You you need to do a bunch of weird stuff though because now you have like a four choice rule where like the leader like needs to like get kicked and then have a new leader and then you do the next thing.

>> Do you also have to use a lot of randomness here so that like the person who's receiving isn't like in any way colluding? >> So there's no randomness in the protocol at the moment. like if you had randomness then it would change like kind of the emitted log which would lead to like basically the so it's actually very important you don't have randomness and that it's deterministic. >> Now you could include a VRF input into that >> to then kind of change up the order of what's actually gets executed when you have the log. >> Yeah. Yeah. Yeah. >> But like that's we we kind of document that as like further research or kind of optimizations because our our motivation for this is like just speed. Okay, >> how fast can we get a user transaction file?

>> And for that, we believe in like a decoupled world, this is this is as good as you get. The idea that you as the leader used to be the only one who could finalize your block in that minimal time. >> Now everyone does at the same time. That's the leap. >> Cool. Okay, this is an older an older system, but like do you remember grandpa from Polka Dot? >> Didn't they do something a little bit like this? >> Babe and Grandpa. >> Yeah. Did was there any was there any sort of echo of this there? >> So back then the idea was that you would have a separate block production from finalization gadget.

>> Yeah. >> So babe was like build the blocks we don't care what happen well don't care what happens with finalization and then you have a separate gadget that kind of follows along and finalizes. This is also how E2 works just to be clear. Okay. Same same concept. I have completely departed from that line of research. Uh we do exclusively single what you would call like a singleshot protocols where like you that may not be exactly the right term here but like the view production happens at the same time that you would determine finality. We don't have like block production or view production happening before finality.

>> Okay. >> Turns out for engineering just much easier to reason about. So, in terms of the overlap with what this is and like what you would do for that, I would say architecturally pretty different. I'm not quite sure how close they might be. I haven't really thought about it from that lens. >> For some reason, it just sort of like for me it gave me a little memory of of that protocol, but maybe it's not connected. >> What you have to reconcile with in Grandpa, which is arguably related, is that people collect different votes at different times. >> Okay? And then you have to land somewhere where you all agree on the same finalized context of the log.

>> Yeah. >> And so but that's I think more a problem just inherent to consensus than I think it is like particular to grandpa. So I wouldn't like overstate the similarity between those two. >> But yeah, thanks for explaining Multimed to us and some of the >> two days old. So this is this is fresh >> days by the time this the episode doesn't come out tomorrow. So it'll be like in a week. But yeah, >> fresh on the farm, bleeding edge. Yeah. Hopefully we don't find an issue with it before then. Yeah. >> Yeah. That has sometimes happened with our episodes where like we'll record and then release two weeks later and in the meantime, you know, some crazy event in the ecosystem had happened. Patrick, it's been really cool getting to know you again and learning about all of your work at Commonwear and like what

Commonwear is doing. I did I did actually want to ask you, how big is CommonWear today? got we got 11 engineers and a lot of LLMs. That's pretty much >> so I mean I I've been inspired inspired by the whole like some of these stories where you like I don't know Instagram sold like five people like WhatsApp had like 22 people or something like that like we are willing to spend money instead of hire more people to keep the team like really capable and cohesive. >> Nice. >> So yeah we try to keep the team as small as we can get away with has been our goal. Very cool.

>> Yeah. But thanks so much for sharing with us kind of your story. The story of common wear, the story of sort of the problem spaces that started to open up after you you thought it was all solved and thanks for walking us through. >> Research is always required. The fundamental problem >> really comes from us all. Man, it's such a shame. >> Started started from Wisconsin and now we're here. So that's the way we we describe it. >> No. Yeah. Thank you, Pat. Always always fun. Always a pleasure. Always a good time to hang out, you know.

>> Thanks for thanks for having me asking, you know, a number of good questions on things. And, you know, next time, maybe in six months from now, I'll just send my agent to do something like this. >> Sounds great. We'll see how it goes. >> All right. Uh, I want to say thank you to the podcast team, Rachel, Henrik, and Tanya, and to our listeners. Thanks for listening.