Coinbase Security Series: Base Azul Sepolia Audit Competition - feat. @Immunefi

Heat. [music] Heat.

[music]

Heat. Heat. [music]

[music]

Builders can build on an open platform where they're in control. Creators can bring [music] their creativity on chain and make sure that they're the ones benefiting. [music] Everyone everywhere gets the same access no matter where you're born, [music] no matter where you live. This is the future [music] of the internet. This is onchain.

[music]

[music]

Hey everyone, welcome back to another edition of the Coinbase Security Series. My name is Dan Johnson and I'm on the blockchain security team here at Coinbase. And it's my pleasure to be in the company of this awesome group of analysts today so that we can provide you with the latest and greatest updates that are happening on base. This series is our favorite opportunity to connect with the great builders and researchers within the onchain community so that we can share and discuss various topics of blockchain security and how to build safely in the space. So, as some of you may already know, Bass has officially launched their first independent network upgrade.

base Azul. So, it's now on the base test net. And we wanted to use this episode as an opportunity to provide an introduction to the upgrade and also talk about our current ongoing public audit competition with ImmuneFi. So, as is the case with each of these sessions, please note the disclaimer that's placed at the bottom of the screen. And uh with that, we've got a great session for you today.

So, why don't I introduce everybody that is here on the call. Uh why don't we start with Tim from the Immunifi side.

Uh hey everyone uh my name is Tim. I'm hacker success product lead at Immunifi and I've been helping Coinbase team with the audit competition that is currently running at IMUI. Happy to be here. Um thanks.

Awesome Jack.

Hey everyone. Uh I'm Jack, a software engineer on the base team. Uh I've been on the team for about a year and a half now and uh did a bunch of work on on the new multi-roof system that is uh coming out with bases.

Daniel,

hey, my name's my name is Daniel. I run the base chain core product. So I'm kind of product lead for the basis hard and I've become dangerous with the advent of codeex and claude.

And and thank you all for being here today. um you know and all of the hard work on Basul as well as this uh awesome audit competition that we have going on right now. Uh as it stands right now, we're at our our midway point. We're one week in and uh yeah, so far the participation has been awesome, but I'll uh let Tim talk about that later on in the session. But for right now, why don't we uh start with Daniel and have him share screen and maybe we can learn a little bit more about basis and get that overview.

Okay, cool. That sounds good. Let me let me bring it up now. So, cool. So, what I want to start with is give a quick overview into like what Basul is.

So, we just like level set so we're all on the same page. So, this is our logo and Azul is BAS's first independent network upgrade. Azul itself is a shade of blue. That's kind of be our naming theme going forward. Blue things, things that look cool in blue, shades of blue, all blue, all the blue stuff.

So the important things on this slide for kind of the security perspective is uh independent and like network upgrade. So I'm going to kind of like dive into both of those two things separately and then we'll we'll wrap it up at the end. So uh firstly is independent. Um, for those of you who don't know, bass up until Azul has been an op stack chain. So what that means in practice is we took all of the opt binaries, so like opth, opref, op node, uh, we packaged them up with like the base configuration.

So things like what's the gas limit? Uh, what's our minimum base fee? And we kind of deployed that. And that was the base release was basically just a wrapper around kind of an openstack release. And Azul is the first hard fork where instead of kind of just taking those like vanilla open stack binaries, we're starting to kind of publish our own.

So we're going to have base ref node for the execution layer and base consensus for the consensus layer. Uh we'll talk a bit more about these later, but these are kind of forks of the OP binary variants with like a hand handful of changes made. Um so that's independent. So if you're looking in the context of like the immunifi order, if you're looking at op, you're looking kind of in the wrong place. You want to be focusing on like the base variants of these.

Um so that's the independent. So on to like what is in the network upgrade like kind of where should you look? What should you be thinking about? Um as I like to think about this what are the new features that are coming in the upgrade. So there's kind of three areas.

