EOSIO v1.8.5 Release Notes
This release contains stability and miscellaneous fixes.
Stability bug fixes
Subjective CPU Leeway (#8027)
Since the initial 1.0 release, EOSIO has had a feature called subjective CPU leeway. This feature allows the CPU usage of a transaction to temporarily go beyond the limit imposed by the billed accounts' CPU quotas during execution in order to give the transaction a chance to increase the CPU quotas (and therefore the imposed limit) by the end of the transaction. The system enforces that the excess CPU usage beyond the initial quota-driven limit does not exceed the subjective CPU leeway configured on the local node as a mechanism to protect the local node. Nodes configured with too low of a subjective CPU leeway may not give a transaction enough time to demonstrate that it would have had enough resources to cover its costs by the end of the transaction, and in such a situation that transaction would be rejected by the node.
On EOSIO blockchains that deploy the reference system contracts, this feature can enable a user that has no tokens staked on their account to push a transaction that stakes sufficient tokens from their liquid token balance. The amount of tokens staked by the end of the transaction must be large enough to cover the aggregate CPU usage of the billed account(s) at that point in time.
However, because the measured CPU usage of a transaction is subjective, some EOSIO nodes along the path from the client to the block producer node may consider the temporary excess CPU usage of the transaction to be larger than their locally configured subjective CPU leeway and therefore drop the transaction. If enough relay nodes drop the transaction in this manner (or if its dropped by the single API node that initially receives the transaction), then the transaction will be unable to propagate through the peer-to-peer network and reach a block producer node to be included in a block.
While prior versions of EOSIO have allowed changing the default value (3 ms) of the subjective CPU leeway through the update_runtime_options RPC of the producer API, there was no convenient way to change this value through a configuration parameter prior to this release. This release introduces the subjective-cpu-leeway-us configuration parameter to chain_plugin which makes it easy for node operators to change the leeway using a config.ini entry or command-line options.
Furthermore, measurements of common transactions related to staking (e.g. the transactions discussed earlier that staked tokens to an account starting with zero tokens staked) showed that on some machines the measured CPU usage could often exceed the default subjective CPU leeway value. If enough nodes with similar performance characteristics were present in the peer-to-peer network (or were the API nodes), it could lead to these "staking from zero" transactions being unreliable. So this release also increases the default value of the subjective CPU leeway to 31 ms. In EOSIO networks where enough nodes have adopted this new higher value (e.g. by simply using EOSIO v1.8.5 or later with the default settings), these changes will likely improve the reliability of "staking from zero" and similar transactions.
Greylist Limit (#8051)
EOSIO 1.1.0 introduced grey listing as a feature. This feature enables a node to subjectively restrict the CPU and NET resource limits of some transactions to what they would be if there were elastic bandwidth benefit provided by the network (e.g. when the network resources are heavily utilized) even when there is low usage of network resources. This restriction in resources is selectively applied only to accounts that are on a locally configured grey list.
This release of EOSIO now adds another tool for subjectively restricting CPU and NET resources: the greylist limit. This limit applies grey listing restrictions to transactions in a manner that simulates what it would be like if the elastic bandwidth multiplier (which can vary from 1 to 1000) was capped by the greylist limit. This is a subjective mechanism just like the original grey listing mechanism; so, the restriction only applies to speculatively executing transactions and each node is able to define its own limit through the new greylist-limit configuration option in producer_plugin (it can also be changed during runtime using the update_runtime_options RPC of the producer API). However, unlike the original grey listing mechanism, the greylist limit applies to all accounts (not just the accounts explicitly specified in the grey list).
To learn more about one way the greylist limit can be used in EOSIO networks and the motivations behind developing this mechanism, please see this article.
Other Changes
- (#8020) [1.8.x] Change submodule script to see stderr for git commands
- (#8040) [1.8.x] dockerhub | eosio/producer -> eosio/ci
- (#8064) [1.8.x] Upgrade mac anka template to 10.14.6
- (#8087) [1.8.x] Linux build fleet update
Disclaimer: All repositories and other materials are provided subject to this IMPORTANT notice and you must familiarize yourself with its terms. The notice contains important information, limitations and restrictions relating to our software, publications, trademarks, third-party resources, and forward-looking statements. By accessing any of our repositories and other materials, you accept and agree to the terms of the notice.