Editor's Note: This article comes fromCarbon chain valueEditor's Note: This article comes from

Carbon chain value

(ID: cc-value), speaker: Conflux Research Director Yang Guang, text collation and proofreading: Cinderella, Tang Han, published with authorization.

I am very glad to have the opportunity to share some of my research and insights in this field with you here.

01 Sybil Attack and Blockchain Consensus Protocol

Today I will talk about the comparison between PoW and PoS. Let's first review the most typical blockchain consensus protocol: everyone packages transactions into blocks, connects the blocks into a chain through hash references, and obtains a shared ledger. But it is definitely not safe to use a ledger directly in this way, because bad people can also create a ledger, and then put two ledgers in front of you at the same time, which one is true and which one is fake, and which one should we believe? asked a question.

If it is centralized, of course, this problem is very easy to solve-I use Alipay, and Alipay says how much money I have in my account, that is how much money it is. If it is inconsistent with the facts, I can go to court to sue him if I have a different opinion. But if it is decentralized, this matter is difficult to say. In the case of decentralization, everyone does not have such a definitive institution. It is necessary to reach a consensus through other means in order to have a fair ledger. So in a decentralized environment, how should consensus be achieved? An easy-to-think method is that we vote, everyone votes together, and votes for a ledger, and then we all believe in it.

However, since we are talking about voting, there is a question of fairness in voting: how to distribute voting rights? For example, we all vote together today, and I have one hundred votes in my hand, and each of you sitting here has one vote. This is not called voting. I have one hundred votes. Basically, I say what I want to vote for, and the result is what it is of. If we really want to reach a consensus, it is impossible to vote in this particularly unfair way. Therefore, the distribution of voting rights is one of the core and most important parts of the consensus protocol. The problem of offline voting rights distribution is actually relatively easy to solve: we simply have one person, one vote. Everyone has an ID card, and then just register when voting. But online, it is very difficult to achieve one person, one vote.

Let’s briefly talk about what Sybil attack is: it means that attackers can create many accounts at low cost, and then control these accounts to act together, making others look like there are many people. For example, on forums, you will see that there are trolls guiding public opinion, and for example, on movie rating websites, there will be people who specially organize to review comments and scores on it. If there are many accounts of this kind of navy vest attacking, the result of your final vote is not true. It is possible that a certain person casts a lot of votes in this way, and the final voting result is completely controlled by this person. In the traditional Internet environment, we have many ways to fight Sybil attacks, such as increasing the registration cost of each account. When you want to register an account on the Internet, you often need to enter a verification code. This is because it is more troublesome to implement on a computer. Even if you can write a program, it is more difficult, but it is very simple if you do it by human beings; Sometimes it is required to bind a mobile phone number, or to detect the IP address, which are relatively common ways to resist Sybil attacks. But in a decentralized environment, the above methods are not easy to use. Because in a decentralized environment, who will publish the verification code, and who will judge whether the verification code is filled in correctly? Then who will verify the mobile phone number? Even if you use the ip address, it is actually a very unfair way. Because we know that not everyone enjoys a static IP address equally.

So in the blockchain, the most common solutions we actually use are a proof of work (PoW), a proof of stake (PoS), and a proxy proof of stake (DPoS). There are other proof methods, such as proving how much space you have, or how much money you have burned, and other methods, but the most common ones are PoW and PoS. Here I would like to emphasize a little bit, no matter PoW or PoS or other PoX, they are anti-Sybil attack mechanisms and an important part of the consensus algorithm (protocol), but they are not equivalent to the consensus algorithm.

secondary title

02 Proof of Work

Next, let me talk about the workload proof that everyone is more familiar with.

The basic idea of ​​proof of work is that computing power determines the right to produce blocks. If you can solve a PoW calculation problem, you can produce a block. Roughly summed up, it can be understood as one vote for one CPU, or one vote for one GPU or one mining machine. Its benefits start with the fact that the system is permissionless. Participants don't need anyone's permission, as long as there are machines with computing power, they can participate-in theory, they don't even need machines. If you can manually calculate the hash of a block and upload it in time, others will recognize that it is a legal block. Another is that the cost of PoW voting itself is relatively high. Regardless of whether CPU, GPU or mining machine is used, the cost of the machine and the cost of electricity must be spent in real terms. This is the same as the verification code we said before, in fact, it is a bit similar in form, right? There are some verification codes. After reading it, people still need to spend a little time to identify what the numbers or letters inside are, and then they can type in and pass the verification. One of the biggest advantages of Proof of Work, I think, is that votes and voting rights are bound: once the vote is successful, even the voter himself cannot modify the content of the vote.

According to the general logic of proof-of-work, when voting, you need to package a block first, and then do proof-of-work on this block. If you make a proof, it is equivalent to casting a vote, but at this time the packaged block has no way to modify up. For example, my mining machine can cast a lot of votes in one day, but if I want to concentrate the computing power of the previous day on a new block, this is impossible; on the other hand, if I want to roll back my own I also have to pay the same computing power as when rolling back other people's blocks for the blocks produced. This is a particularly nice feature of PoW.

Of course, the consensus algorithm based on the PoW mechanism also has some disadvantages. First of all, the disadvantage is that the delay is relatively high, because after we pack the transaction into a block, this block does not immediately become a valid candidate block, at least one proof of work must be completed before this block can be called a candidate block . The time for proof-of-work here cannot be set particularly short, and I will explain why it cannot be too short later. Therefore, at least during the period from when the block is packaged to when the proof of work of the block is completed, it is impossible for your transaction to be confirmed. So even if Bitcoin does not wait for six blocks to be confirmed, but confirms when it sees one block, it takes an average of ten minutes to confirm a transaction. Another point of criticism of the PoW mechanism is that it consumes a lot of energy and is not environmentally friendly. Regarding this point, whether the energy consumption of the proof of work is necessary, I think it is a matter of opinion, and I can have reservations. But since we are talking about proof of work, there is no way to save this workload. If it is saved, it will be called another name.

Let's take a look at how to solve the main problems of PoW-based consensus.

The first one is to say that the confirmation speed is slow. Taking Bitcoin as an example, it takes an average of ten minutes to produce a block, and another six blocks to confirm, which takes an hour on average. The second is relatively low throughput. Everyone knows that Bitcoin has been criticized for several years on this point. Then the third point is that high energy consumption is not environmentally friendly. But the third point, since we want to use PoW, this energy consumption is unavoidable, so we don't want to solve this problem.

For the first two problems, slow confirmation speed and low throughput. In fact, these two problems seem to have a very simple solution - reduce the target difficulty of the PoW problem and increase the speed of block generation. Litecoin actually does just that. It lowered the target difficulty from Bitcoin's 10 minutes to 2.5 minutes, and then produced blocks four times faster than Bitcoin. Another way to improve throughput is to increase the block capacity. For example, BCH first expanded each block from 1M to 8M, and then expanded to 32M. There was even a proposal to change it to 128M. Intuitively, at the same block production speed, the larger the block, the greater the throughput.

Is it so simple to solve the problem of slow confirmation speed and low storage capacity of Bitcoin? of course not. If it were really that simple, Bitcoin would not be set at 1M in ten minutes. Why can't the method just mentioned solve the problem? Because when we produce blocks faster, the blockchain will fork very frequently, especially when your block production speed exceeds the broadcast speed, the fork situation will be particularly serious.

If we reduce the difficulty of the PoW problem, increase the block generation speed, and then increase the block capacity, in fact, under certain network conditions, the broadcast speed will definitely be reduced. Because the larger the block, the slower the broadcast. Then if you say that your block production speed is fast but the broadcast speed is slow, that is to say, I can mine a block myself before receiving a new block from others, and then there will be a fork. Then if the gap is relatively large, there will be a lot of forks.

What's wrong with having too many forks? The biggest disadvantage is that it will reduce security. In Bitcoin, we often say that 51% of the computing power is required for bad guys to attack. The premise is that good people are concentrated on one main chain. In this case, 49% of the good guys concentrate on it, and 51% of the bad guys can attack. But if such frequent forks really occur, for example, I have 30% of the computing power on fork A and 40% of the computing power on fork B. At this time, the bad guys want to roll back fork B and change it to fork A. It doesn’t need a lot, it only needs 11% of the computing power. As long as it is slightly more than the difference between the two forks with the most honest computing power in the world, the attacker can make the longest chain jump back and forth on these two upper forks. So if you really change the parameters of Bitcoin simply and rudely, the security will definitely be reduced in the end.

But I don't think PoW can be blamed for this reduction in security. PoW is just an anti-sybil attack mechanism here, and its difficulty can be adjusted. The culprit of the reduced security here has to be carried by the "longest chain" instead of PoW. Why is the fork much less secure? In fact, it is because Bitcoin adopts the longest chain consensus. Under the longest chain mechanism, if there is a fork, the honest computing power is likely to follow the fork, which means that honest people will vote for fork, so that it is easier for bad people to manipulate the final result.

Then the next question: Why does the longest chain consensus based on PoW fork? Does it mean that if everyone is a good person, there will be no fork?

This is not true either. We use each line in the graph to represent a node, and the arrow to the right represents time. When this node generates a block, it needs to broadcast the block, but broadcasting takes time, so an "event light cone" will be formed. The farther you are from the node that generated the block, the longer it will take to receive the broadcasted block, and you will have to wait until later to see the new block just generated. That is to say, only other nodes in this yellow area and later can see a block generated by your side. Since there is a light cone, there is correspondingly an area outside the light cone, which is the green part in the picture. When a node is in the area outside the light cone, it is impossible for him to know that a block has just been generated on your side, because it has not been broadcast yet. In other words, if the next block generated in the network is in the yellow part behind, then of course it is safe, because at this time all nodes have seen the latest block, and then they will follow behind when producing blocks There will be no forks - if everyone is good.

But if the speed of block generation is relatively fast, and I generate blocks in the area outside the green light cone, then there will inevitably be forks, and then there will be orphan blocks in the end, right? Because it is impossible for these two blocks to reference each other. So to make a simple estimate, the orphan block rate is roughly equal to the area of ​​the area outside the light cone divided by the total area of ​​the expected block interval. Because the event of block generation occurs randomly with equal probability within the expected block interval. On the other hand, the smaller the proportion of the area outside the green light cone, the lower the likelihood of orphans.

But in reality, we will definitely not have only four nodes, we will have a lot of nodes, and when there are more nodes, the broadcast time will naturally become longer. The longer broadcast time means that the area outside the light cone will become larger, and our block generation interval will also need to be longer, so as to ensure that the orphan blocks will be controlled within a relatively small range. Because in fact, the orphan block itself also has an impact on security. For example, if there is a 20% orphan block rate, only 41% of the computing power is needed instead of 51% to complete the attack. Therefore, in order to improve security and reduce orphan blocks, we must lengthen the block interval. For example, Bitcoin is set at ten minutes. Of course, this ten minutes is not completely unchangeable, but the security will definitely be affected a little after the change.

After the block interval is lengthened, the efficiency of the entire system will be reduced, especially the throughput will be greatly affected. Let’s take a look at the bandwidth of the entire system here. In fact, it can be divided into three parts: a part of the bandwidth (blue part) is the transaction that everyone will eventually add to the consensus during transmission; another part of the bandwidth (red part) is the transaction that everyone is transmitting Some data that does not join the consensus, including the overhead of the entire protocol, and some may be invalid blocks and transactions that were not finally added to the consensus; the last part (white) is the bandwidth that was not used and wasted. If we use PoW as an anti-sybil attack mechanism, and then use the longest chain protocol to calculate the final consensus, our utilization rate of bandwidth is actually very low.

Taking Bitcoin as an example, we generate a 1MB effective block in 600 seconds, and expect to have a valid 1MB block in 600 seconds. Even if I expand this block several times, the 600 seconds in the entire network can be effectively used by me. The amount of information stored may be less than 20MB? But now the average speed of the network is already several GB in 600 seconds. Therefore, its utilization rate of the entire network bandwidth is only about 1%, and the waste is still very serious. If we use some technology to speed up the broadcasting speed, such as using dense block technology, then the time for the area outside the green light cone will be shortened. In this way, we can also shorten the block interval proportionally, and improve the utilization of bandwidth while maintaining the same security as before. But even with such an improvement, as long as we use the longest chain and control the orphan block rate, the utilization rate of bandwidth is still not much higher. Generally speaking, a public chain network may have thousands or even tens of thousands of nodes. If it is to be broadcast, it may take ten or more forwards on average. Take the need for ten forwardings as an example, starting from the node that produced the block, sending it to the next node, and then this node receives the block and verifies it before sending it to the next node. This process needs to be repeated ten times. Within the whole process of these ten forwardings, if I want to reduce the orphan block rate, I need other nodes in the whole network not to generate a second block during this period, or only have a very low probability of generating a second block piece. In other words, for such a long time, everyone is actually only broadcasting one block. After the first person passes it on to the second person, and when the second person passes it on to the third person, the first person is in an idle state, right? So the final bandwidth utilization is naturally not high. There may be a constant times improvement compared to before, but it is far from being able to use up the entire bandwidth, and it is already considered very good to be able to use 1/10.

In this case, if we want to avoid forks, the inevitable bandwidth will be dissatisfied, and if the bandwidth is dissatisfied, TPS cannot be so high. Because you have so much data to synchronize together, there is an upper limit to the transactions that can be placed in it - if the size of the transaction remains the same (reducing the transaction size can also improve TPS, but all other blockchains can also be used. Same technology, relative disadvantage remains the same).

In fact, the problem to be solved just now is that the honest computing power will not be concentrated after the fork occurs, which will reduce security. But this solution does not mean that there is only one solution to reduce the probability of bifurcation. For example, we can also use DAG-based directed acyclic graph to solve.

When Ethereum chooses to fork, it does not use the longest chain but the GHOST protocol. In fact, Ethereum uses a slightly modified version. The core idea of ​​this protocol is to choose the branch with the heaviest subtree instead of the longest subchain when encountering a fork. In this case, no matter whether you have a fork or not, and how many forks there are, the problem of security is not a big problem. Because even the honest miners of the fork will still contribute to the security of the previous choice. For example, a miner is forking in a later block, but the miner still contributes to the security of how to choose a branch somewhere before the fork. It contributes a weight on the subtree of the branch that should be selected.

Although Conflux will have some repeated transactions, because it fully utilizes the entire bandwidth, and under this premise, the effective bandwidth utilization rate is much higher than that of GHOST, so the throughput of the entire system can be improved. . In comparison, since the total bandwidth utilization of Bitcoin is extremely low (~1%), even if it reduces the protocol overhead, the throughput gap with Conflux is still very obvious.

03 Proof of Stake (PoS)

The basic idea of ​​proof of equity is: when you hold coins (sometimes people also call this stake), you have the right to bookkeeping and then have the right to vote. Your voting rights are directly proportional to the number of coins you hold, which is one coin, one vote. Simply put, the more money, the more power to vote.

The basic framework of the PoS protocol is to allocate packaging rights and voting rights according to the currency holdings of all participants. In the PoS system, packaging and voting are separated, and it can also be separated-in the PoW system, these two things are actually the same thing. After the packaging right is allocated, the person who gets the packaging right is eligible to create a candidate block. This block contains transactions to be processed and has its own signature. The candidate block does not mean that it will be added to the consensus. After the candidate block is broadcast, those who have voting rights need to vote.

The form of voting can be to make a signature on the voted block. After receiving more votes after voting, the candidate block will finally be added to the consensus and become a valid block. Of course, we can implement the voting process in many ways, and the more common one is to use a consensus algorithm in which the minority obeys the majority. Because now we know how many people are eligible to vote and how many votes there are, so we can easily calculate the majority with this consensus algorithm, such as more than 1/2 or 2/3. This is very different from PoW, because in the PoW system, you do not know how much computing power the entire network has, you can only rely on estimates, and generally the estimates are not accurate. Therefore, it is impossible in the PoW system to use a certain threshold to judge what is the majority.

