Skip to content
This repository has been archived by the owner on Aug 30, 2022. It is now read-only.

[CANDIDATE] EOSIO Contracts v1.6.0-rc2 Release Notes

Pre-release
Pre-release
Compare
Choose a tag to compare
@blockone-devops blockone-devops released this 07 Feb 02:27
· 94 commits to release/1.6.x since this release
82de548

This is a RELEASE CANDIDATE for 1.6.0. The latest STABLE release is v1.5.2.

System contract

The proxy account is no longer notified as a recipient when the stake or votes of those proxying to them change. This change may effect the existing behavior of a contract deployed on an account registered as a proxy if the contract relies on receiving such a notification. Despite the potentially breaking change, the notification to recipients was removed from the system contract because malicious proxies could potentially utilize the notification mechanism to cause a limited denial of certain services to the accounts that have selected them as a proxy.

Three new actions have been added to the system contract to enable explicit management of system resources: setacctram, setacctnet, setacctcpu. These new actions can enable authorized entities, e.g. active block producers, to override the automatic management of particular types of resources limits for specific accounts by pinning the resource quota amount to a provided value. The actions also enable undoing the override by unpinning the resource quotas and allowing them to again be automatically managed by the appropriate system contract mechanism such as the RAM market or staking/delegating CPU and/or network bandwidth resources.

When a particular resource quota of an account is pinned to some value, the typical system contract mechanisms that would change that quota are still allowed to work as usual with the one exception that they would no longer adjust the quotas recognized by the native EOSIO blockchain system. For example, setacctram makes it possible for a two-thirds supermajority of active block producers to pin the RAM quota of an account to some appropriate limit and then sell the existing RAM balance held by account in the RAM market. Or it can allow pinning the CPU and network bandwidth limits of a critical system account such as eosio to unlimited to ensure that critical functions like the eosio::onblock action (which are billed to the eosio account) are not disrupted. For more information about this feature see #172.

REX

This release candidate includes fixes to bugs found in the v1.6.0-rc1 release of REX. For details about the bug fixes, see PR #182.

Changed initial Bancor connector balance to a lower value. This lowers initial renting costs.

Added inline convenience actions to buyrex, unstaketorex, and sellrex. An inline convenience action does not have any effect, however, its data includes the result of the parent action and appears in its action trace. Thus it makes it easier to read the amount of purchased REX or proceeds gained from selling REX.

This release candidate also introduces the concept of a REX savings bucket. In addition to maturity buckets introduced before, a REX owner can now utilize a special bucket which we call the "savings bucket". REX held in this bucket does not mature and cannot be sold directly. Users can move already purchased REX from other buckets to their savings bucket at will using the new action mvtosavings. This action moves REX out from the user's buckets as necessary starting with the bucket with the furthest maturity date. In order to sell REX in the savings bucket, the user must first explicitly move tokens out of it using the new action mvfrsavings which can be executed at any time. The mvfrsavings action moves REX from the savings bucket to a bucket with a maturity date that is 4 days after the end of the day.

Dependencies

This release depends on eosio.cdt v1.5.x and eosio v1.4.x or v1.5.x or v1.6.x. To compile the contracts in this release, first build and install eosio.cdt v1.5.0 and eosio v1.6.1.