# Transaction Tracing Transaction tracing enables a deeper look into smart contract inner calls and account creation calls. It is inspired by the OpenEthereum (Parity) node trace module, which is used in a lot of projects. For now, the following JSON-RPC methods are implemented: * [trace\_block](#trace_block) * [trace\_transaction](#trace_transaction) * [trace\_filter](#trace_filter) * [trace\_get](#trace_get) Currently, it is deployed on these endpoints for the Opera mainnet and testnet: * * ## Start a New Go-Opera Tracing Node Because of stored traces, a tracing node requires slightly bigger storage (around a quarter more). For more information, please follow the README.md file in the txtracing branch. ### **Building** You can check out and build the tx tracing release version from the [git repository](https://github.com/Fantom-foundation/go-opera/tree/release/txtracing/1.1.2-rc.5). ### **Running** It's recommended to launch a new node from scratch with the CLI option `--tracenode` as this flag has to be set to use stored transaction traces. ``` $ opera --genesis /path/to/genesis.g --tracenode ``` Enable JSON-RPC API with the option `trace`: ``` --http.api=eth,web3,net,ftm,trace ``` A complete example command: ``` opera \ --genesis=/datadir/mainnet-5577-full-mpt.g \ --port=5050 \ --maxpeers=200 \ --datadir=/datadir \ --http \ --http.addr=0.0.0.0 \ --http.port=18545 \ --http.corsdomain="*" \ --http.vhosts="*" \ --ws \ --ws.addr=0.0.0.0 \ --ws.port=18546 \ --ws.origins="*" \ --nousb \ --db.preset pbl-1 \ --tracenode \ --http.api=eth,web3,net,ftm,trace ``` ### **Genesis File** For the first start of the node, you have to specify the genesis file, which defines the blockchain and contains its history. Please select a [genesis file](https://download.fantom.network/) with a **full history** ("full-mpt" in the filename) if you need transaction traces for historical states. It's recommended to use the following genesis file, [mainnet-5577-full-mpt.g](https://download.fantom.network/mainnet-5577-full-mpt.g), for a full-history tracing node. ### **Import, Export, and delete** Transaction traces are created on the node while processing transactions and then stored in a node database. You can export these traces and import them on other nodes. This addition allows for responses to certain changes that may alter the trace content without requiring a complete resynchronization of the blockchain. Another method is to delete traces, which will be recreated upon the next request to them from the RPC API. However, this approach is not recommended because recreating traces this way is slower when the first request targets a non-existent transaction trace. All these operations must be performed while the node is stopped, as they involve modifying data in the core database. For both export and delete operations, you can specify a block range to limit the number of processed transaction traces. The command for exporting is `export txtraces `: ``` opera --tracenode --datadir=/path/to/opera/datadir export txtraces filename.gz 10000000 11000000 ``` For importing, it's: ``` opera --tracenode --datadir=/path/to/opera/datadir import txtraces filename.gz ``` No file needs to be specified when using the delete option. `delete txtraces ` ``` opera --tracenode --datadir=/path/to/opera/datadir delete txtraces 10000000 11000000 ``` ## Go-Opera Version Migration This section provides information on migrating a transaction tracing API node to a newer version of go-opera. It will indicate whether a full node resynchronization is required due to stored transaction traces or if only a code update is necessary to upgrade from the previous version. * [release/txtracing/1.1.1-rc.2](https://github.com/Fantom-foundation/go-opera/tree/release/txtracing/1.1.1-rc.2) * [release/txtracing/1.1.1-rc.3](https://github.com/Fantom-foundation/go-opera/tree/release/txtracing/1.1.1-rc.3) — no resync from 1.1.1-rc.2, just update * release/txtracing/1.1.2-rc.2 — don't use this version * [release/txtracing/1.1.2-rc.5](https://github.com/Fantom-foundation/go-opera/tree/release/txtracing/1.1.2-rc.5) — resync from all previous versions and see notes below When using version 1.1.2, you need to add the db.preset argument for the starting Opera command. You can view the available options for this parameter with the opera help command. For standard conditions, please use the following option: * db.preset=ldb-1 *** ## trace\_block Returns traces created at the given block. ### **Parameters** 1. `Quantity` or `Tag` — Integer of a block number, or the string `'earliest'`, `'latest'`, or `'pending'`. ``` params: [ "0x22DB3E" // 2284350 ] ``` ### **Returns** * `Array` — Block traces. ### **Example** Request: ``` curl --data '{"method":"trace_block","params":["0x22DB3E"],"id":1,"jsonrpc":"2.0"}' -H "Content-Type: application/json" -X POST https://rpcapi-tracing.fantom.network ``` Response: ``` { "jsonrpc":"2.0", "id":1, "result":[ { "action":{ "callType":"call", "from":"0x740c82e9009738b3ab6080e89da964a4704a6cba", "to":"0xd4e0aca70d1fe8979e7e1015b30a2085803d0244", "value":"0x0", "gas":"0x689e", "input":"0x6930fd2a0000000000000000000000000000000000000000000000000000000000000608" }, "blockHash":"0x00000ce000001cf16b859ccacc281e32e2c17730ce48b3498bf1f7f05d90fe5c", "blockNumber":2284350, "result":{ "gasUsed":"0x688f", "output":"0x" }, "subtraces":1, "traceAddress":[ ], "transactionHash":"0x58846dd2a9fa3ea9e700838db48fd9829ebbc95e103142ac7968f658fd1ed3ac", "transactionPosition":0, "type":"call" }, { "action":{ "callType":"delegatecall", "from":"0xd4e0aca70d1fe8979e7e1015b30a2085803d0244", "to":"0x1125eabf1eba69ef00266b7a038141474d8afff1", "value":"0x0", "gas":"0x125c", "input":"0x6930fd2a0000000000000000000000000000000000000000000000000000000000000608" }, "blockHash":"0x00000ce000001cf16b859ccacc281e32e2c17730ce48b3498bf1f7f05d90fe5c", "blockNumber":2284350, "result":{ "gasUsed":"0xf62", "output":"0x" }, "subtraces":0, "traceAddress":[ 0 ], "transactionHash":"0x58846dd2a9fa3ea9e700838db48fd9829ebbc95e103142ac7968f658fd1ed3ac", "transactionPosition":0, "type":"call" } ] } ``` ## trace\_transaction Returns all traces of the given transaction. ### **Parameters** 1. `Hash` — Transaction hash ``` params: ["0x58846dd2a9fa3ea9e700838db48fd9829ebbc95e103142ac7968f658fd1ed3ac"] ``` ### **Returns** * `Array` — Traces of given transaction ### **Example** Request: ``` curl --data '{"method":"trace_transaction","params":["0x58846dd2a9fa3ea9e700838db48fd9829ebbc95e103142ac7968f658fd1ed3ac"],"id":1,"jsonrpc":"2.0"}' -H "Content-Type: application/json" -X POST https://rpcapi-tracing.fantom.network ``` ## trace\_filter Returns traces matching the given filter. ### **Parameters** 1. `Object` — The filter object * `fromBlock`: `Quantity` or `Tag` — (optional) From this block. * `toBlock`: `Quantity` or `Tag` — (optional) To this block. * `fromAddress`: `Array` — (optional) Sent from these addresses. * `toAddress`: `Address` — (optional) Sent to these addresses. * `after`: `Quantity` — (optional) The offset trace number * `count`: `Quantity` — (optional) Integer number of traces to display in a batch. ``` params: [{ "fromBlock": "0x22DB29", // 2284329 "toBlock": "0x22DB34", // 2284340 "toAddress": ["0xda7a001b254cd22e46d3eab04d937489c93174c3"], "after": 20, "count": 10 }] ``` ### **Returns** * `Array` — Traces matching the given filter. ### **Example** Request: ``` curl -H "Content-Type: application/json" -X POST --data '{"method":"trace_filter","params":[{"fromBlock":"0x22DB29", "toBlock":"0x22DB34", "fromAddress":["0xda7a001b254cd22e46d3eab04d937489c93174c3"], "count":10, "after":20}],"id":1,"jsonrpc":"2.0"}' https://rpcapi-tracing.fantom.network ``` ## trace\_get Returns trace at given position. ### **Parameters** 1. `Hash` — Transaction hash. 2. `Array` — Index positions of the traces. ``` params: [ "0x58846dd2a9fa3ea9e700838db48fd9829ebbc95e103142ac7968f658fd1ed3ac", ["0x0"] ] ``` ### **Returns** * `Object` — Trace object ### **Example** Request: ``` curl -H "Content-Type: application/json" -X POST --data '{"method":"trace_get","params":["0x58846dd2a9fa3ea9e700838db48fd9829ebbc95e103142ac7968f658fd1ed3ac",["0x0"]],"id":1,"jsonrpc":"2.0"}' https://rpcapi-tracing.fantom.network ``` ## debug\_traceBlockByNumber The method returns a full stack trace of all invoked opcodes of all transaction that were included in a block identified by a block number. The parent of this block must be present or it will fail. ### Parameters 1. `Number` - Block number to be traced. 2. `Object` - (optional) Options for the trace. * `tracer`: `String` - (optional) Setting this will enable JavaScript-based transaction tracing, described below. * `timeout`: `String` - (optional) Overrides the default timeout of 5 seconds for JavaScript-based tracing calls. Check documentation for [ParseDuration](https://pkg.go.dev/time#ParseDuration) for valid values. ### Returns * `Array` - A trace object per transaction inside the block. ### Example ```shell curl -H "Content-Type: application/json" -X POST --data '{"method":"debug_traceBlockByNumber","params":["0x2F5DD49"],"id":1,"jsonrpc":"2.0"}' https://rpcapi-tracing.fantom.network ``` ## debug\_traceBlockByHash This method returns a full stack trace of all invoked opcodes of all transactions that were included in a block identified by a hash. The parent of this block must be present or it will fail. ### Parameters 1. `Hash` — Hash of the block to be traced. 2. `Object` — (optional) Options for the trace. * `tracer`: `String` — (optional) Setting this will enable JavaScript-based transaction tracing, described below. * `timeout`: `String` — (optional) Overrides the default timeout of 5 seconds for JavaScript-based tracing calls. Check documentation for [ParseDuration](https://pkg.go.dev/time#ParseDuration) for valid values. ### Returns * `Array` — A trace object per transaction inside the block. ### Example ```shell curl -H "Content-Type: application/json" -X POST --data '{"method":"debug_traceBlockByHash","params":["0x0002825a0000008c2bc8a86b966c34797db3c21916ca033f4bd68461801217d0"],"id":1,"jsonrpc":"2.0"}' https://rpcapi-tracing.fantom.network ``` ## debug\_traceTransaction This method will try to run the transaction in the same way it was executed on the network. It will replay any transactions that occurred before it in the block and then attempt to execute the transaction corresponding to the given hash. ### Parameters 1. `Hash` — Hash of the transaction to be traced. 2. `Object` — (optional) Options for the trace. * `tracer`: `String` — (optional) Setting this will enable JavaScript-based transaction tracing, described below. * `timeout`: `String` — (optional) Overrides the default timeout of 5 seconds for JavaScript-based tracing calls. Check documentation for [ParseDuration](https://pkg.go.dev/time#ParseDuration) for valid values. ### Returns * `Object` — A trace object of the traced transaction. ### Example ```shell curl -H "Content-Type: application/json" -X POST --data '{"method":"debug_traceTransaction","params":["0xa6598be1f06b0aff5caddec2685ec53599f064f7b8ff9eaded0a719a378c8802"],"id":1,"jsonrpc":"2.0"}' https://rpcapi-tracing.fantom.network ``` ## JavaScript-Based Tracer Specifying the `tracer` option in the second argument of the debug tracing calls enables JavaScript-based tracing. In this mode, `tracer` is interpreted as a JavaScript expression that is expected to evaluate an object which must expose the `result` and `fault` methods. There exists 4 additional methods, namely: `setup`, `step`, `enter`, and `exit`. `enter` and `exit` must be present or omitted together. ### **Setup Method** Method `setup` is invoked once, in the beginning when the tracer is being constructed for each transaction being traced. It takes in one argument, `config`, which allows users to pass in options to the tracer. `config` is to be JSON-decoded for usage and its default value is `"{}"`. ### **Step Method** Method `step` is a function that takes two arguments, `log` and `db`, and is called for each step of the EVM, or when an error occurs, as a transaction is traced. `log` has the following fields: * `op`: Object, an OpCode object representing the current opcode * `stack`: Object, a structure representing the EVM execution stack * `memory`: Object, a structure representing the contract’s memory space * `contract`: Object, an object representing the account executing the current operation And the following methods: * `getPC()` — returns a number with the current program counter * `getGas()` — returns a number with the amount of gas remaining * `getCost()` — returns the cost of the opcode as a number * `getDepth()` — returns the execution depth as a number * `getRefund()` — returns the amount to be refunded as a number * `getError()` — returns information about the error if one occurred, otherwise returns `undefined` If an error is non-empty, all other fields should be ignored. For efficiency, the same `log` object is reused on each execution step, updated with current values; make sure to copy values you want to preserve beyond the current call. `log.op` has the following methods: * `isPush()` — returns true if the opcode is a PUSHn * `toString()` — returns the string representation of the opcode * `toNumber()` — returns the opcode’s number `log.memory` has the following methods: * `slice(start, stop)` — returns the specified segment of memory as a byte slice * `getUint(offset)` — returns the 32 bytes at the given offset * `length()` — returns the memory size `log.stack` has the following methods: * `peek(idx)` — returns the idx-th element from the top of the stack (0 is the topmost element) as a big.Int * `length()` — returns the number of elements in the stack `log.contract` has the following methods: * `getCaller()` — returns the address of the caller * `getAddress()` — returns the address of the current contract * `getValue()` — returns the amount of value sent from caller to contract as a big.Int * `getInput()` — returns the input data passed to the contract `db` has the following methods: * `getBalance(address)` — returns a `big.Int` with the specified account’s balance * `getNonce(address)` — returns a Number with the specified account’s nonce * `getCode(address)` — returns a byte slice with the code for the specified account * `getState(address, hash)` — returns the state value for the specified account and the specified hash * `exists(address)` — returns true if the specified address exists If the step function throws an exception or executes an illegal operation at any point, it will not be called on any further VM steps, and the error will be returned to the caller. ### **Result Method** Method `result` is a function that takes two arguments, `ctx` and `db`, and is expected to return a JSON-serializable value to return to the RPC caller. `ctx` is the context in which the transaction is executed and has the following fields: * `type` — String, one of the two values, `CALL` and `CREATE` * `from` — Address, sender of the transaction * `to` — Address, target of the transaction * `input` — Buffer, input transaction data * `gas` — Number, gas budget of the transaction * `gasUsed` - Number, amount of gas used in executing the transaction (excludes txdata costs) * `gasPrice` — Number, gas price configured in the transaction being executed * `intrinsicGas` — Number, intrinsic gas for the transaction being executed * `value` — big.Int, amount to be transferred in wei * `block` — Number, block number * `output` — Buffer, value returned from EVM * `time` — String, execution runtime ### **Fault Method** Method `fault` is a function that takes two arguments, `log` and `db`, just like `step`, and is invoked when an error happens during the execution of an opcode which wasn’t reported in `step`. The method `log.getError()` has information about the error. ### **Ender and Exit Methods** Methods `enter` and `exit` are respectively invoked on stepping in and out of an internal call. More specifically, they are invoked on the `CALL` variants, `CREATE` variants, and also for the transfer implied by a `SELFDESTRUCT`. `enter` takes a `callFrame` object as argument which has the following methods: * `getType()` — returns a string which has the type of the call frame * `getFrom()` — returns the address of the call frame sender * `getTo()` — returns the address of the call frame target * `getInput()` — returns the input as a buffer * `getGas()` — returns a number that has the amount of gas provided for the frame * `getValue()` — returns a `big.Int` with the amount to be transferred only if available, otherwise `undefined` `exit` takes in a `frameResult` object which has the following methods: * `getGasUsed()` — returns amount of gas used throughout the frame as a Number * `getOutput()` — returns the output as a buffer * `getError()` — returns an error if one occurred during execution and undefined otherwise {% hint style="info" %} Note that several values are Golang big.Int objects, not JavaScript numbers or JS bigints. As such, they have the same interface as described in the godocs. Their default serialization to JSON is as a JavaScript number; to serialize large numbers accurately, call `.String()` on them. For convenience, `big.NewInt(x)` is provided, and will convert a uint to a Go BigInt. {% endhint %} --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.fantom.foundation/build-on-opera/api/transaction-tracing.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.