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:

• CLI11 command-line parsing library with autocompletion
• eosio-blocklog full functionality via sub-command block-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

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 4

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

1. Find supported protocol features

$ cleos get supported_protocol_features

ONLY_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

1. Activate a protocol feature

$ cleos system activate WTMSIG_BLOCK_SIGNATURES

executed 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

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 <signature> option which allows adding additional signatures to a transaction. Repeat option to specify multiple signatures. Example:

$ cleos push transaction -s transaction_json_not_signed.txt --signature SIG_K1_K5vfhnCSPCppSw3sWTPWj7LVf39vxhEZssHsKBrWpgrufE71M1GUvD2Ujt7QxVEWeQnYTkmr3nkHPhkbYgpT1J7Aa56bav

cleos --compression option for transactions

A new --compression option has been added to cleos for all transaction commands.

  --compression ENUM:value in {none->0,zlib->1} OR {0,1}
                              Compression for transaction 'none' or 'zlib'

cleos option to unpack data when forming transaction

Added new cleos option --unpack-action-data which can be used alongside the existing --dont-broadcast option to expand the transaction action data section of JSON.

Limit requests to http_plugin

The http-max-in-flight-requests option has been added to the http_plugin. It restricts the maximum number of concurrent requests. If limit is exceeded, it sends a HTTP 429 error to the client. --http-max-in-flight-requests = -1 disables the restriction allowing unlimited concurrent requests.

eosio-blocklog –extract-blocks option

There is now an --extract-blocks option to the eosio-blocklog tool, along with an accompanying --output-dir option. This option extracts the range of blocks specified by the -f or --first block option and the -l or --last block option and writes a new block log with accompanying index file to the directory specified by the --output-dir option. At least one of --first or --last must be specified.

This new functionality has also been included within the block-log sub-command within the new leap-util program.

Option to run with no block log

The block-log-retain-blocks option has been modified to allow being set to 0, which tells nodeos not to generate blocks.log.

Now the block-log-retain-blocks option description looks like:

--block-log-retain-blocks arg         If set to greater than 0, periodically
                                       prune the block log to store only
                                       configured number of most recent
                                       blocks.
                                       If set to 0, no blocks are be written
                                       to the block log; block log file is
                                       removed after startup.

Basic crypto primitives benchmarking framework

There is now a benchmarking framework to help with writing benchmarking code by reusing common measuring functions and unifying reports.

For end users

A few examples of usage of the benchmarking tool are provided below.

Help

$ benchmark -h

benchmark command line options:
  -m [ --module ] arg       the module to be benchmarked; if this option is not
                            present, all modules are benchmarked.
  -l [ --list ]             list of supported modules
  -r [ --runs ] arg (=1000) the number of runs per function
  -h [ --help ]             execute the benchmarked functions for the specified
                            number of times, and report average, minimum, and
                            maximum time in nanoseconds

Benchmarking All Modules (functions)

$ benchmark

function                      runs               avg              min              max

alt_bn_128:
alt_bn128_add                 1,000         6,467 ns         3,727 ns       113,625 ns
alt_bn128_mul                 1,000       251,105 ns       235,337 ns       395,856 ns
alt_bn128_pair (1 pair)       1,000     6,405,913 ns     6,354,466 ns     8,265,015 ns
alt_bn128_pair (10 pairs)     1,000    25,379,638 ns    25,236,388 ns    36,013,377 ns

modexp:
1024-bit width                1,000       389,252 ns       388,298 ns       396,263 ns
2048-bit width                1,000     2,914,494 ns     2,910,697 ns     2,999,909 ns

Benchmarking Particular Module with Specific Number of Runs

$ benchmark -m modexp -r 500

function                      runs               avg              min              max

modexp:
1024-bit width                500         441,057 ns       388,091 ns       818,064 ns
2048-bit width                500       2,914,402 ns     2,911,318 ns     3,001,094 ns

For developers

The following steps illustrate how to add code to benchmark new functions, using alt_bn_128 functions as an example.

1. Determine functions to be benchmarked: alt_bn128_add, alt_bn128_mul, and alt_bn128_pair.
2. Create a file alt_bn_128.cpp inside <leap-repo>/benchmaking directory. A skeleton of the file looks like:

  void add_benchmarking() {
    ...
  }
 
  void mul_benchmarking() {
     ...
  }
 
  void pair_benchmarking() {
    ...
  }
 
  void alt_bn_128_benchmarking() {
     add_benchmarking();
     mul_benchmarking();
     pair_benchmarking();
  } 

1. For each benchmarked function, define a lambda to call the function and use benchmarking to link it to the framework. The following code segment shows how to benchmark fc::alt_bn128_add:

   void add_benchmarking() {
      bytes point1, point2;
      // initialization of point1 and point2 are omitted
      
      auto f = [&]() {
         fc::alt_bn128_add(point1, point2);
      }
      
      benchmarking("alt_bn128_add", f);
   }

1. Add void alt_bn_128_benchmarking(); to benchmark/benchmark.hpp
2. Add { "alt_bn_128", alt_bn_128_benchmarking } to features (a map) in benchmark.cpp:

   std::map<std::string, std::function<void()>> features {
      { "alt_bn_128", alt_bn_128_benchmarking },
      { "modexp", modexp_benchmarking },
      ...
   }

Additional CPU/NET usage data within get_account results

Added last_updated_time_stamp and current_used (according to the head block timestamp) to get_account RPC results.

The addition of the last_updated_time_stamp value in the result enables a client to calculate in real-time what the current value of the used would be if it were to be refreshed to account for the continuous decay in the used amount; note that the refreshed value is what is relevant for determining how much CPU or NET resources an account has available to use in a new transaction. Clients that put in the effort to calculate the updated values for their users can help alleviate confusion in users who mistakenly believe their account has still used up all of their available CPU despite the fact that their account has been inactive for more than 24 hours.

The current_used value is added as a convenience to the client since it holds the resulting value if this refresh calculation was carried out using the head block time at the moment the RPC request was processed by nodeos.

Note:

Versions of cleos prior to this release normally display the same info as was done previously regardless of whether they make an RPC call to an old or new version of nodeos. But if they make the call to a version of nodeos including the changes of this release, the JSON output for cleos get account -j will additionally contain the two new fields for both the CPU and NET resources of the account.

The version of cleos that is part of this release will display different data for the cleos get account sub-command than it has in previous versions. If the RPC call goes to a new version of nodeos, then the value displayed after used: will now be the current_used value rather than the used value (the original used value still remains accessible in the JSON output). However, if the RPC call goes to an old version of nodeos, then the value displayed after used: will remain the original used value, expect it will be followed by (out-of-date) to signal that the value is the used value and therefore is likely to be quite out-of-date (depending on how recently the account had activity on the blockchain).

Performance improvements

Control whether to log integrity hash on start/stop

It was previously observed that logging the integrity hash after loading a snapshot increased start up time from a snapshot by nearly 33%. This is no longer performed by default: the options integrity-hash-on-start and integrity-hash-on-stop have been added to determine whether the integrity hash is calculated on start up and shut down, respectively.

Multi-threaded support for get_accounts_by_authorizers

/v1/chain/get_accounts_by_authorizers was designed to support multi-threaded calls, but was hooked up to the normal app thread handling. This update hooks it up the http thread handling code. Resultingly, /v1/chain/get_transaction_status has been moved from add_async_api to add_api since it does not support multi-threaded reads.

websocketpp replaced with boost beast for nodeos HTTP server implementation

The http_plugin has been overhauled, replacing websocketpp with boost::beast. The new implementation has feature parity with the previous implementation and adds HTTP Keep Alive support along with additional server-side error logging.

Use get_raw_abi in cleos

To reduce load on servers,get_abi has been replaced with get_raw_abi within cleos to get the ABI of a contract.

Stability and performance improvements to state_history_plugin (SHiP)

Various stability and performance improvements were made to the state_history_plugin. See the referenced PR for details.

