StarkNet 介紹：重點部件 Overview

Published in

Taipei Ethereum Meetup

9 min readApr 10, 2023

*Image Source:* *StarkNet Performance Roadmap*

本文會粗淺地對 StarkNet 中的重要部件進行名詞解釋，不會對程式碼部分做解釋或講太多技術成分的內容，但希望讀者對 ZK-Rollup（Validity-Rollup）有很基本的認識。

同時，由於 StarkNet 的系統設計中有很大一部分與零知識證明和 Merkle Tree 相關的資料結構有關，因此也會需要讀者大概認識什麼是零知識證明和相對 Merkle Tree，會在閱讀過程中順暢很多！未來有機會也會繼續深入各個系統部件做深入討論。

Author: ChiHaoLu(chihaolu.eth) @ imToken Labs

Intro

StarkNet OS（Operating System）主要由 Cairo 這個 StarkNet 的原生語言寫成，Cairo 就像 StarkNet 上的 Solidity，能夠用來撰寫（Cairo-based）智能合約，但同時也是一個零知識證明語言，可以用於構建 StarkNet 核心的作業系統和各種功能。

所有在 StarkNet 這條鏈上的邏輯都會被包含在 StarkNet OS 中，例如如何定義帳戶狀態、交易原理、合約執行，甚至是如何進行位元運算、雜湊運算和原生的簽章演算法等，都會定義在這裡。

概括來說，OS 需要在交易與合約接收 input 之後產出 output，並且將這個 output 更新在 StarkNet 這個 L2 的狀態（State）中。

那為什麼要使用零知識證明語言來撰寫 StarkNet OS 呢，而不是其他常見語言？

相信大家都知道擴容的其中一個大方向就是「把繁雜的計算丟到 Off-Chain 並且只要在 On-Chain 做驗證即可」，而 StarkNet 作為 ZK-Rollups 一員，他會將 Cairo 撰寫的 ZK-STARK Program 執行完的內容透過 STARK-proof system 進行證明（prove）與在 Ethereum 進行驗證（verify）。

如果看到這裡還不是非常了解也沒關係，接下來幾個小節會依序補完這些名詞解釋跟使用場景！

StarkNet Stack

StarkNet 的系統架構我認為有三個重點，Sequencer、Prover & Verifier 和 L1 Core Contract。另外還有原生 AA 設計的 User Account、Full Node、Fact Register 等部件，但這篇文我們先著重在前三個重點的概括介紹上。

StarkNet Sequencer

StarkNet 作為一個 Rollups 沒有類似過往我們認識的礦工角色存在，但依舊需要一個角色來 「驗證交易」、「決定交易順序」、「構建區塊」，而負責這三者工作內容的人就是 Sequencer。

Sequencer 是一個 off-chain server，工作流程的第一步是接收用戶送上來的交易（數筆來自不同用戶的不同交易），之後 Sequencer 會決定交易順序並且構建 L2 的區塊。

Sequencer 需要確認交易是被帳戶擁有者授權的（由於 StarkNet 使用了原生 AA 的帳戶系統，因此這裡不一定是單純確認簽章正確，有可能是多簽或其他驗證邏輯）。接著透過 StarkNet OS 執行一次交易，概念上就像 EVM 一樣，接收 input 後執行合約邏輯並產出 output。

Sequencer 執行過交易這件事情會生產出一個 trace（需要注意這個 trace 不是 function return 而是一個執行過程的見證），並將這些執行內容的 「過程見證」 送去給 Prover 讓其生產證明。也就是告訴大家：「我執行過這段程式碼囉。」。

在我們接下來要講的 Prover 和 Verifier 驗證成功之後，Sequencer 會更新 L1 StarkNet Core Contract 中的狀態。

StarkNet Prover & Verifier

Prover 同樣也是一個 Off-Chain Server，這個角色主要就是接收 Sequencer 執行完程式碼產生的 trace，並且生產出相對應的 STARK proofs，然後交給在 L1 上的 Verifier Contract 驗證，驗證通過之後會註冊 fact 供未來的 L1 StarkNet Core Contract 進行查詢。

Verifier Contract 會在 L1 上負責驗證以上一切是否是合法的，他會接受 input 以及 STARK Proof 來決定。

補充說明：目前 StarkNet 中只有一個 Prover，不僅為 StarkNet 生成證明，還為運行在 StarkWare 自己的 StarkEx rollup 上的所有其他應用程序（例如 Immutable X、dYdX、Sorare 等）生成證明。這就是為什麼該服務被稱為 Shared Prover 或 SHARP 的原因。

StarkNet L1 Core Contract

StarkNet L1 Core Contract 儲存著 L2 上狀態們的證明，大家常常說 Rollups 的安全性是由 Ethereum 這個 L1 保證的就是來自於此。當我們的 trace 經過 Prover 產生 proof 並且在 L1 Verifier Contract 驗證之後，就會告訴 L1 Core Contract 這個「狀態更新」是正確無誤的。

「狀態更新」指的是在 StarkNet 執行交易之後會改變狀態，而我們要想辦法正確地傳達給 L1 Core Contract 説 L2 上的狀態從 S 更新成 S’ 了。

當 L1 Core Contract 透過 Verifier 知曉了此次的狀態更新是合法後，Sequencer 就會在合約中更新 State Root。

換句話說，知道「這次狀態更新是合法」的意思是，我們透過 ZKP 證明了鏈下的運算是真的被正確執行了，而不是瞎掰出來一個隨便的交易結果就叫 L1 Core Contract 更新狀態。

此外如果 StarkNet 在 L1 有一些 operations 需要定義，也會定義在 StarkNet L1 Core Contract 中，例如：

官方認可的 Verifiers Contract（Addresses List）
L1 ↔ L2 互動的邏輯（訊息傳遞的方式）

Discussions

Decentralization & Open Source

Rollups 中的 Sequencer 或像是 Prover 這樣的角色被該鏈的官方把持著其實會引來社群的質疑，因此對長遠發展來說其實開源是非常重要的。不僅僅是有更多雙眼睛可以審視這個 code，也可以因為社群的協作和貢獻讓系統更安全、有效率。退一萬步來說，社群還能夠獨立地開發並維護整個網路。

所謂的去中心化在 StarkNet 社群有兩個主要討論層面：

不需許可就能運作的 Sequencers 和 Provers 可以確保這個網路是抗審查的（censorship-resistant）。
因為使用了 STARK-proofs，任何人都可以用很低的硬體成本來驗證整條鏈的正確性，同時也不需要信任任何第三方單位。

當前 StarkNet 已經開源了最新的 Sequencer，Prover 也即將開源，有興趣的人可以查看以下資源：

Performance & Bottleneck

StarkNet 運作的效能和 Gas Fee 在這幾個月我自己用下來，其實沒有非常好（有時候甚至到差或完全不能用的地步），但 StarkNet 官方表示過往他們都著重在 Functionality 上，現在（Cairo 1.0 即將上線之後）已經做好了基礎建設，將會把開發重心移動到效能上。

StarkNet 認為提高 TPS 最好的方向是在同樣的出塊時間下，提高能夠容納的交易量，也就是區塊限制。因此只要是跟區塊產生有關的部件都會需要提升效率。例如 Sequencer 就是這其中最大的瓶頸，所以才有規劃未來改成不同演算法（從先到者先處理改為平行化處理）、不同資料結構（原本是 Patricia-Trie），以及用 Rust（原本是 python）寫成的新 Sequencer — Blockifier。

新的平行化 Sequencer 可參考以下資源：

關於這個議題，StarkNet 提出了一個說法解釋為何提高區塊限制對 L2 有用，而對 L1 沒用。原因是如果區塊大小太大，我們對全節點的要求就越高（這樣他們才可以跟上鏈的增長速度並且進行驗證）。如果這個要求高到大部分用戶都沒辦法負擔，無法自行驗證，那就使得絕大部份人都需要以一個不信任的方式參與網路。

Closing

撰寫 StarkNet 的介紹文時需要不少的 Reference，我盡量把所有參考到的內容都附上（文中或文末），希望能給願意深入了解的人們提供幫助，也非常感謝這麼多善心人士願意分享自己對 StarkNet 的研究結果！

Special thanks to NIC Lin for reviewing this post.