Concluding the ZPrize 1B Track: Advancing ZK Hardware Acceleration

Nov 1, 2024

Overview

The recently concluded ZPrize 1B ’23 competition is dedicated to accelerating zero-knowledge cryptography through optimized hardware implementations on GPUs and FPGAs. By focusing on energy-efficient designs, the competition encourages solutions that not only enhance performance but also reduce power consumption, addressing sustainability concerns in cryptographic computations. This initiative supports the broader goal of making ZK technology scalable and environmentally responsible.

In the GPU track, Snarkify claimed first place with an impressive proving time of 0.5 seconds, achieving a 900x speed improvement over the baseline. Mike Voronov and Alex Kolganov secured the second position with a 0.7-second proving time, followed by Trapdoor Tech at 3 seconds.

In the FPGA track, Ponos Technology took the lead with a performance of 200 seconds, setting a high benchmark in FPGA-based proving.

With contributions from the Cysic team and Leo Fan, Cysic Co-Founder and Judge and Architect for this ZPrize track, we are proud to support ZPrize’s mission to advance open-source innovation and set new benchmarks in cryptographic hardware.

In a recent Twitter Space for the ZPrize 1B track announcement, those industry leaders came together to discuss the latest breakthroughs in Zero-Knowledge (ZK) proof hardware acceleration and the achievements of ZPrize 1B ‘23.

**Moderator:
**- Leo Fan— Architect and Judge of ZPrize 1B & Co-Founder of Cysic

**Panelists:
**- Alex Pruden — Co-Founder of ZPrize & Executive Director of Aleo
- Niall Emmart — Co-Founder of Snarkify
- Milos — CTO of Ponos Technology
- Star Li — Co-Founder of Trapdoor Tech
- Mike Voronov — Head of R&D at Cloudless Labs

In this article, we dive into the key highlights from this Q&A, exploring the technical hurdles and transformative potential of ZK acceleration as it reshapes the cryptographic landscape.

Take a look at our thoughtfully crafted recap below to hear directly from the experts driving these exciting breakthroughs forward.

Alex: ZPrize was really designed as a mechanism to promote the open source ecosystem for ZK hardware acceleration. A danger, in my eyes, that advanced cryptography or ZK cryptography specifically faces is that a single proprietary solution becomes dominant and chokes out a broader ecosystem that could have developed and flourished and the innovation that comes with that.

🎙: From your perspective, what are the bigger challenges for competing in the 1B track?

Mike: You have a few building blocks that are already individually optimized, so you have to choose the right strategy to unify them in one single algorithm. To do so, in this case, you need to rewrite a significant part of code to reduce the number of contact switchers between GPU and CPU. […] The second challenge was you needed to keep your solution general to be used in real-use cases. And when everything was done, you can tune and optimize building blocks such as MSM and NTT, considering them not as black boxes anymore, and it was the biggest challenge to beat the best again.

Niall: There were three: one was really understanding the entire proof system, basically extracting the actual steps from the Rust code so we could implement them in C. The next was doing ground up implementations of NTT to make them as fast as possible — we used something called the stock chem method on GPU. The final challenge was time management. These are big engineering projects and you have to set really aggressive goals and deadlines in the beginning and meet them or you’ll end up with time trouble in the end.

Milos: We didn’t have very efficient time management, but there was also complexity. The complexity was immense for implementation in hardware. We as a team had a very experienced ASIC design team, which worked mainly on FPGA. We were implementing things the old-fashioned way, which requires more design time than writing or rewriting the software. This is kind of, in terms of hardware acceleration, an immense task for a group of people or enthusiasts for a challenge like this.

Alex: This is the second time where the competitors had to fully integrate several different components into an overall proof. What has happened up to this point and the idea we had leading up to this was that we would have individual competitions focusing on individual components, making each component as fast as possible. It’s interesting when you start thinking about optimizing a specific component within a system versus optimizing a system itself.

Niall: Building an FPGA implementation is a ton of work, if you really want to do a good job on it. Time management is a really difficult thing in these giant engineering projects. A few bugs can sink you half a week. The real question is: how is the performance on these things? On the GPU, we ended up with a submission that was .55 seconds for proof, on FPGA we were around 5 seconds, so it was 10x lower than GPU. We mentioned in a few other spaces that the FPGA we used for this was a pretty old compute node, and definitely not fair on GPU to six year old FPGA.

Leo: If you want to build a specialized chip for ZK, the FPGA is the way to go. When engineering, you will encounter a lot of difficulties, not just in engineering but also in the way to get enough FPGA to do testing, or see what your performance is like. Maybe for the next ZPrize we can get more of the latest FPGAs for people to play with.

🎙: What are your thoughts on the future of ZK proofs, or ZK snarks, or starks? How are ZK proving techniques going to evolve, and what does that portend for hardware acceleration for ZK?

Leo: In the coming year, with more development in hardware acceleration for ZK, we’ll definitely have specialized hardware for ZK, which will make the proving speed much faster and more portable for people to carry around. At Cysic, we have smaller devices called the ZK Air which could be connected to cell phones or to laptops wirelessly. It’s the size of a MacBook charger, and you can carry it around to do client-side ZK proving while not relying on your laptop to do it. We also have a powerful machine called the ZK pro, which can be used to generate more complicated ZK proofs on the server side. Those two things will hugely reduce proving speed for ZK. Also we have ZKVM software technology, so you won’t need to write too much software code. You can just write a normal program and the compiler will compile it into the ZK circuit, which will lower the barrier to programming in ZK. These two things combined: hardware acceleration and more friendly ZK programming tools will make ZK more accessible to regular people.

