過去数ヶ月間、DeFiの生態は大きな激動を経験しました。数回の攻撃の下で、多くの未利用の欠陥が報道されました。
コードの中にはバグがあることは避けられないが、多くの方法が欠陥発生の周波数を低減し、欠陥による負の影響を低減することができる。
審査員として、DeFiユーザーに鋭い質問をしてもらいたいです。これらの質問の目的は、開発者にシステムの安全性の優先度を真剣に考えさせることです。一方、ユーザーに答えの良い協議を見分けて、お金をこれらの契約に投入させます。
以下の問題はユーザーがDeFi開発チームの安全性に対する立場を理解するのを助けることができます。答えは間違いに対してあるとは限らないです。また、各チーム(o独立開発者)がすべての面に配慮しているわけではありません。
しかし、いずれにしても、ユーザーはこれらの情報を知って、自分が受けたいリスクを決定する権利があります。
私たちは以下の質問を通じて、今後より積極的な議論を展開していきたいと思います。
1.管理者権限の大部分の主流のDeFiプロトコルにはいくつかの中心的なメカニズムがあります。
このようにすると安全上のメリットがありますが、これらの「管理者」が彼らの特権を乱用しないと信じなければならないということです。また、これらの管理者がハッカーに攻撃されると、彼らの秘密鍵が漏れてくると、より深刻な結果になります。
管理者アカウントは、単一のアドレス、複数の署名財布、またはDAOによって管理される投票プロセスのいくつかの形態でありうる。
管理人はどのような措置を取ることができますか?システム全体を一時停止しますか?口座残高を修正しますか?トークンユーザのホワイトリストのブラックリストを設定しますか?あるサブシステムをアップグレードしますか?システム全体をアップグレードしますか?(万能に等しい)他の権限?上記のような行為をする場合、遅延実行メカニズムがありますか?遅延時間があれば、どれぐらいかかりますか?何人が管理者権限を持っていますか?上記の行動を取る前に、どのぐらいの管理人の同意が必要ですか?どのような権限がチェーン上のガバナンス(つまりDAO)によってコントロールされますか?どこに行ったら契約更新の提案が分かりますか?上記のいくつかの質問に対する答えはすでにDefiWatchで追跡できます。
2.外部依存は公開されたネットワークであるため、エーテル坊には悪意の攻撃者があふれているので、開発者は本システム以外の契約がどのような行為をするかを想定できない。
しかし、多くのDeFiアプリケーションでは、サービス自体が既存の契約上構築されたものであるという仮定をしなければならない。
これらの問題は、ユーザーがこのプロジェクトの外部依存性に存在するリスクを理解するのを助けることができる。
あなたのシステムは何の予言機に依存していますか?あなたのシステムはどんな取引所に依存していますか?どのような第三者の知能契約(例えば、OpeZeppeli)でシステムを作りますか?あなたのシステムはどのトークンをサポートしていますか?これらのトークン(契約)の行動パターンに対してどのような期待がありますか?3.信頼できる開示システムと奨励計画は才気あふれるハッカーにとって、DeFiを攻撃する契約は彼らに強い金銭的誘惑を持っています。
奨励計画を立てると、手抜かりを見つけて暴くことができます。
ハッカーにとっては、インセンティブシステムを通じてコード・ホールを暴くのも自分の名誉を高める良い方法です。
いかなる会社でもDeFi契約を実行します。またはオンラインでお金を管理する業務に関連しています。奨励システムがあります。
彼らの奨励計画と披露プロセスについて以下の問題を提出してもいいです。あなた達の契約コードはすべての人に見られますか?あなた達のウェブサイトとgitコードバンクから、安全な連絡先を簡単に見つけられますか?あなた達の契約にはボーナスプランがありますか?どの契約が奨励計画内ですか?ボーナスプランの具体的な金額は?ボーナスプランのボーナスを支払ったことがありますか?バグ報告に対して、あなた達は支払いを拒否したことがありますか?あなた達のウェブサイトとgitコードバンクから、奨励計画の詳細情報が簡単に見つけられますか?理想的には、これらの情報は「website.com secuity」ページの下に置くべきです。また、GithubのSECURITY.md機能と組み合わせて使うことができます。
4.緊急対応策のいくつかの安全突発状況に直面した時、新たなニュースが潮のように押し寄せ、ユーザーはTwitte、Telegam、Discodに引き続き手を焼く問題を提起しています。この時、開発者は頭がすっきりしないで突発状況に対応します。
ですから、緊急対応策があれば、プロジェクトが安全に向かって発展していることを証明できます。
プロジェクトの公開を要求していますが、彼らの完全な計画はあまり現実的ではないかもしれません。しかし、以下の基礎的な問題を提出して側面に理解してもらえます。突発安全事件を処理する計画の大綱がありますか?あなた達の緊急事態対応策はどのような緊急状況に適用されますか?もしあなた達のシステムがアップグレードできるなら、これらのアップグレードのステップは記録されていますか?もしシステムの不備を発見したら資金が危険にさらされるかもしれません。緊急対応策を通じて先制的に資金の安全を守ることができますか?5.監査と安全発展監査は萬霊丹ではなく、監査の内容は全体的に多少違っていますが、いかなるDeFi契約を展開する前に監査を行うことが重要な一歩です。
以下の問題は必ずしも「正しい答え」とは限らないが、学識が深いコミュニティーの人々は、プロジェクトの回答から開発チームの安全性に対する立場を見て取ることができるはずだ。
あなた達の最近の監査はいつですか?今回の監査にどれぐらいの力を入れましたか?どの機関の監査ですか?監査報告書は公開されていますか?あなた達のシステムの中には監査の範囲内に含まれていない部分がありますか?最近の監査の後、契約を更新しましたか?もしあったら、何を更新しましたか?どの安全チームと長期的な協力がありますか?コードを統合する前に、開発者は互いにcode eviewを作りますか?あなた達の契約コードの中で、ユニットテストをした比重はいくらですか?監査中、他の安全分析ツールを使ったことがありますか?