Babel
Today I present Babel, a BitDB node designed for data-only applications (apps that use OP_RETURN to store data, instead of money transfers)
What is Babel?
Babel is a new BitDB node that runs on Bitcoin SV in addition to the Genesis Bitdb released yesterday.
Here’s the insight:
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.
1. What a BitDB Full Node Does
Let’s first take a look at what a Bitdb “full node” provides (as seen on https://bitdb.network website);
Those are a lot of things, ranging from “graph database” to “script database” to “transaction database”. This comprehensive nature is useful for many Bitcoin applications, but not all applications need access to all of these features simultaneously.
Especially, most applications that only use the Bitcoin blockchain to store and read immutable data, just need to query OP_RETURN outputs and a couple of other useful attributes, and nothing more.
And THIS is what Babel provides.
2. What a Babel Node Does
Babel is a subset of the Genesis.Bitdb designed specifically for data intensive Bitcoin applications. Highlights:
- Bitcoin original address format: just like Genesis bitdb.
- Lightning fast: Much leaner and faster than a full Bitdb node because it only stores a subset and takes up less memory.
- Backwards compatible: The Babel schema is a subtree of a full Bitdb node schema, so the same Bitquery works.
How Does It Work?
Babel doesn’t store everything. It only stores the data that matter to app developers who use Bitcoin as a database. Here’s the transaction object that gets stored into Babel:
A couple of things to note:
- OP_RETURN Only: Only
OP_RETURNoutput is stored. The rest are stored asnull. - Non OP_RETURN transactions pruned: The database ONLY stores transactions that have an OP_RETURN output. All other transactions are ignored.
- Pruned Inputs: Now ONLY stores the input address (No previous transaction hash and index).
- Push Data Only: Each output ONLY contains the push data (b0, h0, s0, b1, h1, s1, b2, h2, s2, …)
Full Node vs. Light Node
Let’s look at a real world example to understand how they are different.
Here I took a transaction from Bitcoin Plays Pokemon, where each Bitcoin transaction turns into a move in a remote game device (This is a great fun example of “apps that use Bitcoin as a database”, since the entire app is powered by OP_RETURN):
1. Genesis (Full Node)
First, here’s what an original bitdb (a full node) query response looks like, queried through genesis.bitdb.network:
2. Babel (Light Node)
And here’s the Babel node with the same query:
Much simpler!
While Genesis contains everything, Babel contains a small subset. And this is probably all you need in order to build most data-only Bitcoin applications.
Notice the out.s1 says left. This transaction is a command that moves the character in the Pokemon game one step to the left, you control the character with your OP_RETURN transactions!
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.
Usage
Just like Genesis Bitdb, the Babel node is also in beta, and will soon be open sourced after some usage and code cleanup.
But it’s fully functional and more performant than full nodes due to its size and efficiency, so I encourage you to start using it today if you’re building data intensive applications.
Here’s the endpoint:
https://babel.bitdb.network/q/1DHDifPvtPgKFPZMRSxmVHhiPvFmxZwbfh Which means, your requests will look something like this:
https://babel.bitdb.network/q/1DHDifPvtPgKFPZMRSxmVHhiPvFmxZwbfh/[BASE64_ENCODED_BITQUERY]Just remember, this node ONLY stores a subset of the full node as described above, so if you want to migrate an existing app from using a full node to Babel node, first make sure your app is using the attributes that are part of the Babel schema mentioned above.
Also remember, just like Genesis, the Babel node uses the Bitcoin original address format.
You can play with the explorer here:
And join the Slack channel if you have any questions:
Get Started
If you are new to BitDB, you may want to check out the documentation at https://docs.bitdb.network but here’s a quick start:
1. Read from Bitcoin
Learn how to READ from Bitcoin through Bitdb here:
2. Write to Bitcoin
To WRITE to Bitcoin, you can use libraries like:
Datapay is a dead simple JavaScript library that lets you declaratively write data to the blockchain.
BSV is a library maintained by MoneyButton and is the low level library that powers datapay. If you want to try more advanced features, you can always use BSV (By the way, Datapay also exposes BSV library interface to the developers as a variable)
Building an Infinite Library on Bitcoin
Until recently, entrepreneurs interested in building on Bitcoin have been forced to forget about using Bitcoin as an immutable database, despite the fact that this ability could unleash all kinds of business opportunities which then can provide more incentive for the miners and create a virtuous economic cycle.
This has been the case for BTC. Because of its block size limit and OP_RETURN limits, using the blockchain as a database is seen almost as a sin. The rationale is: if too many people start filling up the blocks, the transaction fee would go up and everybody would suffer, and there is no plan to lift the limits from the developers so there’s no other way. Here’s a good recent article discussing this problem:
With Bitcoin SV, it’s a completely different story. Using blockchain as a database is not only NOT a sin, but is a virtue.
Everyone in the Bitcoin SV ecosystem is completely dedicated to the plan to infinitely scale. There’s even a “Stress Test” team that voluntarily uses their own money to spam the blockchain with tons of transactions, just to find out all the choke points. And everyone welcomes it, because everyone realizes Bitcoin needs to scale and they need to be ready.
Many outsiders think all this obsessive scaling is crazy, but you must remember, historically whenever a new disruptive piece of technology came along and claimed to do something, it was always seen as crazy by the vast majority of the public.
And then one day, it just worked.
And this is not some fairy tale. The scaling is already happening. Bitcoin SV just recently mined a 103MB PoW block.
Let’s think about the current status for a moment. Now that we finally have:
- the pure version of Bitcoin which encourages using Bitcoin as a database (Monetizable data)
- node developers who are aiming to scale to Terabyte block size, yet dedicated to never touch the economic aspects of the protocol.
- and a very effective and easy means to using Bitcoin like a regular database (BitDB)
There is nothing stopping creative entrepreneurs from building all kinds of Bitcoin applications that were never possible before due to various artificial and social constraints. You can finally let go, and build all kinds of crazy ideas on Bitcoin, and monetize.
The rest is up to you.
Let’s go build an infinite library on Bitcoin together.
