Episode 391 - lean Ethereum Part 1: Introduction with Justin Drake

Transcript

Welcome to Zero Knowledge. I'm your host, Anna Rose. In this [music] 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 [music] online. This week we kick off our six-part miniseries on lean Ethereum. For these special episodes, we have Nico as our host and we are also releasing this podcast in video form over on our YouTube channel. Links are in the show notes in case you want to check it out over there and be sure to subscribe to the YouTube channel while you're at it.

For this first episode, Nico is joined by Justin Drake, researcher at the Ethereum Foundation to introduce Lean Ethereum. They discussed this vision for Ethereum spanning the consensus data and execution layers. Justin outlines how postquantum cryptography, faster finality, and enshrined ZK are all being used to futureproof Ethereum's core. They also lay out some of the topics that will be covered in subsequent parts of the series. Hope you will watch and listen along and let us know what you think. Before we kick off, three quick points. First, ZK Summit is coming back with its 14th edition. Applications to attend and or speak are now open. It will be on May 7th in Rome. So, I hope

to see you there. Second, ZK Mesh Plus. Our paid subscription tier is rolling. We have released a few bonus clips over there as well as some of our exclusive research reports. If you want to get access, please join the paid tier. Third, if you're looking for other ways to support the show, we have donation accounts visible in the footer of our website. You can donate in ETH, BTC, Ze, or Soul. Support definitely goes a long way. So, if you do decide to donate, thank you in advance. That's all for now. Links are in the show notes. And here is Nico's interview with Justin Drake all about lean Ethereum. [music] Today I am here with Justin Drake,

researcher at the Ethereum Foundation. Justin, you were on the show recently to tell us about uh the ETH proofs initiative. You're back very soon after to tell us about something that I think is a lot bigger and a lot more ambitious uh and that's Lean Ethereum. Yeah. Welcome back to to the show, Justin. >> Absolutely. Thanks for having me. So, this is the first episode in a series that's going to be dedicated to Lean Ethereum. So I was hoping that you could help us introduce the topic and understand what it is. >> Absolutely. So Lean Ethereum has multiple components that correspond to the various layers of Ethereum L1. We have the consensus layer, the data layer, and the execution layer. It's

easy to remember because it's CDE E. Um >> at the execution layer we have the zkms which is what e proofs is all about increasing the the throughput of of the L1 and increasing the gas limit >> and then uh at the consensus and data layer one very big component is postquantum making sure that we have postquantum attestations and postquantum blobs right now we're using BLS signatures and KZG which are not postquantum um and at the consensus layer Another aspect is improving the speed of inclusion of transactions and the speed of finality. Uh so we want to shorten the start durations and

accelerate finality. And here we have this notion of of endgame finality. Um and one of the observations for the consensus layer is that the the two big upgrades postquantum and faster finality they're very invasive. Uh and so what if we were to combine them in a single fork because each individually is largely a rewrite of the consensus layer, >> right? So this is like Ethereum from the ground up a whole new system. >> Yes. So when we do um you know embrace the ambition of making this this this rewrite then we get further opportunities. So one of them is that we can um clear up a lot of technical debt.

For example, we can rewrite the spec using the the latest and greatest techniques. Um, and we can also make sure that none of the components are snark unfriendly within the beacon chain. And that gives us as a as a cherry on top the ability to snarkify in real time the consensus layer which will help for all sorts of use cases uh like um being able to have uh trustless wallets um that are more secure than the current light clients as well as having uh very trustless bridges between the L1 and um as well to unlock uh cheaper um validation for those who are on

extremely weak devices and the meme is, you know, a Raspberry Pi if not a Raspberry Pi uh Pico, which is the the $8 version. >> Wow. Okay. So, through the layers, consensus, data, execution, are we going to see ZK everywhere? >> Yeah. So, one of the the things that we've we've decided on relatively early is that we need ZK at the execution layer for the for the ZK VMs. And this is back to ETH proofs, the sort of stuff we were already discussing last time. >> Yes, exactly. Um, but you know, I would make the argument that we also need ZK at the consensus layer. And the reason is the postquantum signatures are very very large and so we

need to find a way to aggregate them. Um, and the only good way uh to do that is using SNOS. >> Maybe we can have a bit of context here. So what's happening at the consensus layer? Why do we have signatures? and where do we want to aggregate them and how does ZK fit into all this? >> Yes. So, um the way that proof ofstake works is that you have these votes uh every epoch. They're known as attestations and we have basically every validator make a vote per per epoch and that corresponds to roughly 32,000 signatures per slot. So, we're talking thousands of votes every single second.

And in order to process this incredible throughput of of signatures, we need to to aggregate them or or batch them. Uh and that's for two reasons. One is to save on bandwidth and two to save on verification time. Because if each second each signature takes one millisecond to verify, then you know if you have thousands of them per second, that would be seconds of of verification time. Uh you wouldn't be able to keep up. uh but the problem becomes even more pronounced in a postquantum world and the reason is that BLS signatures are 92 bytes sorry 96 bytes uh whereas the the the the postquantum signatures are you know in the best case on the order of 1

kilobyte so 10 times larger >> you know we need to find solutions to recreate this idea of aggregation at the consensus layer and there's just not many options um there's only two flavors of postquantum cryptography that you we would consider from a maturity and and security standpoint. These are the two flavors that have been standardized by NIST specifically the hashbased signatures and the latisbased signatures and you can try and and and do aggregation with with latisbased signatures but it's quite hard and it's also quite inflexible. So we have these these requirements that we want to aggregate across distinct messages. We want to be able to recursively

aggregate. So if you have aggregator A and aggregator B each produce their own aggregates, you want to be able to meta aggregate uh these signatures. >> All these nice things BLS does and postquantum doesn't. >> So BLS unfortunately doesn't do the the meta aggregation. So if you have two sets of signatures that you're aggregating and they have a nonzero intersection, then you can't do the aggregation there. And so what we end up doing in practice is just concatenation of aggregates BLS signatures. And that works fine because the aggregates are so short. They're just 96 bytes. But if you if you're dealing with much larger objects, then aggregation, sorry, concatenation just doesn't work anymore.

And so we're kind of forced to go down the the route of of of SNOX to solve this aggregation problem. And one of the things that we want to do is make sure that whatever cryptography we put in place for the consensus layer is harmonious with the rest of all of the other layers. And so the solution that we put it in place which is called lean VM or introduced for the consensus layer. It looks like we actually have an opportunity to deploy it at every single layer the data layer and the execution layer in order to solve the problems that we have uh there as well. And my personal belief is that lean VM is actually going to escape the bounds of Ethereum um for all of the blockchains or most of the blockchains. And the

reason is that every other blockchain has a very similar problem at the execution layer. So they're >> um they're using for example ECDSA as the way that you sign transactions. And if blockchains like Bitcoin or Solana were to move uh to to a postquantum system naively without the aggregation they would suffer roughly a 10x decrease in in performance. So Bitcoin would go from 3TPS to 0.3 TPS [laughter] and Salana would go from you know a th00and TPS to 100 TPS. >> And so as far as I can tell the FM foundation is the the primary entity that's looking into solving this this uh this problem for the industry. And I think we have an opportunity to be a

first mover, set an example, and ultimately create a a blockchain standard. >> So you've introduced a lot of different ideas here already. One was snarks to fix the aggregation problem, and maybe we should explain how that works. And then lean VM like what is that and how does that fit in? >> So when you have a snark, you can prove knowledge of multiple valid signatures and these signatures can go in the so-called private witness. uh they don't need to be shared as as as public inputs which means that you don't actually have to put the input signatures on chain. Um and one of the the crazy consequences of that is that moving to postquantum will actually be a scalability increase

relative to what we have now. And the reason is that you have a fixed amount of data footprint per per block which is just the one proof and everything else uh from a signature standpoint is is is for free. actually because we have a proof per block already with the ZKVMs >> there's there's like zero marginal overhead to moving to to postquantum um which which is very nice >> right so we'd have one snark that proves the consensus stuff and the execution stuff at the same time >> so we could do it that way but more likely than not there would be sub slots each with their own separate proof but um if you look at the execution layer there's two parts to that one is uh the ZKVM stuff and two would be um the

aggregate signature for all of the user transactions and those two proofs can be merged uh in in in a single proof and you know you you asking why do we need lean VM well first I need to explain what it is >> that's actually what is it [laughter] >> leadvm is a very very minimal ZKVM um to tackle specifically hashbased cryptography So the proposal that we have here is to have these hashbased signatures both at the CL and the EL um and to basically have a very minimal ZKVN that gives us the flex the expressivity the power to aggregate them

but also to recursively aggregate meaning that we want the ZKVM to be able to verify its own proofs which are also hashbased uh proofs right so the idea is to build everything with a single hash function and really embrace the the robustness and simplicity that that that comes with that. >> Okay. So, this is the idea of like a custom VM. This is not a risk VM. This is not a circuit either. It's a VM where you design the ISA yourself. [sighs and gasps] >> Exactly. It's like a ultra risk. So risk stands for reduced instruction set. It's like ultra reduced. Specifically, we have five instructions. uh add mole jump a memory instruction and a a hash pre-ompile peron [clears throat] 2.

>> Um so it's as minimal as as as as you can get. >> Okay. So that thing is going to be hashing all the time. Yeah. >> Yes. Um so [sighs] when we do the benchmarks we actually reach a point where the hashing is so optimized um that not that much time is spent on hashing. Maybe you know 10 20%. So all of the glue logic uh you know that expresses for example how you're going to you know verify the Merkel paths not just do the hashing itself that is starting to to to dominate uh and very roughly speaking one cycle of the ZKVM is roughly as expensive as uh one hash function.

>> Wow. Okay. So we said consensus was a challenge because the signatures were big and we needed to aggregate them. solution there was a snark with a dedicated VM for it. Um does the efforts from ETH proofs feed into what was what is happening here or are these distinct? >> So right now they're they're quite distinct. Um so one of the technical details with the consensus layer is that we have to enshrine it from day one. Uh meaning that it has to be part of the protocol and that has to to do with slashing. So in order for everyone to come to consensus that something bad happened, we need the proof to be to be enshrined. With the ZKVM, we can take a different approach uh which is um to

rely on off-chain proofs, if you will, that are not enshrined uh at at the beginning. Um and this is actually quite appropriate because what's happening at the ZKVM level is a lot of complexity, right? we're dealing with the entirety of the EVM plus uh these the the the risk five virtual machines. And so more likely than not in the short term every implementation will have a bug. And so you want to hedge against these bugs through diversity just like we have diversity at the E level. at the CL we can actually kind of oneshot it if you will with formal verification uh and be have very high confidence that there's

no bugs because we're dealing with an object that is that is so simple. >> Yeah. So actually this is a good segue into another aspect of lean Ethereum which I find super interesting is formal verification. Um >> is it coincidental that it's called lean like the theorem prover or not really? >> It's coincidental. Yes. >> Okay. [laughter] Okay. And so I guess maybe it's a good time to introduce our our listeners to what formal verification is and how it helps with our certainty that these systems can be secure.

>> Yes, formal verification can be applied both to mathematics and theorems and to code. In the context of mathematics, you would have some sort of a theorem statement and instead of writing the proof for that theorem in a math paper or or by hand, you would actually have a machine checkable uh proof. And what m machine checkable means is that you start with like the very basic accents of mathematics and then you you build intermediate lemas in order to eventually reach uh your your lema. And we want to have formorification of all of the mathematics that is involved [snorts] in lean VM. So for example there's the so-called proximity gaps result which is you know the the most

involved uh apart mathematically um and here one of the crazy outcomes is that um to a very large extent this was this has been proven a couple weeks ago uh by by an AI. So, Alex Hicks, who leads the formal verification effort, um kind of gave the theorem statement of what's called the uh the polish spillman lema. Um >> he let the a this kind of AI that specialized in in mathematics run for eight hours. It cost him $200 and in one shot it was able to prove the dilemma.

And basically what it means is that there's just a bunch of um you know lean for code that you can just rerun and know with extremely high certainty that the this dilemma is is indeed correct. >> This is the same property that the EF put out a million dollar bounty for. >> Yes. So there's there's two separate things. So, um, we have this this $20 million formal verification effort that Alex Hick is is leading. Um, and we've been giving a lot of grants for multiple different formal verification efforts.

And then there's this other thing which is the the proximity gaps. Now the way that the proximity gaps is handled in practice is that either you go with a proven proximity gap >> um meaning that we know for sure that that we have soundness or you go with the best known attack to the proximity gap and you're making a conjecture that the best known attack of today will remain the best known attack uh in in in the future. And historically a lot of the teams were using this this conjecture and we're trying what we're seeing right now is the industry migrating from conjectured proximity gaps to provable proximity gaps. Now the

