Skip to content
This repository has been archived by the owner on Aug 30, 2022. It is now read-only.

EOSIO Contracts v1.4.0 Release Notes
Compare
Choose a tag to compare
@arhag arhag released this 11 Oct 00:37
· 787 commits to master since this release
v1.4.0
1b85741
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.

This release unintentionally introduced a backwards incompatible change to the eosio.system ABI. Please use v1.4.1 instead to avoid this specific backwards incompatibility.

All contracts

All of the contracts have been updated to be compatible with eosio.cdt v1.3.x. The 1.3 version of eosio.cdt introduced breaking changes to eosiolib which required the source code of all contracts to be modified so that they could continue to build.

The latest release of eosio.cdt also introduces new features like updated attributes to help with ABI generation and the ignore template to enable optimization of action argument deserialization without sacrificing automatic ABI generation. All contracts have been updated to use the new attributes for ABI generation, and furthermore the eosio.system, eosio.msig, and eosio.wrap (formerly known as eosio.sudo) contracts in particular have also been updated to use the ignore feature.

While the code for all of the contracts in this repository have been modified due to the reasons stated above, the only contracts that have had functional changes since the prior release are eosio.system and eosio.token.

Automatic ABI generation

The contracts have been updated to leverage the automatic ABI generation functionality of the latest eosio.cdt release. ABI files are no longer manually created and committed to the repository. Instead the build system will generate the ABI files and place them in the same directory as the generated WASM file.

Relaxed dependency checks

The dependency checks of prior releases of eosio.contracts were very strict. With each new minor release of eosio, users trying to build an existing eosio.contracts release with the new version of the eosio dependency found that the build would fail with a dependency version failure. The problem would eventually be fixed with the new minor release of eosio.contracts only to break again when one of its dependencies had another minor release.

With v1.4.0 of eosio.contracts, this frustrating problem should be resolved since the dependency version checker is now far more permissive. It will refuse to build with dependency versions that are known to be incompatible at the time of the release, however, now the build will continue (although with a warning) if the dependency has a higher minor (but not major) version than what was known to be good at the time of the eosio.contracts release. For details on the version checking logic, see #89.

Wrap contract (formerly know as the sudo contract)

The eosio.sudo contract has been renamed to eosio.wrap. There is no functionality change to the contract.

Token contract

The eosio.token::open action will now verify that the symbol provided to the action actually exists before attempting to open a new zero-balance table row for the symbol (#102).

System contract

Core symbol no longer needed during build

The concept of a core symbol has been entirely removed with the v1.3.0 release of eosio.cdt. There is no longer a core_symbol.hpp header file and the eosio::asset struct requires a symbol to always be explicitly provided to the non-default constructor.

In prior versions of eosio.contracts, the core symbol that was needed for the system contract was pulled in from eosio.cdt. Now, with the changes in eosio.cdt, the system contract alone is responsible determining what the core (or system) token symbol should be.

However, this change has also not required a core symbol to be provided as a build parameter when compiling the system contract. Instead the system contract has been updated to determine the core (or system) token dynamically rather than hard-coding it into the contract.

When the system contract is deployed to a blockchain for the very first time, a call to the eosio::init action should immediately follow to set up the initial parameters and tables of the system contract (the contract will not be fully functional without the initialization). The core token symbol is provided as an argument to this eosio::init action.

Further updates to the system contract code do not require an eosio::init action; in fact it is disallowed to call eosio::init a second time.

If version 1.4.0 of the system contract is replacing an existing deployment of older versions of the eosio.system contract, then no eosio::init action is necessary. The necessary tables should already be setup to allow v1.4.0 of the eosio.system contract to dynamically retrieve the core token symbol.

Dependencies

This release depends on eosio.cdt v1.3.x and eosio v1.3.x. To compile the contracts in this release, first build and install eosio.cdt v1.3.0 and eosio v1.3.2.

Assets 2
Loading