StarkNet 介紹：重點部件 Overview

本文将对 StarkNet 中的重要组件进行简要解释，不会涉及太多技术细节或代码部分，但希望读者能对 ZK-Rollup（Validity-Rollup）有基本的理解。

同时，由于 StarkNet 的系统设计涉及大量与零知识证明和 Merkle 树相关的数据结构，因此读者也需要大致了解什么是零知识证明和相关的 Merkle 树，这将有助于阅读过程的顺畅！未来可能会继续深入讨论各个系统组件。

简介
StarkNet OS（操作系统）主要由 Cairo 这个 StarkNet 的原生语言编写，Cairo 就像 StarkNet 上的 Solidity，可用于编写（基于 Cairo 的）智能合约，但同时也是一种零知识证明语言，可用于构建 StarkNet 核心操作系统和各种功能。

在 StarkNet 这条链上的所有逻辑都将包含在 StarkNet OS 中，例如如何定义账户状态、交易原理、合约执行，甚至如何进行位运算、哈希运算和原生的签名算法等，都会在这里定义。

总的来说，操作系统需要在交易和合约接收输入之后生成输出，并将这个输出更新到 StarkNet 这个 L2 的状态（State）中。

那为什么要使用零知识证明语言来编写 StarkNet OS 呢，而不是其他常见的语言？

相信大家都知道扩容的其中一个大方向就是 “把繁琐的计算丢到 Off-Chain 并且只要在 On-Chain 做验证即可”，而 StarkNet 作为 ZK-Rollups 的一员，他会将 Cairo 编写的 ZK-STARK 程序执行完的内容通过 STARK-proof system 进行证明（prove）并在 Ethereum 上进行验证（verify）。

如果看到这里还不是非常了解也没关系，接下来几个小节会依序补完这些名词解释和使用场景！

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

Sequencer 是一个 off-chain 服务器，工作流程的第一步是接收用户提交的交易（来自不同用户的多个不同交易），然后 Sequencer 会决定交易的顺序并构建 L2 的区块。

Sequencer 需要确认交易是经过账户所有者授权的（由于 StarkNet 使用了原生 AA 的账户系统，因此这里不一定是简单确认签名正确，可能是多签或其他验证逻辑）。然后通过 StarkNet OS 执行一次交易，概念上类似于 EVM，接收输入后执行合约逻辑并生成输出。

Sequencer 执行交易会产生一个 trace（需要注意这个 trace 不是函数返回而是执行过程的证明），然后将这些执行内容的 “过程证明” 发送给 Prover，告诉大家：“我执行过这段代码了。”

在接下来要讲的 Prover 和 Verifier 验证成功之后，Sequencer 会更新 L1 StarkNet 核心合约中的状态。

StarkNet Prover & Verifier
Prover 同样也是一个 Off-Chain 服务器，主要任务是接收 Sequencer 执行完代码产生的 trace，并生成相应的 STARK 证明，然后交给运行在 L1 上的 Verifier 合约进行验证，验证通过后将注册 fact 以供未来的 L1 StarkNet 核心合约进行查询。

Verifier 合约会在 L1 上负责验证一切是否合法，它会接受输入和 STARK 证明来决定。

补充说明：目前 StarkNet 中只有一个 Prover，它不仅为 StarkNet 生成证明，还为运行在 StarkWare 自己的 StarkEx rollup 上的所有其他应用程序（例如 Immutable X、dYdX、Sorare 等）生成证明。这就是为什么该服务被称为 Shared Prover 或 SHARP 的原因。

StarkNet L1 核心合约
StarkNet L1 核心合约存储着 L2 上状态的证明，大家常说 Rollups 的安全性是由 Ethereum 这个 L1 保证的就是来源于此。当我们的 trace 经过 Prover 生成证明并在 L1 Verifier 合约验证后，将告诉 L1 核心合约这个 “状态更新” 是正确无误的。

“状态更新” 指的是在 StarkNet 执行交易后会改变状态，我们要想办法正确地传达给 L1 核心合约说 L2 上的状态从 S 更新为 S’了。

当 L1 核心合约通过 Verifier 知道这次的状态更新是合法的后，Sequencer 就会在合约中更新 State Root。

换句话说，知道 “这次状态更新是合法” 的意思是，我们通过 ZKP 证明了链下的计算是真的被正确执行了，而不是编造出一个随便的交易结果就叫 L1 核心合约更新状态。

此外如果 StarkNet 在 L1 有一些 operations 需要定义，也会定义在 StarkNet L1 核心合约中，例如：

官方认可的 Verifiers 合约（Addresses List）
L1 ↔ L2 互动的逻辑（消息传递的方式）
讨论
去中心化与开源
Rollups 中的 Sequencer 或像 Prover 这样的角色被该链的官方把持着其实会引来社区的质疑，因此对长远发展来说开源非常重要。不仅有更多双眼睛可以审视这个代码，也可以因为社区的协作和贡献让系统更安全、有效率。退一万步来说，社区还能够独立地开发并维护整个网络。

所谓的去中心化在 StarkNet 社区有两个主要讨论层面：

不需要许可就能运作的 Sequencers 和 Provers 可以确保这个网络是抗审查的（censorship-resistant）。
因为使用了 STARK-proofs，任何人都可以用很低的硬件成本来验证整条链的正确性，同时也不需要信任任何第三方单位。
当前 StarkNet 已经开源了最新的 Sequencer，Prover 也即将开源，有兴趣的人可以查看以下资源：

StarkNet 分散式协议 III — 共识
开源：StarkNet 的新 Sequencer
开源 StarkNet Prover
性能与瓶颈
StarkNet 运作的性能和 Gas 费用在这几个月我自己使用下来，其实并不是非常好（有时甚至差或完全不能使用），但 StarkNet 官方表示过去他们都重点关注在 Functionality 上，现在（Cairo 1.0 即将上线之后）已经做好了基础建设，将会把开发重心移动到性能上。

StarkNet 认为提高 TPS 最好的方向是在同样的出块时间下，提高能够容纳的交易量，也就是区块限制。因此只要是与区块生成有关的部件都会需要提高效率。例如 Sequencer 就是其中最大的瓶颈，所以才有规划未来改成不同算法（从先到者先处理改为并行处理）、不同数据结构（原本是 Patricia-Trie），以及用 Rust（原本是 python）编写的新 Sequencer — Blockifier。

新的并行化 Sequencer 可参考以下资源：

https://twitter.com/starkience/status/1615502502773903361?s=20
https://twitter.com/Starknet/status/1595341405655683072
https://www.youtube.com/watch?v=9IszIArEt1M
关于这个议题，StarkNet 提出了一个说法解释为何提高区块限制对 L2 有用，而对 L1 没用。原因是如果区块大小太大，我们对全节点的要求就越高（这样他们才可以跟上链的增长速度并进行验证）。如果这个要求高到大部分用户都无法承受，无法自行验证，那就使得绝大部分人都需要以一个不信任的方式参与网络。

结语
撰写 StarkNet 的介绍文时需要不少的参考文献，我尽量把所有参考到的内容都附上（文中或文末），希望能给愿意深入了解的人们提供帮助，也非常感谢这么多善心人士愿意分享自己对 StarkNet 的研究成果！