Solana Sealevel：並列処理エンジン

Solana Sealevelの並列処理により、ランタイムは、読み取りおよび書き込みを行うアカウントを宣言したトランザクションが競合しない場合に、それらを同時に実行できます。したがって、Sealevelは実行モデルであり、単独のコンセンサスメカニズムや、すべてのワークロードが並列で実行されることを保証するものではありません。

この記事のパフォーマンス数値には背景が必要です。広く引用されている65,000 TPSという数値は、理論上または管理されたテストでのベンチマークであり、メインネットでのスループットを保証するものではありません。約400ミリ秒のスロットターゲットは、トランザクションのファイナリティと同じではなく、手数料は署名、計算の使用量、優先設定、およびネットワーク条件によって異なります。

イーサリアムはベースレイヤーで1秒あたり約15件のトランザクションを処理します。Solanaのドキュメントでは歴史的に、理論上または管理された条件下で最大65,000 TPSと引用されてきましたが、実際のユーザー向けスループットは異なります。その差は偶然ではありません。その背後にあるエンジンはSealevelと呼ばれます。

SealevelはSolanaの並列スマートコントラクトランタイムです。独立した数千のトランザクションを一つずつではなく同時に処理する実行エンジンです。これは、Solana Labs（Solanaのコアプロトコル開発を担当する会社）の創設者であり、2017年に基礎となるSolanaのホワイトペーパーを執筆した元Qualcommのエンジニア、Anatoly Yakovenko氏によって構想されました。

ラッシュアワーの主要な高速道路を想像してみてください。Solana（ブロックチェーン、または分散型の改ざん耐性のあるデジタル台帳）は、Sealevelを使用して数百の車線を構築し、入ってくるトラフィックを目的地別に分類します。イーサリアムのすべての車は、単一の車線を使用しなければなりません。車は互いの後ろに並び、一台ずつ前進します。Sealevelは車を目的地別に分類します。異なる住所に向かう車は同時に移動し、待ち時間はありません。全く同じ住所に向かう車だけが列に並ばなければなりません。その分類メカニズムこそが、Solanaの速度の優位性の背後にあるアーキテクチャ上の洞察です。

この解説書では、Sealevelとは何か、そのアカウントベースの並列性がメカニズムとしてどのように機能するのか、イーサリアムの実行環境との比較、その欠点、そしてSolanaを評価する開発者や投資家にとってこれらの機能が何を意味するのかについて説明します。

Solana Sealevel並列処理：クイック概要

• Sealevelは、数千のトランザクションを同時に処理するSolanaの並列スマートコントラクトランタイムです。
• 仕組み： トランザクションは事前にアカウントの依存関係を宣言します。Sealevelは競合しないトランザクションを並列に実行します。
• スループット： 理論上の最大値は約65,000 TPSですが、実際の非投票トランザクションは通常2,000～4,000 TPSに達します。
• イーサリアムとの比較： イーサリアムのイーサリアム仮想マシン（EVM）はトランザクションを一つずつ処理しますが、Sealevelは独立したトランザクションを同時に処理します。
• 正直な限界： Solanaは2021年と2022年に、Sealevelの上流での取り込み失敗によりネットワーク停止を経験しました。

逐次実行 vs. 並列実行：Sealevelが解決する核心的な問題

逐次実行と並列実行は、ブロックチェーンのトランザクションを処理するための根本的に異なる2つのアプローチであり、この違いがSolanaとイーサリアムのパフォーマンス差の大部分を説明しています。

逐次実行とは、次のトランザクションが開始される前に、前のトランザクションが完全に完了することを意味します。トランザクションが到着すると、ブロックチェーンは関連する状態をロックし、計算を実行し、結果を書き込み、状態のロックを解除して、ようやく次のトランザクションを開始します。各ステップが後ろのステップをブロックします。オーバーラップも並行性も、独立した作業の同時処理もありません。

これによって生じるスループットの上限は現実的です。イーサリアム財団のドキュメントによると、イーサリアムのイーサリアム仮想マシン（EVM）は、レイヤー2（L2）ロールアップなしのレイヤー1（L1）ベースチェーンで、1秒あたり約15〜30件のトランザクションを処理します。ボトルネックがアーキテクチャ上の理由であるため、その数値は何年もほぼ一定のままです。

