Chain data

The following data structures describe the output of various TrueBlocks blockchain queries. These data structures basically mimic the data available directly from the RPC.

Each data structure is created by one or more tools which are detailed below.

Block#

chifra blocks returns top level data specified block. You can also include an array for the blocks’ transactions.

The following commands produce and manage Blocks:

• chifra blocks

Blocks consist of the following fields:

Transaction#

Transactions represent eth transfers to and from other addresses.

Most of the fields that TrueBlocks returns are standard to all eth transaction. However, one field is very interesting: articulatedTx provides a human readable output of the input field.

This is a very powerful way to understand the story behind a smart contract.

The following commands produce and manage Transactions:

• chifra transactions
• chifra slurp
• chifra export

Transactions consist of the following fields:

Transfer#

The transfer data model is produced by the reconciliation process of chifra export. It represents, for all intents and purposes, the asset value transfer produced by nearly all value transfers on any blockchain. While the details of various token transfers are varied, the underlying mechanism is through token transfers. In our accounting, we focus on the token transfers and label each such transfer on the input data or event topic data. In this way, our accounting remains relatively easy (we only reconcile tokens and ETH), but we cover every conceivable token asset transfer of any type.

The following commands produce and manage Transfers:

• chifra transactions
• chifra export

Transfers consist of the following fields:

Receipt#

Receipts record the amount of gas used for a transaction among other things. If the transaction succeeded, a receipt might also have logs.

If the to address of a transaction is 0x0, the input data is considered to be the source code (byte code) of a smart contract. In this case, if the creation of the contract succeeds, the contractAddress field of the receipt carries the address of the newly created contract.

The following commands produce and manage Receipts:

• chifra receipts
• chifra export

Receipts consist of the following fields:

Log#

Logs appear in a possibly empty array in the transaction’s receipt. They are only created if the underlying transaction suceeded. In the case where the transaction failed, no logs will appear in the receipt. Logs are only ever generated during transactions whose to address is a smart contract.

The following commands produce and manage Logs:

• chifra logs
• chifra export
• chifra blocks

Logs consist of the following fields:

Trace#

The deepest layer of the Ethereum data is the trace. Every transaction has at least one trace which is itself a record of the transaction. If the to address of the transaction is a smart contract, other traces may appear, if, for example, that smart contract calls other smart contracts.

Traces may be arbitrarily deep (up to the gasLimit) and ultimately represent a tree of function calls. Some transactions have 100s of traces. The format of the trace is similar to the transaction itself have a trace action (which contains from, to, value like the transaction) and the trace result (containing gasUsed like the receipt).

The following commands produce and manage Traces:

• chifra traces
• chifra export
• chifra blocks

Traces consist of the following fields:

Notes#

When produced using the --raw option to chifra traces, this data model actually produces transactionPosition instead of transactionIndex. When produced without the --raw option, the model uses transactionIndex to be consistent with other data models such as the transaction.

Traces and TraceActions, when produced during a self-destruct, export different fields when rendered in JSON. In CSV and TXT output, these fields change thier meaning while retaining the header of the original fields. The following table describes these differences:

Fields that change during self-destruct transaction:

TraceAction#

Other than the first trace which is the trace of the transaction itself, traces represent calls into smart contracts. Because of this, trace actions closely resemble the fields of the transaction.

The following commands produce and manage TraceActions:

• chifra traces
• chifra export
• chifra blocks

TraceActions consist of the following fields:

TraceResult#

As mentioned above, other than the first trace, traces represent calls into other smart contracts. Because of this, the trace results closely resembles the fields of the receipt.

The following commands produce and manage TraceResults:

• chifra traces
• chifra export
• chifra blocks

TraceResults consist of the following fields:

BlockCount#

chifra blocks --count returns the number of various types of data in a block. For example, transactionCnt is the number of transactions in the block, and so on.

The following commands produce and manage BlockCounts:

• chifra blocks

BlockCounts consist of the following fields:

NamedBlock#

Left to its own devices, the blockchain would try to convince us that only hashes and bytes are important, but being human beings we know that this is not true. TrueBlocks articulates various types of data with chifra names detailing the names for addresses, -articulate describing the Functions and Events of a transaction, and chifra when describing dated blocks. Dated blocks assign a human-readable date to blocks given block numbers or timestamps and visa versa.

The following commands produce and manage NamedBlocks:

• chifra when

NamedBlocks consist of the following fields:

TraceCount#

chifra trace --count returns the number of traces the given transaction.

The following commands produce and manage TraceCounts:

• chifra traces

TraceCounts consist of the following fields:

Base types#

This documentation mentions the following basic data types.

Edit this page on GitHub