セキュリティ特別号 05｜OKX Web3 ＆ BlockSec：すべてのホエールにアラート、DeFiワールド最新のリスク回避攻略
TechFlow厳選深潮セレクト
セキュリティ特別号 05｜OKX Web3 ＆ BlockSec：すべてのホエールにアラート、DeFiワールド最新のリスク回避攻略
ブロックチェーンセキュリティの先駆者であるBlockSecとOKX Web3ウォレットセキュリティチームが特別に参加し、これから「ホエール」になる予定またはすでにそうなったユーザーおよびプロジェクト関係者向けに、DeFiにおけるリスク回避攻略を共有します。
Web3業界の深掘り報道に専念し潮流を洞察はじめに
OKX Web3ウォレットは特別企画として「セキュリティ特集」コーナーを設立し、さまざまなタイプのオンチェーンセキュリティ問題に対して専門的な解説を行っています。ユーザーの身近で実際に起きたケースを取り上げ、セキュリティ分野の専門家や機関と連携して、複数の視点から二重のシェアと解説を行い、段階的に安全な取引ルールを整理・体系化することを目指しています。これにより、ユーザー自身が秘密鍵やウォレット資産の保護方法を学び、セキュリティ教育を強化することを目的としています。
DeFi世界の最大の魅力は、誰もが「ホエール（大口投資家）」になれる可能性を持っていることだ
しかし、たとえ「ホエール」であっても油断は禁物。利益を得ている一方で、「攻撃を受ける」こともある
だからこそ、オンチェーンでの活動では、何よりもセキュリティが最優先
そうでなければ、またゼロからやり直しになってしまう～
今号は「セキュリティ特集」第5弾。ブロックチェーンセキュリティの先駆者であるBlockSecとOKX Web3ウォレットセキュリティチームを特別に招き、実践的なガイドラインの観点から、これから「ホエール」になるかもしれないすべてのユーザーおよびプロジェクト運営側に向けて、DeFiリスク回避マニュアルをご紹介します。例えば、監査レポートの見方、DeFiプロジェクトのリスク評価に使われる指標やパラメータ、プロジェクト運営側やホエールユーザーが監視・検知能力をどう構築すべきか、DeFiセキュリティ保護の原則など…必見です！
BlockSecセキュリティチーム：BlockSecは世界的にリードする「フルスタック」型ブロックチェーンセキュリティサービスプロバイダーであり、MetaMask、Compound、Uniswap Foundation、Forta、PancakeSwap、Pufferなどの著名なプロジェクトを含む300以上のクライアントにサービスを提供しています。これまでに白帽ハッカーによる救済活動を通じて、2,000万ドル以上の資金損失を回復しました。
CEO兼共同創業者の周亜金氏は浙江大学コンピュータ教授で、Aminerが選出する世界で最も影響力のある研究者の一人であり、トップレベルの論文を50編以上発表し、1万回以上の引用を獲得しています。CTO兼共同創業者の呉磊氏は浙江大学コンピュータ教授で、元PeckShield共同創業者。チームを率いて多数の著名プロジェクトにおいて数十件のゼロデイ脆弱性を発見しました。製品責任者のRaymond氏は、腾讯（テンセント）および360でセキュリティ製品を担当した経験を持ちます。
OKX Web3 ウォレットセキュリティチーム：こんにちは、本日の共有をとても嬉しく思います。OKX Web3 Securityチームは、OKXがWeb3領域において多様なセキュリティ機能を構築することを担っており、スマートコントラクトのセキュリティ監査、ウォレットのセキュリティ強化、オンチェーンプロジェクトの監視などを行い、ユーザーに製品セキュリティ、資産セキュリティ、取引セキュリティといった多層的な保護サービスを提供し、ブロックチェーン全体のセキュリティエコシステムの維持に貢献しています。
Q1：ユーザーが実際に遭遇したDeFiリスク事例をいくつか教えてください
BlockSecセキュリティチーム：DeFiは比較的安定した高利回りを資産にもたらすため、多くの大口ユーザーが参加しています。多くのプロジェクトも流動性を高めるために、積極的に大口ユーザーを誘致しています。例えば、ニュースなどでよく見かけるように、大口ユーザーが巨額の資産をDeFiに預け入れる事例があります。もちろん、これらのホエールたちがDeFiプロジェクトに参加する際には、安定した収益を得られる一方で、一定のリスクにも直面します。以下に、業界で公開されているDeFiリスク事例をいくつか紹介します：
事例1：2022年のPolyNetworkセキュリティインシデントでは、総額6億ドル以上の資産が攻撃されました。報道によると、神魚氏もその中に1億ドルを預けていたとのことです。その後攻撃者が資金を返還し、事件は円満に解決しました。神魚氏はこの出来事を記念してオンチェーン上に記念碑を建立すると宣言しましたが、この過程は非常に苦痛だったことでしょう。一部のセキュリティインシデントでは良い結果に終わりますが、大多数のケースではそううまくいきません。
事例2：有名なDEXであるSushiSwapは2023年に攻撃を受け、大口ユーザー0xSifu氏が330万ドル以上を失いました。彼一人の損失が全体の約90％を占めていました。
事例3：今年3月のPrismaセキュリティインシデントでは、総損失額は1,400万ドルに達し、これは17のウォレットアドレスからのものでした。平均して各ウォレットが82万ドルを失った計算になりますが、そのうち4人のユーザーの損失が全体の80％を占めていました。これらの盗難資産の大部分はまだ回収されていません。
結局のところ、特にメインネットのDeFiはガス代が無視できないため、ある程度の資産規模に達しないと実質的な利益を得ることは困難です（エアドロを除く）。そのため、DeFiプロジェクトのTVL（総預入価値）の大半はホエールによって構成されており、あるプロジェクトではわずか2％のホエールが80％のTVLを占めることもあります。セキュリティインシデントが発生した場合、必然的にこれらのホエールたちが大部分の損失を被ることになります。「ホエールが儲けているばかりに注目するのではなく、彼らも攻撃を受けることがある」ということです。
OKX Web3 ウォレットセキュリティチーム：オンチェーン世界の発展とともに、ユーザーが遭遇するDeFiリスク事例も日々増加しており、オンチェーンセキュリティは常にユーザーにとって最も基本的かつ重要なニーズです。
事例1：PlayDapp 特権アカウントの秘密鍵漏洩事件。2024年2月9日から12日にかけて、イーサリアムベースのPlayDappゲームプラットフォームが秘密鍵漏洩により攻撃を受け、攻撃者は不正に17.9億枚のPLAトークンを鋳造・盗み出し、約3,235万ドルの損失を出した。攻撃者はPLAトークンに新たな鋳造者を追加し、大量のPLAを鋳造して複数のオンチェーンアドレスや取引所に分散させました。
事例2：Hedgey Finance 攻撃事件。2024年4月19日、Hedgey FinanceはイーサリアムおよびArbitrum上で重大なセキュリティ脆弱性により、約4,470万ドルの損失を被りました。攻撃者は、ユーザ入力の検証が不足している契約の脆弱性を悪用し、被害を受けた契約に対する承認を得て、契約内の資産を窃取しました。
Q2：現在のDeFi分野における主なリスクタイプをまとめられますか？
OKX Web3 ウォレットセキュリティチーム：実際の事例を踏まえ、現在のDeFi分野でよく見られる4つのリスクタイプを整理しました。
第一：フィッシング攻撃。フィッシング攻撃は一般的なネットワーク攻撃の一つで、正当な個人または組織になりすまして、ユーザーに秘密鍵、パスワード、その他の個人情報などの機密情報を入力させる手口です。DeFi分野では、以下のような形で行われます：
1）偽サイト：攻撃者が本物のDeFiプロジェクトと似たフィッシングサイトを作成し、ユーザーに承認や送金取引を署名させる。
2）ソーシャルエンジニアリング攻撃：Twitter上で、攻撃者は類似アカウントを使用したり、プロジェクト公式のTwitterやDiscordアカウントを乗っ取り、虚偽のプロモーションやエアドロ（実際はフィッシングリンク）情報を投稿してユーザーを騙す。
3）悪意あるスマートコントラクト：攻撃者が魅力的に見えるスマートコントラクトやDeFiプロジェクトを公開し、ユーザーにアクセス権限を付与させることで資金を盗み取る。
第二：ラグプル（Rugpull）。ラグプルはDeFi特有の詐欺で、プロジェクト開発者が大量の投資を集めた後に突然資金を持ち逃げし、投資家の資金をすべて奪う行為です。これは主に分散型取引所（DEX）や流動性マイニングプロジェクトで発生します。主な形態は以下の通りです：
1）流動性の撤退：開発者が流動性プールに大量の流動性を提供してユーザーの投資を誘い、その後すべての流動性を一気に引き出すことで、トークン価格が暴落し、投資家に甚大な損失を与える。
2）架空のプロジェクト：開発者が一見合法に見えるDeFiプロジェクトを立ち上げ、虚偽の約束や高利回りでユーザーを誘導するが、実際には製品やサービスが存在しない。
3）コントラクト権限の変更：開発者がスマートコントラクト内のバックドアや権限を利用して、いつでもルールを変更したり資金を引き出すことができる。
第三：スマートコントラクトの脆弱性。スマートコントラクトはブロックチェーン上で自動実行されるコードであり、一度デプロイされると変更できません。もしコントラクトに脆弱性があれば、重大なセキュリティ問題につながります。代表的な脆弱性は以下の通りです：
1）再入（リエントランシー）脆弱性：攻撃者が前回の呼び出しが完了する前に脆弱なコントラクトを繰り返し呼び出し、内部状態に異常をきたす。
2）論理エラー：コントラクト設計や実装上の論理ミスにより、予期しない動作や脆弱性が発生。
3）整数オーバーフロー／アンダーフロー：整数演算の処理が不適切で、オーバーフローやアンダーフローが発生。
4）価格操作：攻撃者がオラクルの価格を操作して攻撃を行う。
5）精度の損失：浮動小数点または整数の精度問題により、計算エラーが発生。
6）入力検証の欠如：ユーザー入力に対して十分な検証が行われず、潜在的なセキュリティ問題を引き起こす。
第四：ガバナンスリスク。ガバナンスリスクとは、プロジェクトの意思決定や支配機構に関わるリスクであり、悪用されればプロジェクトが本来の目標から逸脱したり、甚大な経済的損失や信頼危機を招く可能性があります。主なリスクタイプは以下の通りです：
1）秘密鍵の漏洩
特定のDeFiプロジェクトの特権アカウントはEOA（外部所有アカウント）またはマルチシグウォレットで管理されていますが、これらの秘密鍵が漏洩または盗まれた場合、攻撃者は自由にコントラクトや資金を操作できるようになります。
2）ガバナンス攻撃
一部のDeFiプロジェクトは去中心化されたガバナンス方式を採用していますが、それでも以下のリスクがあります：
· ガバナンストークンの借用：攻撃者が大量のガバナンストークンを借りて、短期間で投票結果を操作。
· 多数の投票権を掌握：ガバナンストークンが少数の人物に集中している場合、それらの人物が投票権を集中させてプロジェクト全体の意思決定を支配可能。
Q3：DeFiプロジェクトの安全性やリスクレベルを初期評価するために使える指標やパラメータはありますか？
BlockSecセキュリティチーム：DeFiプロジェクトに参加する前に、プロジェクト全体のセキュリティ評価を行うことは非常に重要です。特に資金規模が大きい参加者にとっては、必要なデューディリジェンス調査が資金の安全を最大限に守ることにつながります。
第一に、プロジェクトコードのセキュリティを包括的に評価することをお勧めします。たとえば、プロジェクトが監査を受けているかどうか、信頼性の高いセキュリティ会社による監査を受けているかどうか、複数の監査会社が関与しているかどうか、最新のコードが監査されているかどうかなどを確認します。通常、複数の信頼できるセキュリティ会社によって監査されたコードは、攻撃リスクを大幅に低減できます。
第二に、プロジェクトがリアルタイムのセキュリティ監視システムを導入しているかを確認します。監査によるセキュリティ保証は静的なものであり、プロジェクト上場後の動的なセキュリティ問題に対応できません。たとえば、プロジェクトが重要な運用パラメータを不適切に調整したり、新しいプールを追加したりする場合です。リアルタイム監視システムを導入しているプロジェクトは、そのような対策を講じていないプロジェクトよりも運用手順の安全性が高いと言えます。
第三に、緊急時における自動応答能力の有無を確認します。この能力は長らくコミュニティ内で軽視されてきました。複数のセキュリティインシデントで、プロジェクト側が自動的な機能遮断（または資金に関わる操作の遮断）ができていないことがわかりました。緊急時には多くの場合、プロジェクト側は手動で対応していますが、これが非効率的、あるいは無効であることが証明されています。
第四に、プロジェクトの外部依存関係とその堅牢性を確認します。DeFiプロジェクトは、価格や流動性など、第三者プロジェクトが提供する情報を依存しています。したがって、外部依存の数、依存先プロジェクトのセキュリティ、異常データに対する監視とリアルタイム処理の有無などから、プロジェクトの安全性を評価する必要があります。通常、外部依存先が業界トップのプロジェクトであり、異常データに対してフォールトトレランスとリアルタイム処理が可能なプロジェクトの方がより安全です。
第五に、プロジェクトが良好なコミュニティガバナンス構造を持っているかを確認します。これには、重要な出来事に対してコミュニティ投票の仕組みがあるか、重要な操作がマルチシグで行われているか、マルチシグウォレットに中立的なコミュニティメンバーが参加しているか、コミュニティセキュリティ委員会の存在などがあります。このようなガバナンス構造はプロジェクトの透明性を高め、rugpullのリスクを低下させます。
最後に、プロジェクトの過去の履歴も非常に重要です。プロジェクトチームや核心メンバーの背景調査を行う必要があります。もし核心メンバーが過去に何度も攻撃を受けたり、rugpullを行ったなどの悪評がある場合は、そのプロジェクトのセキュリティリスクも相対的に高くなります。
要するに、DeFiプロジェクトに参加する前に、ユーザー、特に大口資金の参加者は、事前のコード監査から上場後のリアルタイム監視、自動応答体制の構築まで、プロジェクト側のセキュリティへの取り組みをしっかり調査し、外部依存、ガバナンス構造、過去の履歴などを踏まえて尽職調査を行い、プロジェクトへの資金投入を安全に保つべきです。
OKX Web3 ウォレットセキュリティチーム：DeFiプロジェクトの安全性を100％保証することはできませんが、以下の次元を組み合わせることで、初期的な安全性やリスクレベルの評価が可能です。
一、プロジェクトの技術的安全性
1、スマートコントラクト監査：
1）複数の監査会社による監査を受けているか、監査会社の評判と経験が十分かを確認。
2）監査報告書に記載された問題の数と深刻度を確認し、すべての問題が修正されていることを確認。
3）プロジェクトが展開したコードが監査されたコードバージョンと一致しているかを確認。
2、コードのオープンソース化：
1）プロジェクトのコードがオープンソースかどうかを確認。オープンソースであれば、コミュニティやセキュリティ専門家がレビューでき、潜在的なセキュリティ問題の発見につながる。
2）開発チームの背景：開発チームの経歴や経験、特にブロックチェーンやセキュリティ分野での実績、透明性や公開情報の程度を把握。
3）バグ賞金プログラム：脆弱性報告を促進するためのバグ賞金プログラムを実施しているか。
3、財務および経済的安全性
1）ロックアップ量：スマートコントラクトにロックされている資金量を確認。高いロックアップ量はプロジェクトへの信頼性が高いことを示す。
2）取引量と流動性：プロジェクトの取引量と流動性を評価。流動性が低いと価格操作のリスクが高まる。
3）トークン経済モデル：トークン分配、インセンティブ制度、インフレモデルなど、トークン経済モデルを評価。例えば、トークン保有が過度に集中していないかなど。
4、運用および管理の安全性
1）ガバナンスメカニズム：プロジェクトのガバナンスメカニズムを理解し、去中心化ガバナンスが存在するか、コミュニティが重要決定に投票できるか、ガバナンストークンの分配と投票権の集中度などを分析。
2）リスク管理策：リスク管理策や緊急対応計画があり、潜在的なセキュリティ脅威や経済攻撃に対処できるか。また、プロジェクトの透明性とコミュニティとのコミュニケーションについて、定期的な進捗報告やセキュリティ更新の発信、ユーザーの問題への積極的な対応などを確認。
5、市場およびコミュニティ評価
1）コミュニティの活性度：プロジェクトのコミュニティの活発さとユーザー基盤を評価。活発なコミュニティは広範な支持があることを意味する。
2）メディアおよびSNSでの評価：メディアやSNSでのプロジェクト評価を分析し、ユーザーおよび業界専門家の意見を把握。
3）パートナーおよび投資家：有名なパートナーや投資家が支援しているかを確認。信頼できるパートナーおよび投資家はプロジェクトの信頼性を高めるが、安全性判断の決定的要因とはならない。
Q4：ユーザーはどのように監査報告書やオープンソース状況を確認すればよいですか？
BlockSecセキュリティチーム：監査を受けたプロジェクトは、通常、公式チャネルを通じてコミュニティに監査報告書を公開しています。こうした報告書は、プロジェクトの公式ドキュメントやGitHubリポジトリなどで確認できます。また、監査報告書の真偽を確認する必要があり、確認方法としては、報告書のデジタル署名を検証したり、監査会社に直接問い合わせて二次確認を行うなどがあります。
では、こうした監査報告書を入手した後、投資家はどのように読めばよいでしょうか？
第一に、監査報告書がOpen Zeppelin、Trail of Bits、BlockSecなど、セキュリティ評判の高い会社によって監査されたかを確認します。
第二に、監査報告書に記載された問題がすべて修正されているかを確認します。未修正の場合は、その理由が十分かどうかを検討します。ここで注意すべきは、監査報告書に記載された脆弱性のうち、有効なものと無効なものを見分けることです。監査報告書には統一された業界標準がないため、各監査会社は独自のセキュリティ認識に基づいて脆弱性のリスク評価と報告を行います。したがって、報告書に記載された脆弱性については、特に有効とされるものを重点的に確認すべきです。このプロセスでは、独立したセキュリティコンサルティングチームを導入し、第三者による独立評価を行うのが望ましいです。
第三に、プロジェクトが公開した監査報告書の監査日と最近のプロジェクト更新日が一致しているか（または近いか）を確認します。また、監査報告書に記載されたプロジェクトのコードが、現在オンラインで稼働しているすべてのコードをカバーしているかも注意が必要です。プロジェクトはコストや時間の都合上、部分的なコードしか監査しないことがあります。そのため、監査されたコードがコアプロトコルのコードかどうかを判断する必要があります。
第四に、プロジェクトがオンラインで稼働しているコードが検証（オープンソース）されているか、そしてそのコードが監査報告書と一致しているかを確認します。通常、監査はプロジェクトのGitHub上のコードを基に行われます（オンチェーンに展開されたコードではありません）。プロジェクトが最終的にオンチェーンに展開したコードをオープンソースにしていない、または監査されたコードと大きく異なる場合は、警戒が必要です。
要するに、監査報告書の読み取りは専門性の高い作業であるため、独立した第三者のセキュリティ専門家に相談することをおすすめします。
OKX Web3 ウォレットセキュリティチーム：ユーザーはDeFiプロジェクトの公式サイトやOKLinkなどの第三者ウェブサイトを通じて、スマートコントラクトの監査報告書やオープンソース状況を確認できます。以下に、監査報告書とオープンソース状況の確認手順を紹介します：
第一に、公式アナウンスまたは公式サイトを探す。信頼できるDeFiプロジェクトの多くは、公式サイトに各種ドキュメント情報を掲載しており、「セキュリティ」「監査」「コントラクトアドレス」などのページで監査報告書や展開済みコントラクトアドレスへのリンクを提供しています。公式サイト以外にも、MediumやTwitterなどの公式SNSで監査報告書やコントラクトアドレスが公開されていることが多いです。
第二に、プロジェクト公式サイトを確認した後、OKLinkブラウザでプロジェクトが提示した展開済みコントラクトアドレスを検索し、「コントラクト」タブで該当アドレスのオープンソースコード情報を確認できます。
第三に、プロジェクトの監査報告書と展開済みコントラクトのオープンソースコード情報を取得したら、監査報告書の読み取りを開始します。その際に注意すべき点は以下の通りです：
1）監査報告書の構成を理解し、内容の概要を把握します。監査報告書はおおむね概要、発見された問題、解決策と提案、監査結果に分けられます。
2）概要を読む際は、監査の範囲と対象に注目します。通常、監査報告書には提出されたファイルのGitHub Commit IDが記載されており、監査対象ファイルがオンチェーンに展開されたオープンソースコードと一致しているかを比較する必要があります。
3）発見された問題、解決策と提案、監査結果の部分を読む際は、プロジェクトチームが提案された通りに脆弱性を修正したか、修正内容について再度監査を受けているかを重点的に確認し、すべての問題が適切に処理されたかを確認します。
4）複数の報告書を比較する。プロジェクトが複数回監査を受けている場合、各監査報告書の違いを確認し、プロジェクトのセキュリティ改善状況を把握します。
Q5：ハッキング攻撃の履歴やバグ賞金プログラムは、DeFiプロジェクトの安全性評価にどのような参考価値がありますか？
OKX Web3 ウォレットセキュリティチーム：ハッキング攻撃の履歴やバグ賞金プログラムは、DeFiプロジェクトの安全性評価において一定の参考価値を持ちます。主に以下の点に現れます：
第一に、ハッキング攻撃の履歴
1）過去の脆弱性の明らか化：攻撃の履歴は、プロジェクトが過去に抱えていた具体的なセキュリティ脆弱性を示し、ユーザーが過去に利用されたセキュリティ問題と、それらが完全に修復されたかどうかを理解する助けになります。
2）リスク管理能力の評価：プロジェクトが過去のセキュリティインシデントにどのように対応したかは、リスク管理および危機対応能力を反映しています。迅速に対応し、脆弱性を速やかに修正し、被害ユーザーに補償を行うプロジェクトは、より信頼できる成熟した投資先と見なされます。
3）プロジェクトの信頼性：頻繁なセキュリティ問題はユーザーの信頼を損ないますが、プロジェクトが失敗から学び、セキュリティ対策を強化する能力を示せれば、長期的な信頼を築くこともできます。
第二に、バグ賞金プログラム
DeFiおよびその他のソフトウェアプロジェクトにおけるバグ賞金プログラムの導入は、セキュリティ向上と潜在的脆弱性の発見の重要な戦略です。これらのプログラムは、プロジェクトの安全性評価に以下のような参考価値をもたらします：
1）外部監査の強化：バグ賞金プログラムは、世界中のセキュリティ研究者がプロジェクトのセキュリティ監査に参加することを促進します。この「クラウドソーシング」型のセキュリティテストは、内部監査では見落とされがちな問題を明らかにし、潜在的脆弱性の発見と解決の機会を増やします。
2）セキュリティ対策の有効性の検証：実際のバグ賞金プログラムを通じて、プロジェクトは自らのセキュリティ対策の有効性を実戦でテストできます。バグ賞金プログラムが長期間継続しているにもかかわらず、重大な脆弱性の報告が少ない場合、これはプロジェクトが比較的成熟し、安全である可能性を示唆しています。
3）継続的なセキュリティ改善：バグ賞金プログラムは継続的な改善の仕組みを提供します。新しい技術や攻撃手法の出現に伴い、プロジェクトチームが最新のセキュリティ課題に対応できるよう、セキュリティ対策を随時更新・強化するのに役立ちます。
4）セキュリティ文化の確立：プロジェクトがバグ賞金プログラムを設けているか、その厳密さや活発さは、プロジェクトチームのセキュリティに対する姿勢を反映しています。積極的なバグ賞金プログラムは、堅固なセキュリティ文化へのコミットメントを示しています。
5）コミュニティおよび投資家への信頼向上：バグ賞金プログラムの存在と成果は、コミュニティや潜在的投資家に対してプロジェクトのセキュリティ重視を証明できます。これによりユーザーの信頼が高まり、投資を惹きつける可能性もあります。投資家は、高度なセキュリティ責任感を示すプロジェクトを好む傾向があります。
Q6：DeFi参加時に、ユーザーはどのように監視・検知能力を構築すればよいですか？
BlockSecセキュリティチーム： ホエールユーザーを例に挙げると、ホエールとは個人投資家または小規模な投資機関を指し、資金規模は大きいものの、強力なセキュリティチームを持たず、独自のセキュリティツールを開発する能力もない場合が多いです。そのため、現時点では、実際の大部分のホエールが十分なリスク検知能力を持っておらず、そうでなければこれほど大きな損失は被らなかったでしょう。
巨額の損失リスクに直面しているため、一部のホエールユーザーは、公開されているセキュリティツールに意識的に依存し始めています。現在、多くのチームが監視製品を開発していますが、どれを選ぶかが非常に重要です。ここにいくつかの重要なポイントがあります：
まず、ツールの使用コストです。多くのツールは非常に強力ですが、プログラミングスキルを必要とするため、使用コストは決して低くありません。ユーザーにとって、コントラクトの構造を理解したり、アドレスを収集したりするのは簡単ではありません。
次に、正確さです。夜中に何度もアラームが鳴って、結局誤検知だったという経験は誰もが避けたいものです。これは精神的に大きな負担になります。したがって、正確さも非常に重要です。
最後に、安全性です。特にこのような資金規模では、ツール開発者およびそのチームのセキュリティリスクを無視できません。最近のGala Game攻撃事件では、安全でない第三者サービスプロバイダーを利用したことが原因と言われています。したがって、信頼できるチームと信頼できる製品が極めて重要です。
現時点で、多くのホエールが私たちに相談に来ており、専門の資産管理ソリューションを紹介しています。これにより、ホエールユーザーは資金の安全性を確保しつつ、日常的な資金管理（「掘って・引き出して・売却」）、リスクの検知、緊急時の資金撤退までを両立できるようになります。
Q7：DeFi参加に関するセキュリティアドバイス、およびリスク対処法
BlockSecセキュリティチーム：大口資金の参加者にとって、DeFiプロトコルに参加する際の最優先事項は元本の安全確保です。可能なセキュリティリスクについて十分に調査した上で投資を行うべきです。通常、以下の点から資金の安全を確保できます。
まず、プロジェクト運営側のセキュリティへの重視と投資の程度を多角的に判断します。前述の徹底的なセキュリティ監査の有無、プロジェクトが安全リスク監視と自動応答能力を備えているか、良好なコミュニティガバナンスメカニズムを持っているかなどです。これらはプロジェクトがユーザーの資金安全をどれだけ重視しているか、ユーザーの資産に対して高い責任感を持っているかを反映しています。
次に、大口資金の参加者自身も、独自のセキュリティ監視と自動応答システムを構築すべきです。投資先のプロトコルでセキュリティインシデントが発生した場合、大口投資家はすぐにそれを検知し、資金を撤退させ、損失を最小限に食い止める必要があります。すべてをプロジェクト側に依存してはいけません。2023年にはCurve、KyberSwap、Euler Financeなど、複数の有名プロジェクトが攻撃を受けましたが、残念ながら、攻撃発生時に大口投資家は適切な情報を得られず、独自の監視や緊急撤退システムを持っていないことがわかりました。
また、投資先のプロジェクトの安全性を継続的に監視する優れたセキュリティパートナーを選択する必要があります。プロジェクトのコードアップデート、重要なパラメータ変更など、すべて即座に検知し、リスクを評価できる必要があります。このような作業は、専門のセキュリティチームやツールなしでは困難です。
最後に、秘密鍵の安全を守ることが不可欠です。頻繁に取引を行うアカウントの場合、オンラインマルチシグとオフライン秘密鍵の安全ソリューションを組み合わせる方法が最善で、単一アドレスや単一秘密鍵の喪失による一点故障リスクを排除できます。
もし投資先のプロジェクトがセキュリティリスクに直面した場合、どのように対処すればよいでしょうか？
どんなホエールや投資家にとっても、セキュリティインシデント発生時の第一反応はまず元本を守ること、つまりできるだけ早く資金を撤退させることが最優先です。しかし、攻撃者の速度は非常に速く、手動操作では間に合わないことが多いので、リスクに基づいて自動的に資金を撤退させる仕組みを持つことが理想です。現在、我々は関連ツールを提供しており、攻撃取引を検知した後、自動的に資金を撤退させ、ユーザーが優先的に退避できるように支援しています。
次に、実際に損失が出た場合、教訓を学ぶだけでなく、プロジェクト側に働きかけ、セキュリティ会社の支援を求め、被害資金の追跡と監視を行うべきです。Crypto業界全体がセキュリティを重視するようになってきたことで、資金回収の割合は徐々に上がっています。
最後に、大口投資家の場合は、セキュリティ会社に依頼して、他の投資先プロジェクトに同様の問題がないかを調査することもできます。多くの攻撃の根本原因は共通しており、例えばCompound V2の精度損失問題は、昨年多くのプロジェクトで同様の問題が発生し、連続して攻撃されました。そのため、セキュリティ会社に依頼して投資ポートフォリオ内の他のプロジェクトのリスクを分析し、リスクが見つかれば、速やかにプロジェクト側と連絡を取り、または資金を引き上げるべきです。
OKX Web3 ウォレットセキュリティチーム：DeFiプロジェクトに参加する際、ユーザーは複数の対策を講じることで、より安全にDeFiに参加し、資金損失のリスクを下げつつ、去中心化金融の恩恵を享受できます。ここでは、ユーザー側とOKX Web3ウォレット側の2つの観点から説明します。
第一に、ユーザー側として：
1）監査済みのプロジェクトを選ぶ：ConsenSys Diligence、Trail of Bits、OpenZeppelin、Quantstamp、ABDKなど、信頼できる第三者監査会社による監査を受けたプロジェクトを優先します。公開されている監査報告書を精査し、潜在的なリスクや脆弱性の修正状況を把握します。
2）プロジェクトの背景とチームを理解する：プロジェクトのホワイトペーパー、公式サイト、開発チームの背景を調査し、透明性と信頼性を確認します。SNSや開発コミュニティでの活動から、技術力とコミュニティサポートを把握します。
3）分散投資：すべての資金を単一のDeFiプロジェクトや資産に集中させず、リスクを分散します。貸し出し、DEX、ファーミングなど、異なるタイプのDeFiプロジェクトに投資することで、リスクを分散できます。
4）小額テスト：大口取引の前に、まず小額のテスト取引を行い、操作やプラットフォームの安全性を確認します。
5）定期的なアカウント監視と緊急対応：定期的に自分のDeFiアカウントと資産をチェックし、異常な取引や活動を早期に発見します。Etherscanなどのツールを使ってオンチェーン取引記録を監視し、資産の安全を確保します。異常を検知した場合は、直ちにアカウントのすべての承認を解除したり、ウォレットセキュリティチームにサポートを依頼するなどの緊急措置を講じます。
6）新規プロジェクトの慎重利用：新しく上場したばかり、または検証されていない新規プロジェクトには慎重になるべきです。まずは少量の資金を投入して試し、運用状況や安全性を観察します。
7）主流のWeb3ウォレットを使用：DeFiプロジェクトとのインタラクションには、主流のWeb3ウォレットのみを使用します。主流のWeb3ウォレットはより優れたセキュリティ保護を提供します。
8）フィッシング攻撃への警戒：見知らぬリンクや信頼できないメールのクリックを避け、信頼できないサイトで秘密鍵やリカバリーフレーズを入力しないようにします。アクセスするリンクが公式サイトであることを確認します。公式チャネルからウォレットやアプリをダウンロードし、ソフトウェアの真正性を保証します。
第二に、OKX Web3ウォレット側として：
ユーザーの資金安全を守るために、多くのセキュリティメカニズムを提供しています：
1）リスクドメイン検出：ユーザーがDAppにアクセスする際、OKX Web3ウォレットはドメインレベルで検出・分析を行い、悪意あるDAppにアクセスしようとした場合はブロックまたは警告を表示し、ユーザーの被害を防ぎます。
2）貔貅盤（ピシャオパン）トークン検出：OKX Web3ウォレットは、貔貅盤トークンの検出機能を完備しており、ウォレット内で貔貅盤トークンを自動的にブロックし、ユーザーがそれらとインタラクションするのを防ぎます。
3）アドレスタグデータベース：OKX Web3ウォレットは豊富なアドレスタグデータベースを提供しており、ユーザーが疑わしいアドレスとインタラクションする際に警告を発します。
4）取引の事前実行シミュレーション：ユーザーが取引を提出する前に、OKX Web3ウォレットはその取引をシミュレーション実行し、資産や承認の変化結果をユーザーに提示します。ユーザーはこの結果を見て期待通りかを判断し、取引を提出するかを決定できます。
5）DeFiアプリの統合：OKX Web3ウォレットは、主要なDeFiプロジェクトのサービスを統合しており、ユーザーは安心してこれらのDeFiプロジェクトとインタラクションできます。また、DEXやクロスチェーンブリッジなどDeFiサービスの最適ルートを推薦し、ユーザーに最良のDeFiサービスと最適なガス手数料案を提供します。
6）その他のセキュリティサービス：OKX Web3ウォレットは、今後もさらに多くのセキュリティ機能を追加し、高度なセキュリティ保護サービスを構築することで、OKXウォレットユーザーの安全をより効果的に守っていきます。
Q8：ユーザーだけでなく、DeFiプロジェクト側が直面するリスクタイプとその防御策は？
BlockSecセキュリティチーム：DeFiプロジェクト側が直面するリスクには、コードセキュリティリスク、運用セキュリティリスク、外部依存リスクがあります。
第一に、コードセキュリティリスク。つまり、DeFiプロジェクトがコードレベルで抱える可能性のあるセキュリティ上の懸念です。DeFiプロジェクトにとって、スマートコントラクトはそのコアビジネスロジック（フロントエンド・バックエンド処理ロジックなどは従来のソフトウェア開発業務に属し、比較的成熟している）であり、私たちが注目し議論する重点です。具体的には以下が挙げられます：
1）まず、開発の観点から、Checks-Effects-Interactionsパターンなど、業界で認められたスマートコントラクトのセキュリティ開発ガイドラインに従う必要があります。また、よく使われる機能は信頼できるサードパーティライブラリをなるべく利用し、不要なリスクを避けるべきです。
2）次に、内部テストを徹底します。テストはソフトウェア開発の重要な環節であり、多くの問題を発見できます。しかし、DeFiプロジェクトの場合、ローカルでのテストだけでは不十分で、実際の上線環境に近い環境でさらにテストを行う必要があります。Phalcon Forkのようなツールを使うことでこれを実現できます。
3）最後に、テスト完了後、評判の良い第三者監査サービスに依頼します。監査は100％の安全を保証しませんが、体系的な監査作業はプロジェクト側が既知の一般的なセキュリティ問題を特定するのを大きく助けます。これらは開発者が不慣れだったり、思考の違いから気づきにくい部分です。当然、各監査会社には専門性や方向性の差があるため、予算に余裕があれば、2社以上に監査を依頼することを推奨します。
第二に、運用セキュリティリスク。つまり、プロジェクト上線後の運用中に発生するセキュリティリスクです。一方で、コードには依然として未知の脆弱性が存在する可能性があります。たとえコードが適切な開発、テスト、監査を経ていても、発見されていないセキュリティ上の懸念が残っている可能性があります。これは数十年にわたるソフトウェア開発のセキュリティ実践で広く証明されています。他方で、コードレベルの問題以外にも、上線後には秘密鍵漏洩、重要なシステムパラメータの誤設定など、重大な結果や巨大な損失を引き起こす可能性があります。運用セキュリティリスクへの対策として以下を推奨します：
1）堅固な秘密鍵管理体制の構築：信頼できるハードウェアウォレットやMPCベースのウォレットソリューションなど、信頼できる方法を採用。
2）稼働状態の監視：システムが特権的操作やプロジェクトの稼働状態のセキュリティをリアルタイムで感知。
3）リスクに対する自動応答メカニズムの構築：たとえばBlockSec Phalconを使えば、攻撃を受けた際に自動的に遮断し、（さらなる）損失を回避できます。
4）特権操作の一点故障リスクを回避：Safeマルチシグウォレットを使って特権操作を実行。
第三に、外部依存リスク。プロジェクトが外部依存によって引き起こされるリスクです。たとえば、他のDeFiプロトコルが提供する価格オラクルに依存しているが、オラクルに問題が発生し、価格計算に誤った結果が出るなどです。外部依存リスクへの対策として以下を推奨します：
1）信頼できる外部パートナーを選ぶ：業界で認められた信頼できるトッププロトコルなどを選
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
OKX
