11th update of 2021 on BlockTrades work on Hive software

in HiveDevs4 months ago (edited)

blocktrades update.png

Below is a list of Hive-related programming issues worked on by the BlockTrades team during the last week:

Hived work (blockchain node software)

Last week we’ve been focused on testing hived in preparation for a final feature freeze and fixing bugs as we find them. So far most of the bugs we’ve found are very old bugs that have been around for many years.

We fixed two bugs we found and discussed in last weeks report:

  1. Better warnings and less cpu-loading when node gets no peers at startup
  2. Fix to beem to fix update_proposals test

During benchmarking of hivemind sync on two similarly configured systems, we found one system was syncing much slower than the other one. After a fair amount of debugging effort, we ultimately were able to trace this back to intermittent errors on one of the disks in the raid array where hived stored it’s data, but more interestingly, this also exposed an error that was introduced over 5 years ago (ie. when this code was in the BitShares graphene repo).

This bug caused incoming blocks that are not yet linkable to the node’s head block to be discarded instead of being kept for future usage, once intervening blocks were received.

On normally functioning hardware, this was no big deal, but in the case where disk IO performance was strained (in this case due to intermittent disk errors), this error led to the node often dropping peers and generally straining to keep in sync with the rest of the p2p network.

Note that this is a practical real world problem, not just a theoretical one, as we believe this problem led to one commonly used exchange having problems maintaining their Hive wallet open for deposits. At the time, the problem was resolved by convincing the exchange to move their Hive wallet to another computer, but it’s obviously better to have Hive nodes more resistant to such issues.

We fixed this bug in these two merge requests:

As part of the above work, we had to dive pretty deep into profiling the performance of hived when processing transactions and blocks, and we identified several places where we would like to improve performance in the future, after the hard fork is completed. The majority of such changes can be released at any time, as they don’t require consensus changes.

To facilitate our profiling work, we also made changes to how timestamps are represented in hived logs. By default, timestamps are now stored as UTC times with milliseconds resolution in files and seconds resolution on the console, with the option to store the timestamps with microseconds resolution when needed for profiling: https://gitlab.syncad.com/hive/hive/-/merge_requests/229

We added a script that automatically code-generates the get_config api call, so that when new parameters are added to the blockchain, these parameters are automatically added to the output of this call. This script is executed by CMAKE at build time. https://gitlab.syncad.com/hive/hive/-/merge_requests/211

We fixed several longstanding errors with the account history plugin:
Under rare circumstances, the account history plugin could include duplicate records of an operation in an account’s history as a result of microforks because the notification of last irreversible block was sent to the plugin too early:
The wrong number of operations could be returned by get_account_history because of miscounting of effective_comment_vote_operation:

We also reviewed and merged in @howo’s changes for recurrent transfers today:

Finally, we reviewed and approved @howo’s proposed implementation for resource credit (RC) delegations: https://gitlab.syncad.com/hive/hive/-/issues/152 We will be able to incorporate this change after the hardfork, as it doesn’t require any consensus changes.

Hivemind (2nd layer applications + social media middleware)

Our work in hivemind last week has also revolved around testing performance and fixing bugs.

We ran full hivemind syncs to test the new code that deep cleans the dictionaries to cut a few gigabytes of memory from hivemind’s memory footprint. The new code worked well, and without any apparent performance problems, but we’ll need to repeat the tests again to obtain final performance numbers, as we got distracted by the hived performance issue we found during this testing (discussed earlier in hived section of this post).

We made several fixes to hivemind:

We found another issue with hivemind that is still under investigation, so we’re not quite ready to make a new release candidate for hivemind yet, but I’m hopeful we’ll still be able to do so by the end of this week as originally planned. The timeframe will be tight, as we still need to merge in several of the above changes to the develop branch and do real-world performance testing on api.hive.blog.

Modular hivemind (framework for hive applications)

During documentation and discussion of the fork resolution code for hive using SQL shadow tables, some concerns were raised about issues where a modular-Hive based application could hold a transaction open, preventing the fork-resolving code from swapping to a new fork, so we’re looking at various ways to manage this issue.

We didn’t have time to make the changes for the sql serializer last week due to the time spent fixing the various issues discussed in this post, but we will likely complete that work in the coming week. Then we’ll be able to do a full performance test of the sql serializer in combination with a full sync of hivemind.

Condenser (code base for https://hive.blog)

We incorporated several fixes to condenser and deployed them on hive.blog:
Search fix by @quochuy: https://gitlab.syncad.com/hive/condenser/-/merge_requests/246
Iframe fix by @mahdiyari: https://gitlab.syncad.com/hive/condenser/-/merge_requests/249
Fix for 3speak.tv domain by @jes2850: https://gitlab.syncad.com/hive/condenser/-/merge_requests/251
Api node selection fix by @jes2850: https://gitlab.syncad.com/hive/condenser/-/merge_requests/254

Hived testnet

We’re planning to launch an updated testnet on Wednesday with the latest fixes to hived discussed above. We’ll be tagging this version of hived as an official release candidate.

That will be followed by the launch of an API node configured to draw data from the testnet (probably on Thursday). This API node will allow Hive applications to begin adding code changes to support new features added by the hardfork, such as vote expiration reporting.

Planned date for hardfork 25

Based on our testing experience so far, I’m currently projecting the hardfork will be in the latter part of June (about a week or so past my earlier “best case” projection).

Assuming no major problems are discovered in the coming week with the release candidate, we’ll next begin notifying exchanges in order to give them 30 days notice which should be plenty of time to update their wallets before the hardfork.


Can we please delay the HIVE-> HBD conversion to stack the profit in the DHF instead of everyone with a deep pocket of Hive?
40% on 1mill Hive is a lot more than 40% profit on 10k Hive... unfair.

The downward pressure from the stabilizer proposals is increasing at a fairly rapid rate as the DHF budget increases. By the time we're ready for the hardfork, it wouldn't surprise me if the price of HBD hasn't been driven down to near $1. As of this moment, I'd guess the stabilizer is providing close to 5% of the daily trading volume for HBD. And it could be twice that by the earliest potential hardfork date.

But I certainly wouldn't be opposed to a couple of weeks delay in the HF, if HBD price is much more than $1 at the point. You're not the first person to suggest delaying until the stabilizer has substantially stabilized the price of HBD and a number of people (including me) feel such a delay would be worth the benefit, if HBD price is still high at the projected hardfork time.

Ultimately, the decision will be up to witnesses (and indirectly, the stakeholders who vote for them) as to when they want to update to the new version and trigger the hardfork.

I would be in favor of waiting until HBD gets below 1.05 to trigger the conversions, to avoid a mad rush of conversions (which seems bad for various reasons). However, there is a clear tradeoff with complicating the release and forking process. If the price is pretty close, even if if a bit above 1.05, it probably makes sense to just let it go. If HBD runs back up to $2 or something, then I'd be in favor of letting the stabilizer continue to grind it down for as long as it takes, and continue to contribute the trading profit to DHF.

Is it possible for witnesses to temporarily increase the rate of conversion of Hive to HBD in the DHF? So we can get a higher daily budget for the stabilizer. Otherwise we may have to wait for months if the bull cycle continues for a while and HBD keeps getting pumped.

Hive sent to the DHF is instantly converted, so when the stabilizer sends Hive to the DHF, this becomes HBD immediately. Unfortunately, due to specification change to the proposal system, only 1% of this HBD is immediately available to fund proposals.

Also, the initial Hive supplied to the DHF was hardcoded to be slowly converted to HBD, and the witnesses don't have control over this rate.

Despite all that, the amount of HBD available to fund the stabilizer proposals is increasing at a reasonably fast rate.

Finally, we reviewed and approved @howo’s proposed implementation for resource credit (RC) delegations: https://gitlab.syncad.com/hive/hive/-/issues/152 We will be able to incorporate this change after the hardfork, as it doesn’t require any consensus changes.

This is very intriguing news..a major change to the ecosystem I would say.

I think the primary use case is to ease onboarding for Hive apps that create accounts for new users. This will enable them to create new accounts and delegate RC rather than HP, which lowers the incentive for bad actors to try to game the account creation faucets for profit.

can be also used to support cool apps that don't have a large budget to buy hive. RCs for Tokens for example :)

This change is one that's easy to overlook in the rest of the notes, but has really exciting potential applications specifically for things like onboarding and helping out to grow a new userbase. I'm really excited to see how this works once it's in play.


This will make us much more apt to create an auto-delegation system that checks any user wanting to use peakd.com

I don't understand it very well because technical terms are not my thing. But reading how much hard work you did like testing it, observing it, or doing a change for it. I'm grateful for the information you keep on updating us.

I hope it will be successful and there will be no issues.

Thanks for the update and the excitement!

Great job! Thanks for updates

Congratulations @blocktrades! You have completed the following achievement on the Hive blockchain and have been rewarded with new badge(s) :

You received more than 1130000 HP as payout for your posts and comments.
Your next payout target is 1135000 HP.
The unit is Hive Power equivalent because your rewards can be split into HP and HBD

You can view your badges on your board and compare yourself to others in the Ranking
If you no longer want to receive notifications, reply to this comment with the word STOP

Support the HiveBuzz project. Vote for our proposal!

What will be new on HF 25 in super easy words to understand for everyone? :)

Thanks, I know that post already. I was not sure something new pop up at this time :)

We're doing our best to avoid "surprise" new features as we prepare for HF :-)

I’m currently projecting the hardfork will be in the latter part of June.

Thank you 🙏🏾