Releases: EOSIO/eos
EOSIO v1.8.11 Release Notes
This release contains stability and miscellaneous fixes.
Stability bug fixes
Changes
Limit block production window (#8507, #8574)
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.
Other Changes
- (#8554) Drop late check - 1.8
- (#8558) Read-only with drop-late-block - 1.8
- (#8569) Timestamp watermark slot - 1.8.x
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.
EOSIO v2.0.1 Release Notes
This release contains security, stability, and miscellaneous fixes.
Security bug fixes
Consolidated Security Fixes for 2.0.1 (#8514)
- Earlier block validation for greater security.
- Improved handling of deferred transactions during block production.
- Reduce net plugin logging and handshake size limits.
Note: These security fixes are relevant to all nodes on EOSIO blockchain networks.
Stability bug fixes
- (#8471) Remove new block id notify feature - 2.0
- (#8472) Report block header diff when digests do not match - 2.0
- (#8496) Drop late blocks - 2.0
- (#8510) http_plugin shutdown - 2.0
Other Changes
- (#8430) Update fc to fix crash in logging
- (#8435) [release/2.0.x] Update README.md and hotfix documentation links
- (#8452) [2.0.x] [CI/CD] Boost will not install without SDKROOT
- (#8457) [2.0.x] reverting fc
- (#8458) [2.0.x] Pipeline file for testing the build script
- (#8467) [2.0.x] Switching to using the EOSIO fork of anka-buildkite-plugin for security reasons
- (#8515) [2.0.x] Don't trigger LRT a second time
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.
EOSIO v1.8.10 Release Notes
This release contains security, stability, and miscellaneous fixes.
Security bug fixes
Consolidated Security Fixes for 1.8.10 (#8516)
- Earlier block validation for greater security.
- Improved handling of deferred transactions during block production.
- Reduce net plugin logging and handshake size limits.
Note: These security fixes are relevant to all nodes on EOSIO blockchain networks.
Stability bug fixes
- (#8429) Update fc to fix crash in logging - 1.8
- (#8495) Drop late blocks - 1.8
- (#8509) http_plugin shutdown - 1.8
Other Changes
- (#8426) fix discovery of openssl in tester cmake when OPENSSL_ROOT_DIR not set - 1.8
- (#8454) [1.8.x] Added better sleep pre-execute for Anka commands + boost fix
- (#8469) [1.8.x] Switching to using the EOSIO fork of anka-buildkite-plugin for security reasons
- (#8485) Allow aliases of variants in ABI - 1.8.x
- (#8520) [1.8.x] Don't trigger LRT a second time
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.
EOSIO v2.0.0 Release Notes
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.
Security bug fixes
Consolidated Security Fixes for 2.0.0 (#8420)
- Limit size of response to API requests
- EOS VM fixes
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:
Stability bug fixes
- (#8399) Net plugin sync check - 2.0
This above is in addition to the other stability fixes that were introduced in prior release candidates for 2.0.0:
- (#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
- (#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
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.
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.
Consensus Protocol Upgrades
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 (#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](https://github.com/EOSI...
EOSIO v1.8.9 Release Notes
This release contains security, stability, and miscellaneous fixes.
Security bug fixes
Consolidated Security Fixes for 1.8.9 (#8418)
- Limit size of response to API requests
Note: These security fixes are relevant to all public API nodes on EOSIO blockchain networks.
Stability bug fixes
- (#8400) Net plugin sync check - 1.8
Other Changes
- (#8392) Add eosio-resume-from-state Test
- (#8394) Make multiversion protocol test conditional.
- (#8415) Add better logging of exceptions in emit - 1.8
- (#8416) return more from producer_plugin's get_runtime_options() - 1.8
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.
EOSIO v1.8.8 Release Notes
This release contains stability and miscellaneous fixes.
Stability bug fixes
- (#8380) Revert "Only send handshake if it has changed from last send." - 1.8
- (#8386) Propagate exceptions out push_block - 1.8
Other Changes
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.
EOSIO v1.8.7 Release Notes
This release contains stability and miscellaneous fixes.
Stability bug fixes
- (#8271) Net plugin sync
- (#8286) Net plugin handshake
- (#8301) net_plugin lib sync
- (#8302) net_plugin boost asio error handling
Other Changes
- (#8206) Fixed under min available test to not count failed attempts as actual sends
- (#8241) chainbase sync to pick up DB shrink fix while in heap mode
- (#8246) Install llvm@4 from homebrew -> Install llvm release_40 from github/source + [email protected] fix
- (#8272) Update CentOS version for CI.
- (#8278) Travis updates.
- (#8294) debug level logging for launcher service
- (#8297) Fix bios boot python script due to 1.8.x changes
- (#8310) Extend shutdown allowed time in under min available resources test
- (#8323) Retries and Contract Builders for Tags
- (#8338) increase tester state size - 1.8
- (#8342) [1.8.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.
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):
- 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_plugincommand-line options and then using the/v1/producer/create_snapshotRPC endpoint to generate a portable snapshot (e.g. run the commandcurl -X POST http:/127.0.0.1:8888/v1/producer/create_snapshot -d '{}' | jq). - Shut down nodeos and delete the
blocks/reversibleandstatesub-directories within the data directory. - Launch nodeos v2.0.x from the generated snapshot using the
--snapshotcommand 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--snapshotoption.)
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.
EOSIO v1.8.6 Release Notes
This release contains miscellaneous fixes.
Changes
- (#8112) [1.8.x] Mac OSX steps need a min of 1 hour
- (#8126) [1.8.x] Move the ensure step into the build step, eliminating the need for templaters
- (#8148) [1.8.x] CI platform directories
- (#8156) Post State history callback as medium priority - 1.8
- (#8174) ensure GMP is always dynamically linked - 1.8
- (#8176) [1.8.x] Unpinned CI fixes
- (#8183) [1.8.x] 10 second sleep to address heavy usage wait-network bug in Anka
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-rc2 Release Notes
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):
- 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_plugincommand-line options and then using the/v1/producer/create_snapshotRPC endpoint to generate a portable snapshot (e.g. run the commandcurl -X POST http:/127.0.0.1:8888/v1/producer/create_snapshot -d '{}' | jq). - Shut down nodeos and delete the
blocks/reversibleandstatesub-directories within the data directory. - Launch nodeos v2.0.x from the generated snapshot using the
--snapshotcommand 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--snapshotoption.)
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.