How to store a growing list of 32 byte values?

[jagged scroll]

I am playing around with a system to implement private asset transfers (inspired by zCash, etc.). Such a system inevitably requires the contract to store a list of 256-bit hashes in order to prevent double spending -- each settled transaction adds a unique hash to the list, and checking against double spending requires checking that the new hash does not already exist.

Is there a recommendation for an appropriate storage type? Is there a sample contract that does anything like this?
For reference, a Solidity smart contract on Ethereum makes use of the construct mapping(bytes32 => bool) public nullifierHashes; .
Thanks in advance for any tips.

[shrewd sleet]

you can just do env.storage().persistent().set(hash, Val::Void) for every hash and then do a respective storage check. i.e. your abstraction is not (and does not need to be) a list, it's just a map and storage is designed to support unbounded maps.

that said, I would consider an approach that uses temporary storage when possible. that would be much cheaper. the requirement is that your payloads need to be expirable. that's the way nonces are implemented in Soroban auth framework - every signature must have an expiration ledger (up to 6 months in the future currently) and thus there is no need to store the nonce indefinitely

[jagged scroll]

Thanks! I was indeed looking for a map.
Our next step would be to store the recent hashes in temporary storage, and store a merkle tree root for the set of older hashes. So that should bound the amount of on-chain storage.

[lyric forum]

Hei @jagged scroll I am very interested in what you are building!
Here is a repo where I discuss about growing data:

https://github.com/paltalabs/instance-persistent-dos-soroban

[lyric forum]

Depending on your design, your contract can suffer a DoS attack

[jagged scroll]

That's a good point. Even considering the performance implications, we are working towards a design which maintains this state off-chain, and only stores a merkle trie root on chain. Any membership / non-membership claims will be made with respect to the on-chain root.