Will ZK eat the modular stack?

Author: Hannes Huitula; Translator: Plain Language Blockchain

1. What is blockchain and how does it extend the current computing paradigm?

Blockchain (noun): A coordination machine that enables participants from all over the world to collaborate under a set of commonly agreed rules without the need for any third party to facilitate.

Computers are designed to do three things: store data, calculate, and communicate with other computers and humans. Blockchain adds a fourth dimension: additional guarantees that these three things (storage, calculation, and communication) occur in the agreed manner. These guarantees allow strangers to cooperate without the need for a trusted third party to facilitate (decentralization).

These additional guarantees can be economic (based on trust game theory and incentive/penalty mechanisms) or cryptographic (based on mathematical trust), but most applications leverage a combination of both - cryptoeconomics. This is in stark contrast to current systems that are primarily based on reputation.

While Web3 is often described as "read, write, own", we believe that a better concept for the third evolution of the Internet should be "read, write, verify" because the key advantage of public blockchains is guaranteed computing and easily verifying that these guarantees are being followed. Ownership can be a subset of guaranteed computing if the digital products we build can be bought, sold and controlled. However, many blockchain use cases benefit from guaranteed computing but do not directly involve ownership. For example, in a game that is entirely on-chain, if your health is 77/100, do you own that health, or is it just enforceable on-chain according to the mutually agreed-upon rules?

Web3 = Read, Write, Verify

2. ZK and Modularity - Two Trends That Will Accelerate

Blockchains offer a lot of excitement, but decentralized models also add overhead and inefficiencies through additional features such as P2P communication and consensus. In addition, most blockchains still verify correct state transitions through re-execution, which means that every node on the network must re-execute transactions to verify the correctness of the proposed state transition. This creates waste and is in stark contrast to the centralized model, where only one entity executes. While decentralized systems always contain some overhead and replication, the goal should be to converge to a centralized benchmark in efficiency.

While infrastructure has improved significantly over the past decade, there is still much work to be done before blockchains can handle internet-level scale. We see tradeoffs along two main axes—expressiveness and difficulty—and believe that modularity enables rapid experimentation on the tradeoff frontier, and that zero-knowledge proofs extend that frontier:

Expressiveness—What guarantees can you create? Including scalability (cost, latency, throughput, etc.), privacy (or information flow management), programmability, and composability.

Difficulty—How hard are these guarantees to achieve? Including security, decentralization, and user and code safety.

Modularity is the degree to which system components can be separated and recombined. Modularity enables faster experimentation and specialization, with faster feedback loops and lower barriers to entry, requiring less capital (economic and human). The question between modularity and integration is not binary, but a spectrum of experimentation to figure out which parts should be decoupled and which should not.

On the other hand, Zero Knowledge Proofs (ZKPs) enable one party (the prover) to prove to another party (the verifier) ​​that they know something is true, without revealing any additional information other than its validity. This can increase scalability and efficiency by avoiding re-execution (moving from all executions verifying to one execution, all verifications), while increasing expressiveness by enabling privacy (subject to restrictions). ZKPs increase the difficulty of guarantees by replacing weaker cryptoeconomic guarantees with stronger ones, which is represented by pushing the trade-off frontier outward (refer to the diagram above).

We believe that modularity and “zero-knowledge proofs in everything” are trends that will continue to accelerate. While both provide interesting perspectives to explore the field, we are particularly interested in the intersection of the two. Two key questions we are interested in are:

1) Which parts of the modular stack have already incorporated zero-knowledge proofs, and which are yet to be explored?

2) What problems can zero-knowledge proofs solve?

However, before we dive into these questions, we need to have an updated perspective on the modular stack in 2024.

3. The Modular Stack in 2024

The commonly used image of a modular stack consisting of four components (execution, data publishing, consensus, settlement) is useful for simple mental models, but we feel that this is no longer a sufficiently accurate representation because the modular field has been developing very rapidly. Further deconstruction has led to new components that were previously considered parts of larger parts, while also creating new dependencies that require secure interoperability between different components (we will talk about this in detail later). Given the speed of development in this field, it can be difficult to keep up with all the innovations at different levels of the stack.

Earlier attempts to explore the web3 stack include what Kyle Samani (Mult1C0in) first published in 2018 and updated in 2019. It covers everything from decentralized last-mile internet access (such as Helium) to end-user key management. While the principles may be reusable, some parts, such as proofs and verification, are completely missing.

