零知识证明可以让一方 (证明方) 在不透露任何实际信息的情况下向另一方 (验证方) 证明某保密信息或声明是真的。

为什么需要零知识证明？当我们不想披露任何信息，但需要说服其他人相信我们知道的保密信息和提出的声明是真的时候。

目前有两种零知识证明：

1.交互式的 (Interactive)

2.非交互式的 (Non Interactive)：

（非交互式证明是指证明者可以将证明发送给验证者，而无需任何进一步的通信或信息交换。这使得证明系统更加高效和实用。此属性是通过称为Fiat-Shamir 启发式的过程实现的。）

Rollup 是一种扩容解决方案，在 L1 外执行交易，但在 L1 上发布交易数据。这种工作办法可以让 rollup 对网络进行扩容，但依然受到以太坊共识的安全保护。

将计算转移到链下进行，实际上可以处理更多交易。因为只需要将 rollup 交易的一些数据放进以太坊区块中。

要做到这一点，rollup 交易在另一条链上执行，而这条链甚至可以运行一个 rollup 特定版本的 EVM。

执行完 rollup 上的交易后，下一步是将这些交易打包成一个 batch，然后发布到以太坊主链上。

整个过程基本是执行交易、提取数据、压缩，将其 rollup 到一个个 batch 中然后发到主链上，因而得名 —— ”rollup“。

以太坊怎样得知这些数据是有效的、而不是由恶意份子出于牟利目的而提交的呢🤔？

每个 rollup 都会在 L1 部署一组智能合约，来负责处理存款、取款交易以及验证证明。

证明也是主要区分不同类型 rollups 的因素。

Optimistic rollups 使用欺诈证明。与之相对， ZK rollups 采用有效性证明。

在 ZK rollups 中，发布到 L1 的每个 batch 包含一个叫做 ZK-SNARK 的加密证明。当提交交易 batch 至 L1 之后，L1 上的合约可以快速验证 ZK-SNARK 证明，无效的 batch 会被直接拒绝。

ZK rollups 是第 2 层扩展解决方案，可在主链上提交汇总版本之前处理计算并在链下处理大量交易。零知识汇总在两个层上提供近乎即时的结算，这与乐观汇总不同。

ZK-rollups 利用其零证明技术，定期向父网络上的关联智能合约提交有效性证明，从而确认第 2 层网络上交易的准确性。对零证明的依赖还减少了共享交易数据量，从而使 ZK rollups 默认以隐私为中心。

除了隐私之外，ZK Rollups 还使用户无需等待数天才能从 Layer-2 解决方案中提取资金。

ZK rollups 的构建更加复杂，需要严重依赖开发人员来维护整个系统。此外，网络结构通常涉及设置复杂且昂贵的硬件来验证交易。根据方法的不同，如果验证排序是集中的，ZK rollups 可能会带来一些相同的审查风险。由于并非所有 ZK rollup 都是相同的，因此需要独立检查这些中心化因素。

ZK-SNARK 由三个主要密码功能组成：密钥生成、证明生成和验证。

密钥生成功能是初始设置阶段的一部分，该阶段生成证明系统运行所需的加密密钥。具体来说，该函数生成一个证明密钥（用于创建证明）和一个验证密钥（用于验证证明）。

例如，C(x, w)是我们需要在不透露细节的情况下验证的逻辑语句。这里，“x”是公共输入，“w”是私有输入（见证人）。设置函数作为该语句的数学表示，将安全参数“λ”作为输入。这用于生成证明密钥“pk”和验证密钥“vk”。

设置(C,λ) → (pk,vk)

该函数由证明者运行来创建加密证明——证明者可以发送给验证者的简洁的零知识证明。证明者采用私有输入**“w”（或证人）、公钥“x”和证明密钥pk来生成证明“prf”** ，证明他们知道该信息而不泄露它。

证明(w,x,pk) → prf

zk-SNARKs中的验证函数被验证者用来检查证明者提供的密码证明的有效性。验证者使用证明**'prf'、验证密钥'vk'和公共输入'x'来确定证明是否有效。验证（vk，prf，x）→ True（如果有效）或 False（如果无效）。

这满足了零知识证明的所有三个基本属性：

• 完整性：如果初始语句 C(x, w) 是正确的，则始终会生成有效的证明“prf”并被验证者接受。

• 可靠性：如果初始陈述 C(x, w) 不正确，则证明者生成的任何证明“prf”都将被验证者视为无效。

• 零知识：验证者验证证明“prf”，而不了解有关私人输入（见证人）“w”的任何信息。

这是 zk-SNARK 工作原理的基本概述。除此之外，还有三个重要概念为 zk-SNARK 提供支持。它们是：椭圆曲线加密 (ECC)、可信设置和 Fiat-Shamir 启发式

starknet基于zk-stark，stark与snark类似，不同点在下方指出

StarkNet 作为一个 Rollups， 没有类似过往我们认识的矿工角色存在，但依旧需要一个角色来 「验证交易」、「决定交易顺序」、「构建区块」，而负责这三者工作内容的人就是 Sequencer。

Sequencer 是一个 off-chain server，工作流程的第一步是接收用户送上来的交易（数笔来自不同用户的不同交易），之后 Sequencer 会决定交易顺序并且构建 L2 的区块。

Sequencer 需要确认交易是被帐户拥有者授权的（由于 StarkNet 使用了原生 AA 的帐户系统，因此这里不一定是单纯确认签名正确，有可能是多签或其他验证逻辑）。接着通过 StarkNet OS 执行一次交易，概念上就像 EVM 一样，接收 input 后执行合约逻辑并产出 output。

Sequencer 执行过交易之后会生产出一个 trace（需要注意这个 trace 不是 function return 而是一个执行过程的见证），并将这些执行内容的过程见证送去给 Prover 让其生产证明。

Prover 同样也是一个Off-Chain Server，这个角色主要就是接收Sequencer执行完交易产生的trace，并且生产出相对应的STARK proofs，然后交给在L1 上的Verifier Contract 验证，验证通过之后会注册fact供未来的L1 StarkNet Core Contract 进行查询。

StarkNet L1 Core Contract 储存着 L2 上状态们的证明，大家常常说 Rollups 的安全性是由 Ethereum 这个 L1 保证的就是来自于此。当我们的 trace 经过 Prover 产生 proof 并且在 L1 Verifier Contract 验证之后，就会告诉 L1 Core Contract 这个「状态更新」是正确无误的。

「状态更新」指的是在 StarkNet 执行交易之后会改变状态，而我们要想办法正确地传达给 L1 Core Contract 说 L2 上的状态从 S 更新成 S’ 了。

当 L1 Core Contract 透过 Verifier 知晓了此次的状态更新是合法后，Sequencer 就会在合约中更新 State Root。

换句话说，知道「这次状态更新是合法」的意思是，我们透过 ZKP 证明了链下的运算是真的被正确执行了，而不是瞎掰出来一个随便的交易结果就叫 L1 Core Contract 更新状态。

Starknet 交易生命周期的高级步骤如下：

1. 交易提交：交易被提交到网关之一，充当内存池，并将交易状态标记为RECEIVED。

2. 内存池验证： 内存池对交易进行初步验证。如果交易无效，则不会继续进行。

3. Sequencer验证：Sequencer在执行交易之前对交易进行初步验证，以确保交易仍然有效。如果交易无效，则不会继续进行。

   这种情况下的验证类似于以太坊的签名检查，包括运行帐户的__validate__功能

4. 执行：Sequencer操作按顺序将所有通过初步验证的交易应用到状态。如果交易在执行过程中失败，则会将其包含在状态为 的块中REVERTED。

5. 证明生成和验证： Prover在新块上执行操作系统，计算证明，并将其传输给L1验证器，由L1验证器验证该证明。此时，L1 状态已更新以包含该事务。

• 相同点

  • 都实现了将隐私的输入可靠隐藏；

  • 都是基于知识论证，不知道private input的prover生成不了有效的proof；

  • 都可以实现交互式与非交互式的算法，只是取决于randomness是由谁来生成的；

• 不同点

  • zk-stark具有可扩展性，即证明和验证的耗时与原始计算的耗时分别呈拟线性关系（且线性因子为常量）和对数关系，这意味这，如果原始输入的数据集增大1000000倍，zk-stark的证明耗时增加线性倍数的时间，但验证时间仅仅增加21*log1000000 =~ 420倍。证明耗时呈线性关系基本满足所有的ZKP算法，但是验证时间呈对数关系，仅此一家，因此在扩展性上，zk-stark要胜一筹。

    1. 在扩展性方面，STARK 的扩展性更强。证明生成速度具备线性扩展性，验证时间和证明大小具备对数扩展性。但缺点在于生成的证明尺寸更大。但随着证明规模增加，验证成本将会边际递减——这意味证明越大，总成本越低。

  • zk-stark同样具有简洁性，但是是验证简洁性。所谓简洁性，通常是指即使验证程序很大，生成的proof size也不会很大，同时又能很快的完成验证（比native computation快很多）。相比对zk-snark，zk-stark的proof size要大的多，因此在简洁性上，zk-snark要胜一筹。

  • zk-stark有更简单的密码学假设，避免了对椭圆曲线、配对和指数知识假设的需要，纯粹依赖哈希和信息论，因此抗量子攻击。总体来讲 STARK 比 SNARK 更安全。

链上处理的速度是零知识汇总相对于乐观汇总的根本优势。零知识汇总记录到底层区块链的速度比乐观汇总交易更快，因为没有等待期，在此期间交易的合法性可能会受到质疑。

另一方面，零知识汇总所使用的加密有效性证明需要大量的散列能力来计算。因此，乐观汇总解决方案可能对链上活动较少的项目更有帮助。

由于缺乏有效性证明计算，乐观汇总现在更具可扩展性。使用乐观汇总的程序不太可能受到事务大幅激增的影响，而零知识汇总解决方案可能会严重减慢速度。

Optimistic Rollups 和 ZK Rollups 与以太坊网络上的智能合约交互的方式是另一个区别。Optimistic Rollup 可以直接在主区块链上运行智能合约。另一方面，ZK Rollups 无法在主链上执行智能合约。

参考：

https://www.wtf.academy/starknet-basecamp-2023#sequencer

https://blog.thirdweb.com/what-is-a-zk-snark/

https://ethereum.org/en/developers/docs/scaling/zk-rollups/#zk-rollups-and-ethereum

https://zkrollups.io/optimistic-rollups-vs-zk-rollups/

零知识证明可以让一方 (证明方) 在不透露任何实际信息的情况下向另一方 (验证方) 证明某保密信息或声明是真的。

为什么需要零知识证明？当我们不想披露任何信息，但需要说服其他人相信我们知道的保密信息和提出的声明是真的时候。

目前有两种零知识证明：

1.交互式的 (Interactive)

2.非交互式的 (Non Interactive)：

（非交互式证明是指证明者可以将证明发送给验证者，而无需任何进一步的通信或信息交换。这使得证明系统更加高效和实用。此属性是通过称为Fiat-Shamir 启发式的过程实现的。）

Rollup 是一种扩容解决方案，在 L1 外执行交易，但在 L1 上发布交易数据。这种工作办法可以让 rollup 对网络进行扩容，但依然受到以太坊共识的安全保护。

将计算转移到链下进行，实际上可以处理更多交易。因为只需要将 rollup 交易的一些数据放进以太坊区块中。

要做到这一点，rollup 交易在另一条链上执行，而这条链甚至可以运行一个 rollup 特定版本的 EVM。

执行完 rollup 上的交易后，下一步是将这些交易打包成一个 batch，然后发布到以太坊主链上。

整个过程基本是执行交易、提取数据、压缩，将其 rollup 到一个个 batch 中然后发到主链上，因而得名 —— ”rollup“。

以太坊怎样得知这些数据是有效的、而不是由恶意份子出于牟利目的而提交的呢🤔？

每个 rollup 都会在 L1 部署一组智能合约，来负责处理存款、取款交易以及验证证明。

证明也是主要区分不同类型 rollups 的因素。

Optimistic rollups 使用欺诈证明。与之相对， ZK rollups 采用有效性证明。

在 ZK rollups 中，发布到 L1 的每个 batch 包含一个叫做 ZK-SNARK 的加密证明。当提交交易 batch 至 L1 之后，L1 上的合约可以快速验证 ZK-SNARK 证明，无效的 batch 会被直接拒绝。

ZK rollups 是第 2 层扩展解决方案，可在主链上提交汇总版本之前处理计算并在链下处理大量交易。零知识汇总在两个层上提供近乎即时的结算，这与乐观汇总不同。

ZK-rollups 利用其零证明技术，定期向父网络上的关联智能合约提交有效性证明，从而确认第 2 层网络上交易的准确性。对零证明的依赖还减少了共享交易数据量，从而使 ZK rollups 默认以隐私为中心。

除了隐私之外，ZK Rollups 还使用户无需等待数天才能从 Layer-2 解决方案中提取资金。

ZK rollups 的构建更加复杂，需要严重依赖开发人员来维护整个系统。此外，网络结构通常涉及设置复杂且昂贵的硬件来验证交易。根据方法的不同，如果验证排序是集中的，ZK rollups 可能会带来一些相同的审查风险。由于并非所有 ZK rollup 都是相同的，因此需要独立检查这些中心化因素。

ZK-SNARK 由三个主要密码功能组成：密钥生成、证明生成和验证。

密钥生成功能是初始设置阶段的一部分，该阶段生成证明系统运行所需的加密密钥。具体来说，该函数生成一个证明密钥（用于创建证明）和一个验证密钥（用于验证证明）。

例如，C(x, w)是我们需要在不透露细节的情况下验证的逻辑语句。这里，“x”是公共输入，“w”是私有输入（见证人）。设置函数作为该语句的数学表示，将安全参数“λ”作为输入。这用于生成证明密钥“pk”和验证密钥“vk”。

设置(C,λ) → (pk,vk)

该函数由证明者运行来创建加密证明——证明者可以发送给验证者的简洁的零知识证明。证明者采用私有输入**“w”（或证人）、公钥“x”和证明密钥pk来生成证明“prf”** ，证明他们知道该信息而不泄露它。

证明(w,x,pk) → prf

zk-SNARKs中的验证函数被验证者用来检查证明者提供的密码证明的有效性。验证者使用证明**'prf'、验证密钥'vk'和公共输入'x'来确定证明是否有效。验证（vk，prf，x）→ True（如果有效）或 False（如果无效）。

这满足了零知识证明的所有三个基本属性：

• 完整性：如果初始语句 C(x, w) 是正确的，则始终会生成有效的证明“prf”并被验证者接受。

• 可靠性：如果初始陈述 C(x, w) 不正确，则证明者生成的任何证明“prf”都将被验证者视为无效。

• 零知识：验证者验证证明“prf”，而不了解有关私人输入（见证人）“w”的任何信息。

这是 zk-SNARK 工作原理的基本概述。除此之外，还有三个重要概念为 zk-SNARK 提供支持。它们是：椭圆曲线加密 (ECC)、可信设置和 Fiat-Shamir 启发式

starknet基于zk-stark，stark与snark类似，不同点在下方指出

StarkNet 作为一个 Rollups， 没有类似过往我们认识的矿工角色存在，但依旧需要一个角色来 「验证交易」、「决定交易顺序」、「构建区块」，而负责这三者工作内容的人就是 Sequencer。

Sequencer 是一个 off-chain server，工作流程的第一步是接收用户送上来的交易（数笔来自不同用户的不同交易），之后 Sequencer 会决定交易顺序并且构建 L2 的区块。

Sequencer 需要确认交易是被帐户拥有者授权的（由于 StarkNet 使用了原生 AA 的帐户系统，因此这里不一定是单纯确认签名正确，有可能是多签或其他验证逻辑）。接着通过 StarkNet OS 执行一次交易，概念上就像 EVM 一样，接收 input 后执行合约逻辑并产出 output。

Sequencer 执行过交易之后会生产出一个 trace（需要注意这个 trace 不是 function return 而是一个执行过程的见证），并将这些执行内容的过程见证送去给 Prover 让其生产证明。

Prover 同样也是一个Off-Chain Server，这个角色主要就是接收Sequencer执行完交易产生的trace，并且生产出相对应的STARK proofs，然后交给在L1 上的Verifier Contract 验证，验证通过之后会注册fact供未来的L1 StarkNet Core Contract 进行查询。

StarkNet L1 Core Contract 储存着 L2 上状态们的证明，大家常常说 Rollups 的安全性是由 Ethereum 这个 L1 保证的就是来自于此。当我们的 trace 经过 Prover 产生 proof 并且在 L1 Verifier Contract 验证之后，就会告诉 L1 Core Contract 这个「状态更新」是正确无误的。

