Solana のコミットメントレベルとは？

これは Helius の "What are Solana Commitment Levels?" というブログ記事の日本語訳です。

Solana は、毎秒数千件のトランザクションを処理できる高性能なブロックチェーンです。Solana では、スピードとセキュリティの両立を図るために、トランザクションの確認にコミットメントレベル（commitment levels）という概念を提供しています。

コミットメントレベルは、特定のブロックまたはトランザクションがどの程度「確定的（final）」であるかを示すものであり、応答性と確実性のバランスを取るための指標です。

簡単に言えば、より強いコミットメントレベル（たとえば Finalized）は、ネットワークによってトランザクションが確認されたという、より信頼性の高い保証を提供します（つまり、ロールバックされる可能性が低くなります）。一方で、より弱いコミットメントレベル（たとえば Processed）は、より早くフィードバックを返しますが、確認の確実性は低くなります。

このブログでは、Solana におけるすべてのコミットメントレベル（Processed, Confirmed, Finalized および廃止された用語を含む）について、技術的な定義、違い、内部の仕組み、開発者の利用例、信頼性・パフォーマンス・セキュリティへの影響に至るまでを解説します。

Solana のコミットメントレベルとは？

Solana のコミットメントレベルは、指定されたブロックまたはトランザクションに関するネットワークのコンセンサスを測定する標準的な方法です。Solana の RPC ノードに対して、トランザクションのステータスやアカウントデータ（例：getTransaction）を照会する際には、データにどれほどの確定度を求めるかを示すために、コミットメントレベルを指定することができます。Solana では、このコミットメントレベルを利用して、クライアントが「遅延（latency）」と「確実性（certainty）」のバランスを取れるようにしています。低いコミットメントレベルでは、より素早いフィードバックが得られる一方で、高いコミットメントレベルでは状態が巻き戻されないという強い保証が得られます。

Solana では、主に3つのコミットメントレベルが定義されています（確定度が高い順に）：

Finalized

最も高い確実性のレベルであり、そのブロックが全ステークの3分の2以上（≥66%）によって承認されており、さらにその上に少なくとも31個の承認済みブロックが積み重ねられていることを示します。これにより、そのスロットには32という最大の投票ロックアウトが与えられます。Finalized とされたトランザクションは、事実上、取り消されることはありません。

Confirmed

中間的なレベルであり、そのブロックがステークの3分の2以上（≥66%）によって投票されてはいるものの、さらに長期間の継続的な投票による Finalized 状態にはまだ達していません。この段階はしばしば 楽観的な確認（確定)（optimistic confirmation） と呼ばれ、トランザクションが「メインフォーク（main fork）」すなわち正規のチェーン（canonical chain）上にあるという、強い保証を提供します。

Processed

Processed とは、そのトランザクションがリーダーによって処理され、ノードが把握している最新のブロックに含まれたことを意味します。ただし、そのブロックにはまだネットワーク全体の投票が行われていない可能性があります。もしそのブロックが最終的に多数派のフォークに含まれなかった場合、そのトランザクションは破棄される可能性もあります。

これらのレベルは、トランザクションのライフサイクルにおける段階を表しています。

新しく送信されたトランザクションは、ネットワーク内でそのブロックが観測され、投票され、さらにそのブロックの上に次のブロックが積み重なっていくにつれて、Processed → Confirmed → Finalized という順に進んでいきます。より高いコミットメントレベルになるほど、より多くのノードがそのトランザクションの存在に同意したことを意味し、フォークや巻き戻しのリスクが減少します。

それでは、各レベルについて詳しく見ていきましょう。

Processed コミットメントレベル

トランザクションは、バリデータノード（現在のリーダー）によってブロックに含まれた時点で、Processed として扱われます。これは最も早い段階での承認であり、そのトランザクションが受信され、ローカルの台帳状態に組み込まれたことを意味します。

Processed レベルの主な特徴は以下のとおりです：

・ブロックに含まれた: トランザクションは、あるバリデータが生成したブロック内に含まれています。

・マジョリティーフォークの保証はない: このブロックはマジョリティー（最長／最重量）フォークに入るかもしれないし、入らないかもしれません。

・最速のフィードバック: このレベルでは、ノードによってトランザクションが処理されたという即時のフィードバックが得られます。たとえば、ウォレットの UI で「保留中のトランザクション」としてすぐに表示するなど、クライアント側の素早い更新に役立ちます。

・完全に安全ではない: この段階では、他のバリデータがそのブロックを見たり投票したりしたことが保証されていません。クラスタはこのブロックを「スキップ」したり、別のフォークで上書きしたりする可能性があります。つまり、Processed とは「ブロックには含まれたが、まだ他のノードによって確認はされていない」状態を意味します。

Processed ブロックの例

たとえば、アリスが Solana 上で送金トランザクションを送信したとします。そのトランザクションが現在のリーダーによってブロック（スロットN）に追加された瞬間に、そのトランザクションは Processed として扱われます。この時点で、アリスのウォレットには 「保留中」または「処理済み」 としてトランザクションが即座に表示されるかもしれません。

しかしながら、そのリーダーが作成したブロックがバリデータの多数によって受け入れられなかった場合（たとえば、リーダーの処理が遅かったり、オフラインになっていたりして、別のフォークが採用された場合）、アリスのトランザクションは消えてしまう（すなわち破棄される）可能性があります。これは、その Processed ブロックが最終的にチェーンに組み込まれなかったことを意味します。

Confirmed コミットメントレベル

Confirmed のコミットメントレベルは、そのトランザクションが含まれるブロックがクラスタのスーパーマジョリティ（超過半数）によって受け入れられ、非常に高い確率で正規のチェーン（canonical chain）上にあることを示します。技術的には、Confirmed とは、そのブロックに対して投票したバリデータの合計ステークが全体の66%を超えていることを意味します。

主な特徴は以下の通りです：

・マジョリティーフォーク: トランザクションを含むブロックは、台帳の多数派フォークの一部として認識されています。これは、ネットワークがそのブロックを正規のブロック（canonical block）と見なしていることを意味します。

・スーパーマジョリティの投票: 総ステークの3分の2以上が、そのブロックに対して投票しています。これらの投票は、Solana のゴシップメカニズムを通じて収集されており、バリデータがこのブロックに対する投票をネットワーク全体にブロードキャストし、相互に確認したことを示します。この段階では、Solana v1.3で導入された 楽観的確定（optimistic confirmation） が活用されており、ノードは過半数以上の投票があった時点で（確定前であっても）ブロックを確定として扱うことができます。

・巻き戻されるリスクが低い: 66%以上のコンセンサスが得られているため、このブロックが別の競合フォークによって置き換えられる可能性は非常に低いとされています（ただしゼロではありません）。
正直な（正しく動作する）すべてのバリデータはこのブロックに対して事実上のコミットメントを行っているといえます。Solana の 5 年の運用の中で、Confirmed 状態のブロックが巻き戻された例は一度もありません。

・Finalized より高速: Confirmed ステータスは通常、ブロックまたはトランザクションが Processed とマークされてから1〜2秒以内に発生します。これは、バリデータが新しいブロックにすぐ投票するためです。多数の後続ブロックを待つ必要がないため、Confirmed は速度と信頼性のバランスが良い状態といえます。

・楽観的な確定: Solana の高速なコンセンサスを前提として、多くの開発者は Confirmed 状態のトランザクションを事実上の確定として扱うことがよくあります。ただし、Finalized に達するまでは、ロールバックの可能性がわずかに残ります。

Confirmed ブロックの例

先ほどのアリスのトランザクションは、クラスタのバリデータたちがスロットNのブロックに投票した時点で、Confirmed となります。実際には、その後のいくつかのバリデータ（スロットN+1、N+2など）がブロックNを確認して投票し、66%の閾値に達すると、ネットワークはブロックNを Confirmed とマークします。この時点で、アリスのウォレットはユーザーに対して、そのトランザクションが Confirmed されたことを安全に表示できる状態になります。

この段階でアリスの送金が巻き戻される可能性は非常に低く、起こるとしても極めてまれなフォークやネットワークの問題が発生した場合に限られます。この仕組みは、他のブロックチェーンにおける「N回の確認（N confirmations）」に似ていますが、Solana の場合は固定数のブロックではなく、ステークに基づく投票によって確定が判断されます。

