0xResearch Podcast Summary: zkSync's Hyperchain Network Effect | Alex Gluchowski, Anthony Rose

Introduction of ZK Stack

Matter Labs, the team behind zkSync Era, has published the ZK Stack, a more interoperable and modular solution for building L2s and L3s based on Ethereum.

Vision: Achieve hyper scaling with chains built using ZK Stack, that can be part of a big interconnected ecosystem with (a) shared liquidity (b) seamless interoperability (c) fully trustless (d) minimal cost

ZK Stack centers around Hyperchains, which are rollups with broad design space:

Validium: Uses centralized DA provider, giving it a different set of security guarantees
Pure ZK-rollup: Inherits Ethereum’s security
Many more types by experimenting with the design parameters

Hyperchains can be:

L2s: Settle down to Ethereum or;
L3s: Settling down to L2s

Hyperchains come with out-of-the-box interoperability solution (native communication between Hyperchains): Hyperbridges. Essentially, Hyperchains have the same prover (through shared prover tech) allows seamless and trustless bridging between different Hyperchains.

ZK Credo

Has been used internally by the Matter Labs team. It is now shared to the community for discussion and formalization of the North Star, the framework for ZK powered networks.

One of the core fundamental properties of ZK Credo is the ‘right to exit’. Hyperchains can have the control over whether they wish to share their resources with others, or be siloed.

What is ZK Stack?

Open-sourcing of the codebase that has been developed for zkSync Era, and consist of the key components which includes:

Sequencer
Circuits
Prover
System contracts
Bridging interfaces
Compiler
SDKs

The above mentioned are essentially the core components for deployment of a Hyperchain that is very similar to zkSync Era. Over time, these components can become more flexible and designed in different ways to support more use cases, while reamining configurable and composable.

Why ZK Stack?

Problem with existing stacks used to build rollups is the use of older technologies. This makes it very difficult for transition to newer technologies in the future. The transition is possible, but there will be a limitation to the leverage of ZK. This is because certain design decisions have to be taken from the start, if these are not included from the start, it will be really hard to change.

Analogy: This is evident with technological shifts in the past. Going from cars to airplanes, it is not possible with just an engine replacement. You need to change the entire infrastructure.

When applications build off a certain set of standards, and the ecosystem forms around these standards, it is difficult to change in the future. An example is Ethereum, EIP-4844 is required because of how difficult it is to change Ethereum at the core protocol layer. There were attempts to build EIP-4844 (the concept) in a manner that will natively support account abstraction, but this would have broken the conventions that applications were built on, removing backwards compatibility.

Extension of chain is possible. For example, building an EVM compatible design, but later adding on other languages. This does not affect anything that was deployed previously and is thus unproblematic. However, changing the fundamentals is difficult and there are certain key components such as call data and data availability that can’t really be changed after deployment.

Architectures Available with ZK Stack

ZK Stack: Modular framework which allows customization of different aspects of the chain. It is possible to start with all the defaults, which is just copying the configuration of zkSync Era. However, there are multiple configurable components.

Sequencer

There is the choice of opting into a centralized sequencer, which is easier to maintain initially. It is possible to decentralize the sequencer through a consensus mechanism in L2, which requires validators and token staking. All of these parameters (consensus algorithm, choice of token used for staking etc.) are customizable.
Data Availability (DA)

ZK-rollup is an architecture in which DA is published through the Ethereum network, that means relying on Ethereum L1 as the DA layer. This gives the rollup 100% of Ethereum’s security as they rely on the entire network and not individual validators. As a result, the validators do not have the power to withhold data from the rollup. This is the most secure and centralized option.

However, there is a tradeoff for this. All rollups on Ethereum, optimistic and ZK alike, share the same data bandwidth (same limited blockspace) to be utilized for data. This bandwidth is currently limited, but will be extended after proto-danksharding and eventually danksharding, which will potentially accommodate 1000s of txns per second across all rollups.

Once rollups gain traction and user volume increases significantly, DA will become a bottleneck, increasing the cost. Before Ethereum reaches full sharding on DA, rollups have to consider alternative DA solutions, which includes:

(a) Validium

One / multiple parties hold the DA for a given rollup. State transitions are secured by Ethereum but DA is managed by these other parties. These parties abide by rules enforced by Ethereum, and thus the order of txns will still be preserved. They offer out-of-the-box privacy as they have the power to not disclose certain txns. However, this comes at the expense of decentralization as DA is controlled by the parties.

(b) zkPorter

Also a Validium, but the DA is secured by the users who stake their tokens. Risks of zkPorter is thus lower than a pure Validium.

Rollups and zkPorters can seamlessly interact with each other synchronously within a single txn. zkPorter users will be able to interact with the dApps built on other rollups.

In the future there can be more configurations, such as for the prover etc. At this state, configurable sequencer and DA will be the most interesting as its where users will be able to customize the stack the deepest.

It is also possible to put restrictions on the stack. Such as having a chain host only one single application, to prevent cluttering of sequencer space. In addition, privacy is also customizable.

Characteristics of Hyperchains

Composability

Even with all of these customizations available, the Hyperchains still remain plugged within the ecosystem where liquidity is shared.
Full Sovereignty

All Hyperchains have full sovereignty, they do not depend on each other or zkSync Era, they are only dependent on Etheruem.
Low Latency

Txns can be made between any Hyperchains in the network, regardless of which layer of the stack they are. The team is working on building the tree of recursive proofs, which will prove the blocks in parallel (regardless of the block size), reducing the latency significantly.

Analogy: Email. Users don’t have to worry about the email hosting infrastructure when they send an email.

ZK Stack’s Account Abstraction (AA)

Design of AA in zkSync Era is reliant on the fact that calldata comes for free. The system can include any number of inputs (a lot of parameters), which do not have to tap into Etheruem’s DA layer (expensive). The inputs only have to be computed which is cheap due to efficient ZK proofs and GPU provers.

It becomes possible to have inputs such as biometric data from mobile, and the system can take a lot of parameters and invariants for the txn. There is a higher level of security for the users as the parameters can be customized to indicate the users’ needs. For example: In this txn I only authorize for spending of a particular token up to a certain limit. This will still be as cheap as a single txn on Ethereum.

🍪’s thoughts: The UI of such parameters customization remains to be seen. We have to bear in mind that the UI has to be sufficiently friendly for users to benefit from it. Otherwise, more often than not, users will choose to go for the default choices.

Matter Labs team has designed the AA in a way where developers will have freedom to customize their payment interface so that it makes sense for them at scale.

Co-host, Sam Martin, makes an analogy to Chase mobile banking account which has checking account, savings account and brokerage account. User might choose to have their funds to remain within zkSync Era, which has strong security guarantees, and this would be similar to the savings account. When the user wishes to use a dApp like Uniswap, they will swap to an exterior account that has a certain sum stored within it. The AA comes into play by allowing the users to easily interchange between different accounts on the various Hyperchains with different security assumptions.

Based on the previous analogy, this is how we can view it:

Rollup Account = Savings Account

Rollup account gives users the ability to maintain control of all their assets from L1. This has the highest security. This account would in some sense, be more difficult to maintain. This is where most funds should be maintained.
Porter Account = Checking Account

Carry out txns, interact with the game etc.

This account does not have full security in the same way due to the different approach taken towards DA. The benefit here would be cheaper txn fees.

The use of accounts is likely up to individual risk tolerance.

It is possible for rollup account and porter account to be on the same Hyperchain. This means that on one single chain there is instant seamless synchronous connectivity between them.

Who Would Build a Hyperchain?

The building of a Hyperchain is warranted by the need to customize certain aspects of the chain: Application specific chains. In addition, having a single chain has higher capacity and higher throughput.

Enterprise chain, gaming chains, app-chains that do not wish to have decentralized sequencers given the higher latency, social network chains etc. For example, Reddit which has 500,000 daily active users. They will likely require multiple Hyperchains for the different categories. It might look something like Hyperchain for the Reddit category itself, and then L3s for sub-reddits.

