P-Token：Solanaの次なる大幅な効率向上

はじめに

Solanaが急速に普及した背景として、過小評価されがちな要因の一つが、安全かつシンプルで標準化されたトークンへのアプローチです。他の多くのブロックチェーンとは異なり、Solanaでトークンを作成するためにカスタムコントラクトをデプロイする必要はありません。代わりに、すべての処理はSolana Labsが最初にデプロイした、徹底的に監査済みで実戦検証されたSPL token program（別名Tokenkeg）を通じて実行されます。このアプローチにより、トークンのミント、バーン、転送といった一般的な操作が非常に簡単になります。たとえば、Solanaトークンは1つのCLIコマンドだけでデプロイできます。

SPL Token Programは、Solana上で最も多く利用されているプログラムです（Systemプログラムを除く）。過去6か月間、SPL tokenプログラムを通じて毎週作成された新規ファンジブルトークンは、平均20万〜30万件でした。これは、新規SPL tokenの週間作成数が恒常的に1万件未満だった2年前の2023年9月と比べて、20倍の増加です。全体として、2023年を除き、Solanaのローンチ以降は毎年、新規発行トークン数が大幅に増加しています。以下のグラフにその推移を示します。

SPL tokenの転送件数は、さらに顕著に増加しています。過去3か月間、週間転送件数は一貫して6億5,000万件を超え、7月下旬には8億6,780万件のピークに達しました。このピークは、2023年8月上旬に記録された週間4,940万件という低水準の17.5倍に相当します。

P-Tokenの登場

P-tokenは、現行のSPL Tokenプログラムをそのまま置き換えられるコンピュート最適化実装です。Anzaチームが3月にSIMD-0266: Efficient Token Programで初めて提案しました。既存のSPL tokenとの完全な後方互換性を維持しながら、コンピュートユニット（CU）の使用量を大幅に削減します。 

p-tokenはSPL Tokenプログラムとまったく同じ命令セットとアカウントレイアウトを再現しているため、直接置き換えられます。つまり、p-tokenは新しいトークン標準ではありません。クライアントコードは従来どおり動作し続けるため、アプリケーションやユーザー側で変更することなく、移行による大幅な効率向上を実現できます。

p-tokenの導入促進は、Solanaが進めるプログラムとフレームワーク全体の効率向上という方針に沿うものです。これはネットワーク容量を拡大する取り組みを補完し、とりわけ2025年の目標である利用可能なブロックスペースの倍増につながります。

SolanaにおけるプロプライエタリAMMの最近の成功は、コンピュートコストの低減がもたらす効果と、高効率プログラムの優位性を示しています。たとえば、HumidiFiのようなプラットフォームでは、オラクル更新がわずか143 CUまで徹底的に最適化されています。BlueShiftが開発した新しいオープンソースのオラクルプログラムDopplerは、コストをさらにわずか21 CUまで削減します。

Pinocchio

p-tokenの「p」は、Anzaが開発したSolanaプログラム作成用の最適化された高性能かつ依存関係ゼロのライブラリ、Pinocchioを意味します。Pinocchioは標準のsolana-program crateに代わるもので、命令データとアカウントデータの処理にゼロコピー型を広範に使用します。ゼロコピーでは、データの読み書き時に新しいメモリ領域へ複製しません。代わりに、ポインターを通じて状態へ直接アクセスします。この設計は、不要なメモリ操作を避けてコンピュートを大幅に節約すると同時に、ランタイムのオーバーヘッドも削減します。

Pinocchioはno_stdでもあります。Solana Virtual Machine（SVM）がすでにランタイム環境を提供しているため、Rustの標準ライブラリやヒープ割り当てに依存しません。これにより実行がさらに効率化され、依存関係も減少し、より軽量で高速なプログラムを実現します。

効率向上

CUは、Solanaのランタイムにおける実行コストを測定する単位です。2つの整数の加算やビット演算など、最小の操作は1 CUを消費します。上限は命令あたり20万CU、トランザクションあたり140万CUです。

P-Tokenは劇的な効率向上をもたらし、標準的なSPL tokenトランザクションのCU消費量を約95%削減します（効率は19倍向上）。実行の高速化によってユーザー体験が滑らかになるだけでなく、解放されたコンピュートにより各ブロックへより多くのトランザクションを格納でき、ネットワークのスループットが直接向上します。

現在、Tokenプログラムの命令はブロック全体のCU使用量の約10%を占めています。そのコストを現行水準のわずか5%まで削減することで、p-tokenはこの比率を10%から0.5%へ引き下げ、他のトランザクション向けにブロック容量をさらに9.5%確保できます。p-tokenは後続のプログラムにもメリットをもたらし、CU使用量全体とクロスプログラム呼び出し（CPI）のコストを削減することで、コンポーザビリティを向上させます。

