Gini BlockGrid Database Pruning

To preserve stakeholder privacy, the Gini BlockGrid database only stores the Public Transaction Index (PTI) hash and the Global Transaction Vault (GTV) hash, which are hashes of entire Gini block hashes (i.e., hashes of grouped transaction hashes). These hashes do not include any stakeholder’s personally identifiable details; these hashes are recorded on the public-facing PTI/GTV solely to guarantee that nobody can create any Gini out of thin air, which also helps to prevent the “double-spend” problem.

As a result of Gini’s database architecture (in particular, not recording any personally identifiable information in the public PTI/GTV to preserve privacy), the Gini database size is already much smaller per-transaction than Bitcoin and other previous generation cryptocurrencies. However, all public ledgers will grow out of control if they are not managed much more efficiently than Bitcoin’s DB, which is over 185 gigabytes as of October 2018!

Such a large database file size makes it impossible for the vast majority of nodes to download the entire Bitcoin database to verify all the transactions. This dramatically increases the centralization of the Bitcoin network because only a relatively small number of users have enough available storage capacity to run full nodes, which means only a small number of nodes can analyze the entire blockchain’s transaction history to verify its integrity. This is another form of centralization (in addition to the economic centralization) in the cryptocurrency world today that defeats the entire purpose of a decentralized cryptocurrency.

The pruning feature enables us to substantially eliminate this problem. This is an overview of how it works: With pruning, we can implement periodic database snapshot hashes of the PTI+GTV, then prune all the transactions included in the snapshot, then resume the hash accumulation until the next pruning cycle, which will likely be every week in our case. For context: Bitcoin adds about 3GB/month to its database in late 2018; so, a weekly pruning schedule is reasonable.

This pruning technique enables us to reduce the size of the Gini database by another order of magnitude, which would enable us to limit the total Gini database size at all times to approximately 100-500 megabytes no matter how large the Gini Network becomes. Compared to Bitcoin’s ballooning 185 gigabytes and counting, this would give Gini a huge database performance advantage.

Some people and organizations may still wish to maintain the pruned Gini transaction archives for their own peace of mind or for their own future forensic analysis. In those cases, anybody (including the Gini Foundation or any other person or organization) can archive the pruned snapshots and host them on their own public servers. Again, these pruned archives don't include any personally identifiable information; so, this has no privacy implications whatsoever.

However, the entire point of pruning (specifically, the underlying Merkle Tree data structures that make pruning such a powerful technique) is to have confidence in the cryptographic hashes (BLAKE2 in Gini's case) that are used in the pruning process. So, the vast majority of people will not need to care about the pruned archives because the proven cryptography that creates the hashes and the complimentary Merkle Tree data structure guarantee the integrity of the Gini BlockGrid all the way back to the genesis block without having to load up a 185-gigabyte database simply to verify the Gini BlockGrid's data integrity. To put all this into perspective: On an average computer, this synchronization process on the Bitcoin network can take many days (sometimes weeks!) depending on the speed of the user's network connection and other parameters.

One final point: It's important to keep in mind that the primary reason Gini can leverage database pruning is because the Gini BlockGrid only needs to record each stakeholder's final account balance to verify that the network is not creating any new money and to prevent the double-spend problem (in addition to Gini's Dynamic Proof-of-Commitment consensus algorithm). Thus, Gini does not need to record and analyze every single UTXO (unspent transaction output) across the entire Gini BlockGrid's transaction history because each stakeholder's final account balance—by definition—represents the mathematical truth of the current state of the database at both the individual account and collective BlockGrid levels at any point in time.

In contrast, Bitcoin requires every single UTXO to be recorded and retrievable by all full nodes because the Bitcoin protocol steps through the entire database—one transaction at a time—from the present all the way back to the genesis block in 2008 just to perform a simple database integrity check. Compared to a well-designed snapshot/pruning system based on secure cryptographic hashes and Merkle Trees, Bitcoin's database management approach is a terribly inefficient way to manage a transaction database and it offers no additional security in exchange for all its data bloat and computational demands.