Astro launched the first Chinese Cairo Bootcamp on May 21st. The event aims to help more Chinese developers quickly master the Cairo language and build products on Starknet. This Bootcamp consisted of five sessions. With an overwhelming response, the Bootcamp witnessed more than 200 registrations and an impressive 140+ cumulative participants, averaging over 28 attendees per session.

The topics covered in this session include:

• Introduction to Starknet and Cairo

• Development environment setup

• Deployment of ERC20 and ERC721 tokens on testnet

• Cairo 2.0 syntax

Cryptonerd、Shalom、Max participated in the explanations.

Each class is recorded, and we will upload all the course videos to YouTube soon. Here are the tutorials and related documents we have prepared:

Course documents: https://starknetastro.xlog.app/

Course slides PDF and video replays: https://starknet-astro.super.site/

The first Cairo Bootcamp organized by Astro has come to an end.

On August 3rd, Starknet Astro invited @StarkWareLtd developer Gyanlakshmi to answer questions encountered by Chinese developers in Cairo development 🚀

The Q&A list doc

https://docs.google.com/document/d/1ku_y4M9PUe_GcwiBlvq6Kz2LkagyXD2Za1XCZj-IHVo/mobilebasic

Cairo-Book Chinese Version

On May 31st, Astro completed the Chinese translation of the Cairo Book and maintained it with regular updates, ensuring that the Chinese version of the Cairo Book can stays synchronized with official updates in time.

Our work records(PR).

And Astro has integrated WASM-Cairo into CairoBook, so we can run Cairo code in the browser. If you also want to build Cairo programs that can run in the browser, please contact us.

https://twitter.com/cryptonerdcn/status/1681702635479638016

At the same time, the WASM-Cairo project won awards at both the Starknet Hackathon hosted by Pragma and the Eth Shanghai Hackathon.

China's First Starknet Workshop in Shanghai

On June 23-24, we held China's first Starknet Workshop in Shanghai to help developers quickly understand the Starknet technology stack and learn advanced content such as Cairo syntax, STARK proof generation, zkEVM, and sequencers.

Surprisingly, besides developers, there were also many Starknet project teams(including four full-chain game teams interested in Starknet) and investors present at the scene. The attendees exceeded 50 people for two consecutive days, and even heavy rain on the second day could not extinguish everyone's enthusiasm for Starknet.🔥

At the workshop, we introduced the online Cairo code editor: Astro Editor.

Advocate Works

Astro insists on promoting the entrepreneurial opportunities of the Cairo language and full-chain games, on-chain AI, contract wallets, and account abstractions on Starknet to individual developers, teams, and startups. Astro already helped some wallet, game, and NFT startups joined the Starknet ecosystem, and in the future, more Chinese development teams will land on Starknet. 🚀

On June 3rd, Type V DAO hosted a Twitter Space with Astro to talk about Starknet and L2.

https://twitter.com/TypeV_Official/status/1664549188858945538

On July 13th, Astro held a Twitter Space after the Starknet mainnet upgraded to version v0.12, where many Starknet developers and enthusiasts gathered to discuss the Starknet ecosystem.

On July 15th, Astro researcher CynicSong completed a research article titled "The EVM-Compatible Journey of Starknet: Kakarot zkEVM 101" to introduce Kakarot to Chinese readers.

Special thanks to Kakarot CEO Elias and the team for their suggestions and support on this article.

Kakarot is a zkEVM implemented on Starknet using the Cairo language. It simulates the EVM's stack, memory, execution, and other aspects as Cairo smart contracts. Kakarot faces challenges related to compatibility with Starknet's account system, cost optimization, and stability due to the experimental nature of the Cairo language.

Warp is a translator that converts Solidity code into Cairo code, providing compatibility at the high-level language level. Kakarot, on the other hand, provides compatibility at the EVM level by implementing EVM opcodes and precompiles.

https://twitter.com/StarkNetAstroCN/status/1680195400417054720?t=LlqCQ_6LaPVkzj-0TRPasw&s=19

On July 21st, Astro's Dev Rel & Researcher Max preached about the Starknet technology stack and ecosystem progress to the developer community LXDAO, which focuses on public goods development. The explanation was mainly based on the Chinese knowledge base completed by Astro.

https://starknet-astro.super.site/

Future Plans

Astro will hold the Starknet Hacker House in Chengdu from August 21st to 27th. Students will engage in a one-week development and learning program in the learning environment provided by Astro, and are encouraged to build their own Cairo projects during this period. Astro will provide further updates on the specific details and other information in upcoming event articles.

This Starknet Hacker House is part of Global Hacker House, and multiple developer communities will be hosting Hacker House events in various cities in China in August.

Registration link: 🔗

https://antalphalabs.typeform.com/hackerhouse

Astro will also launch the second phase of BootCamp in the second half of the year, which will include advanced topics such as account abstraction, full-chain games, STARK prover, and sequencer in Cairo.

本文将带大家回顾 Astro 在 2023 年 5-7 月期间取得的成绩，并展望下一步的计划。

欢迎大家为 Astro 的建设提出建议或意见 💡

第一期 Cairo Bootcamp

Astro 在 5/21-7/16 期间举办了首届中文 Cairo Bootcamp ，本次 Bootcamp 旨在帮助更多中文开发者快速掌握 Cairo 语言并在 Starknet 上构建产品。本次 Bootcamp 共开展了五节课，报名数超过 200 人，累计参与人次超过 140，平均每次课程参与人数超过 28。

本期课程内容包括

• Starknet 和 Cairo 介绍

• 开发环境设置

• 在测试网部署 ERC20 和 ERC721 代币

• Cairo 2.0 语法

Cryptonerd、Shalom、Max 参与了讲解。

每次课程都有录制，我们将在不久后将全部课程视频上传到 YouTube，以下是我们编写的教程以及相关文档：

课程文档：https://starknetastro.xlog.app/

课件 PDF 及课程视频回放 https://starknet-astro.super.site/

Cairo-Book 中文版

5 月 31 日 Astro 完成了 Cairo Book 的中文翻译，并保持了平均每周更新一次的水平，保证了中文版 Cairo Book 能即时跟进官方的更新：

工作记录：

https://github.com/cairo-book/cairo-book.github.io/pulls?q=is%3Apr+is%3Aclosed+author%3Acryptonerdcn

并且 Astro 在 CairoBook 中集成了 WASM-Cairo，可以直接在浏览器中运行 Cairo 代码，如果你也希望构建可以在浏览器运行的 Cairo 程序，可以通过 Astro 推特联系我们。

同时 WASM-Cairo 项目分别在 Pragma 举办的 Starknet 黑客松和 Eth Shanghai 黑客松都获奖。

中国首届 Starknet Workshop in Shanghai

6 月 23-24 日我们在上海举办了中国首届 Starknet Workshop，CryptoNerd、Ben、Xiang、Max 四位讲师在现场帮助开发者快速了解 Starknet 技术堆栈，学习 Cairo 语法、STARK 证明生成、zkEVM 和排序器等 Cairo 开发高级内容。

这是第一天 Workshop 现场情况🔥

出人意料的是，除了开发者之外，也有很多 Starknet 项目团队和投资人来到现场，现场有 Starknet 四个全链游戏团队。连续两天的到场人数超过 50 人，第二天尽管有暴雨也不能浇灭大家对 Starknet 的热情🔥

在会上我们介绍了我们开发的在线 Cairo 代码编辑器：Astro Editor

布道工作

Astro 坚持向个人开发者以及开发团队布道 Cairo 语言以及 Starknet 上全链游戏、链上 AI、合约钱包&账户抽象的创业机会。 Astro 也正在帮助三个钱包、游戏、NFT 团队进入 Starknet 生态，在未来将有更多中国开发团队登陆 Starknet 🚀

6 月 2 日，Type V dao 与 Astro 的共同举办了 Starknet 主题的 Twitter Space，我们在本次 Space 中介绍和分享了 Starknet 技术堆栈、生态进展以及和其他 L2 之间的差异。

7 月 13 日 Astro 在 Starknet 主网升级到 v0.12 版本后举办了以 Starknet 主网升级为主题的 Twitter Space，和众多 Starknet 开发者、爱好者以及 Astro 社区成员共同讨论 Starknet。

7 月 15 日，Astro 研究员 @CynicSong 完成了对 Kakarot 的研究文章《Starknet的 EVM 兼容之路：Kakarot zkEVM 101》，向中文读者介绍了 Kakarot。

特别感谢 Kakarot 创始人 Elias 及团队对本文的指导和支持。

Kakarot 是使用 Cairo 语言在 Starknet 上实现的zkEVM。它以 Cairo 智能合约的形式模拟了 EVM 的堆栈、内存、执行和其他方面。Kakarot 面临与 Starknet 帐户系统的兼容性、成本优化和稳定性等挑战，因为 Cairo 语言尚处于实验阶段。

Warp 是将 Solidity 代码转换为 Cairo 代码的转换器，在高级语言级别提供兼容性。另一方面，Kakarot 通过实现 EVM 的操作码和预编译，提供了在 EVM 级别的兼容性。

7 月 21 日，Astro 的 Dev Rel & 研究员 Max，向专注于公共物品的开发者社区 LXDAO 布道了 Starknet 技术堆栈与生态进展，主要基于 Astro 完成的 Starknet 中文知识库讲解。

未来计划

Astro 将于 8 月 21-27 日在成都举办 Starknet Hacker House，学员们将在 Astro 提供的学习环境里进行为期一周的开发学习，鼓励在此期间内构建自己的 Cairo 项目。具体内容和其他信息 Astro 将在接下来的活动文章中更新。

本次 Starknet Hacker House 是 Global Hacker House 的一部分，本次 Starknet Hacker House 是 Global Hacker House 的一部分，多个开发者社区将于八月份陆续在中国各城市开展 Hacker House。

报名链接 🔗

https://antalphalabs.typeform.com/hackerhouse

Astro 也将在未来开展第二期线上 Cairo BootCamp，它将包含账户抽象、全链游戏、STARK 证明器、排序器等 Cairo 高级开发课程。

• 虚拟机是一个软件仿真的计算机系统，为程序提供执行环境。它可以模拟各种硬件设备，使程序在受控且兼容的环境中运行。以太坊虚拟机（EVM）是一种基于栈的虚拟机，用于执行以太坊智能合约。

• zkEVM是一种集成了零知识证明/有效性证明技术的EVM。它允许使用零知识证明验证EVM的执行过程，而无需所有验证者重新执行EVM。市场上有各种zkEVM产品，每个产品都有自己的方法和设计。

• 需要zkEVM的原因在于对在Layer 2上支持智能合约执行的虚拟机的需求。此外，一些项目选择使用zkEVM来利用EVM的广泛用户生态系统，并设计更友好于零知识证明的指令集。

• Kakarot是使用Cairo语言在Starknet上实现的zkEVM。它以Cairo智能合约的形式模拟了EVM的堆栈、内存、执行和其他方面。Kakarot面临与Starknet帐户系统的兼容性、成本优化和稳定性等挑战，因为Cairo语言尚处于实验阶段。

• Warp是将Solidity代码转换为Cairo代码的转换器，在高级语言级别提供兼容性。另一方面，Kakarot通过实现EVM的操作码和预编译，提供了在EVM级别的兼容性。

什么是虚拟机？

要讲清楚什么是虚拟机，必须先讲当今主流的冯诺依曼架构下的计算机执行流程。运行在计算机上的种种程序，通常是由高级语言经过层层转化，最终生成机器可理解的机器码完成执行的。根据转化为机器码的方式不同，高级语言可以大致分为编译型语言与解释型语言。

编译型语言是指在代码的编写完成后，需要经过编译器的处理，将高级语言代码转换成机器码，生成可执行文件。一次编译就可以多次以较高效率执行。编译型语言的优点是因为在编译时已经将代码转换为机器码，因此执行速度快，并且可以在没有编译器的环境下运行程序，便于用户使用，不需要安装额外的软件。常见的编译型语言包括C，C++，Go等。

