EOSIO v2.0.0-rc3 Release Notes

This is a RELEASE CANDIDATE for version 2.0.0. The latest STABLE release is v1.8.7.

This release includes security, stability, and miscellaneous fixes.

Security bug fixes

Consolidated Security Fixes for 2.0.0-rc3 (#8344)

• EOS VM Fixes

Note: These security fixes are relevant to all v2.0.x nodes on EOSIO blockchain networks. In particular, block production nodes that are currently running v2.0.0-rc1 or v2.0.0-rc2 of EOSIO should consider upgrading their nodes to v2.0.0-rc3 as soon as possible.

Stability bug fixes

• (#8229) Net plugin sync
• (#8285) Net plugin handshake
• (#8298) net_plugin lib sync
• (#8303) net_plugin boost asio error handling
• (#8305) net_plugin thread protection peer logging variables
• (#8311) Fix race in fc::message_buffer and move message_buffer_tests to fc.
• (#8307) reset the new handler

Upgrading from previous versions of EOSIO

EOSIO v2.0.x has made changes to the state database that prevent it from working with existing state databases in v1.8.x and earlier. So upgrading from earlier versions of EOSIO requires importing the state from a portable snapshot.

Furthermore, the changes to the state database necessitate a version bump in the portable snapshots generated by EOSIO v2.0.x from v2 to v3. However, unlike the upgrade of portable snapshot versions in EOSIO v1.8.x from v1 to v2, EOSIO v2.0.x is able to import v2 portable snapshots. This means that it is not necessary to replay the blockchain from genesis to upgrade from EOSIO v1.8.x to v2.0.x. (One exception is if the operator of the node is using the deprecated history_plugin and wishes to preserve that history.)

Finally, EOSIO v2.0.x has also upgraded the version of the irreversible blocks log to v3. However, older versions of the blocks log are still supported, so there is no need to do anything special to handle existing blocks log files.

Upgrading from v1.8.x

If the node uses the deprecated history_plugin (and the operator of the node wishes to preserve this history), the only option to upgrade is to replay the blockchain from genesis.

Users of the state_history_plugin (SHiP) do not need to replay from genesis because the state history logs are portable and contain versioned data structures within. However, upgrading a node that uses state history without a full replay means that the state history log will contain a mix of versions for any upgrade types. For example, the changes in v2.0.x modify the global_property_object in the database state and so the state history log could contain a global_property_object_v0 type (for the part of the history before the local node upgrade) and a global_property_object_v1 type (for the part of the history after the local node upgrade). This should not cause problems for any history fillers that have been updated to support both versions of the type. However, operators should be aware that this can lead to the log file contents being slightly different across different nodes even if they all start and stop at the same blocks and have not enabled trace-history-debug-mode. (Replaying a v2.0.x node with state_history_plugin enabled from genesis would guarantee that the state history logs do not contain the global_property_object_v0 type.)

The following instructions should be followed to upgrade nodeos from v1.8.x to v2.0.x without a full replay (after making appropriate backup copies):

1. Obtain a compatible portable snapshot of the state. A v2 or v3 portable snapshot can be downloaded from a trusted source. Alternatively, one can use an existing v1.8.x node to generate a v2 portable snapshot by launching nodeos with --read-mode=irreversible --plugin=eosio::producer_api_plugin command-line options and then using the /v1/producer/create_snapshot RPC endpoint to generate a portable snapshot (e.g. run the command curl -X POST http:/127.0.0.1:8888/v1/producer/create_snapshot -d '{}' | jq).
2. Shut down nodeos and delete the blocks/reversible and state sub-directories within the data directory.
3. Launch nodeos v2.0.x from the generated snapshot using the --snapshot command line option and give it time to import the snapshot while starting up (this could take several minutes). (Subsequent launches of nodeos should not use the --snapshot option.)

Upgrading from v2.0.0-rc1 or v2.0.0-rc2

Node operators should consider upgrading v2.0.0-rc1 and v2.0.0-rc2 nodes to v2.0.0-rc3 as soon as possible. They can follow normal upgrade procedures for the upgrade. There should be no need to do a replay or import from a snapshot.

Other changes

• (#8207) Fixed under min available test to not count failed attempts as actual sends
• (#8233) return more from producer_plugin's get_runtime_options()
• (#8240) chainbase sync to pick up DB shrink fix while in heap mode
• (#8252) debug level logging for launcher service
• (#8247) explictly use openssl 1.1 via brew on macos
• (#8273) Update CentOS version for CI.
• (#8279) Travis updates.
• (#8315) Extend shutdown allowed time in under min available resources test
• (#8318) net_plugin speed up shutdown
• (#8322) Retries and Contract Builders for Tags
• (#8337) increase tester state size - 2.0
• (#8343) [2.0.x] Modification to trigger LRTs and Multiver on any protected branch that is not a scheduled run

Deprecation notice reminder

Please refer to the Consolidated EOSIO Deprecations List for the currently active set of deprecation notices.

Disclaimer: All repositories and other materials are 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 repositories and other materials, you accept and agree to the terms of the notice.