core: add status as a consensus field in receipt #15014

rjl493456442 · 2017-08-21T00:49:57Z

Motivation:

Current receipt doesn't include a field to indicate the transaction execution status. User can only get execution result by replay transaction. While this method is only useful in a full node, fast nodes can only do this for nodes after their pivot point, and light nodes cannot do this at all. So the field in receipt is helpful.

So a new field Failed is added to receipt, if this field be set with false, means the state revert happened in the outermost call(any internal state revert can be discarded).

While in consensus recepit, failed is converted to a field named status, 0x01 means transaction been executed successfully, while 0x00 means failure occurred.

Whatsmore, the Failed can help to estimate gas cost more accurately, and expose more information in evm runner

rjl493456442 · 2017-08-21T13:01:58Z

@karalabe Could you please review the changes?

karalabe · 2017-08-21T14:36:27Z

core/types/receipt.go

 // Receipt represents the results of a transaction.
 type Receipt struct {
 	// Consensus fields
 	PostState         []byte   `json:"root"`
+	Status            byte     `json:"status"`


Since the status can only ever be "failed" or "succeeded", it would make more sense to me to keep this field as a bool called Failed. The actual serialization will of course remain the 0x00 or 0x01 byte, but it seems cleaner to work with a boolean in Go code if nothing else is possible (or will be in the planned future).

karalabe · 2017-08-21T14:37:42Z

core/types/receipt.go

+const (
+	ReceiptStatusSuccess = byte(0x01)
+	ReceiptStatusFailure = byte(0x00)
+)


These should be private (since we want to work with bools API wise) and please document them.

karalabe · 2017-08-21T14:38:27Z

core/types/receipt.go

+			statusStr = "Failure"
+		} else {
+			statusStr = "Undefined"
+		}


If we switch over to using bools, this undefined cannot happen any more.

karalabe · 2017-08-21T14:41:05Z

core/vm/contract.go

+	if parent, ok := self.caller.(*Contract); ok {
+		parent.SetVmError(err)
+	}
+}


I don't think you need this or the contract.VMError field. All the Call* and Create methods already return the same error, and we only care about the outermost one, so internal ones can be discarded without any problems.

karalabe · 2017-08-21T14:41:44Z

core/vm/evm.go

