詳談Solana的技術架構：為什麼Solana沒有被Ethereum殺死？
原文來源：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，以上分析僅為技術+商業視角的冷靜思考與觀察，且在通俗化解讀過程中存在不嚴謹之處，大家權當科普文看看，切莫作為投資參考。
