QPoS Development Review and Staker Economics

In today’s post, I am excited to review qPoS development so far and to give an idea of what progress needs to be made before testnet and mainnet. I also discuss staker economics and present the final pricing structure, which differs somewhat from what I proposed in the Whitepaper.

–––––

Progress of qPoS Development

The following list represents major coding milestones on the way to a basic qPoS implementation that would be minimally suitable for mainnet. For the most part, this list was made in retrospect (after coding). I won’t discuss each milestone because it could get pretty long-winded. But each milestone represents an approximate equal share of time and work (though not necessarily equal lines of code).

1. ☑ Design of qPoS Cardinal Classes (QPStaker, QPQueue, QPRegistry)
2. ☑ QPoS Block Minting Thread
3. ☑ Registry Synchrony Thread
4. ☑ Timestamp Attack Deterrence
5. ☑ Block Validation for qPoS
6. ☑ Transaction Validation for qPoS
7. ☑ CBlock, CBlockIndex, CDiskBlockIndex, CTransaction qPoS Modifications
8. ☑ Registry Persistence
9. ☑ Ternary Key Design (Owner, Delegate, Controller)
10. ☑ Registry Housekeeping (Queue & Staker Management)
11. ☑ QPoS Operations Implementation (Purchase, Set Key, Enable/Disable, Claim Rewards)
12. ☑ QPoS Operations Validation (Filtering and Organizing for Application)
13. ☑ QPoS Operations Application (Effecting Registry State Changes)
14. ☑ Registry Replay on Startup
15. ☑ Registry Replay on Chain Reorganization
16. ☑ Standard Client Data Structure Housekeeping (mapBlockIndex, mempool, etc.)
17. ☑ Staker Economics and Pricing Structure
18. ☐ RPC Commands for qPoS Operations

Hopefully, it is obvious to the reader that all items but #18 are complete (though not yet published to github). One question that comes to mind is “how long will it take to write the RPC commands?” Most readers know by now that my standard answer to “when” questions is “probably never”, but, assuming I actually write the RPC commands at some point in the future, they should take about two to three days to implement.

–––––

QPoS Development Forecast

Would that get us to testnet? No, not immediately. The following list shows the path to testnet (of which there will be more than one) and then mainnet:

1. Implement the RPC commands.
2. Build the client (debug the building process).
3. Get it to run and create a testnet genesis block (meaning it can boot!).
4. Run the Internal Testnet that tests all functionalities of the client, including all qPoS operations (purchasing, setting keys, enabling/disabling, claiming block rewards). This will also test misbehavior (timestamp attacks, idleness), forks (purposefully creating more than one chain), reorganization (normal chain rollbacks), housekeeping (purging of stakers and low balances), fresh startup, blockchain download/synchronization, and client restart, among other functionalities.
5. During the Internal Testnet I will implement blockwise Byzantine fault tolerant (BFT) consensus. By design, qPoS already has block finality according to BFT as defined by Lamport, Shostak, and Pease. I can elaborate in a future post, but finality of a qPoS block could take over 1.5 minutes without blockwise BFT (assuming about 30 stakers). With blockwise BFT, finality could be achieved within a second.
6. Public Testnet Phase 1. I will release the qPoS code to github for the Phase 1 Testnet, making it “public”. Participation will be by invitation only, hoping to get about 10 participants plus the team.
7. Public Testnet Phase 2. We will likely restart the testnet chain and have an open enrollment in Phase 2 until we fill about 20 slots. I expect this period to be free of daily bug reports because we should have found most obvious bugs in Phase 1.
8. During Public Testnet Phases 1 & 2 I will add new functionalities, most notably:
   a) GUI controls for qPoS operations (purchase, setting keys, enable/disable, claims)
   b) Staker bad behavior controls (see the two accusatory operations described in the whitepaper)
9. Public Testnet Phase 3. Open public testnet. Just download the testnet client and ask the team or others for valueless testnet coins. Try to find bugs. We plan incentives for participation, finding bugs, etc. KYC may apply to receive participation and bug bounties.
10. Main Net Release
11. Begin development of anonymity layer.

Please Note: The above list is NOT a list of promises. It is my personal wish list and not an official list in any capacity. The milestones in the above list may never be completed by anyone. The list may change. The list may go away. I may go away. The price of XST could go to zero. The software, if ever produced, may malfunction.

Also please note that I did not include times in this latter wishlist. Each step in the above list does not represent equal work or equal time.

–––––

Staker Prices

This week, I finalized staker prices, attempting to balance several different factors:

1. The pricing of stakers should encourage 20 - 30 stakers with reasonable ROI at 1% total inflation rate. A reasonable ROI would be 10% - 20% earnings on the original price per year, as valued in XST.
2. Earlier buyers should get better deals than later buyers
3. Prices should be sensitive to decreasing money supply as stakers are purchased. In other words the prices of stakers should go up with each new staker, but they should still be reasonable prices in terms of the money supply, at least until some optimal number of stakers.
4. The first 22 stakers should be at a good discount.
5. The next 64 stakers should be at no discount.
6. The next 128 stakers be at a slight premium (we don’t expect more than 50 stakers at this price tier).
7. Any additional stakers should be unaffordable. The reason for the increasing prices is to discourage the purchasing of stakers just to influence consensus, say by governments or other well funded adversaries. Obtaining 50% of the staking power should require much more investment than is reasonable and should make existing XST holders very wealthy. The assumption is that early adopters are likely to be more “pure of heart” than later adopters, some of whom may only be interested in control so that they can undermine XST as a payment system. Additionally, a staker should retain its value, meaning the OTC market should not be undermined by the blockchain market.

The chart above shows the staker price in terms of XST, assuming about a 31 M XST money supply. It shows that stakers get more expensive as new stakers are added, but the increase in price per staker is lower for each new staker.

The above chart is misleading if one considers how much stakers cost as a fraction of the XST money supply, illustrated by the following chart:

Notice that, as a fraction of the XST money supply, the increases in price increase with each new staker. The main reason is that the XST money supply drops with each new staker.

The interpretation of these charts is that it is very difficult to control the XST network simply by buying stakers from the blockchain. Blockchain staker prices do not directly influence OTC market prices, except that blockchain staker prices effectively set a ceiling on OTC market prices. Because each new blockchain staker is more expensive than the previous, this ceiling turns out to be fairly generous, meaning staker owners looking to sell their stakers will not have to worry about competition with the blockchain.

The following table shows the cost for the first 30 stakers, assuming a starting money supply of 31 M XST.

For reference, the formula for the staker price is:

Here, M is the money supply and N is the number of extant stakers. In other words, the price of the first staker bought will be calculated with N=0. The unusual brackets surrounding the log term indicate the mathematical floor function, which converts the result of the log term into an integer, implicitly subtracting any fraction from the result of the log. For those interested in computer science, note that if the log is base 2, as it is here, this floor term is equivalent to one less than the bit length of the number 42+N.

–––––

Hondo

https://www.stealth.org