🍪’s questions: It seems that building a Hyperchain has a lot of outsized benefits, including the customization ability and higher throughput, all while being plugged into the zkSync Era ecosystem where all Hyperchains are highly interoperable and dApps built are composable. In this case, what is deterring builders from developing their own Hyperchain? Could it be the expenses of building it or the overhead cost of maintaining a chain? The security levels remain the same given that both rollup accounts and Porter accounts can be created within any chain.

User Experience (UX) on Hyperchain

Scenario:

Uniswap launches its own Hyperchain. It is completely separate with its own sequencer
User has funds on zkSync Era and wish to interact with Uniswap
The UX will be entirely same as if Uniswap was built on zkSync Era
Once user authorizes the txn, txn will bridge from zkSync Era over a Hyperbridge to Uniswap chain
Txn is executed on Uniswap chain and the results will be sent back to zkSync Era

All of the above will happen asynchronously but atomically. All txns that are scheduled cannot be stopped. There is no trust assumptions, and there is no additional capital requirements.

This is possible because all Hyperchains will have to use a single Hyperbridge on L1. Hyperchains are deployed on a smart contract (Hyperbridge) that will keep the states and balances for all chains, and offer an option for shared prover.

UX: Moving Assets to L1

Question: How can a txn be force included into the L1 should there be problems with zkSync Era? What are the security assumptions of the users?

Every Hyperchain will have its own set of tradeoffs. For example, if Validium decided to freeze the data, since centralized parties control the DA, there’s nothing that can be done by users. However, a user can request for an exit from the Hyperchain, and in the case that the request is not respected, the entire chain has to halt.

ZK-rollups have a mechanism called the priority queue. A user can always go onto the L1 to submit their txn: there is no need to generate any ZK proofs, it’s basically a self sequence (this however might become expensive based on activity on the L1, e.g. congestion). Users sequence their own txns and it is supposed to be included in the next block by the validators of zkSync Era. If the txn is not included, the protocol will halt and enter the priority mode where anyone can sequence txns: anyone that’s in the priority queue HAS to be processed. Priority queue will have a predefined sequence of txns, it will be easy for anyone to generate these blocks and produce the proofs.

The design of the priority queue is extended so that users can come together to submit a collective claim: starting sequencing txns together.

Scenario:

A group of users are censored
They get together (there is a leader that organizes this)
Someone deploys another Hyperchain (new instance) that will not censor the users
Many txns will be collected using the front-end of the other chain
Leader collates the signatures and submits the batch to L1
These users are moving from 1 Hyperchain to another through Hyperbriges

🍪’s questions:

Genuinely curious, if we allow self sequencing without generating any ZK proofs, does the txn still inherit the characteristics of ZK?
If the protocol is halted until the priority queue is empty, wouldn’t the liveness of the chain take a rather huge hit?
Who is the leader to lead the collective claim, how do we know that this leader is trustworthy?
It was mentioned that based on ZK Credo, if one user is censored, the rest of the users will have to all exit and deploy a new instance. This seems to be a too optimistic view on the demographics of users and their willingness to participate in this. Even though on the users’ end all they have to do is to sign a txn, the technical expertise of users to be able to know what is happening (deploying a Hyperchain) is also in question
Sounds like quite a bit of fragmentation to me should there be manual interference required to create and participate in the new instance (new Hyperchain)

Decentralized Sequencer

zkSync Era’s design is such that the sequencer has to be decentralized, the team is close to having their decentralized sequencer be ready for public testnet. Important for chain liveness, which is required to achieve reliability metrics.

The decentralized sequencer is part of the ZK Stack. Builders using the ZK Stack can choose to opt into implementing this.

On top of this, there is a need to decentralize the prover. This is more challenging as a lot of work has to be orchestrated for merging. There is also a need for recursion of the work done in a timely manner. The core component to this is to build a prover that can run on the consumer hardware.

🍪’s thoughts:

If this is the case, it seems like from the get go, builders using the ZK Stack won’t actually have a lot of optionality. This means that the first iteration of Hyperchains will be very similar to that of zkSync Era’s architecture and characteristics
In addition, how backward compatible are these opt-in architecture customizations going to be? For example, once the decentralized sequencer is released, it is incorporated by the Hyperchain, but after a period of time the decentralized sequencer is upgraded (perhaps say a different kind of consensus algorithm), what kind of changes will it have on the Hyperchain?
Will changing the consensus algorithm be akin to the ETH Merge, this is considering the point mentioned above that the entire zkSync Era ecosystem is interconnected

Potential Alpha: Should there be a zkSync token, it will be integral in decentralizing the prover and sequencer, and also securing the data of ZK Porter chains. This is because staking of token is currently the best mechanism to decentralize permissionlessly.

Modularization

Anthony mentioned that there were ideas of allowing the community to contribute modules to the ZK Stack, which might not be in the manner that Matter Labs had implemented things into zkSync Era, but provides flexibility for different use cases, expanding the space for innovation.

🍪’s thoughts: The community contributed modules sound like a marketplace. In Empire’s podcast on Uniswap v4, it was mentioned that in web2 companies tend to converge towards becoming a marketplace. Applying this concept, such community contributed modules could potentially become the ‘products’ to be bought and sold, creating a robust marketplace, with constant feedback loop from both the demand and supply side.

State of Proving Format

Hyperchains are built around the idea of a common standard: Achieved through hyperbridges.

Hyperbridge: Smart contract that serves as a shared bridge hat that Hyperchains can deploy on. There needs to be certain common circuits that they trust from each other that certain actions were performed correctly. It is a challenge to find the minimum set of circuits that are required to be common.

However, the necessity of this shared smart contract means that the hyperscalability can only be built out in one particular ecosystem. It is not possible to do hyperscalability across multiple ecosystems

It is possible to trustlessly bridge between different rollups (optimistic and ZK), but this is not going to be seamless. Bridging from optimistic to ZK-rollups might have delays that goes up to days
Bridging native assets between ZK-rollups will require payment to Ethereum. There will be no benefit of scaling

🍪’s thoughts:

Alex’s (Co-founder and CEO of Matter Labs) point of view over here is that users and developers both have to choose the correct ecosystem to be in. I do understand why this might be the case because the whole concept of Hyperchains is to allow customizations of chains deployed, allowing the ecosystem to host all kinds of applications and use cases (as mentioned earlier on, DEXs, games, social media etc.). By theory, if the ecosystem is already able to accommodate all of these use cases, there is no need for other ecosystems
However, does this mean that there is monopoly in some sense? And if this is the thesis, it sounds like investments into ZK-rollup ecosystems is a binary one, the ecosystem either takes off, or it flops
In addition, Alex mentioned that developers building using a different stack from ZK Stack will not be able to achieve migration into the Hyperchain ecosystem, and will instead have to build from scratch. But why is this the case?
In the current landscape, there are quite a handful of teams working on products such as compilers to be able to deploy EVM projects into zkEVMs (albeit it might not be entirely seamless and there will need to be some manual changes). There are also teams working on zkEVMs that are EVM compliant / equivalent from the get-go, so why is it that the outcome is so binary in the sense that the choice of an ecosystem is a definite and irreversible one?
Should this actually be the case, it seems like there will be a high level of fragmentation and developers might be faced with tougher choices to build (which are not related to the technical aspects)

Proof Systems | Innovation vs Standardization

There is tension between reaching standardization and the speed of innovation.

When innovation is moving at such a fast pace, there is a lot more improvements and optimizations that could come to the design and implementation of proof systems.

ZK Stack vs Other Stacks

Key differentiator: How the bridge works.

Bridges determine the properties of the ecosystem

Trusted Bridges

These are no different from standard multi-sigs as trust assumptions have to be introduced. It is not possible to continuously bridge amongst multiple chains as there will be accumulation of trust assumptions. This is not scalable and not trustless
Hyperbridges

Derived from the internet idea of ‘hyperlinks’, which are able to take users from any page on the page to any other page in exactly one click with 0 trust assumptions. This is seamless, cheap and trustless

The reliance here is on Mathematics, Cryptography and Ethereum

ZK Stack Partners

Likely to be highly institutional

Choice of DA Layers

Hyperchains are able to use alternative DA layers without losing interoperability benefits. It’s just that the security level will differ.