With these considerations in mind, in 2024 we attempted to create an updated representation of the modular stack, expanding upon the existing four-part modular stack. It is segmented by component rather than function, meaning that peer-to-peer networking, for example, is included in consensus rather than splitting it into separate components — primarily because it’s difficult to build protocols around it.

4. Zero-Knowledge Proofs (ZK) in the Modular Stack

Now that we have an updated perspective on the modular stack, we can start focusing on the real question of which parts of the stack ZK has permeated, and which unsolved problems (whether it’s re-execution avoidance or privacy features) can be solved by introducing ZK. Before we dive into each component, here’s a summary of our findings.

1) User Operation Abstraction

Current blockchain users need to navigate between multiple chains, wallets, and interfaces, which is cumbersome and becomes a friction for wider adoption. User operation abstraction is an umbrella term used to try to abstract this complexity so that users only need to interact with one interface (such as a specific application or wallet), and all the complexity happens on the backend. Some examples of base-level abstraction include:

Account Abstraction (AA) enables smart contracts to conduct transactions without requiring user signatures for each operation ("programmable crypto accounts"). It can be used to define who can sign (key management), what to sign (transaction payload), how to sign (signature algorithm), and when to sign (transaction approval conditions). The combination of these features enables things like using social login to interact with dApps, two-factor authentication (2FA), account recovery, and automation (automatically signing transactions). While discussions often focus on Ethereum (ERC-4337 passed in spring 2023), many other chains already have native account abstraction built in (Aptos, Sui, Near, ICP, Starknet, and zkSync). Chain abstraction allows users to sign transactions on different chains while interacting with only one account (one interface, multiple chains). Many teams are working on this, including Near, ICP, and dWallet. These solutions leverage MPC and chain signatures, where the private keys of other networks are split into several small parts and shared among validators on the source chain, who sign cross-chain transactions. When a user wants to interact with another chain, a sufficient number of validators are required to sign the transaction to meet the threshold cryptography. This preserves security because the private keys are never fully shared anywhere. But it does face the risk of collusion among validators, which is why the cryptoeconomic security of the underlying chain and the decentralization of validators are still very relevant.

Intents, at a high level, translate user wishes and needs into actions that can be performed by the blockchain. This requires intent resolvers - specialized off-chain agents responsible for finding the best solution to a user's intent. There are already several applications that use specialized intents, such as DEX aggregators ("best price") and bridge aggregators ("cheapest/fastest bridge"). Generalized intent settlement networks (Anoma, Essential, Suave) aim to make it easier for users to express more complex intents and enable developers to build intent-centric applications. However, there are still many unresolved problems, including how to formalize this process, what an intent-centric language would look like, whether there is always an optimal solution, and how to find it.

Existing ZK Integrations

AA x ZK Authentication: An example is Sui's zkLogin, which allows users to log in using familiar credentials such as email addresses. It uses ZKPs to prevent third parties from associating Sui addresses with their corresponding OAuth identifiers.

More Efficient Signature Verification for AA Wallets: Verifying transactions in AA contracts can be significantly more expensive than transactions initiated by legacy accounts (EOAs). Orbiter attempts to address this with a bundled service that leverages ZKPs to verify the correctness of transaction signatures and maintain nonce values ​​and gas balances for AA accounts (via a Merkle world state tree). This can achieve significant cost savings through proof aggregation and evenly distributing on-chain verification costs to all users.

Open Problems ZKPs May Solve

Proof of Best Execution or Intent to Fulfill: While intent and AAs can abstract complexity from users, they can also act as a centralized force and require us to rely on dedicated actors (solvers) to find the best execution path. Rather than simply trusting the goodwill of the solver, ZKPs could potentially be used to prove that the best path for a user was chosen among the paths sampled by the solver.

Privacy protection for intention settlement: Protocols like Taiga aim to implement fully protected intention settlement functionality to protect the privacy of users - this is part of a broader movement in adding privacy (or at least confidentiality) to blockchain networks. It uses ZKPs (Halo2) to hide sensitive information about state transitions (application type, parties involved, etc.).

Password recovery for AA wallets: The idea of ​​this proposal is to enable users to recover their wallets when they lose their private keys. By storing hashes (passwords, nonce) on the contract wallet, users can generate a ZKP with the help of their password to verify that this is their account and request a change of private keys. The confirmation period (3 days or more) is used as a safeguard against unauthorized access attempts.

2) Ordering

Before being included in a block, transactions need to be ordered, which can be achieved in a variety of ways: ordering by proposer profitability (highest paying transactions first), ordering by order of submission (first in, first out), giving priority to transactions from private memory pools, etc.

Another question is who orders the transactions. In a modular world, there are multiple different parties that can do this, including rolling packers (centralized or decentralized), L1 ordering (based on rolling packing), and shared ordering networks (decentralized ordering networks used by multiple rolling packs). All of these have different trust assumptions and scaling capabilities. In practice, the actual ordering and packaging of transactions into blocks can also be done outside the protocol by dedicated parties (block builders).

Existing ZK Integration

Verify that the memory pool is correctly encrypted: Radius is a shared ordering network with encrypted memory pools with Practical Verifiable Delayed Encryption (PVDE). The user generates a ZKP that proves that solving the timelock puzzle will lead to the correct decryption of a valid transaction, i.e., the transaction includes a valid signature and nonce, and the sender has enough balance to pay the transaction fee.

Open problems that ZKPs may solve

Verifiable Sorting Rules (VSR): Subject the proposer/sequencer to a set of rules about the order of execution, with additional guarantees that these rules are followed. Verification can be done through ZKPs or fraud proofs, the latter of which requires a sufficiently large economic bond that is slashed if the proposer/sequencer misbehaves.

3) Execution (Extended Writes)

The execution layer contains the logic of state updates and is where smart contracts are executed. In addition to returning the results of the computation, zkVMs are also able to prove whether the state transition was executed correctly. This allows other network participants to verify the correct execution by verifying only the proof, without having to re-execute the transaction.

Besides faster and more efficient verification, another benefit of provable execution is the ability to do more complex computations, since you don’t run into the typical issues of gas and limited on-chain resources. This opens the door to entirely new applications that are more computationally intensive to run on the blockchain and take advantage of guaranteed computation.

Existing ZK Integrations

zkEVM Rolling Wrapper: A special type of zkVM optimized to be compatible with Ethereum and to prove the EVM execution environment. However, the higher the compatibility with Ethereum, the greater the performance tradeoff. Several zkEVMs were launched in 2023, including Polygon zkEVM, zkSync Era, Scroll, and Linea. Polygon recently announced the launch of their type 1 zkEVM prover, which can prove mainnet Ethereum blocks at a price of $0.20-$0.50 per block (upcoming optimizations will further reduce costs). RiscZero also has a solution that can prove Ethereum blocks, but it is more expensive and has limited benchmarks.

Alternative zkVMs: Some protocols have chosen an alternative path, optimizing for performance/provability (Starknet, Zorp) or developer friendliness rather than trying to maximize compatibility with Ethereum. Examples of the latter include zkWASM protocols (Fluent, Delphinus Labs) and zkMOVE (M2 and zkmove).

Privacy-focused zkVMs: In this case, ZKPs are used for two purposes: avoiding re-execution and achieving privacy. While the privacy that can be achieved with ZKPs alone is limited (only individual private state), upcoming protocols add a lot of expressiveness and programmability to existing solutions. Examples include Aleo's snarkVM, Aztec's AVM, and Polygon's MidenVM.

ZK Coprocessors: Allow on-chain computation on off-chain data (but without state). ZKPs are used to prove correct execution and settle faster than optimistic coprocessors, but there is a trade-off in cost. Given the cost and/or difficulty of generating ZKPs, we are seeing some hybrid versions, such as Brevis coChain, that allow developers to choose between ZK or optimistic mode (trading off between cost and difficulty of guarantees).

Open Problems ZKPs May Solve

Incorporation into zkVM: Most base layers (L1s) still use re-execution to verify correct state transitions. Incorporating zkVM into the base layer would avoid this as validators can verify proofs. This would increase operational efficiency. Most of the focus has been on Ethereum, which hopes to have a base layer that incorporates zkEVM, but many other ecosystems also rely on re-execution.

zkSVM: While SVM is primarily used in Solana L1 today, teams like Eclipse are experimenting with leveraging SVM for rollovers settled on Ethereum. Eclipse also plans to use Risc Zero for ZK fraud proofs in SVM to address potential challenges with state transitions in SVM. However, a full zkSVM has not been explored yet — probably due to the complexity of the problem and the fact that SVMs are optimized for things other than provability.

4) Data Querying (Read Scaling)

Data querying, or reading data from the blockchain, is an important component of most applications. While much of the discussion and effort in recent years has focused on scaling writes (executions), scaling reads is more important due to the imbalance between the two (especially in a decentralized setting). The read/write ratio varies between blockchains, but one data point is Sig’s estimate that over 96% of all calls to nodes on Solana are read calls (based on 2 years of empirical data) — a read/write ratio of 24:1.

Scaling reads includes improving performance (more reads per second) through dedicated validator clients (like Sig on Solana) and enabling more complex queries (combining reads with computations), such as with the help of coprocessors.

Another angle is a decentralized approach to data querying. Today, most data query requests in blockchains are handled by trusted third parties (based on reputation), such as RPC nodes (Infura) and indexers (Dune). Examples of more decentralized options include The Graph and storage proof operators (also verifiable). There are also attempts to create decentralized RPC networks, such as Infura DIN or Lava Network (in addition to decentralized RPC, Lava also plans to provide additional data access services in the future).

Existing ZK Integration

Storage Proof: Allows querying historical and current data from the blockchain without using a trusted third party. ZKPs are used to compress and prove that the correct data has been retrieved. Examples of projects being built in this space include Axiom, Brevis, Herodotus, and Lagrange.

Open Problems ZKPs May Solve

Efficient querying of private state: Privacy projects often use a variation of the UTXO model, which has better privacy properties than the account model, but at the expense of developer friendliness. The private UTXO model can also lead to synchronization issues - Zcash has been working on this issue since 2022 after experiencing a significant increase in private transactions. Wallets must be synchronized with the chain before being able to spend funds, so this is a very fundamental challenge for the operation of the network. In anticipation of this problem, Aztec recently issued an RFP for ideas for note discovery, but no clear solution has been found yet.

5) Proof

As more and more applications incorporate ZKPs, proof and verification are quickly becoming an important part of the modular stack. However, most proof infrastructure today is still permissioned and centralized, and many applications rely on a single prover.

While centralized solutions are less complex, decentralizing the proof architecture and splitting it into a separate component in a modular stack brings several benefits. One of the key benefits is liveness guarantees, which is critical for applications that rely on frequent proof generation. Users also benefit from greater censorship resistance and lower fees due to contention and sharing the workload across multiple attesters.

We believe that a general-purpose attester network (many applications, many attesters) is superior to a single-application attester network (one application, many attesters) because it more efficiently utilizes existing hardware and is less complex for attesters. Higher utilization also benefits users with lower fees, as attesters do not need to compensate for redundancy with higher fees (fixed costs still need to be covered).

Figment Capital has a great overview of the current proof supply chain landscape, which includes proof generation and proof aggregation (essentially proof generation, but just taking two proofs as input instead of execution traces).

Existing ZK Integration

STARK and SNARK Wrapping: STARK provers are fast and do not require a trusted setup, but the downside is that the large proofs they produce are expensive to verify on Ethereum L1. Wrapping a STARK in a SNARK as the last step can significantly reduce the cost of verification on Ethereum. However, doing so increases complexity, and the security of such a "composite proof system" has not been studied in depth. Examples of existing implementations include Polygon zkEVM, Boojum in zkSync Era, and RISC Zero.

General-purpose decentralized proof networks: Integrating more applications into decentralized proof networks can make it more hardware-efficient for provers (higher hardware utilization) and cheaper for users (no need to pay for hardware redundancy). Projects in this area include Gevulot and Succinct.

Open problems that ZKPs may solve

ZK fraud proofs: In optimistic solutions, anyone can challenge a state transition and create a fraud proof during the challenge. However, verifying fraud proofs is still quite tedious because it is done by re-execution. ZK fraud proofs aim to solve this problem by creating a proof of the state transition that is being challenged, resulting in more efficient verification (no need to re-execute) and potentially faster settlement. At least Optimism (in collaboration with O1 Labs and RiscZero) and AltLayer x RiscZero are working on this problem.

More efficient proof aggregation: A great feature of ZKPs is that you can aggregate multiple proofs into a single proof without significantly increasing the verification cost. This makes it possible to spread the verification cost over multiple proofs or applications. Proof aggregation is also a proof, but the input is two proofs instead of an execution trace. Examples of projects in this space include NEBRA and Gevulot.

6) Data Publication (Availability)

Data Publication (DP) ensures that data is available and easily retrievable within a short period of time (1-2 weeks). This is critical for safety (optimistic Rollups require input data to verify correct execution by re-executing during challenges, which last 1-2 weeks) and liveness (even if the system uses proofs of validity, data may be required to prove asset ownership for escape hatches or forced transactions). Users (like zk-bridges and Rollups) need to make a one-time payment to cover the cost of storing transactions and state until the data is deleted. Data publishing networks are not designed for long-term data storage (see the next section for possible solutions). Celestia was the first project to launch its mainnet as an alternative DP layer (October 31st), but with projects like Avail, EigenDA, and Near DA expected to launch in 2024, there will soon be many alternatives to choose from. In addition, Ethereum's EIP 4844 upgrade improves the efficiency of data publishing on Ethereum (while creating a separate fee market for Blob storage) and paves the way for full tank sharding. DP is also expanding to other ecosystems - one example is Nubit, which aims to build native DP on Bitcoin.

Many DP solutions also offer services beyond pure data publishing, including shared security for sovereign Rollups (such as Celestia and Avail) or smoother interoperability between Rollups (such as Avail's Nexus). There are also projects (such as Dom1C0n and Zero Gravity) that provide data publishing as well as long-term state storage, which is a compelling proposal. This is also an example of re-bundling two components in a modular stack, which is something we may see more of in the future (experiments with further unbundling and re-bundling).

Existing ZK Integration

Verify the correctness of erasure codes: Erasure codes introduce a level of redundancy so that the original data is recoverable even if part of the encoded data is unavailable. This is also a prerequisite for decentralized storage (DAS), where light nodes only sample a small fraction of blocks to probabilistically ensure that the data exists. If a malicious proposer encodes the data incorrectly, the original data may not be recoverable even if the light node samples a sufficient number of unique blocks. Verifying correct erasure codes can be done using validity proofs (ZKPs) or fraud proofs, the latter of which suffers from delays associated with challenge periods. All other solutions except Celestia are using validity proofs.

Data bridge provided by ZK light clients: Rollups that use an external data publishing layer still need to notify the settlement layer that the data has been published correctly. This is where the data authentication bridge comes in. Using ZKPs makes the verification of source chain consensus signatures on Ethereum more efficient. The data authentication bridges for Avail (VectorX) and Celestia (BlobstreamX) are both powered by a ZK light client built in partnership with Succinct.

Celestia Integrates Proofs of Validity to Verify Correct Erasure Coding: Celestia is currently an outlier among data publishing networks in that it uses fraud proofs to verify correct erasure coding. If a malicious block proposer incorrectly encodes data, any other full node can generate a fraud proof and dispute it. While this approach is relatively simple to implement, it also introduces latency (blocks are finalized only after the fraud proof window) and requires light nodes to trust an honest full node to generate the fraud proof (which they cannot verify on their own). However, Celestia is exploring ways to combine their current Reed-Solomon encoding with ZKPs to prove correct encoding, which would significantly reduce finality. The latest discussion on this topic can be found here, which includes notes from previous working groups (in addition to more general attempts to add ZKPs to Celestia's base layer).

ZK-Proof DAS: Some exploration has been done in the area of ​​ZK-Proof Data Availability, where light nodes only need to verify Merkle roots and ZKPs without having to do regular sampling by downloading small blocks of data. This would further reduce the requirements for light nodes, but it seems that development has stagnated.

7) Long-term (state) storage

Storing historical data is mainly important for synchronization purposes and responding to data requests. However, not every full node is able to store all data, and most full nodes prune old data to keep hardware requirements reasonable. Instead, we rely on specialized parties (archive nodes and indexers) to store all historical data and provide data when users request it.

In addition, there are decentralized storage providers, such as Filecoin or Arweave, that provide affordable long-term decentralized storage solutions. While most blockchains do not have a formal archival storage process (relying only on someone to store it), decentralized storage protocols are a good choice for storing historical data and adding a certain amount of redundancy (at least X nodes store the data) through incentive mechanisms built into the storage network.

Existing ZK Integration

Proof of Storage: Long-term storage providers need to generate ZKPs periodically to prove that they have stored all the data they claim. An example is Filecoin's Proof of Spacetime (PoSt), where storage providers receive block rewards every time they successfully answer a PoSt challenge.

Problems that ZKPs Can Solve

Proof of Data Origin and Authorization to View Sensitive Data: For two untrusting parties who want to exchange sensitive data, ZKPs can be used to prove that one party has the credentials necessary to view the data without uploading the actual file or revealing passwords and login details.

8) Consensus

