【Filecoin】Why do we have to compete for the computing power ranking?

At 8:00 AM on Friday (June 19), the Filecoin testnet was reset as planned. This reset was because many changes were incompatible with the original implementation. In order to save time, it was not upgraded by forking the original chain, but directly reset. The benefit is that it saves time, and it is also to allow the development team to focus on the realization of the reward phase, instead of spending a lot of time on chain maintenance.

We still see that after the reset, many teams’ publicity and promotion are still mainly focused on: 1) hashrate ranking; 2) block efficiency; 3) seal speed. It is understandable that everyone needs to do marketing, publicity, and promote ecological development. There is always something to promote.

However, focusing only on these aspects at this stage may be misleading. On the one hand, the general public may not be able to make an accurate judgment, and on the other hand, the information may not be accurate. The reason for this is that as far as the current implementation is concerned:

1. The computing power ratio is too high, and the token income is actually at a disadvantage

2. In the current network, those with a smaller computing power share are theoretically more advantageous, but this is more related to network conditions and synchronization efficiency.

3. Seal speed demonstrates certain optimization capabilities, but sometimes it is contrary to efficiency. At the same time, the Seal speed demonstration can be forged* (for specific details, please refer to some discussions when the second phase was just launched, and of course it can also be proved by a third party challenge).

*Note: This does not mean that someone will definitely forge it, but it is technically feasible. We certainly hope to see everyone improve performance as much as possible.

So the question is, why do people still hold on to these points at this stage? Repeating the various indicators before. Maybe it’s because the rhythm has been brought to this point. However, unfortunately, no one has brought a new rhythm this time.

Why is it said that if the computing power ratio is too high, the token income will actually suffer? Because the algorithm has changed since the second phase of the test network. Whether a miner can win a round of mining rights depends on the following simple judgment:

Here h(vrfout) is a random number; e is the expected number of blocks at each height, currently set to 5; myPower/totalPower is the miner's computing power ratio.

The above formula means: if your computing power is r = myPower/totalPower, then your probability of winning the election is r*e. The problem is, because e=5, when your computing power exceeds 20%, you will definitely win the right to produce blocks. It doesn't matter how much more.

In other words, no matter your computing power is 20%, 21%, 60%, or 80%, in theory you should be able to produce blocks in every round and get block rewards. In this case, the computing power exceeding 20% ​​is meaningless.

On the contrary, if you have 10% of the computing power, theoretically you should have 50% of the block generation rights, which means you have a 50% chance of generating a block. You can weigh whether you have reached this indicator. Generally speaking, due to interference from various factors, the actual probability of successfully generating a block and joining the heaviest chain is less than the theoretical block generation rights.

Why did we change it to this? In a word, it was a trade-off between stability and security. Here are the main factors to consider:

• Block rewards are proportional to the proportion of computing power - Fairness

• Filecoin network blocks are more stable and message packaging is more complete - Scalability

• System security improvement - Security

To achieve these goals, the Filecoin team has done a lot of exploration. In the initial design and last year's development network stage, we basically considered an average of one block per height. This makes it easier to achieve fairness in block generation and rewards, but there is a very uncomfortable problem. There are too many rounds of empty blocks. We have calculated in theory that under a normal Poisson distribution model, the proportion of empty rounds reaches more than 30% (1/e).

What should we do? In the first phase of the test network, we made a simple and interesting improvement: increasing the block generation rate of each miner. We introduced a new concept: ExpectedBlocksPerEpech, or e. Currently, this value is set to 5, which means that the number of blocks generated in each round is 5. We also adopted a complex GenerateCandidates mechanism, which is calculated according to a fixed ratio of sectors, and introduced a ballot system to calculate block rewards according to votes. No matter how many votes a miner wins, he can generate one block. This mechanism is relatively complicated. But it is still very fair.

According to calculations, when the ballot system is adopted, the theoretical number of blocks in each round cannot reach e (5), but the average number of votes is e. The average number of blocks is about 3.8, which varies according to different distributions.

However, this algorithm still has hidden problems. The main problem is that when the computing power increases, the amount of calculation within a block time increases linearly. However, the block time is fixed, and the gradual increase in the amount of calculation is unreasonable.

Therefore, before the start of the second phase of the testnet, the algorithm was further improved. The main improvement was simplification, which is the current algorithm. As mentioned earlier, the algorithm is very simple and the voting system is removed. Every miner gets the same reward for producing a block. However, there is a 20% cap problem here.

The 20% cap seems unfair, because miners with more than 20% computing power will definitely suffer. But is it important? Not important. Because it is fair to miners with less than 20% computing power. If the computing power of every miner in the entire network is less than 20%, it is fair.

In other words, this algorithm actually sets a soft upper limit for computing power. You can exceed this line, but there is no benefit. Such a setting is actually helpful for decentralization. So the team did not care about this when designing. But miners must care about it. But it is true that this upper limit has been ignored by many miners intentionally or unintentionally.

So, is this algorithm okay? Actually, it is not.

There is a big problem with this algorithm. There are no secrets . An important security factor of blockchain is randomness and unpredictability, that is, secret elections. However, in the current algorithm, a miner with a computing power of more than 20% can theoretically win the election in every round, so there are no secrets. Without secrets, many things will be easier to handle. For example, it is too easy for several big miners to do something bad together.

Filecoin's block election is a POS mechanism. Compared with POW, POS has no secrets in terms of equity ratio, which is all public. This POW is completely different. The workload of POW is unknown to the implementation, there is no state record, and it can only be judged by statistics at the time, and the block generation is completely random. The equity ratio of POS is already public. In this world of secret elections, the more public information is, the easier it is to be exploited. So if an algorithm can be used to infer who can definitely win the election, this is not appropriate.

The absence of secret elections and the lack of randomness increase the risk.

Yes, we need a better algorithm. A safer and more random election mechanism to ensure the security of the chain. Once this question is raised, everyone will brainstorm and come up with many solutions. For example:

• Or add a voting system to reduce the probability of large miners producing blocks and increase the weight of votes to adjust the block rewards.

• In addition, set an upper limit on the probability of block generation (that is, further reduce the soft upper limit above)

• Let each miner conduct multiple rounds of elections at each height

I personally prefer to solve the problem by simply setting an upper limit, which will reduce the code changes and take into account both efficiency and engineering implementation. However, the right to produce blocks is not a trivial matter and must be carefully considered and analyzed.

Look forward to the next improvement, which should happen soon.