perf: replace O(n) duplicate scan in calculate_sla with indexed lookup

[Icahbod]

calculate_sla iterates the entire history vector on every invocation to find an existing entry for the supplied outage_id. As HISTORY_KEY grows toward MAX_HISTORY_SIZE (1000) and beyond under the configurable retention limit, this linear scan degrades the hot path of the contract, blowing gas costs on every call and amounting to O(n^2) work over the contract lifetime. Maintain a parallel Map<Symbol, u32> (suggested key LAST_BY_OUTAGE) keyed by outage ID and updated inside the same storage write batch so duplicate detection becomes O(1). Add a regression test that submits N+1 distinct outage IDs and asserts gas usage of the duplicate-detection path is flat, not linear in N.

[nelly439]

I can take this on. I’ll eliminate the O(n) scan in calculate_sla by introducing a parallel Map<Symbol, u32> (e.g. LAST_BY_OUTAGE) to track outage IDs, updated atomically alongside the history write. This will reduce duplicate detection to O(1) and prevent the current O(n²) gas growth as history scales.

I’ll keep the change tightly scoped to the storage layer, ensure consistency between the map and history vector, and add a regression test that validates constant gas usage for duplicate detection as N grows. The goal is to preserve current behavior while making the hot path predictable and efficient.

[ayomidearegbeshola29-dev]

As a Full-Stack Developer with smart contract experience, I would optimize the calculate_sla function by eliminating the repeated linear scan of HISTORY_KEY used for outage duplicate detection. The current implementation performs an O(n) search on every invocation, causing gas costs to increase as the history vector grows and resulting in O(n²) cumulative work over the contract's lifetime.

To resolve this, I would introduce a dedicated storage mapping, LAST_BY_OUTAGE, using a Map<Symbol, u32> structure that stores the index or reference of the most recent record associated with each outage_id. During each calculate_sla execution, the contract would perform a direct lookup in LAST_BY_OUTAGE instead of iterating through the entire history vector, reducing duplicate detection from O(n) to O(1).

The mapping would be updated atomically within the same storage write operation whenever a new outage record is added, ensuring consistency between HISTORY_KEY and LAST_BY_OUTAGE. Any retention or cleanup logic would also update the mapping to prevent stale references.

To validate the optimization, I would add regression and performance-focused tests that insert N distinct outage IDs and then submit an additional outage request. The tests would compare gas consumption before and after the optimization and verify that duplicate detection remains effectively constant regardless of history size. Additional edge-case tests would cover duplicate IDs, retention-limit pruning, empty history states, and storage synchronization.

Skills Applied: Rust, Soroban Smart Contracts, Full-Stack Development, Data Structure Optimization, Algorithm Analysis, Performance Engineering, Gas Optimization, Blockchain Development, State Management, Unit Testing, and Smart Contract Architecture.

[MicD746]

Hello Maintainer, please can I work on this issue and give you a better result