新着：HeliusがLight Protocolを買収
ステーク加重QoS：知っておくべきすべてのこと
ブログ/リサーチ

ステーク加重QoS：知っておくべきすべてのこと

Developer Experience EngineerXの0xIchigoLinkedInの0xIchigoGitHubの0xIchigo
読了時間：22分
目次

はじめに

Solanaは、高スループットかつ低レイテンシのネットワークとしてブロックチェーン技術の最前線に立ち、分散型ネットワークが実現できることの限界を押し広げています。しかし、それには大きな課題も伴います。Solanaの開発における重要な転機の一つが、2022年4月30日の障害です。この障害により、大量のトランザクションを処理し、高負荷時にもネットワーク性能を維持できる、より堅牢な仕組みの必要性が浮き彫りになりました。

ステーク加重QoS（SWQoS）は、この出来事を受けて開発されました。この仕組みは、バリデータが保有するステークに基づいてネットワークトラフィックを優先し、ステークの多いバリデータがより高い優先度でトランザクションを送信できるようにします。SWQoSは、ステークの少ないバリデータによるネットワークの圧迫を防ぎ、Solanaの耐障害性と効率を高めるために設計されました。

この記事では、SWQoS、Solanaのトランザクション処理モデル、そしてSWQoSがそれに与える影響を解説します。また、ステーク接続とその設定方法、SWQoSと優先手数料の違いも取り上げます。さらに、バリデータとリキッドステーキングトークン（LST）の重要性の高まり、参入障壁、このシステムに内在する信頼上の前提など、今後の影響についても考察します。

この記事は、SolanaのプログラミングモデルとQUICに関する知識を前提としています。これらに詳しくない場合は、本記事を読み進める前に、次の記事をお読みになることをおすすめします。

ただし、必要に応じて背景情報も説明します。

ステーク加重QoSとは？

ステーク加重QoS（SWQoS）は、バリデータが保有するステークに基づいてネットワークトラフィックを優先する仕組みです。ステークの多いバリデータほど効率的にトランザクションを送信できるため、サービス品質が向上します。

SolanaがProof of Stakeネットワークであることを考えれば、ステークによる重み付けをトランザクション性能に適用するのは自然です。簡単に言えば、Solanaはステーク（ネットワークを保護するためにバリデータへロックされた資金）を、そのバリデータがどれほど信頼できるかを示す指標として使用します。バリデータのステークが多いほど、ネットワークの安全性と信頼性に対する利害も大きくなります。また、QoSとは、特定のパケットを優先し、ネットワーク上でより安定した性能を得られるようにするネットワークの概念です。そのためSolanaは、優先接続を介してルーティングすることで、ステーク済みバリデータがトランザクションを送信する際の性能をより安定させます。

SWQoSの主な目的は、ステークの少ないバリデータが大量のトランザクションでネットワークを圧迫し、品質やステークの高いバリデータから送信されたトランザクションを埋もれさせることを防ぐことです。たとえば、あるバリデータが総ステークの5%を保有している場合、リーダーに送信できるパケットも全体の5%です。SWQoSは、悪意ある攻撃者が「低品質」なトランザクションでネットワークをあふれさせることを難しくする、シビル耐性の仕組みと考えられます。

チケット数が限られた人気のコンサートや遊園地にいる場面を想像してください。誰でも並んでチケットを購入できる通常の列は、長くなって進みが遅くなることがあります。一方、料金を多く支払う顧客向けのVIP列もあります。特定の会員資格などの条件を満たす人だけが利用でき、一度に一定数の入場が保証されるため、VIP列は通常より短く速く進みます。SolanaにおけるSWQoSは、このVIP列のようなものです。利用できる範囲は、バリデータが保有するステーク量によって決まります。ステークが多いほど、より多くのVIPアクセス（つまり優先接続）が得られ、チケット（トランザクション）をより迅速かつ確実に処理できます。

では、実際にはどのように機能するのでしょうか。まず、Solanaがトランザクションを処理する仕組みを理解することが重要です。

