![blocktrades update.png](https://images.hive.blog/DQmSihw8Kz4U7TuCQa98DDdCzqbqPFRumuVWAbareiYZW1Z/blocktrades%20update.png)

Below are a few highlights of the Hive-related programming issues worked on by the BlockTrades team since my last post.

# Hived (blockchain node software) work

### Refactoring of transaction and block handling code

The primary change associated with this code refactoring is the creation of new `full_transaction` and `full_block` objects to avoid unnecessarily repeating previous computations. These objects are wrappers around the old transaction and block data and they also contain metadata about the original data (for example, a full_block can contain: the compressed binary block data, an uncompressed binary version of the block, the unpacked block decoded into a block header and associated transactions, and various metadata such as the block_id). 

This week, we did a “sync hived from scratch” benchmark with just the above change (none of the changes discussed below yet included) and sync time was down to 23.5hrs (previously took around 48hrs after our p2p optimizations from a while back, and took about a week before that). So, all told, over a 7x speedup so far versus the production version of hived.

We completed the basic refactoring above as of my last report, so this week we focused on further optimizations now available to us after these changes, as discussed below:

### Blockchain thread pool added to speed up block/transaction processing

Probably the most significant such optimization, both now and for the long term, is we’ve added a thread pool that can be used to handle any work that doesn’t need access to chainbase (blockchain state data). This thread pool allows us to speedup a variety of computations that previously loaded down the write_queue thread (block compression/decompression, crypto calculations, pre-checks on operations, etc). 

These changes will result in very significant performance improvements for replay, sync, and live sync modes. We’re still running or setting up benchmarks to measure sync and live sync speedups, but even in basic replay tests where we expect to see the least improvement, we’ve seen a decent speedup: replay time on an AMD 5950X with a 4xnvme raid is down to 5hrs 54mins (with chainbase stored on the nvme raid, not in memory!).

By default, the thread pool is allotted 8 threads, but the thread pool size can be overridden at hived startup using a new command-line/config file option: `--blockchain-thread-pool-size`.

### New json parser for validating custom_json operations (layer 2 operations)

Separately, we also replaced the json parser used to validate custom_json transactions (>60x faster for json validation). Give the large number of custom_json operations stored in the blockchain, this will reduce CPU load substantially. Further improvements can still be made later: we’re not yet using this parser for the API web server and it would provide significant benefits there as well.

### Adding block ids to block_log.index

Currently we don’t directly store block ids in the block_log or block_log.index files, so these had to be dynamically re-computed at run-time, which is computationally expensive (this required block log file to be read, block to be decompressed, hash of block_header to be computed). Retaining these ids in the block_log index will speed up several places where such data is required. The “first round” (and maybe only round, depending on performance results) of this task is expected to be completed tomorrow, then we’ll run benchmarks over the weekend.

In the next phase of this task, we’ll begin benchmarking this new version of the code and experiment with further optimizations.

### Further optimization of OBI (one-block irreversibility) protocol

The optimizations to the OBI protocol are mostly done, but the dev for this work is currently tied up with the refactoring of the transaction and block handling code (task discussed below), so it still needs to be fully completed tested, but I don’t expect this task to take long once it resumes. Based on above rapid progress in blockchain processing optimizations, I believe we should be able to resume and finish optimizations to OBI by sometime next week.

### Hived tests

We continued creating tests for the latest changes, and identified another easily fixed bug in the new code for transaction serialization (problematic code generated two copies of the asset for fee for witness update operation).


# Hive Application Framework (HAF)

We’ve begun re-examination of scripts for backup of HAF database and HAF apps in light of changes to HAF since scripts were created. I expect this task will be completed soon.



# HAF-based hivemind (social media middleware server used by web sites)

We found and fixed a few more issues with HAF-based hivemind last week and we’re testing them now with full syncs and live syncs. I think we’re mostly done here, so remaining big task is to create and test a docker for it to ease deployment.

# Some upcoming tasks

* Allow hived nodes to directly exchange compressed blocks over p2p network.
* Finish up storage of block ids in block_log.index file.
* Test, benchmark, and optimize recent changes to blockchain and p2p layers of hived
* Merge in new RC cost rationalization code (this is blocked by hived optimizations task above because those changes will impact real-world costs of operations).
* Test enhancements to one-block irreversibility (OBI) algorithm.
* Finish testing and dockerize HAF-based hivemind and use docker image in CI tests.
* Test above on production API node to confirm real-world performance improvements.
* Collect benchmarks for a hafah app operating in “irreversible block mode” and compare to a hafah app operating in “normal” mode (low priority)
* Continue testing hived using updated blockchain converter for mirrornet.

# When hardfork 26?

Based on progress this week, we’re still on track for a hardfork at the end of July. We’ve updated the HF date in the develop branch to reflect this plan, and if no surprise issues pop up before Monday, it will be time to notify exchanges of the planned hardfork date.