dido:public:ra:xapend:xapend.b_stds:defact:ethereum:eip:erc_0211
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
dido:public:ra:xapend:xapend.b_stds:defact:ethereum:eip:erc_0211 [2020/11/13 02:15] nick ↷ Page moved from dido:public:ra:xapend.stds:defact:ethereum:eip:erc_0211 to dido:public:ra:xapend:xapend.stds:defact:ethereum:eip:erc_0211 |
dido:public:ra:xapend:xapend.b_stds:defact:ethereum:eip:erc_0211 [2021/08/06 12:55] (current) murphy |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ==== EIP 211: New opcodes: RETURNDATASIZE and RETURNDATACOPY ==== | ==== EIP 211: New opcodes: RETURNDATASIZE and RETURNDATACOPY ==== | ||
| - | [[dido:public:ra:xapend.stds:defact:ethereum:eip| Return to Ethereum ERCs ]] | + | [[dido:public:ra:xapend:xapend.b_stds:defact:ethereum:eip| Return to Ethereum ERCs ]] |
| : **Note**: The following is an excerpt from the official Ethereum site. It is provided here as a convenience and is not authoritative. Refer to the original document as the authoritative reference. | : **Note**: The following is an excerpt from the official Ethereum site. It is provided here as a convenience and is not authoritative. Refer to the original document as the authoritative reference. | ||
| Line 17: | Line 17: | ||
| === Simple Summary / Abstract === | === Simple Summary / Abstract === | ||
| - | : //A mechanism to allow returning arbitrary-length data inside the EVM has been requested for quite a while now. Existing proposals always had very intricate problems associated with charging gas. This proposal solves the same problem while at the same time, it has a very simple gas charging mechanism and requires minimal changes to the call opcodes. Its workings are very similar to the way ''calldata'' is handled already; after a call, return data is kept inside a virtual buffer from which the caller can copy it (or parts thereof) into memory. At the next call, the buffer is overwritten. This mechanism is 100% backwards compatible.// | + | : //A mechanism to allow returning arbitrary-length data inside the EVM has been requested for quite a while now. Existing proposals always had very intricate problems associated with charging [[dido:public:ra:xapend:xapend.a_glossary:g:gas|gas]]. This proposal solves the same problem while at the same time, it has a very simple gas charging mechanism and requires minimal changes to the call opcodes. Its workings are very similar to the way ''calldata'' is handled already; after a call, return data is kept inside a virtual buffer from which the caller can copy it (or parts thereof) into memory. At the next call, the buffer is overwritten. This mechanism is 100% backwards compatible.// |
| | | ||
| === Motivation === | === Motivation === | ||
| : //In some situations, it is vital for a function to be able to return data whose length cannot be anticipated before the call. In principle, this can be solved without alterations to the EVM, for example by splitting the call into two calls where the first is used to compute only the size. All of these mechanisms, though, are very expensive in at least some situations. A very useful example of such a worst-case situation is a generic forwarding contract; a contract that takes call data, potentially makes some checks and then forwards it as is to another contract. The return data should of course be transferred in a similar way to the original caller. Since the contract is generic and does not know about the contract it calls, there is no way to determine the size of the output without adapting the called contract accordingly or trying a logarithmic number of calls.// | : //In some situations, it is vital for a function to be able to return data whose length cannot be anticipated before the call. In principle, this can be solved without alterations to the EVM, for example by splitting the call into two calls where the first is used to compute only the size. All of these mechanisms, though, are very expensive in at least some situations. A very useful example of such a worst-case situation is a generic forwarding contract; a contract that takes call data, potentially makes some checks and then forwards it as is to another contract. The return data should of course be transferred in a similar way to the original caller. Since the contract is generic and does not know about the contract it calls, there is no way to determine the size of the output without adapting the called contract accordingly or trying a logarithmic number of calls.// | ||
| - | : //Compiler implementors are advised to reserve a zero-length area for return data if the size of the return data is unknown before the call and then use ''RETURNDATACOPY'' in conjunction with ''RETURNDATASIZE'' to actually retrieve the data.// | + | : //[[dido:public:ra:xapend:xapend.a_glossary:c:compiler|Compiler]] implementors are advised to reserve a zero-length area for return data if the size of the return data is unknown before the call and then use ''RETURNDATACOPY'' in conjunction with ''RETURNDATASIZE'' to actually retrieve the data.// |
| ://**Note** this proposal also makes the EIP that proposes to allow to return data in case of an intentional state reversion (EIP-140) much more useful. Since the size of the failure data might be larger than the regular return data (or even unknown), it is possible to retrieve the failure data after the CALL opcode has signalled a failure, even if the regular output area is not large enough to hold the data.// | ://**Note** this proposal also makes the EIP that proposes to allow to return data in case of an intentional state reversion (EIP-140) much more useful. Since the size of the failure data might be larger than the regular return data (or even unknown), it is possible to retrieve the failure data after the CALL opcode has signalled a failure, even if the regular output area is not large enough to hold the data.// | ||
dido/public/ra/xapend/xapend.b_stds/defact/ethereum/eip/erc_0211.1605251724.txt.gz · Last modified: 2020/11/13 02:15 by nick
