Skip to main content
Solana でトランザクションを送信する主な方法は2つあります:
  1. staked connections を使用する(デフォルト)
  2. Sender のような専門の着陸サービスを使用する(推奨)
この記事では、Helius の有料プランすべてのデフォルト方法である staked connections を使用したトランザクション最適化のベストプラクティスについて説明します。 staked connections は、ビジネスにとってレイテンシーが重要でないユースケース(例: 支払い、ウォレット、ソーシャルアプリなど)に最適です。 高度なトレーダー(例: propAMM、スナイパー、コピー取引、清算ボット、アービトラージ)が専門の超低レイテンシーのトランザクション着陸サービスを探している場合は、Sender チュートリアルを読んでください。

まとめ

Helius の staked connections は、確認時間を最小限に抑えて100%のトランザクション配信を保証します。staked connections でのトランザクション着陸率を最適化するには、次のベストプラクティスをお勧めします:
  • 最新のブロックハッシュ を取得するためにコミットメント「confirmed」を使用する
  • 優先手数料を追加し、動的に計算する
  • 計算単位(CU)の使用を最適化する
  • maxRetries を0に設定し、堅牢な再試行ロジックを実装する
  • skipPreflighttrue に設定して送信する(オプション)
さらに深く知りたいですか?このブログ記事ですべての基本をカバーしています。

トレーダー向け推奨最適化

レイテンシーに敏感な取引のユースケースには、Sender の使用をお勧めします。 ただし、staked connections を使用しており、可能な限り最低のレイテンシーに設定を最適化したい場合は、上記のベストプラクティスに加えて次の最適化を推奨します:
  • クライアントサーバー(トランザクションを送信するマシン)は米国東部または西ヨーロッパに配置するべきです。
  • Helius のトランザクション送信サーバーと同じ場所に配置する場合は FRA または PIT を選ぶ
  • バリデーターネットワークから遠い地域(例: LATAM、南アフリカ)からの送信を避ける
  • テールレイテンシーを最小化するために、Helius の地域キャッシュをウォームにする
  • 各地域ごとに1つのウォーミングスレッドのみを必要とし、それ以上は効果がありません
  • トランザクションを送信するのと同じエンドポイントとAPIキーを使用して1秒ごとにgetHealth RPC コールを送信する
これらの利点は経験豊富なトレーダーのみに明らかです。一般的なアプリ開発者には、以下の「スマートトランザクションの送信」セクションにあるガイドラインに従うことをお勧めします。
Raw Shreds (UDP) でオンチェイントランザクションデータを可能な限り早く取得してください。Helius ダッシュボードで購読してください。

スマートトランザクションの送信

Helius の Node.js および Rust SDK はスマートトランザクションを送信できます。この新しい方法は、トランザクションの確認ステータスを処理しながら、最適化されたトランザクションを構築および送信します。 HeliusのTypeScriptRustの両方のSDKはスマートトランザクションを送信できます。この新しいメソッドは、確認状態を処理しながら最適化されたトランザクションを構築して送信します。 最も基本的なレベルでは、ユーザーはキー ペアと実行したい命令を提供する必要があり、残りは私たちが処理します。 当社は次のことを行います。
  • 最新のブロックハッシュを取得
  • 初期トランザクションを構築
  • 消費された計算単位(CUs)を取得するために初期トランザクションをシミュレート
  • 前のステップで消費されたCUsに余裕を持たせてCU制限を設定
  • 優先手数料API を通じてHelius推奨の優先手数料を取得
  • ミクロラムポート単位で優先手数料をHelius推奨の手数料に設定
  • 推奨手数料が数秒後に変更される事態に備えて小さなバッファ手数料を追加
  • 最適化されたトランザクションを構築および送信
  • 成功した場合はトランザクションの署名を返す
推奨される値(またはそれ以上)を要求することにより、Helius は高品質のトランザクションを送信し、バリデータによってレート制限されることはありません。
この方法は、Solana 上でトランザクションを構築、送信、着地させる最も簡単な方法です。 Helius 推奨料金を使用することにより、当社の標準有料プランの1つで Helios ユーザーが送信したトランザクションは、非常に高精度で配信され、レイテンシーが最小限に抑えられるように、当社の staked connections 経由でルーティングされます。

Node.js SDK

TypeScript SDK

このsendSmartTransactionメソッドは、Helius TypeScript SDKバージョン>=1.3.2で利用可能です。SDKをより新しいバージョンに更新するには、npm update helius-sdkを実行します。

Rust SDK

send_smart_transaction メソッドは、Rust SDKバージョン >= 0.1.5 で利用できます。SDKを最新バージョンに更新するには、cargo update helius を実行します。 このsend_smart_transactionメソッドは、Rust SDKバージョン>=0.1.5で利用可能です。SDKをより新しいバージョンに更新するには、cargo update heliusを実行します。 必要に応じて2回再試行し、プレフライトチェックをスキップして最適化されたトランザクションを送信するために send_smart_transaction を活用しています:

