Dry goods: On rights and consensus

特邀专栏作者

2020-12-18 13:45 (UTC+8)

This article is about 12006 words, reading the full article takes about 18 minutes

Only relying on the resources in the system, Proof of Stake cannot form a distributed consensus, because it has to rely on the history of its own attempts to form a punishment.

AI Summary

Expand

Only relying on the resources in the system, Proof of Stake cannot form a distributed consensus, because it has to rely on the history of its own attempts to form a punishment.

Editor's Note: This article comes fromEthereum enthusiasts (ID: ethfans), reprinted by Odaily with authorization.

Ethereum enthusiasts (ID: ethfans)https://download.wpsoftware.net/bitcoin/old-pos.pdfturn up.

1 Introduction

, reprinted by Odaily with authorization.

Note: This document was substantially revised in March 2015. Older versions can be found at

turn up.

1 Introduction

In 2009, Satoshi Nakamoto created Bitcoin [Nak09]. Bitcoin is an Internet currency system that enables peer-to-peer digital token transfers. To ensure everyone has a consensus on token ownership, Satoshi employs a public ledger that is replicable and verifiable by all network participants. In order to avoid a single point of failure, the ledger is authenticated using a dynamic membership multiparty signature (DMMS) [BCD+14] mechanism, that is, the entire ledger history is executed once at each "heartbeat". High computational cost (but low verification cost).

