DeFiはユーザーにかなりの収益をもたらすことができますが、資金の安全性こそが資産の安定した成長の核心です。GMTokyoチームは、DeFiのインタラクション中によく見られるセキュリティリスクと対応するセキュリティ対策を整理しました。このガイドがブルマーケット中のDeFiセキュリティインタラクションに対して皆さんにインスピレーションと助けを提供できればと願っています。

2019年のDeFiサマー以来、イーサリアムを中心に、より多くの創造的な分散型金融プロトコル（DeFiプロトコル）が登場し、オンチェーン資産の利用可能性が大幅に向上し、ブロックチェーンユーザーがより多様な金融活動を行い、それによって豊かな収益を得ることができるようになりました。

しかし、DeFiプロトコルの増加とともに、セキュリティの課題も増加しています。2023年だけでも、ブロックチェーン攻撃による資産損失は26.1億ドルに達したとの報告があります。DeFiプロトコルに参加する際には、収益の見込みだけでなく、プロトコルのセキュリティ評価も無視できないことがわかります。

一般的に、現在、プロトコルのセキュリティ評価は主にコードのセキュリティ評価と定義されていますが、この定義は比較的単一の次元であり、評価自体は静的なプロセスでのみプロトコルのセキュリティを考慮しています。

しかし、DeFiのインタラクションでは、セキュリティはしばしばダイナミックであり、アカウント管理、プロトコルのインタラクションの準備、インタラクション後の資産管理、データ監視、極端な状況での資産損失後の自己救済など、複数の段階にわたります。

DeFi新参者として、収益を得ながら資金の安全性を最大限に確保する方法は何でしょうか？Gmtokyoチームは、DeFiのインタラクション中によく見られるセキュリティリスクと対応するセキュリティ対策を整理しました。これが、ブルマーケット中のDeFiセキュリティインタラクションに関する皆さんのインスピレーションと助けになれば幸いです。

DeFi交互中の一般的なセキュリティリスクと予防策

一、アカウントのプライベートキー漏洩

アカウントのプライベートキー漏洩は、現在の新規ユーザーがかなり陥りやすい問題の1つです。現在、市場にはさまざまな種類のウォレットがあり、新規ユーザーはウォレットの安全性を判断する能力が不足しています。そのため、多くの新規ユーザーが安全でないウォレットをダウンロードし、そのウォレットを使用してプライベートキーを生成します。その結果、プライベートキーが悪意のある者に渡され、プライベートキーが漏洩します。多くの経験豊富なユーザーが自分のメインアカウントの資産がある日突然すべて転送されてしまったことに気づき、長時間の分析の結果、すべての操作が正常であることがわかります。このようなケースでは、ほとんどの場合、アカウントが早期に安全でないウォレットを使用してプライベートキーを生成したことにより、プライベートキーが既に漏洩していることが原因です。

同時に、ブロックチェーンのエアドロップによって富の効果が生じ、多くの新規ユーザーがいくつかのエアドロップウェブサイトを盲目的にクリックします。これらのエアドロップウェブサイトは、非常に真面目なプロジェクトのウェブページのように自分自身を包装し、多額の未受け取りトークンが存在することをユーザーに伝えます。利益のために、多くの新規ユーザーがウェブページの誘導に従って自分のアカウントのプライベートキーを入力し、プライベートキーが漏洩します。

プライベートキーの漏洩を防ぐために、ユーザーは以下の点に注意する必要があります：

- よく知られているブロックチェーンウォレットを使用し、それに対応する公式ウェブサイトからウォレットをダウンロードします。可能な場合は、ハードウェアウォレットを使用することをお勧めします。

- 自分のプライベートキーを明示的にインターネットに公開しないでください。また、自分のプライベートキーを任意のウェブページに入力しないでください。

二、署名フィッシングのリスク

署名フィッシングのリスクもプライベートキーの漏洩と同様に、新規ユーザーの重要なリスクです。このようなフィッシング攻撃は、ユーザーに直接プライベートキーを入力させるのではなく、ユーザーに対してトランザクションまたは署名を行うよう誘導し、関連する資産の承認を取得します。これには高い隠蔽性、分析の難しさ、そして気づきにくいという特徴があります。

通常、攻撃者はユーザーをフィッシングウェブサイトに誘導し、エアドロップの受け取りやログインの検証などの名目でユーザーに署名を要求します。この時、ユーザーのブラウザウォレットは署名の完了を要求します。

署名フィッシングの種類にはいくつかあります：

• 直接送金型。ETHを直接送金するか、ERC20トランスファーを呼び出してウォレット資産を攻撃者のアドレスに送金します。
• Approve型。ERC20のApproveメソッドを呼び出して、攻撃者のウォレットに承認を与えます。ユーザーが署名すると資産の移動は発生しませんが、攻撃者のウォレットはtransferFromを呼び出してユーザーの資産を移動できます。
• EIP712メッセージ署名型。ERC20のPermitメソッド、Permit2の承認、NFTオーダーの署名など。このような署名は通常、ウォレットでJSONデータまたは整形されたツリーデータとして表示されます。ユーザーが署名するとトランザクションは発生せず、ガス消費もありません。ただし、署名結果はフィッシングウェブサイトに記録され、攻撃者はその署名結果を使用して被害者のERC20またはNFT資産を移動できます。
• 原始ハッシュ署名型。署名データは16進数のハッシュデータであり、具体的な署名内容は署名データ自体から推測できません。ハッシュの背後には上記の1〜3種類のデータがある可能性があります。署名は資産の損失を引き起こす可能性が高いですが、現在の主流のウォレットは通常、このような署名方式を禁止するか、明確なリスク警告を行います。

