[bisq-network/proposals] Add quick-dao-startup mode (#266)

chimp1984 notifications at github.com
Tue Oct 20 02:39:37 UTC 2020


> _This is a Bisq Network proposal. Please familiarize yourself with the [submission and review process](https://docs.bisq.network/proposals.html)._

<!-- Please do not remove the text above. -->

If a user has not started Bisq for a while the DAO sync can be quite heavy and as it runs on the UI thread it can slow down UI quite a bit on low end machines. Many users do not use the DAO at all (if not paying trade fee in BSQ). I think we should try to find a solution to lower the burden for those users.

One option would be to check when the app was last time used and if it exceeds a certain period (e.g. 5 days) the initial BSQ blocks request is replaced by a new request where the seed is providing the full dao state data. That would be the mutable data structures + the missing (immutable) blocks. The mutable data is about 7.5 MB [1] and the missing blocks are about a few 100kb. The data sent are thus much larger as when only requesting the blocks but the user do not need to run validation over 100s or 1000s of blocks, so its a trade-of traffic vs performance. The user should be able to disable that automatic feature in the settings (or define the duration when it gets triggered). 

Of course those nodes do not contribute to secure the validation of BSQ and they put higher trust into the seed nodes as it is now. But any invalid data would be detected by the in-app dao state hash monitor and most more active users would run the full validation anyway.

As 7.5. MB is quite a bit heavy we have to look into solutions to reduce the size for the muatble data. The bigger ones are are maps with tx output id as key. We might use a similar model as with sending the hashes of the data we have to be excluded from responses from seed nodes at initial data requests. The txo ids are still quite large to send as exclude keys to the seeds (about 3 MB) so it would require probably a wrapper to create a 20 byte hash. SpentInfoMap has 47492 entries atm, so with 20 bytes it would be about 100 kb for the request. The response would still contain the full map entry but it can be expected that it will not be that many missing items.

We could also consider to redesgin the data model to break it up in individual db files and use the existing getData requests to deliver those data as well. 

[1]
Size in bytes if the data inside daoState. Blocks are the main part  with 77 MB followed by getSpentInfoMap with 6.5 MB.

```
Oct-19 21:25:56.071 [BisqSetup-readFromResources] ERROR b.c.dao.state.model.DaoState: getBlocksList 77570139 
Oct-19 21:25:56.073 [BisqSetup-readFromResources] ERROR b.c.dao.state.model.DaoState: getCyclesList 936 
Oct-19 21:25:56.076 [BisqSetup-readFromResources] ERROR b.c.dao.state.model.DaoState: getUnspentTxOutputMapMap 668023 
Oct-19 21:34:05.452 [BisqSetup-readFromResources] ERROR b.c.dao.state.model.DaoState: getSpentInfoMapMap keys 3134618 
Oct-19 21:34:05.454 [BisqSetup-readFromResources] ERROR b.c.dao.state.model.DaoState: getSpentInfoMapMap valued 3328132 
Oct-19 21:25:56.097 [BisqSetup-readFromResources] ERROR b.c.dao.state.model.DaoState: getSpentInfoMapMap 6455270 
Oct-19 21:25:56.098 [BisqSetup-readFromResources] ERROR b.c.dao.state.model.DaoState: getIssuanceMapMap 81178 
Oct-19 21:25:56.099 [BisqSetup-readFromResources] ERROR b.c.dao.state.model.DaoState: getConfiscatedLockupTxListList 0 
Oct-19 21:25:56.099 [BisqSetup-readFromResources] ERROR b.c.dao.state.model.DaoState: getParamChangeListList 925 
Oct-19 21:25:56.101 [BisqSetup-readFromResources] ERROR b.c.dao.state.model.DaoState: getEvaluatedProposalListList 98088 
Oct-19 21:25:56.110 [BisqSetup-readFromResources] ERROR b.c.dao.state.model.DaoState: getDecryptedBallotsWithMeritsListList 1183309 
```

-- 
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/proposals/issues/266
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20201019/9048913c/attachment.html>


More information about the bisq-github mailing list