You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Geth version: Above 12.0, with debug API enabled in RPC
Expected behaviour
For a deployment tx. While calling debug_tracedTransaction with prestate tracer being specified, since the contract at 0x0b96fec58064f3407ca8336426054d0352a48567 is beging deployed so the nonce in prestate for this address should be 0. Or there should be no any entry for this address (according to some discussion for the creation)
Actual behaviour
prestate tracer reported 0x0b96fec58064f3407ca8336426054d0352a48567 with nonce of 1:
Call the debug API of a geth node, for example, using following cmd:
curl <URL for RPC node> \
-X POST \
-H "Content-Type: application/json" \
--data '{"method":"debug_traceTransaction","params":["0x4544af322f2b63d8dbe4dcd41c6c80535095d93406b316087706adca97e662b3", {"tracer": "prestateTracer"}], "id":1,"jsonrpc":"2.0"}'
Discussion
Note that there is more account being created in the tx above like 0x9426105341f2fe684f3218f33987c453faf42de4, and prestate tracer report correct nonce (0) for this address. We note that 0x0b96fec58064f3407ca8336426054d0352a48567 should have be traced in the CaptureStart hook, where the to address has been initialized and nonce being set to 1 rather than 0. This has also made the exist method return true and the address is not pruned in the final result.
The text was updated successfully, but these errors were encountered:
Previously, we deleted the prestate (e.g. there could be existing balance) on deployments.
It was changed, so that the prestate was not deleted,
However, turns out the change didn't take into account that the info from lookupAccount was not the origianl in-state value, but rather the value after nonce-increase and balance-increase (?)
System information
Geth version: Above 12.0, with debug API enabled in RPC
Expected behaviour
For a deployment tx. While calling
debug_tracedTransaction
with prestate tracer being specified, since the contract at0x0b96fec58064f3407ca8336426054d0352a48567
is beging deployed so the nonce in prestate for this address should be 0. Or there should be no any entry for this address (according to some discussion for the creation)Actual behaviour
prestate tracer reported
0x0b96fec58064f3407ca8336426054d0352a48567
with nonce of 1:Steps to reproduce the behaviour
Call the debug API of a geth node, for example, using following cmd:
Discussion
Note that there is more account being created in the tx above like
0x9426105341f2fe684f3218f33987c453faf42de4
, and prestate tracer report correct nonce (0) for this address. We note that0x0b96fec58064f3407ca8336426054d0352a48567
should have be traced in theCaptureStart
hook, where theto
address has been initialized and nonce being set to 1 rather than 0. This has also made theexist
method return true and the address is not pruned in the final result.The text was updated successfully, but these errors were encountered: