In this blog post, we share insights from our work with early adopters of v3, introduce the new features in v3.1, and provide a detailed look at what’s included in this release. To conclude, we provide information about the next release.
Background
ICICLE is a library positioned between the hardware and protocol layer of the ZK stack, allowing engineers to efficiently implement algorithms optimized for target hardware.
In early September, we announced ICICLE v3 featuring a new design that enables optimal performance on both CPUs and GPUs with minimal code changes. Combined with enhancements to our V2 polynomial API, this version offers a true PyTorch-like experience for implementing ZK protocols.
How Users are Adopting v3
We were humbled by the quantity and caliber of engineers who chose to test our code! Here we highlight two examples showing how a unified API and dual CPU-GPU backends are solving real business problems.
Quote 1: “We just ported our Halo2 fork to use Icicle v3. We love the idea of easily switching backend between CPU/GPU, since this will also simplify maintaining our code (before, we used features to selectively use icicle/halo2 APIs).”
ZK provers remain complex, and maintaining a large codebase can slow down deployments, bug fixes, and readability. Previously, ICICLE V2 users who integrated GPU acceleration had to switch between the ICICLE API and their native CPU API — no longer!
With the new ICICLE v3 unified API, and significant advancements in making our CPU backend becoming state of the art in terms of performance, you can now move larger parts of your codebase to a single API with simple switching. No more complicated workarounds or sophisticated conversions. Clean code is the way!
Quote 2: “Having better CPU backend is important to our operations. From our experience, it takes long to acquire new GPU instances, so we depend on CPU to handle traffic surge”
This one is cool. One of the most popular (and critical) infrastructure frameworks in Web3 faces a significant challenge: running on a large public cloud provider. To keep costs low, they need their usage to match actual demand, which means renting instances on-the-fly, based on current needs. The problem is that sometimes, during peak traffic hours, it is impossible to get enough GPUs to maintain the same quality of service — scaling is tough! The solution? When GPUs aren’t available, they seamlessly fall back to CPUs. With ICICLE, this switch is easy — just adjust the target backend — with no compromise in CPU performance compared to other implementations.
We’d like to extend our sincere thanks to everyone who tested v3 — whether new users or those porting from earlier versions. We gain invaluable insights from our users and their feedback.
Click here for release notes on how to use v3.1. For more on how teams are using ICICLE (V2), check out our ICICLE Case Study series of blog posts.
v3.1 — What’s New
The new release includes the following:
Bug fixes (Shoutout to Marlin and Eigenlayer for their help):
CUDA:
- MSM correctness for specific input sizes
- MSM memory allocation for very large MSM
CPU: CPU MSM bug fix for small amount of threads
FrontEnd: Golang race for multiple devices scenario
Examples:
- Arkworks conversion: Yes, you can port your Arkworks code to ICICLE and it will run faster
To get started with ICICLE, head over to our documentation. CPU support means you can get things up and running in no time — no setup or special hardware needed. If you cannot find what you need to implement your algorithm or encounter any unexpected behavior, don’t hesitate to reach out at support support@ingonyama.com, or connect with us on Discord or Github!
Roadmap
We will soon introduce our first client-side backend. This means that the same code can run on server side, client side, or both! We believe client-side proving is set to take off, and we are here to support teams as they explore new applications and use cases. If you’re interested in experimenting with ICICLE on mobile, feel free to reach out!
In the next version, we’re adding official Sumcheck support. After extensive experimentation with Sumcheck algorithms for both CPU and specialized hardware, we believe it’s time to introduce native support and a dedicated Sumcheck API to ICICLE.
On the hash API front, we’re adding Poseidon2, aiming for the CPU version to outperform Plonky3. A GPU version will also be available.
Finally, we’re committed to further enhancing the performance of our existing CPU backend. With new algorithms in development, we anticipate a significant improvement coming to v3.2.
We have many new ideas in the works, with the most valuable ones coming from our ecosystem. We’d love to hear from you — talk to us!
Follow Ingonyama
Twitter: https://twitter.com/Ingo_zk
YouTube: https://www.youtube.com/@ingo_zk
GitHub: https://github.com/ingonyama-zk
LinkedIn: https://www.linkedin.com/company/ingonyama
Join us: https://www.ingonyama.com/careers
