Stories by Ingonyama on Medium

LinkedIn: https://www.linkedin.com/company/ingonyama

Snark Chocolate: Spotify / Apple Podcasts

Ingonyama and Cornami Announce Strategic Collaboration to Accelerate High-Speed Cryptography

Ingonyama — Wed, 28 May 2025 10:03:50 GMT

Major Leap Forward in Zero-Knowledge Prover Performance through Hardware - Software Integration to Deliver Best-of-Class Solutions

Tel Aviv, Israel — May 28, 2025 — Ingonyama, a leader in cryptographic acceleration, and Cornami, Inc., the inventor of a next-generation high-performance computing architecture, are pleased to announce a new collaboration that delivers a major leap forward in high-speed cryptography — beginning with Zero-Knowledge Prover (ZKP) acceleration.

At the center of this partnership is the integration of Cornami’s FracTLcore® computing fabric, a massively parallel, dynamically reconfigurable compute architecture, with Ingonyama’s ICICLE, a leading cryptographic acceleration library. The result is a solution achieving 10× to 100× improvements in throughput and energy efficiency compared to GPU-based accelerators, all while preserving a lower total cost of ownership. Together, the companies aim to address the growing computational demands of zero-knowledge proofs and future-proof cryptographic systems, including post-quantum algorithms.

Technical Highlights:

• ICICLE Cryptographic Acceleration Framework
Ingonyama’s ICICLE provides a highly optimized software stack for high-speed cryptography, with an emphasis on zero-knowledge proofs, including pluggable arithmetic backends and algebraic libraries.

• FracTLcore® Compute Fabric
Cornami’s FracTLcore computing fabric is a scalable, instruction-set programmable architecture designed for massive parallelism and compute density. Its reconfigurable nature allows dynamic adaptation to the dataflow and branching characteristics of ZK proofs, overcoming the limitations of SIMD-based GPU and fixed-function ASIC designs.

• System-Level Optimization
The solution integrates tightly across the hardware-software boundary to deliver high utilization efficiency even under complex circuit topologies and large-scale multi-proof batching scenarios.

“Our software is purpose-built for high performance cryptography, and when paired with the right hardware, it delivers a best-in-class solution,” said Omer Shlomovits, CEO of Ingonyama. “Cornami’s architecture unlocks the parallelism that ZKPs demand. As a hardware backend within our modular ICICLE framework, it forms a solution we call the ZPU™. In essence, it’s our software, powered by Cornami’s computing fabric, delivering acceleration and scale for cryptographers working at the frontier of fancy cryptography.”

“The Cornami architecture is uniquely designed to meet the complexity demands of next-generation post-quantum cryptographic algorithms,” said Paul Master, CTO of Cornami. “When combined with highly tuned compute intensive algorithms such as zero knowledge proofs via Ingonyama’s ICICLE, our FracTLcore Computational Fabric delivers unprecedented scalability for performance and efficacy — delivering solutions for secure communication, identity, and data protection in a post-quantum world. As cryptographic standards evolve, our technology provides the flexibility and computational power needed to stay ahead of both performance requirements and evolving standards.”

Zero-knowledge proofs are increasingly critical to decentralized systems, privacy-preserving technologies, and blockchain scalability — but their intensive computational requirements have been a barrier to adoption. The partnership also lays the groundwork for broader cryptographic cooperation, including lattice-based and post- quantum cryptographic protocols. Both companies are actively engaging with ecosystem partners, enterprises, and early adopters to define and deliver compelling solutions for high-performance cryptography. One such collaborator is Brevis Pico, who joins as the first design partner to help validate and extend ZPU’s capabilities to ZKVMs. These partnerships are critical to driving the industry forward at a time when the world is demanding real-time, more efficient, and privacy-preserving computation.

This collaboration marks a major step forward in the evolution of dedicated cryptographic solutions.

Learn more about ICICLE: https://dev.ingonyama.com

Learn more about Cornami: https://cornami.com/fractlcore

Interested in early access to the ZPU solution? Apply to join our Design Partner Program: zpu@ingonyama.com

About Cornami

Cornami is focused on the deployment of intelligent computing in real-time environments. The company has developed a highly parallel, reconfigurable computational fabric to address the shift in computing needs for the ever-increasing massive datasets of today, and into the future. This game-changing, software-defined technology delivers unprecedented linear scalability from thousands of cores on a single chip to millions across a system to meet performance, cost, and power requirements for customers and partners. Learn more at www.cornami.com.

About Ingonyama

Ingonyama combines expertise in hardware, software, and algorithms to enable the deployment of privacy-preserving technologies at production scale. Learn more at www.ingonyama.com.

Follow Ingonyama

Twitter / X: https://twitter.com/Ingo_zk

LinkedIn: https://www.linkedin.com/company/ingonyama

Snark Chocolate: Spotify / Apple Podcasts

Updated! Ingonyama Research Grants 2025

Ingonyama — Sun, 06 Apr 2025 11:01:28 GMT

April 2025 Update:
We’ve added two new case studies to this announcement, highlighting real-world applications of ICICLE, made possible through our Research Grants.

‍

Feb 2025 Update: We have added a special bonus for algorithms leveraging ICICLE sumcheck.‍

In early 2024, we launched our inaugural grants program, offering $100,000 to support research involving our high-speed cryptography library, ICICLE.

Now, we’re excited to announce our second grants program — another $100,000 dedicated to researchers. Details below!‍

Background: Who Are We? and What Is ICICLE?

Ingonyama is a next-generation hardware acceleration company committed to democratizing access to high-speed cryptography and advancing privacy-enhancing technologies.

ICICLE is our flagship product — a new math library designed for cryptographers to implement algorithms and protocols for high-speed cryptography, offering exceptional performance and a seamless developer experience.

Its design is straightforward:

Frontend APIs: We offer a comprehensive set of APIs, including vectors, polynomials, and hash functions, alongside specialized operations like MSMs, NTTs, Sumchecks, FRI, ECNTT, and more.
Access Options: These APIs are accessible directly in C++ or through Golang and Rust wrappers, ensuring flexibility for diverse development needs.
Backend: ICICLE supports multiple hardware devices and accelerators, including ARM, x86, NVIDIA GPUs, Apple Silicon, and more — all delivering maximum performance. It is embarrassingly simple to switch, offering instant multi-platform support.‍

With ICICLE, every line of code has the flexibility to run on different target hardware as needed. Onboarding is seamless — start by writing your code locally on your machine. The real magic unfolds when you see that same code, unchanged, achieve orders-of-magnitude performance on data center GPUs — or run effortlessly on an iPhone.‍

The Goal: Outperform Existing Research Benchmarks

We’re looking for a collaborative adventure! Choose any research paper you like, identify an algorithm implemented in the paper with reported benchmarks, and re-implement it using ICICLE. The greater your improvement over the original paper’s implementation, the larger the grant you’ll receive.‍

How to Apply

Applying is straightforward. Here’s how it works:

Applying is straightforward. Here’s how it works:
Fill out the form: Start by telling us about your idea through the form, which will ask you to briefly describe your proposal, e.g., “I want to implement Whir in ICICLE” (note: this one’s already taken by Giacomo).
Collaborate: We’ll discuss and finalize the performance milestones together. Expect some back-and-forth to align on the project goals.
Approval: Once we’re aligned, we’ll greenlight the project.
Get started: Begin your work with our support and drive it toward success!

Just like last year’s grants program, our team is here to provide end-to-end support on your journey to success. From access to hardware and ongoing support from our developers to collaborating with our research group on algorithms, we’ve got you covered. We also value detailed write-ups, and promise to showcase your work across our social channels to give it the recognition it deserves.

Case Study 1: Accelerating Threshold Encryption with ICICLE

