-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Get contract return values from transaction recepts #1288
Comments
I believe in the past this has been punted on because of the unbounded size of a contract's result. For example, if a contract returns a string or an array of values the size of the receipt is now unbounded. Since receipts are part of consensus, they need to be kept small/constrained. One option would be to only return the first 32 bytes of the result. This greatly limits what you can usefully return, but would solve the problem for a lot of people. 32 bytes is enough to give an exit code result, a number result, an address result, etc. |
@MicahZoltu a contracts result isn't unbounded as the stack size is pretty shallow. (at least in solidity, correct me if I'm wrong) Strings don't exist in the EVM, just a bunch of uint256s. If you push a "string" on the stack which is greater than 32 chars long, it pushes multiple uint256s internally. |
@ARitz-Cracker The return value of a contract call is a section of memory, not stack elements. It can be as large as the contract's memory space. As @MicahZoltu observes, we punted on this before because of the issue of determining what a fair qas cost would be. |
I think it would be fair to return only the first 32 bytes. Any critical information should be able to be conveyed this way. Getting return values of contracts would be convenient, but what would really help me as a developer is if I can get the revert reason through the transaction receipt (preventing out-commenting/logging/redeploying thousands of times). |
@ARitz-Cracker Have you seen EIP 758? It is an alternative proposal to retrieve the return value of a mined transaction. I believe it should be mentioned in this ERC as well. There was some discussion about receipts in the associated issue #758. |
@frangio I swear I looked through all the EIPs before submitting this one 😅 looks like I missed it! |
Here's the pull request
Simple Summary
This is a proposal to give clients the ability to easily get contract return values and revert reasons from already completed transactions.
Abstract
This EIP proposes to allow eth_getTransactionReceipt to show return values from a smart contract executon, similarly to eth_call.
Motivation
Clients have no reliable way to get why a transaction has failed when mined, nor can they get the return value from a successful smart contract execution. A workaround would be to use eth_call before or after the transaction is mined, but that is unreliable since the state of a smart contract can change multiple times within the same block.
For example, any eth_call checks or gas estimations may return OK before the transaction is submitted to the mempool, but your transaction may be reverted due to the actions of one that got in just before you.
Expanding on this example, your transaction may have been between 2 other transactions which affected yours, so any eth_call checks on that block or the previous block return an unexpected value, resulting in much frustration. and confusion.
Specification
Take the result of eth_call and put it in eth_getTransactionReceipt's returning object; using a field called
contractResult
.The return values can be interpreted using the ABI if status == 1, or as a string when status == 0.
Example
Rationale
This implementation proposal kills 2 birds with one stone, allowing for revert reasons and successful return values to be accessable by the client. This proposal was designed to require minimal work for implementation, and to take advantage of already existing infrastructure.
Backwards Compatibility
This proposal will not break anything that relies on existing behaviour.
Copyright
Copyright and related rights waived via CC0.
The text was updated successfully, but these errors were encountered: