Releases: AntelopeIO/leap
Leap v3.2.1
This patch release contains SHiP stability fixes, several additional bug fixes, test fixes, logging improvements, and documentation updates.
Leap v3.2.1 Release Notes
Bug fixes
SHiP stability fixes
State History Plugin (SHiP) stability issues were reported with the release of Leap v.3.2.0 where it would crash under heavy load. This has been resolved with a backport of state_history_plugin fixes.
From the backport:
- Create an additional thread for all ship network communication. This thread already existed in release Leap v3.2.0 but was not used.
- Fix bug where
state_history_pluginwould send blocks withblock_numsmaller than the client requests when the state history block head is behind the block head of the client.
Additional changes:
- Remove
session_manager_tand use post to main thread sosession_setis only accessed from main thread. - Use
named_thread_poolto simplify SHiP thread. Older versions of boost do not provide anacceptorthat takes astrandin constructor, so rely on implicit strand of single thread runningio_contextwhich is much simpler than wrapping all calls inboost::asio::bind_executor. - The destructor of boost beast web socket stream is called on the SHiP thread.
Interrupt speculative block start_block when a production block is received
Block propagation has been improved under high load by exiting a speculative block start_block when a production block comes into the node and its block header is validated. This allows the block to be processed immediately after the execution of the current transaction.
Previously, for a speculative block, an incoming block would not be processed until the main thread was released from processing the backlog of pending transactions that fit with the completion of start_block. This could delay the incoming block processing by as much as 500ms.
Attempt connection retry for duplicate connections
When syncing from one peer a sync wait timeout could cause the connected peer to determine the reconnect was a duplicate. This prevented reconnection and required a manual disconnect/reconnect to reestablish the connection.
A previous fix for this corner case did not address that no_retry is was redundantly being checked in connect. This duplicate check has been removed because connect is only called from resolve_and_connect where the no_retry is already verified.
Add validation of plugin configuration for deep-mind
Previously there was no enforcement that when deep-mind was enabled that p2p-accept-transactions and
api-accept-transactions be disabled. There is now validation that throws an error when configured incorrectly.
Further details on changes since last release
Contributors
Special thanks to the contributors that submitted patches for this release:
Full list of changes since last release
PRs
- (504)[3.1 -> 3.2] Added validation of plugin configuration for deep-mind
- (534)[3.1 -> 3.2] Test nodeos_forked_chain_test: Fix race on kill of bridge node
- (559)[3.1 -> 3.2] Do not run maintenance task on shutdown
- (566)[3.2] Fix Test: Specify a large time limit for cleos get table
- (587)[3.2] Fixes Producer Plugin Schema Fixes and Better Alignment with OpenAPI spec
- (595)[3.1 -> 3.2] Update nodeos options help usage [docs]
- (615)[3.1 -> 3.2] Attempt connection retry for duplicate connections
- (624)[3.2] Backport SHiP fixes from eosio/eos release/2.2.x
- (648)[3.1 -> 3.2] Interrupt speculative start_block when a block is received
- (653)[3.1->3.2] Merge release 3.1.4 version bump
- (657) [3.2] bump Leap version to v3.2.1
Full Changelog: v3.2.0...v3.2.1
Contributors
Assets 5
Leap v3.1.4
This patch release contains several bug fixes, test fixes, logging improvements, and documentation updates.
Leap v3.1.4 Release Notes
Bug fixes
Interrupt speculative block start_block when a production block is received
Block propagation has been improved during high load by exiting speculative block start_block when a block comes into the node and the block header is validated so that it can be processed immediately after the execution of the current transaction.
Previously, for a speculative block, an incoming block would not be processed until the main thread was released from processing the backlog of pending transactions that fit with the completion of start_block. This could delay the incoming block processing by as much as 500ms.
Attempt connection retry for duplicate connections
When syncing from one peer a sync wait timeout could cause the connected peer to determine the reconnect was a duplicate. This prevented reconnection and required a manual disconnect/reconnect to reestablish the connection.
A previous fix for this corner case did not address that no_retry is was redundantly being checked in connect. This duplicate check has been removed because connect is only called from resolve_and_connect where the no_retry is already verified.
Add validation of plugin configuration for deep-mind
Previously there was no enforcement that when deep-mind was enabled that p2p-accept-transactions and
api-accept-transactions be disabled. There is now validation that throws an error when configured incorrectly.
Further details on changes since last release
Contributors
Special thanks to the contributors that submitted patches for this release:
Full list of changes since last release
PRs
- (441)[3.1] Fix test failure due to trx hitting near end of block production time
- (486)[3.1] Use net_plugin_impl logger instead of default logger
- (503)[3.1] Added validation of plugin configuration for deep-mind
- (533)[3.1] Test nodeos_forked_chain_test: Fix race on kill of bridge node
- (541)[3.1] Do not run maintenance task on shutdown
- (569)[3.1] Fixes Producer Plugin Schema Fixes and Better Alignment with OpenAPI spec
- (583)[3.1] Update nodeos options help usage [docs]
- (606)[3.1] Attempt connection retry for duplicate connections
- (543)[3.1] Interrupt speculative start_block when a block is received
- (651)bump Leap release to 3.1.4
Full Changelog: v3.1.3...v3.1.4
Contributors
Assets 5
Leap v3.2.0
Release 3.2.0 includes a new unified command-line interface (CLI) tool called leap-util to support users operating Leap nodes, a significant number of new cleos sub-commands, and various performance enhancements. A large portion of this release is a series of backported PRs from previous releases of EOSIO.
Leap v3.2.0 Release Notes
New features
New leap-util program
PRs
The nodeos program is meant to be run as a daemon. Over time, however, nodeos has collected various functionalities that are useful to Leap node operators, which are invoked by executing the nodeos program which then completes the desired task and then immediately exits the nodeos process. Since nodeos was designed as a daemon rather than a CLI tool like cleos, the interface to invoke these functions within the nodeos program is clunky compared to the hierarchical sub-command interface of cleos.
However, these functions are meant for Leap node operators and are closely tied to the nodeos executable. The program cleos is intended as tool for a more general audience that includes users who interact with servers running nodeos with public interfaces serving its API but do not necessarily run nodeos themselves. Dumping all that functionality into cleos would clutter its interface and be a distraction for the intended audience of cleos.
Furthermore, the Leap package comes with additional programs like eosio-blocklog which provide additional functionality that is relevant to Leap node operators but is not part of nodeos.
This release introduces a new program called leap-util. The program leap-util is intended to be a unified tool to capture all the functions that would benefit Leap node operators specifically and which are not appropriate to include in nodeos given how nodeos is intended to be used as a daemon. It uses a command-line interface of hierarchical sub-commands familiar to users of cleos.
The scope of leap-util includes all of the functionality provided by eosio-blocklog (which now makes the eosio-blocklog program redundant) and will, over time, include additional functions: some currently in nodeos (that really do not belong in nodeos); and others which are completely new capabilities that haven't existed in prior EOSIO or Leap releases in any form.
For the MVP of leap-util introduced in this release, the following features are supported:
CLI11command-line parsing library with autocompletioneosio-blocklogfull functionality via sub-commandblock-log- Retrieving chainbase build environment information via sub-command
chain-state
Enhancements to cleos
Autocomplete support
The enhancements to the CLI11 library to support autocomplete for the new leap-util program have also made it possible for cleos to also support autocomplete since it shares the same enhanced CLI11 library to parse its command-line arguments.
HTTP/1.1 support for cleos
PRs
- (mandel#533) [3.2] cleos Http 1.1 support and improves response handling
- (mandel#630) [3.2] Allow HTTP-RPC with empty response
In some scenarios involving advanced cloud stacks, cleos was being rejected by gateways or proxies with HTTP status 426. The HTTP 426 Upgrade Required error response code indicates that the server refuses to perform the request using the current protocol but might be willing to do so after the client upgrades to a different protocol. The server sends an Upgrade header with this response to indicate the required protocol(s). This update also improves cleos handling of error codes from nodeos; specifically around use of --print-response.
cleos validate signatures sub-command
This sub-command takes a signed transaction, validates the signatures on it, and outputs a JSON array of the recovered public keys.
cleos validate signatures <json_file_of_transaction>
Example:
$ cleos create account -j -d --json-file t eosio kevinh EOS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV EOS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV{
"expiration": "2022-06-23T00:50:08",
"ref_block_num": 4714,
"ref_block_prefix": 3530990,
"max_net_usage_words": 0,
"max_cpu_usage_ms": 0,
"delay_sec": 0,
"context_free_actions": [],
"actions": [{
"account": "eosio",
"name": "newaccount",
"authorization": [{
"actor": "eosio",
"permission": "active"
}
],
"data": "0000000000ea305500000000b4e9b68201000000010002c0ded2bc1f1305fb0faac5e6c03ee3a1924234985427b6167ca569d13df435cf0100000001000000010002c0ded2bc1f1305fb0faac5e6c03ee3a1924234985427b6167ca569d13df435cf01000000"
}
],
"transaction_extensions": [],
"signatures": [
"SIG_K1_K4ewr6ZLtiWABNKjEhWzXkfgiPdhpF2nKvGz9NKAGaZwtpKdBP6FBXrzKDpuiqEVfh5tZ4GAd4FcFZK4ysMf7NcgtreKfK"
],
"context_free_data": []
}$ cleos validate signatures <t>info 2022-06-23T00:49:48.284 cleos main.cpp:2690 operator() ] grabbing chain_id from nodeos
[
"EOS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV"
]
Add support for authority structure in cleos system newaccount sub-command
It is now possible to specify an authority structure (encoded as JSON) with cleos system newaccount for the owner or active authorities to use for the newly created account. It still remains possible to specify the single public key and single permission reference shorthands in place of the full authority structure.
Example
$ cleos system newaccount eosio testtesttest '{"threshold": 1, "keys":[{"key":"EOS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV", "weight":1}], "accounts":[{"permission":{"actor":"eosio.prods", "permission":"active"},"weight":1},{"permission":{"actor":"eosio.prods", "permission":"prod.major"},"weight":1},{"permission":{"actor":"eosio.prods", "permission":"prod.minor"},"weight":1}],"waits":[]}' --stake-net "1.0000 EOS" --stake-cpu "1.0000 EOS" --buy-ram-kbytes 4cleos get supported_protocol_features and system activate sub-commands
The sub-commands get supported_protocol_features and system activate were added to cleos so that protocol features can be activated by using their names. Feature digests are no longer needed.
A user can now use get supported_protocol_features to find a list of supported feature names. The command description was cleaned up and PREACTIVATE_FEATURE was removed because it is not possible to activate it using activate action from eosio.boot (RPC schedule_protocol_feature_activations must be used).
- Find supported protocol features
$ cleos get supported_protocol_featuresONLY_LINK_TO_EXISTING_PERMISSION
FORWARD_SETCODE
WTMSIG_BLOCK_SIGNATURES
GET_BLOCK_NUM
REPLACE_DEFERRED
NO_DUPLICATE_DEFERRED_ID
RAM_RESTRICTIONS
WEBAUTHN_KEY
BLOCKCHAIN_PARAMETERS
DISALLOW_EMPTY_PRODUCER_SCHEDULE
CRYPTO_PRIMITIVES
ONLY_BILL_FIRST_AUTHORIZER
RESTRICT_ACTION_TO_SELF
GET_CODE_HASH
ACTION_RETURN_VALUE
CONFIGURABLE_WASM_LIMITS2
FIX_LINKAUTH_RESTRICTION
GET_SENDER
- Activate a protocol feature
$ cleos system activate WTMSIG_BLOCK_SIGNATURESexecuted transaction: 667479cd2280739b21b925c1c9cddc2d8dc46626f0ecc61173aec5f092431c61 128 bytes 179 us
# eosio <= eosio::activate {"feature_digest":"299dcb6af692324b899b39f16d5a530a33062804e41f09dc97e9f156b4476707"}
warn 2022-07-16T01:51:13.001 cleos main.cpp:665 print_result warning: transaction executed locally, but may not be confirmed by the network yet
cleos get consensus_parameters sub-command
A new sub-command get consensus_parameters has been added to cleos to retrieve consensus parameters.
cleos --sign-with & --signature options
PRs
- (mandel#547) [3.2] Backport cleos transaction signature keys
- (mandel#674) [3.2] Backport: allow multiple signatures in cleos command “pu...
Contributors
Assets 5
Leap v3.2.0-rc2
Release 3.2.0-rc2 includes several improvements to leap-util, bug fixes, and test fixes.
Leap v3.2.0-rc2 Release Notes
Changes
Default error handler to print help in command line interface apps by default
The functionality to display help text by default when there is an error output has been added to leap-util and cleos.
leap-util final enhancements for MVP release
PRs
There were a few final refactors of the block.log subcommands to complete the leap-util MVP.
Inconsistency between Received block and Produced block log output messages
The Produced block log output message was missing total block elapsed time and total block time. There was also a minor discrepancy in how confirmation was logged.
API not found errors returning as plain-text message
In all previous versions of nodeos, any 404 not-found errors are returned as JSON documents. In 3.2.0-rc1 a plain-text error message was being returned in some scenarios. The standard of always returning application/json for all http responses including errors has been restored.
Building, compatibility, and upgrading
Upgrading from prior releases
To upgrade from Leap 3.1, simply install Leap 3.2 and restart the binaries while pointing to the same config and data directories as usual. The persisted data files used by Leap 3.1 are compatible with Leap 3.2.
Deprecations, removals, and dropped support
Deprecations
eosio-launcher
There is an ongoing initiative to develop a regression test framework that will replace the eosio-launcher functionality with python scripts.
The latest state of deprecations for Leap can be found at https://github.com/AntelopeIO/leap/wiki/Deprecations-and-Proposed-Deprecations-In-Leap-Software.
Further details on changes since last release
Contributors
Special thanks to the contributors that submitted patches for this release:
Full list of changes since last release
PRs
- (307)[3.1] Test fix: trx_finality_status_forked_test.py
- (308)[3.1 -> 3.2] Test fix: trx_finality_status_forked_test.py
- (313)[3.2] Update produced block log output.
- (316)[3.1] Test fix: nodeos_forked_chain_lr_test
- (335)[3.1 -> 3.2] Test fix: nodeos_forked_chain_lr_test
- (326)[3.2] Return application/json for all http responses including errors
- (322)[3.1] Test fix: api_tests checktime_pause_block_deadline_not_extended_test
- (338)[3.1 -> 3.2] Test fix: api_tests checktime_pause_block_deadline_not_extended_test
- (347)[3.1] SHiP Fix log output
- (348)[3.1 -> 3.2] SHiP Fix log output
- (327)[3.2] Block-log leap-util subcommand refactoring
- (356)[3.1] Remove replay optimization that skips recording transactions in dedup list
- (342)Complete Pinned Build Instructions + Other README Updates [docs]
- (365)[3.1 -> 3.2] Remove replay optimization that skips recording transactions in dedup list
- (358)[3.1] Curate eos.io refs and remove unused doc metadata [docs]
- (372)[3.1 -> 3.2] - Complete Build Instructions + Other README Updates [docs]
- (373)[3.1 -> 3.2] Curate eos.io refs and remove unused doc metadata [docs]
- (382)[3.1] Dropped trxs when overloaded logged as warning in nodeos
- (384)[3.1 -> 3.2] Warning message for trx being dropped due to high traffic
- (366)[3.1] Clear expired transactions before snapshot and integrity hash
- (389)[3.1 -> 3.2] Clear expired transactions before snapshot and integrity hash
- (371)[3.2] Changed default error handler to print help in cli apps by default
- (400)[3.1] Use error log instead of warning log when resource_monitor exceeds threshold by
- (404)[3.1 -> 3.2] Use error log instead of warning log when resource_monitor exceeds threshold
- (403)[3.2] restore secp256k1 library in
devinstallation component by @spoonincode - (403)[3.2] restore secp256k1 library in
devinstallation component - (413)[3.2] fix threading on state_history shutdown leading to hung nodeos shutdown
- (399)[3.2] Enable new CLI11 LeapFormatter for both cleos and leap-util
- (418)[3.1] bump Leap to release/3.1.3
- (422)[3.1->3.2] merge release/3.1.3 version bump PR
- (424)[3.2] bump Leap to 3.2.0-rc2
- (419)[3.2] update libfc path in EosioTesterBuild.cmake.in for building integration tests in CDT and System Contracts
Full Changelog:
v3.2.0-rc1...v3.2.0-rc2
Contributors
Assets 5
Leap v3.1.3
This patch release contains a bug fixes for a few small edge cases, several test fixes, and documentation updates.
Leap v3.1.3 Release Notes
Changes
Clearing expired transactions before generating a snapshot and integrity hash
Previously, there was a risk of including expired transactions from the very last call of clear_expired_input_transactions which could lead to generating incorrect snapshots and integrity hashes.
Removal of replay optimization
The replay optimization that skips recording transactions within the dedupe list had a risk of leaving the index in an inconsistent state. After some testing, the performance of the optimization being somewhat negligable justified it's removal instead of investing time in refactoring.
Dropped transactions when overloaded logged as warning in nodeos
Previously, when a transaction was rejected due to too many transactions in progress, that message would only get logged in a debug logging level.
Now, the first time a transaction is rejected due to too many transactions will be periodically logged as a warning in nodeos at an interval of 1 second or more to escalate visibility without spamming the logs.
Use error log instead of warning log when resource_monitor exceeds threshold
Previously, when the resource monitor exceeded its configured threshold, it would be logged as a warning. This has been updated to log as an error in order to prompt action by the operator.
Further details on changes since last release
Contributors
Special thanks to the contributors that submitted patches for this release:
Full list of changes since last release
PRs
- (307)[3.1] Test fix: trx_finality_status_forked_test.py
- (316)[3.1] Test fix: nodeos_forked_chain_lr_test
- (322)[3.1] Test fix: api_tests checktime_pause_block_deadline_not_extended_test
- (347)[3.1] SHiP Fix log output
- (356)[3.1] Remove replay optimization that skips recording transactions in dedup list
- (342)Complete Pinned Build Instructions + Other README Updates [docs]
- (358)[3.1] Curate eos.io refs and remove unused doc metadata [docs]
- (382)[3.1] Dropped trxs when overloaded logged as warning in nodeos
- (366)[3.1] Clear expired transactions before snapshot and integrity hash
- (400)[3.1] Use error log instead of warning log when resource_monitor exceeds threshold
- (418) [3.1] bump Leap to release/3.1.3
- (428)[3.1] CPack: fix separator in depends field of debian dev pacakge
Full Changelog: v3.1.2...v3.1.3
Contributors
Assets 5
Leap v3.2.0-rc1
Release 3.2.0 includes a new unified command-line interface (CLI) tool called leap-util to support users operating Leap nodes, a significant number of new cleos sub-commands, and various performance enhancements. A large portion of this release is a series of backported PRs from previous releases of EOSIO.
Leap v3.2.0-rc1 Release Notes
New features
New leap-util program
The nodeos program is meant to be run as a daemon. Over time, however, nodeos has collected various functionalities that are useful to Leap node operators, which are invoked by executing the nodeos program which then completes the desired task and then immediately exits the nodeos process. Since nodeos was designed as a daemon rather than a CLI tool like cleos, the interface to invoke these functions within the nodeos program is clunky compared to the hierarchical sub-command interface of cleos.
However, these functions are meant for Leap node operators and are closely tied to the nodeos executable. The program cleos is intended as tool for a more general audience that includes users who interact with servers running nodeos with public interfaces serving its API but do not necessarily run nodeos themselves. Dumping all that functionality into cleos would clutter its interface and be a distraction for the intended audience of cleos.
Furthermore, the Leap package comes with additional programs like eosio-blocklog which provide additional functionality that is relevant to Leap node operators but is not part of nodeos.
This release introduces a new program called leap-util. The program leap-util is intended to be a unified tool to capture all the functions that would benefit Leap node operators specifically and which are not appropriate to include in nodeos given how nodeos is intended to be used as a daemon. It uses a command-line interface of hierarchical sub-commands familiar to users of cleos.
The scope of leap-util includes all of the functionality provided by eosio-blocklog (which now makes the eosio-blocklog program redundant) and will, over time, include additional functions: some currently in nodeos (that really do not belong in nodeos); and others which are completely new capabilities that haven't existed in prior EOSIO or Leap releases in any form.
For the MVP of leap-util introduced in this release, the following features are supported:
CLI11command-line parsing library with autocompletioneosio-blocklogfull functionality via sub-commandblock-log- Retrieving chainbase build environment information via sub-command
chain-state
Enhancements to cleos
Autocomplete support
The enhancements to the CLI11 library to support autocomplete for the new leap-util program have also made it possible for cleos to also support autocomplete since it shares the same enhanced CLI11 library to parse its command-line arguments.
HTTP/1.1 support for cleos
PRs
- (mandel#533) [3.2] cleos Http 1.1 support and improves response handling
- (mandel#630) [3.2] Allow HTTP-RPC with empty response
In some scenarios involving advanced cloud stacks, cleos was being rejected by gateways or proxies with HTTP status 426. The HTTP 426 Upgrade Required error response code indicates that the server refuses to perform the request using the current protocol but might be willing to do so after the client upgrades to a different protocol. The server sends an Upgrade header with this response to indicate the required protocol(s). This update also improves cleos handling of error codes from nodeos; specifically around use of --print-response.
cleos validate signatures sub-command
This sub-command takes a signed transaction, validates the signatures on it, and outputs a JSON array of the recovered public keys.
cleos validate signatures <json_file_of_transaction>
Example:
$ cleos create account -j -d --json-file t eosio kevinh EOS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV EOS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV{
"expiration": "2022-06-23T00:50:08",
"ref_block_num": 4714,
"ref_block_prefix": 3530990,
"max_net_usage_words": 0,
"max_cpu_usage_ms": 0,
"delay_sec": 0,
"context_free_actions": [],
"actions": [{
"account": "eosio",
"name": "newaccount",
"authorization": [{
"actor": "eosio",
"permission": "active"
}
],
"data": "0000000000ea305500000000b4e9b68201000000010002c0ded2bc1f1305fb0faac5e6c03ee3a1924234985427b6167ca569d13df435cf0100000001000000010002c0ded2bc1f1305fb0faac5e6c03ee3a1924234985427b6167ca569d13df435cf01000000"
}
],
"transaction_extensions": [],
"signatures": [
"SIG_K1_K4ewr6ZLtiWABNKjEhWzXkfgiPdhpF2nKvGz9NKAGaZwtpKdBP6FBXrzKDpuiqEVfh5tZ4GAd4FcFZK4ysMf7NcgtreKfK"
],
"context_free_data": []
}$ cleos validate signatures <t>info 2022-06-23T00:49:48.284 cleos main.cpp:2690 operator() ] grabbing chain_id from nodeos
[
"EOS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV"
]
Add support for authority structure in cleos system newaccount sub-command
It is now possible to specify an authority structure (encoded as JSON) with cleos system newaccount for the owner or active authorities to use for the newly created account. It still remains possible to specify the single public key and single permission reference shorthands in place of the full authority structure.
Example
$ cleos system newaccount eosio testtesttest '{"threshold": 1, "keys":[{"key":"EOS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV", "weight":1}], "accounts":[{"permission":{"actor":"eosio.prods", "permission":"active"},"weight":1},{"permission":{"actor":"eosio.prods", "permission":"prod.major"},"weight":1},{"permission":{"actor":"eosio.prods", "permission":"prod.minor"},"weight":1}],"waits":[]}' --stake-net "1.0000 EOS" --stake-cpu "1.0000 EOS" --buy-ram-kbytes 4cleos get supported_protocol_features and system activate sub-commands
The sub-commands get supported_protocol_features and system activate were added to cleos so that protocol features can be activated by using their names and feature digests are no longer needed.
A user can now use get supported_protocol_features to find a list of supported feature names. The command description was cleaned up and PREACTIVATE_FEATURE was removed because it is not possible to activate it using activate action from eosio.boot (RPC schedule_protocol_feature_activations must be used).
- Find supported protocol features
$ cleos get supported_protocol_featuresONLY_LINK_TO_EXISTING_PERMISSION
FORWARD_SETCODE
WTMSIG_BLOCK_SIGNATURES
GET_BLOCK_NUM
REPLACE_DEFERRED
NO_DUPLICATE_DEFERRED_ID
RAM_RESTRICTIONS
WEBAUTHN_KEY
BLOCKCHAIN_PARAMETERS
DISALLOW_EMPTY_PRODUCER_SCHEDULE
CRYPTO_PRIMITIVES
ONLY_BILL_FIRST_AUTHORIZER
RESTRICT_ACTION_TO_SELF
GET_CODE_HASH
ACTION_RETURN_VALUE
CONFIGURABLE_WASM_LIMITS2
FIX_LINKAUTH_RESTRICTION
GET_SENDER
- Activate a protocol feature
$ cleos system activate WTMSIG_BLOCK_SIGNATURESexecuted transaction: 667479cd2280739b21b925c1c9cddc2d8dc46626f0ecc61173aec5f092431c61 128 bytes 179 us
# eosio <= eosio::activate {"feature_digest":"299dcb6af692324b899b39f16d5a530a33062804e41f09dc97e9f156b4476707"}
warn 2022-07-16T01:51:13.001 cleos main.cpp:665 print_result warning: transaction executed locally, but may not be confirmed by the network yet
cleos get consensus_parameters sub-command
A new sub-command get consensus_parameters has been added to cleos to retrieve consensus parameters.
cleos --sign-with & --signature options
PRs
- (mandel#547) [3.2] Backport cleos transaction signature keys
- (mandel#674) [3.2] Backport: allow multiple signatures in cleos command “push transaction”
Added --sign-with <public key> or --sign-with [ <public key 1>, <public key 2>, ... ] option to cleos options that generate a transaction. When specified, cleos will use the provided public keys instead of querying nodeos for the keys required for signing the transaction.
Added `--signature...
Contributors
Assets 5
Leap v3.1.2
This patch release contains a bug fix, several test fixes, and documentation updates.
Leap v3.1.2 Release Notes
Bug fix
Transaction de-dup list discrepancy replaying from state or snapshot
When replaying a block log, the transactions with expirations equal to the last irreversible block time were not added to the trx de-dup list. This created a difference in the de-dup list vs starting from state or a snapshot. This update now includes these transactions.
Further details on changes since last release
Contributors
Special thanks to the contributors that submitted patches for this release:
Full list of changes since last release
PRs
- (218) [3.1] Fix nodeos_retry_transaction_test.py
- (211) [3.1] when uploading failure logs, ignore missing files
- (226) [3.1] Test fix: wait for system init to be in block
- (238) [3.1] Sync docs with main [docs]
- (224) [3.1] updated trace_api openapi documentation [docs]
- (245) [3.1] Remove #pragma(s) to ignore warnings
- (249) [3.1] Increase keosd http-max-response-time-ms for tests
- (273) [3.1] Fix replay to correctly add trxs into the de-dup list
Full Changelog: v3.1.1...v3.1.2
Contributors
Assets 5
Leap v3.1.1
This patch release contains several bug fixes.
Leap v3.1.1 Release Notes
Bug fixes
Change to cleos exit status on failed trx processing
The behavior of cleos' exit status for failed transactions has changed in 3.1.1 to more closely align with behavior in previous EOSIO 2.0 releases. In Leap 3.1.0, cleos would return a 0 exit status on a failed transaction and require the caller of cleos to inspect the JSON output to determine that a transaction has failed. In Leap 3.1.1, similar to EOSIO 2.0, cleos' exit status will be non-zero for transaction failures.
Update subjective CPU billing to use uint64_t instead of uint32_t
Subjective billing was previously utilizing uint32_t for duration in microseconds, which only allowed for 1.2 hours before wrapping and returning to zero. If an account had over 1.2 hours of CPU extra, subjective CPU would never be applied, which was directly observed on WAX where waxptreasury subjective CPU wrapped. This has been partially attributed to instances of high CPU usage on that network. To resolve, this value has been updated to match objective billing, which utilizes uint64_t.
Race condition causing failure to sync on startup
Leap 3.1.0 included an attempted fix for block producers stuck in a coma state. However, the fix was a bit too aggressive and introduced a race-condition on startup syncing. This change reverts the aggressive reset of syncing from LIB instead of HEAD for every call to start_sync. Now it instead restarts syncing from LIB only when unlinkable blocks causes a connection to be closed.
Improved validation for set_whitelist_blacklist, add_greylist_accounts and remove_greylist_accounts
PRs
- (113) [3.1] validate input of set_whitelist_blacklist, add_greylist_accounts and remove_greylist_accounts
A lack of input validation for set_whitelist_blacklist, add_greylist_accounts and remove_greylist_accounts was introducing troubleshooting issues. Our current solution is to ensure at least one optional parameter is present in a RPC call.
Further details on changes since last release
Contributors
Special thanks to the contributors that submitted patches for this release:
Full list of changes since last release
PRs
- (56) [3.1] add a final job that passes if all tests pass making it easier to branch protect on checks
- (63)[3.1] fix a number of issues with http-max-bytes-in-flight-mb configuration
- (69)[3.1] Fix python format issue that caused test to fail
- (55)[3.1] Fix failure to sync on startup
- (72)[3.1] Fix crash on startup if port already in use
- (85)[3.1] patch pinned build's boost 1.70 to fix websocket defect
- (99)[3.1] add CLI11 license to install
- (106)[3.1] Fix test failure due to trx hitting near end of block production time
- (113)[3.1] validate input of set_whitelist_blacklist, add_greylist_accounts and remove_greylist_accounts
- (124)[3.1] Allow for larger subjective CPU billing amounts
- (128)[3.1] Test: verify on the correct fork before verifying trx status
- (135)[3.1] net_plugin fix startup issue when peer does not have requested blocks
- (155)[3.1] always overwrite old downloads in pinned build script
- (165)[3.1] use a temp dir for release-build test as it can leak creation of config.ini in to default location
- (179) [3.1] pinned_build.sh: make relative path work
- (183)[3.1] trx_finality_status_forked_test fix
- (194)[3.1] promote ship log recovery logging from dlog to ilog
- (199)[3.1] Update cleos to return an error code on failed trx processing
Full Changelog: v3.1.0...v3.1.1
Contributors
Assets 5
Leap v3.1.0
spoonincode
Matt Witherspoon
Release 3.1.0 includes protocol upgrades enabling:
- contracts to get the current block number and the hash of any contract deployed on an account;
- return values from actions which are accessible from the action trace;
- additional ability to configurable consensus parameters including increasing various limit enforced by the WebAssembly VM;
- and, access to various natively implemented cryptographic functions from contracts.
This release also includes many other new features including:
- a new transaction submission API endpoint with full trace of a transaction failure and automatic nodeos-mediated retry;
- nodeos-mediated cache of transaction finality statuses along with a new API endpoint to query the finality status of a transaction;
- the ability to request a nodeos computation of transaction costs without committing the transaction;
- the addition of new options for subjective billing;
- automatic pruning of old entries in block and
state_history_plugin(SHiP) logs; - and, much more.
Leap v3.1.0 Release Notes
Protocol changes
Action return values
A new protocol feature ACTION_RETURN_VALUE has been introduced which upon activation will make the host function set_action_return_value accessible to contracts. The set_action_return_value allows a contract to set a binary blob as the return value for the action. The last set value, if any, at the time the action completes will be used as the return value of the action which is stored in the action trace but also committed to within the action Merkle tree whose root is stored in the block header. ABI support allows for interpreting this binary blob as a structure similar to how it is done for the action input arguments.
The maximum allowed size for the binary blob for each action is enforced by the new blockchain parameter max_action_return_value_size which defaults to 256 bytes.
Note that while an off-chain client can access the action return value, a contract calling another contract via an inline action has no way to access the return value of the inline action.
Additional configurability of consensus parameters
A new protocol feature BLOCKCHAIN_PARAMETERS provides an alternative extensible mechanism to configure the existing blockchain parameters. Any new blockchain parameters, including the max_action_return_value_size parameter introduced with the ACTION_RETURN_VALUE protocol feature, are retrieved or modified only through this new mechanism to access the values of the parameters. The new mechanism consists of consists of getter and setter host functions, get_parameters_packed and set_parameters_packed respectively, which are made accessible only to privileged contracts upon activation of the BLOCKCHAIN_PARAMETERS protocol feature.
Additionally, another new protocol feature CONFIGURABLE_WASM_LIMITS2 provides a mechanism to adjust limits of the WebAssembly VM that were previous hard-coded. This mechanism consists of consists of getter and setter host functions, get_wasm_parameters_packed and set_wasm_parameters_packed respectively, which are made accessible only to privileged contracts upon activation of the CONFIGURABLE_WASM_LIMITS2 protocol feature.
Get code hash from within contracts
A new protocol feature GET_CODE_HASH has been introduced which upon activation will make the host function get_code_hash accessible to contracts. The get_code_hash host function allows any contract to specify the name of an account and then get back the number of times contract code was deployed to that account and the SHA256 hash of the contract code currently deployed on the account.
Host functions to accelerate crypto primitives
A new protocol feature CRYPTO_PRIMITIVES has been introduced which upon activation will make 7 new host functions accessible to contracts which are all related to cryptographic computations.
While in theory all of these cryptographic computations could be implemented in WebAssembly code if the transaction was given sufficient time to execute before timing out, leveraging these new host functions may allow for significantly reducing the time it takes to execute the computations because the computations are carried out in native implementation of the host executable. This means some cryptographic functions now become practically accessible to contracts even with typical transaction deadlines in production blockchains, and some others continue to remain accessible but at a lower CPU cost.
In particular, all of these new host functions serve to reduce CPU costs of executing the cryptographic functions available in EVM precompiled contracts.
Arbitrary-precision exponentiation under modulo
Activation of the CRYPTO_PRIMITIVES protocol feature introduces the mod_exp host function which enables modular exponentiation with arbitrary-precision numbers.
Support for the alt_bn128 elliptic curve
Activation of the CRYPTO_PRIMITIVES protocol feature introduces the following three host functions that support elliptic curve math involving the alt_bn128 elliptic curve:
alt_bn128_add: Point addition on the alt_bn128 elliptic curve.alt_bn128_mul: Scalar multiplication on the alt_bn128 elliptic curve.alt_bn128_pair: Bilinear function on groups on the alt_bn128 elliptic curve.
These host functions can support implementations that verify zkSNARKs.
ECDSA uncompressed public key recovery for the secp256k1 elliptic curve
The protocol already supported ECDSA public key recovery for the secp256k1 elliptic curve (and also for the secp256r1 elliptic curve) through the recover_key host function. However, that host function has two limitations. First, it aborts the transaction if an invalid signature is presented rather than returning a failure condition to the caller. Second, it returns the recovered public key in compressed format. And going from a compressed to uncompressed public key requires elliptic curve math which involves compiling in an elliptic curve library into the contract, thus bloating the contract size and increasing CPU time for ECDSA uncompressed public key recovery.
Activation of the CRYPTO_PRIMITIVES protocol features introduces the k1_recover host function which addresses both limitations of recovery_key mentioned above. However, it has its own limitation of only supporting the secp256k1 elliptic curve. There is currently no host function that returns an uncompressed public key from ECDSA recovery using the secp256r1 elliptic curve.
Additional support for hash functions
Activation of CRYPTO_PRIMITIVES protocol feature introduces the following two host functions:
sha3: This host function computes the SHA3-256 hash of an arbitrary byte string. Both the NIST and Keccak variants are supported.blake2_f: This host function implements the compression function F used in the BLAKE2 cryptographic hashing algorithm.
Get current block number from within contracts
A new protocol feature GET_BLOCK_NUM has been introduced which upon activation will make the host function get_block_num accessible to contracts. The get_block_num host function returns the block number (aka block height) of the current block.
New features
New transaction submission API
PRs
- (mandel#79) Transaction retry feature
- (mandel#88) Many Transaction Long Running Test
- (mandel#89) Add new transaction retry integration test
- (mandel#116) Add docs for transaction retry
- (mandel#173) Implement return failure traces
- (mandel#809) [3.1] Increase default transaction-retry-max-expiration-sec from 90 to 120
New chain_api_plugin endpoint:
-
/v1/chain/send_transaction2(send_transaction_params)struct send_transaction2_params { bool return_failure_trace = true; ///< Embed transaction exceptions into the returned transaction trace bool retry_trx = false; ///< request transaction retry on validated transaction std::optional<uint16_t> retry_trx_num_blocks{}; ///< if retry_trx, report trace at specified blocks from executed or lib if not specified fc::variant transaction; ///< same format as send_transaction };
This new transaction submission API supports returning the full trace of a failed transaction and automatic nodeos-mediated retry if enabled on the node.
When transaction retry is enabled on an API node, it will monitor incoming API transactions and ensure they are resubmitted additional times into the P2P network until they expire or are included in a block.
receipt and except fields of the returned trace.
New configuration args for nodeos:
transaction-retry-max-storage-size-gb- "Maximum size (in GiB) allowed to be allocated for the Transaction Retry feature. Setting above 0 enables this feature."
transaction-retry-interval-sec(defaults to 20)- "How often, in seconds, to resend an incoming transaction to the P2P network if not seen in a block."
transaction-retry-max-expiration-sec(defaults to 120)- "Maximum allowed transaction expiration for retry transactions, will retry transactions up to this value."
p2p-dedup-cache-expire-time-sec(defaults to 10)
...
Contributors
Assets 5
Leap v3.1.0-rc4
This is a RELEASE CANDIDATE for version 3.1.0. The latest STABLE release is v2.0.14.
This release contains several bug fixes, one small parameter update, and several changes to support the migration to the AntelopeIO organization. Please note that this release references changes committed in the EOS Network Foundation mandel repo.
Leap v3.1.0-rc4 Release Notes
Bug fixes and parameter adjustments
Reduce excessive logging of P2P handshake messages
In testing, it was discovered that when a node's full block log was not available that net plugin would unnecessarily send a handshake message for each unavailable block requested. Instead, the node will now disconnect from the peer with benign_other and move on to a different peer to sync from. This mirrors the existing pattern for blk_send_branch when a block is not available.
Increase default transaction-retry-max-expiration-sec from 90 to 120
It was requested by the community to make a small parameter update to adjust the default transaction-retry-max-expiration-sec to be aligned with the default values in eosio-core SDK when no expiration is specified.
Add missing file package to list of installable packages for pinned builds
There was a minor omission in the installation scripts resulting in an error when file package was not listed as an installable package.
Building, compatibility, and upgrading
New build procedure
The shell scripts previously recommended for building the software have been removed in favor of a build process entirely driven by CMake. Those wishing to build from source are now responsible for installing the necessary dependencies. The list of dependencies and the recommended build procedure are in the README.md file. Instructions are also included for efficiently running the tests.
Ubuntu 18.04, 20.04, and 22.04 are the only build platforms that are supported. Other distributions, compilers, and platforms are known to work. Your mileage may vary.
Activating protocol features
The instructions below walk through how to activate the protocol features introduced in the 3.0 and 3.1 releases on a new Antelope blockchain, e.g. a new local test blockchain. Step 3 does not include the other protocol features introduced in prior releases that you can also activate; simply add additional cleos calls to activate them by the appropriate digest in a suitable order.
If activating the new protocol features on an existing blockchain, you will likely be able to jump ahead to step 3.
- Activate special protocol feature:
PREACTIVATE_FEATURE
All protocol features require a special protocol feature called PREACTIVATE_FEATURE. If this has not already been activated, then first activate it by running:
curl --request POST \
--url http://<RPC_ENDPOINT_IP_PORT>/v1/producer/schedule_protocol_feature_activations \
-d '{"protocol_features_to_activate": ["0ec7e080177b2c02b278d5088611686b49d739925a92d9bfcacd7fc6b74053bd"]}'- Install eosio.boot system contract
Activating other protocol features requires a privileged contract to call the appropriate host function to pre-activate the protocol feature. If the contract deployed on the eosio account already has an activate action, you will likely be able to skip this step and just use that action in the next step.
If you do not have any contract deployed on the eosio account, as would be the case for a new blockchain, then you are recommended to deploy the system smart contract eosio.boot to the eosio account. To do this, run:
./cleos set contract eosio <EOS_SYSTEM_CONTRACTS_DIRECTORY>/contracts/eosio.boot/ eosio.boot.wasm eosio.boot.abi- Activate remaining protocol features
Call the activate action on the contract deployed on the eosio account with a protocol feature's digest as an input to activate that protocol feature. Repeat this in the appropriate order for as many protocol features you wish to activate.
To get the a list of the digests of protocol features, run
curl -X POST http://<RPC_ENDPOINT_IP_PORT>/v1/producer/get_supported_protocol_features | jq .and then look for feature_digest field for each protocol feature.
New protocol features introduced in versions 3.0 and 3.1 do not have dependencies on other protocol features or each other. You can use any order to activate them. For example:
# ACTION_RETURN_VALUE
./cleos push action eosio activate '["c3a6138c5061cf291310887c0b5c71fcaffeab90d5deb50d3b9e687cead45071"]' -p eosio
# CONFIGURABLE_WASM_LIMITS2
./cleos push action eosio activate '["d528b9f6e9693f45ed277af93474fd473ce7d831dae2180cca35d907bd10cb40"]' -p eosio
# BLOCKCHAIN_PARAMETERS
./cleos push action eosio activate '["5443fcf88330c586bc0e5f3dee10e7f63c76c00249c87fe4fbf7f38c082006b4"]' -p eosio
# GET_CODE_HASH
./cleos push action eosio activate '["bcd2a26394b36614fd4894241d3c451ab0f6fd110958c3423073621a70826e99"]' -p eosio
# CRYPTO_PRIMITIVES
./cleos push action eosio activate '["6bcb40a24e49c26d0a60513b6aeb8551d264e4717f306b81a37a5afb3b47cedc"]' -p eosio
# GET_BLOCK_NUM
./cleos push action eosio activate '["35c2186cc36f7bb4aeaf4487b36e57039ccf45a9136aa856a5d569ecca55ef2b"]' -p eosioDeprecations, removals, and dropped support
Dropped support
Ubuntu 16.04, Centos, and macOS
The only officially supported platforms are Ubuntu 18.04, 20.04 and 22.04. All others have been removed from binary package support and/or code level changes.
Developers using cleos, nodeos, etc. should look at DUNE which supports Windows 10 and 11, macOS, and any Linux that supports Docker.
Further details on changes since last release
Contributors
Special thanks to the contributors that submitted patches for this release:
- @heifner
- @766C6164
- @Lin2931
- @arhag
- @spoonincode
- @ClaytonCalabrese
Full list of changes since last release
PRs
- (mandel#791) [3.1] Reduce net_plugin handshake messages in case of unavailable blocks
- (mandel#807) [3.1] Added file package to the list of installable packages
- (mandel#809) [3.1] Increase default transaction-retry-max-expiration-sec from 90 to 120
- (2) Remove mandel and https://github.com/eosnetworkfoundation references in leap
- (4) bump wasm-spec-tests to latest antelope-main
- (5) Remove leap from deep-mind version logging; bump eos-vm and wasm-spec-tests versions
- (7) bump abieos to latest antelope-3.1
- (8) Migrate CI to ENF runners & new platform framework
- (9) fix package CONFLICTS
- (10) Update appbase submodule
- (12) change art to 🅻🅴🅰:parking:
- (11) [3.1] Antelope rename changes
Full Changelog: f63346e...v3.1.0-rc4