Bitbus has arrived—a powerful indexing service

Getting your Trinity Audio player ready...

Unwriter has released Bitbus 2.0, an efficient indexing service for the Bitcoin SV ledger. Bitbus 2.0 essentially deprecates the older Planaria APIs as the increased transaction volume has revealed the flaws in its design. Bitbus strives to be a single endpoint that many services can interact with as opposed to each application running its own Planaria and filtering transactions from another ‘full node’ server.

 

Source: Bitbus

How does Bitbus scale?

Bitbus can scale more effectively because the filtering is done on the server-side. Clients make requests with a Bitquery specifying what data they want, and what format they would like the data in.

Since Bitbus has an indexed copy of the ledger, they can quickly fetch the transactions and return them to the client. Unlike Planaria, users of Bitbus do not need to download any JavaScript software and run on their side—they can simply make HTTP requests from their existing applications to interact with data from the Bitcoin ledger.

Furthermore, this lean architecture enables support with any platform out there. Any application written in any programming language (not just JavaScript!) can immediately use Bitbus since all they have to do is make API requests to the server.

Block header status endpoint

Bitbus implements a ‘Status’ endpoint which contains a JSON object representing details about the most recent block header. This is a nice addition as users can subscribe to this endpoint and be notified of the next block—and subsequently know when Bitbus is updated with the data from that block.

I particularly like this feature as I believe having the latest block details can be leveraged in applications to do some interesting things, and this API endpoint makes that very easy. I touched on this in my presentation at CoinGeek Toronto on unwriter’s tools at the timestamped link:

Bitbus + Bitsocket

The above detail is important because Bitbus does not store unconfirmed transactions; Bitsocket should be utilized to fetch those. Unwriter has documented how to implement this—applications would make an initial query for the confirmed transactions, then enter a ‘listen mode’ to get new ones.

This feature can actually ease the strain on Bitbus if applications simply execute a single query upon booting up, then use Bitsocket for the rest of its uptime.

Efforts to ease the scaling burden

In an attempt to address potential performance issues, Bitbus does not store large data pieces in the same database as the transaction format. Instead they are stored in a file system and referenced by Bitbus. Consequentially, apps will need to make multiple queries to different endpoints in order to fetch data greater than 512 bytes. Apps will receive a reference to the data that they then query against BitFS with.

While this is somewhat inconvenient for the client, this does help Bitbus maintain its uptime and responsiveness as it does not have to deal with serving large pieces of data.

Bitbus requires its clients to sign up for an API token at https://token.planaria.network/. Users can view their token usage on a dashboard with indications for ‘Traffic spent’ and ‘Time spent’ for data consumed and query time respectively.

This is speculation but perhaps this is the first potential revenue stream for Planaria Corp—leveraging the micropayment capability of Bitcoin SV by charging their customers based on actual usage of Bitbus.

Can Bitbus scale to Terabyte-sized blocks?

With all these efforts towards scaling along with the Bitcoin SV network, it is uncertain if Bitbus will be capable. Bitbus must fetch its data from a miner who will have more robust infrastructure in place to be able to handle this job.

That stated, due to the low transaction volume and block subsidy (soon to halve) miners have been quite lazy and passive thus far when it comes to providing these types of services. Regardless of whether this software is run by Planaria Corp or a miner, it is extremely useful in the short-term.