EZKL model integration with on-chain ZK verfication

1. Overview

This specification details implementing a credit scoring system using zero-knowledge machine learning (ZKML) with EZKL. The ML generation happens at Loan-ZKML/demo EZKL prooving facilitiation allows borrowers to prove their creditworthiness without revealing sensitive financial data, enabling privacy-preserving lending decisions.

2. ZKML Components

The system consists of the following components:

1. ML Model Service: Trains and exports credit scoring models
2. EZKL Proof Generator: Generates Halo2 zero-knowledge proofs of model execution
3. Smart Contract Verifier: Verifies proofs and manages lending terms
4. Client Interface: Enables users to generate and submit proofs

3. Proof design and challenges

4 bytes                       32 bytes                        32 bytes
┌───────────────────────────────┬───────────────────────────────┬───────────────────────────────┐
│      Function Selector        │      Offset to Proof Data     │   Offset to Public Inputs     │
│       (0x1e8e1e13)            │         (usually 64)          │      (64 + proof length)      │
└───────────────────────────────┴───────────────────────────────┴───────────────────────────────┘
                    32 bytes                   variable length (e.g., 3648 bytes)
┌───────────────────────────────┬───────────────────────────────────────────────────────────────┐
│       Proof Data Length       │                         Proof Data Bytes                      │
│       (e.g., 3648)            │    (The actual ZKML proof generated by EZKL)                  │
└───────────────────────────────┴───────────────────────────────────────────────────────────────┘
                    32 bytes                       variable length (e.g., 32 bytes per input)
┌───────────────────────────────┬───────────────────────────────────────────────────────────────┐
│   Public Inputs Array Length  │                     Public Input Values                       │
│         (e.g., 1)             │  (e.g., Credit Score Value: 5652)                             │
└───────────────────────────────┴───────────────────────────────────────────────────────────────┘

3.1. Proof Verification

• Proof uniqueness
  • Each proof can only be used once
• Submitter tracking
  • The contract remembers which address first submitted a particular proof
• Sender authorization
  • The contract uses msg.sender to authenticate the submitter
• Proof verification
  • The proof must be cryptographically valid

3.1. Common Pitfalls

1. Improper Calldata Parsing Failing to extract proof data and public inputs from binary formats correctly
2. Mismatched Public Inputs: Using wrong public input formats that don't match proof expectations

3.2. Solutions

These challenges can be addressed through proper implementation:

1. ABI-Aware Parsing: Properly parsing ABI-encoded data with careful offset calculation
2. Synchronized Input Handling: Ensuring public inputs match what was used in proof generation

Smart Contract Layer (Solidity)

• Base loan management contract
• Collateral tiers
• Integration with ZK verifier

Development Environment

asdf - 3rd Party Tools Version Manager

We are suggesting asdf as the version manager for 3rd party tools. This is an awesome tool that runs on many different platforms and uses one single file to manage all tools versions. The file is .tool-versions.

Linux

For Linux, I have made sure that I have go installed and used the go installation instructions of asdf which are given here.

Bash Shell

Then on my .bashrc I also added the following:

export PATH=$HOME/.asdf/shims:$PATH
. <(asdf completion bash)

Foundry (not Hardhat)

Important: This is not installed using asdf.

We work with Foundry. Please, follow the installation instructions here.

We recommend that you install and use the stable release of the tools:

I used the following command to install foundryup:

curl -L https://foundry.paradigm.xyz | bash

Then I restarted my shell and used the command:

foundryup --install stable