The papers Batched Threshold Encryption (https://eprint.iacr.org/2024/1516) and Silent Threshold Encryption (https://eprint.iacr.org/2024/263) introduce a practical protocol to achieve mempool privacy, ensuring transaction content remains hidden until it is included in a block. Two core innovations of the protocol are:

Silent Threshold Encryption — Clients encrypt their transactions independently, without interacting with decryption servers or leaking metadata. This results in a non-interactive and unlinkable submission process.
Batched Threshold Decryption — Once a batch of transactions is selected, each server computes a single partial decryption share for the entire batch. These shares are then combined to recover the plaintexts, keeping communication efficient and fixed regardless of batch size.

The authors began by implementing threshold encryption techniques using the Arkworks ecosystem in Rust. After benchmarking their solution, they applied for a research grant from Ingonyama to accelerate performance using ICICLE. The implementation work was done by Guru Vamsi Policharla from University of California, Berkeley,

The threshold encryption protocols rely heavily on pairing-based cryptography and operations like multi-scalar multiplication (MSM) and fast Fourier transforms (FFT) over fields and elliptic curves — precisely the type of workload ICICLE’s CUDA backend is optimized for.

After migrating their code to ICICLE, Vamsi achieved up to 80x speedup over their original single-threaded Rust implementation. And they’re not stopping there — With native pairing support coming soon to ICICLE, they anticipate 150–200x performance improvements in the near future.

Guru shared, “The vision of ICICLE is great — allowing GPU speedups without GPU experience.” This is exactly what we had in mind when building ICICLE: empowering cryptographers with simple, portable access to high performance.‍

Case Study 2: Collaborative zk-SNARKs with ICICLE

To enable scalable and efficient delegation of ZKPs, a team of researchers from Zhejiang University, led by Xuanming Liu (Hins), introduced a fully distributed collaborative zk-SNARK protocol. Their system, presented in the paper “Scalable Collaborative zk-SNARK and Its Application to Fully Distributed Proof Delegation”, allows multiple cloud servers to jointly compute zk-SNARK proofs without relying on a centralized, powerful prover. The paper introduces several new primitives for collaborative proof generation:

Collaborative Sumcheck — enabling joint computation of polynomial sums across multiple parties
Collaborative Productcheck — a protocol for verifying product constraints in distributed settings
Collaborative Multilinear Polynomial Commitments — allowing distributed commitment and opening of multivariate polynomials
Distributed PST (Permcheck) — used to verify permutation constraints in parallel

These primitives serve as building blocks for a collaborative version of HyperPlonk, where the prover is no longer a single entity but a distributed network of participants — bringing zk proof generation to a more scalable and resilient architecture.

To put this into practice, the team turned to ICICLE for GPU acceleration. When Hins approached us, he shared, “I plan to use ICICLE to implement collaborative zk-SNARKs for HyperPlonk. This project serves both engineering and academic purposes. With ICICLE acceleration, we can develop a truly practical industrial solution.”

Their plan involved rewriting key components using ICICLE leveraging its optimized support for field arithmetic and MSM. ICICLE already supports the elliptic curves the project depends on — BN254 and BLS12–381 — ensuring full compatibility.

After porting parts of the system, the team observed at the MLE commitment up to 60x speedup and at the MLE open up to 6x speedup compared to their Arkworks-based version.

MLE (Multilinear Extension) Commitment refers to the process of committing to a multivariate polynomial that represents a computation over a large domain, typically in the Sumcheck or Productcheck protocol. It allows a prover to compactly represent an entire computation trace.

MLE Open is the step where the prover reveals and proves the value of the committed polynomial at a specific point, enabling the verifier to check its correctness without seeing the full polynomial.

Hins shared, “We found that the GPU indeed achieves a significant speedup, indicating that hardware acceleration is feasible. We are pleased to see that the GPU’s performance is quite satisfactory”.

FAQ

Q: What should be the length of a project?
A: There’s no strict rule for project length — it can span a weekend or extend across multiple months and iterations.‍

Q: How much is the average grant amount?
A: This will be determined on a case-by-case basis, as we consider multiple factors when evaluating the quality of a proposal. That said, it would be exciting if we ended up with a linear scale: for example, a 1x improvement might earn $1k, while a 10x improvement could receive $10k.‍

Q: In what currency will grants be paid?
A: USDC.‍

Q: If I am authoring novel research and want to use ICICLE, can I apply?
A: The grant is intended for new implementations of existing literature. However, you are welcome to apply as the author of the original paper. If you’re writing a new research paper and not considering ICICLE as your default, we’d love to hear why and improve.‍

Q: What’s in it for Ingonyama?
A: This is a great question, so we asked Omer, our CEO. Here’s what he said: “We stand on the shoulders of giants: There is nothing that brings us more joy than reinvesting our earned money into cryptography research. We believe we’ve built a product that can help cryptographers achieve better results while saving time and costs. The most important part of ICICLE’s development lifecycle is user feedback. So, in a way, this grant is part of our tuition.”‍

Q: Is ICICLE good enough?
A: There’s only one way to find out! :) On a more serious note, ICICLE has come a long way and now supports a large and growing ecosystem of applications. Even a performance gain of less than 1x — especially if it highlights areas where ICICLE can be improved — will still be rewarded.

Follow Ingonyama

Twitter / X: https://twitter.com/Ingo_zk

LinkedIn: https://www.linkedin.com/company/ingonyama

Read the full blogpost on HackMD

Snark Chocolate: Spotify / Apple Podcasts

BaseFold±: A Simple Improvement to BaseFold’s Multilinear Polynomial Commitment Scheme using…

Ingonyama — Sun, 06 Apr 2025 08:51:33 GMT

BaseFold±: A Simple Improvement to BaseFold’s Multilinear Polynomial Commitment Scheme using Point-Check

By Yuval Domb

In BaseFold, the authors make a key observation about the connection between multilinear and univariate polynomials, and the FRI protocol, leading to the construction of a new multilinear Polynomial Commitment Scheme (PCS).

Follow Ingonyama

Twitter / X: https://twitter.com/Ingo_zk

Read the full post on HackMD

LinkedIn: https://www.linkedin.com/company/ingonyama

Join us: https://www.ingonyama.com/careers

Snark Chocolate: Spotify / Apple Podcasts

Hardware-friendliness of HyperPlonk, Part2

Ingonyama — Tue, 01 Apr 2025 13:42:57 GMT

This article is a follow-up to our earlier post on the hardware-friendliness of HyperPlonk, expanding on claims made about the Sumcheck protocol. In that post, we argued that the performance bottleneck in Sumcheck stems not from raw computation, but from memory access patterns. This is a critical distinction: ideally, cryptographic protocols like Sumcheck should be compute-bound rather than memory-bound, since modern hardware — particularly GPUs and specialized accelerators — is optimized for high-throughput arithmetic but often struggles when constrained by memory bandwidth.

This memory-bound behavior is especially evident in the use of Number Theoretic Transforms (NTTs), a fundamental building block for polynomial operations in Sumcheck. Although NTTs are highly parallelizable, they require frequent and structured access to large arrays of field elements, placing significant pressure on memory subsystems and cache hierarchies. As a result, even when the underlying arithmetic is relatively inexpensive, memory access overhead can dominate overall performance.

