致命的な欠陥の回避策

MasterChef には使用中に修正できる特定の欠陥がありますが、それはユーザーがそれを認識し、何ができるかを知っている場合に限られます。 によると、回避策は次のとおりです グレブ・ザイコフ そしてヴラド・コロフニコフ ハッシュエクス.

分散型取引所 (DEX は) ほんの XNUMX 年前までは非常にまれでしたが、今ではどこにでも存在しているようです。 独自の個人 DEX を持つ多数のプロジェクト。 これは、ブロックチェーン プロジェクトが DEX の立ち上げを決定するとき、完全にゼロから作成するわけではないために起こりました。 代わりに、DEX のコードの基礎は、多くの場合、XNUMX つの主要な DEX のいずれかのフォークです。 寿司入れ替え or パンケーキスワップ.

マスターシェフ スマート コントラクト

これら XNUMX つの取引所は、MasterChef と呼ばれる特別なスマート コントラクトのおかげで、DEX 空間に大きな革命をもたらしました。 MasterChef は両方に登場するため、これら XNUMX つのいずれかのフォークとして作成された DEX にも登場します。 新しい DEX はそれぞれ同じ機能を共有できるようになります。 しかしそれは、MasterChef の欠点や脆弱性を共有していることも意味します。 

それでは、MasterChef を扱うときにユーザーと開発者がどのような問題に遭遇する可能性があるかを見てみましょう。 彼らは何に注意すべきでしょうか？ そして、彼らにどのようにアプローチすべきでしょうか？

DEX はどのように機能しますか?

最初に注意すべきことは、MasterChef コントラクトは、ファームが実行できることとそれをどのように実行できるかを制御する Solidity で記述されたスマート コントラクトであるということです。 ほとんどのプロジェクトでは、責任と作業を共有する複数のスマート コントラクトが存在します。 しかし、MasterChef ベースのプロトコルに関しては、この単一のコントラクトがファーミングに関するすべてを処理します。

分散型取引所を使用すると、取引所にお金を預けることなく暗号通貨を交換できます。 財布。 代わりに、自分のウォレットからスマートコントラクトに資金を入金します。 それを管理できるのはあなただけであり、契約にバックドアや脆弱性がなければ自分の資金にアクセスできます。

もう XNUMX つの違いは、CEX が売買にオーダーブックを使用するという事実にあります。 これは、DEX が AMM (Automated Market) を使用するのに対し、DEX は買い手と売り手をマッチングすることを意味します。 メーカー) 投資される流動性の量に応じて資産の価格を計算する取引用のプロトコル。

流動性は流動性プールから得られます。流動性プールは、ユーザーが特定のペアの資金を入金し、プロトコルで利用できる資金を作成できるプールです。 その後、誰かがそのペアを使用して資産を購入しようとすると、その注文はプールの資金を使用して即座に履行されます。 一方、流動性プールに資金を入金した人は、その特定のプールの LP トークンを取得します。 これにより、彼らに報酬を共有する権利が与えられます。

そして、資金を取り戻したい場合は、受け取った LP トークンを返還するだけで済みます。

ご存知かもしれませんが、生成するには複数の方法があります。 収量 暗号資産保有から。 農場は流動性を提供することで追加の報酬を与えます。 ユーザーはDEXに流動性を追加し、LPトークンを取得し、ファームに賭けます。

MasterChef: 脆弱性と欠陥

DEX の仕組みと流動性プールの仕組みについて説明しました。 そこで、MasterChef の脆弱性がどこに存在するのか、プロセスにどのような影響を与えるのか、また、物事をスムーズに進めるためにはどのようなアプローチが必要なのかを詳しく見てみましょう。

侵害されたアカウント

注意すべき最大の問題の XNUMX つは、所有者のアカウントが侵害されることに関係しています。 基本的に、SushiSwap は Uniswap に対して優位に立つことを可能にする方法を発明しました。 この方法は、ある取引所から別の取引所に資産を移行することを中心としています。 これは、コントラクトの所有者のみがアクセスできる別の機能を使用してコントラクトによって処理されます。

