[Epic] M1: Support temporary and persistent storage

[konnov]

Soroban has unusual features regarding data persistence. We are not accounting for that currently.

---

Some high-level issues; for the full list, see the milestone

• Fetch other contract's storage changes #121
• Fetch persistent and temporary storage #126
• Handle ledgerEntryRemoved #122
• Instrument other contract storage #124
• Instrument persistent and temporary storage #125

[andrey-kuprianov]

It looks like this is going to be a problem

            durability: xdr.ContractDataDurability.persistent(),

The problem is that durability represents independent keyspaces in ledgers, see here https://developers.stellar.org/docs/learn/smart-contract-internals/state-archival. In particular:

const EXAMPLE_KEY: Symbol = symbol_short!("KEY");
env.storage().persistent().set(&EXAMPLE_KEY, 1);
env.storage().temporary().set(&EXAMPLE_KEY, 2);

env.storage().persistent().get(&EXAMPLE_KEY); // Returns Ok(1)
env.storage().temporary().get(&EXAMPLE_KEY); // Returns Ok(2)

i.e. persistent , temporary , and instance are all independent keyspaces, and they all are used in various combinations in contracts. Thus retrieving only the keys which are persistent would be a heavy mistake on our side.

As our setter contract uses instance storage, but it seems to work when being retrieved as persistent, then most probably persistent and instance are the same from the retrieval perspective... But the storage API still distinguishes between them; probably that's for setting the TTL. Otoh temporary should surely fail to be retrieved as the above code snippet demonstrates.

Here are the examples of usages of all three qualifiers:

• Timelock uses instance
• Token::balance uses persistent
• Token::allowance uses temporary

One way to test that would be to deploy both Timelock and Token contracts, and to try fetcher on both of them. But I did have problems with the Token contract, specifically with the allowance part... So another way would be to extend the Setter contract with some storage variables of all three kinds, and test on it.

[thpani]

I've extended the setter contract like this:

env.storage().instance().set(&MY_U32, &zero_u32);
env.storage().temporary().set(&MY_U32, &1_u32);
env.storage().persistent().set(&MY_U32, &2_u32);

It appears that persistent, instance and temporary indeed are three separate address spaces:

vscode ➜ /workspaces/solarkraft/ContractExamples (th/qol-tests) $ soroban contract invoke --source-account alice --id CB3YKTHSSIZPVKHBFWSSFHMYU3M4V27GE2CJK6NZVBIXMT2HRZ2HXBJR --network testnet -- get_u32
0
vscode ➜ /workspaces/solarkraft/ContractExamples (th/qol-tests) $ soroban contract read --durability temporary --source-account alice --id CB3YKTHSSIZPVKHBFWSSFHMYU3M4V27GE2CJK6NZVBIXMT2HRZ2HXBJR --network testnet --key MY_U32
MY_U32,1,1954002,1971281
vscode ➜ /workspaces/solarkraft/ContractExamples (th/qol-tests) $ soroban contract read --durability persistent --source-account 
alice --id CB3YKTHSSIZPVKHBFWSSFHMYU3M4V27GE2CJK6NZVBIXMT2HRZ2HXBJR --network testnet --key MY_U32
MY_U32,2,1954002,4027601

Although, for some reason soroban contract read does not support instance durability, so I had to soroban contract invoke instead.

[thpani]

In addition to keying the storage by contract id (#121), we will need to key the storage by durability.