SDKを使わずにトランザクションを送信する

SDKの1つを使用してスマートトランザクションを送信することをお勧めしますが、SDKを使用せずに同じ機能を達成することができます。 Node.js SDK と Rust SDK はどちらもオープンソースであり、スマートトランザクション送信機能の基盤となるコードはいつでも閲覧可能です。 TypeScript SDKとRust SDKの両方がオープンソースであるため、スマートトランザクション送信機能の基礎となるコードはいつでも閲覧できます。 まず、初期トランザクションを準備して構築します。これには、一連の命令を含む新しいトランザクションの作成、最新ブロックハッシュの追加、手数料支払者の割り当てが含まれます。 バージョン付きトランザクションの場合、TransactionMessage を作成し、ルックアップテーブルが存在する場合にそれをコンパイルします。 次に、新しいバージョン付きトランザクションを作成し、それに署名します。このステップが必要なのは、トランザクションをシミュレートする際、トランザクションに署名されている必要があるためです。 たとえば、バージョン付きトランザクションを準備したい場合は:

トランザクションのコンピュートユニット(CU)使用量の最適化

トランザクションのコンピュートユニット(CU)使用量を最適化するためにsimulateTransaction RPC メソッドを使用してトランザクションをシミュレートできます。 トランザクションのシミュレーションにより使用されたCU数が返されるため、この値を使用して計算制限を適宜設定できます。 最初に、希望する命令を含むテストトランザクションと、計算制限を1.4m CUsに設定する命令を追加することをお勧めします。 これはトランザクションのシミュレーションが成功するようにするためです。 たとえば:
トランザクションが問題なく実行されることを確実にするために、少しの余裕を持たせることもお勧めします。次のように設定することで可能です:
次に、コンピュートユニット制限をこの値に設定する命令を作成し、それを命令の配列に追加します:

トランザクションのシリアライズとエンコード

これは比較的簡単です。 まず、トランザクションをシリアライズするために、Transaction および VersionedTransaction タイプは .serialize() メソッドを持っています。その後、bs58 パッケージを使用してトランザクションをエンコードします。 あなたのコードは次のようになります bs58.encode(txt.serialize());

適切な優先手数料の設定

まず、優先手数料API を使用して優先手数料の見積もりを取得します。トランザクションを渡して、推奨パラメータを通じてHelius推奨の手数料を取得します:
次に、コンピュートユニット価格をこの値に設定する命令を作成し、その命令を以前の命令に追加します:

最適化されたトランザクションの構築と送信

このステップは最初のステップのほぼ繰り返しです。ただし、初期命令の配列は、計算ユニット制限と価格を最適に設定するための2つの命令を追加するように変更されています。 今、トランザクションを送信します。 プレフライトチェックを有効にして送信するか、他の送信オプションを変更するかどうかは重要ではありません—トランザクションはすべての有料プランのstaked connectionsを通じてルーティングされます。

トランザクションのステータスのポーリングと再送信

staked connections はトランザクションをリーダーに直接送信しますが、トランザクションが銀行ステージでドロップされる可能性は依然としてあります。RPC にトランザクションの再試行を頼るのではなく、ユーザー独自の再送信ロジックを使用することを推奨します。
sendTransaction RPC メソッド には、RPC のデフォルトの再試行ロジックをオーバーライドできる maxRetries パラメータがあります。これにより、開発者は再試行プロセスをより制御できます。 現在のブロックハッシュを getLatestBlockhash から取得し、lastValidBlockHeight を保存し、ブロックハッシュが失効するまでトランザクションを再試行するのが一般的なパターンです。 トランザクションが送信された後、その確認ステータスをポーリングして、ネットワークが処理して確認したかどうかを確認し、再試行する前に確認することが重要です。トランザクションの確認ステータスを確認するには、getSignatureStatuses RPC メソッド を使用してください。 @solana/web3.js SDK には、複数の署名の現在のステータスをフェッチするための getSignatureStatuses メソッドもあります。

sendSmartTransaction のポーリングと再送信の処理

sendSmartTransaction メソッドには60秒のタイムアウト期間があります。ブロックハッシュは150スロット間有効であり、400msのスロットが完璧だと仮定すると、トランザクションのブロックハッシュは1分後に無効になると合理的に考えられます。 このメソッドは、トランザクションを送信し、その署名をこのタイムアウト期間を使用してポーリングします:
txtSig は、送信されたトランザクションの署名に設定されます。 その後、このメソッドは pollTransactionConfirmation() メソッドを使用してトランザクションの確認ステータスをポーリングします。このメソッドは、トランザクションのステータスを5秒ごとに3回まで確認します。 この期間中にトランザクションが確認されない場合は、エラーが返されます:
If the transaction is not confirmed during this time, an error is returned: