REVERT instruction #206

axic · 2017-02-06T19:55:15Z

Replaces #140.

axic · 2017-02-06T20:07:58Z

EIPS/eip-draft_revert_opcode.md

@@ -0,0 +1,47 @@
+## Preamble
+
+    EIP: <to be assigned>


I assume we did assign 140 for this, given issue 140 was accepted.

You can either assign the issue or PR number. In this case it would be better to assign the issue # since that is what it has been referred to most widely.

axic · 2017-02-06T21:52:30Z

I wonder if it would make sense adjusting CALL (and CALLCODE, DELEGATECALL) to indicate a REVERT.

Currently, CALL (& co) will return 1 on success and 0 in in case it failed. Perhaps code 2 could be returned in case of REVERT. Downside is that Solidity contracts would not be backwards compatible.

Likely it would make sense to take this into consideration when designing the successor of CALL and not touching the current one.

chriseth · 2017-02-07T09:23:59Z

For the sake of backwards compatibility, anything that reverts state changes should signal a "failure" to the caller. Since we cannot distinguish the two cases where the callee did provide a return value and where it didn't, I would propose to postpone that feature until we have a means to signal this e.g. in a new call opcode: If the caller used the CALL opcode and the callee provided failure data, the data is discarded.

Arachnid · 2017-02-07T11:01:55Z

Returning 0 from a CALL that ends in a REVERT seems reasonable, though it would be easier to check returned data if contracts had a way to detect the length of returned data; at present they could at least zero the return memory area before calling (or we could HF to specify CALL does that).

axic · 2017-02-07T12:29:32Z

I agree it is better to make this low impact by not touching CALL at the moment. External callers (i.e. users of the RPC) will still be able distinguish and retrieve and error message.

Arachnid · 2017-02-07T12:31:05Z

If we add it without any return support initially, then it'll be even more complex to add it later. Shouldn't we try and solve this once-and-for-all?

axic · 2017-02-07T12:44:10Z

I mean that CALL wouldn't differentiate and would ignore the return value. However, the return value would still be available through external calls, such as a transaction or anything invoked via an RPC.

Arachnid · 2017-02-07T12:47:39Z

Wouldn't it make more sense to have CALL copy the return value, though? Does Solidity currently make any assumptions about the return memory area in case of a failed call?

chriseth · 2017-02-07T12:54:38Z

@Arachnid if revert writes to the same memory area as return then the caller has to be able to distinguish the two cases. Since the ABI does not have an unused bit, I don't see a good way to put the distinction into the data. The only other option (apart from a new call opcode) I see is returning 2 in case of reversion, but that would signal a success condition to older code, which is probably not what you would want.

Arachnid · 2017-02-07T12:57:54Z

@Arachnid if revert writes to the same memory area as return then the caller has to be able to distinguish the two cases. Since the ABI does not have an unused bit, I don't see a good way to put the distinction into the data.

If CALL returns 0, the data area contains any return data from a REVERT. If it returns 1, the data area contains any return data from a normal return. Both have the issue that you can't directly determine the return data length, but that's orthogonal.

chriseth · 2017-02-07T15:21:29Z

That's not correct: If CALL returns 0, the data area either contains the data from the revert or whatever was there before (because it was an OOG).

Arachnid · 2017-02-07T16:10:29Z

Right; just like if call returns 1 - the data area either contains the return data, or whatever was there before (if the return length was 0).

chriseth · 2017-02-08T18:59:51Z

@Arachnid the difference is that currently, with contracts adhering to the ABI, you always know the type of the contents from the type of the contract.

Arachnid · 2017-02-08T21:29:20Z

@chriseth That could still be the case - just extend the ABI spec to specify an ABI definition for error returns, too. The default would be 'null'.

VoR0220 · 2017-02-08T22:21:05Z

@chriseth there is a good way around this by just creating a new type in the ABI, that type being the "error" type. I fully agree with @Arachnid here. An error type has been sorely needed and missed here and has created much confusion for newcomers as to why the only error they ever get with their solidity code is "invalid jump dest.".

chriseth · 2017-02-09T11:00:51Z

@Arachnid @VoR0220 of course that can be done but we still need a flag to indicate whether the data is an error or regular return data.

Arachnid · 2017-02-09T11:21:13Z

@chriseth But we already have that flag - the return code of CALL. If it's zero, the return data - if any - follows the error ABI. If it's nonzero, the return data - if any - follows the return ABI.

chriseth · 2017-02-09T12:52:11Z

@Arachnid sure, but we have three situations instead of two: OOG, revert, success. There is currently no way to distinguish between OOG and revert, so new code that wants to read the revert error code has to clear the output area beforehand. In any case, it is really messy and complicated and thus I would propose to move the feature of actually reading the error data (not supplying it) to a new call opcode.

