iZiFinance is a decentralized finance protocol that leverages zkSync, a layer-2 scaling solution for Ethereum. zkSync enables fast and low-cost transactions on Ethereum, while preserving the security and composability of the layer-1 network. However, gas optimization is still an important aspect of smart contract development on zkSync, as it affects the performance and profitability of the protocol.
In this analysis, we will examine one of the core contracts of iZiFinance, iZiSwapPool.sol, and identify a simple way to reduce gas consumption by eliminating a redundant expression.
The iZiSwapPool Contract
The iZiSwapPool contract implements the logic of liquidity pools and token swaps on iZiFinance. It conforms to the IiZiSwapPool interface, which defines the functions and events of the contract. One of the functions is modifyFeeChargePercent, which allows the owner of the contract (the factory) to adjust the fee charge percent for each pool. The fee charge percent is a parameter that determines the distribution of the swap fee between the liquidity providers and the protocol.
The code of the modifyFeeChargePercent function is as follows:
The function accepts a uint24 argument called newFeeChargePercent, which represents the new fee charge percent to be set. It also has some modifiers and requires statements to ensure that only the owner can invoke the function and that the newFeeChargePercent is valid.
Code Analysis
This contract code is written in Solidity and represents a function that modifies a fee charge percent. It seems to have been designed in a secure manner, considering the restrictions applied before making the actual modification (lines 534–536).
However, line 535 require(newFeeChargePercent >= 0, “FP0”); is indeed unnecessary. This is due to the fact that in Solidity, the uint (unsigned integer) data type cannot be negative. uint24 is an unsigned integer type that ranges from 0 to 2²⁴ — 1. Hence, checking if the newFeeChargePercent is greater than or equal to 0 is tautological, because by definition, an unsigned integer cannot be less than 0.
Therefore, this line constitutes a tautology and can be safely removed without affecting the functionality of the code or introducing any security vulnerabilities. The line immediately after it, require(newFeeChargePercent <= 100, “FP0”);, is enough to ensure that the newFeeChargePercent is within the desired range (0–100).
Centralized Risks
We also found some centralized risks that could compromise the security and trustlessness of the protocol.
Security Suggestions
Here are 10 security tips for iZiFinance to take into consideration to better protect on-chain assets for users.
- Impose timelocks on critical functions like setFarm() and setWrapToken() to only allow modification at a future specified time, giving the community time to discuss and reach consensus.
- Require multi-sig approvals from multiple wallet addresses to invoke functions like enableFeeAmount() and newPool() that affect fees and rewards.
- Implement role-based access control for functions like expandObservationQueue() and collectFeeCharged(), restricting invocation to designated roles.
- Make core parameters like startBlock, endBlock, rewardPerBlock immutable at contract deployment, disallowing subsequent changes.
- Establish a DAO governance structure where invocation of sensitive functions requires community proposals and voting.
- Adopt a modular architecture with separation of duties, avoiding excessive centralization in any single module.
- Build in an emergency stop mechanism with multi-sig authentication to halt the protocol if issues arise.
- Conduct regular external security audits and promptly address findings to reduce centralized control risks.
- Incorporate fuzz testing and other methods during development to identify and eliminate centralized control vulnerabilities.
- Follow the principle of least privilege, granting roles and accounts only the minimum permissions necessary.
These risks stem from the fact that the contract owner may have excessive control over the parameters and functions of the contract, which could allow them to manipulate the protocol or harm the users. We hope that this article has provided some useful insights and security suggestions for improving the smart contract of iZiFinance.
Follow Us
Twitter: @MetaTrustLabs
Website: metatrust.io
All Comments