EIP 5: Gas costs for return values

[chriseth]

Proposal

Change memory gas costs for return values of a call to be applied depending on the size of the written memory area, not the reserved memory area.

Current Situation

In a call, the caller has to provide an area where the returned data from a call is written to. Only reserving it already changes gas costs for memory.

Advantage

This makes it possible to read a return value whose size is not known to the caller prior to the call: The caller just reserves a huge amount of memory.

Possible Extension

The CALL opcode (and its friends) may even return the actual size of memory written to, so that the data can be used (e.g. forwarded) even if nothing is known about its structure.

Implementation

The implementation might be a bit tricky: The CALL opcode has to be charged some gas upfront, then the call is performed without allocating memory for the return value. At the point, the return value is available, gas costs are computed and if some gas is still available, memory is allocated and written to.

[pipermerriam]

This would be quite useful from a contract/library author's perspective. It currently requires some major hoop jumping to get bytes from another contract.

[Nashatyrev]

Voting for this proposal. IMHO this will be a huge jump to multi-contract apps.

[wanderer]

applied depending on the size of the written memory area, not the reserved memory area.

So would there be a max allocation size the the callee would specify?

[vbuterin]

I have thought about this a bit more in the last day and tried to implement some generic call forwarding stuff in serpent, and have really come to appreciate the wisdom of this change and how much easier it would make it to do a lot of things.

So would there be a max allocation size the the callee would specify?

Yes. However, if you trust the callee absolutely, you can just set it to 2**100; but this isn't as scary as it seems as contracts trust the callee with all of their gas by default already.

[obscuren]

👍

[vbuterin]

Here is my proposed implementation in python:

The way it currently works: http://vitalik.ca/files/old.py
After the proposed change: http://vitalik.ca/files/new.py

[wanderer]

lgtm

[janx]

+1

[nmushegian]

+1! This unlocks the full potential of "dynamic" contracts. Without this, you can't use Solidity to write a contract that could be updated to implement an arbitrary Solidity ABI.

[PeterBorah]

What is the status of this proposal? I'm currently running into this issue. :)