Coder Legion - Recent posts tagged zk

Beyond Identity: Rethinking Trust Infrastructure Through Zero-Knowledge Verification

Thu, 11 Jun 2026 10:15:45 +0000

Abstract:

Trust on the internet has traditionally relied on centralized authorities, public credentials, and extensive disclosure of personal information. Whether applying for a job, verifying an academic qualification, or proving professional experience, users are often required to reveal significantly more information than necessary.

While exploring emerging solutions in this space, I came across two interesting approaches. GitHired focuses on proving technical credibility through actual work rather than resume claims, while Fhenix explores privacy-preserving computation through Fully Homomorphic Encryption (FHE). Both projects address different dimensions of trust, yet neither fully solves the challenge of verifiable identity and credential ownership.

This observation led to the conceptualization of ZenProof, a privacy-preserving trust infrastructure that combines decentralized identity standards, verifiable credentials, distributed storage, and Zero-Knowledge Proofs to enable trust verification without exposing sensitive information.

1. Introduction

One question kept bothering me throughout my exploration of Web3 identity systems:

Why do we reveal everything just to prove one thing?

A university graduate only wants to prove they possess a degree.

A developer only wants to prove they possess a skill.

A professional only wants to prove they hold a certification.

Yet modern systems require complete disclosure of personal information, documents, and credentials to establish trust.

As digital ecosystems continue to evolve, trust itself has become one of the internet's most valuable resources. However, existing verification systems remain heavily dependent on centralized databases and excessive information sharing.

This led me to investigate whether trust could be verified differently.

Not through disclosure.

But through cryptographic proof.

2. Existing Approaches

GitHired: Trust Through Proof of Work

One of the most interesting platforms I encountered was GitHired.

Instead of evaluating candidates through traditional resumes, GitHired analyzes actual GitHub contributions, project complexity, and development activity. The platform operates on a simple but powerful philosophy:

Trust what developers build, not what they claim.

This approach significantly improves hiring accuracy by emphasizing demonstrable work over self-reported qualifications. GitHired's model focuses on proof-of-work rather than keyword matching or resume-based filtering.

However, while GitHired addresses credibility, it does not directly solve privacy or identity ownership challenges.

Fhenix: Trust Through Privacy

Fhenix approaches the problem from a completely different direction.

Using Fully Homomorphic Encryption (FHE), Fhenix enables computation on encrypted data without revealing the underlying information. This allows developers to build confidential smart contracts while preserving privacy throughout execution.

The technology represents a major advancement in privacy-preserving blockchain infrastructure.

However, its primary focus is confidential computation rather than decentralized credential verification.

3. Identifying the Research Gap

While studying both systems, I noticed something interesting.

GitHired solves credibility.

Fhenix solves privacy.

But neither directly addresses a broader challenge:

How can individuals prove qualifications, skills, certifications, or achievements without exposing the underlying data itself?

This gap became the foundation of ZenProof.

4. Introducing ZenProof

ZenProof is envisioned as a privacy-preserving trust infrastructure designed around a simple principle:

Prove the claim, not the data.

Instead of sharing certificates, users share cryptographic proofs.

Instead of exposing identities, users verify legitimacy.

Instead of relying on centralized verification systems, trust becomes mathematically verifiable.

To achieve this, ZenProof combines:

W3C Decentralized Identifiers (DIDs)
Verifiable Credentials
IPFS-based decentralized storage
zk-SNARK proof generation
Selective disclosure mechanisms

Together, these technologies create an environment where verification becomes possible without sacrificing privacy.

5. Why This Matters

As AI-generated content, deepfakes, forged certificates, and fake resumes become increasingly common, proving authenticity will become one of the internet's most important challenges.

The future will not belong to systems that collect the most data.

It will belong to systems that require the least data while providing the strongest guarantees of trust.

That is the vision behind ZenProof.

A Clear and Working Example of Zero-Knowledge Proofs in a Real Web3 Application

Wed, 30 Jul 2025 11:25:49 +0000

Zero-knowledge proofs (ZKPs) allow someone to prove they know or did something — without revealing what it was. A specific type of ZKP called a zk-SNARK (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) enables compact and fast proofs that can be verified on-chain.

Writing ZK circuits manually can be complex, but ZoKrates makes it much easier. It provides a high-level language and tooling to compile circuits, generate proofs, and export Solidity verifiers.

In this tutorial, we’ll use ZoKrates to build a simple private voting example:

️ A user will commit to their vote (1 or 2) using a secret nonce and the Poseidon hash function.
Later, they’ll prove (without revealing their vote or nonce) that:

The vote was valid (1 or 2), and
It matches a previously published commitment.

We’ll generate the proof entirely in JavaScript and verify it on-chain — all using a local setup with scaffold-eth-2, a powerful framework for building Ethereum dApps.

⚠️ This is a minimal example to help you understand the flow. It’s not a full voting system — just a small step into the zk world.

