Indexers vs Validator Nodes

The Tari network has three primary clients, namely Validator Nodes, Wallets, and Indexers, excluding the Minotari
network clients. Validator nodes execute transactions and reach an agreement using a variant of the Cerberus consensus,
while wallets serve as an interface for clients. However, what is the role of Indexers?
To enable the Tari network to process thousands of transactions per second, the network has been sharded. This means
that no validator node stores the entire network’s data and would probably be unable to do so, even if it wanted to.
Moreover, specific assets and contracts are spread across different shards to avoid overloading some shards while
leaving others idle. However, this also means that if you’re only interested in a single asset, your wallet would need
to request the data for that asset from every shard. To address this issue, Tari has developed an Indexer that can be
run locally to scan the shards and download all data related to assets you’re interested in.
Indexers function similarly to base nodes for the Minotari layer, providing a unified view of an asset as though it were
a dedicated blockchain.
You can think of the distinction between validator nodes and indexers as cutting vertically and horizontally through
the contract-shard space. This is illustrated in the image below. Validator nodes — during a single epoch — are
only concerned about what happens in a small fraction of the shard space, but are prepared to validate any
instruction for any contract that touches the shard space the node is responsible for. Indexers, on the other hand,
are typically only interested in following what happens to a single contract, and will follow that contract across
the entire shard space.
For this reason, indexers and nodes have orthogonal responsibilities. This configuration may feel somewhat strange
if you’re used to global state machines, like Ethereum or Solana. The polarisation of indexers and nodes is a natural
result of the highly sharded and linear scalability of the Cerberus consensus algorithm.
It also means that tools like [etherscan.io] become very difficult to implement in Tari — as it should be: global
surveillance of a chain that aims to scale to thousands of transactions per second
be very difficult — the
default-private nature of Tari notwithstanding!
Which software would you run? Typically, if you’re interested in helping scale the Tari network (and earn a return
for doing so), you would run a validator node.
If you’re interested in building a distributed client application, you would implement an indexer that follows your
As an example, suppose you run a real-world coffee shop and want to create a loyalty points system. In that case, you
can use the fungible loyalty points contract template and publish it on the network. Your customers can interact with
and store their loyalty points in Tari DAN wallets. Finally, to validate or display transactions for whatever reason,
you can set up a Tari Indexer node to monitor the resource and component address of your contract.
The development of the Indexer is still ongoing, with the Tari development community working on adding GraphQL and event
scanning capabilities. If you’d like to try it out, you can find it
here: https://github.com/tari-project/tari-dan/tree/development/applications/tari_indexer.