Mandel v3.1.0-rc3 Release Notes

This is a RELEASE CANDIDATE for version 3.1.0. The latest STABLE release is v2.0.14.

This release adds subjective limits to the mod_exp host function along with several bug fixes and documentation updates.

Read on for details.

Host function updates

Subjective limit for mod_exp

PRs

• (#739) [3.1] Add subjective limit to mod_exp host function
• (#749) [3.1] Use more flexible subjective limits on mod_exp

With the introduction of host functions to support EVM it was necessary to set limits to big integer modular exponentiation, mod_exp, to prevent transactions from being delayed too much beyond the intended deadline timeout.

Note that this is not a change to the protocol since the limits are enforced at block producer nodes when evaluating whether to include a transaction into a block.

Bug fixes

Deep-mind writing packed transactions instead of signed transactions for PUSH_CREATE

PRs

• (#654) [3.1] Use signed transaction for PUSH_CREATE action deep-mind logging

In testing, it was discovered deep-mind plug-in was writing the packed transactions into the dmlog on PUSH_CREATE, which is only appropriate for the MODIFY_CREATE action. An update was made to match the behavior of the version integrated with EOSIO v2.1, which writes signed transactions instead.

Unexpected behavior in mandel-dev.deb

PRs

• (618) [3.1] ensure an empty llvm-dev dep doesn't make its way to mandel-dev .deb
• (#646) [3.1] make fc::read_file_contents() check for errors instead of silently returning empty string
• (#648) [3.1] more cleanup to EosioTester.cmake to use CMAKE_INSTALL_FULL_LIBDIR instead
• (#680) embed contracts required for native contract unit testing in to libtester

Integration with mandel-dev.deb, mandel-contracts, mandel.cdt, and DUNE revealed unexpected behavior, which required some code cleanup for better error checking.

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 EOSIO 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.

1. 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"]}'

2. 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 <EOSIO_SYSTEM_CONTRACTS_DIRECTORY>/contracts/eosio.boot/ eosio.boot.wasm eosio.boot.abi

3. 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 eosio

Deprecations, 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:

• @spoonincode
• @heifner
• @oschwaldp-oci
• @arhag

Full list of changes since last release

PRs

• (618) [3.1] ensure an empty llvm-dev dep doesn't make its way to mandel-dev .deb
• (627) [3.1] Fix for block producer stuck in coma state
• (633) [3.1] spelling fixes in p2p log messages
• (646) [3.1] make fc::read_file_contents() check for errors instead of silently returning empty string
• (654) [3.1] Use signed transaction for PUSH_CREATE action deep-mind logging.
• (679) [3.1] Fix trx_finality_status_test
• (648) [3.1] more cleanup to EosioTester.cmake to use CMAKE_INSTALL_FULL_LIBDIR instead
• (680) embed contracts required for native contract unit testing in to libtester
• (702) [3.1] remove broad 'using namespace boost' causing float128_t conflict; fixes builds w/ boost 1.80
• (739) [3.1] Add subjective limit to mod_exp host function
• (718) [3.1] set prune logs at debug level except for the initial log when enabling pruning
• (749) [3.1] Use more flexible subjective limits on mod_exp.
• (752) [3.1] bump version to 3.1.0-rc3
• (756) [3.1] Attempt connection retries for duplicate connections

Full Changelog: v3.1.0-rc2...v3.1.0-rc3

Mandel v3.1.0-rc2 Release Notes

This is a RELEASE CANDIDATE for version 3.1.0. The latest STABLE release is v2.0.14.

This release makes changes to a protocol feature introduced in v3.1.0-rc1. Version 3.1.0-rc1 nodes should not be used in a network that has activated the CRYPTO_PRIMITIVES protocol feature. See the protocol changes section below for further details.

This release also includes various miscellaneous fixes and improvements. Changes of particular significant include:

• Bug fixes related to state_history_plugin (SHiP)
• Documentation improvements

Read on for details.

Protocol changes

Host function updates for crypto primitives

PRs

• [498] [3.1] Changes need to crypto-primitives host functions
• [608] [3.1] Allow zero in alt_bn128; fix gmp linking in EosioTester

In this release we updated some of the host functions that are part of the CRYPTO_PRIMITIVES protocol feature.

⚠️ Warning: This update changes the function signatures and semantics of these functions and as such v3.1.0-rc1 should never be used when activating the CRYPTO_PRIMITIVES protocol feature.

The alt_bn128_add, alt_bn128_mul, alt_bn128_pair, mod_exp, and blake2_f host functions now return -1 on an error and 0 for success.

For alt_bn128_pair, we removed the output parameter for the result and now have a tri-state return from the host function. So, it will return -1 on error, 1 for false and 0 is success and true.

The behavior of the alt_bn128_add, alt_bn128_mul, and alt_bn128_pair functions has been altered to consider zero a valid input point. Instead of returning an error upon encountering a zero point, the function will continue processing it like any other point on the curve.

Other changes

state_history_plugin (SHiP) fixes

PRs

• [472] [3.1] Fix issue with current block not sent to SHiP clients
• [483] [3.1] bump fc submod with fix for macos hole punching
• [505] [3.1] fix linking of c++ SHIP tests on boost versions prior to 1.69

In testing, stability issues were discovered with the most recent implementation of log pruning that have been addressed.

Additional, a bug in SHiP that prevented sending the most recent block to clients has been fixed.

Documentation improvements

PRs

• [566] [3.1] fixup CONTRIBUTING.md
• [596] [3.1] various README.md improvements w.r.t. build & branches

The README has been updated to clean up and clarify build and test instructions. It has also been updated to clarify the role of the main branch and where to find stable releases of the software.

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.

Protocol compatibility

This release changes the behavior of the CRYPTO_PRIMITIVES protocol feature introduced in v3.1.0-rc1. The CRYPTO_PRIMITIVES protocol feature of v3.1.0-rc1 is not compatible with the one in this (and future) releases, and therefore v3.1.0-rc1 should not be used.

⚠️ Warning: Delete the JSON files in config/protocol_features before upgrading to nodeos v3.1.0-rc2 to ensure you get the updated digest for the new CRYPTO_PRIMITIVES protocol feature. The feature_digest of the CRYPTO_PRIMITIVES protocol feature should be 6bcb40a24e49c26d0a60513b6aeb8551d264e4717f306b81a37a5afb3b47cedc (which you can verify with curl -s http://localhost:8888/v1/producer/get_supported_protocol_features | jq). If the feature_digest does not match on a nodeos instance, that nodeos instance may be kicked out of the network upon activation of the protocol feature.

Deprecations, removals, and dropped support

Dropped support

Ubuntu 16.04, Centos, and macOS

As mentioned earlier, 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:

• @spoonincode
• @heifner
• @linh2931
• @larryk85
• @oschwaldp-oci
• @arhag

Full list of changes since last release

PRs

• [393] [3.1] remove an unneeded npm command from README
• [387] [3.1] plugin_http_api_test - fix timing issue
• [381] [3.1] net_plugin delay connecting to peers
• [417] [3.1] before reading /etc/os-release make sure it exists
• [483] [3.1] bump fc submod with fix for macos hole punching
• [480] [3.1] Remove confusing error message
• [487] [3.1] Print out warning only if the platorm is not Ubuntu and make build directory relative to where the build starts
• [472] [3.1] Fix issue with current block not sent to SHiP clients
• [496] [3.1] Fix incorrect default option name for wasm-runtime in appbase
• [498] [3.1] Changes need to crypto-primitives host functions
• [505] [3.1] fix linking of c++ SHIP tests on boost versions prior to 1.69
• [502] [3.1] fix libff in 3.1 tester cmakes
• [532] [3.1] misc pinned build script fixes
• [539] [3.1] Fix log trimming of hex_data JSON output.
• [566] [3.1] fixup CONTRIBUTING.md
• [592] [3.1] Fix race condition on trace_api_plugin shutdown
• [596] [3.1] various README.md improvements w.r.t. build & branches
• [608] [3.1] Allow zero in alt_bn128; fix gmp linking in EosioTester
• [610] [3.1] Bump version to 3.1.0-rc2

Full Changelog: v3.1.0-rc1...v3.1.0-rc2

Mandel v3.1.0-rc1 Release Notes

This is a RELEASE CANDIDATE for version 3.1.0. The latest STABLE release is v2.0.14.

Release 3.1.0-rc1 includes protocol upgrades enabling contracts to get the current block number and to accelerate various cryptographic computation, as well as 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.

Read on for details.

Protocol changes

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.

⚠️ Warning: The behavior of this protocol feature has been changed in later releases. Version 3.1.0-rc1 should not be used in a network that has activated this protocol feature.

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

• Transaction retry feature (#79)
• Many Transaction Long Running Test (#88)
• Add new transaction retry integration test (#89)
• Add docs for transaction retry. (#116)
• Implement return failure traces (#173)

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.

⚠️ Warning: Full failure traces are now returned by default instead of exceptions. Be careful to not confuse a returned trace as an indication of speculative execution success. Verify 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 90)
  • "Maximum allowed transaction expiration for retry transactions, will retry transactions up to this value."
• p2p-dedup-cache-expire-time-sec (defaults to 10)
  • "Maximum time in seconds to track transaction for duplicate optimization"

New command line options for cleos:

• --use-old-send-rpc
  • "Use old RPC /v1/chain/send_transaction, rather than new RPC /v1/chain/send_transaction2"
• -t,--return-failure-trace defaults to true use -t false for previous behavior
  • "Return partial traces on failed transactions"
  • Note: Automation which depends on cleos to return a non-zero value on transaction failure will instead need to parse the traces or use option -t false.
• --retry-irreversible
  • "Request node to retry transaction until it is irreversible or expires, blocking call"
• --retry-num-blocks
  • "Request node to retry transaction until in a block of given height, blocking call"

Transaction finality status

PRs

• Added read only transaction status capability, get_transaction_status, to the Chain API Plugin. Also added support in cleos. (#145)
• Added Finality Status storage. Added storage for Finality Status feature and using signals_processor to populate. (#81)
• Added integration tests for finality status. (#189)

New chain_api_plugin endpoint:

• /v1/chain/get_transaction_status(get_transaction_status_params)

  struct get_transaction_status_params {
      transaction_id_type                id; //transaction id to status
  };
  
  struct get_transaction_status_results {
      string                               state;
      std::optional<uint32_t>              block_number;
      std::optional<chain::block_id_type>  block_id;
      std::optional<fc::time_point>        block_timestamp;
      std::optional<fc::time_point>        expiration;
      uint32_t                             head_number;
      chain::block_id_type                 head_id;
      fc::time_point                       head_timestamp;
      uint32_t                             irreversible_number;
      chain::block_id_type                 irreversible_id;
      fc::time_point                       irreversible_timestamp;
      chain::block_id_type                 last_tracked_block_id;
  };

When transaction finality status is enabled, the status of a transaction in the node, as well as a snapshot of the current chain state, can be queried. If a transaction is not found for the given transaction id, only the chain status fields and a status of "UNKNOWN" will be provided.

New configuration args for nodeos:

• transaction-finality-status-max-storage-size-gb
  • "Maximum size (in GiB) allowed to be allocated for the Transaction Finality Status feature. Setting above 0 enables this feature."
• transaction-finality-status-success-duration-sec (defaults to 180)
  • "Duration (in seconds) a successful transaction's finality status will remain available from being first identified."
• `transaction-finality-status-f...

v2.0.14

Mandel v2.0.14 Release Notes

Changes from EOSIO/eos v2.0.13

Three Strike Rule

Previously the 3-strike rule (3 failed trx per block and then no more allowed per account) was only applied during processing of the unapplied transaction queue in start_block. Now it is applied during "regular" block processing as well. This prevents users from flooding a BP with failing transactions during their block production window, which would limit the amount of valid transactions that can be placed in a block.

Configurable Subjective Account Decay

This adds new config option subjective-account-decay-time-minutes to Producer Plugin. The value is used to calculate the expired_accumulator_average_window, thus making account decay time configurable. The passed value must be above 0, and defaults to 1440. The default value for expired_accumulator_average_window remains the same.

Misc Changes

• Added logging for onblock errors.
• Added total CPU and NET to get_info api call.
• Added reset of sync_known_lib_num on closing connection to optimize syncing.

Bug Fixes

• Fix for case when net_plugin sends sync_request_message{0,0} in response to block<lib it doesn't reset sync_last_requested_num. After that when node gets notice_message it ignores it instead of doing catchup since head is less than sync_last_requested_num.
• Fixed handling for deltas bigger than uint32_t size can indicate. This was an issue for Wax.
• Changed to avoid accessing connection data during operation_aborted since it can be called during shutdown when connection is being destroyed and result in a net_plugin segfault.
• Added a fix for https bug, issue EOSIO/eos#10695 where passing incorrect HTTPS configuration to nodeos will prevent HTTP server from functioning properly. Move variable initialization in http_plugin::plugin_initialize to the beginning of the function.
• Fixed where sync_reset_lib_num was not updating sync_known_lib_num when syncing.
• Added a fix to trim_blocklog_front() to address bad memory access exception when there are less than 8 bytes right after address buf + buffer_index in the buffer.
• Fixed some cases where net_plugin kept trying to re-connect on fatal conditions (like node is a different chain (chain_id))

PRs

• #298 Apply 3-strike rule for complete block production
• #99 Configurable subjective account decay time
• EOSIO/eos#11066 net_plugin bugfix for resetting requested range
• EOSIO/eos#11067 Docker tagging required for backwards compatibility of unpinned images
• EOSIO/eos#11051 Big ship deltas
• EOSIO/eos#11038 Log onblock errors
• EOSIO/eos#11007 Release/2.0.x pinned contracts registry image
• EOSIO/eos#10932 Add total CPU and NET to get_info
• EOSIO/eos#10961 net_plugin: shutdown segfault fix
• EOSIO/eos#10767 Fix https bug
• EOSIO/eos#10764 Update sync_known_lib_num even if syncing
• EOSIO/eos#10720 Change stability pipeline specific guard to remove dependency on special patterns
• EOSIO/eos#10370 Handle special case in trim_blocklog_front
• EOSIO/eos#10651 Reset sync_known_lib_num when closing a connection

v3.0.5-rc1

Mandel v3.0.5-rc1 Release Notes

Changes from v3.0.0-rc1

• #38 Backport dfuse support. The log format is different from 2.0 and 2.1 and provides a distinct version number. See #38 for more info.
• #43 Changes to EOSIO 2.0.x since 2.0.13
  • EOSIO/eos#10651 Reset sync_known_lib_num when closing a connection
  • EOSIO/eos#10767 Bug fix: passing incorrect HTTPS configuration no longer breaks the HTTP server
  • EOSIO/eos#10932 Add total CPU and NET to get_info
    • Make it easier to implement calculations to do automatic powerups. Currently, users use hacks to get around this by estimating the values based on the get_account response of an account with a lot of stake.
  • EOSIO/eos#10961 net_plugin: shutdown segfault fix
  • EOSIO/eos#11066 net_plugin bugfix for resetting requested range
• #45 Respect the cpu-effort-percent while processing dedup list
• #52 Backport of additional subjective cpu logging
• #55 Backport fix to take into account network latency when syncing from a node
• #64 Backport fix of compiler warnings

• Build and CI/CD related
  • #54 Report ctest failure results

v3.0.0-rc1

Mandel v3.0.0-rc1 Release Notes

This is the first RELEASE CANDIDATE for the first Mandel release.

Mandel is a fork of eosio, developed by ƒractally with funding from the EOS Network Foundation. Mandel v3.0 is based on eosio v2.0.13, which provides a solid foundation for future development. It includes cherry-picked features from eosio v2.1.x and eosio develop-boxed. It also includes some new features.

Changes from v2.0.13

Hard Forks

Name	From	Description
GET_CODE_HASH	new	The get_code_hash intrinsic allows contracts to check if an account has a contract set, get the hash of that account's contract, plus get the number of times that contract has changed.
ACTION_RETURN_VALUE	v2.1	The set_action_return_value intrinsic allows actions to return values which appear in the action trace.
CONFIGURABLE_WASM_LIMITS2	v2.1, new	This allows chain operators to increase various limits on WASM files. This is based on 2.1's CONFIGURABLE_WASM_LIMITS, but contains additional fixes.
BLOCKCHAIN_PARAMETERS	v2.1	This provides an extensible mechanism to configure blockchain parameters. It includes the ability to configure the maximum return value size supported by ACTION_RETURN_VALUE.

Other Notable Changes

• Chainbase ported from 2.1 has significant performance enhancements plus automatic huge page support. See EOSIO/eos#9577 for configuration changes.
• Supports snapshot versions 4 and 5 from v2.1.
• Has hooks to support cltester and debug_plugin. cltester supports creating deterministic test cases for contracts. debug_plugin supports debugging contracts using gdb and vscode. cltester and debug_plugin come with clsdk.
• onblock logging helps diagnose system contract failures.
• Enhanced snapshot reporting from v2.1: v1/producer/create_snapshot now includes the head block number, head block time, and snapshot format version in its output.

ABI Format Changes

The ABI is now at version 1.3. A new field action_results, a binary extension, is after the variants field. action_results is an array of struct with the following fields:

eosio::name     name;           // Name of the action
string          result_type;    // Return type

There's an entry in action_results for each action which returns data using the set_action_return_value intrinsic.

SHiP Format Changes

• get_status_result_v0 has a new binary extension field, chain_id.
• action_trace_v1 is a new struct version which adds return_value.
• chain_config_v1 is a new struct version which adds max_action_return_value_size.
• wasm_config_v0 is a new struct which stores configurable wasm limits.
• global_property_v1 has a new binary extension field, wasm_configuration.

PRs

• #1: Use a fork of 2.1's fc. The fc fork reintroduces code that 2.1 removed, but 2.0 still depends on. A future release may remove this reintroduced code.
• #2: Backport 2.1's eos-vm. This is a step toward backporting CONFIGURABLE_WASM_LIMITS.
• #3: Backport 2.1's SHiP refactor, but without most of the SHiP format changes. This turns SHiP into a library, needed for cltester. Its only user-facing change is the addition of chain_id as a binary extension to get_status_result_v0.
• #4: Backport 2.1's chainbase. This includes significant performance enhancements plus automatic huge page support. See EOSIO/eos#9577 for configuration changes.
• #5: Lighter-weight cicd system based on GitHub Actions. This runs the in-repo test suite using Ubuntu 20.04 (unpinned build).
• #6: Backport 2.1's tester cmake changes. This allows tests in https://github.com/eosnetworkfoundation/mandel-contracts to build using Mandel.
• #7: Backport 2.1's ACTION_RETURN_VALUE hard fork. This adds the set_action_return_value intrinsic, which allows contracts to place return values into the action trace. This PR adds action_trace_v1 and chain_config_v1 to SHiP.
• #8: Backport 2.1's CONFIGURABLE_WASM_LIMITS hard fork, with additional fixes. The resulting hardfork is CONFIGURABLE_WASM_LIMITS2. This allows chain operators to increase various limits on WASM files. This PR also brings in 2.1's snapshot format versions 4 and 5. Mandel 3.0 should be able to import 2.1's snapshots as long as no 2.1 hard forks were active, though this hasn't been tested.
• #11: Backport 2.1's BLOCKCHAIN_PARAMETERS hard fork. This provides an extensible mechanism to configure blockchain parameters. It includes the ability to configure the maximum return value size supported by ACTION_RETURN_VALUE.
• #12: New GET_CODE_HASH hard fork provides the get_code_hash intrinsic. This allows contracts to check if an account has a contract set, get the hash of that account's contract, plus get the number of times that contract has changed.
• #14: Backport 2.1 WASM tests.
• #15: Add SHiP support for CONFIGURABLE_WASM_LIMITS. This adds wasm_config_v0 and wasm_config. It adds wasm_configuration as a binary extension to global_property_v1.
• #16: Switch to develop-boxed's eos-vm. This adds contract profiling support and is a step toward supporting WASM debugging.
• #17: Add hooks for clsdk or other development tools. This allows cltester to integrate with Mandel. It also allows debug_plugin (comes with clsdk) to integrate with Mandel.
• #18: Port onblock logging from EOSIO/eos#11038. This helps diagnose system contract failures.
• #19: Backport 2.1 enhanced snapshot reporting. v1/producer/create_snapshot now includes the head block number, head block time, and snapshot format version in its output.
• #24: SHiP compressed deltas may exceed 4GB.
• #25: Replace N macro with operator ""_n.
• #26: Remove fc::optional and fc::static_variant.
• #27: Bump version to v3.0.0-rc1.
• #28: Increment codegen_version.