SolanaのPreconfirmations（Preconfs）とは？

リーダー内部におけるトランザクションのライフサイクル

以下では、Preconfirmationsと可観測性に関係する範囲に絞り、リーダー内部でのトランザクションのライフサイクルを説明します。Solanaにおけるトランザクションのライフサイクル全体については、Solana Virtual Machine（SVM）の技術概要をご覧ください。

リーダーに到達する前

Solanaでは、署名済みトランザクションがブロック生成者（つまりリーダー）と今後のリーダーへ直接送信されます。トランザクションはQUIC経由で到着し、接続容量はステーク加重で割り当てられます。そのため、ステーク接続を介して中継されたトランザクションは、高負荷時にも受け入れられる可能性が大幅に高くなります。

この時点でトランザクションを確認できるのは、送信者と、現在および今後のリーダーへトランザクションを中継しているRPCノードまたはトランザクションランディングサービスだけです。 

この段階では、トランザクションがどうなるかは何も分かりません。 

ステージ1：取り込みとSigVerify

リーダーのTransaction Processing Unit（TPU）は、受信トランザクションをパケットとして受け取り、デシリアライズして署名を検証し、重複を破棄します。高負荷時には、不正なパケットやスパムトランザクションが、それ以上のリソースを消費する前にドロップされます。

取り込まれ、SigVerifyステージで署名検証に合格したトランザクションも、単なる候補です。スロットごとに数千の候補トランザクションが到着しますが、その多くはブロックに入りません。

この段階でこれらのトランザクションをストリーミングしてもノイズを配信するだけなので、意味のある可観測性はありません。 

ステージ2：スケジューラ

ブロック生成はBanking Stageで行われます。Agave 1.18以降、その中核を担うのが中央スケジューラです。これは、保留中の全トランザクションをグローバルに把握する単一のスケジューリングスレッドで、実行ワーカーのプールへ処理を割り当てます。完全なコンテキストを持つ単一スレッドなら、共有キューを求めて貪欲に競合するn個のスレッドよりも、ロック競合を大幅に抑えてブロックへトランザクションを詰め込めるという考え方です。

基本的に、スケジューラはトランザクションを次の3つの主要ステップで処理します。

1. バッファリングと優先順位付け

受信トランザクションは、スケジューラのreceive and bufferコンポーネントに入り、各トランザクションの優先度とコストが計算され、優先順位に従って並ぶコンテナへ挿入されます。

この時点でも、トランザクションは数千の「候補」の1つにすぎません。バッファがより優先度の高い処理で埋まれば、排除される可能性があります。

2. スケジューリング 

スケジューラのcontrollerにある制御ループは、コンテナから最も優先度の高いトランザクションを繰り返し取り出し、アカウントロックの競合を確認して、実行用のバッチにまとめます。

Agave 2.3以降、実装されているスケジューリングアルゴリズムはgreedy schedulerです。テストで、greedy方式のほうが少ないオーバーヘッドでブロックにトランザクションを詰め込めることが分かったため、以前のprio-graph設計に代わって採用されました。

3. ディスパッチ 

スケジュールされたバッチは、チャネル経由で実行ワーカーへ送られます。この時点でリーダーは、ワーカースレッド、アカウントロック、組み立て中のブロック内の領域という実際のリソースを、対象のトランザクションへ割り当てています。

この時点でも、トランザクションは保留中です。リーダーは実行する予定ですが、まだ何も実行されていないため、報告できる結果はありません。Preconfirmationsは、その1ステップ後に発行されます。

FiredancerのスケジューラアーキテクチャはAgaveとどう違いますか？

Firedancerも、少し異なるアーキテクチャを通じて同じ時点に到達します。メモリを共有するスレッドの代わりに、Firedancerは共有メモリキューで接続された分離タイルを実行し、スケジューリングロジックはpack tileに配置されています。 

pack tileは保留中の全トランザクションを保持し、各bank tileが現在保持しているアカウントを追跡します。そして、競合せず手数料を最大化するトランザクションを選択してマイクロブロックにまとめ、実行のためbank tileへ渡します。 

