Solana共同創辦人：打造全球狀態機，解析Solana的終極架構

Solana 目标是在符合物理法则下，尽快同步单一、无需许可的全球状态机。

撰文：Anatoly Yakovenko，Solana執行長( 共同創辦人兼CEO)

編譯：1912212.eth，Foresight News

Solana 目標是在符合物理法則下，盡快同步單一、無需許可的全球狀態機。我相信能夠實現這一目標的架構將如下所示：

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

為了使網路作為全球狀態機運行，它需要支援眾多全節點。 Turbine 已經證明在現代硬體和網路上，快速複製到非常龐大的網路是可擴展的。

• 大量區塊生成領導者，超過10,000 個（N > 10,000）
• 並發領導者同時產生區塊，隨機選擇在4 到16 的範圍內。

並發領導者使網路能夠在全球範圍內擁有多個位置來排序用戶交易。可以減少用戶與網路之間的距離，消除了在交易被添加到鏈上之前，需要全節點驗證的需求。

• 區塊時間為120 毫秒

短區塊時間創建了快速的最終性點，增強了抗審查能力，提高了用戶體驗，減少了重新排序交易的窗口，並整體加速了網路。

• 在核准分委員會中的一些投票共識節點，數量在200 到400 之間，隨機選擇領導者，每個epoch 4 到8 個小時輪換一次。

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

120 毫秒區塊中的真正挑戰是回放所有用戶交易。由於網路是無需許可的，保證具有可靠時間執行任意使用者程式碼的同質化執行環境是極其困難的。雖然存在可能性，但只能透過限制用戶交易的可用運算資源，並確保每個節點都超配到最壞情況的情況。

不過，對於投票支持分叉或在分叉上建立的領導者的共識節點，沒有理由執行完整狀態。為了保持共識節點和領導者的核准同步，狀態只需要在每個期間計算一次。

非同步執行

動機

同步執行要求所有投票和創建區塊的節點在任何區塊中都要超高配置，以確定最壞情況的執行時間。非同步執行是極少數幾乎沒有權衡的情況之一。共識節點在投票之前可以執行較少的工作。工作可以聚合和批次，使其在執行時高效，沒有任何快取遺失。它甚至可以在與共識節點或領導者完全不同的機器上執行。希望進行同步執行的使用者可以分配足夠的硬體資源，以便即時執行每個狀態轉換，而無需等待整個網路。

鑑於應用程式和核心開發者的多樣性，值得計劃每年進行一次主要協議更改。如果必須選擇一個，我的選擇將是非同步執行。

概述

目前驗證器迅速在每個​​區塊上重複所有交易，並僅在為區塊計算完整狀態後才進行投票。此提案的目標是將對分叉的投票決策與計算區塊的完整狀態轉換分開。

在核准中進行投票的驗證器只需要選擇分叉；他們根本不需要執行任何狀態。只有在每個epoch，他們才需要狀態來計算下一個核准。

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

所有非投票交易都可以非同步計算。這允許重播批量執行所有非投票交易，預取並提前對所有程式進行JIT，幾乎消除了所有快取遺失。長期目標是只有需要即時低延遲完整狀態計算的機器會為此任務進行設定。據推測，用戶將為額外的硬體支付費用。

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

• 非同步執行
• 每個epoch 輪換固定數量的投票委員會
• 200 毫秒的區塊時間

由於用戶交易重播無法阻塞分叉選擇，因此減小區塊時間時，波動性不再是個問題。唯一需要考慮的是，在200 毫秒時驗證器的投票速率加倍。對核准如何計算配額進行相當直接的更改，將使我們能夠將核准的大小固定為200 或400，或任何看起來合適的數字。

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

實際上，我相信確認時間將會提高，因為核准的絕大多數會盡可能快地進行投票，而在這些投票傳播的同時，向用戶提供完整狀態執行結果的節點可以同時執行交易。因此，我們今天看到的任何重播抖動都應該與投票網絡傳播同時發生。

投票

