How Ethereum’s Istanbul Network Upgrade Affects DeFi

Chaz Schmidt
-
Jul 14, 2021
|3 minutes read

At 12:25 AM (UTC) on December 8th, 2019, the Ethereum network mined block 9,069,000 activating the Istanbul network upgrade. Let’s take a look at how the upgrade might affect existing and future DeFi applications.

So what’s changed with the Istanbul Upgrade?

Istanbul included 6 Ethereum Improvement Proposals (EIPs).

EIP-152: Add Blake2 compression function `F` precompile

EIP-152 introduces a new precompiled contract which implements the compression function F used in the BLAKE2b cryptographic hashing algorithm. Put simply, this EIP creates new interoperability and privacy capabilities for Ethereum smart contracts. BLAKE2b allows for efficient verification of the Equihash PoW used in Zcash which means that Ethereum smart contracts could act like SPV clients.

In a nutshell, it’s now possible for DeFi protocols to perform trustless atomic swaps between Ethereum and Zcash, tapping into its inherent privacy features.

EIP-1108: Reduce alt_bn128 precompile gas costs

Changes in 2018 to the underlying library used by the official Go reference implementation led to significant performance gains for precompiled contracts on the alt_bn128 elliptic curve. Logically, performance gains means faster operations on Ethereum clients. And so, EIP-1108 aims to reduce the gas cost for elliptic curve arithmetic precompiles to account for these performance gains.

All in all, DeFi privacy and scaling solutions built on Ethereum which utilize these precompiles cost less gas now. This is a big win for DeFi users because it makes zk-SNARKs cheaper.

EIP-1344: ChainID opcode

Originally introduced in EIP-155 to prevent replay attacks during the ETC hardfork, Chain ID is another way to indicate which blockchain your node or DApp follows. EIP-1344 adds an opcode to Ethereum which returns the current chain’s ID.

Currently, developers must manually hardcode specific chain IDs into their clients, smart contracts, etc. You can probably see how that might lead to human error among other unintended consequences. This EIP now allows EVM-based DeFi applications to verify chain IDs, handle potential network upgrades, and/or mitigate failures, which is particularly useful for layer 2 solutions.

EIP-1884: Repricing for trie-size-dependent opcodes

As the Ethereum network grew, so did the resources required for some opcodes. EIP-1884 raises the gas costs for these opcodes in an attempt to find a balance between operation cost and resources consumed.

This EIP may break smart contracts which were designed around these opcodes and static gas costs. However, the tradeoff is that changing the gas cost prevents contracts from abusing underpriced but highly intensive opcodes and clogging the network.

EIP-2028: Transaction data gas cost reduction

EIP-2028 reduced the gas cost of Calldata from 68 gas per byte to 16 gas per byte. In other words, less gas per byte means more bytes per block resulting scaling benefits from higher calldata bandwidth.

Most of all, DeFi applications and layer 2 solutions using zk-SNARKs and zk-STARKs are now cheaper because of the cost reduction for calling data within transactions. Additonally, layer 2 solutions benefit from a potential throughput increase.

EIP-2200: Net gas metering for SSTORE operations

EIP-2200 implements a structured definition of net gas metering changes for SSTORE opcode. Simply put, it changes the cost calculation of storage in the EVM and will enable contracts to introduce new functions such as re-entry locks and same-contract multi-send.

In general, network upgrades can cause disruptions to node operators

Network upgrades require a lot of coordination to pull off. There’s plenty of room for human error when it comes to making sure each node is upgraded and ready. If a DeFi application relies on a node and then that node becomes desynchronized from the rest of the network, it may prevent you from using certain features or the DApp entirely until the team puts out a fix.

Now that Istanbul’s live, what’s next for the Ethereum network?

Muir Glacier Upgrade’s slated for activation on Block #9,200,000 or rather January 6th, 2020. This upgrade includes one EIP titled, “EIP 2384: Muir Glacier Difficulty Bomb Delay.” As of October 5th, 2019, the difficulty bombed kicked in again slowing Ethereum blocktimes to over 13 seconds on average. As you might have guessed, slower Ethereum blocktimes impacts the performance of DeFi protocols and DApps. And so, EIP-2384 proposes to delay the difficulty bomb for another 4,000,000 blocks (~611 days).

Follow us on Twitter or join us in our Discord to keep up with the DeFi ecosystem