ここでも同じ引き渡しが行われます。選択されたトランザクションはパッキングロジックから実行ユニットへ送られ、そこで結果が決まります。

ステージ3：実行

AgaveのワーカーまたはFiredancerのbank tileは、現在のbankに対してスケジュール済みトランザクションのバッチを実行し、アカウントの読み込み、プログラムの実行、結果のコミットを行います。

ここでは、スケジュールされたトランザクションがさまざまな理由で失敗することもあります。残高不足、プログラムエラー、リバートを引き起こすスリッページチェック、その他のランタイム条件などです。いずれの場合も、この時点で結果はリーダーのマシン上にのみローカルに存在します。

この瞬間にpreconfirmationが発行されます。リーダーは各トランザクションが実行された瞬間に、そのステータスとともにストリーミングします。結果がエントリへ記録される前であり、ブロックデータがマシンから出るよりもはるかに前です。

トランザクションのライフサイクル全体で、結果が存在し、かつ報告可能になる最初の瞬間です。実行より上流には、ストリーミングできる結果を持たない保留中の候補群しかありません。下流では、情報はすでにブロックへ詰め込まれ、ネットワークの他の部分へ向かっています。

したがって、この種の早期シグナルが存在できる唯一の場所が実行時点です。そのため、すべてのpreconfirmationには予測ではなく、トランザクションの実際の結果が含まれます。

ただし、preconfirmationでは、そのトランザクションを含むブロックが正規チェーンに採用されるかどうかは分かりません。そのブロックはまだシュレッド化も、伝播も、投票もされていないためです。 

このため、Preconfirmationsは保証ではなくシグナルです。

ステージ4：Proof of Historyとエントリ

実行済みバッチはProof of Historyストリームへ記録され、エントリが生成されます。エントリはトランザクションをハッシュ化してまとめ、リーダーの検証可能なクロックへ組み込んだものです。エントリは台帳のネイティブ形式ですが、この時点ではリーダーのマシン上にしか存在しません。

リーダー以外からの可観測性は、実質的にゼロです。

AlpenglowアップデートでProof of Historyが廃止される点に注意してください。RotorとVotorにより、Solanaで分散クロックが不要になるためです。Preconfirmationのモデルには影響しません。リーダーは引き続きトランザクションを配信前に実行するため、観測可能な最も早いシグナルは、リーダーのローカルな実行結果のままです。 

ステージ5：シュレッド化とブロードキャスト

エントリは、シュレッド、つまり損失耐性のために消失訂正符号化されたMTUサイズの断片へ分割されます。これらのシュレッドは署名され、Turbineのステーク加重ツリーを通じてブロードキャストされます。

ここで可観測性の扉が開きます。シュレッドは、対象ブロックについてリーダーのマシンから外部へ出る最初の成果物です。そのため、シュレッドストリームを含むSolana上の他の早期データプロダクトは、すべてここから始まります。シュレッドからトランザクションを再構築する方法は、RPCコミットメントレベルと比べれば高速です。しかし、シュレッドが存在する前にリーダーがトランザクションを実行しているため、preconfirmationと比べると遅くなります。 

その後、バリデータがブロックをリプレイして投票し、トランザクションがprocessed、confirmed、finalizedの各コミットメントレベルへ進みます。 

レイテンシーの階層でPreconfirmationsはどこに位置しますか？

Preconfirmationsは、生のシュレッド、デコード済みシュレッド、LaserStream、その他のデータストリーミング方式を含むあらゆるシグナルの中で、Solana上で最速です。 

ただし、preconfsはレイテンシーの階層の1段として捉えるのが最適です。各段階では、より早く観測するために、完全性または確実性の一部をトレードオフします。

早いものから遅いものへ順に示します。

この表から、2つの点が分かります。 

第1に、これらのシグナルは直接置き換え合うものではなく、すべて相互補完的です。

