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 completed changes to the get_block_api plugin to speedup performance for the get_block API call. The old implementation used an overly pessimistic mutex locking scheme that severely degraded potential performance under loading. We’ve also added a new API call to fetch a consecutive set of blocks in one disk read operation. Unfortunately, due to delays related to several hash computations (including one associated with getting the signee key of the block) and conversion of the binary block data to fc::variants and later to json, these API calls are still too slow for the needs of hivemind initial sync. To overcome this problem, we’re now creating a hived plugin that can directly write the needed data into hivemind’s database during hive reindexing and normal block reception. Most of the data being provided by get_block_api is of no interest to hivemind, so using this API to get the data was unnecessarily wasting CPU, in addition to slowing down hivemind. I expect that using the plugin approach will lead to significant speedup in the initial sync time for hivemind (my guess now is 2x at least) and it should also reduce normal hivemind live-sync write time. ## Hived status We’ve tagged a version v1.24.7 which contains the new `get_block_range(starting_block_num, count)` API call as well as the fix to make the legacy get_account_history API use 0-based operation index like the get_account_history_rocksdb plugin does. v1.24.7 is a recommended upgrade for API node operators, but it doesn’t contain changes needed by witness nodes or exchanges. It doesn’t require a reindex from the previous v1.24.6, as it is strictly contains API-related changes. # Hivemind (2nd layer microservice for social media applications) Most of our Hive devs continued to working on hivemind last week. Below are some of the merge requests incorporated into the develop branch of the hivemind repo: performance optimizations: various bug fixes: new tests: test system improvement: # Condenser + Condenser wallet (open-source code for ****) The bug editing comments was fixed: Fix for wallet proposals page where non-burn proposals were being displayed as burn proposals: We’re also testing and fixing bugs in the UI for creating decentralized lists: # Nearing completion of airdrop proposal re-payment I’ve refunded the overage of Hive from HBD→Hive conversions to the account (when I converted some of the HBD to Hive, there was a slight overage of Hive due to the unpredictable amount that the conversion will yield). Once the proposal completes, I will compute and refund the HBD overage back to the account as well. # What’s the plan for next week? * Finish hivemind and condenser muting changes. We’ve partially completed an additional change to condenser to allow a condenser operator to specify a “default observer” when a user isn’t logged in. This allows the condenser web site operator to specify their own initial list of spammers to be muted (for example, to protect their SEO results) that will function prior to a user’s login. For example, we’ve using the account as the default observer for the site. * Enable reputation calculation code. * Continue creating hivemind tests. * We’re prioritizing the speedup of hivemind full sync via a hived plugin as the slow sync time has a big impact on the speed of hivemind CI (which sets an upper limit on how fast we can validate changes). * Still hoping to get out a post with a comprehensive list of planned changes for HF25 and for 2nd layer improvements soon (although the hived plugin for dumping directly to PostgreSQL is one of the planned major 2nd layer improvements: it’s just getting fast-tracked because it impacts our current work a lot).

See: Update on BlockTrades Hive Work (Nov 16th) by @blocktrades