ZKML
March 1st, 2024

Machine learning has transformed the technological landscape, enabling systems to learn from data, identify patterns, and make decisions with minimal human intervention. Into this transformative era of machine learning steps in ZKML (Zero-Knowledge Machine Learning), a pioneering concept that marries the privacy-preserving concept of zero-knowledge proofs with the data-driven insights of machine learning. This synergy enables the creation of models that can analyze and learn from encrypted data without ever accessing the raw data itself, like it is done on traditional machine learning models.

This document is designed as a reference and guide into ZKML. This includes instructions on how to use the products provided by its Web3 team (https://zkml.systems). Currently, we offer the capabilities to do the following:

  1. Perform anonymous transactions with our Privacy Router.

  2. Search for information securely using our search engine, zkSearch.

  3. Use our zero-knowledge operating systems, zkOS.

  4. Send and receive messages with others under zero-knowledge encryption using Privacy-Centric VoIP.

  5. Browse with an using zkShield

  6. Perform cross-chain transactions between blockchains such as Ethereum, Arbitrium, Ripple, Oasis, Mina, Zcash, Monero, etc.

Our Solutions

  1. Privacy Router

  2. zSnarky

  3. Privacy-Centric VoIP

  4. zkShield

  5. zkSearch

  6. zkOS

  7. Mobile zkOS

  8. Cross-chain interoperability

  9. Privacy Router

Privacy router is a core component for ZKML. It is the confidential ledger used to incorporate private transactions from private accounts. Access to these accounts is strictly limited to designated individuals, ensuring privacy and security within the framework. Servers or nodes using the privacy router connected to a series of known external servers regardless of the geographic location of the server which initiated the connection. The IP address of the connecting server is anonymous to the the public.

To configure this, add a list of trusted servers to your computer using the server ip addresses and the port on the server for connection.

  • Configuring with a proxy

First configure the proxy as a cluster by generating unique seeds to encompass all your servers. You can do this by installing rippled, Conan and Git on your computer. Here are the steps:

With Git run the following command:

git checkout master

With the rippled package in your computer you will need CMake, and a C++ compiler to build the package. Setup the installed Conan like so:

conan profile new default --detect

Update its compiler settings:

conan profile update settings.compiler.cppstd=20 default

add

Now in the master folder of rippled, create a build directory and cd into it:

mkdir .build
cd .build

Generate a CMake file for the build configuration:

conan install .. --output-folder . --build missing --settings build_type=Release
conan install .. --output-folder . --build missing --settings build_type=Debug

Configure CMake and pass the toolchain file just generated:

cmake -DCMAKE_TOOLCHAIN_FILE:FILEPATH=build/generators/conan_toolchain.cmake -DCMAKE_BUILD_TYPE=Release ..

Build rippled:

cmake --build .

With rippled installed, generate a unique seed by using the validation_create method from the rippled package:

Run the following command:

rippled validation_create

You will get a loading response from "etc/rippled.cfg” saying you are connected to port 127.0.0.1:5005 with a JSON object response containing the status message your new unique validation secret key, your public key and your key for validation:


{
   "result" : {
      "status" : "success",
      "validation_key" : "BEE SOLA SPEED BIT COL UDM BROD DEEP GAME ARIA ROM YARN",
      "validation_public_key" : "n5aedafdfADFA4W44WDdkbfg34Fdjdd484785webhbke",
      "validation_seed" : "ssYradgdYdf46dfgdggg4a"
   }
}

On each of your cluster servers, in “master/cfg/rippled-example.cfg”, list the IP address and ports of all members of the cluster under the [ips_fixed] section. The port number must match the protocol = peer port. This port is typically located at 51235:

[ips_fixed]
192.165.0.1 51235
192.165.0.2 51235

Set the server’s node seed to their validation seed values generated with validation_create:, under the [node_seed] section:

[node_seed]
ssYradgdYdf46dfgdggg4a

Set the server’s cluster members using their public key values under the [cluster_nodes] section.

[cluster_nodes]
n5aedafdfADFA4W44WDdkbfg34Fdjdd484785webhbke
n43Bdadrffg43dkaAfdggd45fldg8adgarfbdHa3wjab

Save the changes in “master/cfg/rippled-example.cfg” and restart rippled on all cluster servers:

# systemctl restart rippled

To view members of your new cluster, run the following command:

rippled peers

You will be able to see the proxies you just added in a JSON object response similar to this:

{
  "result" : {
    "cluster" : {
        "n5aedafdfADFA4W44WDdkbfg34Fdjdd484785webhbke": {
          "age": 1
        },
        "n43Bdadrffg43dkaAfdggd45fldg8adgarfbdHa3wjab": {
          "age": 1
        }
    },
    "peers" : [
      ... (omitted) ...
    ],
    "status" : "success"
  }
}

2. zSnarky

zSnarky is a cryptographic proof that states the possession of information by a party without the information being revealed. This concept was inspired by Zcash the first to implement zkSnarks (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) on a blockchain.

zSnarky involves 3 core cryptographic methods which are the trusted setup or key generation, proof of generation, and proof of verification. These components work together to ensure that the prover can demonstrate knowledge of a secret (the "witness") to a verifier without actually revealing the secret itself. This process is non-interactive, meaning it doesn't require any direct communication between the prover and the verifier after the initial setup phase.

The Trusted Setup

This is the setup phase of zSnarky which involves the generation a common reference string (CRS) shared between the prover and verifier. This CRS includes a proving key and a verification key. The CRS acts as a shared foundation for the cryptographic proofs, ensuring that both parties are working from the same set of assumptions and parameters. It relies on the elliptic curve cryptography (ECC) for key generation. The security of elliptic curve cryptography (ECC) relies on the infeasibility of determining the discrete logarithm of a random elliptic curve element with respect to a publicly known base point.

Generating Elliptic Curve Points

A specific elliptic curve is chosen based on security parameters. This curve typically has a defined equation, typically of the form:

A base point G is then selected on the curve. This point is known and used by all participants in the system. The cryptographic strength of the system partly depends on the properties of G. After this, the cryptographic keys are generated through scalar multiplication of the base point G. For a randomly chosen scalar k, the point P = kG is computed on the curve. The intractability of determining k given P and G underpins the security of the keys.

Proof of Key Generation

Utilizing the elliptic curve points generated from combinations of secret scalars and the base point, the keys are used to encode the logic of the computation that the prover wants to prove. The encoding is such that it allows the prover to generate a proof by demonstrating knowledge of a witness to the computation without revealing the witness itself.

Proof of Key Verification

With the elliptic curve points, verifier is able to check the validity of the proof with respect to the encoded computation. The key includes points that allow the verifier to perform a series of checks on the proof, ensuring it corresponds to a valid execution of the computation as encoded in the proving key.

3. Privacy-Centric VoIP

ZKML enhances communication security through a series of rerouting on top of Ator to provide Voice over Internet Protocol (VoIP) services for internet-based voice and video calls. This strategic layer underscores a commitment to user privacy and secure communications, combining zero-knowledge proofs (ZKP) specifically for privacy-focused VoIP (Voice over Internet Protocol). This will enhance privacy by allowing one party (the prover) to prove to another (the verifier) that a statement is true without revealing any information about the statement itself.  For example, using ZKP can authenticate a caller's identity to the system without revealing their actual identity to the receiver or any intermediary systems, ensuring that only authorized users initiate calls.

Private Data Sharing

In a collaborative environment, ZKML can enable users to share certain pieces of information with others securely and privately. No sensitive data is exposed during the communication process. A basic and simplified example guide on how this can be achieved is provided below:

Client Registration

For simplicity, we'll consider a generic ZKP protocol that allows a prover to demonstrate knowledge of a secret (e.g., a user's credentials) to a verifier (e.g., a VoIP server) without revealing the secret itself. Register with the VoIP service.

