EOSIO v1.8.5 Release Notes

This release contains stability and miscellaneous fixes.

Stability bug fixes

• (#7999) Net plugin trx progress - 1.8
• (#8083) Net plugin remove read delays - 1.8

Subjective CPU Leeway (#8027)

Since the initial 1.0 release, EOSIO has had a feature called subjective CPU leeway. This feature allows the CPU usage of a transaction to temporarily go beyond the limit imposed by the billed accounts' CPU quotas during execution in order to give the transaction a chance to increase the CPU quotas (and therefore the imposed limit) by the end of the transaction. The system enforces that the excess CPU usage beyond the initial quota-driven limit does not exceed the subjective CPU leeway configured on the local node as a mechanism to protect the local node. Nodes configured with too low of a subjective CPU leeway may not give a transaction enough time to demonstrate that it would have had enough resources to cover its costs by the end of the transaction, and in such a situation that transaction would be rejected by the node.

On EOSIO blockchains that deploy the reference system contracts, this feature can enable a user that has no tokens staked on their account to push a transaction that stakes sufficient tokens from their liquid token balance. The amount of tokens staked by the end of the transaction must be large enough to cover the aggregate CPU usage of the billed account(s) at that point in time.

However, because the measured CPU usage of a transaction is subjective, some EOSIO nodes along the path from the client to the block producer node may consider the temporary excess CPU usage of the transaction to be larger than their locally configured subjective CPU leeway and therefore drop the transaction. If enough relay nodes drop the transaction in this manner (or if its dropped by the single API node that initially receives the transaction), then the transaction will be unable to propagate through the peer-to-peer network and reach a block producer node to be included in a block.

While prior versions of EOSIO have allowed changing the default value (3 ms) of the subjective CPU leeway through the update_runtime_options RPC of the producer API, there was no convenient way to change this value through a configuration parameter prior to this release. This release introduces the subjective-cpu-leeway-us configuration parameter to chain_plugin which makes it easy for node operators to change the leeway using a config.ini entry or command-line options.

Furthermore, measurements of common transactions related to staking (e.g. the transactions discussed earlier that staked tokens to an account starting with zero tokens staked) showed that on some machines the measured CPU usage could often exceed the default subjective CPU leeway value. If enough nodes with similar performance characteristics were present in the peer-to-peer network (or were the API nodes), it could lead to these "staking from zero" transactions being unreliable. So this release also increases the default value of the subjective CPU leeway to 31 ms. In EOSIO networks where enough nodes have adopted this new higher value (e.g. by simply using EOSIO v1.8.5 or later with the default settings), these changes will likely improve the reliability of "staking from zero" and similar transactions.

Greylist Limit (#8051)

EOSIO 1.1.0 introduced grey listing as a feature. This feature enables a node to subjectively restrict the CPU and NET resource limits of some transactions to what they would be if there were elastic bandwidth benefit provided by the network (e.g. when the network resources are heavily utilized) even when there is low usage of network resources. This restriction in resources is selectively applied only to accounts that are on a locally configured grey list.

This release of EOSIO now adds another tool for subjectively restricting CPU and NET resources: the greylist limit. This limit applies grey listing restrictions to transactions in a manner that simulates what it would be like if the elastic bandwidth multiplier (which can vary from 1 to 1000) was capped by the greylist limit. This is a subjective mechanism just like the original grey listing mechanism; so, the restriction only applies to speculatively executing transactions and each node is able to define its own limit through the new greylist-limit configuration option in producer_plugin (it can also be changed during runtime using the update_runtime_options RPC of the producer API). However, unlike the original grey listing mechanism, the greylist limit applies to all accounts (not just the accounts explicitly specified in the grey list).

To learn more about one way the greylist limit can be used in EOSIO networks and the motivations behind developing this mechanism, please see this article.

Other Changes

• (#8020) [1.8.x] Change submodule script to see stderr for git commands
• (#8040) [1.8.x] dockerhub | eosio/producer -> eosio/ci
• (#8064) [1.8.x] Upgrade mac anka template to 10.14.6
• (#8087) [1.8.x] Linux build fleet update

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.

EOSIO v2.0.0-rc1 Release Notes

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

This release includes an EOSIO consensus upgrade. Please see the "Consensus Protocol Upgrades" section below for details. These protocol upgrades necessitate a change to the state database structure which requires a nodeos upgrade process that involves more steps than in the case of most minor release upgrades. For details on the upgrade process, see the "Upgrading from previous versions of EOSIO" section below.

Changes

EOS VM: New High Performance WASM Runtimes (#7974, #7975)

Three new WASM runtimes are available in this release: EOS VM Interpreter, EOS VM Just In Time Compiler (JIT), and EOS VM Optimized Compiler.

EOS VM Interpreter is a low latency interpreter and is included to enable future support for smart contract debuggers. EOS VM JIT is a low latency single pass compiler for x86_64 platforms. To use EOS VM Interpreter or EOS VM JIT, set the wasm-runtime to either eos-vm or eos-vm-jit respectively

EOS VM Optimized Compiler is a high performance WASM tier-up runtime available on the x86_64 Linux platform that works in conjunction with the configured baseline runtime (such as EOS VM JIT). When enabled via eos-vm-oc-enable, actions on a contract are initially dispatched to the baseline runtime while EOS VM Optimized Compiler does an optimized compilation in the background. Up to the configured eos-vm-oc-compile-threads compilations can be ongoing simultaneously. Once the background compilation is complete, actions on that contract will then be run with the optimized compiled code from then on. This optimized compile can take a handful of seconds but since it is performed in the background it does not cause delays. Optimized compilations are also saved to a new data file (code_cache.bin in the data directory) so when restarting nodeos there is no need to recompile previously compiled contracts.

None of the EOS VM runtimes require a replay nor activation of any consensus protocol upgrades. They can be switched between (including enabling and disabling EOS VM Optimized Compiler) at will.

Block producers should consider running all three of the EOS VM runtimes on test networks, and continue to use WABT for production networks.

Consensus Protocol Upgrades

EOSIO v2.0.x introduces two new consensus protocol upgrade features (or just protocol features for short):

1. WEBAUTHN_KEY: Adds support for WebAuthn keys and signatures (#7421)
2. WTMSIG_BLOCK_SIGNATURES: Adds support for weighted threshold multi-signature (WTMsig) authorities for block production (#7404, #8002, #8021)

Both of these features require activation through the privileged preactivate_feature intrinsic. This is typically facilitated by executing the eosio::activate system contract action (requires system contract v1.7.0 or later) via the eosio.msig contract after getting supermajority block producer approval. However, while these protocol features can be activated through coordination of the block producers alone, it is still critical to give sufficient time for all nodes to upgrade to v2.0.x before activating any of the above two protocol features. Activation of any of these two protocol features will immediately fork out any nodes that do not support the protocol features (e.g. any nodes running a version of nodeos earlier than v2.0.x).

Both of the above protocol features only add new behavior to the EOSIO blockchain. They are not expected to change existing behavior in a significant way that would cause existing contracts to break. Existing applications and block explorers are also unlikely to break upon activation of these protocol features, however these new features enable new data structures to be utilized on-chain which applications and especially block explorers need to be prepared to handle. For example, activation of the WEBAUTHN_KEY protocol feature means that an eosio::newaccount or eosio::updateauth action could now include WebAuthn public keys as part of the provided authority. So, an application dealing with these actions (e.g. a general authenticator for EOSIO transactions) will need to be prepared to support the serialization of WebAuthn public keys appearing in a place where a public_key ABI type is expected. Another example is how the activation of the WTMSIG_BLOCK_SIGNATURES protocol feature causes the new_producers field of a block header to always remain empty, even when a proposed producer schedule gets promoted to pending; upon activation of the WTMSIG_BLOCK_SIGNATURES protocol feature, the pending schedule data is instead stored (when present) within the header_extensions of the block header. So, block explorers expecting to show these pending producer schedules to users will need to update their code accordingly. As usual, test networks provide a great environment to try existing contracts, applications, services, etc. with the changes of the above protocol features to determine what breaks and what needs to be updated.

For more details on the WEBAUTH_KEY protocol feature, see the section titled "WebAuthn Support". For more details on the WTMSIG_BLOCK_SIGNATURES protocol feature, see the section titled "Weighted Threshold Multi-signature (WTMsig) Block Signing Authorities".

WebAuthn Support (#7421)

WebAuthn support within EOSIO is now available for developers to begin testing WebAuthn based transaction signing in their EOSIO applications. Private EOSIO chains can start using WebAuthn based signatures with this release. We also anticipate releasing additional demos which will attempt to outline how Dapp authors can leverage WebAuthn for contract actions meriting higher levels of security as a second factor authorization mechanism.

Weighted Threshold Multi-Signature Block Signing Authorities (#7403)

Block producers must be able to provide high availability for their core service of running the blockchain (aka producing blocks). A common approach to achieve this is redundant infrastructure that efficiently maintains block production, in the event of a hardware malfunction or networking issues. Weighted Threshold Multi-Signature Block Production is the first of many features that seek to provide block producers with a complete high availability solution.

Current consensus rules require exactly one cryptographic block signing key per block producer. This key, whether stored on disk and loaded via software or protected with a hardware wallet, represents a single-point-of-failure for the operations of a block producer. If that key is lost or access to the hardware module that contains it is temporarily unavailable, the block producer has no choice but to drop blocks, impacting the whole network’s throughput.

To improve the security and scalability of block production, weighted threshold multi-signature (WTMsig) block signing authorities provides a permission layer that allows for multiple block signing keys in a flexible scheme that will enable redundant block signing infrastructure to exist without sharing any sensitive data.

An updated version of the system contract is required to enable block producers to use WTMsig block signing authorities. Version v1.9.0-rc1 of eosio.contracts adds a new regproducer2 action to the eosio.system contract which enables a block producer candidate to register a WTMsig block signing authority. (That version of the system contract can only be deployed on an EOSIO chain that has activated the WTMSIG_BLOCK_SIGNATURES protocol feature.) More details are available at: #7404, #8002, #8021.

Multi-threaded net_plugin

We have added multi-threading support to net_plugin. Almost all processing in the net_plugin (block propagation, transaction processing, block/transaction packing/unpacking etc.) are now handled by separate threads distinct from the main application thread. This significantly improves transaction processing and block processing performance on multi-producer EOSIO networks. The net-threads arg (defaults to 2) controls the number of worker threads in net_plugin thread pool.(#6845, #7598, #7392, #7786 and related optimizations are available in: #7686, #7785, #7721, #7825, and #7756).

Chain API Enhancements (#7530)

The uint128 and int128 ABI types are now represented as decimal numbers rather than the old little-endian hexadecimal representation. This means that the JSON representation of table rows returned by the get_table_rows RPC will represent fields using this type differently than in prior versions. It also means that the lower_bound and upper_bound fields for get_table_rows RPC requests that search using a uint128 secondary index will need to use the new decimal representation. This change makes the ABI serialization for `u...

EOSIO v1.8.4 Release Notes

This release contains security, stability, and miscellaneous fixes.

Security bug fixes

Consolidated Security Fixes for 1.8.4 (#7980)

• WebAssembly checktime fixes

Note: These security fixes are relevant to all nodes on EOSIO blockchain networks.

Stability bug fixes

• (#7925) Fix intermittent crash on exit when port already in use - 1.8
• (#7941) Net plugin sync - 1.8
• (#7949) net_plugin correctly handle unknown_block_exception - 1.8
• (#7965) Net plugin unexpected block - 1.8

Other Changes

• (#7882) Create Release Build Test
• (#7902) Add Support for eosio-test-stability Pipeline
• (#7907) [1.8.x] Add Trigger for LRTs and Multiversion Tests Post PR
• (#7917) [1.8.x] Forked PR fix
• (#7913) [1.8.x] Updated anka plugin, added failover for registries, and added sleep fix for git clone/networking bug
• (#7928) Fix Release Build Type for macOS on Travis CI
• (#7936) [1.8.x] Support all BK/Travis cases in Submodule Regression Script
• (#7944) Forked chain test error statement - 1.8
• (#7934) Refactor producer plugin start_block - 1.8
• (#7959) [1.8.x] Fix Mac builds on Travis

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.

EOSIO v1.7.7 Release Notes

This release contains security, stability, and miscellaneous fixes.

Security bug fixes

Consolidated Security Fixes for 1.7.7 (#7979)

• WebAssembly checktime fixes

Note: These security fixes are relevant to all nodes on EOSIO blockchain networks.

Stability bug fixes

• (#7929) Fix intermittent crash on exit when port already in use - 1.7
• (#7942) Net plugin sync - 1.7
• (#7950) net_plugin correctly handle unknown_block_exception - 1.7
• (#7970) Net plugin unexpected block - 1.7

Other Changes

• (#7908) [1.7.x] Add Trigger for LRTs Post PR
• (#7916) [1.7.x] Forked PR fix
• (#7912) [1.7.x] Updated anka plugin, added failover for registries, and added sleep fix for git clone/networking bug
• (#7938) [1.7.x] Support all BK cases in Submodule Regression Script
• (#7945) Forked chain test error statement - 1.7
• (#7951) Refactor producer plugin start_block - 1.7

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.

EOSIO v1.8.3 Release Notes

This release contains stability and miscellaneous fixes.

Deprecation Notices

The network-version-match option in nodeos has been deprecated. When this option is set to true, it may needlessly restrict connections between two different versions of nodeos that are capable of communicating with the same network protocol version. Keeping this option set at its default of false allows two nodeos instances to negotiate a common version of the network protocol. Setting this option to false is especially important given that the v2.0.0 release of EOSIO will add a new supported version of the network protocol that enables additional capabilities; nodeos versions earlier than 2.0.0 will encounter problems connecting to v2.0.0 nodes if network-version-match is set to true. For this reason, the network-version-match option is now deprecated and will be removed in the v2.0.0 release of EOSIO.

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

Stability bug fixes

• (#7836) bandwidth - 1.8.x
• (#7855) Net plugin sync - 1.8
• (#7888) Fix exit crash - 1.8

Other Changes

• (#7844) Deprecate network version match - 1.8
• (#7839) [1.8.x] Travis CI + Buildkite 3.0
• (#7851) [1.8.x] Increase Contracts Builder Timeout + Fix $SKIP_MAC
• (#7861) [1.8.x] Ensure release flag is added to all builds.
• (#7872) [1.8.x] Mac Builder Boost Fix
• (#7869) cleos get actions - 1.8
• (#7875) Fix tests bootstrap - 1.8
• (#7880) [1.8.x] Ensure Artfacts Upload on Failed Tests

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.

EOSIO v1.7.6 Release Notes

This release contains stability and miscellaneous fixes.

Deprecation Notices

The network-version-match option in nodeos has been deprecated. When this option is set to true, it may needlessly restrict connections between two different versions of nodeos that are capable of communicating with the same network protocol version. Keeping this option set at its default of false allows two nodeos instances to negotiate a common version of the network protocol. Setting this option to false is especially important given that the v2.0.0 release of EOSIO will add a new supported version of the network protocol that enables additional capabilities; nodeos versions earlier than 2.0.0 will encounter problems connecting to v2.0.0 nodes if network-version-match is set to true. For this reason, the network-version-match option is now deprecated and will be removed in the v2.0.0 release of EOSIO.

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

Stability bug fixes

• (#7837) bandwidth - 1.7.x
• (#7856) Net plugin sync - 1.7
• (#7890) Fix exit crash - 1.7

Other Changes

• (#7843) Deprecate network version match - 1.7
• (#7815) [1.7.x] Buildkite 3.0
• (#7850) [1.7.x] Increase Contracts Builder Timeout + Fix $SKIP_MAC + Fix hard-coded build command
• (#7863) [1.7.x] Ensure release flag is added to all builds.
• (#7870) cleos get actions - 1.7
• (#7874) [1.7.x] Brew Updater Skips
• (#7879) [1.7.x] Ensure Artfacts Upload on Failed Tests

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.

EOSIO v1.8.2 Release Notes

This release contains stability and miscellaneous fixes.

Stability bug fixes

• (#7660) fix fork resolve in special case - v1.8.x
• (#7674) Net plugin fixes 1.8
• (#7692) Fix nodeos 1.8.x to > 1.7.x peering issue (allowed-connection not equal to "any")
• (#7743) Fix db exhaustion - 1.8.x
• (#7750) Modify net_plugin socket/resolver use
• (#7793) net_plugin capture socket - segfault
• (#7804) Call resolve on connection strand - 1.8.x

Other Changes

• (#7611) use explicit billing for unapplied and deferred transactions in tester - v1.8.x
• (#7613) bios-boot-tutorial.py: bugfix, SYS hardcoded instead of using command…
• (#7631) issues/7627: Install script missing !
• (#7601) fix 7600 double confirm after changing sign key
• (#7701) fix producer_plugin watermark tracking - v1.8.x
• (#7713) [TRAVIS POC] 1.8 Support passing in JOBS for docker/kube multi-tenancy
• (#7726) Fix increment in test - 1.8.x
• (#7728) Fix db_modes_test
• (#7747) two useful chainbase backports for 1.8
• (#7807) Correct cpu_usage calculation when more than one signature - 1.8.x
• (#7811) Add IMPORTANT file and update README - 1.8.x
• (#7819) rename IMPORTANT to IMPORTANT.md - 1.8.x

Deprecation notice reminder

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

Thanks!

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

• @cc32d9
• @rdewilder

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.

EOSIO v1.7.5 Release Notes

This release contains stability and miscellaneous fixes.

Stability bug fixes

• (#7699) Fix nodeos 1.8.x to > 1.7.x peering issue (allowed-connection not equal to "any") - 1.7.x
• (#7628) Call resolve on connection strand - 1.7.x
• (#7745) Fix db exhaustion - 1.7.x
• (#7779) Modify net_plugin socket/resolver use - 1.7.x
• (#7802) net_plugin capture socket - segfault - 1.7.x
• (#7806) Net plugin fixes 1.7
• (#7805) fix fork resolve in special case - v1.7.x

Other Changes

• (#7521) [1.7.x] Removed legacy-os for LRT
• (#7583) Sighup logging - 1.7.x
• (#7612) use explicit billing for unapplied and deferred transactions in tester - v1.7.x
• (#7629) [1.7.x] Brew upgrade fix
• (#7714) [TRAVIS POC] 1.7 Support passing in JOBS for docker/kube multi-tenancy
• (#7727) Fix increment in test - 1.7.x
• (#7808) Correct cpu_usage calculation when more than one signature - 1.7.x
• (#7810) Add IMPORTANT file and update README - 1.7.x
• (#7818) rename IMPORTANT to IMPORTANT.md - 1.7.x

Deprecation notice reminder

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

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

• @rdewilder

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.

EOSIO v1.8.1 Release Notes

This release contains important consensus related security fixes that are relevant to all nodes on EOSIO networks (Producer and API nodes).

Security bug fixes

Consolidated Security Fixes for 1.8.1 (#7619)

• Consensus protocol fixes

Note: These security fixes are relevant to all nodes on EOSIO blockchain networks. However, in particular, block production nodes on public networks that are currently running v1.8.0-rc1, v1.8.0-rc2, or v1.8.0 of EOSIO should consider upgrading their nodes to v1.8.1 as soon as possible.

Upgrading from previous versions of EOSIO

Upgrading from v1.8.0

Node operators should consider upgrading v1.8.0 nodes to v1.8.1 as soon as possible. They can follow normal upgrade procedures for the upgrade from v1.8.0 to v1.8.1. There should be no need to do a replay or import from a snapshot.

Upgrading from v1.7.x and earlier

Node operators that wish to update their v1.7.x nodes to v1.8.x should consider upgrading to v1.8.1 and avoid v1.8.0, v1.8.0-rc1, and v1.8.0-rc2. Upgrading from v1.7.x or earlier to v1.8.1 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 or v1.8.0-rc2

Node operators should consider upgrading v1.8.0-rc1 or v1.8.0-rc2 nodes to v1.8.1 as soon as possible. Upgrading from v1.8.0-rc1/v1.8.0-rc2 to v1.8.1 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.1 (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.1 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/v1.8.0-rc2 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.1 from the generated snapshot using --snapshot command line option.

Other Changes

• (#7573) [1.8.x] Don't create mongo folders unless ENABLE_MONGO is true
• (#7574) [1.8.x] Better found/not found messages for clarity
• (#7582) Update to fc with logger fix - 1.8.x
• (#7559) [1.8.x] Ability to set *_DIR from CLI
• (#7554) [1.8.x] CMAKE version check before dependencies are installed
• (#7587) [1.8.x] Various BATS test fixes
• (#7579) [1.8.x] -i support for relative paths
• (#7589) [1.8.x] SUDO_COMMAND -> NEW_SUDO_COMMAND
• (#7593) [1.8.x] Install location fix
• (#7609) indicate in brew bottle mojave is required - 1.8

Deprecation notice reminder

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

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.

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 ...