Leap v5.0.3

This release enhances the stability, compatibility, and performance of Leap.

Key updates include restoring snapshot scheduler behavior for better backward compatibility, improving deserialization processes, updating cryptographic libraries, and fixing issues in peer-to-peer (P2P) block reporting.

Notable Changes

• Improved Sync Reliability: Fixed the P2P module to correctly report the IDs of known pending blocks. (#2401)
• Improved Deserialization: Limit the vector size that can be reserved when deserializing to prevent errors when handling large data structures. (#2405)
• Better Backwards Compatibility: Treated end_block_num=0 as "forever" in the snapshot scheduler to restore compatibility with Leap 4.0 behavior. (#2402)
• Improved Data Retrieval Accuracy: Corrected the true_lowest() index to resolve issues with some secondary table row RPC queries. (#2403)
• Cryptographic Library Updates: Updated to the latest BLS12-381 library versions with clearer conversion parameters, enhancing cryptographic performance and compatibility. (#2391, #2372)

Complete Change Log

Snapshots

• Treat a end_block_num=0 as "forever" in snapshot scheduler for compatibility with leap 4.0 behavior.

P2P

• P2P to correctly report id of know pending blocks.

Chain-Plugin

• Restore failure trace to compute_transaction.

Logging

• More verbose error reporting on snapshot load exceptions.

Internals

• Update eos-vm submodule for improved exception handling.
• Improve deserialization by limiting vector size that can be reserved, prevent erroring out for large data structures.
• Fix true_lowest() index to possibly resolve some secondary table row RPC queries.
• Clean up unhelpful GS register error.
• Fix minor misspellings.
• Update to latest BLS12-381.
• Update to latest version of BLS12 submodule with clearer conversion parameters.
• Cleanup usage of stack variables in producer api plugin.

Test

• Fix tests to use IPv4 for loopback.

Contributors

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

• @spoonincode
• @heifner
• @greg7mdp

Leap v5.0.2

Leap v5.0.2 is a patch release which fixes a long standing (but recently discovered) issue in trace api wherein some blocks cannot be deserialized. For nodes that are not running trace api there is no need to upgrade.

Nodes that run trace api should upgrade to avoid errors in some calls to /v1/trace_api/get_block.

Leap v5.0.2 Release Notes

Significant Changes

Corrected Return Value Conversion via ABI in TraceAPI

In this release, we made changes to ensure the accurate conversion of return values via ABI within the TraceAPI.

Prior to this update, there were instances where the conversion process was not handled correctly, leading to potential crashes, particularly observed in the _binary_to_variant function under specific conditions. The root cause of the problem stemmed from incomplete handling of action return value conversion by ABI, particularly when an action return value ABI was not readily available. Consequently, attempts to perform such conversions could result in erroneous outcomes, manifesting as crashes or unexpected behavior, especially evident in scenarios where binary to variant conversion was attempted.

Following the implementation of this fix, the TraceAPI module now correctly handles the conversion of return values via ABI. Specifically, action return values are converted using the appropriate ABI, with conversion attempts being made only when a valid action return value ABI is available. This ensures a more stable and reliable behavior, mitigating the risk of crashes or unexpected outcomes previously associated with return value conversion.

Contributors

• @ericpassmore
• @heifner
• @spoonincode

Full PR List

• Bump version for bug fix release
• Correctly convert return value via ABI in TraceAPI
• Improve http plugin unit tests by avoiding dangling listeners

Leap v4.0.6

Leap v4.0.6 is a patch release which fixes a long standing (but recently discovered) issue in trace api wherein some blocks cannot be deserialized. For nodes that are not running trace api there is no need to upgrade.

Nodes that run trace api should upgrade to avoid errors in some calls to /v1/trace_api/get_block.

Leap v4.0.5 Release Notes

Significant Changes

Use 503 instead of 429 response code for exceeding request limits

When https request limits are exceeded (http-max-bytes-in-flight-mb or http-max-in-flight-requests), an HTTP response code is returned. Prior to this change, 429 was the response code returned in these cases.

HTTP response codes in the 4xx range denote errors caused by client behavior, while the 5xx range denote errors on the server side. As the cause of these errors is that the server exceeds its configured resource quota, a 5xx error is most descriptive.

By using semantically correct HTTP response codes, clients & proxies can better react (failover for example).

Corrected Return Value Conversion via ABI in TraceAPI

In this release, we made changes to ensure the accurate conversion of return values via ABI within the TraceAPI.

Prior to this update, there were instances where the conversion process was not handled correctly, leading to potential crashes, particularly observed in the _binary_to_variant function under specific conditions. The root cause of the problem stemmed from incomplete handling of action return value conversion by ABI, particularly when an action return value ABI was not readily available. Consequently, attempts to perform such conversions could result in erroneous outcomes, manifesting as crashes or unexpected behavior, especially evident in scenarios where binary to variant conversion was attempted.

Following the implementation of this fix, the TraceAPI module now correctly handles the conversion of return values via ABI. Specifically, action return values are converted using the appropriate ABI, with conversion attempts being made only when a valid action return value ABI is available. This ensures a more stable and reliable behavior, mitigating the risk of crashes or unexpected outcomes previously associated with return value conversion.

Contributors

• @ericpassmore
• @heifner
• @spoonincode

Full PR List

• Bump version for bug fix release
• Correctly convert return value via ABI in TraceAPI
• Update HTTP response codes for exceeding request limits

Leap v3.2.6

Leap v3.2.6 is a patch release which fixes a long standing (but recently discovered) issue in trace api wherein some blocks cannot be deserialized. For nodes that are not running trace api there is no need to upgrade.

Nodes that run trace api should upgrade to avoid errors in some calls to /v1/trace_api/get_block.

Leap v3.2.6 Release Notes

Significant Changes

Corrected Return Value Conversion via ABI in TraceAPI

In this release, we made changes to ensure the accurate conversion of return values via ABI within the TraceAPI.

Prior to this update, there were instances where the conversion process was not handled correctly, leading to potential crashes, particularly observed in the _binary_to_variant function under specific conditions. The root cause of the problem stemmed from incomplete handling of action return value conversion by ABI, particularly when an action return value ABI was not readily available. Consequently, attempts to perform such conversions could result in erroneous outcomes, manifesting as crashes or unexpected behavior, especially evident in scenarios where binary to variant conversion was attempted.

Following the implementation of this fix, the TraceAPI module now correctly handles the conversion of return values via ABI. Specifically, action return values are converted using the appropriate ABI, with conversion attempts being made only when a valid action return value ABI is available. This ensures a more stable and reliable behavior, mitigating the risk of crashes or unexpected outcomes previously associated with return value conversion.

Use 503 instead of 429 response code for exceeding request limits

When https request limits are exceeded (http-max-bytes-in-flight-mb or http-max-in-flight-requests), an HTTP response code is returned. Prior to this change, 429 was the response code returned in these cases.

HTTP response codes in the 4xx range denote errors caused by client behavior, while the 5xx range denote errors on the server side. As the cause of these errors is that the server exceeds its configured resource quota, a 5xx error is most descriptive.

By using semantically correct HTTP response codes, clients & proxies can better react (failover for example).

Contributors

• @ericpassmore
• @heifner
• @spoonincode

Full PR List

• Bump version for bug fix release
• Correctly convert return value via ABI in TraceAPI
• Update HTTP response code for exceeding request limits

Leap v5.0.1

At a Glance:

Leap 5.0.1 focuses on enhancing test frameworks, stability improvements, and HTTP protocol adjustments. Some notable achievements with this release include:

• Refined test suite for better reliability and coverage
• Enhanced stability through various bug fixes and improvements
• Improved HTTP protocol handling for better error reporting

Leap 5.0.1 Release Notes

Test Enhancements

Improved Test Suite Organization and Stability

Overview

Benefits

• Enhanced test reliability
• Reduced test flakiness

Achieved by

• Reorganizing socket-related tests
• Disabling subjective limits

Details

The test suite was optimized to reduce flakiness and improve reliability. This was achieved by reorganizing tests that listen on local sockets and disabling subjective limits during test runs to enhance stability.

Related Development

• Reorganize tests that listen on local socket.
• Disable subjective limits in tests for greater stability during test runs.

Stability Improvements

Enhanced Resilience to Network and Configuration Changes

Overview

Benefits

• Improved handling of excessive network traffic
• More robust configuration parsing

Achieved by

• Test coverage for traffic and connections
• Enhanced socket handling
• Updated configuration parsing mechanisms

Details

This release introduces improvements to manage high network traffic and numerous connections, along with more resilient configuration parsing mechanisms. These changes aim to ensure smoother operation through varied operational conditions.

Related Development

• Test coverage for two conditions: excessive network traffic or excessive number of connection.
• Changes to socket handling to improve continuous integration test passes.
• Additional enhancement to configuration parsing and check for chain_api_plugin, updated to search through options to be more resilient to changes in the timing of loading plugins.

HTTP Protocol Adjustments

Updated HTTP Error Codes for Better Clarity

Overview

Benefits

• Clearer error communication

Achieved by

• Changing HTTP error codes for specific limits

Details

Leap 5.0.1 updates the HTTP error codes for conditions where specific limits are exceeded, moving from a 429 to a 503 error code, to provide clearer communication about the nature of the error.

Related Development

• 503 is now the HTTP error return code for exceeding http-max-bytes-in-flight-mb or http-max-in-flight-requests.

Internals and Clean Code

Improvements in Configuration Reporting and Dependency Updates

Overview

Benefits

• Improved error reporting
• Support for large mapped tests

Achieved by

• Clearer help texts and full path reporting
• Updating chainbase version

Details

The release enhances error reporting and configuration management with clearer help texts and full path error reporting for failed operations. Additionally, updates to dependencies like chainbase support new features and fix issues.

Related Development

• Clearer help text for read-only-threads defaults.
• Provide the full path of the snapshot file that can't be renamed if the rename fails.
• Brings in new version of chainbase to support large mapped tests.
• Brings in new version of chainbase to fix issues on macos and linux 6.7.

Full Change Log

• Reorganize tests that listen on local socket
• Test coverage for two conditions excessive network traffic or excessive number of connection
• Changes to socket handling to improve continuous integration test passes
• Disable subjective limits in tests for greater stability during test runs
• Guard against errors when exceeding `http-max-requests-in-flight
• Additional enhancement to configuration parsing and check for chain_api_plugin, updated to search through options to be more resilient to changes in the timing of loading plugins
• Check and switch to lib_catchup when starting to sync
• Revs chainbase version to include a bug fix. Leap will now start up cleanly in non-mapped_private mode after failing to startup in mapped_private mode due to lack of swap and/or physical memory
• Add more robust configuration parsing and enhance check for chain_api_plugin. This change addresses failure to provide read-only transaction when using esoteric config pattern
• Prevent error on shutdown by extending the life of http_plugin_state thereby ensuring no invalid memory accesses
• 503 is now the HTTP error return code for exceeding http-max-bytes-in-flight-mb or http-max-in-flight-requests. Previous code was 429
• Clearer help text for read-only-threads defaults
• Provide the full path of the snapshot file that can't be renamed if the rename fails
• Now report read-only API not enabled to caller, when read-only-threads is not configured
• Brings in new version of chainbase to support large mapped tests
• Brings in new version of chainbase to fix issues on macos and linux 6.7

Leap v5.0.0

The Leap v5.0.0 stable release introduces several exciting enhancements and addresses a security issue.

📝	This release includes a change to base64 encoding that is incompatible with versions of leap prior to 3.2.5.For more details, see PR 1888.

At a Glance:

Leap v5.0.0 is designed to be more performant, efficient, and reliable. Some notable achievements with this release include:

• Up to 5x faster execution of system contracts (including EOS EVM)
• Up to 4X speed improvement and more reliable atomic API calls with non-blocking serialization
• Up to 20% reduction in system memory consumption by state database
• High scale read-only-transactions with parallel processing up to 128 parallel threads
• Support for larger transactions with relaxed constraints
• More reliable block production by optimizing block start time to reduce latency between rounds
• Customizable endpoints for more control over networking

See the Upgrade Guide for details on required/recommended configuration changes, deprecations and new nodeos options.

Leap v5.0.0 Release Notes

Relaxed Constraints

Larger Transactions

Quick Summary

Benefit

• Increased max transaction to support larger transactions

Achieved by

• Removing max-nonprivileged-inline-action-size
• Increasing default max-transaction-time

Enabled by

• CPU efficiency gained by leveraging EOS VM OC on system contracts

Details

Leap 5 modifies the behavior controlled by two parameters that constrained the execution of smart contracts.

The first parameter is max-nonprivileged-inline-action-size which, while technically configurable, in practice capped the size of inline actions sent by regular contracts to 4 KiB. This parameter has been removed from Leap 5 so that the only constraint on inline action size comes from the objective limit (max_inline_action_size) that is managed on-chain.

Since the objective max_inline_action_size limit is typically higher (it is 512 KiB on EOS), the removal of the max-nonprivileged-inline-action-size unlocks behavior in smart contracts that was previously constrained. For example, on the EOS network, EOS EVM’s new call action could be used to deploy EVM contracts greater in size than 4 KiB from an EOS smart contract.

The second parameter is max-transaction-time which limits the duration a transaction is allowed to execute as measured by wall-clock time. This parameter is not removed from Leap 5 but its default value is changed to instead effectively drive the transaction wall-clock deadline by the objective limit (max_transaction_cpu_usage) that is managed on-chain.

Since the objective max_transaction_cpu_usage limit is typically higher (it is 150 ms on EOS), the change of default value for max-transaction-time allows transactions to do more work within the longer time duration allotted to them. For example, on the EOS network, EOS EVM can take advantage of the relaxed transaction wall-clock deadline to successfully execute more computationally-heavy EVM transactions that may have been rejected previously.

When upgrading to Leap 5+, node operators:

1. MUST ensure the max-nonprivileged-inline-action-size parameter is not in config.ini so nodeos can start.
2. SHOULD remove the max-transaction-time parameter to allow enforcement of the transaction wall-clock deadline to be driven by the objective on-chain limit.

Related Development

• Allow non privileged inline actions larger then 4KiB
• Remove max-nonprivileged-inline-action-size option
• Raise max-transaction-time
• Change default max-transaction-time
• Add eos-vm-oc-enable auto mode

Increased Speed

Improved Read Performance

Quick Summary

Benefits

• High scale read-only-transactions

Achieved by

• Increased max allowed read-only transaction parallelization to 128 threads.

Enabled by

• Making multi-threaded read only transaction processing more memory efficient
• Improved serialization and deserialization
• Reducing contract compile time
• Reducing module cache size

Details

Leap 4 introduced parallel execution for both read only transactions (made by smart contracts) and read only RPC APIs (like get_block_info, get_transaction_id, etc). However, this initial implementation had to restrict the number of read-only threads up to 8 due to large memory usage.

Leap 5 restructures the underlying execution engine EOS VM, reducing memory usage and making parallelism more natural. The limit has been increased up to 128 threads. This unlocks another option for developers. Read-only solutions are a cheap, fast, and easy way to access data, cutting down on the need for additional history solutions and secondary data caches. Combined with natively supported tables and indexing EOS blockchain can be your one and only distributed database.

Related Development

• Collect EOS-VM-OC memory usage from the mainnet
• Reduce EOS VM OC's memory slice count allowing for higher parallelization
• Set EOS VM OC max mirroring pages to a small number for read-only threads
• Use a single WASM interface per nodeos (instead of per thread) to save WASM compile time and cache
• Increase default read-only-threads
• Increase maximum supported number of read-only threads to 128
• Do not create/use/cache execution context per contract
• Update EOS VM to use a single execution context per thread instead of per contract
• Update Leap to use a single execution context per thread instead of per contract
• Reduce EOS VM OC's memory slice count to allow higher parallelization
• Set specific sliced pages for read-only threads in EOS
• Update Leap to parse WASM code only once for JIT
• Store wasm globals in execution context such that a single parsed module can be shared by multiple threads
• Update eos-vm version to make wasm globals thread safe

Non-blocking ABI Serialization

Quick Summary

Benefits

• ~4X speed improvement for ABI intensive requests
• More reliable atomic API calls

Achieved by

• Moving ABI serialization off the main thread
• Updated serialization time constraints

Details

Leap 5 enhances EOS node performance by moving ABI serialization off the main thread and introducing improved time constraints. Most notably, ABI intensive requests (like get_block) are up to 4X faster.

Previously Leap would error out to avoid long running deserialization processes that tie up reasources. In Leap 5.0 this behaviour changes. In Leap 5, when a specific object deserialization takes longer than abi-serializer-max-time-ms, it will be returned in binary form. This applies to requests that return multiple item. This includes get_block, get_account, and get_table_rows.

Related Development

• Move abi serialization of transaction trace off main thread
• Move abi serialization of transaction trace off main thread for chain_plugin: get_table_rows and get_account
• Update API/serialization time constraints

Improved Efficiency

Optimized Block Start Time

Benefits

• Transmits last block of each round more promptly
• Ensures subsequent producers can commence block production on schedule

Achieved by

• releasing produced blocks immediately without idle time.

Details

Leap v5.0.0 includes changes to the Leap Producer Plugin aimed at optimizing block start and release timings. The updates are designed to maximize transaction throughput while minimizing latency, delayed block starts, and other inefficiencies by introducing a more dynamic and efficient block production strategy.

Prior to this update, the block production was strictly timed to the config::block_interval_us (e.g., 500 ms), with a designated cpu-effort-percent (e.g., 80%), resulting in a mandatory idle time between block productions. This rigid schedule often led to delayed starts for subsequent blocks and underutilized CPU time.

The update introduces a new configuration parameter, produce-block-offset-ms, which dictates the time reserved at the end of a 12-block production round for the last block to reach the next producer. This parameter can be set to more than 500 milliseconds if necessary, allowing greater flexibility in block production timing. The new system calculates the early release of each block in a round, adjusting the production timing dynamically based on network conditions and the fullness of each block. This method ensures that blocks are transmitted and validated more efficiently, accommodating network latencies and varying block sizes.

With the new update, blocks are now...

Leap v5.0.0-rc3

Leap 5.0.0-rc3 builds upon the first Leap 5.0 release candidate with important updates to the BLS host functions, as well as bug fixes, and improvements to performance, efficiency, and stability of the Leap software. It also includes a mitigation for a security issue.

📝	This release includes consensus changes from prior 5.0 releases. Node Operators running prior 5.0 release candidates must upgrade.

See the Upgrade Guide for details on required/recommended configuration changes, deprecations and new nodeos options.

Expand the release notes below for an in depth look at the Leap v5.0.0-rc3 release including a summary of important changes, and a complete change log.

Leap v5.0.0-rc3 Release Notes

Security

Mitigation of Potential Denial of Service for Snapshots & SHiP

A security vulnerability has been mitigated, preventing errors in state_history_plugin and snapshot functionality in certain edge case conditions (PR 1964).

Node Operators that depend on snapshots or state_history_plugin with chain-state-history enabled should upgrade. Users running state_history_plugin with only trace-history are not affected.

Compatibility

basee64 encoding compatibility

This release includes a change to base64 encoding that is incompatible with versions of leap prior to 3.2.5.

For more details, see PR 1888.

Enhancements

BLS Updates

Changed host functions and added benchmarking for BLS. (PRs #1882, #1884, #1904, #1938)

BLS Host Function Updates

Added, removed, and changed host functions to require affine and non-Montgomery form and enable additional BLS mathematical operations to be feasibly implemented in WASM such as compressed signature conversion.

Changes to BLS host functions

• Replaced these
  • bls_g1_mul
  • bls_g2_mul
  • bls_g1_exp
  • bls_g2_exp
• With these
  • bls_g1_weighted_sum
  • bls_g2_weighted_sum
• Added these (which make it feasible to implement more operations in WASM such as converting from compressed encodings of public keys and signatures to the affine form required for use with the host functions)
  • bls_fp_mul
  • bls_fp_exp
• BLS host functions originally expected and returned points in Jacobian and Mongtomery form. They now expect and return points in affine and non-Montgomery form.

BLS Benchmarking

Add benchmarking of BLS host functions into Leap Benchmark suites. Use benchmark/benchmark -f bls to benchmark.

A sample result looks like

function                                runs        average       minimum       maximum

bls:
bls_g1_add                              5,000      76,699 ns      75,622 ns     123,329 ns
bls_g2_add                              5,000      82,521 ns      81,196 ns     131,229 ns
bls_pairing 1 pair                      5,000   1,638,763 ns   1,557,463 ns   3,569,653 ns
bls_pairing 3 pairs                     5,000   2,321,344 ns   2,232,847 ns   3,740,820 ns
bls_g1_weighted_sum 1 point             5,000     260,683 ns     258,196 ns     328,138 ns
bls_g1_weighted_sum 3 points            5,000     670,546 ns     661,700 ns   2,038,831 ns
bls_g1_weighted_sum 5 points            5,000     817,884 ns     808,866 ns   2,200,022 ns
bls_g2_weighted_sum 1 point             5,000     818,862 ns     794,358 ns   2,368,434 ns
bls_g2_weighted_sum 3 points            5,000   2,338,746 ns   2,285,345 ns   4,072,288 ns
bls_g2_weighted_sum 5 points            5,000   2,924,081 ns   2,845,713 ns  22,833,113 ns
bls_g1_map                              5,000     379,593 ns     372,223 ns     566,554 ns
bls_g2_map                              5,000     531,899 ns     522,480 ns     722,943 ns
bls_fp_mod                              5,000         794 ns         703 ns       9,219 ns
bls_fp_mul                              5,000         692 ns         621 ns       7,913 ns
bls_fp_exp                              5,000      32,397 ns      31,702 ns      43,478 ns

Updated Protocol Feature

Renamed BLS_PRIMITIVES to BLS_PRIMITIVES2 to make explicit that there is a breaking change in the interface and behavior of the BLS host functions enabled by the BLS_PRIMITIVES2 protocol feature compared to the BLS_PRIMITIVES protocol feature that was added in v5.0.0-rc2.

Replace cpu-effort-percent with produce-block-offset-ms

5.0.0-rc3 builds upon changes we made in rc2 to optimize block start time but replaces the existing config parameter expressed in miliseconds instead of a percentage.

Specifically, we have replaced the cpu-effort-percent configuration parameter with produce-block-offset-ms, which now specifies the amount of time to leave at the end of the 12-block production round for the last block to reach the next block producer. This value can be configured to be larger than 500 milliseconds if necessary.

See PR 1800 for complete details on the change. BP Documentation has been updated.

Only return wasm config settings if configurable wasm limits enabled

Before this change, these wasm config settings were included in the response regardless of the protocol features in use. However, it has been recognized that these settings are only valid and relevant when the CONFIGURABLE_WASM_LIMITS2 protocol feature is active.

With this update, a change has been made to the behavior of the /v1/chain/get_consensus_parameters endpoint. The wasm config settings, which include various parameters related to WebAssembly execution, will now only be returned if the protocol feature CONFIGURABLE_WASM_LIMITS2 is enabled.

This modification ensures that clients requesting consensus parameters receive only the information that is applicable to the current protocol configuration, making the responses more accurate and relevant.

For complete details on this change see PR 1770.

Prometheus Enhancements

Added stable identifiers for P2P connections and ensured valid unique_conn_node_id. (PRs #1750, #1879).

Stable Identifiers

Improved identification in prometheus_plugin by using node_id as a stable identifier for P2P connections, addressing the issue of changing identifiers with each disconnect and reconnect. This enhancement, implemented in PR #1750, resolves the challenge outlined in Issue #1683 of tracking consistent metrics in nodeos_p2p_connections.

Ensure Valid Connection ID

Ensured the presence of a valid and unique connection ID for Prometheus metrics, as detailed in PR #1879. This update addresses Issue #1871, which highlighted the inefficiency of stats displayed without connection IDs, and now temporarily assigns an ID until an established connection is confirmed.

Performance & Efficiency Improvements

• VM and ABI Serializer Performance: Various improvements to ABI serializer performance. (PRs #1770, #1773, #1792, #1922)
• Chainbase Performance Improvement: Notable enhancements in performance. (PR #1772)
• Snapshot Scheduler Test: Refactored threading for better efficiency. (PR #1821)
• P2P Network Improvements: Several updates including fixes for throttling issues and improvements in sync window management. (PRs #1791, #1811)

Stability Improvements

• Resource Monitor Plugin: Hardened shutdown handling and made tests deterministic. (PRs #1774, #1783, #1826)

Bug Fixes

• Compiler Warnings and Errors: Addressed various compiler warnings and errors to ensure a clean build. (PRs #1752, #1836)
• Test Fixes: Various fixes in tests to avoid deadlocks and improve reliability. (PRs #1766, #1818, #1905)
• Chainbase and EOS VM OC Fixes: Resolved issues with Chainbase database size and EOS VM OC's subjective compilation limits. (PRs #1827, #1843, #1877)
• PH Reliability and Error Handling: Improved error handling and reliability in PH. (PRs #1814, #1866)
• Miscellaneous Fixes: Various other fixes including those for base64 encoding and contract exceptions. (PRs #1886, #1888, #1889, #1901, #1903)

Operational Improvements

• CICD: Enhanced branch protection and integration with CI Build & Test workflow for more stable builds. (PRs #1753, #1710, #1797, #1867)

Deprecations & Removals

Deferred Transactions Removed

Deferred Transactions were previously deprecated and have been removed. No new deferred transactions may be created. Existing deferred transactions, will be blocked from executing.

Get Block Header State Deprecated

As of Leap v5.0.0 v1/chain/get_block_header_state is deprecated. It will be removed in Leap v6.0.0.

Documentation Updates

• Updated tutorial readme to reflect the latest changes. (PR #1810)

Change Log

Pull Requests

• [5.0] fix "All Required Tests Passed" CI Branch Protection by @spoonincode in #1753
• [5.0] Fix compiler warning by @heifner in #1752
• [5.0] Prometheus: Add stable identifier for P2P connections by @heifner in #1750
• [5.0] Test: read-only trxs should only be posted to read_exclusive queue by @heifner in #1766
• [4.0 -> 5.0] Only return ...

Leap v4.0.5

Leap v4.0.5 is a patch release containing a security update and an important change to ensure encoding compatibility between API nodes across multiple versions of Leap.

📝	Node Operators that depend on snapshots or state_history_plugin with chain-state-history enabled should upgrade. Users running state_history_plugin with only trace-history are not affected.

📝	This release fixes cleos interoperability with nodeos 5.0

Expand the release notes below for an in depth look at the Leap v4.0.5 release including a summary of important changes, and a complete change log.

Leap v4.0.5 Release Notes

Important Updates

Mitigation of Potential Denial of Service to Snapshots & SHiP

A security vulnerability has been mitigated, preventing errors in state_history_plugin and snapshot functionality in certain edge case conditions (PR 1964).

Node Operators that depend on snapshots or state_history_plugin with chain-state-history enabled should upgrade. Users running state_history_plugin with only trace-history are not affected.

Cleos compatibility with nodeos 5.0 and later

This release fixes cleos interoperability with nodeos 5.0.

Other Changes

Block Processing

Improved Block Time Reporting: Enhanced log statements for block time reporting (PR #1434).

Validating Accepted Blocks: Enhanced process to signal accepted_block after validation (PR #1769).

Connection Handling

HTTP Connection Error Handling: Ignored HTTP error in remote_endpoint() to prevent termination (PR #1453).

HTTP Connection Reset Check: Added checks for connection_reset (PR #1663).

Shutdown Handling

Improved shutdown handling for the resource monitor manager plugin (PR #1774).

Error Handling

Trace API Plugin (trace_api_plugin) Enhancement: Modified to report serialization errors to users (PR #1468).

EOS VM OC Code Cache Recreation: Added functionality to recreate EOS VM OC code cache if it becomes corrupt (PR #1780).

Bug Fixes

SHiP (state_history_plugin) Improvements

Fixed issues including stack overflow, invalid index, and split file access (PR #1779).

Ensured appending to index file is correctly handled (PR #1801).

Fix read/write switching segfault

Fixed a potential segfault when switching between read/write processing windows/modes (PR #1719).

Fix cleos setcode and setabi

Resolved issues with non-working cleos set code and set abi commands (PR #1900).

Other Changes

Return WASM configuration settings only when enabled (PR #1770).

WASM configuration settings are now only returned when the "CONFIGURABLE_WASM_LIMITS2" protocol feature is enabled. This change reduces confusion and potential errors.

Change Log

Pull Requests

• [4.0] Fix block time reporting log statement by @heifner in #1434
• [3.2 -> 4.0] Ignore http error on remote_endpoint() causing terminate by @heifner in #1453
• [3.2 -> 4.0] Modify trace_api_plugin to report serialization errors to user by @heifner in #1468
• [4.0] HTTP: Check for connection_reset by @heifner in #1663
• [4.0] Fix possible segfault switching between read/write windows by @heifner in #1719
• [4.0] Only return wasm config settings if configurable wasm limits enabled by @heifner in #1770
• [4.0] Signal accepted_block after it is marked valid by @heifner in #1769
• [4.0] hardening resource monitor manager plugin shutdown handling by @linh2931 in #1774
• [4.0] Recreate EOS VM OC code cache if corrupt by @heifner in #1780
• [4.0] SHiP: Fixes: Stack overflow, invalid index, split file access by @heifner in #1779
• [4.0] SHiP: Make sure we append to index file by @heifner in #1801
• [3.2 -> 4.0] Do not require trailing = for base64 encoded strings by @heifner in #1892
• [3.2 -> 4.0] Fix non-working cleos set code and set abi commands by @linh2931 in #1900
• [3.2 -> 4.0] consolidated security fixes for 4.0.5 by @spoonincode in #1964
• [4.0] bump version to 4.0.5 by @spoonincode in #1965

Contributors

• @heifner
• @linh2931
• @spoonincode

Full Changelog: v4.0.4...v4.0.5

Leap v3.2.5

Leap v3.2.5 is a patch release containing a security update and an important change to ensure encoding compatibility between API nodes across multiple versions of Leap.

📝	Node Operators that depend on snapshots or state_history_plugin with chain-state-history enabled should upgrade. Users running state_history_plugin with only trace-history are not affected.

📝	This release fixes cleos interoperability with nodeos 5.0

Expand the release notes below for an in depth look at the Leap v3.2.5 release including a summary of important changes, and a complete change log.

Leap v3.2.5 Release Notes

Important Updates

Mitigation of Potential Denial of Service to Snapshots & SHiP

A security vulnerability has been mitigated, preventing errors in state_history_plugin and snapshot functionality in certain edge case conditions (PR 1961).

Node Operators that depend on snapshots or state_history_plugin with chain-state-history enabled should upgrade. Users running state_history_plugin with only trace-history are not affected.

Cleos compatibility with nodeos 5.0 and later

This release fixes cleos interoperability with nodeos 5.0.

Other Changes

Connection Handling

HTTP Connection Error Handling: Ignored HTTP error in remote_endpoint() to prevent termination (PR #1452).

Error Handling

Trace API Plugin (trace_api_plugin) Enhancement: Modified to report serialization errors to users (PR #1449).

Bug Fixes

Fix cleos setcode and setabi

Resolved issues with non-working cleos set code and set abi commands (PR #1897).

Change Log

Pull Requests

• [3.2] Ignore http error on remote_endpoint() causing terminate by @heifner in #1452
• [3.2] Modify trace_api_plugin to report serialization errors to user by @heifner in #1449
• [3.2] Do not require trailing = for base64 encoded strings by @heifner in #1889
• [3.2] Fix non-working cleos set code and set abi commands by @linh2931 in #1897
• [3.2] consolidated security fixes for 3.2.5 by @spoonincode in #1961
• [3.2] bump version to 3.2.5 by @spoonincode in #1962

Contributors

• @heifner
• @linh2931
• @spoonincode

Full Changelog: v3.2.4...v3.2.5

Leap v5.0.0-rc2

The Leap v5.0.0 Release introduces several exciting enhancements. This release is focused around four key themes: relaxed constraints, increased speed, improved efficiency, and enhanced control.

📝	v5.0.0-rc2 is the first release candidate of 5.0.0 due to an issue discovered in a tagged but not released 5.0.0-rc1.

See the Upgrade Guide for details on required/recommended configuration changes, deprecations and new nodeos options.

Notable Changes at a Glance:

Added

• New default option to automatically apply EOS VM OC to reduce system CPU
• New Peer to Peer configuration options
• New Peer-level Prometheus metrics
• New BLS12-381 elliptic curve crypto primitives

Improved

• Relaxed constraints allow for larger transactions
• Sync latency optimization
• Node memory and multithreading improvements
• New mode for managing state database memory

Removed

• Deferred Transactions

Continue reading for an in depth look at the features of Leap v5.0.0. A complete change log is included at the bottom of these release notes.

Leap v5.0.0-rc2 Release Notes

Relaxed Constraints

Larger Transactions

Quick Summary

Benefit

• Increased max transaction to support larger transactions

Achieved by

• Removing max-nonprivileged-inline-action-size
• Increasing default max-transaction-time

Enabled by

• CPU efficiency gained by leveraging EOS VM OC on system contracts

Details

Leap 5 modifies the behavior controlled by two parameters that constrained the execution of smart contracts.

The first parameter is max-nonprivileged-inline-action-size which, while technically configurable, in practice capped the size of inline actions sent by regular contracts to 4 KiB. This parameter has been removed from Leap 5 so that the only constraint on inline action size comes from the objective limit (max_inline_action_size) that is managed on-chain.

Since the objective max_inline_action_size limit is typically higher (it is 512 KiB on EOS), the removal of the max-nonprivileged-inline-action-size unlocks behavior in smart contracts that was previously constrained. For example, on the EOS network, EOS EVM’s new call action could be used to deploy EVM contracts greater in size than 4 KiB from an EOS smart contract.

The second parameter is max-transaction-time which limits the duration a transaction is allowed to execute as measured by wall-clock time. This parameter is not removed from Leap 5 but its default value is changed to instead effectively drive the transaction wall-clock deadline by the objective limit (max_transaction_cpu_usage) that is managed on-chain.

Since the objective max_transaction_cpu_usage limit is typically higher (it is 150 ms on EOS), the change of default value for max-transaction-time allows transactions to do more work within the longer time duration allotted to them. For example, on the EOS network, EOS EVM can take advantage of the relaxed transaction wall-clock deadline to successfully execute more computationally-heavy EVM transactions that may have been rejected previously.

When upgrading to Leap 5+, node operators:

1. MUST ensure the max-nonprivileged-inline-action-size parameter is not in config.ini so nodeos can start.
2. SHOULD remove the max-transaction-time parameter to allow enforcement of the transaction wall-clock deadline to be driven by the objective on-chain limit.

Related Development

• Allow non privileged inline actions larger then 4KiB
• Remove max-nonprivileged-inline-action-size option
• Raise max-transaction-time
• Change default max-transaction-time
• Add eos-vm-oc-enable auto mode

Increased Speed

Improved Read Performance

Quick Summary

Benefits

• High scale read-only-transactions

Achieved by

• Increased max allowed read-only transaction parallelization to 128 threads.

Enabled by

• Making multi-threaded read only transaction processing more memory efficient
• Improved serialization and deserialization
• Reducing contract compile time
• Reducing module cache size

Details

Leap 4 introduced parallel execution for both read only transactions (made by smart contracts) and read only RPC APIs (like get_block_info, get_transaction_id, etc). However, this initial implementation had to restrict the number of read-only threads up to 8 due to large memory usage.

Leap 5 restructures the underlying execution engine EOS VM, reducing memory usage and making parallelism more natural. The limit has been increased up to 128 threads. This unlocks another option for developers. Read-only solutions are a cheap, fast, and easy way to access data, cutting down on the need for additional history solutions and secondary data caches. Combined with natively supported tables and indexing EOS blockchain can be your one and only distributed database.

Related Development

• Collect EOS-VM-OC memory usage from the mainnet
• Reduce EOS VM OC's memory slice count allowing for higher parallelization
• Set EOS VM OC max mirroring pages to a small number for read-only threads
• Use a single WASM interface per nodeos (instead of per thread) to save WASM compile time and cache
• Increase default read-only-threads
• Increase maximum supported number of read-only threads to 128
• Do not create/use/cache execution context per contract
• Update EOS VM to use a single execution context per thread instead of per contract
• Update Leap to use a single execution context per thread instead of per contract
• Reduce EOS VM OC's memory slice count to allow higher parallelization
• Set specific sliced pages for read-only threads in EOS
• Update Leap to parse WASM code only once for JIT
• Store wasm globals in execution context such that a single parsed module can be shared by multiple threads
• Update eos-vm version to make wasm globals thread safe

Non-blocking ABI Serialization

Quick Summary

Benefits

• ~4X speed improvement for ABI intensive requests
• More reliable atomic API calls

Achieved by

• Moving ABI serialization off the main thread
• Updated serialization time constraints

Details

Leap 5 enhances EOS node performance by moving ABI serialization off the main thread and introducing improved time constraints. Most notably, ABI intensive requests (like get_block) are up to 4X faster.

Previously Leap would error out to avoid long running deserialization processes that tie up reasources. In Leap 5.0 this behaviour changes. In Leap 5, when a specific object deserialization takes longer than abi-serializer-max-time-ms, it will be returned in binary form. This applies to requests that return multiple item. This includes get_block, get_account, and get_table_rows.

Related Development

• Move abi serialization of transaction trace off main thread
• Move abi serialization of transaction trace off main thread for chain_plugin: get_table_rows and get_account
• Update API/serialization time constraints

Improved Efficiency

Asynchronous Block Fetching

Benefits

• Simultaneously fetch and apply blocks

Achieved By

• Continuing to sync the next sync-fetch-span while applying the current blocks

Details

With Leap 5, nodeos now pulls downs new blocks independantly of block processing, allowing seemless and continuous processing of blocks

Related Development

• P2P sync ahead while applying received blocks

P2P Latency Optimizations

Benefits

• Minimize latency for sync
• Simultaneously fetch and apply blocks

Achieved By

• Adding new p2p options and changing defaults
• Tracking peer latency and prioritizing lowest latency peers for sync

Details

Leap 5 enables node operators to sync more efficiently. Peer Latency Tracking prioritizes peers with the lowest latency for faster and more reliable sync. Block Buffering ensures maximum CPU utilization by fetching the next block batch while applying the current one.

Smarter block deadlines optimize transactions scheduled in a block to reduce micro-forking. In previous Leap versions, speculative transaction would be queued up until a new block arrives, causing stale or aborted blocks and unnecessarily delaying read-only transaction. In Leap v5.0.0 speculative blocks scheduling is optimized to prevent unneeded block aborts, and increase liveliness of transactions.

Summary of changes

• Added new option (sync-peer-limit) to limit the number of peers to sync from (default 3).
• Added block range to notice messages to optimize peer choice.
• Modified latency calculation based on round trip of `time_m...