SDBS #14 | Stealth qPoS Testnet Is Moving Blocks and Transactions

After three and a half months of development, qPoS is minimally working on internal testnet

This week, I was able to get the qPoS Internal Testnet to move blocks in real time, marking the most exciting week of qPoS development yet. I demonstrated this functionality on a youtube video. In today’s post I explain the significance of this week’s progress, describe what I did this week to make that happen, and give an overview of some potential next steps for the Internal Testnet.

— — — — — — —

Moving Blocks and Transactions

In the youtube video, I had two nodes running on the nternal Testnet. These nodes were called “t2” and “t3”. This configuration represents the smallest possible network, which keeps the system as simple as possible for debugging. This network had three stakers total, one of which was disabled, and two of which happened to be owned by the node named t3. Both of the stakers owned by node t3 were enabled and produced blocks.

In case this description is still confusing:

1. Node “t2”: 0 Stakers
2. Node “t3”: two stakers, both producing blocks in rounds

Blocks were produced at exactly five second intervals.

After introducing the network, I sent a test transaction from node t3 to node t2. (I could have sent funds the other way.) This transaction was confirmed in about five seconds, faster than I could type the command to check the transaction (gettransaction).

Notice how this demonstration satisfies the requirements for a blockchain payment processing network. (1) It has multiple nodes, (2) blocks are produced in regular intervals, (3) transfers are sent between nodes with reliable confirmation times.

— — — — — — —

Significance of This Successful Testing

The five second blocktimes of qPoS represent a 120x speed-up over the blocktimes of Bitcoin. This means users of Bitcoin must wait on average 120 times longer for a confirmation than users of Stealth qPoS, putting Stealth among the fastest blockchains in existence. Some cryptocurrencies may be slightly faster, but they are at a disadvantage in their designs in that they have account-based ledgers. Account-based ledgers cannot support true cryptographic anonymity available to Bitcoin-like ledgers.

I should point out that qPoS does not shorten the blocktimes of Bitcoin-like ledgers simply by changing one parameter in the code in the way Doge does, for example. Doge has fast one minute blocks, but they are highly irregular, subject to essentially random variations in PoW mining. To demonstrate, immediately after I wrote the previous sentence, I took a screencap of the DOGE block explorer:

Figure: Ten Recent Doge Blocks

Notice that Doge has significance variance around its target block time of one minute, and in this particular case, misses the target time by double the target spacing for this set of 10 blocks. In fact, the longest block is about four minutes (quadruple the target spacing of one minute). These variations impact the usability of the Doge payment system for numerous applications, such as point-of-sale or arbitrage. This lack of usability is compounded in Bitcoin, as it has 10 minute block times, but exhibits the same type of variance as Doge:

Figure: Ten Recent Bitcoin Blocks

This screencap of the Bitcoin block explorer was taken immediately after writing the previous sentence. Notice that Bitcoin’s block times are as variable as Doge’s, but scaled 10 times. For example, the longest time between Bitcoin blocks was about 40 minutes, similar to Doge’s longest of four minutes (scaled 10-fold), and, on average, Bitcoin’s block times are about twice the target of 10 minutes for this sampling.

Stealth qPoS block times exhibit variance, but this variance is on the scale of milliseconds (thousandths of a second) rather than on the scale of dozens of minutes, or in some cases, hours, as has been observed with BTC.

In summary, this week’s key achievements demonstrate the functionality of Stealth’s qPoS. Its design has highly regular five second block times, giving it a much wider range of practicality for numerous different payment applications.

Together, Stealth’s cryptographic anonymity-compatible ledger, derived from Bitcoin’s ledger system, and its novel scheduled staking algorithm (qPoS) will make Stealth practical for far more payment applications than any other coin known to the author.

— — — — — — —

QPoS RPC Commands Working, Replay Bug Fixes

Here I summarize my major coding achievements this week:

• Fixed registry synchronization on startup. Last week, I reported that I successfully registered a staker in a transaction that was permanently added to the qPoS blockchain. However, upon restart, the purchase transaction was not replayed correctly, meaning the registry lost the purchase information upon restart. I began the week by fixing this general problem that prevented the registry from synchronizing on startup.
• Made the PURCHASE3 transaction type work. This is a type of qPoS transaction that supports the RPC command purchasestaker. Purchase staker allows for setting both the delegate and controller keys and the delegate payout as a single transaction, requiring the PURCHASE3 blockchain transaction.
• Made the SETKEY transaction type work. This type of qPoS transaction is required for all qPoS key changes after the initial purchase. This includes setting delegate, controller, and transferring ownership.
• Made the setstakerdelegate RPC work. This RPC command not only changes the delegate public key in the registry, but sets the delegate payout.
• Made the setowner and setcontroller RPCs work. These two commands set the owner key (i.e. transfer ownership) and the controller keys.
• Made the SETSTATE transaction type work. This transaction type is a necessary blockchain transaction type required to enable and disable stakers.
• Made the enablestaker and disablestaker RPC commands work. Stakers can be toggled between enabled and disabled states, the latter of which disables a staker from minting qPoS blocks. In the disabled state, stakers are not penalized for being “offline”, but they do not mint blocks either. The ability to disable a staker is useful for failsafe scenarios, ownership transfer, or any time it is not practical to keep the staker enabled and subject to penalties for missing blocks.
• Fixed chain reorganization without snapshots. When a chain reorganizes, it searches the disk for the most recent snapshot that is earlier than the newest block common to both branches of the fork. If no such snapshot exists, the client now replays the registry from genesis.
• Fixed bootstrapping of qPoS blocks. In some cases, it is necessary to resync a blockchain (especially when debugging a novel consensus algorithm like qPoS!). This fix correctly loads qPoS blocks from bootstrap.
• Fixed registry sync while loading the block index. On restart, there is no need to bootstrap or re-sync a blockchain, but it is important to ensure the registry is synchronized on restart. Prior to this fix, the block index was loaded correctly, but the registry would not synchronize correctly.
• As mentioned above, I got qPoS running on a multi-node network and demonstrated the minimal functionality of sending transactions.

— — — — — — —

Goals for Internal Testnet

Over the next few weeks, I will try to get the Internal Testnet “production ready”. In other words, I hope to have Testnet so thoroughly debugged that I would feel comfortable releasing it on Mainnet, even though we would still have at least two more phases of Public Testnet.

Here is an incomplete list of goals for Internal Testnet:

• Ensure the registry stats are fully updated. Currently, the registry updates balances correctly, but does not keep some staker stats updated, like blocks missed, blocks assigned, blocks observed, total earnings, etc.
• Add another data field to stakers that stores the TxID of the transaction in which they were created. This will allow for third party services, like block explorers and staker monitors to offer more complete staker statistics.
• Scale up the network to at least five nodes. I believe a five node network will reveal at least 95% of all bugs that will be observed on a larger network.
• Have stakers running on all nodes with some nodes running multiple stakers.
• Ensure that qPoS reorganizations work. Currently Stealth PoW and PoS reorganizations work, but qPoS reorganizations still have some issues apparently related to registry synchronization.
• Ensure all nodes can sync to the full network on restart.
• Ensure nodes that restart on the wrong chain can reorganize during network sync.
• Make the CLAIM transaction type and claim RPC command work.

— — — — — — —

Hondo

— — — — — — —

Website / Telegram / Slack / Medium / Twitter / Reddit