IIRC rust vm 將在年底包含在 1.0 版本中
定序器並行化#
我們路線圖的第一步是將並行化引入交易執行。這是在昨天在主網上發布的 StarkNet alpha 0.10.2 中引入的。我們現在深入了解什麼是並行化。
那麼「交易並行化」是什麼意思呢？天真地，並行執行一個交易塊是不可能的，因為不同的交易可能是相互依賴的。這在以下示例中進行了說明。考慮一個包含來自同一用戶的三筆交易的區塊：
- 交易 A：將 USDC 換成 ETH
- 交易 B：為 NFT 支付 ETH
- 交易 C：USDT 換 BTC
顯然，Tx A 必須在 Tx B 之前發生，但 Tx C 完全獨立於兩者並且可以並行執行。如果每筆交易需要 1 秒來執行，那麼通過引入並行化，出塊時間可以從 3 秒減少到 2 秒。
問題的症結在於我們事先並不知道交易的依賴關係。實際上，只有當我們從示例中執行事務 B 時，我們才能看到它依賴於事務 A 所做的更改。更正式地說，這種依賴性源於事務 B 從事務 A 寫入的存儲單元中讀取這一事實。我們可以將交易視為形成一個依賴圖，其中存在從交易 A 到交易 B 的一條邊，當且僅當 A 寫入一個由 B 讀取的存儲單元，因此必須在 B 之前執行。下圖顯示了一個這種依賴圖的示例：
在上面的示例中，每一列都可以並行執行，這是最佳安排（天真地，我們會順序執行事務 1-9）。
為了克服事先不知道依賴圖的事實，我們本著 Aptos Labs 開發的BLOCK-STM的精神，將樂觀並行化引入到 StarkNet 定序器中。在這種範式下，我們樂觀地嘗試並行運行事務並在發現衝突時重新執行。例如，我們可以並行執行圖 1 中的交易 1-4，之後才發現 Tx4 依賴於 Tx1。因此，它的執行是無用的（我們相對於運行 Tx1 所針對的相同狀態運行它，而我們應該針對應用 Tx1 所產生的狀態運行它）。在這種情況下，我們將重新執行 Tx4。
請注意，我們可以在樂觀並行化之上添加許多優化。例如，與其天真地等待每次執行結束，我們可以在發現使它無效的依賴項時中止執行。
另一個例子是優化重新執行哪些交易的選擇。假設包含圖 1 中所有事務的塊被送入具有五個 CPU 內核的定序器。首先，我們嘗試並行執行交易 1-5。如果完成順序是 Tx2，Tx3，Tx4，Tx1，最後是 Tx5，那麼只有在 Tx4 已經執行完之後，我們才會發現依賴 Tx1→Tx4—— 說明應該重新執行。天真地，我們可能也想重新執行 Tx5，因為考慮到 Tx4 的新執行，它的行為可能會有所不同。然而，我們可以遍歷由執行已經終止的交易構建的依賴圖，只重新執行依賴於 Tx4 的交易，而不是僅僅重新執行現在無效的 Tx4 之後的所有交易。
Cairo-VM 的新 Rust 實現#
StarkNet 中的智能合約是在 Cairo 中編寫的，並在 Cairo-VM 中執行，該規範出現在Cairo 論文中。目前，排序器正在使用 Cairo-VM 的python 實現。為了優化 VM 實現性能，我們發起了用 Rust 重寫 VM 的工作。感謝 Lambdaclass 的出色工作，他們現在是 StarkNet 生態系統中一個非常寶貴的團隊，這項工作很快就會取得成果。
VM 的 rust 實現cairo-rs現在可以執行原生 Cairo 代碼。下一步是處理智能合約的執行和與 pythonic 排序器的集成。一旦與 cairo-rs 集成，音序器的性能有望顯著提高。
Rust 中的定序器重新實現#
我們從 python 到 rust 以提高性能的轉變不僅限於 Cairo VM。除了上述改進之外，我們還計劃用 Rust 從頭開始重寫音序器。除了 Rust 的內部優勢之外，這還為序列器的其他優化提供了機會。舉幾個例子，我們可以享受 cairo-rs 的好處，而無需 python-rust 通信的開銷，我們可以完全重新設計狀態的存儲和訪問方式（今天是基於Patricia-Trie 結構）。
其他問題
-
starknet 測試網的應用有執行軌跡限制（執行計算步驟），目前限制在 100 萬，後續會開放更高限制。
-
stark 定制化應用（類似於 starkex）可開發，但目前還沒發現生態項目方使用，因為目前生成證明代碼仍然是一個黑匣子，並未開源。要待 starkware 後續開源，這類應用才好進入市場。