Sindri is thrilled to announce our participation in the upcoming V0RTex Hackathon hosted by Scroll. As pioneers in the zero-knowledge space, Scroll has been instrumental in scaling Ethereum and we share their commitment to uplifting the developer experience. We're excited to engage with the vibrant Scroll community, challenge conventional workflows, and explore new ways to build the scalable future.

Why Participate in V0RTex?​

V0RTex is a hackathon bringing together developers across the experience spectrum from novice to expert looking to push scalability. Builders will hack alongside others from across a variety of ecosystems including Ankr, Aztec, Chainlink, Covalent, Cyfrin, The Graph, and OpenZeppelin.

Hackers will have the opportunity to compete for over $85,000 in hacker rewards (plus Sindri credits if you’re participating in the Sindri track).

Check out previous Scroll hackathon submissions, or sign up here!

What We Bring to the Table​

Sindri brings powerful tooling and accessible infrastructure solutions to ZK devs all via an API call. It’s like if Infura had a ZK proving endpoint for some of the most widely use proving frameworks like Gnark, Halo2, Circom, and Noir. This means builders and teams can have ready-to-use DevOps pipelines built right into the development flow or application logic, streamlined through intuitive Sindri SDKs, our Remix integration and other tooling.

At Sindri, we felt like robust infrastructure ZK solutions were something only well-capitalized organizations could afford to spin-up and manage. Our vision is to democratize acceleration, infrastructure, and the backend deployment experience for any developer, across any ecosystem, and across any ZK framework so they can build and ship with confidence. Our serverless deployment options mean more compute in a format that's consumable for dev teams big and small.

Jump in and get ready to hack in the V0RTex, or explore the bounties for Sindri and other hackathon partners.

Engage, Innovate, and Build​

V0RTex has lined up exciting challenges for participants, focusing on areas where blockchain and zero-knowledge proofs can truly shine:

• DeFi: We’re looking for ideas that revolutionize decentralized finance through superior UX and accessibility.
• Gaming: Show us how zero-knowledge proofs can transform gaming on the blockchain with fairness, privacy, and scalability.
• Privacy: Innovate with projects that utilize ZK to enhance privacy in identity management, voting, and communications.

Each category not only challenges the status quo but also provides a fertile ground for deploying new concepts that could lead to broader adoption and understanding of blockchain technologies. Looking for some inspiration on what to build with Sindri? We have lots of it.

More Than Just Competition​

Sindri’s participation in V0RTex is about more than just competition; it’s about fostering a community. We are committed to supporting all developers, from those just starting their blockchain journey to seasoned experts. To this end, we will be offering comprehensive support throughout the hackathon, including dedicated office hours with our team.

Join us at Scroll's V0RTex hackathon to push the boundaries of what's possible with zero-knowledge technology. Together, we can build a future that leverages the full potential of blockchain technology, making it more accessible, efficient, and secure for everyone.

Explore more about how Sindri can support your projects by visiting our blog, GitHub, and documentation. Let’s build something transformative together in the V0RTex.

Today, we are excited to announce Sindri’s integration with Remix.

The integration of Sindri + Remix streamlines the ZK development process by embedding Sindri’s powerful API directly into the browser-based solution developers already rely on: Remix.

Sindri makes commissioning ZK infrastructure effortless and brings teams from idea to production within minutes not days or weeks. Now teams can incorporate sophisticated smart contract logic with industry-best tooling and powerful ZK infrastructure deployment pipelines without leaving their development environment.

Shareable sessions through Gists make ZK unit testing and collaboration possible with Remix across teams. We envision that, together with Remix, builders will come to rely on templated and shareable builds that can be repurposed, rebuilt, and reimagined on the fly.

To further expedite the development process, this integration provides pre-built helper templates for Circom development built right into Remix. These templates can serve as invaluable starting points, significantly reducing setup time and allowing developers to dive straight into building.

Here’s to moving ZK development forward, making it more accessible, and aligning it with the standards you’ve come to expect in the broader world of software development. Let’s build something amazing.

Create a Sindri account and get started in minutes with pre-built Circom templates or pull in from the Sindri repository of circuits here.

We’re making security, quality assurance, and developer efficiency of zero-knowledge proof (ZKP) circuits more straightforward by incorporating auditor-level insights right into your development flow with Trail of Bits.

