# Twist and Shout highlights
This post the explains highlights of [Twist and Shout](https://eprint.iacr.org/2025/105.pdf), the recent work on memory checking arguments. They are used in [ZKVM](https://hackmd.io/H6DuwE0lQr-FZIil7pyjEQ) to prove that a prover maintained memory correctly. Twist and Shout significantly improve the prover costs of prior works across the full range of realistic memory sizes.
Both Shout and Twist have logarithmic verifier costs. Twist and Shout comprise a family of protocols, namely:
* Twist supports read/write memories
* Shout targets read-only memories (lookup arguments).

Highlights:
* **New Memory‐Checking Paradigm**. Twist and Shout introduce a one‐hot addressing and increment approach to memory checking. Rather than relying on “grand product” or “grand sum” arguments, they commit the prover to sparse memory vectors and then verify reads and writes via sparse constraint systems that the sum‐check protocol handles efficiently.

* **Logarithmic Verifier Cost**. Both protocols achieve logarithmic work for the verifier regardless of memory size. This represents a substantial improvement over prior memory‐checking schemes, which often required linear or superlinear verifier overhead in the number of memory operations

* **Prover Efficiency** Across All Memory Scales. By exploiting sparsity, Twist and Shout drastically reduce prover work for both tiny memories (e.g., 32 RISC‐V registers) and enormous lookup tables (e.g., structured tables of size $2^{64}$+ as in Jolt). In fact, for realistic VM workloads, Twist and Shout outperform earlier memory‐checking SNARKs across the spectrum of memory sizes, enabling the prover to pay only for nonzero elements when running the sum‐check protocol

* **Key Insight: Sparse Commitments + Sum‐Check**. The protocols’ main technical achievement is that the prover can commit succinctly to a large but sparse memory vector. Once committed, memory verification reduces to verifying a handful of sparse constraints via sum‐check. Because these constraints remain sparse, the prover’s work scales with the number of actual memory accesses, not the total memory size. In practical terms, integrating Twist and Shout into a zkVM like Jolt yields roughly a 3× end-to-end prover speedup and shorter proofs, on top of other prover optimizations already in progress.

* **Field‐Choice Implications**. Twist and Shout highlight why 256-bit (or binary) fields are superior for SNARK performance. Fast zero‐commitments combined with sum-check yield particularly efficient memory checks in large characteristic fields. As a result, SNARKs built over 256-bit or binary fields reap maximal benefit from Twist and Shout’s sparse commitments, pushing prover cost profiles closer to native CPU execution.

* **Broader SNARK Utility**: Beyond zkVMs, Shout can be used to build standalone lookup‐based SNARKs. For example, SpeedySpartan uses Shout to outsource gate evaluations as table lookups, resulting in a SNARK for non-uniform circuits that is an order of magnitude faster than Spartan.

* **Closer to “SNARK‐Friendly” Real-World CPUs**: Overall, Twist and Shout narrow the gap between SNARK prover cost and real CPU execution, marking a significant step toward truly SNARK-friendly VM designs. Any VM labeled “SNARK-friendly” in the next few years will likely be measured by how well it leverages protocols like Twist and Shout