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

EOSIO v2.0.0-rc2 Release Notes

Pre-release
Pre-release
Compare
Choose a tag to compare
@blockone-devops blockone-devops released this 08 Nov 00:28
· 6620 commits to master since this release
v2.0.0-rc2
9bd1026
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 is a RELEASE CANDIDATE for version 2.0.0. The latest STABLE release is v1.8.5.

This release includes security and miscellaneous fixes.

Security bug fixes

Consolidated Security Fixes for 2.0.0-rc2 (#8195)

  • 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 of EOSIO should consider upgrading their nodes to v2.0.0-rc2 as soon as possible.

Stability bug fixes

  • (#8084) Net plugin remove read delays - 2.0
  • (#8099) net_plugin remove sync w/peer check - 2.0
  • (#8120) Net plugin sync fix - 2.0

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

Node operators should consider upgrading v2.0.0-rc1 nodes to v2.0.0-rc2 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

  • (#8042) [2.0.x] dockerhub | eosio/producer -> eosio/ci
  • (#8050) Add greylist limit - v2.0.x
  • (#8060) #8054: fix commas in ship abi
  • (#8072) nodeos & keosd version reporting - 2.0
  • (#8071) Update cleos to support new producer schedule - 2.0
  • (#8070) don't rebuild llvm unnecessarily during pinned builds - 2.0
  • (#8074) [2.0.x] Upgrade mac anka template to 10.14.6
  • (#8076) Handle cases where version_* not specified in CMakeLists.txt - 2.0
  • (#8088) [2.0.x] Linux build fleet update
  • (#8091) report block extensions_type contents in RPC and eosio-blocklog tool - 2.0
  • (#8105) Modify --print-default-config to exit with success - 2.0
  • (#8113) [2.0.x] WASM Spec Test Step in CI
  • (#8114) [2.0.x] Mac OSX steps need a min of 1 hour
  • (#8127) [2.0.x] Move the ensure step into the build step, eliminating the need for templaters
  • (#8144) fix pinned builds on fresh macOS install - 2.0
  • (#8149) [2.0.x] CI platform directories
  • (#8155) Post State history callback as medium priority - 2.0
  • (#8173) ensure GMP is always dynamically linked - 2.0
  • (#8175) [2.0.x] Unpinned and WASM test fixes
  • (#8168) add harden flags to cicd & pinned builds - 2.0
  • (#8180) [2.0.x] 10 second sleep to address heavy usage wait-network bug in Anka
  • (#8192) Reduce logging - 2.0

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.

Assets 6
Loading