Butter Network
Github
  • 🌈About Butter Network
  • 🔥ZK Light Client
    • Understanding Light Client
    • Refactored ZK Light Client
  • 🔥Omnichain Development
    • Omnichain Isomorphism
    • More Possibilities
  • 🌈Butter Omnichain Messaging Integration
    • Introduction
    • Integration Guide
      • Message
      • Message with Ton
      • CALLDATA
      • Message And Relay
    • Contract Interface
    • Fee
    • Deployed Contracts
    • 👨‍💻API for Omnichain Message
      • GET Message History by Source Address
      • GET Message Info by Id
      • GET Message Info by Source Hash
  • 🔥Butter Bridge Integration
    • Integration Guide
    • Contract Interface
    • Fee
    • Deployed Contracts
  • 💰Butter Swap Integration
    • Introduction
    • 🟢Integration Guide
      • Contract Interface
      • Fee
    • Deployed Contracts
      • v2.1
    • 👩‍💻API for Routing
      • Integration Guide
      • GET /route
      • GET /swap
      • GET /routeAndSwap
      • GET /supportedChainList
      • GET /findToken
      • 🔴Error Code List
    • 👨‍💻API for Swap Data
      • GET Swap History by Source Hash
      • GET Swap History by Source Address
      • GET Swap Info by Order ID
      • GET Supported Chain Detail List
      • GET Supported Token Detail List
  • 💰Butter Swap User Guide
    • 🫂User Guide
  • Butter Swap SDK
    • Install
    • Config SDK
    • Request Routes
    • Execute Route
    • Others
  • Butter Swap Widget
    • Usage
  • 📢Resources
    • 🏠Website
    • 🫂Telegram
    • 📄X
Powered by GitBook
On this page
  • Understand ZK-Proof
  • Refactored ZK Light Client
  1. ZK Light Client

Refactored ZK Light Client

PreviousUnderstanding Light ClientNextOmnichain Isomorphism

Last updated 1 year ago

Understand ZK-Proof

Zero-knowledge proofs (ZKPs) are a form of cryptographic protocol that allows one party, the prover, to prove to another party, the verifier, that a certain statement is true without revealing any information beyond the validity of the statement itself. In other words, zero-knowledge proofs enable the sharing of proof of knowledge without sharing the knowledge itself.

Refactored ZK Light Client

In the original light clients verification network, clients need to store the public keys of all current validators along with their respective weights. Verifying the validity of a block requires accessing all the public keys of the validator set and aggregating the public keys of the validators participating in block signing (MAPO Relay Chain uses aggregated BLS signatures). By employing zero-knowledge proofs, however, the process above can be expressed through arithmetic circuits, generating the corresponding zero-knowledge proofs;

This now simplifies verifying the legitimacy of a constant-sized zkSNARK proof, thus improving the efficiency of the light clients verification network while maintaining its decentralization.

In this design, the light client no longer needs to store the public keys and weights of all validators in the current validator set. Instead, it only stores the commitment value (hashed values of the industrial and weight information of all validators encoded) of the public keys and weights of the current validator set. The calculations for aggregating public keys and verifying the validity of the aggregated BLS signature are both expressed through arithmetic circuits and computed using the to generate zero-knowledge proofs.

Groth16 protocol
🔥
Page cover image