Addressing this limitation calls for optimized memory layouts, hardware-aware scheduling strategies, and rethinking systems design to push hardware toward its computational limits, not its memory ceilings.

This follow-up aims to empirically validate our earlier claim by profiling the Sumcheck implementations within ICICLE. Through this analysis, we offer concrete evidence that memory access is indeed the dominant bottleneck, and provide insights that can inform future optimization and hardware acceleration strategies for Sumcheck and similar protocols.

Follow Ingonyama

Twitter / X: https://twitter.com/Ingo_zk

LinkedIn: https://www.linkedin.com/company/ingonyama

Join us: https://www.ingonyama.com/careers

Snark Chocolate: Spotify / Apple Podcasts

ICICLE-Snark: The Fastest Groth16 Implementation in the World

Ingonyama — Tue, 18 Mar 2025 14:21:07 GMT

By Emir Soytürk

ICICLE-snark is now the fastest Groth16 prover implementation, delivering record-breaking performance that unlocks new possibilities for ZK applications. This note contains benchmarks, manual and other treats.

Intro

Zero-knowledge proofs have rapidly advanced in recent years, with Groth16 emerging as one of the most widely used proving systems with characteristics ideal for blockchains:

Verification requires only three pairings, making it one of the fastest ZK proofs to verify.
It generates constant-size proofs, in just three group elements, which reduces on-chain storage and transaction costs compared to other proving systems.
While the prover side is computationally heavy, hardware acceleration dramatically speeds it up, making Groth16 feasible even for high-throughput applications.

The biggest trade-off of Groth16 is that a trusted setup is required per circuit. While this disadvantage remains popular, it makes Groth16 ideal for blockchain applications and beyond — a single proof can attest to the correctness of a complex computation without revealing inputs, and anyone can verify it with only three pairings.

How Groth16 Works

Generating a Groth16 proof requires performing intensive arithmetic over large prime fields and elliptic curves. In the scope of this blog, we won’t delve into QAP and R1CS. We can divide the rest of the prover into 2 steps: evaluate quotient and proof. As we can see these two steps contain 3 IFFT, 3 FFT, and 5 MSM. In addition to these, there is also element-wise multiplication and subtraction. These 2 big primitives (MSM and NTT) dominate the proving process. Multi-scalar multiplication (MSM) and Fast Fourier Transform-based polynomial evaluation (FFT/NTT). These two primitives are responsible for most of the execution time. MSM can consume ~60% of proving time and FFT about ~30%.

The prover needs two files: witness and zkey.

The witness file contains the intermediate values for a given input, based on the circuit. This file contains both public and private inputs. This file is unique per input.
The zkey file is a combination of the circuit, trusted setup, proving, and verification keys. This file is generated during the trusted setup phase and is unique per circuit.

The State of Existing Groth16 Implementations

Currently there are many Groth16 implementations. The most popular ones are:

SnarkJS with accessibility and ease of use. It also provides developers with 3 different zkSNARK proof systems and also setup and verification commands.
Rapidsnark is a prover written with c++ and assembly. This is approximately 4–10x faster than snarkjs implementation.
Arkworks
Lambdaworks
Gnark

Breaking the Speed Barrier with ICICLE

ICICLE is a cutting-edge cryptography library engineered to accelerate advanced algorithms and protocols — starting with ZKPs — across diverse compute backends, including GPUs, CPUs, Metal, and more. It supports multiple frontends in C++, Rust, and Go, allowing seamless integration across different development environments. With a single codebase, you can leverage three popular languages and run on multiple hardware platforms.

Accelerating Groth16

We first approached this problem by only integrating MSM and NTT. However, due to data transfer and data conversion, we couldn’t reach the performance we wanted. As a solution, we decided to build a Groth16 prover using ICICLE from scratch. The reference code was snarkjs repository built by iden3 team. This allowed us to build an optimized prover that can work with existing zkey files. So anyone can easily switch to ICICLE-snark from snarkjs or rapidsnark. The primitives explained in the “How Groth16 Works” section are already implemented and well-optimized in the ICICLE library.

Another problem with existing tools is that they are designed to be used as CLI. That means if you’re using these tools to prove the same circuits multiple times then there are many values you can cache and reuse like the proving key, bases, and NTT domain. To utilize this cache trick we developed our prover as a background worker and Rust library.

Data Conversion and Data Transfer

One of the biggest problems with moving any code to the GPU is data transfer and conversion. To be able to use ICICLE and utilize CUDA you need to convert your data to ICICLE type and move it to the device. In most cases preparing data for the CUDA kernel will take lots more time than executing the kernel itself.

Data conversion can take too much time due to calling `from` functions 2^n times. In most cases it’s possible and better to alter the memory directly with `transmute` calls in Rust. This allows the developer to change the type of the existing memory if the developer can guarantee it’s okay to use. It’s practically 100% speedup because `transmute` calls take only 20–30 ns while the same conversion takes 100ms when done in a naive way.

