オンチェーンガバナンス：テックスタック解説

ガバナンスは政治プロセスのように語られることが多いですが、その背後にあるメカニズムは純粋なソフトウェアエンジニアリングです：スマートコントラクト、トークン会計、システムの変更者と変更方法を決定するコンセンサスルール。DAOやプロトコルアップグレード経路を評価する場合、ミッションステートメントを読むより技術スタックを理解する方がはるかに重要です。

コアコンポーネント

ほとんどのオンチェーンガバナンスシステムは小さな部品のセットから構築されています：

• 投票コントラクト — 提案を追跡し、投票をカウントし、定足数閾値を強制する
• トークンまたはレピュテーション加重 — 特定のアドレスの投票がどの程度カウントされるかを決定する（トークン加重、二次投票、または委任）
• タイムロックコントラクト — 承認された提案の実行を遅延させる。通常は24～72時間なので、ユーザーが変更の前に対応できる
• 実行モジュール — 投票が成立した後、影響を受けるコントラクトを実際に呼び出すコードパス

CompoundのGovernor BravoとOpenZeppelinのGovernorコントラクトは、ほとんどの新しいプロジェクトがフォークまたは拡張するリファレンス実装です。パターンを理解するために1つのコードベースを読むなら、OpenZeppelinのGovernor.solを読んでください。よくコメントされており、提案のライフサイクル全体を示しています：提案、投票、キュー、実行。

提案がシステムを通じてどのように進行するか

提案は単なるフォーラム投稿ではなく、非公式に投票されます。オンチェーンでは、calldata：ターゲットコントラクトアドレス、関数セレクタ、エンコードされたパラメーターです。誰かがガバナンス提案を提出するとき、投票が成立した場合に実行される正確なトランザクションを提出しています。

フローは一般的に次のようになります：

1. 提案者がcalldataと説明を提出します。通常はスパムを防ぐために最小トークン残高が必要です
2. 投票遅延（通常は1ブロックから数日）が、投票が開始される前にホルダーが検討する時間を与えます
3. 投票期間が実行されます（Compoundはデフォルトでおよそ3日間を使用しますが、多くのフォークはより長いウィンドウを構成します）
4. 定足数と承認閾値が満たされた場合、提案はタイムロックにキューされます
5. タイムロック遅延が終了した後、誰もが実行を呼び出してトランザクションを実行できます

投票終了と実行の間のギャップは、セキュリティのバックストップです。これはコミュニティが悪質またはバグのある提案に気付き、極端な場合には緊急対応をコーディネートできるウィンドウです。プロトコルが緊急ガーディアンロールまたはマルチシグオーバーライドを持っていると仮定した場合です。多くのプロトコルは初期段階のガバナンスの間にこれを持っています。

加重ロジックが複雑になるところ

シンプルなトークン加重投票には既知の問題があります：最もトークンを保有している者が結果を制御し、投票者参加率は通常低くなります。少数のガバナンスフォーラムは、定期的な提案の循環供給の1桁パーセンテージの参加率を報告しています。

プロジェクトはいくつかの対策を試しています：

• 委任 — トークンホルダーがトークンを転送せずに投票力を委任者に割り当てます。これはCompoundとUniswapが代表投票をどのように処理するかです
• 二次投票 — 追加投票のコストが二次的に増加します。クジラの支配を減らすことを意図していますが、シビル耐性（1人が多くのアドレスを作成する）は未解決の問題です
• 信念投票 — 一部のGitcoin関連ツール由来で、投票力は長くトークンがある立場にコミットされたままになるほど蓄積され、スナップショット投票より継続的な好みを支持します

これらのどれも、トークン投票の低参加率とプルトクラシーに傾いたダイナミクスを完全には解決しません。これらは修緩和であり、修正ではなく、そうでなければ主張する用語解説エントリはテクノロジーを過度に販売しています。

オフチェーンシグナル対オンチェーン実行

「ガバナンス」と呼ばれるものの多くは