Alex Gluchowski and Anthony Rose join us to discuss zkSync's ZK Stack and how Hyperchains enable composable applications at scale. We cover the ZK Stack design and ZK Credo, the security tradeoffs of various Hyperchain implementations, how Hyperchains enable shared composability, zkSync's forced tx inclusion mechanism, Hyperchains vs Cosmos appchains and more!
- -
Timestamps:
(00:00) Introduction
(03:50) Interview Start: zkSync
(04:06) The ZK Stack Announcement + ZK Credo
(08:32) Why Use the ZK Stack?
(14:05) Implementations and Security Tradeoffs
(26:39) Hyperchain Composability
(29:52) The Priority Queue: Forced Transaction Inclusion
(34:59) Account Abstraction
(38:20) Customization and Application Specificity
(42:24) Decentralizing Sequencers and Provers
(52:14) Hyperchains vs Cosmos Appchains
(57:00) ZK Stack ELI5 and Early Partners
- -
Follow Alex: https://twitter.com/gluk64
Follow Anthony: https://twitter.com/anthonykrose
Follow Sam: https://twitter.com/swmartin19
Follow Dan: https://twitter.com/smyyguy
Follow Blockworks Research: https://twitter.com/blockworksres

Subscribe on YouTube: https://bit.ly/3foDS38
Subscribe on Apple: https://apple.co/3SNhUEt
Subscribe on Spotify: https://spoti.fi/3NlP1hA

Get top market insights and the latest in crypto news. Subscribe to Blockworks Daily Newsletter: https://blockworks.co/newsletter/
- -
Today’s episode is brought to you by the Atom Accelerator, now offering grants to build out the ATOM economic zone! It's the perfect time to build with Cosmos and join the thriving ATOM ecosystem. With Interchain Security live, and the power of IBC connecting the interchain, builders are flocking to Cosmos. Join the ranks of Neutron, Lido, Astroport, Gitcoin, Mars and numerous other projects harnessing Cosmos’ leading infrastructure. Discover how to secure a grant from the Atom Accelerator by visiting https://www.atomaccelerator.com/ today! 
--
Use code PODS20 to get 20% off Permissionless 2023 in Austin:
https://blockworks.co/event/permissionless-2023

Research, news, data, governance and models – now, all in one place. As a listener of 0xResearch, you can use code 0XRESEARCH10 for a 10% discount when signing up to Blockworks Research https://www.blockworksresearch.com/
- -
Resources:
zkSync
https://zksync.io/
https://twitter.com/zksync

ZK Credo
https://github.com/zksync/credo

ZK Stack Announcement
https://twitter.com/zksync/status/1673317167628967936
- -
Check out Blockworks Research today! Research, data, governance, tokenomics, and models – now, all in one place
Blockworks Research: https://www.blockworksresearch.com/
Free Daily Newsletter: https://blockworks.co/newsletter
- -
Disclaimer: Nothing said on 0xResearch is a recommendation to buy or sell securities or tokens. This podcast is for informational purposes only, and any views expressed by anyone on the show are solely our opinions, not financial advice. Dan, Sam, and our guests may hold positions in the companies, funds, or projects discussed.

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.

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.

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.

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.

And then we also, as always, have a quick little Atom Accelerator shill for you all.

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.

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

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.

We are joined today by Alex and Anthony from the MatterLabs team to discuss an exciting announcement.

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?

So we announced the release of the ZKStack.

It's the next step of the evolution of ZKSync project.

We started out as a mission focused project, deeply mission driven.

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.

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.

And just to zoom out a little bit, you guys also published your manifesto of sorts on GitHub just a little bit ago.

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.

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.

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.

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.

And I want to answer the second part of this question.

There are a couple of things you can use today to build your own chains.

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.

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.

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.

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.

It does not affect anything that was previously deployed.

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.

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?

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.

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.

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.

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.

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.

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?

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.

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.

This is the key, most important feature of the ZK step.

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.

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 additional capital requirements.

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.

See all 0xResearch transcripts on Applepodcasts

Are Hyperchains The Scaling End Game? | Alex Gluchowski, Anthony Rose