Crypto.BI Toolbox abstracts database access through a thin database access layer.
Every database operation required to run the system has been made into a separate function in
This traditional approach, used in many system architectures, allows us to switch storage solutions by creating new subclasses of
For instance, if a graph database was chosen instead of MySQL, all a developer would have to do is create a subclass of
CBDAODriver and then implement every method for that specific database system.
db/dao/mysql/CBMySQL.* for an example implementation.
Below you’ll find documentation on the main functions in a DAO interface.
All DAO implementations must provide a default, empty, constructor. The singleton implementation on
db/CBDB.h will instance the driver implementation using the default constructor.
db/CBDB.his in charge of choosing which database back-end will be used based on user choice or configuration.
connect() is pretty intuitive, it’s in charge of connecting the driver interface to the underlying database system. The parameters are pretty much self explanatory.
Sends a trivial query to the database system and expects a known return string. An exception should be thrown if anything goes wrong. If the method reaches the return statement without errors then the returned string should contain a known value which can be checked.
Inserts a blockchain block into the database.
Retrieves a blockchain block from the database, keyed by its unique hash.
Retrieves the latest block stored on the blockchain.
Returns false if the blockchain database is empty or if any other error occurs.
Saves a block file path, the block hash and the byte offset into the data file where this block can be found.
This table is analog to the block index in Bitcoin Core.
Retrieves the latest block file path in the database.
Returns false if an error occurs or if the block database is empty.
Saves a transaction into the database.
Retrieves a transaction from the database, keyed by its unique hash.
Note: An early Bitcoin bug allowed a TX to be mined in multiple blocks but the multiply-saved TX contain the same data, so this function returns the first found TX with this hash. But it may not be assumed a TX belongs to a single block in Bitcoin pre BIP30.
Retrieves the latest TX read from disk block files.
This is *not* guaranteed to be the latest TX on the network, as TX’s may be locally stored out of order.
Inserts a transaction input into the local database.
Retrieves a transaction input from the local database.
Get the latest transaction input that was read from disk universally. That is, the latest input that was read and stored on the local database, regardless of which transaction this input belongs to.
List the transaction inputs in a given transaction, keyed by transaction hash.
Complement to list_tx_in : lists outputs instead.
Tries to retrieve a certain transaction output given a transaction hash and index.
Retrieves the latest transaction output that was stored in the local database. As with the other *latest* functions this does not guarantee this TX output is the latest on the network, instead this is the last output ever read from disk within the last TX that was stored on the block files and read by Toolbox into the database.
List transaction outputs, keyed by a transaction hash.
cb_tx_out_addresses table indexes the addresses used in each output.
This function adds an entry to that table.
This function lists addresses on the
cb_address_graph table establishes links between addresses. This function inserts an entry into this table.
address_to fields in the
cb_address_graph table generate a directed graph which represents the flow of value from address to address.
cb_info_nodes table stores general information about blocks, TX’s or addresses.
This function inserts an info node entry into the
cb_info_nodes table entry by its 64 bit unique key.
Lists all information available for an address on the
cb_info_nodes table. Information usually includes scam reports, famous addresses (Satoshi et al), vanity addresses and so on.
This information resides on your local server only and not available to the public. You can store sensitive or personal annotations here and they won’t be shared.
Lists all information available for a block on the
cb_info_nodes table, keyed by block hash.
Lists all information available for a transaction on the
cb_info_nodes table, keyed by TX hash.
Annotations usually include scam TX’s, suspicious TX’s, famous TX’s and so on.
cb_info_nodes table looking for annotations that match
Updates an info node.
Deletes an info node.
Disables database keys. This speeds up data loading from block files by a factor of 5 to 6x on average.
Enables keys if they’ve been disabled.