V God personally tells the design principle of Serenity, and takes you to understand the ingenuity behind this magnificent project!

星球君的朋友们

Odaily资深作者

2019-08-16 12:50 (UTC+8)

This article is about 14422 words, reading the full article takes about 21 minutes

Protocols should strive for the greatest possible simplicity in their decisions.

AI Summary

Protocols should strive for the greatest possible simplicity in their decisions.

Editor's Note: This article comes fromUnitimes（ID：Uni-times）Editor's Note: This article comes from

For the design principle document of the Eth1.0 chain, see:

https://github.com/ethereum/wiki/wiki/Design-Rationale

secondary title

Serenity Design Principles

▲ Simplicity: Especially since cryptoeconomic PoS and quadratic sharding are complex in nature, protocols should strive for the greatest possible simplicity in their decisions. This is very important because it will:

(i) minimize development costs,

(ii) reduce the risk of unintended safety issues, and

(iii) Make it easier for protocol designers to convince users of the legitimacy of parameter choices.

Follow this link [1] for background information. When we want to achieve a certain level of functionality, we cannot avoid certain complexity. The priority level of complexity is: Layer 2 protocol complexity > client implementation complexity > protocol specification complexity.

▲Long-term stability: Ideally, the lower-level protocol should be built so that no protocol changes need to be made in 10 years or more, and any needed innovation can be implemented at a higher level (client implementation or Layer2 agreement) on.

▲ Sufficiency: As many application categories as possible should be able to be built on top of the protocol.

▲Verifiability of light clients: Given some security assumptions (e.g. network latency, attacker budget bounds, only 1/n or few honest verifiers), verify O© data (ideally only verifies the beacon chain) Clients of should be able to obtain indirect assurance that all data across the system is available and valid, even in the event of a 51% attack (note: this is one of the goals of the "defense in depth" aspect).

secondary title

The compromise between Layer1 and Layer2

Readers can read my previous two articles: Layer 1 Should Be Innovative in the Short Term but Less in the Long Term [2] and Sidechains vs Plasma vs Sharding [3].

In any blockchain protocol design, there is a difference between introducing more features at Layer 1 (that is, the consensus layer), and building a more concise Layer 1 protocol and allowing these features to be built on Layer 2 (that is, the application layer). Each has tradeoffs:

Arguments in support of Layer2:
Reduce the complexity of the consensus layer (see "simplicity" mentioned above);
Reduce the need to modify protocol layers (see "Long-Term Stability" mentioned above):
-- Reduce the risk of not being able to reach a consensus;
-- Reduced workload on protocol governance and political risk
More flexibility and ability to implement new ideas over time
Arguments in support of Layer1:
Reduce the risk of progress stalling due to the lack of a mechanism to force everyone to upgrade to the new protocol (i.e. hard fork);
Potentially reduce the complexity of the overall system;
If Layer1 is not strong enough, then it is impossible to build a Layer2 system with the required performance on Layer1 (see "abundance" mentioned above)
The design of Ethereum 2.0 is largely dedicated to carefully maintaining a balance between Layer 1 and Layer 2. This includes (i) Turing-complete, state-rich code execution, (ii) scalability in terms of data validity and computation, and (iii) faster block confirmation times, which are critical for protocol implementations. Sex] are very necessary because:
Without implementing (i), it is impossible to build Layer 2 applications with a robust trust model.
Without (ii), scalability would be limited to technologies such as state channels or Plasma, which have challenges in scaling and locking up funds and/or exiting at scale.
If (iii) is not achieved, there is no way to conduct fast transactions without using channel technology, which has challenges in terms of promotion and locking of funds and/or large-scale exit.
But Ethereum 2.0 also intentionally left some other features to Layer 2: (i) privacy, (ii) high-level programming language, (iii) scalable state storage, and (iv) signature scheme. These features are left to Layer 2 because these aspects are areas of rapid innovation, many existing solutions have different characteristics, and trade-offs are inevitably made to obtain better and newer solutions. for example:
Privacy: Ring Signature + Confidential Values vs. ZK-SNARKs and ZK-STARKs, Rollup vs. ZEXE, etc.
High-level programming languages: declarative programming vs. imperative programming, syntax, formal verification features, type system, protective features (such as prohibiting the use of impure functions in arithmetic expressions), natively supported privacy features, etc.;
Signature schemes: Schnorr signatures, BLS signatures, Lamport signatures, etc.

