AdLunam

Our current proof of work design, Proof of work based on blockchainis the second iteration of our attempt to create a mining algorithm which is guaranteed to remain user -friendly and resistant to the long -term specialized equipment (ASIC). Our first attempt, Dagger, tried to take the idea of ​​hard algorithms of memory like Scrypt a little further by creating an algorithm which is durable to calculate, but in memory easy to check, using directed acyclic graphics (basically, the trees where each node has several parents). Our current strategy takes a much more rigorous track: to demonstrate work implies the execution of blockchain random contracts. Because the language of Ethereum script is Turing-Complete, an ASIC which can execute Ethereum scripts is by definition an ASIC for general calculation, that is to say. A processor – a much more elegant argument than “it’s hard from memory, so you cannot parallelize as much”. Of course, there are problems of “well, can you make specific optimizations and always obtain great acceleration”, but it can be said that they are minor folds to be developed over time. The solution is also elegant because it is both economical: if someone creates an ASIC, then others will have the incentive to seek types of calculation that the ASIC cannot do and “pollute” the blockchain with such contracts. Unfortunately, however, there is a much more important obstacle to such regimes in general, which is unfortunately fundamental: long -range attacks.

A long -range attack works essentially as follows. In a traditional 51%attack, I put 100 bitcoins in a new new account, then I send these 100 bitcoins to a merchant in exchange for a digital instant delivery property (say, Litecoins). I await delivery (for example, after 6 confirmations), but I immediately start to work on a new blockchain from a block before the transaction sends the 100 bitcoins, and I put a transaction instead of these bitcoins to myself. I then put more operating power in my fork than the rest of the combined network puts in the main chain, and finally my fork exceeds the main chain and thus becomes the main channel, so at the end, I have both bitcoins and Litecoins. In a long -term attack, instead of starting a fork block 6, I start the blocks of the fork 60,000, or even to the Genesis block again.

In Bitcoin, such a fork is useless, because you only increase the time you need to catch up. However, in the proof of work based on blockchain, this is a serious problem. The reason is that if you start a fork directly from the Genesis block, while your mine will be slow at first, after a few hundred blocks, you can fill the blockchain with contracts which are very easy to exploit, but difficult for everyone. An example of such a contract is simply:

I = 0 while Sha3 (i)! = 0x8ff5b6afea3c68b6cd68bd429b9b64a708fa2273a93ea9f9e3c763257avee1f: I = I + 1

You know that the contract will take exactly a million laps before the hash corresponds, so that you can calculate exactly the number of steps and the quantity of gas it will be necessary to execute and what will be the state at the end, but other people will have no choice than to browse the code. A significant property of such a regime, a necessary consequence of the HARTING PROBLEMis that it is in fact impossible (as in, mathematically impossible, and not Hollywood impossible) to build a mechanism to detect such intelligent contracts in the general case without executing them. Consequently, the long -range attack could fill the blockchain with such contracts, “mine” and convince the network that it does a massive amount of work when it is only taking the shortcut. Thus, after a few days, our attacker “will exploit” billions of times faster than the main channel, and will therefore exceed it quickly.

Note that the above attack does not involve how the algorithm actually works; All he supposes is that the condition of production of a valid block depends on the blockchain itself, and there is a wide range of variability in the quantity of influence on the blockchain only one unit of computing power can have. A solution is to artificially cap variability; This is done by requiring a trace of calculation battery wearing trees alongside the contract algorithm, which cannot be generated by the shortcut, because even if you know that the calculation will end after 1 million steps and will produce a certain outing, you must always execute these millions of steps to produce all the intermediate hatches. However, although this solves the long -range attack problem, it also guarantees that the main calculation is not a general calculation, but rather to calculate a lot and a lot of SHA3 – which makes algorithm vulnerable to specialized equipment.

Proof of stake

A version of this attack also exists for evidence of stake proof implemented naively. In proof of participation naively implemented, suppose that there is an attacker with 1% of all the parts soon after the Genesis block. This attacker then begins his own chain and begins to extract him. Although the attacker finds himself selected to produce a block only 1% of the time, he can easily produce 100 times more blocks and simply create a longer blockchain in this way. Originally, I thought that this problem was fundamental, but in reality, it is a problem that can be solved. A solution, for example, consists in note that each block must have timelessness, and users reject the channels with horodatages which are well in advance on theirs. A long -range attack will therefore have to integrate in the same duration, but because it implies a much smaller quantity of exchange units, its score will be much lower. Another alternative is require At least a certain percentage (say, 30%) of all the parts to approve each block or each nème block, thus preventing absolutely all the attacks with less of this percentage of parts. Our own pos algorithm, Slashercan easily be modernized with one or the other of these solutions.

Thus, in the long term, it seems that pure proof of stake or hybrid Pow / PO is the way the blockchains will happen. In the case of a hybrid power / pos, you can easily have a diagram where POS is used to solve the problem described above with BBPOW. What we are going to with Ethereum 1.0 can be proof of participation, it could be a hybrid scheme, and it could be boring Old Sha3, with the understanding that the ASICs will not be developed because the manufacturers would see no advantage for the imminent arrival of Ethereum 2.0. However, there is still a challenge that is probably not resolved: the distribution model. For my own reflections on this subject, stay listening for the next part of this series.