Jan Gorzny - Sequencer-Level Security in Zircuit

Transcript

thank you so hi uh my name is Yan I'm co-founder at Zer and Technical lead so um I'll tell you a little bit about uh myself I've been in the space for a while I did a PhD a while ago got some grants from the ethereum foundation started working on rollup related top topics and then decided you know what you know let's just try to build one so we can explore our own ideas and one of the ideas that myself and my co-founders are really excited about were was this concept of sequencer level security which I'm going to talk to you a little bit about uh right now so um you you know you're here you probably know some things about blockchains but I got to get you all on the same page to motivate why we're looking at the specific topic the specific feature of a

rollup um and so let's take a step back for just a second and say what does a what does a blockchain actually sort of do to to guarantee Security on it right um the node does a bunch of things right it'll check that transactions are well formed that things have S uh signatures and that things should be included in blocks right so if you saw Arthur's talk earlier you know censorships are sort of an issue and actually talk on On a related topic um but essentially it does all of these things to make sure that uh the chain advances in the nice way so the chain is doing something correctly always predictably correct According to some rules and this is very very important obviously so that you have a chain that you can trust and rely on to do a whole bunch of really cool things

but what it doesn't do is actually secure your funds so if the chain includes a transaction that might negatively affect your balance because you deposited in some untrustworthy the def5 protocol or something else uh where your your funds are are lost or hacked um this is not ideal right and you actually can't fault the chain for doing this if you believe code is law you certainly think that this should be the expected outcome but probably you know you're a little bit more uh attached to your funds than just saying code is Law and sort of washing your hands with the funds you lost and you want to do better so uh we were looking at this and thought you know can we add some Val in some some area of this ecosystem and

getting ethereum do this is not desirable we don't want to do that um but it doesn't mean that other things other people can't do something about this namely layer twos if you have a particular concern about this you can deal with it and and in particular we're going to do this on circuit which is a new Zer knowledge rollup that we're building uh that's going to put some level of security that can guard against not just that sort of sequencer level traditional protocol implementation concerns that you would normally have so are things signed properly and do transactions execute all of that but also are your funds going to get hacked or lost obviously only on the L2 we can't do anything about the L1 uh but what this means is you can actually design some stuff to guard your funds even when sort of things are going right

and this won't be for everyone this is going to be sort of a hard pill to swallow for some people because we're going to have our hands in the men poool we're going to start looking at things and say oh that should be or shouldn't be and what that means is interesting challenging research questions and research Direction but there is almost certainly value in doing this right if you can guard your funds uh and you're honest actors and you can discourage dishonest actors this is something you might want to do so before we talk about how this works um or what we're doing on zerit uh how to transactions flow in a rollup is important because we're going to be changing that flow so let me go through this very quickly so what happens in a rollup you have some layer one blocks these are the orange ones at the bottom

and you have a mempo which is the sort of text document on the screen and there's a sequencer sequencer is essentially just a centralized privilege node not always centralized in the future everything probably be decentralized uh but generally right now everything is centralized and it it takes some things out of the L2 M Pool constructs you know an L2 block U which is actually post first to the L1 as a batch to sort of get a soft commitment and then from the L1 commitments you actually rederive the L2 state so the sequencer can do this optimistically and it has a good vision of what's going on in the L2 State all the time but you know you probably don't trust it until uh things are hit on the L1 and then there's some notion of finality there's

you know either an optimistic rollup where you're waiting seven days to make sure that no one has proven that the sequencer didn't do anything wrong um or a zero knowledge roll up which is the case for circuit where there is eventually a proof that hits the chain that says actually my state transition followed some rules and we're all good so that is generally what a sequencer does it constructs L2 block by posting data on L1 Zer is going to do a little bit more than that what we're going to do is add this level of sequence or level security where we're going to go into the L2 M Pool and change how L2 blocks are constructed in order to safeguard users and so what's going to happen is we're going to add this security Oracle so we're using Oracle in the computer science sense not in the price Oracle

sense that you're probably familiar with in web 3 um that asks for every transaction is this a safe transaction is this a good transaction and I'm not going to Define for you what a good transaction is right now because that's challenging uh but you can Envision it as you know is there a Flash loan that's wiping out a D5 protocol and you know you can you can Define what this looks like at least at some level for for your needs and we'll talk about how we're going to do it but essentially you know there's some notion of good and bad which we're going to have and we'll have an oracle that will determine for a given transaction on the current tip of the train is this good or bad and if the answer is yes we're going to put that into the batch we're going to process

the transaction just like it normally would be perfectly you know in sync with standard Notions of an L2 if it's bad though we're going to kick it into quarantine or if we think it's bad we're going to kick it into quarantine and what this means I'll talk about in a minute um but essentially it will be ignored at least temporarily and so what you end up having is an L2 chain where everything in that L2 chain actually went well according to some definition of well obviously that is still something we have to talk about and exactly how does this happen well first how does it do it um so what does it mean to put something in transaction can it ever get out is there you know what are the technical details um what happens in it can something leave it um then the hard questions of how do you

tell if a transaction should be quarantined that's going to be probably the most controversial the most challenging thing um and and then there's some technical Corner cases you have to also deal with some transactions originate on L1 for example these are called deposit transactions and then how do you make sure that other people who are running L2 nodes to replicate the node if not acting in this privileged uh sequencer position can also come to the same conclusion of what the L2 State should be so let's start with by talking about what is the quarantine so the quarantine is you know going to be this place where we put things to determine if they're good or bad um in particular if we think they're bad we'll put them in there until we can validate them or for some other criteria that we'll talk about but essentially what happens

inside of a sequencer especially one that's based on on gu like most of them are including circuits um you've got two cues there you got a me pool and you have a Q and the is for sort of things that could be right it could be transactions that have um nons that are too far in advance or the good ones that are ready to process right away and if they're right away uh if like if the kns is sort of the one you'd expect for a user the gas is all appropriate all of that you can put them into the pending queue and from the pending queue you essentially build L2 blocks right away that's nice um and it's exactly that flow where we're going to interrupt and put this Oracle so what we do is we say well before we you know process it into

a block is it good or is it bad and that's that's a simple question um and so it it naturally flows right in there and and that means quarantine essentially just says take it out of the ability to go into um that that pending Q so we're just going to put it somewhere else uh we could call it a different que quarantine queue if you wish uh but essentially it's not going to that pending q and then the rest of the transactions go on okay so let's talk about what happens when we actually to put transactions into the quarantine uh they could stay there forever if they're a bad thing that everyone agrees is objectively bad they lock a lot of fund somewhere it could stay there forever uh and we'll talk about exactly how that will work uh or they could

leave for some other reason right they could leave because there's been a time delay right maybe there is you know a nice rule on the chain that says you can actually leave the queue a little bit later uh or the user could cancel them right you can change you can replay transactions with uh the same nons with a different gas price and a different content of the transaction to actually have your transaction sort of be kicked out of the queue because you'll put a transaction that isn't bad onto the L2 uh and then rendering the any transactions with the same nons invalid namely the ones in the queue so you can actually have users cancel them which is kind of cool uh this is helpful if someone thinks they doing something good but actually they're doing something bad accidentally uh they can cancel that

transaction uh or if it starts to fail we can then sort of not care about it anymore if we can sort of prove that at a given time we playing it out of this quarantine Q would cause it to revert well then no harm D no harm done there except I guess to the person who submitted the transaction will take their gas fees uh or there could be other really cool things you can do right you can release it subject to economic considerations so you could do is say I don't know what good or bad really is uh and you're telling me it's uh a good transaction but I don't believe you I think it's going to do X you know dollars worth of damage so you could have them stake x amount of dollars and say look I'm going to play

your transaction but if something goes wrong I'm going to slash your stake and I'm going to use it somewhere else so there's a bunch of things you can do once you start looking in this design space but the most simple one is also just the administrative concern so if you think something is bad you put in the queue until someone actually sort of traces through the transaction figures out and says hey this doesn't look that bad maybe we can let this go it's probably the one we'll start with but there's a whole lot of areas you can do with this design space once you start doing this and what what you notice is actually this things can do actually a little bit more than that we'll talk about that next but essentially if you have decided something comes back out of the queue for example because it was a

false positive in terms of of Badness it was actually something that was good but just complicated uh you can put it back into that pending Q from two slides ago and everything works as before so the next question is how do we know something is bad and we're going to leave this largely up to the uh Oracle but the Oracle has a lot of information at this point in the game uh because you're not doing something very sort of academic in the sense of like trying to prove that all transactions can go wrong like when you're auditing code you're not saying that there's you know something could go wrong with a smart contract you're saying this transaction will do something bad you can simulate it you can actually play it play with it uh you can play it off train you can simulate it you can use things like air

models to detect patterns in previous hacks and see if this corresponds it and you can do a whole bunch of really cool stuff because you have the information you're not dealing with hypothetical attack vectors you're given a transaction that you want to determine an outcome for good or bad and so this is in fact in fact what we're going to do down the line it might be even nicer to do something better uh or maybe not better per se but different which is to say Define custom invariance you could tell me what is good or bad you have a Dap you're concerned about it's losing its value that's good important to you but the next app doesn't care about that property so you each define specific and varant and the sequencer enforces those in different ways for different apps and you can do this to actually change the

semantics in of the blockchain which is also really really cool um for example you could have invariance that aren't sort of goodness or Badness but actually just enforce things more efficiently for you from a gas point of view you could say that any transaction hitting uh a specific function on one of your uh contracts is bad unless it came from your address right that would that's effectively implementing the only owner modifier that people write in smart smart contracts which say you know you can only upgrade it if you're the owner but now you can take that modifier out of your smart contract code and put into the sequencer and you now saved yourself a little bit of gas when you run that function call that's probably a pretty

