What happens when zero-knowledge proof technology is fully integrated into a modular architecture?

Author: Hannes Huitula Source: equilibrium labs research Translation: Shan Ouba, Golden Finance

What are blockchains and how do they extend the current computing paradigm?

Blockchain (noun): A coordination machine that enables participants from all over the world to collaborate along a set of mutually agreed-upon rules without the assistance of any third party.

Computers are designed to do three things: store data, compute, and communicate with each other and with humans. Blockchains add a fourth dimension: additional guarantees that these three things (storage, computation, and communication) occur in the agreed-upon manner. These guarantees enable cooperation between strangers without the need for a trusted third party to facilitate (decentralization).

These additional guarantees can be economic (trust game theory and incentives/disincentives) or cryptographic (trust mathematics), but most applications leverage a combination of both - cryptoeconomics. This is in stark contrast to the current status quo of systems that are primarily based on reputation. While Web3 is often described as “read, write, own,” we believe a better concept for the third iteration of the internet is “read, write, verify,” because the primary benefit of public blockchains is guaranteed computation and easy verification that those guarantees are honored. If we build digital artifacts that can be bought, sold, and controlled, then ownership can become a subset of guaranteed computation. However, many use cases for blockchains benefit from guaranteed computation but do not directly involve ownership. For example, if your health is 77/100 in a fully on-chain game — do you own that health, or is it just enforced on-chain according to mutually agreed-upon rules? We would argue the latter, but Chris Dickson would probably disagree.

Web3 = Read, Write, Verify

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 like P2P messaging and consensus. Additionally, most blockchains still verify correct state transitions through re-execution, meaning that every node on the network must re-execute transactions to verify the correctness of proposed state transitions. This is wasteful and in stark contrast to centralized models where only one entity executes. While decentralized systems will always include some overhead and replication, the goal should be to gradually approach centralized benchmarks in terms of efficiency.

While the underlying infrastructure has improved significantly over the past decade, there is still a lot of work to be done before blockchains can handle Internet-level scale. We see tradeoffs along two main axes (expressiveness and hardness), and believe modularity enables faster experimentation along these tradeoff fronts while ZK scales it:

• Expressiveness - What guarantees can you make? This includes scalability (cost, latency, throughput, etc.), privacy (or information flow management), programmability, and composability.  

• Hardness - How hard are these guarantees? This includes security, decentralization, and user and code safety.

Modularity refers to the degree to which system components can be separated and recombined.  With faster feedback loops and lower barriers to entry and less capital requirements (economic and human) - modularity enables faster experimentation and specialization. The question of modularity vs. integration is not binary, but a series of experiments to find out which parts are suitable for decoupling and which are 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 beyond its validity. This can improve scalability and efficiency by avoiding re-execution (moving from an execute-all-to-verify model to an execute-once-and-verify-all model), and improve expressiveness by enabling privacy (with limitations). ZKPs also improve the hardness of guarantees by replacing weaker cryptoeconomic guarantees with stronger ones, which is manifested as pushing the tradeoff boundary outward (see the figure above). We believe that both modularity and “ZK-ing of Everything” are trends that will continue to accelerate. While both offer interesting perspectives to explore the space individually, we are particularly interested in the intersection of the two. Two key questions we are interested in are: Which parts of the modularity stack have already been incorporated into ZKPs, and which parts are yet to be explored? Which problems can ZKPs alleviate?

However, before discussing these issues, we need to get up to speed on what the modular stack looks like in 2024.

The Modular Stack in 2024

The commonly used image of a modular stack with four components (execution, data publication, consensus, settlement) is useful as a simple mental model, but given how much the modular space has evolved, we believe it is no longer an adequate representation. Further unbundling has resulted in new components that were previously thought of as part of a larger piece, while also creating new dependencies and the need for secure interoperability between different components (more on this later). Given the pace of development in the field, it is difficult to keep up with all the innovations at different levels of the stack.

Early attempts to explore the web3 stack include that of Kyle Samani (Multicoin) - originally published in 2018 and updated in 2019. It covers everything from decentralized last-mile internet access (e.g. Helium) to end-user key management. While the principles behind it can be reused, some parts, like proofs and verification, are completely missing. With this in mind, we tried to create an updated representation of the 2024 modular stack, expanding on the existing four-part modular stack. It is divided by component rather than functionality, meaning that things like P2P networking are included in consensus rather than splitting it out as a separate component - mainly because it is difficult to build a protocol around it. Now that we have an updated view of the modular stack, we can start looking at the real question of which parts of the stack ZK has already penetrated and which open problems (re-execution avoidance or privacy-features) can be solved by introducing ZK. Before diving into each component separately, here is a summary of our findings.

1 - User Operation Abstraction

Current blockchain users need to navigate multiple chains, wallets, and interfaces, which is cumbersome and hinders wider adoption. User Operation Abstraction is an umbrella term that refers to any attempt to abstract away this complexity and allow users to interact with only one interface (such as a specific application or wallet), while all the complexity happens on the backend. Some examples of low-level abstractions include:

• Account Abstraction (AA) enables smart contracts to conduct transactions without requiring a user signature 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 (signing algorithm), and when to sign (transaction approval conditions). Combined, these features enable features such as using social login to interact with dApps, 2FA, account recovery, and automation (automatically signing transactions). While discussions often revolve around Ethereum (ERC-4337 passed in spring 2023), many other chains already have built-in native account abstractions (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). Multiple teams are working on this, including Near, ICP, and dWallet. These solutions utilize MPC and chain signatures, where the private key of another network is 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 threshold encryption. This preserves security, as private keys are never fully shared anywhere. However, it does face the risk of validator collusion, which is why the cryptoeconomic security of the underlying chain and validator decentralization remain highly relevant.

• At a high level, intents can connect user needs with actions that the blockchain can perform. This requires intent resolvers - specialized off-chain agents whose task is to find the best solution for a user's intent. There are already some applications that use specialized intents, such as DEX aggregators ("best price") and bridge aggregators ("cheapest/fastest bridge"). General intent settlement networks (Anoma, Essential, Suave) aim to make it easier for users to express more complex intents, and for developers to build intent-centric applications. However, there are still many open questions, including how to formalize the process, what an intent-centric language looks like, and whether optimal solutions always exist and can be found.

Existing ZK Integrations

• Authentication with AA x ZK: One example is Sui’s zkLogin, which enables users to log in with familiar credentials such as an email address. It uses ZKP to prevent third parties from linking a Sui address to its corresponding OAuth identifier.  

• More efficient signature verification for AA wallets: Verifying transactions in AA contracts can be much more expensive than transactions initiated by legacy accounts (EOAs). Orbiter seeks to address this by bundling a service that leverages ZKP to verify the correctness of transaction signatures and maintain the nonce and gas balance of AA accounts (via a Merkle world state tree). This can result in significant cost savings thanks to proof aggregation and evenly amortizing the on-chain verification costs across all users.

Open Problems ZKPs Can Solve

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

• Privacy of Intent Settlement: Protocols like Taiga aim to enable fully shielded intent settlement to preserve the privacy of users - part of a broader move to add 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 behind this proposal is to enable users to recover their wallets if they lose their private keys. By storing hashes (passwords, random numbers) on the contract wallet, users can cryptographically generate ZKPs to verify that this is their account and request a change of private keys. Confirmation periods (3 days or more) prevent unauthorized access attempts.

2 - Sequencing

Transactions need to be sorted before being added to a block, which can be done in a number of ways: by proposer profitability (highest paying transactions first), by order of submission (first in, first out), giving priority to transactions from private memory pools, etc.  

Another question is who can order transactions. In the modular world, multiple different parties can do this, including rollup sorters (centralized or decentralized), L1 sorters (rollup-based), and shared sorting networks (decentralized networks of sorters used by multiple rollups). All of these have different trust assumptions and scaling capabilities. In practice, the actual ordering of transactions and bundling them into a block can also be done outside of the protocol by dedicated participants (block builders). Existing ZK Integrations Verify Correct Encryption of Mempool: Radius is a shared sorting network with an encrypted mempool using Practical Verifiable Delayed Cryptography (PVDE). Users generate a ZKP that proves that solving the timelock puzzle will result in the correct decryption of a valid transaction, i.e., the transaction contains a valid signature and nonce, and the sender has enough balance to pay the transaction fee.

Open Problems ZKPs Can Solve

• Verifiable Sorting Rules (VSRs): Make proposers/sequencers adhere to a set of rules about execution order, with additional guarantees that those rules are followed. Verification can be done via ZKPs or fraud proofs, the latter of which requires a sufficiently large economic bond that can be slashed if the proposer/sequencer misbehaves.

3 - Execution (Scaling Writes)

The execution layer contains the logic for state updates and is where smart contracts are executed. In addition to returning the output of a computation, the zkVM can also prove that state transitions were completed correctly. This allows other network participants to verify correct execution by simply verifying the proof, without having to re-execute the transaction.  

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

Existing ZK Integrations

• zkEVM rollups: A special type of zkVM optimized to be compatible with Ethereum and the Proof EVM execution environment. However, the closer Ethereum compatibility is, the greater the trade-off in performance. Multiple zkEVMs were launched in 2023, including Polygon zkEVM, zkSync Era, Scroll, and Linea. Polygon recently released their Type 1 zkEVM prover which is able to attest mainnet Ethereum blocks for $0.20-0.50 per block (optimizations are coming soon to reduce costs further). RiscZero also has a solution that can attest Ethereum blocks, but the cost is high due to limited available benchmarks.   

• Alternative zkVMs: Instead of trying to maximize compatibility with Ethereum, some protocols are taking alternative paths and optimizing for performance/provability (Starknet, Zorp) or developer friendliness. Examples of the latter include the zkWASM protocol (Fluent, Delphinus Labs) and zkMOVE (M2 and zkmove).

• Privacy-focused zkVMs: In this case, ZKPs are used for two things: 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: Enable off-chain computation on on-chain data (but without state). ZKPs are used to prove correct execution and provide faster settlement than optimistic coprocessors, but with a trade-off in cost. Given the cost and/or difficulty of generating ZKPs, we have seen some hybrid versions, such as Brevis coChain, which allows developers to choose between ZK or optimistic mode (trading off between cost and guaranteed hardness).

Open Problems That ZKPs Can Solve

• Important zkVM: Most base layers (L1) still use re-execution to verify correct state transitions. Incorporating zkVM into the base layer would avoid this since validators can verify proofs. This would improve operational efficiency. Most eyes are on Ethereum with zkEVM, but many other ecosystems also rely on re-execution.

• zkSVM: While SVM is currently mainly used in Solana L1, teams like Eclipse are trying to leverage SVM for rollups on Ethereum. Eclipse also plans to use Risc Zero for ZK fraud proofs to address potential challenges with state transitions in SVM. However, full-blown zkSVM has not been explored yet — likely due to the complexity of the problem and the fact that SVM is optimized for other aspects besides provability.

4 - Data Querying (Scaling Reads)

Data querying, or reading data from a blockchain, is an important part 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 environment). The read/write ratio varies between blockchains, but one data point Sig estimates is that >96% of all calls to a node on Solana are read calls (based on 2 years of empirical data) - a read/write ratio of 24:1.

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

Another angle is decentralization of how data is queried. Today, most data query requests in blockchains are facilitated by trusted third parties (based on reputation), such as RPC nodes ( Infura ) and indexers ( Dune ). Examples of more decentralized options include The Graph and anti-storage operators (also verifiable). There are also attempts to create decentralized RPC networks, such as Infura DIN or Lava Network (Lava aims to provide additional data access services later, in addition to decentralized RPC).

Existing ZK Integrations

• Proof-of-Storage: Query historical and current data from the blockchain without using a trusted third party. ZKPs are used to compress and prove that the correct data was retrieved. Examples of projects building in this space include Axiom, Brevis, Herodotus, and Lagrange.

Open Problems ZKPs Can Solve

• Efficient querying of private state: Privacy projects often use a variation of the UTXO model, which can provide better privacy features than the account model, but at the expense of developer friendliness. The private UTXO model can also lead to synchronization issues - an issue that Zcash has been struggling with since 2022 after experiencing a significant increase in shielded transaction volume. Wallets must be synced to the chain before funds can be spent, so this is a fairly fundamental challenge to the operation of the network. With this issue in mind, Aztec recently issued an RFP for ideas for note discovery, but no clear solution has yet been found.

5 - Proofs

As more and more applications incorporate ZKPs, proofs and verifications are quickly becoming an important part of the modular stack. However, today, most attestation infrastructure remains permissioned and centralized, with many applications relying on a single attestor.

While centralized solutions are less complex, decentralizing the attestation architecture and splitting it into separate components in a modular stack offers multiple benefits. A key benefit comes in the form of liveness guarantees, which are critical for applications that rely on frequent attestation generation. Users also benefit from higher censorship resistance and lower fees driven by competition and sharing of workload between multiple attestors.

We believe that universal attestor networks (many applications, many attestors) are superior to single-application attestor networks (one application, many attestors) because of higher utilization of existing hardware and lower attestor complexity. Higher utilization also benefits users in terms of lower fees, as attestors do not need to compensate for redundancy through higher fees (still having to pay fixed costs).

Figment Capital provides a good overview of the current state of the attestation supply chain, which includes attestation generation and attestation aggregation (which is itself attestation generation, but only takes two attestations as input instead of execution traces).

Existing ZK Integration

• STARK with SNARK Wrapper: STARK provers are fast and do not require a trusted setup, but the downside is that they generate a large number of proofs that are prohibitively expensive to verify on Ethereum L1. The final step wraps the STARK in a SNARK, making it much cheaper to verify on Ethereum. The downside is that this adds complexity and the security of these "composite proof systems" has not been well studied. Examples of existing implementations include Polygon zkEVM, Boojum in zkSync Era, and RISC Zero.  

• Generalized decentralized proof networks: Integrate more applications into decentralized proof networks, making provers more efficient (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 can solve

• ZK fraud proofs: In an optimistic solution, anyone can challenge a state transition and create a fraud proof during the challenge. However, verifying a fraud proof is still quite tedious as it is done by re-execution. ZK fraud proofs aim to solve this problem by creating challenged proofs of state transitions, allowing for more efficient verification (no re-execution) and potentially faster settlement. At least Optimism (in partnership with O1 Labs and RiscZero) and AltLayer x RiscZero are working on this.

• More efficient proof aggregation: An important feature of ZKPs is that you can aggregate multiple proofs into one without significantly increasing the verification cost. This enables the ability to amortize the verification cost of 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 area include NEBRA and Gevulot.

6 - Data Publication (Availability)

Data Publication (DP) Ensures that data is available and easily retrievable for 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 within a challenge period (1-2 weeks)) and liveness (even if the system uses proofs of validity, data may be required to prove asset ownership. Escape hatches or forced transactions). Users (such as zk-bridges and rollups) face a one-time payment that covers the cost of storing transactions and state for a short period of time before being pruned. Data Publishing Networks are not designed for long-term data storage (instead, see the next section for possible solutions). Celestia is the first alternative DP layer to launch mainnet (October 31st), but there will soon be many alternatives to choose from, as Avail, EigenDA, and Near DA are expected to launch during 2024. Additionally, Ethereum's EIP 4844 upgrade has also expanded data publishing on Ethereum (in addition to creating a separate fee market for blob storage) and laid the foundation for full dank 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 of sovereign rollups (such as Celestia and Avail) or smoother interoperability between rollups (such as Avail's Nexus). There are also some projects (Domicon and Zero Gravity) that provide both data publishing and long-term state storage, which is a compelling proposal. This is also an example of re-bundling two components in a modular stack, and we may see more progress (further unbundling and re-bundling experiments).

Existing ZK Integration

• Proving the Correctness of Erasure Codes: Erasure codes introduce a level of redundancy that allows the original data to be recovered even if part of the encoded data is unavailable. This is also a prerequisite for DAS, where light nodes only sample a small fraction of blocks to probabilistically ensure that the data exists. If a malicious proposer has encoded the data incorrectly, the original data may not be recoverable even if the light node samples enough unique blocks. Correct erasure codes can be proven using either validity proofs (ZKPs) or fraud proofs - the latter are subject to delays associated with challenge periods. All other solutions except Celestia are working on using validity proofs.

• ZK light clients provide support for data bridges: Rollups that use an external data publication layer still need to communicate to the settlement layer that the data has been published correctly. This is what the data proof bridge is for. Using ZKPs can make the verification of source chain consensus signatures on Ethereum more efficient. Both the Avail ( VectorX ) and Celestia ( BlobstreamX ) data proof bridges are powered by ZK light clients built in conjunction with Succinct.  

Open Problems That ZKPs Can Solve

• Celestia incorporates proofs of validity for correct erasure coding: Celestia is currently an outlier among data publishing networks because it uses fraud proofs to implement correct erasure coding. If a malicious block proposer has misencoded the data, any other full node can generate a fraud proof and dispute it. While this approach is simpler to implement, it also introduces latency (the block is final 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 themselves). However, Celestia is exploring combining its current Reed-Solomon encoding with ZKPs to prove that the encoding is correct, which would significantly reduce finality. The latest discussion around this topic can be found here with records of previous working groups (in addition to more general attempts to add ZKPs to Celestia's base layer).

• ZK Proofs DAS: There has been some exploration of ZK Proofs Data Availability, where light nodes would simply verify the merkle root and ZKPs without having to do the usual sampling by downloading small chunks of data. This would further reduce the requirements for light nodes, but development seems to have stalled.

7 - Long-Term (State) Storage

Storing historical data is important, primarily for synchronization purposes and servicing data requests. However, it is not feasible for every full node to store all the data, and most full nodes prune old data to keep hardware requirements reasonable. Instead, we rely on specialized institutions (archival nodes and indexers) to store all historical data and provide this data upon user request.

There are also decentralized storage providers, such as Filecoin or Arweave, that offer long-term decentralized storage solutions at reasonable prices. While most blockchains do not have a formal archival storage process (just rely on someone to store it), decentralized storage protocols are good candidates for storing historical data through the storage network's built-in storage and adding some redundancy (at least X nodes store the data) in incentives.

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 of this is Filecoin's Proof of Spacetime (PoSt), where storage providers receive a block reward every time they successfully answer a PoSt challenge.

Open Problems ZKPs Can Solve

• Proof of Data Origin and Authorization to View Sensitive Data: For two untrusted 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 actual documents or revealing passwords and logs. More details.

8 - Consensus

Given that blockchains are distributed P2P systems, there is no trusted third party that determines the global truth. Instead, network nodes agree on the current truth (which block is correct) through a mechanism called consensus. PoS-based consensus methods can be classified as BFT-based (where a Byzantine Fault Tolerant quorum of validators determines the final state) or chain-based (where the final state is determined retroactively by 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 some variation in Aleo, Aptos, and Sui.

Consensus is an important component of many different components of the modular stack, including shared sorters, decentralized proofs, and blockchain-based data publishing networks (not committee-based, like EigenDA).

Existing ZK Integrations

• Staking in ZK-based Privacy Networks: PoS-based privacy networks present challenges because holders of 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 non-staked and staked stake as separate assets. This approach keeps individual delegations private, while the total amount bound to each validator remains public.

• Private governance: Enabling anonymous voting has long been a challenge in the crypto space, and projects such as Noun Private Voting attempt to advance this. The same applies to governance, and at least Penumbra is working on anonymous voting on proposals. In this case, ZKPs can be used to prove that a person has the right to vote (e.g. through token ownership) and meets certain voting criteria (e.g. has not yet voted).

Open problems that ZKPs can solve

• 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 introduces the risk of a malicious party launching a DoS attack against each proposer in turn in an attempt to disable Ethereum. To address this, Whisk has proposed a proposal for a privacy-preserving protocol for electing block proposers on Ethereum. Validators use ZKPs to prove that shuffling and randomization were performed honestly. There are other ways to achieve similar finality goals, some of which are covered in this a16z blog post.

• 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 has the potential to be extended to consensus as well.  

9 - Settlement

Settlement is like the Supreme Court - the ultimate source of truth that verifies the correctness of state transitions and resolves disputes. A transaction is considered final when it is irreversible (or in the case of probabilistic finality - when it is very difficult to reverse). The time of finalization depends on the underlying settlement layer used, which in turn depends on the specific finalization rules used and the block time.

Slow finality is particularly a problem in cross-Rollup communication, where Rollups need to wait for confirmation from Ethereum before approving transactions (7 days for optimistic Rollups, 12 minutes and proof time for validity Rollups). This leads to a poor user experience. There are multiple ways to solve this problem using pre-confirmations with a certain level of security. Examples include ecosystem-specific solutions (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. There is also the option of leveraging EigenLayer's native rollup bridge for soft confirmations to avoid waiting for full finalization.

Existing ZK Integrations

• Fast Settlement with Validity Rollups: Compared to Optimistic Rollups, Validity Rollups do not require a challenge period because they rely on ZKPs to prove the correct state transition regardless of whether someone challenges it (Pessimistic Rollups). This allows for faster settlement at the base layer (12 minutes on Ethereum vs. 7 days on Ethereum) and avoids re-execution.

10 - Security

Security is related to the hardness of guarantees and is an important part of the blockchain value proposition. However, bootstrapping cryptoeconomic security is difficult - increasing barriers to entry and acting as a friction for innovation for applications that need it (various middleware and alternative L1s).  

The idea of ​​shared security is to leverage the existing economic security of a PoS network and subject it to additional slashing risk (punishment conditions), rather than each component trying to bootstrap its own security. There have been some early attempts to do the same thing in PoW networks (merged mining), but the misaligned incentives make it easier for miners to collude and exploit the protocol (it is harder to punish bad behavior because the work happens in the physical world, i.e. using computing power). PoS security is more flexible and can be used by other protocols because it has both positive (staking yield) and negative (slashing) incentives.

Protocols built around the premise of shared security include:

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

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

• Babylon is also trying to make BTC available for shared security. To address issues associated with merged mining (it’s hard to punish bad behavior), it is building a virtual PoS layer where users can lock BTC into Bitcoin’s staking contracts (no bridge). Since Bitcoin does not have a smart contract layer, the slashing rules of the staking contract are instead expressed in UTXO transactions written in Bitcoin Script.

• Restaking on other networks includes Octopus on Near and Picasso on Solana. Polkadot parachains also leverage the concept of shared security.

Existing ZK Integrations

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

11 - Interoperability

Secure and efficient interoperability remains a big issue in the multi-chain world, as exemplified by the $2.8 billion loss from the bridge hack. Interoperability becomes even more important in modular systems - not only is it about communicating between other chains, but modular blockchains also require 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 you would with an integrated blockchain is no longer feasible. This adds more moving parts to the equation.  

Interoperability includes token bridging as well as more general messaging across blockchains. There are several different options, all of which make different tradeoffs in terms of security, latency, and cost. Optimizing for all three is difficult and usually requires sacrificing at least one. Additionally, different standards across chains make it more difficult to implement new chains.

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

Existing ZK Integrations

• ZK Light Clients (Consensus Validation): Most current light clients can validate the consensus of other chains - either the full validator set (if small enough) or a subset of all validators (such as Ethereum's Sync Committee). ZKPs are used to make validation faster and cheaper, as the signature scheme used on the source chain may not be natively supported by the target chain. While ZK light clients are expected to grow in importance in bridging, current frictions for wider adoption include the cost of proof and verification and the cost of implementing a ZK light client for each new chain. Examples of protocols in this space include Polyhedra, Avail, and Celestia’s Proof of Data bridges, and Electron Labs’ zkIBC.

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

• ZK Oracles: Oracles act as intermediaries, connecting real-world data to blockchains. ZK oracles improve upon the current reputation-based oracle model by proving the origin and integrity of data and any computations performed on that data.  

Open Problems ZKPs Can Solve

• Full Light Clients: Full light clients also verify correct execution and DA, rather than blindly trusting the validator set of the other chain. This reduces trust assumptions and gets closer to full nodes, while still keeping hardware requirements low (allowing more people to run light clients). However, on most chains, especially Ethereum, verifying anything other than consensus is still prohibitively expensive. Furthermore, light clients only enable information verification (half of the problem), i.e. they can identify that information is false, but there still needs to be additional mechanisms for them to do something about it.

• Aggregation Layer: Polygon’s AggLayer aims to enable smooth interoperability between L2s within the ecosystem by leveraging aggregate proofs and a unified bridge contract. Aggregate proofs allow for more efficient verification and security - enforcing dependent chain states and bundles to be consistent, and ensuring that if the aggregated state depends on an invalid state of another chain, it cannot be resolved on Ethereum. zkSync's HyperChains and Avail Nexus have taken a similar approach.

When did ZK eat the modular stack?

Assuming we can reach a state where ZKP generation becomes very fast (almost at the speed of light) and very cheap (almost free), what will the end game look like? In other words - when did ZK eat the modular stack?

Broadly speaking, we believe two things are true in this case: 

1. All unnecessary re-executions are eliminated: By moving to a 1/N execution model (instead of N/N re-executions), we significantly reduce the overall redundancy of the network and are able to use the underlying hardware more efficiently. While there is still some overhead, this will help blockchains gradually approach centralized systems in terms of computational efficiency.

2. Most applications rely on cryptographic guarantees supported by ZK, not economic security: When the cost and time of generating proofs are no longer a relevant consideration, we believe most applications will rely on ZKPs for stronger guarantees. This will also require some improvements in usability and developer friendliness to build ZK applications, but these are issues that multiple teams are working on. 

The third condition is privacy (or information flow management), but it is more complicated. ZKPs can be used for some privacy applications with client-side proofs, which is what platforms like Aleo, Aztec, or Polygon Miden are building towards, but achieving privacy at scale for all potential use cases also relies on progress in MPC and FHE - potential topics for future blog posts.

Risks of our paper

What if we are wrong, and the future is neither modular nor ZK-ed? Some potential risks of our paper include:

Modularity increases complexity

Both users and developers face the growing number of chains. Users need to manage funds across multiple chains (and potentially multiple wallets). On the other hand, application developers face less stability and predictability, given that the space is still evolving, making it more difficult to decide which chain to build on. They also need to consider state and liquidity fragmentation. This is especially true now, as we are still experimenting along the frontier of which components make sense to decouple and which components will be recoupled. We believe that user operation abstractions, as well as secure and efficient interoperability solutions, are a key part of solving this problem.

Is ZK good enough?  

There is no getting around the fact that proof generation takes too long, and the cost of proof and verification is still too high today. For many applications today, competing solutions such as Trusted Execution Environments/TEEs (privacy) or optimistic/cryptoeconomically secure solutions (cost) still make more sense.

However, there is a lot of work being done on software optimization and hardware acceleration of ZKPs. Proof aggregation will help reduce verification costs further by amortizing the cost across multiple different parties (lower/user cost). The base layer could also be tweaked to be more optimized for ZKP verification. One challenge with ZKP hardware acceleration is the rapid development of proof systems. This makes it difficult to create specialized hardware (ASICs) because they can quickly become obsolete if/when the standards for the underlying proof systems evolve.

Ingonyama attempts to create some benchmarks for 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.

Is the limited privacy that ZKPs can provide useful?

ZKPs can only be used to achieve privacy for individual state, not for shared state where multiple parties need to perform computations on encrypted data (such as a private Uniswap). FHE and MPC also require full privacy, but they need to improve by many orders of magnitude in cost and performance before they become viable options for wider use. That said, ZKPs are still useful for certain use cases that don’t require private shared state, such as identity solutions or payments. Not all problems need to be solved with the same tool.

To summarize

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 that need to be solved are how value and information can flow securely between different modular components without sacrificing speed or cost, as well as abstracting it all away from the end consumer so that they don’t need to care about bridging between different chains, switching wallets, etc.

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

Today, there are still many use cases that default to cryptoeconomic security due to the cost and complexity of generating ZKPs, and some use cases 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 proving and verification. With every exponential reduction in cost and speed, new use cases are unlocked.

While this post focuses specifically on ZKPs, we are also increasingly interested in how modern cryptographic solutions (ZKPs, MPC, FHE, and TEEs) will eventually play together - we are already seeing this.