DAOはどう守ればいいのか——Timelock・Snapshot・Vote Escrowで考える権力の設計

DAOはどう守ればいいのか——Timelock・Snapshot・Vote Escrowで考える権力の設計 エッセイ
PR

対策・哲学的考察(後半)
ガバナンス攻撃への防御策〜「分散化」と「民主化」は違うという結論まで

 

フライです。

前編では、Beanstalkの一瞬の乗っ取りと、Compoundの継続的な資本集中という、二つの異なるガバナンス攻撃を見てきたサ。

では、DAOはこうした攻撃にどう備えればいいのでしょうか。

構成:

  • なぜ投票の後に時間を置く必要があるのか(Timelock)
  • ガバナンス攻撃への4つの防御策(Timelock/Snapshot/Vote Escrow/Delegation監視)
  • 「クジラを禁止すればいいわけではない」
  • ガバナンス攻撃は「コード」と「政治」の境界にある
  • 「分散化」と「民主化」は同じではない
  • まとめ

なぜ「投票の後」に時間を置く必要があるのか

Beanstalk型の攻撃から得られる重要な教訓の一つが、
Timelock(タイムロック)だヨ。

例えば、

投票成立
↓
24時間~数日間の待機
↓
提案実行

という構造にするのサ。

そうすれば、攻撃者が一時的に議決権を握っても、
「投票した瞬間に資金が移動する」ことを防ぎやすくなるネ。

コミュニティはその待機時間の間に、

  • 異常な議決権集中
  • 不自然なトークン移動
  • 提案コード
  • 利益相反
  • 不審なdelegate
  • 資金移動先

などを確認できるサ。

Beanstalk事件後、あのプロトコルではオンチェーンガバナンスが停止され、後にコミュニティ運営の5-of-9 multisigへ移行する措置が取られたヨ。

※5-of-9 multisig:ウォレットやスマートコントラクトに合計9つの秘密鍵を割り当て、資金を移動させるにはそのうち任意の5つの署名による承認を必要とする、暗号技術を用いたセキュリティ構成サ。

完全な分散化を目指して作られたガバナンスが、攻撃後には一時的な集中管理を必要とした。

――これはなかなか皮肉な話でしょう?

ガバナンス攻撃への代表的な防御策

DAOがガバナンス攻撃に対抗するには、単純に「投票を厳しくする」だけでは足りないサ。

代表的な防御策を挙げるヨ。

Timelock

可決から実行までに時間を置く。

最も基本的な防御策サ。

Snapshotによる投票権固定

投票時点の残高ではなく、特定の過去ブロックにおける残高を基準にする方法ヨ。

これによって、投票直前にトークンを借りるだけの攻撃を難しくできるサ。

ただし、Snapshotのタイミング設計そのものが重要になってくるネ。

Vote Escrow

トークンを一定期間ロックすることで、長期的なコミットメントを持つ参加者に大きな議決権を与える方式サ。

ここでは、

「今いくら持っているか」ではなく、

「どれだけ長くコミットしているか」を政治的重みとして評価するのヨ。

Delegationの監視

DAOでは、実際の投票をdelegateに委任することがあるサ。

参加者の負担は減るが、議決権が少数のdelegateに集中する危険もあるヨ。

したがって、単純なトークン分散だけではなく、

  • 誰が誰に委任しているか
  • delegateの議決権がどれだけ集中しているか
  • delegate同士に関係性があるか
  • 特定提案で突然議決権が移動していないか

――これらを見る必要があるでしょう?

「クジラを禁止すればいい」わけではない

では、大口保有者を排除すればいいのでしょうか。

それも簡単ではないサ。

大口保有者は、DAOに多額の資本を投入している重要なステークホルダーでもあるヨ。

問題は、大口であることそのものではないネ。

問題なのは、
大口保有者の経済的利益とDAO全体の利益が一致しているかどうかサ。

例えば、Treasuryから100万ドルを自分の会社へ移す提案を、その会社の所有者自身が投票によって可決できるなら、そこには明確な利益相反があるヨ。

DAOだから利益相反が消えるわけではないサ。

むしろ、
利益相反までコードによって自動実行される可能性がある

――ここがDAOの特殊な危険性でネ。

ガバナンス攻撃は「コード」と「政治」の境界にある

DAOのセキュリティを考えるとき、
「スマートコントラクトにバグがないか」だけを調べても十分ではないヨ。

見るべきは、

技術

  • スマートコントラクト
  • 権限管理
  • Timelock
  • Snapshot
  • Upgradeability

経済

  • トークン流動性
  • 議決権集中
  • フラッシュローン
  • インセンティブ
  • Treasury規模

社会

  • delegate
  • コミュニティ
  • 投票参加率
  • 情報格差
  • 利益相反

そして

政治

  • 誰が提案を作れるのか
  • 誰が議決権を持つのか
  • 誰が実行できるのか
  • 少数派を守る仕組みがあるのか

サ。

DAOは「会社ではない」と言われるヨ。

しかし、ガバナンスが存在する以上、
そこには必ず権力関係があるサ。

ブロックチェーンは、その権力関係を消したわけではないネ。

それを、

トークン・スマートコントラクト・投票アルゴリズム

という新しい形式に変換しただけなのヨ。

「分散化」と「民主化」は同じではない

DAO研究で特に注意したいのが、Decentralization(分散化)Democracy(民主化)は同じではない、という点サ。

ノードが分散していても、トークンが少数に集中していれば、ガバナンスは集中するヨ。

参加者が世界中に存在していても、実際に投票しているのが数人の大口delegateなら、意思決定は集中するネ。

スマートコントラクトが誰でも利用できても、Treasuryを動かせる議決権が少数に集中していれば、経済的権力は分散してないサ。

つまり、技術的分散化 ≠ 政治的分散化なのヨ。

まとめ――DAOの最大の脆弱性は「権力そのもの」かもしれない

Beanstalkの2022年事件は、DAOガバナンス研究に大きな教訓を残しました。

フラッシュローンによって巨大な資本を一時的に調達できる環境では、

資本 → トークン → 議決権 → 政治的権力

という変換が、極端に高速化することを示したサ。

そしてCompoundの2024年の事例は、別の問題を示したヨ。

フラッシュローンがなくても、大口保有者が時間をかけて議決権を蓄積すれば、DAOの意思決定を大きく左右できるということサ。

だからこそ、DAOガバナンスの安全性を考えるとき、問うべきは「誰がコードを書いたか」だけではないネ。

誰が投票できるのか。
誰が議決権を買えるのか。
その議決権はどれだけ長く保持されるのか。
誰が提案を実行できるのか。
そして、少数派にはどのような防御手段があるのか。

――これらサ。

DAOは「管理者のいない組織」ではないヨ。

より正確には、管理者をコードとトークン保有者の集合に置き換えた組織サ。

だからこそ、そのガバナンスを守るには、コードのセキュリティだけではなく、権力の設計そのものを監査する必要があるのでしょう?

フラッシュローンによる一瞬の乗っ取りも、
大口保有者による長期的な議決権集中も、
票の買収も、

結局は一つの問いへ戻ってくるヨ。

「誰が、どのような条件で、DAOの意思を『DAOの意思』として定義できるのか。」

DAOガバナンスの本当のセキュリティ問題は、そこにあるサ。

プロフェッショナル人材のための案件マッチング

フリーコンサルエージェント
企業とプロフェッショナルをつなぐマッチングサービス

New Ace(ニューエース)

PR:VANES株式会社

概要: 特設ページ

 

最後まで読んでくださいまして、ありがとうございます。

 

コメント