SECBIT Delivers a Security Audit Report for Loopring Protocol 3.0
After three months of code review and analysis, SECBIT Labs has just finished its Security Audit Report for Loopring Protocol 3.0 beta3. We cannot wait to share the report with our community and would also like to take the opportunity to comment on some of SECBIT’s findings and our follow-up actions.
The report is available for download:
SECBIT’s Audit Conclusion
Loopring’s Actions and Comments
Below is the list of findings in the report and the actions we’ve taken to address them.
- 4.3.1 “Definitions and implementations of
getLRCFeeStats()interface are inconsistent.” ⟶ This has been fixed.
- 4.3.2 “Assembly code in
SignatureBasedAddressWhitelistdoes not work.” ⟶ This has been fixed with additional test cases.
- 4.3.3 “Operator influence on the choice of maker/taker orders.” ⟶ The topic had been discussed: the fact that relayers decide which orders are maker/takers is by design.
- 4.3.4 “Unchecked return values in use of
transferTokens().” ⟶ The
transferTokensfunction is self-checked when
false, there is no need to verify the return value by the caller.
- 4.3.5 “Unclear intention of
transferDeposit()function.” ⟶ We pass in
msg.senderto this internal function to be more future proof. In future versions, we may allow other addresses to do these kinds of operations for
msg.sender(this allows us to support gas station networks, to give just one example of many possible use cases).
- 4.3.6 “Consider about overflow issues of timestamp in Block.” ⟶ The current
uinty32type can express timestamp before 2106, and we believe Loopring will surely migrate to new protocols before that deadline.
- 4.3.7 “
TransformRingSettlementDataGadgetcould be optimized.” ⟶The code to shuffle the data availability bits does not have any impact on the performance of the circuits and so was not written for maximum performance, but to make it easy to modify. There is little reason to modify the code at this point, even if you could modify the code to run faster in theory. Data compression inside the circuit (using XOR) is currently disabled, but data compression inside the circuit certainly has its benefits! A balance can be found between what operations are cheap in circuits and what operations are cheap on-chain.
- 4.3.8 “Wrong comment in
TakerMakerMatchingGadget.” ⟶ This has been resolved by multiple circuit optimizations.
- 4.3.9 “Call logic of
generateKeyPair()is impractical.” ⟶ This has also been resolved by multiple circuit optimizations, and the
generateKeyPair()method is ONLY called in testing; in production, all proving/verification keys are generated based on the trusted setup MCP ceremony.
- 4.3.10 “Redundant fields in the
OffchainWithdrawalBlockclass.” ⟶ This has been fixed.
- 4.4.1 “Consider about exception handing in extreme cases.”⟶ We have adjusted protocol parameters to handling the following extreme scenarios: 1) Ethereum is heavily congested and relayer transactions will be pending for up to a week and 2) Relayer data lost all its off-chain data.
After careful review of the most up-to-date codebase, we believe all findings from SECBIT should have been addressed and no further action is necessary.
SECBIT’s Analysis of ZKP Circuits
Loopring 3.0's circuit code is hard to digest for those without hands-on experience with ZKP or libsnark. Therefore we’d like to share some diagrams drawn by SECBIT and hope they will be helpful for teams who plan to use libsnark to compose circuits.
All deposit requests are on-chain. The same circuit is also used to create new DEX accounts, reset trading keys, and cancel existing orders.
On-chain Withdrawal Circuit
This circuit enables users to request withdrawals on-chain with an Ethereum transaction. Such withdrawal requests will be processed by the relayer within a limited time window enforced by the protocol. The downside of on-chain withdrawal is that users pay both withdrawal handling fee as well as Ethereum transaction gas.
Off-chain Withdrawal Circuit
This circuit enables users to request withdrawals without any Ethereum transactions. Relayer is recommended but not required to support off-chain withdrawal requests.
Trade Settlement Circuit
This circuit contains the core trading logic and had been optimized to minimize calldata size.
Order Cancellation Circuit
Users can use off-chain cancellation requests to ensure orders are canceled by the relayer. However, in most cases, setting order TTL (time-to-live) is a much better approach to obsolete orders (and can be used together with Order Aliasing to safely extend the lifetime of the order when necessary).
SECBIT Labs is a first-class organization in China that offers security audit service, covering solidity smart contracts, formal verification, as well as ZKP and other cryptographic related algorithm code inspection. SECBIT had also audited Loopring 2.0’s smart contract code and performed formal verification.