[AIP-60][Discussion] Improve fairness of shared computation resources

[thepomeranian]

AIP Discussion

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.

Read more about it here: https://github.com/aptos-foundation/AIPs/blob/main/aips/aip-60.md

[alnoki]

@thepomeranian I understand that this AIP is meant to limit computation time per txn, however this limitation is enforced by gas amounts. I assume that the gas costs per operation do not correlate one-to-one with the execution time, so how do divergences from the mean play out?

E.g. as I understand it some operation are priced at a discount to incentivize good programming practice (events, asserts), so does that mean that loop of event emissions (compared with a no-op loop) could actually exploit the divergence between time and cost?

[meetrick]

@thepomeranian How often does the problem occur?
Is a limited max_execution_gas or max_io_gas sufficient for normal transactions?

[vgao1996]

I assume that the gas costs per operation do not correlate one-to-one with the execution time, so how do divergences from the mean play out?

@alnoki In principle, (execution & IO) gas should be a faithful reflection of the execution time. In fact, it can be seen as a deterministic replacement of time measurement.

In practice, such correlation cannot be perfect due to a few reasons

• Miscalibrated gas parameters
  • This can be greatly improved by our upcoming gas calibrator.
• Discounts/incentives
  • I think at this moment this is only a theoretical approach we may take. Particularly, events and asserts are NOT subsidized under the current gas schedule. Events might have been subsidized during the early days, but when we introduced dedicated storage fees, we didn't remove the corresponding portion from its old execution charge, so they have been charged more than what was necessary. With our new gas schedule for 1.9 out now, you should actually see a decrease in costs associated with events.
  • If we were to introduce incentives again in the future, I think we would need to pair it with some other limits/quota to make sure they only benefit regular transactions, not malicious ones.
• Hardware Architecture Differences
  • No way to perfectly align gas costs for all hardware platforms, but possible to keep the discrepancy under control.

You are correct that such discrepancy can be exploited by an attacker, and we are working very hard on reducing it with better calibrations this quarter, so stay tuned.

[alnoki]

@vgao1996 thank you for the detailed responses here. I favor the approach of IO gas mapping generally to hardware costs on a "generic machine", and understand that the current gas calibration initiatives will be geared toward correlating costs to execution time as accurately as possible.

[igor-aptos]

@meetrick : for the just recently applied reduction in limits, it was rarely hit, and majority of times it was caused by inefficiency in the implementation.

From analyzing mainnet transactions, further reduction will currently additionally affect aggressive batching some projects are doing. Reducing batch size should allow folks in general to keep below the limits.

Overall, a lot of work can still be executed within these limits, and they shouldn't preclude complicated applications. If you have concrete examples where useful work becomes tight with new limits - it would be great it you can share it - and we can take a look, and together figure out how low the limits should go - so that useful work can always be comfortably executed.

[vgao1996]

I favor the approach of IO gas mapping generally to hardware costs on a "generic machine", and understand that the current gas calibration initiatives will be geared toward correlating costs to execution time as accurately as possible.

@alnoki Yes, this is exactly what we are planning to do with gas.