zkSync's Hyperchain Network Effect | Alex Gluchowski, Anthony Rose

Transcript

we want to give people an alternative that will actually work so if you compare the zika stack to the cosmos ecosystem the difference basically the difference between like all these similar Stacks is going to be in the way how the bridges work the bridges determine the properties of the ecosystem what's up everyone welcome back for a bonus episode this week we got a really special announcement for you which is the ZK stack the matter Labs team who built zksync era has now published their ZK stack which is a more of an interoperable modular type solution for building l2s and l3s based on ethereum so the whole idea kind of centers around

hyper chains and Hyper chains are just roll-up blockchains that have a broad design space so you can have a hyper chain that's a validium meaning it uses a centralized da provider so has a different set of security guarantees and it can like lives on a spectrum all the way over to like the complete other side which would be like a pure ZK roll-up that inherits the security of ethereum now those hyper chains can be l2s and settle down to ethereum or they can be l3s where a hyper chain would be like settling down to the L2 so for example maybe you're a game developer and you don't want any of the you know the crowded user traffic of D5 applications taking up some of that block space so you build your own three that maybe settles down to ZK sync error which is

another hyper chain so it kind of gives you this modular stack to build uh ethereum based Roll-Ups in and further to that it comes with an out of the box interoperability solution which is the being dubbed hyper Bridges and so having the same prover so using like a shared proofer technology in this stack allows this seamless and trustless bridging between different hyper chains so super exciting announcement that comes through where we have Alex and Anthony from the matter Labs teams coming on to really give the the lowdown of what all of that actually means and why it's important so super fun episode um but we got another couple announcements for you guys so I'll toss things over to you Sam yeah you guys are going to be super thankful for that uh

that intro Dan just gave you too because it's not gonna lie we kind of jumped right into the nitty-gritty of it all and it's a bit hard to keep it all straight so hopefully that helps you out but I did want to take a moment to uh shout out permissionless it's by far the most fun crypto event of the year went last year we had an absolute blast we definitely want all of you guys to come down and if you want to buy a ticket today and get 20 off you can use the code pods pods in all caps 20 to receive uh 20 off to permissionless tickets um so be sure to do that we will link to it in the show notes and then we also as always have a quick little Adam accelerator show for you all yeah I gotta mention it love our great sponsor

Adam accelerator and if you're a builder looking for a home in this space then you know where to go and the answer is the atom economic zone continued development over there you know on the podcast that released yesterday so this will be a Wednesday uh June 28th we we talked a ton about Duality which is a very exciting Development coming to the Adam economic zone it's really bringing this new era decks to the ecosystem on top of that you have IBC you have interchange security the list goes on and on and with the usdc coming through Noble in the next couple of weeks that's just a continued development that the the ecosystem gets to be excited about so if you're looking for a grant to your Builder uh or you're passionate about some piece of the ecosystem and you

think you can add value then be sure to reach out to the atom accelerator I'll put a link to their website in the uh in the show notes so be sure to check that out and they're giving grants on a rolling monthly basis of 10 000 to 1 million dollars so again be sure to check them out with the link in the show notes but but without further Ado we can jump straight into things with Alex and Anthony from matter Labs alrighty everyone welcome back we are joined today by Alex and Anthony from the matter Labs team to discuss an exciting announcement um I appreciate you guys coming on you know this has been a long time coming getting this out the door so I'm sure that there's a huge weight off your shoulders just to kind of get everything out there but real quickly I'd love to

to get the announcement from you so what is the big news um and what was released today maybe I'll toss it over to you Alex absolutely we're happy to thank you for having us uh so we announced the release of the ZK stack uh what's zika stack it's the the next step of the evolution of the kissing project we started out as a mission Focus project like deeply Mission driven we wanted to scale ethereum we want to scale public blockchains to get to mass production talks sorry at the mass adoption and we started with by focusing on the core technology first we built the first version of GK sync which is now known as I kissing Clyde it's specialized through a lot for payments then we made the the next uh huge step

in bringing the first ZK evm into production which is known as iziki sync era which is the first network uh which is the first block blockchain in our Network and now we're taking the code of ziki sync era and we're giving it over to the community this is something that we planned actually from from the beginning but now it's actually official we see we we unveiled the plans for um to be bigger than just one blockchain it like we're giving you a framework which you can use to build your own chains which all can be part of this big um interconnected ecosystem with shared

liquidity seamless interoperability between the chains uh fully trustlessly with minimal costs and this is something that that has this hyper skating property it can scale to accommodate any need uh that that will arise for for this emerging internal value that's roughly the idea of this step great I appreciate that intro and just to zoom out a little bit you guys also uh published your Manifesto of sorts on GitHub just a little bit ago it's called ZK Credo so I was hoping you guys could kind of dive into that why you felt the need to kind of release uh a vision of sorts to kind of align the community and what the core values are is something we we actually used internally for years not a release of

this Manifesto of the city as it was more a codification of that just putting them in a shape in in in some solid form that can be discussed by the community that we can use strict definitions for we can formalize the North Star the criteria of how we achieve the mission but we we certainly understood them all these years as we were building things we were building the first version the second version of the casing protocol we were Guided by those principles implicitly now we just wanted to make them explicit we the it's it's the first draft it's open for the community to comment to make PRS on GitHub we want to formalize it collect our feedback uh and kind of come to consensus of what this

