Summa
GitHubTelegram
V2
V2
  • Introduction
    • Overview
    • Protocol Flow
    • Resources
  • CRYPTOGRAPHIC PRIMITIVES
    • Zero-Knowledge Proof
    • Univariate Polynomial Grand Sum
    • KZG Commitment Scheme
  • Backend
    • summa-solvency
  • Circuits
    • Univariate Grand Sum
  • Smart Contract
    • Summa.sol
      • Solidity API
    • Verifiers
  • Benchmarks
  • Open Issues
Powered by GitBook
On this page
  1. Smart Contract

Verifiers

PreviousSolidity APINextBenchmarks

Last updated 1 year ago

Summa utilizes three verifier contracts and one key contract: , , , and . The SnarkVerifier and VerifyingKey contracts must be regenerated whenever custodians redeploy the Summa contract with new configurations, as they are specifically generated to a particular circuit configuration by the .

For example, let's assume the Summa contract is initially deployed with the configuration to support two cryptocurrencies as specified by the custodian. This setup allows users to verify their inclusion proofs containing two currencies within the Summa contract. If the custodian decides to accommodate three cryptocurrencies for user convenience, they must redeploy the Summa contract with newly generated SnarkVerifier and VerifyingKey contracts configured for three cryptocurrencies.

In contrast, the GrandSumVerifier and InclusionVerifier contracts do not need to be regenerated for new deployments. These contracts are capable of verifying proofs regardless of size, including any number of cryptocurrencies included in the proof.

This means that custodians might not need to deploy these contracts themselves if they are already deployed on EVM.

Note: Generating a SnarkVerifier for more than 9 currencies may exceed the Ethereum mainnet contract size limit.

SnarkVerifier
GrandSumVerifier
InclusionVerifier
VerifyingKey
halo2-solidity-verifier