From fb9e4539e18e595b6af042c6f8f84c49f5fa76b0 Mon Sep 17 00:00:00 2001 From: Justin Thaler <39494992+GUJustin@users.noreply.github.com> Date: Sun, 6 Oct 2024 20:46:21 -0400 Subject: [PATCH] Update folding.md --- book/src/future/folding.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/book/src/future/folding.md b/book/src/future/folding.md index 797042a31..e26216c8b 100644 --- a/book/src/future/folding.md +++ b/book/src/future/folding.md @@ -20,6 +20,10 @@ and the details will be fully fleshed out in an upcoming e-print. +Note that this plan does not require "non-uniform folding". The fact that there are many different primitive RISC-V +instructions is handled by "monolithic Jolt". Folding is merely applied to accumluate many copies of the same claim, +namely that a Jolt proof (minus any HyperKZG evaluation proof) was correctly verified. + # Space cost estimates If we shard the VM execution into chunks of $2^{20}$ RISC-V cycles each, then naively implemented we expect Jolt proving to require about 10 GBs of space. The bottleneck here is Spartan proving. The prover space cost for proving all the grand products in Jolt is less than that of Spartan proving, and the prover can compute the Spartan proof and more or less "wipe" memory before computing the grand product proofs. @@ -55,4 +59,8 @@ This time overhead can be reduced with additional engineering/optimizations. For
  • For at least the first round of Spartan's sum-check, we could store only $32$ bits per entry of $a, b, c$ rather than 256, which could save another factor of two in space cost. Also, prover speed optimizations for applying sum-check to small values described in Bagad-Domb-Thaler can also lead to additional space improvements for Spartan. At some point, the space cost of computing grand product proofs would dominate the space cost of Spartan proving and it won't be worthwhile to cut Spartan proving space further.
    • +
  • We can lower the size of Jolt proofs, and hence the time spent on recursive proving, by a factor of 2x-4x by +switching to the grand product argument from Quarks/Spartan. This does increase prover time "outside of recursion" +since the Quarks/Spartan prover commits to random field elements, but for small shard sizes (i.e., very small prover space, around 1GB or so) it may lead to a faster prover overall.
    • +