In the decentralized mechanism, we need to elect who is responsible for packaging and who is responsible for voting. Sometimes for the sake of efficiency, everyone will first elect a relatively small committee, and then they will be responsible for voting. If it is not the DPoS mechanism of Proxy Proof of Stake, such committees are usually selected randomly and rotated frequently for fairness.

In the PoS system, if some participants are detected to have violated the PoS consensus protocol, they can be punished. For example, some people vote for many blocks with one vote, or they have votes, but they just refuse to vote. These behaviors that will affect the security of the system can be punished.

Let’s take a look at the advantages of Proof of Stake again.

The first advantage: the incentives of miners and coin holders are the same. All PoS miners must hold coins, reducing a role in the entire ecological environment that does not hold coins but relies on machines to mine. In the PoW community, there are often situations where the interests of the rich, developers, and miners are not completely consistent, and then there will be quarrels, so that many things are difficult to get done in the end. In PoS, at least the interests of miners and capitalists will be more consistent, and conflicts and differences will be reduced to a certain extent.

The second advantage: the delay of PoS can be made very low, and the confirmation can be very fast. In the PoS system, a transaction can be packaged immediately after getting a transaction, and it can be broadcast after packaging. There is no need to wait for this time, unlike PoW, which must wait for at least one PoW problem. In fact, the delay of PoS consensus is mainly limited by the network and the number of voters. Because the more people you vote for, the longer you'll have to wait.

The third advantage: PoS is more environmentally friendly because it does not require proof of work. Voting is actually a signature, and at most some simple calculations are done, which is much easier than solving the PoW problem.

But its disadvantages are also relative to the above, and some advantages of the PoW system are lost.

First, PoS systems are slightly less anonymous and permissioned than permissionless PoW systems. Because as a person, I want to join a PoS system, and if I want to vote in it, I need to hold coins first. It is impossible for me to get this currency through other means. I have to make transactions with those who already have the currency. I have the right after they give me the currency. This is not like PoW, as long as you connect a machine to the system, you can directly mine coins.

Second, the cost of voting itself is very low, and only a signature is required to generate a valid vote. In this case, there will be some problems in security. For example, the common harmless attack problem of PoS system.

In addition, voting rights can be reused and transferred, which is not good. If I sell my private key to others, then the votes I cast before, the choices made by each branch in history, and the person who gets my private key at this time can vote again. The ability to reuse previous voting rights poses some security concerns. We'll discuss that in more detail later when we get to long-range attacks.

There are also some problems caused by the voting mechanism. Just now we said that the advantage of the PoS consensus is that it can be confirmed quickly and can not fork, but the premise of this non-fork is that it is necessary to assume that most nodes are honest. It is mentioned here that more than 2/3 of the nodes are honest. In fact, strictly speaking, it is required that more than 2/3 of the coins and voting rights are in the hands of honest people, and bad people have less than 1/3 of voting rights. ——In this way, for a block that gets more than 2/3 of the votes, even if there are some bad people who can vote for different blocks, they will join the remaining good people who have not signed, and all of them will not exceed 2/3 . In this way, as long as there are enough node signatures and most nodes in the entire system are honest, the system will not fork at all, and it can be done very quickly, and everyone will confirm it quickly. For example, EOS now achieves fast block generation and fast confirmation.

But the PoS consensus also has some new problems.

The first one is that the communication complexity is related to the number of voters, and it is usually a quadratic relationship. The more people voting, the more complicated the communication, and the longer everyone has to wait. It's like if we want to elect the president of the United States with one person, one vote, the whole voting process is very complicated and very slow; while voting in the Politburo to decide a matter is much faster because there are fewer people.

There is also a more essential problem of PoS consensus, that is, the decision time of voting rights is earlier than the generation of candidate blocks. Before there is this block, I know who has voting rights and who has no voting rights. Because of the way voting rights are determined, the actual decision to vote and the act of exercising this right are separate and not bound together. When I got the right to vote, no one else could tell me who I had to vote for. So after getting the right to vote, I can vote at will, and it will not be determined whether I have the right to vote because of my voting behavior. But in this way, the use of voting rights is more flexible, and it also means that I can choose a larger strategy space, and the whole game will become more complicated. In general, a large policy space is bad for security because it leaves more room for an attacker to operate. An honest person usually only follows the rules, and he decides to take an action every time, but if the attacker has a large operating space, he can do a lot of things, and it will become more difficult to ensure security. The result is that there will be more attack methods in the PoS system, such as harmless attacks and long-range attacks.

So why in the PoS system, we can't generate blocks first and then decide the voting rights like in the PoW system? Because we need to ensure that everyone has a consensus on voting rights. No matter which candidate block a voter votes for, it must be known who is entitled to vote. Otherwise, it may degenerate into a situation similar to PoW-this is called stake grinding in the PoS system, which means that each time you try to generate many new blocks, and then select the most beneficial broadcast from these blocks Go out, and then this block will determine the voting rights in the future. If it is true that the block is produced first and the voting rights are determined later, we may see a fork split into several branches, and then each branch block is followed by a committee like a group of relatives and friends. Most of the members of the group of relatives and friends It is said that this block is correct. But because the groups of relatives and friends behind each block are different, no matter how they vote, they still cannot reach the consensus of the entire system.

There is also a problem with PoS consensus, that is, it needs to assume that most nodes are honest. "Honesty" is generally mentioned more in cryptography. But in game theory and economics, it is rare to say that a person is honest, and more that a person is rational-if lying can make more money, many people will choose to lie. So, if you assume that these nodes are honest, it is actually a very strong assumption. It means that even if they can make more money by lying and doing evil, they will still choose to abide by the agreement. This point also needs to look at the specific agreement and the extent to which honesty is required to know whether it is a reasonable assumption.

Let me talk about how to solve these new problems brought about by PoS consensus.

The first one is the problem of high communication complexity, which is actually the easiest to solve. You can randomly select a relatively small committee, and these people are responsible for voting as representatives, or you can use proxy voting, that is, I vote my vote first to elect a representative, such as the super node in EOS, and then these people are elected The representative of the party will vote instead of me. The advantage of this is that the number of people actually participating in the block consensus voting is relatively small, which can reduce the complexity of voting. In reality, people's congresses, foreign parliaments or juries all use similar logic.

Then how to counter the attack? One way is that we assume that most people are honest, and then assume that the network has very good synchronization—that is, after broadcasting a block, within a certain period of time, such as one minute or 30 seconds, the entire network Most nodes can receive it. Under this premise, it is very easy to achieve consensus. But such an assumption is actually very strong, and it is not easy to guarantee it in reality. If we want to solve the problem of a certain attack, directly assume that the attack does not exist, and then the problem is solved, this is definitely not a convincing method.

Let's discuss some more common attack methods against PoS systems.

The first is a disinterested attack, which is actually more than one vote. If in a PoW system, a miner sees two such forks, his computing power can only follow one to dig, and it is impossible to follow two at the same time. Of course, it is not impossible to dig two blocks at the same time, but that means that the computing power allocated to each block must be reduced. The sum of the mining power on both sides is a fixed value, so generally not Someone will do it. It is different in the PoS system: I see a fork on the left, well, I will vote for him; I see a fork on the right, and I will vote again. In this way, no matter which fork is called consensus, I can share the voting rewards. That way the bad guys are happy. The bad guy said that if I do a fork anyway, all of you rational miners will vote for me, so I can roll back the previous main chain as long as I have a little more voting rights than the remaining "not so rational good guys" Lose. This is very unsafe.

For harmless attacks, a common way of confrontation is to say that once such an act of multiple voting is detected, a penalty will be imposed on this person. If you really vote more than one vote, others can get the information of your vote, and then submit it to the chain, saying "this person voted more than one vote, deduct his money". But this method may actually encounter some problems, that is, it may happen that I vote more than one vote on both sides, but in the end only one side will be deducted, but I may get greater benefits on the other side.

There is also a bribery attack. When it comes to voting, most of the participants are actually closer to rational people. For example, if you hold 100 yuan, the income of each vote is 1 yuan, and then I tell you that as long as you vote for my block, I will give you 2 yuan. Probably many people will accept my proposal. In this way, the bad guys can buy more votes to support their branch at a very low cost, for example, buying voting rights equivalent to 100 yuan of assets with two yuan. This definitely has an impact on security. There are already some solutions to the problem of bribery. Although they are not perfect, they are quite convincing. For example, the solution proposed by Algorand is that the distribution of voting rights is calculated through private random numbers. Before the voters make the proof of voting rights public, no one knows who has the right to vote. In this way, at least no one will know that I have the right to vote before voting, and they will not be able to bribe me. After the public vote, because Algorand’s method is to change all the members of the committee every time a round of voting is completed, and then re-elect a group of people to vote, so when others know that I have the right to vote, my vote has already been cast. , There is no way to bribe to modify it. Here is a relatively high assumption about the honesty of the consensus participants: I can’t say that after I have the right to vote, I will go to the Internet to ask, which rounds of voting rights I have, and whether anyone will pay for it. In reality, if someone really asks about this on a large scale, it is actually easy to be discovered by the community, and everyone will know that someone is doing this kind of attack, and it will be easier to respond. So this is at least one way to reduce the risk of being attacked.

Another one is about the security of long-range attacks. What does this say? That is to say, if A has 20% of the coins or 20% of the equity in the creation block, he can vote on the normal block. However, A can sell all his coins on the chain at a certain time, that is, cash out and run away. Now he does not have any money on the chain, and it is impossible for others to punish him on the chain in the future. At this time, he sold his private key to the attacker. An attacker can acquire A's, B's, C's, and many private keys of many people. After acquiring those private keys, the control rights of these private keys in the genesis block may be more than 50%, or even more than 80%. Then the attacker gets these private keys and then makes a malicious block, replacing A, B, and C each with one vote to support the malicious block.

From the perspective of a third party, this block and the real main chain block look equally legitimate, because there are many people voting. If the bad guy’s chain is long enough, new people who join in the future will find that there are two chains, each of which is voted by many people, which one should I believe? At this time, the consensus has already become a problem. So how to deal with this attack? One method is to ensure a weak activity, that is, to require every honest miner to go up and check at least once in a while to synchronize the latest status. If someone tells you that your state is wrong and you should fork from a certain state a year ago, generally speaking, you should not accept such a suggestion, because the rollback time is too long.

Another way is to lock the deposit, and then add the length limit of the rollback. This is the setting in the Casper PoS protocol of Ethereum. If you have to sell your voting money, yes, but you have to wait a while. This time is long enough that other people will not admit it when they see you vote with your previous voting rights. Because other people have followed the legal chain a long way back. This is the solution of Ethereum.

Algorand’s solution to this point is, since you are honest, as an honest person, after each round of voting, you should delete the private key used for the current round of voting. No one will use this private key to do bad things again. This solution is correct, but it puts forward relatively high requirements on the moral level of the participants.

There are some other problems with PoS-based consensus systems. Usually if we choose a small committee, if we don't use DPoS, we need to choose randomly in the PoS system. The randomness in PoW voting is mainly brought about by everyone's luck in distributed parallel mining, because solving the PoW problem itself has inherent randomness. But if we want to use randomness to select a voting committee, we have to solve a new problem: how to generate a fair random number?

How to generate fair random numbers is also a problem that has been discussed for many years in cryptography, and there are relatively good solutions to solve it. Although this scheme cannot generate absolutely uniform and perfect random numbers, the deviation can be controlled within a range. On the other hand, it is very difficult to generate perfectly uniform random numbers. Because we know that if there are more than 2/3 coins, the attacker can completely control the entire chain, and the random numbers generated can also be chosen at will. So if you can control 100% random numbers with 67% of coins, it doesn't sound too unacceptable for 10% of coins to control 11% random numbers. In fact, Bitcoin based on PoW has similar properties: for example, 51% of the computing power can control 100% of the income on the chain; Obtain a higher income than the percentage of actual computing power. This is a non-linear relationship, but as long as it does not deviate too much, it is generally acceptable to everyone.

In addition, the system based on PoS consensus will have some problems when it starts. Because when a project is first started, its asset distribution is the least decentralized. Just like when Bitcoin first started, Satoshi Nakamoto would have many coins. If it is a PoS system, he alone can completely control the entire system. The development teams of other projects and several large investment institutions in the early stage may have already obtained most of the coins, and their right to speak on PoS will become very, very large. So how to start a PoS public chain is also a big problem. It took a long time before EOS was launched to do a better job. So for this point, our team believes that at least when the project starts, it is much more convenient to use PoW than PoS. Only the PoW method can be license-free, and then the initial currency will be relatively fair when it is issued.

04　PoW VS. PoS

Finally, although PoS can check some violations and then punish these people on the chain, it is possible that the attacker’s interests are not all on the chain, and he has other benefits off the chain. For example, I launched an attack on Ethereum, and I was punished to lose a lot of ETH; but at the same time, the price of the currency is likely to decrease. If I short ETH in another market, I can get higher returns by shorting. In this case, the motivation outside the chain will cause some people who have a lot of money on the chain to still have the motivation to attack the chain. This is also a difficult problem for PoS to solve.

secondary title

We finally take a brief look at the comparison of consensus based on PoW and PoS mechanisms.

One is the access mechanism. I.e. is it licensed or not? Is voting anonymous? Is there a limit to the number of participants? Will voting be done in parallel or by broadcast? There is another way to confirm the voting results? Marginal cost of voting?

One is security. I think the two biggest differences are voting rights first, or candidate blocks first? Are voting behaviors and voting rights bound? From these perspectives, PoW does a better job in terms of security.

However, the PoW voting result needs to wait for the accumulated advantages on a branch to be large enough to be confirmed, so in fact, instead of waiting for a block, he has to wait for the honest computing power to concentrate on this block for a period of time before confirming. Therefore, the PoW system can only say that the confirmation speed is as fast as possible through some optimizations, but it is difficult to achieve second-level confirmation like some PoS.

When it comes to the marginal cost of voting, there is no way to avoid PoW because of the need for machines and electricity costs. But other aspects are doing better. In contrast, PoS is better in terms of performance, but mainly in terms of security. It is because it determines the voting rights first, so everyone can vote at will with this voting right. And after you have voted once, you can vote again with this right. As for some other problems of PoS, in fact, we can alleviate or solve those problems by using the committee or proxy proof of rights and interests, but the problem of only voting rights is difficult to solve. The problem that voting rights and voting behavior are not bound is an essential problem of PoS.

The disadvantage of PoW is that the confirmation is slow, and the throughput is generally relatively low. The main disadvantage of PoS is how to deal with various attack methods such as bribery attacks, long-range attacks, and harmless attacks. In order to deal with these attacks, the PoS protocol has to deal with many situations, so it will become more complicated. As we all know, the more complex the system is, the more difficult it is to guarantee the security. On the one hand, it is more difficult to analyze and prove, and on the other hand, it is easier for attackers to find loopholes in complex systems.

Another way that may not be used very much now is to mix PoW and PoS together for consensus. Because the main advantage of PoW is safety and reliability, and the advantage of PoS is high efficiency, especially fast confirmation, and relatively low energy consumption. If the advantages of these two can be combined, it is possible to design a more ideal consensus protocol. At the same time, you can also consider organizing blocks in a DAG way instead of a chain way. Because the DAG method is not afraid of forks, it does not need to limit the speed of block generation too much, so everyone can generate blocks faster, as long as the bandwidth can be synchronized.

When the throughput reaches the upper limit of bandwidth and network capacity, if you want to further expand the capacity, you need to use your brains from other aspects. A relatively simple idea is to adopt a second-layer expansion solution: each transaction should not be transmitted to the entire network for verification. For example, like sharding, a transaction is only locally verified inside the shard. This can save the bandwidth of the entire network and improve overall system throughput. The Lightning Network also uses similar logic. Another more difficult way requires the use of some "black technology", such as verifiable calculations, short zero-knowledge proofs, probabilistic verifiable proofs, etc., which will not be discussed here.