Our current proof-of-work design is Blockchain-based proof of workis the second iteration of our attempt to create a mining algorithm that is guaranteed to be long-term CPU-friendly and resistant to optimization by specialized hardware (ASICs). Our first attempt, Dagger, is a directed acyclic graph (basically, each node has multiple parents). Our current strategy takes a more rigorous direction. In other words, proof of work involves the execution of random contracts from the blockchain. The Ethereum scripting language is Turing-complete, so any ASIC that can run Ethereum scripts is, by definition, his ASIC for general computation. CPU – A much more sophisticated argument than “this is memory intensive, so it can’t be parallelized very much”. Of course, there are questions like “Will I still get significant speedups with certain optimizations?”, but you could argue that those are minor issues that will be resolved over time. This solution is economical and therefore elegant at the same time. Once someone creates his ASIC, others have an incentive to look for types of computations that cannot be performed on his ASIC and “pollute” the blockchain with such contracts. Unfortunately, however, there is generally one obstacle to such plans that is far greater and, unfortunately, somewhat fundamental. It’s a long range attack.
Ranged attacks basically work as follows. A traditional 51% attack involves putting 100 Bitcoins into a new account and sending her 100 Bitcoins to a seller in exchange for an instant-delivery digital product (such as Litecoin). I wait for the delivery (say after 6 confirmations) but immediately start working on a new blockchain from the block 1 block before the transaction that sends 100 Bitcoins and instead transfer those Bitcoins to myself. Execute a transaction to send to. Then they put more mining power into the fork than the rest of the networks combined put into the main chain, and eventually the fork overtakes the main chain and becomes the main chain, and eventually Bitcoin and Litecoin. . For long-range attacks, instead of starting the fork 6 blocks back, start the fork 60000 blocks back, or the Genesis block.
With Bitcoin, such a fork is useless as it only increases the time needed to catch up. However, with blockchain-based proof-of-work, this is a serious problem. The reason is that starting a fork directly from the genesis block will initially slow down mining, but after a few hundred blocks you will be able to fill the blockchain with contracts that are very easy to mine. But for others it is difficult. An example of such a contract is:
If i = 0, sha3(i) != 0x8ff5b6afea3c68b6cd68bd429b9b64a708fa2273a93ea9f9e3c763257affee1f: i = i + 1
Since we know that the contract takes exactly 1 million rounds before the hashes match, we can quickly calculate the number of steps and amount of gas needed to execute and what the final state will be, but others has no choice but to actually run the code. An important characteristic of such a scheme is its inevitable outcome. Stopping problemThat is, building a mechanism to detect such clever contracts in the common case without actually executing them is actually impossible (not impossible in Hollywood, but mathematically provable) . Therefore, long-range attackers could potentially embed such contracts into the blockchain, “mine” them, and trick the network into believing they are doing a large amount of work when in fact they are just taking a shortcut. there is. Therefore, after a few days, the attacker will be “mining” billions of times faster than the main chain and will soon overtake it.
Note that the above attack makes few assumptions about how the algorithm actually works. The conditions for producing a valid block depend on the blockchain itself, and only assume that there is wide variation in the degree to which a single unit of computing power has an impact on the blockchain. One solution is to artificially limit variation. This is done by requesting the computation stack trace of the tree hash along with the contract algorithm. This cannot be produced with a shortcut, because even though we know that the computation will finish after his 1 million steps and will produce a certain output, it still needs to be executed. Generating all intermediate hashes requires performing millions of steps yourself. However, while this solves the long-range attack problem, it also ensures that the main computation is a large SHA3 computation rather than a general computation, making the algorithm once again vulnerable to specialized hardware. Become.
proof of stake
A version of this attack also exists against simply implemented proof-of-stake algorithms. A naively implemented proof of stake assumes that there is an attacker who has 1% of all coins at or immediately after the genesis block. The attacker then starts their own chain and begins mining. Although the probability that an attacker is chosen to generate a block is only 1%, he can easily generate 100 times as many blocks, thus simply creating a longer blockchain . Initially, I thought this issue was a fundamental problem, but it’s actually a workable problem. For example, his one of the solutions is to note that every block must have a timestamp, and users will reject chains with timestamps far earlier than their own. Therefore, a long-range attack must be within the same amount of time, but will have a much lower score because it involves a much smaller amount of monetary units. Another alternative is I need Since at least a certain percentage (say 30%) of all coins is confirmed in every block or every Nth block, all attacks with coins below that percentage are completely prevented. Unique PoS algorithm, slashercan be easily retrofitted using any of these solutions.
Therefore, in the long term, it appears that either pure proof-of-stake or hybrid PoW/PoS is the way forward for blockchain. For hybrid PoW/PoS, we can easily realize the scheme of using PoS to solve the problems mentioned above in BBPoW. Ethereum 1.0 could be Proof of Stake, a hybrid scheme, or boring old SHA3, but manufacturers see no benefit in the impending arrival of SHA3, so no ASICs will be developed. I understand that. Ethereum 2.0. However, there is probably one unresolved issue. It’s a distributed model. Stay tuned for the next part of this series for my own thoughts on that.
