On the heels of his Genesis node, Unwriter introduces Babel

Bitcoin developer Unwriter has quickly become one of the most proficient coders for the Bitcoin SV (BSV) blockchain. Just after announcing his new Genesis BitDB node project, he’s at it again, this time introducing another BitDB node. The latest endeavor is called Babel.

https://youtu.be/gBb9FSxfyVs

In a new Medium post by the developer, Unwriter reveals the new BitDB node, explaining that it is designed for data-only Bitcoin applications. Instead of being used for money transfers, the platform is able to query those apps that use the OP_RETURN code to store data.

As Unwriter states in the post, “Most Bitcoin applications that use the blockchain as a database DO NOT need all the transaction details, because they only need to query OP_RETURN outputs and a couple of other attributes.” He adds that many of the features offered in a full node query, such as script database or graph database, are useful for many Bitcoin apps, but not all of them need to be able to access all of the data at the same time.

Babel was designed to provide a streamlined mechanism that will query OP_RETURN outputs, as well as only a few other useful attributes. It is “a subset of the Genesis.Bitdb designed specifically for data intensive Bitcoin applications.”

As with Genesis, Babel relies on the original address format of Bitcoin. Because it is streamlined, it is faster and more efficient than a full BitDB node and doesn’t use as much memory. Since it is a subtree of a full node, it incorporates the same Bitquery format as do the other nodes.

Babel only stores OP_RETURN output – the rest is stored as “null;” any transactions that don’t include an OP_RETURN output are ignored. Inputs are reduced to only store the input addresses, not the hash and index of previous transaction. In addition, the output produced by queries on Babel only contain push data – b0, h0, s0, b1, h1, s1, b2, h2, s2, etc.

According to Unwriter’s post, “Because the transactions are stored in BitDB according to the same schema as the full node, you can easily switch between a Genesis node and a Babel node.

“Because it stores much less than a full node, the Babel node can stay lean, which means more people will be able to afford to run the node in the future, not to mention higher performance that comes from specialization.”

Babel, like Genesis, is currently in beta. Once it is tweaked, Unwriter will make it open sourced and he welcomes all data builders to begin using it as it transforms.