Fix #199: Mitigate front-running vulnerability in Ticket Contract via commit-reveal scheme

[GEEKYFOCUS]

Summary of Changes

This PR addresses the Issue #199 front-running vulnerability present in the Gatheraa ticket purchasing flow (ticket_contract). By observing the mempool/pending transactions, malicious actors could previously front-run user ticket purchases. Because purchase dynamically evaluated the asset price at execution time using get_ticket_price(), this allowed for price slippage exploitation or sniping the last available tickets.

To mitigate this, I implemented a complete Commit-Reveal Scheme with delay mechanisms, price slippage protection, and suspicious activity monitoring.

1. Commit-Reveal Scheme Implementation

• Data Structures: Added PurchaseCommitment to storage_types.rs.
• Phase 1: commit_purchase: Buyers submit a commitment_hash equal to SHA-256(buyer || tier_symbol || max_price || nonce). This logs their intent to purchase and timestamps it at the current ledger sequence, completely hiding their targeted tier and maximum acceptable price from observers.
• Phase 2: reveal_purchase: Once the delay has passed, the buyer provides the raw parameters. The system recalculates the hash to prove ownership, ensures the ticket tier matches, and executes the purchase securely.

2. Minimum Delay Mechanism

• Added standard configurable MinRevealDelay (default 5 ledgers) enforced between commit_purchase and reveal_purchase.
• This fundamentally eliminates same-block front-running or sandwich attacks because bad actors must wait out the delay while being unable to decrypt the targeted asset during the commit window.

3. Suspicious Transaction Monitoring

• Data Structures: Added FrontRunMonitor to track per-address activity limits.
• Monitoring Logic: Implemented check_front_run_monitor and update_front_run_monitor.
• The contract records failed reveals and excessive commit frequency per user address. If an address hits the MAX_FAILED_REVEALS (5) or attempts to submit an abnormal amount of commitments within the rolling MONITOR_WINDOW_LEDGERS (60), the address is temporarily blocked from purchasing for two full monitor windows.

4. Controlled Randomization (VRF)

• The architecture already relies on VRFEngine and AllocationEngine (Lottery Mode) within ticket_contract for highly contested/critical random operations. Our fix pairs optimally with this by securing the direct-sale channel (purchase).

Validation

• The structured changes to storage_types.rs and the front-runner mitigation integration in ticket_contract/src/lib.rs adhere strictly to standard Soroban Rust SDK engineering practices.
• Integrated and added automated tests directly inside test.rs covering the full commit-reveal flow, slippage threshold protections, and front-running spam monitoring blocks.

Next Steps

• The organizers will need to invoke set_min_reveal_delay (defaults to 5) per the deployment environment capability.
• The UI frontend must be updated to abstract the commit-reveal 2-step transaction flow, generating the commitment_hash locally via SHA-256 for the user before firing reveal_purchase seconds later.

[Xhristin3]

@GEEKYFOCUS resolve conflicts.

[Xhristin3]

@GEEKYFOCUS resolve conflicts.