Proof of Stake FAQ

The Traditional Chinese translation of the ethereum wiki is not very readable — I might as well read the original English and translate it myself. Original article: Proof of Stake FAQ What is Proof of Stake? Proof of Stake (PoS) is a consensus algorithm for public blockchains that depends on the economic interest of validators in the network. In Proof of Work (PoW)-based public blockchains (e.g., the current implementations of Bitcoin and Ethereum), the algorithm rewards participants who solve cryptographic puzzles to validate transactions and create new blocks (i.e., mining). In PoS-based public blockchains (e.g., Ethereum's upcoming Casper implementation), a set of validators take turns proposing and voting on the next block, and the weight of each validator's vote depends on the size of its deposit (i.e., stake). PoS has significant advantages in security, reduced centralization risks, and energy efficiency. Typically, a PoS algorithm works as follows. The blockchain keeps track of a set of validators, and anyone who holds the blockchain's base cryptocurrency (in Ethereum's case, ETH) can become a validator by sending a special type of transaction that locks up their Ether in a deposit. The process of creating and agreeing on new blocks is then done through a consensus algorithm in which all current validators can participate. There are many kinds of consensus algorithms, and many ways to assign rewards to validators who participate, so there are many "flavors" of PoS. From an algorithmic perspective, there are two main types: chain-based proof of stake and BFT-style (Byzantine Fault Tolerant) proof of stake. In chain-based proof of stake, the algorithm pseudo-randomly selects a validator during each time slot (e.g., every 10-second period), and assigns that validator the right to create a single block, and this block must point to some previous block (normally the block at the end of the previously longest chain), and so over time most blocks converge into a single constantly growing chain. In BFT-style proof of stake, validators are randomly assigned the right to propose blocks, but agreement on which block is canonical is made through a multi-round process where every validator sends a "vote" for some specific block during each round, and at the end of the process all (honest and online) validators permanently agree on whether any given block is part of the chain. Note that blocks may still be chained together; the key difference is that consensus on a block can come within one block, and does not depend on the length or size of the chain after it (my interpretation is that consensus is decided by the block itself rather than how many blocks follow it). Advantages of PoS See A Proof of Stake Design Philosophy for a more complete discussion. In summary: - There is no need to consume large amounts of electricity to maintain blockchain security. It is estimated that Bitcoin and Ethereum together spend over $1 million per day on electricity and hardware costs for their consensus mechanisms. - Because of the lower energy requirement, there is no need to issue as many new coins to incentivize participants, reducing pressure on the network. In theory, it is even possible to have negative net issuance, where a portion of transaction fees is "burned," causing the supply to decrease over time. - Proof of Stake opens the door to a wider use of game-theoretic mechanism design techniques in order to better discourage the formation of centralized cartels, and to (if they do form) act in ways that are harmful to the network (such as selfish mining in proof of work). - Reduced centralization risk means that economies of scale are less of an issue. In proof of work, once capital gets large enough, you can invest in larger-scale production equipment and widen the gap with others (investing ten million yields more than ten times the return of investing one million). In proof of stake, one million invested guarantees exactly ten times the returns of one hundred thousand invested. - The ability to use economic penalties to greatly increase the cost of 51% attacks in various forms compared to proof of work — as Vlad Zamfir put it, "participating in a 51% attack would get your ASIC farm burned down." How does Proof of Stake relate to traditional Byzantine Fault Tolerance research? Byzantine Fault Tolerance research has several fundamental results that apply to all consensus algorithms, including traditional consensus algorithms (e.g., PBFT), any Proof of Stake algorithm, and, with the right mathematical modeling, Proof of Work. Key results include: - CAP theorem — In the event of a network partition, you can only have one of consistency and availability, not both. The intuitive argument is simple: if the network splits into two halves, and in one half you send a transaction "send $10 to A" while in the other half you send "send $10 to B," the system becomes unavailable. Either one or both transactions fail to be processed, or the network becomes inconsistent (one half recognizes the first, the other the second). Note that the CAP theorem has nothing to do with scalability; it applies equally to sharded and non-sharded systems. - FLP impossibility — In an asynchronous setting (i.e., there are no upper bounds on network latency even between two honest nodes), no algorithm can guarantee reaching consensus within any specific finite amount of time, even if there is only a single faulty/dishonest node. Note that "Las Vegas" algorithms can achieve consensus within T seconds with a certain probability in each round, exponentially approaching 1 as T grows. This is used in practice by many successful consensus algorithms. - Fault tolerance upper bounds — From the DLS paper: 1) Protocols running in a partially synchronous network model (e.g., there is an upper bound on network latency, but we don't know it in advance) can tolerate up to 1/3 Byzantine (faulty/malicious) faults. 2) Deterministic protocols running in an asynchronous model (i.e., no bounds on network latency) cannot tolerate any faults (though the paper does not mention that randomized algorithms can push fault tolerance up to 1/3). 3) Protocols in a synchronous model (i.e., network latency is guaranteed to be below some known bound d) can surprisingly achieve 100% fault tolerance, though with some restrictions when more than 1/2 of the nodes are faulty. Note that we are concerned with the "authenticated Byzantine" model, not the plain "Byzantine" model. "Authenticated" means that we use public key cryptography in our algorithms, which is well-studied and extremely cheap today. Proof of work has been rigorously analyzed by Andrew Miller et al. and fits as a consensus algorithm in a synchronous network model. We can model the network as consisting of a near-infinite number of nodes, each representing a very small unit of computational power, with a very low probability of being able to create a block in a given time period. In this model, assuming zero network latency, the protocol has 50% fault tolerance (in practice, about 46% for Ethereum and 49.5% for Bitcoin), dropping to 33% if network latency equals block time, and approaching zero as network latency approaches infinity. Proof of Stake consensus is more directly applicable to the Byzantine fault tolerance consensus model, since validators are all known by identity (stable Ethereum addresses) and the network tracks the total number of validators. PoS research is generally split into two threads: one studying synchronous network models, and another studying partially synchronous network models. "Chain-based" PoS almost always relies on synchronous network models, and its security can be formally proven in a way similar to proof of work. The other thread links traditional Byzantine fault tolerant consensus algorithms in partially synchronous networks with existing PoS mechanisms, but is more complex to explain; we will go into more detail in later sections. Proof of work and chain-based PoS choose availability over consistency, while BFT-style consensus algorithms tend toward consistency. Tendermint explicitly chooses consistency, while Casper uses a hybrid model that favors availability while providing as much consistency as possible, and ensures that chain applications and clients always know the current degree of consistency at any time. Note that Ittay Eyal and Emin Gun Sirer's selfish mining research shows that, depending on the network model, the incentive-compatibility of Bitcoin mining breaks down at thresholds of 25% and 33% (i.e., the mining mechanism is incentive-compatible only if the assumption that no 25% or 33% coalition exists is true). This conclusion is separate from the conclusions of traditional consensus algorithms, which do not involve incentive compatibility. What is the "nothing at stake" problem, and how can it be addressed? In many early (all chain-based) PoS algorithms, including Peercoin, there are only rewards for producing blocks and no penalties. This leads to bad consequences: in the event of multiple competing chains (forks), validators will produce blocks on every chain, like this: In proof of work, doing this dilutes the miner's hash power, reducing profits: This creates a situation where: if all participants are narrowly economically rational, the blockchain cannot reach consensus even without an attacker. If there is an attacker, the attacker only needs to overwhelm the altruistic nodes (those voting only for the original chain), not the rational nodes (voting for both the original and attacker's chains). In proof of work, the attacker must overwhelm (or at least threaten, see P + epsilon attacks) both altruistic and rational nodes. Some argue that stakeholders have correct incentives to only bet on the longest chain in order to preserve the value of their investment. However, this ignores that this incentive is subject to the tragedy of the commons: each stakeholder may have only a 1% chance of being the "pivotal" factor (i.e., their participation determines the outcome of an attack), so the bribe needed to buy them is only 1% of their total investment. Thus, the total bribe would be 0.5-1% of all stake. Moreover, this argument implies that any situation with zero failures is not a stable equilibrium, since if the chance of failure is zero, everyone has a 0% chance of being pivotal. There are two ways to solve this. The first is "Slasher", further developed by Iddo Bentov. When a validator creates blocks on multiple chains simultaneously, evidence of misbehavior (e.g., two conflicting signed block headers) is recorded on the blockchain and later the misbehaving validator's funds are appropriately slashed. The change looks like this: Note that for this algorithm to work, the validator set must be known in advance. Otherwise, one would bet on chain A when A is available, on chain B when B is available, and on the longest chain when both are available. The only way to prevent this is to select validators in advance, before the fork. This scheme has weaknesses: nodes need to come online frequently to get a security-trusted blockchain state, and it makes medium-range validator collusion attacks possible (e.g., 25 out of 30 consecutive validators conspiring to execute a 51% attack on the previous 19 blocks). If these risks are considered acceptable, the scheme works well. The second strategy is to simply penalize validators who create blocks on wrong chains. That is, if there are two competing chains A and B, and a validator creates a block on B earning +R on B, but the block header can be included in A (called a "dunkle" in Casper), the validator will be penalized -F on A (possibly F = R). The calculation changes to: Intuitively, we can reuse the PoW reasoning for PoS. In PoW, creating blocks on the wrong chain is also penalized, but the penalty is implicit in external circumstances: the miner has to spend extra electricity and acquire or rent extra hardware. PoS makes the penalty explicit. The downside of this approach is slightly increased risk for validators (though the risk smooths out over time), but the advantage is that it does not require validators to be known in advance. The above explains how chain-based PoS addresses the "nothing at stake" problem. So how does BFT-style PoS work? BFT-style (partially synchronous) PoS allows validators to "vote" on blocks by sending one or more types of signed messages, with two rules defined: - Finality condition: Determines when a hash is confirmed. - Slashing condition: Determines when there is sufficient reason to suspect a validator is cheating (e.g., voting on multiple conflicting blocks simultaneously). If any validator violates any condition, their stake is slashed. To illustrate the different forms that slashing conditions can take, we will give two examples (throughout, "2/3 of all validators" means "2/3 of the total stake of all validators"). In these examples, "PREPARE" and "COMMIT" should be understood as simply referring to two types of messages that validators can send. 1. If contains messages of the form and where is the same but and differ, signed by the same validator, that validator is penalized. (Cannot simultaneously sign conflicting blocks.) 2. If contains a message of the form , then unless view1 = -1 or there are also messages of the form (where ) signed by at least 2/3 of validators, the validator who signed the COMMIT is penalized. (A HASH can only be COMMITted after at least 2/3 PREPARE.) Two important requirements for appropriate slashing conditions: - Accountable safety: If there exist conflicting and (i.e., and differ and neither is a descendant of the other) that have both been confirmed, then at least 1/3 of validators must have violated some slashing condition. - Plausible liveness: Unless at least 1/3 of validators have violated some slashing condition, there exist some messages that could allow 2/3 of validators to confirm something. If we have a set of slashing conditions satisfying these two properties, we can incentivize participants to send messages and begin benefiting from economic finality. What is "economic finality" in general? Economic finality is the idea that once a block is confirmed, or more generally, once enough messages of a certain type have been signed, then for a conflicting block to be included in the chain at any future point in time, a large number of people would have to be willing to burn large amounts of money. If a node sees that a block has met the finality condition, they have a very strong economic guarantee that this block will always be part of the canonical chain. There are two ways to achieve economic finality: 1. A block can be economically finalized if a sufficient number of validators sign a message of the form "I will lose X Ether if block B is not included in the canonical chain." This gives clients the guarantee that either (1) B is part of the chain, or (2) validators who misled the client lost a large amount of money. 2. If enough validators economically finalize block B, and if there is a way to prove that a different block B' was also included under the same conditions, costing validators large amounts of money, then the block is considered economically finalized. If a client validates the chain based on the current situation, and since validity plus finality is a sufficient condition for priority in fork choice rules, the client can be guaranteed that either (1) B is part of the chain, or (2) validators who misled the client lost a large amount of money. These two approaches inherit from the two solutions to the "nothing at stake problem," implementing finality by penalizing errors (e.g., COMMITting to invalid blocks) and penalizing ambiguity (e.g., COMMITting to two conflicting blocks). The main advantage of the first approach is that it is lighter weight and easier to reason about; the main advantages of the second approach are (1) it is easier to see that honest validators are not penalized, and (2) interference factors favor honest validators relative to dishonest validators — the cost of an honest validator interfering with a dishonest one is higher than the cost of a dishonest validator interfering with an honest one. Casper adopts the second approach. Additionally, on-chain mechanisms can be added whereby validators can voluntarily choose to sign finality messages of the first type, increasing client efficiency. So what is the relationship with Byzantine Fault Tolerance theory? Traditional Byzantine Fault Tolerance theory has similar requirements for safety and liveness. First, traditional BFT only requires 2/3 of validators to be honest to achieve safety. This is a very easy-to-achieve model. Traditional fault tolerance tries to prove "if mechanism M has a safety failure, then at least 1/3 of nodes have failed," while our model tries to prove "if mechanism M has a safety failure, then at least 1/3 of nodes have failed, and even if you were offline when the failure occurred, you can still know which ones failed." From the liveness perspective, our model is easier because we do not need to prove that the network can reach consensus; we only need to prove that it cannot be permanently blocked. Fortunately, we can prove that the additional accountability requirement is not very hard to achieve. In fact, with the right defense mechanisms, we can convert any traditional partially synchronous or asynchronous Byzantine fault tolerant algorithm into a trustworthy one. The proof essentially boils down to the fact that faults can be exhaustively categorized into a few classes, and each class is either accountable (e.g., if you commit this type of fault, you may be discovered, so we can make a slashing condition for it) or indistinguishable from network latency (note that the error of sending a message too early is indistinguishable from a delay, since people can simulate it by adjusting clocks). What is "weak subjectivity"? It is worth noting that using stakes to ensure "nothing is costless" does lead to a change in the security model. Suppose assets are locked for four months and can be withdrawn afterward. Suppose a 51% attack occurs, resetting 10 days of transactions. The attacker's blocks can be imported into the main chain as evidence of misconduct ("dunkles"), and the corresponding validators are penalized. However, suppose this attack occurs six months later. In that case, even if these blocks could be re-included in the chain, the offending validators would by then be able to withdraw their funds on the main chain and escape punishment. To solve this, we introduce a "revert limit" rule — that is, nodes refuse to accept reverts older than the assets' withdrawal period (four months). Note that this rule differs from all other protocol rules in that nodes who see certain messages at different times will reach different consensus results. The time at which a node sees a particular message may differ between nodes; we therefore consider this rule to be "subjective" (or, for those familiar with Byzantine fault tolerance theory, a synchrony assumption). However, the "subjectivity" here is very weak: for a node to be on the "wrong" chain, it must receive the original message more than 4 months after it was sent. This is only possible in two scenarios: 1. When a node first connects to the blockchain. 2. If a node has been offline for more than four months. For the first case, users can verify through out-of-chain methods — for example, asking friends, block explorers, or trading partners for the hash of a recent block on the canonical chain and treating it as authoritative. In practice, such block hashes would likely simply be part of the software they use to verify the blockchain; however, an attacker who can corrupt software checkpoints could theoretically easily corrupt the software itself, and no purely economic verification can solve this problem. Note that all of this is only an issue in a very limited case: most previous stakeholders colluding to attack the network and create an alternative chain. Most of the time, there will be only one legitimate chain to choose from. Also note that if there are no hard forks in the chain, there is also a weak subjectivity assumption in proof of work. Bitcoin had a hard fork two months early via bitcoind 0.8.1, fixing a database issue where certain large blocks were invalid, allowing clients to handle blocks that bitcoind 0.7 could not process; users had to download the new version within a 2-month window. This itself is a weak subjectivity assumption, since users had to "log in" within two months to download the update and stay on the correct chain. Moreover, if desired, social verification can even be automated in various ways. For example, (1) BIP 70 requires payment requests to include the hash of a recent block, so the user's client software ensures they are on the same chain as the merchant before approving payment (this can also be done through other on-chain interactions). Another approach is using Jeff Coleman's universal hash time. With this scheme, for an attacker's chain to succeed, it would need to be generated secretly at the same time as the legitimate chain, requiring a majority of validators to collude during this period. Does weak subjectivity mean a PoS-based chain must be "anchored" to a proof-of-work chain for security? The short answer is no. Elaboration In practice, weak subjectivity is a fairly small addition to the security assumptions of a blockchain. To understand why, consider the scenario in which weak subjectivity would harm blockchain security. In the current world, if the majority of the community has seen and stored block hash A for block XXXYYY, a powerful corporation or state entity would have the ability to convince the entire community that the hash is B, but for some reason the powerful force cannot induce users to download client software from a different source. Moreover, the "anchoring" advocated by this scheme is not that secure anyway. All anchoring shows is that a block hash was generated at time T' < T, which doesn't prove it was published at that time. So a PoS chain linked to a PoW chain could be subject to this attack: many nodes collude, simultaneously generate two parallel chains, anchor both, publish one, then publish the other four months later. This problem can be resolved by embedding a full-featured "light client" of the PoS chain in the PoW chain, which would prevent double anchoring — but this requires the PoW chain to have rich enough functionality to implement such a client, which most proof-of-work chains currently do not have. Can censorship be economically penalized in Proof of Stake? Censorship is harder to distinguish than reversion. The blockchain itself cannot directly distinguish between "user A tried to send transaction X but it was unfairly censored," "user A tried to send transaction X but it could not be included because of insufficient transaction fees," and "user A never tried to send transaction X." Fortunately, there are many techniques that can be used to mitigate censorship. First is censorship resistance through obstruction. In the weaker version of this scheme, the protocol is designed to be Turing complete such that validators cannot even know whether a transaction will behave unexpectedly after expensive computation, exposing them to denial-of-service attacks. This is what prevented the DAO soft fork. In the stronger version of this scheme, transactions can trigger guaranteed effects at some point in the near or medium future. A user can send multiple interconnected transactions and use predictable third-party information to cause some future event. Validators wishing to censor would need to wait until the transaction is written into a block (and economically confirmed) before knowing what event occurred, but by then it is too late to block the transaction. Even if all future related transactions are filtered out, the event the validator wanted to prevent will still occur. Note that in this scheme, validators can still attempt to block all transactions, or only allow transactions with formal proofs that they won't cause any undesired consequences — but this would mean excluding a very broad range of transactions, effectively breaking the entire system, since this would cause validators to lose value as their assets as a cryptocurrency would shrink. Second, as described by Adam Back, require transactions to be timelock-encrypted. Thus, validators will include transactions without knowing their contents, and the contents will be automatically revealed later, by which time the transaction can no longer be excluded. However, if validators are sufficiently malicious, they might simply agree to only include transactions with cryptographic proofs (e.g., zero-knowledge proofs like zkSNARKs). This could force users to download relevant software, but validators can provide the software download directly. Users have an incentive to cooperate in such a game. Perhaps the most viable solution in PoS is that users can install software updates containing a hard fork that removes the malicious validators. This is no more difficult than installing a software update to implement "more friendly censorship." So all of these are moderately effective, although it does come at the cost of slowing down blockchain interaction speed (note that this scheme must be mandatory to be effective; otherwise malicious validators can more easily simply filter encrypted transactions without filtering faster unencrypted transactions). A third approach is to incorporate censorship detection into the fork choice rule when forks occur. The idea is simple. Nodes monitor the network for transactions, and if they see a transaction with a sufficiently high fee for a long enough time, they assign a lower "score" to blockchains that do not include that transaction. If all nodes follow this strategy, then eventually the weaker chain will also gain a transaction included, causing all other honest nodes to switch to that chain. The main drawback of this scheme is that offline nodes still record the stronger chain, and if the censorship is temporary and the node comes back online after censorship ends, they will diverge from the online nodes. Therefore, this scheme should be treated as a coordination tool in emergencies like hard forks rather than used in everyday fork choice. How are validators selected? What is stake grinding? In any chain-based PoS, some mechanism is needed to randomly select which of the current validators gets to create the next block. For example, if the current validator set is Alice (40 ETH), Bob (30 ETH), Charlie (20 ETH), and David (10 ETH), we want the next block creator to be Alice with 40% probability, Bob with 30% probability, and so on (in practice, we want an infinite sequence of candidates selected so that later ones can fill in for earlier ones who are absent, but this doesn't change the basic idea). In non-chain-based algorithms, we often also need randomness. Stake grinding is a class of attack where a validator performs some computation or takes other steps to try to influence the randomness in their favor. For example: 1. In Peercoin, a validator could search through various combinations of parameters to find specific parameters that increase the number of valid blocks they can produce. 2. In a method that is no longer used, the randomness for block N+1 depends on the signature in block N. This allows a validator to repeatedly generate new signatures until they find one that allows them to predict and control the next block, thereby controlling the system. 3. In NXT, the randomness for block N+1 depends on the validator who produced block N. This allows a validator to influence randomness by skipping a block creation opportunity. Although the opportunity cost of doing so is losing one block reward, sometimes the new random seed can give the validator above-average block rewards over the next few dozen blocks. See here for details. (1) and (2) are relatively easy to solve: the general approach is to require validators to first deposit funds to prevent them from constantly changing addresses to find values that influence randomness, and to avoid using easily manipulated information such as signatures in blocks. (3) has several main strategies. The first is to use secret sharing or deterministic threshold signatures, allowing validators to jointly produce a random value. Unless a majority of validators collude, this is useful for all operations (in some cases, depending on the implementation, 33-50% of validators can interfere with the protocol, reducing the probability that it maintains liveness to 67%). The second approach uses cryptography: validators commit to some information in advance (e.g., publish ), then must reveal in a block. is added to the random pool. There are theoretically two potential attacks: 1. Manipulating x at commit time. This is impractical, because the randomness result is based on values from multiple participants, and as long as one is honest, the output will be uniformly distributed. XOR of a uniform distribution with any number of arbitrarily biased distributions remains a uniform distribution. 2. Selectively publishing blocks. However, this attack costs one block reward in opportunity cost, and since the scheme ensures people cannot look at anyone other than the next validator, it can barely provide returns beyond one block reward. The only exception is if, when validation is skipped, the backup validator and the next block's validator happen to be the same. If this becomes a serious problem, explicit penalties can be applied for skipping validation. The third approach uses the "majority beacon" proposed by Iddo Bentov, generating a new random number based on the majority value of each bit among N previously generated random numbers (also generated using beacons) (i.e., if the majority of numbers have a first bit of 1, the result's first bit is 1, otherwise 0, and so on). The cost of an attack is , where is the cost of attacking other beacon-generated random numbers. In summary, there are many known solutions to stake grinding. This problem is more like differential cryptanalysis than the halting problem — it is a problem that PoS designers can understand and know how to overcome, not a fundamental unavoidable flaw. What does a 51% attack against Casper look like? The most basic "51%" attack is finality reversion: validators finalize block A, then produce some competing block A', breaking the immutability of the blockchain. In this case, there are two incompatible finalized histories, leading to a blockchain fork. This requires out-of-chain coordination through the community to decide which chain to follow. There are many ways to coordinate, such as through social media, private channels between blockchain explorer providers and exchanges, various online forums, etc. The ultimate principle is "first finalized wins." Another option relies on "market consensus": for a short time, both forks can be traded on exchanges until one wins out due to higher value. In this case, "first finalized wins" will become the Schelling point for market selection. In practice, both methods may be combined. Once the chain reaches consensus, users (validators, light nodes, and full nodes) can manually insert the winning block hash into their clients through a special option in the software interface, then ignore all other chains. Regardless of which chain wins, there is evidence to immediately use to burn at least 1/3 of validators' funds. Another attack is blocking liveness: a group controlling >= 34% of validators can refuse to confirm other blocks. In this case, blocks can never be finalized. Casper uses a hybrid (chain + BFT) consensus mechanism, so the chain will still grow, but security is greatly reduced. If no block is confirmed for a period of time (e.g., one day), there are a few options: 1. The protocol has an automated feature that rotates the validator list. Blocks will be confirmed by new validators, but users will be warned that these recently confirmed blocks are not yet trustworthy, since previous validators might resume operation and confirm different blocks. Once the previous validators are no longer online, users can manually dismiss these warnings. In this case, validators who previously did not participate in consensus confirmation will suffer large penalties. 2. Use a hard fork to add new validators and remove the funds of the validators who launched the attack. In the second case, the fork still needs to be coordinated through community and market consensus (for example, two chains with different validators briefly coexisting on exchanges). Under market consensus coordination, there is a strong argument that the market will choose the "good guys win" fork, since this chain demonstrates goodwill (at least it aligns with users' interests), making it more useful for application developers. Note that automated protocol and social coordination are not mutually exclusive; it is generally considered desirable to use automated solutions as much as possible to minimize the risk of a 51% attack and social-level (or market consensus tools, such as exchanges) attacks occurring simultaneously. One can imagine a (1) implementation where nodes re-select a batch of validators if no new blocks are submitted within a certain time. This would reduce the need for social coordination, but at the cost of requiring nodes that don't want to rely on social coordination to stay online at all times. In any case, a solution can be designed that severely penalizes attackers financially. Censorship attacks are a more subtle attack form, where >= 34% of validators refuse to confirm blocks containing certain transactions, while everything else runs normally. There are multiple variants — mild ones like selectively targeting specific applications (e.g., filtering Raiden or Lightning Network transactions is a relatively simple way to steal money), severe ones like blocking all transactions. There are two scenarios. In the first, the attacker controls 34-67% of stake. In this case, we can program validators to refuse to confirm or build on blocks that are obviously under censorship attack, turning this into a standard liveness attack. If the attacker controls more than 67% of stake, the situation is more dangerous. In this case, the attacker can freely block any transaction they want to block and refuse to build on any block containing such transactions. There are two defensive measures. First, Ethereum is Turing complete, and there are natural mechanisms to resist censorship, since the process of censoring certain special transactions is similar to the halting problem. Due to gas limits, censorship is not impossible, but "simple" censorship attempts actually result in denial-of-service attacks. This preventative mechanism is not perfect and needs improvement. The most interesting improvement is adding a protocol-level feature allowing transactions to automatically schedule future events, since predicting the outcome of events and the subsequent chain of events in advance is very difficult. This allows validators to hide Ether movements through event obfuscation, reducing the attack threshold below 33%. Second, one can introduce the concept of an "active fork choice rule," meaning that when a fork occurs, one consideration for choosing a chain is interacting with the chain to verify it is not filtering your transactions. The most effective way to do this is for nodes to repeatedly send transactions to store Ether, then cancel at the last moment. If a node detects censorship, it does not cancel the transaction and temporarily joins as a validator, diluting attackers below 33%. If the dominant node group filters their transactions, the nodes using the "active fork choice rule" will not choose that chain. The censorship attack then becomes a liveness attack, which can be handled by solving liveness attacks. It sounds like there would be heavy reliance on out-of-chain social coordination — isn't that dangerous? The cost of attacks against Casper will be very high; as we will see, the cost of attacking Casper is roughly comparable to, or even more than, the cost of buying enough mining hardware to continuously 51% attack in a proof of work system. Therefore, the recovery techniques described above would only be used in very extreme circumstances; in fact, PoW advocates have generally expressed willingness to use social coordination in similar situations, for example by changing the proof of work algorithm. In fact, the amount of social coordination required by PoW may even be greater than that required by PoS. In practice, we expect the amount of social coordination needed to be close to zero, since attackers would realize there is no benefit in spending such enormous amounts of money to take the blockchain offline for a day or two. Does MC =MR imply that all consensus algorithms with a given security level are equally (in)efficient? Many hold this view; Paul Sztorc's article perhaps explains it most clearly. The essence is that if you create an opportunity with a $100 reward, people will be willing to spend $99.9 (including labor costs) to get the reward; marginal cost approaches marginal revenue. Therefore, the theory argues that any algorithm with a given block reward is equally "wasteful" in terms of the amount of socially unproductive activity spent trying to obtain the reward. This theory has three flaws: 1. It is not sufficient to say that marginal cost approaches marginal revenue; there must be a plausible mechanism that allows people to spend money to acquire a chance at the reward. For example, if I announce tomorrow that I will randomly select one person from a list of ten to give $100, no one can use $99 to try to manipulate that randomness. Either they are not on the list (in which case nothing they do gives them a chance), or they are on the list, but in that case there is no reasonable way for them to manipulate my randomness, so they simply stick with their expected value of $10 per day. 2. MC =MR does not imply that total cost approaches total revenue. For example, suppose there is an algorithm that pseudo-randomly selects 1000 validators from a very large set (each getting a $1 reward; if one holds 10%, they would receive $100), and it costs $1 to (unlimitedly) reset the random value. Based on the central limit theorem, the standard deviation of rewards is $10, and according to known mathematical results, the expected maximum of N random samples is approximately , where is the mean and S is the standard deviation. So the extra return from retries rapidly diminishes with each additional try (up to N): for example, with no retries, the expected profit is $100; with one retry, $105.5; two, $108.5; three, $110.3; four, $111.6; five, $112.6; six, $113.5. So after five retries it's no longer worth trying again. Thus an economically motivated attacker with 10% of capital would inefficiently spend $5 to gain $13 in extra revenue. If the chance of exploiting a mechanism is small, the economic loss is also small; but this doesn't apply to proof of work, where a single vulnerability can have serious consequences. This point is also closely related to our discussion of capital lockup costs below. 3. The security cost of proof of stake is far less than that of proof of work. What are capital lockup costs? Locking up X amount of Ether has a cost — for example, foregoing the opportunity to do other things with it. Suppose I have 1000 ETH, I could use it for anything; but if locked up as stake, it will sit there for several months. For example, I have no funds to pay for unexpected emergencies. Also, I cannot convert ETH to other tokens freely; I could short an equivalent amount at an exchange to effectively sell ETH, but this itself has costs including transaction fees and interest payments. Some might object: isn't the economic inconvenience of capital lockup the same as the economic inefficiency in proof of work? The answer is no, for reasons (2) and (3). First, (3). Suppose a model where PoS funds are locked indefinitely, ASICs run permanently, ASIC technology is fixed (ignoring Moore's law), and electricity costs are 0. Also assume a stable interest rate of 5% per year. In a PoW chain, spending $1000 on mining hardware yields $50 per year. In a PoS chain, permanently locking $1000 yields $50 per year in rewards. So far, both are equivalent (though technically, in PoS, the "burning" of our funds is not socially destructive since it makes everyone else's coins more valuable — we'll ignore this for now). In both hypothetical scenarios, launching a "Maginot-line" 51% attack requires spending an additional $1000 (e.g., buying more hardware). Now let's modify the model step by step: 1. Moore's law exists and ASICs depreciate 50% every 2.772 years (simplified to 25% per year continuously). To maintain "invest once, produce forever," suppose: put $1000 into a fund, of which $167 goes into ASICs, and the remaining $833 into investments yielding 5% per year. The $41.67 per year generated is just enough to spend on replacing ASICs (assuming continuous technological progress for simplicity). Returns drop to $8.33 per year; thus, hash power decreases by 83.3% until it can recover to earning $50 per year. The cost of a Maginot-line 51% attack is now 6 times lower. 2. Electricity plus maintenance costs constitute 1/3 of total costs. The 1/3 figure comes from recent mining data: Bitfury's latest data center consumes 0.06 joules per gigahash, 60 J/TH, or 0.0000167 kWh/TH. Assuming the entire Bitcoin network has similar efficiency, reaching Bitcoin's hash rate of 1.67 million TH/s requires about 27.9 kWh per second. At China's electricity price of $0.11 per kWh, that's $3 per second, or $260,000 per day. Bitcoin's block reward plus fees is 600 13 144 (600 is fees, 13 is an approximation of 12.5 block reward, 144 blocks per day) approximately $1.12 million per day. So electricity costs are about 23%, and estimating hardware maintenance at 10%, we get roughly "1/3 ongoing costs, 2/3 fixed costs." This means of $1000, only $111 goes into ASICs, $55 for ongoing costs, $833 for investment, reducing the cost of a 51% attack by 9 times. 3. Deposits are temporary rather than permanent. Of course, one could deposit indefinitely. This restores some optionality; we can exit after a period (say, 4 months). This means I can put in more than $1000 of Ether, perhaps even $3000. Therefore, the cost of a PoS 51% attack is 3x higher, while being 27x more secure than PoW at the same cost. The above includes many model simplifications, primarily to show that, after many factors are considered, PoS consistently shows better security. This seemingly suspicious multi-factor argument strongly supporting PoS is simple: in PoW, we directly face physical laws. In PoS, we can design the protocol in specific ways to have certain properties — in short, we can optimize the physical laws in our favor. The change in security model, particularly weak subjectivity, leads to (3) above. Next, we can talk about the difference between marginal and total costs. This is very important in the case of capital lockup costs. Consider this: you have $100,000 in Ether and intend to hold it long-term; therefore, locking $50,000 should have little impact. Locking $80,000 would have some impact, but $20,000 is still enough to remain flexible. $90,000 would be problematic, and $99,000 even more so. Locking everything would be terrible since you'd not even have funds for transaction fees. So marginal costs increase rapidly. The chart below shows the difference between PoS and PoW: As you can see, the total cost of PoS is far less than the marginal cost of depositing more than 1 ETH multiplied by the total existing deposits. Note: The arguments in this section do not fully explain reducing the "safe level of issuance" of tokens. But they do show that even with a very low token issuance rate, PoS can still operate; however, this also means that a large portion of returns would go to validators. Will exchanges cause centralization risk in PoS (similar to mining pools in PoW)? From a centralization perspective, Bitcoin and Ethereum need about three mining pools (or exchanges) to coordinate a 51% attack (4 for Bitcoin, 3 for Ethereum). In PoS, if exchanges have 30% participation, three exchanges would be enough to launch a 51% attack. If participation reaches 40%, the number required increases to 8. However, exchanges cannot invest all their capital in an attack since they need to handle user withdrawals. Additionally, in PoS, the motivation to form pools is lower because of higher trust costs — pools could pretend to be hacked, destroy users' funds, and profit from it. On the other hand, even though trust is required, earning profits through personal tokens without running a full node is also attractive. In any case, the equilibrium of centralization requires empirical evidence and can only be answered after the system has been running for a long time in practice. With sharding, centralization is expected to be further reduced because (1) there are fewer disparities to worry about, and (2) in a sharding model, the compliance of transaction validation is proportional to the amount of funds invested, so there are no direct cost savings from forming pools. Finally, centralization harms PoS less than PoW, because the cost of recovery from a 51% attack is much lower in PoS, and no new mining algorithm is needed. Can Proof of Stake be used in private chains or consortium chains? Generally yes. Any PoS mechanism can be used as a consensus algorithm in private or consortium chains. The only change is in how validators are selected: initially, a group of users who are trusted by all parties become validators, and then these validators vote on whether to add new validators.