Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft BLAKE2b precompile EIP #131

Closed
wants to merge 21 commits into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
75 changes: 75 additions & 0 deletions EIPS/eip-9.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,75 @@
### Title

Title: Add precompiled BLAKE2b contract
Author: Tjaden Hess & Jay Graber
Status: Draft
Type: Standard Track
Layer: Consensus (hard-fork)
Created 2016-06-30

## Abstract

This EIP introduces a new precompiled contract which implements the BLAKE2b cryptographic hashing algorithm.

## Motivation

BLAKE2b is a useful addition to Ethereum's cryptographic primitives. BLAKE2b is faster and more efficient than the SHA hash functions, making it a good complement or alternative to SHA-3. The BLAKE2b algorithm is highly optimized for 64-bit CPUs, and is faster than MD5 on modern processors. Its inclusion will also improve interoperability between the Zcash blockchain and the EVM, and assist in future integration with IPFS, as they are working on switching their default hash function to BLAKE2b.

One BLAKE2 digest in Solidity, (see https://github.com/tjade273/eth-blake2/blob/optimise_everything/contracts/blake2.sol) currently requires `~480,000 + ~90*INSIZE` gas, and a single verification of an [Equihash](https://www.internetsociety.org/sites/default/files/blogs-media/equihash-asymmetric-proof-of-work-based-generalized-birthday-problem.pdf) PoW verification requires 2<sup>5</sup> to 2<sup>7</sup> iterations of the hash function, making use cases such as verification of Zcash block headers prohibitively expensive. However, an efficient implementation of BLAKE2b could allow verification of the Equihash PoW used in Zcash, making a BTC Relay - style SPV client possible on Ethereum.

Adding a precompile for the BLAKE2b hashing function will make the operation significantly faster and cheaper, improving usability.

## Parameters

* `METROPOLIS_FORK_BLKNUM`: TBD
* `GBLAKEBASE`: 30
* `GBLAKEWORD`: 6

## Specification

Adds a precompiled contract for the blake2b hash function.

Address of `0x9`

Function accepts a variable length input interpreted as:

[OUTSIZE, D_1, D_2, ..., D_INSIZE]

where `INSIZE` is the length in bytes of the input. Throws if `OUTSIZE` is greater than 64. Returns the `OUTSIZE`-byte BLAKE2b digest, as defined in [RFC 7693](https://tools.ietf.org/html/rfc7693).

### Gas Costs

Gas costs would be equal to `GBLAKEBASE + GBLAKEWORD * floor(INSIZE / 32)`

## Rationale

The most frequent concern with EIPs of this type is that the addition of specific functions at the protocol level is a deviation from Ethereum's "featureless" design. It is true that a more elegant solution to the issue is to simply improve the scalability characteristics of the network so as to make calculating functions requiring millions of gas practical for everyday use. In the meantime, however, I believe that certain operations are worth subsidizing via precompiled contracts. There is significant precedent for this change, most notably the inclusion of the SHA256 precompiled contract, which is included largely to allow inter-operation with the Bitcoin blockchain.

Additionally, BLAKE2b is an excellent candidate for precompilation because of the extremely asymmetric efficiency which it exhibits. BLAKE2b is heavily optimized for modern 64-bit CPUs, specifically utilizing 24 and 63-bit rotations to allow parallelism through SIMD instructions and is little-endian. These characteristics provide exceptional speed on native CPUs: 3.08 cycles per byte, or 1 gibibyte per second on an Intel i5.

In contrast, the big-endian 32 byte semantics of the EVM are not conducive to efficient implementation of BLAKE2, and thus the gas cost associated with computing the hash on the EVM is disproportionate to the true cost of computing the function natively.

Note that the function can produce a variable-length digest, up to 64 bytes, which is a feature currently missing from the hash functions included in the EVM.

## Backwards Compatibility

There is very little risk of breaking backwards compatibility with this EIP, the sole issue being if someone were to build a contract relying on the address at `0x000....0000c` being empty. The likelihood of this is low, and should specific instances arise, the address could be chosen to be any arbitrary value, with negligible risk of collision.

In order to maintain backwards compatibility, the precompile will return `0` if `CURRENT_BLOCKNUM < METROPOLIS_FORK_BLKNUM`

The community response to this EIP has been largely positive, and besides the "no features" issue, there have as yet been no major objections to its implementation.

## Test Cases


## Implementation

The Go implementation is available from [golang.org](golang.org/x/crypto/blake2b) as well as [on github](https://github.com/dchest/blake2b).

Other languages:
[Javascript implementation](https://github.com/dcposch/blakejs)
[Java implementation](https://github.com/alphazero/Blake2b)
[Python implementatoin](https://github.com/buggywhip/blake2_py)

## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).