How to Make Complex Queries on a Blockchain

Seung Woo Kim
CodeChain
Published in
4 min readOct 16, 2018

A blockchain is often compared to a DB. There is clearly something in common, since both allow you to store and view information. If you want to store data in a blockchain and create various applications that utilize blockchain technology, you must be able to query stored data freely.

“Return a list of transactions contained in a block during a specific time window”

In commonly used RDBs, and NoSQL DBs, we can simply execute the above query. You can also create indexes in time fields to quickly handle them. However, blockchains do not create indexes other than some of the more frequently used fields. In other words, it is very unlikely for blockchains to provide the above query natively. There are significant constraints on the queries provided by the RPC APIs because they do not create an index unless it is information that is crucial for the blockchain. A simple RPC API that reads a block by the block number or hash value can only make a simple block explorer or an application that sends coins to a specific address.

CodeChain Indexer

To support various queries, you must import the data stored in the blockchain and create a new index in the DB. The CodeChain Indexer reads CodeChain’s block data and creates an index on top of ElasticSearch.

When a new block stacks in CodeChain, that block is fetched and the following index is created:

  • Block: Block data
  • Parcel: Parcel data
  • Transaction: Transaction data
  • Asset: List of unused assets at a specific address
  • AssetImage: Image data of a specific asset
  • Log: Number of blocks, parcels, transactions added to the chain during that day
  • Account: CCC quantity of a specific address
  • PendingParcel: Pending parcel data

The CodeChain Indexer indexes all the block information within the chain into ElasticSearch, allowing users to perform complex queries directly to ElasticSearch.

Here are a few examples of how indexes generated by the CodeChain Indexer can be used.

“List of unused assets owned by a specific address”

If you want to create a blockchain wallet, you need the data described above. CodeChain does not support JSON RPC because it does not create an index on the list of assets that a particular address has. If you create an index on ElasticSearch using CodeChain Indexer, you can create a query in a simple manner.

You can use the following query to get a list of the assets that a particular address has:

https://gist.github.com/xpdlf1004/46b35cec876f7c3984099535029b006c

The Indexer also provides a Rest API server in order to provide easy use without having to query ElasticSearch directly.

An API that returns a list of unused assets owned by a specific address is as follows:

```

https://husky.codechain.io/explorer/api/utxo/tcaqyqur2tpam5wgcspdey5vdxvxf95xuxh46esn5m6s7

```

The CodeChain Explorer currently available on the testnet is also using indexed data in ElasticSearch. You cannot implement the latest block, parcel, transaction list pagination or integrated search without indexed data.

Since CodeChain Indexer takes the name from the metadata of the asset and creates an index out of it, CodeChain Explorer can retrieve the asset by name. ElasticSearch provides a fuzzy search function by default, and thus, you can receive corrected results.

https://gist.github.com/xpdlf1004/bd6e9ad2ea2bbbcb90f5b5e85b5dfa72

Likewise, the API for retrieving an asset by name is as follows:

```

https://husky.codechain.io/explorer/api/search/asset/petrol

```

Conclusion

We’ve discussed CodeChain Indexers thus far. As mentioned earlier, in order to utilize the data stored in the blockchain in various ways, you need to re-index the DB. It is difficult to create a DB index separately because the blocks are added and removed repeatedly in the process of forming the blockchain itself. The CodeChain Indexer not only solves this tedious and picky task, but also provides an API to facilitate general usage, and thus, in order to create a variety of applications, the utilization of indexers seems to be a crucial part of the entire process.

(Korean version here)

--

--