Skip to content
This repository has been archived by the owner on Aug 2, 2022. It is now read-only.

restrict range of error codes that contracts are allowed to emit #7274

Merged
merged 2 commits into from
May 6, 2019

Conversation

arhag
Copy link
Contributor

@arhag arhag commented May 6, 2019

Change Description

A contract is allowed to fail with a uint64_t error code using the eosio_assert_code intrinsic. This is an alternative to the other variants of assert intrinsics which take string error messages that allows for reductions in contract WASM size.

Contracts are allowed to choose error code values and assign meaning to them specific to their contract, however they should not be allowed the full range of a uint64_t. The values greater than or equal to 10,000,000,000,000,000,000 are reserved by the EOSIO system for its own error codes to be used in the future.

This PR makes a change to the eosio_assert_code intrinsic implementation to disallow a contract from passing through an error code in the restricted range into the trace, thereby reserving the range to allow the system to unambiguously signal system errors via the error_code field of the trace.

To avoid changing consensus rules, a call to eosio_assert_code with a restricted error_code value is allowed if the condition is true; it is still a no-op in that case. It is only when the condition is false that the restriction on the error_code value is enforced. The transaction still fails but with a different error code (system_error_code::contract_restricted_error_code) to signal that the contract called eosio_assert_code with a restricted error code value.

Any chain exceptions that do not have a more specific error code defined will use the error code of the generic_system_error, which is the value at the start of the range of error codes restricted for system errors.

Consensus Changes

  • Consensus Changes

API Changes

  • API Changes

Documentation Additions

  • Documentation Additions

Contracts are able to use uint64_t error codes as an alternative (and cheaper) means of signaling error conditions as opposed to string error messages. However, EOSIO and EOSIO.CDT reserve certain ranges of the uint64_t value space for their own purposes. They assume that the contract develop respects the following restrictions:

  • 0 (inclusive) to 5,000,000,000,000,000,000 (exclusive): Available for contract developers to use to signal errors specific to their contracts.
  • 5,000,000,000,000,000,000 (inclusive) to 8,000,000,000,000,000,000 (exclusive): Reserved for the EOSIO.CDT compiler to allocate as appropriate. Although the WASM code generated by the EOSIO.CDT compiler may use error code values that were automatically generated from within this range, the error codes in this range are meant to have meaning specific to the particular compiled contract (the meaning would typically be conveyed through the mapping between the error code value and strings in the associated generated ABI file).
  • 8,000,000,000,000,000,000 (inclusive) to 10,000,000,000,000,000,000 (exclusive): Reserved for the EOSIO.CDT compiler to allocate as appropriate. The error codes in this range are not specific to any contract but rather are used to convey general runtime error conditions associated with the generated code by EOSIO.CDT.
  • 10,000,000,000,000,000,000 (inclusive) to 18,446,744,073,709,551,615 (inclusive): Reserved for EOSIO to represent system-level error conditions. EOSIO will actually enforce this by restricting the ability for eosio_assert_code to be used to fail with error code values used within this range.

@@ -106,6 +106,12 @@

namespace eosio { namespace chain {

enum class system_error_code : uint64_t {
default_system_error = 10000000000000000000ULL,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

default_system_error seems like an odd name to me. Maybe reserved_system_error or lowest_reserved_system_error or system_error_range or system_error_range_begin

@arhag arhag merged commit e8ab259 into release/1.8.x May 6, 2019
@arhag arhag deleted the restricted-error-code-range branch May 6, 2019 19:44
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants