セキュリティ特集05|OKX Web3 BlockSec:@All Giant Whales、DeFi界の最新リスク回避戦略

avatar
欧易OKX
4ヶ月前
本文は約19635字で,全文を読むには約25分かかります
ブロックチェーンセキュリティの先駆者である BlockSec と OKX Web3 ウォレットセキュリティチームは、「巨大なクジラ」になろうとしている、またはすでになっているすべてのユーザーとプロジェクト開発者に対する実践的なガイドの観点から、DeFi リスク回避戦略を共有するために特別に招待されています。

はじめに: OKX Web3 ウォレットは、さまざまな種類のオンチェーン セキュリティ問題に対する特別な回答を提供するために、「セキュリティ特別問題」コラムを特別に企画しました。ユーザーの身近で起こっている最も現実的な事例を通じて、セキュリティ分野の専門家や機関と連携し、さまざまな視点からの疑問を共有・回答することで、安全な取引ルールを浅いところから深いところまで整理・まとめ、ユーザーの安全性の強化を目指します。ユーザーが秘密鍵とウォレット資産のセキュリティを自分から守る方法を学ぶための教育と支援。

DeFi世界の最大の魅力は、誰もが「巨大なクジラ」になれる可能性を持っていること

しかし、「巨大なクジラ」ですら、肉を食べることはできますが、時には「殴られる」こともあります。

したがって、チェーンで遊ぶときは安全が第一です

そうしないと、また最初から始めなければなりません~

今号は、ブロックチェーンセキュリティのパイオニアである BlockSec と OKX Web3 ウォレットのセキュリティ チームを特別に招いて、これからそうなる、またはそうなるすべてのユーザーとプロジェクト関係者に向けた実践的なガイドの観点から、セキュリティ特集号の第 5 回目です。 「巨大なクジラ」。DeFi ヘッジ ガイド。たとえば、監査レポートの読み方、DeFi プロジェクトのリスク、プロジェクト関係者またはクジラユーザーの事前評価に一般的に使用される指標とパラメーター、監視意識機能の構築方法、DeFi セキュリティ保護ルールなど...お見逃しなく!

セキュリティ特集05|OKX Web3  BlockSec:@All Giant Whales、DeFi界の最新リスク回避戦略

BlockSec セキュリティ チーム: BlockSec は、世界をリードする「フルスタック」ブロックチェーン セキュリティ サービス プロバイダーであり、現在、MetaMask、Compound、Uniswap Foundation、Forta、PancakeSwap、Puffer、ホワイトハットを通じて、救出活動により 2,000 万ドル以上の経済的損失が回復されました。

BlockSec の CEO 兼共同創設者である Zhou Yajin は、浙江大学のコンピューター教授であり、アミナーによって選ばれた世界で最も影響力のある学者であり、50 以上のトップ論文を発表し、10,000 以上の引用を受けています。 CTO 兼共同創設者である Wu Lei は、浙江大学のコンピューター教授であり、Paidun の元共同創設者であり、複数の有名なプロジェクトで数十のゼロデイ脆弱性を発見するチームを率いました。プロダクト ディレクターの Raymond は、Tencent と 360 でセキュリティ製品を担当してきました。

OKX Web3 ウォレット セキュリティ チーム:皆さん、こんにちは。このことを共有できることをとても嬉しく思います。 OKX Web3 セキュリティ チームは、スマート コントラクト セキュリティ監査、ウォレット セキュリティ機能構築、オンチェーン プロジェクト セキュリティ監視など、Web3 分野における OKX のさまざまなセキュリティ機能の構築を主に担当し、ユーザーに複数の側面を提供します。製品セキュリティ、資金セキュリティ、トランザクションセキュリティなどの保護サービスは、ブロックチェーン全体のセキュリティエコロジーの維持に貢献します。

Q1: ユーザーが実際に遭遇したいくつかの DeFi リスク事例を共有する

BlockSecセキュリティチーム: DeFiは比較的安定して資産に高い収益をもたらすため、多くの大規模投資家が参加するようになっています。流動性を高めるために、多くのプロジェクト当事者も大口投資家を積極的に誘致するだろう。例えば、一部の大規模投資家がDeFiに巨額の資産を預けているというニュース報道をよく目にします。もちろん、これらの巨大なクジラは、安定した収益を得ることに加えて、DeFiプロジェクトに参加する際にいくつかのリスクにも直面します。次に、業界における公的 DeFi リスク事例をいくつか紹介します。

ケース 1: 2022 年の PolyNetwork セキュリティ インシデントでは、総額 6 億ドルを超える資産が攻撃されました。神宇もその中に1億ドルを持っていたと言われているが、その後襲撃者はその金を返済し事件は無事解決したが、神宇はこの事件を記念して鎖に記念碑を建てると発表したが、この手続きは必ず行わなければならない。とても痛かったです。現在発生している少数のセキュリティ インシデントは良い結果をもたらしていますが、大部分はそれほど幸運ではありません。

ケース 2: 有名な DEX SushiSwap が 2023 年に攻撃されました。大規模ユーザー 0x Sifu は 330 万米ドル以上を失い、彼の損失だけで損失総額の約 90% を占めました。

ケース 3: 今年 3 月の Prisma セキュリティ インシデントでは、損失総額は 1,400 万米ドルで、これらの損失は 17 のウォレット アドレスから発生し、ウォレットあたりの平均損失は 82 万米ドルでしたが、損失の 80% は 4 人のユーザーで占められました。これらの盗難された資産のほとんどはまだ回収されていません。

最終的には、DeFi、特にメインネットワーク上の DeFi はガス手数料を無視できないため、資産が一定の規模に達した場合にのみ実際に利益を得ることができます (エアドロップ報酬を除く)。したがって、DeFi プロジェクトのメイン TVL が重要になります。通常、巨大なクジラが貢献しており、一部のプロジェクトでは、2% のクジラが TVL の 80% に貢献しています。安全保障上のインシデントが発生した場合、これらの巨大なクジラが損失のほとんどを負うことは避けられません。 「巨大なクジラが肉を食べるのを見るだけではなく、時には殴られることもあります。」

OKX Web3ウォレットセキュリティチーム:オンチェーン世界の繁栄と発展に伴い、ユーザーが遭遇するDeFiリスクケースも日々増加しています。オンチェーンセキュリティは常にユーザーにとって最も基本的かつ重要なニーズです。

事例 1: PlayDapp 特権アカウントの秘密鍵漏洩事件。 2024 年 2 月 9 日から 12 日にかけて、イーサリアム ベースの PlayDapp ゲーム プラットフォームが秘密キーの漏洩により攻撃され、攻撃者は 17 億 9,000 万の PLA トークンを不正に鋳造し、盗み、約 3,235 万米ドルの損失をもたらしました。攻撃者は、PLA トークンに新しいミンターを追加し、大量の PLA を鋳造して、複数のオンチェーン アドレスと取引所に分散させました。

ケース 2: ヘッジファイナンス攻撃。 2024 年 4 月 19 日、Hedgey Finance はイーサリアムとアービトラムで大規模なセキュリティ侵害を受け、約 4,470 万ドルの損失をもたらしました。攻撃者は、コントラクトにユーザー入力検証がないことを利用して、脆弱なコントラクトへの承認を取得し、それによってコントラクトから資産を盗みます。

Q2: 現在 DeFi 分野に存在する主なリスクの種類を要約していただけますか?

OKX Web3 ウォレット セキュリティ チーム:実際の事例に基づいて、現在の DeFi 分野における 4 つの一般的なリスク タイプを整理しました

カテゴリ 1: フィッシング攻撃。フィッシング攻撃は、正当な組織または個人になりすまして被害者をだまして秘密キー、パスワード、その他の個人データなどの機密情報を提供させる一般的なタイプのサイバー攻撃です。 DeFi 分野では、フィッシング攻撃は通常次の方法で実行されます。

1) 偽の Web サイト: 攻撃者は、実際の DeFi プロジェクトに似たフィッシング Web サイトを作成し、ユーザーをだまして認証や転送トランザクションに署名させます。

2) ソーシャル エンジニアリング攻撃: Twitter では、攻撃者は高度な模倣アカウントを使用したり、プロジェクト チームの Twitter または Discord アカウントを乗っ取って、偽のプロモーションやエアドロップ情報 (実際にはフィッシング リンク) を公開して、ユーザーに対してフィッシング攻撃を実行します。

3) 悪意のあるスマート コントラクト: 攻撃者は、一見魅力的なスマート コントラクトまたは DeFi プロジェクトを公開して、ユーザーをだましてアクセス権を許可させ、それによって資金を盗みます。

カテゴリ 2: ラグプル。ラグプルとは、多額の投資を集めた後、プロジェクト開発者が突然資金を引き出して失踪し、投資家の資金をすべて流してしまうというDeFi分野の特殊な詐欺のことを指します。ラグプルは通常、分散型取引所 (DEX) や流動性マイニング プロジェクトで発生します。主な症状には次のものがあります。

1) 流動性の引き出し: 開発者はユーザーの投資を誘致するために流動性プールに大量の流動性を提供し、その後突然すべての流動性を引き出します。これにより、トークン価格が急落し、投資家が多額の損失を被ることになります。

2) 偽のプロジェクト: 開発者は一見正当な DeFi プロジェクトを作成し、虚偽の約束と高い利益を通じてユーザーを投資に誘導しますが、実際には実際の製品やサービスはありません。

3) 契約権限の変更: 開発者はいつでもバックドアやスマート コントラクトの権限を使用して、契約のルールを変更したり、資金を引き出したりすることができます。

カテゴリ 3: スマート コントラクトの脆弱性。スマート コントラクトはブロックチェーン上で実行される自己実行コードであり、一度デプロイすると変更することはできません。スマートコントラクトに抜け穴があると、重大なセキュリティ問題が発生します。一般的なスマート コントラクトの脆弱性には次のものがあります。

1) 再入可能性の脆弱性: 攻撃者は、最後の呼び出しが完了する前に脆弱なコントラクトを繰り返し呼び出し、コントラクトの内部状態に問題を引き起こします。

2) ロジック エラー: 契約の設計または実装におけるロジック エラー。予期しない動作や脆弱性につながります。

3) 整数オーバーフロー: コントラクトが整数演算を正しく処理しないため、オーバーフローまたはアンダーフローが発生します。

4) 価格操作: 攻撃者は、オラクル マシンの価格を操作することによって攻撃を実行します。

5) 精度の損失: 浮動小数点または整数の精度の問題による計算エラー。

6) 入力検証の欠如: ユーザー入力が完全に検証されていないため、潜在的なセキュリティ問題が発生します。

カテゴリー 4: ガバナンス リスク。ガバナンス リスクは、プロジェクトの中核となる意思決定と制御メカニズムに関係しており、悪意を持って使用されると、プロジェクトが期待された目標から逸脱し、深刻な経済的損失や信頼危機につながる可能性があります。一般的なリスクには次のような種類があります。

1) 秘密鍵の漏洩

一部の DeFi プロジェクトの特権アカウントは、EOA (外部所有アカウント) またはマルチ署名ウォレットによって制御されており、これらの秘密鍵が漏洩または盗まれた場合、攻撃者は契約や資金を自由に操作できます。

2) ガバナンス攻撃

一部の DeFi プロジェクトは分散型ガバナンス ソリューションを採用していますが、依然として次のリスクがあります。

·ガバナンス トークンの借用: 攻撃者は、大量のガバナンス トークンを借用して投票結果を短期間に操作します。

·多数決の投票権を制御する: ガバナンス トークンが少数の人々の手に高度に集中している場合、これらの人々は集中した投票権を通じてプロジェクト全体の意思決定を制御することができます。

Q3: DeFiプロジェクトのセキュリティとリスクレベルを最初に評価するためにどのような次元やパラメータを使用できますか?

BlockSecセキュリティチーム: DeFiプロジェクトに参加する前に、プロジェクト全体のセキュリティ評価を実施することが非常に必要です。特に比較的多額の資金を保有する参加者の場合、必要なセキュリティデューデリジェンスにより資金の安全性を最大限に確保できます。

セキュリティ特集05|OKX Web3  BlockSec:@All Giant Whales、DeFi界の最新リスク回避戦略

まず、プロジェクト当事者が監査を受けているかどうか、セキュリティの評判が良い監査会社によって監査されているかどうか、複数の監査会社が関与しているかどうか、プロジェクトのコードセキュリティの包括的な評価を行うことをお勧めします。最新のコードは監査済みなど。一般に、オンラインで実行されているコードがセキュリティの評判が良い複数のセキュリティ会社によって監査されていれば、セキュリティ攻撃のリスクは大幅に軽減されます。

次に、プロジェクト当事者がリアルタイムのセキュリティ監視システムを導入しているかどうかによって異なります。セキュリティ監査によって保証されるセキュリティは静的なものであり、プロジェクトがオンラインになった後に発生する動的なセキュリティ問題を解決することはできません。たとえば、プロジェクト関係者がプロジェクトの主要な動作パラメータを不適切に調整したり、新しいプールを追加したりしました。プロジェクト当事者が何らかのリアルタイムセキュリティ監視システムを採用している場合、その運用中の安全率は、そのようなソリューションを採用していないプロトコルよりも高くなります。

第三に、プロジェクト当事者が緊急事態に自動的に対応する能力を持っているかどうかに依存します。この機能はコミュニティによって長い間無視されてきました。複数のセキュリティインシデントで、プロジェクト側が自動機能サーキットブレーカー(または資金が重要な業務用のサーキットブレーカー)を実装できていないことが判明しました。プロジェクト関係者は、緊急時のセキュリティ インシデントに対処するために主に手動の方法を使用しますが、この方法は非効率的であるか、非効果的であることが判明しています。

4 番目に、プロジェクト関係者の外部依存関係と外部依存関係の堅牢性に依存します。 DeFi プロジェクトは、価格や流動性など、サードパーティのプロジェクトによって提供される情報に依存します。そのため、外部依存関係の数、外部依存プロジェクトのセキュリティ、外部依存関係の異常データの監視とリアルタイム処理の有無などの観点からプロジェクトのセキュリティを評価する必要があります。一般に、外部に依存するプロジェクト パーティが先頭のプロジェクト パーティであり、耐障害性があり、外部プロジェクトからの異常データをリアルタイムに処理できるプロジェクトの方が安全です。

第五に、プロジェクト当事者が比較的良好なコミュニティガバナンス構造を持っているかどうか。これには、プロジェクト当事者に主要なイベントに対するコミュニティ投票メカニズムがあるかどうか、機密性の高い操作がマルチシグネチャで完了するかどうか、マルチシグネチャウォレットがコミュニティ中立的な参加を導入するかどうか、コミュニティ安全委員会があるかどうかなどが含まれます。これらのガバナンス構造により、プロジェクトの透明性が向上し、プロジェクトにおけるユーザーの資金が不正に利用される可能性が軽減されます。

最後に、プロジェクトパーティーの過去の歴史も非常に重要です。プロジェクト チームとプロジェクトのコア メンバーのバックグラウンド チェックが必要です。プロジェクト チームの中心メンバーが何度も攻撃を受けていたり、過去のプロジェクトでラグプルなどの悪い履歴があった場合、そのようなプロジェクトのセキュリティ リスクは比較的高くなります。

つまり、DeFiプロジェクトに参加する前に、ユーザー、特に大資本の参加者は、プロジェクトがオンラインになる前のコードセキュリティ監査から、プロジェクト開始後のリアルタイムのセキュリティ監視と自動応答機能の構築に至るまで、十分なリサーチを行う必要があります。プロジェクトへの投資資金の安全性を確保するためには、外部依存性、ガバナンス体制、プロジェクト当事者の過去の歴史などの観点から、プロジェクト側の安全性を検討し、投資とセキュリティの調整作業を行う必要があります。

OKX Web3 ウォレット セキュリティ チーム: DeFi プロジェクトのセキュリティを 100% 保証することはできませんが、ユーザーは最初に次の要素を組み合わせて DeFi プロジェクトのセキュリティとリスク レベルを評価できます。

1. プロジェクトの技術的安全性

1. スマートコントラクトの監査:

1) プロジェクトが複数の監査会社の監査を受けているかどうか、監査会社の評判や経験が優れているかどうかを確認します。

2) 監査レポートで報告された問題の数と重大度をチェックし、すべての問題が解決されていることを確認します。

3) プロジェクトによってデプロイされたコードが、監査されたコードのバージョンと一致しているかどうかを確認します。

2. オープンソースコード:

1) プロジェクトのコードがオープン ソースであるかどうかを確認します。オープン ソース コードを使用すると、コミュニティやセキュリティの専門家がコードをレビューできるため、潜在的なセキュリティ問題の発見に役立ちます。

2) 開発チームの背景: プロジェクト開発チームの背景と経験、特にブロックチェーンとセキュリティ分野での経験、およびチームの透明性とオープンな情報のレベルを理解します。

3) バグ報奨金プログラム: プロジェクトには、セキュリティ研究者に脆弱性を報告するよう奨励するバグ報奨金プログラムがありますか?

3. 財政的および経済的安全性

1) ロックされている資金の量: スマート コントラクトにロックされている資金の量を確認します。ロックアップが高いほど、プロジェクトの信頼度が高いことを意味します。

2) 取引量と流動性: プロジェクトの取引量と流動性を評価します。流動性が低いと、価格操作のリスクが高まる可能性があります。

3) トークン経済モデル: トークンの配布、インセンティブ メカニズム、インフレ モデルなど、プロジェクトのトークン経済モデルを評価します。例えば、トークン保有の過度の集中がないか等。

4. 運用管理のセキュリティ

1) ガバナンスメカニズム: プロジェクトのガバナンスメカニズム、分散型ガバナンスメカニズムの有無、重要な決定についてコミュニティが投票できるかどうかを理解し、ガバナンストークンの分布や投票権の集中などを分析します。

2) リスク管理措置: プロジェクトにはリスク管理措置と緊急計画があり、潜在的な安全保障上の脅威や経済攻撃にどのように対処するか。また、プロジェクトの透明性やコミュニティコミュニケーションの観点からは、プロジェクト当事者が定期的にプロジェクトの進捗レポートやセキュリティアップデートを公開しているか、コミュニティと積極的にコミュニケーションをとってユーザーの問題を解決しているかなどを見ることができます。

5. 市場およびコミュニティの評価

1) コミュニティ活動: プロジェクトのコミュニティ活動とユーザー ベースを評価します。活発なコミュニティは、通常、プロジェクトに広範なサポートがあることを意味します。

2) メディアとソーシャルメディアの評価: プロジェクトに対するユーザーや業界専門家の意見を理解するために、メディアとソーシャルメディアでのプロジェクトの評価を分析します。

3) パートナーと投資家: プロジェクトが著名なパートナーや投資家によってサポートされているかどうかを確認します。評判の良いパートナーや投資家はプロジェクトの信頼性を高めることができますが、それが安全性を判断する決定的な要因にはなりません。

Q4: ユーザーは監査レポートやオープンソースのステータスなどをどのように見るべきですか?

BlockSec セキュリティ チーム:監査済みのプロジェクトについては、通常、プロジェクト チームが率先して公式チャネルを通じて監査レポートをコミュニティに公開します。これらの監査レポートは通常、プロジェクト チームのドキュメント、Github コード リポジトリ、およびその他のチャネルにあります。また、監査報告書の電子署名の確認や監査会社への二次確認など、監査報告書の真正性を確認する必要があります。

では、投資家はそのような監査報告書を受け取った後、どのように調査するのでしょうか?

まず、監査報告書が、Open Zeppelin、Trail of Bits、BlockSec およびその他の大手監査会社など、比較的セキュリティの評判が高いセキュリティ会社によって監査されているかどうかによって異なります。

第二に、監査報告書に記載された問題が修復されたかどうかに依存し、修復されていない場合は、プロジェクト当事者が修復しない理由が十分であるかどうかに依存します。監査レポートでは、有効な脆弱性レポートと無効な脆弱性レポートを区別する必要もあります。監査レポートには統一された業界標準がないため、セキュリティ監査会社は独自のセキュリティ認識に基づいてプロジェクトの脆弱性リスクの評価とレポートを実施します。したがって、監査レポートで見つかった脆弱性について効果的な脆弱性レポートを作成することに重点を置きます。このプロセス中に第三者による独立した評価を実施するために、独自のセキュリティ コンサルティング チームを派遣することが最善です。

第三に、プロジェクト当事者によって発行された監査レポートの監査時間が最新のプロジェクトのアップグレードおよび更新時間と一致している (または近い) かどうかに依存します。また、プロジェクト当事者のコードにも注意を払う必要があります。監査レポートには、プロジェクト関係者の現在オンラインのコードがすべて含まれます。経済的コストと時間的コストを考慮して、プロジェクト関係者は通常、部分的なコード監査を実施します。したがって、この場合、監査対象のコードがコアプロトコルコードであるかどうかを判断する必要があります。

第 4 に、プロジェクト側がオンラインで実行しているコードが検証されているか (オープンソース)、検証されたコードが監査報告書と一致しているかどうかによって異なります。通常、監査は (オンラインでデプロイされたコードではなく) Github 上のプロジェクトのコードに基づいて行われます。プロジェクトが最終的にチェーンにデプロイするコードがオープンソースでない場合、または監査対象のコードと大きく異なる場合、これは注意が必要な点です。

つまり、監査報告書を読むこと自体は比較的専門的な問題であり、プロセス中にコンサルティング意見を提供する独立したサードパーティのセキュリティ専門家を紹介することが推奨されます。

OKX Web3 ウォレット セキュリティ チーム:ユーザーは、DeFi プロジェクトの公式 Web サイトまたは OKLink などのサードパーティ Web サイトを通じて、監査レポートとスマート コントラクトのオープンソース ステータスを確認できます。 以下に、プロジェクト監査を確認するための一般的な手順について説明します。レポートとオープンソースのステータス:

まず、公式発表またはウェブサイトを探します。信頼できる DeFi プロジェクトのほとんどは、公式 Web サイトに関連する文書情報を表示します。プロジェクト文書ページには、通常、監査レポートとプロジェクト チームの契約にリンクする「セキュリティ」、「監査」、または「契約アドレス」ページがあります。住所。プロジェクトの公式 Web サイトに加えて、通常は監査レポートや展開された契約アドレス情報も Medium や Twitter などの公式ソーシャル メディアに表示されます。

次に、プロジェクト当事者の公式 Web サイトを読んだ後、OKLink ブラウザを通じてプロジェクト当事者から提供されたデプロイされたコントラクトのアドレス情報を照会し、このアドレスにデプロイされたコントラクトのオープンソース コード情報を「契約」列に表示できます。 。

第三に、プロジェクト パーティの監査レポートと展開契約のオープン ソース コード情報を取得したら、プロジェクト パーティの監査レポートを読み始めることができます。監査レポートを読むときは、次の点に注意する必要があります。

1) 監査報告書の構成を理解し、監査報告書の内容は大きく分けて「序論」、「発見された問題点」、「解決策と提案」、「監査結果」に分かれています。

2) はじめにを読むときは、監査レポートの範囲と目的に注意する必要があります。通常、監査レポートには監査ファイル提出の Github コミット ID がマークされます。監査レポートで監査されたファイルかどうかを比較する必要があります。チェーン上にデプロイされたオープンソース コードと一致しています。

3) 発見された問題、解決策と提案、および監査結果を読むときは、プロジェクト チームが発見された脆弱性を推奨どおりに修正したかどうか、またプロジェクト パーティが修正された内容についてフォローアップ監査を実施して確実に実行したかどうかに焦点を当てる必要があります。すべての問題が適切に処理されたこと。

4) 複数のレポートを比較します。プロジェクトが複数回監査されている場合は、各監査レポートの違いを確認して、プロジェクトのセキュリティの向上を理解してください。

Q5: DeFiプロジェクトの安全性に対するハッカー攻撃履歴と報奨金プログラムの基準値はどれくらいですか?

