Numerous intriguing modifications to the Ethereum protocol are underway, which will hopefully enhance the system’s capabilities, introduce additional features such as light-client support and greater extensibility, and simplify the coding of Ethereum contracts. Theoretically, none of these modifications are obligatory; the Ethereum protocol is adequate as it currently exists, and could potentially be launched as is once the clients are developed to a certain extent; rather, the adjustments aim to improve Ethereum. Nonetheless, there is one design goal within Ethereum where the light at the conclusion of the tunnel is somewhat more distant: the decentralization of mining. While we maintain the fallback option of simply continuing with Dagger, Slasher or SHA3, it remains entirely uncertain whether any of those algorithms can genuinely stay decentralized and resistant to mining pools and ASICs in the long haul (Slasher is ensured to be decentralized due to its proof of stake nature, however, it possesses its own moderately significant issues).
The core concept underlying the mining algorithm we aspire to utilize is essentially established; however, as in numerous situations, the nuances lie in the details.
This variant of the Ethereum mining algorithm is a Hashcash-based method, akin to Bitcoin’s SHA256 and Litecoin’s scrypt; the principle is for the miner to continuously calculate a pseudorandom function on a block and a nonce, attempting a different nonce upon each iteration, until eventually a nonce generates a result that starts with a substantial number of zeroes. The only opportunity for innovation within this type of implementation revolves around altering the function; in Ethereum’s instance, the rough structure of the function, using the blockchain state (described as the header, the current state tree, and all the data from the last 16 blocks), is as follows:
-
Let h[i] = sha3(sha3(block_header) ++ nonce ++ i) for 0 <= i <= 15
-
Let S represent the blockchain state from 16 blocks earlier.
-
Let C[i] signify the transaction count of the block i blocks prior. Let T[i] be the (h[i] mod C[i])th transaction from the block i blocks back.
-
Apply T[0], T[1] … T[15] sequentially to S. However, whenever the transaction leads to processing a contract, (pseudo-)randomly implement minor alterations to the code of all involved contracts.
-
Let S’ represent the resulting state. Let r be the sha3 of the root of S’.
If r <= 2^256 / diff, then nonce is a legitimate nonce.
To encapsulate in non-programmatic terms, the mining algorithm necessitates that the miner extracts several random transactions from the last 16 blocks, executes the calculation of applying them to the state 16 blocks prior with a few random changes, and subsequently takes the hash of the outcome. With each new nonce that the miner experiments with, they must repeat this procedure anew, with a fresh set of random transactions and modifications every time.
The advantages of this include:
-
It necessitates the complete blockchain state to mine, effectively requiring every miner to function as a full node. This contributes to network decentralization, as a larger quantity of full nodes exist.
-
Since every miner is now mandated to be a full node, mining pools see a significant reduction in utility. In the Bitcoin landscape, mining pools fulfill two essential roles. Firstly, pools balance the mining rewards; rather than each block granting a miner a 0.0001% chance of mining a
-
It is inherently ASIC-resistant. Since the EVM language is Turing-complete, any computation that can be accomplished in a standard programming language can be expressed in EVM code. Thus, an ASIC capable of executing all of EVM functions is by its nature an ASIC for generalized computation – namely, a CPU. This presents a social benefit akin to Primecoin: the effort spent on developing EVM ASICs also leads to the additional advantage of constructing hardware that enhances the network’s speed.
-
The algorithm is comparatively quick to verify in computational terms, although a “nice” verification formula cannot be executed within EVM code.
Nevertheless, numerous significant obstacles remain. Initially, it remains uncertain whether the method of selecting random transactions truly necessitates the miner’s use of the complete blockchain. Ideally, blockchain accesses would be random; in this scenario, a miner possessing half of the blockchain would only succeed in approximately 1 in 216 nonces. Yet in practice, it’s likely that 95% of transactions will utilize merely 5% of the blockchain; in this arrangement, a node with 5% of the memory might only experience a slowdown penalty of about 2x.
Next, and more crucially, it is challenging to ascertain how much optimization an EVM miner could attain. The aforementioned algorithm definition instructs the miner to “randomly apply minor alterations” to the contract. This component is vital. The rationale is straightforward: most transactions yield results that are autonomous from one another; the transactions may take the form of “A sends to B”, “C sends to D”, “E sends to contract F which influences G and H”, and so forth, with minimal overlap. Consequently, without random alterations, there would be little necessity for an EVM miner to engage in substantial computation; the computation would occur once, and thereafter the miner would simply precompute and archive the deltas, subsequently applying them instantly. The random alterations imply that the miner must engage in new EVM computations each time the algorithm is executed. However, this approach is flawed in two aspects. Firstly, random modifications may easily lead to what could otherwise be complex and detailed calculations concluding prematurely, or at least to calculations where the optimizations differ significantly from those utilized for standard transactions. Secondly, mining algorithms might intentionally bypass intricate contracts in preference for simpler or more readily optimizable ones. There exist heuristic techniques for addressing both issues, but it remains entirely ambiguous what those heuristics would specifically entail.
Another intriguing aspect that supports this type of mining is that even if optimized hardware miners come into existence, the community can collaborate to effectively modify the mining algorithm by “poisoning” the transaction pool. Engineers can scrutinize existing ASICs, identify their optimizations, and inundate the blockchain with transactions that those optimizations simply cannot handle. If 5% of all transactions are effectively poisoned, then ASICs could not possibly achieve a speedup exceeding 20x. The fortunate aspect is that there is a motive for individuals to bear the transaction fees to execute this: each individual ASIC company has the incentive to spoil the well for its adversaries.
These present an array of challenges that we will be intensively addressing in the forthcoming months.
