Immutability and Upgradeability: Security vs Security

Transcript

we're already set up for our second to last speaker guys who's going to talk about immutability and upgradability security versus security SC ladies and Gentlemen please put your hands together for tog Mah [Music] maharam hello everyone my name is to girl I do research at scroll and today I'm going to talk about immutability and upgradeability within r s and how both are just different dimensions of security so fuel V1 deade what do they have in common the same applies here what does arbitrum optimism polygon

scroll Stark net ZK sync and many many others have in common so in the case of the former it's the fact that they're both immutable and in the case of the ladder it's they're upgradeable but both of them do that for sake of security but they are just different approaches to security so first let's talk about what a rollup is in in in the context of upgradeability so a rollup is required to have a 28 day upgrade delay and that that is relevant to the bridge and uh terms and conditions apply meaning the we don't really have a

universal definition for that vitalic for example uses 30 days some people say that you can have a security Council to upgrade instantly Etc but I'll talk about that later but let's assume that this is the concrete definition for now uh so we have a rollup we have a base layer so in the case of the all the rollups that I listed before that's going to be ethereum and we have a validating bridge that is deployed on top of the base layer and we use that bridge to communicate uh to facilitate communication between the face base layer and the rollup and so let's say we have the first version of the rollup Bridge V1 etc etc but something went wrong or we

want to add a new feature and our bridge is immutable what do we do then well we just deploy a new bridge instantiate a new rollup and that's it so and let the people deal with migrations etc etc now let's go with an example of an upgradable Bridge so you have the same scenario Bridge V1 roll up but the bridge is upgradable in this case you take the base layer again deploy the second version of the bridge and now you just communicate with the second version of the bridge so there's no migration involved unfortunately both of the these approaches have their own downsides and upsides so what are the uh what are the

upsides of immutability so one of the upsides is the fact that there are no sron assumptions I I'll explain what that is in this context later and uh there are also no complex exit strategies and the protocol is rug resistant but unfortunately it comes with a significant con actually two of them so one is you can't PCH vulnerability so for example if you find a bug in the Pro in the bridge or the protocol that's it you're stuck with it like there's nothing you can do the only thing that you can do is warn the users to exit as fast as possible and uh there are no State migration uh strategies in case there is a protocol upgrade so for

example I want to add some new cool feature to my rollup and I need to upgrade the bridge for that what do I do in this case no nothing really I can't really do anything I'll just deploy a new instance and hope that the users and the application operators migrate to my new version and upgradeability see upgradability has its own pros and it's basically the inverse uh we are able to patch wner ability so let's say there's a bug I can instantly upgrade the contract and make sure that the attacker doesn't get to it before I upgrade and the same is true with a protocol upgrade so essentially I can just upgrade the bridge and let the users have the latest features without

having them do any work but again unfortunately it comes with the cons so there's one there's synchron assumption so uh let's say there's an uh the upgradeability is delayed so there's as I said before there's a 28 day DeLay So the users have only 28 days to exit in case of a malicious upgrade so let's say I uh my upgradability key got hacked and I upgraded the i initi i initiated the upgrade in a way where you can steal I can steal money from you once the upgrade is finalized uh so the the users become aware of that but they only have 28 days to exit and basically let's say if you're out on an

island on a holiday and you come back after two months that's it your money may be gone and two there the exit strategies are very complex so let's say if there are a lot of users on the rollup and there's a malicious upgrade and you know that you need to exit within those 28 days the problem here is that there might not be enough capacity on ethereum to allow you to exit without paying exorbitant amount of fees and therefore we essentially get the same problem that we had with plasma which is that uh there's a there's an exit problem a mass exit problem here where the people trying to exit to the1 can just overwhelm the entire system and no rug resistance but again

as before terms and conditions apply so uh in in this case rug what I mean by rug resistance is that you can replace the contract with a malicious contract and instantly deploy it so let's say if there's a delay this is not applicable but in some cases as I'll explain later that might be applicable so and one more note so for Z kvms for example immutability is not an option and once again terms and conditions apply here so uh and the reason why they apply is because let's say if evm osies tomorrow then it's perfectly fine to have an immutable Z evm but since the goal of ZK evm is to retain compatibility with evm there is

uh we always want to make sure that we are able to upgrade the Z evm in case evm gets upgraded to make sure that we always retain that compatibility and therefore we need to have a certain upgradeability path and so what is the current state of the art approach so let's say you're a zqm that needs upgradeability you would have some form of a delayed upgrade let's say 28 days with an external Security Council that can essentially shortcircuit that delay and uh bypass it and allow you to upgrade in instantly so what is a security Council the Security Council is typically a set of external entities between 12 and 15 who are

responsible for who have the capability of initiating uh sorry not initiating FASTT tracking the upgrade so uh again I initiate the upgrade the delay is initiated but then the Quorum signs and the the the delay is either shortcut or completely removed and the upgrade is handled straight away sorry uh so so that's how it will work so let's say the delayed upgrade is initiated by a three out of five multisig team multisig you initiate 28 uh day delayed

upgrade but there's a bug so you don't want to wait for 28 days the reason why you're upgrading is because there's a bug so uh there comes the N nine out of 12 Security Council multis so if the Quorum has reached there they can just sign uh send the signature the Quorum signature to the bridge and bypass the delay and the uh the main reason for that is to allow us to have an instant upgrade in case there's a severe bug that may potentially result in funds being trayed but uh it also allows us to not have internal control of upgrade instant upgradeability so we outsourcers

to some trusted third parties so for example l2b would be a good example of a trusted party uh and but as I said there are cons to this as unfortunately with everything in life one is coordination complexity so let's say if you handle the upgradeability internally it's much more easier to coordinate with people and let's say if there's an emergency where you need to upgrade as soon as possible it's much easier to get hold of uh parties that are internal to the team whereas when it comes to external parties it might be problematic or even impossible to reach them at a certain point and two there's a risk of potential comp complacency so what I

mean by compl complacency in this case is let's say um I just sign every every upgrade without checking it so uh the reason why you need the Security Council is that so they can check that the upgrade is actually valid but if nobody checks they can just trust that the team is being honest and sign it without checking anything and in that case it just adds an unnecessary step it doesn't benefit anything in terms of security so an alternative approach to using some form of upgradability would be enshrinement of the validating bridge and what I mean by that is enshrining we basically uh make the

bridge part of the base layer protocol so in case of ethereum an example would be optimism would be optimism Bridge would be part of ethereum protocol rather than a smart contract deployed on top of it and basically it enables us to have the social consensus of the base layer handle the validating Bridge upgrades so the way you would upgrade ethereum so add certain features so for example recently we added push zero as an OP code you would do the same with the bridge you would just uh it would just come in one package and some form of a pre-compile probably or something like that and that will be just changed uh in the execution client and that's it but unfortunately again there are downsides here so so one it negatively

affects the base layers credible neutrality and so what I mean by that is let's say in case of ethereum there are probably 20 different rollups and of different types Etc uh and ethereum is unlikely to support all of them to ins all of them so they would have to pick the winner or pick a couple of winners and therefore those winners get the preferential treatment over everybody else and that affects how neutral uh if ethereum acts towards protocols being built on top of it and two it increases the burden of coordination for the Bas layer social consensus because now you don't only have to take care of the evm

features consensus Etc you also have to take care of the features of the bridge uh you need to coordinate between more teams and that results in slower upgrade times etc etc and makes certain things uh even more difficult that they are right now but there are more cons uh so it also increases uh the base layer upgrade uh upgrade complexity so as I said before because you need to coordinate much more and also because it adds complexity to the base layer the difference here is that let's say if the enshrined bridge fails then the Bas layer protocol fails if the bridge that is deployed at the contract

fails ethereum still works as intended it doesn't really affect ethereum per se and therefore you need to make sure that the upgrade is secure and it might take longer time to audit to look at different parts Etc because roller bridges are quite complex and because of what I described before it incentivizes homogeneous validating bridge design so what I mean by that is it incentivizes the base layer to have only one type of bridge so for example optimism or Stark net or some other type because of the complexities involved you would rather

just deal with one than have three four five whatever and deal with them separately which will slow down the upgrade path even more and make the social consensus even more complex to handle and what is the perfect solution then well again unfor Ely there's no there are no Perfect Solutions uh and every single solution that I have outlined a fortunately has certain tradeoffs in terms of security and uh one thing that you should remember is that because rollups are not mature enough right now there are still a lot of things that are yet to be

discovered or implemented or even thought of and therefore the state of the rollups right now might not be reflective of where the rollups are going to be in the next two years it might be the case then in one year this problem is completely solved and it was just a nothing burger that nobody should have thought about so thank you for your attention and if you have any questions feel free to ask [Applause] them thank you for the talk I really enjoyed

it uh I have a question what is scroll scroll is a zvm based roll up on top of ethereum specifically where type two roll up zvm from vitalic gradation of rollups so we are bite code equivalent but we are not ethereum equivalent meaning that you you are able to prove the computation of evm completely but you're unable to prove ethereum blocks with an RZ evm

question [Applause] everybody