ethical framework is for for like for basically for all uh ZK um powered Network because it's very genetic it's not specific to ezek it it outlines what we believe are the properties of this hyperscalable networks that that must be implemented in order for us to to fulfill the mission of getting to the massive ocean maybe you still have one thing there as well I think at least internally this has been talex's Point like a framework or a set of lenses by which we think through every decision we're making on the technical side because all of the technical work is sort of uh in support of a mission and in support of a vision for how you know the

future could look and as we're at this point now with ZK sync where we're you know this inflection point where we want the community to be involved we want the community to start driving things in a way that it's not just matalabs and it really opens up and I think this is where we are obviously with the ZK stat it's really important that these principles are like foundational to the way that you know that this work happens the technical work is in support of something and this vision is something that we wanted to socialize our perspective and start to work with the community to refine to hone to discuss and yeah this inflection point I think a lot of these things kind of coming together is because of this is where we are on the technical side and we need to do it in service of the broader Mission

that's awesome I I love how you guys have kind of like laid down these these base uh principles and ideals that you're kind of using to build out your vision but I wanted to kind of dive right into the ZK stack now and really start unpacking like what this is and who it's for so if we look at the L2 landscape today no arbitrim has orbital optimism has the op stack um how's the ZK stack different and what are the primary benefits of using ZK over the optimistic designs sure I can maybe start with a quick outline of what it is and then we can talk about um why you might consider it and some of the advantages so to um to start with what it is so the ZK stack so kind of at a glance is you can argue like the generalization

of the code base that we built and been developing for era but starting to also you know uh give the toolkit the template for what we're calling like hyper chains and this sort of uh vision for hyperscale this could be built on this technology so in scope sort of from the technical perspective for the ZK stack are the core components that we have developed for era there will be more coming as we kind of make the system more configurable more modular and so on but it would include things like the sequencer the circuits the prover um the system contracts bridging interfaces so it's definitely sort of the core components that you would need to deploy if you wanted to deploy a hyper chainer version of a system that

looks a lot like error it will also include things like the tooling around that so the compiler sdks for configuring things clis so essentially it's the set of things that you would need if you were a development team to be able to deploy a version of this system that looks like era today but over time could be more uh flexible and designed in different ways to support different use cases so uh yeah it's this free fully open source piece of code um composable design configurable design um and essentially this is what the ZK stack is uh Alex yeah not sure if you have anything to add to that but this is at least what exists today and then we can talk more about

obviously where we're going with the with the system uh yes and I I want to answer the second part of this question why is it get stuck so yes you're right there are a couple of things you can use today to build your own chains there are optimistic roll ups there are things that even are not non-rollabs that you could build to just deploy a chain which is like separate ethereum or here it's some security um the problem with those approaches is that they use this order Technologies if you build your own stack if you if you build a chain that is based on ethereum like let's say you build an optimistic roller um it's going to be very hard for you to transition to this newer Technologies you can do this potentially

but then you will not be able to Leverage the this kind of what we call super powers of the ZK because you need certain design decisions must be taken from the start if you don't put them in from the start it's really really hard to change so we bring like this this is uh happening with every technological shift in the past you know you go from from Zappa links to airplanes you cannot just replace the engine you need to to build like to change the entire infrastructure you need to change the the hull of the aircraft you need to to do different aerodynamics and so on um with specifically with ZK there are properties of of the zero of zero

knowledge proofs like sensor knowledge proofs such as succinctness that allows you to compress data uh availability that it allows you to use different approaches like when you optimize for example your account abstraction design for optimistic Roll-Ups or physique Roll-Ups you will end up with two very different designs and if you stick like imagine you start building you open your chain you invite applications to start building on it you have a set of standards that they have to start adhering to and then the ecosystem forums around that you cannot really change this anymore look at ethereum look at self-destruct look at the AP 4844 why do we have AAP

for it for four because we cannot change ethereum at the at this core protocol level easily it's like there were attempts to build e884844 in a way that that would natively support account abstraction for all accounts but they were rejected because this would break one or the other invariant one of the other conventions that people are depending on and this this would kind of like remove this backwards compatibility with backwards compatibility is a cost you have to carry it over over like very long time so if you don't build certain you know you don't have to do everything there are certain things that you can change you can always extend the chain if you go for for a specific design like

you can go for evm compatible design and later you can add other languages which our bedroom is doing which we are doing with our llvm compiler so you will be able to write smart contracts in the rust for example so this is a strict extension it does not affect anything that was previously deployed that is unproblematic you can always do it on all chains but changing the fundamentals are hard and there are really a few things that specifically about around um uh call date and data availability that you can't really change after you deployed this version interesting okay so if I am a developer um looking to build with the ZK stack what are what are really my options like

and what are the the security trade-offs of the different options you know it's kind of hard to keep it all all straight you got ZK Porter accounts you have hyper chains and then you have the marketing lingo L3 that everyone tosses around pretty casually like can you kind of clear the air around the different architectures that are actually available through the ZK stack so ZK stack is a modular framework you can build different you can customize different aspects of your chain you can start with all the defaults just copying the configuration of ZK sync era or you can say I want this component to look differently so let's walk through the components that you can customize the first is the um the ear sequencer you can opt into a