Sindri's latest update introduces integration with Circomspect, the powerful circuit analysis tool by Trail of Bits, addressing a critical need in the ZKP development community: more assurances of circuit security and adherence to best practices from the outset.

This move streamlines the ZK development process and makes best practices in circuit design zero friction and foundational from the start rather than an afterthought. By embedding Circomspect's capabilities within Sindri's CLI, developers gain a powerful ally in their development process: Trail of Bits, a leading cybersecurity firm securing some of the world’s most targeted organizations and devices in the defense, tech, finance and blockchain industries.

Our objective at Sindri is to make ZK development more approachable and manageable for teams of any size. We work towards a future where anyone who needs it is up and running with ZK in minutes with powerful tooling and performant infrastructure experienced in a way developers have grown to expect: via API. The integration with Trail of Bits strengthens this proposition.

👇 Read on for how to begin using Circomspect in your workflow

Using Circomspect in Sindri​

You can follow our Quick Start guide for deeper walk through of the CLI in its entirety or get started with Cimcomspect x Sindri right away by following along below.

1. First install the Sindri CLI:

npm install -g sindri@latest

2. Navigate to the root directory housing your Circom main circuit. Once there run:

sindri lint

3. You will receive an output such as the following. Note, if your circuit passes all linting checks your output may differ.

[23:31:47.105] INFO: Running static analysis with Circomspect by Trail of Bits...
[23:31:47.337] WARN: circuit.circom:367:27 Using the signal assignment operator `<--` does not constrain the assigned signal. [Circomspect: CS0005]
[23:31:47.339] WARN: circuit.circom:599:9 Using the signal assignment operator `<--` does not constrain the assigned signal. [Circomspect: CS0005]
[23:31:47.339] WARN: circuit.circom:620:5 Using the signal assignment operator `<--` does not constrain the assigned signal. [Circomspect: CS0005]
...
[23:31:47.341] WARN: Found 14 problems (0 errors, 14 warnings).

If you have any errors running the tool, please check our CLI tutorial or contact us at hello@sindri.app.

Many consider on-chain zkML to be cost-prohibitive due to computational overhead and data publishing. While that remains up for debate, one thing is clear: Sindri’s powerful proving API + the modular paradigm provides a cost-efficient path towards scaling zkML for anyone looking to enrich blockchain UX.

Together with the teams at Celestia and Rollkit, we wanted to explore how these technologies synergize to unlock new paradigms in zkML applications and smart contract development. By integrating Sindri's efficient proof generation, Celestia's modular data availability, and Rollkit's customizable rollup framework, we deploy zkML in minutes (not days) across scalable block space. Together, we're paving the way for developers to create complex, user-centric experiences enabled by zkML across the modular configuration they deem best.

See the model here, otherwise let’s dive in.

Verifiable ML doesn’t have to be prohibitively expensive for operators or end users.​

The core of our findings reveal executing against zkML models with Sindri on Rollkit x Celestia is a) remarkably simple and b) cost-competitive against what’s currently possible on Layer 1 Ethereum. This makes sense given the general purpose nature of Ethereum and breakthroughs in Celestia’s modular blockchain construction + Sindri’s flexible proving API deployable across any EVM ecosystem.

Here’s a snapshot of what we discovered:

• Verifying our zkML model on Ethereum could cost in the range of $15.00 to $20.00, based on gas prices and the current Ethereum market pricing.

• In contrast, verifying a zkML model on Rollkit (without accounting for operator expenses) costs just a fraction of a cent per isolated transaction.

Comparing Verification Costs on Ethereum vs. Rollkit x Celestia​

Our objective was straightforward: assess the cost of verifying a lightweight zkML model on Ethereum against doing the same on Rollkit x Celestia. EVM compatibility and one-click deployability of Rollkit + Sindri allowed for easy deployment.

Here’s a bit about our setup:

• We chose a small neural net model for this proof of concept - simple yet effective for demonstration and applicable in a mobile app context. The model we used is trained to identify the origin region of a recipe based on ingredients. It’s a fun twist on the standard ML models and proves that zkML can have engaging, practical applications. You can find out more about that model here.

• Rollkit served as our execution layer for verification with Celestia DA. Sindri powered proof generation across both the Rollkit and Ethereum environments.

• Rollkit’s support of the Polaris EVM made deploying Sindri’s verifier contract nearly identical between Ethereum and a local Celestia devnet instance. Readers wishing to replicate our findings can easily do so following Rollkit’s Polaris EVM tutorial and Sindri’s smart contract integration walkthrough. Once deployed, proofs of verifiable inference were submitted via the Sindri API which were then routed to our verifier contracts waiting onchain.

