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

DAOrayaki

特邀专栏作者

2023-03-05 07:00

本文約6175字，閱讀全文需要約9分鐘

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

StarkWare

簡介

StarkEx：專有ZKR 引擎

簡介

在去年和今年上半年，StarkWare 通過提供擴容技術解決方案StarkEx 創立了擴容即服務（scaling as a service）的商業模式，建立應用專有網絡，服務業內頭部客戶dYdX 、Sorare、ImmutableX、DeversiFi 等。
整體架構
工作流包括以下四個環節
打包交易：鏈下服務器處理客戶請求，將多個交易組合成一個“批次”，供StarkEx 處理。

確認交易和更新狀態：鏈下服務器確認交易合法，並以被壓縮後的哈希形式更新系統狀態。

為交易生成證明：完成上述流程後，SHARP 會為交易生成STARK 證明以確認交易的有效性。然後將證明和更新發送到鏈上Verifier 智能合約，以確保交易的完整性。

StarkWare Applications

鏈上驗證證明：一旦STARK 證明被驗證，狀態更新被提交並結算回以太坊主網。所有交易都是在鏈外處理和驗證的，而其完整性的證明是在鏈上驗證的。

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

Verifier 是部署在以太坊上的智能合約，用於驗證來自StarkEx 的交易的正確性。
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 系統將會向客戶的專業端點報告錯誤，客戶將會以另外的要執行的交易列表來代替無效交易，如空列表等。

StarkNet：通用ZKR

簡介

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

不同於為不同的應用定制ZK Rollup 的StarkEx，StarkNet 是一個通用的ZK Rollup，開發者可在StarkNet 上部署應用。

基本介紹

在以太坊上，每提交一筆交易都需要所有節點檢查、驗證並執行交易來保證計算正確性，並將計算後的狀態變化在網絡中廣播。

除此之外，相比以太坊讓每個節點完整執行交易的方法，StarkNet 為交易生成ZK 證明的方法可以大大提高網絡運行速度、減少鏈上通信量、增加網絡吞吐，因此StarkNet 相比以太坊具有更高TPS 和更低Gas。

EVM 兼容

簡而言之，將驗證計算正確性比喻為老師需要檢查同學們是不是掌握了知識。以太坊的方法是檢查每個同學是否能背誦整本教科書，而StarkNet 的方法是讓同學們做卷子。後者的效率更高，成本更低，但仍然保證安全。

EVM 兼容

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

StarkNet 網絡本身不兼容EVM ，而設計了另外一套ZK 友好的Cairo VM 。

StarkNet 沒有和Hermez 和Scroll 一樣針對以太坊操作碼做ZK 電路，而是自己做了一套更加ZK 友好的彙編語言、AIR（代數中間表示）以及高級語言Cairo。

StarkNet 屬於Vitalik 定義的type 4 級別——語言兼容的zkEVM（StarkNet 由於定制了虛擬機嚴格來講屬於zkVM）。

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

1、Warp：將Solidity 轉譯為Cairo 語言的轉譯器

Warp 是一個Solidity-Cairo 轉譯器，目前已經由以太坊著名基礎設施團隊Nethermind 開發完成。 Warp 可以把Solidity 代碼轉譯為Cairo，但轉譯後的Cairo 程序往往需要修改並增添Cairo 特性（如調用內置函數，優化內存等）才能最大化執行效率。
2、Kakarot：一個用Cairo 語言編寫的zkEVM

目前已經支持EVM 全部操作碼。

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

工作原理

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

工作原理
組成部分
StarkNet 有五個組成部分。分別是在StarkNet 上的Prover（證明者），Sequencer（排序器）和全節點；以及部署在以太坊上的驗證者（Verifier）和核心狀態合約（StarkNet Core）。

當我們在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 動態出塊，以太坊一小時結算

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

賬戶抽象與交易模型

不同於以太坊EOA+CA 的雙賬戶設計，StarkNet 實現了原生賬戶抽象，只有一種賬戶設計，借鑒了EIP 4337 的精神，
下圖為交易模型，
原生賬戶抽象為賬戶可編程打開大門，StarkNet 的開發倡導者@barretodavid 提到StarkNet 上實現手機硬錢包的思路。
以太坊上的EOA 僅支持Secp 256 k 1 橢圓曲線上的簽名方案ECDSA

大部分的智能手機都不支持以太坊的橢圓曲線。

https://github.com/spartucus/nistp 256-cairo

所以移動錢包需要依靠軟件簽署交易，移動錢包因此是熱錢包。

STARK

StarkNet 原生賬戶抽象，支持多種橢圓曲線，簽名驗證高度可編程，因此基於StarkNet/Cairo 的手機錢包完全可以變成硬錢包。

Cairo 已經有一個nistp 256 （用於智能手機Secure Enlave）的實現

簡單來講就是直接調用手機的加密模塊來對交易進行“硬簽名”。

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

目前有許多不同的證明系統（生成和驗證證明），如Halo、PLONK、Groth 16、Groth 09、Marlin、Plonky 2 等，它們都屬於SNARK 證明系統。證明系統存在一個證明者生成證明，一個驗證者驗證證明。而不同的ZK 項目幾乎都會使用不同的證明系統，StarkNet 使用的STARK 某種意義上屬於一種特別的SNARK 。

STARK 相比SNARK 有更多創新。它不需要和SNARK 一樣依賴“可信設置”。它還帶有更簡單的密碼學假設，避免了對橢圓曲線、配對和指數知識假設的需要，純粹依賴哈希和信息論，因此抗量子攻擊。總體來講STARK 比SNARK 更安全。

在擴展性方面，STARK 的擴展性更強。證明生成速度具備線性擴展性，驗證時間和證明大小具備對數擴展性。但缺點在於生成的證明尺寸更大。但隨著證明規模增加，驗證成本將會邊際遞減——這意味證明越大，總成本越低。

總結一下，相比SNARK，STARK 更安全，平均驗證時間和證明大小將隨著驗證規模擴大而降低，缺點在於初始證明尺寸更大，因此更適合大規模應用。

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

擴展性詳解

證明時間線性擴展：證明人花費的時間與哈希調用的數量呈近似線性關係。

在80 比特的安全級，STARK 每12288 次哈希調用的證明者執行時間為1 秒，得12288 次/S；而每98304 次哈希調用需要10 秒，得9830 次/S，因此，我們可以知道STARK 的證明時間和哈希調用基本呈近似線性關係。如下圖所示

**驗證和證明大小對數擴展：驗證時間（與證明大小）與哈希調用呈現對數關係。 **如下圖所示："遞歸證明"或者

任何通用的、簡潔的知識系統的證明/論證（特別是STARKs）都可以用來遞增地驗證計算。這意味著一個計算可以產生一個證明，以證明該計算的前一個實例的正確性，這個概念被非正式地稱為“遞歸證明組合

https://medium.com/starkware/recursive-starks-78 f 8 dd 401025

或者

換句話說，一個遞歸STARK 證明者可為一個陳述生成一個證明，即係統的狀態可以從a 移到a+ 1 。因為證明者已經驗證了一個證實a 的計算完整性的(遞歸)證明，並且忠實地執行了狀態a 的計算，達到了新的狀態a+ 1 。簡而言之，你可以理解該過程將a 和a+ 1 兩個證明合併為了一個證明。如下圖所示：

Cairo VM 概述

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 的值（這是不確定的部分）。計算y 2 並確保其結果等於x。驗證y 是否在範圍內。並且，如果我們採取以下的計算方式。 Y = SQRT(X)我們可以改為計算如下（非確定性計算）。 Y*Y=X

我們可以看到，有兩種可能的解決方案。 +Y 和-Y，而且有可能只有其中一個能滿足其餘的指令。

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

這意味著，如果沒有一些額外的信息，一些開羅程序（如上述）是無法有效執行的。這種信息由我們稱之為提示的東西提供。提示是Cairo Runner 的特殊指令；用於解決不能輕易推導出數值的非確定性問題。理論上，提示可以用任何編程語言編寫。在當前的Cairo 實現中，提示是用Python 寫的。

關於確定性和非確定虛擬機，witness

Cairo 在這裡其實也會涉及到有確定性的Cairo VM 和非確定性的Cairo VM。前者就是正經的zkVM，證明和驗證；後者用於非確定性計算。

Cairo 確定性VM 的一個可接受的輸入構成了非確定性VM 的witness，ZKP 需要將witness 作為輸入輸出proof。（NP 語句的witness 見證是一條信息，可讓您有效地驗證該語句是否真實。例如，如果聲明某個圖中存在哈密頓環，則見證就是這樣的環。給定一個環，可以有效地檢查它是否是一個有效的哈密頓環，但是找到這樣的環很困難）

是一個並行狀態機。

內存模型：只讀非確定性

只讀的非確定性內存，這意味著每個內存單元的值由證明者選擇，它不能隨時間改變（在Cairo 程序執行期間），是不可變的。該指令只能從中讀取。我們可以將之視為一次寫入的存儲器：可以向一個單元寫一次值，但事後不能改變它。

而且它是連續的，如果有空會被任意值填充。

ROM 優點包括

低成本，電路比RAM 更簡單

永存儲，

https://medium.com/@pban/demystifying-cairo-white-paper-part-i-b 71976 ad 0108

不可篡改，數據不能修改和刪除

內置函數：減少代碼編譯

開發者直接調用內置函數可以減少計算開銷，優化開發體驗，而不需要代碼轉換。添加內置函數不會影響CPU 約束。這只是意味著相同的內存在CPU 和內置函數之間共享，如圖所示。

Cairo 體系結構沒有指定一組特定的內置函數。可以根據需要在AIR （代數中間表示）中添加或刪除內置函數。

CPU 架構：靈活

更加靈活，可以通過軟件編程的方式無限接近AISC 的性能（所以Cairo 會做CPU？）。以Cairo 復刻其他虛擬機。
啟動加載：從哈希加載程序

程序可以將另一個程序字節碼寫入內存，並讓Program Counter 指向該內存段，然後運行該程序。一個從哈希啟動加載的用例是，一個被稱為啟動加載器的程序計算並輸出另一個程序的字節碼，然後像之前一樣開始執行它。這樣驗證者只需要知道程序的哈希而非完整字節碼。這有兩個好處：

可擴展性，驗證時間和程序大小呈現對數關係，正如STARK 部分提到的。

隱私性，驗證者可以驗證程序是否正確執行而無需知道計算。

盤點StarkNet 生態：

https://h 0 m 83 hhc 6 r.feishu.cn/docx/doxcnS 3 GGdXXc 1 PzKh 9 uTgTR 73 c

全鏈遊戲

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/game 2

全鏈遊戲

全鏈遊戲——生產效率+消費體驗的變革，基本上，有思考（各個機構和團隊的文章），有實踐（鏈上游戲項目和黑客松），有資金（融資和grant），最重要的是有一個富有活力的開發者社區。

重點推薦Topology 團隊，Lootreamls 。
合約錢包

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

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

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

大部分的智能手機都不支持以太坊的橢圓曲線。