Fix/fallback sequential for sync methods

[Syzygy106]

Motivation

Fixes #3186

The FallbackLayer implementation was using parallel fan-out for all RPC methods, which caused issues with methods that have non-deterministic results when executed concurrently across multiple nodes.

Specifically, eth_sendRawTransactionSync (EIP-7966) waits for a transaction receipt. When executed in parallel, for example:

• Node A (slow): Processes the transaction and returns the receipt after 100ms
• Node B (fast): Recognizes the transaction as "already known" and returns an error after 10ms

The FallbackLayer would incorrectly return the fast "already known" error instead of waiting for the actual receipt from the slower node.

Solution

Introduced selective execution strategies based on result determinism:

1. Added requires_sequential_execution() function - Identifies RPC methods that return non-deterministic results when executed in parallel:

   • eth_sendRawTransactionSync (EIP-7966)
   • eth_sendTransactionSync

2. Added make_request_sequential() method - Implements sequential fallback that tries transports one-by-one until success, respecting the ranking system.

3. Modified make_request() - Routes non-deterministic methods to sequential execution while keeping parallel execution for all other methods (including eth_sendRawTransaction, which returns a deterministic transaction hash).

Key Design Decision: Not all stateful methods require sequential execution. Methods like eth_sendRawTransaction are stateful but return deterministic results (transaction hashes), making parallel execution safe and beneficial for performance.

Representation -

/// # Before Fix (Parallel Execution):
/// Time       Transport A               Transport B
/// ─────────────────────────────────────────────────────────
/// 0ms        🚀 START                  🚀 START (parallel!)
///            │                         │
/// 10ms       │ Processing...           ✓ "already_known"
///            │                         └──> Returns ❌ WRONG!
/// 50ms       ✓ Receipt {status: 0x1}
///            └──> Discarded (too late)
/// 
///
/// # After Fix (Sequential Execution - Success Case):
/// 
/// Time       Transport A               Transport B
/// ─────────────────────────────────────────────────────────
/// 0ms        🚀 START
///            │
/// 10ms       │ Processing...           (not called yet)
///            │
/// 50ms       ✓ Receipt {status: 0x1}  (not called - A succeeded!)
///            └──> Returns ✅ CORRECT!
/// 
///
/// # After Fix (Sequential Execution - Fallback Case):
/// 
/// Time       Transport A               Transport B
/// ─────────────────────────────────────────────────────────
/// 0ms        🚀 START
///            │
/// 10ms       │ Processing...           (waiting...)
///            │
/// 50ms       ❌ Connection timeout
///            │
/// 51ms       (A failed, trying B...)  🚀 START
///                                      │
/// 61ms                                 │ Processing...
///                                      │
/// 101ms                                ✓ Receipt {status: 0x1}
///                                      └──> Returns ✅ CORRECT!

PR Checklist

• Added Tests
  • test_non_deterministic_method_uses_sequential_fallback - Verifies eth_sendRawTransactionSync uses sequential execution and returns correct receipt
  • test_deterministic_method_uses_parallel_execution - Verifies eth_sendRawTransaction continues using parallel execution for performance
• Added Documentation
  • Comprehensive inline comments explaining the logic
  • Function documentation for new methods
• Breaking changes

[mattsse]

smol suggestions

[mattsse]

can we make this a hashset in the fallbacklayer itself, with these values as the default, then a user can install addiitonal ones on demand

[Syzygy106]

can we make this a hashset in the fallbacklayer itself, with these values as the default, then a user can install addiitonal ones on demand

ok, let me think about it

[mattsse]

this makes sense

[mattsse]

ty!