Author: Hannes Huitula

Translation: Plain Blockchain

1. What is Blockchain and How Does It Expand the Current Computing Paradigm?

Blockchain (noun): a coordination mechanism that enables participants from around the world to collaborate under a set of common agreed rules without the need for any third party to facilitate.

Computers are designed to do three things: store data, compute, and communicate with other computers and humans. Blockchain adds a fourth dimension: additional guarantees on how these three things (storage, computation, and communication) occur according to agreed-upon rules. These guarantees enable collaboration between strangers without the need for a trusted third party (decentralization).

These additional guarantees can be economic (based on game theory and incentive/punishment mechanisms) or cryptographic (based on mathematical trust), but most applications leverage a combination of both—cryptoeconomics. This contrasts sharply with the current reputation-based systems.

While Web3 is often described as "read, write, own," we believe a better concept for the third evolution of the internet is "read, write, verify," as the key advantage of public blockchains lies in guaranteeing computation and easily verifying whether these guarantees are being upheld. Ownership can be a subset of guaranteeing computation if the digital products we build can be bought and controlled. However, many blockchain use cases benefit from guaranteeing computation without directly involving ownership. For example, in a fully on-chain game, if your health value is 77/100, do you own this health value, or is it just executable on-chain according to the agreed-upon rules?

Web3 = Read, Write, Verify

2. ZK and Modularity—Two Accelerating Trends

Blockchain offers many exciting possibilities, but the decentralized model also introduces additional overhead (such as P2P communication and consensus) and inefficiency. Additionally, most blockchains still verify correct state transitions through re-execution, meaning every node on the network must re-execute transactions to validate the proposed state transitions. This leads to waste, contrasting sharply with centralized models, which have a single entity for execution. While decentralized systems always incur some overhead and redundancy, the goal should be to approach efficiency close to a centralized benchmark.

Despite significant improvements in infrastructure over the past decade, there is still much work to be done before blockchain can handle internet-scale. We see trade-offs along two main axes—expressiveness and difficulty—and believe modularity can accelerate rapid experimentation at the frontier, while zero-knowledge proofs (ZKPs) extend this frontier:

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

Difficulty—How difficult is it to achieve 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 entry barriers, requiring less capital (economic and human)—modularity can accelerate the pace of experimentation and specialization. The issue between modularity and integration is not binary but a spectrum of experimentation to find out which parts should be decoupled and which should not.

On the other hand, zero-knowledge proofs (ZKPs) enable one party (prover) to prove to another party (verifier) that they know something is true without revealing any additional information except its validity. This can increase scalability and efficiency by avoiding re-execution (shifting from all execution verification to one execution, all verification) while increasing expressiveness by enabling privacy (in a restricted manner). ZKPs elevate the difficulty of guarantees by replacing weaker cryptoeconomic guarantees with stronger ones, pushing the frontier outward (refer to the chart above).

We believe modularity and "the application of zero-knowledge proofs in everything" are both accelerating trends. While both offer interesting perspectives for exploring this field, we are particularly interested in the intersection of the two. Two key questions of interest to us 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 delving into these questions, we need an updated perspective on the modular stack for 2024.

3. The Modular Stack in 2024

The commonly used image of the modular stack consisting of four components (execution, data publication, consensus, settlement) is useful for a simple mental model, but we believe it is no longer an accurate representation, as the development in the modular field has been very rapid. Further deconstruction has led to new components, which were previously considered parts of larger ones, while also creating new dependencies that require secure interoperability between different components (which we will detail later). Given the rapid pace of development in this field, it may be challenging to keep up with all the innovations at different levels of the stack in a timely manner.

Earlier explorations of the web3 stack included Kyle Samani's (Mult1C0in) first publication in 2018 and its update in 2019. It covered everything from decentralized last-mile internet access (e.g., Helium) to end-user key management. While the principles may be reusable, some parts, such as proofs and verification, were completely missing.

Considering these factors, in 2024, we attempted to create an updated representation of the modular stack, expanding the existing four-part modular stack. It is segmented by component rather than functionality, meaning peer-to-peer networks, for example, are included in consensus rather than being split into separate components—mainly because it is 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 questions—namely, where ZK has permeated in the stack and what problems introducing ZK can solve (whether it's avoiding re-execution or privacy features). Before we delve into each component, here is 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 wider adoption friction. User operation abstraction is a general term used to attempt to abstract this complexity, allowing users to interact with a single interface (e.g., a specific application or wallet), with all complexity happening in the backend. Some basic level abstractions include:

Account Abstraction (AA) allows smart contracts to execute transactions without requiring user signatures for every operation (programmable encrypted 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 functionalities enables interactions with dApps using social logins, two-factor authentication (2FA), account recovery, and automation (auto-signing transactions). While discussions often focus on Ethereum (ERC-4337 passed in spring 2023), many other chains have built-in native account abstraction (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). Several teams are researching this issue, including Near, ICP, and dWallet. These solutions utilize MPC and chain signatures, splitting private keys from other networks into several small parts and sharing them among validators on the source chain to sign cross-chain transactions. When a user wants to interact with another chain, a sufficient number of validators must sign the transaction to meet the threshold encryption. This preserves security as the private keys are never fully shared in any one place. 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.

Intent, at a high level, translates users' desires and needs into operations that can be executed by the blockchain. This requires an intent resolver—a specialized off-chain agent responsible for finding the best solution for user intent. Several applications have already used specialized intent, 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 issues, including how to formalize this process, what the intent-centric language will look like, whether there is always an optimal solution, and how to find it.

Existing ZK Integrations

AA x ZK Identity Verification: 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 may be significantly more expensive than transactions initiated by traditional externally owned accounts (EOAs). Orbiter attempts to address this issue through a bundling service that uses ZKPs to verify the correctness of transaction signatures and maintain the AA account's nonce value and gas balance (via a Merkle world state tree). By aggregating proofs and evenly distributing on-chain verification costs among all users, significant cost savings can be achieved.

Open Issues ZKPs May Solve

Proof of optimal execution or intent fulfillment: While intent and AA can abstract user complexity, they may also act as a centralizing force and require us to rely on specialized participants (resolvers) to find the best execution path. Instead of solely trusting the resolver's goodwill, ZKPs may be used to prove that the user's optimal path was chosen from the resolver-sampled paths.

Privacy protection for intent settlement: Protocols like Taiga aim to achieve complete privacy protection for intent settlement to safeguard user privacy—a part of the broader movement to add privacy (or at least confidentiality) to blockchain networks. It uses ZKPs (Halo2) to conceal sensitive information about state transitions (application type, participants, etc.).

AA wallet password recovery: The idea of this proposal is to allow users to recover their wallets when they lose their private keys. By storing a hash (password, nonce) on the contract wallet, users can generate a ZKP to verify that it is their account and request a change of private key. A confirmation period (3 days or longer) serves as a safeguard against unauthorized access attempts.

2) Sequencing

Transactions need to be ordered before being included in a block, which can be achieved in various ways: sorting by proposer profitability (highest paying transactions first), sorting by submission order (first in, first out), giving priority to transactions from the private memory pool, and so on.

Another issue is who should sequence transactions. In a modular world, several different parties can do this, including rollup packagers (centralized or decentralized), L1 sequencing (based on rollup packaging), and shared sequencing networks (decentralized sequencing networks used by multiple rollup packagers). Each of these has different trust assumptions and scalability. In practice, the actual sequencing and block packaging of transactions can also be done by specialized participants (block builders) outside the protocol.

Existing ZK Integrations

Verifying encrypted memory pool correctness: Radius is a shared sequencing network with practical verifiable delayed encryption (PVDE) in the encrypted memory pool. Users generate a ZKP to prove that solving the time-lock puzzle will result in the correct decryption of valid transactions, i.e., transactions include valid signatures and nonces, and the sender has sufficient balance to pay transaction fees.

Open Issues ZKPs May Solve

Verifiable sequencing rules (VSR): Placing proposers/sequencers under a set of rules about execution order and attaching additional guarantees that these rules are followed. Verification can be done through ZKPs or fraud proofs, the latter requiring a sufficiently large economic bond that will be slashed if proposers/sequencers behave dishonestly.

3) Execution (Scaling Writes)

The execution layer contains the logic for state updates and is where smart contract execution occurs. In addition to returning computation results, zkVMs can also prove whether state transitions were correctly executed. This allows other network participants to verify correct execution by only verifying the proof, without the need for transaction re-execution.

In addition to faster and more efficient verification, another benefit of verifiable execution is the ability to perform more complex computations, as you do not encounter the typical gas and limited on-chain resource problems. This opens the door for entirely new applications with more computation-intensive operations running on the blockchain, leveraging guaranteed computation.

Existing ZK Integrations

• zkEVM rollups: A specialized type of zkVM optimized to be compatible with Ethereum and prove EVM execution environment. However, the higher the compatibility with Ethereum, the greater the performance trade-offs. 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 cost of $0.20-$0.50 per block (upcoming optimizations will further reduce costs). RiscZero also has a solution for proving Ethereum blocks, but it is costly and has limited benchmarking.
• Alternative zkVMs: Some protocols have chosen a different path, optimizing for performance/verifiability (Starknet, Zorp) or developer-friendliness, rather than attempting 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 privacy achievable solely through ZKPs is limited (only personal private states), 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, settling faster than optimistic coprocessors, but with cost trade-offs. Given the cost and/or difficulty of generating ZKPs, we see some hybrid versions, such as Brevis coChain, allowing developers to choose between ZK or optimistic modes (a trade-off between cost and guarantee difficulty).

Open Issues ZKPs May Solve

Inclusion of zkVM: Most Layer 1s still use re-execution to verify correct state transitions. Incorporating zkVM into the base layer would avoid this situation as validators can verify the proofs. This would improve operational efficiency. While most of the focus is on Ethereum, hoping for a base layer incorporating zkEVM, many other ecosystems also rely on re-execution.

zkSVM: Although SVM is primarily used in Solana L1 today, teams like Eclipse are attempting to leverage SVM for rollups on Ethereum. Eclipse also plans to use Risc Zero for ZK fraud proofs in SVM to address potential challenges in state transitions. However, a complete zkSVM has not been explored yet—possibly due to the complexity of the issue and SVM being optimized for things other than verifiability.

4) Data Querying (Read Extension)

Data querying, or reading data from the blockchain, is a crucial component of most applications. While recent discussions and efforts have mostly focused on scaling writes (execution), due to the imbalance between the two (especially in decentralized environments), scaling reads becomes more important. The read/write ratio varies across different 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)—with a read/write ratio of 24:1.

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

Another aspect is decentralized data querying methods. Today, most data querying requests in most 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 Integrations

Storage Proofs: Allow querying historical and current data from the blockchain without relying on trusted third parties. ZKPs are used to compress and prove that the correct data has been retrieved. Projects under construction in this area include Axiom, Brevis, Herodotus, and Lagrange.

Open Issues ZKPs May Solve

Efficient querying of private states: Privacy projects typically use variants of the UTXO model, which has better privacy properties than the account model but sacrifices developer-friendliness. Private UTXO models may also lead to synchronization issues—since 2022, Zcash has been working to address this issue after experiencing a significant increase in privacy transaction volume. Wallets must synchronize with the chain before being able to use funds, making this a very fundamental challenge for network operations. To anticipate this issue, Aztec recently released an RFP about the idea of note discovery, but a clear solution has not been found yet.

5) Proofs

As more applications incorporate ZKPs, proofs and verification quickly become an essential part of the modular stack. However, most proof infrastructure today is still permissioned and centralized, with many applications relying on a single prover.

While centralized solutions are less complex, decentralizing the proof architecture and segmenting it into a standalone component in the modular stack brings several benefits. One key benefit is liveness assurance, crucial for applications relying on frequent proof generation. Users also benefit from higher censorship resistance and lower costs due to competition and workload sharing among multiple provers.

