7th update of 2021 on BlockTrades work on Hive software

in HiveDevs6 months ago

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

Hived work (blockchain node software)

SQL account history plugin for hived

We made some fixes to the SQL account history plugin to enable proper operation with hivemind sync process:

We still have one fix to avoid a potential foreign key violation during live sync (probably will be finished tomorrow).

HF25 changes (these are described in detail in our Hive roadmap post)

We made some fixes and improvements to the code that handles expiration of governance votes (votes for witnesses and Hive Fund proposals):

We started work on voting window changes for HF25. We expect to finish implementation tomorrow, then we can begin testing.

Miscellaneous hived changes

We made a fix related to removal of expired Hive Fund proposals: https://gitlab.syncad.com/hive/hive/-/merge_requests/176

We finished review of @howo merge requests. Two have been merged to develop and one is still under review:

We also fixed an intermittent issue with hived shutdown:

We added some virtual ops to report various changes in state (mainly accounting-related) that weren’t previously reported:

Some changes to cleanup compile process: https://gitlab.syncad.com/hive/hive/-/merge_requests/172
Fix for proper testnet operation: https://gitlab.syncad.com/hive/hive/-/merge_requests/175

Hivemind (2nd layer applications + social media middleware)

Fixed a problem in master branch that caused issues when upgrading an existing hivemind database:

Fixed an issue with git version reporting: https://gitlab.syncad.com/hive/hivemind/-/merge_requests/479

Added a comand-line option to log the time required for hive server to process API requests:

Some new tests for bridge API calls:

Postgres extension for fork handling for Modular hivemind

One of the key challenges for modular hivemind (the upcoming 2nd layer application framework) is automated support of fork handling. Automated fork-handling will simplify design of 2nd layer apps so that they don't need to worry about fork-handling logic.

Currently we’re experimenting with the use of a C-based postgres extension to help accomplish this task (we’re referring to this as the SQL change-audit extension).

Last week we tested the prototype’s ability to recover the original state of an updated record in the database. Below are links to where this work is going on in the repo:


Great job team!

Thanks for your work!

Is there a date for HF25?

We'll announce a tentative HF date when we're ready for the public testnet to be setup.

and wen yield aggregator? 🤣

We don't have a firm date yet, but I guess sometime in May.

Glad that the fire has not slowed you guys down at all, looking forward to all the changes, it seems as if HF 25 is almost set and ready to go soon, that will be good in these semi boom times. We can show the world that we have built a strong foundation for second layer players, and that we do go chasing the reward pool on every hard fork, thus adding confidence that the reward pool will only be altered at real need, not perceived need.

Yes, the fire only cost us about a day of work, and it only impacted our system admins (unfortunately, I was included in that list, and I was up till about 3am last night working on hived nodes for api.hive.blog).

We're kind of in the middle of a bunch of new stuff right now, so most of this report isn't probably relatable to many of the readers, but next week we should have some performance data to report (e.g. related to postgres extension speed).

I have been trying to follow along, and while I am not a technical person it seems as if things are moving pretty good. The primary reason I have been following so close is because I strongly believed a fix was needed to the witness retention/selection so we make it ten times harder for what happened on steem to not happen on Hive. The other part is how the vast majority of Hard Forks on steem involved the reward pool and fixing things that really were not broken.

With the exception of allowing an interest payment system to finally be added to the savings account, I have not seen anything with a major shake up for the reward pool and for that I am very glad. It shows that Hive really is trying to get as solid of a foundation as possible built. HF26 people can bring their lets play with the reward pool up then, because after 24 and 25 and the solidification of the foundation, unless something is seriously wrong then I think people will take a close look at any changes to the system.

All systems can be improved, and I am not against that, but systems need to be tested, and the current reward pool system has been tested, and if there are things which would make it run more smoothly, then I hope people look at it that way, and not go throwing the baby out with the bath water.

It sounds like your view is quite similar to mine. While I don't discount the social media rewards aspect of Hive, it is just one aspect, and it shouldn't dominate future development the way it dominated Steem's development. So while we can and will make minor tweaks to the rewards algorithms, our team's energy is primarily being invested into improvements to information sharing, financial products, and decentralized 2nd layer applications.

This is so helpful

That's great, keep the awesome work!

I see you are still doing an amazing job with Hive! I made my contribution and translated this post to spanish so that the community is informed in detail of everything that happens with Hive ;)


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

You distributed more than 82000 upvotes.
Your next target is to reach 83000 upvotes.

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