Account based zk-Rollup with unlinkable transactions

Tsvetan Dimitrov

Agenda

  • Requirements

  • Protocol Overview

  • Data Structures

  • Protocol Operations

  • On-Chain Flow

  • Off-Chain Components

  • Performance Optimizations

Requirements / 1

  • Perform anonymous transactions on Ethereum.

  • Payments based around accounts and money orders.

  • Three types of actors:

    • Users

    • Operators

    • Observers

Requirements / 2

  • Users keep their account data private.

  • Operators are only aware of account hashes.

  • Observers collect information about rollup state and transactions (users, operators or outsiders).

  • Senders create a money order, and register to an Operator.

  • Receivers redeem a money order and send an update to an Operator.

  • Sender and Receiver are hidden from any Observer.

Protocol Overview

Data Structures

State Transition Function (STF)

Transaction: tx

Old State Root: R

New State Root: R'

STF (R, tx, accounts, merkle_proofs) -> R'

Zero Knowledge Proof of STF

STF (R, tx, accounts, merkle_proofs) -> R'

witness

Arithmetization

Proving

SNARK Proof

Arithmetic Circuit

  • DAG where the inputs are your initial nodes.

  • Nodes go through a network of gates (add, mul).

  • Eventually an output gets accumulated.

Arithmetization and Proving

  1. R1CS Conversion: A * B = C  (dot product).
  2. QAP Conversion (set of quadratic equations that should yield a target polynomial).
  3. The result is a problem that involves checking polynomials at a particular point.
  4. The prover convinces the verifier that they know an assignment of variables that makes all the polynomial equations hold.

Recursive Aggregation / 1

Recursive Aggregation / 2

  1. Create a ZKP for each transaction, resulting in N separate proofs.

  2. Then create another ZKP that attests to the validity of N previous proofs. This is an aggregate proof.

  3. Continue this process, creating a new ZKP each time that attests to the validity of the previous aggregate proof and the next transaction proof.

  4. In the end, you are left with a single proof that can be verified to confirm the validity of all the original transactions.

Protocol Operations

Money Transfer (Sender-> Receiver)

Receiver Money Order Redemption

On-Chain Flow

Operations

  • Rollup State Management

  • Depositing Funds

  • Withdrawing Funds

  • Proof Verification

  • State Root Update

Rollup State Management

pragma solidity ^0.8.0;

contract ZkRollup {
    bytes32 public stateRoot;

    constructor(bytes32 _initialStateRoot) {
        stateRoot = _initialStateRoot;
    }
}

Depositing Funds

event Deposit(address indexed depositor, uint256 amount, uint256 index);

function deposit(uint256 amount) external {
    require(msg.sender.transfer(amount), "Transfer failed");

    uint256 depositIndex = ...; // Calculate deposit index
    emit Deposit(msg.sender, amount, depositIndex);
}

Withdrawing Funds

event Withdrawal(address indexed recipient, uint256 amount);

function withdraw(
	address recipient, 
	uint256 amount, 
	bytes calldata proof) external {
    require(
    	verifyWithdrawalProof(recipient, amount, proof), "Invalid proof");

    (bool success, ) = recipient.call{value: amount}("");
    require(success, "Transfer failed");

    emit Withdrawal(recipient, amount);
}

function verifyWithdrawalProof(
	address recipient, 
	uint256 amount, 
	bytes calldata proof) internal view returns (bool) {
    // Implement the actual proof verification 
    // logic based on the chosen zk-proof system
}

Proof Verification and State Root Update

event StateRootUpdated(bytes32 newStateRoot);

function updateStateRoot(
	bytes32 newStateRoot, 
	bytes calldata proof) external {
    require(verifyProof(newStateRoot, proof), "Invalid proof");

    stateRoot = newStateRoot;
    emit StateRootUpdated(newStateRoot);
}

function verifyProof(
	bytes32 newStateRoot, 
	bytes calldata proof) internal view returns (bool) {
    // Implement the actual proof verification 
    // logic based on the chosen zk-proof system
}

Off-Chain Components

Transaction Aggregator

  • A server or a set of servers responsible for collecting individual transactions from users.

  • Queues transactions for inclusion in the next proof.

zk-SNARK Circuit Compiler

  • Translates your protocol rules into a zk-SNARK circuit.

  • One-time process, but very critical for the operation of the rollup.

zk-SNARK Prover

  • Takes a batch of transactions and the current state as input.

  • Generates a zk-SNARK Proof attesting to the validity of these transactions.

  • A computationally intensive process.

Data Availability Layer

  • The transaction data (sender, receiver, amounts, etc.) can be stored off-chain in a separate layer.

  • This can be a distributed file system, a peer-to-peer network or any other reliable system.

Client Software

  • Users interact with the zk-Rollup through web/mobile apps or command line tools.

  • This software creates transactions, sends them to the transaction aggregator, verify proofs and checks the state of the system.

Monitoring and Alerting Systems

  • Ensure smooth operation of off-chain components.

  • Alert developers or operators to any issues or anomalies in real-time.

Load Balancers and Networking Infrastructure

  • Handle the communication between clients, the transaction aggregator, the prover and the blockchain.

  • Ensure network traffic is efficiently routed and no single point of failure exists.

Notes on Decentralization

  • Components can be run by different entities to enhance security and trustlessness.

  • They could run their own transaction aggregators or provers.

  • Users can opt to verify proofs themselves if they don't trust the operators.

Performance Optimizations

  • Tune transaction batch size.

  • Parallel Proof Generation.

  • Optimize Circuit Design.

  • Fast Data Availability.

  • Efficient Signature Verification inside a zk-SNARK.

  • Choose Efficient zk-SNARK Constructions.

  • Caching and DB Optimization for Account Data.

Summary

 

  • Defined an Account based anonymous zk-Rollup protocol.

  • Defined Account and Rollup State data structures.

  • Defined protocol operations, on-chain and off-chain flow and components.

  • Suggested some performance optimizations.

Questions?

Account based zk-Rollup with unlinkable transactions

By Tsvetan Dimitrov

Account based zk-Rollup with unlinkable transactions

Introduction to software versioning and release management best practices

  • 58

More from Tsvetan Dimitrov