The Mining Question | Ethereum Foundation Blog

There are many exciting changes to the Ethereum protocol in the works that will hopefully improve the power of the system, add more features such as client ease of use and a higher degree of extensibility, and make Ethereum contracts easier. to code. . In theory, neither of these changes is necessary; the Ethereum protocol is fine as it is today and can theoretically be released as is once the clients develop a bit more; rather, the changes are there to improve Ethereum. However, there is one Ethereum design goal where the light at the end of the tunnel goes a little further: decentralization of mining. Although we always have the backup option of just staying with Dagger, slasher or SHA3, it’s not entirely clear that either of those algorithms can truly remain decentralized and resistant to mining and ASICs in the long term (Slasher is guaranteed to be decentralized because it’s proof-of-stake, but it has its own moderately problematic flaws). .

The basic idea behind the mining algorithm we want to use is essentially in place; 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 that the miner repeatedly computes a pseudorandom function on a block and a nonce, trying a different nonce each time, until eventually some nonce produces a result that starts with a large number of zeroes. The only room for innovation in this type of implementation is to change the function; in the case of Ethereum, the general scheme of the function, taking the state of the block chain (defined as the header, the current state tree and all the data of the last 16 blocks), is the following:

1. Let h(i) = sha3(sha3(block_header) ++ nonce ++ i) for 0 <= I <= 15

2. Let S be the state of blockchain 16 blocks ago.

3. Let C(me) be the transaction count of the block Yo It makes blocks. Let you(me) be the (h(i) modification C(i))th block transaction Yo It makes blocks.

4. Request T(0), T(1) … T(15) sequentially to S. However, each time the transaction leads to the completion of a contract, minor code modifications are (pseudo-)randomly made to all affected contracts.

5. Let Yes be the resulting state. Let r be the sha3 root Yes.

Yes r <= 2^256 / differenceafter in the meantime is a valid nonce.

To summarize in non-programmatic language, the mining algorithm requires the miner to take some random transactions from the last 16 blocks, run the calculation of applying them to the state 16 blocks ago with some random modifications, and then take the hash of the result. Every new nonce that the miner tries, the miner would 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 state of the blockchain to mine, essentially requiring each miner to be a full node. This helps with the decentralization of the network, because there is a greater number of full nodes.

2. Because every miner is now required to be a full node, mining pools become much less useful. In the world of Bitcoin, mining pools serve two key purposes. First, the pools match the mining reward; instead of each block giving a miner a 0.0001% chance of mining a $16,000 blocks, a miner can mine in the pool and the pool gives the miner a 1$

3. It is ASIC resistant almost by definition. Because the EVM language is Turing-complete, any type of computation that can be performed in a normal programming language can be encoded in EVM code. Therefore, an ASIC that can run all of EVM is necessarily an ASIC for pervasive computing, in other words, a CPU. This also has a similar social benefit to Primecoin: the effort put into building the EVM ASIC also has the added benefit of building hardware to make the network faster.

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

However, several major challenges still remain. First, it’s not entirely clear that the random transaction selection system actually ends up requiring the miner to use the entire blockchain. Ideally, accesses to the blockchain would be random; in such a setup, a miner with half the block chain would succeed in only about 1 in 216 nonces. However, in reality, 95% of all transactions will probably use 5% of the blockchain; in such a system, a node with 5% of the memory will only suffer a slowdown penalty of about 2x.

However, secondly, and more importantly, it’s hard to say how much an EVM miner could be optimized. The above algorithm definition asks the miner to “make random minor modifications” to the contract. This part is crucial. The reason is this: most transactions have results that are independent of each other; transactions can be of the form “A sends to B”, “C sends to D”, “E sends to contract F affecting G and H”, etc., without overlap. Thus, without random modification, there would be little need for an EVM miner to do a lot of computation; the calculation would happen once, and then the miner would simply pre-calculate and store the deltas and apply them immediately. Random modifications mean that the miner has to do new EVM calculations every time the algorithm runs. However, this solution is itself imperfect in two ways. First, random modifications can potentially easily result in what would otherwise be very complex and intricate calculations that simply terminate prematurely, or at least calculations for which the optimizations are very different from the optimizations applied to standard transactions. . Second, mining algorithms may deliberately omit complex contracts in favor of simple or easily tunable contracts. There are heuristic tricks to combat both problems, but it’s not entirely clear what exactly those heuristics would be.

Another interesting point in favor of this type of mining is that even if optimized hardware miners emerge, the community has the ability to work together to essentially change the mining algorithm by “poisoning” the pool of transactions. Engineers can analyze existing ASICs, determine what their optimizations are, and dump transactions on the blockchain that such optimizations simply won’t work for. If 5% of all transactions are effectively poisoned, then ASICs cannot be more than 20x speedup. The good thing is that there is a reason why people would pay transaction fees to do this: each individual ASIC company has the incentive to poison the well for its competitors.

These are all challenges that we will be working intensively on in the coming months.