This TIP proposes increasing Bounce message size from 32 bytes to a bigger size (e.g. 1024 bytes).
Motivation
Current Bounce message size is 32 bytes and first 4 bytes are always Function ID. That leaves the developers with 28 bytes (224 bits) of effective space to recover bounced message contents. Assuming the call has several variables (including address or uint256 types), current approach to handle the Bounce is creating local variables that store each call information.
Increasing the limit even to 1 Kb will allow most of the functions to bounce the variables back properly and contracts to receive all the data needed for Bounce processing.
P.S. Currently it costs 0.01 TON in forward fees to send 1Kb of data in Free TON blockchain.
P.P.S. New Bounce message size is also a subject of discussion.
Whenever I see some magic number, I ask. Why not n * 2, why not n / 2, why not n * 100?
Why 1Kb, why not 2Kb, or 100Kb? 1Kb will be enough for some calls but not for another calls. Any statistics?
I see 2 solutions.
Remove limit if this do not broke fee system.
Make possible send uint256 id instead uint128. 32 + 256 = 288 - total bits capacity for bounced messages.
New Bounce message size is also a subject of discussion
The current limit is there not just randomly (or is it?), so, I tried to use a number (1 Kb is an example) to keep the balance between forward fees and data amount. Removing the limit is the best option imo, because sender will pay for bounced message.
How about adding a new parameter to external function call? (LINK)
By default bounce message size is unlimited, but the parameter will limit the bounce message size to the specified number of bytes, like this:
IContract(address).function{value: 1 ton, bounce: true, bounce_bytes: 32}(123);