由比特幣的工作坊走進 Solana 的廚房

比特幣有一套腳本語言——Script——並且是刻意設限的。它並非圖靈完備，不容許迴圈，只支援基本操作：驗證簽名、時間鎖（timelock）及多重簽名（multisig）方案。這種簡潔令比特幣的行為可預測，並縮小了執行面——不過網絡的安全性同時取決於協議中的許多其他組件。

以太坊走的是另一條路：它引入了 EVM（Ethereum Virtual Machine），一個圖靈完備的環境，可供智能合約運行。在協議層面，狀態轉換是循序進行的，儘管某些實作能把內部工作部分並行化。

Solana 則以截然不同的架構回應可擴展性的挑戰：SVM（Solana Virtual Machine）以及 Sealevel 執行環境。

Solana（及 SVM）的帳戶模型

在以太坊，狀態「屬於」智能合約——數據就存放在合約之內。在 SVM 中，架構則是分離的：

– 程式碼存放於程式帳戶（program account）；能否更新，取決於部署機制及被指定為 authority 的主體
- 數據（狀態）存放於由程式管理的獨立帳戶中

因此 Sealevel 可以事先分析交易：若交易 A 涉及帳戶 {X, Y}，而交易 B 涉及帳戶 {Z, W}，兩者便可並行執行，互不衝突。

這套模型讓不觸及同一批帳戶的交易得以並行執行。這有機會提升處理容量，但單憑這一點，並不足以就同等硬件條件下相對 EVM 的量化優勢作出任何結論。就 Bitcoin Hyper 而言，迄今並未公布任何具體的效能測試。

這對開發者意味著什麼

SVM 程式以 Rust（或 C/C++）撰寫，並編譯為 eBPF 位元組碼。最常用的框架是 Anchor，它加入了一系列宏與慣例，簡化開發工作。

Bitcoin Hyper 的文件把與 Solana 生態的直接相容性列為目標，並形容為「drop-in compatibility」。按該項目所述，現有程式只需作有限修改即可運行——例如更改 RPC 端點及若干網絡參數。文件亦假定與 Solana CLI、Anchor 及 IDE 外掛等工具相容。實際的相容程度仍有待獨立查證。

若真能達致這種程度的相容，或可降低熟悉 Solana 的開發者的入門門檻。不過，兩個網絡共用建基於 SVM 的環境，並不保證程式、API、系統程式、工具或執行環境行為都能相容。這仍屬設計目標，而非經獨立查證的結果。

仍待釐清之處

有幾點值得坦白說明：

完整相容性未經獨立查證：開發網採取選擇性開放，公開測試有限
收費模型的差異：按項目文件，Bitcoin Hyper 以 $HYPER 而非 SOL 收取手續費，意味部分抽象層有所不同
對 Solana 系統程式的依賴：Solana 上部分應用建基於系統程式（例如官方 Token Program），而這些程式未必以相同形式提供

「drop-in」相容性的說法仍有待查證。要作出評估，前提是具備公開技術文件、足夠的開發網存取權限，以及涵蓋程式、工具與系統依賴的可重現測試。

特許經營的比喻

可以把 SVM 想像成特許經營餐廳的廚房。食譜相當於程式碼，門市則相當於程式運行所在的網絡。Bitcoin Hyper 的目標是提供與 Solana 相容的工具；然而迄今並未證明所有組件完全相同，也未證明結果在任何情況下都一致。

分別在於主要原料：這個廚房的「燃料」應是 $HYPER，而非 SOL。

為比特幣用戶解說 Solana 虛擬機（SVM）