Skip to content

pantyukhov/rippled-zk-verify

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

4 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Rippled and ZK Verify Connector Implementation

This repository contains the implementation of a Rippled server and a ZK (Zero-Knowledge) verify connector. The purpose of this project is to enable ZK_verify transactions, enhancing privacy and security in blockchain transactions.

Introduction

The Rippled server is an open-source blockchain server that implements the XRP Ledger protocol. This project extends its functionality by integrating a ZK verify connector, allowing for the execution of ZK_verify transactions which provide an additional layer of privacy and security. Zero-knowledge proofs are cryptographic methods that allow one party to prove to another that a statement is true without revealing any information beyond the validity of the statement itself. This capability is especially valuable in blockchain and privacy-preserving applications where you need to verify transactions or data without exposing the underlying information.

ZK Verify Connector

The ZK Verify Connector is built upon the ZKInterface code repository, which is a standard framework and protocol designed to facilitate communication and interoperability between different zero-knowledge proof (ZK) systems and applications.

ZKInterface Overview

Key Components and Features

  • Language and Platform Agnostic: The zkInterface is designed to be independent of any specific programming language or cryptographic scheme. This flexibility allows developers to implement and interact with ZK systems using the tools and languages they are most comfortable with.

  • Standardized Communication: It defines a standard way for ZK systems to communicate, specifying how to format and exchange messages. This standardization is crucial for interoperability, enabling different ZK systems and applications to understand each other and work together seamlessly.

  • Support for Various ZK Schemes: The interface supports a wide range of ZK schemes, including SNARKs (Succinct Non-interactive ARguments of Knowledge). This broad support allows developers to choose the most appropriate ZK technology for their specific needs.

The zkInterface protocol acts as a bridge between ZK circuits (mathematical descriptions of computations to be proved) and ZK provers/verifiers (systems that generate and verify proofs), facilitating the following process:

  1. Circuit Definition and Serialization: Developers define a computation or logical circuit that needs to be proved in a zero-knowledge manner and serialize it according to zkInterface specifications.

  2. Proof Generation: Using the serialized circuit and private inputs, the ZK prover generates a proof, asserting knowledge of inputs that satisfy the circuit's conditions without revealing the inputs themselves.

  3. Transaction Submission: The ZKProof, along with CircuitHash, VerificationKey, and other transaction details, are submitted to the Rippled server as a ZKVerify transaction.

  4. Verification: The Rippled server, equipped with the ZK Verify Connector, verifies the ZKProof against the provided CircuitHash and VerificationKey.

  5. Consensus and Ledger Update: If the proof is valid, the transaction is verified, and its details are recorded on the XRP Ledger, maintaining data integrity and privacy.

ZKVerify Transaction Schema

A ZKVerify transaction leverages Zero-Knowledge (ZK) proof capabilities to enhance privacy and security while complying with the operational protocols of the XRP Ledger. This schema enables integration with the existing Rippled server infrastructure, introducing support for ZK transactions.

Fields in the ZKVerify Transaction

  • TransactionID: A unique identifier for the transaction, generated by the Rippled server.
  • Account: The XRP Ledger account initiating the ZKVerify transaction.
  • TransactionType: Set to ZKVerify to denote a ZK transaction.
  • Fee: The network fee for processing the transaction, denominated in XRP.
  • Sequence: The transaction's sequence number for the initiating account.
  • ZKProof: An encoded string representing the zero-knowledge proof, including the proof and any necessary public inputs or commitments.
  • CircuitHash: A hash of the circuit definition used to generate the ZK proof, ensuring both prover and verifier reference the same computational framework.
  • VerificationKey: The public key associated with the ZK circuit, used by verifiers to validate the ZKProof.
  • Signature: Digital signature from the account initiating the transaction, ensuring authenticity and non-repudiation.
  • Memo: An optional field for additional transaction information in a zero-knowledge context, encoded for both human and machine readability.

Processing Flow

  1. Circuit Definition and Serialization: Developers define a ZK circuit for a specific computation or verification task and serialize it following the zkInterface specifications.
  2. Proof Generation: With the serialized circuit and private inputs, the ZK prover generates a proof that they know a set of inputs satisfying the circuit's conditions, without revealing the inputs themselves.
  3. Transaction Submission: The generated ZKProof, along with the CircuitHash, VerificationKey, and other transaction details, are submitted to the Rippled server as a ZKVerify transaction.
  4. Verification: Upon receiving the transaction, the Rippled server, equipped with the ZK Verify Connector, verifies the ZKProof against the provided CircuitHash and VerificationKey.
  5. Consensus and Ledger Update: If the proof is valid, the transaction is verified, and its details (excluding any private inputs) are recorded on the XRP Ledger, ensuring transaction data integrity and privacy.

Rust Bridge for ZK Interface Integration

The core component enabling the integration between the Rippled server, written in C++, and the zkInterface, is a Rust library that acts as a bridge. This Rust bridge facilitates the communication and data exchange between the C++ based Rippled server and the zkInterface, leveraging Rust's interoperability with C++ and its efficient handling of cryptographic operations.

Why Rust?

Rust is chosen for this critical part of the project due to its performance characteristics, safety guarantees, and its strong ecosystem around cryptography and blockchain technologies. Rust's zero-cost abstractions and memory safety features make it an ideal choice for implementing the complex logic required for zero-knowledge proofs, ensuring both efficiency and security.

Architecture Overview

The architecture consists of three main components:

  1. Rippled Server (C++): The Rippled server manages the ledger and processes transactions on the XRP Ledger. It is extended to support ZKVerify transactions.

  2. Rust Bridge: The Rust library acts as a middleware, converting and passing data between the Rippled server and the zkInterface. This includes encoding and decoding data structures, invoking zkInterface functions, and managing memory safely across the boundary between Rust and C++.

  3. zkInterface (Rust/C++): The zkInterface facilitates the creation, serialization, and verification of zero-knowledge proofs. It is designed to be language-agnostic, with bindings for different programming languages, including Rust and C++.

Implementation Details

The Rust bridge is implemented as a library that is compiled into a format compatible with the C++ environment of the Rippled server. This involves:

  • FFI (Foreign Function Interface): Using Rust's FFI capabilities to define and expose a set of functions that can be called from C++. These functions include operations to initiate ZK proof generation, serialize/deserialize data for the zkInterface, and perform cryptographic computations.

  • C++ Bindings: Creating bindings in C++ to call the Rust library functions, allowing the Rippled server to interact with the Rust code as if it were a native C++ library.

  • ZK Proof Operations: The Rust bridge includes logic for generating ZK proofs, interfacing with the zkInterface to define circuits, and verifying proofs against given circuit definitions and verification keys.

This Rust bridge significantly enhances the Rippled server's capabilities, enabling it to support zero-knowledge proofs for transactions, thereby improving privacy and security on the XRP Ledger.

Detailed Instructions for Setting Up the Project

Clone the Repository

First, you need to clone the repository to your local machine. This step involves copying all the files from the online repository to a directory on your computer, which will allow you to work on the project locally.

  • Command:

    git clone https://github.com/pantyukhov/rippled-zk-verify.git

    Explanation: This command creates a copy of the rippled-zk-verify repository in your current working directory. git clone is used to clone a repository from GitHub, allowing you to have a local version of the project.

Build the Project

Once the repository is cloned and submodules are initialized, the next step is to build the project. This involves compiling the code and preparing it for execution.

  • Command:

    sh build.sh

    Explanation: This command executes the build.sh script located in the root of the cloned repository. The script is responsible for compiling the project and resolving any dependencies. Running this script prepares the project for use by building the necessary components.

Test the Project

After building the project, it's important to test it to ensure everything is working as expected. This step runs predefined tests to verify the functionality of the project.

  • Command:

    sh test.sh

    Explanation: The test.sh script is executed to run the project's tests. These tests are designed to automatically verify that the project's key features and functions operate correctly. Successfully passing the tests indicates that the project is set up correctly and ready for development or use.

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages