API+ features for Mandel 3.1

[brianjohnson5972]

Transaction Retry.

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.

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
  • "Maximum time in seconds to track transaction for duplicate optimization" Default of 10 seconds

New command line options for cleos

• --use-old-send-rpc
  • "Use old RPC send_transaction, rather than new RPC /v1/chain/send_transaction2"
• -t,--return-failure-trace
  • "Return partial traces on failed transactions"
    • This is ignored for now, feature to be added later to Mandel
• --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"

New chain_api_plugin endpoint

• /v1/chain/send_transaction2 (send_transaction_params)

struct send_transaction2_params {
      bool return_failure_trace = true; ///< Ignored. Future feature.
      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
   };

Transaction Finality Status

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
  • "Duration (in seconds) a successful transaction's Finality Status will remain available from being first identified."
• transaction-finality-status-failure-duration-sec
  • "Duration (in seconds) a failed transaction's Finality Status will remain available from being first identified."

New command line options for cleos

• get transaction-status <id (required)>

  • "Gets current blockchain state and, if available, transaction information given the transaction id"

New chain_api_plugin endpoint

• /v1/chain/get_transaction_status (get_transaction_status_params )

struct get_transaction_status_params {
      string                       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;
};

PRs

• Added read only transaction status capability, "get_transaction_status", to the Chain API Plugin. With support in cleos "get transaction-status <id (required)>". Added docs for cleos feature. (Add get_transaction_status to chain_plugin #145)
• Adding Finality Status storage. Added storage for Finality Status feature and using signals_processor to populate. (Adding Finality Status storage #81)
• Add docs for transaction retry. (Add docs for transaction retry #116)
• Add integration tests for finality status. (#???)

Transaction Resource Cost Estimation

Transactions sent to this endpoint will be executed and create a transaction trace, including resource usage, and then will revert all state changes and will not contribute to the subjective billing for the account. If the transaction has signatures, they will be processed, but any failures will be ignored.

Users with exposed nodes who have enabled the compute_transaction endpoint should implement some sort of throttling to protect from Denial of Service attacks.

New command line options for cleos

• --read-only
  • "Specify a transaction is read-only"

New chain_api_plugin endpoint

• compute_transaction
  • uses existing send_transaction_params

PRs

• Added read only transaction capability, compute_transaction, to the Chain API Plugin. (Added capability for read-only txns / added compute_transaction to chain api #86)
• Improved read only transaction plumbing. (Ignore signature verification for compute_transaction / integration tests #108)
• Disabled subjective billing for read-only transactions. (Don't apply subjective billing to read-only transactions #114)
• Added send_transaction2 to Chain API Plugin, which provides transaction retry support.(Transaction retry feature #79, Many Transaction Long Running Test #88, Add new transaction retry integration test #89, Add docs for transaction retry #116)

Subjective Billing Improvements

Account max failures: During block production, accounts are permitted a set number of failures before their additional transactions are dropped for a given block. This previously hard-coded limit of 3 is now configurable. Also, disable-subjective-account-billing accounts are no longer subjected to this limit.

Decay time: Users are prevented from abuse of transactions by tracking an account's subjective CPU budget. The budget is returned to an account over a period of time known as subjective account decay. This previously hard-coded decay of 24 hours is now configurable.

New configuration args for nodeos

• Subjective-account-max-failures (default 3)
  • "Sets the maximum amount of failures that are allowed for an account per block."
• Subjective-account-decay-time-minutes (default 24 hours)
  • "Sets the time to return full subjective CPU for accounts"

PRs

• Implemented additional check against account whitelist in subjective billing. (ENFS-43: Add Configured Whitelist to Ignore Number of Failures #84)
• Added "subjective-account-max-failures" option in the Producer Plugin to set the maximum amount of failures allowed per account, per block. (Configurable max_failures_per_account #82)
• Added "subjective-account-decay-time-minutes" option to the Producer Plugin. It sets the amount of time it takes to restore full subjective CPU to an account. (Configurable subjective account decay time #90)

[heifner]

Each individual PRs approved as they went into feature/oci_api_phase1