Solanaガバナンス：包括的な分析

実践的なインサイト

• Solanaのガバナンス投票には拘束力がなく、諮問的なものであり、コミュニティの意向を示すシグナルとして機能します。完全な実装前にバリデータが立場を示せるようにすることで、開発の方向性を定め、対立を最小限に抑えられます。最終的な決定は、バリデータが実行するソフトウェアを選択する時点で行われます。提案は投票後でも変更される可能性があり、最終的にガバナンスが反映するのは強制ではなく合意です。
• SOLトークン保有者は、自身の価値観や選好に沿った投票を行うバリデータへ、ステーキングしたSOLを委任することで間接的に参加します。これは、バリデータを選出された代表者と見なせる比例代表制です。Solanaのステーカーはステークをバリデータに委任し、各バリデータの投票権は委任されたステークに基づきます。
• Solanaのガバナンス投票はSPLトークンを使用して行われます。バリデータにはアクティブステークに比例してトークンが割り当てられ、異なる投票選択肢を表す指定アドレスへ送信します。バリデータは複数の選択肢に票を自由に分割できます。提出後の票は確定し、変更できません。
• コンセンサスを破るすべてのプロトコル更新は、後方互換性のないハードフォークであるfeature gateを通じて有効化されます。意見の不一致によってハードフォークが恒久的なチェーン分岐につながる可能性があるBitcoinやEthereumとは異なり、Solanaでは特定のスロットでクラスター全体のfeature gateが有効化されます。バリデータは事前にアップグレードするため、チェーン分岐を防げます。
• Solanaの初期開発では、50%バーンを伴う優先手数料の導入をはじめ、複数の経済的変更が正式なガバナンス投票なしで実装されました。当時はガバナンスシステムがまだ成熟していなかったためです。
• 現在のガバナンス投票モデルであるバリデータ限定投票は、2023年10月の諮問投票を経て確立されました。総ステークの14.3%に相当する170以上のバリデータが参加し、そのステークの70%以上が、最も実用的かつ効率的な出発点としてバリデータ限定投票を支持しました。
• 最近のSIMD-228投票は、過去最高となる74.3%の参加率に達しました。参加者数と時価総額の両面で史上最大のブロックチェーンガバナンスイベントとなり、2億8,100万SOL（~350億ドル）と900以上のバリデータが1,000票を超える票を投じました。Coinbase、Kraken、Bybitなど大手取引所のバリデータが初めて積極的に参加し、Solanaにおける機関投資家の関与拡大が浮き彫りになりました。
• Solanaのガバナンスプロセスで繰り返し指摘される懸念は、意思決定における委任者の役割が限られていることです。現在、委任者が自身の選好を表明したり、バリデータの決定を覆したりする正式な仕組みはなく、バリデータの投票が委任者の選好と相反する場合があります。
• Solanaのガバナンス投票における定足数の役割も懸念を招いています。実際には、定足数によって、提案が必要なしきい値へ到達するのを阻止するために参加者が戦略的に投票を控えるという、逆効果のインセンティブが生じ得ます。これはSIMD-228の投票パターンで確認されました。
• Solana Foundation Delegation Programは、総ステーキングSOLの10%（4,101万SOL）を897のバリデータに委任し、これらのバリデータの投票権を増幅しています。最近のSIMD-288投票の分析では、SFDPのステークは主に提案への反対票に使用されたことが示されています。このステークが代わりにYESへ投票していれば、提案は可決されていました。SFDPから委任されたステークが棄権していた場合も提案は否決されていましたが、実際の61.39%に対して64.77%と、より僅差になっていました。
• 何がガバナンス投票の対象となるかについては、依然として不確実性があります。2025年3月には、SIMD-218（IVC）に関する投票が、ガバナンス承認は不要との合意が形成された後に取り下げられました。同様にSIMD-123は可決されたものの、明確な経済的変更ではなく、正式な投票を行う必要はなかった可能性があります。

はじめに

ガバナンスは分散化の重要な構成要素であり、プロトコルのアップグレードや経済政策から、バリデータの行動、コミュニティ基準まで、あらゆるものに影響します。適切に機能するガバナンスシステムは透明性、公平性、信頼を高めますが、不適切なガバナンスは混乱、停滞、権力の集中を招く可能性があります。

Solanaのガバナンスは、まだ発展の初期段階にあります。多くのブロックチェーンネットワークと同様に、完全に成熟し、形式化されたガバナンスフレームワークを備えてローンチしたわけではありません。コミュニティの慣行、技術的制約、得られた教訓によって形作られながら、徐々に進化してきました。Solanaのガバナンス改善は、現在も続く反復的なプロセスです。

Solanaのエコシステムは、トークン保有者、ステーカー、ユーザー、バリデータ、RPCオペレーター、アプリケーション開発者、コアプロトコルエンジニアなど、多様で重複するステークホルダーグループで構成されています。各グループは異なる視点、インセンティブ、目標を持ち込みます。これらのインセンティブは一部で一致する場合もありますが、特にリソース配分、プロトコルの制御、経済政策をめぐっては、しばしば対立します。

分散型システムにおいて、ガバナンスはコードと同じくらい社会的合意に関わるものです。ブロックチェーンはしばしば「コードは法である」と表現されますが、コミュニティの合意が求めれば、コードは変更され得るだけでなく、実際に変更されることを歴史が示しています。そのため、ガバナンスメカニズムの設計と、それを時間とともに進化させる能力は、当初の技術アーキテクチャと同じくらい重要です。

本レポートは、Solanaにおけるガバナンスの構造、進化、現状を明確にすることを目的としています。ネットワーク内で意思決定がどのように行われ、そのガバナンスが他のブロックチェーンエコシステムとどう異なるかを包括的に示します。本稿は4つの主要セクションで構成されています。

• Solanaガバナンスの構成要素 – SIMD、feature gateの有効化、正式なオンチェーン投票など、Solanaのガバナンスプロセスの中核要素を検証します。
• ガバナンス投票の分析 – これまでに行われたすべての正式なガバナンス投票について、結果、投票行動、参加指標を含めて詳しく概説します。
• 課題と提言 – Solanaの現行ガバナンスモデルが直面する主要な問題を検討し、適切な場合には実行可能な提言を示します。
• 他のネットワークとの比較 – CosmosとEthereumのエコシステムにおけるガバナンスの仕組みを確認し、Solanaの改善に役立つ可能性のある慣行を取り上げます。

本レポートは順番に読むと最も理解しやすい構成ですが、各セクションは単独でも読めるように設計されています。

Solanaガバナンスの構成要素

以下の表は、Schädler、Lustenberger、Spychiger（2023年）による『ブロックチェーンガバナンスにおける意思決定の分析』の論文を基に調整した分析フレームワークを使用し、Solanaのガバナンスシステムを概説したものです。このフレームワークは、Solanaエコシステム固有のメカニズムと力学を反映するよう調整しています。

Solanaプロトコルの変更は、その性質と影響に応じて異なる複数段階のプロセスに従います。主要な要因には、変更がコンセンサスを破るかどうか、ステークホルダーへの影響、対立や複雑さの度合いが含まれます。コンセンサスを破る変更とは、異なるソフトウェアバージョンを実行するノード間でブロックチェーンの状態に関する不一致を引き起こすプロトコル更新を指します。 

次の表は、規模が異なる変更に通常必要となる手順を示しています。「大規模な変更」とは、経済的影響を及ぼす可能性があるものを指します。

以下では、feature gateの有効化、SIMD、ガバナンス投票の詳細なプロセスを説明します。

Feature Gateの有効化

AnzaとFiredancerのコア開発チームは、syscall、ネイティブプログラム、経済的変更など、コンセンサスを破る新機能を頻繁にリリースしています。これらの機能は作成後、新しいクライアントソフトウェアのリリースに組み込まれ、feature flagの背後でデフォルトでは無効化されます。最近Core BPFプログラムへ移行したFeature Gate Programは、新機能をそれぞれアカウントとして追跡します。各feature gateに固有の秘密鍵は、そのfeature gateを担当するコアコントリビューターが所有します。十分なステークを持つバリデータが新リリースへアップグレードし、安定していると判断されると、ランタイムの機能スイッチが命令によって手動で有効化され、次のエポックの開始時にネットワーク上の全ノードで機能が稼働します。有効化の正確な順序とタイミングは、feature gateのスケジュールで追跡できます。機能の有効化はクラスターに依存せず、まずTestnet、次にDevnet、最後にMainnetで行われます。これにより、Mainnetで最終的に有効化する前に、新バージョンへの信頼性を高められます。

「version floor」とは、クラスターで現在サポートされている最小のソフトウェアバージョンです。新しいfeature gateが有効化されると、version floorはその機能が含まれたソフトウェアリリースに合わせて引き上げられます。Solanaにおける新機能の有効化は定期的な周期で行われ、通常は平日の営業時間内に該当するエポック境界で実施されます。バージョン移行中は有効化が一時停止され、ステークの95%が新しいマイナーリリース（例：バージョン2.2から2.3）へアップグレードしてから約2エポック後に再開されます。

Feature gateの有効化は後方互換性のないハードフォークであり、発効にはすべての参加者による採用が必要です。有効化されたfeature gateを認識するバージョンへバリデータがアップグレードしなければ、グローバル状態の検証を継続できず、ネットワークから分岐します。

意見の不一致によってハードフォークが恒久的なチェーン分岐につながり得るBitcoinやEthereumとは異なり、Solanaのアプローチでは特定のスロットでクラスター全体のfeature gateが有効化されます。バリデータは事前にアップグレードする必要があるため、チェーン分岐を防げます。したがって、feature gateはコンセンサスルールを変更するという意味ではハードフォークですが、競合するチェーンを生み出すことはありません。

新しいクライアントバージョンには、コードのリファクタリングや効率の最適化など、コンセンサスを破らない多くの変更も含まれます。これらにはfeature gateは必要ありません。

Solana Improvement Documents（SIMD）

Solana Improvement Document（SIMD）の提案は、Solanaのコアコンポーネントに対する重要な変更に必要な正式文書です。「重要な」変更とは、通常、ネットワークプロトコル、トランザクションの有効性、相互運用性を変更するものと定義されます。軽微なコードのリファクタリングや客観的なパフォーマンス改善など、重要でない変更には提案は不要です。提案には、機能の根拠と、実装を理解するのに十分な文書を記載する必要があります。 

SIMDの提出に許可は不要ですが、その多くはコアプロトコルの改善にフルタイムで取り組むクライアントチームの開発者が提出しています。

提案には2つの種類があります。 

• 標準提案：Solanaのコア機能（例：コンセンサス、ネットワーク、APIインターフェース）に影響するもの
• メタ提案：コードベース外のプロセスやガイドラインを扱うもの

SIMDは通常、アイデアの検証、草案作成、レビュー、承認の各段階を進みます。正式なレビューはGitHub上で公開され、提案者はAgaveとFiredancer双方のクライアントチームの関連コアコントリビューターからフィードバックを集める責任を負います。コントリビューターはセキュリティ、トレードオフ、後方互換性を考慮し、提案を承認、修正、取り下げのいずれとするか決定します。

提案者に実装の義務はありませんが、正常な完了を確実にする最善の方法として、一般には自身で実装することが推奨されます。承認された提案には、機能実装を追跡する関連issueが含まれることが多く、通常はSolanaのfeature gateメカニズムを通じた有効化が必要です。 

すべてのfeature gateの有効化にSIMDが必要なわけではありませんが、大半には、提案された変更の背景や根拠を示し、標準化された記録を残すためにSIMDが付随します。

ガバナンス投票

プロトコルを大きく変更するSIMD、特に経済パラメーターに影響するものには、ガバナンス投票が必要です。経験豊富なバリデータコミュニティのメンバーが主導するSolanaのガバナンスプロセスは、参加意欲を維持し、ガバナンス疲れを防ぐため、重要な問題のみに焦点を当てています。そのため、投票は年に数回しか行われません。  

ガバナンス投票は主に、提案された変更に対する意向を測る仕組みとして機能します。完全な実装前にバリデータが立場を示せるようにすることで、開発の方向性を定め、対立を最小限に抑えられます。幅広い合意なしに変更を実装すると、特にネットワークの3分の1超が採用に抵抗する場合、摩擦が生じる可能性があります。

投票はSPLトークンを使用して行われます。各アクティブバリデータのidentity accountには、lamports単位で測定されたアクティブステークに比例するトークンが割り当てられます。その後、バリデータは棄権を含む異なる投票選択肢を表す指定アドレスへ、これらのトークンを送信できます。バリデータは複数の選択肢に票を自由に分割できます。たとえば、80%をYES、20%をNOに割り当てることで、ステーカーの多様な選好を柔軟に反映できます。提出後の票は確定し、変更できません。

この構造では、SOLトークン保有者は、自身の価値観や選好に沿った投票を行うバリデータへ、ステーキングしたSOLを委任することで間接的に参加します。これは、バリデータを選出された代表者と見なせる比例代表制です。Solanaのステーカーはステークをバリデータに委任し、各バリデータの投票権はそのアクティブステークに基づきます。

オンチェーンガバナンスの限界

toly 🇺🇸

@toly

@garious14 There is no “governance”. It’s just a signal to check if the proposed upgrade would cause a contentious fork. It has to come from validators.

2025年3月17日 午後3:56

Solanaのガバナンスには、最終的に拘束力がなく、諮問的なものです。実際の投票は、バリデータが実行するソフトウェアのバージョンを選択する時点で行われます。ガバナンス投票はコミュニティからの幅広い支持や反対を示せますが、特定のコードの採用をバリデータに強制するものではありません。提案は投票後に変更される場合さえあり、バリデータは自身のインフラストラクチャで何を実行するかについて完全な制御権を保持します。この力学は、ガバナンスが結果の強制よりも、合意を示すことに重点を置いていることを意味します。

この文脈では、Anza、Jump、Jitoなどのコアコントリビューターと、HeliusやTritonなどのインフラストラクチャプロバイダーが、非公式ながら大きな影響力を持ちます。バリデータは、ステークを失ったりネットワークとの同期から外れたりするリスクを冒してまでこれらのグループに反対する可能性が低いため、正式な意思決定権を持つかどうかにかかわらず、これらの組織はアップグレードの結果を実質的に左右できます。

バリデータがアップグレードを拒否する極端な状況では、フォークが発生する可能性があります。Ethereum Classicの誕生につながった2016年のEthereum DAO Forkは、今なお教訓的な事例です。Solanaのガバナンスプロセスが進化する中で、シグナル投票、ソフトウェアリリース、実際のバリデータによる採用の関係を明確にすることは、透明性を確保し、チェーン分岐というテールリスクを回避するうえで重要です。

ガバナンス投票の分析

Solana初期のガバナンス：2020～2022年

Solanaの当初のガバナンスアプローチは、現在のフレームワークとは大きく異なっていました。初期のガバナンスはFeature Proposal Programを中心としており、バリデータはステーク加重されたSPLトークンを使ってプロトコル変更に投票できました。新機能のリリースが有効化可能になると、バリデータにはアクティブステークに比例した投票トークンが割り当てられました。2週間の期間中にこれらのトークンを指定アカウントへ返すことで、バリデータは提案された機能の有効化への賛成を示せました。ステークの67%というしきい値に達すると、次のエポックで変更がオンチェーン上で直接有効化されました。

Feature Proposal Programは、TestnetとMainnetの両方でバリデータによるガバナンス投票を複数回実施するために使用されました。最も注目すべきものは、現在のインフレーションスケジュールの有効化です。

初期のガバナンス投票に関するオンライン記録は限られています。元のSolana Forumsが閉鎖され、現在はWayback Machineのアーカイブ版からしかアクセスできないためです。

この仕組みにより一定のオンチェーン調整が導入されましたが、広く批判されました。バリデータには反対を表明する方法がなく、集計されるのはYES票のみで、反対や棄権を示す正式な方法はありませんでした。また、特に実装に多大なエンジニアリング作業がすでに投入された後では、変更を承認するよう社会的圧力がかかるシステムでもありました。 

さらに重要な点として、このシステムでは早期に意思を示せませんでした。つまり、複雑な機能が受け入れられるかどうか分からないまま構築される可能性があり、非効率や開発時間の浪費につながりました。

総じて、Feature Proposal ProgramはSolanaのガバナンスの歩みにおける重要な初期段階でしたが、その限界が、現在使用されているより柔軟なガバナンスメカニズムの開発に役立ちました。

この初期段階には、50%バーンを伴う優先手数料の導入など、複数の大きな経済的変更が正式なガバナンス投票なしで実装された点も注目に値します。これは、ガバナンスシステムがまだ黎明期にあったことを反映しています。

Solanaの現在のガバナンス：2023年以降

Feature Proposal Programの利用を経て、Solanaは現在のガバナンス投票システムへ進化しました。これまでに、5回の正式なガバナンス投票が行われています。

• 2023年10月の最初の諮問投票
• Shinobi SystemsのBryan IschoとZantetsuによる2024年4月のSIMD-33 Timely Vote Credits
• AnzaのTao Zhuによる2024年5月のSIMD-96 バリデータへの優先手数料全額付与
• AnzaのJustin StarryによるSIMD-123 プロトコル内でのブロック報酬分配
• Multicoin CapitalのTushar JainとVishal Kankani、AnzaのMax Resnickによる2025年3月のSIMD-228 市場ベースのエミッションメカニズム

最初の諮問投票

Solanaの現在のガバナンスフレームワークを形作るうえで重要だった初期の決定は、誰が投票プロセスに参加すべきかを定めることでした。コミュニティには3つの選択肢が提示されました。

1. バリデータ限定投票。票はステークで加重
2. バリデータとステークアカウント。委任者はバリデータの票を覆すことが可能
3. バリデータ、ステークアカウント、RPCオペレーターや開発者などその他のステークホルダー

諮問投票には170以上のバリデータが参加し、総ステークの14.3%を占めました。投票したステークのうち、70%以上がバリデータ限定投票を支持し、24%がバリデータと委任者によるモデルを支持しました。この投票には最低参加しきい値が設定されませんでした。

既存のインフラストラクチャがあり、実際にテスト済みであることから、バリデータ限定投票が最も実用的かつ効率的な出発点として支持されました。委任者やその他のステークホルダーを含む、より複雑なシステムは、初期段階のガバナンスプロセスには時期尚早で、負担となる可能性があると見なされました。コミュニティは、ガバナンスの成熟に伴い、将来の提案を通じて別の投票モデルを導入し、改善できると認識していました。

ガバナンス投票のパターン

最初の諮問投票以降、同じ3つの投票選択肢、YES、NO、棄権を用いて、さらに4回のガバナンス投票が行われました。これらの選択肢は、提案されたSIMDへの賛否を示します。投票が可決されるには、YES票とNO票の合計の少なくとも3分の2が賛成（つまりYES）である必要があります。 

SIMD-33：Timely Vote Creditsは圧倒的な支持を得て承認され、YES票は98.4%でした。この議論の余地が少ないコンセンサス変更は、バリデータが投票を遅れて提出することで得ていた利益をなくし、インセンティブの不整合を解消することで、ネットワークの動作と公平性を改善しました。

SIMD-96：バリデータへの優先手数料全額付与は、77.7%のYES票で可決されました。この経済的提案は、優先手数料の100%をバリデータへ渡すことで、サイドチャネルによるトランザクション処理を抑制することを目的としていました。インセンティブの整合には効果的でしたが、インフレーションがわずかに増加することや、SOL保有者よりバリデータを優遇しているとの見方から、多少の議論を呼びました。

