Summary

The Patch release 2.0.3 resolves a known bug identified at the time of the 2.0.0 release, a reported low impact bug, continuing precursor work for an upcoming feature, and some tech debt cleanup.

Bug:

• There was a design assumption that contract maintainers would choose to disable 1.x version(s) of their contracts when they upgrade them to 2.x versions, but this assumption was unfounded and the expected outcome isn’t required or enforced by the host. Thus in the case where there is both an enabled 1.x and 2.x contract version, an attempt to call a 1.x version would result in the loading of an applicable 2.x version of the contract (if any).

Impact:

• LOW - A relatively rare edge case. It was detected in testnet hours before mainnet upgrade to 2.0. However, initial assessment was that the potential impact which was insufficient to stop and unwind the release. Ecosystem impact is a little higher as this bug discourages the upgrading of some 1.x smart contracts, depending upon existent and intended usage.
  • If a contract maintainer disables prior 1.x version(s) of their preexisting contract as part of upgrading the contract to 2.x, then they are not affected by this bug. Disabling the prior version of a contract upon upgrade is the preferred practice.

Root Cause:

• Contract major versions (e.g., 1.x vs 2.x) there was no way via the existing interfaces for a caller to specify major version for a specific contract version invocation. Instead, the logic defaulted to the protocol_version_major of the highest enabled version.

Change: The transaction structure and the ffi were extended to allow users to precisely identify a specific contract version:

1. FFI - new function: casper_call_package_version, which includes args for major_version_ptr and major_version_size:

   1.  pub fn casper_call_package_version(
           contract_package_hash_ptr: *const u8,
           contract_package_hash_size: usize,
           major_version_ptr: *const u8,
           major_version_size: usize,
           contract_version_ptr: *const u8,
           contract_version_size: usize,
           entry_point_name_ptr: *const u8,
           entry_point_name_size: usize,
           runtime_args_ptr: *const u8,
           runtime_args_size: usize,
           result_size: *mut usize,
       ) -> i32;

2. Transaction v1
   1. TransactionInvocationTarget
      1. ByPackageHash & ByPackageName variants:
         1. new field: protocol_version_major: Option<ProtocolVersionMajor>

Default Behavior:

• When protocol_version_major is None, the system uses the current major protocol version
• When version is None, the system uses the highest enabled version of the contract
• All combinations for these two fields are supported by default ( some + some, some + none, none + some, none + none).

Bug:

• Inconsistent enforcement of minimum bid amount between native withdraw_bid and vm1 initiated withdraw_bid. Native logic was correct.

Impact:

• LOW - Inconsistent but basically harmless.

Root Cause:

• Contract runtime instantiation of the vm1 execution engine did not inject the chainspec defined minimum bid, resulting in the value being defaulted to a lower number. Instantiation of native runtime did use the chainspec value.

Fix:

• Changed contract runtime instantiation of vm1 execution engine to inject the chainspec specified value.

Misc:

• ONGOING: Continuing work on vm2 (enabled in some test environments but not intended to be turned on for mainnet as part of this rollout).
• TECH DEBT: Removed several unwraps in tracking_copy implementation. Components and utilities should not be allowed to panic if avoidable, such as in this case. Instead, they should either return a message or error code, or raise an event and allow the node to shutdown gracefully, or be made infallible.

RC10 promotion to release

Config only for add_bid minimums

Security Patch 1.5.7

Node

1.5.6

Changed

• The node will recognise if a pending upgrade is unstaged and will avoid shutting down for upgrade in this case.
• If an upgrade with the same activation point as the current one is detected on startup, the node will immediately shut down for upgrade.
• Reduce chainspec setting deploys.max_ttl from 18 hours to 2 hours.

1.5.5

Added

• New chainspec setting highway.performance_meter.blocks_to_consider with a value of 10, meaning that nodes will take 10 most recent blocks into account when determining their performance in Highway for the purpose of choosing their round lengths.

Execution Engine

7.0.1

Changed

• Change the cost of wasm.storage_costs.gas_per_byte and shared::storage_costs::DEFAULT_GAS_PER_BYTE_COST from 630_000 to 1_117_587.
• Change the cost of the host function casper_add_associated_key from 9_000 to 1_200_000.
• Change the cost of the argument entry_points_size of host function casper_add_contract_version from 0 to 120_000.
• Change the cost of the host function casper_blake2band its argument in_size from 200 and 0 respectively to 1_200_000 to 120_000.
• Change the cost of the host function casper_call_contract and its arguments entry_point_name_size and runtime_args_size from 4_500, 0 and 420 respectively to 300_000_000, 120_000 and 120_000.
• Change the cost of the host function casper_call_versioned_contract and the arguments entry_point_name_size and runtime_args_size from 4_500, 0 and 420 respectively to 300_000_000, 120_000 and 120_000.
• Change the cost of the host function casper_get_balance from 3_800 to 3_000_000.
• Change the cost of arguments name_size and dest_size of host function casper_get_named_arg from 0 to 120_000.
• Change the cost of the host function casper_put_key and its arguments name_size and key_size from 38_000, 1_100 and 0 respectively to 100_000_000, 120_000 and 120_000.
• Change the cost of the host function casper_read_value and its argument key_size from 6_000 and 0 respectively to 60_000 and 120_000.
• Change the cost of the argument urefs_size of host function casper_remove_contract_user_group_urefs from 0 to 120_000.
• Change the cost of the host function casper_transfer_from_purse_to_purse from 82_000 to 82_000_000.

