Improve memory metering for WASM VMs

[mootz12]

Problem

As Stellar's DeFi ecosystem grows, protocols built on top of other protocols are performing lots of cross-contract calls. The way memory is metered for WASM VMs puts an artificial ceiling on how many cross-contract calls fit within the per-transaction 40 MB mem_bytes limit.

By default, contracts compiled with stellar-cli declare a WASM linear memory with a ~1 MiB initial size. Each VM instantiation accrues that amount (+ more) to the mem_bytes meter and does not credit any back when the VM is torn down. For contracts with lots of sequential cross-contract calls, this causes them to hit mem_bytes limits without using much memory.

This has impacted builders a few times recently:

• Discussion to bypass cross-contract call mechanics to read data -> https://github.com/orgs/stellar/discussions/1958
• Discord question about hitting this building an interest rate derivatives protocol -> https://discord.com/channels/897514728459468821/1519974752771375164

Proposal

We add the ability to credit memory allocated for a WASM VM after it's frame is popped back to mem_bytes.

Alternatives

• The stellar-cli can likely safely reduce the WASM stack size down from 1 MiB for contract builds. However, this doesn't help contracts that are already live, like Blend. This should be explored regardless of the outcome of this discussion.

[mihaieremia]

Just to add more context, the best return on investment of such change will actually be towards the oracle providers, then the core lending/defi protocols.

If oracles will re build and re deploy the existing contracts with the new linear memory reduced, many protocols (mine included) will be more efficent in reading a bunch of prices for complex positions and in the future ETF style contracts calculating NAV, ETF price.

[leighmcculloch]

Another alternative that I think should be considered is to increase the 40 MB mem_bytes limit. That limit was set quite sometime ago and I doubt is anywhere near the actual limit that could be supported.

But, the proposal to credit memory allocated back after the frame is popped seems preferred, given that the memory should have been released then, unless there's some outsized cost to doing so.

[mihaieremia]

Indeed, that was also my first "quick" fix, but since I am still new to Stellar, I didn't know the reasoning behind the 40 MB decision :))

[jayz22]

Agree with proposed approach of refunding memory on VM teardown, as it makes most contracts cheaper and matches better with reality. Since this is a strict improvement to the host internal (the only observable being cheaper budget number), I think we can fix it and roll it out as an internal improvement in the next protocol.

[mootz12]

Awesome! Thanks! Is there an issue or branch I could link here to connect the work to the discussion?

[mihaieremia]

Amazing, can’t wait to see the result!

Meanwhile, I’ve tested the compile flag with Reflector on testnet and their contracts no longer consume the 1 MB.
This week they’ll roll it out on mainnet contracts too, so all currently deployed protocols using Reflector will get the benefit. It should compound even further once the memory refunding on VM teardown goes live as well 🔥

[leighmcculloch]

Is there an issue or branch I could link here to connect the work to the discussion?

• Refund transient VM linear-memory budget at VM teardown rs-soroban-env#1707