Finalized コミットメントレベル

トランザクションは、そのブロックがスーパーマジョリティによって投票され、さらに十分な数のブロックがその上に構築されたときに Finalized となります。Solana のコンセンサスにおいて、これはそのブロックが最大のロックアウトに達したことを意味し、通常は連続する32回の投票（32スロット）によって確認された後に達成されます。

Finalized は、Solana における最も強いコミットメントレベルであり、トランザクションが巻き戻されることはほぼ絶対にないという、最高レベルの確実性を提供します。

特徴は以下の通りです：

・巻き戻されないブロック: このブロックはクラスタによって Finalized として認識されており、台帳の状態にルートされたことを意味します。バリデータはこのブロックを巻き戻すことはなく、事実上、恒久的なものとなります。

・スーパーマジョリティ+ロックアウト: Confirmed の場合と同様に、ステークの66%以上がこのブロックを支持しています。加えて、その後に31個以上の Confirmed ブロックがこのブロックの上に追加されています。言い換えれば、ネットワークはこのブロックの上に深いチェーンを構築しており、再編成が現実的に不可能となるロックアウトの深さに達しています。

・最大ロックアウト (32 スロットの投票): Solanaの Tower BFT メカニズムでは、投票のロックアウト期間が指数的に倍増していきます。あるブロックが Tower 内で32票分の投票を蓄積すると（つまり、そのブロックが32スロットの間フォークの先頭にとどまり続けると）、最大ロックアウトに達し、Finalized と見なされます。この時点で、別のフォークに対して投票しようとするバリデータは、コンセンサスルールに違反することになります。

・最も安全で最も遅い確定: Finalized に到達するまでには、通常 Processed や Confirmed よりもやや時間がかかります（通常の状況下で約10〜20秒。32スロット × 約400ミリ秒 ≒ 約13秒）。これは、Finalized が持つ高い確実性の代償としての遅延です。この確定を待つことで、クライアントはトランザクションが破棄されたり巻き戻されたりするリスクを完全に排除できますが、その代わりに応答速度が遅くなります。

・Confirmed + ブロック構築：別の見方をすると、Finalized とは「Confirmed されたブロックが、さらに多数のブロックの下に埋め込まれた状態」とも言えます。すべての誠実なノードが、このブロックを恒久的な台帳の一部として確実にロックインしている状態です。

Finalized ブロックの例

アリスのトランザクションは、ネットワークがスロットNの後もブロックを継続して生成し続けることで、Finalized のステータスに到達します。たとえば、スロットN+32の時点で、スーパー・マジョリティのバリデータたちがN+32までの各連続ブロックに投票しており、他のフォークが入り込まなかったとしましょう。このとき、スロットNのブロック（アリスのトランザクションを含む）は Finalized となります

この時点で、アリスのトランザクションは Solana の台帳上で完全に確定した状態にあり、彼女がしばらく待ったとしても、その送金を含む状態が変化することはありません。

強い最終確定性を必要とするアプリケーション（たとえば、取引所が資金を解放するようなケース）は、このトランザクションに対して安全に処理を実行することができます。特に重要なのは、もし攻撃者がこれを巻き戻そうとした場合、ステークの3分の1超を掌握し、かつコンセンサス違反を犯す必要があるという点です。

廃止されたコミットメントレベル

Solana の以前のバージョン（2021年以前）では、現在は廃止された追加のコミットメントレベルが公開されていましたが、現在は前述の3つのレベルに統一されています。

参考のために、以下に旧来の用語と現在の対応関係を示します：

・recent – 廃止済み: 現在の Processed に相当します。古いドキュメントでは、recent は単に「ノードが認識している最新の状態」を指していました。

・single and singleGossip – 廃止済み: 現在の Confirmed に相当します。これらは、1つのバリデータやゴシップ経由の確認を指しています。

・root and max – 廃止済み: 現在の Finalized に相当します。root はクラスタ内で最終確定された「rooted state」を指し、max は最大ロックアウトを意味しており、いずれも事実上 Finalized と同義です。

