同时，由于 StarkNet 的系统设计中有很大一部分与零知识证明和 Merkle Tree 相关的资料结构有关，因此也会需要读者大概认识什麽是零知识证明和相对 Merkle Tree，会在阅读过程中顺畅很多！未来有机会也会继续深入各个系统部件做深入讨论。
Author: ChiHaoLu(chihaolu.eth) @ imToken LabsIntro
StarkNet OS（Operating System） 主要由 Cairo 这个 StarkNet 的原生语言写成，Cairo 就像 StarkNet 上的 Solidity，能够用来撰写（Cairo-based）智能合约，但同时也是一个零知识证明语言，可以用于构建 StarkNet 核心的作业系统和各种功能。
所有在 StarkNet 这条链上的逻辑都会被包含在 StarkNet OS 中，例如如何定义帐户状态、交易原理、合约执行，甚至是如何进行位元运算、杂凑运算和原生的签章演算法等，都会定义在这裡。
概括来说，OS 需要在交易与合约接收 input 之后产出 output，并且将这个 output 更新在 StarkNet 这个 L2 的状态（State）中。
那为什麽要使用零知识证明语言来撰写 StarkNet OS 呢，而不是其他常见语言？
相信大家都知道扩容的其中一个大方向就是“把繁杂的计算丢到 Off-Chain 并且只要在 On-Chain 做验证即可”，而 StarkNet 作为 ZK-Rollups 一员，他会将 Cairo 撰写的 ZK-STARK Program 执行完的内容透过 STARK-proof system 进行证明（prove）与在 Ethereum 进行验证（verify）。
如果看到这裡还不是非常了解也没关係，接下来几个小节会依序补完这些名词解释跟使用场景！
StarkNet Stack
StarkNet 的系统架构我认为有三个重点，Sequencer、Prover & Verifier 和 L1 Core Contract。另外还有原生 AA 设计的 User Account、Full Node、Fact Register 等部件，但这篇文我们先著重在前三个重点的概括介绍上。
StarkNet System Overview
StarkNet Sequencer
StarkNet 作为一个 Rollups 没有类似过往我们认识的矿工角色存在，但依旧需要一个角色来 “验证交易”、“决定交易顺序”、“构建区块”，而负责这三者工作内容的人就是 Sequencer。
Sequencer 是一个 off-chain server，工作流程的第一步是接收用户送上来的交易（数笔来自不同用户的不同交易），之后 Sequencer 会决定交易顺序并且构建 L2 的区块。
Sequencer 需要确认交易是被帐户拥有者授权的（由于 StarkNet 使用了原生 AA 的帐户系统，因此这裡不一定是单纯确认签章正确，有可能是多签或其他验证逻辑）。接著透过 StarkNet OS 执行一次交易，概念上就像 EVM 一样，接收 input 后执行合约逻辑并产出 output。
Sequencer 执行过交易这件事情会生产出一个 trace（需要注意这个 trace 不是 function return 而是一个执行过程的见证），并将这些执行内容的 “过程见证” 送去给 Prover 让其生产证明。也就是告诉大家：“我执行过这段程式码囉。”。
在我们接下来要讲的 Prover 和 Verifier 验证成功之后，Sequencer 会更新 L1 StarkNet Core Contract 中的状态。
StarkNet Prover & Verifier
Prover 同样也是一个 Off-Chain Server，这个角色主要就是接收 Sequencer 执行完程式码产生的 trace，并且生产出相对应的 STARK proofs，然后交给在 L1 上的 Verifier Contract 验证，验证通过之后会注册 fact 供未来的 L1 StarkNet Core Contract 进行查询。
Image Source: Starkience Tweets
Verifier Contract 会在 L1 上负责验证以上一切是否是合法的，他会接受 input 以及 STARK Proof 来决定。
补充说明：目前 StarkNet 中只有一个 Prover，不仅为 StarkNet 生成证明，还为运行在 StarkWare 自己的 StarkEx rollup 上的所有其他应用程序（例如 Immutable X、dYdX、Sorare 等）生成证明。这就是为什麽该服务被称为 Shared Prover 或 SHARP 的原因。StarkNet L1 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 在 L1 有一些 operations 需要定义，也会定义在 StarkNet L1 Core Contract 中，例如：
官方认可的 Verifiers Contract（Addresses List）
L1 ↔ L2 互动的逻辑（讯息传递的方式）
Discussions
Decentralization & Open Source
Rollups 中的 Sequencer 或像是 Prover 这样的角色被该链的官方把持著其实会引来社群的质疑，因此对长远发展来说其实开源是非常重要的。不仅仅是有更多双眼睛可以审视这个 code，也可以因为社群的协作和贡献让系统更安全、有效率。退一万步来说，社群还能够独立地开发并维护整个网路。
所谓的去中心化在 StarkNet 社群有两个主要讨论层面：
不需许可就能运作的 Sequencers 和 Provers 可以确保这个网路是抗审查的（censorship-resistant）。
因为使用了 STARK-proofs，任何人都可以用很低的硬体成本来验证整条链的正确性，同时也不需要信任任何第三方单位。
当前 StarkNet 已经开源了最新的 Sequencer，Prover 也即将开源，有兴趣的人可以查看以下资源：
- StarkNet Decentralized Protocol III — Consensus
- Open-Source: StarkNet’s New Sequencer
- Open-Sourcing the StarkNet Prover
StarkNet 运作的效能和 Gas Fee 在这几个月我自己用下来，其实没有非常好（有时候甚至到差或完全不能用的地步），但 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 没用。原因是如果区块大小太大，我们对全节点的要求就越高（这样他们才可以跟上链的增长速度并且进行验证）。如果这个要求高到大部分用户都没办法负担，无法自行验证，那就使得绝大部份人都需要以一个不信任的方式参与网路。Closing
撰写 StarkNet 的介绍文时需要不少的 Reference，我尽量把所有参考到的内容都附上（文中或文末），希望能给愿意深入了解的人们提供帮助，也非常感谢这麽多善心人士愿意分享自己对 StarkNet 的研究结果！
Special thanks to NIC Lin for reviewing this post.