secondary title

see:

https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQ
https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51

secondary title

Why use Casper?

The current proof-of-stake (PoS) consensus algorithm mainly falls into three camps:
Proof-of-stake algorithms inspired by Satoshi Nakamoto (such as Peercoin (Peercoin), NXT (Future Coin), Ouroboros (Cardano’s consensus algorithm) and other practical algorithms)
Proof-of-Stake algorithms inspired by PBFT (Practical Byzantine Fault Tolerance) (such as Tendermint, Casper FFG, Hotstuff, etc.)
CBC Casper (see [4] and [5] for explanation)

In the latter two camps there is a question of whether and how margin deposits (staking) and slashing (staking) should be used. All three proof-of-stake mechanisms are superior to proof-of-work (PoW), but we want to defend the approach used by Ethereum 2.0 in this article.

Slashing

Ethereum 2.0 uses a Slashing (deposit penalty) mechanism, that is, verifiers who are detected to be misbehaving will be punished. The mildest punishment is to destroy ~1% of the pledge, and the most serious punishment is to destroy the verifier. All deposits.

We defend the use of the Slashing mechanism on the following grounds:
Increased cost of attack: What we want to ensure is that any 51% attack on a PoS chain will result in the attacker expending a very large fee (such as hundreds of millions of dollars worth of Recover from attack. This makes the attack/defense calculus very unfavorable to the attacker and can actually make the attack counterproductive.

Overcome the dilemma brought by the verifier: The most realistic and direct way for the node to start to deviate from the "honest" behavior is negligence (such as the verifier should participate in the verification, but not participate in the verification; or sign when it should not be signed, etc.) . The dilemma posed by validators is detailed in [6], and Bitcoin SPV mining [7] is an example of this happening, which will lead to very serious consequences. Validation penalties for dishonest validators help alleviate these dilemmas.

text

Choice of Consensus Algorithm

Choice of Consensus Algorithm

Among the three camps of the PoS consensus algorithm mentioned above, only the latter two camps (ie, the consensus algorithm inspired by PBFT and CBC Casper) have the concept of finality in these two algorithms, that is, a certain area Blocks are confirmed in this way: only when a large proportion of validators (PBFT-inspired algorithms require at least 1/3 of validators, CBC Casper algorithm requires at least 1/4 of validators) misbehaves and therefore The block will only be reversed when it is slashed;

And the first camp - the Nakamoto-inspired (longest chain rule) consensus algorithm cannot achieve finality in this sense.

We chose Casper FFG simply because it is the simplest algorithm available to the protocol when achieving determinism. We are currently actively exploring switching to CBC Casper in Phase 3 of Ethereum 2.0.

secondary title

Sharding, or why do we hate super nodes?

For Layer1 expansion, one of the main alternatives to sharding is to use supernodes. Supernodes require each consensus node to have a powerful server so that the node can process each transaction individually. trade.

Supernode-based scaling is convenient because it's easy to implement: it's the same approach taken by many current blockchains, except that it requires more software design work to build in a more parallelized fashion.

We do not choose this way of using super nodes for the following main reasons:
Validation pool centralization risk: In a supernode-based system, running a node will require a high fixed cost, which limits the number of users who can participate. While some will counter that "in most PoW and PoS cryptocurrencies, consensus is controlled by 5-20 pools (mining pools or validating pools) that can run nodes just fine." The problem is that it ignores the risk of centralization pressure, even among pools with deep pockets. If the fixed cost of running a validator is very high relative to the rewards, then larger validator pools can offer lower fees than smaller validator pools, which may cause those small validator pools to be crowded out and feel pressure to merge. In a sharding system, validators who pledge more ETH will need to verify more transactions, so the cost is not fixed.
Risk of centralization in the cloud: In a supernode-based system, it becomes infeasible for users to staking at home, so most staking is more likely to happen in a cloud computing environment. This creates a single point of failure.
Reduced censorship resistance: It is impossible for users to participate in consensus without high computational + bandwidth requirements, which makes it easier to detect and censor validators.

secondary title

security model

It is generally believed that the security of the blockchain relies on the assumption that "most participants are honest", that is, ≥50% of the participants will honestly follow the established agreement and will give up the chance of treason for personal benefit.

In fact, (i) the assumption that "the majority of participants are honest" is unrealistic, since participants may be "lazy" and sign blocks without validating them (see Validator [9] and forks caused by Bitcoin SPV mining[10]), which are very common cases of defection; but fortunately, (ii) blockchains usually pass some security models (while does not assume that the majority of participants will remain honest) to maintain its own security properties.

A common and strict security model is the uncoordinated rational majority model (uncoordinated rational majority), that is, participants will act in accordance with their own interests, but the number of participants that cooperate with each other will not exceed a certain proportion (in simple In the PoW chain, this proportion is 23.2% [11]).

Another more stringent security model is the worst-case model, that is, when a single participant controls more than 50% of the computing power or pledge, the problem at this time becomes:

(1) In this case, can we guarantee that the verifier will pay a very high cost when trying to destroy the entire chain?

(2) What guarantees can we keep unconditionally?

In a PoS chain, slashing (slashing of the deposit) can provide the guarantee of the first problem above, that is, when an attacker tries to destroy the entire chain, it will need to be very expensive. In a blockchain without fragmentation (such as the current Ethereum 1.0 chain), each node that verifies all blocks will fulfill the requirements of the second question above by providing the following two guarantees: (i) the longest chains are valid, and (ii) the longest chain is also available (see this link [12] for a theoretical rationale for the importance of "data availability").

In Ethereum 2.0, we implement defense in depth through sharding (sharding), that is, by combining a randomly selected validator committee, based on a security model that most validators will remain honest, to achieve effectiveness and availability Guarantee, and prevent lazy validators through proof of custody (i.e. if the validator is "lazy" and will not participate in the verification will face penalties), through fraud proofs and data availability proofs [9] Detect invalid and unusable chains without downloading and validating all data. This will allow clients to reject invalid and unusable chains even when the chain is supported by a majority of PoS validators.

The expected security characteristics are shown in the table below:

secondary title

Incentive mechanism set by Casper

Basic rewards

During each epoch (in Ethereum 2.0, every generation of 64 blocks (about 6.4 minutes) is called an epoch), each verifier must perform "attestation", that is, to the chain head (head ) to vote and sign (the chain head is the top block). If the verifier's "proof" is included in the chain header, the verifier will be rewarded. This reward consists of five parts:
Rewards for "proofing" inclusion in the top block;
The reward for "proving" the correct epoch checkpoint (Note: the last slot during each epoch is called checkpoint (checkpoint), and the slot is the time required to generate a block set by the protocol ( 6 seconds));
Rewards for "proving" that the correct chain head (top block) is identified;
Rewards for the "proof" being included on-chain quickly (if the "proof" was included after 1 slot, the verifier gets the full reward; if it was included after n slots On the chain, the reward obtained will be 1/n of all rewards);

Reward for "proving" that the correct shard block was identified.

In each case, the actual rewards are calculated as follows. If B is the base reward and P is the fraction of validators who perform the desired "proof" operation, then any validator who performs the required operation will be rewarded with B*P, while any validator who should have performed the relevant operation but has not Validators who do not do this will be penalized with -B. The goal of this "collective reward" mechanism is "if someone does better, everyone does better", thereby limiting the vandalism factor. (See this article [13] for a description of the vandalism factors and why limiting them is important)

Note that point 4 above is an exception; this reward depends on the delay of the "proof" being adopted, not on the behavior of the validator, and there is no risk of punishment.

The base reward B itself is calculated as, where D1...Dn is the size of the validator's deposit and k is a constant. This is a compromise between two common patterns of (i) setting a fixed reward rate, ie, k*Di, and (ii) setting a fixed total reward, ie.

The main argument against (i) is that this model brings two uncertainties to the network: the total amount of coins issued is uncertain, and the total number of participating pledges is uncertain (because if the fixed reward rate is too low, Then basically no one will participate, which threatens the entire network; and if the fixed reward rate is too high, too many people will participate, making the circulation of coins unexpectedly high).

The main argument against (ii) is that this model would make the network more vulnerable to “discouragement attacks”, see [13] for details.

The block proposer is rewarded with 1/8 of the base reward for including the "proof" in the block, in order to encourage the block proposer to listen to information as much as possible and accept as much information as possible.

Online time to break even

text

Suppose there are two kinds of verifiers: (i) online verifiers who play a role, and (ii) offline verifiers. If the former type of verifier is partially P and the basic reward is B, then the online verifier is expected to receive The reward is: reward B*4P for the 1st, 2nd, 3rd and 5th cases above + 7/8*B*(P+(P*(1-P))/2+(P *(1-P)^2)/3+...) (since the "proof" may be delayed from being included in the chain header due to the absence of validators) + block proposer reward 1/8*B*P . The verifier who is absent (that is, should have participated in the verification but did not actually verify it) will be punished by B*4. Therefore, if all other verifiers are online, the verifier will be rewarded with B*5 when online and penalized with B*4 when offline, so if the verifier is online for ≥4/(4+ 5) ≈ 44.44%, the verifier will be able to break even (break even). If P=2/3 (that is, online verifiers account for 2/3 of all verifiers), then the verifier will be rewarded for being online is ≈B*(2/3*4.125+7/8*0.81 )≈B*3.46, or will reach a balance of payments due to online time ≥ 53.6%.

Inacivity leak

However, if P is lower than 2/3 (that is, the number of online verifiers is less than 2/3 of the total), then offline verifiers will be penalized called "inactivity leak".

If the Ethereum 2.0 chain fails to achieve finality for more than 4 epochs, additional penalties will be added such that the maximum possible reward is zero (verifiers who fail to perform operations correctly are penalized), And a second penalty will be added, which will increase proportionally according to how many epochs fail to achieve finality. This is to ensure that if more than 1/3 of the validators go offline, these offline validators will be punished more severely, and this penalty will grow exponentially over time.

This will have three effects:
Offline validators will be penalized more severely, because at this time the validator's offline will actually prevent the block from being finalized;
Serving the goal of "anti-correlation penalty" (explained further below)

Make sure that if more than 1/3 of validators go offline at the same time, the number of validators that eventually come online will recover to 2/3 of the total, because the decreasing deposit of offline validators will cause them to be expelled from the validator ranks.

This means that if 50% of the validators are offline, the block will be finalized again after 21 days, because after 21 days, all offline validators have lost 50% of the deposit (16 ETH), and If the validator's deposit is lower than 16 ETH, he will be expelled from the validator ranks.

text

Slashing & Anti-correlation Penalties

If a validator is found to have violated Casper FFG's slashing conditions, that validator will be penalized (losing a portion of the stake); if other validators are slashed around the same time (specifically, from 18 days before the verifier is punished to the period when the verifier quits the verifier), then the penalty will be three times that of the previous one. This serves several purposes:
Only when a validator misbehaves with many other validators at the same time can the validator's behavior cause real damage to the network, so the penalty in this case will be more severe;
This penalizes the actual attack heavily, but very lightly on individual individual mistakes that may not be malicious;
This inhibits everyone from joining the largest pool of validators.

BLS signature

text

We will use BLS signatures because BLS signatures are aggregation-friendly: a message M is processed by keys k1 and k2 (corresponding public keys K1=G*k1, K2=G*k2, where G is the base point of the elliptic curve). Any two signatures S1 and S2 of can be aggregated simply by elliptic curve point addition: S1+S2. This allows thousands of signatures to be generated, each at a marginal cost of one data bit (to denote the presence of a particular public key in that aggregate signature) and one elliptic curve addition to compute.

We use the signature of the validator's mortgage message as proof of ownership, which specifies the signing key and other important information, such as the withdrawal key.

secondary title

random selection of verifiers<- hash(seed,The seed used to achieve randomness is achieved by "mixing in" a value that the block proposer must reveal (ie, the seed

new_data)) to be updated in each block. Just like the subkey of the escrow proof, the values of the verifier are determined immediately after the verifier makes a pledge, and the third party cannot calculate the subkey, but when the subkey is revealed by the resource Validate it (this mechanism is sometimes called RANDAO).

In the future we plan to use VDFs (Verifiable Delay Functions) to further increase the robustness of randomness seeds against manipulation.

text

Shuffle validators

During each epoch, we use a swap-or-not shuffle [13] to shuffle validators and assign responsibilities. This algorithm ensures that:

Since shuffle is a permutation, each validator is appointed as a member of a long-term committee during each epoch;

text

Crosslinking Committee

During each epoch, each shard will perform a crosslink (crosslink), that is, randomly select 2/3 of the validators from the shard committee (the number of certifiers in each shard committee is about 128). The hash of all the data contained in the shard since the last crosslink is signed (because the crosslink in the shard may fail, the hash can represent the data of the first 64 epochs at most; if there are many consecutive epochs in the shard If the first crosslink fails, it may take multiple successful crosslinks to catch up).

The number of validators per shard committee is set to 128 because this is a minimum number to defend against an attacker accidentally controlling 2/3 of the committee members while controlling less than 1/3 of all validators, By the binomial theorem, the chance of an attacker controlling 2/3 of the committee members is 5.55*10^(-15)

After each epoch (64 blocks, about 6.4 minutes), the beacon chain will reorganize a shard committee for each shard chain (that is, disrupt the validator). The purpose of fast scrambling validators is to ensure that if an attacker wants to attack a shard chain, the attacker will need to quickly destroy (take control of) the shard committee.

text

long term committee

Every 27 hours or so, the system will select a persistent committee for each shard chain. At any point in time, every validator in the Ethereum 2.0 system is a member of one of these long-term committees. Long-term committees are responsible for proposing shard blocks, providing users with some level of guarantee about shard blocks (until the shard block is included in a crosslink), and light clients can rely on long-term committees. To maintain the stability of the P2P network and the efficiency of light clients, long-term committee changes are relatively infrequent (while shard committees are changed every ~6 minutes).

In order to further maintain the stability of the network, not all validators will be rotated from the long-term committee of n time period to the long-term committee of n+1 time period at the same time; instead, the rotation of each validator will be delayed until the next Rotate at a random time point in a period of time.

secondary title

LMD GHOST Fork Selection Rules

The LMD GHOST fork selection rule will combine information from all validators to ensure that under normal circumstances it is impossible for any block to be reversed. Since this fork selection rule relies on all validators, it also ensures that blocks cannot be reversed unless an attacker controls more than 50% of the validators, in which case the attacker cannot gain much by manipulating randomness. big advantage.

secondary title

Beacon Chain/Shard Chain Structure

The structure of the Ethereum 2.0 sharding system consists of a central "beacon chain" that coordinates all activities, and 1024 shard chains. Each shard chain is regularly connected to the beacon chain through a crosslink.

Alternatives to this sharding structure:

(1) Sign the shard blocks through the committee, and put all shard blocks directly into the beacon chain;

(2) There is no beacon chain, but all the shard chains are connected through a certain structure.

The reason why the above structure (1) is abandoned is that it is advisable to set a 6-second time (slot) for the shard chain block, but performing 1024 cross-links on the beacon chain every 6 seconds will lead to The chain is subjected to very high loads.

The reason for the abandonment of the structure in (2) of the appeal is that the hub-and-spoke beacon chain structure is easier to implement and understand than any complex structure.

Shard chain design

Each shard is a semi-independent chain that can process blocks faster than cross-linked aggregated blocks (target 3-6 seconds). This allows transactions to quickly gain some level of confirmation through the shard's long-term committee before being confirmed by the beacon chain (by way of cross-linking).

The structure of the shard chain is such that each block is attested by each verifier of the shard committee, which ensures the simplicity of verification and ensures that the shard block has a fairly high degree of confirmation; large Most applications dealing with lower values should be able to rely on a single confirmation.

At the start of each epoch, each shard block contains a pointer to its parent block and a pointer to the beacon block. This semi-tight coupling between the beacon chain and the shard chain is to (i) ensure that the shard chain knows information about its long-term committee (since this information is generated by the Shard chain blocks are a viable way to decide which chain is the canonical beacon chain.

The shard chain state (rewards, penalties, history accumulators) is deliberately designed to be smaller than the block size in order to ensure that the shard chain state can be fully placed into the beacon chain if fraud proofs require it (although this may only be The limit will be relaxed in phase 2, where the state of each individual execution environment will be limited by this size, but all state combined will be very large, so fraud proofs will require Merkle proofs).

cross-linked data

A crosslink contains data_root, the Merkle root of the data structure containing all shard blocks in a shard since the last crosslink. This crosslink data structure + root has multiple targets:
Let the beacon chain know which are the canonical shard chain blocks;
Create a simple byte array that can be evaluated for fraud proofs.

Validator Lifecycle

pledge

pledge

The verifier performs ETH pledge by sending a transaction (this transaction will call a function of the deposit contract deployed on the Eth1.0 chain), and finally we will add the pledge method on the Eth2.0 chain . This action by the verifier clarifies:
Withdrawal credentials (that is, the public key hash, which will be used to withdraw funds when the verifier completes the verification)
pledge amount
pledge amount
These values are all signed by the signing key. The purpose of separating the signing key from the withdrawal key is to make the more risky withdrawal key more secure (the withdrawal key is offline and will not be shared with any pledge pool, etc. ), and the signing key is used to sign messages during each epoch.

The deposit contract holds the Merkle root of all pledges. Once the Merkle root pledged by the validator is included in the Eth2.0 chain (via the Eth1.0 data voting mechanism), the Eth2.0 block proposer can submit a Merkle proof of the pledge and start the pledge process.

activation

If the total number of existing verifiers in Eth2.0 is |V|, then the maximum number of verifiers that can be added during each epoch will be max(4, |V|/65536); if more verifiers want Join in, then they will need to queue up and the system will process it as fast as possible.

quit

quit

When a validator withdraws from the Eth2.0 system (whether by posting a voluntary exit message or exiting due to slashing), the validator will also need to queue up to withdraw from the system. During each epoch The maximum number of validators that can exit is the same as the maximum number of new validators that can be added as described above.

The reason for this new join/exit queuing limit is to ensure that the total number of validators in the system does not change too quickly between any two points in time, which ensures that as long as validators log in frequently enough (if validators The total number ≥ 262144, then the verifier is guaranteed to be able to log in once every 1-2 months), then it can ensure that there is still certainty between the old and new chains of Ethereum. Related principles refer to [17] and [18].

withdraw money

Once a validator has successfully exited through the queue, there is a waiting period of approximately 27 hours before withdrawals can be made. This wait time has several effects:
This ensures that if the validator misbehaves, there will be time to catch the misbehavior and slash the validator;
This gives the system time to distribute the last period of shard rewards to that validator;

This provides time for a challenge to the Proof of Escrow to be initiated.

During phase 0, validators who want to "withdraw" cannot actually do so; in later phases, they will be able to transfer the funds withdrawn by the validator to an execution environment.

effective balance

Most calculations based on a validator's balance use the validator's "effective balance (EB)"; the only exception is calculations that increase or decrease the validator's balance. Only when the balance B of the verifier is lower than EB or higher than EB+1.5, EB will be adjusted to be equal to floor(B). This is to ensure that the effective balance does not change very often, reducing the amount of hashing required to recompute the state during each epoch; on average, only balances need to be updated, and each validator needs to update the effective balance relatively less .

secondary title

Fork mechanism

The fork data structure contains (i) the current "fork ID", (ii) the previous "fork ID" and (iii) the slot that switched the two forks. The fork ID at the current block height affects the valid signature of all messages; therefore, a message signed with one fork ID is invalid for a verification function using any other fork ID.

Forking can be done by adding a state transition in a "fork slot". The signature verification function will use the fork ID of the slot where the message is located to verify the message. This fork ID may be the previous fork ID or the current fork ID.

Remarks: The translation has been deleted

Links mentioned in the text:

[1]:https://radicalxchange.org/blog/posts/2018-11-26-4m9b8b/

[2]:https://vitalik.ca/general/2018/08/26/layer_1.html

[3]:https://vitalik.ca/general/2019/06/12/plasma_vs_sharding.html

[4]:https://vitalik.ca/general/2018/12/05/cbc_casper.html

[5]:https://medium.com/@aditya.asgaonkar/casper-cbc-simplified-2370922f9aa6

[6]:https://eprint.iacr.org/2015/702.pdf

[7]:https://bitcoin.stackexchange.com/questions/38437/what-is-spv-mining-and-how-did-it-inadvertently-cause-the-fork-after-bip66-wa

[8]:https://twitter.com/VitalikButerin/status/1145576103089602560

[9]:https://eprint.iacr.org/2015/702.pdf

[10]:https://bitcoin.stackexchange.com/questions/38437/what-is-spv-mining-and-how-did-it-inadvertently-cause-the-fork-after-bip66-wa