現在では、開発者はコミットメントレベルを指定する際、Processed, Confirmed, Finalized の3つのみを使用すべきとされています。Solana の JSON-RPC API はバージョン 1.5.5 以降、これらの用語を標準として使用しており、廃止された用語は、それぞれに対応する現在のレベルの別名（エイリアス）として扱われます。また、RPC リクエストでコミットメントレベルを指定しなかった場合、デフォルトでは Finalized が使用されます（つまり、ノードは最も確定された状態を返します）。

コミットメントレベルの違い

Processed, Confirmed, Finalized の違いは、ネットワークのどの程度がその取引を承認したか、また、どの程度その取引が取り消される可能性があるかという観点から理解することができます。以下の表（Solana の公式文書からの引用）は、主要な違いを要約したものです：

特性	Processed	Confirmed	Finalized
ブロックに含まれた	はい	はい	はい
ブロックはマジョリティフォーク	不明	はい	はい
トランザクションがブロックに含まれる	はい	はい	はい
66%以上がブロックに投票	いいえ	はい	はい
後続ブロック生成	N/A	少数	31ブロック以上

まとめると、Processed はトランザクションがブロックに含まれたことを意味しますが、それ以上の保証はありません。Confirmed は、クラスタがそのブロックに合意している（スーパーマジョリティによる投票）ことを意味しますが、そのブロックはまだチェーンの先端近くに位置しています。Finalized は、多数の確認済みブロックがその上に積み重ねられ、チェーンの深い位置にあることを意味し、事実上、変更不可能な状態です。

この違いを理解するもう一つの方法は、そのトランザクションが時間の経過とともに正規の台帳に残り続ける確率という観点から見ることです。

Processed された直後の段階では、そのトランザクションが含まれ続ける確率は 100% ではありません（フォークや失敗が起こる可能性があります）。しかし、ステークの 66% 以上によって Confirmed されると、その含有確率は非常に高くなります。そして、その上に多数のブロックが積み重ねられて Finalized に達すると、そのトランザクションが台帳に残る確率はほぼ 100% となります。

このことは、以下の図に示されています。図では、スロットの経過とコミットメントレベルの上昇に伴い、トランザクションが Finalized に至る可能性がどのように高まっていくかが視覚的に表されています。

トランザクションが最終的な正規チェーンに含まれる確率は、時間の経過とともに高まっていきます。
最初のスロット n（トランザクションが processed された時点）では、そのトランザクションが「スキップ」されたり、フォークによって除外されるリスクがあります。しかし、楽観的確定によって confirmed されると、バリデータの投票により含有確率は急上昇します。その後、十分な数の連続したブロック（フォーク）がその上に構築され finalized に達すると、巻き戻しの可能性は事実上ゼロになります。このように、コミットメントレベルが上がるにつれて、トランザクションがロールバックするリスクが徐々に減っていくことが示されています。

Solana がどのようにコミットメントレベルを決定するか？

Solana のコンセンサスが「内部でどのように動作しているか」を理解することで、これらのコミットメントレベルがなぜ存在するのかがより明確になります。

Proof of History (PoH) とブロック生成

Solana では、リーダーが非常に短い間隔で次々とブロックを生成します（1スロットあたり約400ミリ秒、各スロットごとに1人のリーダー）。トランザクションは Proof of History（PoH） のハッシュチェーンにストリーム形式で取り込まれ、ブロック内のエントリを構成します。ブロックは Turbine（Solanaのブロック伝播プロトコル） によってネットワーク全体に高速で伝播されます。リーダーがあなたのトランザクションを含むブロックを生成した時点で、そのブロックはただちに伝播されますが、まだ確認はされていません。この状態が Processed の段階に相当します。

投票 (Tower BFT)

Solana は、Tower BFT と呼ばれるBFT型のコンセンサスアルゴリズムを使用しています。バリデータ（それぞれが一定のステークを保有）は、台帳の次の一部になるべきと考えるブロックに対して投票します。この投票自体も Solana のトランザクションとして扱われており、ロックアウトという概念を含んでいます。バリデータがスロット N のブロックに投票するたびに、ロックアウトが発生し、その後に競合するフォークに投票した場合、一定期間投票できなくなる可能性があります。

