Fixed race-condition caused by multiple threads being able execute tx

[taco-paco]

At the moment transaction execution is protected b y read lock, which allows different threads execute transactions on the same writable accounts at the same time. This leads to invalid account states.

Example: RPC executes TX on magic_context & at the same time slot-ticker executes AcceptScheduleCommits tx in magic_context.
outcome: Even though accept was executed - MagicContext still contains just accepted Commits

Greptile Summary

This PR addresses a critical race condition in transaction execution by changing the synchronization mechanism in the bank's transaction processing. The change modifies the lock acquisition in load_and_execute_sanitized_transactions from a read lock to a write lock on the transaction_processor.

The issue stems from the current implementation allowing multiple threads to concurrently execute transactions that modify the same writable accounts. This is particularly problematic for the MagicBlock validator's magic_context account, which manages scheduled commits. The race condition occurs when, for example, an RPC request executes a transaction on magic_context while simultaneously the slot-ticker executes an AcceptScheduleCommits transaction on the same account. Even though both transactions might appear to succeed individually, the concurrent execution leads to invalid account states where committed changes can be lost or overwritten.

The fix ensures proper serialization of transaction execution by requiring exclusive access during the execution phase. This prevents multiple threads from simultaneously modifying the same accounts, maintaining data consistency and preventing the loss of scheduled commits or other account state corruption. The change aligns with the broader architecture where the validator manages complex state transitions through scheduled commits and account delegations.

PR Description Notes:

• Minor typo: "protected b y read lock" should be "protected by read lock"

Confidence score: 5/5

• This PR is extremely safe to merge with minimal risk of causing production issues
• Score reflects a simple, well-targeted fix that addresses a clear concurrency bug with a straightforward solution
• No files require special attention as the change is localized and the fix is architecturally sound

[greptile-apps]

_{1 file reviewed, no comments}

_{Edit Code Review Bot Settings | Greptile}

[bmuddha]

LGTM!