Below are a few highlights of the Hive-related programming issues worked on by the BlockTrades team since my last post.
This report is a bit late as I just recently got back from traveling to HiveFest and then traveling to Poland to meet with some of our devs there for a few days. A lot was done in that time, but I’m still time-constrained catching up with work that built up in my absence, so I’m going to make this a quick post and cover a few highlights of the past three weeks.
Hived (blockchain node software) Release candidate 3
Today we released what I expect to be the final release of hived for hardfork 26:
https://gitlab.syncad.com/hive/hive/-/tags/v1.26.0rc3
Fixes in RC3 are described here: https://gitlab.syncad.com/hive/hive/-/merge_requests/688 The most important change was the fix for the potential sync stall condition, but this was relatively rare and could be worked around by restarting the node. Other changes were just performance optimizations. No changes affecting hardfork consensus were made in this release candidate.
About a week ago, we released RC2: This release candidate fixed a few more significant fixes:
- Fixed api node crash when duplicate broadcast_transactions received
- fc:uint128 conversion to string wasn’t thread-safe
- Reduce number of block approval votes cast when switching forks
- Speedup shutdown of syncing node on slow hardware to avoid 30sec timeout that caused crash
We also worked on hived documentation, adding descriptions of new command-line options and config.ini options.
Call for Hive app devs to test against the mirrornet to prepare for the hardfork
At this point, more apps have successfully tested against the mirrornet, but I suspect that a decent number haven’t yet, so I again encourage any app dev who hasn’t yet tested their app against the mrirronet to do so ASAP. It’s really easy: just point at the mirrornet api node and change the chainid that your transaction-signing library uses.
Hive Application Framework (HAF) and related apps
We officially incorporated support for the get_block API into HAF (this will allow us to stop loading down hived nodes with get_block calls as these have traditionally been a very expensive call). We developed CI tests and benchmarks for the API. The tests allowed us to find and fix some differences in the results between hived and HAF. Hived is currently a little faster than HAF at serving up this API (although it uses more CPU power to do so) so we’re looking at ways to speed this up further.
During HAF hivemind testing we found and fixed a performance problem that occurred during livesync mode.
Work also continued on the HAF block explorer, with the focus still on the witness page right now. This is also informing some changes to the data collected by HAF via the sql_serializer.
Some upcoming tasks
- Test and update deployment documentation for hived and HAF apps (ongoing)
- Continue supporting Hive apps devs as they begin testing their app against the mirrornet
- More testing of hived release candidate on production API node to confirm real-world performance improvements
- Continued testing on the mirrornet
- Finish testing and dockerize HAF-based hivemind and use docker image in CI tests.
- Continue work on HAF-based block explorer
- Collect benchmarks for a hafah app operating in “irreversible block mode” and compare to a hafah app operating in “normal” mode (low priority)
When hardfork 26?
The new release candidate still has a date of Oct 11th, 2022 at 12:00 GMT for the time of the hardfork. Based on the relatively small number of changes made in the latest release candidate, I don’t currently see any reason to extend the hardfork date out further in time.