以太坊->Solana->Aptos：高性能公鏈競爭的終局在何方？

原文標題：《Ethereum -> Solana -> Aptos: the high-performance competition is on》
撰文：The Anti-Ape
編譯：0xshushu，7UpDAO

主要結論：

我們提出了一個 L1 設計權衡的第一性原理框架：高性能的三難困境。（如上圖）
與以太坊相比，Solana 的激進的低冗餘（Redundancy）設計既解釋了它的高性能，也解釋了它的低可靠性。
Aptos，一個擁有 2 億美元全明星種子輪融資的新 L1，準備挑戰 Solana 在高性能 L1 領域的壟斷地位。與 Solana 相比，Aptos 增加了更多的可靠性，其代價是更高的節點硬體要求。
我們相信針對特定應用進行優化才是 L1 的未來。考慮到三難問題，沒有哪條鏈能達到一個萬能設計就符合所有應用場景的狀態。在我們之前的跨鏈文章的基礎上，我們提出了一個「三個問題」的問答手冊，供區塊鏈應用的開發者們考慮他們的技術選擇。

文章中會提及的項目包括：

Solana, Aptos, Ethereum, StarkWare, zkSync, Serum, Meteplex

內容目錄

第一部分：Solana 高性能的秘訣

這部分包括：

直到目前，Solana 作為唯一的一條高性能區塊鏈仍處於壟斷地位
Solana 的設計基因是激進地優化最理想情況下的網路性能：並行運算（Parallelism）、減少冗餘度和更高的出塊率。

是什麼讓 Solana 與眾不同？

作為唯一接近 Visa 65,000 TPS 容量的區塊鏈，Solana 獲得了華爾街和矽谷的支持，以嘗試應用大規模的區塊鏈服務。

Solana 並沒有通過一些圖靈獎的魔法來實現 TPS（與零知識證明不同，這是我們即將討論的另一個重要話題）。相反，Solana 在性能和可靠性之間做了一系列的設計權衡。我們將在第一部分討論 Solana 的性能，在第二部分討論可靠性的成本。

設計選擇 1：並行計算。

以太坊虛擬機（EVM）是單線程的——EVM 只能利用一個 CPU 核心來按順序處理交易。由於單核產生的熱量隨著速度的提高而呈指數級增長，物理學限制了單核性能的上限是很低的。

解決方案是什麼？更多的核心！八個 2GHz 的核心比一個 8GHz 的核心溫度要低很多，但也更強大。2007 年，英特爾（Intel）推出了雙核的奔騰處理器，從而結束了單核時代。今天的計算機消費者擁有的 GPU 和 CPU 有 4 到 4096 個核心。讓更多的核心合作得更好，而不是擁有更強大的單核，已經成為了十多年來半導體行業的研究重心。

為了實現原生多線程，Solana 必須放棄 EVM 的兼容性。 Solana 的智能合約可以利用 Nvidia GPU 的 4096 個核心來並行地運行計算。

我們的觀點：在這個 [EVM v.s Multi-thread] 的二元選擇中，我們傾向於多線程而不是 EVM 的兼容性。我們認為 2027 年的 DApp 卻只能使用 2007 年的半導體技術是非常荒謬的。