たとえば、Preconfirmationsはネットワークが知る前にリーダーが実行した内容を伝えます。一方、LaserStreamからのメッセージは、完全なメタデータとともに何が起きたかを示します。

本番システムでは通常、両方を利用する必要があります。Preconfirmationsに基づいて動作し、下流のシグナルで検証します。  

第2に、各段階の差は均一ではありません。

processedストリームからシュレッドへ移ることで短縮できるのは1桁ミリ秒です。一方、シュレッドからPreconfirmationsへ移ると、ブロック生成パイプラインの残り（エントリへの記録、シュレッド化、伝播）を省略できます。観測ポイントが、ブロックで最初に公開される成果物から、リーダー内部にしか存在しない結果へ移るためです。 

その結果、Preconfirmationsはシュレッドより約5〜50ミリ秒速くなります。 

Preconfirmationsの信頼モデル：保証ではなくシグナル

preconfirmationが約束する内容は、1文に集約できます。「リーダーはこのトランザクションをこの結果で実行しました」。preconfが約束しない内容も、同じ文から導き出されます。

実行済みトランザクションは、まだランディング済みトランザクションではありません。つまり、それを含むブロックはまだシュレッド化も、伝播も、投票もされていません。ネットワークに確認される前に、このブロックがスキップされたりフォークから外れたりする可能性は残っています。preconfirmationを受けたトランザクションのほぼすべてが、オンチェーンへのランディングに成功します。ただし、Preconfirmationsに基づいて動作するシステムは、結果を確定済みとして扱う前に、他の可観測性チェックで確認する必要があります。

カバレッジも設計上、部分的です。Preconfirmationsが存在するのは、リーダーがスケジュール済みトランザクションのストリームをHeliusへ転送するスロットだけです。そのため、カバレッジは参加するネットワークステークの割合に応じて拡大し、ストリームが常に連続するとは限りません。

サービスで継続的なカバレッジを絶対的に保証する必要がある場合は、欠落時にLaserStreamまたはShred Deliveryへフォールバックすることを検討してください。

Preconfirmationsは実行後に発行されるため、サブスクライバーが確認するのはすでに決定済みの結果であり、悪用を待つ保留中の注文フローではありません。つまり、ブロック内でそのトランザクションに先行する機会は、すでに失われています。これが、早期可視性の販売と、スケジュール前の注文フロー漏えいとの決定的な違いです。前者ではサブスクライバーがネットワークの他の参加者より早く反応できますが、後者ではストリーミング対象のトランザクションに対抗する行動が可能になります。Preconfirmationsは厳密に前者です。

このシグナルは、その性質を明確に示しています。preconfirmationを裏付ける経済的コミットメントはなく、そのような主張もしていません。リーダーはローカルな結果を報告しますが、その後の履行に何かをステークするわけではありません。Preconfirmationsを利用する戦略にとって、これは適切なトレードオフです。

たとえば清算ボットに必要なのは、トランザクションがランディングするという絶対確実でスラッシュ可能な約束ではありません。特定のトランザクションの結果を競合より数ミリ秒早く知ることです。

Helius Preconfirmationsはどのように機能しますか？

Helius Preconfirmationsは、単一のWebSocketサブスクリプションで配信されます。クライアントはGatekeeperエンドポイント（wss://beta.helius-rpc.com）へ接続し、preconfSubscribeリクエストを送信できます。

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "preconfSubscribe",
  "params": [
    {
      "failed": false,
      "regionInclude": ["ewr", "fra"],
      "accountInclude": ["TARGET_WALLET_ADDRESS"],
      "accountExclude": [],
      "accountRequired": []
    }
  ]
}

フィルターは、アカウント（include、exclude、required）、リージョン、ステータスに基づいてサーバー側で適用され、ルックアップテーブル（LUT）にも対応しています。そのため、サブスクライバーが受信して料金を支払うのは、自身の戦略に関係するスケジュール済みトランザクションだけです。 

Preconfirmationsは実行後に発行されるため、ステータスフィルターは実際の結果に対して機能します。failed: falseを設定すると、失敗したトランザクションは配信されず、メッセージ単位の課金も発生しません。

Preconfirmationsは、Heliusのすべての有料プラン（Developer、Business、Professional、Enterprise）で利用できます。配信メッセージが0件のスロットでは、クレジットを消費しません。スロットで1件以上のメッセージが配信された場合、開いている各preconfSubscribeサブスクリプションには、300クレジットまたは配信メッセージ1件あたり10クレジットのうち、大きいほうが課金されます。

その後、フィルターに一致するスケジュール済みトランザクションはすべて、コンパクトなバイナリフレームとして届きます。具体的には、トランザクションのバージョン、スケジュールされたスロット、スロット内でのトランザクションのインデックス、ステータスを格納した固定18バイトのヘッダーに、完全なトランザクションバイトが続きます。 

この形式を意図的に簡素化しているのは、固定ヘッダーならホットパスでJSONを解析することなく、ナノ秒単位でデコードできるためです。このやり取りで必要なJSONは、利便性のためのサブスクリプション確認応答だけです。 

preconfirmationは、取引の半分にすぎない点に注意してください。トランザクションを最初に確認できても、応答が最初にランディングしなければ意味がありません。そのため、Helius Senderで最高性能のティアとなるSender Maxもリリースしました。

Sender Maxは、送信内容（単一のトランザクション、または最大4件のトランザクションからなるアトミックバンドル）を利用可能なすべての高速経路へルーティングし、最も高いチップを優先する優先チップバッファへ投入します。最低チップは0.001 SOLです。

preconfSubscribeでシグナルを取得し、Sender Maxでトランザクションをランディングさせましょう。  

Preconfirmationsで何を構築できますか？

トランザクションの結果が決まってから観測されるまで、1ミリ秒経過するごとに利益が減る戦略は、すべてpreconfsの恩恵を受けます。ユースケースには次のものが含まれますが、これらに限りません。 

スナイピング

新しいプールの作成やトークンのローンチは、デプロイトランザクションがリーダー内部で実行された瞬間に確認できます。Preconfirmationsを利用するスナイパーは、シュレッドを監視する参加者がブロックの最初の断片を待っている間に反応できます。 

コピートレード

対象ウォレットの動きは、リーダーが実行した瞬間にpreconfirmationストリームへ現れます。accountIncludeを使用して対象アドレスでフィルタリングすると、ストリームが専用のミラーフィードとなり、他のコピートレーダーより早く動きを把握できます。

清算

ポジションを債務超過にするオラクル更新は、実行された瞬間に把握できます。その時点で更新を確認した清算ボットは、シュレッドやprocessedコミットメントを監視するボットよりもパイプライン全体を先行して開始できます。そのため、Preconfirmationsは清算活動に極めて重要です。

マーケットメイキングとpropAMMs

実行時に受信フローを確認できれば、propAMMsやその他のクォートシステムは、そのフローが公開される前に価格を再設定したり、古いクォートを取り下げたりできます。 

いずれのケースでも、Preconfirmationsは戦略の反応時点を「ネットワークが認識した後」から「リーダーが実行した瞬間」へ移します。

Preconfirmationsを転送して収益を得る

Preconfirmationのカバレッジにはネットワーク効果があり、供給側をバリデータが担います。どのバリデータでもストリームをHeliusへ転送し、収益を得られます。これにより、ブロック生成の副産物を、バリデータがその立場を他の方法で収益化しているかどうかに関係なく得られる収入源へ変えられます。

参加ステークが増えるほど、カバレッジは広がります。参加に関心のあるバリデータは、お問い合わせいただくか、バリデータ向けPreconfirmationsドキュメントで詳細をご確認ください。 

EthereumのpreconfsとSolanaのpreconfsの違いは何ですか？

