Alpenglow移行後、SolanaのTPSは低下 — バリデータ投票がトランザクション数から外れた
重要ポイント
- •Solanaは10月21日にAlpenglowアップグレードを有効化し、TowerBFTをVotorトコルに置き換えた。Votorではバリデータ投票がトランザクションとして記録されず、ブロックフッターの証明書にまとめられる。
- •最後のTowerBFTブロックではトランザクション約5分の3（合計649件）がバリデータ投票だった一方、最初のAlpenglowブロックにはゼロだったが、それでも規模は大きいほうだった。
- •Solana Foundationはアップグレード後のTPS低下をスループットの後退ではなく計上方法の変更と位置づけるが、10月21日以降の数値は従来の数値とは異なる定義で集計されている。
- •最初のAlpenglowブロックでは1,701件中844件が実行エラーに達しており、投票を除いた集計でも、手数料を支払いながら支払いや取引を完了しなかった失敗トランザクションが含まれ続ける。
- •Voteプログラムの命令でバリデータ参加を追跡していた監視ツールはブロックフッターの投票証明書を読むよう改修が必要で、10月21日をまたぐTPSチャートは帳簿上の変更と実際の利用変化が混ざっている。
Solanaは10月21日にAlpenglowを有効化した際、トランザクション数と、それに連動する公表上の1秒あたりのトランザクション数（TPS）が減少しました。Solana Foundationのアップグレードドキュメントはこの減少を「計上方法の変更であり、スループットの後退ではない」と説明しています。この説明があっても、Solanaのチャートを見る人には疑問が残ります。活動自体が落ちたのか、それとも計上数だけが減ったのか。TPSはブロックチェーン報道で最も引用されるスループット指標の一つであり、10月21日以降のSolanaの集計はそれ以前に公表されたすべての数値とは異なる定義で行われているため、その答えは単なる移行日の問題にとどまりません。
Alpenglowがトランザクションリストから取り除いたもの
10月21日までSolanaが運用していたTowerBFTというコンセンサスシステムでは、バリデータは投票をのトランザクションとして発行していました。ブロックには支払いやスワップ、その他のアプリケーショントラフィックとともに数百件の投票が載り、総トランザクション数の集計にはその投票トラフィックが含まれていました。これらの投票はユーザーではなくバリデータから発信されたもののため、アップグレード前のTPS数値の一部は、アプリケーションへの需要ではなくネットワークのコンセンサス機構を反映していました。
Alpenglowはこの仕組みをVotorに置き換えます。Votorは、バリデータが投票を直接交換し、それを証明書にまとめるプロトコルです。証明書はトランザクションリストではなく各ブロックのフッターに格納されるため、トランザクションを集計するカウンターは切り替えの瞬間から投票を認識しなくなります。
移行時のブロックが示すもの
Coindooは、Solanaの公開メインネットRPC（ノードがチェーンデータの読み取り用に公開しているインターフェース）を通じて、切り替えの前後のブロックをgetBlockメソッドで調べました。各ブロックは1スロット、およそ400ミリ秒の区間を占有します。TowerBFTはエポックの最初の5,000スロットで稼働し、その後Alpenglowに置き換えられました。
最後のTowerBFTブロックは10月21日13:54:00 UTCに生成され、最初のAlpenglowブロックは13:54:03に続きました。間の8スロットではブロックが生成されていません。最後のTowerBFTブロックのトランザクションの約5分の3、合計649件はバリデータ投票で、1ブロック後にはゼロでした。それでもAlpenglowブロックのほうが大きいままでした。2ブロックだけではネットワーク活動の増減は判断できず、仕組みが示されているにすぎません。傾向の測定には数千ブロックが必要です。
投票だけがカウントのノイズではない
失敗が次の層です。各トランザクションのメタデータのエラーフィールドを読んだところ、最初のAlpenglowブロックの1,701件のうち844件が実行エラーに達し、成功したのは857件でした。失敗トランザクションも手数料を支払い、ブロック内に残りますが、支払いも取引も完了していません。「計上方法の変更」という説明が扱うのは投票の層だけなので、投票を除いた集計でも、実際に完了した処理を記述する前にエラーフィールドによる除外が必要です。
成功したトランザクも人に対応するわけではありません。1つの自動取引アカウントが大量のトランザクションを送れるうえ、1つのトランザクションに複数の命令を含められます。完了したスワップやトークン移転など、トランザクションが実際に達成した内容を数えるほうが、単純なトランザクション総数よりも実利用に近い指標になります。
比較データの所在
SolanaのgetRecentPerformanceSamplesメソッドは、各サンプルについて総トランザクション数、非投票数、サンプル長（秒）を報告します。数値をサンプル長で割ると、その区間の平均レートが得られます。
このメソッドは約1分のサンプルを最大720件、おおよそ直近12時間分を返します。移行から半日以上経ってからの照会ではTowerBFTまで遡れないため、比較のアップグレード前側はそれ以前に保存されたサンプルか過去ブロックから取得する必要があります。
切り替えの前後で同一に適用する3つのフィルターによって、比較は意味を持ちます。
- バリデータ投票を除外する。Alpenglowは新しい側でこれを自動的に行うが、旧側は手動で行う必要がある。
- 各トランザクションのエラーフィールドに基づいて失敗トランザクションを除外する。APIの非投票数には失敗が含まれ続ける。
- 同じ時間枠を比較する。1分平均と1分平均を比べ、ダッシュボードのピーク値と日次合計を比べてはならない。
投票を読むツールには改修が必要
投票トランザクションはTPSを押し上げていた以上の役割を担っていました。監視ツールはトランザクションリストからVoteプログラムの命令を読み、どのバリデータが参加しているかを追跡していました。Alpenglowではその入力がなくなり、Foundationはこうしたツールにブロックフッターの投票証明書を読むよう案内しています。旧ソースを読み続ける追跡ツールは、バリデータが投票し続けているのに沈黙したように表示してしまいます。
Solanaの利用実態の数値は、成功した非投票トランザクションの数日分を、同じ時間帯をカバーする保存済みのアップグレード前データと突き合わせられるようになって初めて意味のある形で得られます。それまでの間、10月21日をまたぐ公表上のTPSチャートは、帳簿上の変更と実際の利用の変化が混ざった状態です。
出典：Coindoo