️ Step 0: Install ZoKrates

On Linux/macOS, install with:

curl -LSfs get.zokrat.es | sh

⚠️ On Windows, make sure to install and run inside WSL (Windows Subsystem for Linux), or you’ll face compatibility issues.

Check it's working:

zokrates --help

⚙️ Step 1: Bootstrap Your dApp

Use scaffold-eth-2 — the fastest way to start building full-stack dApps.

Initialize the project:

npx create-eth@latest # we are using foundry, but hardhat works too
cd my-zk-vote  # open the project's directory
yarn           # install all dependencies

Add ZK dependencies on NextJS package:

cd packages\nextjs # go to nextjs directory
yarn add circomlibjs zokrates-js # add zk frontend dependencies

Start development servers:

cd ..\..       # go back to the root directory
yarn chain     # start local blockchain
yarn deploy    # deploy contracts
yarn start     # launch frontend

Step 2: Write the Circuit

You can see the circuit as a way to validate secret information. Each information marked as private will remain secret and can be validated against other public arguments.

Create a file at packages/foundry/contracts/vote.zok:

import "hashes/poseidon/poseidon.zok";

def main(private field vote, private field nonce, field commitment) -> bool {
    assert(vote == 1 || vote == 2);
    field hash = poseidon([vote, nonce]);
    assert(hash == commitment);
    return true;
}

What this does:

Enforces that the vote must be 1 or 2 — a simple rule for this example.
Hashes the vote and a secret nonce using Poseidon, then checks that it matches the provided commitment — proving the commitment corresponds to a valid vote.

Why Poseidon? It’s a hash function designed for zero-knowledge circuits — much faster and cheaper to verify in zk-SNARKs than SHA256 or Keccak.

Step 3: Generate the Commitment in JavaScript

Create a helper file at packages/nextjs/utils/zkVote.ts:

import { buildPoseidon } from "circomlibjs";

export async function generateCommitment(vote: number, nonce: bigint): Promise<string> {
  const poseidon = await buildPoseidon();
  const commitment = poseidon([BigInt(vote), nonce]);
  return poseidon.F.toString(commitment);
}

You can now copy vote, nonce, and commitment into the ZoKrates Playground to test your circuit manually.

Tip: You can use the commands below to quickly generate a commitment to test on the playground:

cd packages/nextjs
npx --package typescript tsc utils/zkVote.ts --target es2020 --module commonjs --outDir dist --esModuleInterop
node -e "require('./dist/zkVote.js').generateCommitment(2, 123456789n).then(console.log);"

Step 4: Compile the Circuit

Run this from your project root:

cd packages/foundry/contracts
zokrates compile -i vote.zok
zokrates setup
zokrates export-verifier

This will produce a verifier.sol file you can use on-chain.
Move proving.key and verification.key to packages/nextjs/public so it's available in the frontend, don't worry, these keys are not private.
You can delete abi.json, out and out.r1cs files, if you want.

Step 5: Add the Verifier to Your App

Create `packages/foundry/script/DeployVerifier.s.sol:

pragma solidity ^0.8.19;

import "./DeployHelpers.s.sol";
import "../contracts/verifier.sol";

contract DeployVerifier is ScaffoldETHDeploy {
    function run() external ScaffoldEthDeployerRunner {
        new Verifier();
    }
}

Edit `packages/foundry/script/Deploy.s.sol:

pragma solidity ^0.8.19;

import "./DeployHelpers.s.sol";
import { DeployYourContract } from "./DeployYourContract.s.sol";
import { DeployVerifier } from "./DeployVerifier.s.sol";

contract DeployScript is ScaffoldETHDeploy {
    function run() external {
        DeployYourContract deployYourContract = new DeployYourContract();
        deployYourContract.run();

        DeployVerifier deployVerifier = new DeployVerifier();
        deployVerifier.run();
    }
}

Then redeploy everything:

yarn deploy

Step 6: Generate the Proof in the Frontend

Continue in packages/nextjs/utils/zkVote.ts and add the following:

import { initialize } from "zokrates-js";

let cachedKeypair: any = null;

async function loadKeypair() {
  if (!cachedKeypair) {
    const provingKeyResponse = await fetch("/proving.key");
    const provingKeyBuffer = await provingKeyResponse.arrayBuffer();

    const verificationKeyResponse = await fetch("/verification.key");
    const verificationKeyBuffer = await verificationKeyResponse.arrayBuffer();

    const provingKeyUint8 = new Uint8Array(provingKeyBuffer);
    const verificationKeyUint8 = new Uint8Array(verificationKeyBuffer);

    cachedKeypair = {
      pk: provingKeyUint8,
      vk: verificationKeyUint8,
    };
  }
  return cachedKeypair;
}

export type Proof = {
  proof: {
    a: { X: bigint; Y: bigint };
    b: { X: readonly [bigint, bigint]; Y: readonly [bigint, bigint] };
    c: { X: bigint; Y: bigint };
  };
  inputs: readonly [bigint, bigint];
};

function formatProof(rawProof: any): Proof {
  const { a, b, c } = rawProof.proof;

  const toBigTuple = (arr: string[]) => [BigInt(arr[0]), BigInt(arr[1])] as const;

  return {
    proof: {
      a: { X: BigInt(a[0]), Y: BigInt(a[1]) },
      b: { X: toBigTuple(b[0]), Y: toBigTuple(b[1]) },
      c: { X: BigInt(c[0]), Y: BigInt(c[1]) },
    },
    inputs: toBigTuple(rawProof.inputs),
  };
}

export async function proveVote(vote: number, nonce: bigint, commitment: string): Promise<Proof> {
  const zokrates = await initialize();
  const artifacts = zokrates.compile(`
  import "hashes/poseidon/poseidon.zok";

  def main(private field vote, private field nonce, field commitment) -> bool {
      assert(vote == 1 || vote == 2);
      field hash = poseidon([vote, nonce]);
      assert(hash == commitment);
      return true;
  }
      `);
  const keypair = await loadKeypair();

  const { witness } = zokrates.computeWitness(artifacts, [vote.toString(), nonce.toString(), commitment]);
  const rawProof = zokrates.generateProof(artifacts.program, witness, keypair.pk);
  return formatProof(rawProof);
}

The important method here is proveVote, it will:

initialize zokrates
compile the circuit
load the keypairs
compute witness using the arguments of the method
generate the proof with the compiled circuit, the witness and the proving key.

Step 7: Verify the Proof On-Chain

Call your Verifier contract from the frontend on a Nextjs page:

"use client";

import { useRef, useState } from "react";
import type { NextPage } from "next";
import { toast } from "react-hot-toast";
import { useScaffoldReadContract } from "~~/hooks/scaffold-eth";
import { Proof, generateCommitment, proveVote } from "~~/utils/zkVote";

const Home: NextPage = () => {
  // generate a random nonce
  const nonceRef = useRef<bigint>(BigInt(Date.now() + Math.floor(Math.random() * 1000)));

  // state for the vote, the commitment, the proof, and the loading state
  const [vote, setVote] = useState<string>("");
  const [commitment, setCommitment] = useState<string>();
  const [proof, setProof] = useState<Proof | null>(null);
  const [isLoading, setIsLoading] = useState(false);

  // verify the proof onchain once you have the proof
  const { data: isVerified } = useScaffoldReadContract({
    contractName: "Verifier",
    functionName: "verifyTx",
    args: [proof?.proof, proof?.inputs],
    query: {
      enabled: !!proof,
    },
  });

  // generate the commitment when the user clicks the button
  const handleVote = async () => {
    if (!vote) return;

    setIsLoading(true);
    try {
      const voteNumber = Number(vote);
      const newCommitment = await generateCommitment(voteNumber, nonceRef.current);
      setCommitment(newCommitment);
    } catch (error) {
      toast.error("Error generating commitment: " + (error as Error).message);
    } finally {
      setIsLoading(false);
    }
  };

  // prove the vote when the user clicks the button
  const handleProve = async () => {
    if (!vote || !commitment) return;

    setIsLoading(true);

    try {
      const voteNumber = Number(vote);
      const newProof = await proveVote(voteNumber, nonceRef.current, commitment);
      setProof(newProof);
    } catch {
      toast.error("Impossible to prove");
      setProof(null);
    } finally {
      setIsLoading(false);
    }
  };
  
  // render your page...
}

You can check the whole code of the page component in the repository Github.

To test your ZK dApp locally, just open http://localhost:3000 in your browser.

Final Thoughts

In this example, we called the Verifier contract directly from the frontend. That’s useful for learning — but in a real-world application, it’s not the pattern you’d use.

Instead, your main contract (e.g. a voting contract, identity manager, or game logic) would receive the proof and internally call the Verifier contract to validate it before proceeding with any logic.

This architecture gives you control and flexibility:

function submitVote(
  uint[2] calldata a,
  uint[2][2] calldata b,
  uint[2] calldata c,
  uint[] calldata input
) external {
  require(verifier.verifyTx(a, b, c, input), "Invalid proof");
  // continue with vote counting, recording, etc
}

What You Could Build with This

This approach opens doors to powerful applications:

Anonymous voting: prove your vote was valid without revealing it
Private whitelists: prove membership in a group (via Merkle root) without showing which one
Private randomness: commit to a number, later prove its properties (e.g., in a fair lottery)
Game actions: prove you played by the rules without revealing your strategy
Credential systems: prove you hold a credential without disclosing your identity

Zero-knowledge isn’t just privacy — it’s about integrity without exposure.

If you're exploring zero-knowledge or building real-world dApps, feel free to connect — I'd love to exchange ideas.

Written by Gil, a fullstack developer with 15+ years of experience, passionate about practical architecture, clean UX, and blockchain-powered applications.