@@ -127,18 +127,18 @@ func (evm *EVM) Cancel() {
 // parameters. It also handles any necessary value transfer required and takes
 // the necessary steps to create accounts and reverses the state in case of an
 // execution error or failed value transfer.
-func (evm *EVM) Call(caller ContractRef, addr common.Address, input []byte, gas uint64, value *big.Int) (ret []byte, leftOverGas uint64, err error) {
+func (evm *EVM) Call(caller ContractRef, addr common.Address, input []byte, gas uint64, value *big.Int) (ret []byte, leftOverGas uint64, vmErr error, err error) {


As mentioned above, I don't think we need another error return, the existing one can be used for the desired purpose.

karalabe · 2017-08-21T14:42:44Z

core/vm/evm.go

@@ -210,6 +211,7 @@ func (evm *EVM) CallCode(caller ContractRef, addr common.Address, input []byte,
 	ret, err = run(evm, snapshot, contract, input)
 	if err != nil {
 		evm.StateDB.RevertToSnapshot(snapshot)
+		contract.SetVmError(err)


There's no reason to use such a mechanism, since the error is returned anyway from this function.

karalabe · 2017-08-21T14:42:49Z

core/vm/evm.go

@@ -243,6 +245,7 @@ func (evm *EVM) DelegateCall(caller ContractRef, addr common.Address, input []by
 	ret, err = run(evm, snapshot, contract, input)
 	if err != nil {
 		evm.StateDB.RevertToSnapshot(snapshot)
+		contract.SetVmError(err)


There's no reason to use such a mechanism, since the error is returned anyway from this function.

karalabe · 2017-08-21T14:42:55Z

core/vm/evm.go

@@ -286,6 +289,7 @@ func (evm *EVM) StaticCall(caller ContractRef, addr common.Address, input []byte
 	ret, err = run(evm, snapshot, contract, input)
 	if err != nil {
 		evm.StateDB.RevertToSnapshot(snapshot)
+		contract.SetVmError(err)


There's no reason to use such a mechanism, since the error is returned anyway from this function.

karalabe · 2017-08-21T14:43:17Z

core/vm/evm.go

@@ -294,18 +298,18 @@ func (evm *EVM) StaticCall(caller ContractRef, addr common.Address, input []byte
 }

 // Create creates a new contract using code as deployment code.
-func (evm *EVM) Create(caller ContractRef, code []byte, gas uint64, value *big.Int) (ret []byte, contractAddr common.Address, leftOverGas uint64, err error) {
+func (evm *EVM) Create(caller ContractRef, code []byte, gas uint64, value *big.Int) (ret []byte, contractAddr common.Address, leftOverGas uint64, vmErr error, err error) {


As mentioned above, I don't think we need another error return, the existing one can be used for the desired purpose.

karalabe · 2017-08-21T14:47:40Z

core/types/receipt.go

+		} else {
+			statusStr = "Undefined"
+		}
+		return fmt.Sprintf("receipt{status=%s cgas=%v bloom=%x logs=%v}", statusStr, r.CumulativeGasUsed, r.Bloom, r.Logs)


I think you can use failed instead of status and just pass in the bool.

karalabe · 2017-08-21T14:54:39Z

core/state_transition.go

-
-	evm *vm.EVM
+	evm        *vm.EVM
+	vmErr      error // vmErr represents all errors occurred during the execution


There's no reason to have this field, it can be returned as a function result when needed.

karalabe · 2017-08-21T14:59:11Z

core/state_transition.go

+		// can only return the error message called at level 0.
+		// Sub error will not been assigned to err, except for insufficient
+		// balance error.
+		suberr error


I don't think there's a reason for this second suberr, since returning a single error from Create or Call is enough. Below you can check if it's vm.ErrInsufficientBalance and return nil, nil, nil, nil, vmerr in such a case, and return ret, requiredGas, st.gasUsed(), vmerr, nil in the case of the happy path.

I.e. instead of saving the vmerr inside the StateTransition object, might as well simply return it (since you're doing that at the upper call level anyway).

karalabe · 2017-08-21T15:01:11Z

core/state_transition.go

 	st := NewStateTransition(evm, msg, gp)

 	ret, _, gasUsed, err := st.TransitionDb()
-	return ret, gasUsed, err
+	return ret, gasUsed, st.vmErr, err


Just return vmerr from st.TransitionDb() instead of accessing it as a member field.

karalabe

Thanks for the PR! It's almost good, but can be simplified a bit.

karalabe · 2017-08-21T15:03:56Z

Note, an internal reversion doesn't mean the receipt's state should be set to failed. Only the outermost revertal/failure should impact the receipt's new field.

rjl493456442 · 2017-08-21T15:08:00Z

Thanks for your time! If only the outermost failure should take care, it can be more simplified. It will fix these tomorrow.

karalabe · 2017-08-22T09:47:59Z

core/types/receipt.go

+			status = receiptStatusSuccessful
+		} else {
+			status = receiptStatusFailed
+		}


This can be done a bit more compactly with:

status := receiptStatusSuccessful if r.Failed { status = receiptStatusFailed }

karalabe · 2017-08-22T09:48:40Z

core/types/receipt.go

-		// Metropolis receipts have 3 components
+	// Deserialize based on the first component type.
+	switch {
+	case kind == rlp.Byte || kind == rlp.String && len(cnt) == 0:


You don't need the string magic here, it's only byte we're working with.

This should definitely be removed, or else we'll have a potential consensus failure by accepting an invalid receipt.

@Arachnid Since now the empty value is encoded as 0x80. When we use rlp.Split, it returns a String type instead of the byte type we expected. So add these statements in order to deal with this situation.

@Arachnid This is another solution to fix it. Change receipt status type from byte to []byte. Since rlp will treat byte as uint8, and byte(0x00) will be encoded as 0x80, which make confused. If we use []byte to represent receipt status, []byte{0x00} can be encoded as 0x00 correctly. But the receipt definition can cause ambiguity.

I think this part is correct, since 0x01 is decoded as a byte, but 0x80 as an empty string (0 number). It's a bit weird, but that's the way RLP guesses the type unless it's given explicitly.

One thing that did occur to me however, is that we don't enforce the status byte to be 0 or 1. That's a possible consensus problem. I'll add a fix for this.

karalabe · 2017-08-22T09:49:39Z

core/types/receipt.go

+			r.Failed = false
+		} else {
+			r.Failed = true
+		}


You can set the failed flag with a single statement: r.Failed = metro.Status == receiptStatusFailed

karalabe · 2017-08-22T09:53:09Z

core/vm/instructions.go

@@ -33,6 +33,7 @@ var (
 	errWriteProtection       = errors.New("evm: write protection")
 	errReturnDataOutOfBounds = errors.New("evm: return data out of bounds")
 	errExecutionReverted     = errors.New("evm: execution reverted")
+	errMaxCodeSizeExceeded   = errors.New("contract code size exceed the max")


errors.New("evm: max code size exceeded")

karalabe · 2017-08-22T09:57:52Z

core/state_transition.go

+		failed = true
+	}
+
+	return ret, requiredGas, st.gasUsed(), failed, err


This whole block can be replaced imho with:

return ret, requiredGas, st.gasUsed(), vmerr != nil, nil

i.e. the failed flag is only ever used upward from Metropolis, so we don't really care if it's true or false in Frontier.

karalabe · 2017-08-22T13:12:22Z

One tiny error, otherwise it works

 diff --git a/common/bytes.go b/common/bytes.go
index c445968..66577bb 100644
--- a/common/bytes.go
+++ b/common/bytes.go
@@ -47,6 +47,9 @@ func FromHex(s string) []byte {
 //
 // Returns an exact copy of the provided bytes
 func CopyBytes(b []byte) (copiedBytes []byte) {
+       if b == nil {
+               return nil
+       }
        copiedBytes = make([]byte, len(b))
        copy(copiedBytes, b)

Without this, the PostState of a receipt is always set to []byte{} on Metropolis, which causes it to encode as Homestead (since PostState != nil).

karalabe

LGTM (I've squashed it and pulled in a test suite update)

holiman · 2017-08-23T09:28:16Z

core/types/receipt.go

+		default:
+			return fmt.Errorf("invalid status byte: 0x%x", metro.Status)
+		}
+		r.Failed = metro.Status == receiptStatusFailed


We're already setting the r.Failed in the switch above.

God damn it, I left this in.

karalabe · 2017-08-23T10:57:59Z

@holiman Fixed, PTAL.

holiman · 2017-08-23T11:04:59Z

LGTM

ligi · 2017-08-24T20:58:09Z

core/vm/evm.go

@@ -158,7 +158,7 @@ func (evm *EVM) Call(caller ContractRef, addr common.Address, input []byte, gas
 	evm.Transfer(evm.StateDB, caller.Address(), to.Address(), value)

 	// initialise a new contract and set the code that is to be used by the
-	// E The contract is a scoped evmironment for this execution context


what a great typo - love this word!-)

rjl493456442 force-pushed the metropolis-eip658 branch 4 times, most recently from 5b18f24 to 3b9420f Compare August 21, 2017 12:21

rjl493456442 changed the title ~~[WIP]core/types: add status as a consensus field in receipt~~ core: add status as a consensus field in receipt Aug 21, 2017

rjl493456442 force-pushed the metropolis-eip658 branch from 3b9420f to 959ab97 Compare August 21, 2017 12:58

karalabe added this to the 1.7.0 milestone Aug 21, 2017

karalabe added the metropolis label Aug 21, 2017

karalabe reviewed Aug 21, 2017

View reviewed changes

karalabe requested changes Aug 21, 2017

View reviewed changes

rjl493456442 force-pushed the metropolis-eip658 branch from d6a587b to 88691cc Compare August 22, 2017 02:45

rjl493456442 changed the title ~~core: add status as a consensus field in receipt~~ [WIP]core: add status as a consensus field in receipt Aug 22, 2017

rjl493456442 force-pushed the metropolis-eip658 branch 2 times, most recently from 9775459 to fd2d594 Compare August 22, 2017 08:44

rjl493456442 changed the title ~~[WIP]core: add status as a consensus field in receipt~~ core: add status as a consensus field in receipt Aug 22, 2017

karalabe reviewed Aug 22, 2017

View reviewed changes

rjl493456442 force-pushed the metropolis-eip658 branch from fd2d594 to e4f0806 Compare August 22, 2017 11:05

rjl493456442 and others added 2 commits August 22, 2017 18:35

core: implement Metropolis EIP 658, receipt status byte

28aea46

tests: pull in new test suite, enable most block tests

79bf69b

karalabe force-pushed the metropolis-eip658 branch from 1d2b1b4 to 79bf69b Compare August 22, 2017 15:36

karalabe approved these changes Aug 22, 2017

View reviewed changes

holiman approved these changes Aug 23, 2017

View reviewed changes

core/types: reject Metro receipts with > 0x01 status bytes

4ee92f2

karalabe force-pushed the metropolis-eip658 branch from ea03124 to 4ee92f2 Compare August 23, 2017 10:57

karalabe merged commit 3c48a25 into ethereum:master Aug 23, 2017

fjl mentioned this pull request Aug 24, 2017

core/vm: add a failed flag to detect tx execution status #14637

Closed

ligi reviewed Aug 24, 2017

View reviewed changes

Neurone mentioned this pull request Sep 22, 2017

Method decreaseApproval in unsafe OpenZeppelin/openzeppelin-contracts#437

Closed

whilei mentioned this pull request Dec 28, 2018

Articulate EIP parameters and feature implementations whilei/go-ethereum-1#6

Closed

core: add status as a consensus field in receipt #15014

core: add status as a consensus field in receipt #15014

Conversation

rjl493456442 commented Aug 21, 2017 • edited

rjl493456442 commented Aug 21, 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

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

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

karalabe left a comment

Choose a reason for hiding this comment

karalabe commented Aug 21, 2017

rjl493456442 commented Aug 21, 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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

karalabe Aug 22, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

karalabe commented Aug 22, 2017 • edited

karalabe left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

karalabe commented Aug 23, 2017

holiman commented Aug 23, 2017

Choose a reason for hiding this comment

rjl493456442 commented Aug 21, 2017 •

edited

karalabe Aug 22, 2017 •

edited

karalabe commented Aug 22, 2017 •

edited