以下のグラフと表は、現行のSPL Tokenプログラムと比較したp-token命令のCU効率向上を詳しく示しています。

主に`no_std`によって実現したもう一つの注目すべき最適化は、プログラムのバイナリサイズを131 KBから95 KBへ削減したことです。

追加命令

P-tokenでは、元のSPL tokenプログラムにはない3つの新しい命令（`withdraw_excess_lamports`、`batch`、`unwrap_lamports`）をTokenプログラムへ追加することが提案されています。

余剰Lamportの引き出し

現行のSPL Token-2022実装と同様に、`withdraw_excess_lamports`を使用すると、ミントアカウント内で回収不能になった余剰SOLを回収できます。通常、これはユーザーが誤ってトークンのミントアカウントへlamportを送信した場合に発生します。

引き出しにはミント権限者の承認が必要です。標準的なミントアカウントでは指定された署名者、マルチシグアカウントではマルチシグが承認します。ほとんどのSPL tokenではミント権限が失効しているため、代わりにミントアカウント自体を署名権限者として使用し、ミントの秘密鍵で命令へ署名することで承認できます。

すべてのSPL tokenミントアカウントのうち、約869,000件が最低レント免除基準の0.0014616 SOLを超えるSOLを保有しています。合計すると、176,961.5 SOLがトークンのミントアカウント内にロックされています。現在の価格で3,600万米ドル相当です。トークンのミントアカウント内にロックされたSOLのうち、最大級の残高は通常、ミームコイン、レガシートークン、主要な優良資産に関連しています。単一のトークンのミントアカウント内でロックされているSOLとして最大なのは、ミームコインのBOOK OF MEME（$BOME）で、6,328 SOLです。p-tokenが導入されれば、これらの残高を解放できる可能性があり、各トークンの開発チームに思わぬ利益をもたらします。

バッチ

2つ目の新しい命令は`batch`で、p-tokenプログラムとのCPI連携を効率化します。Tokenプログラムを複数回呼び出す代わりに、`batch`を使用すると、可変数のToken命令を1回の呼び出し内で実行できます。これにより、1,000ユニットの基本CPIコストは、個々の命令ごとではなく1回だけ発生します。

その結果、1つの命令内で複数のToken CPIを使用するプロトコルでは、コンピュート使用量を大幅に削減できます。これはSolana DeFi全体で一般的なパターンです。たとえば、AMMではスワップ時に2回の転送を行うことがあり、流動性プールへの入金では転送とミントの両方が必要になる場合があります。`batch`を使用することで、プログラムはこうした状況で大幅にCUを節約できます。

Lamportのアンラップ

`unwrap_lamports`命令（別のPRで最近追加されました）により、一時的なネイティブトークンアカウントを作成せず、宛先アカウントへlamportを直接転送できます。

これまでは、ラップされたSOLアカウントからlamportをアンラップするには、受取人用の関連トークンアカウント（ATA）を作成し、その後閉じる必要がありました。この更新により、ネイティブSOLアカウントからlamportを直接転送できるようになり、処理が簡素化されます。

転送命令の高速パス

mainnetでの**Tokenプログラムの使用状況を分析すると、転送命令に大きく集中しており、これらを合わせると全アクティビティのほぼ半分を占めています。**最も頻繁に使用される5つの命令は次のとおりです。

• transfer_checked（36.33%）
• transfer（13.22%）
• close_account（12.23%）
• initialize_account3（9.98%）
• initialize_immutable_owner（9.78%）

この利用パターンは、転送向けにp-tokenをさらに最適化し、CU消費量を削減できる可能性を示しています。この最適化作業の多くはTemporalのCaveyによるものです（アプローチの詳細については、彼のXライブ配信をご覧ください）。

この効率向上を実現するため、p-tokenは転送命令向けの高速パスを備えたカスタムエントリーポイントを導入し、`sync_native`と`initialize_immutable_owner`を優先するようプロセッサを更新します。これらの変更により、実際の利用パターンに即した大幅なCU効率向上を実現します。

ログ

p-tokenの導入に伴う未解決の問題の一つは、現在のログ動作を維持するかどうかです。**最新バージョンの提案では、ログの削除が推奨されています。**Solanaでは、ログがプログラムからデバッグ、モニタリング、イベントのデータを抽出するための主要な仕組みです。既存のTokenプログラムのログは最小限で、実行中の命令名を出力するだけです。たとえば、次のようになります。

Program TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA invoke [1],
Program log: Instruction: TransferChecked,
Program TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA consumed 6281 of 7738 compute units,
Program TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA success

しかし、一見わずかなこのログ行`Instruction: <name>`には、約103コンピュートユニットのコストがかかります。実際には、このオーバーヘッドが命令自体とほぼ同等のコンピュートを消費する場合があります。たとえば、単純な転送に必要な総コンピュート量の約40%をログが占めます。

