Siniel: Distributed Privacy-Preserving zkSNARK

Siniel: Distributed Privacy-Preserving zkSNARK

Speakers: Yunbo Yang

Conference: NDSS Symposium

YouTube: https://www.youtube.com/watch?v=7x2iHPfERRc

Overview

This talk introduces Siniel, a novel distributed privacy-preserving zkSNARK (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) system designed to enhance the security and efficiency of delegated proof generation. Presented by Yunbo Yang, Siniel addresses critical limitations present in existing state-of-the-art solutions, particularly the need for interactive engagement from the delegator during the proof generation phase. The core innovation lies in its introduction of non-interactive consistency checkers, which allow a delegator to offload the computational burden of proof generation to multiple workers while maintaining strong security guarantees against malicious behavior, without needing to actively participate in the verification process.

The significance of Siniel stems from its ability to make delegated zkSNARK computations more practical for real-world applications. By eliminating the delegator's online involvement in consistency checking, Siniel reduces communication overhead and improves overall system usability, critical factors for scalable decentralized systems. This work contributes to the ongoing efforts to build robust and privacy-preserving cryptographic protocols that can operate securely in adversarial environments, particularly where computational tasks are distributed among potentially untrustworthy parties.

Background

▶ Watch: Introduction and ZK-SNARK Background (0:00)

Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge (zkSNARKs) are cryptographic proof systems that allow one party (the prover) to convince another party (the verifier) that a statement is true, without revealing any information beyond the truth of the statement itself. They are "succinct" because the proofs are small and "non-interactive" because, after an initial setup, the prover can generate a proof that the verifier can check without further communication. This makes them highly valuable for privacy-preserving computations, blockchain scaling, and secure delegation.

A typical zkSNARK computation involves several key components. The speaker breaks down the structure into three parts:

1. POP (Polynomial Oracle Protocol): Here, the prover gives the verifier "oracle access" to a polynomial. The verifier can query this polynomial at a public point to get its evaluation. This involves basic polynomial arithmetic like addition, multiplication, and point evaluation.
2. PCS (Polynomial Commitment Scheme): Instead of direct oracle access, the prover commits to a polynomial. The verifier then provides a challenge point (alpha), and the prover responds with the polynomial's evaluation at alpha, along with an opening proof.
3. Fiat-Shamir Transformation: To make the proof system non-interactive, the Fiat-Shamir heuristic is applied, which converts an interactive proof into a non-interactive one by replacing the verifier's challenges with outputs from a random oracle.

In the context of delegated zkSNARKs, a delegator wants to outsource the computationally intensive task of generating a zkSNARK proof to one or more workers. However, a significant challenge arises from the potential for workers to be malicious. Prior state-of-the-art systems, such as EOS, required the delegator to engage online with workers during the proof generation phase. Specifically, EOS needed the delegator to invoke an interactive consistency checker to verify the correctness of the POP computation, ensuring that workers did not engage in malicious behaviors. This interactivity is a major drawback for real-world applications, as it imposes an online burden on the delegator, negating some of the benefits of delegation. The problem thus lies in designing a delegated zkSNARK system where the delegator can remain offline after the initial setup, yet still be assured of the correctness and integrity of the proof generated by potentially malicious workers.

Key Findings

▶ Watch: Siniel's Core Requirements: Non-interactive, secure (4:00)

Siniel's primary contribution is a novel distributed privacy-preserving zkSNARK system that significantly reduces the delegator's involvement, moving from an interactive model to a non-interactive one. The key findings and contributions can be summarized as follows:

1. Non-Interactive Consistency Checking for the Delegator: Unlike previous systems such as EOS, Siniel allows all workers to collectively use a non-interactive consistency checker to verify the correctness of the entire POP computation. This means that after providing initial information, the delegator no longer needs to engage with the workers for further verification. The delegator ultimately receives a correct proof without online interaction during the proof generation phase.
2. Security Against Honest Majority with Malicious Corruption: Siniel is designed to be secure even when a minority of the workers are malicious. The system ensures that the overall computation remains correct and private, provided that an honest majority of workers are present. This resilience against malicious actors is crucial for real-world distributed systems.
3. Lightweight Operation for the Delegator: By removing the interactive consistency checking burden, Siniel makes the delegator's role significantly lighter. This is a critical improvement for applications where the delegator may have limited computational resources or connectivity, or simply prefers an asynchronous model.
4. Formalization and Mitigation of Three Potential Attack Vectors: The research formalizes three distinct attack scenarios against zkSNARK computation in a delegated setting and proposes specific, non-interactive solutions within Siniel:

• Inconsistent/Invalid Witness Commitment: Malicious workers might generate an invalid commitment to a share of the private witness or alter the delegator's provided witness. Siniel introduces a witness consistency checker to prevent this.
• Deviation in POP Computation: A malicious worker might commit to a correct share of the witness but then use a different share for the POP computation, or deviate from the protocol entirely, generating invalid commitments to output polynomials. Siniel employs a POP consistency checker to ensure correctness between prover polynomials and their commitments, and the integrity of the POP computation itself.
• Invalid Final Proof Generation: Malicious behavior could lead to the generation of an invalid final proof. Siniel addresses this by requiring workers to collectively reconstruct and verify the final proof.

These findings collectively represent a significant step forward in making delegated zero-knowledge proofs more practical, secure, and efficient for a wide range of applications requiring privacy and verifiable computation.

Technical Deep Dive

▶ Watch: First Attack: Inconsistent Witness & Solution (4:40)

Siniel's architecture is built around ensuring consistency and correctness across multiple workers in a non-interactive manner. The speaker outlines the general zkSNARK computation circuit as a sequence: a worker takes a witness (w) as input, performs POP computation to generate prover polynomials (px), commits to these polynomials (generating commitment p), opens them at an evaluation point (using a random oracle to get evaluation PT and opening polynomial HX), and finally commits to HX. Siniel integrates three distinct checkers to secure this process against malicious workers.

1. Witness Consistency Checker

This checker addresses the first attack vector: a malicious worker generating an inconsistent or invalid commitment to a share of the private witness, or altering the private witness sent by the delegator.

• Delegator's Role (Offline Phase): The delegator, in addition to sharing the witness, generates a share of a random element alpha and the corresponding share of the evaluation of the witness polynomial at alpha (WA) for each worker.
• Worker's Role (Verification Phase):

1. Each worker commits to its share of the witness polynomial.
2. It generates the polynomial evaluation (e.g., WA) along with an opening proof (pi) and sends these to other workers.
3. All workers jointly reconstruct the random element alpha.
4. They compute the evaluation of their witness polynomial at alpha and verify its opening proof.
5. Finally, all workers jointly recover the full evaluation WA and check if it matches another independently computed WA (or the expected value based on shares). If each evaluation proof is valid and the reconstructed WA is consistent, the witness is deemed correct.

The Q&A section clarifies the necessity of this initial witness check. A malicious worker might guess a part of the witness (e.g., a bit constraint, where B * (1-B) = 0 means B is 0 or 1). Even if the final proof fails due to an incorrect witness, the abortion of the POP computation could lead to privacy leakage. This check aims to detect such malicious witness tampering early, preventing privacy leaks that might occur if the computation aborts later due. The speaker references a paper published in USENIX Security 2025 that formalizes an "additive attack" in EOS, where errors (cross terms) are added into shares during Beaver multiplication, leading to final proof failure and potential witness leakage. The witness consistency checker proactively guards against such scenarios.

2. POP Consistency Checker

This checker prevents a malicious worker from committing to a correct share of the private witness but then using a different share during the actual POP computation, or deviating from the POP protocol, leading to invalid commitments to output polynomials.

• Secret-Shared Based Arithmetic: The core idea here is to perform POP computation using secret-shared arithmetic. This means that operations like addition and multiplication are performed on shares of values rather than the values themselves. Crucially, these operations exhibit linear homomorphic properties when performed on shares.
• Beaver Multiplication: For multiplication of shares, Siniel employs the Beaver multiplication protocol, a standard technique in secure multi-party computation (MPC) to securely compute products of secret-shared values without revealing the underlying values.
• Tag-Based Verification: To ensure the correctness between prover polynomials and their commitments, and the integrity of the POP computation, the delegator generates a tag along with a key (mu, vi) for each worker.
• For a prover Pj, it receives mu and VP0, VP1, ..., VPD (keys corresponding to polynomial coefficients).
• A tag tau for a share wi is defined as tau = mu * wi + vi. This structure ensures that combining tags correctly reflects the combination of shares.
• Suppose an output polynomial px is p0 + p1*x + ... + pd*x^d. A worker has inputs p0 to pd and corresponding tags.
• Verification Steps:

1. Workers first open their share of px at a public point along with an opening proof.
2. They use random linear combinations to combine their shares of p0 to pd and their corresponding tags tau_p0 to tau_pd. This results in a combined tag corresponding to the evaluation of px.
3. Workers then verify the opening proof of px.
4. Finally, they use random linear combinations to combine all keys (mu, VP0 to VPD) and verify that the combined keys are valid with the combined shares and tags. This ensures that the polynomial operations were performed correctly on the shared data.

3. Final Proof Verification

This checker addresses the final potential attack: a malicious worker generating an invalid final proof.

• Solution: The solution is straightforward: all workers jointly reconstruct the final proof and then collectively verify its validity. If the proof fails verification, it signals malicious behavior.

By integrating these three non-interactive checkers, Siniel constructs a robust protocol where the delegator's trust assumption on individual workers is significantly reduced, and their online presence is minimized. The combination of secret-shared arithmetic, Beaver multiplication, and cryptographic commitment schemes forms the backbone of its security model.

