Privacy and Scaling-Focused EIPs Accepted for Ethereum Istanbul Hard Fork

With community partners, Keep Network brings privacy-preserving technology to EVM

Published in

Keep Network

5 min readSep 4, 2019

The next Ethereum blockchain hard fork, Istanbul, is coming up fast, and it is set to include two Ethereum Improvement Proposals (EIPs) that Keep has contributed to and developed. These two proposals, EIP 152 and EIP 1108, help to improve the scalability of the Ethereum blockchain.

In this post, I’ll go over why we created (for EIP 1108) or picked up (for EIP 152) these proposals, and the specific ways they will help improve Ethereum.

EIP 152: BLAKE2b `F` compression function precompile

EIP 152 has been in development since October 2016, when Tjaden Hess opened an issue that suggested augmenting the Ethereum consensus layer with native support for the BLAKE2b algorithm, allowing “efficient verification of the Equihash PoW used in Zcash to make a BTC Relay-style SPV client possible on Ethereum.” This improvement was to take the form of a precompile that allowed a writing Solidity BLAKE2b implementation with considerably cheaper gas costs compared to an implementation without the precompile.

Zooko Wilcox, CEO of the Electric Coin Company, developers of Zcash, supported the initial EIP efforts. As he put it, EIP 152 would allow “BTC Relay-style interoperation between the Zcash and Ethereum blockchains.”

“I’m excited about the potential of enabling developers and users to combine the programmability of Ethereum with the unparalleled privacy of Zcash,” Zooko said. “Upgrading Ethereum with EIP 152 in Istanbul is a necessary piece of building that kind of side-chaining between Ethereum and Zcash.”

We focused our attention on EIP 152 in July, to take it from the idea stage to a feasible minimum feature, that could be implemented in time for the Istanbul hard fork. Piotr Dyraga, our Tech Lead, also built out an initial implementation for go-ethereum, and ran benchmarks to help set the gas price for the precompile.

Our team also looked at EIP 131, which suggested implementing the BLAKE2b hash function directly, rather than just its F compression function. After discussion with recent EIP authors and the Zcash team, it was decided that, although more developer-friendly, this approach was less flexible than narrowly targeting the F function. Indeed, the F precompile will allow implementation of other variants of the BLAKE2 algorithm, enabling a wider set of use cases.

For EIP 152, Keep team members and others (including zooko, James hancock, Daira Hopwood, and James Prestwich) pursued a direct BLAKE2b F compression function precompile. EIP 152 was accepted into Istanbul during Ethereum core devs meeting #63, and Piotr’s implementation for go-ethereum was merged on August 22nd.

As the need for cross-chain interoperability becomes increasingly apparent, Ethereum and its smart contracts can become a natural coordinating point between other chains, provided that the appropriate operations are made accessible to its broad developer base. EIP 152 lets us realize this possibility for ZCash and other BLAKE2-based chains.

EIP 1108: Reducing gas costs for certain curve operations

In collaboration with the AZTEC team, we’ve also been working to lessen Ethereum network fees in EIP 1108, which proposes reducing alt_bn128 gas costs for the ecadd, ecmul, and pairing check precompiles. These precompiles are used to run elliptic curve arithmetic operations, that are central in several common signing algorithms like BLS, and we considered them to be currently overpriced. Repricing the precompiles greatly supports a number of Ethereum privacy and scaling solutions. EIP 1108 was accepted into Istanbul during Ethereum core devs meeting #65, and my implementation for go-ethereum was merged on August 6th.

These reduced gas costs connect to our development work at Keep as well—we’re leveraging verification of BLS threshold signatures directly on-chain for our random beacon. The EIP makes this cheaper, and unlocks a variety of other potential use cases that were previously too expensive to fit into a single Ethereum block.

Detailed in the EIP’s abstract, there were significant performance gains for the ecadd, ecmul, and pairing check precompiled contracts on the alt_bn128 elliptic curve after changes were made to the underlying library in go-ethereum. Around the same time, similar performance improvements landed in the Parity client as well. The EIP, initially written by me and more recently moved forward by Zac Williamson (CTO at AZTEC), notes that within the Parity client, these improvements to field operations used by the precompile algorithms brought a considerable increase in speed. This improved performance in Ethereum clients therefore needed to be reflected in reduced gas costs.

“Reducing the costs of these precompiles allows for more advanced zero-knowledge proofs to be used within smart contracts. This, in turn, will make it easier to deploy scaling solutions and privacy solutions to Ethereum,” Zac said. “For AZTEC, it brings the gas costs of private token transfers down to a level that is comparable to regular ERC20 token transfers.”

Less costly elliptic curve cryptography will have significant benefits for existing protocols. The EIP lists several specific projects built on Ethereum whose protocols would benefit from a reduction in the gas cost of precompiles including AZTEC, Matter Labs, roll_up, and Zether.

Dedicated to the preservation of privacy

Both of these EIPs were driven by a desire to improve interactions with private data on Ethereum. One of the most prohibitive aspects with respect to privacy on Ethereum is the high cost of certain encryption operations, and both EIPs took direct aim at reducing this cost. With these changes, Ethereum will unlock new possibilities around random beacons, private token transfers, private computations, and cross-chain interoperability with Zcash, the foremost privacy-protecting digital currency.