About HIPs

    GitHub Logo HIP-185: Smart Contract Service Gas Based Throttling

    Author Danno Ferrin
    Discussions-To https://github.com/hashgraph/hedera-improvement-proposal/discussions/192
    Status Final ⓘ
    Needs Council Approval Yes ⓘ
    Review period ends ⓘ Wed, 17 Nov 2021 07:00:00 +0000
    Type Standards Track ⓘ
    Category Service ⓘ
    Created 2021-10-27
    Updated 2022-04-26
    Requires 25, 26
    Release v0.22.0

    Table of Contents

    Abstract

    Changes transaction throttling for Smart Contracts to be based on gas usage and reservations instead of transactions per second.

    Motivation

    Currently, the Smart Contract Service throttling is based on limitations, which are driven by the architecture used to query the smart contracts from the backing store. With the adoption of On-disk Virtual Merkle Tries HIP-25 the limiting factor for smart contract execution quickly becomes compute constrained. To accurately reflect that constraint in the throttling process the unit of throttle should be EVM gas consumption, which is mostly a measure of compute expenditure.

    Rationale

    Gas Per Second Throttling

    Most Ethereum based blockchains place a limit on the amount of gas per block that transactions can consume. This is done to place a limit on the amount of time spent in block validation so that the miner nodes can more quickly produce new nodes. While Hedera does not have blocks in the context of how a Nakamoto consensus system would use it we are constrained by the physics of time as to how many blocks we can process.

    For transactions Gas is a better measure of the complexity of the transaction than counting all transactions the same, so metering the limits on Gas provides a more reasonable limit on resource consumption.

    To allow for more flexibility in what transactions we accept and to mirror Ethereum Mainnet behavior the transactions limits will be calculated on a per-gas basis for smart contract calls (ContractCreate, ContractCall , ContractCallLocalQuery) in addition to a per-transaction limit. It is expected that the gas limits will be hit more consistently than the transaction counts if the latter is raised high enough.

    Gas Reservation and Unused Gas Refund

    Hedera throttles at two locations: prior to consensus nodes limit the number of transactions they submit to the network. Then at consensus time if the maximum number of transactions is exceeded the excess transactions are not evaluated and are cancelled with a busy state. Throttling by variable gas amounts provides some challenges to this system, where the nodes only submit a share of their transaction limit.

    To address this throttling will be based on two different gas measures at pre consensus and post consensus. Pre-consensus throttling will use the gasLimit to measure the throttle, and consensus time throttling will use the actual evaluated transaction gas limit. It is impossible to know the actual evaluated gas pre-consensus because network state can directly impact the flow of the transaction, which is why pre-consensus uses the gasLimit field and will be referred to as the gas reservation.

    ContractCallLocalQuery requests are not submitted to consensus and are only executed on the node receiving the message. Hence, they will only count against the local node’s precheck throttle. ContractCreate and ContractCall transactions are executed in consensus and count against both precheck throttle limits and consensus throttle limits. The throttle limits for precheck and consensus may be set to different values.

    In order to ensure that the transactions can execute properly it is common to set a higher gas reservation than will be consumed by execution. In Ethereum Mainnet the entire reservation is charged to the account prior to execution and then unused portion of the reservation is credited back. Ethereum Mainnet, however, utilizes a memory pool and does transaction ordering at block production time, and that allows the block limit to be based only on used gas and not reserved gas.

    In order to prevent over-reservation of the smart contract services the gas credited back relative to the reservation will be limited to at most 20% of the reservation amount. From a different perspective the minimum amount of gas charged to a user based on the reservation will be a minimum of 80% of the reservation. This will incentivize transaction submitters to get within 25% of the actual gas used inorder to not be charged for unused reservation.

    Maximum Gas per Transaction

    Because consensus time execution is now limited by actual gas used and not based on a transaction count it is now safe to raise the limit of gas available to each transaction. Prior to gas based metering it would be possible for each transaction to consume the maximum gas per transaction without regard to the other transactions, so limits were based on this worst case scenario. Now that throttling is the aggregate gas used we can allow each transaction to consume large amounts of gas without concern for an extreme surge.

    When a transaction is submitted to a node with a gasLimit that is greater than the per-transaction gas limit the transaction must be rejected during precheck with a response code of INDIVIDUAL_TX_GAS_LIMIT_EXCEEDED. The transaction must not be submitted to consensus.

    User stories

    As a transaction submitter, I want the capacity of the Hedera Smart Contract Service to scale with the amount of work done as measured by Gas instead of transaction count so that I can submit larger and more compute intensive transactions while preserving the ability to send many smaller transactions with the same load imposed on processing nodes.

    Specification

    Transactions per second Throttle

    The current transaction per second throttle will be raised from the current levels. Nodes will need to ensure both the existing transaction per second throttle (which is shared among nodes) and the new gas per second throttle are not violated when submitting transactions to consensus (which is calculated per-node).

    Gas Per Second Throttling at Pre-Check

    Each individual node will use the gasLimit field to throttle ContractCreate , ContractCall and ContractCallLocalQuery to calculate the amount of gas that is being reserved. Each node will ensure that submitted transactions by that node do not reserve more gas than the global gas per second throttle.

    Gas Per Second Throttling at Transaction execution

    At transaction execution time the actual gas used by the submitted transactions will be used to determine the throttle, subject to gas minimums charged by the gas reservation refund.

    If a transaction’s gas reservation exceeds the amount of gas left before throttling occurs then the transaction will be canceled with a CONSENSUS_GAS_EXHAUSTED response. This will be evaluated as the transactions are evaluated in-order, so if a consensus transaction with a lower gas limit follows that is less than the remaining throttle amount then that transaction will not be cancelled and will be executed.

    Charging for reserved but unused Gas

    If a transaction uses less than 80% of the gas reserved via the gasLimit field then the transaction will be charged 80% of the gasLimit. If the amount of gas used is equal to or greater than 80% the gas reserved via the gasLimit field then only the actual gas used will be charged.

    Gas that is reserved but not charged does not count against the throttling limit.

    Charging for Intrinsic and Contract Creation Gas

    Because we are throttling by Gas used it is now appropriate to re-introduce Ethereum Mainnet intrinsic and gas creation charges. Transactions will be charged the current base fee (of 21,000 gas) and the Istanbul rates for transaction payload (4 for zero bytes, 16 for non-zero bytes) passed into the EVM. This will help ensure that the computational capacity is not exceeded with numerous small transactions.

    Backwards Compatibility

    This HIP introduces a new throttling mechanism and changes to the EVM gas schedule that are enabled by the new mechanism. No changes are introduced into the EVM semantics. It is expected that the capacity for smart contract transactions in all measures are increased, hence only usages that depend on current low level of throttling will be impacted. No contracts are known that depend on capacity limitations at this time.

    Security Implications

    The increase in the execution of smart contracts may increase load on the consensus nodes in the Hedera network. The limits used were calculated to not increase these loads beyond the levels that the current hardware can handle.

    How to Teach This

    Any documentation or tutorials that address transaction throttling or speed limits will need to be updated to reflect the new gas-based throttling.

    Reference Implementation

    Rejected Ideas

    • Transaction per second only throttling was rejected because increasing the limit would need to take into account the security of all transactions consuming all the available gas with expensive operations.

    Open Issues

    References

    • HIP-25 On-disk Virtual Merkle Tree
    • HIP-26 Migrate Smart Contract Service EVM to Hyperledger Besu EVM

    Copyright/license

    This document is licensed under the Apache License, Version 2.0 – see LICENSE or (https://www.apache.org/licenses/LICENSE-2.0)

    Citation

    Please cite this document as: