zkc performance

[OlivierBBB]

• ability of zkc to run meaningful programs in a reasonable amount of time
  • [RV] running zevm guest program with inputs #3260
  • [RV] running zevm guest program with keccak-zkc-precompile #3257
  • [RV] running zevm guest program with ecdsa-zkc-precompile #3258
  • [RV] running zevm guest program with ssz-zkc-precompile #3259
  • the extended guest program / rollup wrapper when it becomes available
• reasonable performance for realistic workload on
  • keccak, metrics tracked in notion
  • potentially other non RV functionalities (e.g. poseidon1) if we write the verifier in zkc
• reasonable trace generation time for the above executions
• identification of zkc-performance pain points e.g.
  • [RV] once and for all instruction decoding #3256
• how to benchmark ? @amkCha

Note. Transpiling RV to a different architecture for native execution à la ZisK (i.e. pre-flight) is not part of the RV Arith Milestone 2, neither is segmentation / striping. But we may want to start exploration in order to gauge ultimate performance.

[OlivierBBB]

June 3 update

• keccak performance: zkc optimizations + optimization of bit rotation by @DavePearce
  • zkc-native-keccak now performing as follows:
  • 10k keccak hashes [40k data blocks in total, 4 per hash] running in 70 seconds, see metrics notion page
• zevm guest program execution. @garyschulte able to run zevm in our RV-interpreter with inputs, execution is very long to the point where he had to halt it;

Misc

@DavePearce shared metrics on zkc/RV overhead: RV instruction decoding in zkc introduces a 180x overhead over RV execution in the sense of: the average RV opcode processing generates 180 zkc instructions.

@DavePearce unable to merge after zkc repo moved to LFDT/zkc. Poseidon-zkc-precompile integration hanging: waiting for required feature to be merged in zkc;

@ivokub suggested that the arithmetization team could help with the following critical precompiles

• ecdsa
• modexp

Note. We are already working on keccak, and may have to add ssz to the mix if the guest program perf dips in ssz.

Next

• @lorenzogentile404 and @OlivierBBB will connect the zevm to @amkCha's zkc native keccak implementation
  • keccak is a likely culprit in zevm execution being that long
  • ecdsa may also contribute
• we may also look into native ecdsa in zkc
• @amkCha will look into the one-time-decoding of the RV binary