このロックアウト期間は、同じフォークに対して連続して投票するごとに指数的に倍増（1、2、4、8…）し、最大で32票分に制限されています。バリデータが同じフォークに対して32回連続で投票した場合（つまり、32スロット前のブロックが現在も最も重いフォークの一部である場合）、そのブロックは最大ロックアウトに達します。この仕組みによって、バリデータは多数派フォークにとどまり、ブロックを Finalize するよう動機づけられます。

確認 (楽観的確認)

ブロックが生成されると、バリデータたちはそのブロックに対して投票をブロードキャストします。ステークの3分の2以上（≥66%）によってそのブロックに投票が行われた時点で、Solana のノードはそのブロックを楽観的に確認された（optimistically confirmed）ものと見なします。これが Confirmed コミットメントレベルにあたります。投票はゴシップを通じて伝播するため、ブロックの生成後、多くの場合 1～2 スロット以内に迅速に行われます。

重要なのは、Solana の実装では、ブロックが台帳にルートされるのを待つ必要はないという点です。Solana は、スーパーマジョリティによる投票を「このブロックはいずれ確定（finalized）されるだろう」という楽観的なシグナルとして信頼しています（ただし、ステークの33%未満が不正を働かないという前提のもとです）。

このため、この仕組みは「楽観的確認（optimistic confirmation）」と呼ばれています。通常のビザンチン障害耐性の仮定（最大で1/3が不正である可能性）に基づけば、スーパーマジョリティの投票があれば、そのブロックは覆されることはありません。もしそのブロックがフォークによって上書きされるとすれば、33%以上のバリデータが別のチェーンに投票しなければならず、それは Solana のコンセンサス前提を破る行為となります。

最終確定とブロックのルート化

新しいブロックが継続的に生成され、投票が行われていくにつれて、各 Confirmed ブロックはフォークのより深い位置へと移動していきます。あるブロックが、その後32スロット連続で投票を蓄積すると、最大ロックアウト（maximum lockout）に達します。この時点で、ネットワークはそのブロックをrootとして固定し、Finalized としてマークします。この状態になると、そのブロックは不可逆（irreversible）と見なされます。Finalized とは、そのブロックがチェーンの先頭から少なくとも31ブロック後方にあり、他のフォークに差し替えられることなく保持されてきたことを意味します。すべてのノードは、このブロックを変更不可能な履歴（immutable history）の一部と見なし、そのスロットまでの台帳の状態は凍結されたものとして扱います。

事実上、ファイナライズされたコミットメントは、PoW チェーンで例えると「ブロックに32以上の確認がある」ことに相当しますが、Solana では、それを PoW による確認の代わりに、時間的に制限された（time-locked）投票によって実現しています。この32スロットルールは、Tower BFT の設計（ロックアウトが2のべき乗で増加し、2³²まで達する）に由来しており、バリデータの1/3までが不正であるという前提のもとで、数学的に確実な最終性を保証するものです。

フォーク選択とロールバック

Solana のコンセンサスは、常に複数のフォーク（分岐）を評価し続けています。バリデータは、ステークの投票重みに基づいた最も重いフォーク（heaviest fork）選択アルゴリズムを使って、どのフォークにブロックを追加するかを判断します。あるブロックが一部のバリデータによってしか処理されず、十分な投票を得られなかった場合、別のフォークに上書きされることがあります。これが、Processed トランザクションが破棄される可能性がある理由です。

2/3のバリデータによってブロックが Confirmed されると、それを上書きするには1/3超のステークを持つ別フォークが必要になります。これは極めて起こりにくく、悪意のある行動があったことを示唆します。

Finalized された後は、そのブロックを巻き戻すようなフォークは、致命的なコンセンサスの破綻なしには事実上不可能です。仮にネットワークが停止したり攻撃を受けたりしたとしても、Finalized スロットを巻き戻すにはプロトコルのルールを超えた外部的な協調行動が必要になります。

仕組みを要約すると：

• Processed ＝ ブロックが生成された状態（PoH）だが、まだ広く投票されていない
• Confirmed ＝ クラスタがそのブロックに対して Tower BFT によるスーパーマジョリティの投票を完了した状態（楽観的コンセンサス）
• Finalized ＝ 多数の追加投票を経て、そのブロックがチェーンの「ルート」として定着した状態（絶対的なコンセンサス確定）