Data transfer speed is limited by your hardware. So it’s crucial to avoid data transfer if it’s possible. This was the initial motivation for us to build Groth16 from scratch instead of simply replacing MSM and NTT calls in existing implementations.

MSM and NTT

MSM and NTT are cryptographic primitives that are being used in many proving systems like Groth16, Hyrax, Plonk and Libra. ICICLE is providing fast implementations for multiple backends (CPU, CUDA, Metal, and more are upcoming). Replacing 5 MSMs with ICICLE MSM gave 63x improvement on average (size=2²²) and replacing 3 IFFTs and 3 FFTs with ICICLE FFT API gave 320x improvement on average (size=2²²)

VecOps

There are many places we need to multiply and subtract two vectors element-wise. These tasks are highly parallelizable on GPU. Calling VecOps API in ICICLE instead of using CPU to processes long arrays gave 200x boost on average (size 2²²)

Cache

In many applications (like a proving service or L2 rollup), you’ll reuse the same circuit and proving key for many proofs. ICICLE utilizes this by keeping the data in device memory and caching computations To take advantage of this we introduced CacheManager. It first computes values that are dependent on zkey file and save it by mapping with zkey file. If it’s computed previously then the code is using it again without computing.

CACHE Improvement

Performance Benchmarks & Results

We benched the code on 2 different setups:

4080 & i9–13900K
4090 & Ryzen 9 9950X

We used the circuits in the MoPro’s benchmark repository to compare the proving systems.

Complex Circuits: These circuits are for pure benchmarking purposes. It allows us to compare the performance of the provers based on a number of constraints.
Anon Aadhaar: Anon Aadhaar is a zero-knowledge protocol that allows Aadhaar ID owners to prove their identity in a privacy preserving way.
Aptos Keyless: Aptos Keyless lets users create self-custodial Aptos accounts with OIDC credentials (e.g., Google, Apple) instead of secret keys or mnemonics.

As mentioned before, in production it’s more likely that a project is going to prove the same circuits. To utilize this we are using the Cache system. However the other tools we compare are CLI so they terminate after one proving. To keep things fair we provide both benchmarks with and without cache.

How to Integrate ICICLE

You can now start integrating ICICLE-snark into your codebase. Depending on your codebase you have two options.

Use it in Rust Project

If your codebase is written in Rust then best practice is to use the prover as Rust Crate. You just need to add it to your dependencies by calling `cargo add ICICLE-snark`. After that you can import the proving function and create a CacheManager instance then start proving by providing paths of witness and zkey files.

use icicle_snark::{groth16_prove, CacheManager};

fn main() {
    let mut cache_manager = CacheManager::default();
    
    let witness = "witness.wtns";
    let zkey = "circuit_final.zkey";
    let proof = "proof.json";
    let public = "public.json";
    let device = "CUDA"; //replace with CPU or METAL if needed
        
    groth16_prove(
        &witness, 
        &zkey, 
        &proof, 
        &public, 
        device, 
        &mut cache_manager
    ).unwrap();
}

Use it in Other Programming Languages

If your codebase is written in a different programming language you can still use ICICLE prover. In this way you need to fetch the repository and run it in `worker` mode then communicate with it in any codebase. We shared an example of how to do that under ICICLE-snark/examples directory.

ICICLE Grant Program

We’re here to support innovative projects using ICICLE. If you have a unique idea, let’s explore the possibility of a grant to accelerate your work.

Choose any research paper, identify an algorithm with reported benchmarks, and re-implement it using ICICLE. The more you improve upon the original implementation, the larger the grant you’ll receive.

👉 ICICLE Developer Docs

Follow Ingonyama

Twitter / X: https://twitter.com/Ingo_zk

LinkedIn: https://www.linkedin.com/company/ingonyama

https://medium.com/media/130a5af25ceb23b14af2f38b0915565a/href

Snark Chocolate: Spotify / Apple Podcasts

ICICLE Goes Metal: v3.6

Ingonyama — Mon, 17 Mar 2025 13:14:28 GMT

We are excited to introduce ICICLE v3.6, bringing support for the Metal backend! This update expands ICICLE’s multi-backend capabilities, making it even more versatile across diverse hardware platforms.

For macOS users, ICICLE now leverages Metal acceleration, allowing seamless performance improvements without any code modifications — your existing APIs will run smoothly on Metal.

Getting Started is Simple

1. Download & extract ICICLE v3.6
2. Set the ICICLE_BACKEND_INSTALL_DIR environment variable
3. Run your existing code — now accelerated with Metal.
4. Enjoy the performance boost.

ICICLE’s new logo

What’s New in ICICLE v3.6

Metal Backend Support:

Now operable with C++ and Rust frontends.
Supported operations on Metal: MSM, NTT, and Sumcheck.

MSM and NTT: CPU vs Metal in v3.6

Current limitations

○ API implementations for Poseidon & Poseidon2 hashes, Merkle tree, Sumcheck, and G2 Montgomery conversions are not yet included but will be added in future updates.

○ Performance Optimizations — We are actively working on refining these primitives to further enhance efficiency in upcoming versions.

Sumcheck Enhancements:

Full API coverage on Program — The Rust wrapper now supports any user-defined Program as a combination function for the Sumcheck protocol.
Improved CPU Sumcheck — Optimized algorithm delivers significantly better performance.

ICICLE Sumcheck Grant — We’re excited to support innovative projects leveraging Sumcheck! If you have a unique idea, let’s discuss the possibility of a special grant for your work.

Lattice Advancements

LaBRADOR protocol ring, RNS VecOps, and NTT have already been integrated.
These enhancements pave the way for further lattice-based cryptographic developments.

For more details, check out the full release notes.

Future Releases and Upcoming Work

The initial Metal components are now in place, marking a major milestone in ICICLE’s expansion. In upcoming releases, support for Merkle trees and hash functions will be added, along with further optimizations to enhance overall performance.

On the lattice development front, we are focusing on expanding ring APIs, including decomposition, matrix multiplication, and advancements in the Greyhound ring. These improvements will strengthen ICICLE’s capabilities, paving the way for more efficient lattice-based cryptographic applications.

Exploring Groth16 with ICICLE

Our next blog post will dive into Groth16, the most widely used ZK proving scheme. We’ll showcase how ICICLE delivers the fastest implementation available. Stay tuned — this one is worth the wait!

Upcoming ICICLE Release

ICICLE v3.7 — Introducing FRI support! Want to experiment with the next version? Reach out to us at hi@ingonyama.com.

Follow Ingonyama

Twitter / X: https://twitter.com/Ingo_zk

LinkedIn: https://www.linkedin.com/company/ingonyama

Snark Chocolate: Spotify / Apple Podcasts

The Barrett-Montgomery duality and a New Multi-Precision Modular Reduction Scheme with only n2+1…

Ingonyama — Thu, 06 Mar 2025 12:36:39 GMT

The Barrett-Montgomery duality and a New Multi-Precision Modular Reduction Scheme with only n²+1 Digit Multiplications

by Yuval Domb
Yuval@ingonyama.com

Multiplication in prime fields with large unstructured primes is a fundamental building block of modern cryptography. Modular multiplication of two field elements a,b∈Fₚ requires computing their full product ab and reducing it modulo p. The two most widely used reduction algorithms are due to Barrett and Montgomery, with the latter operating in a permuted coset of the field (Montgomery form).

Single-precision implementations of both algorithms typically require three full multiplications: one for ab and two for the reduction. With schoolbook multiplication, each full multiplier costs n² digit multiplications, resulting in a total of 2n² for the reduction. Faster methods like Karatsuba can decrease the number of digit multiplications but introduce significant overhead in additions and complex internal dependencies, making them less suitable for CPU-based implementations.

Multi-precision approaches (operand scanning), particularly with Montgomery reduction, are the most widely used today. The best known algorithm (at least to us and ChatGPT) achieves reduction in n²+n digit multiplications without increasing additions or introducing complex dependencies, making it highly efficient for CPU-based systems.

In this note, we aim to explore modular reduction from a fresh perspective, balancing conciseness with an informal approach. Specifically, let us:

Introduce an alternative way to conceptualize modular reduction, revealing a natural duality between Barrett and Montgomery methods.
Present the n²+n Montgomery reduction algorithm.
Derive the dual n²+n Barrett reduction counterpart.
Explain why Montgomery reduction is inherently better suited for CPU-based implementations.
Introduce a new n²+1 algorithm, demonstrating its applicability to both Montgomery and Barrett reductions.
Show how Barrett and Montgomery reductions can often be used interchangeably in key cryptographic primitives.

As far as we are aware, much of this content is novel, providing new insights into the structure and efficiency of modular reduction techniques.

Read the full technical note on HackMD.

Follow Ingonyama

Twitter / X: https://twitter.com/Ingo_zk

LinkedIn: https://www.linkedin.com/company/ingonyama

Snark Chocolate: Spotify / Apple Podcasts

Case Study: Accelerating Zircuit’s Zero-Knowledge Proofs with ICICLE

Ingonyama — Mon, 03 Mar 2025 11:41:40 GMT

Introduction

Zircuit is an EVM-compatible ZK rollup designed to enhance the scalability and security of Web3 applications. By combining the OP Stack with Zero-Knowledge proofs (ZKPs), Zircuit enables efficient transaction processing and secure state updates. This case study explores how Zircuit integrated Ingonyama’s ICICLE software library to accelerate its cryptographic computations, improving performance and reducing costs.

Zircuit: A Faster, More Secure ZK Rollup

Zircuit employs proprietary proof aggregation for parallel processing, significantly enhancing efficiency while reducing the computational overhead associated with generating ZK proofs. The system maintains Ethereum compatibility, ensuring that gas fees are paid in ETH and that existing Ethereum tools, wallets, and dApps require minimal adaptation.

Key Features of Zircuit

Sequencer-Level Security: Monitors the mempool for malicious transactions and prevents their inclusion in blocks.
Secure Native Bridge: Provides a robust, easy-to-use canonical bridge for asset transfers.
Ethereum Compatibility: Supports Ethereum-native development tools with minimal changes required for integration.

Zircuit’s mission is to provide a scalable, secure, and developer-friendly layer-2 solution, advancing the capabilities of decentralized applications through efficient ZK rollup technology.

Implementing ICICLE: Addressing Performance Bottlenecks

Zircuit’s prover relies on computationally intensive mathematical operations to generate ZK proofs efficiently within a strict time window corresponding to block production. A key bottleneck was the high computational cost of core cryptographic operations, which increased latency and operational expenses. To address this, Zircuit sought a hardware acceleration solution capable of offloading demanding computations to GPUs. Ingonyama’s ICICLE emerged as a promising option, offering specialized support for GPU-accelerated ZK-proof primitives.

The Most Valuable Features of ICICLE for Zircuit

Zircuit identified the following ICICLE functionalities as crucial for optimizing its proving system:

Number Theoretic Transform (NTT) Optimization

Domain caching to reduce redundant computations
Fast twiddles for improved efficiency
Mixed-radix algorithm support to enhance flexibility

Multi-Scalar Multiplication (MSM) Optimization

Base caching to speed up calculations
Customizable Pippenger’s window bit size for performance tuning
Pre-computation factors to optimize large-scale operations

Seamless Integration with Zircuit’s Proving System

The integration of ICICLE into Zircuit’s prover was smooth and efficient. ICICLE’s versatility in handling both Montgomery and non-Montgomery representations eliminated costly data conversions, simplifying the implementation process.

Additionally, ICICLE’s well-structured API allowed Zircuit to implement advanced optimizations, including:

Multi-GPU Distribution: Spreading NTT and MSM computations across multiple GPUs for better workload parallelization.
Cross-Backend Support: The ability to run across multiple environments (CPU, CUDA, and Metal) with minimal adjustments.

These capabilities enabled Zircuit to seamlessly incorporate ICICLE into its proving pipeline, maximizing efficiency while maintaining flexibility.

Speed Improvements in ZK Proving

ICICLE’s optimized primitives contributed significantly to reducing proof generation times. Initially, before implementing additional GPU kernels, Zircuit observed a 20–30% speedup in key cryptographic operations.

To maximize ICICLE’s potential, Zircuit further optimized its prover architecture by:

Batching multiple NTT operations to minimize computational overhead
Distributing workloads across multiple GPUs for parallel execution
Implementing caching strategies to reduce redundant computations and improve memory transfer efficiency

As a result, ICICLE played a foundational role in Zircuit’s broader performance improvements, laying the groundwork for further GPU acceleration innovations.

ICICLE Github

Collaboration with Ingonyama

Zircuit’s collaboration with Ingonyama was characterized by a high level of technical support and responsiveness. Ingonyama’s team actively engaged in the integration process, offering insights and optimizations tailored to Zircuit’s specific needs. Their proactive approach ensured that the expected performance gains were achieved efficiently.

Future Plans for ICICLE in Zircuit

Looking ahead, Zircuit plans to further optimize its proving pipeline, with a focus on improving:

GPU memory management to minimize data transfer bottlenecks
Precision resource allocation for optimized workload balancing
Expansion of GPU acceleration to additional cryptographic primitives

These enhancements will be introduced as part of Zircuit’s upcoming Garfield update, scheduled for testnet launch in the week of February 24, 2025. Users can expect further optimizations and improved performance as the integration with ICICLE continues to evolve.

Influence on Zircuit’s Development Roadmap

ICICLE’s integration has also influenced Zircuit’s broader engineering strategy. Inspired by its optimized primitives, Zircuit has developed in-house CUDA GPU kernels to address additional computational bottlenecks beyond NTT and MSM. This iterative approach to GPU acceleration has significantly enhanced proof generation times and resource utilization.

The Acceleration Continues…

ICICLE has played a critical role in accelerating Zircuit’s ZK proof generation, providing a strong foundation for GPU-based optimizations. By integrating ICICLE, Zircuit has achieved substantial performance gains, paving the way for continued scalability improvements.

The partnership with Ingonyama has not only enhanced Zircuit’s proving capabilities but also inspired further innovation in GPU-accelerated cryptography. As Zircuit continues to refine its architecture, ICICLE remains an essential component in its pursuit of high-performance, scalable, and secure ZK rollups.

For more information, visit:
docs.zircuit.com
github.com/ingonyama-zk

Follow Ingonyama

Twitter / X: https://twitter.com/Ingo_zk

LinkedIn: https://www.linkedin.com/company/ingonyama

Snark Chocolate: Spotify / Apple Podcasts

ICICLE V3.5: Sumcheck with Lambda Functions

Ingonyama — Mon, 17 Feb 2025 18:03:07 GMT

Introducing a fully CUDA-optimized implementation of the non-interactive Sumcheck protocol for arbitrary functions over multilinear polynomials.

What is ICICLE

