ZK Chains

The need for blockchain scalability is paramount as networks like Ethereum, currently limited to processing about 12 transactions per second, strive to handle millions of transactions to support global financial activities on-chain. While various architectures like Polkadot, Cosmos, Near, and Eth 2.0 explore solutions like multi-chain or shard structures, issues with trust persist. However, zero-knowledge proofs have emerged as a promising solution to these challenges, offering cryptographic security when combined with data availability layers and ZK Rollups, thereby enhancing the scalability and security of Ethereum.

What are ZK chains?

ZK chains represent a sophisticated layer of blockchain architecture, consisting of parallel-running instances of zkEVM that achieve consensus and finality on Ethereum's Layer 1 (L1). Inspired by the concept of hyperlinks in the traditional web, which connect various webpages, ZK chains utilize Hyperbridges to connect different rollups within the elastic chain ecosystem, facilitating seamless interactions across chains.

Gray lines show proofs, orange lines the hyperbridges, which automatically connect all blue chains.

Structure and functionality

ZK chains operate with a shared bridge contract on Ethereum's L1 and include native bridges between individual rollups, enhancing the overall interoperability and efficiency of the network. Key features of ZK chains include:

1. Trustless Validating Bridges: Ensures that rollups within the ZK chain are interconnected without requiring additional trust layers.
2. Asset Transfers: Hyperbridges facilitate the easy transfer of assets, including burning and minting mechanisms, across the ecosystem.
3. Unified Governance: Leveraging a shared governance framework on L1, the ecosystem can coordinate updates or respond collectively to vulnerabilities, much like a traditional blockchain network would handle a fork.
4. Security and Trust: All ZK chains must utilize the standardized zkEVM engine to maintain consistent security and operational standards, ensuring that trust and security are derived directly from L1.

Development and Deployment

ZK chains can be developed and deployed by anyone, fostering a diverse and open ecosystem. However, for a ZK chain to remain trusted and fully interoperable within the network, it must utilize the zkEVM engine that powers the ZK Stack. This requirement ensures consistency in execution and security across different instances of ZK chains.

Modular Implementation

ZK chains are designed to be modular, meaning developers can select different components of their blockchain systems or implement their own, with the exception of the zkEVM core. This modular approach allows for customization and flexibility in blockchain development while maintaining core standards necessary for network security and interoperability.

---

How Hyperbridges Work

Hyperbridges are composed of smart contracts that verify transactions across chains using Merkle proofs. The process involves locking the original asset in a shared L1 bridge contract, unifying liquidity across the network, and follows these steps:

1. Initiation: A transaction is initiated on a ZK chain, aimed at crossing to another chain within the elastic chain ecosystem.
2. Settlement on L1: The sending ZK chain compiles a cryptographic proof of the transaction and settles it onto Ethereum's Layer 1, anchoring the transaction's validity.
3. Transaction Root Update: Ethereum's Layer 1 updates the Transaction Root, a cumulative record reflecting all transactions processed across the elastic chain ecosystem.
4. Root Importation: The receiving ZK chain imports this updated Transaction Root through its consensus mechanism, akin to the way Layer 1 to Layer 2 messages are currently handled.
5. Transaction Submission: A relayer submits the transaction along with a Merkle Proof to the receiving ZK chain. This proof connects the transaction to the newly updated Transaction Root.
6. Verification and Execution: The receiving ZK chain verifies the transaction against the Transaction Root. If the verification is successful, the transaction is executed, and the relayer is compensated for their service.
7. Proof Settlement: Finally, the receiving ZK chain settles its proof on L1, conclusively validating the transaction within the elastic chain ecosystem.

Types of Bridges in the Elastic Chain Ecosystem

• L1-L2 Bridges: These bridges are foundational, facilitating direct interactions between Ethereum's main chain (L1) and second-layer solutions (L2).
• zkPorter Shard Bridges: Specifically designed for developers, these bridges connect different shards of the zkPorter virtual machine. They are atomic and asynchronous, ensuring seamless operations akin to traditional blockchain interactions.
• Hyperbridges: Similar in function to L2 to L1 bridges, Hyperbridges are asynchronous and not atomic. They leverage Account Abstraction and the services of external relayers to simplify the user experience, making cross-chain interactions feel as straightforward as moving from L1 to L2.

Enhanced user experience

Hyperbridges enhance the blockchain user experience by abstracting complex cross-chain interactions. Users do not need to manually initiate calls on the destination chain, thanks to the automation provided by Account Abstraction and the efficiency of external relayers. This setup minimizes transaction fees and reduces the complexity typically associated with cross-chain movements.

Simplified Cross-Chain Transactions

Hyperbridges utilize Account Abstraction and external relayers to automate the process of initiating calls on destination chains. This automation means that users do not need to manually manage the technical details of cross-chain transactions. Here’s how this enhances the user experience:

• Reduced Complexity: Users interact with a seamless interface that hides the underlying complexities of blockchain operations.
• Lower Fees: By leveraging efficient relayers and minimizing manual operations, transaction costs are kept low, akin to standard gas fees within a single chain.

Unified Asset Management

In a ZK chain environment, users' wallets will display all of their assets across various chains in a unified interface. Here’s what this integration looks like:

• Asset Bridging: Relayers manage the process of bridging assets between chains, handling the necessary burning and minting of assets as they move across the ecosystem.
• Intuitive Addressing: ZK chains feature unique identifiers that integrate with the Ethereum Name Service (ENS), making recipient addresses as straightforward as email addresses. While users can still use traditional Ethereum addresses, the combination with ZK chain identifiers simplifies transactions further.

Protocol-Integrated Bridging

Bridging is integrated directly into the transaction protocols of wallets, streamlining the process alongside standard asset transfers. Key aspects of this integration include:

• Quick Settlement Times: The time taken for bridging transactions depends on the proof settlement time of the specific ZK chain, typically ranging from 1 to 15 minutes.
• Minimal Infrastructure Needs: With relayers being the primary external infrastructure, the overall system remains lightweight and cost-effective.

Real-World Application: Cross ZK Chain Uniswap Transaction

Consider a practical scenario where you want to swap Ethereum for DAI using a cross ZK chain transaction on Uniswap:

1. Transaction Initiation: You initiate the transaction directly from your wallet.
2. Relayer Involvement: A relayer picks up your Ethereum and deposits it into the Uniswap chain.
3. Asset Swap: On the Uniswap chain, your Ethereum is automatically swapped for DAI.
4. Completion and Return: The relayer then transfers the DAI back to your original chain.

This entire process is executed as a single transaction, making it feel as seamless as if no chain-switching occurred. The only difference a user might notice is a slightly longer confirmation time, depending on the specific ZK chain used.

When setting up wallets on cheaper chains using scaling solultions like (validium), users will have to trust the hosting organization to not lose their funds. Although the funds held in validiums are secure against theft, they can be frozen if the data becomes unavailable. This scenario would not only lock users out of their assets but also potentially damage the reputation and operational status of the hosting organization.

---

Proof Aggregation

Proof aggregation is a critical component in scaling blockchain technologies, allowing for the efficient verification of transactions across multiple chains. This process enhances the hyperscalability of the ecosystem, vital for supporting extensive blockchain operations without overwhelming the base layer (L1). Below, we explore the various methods of proof aggregation within the elastic chain ecosystem and their implications.

Simple proof aggregation

Simple proof aggregation treats each ZK chain's proofs as independent entities that are verified collectively on Ethereum L1. This method is straightforward but has limitations:

• Infrequent Settlements: To conserve on gas fees, proofs are settled less frequently, which can delay the verification process.
• Limited Fast Messaging: The infrequent settlements restrict the ability for rapid communication between chains, potentially slowing down cross-chain interactions.

L3s: Layered proof aggregation

In this model, ZK chains can act as Layer 3 (L3) networks that settle their proofs onto an intermediary Layer 2 (L2) ZK chain. hThis structure allows for several benefits and drawbacks:

• Faster Inter-L3 Messaging: L3s on the same L2 can communicate more swiftly and cheaply.
• Atomic Transactions: Transactions across L3s can be made atomic through the L2, enhancing transaction reliability.
• Increased Reversion Risk: If the L2 faces issues or needs to revert, all dependent L3s could be affected.

This solution is ultimately not scalable, as the L2's VM will be a bottleneck for proof verification, as the VM requires a full consensus mechanism, meaning long-term storage, transaction verification, etc.

Layered Aggregation

Combining the benefits of L3s with simple proof aggregation, this method uses a minimal program on L2 designed specifically for running L3 messaging and proof aggregation:

• Scalable and Efficient: By focusing solely on essential functionalities, this model is more scalable than a full L2 VM.
• Maintains Light Consensus: Only a lightweight consensus mechanism is needed, reducing the computational overhead.

Economic Guarantees

To address the need for quicker interoperability, economic guarantees can be employed, allowing transaction roots to be calculated outside of the proof and imported ahead of proof verification:

• Optional Add-On: This method can be added to systems that need faster transaction finality but comes with increased risks.
  • This add-on can only work for L3s and Layered Aggregators.
• Risk of Reversion: If an invalid transaction is included, all interconnected rollups might need to revert, as generating valid proofs would be impossible.

Sovereignty

ZK chains retain sovereignty, meaning they can opt in or out of proof aggregation:

• Optional Participation: ZK chains may choose not to participate in aggregation, opting instead to settle directly to Ethereum, albeit at higher costs.
• Decentralized Aggregation Access: Aggregation remains accessible and decentralized, ensuring low hardware requirements for provers.

Feature comparison

Different aggregation methods offer various advantages and considerations:

	Aggregation	L3s	Layered Aggregation
Fast Messaging	No	Yes	Yes
Scales	Yes	No	Yes
Consensus Mechanism	None	L2 Full Consensus	Lightweight Consensus
Instant Messaging Add-on	No	Yes	Yes
Sovereign	Yes	Yes	Yes

---

Modularity: ZK chain customization

The ZK Stack offers a wide array of customization options for developers looking to tailor ZK chain to specific needs or create entirely new blockchain architectures. This modular approach allows for significant flexibility in configuring transaction sequencing, data availability policies, and privacy features. Below, we explore these customization options in detail.

Sequencing transactions

• Centralized sequencer - Utilizes a single operator to quickly confirm transactions, ideal for high-frequency trading (HFT) but requires trust in the operator’s reliability and integrity.
• Decentralized sequencer - Employs a consensus algorithm to determine transaction inclusion, enhancing security and decentralization but potentially at the cost of higher latency. It can be any algorithm, so developers can reuse existing implementations (e.g. Tendermint or HotStuff with permissionless dPoS).
• Priority queue - Allows transactions to be submitted directly via an L2 or L1 priority queue, enhancing censorship resistance, particularly useful for governance protocols. It’s worth noting that the priority queue will always be available as an escape-hatch mechanism (even if a centralized or decentralized sequencer is employed), to protect users against censorship by a malicious sequencer.
• External protocol - Offers freedom to integrate any external sequencing protocols, providing further flexibility and potential integration with existing systems. External protocols such as Shared Sequencers and Shared Builders can be used.

Data Availability (DA)

Data Availability (DA) is a critical component in ensuring the security and functionality of ZK chain. It governs how transaction data is managed and made accessible, impacting everything from user privacy to transaction speed and cost. Below, we detail the various DA options available to developers using the ZK Stack, each tailored for specific security, privacy, and scalability needs.

zk-Rollup

zk-Rollup is the recommended DA policy for most ZK chain. It ensures that the values of every changed storage slot are published as calldata (or blobs, depending on what's cheaper) on Ethereum's Layer 1 (L1). This approach benefits from:

• Amortization of Costs: Changes that net to zero are not posted, reducing unnecessary data and saving costs.
• Inherited Security: Adopts the full security and censorship-resistance properties of Ethereum, providing robust protection against potential attacks.

zkPorter

zkPorter is detailed extensively in this informative post. Key aspects include:

• Cost Efficiency: Designed for users seeking lower transaction costs, potentially at the expense of higher security risks.
• Guardian Networks: Developers can utilize the ZKsync main zkPorter implementation, establish their own guardian network, or integrate external DA solutions like EigenDA.

Validium

Validium offers a privacy-oriented solution ideal for enterprise applications that require both auditability and confidentiality. Its key characteristics are:

• Controlled DA: The hosting organization controls data availability, which can easily be restricted to maintain privacy.
• Simpler Implementation: As a simpler variant of zkPorter, Validium allows for straightforward deployment but is generally discouraged for mainstream use due to its trust assumptions.

Based zkRollup

Based zkRollup requires the publication of full transaction inputs instead of just final storage updates, resembling the DA approach used in optimistic rollups:

• State Reconstruction: Allows for trustless state verification and reconstruction, similar to optimistic rollups but with the benefits of zkRollups.
• Application Specific: Best suited for chains where transactions may trigger extensive data changes, such as those involving complex financial simulations.

zkRollup (Self-hosted)

zkRollup (Self-hosted) represents an innovative approach where users manage their own data:

• User-hosted Data: Users store all relevant data for their accounts, significantly enhancing privacy and reducing on-chain data requirements.
• Minimal Data Footprint: Potentially reduces the data footprint to as little as 5 bytes per user interaction, drastically scaling potential.
• Complex Implementation: While offering tremendous benefits, this option requires sophisticated technical solutions to manage user interactions smoothly and securely.

Logical state partitions in ZK Porters

Logical state partitions within ZK Porters offer a powerful way for ZK chain to manage and interact with distinct subsets of their state in a synchronized manner. This modular architecture not only increases the efficiency and scalability of operations but also introduces advanced functionalities such as atomic transactions and state interoperability between partitions.

Synchronicity is important as it enables atomic transactions between partitions, unlocking several unique use cases:

• Transparently reading the state of another partition.
• Using flash loans between the partitions.

One prominent example of this is a combination of zkRollup + zkPorter:

Privacy

ZK chains support various methods to enhance privacy:

• Validium Mode: Naturally provides privacy as long as the data is kept confidential by the operator.
• Privacy Protocols: Specialized L3 protocols like Aztec or Tornado can be integrated to provide user-level privacy while benefiting from ZKsync Era’s features like account abstraction.
• Self-hosted Rollups: Represent a long-term solution for privacy and scalability, where users manage their data and confirm state transitions off-chain.