What is Zero-knowledge proof (ZKP)

For years, Zero-Knowledge Proofs (i.e. ZKPs) have been closely associated with privacy and Layer 2 scaling, but their role in blockchain infrastructure is expanding into a much broader range of applications. ZKPs are increasingly being used to verify computation and blockchain execution, while new applications are emerging across payments, financial clearing, and identity. Ethereum is also pushing execution proving further into the protocol through initiatives such as real-time proving and EIP-8025. As proving performance improves, the focus is increasingly shifting to the security, decentralization, and infrastructure needed to deploy ZKPs at scale.

In this article, we will explore what Zero-Knowledge Proofs are, why they are needed, how they work, and how ZKPs are being deployed across blockchain infrastructure.

What is a Zero-Knowledge Proof?

ZKPs have evolved from academic privacy-preserving primitives into foundational cryptographic infrastructure for verifiable computation. A ZKP system lets a prover demonstrate that a statement or computational state transition is valid without revealing the underlying private parameters, commonly called the witness. This architecture decouples execution from verification, allowing expensive computation in one environment while establishing correctness elsewhere through a succinct cryptographic proof.

Historically, ZKPs were associated primarily with transaction confidentiality and selective disclosure. The emergence of zero-knowledge virtual machines, validity rollups, and execution proofs has materially expanded that role. ZKPs are increasingly being deployed as a verification layer for distributed computation, with Ethereum providing one of the clearest examples of this transition as proof systems move from Layer 2 scaling infrastructure toward protocol-level Layer 1 validation.

Why Zero-Knowledge proofs are needed

Shafi Goldwasser, Silvio Micali, and Charles Rackoff established the theoretical foundation of ZKPs in their 1985 STOC paper on the knowledge complexity of interactive proof systems, formalizing how a verifier can confirm a statement's validity without acquiring the underlying knowledge used to prove it. This framework addresses two structural inefficiencies that remain relevant across modern digital systems.

The first is data over-disclosure, where legacy verification architectures require transmitting raw underlying information even when only a narrow attribute must be established. ZKPs reduce this dependency through selective attestation, allowing a verifier to confirm a specific property without ingesting the broader dataset from which that property is derived. The resulting model reduces information exposure while preserving verifiability.

The second problem is the amount of repeated computation required to verify blockchain transactions. Traditionally, many nodes must independently execute the same operations to confirm that the results are valid, increasing the computational cost across the network. ZKPs offer a different approach by allowing specialized provers to perform complex calculations and generate proofs that other nodes can verify with significantly less work. This reduces the cost of verifying computation across a distributed network, allowing ZKPs to improve efficiency as well as protect private information.

How a Zero-Knowledge proof works

A ZKP involves three main components: a prover, a verifier, and a witness, which is the private information used to generate a proof. For the system to be secure, it must satisfy three conditions. Completeness means an honest prover with a valid witness can generate a proof that the verifier accepts. Soundness ensures that the probability of a dishonest prover convincing the verifier to accept a false statement is extremely low. Finally, zero knowledge ensures that the verifier learns nothing meaningful about the private information beyond whether the statement is valid.

Early ZKP systems required several rounds of communication between the prover and verifier to confirm a proof. Modern blockchain systems generally favor non-interactive ZKPs, where a proof is generated once and can be verified independently by multiple nodes at different times. This approach is better suited to decentralized networks, where validators need to verify the same information without repeatedly communicating with the prover.

Contemporary ZKP infrastructure is largely organized around SNARK and STARK proof families. SNARKs typically provide compact proofs and highly efficient verification, though several traditional constructions rely on trusted setup parameters. STARKs instead use transparent, hash-based security assumptions that remove trusted setup requirements, but generally incur larger proof footprints. System design therefore requires optimization across a broader matrix that includes proving latency, verifier cost, prover memory requirements, proof size, and the cryptographic assumptions embedded in the underlying construction.

How is ZKP deployed across blockchain infrastructure?

Within blockchain architecture, ZKPs are increasingly distributed across privacy systems, scalability protocols, and generalized verifiable computation. Validity rollups apply the primitive primarily as an execution verification mechanism. Transactions are processed outside Ethereum Layer 1, aggregated into batches, and accompanied by a validity proof that certifies the resulting state transition before the new state is accepted on-chain.

This architecture separates execution correctness from data availability. The proof establishes that the computation was valid, while the underlying state data must still remain accessible so that users and nodes can reconstruct the rollup state. ZKPs therefore reduce execution redundancy without collapsing the broader security stack into a single cryptographic layer.

General-purpose zero-knowledge virtual machines extend the same model beyond rollups by compiling standard program execution into provable computation. Systems such as SP1, RISC Zero, and OpenVM increasingly position proving as ambient infrastructure beneath applications rather than as a bespoke circuit layer designed separately for each workload. ZK coprocessors apply a related architecture to resource-intensive smart contract workloads, allowing historical data queries or complex calculations to be executed offchain before a proof-backed result is returned to the contract.

Identity systems use the same primitive for a different objective. Rather than optimizing computation, they use selective verification to establish credentials, permissions, or verification status without exposing the full underlying identity layer. Across these deployments, the common denominator is the reduction of trust requirements between the party performing an action and the party responsible for validating it.

Where does ZK stand in 2026?

Ethereum provides the most visible benchmark for the maturation of the proving stack. In July 2025, the Ethereum Foundation published its real-time proving specification for an L1 zkEVM, requiring zkVMs to prove at least 99 percent of Ethereum mainnet blocks in under 10 seconds. The target hardware profile was constrained to less than $100,000 in cost and below 10 kW of power consumption, while proofs were expected to remain below 300 KiB and converge toward 128-bit security.

These limits reflect a deliberate decentralization objective. If high-performance proving becomes dependent on infrastructure available only to institutional data centers, the proving layer could concentrate around a narrow group of operators even if the validator set itself remains broadly distributed. Hardware ceilings therefore function as a design constraint intended to preserve decentralized validation topologies and reduce reliance on centralized proving providers.

By December 2025, proving performance had converged sharply toward those targets. According to the Ethereum Foundation's subsequent L1 zkEVM security update, proving latency had fallen from roughly 16 minutes to 16 seconds, while proving costs declined by approximately 45 times. Leading zkVMs had also demonstrated that 99 percent of Ethereum blocks could be proven in under 10 seconds on the target hardware, shifting the development bottleneck away from raw speed and toward soundness, formal verification, and production security.

EIP-8025 represents one of the clearest protocol experiments emerging from that transition. Ethereum's existing execution model links validation cost to block computation, because higher gas limits generally require nodes to perform more re-execution. EIP-8025 explores a proof-based architecture in which verification remains much closer to constant time relative to gas limit and state size, creating a potential path toward higher throughput without imposing an equivalent hardware burden on every validating node.

The proposal remains deliberately transitional. Validators can operate in proof-generating or proof-verifying modes without forcing the wider network to abandon existing execution semantics, while proof-verifying nodes continue to re-execute payloads and treat the proof as an additional validity signal. This optional consensus overlay allows Ethereum to stress-test the proving stack under production conditions while insulating consensus from proof-system failures that could otherwise introduce chain-splitting risk.

Glamsterdam reinforces this trajectory by improving the infrastructure surrounding execution proving. Enshrined proposer-builder separation under EIP-7732 expands the effective execution-validation window, providing a larger temporal buffer for proof generation and distribution. Block-Level Access Lists under EIP-7928 complement this architecture by exposing state dependencies before execution, enabling data preloading and more efficient parallel processing across validating nodes.

The strategic position of EIP-8025 became clearer on September 7, 2026, when the Ethereum Foundation Protocol Cluster published its Hegotá EIP tier list after evaluating 62 proposals. Only FOCIL under EIP-7805 and Frame Transactions under EIP-8141 received S-tier status, while EIP-8025 entered a group of 15 A-tier proposals designated as high priority and expected to ship. The distinction matters because it places execution proofs within the near-term roadmap without elevating them above the fork's locked headliners.

That prioritization also reflects Ethereum's broader security constraints. The Foundation has targeted December 2029 for quantum resistance across execution, consensus, and data, while EIP-8365 has entered the A-tier group as part of the effort to begin deprecating BLS-based withdrawal credentials. Mandatory execution proofs may consequently be delayed by one fork if post-quantum attestations require earlier implementation, demonstrating that ZK development now competes directly with orthogonal security requirements rather than advancing as an isolated scaling program.

ZK capital allocation beyond Ethereum

Venture activity in 2026 indicates that ZK is also moving beyond the localized zkEVM scaling thesis into private settlement, financial clearing, and identity infrastructure. The significance lies less in aggregate funding totals than in the composition of capital allocation, because each investment applies ZK to a different verification problem. Private stablecoin infrastructure received fresh backing through Payy's $6 million seed round led by FirstMark Capital, where ZK is used to obscure transaction participants and amounts.

Financial clearing represents a separate deployment path, with Cycles raising $8.7 million for an architecture combining ZK proofs, trusted execution environments, and graph algorithms to net financial obligations with lower aggregate capital requirements.

Identity infrastructure attracted additional capital through VeryAI's $10 million financing led by Polychain Capital for palm-based verification and World Foundation's $52.5 million strategic WLD token sale led by Pantera Capital supporting the expansion of World ID across users, enterprises, and AI agents.

These transactions should not be aggregated into a single industry funding figure because their structures and dependence on ZK differ materially. Their broader implication is that venture capital is underwriting ZK as a generalized verification primitive rather than solely as a blockchain throughput technology.

Architectural limitations and soundness risks

The core constraints around ZK have structurally evolved rather than disappeared. Proof generation remains computationally intensive, preserving a material risk that specialized hardware advantages could concentrate proving capacity among a limited set of institutional operators. At the same time, the growing complexity of execution circuits, compilers, and verifier implementations expands the attack surface, meaning that software defects can directly compromise proof soundness even when the underlying cryptographic construction remains secure.

ZK also remains an incomplete solution for holistic ledger security. Validity proofs can establish execution correctness, but data availability and censorship resistance remain orthogonal risk domains that require independent safeguards. This separation is important because proof-based verification can reduce the cost of checking computation without replacing the other trust assumptions required to operate a resilient blockchain.

Conclusion

Zero-Knowledge Proofs are increasingly moving from specialized privacy infrastructure toward a broader model of asymmetric verification. Their strategic value lies in shifting expensive execution toward specialized provers while allowing a distributed validator set to authenticate results with substantially lower computational overhead.

Ethereum's execution-proof roadmap demonstrates the maturity of this model at the protocol layer, while capital allocation across private payments, clearing systems, and identity infrastructure indicates that the same architecture is expanding well beyond rollups. The principal engineering constraint is therefore no longer limited to proving speed. The more consequential question is whether proving systems can remain decentralized, sound, and operationally compatible with the other security layers that underpin distributed networks.