An open source smart contract platform
This release contains stability and miscellaneous fixes.
The new options cpu-effort-percent
and last-block-cpu-effort-percent
now provide a mechanism to restrict the amount of time a producer is processing transactions for inclusion into a block. It also controls the time a producer will finalize/produce and transmit a block. Block construction now always begins at whole or half seconds for the next block.
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.
This release contains security, stability, and miscellaneous fixes.
Note: These security fixes are relevant to all nodes on EOSIO blockchain networks.
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.
This release contains security, stability, and miscellaneous fixes.
Note: These security fixes are relevant to all nodes on EOSIO blockchain networks.
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.
This release contains security, stability, and miscellaneous fixes.
This release also 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.
Note: These security fixes are relevant to all nodes on EOSIO blockchain networks.
The above is in addition to the other security fixes that were introduced in prior release candidates for 2.0.0:
This above is in addition to the other stability fixes that were introduced in prior release candidates for 2.0.0:
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.
At this time, block producers should consider all running EOS VM JIT as the WASM runtime on their block producing nodes. Other non-producing nodes should feel free to use the faster EOS VM Optimized Compiler runtime instead.
EOSIO v2.0.x introduces two new consensus protocol upgrade features (or just protocol features for short):
WEBAUTHN_KEY
: Adds support for WebAuthn keys and signatures (#7421)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 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.
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.
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).
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 uint128
and int128
ABI types consistent with eosjs and abieos.
The get_table_rows
RPC when used with secondary index types like sha256
, i256
, and ripemd160
had bugs that scrambled the bytes in the lower_bound
and upper_bound
input field. This release now fixes these issues allowing clients to properly search for tables rows using these index types.
A new field next_key
has been added to the response of the get_table_rows
RPC which represents the key of the next row (in the same format as lower_bound
and upper_bound
) that was not able to be returned in the response due to timeout limitations or the user-specified limit. The value of the next_key
can be used as the lower_bound
input for subsequent requests in order to retrieve a range of a large number of rows that could not be retrieved within just a single request.
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.
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):
--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
).blocks/reversible
and state
sub-directories within the data directory.--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.)Node operators should consider upgrading v2.0.0-rc1, v2.0.0-rc2, and v2.0.0-rc3 nodes to v2.0.0 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.
The WAVM WebAssembly runtime was deprecated several months ago with the release of EOSIO v2.0.0-rc1 which introduced EOS VM. Now with the release of a stable version 2.0.0, EOS VM (JIT or Optimized Compiler variants) can be used instead of WAVM. So WAVM has now been removed as a WASM runtime option from nodeos.
Please refer to the Consolidated EOSIO Deprecations List for the currently active set of deprecation notices.
-b
flag for cleos get table
subcommandboost/asio/io_context.hpp
header to transaction_metadata.hpp
for branch develop
release/2.0.x
)Special thanks to the community contributors that submitted patches for this release:
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.
This release contains security, stability, and miscellaneous fixes.
Note: These security fixes are relevant to all public API nodes on EOSIO blockchain networks.
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.
This release contains stability and miscellaneous fixes.
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.
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.
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.
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.
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):
--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
).blocks/reversible
and state
sub-directories within the data directory.--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.)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.
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.
This release contains stability and miscellaneous fixes.
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.
This release contains miscellaneous fixes.
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.
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.
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.
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.
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):
--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
).blocks/reversible
and state
sub-directories within the data directory.--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.)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.
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.