一文梳理StarkWare技术架构与生态应用

StarkWare简介

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

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

StarkEx：专有ZKR引擎

简介

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

整体架构

工作流包括以下四个环节

打包交易：链下服务器处理客户请求，将多个交易组合成一个“批次”，供StarkEx处理。

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

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

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

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

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

StarkWareApplications

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

标准流程

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

参考链接：Introduction::StarkExDocumentation

高级概述

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

前端，StarkEx客户支持两类操作，链上和链下。前者是标准的以太坊交易，用户直接通过StaarkEx合约进行存款取款，后者是通过StarkEx引擎执行的操作，如dydx等。

订单验证，由StarkEx客户的后端设置并进行验证。

业务逻辑，客制化StarkEx合约（子合约）来支持客户业务逻辑

交易流，传输到StarkEx的所有交易都使用称为tx_ids的连续标识符进行验证和索引，类似nonce的做法，

交易发送方，一旦StarkEx网关确认交易正确就会保证执行它（不是真的立即执行），并且将在前端提前显示给用户，而不是等待链上最终确定。

错误处理，如果检测到无效交易，StarkEx系统将会向客户的专业端点报告错误，客户将会以另外的要执行的交易列表来代替无效交易，如空列表等。

批处理审核，任何批次在链上传输之前可以被客户审核，如果和预期状态转换和不一致，客户可以不批准或者回滚。

抗审查，如果客户审查用户请求，StarkEx允许用户直接通过StarkEx合约执行操作，客户必须在规定时间内向用户提供它，否则StarkEx合约将会冻结。

参考文档：StarkExPartnerIntegration::StarkExDocumentation

StarkNet：通用ZKR

简介

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

基本介绍

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

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

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

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

EVM兼容

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

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

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

尽管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全部操作码。

工作原理

组成部分

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

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

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

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

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

参考StarkNet开发倡导者@barretodavid写的《StarkNet’sArchitectureReview》。

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

账户抽象与交易模型

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

下图为交易模型，

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

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

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

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

STARK

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

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

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

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

扩展性详解

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

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

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

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

递归证明

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

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

CairoVM：验证计算正确性

CairoVM概述

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

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

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

Cairo语言概述

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

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

非确定性计算

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

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

伪代码如下：

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

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

Y=SQRT(X)

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

Y*Y=X

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

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

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

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

anacceptinginputtotheCairodeterministicmachine,thatconstitutesthewitnesstothenondeterministicmachine.

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

是一个并行状态机。

内存模型：只读非确定性

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

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

ROM优点包括

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

内置函数：减少代码编译

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

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

CPU架构：灵活

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

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

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

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

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

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

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

StarkNet生态

盘点StarkNet生态：

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

全链游戏

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

MatchboxDAO：https://mirror.xyz/matchboxdao.eth

TheFutureofOn-ChainGaming：

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

Game2.0：

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

重点推荐Topology团队，Lootreamls。

合约钱包

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

共识层支持手机硬件。在StarkNet（编程语言Cairo）这样原生账户抽象的L2上，支持多种椭圆曲线，而不是和以太坊一样只支持ECDSA（Secp256k1），因此可以让手机的加密芯片/模块直接对交易签名（大部分手机不支持ECDSA）。因此，在原生账户抽象的L2上，合约钱包可以和硬钱包一样直接通过硬件签署交易。

钱包层进行签名转录。在以太坊这样非原生账户抽象的网络上，合约钱包可以签名转录。像EIP-4337可以自定义验证逻辑，用户用手机硬件支持的算法签名后再转换为以太坊支持的ECDSA。

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

以太坊上的EOA仅支持Secp256k1椭圆曲线上的签名方案ECDSA

大部分的智能手机都不支持以太坊的椭圆曲线。

所以移动钱包需要依靠软件签署交易，移动钱包因此是热钱包。

StarkNet原生账户抽象，支持多种椭圆曲线，签名验证高度可编程，因此基于StarkNet/Cairo的手机钱包完全可以变成硬钱包。

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

Cairo已经有一个[nistp256](