Gas Limit Denial of Service (DoS) via Nested Loops

Description

The function getUserMemorabiliaDetailed implements a nested loop structure to identify and aggregate the memorabilia owned by a specific user. It first iterates through all existing collections nextCollectionId and then, within each collection, iterates through every individual item currentItemId.As the project scales and the number of collections and unique items increases, the cumulative gas required to execute these loops will grow quadratically. Eventually, the gas cost will exceed the Block Gas Limit, causing the function to revert.

Risk

Likelihood:

As the project scales, the number of collections and items will inevitably increase. The complexity of the nested loops ensures the gas cost will eventually exceed the block gas limit.

Impact:

Failure of this function prevents the frontend from querying asset details directly from the chain, breaking the user experience. While it doesn't result in a direct loss of funds, it causes a permanent Denial of Service (DoS) for a core contract feature.

Proof of Concept

When the contract state contains 10,000 memorabilia entries, calling getUserMemorabiliaDetailed triggers an OutOfGas revert.

Proof of Code：

Test output:

Recommended Mitigation

Instead of using nested loops, the contract should implement proactive ownership tracking by overriding the _update function. By updating a mapping userOwnedTokensduring the mint process, the contract ensures that asset data is pre-compiled, allowing the query function to return results directly without risk of an OutOfGas revert.