「状态更新」指的是在 StarkNet 执行交易之后会改变状态，而我们要想办法正确地传达给 L1 Core Contract 说 L2 上的状态从 S 更新成 S’ 了。

当 L1 Core Contract 透过 Verifier 知晓了此次的状态更新是合法后，Sequencer 就会在合约中更新 State Root。

换句话说，知道「这次状态更新是合法」的意思是，我们透过 ZKP 证明了链下的运算是真的被正确执行了，而不是瞎掰出来一个随便的交易结果就叫 L1 Core Contract 更新状态。

Starknet 交易生命周期的高级步骤如下：

1. 交易提交：交易被提交到网关之一，充当内存池，并将交易状态标记为RECEIVED。

2. 内存池验证： 内存池对交易进行初步验证。如果交易无效，则不会继续进行。

3. Sequencer验证：Sequencer在执行交易之前对交易进行初步验证，以确保交易仍然有效。如果交易无效，则不会继续进行。

   这种情况下的验证类似于以太坊的签名检查，包括运行帐户的__validate__功能

4. 执行：Sequencer操作按顺序将所有通过初步验证的交易应用到状态。如果交易在执行过程中失败，则会将其包含在状态为 的块中REVERTED。

5. 证明生成和验证： Prover在新块上执行操作系统，计算证明，并将其传输给L1验证器，由L1验证器验证该证明。此时，L1 状态已更新以包含该事务。

• 相同点

  • 都实现了将隐私的输入可靠隐藏；

  • 都是基于知识论证，不知道private input的prover生成不了有效的proof；

  • 都可以实现交互式与非交互式的算法，只是取决于randomness是由谁来生成的；

• 不同点

  • zk-stark具有可扩展性，即证明和验证的耗时与原始计算的耗时分别呈拟线性关系（且线性因子为常量）和对数关系，这意味这，如果原始输入的数据集增大1000000倍，zk-stark的证明耗时增加线性倍数的时间，但验证时间仅仅增加21*log1000000 =~ 420倍。证明耗时呈线性关系基本满足所有的ZKP算法，但是验证时间呈对数关系，仅此一家，因此在扩展性上，zk-stark要胜一筹。

    1. 在扩展性方面，STARK 的扩展性更强。证明生成速度具备线性扩展性，验证时间和证明大小具备对数扩展性。但缺点在于生成的证明尺寸更大。但随着证明规模增加，验证成本将会边际递减——这意味证明越大，总成本越低。

  • zk-stark同样具有简洁性，但是是验证简洁性。所谓简洁性，通常是指即使验证程序很大，生成的proof size也不会很大，同时又能很快的完成验证（比native computation快很多）。相比对zk-snark，zk-stark的proof size要大的多，因此在简洁性上，zk-snark要胜一筹。

  • zk-stark有更简单的密码学假设，避免了对椭圆曲线、配对和指数知识假设的需要，纯粹依赖哈希和信息论，因此抗量子攻击。总体来讲 STARK 比 SNARK 更安全。

链上处理的速度是零知识汇总相对于乐观汇总的根本优势。零知识汇总记录到底层区块链的速度比乐观汇总交易更快，因为没有等待期，在此期间交易的合法性可能会受到质疑。

另一方面，零知识汇总所使用的加密有效性证明需要大量的散列能力来计算。因此，乐观汇总解决方案可能对链上活动较少的项目更有帮助。

由于缺乏有效性证明计算，乐观汇总现在更具可扩展性。使用乐观汇总的程序不太可能受到事务大幅激增的影响，而零知识汇总解决方案可能会严重减慢速度。

Optimistic Rollups 和 ZK Rollups 与以太坊网络上的智能合约交互的方式是另一个区别。Optimistic Rollup 可以直接在主区块链上运行智能合约。另一方面，ZK Rollups 无法在主链上执行智能合约。

参考：

https://www.wtf.academy/starknet-basecamp-2023#sequencer

https://blog.thirdweb.com/what-is-a-zk-snark/

https://ethereum.org/en/developers/docs/scaling/zk-rollups/#zk-rollups-and-ethereum

https://zkrollups.io/optimistic-rollups-vs-zk-rollups/