Remote attacks: the critical problem of adaptive workload proof

Editor's Note: This is a blog post published by Vitalik in May 2014 that introduced the concept of Long-Range Attacks (LRAs).

Our current proof-of-work design is a blockchain-based proof-of-work, which is our second attempt to build algorithms that are guaranteed not to burden the CPU and are resistant to dedicated hardware (ASIC) mining in the long run (editor's note: i.e., using ASICs does not significantly improve the advantage in the case of long-term mining). Our first attempt was Dagger, which attempted to build an algorithm that is memory-hard when computing and memory-easy when verifying through directed acyclic graphs (translation: i.e., it takes up a lot of memory when computing but not when verifying), thus further developing the concept of memory-hard algorithms such as Scrypt (which is fundamentally a tree where each node has multiple parents). Our current strategy is much tighter: let the proof-of-work execute random contracts from the blockchain. Since Ethernet uses the Turing-complete scripting language, the ASICs that can execute Ethernet scripts are by definition ASICs for general-purpose computing, or CPUs - which in technical geek terms means "it's memory-hard algorithms, so you can't process too many instructions in parallel". And of course "So can specific optimizations be made (to the ASIC) to make the speed much higher? "and other issues, but these are minor flaws that can be fixed with time. Our solution is clever because it's both affordable: if someone does create an ASIC, that incentivizes others to find the type of computation that that ASIC can't do and flood and pollute the blockchain with those types of contracts. Unfortunately, though, such programs usually face a larger obstacle, and in some ways a fundamental one: remote attacks.

The basic flow of a remote attack operation is as follows。 In the traditional51% Attack in progress， I'll start by putting100 Bitcoins into a brand new account， And then use this.100 A bitcoin to buy a certain digital good for immediate delivery（ As in Litecoin）。 I'm waiting for the seller to deliver（ Let's say we have to wait until6 after the second confirmation）， Immediately afterwards, I took a break from100 A block before the transfer transaction of one bitcoin is concluded starts to build a new blockchain， And resubmit a transaction to transfer those bitcoins back to my account。 later， I used more arithmetic for my fork chain than the remaining network provided to the main chain to mine， Eventually my forked chain overtook and replaced the main chain。 I ended up with both Bitcoin and Litecoin in my pocket。 In a long-range attack， I started to create bifurcations where I no longer advance6 individual block， And it can be done in advance60000 individual block， You can even start with the creation block。

In Bitcoin， This bifurcation is invalid， Because you're just adding to the time it takes to catch up with the main chain in vain。 nevertheless， This is a serious problem for blockchain-based proof-of-work。 Because if you create a fork directly from the creation block， Although your mining process will be slow at first， But after linking a few hundred blocks you'll be able to fill up this blockchain with contracts that can be easily mined， And it's harder than ever for others to tap into these contracts。 About this type of contract， There is a simple example：

You know full well that the contract will go through a whole million rounds of computation before it matches the hash, so you can instantly calculate exactly how many steps the contract will go through in the process, how many gas it will consume, and what state it will end up in, yet no one else has a choice but to actually run the code. The fact that it is impossible to construct a mechanism that can detect such speculative contracts in general without actually running them (which can be proven mathematically here, rather than assuming them out of thin air) is both an important feature of such schemes and a corollary of the downtime problem. Thus, a remote attacker could fill the forked chain with such contracts, "mining" them, obviously taking shortcuts, but convincing the network that he has done a lot of work. Thus, within a few days, our attackers will be mining billions of times faster than the main chain, and their length will soon surpass that of the main chain.

It is important to note that the above attack makes no assumptions about how the algorithm actually works; rather, it only assumes that the conditions for valid block generation depend on the blockchain itself, and that there is wide variability in the degree of influence that can be generated on the blockchain per unit of arithmetic. One solution would be to artificially suppress this variability; this would need to be done via a hash tree computation stack tracing contract algorithm, which would leave no shortcuts because even if you knew that the computation would terminate after a million steps and produce an output value, you would still need to run a million steps yourself to compute all the intermediate hash values. However, while this solves the remote attack problem, it also results in the main computation not being a generic one, but rather the computation of many, many SHA3 hashes - making the algorithm vulnerable to dedicated hardware once again.

certificate of entitlement

There is also a remote attack that is a pure proof-of-interest algorithm. In a pure proof-of-stake. Suppose that the attacker holds 1% of the total number of tokens at or shortly after the creation of the creation block. After that, the attackers start making their own forked chains and start mining them. Although, the attackers had only a 1% chance of being selected to produce blocks at the time, they could easily have created a longer blockchain by generating 100 times the number of blocks. I originally thought this was a fundamental problem, but it is actually solvable in a workaround. For example, one solution is to note that each block must have a corresponding timestamp, and that users resist chains whose timestamps are much earlier than their own timestamps. This way, a long-range attack would have to fit the same length of time, but since it involves far fewer token units, its score would be much lower. Another solution would require at least a percentage of the total token volume (e.g., 30%) to back each block or every Nth block, which would absolutely defend against all attacks with less than that percentage of the token volume. Our own proof-of-interest algorithm, Slasher, can easily be updated to either of these solutions.

So in the long run， simple certificate of entitlement or mixed workload/ certificate of entitlement It all seems to be the way forward for the blockchain。 In the application of mixed workload/ certificate of entitlement in the event that， One can easily find a solution， take advantage of certificate of entitlement to solve the above problems solved through blockchain-based proof-of-work。 as far as sth is concerned Ethereum 1.0， We may use certificate of entitlement， It will probably be a hybrid scenario， Probably still the same old SHA3 algorithm。 We understand. ASIC There will be no development， owing to Ethereum 2.0 imminent，ASIC producers will see this move as unprofitable。 nevertheless， One major challenge remains to be addressed： distributed model。 To see what I think of it， Stay tuned for the next post in the series。

This article was translated and republished with permission from the author by EthFans.

Recommended>>
1、Heres everything you need to know about Markdown for IC Attack Lions
2、Heavy The face recognition capture system is coming soon Pedestrians and nonmotorized vehicles can no longer be left to their own devices
3、成为一名AI工程师永远都不晚
4、Those who havent taken the driving test yet can rest assured that in the future the license may not be required
5、Primer Database qPrimerDB Intrinsic Gene Knowledge Base ICG

已发送

发送中