Um the first is multi-roofs. So Jack's going to talk a lot more about this later, but uh the the TLDDR is up until Azour um we used optimistic proofs, right? Fault proofs onchain. Um with Azul, we're going to a TE and kind of ZK uh proof setup, but I I don't want to kind of steal Jack's thunder. He'll he'll kind of give a lot more info on that later.

But that's probably the biggest change, right? We've completely changed the proof program. Uh the second thing is performance. So historically we would support kind of many different clients like opth, oprath, nethermind. Uh we've taken the most performant of those which is opth and we've started kind of like simplifying it even more to kind of like potentially improve performance there.

And then the third is we're also enabling the Osaka kind of L1 features. So things like the maximum transaction gas cap, a handful of repricings um and so on just to continue for base to have like that L1 EVM equivalent. These are kind of the three areas of change and probably the things to like focus on. Um, we have this website. It's like a shameless plug for my specs website, but if you go to specs.

base.org in the kind of side panel, there's a a zool page which will kind of give you details on every EIP that's kind of changing for Osaka for example. And onto that kind of my my last point here is this is the first of many. So Azour is our first independent network upgrade, but it's not going to be the last. We're aiming to do these every couple of months.

Um, and yeah, that's that's kind of it. Thank you.

All right. And, uh, with that overview of Basul, why don't we, uh, kick things over to Tim with Immunifi so we can learn a bit more about the audit competition and, uh, get an overview from him.

All right. Thank you, Dan. Uh, let me share my screen. Uh, let me know if you can see it. Cool.

Um, so yeah, the biggest difference between a usual bug bounty as most of you know are being hosted on and an audit competition is is the time frame. So for audit competition based Azul, we have a limited time frame of 13 days if I'm not mistaken. Pretty tight timelines for uh quite a huge scope. Um, but that should be more than enough for our security researchers. And on top of that, we have a fixed reward pool as opposed to bug bounties where a certain rewards are being paid out for whatever severity is found, whatever it's high, critical, or medium.

Here we have a 250k reward pool uh which scales uh based on the severities found. So um if if anyone visits this competition page which is at emi.com/ auditcompetition/ uhcombasul you'll find out that um the total reward pool available theoretical one is 250k if at least one critical report is confirmed by base team. If at least one high is found that's half of it 125k. If at least one medium, that's 70K.

If at least one low, it's 30K. And if none of the above conditions apply, then it's going to be only 20K. However, I think uh I can already spoil some details by saying that it's not the least of it. No, it's not it's not the last option. It's not 20K and it's not uh I think it's not even 30K.

Well, I I think I I'll end it here. It's going to be at least 30K. All right, we can we can say it for sure. Um so the competition is going to last for another 6 days at least at the moment of of this recording. Um we have both off-chain and onchain components.

This can be visible within the scope section. So if you go here you'll find out that we have um the offchain components as we call them blockchain DT assets and then smart contracts uh two of them. Uh in order to submit reports, you'll have to sign up uh on emunifi.com as a security researcher. Navigate to the dashboard pass the QC and then you'll be able to um report the bugs on you know whatever severity you you may find in there.

After that base team uh will acknowledge your report um and eventually will either confirm or close it and your reward will depend on the total amount of uh findings found and depending on which what is the highest. So again if a critical is found then the full pool is unlocked. Uh certain rules apply to the reward distributions. The one important one that I will mention is that duplicates are allowed in this competition for all the security researchers that are listening. uh you can find similar bugs and they will be accepted by the base team however at a reduced rate uh very reduced actually I think you'll only get approximately 10 or 15% of what a chief finder would get um but that allows you to you know experiment experiment more search more and don't be afraid to you know submit something that's not in there however um then you can correct me later if I'm wrong uh base team reserves the right to um fix critical findings I'd say high and critical I found during the competition which means that some of them will be pushed live the PR will be will be shared live and for that specific finding the duplicates will be frozen for the rest you know everything is allowed um so yeah um again to reiterate in order to participate you have to be a security research on I mean unifi that's go to imunifi.

com sign up in there uh pass the QIC and you're able to participate bait. Um, that should be it from from Mifi side of things. Dan, back to you.

Cool. Yeah. Uh, awesome stuff to, you know, to see the competition page here. You know, we encourage everyone to, uh, check out that that web page and, uh, read up on the competition details and, you know, really really spend some time with the code. Um, you know, this is a great opportunity to, you know, showcase your abilities as a security researcher.

Um, but also, you know, it's it's great for us to get this feedback from the community while we're, you know, on base test net, uh, as opposed to, uh, having this, you know, program going while, uh, while we're on mainnet. So, um, and with that, the expected, uh, date is, uh, for for mainet release is May 13th. So, stay tuned, uh, for that as well. We're really excited to bring that out to you guys. Um, you know, and I I guess I also want to add that this is a sort of a rare opportunity to have a a public audit competition with both onchain and off-chain components being side by side.

Uh so you get that holistic view of the codebase um and really get to understand and dive into how you know offchain interacts with uh onchain. So um yeah yeah please take a look at that use the resources that are available and also really make sure that you're diving into the uh discord channel. I'll be monitoring that pretty closely throughout the uh remainder days here of the competition. Um, and you know, I would say there's a pretty pretty good shot that you'll be a part of that leaderboard if you spend some time with the code. So, uh, we'll we'll very much appreciate your effort.

All right. And with that, let's, uh, jump over to hear about the, uh, client stack and consensus layer here with, uh, Daniel Prout.

Okay, cool. Thanks, Dan. So, we we kind of left this at the intro with that we were consolidating a bunch of our clients, right, from these kind of like OP variants into base specific variants. So I want to kind of take a few minutes and just show what that means. Uh so we're going to break this into three things.

There's kind of the consolidation like what's mapping to what. There's kind of if I was if I was auditing this like kind of what areas I would be interested in and then I want to give maybe like a a few minute overview of like the repo kind of where all the code is structured how you kind of run it how you can kind of like validate your your changes locally. So starting with like the client consolidation, this is a big diagram, lots of boxes, but the kind of what this shows is on the left hand side you have what we call like the sequencer and the batcher and the proofs. These are the components that kind of are permissioned that we run at base and on the right hand side you have the nodes. So this is this is prizul.

So this is the software that we run kind of prizul um and you can see like on the nodes for example on the right hand side we have uh the execution clients at the top. So we have base node ref as a supported client, opth as a supported client and nethermind and then kind of underneath those we have like consensus clients rights like op node uh kona and with the op stack today you can kind of mix and match those those pairs and on the left hand side it's a lot of similar components so like op node is there base node ref is there but there's also like additional pieces like uh op builder which is what we use to to build flash blocks the conductor which we use for ha and kind of the batcher which we use to uh write kind of your user transactions on the L2 to blobs on the L1. So this is this is kind of prezul. So I'm going to I'm going to kind of go back and forth a little bit just to kind of map these but this is what we had previously and this is kind of what we're going to now. So postul you can kind of see on the starting on the right hand side the nodes there's now only one ELCL pair that's kind of supported.

It's base node ref and base consensus. And then on the sequencer side, uh we've kind of collapsed the uh sequencer and builder into like a single um a single uh server and there's a single e base builder which is kind of paired with base consensus. So if you kind of go back and forth, you can kind of squint and you can see, okay, op node and kona have kind of gone to base consensus and uh base node wrath, op gaps, nethermind have kind of all gone into base node wrath and base builder kind of depending on on which role they're in. Um all of these components in blue are in base and this is what I would kind of focus on for this uh competition. We still run a few kind of vanilla OP stack components.

So like op conductor and op batcher. However, there's there's kind of no changes to those. So uh like Azul doesn't change them at all. So like depending on where you want to spend your time, probably like the the biggest bang for the buck is going to be on the components uh the other components that have changed as well. So that's kind of how the the clients have consolidated.

Um three areas that kind of I would look for for books. Um I'm sure there's lots of others, but firstly is like around the hard fork activation like does it activate correctly? are there kind of any issues? Uh the second is like the new logic that's changing. So like Osaka uh op codes while they're on mainet maybe we've kind of implemented them incorrectly.

Um and then the third is kind of base consensus itself. So if we kind of go back to these slides like base node rest we've been been running somewhat in production for a while. Um base consensus is like truly a new piece of software for us. While it's a fork of Kona, uh we have made a lot of modifications and and and simplifications to it. So that would just be like in general maybe like the CL like the the derivation pipeline, the peer-to-peer network.

Those are probably areas that I would I would look at. Okay. Uh okay, cool. So with that, I want to change uh direction and kind of just show a little bit about the repo and kind of like how to kind of test your your findings and whatnot for the client software. Um, so I'm going to switch to sharing my uh IDE.

So this is the this is the base reaper. On the left you've kind of got the file structure and on kind of the right you've got um like just the file we're looking at right now. It's our readme. So in this kind of terminal if if I was you guys I would come to this project. The first thing I would run is I would run just devet up single.

And what that's going to do is it's going to start you a L1, a fake L1, a fake L2, and kind of every component that we just looked at in that diagram. It will spin one of those up. Takes a few minutes. So I've I've kind of run it in run it in preparation. And then you can come here and you say, "Hey, get me the status, right?"

And you can see, okay, we've got the L1 and has blocks, the L2 builder, which is that base builder piece, the L2 client, um, and so on. You can then just use like your standard cast commands and you can get the latest blocks. You can send transactions and and all of that good stuff. This gives you on 8545 there is a base execution a base node ref kind of uh endpoint listening probably not not super interesting for this but you can kind of go into this kind of docker compose file and you can see what it's running and there's a full consensus client full execution client for both the builder and the um validator. So aside from like switching gears a little bit, that's kind of like how I would run this stuff locally, how you can test your uh checks against it.

The the repo structured in in a couple of ways. So there's the first thing to probably look at is this like bin folder. So the entry point for every binary is in here. So for example, we have um the builder which is base builder. We have consensus which is base consensus.

And we have node which is a base node ref uh sorry base ref node. You can come in here and you can kind of see okay cool this package is is this one. Um a lot of the other components that we were speak on the diagrams like the websocket proxy also follow the same pattern but we've been running those in production for a while. So maybe not the maybe not the best places to look. Um great.

So if we kind of use the consensus for example right you can go to like the main file. they're generally very very sparse. Um the main kind of thing to look at is the CLI RS. This will define in here all of the arguments um for for running the process. And then you'll generally see like a run method um which is just kind of takes those arguments and like wires it up into the into the logic.

These these binary crates are generally very very thin wrappers. Um, and what they wrap is you'll see here we have this like crates directory and the binaries kind of are thin wrappers over like the crates. They'll like take a bunch of crates, compose them together into like the binary. Um, so for example in here you can see like we have the the builder crates. Those are what are mostly used by the uh the builder.

Um, we have consensus. Same deal. They're mostly used by um the consensus. They're also used by the proofs. Um, execution is kind of the same.

It's like these are the consensus crates. These are like the execution crates. And you can just go through each of these. They should be fairly hopefully they're fairly well structured. For example, we have like an EVM crate and you can see kind of what it depends on.

And then you can kind of go into the code and and dig into it for that specific crate. So, at a high level, that's kind of how the repo is organized. Um, these are the main two folders to look at, bin and crates. Um, everything else is mostly like testing or kind of harnesses around that. Um, so yeah, that's that's where I'd focus for for the competition.

All right. And I think that's probably a good point for us to dive into uh the the onchain and proof system now. And thankfully we have Jack Chuma here on the call who can uh give us an overview there.

