EOSIO v1.8.0 Release Notes

This release has a critical bug. Please use version 1.8.1.

This release includes an EOSIO consensus upgrade which necessitates a replay from genesis. Please see the "Consensus Protocol Upgrades" section for details and a link to a guide with important upgrade instructions.

A blog post providing more information about the consensus protocol upgrades can be found here.

Deprecation and Removal Notices

Platforms dropped

Support for the following operating systems has been dropped:

• Mint 18
• Fedora 27
• Amazon Linux 1
• macOS versions earlier than 10.14 such as High Sierra

bnet plugin removed

The bnet_plugin was deprecated in the v1.7.1 release and has now been removed with this release. The net_plugin is the only supported plugin enabling nodeos instances to communicate with one another on the peer-to-peer network.

Users of the irreversible mode feature of the bnet_plugin should switch to the new irreversible read-mode support added to the core of nodeos.

For more information about the new irreversible read-mode, please see below.

Docker files removed

Several months ago we deprecated support for EOSIO Docker images. With this release, we have now removed the Docker folder and its associated files.

Mongo DB plugin deprecated

The Mongo DB plugin has been deprecated and will be removed from the EOSIO source in a future release. Users are recommended to switch to non-deprecated history solutions such as the ones built off of the state_history_plugin.

Changes

Consensus Protocol Upgrades