Solanaがトランザクションを処理する仕組み

SolanaのTransaction Processing Unit（TPU）は、トランザクションを効率的に処理、実行します。トランザクションの検証、実行、ネットワーク全体への伝播を確実に行うため、処理はいくつかの明確な段階に分かれています。Fetch Stage、SigVerify Stage、Banking Stage、Proof of History（PoH）Service、Broadcast Stageです。

Fetch Stage

Fetch Stageは、ネットワーク経由でクライアントから届くトランザクションを受信します。UDPソケットからの入力をバッチ化し、次の3つの主要なソケットに分類します。

  • tpu：トークン転送、NFTミント、プログラム操作などの通常のトランザクション用
  • tpu_vote：投票トランザクション用
  • tpu_forwards：現在のリーダーがすべてのトランザクションを処理できない場合、未処理のパケットを次のリーダーへ転送します。

これらのソケットはGossip内で作成され、ContactInfo構造体に格納され、対応するソケットでタグ付けされます。

Fetch Stageは、同時に受信したパケットをまとめる仕組みを使い、個別のパケット処理回数を減らしながらスループットを高めます。転送されたパケットを受信すると、後続のステージで正しく識別できるよう、FORWARDEDフラグを付けます。ノードが現在のリーダーでない場合、不要な処理を防ぐため、これらの転送パケットは破棄されます。ただし、そのノードがリーダーであれば、パケットは受け入れられ、適切に処理されます。

Fetch Stageは、トランザクションを次のSigVerify Stageへ渡すために、無制限チャネル（packet_sender、packet_receiverなど）を作成します。これらのチャネルによってTPUの各ステージが分離され、互いにブロックされることなく並行して動作できます。unbounded関数は、チャネルのオーバーフローによるパケットの破棄を防ぐため、容量無制限のチャネルを作成します。

トランザクションは128パケットずつのグループにまとめられてから、SigVerify Stageへ転送されます。このバッチ処理により、トランザクションを効率よく処理し、個々のパケットを扱うオーバーヘッドを削減できます。

Fetch Stageは、高スループットを処理するため、複数のスレッドで動作します。各スレッドは、パケットの受信、バッチの処理、トランザクションの転送など、特定のタスクを担当します。streamer::receiver関数を使用して、各ソケットタイプ（tpu、tpu_vote、tpu_forwards）に対応するスレッドが作成されます。各スレッドは割り当てられたソケットを監視し、受信パケットを処理して適切なチャネルへ送信します。

Fetch Stageは、受信したトランザクションを効率よく管理、分類することで、SolanaのTPUにおける後続のすべての処理ステージの基盤を整えます。

SigVerify Stage

SigVerify Stageは、Solanaのトランザクション処理パイプラインにおける第2段階です。トランザクションの完全性と真正性を保証するうえで重要です。

このステージでは、TPUが無制限チャネルを介してFetch Stageからバッチ化されたトランザクションを受信します。ここでの主なタスクは、Ed25519署名方式を使ってトランザクションの署名を検証することです。この暗号学的検証により、関係するアカウントの正当な所有者がトランザクションに署名したことを確認します。

SigVerify Stageは高い性能を発揮するよう設計されており、最新のCPUとGPUの並列処理能力を活用して署名を検証します。デフォルトではCPUがすべての処理を行います。ただし、処理が並列化されているため、パフォーマンスライブラリを利用できる場合はGPUへのオフロードによって処理が大幅に高速化されます。

処理は、SigVerify Stageを初期化し、Fetch Stageからパケットを受信するために必要な受信チャネルを設定するnew関数から始まります。verifier関数は、ブラケットの受信と署名の検証を担います。重複を排除し、過剰なパケットを破棄して、残ったパケットを検証します。この関数は、ed25519_verify署名検証メソッドを使用します。トランザクション量が多い期間には、負荷制限が行われます。つまり、SigVerify Stageが過剰なパケットを破棄します。送信元IPアドレスごとにパケットをグループ化し、アドレスごとに処理するパケットの最大数を割り当てることで実現します。

無効な署名を持つトランザクションにはフラグが付けられ、破棄されます。この破棄処理により、有効なトランザクションだけが先へ進み、不正または誤ったトランザクションが次のステージに進むことを防ぎます。

署名検証後、有効なトランザクションは別の無制限チャネル群を通じて次のステージ、つまりBanking Stageへ渡されます。これにより、各ステージは分離されたまま並行して動作できます。このステージも複数のスレッドで動作し、各スレッドがトランザクションの一部を処理して、署名検証、重複排除、負荷制限を行います。

Banking Stage

Banking Stageは、Solanaのトランザクション処理パイプラインにおける第3段階です。トランザクションが実行され、台帳の現在の状態に適用されるため、非常に重要なステージです。Banking Stageは、Solana独自のSealevelランタイムを活用し、高スループットの並列トランザクション処理を可能にします。

Banking Stageには6つのスレッドがあります。2つはTPUまたはGossipから届く投票トランザクションの処理専用で、4つは非投票トランザクション専用です。各スレッドは独立して動作し、SigVerifyがパケットをバッチで送信する共有チャネル（これは1.18以降に変更される予定です）からパケットを受信します。各スレッドはこの共有チャネルからトランザクションを取り出し、ローカルバッファに保存します。ローカルバッファは優先度キューとして機能し、トランザクションの状態やネットワーク需要のリアルタイムな変化を反映するよう動的に更新されます。

これらのトランザクションの扱いは、バリデータがリーダースケジュールに入っているかどうかで決まります。バリデータがリーダーになる順番から遠い場合、パケットを次のリーダーへ転送してから破棄します。自分の順番が近づくと（約~20スロット前）、後続のリーダーが処理に失敗した場合に備えてパケットを保持しつつ、転送も続けます。リーダーになる2スロット前になると、リーダーになった際に確実に処理できるよう、パケットを保持します。

各スレッドは、ブロック生成中にローカルキューの先頭から128件のトランザクションを取得して処理します。この処理には、ロック、チェック、読み込み、実行、記録、コミット、ロック解除などの手順が含まれます。

Banking Stageは、マルチイテレータ方式を使ってトランザクションをバッチ化します。この方式では、データセットを同時に走査し、競合しないトランザクションをまとめてバッチにできます。まず、トランザクションを優先度順のベクターにシリアライズします。次に、マルチイテレータがトランザクション同士の競合しない位置にイテレータを配置し、128件のトランザクションからなるバッチを作成します。競合するトランザクションはスキップされ、競合の解消後に後続のバッチへ含められます。バッチの作成後、トランザクションが実行されます。成功したトランザクションはProof of History Serviceに記録され、Turbineを介してネットワークへブロードキャストされます。

Proof of History（PoH）Service

Proof of History（PoH）Serviceは、Solanaのトランザクション処理パイプラインを構成する基本要素です。ネットワーク内の時間とイベントの順序を検証可能な方法で追跡し、トランザクションを効率的かつ安全に並べます。ハッシュチェーンを介してトランザクションのタイムスタンプとして機能する暗号学的シーケンスを生成します。この連続したハッシュチェーンが、イベント間で時間が経過したことを証明する履歴記録になります。

PoH Serviceにより、ネットワークのすべての参加者は、中央の計時機関を必要とせずにトランザクションの順序について合意できます。また、ネットワーク全体のバリデータを同期する役割も果たします。信頼できるタイムスタンプを提供し、バリデータがいつリーダーになって次のブロックを生成すべきかを判断できるようにすることで、Solanaのリーダー選出プロセスを支えます。

PoH Serviceは、ハッシュのシーケンスを生成するシード値の初期化から始まります。トランザクションを受信すると、PoHシーケンスの現在のハッシュがタグ付けされ、一意のタイムスタンプが付与されます。その後、バリデータはハッシュのシーケンスを検証し、トランザクションの順序とタイミングを確認します。

Proof of Historyについて詳しく知るには、Proof of History、Proof of Stake、Proof of Workを解説をお読みください。暗号技術が未知の言語のように感じられる場合は、暗号ツール入門 — ハッシュ関数とマークルツリーを解説もおすすめします。

Broadcast Stage

Broadcast Stageは、Solanaのトランザクション処理パイプラインにおける最終段階です。検証、確定されたトランザクションをネットワークの残りの部分へ配信します。

Banking Stageでトランザクションが処理、コミットされると、エントリとしてまとめられます。これらのエントリは、shredと呼ばれるデータ構造にパッケージ化されます。Broadcast Stageはshredをシリアライズして署名し、データの完全性と復旧性を高めるために消失訂正符号を生成します。shredは、Turbineと呼ばれる構造化されたツリー状の配信プロセスを通じてピアへ送信されます。これは効率的で冗長性のある配信プロセスであり、消失訂正符号によって、バリデータは欠損または破損したデータを復元できます。

Turbineの詳細については、Turbine：Solanaにおけるブロック伝播をお読みください。

SWQoSを利用したトランザクションのライフサイクル

ほかのブロックチェーンとは異なり、Solanaには処理前のトランザクションが待機するmempoolがありません。代わりに、トランザクションは現在のリーダーへ直接ルーティングされ、そのTPUで処理されます。ユーザーはウォレットやアプリケーションを使って直接または間接的に、あるいはプログラムからトランザクションを作成し、JSON RPC APIを介してRPCノードへ送信します。これらのノードは、ユーザーとSolanaのバリデータの仲介役を果たします。重要なのは、これらのノードがネットワーク内にステークを持つべきではないことです。つまり、RPCノードはステークされず、投票を行わず、したがってコンセンサスにも参加しません。

リーダーへの接続には現在、QUICが使われています。SolanaのTPUでは、UDPに代わって、ユーザーのトランザクションを受け付けるポートにQUICが追加されました。QUICではハンドシェイクが必要なため、アクターのトラフィックに上限を設け、スパムを除外しながら正規のトランザクション処理にネットワークを集中させられます。もちろん、これがQUIC導入の意図でしたが、現在の有効性についてはこの記事では議論しません。重要なのは、リーダーへの接続がQUIC経由で確立されることです。

接続には2つの種類があります。

  • あらゆるRPCノードが利用できる500のオープン接続
  • ステーク済みバリデータだけが利用できる2,000のステーク加重接続。バリデータには、そのステークに比例した接続枠が割り当てられます

RPCがトランザクションを効率よく中継するには、ステーク済みバリデータとピアリングする必要があります。RPC自体はネットワーク内にステークを持たないため、バリデータが自身のステークを仮想的に拡張する必要があります。バリデータは--staked-nodes-overridesフラグを使い、ステーク接続の一部を特定のRPCノードへ割り当てられます。

バリデータは、ステーク加重接続を設定するため、--staked-nodes-overrides flagを使用してYAMLファイルのパスを指定する必要があります。YAMLファイルには、次の形式のマッピングが含まれます。

コード
staked_map_id:
	<pubkey_of_RPC>: 80000000000000000

特定のRPCアイデンティティの各公開鍵には、lamports単位の値が必要です。この値は、RPCアイデンティティに付与するステークウェイトを指定します。たとえば100万SOLを指定した場合、割り当てられるのは100万SOLを有効な総ステークで割った割合です。実質的には、そのRPCノードをネットワーク内で同量のステークを持つバリデータとみなし、ステーク接続を付与します。つまり、「ローカルビューでは、このRPCアイデンティティが私のバリデータと通信する際、xのステークを持つものとして扱う」と指定します。この設定ではバリデータの再起動は不要です。ファイルを変更し、動作中に再読み込みできます。

さらに、Jito relayerはstaked node overridesフラグに対応しています。性能を最適化するため、relayerはステーク済みノードと同じマシンで実行することをおすすめします。

これらのステーク接続を利用するには、RPCオペレーターが--rpc-send-transaction-tpu-peerフラグを使用する必要があります。このフラグには、ステーク済みバリデータのTPUのIPとポートが必要です。Gossipで確認できるように、TPUポートは通常、動的ポート範囲の開始値に3を加えたものです。Jitoの場合、公開Jito relayerは使用できないため、トラフィックはオペレーターが実行するrelayerへ送られます。RPCオペレーターは接続を検証するため、ログでsolana_quic_clientやwarmのようなエントリを確認する必要があります。この設定に必要なフラグをサポートするには、RPCノードでv1.17.28以降のAgaveクライアントを実行する必要があります。

全体として、SWQoSを利用したトランザクションのライフサイクルは、通常のトランザクションとほぼ同じです。ユーザーがRPCノードを介してトランザクションを作成、送信し、RPCノードがリーダーへ送ります。ただし、RPCノードがステーク済みバリデータとピアリングし、--rpc-send-transaction-tpu-peerフラグを使用している場合、トランザクションはステーク接続を介して送信されます。まとめると、次のようになります。

  • トランザクションの作成：ユーザーがウォレットやアプリケーションを使用するか、プログラムからトランザクションを作成します
  • RPCノードへの送信：JSON RPC APIを介してトランザクションをRPCノードへ送信します
  • QUIC接続：RPCノードはリーダーとのQUIC接続を確立し、設定に応じてオープン接続またはステーク加重接続を利用します
  • ステーク加重QoS：RPCノードがステーク済みバリデータとピアリングしている場合、そのバリデータのステーク接続を使用するため、トランザクション性能が向上します
  • リーダーへの転送：これらのステーク接続を通じてトランザクションがリーダーへ送られ、遅延または破棄される可能性が低下します
  • トランザクション処理：前述のとおり、トランザクションはTPUを通過し、リーダーによって処理されます

SWQoSは、ステーク済みバリデータとピアリングされたRPCノードがリーダーへ接続しやすくすることで、トランザクションのライフサイクルを改善し、ネットワーク混雑による遅延の可能性を低減します。この仕組みは優先手数料と連携し、トランザクション性能を高めます。

SWQoSと優先手数料：明確な違い

ネットワークが混雑している場合、SWQoSにより、ステークの多いバリデータのトランザクションは遅延または破棄されにくくなります。このシステムは一般に、ステークの多いバリデータが高速道路の車線数が増えるように、混雑の少ない経路を利用できる有料道路に例えられます。上の写真を例にしましょう。コロラド州では、ドライバーは渋滞の中で待つか、追加で数ドルを支払って有料レーンを走行できます。Express Lanesはコロラド州のプレミアムレーン網で、交通が円滑に流れるだけの高い料金になるよう、常に価格が調整されています。そのためSolanaのステーク接続は、プレミアムユーザーの混雑を緩和するための優先経路という点で、コロラド州のExpress Lanesに例えられます。

ただし、有料道路という一般的な比喩では2つの概念の違いが曖昧になる可能性があるため、SWQoSと優先手数料を区別することが重要です。

  • 優先手数料はBanking Stageで機能し、リーダーは支払われた手数料に基づいてトランザクションを優先します。手数料の高いトランザクションを先に処理し、追加料金を支払う意思のあるユーザーに、より速い実行を提供するという考え方です。
  • SWQoSは接続アクセスを改善するもので、リーダーのトランザクションキュー内における優先順位には影響しません。SWQoSにより、ステーク済みバリデータはネットワークへ接続しやすくなり、ネットワーク混雑によってトランザクションが遅延または破棄される可能性が低下します

優先手数料は、リーダーのキューに入った後のトランザクションの順序と処理方法に影響します。一方、SWQoSは、ステーク済みバリデータから送信されたトランザクションがリーダーへ到達するための優先経路を確保します。どちらの仕組みもネットワーク性能の向上を目的としていますが、トランザクションのライフサイクルにおける異なる段階で機能します。

SWQoS戦争

