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

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

All contracts

The minimum dependency on eosio.cdt is now v1.5.x. The 1.5 version of eosio.cdt (currently only available as a release candidate v1.5.0-rc1) introduces a new pattern for building smart contracts (uses a new CMake toolchain file and builds the contract code within an external CMake project) which all contracts in eosio.contracts have been updated to take advantage of. All the contracts have also been updated to use the more efficient eosio::check function which is a drop-in replacement for eosio_assert.

System contract

REX (Resource Exchange)

We are excited to introduce REX into the eosio.system contract. It is a CPU and Network resource rental market in which holders of the core token of the blockchain can buy and sell slices of the REX pool in the form of REX tokens. Note that a REX token is not tradable, it is merely a convenient accounting unit. Its value in terms of the core token always increases, but the return rate is determined by the level of rental activity. Proceeds from RAM trading fees and account name auctions can be channeled to the pool, thus providing an additional return to REX holders. Blockchain users can rent CPU and Network resources from the REX pool. The duration of each loan is 30 days and its price is determined by an automated market maker.

We look forward to the community thoroughly testing REX in test networks. The insights gained from the testing can help us improve REX prior to the official release of v1.6.0 of eosio.contracts.

For more information about REX see the description in issue #117.

Channeling system fees to REX

The source code of the eosio.system contract is by default set up to channel the account name auction fees and the fees collected from buying and selling RAM to the REX pool. The channeling of these fees only occurs for new fees collected; it does not touch any of the funds already collected in the eosio.ramfee and eosio.names accounts.

The channeling of these fees can be easily disabled in the source code by setting the CHANNEL_RAM_AND_NAMEBID_FEES_TO_REX macro (defined in eosio.system.hpp) to 0.

Deployment

The REX introduces new setup requirements for initializing the system contract.

The account eosio.rex must now be created in addition to all the other existing system accounts prior to deploying the new system contract.

The eosio::init action, which is only needed when deploying the system contract to a blockchain for the first time, was introduced in v1.4.0 of eosio.contracts. In this release, it has further been modified to send an inline eosio.token::open action to open a zero-balance entry corresponding to the core token symbol for the eosio.rex account. The eosio.token::open action was first introduced to the eosio.token contract in v1.3.0 of eosio.contracts. It is recommended to deploy a recent version of the token contract (at a minimum version 1.3.1) to the eosio.token account prior to deploying the new system contract. If an older version of the token contract is deployed, the eosio::init action will still succeed, however when the inline eosio.token::open action executes it may do nothing.

If this version of the system contract is replacing an existing deployment of an older version of the eosio.system contract, then no eosio::init action is necessary or even allowed. Block producers can optionally execute the eosio.token::open action to create the zero-balance entry to the core token symbol for the eosio.rex account. However, even if this is not done, REX will still be able to fully operate.

Dependencies

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