OKX Web3 ウォレット セキュリティ チーム:ハッカーの攻撃履歴と報奨金プログラムは、DeFi プロジェクトのセキュリティ評価に一定の参考値を提供し、主に次の側面に反映されます。

まず、ハッカー攻撃の歴史

1) 過去の脆弱性を明らかにする: 攻撃履歴にはプロジェクトに存在した特定のセキュリティ脆弱性が表示され、ユーザーは過去にどのセキュリティ問題が悪用されたのか、またそれらの問題が完全に修復されたかどうかを理解できるようになります。

2) リスク管理能力を評価する: 過去のセキュリティ インシデントにプロジェクトがどのように対応するかは、そのリスク管理能力と危機対応能力を反映することができます。一般に、プロアクティブに対応し、タイムリーに脆弱性を修正し、影響を受けるユーザーに補償を行うプロジェクトは、より信頼性が高く成熟した投資オプションとみなされます。

3) プロジェクトの信頼性: 頻繁にセキュリティ問題が発生すると、プロジェクトに対するユーザーの信頼が損なわれる可能性がありますが、プロジェクトが間違いから学習し、セキュリティ対策を強化する能力を実証できれば、長期的な信頼性も築くことができます。

第二に、報奨金プログラム

DeFi やその他のソフトウェア プロジェクトにおける報奨金プログラムの導入は、セキュリティを向上させ、潜在的な脆弱性を発見するための重要な戦略です。これらの計画は、プロジェクトの安全性評価にさまざまな参考値をもたらします。

1) 外部監査の強化: 報奨金プログラムは、世界中のセキュリティ研究者がプロジェクトのセキュリティ監査に参加することを奨励します。このセキュリティ テストへの「クラウドソーシング」アプローチにより、内部監査で見落とされた可能性のある問題が明らかになり、潜在的な脆弱性を発見して解決できる可能性が高まります。

2) セキュリティ対策の有効性を検証する: 実際の報奨金プログラムを通じて、プロジェクトは実際の戦闘でセキュリティ対策の有効性をテストできます。プロジェクトの報奨金プログラムが長くても、深刻な脆弱性の報告が少ない場合、これはプロジェクトが比較的成熟していて安全であることを示している可能性があります。

3) 継続的なセキュリティ改善: 報奨金プログラムは、継続的な改善のためのメカニズムを提供します。新しいテクノロジーや新しい攻撃方法が出現するにつれて、報奨金プログラムはプロジェクト チームがセキュリティ対策をタイムリーに更新および強化し、プロジェクトが最新のセキュリティ課題に確実に対応できるように支援します。

4) 安全文化を確立する: プロジェクトに報奨金プログラムがあるかどうか、またプログラムの真剣さと活動は、安全に対するプロジェクト チームの態度を反映する可能性があります。活発な報奨金プログラムは、強固なセキュリティ文化の構築に対するプロジェクトの取り組みを示しています。

5) コミュニティと投資家の信頼の向上: 報奨金プログラムの存在と有効性は、プロジェクトがセキュリティを非常に重視していることをコミュニティと潜在的な投資家に証明できます。これによりユーザーの信頼が高まるだけでなく、投資家は高いレベルのセキュリティ責任を示すプロジェクトを選択する傾向があるため、より多くの投資を呼び込む可能性があります。

Q 6: ユーザーは DeFi に参加する際、モニタリングと認識機能をどのように構築しますか?

BlockSec セキュリティ チーム:クジラ ユーザーを例に挙げると、巨大なクジラは主に小規模なチームを持つ個人投資家や投資機関を指しますが、通常はあまり強力なセキュリティ チームや自社開発のセキュリティ ツールを持っていません。したがって、これまでのところ、ほとんどの巨大クジラは実際には十分なリスク認識を持っていません。そうでなければ、これほど大きな損失を被ることはありません。

巨額の損失のリスクに直面して、一部のクジラ利用者は、リスクを監視し感知するために、意識的にいくつかの公共のセキュリティツールに依存し始めました。現在、モニタリング製品を作成しているチームは数多くありますが、どのように選択するかが非常に重要です。いくつかの重要なポイントを次に示します。

まず、ツールの使用にはコストがかかります。多くのツールは非常に強力ですが、プログラミングが必要であり、使用するのは安価ではありません。ユーザーが契約の構造を理解し、アドレスを収集することさえ簡単ではありません。

2番目に精度です。夜寝ているときに複数のアラームを続けて受信した後で、それが誤ったアラームであることが判明してイライラすることは誰も望んでいません。したがって、精度も非常に重要です。

最後にセキュリティです。特にこの規模の資金では、ツール開発とそのチームのさまざまなセキュリティ リスクを無視することはできません。最近のGala Game攻撃事件は、安全でないサードパーティサービスプロバイダーの導入が原因であると言われています。したがって、信頼できるチームと信頼できる製品が重要です。

これまで多くのクジラが当社に来ており、クジラ利用者が資金の安全性を確保するだけでなく、「掘る・育てる・育てる」といった日常の資金管理も考慮したプロの資産管理ソリューションをご提案してまいります。緊急事態宣言下では資金の引き出しも。

セキュリティ特集05|OKX Web3  BlockSec:@All Giant Whales、DeFi界の最新リスク回避戦略

Q7: DeFi に参加するためのセキュリティに関する推奨事項とセキュリティ リスクへの対処方法

BlockSecセキュリティチーム:多額の資金を持っている参加者にとって、DeFiプロトコルに参加する最初のことは、本人の安全を確保し、起こり得るセキュリティリスクについて比較的徹底的に調査した上で投資を行うことです。資金の安全性は通常、以下の側面から確保されます。

まず、プロジェクト当事者の安全重視と投資レベルを多面的に判断する必要があります。前述した比較的徹底的なセキュリティ監査を受けているかどうか、プロジェクト当事者がプロジェクトのセキュリティ リスク監視と自動対応機能を備えているかどうか、比較的良好なコミュニティ ガバナンス メカニズムを備えているかどうかなどが含まれます。これらすべては、プロジェクト当事者がユーザー資金の安全性を非常に重視しているかどうか、またユーザー資金の安全性に対して非常に責任ある態度をとっているかどうかを反映することができます。

第二に、多額の資金を持つ参加者は、独自のセキュリティ監視システムと自動応答システムを構築する必要もあります。投資契約においてセキュリティインシデントが発生した後、多額の資金を保有する投資家は、プロジェクト当事者にすべての期待を託すのではなく、即座にそれを察知し、可能な限り損失を回収するために資金を引き上げることができるべきである。 2023 年には、Curve、KyberSwap、Euler Finance など、多くの有名なプロジェクトが攻撃されたことがわかります。残念ながら、攻撃が発生した場合、大規模投資家はタイムリーで効果的な情報を欠いていることが多く、独自のセキュリティ監視システムや緊急避難システムを備えていないことがわかりました。

さらに、投資家は、投資プロジェクト対象のセキュリティに継続的に注意を払うために、より優れたセキュリティパートナーを選択する必要があります。プロジェクト チームのコードのアップグレードであっても、重要なパラメータの変更であっても、リスクをタイムリーに認識し、評価する必要があります。専門のセキュリティ チームとツールの参加なしでは、このようなことを達成することは困難です。

最後に、秘密キーを保護する必要があります。頻繁なトランザクションが必要なアカウントの場合は、オンラインのマルチ署名とオフラインの秘密キーのセキュリティ ソリューションを組み合わせて使用し、単一のアドレスと単一の秘密キーを失った後のシングルポイント リスクを排除するのが最善です。

投資プロジェクトが安全上のリスクに直面した場合、どうすべきでしょうか?

巨大なクジラや投資家にとって、セキュリティインシデントに遭遇したときの最初の反応は、まず資本を保護することであり、できるだけ早く売却することが最優先事項であると私は信じています。しかし、攻撃者は非常に素早く行動することが多く、手動操作では遅すぎることが多いため、リスクに基づいて資金を自動的に引き出すことができるのが最善です。現在、攻撃取引を発見した後に資金を自動的に引き出すことができる関連ツールを提供しており、ユーザーが最初に避難できるよう支援しています。

第二に、実際に損失が発生した場合、教訓を学ぶことに加えて、プロジェクト当事者は、損害を受けた資金を追跡および監視するためにセキュリティ会社に支援を求めるようプロジェクト当事者に積極的に奨励する必要があります。仮想通貨業界全体がセキュリティを重視しているため、回収される資金の割合は徐々に増加しています。

最後に、あなたが大規模な投資家の場合は、投資している他のプロジェクトに同様の問題がないかどうかを調査するよう証券会社に依頼することもできます。 Compound V2 の精度損失の問題など、多くの攻撃の根本原因は同じです。昨年、多くのプロジェクトが同様の問題を抱え、継続的に攻撃を受けていました。したがって、投資ポートフォリオ内の他のプロジェクトのリスク分析を証券会社に依頼することができます。リスクが発見された場合は、プロジェクト当事者に連絡するか、できるだけ早く撤退する必要があります。

OKX Web3ウォレットセキュリティチーム: DeFiプロジェクトに参加する際、ユーザーはより安全にDeFiプロジェクトに参加し、キャピタルロスのリスクを軽減し、分散型金融のメリットを享受するためのさまざまな措置を講じることができます。ユーザー レベルと OKX Web3 ウォレットの 2 つのレベルから始めます。

まずユーザー向け:

1) 監査済みプロジェクトの選択: 有名なサードパーティ監査会社 (ConsenSys Diligence、Trail of Bits、OpenZeppelin、Quantstamp、ABDK など) によって監査済みのプロジェクトを優先し、その公開監査報告書を確認し、潜在的なリスクと脆弱性を理解します。修理。

2) プロジェクトの背景とチームを理解する: プロジェクトのホワイト ペーパー、公式 Web サイト、開発チームの背景を調査して、プロジェクトが透明性と信頼性があることを確認します。ソーシャル メディアや開発コミュニティでのチームの活動をフォローして、その技術的能力とコミュニティ サポートについて学びましょう。

3) 分散投資: 単一の DeFi プロジェクトまたは資産にすべての資金を投資しないでください。分散投資によりリスクを軽減できます。融資、DEX、農業など、複数の異なるタイプの DeFi プロジェクトから選択して、リスク エクスポージャを分散します。

4) 少額テスト: 運用とプラットフォームのセキュリティを確保するために、大額取引の前に少額テスト取引を実施します。

5) アカウントと緊急対応を定期的に監視する: DeFi アカウントと資産を定期的にチェックして、異常な取引や活動をタイムリーに発見します。ツール (Etherscan など) を使用してオンチェーンのトランザクション記録を監視し、資産のセキュリティを確保します。異常を検出したら、アカウントのすべての権限を取り消す、ウォレットセキュリティチームに連絡してサポートを求めるなど、タイムリーに緊急措置を講じてください。

6) 新しいプロジェクトは注意して使用してください。開始されたばかりの新しいプロジェクトや検証されていない新しいプロジェクトには注意してください。最初に少額の資金を投資して、その動作と安全性を観察するテストを行うことができます。

7) トランザクションには主流の Web3 ウォレットを使用する: DeFi プロジェクトと対話する場合には、主流の Web3 ウォレットのみを使用すると、より優れたセキュリティ保護が提供されます。

8) フィッシング攻撃を防ぐ: 見慣れないリンクや不明な送信元からの電子メールをクリックする場合は注意し、信頼できない Web サイトでは秘密キーやニーモニック フレーズを入力しないでください。また、アクセスするリンクが公式 Web サイトであることを確認してください。ソフトウェアの信頼性を確保するために、公式チャネルを使用してウォレットとアプリケーションをダウンロードしてください。

次に、OKX Web3 ウォレットの観点から:

ユーザーの資金を保護するために、次のような多くのセキュリティ メカニズムを提供しています。

1) ドメイン名検出のリスク: ユーザーが DAPP にアクセスすると、OKX Web3 ウォレットはドメイン名レベルで検出と分析を実行し、ユーザーが悪意のある DAPP にアクセスすると、ユーザーが騙されないように傍受または通知します。 。

