EOSIO.Contracts v1.7.0 Release Notes
EOSIO.Contracts v1.7.0 is required to support activation of nearly all of the consensus protocol upgrades introduced in EOSIO v1.8.0. The eosio.system and eosio.bios contracts contained in this release can only be deployed on an EOSIO blockchain after the activation of the PREACTIVATE_FEATURE consensus protocol upgrade.
Ricardian contracts (#263)
A set of reference Ricardian contracts is now included for all actions in the five smart contracts in the eosio.contracts repository. These Ricardian contracts build upon the ones already released in v1.6.1 by adding Ricardian contracts for the new eosio::activate and eosio::reqactivated actions. The Ricardian contracts also come with icons that are free to use under the same MIT License as the source code (please see the notes under the License section of the README for details). Be aware that to actually deploy the contracts with working Ricardians for production use, the icons will need to be hosted on a public server and the URL to the icons need to be in the generated ABI files for the contracts. This requires changing the base URL for the icons by setting the appropriate variable in the contract CMakeLists.txt file before compiling the contracts.
Token contract
The eosio.token::open action will now ensure the owner account exists before creating a zero-balance table row for the account (#271).
After activation of the RESTRICT_ACTION_TO_SELF protocol feature, the eosio.token::issue action will no longer be able send an inline transfer when issuing tokens to an account other than the issuer. In preparation for this change in capabilities, the eosio.token::issue action's behavior has been modified to explicitly disallow issuing tokens to any account other than the issuer (#232). Token managers who use the eosio.token reference contract and wish to continue issuing tokens to other accounts will need to replace the single eosio.token::issue action with a transaction with two actions: one that first issues tokens to the issuer and then the second one that transfer that same quantity of tokens from the issuer to the intended recipient.
System contract
Due to the change to eosio.token::open described earlier, the eosio::init now requires that the eosio.rex account exists before it is called.
This release adds a new action activate to the system contract (#220). The activate action pre-activates (which then subsequently activates at the start of the next block) the protocol feature represented by the digest (hash) provided in the action data.
The implementation of the activate action requires linking against a new intrinsic function which is only made available after the PREACTIVATE_FEATURE protocol feature is activated on the EOSIO blockchain. This means that until that protocol feature is activated, it will not be possible to deploy this system contract to the chain.
In addition, the implementation of the Bancor algorithm behind buying and selling RAM has been simplified while maintaining the same behavior (#222). Both mathematical and empirical analyses have shown that the change in the implementation does not materially change the behavior of the actions to buy and sell RAM. Furthermore, the estimation used in the buyrambytes action has been improved to allow the buyer to pay a calculated amount of tokens in exchange for a number of bytes of RAM that is very close to the number they requested in the action (#258).
Finally, if any deferred transactions that were sent by the system contract (such as the ones including the refund or bidrefund actions) objectively fail, they will now automatically advance to a hard_fail (rather than soft_fail) because the onerror action handler of the system contract now rejects being called or notified (#265). This means that the eosio account can no longer be billed for the CPU/NET usage of the failed deferred transaction.
Bios contract
The same activate action added to the system contract has also been added to the bios contract (#220). The bios contract also has a new action reqactivated which asserts that the protocol feature represented by the provided digest has been activated. In addition, the onerror action can no longer be directly called and it will also reject notifications of the onerror action (#265). Finally, the unnecessary setglimits action was removed from the bios contract (#263).
Multisig and Wrap contracts
If any deferred transactions that were sent by the multisig or wrap contracts (such as eosio.msig::exec or eosio.wrap::exec) objectively fail, they will now automatically advance to a hard_fail (rather than soft_fail) because the onerror action handler of these contracts will reject being called or notified (#265). This means that the eosio.msig and eosio.wrap accounts (assuming those are the accounts on which the multisig and wrap contracts are deployed respectively) can no longer be billed for the CPU/NET usage of the failed deferred transactions.
Other changes
- (#188) Created Buildkite Pipeline with Docker Build
- (#202) Producer pay vars update
- (#201) Fix/update votes
- (#197) Contracts Pipeline: Add Test Steps and Use Pre-Built EOSIO Docker Images
- (#223) Annotate all public EOSIO system contracts' classes, structs, methods, actions
- (#230) Change add_eosio_test to add_eosio_test_executable
- (#228) Fix broken links in README.md
- (#226) fix description comment typo
- (#231) Added ctest Error Handling
- (#218) Deleted docker files and scripts used by old contracts pipeline
- (#239) Created Universal Pipeline Configuration File
- (#255) fix assertion in create_core_token; clean up inconsistent license references - v1.7.x
- (#260) Implemented support for custom eosio and eosio.cdt installation paths.
- (#265) remove unnecessary EOSIO_DISPATCH macros; add action wrappers for activate and reqactivated actions - v1.7.x
- (#267) update contracts to work with new CDT headers - 1.7
- (#273) fix double-move bug in system_contract::registration - v1.7.x
Dependencies
This release depends on eosio.cdt v1.6.x and eosio v1.8.x. To compile the contracts in this release, first build and install eosio.cdt v1.6.1 and eosio v1.8.0. The eosio.bios and eosio.system contracts in particular also require that the PREACTIVATE_FEATURE consensus protocol upgrade has been activated on the EOSIO blockchain before they can be deployed.
Thanks!
Special thanks to the community contributors that submitted patches for this release:
Important: All material is 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 material, you accept and agree to the terms of the notice.