ガバナンス攻撃とは何ですか？一般的に理解されるハッキング攻撃とどう違いますか？
ガバナンス攻撃とは、攻撃者が分散型自律組織（DAO）の投票メカニズム自体を攻撃ツールとして利用することを指す。十分な量のガバナンストークンを取得した後、表面上は合法的だが実質的にはプロトコルに有害な提案を提出し可決させる——例えばプロトコルの金庫の資金を攻撃者が管理するアドレスに移転する、あるいは核心的なパラメータを変更して攻撃者が通常のセキュリティチェックを回避できるようにするなどだ。一連のプロセスは完全にプロトコルが設計したガバナンスプロセスに従って進行するため、技術的な観点から見ると、これは何らかのセキュリティ脆弱性を「破った」ものではなく、ガバナンスメカニズム自体を「合法的に」悪用したものである。
一般的に理解されるハッキング攻撃との最大の違いは「攻撃経路」にある：ほとんどのハッキング攻撃はスマートコントラクトのコードにある技術的な欠陥（以前の記事で紹介したリエントランシー攻撃やオラクル操作など）を悪用し、本質的にはシステムのセキュリティメカニズムを回避または欺くものである。ガバナンス攻撃はこれに対して、いかなる技術的な防御線も回避する必要がなく、攻撃者はプロトコル自身が設計した投票プロセスを通じて堂々と目的を達成する。ある意味で「ルール自体の欠陥を使ってルールを攻撃する」のであり、コードの欠陥を攻撃するのではない。これがガバナンス攻撃が伝統的なコード監査の方法では特に防ぎにくいリスクタイプとしてしばしば考えられる理由でもある。
ガバナンス攻撃はなぜ発生するのですか？なぜフラッシュローンはこの種の攻撃を特に実行しやすくするのですか？
ほとんどのDAOガバナンス設計の本来の想定は、ガバナンストークンの保有分布が比較的分散しており、単一の参加者が短時間で投票結果を左右できる量を取得することは難しいというものだった。この前提はプロトコルのローンチ初期、トークンの分布が確かに比較的分散していた時期にはおおむね成立していた。しかしこの設計には十分に考慮されていなかった隠れた前提がある：ガバナンストークン自体が公開市場で借入に利用できる十分な流動性を持っている場合、攻撃者は理論上これらのトークンを長期間実際に「保有」する必要はなく、投票のその瞬間に管理権を得ればよいだけだ。
フラッシュローンの登場は、この脆弱性を理論的リスクから実際に実行可能な攻撃手法へと変えた：攻撃者は同一のトランザクション内で、フラッシュローンを通じて巨額のガバナンストークンを借り入れ、これらのトークンで悪意ある提案に投票して可決させ、提案がもたらす利益を実行し（金庫資金の移転など）、その後借りたトークンを返済できる。この一連のプロセスは攻撃者が長期的な資金を準備する必要も、トークン価格の変動リスクを負う必要もない。これがほとんどのプロトコルが類似の攻撃事件を経験した後、自らのガバナンスメカニズムの設計を見直し始めた理由でもある。例えば投票前のトークンロック期間の要件を追加する（これはまさに当サイトで紹介したveTokenモデルである）ことで、瞬間的な借入による投票権取得の可能性を根本から排除する。
ガバナンス攻撃は具体的にどう実行されますか？完全な攻撃の一連の流れはどのようなものですか？
典型的なフラッシュローン型ガバナンス攻撃の流れにはいくつかの段階がある：
ここに特に注目すべき重要な要素がある：もしプロトコルが提案の可決から実際の実行までの間に強制的な時間遅延（「タイムロック」と呼ばれる）を設けていれば、これはこの瞬間的に完了する攻撃パターンを効果的に阻止できる。攻撃者は借りたトークンを1つのトランザクションを超えて留めておくことができないからだ。タイムロックの存在はコミュニティに十分な反応時間を与え、提案が本当に実行される前に異常を発見し対応策を講じられるようにする。
ガバナンス攻撃は一般ユーザーにとって実際どのような影響がありますか？あるDAOが被害に遭いやすいかをどう評価すればよいですか？
ある協議のガバナンストークンを保有している、あるいは資金をそのプロトコルに預けているユーザーにとって、ガバナンス攻撃が一度成功すると、直接的な結果はプロトコルの金庫が空にされる、重要なセキュリティパラメータが悪意を持って変更され他の攻撃が相次いで起こることになるかもしれない。この種の損失はしばしば即座かつ不可逆的である。投票と実行のプロセスは完全にプロトコル自身が設計したルールに従っており、中央集権的な機関が事後にこの投票を無効と宣言し強制的に取り消すことはできないからだ。
あるDAOが被害に遭いやすいかを評価するいくつかの具体的な指標：ガバナンストークン自体がオンチェーンでフラッシュローンによる借入に利用できる大量の流動性を持っているか（流動性が深いほど、瞬間的に巨額の投票権が借り出されるリスクが高い）；提案の可決から実際の実行までの間にタイムロックが設定されているか（タイムロックがないか遅延時間が短すぎる場合、コミュニティが異常な投票に対応する十分な反応時間を欠くことを意味する）；投票が最低参加しきい値（定足数）を要求しているか、もし日常の投票参加率がもともと低ければ、攻撃者が取得する必要のある投票権のしきい値も相対的に低くなり、少量の突発的な資金に左右されやすくなる；そしてプロトコルが過去に類似の攻撃を試みられたことがあるか（未遂であっても）——この種の過去の記録は、プロトコルのガバナンスメカニズムが実際にどれだけ攻撃に耐性があるかについて具体的な参考を提供する。あるプロトコルが信頼できるかを確認する際、これらの具体的なガバナンスメカニズムの設計の詳細は、単に「これはDAOか」を見るよりもしばしば参考価値が高い。
2022年4月、農業プロトコルのBeanstalkは著名なフラッシュローン型ガバナンス攻撃を受けた：攻撃者はフラッシュローンを通じて巨額の資金を借り入れ、このプロトコルのガバナンストークンの投票権の大部分を取得し、同一のトランザクション内で表面上は正常な提案に見えるが実質的にはプロトコルの金庫資金を攻撃者のアドレスに移転する悪意ある提案を可決させ、即座にその提案を実行しフラッシュローンを返済した。この一連の攻撃は単一のブロック内で完了し、約1億8,000万ドルの損失をもたらした。これはガバナンス攻撃史上最大規模の事例の一つであり、その後「投票前のロック期間」と「実行前のタイムロック」という2つの設計が、ほとんどのプロトコルのガバナンスメカニズムの標準的な構成となるきっかけとなった。
これはセキュリティリスクの用語であり、前向きなトレードオフというものは存在しない——ガバナンス攻撃は被害を受けたプロトコルとそのメンバーにとって純粋な損失である。唯一議論できるトレードオフは：プロトコルがオープンで即時のガバナンスメカニズム（低い参加ハードル、迅速な実行）を選択することでガバナンスの効率と参加の利便性を向上させられるが、代償として攻撃耐性が弱くなること；投票前のロックや実行前のタイムロックなどの防御メカニズムの追加を選択することで安全性を大幅に向上させられるが、代償としてガバナンスプロセスが遅くなり参加ハードルが上がることであり、これはプロトコル設計段階でのトレードオフであり、ユーザーが一方的に変えられる選択ではない。