Solana 與以太坊：為什麼他們的交易速度不同？

共識機制架構

1. Solana 採用歷史證明 (PoH)，這是一種可驗證的延遲函數，可在交易進入共識層之前以加密方式為交易添加時間戳記。這種預排序消除了驗證者在區塊生產期間協商排序的需要。

2. 以太坊依賴提議者與建構者分離的權益證明（PoS），其中區塊建構者競爭建構最佳區塊，而提議者從中進行選擇。交易順序是在插槽執行期間動態決定的。

3. PoH 使 Solana 驗證器能夠並行處理數千個交易，而無需交叉驗證器協調開銷，從而直接有助於亞秒最終確定。

4.以太坊的共識設計優先考慮審查阻力和去中心化而不是原始吞吐量，需要順序驗證每個區塊內的交易效果。

5. Solana 架構中缺乏全域狀態鎖定，允許跨非重疊帳戶集並發執行，而以太坊的 EVM 則強制執行每個區塊的嚴格串列執行。

執行引擎設計

1. Solana 的 Sealevel 運行時透過在調度之前在指令層級分析讀取/寫入帳戶依賴性來並行執行交易。

2. 以太坊的 EVM 以 Gas 排序順序一次處理一筆交易，無論底層硬體功能如何，都使得執行本質上是線性的。

3. Sealevel 要求開發人員明確聲明帳戶存取模式，從而在執行開始之前啟用確定性衝突偵測。

4. EVM不需要此類聲明；衝突僅在執行時出現，當發生狀態不一致時強制重新執行或拒絕。

5. Solana 中的平行執行減少了每筆交易的平均延遲，但由於明確的並發管理，增加了智慧合約開發的複雜性。

網路級吞吐量約束

1. Solana 的目標是在理想條件下達到 65,000 TPS，並由使用 GPU 和自訂加密庫的硬體加速簽章驗證提供支援。

2. 以太坊目前的後 Deneb 容量仍限制在 L1 接近 100 TPS 的範圍內，大多數大容量活動轉移到獨立於基礎層瓶頸運行的匯總操作。

3. Solana 的驗證器集在嚴格的硬體要求下運作 - 節點必須維持 10 Gbps 頻寬和 NVMe 儲存 - 以在其高頻領導輪換中保持同步。

4. 以太坊驗證器在具有寬鬆 I/O 需求的商品硬體上運行，以原始速度換取更廣泛的參與和容錯能力。

5. Solana 中的網路傳播延遲透過 Turbine 最小化，Turbine 是一種區塊分發協議，可將區塊分割成更小的資料包，並跨地理區域同時多播它們。

交易失敗動態

1. Solana 的交易失敗率約為20% ，這主要是由於資源耗盡、時序違規以及峰值負載期間的帳戶鎖定爭用造成的。

2. 以太坊的失敗率接近0.1% ，反映了保守的 Gas 估算實踐和從 EVM 設計繼承的內建執行保障措施。

3. Solana 上失敗的交易即使恢復也會消耗計算預算和網路頻寬，從而為用戶和驗證者帶來可衡量的成本。

4. 以太坊的 Gas 機制確保失敗的交易僅消耗為其執行嘗試支付的 Gas，從而限制對經濟激勵的附帶損害。

5. Solana 上的高故障率與記憶體池擁塞和快速領導者過渡時期密切相關，從而暴露了架構對即時網路變化的敏感度。

零值轉移行為

1. 所有 Solana 交易中約7.6% 的交易價值為零，通常用於帳戶初始化、程序升級或 CPI 呼叫腳手架。

2. 以太坊僅記錄了0.66% 的零價值轉移，因為其交易模型將價值轉移與執行意圖緊密耦合。

3. Solana 的帳戶模型將每個指令視為一流的交易實體，從而無需原生價值移動即可實現原子多指令捆綁。

4.以太坊以交易為中心的模型即使對於簡單的狀態突變也需要明確的 ETH 轉移或 ERC-20 批准，這不鼓勵零價值使用模式。

5. Solana 上零值流量的盛行反映了應用程式與鏈狀態互動方式與使用者發起操作方式之間更深層的結構差異。

常見問題解答

Q：Solana 的高 TPS 是否是以去中心化為代價的？答：是的。 Solana 的驗證器要求（包括高頻寬連線、低延遲 NVMe 儲存和 GPU 加速）排除了低資源參與者，導致驗證器集明顯小於以太坊。

Q：為什麼以太坊不能簡單地採用 PoH 來提高速度？答：PoH 假設同步時脈和確定性網路延遲，這與以太坊在對抗性、異質網路條件下可靠運作的設計原則相矛盾。

Q：Solana 的平行執行優勢是否可供所有開發人員使用？答：不行。開發者必須手動註釋帳戶存取模式和結構邏輯，以避免執行時間衝突，與以太坊的即插即用 EVM 相容性相比，提高了進入門檻。

Q：以太坊如何在將規模委託給 L2 的同時保持安全性？答：以太坊透過呼叫資料發布和詐欺/有效性證明確保 L2 資料可用性，確保 L2 狀態轉換保持錨定於 L1 結算層並可由 L1 結算層驗證。