SIMD-123：プロトコル内でのブロック報酬分配は、74.91%のYES票で承認されました。この提案は、バリデータがブロック報酬をステーカーへ直接分配するための、任意かつ標準化された仕組みを導入しました。複数のバリデータがすでに手動に近い方法でこれを行っていましたが、プロトコル内に組み込むことで競争圧力をめぐる議論が起こり、ブロック報酬の手数料率が「ゼロへの競争」に陥る可能性が懸念されました。

SIMD-228：市場ベースのエミッションメカニズムは、YES票が61.39%にとどまり、否決されました。この提案は、Solanaのインフレーション率をステーキング参加率に応じてより柔軟に変動させることを目的とし、現在のエミッションは高すぎるうえ、利回り需要に反応せず、ネットワークがセキュリティに対して過剰に支払っていると主張しました。

反対派は、小規模バリデータの経済的持続可能性と、ステーキング利回りに新たな不確実性が生じることへの懸念を示しました。この投票は非常に論争的となり、広範な議論を引き起こし、Solanaの長期的な経済モデルに対する見解の相違を浮き彫りにしました。

詳細な投票行動については、SIMD-96、SIMD-123、SIMD-228のオープンソース投票ダッシュボードをご覧ください。さらに、投票データを掲載したスプレッドシートはこちらです。

SIMD-228とSIMD-123には、棄権票を含むステーク参加率33%の定足数しきい値が適用されました。一方、SIMD-96やSIMD-33など以前の提案には最低参加要件がなく、総ステークのうち投票した割合にかかわらず可決できました。

参加率

投票参加率は時間の経過とともに上昇傾向を示しています。2023年10月の最初の諮問投票は参加が少なく、投票したステークは14.3%にとどまりました。その後、参加率は着実に高まり、2025年3月に行われた市場ベースのエミッションメカニズムであるSIMD-228の投票では74.3%に達しました。これまでの他の3回の投票は、51.2%から57.1%までの比較的一貫した参加率でした。

SIMD-228の投票は、参加者数と対象となった総時価総額の両面で、暗号資産史上最大のガバナンスイベントとなりました。議論当時、Solanaの時価総額は2017年半ばのブロックサイズ戦争当時のBitcoinに匹敵し、この決定の重要性を裏付けていました。350億ドル相当の合計2億8,100万SOLが投票に参加し、900以上のバリデータが1,000票を超える票を提出しました。特筆すべきは、Coinbase、Kraken、Bybitを含む大手取引所のバリデータが、Solanaのオンチェーンガバナンスへ積極的に参加した初の事例だったことです。これは、ネットワークの意思決定プロセスにおける機関投資家の存在感が高まっていることを示しています。特に米国を拠点とする組織による最近の参加増加は、現政権下でブロックチェーン規制環境がより好意的になったことにも一部起因している可能性があります。

問題点と提言

次のセクションでは、ガバナンス投票プロセスの主要な課題を検討し、必要に応じて透明性、セキュリティ、効率を改善するための提言を示します。

ステーカーの参加不足

Solanaのガバナンスプロセスで繰り返し指摘される懸念は、意思決定における委任者の役割が限られていることです。バリデータはステーク加重されたガバナンス権限を使って提案に投票しますが、委任者が自身の選好を表明したり、バリデータの決定を覆したりする正式な仕組みはありません。そのため、バリデータの投票が委任者の利益と相反し、ステーカーがガバナンスの結果へ直接影響を与える手段を持たない状況が生じ得ます。

数千人の委任者を持つバリデータが、個々の投票選好を収集することは困難であり、ステーカーの参加率も通常は低水準です。一部のバリデータは、投票前に最大規模の委任者へ意見を求め、その選好に基づいて票を分割することで、この問題に部分的に対処しています。また、既存のトークン投票システムを模したカスタムツールを試し、比例するステークに基づいてステーカーへ新しいガバナンストークンを発行しているバリデータもいます。ただし、これはプロトコル全体で標準化された機能ではなく、各バリデータ固有の解決策にとどまります。

ステーカーの参加に反対する人々は、ほとんどの委任者が技術者ではなく、ガバナンス上の決定を詳しく追うことも少なく、十分な情報に基づく意思決定に必要なブロックチェーンの仕組みやトレードオフへの深い理解を欠いていると指摘します。一方、支持者は、バリデータだけに依存すると利益相反が生じると主張します。バリデータ自身の経済的インセンティブを犠牲にする提案について、過半数のバリデータがネットワークの利益を優先して投票すると期待するのは非現実的だという考えです。

改善策としては、ガバナンスダッシュボード、意向追跡ツール、さらにはガバナンスイベントに関するウォレット通知など、バリデータと委任者の間のコミュニケーションチャネルを強化することが考えられます。本レポートの後半では、Cosmosエコシステムのアプローチを検討しながら、このトピックを再度取り上げます。

ガバナンス議論の課題

分散型エコシステムの効果的なガバナンスには、明確で有益なコミュニケーションが欠かせません。しかし、最近のSIMD-288提案では、激しい論争、個人攻撃、派閥争いによって不健全なガバナンス環境が生まれ、最終的に建設的な議論が妨げられました。Solanaの重要な提案をめぐる議論では、複数のプラットフォームで非効率や情報品質の低下が生じる場合があります。GitHubや公式Solanaフォーラムでの技術的議論は、体系的で思慮深い討論を実現していますが、DiscordやTwitterに話題が移る頃には、有意義な議論が罵り合いや人身攻撃に陥ることがあり、意思決定の全体的な質を低下させています。

さらに、ほとんどの参加者は議論期間全体を活用せず、投票直前の数日間にしか参加しません。早期の参加を促し、重要な議論が最終投票期間より十分前に行われるようにするなど、ガバナンスのタイムラインをより適切に構成すれば、こうした問題の軽減に役立つ可能性があります。

ガバナンスコールは、直接的な対話、迅速な確認、荒らしやミスリードの機会削減を可能にし、効果を発揮しました。建設的なガバナンスプロセスを維持するには、モデレーションの強化、体系的な議論の促進、対立的な応酬より事実に基づく分析を重視することが重要です。

ガバナンス提案の一括化

ガバナンス上の意思決定は、各提案を個別に投票し、それぞれの問題を固有の価値に基づいて検討できるようにすると、最も効果的になる場合が多くあります。提案を一括化する際の主な懸念は無意識の偏りです。ある問題に強い意見を持つ投票者は、無関係であっても、意図せず他の問題への立場にその意見を反映させる可能性があります。これにより、きめ細かな意思決定が行われにくくなり、本来は有益な変更の実装が妨げられる可能性があります。

もう1つのリスクは、一括化によって運用の複雑さが増し、エラーが発生しやすくなることです。SIMD-228とSIMD-123の合同投票期間中、SIMD-123向けの少数のトークンが誤ってSIMD-228の棄権アドレスへ送信された際に、この問題が確認されました。このようなエラーはまれですが、投票結果を歪め、ガバナンスプロセスへの信頼を損ないます。

一方、提案を一括化することへの反論として、複数の意思決定を少ない投票期間にまとめることで、投票疲れを軽減し、参加率の向上を促せるという点があります。参加の促進には役立つ可能性がありますが、その代償として意思決定の明確さと精度が損なわれます。さらに、一括化された提案が複雑な場合、投票者、特に普段は直前に参加する人が各要素を十分に理解し評価できる時間を確保するため、投票開始前に長期の議論とレビュー期間が必要になることがよくあります。

より効果的なアプローチは、可能な限りガバナンス提案を分離し、各問題を個別に評価することです。一括化が必要な場合は、その理由を明確に示すべきです。

投票の定足数

Solanaのガバナンス投票で定められた定足数の役割には、懸念が示されています。実際には、定足数によって、提案が必要なしきい値に到達するのを阻止するため、参加者が戦略的に投票を控えるという逆効果のインセンティブが生じ得ます。最近のSIMD-228投票では、特にNO票を投じる側にこの傾向が明確に見られました。投票期間の最初の2エポックでは、提案へ積極的に反対票を投じるより、棄権する方が有効な戦略だったためです。 

進行中の得票数が見えることは、参加に影響します。予想される結果がすでに自身の選好と一致している場合、投票しないことを選ぶバリデータもいます。定足数の操作を防ぐため、投票期間が終了するまで得票状況を非公開にすることが改善策として考えられます。

こうした課題を踏まえ、より直接的で透明性の高いガバナンス参加を促すため、定足数要件を再評価または撤廃することへの支持が高まっています。

SFDPの影響

執筆時点で、Solana Foundation Delegation Programは897のバリデータへSOLを委任しています。これはネットワーク上の全アクティブバリデータの66%に相当します。委任総額は4,101万SOLで、ステーキングされたSOL総量の10%です。プログラムとその委任戦略の全詳細については、Heliusブログによる以前のSFDPレポートをご覧ください。

現在のガバナンスモデルでは、プログラムに参加するバリデータの投票権が実質的に増幅され、Solana Foundationを代表して投票することになります。最近のSIMD-288ガバナンス投票に関する社内分析と公開ダッシュボードでは、SFDPのステークが投票結果に重要な役割を果たすことが確認されています。この投票では、SFDPのステークは主に提案へのNO票に使用されました。NOまたは棄権に投じられたSFDP管理下のステークが代わりにYESへ投票していれば、提案は可決されていました。SFDP管理下の全ステークが中立を維持して棄権していた場合も提案は否決されていましたが、可決に66.6%が必要なところ、実際の61.39%に対して64.77%と、より僅差になっていました。

投票実施基準の明確化

