Today’s @steemitblog post is brought to you by Steemit’s Blockchain team. We have been making significant progress on our development projects, and wanted to share with you the details of what we have been working on. This post includes updates on Hardfork 20, as well as our 19.4 release which includes AppBase, the StatsD plugin, and RocksDB.

Hardfork 20 Updates

Our primary focus since our May update has been the completion of Hardfork 20. The recent changes we have been working on related to HF20 are listed below.

Resource Credits (RCs)

A major component of Hardfork 20 development is a complete overhaul of the bandwidth system, which is being replaced with a more advanced implementation of Resource Credits (RCs), as described in this post. Much of the work for this new system has now been developed, and we continue to make progress toward its completion. As we discussed in the post, the purpose of this update is to:

… create a system that 1) more efficiently allocates blockchain resources; 2) more accurately measures the true cost of running the blockchain; and 3) enables Steem developers to create more predictable user experiences.

Curation Updates

With the current blockchain rules, if authors vote for themselves right away, they get their author rewards, plus 100% of the curation rewards from their vote, plus a portion of the curation rewards coming from everyone who votes for the post after them. Any other curator voting at the same time as the author would get 0% of the curation rewards. This gives the author an unfair advantage over other curators, because the author can earn additional curation rewards through self-voting.

In order to eliminate this advantage, the unused portion of the curation rewards will be returned to the rewards pool instead of being awarded to the author, thereby increasing the overall percentage of rewards that will be paid to curators. This will better serve the original mission of the curation rewards budget: to ensure that the Steem blockchain distributes rewards to the most valuable content.

Expiration of Internal Market Orders

With the current implementation of the internal market, market orders are never forced to expire. This allows users to submit orders to the internal market which requires long-lived consensus bandwidth, degrading the overall performance of the blockchain. As part of Hardfork 20, we are including a change to require all market orders to expire after 28 days. This is consistent with the implementation of market orders on many of the major exchanges.

Update to Account Creation Fee

Since Hardfork 20 will no longer support the creation of accounts using a portion of delegated stake, there is no longer a need to take a multiple of the witnesses’ account creation fee in order to arrive at the “actual” fee for creating accounts. With Hardfork 20, we will start using the witnesses’ account creation fee value as the actual account creation fee.

In order to preserve the current account creation fee (which is currently the witnesses’ value multiplied by 30) at the time of the hardfork, there will be a one-time 30x modification of all the witnesses’ values.

Removal of 20 Second Comment Limit

We have completed the change to remove the 20-second limit on comments as part of Hardfork 20. It will now allow a new comment every block (once every three seconds), which is the same restriction that is placed on voting.

Implementation of Inventory Based Market for Account Creation

It is a highly technical change, but we have laid the foundation to implement a discounted account creation market based on a user’s held stake. More details about this change are in our original hardfork proposal post.

Discounted Account Creation Methods

In issue 1771 we implemented the operations to allow discounted account creation. The information that follows is somewhat technical (so feel free to skip over it), but we want to give the explanation here for those who are interested.

Creating an account normally requires matching the account creation fee. A discounted account will always have a fee of 0 STEEM. If an account is created in this manner, a discounted account creation token will be consumed, and the account creation will fail if no tokens remain in the creating account.

Any account creation that consumes the account creation fee or greater will not consume a discount token. Any account creation that has a fee less than the account creation fee will consume a token, and fail if a token does not exist. In this manner, accounts can be created cheaply, but not infinitely, and account creation is never prevented via the full fee.

The first operation will claim an account from the discount pool to the creator. This account can be created later at any time with the second operation. If the fee is greater than or equal to the account creation fee, then an account is claimed without taking from the discount pool. The second operation consumes a claimed account from the creator to create the account object, which is able to transact.

Combining these two operations works identically to the account_create_operation currently in use. However, because of the added extensions field, any potential changes to account creation will likely require this operation flow.

Removal of the Minimum SP Power Down Restriction

There is currently a rule that does not allow an account to power down until it has 10x the current account creation fee worth of SP. This was designed to prevent a new account from being created and immediately powered down.

HF 20 burns the account creation fee now instead of powering it up to the new account. Because of that, there is no danger in an account powering down as soon as it gets SP. For this reason, the 10x requirement has been removed.

Fix for Double Voting Exploits

Users reported two exploits: (issue 2428 and issue 2539), where an account could gain extra voting power by using up all of their voting power, and then delegating their SP to another account, or powering down and powering up again into another account.

We are including fixes for these exploits as part of Hardfork 20.
(These are also highly technical, so feel free to skip over if you’re not interested.)

• The Steem blockchain will track remaining voting power as something called Voting Mana. Voting Mana will still generate to 100% * SP over five days. There is no impact on how votes are cast, only on how their weight is stored.
• When STEEM is powered up into an account, 100% * STEEM Voting Mana will be added to the account. Currently, voting power remains unchanged and Voting Power% * STEEM is added to your account. The new system provides an increase in voting power compared to what happens today, and is 100% fair.
• When STEEM powers down, the week before the power down it will not generate Mana for the account. The seven days needed for a chunk of STEEM to Power Down is greater than the five-day regeneration, which allows the STEEM to reach 100% power before it becomes liquid. This is why you can access the Mana as soon as you power up your STEEM.
• When delegating SP, you have to have the excess Mana needed in order to transfer the SP; otherwise, the delegation will not be allowed. For example, if you have 1000 SP and 50% mana (500 Voting Mana), you will only be able to delegate 500 SP until your mana increases.
• This will also let us reduce the delegation return period to five days (the mana regeneration period), to let the returning delegation power back up before returning the owner.

This will not negatively impact the user experience: it is a technical change designed to specifically address the double voting exploit.

Fix for End of Payout Period Downvote Abuse

In Hardfork 17, a change was implemented to prevent upvote abuse by creating a twelve-hour “lock out” period at the end of a post’s payout period. During this time, users are no longer allowed to upvote the post, but they can downvote.

This change opened an avenue for abuse, where a user could downvote a post during this period with no opportunity for stakeholders to negate the downvote by adding additional upvotes.

Hardfork 20 will change this “lock out” period to a “cool down.” During the last 12 hours of a post or comment payout period, upvotes and downvotes will still be allowed, but their strength (for the same amount of voting power) will decrease linearly from 100% to 0% over that 12-hour period. In other words, it will take twice as much voting power to have the same impact on a post’s payout if the vote is done with only six hours left on the payout window instead of twelve. A downvote cast in the last minute would have virtually no impact.

This change has not been implemented yet, but we have decided to include it in the hardfork, and are tracking the progress here.

Release 19.4 – AppBase, StatsD, and RocksDB

The 19.4 release, which includes AppBase, the StatsD tool for measuring statistics data in steemd, and the RocksDB plugin for account history, is nearing completion. At this point we have completed all of our planned development, and are just in the final stages of testing. Assuming no new issues are found, we plan to tag the latest master as release 19.4 very soon.

Miscellaneous Changes

In addition to the changes listed above, we have also been working with the Applications Team to make some necessary structural changes to better support Hivemind and communities. There have also been several minor bug fixes, and changes that are highly technical in nature.

The full details of all the changes we described here, as well as several that were not mentioned, can be found in our steem GitHub repository.

We will continue to keep you up to date on our progress and will let you know as soon as the 19.4 Release and Hardfork 20 are ready.

Steem on,

The Steemit Blockchain Team