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 の安全上のヒントを紹介します。
- setFarm() や setWrapToken() などの主要な関数にはタイム ロックが課されており、将来の指定された時刻にのみ変更が許可されるため、コミュニティに議論して合意に達する時間が与えられます。
- 手数料や報酬に影響を与えるenableFeeAmount()やnewPool()などの関数を呼び出すには、複数のウォレットアドレスのマルチシグネチャ承認が必要です
- ExpandObservationQueue() やcollectFeeCharged()などの関数に対してロールベースのアクセス制御を実装し、指定されたロールのみの呼び出しを制限します
- コントラクトがデプロイされるとき、startBlock、endBlock、rewardPerBlock などのコア パラメーターを不変にし、その後の変更は許可されません。
- 機密機能への呼び出しに対してコミュニティの提案と投票を必要とする DAO ガバナンス構造を確立する
- モジュール式アーキテクチャを採用して責任を分離し、単一モジュールの過度の集中化を回避します。
- マルチシグネチャ認証による緊急停止メカニズムを確立し、問題が発生した場合に契約を一時停止できる
- 定期的に外部セキュリティ監査を実施し、発見された問題にタイムリーに対処することで集中管理のリスクを軽減します。
- 開発中に、ファジングやその他の手法を使用して、集中制御の脆弱性を特定して排除します。
- 最小特権の原則に従い、ロールとアカウントには必要最小限の権限のみを与えます
これらの集中化のリスクは、契約の所有者が契約のパラメータと機能を過剰に制御できる可能性があるという事実から生じており、その結果、所有者がプロトコルを操作したり、ユーザーに損害を与えたりする可能性があります。また、この分析が、iZiFinance のスマート コントラクトを改善するための有用な洞察とセキュリティに関する推奨事項を提供できることを願っています。
フォローする
Twitter: @MetaTrustLabs
ウェブサイト： metatrust.io
全てのコメント