EOSIO Contracts v1.3.1 Release Notes

Multisig contract

This release fixes a discrepancy in a struct definition within the ABI of the eosio.msig contract (#76).

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.

EOSIO Contracts v1.2.1 Release Notes

System contract

This release fixes adds the ability to limit resources allocated to previously unlimited system accounts such as eosio.token to prevent the abuse of those unlimited resources.

This release adds additional authorizations on transfers from eosio.vpay eosio.bpay eosio.stake and eosio.names so that receivers of funds from those accounts can use their own RAM to create account balance records in eosio.token. This mirrors changes made in version 1.1.0 to the buyram action.

This release fixes a bug where a contract on a previous high-bidders account could block attempts to outbid any name auctions resulting in an uncontestable auction.

EOSIO Contracts v1.2.0 Release Notes

System contract

The setramrate action will now first update the RAM supply based on the old rate prior to changing the RAM growth rate to the new rate specified in the action. Other improvements were also made to the implementation of setramrate so that the instantaneous RAM supply never temporarily lags behind (because of missed block production slots) what it should be at the time of buying or selling RAM.

Due to initial over-conservative estimates of the amount of RAM overhead costs per account, 1400 extra bytes RAM was identified to be safe to return to each account. However, because the amount of bytes charged for the fixed overhead of creating account is part of the protocol, it would require a consensus-breaking change to reduce the charged amount.

Instead, this system contract upgrade effectively achieves the same results by gifting all accounts a free 1400 extra bytes to their RAM quota. All new accounts will have the additional 1400 bytes of RAM from the very beginning, which effectively drops the minimum RAM requirements to create a new account by 1400 bytes. For existing accounts, the same RAM quota increase of 1400 bytes will be reflected on their account the first time that they sell ram, buy ram, or delegate/undelegate CPU/network bandwidth.

Dependencies

This release depends on EOSIO.WasmSDK v1.1.x and a version of EOSIO no older than v1.1.2. To compile the contracts in this release, first build and install EOSIO.WasmSDK v1.1.0 and EOSIO v1.1.3.

EOSIO Contracts v1.1.1 Release Notes

System contract

This release fixes a bug in the account name auction logic which prevented account name auctions from closing at the intended time. The bug caused closed name auctions that had not yet been claimed to block other eligible account name auctions from closing.

EOSIO Contracts v1.1.0 Release Notes

Token contract

In case that action transfer needs to create new database row for storing user's balance, the contract bills storage of the row to the user which balance belongs to, if the user's authorization was provided

New action retire introduced, it removes tokens from circulation

New action close introduced, it removes balance for given account and token from the database and frees storage. action transfer no longer removes balance from database even if it reaches zero

System contract

Action sellram provides authorization of caller to eosio.token contract action transfer when transferring system tokens from eosio.ram account in order to avoid billing RAM to eosio.ram account

Action buyram provides authorization of eosio.ram' account to eosio.token contract action transferwhen transferring system tokens from caller to eosio.ram in order to bill RAM to eosio.ram account

Add action setramrate. It allows producers to set the rate at which RAM supply (in bytes) increases per block. Amount of new RAM is calculated and added to the supply every time someone buys/sells RAM. RAM is then priced based on the new supply.

Another change to the system contract is removing multiplying/dividing by 1000 in bancor algorithm connector weights used in calculating RAM price. It can be proved that RAM price remains invariant under this change. However, rounding errors are reduced.

EOSIO.WasmSDK

This repo requires the new eosio.wasmsdk to build the contracts.

EOSIO Contracts v1.0.0 Release Notes

Introducing the eosio.contracts repo

Block.one is pleased to announce the public release of the eosio.contracts repository. This repository is a collection of contracts offered as examples for various systems which are useful when deploying, managing, and/or using an EOSIO blockchain. They are provided for educational purposes.

Additions to EOSIO/eos v1.0.8 included in this release

Introducing Example Contract eosio.sudo (EOSIO/eos#4429)

eosio.sudo is a contract that provides administrative access to actions on behalf of other accounts. Access to such features can be controlled via the rich permission and authority structure of EOSIO allowing for a powerful but ultimately flexible tool for EOSIO-based blockchains.