 So the topic of today's panel is the ZK-AVM security, and how can we be convinced that the ZK-AVM implementations that we're all working on are secure. So today I'm joined by Hai Chen, who works with Skoltech and has been like leading engineering there about implementing the ZK-AVM. I'm with Jordy Bolina, who's part of the Polygon Hermes team and has been leading engineering there. One thing that strikes me about like the organizations of Polygon and Skol is that their willingness to collaborate. They've both been like big collaborators in Xerox PARC and I'm now exploring like how to secure ZK-AVMs together. I'm also joined by David, who's on the Ethereum Foundation security team and has a traditional background in security and audits and things like that. So I hope that today we can have a nice kind of exploration of how we're going to be able to make the ZK-AVMs that we've been working on secure. So that's my first question. How can we secure the ZK-AVM? How can we secure the ZK-AVM? Yeah, so yeah, hello everyone, I'm Hai Chen. So I think like the ZK-AVM is a very complicated circuit. So I think to make sure like the ZK-AVM is secure, I would definitely need to go through like the all several auditing, like having auditors to look at the circuits. And probably I think like the maybe not even like the one single team of auditors, maybe have multiple teams look at that. Again, again, and then we can like find some bugs and then we can fix that. And then after that, I think we also should do like the, on parallel can do some bug bounty program, which like have like the more community members who like the interesting to looking into this stuff and then find any different bugs or attack those things. So I think like to have it's more secure. And then last I think maybe a little bit like to say like have some more advanced techniques like the very nice people and other people like they would describe have some more formal very clear tools and then for most do like a model checking those kinds of stuff. Also like I think like initially maybe it's more scalable to a very large circuit, but I think we can eventually get to there. Yeah, that's like my. And maybe just to compliment that and the first of all open source. That's probably the first step in securing something. Cryptography, biofuscation or just you know, private cryptography, this has the humanity already have been tested that this doesn't work. Half our experience, Microsoft, Google, IBM. So big corporations that just pay a lot of money just building private cryptography systems. We know that this is not the way to go. We need as many as possible of all kinds to take a look at the code, at the protocols. And that's why it's the first. So the first must, this is not enough, but the first is that this needs to be open source and the people and especially the users have to have access to this code. This is the first step. And from now on, let's start as in says it's a complex system. So the first thing is the first problem that we are challenging is that who can't review that? Because it's something that's new. It didn't exist before. We are creating a lot of primitives, a lot of, now they're in mitigation, all the, because we're doing a lot of tricks and a lot of things and there is no experience on that side. So the first thing is who's gonna review that? Who's gonna take a look? Who has the capacity to look at that? So the first step and this is where we have started. Is partnering here together just to, that is to somehow start teaching, start explaining, explaining to the auditors, explaining to the community, explaining to anybody that's interested in the system. This is the first, so this is for sure is the first step because we need to open and the first, open even if it's open source, if nobody can understand what's in that repo, it's like being closed source. So we need this to open and to explain, to teach, to spread who we are working and publishing that and this is the next step. After that, so when we have this, let's say minimal, minimal critical mass of auditors and so on, next step is okay. Then here is how we organize. Here is how we organize the auditing and because we need to be here a little, we need to talk about procedures and we need to talk about how we specifications, how we write the good specifications, how we can split these specifications and have them in the procedures. How can we clean the code? How can we go? And this is gonna be the next step. And once we have this clear, we have this specification phase, quite clear that the things is quite clear, then it's a matter of just taking a look. And even that, we will never have the warranty like any cryptographic system, we will never have the warranty that the system is gonna be 100% safe. Here, we have the responsibility, projects to invest as much as possible in resources at least in the Polygon side, I'm sure that in most of the other projects too, they will not launch anything until they feel comfortable enough that the system is reasonably safe. Okay, thank you, Jordy. Sorry to interrupt you. David, do you have any comments about this? Yeah, I think open source, multiple audits, I think education is important. For me, coming from like a traditional security research background, I think we have very strong software security research capabilities in the community. I think that there's multiple components here, there's like the L1 verifying contracts, and as you've seen in previous talks, three or four years ago, we didn't really, we just knew what re-entrancy was because the big Dow hack, now we have like 101 best practices for solidity coding. So we have like these different components, pillar to stand on, unfortunately with security, it's kind of the weakest link issue here. So like we've got a great bug tracker for ZK stuff, but I kind of, where I see like a large gap is that we have a lot of academics that come from like a formal verification or like a mathematical background. And then we have these people that understand like implementation. So it's great to want like multiple audits, but we don't really have multiple firms that know how to audit. So the education stuff is like critical here. Some of the tooling stuff is reusable with like a formal verification. But I think like over time it's gonna be about this collaboration. I think that this is like critical. I think you can look at some of these things and say like, hey, all these L2s are competing. And I'm not sitting, I work for the EF and I care about systemic things. So I'm not like on an L2s team here. But in the long run, like you could say, oh yeah, it's a zero sum game for these L2s. But if something catastrophic happens to any of them, I guarantee you it's a positive sum in the negative direction for everyone. Nobody is gonna trust billions of dollars on TBL here. And they're all just gonna go to optimistic roll-ups, right? So I think this approach here, I see Polygon, ZKVM folks in the crowd. I see all these people working together. And Xerox PARC kind of like hosting this community where academics can come together. I think that this is kind of the only path forward because it's the only missing thing that we have here that we don't have some like tried and true testing methodology. And so I don't think this is anything new for the blockchain community. The prerequisites to understand smart contract security require you to understand decentralization, things like oracles, all these new preminips. And so we've had this already. We've seen people tackle things where you have to not just be an expert in like one domain, like software security. You have to understand economic security and all these things are the whole system falls apart. So I think this is just gonna be an evolution. And I think that there's like, we're on the correct path forward. Thank you. Thank you, David. So the ZKVM is a very complicated piece of software. It has many components and those components interact with each other. And my next question is like, what components are you all specifically worried about? What keeps you up at night? Yeah, I think like the, so there are multiple pieces in the ZKVM circuits. So it's not like, so architecture is not only one single circuit. It's actually a set of circuits connected with each other. And then I work together to, to soundly like to verify the EVM behavior is correctly that the trace is correct. So I think like that the first of all, like the most important piece is like the original, the EVM circuits, which is the most essential piece. It's kind of like the, you model like the EVM of course and then all the state foundations correctly. So those kinds of things like I think, so I think like the people usually like to know how to do like the so integers, like big integer multiplications and then integer additions. But like, if you need to be true, like that all of the constraint is very true to what EVM specs it does, like the what is in yellow paper defines how EVM works. There's lots of like the corner cases if you look into the details. So those are corner cases that usually will be easily overlooked. So I think that's like the one thing like very important to do to check. And then the second thing is that, so the circuits need to work together. Then you connect through some lookup tables to be sure. And then certain things like maybe checking one circuit and saloon property will be guaranteed by another circuit. Then how can we guarantee that that's like the combination of all the circuits is a sound and then complete the ones like to check everything that you have inside the EVM to fully guarantee that the ZK EVM is correct. I think like this is the kind of two biggest things like I think it would be important to audit the ZK EVM. So like you're saying that like the two big issues are the corner cases and the interfaces between the different components. Yeah, yeah. Nice, okay. Yeah, I agree. I think that makes sense. Jordy? You'll have for Kenneth, maybe a different architecture on that. So probably the pieces are different on that side. Here I would say two parts. One is the what we call it the ROM or if you want is the code that actually implements the EVM itself. There is a lot of lines of code and this is like writing a smart code track. It's again a single mistake in one of the lines can screw up everything. And this is, well, this is concerning because it's critical code and if you see the number of lines that are in there are a lot. Actually, you can imagine geth but writing in assembly. It's a complex code there. So this is probably my biggest concern at this point. And then there is the magnetization. In our case, the magnetization is probably much more simple because at the end we have just a kind of a process over there. So the logic is more in the wrong part. But it's not a lot. It's a very new language. It's a very new thing. It's something that we don't have experience designing polynomial identities on that side. So and it's very, very easy to miss something or don't take in account something and so on. So probably these are the two things that are more concerned but I cannot forget even the smart contracts that are in there. And then more things that are more basic if you want but they need to be safe too. I find that there's this misunderstanding in the space where people equivocate like L1 to L1 bridges with L1 to L2 bridges. And I think that... It's the problem is that they call it even bridges. No, I would like to go back to the double pegging for chain to chain. And this is maybe it's a bridge but it's just a smart contract. It's a mechanism to move in funds but it's not what we understand as a classical breach of just a kind of a multi-seq where you need to trust some party. Yeah, absolutely. So to be clear, L2 bridges are much more secure than L1 bridges, hopefully. Yeah, so I think this kind of just like points to a lack of like true terminology. Everybody's marketing right now. I would say like L2 bridges, I would call them fast bridges where there's like a third party and they're taking the risk. So if there's a double spend on one of these bridges like the person that's getting the 1% fee for transferring your off of an optimistic roll-up and letting you not take the seven day wait period or between two ZKVMs or whatever like they get a yield and they take the risk and they're the ones that's like out of luck if something happens. For me, like I'm not sitting here thinking like what's the worst zoom day scenario for my ZKVM. I'm thinking like what happens to ETH when something bad happens to a ZKVM? And I hate to say it, but like something bad is gonna happen. We've seen double spend bugs in Aztec. We've seen them in ZCash. Like these things are a big deal. The one thing that's like the saving grace for Ethereum here is that we have a native non-privacy like token standard at the base layer. And the reason this is important is because you can see when there's insolvency in a contract. Whereas if you just had like the ZK like roll up and this is your entire ecosystem and everything is either private or it's using ZK to scale, you might not know that somebody's printed infinity tokens or that some of their wallet has negative tokens and that's like how your constraints add up. And so for me, it's like this lack of transparency here. I think that there's some like traditional security like philosophy that we can apply here. You can do things like have like buckets. And I understand like if you're trying to do something like scale this isn't that big of a deal if you're trying to do something like saying private having buckets for like your like zero knowledge cash type transfers like you can think of like tornado cash that it reduces the anonymity set. So like there are some issues here but there are also things that we're starting to see now where you might have like a withdrawal like we do see these like chain to chain bridges that aren't really bridges. They maybe can have like a floodgate mechanism. Like if somebody is gonna drain the entire contract that's probably not normal when there's a hundred thousand users that are using your L2. So like if 10% of the contract exits in a 24 hour period maybe having like these kill switches will be good. And then you can do things like have guarantees where if there is an issue everybody takes a 10% or a 20% haircut on their TBL and nobody's left holding like the complete miss like lost bag. I do think though that like if there is something systemic and like a multi-billion dollar ZK EVM gets basically drained and this is a problem then at least the base layer of Ethereum is like still there and we can still make those like trust and rebuild. And so for me that like the scariest part here is the new technology. I mean people were afraid that people don't really understand like the zero spin problem until they see that like Bitcoin has gone up over time and like well yeah there's nothing behind it. There's all this stuff but there's somebody willing to buy it from you right now for $20,000, right? And so over time people like start to trust these things and I think of like if you guys have seen the Indiana Jones where he's like stepping on the like different pieces and like one of them falls through or like if you're crossing a creek you kind of wanna like feel the rock that you're gonna put all your weight on before you go. I think that that's gonna be the same thing here. We're gonna have to like have people start to trust you know the cryptography that they don't understand yet like this is all moon math to the average person, right? Even like advanced security engineers don't understand any of this stuff. And so there's this gap between the understanding of like you know this like high level multi-dimensional matrix math that you guys all understand. And then like the people that like know what like a traditional software bug looks like. And so that gap right there is the scariest thing and the lack of transparency if something goes wrong is also scary to me. But you know you can mitigate some of that risk by bucketizing and these other things I've mentioned. I think that like what resonates with me about what you were saying was how it's really nice to have this L this roll-up centric roadmap so that we're able to experiment with these new things and we're able to build systems that with time can get the kind of trust that we need. Cool, so my next question is that so when I do audits, what I normally do is I try to find things that like people don't know or that the developer didn't know when they were writing the code. So what are some of the things that people don't know about like your code or things that could be interesting for people to pay attention to? Yeah, I think that's a good question. It's like I'm not sure like you hear audits, what audits does like the when they do like auditing but I think like there'll be seems like I think behind like the farm for the proving system like whether those interface that you use is correct or like even behind like there's some repository like dependency you use like the on top of that whether that's a secure like I think that's one thing. And then I think another piece is like there's a lot of optimization tricks and then that could be make the circuits like less readable which like the I think auditors may find like that's very hard to understand certain part of the logic of the circuits. So I think that seems like we should explain those kinds of things to the auditors. And I think in addition like there's some certain assumptions will make like the certain part of gadgets or part of the circuits like you make certain assumptions and I think those things like are very important maybe only the developers who develop those circuits knows about that. But I think those are things that are important to put down in the specs so that the audits can know like the why you're doing certain things and the why like you're not doing certain things. Yeah. There are many things but one that's important in the concern is that from what we have in the program is a non-deterministic. So it's a non-deterministic circuit. It's not deterministic means that for example you want to do a division actually what you do is you put the result and then you check the multiplication. And tricks like that, well there are many. For example, when we are scanning transactions actually what we are doing is we are hashing all the transactions but we are putting all the data all this data is we call it free input. And then we are, we have a constraint that calculates the hash somehow and then the hash is the public output that's actually what needs to be matched. But you can put anything in there. It's okay because you have to hash. But this kind of, this is something that for a normal programmer for a normal, normal programmer is something strange. It's something that's not used to it's something that's different. And this needs to be explained very well. It seems, this we have seen for example internally in the team, you know in the team and maybe it's just the people that just learn things as people that you know they come from other backgrounds and it's natural that when you first write these programs and you do a lot of mistakes because you don't have, you didn't absorb this concept. Of course you repeat that, you do it again and then the people is getting it. But it's something that needs to be explained very well because I think this could be one of the big sources of problems in there. I actually don't have any real good input for this question so leave it there. Thank you. My next question is how can traditional tools help us when we're trying to secure the KVM? Yeah, let me just start with like one more simple thing. It's like setting everything to zero and see if I can pass. That's like in a lot of cases you can pass which is not correct in your circuits. So that's like one simple thing. And another thing like some basic things like a fuzzing. So I think like in a zero noise circuit I think the fuzzing could be like slightly different. You know like fuzzing arbitrary data that's putting inside your circuit with this but it's very easily, you don't like that. That like it won't pass the proof because like there's lots of constraint checks and you need to be very careful to make some conduct cases to make sure like there's some invalid since you put into the circuit but they can pass that. But I think like in the context of the VK EVM is that you can generate arbitrary trace. Like you can fast the trace of the from the EVM and then see like that's, if that can pass. I think like that's like what Meridaz was just like talking about like that. Those fuzzing will be very helpful to use like generate some valid trace and some invalid trace and then just, and then you can tweak a little certain small amount of things like inside the trace to make things like that should not be passed but if they pass the circuit then there's some bugs inside that. Yeah, in general all these formal verification tools with maybe some adoption, with some adoption specifics but can be used at least to understand better some parts of the circuit. Maybe not like everything but there are specific pieces that are quite clear and that work very well or that can work very well with this tooling. I'm thinking for example, they are an arithmetic machine in our case. This is very clear, it's arithmetic. This must be a multiplication and cannot do anything else. This is something that formal verification people love to see this clear patterns in there. So I'm sure that some work can be done there. If you go to the main processor that is not that mathematically well defined maybe there they have more problems and that here is for free fuselage, it may make more sense. But yeah, definitely can help and here maybe it's a call for people that's expert in some, it's good to understand and to see how this thing works because I'm sure that there is a lot of tooling and a lot of these things that can be very helpful and we don't even know that those tools exist. So here is, it's important for the community to be productive. Here the zero X part people is doing a great job on that and there is people that's already looking at that and there are some ideas that things can be done in there. That's important. Again, it's just explaining because when you really understand the circuits, when you really see what it is, you can find people that's expert in that material that can see ways to, that can help a lot. I think so formal verification has been mentioned, formal verification and it's like, can only do so much in like a regular security testing. And so it just so happens that there's like so much math and these circuits here that it just lends really well to this. So I mean, I'm really excited about that. First of all, it's like the first time I think I've seen it applied in a way where I'm like, well, this is gonna be a big part of my life. I need to go read, you know, brush the dust off of all the textbooks. Another thing is that there's like a lot of, there's like a lot of traditional things with security audits that actually lend well to these also. And like a good example would be like typing, like strong typing is serious and regular security. You have integer underflows, you have integer overflows, you have casting errors, things can flip negative. And you see this in these circuits, but you also see like there's sometimes optimizations and developers do this stuff naturally. A good example is like the ASSEC 2.0 maybe was not ever exploited, but what was reported, there was like an input that was 128 bits or 64 bits. And the actual constraint was only 32 bits. So you could actually provide multiple nullifiers that pass all the constraints, which means you could potentially like withdrawal from Zcash type thing more than once, even though you only deposited once. And that is something that is queryable and you can just have a strong typing system. So like a correct static analysis tool that could have been applied to that and just said, hey, error, manual, like reviewed, required, this input over here is a larger, is a different type than this, like the way it's used and casted over here. So anytime there's like a casting error, you can have this. I think there's gonna be like plenty of other queryable examples like this, where we can apply traditional security tools towards this. Cool. So where do we need to make new tools too? Like Lucas talked earlier about his exploration of trying to make a polynomial solver. And like, there seems like there's a lot of scope for us to explore, like, where would you like to see new tools? Yeah, I think like the, so a lot of tools like I mentioned like the fundamental traditional, like formal verification, they are not very ready, I think for the, proving the ZK like the circuits. So I think like those things like will be very good to have. And then I think like not only like some tools like from the, like for auditing, I think like there's more tools will be very useful from the proof system side. It's like they can provide you a very easy to use interface to generate some arbitrary like the arrow cases like you can inside a circuit and also have a very bug reporting found for where does the circuits fail? As in those kind of bug reporting will be also very important tools as they can auxiliary make the auditing and then make the testing like the more easier and then easier to find some bugs. Yeah, clearly this bug reporting. We launched the testnet, the public testnet on Monday. We already got a report of an error was nothing crazy but it was already a bug that we already fixed. And that was because we published that and somebody just test that and just put something there. So is this the importance of testing the things and I agree the bug reporting is when you see something that goes wrong, you need to investigate until the last and fully understand what's going on because you probably have something that can be getting worse. I think a formal specification for differential fuzzing would be really cool. I think that there's like a value ad when you could take like 10 different ZK EVMs and you could potentially throw a test case at each of them and then you can compare the output states afterwards. I think the value ad here is everybody wants to be part of it because you're gonna know that you're conforming to the spec if your output matches everyone else's. This has been incredibly fruitful with our consensus layer clients in Ethereum for the beacon chain. So we have five clients. There's certain things that are in the spec like processing an epoch transition. And so we can hand it like us form. It's a specified beacon block object and we can run it through every one of them and we can diff all the outputs afterwards. And that's like incredibly valuable, right? Like that's uncovered multiple bugs that would be like chain splitting bugs. And these types of bugs like in the L2 world would mean that you have a state diff between the L1 and the L2 which means double spins and means all kinds of other horrible things can happen. Another thing that I think is really important is like zoomed out from the ZKVM. It's more like about L1 contracts in general and that's like an open security standard of like ahead of time, hey, if you're a white hat and you find a bug, please report it to us. Obviously, we'll resolve it privately but there are some cases in the security world where like a vulnerability primitive drops and everybody hears about it at the exact same freaking time. And like when that happens, you've actually seen this like be fruitful where white hats will front run black hats, they'll steal all the money out of the contract and then they'll return it like and maybe get a bounty or whatever. And so having like a previous specified like, hey, on your bug bounty page, have a little thing down there that's like, yo, if you guys drain a billion dollars of TVL from my contract, this is how much the white hat bounty is and we're like legally saying you're off the hook ahead of time if you return it all and you do all this kind of stuff. And we are seeing some of this stuff kind of come out and flush out in like the DeFi ecosystem. There's gonna be like a spec that's being worked on right now with the open security standard or alliance or something like that. I think there'll be more information about this like in a few months. I think this is all just kind of like in the community right now. But I think that that's gonna be huge because if you know ahead of time, I know a lot of like white hats that they just don't wanna touch stuff like this. So there was like, I think it was like the Nomad hack. A bunch of people were able to just replace like the public key to receive funds and replay the attackers original like exploit. And they were all like a bunch of white hats stepped up and started draining this contract. And it was weird, you can only drain like a little bit at a time. So they were able to like actually recover a certain amount of the funds. And it sounds weird to say like, hey, we're gonna give you a white hat bounty if you hack our contract and steal all of our crap. But this is like a phenomenon that keeps reappearing where everybody hears about the vulnerability at the same time. And we do need people to drain these contracts ahead of time. So like that's one example of something like that. Thank you, David. Sorry to interrupt. Yeah. So my next question is like a harder one. So when would you all feel comfortable to put all of Ethereum's assets inside your CKVM? Yeah, that's a tricky one side. I think like that's all when we launched the mainnet, I think that would be assumed like that's audited. And I'll be like very happy to do that myself. We have the experience of Hermes One and other, you know, other real production life. And yeah, it's a hard decision. In general, I look at days of the people that audit that. And it's who audited that? And I'm talking to the specific guy. I don't care about the brand and it's just the guy and even the kind of questions that the auditor made, how deep they went and the experience that this person have. When you put all these pieces together, so it's just, but you need to know personally like each of the auditors, each of the internal and external auditors and each person of the people, you just check to all the places and here it's just a feeling. It's a feeling that, okay, this should be reasonable safe, but it's a feeling, it's difficult to put the parameter because what you say is, oh, we need two audits, we need three audits, we need four persons, three persons. It's really hard because these persons, now I seen audits, I paid audits that I'm sure that the guys that made the audit, they didn't check the small contract at all. And I've seen that, okay? So it's not, it's okay, we have two audits and I'm not gonna trust it depending on the who made the audit, okay? So that's, it's more personal thing, it's personal people who made what the questions they did, what's can it, where they went and this is when I would feel comfortable. But it's a very personal decision and it's a very feeling decision, so it's hard. To the answer, all of Ethereum's assets, I say never. I think the ZKEVM for L1 will be good for having statelessness and being able to sync a light client instantly without having to download all the transaction history. I think there's value there, but I think just like everything else here, time is the thing that makes you trust it. People trust Uniswap because Uniswap has a natural bug bounty of billions of dollars sitting in it right now, anyone can go after it. So time will tell the analogy of stepping and feeling the rock. I think that's important, but I think that like bounties are a big deal and these things naturally have bounties. Open source is important, you need lots of eyes, but Shellshock and Heartbleed were in the Linux kernel for like how long? I mean, every, for 10 years, every single, like 75% of the computers connected to the internet had an arbitrary kernel read and nobody knew about it, right? Somebody was probably using that the whole time. So for me, like, you know, this stuff is very new. ECDSA tried and shrew, like, sure, BLS, like, we took some, like, we can do this because we want to aggregate signatures and the trade off was important, but we're not putting ZK in the consensus layer right now for a reason. And this is like, I mean, I sat in a backyard with Vitalik and Dan Benet, and you know, this guy's been doing ZK stuff since the 70s when nobody cared about it, and now we're heading to golden age of cryptography and we're implementing it, and he was like, I wouldn't put it in the consensus layer. So we're taking baby steps in the consensus layer, SSLE so that we can prevent, you know, privacy about who's proposing next, so they can't DDoS, like targeted DDoS, our proposers, and proof of stake. That's like the only place we're taking a tiny little baby step of ZK. I think beyond that, everything else is, there's a reason you have like this, there's no privacy and like ZK scaling in the layer one, and I talked a little bit about contract solvency. I think that, like, my golden future for Ethereum is that all nation states are issuing their CBDCs and they have their privacy, they have their KYC, all these things, and then there's ZK rollup, and then we can all say like, yep, the US government actually has something to back up their reserves, right, which is something that's a benefit on our current system. If we didn't see the M1 and M2 money chart and if we even trust that, we don't actually know how many dollars are out there because nothing's backed by gold anymore. So I think there's always a trade-off, I think anytime you take a bridge, whether it's ZK or it's an optimistic rollup, you end up inheriting the risk of all of the pieces there, whether it's the fraud-proving or anything, and I think that people will do things like, have their large company or their large corporation or their large government having their financial reserves being completely visible on the L1 contract, and then all the fun, scalable, private stuff we can do with ZK we do on top of that, and we take the risk trade-offs the same way that you have a bank account and you have the cash in your wallet. Thank you, David. I think I only have time for one more question. So my last question, and hopefully we can go through this quickly, is what's your favorite security bug? Yeah, I think my favorite security bug is like, I think previously for the ZKash, they have like a trusted setup, and then they put like one extra additional points to there, which like allow people to do like an infinite counterfeit some ZKash tokens on top of that, and then that was like, wasn't fun for like many years until like, I really found out that bug in ZKash, a very epic one. Security bug, in general, or specific to the ABM that you're building? In general. I can tell you the internal one. This is the, no, but it's, I think it's a good example of, this is a bug that we actually found, but this is a good example that it's okay, we found this bug, but you know, we couldn't phone for sure, you know. I tell you, it's like in the sparse miracle tree, there is a condition at some point, there is a condition that you need to check that when you are deleting that, the key, you need to check that the key is the same, that's not the same key, that there is, there is a check that you need to do that. We didn't, well, the first implementation, that check was not there. And when I saw that is, it's so easy to forget that check, it's so easy, that's when you realize how complex this is, this is this. And this was phoned by, well, by the person that was documenting, was documenting this part of the storage. But if it sees this, what else can be in there? And this is the concern and the learnings. I have like a million favorite bugs, so I'll say the ZK specific ones. I think that the lack of auditability because of the privacy that ZK inherits here is just really cool. I mean, you see these L1 contracts get hacked and Twitter's excellent at broadcasting information and this distributed network way where if you follow somebody, you can, InfoSec Twitter, I know about bugs before potentially developers do because it just gets spread so fast. And you cannot see a DeFi protocol get hacked now and not know in 30 minutes if you're keyed into crypto and InfoSec Twitter. I think it's really cool that a hacker could basically steal all the funds, slide out the back door and nobody would know for like years potentially because of the ZK. I think that's just really cool. Cool, thank you everyone. Thanks for taking the time. Thank you. Thank you.