Why I am excited about the eCash Chronik project.
This article is based on my twitter thread about the new Chronik Indexer project.
It was recently announced that the eCash Global Network Council (GNC) approved and funded a project to build a blockchain indexer, and integrate that indexer into the Bitcoin ABC node software. The goal of this article is to explain the significance of this announcement.
What is a Blockchain Indexer?
An indexer is a basic piece of blockchain infrastructure. That sounds pretty boring, but in this case there are lots of interesting effects of this project. It’s nice to see others excited about this also. A recent post at the eCash blog explains how using Chronik will make Cashtab faster.
But what’s special about Chronik? Aren’t there already other indexers in existence? Yes, in fact there seems to be an over-abundance of blockchain indexers out there! A few examples are:
- Blockbook
- Bitcore
- BTCD/BCHD nodes
- bcoin/bcash nodes
- SLPDB
- psf-slp-indexer
- ElectrumX
- Fulcrum
- and many more
So why add one more to the mix? In fact, the proliferation of indexer projects is an ongoing problem in the Bitcoin space. So it’s definitely not obvious that creating Yet Another Indexer is a good idea. (obligatory XKCD)
What makes the eCash Chronik project different?
A major goal of the Chronik project is to integrate the indexer directly into the node software. This is something that has been proposed on Bitcoin Core several times, but was never able to come to fruition.
But what difference does it make if the indexer is integrated into the node? Why not keep them as independent components in the system? The reason it’s important to integrate the indexer into the node can be summarized in one word: STATE
In short, things such as transactions and blocks have “State”, which means they have attributes that can change (eg, a transaction can be unconfirmed vs. confirmed, a block can be in the longest chain, or can be orphaned).
Keeping track of this State is the Node’s job.
The job of the indexer is to keep track of large amounts of aggregated information that users care about. For example, an address indexer can keep track of XEC address balances, and then people can ask “what’s the balance of address “ecash:xxxxxxx”, and get a quick answer.
But as you’ll notice in that example, the balance of addresses depends on the State of blocks and transactions (whether a transaction is confirmed or not). This means that indexers also have to keep track of State. That’s duplicating the the node’s job!
Duplicating state also adds complexity, since it’s now possible that the node and indexer states could get out of synch. Basically it’s a big mess. Integrating the indexer into the node will result in simpler logic. It’s just “The Right Thing to Do”.
Empowering Builders
An indexer included in the node will also be easier for developers and entrepreneurs building on top of eCash. Rather than having to manage two programs (with possible version incompatibilities, etc.), they can just run their Bitcoin ABC node with some flags turned on to activate the indexing functions they want.
The goal is to build technical infrastructure to enable eCash to be a viable alternative to Central Bank Digital Currencies (CBDCs). Having an indexer is just one of the needed pieces, but an important one. It facilitates building applications that interact directly with the eCash blockchain.
Good luck to Tobias Ruck who will be doing the work to integrate Chronik into Bitcoin ABC node software!
