core/vm: Make INVALID a defined opcode

[gumb0]

This doesn't change anything except error message, but will be required for EOF code calidation (EIP-3670) It doesn't solve the needs of EIP-3670 anymore (because undefined and INVALID are not distinguished in jump table), but does improve the traces.

Before:

> build/bin/evm --code "0xfe" --json --debug run
{"pc":0,"op":254,"gas":"0x2540be400","gasCost":"0x0","memory":"0x","memSize":0,"stack":[],"returnData":"0x","depth":1,"refund":0,"opName":"opcode 0xfe not defined","error":"invalid opcode: opcode 0xfe not defined"}
{"output":"","gasUsed":"0x2540be400","time":132537,"error":"invalid opcode: opcode 0xfe not defined"}
#### LOGS ####

After:

> build/bin/evm --code "0xfe" --json --debug run
{"pc":0,"op":254,"gas":"0x2540be400","gasCost":"0x0","memory":"0x","memSize":0,"stack":[],"returnData":"0x","depth":1,"refund":0,"opName":"INVALID","error":""}
{"output":"","gasUsed":"0x2540be400","time":119327,"error":"invalid opcode: INVALID"}
#### LOGS ####

[axic]

Suggested change

	ErrInvalidOpcode = errors.New("exection reached INVALID (0xfe) opcode")
	ErrInvalidOpcode = errors.New("execution reached INVALID (0xfe) opcode")

[axic]

Could also just say:

Suggested change

	ErrInvalidOpcode = errors.New("exection reached INVALID (0xfe) opcode")
	ErrInvalidOpcode = errors.New("aborted with INVALID (0xfe) opcode")

[axic]

Lastly with EIP-1803 I hope we can rename INVALID to ABORT to make it more clear, but that should be a separate PR I suppose?

[holiman]

Overall, I'm not quite convinced about the need for doing this. Can you elaborate on that?

[holiman]

We already have an ErrInvalidOpCode, as a type, defined further down in this file. Having a type with the same name as a global var is not a good idea.

IMO let's not define a new specific error for this specific opcode -- the idea with 0xFE is that it will always remain undefined. There are others currently undefined, and IMO this opcode should be treated exactly like those, by the EVM.

So I think we can skip this var here. And the opInvaid could just do

return nil, &ErrInvalidOpCode{opcode: OpCode(0xfe)}

[gumb0]

Overall, I'm not quite convinced about the need for doing this. Can you elaborate on that?

With EOF we propose (in EIP-3670) to forbid deploying undefined opcodes (which will allow introducing new opcodes later without bumping EOF version and also simplifies EVM implementation, where it needs only EOF version (without additional revision) to know if particular byte value is defined)

0xfe should still be allowed to deploy as a guaranteed way to fail execution, so this is where it differs from all other bytes that are not defined.

Also a minor point: having an enum value for INVALID helps to clarify EIP-3540 rules in code, see this discussion #22958 (comment)

[gumb0]

0xfe should still be allowed to deploy as a guaranteed way to fail execution, so this is where it differs from all other bytes that are not defined.

And I have EIP-3670 implementation where I use jumpTable[opcode] == nil to find if the opcode is defined, that's what required this PR.

[holiman]

Though -- in the context of what you're implementing in that other PR... Is it really necessary to define it as an acutal op in the jumptable, as opposed to just define the OpCode but leave it empty in the jumptable?

[gumb0]

I think it's better to have it in the jumptable, I see the question of whether 0xfe is a defined opcode as a property of particular fork rules (currently it's defined in all forks, but theoretically 0xfe might mean something else in some other jump table)

Without putting it into jumptable I can only think of having it as a special case in code validation, like jumpTable[opcode] == nil && opcode != 0xfe will mean it's not defined.

[axic]

As discussed with @gumb0, opInvalid may be required for the EIP-3670-style code validation, but lets tackle that once @gumb0 opens a draft PR for that. This change (defining the instruction) is useful for logging purposes as well as for consumers of the instruction set for (dis)assembly purposes (such as goevmlab). As a reference, most assemblers (including Solidity) out there support invalid as an opcode.

[holiman]

LGTM