Anatomy of a STARK, Part 1: STARK Overview(译)

source: https://aszepieniec.github.io/stark-anatomy/overview

目录

• 交互式证明系统
• STARK概述
  • Computation
  • Arithmetization and Arithmetic Constraint System
  • Interpolation and Polynomial IOPs
  • Cryptographic Compilation with FRI

STARK 是一类交互式证明系统，但本教程将它们视为 SNARK 的一个特例，其中

• 哈希函数是唯一的加密成分，
• 算术化基于 AIR（algebraic intermediate representation,代数中间表示），并将关于计算完整性的声明转化为关于某些多项式的低次数(low degree)的声明
• 使用 FRI 作为子协议来证明多项式的低阶，并且 FRI 本身是用 Merkle 树实例化的
• 零知识是可选的。

本教程的这一部分主要是解释 STARK 定义中的关键术语。

交互式证明系统

在计算复杂性理论中，交互式证明系统是至少需要两方参与的协议，其中的一方为验证者，当且仅当该声明为真时，他才确信某个数学声明的正确性。从理论上讲，该主张可以是任何可以用数学符号表达的东西，例如 Birch 和 Swinnerton-Dyer 猜想，\(P \ne NP\), 或 “第十五个斐波那契数是 643617。” （在可靠的证明系统中，验证者将拒绝后面的声明。）

A cryptographic proof system turns this abstract notion of interactive proof systems into a concrete object intended for deployment in the real world. This restriction to real world applications induces a couple of simplifications:

• 该声明不是关于数学猜想，而是关于特定计算的完整性，例如“circuit \(C\) 在输入为 \(x\) 时输出为 \(y\)”, 或者“图灵机器 \(M\) 在 \(T\) 步后输出 \(y\)”。我们称该证明系统建立了 计算完整性
• 协议有两方，证明者和验证者。一般情况下验证者向证明者发送的消息包含纯粹的随机性，在这种情况下可以通过 Fiat-Shamir 变换让证明系统变为非交互。非交互式证明系统由从证明者到验证者的单个消息组成。
• 验证者可以接受非零但可以忽略不计的误报率或误报率，而不是要求完美的安全性。或者，证明系统仅在证明者计算能力有限的前提下提供安全性也是可以接受的。毕竟，所有计算机在实践中都是计算能力有限的。有时，作者使用术语argument system来区分 the protocol from a proof system that offers security against computationally unbounded provers, and argument for the transcript resulting from the non-interactivity transform.
• 之所以验证者不能重新运行整个计算来判断计算的完整性，是因为证明者可以访问验证者无法访问的资源。
  • 当受限资源是时间时，验证者的运行速度应该比天真的重新执行程序快一个数量级。实现此属性的证明系统被认为是简洁的(succinct)
  • 简洁的验证需要简短的证明，但一些证明系统（如 Bulletproofs 或 Aurora）虽然具有紧凑的证明，但验证仍然很慢。
  • 当验证者无法访问证明者可用的秘密信息时，并且当证明系统保护该秘密的机密性时，证明系统满足零知识性(zero-knowledge)。 验证者能够在不了解有关该计算的部分或全部输入的情况下确信该计算声明的真实性。
• 特别是在零知识证明系统的背景下，计算完整性声明可能需要进行细微的修改。 在某些情况下，仅仅证明一个声明的正确性是不够的，but the prover must additionally prove that he knows the secret additional input, and could as well have outputted the secret directly instead of producing the proof. Proof systems that achieve this stronger notion of soundness called knowledge-soundness are called proofs (or arguments) of knowledge.

A SNARK is a Succinct Non-interactive ARgument of Knowledge. The paper that coined the term SNARK used succinct to denote proof system with efficient verifiers. 然而，近年来，该术语的含义已被淡化为包括任何证明紧凑的系统。 本教程站在原始定义的一边。

STARK概述

STARK 代表 Scalable Transparent ARgument of Knowledge。

• Scalable 指需要同时满足两个条件：（1）证明时间在计算量上至多quasilinear的 \(T(n) = O(nlog(n))\)，而 SNARK 则允许证明者具有非常昂贵的复杂性，并且 (2) 验证时间在计算量上是polylogarithmic的 \(T(n) = O(log(n)^k)\)。
• Transparent refers to the fact that all verifier messages are just publicly sampled random coins. In particular, no trusted setup procedure is needed to instantiate the proof system, and hence there is no cryptographic toxic waste.

The acronym’s denotation suggests that non-interactive STARKs are a subclass of SNARKs, and indeed they are, but the term is generally used to refer to a specific construction for scalable transparent SNARKs.

For the purpose of introducing STARKs, the compilation pipeline is divided into four stages and three transformations. Later on in this tutorial there will be a much more fine-grained pipeline and diagram.

Computation

整个管道的输入是计算(computation)，您可以将其视为程序+输入+输出。 所有这三个都以机器友好的格式提供，例如字节列表。通常，程序由决定机器如何操作其资源的指令组成。如果正确的指令列表可以模拟任意图灵机，那么机器架构就是图灵完备的。

在本教程中，程序被硬编码到机器架构中，这也使得可以执行的计算是受限的。然而，输入和输出仍然是可变的。

The resources that a computation requires could be time, memory, randomness, secret information, parallelism. The goal is to transform the computation into a format that enables resource-constrained verifier to verify its integrity. It is possible to study more types of resources still, such as entangled qubits, non-determinism, or oracles that compute a given black box function, but the resulting questions are typically the subject of computational complexity theory rather than cryptographical practice.

Arithmetization and Arithmetic Constraint System