This release adds the foundations needed to support consensus protocol upgrades (#6831, #7167). PR #6831 also introduced the consensus protocol upgrade feature (or just protocol feature for short) with the codename PREACTIVATE_FEATURE which, after activation, enables operators of an EOSIO blockchain to use an on-chain process to activate further protocol features. For example, after activation of PREACTIVATE_FEATURE, block producers of an EOSIO chain could deploy the new system contract from eosio.contracts v1.7.0-rc1 and then use a standard eosio.msig proposal to activate any of the other protocol features supported by this release.

This release introduces an initial set of protocol features that can be activated individually:

1. ONLY_LINK_TO_EXISTING_PERMISSION (#6831)
2. REPLACE_DEFERRED (#6997, #7185)
3. NO_DUPLICATE_DEFERRED_ID (#7072, #7173, activation depends on REPLACE_DEFERRED)
4. FIX_LINKAUTH_RESTRICTION (#7025)
5. DISALLOW_EMPTY_PRODUCER_SCHEDULE (#7026)
6. RESTRICT_ACTION_TO_SELF (#7088)
7. ONLY_BILL_FIRST_AUTHORIZER (#7089)
8. FORWARD_SETCODE (#7109)
9. GET_SENDER (#7111)
10. RAM_RESTRICTIONS (#7131)

Support for consensus protocol upgrades required extensive changes to nodeos which force a replay from genesis. Please see this guide for how to upgrade from v1.7.x and earlier to v1.8.x as well as important notes to be aware of regarding the transition. In particular, the guide includes special instructions that block producers of EOSIO networks should be aware of before upgrading their nodes to carry out a smooth transition for the network when activating the first protocol feature.

Irreversible read mode

A new read-mode has been enabled in nodeos: irreversible (#6624, #6842, #6843). When nodeos is configured to be in irreversible read mode, it will still track the most up-to-date blocks in the fork database, but the state will lag behind the current best head block (referred to as the fork DB head in the output of cleos get info) to always reflect the state of the last irreversible block. The irreversible mode behaves in a similar manner to read-only mode in that the node will not accept transactions pushed to it through the chain API.

Support has been added to easily switch back and forth between irreversible mode and the other modes. When switching from speculative mode to irreversible mode, the state will be rolled back to that of the last irreversible block and the reversible blocks database will be deleted. When switching from irreversible mode to speculative mode, nodeos will attempt to recover the reversible blocks from the fork database and re-apply those blocks to get the state back to the one corresponding to the best available head block.

The create_snapshot RPC of the producer API has been modified to only return the path to the finalized snapshot when the block they represent becomes irreversible (#7119). These changes protect the user from generating an invalid snapshot. When a request for a snapshot is received through the API, nodeos will now write the snapshot data to a temporary file, create an internal tracking record, and then the RPC will just wait until the snapshot is finalized. As this block becomes irreversible OR the real last irreversible block passes it on a competing fork, nodeos will either rename the temporary file to the expected snapshot name and return the path to the caller OR delete the temporary file and return an error indicating that the snapshot was unusable. When in irreversible read mode, the create_snapshot RPC will immediately return the finalized path to the snapshot after the snapshot is written to disk (#7172).

Changes to transaction traces

The structure of transaction traces has significantly changed (#7044, #7108). All the action traces are now stored within the transaction trace in a flat format. The legacy tree structure can be recovered by using the new action_ordinal and closest_unnotified_ancestor_action_ordinal fields added to action traces. However, clients are encouraged to instead consider an alternative tree representation of the action traces: the creation tree. The creation tree solves an issue of ambiguities that may exist in the legacy tree structure (see issue #6897 for details). Clients can construct the creation tree from the flat set of action traces by using the new action_ordinal and creator_action_ordinal fields added to action traces. Additionally, the transaction trace may optionally contain an account_ram_delta field which can enable block explorers to properly track the RAM usage changes due to the scheduling and retirement of deferred transactions.

The existing push_transaction and push_transactions RPCs of the chain API have been modified to return a transaction trace JSON that is designed to remain backwards compatible with existing consumers of those APIs. The transaction trace will still include the newly added fields; however, it will be re-assembled into the legacy tree structure that the client may expect.

Clients are encouraged to switch over to the new send_transaction RPC of the chain API which does the same thing as push_transaction except that it returns the new flat structure rather than spending the time to convert the output back into the legacy format.

The changes to the transaction trace structure will likely affect any nodeos plugin that depends on them. In addition, PR #7150 has modified the interface of the applied_transaction signal, which means existing nodeos plugins that use this signal need to be updated to continue to compile and function correctly. The state_history_plugin, as well as the deprecated history_plugin and mongo_db_plugin, have already been updated to support these changes.

Updates to state history plugin

The state history plugin was introduced as an alpha product in EOSIO v1.5.0. As part of being alpha, the release notes mentioned how it was likely for the state history plugin to substantially change prior to its final release. This release makes breaking changes both to the structure of the files that the state history plugin stores on disk as well as the WebSocket API the clients use to retrieve traces and table deltas from the state history plugin (#7113, #7139, #7150, #7163, #7383).

The state history plugin logged all values in traces including subjective ones that varied from node to node, e.g. the elapsed time to locally execute an action. The default behavior of the state history plugin is now to modify these subjective values to get consistent results across all nodes (#7298). The new default behavior enables state history nodes on the same version to generate identical trace and table delta logs assuming they both end at the same head block. The old behavior (which can enable access to action console logs and error messages) can be recovered by setting the trace-history-debug-mode to true which puts the state history plugin into a debug mode.

With this release, the state history plugin has been promoted to a stable product that is ready for use in production environments. Future changes to the APIs and data structures will leverage the versioning system baked into the state history plugin to avoid the need to replay from genesis in order to maintain the existing history, assuming consumers can tolerate not having access to any newly tracked data for the part of the history preceding the nodeos upgrade. If consumers cannot tolerate discrepancies in the availability of data throughout the history of the blockchain, then the node operator would still need to replay from genesis for each substantial upgrade of the state history plugin.

Build script changes (#7107, #7458, #7517, #7523, #7531, #7549)

The build scripts now support an optional parameter (-P) which will try to pin the versions of the compiler, C++ standard library, Boost library, and a few other dependent libraries that could have an impact on the ability for nodeos to access the shared memory database created by prior versions. By pinning these critical dependencies, which requires building them from source, a user can ensure that a nodeos binary rebuilt after an operating system upgrade can still access existing shared memory databases. When switching from an unpinned build to a pinned build or vice versa, it is best to delete the build subdirectory in the EOSIO source root directory.

Both EOSIO and its dependencies will be built and installed by default in a sub-directory within the user's $HOME directory that includes the major and minor version numbers of the EOSIO release. For example, the build script in this release will default to installing everything into $HOME/eosio/1.8/. The directory in which the eosio directory is contained can be changed from the default of $HOME to any path specified by the -i option of the build script. (Note that the -p option in previous versions of the build script, which changed the build script prefix directory, is no longer supported.)

The build scripts will detect if prior built dependencies exist and try to use them rather than rebuild, but this can lead to compiling/linking problems if the dependencies were built with a different version of the compiler or standard library. If this problem is encountered, one solution is to clean up all the old dependencies that were built. Users are unlikely to run into this problem if they always use the -P option to build EOSIO. If users encounter build issues, they are recommended to try deleting the contents of $HOME/eosio/ and running the build script again with the -P option. Taking those steps will likely resolve the the build issues. (The build scripts in previous release candidates of 1.8.0 included a -f option to force the build of all the relevant dependencies, but that should no longer be necessary with the latest version of the build script. The -f is still accepted by the current build script, but it now does nothing. It has been deprecated and will be removed in a future release of EOSIO.)

The build scripts will no longer build the deprecated Mongo DB plugin by default. The new -m parameter can be passed to the build script to build the Mongo DB plugin and install any of its needed dependencies.

With this release, the build script will automatically use version 1.70 of Boost when building EOSIO. EOSIO does still support using Boost version 1.67, but building with versions of Boost earlier than 1.70 will require using CMake directly rather than using the build script. Also, the minimum version of Boost supported in EOSIO is expected to increase to 1.70 in the future, so users are encouraged to build EOSIO with Boost version 1.70. An easy way to do this is to use the build script and pass in the -P option. Doing so will make it less likely to require portable snapshots in order to upgrade an existing chain state database to work with a future version of EOSIO.

Note: The build script depends on CMake 3.8 or later. Please ensure you have an appropriate version of CMake installed on your system prior to running the build script.

Upgrading from previous versions of EOSIO

Upgrading from v1.7.x and earlier

Upgrading from v1.7.x or earlier to v1.8.0 requires a replay from genesis (see the upgrade guide). Alternatively, a user can quickly get a node up to speed with a version 2 portable snapshot generated by some other trusted entity that has gone through the upgrade process. This alternative process is not applicable for nodes that want to track all of the blockchain history using the deprecated history plugin. However, nodes tracking history using the state history plugin could also grab the state history log files (which are portable across machines) along with the portable snapshot retrieved from the trusted entity.

Upgrading from v1.8.0-rc1

Upgrading from v1.8.0-rc1 to v1.8.0 for a nodeos configured to run with plugins that handle history requires a replay from genesis similar to the upgrade from v1.7.x to v1.8.0 (see the upgrade guide).

If nodeos is not configured with any history-related plugins, it is possible to upgrade from v1.8.0-rc1 to v1.8.0 without doing a replay from genesis. The snapshots generated and accepted by both versions are identical. So the operator could:

1. Launch nodeos v1.8.0-rc1 in irreversible mode and with the producer_api_plugin enabled by passing the --read-mode=irreversible --plugin=eosio::producer_api_plugin command-line options. (Note that producers cannot be configured when launching nodeos in irreversible mode.)
2. Create a snapshot of the last irreversible block by calling the create_snapshot RPC (for example by using the command curl -X POST http:/127.0.0.1:8888/v1/producer/create_snapshot -d '{}' | jq). Record the path to the generated snapshot file in snapshot_name field of the returned JSON object.
3. Shut down nodeos and delete the blocks/reversible and state sub-directories within the data directory.
4. Launch nodeos v1.8.0 from the generated snapshot using --snapshot command line option.

Upgrading from v1.8.0-rc2

Upgrading from v1.8.0-rc2 should typically be as easy as most other upgrades of EOSIO versions. No special action is required. The new version of nodeos should be able to use the existing state and history files on disk produced by nodeos v1.8.0-rc2.

However, it is possible that some users may run into a problem where v1.8.0 nodeos is not able to start up using the old state files because of a failure of an environment check. This is likely to apply to users who did not do a pinned build of v1.8.0-rc2, but may also apply to pinned v1.8.0-rc2 builds due to a bug in compiler pinning that has been fixed in 1.8.0. If users come across this environment check failure, they can fall back to the four step upgrade process described in the section "Upgrading from v1.8.0-rc1" assuming they are not relying on the deprecated history plugin. Users who run into this environment check failure and do rely on the deprecated history plugin will be forced to fallback to the replay from genesis upgrade process linked to in the "Upgrading from v1.7.x and earlier" section.

Other changes

• (#6815) Avoid duplicate connection error
• (#6818) Unused comment removal
• (#6814) appbase: Block (queue) exit signals during shutdown
• (#6825) Docker: Add missed build deps and packages deps for libusb/libcurl/pk…
• (#6819) Support --genesis-json argument with --snapshot argument
• (#6840) quick pipeline fixes
• (#6836) Remove *.cmake from .gitignore
• (#6841) Support for amazonlinux2
• (#6833) GCC defect fixes.
• (#6846) Small console optimization
• (#6852) Fix testee tester brew
• (#6855) enable expiring data in mongodb for mongodb_plugin
• (#6857) appbase: rework blocking (queuing) exit signals during shutdown
• (#6854) database memory locking & hugepage support
• (#6853) Stable application execution priority queue
• (#6869) appbase sync
• (#6872) Signature cpu usage - dev
• (#6883) Consolidated Security Fixes for 1.7.0-rc2
• (#6888) Two small compiler warning fixes
• (#6825) Docker: Add missed build deps and packages deps for libusb/libcurl/pk…
• (#6899) Add example logging.json
• (#6902) Add back integration_test contract; fixes nodeos_under_min_avail_ram_lr_test
• (#6904) Fix bug in get_block of chain_plugin that would lead to unnecessary failures for some block numbers
• (#6829) cleos get transaction_id enhancements
• (#6893) Move json::to_string response processing to http thread pool
• (#6911) Fix db_modes_test to not use http
• (#6914) Fix empty strings in db_modes_test.sh again
• (#6919) Pipeline upgrades for 2-1
• (#6920) pipeline changes
• (#6925) Added EOS Rio's Hyperion History API to COMMUNITY.md
• (#6936) Add Chronicle to COMMUNITY.md and update disclaimer
• (#6934) Remove unused variable
• (#6942) support heterogeneous version tests
• (#6962) Update appbase to shutdown fix
• (#6968) remove eosio-wat2wasm and other WAVM tools from being built
• (#6963) Created test scripts with xUnit, auto-scaling parallelism, and empty test detection; and added them to pipeline
• (#6975) Fix txn_test_gen_plugin crash on multiple create_test_accounts calls - develop
• (#6976) Add strand to protect internals of asio - develop
• (#6978) Issue 6940 Build script uninstallation instructions added
• (#6985) Remove setting CMAKE_OSX_SYSROOT
• (#6990) Optimize mongodb plugin
• (#6993) readme, license, contrib
• (#6989) Add Integration Catchup Test
• (#7017) [XC 10.2] Remove boost::thread usage from mongo plugin
• (#7019) [XC 10.2] disable asio's experimental string_view usage on macos
• (#7022) [XC 10.2] fc sync - Remove fc::shared_ptr & refactor logging code to not use it
• (#7024) [XC 10.2] chainbase sync - Remove boost thread include and unused typedef
• (#7035) Fix Catchup Test
• (#7036) [XC 10.2] Remove final boost thread references in cmake & change macos boost build
• (#6915) Turning off bnet long running tests
• (#7041) Fix for close() called while async_read in-flight - develop
• (#7043) Use shared_future - develop
• (#7056) Add git submodule regression check
• (#7059) Add back in Docker Hub deprecation that was accidentally removed - develop
• (#6992) Name application threads
• (#7068) Make the submodule regression check more robust
• (#7063) Removed Deprecated Operating Systems from Buildkite Pipelines
• (#7076) Fix for Catchup long running test exhausting memory
• (#7079) Increase timeout for nodeos_startup_catchup_lr_test
• (#7078) Removed Remaining bnet Tests
• (#7083) Prevent core dump by catching exception
• (#7075) Remove unused skip_flag in base_tester::produce_block
• (#7064) fix rpm command for uninstalling eosio
• (#7086) Fix crash #7084 - develop
• (#6878) update the bios boot tutorial python script to create the eosio.rex account as well update the bios boot tutorial python script to create the eosio.rex account as well
• (#7115) #6980: fix memory leak when --trace-history not used
• (#7125) Revert EXCLUDE_FROM_ALL
• (#7126) add libicu as dependency for .deb packages
• (#7047) Remove unwinding frames from WAVM code generation
• (#7128) sync fc: remove last remnants of boost mutex usage
• (#7135) remove bnet_plugin
• (#7137) Fix Catchup Test Validation
• (#7135) remove bnet_plugin
• (#7127) bump libyubihsm library to 2.0.1
• (#7133) Limit ubuntu versions eosio_build.sh runs on to 16.04 & 18.04
• (#7132) configurable curve for https ECDH to improve interoperability
• (#7141) Added lib64 to CMAKE_MODULE_PATH
• (#7118) Make executable names configurable
• (#7095) Build script: support new options
• (#7160) remove "eosio root" print on nodeos startup
• (#7164) Fix EosioTester to only generate one CTest "target"
• (#7149) Buildkite Docker Plugin propagate-environment AND ctest Error Handling
• (#7168) Reduce logging of complete object when unable to serialize
• (#6588) Refactor block_header_state
• (#6856) fix bug in apply_block that constructed and committed blocks with missing signatures in the protocol-feature-foundations branch
• (#6864) Add unit test to ensure that broadcasted block by producer node and receiving node is identical
• (#7134) store all wasm code in a separate index
• (#7156) fix RAM billing consensus bug in eosio::setcode native handler
• (#7123) wabt optimization
• (#7143) fix tests in forced-replay branch; use updated bios contract
• (#7179) evict wasm_cache entries once the last block they are used in becomes irreversible
• (#7188) Fix bugs in block_log
• (#7171) reduction of wavm memory usage
• (#7176) Destroy wavm module instances when deleting the wavm_instantiated_module
• (#7177) Avoid possibly lengthy destruction of wasm instances on shutdown
• (#7194) update fc submodule
• (#7184) Keep block log open to minimize open/close of file
• (#7211) commit db during replays when replay optimizations are disabled
• (#7215) Proper replay shutdown from database_guard_exception
• (#7204) Remove dockerfiles
• (#7208) Gives a timeout for bios node check pulse and also minor cleanup on Cluster.py
• (#7206) Remove stale license template
• (#7197) remove unsupported platforms from README and build scripts
• (#7205) remove old testnet.md file that isn't relevant
• (#7104) Remove dead code
• (#7221) try to fix relaunch error in nodeos_irreversible_mode_lr_test
• (#7224) Remove -Werror from wabt
• (#7218) reenable building of mongo c/cxx drivers
• (#7223) Update to fc with gcc fix
• (#7228) build clang8 only when $BUILD_CLANG8 is "true"
• (#7227) link to icu or sasl2 when appropriate for mongo
• (#7229) link to snappy when appropriate for mongo
• (#7230) disable snappy support for mongo-c-driver
• (#7233) startup catchup test not killing node
• (#7246) Change default log level from debug to info. - v1.8.x
• (#7256) Move Test Metrics Code to Agent
• (#7242) Created Universal Pipeline Configuration File
• (#7265) use protocol-features-sync-nodes branch for LRT pipeline - v1.8.x
• (#7266) chainbase uniqueness violation fixes
• (#7280) build unittests in c++17, not c++14 - 1.8
• (#7283) Fix cleos REX help - v1.8.x
• (#7274) restrict range of error codes that contracts are allowed to emit
• (#7281) Update EosioTester.cmake.in
• (#7296) Modify the pipeline control file for triggered builds
• (#7297) added sudo -E to installs for Ben on automation + zlib if fix
• (#7298) add debug_mode to state history plugin
• (#7311) when unable to find mongo driver stop cmake - 1.8
• (#7326) fix block serialization order in fork_database::close - v1.8.x
• (#7334) Use debug level logging for --verbose - 1.8.x
• (#7335) Anka for 1.8.x + new linux vm image labels
• (#7324) Look in both lib and lib64 for CMake modules when building EOSIO Tester
• (#7347) Anka 1.8.x fixes
• (#7351) correct signed mismatch warning in chain controller - 1.8
• (#7344) correct signed mismatch warning in http_plugin - 1.8
• (#7345) (softfloat sync) clean up strict-aliasing rules warnings - 1.8
• (#7357) Boost 1.70.0 changes - v1.8.x
• (#7358) Fixes for Boost 1.70 to compile with our current CMake (release 1.8.x)
• (#7360) update to use boost 1.70 (release 1.8.x)
• (#7353) Add Version Check for Package Builder
• (#7368) Fix exception # - v1.8.x
• (#7373) Adds configuration for replay test pipeline
• (#7372) Add boost/asio/io_context.hpp header to transaction_metadata.hpp for branch release/1.8.x
• (#7384) fix ship segfault in get_block, #7136
• (#7409) Centralize EOSIO Pipeline
• (#7428) [Anka] 1.8.x added base images pipeline.
• (#7437) Fix #7436 SIGSEGV
• (#7454) fix assignment during timer creation - 1.8
• (#7469) Pipeline Configuration File Update
• (#7481) Removed default base-image pipeline.
• (#7493) Enabled helpers for unpinned builds.
• (#7501) [1.8.x] Versioned images (prep for hashing)
• (#7506) use create_directories in initialize_protocol_features - v1.8.x
• (#7485) [1.8.x] Ensure we're in repo root
• (#7520) [1.8.x] Removed lrt from pipeline.jsonc
• (#7528) Readlink bats fix r1.8
• (#7550) Sighup logging - v1.8.x

Thanks!

Special thanks to the community contributors that submitted patches for this release:

• @UMU618
• @conr2d
• @xinyijun
• @learnforpractice
• @raymondnuaa

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.