所有非投票交易，都可以異步計算。
作者：Anatoly Yakovenko，Solana 首席執行官（聯合創始人兼 CEO）
編譯：1912212.eth，Foresight News
封面：Photo by Shubham’s Web3 on Unsplash
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、橋接等都將停止運行。 這只需要極小比例的有缺陷的無狀態共識節點。
無銀行領導者可以依賴於多個全節點的樣本提供付費帳戶的初始餘額緩存。 即使有缺陷，結果將是區塊中的垃圾郵件而不是共識失敗。 操作者應該能夠監控他們的領導者健康情況以及他們注入到區塊中的垃圾郵件的百分比，並迅速回應故障。
免責聲明：作為區塊鏈資訊平臺，本站所發佈文章僅代表作者及嘉賓個人觀點，與 Web3Caff 立場無關。 文章內的資訊僅供參考，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。