より広範な課題は、広く引用されているスケーラビリティのトリレンマ、つまり、ブロックチェーンは歴史的に、高度なスケーラビリティを実現しながら分散化とセキュリティを最大化することに苦労しているという観察結果に集約されています。逐次実行は、主要なスケーラビリティの制約です。実行モデル自体が単一のパイプラインを通じてすべての作業をシリアル化するため、より高速なハードウェアを追加しても解決されません。

並列処理は異なる答えを提示します。すべての顧客に対して一人のレジ係がいるのではなく、500のレジがあるスーパーマーケットを想像してみてください。全く異なる商品を購入する顧客（支払い端末を共有せず、ポイントアカウントも共有しない）は、すべてのレーンで同時にチェックアウトできます。端末を本当に共有する必要がある顧客だけが、そのために列に並ばなければなりません。店舗の総スループットは、個々のレジ係が速くなったからではなく、独立したトランザクションが互いにブロックしなくなったために、桁違いに増加します。

スマートコントラクトランタイムは、ブロックチェーン上でスマートコントラクトコードを実行するソフトウェア環境です。プログラムコードを受け取り、実際に実行するレイヤーです。Solanaでは、スマートコントラクトは「プログラム」と呼ばれます（これはSolanaのドキュメントにおける正式な用語ですが、「スマートコントラクト」も広く理解されており、ここでは同じ意味で使用されています）。SealevelはSolanaのランタイムであり、数千のこれらのプログラムを逐次的ではなく同時に実行するためにゼロから構築されました。

レースコンディションや状態の破損を起こさずに、Sealevelがこれを安全に達成する方法を理解するには、並列処理を安全にするアーキテクチャ上のメカニズムを理解する必要があります。そのメカニズムこそが、Solanaのアカウントモデルです。

Sealevelの仕組み：アカウントモデルと事前の状態宣言

Sealevelは、2つのアーキテクチャ上の特徴が連携することで、安全な並列実行を実現しています。Solanaのアカウントモデルと、歴史の証明（Proof of History: PoH）によって提供されるトランザクションの事前順序付けです。PoHは、Solanaネットワーク上のすべてのイベントに対して検証可能なタイムスタンプを作成する暗号時計メカニズムです。このセクションでは、その両方について説明します。

Solanaアカウントモデル：コードと状態の分離

Sealevelがトランザクションを並列に実行できるのは、Solanaのアカウントモデルが、実行を開始する前に安全に実行するために必要な情報を与えてくれるからです。

Solanaでは、プログラムには実行可能なコードのみが含まれ、プログラム自体にはデータは保存されません。これらはステートレスなプログラムです。命令を運びますが、自身の状態は保持しません。データは、プログラムが読み書きできる個別のアカウントオブジェクトに存在します。この設計により、アーキテクチャレベルでコードと状態が分離されます。これは、スマートコントラクトが実行可能コードとその状態の両方を単一のコントラクトアドレスに保存するイーサリアムのモデルとは異なります。

Solanaのすべてのトランザクションは、実行を開始する前に、どのアカウントから読み取り、どのアカウントに書き込むかを事前に宣言する必要があります。Sealevelはこれらの宣言を読み取り、実行をスケジュールします。このステップをスキップしたトランザクションは、ランタイムによって拒否されます。これはオプションの管理業務ではなく、安全な並列処理を可能にする構造的な前提条件です。

6つのコンロがあるキッチンで働く2人のシェフを想像してみてください。シェフAはパスタを作っており、コンロの1番と2番を必要としています。シェフBは野菜炒めを作っており、コンロの4番と5番を必要としています。彼らの作業面は重なっていないため、調整なしに同時に作業できます。どちらも相手を待つ必要はありません。両方のシェフが同時に3番のコンロを必要とする場合にのみ、一方が待たなければなりません。Sealevelはこの正確なロジックをトランザクションに適用します。異なるアカウントを使用するものは並列に実行され、書き込みアカウントを共有するものは逐次実行されます。

開発者ノート: ランタイムは、未宣言のアカウントにアクセスするトランザクションを拒否します。アカウントへのアクセスは実行時ではなく、トランザクションの構築時に決定されなければなりません。この制約は、以下で説明する並列スケジューリングを可能にする設計メカニズムです。

Sealevelがどのように並列実行をスケジュールするか

トランザクションがSealevelに到達すると、スケジューリングプロセスは4つの明確なステップに従います。

