Below is a list of Hive-related programming issues worked on by BlockTrades team during the last week or so:
Hived work (blockchain node software)
Official release of Equilibrium (hived code for hardfork 25)
Last week we merged all develop branch changes since the last hardfork into the master branch and tagged an official release of hived (v1.25.0). The “code name” for this release is “Equilibrium”.
For the official press release associated with the new release and details about associated functional changes, see https://hive.blog/hive/@hiveio/hive-hardfork-25-is-on-the-way-hive-to-reach-equilibrium-on-june-30th-2021
The release notes for Equilibrium represent a concise summary of virtually all changes that were made as part of this hardfork, along with links to review the code associated with each individual change.
Alternatively, you can inspect a diff with the totality of changes for this hardfork.
Other hived work last week
We continued performance testing of the new “recurrent transfers” feature written by @howo. As a side note, based on some discussion among various devs, I believe Hive frontends will use the term “recurring payments” to refer to the “recurrent transfers” feature, since that is the name most commonly used in the business world for this type of functionality.
During our still incomplete testing, we found some areas where the new “test tools” framework that is being used to create and test massive numbers of recurrent transfers could be improved to make it faster and more stable:
https://gitlab.syncad.com/hive/hive/-/merge_requests/257
https://gitlab.syncad.com/hive/hive/-/merge_requests/263
Here’s a short list of other work done on hived:
- Fixed two unit tests that we previously had to disable and re-enabled them: https://gitlab.syncad.com/hive/hive/-/merge_requests/259
- Added a new command-line option –exit-before-sync for configuring hived to a predictable state for running a replay or creating a statefile dump, then ending the hived process. This is useful for setting up test scenarios. https://gitlab.syncad.com/hive/hive/-/merge_requests/232
- Added new regression tests to test recent changes to last irreversible block handling (a change that was made to fix a longstanding bug with duplicate transactions in the account history plugin): https://gitlab.syncad.com/hive/hive/-/merge_requests/252
- Fixed an intermittent crash on application shutdown: https://gitlab.syncad.com/hive/hive/-/merge_requests/253
- Documentation cleanup: https://gitlab.syncad.com/hive/hive/-/merge_requests/258
- Implemented option for automatic spawning of hived replays within our continuous integration system (done off main servers to avoid breaking or interrupting primary development CI system).
Hivemind (2nd layer applications + social media middleware)
- Added tests for recent changes in behavior of setLastRead operation: https://gitlab.syncad.com/hive/hivemind/-/merge_requests/511
- Explicit specification of package versions to be used when building hivemind to avoid potential headaches when package dependencies are updated: https://gitlab.syncad.com/hive/hivemind/-/merge_requests/498
- Update CodeQL analysis configuration: https://gitlab.syncad.com/hive/hivemind/-/merge_requests/509
- We’re currently investigating ways to improve performance of the
update_rsharesfunction immediately after massive sync of a hivemind instance. - Fixed "broken reputation" problem related to ordering issue because of multiple transactions used per block. This was known to impact the calculation of reputation for at least two Hive users.
- list_subscribers bug being worked on (tests being created first).
Hive Application Framework
The current implementation of the Hive Application Framework requires applications to mark their constraints as DEFERRABLE to enable HAF apps to use the auto-rewind feature when a fork switch occurs.
While this may be an acceptable limitation on the design of HAF-based apps, we decided to create an alternative implementation of HAF without that limitation and measure the performance of the two alternative designs. The ongoing discussion of this topic can be found in the latest comments attached to the still open HAF merge request: https://gitlab.syncad.com/hive/psql_tools/-/merge_requests/1
Upcoming work in the next week
- Continue performance testing of recurring payments functionality in hived.
- Complete psql_serializer updates and begin testing hived+psql_serializer with hivemind. This is a prerequisite for testing the entire HAF code base.
- More work and testing of the Hive Application Framework (HAF), including more documentation and example HAF-based applications.
- Finish up fix for list_subscribers.
- Work with witnesses to collect performance statistics for the Equilibrium release on different hardware configurations.
On a related note, @drakos noted a significant performance improvement in the speed of creating statefile snapshots and @gtg has confirmed the same findings on his system. Gandalf reports v1.24.8 took 4866 seconds whereas v1.25.0 was able to complete this task in only 3134 seconds.
I can confirm that creating snapshots in HF25 is very fast.
For a plain witness node it took about 3-5 seconds to make a HF25 snapshot.
It was so fast I couldn't believe it.
Also my replay after installing HF25 took less than 9 hours!
This is on a pretty fast machine with lots of RAM.
Details here: https://peakd.com/hf25/@apshamilton/witness-node-upgrade-to-hf25-hiab-hf25-snapshot-available-for-download
Well done!
Thanks for the performance info, I had no idea a plain witness node could create a snapshot so fast.
It takes 10-11 seconds here.
HAF🥳
Congratulations @blocktrades! You have completed the following achievement on the Hive blockchain and have been rewarded with new badge(s) :
Your next payout target is 1195000 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
STOPSorry, maybe this question has nothing to do with this post. my friend asked me, how to remove the reward distribution permanently. Previously he did not mind the distribution of the percentage of the reward he got. because he created an account through dbuzz referrals. and lately he's been complaining to me. why are the rewards divided? I've tried to change it several times. but still appears again like the picture above. My question is, is there a solution to get rid of the recipient of the gift?
I'm not really sure about this. First question, is he using hive.blog or some other frontend interface to create his posts?
the picture I show it is a screenshot from hive.blog.
Are you sure it is? It could be another instance of condenser.
This screenshot also happened to another friend of mine.
I asked around, and it looks like your friend can opt out of the beneficiary payment by going to the settings page on hive.blog. It looks like this:
Can you share the account name? So we can check if there are some specific beneficiaries set?
If i only have hive power, do i need to prepare for anything for hive hardfork?
No, users do not need to prepare anything.
So i will continue with hive journey, it is a very good blockchain, thx
First time I see one of these posts and even though I don't understand any of the witnesses I still find everything you share fascinating, thank you for working for the community.
Great Job!! And sorry for the wrong section on gitlab :)
No worries, it is easy to get mixed up which subsystem manages a given API method on an API server. Thanks for the report anyways.
Good job as always.
Excellent read! Thanks for share!
OMG, Green Arrow? It's you?
Calm down, you have not failed this community!
Jajaja greetings
Same
Shit just got real son!
awesome