DAPPCON 2024: Path To Multisig-less Rollups - Toghrul Maharramov

Transcript

hello everyone uh my name is to girl I pretend to do research at schroll but I usually just complain about things on Twitter and today we're going to be talking about how we get to multi-us rollups and I'll explain more but what I mean by it in a bit so yeah just remove the multi that's it that's the entire solution thank you no I'm just joking let's go back so uh let's start with this great screenshot from L2 beat and it shows a lot of familiar names here arbitrum optimism base there scroll underneath there but and there are a lot of red things the color red in that pie

and all of those pies over there so there's this nice scroll down menu there that you can pick and it shows the stage of uh that you can pick and filter the protocols by so let's do that let's pick stage two and let's see oh all of a sudden you only have two protocols one is Dade which is an ZK rollup that as application specific and as aex and then there's fuel V1 which is an optimistic rollup that does payment and has what $953 oh it actually went out it used to be $8 so uh great great thanks bck for your contribution

uh and as I said both of the those rollups are application specific so let's go back to the question why why why is a multisig necessary or let's be more precise here why is upgradability in general necessary for rollups I think with with app specific rollups you can get away to a certain degree without having a multi but if you're talking about general purpose rollups I think it's not a question and I'll explain why it is later so if if you're a bit of a conspiracy freak the answer would be the covert cabal wants to retain full control over the user funds but I'm not a conspiracy freak so I'll take off the team fall hat and

let's talk about the reasons why you actually need a multi or upgradeability so one is security and so you great you build a rollup it's super good it's super fast it's super uh the proving is super cheap but what if there's a bug like you don't want to be on this board and this is incomplete like a lot of the projects uh warm hle and stuff are not on here that had hundreds of millions stolen from it and as we know smart contracts are complex and with rollups they're even more complex because you have the verifier you have the bridge you have a lot of different functionality than an average defi contract doesn't have and so it's likely

that there are bugs in there and there are potentially bugs that can lead to catastrophic consequences so and to that you must also add that you have provs so uh in case of optimistic rollups how many people actually understand the game theory behind how fra proofs work and how they're Implement yeah BK five oh okay the BK says five so I trust him on that uh and then on on the Zero knowledge side how many people can actually audit the circuit I would also say five here as well so we're not it's we almost treat both the fraud proofs and the zero knowledge proofs at black as black boxes and trust a handful of

people in the world who can actually look at the code and audit and understand what it's doing that that they're actually paying attention at all time and didn't miss an important bug and then the second reason why you want to have upgrade abilities feature expansion so for example say you're building an evm equivalent rollup it's either an optimistic rollup or ZK rollup it doesn't matter in this case so evm equivalence requires you to expand the feature set in case evm specification adds some new feature let's say new cool op code is introduced or we get something that improves the uh the fees so for example multi-dimensional fees Etc ET and you're

evm equalent so you want to support it but to support it you actually need to upgrade the code uh on chain code so you need a way to upgrade the contract and currently most of the solutions involve some form of multisig but you might rightfully point out that oh yeah but Security Council is are a thing you don't need a multisig but what is a security Council so like security councils are communes that have ability to initiate FastTrack post roll of contract upgrades like it depends on a specific imp implementation of the security Council and it's usually uh cons it usually consists of external parties so I think the definition of uh

Security Council that El to be in theal propose is that up the maximum amount of coure team member that can be members that can be on the Security Council is 25% of the entire multi and so it is a step in the right Direction because it's not fully controlled by the team but it's still a multi and a multi is a multi like of course you can argue that an external team might not be uh it might not be as easy to compromise as like a bunch of team members but it's still an honest majority assumption so essentially you have a rollup that has all the tech underneath that allows it to have a trust minimized bridge that cannot have a trust minimized Bridge

because you have that multi- working underneath and so I I showed the graph before about State uh where we filter out stage two rollups so like let's examine what a stage two rollup actually is and specifically we care about upgradeability here there are a lot of different things that require uh a rollup to comply with in order to be a stage two but in this case uh uh stage two rollup should allow users ample time to exit uh from the rollup in case there's a malicious upgrade so what that means is let's say if you introduce an upgrade there has to be some time to allow those users to exit in case they either

disagree with the upgrade for one reason or another or it's an actual malicious upgrade so and typically we Define ample time as 28 days so that means that if you upgrade a bridge to either add a new feature or to fix a bug which is even more pressing because like with features you can wait for a bit but like if you're fixing a bug that is critical and then that could result in funds being drained this is not really a good option because by the time the upgrade actually is in effect the funds might be gone and so I lied a bit in the name because you can still have a multi-c that initiates those upgrades even though I expect the majority of the rollups actually use some form of

governance to do that or the security Council to do that but uh it has to be delayed by by 28 days as I said before at least 28 days so how can you become a stage to roll up without compromising on security or future future expansions so there are a couple of steps here one is multi-prover so why should we have one PR when we can have multiple provs and specifically distinct provs because if you have two provs working with the same implementation and the same ZK system computing proves then it doesn't matter you might as well just have one so for example you can combine halo two prover

with an sgx prover so how it will work is basically you have those two provs working in parallel and uh they submit the attestations uh and then also submit the state Roots the output State roots and so basically and the bridge Compares those output State roots and if the output State root Roots don't match then it just holds and doesn't apply the state transition that the corresponds to that state route and basically what it allows you to do is to protect against correctness bugs in case there's a vulnerability inside one of the proofs so you you can think of it this way this allows us to D downgrade uh

correctness failure in case of a bug to an availability fa failure of course if two of the provs have have the same bug in them then this doesn't really protect against that but it's unlikely that you're going to have the same implementation of bug in both of the provs and basically in this case the the bridge would Hal and you either let the governance choose what to do next or have the security Council pick the correct Pro which is much better than just having the fund stolen but that's not really enough because that only solves the problem with provs but we still have the problems of with smart contracts the same problem actually what

if there's an implementational bug and that's where multi verifiers come in so with multi as with multi proofers it's the same problem here why not have two distinct contract implementations you can have more but like let's keep it simple for now and say two so uh and we also remember that aside from implementational Bugs on the on the smart contract side you can have contracts or the bite code that results from a contract code suffer from a compiler BG it happened recently with Viper and curve when certain curve pools were exploited because of a compiler bug

and so how would that work how do you do that on the verifier side so you combine two implementations say one is in and another is in Viper and you have two implementations running in parallel and the way it works is is it basically protects you from both the compiler issues but also uh diversifies the implementations which means that you you you're not only protected from the bugs that you introduced but also are protected from the bugs that are introduced on the compiler level and to make it work we need a minimal adapter

contract that basically handles the checks whether both of those contracts say as I mentioned before like let's say in solidity and Viper are producing the same mutation so for example if two of them are are trying to ask for a different slot to be changed or like a different mutation to happen in storage uh within the same uh State transition then it just Rejects and it it holds and the same way it will work with a multi-prover you convert uh you down downgrade a correct potential correctness failure that results in your funds being stolen to an availability

failure that again can be either resolved through the uh governance or the security Council it's up to you how you how you sort that out there are downsides to both of them and basically the main downside is that both both of them in increase the cost of settling on ethereum which means that especially right now when the cost is not negligible as is introducing additional cost which will mean that certain users are going to say like why would I use you when I can use somebody else and it's difficult to rationalize with a lot of people about the security features that the security properties that you introduce with that but

hopefully as time passes as ethereum becomes cheaper to settle on and we come up with better ways to optimize the costs this becomes more and more viable and then and we basically talk about implementational bugs but that doesn't really touch on the specification side uh failure so for example you have the protocol specification and it has an inval statement in it that might result in funds being stolen this doesn't protect against that so what do we do there uh so as I said like even if your implementation is completely bug free the specification can have some faulty

statement in it and that's where formal verification come in comes in so if you combine the multi-prover the multi multi verifier and formal verification you get a system that is sufficiently secure where where the probability of a safety failure is decreased to a point where uh the risk of having delayed upgradeability is acceptable thank you and feel free to ask [Applause] questions great and thank you very much so we have about five minutes to 10 minutes for some questions so over here on the left okay so I have a question do

you think that we could combine the uh fault proofs or fraud proofs with this system to reduce cost meaning that you always go through one implementation and one prover maybe not the prover but the implementation right and then you give some time window it doesn't necessarily have to be 7 days because there is no challenge game right can we do that can we reduce cost in this way yeah I think that's definitely possible to build a more optimistic system but uh the downside here is you're introducing Game Theory again because there are certain things that you need to take into account and also you're delaying finality which I think is fine for now but the more we go uh

further and the more we actually get to the point where we can produce real-time proofs and have near synchronous composability between different LTS that becomes a real downside and I don't think you can shorten it to a point where the the time difference is negligible you still have to allow for like at least an hour or a few hours for this to work great uh next question yeah over here on the left hi thank you for the talk uh we're here um so like fundamentally it looks to me from what you describe is that we don't actually get rid of the multi so we kind of still have some kind of a committee or some kind of governance that is fundamentally the multi so am I correct that basically we just decrease

the share of edge cases where this multi will be applied like what's the what's the fundamental difference to what we have now so uh let's say we we refer to governance as multisig in this case uh the multi would only act uh in two in two different can act in two different ways in this setup one in case they want to introduce an upgrade but this is delayed so we just need to allow the user sufficient time to exit in case an upgrade actually happens and the second uh time when it's actually introduced is to break the de log where let's say you have two implementations and one disagrees with the other you introduce it to basically solve the

availability failer but what you can do instead of multi there you can actually have a third implementation working as well so it acts as a tiebreaker and both it's just a bit not not very viable right now because it'll take a lot of resources but I I can see in the future how you can have two primary implementations working all the time and then the third implementation acting as a tiebreaker in in cas in case one of them fails so I I think I I would agree that the title is a bit misleading you still have multix but you don't have them acting in the same capacity that they do now thank you thank you