与编译型语言相对应的是解释型语言。解释型语言是指代码通过解释器逐行解释执行，直接运行在计算机上，每次运行都要重新进行翻译过程。解释型语言的优点是开发效率高，代码易于调试，但执行速度相对较慢。常见的解释型语言包括Python，JavaScript，Ruby等。

需要强调，语言从本质上并不区分编译型和解释型，只是在最初设计时会有一些倾向。C/C++绝大多数情况下是编译执行，但是也可以解释执行（Cint、Cling）。很多传统意义上的解释型语言，现在是编译成中间代码在虚拟机上执行（Python、Lua）。

知道了物理机的执行流程，现在来讲虚拟机。

虚拟机通常通过模拟不同的硬件设备来提供一个虚拟的计算机环境。不同的虚拟机可以模拟的硬件设备有所不同，但通常包括CPU、内存、硬盘、网络接口等。

以以太坊虚拟机EVM为例，EVM是一种基于堆栈的虚拟机，它被用于执行以太坊智能合约。EVM通过模拟CPU、内存、存储器和栈等硬件设备来提供一个虚拟的计算机环境。

具体来说，EVM是一种基于堆栈的虚拟机，它使用堆栈来存储数据和执行指令。EVM的指令集包括各种操作码，例如算术操作、逻辑操作、存储操作、跳转操作等，这些指令可以在EVM的堆栈上执行，从而完成智能合约的执行。

EVM模拟的内存和存储器是用于存储智能合约的状态和数据的设备。EVM将内存和存储器视为两个不同的区域，它可以通过读取和写入内存和存储器来访问智能合约的状态和数据。

EVM模拟的栈用于存储指令的操作数和结果。EVM的指令集中的大多数指令都是基于堆栈的，它们从栈中读取操作数并将结果推回栈中。

总之，EVM通过模拟CPU、内存、存储器和栈等硬件设备来提供一个虚拟的计算机环境，它可以执行智能合约的指令并存储智能合约的状态和数据。在实际运行中，EVM会将智能合约的字节码加载到内存中，并通过执行指令集来执行智能合约的逻辑。EVM实际取代的是上图中操作系统+硬件的部分。

EVM的设计过程，显然是自下而上的，先敲定了模拟的硬件环境（堆栈、内存），再根据对应的环境设计了自己的一套汇编指令集（Opcode）与字节码（Bytecode）。尽管汇编指令集是给人看的，但是涉及到很多底层知识，对开发者的要求较高，开发起来也较繁琐，所以需要高级语言，屏蔽晦涩繁琐的底层调用，为开发者提供更好的体验。EVM由于其汇编指令集的的定制化设计，很难直接利用传统的高级语言，索性重新一个新的高级语言以适配该虚拟机。以太坊社区为了EVM执行效率设计了两种编译型的高级语言——Solidity和Vyper。Solidity自不必强调，Vyper是Vitalik针对Solidity中存在的部分缺陷进行改进后设计的EVM高级语言，但是在社区没有获得很高的采用度，于是渐渐淡出历史舞台。

什么是zkEVM

简单来讲，zkEVM就是运用零知识证明/有效性证明技术的EVM，让EVM的执行过程，可以通过零知识证明/有效性证明来更高效、低成本地验证，而不需要所有验证者都重新进行EVM的执行过程。

市场上的zkEVM产品众多，赛道火热，主要玩家包括Starknet, zkSync, Scroll, Taiko, Linea, Polygon zkEVM（原Polygon Hermez） 等，被vitalik分为了5类（1、2、2.5、3、4）。具体的内容可以查看Vitalik的博客。

https://vitalik.ca/general/2022/08/04/zkevm.html

为什么需要zkEVM

这个问题需要从两方面来看。

最初的zk Rollup尝试，都只能实现较为简单的转账、交易功能，例如zkSync Lite, Loopring等。但是曾经沧海难为水，用惯了以太坊上图灵完备的EVM，当无法通过编程创造多样的应用时，人们便开始呼唤L2上的虚拟机。撰写智能合约的需求，是为一。

由于EVM中部分设计对于生成零知识证明/有效性证明不友好，部分玩家选择了在底层使用对于零知识证明/有效性证明友好的指令集，例如Starknet的Cairo Assembly和zkSync的Zinc Instruction。但是大家同时也都不愿放弃EVM庞大的用户生态，于是选择在上层兼容EVM，是3、4类zkEVM。还有部分玩家仍然坚持EVM传统指令集Opcode，将精力放在为Opcode生成更高效的证明上，是1、2类zkEVM。EVM的庞大生态，是为二。

Kakarot：虚拟机上的虚拟机？

为什么能够在虚拟机上再做一个虚拟机？这个事情对于计算机从业者而言是司空见惯的，但是对于不了解计算机的用户可能没那么显然。其实很好理解，这就好像搭积木，只要下层足够牢固（有图灵完备的执行环境），就可以无上限地往上层叠加积木。但是不论搭了多少层，最后的执行还是要交给最底层的物理硬件去处理，所以层数增高会导致效率的降低。同时，由于不同积木的设计不同（虚拟机设计不同），随着积木越搭越高，积木倒塌的可能性就越大（运行出错），也就需要更高的技术水平支撑。

Kakarot是在Starknet上用Cairo语言实现的一个EVM，以Cairo智能合约形式去模拟EVM中堆栈、内存、执行等内容。相对而言，实现EVM并不是什么难事，除了使用率最高的Go-Ethereum中用Golang编写的EVM，现存的还有使用Python, Java, JavaScript, Rust编写的EVM。

Kakarot zkEVM的技术难点在于，协议是作为Starknet链上合约存在的，这就带来了两个关键的问题。

1. 兼容性 Starknet使用的是和以太坊完全不同的账户体系，以太坊中账户分为EOA（外部拥有账户）和CA（合约账户），然而Starknet中支持原生的账户抽象，所有账户都是合约账户。同时，由于使用的密码学算法不同，用户无法使用同一个熵在Starknet中生成与以太坊相同的地址。

2. 成本 由于kakarot zkEVM是作为合约存在于链上的，所以对于代码实现有着较高的要求，需要尽可能地面向Gas进行优化，降低交互成本。

3. 稳定性 与使用Golang, Rust, Python等传统高级语言不同，Cairo语言仍然处于试验阶段，从Cairo 0到Cairo 1再到Cairo 2（或者如果你喜欢的话，Cairo 1 version 2），官方团队仍然在不断修改语言特性。同时，Cairo VM还未得到足够的测试，不排除后续大规模重写的可能。

kakarot协议由五个主要的组件组成（GitHub文档中写的是四个，未包含EOA，本文为了便于读者理解做了调整）：

• Kakarot (Core)：负责执行以太坊形式的交易，同时为以太坊用户提供对应的Starknet账户

• Contract Accounts：以太坊意义上的CA，负责存储合约的字节码、合约中变量状态

• Externally Owned Accounts：以太坊意义上的EOA，负责将以太坊交易转发给Kakarot Core

• Account Registry: 存储以太坊账户和Starknet账户的对应关系。

• Blockhash Registry：Blockhash作为一个特殊的Opcode，需要过去的区块数据，而Kakarot无法在链上直接获取到数据。该组件存储block_number -> block_hash的映射关系，由管理员写入，提供给Kakarot Core。

据kakarot CEO Elias Tazartes反馈，在团队的最新版本中，放弃了Account Resister的设计，改为直接使用一个31bytes的Starknet地址到20位EVM地址的mapping来保存对应关系。在未来，为了提高互操作性以及允许Starknet合约注册自己的EVM地址，可能会重新使用Account Register的设计。

Starknet上兼容EVM：Warp与kakarot有什么差异

按照Vitalik定义的zkEVM类型而言，Warp属于Type-4，而kakarot当前属于Type-2.5。

Warp是一个将Solidity代码转化为Cairo代码的转译器，之所以不叫编译器，大概是因为输出的Cairo仍是高级语言。通过Warp，Solidity开发者可以维持原先的开发状态，而不需要学习新的Cairo语言。对于很多项目方而言，Warp降低了进入Starknet生态的门槛，不需要使用Cairo重写大量的工程代码。

转译的思想虽然简单，但是兼容性也是最差的，有部分Solidity代码无法很好地翻译为Cairo，涉及到账户体系、密码算法等代码逻辑需要修改源代码才能完成迁移，具体的不支持特征可见Warp文档。例如，许多项目会对EOA账户与合约账户的执行逻辑进行区分，但是Starknet中所有账户都是合约账户，这部分的代码就需要修改后才能进行转译。

Warp是在高级语言层面的兼容，kakarot是在EVM层面的兼容。

EVM的全部重写，Opcode与Pre-compile的逐条实现，让kakarot拥有了更高原生的兼容性。毕竟，在相同的虚拟机（EVM）中执行，总是要比在不同的虚拟机（Cairo VM）中执行来得更兼容一些。Account Registry、Blockhash Registry更是巧妙地屏蔽了不同体系下的差异，把对用户的迁移摩擦降到最小。

Kakarot 团队

感谢kakarot团队对本文提出的宝贵意见，特别是Elias Tazartes。Thank you, sir!

本次 Cairo Bootcamp 是一个短期、知识密集的培训项目，旨在帮助有编程经验的个人掌握 Cairo 编程语言，Cairo 是一种用于编写可证明程序的编程语言，目前 Starknet 将 Cairo 语言用于其基础设施和编写 Starknet 合约。

在本次培训中我们将专注于代码实践，旨在使学员迅速沉浸在编码环境中，以培养更多具有独立开发能力的 Cairo 开发者。我们将邀请研究员与开发者以网络直播的形式讲解 Cairo 语言的基础理论和代码实践。完成课时还可获得专属 NFT 结课证明 😎

一、课程规划

课程时长：六周

课程安排：共计六个课时，每周末一课，持续 90 分钟。每周中安排直播答疑。

实践开发：在 Starknet 独立部署 ERC-20 或 ERC-721

直播形式：腾讯会议

学员要求：具备编程基础

二、课程大纲

第一课：介绍 Starknet&Cairo 并部署开发环境

第二课：Cairo 语言介绍

第三课：在 Starknet 上发布 ERC20 代币（上）

第四课：在 Starknet 上发布 ERC20 代币（下）

第五课：在 Starknet 上发布 ERC721 代币（上）

第六课：在 Starknet 上发布 ERC721 代币（下）

第一课将于北京时间 2023 年 5 月 21 日（周日） 20：00-21：30 开始，直播课将会持续 90 分钟，讲30分钟，提问 10 分钟，休息 10 分钟，讲 30 分钟，提问 10 分钟。我们将在课前和课后向学员提供相关教程文档。

三、报名方式

点击报名表链接进行报名。

并添加小助手微信进入 Cairo 学习群

四、官方支持

本届中文 Cairo Bootcamp 受到 Starknet 支持。Starknet 是去中心化的 Validity-Rollup（通常称为 ZK-Rollup）。它作为以太坊上的 L2 网络运行，使任何应用程序都能实现大规模扩展，而不会影响以太坊的可组合性和安全性。

五、合作社区

Antalpha Labs 是一个非盈利的 Web3 开发者社区，致力于通过发起和支持开源软件推动 Web3 技术的创新和应用。

BeWater 是一个服务于 buidler / builder 的开放创新平台。

BuidlerDAO 是一个 web3 项目和人才网络。聚集投研、技术、运营等领域的 Web3 实干家，以 DAO 的方式组织内容输出和产品实践，建立 Web3 人才网络和项目加速器。

Dapp Learning 是一个专注于以太坊开发的线上开源开发者社区。

登链是一个由一群区块链技术爱好者维护、秉承去中心化理念的区块链技术社区。

以太坊中文社区(ECN)是以太坊区块链的中文社区，致力于提供优质的以太坊前沿技术资讯、促进以太坊爱好者的分享交流、用心连接中国社区和国际社区。

