Proof of Commitment (PoC+): a Proof of Capacity Upgrade

Introduction

Proof of Capacity (PoC) is a sound and fair consensus algorithm, field tested for more than 5 years in the Burstcoin network. Sound because it can use off-the-shelf equipment and is energy efficient. Fair because it has a very low entry barrier and shows a more linear scaling.

Burstcoin mining process: individual miners can use pools but there is no actual barrier for solo mining and improved decentralization. (image source)

Essentially, PoC consists of storing hard to compute hashes in the so called plot files and then reading a small fraction of these files (around 0.025%) every time a new block is forged. The basic idea is, the more disk capacity you have, the more hashes you can store (using different nonces), the higher your commitment is to the system and the higher should be your reward (your chances to forge a block).

However, due to its nature, PoC — as it is currently implemented — can show security issues resembling the nothing at stake problem. Burstcoin plot files can be easily reused by copycat PoC coins. On one hand this reduces mining costs and could increase total network capacity. On the other hand, however, this can be seen as a weak point, since mining an additional coin with the same plot files also only adds the small cost of an additional sweep on the plot files. This can bring future consequences: as the commitment in the mining process is reduced, the network as a whole is weakened. I’m referring to this as the multi-mine issue.

In this work, an alternative for increasing the commitment in the Burstcoin mining process is proposed. It addresses the multi-mine issue but it keeps: compatible plot files; all written in stone rules (block time, total supply, and reward decreases); a linear scale dependency; and the celebrated fairness and highly distributed nature of Burstcoin. The proposed method is called here Proof of Commitment (PoC+).

PoC Mining, Base Target, and Deadline

On PoC coins, every time a new block is to be forged, miners scan their plot files (which contain many nonces) looking for the smallest hit to compute the block deadline as follows:

deadline = hit/baseTarget (Eq. 1)

The miner with the smallest hit (every nonce stored in the so called plot files produces a different hit for a given block height) can forge the block after the deadline expires (amount of time after the last block). The baseTarget value in Eq. 1 is adjusted to keep the average deadline (block time) close to 240 seconds.

Now, let’s use a simpler version of the problem to understand how exactly it works, by assuming the hit values are integer values ranging from 1 to 100 only.

As a first example, let’s also assume that we have a single miner and that he/she has only one nonce stored in his/her plot file. As strong cryptography is used, hit values are unbiased and the chance of finding any number from 1 to 100 is the same. This means the frequency one should find the number 1, 2, 3, …, 100 are all the same, obviously, the long time average (or expected) hit value would be the average value, 100/2 = 50, in the middle of the interval:

Now, let’s assume that our single miner has 2 nonces stored, still valid hit values are in the range from 1 up to 100. The nonce mining a block is always the one with the smallest hit and the question is what would be the average hit value then? Again, as both values are completely random we should see an even distribution and one could reason that (on average) best and second best value should be equidistant:

Thus, on average, the hit value should be 100/3 = 33. Moving on with this logic, we can realize that the average hit (average small value found) should be N/(nonces+1). Where N is the number of different possible hit values. This can also be shown mathematically as discussed previously on Burst Reddit.

As the number of nonces in actual plot files is usually very large, nonces+1 ≃ nonces and we can safely drop the +1 to conclude that:

hit = N/nonces (Eq. 2)

This is a very interesting result, showing that miners with two times more capacity (2 times more nonces) should have (on average) half the hit value, all governed by this very simple relation. Actually, Eq. 2 is the fundamental equation used on estimating total network size and also individual miner capacities.

Burst Base Target

Different from our simple examples above, the universe of values a hit can actually assume is very large, given by 64 bits:

N = 2⁶⁴ = 18’446’744’073’709’600’000

Burstcoin creator (or team) probably knew about this and apparently assumed that the initial capacity (or genesis capacity) should be 1 TiB. Knowing that every nonce occupies 262’144 bytes, 1 TiB of capacity can fit 4’194’304 many nonces. Thus, the long time average hit for 1 TiB capacity should be:

18’446’744’073’709’600’000 / 4’194’304 = 4’398’046’511’104

However, we want the deadline in Eq. 1 to evaluate to 240 seconds, requiring the initial (or genesis) base target to be the above value divided by 240:

initialBaseTarget = 4’398’046’511’104 / 240 = 18’325’193’796

As more blocks are added to the blockchain, the block time control algorithm updates the baseTarget value to take into account miners coming and going and yet keeping block times near to 240 seconds. Using the adjusted baseTarget, the total network size in Tb can be easily estimated as:

networkCapacity = initialBaseTarget / baseTarget

SODIUM Deadline

The deadline formula in Eq. 1 is now called the legacy deadline. As discussed in a recent article and implemented in the SODIUM Burst hard-fork, currently the mining deadline is given by:

deadline = ln(hit/baseTarget) * 240 / ln(240) (Eq. 3)

As in the legacy deadline, the smaller the hit value the better, but the above equation ends up producing values much more close to the average value of 240 seconds.

Eq. 3 was chosen in a way that a hit generating 240 seconds deadline in Eq. 2 generates the same result in Eq. 3. However, as the new deadline formula is not linear on the hit, its average is not the same as the legacy deadline. Thus, a modified equation for estimating the total network capacity is needed. The following equation can be used as a good approximation:

networkCapacity = initialBaseTarget / (1.83 * baseTarget)

Individual miner capacities estimated using the legacy deadline (Eq. 2) can be left as they are.

PoC+ Proposal

In this section an alternative method for combining committed capacity (plot files stored on hard disks) and committed balance (stake in BURST on the block forger account) is proposed as a method to improve the commitment in the mining process. In the proposed method, the deadline should be computed as:

deadline = ln(hit/(stakeFactor*baseTarget)) * 240 / ln(240) (Eq. 4)

The only difference between Eqs. 3 and 4 is the introduction of the stakeFactor. As discussed before, miners with more capacity should have smaller hit values, given by the simple relation in Eq. 2. By adding a factor to the miner hit, we can account not only for the stored capacity the miner commits to the process (exactly as is today) but also for the stake in BURST committed to the mining process.

In Eq. 4, the stakeFactor should be a function of the miner committed stake in BURST per Tb. If all miners were to commit the very same stake per Tb, all miners would have a stakeFactor = 1 and mining would work exactly as it does today. However, different miners can decide to commit different balances and the idea is to benefit miners with more balance committed by attributing to them a factor higher than 1. These miners would have an increased estimated commitment (in contrast to the estimated capacity) as their deadlines would be effectively smaller.

Assuming miners would commit balances ranging in 9 different orders of magnitude, many possible factors could be derived. While in the present proposal I’m recommending a maximum factor of 4, some alternatives are listed below:

Stake factors for different committed balances per Tb with respect to the network average balance per Tb.

If the maximum factor is set to 4, a miner with 10’000 more stake than average will have his capacity multiplied by 4 (as this miner is much more committed to the network). A miner with 10’000 less balance than average will have his capacity reduced by a factor of 4.

By keeping all tied to the average stake value, there are no fixed requirements for the BURST amount miners should commit to the process, but a value that will emerge from the consensus algorithm itself. There is an advantage in committing more balance than average but the effective deadline is still strongly tied to the storage capacity committed. Additionally, miners actually vote on the mining process on what should be the average committed balance. As every time a miner with a higher balance forges a block, the balance deadline average is increased indicating the average value should be increased. The same is true in the opposite direction in the event miners with smaller balances per Tb forge more blocks.

The formula for computing the stake factor as suggested above is very straightforward:

stakeFactor = pow(stakePerTb, C) (Eq. 5)

Where stakePerTb is the committed balance per Tb being raised by the C power. If the maximum factor is to be 4, C should be 0.1505.

Computing the balance factor based on committed balance per Tb keeps a linear (fair) distribution. Making the miner estimated capacity based on the long period of one month also aims at making the balance commitment more fair for small miners. The block being mined is also computed on the capacity estimation to avoid attacks by splitting a large mining capacity in many different IDs.

All computations for the balance factor are based on block creator data (estimated capacity and committed balance based on block creator ID) and never based on pool data. The amount committed is the forger current balance or 1440 blocks in the past, whichever is the lowest. The base target control is kept as is and a new control variable is added: averageStake. This new variable will be adjusted to keep the average stakeFactor equals to 1.

Pool software would need to update their deadline formula so the estimated commitment (in contrast to the usual estimated capacity) is taken into account on the pool balance share.

Improved Robustness for 51% Attacks

The so-called 51% attacks are a frequent concern for any distributed consensus. With the PoC+ hybrid consensus, a miner/pool would only be able to succeed in a 51% attack if he/she has 51% of plotted disk space and at the same time has the average value in Burst available on his/her miner ID. If a miner has 51% of disk space (or even much more than that) but zero Burst, the effective mining power would be reduced by 3 or 4 times. If a miner has a lot of stake but low capacity, again a majority attack is impossible. If a miner has for instance 20% of the network in disk space and 10’000 times the average value in stake, as soon as more blocks are mined the average stake increases and the effective capacity of such a miner is again reduced.

As can be seen, PoC+ not only increases the commitment in the mining process but also makes the consensus much harder to attack. One cannot simply divert capacity currently mining other coins but also need to simultaneously stake a substantial coin amount for a non negligible period of time.

Expected Average Amount Committed per Tb

In the proposed method the average amount miners will commit to the mining process will emerge from the consensus algorithm itself, due to many different driving forces (economical, political, etc.).

One can only try to estimate what would be this future value in BURST per Tb, there is no way to actually predict it.

By the simple assumption that 1% of all circulating coins would be allocated for mining, that would amount to around 20’000’000 BURST. If we assume a total network capacity of 400’000 Tb, that would give an average amount of 50 BURST per Tb average. If 5% of all circulating coins is committed to mining, the average amount would be 250 BURST per Tb and so on.

Current Average Balance per Tb

Using one month as a time frame for estimating miner’s capacities and 1440 blocks as the time frame of the committed balance (as described before), the following distribution is observed for a short period of time (around block height 757’000):

Current balance per Tb for miners (unique generator ID) observed during half a day. Capacities and balances estimated as previously described.

As can be seen in the above chart, without any control measure, the larger the capacity the smaller tends to be the miner balance per Tb. So metrics that benefit those with more committed balance should favor decentralization in our current scenario and not the other way around. Average balance on miner’s accounts is currently less than 100 BURST per Tb. This translates to around 0,50 USD per Tb at current prices.

Conditioned Proof of Capacity

Many coins derived from Burstcoin now use what they call conditioned proof of capacity (cPoC). This method has the merit of requiring more than just capacity (plot files) but also requiring miners to stake a given coin amount. However, different from the proposal of this document, cPoC adds no additional 51% attack protection. It is purely an economic incentive that leads to centralization and benefits that extremely favor the coin creators (developers, team, company, or similar).

Conditioned Proof of Capacity centralization: coin creators at top, pools below. It is nearly impossible to solo mine. (image source)

Not only do the coin creators usually get a cut of every block forged, this cut has amounted up to 70% in some cases. A static stake requirement is hard-coded and miners that don’t have the required amount have a substantial part of their rewards diverted to coin creators. This gets even worse as coin creators usually pre-mine a large initial coin supply. Honest miners are forced to buy from coin creators to get closer to full block rewards. High fees apply to bind or pledge coins. This way, market manipulations become extremely beneficial to the coin creators and other possible bad actors.

Another centralization aspect is the assumption that a miner’s minimal capacity is 0.05% of the total network making stake requirements extremely nonlinear for small capacities. Stake requirements for small solo miners can be way greater than for big mining farms or pools, again leading to centralization.

Conclusions

Proof of Capacity (PoC) implemented in Burstcoin is the living proof that something better than Proof of Work (PoW) exists, running since 2014. It not only avoids the waste of huge amounts of energy but also provides more stable average block times and can use off-the-shelf equipment. However, the nature of PoC allows for multiple coins being mined with the same equipment with a small additional cost. This can lead to concerns similar to the classical nothing at stake problem in Proof of Stake (PoS) coins, with consequences still unknown.

Thus, in this work an improved PoC consensus is proposed, called Proof of Commitment (PoC+). PoC+ is a hybrid method combining Proof of Capacity (PoC) and Proof of Stake (PoS). In this new method, miners have to commit not only storage capacity but also balance (stake). This not only increases the commitment in the mining process but also makes the consensus much harder to attack, you cannot simply divert capacity currently mining other coins but also need to simultaneously stake a substantial coin amount for a non negligible period of time.

Different from the PoC variants available today (known as cPoC) that lead to centralization and unbearable benefits to the coin creators (team, company, etc), in the proposed method all celebrated Burstcoin principles of fairness and distribution are kept. Further, plot files are just the same and there are no changes on “written in stone” rules like total supply and reward decrease.

Energy efficiency enthusiast interested in encryption and blockchain. Has developed the BlockTalk platform, allowing to write smart contracts in Java.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store