The service should generate a cryptographic key based on your credentials, to be used in the ZKP process. If successful, proceed with the call setup.

Call Setup

Upon successful proof verification, the VoIP service should establishe a communication channel between the caller and callee, ensuring the call is encrypted end-to-end.

Pseudo-Code Example

This demonstrates the ZKP verification process for call initiation (written in python):

CRS = generate_common_reference_string()
user_credentials = register_user("username", "password")
user_proof_key = generate_proof_key(user_credentials)

def initiate_call(caller_proof_key):
    zkp = generate_zkp(caller_proof_key, CRS)
    if verify_zkp(zkp, CRS):
        print("Proof verified. Establishing call...")
    else:
        print("Proof verification failed. Call denied.")

initiate_call(user_proof_key)

Ensure the chosen ZKP scheme is secure and the setup phase is conducted safely to prevent leaks of all sensitive data.

4. zkShield

zkShield is a security layer which ensures the integrity of information being transferred in the system. Behind it lies a fully homorphic encryption, allowing operations on encrypted data without needing to decrypt it first. For zkShield to be fully homorphic, the TFHE library has to be utilized. Begin by installing the library into your pc or hardware machine to ensure you can perform encrypted computations:

mkdir build
cd build
cmake ../src -DENABLE_TESTS=on -DENABLE_FFTW=on -DCMAKE_BUILD_TYPE=debug
make

With these parameters, the gate bootstrapping runs in about 10-20 ms, The LWE estimator made security estimates to change according to any potential data attacks and the updates/adapts itself. Double check the estimates and update your code with the new safe parameters.

To reproduce the estimate, copy the code below and run on http://aleph.sagemath.org/:

Code:

from sage.all import load, sqrt, RR, ZZ, pi, oo
load('https://bitbucket.org/malb/lwe-estimator/raw/HEAD/estimator.py')

n = 1024                 # ciphertext dimension (also, key entropy)
sd = 2**(-25)            # noise standard deviation
alpha = sqrt(2*pi)*sd    # estimator defines noise rate = sqrt(2pi).stdev
q = 2**32                # for compatibility only
m = oo                   # the attacker can use as many samples he wishes 
secret_distribution = (0,1)
success_probability = 0.99

print("CLASSICAL PRIMAL")
print(primal_usvp(n, alpha, q, secret_distribution=secret_distribution, m=m, success_probability=success_probability, reduction_cost_model=BKZ.sieve))
# BKZ cost models: CLASSICAL - 0.292*beta + 16.4 + log(8*d,2) - dual
# i.e. BKZ.sieve =  lambda beta, d, B: ZZ(2)**RR(0.292*beta + 16.4 + log(8*d,2))
print("CLASSICAL DUAL")
print(dual_scale(n, alpha, q, secret_distribution=secret_distribution, m=m, success_probability=success_probability, reduction_cost_model=BKZ.sieve))

# For more conservative parameters, both classical and quantum  
# BKZ cost models: CLASSICAL - 0.292 beta - primal
reduction_cost_model =  lambda beta, d, B: ZZ(2)**RR(0.292*beta)
print("CLASSICAL PRIMAL (conservative)")
print(primal_usvp(n, alpha, q, secret_distribution=secret_distribution, m=m, success_probability=success_probability, reduction_cost_model=reduction_cost_model))
# BKZ cost models: CLASSICAL - 0.292 beta - dual
print("CLASSICAL DUAL (conservative)")
print(dual_scale(n, alpha, q, secret_distribution=secret_distribution, m=m, success_probability=success_probability, reduction_cost_model=reduction_cost_model))
# BKZ cost models: QUANTUM - 0.265 beta - primal
reduction_cost_model =  lambda beta, d, B: ZZ(2)**RR(0.265*beta)
print("QUANTUM PRIMAL (conservative)")
print(primal_usvp(n, alpha, q, secret_distribution=secret_distribution, m=m, success_probability=success_probability, reduction_cost_model=reduction_cost_model))
# BKZ cost models: QUANTUM - 0.265 beta - dual
print("QUANTUM DUAL (conservative)")
print(dual_scale(n, alpha, q, secret_distribution=secret_distribution, m=m, success_probability=success_probability, reduction_cost_model=reduction_cost_model))

Use the TFHE library's API to encrypt your data inputs before they are processed. Use functions from the library to perform operations on the encrypted data.

After processing, decrypt the results to obtain the final output. Your pc may not be strong enough so it is also recommended you focus on parallel processing and potentially using hardware like GPUs or ASICs for an improved speed.

  1. zkSearch

zkSearch is a web3 search engine to anonymously surf the web. Searched data is never tracked with zkSearch neither is it marketed to third-parties. zkSearch makes use of zkShield to safely send call requests and receive information from the web. Integration with zkShield ensures that all user queries are encrypted, preserving user anonymity and preventing any potential tracking or data misuse. It combines the strengths of zero-knowledge proofs and fully homomorphic encryption to provide a secure and private web browsing experience.

  1. zkOS

