區塊鏈擴展性難題：Polkadot的解決之道

在區塊鏈領域追求更高效率的今天，一個關鍵問題逐漸顯現：如何在擴展性能的同時不犧牲安全性與系統彈性？這不僅是技術層面的挑戰，更是架構設計的深層抉擇。對於Web3生態而言，一個更快的系統如果建立在犧牲信任和安全性的基礎上，往往難以支撐真正可持續的創新。

本文將深入剖析Polkadot在擴展性設計中的取舍與權衡，並與其他主流公鏈的解決方案進行對比，探討它們在性能、安全與去中心化三者之間的不同路徑選擇。

Polkadot擴展設計面臨的挑戰

彈性與去中心化的平衡

Polkadot的架構依賴於驗證者網路以及中繼鏈。Rollup的運行依賴於連接中繼鏈的排序器，其通信使用collator協議機制。該協議完全無需許可、無需信任，任何有網路連接的人都可以使用它，連接少量中繼鏈節點，並提交rollup的狀態轉換請求。這些請求會通過中繼鏈的某個core驗證，只需滿足一個前提：必須是有效的狀態轉換，否則該rollup的狀態將不會被推進。

垂直擴展的權衡

Rollup可以通過利用Polkadot的多core架構來實現垂直擴展。這項新能力由「彈性擴展」功能引入。在設計過程中發現，由於rollup區塊驗證並不固定在某一個core上執行，這可能會影響其彈性。

由於向中繼鏈提交區塊的協議是無需許可、無需信任的，任何人都可以將區塊提交到rollup所被分配的任一core上進行驗證。攻擊者可能會利用這一點，將之前已經驗證過的合法區塊反復提交到不同core上，惡意消耗資源，從而降低rollup的整體吞吐量和效率。

Polkadot的目標是在不影響系統關鍵特性的前提下，維持rollup的彈性以及中繼鏈資源的有效利用。

Sequencer的信任問題

一種簡單的解決方法是將協議設置爲"有許可的"：例如採用白名單機制，或默認信任排序器不會惡意行爲，從而保障rollup的活性。

然而，在Polkadot的設計理念中，我們不能對sequencer做任何信任假設，因爲要保持系統的「無需信任」和「無需許可」特性。任何人都應該可以使用collator協議提交rollup的狀態轉換請求。

Polkadot: 不妥協的解決方案

Polkadot最終選擇的方案是：將問題完全交由rollup的狀態轉換函數（Runtime）解決。Runtime是所有共識信息的唯一可信來源，因此必須在輸出中明確聲明應在哪個Polkadot core上執行驗證。

這種設計實現了彈性與安全性的雙重保障。Polkadot會在可用性流程中重執行rollup的狀態轉換，並通過ELVES加密經濟協議確保core分配的正確性。

在任何rollup區塊寫入Polkadot的數據可用性層前，由約5位驗證者組成的小組會先驗證其合法性。他們接收排序器提交的候選回執和有效性證明，其中包含rollup區塊及相應的存儲證明。這些信息將交由平行鏈驗證函數處理，由中繼鏈上的驗證人重執行。

驗證結果中包含一個core selector，用於指定應在哪個core上驗證區塊。驗證人會比對該索引是否與自己負責的core一致；若不一致，該區塊將被丟棄。

這種機制確保系統始終保持無需信任和無需許可的屬性，避免排序器等惡意行爲者操控驗證位置，確保即使rollup使用多個core也能保持彈性。

安全性

在追求擴展性的過程中，Polkadot並未在安全性上妥協。rollup的安全由中繼鏈保障，只需一個誠實排序器即可維持存活性。

借助ELVES協議，Polkadot將其安全性完整擴展到所有rollup，驗證所有core上的計算，無需對使用核心數量做任何限制或假設。

因此，Polkadot的rollup可以在不犧牲安全性的前提下實現真正的擴展。

通用性

彈性擴展不會限制rollup的可編程性。Polkadot的rollup模型支持在WebAssembly環境中執行圖靈完備的計算，只要單次執行在2秒內完成。借助彈性擴展，每6秒週期內可執行的總計算量得以提升，但計算類型不受影響。

復雜性

更高的吞吐量和更低的延遲不可避免地引入復雜性，這是系統設計中唯一可接受的權衡方式。

Rollup可通過Agile Coretime接口動態調整資源，以維持一致的安全水平。它們還需實現部分RFC103要求，以適應不同使用場景。

具體的復雜性取決於rollup的資源管理策略，這些策略可能依賴鏈上或鏈下變量。例如：

• 簡單策略：始終使用固定數量的core，或通過鏈下手動調整；
• 輕量策略：在節點mempool中監控特定交易負載；
• 自動化策略：通過歷史數據和XCM接口提前調用coretime服務配置資源。

自動化方式雖然更高效，但實現與測試成本也顯著上升。

互操作性

Polkadot支持不同rollup間的互操作性，而彈性擴展並不會影響消息傳遞的吞吐量。

跨rollup的消息通信由底層傳輸層實現，每個rollup的通信區塊空間是固定的，與其分配的核心數量無關。

未來，Polkadot還將支持鏈下消息傳遞，由中繼鏈作爲控制面，而非數據面。該升級將使rollup間通信能力隨彈性擴展一同提升，進一步增強系統的縱向擴展能力。

其他協議的權衡

衆所周知，性能提升往往以犧牲去中心化與安全性爲代價。但從Nakamoto系數來看，即便一些Polkadot競爭對手的去中心化程度較低，其性能表現也並不如人意。

Solana

Solana不採用Polkadot或以太坊的分片架構，而是以單層高吞吐架構實現擴展性，依賴歷史證明、CPU並行處理和基於領導者的共識機制，理論TPS可達65,000。

一個關鍵設計是其預先公開且可驗證的領導者調度機制：

• 每個epoch（約兩天或432,000個slot）開始時，按質押量分配slot；
• 質押越多，分配越多。例如質押1%的驗證人將獲得約1%的出塊機會；
• 所有出塊者提前公布，增加了網路遭受定向DDoS攻擊、頻繁宕機的風險。

歷史證明與並行處理對硬件要求極高，導致驗證節點集中化。質押越多的節點出塊機會越大，小節點幾乎無slot，進一步加劇中心化，也增加了被攻擊後系統癱瘓的風險。

Solana爲追求TPS，犧牲了去中心化和抗攻擊能力，其Nakamoto系數僅爲20，遠低於Polkadot的172。

TON

TON宣稱TPS可達104,715，但這一數字是在私有測試網、256個節點、理想網路與硬件條件下實現的。而Polkadot在去中心化公網上已達128K TPS。

TON的共識機制存在安全隱患：分片驗證節點的身分會提前暴露。TON白皮書也明確指出，這雖能優化帶寬，但也可能被惡意利用。由於缺乏"賭徒破產"機制，攻擊者可等待某個分片被其完全控制，或通過DDoS攻擊阻斷誠實驗證者，從而篡改狀態。

相比之下，Polkadot的驗證人是隨機分配、延遲揭示的，攻擊者無法提前得知驗證人身分，攻擊需賭全部控制成功，只要有一個誠實驗證者發起爭議，攻擊就會失敗並導致攻擊者損失質押。

Avalanche

Avalanche採用主網+子網架構進行擴展，主網由X-Chain（轉帳，~4,500 TPS）、C-Chain（智能合約，~100-200 TPS）、P-Chain（管理驗證者與子網）組成。

每個子網理論TPS可達~5,000，類似Polkadot的思路：減少單個shard的負載以實現擴展。但Avalanche允許驗證者自由選擇參與子網，且子網可設置地理、KYC等額外要求，犧牲了去中心化與安全性。

在Polkadot，所有rollup共享統一安全保障；而Avalanche的子網沒有默認的安全保證，部分甚至可完全中心化。若想提高安全性，仍需在性能上妥協，且難以提供確定性的安全承諾。

Ethereum

以太坊的擴展策略是押注於rollup層的可擴展性，而不是在基礎層直接解決問題。這種方式本質上並沒有解決問題，而是將問題傳遞到了堆棧的上一層。

Optimistic Rollup

目前大多數Optimistic rollup都是中心化的（有些甚至只有一個sequencer），存在安全性不足、彼此孤立、延遲高（需等待欺詐證明期，通常幾天）等問題。

ZK Rollup

ZK rollup的實現受到單筆交易可處理數據量的限制。生成零知識證明的計算需求極高，且"贏者通喫"機制易導致系統中心化。爲保證TPS，ZK rollup往往限制每批次交易量，在高需求時會引發網路擁堵、gas漲，影響用戶體驗。

相比之下，圖靈完備ZK rollup的成本大約是Polkadot核心加密經濟安全協議的2x10^6倍。

此外，ZK rollup的數據可用性問題也會加劇其劣勢。爲了確保任何人都能驗證交易，仍需提供完整交易數據。這通常依賴額外的數據可用性解決方案，進一步推高成本和用戶費用。

結語

可擴展性的盡頭，不應該是妥協。

與其他公鏈相比，Polkadot並未走上以中心化換性能、以預設信任換效率的道路，而是通過彈性擴展、無需許可的協議設計、統一的安全層和靈活的資源管理機制，實現了安全性、去中心化與高性能的多維度平衡。

在追求更大規模應用落地的今天，Polkadot所堅持的"零信任擴展性"，或許才是真正能支撐Web3長遠發展的解決方案。