Front-running Attack in likeUser Function

Summary

The likeUser function in the LikeRegistry contract is vulnerable to a front-running attack. Since the function requires users to send at least 1 ETH to like another user, a malicious actor can monitor the mempool and front-run the transaction of a legitimate user by executing the same action with a higher gas fee. This allows the attacker to secure the match before the original user's transaction is processed.

Impact

• Users attempting to like someone may lose their opportunity if an attacker front-runs their transaction.

• Attackers can manipulate the system by ensuring they are always matched first.

• This reduces fairness and trust in the protocol.

Recommendation

To mitigate the risk of front-running, the following solutions can be implemented:

1. Commit-Reveal Scheme:

   • Require users to first submit a commitment hash (e.g., keccak256(liker, liked, secret)).

   • Later, they can reveal their like transaction, preventing front-running since attackers won’t know who is liking whom beforehand.

2. Time-based Randomization:

   • Introduce a small, random delay before processing likes to make front-running difficult.