最近のいくつかのケースでは、一部のフィッシングウェブサイトがユーザーに複数回の署名を要求し、最初の数回は無害な正常な署名ですが、その後に悪意のある署名が混在しています。これにより、ユーザーの操作の慣性を利用して署名操作を完了させます。

フィッシングによる資金損失を防ぐためには、盲目的な署名を拒否することが重要です。各署名を注意深く審査し、不確かな内容の取引に対して署名を拒否する必要があります。具体的には、以下の点に注意することができます：

• インタラクションするウェブサイトがDeFiプロジェクトの公式ウェブサイトであることを確認し、完全なドメインを確認します。
• 呼び出されるコントラクトのメソッドを確認し、特にtransferやapproveメソッドを重点的にチェックします。
• 取引に含まれるETH送金を確認します。一部のフィッシングウェブサイトは、安全に見える方法（例：Claim）を構築しようとしますが、実際にはETH送金が含まれ、ETHなどのネイティブトークンの損失を引き起こします。
• 原始ハッシュの内容に署名しないようにします。

三、送金先アドレスの汚染

送金先アドレスの汚染は比較的新しい攻撃手法であり、ユーザーが転送トランザクション（ERC20、ネイティブトークンなど）を行う際に、そのトランザクションの受信アドレスに似たアドレスを使用して、ユーザーに同じ金額のトランザクションまたは同じ金額のトランザクションが送信され、対応するトークンが偽のトークンである場合があります。

例えば、Aliceは毎月1 ETHをBobに給料として転送します。Charlieはこのトランザクションを監視し、Bobと類似したアドレス（先頭の8桁と末尾の8桁が同じ）に0.001 ETHをAliceに送信します。この操作により、次回のAliceからBobへの転送時にCharlieのアドレスがトランザクションの受信アドレスとして使用される可能性があります。これは、ブロックチェーンアドレスが長くて規則性がないため、ユーザーが覚えるのが難しいため、多くの場合、ユーザーが前回のトランザクション履歴からアドレスをコピーすることを望んでいるためです。CharlieとBobのアドレスが非常に類似しているため、Aliceが識別するのが難しく、最終的に資産の損失を引き起こす可能性があります。

そうならないために、ユーザーは次の手段を取ることができます：

• 各取引時に送金先アドレスを確認し、前後数バイトだけでなく、完全な内容を確認します。
• よく使うアドレスをアドレスブック（ホワイトリスト）に設定し、転送時にはできるだけアドレスブックのアドレスを使用します。
• チェーン上のチャネル（ブロックチェーンエクスプローラ、ウォレット取引履歴など）からアドレスをコピーして送金先として使用しないようにします。

四、トークンの過度な承認

トークンの承認は、DeFiの相互作用のほぼ最初のステップです。DeFi操作を行う際に、取引データは通常、プロジェクトのウェブページによって構築され、ユーザーによって構築されません。通常の場合、ユーザーが繰り返し承認を行う必要がないようにするため、プロジェクトのウェブページはユーザーに無限の承認トランザクションを提供し、ユーザーに署名させます。これは、ユーザーのガスを節約するためのものですが、後続の資金の安全性にも潜在的なリスクがあります。たとえば、後続のプロジェクトコードに問題が発生した場合、未承認のインターフェースや任意の呼び出しの脆弱性が存在する場合、ユーザーの無限の承認は攻撃者によって利用され、ユーザーの資産が移動される可能性があります。この攻撃シナリオは、クロスチェーンブリッジやDEXプロトコルでよく見られます。

後続のプロジェクトがリスクコードを導入する可能性があるか、またはプロジェクトコード自体に未発見の脆弱性が存在する可能性を防ぐために、ユーザーは最小の承認原則を採用し、可能な限り今回の取引に使用される金額のみを承認するべきです。

五、安全でないDeFi操作

交換前の準備に加えて、交換の過程で見落とされやすい多くのリスクが存在します。これらのリスクは通常、ユーザーがプロジェクト自体を理解していないことに起因します。具体的な例には以下があります：

• オンチェーンのスワッププロトコルを使用してトークンを交換する際に、スリッページ設定が大きすぎるか、またはスクリプトを使用してスワップする際に、最低受け取り数量を設定しない（便宜上0に設定）ため、取引がMEVロボットの「サンドイッチ」攻撃を受ける。
• オンチェーンの借入プロトコルを使用して借入操作を行う際に、ポジションの健全性を適切に管理せず、大きな価格変動中にポジションが清算される。
• 特定のプロジェクトとのやり取りを行う際に、プロジェクトのトークンを適切に管理せず、例えばUniswap V3のNFTトークンを通常のNFTとして扱い、OpenSeaで売却してしまう。

これらのリスクを防ぐために、ユーザーはプロジェクトとのやり取りを行う際に、適切なプロジェクトリサーチを行い、プロジェクトのメカニズムと関連する特性を明確にし、資産の損失を防ぐ必要があります。

まとめ

DeFiのインタラクティブには防ぎにくい多くのリスクが存在します。記事で述べられた内容は多くの一般的なシナリオをカバーしていますが、すべてのリスクポイントを完全に網羅することはできません。ユーザーはすべての取引に真剣に取り組む必要があります。

DeFiはユーザーにかなりの利益をもたらすかもしれませんが、資金の安全が資産の安定的な成長の核心です。GmtokyoはすべてのDeFi Farmerを保護し、ブルマーケットでさらに多くの価値を創造するお手伝いをします。

‍