Improve fairness of shared computation resources
AIP-60 - Improve fairness of shared computation resources
Section titled “AIP-60 - Improve fairness of shared computation resources”Summary
Section titled “Summary”Currently per-transaction max_execution_gas and max_io_gas limits allow single transaction to unfairly hog resources, and take ~1s to execute.
Proposal is to reduce the limits to ~100ms short term, with target of 10ms mid-term.
Out of Scope
Section titled “Out of Scope”Any gas calibration changes, or block limit changes. This also doesn’t touch overall transactions gas limit, which are much larger - as storage fees themselves are much larger.
Motivation
Section titled “Motivation”Allowing large individual transactions, makes it easy for individual transactions to unfarily hog computation resources, makes it harder to fairly share resources, and makes chain less responsive.
From investigations, most common causes for single transaction taking a lot of time to execute are:
- inefficient implementations
- batching of many individual operations into single transaction
Less commonly, and mostly on the lower end of around the ~10-30ms range is a set of use cases with actual need, for example using cryptographic expensive primitives.
This suggests reducing transaction limit should be overall beneficial:
- innefficient contracts will get early information to optimize
- reducing batching allows for more parallelism and higher throughput
- chain will be more responsive and fair
We will work to understand use cases with real need - and see how they can be handled. Reach out if your transactions fall into this category.
Impact, Risks and Drawbacks
Section titled “Impact, Risks and Drawbacks”Any transaction that exceeds reduced max_execution_gas or max_io_gas will be rejected.
Valid use cases that want to do larger amount of work will need to be split across multiple transactions.
Full framework upgrade is more expensive than new wanted limits, and so special handling will be added (similarly to special transaction size). In the meantime, our multi-step proposal is going to first be increasing the limit, then executing framework upgrade, then reducing the limit back down.
Reference Implementation
Section titled “Reference Implementation”Modifying two configs in transaction.rs
PR to apply changes and create mainnet proposal
Timeline
Section titled “Timeline”Suggested deployment timeline
Section titled “Suggested deployment timeline”By mid-January, reduce mainnet limits to 100ms, to improve fairness immediatelly. Less than 0.1% of mainnet transaction fall into this cateogry.
Gradually, in collaboration with the ecosystem, reduce limits further down to 10ms, in the coming weeks/months.
On devnet/testnet, we will more aggressively reduce limits, to help everyone understand impact on their applications, and do the mainnet transition more smoothly.
Security Considerations
Section titled “Security Considerations”None