1. トランザクションがマニフェスト（読み取りを行うアカウントと書き込みを行うアカウントの完全なリスト）を伴って到着します。
2. Sealevelは、保留中のすべてのトランザクションのマニフェストを同時に比較することにより、依存関係グラフ（どのアカウントを共有しているかのマップ）を構築します。
3. 書き込みアカウントを共有していないトランザクションは独立しています。Sealevelはそれらを別々のプロセッサコアに同時にディスパッチし、利用可能なすべてのCPUおよびGPUコア全体で並列に実行します。
4. 同じアカウントに対して書き込み依存を宣言しているトランザクションは競合状態にあります。Sealevelはそれらの特定のトランザクションをシリアル化し、PoHによって確立された順序で次々に実行します。その間、他の競合しないトランザクションは並列に実行され続けます。

このアプローチは「決定論的並列処理」です。Sealevelは実行が開始される前に競合を特定し、事後に解決することはありません。トランザクションを投機的に実行して失敗をロールバックすることはありません。この点が、AptosのBlock-STMのような、最初にトランザクションを投機的に実行し、競合が発生した際に再実行する楽観的並行性アプローチとは異なります。

Sealevelはまた、ゲーミングやAIのワークロードでGPUが数千のシェーダー計算を同時に実行するのと同様に、署名検証タスクをGPUコアにルーティングすることもできます。Solanaのトランザクション処理ユニット（TPU）は、パイプライン処理を使用してハードウェアユニット間でトランザクション検証ステージを同時に実行し、Sealevelはそのパイプラインの実行ステージを担当します。

Sealevel vs. Ethereum EVM：アーキテクチャの直接比較

SolanaがベースレイヤーでEthereumよりも高速である主な理由は、並列スマートコントラクトランタイムであるSealevelにあります。EthereumのEVMが1つのトランザクションを厳密な順序で一度に1つずつ処理するのに対し、Sealevelは複数のプロセッサコアにわたって数千の独立したトランザクションを同時に処理します。

SealevelとEVMの比較

EVMがトランザクションを一度に1つずつ処理するのは、そのステートフルなコントラクトアーキテクチャにより、どのトランザクションを並列化しても安全かを事前に判断することがアーキテクチャ上困難であるためです。Ethereum上のスマートコントラクトは独自のステートを保持します。理論上、任意の2つのコントラクトがステートを共有する可能性があり、どのトランザクションが独立しているかを事前に把握せずに並列化すると、ステートを破損させるリスクがあります。これはEthereumの設計上の欠陥ではなく、そのアーキテクチャの結果です。

Solanaはプログラムを、確立されたLinuxネイティブ形式から適応されたコンパクトな命令セットである、Solana独自の修正済みeBPF（extended Berkeley Packet Filter）バイトコードにコンパイルします。Sealevelはこのバイトコードをネイティブに近い速度で実行します。対照的に、EVMバイトコードはカスタムのソフトウェアエミュレートされた仮想マシン上で動作します。BPFアプローチは、EVMのカスタム形式にはないハードウェアレベルの最適化パスを提供し、命令実行レベルでのSealevelのスループットの優位性に寄与しています。

SolanaがEthereumとアーキテクチャ上で異なる点：

• 実行モデル： 並列決定論的（Sealevel） vs. シーケンシャル（EVM）
• ステートアーキテクチャ： ステートレスプログラムと個別データアカウント vs. ステートフルコントラクト
• スケーリングアプローチ： L1並列実行 vs. L2ロールアップとシャーディング
• 開発言語： Rust vs. Solidity

レイヤー1ブロックチェーンのアーキテクチャ間でアカウントモデルがどのように異なるかという文脈において、Solanaの事前宣言アプローチと他のオンチェーンストレージ設計との対比は示唆に富んでいます。

Sealevel vs. Aptos Block-STM および Monad：並列実行アプローチの違い

実稼働している並列実行アーキテクチャはSealevelだけではありません。そのアプローチをAptosのBlock-STMやMonad、さらにはSuiと比較することで、それぞれの設計がどのようなトレードオフを行っているかが明らかになります。

Aptosは、楽観的並行性アプローチであるBlock-STM（Software Transactional Memory）を使用しています。これは、事前の作成時のアカウント宣言を必要とせずに、投機的にトランザクションを並列実行し、その後結果を検証して競合が発生したトランザクションを再実行します。開発者にとっての利点は、構築時にアカウントの依存関係を宣言する必要がないことです。トレードオフは、競合の多いワークロードでは再実行が発生し、時間がかかることです。Sealevelは実行前に競合を特定するため、再実行を完全に回避します。

