Enshrining zkRollups Into Ethereum | Porter Adams - Matter Labs

[Music] hello welcome everyone I'm excited to be talking about enshrining ZK rollups into ethereum so my name is Porter I am a protocol security engineer at matter laabs matter laabs is one of the teams that's building ZK sync which is one of the biggest rollups we're also one of the fastest and cheapest uh this talk is not too much about sync it's more just about in general what is enshrinement and how does the how does that affect the long-term future of ZK rollups in particular so this talk is based on this blog post by vitalic that came out last year um should ethereum be okay with enshrining more things in the protocol now I'm going to explain what enshrining means it's kind of a big word I'm also going to say that word like 50 times during this presentation so here's the agenda enshrining dein shrining future um it'll be fun I think it's a really cool topic so what is enshrinement it's a good place to start enshrinement is including something into ethereum's core protocol so there are lots of things that happen sort of in the ecosystem around ethereum the l2s all the smart contracts all the applications and then there's some things that happen within ethereum itself and so the question is always like what should be included into the Proto ethereum protocol itself and then what should be left to like the smart contract ler basically so here here's a joke from one of our our head of Education cougan U made this meme for me so I think it fits well if you love zkm so much why don't you just incorporate them directly onto the L1 now I do one caveat for this inment is not just for rollups I'm going to be talking about rollups because that's what I'm most interested in but we could talk about enshrinement for any other like application pretty much in the entire space so for instance Unis swap maybe ethereum should have built-in token swaps uh for like erc20 tokens so that theoretically you could enshrine Unis swap into ethereum core and then it would be sort of the default way to swap the same way for ethereum name service um tornado cache if you wanted to enshrine privacy and actually include privacy at the protocol layer of ethereum um I'm not sure that one's going to happen but it would be cool uh oracles are another good example of it would be nice if we could use the ethereum validators themselves to sort of be the oracles because we already trust the ethereum validators but we don't trust the the or I don't trust a lot of the the Oracle providers um liquid staking Etc anyways today we'll just focus on in shrining uh layer twos or rollups specifically so first background how do l2s rollups work uh without enshrinement so this is the current state of things um this diagram kind of helps parse out some of the buzzwords so you start as your user and then making your way through your transaction gets included into a block through the sequencer um there's an unverified block that data is posted down to an ethereum um and then for ZK rollups we prove everything with zero knowledge proofs the proof is also posted down to ethereum and given the data and the proof that it's valid now this way ethereum can keep track of everything that happens in the L2 so using the L2 is like the same security as ethereum um so this is the picture that we're working with um you don't have to get too much into the whole top half of the picture what's most important for enshrining is that the only thing that really needs to be on the layer one is posting some data and verifying a proof uh which is is very very minimal and so if we want to include this I'll I'll go into more detail later but if we want to include ZK rollups into ethereum it would not take that much effort because most of this still can happen to Layer Two not that many changes would need to happen to ethereum um current situation what happens if we need to update L2 this is kind of the motivating problem for this um ethereum makes changes every couple months they're big upgrades similarly l2s have their own upgrades occasionally security related but sometimes we're just trying to keep like equivalent with etherium and so if you need to be updating you can't be using a mutable smart contract so someone needs to be in charge of who updates the verifier on the L1 and so this is kind of the problem with the current model um is it's not the ethereum validators but if we enshrined uh then the ethereum validators would be able to update ethereum itself and the L2 at the same time it's kind of weird to have like separate update mechanisms it's kind of messy um so in in a little more detail currently we have uh Security Council and then multi-prover systems these are kind of two ways to help control the update mechanism uh so the multi-prover system is something that I'm actually very proud of we have at ZK sync we are building a sgx trusted execution uh version of our ZK proof system so if if there happened to be a bug in our ZK proof we would also do a completely separate implementation inside of sgx and only when both agree can we actually move L1 State forward um so this kind of gives us that added resiliency to our protocol the same way that ethereum layer one has multiple different client client implementations U the multi-prover is kind of the equivalent for ZK rollups um occasionally though um we still need to do updates like multi-prover you know might both might need to be updated at the same time if we make some change to the protocol um and so the way it works is we have a security Council uh this 407 is a screen shot from balic blog uh it's not details on how ZK Security Council uh Works um this is just generic um picture so you can get the idea but with enshrining so a lot of people critique the the security Council because it's a little bit trusted they get to upgrade the code what if they upgrade it to something bad and so even if you do like four out of seven or say you do like I don't know 100 out of 15 people in the security Council like you have some crazy massive thing like it's still hard to tr it's still not as good trusting those like 150 people as it is just trusting the ethereum core uh full nodes um so how do rups work with in shment so if we enshrine rollups again all we need to do is change this base layer down at the bottom and pretty much you just need a verifier included natively into ethereum um so that's it it it would be pretty nice and then when um E when we're making an update it would just need to be made in each of the different like ethereum client implementations G and WTH and all the others um and this way like they would decide hey we're going to you know upgrade to 444 at this time and in the exact same like step we're also going to upgrade ZK sync's verifier contract to like match the 4844 changes um this way we don't have to have like this separate Security Council come in and do the same upgrade at the same time um cool so that's kind of what is enshrinement and some Basics here's like the kman arguments against it uh one we want to keep ethereum core simple and to keep it simple we you don't want to include too many things into ethereum core so in that first list of all the different like protocols with privacy and Li what's taking and there's m V stuff like if you like start enshrining everything then you end up with like a very large core protocol and a balic talks about like unix's philosophy is like keep it very minimal and then let the higher layers figure everything else out um second point on why not enshrinement maybe is give more flexibility instead of having one enshrined option um I'll talk about this in a second why I think this one's a little fake um and it's maybe people not quite understanding what's going on but like there's lots of options whether something's included within the ethereum core protocol or whether it's like done at the Smart contract layer um in fact giving developer well actually I'll get to it in a second I I have critiques on all of these points so and and the last uh critique which I think is probably the most serious but also the most important is overloading ethereum consensus so overloading ethereum consensus means we shouldn't use the ethereum consensus mechanism for too many different things because we don't want to be having arguments all the time on like what's the current state of the chain uh so we want to have like it should be pretty rare that we need to like have a bug fix or do an upgrade or anything else um this gets into like reaking is kind of a similar idea where you're reusing the validators for other purposes enshrinement is like a more direct way of doing that where you're just giving the validators more responsibilities um so anyways argument for in trining anyways uh instead of like keeping ethereum core simple is nice but from the perspective of users it's simpler to enshrine like you want the whole system to just nicely flow together and there's just like one update mechanism that everyone can use and so I think like overall and for the users it's simpler to do this so uh could be good to enshrine still uh uh again giving more flexibility or having one instand option sometimes like in shining uh gives developers more tools to work with so the current example is account abstraction on znc we already have native account abstraction but on the ethereum layer one the like uh the user facing accounts are like sort of privileged in a way and by enshrining account abstraction you can have all kinds of like smart contract wallets and other ways of like signing and creating signing signing transactions so um it's almost like dein shrining the the old user accounts by giving like ethereum developers more options to work with for and like more flexibility for building wallets and all these other things so um and traning doesn't mean like limiting it it can be like opening for for more options and then the last uh critique was overloading ethereum consensus uh if we don't use ethereum consensus then we're stuck with security councils or like even worse like whatever uh the like bridges are using and all these other random multi sigs and like sometimes like you can give multi very nice properties but really at the end of the day at least I really want ethereum full nodes like if you're just running it full node at home you should be able to like check everything and check that everything's being done correctly and I'm in favor of like in general giving the full nodes the the power to do this I think they're the most trusted group as opposed to any other like if if every protocol has to make up their own group of like trusted people it's kind of it's kind of a mess so ZK rollups are well suited to being enshrined in particular um ZK rollups are finalized as soon as that proof is verified by ethereum and the proofs are like relatively quite small I mean that's part of why ZK proof starts to sync it's a very cool property so to insine ZK rollups we just need an enshrined verifier contract and this could be like a it could be a very neutral contract so there's lots of different uh l2s and ZK rollups and um we we could all share like one ZK verifier obviously has to be tied to like one ZK proof system I'm getting into some like the the Nuance like implementation detail here but even if we pick one proof system you can still like you can do a stark proof and then wrap it down into a snark proof and so it's not too big of a problem as long as there's one available like enshrined uh ZK verifier um all the rollups can use it if you have like multiple hyper chains and the ZK stack for example they could all use it at the same time um so you don't have to enshrine like 50 different verifiers for every single one of these chains or every single one of these projects that's not how it needs to work you really just need one verifier for every single ZK rollup and the world works and it's magical and that's part of why ZK proofs are amazing okay so future of enshrining ZK rollups um as much as possible I think ethereum validators should decide everything um and also I think we should have more discussions about what should be enshrined I think there there's lots of room here for cool design I think reaking is sort of taking the narrative over but potentially like if if some protocol is like adding that much value to ethereum and it's that important uh that a lot of ethereum validators are like reaking and users are using it and it's doing very well I think at some point we should just enshrine things into ethereum uh we get better security properties it's better for the users uh there there's a lot of like good benefits to enshrining things and ZK rollups in particular I think are are very well suited and um I think it's the future of scaling so uh think it's very cool but if you want to talk more I think um that's it thank you I will be over at the booth uh at the ZK Quest Booth happy to talk about this anytime or if you want to know ZK details or anything else thanks