DAOrayaki ｜Starkware技術架構與生態應用梳理
發表於 2023-02-23 10:57 作者： DAOrayaki_
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 上實現手機硬錢包的思路。
以太坊上的 EOA 僅支持 Secp256k1 橢圓曲线上的籤名方案 ECDSA
大部分的智能手機都不支持以太坊的橢圓曲线。
所以移動錢包需要依靠軟件籤署交易，移動錢包因此是熱錢包。
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 ｜Starkware技術架構與生態應用梳理
地址：https://www.coinsdeep.com/article/10709.html
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。