SDBS #28: First Look at StealthExplore
In today’s blog post, I give a first look at the StealthExplore application programming interface (API). Herein I refer to this API as simply StealthExplore.
Before watching the video, viewers are encouraged to check out SDBS #25 where I introduce StealthExplore, and SDBS #27 where I discuss how a rich list exemplifies central challenges of infrastructure scalability and how these challenges will be addressed in the implementation of StealthExplore. These two SDBS posts also give background information that will help viewers understand some of the concepts I touched on in the video.
— — — — — — —
The StealthExplore API is Under Construction
Please note that StealthExplore is still being developed and the API may change, including, but not limited to the name of the API commands, their required and optional parameters, what information the commands produce, the organization of this information. Once the core set of API commands are stabilized, I will release API documentation so that users can begin developing workflows around StealthExplore.
— — — — — — —
StealthExplore Performance
In the video I was a little surprised that it took over one second to retrieve 1511 outputs associated with an example address. While actually very fast compared to typical block explorers that use SQL backends, I can make this retrieval much faster using some optimization strategies.
In the video, I guessed that most of the time spent collating that information was to calculate block hash and retrieve the block information. After looking at the code, the time appears to be spent reading transactional data from disk (this transactional data is required to find the containing block and hence the block hash). This process was also slowed down by disk read latency arising from the fact that I was synchronizing the blockchain at the same time (which is very disk intensive).
I will improve these types of queries by storing the needed transactional data (namely block hash and amount of the output) in the StealthExplore records, reducing the number of times the disk is accessed. This increases the storage requirements of each input and output record by 36 bytes. But since this requirement represents disk storage, it isn’t significant.
— — — — — — —
Enabling StealthExplore
To enable StealthExplore, the user must add the line “exploreapi=1” to the StealthCoin.conf configuration file. Anyone familiar with running a typical cryptocurrency node will be familiar with how to modify this configuration file.
IMPORTANT: At this moment, the entire blockchain must be fully validated using the Stealth bootstrap to index the chain for StealthExplore. As mentioned in the video, the requirement to fully validate the blockchain will be removed in the near future, so that one can index a fully synchronized blockchain much faster.
StealthExplore can be used on the mainnet blockchain, but anyone wishing to experiment with StealthExplore must build for the qpos-3.0 branch. Please note that this is a development branch, and it is not recommended to run a production client or staking node from this branch. However, testing has not revealed any problems when using the qpos-3.0 branch with mainnet. Also note that StealthExplore is subject to implementation changes and that these changes will often mean the chain needs to be re-indexed.
In the video, I mention that it is possible to set the maximum dust used by StealthExplore. This configuration setting is called “maxdust”. The default value is 0.05 XST. To reduce it to 0.01 XST, for example, requires adding the line “maxdust=0.01” to the StealthCoin.conf configuration file. Please be aware that changing the max dust will necessitate re-indexing the chain for StealthExplore (which as mentioned in the video presently requires blockchain validation).
If you just want to experiment with StealthExplore, a convenient option is “maxblocks”, which stops blockchain synchronization at the specified block number. For example, you only want to wait a few minutes while bootstrapping and want to end blockchain synchronization at block 100,000, add the line “maxblocks=100000” to the StealthCoin.conf file.
— — — — — — —
StealthExplore Commands Demonstrated in the Video
In the video I demonstrate a few commands that embody most of the database management logic of StealthExplore. In principle, these commands are a minimal set to create a block explorer or light wallet.
Help for these commands can be obtained using the GUI console or the StealthCoind client. Commands take the form “help command”. For example, to get help for the getrichlist command, use “help getrichlist”.
A brief description of each command I demonstrated follows. All commands produce JSON.
- getrichlistsize — Reports the number of addresses with a balance greater than the max dust.
- getrichlist — Gets a subset of the rich list, and takes two optional parameters. The first optional parameter is the start (default: 1), and the second is the maximum number to retrieve (default: 100). Results are reported as an ordered set of key-value pairs where the key is the address and the value is the balance. Ordering is in descending order by balance.
- getaddressbalance — Requires one parameter, which is the address. The balance of the address is returned if it is known to the blockchain. Even balances of zero are returned.
- getaddressinfo — Returns the balance, its rank in the rich list (if it has non-dust balance), number of inputs, number of outputs, number of unspent, and block height at which the information was calculated.
- getaddressinputs — For each input in the blockchain for the supplied address, the transaction ID (txid), input index (vin), depth in main chain (confirmations), block time, block hash, lock time, previous output txid (prev_txid), and previous output index (prev_vout). The latter two allow an explorer or other application to cross references inputs with their spent outputs. The mandatory parameter is the address and two optional parameters indicate the first input to be reported and the maximum number of inputs to report (similar to the optional parameters of getrichlist).
- getaddressoutputs — For each output in the blockchain for the supplied address, the transaction ID (txid), output index (vout), amount, depth in main chain (confirmations), block time, block hash, and whether the output is spent (isspent) is returned. Parameters are the same as for getaddressinputs.
— — — — — — —
Hondo
— — — — — — —
