[AIP-59][Discussion] Storage IO Gas Adjustments

[msmouse]

AIP Discussion

Proposing here is to fine tune the logic of charging gas for both storage reads and writes in order to make the cost structure more fair and reflect better the system resource consumption from different transaction workloads. Specifically:

• Charge the state read size at 4KB (dubbed "Page" onwards) intervals.
• Tune the relative weight of per read charge over the size of the read (in pages).
• Remove the per state write op free quota in bytes.
• Lower the relative cost per byte write.

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

[msmouse]

The concrete gas parameter changes are part of https://github.com/aptos-foundation/AIPs/issues/286 which relies on the mechanism change (reads charged at page intervals, for example) introduced in this AIP.

[alnoki]

@msmouse as I understand it this AIP essentially accounts for cache hits/misses via 4KB pagewise awareness. On the read side the constant per-page (4KB) read cost is pretty straightforward.

But on the write-side the constant per-byte write cost is not page-aware: I understand that the on-the-fly merkle tree encryption is expense, but what about the cost to allocate each new page, e.g. the difference between a 4096 B write (1 page) and a 4097 byte write (2 pages)?

Also, since writing is already much more expensive than reading, I understand that this AIP highly incentivizes practices like bitpacking, which are of course storage optimized but can lead to memory leaks if not done properly. Is this understanding correct?

[msmouse]

what about the cost to allocate each new page

RocksDB, our underlying storage engine packs individual items writes to consecutive areas in the WAL and whole sst files, i.e. only large sequential writes, but page-based allocation for separate write ops. Relatively, only the total bytes matter while writing. (On reading however, the DB does need to seek to the particular value in the sst and load them by random IO.)

this AIP highly incentivizes practices like bitpacking, which are of course storage optimized.

Generally gas charges (other than the storage fees which is irrelevant to this AIP), calibrates towards latency impact to the execution of a transaction. Looking purely at the io gas dimensions it's always a good idea to compress things because that converts to faster loads and writes. However it can be a valid tradeoff to consider between time used to compress / decompress things versus time used to read / write things.