• Some general assumptions around operator costs, rollup efficiencies, and sequencing logic were made to establish a good baseline for framing the tradeoffs. Lastly, because compute cost using Sindri is consistent in both instances, that cost has not been included in this analysis.

The Results: Demonstrated Cost Efficiency​

Our findings are compelling for those seeking to develop zkML with greater customization, powerful infrastructure, and choice of deployment:

• Verifying our zkML model on Ethereum was approximately 214286 gas, translating to a fee of around $15.00 to $20.00 at average market prices. (Source: YCharts)

• Rollkit transactions, on the other hand, cost about $0.000939 per isolated transaction (assuming a 526 byte block). This difference in cost underscores the cost efficiency of Rollkit x Celestia for running zkML models, making it an attractive platform for developers and projects keen on leveraging ML in blockchain.

Why This Matters For Builders​

Builders are always seeking design optionality and the modular paradigm expands developer choice across that spectrum. In addition to the stark cost difference between deploying your zkML application on Ethereum vs Rollkit, this end-to-end experiment establishes a few points, beyond cost savings, worth emphasizing:

• First, Sindri's serverless API and portable toolkits enable rapid deployment of zkML circuits across the blockchain environments developers already love to build on. So long as the blockchain is EVM compatible, performing zkML verified inference is streamlined - code once, deploy anywhere.

• Second, Rollkit x Celestia afforded greater control over our zkML-oriented use cases providing developers a wide range of rollup configurations and optionality paired with cost efficient blockspace on Celestia.

We’re excited to be a part of the Rollkit and Celestia ecosystem. Coupled with Rollkit and Celestia, we turn the dream of flexible zkML deployment into the standard, ushering in an era where ZK utility is globally accessible and recognized as a fundamental developer resource.

We’re eager to continue integrating with teams deploying generational applications built on Celestia and Rollkit as we build out the proving layer. If you’re a team building in the space, let’s talk.

ETHGlobal's Circuit Breaker hackathon is a beacon for the zero-knowledge (ZK) developer community, and Sindri is thrilled to be a part of it. As the inaugural ZK-focused event by ETHGlobal, this event isn't just another hackathon; it's a gathering of builders and forward-thinkers eager to push the boundaries of what's possible with ZK technology. We're here to support you, whether you're a seasoned ZK developer or just starting to explore ZK. The best part: prizes will be an added bonus. Read on to find out more.

There are also some truly amazing projects and teams joining in on the event as well including Avail, Scroll, Aztec, Privacy + Scaling Exploration, and Iron Fish.

At Sindri, we're all about removing barriers and meeting developers wherever they are in the development lifecycle. We believe in giving every developer, regardless of their background or the ecosystem they operate in, the tools and infrastructure to build and deploy with confidence. Our goal is to make high-quality backend deployment accessible to everyone, democratizing the ability to accelerate and scale projects without compromising.

Why Hack with Sindri​

We want you to help reshape what’s possible with ZK. We respect the builders at the forefront of this exciting technology, but also see the hurdles of developing, iterating, and shipping ZK solutions due to infrastructure that just hasn’t been able to keep pace with the industry. We seek to deliver productivity and developer choice in every line of code. Thus, integrating Sindri is simple! It integrates with workflows you’re accustomed to (e.g., Github, SDKs, etc) and, most importantly, it is deployed through an API, which UX developers have come to expect with infrastructure solutions. So, let’s build together.

To make things more interesting and encourage boundary pushing, we've structured two main prize categories to spark your creativity:

Prize 1: Most Unique Use of Sindri - Show us how you can creatively use Sindri’s API to solve complex problems or create something entirely new. This category rewards creative applications that leverage Sindri’s API and supported proving systems such as Gnark, Noir, Halo2, and Circom. Whether it's through rollups, interoperability solutions, DePIN, proof aggregation, or any other application, we're looking for projects that stand out.

Prize 2: Best Use of Sindri in ML x Web3 - Combine AI with Web3 in ways that challenge the status quo. If you've got an idea that merges these fields in a unique way, we want to see it. We’ve got some examples that may provide off-the-shelf inspiration here.

We’ll be hosting office hours weekly to ensure we’re making ourselves available to take on your questions or issues. Also, be sure to check out the other great prize tracks here.

More Than Just a Tool​

Sindri was built by builders just like you who value modernized tooling to get the job done in a way that “just works.” Our goal is to be your tool of choice wherever you are across the development cycle. The Sindri API has been built in a way that fits into existing application and protocol logic via our SDK and CLI tooling to streamline your ZK journey from dev to prod.

Sindri comes jam-packed with a lot of power under the hood including: serverless deployment, proprietary acceleration hardcoded into every API call, high-availability GPU nodes, out-of-the-box proof system support, near-zero latency, and more.

A Friendly Invitation​

We’re excited about the possibilities that Circuit Breaker and the broader ZK community hold. Sindri is here to support your journey, offering the tools and infrastructure needed to bring your vision to life. Join us at ETHGlobal’s Circuit Breaker hackathon and let’s explore the future of ZK technology together.

Discover more about how Sindri can support your projects by visiting our blog, GitHub, and documentation. Let's build something amazing together.

It's a big day at Sindri HQ. Over the last nine months we've been hard at work to make ZK proving infrastructure more accessible. We've done so through extraodinary developer tooling and an API-driven DevEx that developers, researchers, and builders have come to expect when designing and shipping next generation applications.

Starting today, we're officially inviting developer teams to transform their development workflows and proving environments with closed beta access to Sindri. Our closed beta prioritizes the features and utilities requested by the coders and engineers who trust our platform with their life work.

If you’d like access, you can create an account here. Let's dive in to what's in this release below!

What’s in the V1 release?​

From the outset, Sindri was envisioned as a tool built by developers, for developers building the next frontier using ZK technology. This first release will provide a suite of out-of-the-box tooling for developer, app, and research teams that need streamlined iteration and turbocharged deployment pipelines across ZK environments. Here's a sneak peek at some of things that will be shipped in this release:

• Built-in Acceleration for ZK-Proof Workloads. Sindri’s algorithms are optimized for streamlining proof generation and save over +50% on average proving time across supported proving frameworks, end-to-end. We're democratizing managed, L2-grade acceleration for any developer, rollup, or organization with no configuration overhead.

• Serverless, High-Availability Proving Infrastructure. A serverless, low-latency infrastructure backend that scales with zero-code. Today, we’ve seeded Sindri with a wide catalog of high performance hardware options to allow near-infinite scalability for mission-critical proving workloads.

• Protoype Circuits. We've provided sample circuits to assist with and inspire developer creativity. Explore how each of our supported proving sytems can be leveraged across use cases with some of these examples in action here or on our Github here.

• Support for Noir, Halo2, Gnark, and Circom Proving Systems. Support across leading ZK DSLs and frameworks with more on the way. Low degree of circuit refactoring makes integration and deployment easy while retaining developer choices.

• SDK and CLI Tooling. Tailored to modern development needs, the Sindri SDK and CLI tools allow rapid setup of proving environments in fewer than 10 minutes. Build custom scripts or start with our quickstart guide.

• Robust Development and Production Environments. We built Sindri as a lifecycle tool. Perform mock trusted setups for your unit testing and development or integrate proving keys for immediate, production-ready deployment with Sindri. Compile through Github integrations or locally via our SDK or CLI.

  Sign up for Sindri beta access.

What is Sindri Solving For?​

We’ve talked at length about the trouble with existing ZK proving infrastructure, DevOps tooling, and the move towards Hybrid Edge Cryptography. Here’s a quick refresher on the things we don’t think developers should have to manage or compromise on:

• Universal Support. Don't compromise on ZK DSLs’ performance and flexibility due to infrastructure customization needs. Find a list of our supported frameworks here.
• Bootstrap Proving Resources. Sindri eliminates the time-consuming and costly process of bootstrapping performant proving resources.
• Economical Serverless Compute. Avoid the financial and time burdens of always-on instances and over-provisioned cloud environments. With Sindri, you save time and money with instances that are 2x more cost effective than major cloud providers.
• Managed Services. Leave it to Sindri. Sidestep the hassles of self-deployed instance maintenance and unforeseen compute shortages or changes in dependencies.
• SLA Reliability and Uptime You Can Count On. Benefit from the convenience of on-demand, high availability compute, complete with SLA-backed reliability.

A Preview of Things to Come​

We’ve got a jam-packed roadmap of features to streamline ZK development:

• Circuit Hub. Discover a community-built repository of public circuits. For now, you can find some public circuit examples here, including our PageRank algorithm written in Noir.
• Managed Instances. Customize and configure your ZK environment for on the fly. This includes hardware selection, acceleration preference, and shared vs. dedicated instances.
• Expanding Framework Support. We’re committed to supporting your preferred ZK proving frameworks. If you have a specific framework request or suggestion, please let us know by emailing us at hello@sindri.app.

We’re eager to connect with those pushing the boundaries with ZK technology. Whether you have feature suggestions or are a ZK developer team in need of streamlined deployment, we’re here to listen and collaborate. Let’s talk.

Introducing Sindri — A Modernized ZK DevOps and Proving Stack​

We're proud to unveil Sindri, a modernized zero-knowledge proof (ZKP) DevOps and proving stack, designed with the developer in mind. Sindri represents our contribution to the developer ecosystem and a step towards transforming ZKPs from a niche cryptographic concept into an accessible, universal utility.

Sindri has already generated countless proofs across a myriad of popular proving systems for ZK-enabled apps. We've opened our beta for developers. Feel free to sign up here!

Persistent Problems with ZK Development Today​

ZK development is mired in trapdoors and pitfalls from development through production. Many developers fall into the trap of thinking the hard work is done once they've decided on a proving framework, fine-tuned their circuits, perhaps even self-provisioned "beefy" hosted machines from a cloud provider, and so on. The truth is: that's when many of the most complex, incessant tasks begin and existing solutions fall short.

Today's developers grapple with an array of pervasive ZK-related DevOps and infrastructure challenges, ranging from managing large proving keys and network latency to handling cold starts and versioning. Other important issues include cost control, integrating hardware acceleration, cloud infrastructure, and instance type selection, and establishing intelligent queue logic for workloads. Additionally, constant oversight of infrastructure and ensuring availability are critical. Falling short in any of these areas could lead to failure, yet proficiency in each is now a basic necessity. This underscores the urgent need for modernized tools for today's ZK developers.

