2月26日，Polygon zkEVM一張預告主網上線的宣傳海報，卻引發了“以太坊”等效性一詞用法的爭論，Scroll創始人Ye Zhang嚴正指出Polygon zkEVM不具備這一特性。從事後Polygon Labs負責人Ryan Wyatt的回應來看，這更像是團隊內部營銷人員和技術人員溝通不到位的結果。
這並非小題大做，何種程度上的有效性甚至會直觀關係到L1/L2性能和擴展性，就在此前2天，Solana聯創Toly發文認為ZK L2s 不會是解決可擴展性的最佳方案。
2月27日，而本次事件主角Polygon技術團隊也在積極回應關於zkRollup工作原理，解釋zkRollup的擴展性指向何處。
3月1日，Solana也宣布“改進網絡升級的計劃”，重新扛起以太坊殺手的大旗，但是其在經歷多次宕機後運作機制仍未根本革新，而更像是危機後的優化，也給高性能L1取代以太坊一事蒙上了陰影。
本文將結合多位L1/L2創始人的推文，為大家揭示關於公鏈性能的大討論的來龍去脈。
緣起：關於EVM等效性的爭論
Polygon的zkEVM，嚴格來說是一種zk VM機制，通過映射的方式在L2層面跟以太坊主網保持一致，zk技術的引入是其稱為zk VM的原因，而在非嚴格意義上而言，只要能保持同步性，那麼稱為zk EVM便無傷大雅。
但根據Scroll創始人Ye Zhang的觀點，EVM等效性並不完全等於以太坊等效性，因為後者至少還需要在數據存儲方面保持跟以太坊主網的一致。
從更廣泛的角度而言，目前的各類L2s或者以太坊跨鏈橋都不能宣稱具備以太坊等效性，以太坊後續後更為模塊化，更為複雜的堆棧也會帶來更困難的兼容性。
可以舉一個簡單的例子來直觀理解二者的不同，Optimism在產品規劃中涉及二者的區別，在其看來：
EVM等效性：主要是從dApp開發者視角而言，其在OVM上的體驗和在以太坊主網開發dApp別無二致，因此OVM便具備EVM等效性；
以太坊等效性：主要是從協議開發者視角而言，需要在客戶端、通信層、共識層和執行層等方面和以太坊保持較高的一致性。
而在EVM等效性的爭論之餘，還應該注意到關於擴展性的爭執，這也是目前各類基於以太坊L2和高性能L1之間的爭奪焦點。
前因：Solana對ZK擴展性的質疑
就在Polygon zkEVM預告上線的前兩天，即2月24日，Solana聯創Toly便在推特發文質疑ZK L2s對公鏈擴展問題的解決能力，以抵消公眾對Solana運作機制的質疑。
他的主要觀點如下:
- 數據實時上鍊需要保持穩定的順序執行能力；
- ZK證明方案成立，前提是ZK生成證明時間+驗證時間的總和小於實時執行時間；
- ZK方案無法做到實時處理大批量數據，只能進行間歇性的匯總，而無法保持鏈上狀態的實時性；
因此，ZK方案更適合單次、低頻的場景，比如批量結算，而公鏈級的可擴展性還是需要Solana。
但不湊巧的是，Solana在2月25號發生嚴重的宕機事故，社區、工程師和驗證者在經歷兩次重啟後才重新恢復主網，而屋漏偏逢連夜雨，“好事者”趁機對Solana的機制產生質疑，推特用戶DBCryptoX認為“Solana上90-95%的交易都包含驗證者消息和鏈上投票”。
Solana使用PoS共識機制，其自稱為”歷史證明”（Proof of History）機制。 PoH使網絡能夠更快地運行，因為節點不需要通過通信來驗證一個區塊，PoH使驗證者能夠精確確定某一時刻上的事件。
一方面，這種機制帶來了高度的統一性，帶來了遠超以太坊主網的TPS，但另一方面確實會嚴重佔用鏈上區塊空間，一旦出現問題，則很難取得共識以恢復網絡。至少在2021-2023年間，每年均發生至少一次以上的主網宕機事件。
宕機事件為Solana的可擴展性貢獻了反面教訓。 Solana聯創Toly認為ZK L2上的證明者（prover）無法做到實時執行，因此，最終ZK L2s的鏈上執行將和既定順序不一致，為此，要么用戶運行完整節點增加網絡負擔，要么依賴少數誠實節點以提高效率而走向中心化。
但目前的事實證明，高性能L1 Solana似乎也無法解決實時執行問題，畢竟，垮掉的網絡最後也會丟失既定順序，而強行恢復後的數據也會變成人為認定的“共識”，而非網絡本身的自發狀態。
後果：Polygon的擴展性關鍵所在
Polygon zkEVM先是遭遇Solana質疑，後是宣發出現烏龍事件，被質疑不專業和具有誤導性。因此其開發者Jordi Baylina跳出來承擔了對專業性的挑戰，集中在解釋證明者（prover）並非是ZK L2s的限制因素，真正的阻礙者其實是DA（數據可用性）。
首先是zkRollup的運作流程，如下圖所示，大致可分為三步：
保持網絡同步，無論是何種架構的Rollup，只要涉及L2上的數據，都需要為批量處理的消息進行有效性證明，以在最終回傳至L1時可以得到確認，
聚合證明生成，需要使用zk證明方案（ZKP），並行處理可以加速這個過程，但批量證明的生成本身確實需要一些時間。甚至可以設計動態機制，網絡證明者的數量可以根據網絡需求進行增加或減少。
在ZKP運行後，會對數據生成一個完整的樹狀證明網絡，可以讓不同的服務器進行數據驗證，並將結果發送到L1鏈上。
其次是成本問題，其中最關鍵的是證明成本，ZK運作調用的軟硬件和時間都會被TX（交易）費用納入計算因子，最終反映到網絡的Gas Fee上，而不同的算法，如STARK/SNARK/FLONK等會大幅優化網絡使用成本。而其中的關鍵還在於，數據的加載並不需要完全順序執行，以便於並行化處理。
因此，Solana聯創Toly所認為的證明者（Prover）並不能阻礙ZK證明方案的運行，而真正的阻礙是數據可用性，需要ETH 2.0和DankSharding、EIP4844等方案來解決。
結論：擴展性究竟走向何方
圍繞Polygon zkEVM的爭論將繼續進行，其中的關鍵在於zk EVM究竟能在多大程度上解決當前的擴展性問題，這也是一眾L1/L2s接下來面臨大規模dApp和用戶量所直面的考驗。
