RISC Zero zkVM guest程序优化技巧 及其 与物理CPU的关键差异

1. 引言

RISC Zero zkVM 设计并实现为 与物理CPU功能类似。从而对于RISC Zero zkVM guest程序:

  • 可使用通用编程语言(如Rust)和通用工具(如Cargo,LLVM)。
  • 通常,也可使用通用优化技术来优化。

在RISC Zero zkVM的某应用中,guest程序 为zkVM待执行和证明的代码。
RISC Zero zkVM guest程序优化技巧 及其 与物理CPU的关键差异_第1张图片
guest应具有reading、writting 和 committing的基本功能,具体为:

  • 1)读取输入。相关方法有:env::readenv::read_sliceenv::stdin
  • 2)将private outputs 写入到host。所谓host,是指运行zkVM的系统。相关方法有:env::writeenv::write_sliceenv::stdoutenv::stderr
  • 3)将public outputs commit到journal。相关方法有:env::commitenv::commit_slice
    所谓journal,为receipt的一部分,包含了某zkVM应用的public outputs。而receipt用于证明某guest程序的有效执行。验证receipt可提供密码学的保证——该journal确实构建自expected circuit和expected imageID。
    • receipt中包含:
      • journal:用于证实该guest程序的public outputs。
      • seal:为难懂的blob,来密码学证实该receipt的有效性。

为证明guest程序的正确执行,其遵循如下流程:

  • 1)将guest程序编译为ELF二进制。
  • 2)Executor运行该ELF二进制,并记录其session。
  • 3)Prover检查并证明该session的有效性,输出receipt。
  • 4)任何具有receipt的人都可验证该guest程序的执行,并读取其public outputs。该验证算法会以ImageID为参数,其中ImageID用作特定ELF二进制的密码学标识。

为让zkVM应用性能尽可能好,需:

  • 让guest程序尽可能轻量级,为此#![no_std],guest程序不能使用std
  • guest程序永远无法以单独Rust可执行程序启动,因此设置#![no_main]
  • 为让guest程序可供host启动,需指定host启动guest程序该调用哪个函数,因此使用risc0_zkvm_guest::entry!宏来指定所调用的guest初始函数。

为优化zkVM程序,当前提供了如下debug和性能分析工具:

  • Count cycles:env::get_cycle_count
  • 打印debug消息:env::log

本文将重点关注:

  • guest程序优化技巧:有更快的证明,或(和),降低计算开销。
  • RISC Zero zkVM与物理CPU的关键差异

为实现更快的证明,或(和),降低计算开销,除对guest程序优化之外,还可利用硬件加速。借助NVIDIA图形卡,可通过CUDA来实现证明加速。当运行某zkVM程序时,需安装兼容版本的CUDA runtime。当从源码构建zkVM时,需在build机器上安装兼容版本的CUDA tookit,并启用cuda feature。

1.1 何为zkVM?

zkVM,本质为CPU。

RISC Zero zkVM为RISC-V架构的实现,更确切来说,是实现了riscv32im。其与笔记本上基于X86架构或ARM架构所实现的CPU类似。

zkVM与物理CPU之间的最大不同之处在于:

  • zkVM中,以软件,实现了算术电路,而不是硅铜形式构建的电路。

1.2 何为“cycle”?

zkVM和物理CPU中,运算的开销都是以“clock cycles”来衡量。

直观来说,一个“clock cycle”为CPU运算中的最小时间衡量单位,表示CPU内部时钟的一个tick,且为执行某基础CPU运算(如2个整数求和)所需时间。后续将其简称为“cycle”。

zkVM的证明时长与execution中的cycle数,直接相关。

2. guest程序优化技巧及建议

可使用通用技术和最佳实践来优化guest程序。
通用优化技术:

  • The Rust Performance Book 为非常赞的资源。其篇幅不长,覆盖了性能的各个重要议题,并提出了优化实用建议。若是优化新手,或Rust新手,推荐阅读该资源。

最佳实践优化技巧:

  • 1)Don’t assume, measure:性能是复杂的,无论是zkVM中的性能,还是物理CPU中的性能。不要假设你知道瓶颈在哪,而是要测量并试验。

    • 若对执行用时的1%优化,哪怕将其提升100倍,该改进对总体性能的影响仍少于1%。这通常称为Amdahl定律,实际这意味着不应浪费时间来优化一些不花费大量执行时间的东西。
    • 通过控制台打印来测量:
      • 在guest程序中添加eprintln!来打印衡量某运算用时,以及调用次数等。
      • 使用env::get_cycle_count()来获取程序当前位置的执行cycle数。【也可使用counts工具。】
      fn my_operation_to_measure() {
        let start = env::get_cycle_count();
      
        // potentially expensive or frequently called code
        // ...
      
        let end = env::get_cycle_count();
        eprintln!("my_operation_to_measure: {}", end - start); //这样每次被调用时,会打印出相应的cycle数。
      }
      
  • 2)Profiling:为理解和优化代码的最重要的工具之一。Profiling工具有:【以找到cycles多的地方,作为优化点。】

    • pprof
    • perf

    来收集程序整个执行期间的性能信息,并创建可视化的性能图。RISC Zero已尝试支持为cycle counts生成pprof文件。pprof和perf所实现的 Sampling CPU profiles,提供了程序各处时间花费视图——通过记录sampling interval时的当前call stack。RISC Zero为guest执行提供了“sampling” CPU profiler。

    一个很有用的数据化可视化为flamegraph火焰图。下图为ECDSA验证例子的火焰图:
    RISC Zero zkVM guest程序优化技巧 及其 与物理CPU的关键差异_第2张图片
    需安装Go,并允许如下命令:

    # In your clone of github.com/risc0/risc0
    cd examples/ecdsa
    RISC0_PPROF_OUT=ecdsa_verify.pb RISC0_DEV_MODE=true cargo run -F profiler
    go tool pprof -http 127.0.0.1:8000 ecdsa_verify.pb
    

    然后在浏览器中打开http://127.0.0.1:8000/ui/flamegraph,即可查看相应火焰图。尽管pprof工具与Go关联,但其可用于profile非Go编写的程序。pprof具有丰富的功能,详情可参看文档https://github.com/google/pprof/blob/main/doc/README.md。

    更多zkVM guest程序profiling技巧,可参看Guest Profiling Guide。

2.1 当读取数据作为raw bytes时,使用env::read_slice

当向guest读取输入时,env::read为主要api。其自动将输入bytes反序列化为structs,类似于password checker例子中的代码片段:

let request: PasswordRequest = env::read();

在host代码中,ExecutorEnvBuilder::write用于序列化并写入到input struct,使得guest可读取:

let request = PasswordRequest { /* .. */ };
let env = ExecutorEnv::builder()
        .write(&request).unwrap()
        .build()
        .unwrap();

大多数情况下,使用这些API来给guest发送数据。

但是,但需要读取并使用的数据为raw bytes(或words)时,使用env::read_sliceenv::stdin().read_to_end会更高效。这2种方法都没有序列化和反序列化,因此无需复制或重解析输入数据。当按字节读取image数据,或按二进制编码读取数据时,这很有用。具体见CBOR。

Bonsai Governance例子代码片段中展示了如何读取字节:

let mut input_bytes = Vec::<u8>::new();
env::stdin().read_to_end(&mut input_bytes).unwrap();

对应host端,使用ExecutorEnvBuilder::write_slice来按字节传输:

let input_bytes: Vec<u8> = b"INPUT DATA".to_vec();
let env = ExecutorEnv::builder()
        .write_slice(&input_bytes)
        .build()
        .unwrap();

2.2 当仅需部分输入数据时,尝试对其Merkle化

某些程序仅需可用的整个数据的一部分。如Where’s Waldo例子:

  • 其输入为一整张图,但仅需要有Walo的部分。
  • 加载和对整张图进行哈希将非常昂贵,因此,对guest的初始输入仅为Merkle root,每个chunk动态加载。
  • guest会通过Merkle inclusion proof来验证该chunk确实是该image的一部分。

当所写guest具有large input,且需要一部分输入来计算时,可考虑将large input切分为chunks,然后构建一棵Merkle tree。具体可查看Where’s Waldo代码。

2.3 guest中的密码学操作可利用accelerator circuits

RISC Zero的riscv32im实现中包含了一些特殊用途的运算,包含2个对密码学函数的“accelerator”:

  • SHA-256:一次SHA-256压缩运算,通常对每个64-byte block需要68个cycle且初始化需要6个cycle。【这包含了基础的内存操作cycle,而不包含所触发的page-in或page-out操作。】
  • 256-bit modular multiplication:一次256-bit modular multiplication需要10个cycle。【这包含了基础的内存操作cycle,而不包含所触发的page-in或page-out操作。】

通过在zkVM中“hardware”实现这些运算,使用这些accelerator的程序可执行得更快,并以少得多的资源完成证明。

详情见:

  • Cryptography Acceleration

使用accelerator,一次SHA-256压缩运算,通常对每个64-byte block需要68个cycle且初始化需要6个cycle。

