プロトコルDAO（pDAO）
Rocket PoolのプロトコルDAO（pDAO）は、プロトコルの方向性を形成する責任を持ち、RPLガバナンスによって運営されています。そのメンバーと投票権は、大小問わずすべてのノードオペレーターで構成され、すべてがプロトコルに直接参加しています。pDAOは、rETH保有者、ノードオペレーター、RPL保有者を含むRocket Poolコミュニティ全体に奉仕します。pDAOはRocket Poolプロトコルの安全性とEthereumネットワークの健全性を優先します。pDAOが誰で何であるかの明確な定義については、pDAO憲章をご覧ください。
Houstonにおける新しいpDAO機能
pDAO責任のオンチェーン実行
Houstonアップグレードは、pDAOガバナンスシステムの実行プロセスのオンチェーン代替を導入します。これは、任意のノードオペレーターが提案を提起し、「pDAOプロトコルパラメータ」を調整し、財務資金を支出する提案に投票できるようにする楽観的詐欺証明システムを使用します。pDAO制御可能なパラメータの包括的なリストを確認するには、こちらをクリックしてください。 Houston以前は、コアチームがコミュニティガバナンスプロセスの命令でpDAOの義務を実行する責任を負っていました。たとえば、チームはガバナンス投票された支払いスケジュールに従って毎月のIMCとGMCの支払いを実行します。この権限はチームに一時的に存在し、これらの責任を引き継ぐ新しい権力構造が設定されるまでの計画でした。Houstonはチームへのこの依存を取り除き、プロトコルをより分散化しトラストレスにします。
セキュリティカウンシル
Houstonアップグレードには、プロトコルに関する潜在的な問題が発生した場合に迅速に対応するための新しいセキュリティカウンシルも含まれています。これらのメンバーはpDAOによって選出され、遅延なく変更を提案し実行する能力を持っています。pDAOはセキュリティカウンシルからメンバーを選出および削除する権限を持っています。これは重大な役割であり、pDAOは厳格な参加要件と古くなったメンバーを排除するプロセスを開発する必要があります。pDAOガーディアンは、Houstonの開始時にセキュリティカウンシルの唯一のメンバーとなります。
定期的な財務支出
RPLには5%のインフレ率があります。このインフレの22%は、RPIP-25で定義されているようにpDAOに向けられます。pDAOはこれらの資金をさまざまな目的に使用できます。たとえば、流動性プロバイダー（LP）ボーナスなどのインセンティブ、サードパーティの改善とプロジェクトのための助成金と報奨金、Rocket Poolプロトコルの開発への資金提供などです。Houstonアップグレードは、報酬期間ごとに指定された受益者に対して行われる定期的な財務支払いを可能にする新機能も導入します。
プロトコルDAO（pDAO）提案
ゼロでない投票権を持つ任意のノードは、いつでもpDAO提案を提起または参加できます。提案は次のタイプのいずれかになります：
- pDAO設定の変更
- 一回限りの財務支出
- 繰り返し財務支出（管理委員会）
- セキュリティカウンシルのメンバーシップ
より詳細な説明と根拠については、提案タイプを参照してください。pDAO提案は、プロトコルレベルで変更を実行するために存在するオンチェーンエンティティであることを理解することが重要です。
pDAO提案のライフサイクル
提案は、オンチェーンに至る前にガバナンスプロセスによって予測されるべきです。これは4つの期間で構成され、すべてがpDAO制御可能なパラメータです：
- 投票遅延期間：
proposal.vote.delay.time - 投票フェーズ1：
proposal.vote.phase1.time - 投票フェーズ2：
proposal.vote.phase2.time - 実行：
proposal.execute.time
投票遅延期間
提案の結果を決定するために、プロトコルは必要な定足数を知る必要があります。提案者はこの値をオフチェーンで計算し、提案と一緒に提出します。この値は楽観的に受け入れられますが、詐欺の場合、検証者はチャレンジ/レスポンスプロセスを実行して値が正しくないことを証明できます。無効な提案は破棄されます。
提案者とチャレンジャーがRPLをロックする必要がある理由がいくつかあります。
proposal.bondは有効な提案を奨励し、スパムを抑制します。proposal.challenge.bondは無効/悪意のある提案の削除を奨励します。
チャレンジャーは、不正であると主張しているMerkle-sumツリーへのインデックスを提供します。任意のノードオペレーターは不正な提案への挑戦に参加できます（そうすることで報酬を得ることができます）。参加を希望する場合は、pDAOチャレンジプロセスについて自由に読んでください。投票遅延期間の終わりまでにチャレンジで敗北しなかった提案は投票段階に入ります。
proposal.vote.delay.timeが期限切れになると、提案はもはや挑戦または敗北できなくなります。
投票期間1
投票期間中、ノードオペレーターと委任者は4つのオプションのいずれかで投票を行うことができます：
彼らの投票権は、選択したオプションに含まれます。
これは次のコマンドを使用して実行できます：
拒否権定足数（proposal.veto.quorumパラメータで定義）が満たされると、提案は直ちに敗北し、提案者は担保を失います。これは、スパム、低品質の提案、またはオフチェーンプロセスを最初に経ていない提案を思いとどまらせるためです。smartnodeコマンドrocketpool pdao proposals finalizeは、提案者のロックされたRPL担保を燃やすことによって拒否された提案を最終化するために使用されます。
期間1の期間はproposal.vote.phase1.timeパラメータによって決定されます。提案はproposal.quorumが達成されたかどうかにかかわらず、フェーズ2に移行します。
投票期間2
委任者は投票期間2中に投票できますが、彼らの投票はローカル投票権のみの価値があります。期間1で投票しなかった投票者は、期間2中に投票を行うことができます。自分の委任者の選択に同意しないノードオペレーターは、委任者の投票を覆す機会があります。
投票を覆すプロセスは非常に簡単で、投票期間2中にrocketpool pdao proposals voteを呼び出し、プロンプトに従うだけです。委任者の投票権は委任者の投票権によって覆されます。
提案の結果は投票期間2が終了したときに結論されます。結果が決定され（実行される）ためには、proposal.vote.phase2.timeの終わりまでにproposal.quorumの総投票権に達する必要があります。定足数が満たされコンセンサスに達した場合、提案は投票期間を通過し、成功としてマークされます。
proposal.quorumが満たされない場合、さらなるアクションは取られません。定足数が満たされない場合、提案は結論され最終的であると見なされます。
実行
両方の投票期間が経過し提案が成功すると、提案は実行され、変更（ペイロードによって定義される）がRocket Poolプロトコルに適用されます。提案を実行するには、次のコマンドを使用します：
実行する提案を選択するよう求められ、このステップの後に提案がプロトコルに適用されます！
提案が投票期間を通過した後、提案者はチャレンジによって敗北したか拒否されたのでない限り、ロックされたRPL担保を請求できます。
提案を実行できるウィンドウproposal.execute.timeがあります。このタイマーが終了に達すると、提案は期限切れになります。
以上です！上記で言及されたすべての変数はpDAO制御可能なパラメータであることに留意してください。pDAOがオンチェーン提案を使用して変更する権限を持つすべてのパラメータの包括的なリストについては、こちらをクリックしてください。
チャレンジプロセス
完全なネットワーク投票権ツリーは、ガス制限のためオフチェーンに保存されます。ユーザーが新しい提案を提出するとき、彼らは目標ブロック番号でネットワーク投票ツリーを構築する責任があります。このツリーはオフチェーンで生成されますが、オンチェーンで提出されるMerkleルートを介して検証可能です。プロトコルは、提案者が提出した詳細をチェックする検証者に依存しています。
任意のノードは、提案の正確性の追跡と検証に参加できます。この責任を選択するには、コマンドrocketpool service configを使用し、Smartnode and TX Fee Settingsメニューに移動し、Enable PDAO Proposal Checkerのチェックボックスをオンにします。
この設定が有効になると、ノードは新しい提案をチェックし、その正確性を検証し、無効な提案に対するチャレンジを提出します。唯一の前提条件は、RPLロックが有効になっていることです。
このチェックは、他のいくつかのノード関連の義務と合わせて5分ごとに実行されます。不正な提案に挑戦する例を見ていきます。smartnodeコマンドrocketpool service logs nodeを使用して進行状況を監視できます：
ノードが不正な提案を捕捉し、それに挑戦するプロセスを開始したことがわかります。ブロック1283202は提案177が提起されたブロックであり、この提案の投票権はブロック1283202で計算されます。これらの投票情報スナップショットがどのようなものかを見ることに興味がある場合は、このディレクトリで見つけることができます：~/.rocketpool/data/voting
提案者が不正な投票情報を提出したことが捕捉されたため、ノードは提案177のインデックス5で契約呼び出しFunction: createChallengeを行い、提案者がチャレンジに応答するのを待ちます。
提案者の投票情報が不正であるため、チャレンジに時間内に応答できません（proposal.challenge.periodによって決定）。この時点で提案は敗北したと見なされます。提案が敗北すると、ノードは提案177のインデックス5で契約呼び出しdefeatProposalを自動的に行い、提案を終了します。
提案の敗北に参加したチャレンジャーは、不正であることが証明されたインデックスを提出した場合、提案者の担保の比例配分を受け取ります。他のすべてのチャレンジャーは担保のみを返却されます。
提案が敗北したので、ノード（チャレンジャー）は元のRPL担保と、不正な提案を敗北させたことに対する報酬として提案者のRPL担保を請求できます。
pDAO提案とチャレンジシステムの詳細を掘り下げることに興味がある場合は、技術仕様をご覧ください。低レベルの詳細に入る例を研究することに興味がある場合は、このチャレンジプロセスのセクションに自由にスキップしてください。