Demo / Proof of Concept

▶ Watch: Second Attack: Malicious POP Computation & Solution (6:30)

The speaker presented an implementation of Siniel, comparing its running time against a naive Marlin proof prover and the state-of-the-art EOS system. The implementation results were depicted in figures (though not detailed in the transcript, the speaker explicitly mentions "these figures are the results of the implementation").

The comparison included:

• Running time of the naive Marlin proof prover: This serves as a baseline for a standard, non-distributed zkSNARK prover.
• Running time of EOS: This represents a state-of-the-art delegated zkSNARK system, which Siniel aims to improve upon, particularly regarding delegator interactivity.
• Running time of Siniel: The proposed system.
• Running time of EOS worker: This specifically measures the computational load on individual workers in the EOS system.
• Running time of Siniel worker: This measures the computational load on individual workers in the Siniel system.

While specific numerical results (e.g., percentages of speedup or overhead) are not provided in the transcript, the presentation of these comparative figures indicates that the researchers have built a working prototype. The implication is that Siniel achieves its security and non-interactivity goals without incurring prohibitive performance costs compared to existing solutions. The comparison with worker-specific running times suggests an analysis of the distribution of computational load, which is critical for a distributed system. The successful implementation and presentation of comparative performance data serve as a strong proof of concept for the practicality and efficiency of the Siniel design.

Defensive Implications

▶ Watch: Siniel Implementation and Performance Results (10:45)

Siniel offers significant defensive implications for the design and deployment of systems leveraging delegated zkSNARKs, particularly in environments where trust in individual computation nodes (workers) cannot be fully assumed.

1. Reduced Delegator Trust Assumptions: The most critical implication is the shift from an interactive trust model to a non-interactive one for the delegator. Defenders can now deploy zkSNARK-based applications where the delegator (e.g., a user, an organization) does not need to be online or actively monitor the proof generation process. This simplifies system architecture, reduces operational overhead, and makes delegated private computation much more scalable and resilient to delegator-side failures or latency issues.
2. Enhanced Security Against Malicious Workers: Siniel's comprehensive set of non-interactive consistency checkers (witness, POP, and final proof) provides robust protection against various forms of malicious worker behavior. This means that even if a minority of workers attempt to tamper with the witness, deviate from the protocol during intermediate computations, or submit an invalid final proof, the system is designed to detect and prevent such attacks. This strengthens the overall integrity and privacy of the outsourced computation.
3. Privacy Protection During Aborted Computations: The witness consistency checker is particularly important for privacy. By detecting malicious witness tampering early, Siniel prevents scenarios where a computation might abort later due to an incorrect witness, which could inadvertently leak partial information about the private witness. This proactive privacy protection is a critical defensive measure.
4. Foundation for Robust Decentralized Applications: For decentralized applications (dApps) and blockchain systems that rely on off-chain computation or privacy-preserving data processing, Siniel provides a more secure and efficient method for generating verifiable proofs. Developers can build systems that leverage the power of zkSNARKs for scalability and privacy without imposing heavy interactive burdens on users or central entities.
5. Guidance for Future Protocol Design: The formalization of attack vectors and the design of specific non-interactive mitigation strategies in Siniel provide a blueprint for future research and development in secure multi-party computation and delegated proving systems. The techniques, such as secret-shared arithmetic with Beaver multiplication and tag-based verification, are valuable tools for any protocol designer aiming to secure distributed cryptographic tasks.

In essence, Siniel empowers defenders to build more secure, private, and operationally efficient systems by outsourcing complex cryptographic computations to untrusted parties, confident that the integrity and privacy of the results will be maintained without constant oversight.

Key Takeaways

• Siniel eliminates delegator interactivity: It removes the need for the delegator to be online and interactively verify proofs during the distributed zkSNARK generation process, a significant improvement over prior works like EOS.
• Robust security against malicious workers: Siniel is designed to be secure against an honest majority with malicious corruption, formalizing and mitigating three specific attack vectors against delegated zkSNARK computations.
• Three non-interactive consistency checkers: The system integrates a witness consistency checker, a POP consistency checker (using secret-shared arithmetic and Beaver multiplication), and a final proof verification step to ensure correctness throughout the computation.
• Lightweight delegator operation: By shifting verification responsibilities to the workers and making checks non-interactive, Siniel significantly reduces the computational and communication burden on the delegator.
• Practical implementation demonstrated: The research includes an implementation of Siniel, with comparative performance analysis against Marlin and EOS, indicating its practical viability and efficiency.

About the Speaker(s)

The talk was delivered by Yunbo Yang. Based on the provided metadata and transcript, Yunbo Yang is the sole speaker for this presentation. The transcript also indicates that Yunbo Yang can be contacted via Telegram, WhatsApp, WeChat, or email, and maintains a personal website. Further detailed biographical information, such as academic affiliations or specific roles, was not provided in the input materials.