# Hived work (blockchain node software) ## SQL account history plugin In the last week or so, we continued our work on the SQL account history plugin. Don’t be confused by the name of this plugin: while it can and will function as a very fast replacement for the rocksdb account history plugin, its primary purpose is to lay the foundation for “modular hivemind” (an application framework for 2nd layer applications). We added support for resuming a hived replay configured with the SQL account history plugin. This support is also necessary for enabling the use of this plugin when operated in conjunction with a hivemind running in “live sync” mode. The SQL account history plugin also now populates the database with block and transaction signatures needed for get_block api calls. Finally, we added code to drop/restore the SQL indexes associated with the account history data to enable faster hived replays (this can be useful, for example, if no hivemind sync is happening at the same time). ## Other work on hived We reviewed recent changes in the hived code, which resulted in some code fixes and code reformats and new unit tests. We also did some preliminary reviews of current merge requests for hived. # Modular Hivemind (2nd layer application framework) ## Syncing hivemind from SQL account history plugin databases Hivemind can now run an “initial sync” directly from the postgres data generated by the SQL account history plugin. We repeated the “initial sync” of hivemind that died near the end during our previous test (running for 49.58M blocks) and confirmed that it takes just under 46 hours (just under two days). For comparison, a hivemind sync using the old “pull” process with all our other recent optimizations still took 61.2 hours. The final database size for this test was: SQL account history-generated data (~1.1 TB) + hivemind sync-generated data (~0.5 TB) for a total size of 1.6 TB. ## Experimenting with Postgres extensions for fork handling One of the key challenges for modular hivemind is automated support of fork handling, to remove this burden from 2nd layer applications. Currently we’re experimenting with the use of C-based postgres extensions to help accomplish this task. ## Miscellaneous changes to hive sync We eliminated use of some SQL constructs in hivemind sync that obtained exclusive locks on tables and therefore prevented database dumps from being run concurrently with a hivemind sync. Without this change, a hivemind server operator would need to temporarily disable his hivemind server in order to make a database backup. ## Official hivemind release v1.24.2 We completed testing of the develop branch, then merged all our latest work on hivemind to the master branch, tagged it as v1.24.2. We notified all API node operators that they should upgrade to v1.24.2 as soon as practical, as it contains not only optimizations and the exclusive lock fix, but also various bugfixes related to hivemind indexing and API responses. # Condenser (https://hive.blog code base) We finished fixing condenser bugs related to the follows, mutes, and decentralized lists, and deployed a new version of hive.blog with the fixes. At this point, we’ve completed and tested all work on decentralized lists. # Plans for next week On hived side, we’ll continue working on changes for HF25 (vote expiration for governance changes, curation vote window changes, merge request review, etc). Depending on how much time we have, we may take a look at the HBD interest code, now that witnesses are experimenting with enabling HBD interest payments. I’ve also considered adding a mechanism for helping to maintain the HBD peg if we have time. I’ll write a post about it if we make enough progress on other fronts in the next week or so that it seems feasible to fit the enhanced pegging mechanism into HF25. For modular hivemind, we’ll continue to explore ways to automate fork-handling. On the optimization front, we’re experimenting with python profiling to see if we can further reduce the time for a hivemind initial sync from SQL account history data. For a visualization tool, we’re using kcachegrind. We also want to look at combining the process of replaying hived with the SQL account history plugin (which takes about 11 hours) while running a hivemind sync simultaneously (which takes 46 hours). Currently these process are running sequentially, which takes 11 + 46 = 57 hours. By running them concurrently, I believe we can reduce the overall time to nearly just the time of the hivemind sync (i.e. 46 hours currently). As a reminder, previously this process took 17 hours for a hived replay with rockdsb account history + about 96 hours for a hivemind sync, before we began optimizations of sync time.

See: 6th update of 2021 on BlockTrades work on Hive software by @blocktrades