これは、 デュアルガバナンス18に関する最初のスレッドの続きです。 リンク先のスレッドには重要な文脈が含まれていますので、時間があれば読んでみてください。

この投稿5で最後のメカニズム設計バージョンが提案されて以来、DGに取り組んでいるプロトコルコントリビューターは、受け取ったフィードバックを組み込み、メカニズムをより単純で、より脆弱でなく、より効率的にするために、いくつかの反復を行いました。

更新されたバージョンを提示する前に、私たちが解決しようとしている問題の概要を説明し、提案されている解決策につながった推論の連鎖を簡単にたどりましょう。

問題を

現在、Lidoプロトコルコードとそのパラメータは、LDOトークン投票を介してLido DAOによって制御されています。 プロトコルは、ステーキング報酬から5%の手数料を受け取り、それをDAOトレジャリーに振り向けます(さらに5%はプロトコルに参加しているノードオペレーターに分配されます)。

LDO保有者は、LDOトークンの価格に反映されるため、一般的にプロトコルの健全性を維持することに動機付けられるべきですが、必ずしもLDO保有者がプロトコルユーザーを効率的に代表していることを意味するものではありません。 例えば、LDO保有者が共同でプロトコル手数料の値上げを決定したとします:これはLDO保有者の当面の幸福にプラスの影響を与えるかもしれませんが、プロトコルユーザーの少なくとも一部の利益には明らかに反します。

これは、DAO (エージェント) とプロトコル ユーザー (プリンシパル) の間のプリンシパル エージェント問題 (PAP) として一般化できます。 問題は、LDO保有者がユーザーとまったく同じインセンティブを持っていないためです。

さらに、ヴィタリックが「 Moving beyond coin voting 9 」というエッセイで強調しているように、PAPは、プロトコルの収益に対する経済的利益をガバナンスの力から切り離すことができるという事実によって悪化しています。プロトコル ユーザー。

PAPの存在は大きくありませんが、ユーザーが現在のエージェントが十分に自分を代表していないことに気付いた場合、いつでもプロトコルを離れて、自分の興味により適した別のエージェントを選択したり、ソロステーキングでエージェントを完全に削除したりすることもできます。

これは、一般に足投票として知られている非常に重要なメカニズムです。 理論的には、DAOとの間のインセンティブの不整合やDAOへの攻撃による悪影響からユーザーを保護する必要があります。 しかし、実際には、イーサリアムのリキッドステーキングの特定のケースでは、多くの要因が作用しているため、足投票の効率は制限されています。

最初の要因は、イーサリアムPoSがどのように機能するかの詳細です。 バリデーターからETHのステークを解除するには、バリデーターが完全に終了し、すべてのイーサリアムバリデーターの出口がスループットが制限された単一のキューで処理されるまで待つ必要があります。 つまり、プロトコルを離れるのに必要な時間は、外部のプロトコル外の要因によって異なり、桁違いに変化する可能性があります。 これは、DAOの決定に静的なタイムロックを課すことは、DAOがユーザーの利益にならない変更を適用する前に、ユーザーがプロトコルを離れるのに十分な時間があることを保証できないことを意味します。

2つ目の要因は、ユーザーのかなりの部分が、ステーキングした資金を他の形態の経済活動に再配分したいという理由でリキッドステーキングを選択し、その結果、リキッドステーキングトークン(LST)がDeFiで広く使用されていることです。 貸出市場)。 これにより、ユーザーが事前に定義された時間枠内にプロトコルを離れるのを妨げる可能性のある外部依存関係が 1 つ追加されます。

第3の要因は、受動的多数派と能動的教育を受けた少数派のユーザー間の情報の非対称性に起因しており、テールリスクを含む特定のガバナンス決定に関連するすべてのリスクを正しく評価するには、ほとんどのユーザーが持っていない知識が必要です。 DAOの決定がもたらす潜在的な悪影響をソーシャルレイヤーで伝えるには、さらに時間がかかり、意思決定が実行される前に受動的な多数派がプロトコルを離れる可能性が低くなります。

Lido DAOは、情報の非対称性を減らすために多くのガバナンスプロトコル(GOOSEフレームワーク、Node Operators Sub-Governance Group、LIPフレームワーク、メインネットコード変更の監査回数を最小限に抑えるためのコミットメントなど)を確立していますが、それらはすべて現在のLDO保有者間のソーシャルレイヤー契約であるため、DAOに対する外部からの攻撃から保護することはできません。

解決に向けて

この問題の最終的な解決策は、ガバナンスの最小化と、プロトコルコードとパラメータの最終的な骨化です。 何も管理されていない場合、ガバナンスのリスクはありません。

ガバナンスの範囲を徐々に最小化することは、プロトコルのコントリビューターが今後数年間で必要だと考えていることです。 ただし、イーサリアムの仕様が骨抜きになるまでは、コードのアップグレード可能性はある程度までしか減らすことができません(例: EIP-7002 5、 EIP-7251 6 を参照)。さらに、不変コードはバイトコードレベルで正式に検証され、コンパイラのバグによって修正不可能な脆弱性が発生する可能性を排除する必要があります。

また、プロトコルの代替性レイヤーは、リスク/リターン評価エンジンとして機能し、結果として得られるバリデータセットの利回りとリスクのバランスをとる方法で、異なるバリデータサブセット間でETHを分配します。 ここでのリスクには、バリデーターセットがイーサリアムネットワークにもたらすテールリスクが含まれます。 検閲可能性と相関するスラッシングリスク。 必要な情報をオンチェーンにもたらすトラストレスなオラクルガジェットの助けを借りて、これらのリスクをプロトコルで推定できるかどうかについては、現在進行中の研究が行われていますが(最新のイテレーションについては、 このレポート6 を参照)、それは長期的な取り組みであり、望ましい結果を実際にどのように達成できるかはまだ明らかではありません。 プロトコルにこのようなトラストレスなメカニズムが実装されるまでは、代替可能性レイヤーで何らかのガバナンスが必要です。

もう1つの潜在的な研究分野は、stETH保有者と統合のために、新しいコードとパラメータセットのバージョンに明示的なオプトインを導入する方法を模索することです。 LSTの代替可能性と、その結果生じる流動性の断片化を損なうことなく実現できるかどうかはまだ明らかではなく、流動性がユーザーをLSTに駆り立てる主な要因の1つであることを考えると、他の分散型および中央集権型のリキッドステーキングプロバイダーに対するプロトコルの競争力を破壊することになります。 とはいえ、興味深い研究の方向性です。

プロトコルが少なくとも中期的には何らかのガバナンスで存続しなければならないことがわかったので、<a href="https://notes.ethereum.org/@mikeneuder/magnitude-and-direction"> このガバナンスが生み出すリスク 1.

デュアルガバナンス

第1節で強調したように、一般的な問題は、1)PAPの存在、2)足踏み投票の効率の限界に分解できる。 ですから、理想的には、DAOとプロトコルユーザーの間の連携と、足踏み投票の効率の両方を向上させるメカニズムを導入したいと考えています。

そこで、提案されたデュアルガバナンス設計にたどり着きます。 これは、次の改善を目的としています。

1. ステーカーに、DAOとの意見の相違と、DAOがインセンティブの対立の解決に協力しない場合はプロトコルを離れるというコミットメントを信頼できる方法で示す方法を提供します。
2. ステーカーとDAOの間のネゴシエーションデバイスを提供します。
3. DAOの決定に、アクティブな少数のステーカーによってトリガーされ、より多くのステーカーが参加するにつれて延長される、拡張された動的タイムロックを導入します。
4. ステーカーが新規および保留中のDAOの決定を受けることなくプロトコルを終了できるようにすることで、足の投票効率を向上させます。

提案されたメカニズム設計の概要と、ガバナンスリスクの最小化に関する将来の研究のためのいくつかのアイデアは、このノートに記載されています:<a href="https://hackmd.io/@skozin/r17mlW2la"">https://hackmd.io/@skozin/r17mlW2la 37.

なお、プロトコルユーザーのカテゴリーはステーカーだけではありません。ノード演算子もあります。 将来の研究の方向性として考えられるのは、ノードオペレーターによる足投票の効率を向上させる方法を探すことです。 ステーカーとノードオペレーターのサブセットが、バリデーターの引き出し認証情報を新しいコントラクト(現在コンセンサスレイヤーではサポートされていません)に再ポイントすることで、プロトコルとDAOフォークを調整できるようにします。

今後の研究のもう一つの方向性は、 非トークンとハイブリッドのガバナンスを模索することです 2.

次のステップ

ここから、設計が確定する前にいくつかのことを行う必要があり、その結果、DAOの投票と関連するアーキテクチャ決定記録(ADR)ドキュメントのために提出される、より正式なLido Improvement Proposal(LIP)が作成されます。

1. シナリオと攻撃のモデリングによる提案メカニズムの堅牢性の評価。
2. コードのプロトタイピングによるメカニズムの実用性の評価。
3. コミュニティからのフィードバックを収集する。

このスレッドは、プロトコルのコントリビューターが 1 と 2 に取り組んでいる間に 3 を達成することを目的としています (どちらも現在進行中です) ので、フィードバックは大歓迎です!

デュアルガバナンスは(私の意見では)プロトコルのガバナンスリスクを軽減するための重要なステップですが、決して最終ステップではないことを強調することが重要です。 さらなる改善のためのアイデアのいくつかは、上記のリンク先のメカニズム設計文書に記載されていますので、このフォーラムにトピックを投稿して、関心のあるすべての人に、それらやその他の潜在的な改善点について議論することを勧めます。

免責事項：

1. この記事は[lido]からの転載です。 すべての著作権は原著作者[skozin]に帰属します。 この転載に異議がある場合は、 Gate Learn チームに連絡していただければ、迅速に対応いたします。
2. 免責事項:この記事で表明された見解や意見は、著者のものであり、投資アドバイスを構成するものではありません。
3. 記事の他言語への翻訳は、Gate Learnチームによって行われます。 特に明記されていない限り、翻訳された記事を複製、配布、盗用することは禁止されています。