Unlike traditional digital signatures, there is no notion of "forgeability" for a DMMS in DMMS. Each DMMS is expensive to create (in Bitcoin, high electricity costs), and this behavior can be rewarded with new coins issued on the ledger. Since these new tokens must be endorsed by others to be useful, participants are incentivized to collectively extend the "true ledger" rather than creating the ledger themselves1. (Translator's Note: The original text of the word "recognition" here is "recognize", which means that its original meaning may not have so many hints of "social consensus", and it itself can have a strict technical meaning: if you do not accept To a block, you will not approve the currency issued by this block.)

Since Bitcoin's DMMS is computationally and thermodynamically expensive [Poe14a], other more economical and greener alternatives have been proposed. The most commonly proposed solution is PoS (Proof of Stake), which is a low-cost distributed consensus mechanism. As Andrew Poelstra [Poe14b] stated in 2014, PoS is not feasible, but various forms of PoS schemes have emerged. At the same time, Poelstra's arguments are often claimed to be "false" or "false" in various forums, although they never present any convincing counterexamples or errors. In addition, some people gave a pertinent opinion that Poelstra's paper was written obscurely and boringly. It can be seen that there are still many shortcomings in this paper. While Poelstra found no inaccuracies in his previous work, he is prepared to take the opportunity to further formalize his argument.

The scientific understanding of Bitcoin consensus has come a long way since Poelstra wrote his paper [MLJ14, BMC+15].

This article aims to update Poelstra's thesis to shed light on the problems Bitcoin solves, the design rationale behind PoS, and why mechanisms like PoS cannot produce distributed consensus within Bitcoin's trust model.

Note 1: To ensure that all participants can see the "true ledger", we need a synchronous network: all (valid) data can reach all participants within a certain length of time λ, and the network heartbeat time is longer than λ much. Without a synchronized network, distributed consensus is much more difficult. (One of the often cited conclusions is that distributed consensus is impossible with deterministic algorithms [FLP85]; this problem is easily avoided with probabilistic algorithms, so there is not much discussion on the difficulty of designing consensus systems .An older version of this document misquoted this conclusion as thinking that it made consensus impossible for all distributed consensus mechanisms in an asynchronous network. Thanks to Dominic Williams for pointing this out.)

2. Distributed consensus

Before discussing Bitcoin's solution to the distributed consensus problem, we must first understand the nature of the problem. Distributed consensus (the term used by the Bitcoin system) is a consensus (ie, a global agreement) between parties that lack trust in each other. These parties are anonymous and did not necessarily exist when the system was established. As Poelstra explains in his paper:

In the case of cryptocurrencies, it is sufficient to achieve distributed consensus only on the chronological order of transactions, i.e., "consensus on the first transaction to transfer a specific amount of money". This ensures that the entire network recognizes the new owner of funds.

The reason this consensus is needed is to prevent double-spending. In all decentralized digital currency mechanisms, it is possible for a payer to send the same funds to two different people, and both transactions appear to be valid. Therefore, the payee needs to be able to ensure that no conflicts have occurred, or that in the event of a conflict, the network will recognize its transaction as the correct version. A distributed consensus on the order of transactions enables this: in the event of a conflict, everyone agrees that the first transaction is valid and the rest are invalid.

(Other problems with digital currencies, such as permissions and anti-counterfeiting, are relatively easy and can be solved by traditional cryptography.)

The point is, we should realize that while distributed consensus is a hard problem, general consensus is easier, better researched, and trillions of times more efficient with trusted and identifiable signers. Therefore, a cryptocurrency that introduces trusted parties (even under limited conditions) should consider whether its new trust model can help reduce the difficulty of reaching consensus. Readers interested in more efficient consensus mechanisms with trusted parties may look into it.

3. Dynamic Membership Multiparty Signatures

Bitcoin's ledger is publicly available, and all participants in the Bitcoin network can verify the validity of each transaction on the ledger. However, since the ledger is fundamentally a historical record, cryptography cannot distinguish authenticity, someone must prove the ledger, and others must trust that this person will not sign the wrong history.

The earliest digital cash systems had a single non-anonymous person sign all transactions [Cha83]. However, this not only introduces a single point of failure risk to the system, but also allows the signer (and anyone who can coerce that signer by power or force) to censor transactions or initiate double spends. While blind signatures (see [Cha83] for details) can be used to prevent censorship, they cannot protect against single points of failure and double spending. Multi-party signatures may be able to solve the latter two problems, but the two requirements that it is difficult for all signers to be coerced at the same time and that all signers must be trusted by all participants conflict with each other. Non-anonymity also means that a particular attacker can always attack the system.

Bitcoin's solution is to remove fixed and identifiable signers entirely. Bitcoin's ledger is verified by a group of signers called miners, who do not disclose their identities to other participants, and perhaps can enter or exit the system at zero cost. Miners generate signatures through a process called "mining". During mining, they collectively generate proof-of-work [Bac02] for successive blocks of transaction data.

In this section, we explain how mining works and how it provides verification.
3.1 Authentication in an anonymous world
The operation principle of the cryptographic digital signature mechanism is as follows. The signer generates a "signing" and "verifying" key pair (s, v) and publishes v along with its name on some public channel. The signer can generate a signature σ according to a given message m, and anyone can verify the validity of σ. That is, inputting v, m and σ into the verification algorithm will always output 1 if the signature is valid.

For security reasons, traditional digital signatures must be anti-forgery, that is, the probability of any attacker with limited computing power forging a signature is negligible. Specifically, "fake" means (the attacker) can win the following games:

The signer hands over the verification key v to the attacker.

The attacker sends messages m_i to the signers and receives valid signatures σ_i for those messages. An attacker can repeat this operation multiple times.

The attacker generates a new message m together with a valid signature σ based on m.

This security is known as existential unforgeability under chosen-message attack and is a common standard in the cryptography literature.

[In a multi-signature mechanism, each signer has a verification key. Only signatures generated by an "admissible subset" of signers (or signing keys) are valid. In defining security, the above game is modified to allow an attacker to request (and obtain) a signing key, as long as the attacker obtains keys that do not form an "admissible subset". 】

It can be seen that the verification algorithm uses the verification key v to verify the signature and in this way verify the "identity" of the signer. Since anyone can create a key pair, for a signature to have value, a public record must link the verification key to the signer's true identity. If there is a dishonest behavior (sign invalid history), the dishonest party will be held accountable.

From this point of view, authentication is not suitable for systems where the signer is anonymous and not fixed. In fact, it's not clear what role "authentication" can play in such systems! If anyone could generate signatures anonymously, it would be impossible to distinguish honest signatures from dishonest ones, real histories from fake histories. Then the above definition of security loses its meaning, because the attacker can freely join the set of signers and "forge signatures"2.

To solve this problem, Bitcoin employs another security model. In this model, all participants are equal, but they have economic incentives to be honest. In the next section, we introduce this security model.
Note 2: As we saw in Section 4, in the case of cryptocurrencies, it is possible for anonymous parties to lock up deposits and have some mechanism to punish dishonest actors without confirming anyone's identity. This is effectively Proof of Stake. However, cryptocurrency is inseparable from consensus, so the premise of "if it is cryptocurrency" makes us unable to use proof of stake here, otherwise it will fall into circular reasoning. We will address this issue in the next section.
3.2 Define Security for DMMS

As far as the DMMS is concerned, all parties are equal; security cannot be gained by having an "adversary" with only incomplete knowledge. Therefore, we define DMMS using the following three parts. These parts are different from the key generation algorithm of traditional signatures:

Use a cost function c to track the execution of the algorithm and output a "cost" t ∈ , where is some "cost field". The function must be linear because the cost of running two algorithms in succession is the sum of their respective costs.

The randomization algorithm AttemptSign takes a message m as input and a signature σ. The algorithm should have a cost of 1 for any input message m.

The deterministic algorithm Verify takes message m, signature σ and target cost T as input, and outputs 0 or 1.

If and only if Verify(m, T, AttempSign(m)) = 1 has a probability of 1/T for all T belonging to it, then we say that the DMMS is correct (correct), this probability is determined by the AtemptSign algorithm Guaranteed; if and only if the probability of any polynomial algorithm to realize Verify(m, T, A (m)) = 1 does not exceed 1−(1−1/T)t, then we say that such a DMMS is safe ( secure) (where t is the execution cost of Algorithm A).

In other words, a secure DMMS means that there is no better signing algorithm (in the sense of creating a verification signature) than repeatedly executing AttemptSign.

We briefly demonstrate our security definition. In order to achieve a dynamic membership set, we cannot make participation too expensive, nor allow existing signers to exclude new signers through obvious means or economic factors. This means that the signing process should be "divisible", neither requiring nor incentivizing any communication between signers. That is, taking twice as long to run a signature algorithm should have as high a probability of success as running it in parallel on the same two pieces of hardware. At the extreme, this means that the best signature algorithms should consist of repeated, independent executions of a single underlying step, which is derived by definition.

3.3 Mining mechanism as a DMMS
Bitcoin mining uses hashcash [Bac02], a proof-of-work algorithm based on hash functions. This is a DMMS [BR93] using a random oracle model. As a calculation model, the random oracle refers to the model that regards the hash function as a "random number oracle", or true random function 3, whose output is purely random, and can only be calculated through this function .
Although the use of the random number oracle model has caused much controversy [Gre11], there is strong empirical evidence that it can be used to ensure security. Hereinafter, H refers to a hash function with an input of up to 256 bits, which is considered a random number oracle.

Bitcoin's DMMS is as follows:

The cost function gives the number of times the random number oracle is called during the execution.

AttemptSign takes a message m as input and outputs a random number σ ∈ {0,1}256.

Verify takes as input a signature σ, a message m, and a target T. Output 1 only when H(m || σ) < 2256/T.

It's not hard to see that in the random number oracle model, there is no better way to create valid signatures than repeatedly running a hash function.

Note 3: This model is completely unrealistic, because the true random function, from, say, 512 bits to 256 bits, requires an average of 2512·256 bits to represent, which has exceeded the currently known expression limit.

3.4 No world time

Note that in the previous section we used the number of hash function calls as our cost function, which is roughly proportional to the number of computations, which in turn is roughly proportional to the heat dissipation. In the end, the amount of heat dissipation is roughly proportional to the economic and environmental cost of creating these signatures.

An obvious question is, can we use a "cheaper" cost function? In particular, why can't we use clock time directly? Why do we use DMMS to sign blocks to create a blockchain instead of directly sorting transactions chronologically to resolve consensus conflicts?

The answer is that there is a lack of well-defined clock time in distributed systems. Network latency limits the speed at which information can travel. According to the special theory of relativity, different observers cannot agree on the chronological order of events that occur nearly simultaneously.

If this is the only problem, then ask for a few seconds between each transaction (if the interval between conflicting transactions is too short, both transactions will be rejected; but wait until a few seconds after each transaction, all parties involved can ensure that this does not happen). However, the actual situation is much worse for two reasons:

"Network latency" cannot be limited in hostile environments. Attackers may be able to use denial-of-service measures to arbitrarily slow down systems and otherwise physically partition networks.

In relativity terms, this means that no matter how long the wait time is set, there is no way to ensure that a participant will not become spacelike separated from other participants in the network.

Users who are new to the network or have recently gone offline need access to historical data. However, there is no way to verify the order in which transactions occurred after the fact, so in the event of transaction conflicts, users have no guarantee that the transaction they received occurred first.

3.5 Consensus from DMMS

Now that we have understood DMMS and explained why Bitcoin's hashcash is a secure algorithm, let's think about how to achieve distributed consensus through DMMS.

Our claim is that it is possible to achieve distributed consensus through DMMS.

We first need to measure (a) some kind of scarce resource that cannot create signatures for many messages at once, and (b) the average time it takes to create a signature via our cost function (a monotonic function). (In order to be decentralized, this scarce resource may need to be consumed forever, as in the Bitcoin system, allowing the marginal cost of mining to dominate the cost of capital. Poelstra supports this view [Poe14a], but John Tromp disagrees with [Tro14].)

Taking Bitcoin as an example, our cost function is defined as "the number of times the hash function is called". We argue that this function actually measures the energy consumed to compute the signature and is justified by the Landauer limit [Lan61]. From a physical point of view, the so-called energy is the minimum heat consumed by any irreversible bit operation. By counting the number of irreversible bit operations involved in the sha256 computation, we can (at least in principle) place a lower bound on the amount of energy required to create a Bitcoin DMMS.

A cost function can also be used to measure the time it takes to create a signature, since only a certain amount of energy can be expended per unit of time, unless you create a black hole (i.e., do not allow the signature, or indeed any information, to be extracted in a usable form ). Of course, in real life, Bitcoin miners don't operate near the black hole limit, and the time it takes depends on the speed of the mining hardware. As mining hardware improves and the number of hardware online at the same time increases, the time required to create a DMMS decreases. In Bitcoin, the target cost is adjusted according to this, keeping the time required to create each signature at around 10 minutes4.

Note 4: Given the no world time mentioned in 3.4, the reader may wonder how to adjust the time accurately. In reality, timestamps are inserted into blocks by miners, and there is really no way to prevent miners from falsifying them. Bitcoin is resistant to minor deviations from the target caused by false timestamps, and also prohibits the target (Translator's Note: Difficulty) from changing too quickly. Therefore, it is very expensive to create large deviations from the target, and may be thwarted by uncooperative miners. See [Poe14c, Section 6.3] for more discussion.

So, with a secure DMMS that measures scarce resources via a cost function, how do we get consensus history? First, we assume that the network is synchronous, so that (the vast majority) of participants have all valid data available within a certain time λ. We split the transaction history into a series of blocks, where each block contains a series of transactions and a cryptographic commitment to the previous block5. Every valid block must have a DMMS that has a target such that it takes much longer than λ to create a block (so that miners working on the same consensus history know which block is up-to-date, and block creators do not have much advantage in knowing the latest block first). To be clear, the target cost of each DMMS is defined by system rules, not by miners.

Note 5: A commitment (commitment) is a cryptographic object that is calculated from a certain secret data, but the data will not be leaked, so the data cannot be modified afterwards. Collision-resistant hash functions are an example: given data x, you can first publish H(x) (H is the hash function), and then publish x later. The verifier can use the public value to calculate H(x) to confirm whether this value is the same as the original value.

Network participants work by first considering all valid block branches that start with the same genesis block (hardcoded into the system). (Since each block contains the commitment of the previous block, the result is a directed acyclic graph rooted at the genesis block, and these block branches are the paths in the graph.) Then calculate the The sum of the target costs in DMMS yields the weight of each block branch. The heaviest block branch is considered the "true" history.

When creating a block, the miner chooses transactions according to his own wishes, and adds a special "reward transaction" to distribute the fees of other transactions and the subsidy defined by the network to himself, plus (what he considers the orthodox chain's ) of the latest block commitment, and then calculate the DMMS. If another miner creates and publishes a block, the miner updates their "true history latest block" accordingly and changes the commitments in their own blocks to accommodate this change. After calculating a DMMS, they publish the completed block to the network.

We argue that this leads to a consensus history, meaning that the entire network will gradually come to a consensus on exactly which blocks are part of the real history (and which are not), and that inconsistencies will only occur in recent history. The specific discussion can be found in Miller and La Viola Jr. [MLJ14] (we can measure the degree of energy consumption DMMS in this article, and the expression in that article is "moderately-hard puzzles"), but we attach here a less so formal argument.

Because the network is synchronous, the block transmission time is much shorter than the block production time, so all participants can quickly realize the heaviest history.

We further believe that most of the participants in the network will participate in producing DMMS that extend the real history. An elegant and correct reason is proposed by Vitalik Buterin [But15]: because "reward transaction" will be accepted if and only if its block belongs to the real history, for each miner, the Nash equilibrium is to obey the absolute Most of 6.

Note 6: Also in the same article, Buterin said: "If you are tired of PoS opponents quoting you from this article written by Andrew Poelstra (ie [Poe 14b]), please feel free to link this article as Hit back." It's not quite clear what he means by that; throughout, and nowhere, he fails to refute the article's claim that there is no way to generate consensus other than by consuming resources outside of one system.

In order to change the "true history", the attacker must generate another history with greater weight (that is, the target cost is greater) (such an alternative history version can be defined as being generated from the latest top of the current history back N blocks) a fork of ). He has fewer resources than the group of miners who is extending real history, because that group of miners is the majority. Therefore, the probability that he can win in the network is less than 1 (because in any given time period, the number of attempts to extend the real history in the network is more than the number of attempts to extend his own alternative history), and for His own history exceeds the real history, and he must win more than N times. If the probability of winning once is P < 1, then the probability of him winning N times is PN. If N is large enough, the probability is so small that it can be ignored.

(The argument here is very weak, because it only considers that an attacker has to win continuously, and does not take into account that the difficulty of block generation will be adjusted; the adjustment of difficulty will allow the attacker to reproduce the old block faster than the network. New blocks are faster. I assert here, without any basis, that these are not serious problems, just tedious ones.)

3.6 Consensus without DMMS

Is it necessary to use DMMS to create a distributed consensus mechanism? So far this is an open issue. My guess is "no". More specifically, simply changing the Bitcoin protocol to reward miners with "coupons" for mining future blocks at a lower difficulty [BDC+14, Section 6.1] is unlikely to break consensus, but the model Obviously does not meet our above definition of DMMS.

4. Proof of Stake

With Bitcoin's consensus mechanism as a basis, let's analyze the most popular alternative, Proof of Stake. See [Poe14b] for a description of PoS:

With modern cryptography, the notion that 'information' itself is something physically real and valuable" moved out of the philosophy department classroom and into the real world of business. We are all familiar with the economic activity underpinned by secure communications: Negotiations, contracts, deals, bills, and orders can all be sent to the public Internet without fear of forgery or interception. We also all know the financial consequences if confidential data is lost or stolen. By January 2009, with the advent of cryptographic currencies [Nak09], the concept of valuable information became more concrete. You can hold and exchange a fungible store of value in an open communication medium, only using cryptography (no physical security facilities) to prevent fraud and theft. Not only can one say "this encryption key is worth $10,000 because we'd lose this much money if it were exposed," but one can also say "this key is worth $10,000, but the value in it is divisible Yes, you can split $20 and send it to someone else, and keep the rest for yourself.” With this background knowledge, proof of stake is actually easy to understand. A proof of stake is a cryptographic proof of ownership. In cryptocurrency, proof of equity can not only prove the ownership of a currency, but also prove that the money meets some characteristics (for example, the money is locked and cannot be spent until certain conditions are met). unlock). Specifically, proving that funds are locked in a scarce and experimental cryptocurrency can be seen as proof that one has a serious interest in the project's success. Users can prove their interest in the continued existence (and sustainable development) of the project by providing locked-in rights and interests.

That is, Proof of Stake is the notion that we can use cryptographic proofs, rather than physical theories like the Landauer limit, to prove that certain computations are prohibitively expensive.

4.1 Proof of Stake vs DMMS

Using "pure proof-of-stake" to generate consensus on the history of a cryptocurrency presupposes that it is possible to create a DMMS-like signature scheme7 whose cost function measures the the number of coins themselves. This sounds simple in principle, and we quote [Poe14b] again:

On a sufficiently expressive ledger, currency holders can lock their currency for a period of time to lease a cryptographically verifiable "stake". When the consensus history needs to be advanced, each stakeholder signs the extended content (blocks) instead of attaching a proof-of-work to these content. For practical convenience, generally speaking, every time a block is produced, a small part of the stakeholders will be randomly selected to be responsible for producing the block; moreover, to obtain the validity of the block, it only needs Most of the small team agrees. These selected stake holders are rewarded and after a period of time, they can unlock their stake if they wish. The idea here is that rather than making the economic cost of controlling history prohibitively high, stakeholders have an incentive to agree on every block because (a) they are all chosen at random and are unlikely to collude with each other;( b) even though they might collude with each other, they don't want to bring down the whole system (e.g. signing conflicting histories would lead to that); (c) they have limited capital to do much damage. For the above reasons, the next randomly selected stakeholder group may only choose to produce blocks on a history they believe to be reliable.

Note 7: The proof-of-stake scheme is not always designed to be process-free (progress-free, that is, no matter what you have done before, it will not affect the success rate of your next attempt), so not all of them can become Proper or safe DMMS. However, the underlying tenet is still "make making history very expensive and reward those who participate in correct history", so we continue to look at it through the lens of cost.

This article has complicated things a little: in a real proof-of-stake system, often only one signer's approval is required, and most of the approvals are not required.

The problem here is that properly defining a cost function that measures the amount of stake locked (in a currency) requires a consensus history of the currency. If it can only reach the point of "there is a certain history in which these coins are locked together", then although the final DMMS may be well defined, its cost function is no longer a measure of scarcity, and Section 3.5 of this paper The conclusions also do not hold.

Of course, scarcity can be shaped by penalizing stakeholders who sign multiple histories. For example, if the system uses Schnorr or ECDSA signature schemes, and stakeholders can only choose a specific nonce when signing, they must use the same (key, nonce) when they want to sign multiple histories pair to sign two messages, which would allow others to geometrically solve for their private key. However, such a design still cannot prevent stakeholders from "grinding" blocks (continuously trying different blocks), and only publishing the block 8 that allows them to continue to be block producers in the next block, This repeated repetition gives complete control over the entire blockchain. This is an example of a "stake grinding" attack. As we'll see below, equity grinding is just a special case of a more general problem.

In general, one-time signature schemes prevent stakeholders from publishing conflicting histories (provided the attacker values the coins he would lose more than he can get more from the chaos he caused), but once Sexual signatures do nothing to prevent stakeholders from secretly creating conflicting histories.

Note 8: Note that the random number must be determined by the blockchain itself, because it is the only object that everyone needs to agree on. So PoS miners can twist the system with stake grinding. Using multiple blocks or long-term blocks to determine the random number does not solve this problem. Either way, some party can manipulate it.

4.2 Costless Simulation

Ultimately, the problem is that coins bonded against a stake signature only exist within the blockchain to which those coins belong to. This means that as long as certain groups can create blockchains cheaply, such groups will create multiple blockchains and choose the one that is more favorable to their interests.

If everyone could create history cheaply, the system would break down. The point of locked equity is to make "cheap creation history" only available to those who are willing to hold the currency for a long time, and it can be assumed that for these people, the system is so meaningful that it is impossible to attack it. it. However, since there is no global time (and no global history for those new to the network), there is simply no way to distinguish someone who has "recently" started holding coins from someone who has "always" held coins. For a proof-of-stake system, at any point in history, there is a set of signature keys that can transfer currency, lock and unlock equity, and sign blocks. It can be assumed that at a certain moment in the real world, when the system creates a new block, at this moment, some keys correspond to ownership. However, real-world time will continue to flow, and this block will become a static thing, and all the signing keys associated with it will also become static.

I'll say it again: In real time, the blockchain will get longer and longer, the rights will be unlocked, the coins will be exchanged for other products and services, and those keys, even if misused, will cause the holder Lose value and become meaningless. But for an immutable blockchain, the meaning of a block's key can never change.

Because in a proof-of-stake system, part of the key determines the future, this creates a problem. No matter who can get these keys (it may be a user who cleared the currency by himself, or someone who bought a private key with her or picked up her private key; users are not good at keeping private keys for a long time, especially those who private keys they feel they will never use again!), have the ability to fork the network, or create an alternate history; new users cannot tell which is real and which is fake.

The point is that even if a stake holder were to lock up a large sum of funds (with a high market value) and lose all funds if they did not comply with the agreement, this deterrence will disappear after the user unlocks their stake, and the unlocked It will come sooner or later (whether it is viewed from the outside of the system or from the inside of the system), and at the moment (this block) it is bound to be impossible to determine when (which block) the rights and interests will be unlocked. Therefore, free history, or "zero-cost simulation", cannot be prevented by locking the value defined internally by the system.

4.3 "Long range" attack vs. "short range" attack

If you require stake holders to bind their stake for a long time, and use blocks from long ago (in blocks) to generate randomness in choosing signers, then you can make the above attackers have to rewrite for a long time History. It is often said that this will "protect against short-range attacks".

Clearly, this still doesn't solve the zero-cost simulation problem; after all, creating history branches is easy, no matter how long, as long as creating the history itself is easy. However, proponents often say that there is a history created by honest signers, the number of blocks accumulated in this chain also corresponds to a longer time in the real world, and any modification of this history will be related to the participants. The remembered history conflicts. So, people can detect and realize it's an attack and deny it.