DatingDapp

Summary

The executeTransaction() function in the Multisig contract does not remove executed transactions from storage, causing the transactions array to grow indefinitely. Over an extended period of operation, this results in an ever-increasingtxId, leading to excessive gas consumption and potential DoS risks.

Vulnerability Details

Whenever a transaction is executed using executeTransaction(), the corresponding entry remains in the transactions array instead of being deleted or marked as inactive. Because the contract continuously appends new transactions to this array, the overall storage usage increases indefinitely. This means that any operation that requires iterating over the array or checking transaction details will become progressively more expensive.

One major consequence of this design is that gas costs will increase as more transactions accumulate. Since Ethereum has a block gas limit, there may come a point where interacting with the contract becomes impractical due to prohibitively high gas fees. Additionally, as txId continues to increment, future transactions may become difficult to process, increasing the risk of transaction failures. If an attacker or a high-volume user continuously submits transactions without limit, the contract could experience significant storage bloat, leading to a DoS condition where it can no longer function effectively.

Impact

The unrestricted growth of the transactions array leads to an inefficient and unsustainable contract design. As the contract operates over a long period, the increasing gas costs will make transaction execution and retrieval more expensive. In extreme cases, the contract may become too costly to interact with, effectively rendering it unusable. The risk of a DoS attack also increases, as an attacker could exploit this flaw by continuously submitting transactions to exhaust storage resources and prevent others from using the contract.

Tools Used

Manual Audit

Recommendations

To mitigate this issue, the contract should implement a mechanism to remove executed transactions from storage. One solution is to explicitly delete a transaction from the transactions array after it has been processed. This can be done using Solidity’s delete keyword to free up storage and prevent unnecessary data accumulation.

Another approach is to replace the array-based transaction storage with a mapping structure that allows for more efficient deletion. Instead of maintaining a growing list of transactions, the contract can use mapping(uint256 => Transaction) to store transaction data, which enables direct deletion without requiring expensive array shifting operations.

Additionally, the contract could introduce an expiration mechanism for old transactions. By setting a time limit or a storage cap, transactions that are no longer relevant could be automatically removed or archived to off-chain storage. This would help prevent long-term storage bloat and ensure that the contract remains efficient over time.

By implementing these optimizations, the contract can significantly reduce gas costs and prevent long-term usability issues while also protecting against potential DoS attacks caused by storage overflow.