The BlockTrades team is planning a lot of future work to the Hive ecosystem. This posts details some of the changes we’re planning so far.

I want to apologize in advance, as this is still a somewhat raw dump of my thoughts about sometimes complicated issues. This means that some of the topics are written for everyone, but other topics contain fairly technical details that will likely be difficult to grasp at first reading (and maybe subsequent ones). As we get closer to implementation of some of these ideas, I’ll try to elaborate more on individual ideas from this post in later posts (if someone else hasn’t taken on that challenge in the meantime).

I’m dividing these changes up into several categories, because they impact different systems and therefore have different scheduling needs.

Blockchain-consensus changes (hardfork changes)

These are changes to Hive’s governance model, so they require a hardfork and approval by the top 20 witnesses.

Hardfork changes require all nodes to update to continue operating on the Hive network, which is a bit of a pain to coordinate, so Hive devs try to avoid requiring too many hardforks (usually by scheduling several hardfork changes at once).

The current plan is to schedule hardfork 25 for around 6 months from now (mainly to avoid requiring exchanges from having too upgrade too soon after the last hardfork). The protocol changes planned for hardfork 25 are expected to be rather easy changes and will likely be coded much sooner than 6 months from now.

The changes planned for the hardfork are NOT required in order to execute on our other planned changes to the Hive ecosystem: this means we can make many important and useful changes to Hive before the next hardfork.

What about HMTs (user-defined tokens)?

The only potential change we might conceivably make to the blockchain rules in hardfork 25 that wouldn’t necessarily be easy would be enabling HMTs (mainly because the HMT code hasn’t been tested well yet and would likely need improvements prior to release).

At this point, we haven’t made any decision about whether or not to enable HMTs, because we think there’s a reasonable chance that we can do something more useful in the way of tokenization at the 2nd layer. In short, the topic needs more research, and will be discussed in depth in a later post, after we’ve fully explored the options.

My personal preference at the moment is to implement user-defined tokens at the 2nd layer using a smart contract evaluation system, which will allow for much more flexibility than is possible with HMTs. But to make this feasible, we have to define a robust model for decentralized 2nd layer apps (to be discussed more in later sections of this post).

It’s also worth noting that these don’t have to be exclusive options: it’s possible to implement HMTs at the first layer and smart contract-based tokens at the 2nd layer. But this could be more confusing for Hive users and may offer no real benefit.

Governance changes planned for hardfork 25

Vote expiration for witnesses, proxies, and proposals

Currently governance votes don’t expire, which can lead to votes that never change, either due to inattention of the voter or in worse cases, because the owner loses their keys or passes away (yes, on Hive, dead people really can still be voting). This can lead to non-optimal voting, since the stake isn’t properly monitoring the people and proposals being voted for.

To address this issue, we’ll set governance votes to automatically expire one year after the last governance action by an account. This will be implemented by storing a “last governance action time” for each Hive account (this information will be part of an account’s profile information).

Whenever a user sets a voting proxy, or vote/unvotes a witness or a proposal, this last governance action time will be updated to the current time. If a year passes without a governance action by the account, the account’s votes for witnesses and proposals will be canceled, and any proxying of the account will be reset.

User interfaces like Hive wallets and browsers will be updated to report a warning when an account’s votes are getting near to expiration. Such warnings should prevent any active user from forgetting to take a governance action that keeps their votes from expiring.

Just to be clear about how this works in practice: your votes will only expire if you don’t take any governance action for an entire year. So this change should only impact people who are no longer “paying attention” to what’s going on (or who have lost control of their keys).

Change 5min vote window to longer window and provide proportional rewards during the window

Currently, voting earlier than 5 minutes after a post is published results in less curation rewards for the voter. This led to the rise of auto-vote bots that vote at or near the end of this 5 minute window, severely disadvantaging manual voters.

With this change, there will no longer be a penalty for early voting of a post/comment. Furthermore, there will be no advantage to voting earlier than anyone else who votes within the new longer time period.

There will still be an advantage for voters who vote within the time window, but the idea is that the new window time should be long enough for manual curators to find good content, putting them on equal footing with the vote bots.

How long should the new window be? I’d argue for somewhere between 2 hours and 24 hours at most. I generally favor it being closer to 2 hours, to allow for some friendly competition between manual voters, and to encourage somewhat rapid curation that brings good content to the trending page quicker.

This change isn’t expected to eliminate auto-vote bots, but it should remove the financial incentive to use an auto-vote bot instead of voting manually.

This change will still lead to an incentive to select “popular” content, since voters during the first 2 hours will gain somewhat more rewards than later voters on a post.

The above means that “Smart” auto-vote bots will likely begin trailing successful manual curators by voting near the end of the 2 hour period in an attempt to maximize their rewards. On the whole, this incentive seems beneficial, since it should lead to good manual curation being the guiding force for how the bots vote as well.

Non-consensus changes to hived blockchain software

These are changes that can be made without a hardfork, and often don’t require everyone to upgrade their node. Changes of this type include: 1) speed and memory optimizations, 2) minor bug fixes, 3) addition and changes to API functionality. They are also usually not very controversial, because they don’t affect governance.

Because non-consensus changes usually don’t require everyone to upgrade their node, these changes can be released whenever they are ready, instead of being scheduled as part of a big planned release. As a simple example, we’ve had 7 such non-consensus releases since HF 24 (we’re at hived v1.24.7 right now).

Most of these changes only impacted API node operators, so normal witnesses and exchanges didn’t need to upgrade their nodes (most hived nodes are still running v1.24.2).

There’s several areas we can explore making non-consensus improvements to the blockchain:

1. further reductions to memory usage
2. improvements to peer-to-peer networking layer
3. improvements to API services
4. a hived plugin to provide real-time data to 2nd layer apps

Of the above areas, I believe 4) is the most critical change. Currently it takes over 4 days to sync all the existing blockchain data to a new hivemind instance. We should be able to significantly reduce this time by creating a custom plugin that can fill a hivemind database (we’ve made measurements that show that hivemind database filling time is the main bottleneck in hivemind full sync timing on a system with fast IO, because of cpu bottlenecking on the hived side).

Another issue is that the current hivemind “live sync” process intentionally lags 2 blocks behind the head block, because hivemind isn’t able to handle micro-forking by hived. The creation of a plugin that directly writes to hivemind’s database will allow for faster data filling and also allow hived to manage the required changes to hivemind’s database in the case of microforks. This, in turn, means that hivemind will be able to operate with the most recent block data, eliminating the 6 second lag (2 blocks behind the head block at 3s block intervals = 6s) that it currently has. This is very important for an interactive experience by Hive users on the various Hive frontends.

Development of 2nd layer ecosystem

This is one of the areas where I expect we’ll be devoting the most time in the next few months. The most important thing I want to do is to create an easy framework for the creation of new Hive apps.

Right now, apps usually rely on API nodes to supply a lot of their blockchain information via API calls (with the data coming from a hived blockchain node and the hivemind social media microservice). Some apps also directly process custom_json operations to implement functionality that is generally unique to their application. This approach “works”, but it could definitely be improved.

Implementation challenges for 2nd layer apps

One issue is that apps either need to run their own heavy weight API node or rely on the API nodes provided by others. Ideally, it should be possible for an app to run a lightweight node that provides all the data needed by the app, avoiding reliance on uptime and data integrity of external API nodes.

Another issue is the processing of custom_json streams (and other operations) in the face of forks, where operations in blocks that have already been processed have to be discarded in favor of new data. This is one of the most potentially problematic issues for any blockchain-based app.

A lightweight framework for 2nd layer apps (via “modular hivemind” nodes)

To address, the above issues, we plan to create a lightweight framework using much of the technology stack of hivemind, combined with the new hived plugin we’re developing that will simplify real-time reception and processing of blockchain data and support easy fork-handling via a generic undo mechanism.

However, unlike in a traditional hivemind installation, the operator of a 2nd layer node of this type will get to decide what data he wants to store and what APIs he wants to support. For example, a 2nd layer node that supports a game might initially only track account balances and game history, but no social media data. But if the node operator later wants to add more data and API support to their 2nd layer node, we want to make it easy to add it via some form of upgrade mechanism. I believe it was @howo that coined the term “modular hivemind” to refer to this idea.

Consistency checking to decentralize trust in blockchain ecosystems

Note: this is one of those topics that I mentioned at the outset of this post that might not be trivial to understand unless you’re a programmer (and maybe not even then).

Another important capability that would be very useful for 2nd layer apps is a way of automating the checking of data consistency between multiple API servers. A system of this sort would go a long way towards reducing the need to trust any particular node that supports a 2nd layer app (i.e. decentralizing trust).

One way to do this would be for decentralized 2nd layer apps to periodically (for example, once every 1000 blocks) generate a hash of their state (or some portion thereof) and publish it as a blockchain transaction. 2nd layer apps that generate the same hash are making a statement that they interpret the blockchain data in the same way (i.e. they are operating under the same protocol rules).

In such a system, 2nd layer apps can decide to operate by different rules (a protocol fork), while continuing to coexist on the same blockchain network. But by publishing hashes of their state, users will know which nodes have decided to operate under a common set of rules, and they can therefore make an informed choice about which nodes they want to rely on for data. Of course, a user can always decide to simply run their own node, which is something we want to make it much cheaper and easier to do. But even in this case, it’s very valuable information to know who is supporting a particular protocol, as the amount of consensus among protocol users is a major determinant of the value of that protocol.

Increase development pace of open-source user interfaces for Hive (e.g hive.blog , ecency.com, etc)

For the past few months, I’ve focused on adding more user interface programmers to our team to support increased development of open-sourced Hive-based front ends. Naturally BlockTrades already employed a number of front-end programmers, but they were all tied up on other projects, and couldn’t be moved without serious impacts on the scheduling of those projects.

There’s little point in going into specifics at this moment as to the exact changes we’ll be making on Hive front ends, as often these changes are quite small, can be done at any time, and are generally driven by user demand. But I felt it’s important to say we recognize the importance of how user interfaces impact enjoyment of Hive in all it’s facets (as a currency, as a platform of blockchain based apps, and as a social media backbone) and that we will be increasing our efforts in this area.

A new decentralized reputation/rating system using web-of-trust concepts

This last topic is the one that I’m most interested in, and I’ll have much more to say about it later, but it’s a huge topic and deserves many posts of its own to divide it up into digestible bites.

The basic idea for this system is you assign judgment skill ratings to people you know in various disciplines and you also publish your own ratings on products/people/ideas. Based on who you trust and how much you trust them in different areas of judgment, this system will compute rating scores using your web of trust network on potentially any subject where people form opinions.

I almost didn’t mention it in this post, but since this is something like a roadmap of planned Hive-related work for BlockTrades and this will function as a 2nd layer Hive app, I figured I should at least give it a brief mention now, as I plan to start this effort in the next 6 months. I say “start” because the reputation/rating system is planned to be a long-term project that will grow over many years and expand to address many different areas. Initially, of course, we’ll need to focus on creating a prototype that covers a relative small subset of things that can be rated and a few mechanisms for computing ratings and analyzing how ratings change as a user makes changes to his trust network.

Final note

Also note that this is just a roadmap of things BlockTrades is currently planning to work on. For example, @howo is working on support for recurrent payments currently, to allow for Patreon-style payment models.