Etn-sc supports tracing via custom Javascript tracers. This document provides a tutorial with examples on how to achieve this.
A simple filter
Filters are Javascript functions that select information from the trace to persist and discard based on some conditions. The following Javascript function returns only the sequence of opcodes executed by the transaction as a comma-separated list. The function could be written directly in the Javascript console, but it is cleaner to write it in a separate re-usable file and load it into the console.
Create a file, filterTrace_1.js, with this content:
Run this line to get a more readable output with each string in its own line.
console.log(JSON.stringify(tracer('<hash of transaction>'),null,2));
More information about the JSON.stringify function is available here.
The commands above worked by calling the same debug.traceTransaction function that was previously explained in basic traces, but with a new parameter, tracer. This parameter takes the JavaScript object formatted as a string. In the case of the trace above, it is:
fault, called if there is a problem in the execution.
result, called to produce the results that are returned by debug.traceTransactionafter the execution is done.
In this case, retVal is used to store the list of strings to return in result.
The step function adds to retVal the program counter and the name of the opcode there. Then, in result, this list is returned to be sent to the caller.
Filtering with conditions
For actual filtered tracing we need an if statement to only log relevant information. For example, to isolate the transaction's interaction with storage, the following tracer could be used:
The step function here looks at the opcode number of the op, and only pushes an entry if the opcode is SLOAD or SSTORE (here is a list of EVM opcodes and their numbers). We could have used log.op.toString() instead, but it is faster to compare numbers rather than strings.
The trace above reports the program counter (PC) and whether the program read from storage or wrote to it. That alone isn't particularly useful. To know more, the log.stack.peek function can be used to peek into the stack. log.stack.peek(0) is the stack top, log.stack.peek(1) the entry below it, etc.
The values returned by log.stack.peek are Go big.Int objects. By default they are converted to JavaScript floating point numbers, so you need toString(16) to get them as hexadecimals, which is how 256-bit values such as storage cells and their content are normally represented.
Storage Information
The function below provides a trace of all the storage operations and their parameters. This gives a more complete picture of the program's interaction with storage.
One piece of information missing from the function above is the result of an SLOAD operation. The state we get inside log is the state prior to the execution of the opcode, so that value is not known yet. For more operations we can figure it out for ourselves, but we don't have access to the storage, so here we can't.
The solution is to have a flag, afterSload, which is only true in the opcode right after an SLOAD, when we can see the result at the top of the stack.
So the storage has been treated as if there are only 2^256 cells. However, that is not true. Contracts can call other contracts, and then the storage involved is the storage of the other contract. We can see the address of the current contract in log.contract.getAddress(). This value is the execution context - the contract whose storage we are using - even when code from another contract is executed (by using CALLCODE or DELEGATECALL).
However, log.contract.getAddress() returns an array of bytes. To convert this to the familiar hexadecimal representation of Electroneum addresses, this.byteHex() and array2Hex() can be used.
