Bitcoinユーザーのために解説するSolana Virtual Machine
Bitcoin Hyperはなぜ、実行環境としてSolana Virtual Machineを用いることを提案しているのか。Bitcoinには詳しいものの、スマートコントラクトに初めて触れる読者に向けた解説です。
教育目的の記事です。本記事の内容は、情報提供と解説のために提供するものであり、金融助言ではありません。免責事項の全文をご覧ください。
Bitcoinの書き物机から、Solanaの厨房へ
BitcoinにはScriptと呼ばれるスクリプト言語がありますが、その機能は意図的に限定されています。チューリング完全ではなく、ループを持たず、署名の検証、タイムロックの検証、マルチシグの構成といった基本的な操作しか行えません。この単純さこそが、安全性と予測可能性を支えています。
Ethereumは逆の道を選びました。チューリング完全な環境である EVM（Ethereum Virtual Machine）を導入し、誰もが任意のプログラム（スマートコントラクト）を書けるようにしたのです。強力ではあるものの、欠点があります。実行が逐次的であることです。コントラクトは一度に一つずつ、順番に処理されます。
Solanaは、スケーラビリティの課題に対して根本的に異なるアーキテクチャで応えました。SVM（Solana Virtual Machine）と Sealevel ランタイムです。
Solana（およびSVM）のアカウントモデル
Ethereumでは、スマートコントラクトが自らのステートを「保持」します。データはコントラクトの内部に置かれます。SVMでは、この両者が分離されています。
- - コード（プログラム）は、変更不可のアカウントに置かれます
- - データ（ステート）は、プログラムが制御する別のアカウントに置かれます
これによりSealevelは、トランザクションを事前に解析できます。トランザクションAがアカウント{X, Y}に、トランザクションBがアカウント{Z, W}に触れるのであれば、両者は並列に競合なしに実行できます。
その結果、同じハードウェア上でEVMが達成する水準を大きく上回るスループットが得られます。
開発者にとっての意味
SVMのプログラムは Rust（またはC/C++）で記述され、eBPFバイトコードにコンパイルされます。最も広く使われているフレームワークは Anchorで、開発を簡素化するマクロと規約を提供します。
Bitcoin Hyperが掲げる目標は即時の互換性です。プロジェクトの資料によれば、既存のSolanaプログラムは最小限の変更——RPCエンドポイントといくつかのネットワーク設定のみ——でHyper上で動作するとされています。同じツール（Solana CLI、Anchor、IDEプラグイン）もそのまま使えるとされています。
これが実現すれば、決して小さくない競争優位となります。Solanaのエコシステムには数千人の開発者と膨大な既存プログラムがあります。それらをBitcoin Hyperに持ち込めれば、参入の敷居は大きく下がります。ただし現時点では、これは表明された目標であり、独立に検証された結果ではありません。
まだ明らかでない点
そのうえで、率直に述べておくべき点がいくつかあります。
- 完全な互換性は独立に検証されていない。DevNetのアクセスは限定的で、公開された検証も限られています。
- 手数料モデルが異なる。Bitcoin Hyperは手数料にSOLではなく$HYPERを用いるため、一部の抽象化が異なります。
- Solanaのシステムプログラムへの依存。Solanaのアプリケーションの一部は、公式のToken Programなどのシステムプログラムに依存しており、それらが同じ形で利用できるとは限りません。
「即時の互換性」という主張は、真剣に受け止めるに値すると同時に、批判的に検討されるべきものです。前提を置く前に、DevNetで検証してください。本番環境における独立した検証は、まだ行われていません。
フランチャイズのたとえ
SVMをフランチャイズ店の厨房と考えてみてください。レシピ（Rustのコード）はどこでも同じです。店舗は異なるかもしれませんが（Solanaのmainnetではなく、Bitcoin Hyper）、設備（SVMランタイム、Anchor）は同一です。出てくる料理は同じはずです。
違いは主たる材料にあります。この厨房の「燃料」はSOLではなく$HYPERです。