SDBS #24: Public Testnet Launch Update

A little more than a month ago we launched a public testnet featuring Stealth’s new consensus technology called Junaeth (formerly called “qPoS”). This testnet has 15 public participants, each running their own StealthNode. StealthNodes are the block producers of the Junaeth protocol, described extensively in the whitepaper.

— — — — — — —

Resolving Messaging Deadlock in Testnet

As with all new technologies, the testnet was not without its early hiccups. The main symptom was a general inability for some nodes to broadcast blocks. This problem was related to the multithreaded design of the protocol. I spent a lot of time in early development trying to preserve the multithreading design of the original Bitcoin protocol (discussed mostly in SDBS #4). In this design, the block production and message processing loops are separate. Having separate loops for block production and message processing makes sense for Bitcoin because its 10 minute block interval allows for plenty of time to resolve conflicts between blocks produced internally and those received from the network. Additionally, Bitcoin’s full UTXO model means that consensus does not rely on the synchronized state of any particular data structure.

Junaeth’s efficiency, flexibility, and five second block times require nearly constant execution of the block production loop to ensure the node continuously checks whether it should try to produce a block. Perhaps more importantly, Junaeth uses a StealthNode registry that tracks the scheduling of StealthNodes and their earnings, among other state-specific information. The stateful nature of the registry is a requirement for scheduled block production and therefore indispensable for Junaeth’s ultra-fast five second blocks.

Because of the reliance on registry state, two blocks cannot be processed simultaneously. Any blocks coming in from the network via the message processing loop must wait for the block production loop to temporarily halt. In my original design (with which the public testnet launched) I used multithreading techniques to alternately stop both the message processing and block production loops while the other loop executed. This approach was a consequence of necessity rather than the result of good planning.

Thanks to our patient public testnetters, we quickly noticed that this two-threaded implementation was too clunky to scale to a full network. The fix was simple and obvious once I identified the problem. I joined the two loops executing in two threads into a single loop executing in one thread. After this fix, testnet performed nearly flawlessly.

In a way, my original design was lucky in that it exacerbated so many problems in internal testnet (aka “devnet”). I was able to locate consensus issues much more readily and fix them before we went to public testnet, making the journey from launch to well-functioning testnet very fast.

— — — — — — —

Competition Update

Results of the competition as of block 559,051.

Blocks produced:

DonaldTrump 25349

Aizen 25348

onelove 25347

Sushi 25345

duvno 25343

dostealthstaker 25332

Richman 25332

GStaker 25223

LV1 24818

oracle 23377

dinkleberry 21700

Barrage 21657

Kitten 20483

snWestcoastUS 19790

stone 17155

— — — — — — —

Activities Since Launch of Public Testnet

One question the community might have is: what has the team been doing since public testnet began running smoothly? As a prelude, I must admit that we did not expect the transition from launch to near perfect performance to go so quickly. We originally anticipated at least a couple of months of debugging just to get a stable network. In reality, full network stability and nearly perfect performance required only about one week (though it was a long and tiring week for the core team). After that, we used this much needed buffer to attend to some Stealth business that we put off for months to get to testnet. Then, soon after we got this business taken care of, I had some unplanned family business to tend to. Under normal circumstances, this type of gap wouldn’t be worth mentioning. However, since we are in the midst of a public testnet, I feel like I should account for my time so testnet participants don’t feel left “hanging”.

— — — — — — —

What are the plans for testnet?

From here, we plan on running the testnet competition until December 10, 23:59:59 UTC, exactly three months after we made the announcement of the contest on Twitter. At this exact time, we will tally all blocks produced by every testnet participant and divide rewards according to block production.

After that, the public testnet will continue in a manner as close to a true mainnet as possible. All testnetters are encouraged, though not required, to participate going forwards. However, we will not be able to offer specific bounties for helping or running a testnet node. If no community members want to help, the team will simply continue with our own nodes and welcome anyone who wants to join.

The public testnet will then enjoy the introduction of our short-term development priorities. All of these updates are destined for mainnet and some are discussed in the roadmap.

1. A proof-of-concept of our design for blockchain oracles, which will serve as a prototype for other blockchain functionalities like on-chain governance and sidechains
2. An SPV wallet based on Electrum for public testnet, so that a larger community can preview the Junaeth protocol and potentially participate in Stealth
3. Updated built-in Tor that works better for Junaeth block producers
4. High performance secp256k1 implementation
5. A 10:1 split of the money supply
6. Transaction privacy layer

— — — — — — —

Hondo

— — — — — — —

Website / Telegram / Slack / Medium / Twitter / Reddit