ICICLE is our software library built to empower cryptographers in implementing advanced algorithms and protocols — starting with Zero-Knowledge Proofs (ZKPs) — with exceptional performance and ease of use. It marks a major step toward hardware-agnostic cryptographic solutions, ensuring seamless compatibility across diverse hardware platforms with zero switching costs.

Highlights: What’s New in V3.5

The key highlight of V3.5 is the new Sumcheck API. Below, we’ll dive into the details of how to use this interface and the Program engine, which enables the user to generate sumcheck proof for any statement expressed as an arbitrary function of MLE (Multi Linear Extensions).

We also implemented proof-of-work in this version to accelerate grinding in FRI-like protocols — shoutout to Eylon Yogen and Giacomo Fenzi for requesting this feature! Additionally, we added the Poseidon2 sponge function and fixed bugs in:

get_device_count() now correctly returns the actual value instead of 0 — thanks to Zircuit for reporting this!
The vecops Rust wrapper now supports batch sizes greater than 1.
Fixed host-math inv2() by disabling the no-aliasing optimization.

For further information, see the full release notes.

Program — Lambda Functions

The Program class enables users to define expressions on vector elements, which ICICLE compiles into a fused implementation for the backends. This approach mitigates memory bottlenecks while allowing users to customize algorithms like Sumcheck. Program exclusively supports element-wise lambda functions and currently includes two predefined programs: (A(X) * B(X) — C(X)) and eq(X) * (A(X) * B(X) — C(X)), with more to come in future updates. The Rust API currently supports only these predefined functions, with full API coverage planned for the next releases.

Program Use Case: Sumcheck API

Sumcheck is a fundamental protocol with broad applications in ZKPs. Its most common use case is in the R1CS system (Spartan), where it efficiently verifies constraints of the form eq(X) * (A(X) * B(X) — C(X)), encapsulating degree-two relations. A year ago, we started our journey with a research paper where we developed parallelizable algorithms for arbitrary product sumcheck. Following which, we released an Arkworks based POC that enables users to prove sumcheck for arbitrary functions of MLE’s.

Applications such as the Jolt VM — use Sumcheck with arbitrary products and linear combinations of these products. Notably, in Jolt’s LASSO lookup arguments, the primary Sumcheck function depends on the lookup table structure defined by the user’s application.

Another key application is HyperPlonk, which allows users to define custom gates for high-degree constraints and leverage Sumcheck for efficient proof generation.

With the Program class, ICICLE users can now generate Sumcheck proofs for arbitrary functions, enabling scalable and flexible proof generation across various cryptographic protocols.

Note: This is the first time Fiat-Shamir is being run in ICICLE. As a result, both Sumcheck CUDA and Sumcheck CPU are currently undergoing an audit. If you’re considering incorporating Sumcheck into a production system, we’d be happy to share our design documents and audit report (which will be made public in the future).

Full Example

In this section, we demonstrate the Sumcheck C++ API.

First, we define the parameters for the polynomials, such as their size and number. Specifically, we use the function eq(X) * (A(X) * B(X) — C(X)), which involves four polynomials. In this example, these polynomials are generated randomly.

In this step, we compute the sum of the polynomials:

In this example, the calculation is performed using the CPU backend, but you can also use the GPU backend to generate the Sumcheck proof:

Next, we create the transcript configuration with default values. The transcript is essential for the Fiat-Shamir scheme, as both the Prover and Verifier use it to ensure consistency.

Next, we set up the Sumcheck Prover, which uses the function eq(X) * (A(X) * B(X) — C(X)). Since this function is commonly used, it has a predefined type, allowing it to run faster.

Next, we create the Sumcheck configuration object and an empty proof object to store the proof generated by the Prover.

At this stage, the proof is generated. The Sumcheck Prover produces the proof, which is then stored in the sumcheck_proof object. This proof will later be sent to the Verifier.

Once the proof is ready, we proceed to the Verifier side. Here, a new Sumcheck object is created for verification. We also define a boolean variable to store the verification result.

This line of code executes the verification process. After execution, the verification_pass variable is set to true if the proof is valid, or false otherwise.

It’s important to note that the transcript used by both the Prover and Verifier must be identical to ensure the Fiat-Shamir scheme produces consistent results on both sides.

Our Fiat-Shamir implementation closely follows the Merlin library implementation. Specifically, we append relevant metadata to the Prover’s messages, and challenges are generated using the strong Fiat-Shamir protocol.

Future Work and Upcoming Releases

In V3.5, the Sumcheck API supports only large fields. Since large fields have seen greater adoption than small fields, we have prioritized their support. Small fields will be added in a future release.

As mentioned above, while the C++ Sumcheck API is fully featured, the Rust implementation currently supports only predefined functions, and Golang support is not available. Full Rust and Go support will be provided in upcoming releases.

ICICLE V3.6 will introduce a new backend: Metal support! This will enable all ICICLE code to run efficiently on Apple Silicon. If you’d like to experiment with the next version, send us an email at hi@ingonyama.com.

Follow Ingonyama

Twitter / X: https://twitter.com/Ingo_zk

LinkedIn: https://www.linkedin.com/company/ingonyama