Reddio 是一家专注 StarkWare 生态的基础设施公司，基于 StarkEx 提供简单易用、面向 Web2 开发者的 0 gas, 10k TPS 以太坊 App/Game Chain，同时为 Starknet 提供自动化开发工具，并将提供 0 gas 的 L3 部署方案

活动时间：从4月25日下午2点（UTC）到5月25日下午2点（UTC）

步骤：

1. 注册和准备：

   • 访问官方网站或点击链接：https://seance.ninth.gg/。

   • 进行注册并创建账户。

2. 游戏规则：

   • 在"Seance"游戏中，您需要选择使用的代币，这里提供了$USDT和$NOAH两个选项。

   • 进入一个房间并选择两个数字（0-9），以消耗20个$NOAH或$USDT完成祈祷。每个房间最多可容纳5名玩家。

   • 在所有玩家完成祈祷后，将产生获胜者。游戏将通过随机数预言机获得链下的随机数，并根据随机数的最后一位选择失败者。

   • 前4名获胜者将每人获得25个$NOAH或$USDT。

   • 失败者将失去所有投入的代币，但可获得积分（$NOAH区域为3分，$USDT区域为1分）。如果玩家在$USDT区域，还将额外获得30个$NOAH。

   • 请注意，活动结束后，游戏仍将继续开放，但只有在活动期间，失败者才能获得$NOAH作为奖励。

1. $NOAH代币和奖励的获取：

   • $NOAH是"The Ninth"的游戏内资产，可在"The Ninth"的所有游戏中获取和使用。

   • 在当前阶段，您只能通过参与"Seance"游戏来收集$NOAH。

2. 奖励：

   • 活动期间，将开设积分排行榜：前20名的参与者将获得各种"The Ninth: Acsendance"奖励，以及$USDT和$NOAH奖励。

   • 第1名：城市通行证NFT1，NFT神秘盒5，500美元USDT，5,000个$NOAH。

   • 第2名：NFT神秘盒*3，200美元USDT，3,000个$NOAH。

   • 第3名：NFT神秘盒*2，100美元USDT，2,000个$NOAH。

   • 第4-10名：NFT神秘盒*1，1,000

Cairo 是一个图灵完备的 ZK 友好高级语言，也是以太坊 L2-Starknet 的合约开发语言，它正在进行改版升级。本篇文章是分析 Cairo 1.0 系列文章的第一篇，作者 Mathieu 分析了 Sierra 作为 Cairo 高级语言到 Cairo 汇编的中间层的设计动机与实现原理。文中提到了大量 Cairo 0 存在问题、Cairo 1 改进之处，并附有丰富的代码细节，推荐 Cairo 开发者阅读全文以深入了解 Cairo 1.0。

原文链接

TL;DR

Sierra 在高级 Cairo 编程语言与更原始的编译目标（如 CASM）之间担任了重要的中间人角色，确保生成的 CASM 可在 Starknet 上安全运行。它的设计以安全为中心，使用一组函数来生成安全的 CASM 代码，结合强大的编译器和线性类型系统来防止运行时错误，以及内置 Gas 系统来防止无限循环。 在接下来的部分，我们将专注于理解 Sierra 程序的结构，提供了阅读和理解 Sierra 程序所需的基本要求。

简介

我（Mathieu）最近参加了 Starkware Sessions 的两场会议，分别是 Shahar Papini 的“Enforcing Safety Using Typesystems”和 Ori Ziv 的“Not Stopping at the Halting Problem”。如果你想了解更多有关 Cairo 堆栈的信息，我强烈建议你观看这些视频。以下文章是一个系列的第一篇，我将深入了解 Sierra 以更好地理解 Cairo、其机制以及整个Starknet。

Sierra（Safe Intermediate Representation 安全中间表示）是高级语言 Cairo 和诸如 Cairo Assembly（CASM）之类的编译目标之间的中间层。该语言旨在确保安全并防止运行时错误。它使用编译器检测可能在编译时失败的操作，以确保每个函数都返回并且没有无限循环。Sierra 使用简单但强大的类型系统来表达中间层代码，同时确保安全性。这使得可以有效地编译成 CASM。

动机

在 Cairo 0 中，开发人员会使用 Cairo 编写 Starknet 合约，将其编译为 CASM，并直接部署编译输出到 Starknet 上。用户可以通过调用智能合约函数、签署交易并将其发送给排序器来与 Starknet 合约交互。排序器将运行交易以获取用户的交易费用，证明者（SHARP）将为包括此交易的批次生成 ZK 证明，排序器将收取包括交易在内的交易费用。

然而，该 Cairo 0流程会产生一些问题：

• 在 Cairo 中只有有效的语句才能被证明，所以无法证明失败的交易。无法证明无效的语句，例如 assert 0 = 1，因为它转换为无法满足的多项式约束。

• 交易执行可能会失败，导致交易未被包括在块中。在这种情况下，排序器会做无偿的工作。由于失败的交易没有有效的证明，它们不能被包括在内，也没有办法强制排序器收费。

• 排序器可能被 DDoS攻击，攻击者使用无效交易使其白干一场，而排序器无法收取运行这些交易的任何费用。

• 无法区分审查制度 censorship（当排序器故意决定不包括某些交易）和无效交易，因为这两种类型的交易都不会被包括在块中。

在以太坊上，所有失败的交易都被标记为 reverted，但仍包括在块中，允许验证者在失败时收取交易费用。为了防止恶意用户用无效交易轰击网络并使排序器不堪重负，从而使合法交易无法处理，Starknet 需要一个类似的系统，允许排序器收取失败交易的费用。为了解决上述问题，Starknet 网络需要实现两个目标：完整性和有效性。完整性确保交易执行始终可以被证明，即使它预计会失败。有效性确保不会拒绝有效交易，从而防止审查制度。

Sierra 是构造正确的（Correct-by-constrction），让排序器为所有交易收费。我们可以部署分支代码（例如if/else），而不是可能失败的代码（例如asserts）。Cairo 1 的 asserts 被翻译成分支 Sierra 代码，允许错误传播回返回布尔值的原始入口点，表示交易成功或失败。如果入口点返回值为 true/false，则 Starknet 操作系统可以确定交易是否有效，并决定是否应用状态更新，如果交易成功。

Cairo 1 提供类似于 Rust 的语法，并通过抽象 Sierra 的安全构造来创建可证明的、开发人员友好的编程语言。它编译为 Sierra，这是 Cairo 代码的构造正确的中间表示，不包含任何失败语义。这确保了没有 Sierra 代码会失败，并且它最终编译为 CASM 的安全子集。开发人员可以专注于编写高效的智能合约，而不必担心编写非失败的代码，所有这些都具有改进的安全原语。

开发人员将会将他们的 Cairo 1 代码编译为 Sierra，并将 Sierra 程序部署到 Starknet 上，而不是将 CASM 代码部署到 Starknet 上。在声明交易时，排序器将负责将 Sierra 代码编译为 CASM，以确保不能在 Starknet 上部署失败的代码。

构造正确

为了设计一个不会失败的语言，我们必须首先确定 Cairo 0 中的不安全操作。包括：

• 非法的内存地址引用；尝试访问未分配的内存单元

• 断言（assertions），因为它们可能会失败而无法恢复

• 由于 Cairo 的一次性写入内存模型，导致对同一内存地址的多次写入

• 无限循环，这使得无法确定程序是否会退出

确保解引用不会失败

在 Cairo 0 中，开发人员可以编写以下代码，试图访问未分配的内存单元的内容。

let (ptr:felt*) = alloc();

tempvar x = [ptr];

Sierra 的类型系统通过强制执行严格的所有权规则并利用 Box 等智能指针来防止常见的指针相关错误，从而使得在编译时能够检测和防止无效指针解引用。Box<T> 类型用作指向有效和已初始化指针实例的指针，并提供两个函数进行实例化和解引用：box_new() 和 box_deref()。通过使用类型系统在编译时捕获解引用错误，从而使得从 Sierra 编译的 CASM 避免了无效指针解引用。

确保不会重复写入任何内存单元

在 Cairo 0 中，用户将使用如下数组：

let (array:felt*) = alloc();

assert array[0] = 1;

assert array[1] = 2;

assert array[1] = 3; // fails

然而，尝试两次写入同一数组索引会导致运行时错误，因为内存单元只能被写入一次。为避免这个问题，Sierra 引入了一个 Array<T> 类型以及一个 array_append<T>(Array<T>, value:T) -> Array<T> 函数。该函数接受一个数组实例和一个要附加的值，并返回指向新的下一个空闲内存单元的更新的数组实例。因此，值会按顺序附加到数组的末尾，而不必担心由于已经写入的内存单元可能导致的冲突问题。

为确保已经附加的先前使用的数组实例不会被重复使用，Sierra 使用线性类型系统确保对象仅使用一次。因此，任何已经被附加的 Array 实例不能在另一个 array_append 调用中重复使用。

下面的代码显示了一个 Sierra 程序的片段，该程序创建了一个 felt 数组，并使用 array_append 库函数两次追加值 1。在代码中，第一个 array_append 调用使用 id [0] 的数组变量作为输入，并返回一个表示更新的数组的 id [2] 变量。然后将此变量用作下一个 array_append 调用的输入参数。重要的是要注意，一旦被库函数使用，id [0] 的变量就不能被重复使用，尝试使用 id [0] 作为输入参数调用 array_append 将导致编译错误。

array_new<felt>() -> ([0]);

felt_const<1>() -> ([1]);

store_temp<felt>([1]) -> ([1]);

array_append<felt>([0], [1]) -> ([2]);

felt_const<1>() -> ([4]);

store_temp<felt>([4]) -> ([4]);

array_append<felt>([2], [4]) -> ([5]);

对于可以多次重新使用的对象，比如 felts，Sierra 提供了 dup<T>(T) -> (T,T) 函数，返回两个相同对象的实例，可以用于不同的操作。 这个函数仅适用于安全可复制的类型，通常是不包含数组或字典的类型。

非故障断言

通常使用断言来评估代码中特定点布尔表达式的结果。如果评估结果不符，就会引发错误。与 Cairo 0 中不同，Cairo 1 断言指令的编译将生成分支 Sierra 代码。如果不满足断言，则该代码将提前终止当前函数执行，并继续执行下一条指令。

确保使用字典的程序的健全性

字典和数组一样存在多次添加值的问题，可以通过引入特殊的 Dict<K,V> 类型和一组工具函数来实例化、检索和设置字典中的值来解决这个问题。然而，字典存在一个健全性问题。每个 Dict 都必须在程序结束时调用 dict_squash(Dict<K,V>) -> () 函数来压缩，以验证键更新序列的一致性。未压缩的字典是危险的，因为恶意证明者可以证明不一致更新的正确性。

正如我们之前所见，线性类型系统强制对象只能使用一次。唯一使用“使用”Dict 的方法是调用 dict_squash 函数，该函数使用字典实例并不返回任何内容。这意味着在将 Sierra 代码编译为 CASM 时将检测到未压缩的字典，并在编译时引发错误。对于其他不需要一次性使用的类型，通常是不包含 Dict 的类型， Sierra 引入 drop<T>(T)->() 函数，该函数使用对象的实例并不返回任何内容。

值得注意的是，drop 和 dup 都不会产生任何 CASM 代码。它们仅在 Sierra 层提供类型安全，确保变量仅使用一次。

防止死循环

确定程序最终会停止或永远运行是计算机科学中的一个基本问题，被称为停机问题，在一般情况下是无法解决的。在像 Starknet 这样的分布式环境中，用户可以部署和运行任意代码，因此防止用户运行无限循环代码是很重要的，例如以下 Cairo 代码。

fn foo() { foo() }

由于递归函数如果停止条件永远不满足就可能导致无限循环，因此 Cairo-to-Sierra 编译器将在递归函数开头注入 withdraw_gas方法。由于该功能尚未实现，因此开发人员仍需要在递归函数中调用 withdraw_gas并自行处理结果，尽管在未来版本中应该会包含在编译器中。

