Sequencer-Level Security (SLS) in Zircuit | Martin Derka - Zircuit
Ethereum Denver·Wed, Oct 9, 2024, 12:00 AM
Blockchain nodes and validators secure blockchains’ consensus. However, they provide no security guarantees to smart contracts operating on the blockchain. This is probably necessary on L1s, however, the architecture of rollups allows for doing more at the sequencer level. In this talk, we present our solution to the architectural and cryptographic challenge—a zero-knowledge rollup protocol implemented on top of the OP stack that brings security to the sequencer level. APPLICATIONS FOR ETHDenver 2024: #YearOfTheSpork ARE OPEN APPLY NOW https://ethdenver.com/apply
Transcript
derker from zerit who is going to be discussing sequencer level security awesome uh thank you very much so welcome everybody as said my name is Martin I am the technical lead and co-founder uh at circuit and I will be talking about how we treat security at zerit and its sequencing protocol so when you now look at blockchains what is the state of art for security that they offer to end users when you take a transaction you broadcast to the blockchain to your favorite node right and then the node does a whole bunch of stuff it checks that that payload it received is well formed that it actually is a transaction it will check that the transaction is properly signed and it will also check that the transaction is valid for Block inclusion right so it will check that we have the proper NOS that is expected for the account that is trying to transact that it has the proper chain ID so you know the transaction was actually meant to be transacted on this particular blockchain and then it ALS also check some other stuff that is you know introduced by various Fork rules and and similar things so the bottom line is that the nodes they actually actually secure everything that is important from the chain right they follow the block formation rules and they secure the Chain by forming the consensus on the content what they do not do at all is security for the users they do not care what is contained in the transaction and what the transaction will actually result in right so what is this talk about this talk is about zerit and its sequencing protocol because it works a little bit differently it brings security to the level of sequencer and this talk specifically is about how we do this with very minimal impact on principles such as sensorship resistance or data data permanence and ration of the chain okay so before I go deeper let's take a look H how transactions normally flow through a rollup okay so you are the user you have a transaction this is what I'm depicting by this you know little note right so you take this transaction and the transaction goes to some blockchain node then in the context of rollups we actually have one system component one service that is called the sequencer and the sequencer is responsible for collecting transactions and whenever it has enough of them it poops up a block and it pens this block into the blockchain okay so this is my L2 and this keeps happening for a little bit longer I also have my L1 and at some point when we have collected enough blocks on the L2 we take the state rout that represents the current state current tip of my L2 blockchain and roll it up into some smart contract on an L1 so this is the process how it normally works here I'm going to make a pause because in circuit we clearly do this slightly differently so this is the high level concept of what I'm going after and then in the rest of the talk I'll be explaining the details how it actually works in the nitty-gritty okay so on circuit the beginning is exactly the same you have a transaction and you broadcast it to the blockchain somehow this transaction makes it through the peer-to-peer mechanism to the sequencer but before the sequencer includes it into the next block it is actually going going to scrutinize it it is going to ask some kind of an oracle whether this transaction is safe for Block inclusion with respect to the user so is this transaction here to hack something or is this transaction here to not hack something and if the answer is that the transaction is safe then everything happens the same way how it would happen normally so the transaction will be included in the first available block and everything is fine if the Oracle responds no know this transaction is here to cause some damage to the users it is here to hack your favorite protocol or do something that you know we do not really consider cool as users then the sequencer is going to handle it differently and we want for the sequencer to put it into the quarantine for some time I'm going to elaborate on what exactly this means in a few seconds okay so the malicious transactions go into the quarantine the honest ones and benign ones go directly into the blockchain and exact and the rest of the process is exactly the same we will be waiting for you know sufficient number of blocks to be formed and then eventually take the tip of the chain and the form of the state rout we are going to roll it up so now if you're a developer or somehow technical you must have a whole bunch of questions how exactly are we doing that right so what exactly does it mean that we place a transaction into the quarantine what happens with that transaction once it has been placed into the quarantine quane uh how do we actually tell if this transaction is malicious and it should be placed in the quarantine and then we also have some specific or special types of transactions I'm going to call them here deposit transactions from L1 that you know if you know something about rollups also require some kind of a special handling so I'm going to address these topics in the rest of the call so the first question what the hell is the quarantine in the first place right so now I'm going to sort of switch from the generosity into the specific imp implementation that we are following in circuit so circuit is actually implemented based on gu now when G handles transactions it follows uh this simplified life cycle it maintains two pools one is called q and the other one is creatively called pending Q so you know we have a little bit of term overloading in here but the bottom botom line is I have a transaction and it goes into what I call Q all the transactions that are valid transaction proper payload that belong to the proper chain will be placed in this queue but the fact that I have received transaction it doesn't mean that this transaction is ready for Block inclusion just yet for example uh the transactions from Individual accounts they have to be included in blockchain in the right sequence following the nonsequence without any gaps right so if the transaction has a nons that is way way way in the future G will keep this transaction inside of the queue up until it receives the transaction to fill up the Gap and then eventually it is going to be ready for inclusion in the block so there is this validation happening and the transactions that are validated and marked as ready to be included in the next block then make it into the other pool which we call dep pending queue okay and then from the pending que gu just selects you know the best transactions and forms the next block so this is what happens in gu so when we ask what is the quarantine we need to understand how we or when we actually quate the Oracle and where the quarantine sits in the system and it's between the queue and the pending queue so on top of the regular validations whether this transaction is ready for inclusion in the block our system also asks at this point to Oracle hey is this transaction okay on top of being ready to be included in the block and if the answer is no it's not okay then it's going to place some flag somewhere in the data structures that g maintains which means Hey whenever you're are considering moving transactions from Q into the pending queue skip this one don't move it into the pool that is ready for immediate block inclusion so that is what it means to place the transaction into quarantine we set some kind of a flag that says hey skip this this don't include it and don't move it into the pending queue so what happens with those transactions when they are placed in the quarantine right uh if I left the transactions in the quarantine forever that would be some kind of censorship right and we don't want that so we Define whole bunch of criteria that allow for transactions to exit the quarantine some criteria are you know fairly straightforward so we said hey no transaction should be in the quarantine forever we you know generally don't need that right even when there is a hack transaction that somehow showed up in the me pool it is enough that the transaction doesn't get included in the blockchain for long enough time so that everybody else can exit the given protocol that is about to be hacked in 24 hours right it is enough that the users and general Community are able to query the node for transactions that are currently in the quarantine and that the word can be spread around that there will be an incident and that there is some kind of vulnerability that exists in the given protocol right so once we have left the transactions in the quarantine for long enough 24 hours 48 hours configuration dependent constant parameter those transactions can exit the quarantine and if they still can be included in blockchain meaning they didn't start yet violating some other inclusion rules they will be included if they started valuating some inclusion rules then G has default behavior of just purging this transaction and dropping it from its memory so that it doesn't get clogged right so that's the timing time Criterion now you as the user might not be comfortable waiting for the quarantine to sort of elapse say that you know you changed your mind and you do not want to wait you don't want to hack that protocol anymore you just want to use your wallet again and start transacting right so you yourself can choose to actively replace the transaction because this is how we cancel transactions from mining from blockchains and this is what we call the replacement Criterion so if there was a transaction already included in the chain which with exactly the same nons from exactly the same uh Center this meets the replacement Criterion tra transaction makes it out of quarantine and uh it will be dropped by gu then we have failure Criterion so imagine that a transaction is about to hack a protocol but the protocol gets paused the transaction will revert right that's the principle of uh pausing so whenever our system detects that we have a transaction in a quarantine and the transaction is simulated and starts failing that's fine we will include it in the next block it's going to fail and it cannot hurt anybody so those are the trivial criteria that are sort of you know not very interesting the Criterion that I really really like uh is economic Criterion so say that you are an honest actor you are performing some sort of Arbitrage on chain right so you are F pursuing some Arbitrage opportunity and we unfortunately falsely accuse your transaction from being malicious well in such a case you are 100% confident that your transaction is not malicious right you are not here to hack your favorite lending protocol well in that case you should have the option of telling us hey zerit I think that you are wrong so what do we actually do our oracles are a little bit smarter they do not just say your transaction is good or bad if the transaction is bad they also tell us how bad the transaction it is so you know this is going to cost $50,000 in Damages but if I know that the transaction is suspected to cost $50,000 in Damages then it's absolutely fine for me to give you the opportunity to give me a temporary stake $50,000 then I will include a transaction in the the block right away right because I mean if it does cause some damage I have your $50,000 and I can reimburse everybody who got damaged by this action and there will be no discussion we will see the effect of this transaction on chain if the transaction was honest your state comes back immediately in the next block our block time is 2 seconds so you know this is really not some kind of long-term block up or anything like that so this is our economic Criterion and really you can imagine whole bunch of other criteria we have security companies we have communities we have researchers right so you can also think of some form of an administrative Criterion where we just give somebody the privilege to say uh you can release transactions from quarantine by just you know signing something right so that's the release criteria now what exactly does it mean to release transaction from quarantine going back to the implmentation of the quarantine itself we just remove that flag and transaction can be moved from que to the pending queue from which it can be included in the block so this is exiting the quarantine right cool so how do we actually know that transactions are malicious right that's a very good question so I will say this I don't we are a blockchain we are a platform so we are here to provide a blockchain but there are many many companies in the space that provide active monitoring Solutions and similar Technologies right so all of these Technologies can be turned into oracles and we are doing that so if you don't know how an oracle could work imagine this most of them is currently based on some simulation of transaction and then predictive modeling machine learning on something like that so I will take my transaction I uh obtain a trace for it we will see how many contracts it has hit you know whether it performs the same thing over over and over and over and over which is actually a pattern that very frequently occurs in various hacks and so we feed that into some kind of a machine learning model and it will tell us yes this is malicious or no this is absolutely fine right so that's kind of zuit basic now I have circuit advance so I said machine learning artificial intelligence in generally can hallucinate right and we do not like hallucinations in our case that could result in somebody being falsely accused from executing a hack so we want to step up the game the game and what zeret is going to do we are going to provide some declarative language where you as the developer and the deployer of a smart contract can identify for us the intentions that you had for the smart contract and the invariance that should never ever ever be violated in the execution of any kind of transaction so here we we are actually doing something very interesting because we are opening a very new way of doing clever things with smart contracts so if you have ever developed a smart contract you might have used something that is called only owner modifier you can make your smart contracts ownable right there is a library for that in open Zeppelin many people do it so what only owner does is that whenever a particular method gets invoked it checks whether the message sender which is a context variable environment variable that we have access to in solidity matches the address stored in some slot but when this happens there is some bite code executed right so uh users have to pay gas for it and you actually have to code the logic into the smart contract which depending on what exact logic you are coding in it can actually be a lot of code and so on so on what we are doing here in this uh declarative language and in variance we are essentially giving the developers the opportunity to take this thing away from Smart contracts because in this new setting we would allow you through this language to say hey the my invariant is that this particular method can only be called if message sender equals this and you will make that known to the sequencer without the necessary to have that bite code present in your smart contract itself and then the sequencer will simulate every single transaction if it notices that it actually violates the invariant you have the certainty that it will not ever be included in the block which can leads to simplification of many projects right so it essentially opens whole new paradigm and the bottom line here is that you know as a circuit we don't have to have a single Oracle we can work with multiple oracles right and one thing that you can be certain about is that we will have a very good data set we will have the entire history of our blockchain we will have the entire history of our other blockchains where hacks hacks were executed in the past so we can take this data we can somehow publish it to all the security researchers be it Independents academics industry partners and we can say hey do you have an oracle do you think that this is actually better than whatever we have well let's see back test it right we don't have a problem of including more so that's a way how we are going to engage the entire Community final topic for me L1 deposit transactions so if you know anything for example about uh optimism Bedrock or in general about any kind of rollups you might know that the transactions that uh operate with the canonical Bridge so they bring ether from L1 onto L2 they have some kind of a special handling right so those transactions they're actually submitted to L1 and so that we are certain that that ethal ether will be bridged over very often the sequencing protocols they actually contain some kind of a mandate date that these transactions have to be included at the beginning of very first block when you know they were detected and so and so on so why is this important if you come back you know in the future 5 years down the road right what you as an independent actor in the system should be able to do you should be able to read data availability layer read all the transaction and completely deterministically deterministically rederive the state of the chain and that's cool if you don't have any Oracle that could potentially say no this transaction should not be included right because if that Oracle has disappeared you cannot ask it and you also sort of kind of do not have the guarantee that the Oracle would always respond exactly in the same way so what I am say saying here is L1 deposit transactions are a little bit of a problem but not not really they can be handled it is just important that uh we check them as well because they can trigger hacks and that we record somewhere on blockchain somewhere on the data availability layer the decisions of the Oracle which then needs to impact that decision whether this transaction will on go onto blockchain or not and I have 50 seconds left this is the end of my talk so with this I would like to thank you for your attention my name is Martin uh you have my email right there you have my telegram right there uh we have Twitter account or X accounts the official account for the network is zirc L2 me and some other Engineers occasionally tweet from uh account Dr circuit we have pretty active community on Discord so feel free to join there is roughly 100,000 people who can be your friends and last week we also launched a liquid reaking program which as I checked right before this talk has something like $350 million in loged ether value you so if you would like to stake maybe get some points uh here is the link for you with that if you have any questions
Automatic transcript — names and jargon may be misspelled.