Optimizations to transaction and block processing

Transaction processing has been optimized by using deque instead of std::vector. Building with a version of boost >= 1.71 will provide an additional performance improvement by using boost::container::deque. Also calculation of the action_receipt digest and transaction_receipt digest was moved to transaction and action execution time to avoid copying of receipts and to bill for hash time.

Leap now skips context-free action execution during light validation. Since context-free actions are designed to not have any side-effects (except for possible console output) and to only influence execution via asserting, the fact that they exist in a signed block is indication that the producer executed them and they did not assert. Therefore, they can be skipped during light validation where producers are implicitly trusted. Note: Any node that wishes to include all context free action console output in action traces needs to run nodeos with --force-all-checks for replay, no trusted producers, and in full validation mode.

Multithreaded enhancements:

• Pack blocks for writing to the block log in a thread pool.
• Destroy block_state objects and their associated transaction_metadata objects in thread pool.
• Calculate Merkle roots in a thread pool.

Other changes

3-strike rule applied to speculative blocks

Previously, subjective-account-max-failures only applied to signed produced blocks, not to speculative blocks. On the WAX network, it was sometimes observed that a large number of failed transactions on speculative blocks caused excessive (100%) CPU usage, and enabling subjective-account-max-failures within that environment was observed to reduce CPU usage to approximately 40%.

Applying the 3-strike rule to speculative blocks means that an account is only allowed 3 failures per speculative block, approximately 3 failures every 500 ms. It is not exactly over 500 ms as speculative blocks can be shorter or longer than 500 ms as new speculative blocks are only started when a BP signed block is received or a block CPU/NET limit is exhausted. Any transaction processed into a speculative block after the first 3 failures is immediately failed with a transaction exceeded CPU usage exception without any attempt to execute it.

The 3-strike rule is enabled by disable-subjective-billing=false and configured by subjective-account-max-failures. It is not applied to disable-subjective-account-billing accounts.

Since subjective-account-max-failures is configurable already (defaults to 3) it can be configured to 99999 to disable the 3-strike rule. Also it can be configured differently for block signing nodes, API nodes, and relay nodes.

Separate dry run from read only transactions

cleos push transaction --read-only was previously used to send transactions to the compute_transaction endpoint which were not true read-only transactions. To avoid confusion, some changes were made to cleos flags.

• --read-only has been deprecated, but continues to function as before
• --dry-run is a new option in this release and should be used instead of --read-only, by default this option will not sign the transaction.
• --sign-with allows explicit signing of --dry-run transactions is desired
• --read will be added as an option in a future release, to be used for a true read-only transaction endpoint

Additional logging

Logging enhancements add additional information to existing log statements.

The info log statement tracked in the default logger for when a block is produced in the producer_plugin adds the following fields:

• net - sum of transaction trace net_usage in bytes
• cpu - sum of transaction trace cpu_usage_us in microseconds

Example:

info 2022-06-25T16:37:28.419 nodeos producer_plugin.cpp:2486 produce_block ] Produced block 23e74c6387b1b15f... #53 @ 2022-06-25T16:37:28.500 signed by defproducerc [trxs: 18, lib: 48, confirmed: 0, net: 2592, cpu: 7030]

The info log statement tracked in the default logger for when a block is received by the producer_plugin adds the following fields:

• net - sum of transaction trace net_usage in bytes
• cpu - sum of transaction trace cpu_usage_us in microseconds
• elapsed - sum of transaction trace elapsed in microseconds
• time - wall clock time for processing/validating the block in microseconds

Example:

info 2022-06-25T16:37:23.979 nodeos producer_plugin.cpp:509 on_incoming_block ] Received block 01e618736c7f02f5... #44 @ 2022-06-25T16:37:24.000 signed by eosio [trxs: 9, lib: 43, conf: 0, net: 89592, cpu: 20526, elapsed: 19293, time: 44956, latency: -20 ms]

The debug log statements for subjective billing of a transaction processed in the producer_plugin, whether for the success case (tracked in transaction_success_tracing logger) or the failure case (tracked in transaction_failure_tracing logger), capture two time-based metrics in the log:

