详解Starkware技术架构与生态应用梳理

频道：区块链日期：2023-04-13 08:04:12 浏览：72

新用户下载，赢取高达 60,000 元盲盒

?原文：《DAOrayaki ｜Starkware技术架构与生态应用梳理》

StarkWare

简介

StarkEx 和 StarkNet 均为 StarkWare 团队开发的项目，前者类似 Iaas，类比应用链，StarkWare 帮助大型项目开发专有应用 Rollup；后者则是可部署通用应用的 Rollup。

截止目前，StarkWare （StarkNet 背后团队）已经完成 6 轮融资，共计 2.73 亿美元。尤其是最近一轮融资金额达到 1 亿美元，使其估值翻了两番，达到 80 亿。作为L2 项目中估值最高的项目，本文特探讨Starkware的技术架构和生态应用。

StarkEx：专有 ZKR 引擎

简介

在去年和今年上半年，StarkWare 通过提供扩容技术解决方案 StarkEx 创立了扩容即服务（scaling as a service）的商业模式，建立应用专有网络，服务业内头部客户 dYdX 、Sorare、ImmutableX、DeversiFi 等。

整体架构

工作流包括以下四个环节

打包交易：链下服务器处理客户请求，将多个交易组合成一个“批次”，供 StarkEx 处理。确认交易和更新状态：链下服务器确认交易合法，并以被压缩后的哈希形式更新系统状态。为交易生成证明：完成上述流程后，SHARP 会为交易生成 STARK 证明以确认交易的有效性。然后将证明和更新发送到链上 Verifier 智能合约，以确保交易的完整性。链上验证证明：一旦STARK证明被验证，状态更新被提交并结算回以太坊主网。所有交易都是在链外处理和验证的，而其完整性的证明是在链上验证的。

SHARP 是一个共享证明者，它同时为多个 StarkEx 客户/应用提供证明生成服务——生成计算完整性声明的证明。

Verifier 是部署在以太坊上的智能合约，用于验证来自 StarkEx 的交易的正确性。

StarkWare Applications

StarkEx 应用程序（图中Exchange）是一系列支持可扩展和自我托管交易的应用程序，区分现货交易和杠杆交易。应用包括两个组件，智能合约和后端。

标准流程

用户发起交易，交易可以直接与智能合约交互每个交易都有一个唯一的 id，共同组成一个交易流，StarkEx 应用将交易流传输到后端后端将状态转换提交给 SHARP，SHARP 为状态转换生成证明 SHARP 向验证者合约提交证明并在验证者完成验证后，验证者将之记录在 Verifier Fact Registry，然后后端将在 StarkEx 智能合约上执行状态转换。 StarkEx 智能合约检查状态转换是否符合预定义规则来确保状态转换的有效性（通过验证者合约）。

参考链接：Introduction :: StarkEx Documentation

高级概述

如下图所示，StarkEx 系统旨在接受来自合作伙伴后端的用户交易。这些交易随后由 StarkEx 系统进行批处理和处理。结合前面智能合约和后端的介绍，整个 StarkEx 处理交易的过程和职责分工概述如下。

前端，StarkEx 客户支持两类操作，链上和链下。前者是标准的以太坊交易，用户直接通过 StaarkEx 合约进行存款取款，后者是通过 StarkEx 引擎执行的操作，如 dydx 等。订单验证，由 StarkEx 客户的后端设置并进行验证。业务逻辑，客制化 StarkEx 合约（子合约）来支持客户业务逻辑交易流，传输到 StarkEx 的所有交易都使用称为 tx_ids 的连续标识符进行验证和索引，类似 nonce 的做法，交易发送方，一旦 StarkEx 网关确认交易正确就会保证执行它（不是真的立即执行），并且将在前端提前显示给用户，而不是等待链上最终确定。错误处理，如果检测到无效交易，StarkEx 系统将会向客户的专业端点报告错误，客户将会以另外的要执行的交易列表来代替无效交易，如空列表等。批处理审核，任何批次在链上传输之前可以被客户审核，如果和预期状态转换和不一致，客户可以不批准或者回滚。抗审查，如果客户审查用户请求，StarkEx 允许用户直接通过StarkEx 合约执行操作，客户必须在规定时间内向用户提供它，否则 StarkEx 合约将会冻结。

参考文档：StarkEx Partner Integration :: StarkEx Documentation

StarkNet：通用 ZKR

简介

不同于为不同的应用定制 ZK Rollup 的 StarkEx，StarkNet 是一个通用的 ZK Rollup，开发者可在 StarkNet 上部署应用。

基本介绍

在以太坊上，每提交一笔交易都需要所有节点检查、验证并执行交易来保证计算正确性，并将计算后的状态变化在网络中广播。

https://ethereum.org/zh/developers/docs/evm/

StarkNet 仅在链下执行计算并生成一个 ZK 证明，然后在链上验证该证明的正确性，最后把多个 L2 交易打包为以太坊上的一笔交易。因此，StarkNet 上发生的交易成本可以被同一打包批次的其他交易所均摊，就像拼车（拼多多）一样，交易越多，成本越低。

除此之外，相比以太坊让每个节点完整执行交易的方法，StarkNet 为交易生成 ZK 证明的方法可以大大提高网络运行速度、减少链上通信量、增加网络吞吐，因此 StarkNet 相比以太坊具有更高 TPS 和更低 Gas。

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

EVM 兼容

StarkNet 网络本身不兼容 EVM ，而设计了另外一套 ZK 友好的 Cairo VM 。

StarkNet 没有和 Hermez 和 Scroll 一样针对以太坊操作码做 ZK 电路，而是自己做了一套更加 ZK 友好的汇编语言、AIR（代数中间表示）以及高级语言 Cairo。

StarkNet 属于 Vitalik 定义的 type 4 级别——语言兼容的 zkEVM（StarkNet由于定制了虚拟机严格来讲属于zkVM）。

https://vitalik.eth.limo/general/2022/08/04/zkevm.html

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

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

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

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

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

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

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

https://github.com/sayajin-labs/kakarot

工作原理

组成部分

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

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

当我们在 StarkNet 上发起一个交易，一个链下服务器——排序器将会接收、排序、验证，并将它们打包到区块。执行交易，然后状态转换发送给 StarkNet Core 合约；证明者将为交易生成证明，并发送给以太坊的验证者合约；验证者将验证结果发送到以太坊上的 StarkNet Core 合约，并从 StarkNet Core 合约触发一组新的以太坊交易，以更新链上的全局状态以进行记录保存。状态事务作为“calldata” （EIP-4844后为Blob）来发送，以节省 L1 事务 gas。这些“metadata”可被 StarkNet 全节点解密。

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

参考 StarkNet 开发倡导者@barretodavid 写的《StarkNet’s Architecture Review》。【1】

浏览器https://testnet.starkscan.co/，L2动态出块，以太坊一小时结算

账户抽象与交易模型

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

下图为交易模型，

https://community.starknet.io/t/starknet-account-abstraction-model-part-1/781

原生账户抽象为账户可编程打开大门，StarkNet 的开发倡导者@barretodavid 提到 StarkNet 上实现手机硬钱包的思路。

以太坊上的 EOA 仅支持 Secp256k1 椭圆曲线上的签名方案 ECDSA 大部分的智能手机都不支持以太坊的椭圆曲线。所以移动钱包需要依靠软件签署交易，移动钱包因此是热钱包。 StarkNet 原生账户抽象，支持多种椭圆曲线，签名验证高度可编程，因此基于 StarkNet/Cairo 的手机钱包完全可以变成硬钱包。

Cairo 已经有一个nistp256（用于智能手机Secure Enlave）的实现

https://github.com/spartucus/nistp256-cairo

简单来讲就是直接调用手机的加密模块来对交易进行“硬签名”。

STARK

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

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

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

https://consensys.net/blog/blockchain-explained/zero-knowledge-proofs-starks-vs-snarks/

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

扩展性详解

证明时间线性扩展：证明人花费的时间与哈希调用的数量呈近似线性关系。

在 80 比特的安全级，STARK 每 12288 次哈希调用的证明者执行时间为 1 秒，得 12288次/S；而每 98304 次哈希调用需要 10 秒，得 9830次/S，因此，我们可以知道 STARK 的证明时间和哈希调用基本呈近似线性关系。如下图所示

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

**验证和证明大小对数扩展：验证时间（与证明大小）与哈希调用呈现对数关系。**如下图所示：

左图可以看出，当哈希调用从 3072 增加到 49152，验证时间从 40 毫秒增加到 60 毫秒。而当哈希调用从 49152 增加到 786432，验证时间仅从 60 毫秒增加到 80 毫秒。证明大小同理。因此，我们可得知，哈希调用次数越多，平均验证时间越短，平均证明大小也会更小（调用哈希生成哈希值/证明）。

递归证明

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

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

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

Cairo VM：验证计算正确性

Cairo VM 概述

有时候也通过 StarkNet OS/Cairo OS 的方式出现，是一个东西，不同于 EVM 执行计算，Cairo VM 本身仅为计算生成证明并验证正确性。

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

关于工作方式，它根据收到的输入的交易来更新系统的 L2 状态。促进（基于Cairo的）StarkNet 合约的执行。操作系统是基于Cairo的，本质上是使用 STARK 证明系统对其输出进行证明和验证的程序。StarkNet 合约可用的具体系统操作和功能可作为对操作系统的调用。

Cairo 语言概述

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

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

非确定性计算

Cairo 程序的目标是验证某些计算是正确的，因此可以相比那些确定性计算走捷径。它意味着为了证明一个计算，验证者可以做一些不属于计算的额外工作。

例如，证明x=961的平方根y是在0,1,…,100的范围内。直接的方法是写一个复杂的代码，从 961 开始，计算它的根，并验证这个根是否在所要求的范围内。

伪代码如下：

猜测y的值（这是不确定的部分）。计算y2并确保其结果等于x。验证y是否在范围内。

并且，如果我们采取以下的计算方式。

Y = SQRT(X)

我们可以改为计算如下（非确定性计算）。

Y*Y=X

我们可以看到，有两种可能的解决方案。+Y和-Y，而且有可能只有其中一个能满足其余的指令。

这意味着，如果没有一些额外的信息，一些开罗程序（如上述）是无法有效执行的。这种信息由我们称之为提示的东西提供。提示是 Cairo Runner 的特殊指令；用于解决不能轻易推导出数值的非确定性问题。理论上，提示可以用任何编程语言编写。在当前的Cairo实现中，提示是用 Python 写的。

关于确定性和非确定虚拟机，witness

Cairo 在这里其实也会涉及到有确定性的 Cairo VM 和非确定性的 Cairo VM。前者就是正经的 zkVM，证明和验证；后者用于非确定性计算。

an accepting input to the Cairo deterministic machine, that constitutes the witness to the nondeterministic machine.

Cairo 确定性 VM 的一个可接受的输入构成了非确定性 VM 的 witness，ZKP 需要将 witness 作为输入输出 proof。（NP 语句的 witness 见证是一条信息，可让您有效地验证该语句是否真实。例如，如果声明某个图中存在哈密顿环，则见证就是这样的环。给定一个环，可以有效地检查它是否是一个有效的哈密顿环，但是找到这样的环很困难）

是一个并行状态机。

内存模型：只读非确定性

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

而且它是连续的，如果有空会被任意值填充。

ROM 优点包括

低成本，电路比 RAM 更简单永存储，不可篡改，数据不能修改和删除

内置函数：减少代码编译

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

https://medium.com/@pban/demystifying-cairo-white-paper-part-i-b71976ad0108

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

CPU 架构：灵活

更加灵活，可以通过软件编程的方式无限接近 AISC 的性能（所以Cairo会做CPU？）。以 Cairo 复刻其他虚拟机。

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

程序可以将另一个程序字节码写入内存，并让 Program Counter 指向该内存段，然后运行该程序。一个从哈希启动加载的用例是，一个被称为启动加载器的程序计算并输出另一个程序的字节码，然后像之前一样开始执行它。这样验证者只需要知道程序的哈希而非完整字节码。这有两个好处：

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

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

连续记忆：连续访问内存地址

Cairo 有一个技术要求，程序访问的内存地址必须是连续的。例如，如果访问地址 7 和 9，那么在程序结束之前也必须访问 8（访问顺序无关紧要）。如果地址范围中存在小间隙，证明者将自动用任意值填充这些地址。通常，存在这样的间隙是低效的，因为这意味着内存在未被使用的情况下被消耗。引入太多的漏洞可能会使证明的生成对于诚实的证明者来说过于昂贵而无法执行。然而，这仍然没有违反可靠性保证——无论如何都不会产生错误的证明。

StarkNet 生态

盘点 StarkNet 生态：

https://h0m83hhc6r.feishu.cn/docx/doxcnS3GGdXXc1PzKh9uTgTR73c

全链游戏

全链游戏——生产效率+消费体验的变革，基本上，有思考（各个机构和团队的文章），有实践（链上游戏项目和黑客松），有资金（融资和grant），最重要的是有一个富有活力的开发者社区。

Matchbox DAO：https://mirror.xyz/matchboxdao.eth

The Future of On-Chain Gaming：

https://volt.capital/blog/the-future-of-on-chain-gaming

Game 2.0：

https://www.guiltygyoza.xyz/2022/07/game2

重点推荐 Topology 团队，Lootreamls 。

合约钱包

合约钱包变成硬钱包的实现方法有两种。

共识层支持手机硬件。在 StarkNet（编程语言Cairo）这样原生账户抽象的 L2 上，支持多种椭圆曲线，而不是和以太坊一样只支持 ECDSA（Secp256k1），因此可以让手机的加密芯片/模块直接对交易签名（大部分手机不支持ECDSA）。因此，在原生账户抽象的 L2 上，合约钱包可以和硬钱包一样直接通过硬件签署交易。钱包层进行签名转录。在以太坊这样非原生账户抽象的网络上，合约钱包可以签名转录。像 EIP-4337 可以自定义验证逻辑，用户用手机硬件支持的算法签名后再转换为以太坊支持的 ECDSA。

StarkNet 的开发倡导者@barretodavid，提到的在 StarkNet 上实现手机硬钱包的思路。

https://twitter.com/barretodavid/status/1563584823884935168

Cairo 已经有一个[nistp256](

)（用于智能手机Secure Enlave）的实现。