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

Embedding transaction status code in receipts #658

Merged
merged 6 commits into from Nov 30, 2017

Conversation

Projects
None yet
@Arachnid
Collaborator

Arachnid commented Jun 30, 2017

This EIP replaces the intermediate state root field of the receipt with either the contract return data and status, or a hash of that value.

@tjayrush

This comment has been minimized.

Show comment
Hide comment
@tjayrush

tjayrush Jun 30, 2017

May I ask, in option 2, why you use "GetReturnData and ReturnData, permitting nodes to fetch the status and return data" as opposed to say GetStatus and GetReturnData which would match the names of items presumably being retrieved?

tjayrush commented Jun 30, 2017

May I ask, in option 2, why you use "GetReturnData and ReturnData, permitting nodes to fetch the status and return data" as opposed to say GetStatus and GetReturnData which would match the names of items presumably being retrieved?

@karalabe

This comment has been minimized.

Show comment
Hide comment
@karalabe

karalabe Jun 30, 2017

Member

Given that everywhere the 0 status code means success, should we really invert it here? If you want to stick to it, then perhaps lets call it "Success" and not "Status"?

Member

karalabe commented Jun 30, 2017

Given that everywhere the 0 status code means success, should we really invert it here? If you want to stick to it, then perhaps lets call it "Success" and not "Status"?

@cdetrio

This comment has been minimized.

Show comment
Hide comment
@cdetrio

cdetrio Jun 30, 2017

Member

Full nodes can provide RPCs to get a transaction return status and value by replaying the transaction, but fast nodes can only do this for nodes after their pivot point, and light nodes cannot do this at all, making a non-consensus solution impractical.

Can't light clients replay a tx by fetching the state branches (merkle proofs) for all accounts that the tx touches? Since within a block any prior tx may have modified an account, all prior tx's would also have to be replayed. But in principle, light clients are capable of replaying transactions.

Member

cdetrio commented Jun 30, 2017

Full nodes can provide RPCs to get a transaction return status and value by replaying the transaction, but fast nodes can only do this for nodes after their pivot point, and light nodes cannot do this at all, making a non-consensus solution impractical.

Can't light clients replay a tx by fetching the state branches (merkle proofs) for all accounts that the tx touches? Since within a block any prior tx may have modified an account, all prior tx's would also have to be replayed. But in principle, light clients are capable of replaying transactions.

@Arachnid

This comment has been minimized.

Show comment
Hide comment
@Arachnid

Arachnid Jun 30, 2017

Collaborator

@tjayrush

May I ask, in option 2, why you use "GetReturnData and ReturnData, permitting nodes to fetch the status and return data" as opposed to say GetStatus and GetReturnData which would match the names of items presumably being retrieved?

Typo, thanks.

@karalabe

Given that everywhere the 0 status code means success, should we really invert it here? If you want to stick to it, then perhaps lets call it "Success" and not "Status"?

The CALL opcode returns 0 on failure and 1 on success.

Collaborator

Arachnid commented Jun 30, 2017

@tjayrush

May I ask, in option 2, why you use "GetReturnData and ReturnData, permitting nodes to fetch the status and return data" as opposed to say GetStatus and GetReturnData which would match the names of items presumably being retrieved?

Typo, thanks.

@karalabe

Given that everywhere the 0 status code means success, should we really invert it here? If you want to stick to it, then perhaps lets call it "Success" and not "Status"?

The CALL opcode returns 0 on failure and 1 on success.

@cdetrio

This comment has been minimized.

Show comment
Hide comment
@cdetrio

cdetrio Jul 14, 2017

Member

If something like EIP 101 is eventually adopted, I'm wondering how it would interact with a definition of failure as "any operation that can cause the transaction or top-level call to revert."

Under EIP 101, wouldn't the "top-level call" be the execution which pays the gas fee to the miner? Then every transaction that pays a gas fee to block.coinbase would be a success, and only those transactions that revert the gas payments would be failures.

Member

cdetrio commented Jul 14, 2017

If something like EIP 101 is eventually adopted, I'm wondering how it would interact with a definition of failure as "any operation that can cause the transaction or top-level call to revert."

Under EIP 101, wouldn't the "top-level call" be the execution which pays the gas fee to the miner? Then every transaction that pays a gas fee to block.coinbase would be a success, and only those transactions that revert the gas payments would be failures.

@Arachnid

