Vitalik新作：探索Circle STARKs

原文标题：《Exploring circle STARKs》

想要理解这篇文章的前提是你们已经了解了 SNARKs 和 STARKs 的基本原理。如果你对此不太熟悉，建议你先阅读本文的前几部分来了解相关基础知识。

近年来，STARKs 协议设计的趋势是转向使用较小的字段。最早期的 STARKs 生产实现使用的是 256 位字段，即对大数字（如 21888...95617）进行模运算，这使得这些协议与基于 elliptic curve 的签名兼容。但是这种设计的效率比较低，一般情况下，处理计算这些大数字并没有实际的用途，还会浪费很多的算力，比如处理 X（代表某个数字）和处理四倍的 X ，处理 X 只需要九分之一的计算时间。为了解决这个问题，STARKs 开始转向使用更小的字段：首先是Goldilocks，然后是Mersenne31 和 BabyBear。

这种转变提升了证明速度，比如 Starkware 能够在一台 M3 笔记本电脑上每秒证明620,000 个 Poseidon2 哈希值。这意味着，只要我们愿意信任 Poseidon2 作为哈希函数，那么就可以解决开发**的ZK-EVM中的难题。那么这些技术是如何工作的？这些证明如何在较小的字段上建立？这些协议与 Binius 等解决方案相比如何？本文将探讨这些细节，特别关注一种名为Circle STARKs（在Starkware 的 stwo、Polygon 的plonky3以及我自己在 Python 中实现的版本）的方案，这种方案具有与 Mersenne31 字段兼容的独特属性。

使用较小的数学字段时常见的问题

在创建基于哈希的证明（或**类型的证明）时，一个非常重要的技巧是通过对多项式在随机点的评估结果进行证明，能够间接验证多项式的性质。这种方法可以大大简化证明过程，因为在随机点的评估通常比处理整个多项式要容易得多。

例如，假设一个证明系统要求你生成一个对多项式的 commitment，A，必须满足 A^3 (x) x - A (\omega*x) = x^N（ZK-SNARK 协议中一种非常常见的证明类型）。协议可以要求你选择一个随机坐标