Arachnid · 2017-02-09T13:18:22Z

But what I'm saying is that the issue of "was any data returned" is orthogonal to returning the data; we already have this problem (and the need to zero out the data before calling) with regular returns, where the called contract could return 0 bytes of data and the caller wouldn't know.

It makes far more sense to me to just return error data using the existing mechanism, and then add a 'RETURNDATALEN' (or similar) opcode afterwards.

chriseth · 2017-02-09T13:21:34Z

Sure, but I would say that something like "returndatalen" should be a feature of the call opcode. I don't think it is a nice design if you can check the size of the returned data at any time after the call. This is another word of state the VM (and all related tools) have to keep.

Arachnid · 2017-02-09T13:52:44Z

I agree - a better CALL opcode would be an improvement. But I don't see why that means that CALL shouldn't return error data with the introduction of REVERT. We shouldn't make it impossible just because the current design is not ideal.

vbuterin · 2017-02-09T14:21:24Z

Looks good to me.

Arachnid · 2017-02-13T15:21:14Z

Update post all-core-devs meeting: The consensus was that REVERT should take the same arguments as RETURN, and CALL should return data provided to REVERT, with another EIP to be opened on improving handling of return data from CALL and other related opcodes.

pipermerriam · 2017-10-18T20:02:27Z

@Souptacular

Can this be merged now that Byzantium is live?

pirapira · 2017-11-17T18:04:51Z

EIPS/eip-140.md

+
+    EIP: 140
+    Title: REVERT instruction in the Ethereum Virtual Machine
+    Author: Alex Beregszaszi, Nikolai Mushegian (nikolai@nexusdev.us)


@chriseth do you want to be listed as an author for your paragraphs added in efd2333 ?

Would that be ok @axic?

pirapira · 2017-11-17T18:15:01Z

EIPS/eip-140.md

+
+## Motivation
+
+Currently this is not possible. There are two practical ways to revert a transaction from within a contract: running out of gas or executing an invalid instruction. Both of these options will consume all remaining gas. Additionally, reverting a transaction means that all changes, including LOGs, are lost and there is no way to convey a reason for aborting a transaction.


reverting a transaction

aborting a transaction

We are here talking about something smaller than a transaction. Perhaps "reverting an EVM execution" and "aborting an execution"?

pirapira · 2017-11-17T18:16:45Z

EIPS/eip-140.md

+
+## Specification
+
+The `REVERT` instruction is introduced at `0xfd`. It expects two stack items, the top item is the `memory_offset` followed by `memory_length`. It does not return anything because it stops execution.


return anything

is ambiguous. It might be talking about return data to the caller, or returned word on top of the stack.

Perhaps It does not produce any stack elements because it stops execution?

pirapira · 2017-11-17T18:22:29Z

EIPS/eip-140.md

+should:
+- return `726576657274206d657373616765` as `REVERT` data,
+- the storage at key `0x0` should be left as unset and
+- use 20024 gas in total.


20024 here should be interpreted as decimal while 726576657274206d657373616765 might be hex.

Would it hurt to add 0x in front of the hex?

pirapira

I left some small comments. After a week of silence, I'll apply those cosmetic changes myself.

frangio · 2017-11-17T19:23:55Z

The "Backwards Compatibility" section seems to imply that REVERT is treated as an invalid opcode for a contract created before the Byzantium hard fork.

Is this interpretation correct?

pirapira · 2017-11-20T09:48:21Z

@frangio you are correct with how you interpret the section. I'll leave a comment there.

pirapira · 2017-11-20T09:48:52Z

EIPS/eip-140.md

+
+## Backwards Compatibility
+
+This change has no effect on contracts created in the past.


This is not true if those contracts contain 0xfd as an instruction.

I'll add unless they contain 0xfd as an instruction after a week of silence.

Okay, that is a pretty important difference! IIRC Solidity had been emitting 0xfd opcodes several months before Byzantium, so there were many contracts out there whose behavior changed after being created.

1 week of silence. :)

ethereum#206 (comment)

pirapira · 2017-11-30T16:25:02Z

I think this EIP should say

If block.number >= BYZANTIUM_FORK_BLKNUM

I wait for another week and apply the change.

pirapira

Looks good to me.

cleanunicorn · 2018-03-06T13:09:56Z

If REVERT is called with a message where is this returned?
Will this be returned in eth_getTransactionReceipt for that transaction?

pirapira · 2018-03-06T13:12:49Z

The message is returned to the caller if the caller is also a program in EVM.

Transaction receipts do not contain the REVERTed messages (that was once considered).

axic commented Feb 6, 2017

View reviewed changes

axic mentioned this pull request Feb 6, 2017

New opcode: REVERT ("cheap throw") #140

Closed

This was referenced Feb 6, 2017

Data structure for the REVERT instruction #207

Closed

Implement REVERT (EIP140) ethereum/solidity#1661

Merged

axic mentioned this pull request Feb 7, 2017

All Core Devs Meeting 10 Agenda ethereum/pm#5

Closed

Souptacular mentioned this pull request Feb 10, 2017

Metropolis Plan Discussion ethereum/pm#4

Closed

3 tasks

pirapira mentioned this pull request Feb 10, 2017

Byzantium changes ethereum/yellowpaper#229

Closed

12 tasks

pirapira mentioned this pull request Feb 13, 2017

EIP140: REVERT ethereum/yellowpaper#232

Closed

pipermerriam mentioned this pull request Oct 20, 2017

Byzantium Fork Rules ethereum/py-evm#123

Merged

9 tasks

pirapira mentioned this pull request Oct 23, 2017

Apply Byzantium changes pirapira/eth-isabelle#459

Open

10 tasks

pirapira reviewed Nov 17, 2017

View reviewed changes

pirapira suggested changes Nov 17, 2017

View reviewed changes

5chdn mentioned this pull request Nov 18, 2017

Move Meta Byzantium to Finalized #770

Closed

pirapira reviewed Nov 20, 2017

View reviewed changes

pirapira added 3 commits November 30, 2017 17:16

Limit the backward compatibility

3355c09

ethereum#206 (comment)

Change the status to Final

1d93a80

Improvements after a week of silence on ethereum#206

8e92d5b

pirapira and others added 3 commits December 1, 2017 18:14

Merge branch 'master' into revert

a5eb63d

Merge branch 'master' into revert

f0298a1

Simplify the title

bccf7d1

axic changed the title ~~Draft EIP for the REVERT opcode~~ REVERT instruction Dec 5, 2017

Update eip-140.md

75121e2

pirapira approved these changes Dec 8, 2017

View reviewed changes

pirapira merged commit 75edcfd into ethereum:master Dec 8, 2017

pirapira deleted the revert branch December 8, 2017 11:01

Dexaran mentioned this pull request Dec 30, 2017

ECIP-1040: Generalized Account Versioning Scheme for Hard Fork ethereumproject/ECIPs#86

Closed

aerth mentioned this pull request Jun 5, 2018

HF7 @ 36050 aquanetwork/aquachain#24

Merged

holgerd77 mentioned this pull request Jun 25, 2020

SpuriousDragon HF Support ethereumjs/ethereumjs-monorepo#791

Merged

15 tasks

0xkookoo mentioned this pull request Oct 8, 2022

require和assert的gas消耗对比问题 AmazingAng/WTF-Solidity#93

Closed


		## Motivation

		Currently this is not possible. There are two practical ways to revert a transaction from within a contract: running out of gas or executing an invalid instruction. Both of these options will consume all remaining gas. Additionally, reverting a transaction means that all changes, including LOGs, are lost and there is no way to convey a reason for aborting a transaction.


		## Specification

		The `REVERT` instruction is introduced at `0xfd`. It expects two stack items, the top item is the `memory_offset` followed by `memory_length`. It does not return anything because it stops execution.


		## Backwards Compatibility

		This change has no effect on contracts created in the past.

REVERT instruction #206

REVERT instruction #206

Conversation

axic commented Feb 6, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

axic commented Feb 6, 2017

chriseth commented Feb 7, 2017

Arachnid commented Feb 7, 2017

axic commented Feb 7, 2017

Arachnid commented Feb 7, 2017

axic commented Feb 7, 2017

Arachnid commented Feb 7, 2017

chriseth commented Feb 7, 2017

Arachnid commented Feb 7, 2017

chriseth commented Feb 7, 2017

Arachnid commented Feb 7, 2017

chriseth commented Feb 8, 2017

Arachnid commented Feb 8, 2017

VoR0220 commented Feb 8, 2017

chriseth commented Feb 9, 2017

Arachnid commented Feb 9, 2017

chriseth commented Feb 9, 2017

Arachnid commented Feb 9, 2017

chriseth commented Feb 9, 2017

Arachnid commented Feb 9, 2017

vbuterin commented Feb 9, 2017

Arachnid commented Feb 13, 2017

pipermerriam commented Oct 18, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pirapira left a comment

Choose a reason for hiding this comment

frangio commented Nov 17, 2017

pirapira commented Nov 20, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pirapira commented Nov 30, 2017 • edited

pirapira left a comment

Choose a reason for hiding this comment

cleanunicorn commented Mar 6, 2018

pirapira commented Mar 6, 2018

pirapira commented Nov 30, 2017 •

edited