I haven’t had much time to post lately, but I did want to give a quick rundown on some of what BlockTrades has been working on with respect to Hive, on the coding and hardware side, that hasn’t been discussed much in previous posts.

Setup of multiple API servers

API servers provide the blockchain data in various forms used by all the frontend web sites. A number of community members are now operating API servers, with some variance in the capabilities of the servers.

BlockTrades is currently working to build a “cluster” of such servers for higher availability. We have one server functional now (it has been running since the Hive hardfork), but we’re still working on the cluster solution. We’ve been struggling with various hardware issues, but I think we’re nearing a solution on those problems, so I expect our cluster capability will be operational soon.

Optimizing image serving to frontends

Most people include images in their posts, but not everyone is aware that those images aren’t stored in the blockchain data (only the text from the post is). Instead, the images themselves are maintained on “image servers” and the blockchain posts contain links to the images on those image servers.

The main image server for Steem was provided by Steemit Inc, so we’ve had to move to our own image server to support Hive. We were able to setup the new image server prior to the hardfork, but we’re still working to optimize it to provide better service. This is important, because it can result in faster post loading times from the frontend websites where you post and curate from.

One area where we’re optimizing is the use of an “image-caching server” that allows for fast lookup of recently displayed images. We deployed this caching server at the time of the hardfork, but we’re improving its performance as we learn its quirks. One problem we found today is that when we had the caching server configured with a disk cache larger than its memory cache, its performance began to degrade over time, so we’ve corrected that.

We’re also experimenting with tweaking what it recognizes as a “cache hit” (i.e. when it can figure out that an image is one we have locally in the caching server, so we don’t need to re-fetch it from the image server). This will reduce the amount of load on both the caching server and the image server.

Optimizing performance of https://hive.blog

During the first week, we and several other devs were focused on making basic adjustments to the software for hive.blog (including getting the wallet working with the site). Now that that work is done, we’re moving on to working on making the site faster and more robust.

Currently we’re adding the capability to use multiple API endpoints. API endpoints are how the frontends get blockchain data to display. Hive.blog was designed to always use a single endpoint, so if this endpoint had problems, so did Hive.blog. Once multiple endpoints are supported, the web site can swap to a different endpoint if the one it is currently using experiences problems.

Blockchain work for the next Hive hardfork

Our blockchain team is currently working on several tasks for the next hardfork: 1) adding code to do a second round of airdrops on some of the accounts that were excluded from the previous airdrop, 2) final testing and fixes for the delayed voting power code that is meant to stop future voting attacks by exchanges or someone who hacks an exchange, and 3) performing a security audit as requested by some of the exchanges that are interested in listing Hive.

Second round airdrop code

This code will transfer Hive, HP, and HBD from the treasury account to some account groups that were excluded in the initial airdrop. The exact excluded groups that will be eligible will be decided by stakeholder voting, followed by agreement of the witnesses to run the new hardfork code. Note that stakeholders can always change their votes to change the makeup of the top 20 witnesses if they disagree with witness decisions about the hardfork.

Delayed voting power change

The delayed voting power code works by discounting the voting power of newly powered-up stake for 30 days when it comes to witness voting and proposal voting.

Note that this delay will not affect other uses of newly powered up stake. For example, newly powered up stake will still immediately increase your voting power on posts and will increase your available resource credits.

Security audit

This audit will involve a general review of the blockchain code, with a focus on verifying the cryptography code that ensures funds can only by used by someone with the correct private keys, and verifying that the code doesn’t allow for coins to be transferred in unexpected ways.

Hardfork timing

The timing for the next hardfork hasn’t been determined yet. It will depend on both when the code is ready and also when witnesses and stakeholders think it’s most appropriate. Note that we’ll want to give exchanges that list Hive at least 30 days notice before the hardfork, so that they can prepare to transition their wallets to the new code.