iZiFinance は、イーサリアムのレイヤー 2 スケーリング ソリューションである zkSync を利用した分散型金融プロトコルです。 zkSync は、レイヤー 1 ネットワークのセキュリティと構成可能性を維持しながら、イーサリアム上での高速かつ低コストのトランザクションを可能にします。ただし、ガスの最適化は、プロトコルのパフォーマンスと収益性に影響を与えるため、zkSync でスマート コントラクト開発を行う場合には依然として重要な側面です。

この分析では、iZiFinance の中核契約の 1 つである iZiSwapPool.sol を調査し、冗長な式を排除することでガス消費量を削減する簡単な方法を見つけます。

iZiSwapPool契約

iZiSwapPool コントラクトは、iZiFinance 上の流動性プールとトークン交換のロジックを実装し、コントラクトの機能とイベントを定義する IiZiSwapPool インターフェイスに従います。これらの関数の 1 つは、modifyFeeChargePercent です。これにより、契約の所有者は、プールごとの手数料の割合を調整できます。手数料徴収率は、流動性プロバイダーとプロトコル間の為替手数料の配分を決定するパラメーターです。 modifyFeeChargePercent 関数のコードは次のとおりです。

この関数は、設定される新しい料金請求パーセンテージを表す newFeeChargePercent と呼ばれる uint24 型のパラメーターを受け入れます。また、所有者だけが関数を呼び出すことができ、newFeeChargePercent が有効であることを保証するための修飾子と require ステートメントも含まれています。コード分​​析 この契約コードは Solidity で書かれており、料金徴収率を変更する機能を表しています。実際の変更前に適用された制限を考慮して、安全な方法で設計されているようです (534 ～ 536 行目)。

ただし、535 行目 require(newFeeChargePercent >= 0, "FP0"); は実際には不要です。これは、Solidity では uint (符号なし整数) データ型を負にすることができないためです。 uint24 は、0 ～ 2^24 - 1 の範囲の符号なし整数型です。

したがって、定義上、符号なし整数は 0 未満にはならないため、newFeeChargePercent が 0 以上であるかどうかを確認することはトートロジーになります。したがって、この行はトートロジーを構成しており、コードの機能に影響を与えたり、セキュリティ ホールを導入したりすることなく、安全に削除できます。その直後の行 require(newFeeChargePercent <= 100, "FP0"); は、newFeeChargePercent が予想範囲 (0 ～ 100) 内であることを確認するのに十分です。

集中化のリスク

また、プロトコルのセキュリティとユーザー資産のセキュリティを損なう可能性のある集中化のリスクも特定しました。

集中化のリスク

また、プロトコルのセキュリティとユーザー資産のセキュリティを損なう可能性のある集中化のリスクも特定しました。

安全上のアドバイス

iZiFinance プロジェクト チーム向けに、ユーザーのオンチェーン資産を集中化リスクから保護するための 10 の安全上のヒントを紹介します。

これらの集中化のリスクは、契約の所有者が契約のパラメータと機能を過剰に制御できる可能性があるという事実から生じており、その結果、所有者がプロトコルを操作したり、ユーザーに損害を与えたりする可能性があります。また、この分析が、iZiFinance のスマート コントラクトを改善するための有用な洞察とセキュリティに関する推奨事項を提供できることを願っています。

フォローする

Twitter: @MetaTrustLabs

ウェブサイト： metatrust.io