Eclipse Hardfork progress (HF date set to Sep 22nd)

Hived work

The witnesses have continued to create testnets to test hived. No major issues were discovered so far. There’s still one big test to be completed, which is to operate a testnet where transactions are injected from the mainnet using tinman.

Some minor issues were discovered and/or fixed:

@howo fixed the uint32 overflow problem that caused a minor progress reporting problem during sync: https://gitlab.syncad.com/hive/hive/-/merge_requests/108

Also,

@gtg identified a post-HF problem: nodes with a different chainid will reject connections from a node reporting a different chainid, and this would cause problems for unsynced Eclipse nodes connecting up to the network after the HF, where the chainid has changed on synced eclipse nodes. There’s two fairly simple solutions to this issue:

the simplest, would be to create a new version of Eclipse for syncing up post-HF that contains the new chainid.

alternatively, we can add a command-line option and/or environment variable that allows the node’s chainid to be specified at startup. In this case, eclipse nodes connected before the HF time would use the old default chain id, and swap to the chainid at HF time, and eclipse nodes connected after the HF time would be launched with new chain id.

It’s still under discussion, but I think we’ll probably employ both solutions. We’ll add a command-line option for specifying the chainid, since this can also be useful for specifying multiple testnets with different chainids in such a way that a node doesn’t need to worry about accidentally connecting to the wrong testnet. And we’ll also produce a new version (e.g. 1.24.1) after the HF, that defaults to the new chainid, so that node operators won’t need to continue specifying the new chainid on the command line in order to connect up to the mainnet.

Hivemind work

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

We implemented reputation calculation in hivemind last week, but we consider the current implementation to be too slow during the initial hivemind sync process, so we’re still looking into ways to speed up the calculation.

Another big task currently underway is a new notification algorithm (i.e. notifications about when an account receives a vote, rehive, or mention). The old notification algorithm was broken during the switch to the Eclipse version of hivemind and during investigation we found that the old version seemed to use excessive storage space, so we’re trying a new algorithm that generates notification information on demand instead of constantly updating it for all accounts.

We completed a second “full sync” of hivemind today (these tests take 4 days to complete) and found another problem in the post-sync fixup of the database, which we’re fixing now.

Hardfork release date and plans for upcoming week

While hived seems quite stable, we’re still working on hivemind, so we’re not yet able to provide a full API node that apps developers can use to test against. I think that we need to give apps developers at least a full week to test against an Eclipse API node, so we’re setting the hardfork date to 22nd, as we don’t think we’ll have a full API node (i.e. hived + hivemind) ready until at least next week.

We’ll likely be tagging an official 1.24.0 release of hived either tomorrow or the day after with the updated hardfork date, assuming the code for setting the chainid at startup works as expected. Witnesses and exchanges will be able to deploy this upcoming version on the mainnet, although full API nodes will still need to use the current release version of hived until the Eclipse version of hivemind is ready.

Although we are setting the hardfork date to the 22nd in hived 1.24.0, it’s still possible that the date may need to change again, if hivemind work isn’t completed next week. In such case, we would tag a new version of hived with the updated hardfork date. But this should not pose any major inconvenience to witnesses or exchanges who’ve already updated to hived 1.24.0 if it happens, since no blockchain replay would be required.