Helius の製品とプラットフォーム
自動スケーリング
法定通貨プラン向けの Helius の自動クレジット補充メカニズムです。月間クレジット枠を使い切ると、ユーザーが設定した上限まで追加クレジットを自動購入し、429 エラーによって本番トラフィックが中断されるのを防ぎます。暗号資産プランには自動スケーリングがありません。代わりに、手動で購入するプリペイドクレジットを使用します。
自動スケーリングを参照してください。
クレジット
Helius が API とストリーミングの使用量を請求する際の単位です。RPC メソッド、DAS 呼び出し、ストリーミングのスループットには、それぞれ固有のクレジットコストがあります。すべてのプランには請求サイクルごとにリセットされる月間クレジット枠が含まれます（未使用のクレジットは繰り越されません）。 完全なコスト表については、クレジットを参照してください。DAS API
Digital Asset Standard（デジタルアセット標準）は、Solana のデジタルアセット（NFT、圧縮 NFT、代替可能トークン）向け統一インターフェースのオープン仕様です。Helius の DAS API 実装は、拡充されたメタデータ、所有権、価格情報を構造化された単一のレスポンスで返すため、オンチェーンのアセットデータ用に独自のパーサーを用意する必要がありません。 DAS APIを参照してください。専用ノード
レート制限やクレジット計測がなく、固定月額料金で請求されるプライベート Helius RPC ノードです。無制限のスループットが必要な限定的なユースケースに適しています。ほとんどのアプリケーションでは、性能、フェイルオーバー、機能範囲に優れる通常の Helius RPC の方が適しています。 専用ノードを参照してください。拡張トランザクション
生の Solana トランザクションを、トークン転送、NFT 販売、スワップ、ステーキング操作など、人が理解できるイベントへデコードする Helius の解析済みトランザクション API です。プログラムごとの命令パーサーは不要です。 拡張トランザクションを参照してください。エラーコード
Helius API が返す標準 HTTP ステータスコードと、Helius 固有の説明は次のとおりです。400 Bad Request— 無効なパラメーターまたは不正なリクエスト（例：無効なアドレス形式、必須フィールドの欠落、不正な JSON）401 Unauthorized— API キーがないか無効です403 Forbidden— アクセスが拒否されました。通常は IP 制限、エンドポイントが含まれないサブスクリプション、または API キーの権限不足が原因です404 Not Found— リクエストしたリソースのデータがありません（不明なウォレットの ID 検索では正常です）429 Too Many Requests— クレジット枠の超過、レート制限の超過、または同時リクエスト数の上限到達です5xx— Helius 側の問題です。指数バックオフを使用して再試行してください
Gatekeeper
世界各地に分散したプロキシ群を介してリクエストをルーティングし、標準 RPC 呼び出しよりも大幅に低いレイテンシを実現する Helius のエッジゲートウェイです。RPC URL 内のmainnet.helius-rpc.com を beta.helius-rpc.com に置き換えてアクセスします。
アーキテクチャの背景については、GatekeeperとGatekeeper の紹介ブログ記事を参照してください。
LaserStream
Solana のオンチェーンデータ向けに提供される Helius の高性能 gRPC ストリーミングサービスです。履歴リプレイ、マルチリージョンフェイルオーバー、Helius のストリーミング製品の中で最も豊富な機能セットを備えています。JavaScript/TypeScript、Rust、Go 用の公式 SDK が提供されています。LaserStream WebSocketは同じインフラストラクチャ上で動作します。 LaserStreamを参照してください。SDK ベンチマークの詳細については、LaserStream SDK のパフォーマンスに関するブログ記事を参照してください。LaserStream WebSocket
Helius の永続的な WebSocket ストリーミングサービスです。標準の Solana WebSocket メソッドと Helius 固有の拡張機能（transactionSubscribe、およびより高度なフィルタリングを備えた拡張版 accountSubscribe）の両方を、統合された単一のエンドポイントで提供します。LaserStream WebSocket は、LaserStream gRPC とバックエンドを共有します。
LaserStream WebSocketを参照してください。
Preconfirmations
Helius で最も低レイテンシーのトランザクションシグナルです。トランザクションがエントリにまとめられてシュレッド化される前にストリーミングします。リーダーが実行した瞬間に、その実行ステータスとともに Helius Preconfirmations を配信し、さらに実行前にバリデータが実行を確約した時点で BAM Preconfirmations を配信します。Shred Delivery よりも早く、processed コミットメントストリームよりも早く配信されます。preconfSubscribe WebSocket サブスクリプション経由で配信されます。すべての有料プランで利用でき、配信メッセージ 1 件あたり 10 クレジットです。メッセージが 0 件のスロットは 0 クレジットです。1 件以上のメッセージが配信されたスロットには、サブスクリプションごとに最低 300 クレジットがかかります。カバレッジは、どのバリデータが自身のストリームを Helius に転送するかによって異なるため、フィードは連続的ではありません。
PreconfirmationsとpreconfSubscribeを参照してください。
優先手数料 API
リアルタイムのオンチェーン手数料市場に基づいて、推奨優先手数料を返す Helius の手数料見積もりエンドポイントです。推測や混雑時の過払いをせずに、競争力のある手数料を設定できます。 優先手数料 APIを参照してください。レート制限
各 Helius プランで許可される 1 秒あたりの最大リクエスト数です。レート制限はプラン階層と API ファミリー（標準 RPC、拡張 API、ストリーミング）によって異なります。制限を超えると429 Too Many Requests が返されます。
レート制限を参照してください。
Sender
低レイテンシを必要とするトレーダー向けに構築された Helius の特化型トランザクション到達サービスです。優先手数料、Jito チップ、ステーク済み接続のルーティングを組み合わせ、到達率を最大化します。https://sender.helius-rpc.com/fast で利用できます。
Senderを参照してください。
Shred Delivery
最終的なブロック組み立て前に配信される、UDP 経由で未加工の Solana shred をストリーミングする Helius のサービスです。Helius は、単一のバリデータに起因する地理的なレイテンシのばらつきを最小限に抑えるため、複数の地域にまたがる分散型バリデータネットワークから shred を集約します。高頻度取引やその他の低レイテンシアプリケーションに役立ちます。未加工の shred は Helius Dashboard からセルフサービスで利用できます。料金は IP あたり月額 $1,000 USD です（Pro プランでは IP あたり月額 $800 USD）。 Shred Deliveryを参照してください。シュレッドの仕組みの詳細については、ブログ記事ミリ秒単位の競争に勝つ：シュレッド、LaserStream、Solana の優位性を参照してください。ステーク済み接続
Helius の有料プランで使用されるデフォルトのトランザクション送信経路です。ステーク済み接続は、Solana のプロトコルレベルの Stake-Weighted Quality of Service（SWQoS）を介して、今後のブロックリーダーにトランザクションをルーティングします。SWQoS はバリデーターのステークに基づいて接続スロットを優先的に割り当て、混雑時のパケット損失を低減します。Helius の有料プランでは、呼び出し元が大量のステークを持つバリデーターを直接運用しなくても、この到達率の利点を得られます。 トランザクションの最適化とブログ記事Stake-Weighted Quality of Service：知っておくべきすべてのことを参照してください。Wallet API
Solana ウォレットの残高、トランザクション履歴、転送、ID、資金源を照会するための Helius の REST API です。生の RPC 出力ではなく、構造化され、USD 価格を含むレスポンスを返します。アドレスに加えて、SNS.sol と ANS ドメイン名を受け付けます。
Wallet APIを参照してください。
Solana の基礎
アカウント
Solana 上でデータを永続的に保持するコンテナで、32 バイトの公開鍵によって識別されます。ユーザー残高、プログラムコード、トークンメタデータなど、すべてのオンチェーン状態は、プログラム自体も含めてアカウントに保存されます。各アカウントには、そのデータの変更または lamport の引き出しを許可されたプログラムである所有者が存在します。永続化するには、最低限の SOL 残高（レント免除）を維持する必要があります。 詳細については、ブログ記事Solana プログラミングモデル：Solana 開発入門を参照してください。Agave
Anza が保守する、現在の標準的な Solana バリデータークライアントです。ブランド変更された、元の Solana Labs クライアントの後継です。特定の Agave リリースへの言及（例：v1.17.31 の SWQoS 最小ステークしきい値）は通常、動作をクライアントの特定バージョンに固定します。Jito-Solanaはブロックエンジンを統合した Agave のフォークです。Firedancerは Jump Crypto が開発した、C ベースの独立した代替実装です。 Agave が実装する SVM モデルについては、ブログ記事Solana Virtual Machineを参照してください。エアドロップ
アドレスに SOL または SPL トークンを付与することです。Devnet と Testnet では通常、開発用ウォレットに資金を供給するため、フォーセットから少量のテスト用 SOL を受け取ることを指します。Mainnet では、既存の保有者へのトークン一括配布を指します。Devnet のエアドロップはDevnet フォーセットから利用できます。関連トークンアカウント（ATA）
特定のウォレットアドレス用に特定の SPL トークンを保持する、決定論的に導出されたトークンアカウントです。各ウォレットがトークンミントごとに持てる ATA は最大 1 つであるため、ATA はユーザーのトークン残高を検索する標準的な場所です。ウォレットアドレスとトークンミントをシードとして導出されます。ブロック
一連のトランザクションと重要なメタデータを含むデータ構造です。メタデータにはブロックのハッシュと直前のブロックのハッシュが含まれ、変更不可能なチェーンを形成します。ブロックはスロット中に生成されます。スロットに割り当てられたリーダーが受信トランザクションを検証し、ブロックにまとめ、Turbineを介してネットワークにブロードキャストします。すべてのスロットでブロックが生成されるわけではありません。リーダーが時間内に生成できなければ、そのスロットはスキップされ、ネットワークは先に進みます。 ブロックがステーク加重されたバリデーター投票の超過半数を得ると、確認済みと見なされます（コミットメントレベルを参照してください）。 詳細については、ブログ記事Solana のスロット、ブロック、エポックを理解するを参照してください。コミットメントレベル
トランザクションがオンチェーンに取り込まれたことに対する確信度です。processed— 現在のリーダーが確認していますが、まだ投票されていません。ブロックがコンセンサスを失うと破棄される可能性があります（約 0.4 秒）confirmed— ブロックに対するステーク加重バリデーター投票が 66% 以上です。これまで、確認済みブロックが巻き戻されたことはありません（約 0.6 秒）finalized— ブロックが 66% 以上の投票を得ており、その上に後続の 31 ブロックが構築されています（つまり Tower BFT の最大ロックアウト）。実質的に不可逆です（約 13 秒）
confirmed が推奨されるデフォルトです。UI のフィードバックには processed、取引所への入金やクロスチェーンブリッジなどの高額操作には finalized を使用してください。finalized で取得したブロックハッシュは confirmed で取得したものより早く失効するため、トランザクションが失効するまでの時間が短くなります。
詳細については、ブログ記事Solana のコミットメントレベルとは？を参照してください。
コンピュートユニット（CU）
トランザクションが実行する計算処理を示す Solana の尺度で、Ethereum の gas に相当します。各トランザクションは、コンピュートユニット上限とコンピュートユニット価格（CU あたりのマイクロ lamport 単位の優先手数料）を指定します。この積が優先手数料の総額を決定します。上限を超えるとトランザクションは失敗します。CPI（Cross-Program Invocation）
あるオンチェーンプログラムがアカウントと命令データを渡して別のプログラムを呼び出せるようにする Solana の仕組みです。Solana のコンポーザビリティを実現する基本機能です。CPI はsol_invoke_signed システムコールを介して公開され、呼び出し元が渡されるアカウントに対して適切な権限を持つことを検証します。PDAにより、プログラムは所有するアカウントに代わって署名できます。
呼び出されたプログラムは、呼び出し元プログラムに残っているコンピュート予算内で動作します。予算を使い切るか設定上限を超えると、元のトランザクションを含む呼び出しチェーン全体が失敗します。
詳細については、ブログ記事Solana Virtual Machineを参照してください。
エポック
約 432,000 個の Solana スロットからなるまとまりです。Solana がバリデーターセット、リーダースケジュール、ステーク委任、報酬分配を更新する上位の管理区間です。現在のスロット目標では、各エポックは約 2 日間です。 詳細については、ブログ記事Solana のスロット、ブロック、エポックを理解するを参照してください。Firedancer
Jump Crypto が C でゼロから作成した、2 番目の独立した Solana バリデータークライアントです。Firedancer が掲げる目標は、（1）独立実装を通じた Solana プロトコルの文書化と標準化、（2）クライアントの多様性向上（単一クライアントがステークの 33% 超を制御しない状態）、（3）エコシステムの性能向上です。アーキテクチャはモジュール式です。「タイル」と呼ばれる多数の単一目的 Linux プロセス（QUIC タイル、検証タイルなど）が共有メモリを介して通信し、Agaveの単一プロセス設計とは対照的です。 Frankendancer は、そのハイブリッドな中間実装です。Firedancer の高性能な C ネットワークコードと、Agave の Rust ランタイムおよびコンセンサスコードを組み合わせています。 詳細については、ブログ記事Firedancer とは？を参照してください。命令
Solana トランザクション内の最小作業単位で、関連するアカウントとデータを伴う単一のプログラム呼び出しです。トランザクションには 1 つ以上の命令がまとめられ、アトミックに実行されます（すべて成功するか、すべて一緒に元に戻ります）。 詳細については、ブログ記事Solana プログラミングモデル：Solana 開発入門を参照してください。Lamport
SOL の最小単位です。1 SOL = 1,000,000,000 lamports（10⁻⁹ SOL）です。分散システムの基礎研究でチューリング賞を受賞した Leslie Lamport にちなんで名付けられました。生の Solana RPC メソッドは、残高と手数料を lamport 単位で返します。Helius の Wallet APIは自動的に換算します。優先手数料はマイクロ lamport、つまり lamport の 100 万分の 1（10⁻¹⁵ SOL）単位です。リーダー／リーダースケジュール
リーダーは、特定のスロット中に新しいブロックを提案するよう割り当てられたバリデーターです。リーダーは各エポックの開始時に計算されるステーク加重ランダムスケジュールによって選ばれます。そのため、各バリデーターは今後約 2～3 日間のすべてのスロットについて、誰がリーダーになるかを独自に導出できます。各リーダーには連続する 4 スロット（1 スロット約 400 ms として約 1.6 秒）が割り当てられ、連続してブロックを生成する短い時間枠が与えられます。 リーダーが担当スロットでブロックを生成できなければ、そのスロットはスキップされます。ネットワークは欠落したブロックを待たずに先へ進みます。Senderのようなトランザクション送信サービスは、到達確率を最大化するため、署名済みトランザクションを現在のリーダーと次の 2 人のリーダーへルーティングします。 詳細については、ブログ記事Solana のコンセンサス：Tower BFT と Proof of Historyを参照してください。マークルツリー
各非リーフノードが子ノードのハッシュで構成され、単一のルートハッシュがデータセット全体を確定する暗号学的ツリー構造です。データがツリーに属することを検証するには、リーフからルートまでの経路にある兄弟ハッシュ（マークル証明）のみが必要です。ツリーのサイズに関係なくデータ量は O(log n) です。深さ 26 のツリーでは、証明は 26 個の兄弟ハッシュ（約 832 バイト）です。小さいもののリーフごとに必要であり、圧縮 NFTで使用される証明形式です。ZK Compressionは、データセットとともに増大しない、固定サイズの単一の有効性証明に置き換えます。 ブログ記事暗号ツール入門：ハッシュ関数とマークルツリーの解説を参照してください。プログラム
コンパイル済み sBPF バイトコードを含む実行可能アカウント、つまり Solana 上のスマートコントラクトです。プログラムはステートレスであり、所有するデータアカウントを読み書きします。プログラム ID（32 バイトのアドレス）によって識別されます。Solana には、ランタイムに組み込まれた一連のネイティブプログラム（System、Stake、Vote など）があります。それ以外はすべてユーザーがデプロイしたプログラムです。 詳細については、ブログ記事Solana プログラミングモデル：Solana 開発入門を参照してください。プログラム派生アドレス（PDA）
プログラム ID と一連のシードから導出される決定論的なアドレスです。PDA により、プログラムは制御するアカウントに代わって署名できます。そのため、状態を持つプログラムの設計に不可欠です。PDA は意図的に曲線外にあるため、対応する秘密鍵は存在しません。Proof of History（PoH）
Solana の同期プリミティブであり、コンセンサスアルゴリズムではありません。PoH は、バリデーター同士が通信せずにイベントの順序へ合意できる暗号学的タイムスタンプ機能を提供します。実装は、各バリデーターの単一 CPU コア上で継続的に動作し、各反復の出力を次の反復の入力として使用する逐次 SHA-256 ハッシュチェーンです。生成は逐次的かつシングルスレッドで行われ、検証は並列化できます。 PoH は、ブロックが有効となるタイミングを定義する「tick」を提供します。リーダーは指定された PoH tick 範囲内でブロックを公開する必要があります。範囲外のブロックはスキップされたと見なされます。PoH は、実際のコンセンサスメカニズムであるTower BFTと並行して動作します。 詳細については、ブログ記事Proof of History、Proof of Stake、Proof of Work の解説を参照してください。レント／レント免除
各 Solana アカウントがオンチェーンに永続化するために保持する必要がある SOL 残高で、アカウントのストレージサイズに応じて変わります。アカウントはレント免除状態で作成する必要があります。アカウントの残高が最低額を下回るトランザクションは失敗します。レント免除になると、それ以降の支払いなしでアカウントが無期限に存続します。Sealevel
Solana の並列トランザクション実行エンジンです。EVM のような逐次 VM とは異なり、Sealevel は複数のトランザクションを CPU コア間で同時実行します。これは、すべての Solana トランザクションが実行開始前に、読み取りおよび書き込み対象のアカウントを明示的に宣言するため可能です。スケジューラーは、実行時の分析なしに競合しないバッチを特定できます。 スケジューリングルールは単純です。異なるアカウントにアクセスするトランザクションは並列に実行されます。同じアカウントを読み取るだけのトランザクションも、読み取りは競合しないため並列に実行されます。同じアカウントへ書き込むトランザクションは、競合状態を防ぐため逐次実行されます。 詳細については、ブログ記事Solana Virtual Machineを参照してください。スロット
Solana の基本時間単位です。この間、指定されたリーダーバリデーターがブロックを生成できます。現在のスロット目標は 400 ms ですが、実際の長さはネットワーク状況によって変動します。リーダーが担当スロット中にブロックを生成できなければ、スロットはスキップされます。ネットワークは待機せず次のスロットへ進むため、すべてのスロットでブロックが生成されるわけではありません。 詳細については、ブログ記事Solana のスロット、ブロック、エポックを理解するを参照してください。SVM（Solana Virtual Machine）
Solana の完全なトランザクション実行スタックであり、限定的なバイトコードインタープリターではありません。SVM には、実行を調整する Bank コンポーネント、Banking Stage スケジューラー、BPF ローダー、sBPF 仮想マシン自体（11 個の汎用レジスターと約 100 個のオペコードを持ち、性能向上のため JIT コンパイルされるレジスターベースの VM）が含まれます。単一のバイトコード実行系を明確に指す EVM とは異なります。 Solana プログラムは、Linux eBPF からフォークされた Solana の sBPF にコンパイルされます。LLVM フロントエンドを持つ言語（C、C++、Rust、Zig）はすべて sBPF をターゲットにできます。トランザクションにアカウントアクセスの事前宣言を要求することで、Sealevelの並列実行と Solana の局所的な手数料市場が実現します。 詳細については、ブログ記事Solana Virtual Machineを参照してください。Tower BFT
Solana のコンセンサスメカニズムです。Tower BFT は、Proof of Historyの同期クロックを利用する pBFT 類似のアルゴリズムで、スロットごとの同期的なコンセンサスラウンドを不要にします。バリデーターは「投票タワー」を構築します。これは投票を積み重ねた逐次スタックで、新しい投票ごとに過去のすべての投票のロックアウト期間が 2 倍になり、フォークを切り替える際のステーク損失コストが指数関数的に増加します。 確認しきい値：ステーク加重投票の 3 分の 2 以上がブロックに集まると、そのブロックは確認済みになります（ファイナリティに違反するには、総ステークの 4.6% 以上がスラッシュされる必要があります）。投票を得たブロックの上に後続の 31 ブロックが構築され、Tower BFT の最大ロックアウトに達すると、そのブロックは確定済みになります。使用方法については、コミットメントレベルを参照してください。 詳細については、ブログ記事Solana のコンセンサス：Tower BFT と Proof of Historyを参照してください。Turbine
Solana のブロック伝播プロトコルです。リーダーは各ブロックを MTU サイズのシュレッドと Reed-Solomon 消失訂正符号化された復元シュレッドに分割します。FEC 比率（通常 32:32）により、約 33% のパケット損失があってもネットワークはブロックを復元できます。その後リーダーは、ブロック全体を各バリデーターへ直接ブロードキャストする代わりに、決定論的なステーク加重ピアバリデーターツリー（シュレッドグループごとに(leader id, slot, shred index, shred type) でシードされます）を介してシュレッドを転送します。このツリー（DATA_PLANE_FANOUT = 200）により、バリデーター数にかかわらずリーダーの送信帯域幅はほぼ一定に保たれ、ブロックは O(n) ではなく 2～3 ホップでネットワークに到達できます。
ブログ記事Turbine：Solana のブロック伝播を参照してください。
バリデーター
割り当てられたリーダースロット中にブロックを生成し、他のバリデーターのブロックに投票することでコンセンサスに参加する Solana ネットワーク上のノードです。バリデーターは、アクティブステークに比例してリーダースロットに選ばれます。トランザクションの仕組み
アドレスルックアップテーブル（ALT）
バージョン付きトランザクションが完全な 32 バイト公開鍵の代わりに 1 バイトのインデックスで参照できる、Solana アドレスのオンチェーンテーブルです。1 つのトランザクションで最大 256 個のアカウントを参照できます。ALT は、使用しなければトランザクションサイズの上限を超える複雑な DeFi 操作に不可欠です。ブロックハッシュ
最近のブロックを識別する 32 バイトのハッシュで、鮮度を証明するためにすべての Solana トランザクションへ含まれます。ブロックハッシュは約 150 スロット（約 1 分）後に失効します。失効したブロックハッシュを持つトランザクションは拒否されます。クライアントは署名の直前にgetLatestBlockhashで最近のブロックハッシュを取得します。
優先手数料
トランザクションを他より優先し、取り込まれるまでの時間を短縮するため、バリデーターに支払うコンピュートユニット単位のチップです。優先手数料は、コンピュートユニットあたりのマイクロ lamport（µLamports/CU）で設定されます。Helius の優先手数料 APIは、最近のオンチェーン手数料市場に基づくリアルタイムの見積もりを返します。シュレッド
Solana ブロックの最小単位です。ブロックは、Turbineを介してバリデーターネットワーク内で並列に伝播できるよう、シュレッドに分割されます。シュレッドレベルのアクセスにより、トレーダーはブロック組み立て前に超低レイテンシのオンチェーンシグナルを取得できます。ただし、Preconfirmationsはエントリがシュレッド化される前に、さらに早く到着します。 生のシュレッド（UDP）とShred Delivery の概要を参照してください。Stake-Weighted Quality of Service（SWQoS）
送信元のステークに基づいて、現在および今後のリーダーへの受信トランザクションを優先する Solana のプロトコルレベルの仕組みです。2022 年 4 月 30 日に発生した Solana の停止後、シビル攻撃への耐性を高める対策として導入されました。SWQoS は、ステークが少ない、またはステークのないピアが、混雑時にリーダーの帯域幅を独占するのを防ぎます。 リーダーは 2 つの受信接続プールを公開します。全ステークなしピアで共有される約 500 個のオープン接続と、ステーク済みバリデーターへ比例配分される約 2,000 個のステーク加重接続です。総アクティブステークの X% を持つバリデーターは、リーダーに送信されるパケットの最大 X% を送信できます。アクティブステークが約 15,000 SOL（ネットワーク総ステークの約 1/25,000）未満のバリデーターは、ステークなしとして扱われます。最小ステークしきい値は Agave v1.17.31 で導入されました。 Helius のステーク済み接続は、顧客のトランザクションを Solana 最大のバリデーター経由でルーティングすることで、この到達率の利点を引き継ぎます。そのため、呼び出し元は大量のステークを持つバリデーターを直接運用せずに SWQoS の恩恵を受けられます。 ブログ記事Stake-Weighted Quality of Service：知っておくべきすべてのことを参照してください。バージョン付きトランザクション
シリアル化されたトランザクションの先頭にあるバージョンバイトによって識別される Solana トランザクション形式です。バージョン 0（v0）ではアドレスルックアップテーブルが追加され、1 つのトランザクションで最大 256 個のアカウントを参照できるようになりました（従来のトランザクションでは約 35 個）。バージョン 1（v1、SIMD-0385、Agave 4.2）では署名がトランザクションの末尾へ移動し、ComputeBudget 命令の代わりにtransactionConfig ヘッダーフィールドでコンピュート予算を保持します。すべてのバージョンを受信するには、RPC リクエストで maxSupportedTransactionVersion: 1 を設定してください。トランザクション v1 のサポートを参照してください。
トークンとアセット
圧縮アカウント
圧縮アカウントは、完全なデータがバリデーターのディスク上にある従来のアカウントスロットを占有する代わりに、データがトランザクションログを介して台帳にコミットされ、バリデーター状態にはハッシュフィンガープリントのみが保存される Solana アカウントです。開発者は圧縮アカウントを通常のアカウントと同様に扱えます。インデクサー（Photon など）はトランザクションログを解析して現在の状態を再構築し、ZK Compression を介してアカウントを読み取りまたは変更する際は、固定サイズの Groth16 ゼロ知識証明で完全性を検証します。このモデルはデータ量の少ないアカウントに最適です。データが大きい場合（約 100 バイト超）、圧縮は実用的ではありません。圧縮 NFT（cNFT）
独自のアカウントではなく、オンチェーンの並行マークルツリー内のリーフとして表現される Solana NFT です。ツリーは Solana アカウント内にあり、その状態遷移は台帳によって保護されます。NFT の現在の状態はインデクサーがトランザクション履歴から導出し、ツリーのオンチェーンルートに対して検証可能なマークル証明を生成します。そのため、cNFT の読み取りには DAS API のようなインデクサーが必要です。標準の Solana RPC では cNFT データを直接返せません。このモデルでは、標準 NFT と比べてミントコストを最大 99% 削減できます。並行マークルツリー
複数の書き込み元が同じスロット内でツリーを更新しても、互いの証明を無効化しないよう設計された、Solana 固有のマークルツリーの一種です。オンチェーンアカウントには現在のルートだけでなく、最近の有効なルートの変更履歴バッファーとキャノピー（ツリー上部ノードのキャッシュ済みサブセット）も保存されます。これによりバリデーターは、バッファー期間内に残っている任意のルートに対して生成された証明を検証できます。ツリーは 3 つのパラメーターで定義されます。最大深度（リーフ数を 2^depth に制限）、バッファーサイズ（変更履歴の深さ。進行中の古い証明が無効になるまでに可能な書き込み回数）、キャノピー深度（オンチェーンのレントとトランザクション内証明の小ささをトレードオフ）です。有効な（深度、バッファー）の組み合わせは（3, 8）から（30, 2048）までです。実用的なコンポーザビリティを維持するにはmaxDepth − canopyDepth ≤ 10 としてください。
並行マークルツリーは SPL Account Compression プログラムによって実装され、Metaplex Bubblegum を介してリーフとしてミントされる圧縮 NFTの基盤となります。
ブログ記事Solana の圧縮について知っておくべきすべてのことを参照してください。
Groth16
命題の複雑さに関係なく固定サイズのゼロ知識証明（BN254 曲線上で点圧縮を使用した場合は 128 バイト）を生成し、O(1) で検証できる zk-SNARK 証明システムです。ZK Compressionは Groth16 を使用して、圧縮アカウントが既知のルートにおける既知の状態に属していたことを示す有効性証明を生成します。証明サイズが小さいため、圧縮アカウントのトランザクションを低コストに抑えられます。 ブログ記事Solana Builders：ZK Compressionを参照してください。ミントアカウント
SPL トークンのプロパティ（供給量、小数桁数、ミント／凍結権限）を定義するオンチェーンアカウントです。ミントアカウントのアドレスは、そのトークンの標準識別子です（Ethereum でいう「コントラクトアドレス」）。SPL トークン
Solana Program Library（SPL）の Token Program を介して発行される Solana 上のトークンです。代替可能トークン（USDC、BONK、JUP など）は SPL トークンです。標準の（非圧縮）NFT も SPL トークンであり、供給量 1、小数桁数 0 でミントされます。SPL トークンは、おおむね Ethereum の ERC-20 と ERC-721 に相当します。Token-2022 は、転送手数料や機密転送などのオプション機能でこのインターフェースを拡張する新しいプログラムです。状態ツリー
ZK Compressionが圧縮アカウントのハッシュを保存するために使用するマークルツリーです。オンチェーンアカウントは現在のルートと最小限のメタデータのみを保持します。実際の圧縮データはトランザクションログ内にあり、Photonのようなインデクサーによって再構築されます。プログラムは、アカウントが主張する内容のハッシュが現在のルート配下のリーフになることを示す有効性証明を渡すことで、圧縮状態を読み取りまたは変更します。 ZK Compressionを参照してください。トークンアカウント
特定の所有者について、特定の SPL トークンの残高を保持するオンチェーンアカウントです。ウォレットは任意のトークンアカウントを所有できますが、通常は関連トークンアカウント（ATA）を使用します。これは、Associated Token Account Program が（ウォレット、ミント）の各ペアについて決定論的に導出して作成するトークンアカウントです。Token-2022（トークン拡張）
オプションの拡張機能（例：転送手数料、機密転送、利息付きトークン、譲渡不可トークン）をサポートする SPL Token Program の一種です。Token-2022 は独自のプログラム ID を持つ別のオンチェーンプログラムとして動作しますが、従来の Token Program と互換性のある後継として設計されているため、通常 SDK は両方を処理できます。拡張機能を使用するには、Token-2022 プログラムでミントを作成する必要があります。 ブログ記事トークン拡張とは？を参照してください。有効性証明
圧縮アカウントが主張する内容が、特定のルートにおける状態ツリーに存在していたことを示す固定サイズの Groth16 ゼロ知識証明です。ZK Compressionプログラムでは、圧縮アカウントを読み取りまたは変更するたびに有効性証明が必要です。この証明により、バリデーターがデータをオンチェーンに保存しなくても、プログラムはオフチェーン状態を検証できます。Photonは、getValidityProof RPC メソッドを介して呼び出し元に有効性証明を公開します。
有効性証明は、ZK Compression と圧縮 NFTを区別する要素です。cNFT は通常のマークル証明（リーフからルートまでの兄弟ハッシュのリストで、ツリーの深さとともに増大）を使用します。一方、ZK Compression の固定サイズ ZK 証明は、経路や周囲のツリー状態を公開しません。
ブログ記事Solana Builders：ZK Compressionを参照してください。
ZK Compression
ZK Compression は Helius と Light Protocol が開発した Solana プリミティブです。アカウントデータを台帳内のトランザクションログにコミットし、バリデーター状態にはハッシュフィンガープリントのみを保存することで、オンチェーンストレージのコストを大幅に削減します。インデックス化されたトランザクションデータから生成される固定サイズの Groth16 ゼロ知識証明により、暗号学的完全性が維持されます。このプリミティブは、ゼロ知識証明を使用せず並行マークルツリーを使用する圧縮 NFT とは異なります。 詳細については、ZK Compressionとブログ記事Solana Builders：ZK Compressionを参照してください。接続とストリーミング
Geyser
バリデーターの状態変更（アカウント、トランザクション、スロット、ブロック）を外部の利用者へリアルタイムでストリーミングする Solana のプラグインシステムです。バリデーターは Geyser プラグインを動的ライブラリとして読み込みます。プラグインは、バリデーターが状態を処理する際に更新を受信するため、変更を RPC でポーリングする必要がありません。主要な Geyser プラグインである Yellowstone gRPC は、これらの更新を gRPC で公開します。Helius の LaserStream は Yellowstone gRPC インターフェースを実装し、履歴リプレイ（最大約 48 時間、現在のネットワーク速度で約 691,200 スロット）やマルチリージョンフェイルオーバーなどの機能を追加しています。gRPC
gRPC は汎用の高性能バイナリ RPC プロトコルです（「gRPC Remote Procedure Call」の再帰的頭字語）。Solana の文脈で「gRPC」は通常、Yellowstone gRPC を指します。これは Solana の Geyser プラグインシステム上に構築されたストリーミングインターフェースで、アカウントとトランザクションの更新を gRPC で公開します。Helius の LaserStream サービスは Yellowstone ベースのインターフェース上に構築され、履歴リプレイ、マルチリージョンフェイルオーバー、マネージドインフラストラクチャなどの機能を追加しています。RPC
RPC は Remote Procedure Call の略で、サーバーのメソッドをローカル関数のように呼び出すための一般的なパターンです。Solana で「RPC」は多くの場合、RPC ノードを指します。これは Solana の状態を追跡しますがコンセンサスには参加せず、JSON-RPC インターフェースを介したデータリクエスト（アカウント状態、トランザクション履歴、トランザクション送信など）の処理に特化したノードです。対照的に、バリデーターはブロックを生成して投票します。Helius の RPC サービスは、本番ワークロード向けに最適化され、世界各地に分散した RPC ノード群です。 詳細については、ブログ記事Solana ノード — Solana RPC、バリデーター、RPC プロバイダーの入門を参照してください。Webhook
Webhook は、サブスクライブしたイベントが発生したときに、サーバーから受信側 URL へ送信される HTTP POST リクエストです。サーバーが呼び出しを開始する「逆方向」の HTTP です。Helius の Webhooks は、Solana のオンチェーンイベント（転送、NFT 販売、カスタムプログラムのアクティビティ）を登録済みエンドポイントへプッシュするため、ポーリングは不要です。WebSocket（WSS）
WebSocket は HTTP からアップグレードされる永続的な双方向 TCP 接続で、HTTP リクエストを繰り返さずに Solana データをプッシュ型でストリーミングするために使用されます。WSS（WebSocket Secure）は TLS 上で動作する同じプロトコルで、本番環境の Solana 接続に使用されます。LaserStream WebSocketは Helius の WebSocket ストリーミング製品で、標準の Solana メソッドとtransactionSubscribe などの Helius 拡張機能を含み、WSS を使用します。
エコシステム
Anchor
Anchor は、Solana プログラムを迅速かつ安全に構築するための Rust フレームワークです。手続き型マクロを通じて、アカウントのシリアル化、検証、命令のディスパッチなどの定型処理を担うため、開発者は低レベルの詳細ではなくプログラムロジックに集中できます。ほとんどの Solana 開発者は、ネイティブ Rust でプログラムを書く代わりに Anchor を使用します。 詳細については、ブログ記事Anchor 入門：Solana プログラム構築の初心者向けガイドを参照してください。IDL
IDL は Interface Definition Language の略です。IDL は Solana プログラムの命令、アカウント、データ型を記述する JSON スキーマです。クライアントはこれを使用し、命令レイアウトを手作業で実装せずにトランザクションを構築してプログラムデータをデコードします。Anchor は IDL を自動生成し、公開検索できるよう、デフォルトでは専用アカウントでオンチェーンに公開します。Jito
ネットワークで主流のブロックエンジンを運営する Solana エコシステム企業です。このエンジンは、トランザクションバンドル（一緒にすべて実行されるか、まったく実行されないトランザクションのアトミックなグループ）を受け付け、サーチャーがバリデーターにチップを支払って優先的に到達させられる MEV（最大抽出可能価値）インフラストラクチャレイヤーです。 Jito-Solana バリデータークライアントは、ブロックエンジンを統合した Agave のフォークです。バンドルを取り込むには最低 10,000 lamports のチップが必要です。Jito-Relayer はオフチェーンのバンドルオークションを可能にするため、受信トラフィックを約 200 ms 保持します。 Helius の Sender は、ステーク済み接続と Jito のブロックエンジンの両方を介してトランザクションを同時に送信し、先に到達した経路を採用します。 ブログ記事Solana MEV：入門を参照してください。Light Protocol
Helius と共同で ZK Compression を開発した Solana プロトコルチームです。Helius は標準インデクサー（Photon）を構築して公開 RPC を運用し、Light Protocol はインデクサーが依存するオンチェーンプログラムと証明スタックを構築しています。 github.com/Lightprotocol/light-protocolを参照してください。Photon
Helius が構築したオープンソースの ZK Compression インデクサーです。圧縮アカウントデータはアカウント状態ではなく Solana トランザクションログに存在するため、バリデーターは標準 RPC では公開しません。Photon は Solana トランザクションを解析し、圧縮アカウントの状態を再構築して、Solana のネイティブ RPC にgetCompressedAccount や getValidityProof などの ZK Compression 固有メソッドを加えた JSON-RPC インターフェースを介して提供します。開発者は github.com/helius-labs/photon からセルフホストするか、Helius がホストするエンドポイントを使用できます。
ZK Compressionを参照してください。