EOSIO.contracts Version 1.6.0: Scaling Accessibility of Network Resources through a Resource Exchange (REX)

As a contributor to the development and enhancement of the EOSIO™ software, we are pleased to confirm that a stable release is available for EOSIO.contracts. For a full list of updates made in this release, please refer to the Summary of Changes in EOSIO.contracts v1.6.0 in detail on Github and the description in issue (#117). This release focuses primarily on issues related to REX (#94, #182, #196, and #208).

The intention of The Resource Exchange (REX) functionality is to enable token holders to rent portions of their CPU and Network resources to those needing more computational power to operate applications on the platform. In this release, we focus on what we believe to be a more robust functionality for the contracts supporting REX for the community to review, adapt, and build on.

Interested users can review the Bancor equations that were used to support REX and the possible choices for initializing the system. An overview of these considerations will be detailed further in an article forthcoming by Block.one engineers who have been working on these issues.

Allocation of Network Resources through an Exchange

The functionality provided in this release for REX-related contracts are provided within the eosio.system contract without corresponding user interfaces and deployment choices. REX contract code provided is not a product in and of itself, but is intended as a baseline for contracts that developers can utilize to create exchange products that enable this functionality for users of EOSIO-based blockchains.

As such, REX provides contracts for a CPU and Network resource rental marketplace in which holders of the core token of the blockchain can lend portions of their existing resource allocations by buying (lending resources) and selling (un-lending resources) REX tokens into the REX pool.

Blockchain application developers can rent CPU and Network resources from the REX pool to meet their resource needs. The duration of each loan, as designed, is 30 days and the loan price is determined by an automated market maker. Note that a REX token is not tradable, it is merely a convenient accounting unit and helps determine the return rate available to REX holders as determined by the level of rental activity. Optionally, proceeds from RAM trading fees and account name auctions can also be channeled to the REX pool, thus providing an additional source of return to REX holders.

One byproduct of the way REX contracts have been developed is that it has the potential to increase voter engagement on public EOSIO-based blockchains. Core token holders are only allowed to participate in the REX pool (earning tokens for renting their available resources) only after having voted for at least 21 Block Producers or having delegated their votes to a proxy.

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 impact any of the funds already collected in the `eosio.ramfee` and `eosio.names` accounts.

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

Deploying REX in your Environment

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 eosio.rex must not be a privileged account.

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.

ABI file `rex.results.abi` (generated automatically) needs to be deployed on account `eosio.rex`. The corresponding contract `rex.results.wasm` must NOT be deployed. The actions `buyresult`, `sellresult`, `rentresult`, and `orderresult` of `rex.results` are all no-ops. They are added as inline convenience actions to `rentnet`, `rentcpu`, `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 trace.

Adjusting the REX Pool Virtual Balance

Action setrex allows Block Producers to reset the `total_rent` balance of the REX pool to a given value, if the need arises. It is important to note that this action is NOT required to initialize the REX system and is not recommended to be used more than once. It is a backup mechanism that allows Block Producers to balance the renting market prices in case the initial settings were impractical and not in line with the amount of tokens lent to REX. `total_rent` is a virtual balance and no real tokens will be added or removed in this action.

Stay Connected

If you are interested in providing feedback and working more closely with our team to improve the EOSIO software for developers, you can send our developer relations team an email at developers@block.one.

You can also keep up to date with future updates by subscribing to our mailing list on the EOSIO Developer Portal. We are excited to be continually improving the usability of the software for EOSIO developers as we continue laying a foundation for the mass adoption of blockchain technology.

All product and company names are trademarksTM or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.

Disclaimer

Block.one makes its contribution on a voluntary basis as a member of the EOSIO community and is not responsible for ensuring the overall performance of the software or any related applications. We make no representation, warranty, guarantee or undertaking in respect of the releases described here, the related GitHub release, the EOSIO software or any related documentation, whether expressed or implied, including but not limited to the warranties or merchantability, fitness for a particular purpose and noninfringement. In no event shall we be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or documentation or the use or other dealings in the software or documentation. Any test results or performance figures are indicative and will not reflect performance under all conditions. Any reference to any third party or third-party product, resource or service is not an endorsement or recommendation by Block.one. We are not responsible, and disclaim any and all responsibility and liability, for your use of or reliance on any of these resources. Third-party resources may be updated, changed or terminated at any time, so the information here may be out of date or inaccurate.