Solanaの設計は、Confirmed ブロックが短時間のうちに Finalized へと進むようになっており、
これにより、迅速な確認と最終的な確定性の両立が実現されています。

各コミットメントレベルの開発者ユースケース

Solana 上で開発を行う際には、適切なコミットメントレベルを選択することが非常に重要です。アプリケーションによって、スピードを優先するか、確実性を優先するかの要件は異なります。

以下に、各コミットメントレベルごとの代表的なユースケースと推奨される使い方を示します：

迅速なフィードバックとクリティカルではない操作には Processed

開発者は、スピードが最優先であり、ある程度の巻き戻しリスクが許容される場面においては、Processed コミットメントを使用してもよいでしょう。たとえば、開発やテストの際に、トランザクションがバリデータに受信されたことを即座に確認したい場合などです。

ユーザーインターフェースを伴うアプリケーション（ウォレットやゲームなど）では、トランザクションが Processed になった時点で、楽観的に表示することでユーザー体験を向上させることができます（例：「保留中」の状態をすぐに画面に表示する）。

ただし、Processed 状態のトランザクションは確実に保持される保証がないため、本番環境での重要な処理には推奨されません。このレベルを使用する場合は、金額が小さいトランザクションや、巻き戻しが発生しても重大な影響を与えない処理に限定すべきです。

ほとんどのトランザクションには Confirmed

Confirmed コミットメントレベルは、多くの Solana アプリケーションにおいて一般的に推奨されるデフォルトの設定です。このレベルは、成功に対する強い保証を提供しながら、遅延は最小限に抑えられます。

たとえば、DeFi アプリケーションでのトークンスワップや、ユーザーによる資金の送金などでは、通常 Confirmed ステータスに依拠します。トランザクションが Confirmed になった時点で、アプリケーションはそれを通常通り完了したものとして扱うことができます。このレベルは、Processed に比べてトランザクションが破棄される可能性を大幅に低減します。直近のブロックハッシュを取得したり、トランザクションを送信したりする際には、Confirmed を使用するのがベストプラクティスです。これは、遅延と安全性のバランスが最も優れているためです。

高価値およびクリティカルなトランザクションには Finalized

絶対的な確実性が求められる場合（たとえば、高額資産の移動、クロスチェーンブリッジ、取引所での入金確認など）には、開発者は Finalized コミットメントレベルを使用すべきです。これは、ほんのわずかな巻き戻しのリスクすら許容できないような状況で一般的に使われます。

たとえば、ある取引所では、トランザクションが Finalized されるまで、ユーザーアカウントへの入金を反映させないようにして、後からの再編成（reorg）によって入金が取り消されるリスクを回避します。

もう一つの活用例としては、一連のトランザクションの完了後に、最終状態が Finalized されたことを確認するような場面があります。これは、監査や決済など、確定済みの台帳状態が必要な処理において有用です。

ただし、開発者は Finalized を要求すると待機時間が発生することに注意すべきです。ネットワーク負荷が高いときには、トランザクションが有効期限切れになる可能性も高くなります。これは、古いブロックのハッシュが Finalized されるまで待つ必要があるためです。そのため、Finalized は、その安全性の価値が待機時間の代償に見合う場合に限り、慎重に使うべきです。

要約すると、Processed は主に迅速なフィードバックと非生産的な用途に、Confirmed は安全性とパフォーマンスのバランスを提供するほとんどの操作に、そして Finalized は、絶対的な確定が必要な重要処理に限定して使用します。

多くのアプリケーションでは、これらを用途に応じて組み合わせて使うことになります。たとえば、UI上の表示には Processed を使い、処理の完了判断には Confirmed を使い、Finalized になったらログ記録を行う、といった形です。

トランザクションの信頼性・パフォーマンス・セキュリティ

どのコミットメントレベルを採用するかという選択は、信頼性（トランザクションが本当に確定され、巻き戻されずに残るかどうか）、パフォーマンス（遅延）、セキュリティ（フォークの問題や二重払いが発生するリスク）に直接的な影響を与えます。

信頼性

