Basic database structure and design
The Bitcoin Cash coin is a blockchain with millions of transactions. This is, in effect, a really large database. Some 200GB at the end of 2019. But it is and will be a database.
To do anything other than a simple interaction with the blockchain you will need to understand the basic database concepts of Bitcoin Cash in general, and Flowee in particular.
At the core of this are transactions. Any transaction moves funds unlocked
inputs and stores these funds in
outputs. With the difference
between them being a miner fee.
Transactions are mined into blocks. A block has a time-stamp, and blocks are always appended to the end of the chain.
Flowee stores transactions in the Hub. The hub uses the number of the block, also called blockHeight, as a key for any specific transaction. The second part of the key is offsetInBlock which is the byte-position of the transaction in the block.
The Indexer reads the entire blockchain once and creates separate database tables to allow fast lookup of transactions. For instance there is the transaction-ID (a 32-byte hash we call TxId) that is unique for each transaction. Using the Indexer you can resolve that TxId and you will receive the (blockHeight, offsetInBlock) pair that uniquely identifies a transaction in the Hub.
Transactions themselves form a chain (a Directed acyclic graph (DAG)). A transaction that spends a previously created transaction-output refers to it by TxId. From any transaction you can follow the money backwards in time till the moment the money was created as miner-reward (also called block-reward).
So, the basic transactions already allow going back in time. In order to do something different we need to be introduced to two new databases.
The UTXO database (short for Unspent-Tx-Outputs) stores all the transaction outputs that have not yet been spent. Or, in other words, which hold real money right now. According to the latest validated block, at least.
Any transaction output that has already been spent is removed from the UTXO. After it’s been removed the transaction that spent it is inserted into the Indexer’s spent database.
The Spent database allows you to create the reverse DAG, where you can start at any point from the creation of a coin and follow it forward in time until the current state.