centralized sequencer which which is easier to maintain initially but you probably don't want to stick to this option unless you are you need the centralized sequencer you're an Enterprise a bank a maybe a gaming company that really does not need to decentralize the sequencer but we expect most chains to decentralize the sequencer in a way that like for example you're on a consensus in layer 2 that will sequence transactions so then you'll need the validators you will need to stick some token maybe to to decentralize it permissionlessly and so on so you will be able to choose all of that parameters which consensus algorithm you want to use which how do you secure how like what token do you want to use there and so on

the second option is uh or configuration is data availability this is this is really really important this is a huge topic uh by default sync era is a ZK roll up and we encourage everyone to build ZK Roll-Ups for and promoting roll ups first and foremost because he can roll up is an architecture in which you publish data availability through the ethereum network so you kind of you you rely on on ethereum Slayer one as your data availability layer um and you do it in a way that is basically giving you 100 of the ethereum security you do not rely on ethereum validators you rely on the entire

network the validators do not have any power to withhold data from you because it you kind of you depend on all the full nodes of ethereum so this is by far the best and most secure option but and the most centralized one but it comes with the price because all the roll ups on ethereum optimistic and zero apps alike share the same data bandwidth the same limited block space which you can use utilize for your data so the it will it's currently pretty limited uh it will be extended after proto-dunk sharding and then with tank sharding it it will go much much bigger and we will be able to accommodate potentially um thousands of transactions per second

across all the roll ups but we still need some path to go there and meanwhile it's gonna it might be quite expensive once all the Roll-Ups get a lot of traction and you really bring millions of users onto them um the data availability will become a bottleneck so like on this path forward towards the the you know ethereum getting full sharding on on da um you need to consider other options and the the Alternatives could be um a validium where one or multiple parties hold the data availability for for a given chain the state transitions are still secured by ethereum but the data availability is is then managed by

these parties um it gives you an upside of privacy so this party could be a bank and they might not want to disclose all of the transactions that happen on the chain on this specific chain while still guaranteeing to the users that the all the rules are preserved you know you don't trust the bank to not spend your money it's still enforced by ethereum and all the smart contract rules at first um but it's obviously uh like they control the data and they can just shut down the data for everyone burning the entire chain which is a bit sub-optimal the other option is ZK Porter where you can um it's essentially the same architecture

it's still a validium but the data availability is secured by um the uh by the users who hold like by talking holders putting something at stake they stake some token and they guarantee data availability from there now depending on what token you use you get different properties but roughly like if you use some stable token it would be suicidal for them to burn all of the stake you know so like the the risks are significantly lower than the pure validium um so you can you as a user can choose like do you want to sell for that do you want to set do you want to go for full

ZK roll up and in the ziki sync architecture because it's designed like this from the beginning you can have what what is called official Evolution you can have a choice which account you want to use within the same chart of the system and the uh so it's done in a way where roll up accounts and GK border accounts can seamlessly interact with each other synchronously within a single transaction what this practically means is ZK Porter users will be able to interact let's say with with a uni swap or with uh balancer with curve but all the D5 particles on the ZK roll-up side where the whales hold all of their liquidity

very very cheaply because they don't have to pay like the data availability is going to be amortized so this is one very interesting flexible high production I think to a first approximation these are going to be some of the most interesting areas I think there will be uh in the fullness of time other pieces that could be configured we can talk about decentralization of the prover or centralization of the proof of but yeah it's a first approximation I think data availability and the options around the sequencer are going to be the most interesting because it is where you probably are able to customize the stack the deepest at least initially yeah and I think on top of that you can just customize the various you know like you get you could put a different

restrictions on this tag for example you can say I want to launch this chain which will only Host this one application I don't want any you know any D5 apps there that will clutter the uh the sequencer space with something irrelevant it's just a chain for this specific game so we only deploy this one contract on this chain and then you interact within the balance of this contract or you can only deploy contracts of this type see you can you can like you are you are you are for freedom to shape all aspects of the experience on on the Chain depending on what you need and and on top of that you you can also choose different privacy options as I said like if you if you have a validium

you get privacy out of the box at the expense of decentralization and full ethereum security but you could also build a chain that is private by default that only allows private transactions you like you deploy privacy protocols something like ad stack or um like there are multiple other different options espresso Labs is working on other guys um I forgot the name of the protocol but like there are multiple different protocols now in development that you can deploy and you can say in on this chain all the transactions must be transactions from this protocol and then you still remain in the ecosystem that shares the liquidity so like when we say

uh hyper chains it's not really an option everything you launch is by definition called hyper chain if you if you build something with a zk6 or ZK stack it's basically a hyper chain it can be an isolated hyper chain or it can be hyper chain plugged into this network uh and this is really really interesting this is the key most important feature of the of the ZK step so like you have to imagine it like this you have different chains you have the key sync error someone launches their own like let's say let's imagine Union swap would launch their own uni chain as a separate hyper chain in visig network so it's it's fully separate it has its own sequencer it's a ZK are all

up so it's inherit security from ethereum uh now you have some funds in the wallet on the uh on on the kissing era and you want to interact with unius opponents on chain the way it will work for you from the user perspective is essentially the same as if the the unusual protocol was deployed on the keysync era you will go to the website to you know to the depth application whatever you use you connect your wallet you choose transaction parameters you you click initiate you do one click say like I authorize this transaction what will happen is the transaction will then go will Bridge from the kissing era over a hyper bridge to the uni chain

will execute will reach the smart contract there will execute swap some tokens and then it will send you the results back over a hyperbridge to the casing error all of that will happen asynchronously but atomically so like all of these transactions will be scheduled and they cannot be stopped they they will have to like or like you you will be able to enforce them as long as the chains remain uh live the transaction will fully come through and if this if they stop then subject to the security uh liveness assumptions you will be able to process it there but essentially for you as a user you just wait a couple of minutes and the funds come back and this is the experience you

get today with centralized exchanges I mean the the experience is even worse if you want to trade on a coinbase or Kraken or or binance you first have to bridge funds there wait 10 minutes until they arrive then you make the Swap and then you send funds back and then you wait a couple of minutes till you're at but now you have to do like three different transactions whereas with Hyper Chains It's one transaction you don't have any trust assumptions you don't have any additional Capital requirements and the ux is completely seamless and the reason it works is that that like all the hyper chains that want to be part of this network will have to reuse a single Bridge hat on layer one

so they they will all like you don't deploy a separate instance completely separate from all the other chains you will deploy it on a special like smart contract that um will keep the states and and the balances for all of these chains and we'll offer an option for shared prover it's going to be fully optional so like all the all the hyper chains at all times whether they are l2s or or l3s you have a choice for like how far up the stack you want to go have full sovereignty they do not depend on each other they do not depend on Sikhism era they only depend on ethereum so this contract even though it's shared it's fully

independent so like if if you don't want to use your shirt Brewer with someone else you can always generate your own proofs and you can settle them on ethereum this will work it's just going to be less efficient than if multiple chains get together and compress the proofs and this can be protocol for this how to do it easily and with with high alignments you basically just accumulate proofs and then anytime anyone can compress them and it's going to be very cheap computationally to produce the this final proofs that you settle in ethereum uh but if you don't like the system you can always kind of exit the right to exit is one of the core fundamental properties declared by the ZK credit and and we're gonna honor it at you know in

in at all times in any conditions like we will build protocols that allow you to go away with your own chain or go away from any chain if you don't like whatever happens on the Chain even if it's like a mass movement the mass exit of many users okay that I want to dive a little deeper on that one bit there I think that's really really exciting that you can have two separate hyper chains that have composability between the two chains and so I want to dive into exactly how that gets enabled so um it sounds like there is a you have to opt into the shared prover which is a contract that lives on ethereum L1 and then that would allow two like L2 hyper chains to interact

um so we think about the architect uh the architecture right so there'll be l2s that can speak to this contract and then each of those l2s could theoretically have l3s built on top of them so if I was trying to transfer funds let's just say uh make a transaction between two l3s that are both opted into the shared prover is that possible as well or is it only the output transactions between the l2s themselves you can make a transaction you can transact from any address on any hyper chain in the network whether it's an O2 L3 L5 it doesn't matter to any other and it's going to be very very fast like the latency of the

of this transaction is going to be like a few minutes it like it starts with probably like something like 15 minutes and then it's going to go down to one minute and maybe even under one minute because the proofs will be generated like very very fast recursively like we're building the tree of recursive proofs no matter how large your block it's all going to be proven in parallel and it will take just a few minutes with with the modern GPU Pros that we have maybe just to kind of give some intuition about how we're thinking about this design and why we're thinking about you know to your question about you know can 2l3s interact I would argue that for us to get to the point where we're talking about you know billions of users being

able to interact with applications that are built on top of a system like this they built on top of a system like ethereum we need to be able to abstract away that sort of question to a degree but in the same sense like the obvious analogy for me is email I don't have to worry about where if I want to send you an email where you know email hosting situation like how the infrastructure is configured like none of that matters because to the user the thing that we want to do is to be able to send information from you know from me to you in this example what we're thinking about is actually how do you get to something that feels like email but for sending value and you can think about some future iteration of something like ens Unstoppable domain Unstoppable domains where you you could imagine

having like an ens like address that you can speak to like you know Dan Smith at X and this protocol can start to provide a user experience where it doesn't matter whether thing is deployed you can build a composable experience in between you know wallet hosted on some layer five some Layer Two it really is kind of agnostic to the situation because the hyper bridging infrastructure provides connectivity in a way that the user doesn't need to think about it and to First approximation application developers shouldn't really need to think about it right building to an interface an interface can look constant independent whether it's an L2 or you know whatever configuration of the ZK stat interesting okay so something that um you guys

talked about that's from The Credo as well as uh just a core value of of what you guys hold is like sovereignty and the ability the ability to exit I get that from the perspective of like the individual chain but if I'm a user on an L3 and I want to return to the L1 and something's going on with era like how exactly can you force include a transaction to the one like what really is the security assumption from the user of the like the user or the perspective of the user um like how hard would it be to actually get your assets back to layer 1.

um so the we have to consider Every Chain separately because it every hyper Gene will have its own set of Traders like if it's a validium for example they could freeze the data any there is nothing you can do but you can try to do something you can request and exit and then if your request is not respected then the entire chain has to hold for uh easyk sync error specifically it's a first and foremost Ezekiel roll-up most accounts we encourage all the users who can afford it to have an account on this key role and for ziki roll up we will have something called a mechanism called the priority queue so you can always go on layer 1 and submit your transaction there you don't have to

provide or generate any zero knowledge Pros you just submit a basically self sequence you sequence your own transaction there and it's uh it is supposed to be included in the next plot in next like block within some some time frame some some deadline by the validators of the casing error if it's not included the protocol will hold and enter the priority mode where anyone can sequence transactions like whatever is in the priority queue has to be processed the protocol Will Will just not work until the priority queue is emptied and since the priority queue will have a kind of predefined sequence of transactions it's