We believe a generalized prover network (many applications, many provers) is superior to a single-application prover network (one application, many provers) as it efficiently utilizes existing hardware and is less complex for provers. Higher utilization also benefits users with lower costs, as provers do not need to compensate for redundancy through higher fees (still needing to cover fixed costs).

Figment Capital provides a good overview of the current proof supply chain situation, including proof generation and proof aggregation (essentially proof generation but only taking two proofs as input instead of executing a trace).

Existing ZK Integrations

STARK and SNARK Wrapping: STARK provers are fast and do not require trusted setups, but the downside is that their large proofs are costly to verify on Ethereum L1. Wrapping STARK in SNARK as a final step can significantly reduce verification costs on Ethereum. However, doing so adds complexity, and the security of such a "composite proof system" has not been thoroughly researched. Examples of existing implementations include Boojum in Polygon zkEVM and zkSync Era, both using RISC Zero.

Generalized decentralized proof network: Integrating more applications into a decentralized proof network can make provers more efficient in utilizing hardware (higher hardware utilization) and make it cheaper for users (no need to pay for hardware redundancy). Projects in this field include Gevulot and Succinct.

Open Issues ZKPs May Solve

ZK Fraud Proofs: In optimistic solutions, anyone can challenge a state transition and create a fraud proof during the challenge period. However, verifying fraud proofs is still quite cumbersome as it is done through re-execution. ZK fraud proofs aim to address this issue by creating a proof of the challenged state transition, enabling more efficient verification (without re-execution) and potentially faster settlement. At least Optimism (in collaboration with O1 Labs and RiscZero) and AltLayer x RiscZero are working on this issue.

More efficient proof aggregation: A great feature of ZKPs is that you can aggregate multiple proofs into a single proof without significantly increasing verification costs. This allows spreading verification costs across multiple proofs or applications. Proof aggregation is also a form of proof, but the input is two proofs instead of executing a trace. Projects in this field include NEBRA and Gevulot.

6) Data Publication (Availability)

Data publication (DP) ensures that data is available and easily retrievable within a short period (1-2 weeks). This is crucial for security (optimistic rollups require input data for verifying correct execution during the challenge period, lasting 1-2 weeks) and liveness (even with validity proofs, data may be needed to prove asset ownership for escape hatches or forced transactions). Users (such as 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 publication networks are not designed for long-term data storage (see the next section for possible solutions).

Celestia is the first project to release its mainnet as an alternative DP layer (October 31), but with projects like Avail, EigenDA, and Near DA expected to launch in 2024, there will soon be many alternative options available. Additionally, Ethereum's EIP 4844 upgrade improves data publication efficiency 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—an example is Nubit, which aims to build native DP on Bitcoin.

Many DP solutions also offer services beyond pure data publication, 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 offer data publication as well as long-term state storage, which is an intriguing proposal. This is also an example of rebundling two components in the modular stack, which we may see more of in the future (experimenting with further unbundling and rebundling).

Existing ZK Integrations

Verification of erasure code correctness: Erasure codes introduce a certain level of redundancy so that even if parts of the encoded data are unavailable, the original data is recoverable. This is also a prerequisite for decentralized storage (DAS), where light nodes only sample a small portion of blocks probabilistically to ensure data existence. If a malicious prover incorrectly encodes data, even if the light nodes sample enough unique blocks, the original data may still be unrecoverable. Verifying correct erasure codes can be done using validity proofs (ZKPs) or fraud proofs, the latter being affected by delays associated with the challenge period. All solutions except for Celestia are using validity proofs.

Data bridges provided by ZK light clients: Rollups using an external data publication layer still need to inform the settlement layer that the data has been correctly published. This is where data authentication bridges come in. Using ZKPs can make the verification of source chain consensus signatures on Ethereum more efficient. The data authentication bridges of Avail (VectorX) and Celestia (BlobstreamX) are supported by ZK light clients built in collaboration with Succinct.

Celestia integrates validity proofs to verify correct erasure codes: Celestia is currently an outlier in the data publication network as it uses fraud proofs to verify correct erasure codes. If a malicious block proposer incorrectly encodes data, any other full node can generate a fraud proof and challenge it. While this approach is relatively simple in implementation, it introduces delays (blocks are only finalized after the fraud proof window) and requires light nodes to trust an honest full node to generate fraud proofs (unable to self-verify). However, Celestia is exploring combining their current Reed-Solomon encoding with ZKP to prove correct encoding, which would significantly reduce finality. The latest discussions on this topic can be found here, including records of previous working groups (in addition to more general attempts to add ZKP to the Celestia base layer).

ZK-Proof DAS: Some exploration has been done in ZK-proof data availability, where light nodes only need to verify Merkle roots and ZKPs without downloading small data chunks for regular sampling. This would further reduce the requirements on light nodes, but it seems that development has stalled.

7) Long-Term (State) Storage

Storing historical data is important for synchronization purposes and responding to data requests. However, not every full node can 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 it upon user request.

Additionally, there are decentralized storage providers, such as Filecoin or Arweave, offering cost-effective long-term decentralized storage solutions. While most blockchains do not have a formal archival storage process (relying on someone to store), decentralized storage protocols are a good choice for storing historical data and increasing some redundancy through built-in incentive mechanisms in the storage network (at least X nodes storing data).

Existing ZK Integrations

Storage Proofs: Long-term storage providers need to regularly generate ZKPs to prove that they have stored all the data they claim to have stored. An example is Filecoin's proof of space-time (PoSt), where storage providers receive block rewards each time they successfully respond to a PoSt challenge.

Issues ZKPs Can Solve

Proving data source and authorizing access to sensitive data: For two untrusted parties who want to exchange sensitive data, ZKPs can be used to prove that one party has the credentials to view the data without uploading the actual file or revealing passwords and login details.

8) Consensus

Considering that blockchain is a distributed P2P system, there is no trusted third party to determine 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 validator set determines the final state) or chain-based (where the final state is determined retrospectively through fork selection rules). While most existing PoS consensus implementations are BFT-based, Cardano is an example of a longest chain implementation. There is also increasing interest in DAG-based consensus mechanisms, such as Narwhal-Bullshark, implemented in different forms in projects like 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 publication networks (not committee-based, such as EigenDA).

Existing ZK Integrations

Staking in ZK privacy networks: PoS-based privacy networks bring a challenge where holders of staked tokens must choose between privacy and participating in consensus (and receiving staking rewards). Penumbra aims to address this issue by eliminating staking rewards and treating unstaked and staked stakes as different assets. This approach can maintain the privacy of individual delegations, while the total amount staked by each validator is still public.

Private governance: Achieving anonymous voting has long been a challenge in the cryptocurrency space, and projects like Nouns Private Voting are attempting to make progress in this area. The same goes for governance, with at least Penumbra working on anonymously voting on proposals. In this case, ZKPs can be used to prove someone's right to vote (e.g., through token ownership) and whether certain voting criteria are met (e.g., not yet voted).

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 poses a risk where malicious parties could sequentially launch DoS attacks on each proposer, attempting to bring down Ethereum. To address this issue, Whisk proposes a privacy-preserving protocol for electing block proposers on Ethereum. Validators use ZKPs to prove that shuffling and randomization are done honestly. There are also other methods that can achieve similar goals, some of which are covered in this blog post by a16z.

Signature aggregation: Using ZKPs to aggregate signatures can significantly reduce the communication and computation overhead of signature verification (verifying an aggregated proof instead of each individual signature). This has been leveraged in ZK light clients, but could also be extended to consensus.

9) Settlement

