We are continually collecting feedback on how the community is building applications on the platform and are consistently improving the developer experience on EOSIO. Going forward, we will be targeting the second Tuesday of each month for an update to the EOSIO software.
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.
Continue reading below to learn more about EOSIO V1.3.0.
Highlights in EOSIO V1.3.0:
Trusted Producer Light Validation (#5631)
In the EOSIO V1.2.0 release, we introduced Replay and Resync (#5130) to address the issue that as the blockchain grows, the time needed to set up a new node and replay the chain will also continue to rise. Building on that, in V1.3.0, we have included more performance enhancements called Trusted Producer Light Validation (#5631).
In conversations with the community, we have been discussing the concept of a “trusted producer.” This would allow for blocks from specific Producer(s) to be considered “trusted” and only need light-verification. For example, Producers would have the ability to trust their own blocks and designate them as “light” drastically reducing propagation delays across their own internal networks of API and P2P nodes for blocks they produce in order to increase the overall performance of the network.
With this, we needed to create a way to allow for trusted producers in nodeos (#5268). With modern producers running entire networks of nodes to provide resilience and high availability, the number of hops a block must traverse to leave the trusted network grew and we needed to optimize so that we could continue to deliver a performant, usable blockchain software for the community.
Overall, we expect to see a significant performance increase from this for Producers as they continue to optimize their own infrastructure to run the EOSIO blockchain. Note that light validation is intended to be used on the interior of a single block producer’s network of nodes, it is not intended to be used on P2P nodes connecting to other block producers since blocks traversing the P2P net between producers must continue to be fully validated in order to maintain integrity of the blockchain.
Meet wabt, the new WASM backend (#5416)
We have replaced the existing binaryen interpreter with wabt (pronounced “wabbit”), a suite of tools for WebAssembly that is considerably faster than the current default binaryen interpreter. This means that every microsecond spent processing transactions on an EOSIO-based blockchain can be more productive. Additionally, we expect that the replay time for existing chains can be cut in half. For more information on wabt you can review the project directly on github here.
The best part is, as this is all backend mechanics powering the EOSIO platform, no additional development complexity is needed to see these benefits. New developers will be able to more easily set up a node, lowering the barrier to entry to start using the EOSIO blockchain.
EOSIO Contract Development Toolkit (EOSIO.CDT)
A core part of writing applications for EOSIO is writing C++ smart contracts compiled to WASM. Previously, we recommended using the eosiocpp utility, which was included as a part of the EOSIO build. You may have seen that there is a deprecation notice posted to the issue here and is displayed to developers when using eosiocpp. Please note that eosiocpp will be gradually deprecated across future releases. It will not be removed immediately, but it is strongly recommended to begin transitioning.
That said, with the release of EOSIO V1.3.0, we are excited to announce a new toolkit we will start recommending for compiling smart contracts and generating ABI files — the EOSIO Contract Development Toolkit (EOSIO.CDT). EOSIO.CDT provides support for Gnu & C++ 11 style creating a more reliant way of declaring your smart contract structure and associated data structures.
This has been available on github in experimentation mode for some time, but has reached enough stability where it will start having its own release cycle independent of EOSIO core. At the moment, to start using EOSIO.CDT it must be compiled from the source found here, but stay tuned for coming releases where we plan to include the precompiled binaries.
Full List of 1.3.0 Release Issues:
- Add block info & ram delta to action_trace (#5339)
- Add UNIX socket HTTP server to keosd (#5425)
- Transaction trace logging for visibility of transactions on P2P (#5725)
- Fix typo in cleos help text (#5639)
- Doxygen fixes for copy of eosiolib (#5603)
- Unit test fixes (#5634)
- Fix wording for Inline Action Depth Reached (#5635)
- Support iteration over scopes & tables in cleos (#5486)
- Remove unused variable (#5582)
- Spelling and whitespace corrections in transaction.h (#5580)
- Inverted check for flag for no auto keosd (#5574)
- Fix Spurious Long Running Test Failures (#5558)
- Launcher tests (#5476)
- Print separators properly with cleos get account (#5506)
- cleos support for delayed transaction(#5492)
- Remove old exchange contract (#5477)
- New test to ensure require_recipient to generator is ignored (#5446)
- Chain api: get code hash (#5434)
- add cleos set contract/code/abi — clear (#5442)
- Correct cleos get table help text from ‘contract’ to ‘account’ (#5448)
- Stop creating anonymous volumes during image build (#5444)
- Docker Improvements (#5452)
- Build secp256k1 as a submodule (#5478)
- Updates to fc:
– A handful of fc changes to support unix sockets for HTTP RPC (EOSIO/fc#12)
– Optimize sha256 comparison (EOSIO/fc#16)
– Change various asserts in fc code to use FC_ASSERT (EOSIO/fc#19)
– Fix uninitialized data bug in fc cryptographic hash classes when constructing from a hex string (EOSIO/fc#21)
- Fixed framework casing for case sensitive MacOS builds (#5386)
- Improve error for malformed signature (#5305)
- use config::producers_account_name instead of N(eosio.prods) (#5277)
- Add new get_raw_abi RPC to chain API (#5375)
- Support for ABI version 1.1 in abi_serializer: added variants and binary extensions; major version number in ABI is now enforced (#5652, #5673)
- Fixed bugs in abi_serializer (#5680)
- When clearing state DB, erase contents of the state directory but not the directory itself (#5696)
- Add optional — pay-ram-to-open flag for the cleos transfer command to prepend an eosio.token::open action before the eosio.token::transfer action (#5581)
- get_account RPC in chain API now tries to determine the core symbol from the installed system contract rather than relying on the build configuration parameter (#5704)
- Improvements to cleos get account sub-command: robust against mismatch of core symbol between API node and cleos; now also prints account creation time in output (#5704)
- Proper matching of transaction ID prefix within get_transaction RPC of the history_plugin (#5723)
- avoid plugin through irreversible_block signal change block before apply_block (#5611)
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 email@example.com. 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.
All product and company names are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.
Important Note: 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.