より高いコミットメントレベルを使用することで、トランザクションが恒久的に記録される信頼性が向上します。Finalized されたトランザクションは、台帳に残り続けるという点で、実質的に100%の信頼性を持ちます（ただし、極めて例外的な事態を除きます）。一方、Confirmed のトランザクションは非常に高い信頼性を持っていますが、それでもわずかに巻き戻しの可能性があります。Processed のトランザクションは、それよりも信頼性が低くなります。

先に述べたとおり、Processed のみを基準とした場合、約5%のトランザクションがフォークの変動（fork churn）により破棄される可能性があるとされています。一方で、Confirmed を使用することで、そのリスクはほぼ0%にまで低下します。

重要なアプリケーションにおいては、Finalized コミットメントを使用することで、後から破棄されるようなフォークに自分のトランザクションが含まれてしまうリスクを完全に排除することができます。

パフォーマンス　（遅延）

コミットメントレベルによって、どれだけ早くトランザクションの確認が得られるかには明確なトレードオフがあります。

Processed は、ほぼ瞬時に確認が返されるのが特徴で、ブロック生成時間内（多くの場合1秒未満）で応答が得られます。

Confirmed は、バリデータの投票を集めるためにわずかな遅延（1～2スロット程度、約0.5～1秒の追加時間）が発生しますが、それでも非常に高速で、実際にはユーザーにとってほとんど気づかないレベルです。

Finalized は、最も大きな遅延を伴います。というのも、そのトランザクションが Finalized とみなされるのは、その後に約30個以上のブロックが生成された後だからです。通常、ファイナリティに達するまでには約10〜20秒かかります。

ネットワークが混雑していたり、ブロック生成が遅れていたりする場合には、この遅延はさらに長くなる可能性があります。そのため、Finalized コミットメントを多用すると、ユーザー体験や処理スループットを遅らせる要因となります。アプリケーションが Finalized を待つ設計になっている場合は、その分の待機時間を考慮に入れる必要があります。ただし、これはあくまでクライアント側が最終性の確認を待っているという意味であり、トランザクション自体のオンチェーン実行が遅れているわけではありません。Solanaはその間も新たなトランザクションを継続して処理しています。

スループットと有効期限

もう一つの重要な点として、トランザクションの有効期限およびブロックハッシュの使用に関する影響があります。Solana のトランザクションには直近のブロックハッシュが含まれており、そのトランザクションはそのブロックハッシュから約150スロットの間だけ有効です。

もし Finalized なブロックハッシュを取得してトランザクションに署名した場合、そのブロックハッシュは現在の最新スロットから遅れたものになるため、有効期限までの残りスロット数が少なくなります。その結果、ネットワークが混雑していてトランザクションの処理が遅れた場合、有効期限切れになるリスクが高まります。

一方、より新しい（Confirmed）ブロックハッシュを使うことで、より長い有効期間を確保できます。そのため、getLatestBlockhash を使用する際は Confirmed を指定するのが公式に推奨されています。これにより、有効期限切れのリスクを抑えることができます。

したがって、トランザクションの送信前チェック（preflight）やブロックハッシュの取得に Finalized を指定すると、処理されるまでの猶予時間がわずかに短くなる可能性があり、ネットワーク負荷が高い状況では信頼性に影響を与えることがあります。

要するに、Finalized コミットメントを使用することで確実性は高まる一方で、ネットワークが逼迫している状況ではトランザクションのタイムアウトが増える可能性があり、「確実性」と「ライブ性（処理される速さ）」の間にトレードオフが生じることになります。

セキュリティ

セキュリティの観点（たとえば、二重支払いの防止やフォークの安全性）においては、Finalized が最も安全です。

一度トランザクションが Finalized されると、それを巻き戻すには総ステークの3分の1超が悪意を持って行動する必要があり、それが発生すればほぼ確実にネットワークに検知され、制裁の対象となるでしょう。

Confirmed は、通常の条件下では非常に高い安全性を持っています。攻撃者がこれを覆すには、既にスーパーマジョリティによる投票が完了した後に、33%以上のバリデータを別のフォークに参加させる必要があり、これは大規模かつ綿密に協調された攻撃がない限り極めて困難です。

ただし、Confirmed にも理論的なリスクは存在します。たとえば、一部のバリデータ（33%未満）が投票を意図的に遅らせたりした場合や、フォークがちょうど分岐の境界にあるような状況では、Confirmed 済みのブロックが孤立化（orphaned）する可能性があります。とはいえ、Solana の設計（楽観的確認）は誠実な多数派が存在するという前提に基づいており、こうした状況を防ぐようになっています。

