Solana 聯合創始人：構建全域狀態機並分析 Solana 的終極架構

**詞：阿納托利·雅科文科，首席執行官（聯合創始人兼首席執行官），索拉納

編譯器：1912212.eth，遠見新聞

Solana 的目標是按照物理定律儘快同步單個無需許可的全域狀態機。 我相信能夠實現這一目標的架構將如下所示：

• 大量完整節點，超過 10,000 個（N > 10,000）

為了使網路充當全域狀態機，它需要支援大量完整節點。 Turbine 已經證明，快速複製到超大型網路可以在現代硬體和網路上擴展。

*大量的區塊生成領導者，超過10,000（N>10,000）

• 併發領導者同時生產區塊，在 4 到 16 個範圍內隨機選擇。

併發領導者使網路能夠在全球範圍內擁有多個位置來對使用者事務進行排序。 它縮短了使用者和網路之間的距離，消除了在將交易添加到鏈之前進行全節點驗證的需要。

• 區塊時間為 120 毫秒

較短的區塊時間創造了快速的終結點，增強了抗審查性，改善了用戶體驗，減少了重新排序交易的視窗，並加速了整個網路。

• 審批小組委員會中的一些投票共識節點，數量在 200 到 400 之間，是隨機選擇的，每個紀元每 4 到 8 小時輪換一次。

共識對於選擇分叉至關重要，這是由於網路分區而發生的。 200 個或更多節點的樣本將在統計上代表網路中的所有主要分區，並與其實際分佈緊密匹配。 因此，不需要所有全節點投票，200 就足夠了。 將批准限制為小組委員會，以減少支援 120 ms 塊所需的記憶體和網路頻寬。 減少區塊時間自然會增加每秒發送的投票數，給分配給共識的資源帶來一些壓力。

120ms區塊的真正挑戰是重放所有使用者交易。 由於網路是無許可的，因此很難保證一個同構的執行環境，並有可靠的時間來執行任意用戶代碼。 雖然存在這種可能性，但只能通過限制使用者事務的可用計算資源並確保每個節點都過度分配給最壞的情況來實現。

但是，沒有理由為投票支援分叉的共識節點或基於分叉構建的領導者強制執行完整狀態。 為了保持共識節點和領導者的批准同步，每個週期只需要計算一次狀態。

異步執行

動機

同步執行要求所有投票和創建區塊的節點在任何區塊中進行超級配置，以確定最壞情況下的執行時間。 異步執行是極少數權衡很少的情況之一。 共識節點可以在投票前執行更少的工作。 工作可以聚合和批處理，使其在執行中高效，而不會丟失任何緩存。 它甚至可以在與共識節點或領導者完全不同的機器上執行。 想要同步執行的使用者可以分配足夠的硬體資源來即時執行每個狀態轉換，而無需等待整個網路。

鑒於應用程式和核心開發人員的多樣性，值得每年計劃一次重大的協定更改。 如果我必須選擇一個，我的選擇將是異步執行。

概述

目前，驗證者會快速重複每個區塊上的所有交易，只有在計算出區塊的完整狀態后才能投票。 該提案的目標是將分叉的投票決定與計算區塊的完整狀態轉換分開。

在批准中投票的驗證者只需要選擇分叉;他們根本不需要執行任何狀態。 只有在每個紀元上，他們才需要狀態來計算下一個批准。

對表決程序進行了調整，以便可以獨立進行。 節點僅在投票前執行投票程式。 由於驗證器不佔用太多空間，因此記憶體需求應該相對較小。 由於投票的執行時間非常可預測，因此在執行投票程式時應該幾乎沒有抖動。

所有無投票權的交易都可以異步計算。 這允許重放批量執行所有無投票事務，提前預取和JIT所有程式，幾乎消除了所有緩存丟失。 長期目標是，只有需要即時、低延遲、完整狀態計算的計算機才會為此任務配置。 據推測，使用者將為額外的硬體付費。

一旦分叉選擇和狀態執行分開，加快速度就變得更容易了：

• 異步執行
• 每個紀元輪換固定數量的投票委員會
• 200 ms 塊時間

由於使用者交易重放不會阻止分叉選擇，因此在減去區塊時間時，波動性不再是問題。 唯一要考慮的是，在 200 毫秒時，驗證者的投票率翻倍。 對批准配額的計算方式進行相當直接的更改將使我們能夠將批准的大小固定為 200 或 400，或任何看起來合適的數位。

將執行與共識完全分開也是很自然的。 重新啟動共識節點會更快，只需要在固定大小的批准中檢查投票程序帳戶。

事實上，我相信確認時間會增加，因為絕大多數批准都會儘快投票，並且在傳播這些投票的同時，為使用者提供完整狀態執行結果的節點可以同時執行事務。 因此，我們今天看到的任何重播抖動都應該與投票網路傳播同時發生。

投票

• 投票帳戶必須有足夠的SOL數來涵蓋 2 個時代的投票。
• 投票交易必須簡單。 非簡單的投票註定會失敗。 區塊生成器應該放棄複雜的投票。 *允許從投票帳戶中提取SOL，只要餘額不下降到少於1個投票紀元。
• 為了將所有 lamport 歸零，Vote CLOSE 指令必須要求經過整個紀元。 投票帳戶在第 1 代標記為關閉，但只能在第 2 代關閉。 關閉允許您撤回所有SOL並刪除投票帳戶。 一旦帳戶被標記為關閉，它只能被完全刪除，不能重新打開。
• 投票包含 VoteBankHash 而不是常規 BankHash。

領導者監管和批准

只有驗證器符合以下條件：

• 質押金額 > X *以及SOL >2個投票時代
• 並且未標記為關閉

以進入領導者時程表並計入批准。 對於版本 2，我們可以將 LeaderSchedule 與仲裁分開，並且它們不必各自具有相同的要求。

投票銀行哈希計算

與計算所有交易的Bankhash不同，驗證者只計算與LeaderScheduler中的驗證者相關的簡單投票交易的VoteBankHash。 所有其他事務將被忽略。 重播所有投票后，VoteBankHash 的計算格式與當前 BankHash 相同。

VoteBankHash 應該累積之前的 VoteBankHash，而不是完整的 BankHash。

銀行哈希計算

對於所有樂觀確認的區塊（可為所有區塊配置），驗證器開始計算UserBankHash，其中包括所有狀態轉換，但不包括VoteBankHash計算中考慮的交易。

然後，BankHash 從 （VoteBankHash， UserBankHash） 的累積中派生出來。 前99.5%的驗證者每100個時間段提交BankHash作為投票的一部分。 雖然每 100 個時隙提交一次，但它在每個時隙計算。 值得注意的是，對於一小部分節點來說，在八卦中始終如一地提交BankHash作為軟信號，沒有觀察到非確定性信號，這可能是值得的。

如果只有不到67%的驗證者提交了完整的BankHash計算，領導者應該將使用者交易和可寫帳戶可用的區塊空間減少50%。 這項措施是為了保護鏈條免受可能過度增加重播時間的濫用。

BankHash 應該累積以前的 BankHashes。

去找銀行領導

在區塊創建過程中，領導者很可能無法獲得用於創建區塊的狀態，並且在區塊創建期間執行所有交易並不理想。

• 領導者維護已支付賬戶餘額的緩存。
• 如果付費帳戶用作系統轉移的來源，或用作與系統程式一起傳遞到另一個程式的可寫帳戶，則付費帳戶餘額設置為 0。
• 區塊根據聲明的計算單位 （CU） 按本地費用優先順序順序打包，直到區塊被填滿。
• 費用從付費帳戶餘額緩存中扣除。
• 付費帳戶餘額緩存由BankHash計算補充。

網路對交易垃圾郵件失敗的成本相對較低，僅包括存儲在存檔中的位元組和在塊中傳播交易所需的頻寬。

鑒於驗證者已經在尋求最大化他們的收入，他們有足夠的動力來維護付費帳戶的準確緩存。 此外，如果沒有懲罰，從長遠來看，任何網路中的任何人都可以輕鬆地為緩存提供服務。 在伺服器損壞的情況下，無銀行領導者操作員應該能夠輕鬆地從多個來源切換或採樣。

這意味著，由於驗證者最大化收益的動機，他們將努力維護付費帳戶的準確緩存。 在沒有懲罰機制的情況下，網路中的任何節點都可以長時間為該緩存提供服務。 此外，如果伺服器發生故障，沒有銀行負責人的操作員應該能夠輕鬆地從多個來源切換或採樣。

權衡

主要的權衡是，為用戶狀態提供服務的完整節點上缺少確認簽名，以確認其交付狀態與批准的 rest 完全相同。 狀態的唯一權威解釋應該保持不變，即使每個交易在分類賬中按順序重放。 任何性能優化都不應更改結果。 因此，一旦分叉完成，只要運行時實現沒有錯誤，就只剩下正確的狀態可以計算。

設計為可靠地提供狀態的節點應運行多台計算機和用戶端，如果狀態執行存在差異，則應停止運行。 這基本上是運營商今天應該做的事情，因為僅僅依靠網路的其餘部分會引入大多數完整性假設。

使用者還可以對斷言BankHash或觸發中止的交易進行簽名。 僅當計算出的確切BankHash與RPC供應商提供給使用者的BankHash完全相同時，網路的其餘部分才會執行這些交易。

長期無狀態共識節點路線圖

具有固定大小批准的網路只需要非常少量的狀態即可啟動。 批准本身及其質押權重，以及所有投票賬戶餘額。 這是一個非常小的內存量和一個小的快照檔，可以在重新啟動時快速分發和快速初始化。

如果審批與全節點不一致，則同時跟蹤審批和狀態的完整節點將停止運行。 這意味著，如果批准和狀態之間存在分歧，交易所、法定管道、RPC、橋接等都將停止運行。 這只需要很小比例的有缺陷的無狀態共識節點。

無銀行領導者可以依靠多個完整節點的樣本來提供付費帳戶初始餘額的緩存。 即使有缺陷，結果也會是區塊中的垃圾郵件，而不是共識失敗。 運營商應該能夠監控其領導者的健康情況以及他們注入塊的垃圾郵件百分比，並快速回應故障。