该 withdraw_gas 函数将通过计算函数中每条指令的运行成本来从交易总可用 Gas 中扣除运行函数所需的 Gas 数量。成本是通过确定每个操作需要多少步来分析的，大多数操作的步在编译时是已知的。在 Cairo 程序执行期间，如果 withdraw_gas 调用返回 null 或负值，则当前函数执行会停止，所有待处理的变量都将通过对未压缩字典调用 dict_squash 和对其他变量调用 drop 来消耗，并将被认为是执行失败。由于 Starknet 上的所有交易都有一个有限的可用 Gas 量来执行交易，因此避免了无限循环，并通过确保仍有足够的 Gas 可用来删除变量并停止执行，排序器将能够从事务失败中收取费用。

通过一组有限的指令实现安全的CASM

Sierra 的主要目标是确保生成的 CASM 代码不会失败。为实现这一目标，Sierra 程序由调用 libfuncs 的语句组成。这些是一组内置库函数，为这些函数生成的 CASM 代码是保证安全的。例如，array_append 库函数生成的安全 CASM 代码可用于将值附加到数组中。

通过仅允许一组安全和可信赖的库函数来实现代码安全的这种方法类似于 Rust 编程语言的哲学。通过提供一组安全和可信赖的抽象，这两种语言都有助于避免常见的编程错误，并增加代码的安全性和可靠性。Cairo 1 使用了与 Rust 类似的所有权和借用系统，为开发人员提供了一种在编译时推理代码安全性的方式，这有助于防止错误并提高整体代码质量。

免责声明

本文旨在为读者提供通用信息和理解，不表示 Nethermind 支持任何特定资产、项目或团队，也不保证其安全性。Nethermind 没有明示或暗示地向本文中包含的信息或观点的准确性或完整性作出任何陈述或保证。任何第三方不得以任何方式依赖本文，包括但不限于金融、投资、税收、监管、法律或其他建议，或将本文解释为任何形式的建议。 请注意，虽然 Nethermind 为 Starkware 提供服务，但本文不是这些服务的一部分。

关于我们

Nethermind 是一个由世界级建设者和研究者组成的团队。我们为全球企业和开发人员提供访问和构建去中心化 Web 的能力。我们的工作触及 Web3 生态系统的每个部分，从 Nethermind 节点到基础密码学研究和 Starknet 生态系统的基础设施。发现我们的 Starknet 工具套件：Solidity 转 Cairo 编译器 Warp、StarkNet 区块浏览器 Voyager、针对 StarkNet 智能合约的开源形式验证工具 Horus、StarkNet 客户端实现 Juno，以及 Cairo 智能合约安全审计服务。 如果您有兴趣解决一些区块链中最困难的问题，请访问我们的求职信息！

1. How Starknet Works: Compares to Ethereum, Starknet only needs a sequencer to executes calculations off-chain. Then, in order to reduce the amount of data, the prover generates a ZK-STARK proof for the transaction. Finally, verifier verifies the correctness of the proof on-chain, and finally bundles multiple L2 transactions into a single transaction on Ethereum (known as Rollup). Therefore, Starknet reduces the execution and storage cost on the chain, resulting in lower gas fees and higher TPS.

2. EVM-equivalent: Starknet has a ZK-friendly Cairo VM which is different from EVM, which means Starknet does not support EVM and Solidity. But with the introduction of the Solidity compiler Warp and the Cairo zkEVM Kakarot, Starknet can achieve type 3 EVM-equivalent.

3. STARK Proof System: Compared with other ZK proof systems, STARK is safer and more scalable. Its proof generation speed linearly scalable, and verification time and proof size are logarithmically scalable($O(polylog(N))$). The larger the proof, the lower the total cost and verification time. Additionally, STARK relies purely on hashing and information theory, so it has simpler cryptography assumptions, making it resistant to quantum attacks. But it’s disadvantage is that the size of the initial proof generation is large.

4. Cairo VM and Language: The Cairo VM is a STARK-friendly, Turing-complete von-Neumann CPU architecture. It can perform infinitely close to ASIC through software programming. And it has a programming language called Cairo, which is based on Cairo assembly AIR and Sierra. This makes it highly efficient and safe to compile. It is similar to Rust, have a certain learning difficulty. Cairo supports verifiers to verify programs through bytecode hashes, improves on-chain scalability and privacy. But Cairo is still updating.

In another article, we’d show the progress of decentralization of prover, sequencer, full node, client, Cairo, protocol and other Starknet network components.

🛒 How Starknet Works

First of all, let's see how Ethereum works. In Ethereum, verifying the correctness of transactions requires all nodes to check, validate, and execute each transaction. This process ensures the accuracy of the computation and broadcasts the resulting state changes across the network.

But Starknet only executes calculations off-chain and generates a proof, then verifies the correctness of the proof on-chain, and finally bundles multiple L2 transactions into a single transaction on Ethereum. Accurately ZKR will write transactions to Ethereum as calldata, where data that is included in external calls to smart contract functions gets stored(similar to memory).

So Starknet can greatly improve network operation speed, reduce on-chain communication, increase network throughput, and therefore has higher TPS and lower gas compared to Ethereum.

In short, verifying the correctness of a calculation can be compared to a teacher needing to check whether the class has mastered a certain topic.

The Ethereum method is to check that each student (node) if has memorized the entire textbook (state history), while the Starknet method is to administering a paper test. The latter being more efficient and less costly, but still guaranteed to be safe.

As with most ZKRs such as Validity Rollup, Scroll, Polygon zkEVM and zkSync, Starknet has a class of roles called provers to generate proofs. And the verifiers verify the proofs as a contract on L1 (Ethereum).

Specifically, Starknet consists of five components: Prover, Sequencer, and Full Node on Starknet, as well as Verifier and Starknet Core (they are all deployed on Ethereum).

The following figure shows the architecture of Starknet, thanks to David for his great work!

The workflow of Starknet is as follows:

1. When we initiate a transaction on Starknet, an off-chain server—the sequencer—receives, sequences, validates, and bundles them into blocks. Execute the transaction, and then send the state transition to the Starknet Core contract.

2. The prover generates a proof for every transaction and send it to the verifier contract deployed on Ethereum.

3. The verifier sends the result of the validation to the StarkNet Core contract on Ethereum, and triggers a new set of Ethereum transactions from StarkNet Core contract to update the global state on-chain for record keeping. State transition is sent as "calldata" (Blob after EIP-4844) to save L1 transaction gas. These "metadata" can be decrypted by Starknet full nodes.

A full node stores state changes, metadata, proofs, and records all transactions performed in Rollup. It tracks the current global state of the system. Decrypting the "metadata" allows for the reconstruction of Starknet's history when necessary.

🚄EVM-equivalent

The Starknet network itself is not EVM-equivalent and has designed a ZK-friendly Cairo VM.

Instead of making circuits for the Ethernet opcode, Starknet has made its own set of assembly language, AIR (Algebraic Intermediate Representation), and high-level language Cairo that are more ZK-friendly.

The disadvantage of not being equivalent with EVM is that it cannot inherit the Ethereum’s Solidity code and toolchain, so there is no basis for large-scale migration of the Ethereum application ecosystem to Starknet. The Cairo language has a certain learning threshold for developers, and the Cairo toolchain and libraries are in their infancy.

However, designing independent VM has its benefits. For instance, Starknet's Cairo VM is more ZK-friendly and executes circuits more efficiently, resulting in higher TPS and lower gas usage in the future (more details to follow). Additionally, abandoning EVM design opens up many possibilities for application innovations that are not possible on Ethereum.

Starknet belongs to the type 4 level EVM-equivalent defined by Vitalik (strictly speaking, Starknet is a zkVM).

Although Starknet “itself” is not EVM-equivalence, Starknet is still equivalent with Ethereum in other ways.

Warp is a Solidity-Cairo translator, now complete, developed by Nethermind. It possible for Warp to transpile Ethereum smart contracts to Starknet Cairo Contracts.

However, there are several features of Solidity that are not yet supported or do not have analogs in Starknet. While some of these features may be introduced in the future, others may not be possible due to fundamental differences between the platforms.

Kakarot is a zkEVM written in Cairo(so it’s a contract), bytecode-equivalent EVM and allow developers run any EVM bytecode program. Ethereum applications can be deployed on Starknet by deploying to Kakarot.

Kakarot is a work in progress and is not yet ready for production.

Starknet's ZK-friendly Cairo VM does not support EVM and Solidity. However, by introducing the Solidity compiler Warp and the Cairo zkEVM Kakarot, it will be possible for Starknet to achieve a type 3 EVM-equivalent.

🧬 STARK Proof System

Currently, there are many different proof systems available for generating and verifying proofs, such as Halo, PLONK, Groth16, Groth09, Marlin, and Plonky2, etc., which all belong to the SNARK proof system. Every proof system has a prover who generates proofs and a verifier who verifies the proofs. Different ZK projects almost use different proof systems. The main proof systems are SNARK and STARK. And Starknet uses STARK.

SNARK stands for Succinct Non-interactive Argument of Knowledge, while STARK stands for Scalable Transparent Argument of Knowledge. STARK is a special and innovative type of SNARK, with "S" changing from Succinct to Scalable and "T" standing for transparent, replacing the non-interactive feature.

STARK has more innovations than SNARK. It does not need to rely on "trusted settings" like SNARKs. It also comes with simpler cryptography assumptions, avoids the need for elliptic curve, pairing, and exponential knowledge assumptions, relies purely on hashing and information theory, and is therefore resistant to quantum attacks. Generally speaking, STARK is more secure than SNARK.

And STARK is more scalable. Proof generation speed is linearly scalable, and verification time and proof size are logarithmically scalable. However, the disadvantage is that the generated proof size is larger. As the size of the proof increases, the cost of verification decreases marginally, meaning that the larger the proof, the lower the average cost.

Proof time scales linearly

Let's take a look at the doc for STARKs. The amount of time spent by the prover scales nearly linearly with the number of hash invocations.

At 80-bit security, STARK takes 1 second to execute for every 12,288 hash invocations, yielding 12,288 invocations per second; while it takes 10 seconds for every 98,304 hash invocations, yielding 9,830 invocations per second. Therefore, we can know the amount of time spent by the prover scales nearly-linearly in the number of hash invocations, as shown in the following figure:

Verifier time and proof size scales logarithmically

As you can see on the left, when the hash invocations is increased from 3,072 to 49,152, the verification time increases from 40 ms to 60 ms. And when the hash invocations increases from 49,152 to 786,432, the verification time only increases from 60 ms to 80 ms. The proof size is the same. Therefore, we can conclude that the more hash invocations, the shorter the average verification time and the smaller the average proof size.

As an example: Verification of the proofs of two programs of 1 million steps

● Total verification cost of each verified separately: $2 log2(T) \approx 794$

● Total verification cost of both verified together: $log2(2T) \approx 438$

Cost reduction of factor 1.8 (or almost 2)

All the experiments, for both the prover and the verifier, were run on the same machine with the following specifications:

1. Operating-System: Linux 5.3.0-51-generic x86 64.

2. CPU: Intel(R) Core(TM) i7-7700K @ 4.20GHz (4 cores, 2 threads per core).

3. RAM: 16GB DDR4 (8GB × 2, Speed: 2667 MHz) While the prover uses multi-threading, in all of the experiments the verifier was restricted to utilize only a single thread.

Recursive Proving

A universal and succinct proof/argument of knowledge system, such as STARKs, can be used to incrementally verify computation. This means that a computation can generate a proof that attests to the correctness of a previous instance of that computation. This concept is known informally as "recursive proof composition" or "recursive STARKs.”

In other words, a recursive STARK prover would generate a proof for a statement saying the state of a system can be moved from a to a+1 because the prover has verified a (recursive) proof attesting to the computational integrity of a and has faithfully executed the computation on the state a, reaching the new state a+1.

In short, you can understand that the recursive proving combines two proofs, a and a+1, into a single proof. As the following figure shows:

In this example, four statements are sent to SHARP (a Verifier) and each statement is proven in parallel. Then, each pair of proofs is validated by a Recursive Verifier statement, which is a Cairo program that verifies a STARK proof, and a proof is generated for each validation. This Recursive Verifier statement confirms that two proofs have been verified to be correct. Next, the two proofs are merged again by another Recursive Verifier statement. This results in one proof that attests to all four original statements. Finally, this proof can be submitted on-chain and verified by a Solidity verifier smart contract.

According to Eli Ben-Sasson, co-founder of StarkWare, the new recursive validity proofs have the potential to rollup to 60 million transactions into a single one on the Ethereum blockchain.

⭐Cairo VM and Cairo Language

The Cairo VM is a STARK-friendly, Turing-complete von-Neumann CPU architecture. It includes a programming language called Cairo, which is based on Cairo assembly and AIR (Algebraic Intermediate Representations), making it highly efficient to compile.

Let's first take a look at Cairo VM. Cairo VM is a parallel state machine that allows transactions to be executed concurrently, significantly increasing TPS. In contrast, EVM is a serial state machine.

Cairo is a smart contract language that can be deployed on or off Starknet. Any Cairo program can generate STARK proofs. Its syntax is similar to Rust.

This a Cairo voting system example:

import json

from starkware.crypto.signature.signature import (
    pedersen_hash, private_to_stark_key, sign)

# Set an identifier that will represent what we're voting for.
# This will appear in the user's signature to distinguish
# between different polls.
POLL_ID = 10018

# Generate key pairs.
priv_keys = []
pub_keys = []

for i in range(10):
    priv_key = 123456 * i + 654321  # See "Safety note" below.
    priv_keys.append(priv_key)

    pub_key = private_to_stark_key(priv_key)
    pub_keys.append(pub_key)

# Generate 3 votes of voters 3, 5, and 8.
votes = []
for (voter_id, vote) in [(3, 0), (5, 1), (8, 0)]:
    r, s = sign(
        msg_hash=pedersen_hash(POLL_ID, vote),
        priv_key=priv_keys[voter_id])
    votes.append({
        'voter_id': voter_id,
        'vote': vote,
        'r': hex(r),
        's': hex(s),
    })

# Write the data (public keys and votes) to a JSON file.
input_data = {
    'public_keys': list(map(hex, pub_keys)),
    'votes': votes,
}

with open('voting_input.json', 'w') as f:
    json.dump(input_data, f, indent=4)
    f.write('\n')

Cairo programs are collections of assembly code, and Cairo developers will write smart contracts in the high-level language Cairo rather than Cairo assembly. When we write a Cairo program, the Cairo compiler will compile the Cairo code into Cairo assembly, and the Cairo assembler will take the assembly code and generate Cairo bytecode (which runs on the Cairo CPU) to be executed in the Cairo VM.

Here are some Cairo's features.

Bootloading: Loading programs from their hash

A program may write the bytecode of another program to memory and then set the Program Counter to point to that memory segment, thus starting the execution of the other program.

One specific use of this idea is “Bootloading from hash”: A program, called “the bootloader” computes and outputs the hash of the bytecode of another program and then starts executing it as above. This way, the verifier only needs to know the hash of the program being executed and not its full bytecode.

This improves both privacy and scalability:

1. Privacy: the verifier can verify the execution of a program without knowing what the computation does.

2. Scalability: assuming the program hash is known to the verifier, the verification time does not depend linearly on the program size, as would be the case if the program – rather than its hash – were given as input to the verifier. Verification time and program size have a logarithmic relationship, as mentioned in the STARK section.

CPU Architecture

Cairo VM is flexible. It can be infinitely close to the performance of AISC through software programming.

Builtins

Developers can debug and use the internal setting function directly to reduce the amount of calculation development needed without converting any code.

The circuit represented by the ASIC chip or the experiment described in the developer's mathematics is equivalent to Cairo's circuit. However, Cairo is still being updated, and the latest version is called Cairo 1.0.

The main addition in Cairo 1.0 is Sierra (Safe Intermediate Representation). It serves as a new intermediate representation layer between Cairo 1.0 and Cairo bytecode. Sierra’s goal is to ensure that every Cairo run — i.e. a Cairo program and its input — can be proven.

Acknowledgement

Special thanks to Cyberight Capital for supporting this article.

Cyberight Capital is an alternative investment institution. We discover the valid potential points of the industry by changing roles and respect for people and technology. Focusing on Humanist, Technology Driven, Independent Thinking.

Reference

[1]Starknet architecture review

https://david-barreto.com/starknets-architecture-review/#more-4602

[2]l2beat_final

https://drive.google.com/file/d/1dhZ5GtSK4sHCNcklGzNHfR-lSzplpD8J/view

[3]ZKPs in Web 3: Now and the Future

https://medium.com/alliancedao/zkps-in-web-3-now-and-the-future-21b459348f29

[4]A Zero-Knowledge Proof: Improving Privacy on a Blockchain

https://www.altoros.com/blog/zero-knowledge-proof-improving-privacy-for-a-blockchain/

[5]The Zero Knowledge Frontier: On SNARKs, STARKs, and Future Applications

https://research.thetie.io/zero-knowledge-starks-snarks/

[6]Cairo White Paper

https://www.cairo-lang.org/cairo-whitepaper/

[7]Demystifying Cairo White Paper — Part I https://medium.com/@pban/demystifying-cairo-white-paper-part-i-b71976ad0108

[8]Demystifying Cairo White Paper — Part II

https://medium.com/@pban/demystifying-cairo-white-paper-part-ii-9f9dc51886e9

[9]Scalable, transparent, and post-quantum secure computational integrity

https://eprint.iacr.org/2018/046.pdf

[10]ethSTARK docs

https://eprint.iacr.org/2021/582.pdf

[11]Recursive STARKs

https://medium.com/starkware/recursive-starks-78f8dd401025

[12]AIR docs

https://arxiv.org/pdf/2109.14534.pdf

• 为什么需要关注链上游戏？（1）在区块链基建创新的背景下，链上游戏可能是下一代杀手级应用的雏形。（2）链上用户增长面临瓶颈，期望链上游戏可以为区块链可持续地带来更多活跃用户。（3）随着区块链扩容提速，区块链的 4G 时代将推动链上复杂应用的创新。新公链、zkEVM/VM、模块化所具备的账户抽象、资产管理、并行处理和 ZK 特性，为低单位收益、高 TPS 的链上复杂应用奠定了基础。

• 链上游戏的现状如何？（1）目前链上游戏处于探索产品形态和验证市场的早期阶段。至今还没有一个可称成熟的链上游戏诞生，大多数链上游戏的可玩性、完成度不尽人意。（2）链上游戏相比传统游戏和 GameFi 仍有创新，如 Dark Forest、Isaac、Treaty 等链上游戏具有去中心、可组合、链上协作、合约化互动的特点。

• 链上游戏可分为移植和原生两个类别。（1）移植类的链上游戏将解锁传统游戏的可能性，模拟经营类游戏由于可组合、异步回合时间以及金融博弈属性相比其他类型的游戏更适合移植成为链上游戏。（2）原生类的链上游戏更有可能带来链上复杂应用的创新。与链上游戏相关的概念还有超结构，自主世界等，它们扩展了链上游戏的想象空间。

• 链上游戏引擎的现状如何？（1）在链上游戏的早期阶段，链上游戏引擎团队往往肩负开创游戏产品的责任，且引擎团队远远少于游戏团队，分别有以太坊上的 MUD 和 Starknet 上的 Dojo。（2）在链上游戏引擎之外，还存在着其他链上游戏基础设施，如游戏公会 Guildly 和游戏商店 Cartridge.gg。

• 为什么 Starknet 是链上游戏军火库？（1）在性能方面，Starknet 理论上能达到 9000 TPS，其 STARK 证明系统能够将 6000 万笔 L2 交易合并为以太坊上的一笔交易，Gas 有望低至 0.001 U。且 STARK 存在网络效应，交易成本会随着交易量的增加而减少，因此 Starknet 适合庞大用量的链上游戏。（2）Starknet 原生账户抽象，合约钱包相比传统钱包更能适应链上游戏交互场景。（3）Starknet 重视原生应用孵化。其开发团队 StarkWare 与 MatchBox、Only Dust、Volt Capital、Mask Network 等合作伙伴举办了多轮黑客松，孵化了大量链上游戏生态。

• 我们认为 Starknet 是链上游戏最重要的生态，我们将在下一篇研究中深入分析 Starknet 技术特性、链上游戏生态以及链上游戏设计与构建。

什么是链上游戏

链上游戏（Fully On-chain Game，也叫完全链上游戏、全链游戏）是指以合约的方式存在于区块链之中的游戏，区别于仅仅将游戏内资产铸造为代币的 GameFi 这类不完全链上游戏，链上游戏的状态存储、逻辑执行也在链上，因此它也具有去中心化、无需许可、可组合的特性。它更倾向于开创全新的游戏机制，而不是仅仅对现有游戏进行渐进式改进或者把道具上链。

那些不完全的链上游戏大多仅仅将游戏中的关键道具铸造为代币并流通于链上，游戏数据的存储与计算则在链下的中心化服务器上，比如 Axie Infinity、StepN，尽管它们已经取得了非常好的成绩，但这些游戏存在着一些显而易见的问题：

1. 玩法和内容有限。

2. 中心化运营，项目方可以更改游戏规则。

3. 以旁氏模型著称，往往被认为是 DeFi 的延续而非新的“游戏类别”。

4. 仅仅是链下游戏的移植，并非链上原生应用。

那么链上游戏能够解决这些问题，并承诺一个更加美好的未来吗？答案是：不。

区块链是一种全新的技术，与其用它来仿制、改造、嫁接旧产品，不如用它做一个原生的、全新的产品。马车时代的马粪问题从未被解决，而是随着汽车时代的到来被消灭了。链上游戏并非为解决 Web2 游戏和不完全链上游戏的旧问题而生，它致力于完全的创新。

19 世纪的马拉火车在今天看来可能有些荒谬，但它是对当时的大众心理、政策法律、道路状况和产品形态的妥协。如今的联盟链和 GameFi 也是新技术对旧生态的妥协，是新时代的马拉火车，但我们都能感觉到它们不可能成为未来。新技术最终会逐渐重塑整个生态，链上游戏可能就是一个不太成熟的开端。

因此，更加重要的问题是：我们为什么需要关注和探索链上游戏？链上游戏处于哪个发展阶段？

为什么需要链上游戏？

【I don't know what this thing will be worth in the future, but it's new, so let's do it first.】

——Max, founder of Astro Aerospace Industries, said

技术演化的必然

链上游戏是技术演化的必然路径。

历史上的每次技术革命往往在若干年后才爆发出一些超级产品。那些推动技术大规模普及的二次创新和发明往往被人们所忽视，但正是这些创新和发明相互推动，才在因缘际合中碰撞出了真正的创新产品。历史上每个号称“从 0 到 1”的创新产品的背后往往都有若干个铺垫的技术。

坦克的背后是石油开采与冶炼、钢材加工、发动机、炸药学，智能手机的背后是操作系统、触摸屏、处理器、传感器，AI 的背后是计算机科学、神经科学、统计学、心理学、哲学。但弄清楚哪些具体的 N 次创新和发明是最终实现大规模采用并改变世界的创新产品是几乎不可能的，因为它们更有可能是一个技术发展路径上的一个分支而非“最终果实”。

因此，目前不成熟的链上游戏可能会随着技术完善而成熟，也有可能变成另一个产品发展路上的中转站。但无论如何它是值得去关注与探索的，它作为链上应用最前沿的探索方向，即使它不是那个最终的杀手应用，也可能是杀手应用强相关的领域——正如历史中的每个创新产品所告诉我们的那样。

区块链需要活跃用户

区块链需要应用创新，以带来更多的活跃用户或者将用户活跃起来。

根据上图，我们可以知道以太坊每日活跃用户数存在瓶颈。我们已经见证了泛 DeFi 生态的爆发，但从旁观者的角度来看，NFT、GameFi 都是 DeFi 的延续。区块链目前缺少能够保证用户持续在链上活跃的、大规模采用的应用，因此游戏成为了区块链行业进一步扩展的目标领域。Axie Infinity 和 StepN 的经验表明，GameFi 不可持续，因此更持久、健康的链上游戏将取代 GameFi，成为下一代链上应用创新的代表。除了行业需求，一些技术极客也想要证明区块链能够实现更有趣、更复杂、更沉浸的应用程序，而不仅仅是数字货币和 DeFi。

链上复杂应用

一方面，对区块链而言，链上游戏是区块链科技树发展的必然路径，并且区块链也需要更大量级的活跃用户。

另一方面，新公链、zkEVM/VM、模块化的最新发展为区块链应用提供了一个更高 TPS 和更低 Gas 的网络环境，并且它们所具备的更加优越的账户抽象、资产管理、并行处理和 ZK 特性也为应用创新奠定了基础。

回顾低 TPS，高 Gas 的以太坊发展历史，那些低 TPS 要求、高单位收益（每笔交易都有高收入，因此对高 Gas 不敏感）的应用率先发展出来，如 DeFi、NFT。在早期，它们往往仅通过发行代币，设计旁氏模型，然后加上“简单”的运营，就能收获大量的财富。

但在一个 TPS 更高，Gas 更低的网络上，允许有更低单位收益（每次交易的收益很低，因此容忍高Gas）和更高 TPS 要求的应用——或称之为链上复杂应用涌现出来。我们可以建立一个坐标系，横轴是 TPS，纵轴是单位收益，将许多应用排上去，我们将会知道在不同的 TPS/单位收益等级都有哪些应用，进而可以大致推理出有哪些应用将在更高性能表现的网络上诞生。

Bas1s Ventures 的 Wonder 认为：一个低单位收益高 TPS 的链上复杂应用类似于在 Web2 游戏里低 ARPPU（每个付费用户的平均收入） 的游戏/应用，需要足够多的用户交易才能不断突破应用的商业模式/代币经济的天花板——就像中国的美团和美国的 EPIC 依赖高频交易量的业务不断地切入其他低频的业务，最终都打造出了自己的商业生态。而足够多的用户交易又需要一个高 TPS 和低 Gas 的网络环境，因此这样的商业生态【较难直接在gas费高且处理速度有限的以太坊】上涌现，而在全新的区块链基础设施中诞生。

回顾历史，3G 转 4G 的网络扩容驱动了移动互联网的应用爆发。当年在进行 4G 部署的过程中，许多人质疑 4G 技术的作用，更快的邮件和更多的博客有什么用？更多的网速有什么用？但随后的智能手机应用爆发消除了这些疑问。

因此，在区块链扩容提速的背景下，链上游戏可能是下一代链上复杂应用的开端，链上游戏的早期探索可能为复杂链上应用的涌现奠定基础。正如 Jacob 所描述的超结构（Hyperstructures）那样，我们有机会通过区块链构建可以比我们自己的生命更长久的文明基础设施，为全世界人类及其后代打造永久可用的、可组合的、公共复用的网络应用。

链上游戏现状

一个为人们所熟悉的链上游戏是 Dark Forest（黑暗森林），它是一款太空征服题材的多人在线链上游戏，dfdao 的成员也在构建自定义的基础设施 Light Forest 以允许任何人使用自定义规则集修改和运行自己的黑暗森林回合，从而创造出像 Dark Forest 竞技场：大奖赛 等的内容。

“黑暗森林的游戏背景是一个加密生成的无限宇宙，在宇宙中包含各种不同类型的行星和空间实体。最受欢迎的黑暗森林游戏模式是长达一周的大混战，数千名玩家、Bot、AI、甚至智能合约，为银河霸权展开面对面的竞争。玩家出生在宇宙中的一个微小母星上，他们必须收获资源，征服附近的星球，并通过联盟、贸易、谈判甚至战争与邻居互动，以扩大他们的帝国。”——《黑暗森林 : 三年全链上游戏的启示录（上）》

黑暗森林不仅完全在链上运行，还利用了 ZK-SNARK 来帮助玩家在参与博弈的同时隐藏个人信息，因此游戏中的许多决策都是在隐藏信息或信息不对称的前提下完成的。

Dark Forest 在日新月异的链上游戏是一个经典的案例，更前沿的案例是 Isaac、Treaty 和 LootRealms。

Isaac 由 Starknet 上的 Topology 团队开发，它是一个基于《三体》和《流浪地球》背景的多人在线物理模拟游戏，部署在 Starknet 。所有玩家需要合作建造工厂管道和电网，将自然资源转化为各种设备以驱动行星逃离太阳系。它的特色在于需要玩家在链上进行协作以共同完成一个链上目标。

Treaty 由 Curio 团队开发，它是一个大型多人在线的沙盘战略游戏。玩家可以在世界中扮演自己国家的州长，以分配资源、扩张领土、选择信任和合作的玩家做出战略决策，类似 Web2 中的《三国志-战略版》和《率土之滨》的简化版。它的特色在于玩家可以与其他玩家共同起草由代码执行的合约，比如禁运合约、和平合约，玩家在加入合约和支付会员费后，将被禁止攻击其他成员。

LootRealms 由 Starknet 上的 Bibliotheca DAO 开发，其灵感来自于 Loot，是一个沙盘战争策略类游戏，在第一个版本，玩家需要持有 Realms NFT 才能开始游戏，在第二个版本可以通过铸造冒险家 NFT 参与游戏，值得补充的是冒险家的装备就是之前大火的 Loot。在 2023 年 2 月 1 日，LootrRealms 总共筹集了近 4 百万 USDC（超额认购 6.35 倍）的社区筹款，它的特色在于相比其他链上游戏，它的可玩性和完成度非常高，并且率先进行了代币分配和链上治理，游戏内所有交易都通过一个叫做 Nexus 的网络机器流动，玩家提供 $LORDS 作为 Nexus 运转的 Gas。目前 Mask Network 的 Kaspar 正在为 LootRealms 撰写一份深度研报，我们可以期待他的独特见解。其他沙盘模拟类型的完全链上游戏还有 Mithraeum、Conquest。

链上游戏有哪些类别

在这个部分，将展示链上游戏的细微差别。从区块链计算能力和成本的现状来看，链上游戏应该具备低并发量的特点以适应区块链的低效率，但从完全创新的角度来看则不然。在这里存在两个可能被忽略的潜在语境，它们分别是移植，即将以前的游戏移植到链上，以及原生，即开发一种只能在链上发展的游戏，如果我们还称之为游戏的话。

移植

移植，指的是这个游戏本身可以在链下发展，但我们开发一个具有链上特色的版本。正如前面提到的，一个链上的游戏会比链下更加可组合、可复用、去中心，在某些地方更大化其游戏特色。移植类的链上游戏直观来看仅仅将游戏的存储和计算转移到链上。

受到 Will Robinson 《Unblocking On-Chain Games: Part Two — The 18xx Genre》 的启发，我将以 18xx 游戏为例以描述移植型的链上游戏。18xx 是一种回合制模拟经营游戏，游戏背景是在 1846 年，3-5 位铁路大亨在 1846-1935 年间通过在中西部投资和经营铁路公司来竞争赚钱并建立最佳股票投资组合，可以理解为更加复杂的大富翁。每个公司都有自己的金库，用来铺设铁轨或者升级铁轨和购买火车，而这个金库是完全独立于玩家的个人股票组合和银行的。游戏的关键在于平衡何时向您的公司注资以采取行动，或者全额支付您自己和其他股东的费用，这两种行动都会影响公司的股价。

18xx 游戏这类游戏非常适合移植成为链上游戏，因为：

1. 具有足够的回合时间。在每个回合时间内，每个玩家需要确定一系列决策，然后在一个统一的时间点提交，因此它对区块链的 TPS 要求不会太高，并且可以通过聚合或打包交易以降低 Gas。

2. 具有金融博弈属性。在 18xx 中玩家需要与其他玩家在一个金融市场中进行博弈，比如资产拍卖，因此它可以与 DeFi 很好地结合在一起。

18xx 游戏移植到链上后，游戏中的股票可能是 Uni 和 Sushi、DAI 等“真实世界”中的代币，游戏中的交易市场由 Uni V3 驱动；我们还可以将过去的游戏状态写成合约——就像 Treaty 所做的那样。理论上我们可以将 18xx 置换为任何模拟经营游戏——如前面提到的 Treaty、Mithraeum、Conquest、Lootrealms。

原生

原生，指的是那些在链上“第一次”被创造出来的游戏——如果我们还称它为“游戏”的话。

Dark Forest 的创始人 gubsheep 在 《The Strongest Crypto Gaming Thesis》 中提到：

加密原生游戏是一种最大限度地拥抱区块链应用程序开发的架构模式和精神的游戏：

• 游戏数据的真实来源是区块链。区块链不仅仅用作数据的辅助存储，或者存储在专有服务器中的数据“镜像”。所有有意义的数据都存储在区块链上——而不仅仅是资产所有权。这使游戏能够充分利用可编程区块链的优势：一种无需许可即可互操作的透明数据存储。

• 游戏逻辑和规则通过智能合约实现。例如，游戏中的战斗，而不仅仅是所有权，都在链上。

• 该游戏是根据开放生态系统原则开发的。游戏合约和可访问的游戏客户端是开源的。第三方开发者有权通过插件、第三方客户端、可互操作的智能合约，甚至完全重新部署来定制甚至分叉他们自己的游戏体验。这反过来又让游戏开发者可以利用整个（激励一致的）社区的创意输出。

• 该游戏与客户端无关。这与以上三点密切相关，一个游戏是否加密原生的试金石是：“如果核心开发者提供的客户端明天就消失了，这个游戏还能玩吗？” 当且仅当游戏数据存储是无需许可的，如果游戏逻辑可以无需许可地执行，并且社区可以在不依赖核心团队提供的接口的情况下与核心智能合约进行交互，答案才是肯定的。

• 该游戏包含真实世界价值的数字资产。区块链为价值本身的概念提供了一个原生 API，数字资产在默认情况下可以与加密货币互操作。这允许游戏开发者为其玩家和开发者社区构建新的正和激励结构。

Topology 的创始人 GuiltyGyoza 在 《On Medium, Validity Rollup, and Digital Physics》 中借用艾伦凯和麦克卢汉之口所说：区块链作为一种全新的媒介，最前沿的创新者需要在它上面创造独属于区块链的原生应用，如“自主世界”（Autonomous Worlds）。关于自主世界的更多资料，可以参考 0xparc 所撰写的《Autonomous Worlds》 。

一个原生链上游戏的简单案例是 Starknet 上的生命游戏（Game of Life） GOL2。关于生命游戏，也被叫做康威生命游戏（Conway's Game of Life），或者康威生命棋，是英国数学家约翰·何顿·康威在 1970 年发明的细胞自动机。生命游戏规则可以概括为：以正方形网格排列的细胞要么活著要么死亡。 具有 2 个或 3 个活邻居的活细胞可以生存； 一个有 3 个活邻居的死细胞可以复活； 否则细胞死亡。

游戏原型大概是下面这个样子：

GoL2 仍然参考传统生命游戏的基本规则，玩家在网格上创建一个初始配置，然后细胞将根据游戏规则进化（生或死），形成多种组合。玩家可以通过 GOL2 的代币来恢复选定的细胞或创建新的游戏。

GOL2 利用了区块链特性在链上生成游戏内容，但它存在游戏机制过于简单，可玩性不足的问题——游戏中的任何“成就”不会给玩家带来任何成就感，也许我们可以期待链上原生游戏的迭代。

链上游戏引擎现状

如果链上游戏市场成立，那么制造链上游戏的游戏引擎就也是一个需求成立的基建赛道。

但游戏引擎和游戏生产过程以及用户体验直接相关，特别是在用户生成内容（UGC）在游戏中扮演着重要角色的情况下。因此在链上游戏尚未验证的早期阶段，链上游戏引擎往往也肩负着开创一个游戏产品的责任。关于链上游戏引擎会有看上去两种实际上是一种的创投思路——无论是直接做链上游戏还是做链上游戏引擎都需要先做一个游戏。

关于链上游戏引擎的事实是目前在构建它的团队远远少于链上游戏的团队。

一个关于链上游戏引擎的案例是 MUD，它是以太坊复杂应用的开发框架，但更多用于开发链上游戏。

它添加了一些用于组织数据和逻辑的约定，并抽象掉了低级复杂性，因此允许开发者专注于应用程序的功能。它标准化了数据在链上的存储方式以提供所有网络代码来同步合约和客户端状态。这包括直接从 RPC 节点或通用 MUD 索引器同步状态。MUD 是 MIT 许可的，因此它完全开源并且可以免费使用。

在 22 年 11 月 22 日，MUD 背后的开发团队 Lattice 使用 MUD 完成了一个链上 MineCraft（我的世界）——OPCraft。

还记得前面提到过的自主世界吗？Lattice 认为 OPCraft 是一个自主世界：“这是一个链上 3D 体素世界，世界的每一个方面——每条河流、草叶和山顶上的一片雪——都存在于链上。每个动作都作为以太坊交易执行的世界。”Lattice 的思路是先开发引擎，再通过引擎开发游戏。

而 Starknet 链上游戏开发团队 Topology 的创始人 GuiltyGyoza 认为不应该先设计游戏引擎再开发游戏，而应该根据游戏开发需求设计引擎。Topology 是一个知行合一的团队，它们已经开发出了 Isaac、MuMu 等链上游戏，新的链上 AI 格斗游戏将在二月份进行内测。顺便提一下，Starknet 生态的开发人员正在开发一个叫做 Dojo 的链上游戏工具链，Starknet 的开发语言是 Cairo，因此它类似 MUD 的 Cairo 版本。

Folius Ventures 的 Aiko 也在《沙盒，模拟游戏，和完全链上游戏引擎》中提出了一种物理+化学+时间的游戏引擎，她认为基于物理规则的完全链上游戏没有意义，因为它是让玩家被动地“发现”逻辑。与这类链上游戏对应的是游戏物理（玩家在交互过程中发现的、在游戏中的物理规则，如打击土壤掉落装备），它相比剧情式的“被动游戏”更能让玩家有交互感，是一种“主动游戏”。

另一方面，Bas1s Ventures 的 Wonder 表示：现在有的链上游戏引擎主要是将部分关键事件触发的条件（如地理坐标信息）以数据结构的形式传送上链，但有相当一部分完整的逻辑是在中心化的服务器中执行的。而对于高并发游戏如 MMORPG 及 MOBA 来说。如果全部逻辑都在去中心化的环境下进行，则对网络传输的效率和成本有较高要求，才能在进行状态转换(state transition)时对游戏体验不造成重大负面影响。

在链上游戏引擎之外，还存在着其他链上游戏基础设施，比如游戏公会和游戏商店。

Guildly 是一个链上游戏公会，允许玩家共享账户和 NFT，目前还处于开发阶段。

Cartridge.gg 是一个 Starknet 上的游戏商店，玩家可以在其中了解和访问多个链上游戏，用户可以通过手机扫描二维码创建和登陆账户而不需要加密钱包。

链上游戏军火库：Starknet

见多识广的读者会发现本篇文章中提到的许多案例都与 Starknet 相关，Starknet 是以太坊的 ZKR（基于 ZK 技术构建的 L2），它的链上游戏生态在整个区块链生态系统中独树一帜。

Starknet 在性能方面非常适合链上游戏部署。一方面，Starknet 理论上能够达到 9000 TPS，其独特的 STARK 证明系统能够将 6000 万笔 L2 交易合并为以太坊上的一笔交易。且其 ZK 友好的 Cairo 语言有非常高的编译效率，开发人员也能为其 Cairo 代码生成零知识证明， Gas 有望低至 0.001 U。另一方面，其使用的 STARK 证明系统存在网络效应——平均证明大小和验证时间会随着证明规模的扩大而边际递减，简单来讲就是交易成本会随着交易量的增加而减少，因此 Starknet 尤其适合那些需要庞大采用量的链上游戏。

Starknet 基于原生账户抽象设计的合约钱包相比传统钱包也更能适应链上游戏的交互场景。以太坊以及 EVM 兼容的公链/L2 大多都采用双账户设计，而 Starknet 是单账户设计，所有的账户都是合约，简单来讲这将赋予用户账户高度可编程性。比如我们在以太坊上常用的 Metamask（传统 EOA 钱包）不能够自定义某个授权的具体使用场景、功能甚至交易限额，且不支持多签，免密支付（会话密钥）等功能，因此在传统账户设计的区块链中的传统钱包不能适应需要高频授权和复杂交互的链上游戏交互场景，而这恰巧是合约钱包的长处。

并且 Starknet 重视原生应用孵化。其开发团队 StarkWare 与 MatchBox、Only Dust、Nethermind、Mask Network 等合作伙伴举办了多轮黑客松，促进了大量链上游戏团队的发展。

但 Starknet 存在一些问题。一方面，目前 Starknet 的排序器和证明器都是中心化运作的，需要在未来等待去中心协议的设计完成和证明器开源才能保证网络去中心。另一方面，由于网络限速，Starknet 性能尚未解锁，高 Gas 和网络拥堵的情况时而发生，用户体验较差，可能会在 Q1 进行主网更新，短期并不推荐大型项目直接部署在 Starknet 主网。

但总的来看，我们仍然认为 Starknet 是整个链上游戏生态中最有潜力的系统，我们将在下一篇研究中深入分析 Starknet 技术特性、链上游戏生态以及链上游戏设计与构建。

鸣谢

Starknet Astro 是 Starknet 生态最具创意的媒体，提供最前沿、深度的研究。本篇研究同样受到 Bas1s Ventures 对部分思路与内容的支持推出，他们亦是 Web3 最前沿、专业的投资机构。

Bas1s Ventures 成立于 2021 年，是一家新晋 Web3 国际风投机构，围绕区块链的大规模应用及技术生态展开投资布局，并获得亚洲及世界一线传统游戏公司等支持。团队成员曾早期工作于币安等知名企业，投资组合包括：Delysium，Mirror World，Highstreet，Xterio，Taker Protocol 等。

关注 StarkNet Astro ✨ 中文频道；英文频道

分享会内容过长，本次 AMA 总结文字做大量删减，如果你想了解 StarkNet 更多知识可前往 StarkNet Astro 知识库页面。

StarkWare

StarkWare 是 StarkEx 和 StarkNet 背后的开发团队，团队成员以密码学工程师为主，STARKs 和 SNARKs 发明者均是其创始人，技术实力一流；融资方面累计融资 2.7 亿美元，估值达到 80 亿美元，为 L2 最高。

StarkEx

简介

StarkEx 是 StarkWare 创立的，为项目方定制 ZKR 的企业服务，它可以帮助项目定制应用专有的 ZKR，目前使用 StarkEx 的客户包括 dYdX 、Sorare、ImmutableX、DeversiFi 等。

与通用 ZKR 不同，在通过 StarkEx 定制的 ZKR 中，项目方往往具有超级管理员的权限，可以决定交易是否通过与排序，外部开发者不能免许可地部署应用，网络较为中心化，但优点是性能极高。

工作原理

StarkEx工作流如下：

1. 打包交易：链下服务器（往往由项目方中心化运行）处理客户请求，将多个交易组合成一个“批次”，供 StarkEx 处理。

2. 确认交易和更新状态：链下服务器确认交易合法，并以被压缩后的哈希形式更新系统状态。

3. 为交易生成证明：SHARP 会为交易生成 STARK 证明以确认交易有效性，然后将证明和更新发送到链上 Verifier 智能合约，以确保交易的完整性。

4. 链上验证证明：一旦 STARK 证明被验证，状态更新被提交并结算回以太坊主网。所有交易都是在链外处理和验证的，而其完整性的证明是在链上验证的。

SHARP 是一个共享证明者，它同时为多个 StarkEx 客户/应用提供证明生成服务——生成计算完整性声明的证明。Verifier 是部署在以太坊上的智能合约，用于验证由 StarkEx 的交易生成的 STARK 证明的正确性。

StarkNet

简介

StarkNet 是一个通用的 ZK Rollup，理论上能够将 TPS 提高到 2000+，Gas 降低到 0.002 以下。

为什么 StarkNet 具有相比以太坊更高的性能？首先回顾一下以太坊的工作原理。在以太坊上，每提交一笔交易都需要所有节点检查、验证并执行交易来保证计算正确性，并将计算后的状态变化在网络中广播。

相比之下，StarkNet 仅在链下执行计算并生成一个 ZK 证明，然后在链上验证该证明的正确性，最后把多个 L2 交易打包为以太坊上的一笔交易。因此，StarkNet 上发生的交易成本可以被同一打包批次的其他交易所均摊，就像拼车（🚌拼多多）一样，交易越多，成本越低。StarkNet 为交易生成 ZK 证明的方法可以大大提高网络运行速度、减少链上通信量、增加网络吞吐，因此 StarkNet 相比以太坊具有更高 TPS 和更低 Gas。

简而言之，将验证计算正确性比喻为老师需要检查同学们是不是掌握了知识。以太坊的方法是检查每个同学是否能背诵整本教科书，而 StarkNet 的方法是让同学们做卷子。后者的效率更高，成本更低，但仍然保证安全。

EVM 兼容

StarkNet 网络本身不兼容 EVM（以太坊虚拟机），而设计了另外一套 ZK 友好的 Cairo VM，是 Vitalik 所说的第四类 zkEVM,，但属于严格意义上的 zkVM。

在 zkVM 架构方面，StarkNet 实现了一套更加 ZK 友好的指令集、汇编语言、字节码、AIR（代数中间表示） 以及高级语言 Cairo。

尽管 StarkNet 本身不兼容 EVM，但 StarkNet 仍然可以通过其他方式兼容以太坊。

1、Warp：将 Solidity 转译为 Cairo 语言的转译器

Warp 是一个 Solidity-Cairo 转译器，目前已经由以太坊著名基础设施团队 Nethermind 开发完成。Warp 可以把 Solidity 代码转译为 Cairo，但转译后的 Cairo 程序往往需要修改并增添 Cairo 特性（如调用内置函数，优化内存等）才能最大化执行效率。

2、Kakarot：一个用 Cairo 语言编写的 zkEVM

Kakarot 是一个用 Cairo 写的智能合约，目前部署在 StarkNet（goerli测试网）上，100% 字节码等效 EVM。目前处于测试阶段。以太坊应用可以通过部署到 Kakarot 的方式移植到 StarkNet。

• ✅ Kakarot 可以：(a) 执行任意 EVM 字节码，(b) 按原样部署 EVM 智能合约，(c) 调用 Kakarot 部署的 EVM 智能合约的功能（视图和写入方法）。

• ✅ Kakarot 是一个 EVM 字节码解释器。

目前已经支持 EVM 全部操作码。

工作原理

StarkNet 有五个组成部分。分别是在 StarkNet 上的 Prover（证明者），Sequencer（排序器）和全节点；以及部署在以太坊上的验证者（Verifier）和核心状态合约（StarkNet Core）。

工作流程如下：

1、当我们在 StarkNet 上发起一个交易，一个链下服务器——排序器将会接收、排序、验证，并将它们打包到区块。执行交易，然后状态转换发送给 StarkNet Core 合约；

2、证明者将为交易生成证明，并发送给以太坊的验证者合约；

3、验证者将验证结果发送到以太坊上的 StarkNet Core 合约，并从 StarkNet Core 合约触发一组新的以太坊交易，以更新链上的全局状态以进行记录保存。状态事务作为“calldata” （EIP-4844后为Blob）来发送，以节省 L1 事务 gas。这些“metadata”可被 StarkNet 全节点解密。

全节点基本发挥存储功能。全节点存储状态改变、元数据、证明以及记录在 StarkNet 中的已被执行的所有事务，并跟踪系统的当前全局状态。在有必要的时候，全节点将解密“metadata”来重构 StarkNet 的历史。

参考 StarkNet 开发倡导者 @barretodavid 写的《StarkNet's Architecture Review》。

账户抽象

不同于以太坊 EOA+CA 的双账户设计，StarkNet 实现了原生账户抽象，只有一种账户设计，借鉴了 EIP 4337 的精神，下图为交易模型：

STARK 证明系统

目前有许多不同的证明系统（生成和验证证明） ，如 Halo、PLONK、Groth16、Groth09 、Marlin、Plonky2 等，它们都属于 SNARK 证明系统。证明系统存在一个证明者生成证明，一个验证者验证证明。而不同的 ZK 项目几乎都会使用不同的证明系统，StarkNet 使用的 STARK 某种意义上属于一种特别的 SNARK 。

STARK 相比 SNARK 有更多创新。它不需要和 SNARK 一样依赖“可信设置”。它还带有更简单的密码学假设，避免了对椭圆曲线、配对和指数知识假设的需要，纯粹依赖哈希和信息论，因此抗量子攻击。总体来讲 STARK 比 SNARK 更安全。

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

总结一下，相比 SNARK，STARK 更安全，平均验证时间和证明大小将随着验证规模扩大而降低，缺点在于初始证明尺寸更大，因此更适合大规模应用。

这里介绍一下 STARK 的重要特性：递归证明

任何通用的、简洁的知识系统的证明/论证（特别是STARKs） 都可以用来递增地验证计算。这意味着一个计算可以产生一个证明，以证明该计算的前一个实例的正确性，这个概念被非正式地称为 "递归证明组合"或者"递归STARKs"。

换句话说，一个递归 STARK 证明者可为一个陈述生成一个证明，即系统的状态可以从 a 移到 a+1。因为证明者已经验证了一个证实 a 的计算完整性的(递归)证明，并且忠实地执行了状态 a 的计算，达到了新的状态 a+1。简而言之，你可以理解该过程将 a 和 a+1 两个证明合并为了一个证明，在理论上可以将近乎无限的证明合并为一个证明，这将大幅减少证明大小和验证时间。如下图所示：

Cairo VM 和 Cairo 语言

Cairo VM 概述

Cairo VM 是一个是一个采用冯诺依曼架构的 CPU VM，其编程语言也叫 Cairo，Cairo 语言基于 Cairo 汇编，因此编译效率非常高。 Cairo 是 CPU Algebraic Intermediate Representation （代数中间表达）的首字母缩写。Cairo VM 包含单个 AIR 来验证这个 「CPU」 的指令集。

它有时候也被叫做 StarkNet OS/Cairo OS 。它不同于 EVM，Cairo VM 不执行计算，仅为计算生成证明并验证正确性。

关于工作方式，它根据收到的输入的交易来更新系统的 L2 状态。促进 Cairo 合约的执行。Cairo VM 是基于 Cairo 的，合约可用的具体系统操作和功能可作为对操作系统的调用。

Cairo VM 特性

灵活的 CPU 架构

Cairo VM 采用图灵完备的冯诺依曼 CPU 架构，可通过软件编程的方式无限接近 AISC 的性能，有对应的指令集，所以 Cairo 理论上可以复刻其他虚拟机。

只读非确定性内存模型

Cairo VM 采用只读的非确定性内存，这意味着每个内存单元的值由证明者选择，它不能随时间改变（在 Cairo 程序执行期间），是不可变的。该指令只能从中读取。我们可以将之视为一次写入的存储器：可以向一个单元写一次值，但事后不能改变它。而且它是连续的，如果有空会被任意值填充。

ROM 优点包括：低成本，电路比 ROM 更简单；永存储，内存值将保证永久存储；不可篡改，数据不能修改和删除。

Cairo 语言概述

Cairo 是 StarkNet 的智能合约语言，基于 STARK 设计，Cairo 程序可生成 STARK 证明。

Cairo 程序是汇编代码的集合，Cairo 开发人员将以高级语言 Cairo 来编写智能合约而非 Cairo 汇编。当我们写了一个 Cairo 程序，Cairo 编译器会将 Cairo 代码编译成 Cairo 汇编，Cairo 汇编器将采用汇编代码生成 Cairo 字节码（它运行在 Cairo CPU）以在 Cairo VM 执行，当他最终运行到真实机器上还需要编译为操作码和机器代码（还有指令）。

Cairo 语言特性

启动加载：从哈希加载程序

程序可以将另一个程序字节码写入内存，然后运行该程序。 这有两个好处：

1. 可扩展性，验证时间和程序大小呈现对数关系，正如 STARK 部分提到的。

2. 隐私性，验证者可以验证程序是否正确执行而无需知道计算。

内置函数：减少代码编译

开发者直接调用内置函数可以减少计算开销，优化开发体验，而不需要代码转换。添加内置函数不会影响 CPU 约束。这只是意味着相同的内存在 CPU 和内置函数之间共享，如图所示。

Cairo 体系结构没有指定一组特定的内置函数。可以根据需要在 AIR （代数中间表示）中添加或删除内置函数。

特色生态

与其他生态不同，StarkNet 有一些原生的创新应用，分别是全链游戏、合约钱包和链上 AI。

关于全链游戏（On-chain game），它不同于 GameFi。全链游戏与 GameFi 的根本差别在于前者是去中心、免许可、可组合、互操作的，而后者仅仅将游戏中的关键道具铸造为代币。

GameFi 只是将游戏资产上链，计算与存储的部分则在链下的中心化服务器上，比如知名的 StepN，Axie Infinity，尽管它们已经取得了非常好的成绩，但这些游戏的玩法和内容是有限的，且受到项目方中心化运营的影响，项目方可以更改游戏规则。GameFi 也不支持 UCG ——玩家和开发者不能免许可地创造游戏内的内容与资产，并且其他链上应用也难以与之互操作。

全链游戏则不仅仅是将游戏资产上链，整个游戏也以合约的方式存在于网络之中，游戏的状态存储、逻辑执行也完全在链上，符合区块链的去中心、免许可、可组合的基本属性。这意味着没有实体可以单方面更改游戏规则，游戏的主动权在玩家手中，游戏“官方”的概念将会逐渐消失。

更有价值的是，玩家与开发者可以基于开源代码自定义前端，在基本规则约束下对游戏内的设施和资产进行再创造，解锁 UCG——用户创作内容的可能性。而且任何符合全链游戏合约规则的 DApp 都可以免许可地与之互操作，这将把全链游戏的可组合性扩展到更大的生态范围之中，不仅各个链游可以相互操作，链游与 DeFi 、NFT 以及在未来可能涌现的任何 DApp 都能够与全链游戏相互操作，这将打破 Web2 以垄断为商业模式的业务格局，给开发者和用户更完美的应用体验以及更有想象力的创造机会。

推荐项目 Topology、Cartridge.gg、Briq、Lootrealms

关于合约钱包，它具有强大的可编程、可组合的特性，从而能够适应 DeFi 之外的新场景如全链游戏、社交等。推荐 StarkNet 合约钱包 Braavos 和 Argent，前者可以将手机变成硬钱包，后者支持社交恢复，并且还将不断更新功能。

关于链上 AI，StarkNet 允许 AI 模型在链下执行计算，将生成证明交由他人验证即可保证计算完整性，并且 STARK 证明系统存在网络效应，因此可降低需要大规模证明生成的 AI 模型的成本。

链上 AI 应用范围包括：游戏、预言机、交易（自动收益）、反女巫、KYC、数据隐私以及 AI 模型算力挖矿等。

问答

Q：StarkNet 交易排序的逻辑是什么？是否也会有以太坊上的 MEV？官方排序器有 MEV 需求吗？能做吗？

A：1）StarkNet 排序器排序，仍然是 gas 优先，去中心排序器后会做并行执行，目前去中心排序器的更多细节还没有确定，排序设计也还没有确定；L2 交易有顺序，在 L1 上作为批处理就不体现 L2 交易顺序；2）会有 MEV，但是还没确定排序器去中心的共识，可能会借鉴 Flashbots，PBS 之类的机制；3）目前 StarkNet 中心化运营排序器，官方没有做 MEV，Rollup 理论上都可以做。

Q：L2 gas fee，速度在哪里可以看？哪里能看到它们最终的性能指标？

A：Gas 在 https://l2beat.com/scaling/tvl 看，TPS 在这里看 https://ethtps.info/。目前 ZKR 的工程进度较慢，可能在年中才能迎来规模采用，现在比较性能意义不大，且 L3 的实现可能会给 TPS 计算造成阻碍。

Q：为什么很多以太坊都部署在 Arbitrum？

A：因为是 OPR，开发得更快；在前年就部署了，发展期更长。

Q：ZKR 什么时候会迎来应用爆发？

A：应用爆发分为两类，应用迁移和应用创新，迁移进度取决于不同 ZKR 的工程周期，可能会在 Q3-Q4；应用创新方面，哪些高 TPS、低单位收益的应用更能在 ZKR 上实现，可能会在年末爆发，取决于。

Q：OPR 和 ZKR 的差别是什么？

A：OPR 使用欺诈性证明，ZKR 使用有效性证明，后者更快更便宜，Vitalik 有过文章阐述

https://vitalik.eth.limo/general/2021/01/05/rollup.html

Q：StarkNet 有什么马上能用的合约钱包？

A：Braavos、Argent。

Q：账户抽象的未来是什么？

A：基于账户抽象的合约钱包可编程，比如它允许用户自定义设置在某个时间内，低于一定价格的 Gas 都将被自动支付；而且相比 EOA 钱包更能适用 DeFi 之外的新场景如全链游戏、社交。它就是把钱包当成合约来设计，让钱包能实现合约能实现的功能。

Q：StarkNet 上有哪些值得交互的项目？

A：可以关注 Topology 团队开发的全链游戏 MuMu，它们近期还会推出一个新的链上 AI 格斗游戏；NFT 项目推荐 Briq，之前项目方给购买 NFT 的用户空投了圣诞树 NFT；推荐 Loot 系的游戏 Lootrealms，这个游戏发币了。

Q：StarkNet 是不是更适合做链上 AI 和全链游戏？

A：是的，因为 StarkNet 使用 STARK 证明系统，它的平均验证时间和证明尺寸会随着证明规模扩大而降低，因此具备网络效应，这是 SNARK 所不具备的特性，这对链上 AI 和游戏而言有助于降低成本和提高性能；另一方面 StarkNet 生态有很多全链游戏融资、开发的基础设施，如 MatchBoxDAO、Volt Capital、Cartridge.gg 等，官方也在大力支持全链游戏的发展，因此 StarkNet 在技术和资源支持方面适合做链上 AI 和全链游戏。

Q：StarkNet 可不可以和其他公链对接？

A：官方宣称不会，只会以太坊作为结算层；技术上可以。

Q：账户抽象的缺点是什么？

A：现在比较早期，相关的工具、代码不够成熟，但随着时间的推进账户抽象会越来越成熟，账户抽象的优点是让交易更加可编程。

Q：ZKR 的电路是什么？为什么要有电路？

A：可以理解为 ZK 的代码；ZKR 需要为代码的计算生成证明，高级语言的代码需要编译为字节码再变成 ZK 电路才能够被用来生成 ZK 证明。