Naming Conventions
StreamingFast Firehose naming conventions

Each Firehose setup has unique naming conventions depending on versioning and the blockchain being targeted.
Note: This page serves as a resource to provide a unified experience for developers working between the Firehose versions.

Each Firehose setup uses two forms of naming. The naming is taken from the target blockchain's protocol name. The two forms establish a long and a short form of the protocol name.
The short form will be the shortest abbreviation of the chain name possible. For Ethereum, the long form would beethereum and the short form would be eth.
Important: These naming forms will be referenced throughout the Firehose naming conventions documentation.

Codebases of blockchain nodes that integrate Firehose use the following naming conventions.
Go Ethereum uses geth, Solana usessolana-validator, and Cosmos uses gaia.
For line-based Firehose instrumentations, each line of output should start with the word FIRE followed by a simple word defining what data to expect on each line.
Note: previous implementations used DMLOG, for deepmind, which was the codename of StreamingFast instrumentation.

When using libraries for node instrumentation using firehose as the name of the library for all firehose helpers is preferable.
Note: deepmind was used in several prior Firehose implementations.
Important: The top-level flag --firehose-enabled can be used for quickly dumping massive quantities of data to standard output from Firehose.

Replace acme with the chain you are instrumenting for the following items.
In a sample scenario instrumenting the Tezos blockchain acme would be replaced by the two forms of Tezos; something similar to tezos and tez.

If the target blockchain were Tezos the name would be firehose-tezos.

The binary name will be the first half of the Firehose product name "fire" combined with the short form of the target blockchain. If the target blockchain were Tezos, the name of the binary would be something similar to firetez.

The top-level Block protobuf definition convention for a new chain is sf.[chain].type.v1.Block. For Tezos it would be sf.tezos.type.v1.Block

Proto Directory - /proto
The proto directory contains properly namespaced protobuf definitions for the target chain. For example proto/sf/acme/type/v1/type.proto as the first, and often only, file. For Tezos it would be proto/sf/tezos/type/v1/type.proto
Types Directory - /types
The types directory contains rendered protobuf types and some helpers. For example /types/pb/sf/acme/type/v1;pbacme, using the short form package name prefixed with pb. For Tezos it would be something similar to: /types/pb/sf/acme/type/v1;pbtezos
/types/go.mod: to be able to import and pull only a limited number of dependencies.
Codec Directory - /codec
The codec directory contains all of the coding and decoding methods used to manipulate the stream of data coming from the Firehose-enabled Blockchain Node. Note, this library is concerned only with the data wrangling, and not the management of nodes.

The reader component has historically been known as the mindreader. The reader component has its own twist on the deepmind instrumentation originally created by StreamingFast.

  • The mindreader component is now called the reader component in the Firehose documentation.
  • The app within the fireacme binary is now calledreader.Previous names for the component included mindreader, extractor and ingestor.
  • Flags for other components would follow the naming convention of the different types of nodes handled by the fireacme binary. For example --reader-node-config-1-2-3, alongside: --peering-node-config123 and --miner-node-config123.
  • Pods will also be named reader instead of mindreader throughout Firehose setups.
Copy link
On this page
Firehose Naming Conventions
Firehose Instrumentation Naming
Chain-specific Binary Changes
Prior Naming Convention Changes