contrived example you're probably not doing that very often to have that warrant the extra engineering effort but you could Envision taking these other things in smart contracts and putting them into smart into in that are enforced by a sequencer which we think are really cool for now um what we're going to do is research this idea quite a bit we've got some uh some Partners both in Academia and Industry where we're going to figure out how to look at these models how to test them how to simulate them and how to use back testing of previous hacks so we know what things have gone wrong in the past L chains obviously everyone probably remembers with the Dow hack and all of that there was a whole bunch right there was $2 billion lost in bridges over the last couple of years there were you know tens

of hacks over the you know each of the last months uh we can play around with those we can figure out what looks bad and start to tailor the system to start at least um to counter transactions that look exactly like those or similar to those right so that we can prevent at least those disastrous outcomes because none of those seem to be you know upsetting to the people who uh who pulled off the attack right they all knew that they were pulling off attacks okay so we just have a couple more minutes and there's actually some small technical considerations that I'm going to dive into just for a bit in case you're wondering about some of the more detailed stuff or just to avoid questions about it later sorry uh L1 deposit transactions are a bit unique uh so L1 deposit transactions are generally

the transactions say put my eth off of ether or offer off of ethereum and onto a rollup say circuit um the terms actually been conflated to say any transaction that affects L2 state that starts on on L1 um but essentially this is is a little bit of a technical issue because uh the sequencer has less control over these transactions right the protocol for most sequencers says look at the L1 inbox or you know the bridge and if there's a transaction there that puts something on L2 I sort of just have to deal with it so I can't kick it out of my M poool because everyone looking at the L1 State and trying to rederive the L2 state from it will look at that deposit transaction and actually realize oh that's should be in there all the time so what you

actually need to do is you need to have a different way to check and quarantine them sorry I thought that was a slide um and you can do this but what you have to do is you have to go back to the L1 chain and write to the L1 chain saying this deposit transaction is going to be ignored put in quarantine essentially uh because of some reason you know you can say the reason or you can just mark it as ignor it and what this also means is uh to rederive the state you know you have other nodes watching the L1 and it's got to have this sort of special functionality so um I think that is actually the end of my talk which means I'm a little 5 minutes early uh but if you have any questions please find me I'll be around here um outside or

sitting or at chain science I think I'm also on a panel on Sunday uh and I have a talk on at chain science tomorrow uh but you know come check us out Zer get a new ZK roll up the staking thing is actually over a billion now so uh it's grown quite a bit since these slides were made but check us out ask me questions and thanks we actually have uh time for one or two questions are there any questions in the audience so do you imagine Oracle to be deterministic or can be randomized I mean I I mean you're going to be I I don't have a good answer for that I mean I think you'd want it to be deterministic so that you could show to someone that like hey this transaction

didn't go into the chain because of this reason uh if there was a compelling reason to to introduce randomization there I'm not sort of opposed what we envision long term uh is to have have the ability to sort of have multiple of these oracles so you could also Envision like a two of three majority where you know your Oracle might be randomized and might say this is not good and someone else's Oracle is a little bit more deterministic and gives a different answer and you take the majority of them um I don't really know uh would you consider llms or like AI based things randomized probably also not but um you know they're probably not necessarily deterministic depending on how you train the models I mean if Oracle is deterministic malicious attacker can

also check in advance and design transaction so that it passes yeah yeah I mean it's it's the hackers I think probably always have a little bit of a leg up here because they're trying to skirt this uh I don't know how how much we're going to be able to counter that right and the best answer there is probably that custom invariance if you tell me at as as AAP developer what shouldn't go wrong and you do that in a way that's careful then the attacker should never be able to break break that in variant if I can simulate it and if we do that then you know there's sort of no Advantage I think to the the attacker above hand until we get to that point I think yeah people can come up with new

attacks in the same way that if you're a smart contract auditor you've probably been looking for a re-entrancy all of your life but now there's a whole bunch of new classes of attacks that you also need to look at because you didn't think of them as concerns before but now you do right in particular things like read only reeny so ideally we catch all of those as well but you know if the invariants are defined it's a long waed answer if the invariants are are defined well enough even new attacks can be cancelled right so if you just say don't wipe this protocol it doesn't matter how the attack R do that if it if it wipes the balance of protocol is going to be it any other questions one last question maybe

anyone r so for now it's us for now it's going to be an AI based model using the previous um hacks that I've G gone on ideally we would love that that you were the daps to say this is what I care about in addition to the AI because you know you might have gotten it wrong or the might have gotten it wrong but together we can do it better well yeah every rollup is sort of a middleware so yeah this is I yeah I mean we haven't open sourced the ideas just yet or the tech um we will probably at least the infra for the for the rollup I'm not sure the LM will will go or the i stuff will go public um but the idea you know you can definitely

take and Implement thank you so much uh Yan uh was a really interesting presentation