StarkWare
简介
StarkEx和StarkNet均为StarkWare团队开发的项目，前者类似Iaas，类比应用链，StarkWare帮助大型项目开发专有应用Rollup；后者则是可部署通用应用的Rollup。
截止目前，StarkWare已经完成6轮融资，共计2.73亿美元。尤其是最近一轮融资金额达到1亿美元，使其估值翻了两番，达到80亿。作为?L2项目中估值最高的项目，本文特探讨?Starkware?的技术架构和生态应用。
StarkEx：专有ZKR引擎
简介
在去年和今年上半年，StarkWare通过提供扩容技术解决方案StarkEx创立了扩容即服务的商业模式，建立应用专有网络，服务业内头部客户dYdX、Sorare、ImmutableX、DeversiFi等。
整体架构
工作流包括以下四个环节
打包交易：链下服务器处理客户请求，将多个交易组合成一个“批次”，供StarkEx处理。
确认交易和更新状态：链下服务器确认交易合法，并以被压缩后的哈希形式更新系统状态。
为交易生成证明：完成上述流程后，SHARP会为交易生成STARK证明以确认交易的有效性。然后将证明和更新发送到链上Verifier智能合约，以确保交易的完整性。
链上验证证明：一旦?STARK?证明被验证，状态更新被提交并结算回以太坊主网。所有交易都是在链外处理和验证的，而其完整性的证明是在链上验证的。
SHARP是一个共享证明者，它同时为多个StarkEx客户/应用提供证明生成服务——生成计算完整性声明的证明。
Verifier是部署在以太坊上的智能合约，用于验证来自StarkEx的交易的正确性。
StarkWareApplications
StarkEx应用程序是一系列支持可扩展和自我托管交易的应用程序，区分现货交易和杠杆交易。应用包括两个组件，智能合约和后端。
?标准流程
用户发起交易，交易可以直接与智能合约交互
每个交易都有一个唯一的id，共同组成一个交易流，StarkEx应用将交易流传输到后端
后端将状态转换提交给SHARP，SHARP为状态转换生成证明
SHARP向验证者合约提交证明并在验证者完成验证后，验证者将之记录在VerifierFactRegistry，然后后端将在StarkEx智能合约上执行状态转换。
StarkEx智能合约检查状态转换是否符合预定义规则来确保状态转换的有效性。
参考链接：Introduction::StarkExDocumentation
高级概述
如下图所示，StarkEx系统旨在接受来自合作伙伴后端的用户交易。这些交易随后由StarkEx系统进行批处理和处理。结合前面智能合约和后端的介绍，整个StarkEx处理交易的过程和职责分工概述如下。
Liquid Staking的TVL上升至141亿美元:金色财经报道，据DeFi Llama数据，Liquid Staking的 TVL 上升至 141 亿美元，成为第二大加密市场领域。DeFi 借贷协议的 TVL 为 137 亿美元，位居第三，而去中心化交易所以 194 亿美元的TVL位居榜首。[2023/2/27 12:32:22]
前端，StarkEx客户支持两类操作，链上和链下。前者是标准的以太坊交易，用户直接通过StaarkEx合约进行存款取款，后者是通过StarkEx引擎执行的操作，如dydx等。
订单验证，由StarkEx客户的后端设置并进行验证。
业务逻辑，客制化StarkEx合约来支持客户业务逻辑
交易流，传输到StarkEx的所有交易都使用称为tx_ids的连续标识符进行验证和索引，类似nonce的做法，
交易发送方，一旦StarkEx网关确认交易正确就会保证执行它，并且将在前端提前显示给用户，而不是等待链上最终确定。
错误处理，如果检测到无效交易，StarkEx系统将会向客户的专业端点报告错误，客户将会以另外的要执行的交易列表来代替无效交易，如空列表等。
批处理审核，任何批次在链上传输之前可以被客户审核，如果和预期状态转换和不一致，客户可以不批准或者回滚。
抗审查，如果客户审查用户请求，StarkEx允许用户直接通过?StarkEx合约执行操作，客户必须在规定时间内向用户提供它，否则StarkEx合约将会冻结。
参考文档：StarkExPartnerIntegration::StarkExDocumentation
StarkNet：通用ZKR
简介
不同于为不同的应用定制ZKRollup的StarkEx，StarkNet是一个通用的ZKRollup，开发者可在StarkNet上部署应用。
基本介绍
在以太坊上，每提交一笔交易都需要所有节点检查、验证并执行交易来保证计算正确性，并将计算后的状态变化在网络中广播。
https://ethereum.org/zh/developers/docs/evm/?
StarkNet仅在链下执行计算并生成一个ZK证明，然后在链上验证该证明的正确性，最后把多个L2交易打包为以太坊上的一笔交易。因此，StarkNet上发生的交易成本可以被同一打包批次的其他交易所均摊，就像拼车一样，交易越多，成本越低。
除此之外，相比以太坊让每个节点完整执行交易的方法，StarkNet为交易生成ZK证明的方法可以大大提高网络运行速度、减少链上通信量、增加网络吞吐，因此StarkNet相比以太坊具有更高TPS和更低Gas。
简而言之，将验证计算正确性比喻为老师需要检查同学们是不是掌握了知识。以太坊的方法是检查每个同学是否能背诵整本教科书，而StarkNet的方法是让同学们做卷子。后者的效率更高，成本更低，但仍然保证安全。
Arista Networks为数据驱动的云网络扩展EOS网络堆栈架构:11月3日消息，随着EOS Network Data Lake（NetDL）的引入，Arista Networks宣布了对Arista EOS网络堆栈的下一个重大扩展。加上AI/ML驱动的自动虚拟助手（Arista AVA）和广泛生态系统，Arista正在扩展EOS网络堆栈架构，为下一个数据驱动网络时代提供高保真数据湖功能。（Helpnet Security）[2021/11/3 6:28:59]
EVM兼容
StarkNet网络本身不兼容EVM，而设计了另外一套ZK友好的CairoVM。
StarkNet没有和Hermez和Scroll一样针对以太坊操作码做ZK电路，而是自己做了一套更加ZK友好的汇编语言、AIR以及高级语言Cairo。
StarkNet属于Vitalik定义的type4级别——语言兼容的zkEVM。
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上，字节码等效EVM。目前处于测试阶段。以太坊应用可以通过部署到Kakarot的方式移植到StarkNet。
Kakarot可以：(a)执行任意EVM字节码，(b)按原样部署EVM智能合约，(c)调用Kakarot部署的EVM智能合约的功能
Kakarot是一个EVM字节码解释器。
目前已经支持EVM全部操作码。
https://github.com/sayajin-labs/kakarot
工作原理
组成部分
StarkNet有五个组成部分。分别是在StarkNet上的Prover，Sequencer和全节点；以及部署在以太坊上的验证者和核心状态合约。
https://david-barreto.com/starknets-architecture-review/#more-4602?
当我们在StarkNet上发起一个交易，一个链下服务器——排序器将会接收、排序、验证，并将它们打包到区块。执行交易，然后状态转换发送给StarkNetCore合约；
HashSpace无国界社交应用生态链上线发布流动性挖矿Double Star:据官方消息，HashSpace无国界社交应用生态链将于2021年7月19日9：00（GMT+0）上线“Double Star”Defi应用。“Double Star”是基于HS-Chain开发的去中心化金融应用，旨在帮助HS持有者可以通过质押HS流动性获得HashSpace平台的BTC分红。
HashSpace是一个免VPN的区块链社交应用生态，目前内测期间全球用户已突破30万+，上线5款应用及跨链钱包。旨在打造区块链世界的社交、应用、支付综合生态。[2021/7/18 1:00:52]
证明者将为交易生成证明，并发送给以太坊的验证者合约；
验证者将验证结果发送到以太坊上的StarkNetCore合约，并从StarkNetCore合约触发一组新的以太坊交易，以更新链上的全局状态以进行记录保存。状态事务作为“calldata”来发送，以节省L1事务gas。这些“metadata”可被StarkNet全节点解密。
全节点基本发挥存储功能。全节点存储状态改变、元数据、证明以及记录在StarkNet中的已被执行的所有事务，并跟踪系统的当前全局状态。在有必要的时候，全节点将解密“metadata”来重构StarkNet的历史。
参考StarkNet开发倡导者?@barretodavid写的《StarkNet’sArchitectureReview》。
浏览器?https://testnet.starkscan.co/，L2?动态出块，以太坊一小时结算
账户抽象与交易模型
不同于以太坊EOACA的双账户设计，StarkNet实现了原生账户抽象，只有一种账户设计，借鉴了EIP4337的精神，
下图为交易模型，
https://community.starknet.io/t/starknet-account-abstraction-model-part-1/781?
原生账户抽象为账户可编程打开大门，StarkNet的开发倡导者@barretodavid提到StarkNet上实现手机硬钱包的思路。
以太坊上的EOA仅支持Secp?256?k?1椭圆曲线上的签名方案ECDSA
大部分的智能手机都不支持以太坊的椭圆曲线。
所以移动钱包需要依靠软件签署交易，移动钱包因此是热钱包。
StarkNet原生账户抽象，支持多种椭圆曲线，签名验证高度可编程，因此基于StarkNet/Cairo的手机钱包完全可以变成硬钱包。
Cairo已经有一个?nistp?256?的实现
https://github.com/spartucus/nistp?256-cairo
简单来讲就是直接调用手机的加密模块来对交易进行“硬签名”。
动态 | 600枚BTC从Bitstamp交易所转出 价值538.4万美元:WhaleAlert数据显示，北京时间01月28日07:09, 600枚BTC从Bitstamp交易所转入3LRHZZ开头地址，按当前价格计算，价值约538.4万美元，交易哈希为：3d546ac16cd367bcc6d7c126ea7b89eb1e3a0e010abb67fa7dece7d9cc96f5c2。[2020/1/28]
STARK
目前有许多不同的证明系统，如Halo、PLONK、Groth?16、Groth?09、Marlin、Plonky?2等，它们都属于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”。
动态 | 美国亿万富翁Stanley Druckenmiller表示不会对比特币进行任何投资:据cointelegraph消息，美国亿万富翁Stanley Druckenmiller最近在接受采访时表示自己不会对比特币进行任何长期或短期的投资。他曾经表示，比特币作为一种交易手段的概念应该被抹去，因为在这种大的波动性下，人们不可能进行交易尤其是零售交易。[2019/6/4]
换句话说，一个递归STARK证明者可为一个陈述生成一个证明，即系统的状态可以从a移到a?1?。因为证明者已经验证了一个证实a的计算完整性的(递归)证明，并且忠实地执行了状态a的计算，达到了新的状态a?1?。简而言之，你可以理解该过程将a和a?1两个证明合并为了一个证明**。如下图所示：**
https://medium.com/starkware/recursive-starks-78?f?8?dd?401025?
CairoVM：验证计算正确性
CairoVM概述
有时候也通过StarkNetOS/CairoOS的方式出现，是一个东西，不同于EVM执行计算，CairoVM本身仅为计算生成证明并验证正确性。
CairoVM是一个是一个采用冯诺依曼架构的CPUVM，其编程语言也叫Cairo，Cairo语言基于Cairo汇编，因此编译效率非常高。Cairo是CPUAlgebraicIntermediateRepresentation的首字母缩写。CairoVM包含单个AIR来验证这个「CPU」的指令集。
关于工作方式，它根据收到的输入的交易来更新系统的L2状态。促进StarkNet合约的执行。操作系统是基于?Cairo?的，本质上是使用STARK证明系统对其输出进行证明和验证的程序。StarkNet合约可用的具体系统操作和功能可作为对操作系统的调用。
Cairo语言概述
Cairo是StarkNet的智能合约语言，基于STARK设计，Cairo程序可生成STARK证明。
Cairo程序是汇编代码的集合，Cairo开发人员将以高级语言Cairo来编写智能合约而非Cairo汇编。当我们写了一个Cairo程序，Cairo编译器会将Cairo代码编译成Cairo汇编，Cairo汇编器将采用汇编代码生成Cairo字节码以在CairoVM执行，当他最终运行到真实机器上还需要编译为操作码和机器代码。
非确定性计算
Cairo程序的目标是验证某些计算是正确的，因此可以相比那些确定性计算走捷径。它意味着为了证明一个计算，验证者可以做一些不属于计算的额外工作。
例如，证明?x=?961?的平方根?y?是在?0,?1,…,?100?的范围内。直接的方法是写一个复杂的代码，从961开始，计算它的根，并验证这个根是否在所要求的范围内。
伪代码如下：猜测?y?的值。计算?y?2?并确保其结果等于?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。
是一个并行状态机。
内存模型：只读非确定性
只读的非确定性内存，这意味着每个内存单元的值由证明者选择，它不能随时间改变，是不可变的。该指令只能从中读取。我们可以将之视为一次写入的存储器：可以向一个单元写一次值，但事后不能改变它。
而且它是连续的，如果有空会被任意值填充。
ROM优点包括
低成本，电路比RAM更简单
永存储，
不可篡改，数据不能修改和删除
内置函数：减少代码编译
开发者直接调用内置函数可以减少计算开销，优化开发体验，而不需要代码转换。添加内置函数不会影响CPU约束。这只是意味着相同的内存在CPU和内置函数之间共享，如图所示。
https://medium.com/@pban/demystifying-cairo-white-paper-part-i-b?71976?ad?0108?
Cairo体系结构没有指定一组特定的内置函数。可以根据需要在AIR中添加或删除内置函数。
CPU架构：灵活
更加灵活，可以通过软件编程的方式无限接近AISC的性能。以Cairo复刻其他虚拟机。
启动加载：从哈希加载程序
程序可以将另一个程序字节码写入内存，并让ProgramCounter指向该内存段，然后运行该程序。一个从哈希启动加载的用例是，一个被称为启动加载器的程序计算并输出另一个程序的字节码，然后像之前一样开始执行它。这样验证者只需要知道程序的哈希而非完整字节码。这有两个好处：
可扩展性，验证时间和程序大小呈现对数关系，正如STARK部分提到的。
隐私性，验证者可以验证程序是否正确执行而无需知道计算。
连续记忆：连续访问内存地址
Cairo有一个技术要求，程序访问的内存地址必须是连续的。例如，如果访问地址7和9?，那么在程序结束之前也必须访问8?。如果地址范围中存在小间隙，证明者将自动用任意值填充这些地址。通常，存在这样的间隙是低效的，因为这意味着内存在未被使用的情况下被消耗。引入太多的漏洞可能会使证明的生成对于诚实的证明者来说过于昂贵而无法执行。然而，这仍然没有违反可靠性保证——无论如何都不会产生错误的证明。
StarkNet生态
盘点StarkNet生态：
https://h?0?m?83?hhc?6?r.feishu.cn/docx/doxcnS?3?GGdXXc?1?PzKh?9?uTgTR?73?c
全链游戏
全链游戏——生产效率消费体验的变革，基本上，有思考，有实践，有资金，最重要的是有一个富有活力的开发者社区。
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/game?2?
重点推荐Topology团队，Lootreamls。
合约钱包
合约钱包变成硬钱包的实现方法有两种。
共识层支持手机硬件。在StarkNet这样原生账户抽象的L2上，支持多种椭圆曲线，而不是和以太坊一样只支持ECDSA，因此可以让手机的加密芯片/模块直接对交易签名。因此，在原生账户抽象的L2上，合约钱包可以和硬钱包一样直接通过硬件签署交易。
钱包层进行签名转录。在以太坊这样非原生账户抽象的网络上，合约钱包可以签名转录。像EIP-4337可以自定义验证逻辑，用户用手机硬件支持的算法签名后再转换为以太坊支持的ECDSA。
StarkNet的开发倡导者@barretodavid，提到的在StarkNet上实现手机硬钱包的思路。
以太坊上的EOA仅支持Secp?256?k?1椭圆曲线上的签名方案ECDSA
大部分的智能手机都不支持以太坊的椭圆曲线。
所以移动钱包需要依靠软件签署交易，移动钱包因此是热钱包。
StarkNet原生账户抽象，支持多种椭圆曲线，签名验证高度可编程，因此基于StarkNet/Cairo的手机钱包完全可以变成硬钱包。
https://twitter.com/barretodavid/status/1563584823884935168?
Cairo已经有一个(
)的实现。
合约钱包全链游戏的耦合，开辟了钱包DeFi之外的新场景。Argent、Cartridge.gg正在做。
链上?AI
目前有2个机器学习项目，ML平台Giza和链上交易机器人StarkNet中文群还有另外一个。
ModulusLabs：https://www.moduluslabs.xyz/
Giza-MachineLearningintheBlockchain：
https://gizatech.xyz/
StarkNetdecentralization:Kickingoffthediscussion
mirror.xyz：https://community.starknet.io/t/starknet-decentralization-kicking-off-the-discussion/711?
总结下StarkNet与AIML为何如此登对？ZKP允许AIML链下计算，将生成证明交由他人验证。
应用范围包括：游戏、预言机、交易、反女巫、KYC、数据隐私；AI模型算力挖矿。
致谢
本文由?HackerDojo?资助和创作。HackerDōjo?是由?Hacker?共建的加密、Web3前沿技术开源知识社区。
感谢创作者?Maxlion?及?HackerDojo。
原文链接：https://community.dorahacks.io/t/starkware/272?
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。