• elapsed - transaction trace elapsed in microseconds
• time - wall clock time for processing/validating the transaction in microseconds

Example:

debug 2022-06-25T16:37:24.007 nodeos producer_plugin.cpp:743 process_incoming_tra ] Subjective bill for success eosio: 0 elapsed 1082us, time 1287us

The logging enhancements also add completely new log statements.

A debug log statement is added within the producer_plugin and tracked by the transaction_success_tracing logger to report the wall clock time in microseconds since the completion of the previous transaction or since the start of the block.

Example:

debug 2022-06-25T17:38:36.326 nodeos producer_plugin.cpp:689 process_incoming_tra ] Time since last trx: 21479us

Debug log statements are added within the producer_plugin and tracked by the transaction_success_tracing and transaction_failure_tracing loggers to capture the processing of deferred transactions (whether they succeed or fail) with the following additional data:

• time - wall clock time for executing the transaction in microseconds
• auth - first authorizer of the transaction
• cpu - transaction trace receipt cpu_usage_us in microseconds

Example:

debug 2022-06-25T17:26:28.501 nodeos producer_plugin.cpp:2213 process_scheduled_an ] [TRX_TRACE] Block 77 for producer defproducera is ACCEPTING scheduled tx: 8203fcf4583e6f86377c09391d3a11688379fb4969df65eec38173d286ee083f, time: 452, auth: eosio, cpu: 210

Additionally, debug log statements are added within the producer_plugin and tracked by the transaction_trace_success and transaction_trace_failure loggers to capture the processing of deferred transactions (whether they succeed or fail) along with the full transaction trace.

Example:

debug 2022-06-25T17:38:34.001 nodeos producer_plugin.cpp:2216 process_scheduled_an ] [TRX_TRACE] Block 77 for producer defproducera is ACCEPTING scheduled tx: {"id":"93778ab0d07ceab684323c3f7ab053923266318254ab5d583f5a699ef1d7b585","block_num":77,"block_time":"2022-06-25T17:38:34.500","producer_block_id":null,"receipt":{"status":"executed","cpu_usage_us":172,"net_usage_words":0},"elapsed":172,"net_usage":0,"scheduled":true,"action_traces":[{"action_ordinal":1,"creator_action_ordinal":0,"closest_unnotified_ancestor_action_ordinal":0,"receipt":{"receiver":"eosio","act_digest":"cfd5ae30263ee0c3873c6f6895fb34d6b2898f55a16afd4fc4c41044a069b60f","global_sequence":111,"recv_sequence":107,"auth_sequence":[["eosio",108]],"code_sequence":1,"abi_sequence":1},"receiver":"eosio","act":{"account":"eosio","name":"newaccount","authorization":[{"actor":"eosio","permission":"active"}],"data":{"creator":"eosio","name":"sample","owner":{"threshold":1,"keys":[{"key":"EOS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV","weight":1}],"accounts":[],"waits":[]},"active":{"threshold":1,"keys":[{"key":"EOS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV","weight":1}],"accounts":[],"waits":[]}},"hex_data":"0000000000ea305500000000a858a5c101000000010002c0ded2bc1f1305fb0faac5e6c03ee3a1924234985427b6167ca569d13df435cf0100000001000000010002c0ded2bc1f1305fb0faac5e6c03ee3a1924234985427b6167ca569d13df435cf01000000"},"context_free":false,"elapsed":111,"console":"","trx_id":"93778ab0d07ceab684323c3f7ab053923266318254ab5d583f5a699ef1d7b585","block_num":77,"block_time":"2022-06-25T17:38:34.500","producer_block_id":null,"account_ram_deltas":[{"account":"sample","delta":2724}],"except":null,"error_code":null,"return_value_hex_data":""}],"account_ram_delta":{"account":"eosio","delta":-424},"except":null,"error_code":null}

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

The latest state of deprecations for Leap can be found at https://github.com/AntelopeIO/leap/wiki/Deprecations-and-Proposed-Deprecations-In-Leap-Software.