This comment has been minimized.

Show comment
Hide comment
@Arachnid

Arachnid Jul 14, 2017

Collaborator

After out of band discussion with Vitalik and others, I've amended this proposal to simply insert a 1 byte return status (1 for success, 0 for failure).

Collaborator

Arachnid commented Jul 14, 2017

After out of band discussion with Vitalik and others, I've amended this proposal to simply insert a 1 byte return status (1 for success, 0 for failure).

pirapira added a commit to pirapira/yellowpaper that referenced this pull request Jul 17, 2017

Implement EIP-658 ethereum/EIPs#658
Now transaction receipts contain one byte indicating success or failure.
@axic

This comment has been minimized.

Show comment
Hide comment
@axic

axic Jul 28, 2017

Member

I am not fully familiar with this part of the protocol, but does this EIP only refer to a P2P message or does it also influence what the eth_transactionReceipt RPC call do?

If the latter, wouldn't it make sense including a third option to signal revert as mentioned in #206 (comment)?

Member

axic commented Jul 28, 2017

I am not fully familiar with this part of the protocol, but does this EIP only refer to a P2P message or does it also influence what the eth_transactionReceipt RPC call do?

If the latter, wouldn't it make sense including a third option to signal revert as mentioned in #206 (comment)?

@cdetrio

This comment has been minimized.

Show comment
Hide comment
@cdetrio

cdetrio Jul 28, 2017

Member

Since this will encompass #98, how about Replacing intermediate state roots with return data in transaction receipts for a title?

Member

cdetrio commented Jul 28, 2017

Since this will encompass #98, how about Replacing intermediate state roots with return data in transaction receipts for a title?

@MicahZoltu

This comment has been minimized.

Show comment
Hide comment
@MicahZoltu

MicahZoltu Jul 29, 2017

Contributor

The motivation section discusses including return/revert data, yet the specification section doesn't mention it. Is this specification incomplete? If so I recommend adding a TBD or something to make that more clear for the time being. If not, am I missing something about how return/revert data is provided for in the transaction receipt?

Contributor

MicahZoltu commented Jul 29, 2017

The motivation section discusses including return/revert data, yet the specification section doesn't mention it. Is this specification incomplete? If so I recommend adding a TBD or something to make that more clear for the time being. If not, am I missing something about how return/revert data is provided for in the transaction receipt?

@pirapira pirapira referenced this pull request Aug 2, 2017

Closed

Byzantium changes #229

12 of 12 tasks complete
@holgerd77

This comment has been minimized.

Show comment
Hide comment
@holgerd77

holgerd77 Aug 2, 2017

Can someone add example cases for the different outcomes with concrete exemplary values to the specification?

holgerd77 commented Aug 2, 2017

Can someone add example cases for the different outcomes with concrete exemplary values to the specification?

@rjl493456442

This comment has been minimized.

Show comment
Hide comment
@rjl493456442

rjl493456442 Aug 18, 2017

Member

@Arachnid
To sum up, from METROPOLIS_FORK_BLKNUM later, the PostState field in receipt will been replaced by a field called Status, which indicates the transaction execution result.
The Status field is a single byte, 0x01 represents successfully execution and 0x00 represent s a failure occured(No matter accidental error or a Revert opcode called).
And the field will be added into the consensus comparison. Right?

Member

rjl493456442 commented Aug 18, 2017

@Arachnid
To sum up, from METROPOLIS_FORK_BLKNUM later, the PostState field in receipt will been replaced by a field called Status, which indicates the transaction execution result.
The Status field is a single byte, 0x01 represents successfully execution and 0x00 represent s a failure occured(No matter accidental error or a Revert opcode called).
And the field will be added into the consensus comparison. Right?

@holgerd77

This comment has been minimized.

Show comment
Hide comment
@holgerd77

holgerd77 Aug 29, 2017

@Arachnid This PR lacks very much a concrecte specification, are you still responsible for this and can update this since the EIP is actually getting into Byzantium?

holgerd77 commented Aug 29, 2017

@Arachnid This PR lacks very much a concrecte specification, are you still responsible for this and can update this since the EIP is actually getting into Byzantium?

@pirapira

I commented about some formalities. After a week of silence, I would edit the PR accordingly.

@pirapira

This comment has been minimized.

Show comment
Hide comment
@pirapira

pirapira Nov 20, 2017

Member

I'll also change the filename.

Member

pirapira commented Nov 20, 2017

I'll also change the filename.

@Arachnid

This comment has been minimized.

Show comment
Hide comment
@Arachnid

Arachnid Nov 20, 2017

Collaborator

@pirapira PTAL.

Collaborator

Arachnid commented Nov 20, 2017

@pirapira PTAL.

@pirapira

This comment has been minimized.

Show comment
Hide comment
@pirapira

pirapira Nov 20, 2017

Member

@Arachnid the changes look good. Thanks.

I still need to

  • change the filename
  • give some time for others to respond to #658 (comment)
Member

pirapira commented Nov 20, 2017

@Arachnid the changes look good. Thanks.

I still need to

  • change the filename
  • give some time for others to respond to #658 (comment)
@tinybike

This comment has been minimized.

Show comment
Hide comment
@tinybike

tinybike Nov 21, 2017

Member

Should the title of this PR be updated, to reflect that it's now an EIP for the new status field in receipts, rather than returndata?

Member

tinybike commented Nov 21, 2017

Should the title of this PR be updated, to reflect that it's now an EIP for the new status field in receipts, rather than returndata?

@pirapira pirapira changed the title from Embedding transaction return data in receipts to Embedding transaction status code in receipts Nov 30, 2017

@pirapira

This comment has been minimized.

Show comment
Hide comment
@pirapira
Member

pirapira commented Nov 30, 2017

@tinybike done.

@pirapira pirapira merged commit 130153b into ethereum:master Nov 30, 2017

@Arachnid Arachnid deleted the Arachnid:returndata branch Nov 30, 2017

@SergioDemianLerner SergioDemianLerner referenced this pull request Dec 15, 2017

Merged

EIP 658 #333

pirapira added a commit to pirapira/yellowpaper that referenced this pull request Jan 19, 2018

Implement EIP-658 ethereum/EIPs#658
Now transaction receipts contain one byte indicating success or failure.

pirapira added a commit to pirapira/yellowpaper that referenced this pull request Jan 19, 2018

Implement EIP-658 ethereum/EIPs#658
Now transaction receipts contain one byte indicating success or failure.

pirapira added a commit to pirapira/yellowpaper that referenced this pull request Jan 19, 2018

Implement EIP-658 ethereum/EIPs#658
Now transaction receipts contain one byte indicating success or failure.

@hrntknr hrntknr referenced this pull request Feb 14, 2018

Open

Error handling #1315

@ivica7

This comment has been minimized.

Show comment
Hide comment
@ivica7

ivica7 Mar 2, 2018

After consultation with others, I dropped it because of concerns about DoS and spam opportunities; return data isn't charged for (except for memory expansion) but if it's part of consensus, would have to be stored indefinitely with receipts. It's still a possibility to add this to later forks, but I didn't want to rush in something that wasn't fully thought out.

@Arachnid DoS and Spam opportunities are a problem, but IMHO a good compromise would have been to allow to return an arbitrary 8-bit return code with the meaning 0=success, everything else an error. With 0/1 limitation we're only slightly better compared to earlier where we checked gasSent==gasUsed. On the UI side the message that can be presented to the user is only: "Everything is good" or "Something is wrong" -> bad user experience. I hope one day the specification for this will be extended.

ivica7 commented Mar 2, 2018

After consultation with others, I dropped it because of concerns about DoS and spam opportunities; return data isn't charged for (except for memory expansion) but if it's part of consensus, would have to be stored indefinitely with receipts. It's still a possibility to add this to later forks, but I didn't want to rush in something that wasn't fully thought out.

@Arachnid DoS and Spam opportunities are a problem, but IMHO a good compromise would have been to allow to return an arbitrary 8-bit return code with the meaning 0=success, everything else an error. With 0/1 limitation we're only slightly better compared to earlier where we checked gasSent==gasUsed. On the UI side the message that can be presented to the user is only: "Everything is good" or "Something is wrong" -> bad user experience. I hope one day the specification for this will be extended.

@aerth aerth referenced this pull request Jun 5, 2018

Merged

HF7 @ 36050 #24

sabondano added a commit to poanetwork/blockscout that referenced this pull request Sep 19, 2018

Derive status from internal transaction at index 0
Why:

* Issue #757 was created after we noticed a few constraint violations
for the `error` column in the `transactions` table. The constraint
violations came about as we attempted to update transactions with a
successful status but some value for the error field. The constraint
is violated in this scenario because we expect successful transactions
to not have an error. (EIP
658)[ethereum/EIPs#658], which apparently is
also called (EIP
98)[ethereum/EIPs#98 (comment)]
, says that the status should be set to 1 (success) if the outermost
code execution succeeded (internal transaction with index 0), or it
should be set to 0 (failure) if the outermost code execution failed.
We're currently deriving the status from the last internal transaction
when in fact we should be deriving it from the first internal
transaction.
* Issue link: #757

This change addresses the need by:

* Editing `Explorer.Chain.Import.update_transactions/2` to set the error
for a transaction equal to the error, if any, of the internal
transaction with index 0.
* Editing `Explorer.Chain.Import.update_transactions/2` to set a
transaction's status as successful if it's internal transaction at index
0 doesn't have an error.

sabondano added a commit to poanetwork/blockscout that referenced this pull request Sep 19, 2018

Derive status from internal transaction at index 0
Why:

* Issue #757 was created after we noticed a few constraint violations
for the `error` column in the `transactions` table. The constraint
violations came about as we attempted to update transactions with a
successful status but some value for the error field. The constraint
is violated in this scenario because we expect successful transactions
to not have an error. (EIP
658)[ethereum/EIPs#658], which apparently is
also called (EIP
98)[ethereum/EIPs#98 (comment)]
, says that the status should be set to 1 (success) if the outermost
code execution succeeded (internal transaction with index 0), or it
should be set to 0 (failure) if the outermost code execution failed.
We're currently deriving the status from the last internal transaction
when in fact we should be deriving it from the first internal
transaction.
* Issue link: #757

This change addresses the need by:

* Editing `Explorer.Chain.Import.update_transactions/2` to set the error
for a transaction equal to the error, if any, of the internal
transaction with index 0.
* Editing `Explorer.Chain.Import.update_transactions/2` to set a
transaction's status as successful if it's internal transaction at index
0 doesn't have an error.

sabondano added a commit to poanetwork/blockscout that referenced this pull request Sep 19, 2018

Derive status from internal transaction at index 0
Why:

* Issue #757 was created after we noticed a few constraint violations
for the `error` column in the `transactions` table. The constraint
violations came about as we attempted to update transactions with a
successful status but some value for the error field. The constraint
is violated in this scenario because we expect successful transactions
to not have an error. [EIP 658](ethereum/EIPs#658),
which apparently is also called [EIP 98](ethereum/EIPs#98 (comment))
, says that the status should be set to 1 (success) if the outermost
code execution succeeded (internal transaction with index 0), or it
should be set to 0 (failure) if the outermost code execution failed.
We're currently deriving the status from the last internal transaction
when in fact we should be deriving it from the first internal
transaction.
* Issue link: #757

This change addresses the need by:

* Editing `Explorer.Chain.Import.update_transactions/2` to set the error
for a transaction equal to the error, if any, of the internal
transaction with index 0.
* Editing `Explorer.Chain.Import.update_transactions/2` to set a
transaction's status as successful if it's internal transaction at index
0 doesn't have an error.

sabondano added a commit to poanetwork/blockscout that referenced this pull request Sep 19, 2018

Derive status from internal transaction at index 0
Why:

* Issue #757 was created after we noticed a few constraint violations
for the `error` column in the `transactions` table. The constraint
violations came about as we attempted to update transactions with a
successful status but some value for the error field. The constraint
is violated in this scenario because we expect successful transactions
to not have an error. [EIP 658](ethereum/EIPs#658),
which apparently is also called [EIP 98](ethereum/EIPs#98 (comment))
, says that the status should be set to 1 (success) if the outermost
code execution succeeded (internal transaction with index 0), or it
should be set to 0 (failure) if the outermost code execution failed.
We're currently deriving the status from the last internal transaction
when in fact we should be deriving it from the first internal
transaction.
* Issue link: #757

This change addresses the need by:

* Editing `Explorer.Chain.Import.update_transactions/2` to set the error
for a transaction equal to the error, if any, of the internal
transaction with index 0.
* Editing `Explorer.Chain.Import.update_transactions/2` to set a
transaction's status as successful if it's internal transaction at index
0 doesn't have an error, and as failed if it does. This only applies to
pre-Byzantium and Ethereum Classic, for which transaction status is not
set from receipts.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment