[bisq-network/bisq] Deactivate DAO state monitoring as it is too slow (Issue #5779)

[chimp1984]

The DAO state monitoring is creating after each block a hash from the DAO state (excluding the blocks) + the latest block (as that contains a hash to the prev. block that is enough to ensure the whole chain is correct).
Some data like the spentInfoMap is already pretty large (about 80k entries) and serializing the data to a bytearray via protobuf serialisation and hashing it takes quite some time. This is the reason why parsing of even empty blocks takes about 100-200 ms. We could optimize a bit by serializing a big part of the data only if there have been actual changes (if no tx was added there is usually no change beside the blockheight and an empty block added), but that would only reduce the required time by about 50 ms. As we still need to add the block height and the latest block all the rest needs to be redone still (hashing, concatenating with prev hash,...).

So I do not see a good solution how to fix that, specially of we do not want to break the hash compatibility (if redesigning dao state hash creation some optimisations might help a bit, but I doubt it will be much better).

It takes about 10-15 min for syncing for a user who downloads the app after a 1 months release (about 4000 blocks). This is a pretty bad user experience.

When deactivating the monitoring it takes about 4 seconds to parse 4000 blocks!

I would recommend that we add a flag to the preferences and disable dao state monitoring by default, and let users choose to enable it if wanted. For users who are regularily online the parsing costs are not critical, but for new users or users who have not used the app since a while its a real problem IMO.

The DAO state is anyway an area which will require some larger refactoring to not cause more scaling issues. In such a process the monitoring could be redesigned as well. Not an easy task though....

Any input/feedback?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/bisq/issues/5779
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20211023/348952ef/attachment-0001.htm>