7.0.0

Added

• Add chainspec option core.allow_unrestricted_transfers that, if enabled, allows token transfers between any two peers. Disabling this option makes sense only for private chains.
• Add chainspec option core.allow_auction_bids that, if enabled, allows auction entrypoints delegate and add_bid to operate. Disabling this option makes sense only for private chains.
• Add chainspec option core.compute_rewards that, if enabled, computes rewards for each era. Disabling this option makes sense only for private chains.
• Add chainspec option core.refund_handling that specifies how payment refunds are handled.
• Add chainspec option core.fee_handling that specifes how transaction fees are handled.
• Add chainspec option core.administrators that, if set, contains list of administrator accounts. This option makes sense only for private chains.
• Add support for a new FFI function enable_contract_version for enabling a specific version of a contract.

Changed

• current stack height is written to stderr in case Trap(Unreachable) error is encountered during Wasm execution.
• Tweak upgrade logic transforming withdraw purses to early exit if possible.
• Lower the default gas costs of opcodes.
  • Set the cost for branching opcodes to 35,000 (br, br_if, br_table).
  • Set the cost for call opcodes to 68,000 (call, call_indirect).
• Default value for round seigniorage rate is halved to 7/175070816 due to reduction in block times, to maintain current seigniorage rate (per unit of time).
• Refund ratio is changed from 0% to 99%.

1.5.4

Added

• New environment variable CL_EVENT_QUEUE_DUMP_THRESHOLD to enable dumping of queue event counts to log when a certain threshold is exceeded.
• Add initial support for private chains.
• Add support for CA signed client certificates for private chains.
• Add a Highway Analysis tool for checking the state of the consensus.

Changed

• Minimum block time reduced from 32.768s to 16.384s, with corresponding changes to related chainspec settings:
  • core.minimum_block_time reduced to 16384 ms.
  • core.round_seigniorage_rate reduced to [7, 175070816].
  • highway.block_gas_limit reduced to 4_000_000_000_000.
• The state_identifier parameter of the query_global_state JSON-RPC method is now optional. If no state_identifier is specified, the highest complete block known to the node will be used to fulfill the request.
• state_get_account_info RPC handler can now handle an AccountIdentifier as a parameter.
• Replace the sync_to_genesis node config field with sync_handling.
  • The new sync_handling field accepts three values:
    • genesis - node will attempt to acquire all block data back to genesis
    • ttl - node will attempt to acquire all block data to comply with time to live enforcement
    • nosync - node will only acquire blocks moving forward
• Make the network.estimator_weights section of the node config more fine-grained to provide more precise throttling of non-validator traffic.

Removed

• The section consensus.highway.round_success_meter has been removed from the config file as no longer relevant with the introduction of a new method of determining the round exponent in Highway.

Fixed

• Now possible to build outside a git repository context (e.g. from a source tarball). In such cases, the node's build version (as reported vie status endpoints) will not contain a trailing git short hash.
• Remove an error that would unnecessarily be raised when a node includes its highest orphaned block within the current era.
• Short-circuit initialization of block and deploy metadata DB to resolve delays after an upgrade.

Security

• Update openssl to version 0.10.55 as mitigation for RUSTSEC-2023-0044.

1.5.3

Added

• Add deploy_acceptor section to config with a single option timestamp_leeway to allow a small leeway when deciding if a deploy is future-dated.
• Add deploys.max_timestamp_leeway chainspec option to define the upper limit for the new config option deploy_acceptor.timestamp_leeway.
• Add block_validator.max_completed_entries config option to control the number of recently validated proposed blocks to retain.

Changed

• Change the limit of the core_config.simultaneous_peer_requests chainspec parameter to 255.
• Optimize the BlockValidator component to reduce the number of simultaneous fetch events created for a given proposed block.

Fixed

• Fix issue in chain_get_block_transfers JSON-RPC where blocks with no deploys could be reported as having null transfers rather than [].
• Fix issue in chain_get_block_transfers JSON-RPC where blocks containing successful transfers could erroneously be reported as having none.

Removed

• Remove the block_synchronizer.stall_limit node config parameter since it is no longer needed.

Alternate 1.5.2 binary to fix some reporting issues.