2.4 其它优化尝试

  • 尝试不同的编译配置:

    • 设置lto="thin",有时比设置lto="fat"lto=true要更快。
    • 有时opt-level=2要比3更快。也可以试试sz
    • 尝试设置codegen-units=1
  • 当需要使用map时,用BTreeMap而不是HashMap

  • 当需要对数据哈希时,使用SHA-256 accelerator。

  • 查找没必要复制 或 (反)序列化 的地方,改为使用使用env::read_sliceenv::stdin().read_to_end

3. RISC Zero zkVM与物理CPU的关键差异

使用通用建议和工具来优化guest程序,80%能凑效。但,物理CPU与zkVM之间存在关键差异,理解这些差异,有助于获取尽可能最好的guest行囊够。

本节重点关注RISC Zero zkVM与物理CPU的关键差异,因其与guest性能相关:

  • 1)大多数RISC-V运算仅需要1个cycle。zkVM中指令间的相对差异要小得多。
  • 2)内存访问需要1个cycle,page-in和page-out情况除外。
  • 3)zkVM没有原生浮点运算
  • 4)zkVM未对齐数据访问要贵得多
  • 5)zkVM内存访问是同步的
  • 6)zkVM所有执行都是单线程的
  • 7)zkVM无pipelining或其它指令级的并行化

3.1 大多数RISC-V运算仅需要1个cycle

大多数RISC-V运算仅需要1个cycle。并不是所有运算需要的cycle数都一样。对于物理CPU和zkVM来说,都有:add指令需要的cycle数少于div指令。

但是,zkVM中指令间的相对差异要小得多:

  • zkVM中,div指令,所需cycle数为add指令的2倍。而物理CPU中,div指令所需cycle数为add指令的15到40倍。实际上,当实现某算法(The Most Efficient Known Addition Chains for Field Element & Scalar Inversion for the Most Popular & Most Unpopular Elliptic Curves),有10个add运算,或,1个div运算,这2个选项时。对于物理CPU,选择10个add运算选项;而对于zkVM,则选择1个div运算。

zkVM中:

  • Addition, comparison, jump, shift left, load 和 store 均需要1个cycle。
  • Bitwise operations (AND, OR, XOR), division, remainder, 和 shift right 均需要2个cycle。

这即意味着,shift left 并不比 “乘以a power of two” 快,shift right 不比 division 快。开发者和编译器所做的类似这样的小优化,对zkVM来说并无效果。
物理CPU和RISC Zero zkVM中每种RV32IM运算所需的cycle数见下表:【见RISC-V Instruction Set Reference】

Assembly Name Pseudocode RISC Zero Cycles
LUI rd,imm Load Upper Immediate rd ← imm 1
AUIPC rd,offset Add Upper Immediate to PC rd ← pc + offset 1
JAL rd,offset Jump and Link rd ← pc + length(inst)pc ← pc + offset 1
JALR rd,rs1,offset Jump and Link Register rd ← pc + length(inst)pc ← (rs1 + offset) ∧ -2 1
BEQ rs1,rs2,offset Branch Equal if rs1 = rs2 then pc ← pc + offset 1
BNE rs1,rs2,offset Branch Not Equal if rs1 ≠ rs2 then pc ← pc + offset 1
BLT rs1,rs2,offset Branch Less Than if rs1 < rs2 then pc ← pc + offset 1
BGE rs1,rs2,offset Branch Greater than Equal if rs1 ≥ rs2 then pc ← pc + offset 1
BLTU rs1,rs2,offset Branch Less Than Unsigned if rs1 < rs2 then pc ← pc + offset 1
BGEU rs1,rs2,offset Branch Greater than Equal Unsigned if rs1 ≥ rs2 then pc ← pc + offset 1
LB rd,offset(rs1) Load Byte rd ← s8[rs1 + offset] 1 if paged-in 1094 to 5130 otherwise
LH rd,offset(rs1) Load Half rd ← s16[rs1 + offset] 1 if paged-in 1094 to 5130 otherwise
LW rd,offset(rs1) Load Word rd ← s32[rs1 + offset] 1 if paged-in 1094 to 5130 otherwise
LBU rd,offset(rs1) Load Byte Unsigned rd ← u8[rs1 + offset] 1 if paged-in 1094 to 5130 otherwise
LHU rd,offset(rs1) Load Half Unsigned rd ← u16[rs1 + offset] 1 if paged-in 1094 to 5130 otherwise
SB rs2,offset(rs1) Store Byte u8[rs1 + offset] ← rs2 1 if paged-in 1094 to 5130 otherwise
SH rs2,offset(rs1) Store Half u16[rs1 + offset] ← rs2 1 if paged-in 1094 to 5130 otherwise
SW rs2,offset(rs1) Store Word u32[rs1 + offset] ← rs2 1 if paged-in 1094 to 5130 otherwise
ADDI rd,rs1,imm Add Immediate rd ← rs1 + sx(imm) 1
SLTI rd,rs1,imm Set Less Than Immediate rd ← sx(rs1) < sx(imm) 1
SLTIU rd,rs1,imm Set Less Than Immediate Unsigned rd ← ux(rs1) < ux(imm) 1
XORI rd,rs1,imm Xor Immediate rd ← ux(rs1) ⊕ ux(imm) 2
ORI rd,rs1,imm Or Immediate rd ← ux(rs1) ∨ ux(imm) 2
ANDI rd,rs1,imm And Immediate rd ← ux(rs1) ∧ ux(imm) 2
SLLI rd,rs1,imm Shift Left Logical Immediate rd ← ux(rs1) « ux(imm) 1
SRLI rd,rs1,imm Shift Right Logical Immediate rd ← ux(rs1) » ux(imm) 2
SRAI rd,rs1,imm Shift Right Arithmetic Immediate rd ← sx(rs1) » ux(imm) 2
ADD rd,rs1,rs2 Add rd ← sx(rs1) + sx(rs2) 1
SUB rd,rs1,rs2 Subtract rd ← sx(rs1) - sx(rs2) 1
SLL rd,rs1,rs2 Shift Left Logical rd ← ux(rs1) « rs2 1
SLT rd,rs1,rs2 Set Less Than rd ← sx(rs1) < sx(rs2) 1
SLTU rd,rs1,rs2 Set Less Than Unsigned rd ← ux(rs1) < ux(rs2) 1
XOR rd,rs1,rs2 Xor rd ← ux(rs1) ⊕ ux(rs2) 2
SRL rd,rs1,rs2 Shift Right Logical rd ← ux(rs1) » rs2 2
SRA rd,rs1,rs2 Shift Right Arithmetic rd ← sx(rs1) » rs2 2
OR rd,rs1,rs2 Or rd ← ux(rs1) ∨ ux(rs2) 2
AND rd,rs1,rs2 And rd ← ux(rs1) ∧ ux(rs2) 2
MUL rd,rs1,rs2 Multiply rd ← ux(rs1) × ux(rs2) 1
MULH rd,rs1,rs2 Multiply High Signed Signed rd ← (sx(rs1) × sx(rs2)) » xlen 1
MULHSU rd,rs1,rs2 Multiply High Signed Unsigned rd ← (sx(rs1) × ux(rs2)) » xlen 1
MULHU rd,rs1,rs2 Multiply High Unsigned Unsigned rd ← (ux(rs1) × ux(rs2)) » xlen 1
DIV rd,rs1,rs2 Divide Signed rd ← sx(rs1) ÷ sx(rs2) 2
DIVU rd,rs1,rs2 Divide Unsigned rd ← ux(rs1) ÷ ux(rs2) 2
REM rd,rs1,rs2 Remainder Signed rd ← sx(rs1) mod sx(rs2) 2
REMU rd,rs1,rs2 Remainder Unsigned rd ← ux(rs1) mod ux(rs2) 2

3.2 内存访问需要1个cycle,特例情况除外

RISC-V运算,需要先将数据从内存加载到寄存器,然后再做实际运算(如,用作add运算的输入)。还必须将寄存器中的值写回到内存中,以存储结果。内存的加载和存储(即读写)通常需要1个cycle。

内存访问,即读和写需要1个cycle,例外情况为page-in和page-out运算。

注意,与物理CPU相比,zkVM中的page非常快(衡量单位为cycle数):

  • 在物理CPU中,访问L1 cache中的某值,甚至需要3到4个cycle。访问L3 cache中的值需要30到70个cycle,访问主内存中的值需要100到150个cycle。应用程序中最常见的瓶颈之一是访问内存中的数据所需的往返时间。

3.2.1 paging

RISC Zero zkVM的每次执行,都是基于初始内存状态开始的。该内存状态(又名image),由image ID索引,image ID中包含了对内存中所有数据所commit的Merkle root。基于效率考虑,内存中的数据切分为1kB pages。

RISC Zero zkVM中的page与操作系统中的page类似,选择该术语来特指memory paging,或,swapping。程序的执行会切分为continuation segments。segments之间,zkVM本质是休眠的,以节约所有working memory给host;因CPU将使用hard drive。

a segment中首次访问page,需要paged-in,加载自host。为确认该page的正确性,guest会验证该page相对其image ID的Merkle inclusion proof。这些哈希操作需要一定数量的cycle:

  • 一次page-in操作,需要1094到5130个cycle,平均需要1130个cycle。