ただし、この移行は最終的には制限なく、基本的にあらゆる契約に合わせて調整される可能性があり、最終的には大きな見落としとなりました。 したがって、所有者アカウントが侵害された場合、すべてのファーミング プール内のすべての基本 LP トークンを任意のアドレスに送信する新しい移行契約が生じる可能性があります。 そうなると、投資資産の巨額の損失につながります。

この関数は現在開発者にとって馴染みのあるものであるため、最終的にはすぐに削除されることに注意してください。 フォーク。 ただし、それが依然として存在する場合は、直ちに危険信号とみなされる必要があります。

もう XNUMX つ注意すべき点は、一部の MasterChef フォークでは、契約の所有者が制限なく排出レートを変更できることです。 ただし、アカウントが侵害された場合、攻撃者は非常に大きな排出レートを設定する可能性があり、これによりトークンの価値が下落する可能性があります。

これを解決する非常に簡単な方法は、契約の所有者が利用できるすべての機能にマルチ署名認証が必要であることを確認するだけです。 そうすることで、XNUMX つのアドレスが侵害された場合でも、悪意のある者はそれに対して何もすることができなくなります。 もう XNUMX つ行うべきことは、移行関数の呼び出し時に一時的なブロック (タイムロック コントラクト) を追加することです。 こうすることで、ユーザーは意思決定をする時間が増え、取引所は移行やその他の不審なトランザクションをユーザーに通知する必要があります。

同一のファーミング プールの追加

元の契約が同一の農業プールの処理を考慮していない場合、これは契約が農業報酬を誤って計算する恐れがあることを意味します。

MasterChef が正しく使用されている場合、所有者は意図的に同一のプールを追加しないため、これは大きな問題ではありません。 実際、適切に運営されている取引所では、これらのことが検証されており、重複したプールの作成は強く禁止されています。 したがって、プールの作成を開始し、既存のプールの複製を作成する方向に進んでいる場合、システムはエラーを報告できるはずです。 または、新しいプールを作成するのではなく、既存のプールに資金を追加することをお勧めします。

入金されたトークンの量を計算しない

何らかの理由で、人々は転送手数料付きのトークンまたはリベース トークンがプールとして MasterChef コントラクトに追加された場合に何が起こるかを考慮することを忘れがちです。 コントラクト コードは特定の関数を呼び出すことによってのみアセットをプールに追加するため、実際に発生するのは報酬の計算方法の破綻です。 これは、アドレスにトークンを追加すると、それらのトークンがプール内に既に存在する資産と結合されることを意味します。 しかし、そのようなトークンの報酬の計算は壊れる可能性があり、それが脆弱性につながります。

適切に運営されているプラ​​ットフォームは、手数料を考慮した実際の送金額を確認することにより、農業のために送金される資金の量を別途計算する必要があります。 このようにして、報酬の計算が正しく行われます。

マスターシェフ: 結論

MasterChef は、DEX で流動性を提供することによって収益を得るために使用される単一のスマート コントラクトです。 残念ながら、使用中に修正できるいくつかの欠陥がありますが、それはユーザーがそれを認識し、自分でできることを知っている場合に限られます。 

上記では、起こり得るいくつかのことと、これらの問題を回避する方法について説明しました。 ただし、トークンがコントラクトアドレスに直接送信された場合の報酬の希薄化、開始ブロックの変更、ガスの最適化などの問題がさらにあることに注意する必要があります。 

言い換えれば、心に留めて監視しておくべき脆弱性や問題が存在するということです。 しかし全体として、MasterChef は分散型取引所をほぼ可能にした革新的な契約です。 したがって、注意して使用し続け、その欠陥とその修正方法を認識している限り、問題はありません。

著者について

グレブ・ザイコフ の共同創設者兼 CTO です。 DeFi セキュリティ と分析会社 ハッシュエクス.

â€<â€<ヴラド・コロフニコフ ジュニア スマート コントラクトの監査人および開発者です。

いくつか得たtMasterchef の回避策やその他について何か言いたいことはありますか? 私たちに書いてください または私たちの議論に参加する テレグラムチャネル。 あなたも私たちを捕まえることができます Tikの トック, Facebookまたは Twitter.

免責事項

当社のウェブサイトに含まれるすべての情報は、誠意を持って、一般的な情報提供のみを目的として公開されています。 当社のウェブサイトに掲載されている情報に対して読者がとる行動は、厳密に自己責任で行ってください。