zkOS is a native operating system of ZKML designed to leverage zero-knowledge proofs for enhanced security and privacy, focusing on secure computation and data handling within the operating system environment. The goal is to protect user privacy and data by ensuring operations on the OS are verified without exposing the actual data, user information or user actions.

  1. Mobile zkOS

Mobile zkOS is an extension of zkOS, tailored for smartphones and mobile devices just like with Kotlin and Swift but with privacy. It inherits zkOS's focus on security and privacy through zero-knowledge proofs, ensuring mobile operations and data are processed in a secure manner. Mobile zkOS offers a shielded environment where users can perform operations and handle data without compromising privacy.

  1. Cross-chain interoperability

Cross-chain transactions involve the burning or locking of currency on a source chain in order for an action to happen on another/destination chain. Currency can be burned or locked by sending the currency to either a burn address, this is typically the Genesis address or a trusted address that is inaccessible to anyone. Communication between the two chains is done by validating the state of the source chain while signing a message on the destination chain. This message can be looked into and verified by its designated nodes in order to perform the required action of the message.

Cross-Chain Interoperability Protocol (CCIP) CCIP a protocol for cross-chain applications to connect easily to foreign chains. Instead of these communications being public, ZKML adds zero-knowledge proofs to the exchanged messages to ensure encryption while maintaining the integrity of the action meant to be performed.

Traditional Cross-Chain Communication
Traditional Cross-Chain Communication
ZKML Cross-Chain Communication
ZKML Cross-Chain Communication

ZKML is the central point for privacy between communicating chains. With zero-knowledge being the central piece for cross-chain operations, action integrity and data privacy remains confidential.

Hardware configuration

Graphics Processing Units (GPUs) and Field-Programmable Gate Arrays (FGPAs) significantly improve computational speed when performing zero-knowledge proof generation and verification. GPUs accelerate the parallelized transaction and machine learning tasks. FPGAs are highly versatile and adaptable silicon chips used in a wide range of applications, from digital signal processing to complex computing tasks and everything in between. Unlike Application-Specific Integrated Circuits (ASICs) that are custom manufactured for a specific task, FPGAs can be reprogrammed to perform different functions or tasks after manufacturing.

FPGAs consist of an array of programmable logic blocks and a hierarchy of reconfigurable interconnects that allow the blocks to be wired together, somewhat like many logic gates that can be inter-wired in different configurations. These logic blocks can be configured to perform complex zero-knowledge tasks arguably more powerful than GPUs.

Parallel Processing for ZKP Computations GPUs, with their massively parallel architecture, excel in handling computations that can be broken down into smaller, concurrent tasks. This characteristic is particularly advantageous for ZKP computations, which often involve complex mathematical operations that can be parallelized to improve throughput and reduce processing time. For instance, the generation of zero-knowledge proofs involves multiple cryptographic computations that GPUs can perform simultaneously, significantly accelerating the overall process.

On the contrary, FPGAs offer a different set of advantages for ZKP computations. Unlike GPUs, which are designed with a fixed architecture, FPGAs can be configured to match the specific parallel processing needs of ZKP algorithms, potentially offering higher efficiency for particular tasks.

Recommended GPU specifications

  • NVIDIA RTX 3080: With 8704 CUDA cores and a memory bandwidth of 760 GB/s, this will offer excellent parallel processing.

  • AMD Radeon RX 6800 XT: This features 4608 cores and a 512 GB/s memory bandwidth, this GPU balances power cost and performance.

Recommended FPGA specifications

  • Xilinx Virtex UltraScale+ VCU1525: Specifically designed for high-performance acceleration applications, this FPGA is capable of handling complex algorithms and computational tasks, including those required for zero-knowledge proof computations. It features a high number of logic cells, high-bandwidth memory (HBM), and support for high-speed connectivity options, making it ideal for data center applications and cryptographic computations.

  • Intel Stratix 10: This offers a range of devices that deliver high levels of performance and capabilities, the Stratix 10 is suitable for demanding computational tasks. It combines the flexibility of programmable logic with the power of integrated system-on-chip (SoC) functionalities, including a quad-core ARM Cortex-A53 processor. Its advanced DSP blocks and high-speed transceivers make it an excellent choice for ZKP computations and other data-intensive applications.

Subscribe to ZKML
Receive the latest updates directly to your inbox.
Mint this entry as an NFT to add it to your collection.
Verification
This entry has been permanently stored onchain and signed by its creator.
More from ZKML

Skeleton

Skeleton

Skeleton