Solana SIMD 547: リソースベースの固定料金を全額バーンすることで、1日あたり1,500 SOL以上のバーンに貢献する可能性
Solana SIMD 547: リソースベースの固定料金を全額バーンすることで、1日あたり1,500 SOL以上のバーンに貢献する可能性
Solanaの「低料金、高スループット」という設計は、オンチェーン取引、消費者向けアプリ、リアルタイム決済の主要なプラットフォームとしての地位を確立するのに役立ってきました。しかし、ネットワークの経済活動が拡大するにつれて、より広範な暗号資産業界で繰り返し浮上する疑問があります。「Solanaが、そもそもSolanaを競争力のあるものにしたユーザーエクスペリエンスを損なうことなく、リソース集約型の利用からより多くの価値を捉えるべきではないか？」
新しいコミュニティ提案であるSIMD 547は、その可能性のある一つの答えを探求しています。それは、「コストユニット」で価格設定されたリソースベースの固定料金を導入し、その料金を全額バーンするというものです。このアイデアは、今日の比較的小さな料金バーンとネットワークの継続的な発行との間のギャップ、特にSolanaのトークノミクスに直接対処するため、注目を集めています。
以下に、この提案が示唆すること、その重要性、そして開発者、トレーダー、そして一般ユーザーにとってどのような意味を持つかについて説明します。
1) Solanaの料金バーンが今日「小さすぎる」と感じられる理由
Solanaの現在の料金モデルでは、トランザクションコストは主に以下のようになっています。
- 固定料金（署名ベース、現在署名あたり5,000ラムポート）、それに
- 優先料金（オプション、コンピュートバジェット命令を通じて設定）。 トランザクションが失敗した場合でも料金は発生します。 Solanaの料金体系ドキュメントを参照してください。 (solana.com)
トークノミクスにとって重要なのは以下の点です。
- 固定料金の50%がバーンされ、残りの50%はブロック生成バリデーターに送られます。
- 優先料金の100%はバリデーターに送られます（バーンされるものはありません）。 詳細は同じ料金体系ドキュメントにもまとめられています。 (solana.com)
SIMD 547の議論では、提案者は「現在の固定料金からのバーンは経済的にわずかである」と主張しています。高スループットの仮定の下では、固定料金メカニズムからのバーンは1日あたり約648 SOLと推定されていますが、これは指摘されている1日あたり約60,000 SOLというインフレペースと比較すると無視できるほどです。 (github.com)
このギャップが動機となっています。SOLがネットワークアクティビティを反映することを目的としているのであれば、一部のコミュニティメンバーは、プロトコルのバーンダイナミクスが、単なる署名だけでなく、実際の資源消費に合わせてよりスケールすることを望んでいます。
2) SIMD 547が提案すること（平易な言葉で）
SIMD 547の主要な提案は非常にシンプルです。
- 各トランザクションには、（コンピュートだけでなく）複数のリソース次元に基づいて推定された**「コスト」**がすでに割り当てられています。
- そのコストから計算される新しい固定料金を追加します。価格設定は以下の通りです。 要求されたコストユニットあたり0.1ラムポート、そしてその100%をバーンします。 (github.com)
簡単な復習ですが、ラムポートはSOLの最小単位です（1ラムポート = 0.000000001 SOL）。Solanaのラムポートの用語集を参照してください。 (solana.com)
「コストユニット」 対 「コンピュートユニット」
多くのユーザーは、優先料金の調整で表示されるため、コンピュートユニットに馴染みがあります。しかし、Solanaのスケジューラにおける「コスト」はより広範です。コンピュートだけでなく、書き込みロックやロードされたアカウントのデータサイズなどの項目も考慮されます。これは、料金体系ドキュメント（トランザクションスケジューリングにおける「コスト」の使用方法を参照）におけるプロトコルの料金とスケジューリングの説明に反映されています。 (solana.com)
SIMD 547のスレッドでは、著者もコストユニットにはコンピュートに加え、その他の暗黙的に要求されるリソース（ロードされたデータ、ヒープ、書き込みロックなど）が含まれることを強調しています。 (github.com)
3) 予想されるバーンへの影響：「意味のあるものだが、魔法ではない」
最も議論されている点の1つは、実際にさらにいくらのSOLがバーンされるかです。
スレッドでは、コミュニティメンバーが1日あたりの要求コンピュートユニット制限の最近の集計を共有し、現在の使用レベルでは、このメカニズムは1日あたり1,500～1,800 SOLの追加バーンになると結論付けており、ピーク時の需要時にはさらに増える可能性があります。 (github.com)
これは今日の固定料金バーンよりも大幅に大きいものですが、通常の状況下でSolanaを信頼できるデフレ資産に「転換」するには、それだけでは十分ではありません。特に、料金が高くなると需要が減少する場合です。そのトレードオフが、議論の中心となっています。
4) 誰がより多く支払うのか？メイカー対一般ユーザー（そしてなぜこの提案が重要なのか）
重要な設計目標は、リソース集約型のトランザクションにより多く課金しながらも、高頻度市場構造を壊さないことです。
SIMD 547の提案文書では、提案者は、多くの高頻度更新（しばしばメイカー／オラクルの更新に関連付けられる）は比較的少ないコストユニットを要求する傾向があるため、追加料金はそれらのワークフローで一桁台後半のパーセント増加に限定される可能性があると主張しています。 (github.com)
しかし、現在優先料金が低いかゼロのトランザクションを送信する一般ユーザーにとっては、相対的な増加は劇的に見える可能性があります。スレッドには、最小限の料金のトランザクションから新しいリソースベースのバーン料金も支払うトランザクションに移行した場合の**+639%**の増加を含む、3桁のパーセント増加を示す例が含まれています。 (github.com)
実用的なポイント
- すでに優先料金に依存している場合（例：競争力のある取引）、増加率はパーセントで言えばわずかかもしれません。
- 通常「安い」トランザクション（特に緊急性の低い状況）を送信する場合、コストへの感応度が高くなる可能性があります。
これがこの提案が物議を醸す理由です。バーンを通じてSOL保有者への価値還元を改善する一方で、多くのユーザーがSolanaと結びつけている「安価なデフォルト」UXを再形成する可能性もあります。
5) Alpenglowへの依存：タイミングが重要な理由
SIMD 547は、すぐに有効化できるようなものとしては提示されていません。
議論では、Alpenglowが有効になるまでバリデーターの投票コストが重要であることが明記されており、このメカニズムはAlpenglowの後に活性化されると想定されています。 (github.com)
Alpenglow自体は、現在のProof-of-History + TowerBFTベースのコンセンサスをAlpenglow（Votor）に置き換える、パフォーマンスと耐障害性を向上させるための主要なコンセンサス再設計提案であり、SIMD 0326として正式化されています。SIMD 0326ドキュメントを参照してください。 (github.com)
したがって、実際には、SIMD 547はより広範なロードマップの一部として理解するのが最善です。まずコンセンサスと投票メカニズムを変更し、次に今日の仮定の下では痛みを伴うであろうトークノミクスの調整を再検討するということです。
6) コミュニティが議論する可能性のある未解決の質問
支持者でさえ、通常、詳細が重要であることに同意します。スレッドとSolanaの現在の料金メカニズムに基づいて、以下のような議論が予想されます。
- 要求されたリソース vs 使用されたリソース：「要求されたコスト」に課金することはシンプルで予測可能ですが、設定が不十分なトランザクションに過剰請求する可能性があります（優先料金が要求されたCU制限に依存するのと同様）。 (solana.com)
- アプリレベルのUX：ウォレットやdAppsは、より優れた料金推定と明確な内訳（「バーン分はいくら、チップ分はいくら、基本料金はいくら」）を必要とするかもしれません。
- スパムとDoS経済学：より強力なバーンは、特定のアビューシブなパターンを抑止する可能性がありますが、正当な高複雑性ユースケース（DeFiルーティング、高度なプログラムインタラクション）を罰する可能性もあります。
- トークノミクス vs 採用：2025～2026年にかけて、業界のトレンドはより持続可能な料金市場と明確な価値捕捉へと向かっていますが、行き過ぎたネットワークはアクティビティを代替手段に押しやる可能性があります。
一次情報源にアクセスしたい読者にとっては、元のSIMD 547コミュニティスレッドが最良の出発点です。 (github.com)
7) ユーザーとビルダーが今できること
SIMD 547はまだ議論段階であり、アクティブではありませんが、準備を始める良い機会です。
dAppチーム向け
- 「念のため」と常に高い制限を要求するトランザクションを監査してください。 Solanaのドキュメントでは、料金体系ドキュメントに、優先料金が要求コンピュートユニット制限にどのように依存するかを説明しています。 (solana.com)
- ユーザーが「優先料金なし」のフローにどの程度依存しているかを追跡してください。これらのユーザーは、新しい必須バーンコンポーネントに最も影響を受けやすい層です。
トレーダーとパワーユーザー向け
- 自動化を実行している場合、バーンを丸めの誤差として扱うのではなく、**（署名固定料金 + 優先料金 + 潜在的なリソースベースバーン）**として手数料をモデル化し始めてください。
- アクションをバッチ処理している場合、より少ないが重いトランザクションが、より細かいインタラクションよりも魅力がなくなるかどうかを検討してください。
全員へ：自己保管は依然として重要
料金メカニズムやトークノミクスの議論は、オンチェーン実験（新しいルーティング、新しいMEV戦略、新しいボット）を増加させる傾向があります。その時期は、フィッシングや悪意のある承認も急増します。
SOLを長期保有している場合やSolana DeFiを頻繁に利用している場合は、OneKeyのようなハードウェアウォレットが、秘密鍵をオフラインに保ち、トランザクション承認を明示的に要求することで役立ちます。これは、トランザクションの構成（および料金の内訳）がより複雑になった場合に便利です。
結論
SIMD 547は、トークノミクスに焦点を当てた提案であり、難しい課題に対処しようとしています。それは、リソース消費に合わせてスケールする形でSOLバーンを増加させつつ、バリデーターや高頻度流動性提供を混乱させる可能性のある、乱暴な料金引き上げを回避することです。
提案通りに実装された場合、コミュニティの推定では、現在の使用レベルで1日あたり約1,500～1,800 SOLの追加バーンがもたらされるとしています。これは発行量と比較するとまだ控えめですが、もはや無視できるレベルではありません。 (github.com)
現時点では、最も重要な点は正確な数字ではなく、その方向性です。Solanaは、ネットワークリソース、料金市場、およびSOLの価値獲得をどのように整合させるかを積極的に模索しています。これは、おそらくAlpenglowのようなより大きなプロトコル変更と連携して行われるでしょう。 (github.com)
