From 230647f536a856e935c603d30b110096e52212a2 Mon Sep 17 00:00:00 2001 From: Tjaden Hess Date: Thu, 30 Jun 2016 10:45:51 -0400 Subject: [PATCH 01/19] Start new EIP --- EIPS/eip-9.md | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 EIPS/eip-9.md diff --git a/EIPS/eip-9.md b/EIPS/eip-9.md new file mode 100644 index 00000000000000..9c22aae58e622d --- /dev/null +++ b/EIPS/eip-9.md @@ -0,0 +1,9 @@ +### Title + + EIP: 9 + Title: Add precompiled contracts for blockchain interoperability + Author: Tjaden Hess + Status: Draft + Type: Standard Track + Layer: Consensus (hard-fork) + Created 2016-06-30 From 585958c16b0f0f3c192940c210b663770a728c60 Mon Sep 17 00:00:00 2001 From: Tjaden Hess Date: Thu, 30 Jun 2016 11:05:33 -0400 Subject: [PATCH 02/19] Add abstract and specification --- EIPS/eip-9.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/EIPS/eip-9.md b/EIPS/eip-9.md index 9c22aae58e622d..a55a68128aaf3e 100644 --- a/EIPS/eip-9.md +++ b/EIPS/eip-9.md @@ -7,3 +7,19 @@ Type: Standard Track Layer: Consensus (hard-fork) Created 2016-06-30 + +### Abstract + +This EIP introduces several new "precompiled contracts" designed to provide interoperability between the Ethereum network and various other blockchains by enabling the construction of efficient BTC Relay- like SPV clients on top of the EVM. + +### Specification + +EVM implementations should support 2 new precompiled contracts at addresses 5 and 6, respectively. The contract at address 5 implements the Scrypt KDF with parameters + + N = 1024 + r = 1 + p = 1 + salt = input + 256 bit digest length + +which are notably used in Litecoin and its derivatives. The contract at address 6 should implement the BLAKE2b hash function, a Password Hashing Competition finalist most notably used Proof of Work function for Zcash. From ae2a9ef89bc5ea004cf1f5464569d722d8105576 Mon Sep 17 00:00:00 2001 From: Tjaden Hess Date: Mon, 11 Jul 2016 11:07:28 -0400 Subject: [PATCH 03/19] Add specification and rationale --- EIPS/eip-9.md | 42 ++++++++++++++++++++++++++++++++++-------- 1 file changed, 34 insertions(+), 8 deletions(-) diff --git a/EIPS/eip-9.md b/EIPS/eip-9.md index a55a68128aaf3e..09b02508edb61c 100644 --- a/EIPS/eip-9.md +++ b/EIPS/eip-9.md @@ -10,16 +10,42 @@ ### Abstract -This EIP introduces several new "precompiled contracts" designed to provide interoperability between the Ethereum network and various other blockchains by enabling the construction of efficient BTC Relay- like SPV clients on top of the EVM. +This EIP introduces a new precompiled contract which implements the BLAKE2b cryptographic hashing algorithm, for the purpose of allowing interoperability between the Zcash blockchain and the EVM. + +### Parameters + +* `METROPOLIS_FORK_BLKNUM`: TBD +* `GBLAKEBASE`: 30 +* `GBLAKEWORD`: 6 ### Specification -EVM implementations should support 2 new precompiled contracts at addresses 5 and 6, respectively. The contract at address 5 implements the Scrypt KDF with parameters +Adds a precompile at address `0x0000....0c` which accepts a variable length input interpreted as + + [INSIZE, OUTSIZE, D_1, D_2, ..., D_INSIZE] + + + where `INSIZE` is the length in words of the input. If the bytes of data provided is fewer than `INSIZE`, remaining bytes are assumed to be zero, extra bytes are ignored. 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 would be equal to `GBLAKEBASE + GBLAKEWORD * INSIZE` + +### Rationale + +Besides being a useful cryptographic hash function and SHA3 finalist, BLAKE2b allows for efficient verification of the Equihash PoW used in Zcash, making a BTC Relay - style SPV client possible on Ethereum. One BLAKE2 digest in Soldity, (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 25 to 27 iterations of the hash function, making verification of Zcash block headers prohibitively expensive. + +The BLAKE2b algorithm is highly optimised for 64-bit CPUs, and is faster than MD5 on modern processors. + +Interoperability with Zcash would enable trustless atomic swaps between the chain, which could provide a much needed aspect of privacy to the very public Ethereum blockchain. + +Other functions useful for cross-chain interoperability, such as the Scrypt KDF, should also be considered for inclusion. + +# Implementation - N = 1024 - r = 1 - p = 1 - salt = input - 256 bit digest length +There are public-domain BLAKE2b libraries in most languages: -which are notably used in Litecoin and its derivatives. The contract at address 6 should implement the BLAKE2b hash function, a Password Hashing Competition finalist most notably used Proof of Work function for Zcash. +* [Go](https://godoc.org/github.com/codahale/blake2#pkg-files) +* [Python](https://github.com/dchest/pyblake2) +* [Rust](https://github.com/cesarb/blake2-rfc) +* [JavaScript](https://github.com/ludios/node-blake2) +* [Java](https://github.com/alphazero/Blake2b) +* [C++](https://github.com/BLAKE2/BLAKE2) From 2fed08bc995f98df171360aafa7c31269bc99848 Mon Sep 17 00:00:00 2001 From: Tjaden Hess Date: Mon, 11 Jul 2016 12:15:55 -0400 Subject: [PATCH 04/19] Add rationale --- EIPS/eip-9.md | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/EIPS/eip-9.md b/EIPS/eip-9.md index 09b02508edb61c..a1e79fe570f8e7 100644 --- a/EIPS/eip-9.md +++ b/EIPS/eip-9.md @@ -1,7 +1,7 @@ ### Title EIP: 9 - Title: Add precompiled contracts for blockchain interoperability + Title: Add precompiled BLAKE2b contract Author: Tjaden Hess Status: Draft Type: Standard Track @@ -29,23 +29,26 @@ Adds a precompile at address `0x0000....0c` which accepts a variable length inpu Gas costs would be equal to `GBLAKEBASE + GBLAKEWORD * INSIZE` -### Rationale +In order to maintain backwards compatibility, the precompile will return `0` if `CURRENT_BLOCKNUM < METROPOLIS_FORK_BLKNUM` + +### Motivation Besides being a useful cryptographic hash function and SHA3 finalist, BLAKE2b allows for efficient verification of the Equihash PoW used in Zcash, making a BTC Relay - style SPV client possible on Ethereum. One BLAKE2 digest in Soldity, (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 25 to 27 iterations of the hash function, making verification of Zcash block headers prohibitively expensive. The BLAKE2b algorithm is highly optimised for 64-bit CPUs, and is faster than MD5 on modern processors. -Interoperability with Zcash would enable trustless atomic swaps between the chain, which could provide a much needed aspect of privacy to the very public Ethereum blockchain. +Interoperability with Zcash would enable trustless atomic swaps between the chains, which could provide a much needed aspect of privacy to the very public Ethereum blockchain. + +### Rationale + +The most frequent concern with EIPs of this type is that the addition of specific functions at the protocol level is an infringement on 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 subsidising via precompiled contracts and there is significant precedent for this, most notably the inclusion of the SHA256 prcompiled contract, which is included largely to allow interoperation with the Bitcoin blockchain. + +Additionally, BLAKE2b is an excellent candidate for precompilation because of the extremely asymetric 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. -Other functions useful for cross-chain interoperability, such as the Scrypt KDF, should also be considered for inclusion. +In contrast, the big-endian 32 byte semantics of the EVM are not conducive to efficent 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. -# Implementation +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 and is an important component in the Equihash PoW algorithm. -There are public-domain BLAKE2b libraries in most languages: +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. Te likelihood of this is low, and should specific instances arise, the address could be chosen to be any arbitrary value, with negligble risk of colllision. -* [Go](https://godoc.org/github.com/codahale/blake2#pkg-files) -* [Python](https://github.com/dchest/pyblake2) -* [Rust](https://github.com/cesarb/blake2-rfc) -* [JavaScript](https://github.com/ludios/node-blake2) -* [Java](https://github.com/alphazero/Blake2b) -* [C++](https://github.com/BLAKE2/BLAKE2) +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. From 9044f994a3e631980f5f8f53a767fe25be487676 Mon Sep 17 00:00:00 2001 From: Tjaden Hess Date: Mon, 11 Jul 2016 12:18:03 -0400 Subject: [PATCH 05/19] Spelling fixes --- EIPS/eip-9.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/EIPS/eip-9.md b/EIPS/eip-9.md index a1e79fe570f8e7..0114f2931a2c48 100644 --- a/EIPS/eip-9.md +++ b/EIPS/eip-9.md @@ -35,20 +35,20 @@ In order to maintain backwards compatibility, the precompile will return `0` if Besides being a useful cryptographic hash function and SHA3 finalist, BLAKE2b allows for efficient verification of the Equihash PoW used in Zcash, making a BTC Relay - style SPV client possible on Ethereum. One BLAKE2 digest in Soldity, (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 25 to 27 iterations of the hash function, making verification of Zcash block headers prohibitively expensive. -The BLAKE2b algorithm is highly optimised for 64-bit CPUs, and is faster than MD5 on modern processors. +The BLAKE2b algorithm is highly optimized for 64-bit CPUs, and is faster than MD5 on modern processors. Interoperability with Zcash would enable trustless atomic swaps between the chains, which could provide a much needed aspect of privacy to the very public Ethereum blockchain. ### Rationale -The most frequent concern with EIPs of this type is that the addition of specific functions at the protocol level is an infringement on 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 subsidising via precompiled contracts and there is significant precedent for this, most notably the inclusion of the SHA256 prcompiled contract, which is included largely to allow interoperation with the Bitcoin blockchain. +The most frequent concern with EIPs of this type is that the addition of specific functions at the protocol level is an infringement on 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 subsidising via precompiled contracts and there is significant precedent for this, most notably the inclusion of the SHA256 prcompiled 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 asymetric 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 efficent 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. +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 and is an important component in the Equihash PoW algorithm. -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. Te likelihood of this is low, and should specific instances arise, the address could be chosen to be any arbitrary value, with negligble risk of colllision. +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. Te 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. 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. From 57f250445c26e8ae9416a2e075a4c7165a4f24e8 Mon Sep 17 00:00:00 2001 From: Tjaden Hess Date: Mon, 11 Jul 2016 12:26:48 -0400 Subject: [PATCH 06/19] Remove EIP number until assignment --- EIPS/eip-9.md | 1 - 1 file changed, 1 deletion(-) diff --git a/EIPS/eip-9.md b/EIPS/eip-9.md index 0114f2931a2c48..3308f6fbae6b62 100644 --- a/EIPS/eip-9.md +++ b/EIPS/eip-9.md @@ -1,6 +1,5 @@ ### Title - EIP: 9 Title: Add precompiled BLAKE2b contract Author: Tjaden Hess Status: Draft From 1649ded4713004792b6b0b9a88e181b3ec3c7dba Mon Sep 17 00:00:00 2001 From: Tjaden Hess Date: Mon, 11 Jul 2016 13:53:20 -0400 Subject: [PATCH 07/19] Fix gas calculation --- EIPS/eip-9.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-9.md b/EIPS/eip-9.md index 3308f6fbae6b62..63bed214c0a3c8 100644 --- a/EIPS/eip-9.md +++ b/EIPS/eip-9.md @@ -24,9 +24,9 @@ Adds a precompile at address `0x0000....0c` which accepts a variable length inpu [INSIZE, OUTSIZE, D_1, D_2, ..., D_INSIZE] - where `INSIZE` is the length in words of the input. If the bytes of data provided is fewer than `INSIZE`, remaining bytes are assumed to be zero, extra bytes are ignored. Throws if `OUTSIZE` is greater than 64. Returns the `OUTSIZE`-byte BLAKE2b digest, as defined in [RFC 7693](https://tools.ietf.org/html/rfc7693). + where `INSIZE` is the length in bytes of the input. If the length of data provided is less than `INSIZE`, remaining bytes are assumed to be zero, extra bytes are ignored. 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 would be equal to `GBLAKEBASE + GBLAKEWORD * INSIZE` +Gas costs would be equal to `GBLAKEBASE + GBLAKEWORD * floor(INSIZE / 32)` In order to maintain backwards compatibility, the precompile will return `0` if `CURRENT_BLOCKNUM < METROPOLIS_FORK_BLKNUM` From bb26ea7bef4de2a048fa4615017641f596a75329 Mon Sep 17 00:00:00 2001 From: Tjaden Hess Date: Tue, 12 Jul 2016 10:38:30 -0400 Subject: [PATCH 08/19] Remove INSIZE parameter, as it is unnecessary --- EIPS/eip-9.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-9.md b/EIPS/eip-9.md index 63bed214c0a3c8..41fe3bc0007441 100644 --- a/EIPS/eip-9.md +++ b/EIPS/eip-9.md @@ -21,10 +21,10 @@ This EIP introduces a new precompiled contract which implements the BLAKE2b cryp Adds a precompile at address `0x0000....0c` which accepts a variable length input interpreted as - [INSIZE, OUTSIZE, D_1, D_2, ..., D_INSIZE] + [OUTSIZE, D_1, D_2, ..., D_INSIZE] - where `INSIZE` is the length in bytes of the input. If the length of data provided is less than `INSIZE`, remaining bytes are assumed to be zero, extra bytes are ignored. Throws if `OUTSIZE` is greater than 64. Returns the `OUTSIZE`-byte BLAKE2b digest, as defined in [RFC 7693](https://tools.ietf.org/html/rfc7693). + 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 would be equal to `GBLAKEBASE + GBLAKEWORD * floor(INSIZE / 32)` From ebea49b46159f4b5d712052f88b053ea32440136 Mon Sep 17 00:00:00 2001 From: Tjaden Hess Date: Thu, 30 Jun 2016 10:45:51 -0400 Subject: [PATCH 09/19] Start new EIP --- EIPS/eip-9.md | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 EIPS/eip-9.md diff --git a/EIPS/eip-9.md b/EIPS/eip-9.md new file mode 100644 index 00000000000000..9c22aae58e622d --- /dev/null +++ b/EIPS/eip-9.md @@ -0,0 +1,9 @@ +### Title + + EIP: 9 + Title: Add precompiled contracts for blockchain interoperability + Author: Tjaden Hess + Status: Draft + Type: Standard Track + Layer: Consensus (hard-fork) + Created 2016-06-30 From 9c45bf983d2e3eb7835e34f03465d4d9f4fe55f9 Mon Sep 17 00:00:00 2001 From: Tjaden Hess Date: Thu, 30 Jun 2016 11:05:33 -0400 Subject: [PATCH 10/19] Add abstract and specification --- EIPS/eip-9.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/EIPS/eip-9.md b/EIPS/eip-9.md index 9c22aae58e622d..a55a68128aaf3e 100644 --- a/EIPS/eip-9.md +++ b/EIPS/eip-9.md @@ -7,3 +7,19 @@ Type: Standard Track Layer: Consensus (hard-fork) Created 2016-06-30 + +### Abstract + +This EIP introduces several new "precompiled contracts" designed to provide interoperability between the Ethereum network and various other blockchains by enabling the construction of efficient BTC Relay- like SPV clients on top of the EVM. + +### Specification + +EVM implementations should support 2 new precompiled contracts at addresses 5 and 6, respectively. The contract at address 5 implements the Scrypt KDF with parameters + + N = 1024 + r = 1 + p = 1 + salt = input + 256 bit digest length + +which are notably used in Litecoin and its derivatives. The contract at address 6 should implement the BLAKE2b hash function, a Password Hashing Competition finalist most notably used Proof of Work function for Zcash. From f33bbe1231845b2213e10a0a3f6805b476c7af2a Mon Sep 17 00:00:00 2001 From: Tjaden Hess Date: Mon, 11 Jul 2016 11:07:28 -0400 Subject: [PATCH 11/19] Add specification and rationale --- EIPS/eip-9.md | 42 ++++++++++++++++++++++++++++++++++-------- 1 file changed, 34 insertions(+), 8 deletions(-) diff --git a/EIPS/eip-9.md b/EIPS/eip-9.md index a55a68128aaf3e..09b02508edb61c 100644 --- a/EIPS/eip-9.md +++ b/EIPS/eip-9.md @@ -10,16 +10,42 @@ ### Abstract -This EIP introduces several new "precompiled contracts" designed to provide interoperability between the Ethereum network and various other blockchains by enabling the construction of efficient BTC Relay- like SPV clients on top of the EVM. +This EIP introduces a new precompiled contract which implements the BLAKE2b cryptographic hashing algorithm, for the purpose of allowing interoperability between the Zcash blockchain and the EVM. + +### Parameters + +* `METROPOLIS_FORK_BLKNUM`: TBD +* `GBLAKEBASE`: 30 +* `GBLAKEWORD`: 6 ### Specification -EVM implementations should support 2 new precompiled contracts at addresses 5 and 6, respectively. The contract at address 5 implements the Scrypt KDF with parameters +Adds a precompile at address `0x0000....0c` which accepts a variable length input interpreted as + + [INSIZE, OUTSIZE, D_1, D_2, ..., D_INSIZE] + + + where `INSIZE` is the length in words of the input. If the bytes of data provided is fewer than `INSIZE`, remaining bytes are assumed to be zero, extra bytes are ignored. 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 would be equal to `GBLAKEBASE + GBLAKEWORD * INSIZE` + +### Rationale + +Besides being a useful cryptographic hash function and SHA3 finalist, BLAKE2b allows for efficient verification of the Equihash PoW used in Zcash, making a BTC Relay - style SPV client possible on Ethereum. One BLAKE2 digest in Soldity, (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 25 to 27 iterations of the hash function, making verification of Zcash block headers prohibitively expensive. + +The BLAKE2b algorithm is highly optimised for 64-bit CPUs, and is faster than MD5 on modern processors. + +Interoperability with Zcash would enable trustless atomic swaps between the chain, which could provide a much needed aspect of privacy to the very public Ethereum blockchain. + +Other functions useful for cross-chain interoperability, such as the Scrypt KDF, should also be considered for inclusion. + +# Implementation - N = 1024 - r = 1 - p = 1 - salt = input - 256 bit digest length +There are public-domain BLAKE2b libraries in most languages: -which are notably used in Litecoin and its derivatives. The contract at address 6 should implement the BLAKE2b hash function, a Password Hashing Competition finalist most notably used Proof of Work function for Zcash. +* [Go](https://godoc.org/github.com/codahale/blake2#pkg-files) +* [Python](https://github.com/dchest/pyblake2) +* [Rust](https://github.com/cesarb/blake2-rfc) +* [JavaScript](https://github.com/ludios/node-blake2) +* [Java](https://github.com/alphazero/Blake2b) +* [C++](https://github.com/BLAKE2/BLAKE2) From 34f649ea9d16d7524a5a806ffb9297c6a6bc3ddf Mon Sep 17 00:00:00 2001 From: Tjaden Hess Date: Mon, 11 Jul 2016 12:15:55 -0400 Subject: [PATCH 12/19] Add rationale --- EIPS/eip-9.md | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/EIPS/eip-9.md b/EIPS/eip-9.md index 09b02508edb61c..a1e79fe570f8e7 100644 --- a/EIPS/eip-9.md +++ b/EIPS/eip-9.md @@ -1,7 +1,7 @@ ### Title EIP: 9 - Title: Add precompiled contracts for blockchain interoperability + Title: Add precompiled BLAKE2b contract Author: Tjaden Hess Status: Draft Type: Standard Track @@ -29,23 +29,26 @@ Adds a precompile at address `0x0000....0c` which accepts a variable length inpu Gas costs would be equal to `GBLAKEBASE + GBLAKEWORD * INSIZE` -### Rationale +In order to maintain backwards compatibility, the precompile will return `0` if `CURRENT_BLOCKNUM < METROPOLIS_FORK_BLKNUM` + +### Motivation Besides being a useful cryptographic hash function and SHA3 finalist, BLAKE2b allows for efficient verification of the Equihash PoW used in Zcash, making a BTC Relay - style SPV client possible on Ethereum. One BLAKE2 digest in Soldity, (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 25 to 27 iterations of the hash function, making verification of Zcash block headers prohibitively expensive. The BLAKE2b algorithm is highly optimised for 64-bit CPUs, and is faster than MD5 on modern processors. -Interoperability with Zcash would enable trustless atomic swaps between the chain, which could provide a much needed aspect of privacy to the very public Ethereum blockchain. +Interoperability with Zcash would enable trustless atomic swaps between the chains, which could provide a much needed aspect of privacy to the very public Ethereum blockchain. + +### Rationale + +The most frequent concern with EIPs of this type is that the addition of specific functions at the protocol level is an infringement on 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 subsidising via precompiled contracts and there is significant precedent for this, most notably the inclusion of the SHA256 prcompiled contract, which is included largely to allow interoperation with the Bitcoin blockchain. + +Additionally, BLAKE2b is an excellent candidate for precompilation because of the extremely asymetric 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. -Other functions useful for cross-chain interoperability, such as the Scrypt KDF, should also be considered for inclusion. +In contrast, the big-endian 32 byte semantics of the EVM are not conducive to efficent 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. -# Implementation +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 and is an important component in the Equihash PoW algorithm. -There are public-domain BLAKE2b libraries in most languages: +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. Te likelihood of this is low, and should specific instances arise, the address could be chosen to be any arbitrary value, with negligble risk of colllision. -* [Go](https://godoc.org/github.com/codahale/blake2#pkg-files) -* [Python](https://github.com/dchest/pyblake2) -* [Rust](https://github.com/cesarb/blake2-rfc) -* [JavaScript](https://github.com/ludios/node-blake2) -* [Java](https://github.com/alphazero/Blake2b) -* [C++](https://github.com/BLAKE2/BLAKE2) +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. From 10004d4e96ecb6ffb513e2d7b6f1168702ece7f6 Mon Sep 17 00:00:00 2001 From: Tjaden Hess Date: Mon, 11 Jul 2016 12:18:03 -0400 Subject: [PATCH 13/19] Spelling fixes --- EIPS/eip-9.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/EIPS/eip-9.md b/EIPS/eip-9.md index a1e79fe570f8e7..0114f2931a2c48 100644 --- a/EIPS/eip-9.md +++ b/EIPS/eip-9.md @@ -35,20 +35,20 @@ In order to maintain backwards compatibility, the precompile will return `0` if Besides being a useful cryptographic hash function and SHA3 finalist, BLAKE2b allows for efficient verification of the Equihash PoW used in Zcash, making a BTC Relay - style SPV client possible on Ethereum. One BLAKE2 digest in Soldity, (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 25 to 27 iterations of the hash function, making verification of Zcash block headers prohibitively expensive. -The BLAKE2b algorithm is highly optimised for 64-bit CPUs, and is faster than MD5 on modern processors. +The BLAKE2b algorithm is highly optimized for 64-bit CPUs, and is faster than MD5 on modern processors. Interoperability with Zcash would enable trustless atomic swaps between the chains, which could provide a much needed aspect of privacy to the very public Ethereum blockchain. ### Rationale -The most frequent concern with EIPs of this type is that the addition of specific functions at the protocol level is an infringement on 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 subsidising via precompiled contracts and there is significant precedent for this, most notably the inclusion of the SHA256 prcompiled contract, which is included largely to allow interoperation with the Bitcoin blockchain. +The most frequent concern with EIPs of this type is that the addition of specific functions at the protocol level is an infringement on 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 subsidising via precompiled contracts and there is significant precedent for this, most notably the inclusion of the SHA256 prcompiled 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 asymetric 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 efficent 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. +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 and is an important component in the Equihash PoW algorithm. -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. Te likelihood of this is low, and should specific instances arise, the address could be chosen to be any arbitrary value, with negligble risk of colllision. +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. Te 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. 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. From 00da725af2f34c523bafd181c80d48bddd6fbc0e Mon Sep 17 00:00:00 2001 From: Tjaden Hess Date: Mon, 11 Jul 2016 12:26:48 -0400 Subject: [PATCH 14/19] Remove EIP number until assignment --- EIPS/eip-9.md | 1 - 1 file changed, 1 deletion(-) diff --git a/EIPS/eip-9.md b/EIPS/eip-9.md index 0114f2931a2c48..3308f6fbae6b62 100644 --- a/EIPS/eip-9.md +++ b/EIPS/eip-9.md @@ -1,6 +1,5 @@ ### Title - EIP: 9 Title: Add precompiled BLAKE2b contract Author: Tjaden Hess Status: Draft From 8e59a8d7a3effea67376cbe5b3321729e7d953e2 Mon Sep 17 00:00:00 2001 From: Tjaden Hess Date: Mon, 11 Jul 2016 13:53:20 -0400 Subject: [PATCH 15/19] Fix gas calculation --- EIPS/eip-9.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-9.md b/EIPS/eip-9.md index 3308f6fbae6b62..63bed214c0a3c8 100644 --- a/EIPS/eip-9.md +++ b/EIPS/eip-9.md @@ -24,9 +24,9 @@ Adds a precompile at address `0x0000....0c` which accepts a variable length inpu [INSIZE, OUTSIZE, D_1, D_2, ..., D_INSIZE] - where `INSIZE` is the length in words of the input. If the bytes of data provided is fewer than `INSIZE`, remaining bytes are assumed to be zero, extra bytes are ignored. Throws if `OUTSIZE` is greater than 64. Returns the `OUTSIZE`-byte BLAKE2b digest, as defined in [RFC 7693](https://tools.ietf.org/html/rfc7693). + where `INSIZE` is the length in bytes of the input. If the length of data provided is less than `INSIZE`, remaining bytes are assumed to be zero, extra bytes are ignored. 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 would be equal to `GBLAKEBASE + GBLAKEWORD * INSIZE` +Gas costs would be equal to `GBLAKEBASE + GBLAKEWORD * floor(INSIZE / 32)` In order to maintain backwards compatibility, the precompile will return `0` if `CURRENT_BLOCKNUM < METROPOLIS_FORK_BLKNUM` From 5798cb74dad71352c18103634d875041ee32b994 Mon Sep 17 00:00:00 2001 From: Tjaden Hess Date: Tue, 12 Jul 2016 10:38:30 -0400 Subject: [PATCH 16/19] Remove INSIZE parameter, as it is unnecessary --- EIPS/eip-9.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-9.md b/EIPS/eip-9.md index 63bed214c0a3c8..41fe3bc0007441 100644 --- a/EIPS/eip-9.md +++ b/EIPS/eip-9.md @@ -21,10 +21,10 @@ This EIP introduces a new precompiled contract which implements the BLAKE2b cryp Adds a precompile at address `0x0000....0c` which accepts a variable length input interpreted as - [INSIZE, OUTSIZE, D_1, D_2, ..., D_INSIZE] + [OUTSIZE, D_1, D_2, ..., D_INSIZE] - where `INSIZE` is the length in bytes of the input. If the length of data provided is less than `INSIZE`, remaining bytes are assumed to be zero, extra bytes are ignored. Throws if `OUTSIZE` is greater than 64. Returns the `OUTSIZE`-byte BLAKE2b digest, as defined in [RFC 7693](https://tools.ietf.org/html/rfc7693). + 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 would be equal to `GBLAKEBASE + GBLAKEWORD * floor(INSIZE / 32)` From db857714e6125691ade9f25d4744a12bc9fb0625 Mon Sep 17 00:00:00 2001 From: Jay Graber Date: Wed, 27 Sep 2017 08:59:34 -0700 Subject: [PATCH 17/19] Expand motivation section, typo fixes --- EIPS/eip-9.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/EIPS/eip-9.md b/EIPS/eip-9.md index 41fe3bc0007441..3d9ce6afc30a3d 100644 --- a/EIPS/eip-9.md +++ b/EIPS/eip-9.md @@ -1,7 +1,7 @@ ### Title Title: Add precompiled BLAKE2b contract - Author: Tjaden Hess + Author: Tjaden Hess & Jay Graber Status: Draft Type: Standard Track Layer: Consensus (hard-fork) @@ -9,7 +9,14 @@ ### Abstract -This EIP introduces a new precompiled contract which implements the BLAKE2b cryptographic hashing algorithm, for the purpose of allowing interoperability between the Zcash blockchain and the EVM. +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 25 to 27 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. Interoperability with Zcash would enable trustless atomic swaps between the chains, which could provide a much needed aspect of privacy to the very public Ethereum blockchain. + +Adding a precompile for the BLAKE2b hashing function will make the operation significantly faster and cheaper, improving usability. ### Parameters @@ -30,19 +37,12 @@ Gas costs would be equal to `GBLAKEBASE + GBLAKEWORD * floor(INSIZE / 32)` In order to maintain backwards compatibility, the precompile will return `0` if `CURRENT_BLOCKNUM < METROPOLIS_FORK_BLKNUM` -### Motivation - -Besides being a useful cryptographic hash function and SHA3 finalist, BLAKE2b allows for efficient verification of the Equihash PoW used in Zcash, making a BTC Relay - style SPV client possible on Ethereum. One BLAKE2 digest in Soldity, (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 25 to 27 iterations of the hash function, making verification of Zcash block headers prohibitively expensive. - -The BLAKE2b algorithm is highly optimized for 64-bit CPUs, and is faster than MD5 on modern processors. - -Interoperability with Zcash would enable trustless atomic swaps between the chains, which could provide a much needed aspect of privacy to the very public Ethereum blockchain. ### Rationale -The most frequent concern with EIPs of this type is that the addition of specific functions at the protocol level is an infringement on 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 subsidising via precompiled contracts and there is significant precedent for this, most notably the inclusion of the SHA256 prcompiled contract, which is included largely to allow inter-operation with the Bitcoin blockchain. +The most frequent concern with EIPs of this type is that the addition of specific functions at the protocol level is an infringement on 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 and there is significant precedent for this, 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 asymetric 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. +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. From f4e2fd89ded0cd104a09ae12878078f923848621 Mon Sep 17 00:00:00 2001 From: Jay Graber Date: Tue, 3 Oct 2017 03:55:21 -0700 Subject: [PATCH 18/19] Add implementations in various languages --- EIPS/eip-9.md | 31 +++++++++++++++++++++++-------- 1 file changed, 23 insertions(+), 8 deletions(-) diff --git a/EIPS/eip-9.md b/EIPS/eip-9.md index 3d9ce6afc30a3d..72abf8c60fa89b 100644 --- a/EIPS/eip-9.md +++ b/EIPS/eip-9.md @@ -7,26 +7,26 @@ Layer: Consensus (hard-fork) Created 2016-06-30 -### Abstract +## Abstract This EIP introduces a new precompiled contract which implements the BLAKE2b cryptographic hashing algorithm. -### Motivation +## 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 25 to 27 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. Interoperability with Zcash would enable trustless atomic swaps between the chains, which could provide a much needed aspect of privacy to the very public Ethereum blockchain. Adding a precompile for the BLAKE2b hashing function will make the operation significantly faster and cheaper, improving usability. -### Parameters +## Parameters * `METROPOLIS_FORK_BLKNUM`: TBD * `GBLAKEBASE`: 30 * `GBLAKEWORD`: 6 -### Specification +## Specification -Adds a precompile at address `0x0000....0c` which accepts a variable length input interpreted as +Adds a precompile at address `0x0000....0c` which accepts a variable length input interpreted as: [OUTSIZE, D_1, D_2, ..., D_INSIZE] @@ -38,9 +38,9 @@ Gas costs would be equal to `GBLAKEBASE + GBLAKEWORD * floor(INSIZE / 32)` In order to maintain backwards compatibility, the precompile will return `0` if `CURRENT_BLOCKNUM < METROPOLIS_FORK_BLKNUM` -### Rationale +## Rationale -The most frequent concern with EIPs of this type is that the addition of specific functions at the protocol level is an infringement on 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 and there is significant precedent for this, most notably the inclusion of the SHA256 precompiled contract, which is included largely to allow inter-operation with the Bitcoin blockchain. +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. @@ -48,6 +48,21 @@ In contrast, the big-endian 32 byte semantics of the EVM are not conducive to ef 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 and is an important component in the Equihash PoW algorithm. -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. Te 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. +## 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. 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 + +[Go implementation](https://github.com/dchest/blake2b) +[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/). From 2d4ea31b223aa62919eb1b8768335f7df5a63302 Mon Sep 17 00:00:00 2001 From: Jay Graber Date: Wed, 4 Oct 2017 07:15:46 -0700 Subject: [PATCH 19/19] Edit wording --- EIPS/eip-9.md | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/EIPS/eip-9.md b/EIPS/eip-9.md index 72abf8c60fa89b..a77c59662cf7b0 100644 --- a/EIPS/eip-9.md +++ b/EIPS/eip-9.md @@ -14,7 +14,7 @@ This EIP introduces a new precompiled contract which implements the BLAKE2b cryp ## 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 25 to 27 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. Interoperability with Zcash would enable trustless atomic swaps between the chains, which could provide a much needed aspect of privacy to the very public Ethereum blockchain. +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 25 to 27 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. @@ -26,17 +26,19 @@ Adding a precompile for the BLAKE2b hashing function will make the operation sig ## Specification -Adds a precompile at address `0x0000....0c` which accepts a variable length input interpreted as: +Adds a precompiled contract for the blake2b hash function. - [OUTSIZE, D_1, D_2, ..., D_INSIZE] +Address of `0x9` +Function accepts a variable length input interpreted as: - 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). + [OUTSIZE, D_1, D_2, ..., D_INSIZE] -Gas costs would be equal to `GBLAKEBASE + GBLAKEWORD * floor(INSIZE / 32)` +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). -In order to maintain backwards compatibility, the precompile will return `0` if `CURRENT_BLOCKNUM < METROPOLIS_FORK_BLKNUM` +### Gas Costs +Gas costs would be equal to `GBLAKEBASE + GBLAKEWORD * floor(INSIZE / 32)` ## Rationale @@ -46,12 +48,14 @@ Additionally, BLAKE2b is an excellent candidate for precompilation because of th 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 and is an important component in the Equihash PoW algorithm. +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 @@ -59,7 +63,9 @@ The community response to this EIP has been largely positive, and besides the "n ## Implementation -[Go implementation](https://github.com/dchest/blake2b) +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)