Today we are pleased to announce the release of EOSIO V1.4.3 and EOSIO.CDT V1.4.0.

We are continually collecting feedback from community members who are building applications on EOSIO and are constantly seeking to improve the developer experience on the platform.

In addition to release notes and documentation, the Block.one Developer Relations team — in coordination with the C++ Development and Public Communications teams — will provide easy-to-digest summaries of the features and benefits of each release and their implications on our goals for the platform.

Highlights of EOSIO V1.4.3:

EOSIO V1.4.3 is a scheduled minor release containing various improvements and bug fixes for EOSIO V1.4.

Failed deferred transactions were in history plugin results ( #6220 )

- Please note, the history_plugin was DEPRECATED in version 1.2.0 and is receiving this fix as part of the support for that lifecycle

- The history_plugin sometimes included failed deferred transactions in its search results. Since it doesn’t store receipt status, there wasn’t a reliable way for users of the history API to know which actions were executed. See #6214 for detailed discussion.

- Nodes which have to use the history_plugin and are concerned that this class of transaction may cause misleading results are encouraged to regenerate that plugins database using — replay-blockchain

- This does not affect the state of the chain. These failed deferred transactions were merely being misreported through this plugin. Their side-effects were correctly removed from any intermediate state of the blockchain

Please note, the history_plugin was DEPRECATED in version 1.2.0 and is receiving this fix as part of the support for that lifecycle - The history_plugin sometimes included failed deferred transactions in its search results. Since it doesn’t store receipt status, there wasn’t a reliable way for users of the history API to know which actions were executed. See #6214 for detailed discussion. - Nodes which have to use the history_plugin and are concerned that this class of transaction may cause misleading results are encouraged to regenerate that plugins database using — replay-blockchain - This does not affect the state of the chain. These failed deferred transactions were merely being misreported through this plugin. Their side-effects were correctly removed from any intermediate state of the blockchain Trusted producer should be configured via cfg and cli ( #6219 )

Print config.ini & data-dir nodeos is using at launch ( #6222 )

Restore eosio root ilog (#6253)

As mentioned above, if you are concerned with misrepresentation of deferred transactions in the history_plugin, please reconstruct that plugin’s state using — replay-blockchain as referenced in https://developers.eos.io/eosio-nodeos/docs/troubleshooting.

Highlights in EOSIO.CDT V1.4.0:

Ricardian contracts for ABI generation (#229)

Currently, the generation of Ricardian contracts has been a manual process with no automation in the EOSIO.CDT toolset. With the release of EOSIO.CDT 1.4.0 and the evolution of our Ricardian contract standard we are providing you with a simplified tool to automatically extract information needed for the generation of Ricardian contracts and clauses for a given smart contract. This is an evolving standard and we welcome feedback on this functionality.

Action wrapper for inline actions (#229)

The original way of working with inline actions was through a macro, which was not optimal in terms of the developer experience. In EOSIO.CDT 1.4.0 you can use a simplified syntax for inline actions similar to regular function calls. In the future, it will allow for an easy cross smart contract interactions by allowing you to expose the action wrappers in the header files. These action wrappers can be referenced and called by other smart contract developers in an easy way.

New types (#229, #236)

EOSIO.CDT V1.4.0 introduces binary extensions type. As a smart contract developer, sometimes you may need to add new parameters to your smart contract actions or enhance a table structure, but you may want to maintain backward compatibility with applications that already interact with your smart contract and are not updated yet.

Prior to EOSIO.CDT V1.4.0 you could add new parameters and re-upload your smart contract to the chain. However, it would break applications that do not follow an updated parameters set.

Binary extensions allow for an evolving architecture of the actions and table structures that need an architectural upgrade over time. We have added ABI support for the binary extensions using — abigen that will be picked up automatically.

eosio::fixed_bytes<T> and type aliases eosio::digest160/256/512 have also been added. These serve as functional replacements for eosio::fixed_key<T> (which has been marked deprecated) and as C++ alternatives to capi_checksum160/256/512.

Additional Docker file for EOSIO.CDT (#206)

We’ve added support for Docker file for EOSIO.CDT container.

eosio-abidiff (#229)

We are introducing a new tool that provides you with functionality to track differences in the generated ABI files. The tool will provide you with a report of structural differences between different versions of the ABI files.

Full list of EOSIO.CDT 1.4.0 Release issues:

Ricardian import support (#229)

Binary extensions (#229)

Variant types (#229)

Action/variant action wrapper (#229)

ABI generation for map, set, tuple, std::pair, general template types (#208)

Additional Docker file for EOSIO.CDT (#206)

Various bugfixes and performance improvements (#244, #200, #164, #236, #233)

Stay Connected

If you are interested in providing feedback and working more closely with our team to improve EOSIO for the community, you can send our developer relations team an email at developers@block.one. You can also hear about 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 most scalable blockchain development.

Read disclaimer