Security and ZK-Rollups - No compromise approach to scaling Ethereum

the next discussion is called security and ZK Roll-Ups no compromise approach to scaling ethereum moderated by Sam Kessler at coindesk and we'll have Michael Llewellyn at open Zeppelin Riptide a white hat Sandy Pung scroll and Anthony Rose at ZK sync give a warm welcome sweet hi everybody thanks so much for joining us um we don't have that much time so we're gonna jump straight into things and just talk first maybe a little bit about for those of you who are less familiar what is the difference between a ZK roll-up to scale ethereum and an optimistic roll-up to scale ethereum specifically with regards to security maybe Mike you can kind of get us started there all right so uh first preface is not an auditor but I work with very smart Auditors so I can translate for them and simplify and so we've done audits on optimism we've done audits in CK sync um and the main difference that you end up finding is that with optimistic Roll-Ups you're awesome you're optimistically assuming that the transactions that you're running on the L2 are going to be correct but you're going to give a challenge period for someone to prove otherwise essentially um so the the fraud proof is actually fairly simple in terms of complexity the complexity usually comes in the fact that you have to worry about a fraud proof coming through during your seven day period with ZK Roll-Ups the technology that makes it work the contography can be very complex and difficult to understand but the actual proof in terms of like knowing that the transactions are valid when they're published on mainnet or on ethereum uh is actually like fairly simple it basically is just it is yes or no and as long as you uh some of the cryptography is working properly with all the other systems then you know the transactions are good to go sweet um so I'm sure everybody completely understands what CK Roll-Ups an optimistic Roll-Ups are now that was actually the the best overview I've heard in that small amount of time but we've got two of the teams who are building ZK EVMS here there's a bunch of teams trying to do it some teams are further along than others but it's been like one of the main things that crypto journalists have been covering when it comes to you know the the ethereum business landscape and the L2 landscape so we've got Sandy from scroll and we've got Anthony from zksync and I think now maybe you can one of you maybe Anthony starting with you you can tell us a little bit about what are the risks inherent to zero knowledge Roll-Ups um that maybe aren't there for optimistic roles or how are you thinking about those vulnerabilities yeah this is a great question obviously one that's uh something that we're thinking a lot about as we you know as many people have been maybe using the food truck experience can see the error is basically on the on the thresholder being ready for users I don't know about risks specific to ZK Roll-Ups being the thing that I would uh put as like our number one concern I think there's you know with any complex systems we're thinking about risks from sort of end to end right so we as we're approaching securing ZK Singh we're thinking about risks at the Smart contract level this is obviously common to many different systems including optimistic rollups we're thinking of you know risks inherent to complex systems that are not even unique to web3 right you're building complex software there are sort of application and network security problems that you have to think about generally things about Key Management there's just lots of different problems the only piece I would say is maybe uh specific to zero knowledge Roll-Ups is that the cryptography is hard right uh it's hard to get it right it takes a serious level of like uh intellectual effort it's hard to build teams that have the competencies to do this correctly um it's also hard to audit because you know you need basically like an adversarial auditor who's at least as competent as the people who built the thing so you know for us when we're thinking about security it's about like how do you think about orthogonal methods to secure the system so that at any one point that fails uh you know the system still has sort of uh redundancy in its in its security posture awesome um maybe let's move to Riptide like we just heard about what some of the risks are um in Roll-Ups generally and in ZK Roll-Ups and you're a white hat um you hack these systems find vulnerabilities what would you look for if you were a white hat or not a white hat in these systems when they come out so I don't I don't think I understand uh all the cryptography I'm not gigabrain I'm just a simple Chad what I would do I used to work it tech support and people would call in and they say oh what's the problem this was the problem this first thing I'd say is it plugged in so oftentimes I think these teams they're so smart and they go so deep in detail that they miss the forest for the trees and so you're looking at the mathematical proofs this and that and then meanwhile you've deployed your concrete contracts incorrectly or you've missed something glaringly obvious and I'll be that one to find it yeah it's interesting when I talk to ZK teams they often talk about how the um there's so few people who understand the technology I mean maybe Sandy you could speak a little bit about I I there's a lot of nuances both to how ZK Works generally but also to how different implementations work maybe you can speak a little bit about how scroll is going to differ from ZK sync and some other platforms and what are in your view some of the advantages that come from this byte code level equivalence even though you know you say you'll both be compatible with all the same sorts of apps yeah sure um I think the question I've answered the most frequently in this conference is like what is an L2 have you heard of an L2 so it's always good to kind of step out and talk to developers and and and realize we're still very um early in this space and to answer the previous question you know one thing your question actually reminds me that for all of the row up teams um how how we think about security I I assume is probably relatively similar regardless whether it's ZK or optimistic the way we think about it it's a matter of um security principles and um and it's about kind of security being an ongoing process about um or we think about it from the terms of having an internal security team about having continuity um that I was kind of like joking before about you know let's start a new war on who's the most secure ZK or the most secure row up but that's kind of a meme because you know the security doesn't go from like no one can claim at one point saying oh we're now secure we're now definitively secure like that concept doesn't really like exist in the Realms of security um but I think the way we think about security is that we try to kind of um we've been open source since day one and we've tried to kind of implement a set of security principles and make sure that all of our Engineers are trained in like security practices and whenever we kind of commit code in the open source repo there are people from the open source Community or from our team who didn't work on that part randomly selected to audit it every single step of the way and as we just launched our test net or Gourley kind of a few days ago going forward we were engaging you know a number of individuals who are well versed in the space of ZK circuit to kind of audit um just kind of lend a lend a fresh pair of eyes to the entire code base but that's kind of a ongoing work and and we anticipate to continue doing for the for the next few years essentially um and to address the question of how do we differ from the other zkevms um I think we we we we set out on this path to build what we called a by code level equivalent ZK evm um and and I think with every design Choice there are pros and cons and there are trade-offs um with our decisions we're optimizing for um ethereum nativeness and we're also optimizing for um like easiness for developers so part of kind of going back to part of how we think about security um you know like when when a protocol has been running on ethereum mainnet for multiple years all of their debugging program and all of the things that that accumulates over the years about how secure a certain protocol is and we want them to be able to transfer to Layer Two without losing any of that historical Traction in terms of like you know putting in putting it like finding bugs and discovering process so so that's why we went for I'm 100 by code level equivalents and um the the plug there the advertisement here is that everyone wants to try out our test net it's on um you know scroll.io so I I think um you know implicit in in what we've been talking about so far is that this whole ZK thing um is it's a big money opportunity it's a it's a it's a race um in large part between a bunch of different teams a bunch of different companies and um you know to to scale up ethereum I don't know if it's going to be a Winner Takes all I don't know nobody will tell me whether they think it's Winner Takes all or not but one thing that has been a consequence of this race um for those of you following you know who followed Along on Twitter has been a bunch of different marketing we've seen from teams around who's going to be the first ZK evm to Market and different teams have had different ways of defining that um ZK sync like you guys have you know dueled with polygon another big team that's building a ZK evm to say that you're going to be the first in 2021 you said you were going to launch I don't want to pick on you specifically by the way um Anthony is very nice um 20 21 they said they were going to launch um and then you know they said there was going to be 100 days to maintenance and you launched a main and there was a bunch of criticism around what you launched was not necessarily A launch you were transparent about that but anyway I'm curious how you're thinking about this marketing side of things with regards to is has that kind of pushed you to roll something out that might not be as secure for end users you and other teams yeah I great question I would say I mean to your point about the quote unquote you know potential delays I think this is exactly because we haven't been pushed to do what we don't want to do with respect to security I mean the hundred days to main net peace I definitely think probably could have been communicated better in hindsight but for us it was always about you know how do we roll out a system that we've had live on testnet for a year in a way that you're uh being thoughtful about security being respectful about early users buying down risk yourself rather than you know rushing to say yes quote-unquote we're first let's open the doors and then you know users or developers have they're they're shouldering the burden so for us with with the deployment back in October the idea was always to run this closed version of the system work with teams like open Zeppelin work with you know white hat researchers like Riptide and really reduce the risk on the system and it ended up being the case that we found improvements we ended up fixing various bits and pieces and this led us to you know where we are today where two weeks ago or so ago we we opened up the system for external developers to deploy a few weeks from now we'll see we'll see users on mainnet we have also you know this sort of soft launch with the food truck experience which is running on mainnet today um but you know to Sandy's Point like security is an ongoing thing it's important for us it's it's something that we take very very seriously it's why we're not rushing to do things that uh you know might otherwise put users at risk awesome um so so my next question is for you Mike I'm kind of branching off of um the answer there so you kind of referred to these sort of training wheels that all of these ZK EVMS are launching with that's what vitalik calls them training wheels one of the big training wheels is upgrade ability so contracts like uniswap are not upgradable which seems counterintuitive in a web 2 context but you know Nomad a big bridge got hacked for 200 million dollars when it got upgraded and Auditors didn't catch because they had audited a version of the code then it got upgraded and Auditors hadn't seen that version of the code and whatever 200 million dollars were stolen so I'm curious what kind of a challenge that poses for you as an auditor um you know in the short term like how do you communicate your findings to people when these softwares are changing for a while uh it's a good question so there's a few things we do first of all um we could read the audit report and I definitely recommend everyone reads the auto report because sometimes there's things in there that um you wouldn't know about the protocol and you should read it that's where we confirm whether the documentation matches or not but the first thing we do is we say what are the trust assumptions and usually it is there are if there's privileged operators if there's upgraders we list that and we say we are assuming that they act honestly and this is the Commit This is a specific version of the code that we're addressing in this report so we just be very clear about this is the snapshot we're looking at we're not saying this is going to be secure forever we're saying or we're not even really saving secure now we're saying we've done our best to make sure it's secure at this point in time um and then going forward we make it clear like okay there's a proxy here's the implementation um and what we've done with other teams especially with compound and I think we're now doing a better Labs is we encourage like very close security monitoring of the multi-tig and of any privileged roles in the system one to just make sure like no keys got lost or anything that could have been loss of access which luckily with a high multi-sig is very difficult but also to show okay if there is an upgrade coming through it's not something that it's something that the community should be aware of and the one thing I liked about the zksync light approach was the fact that it introduced it was one of the few if you look at L2 beats and you look at like the the asterisk on the security for all these Roll-Ups the ZK sync did say hey for upgradability we are going to put in a time lock uh and the only exception of that time lock is if we have a very large threshold of multi-sig members who are from independent parties approve a rapid upgrade which would be like emergency scenario um you know we need to basically fix a bug that could otherwise cause uh users losses so I think like that's the best middle ground and I think the the path over time is the progressive decentralization like slowly take out the training wheels in terms of like restricting upgrade ability maybe it's instant today but it gets time locked more higher multi-sig and maybe someday you can take it out entirely and just burn the upgrade roll and make it so that it's immutable going forward but that's a it's a roadmap you have to be careful about because you never want to be in a position where you don't have any ability to respond to a security incident um so it's like it's a balance between decentralization and Security in that particular context and um I think the idea is for projects to just be clear about the expectations for what the system is now and then what it will be over time where they're going gotcha um Riptide maybe uh uh if I were a user looking at these audits um audit reports or you know probably not looking at these audit reports just looking um at these products is there anything that I should look out for not saying that you know your two products aren't trustworthy but like what should i as a user look at when I'm deciding whether to bridge my tokens from a layer one ethereum to a layer two how can I judge if something's secure that's one of the toughest things is is uh you talk about how users can assess the risk of providing capital and using these products and it's so tough when we need more transparency in the space so I think one of the things that we should do as users is look at the security posture of the protocol so would you rather have them rush it out or would you rather have them check double check um you know consider different layers to the onion if they're using a proxy if it's upgradable that's another layer of risk you have to accept as a user but you don't know what's going on behind the scenes they may have a bug Bounty that's active which is great A bunch of audits all fantastic but then you know let's let's dime out arbitrum they have a big bug Bounty and then you find a bug they don't pay out so you're incentivizing black hats instead of white hats do users know that users need to see that users need to know everything about the security of the protocol so all that needs to be very transparent the more transparent these Protocols are the better off they're going to do with attracting capital and hopefully gaining market share speaking of market share I kind of like bury the lead with one of my other questions talking about like whether this is going to be a Winner Takes all space but there are a lot of teams like polygons polygon ZK sync matter Labs scroll consensus and there's also a bunch of I mean there's others um not to forget anybody but there's a bunch of people launching these um I I wonder Sandy like what you think about the space with regards to will there be a place for all of these different softwares these different layer twos or will people eventually coalesce around one is that something your team has thought about um I think it's really hard to predict whether developers will coalesce because right now the number of ethereum deaf Community is super super small and so most projects can have this very high touch relationship with all of the the the row up players so rather than being a a you know a so just by nature of the space being so small it's really difficult to break down kind of like personal relationships and like direct investment relationships or grants relationships or whatever so so I think right now you will see like clusters of teams forming around the the row ups and and building on top of it I think at some point that there might be a kind of a um a point where the ecosystem has grown so large or one of the robs might have carved out a particular Niche that um that that a certain New pieces of the Lego can only exist on a particular roll-up but I think we're some time away from that yet um and and what you know when and how that will happen I think will depend somewhat on user adoption developer adoption and um yeah I think it's a it's a race that developers will will get to decide really now um Anthony um I think this might be our last question um I you you all made the choice that matter lab CK sync to open source your code a lot of these teams are doing that and it kind of presents a trade-off between making it faster for this technology to get commoditized available available to anybody but also um on security it might be a good thing might be a bad thing can you talk about it specifically with respect to security why is it a positive in your view for the community to be able to contribute see all of your code yeah for us um so we open source the entire system at our recent Milestone under a very permissive like dual MIT Apache license um and then I think it's just like a foregone conclusion for us that this was the choice that we had to make from the security perspective I mean just you know the complexities of these systems are really vast I think tools like the l2b risk analysis framework is really useful for users to be able to kind of understand where things are but this just you know it's it's a complex system with lots that can go wrong the more that we couldn't put in place to secure these systems the better the more eyes on the code the like higher the probability that an issue is found and again it comes back to buying down this early risk I think there are other valuable reasons to open source the code and it's for us you know we want to get to a point where the the network is we are one contributor of many and this is a trustless system and a trustless system doesn't work in a world where you have to you know if you don't have access to the source code so for us this was an inevitable step that we wanted to take we wanted to even take it sooner but you know be being cautious about risk being thoughtful about the right way to do it was uh yeah essentially we thought as soon as external developers are required to use the system this had to happen um awesome thanks Anthony thanks everybody and thanks for listening I know this was really dense but I hope you all took something away I thought this was fantastic thanks everyone thank you [Applause]