Settlement is akin to the Supreme Court—it is the ultimate source of truth for verifying the correctness of state transitions and resolving disputes. A transaction is considered final at a point of irreversibility (or in the case of probabilistic finality, at a point considered 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 time used.

Slow finality is particularly problematic for cross-rollup communication, as rollups need to wait for Ethereum confirmations to approve transactions (7 days for optimistic rollups, 12 minutes and verification time for validity rollups). This leads to a poor user experience. There are currently several efforts to address this issue, including ecosystem-specific solutions with a certain level of security pre-confirmation (such as Polygon AggLayer or zkSync HyperBridge) and general solutions like Near's Fast Finality Layer, aimed at connecting multiple different rollup ecosystems by leveraging the economic security of EigenLayer. Another option is to use EigenLayer for soft confirmation of local rollup bridging to avoid waiting for complete finality.

Existing ZK Integrations

Speeding up settlement with validity rollups: Unlike optimistic rollups, validity rollups do not require a challenge period, as they rely on ZKPs to prove correct state transitions, regardless of whether someone challenges (pessimistic rollups). This makes settlement speed on the base layer faster (12 minutes compared to 7 days on Ethereum) and avoids re-execution.

10) Security

Security, related to the difficulty of assurance, is a key part of the value proposition of blockchain. However, bootstrapping cryptographic economic security is difficult, as it adds barriers to entry and creates innovation friction for applications (various middleware and alternative L1s) that need it.

The concept of shared security leverages the economic security of existing PoS networks and places it under additional slashing risk (penalty conditions), rather than each component trying to bootstrap its own security. Similar attempts were made in PoW networks (merged mining), but inconsistent incentive mechanisms made it easier for miners to collude and manipulate the protocol (difficult to punish bad behavior as work happens in the physical world, i.e., mining with computational power). PoS security is more flexible and can be used by other protocols, as it has both positive (staking rewards) and negative (slashing) incentive mechanisms.

Protocols built around shared security include:

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

Cosmos launched its Interchain Security (ICS) in May 2023, allowing the Cosmos Hub (one of the largest chains on Cosmos, supported by approximately $2.4 billion staked ATOM) to lease its security to consuming chains. By using the same validator set driving the Cosmos Hub to validate blocks on consuming chains, it aims to lower the barriers to launching new chains on the Cosmos stack. However, only two consuming chains are currently active (Neutron and Stride).

Babylon is also attempting to use Bitcoin for shared security. To address issues related to merged mining (difficult to punish bad behavior), it is building a virtual PoS layer where users can lock Bitcoin in staking contracts on Bitcoin (without bridging). Since Bitcoin does not have a smart contract layer, the slashing rules for staking contracts are expressed in the form of UTXO transactions in Bitcoin scripts.

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

Existing ZK Integrations

Hybrid ZK with economic security: Although ZK-based security guarantees may be stronger, the cost of proofs is still prohibitively high for certain applications, and the time to generate proofs is too long. An example is Brevis coChain, which is a coprocessor that obtains economic security from ETH re-stakers 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 trade-offs.

11) Interoperability

In a multi-chain world, secure and efficient interoperability remains a major issue, as evidenced by the $2.8 billion lost in bridge hacks. In a modular system, interoperability becomes even more important—not only does communication need to occur between different chains, but modular blockchains also need to communicate between different components (e.g., DA and settlement layers). Therefore, simply running full nodes or verifying individual consensus proofs, as with integrated blockchains, 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, each making different trade-offs in terms of security, latency, and cost. Optimizing all three simultaneously is very difficult and usually requires sacrificing at least one. Additionally, different standards on different chains make implementation on new chains even more challenging.

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

Existing ZK Integrations

ZK light clients (consensus verification): Most current light clients can verify consensus on other chains—either a complete 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 the importance of ZK light clients in bridging is expected to increase, current friction in adoption includes proof and verification costs, as well as implementing ZK light clients for each new chain. Protocol examples in this area include Polyhedra, data confirmation bridges of Avail and Celestia, and Electron Labs' zkIBC.

Storage proofs: As mentioned earlier, storage proofs allow querying historical and current data on the blockchain without relying on a trusted third party. This is also important for interoperability, as they can be used for cross-chain communication. For example, users can prove ownership of tokens on one chain and use them for governance on another chain (without bridging). There are also attempts to use storage proofs for bridging solutions, such as this solution developed by LambdaClass.

ZK Oracle: Oracles act as intermediaries, bridging real-world data to the blockchain. ZK Oracle improves upon the current reputation-based Oracle model by being able to prove the source and integrity of data, as well as any computations on the data.

Open Problems ZKPs Can Solve

A. Complete light clients: Unlike blindly trusting the validator set of other chains, complete light clients also verify correct execution and DA. This reduces trust assumptions and comes close to full node security while maintaining low hardware requirements. However, verifying anything beyond consensus on most chains is still prohibitively expensive, especially on Ethereum. Additionally, light clients are only able to verify information (half of the problem), meaning they can identify if information is incorrect but still need additional mechanisms to take action.

B. Aggregation Layer: Polygon's AggLayer aims to achieve smooth interoperability between L2s within the ecosystem by leveraging aggregated proofs and a unified bridging contract. Aggregated proofs enable more efficient verification and provide higher security—enforcing dependency chain state and bundle consistency, ensuring that if a rollup state depends on an invalid state from another chain, it cannot be settled on Ethereum. Similar approaches are taken by zkSync's HyperChains and Avail's Nexus.

5. What Happens When Zero-Knowledge Proofs (ZKPs) Consume the Modular Stack?

Suppose we reach a state where generating ZKPs becomes very fast (almost approaching the speed of light) and costs extremely low (almost free), what would the ultimate result look like? In other words, what happens when ZKPs consume the modular stack?

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

Elimination of all unnecessary re-execution: By shifting to a 1/N execution model (instead of N/N with re-execution), we significantly reduce overall redundancy in the network and achieve more efficient utilization of underlying hardware. While some overhead still exists, this will help blockchain systems progressively approach centralized systems in computational efficiency.

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

The third condition involves privacy (or information flow management), but this is more complex. Using client-side proofs, ZKPs can be used for some privacy applications, which is what platforms like Aleo, Aztec, or Polygon Miden are building. However, achieving widespread privacy protection applicable to all potential use cases still depends on the progress of MPC and FHE—this is a potential topic for a future blog post.

6. Risks of Our Argument

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

Increased complexity with modularity

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

Will ZK be efficient enough?

Proof generation is still too time-consuming, and proof and verification costs are still prohibitively high today. Competitive solutions such as trusted execution environments (TEEs) for privacy or optimistic/cryptoeconomic security solutions (cost) still make more sense for many applications.

However, work is already underway on software optimization and hardware acceleration for ZKPs. Proof aggregation will further reduce verification costs by spreading the cost across multiple participants (lower cost/user). There is also potential to adjust the base layer to optimize ZKP verification further. One challenge with hardware acceleration for ZKPs is the rapid evolution of proof systems, making it difficult to create specialized hardware (ASICs) as they may quickly become obsolete if/when the standards of the underlying proof systems change.

Ingonyama is attempting to create some proof performance benchmarks using a comparable metric called ZK Score. It is based on the cost of running computations (OPEX) and tracks MMOPS/WATT, where MMOPS stands for modular multiplication operations per second. For further reading on this topic, we recommend checking out the blogs from Cysic and Ingonyama, as well as Wei Dai's speech.

Is the limited privacy provided by ZKP useful?

ZKPs can only be used to achieve individual state privacy, not shared state among multiple parties that need to perform computations on encrypted data (e.g., private Uniswap). Complete privacy also requires FHE and MPC, but significant improvements in cost and performance are needed for them to become more widely used viable options. That being said, ZKPs are still useful for some use cases that do not require privately shared state, such as identity solutions or payments. Not all problems need to be solved with the same tool.

7. Conclusion

So, what does this leave us with? While we are making progress every day, there is still much work to be done. The most pressing issue is how to securely transfer value and information between different modular components without sacrificing speed or cost, and how to abstract all of this so that end users do not have to worry about bridging between different chains, switching wallets, and so on.

While we are still in the experimental phase, over time, things should stabilize as we find the optimal trade-offs for each use case. This, in turn, will provide space for the emergence of standards (informal or formal) and more stability for those building on these chains.

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

While this article focuses on ZKPs, we are also increasingly interested in how modern cryptographic solutions (ZKPs, MPC, FHE, and TEE) work together, which is something we are already beginning to see.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。