Monadは、EthereumのSolidityとの互換性を保ちつつ、並列EVM実行を目指しています。実行ステージをパイプライン化し、EVMモデルの上に楽観的並列処理を適用します。Monadの賭けは、EVM互換性がアーキテクチャ上のオーバーヘッドに見合う価値があるということです。Sealevelは逆の選択をしました。つまり、より高い生の並列性を備えた白紙状態のアカウントモデルを採用しましたが、開発者には新しいプログラミングパラダイムの採用を求めています。

Suiは、オブジェクトベースの所有権を並列処理の単位として使用します。独立したオブジェクトに触れるトランザクションは、明示的な宣言を必要とせず、定義上並列に実行されます。現在のドキュメントの時点では、それぞれのアプローチ（Sealevelの決定論的モデル、Block-STMの楽観的モデル、Suiのオブジェクト所有権モデル）は、「大規模に安全な並列処理をいかに実現するか」という同じ問いに対する異なる回答を提示しています。

どのアプローチも普遍的に優れているわけではありません。Sealevelの事前宣言は開発者のオーバーヘッドを生みます。Block-STMの楽観的モデルは、競合の激しい負荷の下で再実行コストが発生します。Monadは、Solidity互換性のために生のパフォーマンスの余裕を犠牲にしています。適切な選択は、ユースケースの要件やチームがすでに運用している開発エコシステムに依存します。

Solanaの8つのイノベーション・アーキテクチャにおけるSealevelの役割

Sealevelの並列処理が安全であるのは、実行が始まる前にProof of History（PoH）によって信頼できるトランザクション順序が既に確立されているためです。この依存関係を理解することで、SealevelがSolanaのより広範な8つのイノベーション・アーキテクチャにどのように適合しているか、そしてなぜコンポーネントを切り離して評価できないのかが明らかになります。

Solanaのアーキテクチャは、共同設計された8つのイノベーションに基づいています：PoH、Tower BFT、Turbine、Gulf Stream、Sealevel、Pipelining、Cloudbreak、Archivers。それぞれがトランザクションライフサイクルの異なるステージを担当します。Sealevelは実行レイヤーであり、プログラムを動かすエンジンです。

PoHは、Solanaネットワーク上のあらゆるイベントに対して検証可能なタイムスタンプを作成する暗号学的クロックメカニズムです。すべてのバリデーターはこのタイムスタンプの順序に合意します。トランザクションがSealevelに到達する頃には、順序の問題は既に解決されています。Sealevelは調整を行うのではなく、スケジューリングを行います。

これを組み立てライン（アセンブリライン）として考えてみてください。PoHは、検証済みの順序で事前に仕分けされた作業項目を運ぶベルトコンベアです。Sealevelは、そのラインで競合しない項目を同時に拾い上げて処理する作業員チームです。ベルトコンベアが既に順序を決定しているため、作業員は次にどの項目を扱うかを交渉する必要がありません。ベルトコンベアがなければ、作業員は絶えず立ち止まって調整を行う必要があり、並列処理のメリットは完全に失われてしまいます。

PoH（プルーフ・オブ・ヒストリー）がトランザクションの順序を事前に決定し、アカウントモデルが実行前の状態宣言を必要とするため、Sealevelは実行開始前にどのトランザクションが競合するかを特定します。実行してから衝突時に再実行する楽観的並行性モデルとは異なり、競合は事後ではなく事前に解決されます。

残りのイノベーションもそれぞれ補助的な役割を果たしています。Tower BFT（Solanaのコンセンスメカニズムであり、Practical Byzantine Fault ToleranceをPoH向けに最適化したバリアント）は、Sealevelが生成したブロックを検証します。Gulf Stream（メンプールレスのトランザクション転送プロトコル）は、ブロック確定前にトランザクションをバリデーターにプッシュするため、Sealevelは現在のブロックが決済される間に次のバッチの処理を開始できます。Cloudbreak（アカウントデータベース）は、数千の並列実行スレッドにわたる同時読み書きをサポートするようにSealevelと共同設計されています。

実環境でのパフォーマンス：Sealevelが実際に提供するもの（と不足している点）

Sealevelは逐次実行のブロックチェーンに対して実質的なスループットの向上をもたらしますが、実環境でのパフォーマンスは理論上の最大値を大幅に下回っており、ネットワークは重大な停止も経験しています。正直な評価のためには、これら両方の事実が重要です。

理論上のスループット vs 実環境のスループット

Solanaのスループットの数値には注意深い読み取りが必要です。一般的に引用される約65,000 TPS（Transactions Per Second）という数値は、典型的なメインネットのパフォーマンスではなく、理論上のアーキテクチャ上の上限を示しているからです。

公表されているTPSの数値には、バリデーター間の内部投票トランザクションが含まれていることが多く、これが報告される数値を膨らませています。非投票TPSこそが、実際のユーザー向けトランザクションのスループットを反映しています。

65,000 TPSという数値は、アーキテクチャ設計上の上限としては事実です。これは、最適なトランザクションプロファイルを持つ理想的な条件下でSealevelが処理できる能力を示しています。実環境の数値が低い理由としては、トランザクションの複雑さ、人気プログラムにおけるアカウントの競合、およびSealevel自体の上流にあるネットワークレベルの制約などが文書化されています。それでもなお、Solanaのメインネットのスループットは、約15〜30 TPSであるイーサリアムのベースレイヤー（イーサリアム財団ドキュメント）を大幅に上回っています。

Sealevelの並列実行機能は、マーケティング上の主張ではなく、文書化されたアーキテクチャ上の事実です。理論上のTPS数値はランタイムの設計を反映しており、実環境の数値はその周囲の運用環境を反映しています。

ネットワーク停止と混雑：正直な評価

Solanaは2021年と2022年に数回の大規模なネットワーク停止を経験しており、Sealevelを公平に扱うならば、ランタイムに並列処理能力があるにもかかわらず、なぜそれらの停止が発生したのかを説明しなければなりません。

2021年9月のインシデントは約17時間続きました。トークンローンチで優位に立とうとしたボットネットが、ネットワークのトランザクション取り込みレイヤーにスパムを浴びせ、パンクさせました。さらに2022年1月および2022年を通じて数回、重大な停止が発生しました。これらは公表された事後報告書（ポストモーテム）が存在する、記録された歴史的事象です。

これらの停止はSealevelの並列実行ロジックの失敗ではありませんでした。それらはSealevelの上流にあるトランザクション取り込みインフラの失敗でした。Sealevelの約65,000 TPSという能力は、どれだけの「有効な」トランザクションを処理できるかを示すものであり、ネットワークをトランザクションの洪水に対して無敵にするものではありません。100車線ある高速道路でも、10億台の車が同時にオンランプに進入しようとすれば渋滞します。処理能力の上限とスパム耐性は、別のエンジニアリング上の問題です。

数千のユーザーが同時にミントを試みるNFT (NFT) ミントイベントは、ネットワークが直面した中で最も激しい負荷スパイクの一部を引き起こし、同じ取り込みレイヤーのボトルネックを露呈させました。

Solanaはその後、いくつかのエンジニアリング上の対策を実施しました。トランザクション取り込みにおいてUDPに代わりQUICプロトコルを採用（より優れた混雑制御を提供）、ローカル手数料市場により負荷時にアプリケーションが優先手数料を設定可能にしました。また、Jump Cryptoが開発しているバリデータークライアント「Firedancer」は、スループットと回復力をさらに向上させることが期待されています。これらの対応は反復的な改善を示していますが、どのようなアップグレードであっても、オープンなトランザクション送信と限定された処理能力の間の根本的な緊張関係を完全になくすことはできません。

Sealevelのマルチコア並列実行には、バリデーターが高いスペックのハードウェア（高速なマルチコアプロセッサ、大容量のRAM、広帯域のネットワーク接続）を運用することも求められます。これはバリデーターの参加に対する実質的な障壁となり、Solanaのアーキテクチャの批判者が正当に指摘する分散型モデルとのトレードオフを表しています。

SealevelはSolana (SOL) にとって持続的な競争優位の堀（Moat）か？

SealevelはSolanaにベースレイヤーでの実質的なスループットの優位性をもたらします。その優位性が持続的な競争優位の堀を構成するかどうかについては、アーキテクチャ上の事実とエコシステムの変数を切り離して考える必要があります。

