Pete retweetet
Solana Transaction Execution Lock Relaxation Proposal
A scheduler (both leader and replay) change that has a theoretical improvement of less than ~2x. No protocol changes needed.
Idea: Drop transaction read locks right away after loading the account state.
Why? This allows upcoming transactions that write-lock the same account to start executing immediately. Pipeline efficiency potential increases significantly (depending on shape).
How? Enforce linearizability requirements. While sub-sequent transactions write locking the same account can start execution, they cannot be recorded as before the reading transaction.
All account states are locked, read and frozen at the start of the transaction; this keeps things consistent throughout execution of the reading transaction.
The linearizability concept happens at the commit/record level; even though the reading and writing transactions might be happening at the same time; the read will always be recorded before the write.
In the case of failure; write transaction is unblocked from commit.
Now that transaction batches can be conflicting (recent change), the trade off here would be the savings of locking and loading the account in one thread and then execute sequentially versus finding an optimized boundary in the graph to split and put into another thread (paying the price for the cross-thread communication). For 'heavy' transactions this could exceed the cross-core optimization.
Generally the less restrictions for ordering, the more flexibility the execution pipeline has and the more efficiently it can schedule.
English