Mike: I’ve designed several protocols that are based on different ZKP techniques and one of them was zkTLS. This was a project that was intended to solve different authentication and authorization problems. One of the challenges was to construct proofs on a mobile device, and there was another idea we connected it to ZPrize. When I was designing this protocol, I referred to ZPrize as a library of previous solutions, some of which were the fastest and best in the world. I could refer to which related to mobile phones, and found prizes from 2022 and how they performed on other mobile devices. In my opinion, all hardware platforms are quite important, and ZK is becoming really huge. A lot of people from my circles who work in Web2 areas have learned about ZK and have said, “You can wrap one single proof or solution in the constant side, so it’s awesome. And we want to use it in our Web2 technologies for different use cases.” So in my opinion all hardware and different platforms matter, and ZPrize is very useful as a library for the best algorithms in the world.

Niall: There are still open questions in my mind for interesting paths forward, about small field vs large field, about circuits vs VM style where you execute a program, so I think there are a lot of interesting questions to explore in future ZPrize competitions. One of the really important takeaways is that in this competition, the original Rust baseline code ran in 540 seconds on the machine we were given access to, and after going through a full acceleration it’s down to 0.55 seconds. There’s been a 900x speedup. This is a really interesting inflection point. We’re getting into the space of doing real-time proving. This isn’t minutes, this is sub-second, and the actual proof we did in ZPrize was quite big. If you look at all the different kinds of things that you can prove in that proof size, it covers a lot of ground. This is a really important inflection point for ZK.

Alex: There are two directions that ZK is evolving and one is this small field recursive VM style, one is potentially larger field circuit style. You can think of this similarly to the difference between a CPU and an ASIC. You kind of have a general computational model that can do many things or something that can do one thing specifically. The jury is still out in my opinion on how to do these small field VM style client-side performantly. It’s not quite clear if it will be practical for use cases like zkTLS, where if you had a dedicated circuit that you accelerate, that would be faster all the time. A lot of it comes down to, as it does in these cases, what is the ultimate use case that will drive demand for proving. What is going to be the source of demand for proofs? If the sources are varied and many, I can see the VM approach increasingly becoming preferred. If the sources are overwhelmingly zkTLS like, then it will be more likely that you have circuits that are optimized for that specific use case. But, it’s hard to see the future. TBD.

Niall: I think the one takeaway I have had over the past couple of ZPrizes is that the Rust code is really inefficient, so people started saying Rust is equivalent to C, but it depends on the implementation. Everybody is building on top of arkwork as the base of all their proving systems and there’s a lot of performance issues in arkwork, so you get these really massive speedups by taking the problem and reimplementing everything from the ground up in a much more specialized way in C and getting rid of the Rust code. So even on the CPU side there’s a lot of space for improvement by different software practices and reengineering everything from the ground-up.

🎙: As we think about future iterations of ZPrize, what else do people want to see?

Tony: Small fields is something I’d like to see for the next ZPrize, […] because there are a lot of different works spread over several companies that are siloed and closed source. We’ve yet to see an open source study on whether some of the questions mentioned earlier about big fields vs. small fields compare. It’d be nice to see in open source to me.

Alex: One I’d like to see is a prize specifically around zkTLS. That model is really interesting. As Mike pointed out, it’s a natural bridge between blockchain/crypto world and the Web2 and Web3 worlds. The zkTLS applications can be oracles, and oracles are incredibly important to blockchains, specifically for what are probably the killer applications of blockchains, which is stablecoins.

Mike: ZKVMs are really interesting from terms of optimization. If you set a broad goal to implement zkTLS as ZKVM, so you can have a big degree of freedom of which instructions to use — you can invent new instructions that are optimized for these particular use case.

Leo: I’m interested in seeing what other traditional hash functions such as keycheck or BLAKE. What is the proving speed for those if we put them in the context of ZK to achieve the best proving speed for these traditional hash functions? You can choose whatever proof backend you want to tackle this.

Closing remarks

Alex: There’s a lot of exploration left in this field and it’s been very exciting to run this competition for the last three years. I’ve learned an enormous amount — I think we all have — and it’s a very exciting time as we all look forward and see where this technology goes, and the nice thing is we — and you all — should congratulate yourselves because your work really has set the foundation for people to experiment with these technologies and use them in ways considered practical as opposed to theoretical. Five years ago these things were considered more or less impractical to deploy in production and now we have proving speeds for end-to-end proof that could be used in a real-time proving setting. That was unthinkable a few years ago. It’s incredible to see how fast this technology has moved. ZPrize can’t take all the credit for these developments but we’ve certainly been instrumental. And I know for a fact that there are many folks who benefit from this, both as open source projects and other proprietary ecosystems. Ultimately, it demonstrates the goal we set out for this competition and organization is being achieved and you all should feel very proud of that.

END

About Cysic:

Cysic is an industry-leading ZK hardware acceleration project, dedicated to designing advanced ASIC chips to help reduce ZK proving generation time and become the first ZK Prover Network. It is a real-time ZK proof generation and verification layer, that aims to provide ZK proofs in the fastest, cheapest, simplest, and most decentralized way.

Cysic Provides ZK-CaaS (ZK Compute-as-a-Service) based on advanced self-developed ASIC chips and can undertake computing power requirements for all ZK computing scenarios including ZK Rollup, ZKML, ZK Bridge, etc. Based on chip computing power + community GPU computing power, it integrates many verification nodes in the community. Finally, it builds the Cysic Network to provide a credible integrated computing power + verification network for the entire industry.

Join Cysic Community for the latest updates:

Discord 🔗｜Telegram 🔗｜X 🔗