going to be any easy for anyone to generate these blocks and produce the proofs without any erase conditions because the transaction sequence is predefined there is no race you know you know exactly what's going to go in which block so you can you can build that and um when you generate the proofs you can do it in small chunks and then like if no one else generated the block you just submit the this block a new collect the fees that the users who who are requesting transactions to exit will have to put in there so it's kind of a game theoretically stable system it's not that someone needs to do selfless work to make it work you know it's just like it will stop and everyone anyone can can do the

work for being compensated for this work so the the tricky part is if you as a user has to have to submit a single transaction on layer 1 to exit it might be too expensive for you because we expect layer 1 at some point might it might become very expensive just like it was in the past it might cost you like hundred dollars one thousand dollars to submit a single transaction so this is this is like we we kind of we we realize that this is a problem and the solution to this is that the design of the priority queue is going to be extended so that the users can get together and like submit a collective claim so basically doing like starting sequencing

transactions together so imagine a group of users is being censored they they get together like there is a leader someone organizes that and says like censorship is happening so we cannot trust this chain anymore and we all have a moral obligation to exit like we the minority and everyone who supports us and we believe there should be a broader movement like more people who support the uh you know who embrace the values of the ZK credit I have to say this is not a normal situation no one should be censor attention even if one one a person is standard we have to all exit so they get together and someone deploys another instance another hyper chain which

that will not censor this users or like we will not behave only actually the censorship should be resolved at the protocol level but like let's imagine that the chain tries to change this and introduce some form of censorship so like before before this time the users get together and say like we we launched this new instance and then we all want together to exit so like you basically start collecting many transactions together using the front end of the other chain saying like you as a user you just have to sign this this transaction then all the signatures are getting together and you submit a big batch by you I mean the the whoever is organizing this this movement

and then you get a lot of users going from hyper TNA to hyper chain B not through layer 1 but through the mechanism of hyper chains uh sorry hyper Bridges which is going to be very very cheap great okay that's that's super helpful and then Anthony you alluded to the use of account abstraction and that's obviously been a a core focal point of ZK sync um era uh and you also reference in the ZK stack blog post that you released this morning uh gasless call data um could you kind of elaborate on that and and what it enables in the future yeah so in terms of account obstruction this is definitely yeah one of the sort of key features that we would highlight when we're thinking about scale scale isn't just infrastructure scale is the user

experience so yeah for us this is a big part of uh of what it looks like for us to actually be successful as we imagine the future here um with respect to gases transactions maybe Alex is a good one for you to to pick up the ideas with Gallant abstraction uh create like design that we use for education error we rely on the fact that call data comes essentially for free because in our design the state we only publish the status the final the outcomes of the transaction the the the effects of this transaction on the state so you can include any number of inputs you can do a lot of parameters and for

these parameters you will not have to tap into ethereum's Data availability which is expensive you only need to process them uh computationally which is cheap because we're using very very efficient your knowledge proofs and very efficient GPU programs for them so the the like from from the Practical perspective they are free so like our Design leverages This fact you could put signatures that are coming from the biometric devices on your phone for example which is going to be much larger you can put a lot of parameters you can put a lot of um invariants into this transaction you can put a lot more safety for the users because you can say as a result of this transaction my account has to remain like this like we I only want to uh

allow modification of listening these tokens and I am only authorizing to spend this token up to this limit and so on you can put all these parameters in there uh and and the the resulting transaction is going to be as cheap as a simple transfer on ethereum yeah the way I think about the cut obstruction generally is that I think of it like a we've designed this or thought about this in a way where developers should have some freedom to customize their payment interface to a way that makes sense for them at scale right so account abstraction isn't necessarily one thing but you can think about okay I have a design in mind for my application whatever happens to be I want to subsidize I don't know the 10

the first 10 transactions of a specific user I want to pay their gas or you know maybe I uh some relationship with the Dow or for anyone who holds this specifics all about nft I want to make sure that transactions to this application are gasless forever so I think of the set of Tools around account obstruction of our set of tools to enable really good user experience the set of tools for development teams to be able to customize their payment interface and then related to what Alex was saying is like the cost of these transactions you can you can benefit from the implementation of State diffs such that you don't necessarily have uh transactions that look incredibly expensive as a function of the complexity of what developers are

choosing to do with them so is it fair to think of this architecture as a bit like like when I open my Chase mobile banking app for example I've got a checking account a savings account a brokerage account Etc so maybe I'd want my funds to rest on zksync era where it has strong security guarantees you know my savings account and then if I want to use uniswap maybe I have an exterior account that has five percent of my you know value there like is that kind of the right framework and then you're able to easily interchange between different accounts on different chains with different security assumptions this is typically how I would think about the split between say the roll-up account which I would argue is basically your equivalent of your savings account right so the roll-up account with all of the guarantees that we've spoken to with the

ability to maintain you know control of your assets from L1 this is essentially the highest security so this is the account that would be more expensive to a degree to maintain this account but it will come comes with you know security assumptions that are as strong as they could be this is where I would argue for most users most of your funds should be maintained and then the way I think about the porter account is more like your checking account right I want to do some cheap transactions I want to interact with the game I want to whatever it happens to be you don't have the full Security in the same way you know there is this um different approach to data availability that introduces slightly less secure uh situation with respect to the funds but

you benefit from that with orders of magnitude cheaper transaction fees so you can think about you know your individual risk tolerance you know some people might choose not to have a wardrobe account some people might choose not to have a roll-up account I would imagine that actually most people would have to your point some large majority of the uh activity like day-to-day activity from like a cheaper account like a porter style account but then the the savings account is is the role of account but they'll also clarify something you touched on in the question um the both roll up and Porter accounts can be part of the same hyper chain so the the this can be the part of ZK sync error on one single chain you have instant seamless synchronous connectivity between them

um the it it's not that you need to build a separate hyper chain to implement ZK Porter the way we think about the needs like who will need their own hyper chain is slightly different you build your own hyper chain if you need to control you customize certain aspects of it so it doesn't I don't see the much need like maybe like you know it will be the market the builders will decide but the generic chains are probably less of a candidate for for being a hyper chain it's more for application specific chains or you don't want to share the sequencer with with with with everyone else because if

you're sharing the sequencer you're probably just better off on a single chain which is going to be high capacity High throughput uh with roll up and Porter accounts giving users different levels of security and um and throughput Traders uh now but like Enterprise chains gaming chains app chains for maybe you want like you don't want a decentralized sequencer because it's too uh your latency of transactions is too low but instead you want like high frequency trading like ultra low confirmations for your transactions think something like dydfs they can have their own separate chain for just for this exchange um maybe social networks some specific

social networks that or like maybe even you know if you think of Reddit with 500 million active daily users they will likely need multiple hyper chains for each for for separate subreddits not just for the Reddit entirely you know like you might want they they might want to use like the Reddit hyper chain and then l3s for for all the different subreddits so this is how we think about it it's more of a customization and application specificity and and full control of what you're doing there and potentially also for privacy for banks Enterprises and so on okay so that landscape makes a lot of sense to me and one of the things I want to hit dive a little deeper on is the the state of the sequencer today so

um you know all these l2s have centralized sequencers but there's been serious talks towards you know shared sequencing or the idea of decentralizing the sequencer how do you guys think about what the next step is for decentralizing the sequencer um of ZK sync era and offering that to other change to opt into yeah I mean I can jump in with respect to what we're doing already for error and you can generally speak to the plans for the future so you know you can think of as we've spoken to like era is the first hyper chain in our opinion um but it's also True by definition that even in a world without HEPA change like the the philosophy behind what we're doing is such that the sequencer has to be decentralized but this is sort of a

non-negotiable piece for how we're thinking about the design for era so this is something that we've been working on how the engineering team actually working on for months at this stage and we're you know very close to actually having the decentralized version of the sequencer ready for public test net so this is something that from I'm just you know talking about era and then not even talking about the generalization through the ZK stat this is very very close to completion this is something we'll be doing in public very very soon um and again like critically important for us for a number of different reasons right but thinking about liveness of the chain right you need to get to a point where the system is decentralized to hit the reliability metrics that we're looking for is with respect to liveness it's um yeah it's been part of the era roadmap

wasn't obviously part of the alpha release for I think sensible reasons of a lot of hard problems to solve when you're building a system like this like we can sequence them in a sensible way but this is very close to completion and it will be part of the ZK step so for people that are choosing to work with the ZK stack they will have the option to implement a decentralized version of their system just along the lines of the way that era will work so um yeah the engineering work is very mature at the stage we haven't fully open sourced everything we're doing on this but we will do very soon and people will see a decentralized version of era on testnet very very soon and this is one area where I think you know personally just sort of interested for

people to think about you know modularization you know other people interested in building different consensus algorithms like when we think about ZK stack I think in the fullness of time or at least the way I think about it it'd be nice for the community to be able to contribute modules which aren't necessarily implementing things exactly in the way that we have implemented the mirror but providing some flexibility for different use cases so we will have I would argue like the first version of the decentralized sequencer available for people to run uh on their version of the ZK stack or obviously we'll be deploying as we decentralize era um but this is also an opportunity for Innovation you know creativity more modular options to be built into the stack itself and so when you think about

decentralizing the sequencer like what does that actually look like is that like creating an alternative validator set that is kind of you know acting similarly to something you'd see on the L1 where these uh validators are working together maybe they have something at risk or some token that's that's staked um to kind of like prove their honesty or like how do you think about actually decentralizing the sequencer yes so the idea would be that you have a validator L2 that are performing the role that we perform with the centralized sequencer today of you know ordering and processing the transactions we have um a design like I mentioned for what this looks like for era and we'll be talking about that a lot more in the coming months we

rolling this out and uh you can imagine yeah what this looks like the first simple version from an engineering perspective that we might even have on testnet something like a proof of authority Network where you basically say look we want to test the decentralized sequencer on a test net we're going to run end nodes and this just doesn't require proof of stake right it's a it's a test net we're actually more interested in testing the consensus testing the edge cases that come with decentralizing the sequencer over time as we take this to all mainnet the design will mature and we'll roll more pieces in but yeah we have a roadmap internally for how we're thinking about bringing this to production uh and it will look like you know an increasingly mature and

increasingly sophisticated uh uh consensus algorithm it's not enough for us to centralize the sequencer we also have to decentralize the prover which is a bit more challenging because uh you need to orchestrate a lot of work and like then merge the results of this work recursively in a relatively timely manner but this is doable and the key part of this is building the Brewer in a way that can run on the consumer Hardware we actually made a huge progress in this direction we will publish some really interesting news about this soon okay I see and I imagine uh you know it's harder for you guys to say but uh the DK sync token if there ever is one would be pretty integral in

decentralizing the prover the sequencer and then also securing the data of ZK Porter chains do I have that correct uh we will we will publish separate designs on this layer there are important aspects to take into account but like in general I can say that we don't have uh better mechanisms to decentralize permissionlessly other than the token at stake so you can infer things from here that that part's interesting to me though is like last time we spoke um you know we had a long long conversation on the idea of like the industry arriving at a standardized proving format so that you could like exactly like

have composability across a larger ecosystem um what how so that was you know a couple months ago now I'm curious here to get your ideas around are we closer to arriving at a common standard or will this be kind of like you know we'll have likely have separate ecosystems that are utilizing different um proving mechanisms and therefore can't totally interact with each other like what are your thoughts around all that we will have so like the the hyper genes are built around the idea of the common standard it's just a question of what this concern has to be so you you have several components here you have the this shared Bridge hat with this shared smart contract where hyper chains can be deployed on and then you need to

that for them to have certain common circuits that they trust from each other that the certain actions were performed correctly so it would be a challenge to find the minimum viable like protocol like minimum set of circuits that that are required there but the necessity to have this shared smart contract uh means that it's it's a little you know like um it requires you to pick an ecosystem in which you will be building your hyperscalability like you cannot be you cannot do hyperscalability across multiple

ecosystems it's you can trustlessly bridge between different Roll-Ups you can trustlessly bridge for example even between optimistic and ZK Roll-Ups that is possible but it's not going to be seamless if you bridge from it from an optimistic roll up to secure all up you you have to wait seven days for the native security from ethereum if you like if you if you um transfer if you bridge something from one Z key roll up to another zika roll up not using synthetic assets but actually like true bridging of real assets you will have to pay to ethereum for this transaction you will let you like you will have to pass this transaction for ethereum actually like transferring assets from one layer one contract to

another layer one contract in which case you don't have any benefit of the scale you know like you you still have to pay for a single ether or esc-20 or nft transfer on layer one it defeats all the purpose of scale like it's it's not hyper scalability it will not give you the seamless experience with like user on any channel interacting with any protocol in any other chain so I think we'll end up a situation where the users have to pick the secret systems and then this is why you have to pick the ecosystem wisely from from the beginning because it's going to be very challenging for you to change if you build today on a stack that is incompatible with the let's say ZK sync ecosystem then it will be like you

cannot migrate you will need to like abandon the old system and then build something on uh from scratch uh in in the hyper chain world so like yeah I hope this answers the question maybe just add one other quick thought as well I think there's some tension between the idea of uh reaching sort of more standardization more commonality today with also how quickly we're seeing Innovation right so when things are moving as quickly as they are my expectation I think our expiration internally is that sort of at least for the foreseeable future we are there is a lot more 10x 100x improvements to happen when it comes to the design of the

implementation of the proof systems lots of optimization that we're not ready for yet uh or at least like hasn't been implemented yet so lots of optimition that's still a low hanging fruit and also as you know research continues lots of new ideas that will I'm sure proliferate uh so yeah for us like when we're thinking about um like standardized proving share proving doing it inside the framework of the the ZK stack is really compelling because you get to uh move these things in a way that's consistent related and everybody can kind of benefit from the advantages and the implementations that are done in a in a shared way with the open source technology so I want to zoom out a little bit just to get your guys's take on one question so I I feel like it's undeniable that l2s have kind of taken a

page from the cosmos Playbook with like the app specific stuff and interoperability between an ecosystem of chains uh it's just roll apps versus app specific but then we saw dydx uh announce their commitment to the cosmos and that should be launching in the next couple months so I was just wanted to ask you guys is there uh anything you're watching closely on that move that would potentially change your ethereum-centric thesis if you set aside your your values I guess for decentralization and security for a moment so I I want to start with saying that this is not a coincidence that we're we're having very similar Paradigm because the original idea of Cosmos was to build the internet of blockchains and if you think about it like basically blockchains themselves

are just a continuation of the internet with blockchains what we're trying to build is the internet of value extending the internet with the ability to transfer and program value so all like the the analogies are invisible and they are going to be present in in all ecosystems like ethereum is the internet of roll-ups uh as you can think it's going to be the the network of hyper chains um the uh so like from this perspective it's it's understandable uh it's also understandable why dydx had to move the key word here is sovereignty they did not have Sovereign like they were not sovereign enough in the previous ecosystem in which they were incubated it was not

fully open source it is to my best knowledge still not fully open source it would not be um they did not have something like the priority queue so you could not enforce transactions to be exited unless the validators of your network agree to this and so on and they clearly needed more control and more decentralization and they did not have anything available back then other than the cosmos chains then Cosmos SDK temperament where you can just plug in your consensus and it's a modular framework where you can build stuff and for whatever reason they they were not happy with the optimistic uh Ultra stack Alternatives that that were available back then uh because you know like having vnck build in the first place puts you in a in a position where