今後、SWQoSはSolanaのネットワークインフラの基本要素になる見込みです。トランザクション処理を最適化し、ステーク済みバリデータからリーダーへの接続を優先することで、エコシステムに大きな影響を与えます。この事実は、いくら強調してもしすぎることはありません。

ネットワークが混雑しておらず、トランザクションに時間的制約がない場合、ステークの多いバリデータを使う利点は薄れると言えます。背後にあるステークウェイトに関係なく、トランザクションを迅速に処理する十分な容量がネットワークにあるためです。しかし、大規模な普及が視野に入りSolanaへの需要が増えると、すべてのトランザクションを遅延や一時的な破棄なしに処理できるだけの容量が、常に確保されるとは限りません。これはSolanaがスケールできないという意味ではありません。Solanaは、スケーラブルなブロックチェーンを実現する最有力候補の一つ、あるいは最有力候補だと言えるでしょう。重要なのは、需要が拡大するにつれ、優れたUXを実現するうえでSWQoSが引き続き重要になるということです。

それに伴い、バリデータの役割はさらに重要になり、可能な限り優れたサービスを提供するための競争とイノベーションも活発になります。そうなると当然、誰もが独自のバリデータを立ち上げたいと考えるのではないでしょうか。

バリデータとリキッドステーキングトークン（LST）

傾向は明らかです。本格的なSolanaプロトコルは、すべてバリデータを運用するようになります。アプリケーションを支えるために必要になるからです。独自のバリデータ運用に関心がある場合は、Heliusブログのスタートガイドをご覧ください。

Solanaでは、SWQoSによって勢いを増すLSTの大規模なカンブリア爆発が目前に迫っています。今月だけでも、総ステーク（Native + LST）は約320万増加しています。LSTだけでも、今月の市場価値は現在60億〜90億ドルの範囲です。Sanctumのようなプロトコルは、バリデータやアプリが独自のLSTを作成できるプラットフォームを提供しており、主要プレイヤーになりつつあります。さらに、Picasso NetworkはSolanaでのリステーキングを可能にし、LSTの有用性と利回りを高めるハブとして機能します。付加的な有用性を持つLSTを作成する機能は、すでに実現し、本格的に活用されています。

ただし、潜在的な参入障壁もいくつか考慮する必要があります。

参入障壁

SWQoSには潜在的な利点がある一方、いくつかの参入障壁も生じます。具体的には、ステークの少ないバリデータを未ステークのピアとして扱うため、Agaveクライアントのv1.17.31で最低ステーク要件が導入されました。ステークの少ないノードが、不釣り合いな帯域幅を受け取ってステーク接続を悪用できることが問題だったためです。現在は、ステーク比率が次の式を下回るノードは未ステークとして扱われます。

コード
stake / total_stake < 1 / (max packet per 100ms)

つまり、ステークが約15,000 SOL未満のクライアントは、未ステークのバリデータとして分類されるようになりました。この要件により、Solanaバリデータの運用にすでに必要な高い資金面・技術面の負担がさらに増え、小規模な参加者や独立系バリデータがネットワークへ参加しにくくなる可能性があります。この要件は約300万米ドルに相当し、一見すると高額です。

しかし、Austin Federa氏が指摘しているように、しきい値は総ステークの25,000分の1にすぎず、低い水準とも言えます。また、ステークを競う大多数のバリデータが、可能な限り優れたサービスを提供し、自らの収益を最大化するために継続的に性能を改善すれば、ネットワーク全体にも利益があります。これはまさに、Toly氏がSWQoSの全体的な目的として説明していることです。

Heliusでは、Heliusが推奨する手数料でトランザクションを送信するすべての有料プランを対象に、参入障壁を引き下げています。つまり、有料の共有プランからトランザクションを送信するユーザーは、Priority Fee APIが提示する推奨値以上の手数料を設定すれば、Heliusのステーク接続を介してルーティングされます。また、Node.jsおよびRust SDKに追加した新しいSmart Transactions機能により、このプロセスを効率化しました。基本的には、使用するSDKにかかわらず、ユーザーがキーペアと実行したい命令を提供すれば、残りはHeliusが処理します。現在は、Developerプランなら月額50米ドルから共有ステーク接続を利用できます。また、ステーク接続の帯域幅を保証する専用ステーク接続も提供しており、企業、クオンツ、トレーディング会社におすすめです。専用ステーク接続に関心がある場合は、営業チームにお問い合わせください。

ステークは、大規模なプロトコルや0%の手数料を設定できるRPCプロバイダーが運用するバリデータへ集中していく可能性が高い点に注意が必要です。Heliusを例にすると、別の事業から収益を得て、バリデータの運用コストを補えます。Solanaネイティブのチームが上位バリデータを運用してネットワークの分散化を進めるとともに、ステーク接続へのアクセスを拡大してユーザー体験を向上させるために、私たちはこの取り組みを行っています。

信頼上の前提

大規模なプロトコルやRPCプロバイダーが運用するバリデータへステークが集中する可能性が高いのであれば、Solanaの利益を最優先に考えるバリデータへステークすることが重要です。SWQoSには、いくつかの信頼上の前提があります。

主な信頼上の前提の一つは、バリデータとRPCノードの間に高いレベルの信頼が必要なことです。ここまで説明してきたように、SWQoSでは、リーダーがステーク済みバリデータからのトランザクションを識別し、優先できます。RPCノードはステークされず、投票を行わず、コンセンサスにも参加しないため、ステーク済みバリデータと同じ方法で優先トランザクションの恩恵を直接受けることはできません。そのため、SWQoSの利点を活用するには、バリデータとRPCノードの間に信頼関係を築く必要があります。

SWQoSを有効にするには、機密性の高いネットワーク設定を共有し、RPCノードがトランザクションの優先度に影響を与えられるようにするため、この信頼関係は非常に重要です。バリデータは、ピアリングするRPCノードがネットワークの利益を考えて行動し、拡張されたステークを悪意ある目的で悪用しないことを確認する必要があります。バリデータとRPCノードは、ステーク接続の用途について事前に合意し、相互理解を持つべきです。理想的には、長年のパートナーや同じ組織内など、高い信頼関係を持つ主体同士で設定する必要があります。

現在、こうした関係は隠されていることが少なくありません。そして今後、RPCオペレーターがステーク上書きについてバリデータと交渉しない未来は想像できません。一般ユーザーが自分の利用するRPCとバリデータを把握できるよう、透明性をさらに高める必要があります。その需要は時間とともに増す一方でしょう。

まとめ

SWQoSは、Solanaのネットワークインフラを一変させる可能性を秘めています。トランザクション性能の向上やシビル耐性の改善など、多くの利点がある一方で、慎重に対処すべき新たな課題と信頼上の前提も生じます。SWQoSはステーク済みバリデータから送信されたトランザクションを優先するよう設計されていますが、現時点では、その優先度を強制する仕組みはありません。本格的なバリデータはデフォルト設定を上書きすることが多く、特定のアクターをブロックする場合さえあります。これは、SWQoSを公正かつ効果的に使用するため、バリデータとRPCノードの関係に信頼と透明性が必要であることを示しています。それでも、その導入は、効率的で耐障害性の高いネットワークへとSolanaが進化するうえで、大きな一歩です。

この記事では、SWQoSと、それがトランザクション処理に与える影響を解説しました。また、SWQoSと優先手数料の違いなど、重要な区別も取り上げました。さらに、バリデータとLSTの台頭、潜在的な参入障壁、関係する信頼上の前提について議論し、今後の議論に向けた重要な出発点を示しました。SWQoSを効果的に活用し、Solana全体を改善するには、これらすべての要素を理解することが不可欠です。

ここまでお読みいただき、ありがとうございます！以下にメールアドレスを入力して、Solanaの最新情報を見逃さないようにしましょう。さらに深く知りたいですか？今すぐHeliusブログの最新記事を読み、Solanaの旅を続けてください。

その他のリソース

関連記事

Heliusを購読

Solana開発の最新情報や新しい記事の公開通知を受け取れます

拡大画像