PoS Boo, MNs and QP in detail

SHIELD
10 min readApr 29, 2018

Community members often ask what will happen to mining, staking and masternode rewards once the maximum supply of XSH is reached.

For the sake of clarification, it’s important to note that at the time the standard block reward reaches its terminus, both miners and stakers will continue to be rewarded through the generation of transaction fees. However, to incentivise staking and the creation of masternodes, we are increasing the maximum coin supply of SHIELD from 660 million to approximately 750 million, by means of an adjusted rewards scheme.

Masternodes

Evaluating the return-on-investment (ROI) for a masternode (MN) involves considering the amount of active masternodes (which is not predictable). To better understand ROI calculations, the following formula can be applied

a = Number of coins minted (in this period, 45% of the blockreward)
b = Total number of active masternodes
c = Last block number (in this period)
d = First block number (in this period)
e = 45/3600/24/365 (time per block, given in years)
f = Coins required to host a masternode (200,000 XSH)

Masternodes will earn a percentage of the block rewards over a period of around 5.5 million blocks. During this period, masternode rewards will account for approximately 106 million XSH in total. This amounts to a calculated ROI of about 9% per year (varying on the number of active MNs) at the time masternodes are activated on the SHIELD network. We concede that this ROI strategy may offer lower rewards than some other cryptocurrency masternodes, but we believe this is a necessary approach in order to prevent a high rate of inflation, which can impede coin adoption.

The following graph plots ROI/year (in %) against the amount of active masternodes (initially estimated at 500 — low, and up to 2500 — around maximum).

Here is another representation, extended into the z-axis.

This additional axis illustrates the effect of a decreasing block reward on the ROI/year of a masternode. The value for z is calculated across a time period, in which the sum of all masternode rewards during that period is divided by the time period (in years). Naturally, the higher the z, the earlier the blocks.

Applying this formula to the two years following the implementation of masternodes will result in a yearly return of approximately 9%, or approximately 7% when applied to the total masternode reward period of 5.5 million blocks.

Proof of Stake Rewards (PoS Boo)

Due to the greater number of variables involved, calculating the estimated returns of staking with our custom PoS protocol is made slightly more difficult. In simple terms, per user rewards are dependent on both the number of users staking, and the total amount of coins those users are staking at any given time. It cannot be assumed that when half the available XSH supply is locked in masternodes, the remaining supply is being staked. This factor creates an additional variable to the reward calculation that is likely to change frequently.

PoS Boo is fundamentally similar to a voting system, where stakers may choose to vote for which block is likely to be “correct” and subsequently be added to the blockchain. We can define this variable as the factor c, for the staker’s “confidence”. The higher the c, the higher the reward (r) if correct, however, a higher penalty will also be incurred if found to be incorrect. A block will be accepted when the majority of voting power has voted that particular block to be correct.

The economic weight is a function of the number of coins a user has chosen to stake, as well as the users c value. The block with the largest economic weight will be accepted as the valid block. Additionally, if a user gives a c value to multiple blocks (with ill intent), a severe blockchain level penalty will be applied to that user.

Consider the following when calculating the estimated annual reward for a SHIELD staker:

reward per block = (PoS block reward) * (weight / network weight)

The PoS block reward is initially 16.1 XSH. Both “network weight” (the sum of the weight of all users that correctly validated the block) and the “weight” will need to be calculated separately.

weight = z * (number of coins the user is staking)
z = 2 -2/(c + 1)

Because user confidence will vary for each block (just like user weight and the network weight), the calculation of annual staking returns accurately is not possible.

To further illustrate this, the chart below shows the annual SHIELD PoS reward, assuming 280 users are staking every stakeable block with both the same weight and confidence. These 280 users are also correct 100% of the time. This chart demonstrates the large variance in the number of XSH users receive.

Proof of Stake Penalties (PoS Boo)

That was the most-requested information by the community. But now comes one of the most interesting parts of the custom PoS Boo protocol, differentiating it from almost all other proof-of-stake implementations: the possible penalties. Penalties are required to ensure the integrity and security of the blockchain is maintained, acting as a countermeasure to malicious blockchain attacks. There are two types of penalties implemented: a penalty one receives due to voting on multiple blocks at the same blockheight, and a penalty one receives for giving confidence to a chain that turned out to not have majority support. Each scenario is different and attracts different penalties.

Multiple votes at the same blockheight

If a client gives confidence to multiple blocks at the same blockheight (and it is deemed as malicious), they will be penalised. This mechanism will discourage blockchain attacks by drastically decreasing its profitability. There are two ways (the two types of penalties) with which Boo inherently decreases the likelihood of attacks on the chain, with more if you count the annihilation of long range attacks. Boo has been made to prevent any one entity from gaining 51% or more of total validation power. This is because now, instead of just 51% of hashing power, an attacker also requires a significant amount of coins; without enough coins, an attacker with sufficient hashpower still cannot take over the network. If one still attempts to manipulate the chain by maliciously voting for multiple blocks at the same height, 25% of their staked coins will be burned.

Voting for the “wrong” block

If a staker gives confidence to a certain block at a certain height but turns out to be incorrect, they will receive a penalty, but not as severe as the one for voting on multiple blocks (as voting on the wrong chain may happen by chance, whereas voting for multiple blocks will not happen without malicious intent). A penalty is required to discourage voting on bad chains, and thus promote achieving consensus. The penalty is initially small/zero, but in the case a staker gets a block “wrong” n number of times per time period, they shall lose an amount of SHIELD given by the following formula:

or simply:

where:
n = the number of faulty votes
weight = z * (the amount of coins you are staking)
blockreward = the current SHIELD block reward (initially 46)

Quantum proofing (QP)

Last but not least, some hotly-anticipated news about quantum resistance — we have decided on the resistance scheme to integrate into SHIELD. There were various factors that were carefully considered when choosing an appropriate algorithm. Some algorithms are very secure, but consume a lot of storage space to use. To allow greater transaction speed (tx/s) while keeping quantum resistance active, our initial thought was that we may have to sacrifice security. But after many hours of research and planning, we found a way to achieve both: relatively small transaction size with great security against both classical and quantum computers. This is through the use of BLZZRD (an improved version of BLISS). The quantum proofing algorithm will be written in C++, and we have already finished a lot of work, including creating the library. Implementing the technique into the SHIELD blockchain is still in progress.

And that’s not all. Most quantum-proof algorithms have a problem when used in a cryptocurrency; they do not permit reuse of private keys or public addresses. Naturally this is a very prohibitive and unrealistic restriction. Our mission was to find a way to solve this. Introducing Project Carbyne.

The existence of Project Carbyne is one of the reasons why we cannot deploy quantum resistance onto the SHIELD network in the short term — our quantum proofs are custom made, just like our PoS scheme. Creating, perfecting and testing these solutions takes a considerable amount of time. But by making this large investment of our time, we are able to build a more robust and superior implementation than others before us.

With BLZZRD, transaction size will be approximately 0.8KB. This is a lot larger than normal SHIELD transactions, which are around 0.18–0.3KB. What this means is that one transaction signed with BLZZRD can take almost 20x as much space to store. We are working on a system that will allow you to choose whether you want a quantum proof address or a regular address, leaving the user free to choose whether they desire a secure address (with the downside of possibly higher transaction fees), or not. In the case that all transactions are quantum proof, SHIELD can still pass on around 800 transactions per minute, which is superior to any other post-quantum algorithm. This, combined with the fact that our technique does not restrict the reuse of the same private key and public address make our quantum resistance solution the best to date.

The differences between the standard and QP schemes

The above chart shows the transaction size of a transaction with x amount of inputs. You can clearly see that the QP transactions hit 500KB relatively quickly (which is currently the maximum block size for SHIELD). A SHIELD block containing only normal, non-QP transactions can carry a maximum of around 2800 inputs. This is in contrast to a block that only contains quantum-proof transactions, which can only carry a maximum of around 625 inputs in that same 500KB. Although resistance to quantum computers is very important, we are initially going to support both non-QP and QP transactions. To illustrate this in another way, the graph below shows how many QP and non-QP transactions you can fit into a block together, for a varying number of inputs per tx (z).

An increase in the amount of inputs drastically lowers the amount of transactions that can fit into a block. Plotting this on a 3D plane shows a view of the above data for a series of z values.

Furthermore, we also compared our post-quantum algorithm with other solutions. This isn’t a completely fair overview, as we do have re-usable private keys and public addresses while most other post-quantum techniques shown below do not.

The data shown above is from the best case scenario, with only one input per transaction and no outputs. This is, however, a great indicator to show the difference in transaction speed (tx/s) and the amount of transactions that can fit in a block for a variety of post-quantum algorithms, as well as the standard signature scheme. This also illustrates a key factor in our decision for choosing this particular algorithm as opposed to others.

Maximum supply

As mentioned earlier, the maximum supply of SHIELD will be increased. This will be achieved in two ways: the amount of blocks with a reward will be increased, and the block reward itself will be slightly increased, through a hard fork. This was done to incentivize staking and the creation of masternodes by increasing annual ROI, and will ultimately increase the efficiency and stability of the SHIELD blockchain.

The reward changes will take effect after a relevant hard fork. The following table highlights the changes that were made.

Our current plan is to implement masternodes before block #800,000. The reward from the blocks immediately following the hard fork upgrade have the same reward as pre-fork, to not promote inflation over that period of time. After that, we have a rewards reduction planned for block #2,124,000, with the following blocks having an increased total reward of 46 (as opposed to the previous 32). After block 4.248M, we initially had no reward. But we have now chosen to delay this for another 2.124M blocks, with a halved reward (23).

--

--