The blockchain for Smart Media Tokens (SMTs) and decentralized applications.
Steem 0.20.12 does require reindexing from all previous versions.
Steem 0.20.12 is an identical release to 0.21.0, containing the latest security and stability fixes for Steem, but will not vote for 0.21.0 if ran by a witness.
This version does not build MIRA by default in our pre-built docker image.
This is an optional update for the Steem database backend, called MIRA.
MIRA is a Multi Index Rocksdb Adapter that updates the database backend of Steem from memory mapped files to a disk log-structured merge-tree implemented via the RocksDB library.
0.20.11 requires reindexing if you want to use MIRA for the database backend of Steem.
MIRA is enabled via the cmake build options, ENABLE_MIRA=ON. This build option replaces the experimental build option ENABLE_STD_ALLOCATOR_SUPPORT. Due to the nature of C++ dynamically allocated data structures and the previous memory mapped database, MIRA is not compatible with the old database at runtime and must be enabled/disabled at compile time.
A reindex will be required to rebuild state in MIRA. The same command line argument, --replay-blockchain is used. Additionally, reindexing can be done entirely in memory with MIRA to improve reindex performance using the command line argument --memory-replay. This will keep all indices in memory until the end of the reindex. This can require a significant amount of memory. In the config file, memory-replay-indices can set which individual indices should be kept in memory to keep memory usage down while still benefitting from the increased performance.
RocksDB has many performance tuning options available. We have exposed a subset of those options in a new config file, database.cfg which lives in the data directory. We have provided a tuning guide to get node operators started on configuring their nodes for their hardware.
RocksDB does open a considerable number of files. You may need to configure your OS to allow for so many files to be open at once. These resources can help walk you through that process. ( OS X, Linux )
In our testing, memory requirements have decreased from 64G for consensus nodes to 16G when tuned correctly. Additionally, we were able to migrate from attached NVMe drives to network attached SSDs with similar, if not better, performance on a live node. Reindex performance with MIRA has much less variability. What this means is that it is much slower when compared to reindexing with an attached NVMe, but considerably faster than a network attached SSD. Your actual performance gain/loss may vary and are largely dependent on the hardware you were running on.
0.20.10 does not require reindexing from 0.20.9
This release is recommended for all nodes.
This release fixes a vulnerability in how the pending transaction queue is treated during block application. In the worst case, the previous behavior could result in block propagation delays and general instability/denial of service of the Steem network.
0.20.9 does not require reindexing from 0.20.8
This release fixes a security vulnerability in JSON parsing. This update is optional, but recommended for all nodes running public API endpoints or plugins that rely on custom JSON operations (i.e. follow plugin).
0.20.8 does not require reindexing from 0.20.7
This release fixes a fatal memory leak during reconstruction of the block log index. This update is optional so long as you do not need to reindex. However, if your block log index needs to be reconstructed, this update is required.
This is a bug fix release primarily targeting the RC Plugin.
Note: witness_api plugin no longer exists, and should be removed from config.ini if present.
Nodes running the RC plugin need to manually force a reindex with --replay.
Nodes that do not run the RC plugin do not need to upgrade or replay.
At this time we recommend witnesses and API nodes upgrade.
This is an optional release for exchanges. While the RC values will be different on 0.20.5 and 0.20.6, we have determined through our testing the difference will not be significant and should not cause problems for exchanges. If an exchange wants to update we recommend reindexing 0.20.6 up on a separate machine and switching only once the 0.20.6 node is functional.
RCs are no longer calculated prior to HF20 (#3007)
Removed the old bandwidth system. This includes the removal of several API fields that were specific to bandwidth and the removal of the witness_api, which was used exclusively for returning information related to bandwidth. (#3029)
Changes were made to the RC parameters to conserve current pricing while more aggressively protecting blockchain resources at high usage levels. (#3061)
The state byte cost for votes has been reduced as votes are only required in consensus before a comment has been paid. (#3064)
Negative RCs are limited to 2 hours worth of regeneration. (#3050)
The execution time cost of custom json operations has been reduced by 20 times for all custom json operations except those used by the follow plugin. (#3027)
RC Execution Time was not be charged against ops. This has been fixed and execution time is properly being checked. (#2972)
Fixed command line interface compatibility issues with boolean flags. Flags work as intended on the command line but are settable to boolean values in the config file. For example, on the command line you can set --enable-stale-production or set it as enable-stale-production=true in the config. (#3025)
The account creation fee in the command line wallet uses the correct HF 20 value. (#3019)
Release notes for 0.20.5
[1] If you choose not to upgrade, you should re-consider if you notice that transactions submitted to your node seem to frequently get "lost," i.e. not included in blocks. Upgrading to 0.20.5 should fix this issue.
[2] If you choose not to upgrade, you should re-consider if the accounts broadcasting transactions on your node have low Steem Power or RC. Upgrading to 0.20.5 should fix issues experienced by such accounts.
This is a bug fix release regarding the rc plugin. All nodes running the rc plugin should to upgrade to 0.20.4.
Steem 0.20.4 requires reindexing from previous version if running the rc plugin. Please note: The witness plugin and network broadcast API specify the rc plugin as dependencies. All of the provided Docker configs run the rc plugin.
All nodes should to upgrade to 0.20.2.
Steem 0.20.2 does not require reindexing from 0.20.1. If upgrading from 0.20.0 or older, reindexing is required.
This is a hard fork release. The primary changes in this release are to the account creation and voting power systems and the addition of the resource credit system.
Steem 0.20.2 is built on top of the Appbase architectural changes released in Steem 0.19.10. If you are not familiar with the changes introduced in that release, we strongly recommend you read those release notes as well.
Steem 0.20.2 usurps 0.20.1 as the official release for Steem Velocity and contains some changes to how the RC system will behave at the time of the hardfork to create a better user experience.
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.
There are a new pair of operations, claim_account_operation and create_claimed_account_operation that upgrade the account creation process. When combined, these operations work identically to the current account_create_operation. When used separately, this allows an account to pool claimed accounts and create them at will later on. When combined with subsidized account creation, this will lead to the smoothest user experience by allowing faucets to buffer subsidized accounts at a steady rate and consume them sporadically to meet user demand.
It is recommended that all faucets upgrade to use this creation flow as any possible future updates to account creation are more likely than not to be implemented using these operations.
struct claim_account_operation
{
account_name_type creator;
asset fee;
extensions_type extensions;
};
struct create_claimed_account_operation
{
account_name_type creator;
account_name_type new_account_name;
authority owner;
authority active;
authority posting;
public_key_type memo_key;
string json_metadata;
extensions_type extensions;
};
After HF 20 goes into effect, the blockchain will begin limited subsidization of account creations. A subsidized account can be created by paying a fee of 0 STEEM with the claim_account_operation. There are consensus and non-consensus limits on subsidized account creation. There are two primary consensus mechanisms. The first is a global pool of subsidized accounts that is enforced in consensus. This prevents unlimited creation when to pool is empty. The dynamics of the pool are controlled by the witnesses and discussed later. The second is a per witness consumption that prevents a compromised witness from draining the subsidized account pool. The non-consensus limit exists in the RC Plugin and charges account creators RCs to create subsidized accounts. The consensus supply is used as input to determine the cost in RCs of creating a subsidized account.
The account_create_with_delegation_operation is deprecated and as of HF 20 will stop working. This was an initial attempt at cheaper account creation and is eclipsed by subsidized account creation.
The account creation fee is now burned upon account creation instead of being powered up to the new account. To compensate for the reduction in available RCs, each new account is granted a bump to their RCs proportional to the burned fee. This is retroactively applied to all accounts created prior to HF 20.
We are removing the minimum power down restriction that prevents users from powering down their Steem Power until they have earned a certain amount. This was created to prevent new accounts from instantly powering down the STEEM used to fund the account. Because STEEM is now burned when an account is created, this restriction is not needed.
There are a number of new properties added in Steem 0.20.2 and the existing witness_update_operation does not support extension. witness_set_properties_operation is an extensible replacement that supports new properties added in 0.20.2 and can support properties that may be added in later releases.
Documentation on witness properties can be found here.
struct witness_set_properties_operation : public base_operation
{
account_name_type owner;
flat_map< string, vector< char > > props;
extensions_type extensions;
When account_create_with_delegation_operation was introduced, we changed the semantics of the account creation fee. In Steem 0.20.2 we are reverting the semantics back to the original. After HF 20, the account creation fee is simply the required STEEM to create an account and the complications that were added will be removed. To ease this transition, at the time of the hardfork, all elected witnesses will have their account creation fees increased by 30x. The amount of STEEM required to make an account before and after the hardfork will not actually change. Witnesses are required to update their infrastructure to account for the change after the hardfork, but the blockchain will ease the transition.
It has already become customary to report price feeds as an SBD:STEEM pair. HF 20 will require the price feed to be reported this way for consistency and optimization.
As a restriction of the p2p code, the highest votable max block size will be limited to 2MiB.
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.
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.
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.
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.
Limit orders must expire within 30 days of creation. Existing limit orders with long or non-existent expirations are having their expiration set to 30-31 days (deterministically pseudorandom) after HF 20.
The curation "reverse auction" window has been reduced from 30 to 15 minutes.
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.
For the last 12 hours before content is rewarded both positive and negative changes to reward payouts will decline linearly. Previously only upvotes were allowed which lead to some users waiting until their content was about to pay out and then upvoting it considerably without fear of moderation. The symmetric approach to positive and negative feedback prevents excessive trolling and rewards exploitation equally.
The comment cooldown of 20 seconds is being reduced to 3 seconds (one comment per block).
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%).
The definition of canonical Steem signatures now follows the BIP-0062 specification to prevent transaction malleability. The previous implementation was not quite right and while it did not allow transaction malleability, it did reduce the entropy of canonical Steem signatures.