Non-exclusive account write locks

[jstarry]

Originally posted by @godmodegalactus in #21883 (comment)

I have an idea which could be interesting in future roadmap. It involves changes both in solana and dapps with writable account which have heavy traffic. [..]

I suggest we can create a trait called Mergeable accounts which have some methods or helpers to help us accumulate the difference. Something like

fn merge(current: Account, pre_account: Account, post_account: Account) -> Result<Account>
[..] Once we have that, then for a small context or batch we can run transactions on mutable accounts implementing mergeable in parallel and then merge the difference at the end of a batch or block. Instructions which generate non mergeable states will be failed. The differences of lamports can also be accumulated easily.

This trait then can be used by dapp developers to convert accounts that are locked continuously to mergeable accounts. I guess this solution will enable to be partially multithreaded instead of being single threaded on writable accounts effectively increasing the TPS of solana.

[jstarry]

@godmodegalactus thanks for proposing this! I pulled this out of #21883 since it's not directly related to the problem stated there. Anyways, I've thought about this idea as well in the past and agree that it could be a useful tool for app developers.

Another idea I'd like to raise (might be worth another issue) is read locks that allow programs to read a slightly delayed account state such that they can't be starved by write locks.