Hardfork 24 progress last week

Hived work

Last week we made one final update to hived, this time to allow eclipse nodes that haven’t yet processed hardfork 24 to connect to nodes that have processed the hardfork. This change was necessary because the chainid (the special code that identifies network nodes for the hive blockchain) will change when hardfork 24 takes place. The chainid change posed a potential problem after hardfork 24 took place, because someone starting an eclipse node for the first time that didn’t have blockchain data would only connect to nodes with the old chainid, so they wouldn’t be able to get blocks created after the hardfork. To fix this problem, we now allow eclipse nodes to communicate regardless of whether they’ve processed the hardfork or not yet.
https://gitlab.syncad.com/hive/hive/-/merge_requests/110
https://gitlab.syncad.com/hive/hive/-/merge_requests/111

At a later date, sometime after the hardfork, we’ll release a version of hived that always broadcasts the new chainid (although it will still validate blocks before hardfork 24 using the old chainid).

We’ve tagged v1.24.0 which has the hardfork date set to be triggerable after Sept 22nd (whenever a super-majority of the top 20 witnesses upgrade to the new version). We’re also notifying exchanges to begin updating to v1.24.0, so that they can continue to operate without any interruption whenever the hardfork is triggered.
https://gitlab.syncad.com/hive/hive/-/tags/v1.24.0

Hivemind work

Most of our work last week continued to focus on hivemind.

We continued work on the reputation algorithm. The second attempt at a SQL-based implementation was also too slow, and we’re about to try a 3rd one. If that one is too slow, we’ll implement an in-memory solution using python that periodically commits the computed reputations to the database.
https://gitlab.syncad.com/hive/hivemind/-/merge_requests/121

We’ve mainly completed the new notification algorithm that generates notification information on demand instead of constantly updating it for all accounts. The last thing that needs to be implemented is notifications from communities, which do need to be created as objects rather than on-demand. We’re hoping to complete the implementation tomorrow.
https://gitlab.syncad.com/hive/hivemind/-/merge_requests/123

During our “full sync” tests of hivemind, we found a couple of problems, including one problem where indexes that were dropped for fast processing during “bulk syncs” (a fast processing mode used to process many blocks at once when hivemind is far behind hived’s head block) weren’t always probably restored during normal “live sync” (when hivemind is in sync with hived and receive blocks one at a time). We made a fix today and we’re waiting for results from that test now (this particular test is time intensive). Related commits:
https://gitlab.syncad.com/hive/hivemind/-/merge_requests/125
https://gitlab.syncad.com/hive/hivemind/-/merge_requests/128
https://gitlab.syncad.com/hive/hivemind/-/merge_requests/144

Hardfork release date and plans for upcoming week

We’re still working on hivemind, but we have setup one preliminary API node for eclipse that has hivemind support (minus reputation and notification support, which still needs testing). See @gtg/how-to-survive-eclipse-cheat-sheet for more details.

There’s still a chance that we can have the hardfork on the 22nd, but it will depend on us being able to setup a full hivemind node for apps testing this week (i.e. we’ll know in the next few days if we can meet that deadline). If we don’t, we will tag a new version of hived with an updated hardfork date. This should not pose any major inconvenience to witnesses or exchanges who’ve already updated to hived v1.24.0 if it happens, since no blockchain replay would be required (exchanges wouldn’t even be required to update to the later version, as there would be no consensus changes).