第一个page-in需要更多cycle——5130个cycle,因为其需要横穿该page table(即Merkle tree)直到root,对应的root等于image ID。一旦某path验证通过,就无需再次哈希,因此大多数page-in操作仅需要对leaf page(即data page)进行哈希。若某程序按顺序遍历内存,则其平均每个page需要1130个cycle,或每个字节对应1.35个cycle。

为在segment结束(即zkVM “休眠”)后支持continuation,需要page-out pages。page-out和page-in需要的操作数相同,因此,当首次将任意page写入到segment时,page-out开销为1094到5130个cycle。

若对应用profiling之后,了解page-in和page-out操作具有一定的开销,可优化应用以降低其内存使用和locality。这与优化data locality和L1/2 cache usage类似:

  • 使用更少的page
  • 重复使用相同的page,而不是随机访问模式
  • 压缩所访问的地址

都有助于降低paging开销。最好做试验来验证相应的优化效果。

3.3 zkVM没有原生浮点运算

RISC Zero zkVM未实现RISC-V浮点指令。因此,所有的浮点运算都以软件模拟。相比于1到2个cycle的整数运算,对浮点的基础运算(如加减乘除)需要60到140个cycle。
如有可能,尽可能使用整数来代替浮点数。

3.4 未对齐数据访问要贵得多

CPU定义四了运算数据的标准size——word。在RISC-V 32-bit ISA中,一个word的size为32位(4个字节)。内存通常按words读写。

当读写某地址不是4字节的倍数时,该运算将更昂贵。在一个简单的benchm按人口中,读取未对齐的u32值需要12个cycle,而读取对齐的u32值仅需要1个cycle。

内存的所有分配默认都是对齐的,且编译器会帮助对齐,这通常不是问题。

若你定义的结构体中包含了多个小原语类型字段(如boolu8i16等),且频繁访问该数据,则需要额外考虑对这些字段进行对齐。此外,若切成字节数组,注意做word-aligned索引。

3.5 内存访问是同步的

在物理CPU中,内存访问与寄存器操作是异步的,即意味着寄存器上的算术或逻辑运算运行的同时,该CPU在等待源自内存的结果。因为内存fetch延迟很大(为add两个寄存器时长的100到150倍),从而在处理器和应用层都有prefetching和speculative execution技术。

而在RISC Zero zkVM中,所有内存操作都是同步的,无论数据当前是否paged-in。内存prefetching对zkVM性能无益反而可能有害。

3.6 所有执行都是单线程的

zkVM执行有一个core和一个线程。因此,无需使用多线程。在guest程序中使用async routines、locking、atomic操作,只会让guest程序变慢。

3.7 zkVM无pipelining或其它指令级的并行化

现代处理器有execution pipelines,且Superscalar架构设计为并行执行指令。当pipeline保持为full,且使用独立执行单元时,指令吞吐量将更高。物理CPU实现无序和推测性执行,以及实现这一点的其他技术。

而RISC Zero的riscv32im实现非常简单。将从guest程序中读取指令,并按编译器选择的顺序执行。

开发者和编译器长使用如pre-fetching、avoiding branches或reordering指令等技术,来最大化指令级的并行化。但这些技术对zkVM根本无效。

参考资料

[1] RISC Zero团队2023年11月视频 zkVM Guest Optimization Tips and Tricks (RISC Zero Study Club)
[2] Guest Optimization Guide
[3] Guest Code 101
[4] zkVM Overview
[5] Guest Profiling Guide

RISC Zero系列博客

  • RISC0:Towards a Unified Compilation Framework for Zero Knowledge
  • Risc Zero ZKVM:zk-STARKs + RISC-V
  • 2023年 ZK Hack以及ZK Summit 亮点记
  • RISC Zero zkVM 白皮书
  • Risc0:使用Continunations来证明任意EVM交易
  • Zeth:首个Type 0 zkEVM
  • RISC Zero项目简介
  • RISC Zero zkVM性能指标
  • Continuations:扩展RISC Zero zkVM支持(无限)大计算
  • A summary on the FRI low degree test前2页导读
  • Reed-Solomon Codes及其与RISC Zero zkVM的关系
  • RISC Zero zkVM架构
  • RISC-V与RISC Zero zkVM的关系
  • 有限域的Fast Multiplication和Modular Reduction算法实现
  • RISC Zero的Bonsai证明服务
  • RISC Zero ZKP协议中的商多项式
  • FRI的Commit、Query以及FRI Batching内部机制
  • RISC Zero的手撕STARK

你可能感兴趣的:(zkVM,zkVM)