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

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

Solanaのコミットメントレベルは、特定のブロックやトランザクションに対するネットワークのコンセンサスを測る標準的な方法です。Solana RPCノードにトランザクションのステータスやアカウントデータ（例：getTransaction）を問い合わせる際、データにどの程度の確定性を求めるかをコミットメントレベルで指定できます。Solanaはこのレベルにより、クライアントがレイテンシと確実性のバランスを取れるようにしています。低いコミットメントではすばやくフィードバックを得られ、高いコミットメントでは状態が元に戻らないという強い保証を得られます。

Solanaでは、ファイナリティが高い順に3つの主要なコミットメントレベルが定義されています。

Finalized

最も確実性が高いレベルです。ブロックがステークの圧倒的多数（66%以上）により確認され、その上に少なくとも31個の確認済みブロックが構築されて、スロットが最大の32票ロックアウトに達したことを示します。Finalizedになったトランザクションは事実上取り消せません。

Confirmed

ブロックがステークの圧倒的多数（66%以上）による投票を得たものの、反転をより困難にする継続的な投票期間を経て、まだFinalizedにはなっていない中間レベルです。これは多くの場合、楽観的確認と呼ばれ、トランザクションが「メインフォーク」、つまり正規チェーン上にあることを強く保証します。

Processed

Processedは、トランザクションがリーダーによって処理され、ノードが認識している最新ブロックに含まれたことを意味します。ただし、そのブロックはまだクラスター全体から票を得ていない可能性があります。そのブロックが多数派フォークに入らなければ、トランザクションは削除される可能性があります。

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

送信直後のトランザクションは、それを含むブロックをより多くのネットワーク参加者が確認して投票し、その上に後続ブロックが構築されるにつれて、Processed → Confirmed → Finalizedと進みます。コミットメントが高いほど、より多くのノードがトランザクションの包含に合意しており、フォークやロールバックのリスクが低下します。 

各レベルを詳しく見ていきましょう。

Processedコミットメントレベル

トランザクションは、バリデータノード（つまり現在のリーダー）がブロックに含めた時点でProcessedになります。これは最初の確認であり、トランザクションが受信され、ローカルの台帳状態に組み込まれたことを意味します。

Processedレベルの主な特徴は次のとおりです。

• ブロックに包含済み： トランザクションは、バリデータが生成したブロックに含まれています。
• 多数派フォークの保証なし： このブロックが多数派（最長／最重量）フォークに入るかどうかは不確実です
• 最速のフィードバック： トランザクションがノードで処理されたことを即座に確認できます。クライアント側の迅速な更新（例：ウォレットUIで保留中のトランザクションを表示）に役立ちます。
• 完全には安全でない： この段階では、他のバリデータがそのブロックを確認または投票した保証はありません。クラスターがこのブロックを「スキップ」したり、別のフォークで上書きしたりする可能性があります。つまり、Processed = 包含済みだが、他の参加者による確認はまだない状態です。

Processedブロックの例： 

AliceがSolana上で送金を実行するとします。現在のリーダーがそれをブロック（スロットN）に追加すると、トランザクションはすぐにProcessedとマークされます。Aliceのウォレットでは、即座に保留中／処理済みと表示される場合があります。 

しかし、そのリーダーのブロックがバリデータの過半数に受け入れられなかった場合（例：リーダーが遅い、またはオフラインで、別のフォークが優勢になった場合）、そのProcessedブロックはメインチェーンに含まれないため、Aliceのトランザクションが消える（つまり削除される）可能性があります。

Confirmedコミットメントレベル

Confirmedコミットメントレベルは、トランザクションを含むブロックがクラスターの圧倒的多数に受け入れられ、正規チェーン上にある可能性が非常に高いことを示します。技術的には、「Confirmed」はステーク加重されたバリデータの66%以上がそのブロックに直接投票したことを意味します。 

主な特徴：

• 多数派フォーク上に存在： トランザクションを含むブロックが、台帳の多数派フォークの一部として認識されています。これは、ネットワークがこのブロックを正規ブロックと見なしていることを意味します。

• 圧倒的多数の票： 総ステークの少なくとも3分の2がブロックの確認に投票しています。これらの票はSolanaのゴシップメカニズムを通じて収集されます。つまり、バリデータがネットワーク全体でこのブロックへの票をブロードキャストし、観測しています。この段階ではSolana v1.3で導入された楽観的確認が利用され、圧倒的多数が投票した時点で、まだFinalizedになる前でもノードがブロックをConfirmedとして扱えます。

