Dialogue with Scroll and Cysic: Exploring Prover Networks and zk Hardware Acceleration
TechFlow Selected TechFlow Selected
Dialogue with Scroll and Cysic: Exploring Prover Networks and zk Hardware Acceleration
This episode explores rollup decentralization from the perspective of "decentralized proving networks and hardware acceleration."
Navigating Web3 tides with focused insightsIntroduction
This is the third episode of our decentralized Rollup interview series. This episode explores rollup decentralization from the perspective of "decentralized proving networks and hardware acceleration." We are joined by Ye Zhang, Co-Founder of Scroll, and Leo Fan, Co-Founder of Cysic, to discuss community-focused topics such as ZK circuits, what exactly hardware acceleration speeds up in zk proof generation, what an open decentralized prover network looks like, and how zk proof mining differs from Bitcoin's PoW mechanism. Both Ye and Leo also share insights into their teams' research and future plans regarding prover networks and zk hardware acceleration markets.
Guest Profiles
Ye
My name is Zhang Ye, Co-Founder of Scroll. My focus is on ZK Research—specifically ZK Hardware Acceleration, exploring how hardware can speed up the proving process. I also work on cryptographic and mathematical algorithms behind zero-knowledge proofs. Recently, I’ve been focused on zkEVM, building a zk-Rollup network compatible with EVM, so my work is more application-oriented. Additionally, I contribute to related protocol research.
Leo
I’m Leo Fan, Co-Founder of Cysic. I earned my PhD at Cornell in cryptography. Like Ye, I focus on algorithm research. My earlier work was in post-quantum cryptography, but in recent years I've shifted toward ZK-related algorithm development. At Cysic, we aim to accelerate the zero-knowledge proof "proof generation" process using hardware, eliminating it as a performance bottleneck.
Interview Transcript
Understanding Zero-Knowledge Proofs
Explaining Zero-Knowledge Proofs
Ye
Let’s start with the basics. Zero-knowledge proofs involve two parties: a Prover and a Verifier. The Prover can convince the Verifier that a certain statement is true without revealing any secret information. Let me give some concrete examples to illustrate what this statement and information might be.
Imagine a classroom where the teacher assigns a math problem, say solving an equation. Student A solves it, but student B does not. A wants to prove to B that they know the solution without actually revealing it. If A simply tells B the answer, then B learns the solution too—defeating the purpose. This is a classic case where zero-knowledge proofs allow A to prove knowledge of the solution without disclosing it.
A more blockchain-relevant example involves hashing. Suppose the hash output is 0. A can prove to B that they know some input (a pre-image) that hashes to 0, without revealing what that input is. In proof-of-work systems, finding such a pre-image requires massive computational power. With ZKPs, A can boast about knowing the pre-image while keeping it secret.
Another blockchain use case is privacy enhancement. Public blockchains are transparent, which creates privacy issues. Every transaction you send must be broadcast publicly, including details like who sent how much to whom. While transparency has benefits, it eliminates anonymity—once someone receives funds, their address becomes linked to many others. Zero-knowledge proofs solve this by allowing users to attach a proof to a transaction, verifying its validity without revealing its contents.
Later, applications like zk-Rollups leverage ZKPs for scalability—bundling thousands of transactions and generating a single succinct proof.
That’s the core idea behind zero-knowledge proofs and some key applications.
What is the zk circuit used in zk-Rollup?
Ye
What exactly is a zero-knowledge proof circuit? It relates to how you actually generate these proofs. As mentioned earlier, ZKPs let you prove something without revealing secrets. But how do you generate a proof for an arbitrary program? That involves the actual computational process of zero-knowledge proofs.
For instance, whether proving an equation or a hash function, you're essentially proving that given certain inputs, a specific output is produced. So you need to prove the entire execution of a program is correct, but in a way that produces a mathematical, cryptographic proof.
Normally, programs are written in high-level languages like C++. Similarly, to generate a ZK proof, you first need to encode your program into a special ZK language—not C++, but a domain-specific one designed for zero-knowledge computation.
This language is highly mathematical—similar to assembly but even more abstract. It only supports basic operations like addition, multiplication, and simple gate logic. You rewrite your original program using this format. Once your program is expressed in this specific ZK circuit language, you run a cryptographic algorithm to generate the proof.
In short, if you want to generate a proof for a program, you must rewrite it in this ZK-friendly format—the encoding method is known as a ZK circuit.
Is there a connection between zk circuits and hardware acceleration?
Ye
Great question—people often associate “circuit” with physical chips or electronic circuits. But ZK circuits are algebraic circuits: algebraic representations of programs. Think of them as a collection of mathematical equations like A × B = C. They’re fundamentally different from physical circuit boards.
There are some similarities though. When writing ZK circuits, you build up from basic logical gates—limited to addition, multiplication, and primitive structures—with their own layout rules. There are conceptual parallels, but the actual computation is entirely different.
The power of ZK circuits lies in their ability to verify mathematical relationships like A × B = C. Physical circuits, on the other hand, take an input, pass it through silicon, and produce an output.
Here’s a key difference: To compute A ÷ B = C on a physical circuit, you need a dedicated divider module—you input A and B, perform division, and get C. In a ZK circuit, you don’t perform division; instead, you assume witnesses A, B, and C are provided, and simply prove that B × C = A. That’s the essence of the distinction between ZK and physical circuits.
What does hardware acceleration actually speed up?
Ye
When people talk about hardware acceleration, they usually aren’t referring to accelerating the ZK circuit itself. The ZK circuit is just another representation of your original program. For example, if you have a hash function, rewriting it in ZK circuit form doesn't change what it computes—it’s still the same logic, just encoded differently.
What you actually run is a cryptographic algorithm—taking the ZK circuit as input and producing a proof. This algorithm takes a long time—hours or even days—because it involves complex operations like elliptic curve arithmetic and polynomial evaluations. It’s computationally intensive. That’s when acceleration becomes necessary: not during circuit creation, but during proof generation.
Writing the circuit is more like program preprocessing—a prerequisite step. Only after you have the ZK circuit can you begin generating a proof. The actual acceleration targets this proof-generation phase. Once the circuit exists, you use GPUs or ASICs to speed up the cryptographic computation required to produce the final proof.
So the key point is: acceleration applies to the proof-generation phase after the ZK circuit has already been created.
Leo
I think Ye summarized it very well. The ZK circuit is simply an alternative expression—an abstract mathematical model that ZK systems can understand. This model is then fed into a backend system to generate the actual proof. Hardware acceleration comes into play during this backend proof-generation stage. So ZK circuits and hardware acceleration are separate concerns. However, hardware acceleration improves the overall efficiency of ZK proof generation.
Ye
One thing I forgot to add earlier: Can the same hardware accelerator handle different ZK circuits? Yes, absolutely. Different circuits—whether for hashing or other programs—are just different encodings. But as Leo said, the acceleration happens during proof generation, which uses a deterministic cryptographic algorithm. This algorithm works the same regardless of the circuit. So an ASIC accelerates the proof-generation process uniformly across all circuits—the circuits themselves are just different inputs. Therefore, the same accelerator can speed up proof generation for any ZK circuit.
Centralization vs Decentralization in Prover Networks
What role does the Prover play in zk-Rollup?
Ye
Let me briefly explain what zk-Rollup solves: Ethereum’s scalability problem. Ethereum is a P2P network that prioritizes decentralization—every node receives and executes every transaction. But high decentralization leads to inefficiency, since thousands of nodes redundantly perform the same computations. This makes the network expensive and limits transaction throughput.
zk-Rollup’s core idea is to move batches of transactions off-chain. Instead of submitting each transaction to Ethereum, we bundle thousands of them and generate a single ZK proof attesting to their correctness. This small proof—and minimal data—is submitted on-chain. Ethereum nodes only need to verify the proof to confirm all transactions are valid.
Instead of processing ten thousand transactions, Ethereum now verifies one compact proof. This dramatically increases efficiency. If Ethereum normally handles ten transactions per second, but each verifies a proof covering ten thousand transactions, scalability improves by a factor of one thousand. Of course, real-world details complicate this picture, but that’s the fundamental concept: batch transactions, generate a proof, submit it, and let nodes verify.
Where does the Prover fit in? **A zk-Rollup needs a block proposer to collect and order transactions, and a Prover to generate the cryptographic proof attesting to the validity of each block.** The Prover ensures the integrity of the zk-Rollup’s state transitions.
Currently, most provers are centralized—they rely on powerful GPU clusters. Proof generation is deterministic: given a block, run the algorithm and produce the proof. It’s a fixed process that can be distributed across servers or data centers. But we believe moving toward decentralization is essential.
Introducing Scroll’s Approach
Ye
Scroll aims to build a zkEVM-based zk-Rollup. What is zkEVM? Earlier, I mentioned generating proofs for batches of transactions. To do this, we must express the program being proven in ZK language. zkEVM means rewriting the entire Ethereum Virtual Machine (EVM) in ZK-compatible form. Previously, zk-Rollups could only generate proofs for specific use cases—like DEX swaps—by encoding only the relevant logic.
Our goal is a general-purpose network where developers can deploy Solidity contracts unchanged. We build a ZK version of the EVM so that developer experience remains identical to Ethereum. Under the hood, we translate EVM execution into ZK circuits and prove every transaction is valid.
Simply put, Scroll is a faster, cheaper, higher-throughput network with Ethereum-level security. Its magic lies in accepting transactions, generating proofs, and submitting them—instead of broadcasting and achieving consensus via replication. The Prover plays a critical role by proving each block’s validity.
Why build a decentralized prover network? Benefits for reliability and incentivizing efficient proof generation
Ye
An excellent question: Why go through the trouble of decentralizing the prover market? After all, we could centralize it ourselves—and many projects currently do. But here’s why we believe decentralization matters:
First, it enhances network reliability. The core idea of zk-Rollups is that even if Scroll or the Layer 2 shuts down, users should still be able to generate proofs independently and withdraw funds from Layer 1. If the prover is centralized and fails, the entire network becomes fragile. A decentralized network ensures there are always backup provers ready to generate proofs.
Second, unlike proof-of-work, proof generation is deterministic—there’s no randomness. The goal is simply to do it faster. We want to create a positive feedback loop: faster proofs mean shorter withdrawal times and quicker finality on Layer 1. Our ambition is to continuously reduce proof generation time.
Only by opening a public prover market can we attract innovation. Companies like Cysic and others building ASICs will push hardware boundaries. As more players enter, competition drives progress. If only Scroll generated proofs, we’d eventually hit diminishing returns—we’d need constant hiring and investment to improve. But by opening the ecosystem, we incentivize external contributors to innovate, reducing costs and latency organically.
Opening the prover market encourages continuous improvement—tenfold speedups, then another tenfold. This fosters entirely new possibilities, perhaps enabling previously impractical applications. It’s a virtuous cycle that benefits the entire platform.
Leo
I agree with Ye’s points. ZK is now a hot topic in blockchain, with diverse applications driving strong demand for provers. From day one, Cysic has embraced open design—we regularly publish data and invite the community to collaborate on better ZK hardware. Our goal is to eliminate performance bottlenecks for ZK projects.
The market is still early, but we’re highly optimistic. We see enormous potential—which is why we committed early to FPGA development, progressing toward ASICs.
Scroll’s Current Plans and Progress on Decentralized Provers
Ye
Our immediate priority is launching our mainnet. We’re focused on delivering a stable, production-ready zkEVM and zk-Rollup implementation.
Internally, we’re developing high-performance GPU-based proving solutions. These will be open-sourced so anyone can run them. We’ve already published two academic papers—one on ASIC acceleration for ZK—and collaborate with institutions like Huazhong University of Science and Technology, Tsinghua, and others. Open GPU architecture designs are available for public review. Our current optimization target is maximizing ZKEVM performance on GPUs, particularly focusing on making our prover algorithm work efficiently on affordable consumer-grade GPUs like the 1080 or 2080. By lowering hardware requirements, we aim to broaden participation and promote decentralization.
Regarding specific prover network plans, we have high-level design principles: We don’t want the fastest prover to always win. Because proof generation is deterministic, if one entity uses superior hardware (e.g., ASICs) to dominate, the system becomes fragile—if that prover exits, the network suffers. We prefer redundancy. Our design allows reasonable proof submission within a time window. Faster hardware reduces energy and cost but doesn’t monopolize rewards. Over time, as aggregate compute power grows, we’ll gradually shorten the window. This is our philosophy.
Concrete timelines are still under discussion. First, ensure network stability. Then gradually onboard decentralized entities before fully opening the network. Our GPU-based prover will be publicly accessible, high-performance, and well-documented.
One more note: We uphold three core values—neutrality, openness, and community-driven development. Decentralized provers embody openness and community orientation.
Ethereum’s strength lies in its vast community. We aim to cultivate ours. Projects like Cysic are part of our ecosystem. We proactively host workshops and publish tutorials to help developers understand our ZK tooling stack. The vision is that hundreds of next-gen ZK projects use the same tools and benefit from shared infrastructure—common ASICs, common GPUs. We’re building a broad framework and network for the community. This is our long-term mission, though exact timelines remain fluid.
Understanding zk Proof Hardware Acceleration
Why accelerate zk proof generation?
Leo
We started Cysic based on my experience at Algorand, where I worked on Algorand State Proof—a zk proof used in cross-chain bridges. After completing the PoC around March-April last year, I realized proof generation took several minutes. Software and algorithmic optimizations couldn’t close the gap. That’s when I turned to hardware acceleration. Algorand wanted proof generation under thirty seconds; when software failed, hardware became the only viable path. This mirrors historical trends in cryptography—RSA encryption was once too slow on general-purpose computers, prompting the inventors to build custom hardware. The same principle applies to ZKPs: when generic hardware proves insufficient, specialized hardware drives ecosystem growth.
What hardware approaches exist? Cysic’s roadmap
Leo
Cysic drew significant inspiration from a paper by Ye. Main hardware options include CPU, GPU, FPGA, and ASIC. CPUs are general-purpose but typically slow unless using high-core-count models (e.g., 192-core), which are inaccessible to most.
GPUs and FPGAs offer faster time-to-market. Two key metrics define hardware performance: performance per dollar and performance per watt.
Performance per dollar refers to upfront capital cost. Here, GPUs outperform FPGAs—they deliver higher performance for the same investment. Due to inherent limitations, FPGAs can’t match GPU throughput. Thus, GPUs are ideal for initial market entry—this is the path Ye’s team chose internally.
However, Cysic’s ultimate goal is ASIC development—a universal ZKP accelerator. **Before mass-producing ASICs, extensive testing and prototyping on FPGAs are essential. This is our current focus.** While a single FPGA may underperform a GPU, connecting multiple FPGAs in parallel can surpass GPU capabilities. FPGA testing also informs future ASIC design.
Performance per watt measures ongoing electricity costs. Here, FPGAs and GPUs are comparable. But ASICs outperform both—once production scales, they achieve superior efficiency in both categories. That’s the current hardware landscape.
How will Scroll approach hardware acceleration?
Ye
As Leo noted, we’ve researched both ASIC and GPU acceleration. However, our in-house and open-source solution will be GPU-based.
Building ASICs and FPGAs requires rare expertise: selecting chip models, managing fabrication, navigating supply chains—tasks beyond typical software companies. They entail high R&D and non-recurring engineering costs.
GPUs are different. Software engineers write code, and anyone with a GPU can participate. This aligns with our philosophy: reuse existing resources, including GPUs formerly used by Ethereum miners. Considering accessibility, device availability, and timeline (FPGA/ASIC development takes longer), GPU is the pragmatic choice. And GPU performance is already excellent—so we’ll stick with GPUs in the near term.
That said, we welcome ASIC and FPGA builders joining our network. Several teams are exploring GPU paths (e.g., Supranational), ASICs (e.g., Cysic, Accseal), and FPGAs (e.g., Ulvantanna, Ingonyama). All are part of our ecosystem—we support them. If they have benchmarking questions, we’ll help. Everything remains open.
Our outlook aligns with Leo’s: FPGAs serve well as a transitional step. A single FPGA rarely beats a GPU, but interconnected FPGAs can. Still, FPGAs are expensive. ASICs promise similar performance to multi-FPGA setups but require multi-million-dollar investments and ~18-month timelines. Hence, pragmatically, we start with GPUs. Over time, the community—including various companies—will drive continuous improvements, eventually transitioning to ASICs for maximum speed.
Future Outlook: Prover Networks and Hardware Acceleration Markets
Supply and demand in the ZKP hardware acceleration market
Leo
Cysic aims to build a ZK Prover DAO, where diverse hardware participates. This DAO will partner with multiple ZK projects—constituting the demand side. On the supply side are provers. Cysic has engaged over 20 former mining farms—facilities capable of hosting proof generation services but lacking R&D expertise. Initially, Cysic will provide hardware to these farms, enabling them to join the DAO and serve the broader ZK community.
This jump-starts the ZK Prover DAO—Cysic avoids building decentralized infrastructure from scratch by leveraging existing facilities. Importantly, the DAO won’t be ASIC-only; it will include GPUs too. This aligns with community ideals of decentralization.
Cysic’s key partners span scaling solutions, privacy-focused Layer 1s, cross-chain bridges, ZK indexers (e.g., Axiom, HyperOracle), and emerging ZKML (zero-knowledge machine learning) projects. While ZKML is still early, it represents part of Cysic’s blockchain ecosystem.
How does this zk proof-generation “mining” market differ from Bitcoin’s PoW?
Leo
It depends on the project’s design. Scroll, for instance, adopts a decentralized philosophy: rewards aren’t limited to the fastest prover. Instead, provers submitting valid proofs within a time window earn rewards. This fosters healthy decentralization.
This market won’t resemble Bitcoin or Ethereum mining, where dominance concentrates—e.g., Bitmain capturing over half the market. Here, decentralization prevails. Participants benefit from the ecosystem’s growth, earning sustainable profits without winner-takes-all dynamics.
Ye
The biggest difference between PoW and ZK proof generation lies in determinism. ZK algorithms are deterministic—we can set time windows, but once a proof is complete, it’s valid. Ideally, we want tens of thousands of provers working in parallel—each generating proofs for different blocks—maximizing throughput and amortizing costs. Everyone contributes useful work.
In contrast, PoW is competitive: thousands race to solve a puzzle, but only the first miner wins. The rest waste their effort. This is inherently inefficient. Our energy and cost footprint may be less than 0.01x that of Ethereum’s former PoW.
Hardware requirements differ drastically. PoW involves repetitive hashing—“useless” computation—leading to mining rigs with weak CPUs and powerful GPUs. ZK proof generation, however, is a sophisticated algorithm requiring robust CPUs with large memory capacity. This changes hardware selection entirely. PoW just connects GPUs to a network and runs hashes in parallel. ZK requires coordinated CPU-GPU architectures—a holistic computing system.
Thus, hardware selection diverges significantly. ZK demands high-performance CPUs, unlike traditional mining rigs built around GPUs. In summary: determinism vs randomness, efficiency vs waste, useful computation vs brute force. And yes, zk places greater demands on CPUs—though some prior systems like Filecoin already had similar requirements.
Leo
Let me add some quantitative context. PoW chips (e.g., in Bitmain miners) are tiny—hundreds fit in one machine. Total power draw reaches 30–40 MW.
ZK chips are larger, but fewer are needed per machine. The process involves frequent interactions between chip and memory. We estimate total machine power consumption around 400–500 kW—comparable to a single high-end GPU system.
How does hardware acceleration promote prover network decentralization?
Ye
Better hardware from specialized vendors lowers entry barriers. Once we open-source our algorithms, individuals with consumer GPUs or similar equipment can join the network. Hardware acceleration reduces both cost and power consumption, making participation more accessible. This expands the prover market, improving network throughput, stability, reliability, and resilience.
Leo
I’d add that fast proof generation enables new applications. For example, proving correctness of a deep neural network might take hours today—rendering it impractical. With hardware acceleration, this could shrink to seconds, unlocking novel use cases in ZKML and beyond.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
ECN | Ethereum.cn