一方、Processed は最もセキュリティが低いレベルです。投票がまだ行われていない段階では、他のバリデータがそのトランザクションを認識しているという保証すら存在しません。悪意のあるリーダーがトランザクションをブロックに含めた後、適切にそのブロックをネットワークに伝播させないといったことも理論上可能です。

このため、Processed に基づいた確認は、セキュリティを要する処理においては信頼すべきではありません。これはあくまで「処理が開始されたことを通知する」程度の役割でしかありません。

要約すると、フォークや二重支払いに対するセキュリティ強度の順序は Finalized ＞ Confirmed ＞ Processed となります。

読み書きのコミットメントレベル

Solana から状態を読み取る場合（たとえば RPC でアカウントの残高を確認するなど）、読み取りにもコミットメントレベルを指定することができます。Processed を指定すると、最新の状態が取得できる可能性がありますが、それはまだ確定していないフォーク上のデータかもしれません。一方で、Finalized を使って読み取ると、すべてのノードが合意している確定済みの状態が得られますが、数スロット分遅れていることがあります。多くのケースでは、トランザクションと同様に、Confirmed を使用するのがバランスの良い選択です。これにより、将来的に巻き戻される可能性のあるフォークに基づいて判断することを防げます。

書き込み操作（トランザクション送信など）の場合、コミットメントレベルは主にクライアントライブラリが確認を待つ際に関係します。一般的なパターンとしては、トランザクション送信時に preflightCommitment を指定し（これはトランザクションを最新状態でシミュレートする際に使われる）、その後 confirmTransaction で同じコミットメントレベルを使って確認を行う、という流れです。開発者は必要に応じて、Finalized まで待つ設計にすることも可能です。

これを実際の数字に置き換えると、最近の測定によれば、Solana のトランザクションは 〜0.4秒 で Processed に、〜0.6秒で Confirmed に達し、そして 〜13秒 で Finalized を達成しています。

たとえば、決済アプリのように1件あたり13秒も待てないユースケースであれば、Confirmed を使うのが適しています。それでも十分なセキュリティが保たれています。

一方で、多額の資産をチェーン間で移動させるような処理では、完全な確実性を求めて13秒間 Finalized を待つ選択も妥当です。逆に、スピードが最優先で、ある程度のリスクが許容されるような状況（たとえば、UIの即時更新など）では、Processed のステータスを使って素早いユーザー体験を提供することもできます。

まとめ

Solana のコミットメントレベル - Processed, Confirmed, Finalized - は、各トランザクションにおいて「スピード」と「確実性」のバランスを調整できるようにするための、Solana の中核的な機能です。

Processed は、即時性に優れる一方で確実性が低く、Confirmed は、1～2秒以内にほぼ最終的な保証が得られるレベルであり、多くのアプリケーションにとってはこれで十分です。そして Finalized は、さらなる時間を要するものの、絶対的な確定性を提供します。

これらのレベルは、Solana のコンセンサスの進行状態と対応しており、ブロックの生成 → スーパーマジョリティによる投票 → 最大ロックアウトによる台帳へのルート化 という段階に対応します。

Solana 上でアプリケーションを構築する際には、目的に応じて適切なコミットメントレベルを選択することが極めて重要です。

• 高速なフィードバックや重要度の低い操作には、より低いコミットメントを使用する。
• スピードと安全性の両立が求められる標準的な処理には Confirmed を使う。
• 完全な確定性が絶対に必要なケースでは Finalized を使う。

それぞれのレベルは、トランザクションの確実性（巻き戻されないこと）と、確認までの待機時間に影響を与えます。

66%以上の投票、32スロット、フォーク、ロックアウトといった技術的な背景を理解し、最新のベストプラクティスに従うことで、開発者は Solana の持つ高い性能を活かしつつ、アプリケーションの一貫性とセキュリティを損なうことなく設計することができます

参考文献

• Solana ドキュメント – Configuring State Commitment, Commitment Status Table
• Helius ブログ – Consensus on Solana (コンセンサスとファイナリティーの仕組み)