DeFi（分散型金融）に内在する10のリスク それぞれのリスク対応の考え方
2020年11月19日
この記事を簡単にまとめると（AI要約）
目次
- 前提
- 1.ベースレイヤーのブロックチェーンのリスク
- ユーザー視点で考えられる対策：
- 2.ペグ・ソフトペグトークンのリスク
- ユーザー視点で考えられる対策：
- 3.フロントエンドのリスク
- ユーザー視点で考えられる対策：
- 4.アプリケーション管理者のAdmin Key起因のリスク
- ユーザー視点で考えられる対策：
- 5.ユーザー起因のリスク
- ユーザー視点で考えられる対策：
- 6.スマートコントラクトリスク
- ユーザー視点で考えられる対策：
- 7.オラクル攻撃によるリスク
- ユーザー視点で考えられる対策：
- 8.フラッシュローンによる攻撃のリスク
- ユーザー視点で考えられる対策：
- 9.統合プロトコルのリスク
- ユーザーとして考えられる対策：
- 10.価格暴落による精算が実行できないリスク
- ユーザー視点で考えられる対策：
- 総論
前提
本レポートではDeFi（分散型金融）に内在するリスクを構造別に整理し、攻撃ケーススタディを解説します。
DeFiのアプリケーションを利用する際によく指摘されるリスクはスマートコントラクトのバグです。しかしながら、2020年に起こったDeFiのスマートコントラクトから資金が流出したケースを概観すると、スマートコントラクトのバグに起因したもの以外にも様々なケースが見受けられます。事例として多いものは、スマートコントラクトの仕様を突いた攻撃であり、オラクルやフラッシュローンを利用した攻撃です。例えば、2020年10月に起こったHarvest Financeからの約24億円の資金流出はフラッシュローン攻撃でした。
関連レポート：24億円が流出したHarvest Financeへのフラッシュローン攻撃の解説
https://hashhub-research.com/articles/2020-11-02-harvest-flashloan-economic-attack
https://hashhub-research.com/articles/2020-11-02-harvest-flashloan-economic-attack
もちろんスマートコントラクトリスクも無視できない問題です。ですが、DeFiのリスクファクターはそれだけでなく、実に広範にわたります。本レポートではDeFi（分散型金融）に内在するリスクを構造別に10の項目に分けて整理します。またそれぞれのリスク項目に、ユーザーとして考えられる対策も明記しています。
読者の方々がスマートコントラクトだけではなく様々なDeFiのリスクを理解したうえで、アプリケーションを利用するきっかけになれば幸いです。
1.ベースレイヤーのブロックチェーンのリスク
第一にベースレイヤーのブロックチェーンのリスクです。
Ethereum上のDeFiや、Ethereum上のアセットは、Ethereumのブロックチェーン自体が機能不全になるリスクを内包していると言えます。また、他の基盤のブロックチェーンを利用したDeFiであればそのベースレイヤーのブロックチェーンのリスクが同じく内在していると言えます。攻撃者はベースレイヤーのバリデータの1/3や過半数を支配して、二重支払いを実行できれば、DeFiのプロトコルから資金を奪える可能性があります。
ユーザー視点で考えられる対策：
これについては考えられる対策は非常に少ない状態です。強いて言うのであれば、パブリックブロックチェーン上のセキュリティはPoWであれ、PoSであれ、時価総額と相関します。時価総額が低いブロックチェーンであるにもかかわらず、多額の資産が取引されているブロックチェーンは攻撃されるリスクが増している可能性があります。そのような観点からユーザーはベースレイヤーを十分選定した上で使用するアプリケーションを選ぶ必要があります。
2.ペグ・ソフトペグトークンのリスク
ペグ・ソフトペグトークンも1つのリスクファクターです。
ペグトークンとは、USDCやUSDTなどの現物資産が担保になった資産のことです。例えばTetherが当局から摘発されたとして、そのときにDeFiでTetherを使用していた場合、価格下落リスクを負うことになります。
ソフトペグトークンとは、DAIやsUSDに代表されるステーブルコインです。DAIやsUSDは暗号資産を担保にした債権であり、ドルとソフトペグされていることが特徴です。このソフトペグトークンが何かしらの理由によって価格変動をした際、そのとき当該ステーブルコインを使用していた場合、価格下落リスクを負うことになります。
ユーザー視点で考えられる対策：
第一に、透明性が高く監査もされているステーブルコインを選ぶことです。USDCなどは監査レポートを定期的に公開し、発行と同額の資産が預託されていることが報告されています。
一方、Tetherなどを利用する場合、リスクヘッジをする手法も存在します。例えばTetherのCDS商品もEthereum上のDeFiで取引されており、Tetherの下落時に資金を回収できる保険のような商品が存在しています。
（参照： https://www.coindesk.com/credit-default-swaps-tether-opium ）
（参照： https://www.coindesk.com/credit-default-swaps-tether-opium ）
3.フロントエンドのリスク
DeFiのスマートコントラクトではなく、DeFiアプリケーションをホストしているフロントエンドのWebサイトがハッキングされ、ユーザー資金を流出する可能性がありえます。
DeFiアプリケーションのスマートコントラクト自体はブロックチェーンで実行されていますが、フロントエンドは従来のクラウドで管理されている場合がほとんどです。フロントエンドでは、コード、ドメイン、ホスティングなどのいずれかでバグやハッキングが発生する可能性があります。一時的にホストしているサイトが利用できなくなり、ユーザーがスマートコントラクトへのアクセス手段を失うことがあり得ます（この場合でも直接スマートコントラクトにアクセスすることは可能です）。さらに深刻な場合は、攻撃者がハッキングしたフロントエンドに悪意ある別のスマートコントラクトを配置してユーザー資金を奪うことが考えられます。
また、フロントエンドリスクに類似するものとして、悪質な詐欺師が公式によく似たURLで公式を模したフロントエンドを作成し、広告やSNSで拡散をすることなども考えられます。例えば、Uniswapとよく似たURLでUniswapとそっくりのwebサイトが公開されているものの、実際のスマートコントラクトは別物で悪意のあるスマートコントラクトだというケースです。
ユーザー視点で考えられる対策：
理想的な対策は、各アプリケーションの正規のスマートコントラクトアドレスを毎回確認することです。ですが、実際にはそういった対策を常に行うことは難しいでしょう。
Uniswapのホスティングサイトについては、分散ファイルシステムのIPFSとSia Networkにミラーがあり、またアグリゲーターのマージされたインターフェイス経由で同じように触ることができます。つまりUniswapのフロントエンドがハッキングされても分散ファイルシステム上にホストされた別サイトも存在しています。プロジェクトによってはこのように単一障害点を持たない工夫も実施されています。
（参照：https://siasky.net/hns/uniswap-dex/#/swap ）
（参照：https://siasky.net/hns/uniswap-dex/#/swap ）
4.アプリケーション管理者のAdmin Key起因のリスク
DeFiのスマートコントラクトにはAdmin Keyという概念があります。Admin Keyとはその名の通り「管理者鍵」であり、この管理者鍵を用いてスマートコントラクトのアップデートやパラメータの変更を行います。Admin Keyを使用して手数料パラメータやオラクルを自由に変更し、ユーザー資産を奪うことが可能な場合もあります。
ユーザーが知っておくべきリスクは主に2つあります。
1つ目は、管理者の持つAdmin Keyが、第三者のハッカーによって奪われるリスクです。当該アプリケーションのコアチームがAdmin Keyをどのように管理しているのか、ユーザーは知ることができません。ハードウェアウォレットで安全に管理されているのか、あるいはスクリーンショットなどで雑に管理されているのか、ユーザーには確かめる術がないのです。
2つ目は、Admin Keyを保有する管理者が悪意を持っている場合や、Admin Keyの権限が大きすぎる場合のリスクです。Admin Keyにも権限レベルというものが存在します。パラメータのみを変えられる場合や、スマートコントラクトの大部分をアップデートできる場合、あるいはユーザー資産のトランザクション権限がある場合など、ケースバイケースです。この権限レベルが大きすぎると、DeFiと称しながらも実態としては開発者を完全に信用しなくてはいけない金融サービスだったということも少なくありません。
ユーザー視点で考えられる対策：
上記のリスクを前提にして、ユーザーは自身が使用するプロジェクトのAdmin Keyの権限、Admin Keyがどのように管理されているのか、またtimelockの有無を認識することが望ましいでしょう。
Admin Keyの権限については、そのAdmin Keyで何ができるのかを知ることです。特定のパラメータを調整できるだけなのか、クリティカルなパラメータを調整できるのかなどを確かめる必要があります。
次にAdmin Keyがどのように管理されているのかという観点ですが、これはいくつかのパターンがあります。マルチシグで管理されているのか、シングルシグなのかを知っておくべきでしょう。また、完全にコミュニティガバナンスに移行しているプロジェクトでは、コアチームのAdmin Keyでコードのアップデートができず、ガバナンストークンの投票のみによってアップデートされる場合もあります。
最後にtimelockの有無の確認です。timelockとは、コードのアップデートトランザクションが実行されてから実際に変更されるまでの期間の設定です。例えば、あるDeFiプロトコルがtimelockを3日に設定したとします。この場合、悪意ある第三者にコアチームが保有するAdmin Keyを盗まれたとしても、ユーザーの資金に影響を与えるコードをアップデートを実行しても実際にコードが変更されるまで3日間の猶予が発生します。その3日間の内に、意図していないコード変更が行われようとしていることがコミュニティ内で警告されるはずです。このためtimelockは有効な対策の1つと言えます。
このような各プロジェクトのAdmin Keyの状況について纏めたサイトとして、DeFi Watchが有効な情報源になり得ます。（参照： https://defiwatch.net/ ）
5.ユーザー起因のリスク
ユーザー起因のリスクもあります。例えば、秘密鍵の紛失はその典型です。DeFiはユーザーが秘密鍵を管理するノンカストディの形式が一般的であることから、ユーザーが秘密鍵を紛失した場合、その資産は取り出せなくなります。
ユーザー視点で考えられる対策：
対策としてはBitcoinなどの暗号資産を保管する際と同様です。まずはシードフレーズをオフラインで厳重に保管することです。また、ハードウェアウォレットを使用することも有効です。TrezorやLedgerなどのハードウェアウォレットは主要なDeFiアプリケーションに対応しており、ユーザーはハードウェアウォレット経由で署名をしてトランザクションが実行できます。
また他の選択肢としては、Gnosis Safeのマルチシグを利用することも手段として考えられます。Gnosis Safeのマルチシグもまたスマートコントラクトで構成されているので、スマートコントラクトリスクのファクターの1つでもありますが、当該コントラクトは広く利用されているものであり比較的安全であると判断できます。
6.スマートコントラクトリスク
次にスマートコントラクトリスクです。スマートコントラクトは一度デプロイをした場合、変更が容易ではないという性質があります。また、お金そのものをスマートコントラクトにデポジットするという性質からスマートコントラクトのバグによって、デポジットされた資金の引き出しが実行できないということが起こり得ます。
本番リリースされる前のコードのテストが不十分であると、テストパターンが考えられる十分なケースを満たしておらず、○○のプロセスでデポジットされた資金は引き出せない、というようなことが起こり得ます。そういった脆弱性を突いた攻撃をここではスマートコントラクトリスクと総称します。多くのスマートコントラクトでは、専門の会社に監査されていることが一般的です。
スマートコントラクトのバグによって最も多額の資金が喪失した事例として、2017年に起きたParityのマルチシグで$280million分の資産が凍結されました。2016年のThe DAOに関しては$50millionの資金がハッカーによって流出しました。
（参照： https://blog.comae.io/the-280m-ethereums-bug-f28e5de43513 ）
（参照： https://blog.comae.io/the-280m-ethereums-bug-f28e5de43513 ）
比較的最近の事例では、2020年8月にその時点で約500millionの資金がロックされたYam Financeに脆弱性が報告されました。攻撃には発展しなかったものの、バグの報告によりネイティブトークンの価格は大幅に下落しました。同プロジェクトはそれまでコード監査がされておらず、スマートコントラクトの脆弱性に関わる監査の実施は必須であるという考えが業界全体に広まりました。
ユーザー視点で考えられる対策：
第一に、スマートコントラクトは100%のセキュリティを保証することはできません。また、ユーザーはスマートコントラクトの監査を自分自身で行うことはできません。専門のチームが数名で取り掛かっている監査業務をユーザー自身で行うことは難しいでしょう。その上でユーザー視点で行うべき対策としては、以下のようなものがあります。
・監査レポートを読む
まずはスマートコントラクトの監査報告書を読むことです。監査されているとしても、監査レポート次第では「○○の箇所に問題がある可能性がある」と締めくくられている場合もありますし、監査レポートの内容が簡素になっている場合あります。
・その監査レポートはどこの会社が出したものか
当該スマートコントラクトにいくつの監査がなされているか、それぞれの監査レポートはどこの会社から出ているものかも重要な観点です。
スマートコントラクト監査の会社にも格のようなものが存在しています。ChainSafe Systems、Quantstamp、Trail of Bits、Zeppelinなどはいわゆるティアが高い会社として認識されています。これらの会社はスマートコントラクト監査を事業としている期間が比較的長いと言えます。一方で最近できたばかりのスマートコントラクト監査会社も存在し、そういった会社のみに監査されている場合、やはり監査レポートの重みは異なるでしょう。
・監査がなされてからコードのアップデートや新しいバージョンがリリースされていないか
当該プロジェクトにスマートコントラクト監査が行われていても、その監査がいつ行われたものかという視点を持つことが必要です。監査がなされてからコードのアップデートや新しいバージョンがリリースされていないか確認する必要があります。
過去の監査に問題がなくても、監査後にアップデートされたコードに脆弱性が存在する場合もあります。
関連レポート：スマートコントラクト監査事業企業の概観、その必要性や市場動向など
https://hashhub-research.com/articles/2018-07-14-smartcontract-audit
https://hashhub-research.com/articles/2018-07-14-smartcontract-audit
また、最近はDeFi保険のようなプロジェクトも複数登場しています。
関連レポート：Ethereum上の分散保険システムであるNexus Mutualの概要。コミュニティでリスクをカバーするDeFiやDApps向けの保険ソリューションについて
https://hashhub-research.com/articles/2019-06-13-nexus-overview
https://hashhub-research.com/articles/2019-06-13-nexus-overview
7.オラクル攻撃によるリスク
Synthetix、bZx、Harvest Financeへの攻撃に利用された手法です。いくつかのDeFiプロダクトはプラットフォーム上で利用する価格を外部情報に依存しています。この価格情報を操作することで、攻撃者にとって有利な為替レートを実現させ、その間にプラットフォーム上でトークンの交換を完了させることで利益をかすめ取る方法がオラクル攻撃です。
ユーザー視点で考えられる対策：
プロトコル側からの対応策としては、時間加重平均値を使う、M-of-N方式で特定のユーザーのみが価格情報を更新できるようにする、価格情報の更新のリアルタイム性を捨て遅延を導入する等があります。
ユーザーとしては、それらの各プロトコルの対応を理解して考え得るリスクをなるべく洗い出すことです。
関連レポート：オラクル利用のレンディングプラットフォームからETHを掠め取るハッキング事例
https://hashhub-research.com/articles/2020-02-24-defi-oracle-attack
https://hashhub-research.com/articles/2020-02-24-defi-oracle-attack
関連レポート：オラクルの利用時の工夫をUniswapとMakerDAOの例から学ぶ
https://hashhub-research.com/articles/2020-08-21-oracle
https://hashhub-research.com/articles/2020-08-21-oracle
8.フラッシュローンによる攻撃のリスク
前節のオラクル攻撃を1トランザクション内に完結させたものがフラッシュローン攻撃です。フラッシュローン攻撃には「借り入れが可能なので手持ちの資産が必要ない（ガス代のみ）」、「1トランザクション内で完了するので気付いた頃には攻撃が完了している」等の特徴があり、スマートコントラクトそのものにはバグがなくとも仕様上の特性を利用することで悪用が可能という厄介さがあります。これはスマートコントラクトセキュリティの監査を行っていたとしても、フラッシュローン攻撃やオラクル攻撃への耐性は別途検討しなければならないことを意味します。
フラッシュローン攻撃とオラクル攻撃は別物ですが、最近のフラッシュローン攻撃はほとんどがオラクル攻撃を内包したものであり、その意味ではオラクル攻撃が進化して1トランザクション内で完結したものの一種だと捉えることも可能です。
関連レポート：24億円が流出したHarvest Financeへのフラッシュローン攻撃の解説
https://hashhub-research.com/articles/2020-11-02-harvest-flashloan-economic-attack
https://hashhub-research.com/articles/2020-11-02-harvest-flashloan-economic-attack
関連レポート：bZxの3000万円消失事件の解説と今後のDeFiの利用方法
https://hashhub-research.com/articles/2020-02-20-incident-blockchain
https://hashhub-research.com/articles/2020-02-20-incident-blockchain
ユーザー視点で考えられる対策：
プロトコル側からの対応策としては、時間加重平均値を使う、M-of-N方式で特定のユーザーのみが価格情報を更新できるようにする、価格情報の更新のリアルタイム性を捨て遅延を導入する等があります。
ユーザーとしては、それらの各プロトコルの対応を理解してなるべく考えうるリスクを洗い出すことです。
9.統合プロトコルのリスク
DeFiのアプリケーション・プロトコル群の特徴は、様々なプロジェクトを組み合わせて1つの新しいプロダクトを構成するマネーレゴと呼ばれる性質にあります。これはあるアプリケーションAの背後に他のプロトコルBやCが稼働をしており、アプリケーションAの利用者は背後のプロトコルのリスクも背負っていることを意味します。そのリスクとは、本レポートでここまで指摘をしてきたスマートコントラクトの脆弱性やオラクル攻撃、フラッシュローン攻撃など全般を含みます。
ユーザーとして考えられる対策：
ユーザーとしては、あるアプリケーションを利用する際に、その背後の統合先のプロトコルも理解する必要があります。
一方で統合しているプロトコルのすべてのリスクを引き受けるとは必ずしも限らない場合もあります。これについては下記のレポートで詳しく解説していますが、いずれにしても各プロジェクトを正確に把握するように努めることしかできないでしょう。
関連レポート：DeFiのリスク構造を正しく理解するための延焼度という指標
https://hashhub-research.com/articles/2020-08-10-defi-risk-model
https://hashhub-research.com/articles/2020-08-10-defi-risk-model
10.価格暴落による精算が実行できないリスク
DeFiの構造的リスクとして、暗号資産市場全体が暴落したとき、あるいは特定の銘柄が大きく暴落したときに精算が実行できない事態が想定されます。典型的な例では、DeFiのレンディングプロトコルはある資産を担保にして、他のアセットを借り入れしています。担保資産の価格が下落して基準価格以下になった際、プロトコルが健全に機能している場合は、精算ロジックが執行されます。
しかし、市場が急速な下落をしたときには精算プロセスが正常に実行できない可能性があります。これは担保資産をあるべき価格で売却できず、プロトコルが債務超過になることを意味します。プロトコルが債務超過になるとは、そのプロトコルに貸し手として参加しているユーザーの資金も元本通り引き出せないことと同義です。
過去にこのような事態に陥った具体的事例としては、2020年3月12日に起きたMakerDAOの事例が挙げられます。当時、新型コロナウイルス拡大の報道を受けて世界の金融市場が大暴落をし、暗号資産市場も歴史的な暴落を経験しました。MakerDAOもまたプロトコル内で担保にされているETHが暴落して危機的な状況になりました。このMakerDAOの事例では、MakerDAOのネイティブトークンMKRを新規で発行しオークション販売をして、その売却益でプロトコルの債務超過を補填しました。MakerDAOのこのような動作は元々設計されていた仕様です。その後、MakerDAOは正常に稼働しています。
上記ケースはこういった危機的状況をプロトコルがなんとか乗り切った事例ですが、もしネイティブトークンのMKRがオークションで買い手がつかなかったとしたら債務補填ができず、ロスカットをせずに担保マネジメントをした場合でもユーザーが損失を被る事態に発展した可能性があります。
このような価格暴落時に精算が機能しないリスク、それによってプロトコルが債務超過になるリスクは、DeFiの構造的リスクです。またこの状態があるプロトコルAで起こった場合、その他のプロトコルにも連鎖的に波及する可能性が考えられます。
関連レポート：3月12日、市場暴落時にMakerDAOのエコシステム何が発生したかを概観する
https://hashhub-research.com/articles/2020-03-15-march-12-market
https://hashhub-research.com/articles/2020-03-15-march-12-market
ユーザー視点で考えられる対策：
これについては、自身が使用を検討しているプロトコルが相場暴落時に債務超過にならないためにどのような仕組みを実装しているか理解することが必要です。プロトコルが設計している損失補填の仕組みは大きく分けて2つのパターンがあります。
1つ目はすでに例に挙げたMakerDAOのように、ネイティブトークンを新規発行・希釈して補填をする形式です。MakerDAOのケースではMKRの価格が高く、トークンの需要もあったためプロトコル内の資金の損失を補填できました。しかし逆説的にはトークンの価格が低く、トークンの需要も限定的だった場合、この手法を採用しているプロトコルは損失の補填が困難な可能性があることを想定するべきでしょう。
2つ目はプロトコルが日々の手数料であるオンチェーンキャッシュフローを保険基金として積み立てているモデルです。これにはCompoundやAaveなどのモデルが存在します。このモデルを採用しているプロトコルのリスク算定や相場急落時の耐性を見極めるには、保険基金の残高を確認する必要があります。
関連レポート：Compound/CREAMの仕組みを担保率や準備率、金利モデルから理解する
https://hashhub-research.com/articles/2020-10-28-how-compound-and-cream-work
https://hashhub-research.com/articles/2020-10-28-how-compound-and-cream-work
総論
本レポートではDeFi（分散型金融）に内在するリスクを構造別に整理しました。話題になることが多いDeFiのリスクをほぼ網羅できたのではないかと思います。しかしこれは2020年11月時点での情報です。
DeFiに限らずサイバーセキュリティの基本前提は、攻撃パターンは常に更新され続けるということです。実際のところ、DeFiのフラッシュローン攻撃については2020年に入ってから非常に多く発生しており、現在の攻撃手法の主流になっていると言えるでしょう。DeFiユーザーは、本レポートの内容を念頭に置きつつも、今後も様々な攻撃方法が登場することを当たり前だと考えるべきでしょう。
HashHub Researchでは今後もDeFiの攻撃ケーススタディなどを積極的に取り上げていくつもりです。
※免責事項：本レポートは、いかなる種類の法的または財政的な助言とみなされるものではありません。
