Key-value state caches

[nickgarfield]

Many threads need to share state between instructions. Programs are forced to save this state into an account and add the account as an input to all downstream instructions which need to read/write to it. Adding an extra account to programs can be tricky, deriving its PDA is error-prone, and mutating its data is restricted only to the program that owns it. Can we do better?

We know the thread account will be a signer on every executed instruction. Knowing this, thread accounts could provide a convenient location to save information that needs to be shared to downstream instructions. Any instruction would be able to write to a thread's cache simply by returning a KV map of data in the ThreadResponse. Downstream instructions would be able to access this data from the cache and update it.

Open questions:

• Should programs be forced to sign the data they write to the cache? This would help programs verify data authorship.
• Do programs need to care about data authorship? Or do threads provide a "trusted" computing environment?
• Should a thread's cache be deleted between each kickoff? It doesn't need to be.

[nickgarfield]

With caches, developers could use threads to solve problems like this:
https://solana.stackexchange.com/questions/4715/how-to-get-result-of-a-previous-instruction-within-a-transaction