Thread by @AntonyZegers

Why am I excited about the #eCash #Chronik project? (And why you should be excited too!)

An indexer is a basic piece of blockchain infrastructure, sounds pretty boring.

But in this case there are lots of interesting effects of this project, read on to find out more!

/Thread

https://twitter.com/eCashOfficial/status/1514574486242213895

BTW, it's nice to see others excited about this also.

An immediate benefit @CainBCHA mentions is that it will make #Cashtab faster.

https://twitter.com/CainBCHA/status/1518711866331176966

But what's special about Chronik? Aren't there already other indexers in existence?

/2

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?

/3

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: xkcd.com/927/)

What makes the Chronik project different?

/4

A major goal of the #eCash #Chronik project is to integrate the indexer directly into the node itself. This is something that has been proposed on Bitcoin Core several times, but was never able to come to fruition.

github.com/bitcoin/bitcoi…

/5

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

en.wikipedia.org/wiki/State_(co…

/6

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.

/7

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.

/8

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!

/9

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”.

/10

An indexer included in the node will also be easier for users. Rather than having to manage two programs (with possible version incompatibilities, etc.), they can just run the Bitcoin ABC node software, with some flags turned on to activate the indexing functions they want.

/11

The goal is to build technical infrastructure to enable #eCash to be a viable alternative to #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.

/12

Wow, this turned into a longer thread than I expected!

That's all for now.

Good luck to @TobiasRuck who will be doing the work to integrate #Chronik into #BitcoinABC node software!

/FIN