セキュリティ特集05|OKX Web3  BlockSec:@All Giant Whales、DeFi界の最新リスク回避戦略

2) Pixiu Pan トークンの検出: OKX Web3 ウォレットは、完全な Pixiu Pan トークン検出機能をサポートし、ウォレット内の Pixiu Pan トークンをアクティブにブロックして、ユーザーが Pixiu Pan トークンと対話しようとするのを防ぎます。

3) アドレス タグ ライブラリ: OKX Web3 ウォレットは、豊富で完全なアドレス タグ ライブラリを提供します。ユーザーが疑わしいアドレスとやり取りすると、OKX Web3 ウォレットはタイムリーに警告を発します。

4) トランザクションの事前実行: ユーザーがトランザクションを送信する前に、OKX Web3 ウォレットはトランザクションの実行をシミュレートし、資産と承認の変更の結果を参照用にユーザーに表示します。ユーザーは、結果が期待どおりかどうかを判断し、トランザクションの送信を続行するかどうかを決定できます。

セキュリティ特集05|OKX Web3  BlockSec:@All Giant Whales、DeFi界の最新リスク回避戦略

5) 統合された DeFi アプリケーション: OKX Web3 ウォレットは、さまざまな主流の DeFi プロジェクトのサービスを統合しており、ユーザーは OKX Web3 ウォレットを通じて統合された DeFi プロジェクトと安全に対話できます。さらに、OKX Web3 ウォレットは、ユーザーに最適な DeFi サービスと最適な Gas ソリューションを提供するために、DEX やクロスチェーン ブリッジなどの DeFi サービスのパスも推奨します。

セキュリティ特集05|OKX Web3  BlockSec:@All Giant Whales、DeFi界の最新リスク回避戦略

6) セキュリティ サービスの追加: OKX Web3 ウォレットは徐々にセキュリティ機能を追加し、より高度なセキュリティ保護サービスを構築しています。これにより、OKX ウォレット ユーザーのセキュリティがより適切かつ効率的に保護されます。

Q8: ユーザーだけでなく、DeFi プロジェクトが直面するリスクとその保護方法についても教えてください。

BlockSec セキュリティ チーム: DeFi プロジェクトが直面するリスクには、コード セキュリティ リスク、運用セキュリティ リスク、外部依存関係リスクが含まれます。

まず、コードのセキュリティリスクです。つまり、DeFiプロジェクトがコードレベルで持つ可能性のあるセキュリティリスクです。 DeFi プロジェクトの場合、スマート コントラクトは中核となるビジネス ロジック (フロントエンドおよびバックエンドの処理ロジックやその他の従来のソフトウェア開発ビジネスは比較的成熟しています) であり、次のような私たちの注目と議論の焦点でもあります。

1) まず、開発の観点から、再入脆弱性を防ぐための Checks-Effects-Interactions モードなど、業界で認められたスマート コントラクトのセキュリティ開発慣行に従う必要があります。一般的に使用される機能には信頼できるサードパーティのツールを使用し、車輪の再発明によって引き起こされる未知のリスクを回避するために、サードパーティのライブラリを使用して実装します。

2) 2 番目のステップは、内部テストを実施することです。テストはソフトウェア開発の重要な部分であり、多くの問題の発見に役立ちます。ただし、DeFI プロジェクトの場合、ローカル テストだけでは問題を明らかにするのに十分ではありません。これを実現するには、Phalcon Fork などのツールを使用して、実際のラインに近いデプロイメント環境でさらにテストを行う必要があります。

3) 最後に、テストが完了したら、信頼できるサードパーティの監査サービスに接続します。監査によって問題が発生しないことを 100% 保証することはできませんが、体系的な監査は、プロジェクト チームがさまざまな既知の一般的なセキュリティ問題を特定するのに大いに役立ちます。これらの問題は、多くの場合、セキュリティに精通していない開発者や異なる考え方を持っている開発者によって引き起こされます。手が届きにくい部分。もちろん、監査法人ごとに専門性や方向性が異なるため、予算が許す限り、実務的には2つ以上の監査法人が参加することが推奨されます。

2 つ目は、運用上のセキュリティのリスクです。つまり、プロジェクトがオンラインになった後、その運用中に発生するセキュリティ リスクです。一方で、コードにはまだ未知の脆弱性が存在する可能性があります。コードが適切に開発、テスト、監査されたとしても、まだ発見されていないセキュリティ リスクが存在する可能性があることは、ソフトウェア開発における数十年のセキュリティ実践で広く証明されています。その一方で、プロジェクトはコード レベルの問題を超えて、さらに多くの課題に直面しています。秘密キーの漏洩、重要なシステムパラメータの誤った設定など、オンラインになった後の課題は、重大な結果と巨額の損失を引き起こす可能性があります。運用上のセキュリティ リスクに対処するための推奨戦略は次のとおりです。

1) 秘密鍵管理の確立と改善: 信頼性の高いハードウェア ウォレットや MPC ベースのウォレット ソリューションなど、信頼性の高い秘密鍵管理方法を使用します。

2) 稼働状況の監視をしっかり行う: 監視システムは、プロジェクトの特権操作とセキュリティ状況をリアルタイムで把握します。

3) リスクに対する自動応答メカニズムを構築する: たとえば、BlockSec Phalcon を使用すると、攻撃に遭遇したときに自動的にブロックし、(さらなる) 損失を回避できます。

4) 特権操作の単一点リスクを回避します。たとえば、安全なマルチシグネチャ ウォレットを使用して特権操作を実行します。

第三に、外部依存リスクとは、他のDeFiプロトコルが提供する価格オラクルに依存するなど、プロジェクトの外部依存によって引き起こされるリスクを指しますが、オラクルに問題があるため、価格計算で誤った結果が生成されます。外部依存リスクに対する推奨事項は次のとおりです。

1) 業界で認められた信頼できるヘッドプロトコルなど、信頼できる外部パートナーを選択します。

2) 運用状況の監視を適切に行う: 運用上のセキュリティリスクと同様ですが、ここでの監視対象は外部依存関係です。

3) リスクに対する自動応答メカニズムを構築する: 運用上のセキュリティ リスクと似ていますが、プロトコル全体を直接停止するのではなくバックアップの依存関係を切り替えるなど、処理方法が異なる場合があります。

