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:

• English: LoopringV3_Report_EN.pdf
• Chinese: LoopringV3_Report_CN.pdf

SECBIT’s Audit Conclusion

Audit Result

Risk Assessment

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 SignatureBasedAddressWhitelist does 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 transferTokens function is self-checked when allowFailure is 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.sender to 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 uinty32 type can express timestamp before 2106, and we believe Loopring will surely migrate to new protocols before that deadline.
• 4.3.7 “TransformRingSettlementDataGadget could 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 thegenerateKeyPair() 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 OffchainWithdrawalBlock class.” ⟶ 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.

Deposit Circuit

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).

Acknowledgment

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.

If you have questions or suggestions regarding the report or Loopring Protocol in general, feel free to email Loopring or/and SECBIT.

⭑ Website: https://secbit.io
⭑ Email: info@secbit.io
⭑ Twitter: @secbit_io

Loopring is a protocol for building high-performance, non-custodial, orderbook-based exchanges on Ethereum. You can sign up for our Bi-Weekly Update, learn more at Loopring.org, or check out:

Twitter ⭑ Reddit ⭑ Telegram ⭑ GitHub ⭑ Discord ⭑ YouTube ⭑ LinkedIn