Ethereumのpreconfirmationsは、トランザクションが将来のブロックに入ることを保証するプロポーザーのコミットメントです。一方、SolanaのPreconfirmationsは、現在のブロックについてリーダーがローカルで実行した直後のトランザクションを伝える、リアルタイムのオンチェーントランザクションシグナルです。前者の目的は早く知ることであり、後者の目的は早く見ることです。

EthereumのPreconfirmations

Ethereumのpreconfirmationsは、研究文献ではbased preconfsと呼ばれることが多く、2023年にJustin Drakeが初めて提唱した設計で、包含コミットメントです。プロポーザーは自身のスロットより前に、トランザクションを将来のブロックへ含めることを約束し、その約束はスラッシングなどの経済的メカニズムで裏付けられます。 

すでに稼働している実装が複数あります。 

• PrimevのMEV-Commit：ウォレット、サーチャー、インテントプロトコルが、コミットメントを得るために実行プロバイダー（ブロックビルダーやシーケンサー）へ入札するマーケットプレイス
• ETHGas：経済的な裏付けを持つpreconfirmationネットワーク
• ChainboundのBolt：パーミッションレスでMEV-Boost互換のプロポーザーコミットメントを提供

最も重要な点として、Ethereumのpreconfirmationsには次の特徴があります。

• 自身のトランザクションが対象
• 実行前に発行
• 確実性を重視して最適化

Ethereumのpreconfirmationsは、実際にランディングする前に、トランザクションがランディングすることを保証します。

Ethereumでこの仕組みが必要なのは、ブロックの構築方法に理由があります。多くのプロポーザーはMEV-Boostを通じて、ブロック構築を直前にオークションへ出します。そのため、オークションが決着するまで、ブロックについて確実な約束はできません。しかし、Solanaにはこの空白がもともとありません。リーダースケジュールは事前に分かっており、mempoolは存在せず、単一のリーダーがスロット内でブロックを継続的に受信、順序付け、実行、ストリーミングします。Ethereumが経済的な仕組みを構築して生み出す必要がある早期シグナルは、Solanaのブロック生成パイプラインにネイティブで存在します。必要だったのは、それを公開することだけです。

Solana Preconfirmations

Solana Preconfirmationsは、将来の約束ではなく、リアルタイムのオンチェーンシグナルです。リーダーは、トランザクションがネットワークの他の部分へ伝播する前に、すでに実行したトランザクションを報告します。

最も重要な点として、Solana Preconfirmationsには次の特徴があります。

• 全員のトランザクションが対象
• 実行後に発行
• レイテンシーを重視して最適化

Solana Preconfirmationsを利用すると、実行済みトランザクションを、シュレッドや標準コミットメントレベルのRPCリクエストを通じてネットワーク全体で観測されるより数ミリ秒早く確認できます。

Ethereumのブロックスペース予約型preconfirmationに最も近いSolanaの仕組みは、Raikuが提供するAhead-of-Time（AOT）Transactions向けのコンピュートユニットマーケットプレイスです。これにより、アプリは将来のブロックへの包含保証を予約できます。

まとめ

Solana上のすべてのトランザクションには、その行方が不明から決定済みへ切り替わる瞬間が1度だけあります。リーダーが実行する瞬間です。Preconfirmationsは、その瞬間をネットワークの他の部分が確認できるようになる前にストリーミングします。リーダーの実行結果を観測するため、ブロックの公開成果物を観測するシュレッドよりもレイテンシーの階層で上位に位置します。Preconfirmationsは保証ではなくシグナルです。ブロックは、ネットワークが確認するまで正規チェーンに採用されたとはみなされないためです。

スナイパー、コピートレーダー、清算者、マーケットメーカー、サーチャーなど、レイテンシーが重要なシステムでは、preconfSubscribeでサブスクライブし、重要なアカウントをフィルタリングしてください。Sender Maxでシグナルに応答し、標準のコミットメントチェックで検証できます。

サブスクリプションの完全なリファレンス、メッセージ形式、統合例は、すべてPreconfirmationsドキュメントで確認できます。