管道中的第一个转换称为算术化(arithmetization)。在这个过程中，对bit的基本逻辑和算术运算操作被转换为对有限域元素的本地有限域操作，它们最终表达了相同的计算。输出是一个算术约束系统，本质上是一堆方程，其系数和变量从有限域中取值。当且仅当约束系统具有符合条件的解时，计算才是完整的——这意味着，变量的某个取值使得所有方程都成立。

STARK证明系统对计算进行算数化的逻辑如下。 在任何时间点，计算状态都包含在 \(w\) 个寄存器的元组中，这些寄存器从有限域 \(\rm F\) 中获取值。机器定义了一个状态转换函数 \(f: {\rm F}^w \rightarrow {\rm F}^w\)，它在每个周期更新状态。The algebraic execution trace (AET) is the list of all state tuples in chronological order.

The arithmetic constraint system defines at least two types of constraints on the algebraic execution trace:

• Boundary constraints: at the start or at the end of the computation an indicated register has a given value.
• Transition constraints: any two consecutive state tuples evolved in accordance with the state transition function.

这些约束统称为 代数中间表示(algebraic intermediate representation) 或 AIR。Advanced STARKs may define more constraint types in order to deal with memory or with consistency of registers within one cycle.

Interpolation and Polynomial IOPs

通常意义上的插值(Interpolation)意味着找到一个通过一组数据点的多项式。在STARK的上下文中，插值意味着找到算数约束系统(arithmetic constraint system)的一个多项式表示。The resulting object is not an arithmetic constraint system but an abstract protocol called a Polynomial IOP.

The prover in a regular proof system sends messages to the verifier. But what happens when the verifier is not allowed to read them? 具体的说，如果来自证明者的消息能够被oracles取代(oracle指的是一种验证者可以在他选择的点中查询的抽象黑盒功能),那么协议就是一个 interactive oracle proof (IOP). 当oracles对应低度多项式时, 它是 Polynomial IOP. 直觉就是诚信的prover可以获得一个等式都成立的多项式约束系统，而作弊的prover获得的约束系统中，至少有一个等式是不成立的。当多项式相等时，它们在任何地方都相等，尤其是在验证者选择的随机点上。但是当多项式不相等时，它们几乎处处不相等，并且当验证者在随机点处验证时，这种不相等有极大的概率会暴露出来。

The STARK proof system interpolates the algebraic execution trace literally – 也就是说，它找出 \(w\) 个多项式 \(t_{i}(X)\), 使得 \(t_{i}(X)\) 在域 \(D\) 上的取值和 AET 中的第i个寄存器上的值对应. 这些多项式被作为oracle发送给verifier. At this point the AIR constraints give rise to operations on polynomials that send low-degree polynomials to low-degree polynomials only if the constraints are satisfied. 验证者模拟这些操作，因此可以推导出新的多项式，其低度(low degree)证明了约束系统的可满足性，从而证明了计算的完整性。换句话说，插值步骤将算术约束系统的可满足性降低到关于某些多项式的低阶的声明。

Cryptographic Compilation with FRI

在现实世界中，多项式预言机(polynomial oracles)并不存在。想要使用多项式 IOP 作为中间阶段的协议设计者必须找到一种方法来commit多项式，然后在验证者选择的点打开该多项式。 FRI 是 STARK 证明的关键组成部分，它通过使用 Reed-Solomon Codewords 的 Merkle 树来证明多项式次数的有界性，从而实现了这一任务。

与多项式 \(f(X) \in {\rm F}[X]\) 相关的 Reed-Solomon codeword 是它在给定域 \(D \subset {\rm F}\) 上的值列表. 考虑不失一般性的域 \(D\)，其元素个数大于多项式的最大允许次数。这些值可以放入 Merkle 树中，在这种情况下，Merkle树的根代表对多项式的承诺(commitment)。Fast Reed-Solomon IOP of Proximity (FRI) 是一种协议，它的证明者发送一个 Merkle 根序列，对应的codeword在每次迭代中长度减半。验证者检查连续轮次的merkle树（验证merkle path）以测试简单的线性关系。对于诚实的证明者，所表示的多项式的次数同样在每一轮中减半，因此远小于codeword的长度。然而对于恶意证明者来说，这个度数比codeword的长度小一。在最后一步，证明者发送一个与常数多项式相对应的non-trivial codeword。

上面没有提及的一个问题是：验证者如何在不属于域的点 \(z\) 处查询一个 committed polynomial \(f(X)\) ? 原则上，有一个明显而直接的解决方案：verifier将 \(z\) 发送给prover, prover则响应 \(y = f(z)\). 多项式 \(f(x) - y\) 在 \(X = z\) 处等于0, 因此 \(f(x) - y\) 必须被 \(X-z\) 整除. 所以证明者和验证者都可以访问一个新的低次多项式 \(\frac{f(X)-y}{X-z}\) . 如果prover在 \(f(z) = y\) 上撒谎, 那么他就无法证明 \(\frac{f(X)-y}{X-z}\) 是低度的, 所以他的欺诈行为将在 FRI 协议的过程中暴露出来。This is in fact the exact mechanism that enforces the boundary constraints; a slightly more involved but similar construction enforces the transition constraints. 新的多项式是已知因子相除的结果，因此它们将被称为 商(quotients) 并表示为 \(q_{i}(X)\) .

至此，多项式 IOP 已编译为一个交互式具体证明系统。 原则上，该协议是可以执行的。 然而，多做一步加密编译是值得的：用伪随机(但具有确定性)的东西替换验证者的随机硬币（随机性）。 这正是 Fiat-Shamir 变换，其结果是称为 STARK 的非交互式证明。