During the last week we saw Hive apps developers become very engaged in testing and error reporting. BlockTrades team has been very busy addressing problems that were found and we’ve also took on the role of testing and fixing condenser and condenser’s wallet (open source code used by hive.blog, etc).
Hived progress (blockchain node software)
On Friday, our testing of condenser against our Eclipse node exposed that the data reported by the Eclipse API server (https://beta.openhive.network) wasn’t as current as the data on our production API server (https://api.hive.blog). After some investigation, we found that this was because Eclipse hivemind is fed blockchain data from a hived node configured with the rocksdb-based account history plugin which only reported data from irreversible blocks, whereas our production system gets blockchain data from a hived node configured as a “fat node” which provides operations up to the blockchain’s current head block.
In eclipse-based API servers, fat nodes were eliminated to save resources. In pre-eclipse nodes, an API server was generally configured with two hived nodes: fat node + account history node. But this dual-node requirement consumed a lot of extra RAM and other resources.
To avoid going back to a two-node solution, we added a new flag
include_reversible to the API so that the rocksdb account history plugin can report reversible operations when API calls are made to it. This change is only needed by API server nodes and it is a non-consensus change, so it doesn’t require API server nodes to replay or load a new snapshot (it doesn’t change the blockchain state). The related changes are here:
While making the above change, we discovered that some change to beem was resulting in unexpected CI test failures. The changes below were made to fix the installation of beem on our CI system:
@timcliff also reported a long-standing bug with using websockets with the cli_wallet that we found was caused by a long-ago update (0.22 I think) to the websocketpp library, so we cherrypicked a patch to that:
Status: at this time there are no known issues with hived, although we encourage active testing of the new include_reversible operations feature by witnesses and devs.
Hivemind progress (2nd layer social media microservice)
Use the new
include_reversible flag when calling enum_virtual_ops on hived to get recent blockchain operations from the hived node:
Added pre-appbase api support for some condenser api methods (this functionality will likely be deprecated, but included now to support temporary backward compatibility for Hive apps):
Added missing fields from get_content call:
Unread notifications call (bridge.unread_notifications) was too slow. Originally it was taking 11.8s, now it is down to 3.7s. This is still much slower than we would like, so further improvements are planned.
Miscellaneous performance improvements:
Miscellaneous bug fixes:
Updates to hivemind docs, especially build instructions:
Condenser + web wallet progress (open source code for hive.blog and similar sites)
We’ve been updating condenser for Eclipse and also using it to test for differences between Eclipse and pre-Eclipse nodes. This was how we found the issue with the rocksdb account history node only reporting operations up to the last irreversible block. Below are fixes we’ve made to condenser as we’ve been testing (other social frontends may want to look over these issues to see if they could impact their own frontend):
Devops update (assisting other API node operators)
We’re in the process now of updating beta.openhive.network with the latest changes above. It should be updated in the next hour or so.
We’ve prepared a snapshot of hived with changes required for v1.24.3 (version with json_metadata) and this snapshot is also needed for the current head of master (which has the irreversible_operations support as well as the json_metadata). With this snapshot, hived’s can be updated to the latest version needed for API nodes in about 15 minutes.
We’ll also be creating a hivemind dump tomorrow, to enable other API nodes to update faster.
The witnesses are planning to execute the hardfork on Oct 14th . This means we’re going to be extremely busy tomorrow doing last minute testing, etc. And despite all the apps testing that’s been done in the last week, I expect we’ll be spending the rest of the upcoming week after the hardfork working with apps developers to fix any remaining problems that get uncovered and working on further speedups to slower operations such as bridge.unread_notifications.
After we’ve finished the cleanup work, we’ll be starting to collect a set of features for the next hardfork. I’ve already thrown out some of my preliminary ideas for work to be done (mostly existing ideas that have been tossed around in onchain posts for a while by different people) in the last developer online meetup, but I’m planning a post late in the week to begin formal discussions on the proposed changes for the next hardfork (assuming I’m not buried in cleanup work still).