reason why a lot of teams were very tempted to go with uh conjectured proximity gaps is that they give you roughly a 2x improvement in in the proof size. And so we have this additional $1 million bounty for anyone who can close the gap between provable uh and conjected. But that is separate from the $20 million formal ver verification. >> Okay. And actually, if anyone feels like we've been over this super quickly, don't worry. We have an episode planned on proximity gaps and like all these security questions and an episode planned on formal verification with Alex who you were mentioning a second ago.

>> Yes. And like very very briefly in addition to proving the theorems and the mathematics is are correct, we can also prove that the code is correct. So when you're building a ZKVM for example, you want to make sure that the arithmetization corresponding to your ISA is correct. And what you would do there is that you would have a a formalization of the ISA and then you'd have the implementation in code and you want to show that these two things are equivalent. >> Right? So here is what I want my machine to do. Here is the polomials I generated from my code. Do they match?

>> Exactly. So airtight security through and through essentially. >> Exactly. It's what we call end to end formal verification. And when you're building a ZKVM, there's multiple layers of the stack. You know, there's the the mathematics, there's the back end, there's the front end, and in our case, there's also the program that you could be running on top of the ZKVM, which in in our case would be the uh the signature aggregation program as well as the recursive verify. And that's also something that we want to formally verify. >> Wow. So we're inventing LINV LINVM.

You're formally verifying LINVM and then you're going to formally verify programs written for LINVM. >> Exactly. Yes. >> Well, [laughter] we're talking a lot about hash functions, uh, signatures from hash functions, snarks from hash functions. Uh, the elephant in the room is which hash function are we going to use? >> Yeah. So the answer is that we don't know today but we do do have a top candidate uh which is called pedon 2. Uh it's very very snark friendly uh meaning that if we build our basic um hashbased stocks with it we'll be able to aggregate way more signatures than if we were to use a traditional hash function

like 256 >> uh or or or or Blake. we're talking about, you know, more than a 10x uh improvement in in performance. Now, when we introduce a new hash function, there's this baking time for the community to uh get comfortable with the hash function. And the heristic that I have in mind here is roughly 8 years. And the reason is that when Satoshi picked Shatu 56, it was 8 years old. And when Vitalik picked Ketchac for Ethereum, it was also eight years old. Okay. Um and p done is you know roughly like five six years old. So there's like more time that we need in order to to to have confidence in it. But uh we don't

want to just like wait for this this this function to age naturally. We kind of want to accelerate the the maturation process >> and we're we we're seeing that in multiple ways like one is that the foundation is organizing all sorts of workshops. So we had three last year we're going to have at least two this year. These are cryp crypto analysis workshops where we invite experts, we give them grants to try and break the the hash function. We also have a natural bounty program which is which is happening through the the the ZK rollups. So yeah, several billions of dollars are being secured today um by Padon to indirectly through the ZK rollups. And what we announced uh maybe a week ago or so uh is this new program

called the the Pedon prize which is an additional $1 million for um anyone who can uh break Padon and we'll be you know revealing some of the details of that prize in Eve proof call number eight uh which should be on March 20th. >> Amazing. It should be worth mentioning as well like why can't we just formally verify the security of pose >> when you do like a cryp cryptography um you have these the these basic uh computational assumptions >> it goes back to um what I was saying about the the proximity gaps you know the the the best that you can do is um look at the best known attacks um and try and improve those but you can't

actually uh prove them and so you know you can reduce everything to your your your most minimal assumption which might be you know that the hash function is pre-image resistant or second pre-image resistant. Um but like proving that it is actually is is is is extremely difficult. The best that you can do is prove that it's it it's not uh secure by showing an algorithm that that that would break it. Now, interestingly, um, and this is a bit of a of of a side note, but the the cryptography that we're building, um, doesn't require, uh, what's known as collision resistance.

>> Mhm. >> And so the the hash functions that have broken in the past, for example, SHA and MD5, um, they've lost collision resistance, but they haven't lost, uh, second pre uh, pre-image resistance. Um, >> okay. And so um if we were to instantiate the cryptography even with such a a broken hash function like MD5 or Shiaan the schemes would actually be still still secure. And so >> okay >> even if you know poseon were to break its collision resistance you know we would have a period of time where you know we could safely migrate away to something else and that could act as a canary in in the coal mine if you will.

>> Wow. Okay. So second pyramid is sort of a weaker security property than collision resistance and so or like a weaker requirement. I guess you can break one without breaking the other, right? >> Yeah, exactly. Yes. Um >> yeah, it's easier to break collision resistance than it is to break second preeage. >> Okay. So I think the picture is starting to draw out. We have snark signatures overlying on uh poseon. Um I'm curious how how is this going to be rolled out sort of actually maybe two questions in one one is like we wanted more throughput how is the network going to survive more throughput when our signatures are bigger and then

the next question is how do we test this out so the the throughput aspect uh of of the the ZKVMs in some sense is largely at this point unrelated with with with postquantum um >> so really what we're trying to do at the consensus layer is retain the throughput that we have today. Now what is the throughput? I mentioned it. It was 32,000 votes per slot which is a you know a couple thousand uh uh signatures per per second. >> Um and uh you know we want we want to retain that. Today we have a million validators and the the the voting is spread over 32 slots. But in the future we want to have closer to 32,000

validators each casting a vote every single every single slot. And this is the basis of of faster finality. Um now in in order to retain this this voting uh throughput we we need to come up with the equivalent of BLS. The the basic idea here is that we we we take all of the attesters and we split them up in subnets uh within an individual subnet which might be only a thousand validators. We do a first round of of aggregation. Um and note here that recursive aggregation is already useful in case that um you have the aggregator doing censorship of a minority of

validators. So anyone can take the best known aggregate and enrich it with uh any any censorship that that that might have happened. And then we want to do aggregation across the subnets. Um >> so that we have like a a final aggregate if we have you know two this two layer of aggregation but we're also considering what's called threelayer uh aggregation where [snorts] we have uh you know very very small subnets to start with and then we do aggregation across uh some some some subsets of those and then we do the the the final proof again.

The advantage of moving to three layer aggregation is that it would allow us to have significantly more validators uh because basically the number of validators uh would go to the the power three um as opposed to the power two um with w with with with two layers. And one of our, you know, end games [clears throat] that we want to try and and and achieve here is to to have a a million validators be able to participate in Ethereum proof of stake so that the minimum deposit amount to become a validator is as as low as possible.

>> Right. Just to make sure I understand this correctly, this layering of aggregation layers is completely new to lean Ethereum. It's not something that's happening already with BLS, right? No, it it is actually happening with BLS. So, today we have the the two-layer aggregation. We have some constraints with BLS that I mentioned. So, for example, uh to solve the censorship problem, what we what we're doing is that we have um multiple nominated aggregators per subnet. For example, we have eight of them. Um and they each do a best effort at doing the aggregation.

And then the final aggregate is basically the concatenation of these eight things. But this concatenation idea just doesn't work very well uh in in the context of postquantum because you're dealing with with with much bigger objects. And >> ironically um the the flexibility that comes from recursive aggregation allows us to have um a much wider design space for the aggregation topology. So instead of nominating eight aggregators per subnet, we can just allow anyone who wants to be an aggregator to be an aggregator. So [snorts] it's it's permissionless and it can be much more unstructured. Instead of being like a strict hierarchy of aggregators, we can um we can have more of a kind of uh

fluid emergent mesh network type of of aggregation. >> Okay. I want to touch upon sort of the last layer that and not aggregation layer here like the the CDE layers you mentioned at the very beginning. Uh we talked a lot about consensus. We talked a bit about execution data we didn't really mention. Is that also part of the Line Ethereum upgrade? >> Yes, it is like moving the data layer to uh postquantum blobs is is part of it. Um, and one of the solutions that we're considering doing is to take your blob, uh, erasia code it, uh, for example, with a read solomon code, uh, merkelize that and then prove within leanvm that

the Merkel route is correct. >> Beautiful. So, lean VM once again rears its head. >> Yes. Uh, exactly. Um, like ultimately we're trying to have as many synergies as possible and reduce the total amount of cryptographic machinery and since we're biting the bullet with this cryptographic uh ZKVM, we might as well use it for for many different layers. Um, one of the, you know, question marks is, you know, is it going to be efficient enough to to to snarify, you know, this eraser coding and and the Merkel tree, especially when we're doing dealing with very very large blobs. Like one of my hope is that we

can unlock the so-called uh terra gas per second uh kind of error where all of the L2s combined that consume uh ERMDA can have enough DA to support the the one teras per second which corresponds to 10 million uh transactions per second. And from a throughput perspective, we're talking about one gigabyte per second uh for for all of the L2s. And uh it's several orders of magnitude larger than what we have today. >> Mhm. I think that cuts back into the ETH proofs discussion we had last time you were on the show, I think almost 6 months ago.

>> Yes, exactly. So on L1, we want one gigas per second, which is 10,000 TPS and a thousand times more for all of the L2s combined. >> Amazing. So so far what I have planned for this series Justin is to talk about uh the signatures in one episode and how we agreed them to talk about the security of p postquantum uh postquantumness I guess or postquantum migration. Um we'll have one on lean VM obviously and implementing all this. Um there was one about the networking devet and one about formal verification. My question to you is have we missed any big aspects and is there something we should cover you and I now before splitting off into smaller episodes?

>> No, I think I think this covers it uh a lot and um you know one of the the difficult things with the leaner project was to kind of find the right people to work at the different layers and one of the the kind of observations is that we have a very lean team. Um, and I've been trying to put forward this meme of, you know, the lean Ethereum Foundation where, you know, we kind of have this this elite team of of of devs and and and researchers. And, you know, nowadays, a lot of the the the help is coming from from AI. So, you know, just recently, you know, with um >> with Opus 4.5, you know, things kind of flipped where AI was kind of net, you

know, slowing things down for for some developers and now now it's speeding things up and um you know, for example, on lean lean VM, we primarily have one person uh who who is Emil um and you know, uh he's he's possibly can single-handedly uh do most of the the R&D for for the virtual machine >> which is absolutely wild right because two three years ago we had like entire teams dedicated to coming up with a VM implementing it yeah it it's it's absolutely wild um [snorts] I mean we also have a lot of the heavy lifting that's happening in the libraries underneath it so we're reusing plunky 3 uh and we also have an implementation of

Word in Plunky 3 which is is doing a lot of the heavy lifting and There was a lot of work done on on Tomar and others on that specifically. >> That makes sense. So Justin, what's I guess next for Lean Ethereum? What's the path forward and how can people follow along if they're interested? >> Yes, we have a weekly call which is the the postquantum interrupt call where a lot of the new teams that are that have started implementing the lean spec uh are collaborating through through DevNet. So this is very technical. Um we also have various events that uh are being organized. So uh in KN at EFCC uh we're going to have a postquantum day uh that we're calling forth mode. Um and

we're also going to repeat the very successful postquantum workshop that we did last year uh in in October. So this is uh a three full day uh postquantum workshop uh in in October. Um and um yeah, we have a limited number of seats, but uh if you are interested in it, please feel free to DM me. >> Yeah, having been to the previous one, I can only recommend it. It was truly amazing experience. It felt really, you know, like the imitation game, Bletchley Park, Alan Turing kind of situation.

That's kind of what it felt like. This group of people meeting every day like let's do this postcontent thing. Yeah. Truly amazing workshop. >> Yeah. And like various papers came out of it, possibly even one from you. >> Yes, absolutely. Uh we were talking about Fry and like how to do things simply. Um and all the proximity gaps of a lot of them came out of workshops happening there. Uh and we're going to touch upon this in the third episode actually. >> Yeah, absolutely. Um and you know I think the the research and the development will be will reach a point of maturity that you know the the the vibe of the workshop will be slightly different. It will be more about productionizing and standardizing these

things and how do you make sure that it's application that's applicable not just for Ethereum but also for Bitcoin. And I'm hoping to make a big big big effort uh to make sure that you know the Bitcoiners and the Sena folks will also use it because it would be a bit of a of a disaster if every single blockchain came up with their own postquantum solution. >> Um and that uh yeah, lots of duplication of effort. >> Yeah, absolutely. Justin, thank you so much for coming on the show and for introducing Lin Ethereum. >> Absolutely. Yeah, it's it's super fun to get to this series and to get to dig deeper with all this amazing team that you mentioned because a lot of the guests for the next episodes are part of that like core lean team, right?

>> Yes. You're in for a treat. >> Yeah. So, thank you very much. I also want to thank uh the podcast team, Anna, Rachel, Henrik, Tanya, and Hector. To those of you catching us on video, thank you for watching. [music] And to our listeners, thanks for listening. >> [music]