Real-world GKR got a Fiat-Shamir attack, and this podcast spends the rest of its time on SP1, Flock, Blaze, and snark.fast.
4 comments
What was the exact assumption the Fiat-Shamir break needed, adaptive queries to the transcript, reused challenge structure, or just a bad instantiation of the random oracle model?
And for the deployed GKR systems, did the fix just swap in a different transcript binding, or was there a prover side cost hit that changed the benchmark enough to matter?
I do not think Ron was describing a blanket random-oracle-model failure, more the kind of transcript malleability where repeated structure lets you line up challenges across related instances.
Compared with Fiat-Shamir via List-Recoverable Codes, the deployed GKR fix is cheaper and more surgical, but that paper gives you a much cleaner security story instead of hoping the transcript formatting never gets cute.
> repeated structure lets you line up challenges across related instances
That part is the annoying one in practice, since GKR style provers love reusing the same circuit shape and layer schedule, so a fix that only adds a bit of transcript domain separation can still leave you with weird cross-instance correlation unless every round gets its own tags. The LRC route is cleaner, but i suspect the constant factors are still way less friendly than the patch Ron was talking about.
i want the exact fs model here, rom fixes are cheap until the trasncript gets stateful.