See all 0xResearch transcripts on Applepodcasts

We want to give people an alternative that will actually work. So if you compare the ZK stack to the Cosmos ecosystem, the difference, basically the difference between all the 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've got a really special announcement for you, which is the ZK Stack. The Matterlabs team who built ZK Sync 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 hyperchains.

And hyperchains are just roll-up blockchains that have a broad design space. So you can have a hyperchain that's a Validium, meaning it uses a centralized DA provider, so it has a different set of security guarantees. And it lives on a spectrum all the way over to the complete other side, which would be like a pure ZK roll-up that inherits the security of Ethereum. Now those hyperchains can be L2s and settle down to Ethereum or they can be L3s where a hyperchain 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 crowded user traffic of DeFi applications taking up some of that block space.

So you build your own L3, and maybe it settles down to ZK-Sync-ERA, which is another hyperchain. So it kind of gives you this modular stack to build Ethereum-based rollups in. And Further to that, it comes with an out-of-the-box interoperability solution, which is being dubbed Hyper Bridges. Having the same prover, so using a shared prover technology in this stack, allows this seamless and trustless bridging between different hyperchains. So super exciting announcement that comes through and we have Alex and Anthony from the Matterlabs teams coming on to really give the lowdown of what all of that actually means and why it's important.

So super fun episode, But we got another couple announcements for you guys. So I'll toss things over to you, Sam.

Yeah, you guys are gonna be super thankful for that. That intro Dan just gave you to because 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 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 P0DS, pods in all caps, 20 to receive 20% off to permissionless tickets. 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 Atom Accelerator shill for you all.

Yeah, I got to mention it. Love our great sponsor, Atom 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.

The podcast that released yesterday, so this will be a Wednesday, June 28th. We talked a ton about duality, which is a very exciting development coming to the item economic zone. It's really bringing this new era DEX to the ecosystem. On top of that, you have IBC, you have interchange security, the list goes on and on. And with USDC coming through Noble in the next couple of weeks, that's just a continued development that the ecosystem gets to be excited about.

So if you're looking for a grant, or you're a builder, 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 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. So again, be sure to check them out with the link in the show notes. But without further ado, we can jump straight into things with Alex and Anthony from MatterLabs. Alrighty, everyone, welcome back. We are joined today by Alex and Anthony from the MatterLabs team to discuss an exciting announcement.

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 get the announcement from you. So what is the big news and what was released today?

Maybe I'll toss it over to you, Alex.

Absolutely. Happy to. Thank you for having us. So we announced the release of the ZKStack. What's ZKStack?

It's the next step of the evolution of ZKSync project. We started out as a mission focused project, deeply mission driven. We wanted to scale Ethereum. We want to scale public blockchains to get to mass adoption, to accelerate the mass adoption. And we started by focusing on the core technology first.

We built the first version of ZK-SYNC, which is now known as ZK-SYNC Lite. It's specialized for payments. Then we made the next huge step in bringing the first ZK EVM into production, which is known as ZK-Sync Era, which is the first network, which is the first blockchain in our network. And now we're taking the code of ZK-SYNC era and we're giving it over to the community. This is something that we planned actually from the beginning, but now it's actually official.

We unveiled the plans for ZK-Sync to be bigger than just 1 blockchain. Like we're giving you a framework which you can use to build your own chains, which all can be part of this big interconnected ecosystem with shared liquidity, seamless interoperability between the chains, fully trustlessly with minimal costs. And this is something that has this hyper-scaling property. It can scale to accommodate any need that will arise for this emerging Internet of Value. That's roughly the idea of the ZK step.

Great. I appreciate that intro. And just to zoom out a little bit, you guys also 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 a vision of sorts to kind of align the community and what the core values are.

ZK Credo is something we actually used internally for years, not a release of this manifesto or of this idea, it was more a codification of that, just putting them in a shape, in some sort of 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 necessarily understood them all this year as we were building things, we were building the first version, the second version of the ZK-SYNC protocol. We were guided by those principles implicitly. Now we just wanted to make them explicit. It's a first draft, it's open for the community to comment, to make PRs on GitHub.

We want to formalize it, collect feedback and kind of come to a consensus of what this ethical framework is for, like, for basically for all ZK-powered network, because it's very generic, it's not specific to ZK-SYNC. It outlines what we believe are the properties of this hyper-scalable networks that must be implemented in order for us to fulfill the mission of getting to the mass adoption.

Maybe just to add 1 thing there as well, I think at least internally this has been, to Alex'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 in support of a mission and in support of a vision for how 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 MATLABs, 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 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 love how you guys have kind of like laid down these base 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, Arbitrum has orbital, Optimism has the OP stack. How is 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 why you might consider it and some of the advantages. So To start with what it is, so the ZKStack, at a glance, is, you could argue, the generalization of the code base that we've built and have been developing for ERA, but starting to also give the toolkit, the template for what we're calling like hyper chains and this sort of vision for hyperscale. This could be built on this technology. So in scope, so from the technical perspective for the ZK stack are the core components that we have developed for ERA. There'll 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, 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 hyperchained version of a system that looks a lot like ERA. 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 flexible and designed in different ways to support different use cases. So yeah, it's this free, fully open source piece of code, composable design, configurable design.

And essentially this is what the ZKStack is. 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 system.

Yes. And I want to answer the second part of this question. Why is it case-stacked? 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-roll-ups that you could build to just deploy on a chain, which is like separate to Ethereum or inherit some security. The problem with those approaches is that they use this older technologies. If you build your own stack, if you build a chain that is based on Ethereum, like let's say you built an optimistic rollout, 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 superpowers 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 is happening with every technological shift in the past. You know, you go from Zeppelins to airplanes, you cannot just replace the engine. You need to build, like, to change the entire infrastructure, you need to change the hull of the aircraft, you need to do different aerodynamics and so on.

With specifically with ZK, there are properties of zero-knowledge proofs, succinct zero-knowledge proofs, such as succinctness, that allows you to compress data availability, that allows you to use different approaches. Like when you optimize, for example, your account abstraction design for optimistic rollups or for ZK rollups, you will end up with 2 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 forms around that. You cannot really change this anymore.

Look at Ethereum. Look at SelfDestruct. Look at the EAP-4844. Why do we have EAP-4844? Because we cannot change Ethereum at this core protocol level easily.

There were attempts to build EAP-4844 in a way that would natively support account abstraction for all accounts. But they were rejected because this would break 1 or the other invariant, 1 of the other convention that people are depending on. And this would kind of like remove this backwards compatibility. Backwards compatibility is a cost. You have to carry it over a 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 a specific design, like You can go for EVM compatible design, and later you can add other languages, which Arbitrum is doing, which we are doing with our LLVM compiler. You will be able to write smart contracts in Rust, for example.

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 call date and data availability that you can't really change after you deploy this version.

Interesting. Okay. So if I am a developer looking to build with the ZK stack, what are really my options? And what are the security trade-offs of the different options? It's kind of hard to keep it 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 ZKSync era, or you can say, I want this component to look different. So let's walk through the components that you can customize. The first is your sequencer.

You can opt into a centralized sequencer, which is easier to maintain initially, but you probably don't want to stick to this option unless you are, you need a centralized sequencer. You're an enterprise, a bank, 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, for example, you run a consensus in layer 2 that will sequence transactions. So then you'll need the validators, you'll need to stake some token maybe to decentralize it permissionlessly and so on. So you will be able to choose all of the parameters.

Which consensus algorithm you want to use, which how do you secure, what token do you want to use there and so on. The second option is, or configuration, is data availability. This is really, really important. This is a huge topic. By default, ZKSync Era is a ZKRollup.