さらに、モニタリング機能を構築したいプロジェクト関係者向けに、モニタリングに関するいくつかの提案も提供します。

1) 監視ポイントを正確に設定する: プロトコル内にどの主要な状態 (変数) が存在し、どこで監視する必要があるかを決定することは、監視機能を構築するための最初のステップです。ただし、すべての側面をカバーする監視ポイントを設定することは困難であり、特に攻撃監視に関しては、実際の戦闘でテストされた外部の専門的なサードパーティの攻撃検出エンジンを使用することをお勧めします。

2) モニタリングの正確性と適時性を確保する: モニタリングの正確性とは、誤検知 (FP) や誤検知 (FN) が多すぎないことを意味します。正確性が欠けているモニタリング システムは本質的に使用できません。 (疑わしいコントラクトの展開後、攻撃トランザクションがチェーンにアップロードされる前に、疑わしいコントラクトを検出できるかどうかなど)、そうでない場合は、イベント後の分析にのみ使用でき、パフォーマンスとパフォーマンスに非常に高い要件が課されます。監視システムの安定性。

3) 自動応答機能が必要です。正確かつリアルタイムの監視に基づいて、攻撃をブロックするための一時停止プロトコルなどの自動応答を構築できます。これには、対応戦略を柔軟にカスタマイズし、プロジェクト関係者のニーズに応じて実行を自動的にトリガーできる、カスタマイズ可能で信頼性の高い自動応答フレームワークのサポートが必要です。

一般に、監視機能の構築には、専門の外部セキュリティ ベンダーの参加が必要です。

OKX Web3 ウォレット セキュリティ チーム: DeFi プロジェクトはさまざまなリスクに直面しており、主に次のカテゴリが含まれます。

1) 技術的リスク: 主にスマート コントラクトの脆弱性とネットワーク攻撃が含まれます。保護策には、安全な開発慣行の採用、スマートコントラクトの包括的な監査を実施するための専門の第三者監査会社の雇用、ホワイトハットハッカーによる脆弱性発見を奨励するためのバグ報奨金プログラムの設定、資金の安全性を向上させるための資産の分離などが含まれます。

2) 市場リスク:主に価格変動、流動性リスク、市場操作および複合リスクが含まれます。保護策には、価格変動を防ぐためのステーブルコインとリスクヘッジの使用、流動性リスクに対処するための流動性マイニングと動的な手数料メカニズムの使用、DeFiプロトコルでサポートされている資産タイプの厳密なレビュー、市場操作を防ぐための分散型オラクルの使用、継続的な革新と最適化によるものが含まれます。競争上のリスクに対処するためのプロトコル機能。

3) 運用リスク: 主に人的エラーとガバナンスメカニズムのリスクが含まれます。保護策には、人的エラーの発生を減らすための厳格な内部統制と運用手順の確立、運用効率を向上させるための自動化ツールの使用、投票遅延や複数署名メカニズムの導入など、分散化とセキュリティのバランスを確保するための合理的なガバナンス メカニズムの設計が含まれます。 。また、オンラインプロジェクトの監視や緊急時計画を策定し、異常が発生した場合には即座に対応し、損失を最小限に抑えます。

4) 規制リスク: 法的遵守要件およびマネーロンダリング防止 (AML)/顧客確認 (KYC) 義務。安全対策には、プロジェクトが法律および規制要件に準拠していることを確認するための弁護士の雇用、透明性のあるコンプライアンス ポリシーの確立、ユーザーと規制当局間の信頼を高めるための AML および KYC 対策を積極的に実施することが含まれます。

Q9: DeFiプロジェクト関係者はどのようにして優れた監査会社を判断し、選択するのでしょうか?

BlockSec セキュリティ チーム: DeFi プロジェクト関係者はどのようにして優れた監査会社を判断し、選択するのでしょうか? 参考までに、いくつかの簡単な基準を示します。

1) 著名なプロジェクトの監査実績の有無:当該監査会社が当該著名なプロジェクトにおいて認知されていることを示します。

2) 監査されたプロジェクトが攻撃されているかどうか: 理論上、監査は 100% のセキュリティを保証することはできませんが、実際の経験では、評判の良い監査会社によって監査されたほとんどのプロジェクトは攻撃されたことがないことがわかっています。

3) 過去の監査報告書による監査品質の判断: 監査報告書は監査法人の専門性を示す重要な指標であり、特に同じ監査プロジェクト、同じ監査範囲を比較できる場合、抜け穴の発見の品質に焦点を当てることができます。危険度)と量など、および脆弱性の発見がプロジェクト関係者によって一般的に採用されるかどうか。

4) 専門家: 監査会社の人員構成には、体系的な教育と専門的経歴が監査の品質を確保する上で大きく役立ちます。

最後に、OKX Web3 Walletコラム「セキュリティ特集」第05号をご覧いただきありがとうございます。現在、実際の事例やリスクの特定、安全な運用のヒントだけでなく、第06号も準備中ですので、ご期待ください。

免責事項

この記事は情報提供のみを目的としており、(i) 投資アドバイスまたは投資推奨、(ii) デジタル資産の購入、売却、または保有の提案または勧誘、または (iii) 財務、会計、法律または税務に関するアドバイスを提供することを目的としたものではありません。 。 ステーブルコインやNFTを含むデジタル資産の保有には高レベルのリスクが伴い、大幅に変動したり無価値になる可能性があります。自分の財務状況に基づいて、デジタル資産の取引または保有が自分に適しているかどうかを慎重に検討する必要があります。適用される現地の法律および規制を理解し、遵守することはお客様の責任です。

オリジナル記事、著者:欧易OKX。転載/コンテンツ連携/記事探しはご連絡ください report@odaily.email;法に違反して転載するには必ず追究しなければならない

ODAILYは、多くの読者が正しい貨幣観念と投資理念を確立し、ブロックチェーンを理性的に見て、リスク意識を確実に高めてください、発見された違法犯罪の手がかりについては、積極的に関係部門に通報することができる。

おすすめの読み物
編集者の選択