like you don't like seven days delays and stuff like this so this is why we're building the ZK stack we want to give people an alternative that will actually work so if you compare the zika stack to the cosmos ecosystem the difference basically the difference between like all the similar Stacks is going to be in the way how the bridges work the bridges determine the properties of the ecosystem if the bridges are trusted they are not different from extended multi-6 so you have like you introduce trust assumptions you cannot Bridge from one chain to the next and then from there to

the next to the next you can do this multiple hopes of trust because you're going to be accumulating trust assumptions severely it's not scalable it's not process it's not the spirit of blockchains as we know them the decentralized potential vision with Hyper genes we like the the thing that makes hyper chains hyper chains is hyper Bridges so this name is derived from the internet idea of hyperlinks which take you from any page on the internet to any other page in exactly one click and zero trust assumptions because if if the link is https then you know for sure that you're landing on the right page right like you

don't have to think about the architecture underneath all you need to know is like it's seamless cheap one click and trustless and this is what hyper hyperbridge is enable and we we've touched a little bit on the architecture on the on the aspects like how exactly this works um we encourage the the listeners to actually go into the into the docs and read the the posts and we we we did our best to expand it and we will have an A an amm let's say an MMA where uh we encourage people to ask questions and we're we're happy to engage in and try to provide more clarity there but with Hyper Bridges you rely on math

cryptography and ethereum and nothing else on ethereum as a whole set of the the entire set of ethereum validators with Hyper with with Cosmos chains you rely on Cosmos validators you have you have to trust some group of people this is the key difference that determines everything else that's fantastic I just I want to give a let's see I want to try to like sum this up and tell me if it you know this is like the inaccurate way to kind of explain what the ZK stack uh really is so the ZK stack gives you the ability to create a network of blockchains that are called hyper chains and they can take the form of either an L2 or an L3 depending on what the you know the use case particularly is and the actual design of the hyper chain can

vary you can use you know a validium that maybe has different security guarantees because it uses uh some centralized da layer or you could you know build the opposite end of this spectrum which would be like a pure ZK row up that posts all of its data down to the L1 so there's like a design space within the hyper chain itself as well as like kind of where it's situated in the stack again being an L2 or an L3 and then all of these hyper genes have native communication between them because of the shared prover system that enables the hyper bridges that you just spoke to is that like a good way to kind of sum up what the design space of uh the ZK stack really is that was an amazing summary it's extremely accurate okay perfect I love that all right so

this kind of just gives you this full interoperability space to to really kind of create into and I just want to have one more question for you of like what do you think is the you know is have you have you talked to any teams that are like excited to come build out their own hyper chain and like what's the the leading kind of like design choice they don't have to like speak to exactly who it is but rather like what they're building and why they think a hyper chain is the right solution for them yeah I can jump in so we've got uh some really exciting uh early Partners um I think with respect to announcing specific names I think I I will leave it for them to make their own announcements them so many will be coming soon the choice of Partners early on was not

accidental so one of the things that we wanted to do was start to sort of sample the possible landscape for different use cases you know for example in a world where you'd picked three different banks probably the solutions that they would have chosen would look somewhat consistent so we've definitely got a cross-section of partners for doing different things maybe surprisingly maybe not that one of the big early use cases that people have wanted to explore was what a validium would be like so we want to be able to deploy an instance of the ZK stack but for whatever reason we want to keep some of the state private and there are different reasons that different partners have got for you know wanting to make that design Choice um but yeah what we'll see in the coming months is we will see uh progress in public from I think of the order of

four or five key partners that are building towards uh you know their own particular solution with the ZK stat but definitely in terms of some of the early use cases they want to be able to have you know interoperability with the broader ecosystem they want to be able to interact with the correctly neutral platform that I think is ethereum but for whatever reason and there are different reasons behind this they want to like keep some of their State uh or yeah you know have different choices with respective data availability such that not everything is fully public so this doesn't look consistent partner by partner they have different reasons for doing so many different design choices but this is one of the interesting areas that we've seen explored with the first few people that we've been you know sort of privately um thinking through some of this before

being ready to do it as publicly as we are now and then the last question for you guys you've already been so generous with your time but just a real quick one so in your blog post you mentioned being able to use external da layers for data availability Services obviously so would you lose some of the the interoperability benefits if you would choose maybe like a Celestia or eigen da to post your data to as a hyper chain not at all you will just they will determine the security properties of your hyper chain but the beauty of it is as soon as you move funds from one hyper chain to the to the next the original hyper chain doesn't matter for you this is not the case for Cosmos but this is the case for us like if even if the original chain crashes collapses

the data availability is not working there you're you're safe because you just moved it to a to some secure roll up um so yeah uh it's it's the choice it's Sovereign choice of of each participant does not affect anyone else interesting all right well thank you guys again so much for coming on and being so generous with your time we love getting to talk to you too every uh three to six months so we'll have to do it again but I'll toss it over to Alex maybe first then Anthony we can go to you if you guys just want to share where you can learn more about zkasync what you're building and maybe where to find you on Twitter well we are on Twitter under ZK sync and we publish all updates there uh we encourage you guys to take a look at our code base and and consider contributing

or applying to join our team to help us build uh scalable blockchains and thank you for having us it was a fun conversation loved it yeah maybe just a Vibe we would love really feedback on the ZK Credo you know comment we've got everything open in public on GitHub now we would love for some discussion with the community for anybody who's interested in building or thinking through solutions for the ZK stat don't hesitate to reach out we'd love to chat I would love to discuss small as the system evolves awesome take it easy guys talk to you next time [Music]