Given that blockchains are distributed P2P systems, there is no trusted third party to decide the global truth. Instead, nodes in the network reach a consensus on the current truth (which block is correct) through a mechanism called consensus. PoS-based consensus methods can be divided into BFT-based (where a Byzantine Fault Tolerant group of validators decides the final state) or chain-based (where the final state is determined retroactively through a fork choice rule). While most existing PoS consensus implementations are BFT-based, Cardano is an example of a longest chain implementation. There is also growing interest in DAG-based consensus mechanisms, such as Narwhal-Bullshark, which is implemented in different forms in projects such as Aleo, Aptos, and Sui.

Consensus is a key part of many different components in the modular stack, including shared sequencers, decentralized proofs, and blockchain-based data publishing networks (not committee-based, such as EigenDA).

Existing ZK Integration

Staking in ZK Privacy Networks: PoS-based privacy networks present a challenge in which people holding staked tokens must choose between privacy and participating in consensus (and earning staking rewards). Penumbra aims to solve this problem by eliminating staking rewards and instead treating unstaked and staked stakes as different assets. This approach keeps individual delegations private while the total amount staked by each validator remains public.

Private Governance: Enabling anonymous voting has long been a challenge in the cryptocurrency space, with projects such as Nouns Private Voting attempting to advance this. The same is true for governance, with Penumbra at least working on anonymous voting on proposals. In this case, ZKPs can be used to prove that someone has the right to vote (e.g. through token ownership) and that certain voting criteria have been met (e.g., a vote has not yet been cast).

Private leader election: Ethereum currently elects the next 32 block proposers at the beginning of each epoch, and the results of this election are public. This creates a risk that a malicious party could launch a DoS attack against each proposer in turn in an attempt to bring Ethereum down. To address this, Whisk proposes a privacy-preserving protocol for electing block proposers on Ethereum. Validators use ZKPs to prove that shuffling and randomization were done honestly. There are other ways to achieve similar goals, some of which are covered in this blog post from a16z.

Signature aggregation: Using ZKPs to aggregate signatures can significantly reduce the communication and computational overhead of signature verification (verifying an aggregate proof instead of each individual signature). This is already being exploited in ZK light clients, but could also be extended to consensus.

9) Settlement

The Settlement is similar to the Supreme Court - the final source of truth that verifies the correctness of state transitions and resolves disputes. A transaction is considered final at the point where it is irreversible (or in the case of probabilistic finality, at the point where it is sufficiently difficult to reverse). The time required for finality depends on the underlying settlement layer used, which in turn depends on the specific finality rules and block times used.

Slow finality is particularly problematic in cross-Rollup communication, as Rollups need to wait for confirmations from Ethereum before approving transactions (7 days for optimistic Rollups; 12 minutes and verification time for validity Rollups). This results in a poor user experience. There are currently multiple efforts to address this issue, including ecosystem-specific solutions with pre-confirmations that have a certain level of security (such as Polygon AggLayer or zkSync HyperBridge) and general solutions such as Near's Fast Finality Layer, which aims to connect multiple different Rollup ecosystems by leveraging the economic security of EigenLayer. Another option is to use EigenLayer for local Rollup bridges with soft confirmations to avoid waiting for full finality.

Existing ZK Integration

Fast Settlement with Validity Rollup: Unlike Optimistic Rollup, Validity Rollup does not require a challenge period because they rely on ZKP to prove the correct state transition regardless of whether someone raises a challenge (Pessimistic Rollup). This makes settlement on the base layer faster (12 minutes compared to 7 days on Ethereum) and avoids re-execution.

10) Security

Security is related to the difficulty of guaranteeing and is a key part of the value proposition of blockchain. However, bootstrapping cryptoeconomic security is difficult, which increases barriers to entry and creates friction for innovation for those applications that need it (various middleware and alternative L1s).

The idea of ​​shared security is to leverage the economic security of existing PoS networks and subject them to additional risk of staking (penalty conditions), rather than each component trying to bootstrap its own security. Similar approaches have been tried in PoW networks (merged mining), but the misaligned incentives make it easier for miners to collude and manipulate the protocol (it’s hard to punish bad behavior because the work happens in the physical world, i.e. mining using computational power). PoS security is more flexible and can be used by other protocols because it has both positive (staking yield) and negative (staking reduction) incentives.

Protocols built around shared security include:

EigenLayer aims to leverage existing Ethereum security to protect a variety of applications. The whitepaper was released in early 2023, and EigenLayer is currently in mainnet testing, with a full mainnet expected to launch later this year.

Cosmos launched its Interchain Security (ICS) in May 2023, which enables the Cosmos Hub (one of the largest chains on Cosmos, backed by about $2.4 billion in staked ATOM) to rent its security to consumer chains. By using the same set of validators that power the Cosmos Hub to validate blocks on consuming chains, it aims to lower the barrier to launching new chains on top of the Cosmos stack. However, only two consuming chains are currently active (Neutron and Stride).

Babylon is also trying to enable Bitcoin to be used for shared security. To address the issues associated with merged mining (difficulty in punishing bad behavior), it is building a virtual PoS layer where users can lock Bitcoin in a staking contract on Bitcoin (without a bridge). Since Bitcoin has no smart contract layer, the staking contract's redeposit rules are expressed in the form of UTXO transactions in Bitcoin Script.

Other restaking on networks include Octopus on Near and Picasso on Solana. Polkadot's parachains also leverage the concept of shared security.

Existing ZK Integration

Hybrid of ZK and Economic Security: While ZK-based security guarantees may be stronger, proofs are still too costly and take too long to generate for some applications. An example is Brevis coChain, a coprocessor that derives economic security from ETH re-stakeholders and optimistically guarantees computation (via ZK fraud proofs). dApps can choose between pure ZK mode and coChain mode based on their specific needs for security and cost tradeoffs.

11) Interoperability

In a multi-chain world, secure and efficient interoperability remains a significant issue, as evidenced by the $2.8 billion lost in the bridge hack. In modular systems, interoperability becomes even more important - not only do they need to communicate between other chains, but modular blockchains also need different components to communicate with each other (such as DAs and settlement layers). Therefore, simply running a full node or verifying a single consensus proof, as the integrated blockchains do, is no longer feasible. This adds more variables to the equation.

Interoperability includes token bridging and more general messaging between blockchains. There are currently several different options, all of which make different trade-offs in terms of security, latency, and cost. It is very difficult to optimize all three at the same time, and usually requires sacrificing at least one of them. In addition, different standards on different chains make it even more difficult to implement on new chains.

While we still lack a clear definition of the different types of light clients (or nodes), Fluent and Modular Media co-founder Dino provides a good introduction in this post. Most light clients today only verify consensus, but ideally we should have light clients that can verify both execution and DA to reduce trust assumptions. This would allow for close to full node security without the high hardware requirements.

Existing ZK Integration

ZK Light Clients (Consensus Verification): Most current light clients can verify the consensus of other chains - either the full validator set (if small enough) or a subset of the total validators (e.g. Ethereum's Sync Committee). ZKPs are used to speed up and reduce verification costs, as the signature scheme used on the original chain may not be natively supported on the target chain. While it is expected that the importance of ZK light clients in bridging will increase, the frictions encountered in current promotion include the cost of proof and verification, as well as implementing a ZK light client for each new chain. Examples of protocols in this space include Polyhedra, Avail, and Celestia's data confirmation bridge, and Electron Labs' zkIBC.

Proof of Storage: As mentioned earlier, proofs of storage make it possible to query historical and current data on a blockchain without the use of a trusted third party. This is also important for interoperability, as they can be used for cross-chain communication. For example, a user can prove that they own a token on one chain and use it for governance on another chain (without bridging). There are also solutions that attempt to use proof of storage for bridging, such as this one developed by LambdaClass.

ZK Oracle: Oracle acts as a middleman and bridges real-world data to the blockchain. ZK Oracle improves on the current reputation-based oracle model by being able to prove the origin and integrity of data, as well as any computations performed on the data.

Open Problems That Zero-Knowledge Proofs (ZKPs) Can Solve

A. Full Light Clients: Instead of blindly trusting the validator set of other chains - full light clients also verify correct execution and DA. This reduces trust assumptions and is close to full nodes while keeping hardware requirements low (allowing more people to run light clients). However, it is still too costly to verify anything other than consensus on most chains, especially on Ethereum. In addition, light clients are only able to verify information (half of the problem), i.e. they can identify if the information is wrong, but additional mechanisms are still needed for them to take action.

B. Aggregation Layer: Polygon's AggLayer aims to enable smooth interoperability between L2s within the ecosystem by leveraging aggregate proofs and unified bridge contracts. Aggregation proofs enable both more efficient verification and higher security - enforcing dependent chain states and bundles to be consistent, and ensuring that if a rollup state depends on an invalid state of another chain, the state cannot be resolved on Ethereum. zkSync’s HyperChains and Avail’s Nexus take a similar approach.

5. What happens when zero-knowledge proofs (ZKPs) eat the modular stack?

Suppose we can reach a state where generating ZKPs becomes very fast (almost close to the speed of light) and very cheap (almost free), what will the end result look like? In other words, what happens when ZKPs eat the modular stack?

Overall, we believe there are two real scenarios in this situation:

Eliminate all unnecessary re-executions: By moving to a 1/N execution model (rather than an N/N model with re-executions), we significantly reduce the overall redundancy of the network and achieve more efficient utilization of the underlying hardware. Although there is still some overhead, this will help blockchains asymptotically approach centralized systems in terms of computational efficiency.

Most applications rely on ZKP-enabled cryptographic guarantees rather than economic security: When the cost and time of generating proofs are no longer a relevant factor, we think most applications will rely on ZKPs for stronger guarantees. This will also require improvements in usability and developer-friendliness to build ZKP applications, but these are issues that multiple teams are working on.

The third condition involves privacy (or information flow management), but this is more complicated. Using client-side proofs, ZKPs can be used for some privacy applications, and this is what platforms like Aleo, Aztec, or Polygon Miden are building, but achieving broad privacy protections to apply to all potential use cases also depends on progress in MPC and FHE - a potential topic for a future blog post.

6. Risks to our argument

What if we are wrong and the future is neither modular nor zero-knowledge? Some potential risks to our thesis include:

Modularity increases complexity

Both users and developers are impacted by the increasing number of chains. Users need to manage funds across multiple chains (and potentially multiple wallets). Application developers, on the other hand, face less stability and predictability as the space is still evolving, making it harder to decide which chain to build applications on. They also need to consider fragmentation of state and liquidity. This is especially true now as we are still exploring which components are suitable for decoupling and which will be recoupled. We believe that abstraction of user operations and secure and efficient interoperability solutions are key parts of solving this problem.

Will ZK be efficient enough?

In any case, proof generation is too time-consuming, and the cost of proof and verification today is still too high. For many applications, competing solutions such as Trusted Execution Environments/TEEs (privacy) or optimistic/cryptoeconomic security solutions (cost) still make more sense today.

However, work is already underway on software optimization and hardware acceleration of ZKPs. Proof aggregation will further reduce the cost of verification by spreading the cost across multiple different parties (lower cost/users). There is also the potential to tweak the base layer to more optimally verify ZKPs. One challenge with hardware acceleration of ZKPs is the rapid evolution of proof systems. This makes it difficult to create specialized hardware (ASICs) because they can quickly become obsolete if/when the standards of the underlying proof systems change.

Ingonyama attempts to create some benchmarks of prover performance through a comparable metric called the ZK score. It is based on the cost of running a computation (OPEX), and tracks MMOPS/WATT, where MMOPS stands for modular multiplication operations per second. For further reading on the topic, see Cysic and Ingonyama’s blog, and this talk by Wei Dai.

Is the privacy provided by limited ZKPs useful?

ZKPs can only be used to achieve privacy for individual state, not shared state where multiple parties need to compute on encrypted data (e.g. a private Uniswap). Full privacy also requires FHE and MPC, but will require significant improvements in cost and performance to become a viable option for wider use. That said, ZKPs are still useful for certain use cases that do not require private shared state, such as identity solutions or payments. Not all problems need to be solved with the same tool.

7. Conclusion

So, where does this leave us? While we are making progress every day, there is still a lot of work to be done. The most pressing problems to be solved are how to securely transfer value and information between different modular components without sacrificing speed or cost, and how to abstract all of this away so that end users don’t have to worry about bridging between chains, switching wallets, etc.

While we are still in an experimental phase, things should stabilize over time as we figure out where the best tradeoffs are for each use case. This in turn will provide room for standards (informal or formal) to emerge and provide more stability for those building on top of these chains.

There are still many use cases today that use cryptoeconomic security by default due to the cost and complexity of generating ZKPs, and some that require a combination of both. However, this share should decrease over time as we design more efficient proof systems and specialized hardware to reduce the cost and latency of proofs and verification. With each exponential reduction in cost and speed, new use cases will be unlocked.

While this post focuses on ZKPs, we are also increasingly interested in how modern cryptographic solutions (ZKPs, MPC, FHE, and TEEs) can work together, which is something we have already started to see.