原文：https://www.parity.io/blog/scalability-tradeoffs-polkadot-web3
作者：Andrei Sandu
編譯：OneBlock+
在區塊鏈不斷追求更高效率的今天，一個關鍵問題逐漸顯現：擴展效能的同時，是否必須犧牲安全性與系統彈性？
這不僅是技術層面的挑戰，更是架構設計的深層抉擇。尤其對於Web3 生態而言，一個更快的系統如果建立在犧牲信任和安全性的基礎上，往往難以支撐真正可持續的創新。
作為Web3 可擴展性的重要推動者， Polkadot 是否也在高吞吐、低延遲的目標下作出了某些犧牲？其rollup 模型是否在去中心化、安全性或網路互通性上做出了讓步？
本文將圍繞這些問題展開，深入剖析Polkadot 在擴展性設計中的取捨與權衡，並與其他主流公鏈的解決方案進行對比，探討它們在性能、安全與去中心化三者之間的不同路徑選擇。
🧬Polkadot 擴展設計面臨的挑戰
彈性與去中心化的平衡
Polkadot 的架構依賴於驗證者網路以及中心化的中繼鏈（Relay Chain），這是否可能在某些方面引入中心化風險？是否可能形成單點故障或控制，進而影響其去中心化特性？
Rollup 的運作依賴於連接中繼鏈的排序器（sequencer），其通訊使用一種稱為collator 協定的機制。該協議完全無需許可、無需信任，任何有網路連線的人都可以使用它，連接少量中繼鏈節點，並提交rollup 的狀態轉換請求。這些請求會經過中繼鏈的某個core 驗證，只需滿足一個前提：必須是有效的狀態轉換，否則該rollup 的狀態將不會被推進。
垂直擴展的權衡
Rollup 可以透過利用Polkadot 的多core 架構來實現垂直擴展。這項新能力由「彈性擴展」（Elastic Scaling）功能引入。在設計過程中我們發現，由於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 的資料可用性層（DA）前，由約5 位驗證者組成的小組會先驗證其合法性。他們接收排序器提交的候選回執（candidate receipt）和有效性證明（PoV），其中包含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 也將支援鏈下訊息傳遞（off-chain messaging），由中繼鏈作為控制面，而非資料面。此升級將使rollup 間通訊能力隨彈性擴展一同提升，進一步增強系統的縱向擴展能力。
🧩其他協議做出了哪些權衡？
眾所周知，性能提升往往以犧牲去中心化與安全性為代價。但從Nakamoto 係數來看，即便有些Polkadot 競爭對手的去中心化程度較低，其效能表現也不如人意。
Solana
Solana 不採用Polkadot 或以太坊的分片架構，而是以單層高吞吐架構實現擴展性，依賴歷史證明（PoH）、CPU 並行處理和基於領導者的共識機制，理論TPS 可達65,000。
一個關鍵設計是其預先公開且可驗證的領導者調度機制：
每個epoch（約兩天或432,000 個slot）開始時，以質押量分配slot；
質押越多，分配越多。例如質押1% 的驗證人將獲得約1% 的出塊機會；
所有出塊者提前公佈，增加了網路遭受定向DDoS 攻擊、頻繁宕機的風險。
PoH 與平行處理對硬體需求極高，導致驗證節點集中化。質押越多的節點出塊機會越大，小節點幾乎無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 長遠發展的解決方案。