And we encourage everyone to build ZK-Rollups and promote ZK-Rollups first and foremost. Because ZK-Rollup is an architecture in which you publish data availability through the Ethereum network. So you rely on Ethereum's layer 1 as your data availability layer. 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 you depend on all the full nodes of Ethereum. So This is by far the best and most secure option, and the most centralized 1. But it comes at a price because all the rollups on Ethereum, optimistic and secure rollups alike, share the same data bandwidth, the same limited block space, which you can utilize for your data. So it's currently pretty limited.

It will be extended after proto-dunk sharding and then with dunk sharding it will go much, much bigger and we will be able to accommodate potentially thousands of transactions per second across all the rollups. But we still need some path to go there. And meanwhile, it might be quite expensive. Once all the rollups get a lot of traction and you really bring millions of users to them, the data availability will become a bottleneck. So on this path forward towards Ethereum getting full sharding on DA, you need to consider other options.

And the alternatives could be a Validium, where 1 or multiple parties hold the data availability for a given chain. The state transitions are still secured by Ethereum, but the data availability is then managed by these parties. 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 all the rules are preserved. You don't trust the bank to not spend your money. It's still enforced by Ethereum and all the smart contract rules are enforced.

But it's obviously like they control the data and they can just shut down the data for everyone, burning the entire chain, which is a bit suboptimal. The other option is ZK Porter, where you can... It's essentially the same architecture, it's still a Validium, but the data availability is secured by the users, by token 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 will be suicidal for them to burn all of the stake.

So like the risks are significantly lower than the pure Validium. So you as a user can choose, like, do you want to settle for that? Do you want to go for full ZK Rollup? And in the ZK-Sync architecture, because it's designed like this from the beginning. You can have what is called official evolution.

You can have a choice which account you want to use within the same shard of the system. So it's done in a way where roll-up accounts and ZK Porter 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 Uniswap or with Balancer, with Curve, with all the DeFi protocols on the ZK rollup side, where the whales hold all of their liquidity very, very cheaply, because they don't have to pay, like the data availability is gonna be amortized. So this is 1 very interesting, flexible hybrid option.

I think to a first approximation, these are going to be some of those interesting areas. I think there will be, in the fullness of time, other pieces that can be configured. We can talk about decentralization of the prover or centralization of the prover. But yeah, to 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 could put different restrictions on this tech. For example, you can say, I want to launch this chain which will only host this 1 application. I don't want any DeFi apps there that will clutter the the sequencer space with something irrelevant. It's just a chain for this specific game.

So we only deploy this 1 contract on this chain and then you interact within the bounds of this contract or you can only deploy contracts of this type. So you can, like, you are for freedom to shape all aspects of the experience on the chain, depending on what you need. And on top of that, you can also choose different privacy options. As I said, like 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 deploy a privacy protocol, something like AdStack, or there are multiple other different options. Espresso Labs is working on 1. Other guys, I forgot the name of the protocol. But there are multiple different protocols now in development that you can deploy and you can say 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 when we say Hyperchains, it's not really an option. Everything you launch is by definition called hyperchain. If you build something with the zk-sync or zk-stack, it's basically a hyperchain. It can be an isolated hyperchain or it can be a hyperchain plugged into this network. And this is really, really interesting.

This is the key, most important feature of the ZK step. So you have to imagine it like this. You have different chains. You have ZK-SYNC-ERA. Someone launches their own, like let's say, let's imagine Uniswap would launch their own UniChain as a separate hyperchain in the ZK-SYNC network.

So it's fully separate, it has its own sequencer, it's a ZK-ROAP, so it's Inherit Security from Ethereum. Now, you have some funds in the wallet on the ZK-SYNC era and you want to interact with Uniswap in its own chain. The way it will work for you from the user perspective is essentially the same as if the Uniswap protocol was deployed on ZK-Sync-ERA. You will go to the website, to the DEP application, whatever you use, you connect your wallet, you choose transaction parameters, you click initiate, you do 1 click and say, like, I have to write this transaction. What will happen is the transaction will then go, will bridge from ZK-SYNC era over a hyperbridge 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 ZK-SYNC error.