有些人可能會指出 EVM/Solidity 相關的開發者的護城河問題。但是開發者其實很容易轉換編程語言。今天的大多數 Web 2 應用和開發人員使用的編程語言都是原生的多線程。我們認為未來的開發者會像當前高 GAS 一樣對 EVM 的神秘的單線程架構感到沮喪。 (另外，我們也不是 EVM 兼容的 rollups 方案的粉絲）。

設計選擇 2：通過確定的領導節點輪換減少冗餘度

去中心化需要冗餘性。在谷歌（Google）這樣的中心化雲服務中，計算只發生一次——因為用戶相信谷歌是正確的。

在區塊鏈中，由於我們不能信任任何人，所有數據都需要由不同的節點進行計算和驗證。一個相同的計算所做的額外次數就是所謂的間接費用 / 冗餘度。為了量化冗餘，我們使用[Big-O 符號]（大 O 符號，漸進符號），如：[O(n^2), O(n), O(log n)]，裡面的函數表示當他們擴展到更多節點時，網路計算將變得多麼複雜。例如，隨著網路的增長，O(n^3) 可能意味著比 O(n^2) 大幾個數量級的冗餘度。

在比特幣、以太坊和其他許多簡單的 PoS 鏈中，共識的冗餘度至少是 O(n^2)，與節點數量的平方成正比：每個區塊都必須傳輸、檢查和比較其他每個區塊的工作。

對於 Solana，只有被指定的那個領導節點來生產下一個區塊。（See Gulf Stream, Leader Rotation）。在此基礎上，Solana 將區塊分割成很多小塊，然後只有一小部分節點驗證者來驗證每個小塊（See Turbine），而不是所有的節點都要發送和驗證所有的區塊。

Solana 的協議將 Solana 的最佳情況下的冗餘度從 O(n^2) 減少到 O(log n)，這是計算複雜性理論中最有效的可能。這個結果確實很了不起。考慮一個（過於簡化的）說明。

網路 A 和 B 在其他方面是相同的，100 個節點有 100k TPS。一個 O(n^2) 網路每增長 10 倍的節點性能就會衰減 100 倍。一個 O(log n) 網路每增長 10 倍節點性能才會衰減~ 3 倍。在 10 萬個節點時，兩個網路的性能將相差 30000 倍。

這種複雜性的降低也有意識形態上的意義。在這方面，我們認為 Vitalik 對 Solana 的批評有些誤導——Vitalik 認為 Solana 因為硬體要求高而不夠去中心化。Solana 4000 美元的硬體成本阻止了「每個用戶在自己的機器上運行 Solana 節點」。這個成本是沒錯的。但從長遠來看，計算成本會越來越便宜，而且 Solana 的複雜度降低的設計使它有可能擁有 100 倍的節點，而不會使網路變得難以忍受的緩慢。

其他的設計選擇：

支持者和批評者還就 Solana 的其他一些技術特點進行了辯論。我們認為這些特點不那麼核心，所以我們概括性地討論：

3.1 投票交易算入了 TPS

一些批評者指出 Solana 透過將驗證者投票也算入了交易，從而人為的增加了 TPS。投票確實被算入了交易，但這只是一個表面問題。也許 Solana 應該重申一下它的 TPS 是 60,000（剔除投票交易），而不是 65,000。

3.2 吞吐量—更快的出塊時間和更大的區塊

Vitalik 和 StarkWare 都批評 Solana 的性能改進有些懶惰，因為 Solana 只是讓每個區塊更大，區塊時間更短，以更高的硬體要求為代價來容納更多的交易。簡單的數學會告訴你這並不是全部。

Solana 的最大區塊大小為 10MB，是 ETH 目標大小 1MB 的 10 倍。
Solana 的出塊時間是 0.4 秒，是以太坊 12 秒的 30 倍。
相比以太坊，以上兩者的組合給了 Solana 大概 300 倍的懶惰性能改進。
但實際上 Solana 的 TPS 比以太坊通常的 TPS 要高 3000 倍。

這另外 90% 的性能提升可以由我們討論過的 Solana 的並行運算和降低冗餘性的設計來更好的解釋。

3.3 歷史證明（POH，Proof of History）

Solana 將 POH 宣傳為其最大的創新。從長遠來看，歷史證明允許 Solana 將區塊時間減少到極端的 400ms / 區塊，儘管事實上物理網路延遲往往大於 400ms。這個功能的花哨名字是異步共識，更多細節見 Multicoin 的文章。

設計選擇總結：Solana 的高性能秘訣

三個關鍵指標共同決定了區塊鏈的最大吞吐量：出塊率、並行計算和冗餘性。

冗餘度決定了總共需要多少數據和計算量，也就是說，總計算量 = 有效計算 + 冗餘度；
並行計算允許節點計算的速度更快；
出塊率決定了一定時期內區塊鏈數據庫中可保存的數據量。

Solana 在這三個方面都做出了大膽的設計選擇：從 O(n^2) 到 O(log n) 冗餘；從 1 核到 4096 核並行，以及從 5MB/min 到 1500MB/min 的出塊速率。這些是 Solana 的 65,000TPS 背後的主要秘訣。在下一章中，我們將討論 Solana 這些選擇的成本。

第二部分：Solana 選擇的成本：優先性能而非彈性

這部分包括：

Solana 激進的性能優化的 DNA 使它比其他區塊鏈更容易發生故障。
我們提出了冗餘困境：鑑於有限的計算能力，L1 必須在性能和可靠性之間做出權衡。
冗餘困境是第 3 部分中高性能三難問題的一個子集。

頻繁的網路事故

在過去的一年裡，Solana 至少經歷了 4 次重大網路事故。2021 年 9 月停運事故，2021 年 12 月降級事故，2022 年 1 月降級事故，2022 年 4 月停運事故。任何有興趣的利益相關者一定有很多問題：

是什麼導致了事故？
本質的原因是是什麼？一次性的系統 BUG ？意外的攻擊？還是區塊鏈設計 DNA 中的某些問題，我們只能緩解？

選擇最佳性能而不是可靠性

在第一部分中，我們討論了 Solana 如何積極地優化其最佳情況下的性能。「最佳情況」是這裡的一個關鍵詞。當事情沒有完全按照理想模式發生時，Solana 就會失控。

設計成本 1：當交易在邏輯上有順序時，激進的的並行計算就會退化。

NFT mint 和 IEO 交易常常導致 Solana 網路中斷。原因是：這些交易無法在 4096 個核心上同時進行。 Minting NFTs 時，不知道哪些已經被 mint 了，這會導致重複和 BUG。所有在同一個 collection 的 mint 交易必須按順序處理。一個直接含義就是，Solana 的 65,000 TPS 並不意味著用戶可以在一秒鐘內鑄造 6 個 BAYC 集合：由於只依賴一個 GPU 核心，Solana 的按順序處理能力可能更接近甚至低於以太坊，大約在 10 到 100 TPS 之間。

這就解釋了性能下降的原因：NFT mint 時失控的交易量會使 Metaplex 無法使用，但其他不依賴 Metaplex 的應用（如 Serum 訂單簿）仍然可以在其他 4095 個核心之一上處理交易。

但更多的時候，性能降低變成了網路中斷：等待 Metaplex 的未處理的交易致使節點內存溢出——當內存溢出時，節點崩潰並完全離線。

核心權衡：透過使用 4096 核心的 GPU 而不是 16 核 CPU，Solana 犧牲了單核性能而支持激進的並行運算。通常情況下，當交易不相關時，網路運行得很好，但一旦交易表現出不理想的模式，Solana 比高冗餘度的以太坊更容易崩潰。

設計成本 2：當領導者崩潰時，決定性的領導者選擇會變得很難看

當 Solana 接近崩潰時，負責當前的區塊領導節點往往是第一個崩潰的。 Solana 的低冗餘設計嚴重依賴領導節點是否在線 – 其他節點都沒有與當前領導節點相同的交易數據或網路角色。這意味著一旦領導節點離線，網路的其他部分需要做大量的應急工作：同意跳過一個區塊，重新組織交易數據，並將丟失的交易數據轉發給下一個領導節點……

考慮以太坊網路，它沒有領導節點，每個節點都有一份精確和重複的副本，這份副本中包含有將被放入一個區塊（mempool）的交易數據。如果任何以太坊節點離線，所有其他節點手頭仍有他們需要產生一個新區塊的所有內容。這就是冗餘的雙刃劍：在理想的情況下，冗餘導致了網路的緩慢；但在壞的情況下，它可以防止重大事故。

讓我們用數字來說明。根據這篇論文，在領導者節點崩潰的情況下（正式稱為「級聯領導者故障 cascading leader failure」），Solana 的緊急計算量開銷可以達到 O(n^4)。一個 O(n^2) 的網路很慢，但可以使用，然而一個一下子需要 O(n^4) 計算量的網路就好比死了。這就是為什麼 Solana 一旦進入 O(n^4) 級聯領導故障模式，就難以自行恢復的主要原因。

這是一種特性，不是 BUG

Solana 的基因是激進的以最佳性能為優先。這個原則在架構中無處不在，所以很難只改變一個地方而不改變其他一切。（我們沒有討論這個問題，但為了說明相互依賴性，如果在 CPU 而不是 GPU 上運行，核心的 PoH 算法將是不切實際的，而 Solana 的 PoH—最理想情況下進行性能優化的數據管理系統使其難以實現類似 ETH 的 mempool）。再次說明，這是一個權衡，不能兩全其美——要從根本上使 Solana 更加穩定，需要創造更多的冗餘度，從而犧牲最理想情況下的性能。

即使是 Solana 的支持者，也需要做好心理準備，網路中斷和性能降低還會發生很多次，因為今天的 Solana 網路還遠遠沒有嘗試過所有可能的緩解措施。緩解措施是一個需要迭代的捉迷藏遊戲。有一天，Solana 實驗室的努力工作可能使 99.99% 的網路正常運行時間成為可能。但是，它從來都不意味著要達到 100% 的網路正常運行，今天的主網 beta 版離 99.99% 也還很遠。

第三部分：Aptos 加入了競爭和高性能的三難問題

這部分包括：

Aptos 的設計選擇是在可靠性和性能之間的折衷，位於 Solana 和 Ethereum 之間
我們提出了高性能、可靠性和效率之間的高性能三難問題
對開發者來說，未來的趨勢是根據具體使用場景進行優化。我們提出了一個 3 個問題的問答手冊來幫助開發者選擇基礎設施

在過往整整一年多的時間裡，Solana 仍然是高性能 L1 細分市場裡唯一的名字。現在我們有了 Aptos，由 Facebook 的前 Libra 團隊開發，並由 a16z、Tiger、Multicoin 和 FTX 投資。Multicoin和 FTX 明顯也是 Solana 的重注投資者。Aptos 最近成為頭條新聞，因為他們聲稱有 16 萬的 TPS，顯然將自己定位為 Solana 的競爭對手。

這也是時我們為什麼花這麼多時間來剖析 Solana 的原因：這是一個最好的角度來結合實際理解 Aptos：

回顧第二部分，以太坊對網路能夠正常運行的時間進行了優化：以太坊花費了大量的數據冗餘來為最壞的情況做準備，所以幾乎不可能用攻擊來使以太坊網路中斷。而 Solana 是為最理想情況下的性能進行了優化，在冗餘上花費較少，從而使網路在極端情況下的可靠性降低。

在解決冗餘度困境時，Aptos 試圖從 Solana 退一步。下面是它的一些關鍵設計選擇：

Aptos 設計選擇 1：16 核服務器級 CPU

這是 Solana 的 4096 個 GPU 核心和以太坊的 1 個 CPU 核心之間的一個中間地帶。在處理高度可並行的任務時，Aptos 可能不如 Solana 快。 Aptos 的每個 CPU 核心都比 Solana 的 GPU 核心性能高得多，所以在 NFT mint 等邏輯上按順序交易的情況下，Aptos 可能比 Solana 處理得更好。

Aptos 設計選擇 2：最理想情況冗餘為 O(n)，最差情況冗餘為 O(n^2)

相對於 Solana，Aptos 試圖透過增加冗餘使其網路更具彈性。 Aptos 沒有試圖達到 Solana 的極端 O(log n) 次線性冗餘度，而是設置為 O(n) 的冗餘度。在每一輪共識中，Aptos 要求所有非領導者的節點同步額外的數據，以備當前領導者節點失敗時其他節點需要接管。Aptos 也沒有嘗試對區塊進行分割和驗證，因為分割會在出錯的情況產生額外的工作量。這麼設計的結果是：當領導者節點確實失敗時，Aptos 的應急處理並沒有 Solana 那麼混亂。

比較一下：Aptos 的最佳性能不如 Solana，但 Aptos 在最差情況下的表現更容易接受——O(n^2)，而 Solana 為 O(n^4)。如果我們把這五個性能表現放在一起，它們剛好是一個漂亮的三明治，把 Aptos（紫色）夾在 Ethereum（藍色）和 Solana（綠色）之間。

Aptos 設計選擇 3：瘋狂的硬體要求

你們可能已經看到 Aptos 聲稱有 16 萬的 TPS，並想知道為什麼我說其最理想情況下的性能不如 Solana 好。

注意 Aptos 的硬體要求：他們所有的測試都是在 AWS EC2 實例上運行的，有 16 核服務器級別的 CPU。 Aptos 還公開建議在谷歌雲平台上運行他們的節點，而不是個人電腦。

16 萬這個數字是在大約 100 個有權限的節點上進行的實驗室測試的結果——在更複雜的實際生產環境中，如果節點更多，TPS 肯定會更低。 Aptos 的內部測試也表明，隨著網路擴展到更多節點，其性能將接近甚至低於 Solana 目前的 65,000 TPS。

下面是對 Aptos、Solana 和以太坊關鍵技術規格的快速總結，供參考：

把所有東西放在一起總結一下：高性能的三難問題

把問題擴展到冗餘困境，同時把 Aptos 變態的硬體要求也考慮在內，我們提出了一個 Vitalik 的區塊鏈可擴展性三難問題的翻版：高性能三難問題。

在這個三難問題中，三個不能同時滿足的符合第一性原則的特質如下：

可靠性：透過在冗餘度上花費更多的計算來保證網路正常運行時間
性能：透過在冗餘上花費更少的計算來加強網路的吞吐量
效率：提升可靠性和性能的唯一方法是獲取更多的計算資源來用於這兩方面

在以太坊、Solana、Aptos 三者中：

以太坊選擇了網路正常運行時間和效率，所以它在冗餘度上花費了的一定的計算量，導致性能緩慢。
Solana 選擇了性能和（相對）效率，所以它把有限的計算量都花在了最佳情況的性能上，較低的冗餘度導致可靠性受到了負面影響。
Aptos 選擇了網路正常運行時間和高性能，所以為了有足夠的計算來覆蓋這兩個方面，Aptos 不得不選擇基於服務器的節點，放棄了效率。

Aptos 的設計理念相當 Web 2：強調對用戶的友好，而不是去中心化。早期的描述表明，Aptos 可能會整合一個帶有密碼恢復功能的高級用戶帳戶系統。從任何角度看，Aptos 肯定不是最去中心化的區塊鏈。它並不以意識形態的純粹性為目標。來自 a16z 和 Tiger 的 2 億種子輪投資者將一些真正的資金和資源放在這個有點逆向的願景背後。