2025年3月のガバナンス投票には当初、SIMD-228、SIMD-123、SIMD-218：Intermediate Vote Credits（IVC）の3つの提案が含まれていました。IVCは、バリデータが子ブロックに投票した際、すべての親ブロックのクレジットを自動的に補完することで、Tower BFT（Solana版のpBFTコンセンサスアルゴリズム）の投票クレジットを最適化する、バリデータ運用のmodを不要にします。

議論期間中、SIMD-218にはガバナンスの承認は不要だという合意が広がりました。この変更は、Timely Vote Credits（TVC）のアップグレードを単に強化または修正するものであるため、実質的なプロトコル変更ではなくバグ修正だと広く見なされました。TVCはすでにガバナンス投票を通過し、コミュニティから強い支持を得ていました。Solana Tech Discordでバリデータを対象に実施された非公式投票でも、ほぼ全会一致でこの見解が支持されました。

さらにAnzaのエンジニアは、SIMD-123：プロトコル内でのブロック報酬分配は、その名称が示唆するような経済的変更ではないと指摘しました。この提案は、ブロック報酬をステーカーへ分配する任意のプロトコル内方式を導入するものです。複数のバリデータが別の方法ですでに行っていた慣行を正式化し、それまでプロトコル外で行われていた活動を標準化しました。

これにより、ガバナンスに関する重要な疑問が生じます。

• 提案に投票が必要かどうかは誰が決めるのでしょうか。現在、提案をガバナンスにかけるべきか、直接実装すべきかを判断する公式機関や体系的なプロセスはありません。
• 何が「実質的なプロトコル変更」に該当するかは、依然として曖昧です。通常のアップグレードと、正式なガバナンス介入を必要とする変更の境界は不明瞭であり、現在の定義はやや曖昧な「経済的影響」という概念に大きく依存しています。

セキュリティ上の問題

現在のガバナンス提案の投票プロセスは、コミュニティメンバーのLaineが開発、ホストするサードパーティツールsolgov-distributorに依存しています。このツールは、Jitoが当初開発したMerkleベースのトークンディストリビューターのフォークです。Laineは高く評価されているコミュニティメンバーですが、外部で管理されるツールへの依存は、信頼に関する前提とセキュリティリスクをもたらします。

• 可変性 – ツールとその文書はどちらも変更可能であり、いつでも一方的に修正できます。
• バリデータのIdentity Keypairの使用 – バリデータはCLIをビルドし、機密性が極めて高いバリデータのidentity keypairを使用してトークンを請求する必要があります。このような重要な認証情報を扱うために外部ソフトウェアへ依存するプロセスは、セキュリティリスクをもたらします。
• 個人メンテナーへの依存 – 正式なガバナンスプロセスは、正式なセキュリティ保証や独立監査なしに、外部の第三者へ重大な依存関係を持つべきではありません。

代替投票メカニズム

オンチェーンガバナンスを促進するために当初設計された、既存のSPL Feature Proposalツール（文書はこちら）があります。しかし、最近のガバナンスプロセスではこのアプローチは採用されませんでした。代わりにsolgov-distributorが使用され、この追加ツールが必要だったのかという疑問が生じています。

原則として、SPLトークンシステムはすでにガバナンス投票権を配布するネイティブな方法を提供しています。プロセスの開始者が全バリデータへSPLトークンを配布し、外部ツールに依存する代わりに、標準のspl-token CLIを使って投票できるようにすればよいのです。これにより不要な依存関係がなくなり、投票プロセスのトラストレス性が向上します。

今後のオンチェーンガバナンスツール：SIMD-133

近くMainnetで有効化される予定のSIMD-133：Get Epoch Stakesでは、プログラムがオンチェーンでステークの重みを取得できる新しいガバナンスツールが導入されます。現在、オンチェーンプログラムは現エポックのステーク分布や、各vote accountへ委任されたステーク量を把握できません。

SIMD-133により、ガバナンスプログラムは新しいsysvarを介してバリデータのステーク量をオンチェーンでスナップショットでき、オフチェーンまたは手動によるステーク検証プロセスが不要になります。これにより、既存のガバナンスフローが大幅に効率化され、手動でステークを照合する必要がなくなります。

他のネットワークとの比較

Cosmos

Cosmos SDKチェーンは委任者中心のガバナンスモデルを提供しており、ステーカーはKeplrやLeapなどの人気ウォレットから、バリデータの票を直接覆せます。つまり、バリデータは当初、全ステークの重みで投票しますが、同意しない委任者は自身のステーク分を別の投票選択肢へ再配分できます。たとえば、バリデータが総ステークの2%を保有していても、ステークの重みが1%の委任者が反対すれば、委任者は別に投票でき、バリデータの実効票を1%へ減らし、自身の1%を別の選択肢へ移せます。

このシステムでは、委任者が常に最終決定権を持つため、透明で使いやすく、効率的なガバナンスプロセスが実現します。Cosmosでは投票がウォレットやブロックエクスプローラーへ直接統合されているため、ガバナンスへの参加が非常に見えやすく、すべてのステークホルダーが簡単にアクセスできます。

ステーカーとバリデータの投票行動の違いを示す関連事例として、最大インフレーション率を10%へ引き下げることを目指したCosmos ATOM半減投票（提案848、2023年11月）があります。

• ステーカーの94.93%がYESに投票し、インフレーション上限を支持しました。
• 多くのバリデータがより高い収益源の維持を求めたため、YESに投票したバリデータは53.44%にとどまりました。

この相違は、直接的なステーカー参加の重要性を示しています。ガバナンス上の決定にバリデータだけの選好ではなく、より広範なコミュニティの意向を反映させられるためです。

Cosmosのガバナンスモジュールはプロトコルレベルに組み込まれており、ブロックチェーンの中核機能としての役割を強化しています。一部のガバナンス上の決定はオンチェーンで自動実行でき、透明性と説明責任を高めます。 

このモデルは民主的なガバナンス構造を提供しますが、積極的な参加に依存し、委任者が十分な情報に基づく決定を下す時間と知識を持っていることを前提とします。Cosmosは、Solanaが改善の可能性を見極めるために研究できる、有力な代替ガバナンスフレームワークを提供しています。

Ethereum

Ethereumのガバナンスは、ステークに基づく直接投票ではなく、社会的なオフチェーンプロセスに従います。意思決定プロセスは主に、Ethereum Improvement Proposal（EIP）、コア開発者、コミュニティの合意に依存しています。

Ethereumへの変更は、SolanaのSIMDに相当するEIPを通じて提案されます。EIPでは、Ethereumプロトコルの新機能、標準、アップグレードを説明します。Ethereum Request for Comments（ERC）は、ERC-20トークンやERC-721 NFTなど、アプリケーションレイヤー機能の標準を定義します。これらの提案は、Ethereumの研究フォーラム（Ethereum Magicians）、著名なEthereumイベント（例：Devcon、ETHDenver、ETHCC）、GitHub、コア開発者コールで公開討論されます。より広いコミュニティも、Discord、Farcaster、Xなどのプラットフォームで提案を議論し、ガバナンスに関与します。

CosmosやSolanaとは異なり、Ethereumはプロトコル上の意思決定にステークベースまたはトークン投票型のガバナンスを使用しません。EthereumがProof-of-Stakeへ移行して以来、バリデータはコンセンサスでより積極的な役割を担っていますが、正式な投票は行いません。代わりに、技術的な議論と幅広いコミュニティの支持を通じて、おおよその合意が形成されます。Ethereumのプロトコル変更は、Ethereumの実行クライアントとコンセンサスクライアント（例：Geth、Nethermind、Prysm）を保守するコア開発者に大きく依存しています。

大規模なアップグレードはハードフォークを通じて有効化され、バリデータとノードオペレーターはソフトウェアをアップグレードする必要があります。バリデータは、新しいアップグレードを採用するかどうかを選択することでネットワークルールを適用します。まれではあるものの、提案された変更に議論があり、合意を得られない場合は、DAO Fork（2016年、Ethereum Classic）や、程度は小さいもののEthereumのProof-of-Stakeへの移行（2022年、EthereumPoW）といった過去のフォークのように、チェーン分岐につながる可能性があります。

Ethereumの社会的ガバナンスモデルは、正式な投票メカニズムよりも技術的合意とコミュニティの議論を優先します。この仕組みによりEthereumは柔軟性と分散性を維持してきましたが、変更にはトークンベースの直接的なガバナンスではなく、長期にわたる議論と社会的調整が必要です。さらに、ETH保有者やステーカーが提案に投票する正式な方法はなく、ユーザーが直接及ぼせる影響は限られています。

まとめ

Solanaのガバナンスシステムは現在も発展途上にあり、現実世界での実験とコミュニティからの意見によって形作られています。本レポートでは、その中核要素であるSIMD、機能の有効化、オンチェーン投票を検証するとともに、これまでのすべての正式投票、主要な課題、CosmosやEthereumなど同種のネットワークとの比較を取り上げました。 

Solanaエコシステムは、長期の議論よりも迅速な反復と実行を重視する、エンジニアリング主導の強固な文化に根ざしています。この高速なアップグレードはSolanaを多くの同種ネットワークと差別化する一方、長期にわたるコミュニティの議論と幅広い社会的調整に依存するガバナンスモデルとの間に緊張を生み、スピードと包摂的な意思決定の両立に固有の課題をもたらします。

Solanaのガバナンスは今なお形作られている最中ですが、1つ明らかなことがあります。コミュニティの関与はかつてないほど高まっています。より多くのステークホルダーがネットワークを積極的に形作る中、Solanaには、その野心、スピード、成長するエコシステムにふさわしいガバナンスモデルを構築する絶好の機会があります。

参考資料

• Solanaの分散化を測る：事実と数値 - Heliusブログ
• Solanaガバナンス・シンクタンク
• ブロックチェーンガバナンス：未来をプログラムする - Fred Ehrsam