Five days ago @blocktrades issued an announcement on what they are working on in terms of the next hardfork 25

https://peakd.com/hive-139531/@blocktrades/roadmap-for-hive-related-work-by-blocktrades-in-the-next-6-months

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.

This is always something to be mindful of.

Even though we can write the code changes quickly and put them on the testnet, we can't implement them quickly. Everyone knows how much of a pain it is for exchanges to be down for days while they reconfigure their nodes so that wallets can be reenabled. Every hardfork requires a certain overhead cost in this respect.

If I recall correctly, this is one of the advantages Koinos is trying to bring to the table. That network theoretically will be able to upgrade on the fly without having to deal with all the hardcore consensus issues that most chains face when upgrading.

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.

Tokens still on hold.

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.

In this context, if I'm reading this correctly, "second layer" simply means "centralized shit tokens like HiveEngine" running on a single server. Of course as a LEO whale I have to walk on eggshells with that statement. Still, it will be interesting to see what they can do short of witnesses confirming token operations on layer 1.

Governance changes

• Vote expiration After one year votes will expire if that account has cast no votes within the last 12 months.

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.

I would have been way more aggressive with this one, but it's nice to see @blocktrades employing some restraint. Personally I'd like to see a 10% vote decay per month rather than having to wait an entire year for votes to get canceled. That being said, this is a clear step in the right direction, and if it works out well then perhaps we can revisit the idea later.

Change 5 min vote 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.

Now this is a great change for the network. LEO got rid of this mechanic entirely and it has been a great success. This solution is a nice compromise. I like it.

How long should the new window be? I’d argue for somewhere between 2 hours and 24 hours at most.

Honestly anything within that range would be fine. 24 hours would almost be as if the mechanic didn't exist (like LEO) while 2 hours would give plenty of time for the vast majority of users to vote, while those that lagged behind would have their curation leeched by the frontrunning group. Even 1 hour would be fine.

I think if there's one thing that this all points to: it's that curation was a fun little mechanic that failed miserably and now it is slowly being phased out. It was exploited into the ground by bots and vote buying, and that's fine. Now it dies a slow death. Sorted.

What we need to remember is the reason why curation existed in the first place: to incentivize big accounts to upvote other people and decentralize the network. As we see on LEO, a simple kickback to the curator is all you need.

There's no point to this whole whoever-votes-first-gets-more-money nonsense... in fact the old way seems to be extremely counterproductive. Yet another great change that requires very little effort in the development category.

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.

Interesting theory...

Personally I think it gimps bots so hard that they may hardly be worth it. All those who voted within the 2 hour window will get an equal share of the curation, greatly diluting the exploits of bots that vote at exactly the right time programmatically. It then becomes a guessing game of which whales are going to vote which posts after the 2 hours window. I guess we'll see how it works out. Should be interesting.

And that's it!

The rest of the @blocktrades post is all about non-consensus changes.

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.

So it's basically a bunch of boring stuff that you don't care about but I do because I'm trying to build dapps here.

Conclusion

@blocktrades is still pumping out a lot of work. Sure, I've talked a lot of shit from time to time, but where would we be without @blocktrades? Hive might not even exist and we'd still be begging Sun for our network back, messing around on Blurt, or some other patchwork fork.

Remember that the next time someone claims this network is broken and needs to be fixed with "XYZ". Yeah? Go fix it, cause saying things is a million times easier than actually doing it. You don't see devs around here whining that everything is bust, they just keep their heads down and keep grinding out code. Good thing too, or we actually would be doomed if the people around here actually building things gave up based on what the price-action was at the time.

In any case I'd say things are looking pretty up and we're headed in the right direction as we enter into the next mega bubble year. It's easy to get impatient and lose sight of the long term, but every time a year ticks by definite strides have been made. I assume these developments will continue and even get stronger as the network expands. Persistence is key, and this community is nothing but hunkered down during times of great adversity.

Posted Using LeoFinance ^Beta

Return from Blocktrades Proposed Consensus Changes to edicted's Web3 Blog