The rise of Appchains: from L2s to Rollup Clusters by Alex Gluchowski | Devcon SEA

[Music] hello everyone my name is Alex I'm the founder of ZK sync and Co of matter laabs and today I'm going to talk about the app chains uh and how rollup clusters work what they are and and what implications they have and uh I will start with uh the uh you know it's probably obvious rollup Centric cow map has led to transformation of the ethereum's original vision of the world computer into the internet of chains which is not a coincidence that the this is like we're in in blockchain web 3 you we're kind of following the evolution of computing in general and the evolution of the internet is the third wave where we're putting value and putting valuable State and Global cooperation to the ultimate degree on on the internet uh on on chain and uh the um like what what what what what what it is going to lead to is that the apps will also transform uh just like the applications on the internet got their own servers and got their own functionality moving from shared collocated uh environments uh the same thing is going to happen with app chains uh with with with applications on ethereum uh there are uh many reasons for this but we like basically we're going to go from a world uh of every application is deploying on a separate chain uh on on like on on all of the chains to a world where you can deploy in one chain it might be a chain you fully control as an application and then all the other chains are interacting together and have access to to what you're doing and we see uh a lot of interest for this topic from the app Builders uh because obviously developer experience of deploying many chains Is Not Great uh but more importantly because you can customize your uh application and you can offer functions that are not possible on uh on a uniform like one size fit all environment uh and also very importantly you have the full ownership of what's happening there you can control the access rights you can control how you hand Le uh different policies and then you can control the value flow of the application to a much higher degree for example you can have validators who are receiving the the fees uh certain other value capturing mechanisms and then delegating this to the Token holders to to the larger community of of this app so there are many like very very strong incentives uh and the main blocker why we have not seen this happening so far is the lack of native interal it it's not even the lack of infrastructure the infrastructure is there we have rollup as service providers you you see now hundreds of rollups being uh being built but many of them application specific kind of like in their infancy many of them generalize but the cost of running your own chain is approaching negligible thresholds and like you you basically get a lot of services everything is is coming out of the box available for you to use but the lack of native interrup is really preventing us to to live this Vision through uh fully and I want to give you an intuition why and then I want to walk you through the technical trade-offs of different approaches of how we can actually make this work so this talk is mostly for application Builders and chain Builders uh and those application Builders specifically who who want to uh who are considering doing their own app chain uh what is the F the perfect world like we whenever we we build a revolutionary technology the best approach is to imagine the Perfection the perfect end game and then reverse engineer from there and see what steps we need to follow to get there uh a perfect user experience in our opinion consists of three major pillars pillar number one is you want to have a single account just like you today on E on on on the internet net we got to a maturity where you have your email and it's basically controlling everything you're uh you're you're doing on on the internet all of your accounts uh uh and it's like really easy to connect like you basically have Gmail uh connect Apple connect one click unlocks everything we need to get to the same experience on ethereum your single wallet you don't have to maintain a pleora of Wallets on all different chains and manage their complexities it should be very very easy the second thing is from this one account you should be able to interact with any app on all of these chains that comprise the internet of chains that is today ethereum which means no manual bridging no manual switching of networks uh and the confirmations are F so the same user experiences you have on a single chain should happen cross multiple chains and finally there should be no overhead involved with this interactions when you interact when you can transact from one chain from your account one chain to to some application should not be thinking about like oh that's going to cost me some percentage of the capital or assets that I'm sending there because there is some bridging involved and you should not your security model should remain the same like if an app is deployed on a z rollup and it's IM mutable smart contract uh you can firmly count on it because ethereum gives you this hardness and uh enforces commitments and this should not be violated by some new intermediaries that are jumping in between and facilitating your briding right so those three things must be uh uh held intact and um there are basically two ways to get there um as you probably know from from the uh um product world uh we can try to come to a Perfection at ethereum wide level like have endless conversations think through go through like endless iterations and come with a perfect design and try to implement this which will probably take 10 years or we can go through a gradual path and deliver incremental value uh as we go and obviously you you can imagine which uh way I'm advocating for ethereum has always been pragmatic and embraced the the second approach so what would this second approach look like uh for uh for p ethereum inter that can enable the the rise of the app chains um the first level like the most basic lowest hanging fruit is to agree on the standards for interop across uh all rollups like the all rollups that are being deployed right now we cannot perfectly connect them but at least we can agree on the future way how we will be connecting them and then some definitions and this include chain registry it should not be a GitHub account where someone manually assigns chain IDs should be something permissionless and Open Cross chain specific addresses again like this is quite obvious like zerox something does not define your chain we've seen like millions of dollars being sent to wrong addresses on wrong chains simply because we did not think about this when we were designing the the uh address format uh in the early version you like in like five years ago when ethereum was in its nent state but now it's time to fix that so like again we we can use we can copy uh borrow some ideas from from the internet do something that very is very intuitive very easy to understand and is fully permissionless and it's stepping into the chain ID registry and so on and then we can Define the apis of how the contracts on different chains can interact with each other not because we can do it today immediately but because like it's it's a lot easier to commit to something and then build towards this future this is in my opinion not very contentious like we have conversations with different rollup Stacks everyone supports this ideas and this is happening like the conversations are happening I think very soon we'll a number of erc's Will crystallize that um Define the specifications and it's going to be a really really great first step the step number two is the rollup clusters why rollup clusters what is rollup clusters uh we cannot build this perfect interrupt World on ethereum today because we have a lot of Legacy like we we cannot just start and rewrite ethereum from scratch to support these things this goes back to like chain ID is embedded in transaction format chain address is not being supported uh like not the design is not there right so like it's hard to to change something like ethereum you you've seen Justin stock for like 5 years to to get some uh relatively Limited improval in the uh in the base layer one it's really hard but we can totally do it at layer twos the power of ethereum uh rollup Centric road map is that we have this permission this Innovation we are allowed to change things and deviate from this standard and we can just come up with this perfect world and say like you know like unburdened by what has been we're now building our own way in ZK sync we're building our own way like within like super chain eger uh Arbitron orbits uh in um uh uh chain groups and we can call them rollup clusters and what defines a rollup cluster is it's something that enables this perfect world of the ux that I was talking before within the boundaries of the cluster so it only applies to the chains inside this this one cluster and between the Clusters we'll have the same problems as we have today at this stage and we have the same Solutions like we can use external bridg briging we can go and Bridge through layer one if it's some significant amount of uh of assets but at least we can Sol it within the Clusters and there will be a limited number of clusters it it is not going to be hundreds just going to be like a handful and uh and then as the next stage one once we have have tried and figured out what works at the cluster level we can go back to layer one and say like okay here are the best practices we know how to build it it's been bottle tested let's now get something enshrined as a standard for Pon ethereum interop on layer one uh so how what what is the stage of current maturity of clusters and what we can do there and like how how to enable this now we' argue that cluster an interrup rollup cluster is defined by two key mechanisms uh you need both of these mechanisms the one is shared liquidity and the other is native message relay if you only have one not the other you will not get the full user experience that that I was describing that that we need to get to the EP chain uh centri Coral uh you practically have it already like with um uh message relay mechanism enabled by thirdparty bridges for example enables you to pass arbitrary messages but since you don't have shared liquidity between chains they only work with external sources of liquidity and this is why there are external costs and external risks associated with those third party Bridges so you also need the the uh uh uh the liquidity there now let's let's cons let's explore them each of them in in in detail and see what trade-offs we have and how we can actually build that uh shared liquidity um we have two approaches for this one is um each chain can maintain the liquidity locked into there like their tvl that is currently managed by a smart contract on ethereum the bridge head uh that is deployed in layer one we can keep them separate and then coordinate and if you imagine you have like op Manet has like 100 e total liquidity and then base has 100 liquidity and then you move all of this liquidity from op to base through the Native Messaging interop uh and you own it on your account you obviously cannot withdraw it from base right because there is not enough liquidity on the on the on this bridge contract uh so like you will then need to coordinate something more complicated like if you need to withdraw more than a single Bridge contract contains you will need to orchestrate and do multiple transactions and you will need to build like relatively complex orchestration framework but this is doable it just like adds more complexity but like that that is plausible path forward the alternative is to say you know what let's take let's take one contract let's build like a single store of Treasury for all of these chains that are participating in the cluster on layer one and then uh merge it together have some mechanism of uh um token accounting between the chains so we we know exactly how how many tokens are in each of the chains so they don't violate each other's security but then it makes it a lot easier to withdraw everything from a single place both are valid approaches not not that uh that contentious uh the native massaging is a lot more interesting this is actually where we will see um the largest Divergence in 2025 and uh the the biggest trade-offs being made uh what is native message lay you need to prove from one chain to another that something happened on the origin chain because imagine you are like you have separate sequencers you have you want to bridge funds you want to transact from chain a to chain B um you're initiating this message on chain a chainb does not know anything about this their validators don't know their sequencer doesn't know they need to decide that like the I'm going to include a transaction that modifies my state that attests that something happened on GNA uh and you need to figure out like at what moment can I include this when can I trust the the the source chain and again you have two two different approaches the optimistic approach well I mean like you have three approaches approach zero is you just trust whoever is sending you this message this is basically what we have today with third party Bridges uh this is like relatively similar to how side chains pass messages to each other and how arbitrum orbit fast withdrawal feature works you just have to trust them right like C like certain chain okay that uh that is one option but we're talking about ethereum we want to derive security from layer one we want to preserve the security model of uh of the rollups we want basically all transactions to be verified by ethereum um in this case if your cluster is optimistic all chains are optimistic cups then you can build a n native interrup message passing mechanism but that will mean that every node of every rollup in this cluster will have to very y all transactions on all other chains of the Clusters so like not only the validators not only the sequencers every single full node and remember in optimistic cups You're supposed to run your full node uh to to make sure that you can uh enact fraud proofs to to run your own uh like you know to be able to to see that finalities happened at least subjectively on chain uh and that means that you're basically concatenating all of the rollups in one giant sharded system it's not really like separating them it's it's like you you're adding more and more and all of that needs to run on a single Noe with the ZK cluster approach you can do it differently each of the chains has to generate the validity proof the ZK proofs of uh each of its blocks you can then recursively aggregate them together you can take the state of the latest uh block of of these chains and all cers will aggregate them get a single root hash put it on ethereum as a settlement layer and then each of these chains so like each chain is doing like its own piece of work not caring about everyone else and then in order to trust a message coming from from some chain participating in this cluster all you have to do is to check the root hash of the aggregated state and it's going to be enough for you to check okay some event happened fully trustless relying p on pure math and not on any game theoretical or like cryptoeconomic mechanisms uh and that make that leads to like a really interesting Divergence of properties uh so with optimistic clusters all of the operators that can be allowed on the cluster are essentially trusted it's kind of this Insider group you cannot allow permissionless participation you cannot let everyone there you will have like five chains and then you to get the sixth one you need the permission from all five because all of them and all of their users will have to run the full note of that new chain and this continues like it it gets really hard to expand whereas in the ziki approach you can make it fully permissionless anyone can join they cannot do any harm because these your knowledge proofs is validating everything that's happening on their change uh and the second color is that the optimistic uh approach will be like limited in in its total capacity because you still need to make sure that the full node can be run on consumer Hardware uh as opposed to the ZK which is like fully uncapped because this Merkle tree this aggregation we can just keep adding chains to this uh uh thing and you know there are no inherent limits on why where where we should stop uh similarly with optimistic approach you can only rely on ethereum data availability you can only rollups in this cluster if you allow one non rollup one optimium the entire thing then der like becomes um an optimium from the security perspective like your security model is downgrading to the weakest link in the entire thing because your full Noe will not be able to attest what happened on some chain where data is not available publicly through ethereum whereas with the ZK cluster the chains participating can use custom data availability Solutions like Celestia igen layer whatever you you you choose as a as a as a builder and then finally oops uh optimistic approach basically requires uniform architecture because everyone has to fit into this like um into something that can be run on a single Noe by all participants whereas with ZK everyone can do their custom design manage their policies in whatever they would they want want Implement custom functions Implement any sequencer centralized decentralized what they want uh but the the this is becoming reality like we will see the first optimistic and ZK clusters uh going live optimistic are going to be limited ZK are probably going to we're going to see more chains participating in the interop uh and I'm certain that the next year is going to become the year of the app chains thank you happy today question all right let's hear it for Alex ladies and gentlemen very engaging presentation some very very good questions are coming in as well Alex now you can vote for the favorite questions let's look at the one with four votes at the top more app chain implies less decentralization as there is no incentive to run the full L2 nodes how do you mitigate this quite the opposite more app chains means more decentralization because you can have thousands of completely different chains run by different communities run by different uh you like some some of them will be corporate chains institutional chains with privacy with their own things some of them will be run by decentralized communities with very very different approaches to how these decentralized mechanisms work not feeding everyone into the same basically like a few oligarchic builders that produce all of the blocks for everyone like this is the only way to actually keep ethereum fully truly decentralized and keep it growing in a decentralized manner very good more CH good all right next question with six votes we're fighting with two questions there who is working on standardizing interrup oh excuse me went to the where did they um we have a group between different l2s the leading L2 stacks and uh we're making quite some progress there I think by the end of the year we'll have this this RC standards uh kind of well spelled out excellent go the top one what do you think about ERC 7802 by Wonderland Unis optimism about Bridge agnostic cross chain token interface it's a nudge we just uh uh you know posted the uh a tweet on support for the standard because it's yeah obviously that that's one great example of how things can work at this stage one of coordination excellent lots of questions getting voted up now this one with eight when stage one for ZK sync era it's more more most likely going to be in q1 next year it's the the next thing on the priority it's very very important for us Z has always been committed to like very deeply gone Cypher Punk values and be a pioneer of that and the only thing missing is the priority Q everything else is is in place for but like it's almost stage one today with the missing of this one component which is going to be finished so very very close for those of you who are waiting in anticipation q1 next year look out for it six votes at the top Security First do you agree that l2s and app chains increases throughput but don't reduce latency compared to L1 um so the latency of this approach is going to be like the hard latency of fully trust trustless interop with Native message uh with Native um asset bridging will be determined by the latency of proof generation the latency of proof generation is going down massively because it's a fully paralyzable thing uh in in in in the design of the new uh proof system the buum 2.0 the the new uh buam virtual machine that Z casn is having it's something like on the order of minutes and then it's it's coming down to seconds and I'm sure we will have um uh full uh uh like close to real time proving in the next couple of years until then we can do something interesting like we can use um lesser less secure proofs for example te sgx proofs to make the message passing faster and the chains who willing to accept those proofs for a short period of time under the risk of reorg and like this is important only reor of this like last one minute uh not any other security violation they will be able to enable practically um instantaneous uh interrupt like under like with one second latency because the most blocks in the in ZK St specifically are going to have one one second all right 5050 seconds let's do the last question at the top how is it different from the polygon egg layer uh it's very similar in design I like it it just like I I I think it's more mature we have the shared Bridge uh live today with three chains live ziki syera Kronos zero and it doesn't of others launching on this uh on this sh bridge and the interop uh is becoming production ready by the end of this year and then it has to pass the audit and governance I'm I'm pretty sure it's coming like early next year in full integration uh yeah all right that's all the time we have I think for today ladies and Gentlemen let's give Alex a big big Round of Applause well done well done