What

go-svdb allows for customizable structured storage of data on the BSV chain, making it easy for application developers to quickly and easily access the data they need without having to care about UTXO maintenance.

 

Why

Imagine, if you want to check out all transactions relating to your bitcoins from massive UTXO, the Bitcoin network will have to spend a lot of time to search, and then you can get the relevant data.

Imagine, if you want to check out all transactions relating to your bitcoins from massive UTXO, the Bitcoin network will have to spend a lot of time to search, and then you can get the relevant data.

To this end, an infrastructure service that supports structured, persistent storage of data on the chain and allows quick retrieval of data is necessary.

go-svdb is the infrastructure service that was born to solve the problem of data query on the chain. go-svdb can help developers quickly and easily obtain customized data on the chain to meet different business needs.

 

How

Using go-svdb to query all transactions for an address can be done with a simple http request.

go-svdb currently uses mongodb as its data persistence tool. The entire query process is similar to:

        db.collection.find({
                addr:”1NRURpVumZn4tm7WBvhmMUwV1VVVuiDS25”
        })

The result of the query will be returned via the response body of the http request.

The internal implementation of go-svdb is implemented by four modules.

        Amoeba Main program. It builds the skeleton for the entire crawling process.
        Filter , which is the key to customization, identifies and structuring data.
        DBS , which persists customized data and can be expanded arbitrarily.
        API , which is a module for go-svdb to provide external services.

 

Component description

Amoeba

Amoeba is the bridge between gp-svdb and the whole node, as well as the p2p network. Every time a block is sent, it gets the latest block from the whole node and passes the block to the filter, so that the filter filters and structures the data we care about in the block.

Amoeba uses a double-flag form to ensure the transactionality of the block during the crawling process. Each time Amoeba sets the first flag and then passes the block to filter. Wait until the filter completes his work, then set the second flag.

Amoeba listens for transactions in the memory pool at the same time. Pass the transaction in the memory pool to filter, so that go-svdb supports zero-acknowledgment transactions.

Amoeba is also responsible for the detection of the fork. Once a lone block is discovered, it will roll back the data.

Filter

Bitcoin networks are extremely inclusive, and everyone or every company can handle some services with the help of the Bitcoin network. Business is ever-changing, so no single data fits well across all businesses. Filter has adopted a single functional guideline at the beginning of the design. A Filter only cares about a specific type of data.

Filter is essentially a transaction’s observer. It cares about every transaction that appears on the Bitcoin network.

Filter customization is fairly simple and only needs to be implemented:

        type IAmoebaFilter interface {
                GetName() string
                StartCrawl(pFullnodeManager *common.FullnodeManager, block *wire.MsgBlock, height int64, tid int) error
                ClearContent(hash string) error
                HandleOrphanBlock(hash string)
                HandleNewTx(tx *btcutil.Tx, pFullnodeManager *common.FullnodeManager)
        }

And the matching persistence adaptation layer can be. The rest of the things amoeba will help you achieve.

DBS

go-svdb currently uses mongodb as a persistence tool. You can also adapt mysql and other databases if needed.

With the expansion of the bitcoin-sv network, the era of large blocks is in the near future. Data on the entire Bitcoin network will accelerate. The dbs module was originally designed to be the best for the arrival of the big block era.

Dbs controls multiple mongodb instances for data storage. It solves the problem of infinite expansion by adopting random insertion and unified query on data.

The current go-svdb runs three mongodb instances.

API

The data that the developer needs will be returned by the API module using the http protocol.