|Needs Council Approval||Yes|
|Review period ends||Wed, 17 Nov 2021 07:00:00 +0000|
Table of Contents
- User stories
- Backwards Compatibility
- Security Implications
- How to Teach This
- Reference Implementation
- Rejected Ideas
- Open Issues
Changes transaction throttling for Smart Contracts to be based on gas usage and reservations instead of transactions per second.
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.
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 (
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.
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
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.
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.
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.
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.
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).
Each individual node will use the
gasLimit field to throttle
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.
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
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.
If a transaction uses less than 80% of the gas reserved via the
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
then only the actual gas used will be charged.
Gas that is reserved but not charged does not count against the throttling limit.
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.
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.
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.
Any documentation or tutorials that address transaction throttling or speed limits will need to be updated to reflect the new gas-based throttling.
- Hedera Services PR#2373
- 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.
- HIP-25 On-disk Virtual Merkle Tree
- HIP-26 Migrate Smart Contract Service EVM to Hyperledger Besu EVM
This document is licensed under the Apache License, Version 2.0 – see LICENSE or (https://www.apache.org/licenses/LICENSE-2.0)
Please cite this document as: