BlockTrades update on Hive development work

Last week we continued work on post-HF24 optimizations. Below is a summary of the work done last week and our plans for the upcoming week.

Hived work (blockchain node software)

We added reporting of some virtual ops related to hive fund for better accounting by a block explorer (done in conjunction with Hive account@howo):
https://gitlab.syncad.com/hive/hive/-/merge_requests/144
https://gitlab.syncad.com/hive/hive/-/merge_requests/135

We made fixes to filtering of get_account_history functionality and a fix to the legacy get_account_history plugin (it used a 1-based indexing of operation history instead of a 0-based indexing like the get_account_history_rocksdb plugin, now they both use 0-based indexing):
https://gitlab.syncad.com/hive/hive/-/merge_requests/145
https://gitlab.syncad.com/hive/hive/-/merge_requests/146
https://gitlab.syncad.com/hive/hive/-/merge_requests/148

Fixes to hived API tests:
https://gitlab.syncad.com/hive/hive/-/merge_requests/141

Miscellaneous:
https://gitlab.syncad.com/hive/hive/-/merge_requests/147 (set reported version to 1.24.6)

We’re currently working on a major optimization to the get_block_api plugin that should likely provide a big boost in performance for the get_block API call (this will likely enable us to speed up the hivemind “full sync” process as well). The old implementation used an overly pessimistic mutex locking scheme that severely degraded potential performance under loading.

Hived status

We completed all tests on changes made in the previous week and this week and there are no known outstanding issues with hived operation (other than the known longstanding issue with servicing of API requests during startup of a hived node).

We plan to tag v1.24.7 as soon as we complete the optimizations to the get_block_api plugin. V1.24.7 will be a recommended upgrade for API node operators, but it doesn’t contain changes needed by witness nodes or exchanges.

Hivemind

Due to the rapid pace with which changes are being made to hivemind, we also started upgrading our automated build-and-test (CI) system to support building on multiple gitlab runners so that our devs could get faster feedback on changes they make.

The primary challenge was to setup more than one system configured for performing a hivemind sync and to allow troubleshooting in the case of test fails). For speed reasons, hivemind’s CI system is configured to only sync to the 5 millionth block, but we’re adding an option to do testing with a full sync as well (via a manual trigger, as this test is much more time-consuming).
https://gitlab.syncad.com/hive/hivemind/-/merge_requests/327
https://gitlab.syncad.com/hive/hivemind/-/merge_requests/340

We also introduced mock data providers to allow testing of operations that didn’t occur by the 5 millionth block:
https://gitlab.syncad.com/hive/hivemind/-/merge_requests/336

Hivemind status (2nd layer social media microservice)

We deployed all the above changes to hived and hivemind to our production node, api.hive.blog, and they’re working well. We still have a few optimizations to make (mostly importantly, further speedups to unread_notifications which averages around 1.5 seconds to complete right now).

We created a data dump of our hivemind database and several other API node operators have used that data dump to update their node and begin serving data with the latest code.

Condenser + Condenser wallet (open-source code for hive.blog)

The most visible change that BlockTrades made to condenser last week will likely be deployed tomorrow. This change will update the vote information for a post 9 seconds after the user does an upvote or a downovte on the post:
https://gitlab.syncad.com/hive/condenser/-/merge_requests/136

What’s the plan for next week?

We’ll be finishing up a few more optimizations to hived and hivemind. In addition to speeding up API calls for both, we’re also going to look at speeding up the hivemind full sync time (currently it takes 4 days). And we’ll continue filling out the test cases in the automated testing suites for both projects.

I’d hope to begin analysis of future features for Hive (both for hardfork 25 and for 2nd layer apps support), but most of our time last week was consumed with optimization of the current system. We did make a little headway on this issue in the Hive developers meeting we had earlier today, though.

I’ll make a post later this week in the Hive improvements community on some of the features we’re considering both for HF25 and for 2nd layer features (all the hardfork features are ones that have been previously discussed many times by the Hive community and have met general approval).

One of the nice things about the architecture we’re moving Hive towards is that we can now add more capabilities to Hive without requiring a hardfork to do so. We will still need to do a hardfork when we make governance improvements, of course, but for many of our future features, these features can be released as they become ready, without having to coordinate their release with other features and with exchanges.