詳解Starkware技術架構與生態應用梳理

‍原文：《 DAOrayaki ｜Starkware技術架構與生態應用梳理》

出品：HackerDojo

原文作者：Maxlion，Starknet Astro

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 等。

整體架構

工作流包括以下四個環節

1. 打包交易：鏈下服務器處理客戶請求，將多個交易組合成一個“批次”，供StarkEx 處理。
2. 確認交易和更新狀態：鏈下服務器確認交易合法，並以被壓縮後的哈希形式更新系統狀態。
3. 為交易生成證明：完成上述流程後，SHARP 會為交易生成STARK 證明以確認交易的有效性。然後將證明和更新發送到鏈上Verifier 智能合約，以確保交易的完整性。
4. 鏈上驗證證明：一旦STARK證明被驗證，狀態更新被提交並結算回以太坊主網。所有交易都是在鏈外處理和驗證的，而其完整性的證明是在鏈上驗證的。

SHARP 是一個共享證明者，它同時為多個StarkEx 客戶/應用提供證明生成服務——生成計算完整性聲明的證明。

Verifier 是部署在以太坊上的智能合約，用於驗證來自StarkEx 的交易的正確性。

StarkWare Applications

StarkEx 應用程序（圖中Exchange）是一系列支持可擴展和自我託管交易的應用程序，區分現貨交易和槓桿交易。應用包括兩個組件，智能合約和後端。

標準流程

1. 用戶發起交易，交易可以直接與智能合約交互
2. 每個交易都有一個唯一的id，共同組成一個交易流，StarkEx 應用將交易流傳輸到後端
3. 後端將狀態轉換提交給SHARP，SHARP 為狀態轉換生成證明
4. SHARP 向驗證者合約提交證明並在驗證者完成驗證後，驗證者將之記錄在Verifier Fact Registry，然後後端將在StarkEx 智能合約上執行狀態轉換。
5. StarkEx 智能合約檢查狀態轉換是否符合預定義規則來確保狀態轉換的有效性（通過驗證者合約）。

參考鏈接：Introduction :: StarkEx Documentation

高級概述

如下圖所示，StarkEx 系統旨在接受來自合作夥伴後端的用戶交易。這些交易隨後由StarkEx 系統進行批處理和處理。結合前面智能合約和後端的介紹，整個StarkEx 處理交易的過程和職責分工概述如下。

1. 前端，StarkEx 客戶支持兩類操作，鏈上和鏈下。前者是標準的以太坊交易，用戶直接通過StaarkEx 合約進行存款取款，後者是通過StarkEx 引擎執行的操作，如dydx 等。
2. 訂單驗證，由StarkEx 客戶的後端設置並進行驗證。
3. 業務邏輯，客制化StarkEx 合約（子合約）來支持客戶業務邏輯
4. 交易流，傳輸到StarkEx 的所有交易都使用稱為tx_ids 的連續標識符進行驗證和索引，類似nonce 的做法，
5. 交易發送方，一旦StarkEx 網關確認交易正確就會保證執行它（不是真的立即執行），並且將在前端提前顯示給用戶，而不是等待鏈上最終確定。
6. 錯誤處理，如果檢測到無效交易，StarkEx 系統將會向客戶的專業端點報告錯誤，客戶將會以另外的要執行的交易列表來代替無效交易，如空列表等。
7. 批處理審核，任何批次在鏈上傳輸之前可以被客戶審核，如果和預期狀態轉換和不一致，客戶可以不批准或者回滾。
8. 抗審查，如果客戶審查用戶請求，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。

1. Kakarot 可以：(a) 執行任意EVM 字節碼，(b) 按原樣部署EVM 智能合約，(c) 調用Kakarot 部署的EVM 智能合約的功能（視圖和寫入方法）
2. 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

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》。 【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 上實現手機硬錢包的思路。

1. 以太坊上的EOA 僅支持Secp256k1 橢圓曲線上的簽名方案ECDSA
2. 大部分的智能手機都不支持以太坊的橢圓曲線。
3. 所以移動錢包需要依靠軟件簽署交易，移動錢包因此是熱錢包。
4. 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 優點包括

1. 低成本，電路比RAM 更簡單
2. 永存儲，
3. 不可篡改，數據不能修改和刪除

內置函數：減少代碼編譯

開發者直接調用內置函數可以減少計算開銷，優化開發體驗，而不需要代碼轉換。添加內置函數不會影響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 。

合約錢包

合約錢包變成硬錢包的實現方法有兩種。

1. 共識層支持手機硬件。在StarkNet（編程語言Cairo）這樣原生賬戶抽象的L2 上，支持多種橢圓曲線，而不是和以太坊一樣只支持ECDSA（Secp256k1），因此可以讓手機的加密芯片/模塊直接對交易簽名（大部分手機不支持ECDSA）。因此，在原生賬戶抽象的L2 上，合約錢包可以和硬錢包一樣直接通過硬件簽署交易。
2. 錢包層進行簽名轉錄。在以太坊這樣非原生賬戶抽象的網絡上，合約錢包可以簽名轉錄。像EIP-4337 可以自定義驗證邏輯，用戶用手機硬件支持的算法簽名後再轉換為以太坊支持的ECDSA。

StarkNet 的開發倡導者@barretodavid，提到的在StarkNet 上實現手機硬錢包的思路。

1. 以太坊上的EOA 僅支持Secp256k1 橢圓曲線上的簽名方案ECDSA
2. 大部分的智能手機都不支持以太坊的橢圓曲線。
3. 所以移動錢包需要依靠軟件簽署交易，移動錢包因此是熱錢包。
4. StarkNet 原生賬戶抽象，支持多種橢圓曲線，簽名驗證高度可編程，因此基於StarkNet/Cairo 的手機錢包完全可以變成硬錢包。

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

Cairo 已經有一個[nistp256]( )（用於智能手機Secure Enlave）的實現。

合約錢包+全鏈遊戲的耦合，開闢了錢包+DeFi 之外的新場景。 Argent、Cartridge.gg 正在做。

鏈上AI

目前有2 個機器學習項目，ML 平台Giza 和鏈上交易機器人（Rockybot by ModulusLabs）StarkNet 中文群還有另外一個。

Modulus Labs： https://www.moduluslabs.xyz/

Giza - Machine Learning in the Blockchain：

https://gizatech.xyz/

StarkNet decentralization : Kicking off the discussion

mirror.xyz：https://community.starknet.io/t/starknet-decentralization-kicking-off-the-discussion/711

總結下StarkNet 與AI+ML 為何如此登對？ ZKP 允許AI ML 鏈下計算，將生成證明交由他人驗證。

應用範圍包括：遊戲、預言機、交易（自動收益）、反女巫、KYC、數據隱私；AI 模型算力挖礦。

致謝‍‍‍‍

本文由HackerDojo資助和創作。 Hacker Dōjo是由Hacker共建的加密、Web3前沿技術開源知識社區。

感謝創作者Maxlion及HackerDojo。

原文鏈接：https://community.dorahacks.io/t/starkware/272

DAOrayaki是一個代表社區意志的去中心化媒體平台。通過構建基礎且關鍵的去中心化媒體組件，鏈接社區內資助者、創作者、策展者和讀者，使其自由的策展、研究、創作、出版和報導各類話題。歡迎通過以下方式提交星際移民、量子計算、DAO、Web3等的相關研究並提案獲得資助！