Mining issue Ethereum Foundation Blog

There are a lot of interesting changes to the Ethereum protocol in the works, which will hopefully improve the robustness of the system, add more features such as light client ease and a higher degree of scalability, and make Ethereum contracts easier to program. . In theory, none of these changes are necessary; The Ethereum protocol is fine as it is today, and could theoretically be released as is once the number of clients increases somewhat; Rather, the changes are there to make Ethereum better. However, there is one design goal of Ethereum where the light at the end of the tunnel is a little further: decentralization of mining. Although we always have the backup option of continuing to use Dagger, Slasher or SHA3, it’s not entirely clear that any of these algorithms can remain truly decentralized, mining pool, and ASIC-resistant in the long term (Slasher is guaranteed to be decentralized because it’s proof of stake, but it has its own drawbacks of moderate issues).

The basic idea behind the mining algorithm we want to use is basically there; However, as in many cases, the devil is in the details.

This version of the Ethereum mining algorithm is a Hashcash-based implementation, similar to Bitcoin’s SHA256 and Litecoin’s scrypt; The idea is for a miner to repeatedly compute a pseudorandom function over a block and a number, trying a different number each time, until eventually producing a result that starts with a large number of zeros. The only area for innovation in this type of implementation is in changing the function; In the case of Ethereum, a rough diagram of the function, taking the state of the blockchain (identified by the header, the current state tree, and all data for the last 16 blocks), is as follows:

1. Leave H[i] = sha3(sha3(block_header) ++ nonce ++ i) to 0 <= i <= 15

2. Leave s Become a blockchain state 16 blocks ago.

3. Leave C[i] The number of transactions for the block I blocks ago. Leave T[i] Be the (H[i] v. c[i])Transaction from the block I blocks ago.

4. Progressing T[0], T[1] … T[15] sequentially for s. However, every time a transaction triggers a contract to be processed, minor modifications are (pseudo)randomly made to the code of all affected contracts.

5. Leave s’ The resulting state is . Leave s Sha3 is from the root s’.

if p <= 2 ^ 256 / diffthen nonce It is a valid nonce.

To summarize in non-programming language, the mining algorithm requires the miner to get some random transactions from the last 16 blocks, run a calculation applying them to the state 16 blocks ago with some random modifications, and then take a hash of the results. Every new time the miner tries, he will have to repeat this process again, with a new set of random transactions and modifications each time.

The benefits of this are:

1. It requires the entire blockchain state to mine, essentially requiring each miner to be a full node. This helps decentralize the network, since there are more full nodes.

2. Since each miner is now required to be a full node, mining pools become much less useful. In the world of Bitcoin, mining pools serve two main purposes. First, groups settle the mining reward; Instead of each block providing the miner with a 0.0001% chance of mining a $16,000 blocks, the miner can mine in the pool and the pool gives the miner a 1$

3. They are ASIC resistant almost by definition. Since the EVM language is Turing complete, any type of computation that can be performed in a regular programming language can be encoded in EVM code. Therefore, the ASIC that can power each EVM is necessarily a general compute ASIC – in other words, a CPU. This also has a social benefit similar to Primecoin: the effort spent building EVM ASICs also has the side benefit of building the hardware to make the network faster.

4. The algorithm is relatively computationally fast for verification, although there is no “nice” verification formula that can be run within EVM code.

However, several major challenges remain. First, it is not entirely clear that the system of picking random transactions actually ends up requiring the miner to use the entire block chain. Ideally, access to the blockchain would be random; In such a setup, a miner who owns half the block chain will only succeed with about 1 in 216 numbers. However, in reality, it is likely that 95% of all transactions will use 5% of the blockchain; In such a system, a node with 5% memory would only incur a slowdown penalty of about 2x.

Second, and more importantly, it is difficult to determine how much an EVM miner can be improved. The above algorithm definition asks the miner to “randomly make minor modifications” to the nodes. This part is crucial. The reason is that most transactions have outcomes that are independent of each other; Transactions may be of the form “A sends to B”, “C sends to D”, “E sends to nodes F which affects G and H”, etc., without overlapping. Thus, without random modification, there would be no need for an EVM miner to perform much computation; The calculation will happen once, after which the miner calculates the delta, stores it in advance, and applies it immediately. Random modifications mean that the miner has to perform new EVM calculations every time the algorithm is run. However, this solution in itself is incomplete in two respects. First of all, random adjustments can easily lead to what can be very complex and complex calculations that simply end early, or at least calculations in which the improvements are completely different from the improvements applied to standard coefficients. Second, mining algorithms may intentionally skip complex contracts in favor of simple or easily improved contracts. There are heuristics to combat both problems, but it is not entirely clear what they are.

Another interesting point in favor of this type of mining is that even if hardware-optimized miners emerge, the community has the potential to work together to fundamentally change the mining algorithm by “poisoning” the transaction pool. Engineers can analyze existing ASIC chips, identify improvements to them, and dump transactions into the blockchain for which such improvements do not work. If 5% of all transactions are effectively poisoned, it is not possible for ASICs to have a speedup of more than 20x. The nice thing is that there’s a reason people pay transaction fees to do this: each individual ASIC company has an incentive to poison the well for its competitors.

These are all challenges that we will work on intensively in the next few months.