🦚 Istanbul Hardfork — Issue No. 76

📰News

By the time this newsletter reaches your inbox, the Ethereum network's "Istanbul" hardfork will be several hours in the past. If all goes smoothly, the upgrade will bring a number of low level improvements to the network, including two changes that can be leveraged by developers to enhance privacy. Also noteworthy in this release is whats not going to be included. Let’s dive into Istanbul, looking at what's in it, what's not in it, and why these upgrades are important.

Privacy Precompiles

Two of the changes being included in this upgrade have to do with so-called "pre-compile" functions. Pre-compiles in the Ethereum Virtual Machine (EVM) are hash functions that would normally be too expensive to implement directly in a smart contract. Instead, these functions are implemented in the client software, and are thus made available for smart contract developers as native operations in the EVM.

Ethereum Improvement Proposal (EIP) 1108 lowers the fee for executing the existing "alt_bn128" hash function, since most Ethereum clients now include an optimized implementation. This particular pre-compiled hash function is useful when implementing private token transfers via zero knowledge proofs. One project which does just this, the Aztec Protocol, is already live on mainnet. With the gas fee reduction, private token transfers via Aztec will become much more affordable. Link.

Speaking of zero knowledge proofs, you've probably heard about them in the context of Zcash. As you might know, Zcash is a fork of the Bitcoin codebase that uses zero knowledge proofs to enable shielded transactions on its network. It so happens that another Istanbul upgrade, EIP-152, adds a pre-compile for BLAKE2, which is the hash function used for mining Zcash. Why is this important? It makes it feasible to process Zcash block headers efficiently in Ethereum smart contracts, which should eventually enable a trust-minimized bridge between the two networks to be built. Link.

Gas Controversies

Of the remaining EIP's, most are devoted to repricing fees charged to execute certain low level smart contract operations. For the most part, the changes are arcane and uncontroversial, with the exception of EIP-1884. That EIP increases the cost of accessing certain data stored in the Ethereum network's state. Yes, that is arcane, but it's not uncontroversial. That's because the change can break smart contracts that hardcode assumptions about gas costs, but work on the network today. Link.

Smart contracts, you'll remember, can't be changed once they're deployed (unless the developer specifically includes code which makes it possible to upgrade). This is part of what makes smart contracts interesting: no one can change the rules of the system, not even the people who created it. It also presents a major problem if the network changes in a way that breaks a contract after it's deployed. That's what's happening here.

This isn't just a theoretical risk. Quite a few contracts that will break have been identified on the Ethereum mainnet. Many have ways of mitigating the issues, but it's yet to be seen just how much disruption this will cause. Ethereum core devs have offered vague promises to "fix" any issues that arise in a future hardfork. That seems like a risky commitment to make. Still, the consensus seems to be that the changes are important for the healthy functioning of the network, and thus worth the potential turmoil. Link.

Kicking The Can

While EIP-1884 may be a tad controversial, the most contentious change by far is the one not being included in Instanbul: switching the network's mining algorithm. When planning for this hardfork began, many anticipated a long-debated change to the ProgPoW mining algorithm would be included. For now, though, that change— and the fractious debate around it— has been tabled for a future hardfork. Link.

Ethereum currently use the “Ethash” mining algorithm. Ethash was designed to prevent the development of specialized mining hardware. Despite this, specialized hardware for mining Ethash was eventually created. It’s now widely accepted that a large fraction of Ethereum’s hashrate comes from industrial farms of such machines, like the A10 Ethmaster, pictured below.


Some argue that specialized hardware leads to mining centralization, and puts the network at risk for collusion based attacks by top miners. ProgPoW supporters want to "fix" this by deploying the new algorithm which is, once again, designed to be resistant to the development of specialized hardware. Proponents argue it's needed to protect the network from centralization. Detractors argue it's a risky change that might not even succeed in its goal, and isn't necessary anyway, with Ethereum 2.0's planned shift to Proof-of-Stake. Link.

Alarming Oversights

Another change that didn't make it into the Istanbul hardfork? A delay to the so-called "difficulty bomb." The difficultly bomb is a pre-programmed slow down in the network's block production caused by a gradual increase in the threshold miners must reach to produce a new block. The "bomb" is hardcoded into the protocol to prevent community stagnation— without a hardfork, the network will eventually grind to a halt. Thomas Jay Rush, of TrueBlocks, put together an excellent write up on how the "bomb" works. Link.

Incredibly, it seems everyone just forgot to include a delay to difficulty bomb in Istanbul, despite the fact it's "hiding" in plain sight. Another small hardfork, codenamed Muir Glacier, will occur sometime in the near future to diffuse the bomb. Link.

One more alarming oversight was luckily caught only two days before the hardfork. Parity, one of the two major Ethereum clients, was missing a configuration parameter specifying at which block number to enact one of the consensus changes. Without that setting, Parity would have behaved differently from other clients, causing a chainsplit. Link.

💡Commentary

Early this year, I wrote that the Istanbul upgrade would be a major stress test for Ethereum's governance. In addition to the daunting number of proposals submitted for consideration, the community faced two contentious debates around EIP-1884 and ProgPoW. So, if it was a test, how did the community fare?

It's hard to say.

On the positive side, the core developers succeeded in whittling down nearly thirty proposals to the ones that were seen as most important. The community also came to rough consensus around the necessity of EIP-1884, despite the risk it entails, without too much drama.

Still, on the biggest governance challenge it faced, the community punted. The debate around ProgPoW is far from over. The change is tentatively slated for the next upgrade hardfork, codenamed Berlin, which will occur sometime in 2020. You can expect things to get heated in the lead up to that change, and there's still a small-but-non-zero chance it leads to a chainsplit.

All that said, if the Istanbul hardfork executes without any technical issues, it will be a win for Ethereum. The changes aren't sexy, but they're useful. The privacy improvements and potential interop with Zcash are especially welcomed. On top of that, Ethereum 2.0 has hit some important milestones in recent weeks. You can expect more on that in future issues of this newsletter. Suffice it to say, 2020 is shaping up to be an important year for Ethereum, and for the broader crypto ecosystem as a whole!