There are many exciting changes to the Ethereum protocol in the works. This improves system performance, adds additional features such as light client friendliness and a higher level of scalability, and makes it easier to code Ethereum contracts. . In theory, this change is not necessary. The Ethereum protocol is fine as is and could theoretically be released as-is once more clients are built out. Rather, there are changes to make Ethereum better. However, there is a bit more light at the end of the tunnel: Ethereum’s design goal is to decentralize mining. Although there is always the backup option to still use Dagger, slasher or SHA3, it is completely unclear whether any of these algorithms can remain decentralized and mining pool and ASIC resistant in the long run (Slasher is proof-of-stake, so decentralization is guaranteed, but it has its own flaws that make it slightly problematic).
The basic idea of the mining algorithm we are going to use is essentially established. But as with many things, 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 computes a pseudo-random number function over blocks and nonces repeatedly, trying a different nonce each time, eventually producing a result where some nonces start with a large number of zeros. The only room for innovation in this kind of implementation is to change functionality. For Ethereum, a high-level outline of the function that takes the blockchain state (defined as the header, current state tree, and all data from the last 16 blocks) is as follows:
Permit h(i) = sha3(sha3(block_header) ++ nonce ++ i) for 0 <= me <= 15
Permit S The blockchain state must be 16 blocks ago.
Permit C(i) Number of transactions in block me Before the block. Permit t(i) be (h(i) mode C(i))first transaction of block me Before the block.
apply T(0), tee(1) … T(15) Sequentially S. However, whenever a transaction leads to contract processing, it (pseudo) makes small random modifications to the code of all affected contracts.
Permit S’ This will be the result state. Permit R Become root’s sha3 S’.
If the r <= 2^256 / differenceThen now A valid nonce.
To summarize in non-programming language, the mining algorithm requires the miner to take a few random transactions from the last 16 blocks, run a calculation that applies them to the state 16 blocks ago with some random modifications, and then get the hash. result. Every new nonce a miner tries, they have to repeat this process again, each time with a new set of random transactions and modifications.
The benefits of this are:
Mining requires the entire blockchain state, essentially requiring all miners to be full nodes. This helps decentralize the network because there is a greater number of full nodes.
Mining pools are now much less useful because every miner must be a full node. In the Bitcoin world, mining pools serve two main purposes. First, mining rewards are distributed equally. Instead of every block giving miners a 0.0001% chance to mine. 1.60. Second, the pool also provides centralized block validation. Instead of running a full Bitcoin client directly, miners can pull block header data from the pool and use that data to mine without actually verifying the block themselves. With this algorithm, the second claim is debatable and the first concern can be appropriately satisfied through a P2P pool that leaves a significant portion of the network hash power uncontrolled by a centralized service.
By definition they are almost ASIC resistant. Because the EVM language is Turing-complete, any kind of computation that can be performed in a regular programming language can be encoded in EVM code. Therefore, an ASIC that can run both EVMs is necessarily an ASIC for generalized computation, i.e. a CPU. This also has similar social benefits to Primecoin. The effort spent building an EVM ASIC also has the side benefit of building hardware to make the network faster.
Although there is no “good” verification formula that can be run within EVM code, the algorithm can be verified relatively quickly computationally.
However, several major challenges still remain. First, it is not entirely clear whether a system that selects random transactions actually requires miners to use the entire blockchain. Ideally, blockchain access is random. In this setup, a miner holding half of the blockchain will succeed on only about 1 in 216 nonces. But in reality, 95% of all transactions will likely use 5% of the blockchain. In these systems, a node with 5% memory only suffers a slowdown penalty of about 2x.
Second, but more importantly, it is difficult to say how optimized EVM miners can be. The algorithm definition above asks miners to make “random minor modifications” to the contract. This part is important. Here’s why: Most transactions have outcomes that are independent of each other. Transactions may not have overlapping formats such as “A sends to B”, “C sends to D”, “E sends to contract F affecting G and H”, etc. So, without random modifications, the EVM miner rarely needs to actually perform much computation. The calculation is performed only once, and the miner pre-calculates the delta, stores it, and applies it immediately. Random modifications mean that miners actually have to perform new EVM calculations every time the algorithm runs. However, this solution itself is incomplete in two ways. First of all, random modifications can easily cause very complex and complex calculations to simply terminate prematurely, or at least have optimizations that are very different from those applied to standard transactions. Second, mining algorithms may intentionally skip complex contracts in favor of simple or easily optimizable contracts. There are heuristics for solving both problems, but it is not entirely clear what exactly these heuristics are.
Another interesting thing that favors this type of mining is that even if optimized hardware miners emerge, the community can work together to essentially change the mining algorithm by “poisoning” the transaction pool. Engineers can analyze existing ASICs, determine what the optimizations are, and dump transactions on the blockchain for which those optimizations are not working. If 5% of all transactions are effectively tainted, the speed of an ASIC cannot be improved by more than 20x. The good thing is that there is a reason why people pay transaction fees for this. Each individual ASIC company has an incentive to poison its competitors’ wells.
These are all challenges we will be focusing our efforts on in the coming months.