# “When HF24?”

Software never gets developed as fast as anyone would like, unless it’s rushed out the door too quickly, which only leaves a bad taste in everyone’s mouth when the resulting software is full of bugs. I’ve seen this happen many times over the years, and I’ve even been guilty of it myself once or twice, so I’m very much opposed to releasing software before it’s adequately tested. This doesn’t guarantee there still won’t be bugs, but it usually prevents the obvious ones.

All that’s a preamble to saying that most of the coding work for HF24 itself is done by now, but we’re still working very hard on creating tests, running those tests, and fixing bugs that those tests expose.

First, a tentative prediction: I’m hoping we can successfully update the mainnet to using HF24 rules within about 30 days from now. Here’s what needs to happen in that time to achieve that, along with time estimates for the tasks:

## Remaining work on hived (the 1st layer blockchain code)

Yesterday @howo submitted a merge request for the code that will periodically convert Hive stored in the hive.fund account to HBD at prevailing market feed prices. After discussion with the community, he’s designed the code to convert 0.05% of the Hive in hive.fund once each day. At this rate, assuming no new Hive was added, all the hive there would be converted in 2000 days (100% / 0.05 = 2000) which is approximately 5.48 years. He’s also added code to exclude HBD stored in the hive.fund from debt ratio calculations. Currently, this is the last functional change planned for hived in HF24.

A couple of BlockTrades team members are currently working on developing and running more tests for hived.

I expect all the above work to be completed within the next week. The above work represents the blocking tasks for HF 24 in the blockchain code.

After the blocking tasks are completed, the same BlockTrades team members currently doing testing will also be doing follow-on work to fully measure and document the various speed and memory improvements associated with Eclipse software. Some of that is done already, but not all such measurements have been made on the same machines, we’ve had changes since those measurements, and making some of these measurements can take several days. Since this isn’t a blocking task, and we already are confident from previous measurements that we only have improvements in performance, full measurement of the performance improvement is a lower priority task.

# Remaining work on hivemind (the 2nd layer microservice for social media information)

We have 2 devs working full-time and one additional dev that spends about ½ his time working on hivemind. We also have two more devs who occasionally provide design and technical help and do code reviews from time to time (I’m one of the latter).

Hivemind is pretty much feature complete for HF24 and we’re currently in the testing phase. Despite that, there’s actually more work left to do on hivemind than on hived, because there’s more things to test, and the testing framework was incomplete and considerably out-of-date when we started working on it. I don’t know for sure, but from what I can see and recall, I think there was only one dev (@roadscape) assigned to it when Steemit was developing it, so I think he had his hands full.

Some of the same guys recently assigned to testing hived will also be helping out with testing of hivemind. Due to the sweeping nature of the changes to hivemind, we do expect to find a reasonable number of bugs in hivemind that will need to be fixed (we’ve already found outdated tests that are arguably bugs themselves since they report false positives). Fortunately, the tests we’re developing are pretty good at isolating where the bugs are, so the bugs should be relatively easy to fix.

I am somewhat optimistically estimating that we’ll be able to complete the tests and fix the bugs we find in about a week. This work proceeds in parallel with hived work, so I’m currently estimating 1 week for complete testing of hived and hivemind, but my 30 day estimate allows for this taking up to 2 weeks.

As is the case for hived, we’ll also do some follow-on work to make measurements of final performance improvements after the testing is completed, but this is also not a blocker for HF24.

# Update documentation and scripts to help node operators take advantage of new Hive features

Several features such as saving/restoring state information were introduced into hived that ease the burdens of node operators (including exchanges that want to support Hive). There’s also been several changes in how to optimally configure an API node and run it with fewer resources. 

Since @gtg is one of our primary technical liaisons to exchanges, and he’s familiar with the recent changes, he has begun to review the documentation for hived and make appropriate changes to the associated docs, scripts, and config files.


# Setup of testnet API nodes for library and 2nd layer application testing

We currently have an Eclipse node connected to the mainnet that can be used by 2nd layer applications for integration testing. However, this node currently only supports 1st layer API calls (i.e. blockchain API calls supported by hived). It’s being used for updating Hive API libraries like hive-js, beem, dhive, etc, mainly to support the rebranding changes (e.g. SBD → HBD) that have been made to the API. As of today, I think a good number of the libraries have completed their updates for this.

After we’ve completed testing of hived and hivemind (currently estimated at 1 week), we’ll need to setup one or more Eclipse testnets with a full API node that supports the API of both services. At this point, 2nd layer applications will be able to use this testnet to update their code to support Eclipse. Setting up a testnet node isn’t too difficult, so I don’t think this will take more than a day.

# Updating 2nd layer applications

There’s quite a number of 2nd layer applications, so it’s hard to predict how long each team will take to make their updates. So I’m factoring in two weeks for the majority of the apps to be ready after the testnet is deployed.

We’ll also likely add a hivemind node to the Eclipse node that’s currently connected to the mainnet, so that 2nd layer applications will also be able to test against an Eclipse API server connected to the mainnet.


# That’s only 3 weeks worth of work, why 30 days to HF24?

The idea is simple: we release a well tested version of the core blockchain code in one week from now. Exchanges then ideally have 3 weeks to setup up their Eclipse nodes in preparation for the hardfork (even though we only think they will need 2 weeks). During this same 3 weeks, 2nd layer applications can be completing their updates to work with Eclipse nodes. We essentially have one week of “slack”, in case we discover an error in the Eclipse core code, which will still leave exchanges and 2nd layer apps at least 2 weeks to upgrade. 

Nonetheless, there’s never any guarantees with software, so it’s possible unexpected problems may come up and force us to delay more than 30 days. Our priority remains to ship a solid platform update, even if it means we have to miss our current estimated delivery date.