All of that will happen asynchronously, but atomically. So all of these transactions will be scheduled and they cannot be stopped. They will have to be like or like you will be able to enforce them as long as the chains remain live, the transaction will fully come through and if they stop then subject to the security 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.

And the experience is even worse. If you want to trade on Coinbase or Kraken 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 they arrive. But now you have to do like 3 different transactions. Whereas with hyperchains, it's 1 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 all the hyperchains that want to be part of this network will have to reuse a single bridge hat on layer 1. So 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 will keep the states and the balances for all of these chains and will offer an option for shared prover.

It's going to be fully optional. So like all the hyperchains at all times, whether they are L2s 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 ZK-SYNC-ERA. They only depend on Ethereum.

So this contract, even though it's shared, it's fully independent. So if you don't want to use your shared proof with someone else, you can always generate your own proofs and you can settle them on Ethereum. This will work. You're just going to be less efficient than if multiple chains get together and compress the proofs. And there's going to be protocol for this, how to do it easily and with high lightness.

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 proof that you settle on Ethereum. But if you don't like the system, you can always kind of exit. The right to exit is 1 of the core fundamental properties declared by the ZK Credo and we're going to honor it at you know 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 mass movement, a mass exit of many users.

Okay, I want to dive a little deeper on that 1 bit there. I think that's really, really exciting that you can have 2 separate hyperchains that have composability between the 2 chains. And so I want to dive into exactly how that gets enabled. So it sounds like there is a you have to opt into the shared prover, which is a contract that lives on a Ethereum L1. And then that would allow to like L2 hyper chains to interact.

So we think about the architecture, 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, make a transaction between 2 L3s that are both opted into the shared prover, is that possible as well? Or is it only the transactions between the L2s themselves?

You can make a transaction. You can transact from any address on any hyperchain in the network, whether it's an L2, L3, L5, it doesn't matter, to any other. And it's going to be very, very fast. The latency of this transaction is going to be a few minutes. It starts with probably 15 minutes and then it's going to go down to 1 minute and maybe even under 1 minute.

Because the proofs will be generated very, very fast recursively. We're building a 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 the modern GPU proofs 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 2 or threes 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, right? 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 your 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 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 domains, where you could imagine having an ENS-like address that you could 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 the thing is deployed. You can build a composable experience in between, you know, while it hosted on some layer 5, some layer 2, 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 so first approximation, application developers shouldn't really need to think about it, right? You're building to an interface, And the interface can look constant, independent of whether it's an L2 or whatever configuration of the ZK step.

Interesting. Okay. So something that you guys talked about that's from the credo as well as just a core value of what you guys hold is like sovereignty and 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 included transaction to the L1? What really is the security assumption from the user or the perspective of the user?

How hard would it be to actually get your assets back to layer 1?

We have to consider every chain separately because every hyperchain will have its own set of tradeoffs. Like if it's a Validium, for example, they could freeze the data and there is nothing you can do. But you can try to do something, you can request an exit, and then if your request is not respected, then the entire chain has to hold. For zk-sync-error specifically, it's first and foremost a zk-rollup. Most accounts, and we encourage all the users who can afford it to have an account on zk-rollup.

And for zk-rollup, 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 proofs. You just submit a, basically self-sequence. You sequence your own transaction there and it is supposed to be included in the next block within some time frame, some deadline, by the validators of ZK-SYNC 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 just not work until the priority queue is empty. And since the priority queue will have a kind of predefined sequence of transactions, it's going to be easy for anyone to generate these blocks and produce the proofs without any race conditions. Because the transaction sequence is predefined, there is no race. You know exactly what's going to go in which block, so you can build that.

And when you generate the proofs, you can do it in small chunks, and then if no 1 else generated the block, you just submit this block and you collect the fees that the users 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. It just like it will stop and everyone, anyone can do the work for being compensated for this work. So the tricky part is if you as a user 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, it might become very expensive. Just like it was in the past, it might cost you like $100, $1, 000 to submit a single transaction. So we realized 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 submit a collective claim. So basically doing like starting sequencing transactions together.

So imagine a group of users is being censored. 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. We, the minority, and everyone who supports us. And we believe there should be a broader movement, like more people who support the, who embrace the values of the ZK credit have to say, this is not a normal situation. No 1 should be centered on the chain.

Even if 1 person is centered, we have to all exit. So they get together and someone deploys another instance, another hyperchain, which will not center the users, or will not behave well. Actually, the censorship should be resolved at the protocol level, but let's imagine that the chain tries to change this and introduce some form of censorship. So before this time, the users get together and say like, 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.

You as a user, you just have to sign this transaction, then all the signatures are getting together and you submit a big badge. By you, I mean whoever is organizing this movement. And then you get a lot of users going from Hyperchain A to Hyperchain B, not through layer 1, but through the mechanism of hyper bridges, which is going to be very, very cheap.

Great. Okay. That's super helpful. And then Anthony, you alluded to the use of account abstraction, and that's obviously been a core focal point of ZK Sync era. And you also referenced in the ZK Stack blog post that you released this morning, gasless call data.

Could you kind of elaborate on that and what it enables in the future?

Yeah, so in terms of account abstraction, this is definitely 1 of the 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 what it looks like for us to actually be successful, as we imagine the future here. With respect to Gassers transactions, maybe Alex is a good 1 for you to pick up.

The idea is with account abstraction design that we use for ZK-SYNC era, we rely on the fact that call data comes essentially for free. Because in our design, we only publish the state divs, the final, the outcomes of the transaction, 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 computationally, which is cheap, because we're using very, very efficient zero-knowledge proofs and very efficient GPU provers for that. So from the practical perspective, they are free. So our design leverages this fact. You could put signatures that are coming from the biometric devices on your phone, for example, which are gonna be much larger. You can put a lot of parameters.

You can put a lot of 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. I only want to allow modification of this and these tokens, and I am only authorizing to spend this token up to this limit and so on. You can put all of these parameters in there and the resulting transaction is going to be as cheap as a simple transfer on Ethereum.

Yeah, the way I would think about account abstraction generally is that I think of it like 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. So account abstraction isn't necessarily 1 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 first 10 transactions of a specific user, I want to pay their gas. Or, you know, maybe I have some relationship with a DAO, and for anyone who holds this specific SoldWild NFT, I wanna make sure that transactions to this application are gasless forever. So I think of the set of tools around account abstraction are a set of tools to enable a really good user experience, a 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 opened my Chase mobile banking app, for example, I've got a checking account, a savings account, a brokerage account, et cetera. So maybe I'd want my funds to rest on ZK-SYNC Aira, 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 5% 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. So the roll-up account, with all of the guarantees that we've spoken to, with the ability to maintain 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 comes with 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 wanna 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 different approach to data availability that introduces slightly less secure situation with respect to the funds, but you benefit from that with orders of magnitude cheaper transaction fees.

So you can think about your individual risk tolerance. 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 their activity, like day-to-day activity from a cheaper account, like a Porter-style account, but then the savings account is the Rollup account.

But to also clarify something you touched on in the question, both Rollup and Porter accounts can be part of the same hyperchain. So this can be the part of ZK-Sync error. On 1 single chain you have instant, seamless, synchronous connectivity between them. It's not that you need to build a separate hyperchain to implement ZK-Porter. The way we think about the needs, like who will need their own hyperchain is slightly different.

You build your own hyperchain, if you need to control, you customize certain aspects of it. So it doesn't, I don't see the much need, or maybe it will be the market, the builders will decide, but the generic chains are probably less of a candidate for being a hyperchain. It's more for application-specific chains, where you don't want to share the sequencer with everyone else. Because if you're sharing the sequencer, you're probably just better off on the single chain, which is going to be high capacity, high throughput, with roll-up and porter counts, giving users different levels of security and throughput trade-offs. Now, but like enterprise chains, gaming chains, app chains for maybe you want, like You don't want a decentralized sequencer because latency of transactions is too low.

But instead you want high frequency trading, ultra low confirmations for your transactions. Think something like DYDX. They can have their own separate chain for just for this exchange. 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 separate subreddits, not just for the Reddit entirely. They might want to use the Reddit hyperchain and then L3s for all the different subreddits.

So this is how we think about it. It's more for customization and application specificity 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 1 of the things I want to dive a little deeper on is the state of the sequencer today. So, you know, all these L2s have centralized sequencers, but there's been serious talks towards shared sequencing or the idea of decentralizing the sequencer. How do you guys think about what the next step is for decentralizing the sequencer of ZK-Sync-ERA and offering that to other chains to opt into.

Yeah, I mean, I can jump in with respect to what we're doing already for ERA and can generally speak to the plans for the future. So, you know, you can think of, as we have spoken to, like ERA is the first hyperchain in our opinion. But it's also true by definition that even in a world without hyperchains, the philosophy behind what we're doing is such that the sequencer has to be decentralized, right? 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, had an engineering team actually working on for months at this stage.

And we're very close to actually having the decentralized version of the sequencer ready for public test net. So this is something that from just talking about ERA and then not even talking about the generalization through the ZK stack. This is very, very close to completion. This is something we'll be doing in public very, very soon. And again, like critically important for us for a number of different reasons, right?

But thinking about liveness of the chain, you need to get to a point where the system is decentralized to hit the reliability metrics that we're looking for with respect to liveness. 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 stack. 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 yeah, the engineering work is very mature at this stage. We haven't fully open sourced everything we're doing on this, but we will do very soon.

And people will see decentralized version of ERA on testnet very, very soon. And This is 1 area where I think, personally, just interested for people to think about modularization. Are people interested in building different consensus algorithms? When we think about ZKStack, 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 them in ERA, but providing some flexibility for different use cases. So we will have, I would argue, the first version of the decentralized sequencer available for people to run on their version of the ZK stack, or obviously we'll be deploying as we decentralize ERA.

But this is also an opportunity for innovation, creativity, more modular options to be built into the stack itself.

And so when you think about decentralizing the sequencer, what does that actually look like? Is that like creating an alternative validator set that is kind of acting similarly to something you'd see on the L1, where these validators are working together? Maybe they have something at risk, some token that's staked to kind of prove their honesty? Or how do you think about actually decentralizing the sequencer?

Yes, so the idea would be that you have a validator set at L2 that are performing the role that we perform with the centralized sequencer today of, you know, ordering and processing the transactions. We have a design, like I mentioned, for what this looks like for ERA. And we will be talking about that a lot more in the coming months. We'll be rolling this out and you can imagine, yeah, what this looks like. The first simple version from an engineering perspective that we might even have on testnet is something like a proof of authority network, where you basically say, look, we want to test the decentralized sequencer.

On a testnet, we're going to run n nodes, and this just doesn't require proof of stake, right? 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 our main net, 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. And it will look like, you know, an increasingly mature and increasingly sophisticated consensus algorithm.

It's not enough for us to decentralize the sequencer. We also have to decentralize the prover, which is a bit more challenging because 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 prover in a way that can run on the consumer hardware. We actually made huge progress in this direction.

We'll publish some really interesting news about this soon.

Okay, I see. And I imagine, you know, it's harder for you guys to say, but the ZK-SYNC token, if there ever is 1, 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?

We will publish separate designs on this later. There are important aspects to take into account, but in general, I can say that we don't have better mechanisms to decentralize permissionlessly other than the token at stake. So you can infer things from you.

That part's interesting to me though, is like, last time we spoke, 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 exact like have composability across a larger ecosystem. So that was you know a couple months ago now I'm curious 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 likely have separate ecosystems that are utilizing different 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 hyperchains are built around the idea of a common standard. It's just a question of what this common standard has to be. So you have several components here. You have this shared bridge hat, this shared smart contract where hyperchains can be deployed on. And then you need for them to have certain common circuits that they trust from each other that the certain actions work from correctly.

So it would be a challenge to find a minimum viable like protocol like minimum set of circuits that are required there. But the necessity to have this shared smart contract means that it's a little... It requires you to pick an ecosystem in which you will be building your hyperscalability. You cannot do hyperscalability across multiple ecosystems. You can trustlessly bridge between different rollups.

You can trustlessly bridge, for example, even between optimistic and ZK rollups. That is possible, but it's not going to be seamless. If you bridge from an optimistic rollup to ZK rollup, you have to wait 7 days for the native security from Ethereum. If you transfer, if you bridge something from 1 ZK rollup to another ZK rollup, not using synthetic assets, but actually like true bridging of real assets, You will have to pay to Ethereum for this transaction. You will have to pass this transaction for Ethereum, actually transferring assets from 1 layer 1 contract to another layer 1 contract, In which case you don't have any benefit of the scale.

You still have to pay for a single Ether or ERC20 or NFT transfer on layer 1. It defeats all the purpose of scale. It's not hyper-scalability. It will not give you this seamless experience with user on any chain interacting with any protocol on any other chain. So I think we'll end up with a situation where the users have to pick these ecosystems.

And then this is why you have to pick the ecosystem wisely 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 from scratch in the hyperchain world. So yeah, I hope this answers the question.

Maybe just add 1 other quick thought as well. I think there's some tension between the idea of reaching more standardization, more commonality today, with also how quickly we're seeing innovation. So when things are moving as quickly as they are, my expectation, I think our expectation 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 and implementation of the proof systems, lots of optimization that we're not ready for yet, or at least like hasn't been implemented yet. So lots of optimization that's still a low hanging fruit. And also as research continues, lots of new ideas that will, I'm sure, proliferate.

So yeah, for us, when we're thinking about standardized proving, shared proving, doing it inside the framework of the ZK stack is really compelling because you get to 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 shared way with the open source technology.

So I want to zoom out a little bit just to get your guys' take on 1 question. So 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. It's just roll apps versus app specific. But then we saw DYDX announce their commitment to the Cosmos, and that should be launching in the next couple of months. So I just wanted to ask you guys, is there anything you're watching closely on that move that would potentially change your Ethereum-centric thesis if you set aside your values, I guess, for decentralization and security for a moment?

So I want to start with saying that this is not a coincidence that we're having a very similar paradigm, because the original idea of Cosmos was to build the Internet of blockchains. And if you think about it, 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 analogies are inevitable and they are going to be present in all ecosystems like Ethereum is the internet of roll-ups. As you can think it's going to be the network of hyperchains.

So like from this perspective it's understandable. It's also understandable why DYDX had to move. The keyword here is sovereignty. They did not have sovereign... 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 with 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, the Cosmos SDK, Tendermint, where you can just plug in your consensus and it's a modular framework where you can build stuff. And for whatever reason, they were not happy with the optimistic stack alternatives that were available back then. Because being ZK-pilled in the first place puts you in a position where you don't like 7 day delays and stuff like this. So this is why we're building the zkstack. We want to give people an alternative that will actually work.

If you compare the zkstack 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-sigs. So you have like you introduced trust assumptions. You cannot bridge from 1 chain to the next and then from there to the next and 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 trustless. It's not the spirit of blockchains as we know them, the decentralized Satoshi vision. With Hyperchains, the thing that makes hyperchains hyperchains is hyperbridges.

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 1 click and 0 trust assumptions because if the link is HTTPS then you know for sure that you're landing on the right page. You don't have to think about the architecture underneath, all you need to know is it's seamless, cheap, 1 click, and trustless. And this is what hyperbridges enable. And we've touched a little bit on the architecture, on the aspects, like how exactly this works. We encourage the listeners to actually go into the docs and read the posts.

We did our best to expand it and we will have an AMA where We encourage people to ask questions and we're happy to engage and try to provide more clarity there. But with hyperbridges, you rely on math, cryptography, and Ethereum and nothing else. On Ethereum is the whole set of the entire set of Ethereum validators. With hyper, with Cosmos chains, you rely on Cosmos validators. 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, I want to try to like sum this up and tell me if you know this is like the inaccurate way to kind of explain what the ZK stack 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 use case particularly is. And the actual design of the hyperchain can vary. You can use a Validium that maybe has different security guarantees because it uses some centralized DA layer, or you could build the opposite end of the spectrum, which would be like a pure ZK roll up that posts all of its data down to the L1.

So there's like a design space within the hyperchain itself, as well as kind of where it's situated in the stack, again, being an L2 or an L3. And then all of these hypergames have native communication between them because of the shared prover system that enables the hyperbridges that you just spoke to. Is that like a good way to kind of sum up what the design space of 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 really kind of create into. And I just want to have 1 more question for you of like, what do you think is the, you know, is, have you talked to any teams that are like excited to come build out their own hyperchain?

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 hyperchain is the right solution for them.

Yeah, I can jump in. So we've got some really exciting early partners. I think with respect to announcing specific names, I think I will leave it for them to make their own announcements. I'm sure many will be coming soon. The choice of partners early on was not accidental.

So 1 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 3 different banks, probably the solutions that they would have chosen would look somewhat consistent. So we've definitely got a cross-section of partners who are doing different things. Maybe surprisingly, maybe not, that 1 of the big early use cases that people have wanted to explore was what a Validium would look 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 wanting to make that design choice. But yeah, what we'll see in the coming months is we will see progress in public from, I think, of the order of 4 or 5 key partners that are building towards their own particular solution with the ZK stack. But definitely in terms of some of the early use cases, they want to be able to have interoperability with the broader ecosystem. They want to be able to interact with the credibly neutral platform that I think is Ethereum. But for whatever reason, and there are different reasons behind this, they want to keep some of their state, or yeah, have different choices with respect to 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, made different design choices. But this is 1 of the interesting areas that we've seen explored with the first few people that we've been, you know, sort of privately thinking through some of this before being ready to do it as publicly as we are now.

And then last question for you guys, you've already been so generous with your time, but just a real quick 1. 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 interoperability benefits if you would choose maybe like a Celestia or EigenDA to post your data to as a hyperchain?

Not at all. You will just, they will determine the security properties of your hyperchain. But the beauty of it is as soon as you move funds from 1 hyperchain to the next, the original hyperchain doesn't matter for you. This is not the case for Cosmos, but this is the case for us. Even if the original chain crashes, collapses, the data availability is not working there, you're safe because you just moved it to a to some ZK rollup.

So yeah, it's the choice, sovereign choice 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 3 to 6 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 ZK Sync, 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. We encourage you guys to take a look at our code base and consider contributing or applying to join our team to help us build scalable blockchains. And thank you for having us. It was a fun conversation. Loved it.

Yeah, maybe just to add, we would love really feedback on the ZK Credo, you know, comment. We've got everything open in public on GitHub now. We'd love for some discussion with the community. For anybody who's interested in building or thinking through solutions for the ZK stack, Don't hesitate to reach out. We'd love to chat and we'd love to discuss more as the system evolves.

Awesome. Take it easy guys. Talk to

you