Data structure and integrity
On Namecoin, similar to Bitcoin, all data are stored on multiple instances, including key/value stores as table-like databases. This way, Namecoin's data structure ensures the uniqueness of each Namecoin asset, regardless of its registration lifecycle.
The blockchain-based database (“the blockchain”) stores hex-encoded raw data of the transactions including inputs (previous outputs such as transfers), unspent outputs (UTXOs), and name operations (e.g.,
name_update) along with the TxIDs of the inputs. Naturally, future transactions accessing these outputs can't be written to the current block, so it's impossible to trace a transaction history forward just by making data requests from the blockchain. While it's possible to toggle backwards by reading the TxIDs of a transaction's input, toggling forward the transaction history requires a fully indexed blockchain explorer based on a server-based SQL database. The blockchain-based transaction details of name operations include data such as the name of the cryptographic asset (e.g.,
d/bitcoin), its associated NMC address, and the user-generated payload data values such as DNS settings or contact data.
The purpose of making this database blockchain-based is to cryptographically secure the database against future manipulation. Each data block is therefore linked to the previous one by the hash of the previous block header written to the current block. To further verify the integrity of the transaction history, TxIDs are added to a hash- or transaction-tree, a data structure called the Merkle tree. In a Merkle tree, transactions are grouped into pairs, and a hash is calculated for each pair. In the next instance of the tree, these hashes are paired and hashed again until there remains a single root hash, known as the Merkle Root. Every node operated by a community member, not just the mining nodes, validates the integrity of this data structures.
For efficient user requests, such as domain name lookups and their history, name-related data is stored additionally in a key/value store in the
of the data directory, along with UTXO data and other blockchain state information. This database is formatted as a LevelDB database, an open source key/value store developed by Google LLC in 2004, split up into multiple files. The database contains tables such as the “name database”, which stores the decoded transaction details from the blockchain mentioned before, including the TxID of the most recent name operation and its associated NMC address, as well as the asset's name and its current user-generated data value. Another dedicated index in the LevelDB database provides the block height of the asset's expiration. If the
-namehistory start parameter of the Namecoin Core wallet is set, a separate “name history” table is created to store the data that will be output on the
name_history RPC call.
The start parameter can be set when starting the Core wallet via CMD console/Terminal or, line by line without the leading dash, as a parameter in the
namecoin.conf configuration file in the data directory. On a fresh installation, this file needs to be created manually using a text editor. If the additional start parameter
-txindex is set, another dedicated LevelDB database containing the entire transaction history will be created in the
.\indexes\txindex subfolder of the data directory. Nodes running with both
-namehistory -txindex start parameters are called fullnodes.
As of February 2024, the data directory of a full node is about 7.5 GB in size, of which about 1.4 GB (or about 18%) are allocated to the separated LevelDB-based key/value stores in the
txindex subfolders. While the blockchain is being distributed step by step with each block submitted over the network, the separated databases are created locally by the node from the decoded blockchain data.