詳談Solana的技術架構：為什么Solana沒有被Ethereum殺死？

2023-09-20 16:09:04

原文來源：Haotian，區塊鏈安全從業者

在熊市的基底下，大家會冷靜思考一些牛市可能忽略的東西，比如，重回公衆視野的 Solana ，技術到底行不行，一句「中心化宕機」就能毀所有嗎？

最近， MakerDAO 說 Solana 的 codebase 還不錯， Visa 也宣布要和 Solana 試點合作，Solana 的 TVL 等數據指標也回暖不少，Solana 要迎來第二春嗎？到底該怎么解讀？

牛市正當時的時候，面對$SOL 突突上漲的幣價，大家都說 Solana 的資本背景和 Community 生態很強，鮮有人能說清楚 Solana 的技術框架到底怎樣。

不吹不黑，本文從科普角度淺析下 Solana 的背後的技術架構，以及為什么 Solana 沒有被 Ethereum 殺死的原因。

Tips：僅本着技術科普的角度，帶大家重新認識和理解 Solana，不做任何投資參考。

POH 共識機制

首先說說 POH 共識機制，即（Proof of history），它是 Solana 採用的特殊創新機制。傳統意義上區塊時間和物理時間並沒有關系（弱關聯），比如比特幣以太坊等公鏈的時間基准為塊高度，時間流逝的表現載體也只是塊高度的不斷疊加，因此坎昆升級這種具體時間只能根據網絡出塊速率進行預估。

Solana 的 POH 創新點就在於把鏈的時間流逝和物理時間錨定了，比如：每個 POH 出塊的間隔時間是固定的，連續的哈希運算會產生一個可驗證的時間序列等等。

這樣做可以避免「主觀」時間帶來的操縱和攻擊問題，試想若出塊時間不規律，節點之間很難快速達成共識，就容易產生回滾、重放等攻擊，而物理時間的客觀性是無法撼動的，節點無需回溯全部歷史數據僅依據當前時間序列就能監測一些異常情況。

因此，POH 的創新就是為了強綁定物理時間，以促進 Solana 節點之間更好協作和達成共識。

在我看來，POH 機制還有一個優勢：節點批量接收大量交易並進行排序（Pipeline），要等待 POH 時間戳來遞交交易，等同於 layer 2 向 layer 1 Batch 交易一樣，這種機制如同把 Rollup 的思想帶入了 layer 1 中，為下面要說的高吞吐和並行處理等提供了先決條件。

存儲和計算分離特性

其次來看「存儲和計算分離」特性，它讓 Solana 擺脫了 Data Availability 的瓶頸限制。

傳統的區塊鏈驗證框架要依賴全節點發布大量歷史數據來實現即時計算變更狀態，這種計算和存儲的耦合某種程度上會限制鏈的性能。比如以太坊要更新狀態時要先同步全鏈數據然後執行歷史記錄計算，加之以太坊是順序出塊並不能串行因此出塊時間和單區塊容量都會受限。

而 Solana 將狀態存儲和交易執行進行了分離，有個單獨的存儲系統來保留狀態，包括账戶信息、籤名者歷史和交易記錄等狀態，有新交易執行時，Solana 會在 Pipeline 節點上高速運算，最後只更新狀態到存儲系統中。二者分離，可以確保账本系統快速運行，避免了 DA 校驗狀態時間+計算等待 DA 校驗結果的時間損耗。要注意的是，網絡計算和存儲資源需要通過質押 SOL 獲取。

通俗來比喻，以太坊的工人要到倉庫取原材料再去車間加工，兩份職責來回奔波效率低；而 Solana 兩個車間都有專門的工人，搬運工只需要把臨近使用的材料不定時搬到生產車間就好了，大大提升了效率。

高並發交易處理

再好好解析下「高並發交易處理」特性，這讓 Solana 接軌 web2 市場需求有了可行性。

雖然 Solana 宣稱自己有 70 萬的 TPS 在其偶爾的宕機背景下被當成了笑話，但 MakerDAO 的 Endgame 選擇，Visa 的選擇某種程度上是對其性能極限的認可。那么，Solana 的高並發是如何做到的呢？

簡單來說，是前邊談及的 POH 和計算存儲分離等優勢共同鑄就的，便於讓大家深刻理解，我試着把他和 Starknet 的高並發做一個對比。

Solana 收到用戶 Alice 同時發出的 10 筆交易，節點會對交易進行排序，等到 POH 時間戳來 Batch 打包，然後等下一個時間戳到來時，節點會調用獨立存儲系統的狀態數據，檢測 10 筆交易是否存在狀態衝突，若無衝突就可正常把 10 筆交易打包到一個區塊中，若存在衝突，存在衝突的區塊會被排除在本次打包之外。

不同的是，Starknet 網絡的 Alice 由於在一套账戶抽象模型下， 1 個账戶發布的交易本身就不能存在狀態衝突，可以同時執行 Approve 和 Transfer，因為他們修改的是合約不同的狀態，Approve 對應 Allowance，Transfer 對應 Balance，但若同時執行兩筆 Transfer 的話就要同時修改 Balance，就容易導致狀態衝突導致計算錯誤。因此账戶抽象特性是 Starknet 高並發的基礎。

舉個通俗的例子，Solana 的並行方式如同一個餐廳安排了多個服務員同時為客戶點餐，每個服務員處理一個交易线程，點餐順序也由服務員來協調，若有相同的菜品後廚可以並行上菜；而 Starknet 的並行方式則相當於用自助點餐機掃碼點菜，客戶可以同時在多個機器上接收訂單，由後臺中控系統統一協調訂單。

總之，高並發的宗旨都是在網絡秩序不紊亂的前提下合理高效利用系統資源。

Solana 的服務員就是被大家吐槽的高昂成本的節點運維系統，而 Starknet 的自助點餐機就是那套和合約兼容的账戶抽象基礎。

有了對 Solana 技術底層的深刻理解，再來看一些被詬病的問題，或許會有不同的答案。

在我看來，Solana 的問題出在技術實現邏輯過於復雜： 1）Solana 的節點運維成本過高，導致節點數量受限，其去中心化能力也受到牽制；2）POH+POS 的共識機制，需要節點有強大計算和帶寬資源才能承載高並發，而資源成本越高，節點運維成本就越大；3）高並發處理時也難免存在狀態衝突、網絡負載等問題；

有人說，Solana 在用 web2 的思維做 web3 網絡，它的技術創新起點高於已有區塊鏈架構，如果把它的問題當成創新路上的容錯率，或許會有不一樣的評價。

創新的代價也許正如大家看到的那樣，眼看他高樓起，眼看他樓塌了，但若創新的基底在，這塌方的樓會不會再次拔地而起呢？

Note?item_id=888" target="_blank" rel="noopener noreferrer">查看更多 ? item_id= 888" target="_blank" rel="noopener noreferrer">查看更多? item_id= 888" target="_blank" rel="noopener noreferrer">查看更多? item_id= 888" target="_blank" rel="noopener noreferrer">查看更多? item_id= 888" target="_blank" rel="noopener noreferrer">查看更多? item_id= 888" target="_blank" rel="noopener noreferrer">查看更多? item_id= 888" target="_blank" rel="noopener noreferrer">查看更多? item_id= 888" target="_blank" rel="noopener noreferrer">查看更多? item_id= 888" target="_blank" rel="noopener noreferrer">查看更多? item_id= 888" target="_blank" rel="noopener noreferrer">查看更多? item_id= 888" target="_blank" rel="noopener noreferrer">查看更多? item_id= 888" target="_blank" rel="noopener noreferrer">查看更多? item_id= 888" target="_blank" rel="noopener noreferrer">查看更多? item_id= 888" target="_blank" rel="noopener noreferrer">查看更多? item_id= 888" target="_blank" rel="noopener noreferrer">查看更多? item_id= 888" target="_blank" rel="noopener noreferrer">查看更多? item_id= 888" target="_blank" rel="noopener noreferrer">查看更多? item_id= 888" target="_blank" rel="noopener noreferrer">查看更多? item_id= 888" target="_blank" rel="noopener noreferrer">查看更多：本人不持有 SOL，以上分析僅為技術+商業視角的冷靜思考和觀察，且在通俗化解讀過程中存在不嚴謹之處，大家權當科普文看看，切莫作為投資參考。