• 反転リスクが低い： 66%以上のコンセンサスがあるため、競合するフォークがこのブロックを置き換える可能性は極めて低いものの、ゼロではありません。大規模な再編成が発生しない限り、すべての誠実なバリデータは事実上このブロックにコミットしています。Solanaの5年の歴史で、Confirmedブロックが反転した例はありません。

• Finalizedより高速： バリデータは新しいブロックにすぐ投票するため、通常、ブロックまたはトランザクションがProcessedとマークされてから短時間（1〜2秒以内）でConfirmedになります。多数の後続ブロックを待つ必要はありません。そのため、通常の状況では速度と信頼性のバランスに優れています。

• 楽観的ファイナリティ： Solanaの高速なコンセンサスを考慮し、多くの開発者はほとんどの実用的な目的において、Confirmedトランザクションを実質的に確定済みとして扱います。ただし、Finalizedになるまではわずかなロールバックの可能性が残ります。

Confirmedブロックの例： 

上記のAliceのトランザクションは、クラスターのバリデータがブロックNに投票するとConfirmedになります。実際には、後続の数人のバリデータが（スロットN+1、N+2などで）投票してブロックNを認識し、66%のしきい値に達すると、ネットワークはブロックNをConfirmedとマークします。Aliceのウォレットは、トランザクションをユーザーに確認済みとして安全に表示できるようになります。 

この時点でAliceの送金が反転する可能性は非常に低く、まれなフォークやネットワーク障害が発生した場合に限られます。他のチェーンにおける「N回の確認」に似ていますが、Solanaでは固定数のブロック確認ではなく、ステーク投票に基づきます。

Finalizedコミットメントレベル

トランザクションを含むブロックが圧倒的多数の投票を獲得し、さらにその上に十分な数の追加ブロックが構築されると、トランザクションはFinalizedになります。Solanaのコンセンサスでは、これはブロックが最大ロックアウトに到達した状態に相当し、通常は32回連続の投票（スロット）で確認された後に達成されます。Finalizedは最も強いコミットメントレベルであり、トランザクションが反転しないことについて最高レベルの確実性を提供します。 

Finalizedの特徴は次のとおりです。

• 取り消し不能なブロック： クラスターがこのブロックをFinalizedとして認識し、台帳状態にルート化しています。バリデータがロールバックすることはなく、事実上永続的です。

• 圧倒的多数 + ロックアウト： Confirmedと同様に、ステークの少なくとも66%がブロックを支持しています。さらに、その後に31個以上のConfirmedブロックが追加されています。つまり、ネットワークはこのブロック上に深いチェーンを構築し、再編成が現実的に不可能なロックアウト深度に達しています。

• 最大ロックアウト（32票）： SolanaのTower BFTメカニズムは、投票のロックアウト期間を指数関数的に倍増させます。ブロックがタワー内で32票を蓄積すると（つまり、さらに32スロットにわたりフォークの先頭に残ると）、最大ロックアウトに達してFinalizedになります。この時点で、別のフォークに投票しようとするバリデータはコンセンサスルールに違反することになります。

• 最も安全で、確認は最も遅い： Finalizedになるまでには通常、ProcessedやConfirmedよりも時間がかかります（通常時で約~10〜20秒。各スロットが約~400msで、32スロット ≈ 13秒）。これはFinalizedの確実性を得るためのトレードオフです。クライアントはFinalizedになるまで待つことで、追加のレイテンシと引き換えに、トランザクションが削除または反転されるリスクを完全に排除できます。

• Confirmed + 上にブロックが構築済み： Finalizedは、さらに多数のブロックの下に埋まったConfirmedブロックとも捉えられます。すべての誠実なノードが、このブロックを永続的な台帳の一部として検証可能な形でロックしています。

Finalizedブロックの例：

Aliceのトランザクションは、ネットワークがスロットN以降もブロックを生成し続けると、Finalizedステータスに到達します。スロットN+32までに、バリデータの圧倒的多数がN+32までの各後続ブロックに投票し、他のフォークが優勢にならなかったとします。Aliceのトランザクションを含むブロックNは、ここでFinalizedになります。 

この時点で、AliceのトランザクションはSolanaの台帳に完全に永続化されています。どれだけ時間が経っても、彼女の送金を含む状態は変わりません。 

強いファイナリティを必要とするアプリケーション（例：資金を払い出す取引所）は、このトランザクションに基づいて安全に処理を実行できます。攻撃者がこれを反転させるには、ステークの3分の1超を支配し、コンセンサスに違反する必要があります。

非推奨のコミットメントレベル

以前のバージョンのSolana（2021年以前）では追加のコミットメントレベルが公開されていましたが、現在は上記3つが採用され、それらは非推奨になっています。

参考として、従来の用語と現在のレベルとの対応を以下に示します。

• recent – 非推奨。Processedに相当します。古いドキュメントで「recent」は、単にノードが認識している最新状態を指します。

• singleおよびsingleGossip – 非推奨。Confirmedに相当します。単一バリデータまたはゴシップ経由の確認を指し、Confirmedの定義と一致します。

• rootおよびmax – 非推奨。Finalizedに相当します。「root」はクラスターでFinalizedになったルート状態を、「max」は最大ロックアウトを指し、どちらも実質的にFinalizedを意味します。

現在、開発者がコミットメントレベルを指定する際は、processed、confirmed、finalizedのみを使用してください。v1.5.5以降のSolana JSON-RPC APIではこれらの用語が標準であり、非推奨の用語は対応するレベルのエイリアスとして扱われます。 

また、RPCリクエストでコミットメントが指定されていない場合、デフォルトはFinalizedです（つまり、ノードはデフォルトで最も確定性の高い状態を返します）。

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

Processed、Confirmed、Finalizedの違いは、ネットワークのどの程度がトランザクションを承認したか、および反転する可能性がどの程度あるかという観点から理解できます。以下の表（Solana公式ドキュメントを基に作成）は、主な違いをまとめたものです。

要約すると、Processedはトランザクションがブロックに含まれていることだけを意味します。Confirmedは、クラスターがそのブロックに合意（圧倒的多数が投票）したものの、まだチェーンの先端に近いことを意味します。Finalizedは、多数の確認を経てブロックがチェーンの深部にあり、事実上変更不可能であることを意味します。

もう1つの見方は、時間の経過に伴ってトランザクションが正規台帳に残る確率を比較することです。 

Processedになった直後は、フォークや障害の可能性があるため、確率は100%ではありません。ステークの66%超によりConfirmedになると、包含される確率は大幅に上昇します。その上に数十個のブロックが構築されてFinalizedになる頃には、包含確率は~100%になります。 

以下のグラフは、より多くのスロットが経過し、コミットメントレベルが上昇するにつれて、トランザクションがFinalizedになる可能性が高まる様子を示しています。

トランザクションが最終的な正規チェーンに含まれる可能性は、時間とともに高まります。スロットn（トランザクションがProcessedになった時点）では、トランザクションが「スキップ」されたり、フォークから外れたりするリスクがあります。楽観的確認（Confirmed）では、バリデータが投票するにつれて包含の可能性が急激に高まります。その上に十分な数の連続したフォークが構築されると（Finalized）、反転する確率は事実上ゼロになります。これは、コミットメントレベルの上昇に伴いロールバックのリスクが低下することを示しています。

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

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

Proof of History（PoH）とブロック生成

Solanaのリーダーはブロックをすばやく連続して生成します（1スロットにつき1リーダー、スロットは~400ms）。トランザクションはProof of History（PoH）ハッシュチェーンにストリーミングされ、ブロック内のエントリを形成します。ブロックはタービン（Solanaのブロック伝播プロトコル）を通じてネットワーク全体にすばやく伝播します。リーダーがトランザクションを含むブロックを生成すると、そのブロックは即座に伝播されますが、まだ確認されていません。これがProcessed段階に相当します。

投票（Tower BFT）

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

これらのロックアウトは、同じフォークへの投票が続くたびに指数関数的に倍増し（1、2、4、8...スロットのロックアウト）、32票で上限に達します。バリデータがあるフォークに32回連続で投票した場合（つまり、32スロット前のブロックがまだ最重量フォークの一部である場合）、そのブロックは最大ロックアウトに達します。このメカニズムにより、バリデータには多数派フォークを維持してブロックをFinalizedにするインセンティブが与えられます。

確認（楽観的確認）

ブロックが生成されると、バリデータはそのブロックへの票をブロードキャストします。ステークの圧倒的多数（66%以上）がブロックに投票すると、Solanaノードはそのブロックを楽観的に確認済みと見なします。これがConfirmedコミットメントレベルです。票はゴシップ経由で伝播するため、通常はブロック生成後1〜2スロット以内にすばやく達成されます。 

重要なのは、Solanaの実装ではブロックが台帳にルート化されるまで待つ必要がないことです。圧倒的多数の票を、そのブロックが最終的にFinalizedになるという楽観的なシグナルとして信頼します（ステークの<33%が不正に振る舞う場合を除く）。 

これが楽観的確認と呼ばれる理由です。通常のビザンチン障害の前提（不正な参加者は最大3分の1）では、圧倒的多数の票があればブロックは覆りません。フォークがそれを上書きするには、33%超のバリデータが別のチェーンに投票する必要があり、前提が破られることになります。

ファイナライズ（ブロックのルート化）

新しいブロックの生成と投票が続くにつれて、各Confirmedブロックはフォークの深部へ移動します。ブロックの後に32スロット連続で票が蓄積されると、最大ロックアウトに達します。この時点でネットワークはそのブロックをルート化し、Finalizedかつ取り消し不能とマークします。Finalizedとは、そのブロックが先頭から少なくとも31ブロック後方にあり、別のフォークを優先して破棄されなかったことを意味します。これで、すべてのノードがこのブロックを変更不可能な履歴の一部と見なします（そのスロットまでの台帳状態は固定されます）。 

実質的に、FinalizedコミットメントはPoWチェーンにおける「ブロックが32回以上確認された」状態に相当します。ただし、SolanaではProof of Workによる確認ではなく、時間ロック付きの投票によってこれを実現します。32スロットというルールはTower BFTの設計（2^32まで倍増するロックアウト）によるもので、障害許容率を3分の1とする前提の下で、ファイナリティを数学的に保証します。

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

Solanaのコンセンサスは継続的にフォークを評価します。バリデータは、ステーク投票の重みに基づく最重量フォーク選択アルゴリズムを使用して、どのフォーク上に構築するかを決定します。ブロックが一部のバリデータによってのみ処理され、票を獲得できなければ、別のフォークが上書きする可能性があります。そのため、Processedトランザクションは削除されることがあります。 

ブロックが3分の2によりConfirmedになると、別のフォークが勝つには3分の1超のステークによる支持が必要です。これは極めて可能性が低く、不正行為を意味します。 

Finalizedになった後、そのブロックまで巻き戻すフォークは、壊滅的なコンセンサス障害がない限り事実上不可能です。ネットワークが停止または攻撃された場合でも、Finalizedになったスロットを反転するには、プロトコルルール外での連携が必要になります。

メカニズムを要約すると、Processed = ブロックが生成（PoH）されたが、まだ広範な投票を得ていない状態、Confirmed = ブロックへのクラスター投票（Tower BFT）が圧倒的多数に達した状態（楽観的コンセンサス）、Finalized = さらに多くの投票を経て、ブロックがチェーンの「ルート」として維持された状態（絶対的なコンセンサスファイナリティ）です。Solanaの設計では、Confirmedブロックが短い遅延の後にFinalizedになり、高速な確認と最終的な絶対的ファイナリティを両立します。

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

Solana上で構築する際は、適切なコミットメントレベルを選択することが重要です。アプリケーションごとに、速度と確実性に対する要件は異なります。 

各レベルの一般的なユースケースとベストプラクティスは次のとおりです。

即時フィードバックと重要度の低い操作にはProcessedを使用

速度が最優先で、一定のロールバックリスクを許容できるシナリオでは、Processedコミットメントを使用できます。たとえば、開発やテスト中には、トランザクションがバリデータに受信されたことを即座に確認したい場合があります。 

ウォレットやゲームなどのUIアプリケーションでは、ユーザー体験を向上させるため、処理された直後にトランザクションを楽観的に表示できます（例：「保留中」状態を表示）。 

ただし、Processedトランザクションが維持される保証はないため、本番環境の重要なフローには推奨されません。使用する場合は、ロールバックが発生しても深刻な問題にならない、少額または重要度の低いトランザクションに限定してください。

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

Solanaの多くのユースケースでは、通常、Confirmedレベルが推奨されるデフォルトです。レイテンシへの影響を最小限に抑えながら、成功を強く保証します。 

たとえば、トークンをスワップするDeFiアプリケーションや、資金を送金するユーザーは通常、Confirmedステータスを利用します。トランザクションがConfirmedになれば、通常は完了として扱えます。このレベルでは、Processedと比べてトランザクションが削除される可能性が大幅に低下します。特に最近のブロックハッシュを問い合わせてトランザクションを送信する場合は、レイテンシと安全性のバランスに優れるConfirmedを使用することがベストプラクティスです。

高額かつ重要なトランザクションにはFinalizedを使用

高額資産の移動、クロスチェーンブリッジ、取引所への入金確認など、絶対的な確実性が必要な場合、開発者はFinalizedコミットメントレベルを使用してください。わずかなロールバックリスクも許容できないシナリオで一般的です。 

たとえば取引所では、後の再編成によって入金が取り消される可能性を排除するため、トランザクションがFinalizedになるまで待ってからユーザーのアカウントに入金を反映できます。 

もう1つの用途は、一連のトランザクション後の確認です。複雑な操作が完了したと見なす前に、最終状態がFinalizedになったことを確認できます（例：最終的な台帳状態を必要とする監査や決済プロセス）。 

Finalizedコミットメントを要求するとレイテンシが増加する点に注意してください。実質的に古いブロックのハッシュがFinalizedになるのを待つため、ネットワーク負荷が高いとトランザクションが期限切れになる可能性も高まります。Finalizedは、追加の安全性がレイテンシとのトレードオフに見合う、最も重要なトランザクションに限って慎重に使用してください。

要約すると、Processedは主に迅速なフィードバックと非本番用途向け、Confirmedは安全性とパフォーマンスのバランスを提供する多くの操作向け、Finalizedは待ち時間が発生しても確実なファイナリティが本当に必要な場合に使用します。 

多くのアプリケーションではこれらを組み合わせます。ProcessedでUIを更新し、Confirmedで完了と見なし、Finalizedでログに記録します。

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

コミットメントレベルの選択は、信頼性（トランザクションが維持されるか）、パフォーマンス（レイテンシ）、セキュリティ（二重支払いやフォーク問題のリスク）に直接影響します。

信頼性

コミットメントレベルが高いほど、トランザクションが永続的に記録される信頼性が向上します。Finalizedトランザクションが台帳に含まれる信頼性は（異常事態を除き）事実上100%です。Confirmedトランザクションは非常に高いものの100%ではなく、Processedトランザクションはさらに低くなります。 

前述のとおり、Processedのみを基準にすると、フォークの変動により約~5%のトランザクションが削除される可能性があります。一方、Confirmedではそのリスクがほぼ0%になります。 

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

パフォーマンス（レイテンシ）

確認を得るまでの速さとコミットメントレベルの間には、明確なトレードオフがあります。 

Processedの確認はほぼ瞬時です（ブロック時間内で、多くの場合1秒未満）。 

Confirmedでは、バリデータの票を集めるためにわずかな遅延（1〜2スロット程度、追加で約~0.5〜1秒）が発生します。それでも非常に高速で、実際には通常ユーザーが気づくことはありません。 

Finalizedでは、約30個以上の後続ブロックが生成されるまでFinalizedとして報告されないため、最も大きな遅延が発生します。通常、ファイナリティに達するまで~10〜20秒かかります。 

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

スループットと有効期限

トランザクションの有効期限とブロックハッシュの使用にも、見落としやすい重要な影響があります。Solanaトランザクションには最近のブロックハッシュが含まれ、そのブロックハッシュから約~150スロットの間のみ有効です。 

トランザクションへの署名にfinalizedブロックハッシュを要求すると、Finalizedは先端より遅れるため、そのブロックハッシュは古くなります。その結果、トランザクションの有効期限までに残されたスロット数が少なくなります。ネットワークが混雑し、トランザクションがすぐに処理されない場合、有効期限切れの可能性が高まります。 

より新しい（Confirmed）ブロックハッシュを使用すると、有効期間が長くなります。有効期限切れのリスクを軽減するため、getLatestBlockhashにはConfirmedを使用することが公式に推奨されています。 

そのため、プリフライトやブロックハッシュにFinalizedを使用すると、トランザクションが取り込まれるまでの猶予がわずかに短くなり、高負荷時の信頼性に影響する可能性があります。 

つまり、Finalizedコミットメントは高負荷時の活性とトレードオフになる場合があります。確実性を得られる一方、ネットワークが容量上限に近い場合は、トランザクションのタイムアウトが増える可能性があります。

セキュリティ

セキュリティ（二重支払いの防止やフォークに対する安全性など）の観点では、Finalizedが最も安全です。 

Finalizedになったトランザクションを反転するには、総ステークの3分の1超が不正に行動する必要があり、その行為は検出されて処罰される可能性が高いです。 

通常の状況では、Confirmedも非常に安全です。攻撃者が競合フォークを作成し、圧倒的多数がすでに投票した後で、33%超のバリデータに支持させる必要があるため、大規模な組織的攻撃がなければ極めて困難です。 

ただし理論上、一部のバリデータ（33%弱）が票を保留した場合や、フォークがちょうど境界にあった場合には、Confirmedブロックが孤立するシナリオがあります。しかし、Solanaの設計（楽観的確認）は、誠実な多数派がこれを防ぐことを前提としています。 

Processedのセキュリティは最も低くなります。票が集まるまでは、他のバリデータがそのトランザクションを認識している保証すらありません。悪意あるリーダーがトランザクションを含めた後、ブロックを適切に送信しない可能性もあります。 

したがって、セキュリティ上重要な確認にProcessedを利用してはいけません。これは処理が開始されたことを知らせる「通知」に近いものです。 

要約すると、フォークと二重支払いに対するセキュリティは、Finalized > Confirmed > Processedの順です。

読み取りと書き込みでのコミットメントの使用

Solanaから状態を読み取る場合（例：RPC経由でアカウント残高を確認する場合）にも、コミットメントレベルを指定します。読み取りにProcessedコミットメントレベルを使用すると、非常に最新のデータを取得できますが、Finalizedになっていないフォークのデータである可能性があります。読み取りにFinalizedを使用すると絶対的な一貫性（全員が合意した状態）が得られますが、数スロット遅れる場合があります。ほとんどの場合、トランザクションと同様に、状態の問い合わせにはConfirmedを使用するとバランスが良くなります。これにより、反転する可能性のあるフォークに基づいて判断することを避けられます。 

書き込みクエリ（つまりトランザクションの送信）では、コミットメントは主に、クライアントライブラリが確認をどのように待つかに影響します。一般的なパターンは、特定のpreflightCommitment（最新状態に対してTXをシミュレーションする場合があります）でトランザクションを送信し、同じコミットメントレベルでconfirmTransactionを使用することです。必要に応じて、開発者はFinalizedの確認まで待つこともできます。

具体的な数値で見ると、最近の測定では、Solanaはトランザクションを約~0.4秒でProcessedにし、約~0.6秒でConfirmed状態に到達し、約~13秒でFinalizedにしました。 

たとえば決済アプリがトランザクションごとに約~13秒も待てない場合は、強力なセキュリティを維持できるConfirmedを使用してください。 

チェーン間で多額の資金を移動する場合は、完全に確実にするため約~13秒すべてを待つことができます。一方、UIを楽観的に更新する場合など、速度が重要で、わずかなリスクを許容できるものを構築している場合は、Processedステータスを利用して軽快なユーザー体験を提供できます。

まとめ

SolanaのコミットメントレベルであるProcessed、Confirmed、Finalizedは、開発者が各トランザクションについて速度と確実性のバランスを調整できる中核機能です。

Processedは即時ながら不確実な結果を返し、Confirmedは1〜2秒以内にほぼ確定したという保証を提供し（ほとんどのアプリケーションには十分です）、Finalizedは追加の時間を経て絶対的なファイナリティを提供します。 

内部では、これらのレベルはSolanaのコンセンサスの進行状況に対応しています。ブロックが生成され、圧倒的多数の投票を受け、最大ロックアウトで台帳にルート化されるまでの各段階です。

Solana上で構築する際は、タスクに適したコミットメントレベルを選ぶことが不可欠です。

• 迅速なフィードバックや重要度の低いアクションには、低いコミットメントを使用します
• 速度と安全性の両方が必要な標準操作には、confirmedを使用します
• 完全なファイナリティ以外を許容できない場合には、finalizedを使用します

各レベルは、トランザクション包含の信頼性と待ち時間に影響します。 

技術的な意味（66%の票、32ブロック、フォーク、ロックアウト）を理解し、最新のベストプラクティスに従うことで、開発者はアプリケーションの一貫性とセキュリティを犠牲にすることなく、Solanaが約束するパフォーマンスを得られます。

その他のリソース

• Solanaドキュメント – 状態コミットメントの設定、コミットメントステータス表
• Heliusブログ – Solanaのコンセンサス（コンセンサスとファイナリティのメカニズム）