Link return values by CID in receipts

[Stebalien]

Currently, return values are directly embedded in receipts. However:

• Return values may be large (up to a megabyte). Embedding them in receipts forces clients to fetch said return value just to, e.g., view events, exit codes, etc. Worse, receipts are directly embedded in AMT nodes along with 8 other receipts.
• The return value does not specify the IPLD codec of the returned data. Right now this is ok because we always return CBOR. But we'll eventually want to return, e.g., raw data directly. Not including the codec makes it hard for clients to decode return data.

My proposal here is to link to return values by CID in on-chain receipts. This solves both problems at the cost of hashing return value.

In terms of gas, this would cost an extra 10gas/byte on top of the current 1300/byte storage fee (<1% increase). In terms of performance:

1. This would make receipts slightly larger for small return values (unless we introduced some rule for inline CIDs).
2. Most "simple" return values would get deduplicated in the blockstore itself.

[anorth]

This conceptually makes sense. Do you have any data on the size of return values today? I realise this data may not indicate the future, since new smart contracts might return large items.

• Would this affect inter-actor calls in any way?
• For the many small return values, I do think using inline CIDs should be used, at least up to ~40 bytes. Otherwise we'd be making them larger and less convenient.

[Stebalien]

Do you have any data on the size of return values today?

I don't but I do think they're pretty small. However:

1. I want to allow large return values, actor to actor.
2. I'd like to minimize the differences between actor to actor calls and off-chain calls. So I'd rather not impose additional return-value size constraints for top-level calls.

Would this affect inter-actor calls in any way?

No.

For the many small return values, I do think using inline CIDs should be used, at least up to ~40 bytes. Otherwise we'd be making them larger and less convenient.

I agree on the size difference, I don't agree on the convenience. I don't want users to hard-code assumptions that values will be inlined when they may not be.