Rollups Unfiltered: What We Wish We Knew While Building Zircuit | Martin Derka - Zircuit

[Music] that was a great talk I am a big fan of bringing back access for everyone for investment deals uh next up we have Martin derka from zerit and he's going to be talking about Roll-Ups unfiltered what we wish we knew while building zerit Hello everybody welcome my name is Martin I'm from zerit I'm the technical lead and co-founder and when I was submitting the talk to eth Denver I sort of wanted to do a little class that would convey all the things that I wish somebody told me roughly two years ago when we were starting Z zerit and while we were building zerit so that I didn't have to go through my own journey of learning this in practice so this talk is about insights it's inspired by our experience it's inspired by all the mistakes that we have made while uh innovating and it's inspired by all the good practices and best practices that we have ourselves developed for our procedures uh while making circuit so the first topic that I want to talk about are ethereum upgrades we are building rollups many rollups as well as our rollup uh on uh stack that is called the op stack it's an open source software it's an open source framework that allows everybody to spin up their own rup so let me go through small walkthrough of the design of op stack so what does happen when you know you are transacting on a rup on a rup you have essentially two sets of services or one set of services this is this green stuff that's everything that your rollup consists of so when somebody transacts they send a transaction which enters the menol of the execution client in the op stag this is some version of gu so this is right here what happens with the transaction afterwards is that this execution Cent is going to pass it to a service called Bater and the purpose of the Batcher is to take the transaction and record it on the data availability layer for rollups the data availability layer is L1 so in our case this is ethereum and blobs right here and so the op stack has a service called the L1 client which essentially creates the transactions and sends them to ethereum into blobs so that's when we are here now what else WR s need to do they have to guarantee that there is absolute Integrity between the content of the da on the L1 and what is the state of the execution client so here on the left side we actually have the opposite direction we have some service called the op node which reads the L1 and content of the blobs through the L1 client again and if it notices that the state on the execution client doesn't match whatever is recorded on the L1 it forces a reorg on the L2 down here so once we achieve state that is stable consistent and can be considered final with some definition of finality the prover that this is our case because we are a zero knowledge Dr reads that state and generates a proof so that the state can be rolled up onto L1 once we have that proof the state route together with the proof is given to another service called the proposer which again uses L1 CL Cent and the underlying gu dependencies to create transaction and submit it onto L1 well here is one thing the op stack and gu itself are developed in go Ling and gu is used as a dependency in this code base well goang has this one rule and it is called single version dependency that means that you can import every dependency exactly once and that dependency has to have a Frozen version so what you end up with is this weird situation where your execution client and the L1 client are tightly coupled because they share the dependencies and this is a little bit of a problem because here on the state of L1 we actually have to adhere to the rules of ethereum right because we are talking to ethereum however here on the execution client this is the behavior of the rollup that we are building and rollups are here to in inovate to bring new functionality so these two things have to divert in their own logic but they sort of cannot or it's actually really difficult so what it means in in practice is that and this might be fact that the community might not be so well aware of the rollups and l2s that you see today if the entire world stopped developing and was never doing any extra work and at some point ethereum upgraded itself they will stop running because they will not be able to talk to it through the L1 client that L1 client always needs to be adjusted to the you know blog header format that uh the ethereum is using otherwise distalization and serialization of transaction will start failing the other thing that it means is that if you are actually organizing your code as a monor repository which is how op stack is organized and which is very beneficial for testing you will run into troubles as soon as that logic between L1 and N2 starts differing and as I said it will differ because you will have upgrades and you do not necessarily want to respect all the eips that are implemented on ethereum one example for all on ethereum we now have pectra upgrade that is coming up inside of pectra upgrade there is a repricing of submitting call data in transactions makes them more expensive for the people transacting on ethereum this is the particular EIP de makes zero sense to adopt on rollups Roll-Ups are supposed to be cheap and fast there is no point in making transactions more expensive for the people so that's when you will at some point start diverting so that was topic number one topic number two EIP 1559 so we are teleporting a little bit back uh into 2021 uh this is when EIP 1559 arrived together uh with the London Fork of a eum and what it did was that it essentially broke the cost of transactions into two components when pricing it transaction in ether what happens is that we always execute the transactions see what op codes were executed during it and we see how many gas units this should correspond to and before EIP 1559 that was multiplied by one number that was the gas price that the uh submitter of the transaction was willing to pay after Fork we are multiplying this by the sum of two coefficients one is called the base fee which is mandatory it cannot be zero this is what you have to pay and the other one is called the priority fee and it has the purpose of a tip which is supposed to convince the block Builder that your transaction is the most convenient and profitable one to include into a block so this is how it works now so base fee is mandatory tips are optional so if you really want to see how much you you are going to generate in onchain profits you actually want to focus on what kind of a base fee the transacting users will be paying on your network so the base feed this is not something that you would set as a network there is actually an algorithm and it is determined dynamically so if I'm now forming block n the way how I calculate base fee is that I will take a look at the previous block I will take a look at what base fee that previous blog had and how full it was and if it was less than 50 % full uh with respect to the gas limit of this block the base fee decreases if it was more full the base fee increases so it's dynamically determined well what's going to happen on your rollup imagine that you have just spun up a rollup Network your primary purpose is to scale ethereum so you will have a lot of blocks you will be producing them very quickly right some chains go sub 1 second sub 1 second we are producing blocks every 2 seconds seconds so every 2 seconds there will be a block and that block will not be small you know you will give it exactly the block space that ethereum had or bigger because you want to scale it up right that's why we are here well then the reality is that depending on your Cadence and the capacity of your blocks they will actually be pretty empty it will be pretty hard to you know get 50% full block every 2 seconds right so the reality for a rollup is that what we started calling the ultrasound money for ethereum for you actually means that your onchain profits will be formed by tips because you will have long periods of many blogs that will just drive the base fee to zero it's very obvious when you think about it but until you really notice it once you build something you know it might not be so obvious all right so earlier this week or last week we had the bit incident which actually was the inspiration for me to include this section when we run networks in centralized or even decentralized setting there are some roles that have Privileges and that can modify I don't know the access control on the smart contracts the state of the L2 chain and so and so on so this exists it exists on all the networks and everybody who is operating some kind of multii with strong privileges has to you know be aware how to sign transactions properly and not screw up in the process so this is what we are doing it always worked it didn't come to bite Us in the ass yet so you might consider doing something similar but obviously no pressure the process that I'm going to be describing for you is how we are doing it and we are working with one prerequisite which might sound strong but it's actually not so strong so the prerequisite is that every single holder of a multi- private key on our end theer is Technical and it's technical enough to the EXT that they understand what the signing process is about what account is what smart contract is how transactions get encoded how to execute a trace how to actually take a look at the trace and check what was happening and really fully understand the effect of what they are signing and I said that this might be sort of hard people to swallow because sometimes you have Executives who are actually not technical are not best suited to actually have this understanding but this is in reality not a problem because every single non-technical executive who is on a multi-c can actually be signing with an assistance of somebody else who doesn't hold the private key directly but understands the entire process and can walk them through that right so in our case we actually decided that we do not want to use any kind of website or web UI for signing multi- transactions the reason is as follows it doesn't matter what kind of front end you are using for creating this transaction and signing it every single front end can be compromised so in our case we've actually decided the smartest thing is to reduce the size of the front end and reduce the size of this attack surface to the minimum and that is best achieved in our case by using very simple scripts so no complicated uis nothing like that everything is scripted and in the process of signing we have inserted many steps where designers actually take a pause take a pause and uh take a look at the Integrity of the data and of what they are really signing so before we start signing the uh there is always somebody some developer who prepares the code in our case we assume or we want that the effects have to be known to every every single signer or the intended effects of the transaction have to be known to every single signer before any sort of signing occurs so we have a developer who prepares the code and creates a PO request could I ask the stage manager to maybe no okay fine uh all right so uh we have a developer who prepares to pull request and that pull request is you know queued up for a review and for merging to our code base then we gather all the remaining signers who are supposed to sign this and they do a code review very typical code review that you would normally conduct when you are merging features uh into your code base during this code review they check how this transaction was formed and what the intention really is they will check all the parameters and values that would be passed to this transaction they will check correctness of the remainder of the code that the proper signature is applied that the chain ID is proper and so and so on and they will make sure that they fully understand the effects of this transaction if it was signed by everybody and if it was executed upon this review the code is merged this merge and review is really important because this is really the moment when you can say that all your signers are actually aligned on the content of the transaction that you are signing but nobody signed anything yet so after that happens the developer or an appointed executor of the transaction cues it up in the multi-c and that's the moment when everybody else should actually get together and sign or you know pull out their Ledger and sign so prior to signing what our developers or signers do they actually use some technical tooling such as Foundry such as hard hat such as gu itself such as tenderly whatever they prefer and we encourage them to use actually multiple methods they do the trace for the transaction and they check it they check the method selector they again check the parameters they check the values they check the entire trace for intermediate calls that are being made so that there is no smart contract that is unexpected or some other account that could be otherwise compromised they will also check the effect trans of the transaction in terms of the storage so they will check that the proper storage Sals are modified and that proper values are recorded in them and that the resulted State on the Chain will be correct and finally they will check the success of the execution right because the fact that the transaction you know obtained some kind of a trace doesn't mean that it executed and didn't revert and only if everything matches to what we expected during that code review process and it matches the intention then we proceed to signing otherwise Ring the Alarm for all the other signers during signing itself that's when you have The Ledger connected to your computer using your USB again we ask the signers to compare the entire payload that shows up on screen to what they saw during the review and what they expected and again if if it doesn't match if there is a character difference they will not sign and they are supposed to uh raise the alarm so this is signing that only gives us these signatures but no transaction was yet executed on the Chain so now it goes to the lead of this process to that executor who collects all of these signatures we use you know internal communication channels for you that can be signal that can be WhatsApp that can be slack whatever you are comfortable with honestly once a transaction is signed it's signed you know it's out there so we uh or the executor collects all the signatures they check the validity and they once again go through this entire process of tracing and simulating and then check everything that I have just listed and only if this again matches they will go ahead and they will execute transactions finally there are some operational aspects right so a lot of stuff with these checks in the process can actually go go wrong or if you know there is a problem with some of these steps we want to have very convenient way of conveying this information to the other signers so what we actually usually do we either get on a call or you know together with a bu in the same room and we sign together so that we can discuss anything that sort of appears weird right for example when your uh wallet asks you to upgrade the firmware right when you are about to sign a sensitive transaction that's you know probably a little unexpected right so we make sure that we have the ground for quick discussion and everybody remains Vigilant So This Is How We Do signing I have roughly 2 minutes left so I'm going to speed up here quite rapidly there is a whole bunch of topics that you know I could include into this mini class so first of all if you're developing a network if you're developing a rollup understand that staging networks and test Nets are your friend with every single feature however you test it in your unit test integration test or whatever like that you will actually never obtain the real noise that you will get on the public network nodes being down you know fluctuating gas prices uh reorgs and so on so set up a devet or test net for every single feature that you are building this is what we are doing we are actually having five stages for every feature first stage is the local environment that the developers use so it's some kind of a li image doer image that is uh running on their uh local machine once they few appr requests we actually deploy everything to a stage that is called alphanet it doesn't have public access all the rpcs are you know controlled by us but it's already deployed against the POA we hook up multiple peer nodes we hook up the front ends that we care about so that you know everything can be tested once that's done that's moving on to uh beta net where we add proving and Integrations that tests all those processes that actually take multiple hours to go through uh then it moves onto public test net which already has access uh for the general public and only if everything is stable it moves onto mainnet since I now said that we are setting up five stages for every single feature we are building you know the next obvious advice make sure that you have enough sepolia e looking back into the summer we have days when you know we went through 500 eth for every single stage uh because it was just costing so much to roll up blobs and you don't really want to spend insane engineering Cycles to save you know gas for net ether you can just get more you will have to focus on CICS you will have a big system uh it will take a lot of time to build and uh you will need to get your team new laptops get ready for that if you're operating on development equipment from 3 years ago you will be insanely insanely blocked and I could speak for ages and ages and ages there is many more topics so if you enjoyed my talk if you enjoy content like this catch and talk of ours at a different event but at this point I would like to thank you for your attention thank you for coming to East Denver if you want to talk to us we have booth on the main floor thank you that's it [Applause] [Music]