Below are new deprecations introduced as part of this release.

HTTPS support

nodeos does currently have limited HTTPS support but in actual production networks node operators tend to use the HTTPS support provided by a reverse proxy. Using the reverse proxy is the recommended way to secure client connections to the nodeos API services provided by an organization.

HTTPS support built into keosd is also not a popular way of securely connecting transaction signing tools, such as cleos, to keosd.

HTTPS support has been deprecated in nodeos and keosd and will be removed from both programs in a future release. HTTPS support within cleos has not been deprecated.

Speculative mode

Speculative mode is currently the default mode for nodeos. In speculative mode, nodeos will create a pending block even when it is not configured to produce a block for the current time slot to capture the side-effects of transactions that it has received. This allows a client to query the state of that nodeos and see what the side-effects of a transaction sent to that nodeos would be even before the transaction has actually made its way to a block producer.

However, this behavior can mislead users into believing their transaction was included in the blockchain when it may not have even been seen by a block producer yet. Furthermore, even when communicating with a particular API provider, there is no guarantee of consistently seeing the side-effects of a transaction that was sent to that API provider earlier because the API provider's load balance may route one read request to an API node that has speculatively applied the transaction and then route the next read request to another API node that never saw the transaction.

For the sake of simplicity, we recommend all nodes to run in head mode for any situation where they would otherwise considered running nodeos in speculative mode.

Speculative mode is deprecated and will be removed in favor of head mode in a future release. The disable-api-persisted-trx option is related to speculative mode and so it is also deprecated and will be removed at the same time speculative mode is removed.

eosio-blocklog functionality ported into leap-util

The functionality provided by eosio-blocklog has been integrated into the new leap-util program. Therefore, eosio-blocklog is now deprecated and will be removed in a future release.

trx_test_gen_plugin

The trx_test_gen_plugin has not ever been a reliable way to benchmark nodeos. The trx_test_gen_plugin is deprecated and will be removed in the future once a better mechanism is in place for executing transaction benchmarks for Leap.

login_plugin

The login_plugin is an obscure plugin with no known usage. It has been deprecated and will be removed in a future release.

fc and wasm-spec-tests repos

Due to limited cases for fc and wasm-spec-tests outside of Leap along with the associated overhead, the code for both repositories, which used to be integrated into the leap repository through submodules, has now been integrated directly into leap repository (see (236) and (111)).

This change means the two repositories https://github.com/AntelopeIO/fc and https://github.com/AntelopeIO/wasm-spec-tests are no longer needed for Leap versions 3.2 and later, and so they are both deprecated. Further development on related code will occur directly in the leap repository and the only development that will occur within the fc and wasm-spec-tests repositories are critical bug fixes that are necessary to support Leap 3.1 patches.

When support for Leap 3.1 reaches its end of life, the fc and wasm-spec-tests repositories will be archived.

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.

Known Issues

HTTP Requests to GetBlock fail with timeout on large blocks

API endpoints often require ABI serialization. For large blocks requested with the /v1/chain/get_block endpoint, this serialization can take quite a long time. To minimize the occurrence of requests that require a long running serialization failing due to exceeding the maximum allowed http response time our suggested workaround is to ensure that max-http-response-time is configured to be greater than max-abi-serialization-time.

If a node operator would like to keep a lower maximum allowed http response times for endpoints that don’t have this problem, one option is to use a proxy to direct GetBlock requests to a dedicated nodeos instance with a higher max-http-response-time, and all other requests to a nodeos instance with your preferred max-http-response-time.

fixed in Antelope Leap 4.

Further details on changes since last release

Contributors

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

• @spoonincode
• @heifner
• @linh2931
• @larryk85
• @arhag
• @766C6164
• @ericpassmore
• @lparisc
• @ClaytonCalabrese
• @jgiszczak
• @oschwaldp-oci
• @ndcgundlach
• @pnx
• @kj4ezj

Full list of changes since last release

Full Changelog: v3.1.0...v3.2.0