sigma0-xyz / zkbitcoin

zkBitcoin: zero-knowledge proofs on Bitcoin!
MIT License
161 stars 31 forks source link

limit memory growth of a node #2

Closed mimoo closed 6 months ago

mimoo commented 6 months ago

A node keeps track of signing tasks locally:

signing_tasks: RwLock<HashMap<Txid, LocalSigningTask>>

they might grow that hashmap infinitely if they don't perform the second round of a LocalSigningTask, which is created during round 1 but only deleted at the end of a round 2.

Thus, we should limit that growth. Naive solution is to also keep track of a queue last_tasks: Vec<Txid> that is limited in size (maybe 100?), and when we reach its capacity then pop the oldest inserted element and remove it from the signing_tasks as well. We should also log the fact that we reached the capacity. A sure way of not blocking the network is to have a log when we reach half the capacity, a quarter of the capacity, etc.

mimoo commented 6 months ago

from @imikushin which is also a good idea:

perhaps notify nodes to abort generating their signature share if we don't need them anymore

ppoliani commented 6 months ago

@mimoo the idea of having a last_tasks vector is pretty simple and easy to understand. We could also wrap this logic inside a custom generic structure e.g. CappedHashMap.

ppoliani commented 6 months ago

Regarding this comment

perhaps notify nodes to abort generating their signature share if we don't need them anymore

I believe this should be part of a separate PR. The current WIP implementation of the CappedHashMap will return Some(key) when inserting a new task. key is the key that is removed when the collection reaches full capacity.

So whoever calls this function can check if a key was removed and then notify the other nodes about this.