Shardeum 推出：突破性的成就
2024 年 1 月 27 日星期一，web3 世界發生了一件開創性的事件，這可以比作航天器在首次飛行測試任務後完美返回發射臺的歷史性壯舉。在這個非凡的場景中，Shardeum不僅面臨嚴峻的挑戰，而且取得了勝利，其網絡彈性標誌着分片網絡首次在分佈式賬本技術領域實現自我修復。
正如宇宙飛船之旅需要縝密的規劃、精密的工程和複雜操作的無縫執行一樣，Shardeum 遭受嚴重事故的 Sphinx betanet 的恢復也需要同等水平的技術掌握和創新。在網絡上保留所有數據的能力，尤其是使用動態分片運行的數據，是開創性的。
當我們踏上這一探索之路時，我們不僅慶祝 Shardeum 具有里程碑意義的落地，還認識到它是 web3 技術發展的分水嶺時刻，這一飛躍可能會重新定義 IT 網絡彈性和數據完整性的界限。
第一個獨立恢復和保留數據的分片網絡
動態維護和恢復分片網絡（例如 Shardeum）包含一系列複雜的技術挑戰，這使其與比特幣或以太坊等傳統區塊鏈網絡不同。在具有自動擴展功能的動態表達分片環境中，跨不同分片的節點和資源的持續重新分配和平衡對於優化性能和可擴展性至關重要。網絡架構的不斷變化增加了維護數據一致性、確保網絡穩定性和促進有效故障恢復的複雜性。
在將 Shardeum 對節點波動的響應與比特幣進行比較時，強調了這一挑戰的重要性。即使節點數量很少，比特幣網絡也能保持功能，因爲每個活動節點都有完整的狀態和交易歷史。相比之下，由於 Shardeum 分片網絡的原因，Shardeum 上的每個活躍節點都沒有完整的狀態和交易歷史記錄，並且每個驗證器僅擁有整體狀態的一部分。這種分片的結果是所有驗證器節點都變得非常輕量級。因此，這創造了大量的工程機會和挑戰。如果一個節點宕機了，我們如何保證所有數據得到維護？ Shardeum 有兩種主要方式。
首先，Shardeum 使用動態分片，整個地址空間根據活動節點的數量進行分區（或劃分）。每個節點負責其分配的分區，以及其周圍一定的半徑（R）和與其相鄰的附加分區（E），確保網絡框架內的動態適應性和強大的數據冗餘。因此，即使某個節點發生故障，網絡仍然連續，不會丟失數據。
其次，Shardeum使用歸檔節點來存儲整個網絡的完整狀態。這是通過活動節點將部分存儲的狀態流式傳輸到存檔器進行收集來實現的。由於這兩個因素和設計優化，必須以新的方式設計恢復此類網絡，以仍然促進自動縮放和線性縮放等有益功能。
瞭解崩潰
現在我們瞭解了動態分片的基礎知識以及歸檔器節點以某種方式參與其中，讓我們更深入地分解一些附加組件並解釋它們。要了解 Shardeum betanet 崩潰和恢復，我們必須首先了解以下內容：
歸檔器節點
檢測丟失的歸檔器
網絡模式
恢復模式
在我們深入研究所涉及的錯誤之前，瞭解其中每一個的基礎知識非常重要，所以讓我們來看看！
存檔節點：星際存儲
在Shardeum中，歸檔器節點也稱爲歸檔器，是非常重要的一類節點，其任務是存儲網絡的整個狀態和歷史記錄。與主動節點不同，歸檔者不參與共識過程；其主要功能是全面歸檔所有網絡數據，包括交易和收據。存檔節點的貢獻對於維護網絡的完整性並確保其運行順利運行至關重要，從而確認了 Shardeum 作爲一個強大、完整和可靠的網絡的地位。由於存檔器是其網絡的組成部分，Shardeum 必須制定協議來檢測無響應的存檔器（和驗證器）。
丟失檔案檢測：外星技術揭曉
Shardeum 有一個稱爲丟失節點檢測協議的協議，用於檢測活動節點何時變得不工作 ——這僅適用於活動節點。然而，Shardeum 也有一個用於歸檔器的協議，它可以執行類似的操作，稱爲丟失歸檔器檢測。丟失存檔器檢測是一種特殊協議，旨在處理一個或多個存檔器無法運行並被標記爲丟失的罕見情況。由於歸檔節點對於維護網絡中歷史數據的完整性和可訪問性至關重要，因此至關重要的是，如果它們變得無響應或發生故障，可以捕獲這些關鍵事件以減輕下游影響。儘管丟失的歸檔程序不會導致這種特定的崩潰，但丟失的歸檔程序檢測協議和特定網絡模式之間的交互會導致這種崩潰。現在我們來看看Shardeum有哪些網絡模式。
Shardeum 上的網絡模式：無需 NASA
Shardeum 底層 Shardus 協議支持的旗艦創新是網絡模式框架。這些模式超越了基本的運行條件，實現了各種節點活動、數據同步方法和交易管理系統的複雜協調。這種網絡配置在維護網絡運行完整性方面發揮着重要作用，尤其是在節點和數據丟失的場景中——因爲 Shardeum 是一個分片網絡。
在更簡單的層面上，瞭解 Shardeum 網絡模式的最佳方法是制定一個編碼良好的應急計劃，即使在網絡崩潰或網絡範圍降級等不太可能發生的情況下，也能實現整個網絡的連續運行。這種預先編程的操作彈性和彈性確保 Shardeum 始終保持活力 ——無論網絡面臨什麼困難。
雖然理解錯誤並不需要了解網絡模式框架的每個方面，但瞭解基礎知識會很有幫助。網絡模式框架的核心是幾個不同網絡階段的結合：建立、處理、安全、恢復、重啓、恢復和中斷。這些模式經過精心設計，可以解決各種網絡情況和緊急情況。然而，我們在本文中關注的模式是恢復模式。
逆向工程恢復模式：Rosewell 重溫
恢復模式是上述7種網絡模式中的一種。當網絡活動節點的數量低於預定的臨界閾值（當前配置爲 75% 或更低）時，啓動恢復模式。該閾值可以根據網絡需求進行調整。在此模式下，網絡暫停應用程序事務處理和應用程序數據同步。該策略旨在通過無縫循環空閒節點作爲節點輪換的一部分來促進網絡擴展，從而使活動節點數量恢復到最佳水平，理想情況下高於 100%。
在恢復模式下，Shardeum 的網絡架構允許逐步進行節點升級，每個週期的增長限制爲 20%（每個週期大約爲 60 秒）。這種受控的增長率對於維持網絡穩定性和確保新節點的順利集成至關重要。節點數量的快速增加，例如 50% 的峯值，有可能破壞網絡的穩定性並使集成過程複雜化。
每個新添加的節點都需要網絡資源來進行同步和集成。通過將每個週期的升級限制在 20%，網絡可確保其基礎設施能夠充分支持新節點的添加，而不會造成壓力。這種方法不僅可以保持網絡穩定性，還可以最大限度地降低同步過程中數據不一致或錯誤的風險，從而保持循環鏈數據的完整性。
崩潰的根本原因：事件視界
值得注意的是，存在兩個不同的錯誤。 Neon 庫錯誤 —導致驗證器隨機崩潰，以及缺失存檔器檢測協議中的錯誤 — 不接受空驗證器列表。雖然是缺少歸檔器檢測協議錯誤導致當前版本的 Betanet 崩潰，但我想邀請您首先討論 neon 庫錯誤。
在 Sphinx 版本 1.9.1 中，我們集成了對庫的更新，該更新使用 Neon binder 鏈接 Rust 和 TypeScript 函數，因爲 Shardeum 主要是用 TypeScript 構建的。 Neon 以其創新的、實驗性的方法而聞名，這種方法經常突破傳統軟件開發實踐的界限。這種集成旨在提高這兩種語言之間的互操作性，從而在我們的軟件架構中實現更高效、更直接的通信。然而，這會導致一個錯誤，導致節點隨機退出網絡。
其次，在最近導致 Shardeum 測試網崩潰的事件中，根本原因被確定爲源於上述兩個不同子系統之間交互的嚴重異常：缺失的存檔器檢測機制和網絡恢復模式協議。
這次短暫的崩潰是由這兩種機制同時激活觸發的，這是以前從未遇到或測試過的場景。丟失存檔過程與網絡恢復模式一起觸發，並且由於丟失存檔模式中的錯誤不接受活動節點的空列表而觸發。這會導致網絡崩潰。
恢復編年史：從系統性休克到恆星覺醒
那麼究竟發生了什麼以及何時發生？圍繞網絡崩潰的事件及其解決方案的時間表如下：
漏洞和初始升級：網絡存在由 npm (neon) 庫中的 1.9.1 linting 過程標記的漏洞。已實施一項改進來解決此問題。然而，這一改進無意中引發了一個異常，該異常在本地測試期間並未重現。
間歇性庫異常導致驗證器中斷：neon 庫遇到零星異常，導致週期性網絡驗證器中斷。儘管網絡設計允許通過重新填充這些驗證器來實現彈性，但不幸的是，多個驗證器之間同時發生故障會觸發網絡恢復模式。
觸發網絡恢復模式：一旦進入網絡恢復模式，協議必須清理並重新創建活動節點列表。丟失的文件系統中的併發錯誤（不容納空的驗證器列表）是網絡崩潰的主要原因。
網絡解決和恢復：崩潰已修復，網絡已使用存檔器中存儲的數據成功恢復。這是歷史上第一次崩潰的第1層分片網絡被成功恢復，網絡上的所有數據都完好無損地保存下來。這在任何網絡上都從未做過，更不用說具有動態分片的網絡了。這一成果標誌着網絡恢復的“火箭着陸”成功。
已完成的修復：實施了初步修復以解決庫問題，但爲了不斷提高網絡穩定性，發佈了 1.9.5 版本。此更新引入了一個重要的錯誤修復，該修復解決了 neon 綁定崩潰的另一個實例，無需進行網絡範圍的升級即可查明並修復特定漏洞。最初，使用 1.9.4 版本的用戶可以根據對網絡性能和穩定性偏好的評估靈活地保留當前版本或選擇升級到 1.9.5。但最終決定，爲了提高網絡穩定性並解決與 neon 綁定相關的持續問題，驗證器所需的最低版本應增加至 1.9.5。此更新旨在系統地排除在 1.9.4 版本上運行的驗證器，該版本已被確定由於上述 neon 綁定複雜性而容易崩潰。這是確保霓虹燈錯誤已被完全刪除並完全修復所必需的。
現在我們已經知道了時間線和重大事件是如何發生的，讓我們來看看到底發生了什麼，以便網絡能夠快速恢復。
邁向復甦
敏捷恢復
網絡恢復由很多部分組成，但其中主要的部分之一是Shardeum恢復模式。如前所述，當網絡活動節點的數量低於預定的臨界閾值時，恢復模式就會啓動，並允許以安全的方式快速、受控和有效的網絡增長來恢復網絡。需要強調的是，如果沒有網絡模式設計者和開發者的技術獨創性，Shardeum 不可能如此輕鬆地從崩潰中恢復過來，也不會展示其創新能力。
此外，Shardeum 的技術團隊做出了重大努力，立即採取了行動。第一步涉及徹底分析，以確定崩潰的根本原因，可追溯到網絡丟失存檔檢測與其恢復模式系統之間的交互異常。瞭解問題的複雜性後，團隊迅速實施了多方面的方法來解決直接影響和潛在的漏洞。
Shardeum 技術團隊的反應不一
從技術上講，反應不一：首先，研究小組隔離了受影響的成分，以防止組織進一步退化。與此同時，他們應用了補丁來修復丟失的文件系統中的錯誤，確保它可以處理空的驗證器列表——這是觸發網絡故障的嚴重錯誤。爲了將網絡恢復到完全運行能力，存儲在存檔中的數據將被激活並用於重建崩潰前的網絡狀況，確保在此過程中不會丟失任何數據。
從邏輯上講，該團隊跨時區和學科進行協調，利用基於雲的工具進行協作和實時監控。這種協調一致的工作不僅有助於修復的快速開發和實施，而且還確保所有團隊成員在恢復過程和後續步驟上保持一致。
此次事件是對 Shardeum 事故管理協議的嚴格考驗，凸顯了敏捷和創新應對意外挑戰的重要性。這強調了該團隊致力於維護一個有彈性和安全的網絡，準備克服出現的複雜技術障礙。
安全和太空着陸創新
綜上所述，Shardeum分片網絡的成功恢復標誌着網絡技術的重大轉變，對行業具有深遠影響的里程碑。雖然目前鮮爲人知，但網絡模式等創新最終將爲 web3 制定新的行業標準。
我一直相信Shardeum的核心創新很有可能影響未來的技術發展，激發創新和新一代賬本技術。作爲第一次 Shardeum 網絡恢復的第一手見證者，我知道這將成爲重新評估行業標準的催化劑，有可能導致在網絡設計和架構中採用更嚴格的協議和方法。
此次活動不僅展示了Shardeum團隊的技術實力和創新，還標誌着去中心化網絡在災難恢復規劃方面變得更加強大、適應性更強並能夠應對不可預見的挑戰的時代的開始。最終，Shardeum 技術將預示着去中心化的新時代。