Thanks, Dan. Uh yeah, let me go ahead and share screen and we can talk about multiproofs. All right. Yeah. So, for multiproofs, as uh you may or may not know, Bass is an optimistic rollup or has been up to this point that rolls up to Ethereum.

Uh and part of what that means is we operate a canonical bridge for moving funds back and forth between Bass and Ethereum. And as Bass grows, so do these bridged funds. So, as of last week when I took this screenshot, uh there was about $2.5 billion of funds sitting in our L1 bridge contract. And as that number goes up, it becomes more and more important that we have secure and you know reliable systems to protect those funds.

And this is where the proof system comes into play. Uh it's essentially in charge of facilitating the withdrawal flow of moving funds off of base and onto Ethereum. And it's done in this multi-step process where uh you know user starts with an initiation of the withdrawal on L2. We operate this proposer component that submits uh checkpoints of L2 state to Ethereum. The user can then prove their withdrawal exists against one of these checkpoints.

Then after about a 7-day delay, the checkpoint becomes trusted and the user gets their money. And up to this point, the 7-day buffer has been to allow for the resolution of a dispute in the event that someone disagrees with the correctness of that route. So we're moving away from this dispute resolution system in place of multi-roofs and uh what that means in set another way is we're moving away from a optimistic proof system where anyone can post any output route to L1 and the security of the system relies on dispute resolution. uh and instead we're moving to a validity proof system where now any proposal submitted to L1 needs to be accompanied by a proof of its correctness and that can be in the form of a TE proof, a ZK proof or both. Why are we doing this?

For starters, it is simpler. Uh this is going to be an oversimplification in terms of an explanation, but when we make changes to the base protocol and the proof system needs to be kept up to date, essentially what we can do is just drop the new base binary into our TE provers as well as our ZK prover ZKVMs and then we register new program hashes uh for both prover types on chain. And that's basically it. It's pretty minimal uh manual effort to keep keep things up to date. Uh number two, it enables faster withdrawals.

So we are introducing two fundamentally different proof types to our system and when both are used and they agree on an output route, our confidence in the correctness of that route is elevated which allows us to uh reduce the time until that route is trusted um all the way down to one day. And then lastly, this is our first step towards stage two decentralization because it introduces provable onchain uh bugs and I'll go into more detail uh on that front in in a couple slides. So again this is going to be an oversimplification because it's a highle slide but just rough mental model for the different proof types. uh TE stands for trusted execution environment and the way you can think about it is it's basically hardware magic that proves that base code ran in the enclave and then for the ZK side this stands for zero knowledge proof I think of this as math magic that proves that the base route is correct without revealing the info that makes it correct so the info that makes it correct would be things like transaction in inputs and uh blob data that's used as inputs to drive base blocks this brings us to a couple of system properties to call out. So the TE proofs are permissioned.

These can only be submitted by us or whoever the registered TE provers are on chain. Uh however, the ZK proof side is permissionless and can be submitted by anyone. And in the event of a disagreement between the two proof types, the ZK proof side will take precedence. And because the permissionless side takes like can override the permissioned side, uh if there's a disagreement, that's what allows the system in its current form to remain stage one compatible, which is which is great. So now uh we have a couple of new off-chain system components to cover uh that are relevant for the audit competition.

We are still operating a proposer as we always have. However, now the proposer needs to source proofs before it can submit the output proposals to L1 to L1. Um, and under normal operations with this first iteration, it'll be sourcing proofs from TE provers. In addition to the proposer, we'll be operating a challenger as well to protect the system against invalid routes finalizing on L1. This could be done in uh a couple of different manners.

The most likely of which would be if there's a bug in the ZK system that allows for an invalid route to be submitted to L1 while still passing ZK verification. Our challenger is in place to detect that and either challenge or or nullify. And I'll go into more details on what nullification means uh in one of the next slides, but it can challenge in the event of the proposer submitting an invalid TE proof. We also will uh be operating a registar component that is in charge of managing the onchain TE prover set. So taking a step back for context here, the TE provers when they are spun up, each new enclave will generate its own private key in memory that is never exported from the TE prover.

Um, and so when things like a redeployment or infra kills and and spins up a new instance of the TE prover, we need something in place to auto uh register and dregister these these signer keys inside of the um enclaves. That's where the register comes into play. So we have this registar component that is watching our uh TE prover autoscaling group in AWS. When it registers new provers, it's in charge of registering them on chain. And when it uh detects that old like currently registered provers on chain no longer exist in the autoscaling group, it is in charge of dregistering them.

And uh the way it is registering on chain is it sources a zk proof from the boundless network to uh ver to it's a zk proof of AWS nitro atestation verification um to prove that the key is coming from inside of an AWS nitro enclave which is the TE prover type that we're using. And then lastly, the the other two components are TE and ZK provers, which are somewhat self-explanatory, and I kind of already went through that, but TE provers are in charge of uh generating and signing base output routes um using the serer key that's generated inside of the enclave, and ZK prover is going to be SP1 provers from succinct that um are proving the correctness of base output roots. Lastly, uh I wanted to go in a little bit more detail on onchain bug detection. This is an illustrated example that uh can describe this. So we have finalized roots on L1 on the left of this image here.

And then on the right we have a handful of submitted output routes that have not yet finalized. A core invariant of the system is both proof paths should only allow one valid output route per base block. And if it doesn't, that is trivial to detect on on L1. and we can um handle things automatically as a result of this. So in this example, let's say there's a bug in the ZK system that allows an invalid route to get submitted to the L1 system that passes CK verification.

As mentioned on the previous slide, we will be operating a challenger that can detect that um an invalid route has been submitted and we can then sub uh generate a valid or we can generate a ZK proof for the correct output proposal. submit that to L1 for the same base block and our L1 system will detect that we have two different routes for the same block and shut down the ZK path altogether automatically and this will be shut down until our security council takes manual intervention to mitigate the issue. Okay, so last thing to call out, uh I don't want to go too in the weeds on different attack vectors to consider. Um but high level, the main thing we need to prevent at all costs is a finalized invalid output route. If this is possible, it is possible to steal all funds from our L1 bridge contract, which obviously is catastrophic.

So this is like the main thing that we must be able to prevent at all costs. um anything else. We we technically have security back stops of um the challenger or the security council that can take manual intervention in the event of uh like you're risking some kind of catastrophic event. Um because of the fact that we have a finality delay even when both proof types are used. Um granted when both proof types are used it's one day.

So, uh, maybe that's like the the biggest risk that if there's somehow a way that both proof types are used and they agree on an invalid route, uh, there's less time to to mitigate that issue. But other than that, that is uh, basically it for multipproofs. Awesome. Yeah. And I I know that you are probably chomping at the bit to uh dive deeper into so much of this because I know that you know the entire base team as well as our uh some members of our protocol security team uh Roger and the rest of the folks there put a lot of effort into you know building this out.

So, um, but you know, fortunately, there'll be probably a lot more information in the pipeline in terms of blogs and, uh, yeah, potentially other episodes that might dive deeper into this. Let's, uh, yeah, I think this is probably a good point to open things up to our Q&A and we can, uh, take a look at some of the questions that both came in from our our studio audience here, as well as uh, yeah, some questions that were coming up in the in the Discord. um and uh other locations as well. So, uh let's see. Oh, this one.

Okay. Um will there be any downtime during the mainet upgrade? Uh I'll I'll let I'll let Daniel uh quickly quickly take that on.

Hopefully not. Um we're hoping this should be a seamless upgrade. No, no downtime at all. Um from a users perspective, they they shouldn't notice like block n will happen and block n plus one should happen two seconds later. Both will will also contain user transactions.

So there shouldn't even be a a two-c blip. It should be completely seamless.

Okay. Awesome. Yeah. And all right. Next one I'm seeing was uh All right.

So what's out of scope for the competition? Um and I will, you know, just say that there's a uh we have a whole segment of that on the competition page. Uh so people will you know see the old uh OP stack components that were not um that will not be in scope but also you know any modifications that we made to those will be in scope. Okay. If you were participating in your first audit contest what advice would you give yourself?

Oh, all right. More general. I like it. Jack or Daniel, you guys want to take that? What what advice would you give yourself if you were participating?

Go for it, Jack. You can handle that one.

Nice.

Um, well, I've never participated in a audit contest, so I don't know if I'm the right one to be giving advice here. Uh, but I guess I would say don't assume that everything works as intended. Um, there could be issues anywhere and overlooking the areas where it seems like things are obvious and should be working. Maybe that's where where the the next crit lies.

100%. Yeah, you need to just just poke around and poke around, find out. You will you will discover uh yeah, that there's a lot of things that you know fall through the cracks. Um and you know worst case scenario is that you got to have a better understanding of how a system works. Um even if they're you know you find that it is functioning as intended.

Um and that that type of understanding might lead you to be able to ask a different question about the system that ultimately leads to you know identifying a vulnerability or a bug. So, um, yeah, I think that's a great point. And, uh, all right, let's see. Next, Den, if I may add one more point to the to the first question. Um, I think the the most important important mistake that all the rookies make when they uh start hunting on audio contest is relying too much on AI.

And I want want to warn uh most of them that claude chat GPT or any model that you're using won't uncover a critical for you within the first prompt. It won't even uncover uncover it on the second one. So if you're approaching a contest especially a difficult one such as base contracts and believe me they are quite difficult you have to bear some knowledge uh behind your shoulders understanding how contracts work and you know how the the overall functionality works so don't rush it um don't try to you know find something that's seems to be uh very easy to find with with an AI think twice test your assumptions and that will be your you your next hyio crit is is definitely there. Yeah, could not agree more. Um, yeah, there's a lot of like hallucinations and, you know, false positives and things that will that AI will yield that uh, you know, can just lead you down the wrong path and end up taking up more time.

However, you know, there are a lot of I would still definitely encourage folks to lean into tools that are available um you know that are catered to blockchain security. Um yeah, so the I'm sure there's a lot of uh tips and tricks there on the uh on the Amunifi website as well and other public resources that are available. Um okay, about the back to ZK proofs. Uh yeah, can can anyone submit a ZK proof? We'll have Jack take that one.

Yep. So, as mentioned uh before in the overview of multipproofs, the ZK side is completely permissionless. Uh which means anyone anyone can submit and or generate and submit a ZK proof. Um and if you have a ZK proof that disagrees with a TE proof that our proposer submits, um your ZK proof will override the TE proof.

Yep. And you know, for anyone else that has uh questions there, want wants a little bit more information, do reference the uh the specs uh link that that Daniel shared on screen as well. Um because that will provide some additional information that's really helpful. [sighs] Um okay, cool. Uh Tim, did you want to did you have questions for us that you wanted to to throw in there?

Yeah, I don't think I have anything in particular. I I I'm just going to echo Dan's words here saying that we have discord channel where bass devs are actually sitting and reading. Dan is also there. Uh you can go to discord u bases competition channel leave your questions there. They're going to be responded and also our community themselves are going to help you because many of those guys actually uh learn quite fast.

They craft their own schematics, their own pictures and images of the architecture. So, they're going to help you out and good luck.

Absolutely. Yeah. Yeah. Very well said. And, you know, thank you very much to Daniel and Jack for taking the time to uh to share their advice and uh the overviews of the system as well.

Um, you know, I I wish you all the best of luck. Grab a cup of coffee or your caffeinated beverage of choice and uh really please please dive in. We'll greatly appreciate your feedback. And uh we'll see you next time on the Coinbase Security Series, everybody. Take care.