Implement-Soroban-Contract-Invocation-Cache

[Habibah371]

Implement Soroban Contract Invocation Cache

Overview

This PR introduces a caching layer for Soroban contract invocation results to reduce RPC load, improve response times, and optimize overall application performance. Frequently requested contract calls can now be served from cache instead of repeatedly querying the Stellar RPC endpoint.

Problem

Repeated invocations of the same Soroban contract methods generate unnecessary RPC traffic and increase latency for end users. As application usage grows, redundant requests can lead to higher infrastructure costs and slower response times.

Changes Implemented

Contract Invocation Cache

• Added a dedicated cache layer under src/cache/contracts/stellar/
• Stores responses from Soroban contract invocations
• Reuses cached responses for identical requests when available

Cache Expiration Policies

• Configurable cache expiration (TTL) support
• Automatically invalidates stale entries after expiration
• Ensures cached data remains reasonably fresh while reducing RPC calls

Cache Management

• Generates deterministic cache keys based on:

  • Contract ID
  • Invoked method
  • Method parameters
  • Network/environment context

• Prevents collisions between different contract invocations

Performance Improvements

• Reduces duplicate RPC requests
• Lowers response latency for frequently accessed contract data
• Minimizes load on Stellar RPC infrastructure

Technical Details

Location

src/cache/contracts/stellar/

Cache Flow

1. Request for contract invocation received

2. Cache key generated from invocation parameters

3. Cache checked for existing valid response

4. If cache hit:

   • Return cached result immediately

5. If cache miss:

   • Execute Soroban RPC call
   • Store response in cache with TTL
   • Return fresh result

Acceptance Criteria Coverage

• ✅ Invocation cache implemented
• ✅ Contract invocation responses are cached
• ✅ Cache expiration policies supported
• ✅ Repeated requests reuse cached results when available

Testing

Verified Scenarios

• Cache miss triggers RPC invocation and stores result
• Cache hit returns cached response
• Expired entries are automatically refreshed
• Different contract methods generate unique cache keys
• Different parameter sets create separate cache entries

Impact

This implementation significantly reduces redundant Soroban RPC traffic, improves application responsiveness, and provides a scalable foundation for future blockchain data caching strategies.
Closes #356