コストに加えて、これらのログは常に信頼できるとは限りません。ログインジェクションによって切り詰められたり操作されたりする可能性があり、後続のパーサーを誤解させるリスクがあります。一方で、ログを完全に削除すると、現在その存在に依存している開発者やアプリケーションのワークフローが壊れる可能性があります。

ログを廃止すると、プログラムの動作を可視化するためにチームがIDLを公開する重要性が増します。たとえばAnchorでは、明示的に無効化しない限り、すべての新規プログラムでIDLをデフォルト公開することで、現在これを徹底しています。

監査

完全な後方互換性とセキュリティを確保するため、p-tokenプログラムの監査はすでに進行中です。p-tokenを導入するには、現行のTokenプログラムとまったく同じ命令とアカウントレイアウトを厳密に遵守し、その動作を正確に再現する必要があります。いかなる相違もリスクとなるため、広範なテストと独立監査を通じて対処しています。

監査企業Neodymeは同等性テストを実施しました。直近数か月のmainnetトランザクションをすべて、元のTokenプログラムとp-tokenで1回ずつ、計2回リプレイしました。その結果、出力が同一であることが確認され、同時に大幅なCU削減も実証されました。

同社の分析によると、2025年8月3日から8月11日までの期間に、p-tokenはログを有効にした場合で8.9兆CU、ログを無効にした場合で9.14兆CUのオーバーヘッドを削減できたとされています。これは、ブロックスペース総使用量のそれぞれ12.0%と12.3%に相当します。

P-tokenは現在、Zellicによる2回目の監査と、Runtime Verificationによる形式検証を受けています。

ロールアウト

p-tokenの計画的なロールアウトは、段階的なアプローチで進められます。まず監査、ファジング、形式検証を完了します。その後、p-tokenの導入とSIMD 266の正式承認について、validatorによるガバナンス投票を行います。続いてp-token機能をクラスターへデプロイし、feature gateの背後に配置します。

プログラムはまず、指定されたアカウント（ptokN…UkkZ2）へデプロイされます。epoch境界でfeature gateが有効になると、すべてのvalidatorのランタイムがUpgradable Loader v3を使用して、既存のTokenプログラム（Tokenkeg…VQ5DA）を新しい実装へ置き換えます。

別の方法として、p-tokenプログラムを新しいアドレスへデプロイし、ユーザーとアプリケーションに手動での移行を求めることもできます。しかし、多くのユーザーが切り替えをためらうか、移行に時間がかかることで、導入が妨げられ、全体的なメリットも薄れる可能性が高いため、この方法は推奨されていません。

経済的影響

p-tokenの導入は、Solana全体の容量を劇的に拡大し、各ブロックへより多くのトランザクションを格納できるようにする一連の改善の一つです。その他の注目すべきアップグレードには、ブロックスペースを1億CUへ倍増することや、アカウントあたりのCU上限を固定の1,200万からブロックの40%へ引き上げることが含まれます。

現在、1つのアカウントはブロックあたり1,200万CUに制限されています。以下のAnzaのグラフが示すとおり、各ブロックで最も競合の激しいアカウントは、頻繁にこの上限へ達しています。p-tokenだけでもアカウントがこの上限へ達しにくくなり、アクセスが集中する状態におけるボトルネックの発生頻度を減らせます。

現在、ほぼすべてのトランザクションには、validatorへブロックへの格納を促すため、優先手数料またはJito tipのいずれかが含まれています。優先度はCUあたりの手数料で決まるため、消費CUが少ないp-tokenトランザクションは、他の条件が同じであれば、同額の手数料またはtipでより高い優先度を得られるはずです。ただし、すべてのSPL tokenトランザクションがp-tokenへのアップグレードによる恩恵を受けるため、トランザクションの優先順位付けに対する全体的な影響はまだ分かりません。

まとめ

ガバナンス投票で可決されることを前提に、p-tokenの導入はSolanaの効率性とスケーラビリティを向上させる大きな一歩となります。コンピュート使用量を大幅に削減し、CPI連携を効率化することで、ネットワークで最も使用されているプログラムの基盤を強化すると同時に、ブロック全体の容量を拡大します。成功すればp-tokenは、Associated Token Account（ATA）プログラムやSystemプログラムなど、広く使用されている他のプログラムについてPinocchioで最適化したバージョンを開発する際の青写真となり、より高速で効率的なランタイムへの道を開く可能性があります。

関連リソース

• p-tokenリポジトリ - GitHub
• Pinocchioリポジトリ - GitHub
• Solana Program Library（SPL） - GitHub
• p-Token SOL節約額計算ツール - SendAI