## Hard Fork 20 starting from September 25th
Hi everyone! Today I would like to pick up the major changes from the **Hard Fork 20** (*Velocity Hard Fork*) which is planned from **September 25th**. Were you aware about the change?
 I will pick about which the current users would be affected to their general use of steemit and explain it for Japanese users.

First of all, the team announced the change summary of the hard fork a month ago.
[announcement](https://steemit.com/steem/@steemitblog/steem-velocity-hardfork-hardfork-20)
And updated their GitHub a few days ago.
[GitHub](https://github.com/steemit/steem/releases/tag/v0.20.0)
You can check the changes at these pages if you are familiar with English.

皆様、Steemが9月25日（日本時間26日０時）にハードフォークを控えていることはご存知でしょうか？**Hard Fork 20** (*Velocity Hard Fork*と呼んでるようです)ということで**20回目**のハードフォークとなります。
ハードフォークに伴ってsteemitの利用についてもいくつか変更点がありますので、既存のユーザーが通常の使用において影響を受けそうな項目をピックアップして説明できればと思います。
*※翻訳ではなく私の解釈も含んで簡単に解説できればと思います*

まず、先月ハードフォークで何が変わるかのアナウンスがされ、また数日前GitHubも更新されました。
[アナウンス](https://steemit.com/steem/@steemitblog/steem-velocity-hardfork-hardfork-20)
[GitHub](https://github.com/steemit/steem/releases/tag/v0.20.0)

それではGitHubからピックアップした変更点を以下で記載していきたいと思います。

### Resource Credits
> Steem Velocity moves beyond the bandwidth system to a an improved system based on Resource Credits (RCs). The RC Plugin defines blockchain resources and limits medium and long term use through stake based Resource Credits. Based on the usage of a particular resource, there will be a market price in RCs. When a transaction is included, the issuing account will be charged a number of RCs according to the resources consumed by the transaction. In this release those resources are history bytes, market bytes (these are analogous to the bandwidth plugin), state size, execution time, and subsidized accounts. The RC Plugin is designed to be extensible and more resources may be added if the need arises. This is the most comprehensive update to the resource management of the Steem Blockchain since the initial release in March of 2016.
There is also a new rc_api that will allow querying of various RC metrics. Those calls are get_resource_params, get_resource_pool, and find_rc_accounts.
The RC Plugin is listed as a dependency of the Witness Plugin. When HF 20 goes into effect, the Witness Plugin will automatically begin listening to the RC Plugin for bandwidth feedback instead of the existing bandwidth algorithm. For the time being, both algorithms will continue to operate but only one will be listened to for the purposes of rejecting transactions.
If, after HF 20 goes into effect, there is a problem with the RC Plugin, witnesses can go back to listening to the bandwidth algorithm by setting the following command line arguments. --witness-skip-enforce-bandwidth=false --rc-skip-reject-not-enough-rc=true. These arguments are exclusive and a steemd node will not start if they are both set to true or both set to false when running the Witness Plugin. In such an event, Steemit and the witnesses will coordinate to make the switchover.

これは今までの「Bandwidth」という概念から「Resource Credits」という概念に置き換わるということになります。「Bandwidth」とはsteemit上の各種操作においてブロックチェーン上に記録ができるデータの上限値のようなものです。ブロックチェーンではすべての行動を記帳しており、それぞれのブロックにおいて記録できる容量が決まっているため、各アカウントが利用することができる容量も同様に上限が決まっていることになります。
ブロックチェーンに記帳することによってトランザクションが発生しますので、操作ごとにブロックチェーン上ではリソースコストが発生しているわけです。このコストをより効率的に抑制するために新しく「Resource Credits」というものに置き換えるようです。「Resource Credits」は各アカウントが保有しているSteem Powerの量に比例して割り当てられます。

### Manabar
> The way voting power is now tracked is via a "manabar". Rather than tracking percentage voting power remaining, it is now tracked as unspent rshares, also called mana. Your max mana is a function of your SP, delegations, and active power down. Mana regenerates proportional to your max mana and is updated whenever there is a change to your max mana or a vote takes place. This lazy updating is important for API consumers to be aware of. However, it is easy to extrapolate current mana. Mana is regenerated from 0 to 100% of max linearly over 5 days. The manabar records when it was last updated. The current mana is last_mana + (now - last_update) * max_mana / 5 days. This is, of course, capped by max mana.

今まで％で表現されていたVoting Powerが「Mana（マナ）」に変わるようです。機能的にはこれまでの％とあまり変わりはないのかなと思います。

### Per Satoshi Steem Power
> This change is largely motivated by a refinement of how we think about Steem Power in terms of voting power. Some voting exploits relied on this lack of a foundation to vote with more stake than an account should have. While it would be easy to assume that any maximally acting actor should use the exploit, we don't want users of Steemit.com, DTube, Busy, and other Steem DAPPS to be at a disadvantage because they don't use these exploits. What we came up with, or rather clarified internally, is a set of base rules defining how we treat Steem Power in this regard. Each satoshi of Steem has power associated with it regardless of whether it is powered up or not. That power is used for all stake based actions such as voting and RCs. The power regenerates linearly from 0 to 100% over five days. All liquid STEEM is treated as having 100% power even though it is not used for stake based calculations. The result of this decision is that when you power up STEEM, you instantly have access to it at 100% power, but the STEEM must be powered back up to 100% before it becomes liquid. To do this, the week before STEEM is powered down from Steem Power to liquid STEEM, it is not used for voting. This gives the STEEM seven days to regenerate its power.
This distinction is important and is a departure from the current rules. Currently, new Steem Power inherits the voting power of the account. 100 STEEM powered up into an account with 0% voting power would effectively have 0% power and the same STEEM powered up into an account with 100% voting power would effectively have 100% power. This discrepancy is fixed and was the crux of several delegation/voting exploits. Now, when the 100 STEEM is powered up, 100 mana is added to each account, regardless of how much mana the accounts had previously.

これはSTEEMをSteem PowerにパワーアップするときにVoting Powerとして反映されるのに時間がかかっていたのが、直ちに反映する変更のようです。Voting Powerが0％の時はパワーアップされたSTEEMのパワーは0％反映され、100％であればパワーは100％反映されるということみたいです。

### Return Delegation Return Time
> When Steem Power delegations are returned, the delegated STEEM needs to power up as well. Even though the return time was 7 days, because we had not defined these interactions well, exploitation was possible. Now, with well defined interactions, we have actually reduced the return time to 5 days and fixed exploits.

Steem Powerのデリゲーション（貸出）していたものを自身のアカウントに戻すのに７日必要だったのが**５日**に短縮されます。

### Vote Dust Threshold
> There is currently a small threshold that must be met in order to vote. This was to prevent "dust" votes that don't impact rewards. However, this leads to a bad user experience for new users that tend to have low value accounts. Instead, the threshold is subtracted from all votes and votes are allowed no matter how few rshares the vote allocates.

Upvoteにおいて、少量の力（影響力）しかないものについては無視（？）されていたようで、それが変更によってこの要件が取り除かれるようです。これは力を持たない新規アカウントを考慮してとのことです。

### Curation "Reverse Auction" Window
> The curation "reverse auction" window has been reduced from 30 to 15 minutes.

投稿直後の30分間の記事へのキュレーション報酬はupvoteされた時間によって段階的に投稿者への報酬取り分が多い仕組みですが、この時間間隔が30分から**15分**に短縮されます。

### Curation "Reverse Auction" Destination
> Currently, the curation rewards lost in the reverse auction are sent to the author. This gave the author an unfair advantage when self-voting because they would not pay the price of the reverse auction and would be able to guarantee themselves as the first curator and get a larger portion of the curation rewards. Now the curation rewards lost in the reverse auction are sent back to reward pool instead to put the author on an even playing field with other curators.

記事を投稿直後自身でセルフvoteすることによってキュレーション報酬を多めに得ることができましたが、今後セルフvoteによって得られるキュレーション報酬は投稿者には還元されずにリワードプールに戻されることになります。

### Comment Limit
> The comment cooldown of 20 seconds is being reduced to 3 seconds (one comment per block).

コメントを投稿した後に別のコメントを投稿するのに20秒の間隔が必要だったのが**3秒**に短縮されます。

### SBD Changes
> The Steem Blockchain has some rules in place to encourage healthy market dynamics for SBD. Those are being tweaked to attempt to keep SBD on the peg more often. SBD will slow printing linearly starting at 9% of the market cap (instead of 2%) and stop entirely at 10% (Instead of 5%).

以前[SBD報酬の怪](https://steemit.com/japanese/@glastar/jpnsbd9argahm5)という投稿で報酬がどのようにSTEEMかSBDかで払い出しされるかを解説しましたが、以下の通り変更されます。
1. STEEM流通量に対してSBD総発行量が9%未満の場合：報酬はすべてSBDで発行される
2. STEEM流通量に対してSBD総発行量が10%超の場合：報酬はすべてSTEEMで発行される
3. 9%～10%の間の場合：割合に応じてSTEEMとSBDのどちらも発行される

いかがでしたでしょうか？
セルフvoteの仕組み変更によって、より効果的な投票botやupvoteの販売サービスやデリゲーションサービスを模索するユーザーが増えたりするのでしょうか？私自身、現在投票botの使い方なんかも模索していますので、いつか記事にできればと思います。
steemitの使い方がどのように変わっていくのか楽しみです！！

今回の記事が皆様のお役に立ちますと幸いです。