SDBS #18 | A Working qPoS Prototype with the Asynchronous Network Clock

We present a video demonstrating qPoS and its asynchronous network clock in action.

I spent this week debugging the qPoS asynchronous network clock that ensures regular five second block intervals, but allows clients to resume on the correct chain even in times of heavy network disruption. Aside from the need to address some minor remaining bugs, the qPoS prototype on the internal testnet is functional enough to begin preparations for Public Testnet Phase 1.

This week’s update will be short because I spent most of my time this week debugging the network clock instead of adding additional features or making protocol improvements. I also spent time updating the whitepaper to document most of the major changes on the path to the functional prototype. However, the whitepaper does not yet include a description of the asynchronous network clock.

This post presents a video demonstration of the qPoS asynchronous network clock in action and elaborates a little on its final design. I will also review development progress and attempt to give a forecast.

— — — — — — —

Demonstration of the qPoS Asynchronous Clock

Earlier this week, moments after getting it working, I made a video demonstrating that the Stealth qPoS asynchronous network clock enables highly regular block intervals without any validation of block times against local hardware clocks. As noted in the video description, asynchrony means that block timestamps are not compared to the internal hardware clocks of nodes. Each block carries a timestamp that helps other nodes determine blockchain ordering. This timing information is not used to accept or reject blocks, only to advance the staker queue. The asynchronous nature of the protocol means that blocks can be late without being rejected. This property is useful because block latencies can be extreme when a network node has connectivity problems. The result is that nodes that won’t reject valid blocks just because they were late.

This video shows the a passive (non-block producing) node that records blocks as they arrive. Each new block creates a new line of output in the terminal screen shown. I start a stopwatch app immediately after a block.

Notice that approximately every five seconds a new block comes in. This is a network of three stakers and three nodes. Although it sounds like a simple network, it is actually a very difficult network to keep synchronized because of automatic network remodeling that is part of the peer-to-peer protocol. As I discussed in SDBS #16, I decided to keep this remodeling functionality on, even though it makes the small internal testnet extremely fragile. I figured if I could find a way to keep this highly problematic network synchronized, I would have discovered a very robust timekeeping protocol.

— — — — — — —

Development Review and Forecast

Since the last development review over two months ago, I have made a lot of progress towards getting qPoS to public testnet. In fact, it’s almost ready. The only tasks prior to launching the first public testnet (Public Testnet Phase 1) are to (1) fix a couple of bugs already identified, (2) do another round of rigorous testing, and (3) decide upon and code the testnet network parameters.

The following list summarizes the development forecast I presented in SDBS#9. Please see that post for a full description of all the forecast items. As always, note my standard set of disclaimers. Only one please

1. ☑ Implement the RPC commands.
2. ☑ Build the client (debug the building process).
3. ☑ Get it to run and create a testnet genesis block.
4. ☑ Run the Internal Testnet that tests all functionalities of the client.
5. ☐ During the Internal Testnet I will implement blockwise Byzantine fault tolerant (BFT) consensus.
6. ☐ Public Testnet Phase 1.
7. ☐ Public Testnet Phase 2.
8. ☐ GUI controls for qPoS operations (during Public Testnet Phase 1 & 2)
9. ☐ Staker bad behavior controls (during Public Testnet Phases 1 & 2)
10. ☐ Public Testnet Phase 3: open public testnet.
11. ☐ Mainnet release.
12. ☐ Begin development of anonymity layer.

In terms of the timeline, we hope to have a patent application submitted for parts of the protocol as well as working prototype source code released to GitHub by the start of Consensus in New York on May 13, 2019. Although functioning qPOS code may be available by then, Public Testnet Phase 1 may not be underway, but should begin shortly thereafter.

— — — — — — —

Hondo

— — — — — — —

Website / Telegram / Slack / Medium / Twitter / Reddit