EOSIO Contracts v1.3.0 Release Notes

Token contract

A new action open (#61) is introduced to complement the existing close action. The open action allows an arbitrary payer to create (and pay for the RAM of) a new zero-balance token table row for an account. The initial setup using the open action makes it possible for a transfer of that token to the account (even for the first time) to not incur RAM costs to the sender.

This new action is the first step in a significant change in the behavior of the transfer action of the eosio.token contract.

As was discussed in a prior blog post, a recommended EOSIO protocol upgrade will eventually be introduced to objectively enforce the restrictions on billing RAM to other accounts from within the context of an action notification (which as of the v1.2.3 release of EOSIO is already possible to enforce subjectively by block producers).

And now as part of this release, the current behavior of eosio.token::transfer to implicitly create a token table row if one does not already exist is deprecated, and the new behavior of the action (#62) will eventually be enforced in a future release of eosio.contracts. The new behavior (which is not yet enforced as of this release) will require a zero-balance token table row to already exist in order for the transfer to succeed. Clients that want to maintain the old behavior of transfer going forward (for example unsolicited airdrops that should succeed even if it means the sender has to initially pay the RAM costs for the receiver) should modify their transactions to first open the balance before they then transfer the token into that new balance.

With the above two changes (objective enforcement of restricted RAM billing during notify and no table rows implicitly created during a eosio.token::transfer action) eventually fully realized, it would become possible to guarantee that the sender of tokens via a simple eosio.token::transfer action would not be billed additional RAM.

Multisig contract

The behavior of multisig proposals in the eosio.msig contract has been modified to respect the effect of a new action: invalidate (#59). The eosio.msig::invalidate action allows an account to invalidate all prior approvals it provided to any pending proposals. This action provides a simple way to close one loophole (#53) that a malicious account seller could use to take back control of the account (via a pending approved proposal with an updateauth to change the owner authority) immediately after completing the sale of their account. Account buyers should be aware though that other similar loopholes remain via deferred transactions and the safest way to trade ownership of accounts is to use trusted escrows with the expertise to manually audit the possible pending issues associated with the to-be-purchased account to ensure the buyer is getting what they expect.

System contract

Tracking ABI hashes

The system contract now includes a new table abihash (#48) which includes the SHA256 hash of the most recent ABI set using eosio::setabi for each account (only for eosio::setabi actions executed after this version of the system contract is deployed).

New producer pay algorithm

A new and improved algorithm for calculating per-vote producer pay is introduced (#58) in v1.3.0 of the eosio.system contract. The new algorithm better fulfills the intent behind the per-vote producer rewards system that the original algorithm also attempted to fulfill.

The main difference between the new algorithm and the original one is that the new algorithm, when fully activated, uses a new metric called "votepay share" to determine the fraction of the per-vote producer reward bucket to pay out to the claiming producer during the execution of the claimrewards action. This new votepay share metric is defined (at least for the first three days after claiming rewards) as the time integration of the total weighted votes for that producer starting from the last time that producer claimed rewards until the present time. Using this new metric during claimrewards fixes some flaws in the original algorithm that in theory could be abused to give some producers a larger share of their per-vote producer rewards than was intended.

One of the side-effects of the new algorithm is that the accumulation of votepay share over time has to have an upper time limit in order to not bypass the intent behind the lower threshold limit on per-vote producer pay imposed on block producer candidates that are claiming rewards (which is still enforced in the new algorithm). So, the new algorithm also imposes a further restriction which requires claimrewards to be executed prior to three days after the last time it was executed, otherwise the per-vote portion of the producer rewards would be zeroed out.

Even after deployment of the new system contract, the claimrewards action will continue to use the original algorithm until active block producers explicitly activate the switchover by advancing the system contract revision to 1 using the new updtrevision action. It is not recommended for producers to update the revision of the system contract to 1 immediately after deploying the new version to the blockchain. Instead, sufficient time (e.g. 1 week) should be given to allow existing producers to update their records to prepare for the switchover to the new producer pay rules.

Currently registered producers are recommended to update their producer records in preparation for the switchover after the new contract is deployed by executing either the regproducer or claimrewards actions as they normally would; doing so before the switchover ensures that the producers do not miss out on any of the per-vote producer rewards that they are entitled to during the transition from the original algorithm to the new algorithm. Even if a producer remains dormant throughout the period of time from contract deployment to activation of the new algorithm via the updtrevision action, the only rewards they may miss out on are the per-vote producer pay rewards that they could have accumulated and claimed between the time of algorithm activation and the first time afterward that they execute either a regproducer or claimrewards action.

Dependencies

This release depends on v1.2.x of EOSIO.CDT (formerly known as EOSIO.WasmSDK) and EOSIO v1.2.x. To compile the contracts in this release, first build and install EOSIO.CDT v1.2.0 and EOSIO v1.2.4.