status-im
/
EIPs
mirror of https://github.com/status-im/EIPs.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

Update eip-draft-returndata.md

This commit is contained in:
Nick Johnson 2017-11-20 13:06:48 +00:00 committed by GitHub
parent 947e765043
commit 47e30db9f3
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
EIPS/eip-draft-returndata.md
View File

@ -1,11 +1,11 @@
## Preamble ## Preamble
EIP: <to be assigned> EIP: 658
Title: Embedding transaction return data in receipts Title: Embedding transaction status code in receipts
Author: Nick Johnson <nick@ethereum.org> Author: Nick Johnson <nick@ethereum.org>
Type: Standard Track Type: Standard Track
Category Core Category Core
Status: Draft Status: Final
Created: 2017-06-30 Created: 2017-06-30
Requires: 140 Requires: 140
Replaces: 98 Replaces: 98
@ -22,7 +22,7 @@ Full nodes can provide RPCs to get a transaction return status and value by repl
Instead, we propose to replace the intermediate state root, already obsoleted by EIP98, with the return status (1 for success, 0 for failure). This both allows callers to determine success status, and remedies the previous omission of return data from the receipt. Instead, we propose to replace the intermediate state root, already obsoleted by EIP98, with the return status (1 for success, 0 for failure). This both allows callers to determine success status, and remedies the previous omission of return data from the receipt.
## Specification ## Specification
For blocks where block.number >= METROPOLIS_FORK_BLKNUM, the intermediate state root is replaced by a status code, 0 indicating failure (due to any operation that can cause the transaction or top-level call to revert) and 1 indicating success. For blocks where block.number >= BYZANTIUM_FORK_BLKNUM, the intermediate state root is replaced by a status code, 0 indicating failure (due to any operation that can cause the transaction or top-level call to revert) and 1 indicating success.
## Rationale ## Rationale
This constitutes a minimal possible change that permits fetching the success/failure state of transactions, preserving existing capabilities with minimum disruption or additional work for Metropolis. This constitutes a minimal possible change that permits fetching the success/failure state of transactions, preserving existing capabilities with minimum disruption or additional work for Metropolis.