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

EOSIO.Contracts v1.9.0 Release Notes
Compare
Choose a tag to compare
@blockone-devops blockone-devops released this 10 Jan 22:36
· 116 commits to master since this release
v1.9.0
636406b
This commit was created on github.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.

The eosio.system and eosio.bios contracts contained in this release can only be deployed on an EOSIO blockchain after the activation of the WTMSIG_BLOCK_SIGNATURES consensus protocol upgrade.

System contract

New regproducer2 action

A new action regproducer2 has been added to the eosio.system contract (#349). This action acts an alternative to the existing regproducer (which still remains) to allow an account to register as a block producer candidate with a weighted threshold multi-signature (WTMsig) block signing authority (see the release notes for eosio v2.0.0) rather than just a single public key.

Note: The changes to the eosio.system contract introduce both binary extensions and variants (which are ABI 1.1 features) to the contract's ABI. Clients must support these ABI 1.1 features if they are to interact with the new eosio.system contract.

Changes to REX (#413)

In releases of the system contract prior to v1.8.3, the proceeds from CPU and NET loans, RAM trading fees, and name auction bids were immediately added to the REX pool which effectively distributed those proceeds pro rata to REX holders instantly. In this release, the proceeds are instead first collected into a staging pool within REX and then gradually distributed to REX holders linearly with time over a period of 30 days starting within 12 hours from the time at which the proceeds were collected into the REX staging pool.

REX tries to maintain a lower bound on the unlent balance to provide robustness in the rental price tracked by REX. To prevent a sell order from dropping the unlent percentage of the total tokens held by REX below a pre-determined fraction (thus violating the unlent balance lower bound), REX must delay the sell order by placing it in a sell queue to be processed at a later time when the sell order can be fulfilled without violating the lower bound. Any sell orders on the sell queue block further renting in order to satisfy the requirement that sell orders be fulfilled within 30 days of first entering the sell queue. Without an unlent balance lower bound, the REX rental price could become unstable under certain conditions and end up offering all available tokens to rent at too cheap of a price (click here to learn more about the mathematics behind the REX rental pricing algorithm). So while the unlent balance lower bound is necessary with the current REX rental pricing algorithm, there is some flexibility available in the particular choice of the pre-determined fraction value.

In releases of the system contract prior to v1.8.3, REX ensured that a sell order could not cause the amount of unlent tokens to become less than 20% of the amount of lent tokens (or equivalently that the unlent fraction of the total tokens held by REX could not go below one-sixth due to a sell order). This release lowers that threshold percentage from 20% to 10% which means that a larger fraction of tokens in REX can be lent out before further sell orders are forced into the sell queue.

Other changes within system contract

When someone outbids an existing account name, the system contract generates a deferred transaction containing the eosio::bidrefund action to return the funds of the account that was outbid. In releases of the system contract prior to v1.8.1, this action was authorized by the active permission of the eosio which meant the CPU/NET costs of the entire deferred transaction was billed to the eosio account. As of this release, the authorizer of the eosio::bidrefund action is the active permission of the account that was outbid (#383).

The system contract tracks a variable (total_activated_stake) to determine the first moment when 15% of all stake has voted so that it can trigger full activation of the system's features. After activation occurs, this variable is no longer needed. In releases of the system contract prior to v1.8.2, this variable continued to be updated even though it no longer had a purpose or even a well-defined meaning after activation. Furthermore, checks within the code that enable full functionality still referred to this variable. Since manipulation of this variable could potentially have adverse effects on the operation of the system contract, this release prevents further updates to the variable after activation and avoids depending on its value in the logic of the code after activation (#400).

Bios contract

The interface of the setprods action of the eosio.bios contract has been modified (#349) to take a producer schedule consisting of WTMsig block signing authorities rather than a producer schedule consisting only of single public keys per each block producer.

Other Changes

  • (#328) Prevent overflow within claimrewards in cases of extreme inflation - develop
  • (#334) [develop] Fix build breaking when specifying commit hash
  • (#338) Wait for Base Image Build
  • (#333) Update minimum CDT dependency to 1.7.x
  • (#348) Update minimum EOSIO dependency to 2.0.x
  • (#354) Change pronoun in buyrex Ricardian summary - v1.9.x
  • (#360) [1.9.x] Test metrics fix
  • (#356) Add eosio.contracts documentation content to release/1.9.x
  • (#373) [1.9.x] Fix for forked PRs.
  • (#379) [1.9.x] CI/CD: switch from gke to eks

Dependencies

This release depends on eosio.cdt v1.7.x and (optionally) on eosio v2.0.x. To compile the contracts in this release, first install eosio.cdt v1.7.0. To also compile the unit tests, first build and install eosio v2.0.0. The eosio.bios and eosio.system contracts in particular also require that the WTMSIG_BLOCK_SIGNATURES consensus protocol upgrade has been activated on the EOSIO blockchain before they can be deployed. When starting a fresh blockchain, an older version of the eosio.bios contract (v1.7.x or v1.8.x) could be used to first activate the WTMSIG_BLOCK_SIGNATURES protocol feature.

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.

Assets 2
Loading