• 投票帳戶必須擁有足夠數量的SOL，以涵蓋2 個epoch 的投票。
• 投票交易必須是簡單。非簡單的投票必定執行失敗。區塊生成者應該放棄複雜的投票。
• 從投票帳戶提取SOL 被允許，只要餘額不降到低於1 個epoch 的投票。
• 為了清除所有的lamports，Vote CLOSE 指令必須要求完整的時代經過。投票帳戶在時代1 被標記為CLOSE，但只能在時代2 時進行CLOSE。 CLOSE 允許提取所有的SOL，並刪除投票帳戶。一旦一個帳戶被標記為CLOSE，它只能被完全刪除，不能重新開啟。
• 投票包含一個VoteBankHash，而不是常規的BankHash。

領導者調控與核准

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

• 質押量> X
• 以及SOL > 2 個時代的投票
• 且沒有標記為CLOSE

才能進入領導者調度併計入核准。對於版本2，我們可以將LeaderSchedule 與Quorum 分開，它們各自的要求不必相同。

VoteBankHash 計算

與計算所有交易的Bankhash 不同，驗證器僅為與LeaderScheduler 中的驗證器相關的簡單投票交易計算VoteBankHash。所有其他交易都被忽略。在重播所有投票後，VoteBankHash 以與目前BankHash 相同的格式計算。

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

BankHash 計算

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

然後，BankHash 是從（VoteBankHash，UserBankHash）的累積中派生出來的。前99.5% 的驗證器每100 個時隙將BankHash 作為其投票的一部分提交。雖然每100 個時隙提交一次，但它在每個時隙都進行計算。值得注意的是，對於一小部分節點始終在gossip 中提交BankHash 作為沒有觀察到非確定性的軟體訊號可能是值得的。

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

BankHash 應該累積先前的BankHash。

去銀行領導者

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

• 領導者維護付費帳戶餘額的快取。
• 如果一個付費帳戶被用作系統轉帳的來源，或作為可寫入帳戶與系統程序一起傳遞給另一個程序，那麼該付費帳戶餘額被設定為0。
• 根據聲明的計算單元（CUs）將區塊按本地費用優先排序打包，直到區塊被填滿。
• 從付費帳戶餘額緩存中扣除費用。
• 付費帳戶餘額快取由BankHash 計算進行補充。

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

鑑於驗證者已經尋求最大化自己的收益，他們有充分的激勵來維護一個準確的付費帳戶快取。此外，如果沒有設定懲罰機制，長期來看，任何網路中的任何人都可以輕鬆地為快取提供服務。在伺服器損壞的情況下，無銀行領導者操作者應該能夠輕鬆切換或從多個來源進行取樣。

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

權衡

主要權衡在於為使用者狀態提供服務的全節點缺乏確認的簽名，以確認其提供狀態與核准的其餘部分完全一致。狀態的唯一權威解釋應該保持不變，即使每個交易在分類帳中按順序重播。任何效能優化都不應改變結果。因此，一旦分叉被最終確定，就只剩下正確的狀態可以計算，只要運行時實現沒有錯誤。

旨在可靠提供狀態的節點應該運行多台機器和客戶端，如果狀態執行中出現差異，它們應該停止操作。這本質上是運營商今天應該做的事情，因為僅僅依賴網路的其餘部分引入了正直的大多數假設。

使用者也可以簽署斷言BankHash 或觸發中止的交易。只有在計算的確切BankHash 與由RPC 提供者提供給使用者的BankHash 完全相同時，網路的其餘部分才會執行這些交易。

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

具有固定大小核准的網路只需要非常小的狀態量來啟動。核准本身及其質押權重以及所有投票帳戶餘額。這是一個非常小的記憶體量和一個可以快速分發並在重新啟動時快速初始化的微小快照檔案。

如果核准與全節點不一致，正在同時追蹤核准和狀態的全節點將停止運作。這意味著，如果核准與狀態發生分歧，交易所、法幣通道、RPC、橋接等都將停止運作。這只需要極小比例的有缺陷的無狀態共識節點。

無銀行領導者可以依賴多個全節點的樣本來提供付費帳戶的初始餘額快取。即使有缺陷，結果將是區塊中的垃圾郵件而不是共識失敗。操作者應該能夠監控他們的領導者健康狀況以及他們注入區塊中的垃圾郵件的百分比，並迅速回應故障。