(If this sounds familiar to you, email us at hello@sindri.app, and let's work together on how we can help you!)

Sindri: Edge Cryptography​

Sindri is our contribution towards transformative change at the DevOps and infrastructure level required to unlock greater developer freedom. Our initial product release allows any developer to easily access and scale production-caliber ZK proving from anywhere on the planet, across any stage in their development cycle, across the DSLs and proving systems they love, and across any ecosystem (blockchain, web2, etc.) with near-zero lines of code through the Sindri SDK and API.

Sindri is a paradigm shift toward what we call "Hybrid Edge Cryptography" — handling cryptographic processes that involve offloading intense cryptographic computations from the source. This approach is designed to provide localized, verifiable, and high-performance cryptographic computation for any device that requires it. Embracing this paradigm means continuously driving innovation toward the edge while simultaneously maintaining the flexibility to shift workloads dynamically to serverless, high-performance operators as required. We've engineered Sindri to be modular, portable, and powerful to fit the current and future needs of this paradigm and will share more soon.

For those eager to learn more about Sindri's architecture today, we encourage you to take a spin through our documentation.

Blockchain is the Substrate for ZK — the Future is Much Bigger​

While ZK has clearly found its early product-market fit in blockchain, it is just the beginning of the Sindri story. Our vision is to become the bedrock orchestration layer for ZKP development, integrating seamlessly with various proving systems, hardware vendors, and critical proving participants, and catering to an ever-expanding array of applications and use cases across digital ecosystems:

The Emerging Service Layer: We anticipate the emergence of a service layer, or "Halo Applications," where applications provide multifaceted, auxiliary services to blockchains and rollups leveraging ZK. The earliest of these can be seen in the form of breakthrough technology such as coprocessors and zkML. Expansion at this layer is inevitable and will not only enrich blockchain functionality, but it will bridge gaps between various digital ecosystems.

AI, Trust, and the Expansion: We're entrusting AI with greater decision-making power as it becomes more advanced. Enhanced cryptographic trust mechanisms are key components for reliably auditing and verifying AI actions, which ensure transparency and accountability They also enable broader, permissionless access to these AI systems. Sindri is at the forefront of this shift, building streamlined infrastructure for secure, efficient AI interactions.

Sindri Circuit Hub: An organized repository for open source circuits, offering a convenient starting point for circuit developers, aiming to enable greater composability within the circuit developer ecosystem. We will be seeding the Hub with the building blocks for verifiable PageRank in Noir, compression with Gnark, verifiable machine learning inference using Circom, and a float radius tutorial using the Axiom team's Halo2 tooling. We hope these inspire builders looking to take advantage of the unique use cases of ZK technology and we'll dig into each in more depth soon.

Permeation into Web2: The attributes that make ZKP appealing in blockchain environments can be cross-purposed into the Web2 landscape. We're actively engaged in conversations with organizations that seek to bring ZKP into the fray of environments that require high-integrity source data and computation.

Our Team and Advisors​

Our team comprises PhD-level mathematicians, engineers, and builders with rich backgrounds in cryptography, network intrusion detection, software development and design, algorithmic optimization, deep learning, and digital signal processing. As developers, operators, and former academics, we bring deep expertise in secure and trustless networks and decades of experience building critical infrastructure. Our team's current and prior work includes creating groundbreaking machine learning techniques that enhanced information retrieval and set new industry standards, pioneering the first use of unsupervised machine learning for particle identification in high-energy nuclear physics, and algorithmic optimization for zero-knowledge processing.

$5M Seed Funding: Accelerating Our Vision​

We are also thrilled to announce our $5M Seed funding, led by CoinFund with participation from strategics and angels across chip design and fabrication, signal processing, high-performance computation, and renowned figures in the fields of cryptography and blockchain. This investment will fuel our team expansion, developer network growth, and network seeding.

We're excited to join the CoinFund portfolio of world-class companies advancing zero-knowledge technology and the integration of machine learning, on and off-chain Together, we're dedicated to innovating with enhanced developer tools and pushing the boundaries of ZK technology, aiming to make blockchains more intelligent and the world's data verifiable.

Join us in shaping the ZK development landscape. For career opportunities, visit our Careers Page. To integrate with Sindri and for partnership opportunities, contact us at hello@sindri.app.

Discover more about Sindri here and stay updated by following us on Sindri's X account.

Zero-Knowledge Programs​

Inspired by this thread.

Suppose you have a function that takes in two variables and returns some result:

There are a few consequences of executing $doSomething$ the traditional way:

1. Anyone wishing to verify result will need both inputs x and y
2. They will also have to expend compute resources to run $doSomething$

In a trustless setting, you may want to keep some of the variables private or you may want to convince anyone that the result is legitimate without having to rerun the program. Zero-knowledge proofs modify the execution of your program to look more like this:

so that:

1. broadcasting result and proof reveals nothing about y
2. verifying result only requires proof and x

A major caveat is that $doSomething^{ZK}$ takes much longer to execute. Research surrounding the subject of Zero-Knowledge Proofs has proliferated in the last few years. Every work is attempting to optimize at least one of the following:

1. The runtime of $doSomething^{ZK}$
2. The verification time given result and proof
3. The size of proof

Proofs​

In this section, we present a high level overview of the KZG polynomial commitment scheme in order to explain why $doSomething^{ZK}$ generally takes so long. KZG is a popular protocol choice for blockchain developers because the proof size is small and the verification work is minimized. Furthermore, while proving still needs to happen off-chain, verification is enabled on-chain.

One way to convince someone that you’ve run code is to show your work by publishing the execution trace, i.e. all of the intermediate steps and variable values. You could convince any verifier that you ran the program at the price of giving the verifier full knowledge of private inputs. Additionally, the size of such a proof is unappealing. However, this transformation is still a useful first step towards a zero-knowledge proof.

The diagram above depicts the process of transforming pseudocode into an execution trace, which is sometimes called arithmetization. We will call the right hand side a circuit: it is a matrix with each entry given by a formula representing some intermediate value of the program. For a concrete input pair x and y, filling in the actual values of the circuit is known as witness generation.

The next step is going to turn each column of the circuit into a polynomial. This improvement is not initially obvious. In the diagram below, we have a vector of length n, which will turn into a polynomial of degree n, and it takes the same amount of data to describe both the vector and the polynomial. However, we do not intend to publish the entire polynomial for a column. Rather, we will convince a verifier that we know the global structure of the polynomial and that we can predict how it will behave in any local neighborhood.

The first phase of the polynomial argument, the global structure, functions similarly to a hash. Random hash collisions are unlikely, meaning the hash output is a sufficiently identifying property of a polynomial. Additionally, the hash is irreversible. So, an adversary cannot learn much about the pre-image given only the hash output.

The second phase of the polynomial argument, the local structure, opens up the behavior of the polynomial around any random point (note that the prover does not get to choose this). Consider first the claim: “I have a polynomial and when I plug $12$ into it, I get $42$ back”. In order to convince a hostile listener that I have full knowledge of this polynomial, I’ll need to supply more information. Like the diagram below indicates, if I know $P(12)=42$, then $P(x)-42$ will cross the x-axis at $12$. There is a programmatic way (polynomial division) to retrieve a polynomial of degree $n-1$ that crosses the x-axis in all the same places as $P(x)-42$, except at the root $12$. In short, in my role as the prover I need to supply $Q$ so that $Q(x)(x-12) = P(x)-42$. This is a very convincing argument to the verifier that I know the polynomial $P(x)$. But, to stick to the principles of ZK, I need to withhold both $P(x)$ and $Q(x)$. We already have a hashed version of $P$, so we’ll supply the hashed version of $Q$ as well.

The final act is for the verifier to evaluate the proof they have received. The prover sent along commitments for the two polynomials $P$ and $Q$ in addition to the claim that $P$ evaluates to $42$ when you plug in $12$. The verifier is not able to to directly check that the polynomial equation $Q(x)(x-12) = P(x)-42$ holds but they can check a “hashed” version of this equality, very similar to the way the commitments for $P$ and $Q$ were obtained.

That concludes the steps in a ZK proof. The “not quite zero-knowledge” comment in the diagram above deserves elaboration. If you were to rerun $doSomething^{ZK}$ many times and show a different evaluation point of the polynomial each time (the $(12,42)$ pair), then an adversary gains a little information about your polynomial $P$ each time. It would only take them $n$ communications from you to completely determine your polynomial $P$ and work backwards to get the private $x$ value. KZG does not initially qualify as a zero-knowledge protocol, but there are straightforward revisions which grant this property.

The discussion above oversimplified a lot of the “moon math” that makes the final verify equation un-cheat-able. Because of that, the complexity might be unclear. Here are some more specific comments:

1. The commitment function, or hash, is not fast. Another name for this operation is ‘multi-scalar multiplication’ or MSM. Each of the coefficients of your polynomial is represented with around 250 bits and the $\tau$ values are elliptic curve points which require around 380 bits to represent. While MSM is O(n/log(n)), n is already large enough for this to be a heavy computational burden. Additionally, KZG requires more calls to MSM than the operation described next, so this is the bottleneck.
2. Calculating Q(x) requires polynomial division. Fast fourier transform (FFT) techniques place this computation in O(n*log(n)). In addition to the complexity introduced by large n (the degree of your polynomial), recall that the coefficients are each around 250 bits.

Sindri's API​

Hopefully the discussion above has convinced you of the difficulties of producing ZK proofs. If you have your own $doSomething$ and want to convert to $doSomething^{ZK}$ then there are three major options available to you:

1. Perform all the work yourself with your own machines. There are many open source libraries available to you that already provide accelerated proving implementations on certain hardware options. Selecting the implementation that best suits your hardware setup will require a technical deep dive. Additionally, you should not underestimate the work it will take to scale this acceleration beyond your initial prototype and reconfigure the entire stack as needed to stay up to date with a rapidly evolving backdrop.
2. Plug $doSomething$ into a ZK-VM that will outsource the entire process. As long as you write your program in a way the virtual machine can understand, it will automatically convert it into a $doSomething^{ZK}$ circuit and host proofs for you. There may be limitations placed on the development of $doSomething$. For instance, a VM might have trouble with a multi-thread program which is very hard to prove. The biggest perk of competitive VM solutions is that proof acceleration is baked into their product, so that you reap the benefits of an incredibly technical field with zero headaches. However, a crucial consideration with this option is that you have very limited control. The field of ZKP is still evolving and the form $doSomething^{ZK}$ takes currently may become obsolete given research advances. You must place a lot of trust in your VM solution to keep pace with those advances while providing stability to your own application.
3. Compute the $doSomething^{ZK}$ circuit definition and upload to Sindri. Sindri's API offers the middle ground between the previous two options. You’ll need to learn a little bit of the ZK space in order to pick the proving scheme and arithmetization that is right for your use case. Additionally, you’ll have to roll up your sleeves and provide the circuit definition for us. After that, the responsibility of running proofs quickly and reliably falls to Sindri's infrastructure.

Summary​

TL;DR — Our streamlined approach, which has a deterministic ordering of bucket updates, 3 orders of magnitude fewer buckets, and removes the logic for the double/double-add, queuing, scheduling, and conflict detection/resolution, results in at least a 90% reduction in the number of EC point additions when compared to the pseudo-naive approach.

Sindri Labs developed a streamlined implementation of the Multi-Scalar-Multiply (MSM) algorithm that computes the inner product of a vector of large (e.g. 256 bit) scalars with a vector of points on an elliptic curve (EC) whose coordinates are in the finite field Fq with q roughly 384 bits in size. Our improvements are targeted at GPU and FPGA implementations.

The well-known algorithm of Pippenger (Bucket Algorithm) allows the computation to use a remarkably small number of EC point additions, but at a cost. Proposed implementations require maintaining on the order of $2^{20}$ partial sums (buckets) of EC points. Moreover, the updates to the partial sums are performed in a random order, and can cause stalls in feeding the EC point addition pipeline if point additions involving the same bucket are not separated in time by at least the length of the pipeline. Conflict resolution strategies require relatively complex logic.

Our proposed solution falls short of the theoretical minimum number of EC point additions required for an MSM with vectors of length in excess of $2^{20}$, but it has several main advantages that will make up for it.

Our solution:

• Has a simple, deterministic ordering of bucket updates. This guarantees no conflicts and obviates the need for logic to detect and resolve them (queues and schedulers) that the Pippenger approach requires.
• Removes the logic of the double or double-add method for performing an efficient scalar multiply using additions.
• Utilizes projective coordinates in Montgomery form.
• Reduces the memory footprint for the buckets by three orders of magnitude; it uses $2^{8}$ buckets instead of $2^{20}$ buckets. With so few buckets, aggregating the buckets in the final phase is of negligible cost. Therefore, we can move our finalized buckets back to the host (CPU) and aggregate them there. On an FPGA implementation, this frees block RAM because we do not have to implement the aggregation algorithm on the device.
• Allows for the precomputation of EC point additions. This is a one-time computation for all proofs that use the same common reference string (CRS). It increases the size of the CRS, so it comes at the expense of either a higher data transfer rate to the device or a larger amount of device RAM. The amount of precomputed EC point additions is an adjustable parameter.

The combined effect of a reduced memory footprint and simpler control logic offers an opportunity to realize multiple EC point addition pipelines on the FPGA and a consequent improvement from parallelization. We anticipate that our EC point addition pipeline will be shorter than the schedule of partial sum updates. This means we can break up particular bottlenecks in the pipeline if it allows for a higher clock rate.

Furthermore, this streamlined approach is more adaptable to GPUs and may open the door to more performant GPU zk-prover systems because, with the omission of the performance hits of queues, scheduling functions, conflict resolution functions, caching, and double/double-add logic, our approach will allow for a much greater GPU utilization.‍

Comparison Against the Pseudo-Naive Approach

Pseudo-naive approach problem definition

Each three-dimensional point, $G_k$, of an array of points $G$, needs to be scaled by adding to itself a corresponding number of times, $s_k$, from an array, $s$, of the same index size, $N$, as $G$. The sum of all the scaled points, $R_f$, needs to be computed and returned.

Let

where $N$ is on the order of 100 million, $G_k$ is a three-element array (x,y,z) of 377 bit integers, $s_k$ is a single 253 bit integer, and $s_k * G_k$ is an elliptic curve point scalar multiply that utilizes the double/double-add method, which uses at most $2*s_k$ EC point additions ($1.5*s_k$ on average).

Comparison

Our approach results in at least a 90% reduction in the number of EC point additions when compared to the pseudo-naive approach described above.‍

Want to chat? Give us a visit at Sindri Labs.

References

Aasaraai, Kaveh, et al. FPGA Acceleration of Multi-Scalar Multiplication: CycloneMSM. 2022, https://eprint.iacr.org/2022/1396.

Lu, Tao, et al. CuZK: Accelerating Zero-Knowledge Proof with a Faster Parallel Multi-Scalar Multiplication Algorithm on Gpus. 2022, https://eprint.iacr.org/2022/1321.

Xavier, Charles. F. pipeMSM: Hardware Acceleration for Multi-Scalar Multiplication. 2022, https://eprint.iacr.org/2022/999.