持続性の根拠は、統合の深さから始まります。Sealevelのアーキテクチャは、Solanaの他の共同設計されたコンポーネントと密接に結びついています。PoHはSealevelに届く前にトランザクションの順序を決定します。CloudbreakはSealevelの並列スレッドが必要とする同時ストレージ読み取りを処理します。Gulf StreamはSealevelが処理すべきトランザクションのバックログを削減します。このフルスタックなしでSealevelのパフォーマンスだけを模倣しても、その優位性は再現されません。この統合は、絶対的ではないにせよ、模倣に対する真の障壁となっています。

また、アカウントモデルは、Sealevelのパラダイムに基づいてプロダクションアプリケーションを構築した開発者にとって、実質的な乗り換えコストを生み出します。事前の勘定宣言、PDAパターン、Anchor開発フレームワークを中心に設計されたプログラムアーキテクチャは、大幅な再設計なしにはEVMチェーンに移植できません。Rustツール、Anchorのリソース、監査サービス、およびリファレンス実装のライブラリが増え続けていることも、さらなる慣性を生んでいます。

一方で、永続的な持続性に対する反論も同様に現実的です。AptosやMonadは、異なる技術的基盤の上に並列実行アーキテクチャを構築できることを示しています。イーサリアムのL2エコシステム（Arbitrum、Optimism、Base）は、オンチェーン決済を伴うオフチェーン実行を通じて高スループットを実現しており、Sealevelの制約を完全に回避する別のスケーラビリティへの道を歩んでいます。多くの分散型（DeFi）金融（AMMや、OrcaやRaydiumのようなDEXを含む）のユースケースでは、Sealevelのパラダイムシフトを必要とせずとも、L2ロールアップのスループットで十分です。

Sealevelの優位性が構造的に最も守りやすいのは、高頻度かつ同時進行のオンチェーン状態更新を必要とするユースケースです。例えば、オンチェーンオーダーブック、強制決済エンジン、そして数千の独立したトランザクションを同時に決済しなければならない大規模な NFT ミントイベントなどです。これらのユースケースは、L2決済であっても最終確定のためにL1レイヤーとの調整が必要なため、L2ソリューションを備えたEVMチェーンであっても依然としてアーキテクチャ上の困難が伴います。

Sealevelは、ベースレイヤーにおいて真正かつ文書化されたアーキテクチャ上の差別化要因となっています。その競争優位の堀は実在しますが、永続的なものではありません。新興の並列チェーンやイーサリアムの拡大するL2エコシステムからの圧力にさらされています。Solanaの地位の持続性は、ランタイムの素の技術的アーキテクチャと同じくらい、ネットワーク効果（開発者の採用、DeFi の預かり資産（TVL）、機関投資家向けインフラ）に依存しています。

ブロックチェーンネットワーク全体におけるレイヤー1の競争上の位置付けや、異なるL1設計においてアーキテクチャのトレードオフがどのように作用するかという文脈において、Sealevelの設計上の選択との類似点は示唆に富んでいます。

このセクションは情報提供および教育目的のみを目的としており、財務、投資、または取引に関するアドバイスを構成するものではありません。暗号資産投資には、全損のリスクを含む重大なリスクが伴います。投資判断を下す前に、資格のある財務アドバイザーにご相談ください。

Solanaアーキテクチャ関連リソース

SealevelはSolanaのアカウントモデルに依存しており、Solanaの広範な高速アーキテクチャの一部を構成しています。市場に関心のある読者はSOL価格ページ. を参照してください。SOLUSDT無期限契約 はレバレッジ派生商品であり、強制決済リスクを伴います。これはSealevelの技術的パフォーマンスを測る指標ではありません。

FAQ：Solana Sealevelの並列処理

これらのよくある質問（FAQ）では、Sealevelの並列実行モデル、スループットの数値、および他のブロックチェーンアーキテクチャとの関係について、混同されやすい主なポイントを解説します。

SolanaのSealevelとは？

Sealevelは、Solanaの並列スマートコントラクトランタイムです。これは、数千の独立したトランザクションを1つずつではなく同時に処理する実行エンジンです。Solanaのアカウントモデルを通じてデータ依存関係を共有していないトランザクションを特定することで、Sealevelはそれらを同時に複数のプロセッサコアに振り分け、逐次実行では到達できないスループットを可能にします。

Sealevelはどのようにしてトランザクションの並列処理を実現しているのですか？

イーサリアム仮想マシン（EVM）は、トランザクションを1つずつ逐次処理します。これは、イーサリアムのステートフルなコントラクトアーキテクチャでは、どのトランザクションを安全に並列化できるかを事前に判断することが構造的に難しいためです。一方、Sealevelは、競合しないトランザクションを同時に処理します。これは、Solanaのアカウントモデルがトランザクションに対し状態依存関係の事前宣言を求めるためであり、実行開始前に安全に並列化するために必要な情報をSealevelに提供できるからです。

Solana Labsのドキュメントによると、Solanaは理想的な条件下で理論上最大約65,000 TPSを処理できます。実際には、投票以外のトランザクションにおける現実のメインネットのスループットは、トランザクションの複雑さ、アカウントの競合、ネットワークの状態に応じて、通常2,000～4,000 TPSの範囲に収まります。それでも、イーサリアムのベースレイヤーのスループットである約15～30 TPSよりも大幅に高い数値です。

Solanaプログラムは主にRustプログラミング言語で記述されますが、CおよびC++もサポートされています。すべてのプログラムは、オンチェーンにデプロイされる前に、Solanaが修正を加えたeBPF（extended Berkeley Packet Filter）バイトコード形式にコンパイルされます。Anchorフレームワークは広く使用されているRustベースの開発ツールであり、アカウント管理を抽象化し、Solanaプログラム開発の定型コードを削減します。

2021年と2022年のSolanaのネットワーク停止は、Sealevelの並列実行ロジックの失敗によって引き起こされたものではありません。これらは、Sealevelの上流にある別システムであるネットワークのトランザクション取り込みレイヤーを、大量のスパンや不正な形式のトランザクションが圧迫したことによって発生しました。SealevelのTPS上限は、処理可能な有効なトランザクション数を示すものであり、取り込みレベルでのトランザクションフラッド攻撃に対してネットワークを免疫にするものではありません。

プルーフ・オブ・ヒストリー（PoH）は、実行開始前に信頼できるトランザクション順序を確立することで、Sealevelを可能にします。PoHは暗号化されたクロックメカニズムであり、すべてのバリデーターが合意する検証可能なタイムスタンプシーケンスを生成します。Sealevelがトランザクションを受け取る前にトランザクションの順序付けが確定しているため、Sealevelはバリデーターとの調整のために一時停止する必要がありません。競合しないトランザクションを即座に並列処理スレッドにスケジュールできます。

結論：SealevelがSolanaの未来にもたらす意味

Sealevelは、あらゆるブロックチェーンが直面する「セキュリティや分散性を犠牲にすることなく、いかにしてより多くのトランザクションを処理するか」という問いに対する、Solanaの最も明確な回答です。

Sealevelの並列実行は、アーキテクチャ上リアルで文書化された機能であり、Solanaの実行モデルをレイヤー1のあらゆる逐次実行ブロックチェーンと区別しています。その実環境でのスループットは有意義であり、イーサリアムのベースレイヤーを大きく上回っていますが、依然として理論上の最大値には届かず、ネットワーク停止を引き起こした取り込みレイヤーの制約を受け続けています。競争上の優位性としての持続性は、ランタイム自体の設計と同様に、エコシステムの発展や競合する並列実行アーキテクチャのペースに依存します。

バリデータークライアント「Firedancer」のローンチや、Monadのような競合する並列チェーンの成熟により、今後の競争図式はより鮮明になるでしょう。もはや関連する問いは「ベースレイヤーでの並列実行が可能かどうか」ではありません。「どのアーキテクチャ的アプローチが、大規模な各ユースケースに最も適しているか」なのです。

関連記事

• イーサリアムスマートコントラクトの実行：5ステップのトレーディングフレームワーク
• ブロックチェーンアーキテクチャ全体でのアカウントモデルの仕組み
• レイヤー1ブロックチェーンアーキテクチャの比較：Near Protocol vs. FetchAI

出典

1. Anatoly Yakovenko, "Solana: A new architecture for a high performance blockchain v0.8.13," 2017. https://solana.com/solana-whitepaper.pdf
2. Solana開発者ドキュメント：プログラミングモデルとアカウントモデル https://docs.solana.com/developing/programming-model/accounts
3. Solanaオンチェーンプログラムドキュメント https://docs.solana.com/developing/on-chain-programs/overview
4. Ethereum Foundation：イーサリアム仮想マシン（EVM）ドキュメント https://ethereum.org/en/developers/docs/evm/
5. Solanaネットワークの停止およびパフォーマンスレポート https://solana.com/news/
6. Aptos Block-STM並列実行ドキュメント https://aptoslabs.com/developer