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
debug_traceBlockBy{Number,Hash}
outputs new opcodes for pre-fork blocks
#29464
Comments
I wonder is this the right way to resolve the issue you left. I tried to handle it by adding the code below at here // for handling issue#29464
if vmenv.ChainConfig().IsCancun(txctx.BlockNumber, vmenv.Context.Time) != true {
for _, opcode := range message.Data {
var opcode = vm.OpCode(opcode)
// cancun, EIP-4844
if opcode == vm.StringToOp("BLOBHASH") {
return nil, fmt.Errorf("invalid cancun opcode: %s", opcode.String())
}
// cancun, EIP-7516
if opcode == vm.StringToOp("BLOBBASEFEE") {
return nil, fmt.Errorf("invalid cancun opcode: %s", opcode.String())
}
// cancun, EIP-1153
if opcode == vm.StringToOp("TLOAD") || opcode == vm.StringToOp("TSTORE") {
return nil, fmt.Errorf("invalid cancun opcode: %s", opcode.String())
}
// cancun, EIP-5656
if opcode == vm.StringToOp("MCOPY") {
return nil, fmt.Errorf("invalid cancun opcode: %s", opcode.String())
}
// cancun, EIP-6780 skip
}
} Output is not the trace anymore but an error message. (code: -32000, message: invalid cancun opcode: BLOBHASH, data: None) you can also check the log from geth client |
@c0np4nn4 I don't think that's the correct way of handling this. Tracing should still work and not return an error if there were invalid opcodes in the transaction. |
@s1na from looking at other issues it seems you are the most familiar with tracing. Do you believe this can be considered a bug that is worth fixing? |
The old trace format is bad this way (hence why we created a different output-format, standard-tracing, which has The actual underlying bytecode is non-ambiguous. Translating a byte into a string-representation is context-dependent, e.g For fuzzing, I never look at the string-name of the operation. That's for human consumption. The |
System information
Geth version:
geth version 1.13.14-stable-2bd6bd01
CL client & version: none
OS & Version: Linux
Expected behaviour
The output of
debug_traceBlockByNumber
should containinvalid
for cancun opcodes in pre-cancun blocks (or any other fork that introduces new opcodes).Actual behaviour
The trace contains the new opcodes
BLOBHASH
,BLOBBASEFEE
,TLOAD
,TSTORE
,MCOPY
despite these not being active yet.Steps to reproduce the behaviour
Make sure cancun is not active
Start geth and fund the test account
Send a transaction that uses
BLOBHASH
, specificallyPUSH0, PUSH0, BLOBHASH, PUSH0, PUSH0
.Output of the trace will contain
BLOBHASH
as the last opcode despite the opcode being interpreted as invalid opcode.The text was updated successfully, but these errors were encountered: