From 230647f536a856e935c603d30b110096e52212a2 Mon Sep 17 00:00:00 2001 From: Tjaden Hess Date: Thu, 30 Jun 2016 10:45:51 -0400 Subject: [PATCH 001/137] 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 0000000000000..9c22aae58e622 --- /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 002/137] 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 9c22aae58e622..a55a68128aaf3 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 003/137] 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 a55a68128aaf3..09b02508edb61 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 004/137] 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 09b02508edb61..a1e79fe570f8e 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 005/137] 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 a1e79fe570f8e..0114f2931a2c4 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 006/137] 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 0114f2931a2c4..3308f6fbae6b6 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 007/137] 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 3308f6fbae6b6..63bed214c0a3c 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 008/137] 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 63bed214c0a3c..41fe3bc000744 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 009/137] 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 0000000000000..9c22aae58e622 --- /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 010/137] 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 9c22aae58e622..a55a68128aaf3 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 011/137] 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 a55a68128aaf3..09b02508edb61 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 012/137] 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 09b02508edb61..a1e79fe570f8e 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 013/137] 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 a1e79fe570f8e..0114f2931a2c4 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 014/137] 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 0114f2931a2c4..3308f6fbae6b6 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 015/137] 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 3308f6fbae6b6..63bed214c0a3c 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 016/137] 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 63bed214c0a3c..41fe3bc000744 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 017/137] 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 41fe3bc000744..3d9ce6afc30a3 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 018/137] 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 3d9ce6afc30a3..72abf8c60fa89 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 019/137] 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 72abf8c60fa89..a77c59662cf7b 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) From 240cabc7b5ec42049275a03bbe7c9a7147be492a Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Tue, 30 Apr 2019 09:57:13 +0100 Subject: [PATCH 020/137] Change the citation format in README to point to EIP-1 --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 03278d567ae9d..4bb44a250fb26 100644 --- a/README.md +++ b/README.md @@ -32,7 +32,7 @@ When you believe your EIP is mature and ready to progress past the draft phase, # Preferred Citation Format -The canonical URL for a EIP that has achieved draft status at any point is at https://eips.ethereum.org/. For example, the canonical URL for ERC-165 is https://eips.ethereum.org/EIPS/eip-165. +The canonical URL for a EIP that has achieved draft status at any point is at https://eips.ethereum.org/. For example, the canonical URL for EIP-1 is https://eips.ethereum.org/EIPS/eip-1. # Validation From 39f7c3f606bc840169af30bbe9e578632b6d696a Mon Sep 17 00:00:00 2001 From: James Hancock Date: Mon, 13 May 2019 18:31:58 -0400 Subject: [PATCH 021/137] Create eip-Funding-eth-1x.md --- EIPS/eip-Funding-eth-1x.md | 174 +++++++++++++++++++++++++++++++++++++ 1 file changed, 174 insertions(+) create mode 100644 EIPS/eip-Funding-eth-1x.md diff --git a/EIPS/eip-Funding-eth-1x.md b/EIPS/eip-Funding-eth-1x.md new file mode 100644 index 0000000000000..391d3eba6b904 --- /dev/null +++ b/EIPS/eip-Funding-eth-1x.md @@ -0,0 +1,174 @@ +--- +eip: +title: Block Rewards Proposal for funding Eth1.x +author: James Hancock (@madeoftin) +discussions-to: https://github.com/MadeofTin/EIPs/issues +status: Draft +type: Standards Track +category: Core +created: 2019-04-20 +requires: 1890 +--- + +## Simple Summary +Add `0.044 ETH` per block for 18 months as a block reward that goes to funding Ethereum1.X development. + +Currently, EIP 1890 is a proposal for a mechanism to capture Block Rewards for Ethereum Development with values and addresses set to zero. This proposal is to set those values to non-zero for 18 months focusing on funding Ethereum 1.X Development. Funds go to paying back a loan for funding Eth1.X working groups as well as established organizations currently investing in ecosystem development. + + + +## Abstract + +This EIP extends the mechanism established in EIP-1890 to add `0.044 ETH` to the Block Reward for a specific distribution period of `3,100,000 BLOCKS`(≈18 months). The `RECIPIENT_ADDRESS` set to a smart contract with hardcoded denominations that distribute ETH to a set of addresses for the purpose of Eth1.X development. The emission schedule would start at the inclusion of this EIP in a hard fork and continue until the end of the period `3,100,000 BLOCKS` (≈18 months) where the address and amount would again return to 0. Any further distribution will require a future hard fork. + +## Motivation + + +The context for this proposal came from attending the [Core Dev Eth1.X Meeting](https://www.youtube.com/watch?v=Au1Qll-86v0) in Berlin. Development is needed to move Eth1.X forward, and I observed that a lack of funding is the primary barrier to this work. This work can only be effectively conducted within the context of working groups forming around these issues, and these working groups need funding in order to pay dedicated contractors and project managers. This proposal is a plan for funding these groups and supporting their operation. + + + +## Specification + + +The Block Rewards Schedule set to a fixed period "EMISSION_SCHEDULE = 3,100,000 blocks" (≈18 months). After this point emission would halt with the following logic. `WHILE CURRENT_BLOCK - FORK_BLOCK < 3,100,000`. + +During the emission schedule, Block rewards will send funds to a smart contract that distributes funds to the following addresses* denominated in ETH. + + +Distribution Per Block +``` + Development Loan: 0.04 - 124,000 ETH + Development Loan Interest 10%: 0.004 - 12,400 ETH + + Total Block Reward Increase = `0.044` ETH Per Block - 136,400 ETH Total +``` + +*With a current price of Etheruem at $200.00 this will raise 25 million USD for developing Eth1.X over the next 18 months.* + +![Block Rewards Distribution](https://docs.google.com/drawings/d/e/2PACX-1vRzpcFXvkftqEduftfCnNeJmjxQAyBjD1RMkuFt0JeURxSZ2oUSGA1HQ1-v5rjGeim2cn8IwF4UFH18/pub?w=873 "Logo Title Text 1") *Specific Addresses to be determined + +* [FAQ - Why hardcoded values?]( #why-hardcoded-values ) + + + +## Rationale + + +There has been great debate on Twitter concerning EIP-1890, and one of the primary concerns is that it is difficult to come to a conclusion without the other half of the proposal, or more specifically, how much and where to allocate Block Reward funds. There is a need for funding Eth1.x development and it is currently unclear from where those funds will come. This proposal is intended to give a more comprehensive proposal for its funding. In the case that ETH1.x is funded I will withdraw this EIP that would render it obsolete. Until that point I intend to continue championing this proposal as a valid funding mechanism for this work. + + +### Why a Loan? + +A loan is necessary to complete certain stages of work before the funding mechanism is put into the protocol , and before it begins to provide funds. A loan would provide this necessary funding today, and the organizations willing to front this cost can recoup their contribution + a reward of *a fixed interest rate* for participating in ecosystem development. This arrangement will make it easier for organizations to participate who have sufficient funds. + +### Development Loan + +`Development Loan: 0.04` over 3.1 Million blocks = 124,000 ETH + +**Funding Working Groups on 1.X** +* Funding Contractors, Coordinators, and project mangers. +* Working Groups defined with clear mandates at the time of creation before allocating funds +* Membership and creation managed by the Core Devs (i.e., I would not choose them) +* 30-50 Core Devs is sufficient to work on ETH1.X + * 7-8 Working groups with a Membership size of 3-7 is ideal from a coordination perspective. + +**ETH1.X Core Dev Gatherings** +Funding hosting, traveling, and accomodations for neccesary in person gatherings of ETH1.X core developers similar to the Stanford and Berlin ETH1.x Core Dev Meeting held earlier this year. + +**Client Teams** +Any research completed by ETH1.X working groups will need to be integrated into core clients before the network can adopt any changes. It is anticipated some of these funds will go to support the existing client teams in this effort. + +At the end of the 18 Months, the whole process would be torn down to prevent any internal tyranny of unstructuredness forming within. + + +* [FAQ - How will the funding of the Devs be organized?]( #how-will-funding-the-devs-be-organized) + +![Eth1.x Working Groups Status](https://docs.google.com/drawings/d/e/2PACX-1vRzaZFh4fZS0mksfyfJs1AsXNoqgfMmyJMYLHXEVariN-S9YsI43_FhHl1K_iO4rrqDsSy-tX4-MWws/pub?w=548&h=423) + + + +## Personal Notes and Disclosure +I want to address any concerns about conflicts of interests directly. My participation with Eth1.X currently has been as a volunteer. I am in talks about a possible funded role helping with testing and coordination. If my work for with Eth1.x is funded, I would seek the following conditions. + + 1) Funding for my work will not come from the loan meant for the Eth1.X Working Groups. + +Eth1.X is the now of Ethereum and I would like to see it succeed. This is the intent of my proposal + +### COI +Previously I was PM for Tennagraph, a Signalling solution for Ethereum. An Aragon Grant funded this project and was distributed through Giveth and an AragonDAO. I have not received any funding from the project past this Grant. All of this is verifiable on-chain. I am stepping down from any paid role on the project to continue as an advisor. I am also stepping down as a moderator for stances as there is a COI moderating stances for EIPs I am working with directly. + +### Finally + +I do not claim to represent the community with my views; any members who wish to join supporting me with this proposal are free to do so. I welcome feedback and will listen carefully, but any adaptations are according to my judgment. This is an honest reflection. This is as fair of a proposal as I can personally conceive. If the community rejects it then so be it, I am satisfied with the submission. + +## Backwards Compatibility + +None + +## Test Cases + +Not Implemented + +## Implementation + + +Not Implemented + +## FAQ + +### Why Hardcoded Values + +Why not us a smart contract with some governance mechanism to allow changing the distribution of funds? Wouldn’t that be more flexible and effective? + +*TL;DR This EIP is not about Governance Reform* + +First, the payment of the loan will be hardcoded. Once agreed, the terms must be kept to give the lenders confidence in the repayment of the loan. As long as blocks are created the debt will be paid back. This is the essence of a trustless smart contract. + +After the loan, there is the option to allow the amounts (limited to less than .05ETH), and the locations (orgs that receive ecosystem funding) to be changed throughout the emission schedule. A smart contract or DAO is pretty easy to imagine fulfilling this role. However, there are three classes of options available today we can consider when governing changes. + +* **Give the Keys to the Hands of the Few (Oligarchy)** + +Create a multisig that allows a group of individuals to update the smart contract. The most likely candidates for this are the Core Devs themselves, but it could also be a trusted few from the community/stakeholders. No matter how you slice it, there is a fundamental issue in deciding who gets to decide. There currently is not an trusted/adopted governance mechanism to make these decisions with-in Ethereum. Also, preventing changing the contract in self interest is difficult without a well engineered governance system of checks and balances. This EIP does not claim, nor aim to solve these issues. + +* **Give the Keys to the Hands of the Many (Plutarchy)** + +Allow ethereum holders with coin votes to update the smart contract. Using holographic consensus could overcome the issue of voter turnout as it scales as participation scales, even to the size of the whole network. This has some benefits as the entire network can participate. However, the problem is that some individuals in the network are over represented -- the wealthy. Without a solution to identity that has been agreed to and implemented by the entire Ethereum Network, there is no way around giving more power in votes to the rich. This EIP does not claim, nor aim to solve these issues. + +* **Use Ethereum Governance as it is Today** + +Criticisms or support aside, there is a system that governs ethereum today. It is a mix of rough consensus among core devs, miners running nodes, clients implementing changes, and stakeholders adopting those changes. It includes yelling or not yelling on twitter and reddit. It is complicated and I don’t claim to understand it. Even without a clear view of how it works, there is evidence of its existence. This evidence is there are changes that have allowed to be implemented, and changes that have not allowed to be implemented in Ethereum. + +I do not aim to change ethereum governance. Because this EIP has hardcoded values, it must go through the existing governance process, whatever that is, before it will be implemented in the network. It will then continue until as decided until the end of the emission schedule. This is intentional. This makes it uncapturable. No party other then the ecosystem itself can modify the contract once it has been deployed. + +This EIP is not about Governance Reform + +### Why not allow current client implementors fund this work? (EF, Consensys, Parity, etc...) + +Historically there has been a precedent that the Ethereum foundation is solely responsible for funding the development of Ethereum. This process has evolved as the development has become more distributed. Aya Miyaguci observed in a recent coindesk article. “it really is not only Ethereum Foundation people who are building [ethereum,]” . Yes, we could rely on the Ethereum Foundation to fund Eth1.X. But, why should we? This is a call for the network to come together and fund its own development. Ethereum the Network is not owned by any one organization or group of people. We are lucky to have the EF and I consider this EIP in support of their coordination efforts. + +### How Will Funding the Devs be Organized + +I do not profess to know the best way to organize these funds. There is work already in progress to organize these efforts championed by Alexey Akhunov. The following is a quote from a [recent medium article](https://medium.com/@akhounov/ethereum-1x-as-an-attempt-to-change-the-process-783efa23cf60). + +>“Going from funding a few implementation teams continuously and letting them do “their stuff” to funding more specific and temporary initiatives requires looking at funding through different lenses. How much “due diligence” and oversight is too much (in terms of overhead), who can decide whether working groups actually deliver, etc. This is also solvable, and also more on this will come later (not in this post). + +My suggestion would be to create an Eth1.X core developer DAO using [DaoStack](https://daostack.io/) to coordinate memberhips and payment of the CoreDevs, but ultimately they are capable of determining the system that works best for them. As long as the system is transparent and mature enough to distribute funds when the time comes, this is sufficient for now. + +### Isn't a loan considered a security, or is it? + +I am not a lawyer and will seek further guidance from lawyers in the field on this point in particular. From the research I have done and conversations I have had there is a very good argument that a loan of this nature will not be considered a security by the US Supreme Court. +As the result of [REVES ET AL. v . ERNST YOUNG 1990](https://casetext.com/case/reves-v-ernst-young), the court stated that a home loan, consumer financing, a loan secured by a lien on a small business or some assets of a small business, short term notes, or notes that formalize a debt incurred in the ordinary course of business are not securities. If the note resembles the items listed above (home loans, etc.) then the note will not be deemed a security. The Supreme Court provided four factors to determine if a note sufficiently resembles the types of notes that are not classified as securities. [src](https://www.invigorlaw.com/loan-subject-securities-regulations/) + +**Family Resemblance Test** + 1) The intentions of the company and the individual—if the company raised money for general use in a business enterprise, then the note is more likely to be a security; if the individual agreed to the loan primarily for the profit the note was expected to generate, the note is more likely to be a security. + 2)The plan of distribution—the more widely the note is offered, the more likely it is to be found a security. + 3) The expectations of the investing public—if the investors thought they were investing in a business to make a profit on their investment, the note is more likely to be found a security. + 4) Other risk-reducing factor—if the note is collateralized or otherwise less risky than common notes, the note is less likely to be found to be a security. + +The loan is for the specific use of supporting Eth1.X research and deployment. The Distribution will not be widely offered and the note will be collateralized by the network itself, Made in ETH and repaid in ETH. I in coordinating the collection of these funds recognise I may be legally liable for some of this work and I will do all of the duedillegence I can, seek legal counsel, and accept any legal repercussions resulting from this work. + +#### + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 6003de75bf8d36ccda1e46b1d7501694b9a3e092 Mon Sep 17 00:00:00 2001 From: James Hancock Date: Mon, 13 May 2019 18:36:44 -0400 Subject: [PATCH 022/137] Delete eip-Funding-eth-1x.md --- EIPS/eip-Funding-eth-1x.md | 174 ------------------------------------- 1 file changed, 174 deletions(-) delete mode 100644 EIPS/eip-Funding-eth-1x.md diff --git a/EIPS/eip-Funding-eth-1x.md b/EIPS/eip-Funding-eth-1x.md deleted file mode 100644 index 391d3eba6b904..0000000000000 --- a/EIPS/eip-Funding-eth-1x.md +++ /dev/null @@ -1,174 +0,0 @@ ---- -eip: -title: Block Rewards Proposal for funding Eth1.x -author: James Hancock (@madeoftin) -discussions-to: https://github.com/MadeofTin/EIPs/issues -status: Draft -type: Standards Track -category: Core -created: 2019-04-20 -requires: 1890 ---- - -## Simple Summary -Add `0.044 ETH` per block for 18 months as a block reward that goes to funding Ethereum1.X development. - -Currently, EIP 1890 is a proposal for a mechanism to capture Block Rewards for Ethereum Development with values and addresses set to zero. This proposal is to set those values to non-zero for 18 months focusing on funding Ethereum 1.X Development. Funds go to paying back a loan for funding Eth1.X working groups as well as established organizations currently investing in ecosystem development. - - - -## Abstract - -This EIP extends the mechanism established in EIP-1890 to add `0.044 ETH` to the Block Reward for a specific distribution period of `3,100,000 BLOCKS`(≈18 months). The `RECIPIENT_ADDRESS` set to a smart contract with hardcoded denominations that distribute ETH to a set of addresses for the purpose of Eth1.X development. The emission schedule would start at the inclusion of this EIP in a hard fork and continue until the end of the period `3,100,000 BLOCKS` (≈18 months) where the address and amount would again return to 0. Any further distribution will require a future hard fork. - -## Motivation - - -The context for this proposal came from attending the [Core Dev Eth1.X Meeting](https://www.youtube.com/watch?v=Au1Qll-86v0) in Berlin. Development is needed to move Eth1.X forward, and I observed that a lack of funding is the primary barrier to this work. This work can only be effectively conducted within the context of working groups forming around these issues, and these working groups need funding in order to pay dedicated contractors and project managers. This proposal is a plan for funding these groups and supporting their operation. - - - -## Specification - - -The Block Rewards Schedule set to a fixed period "EMISSION_SCHEDULE = 3,100,000 blocks" (≈18 months). After this point emission would halt with the following logic. `WHILE CURRENT_BLOCK - FORK_BLOCK < 3,100,000`. - -During the emission schedule, Block rewards will send funds to a smart contract that distributes funds to the following addresses* denominated in ETH. - - -Distribution Per Block -``` - Development Loan: 0.04 - 124,000 ETH - Development Loan Interest 10%: 0.004 - 12,400 ETH - - Total Block Reward Increase = `0.044` ETH Per Block - 136,400 ETH Total -``` - -*With a current price of Etheruem at $200.00 this will raise 25 million USD for developing Eth1.X over the next 18 months.* - -![Block Rewards Distribution](https://docs.google.com/drawings/d/e/2PACX-1vRzpcFXvkftqEduftfCnNeJmjxQAyBjD1RMkuFt0JeURxSZ2oUSGA1HQ1-v5rjGeim2cn8IwF4UFH18/pub?w=873 "Logo Title Text 1") *Specific Addresses to be determined - -* [FAQ - Why hardcoded values?]( #why-hardcoded-values ) - - - -## Rationale - - -There has been great debate on Twitter concerning EIP-1890, and one of the primary concerns is that it is difficult to come to a conclusion without the other half of the proposal, or more specifically, how much and where to allocate Block Reward funds. There is a need for funding Eth1.x development and it is currently unclear from where those funds will come. This proposal is intended to give a more comprehensive proposal for its funding. In the case that ETH1.x is funded I will withdraw this EIP that would render it obsolete. Until that point I intend to continue championing this proposal as a valid funding mechanism for this work. - - -### Why a Loan? - -A loan is necessary to complete certain stages of work before the funding mechanism is put into the protocol , and before it begins to provide funds. A loan would provide this necessary funding today, and the organizations willing to front this cost can recoup their contribution + a reward of *a fixed interest rate* for participating in ecosystem development. This arrangement will make it easier for organizations to participate who have sufficient funds. - -### Development Loan - -`Development Loan: 0.04` over 3.1 Million blocks = 124,000 ETH - -**Funding Working Groups on 1.X** -* Funding Contractors, Coordinators, and project mangers. -* Working Groups defined with clear mandates at the time of creation before allocating funds -* Membership and creation managed by the Core Devs (i.e., I would not choose them) -* 30-50 Core Devs is sufficient to work on ETH1.X - * 7-8 Working groups with a Membership size of 3-7 is ideal from a coordination perspective. - -**ETH1.X Core Dev Gatherings** -Funding hosting, traveling, and accomodations for neccesary in person gatherings of ETH1.X core developers similar to the Stanford and Berlin ETH1.x Core Dev Meeting held earlier this year. - -**Client Teams** -Any research completed by ETH1.X working groups will need to be integrated into core clients before the network can adopt any changes. It is anticipated some of these funds will go to support the existing client teams in this effort. - -At the end of the 18 Months, the whole process would be torn down to prevent any internal tyranny of unstructuredness forming within. - - -* [FAQ - How will the funding of the Devs be organized?]( #how-will-funding-the-devs-be-organized) - -![Eth1.x Working Groups Status](https://docs.google.com/drawings/d/e/2PACX-1vRzaZFh4fZS0mksfyfJs1AsXNoqgfMmyJMYLHXEVariN-S9YsI43_FhHl1K_iO4rrqDsSy-tX4-MWws/pub?w=548&h=423) - - - -## Personal Notes and Disclosure -I want to address any concerns about conflicts of interests directly. My participation with Eth1.X currently has been as a volunteer. I am in talks about a possible funded role helping with testing and coordination. If my work for with Eth1.x is funded, I would seek the following conditions. - - 1) Funding for my work will not come from the loan meant for the Eth1.X Working Groups. - -Eth1.X is the now of Ethereum and I would like to see it succeed. This is the intent of my proposal - -### COI -Previously I was PM for Tennagraph, a Signalling solution for Ethereum. An Aragon Grant funded this project and was distributed through Giveth and an AragonDAO. I have not received any funding from the project past this Grant. All of this is verifiable on-chain. I am stepping down from any paid role on the project to continue as an advisor. I am also stepping down as a moderator for stances as there is a COI moderating stances for EIPs I am working with directly. - -### Finally - -I do not claim to represent the community with my views; any members who wish to join supporting me with this proposal are free to do so. I welcome feedback and will listen carefully, but any adaptations are according to my judgment. This is an honest reflection. This is as fair of a proposal as I can personally conceive. If the community rejects it then so be it, I am satisfied with the submission. - -## Backwards Compatibility - -None - -## Test Cases - -Not Implemented - -## Implementation - - -Not Implemented - -## FAQ - -### Why Hardcoded Values - -Why not us a smart contract with some governance mechanism to allow changing the distribution of funds? Wouldn’t that be more flexible and effective? - -*TL;DR This EIP is not about Governance Reform* - -First, the payment of the loan will be hardcoded. Once agreed, the terms must be kept to give the lenders confidence in the repayment of the loan. As long as blocks are created the debt will be paid back. This is the essence of a trustless smart contract. - -After the loan, there is the option to allow the amounts (limited to less than .05ETH), and the locations (orgs that receive ecosystem funding) to be changed throughout the emission schedule. A smart contract or DAO is pretty easy to imagine fulfilling this role. However, there are three classes of options available today we can consider when governing changes. - -* **Give the Keys to the Hands of the Few (Oligarchy)** - -Create a multisig that allows a group of individuals to update the smart contract. The most likely candidates for this are the Core Devs themselves, but it could also be a trusted few from the community/stakeholders. No matter how you slice it, there is a fundamental issue in deciding who gets to decide. There currently is not an trusted/adopted governance mechanism to make these decisions with-in Ethereum. Also, preventing changing the contract in self interest is difficult without a well engineered governance system of checks and balances. This EIP does not claim, nor aim to solve these issues. - -* **Give the Keys to the Hands of the Many (Plutarchy)** - -Allow ethereum holders with coin votes to update the smart contract. Using holographic consensus could overcome the issue of voter turnout as it scales as participation scales, even to the size of the whole network. This has some benefits as the entire network can participate. However, the problem is that some individuals in the network are over represented -- the wealthy. Without a solution to identity that has been agreed to and implemented by the entire Ethereum Network, there is no way around giving more power in votes to the rich. This EIP does not claim, nor aim to solve these issues. - -* **Use Ethereum Governance as it is Today** - -Criticisms or support aside, there is a system that governs ethereum today. It is a mix of rough consensus among core devs, miners running nodes, clients implementing changes, and stakeholders adopting those changes. It includes yelling or not yelling on twitter and reddit. It is complicated and I don’t claim to understand it. Even without a clear view of how it works, there is evidence of its existence. This evidence is there are changes that have allowed to be implemented, and changes that have not allowed to be implemented in Ethereum. - -I do not aim to change ethereum governance. Because this EIP has hardcoded values, it must go through the existing governance process, whatever that is, before it will be implemented in the network. It will then continue until as decided until the end of the emission schedule. This is intentional. This makes it uncapturable. No party other then the ecosystem itself can modify the contract once it has been deployed. - -This EIP is not about Governance Reform - -### Why not allow current client implementors fund this work? (EF, Consensys, Parity, etc...) - -Historically there has been a precedent that the Ethereum foundation is solely responsible for funding the development of Ethereum. This process has evolved as the development has become more distributed. Aya Miyaguci observed in a recent coindesk article. “it really is not only Ethereum Foundation people who are building [ethereum,]” . Yes, we could rely on the Ethereum Foundation to fund Eth1.X. But, why should we? This is a call for the network to come together and fund its own development. Ethereum the Network is not owned by any one organization or group of people. We are lucky to have the EF and I consider this EIP in support of their coordination efforts. - -### How Will Funding the Devs be Organized - -I do not profess to know the best way to organize these funds. There is work already in progress to organize these efforts championed by Alexey Akhunov. The following is a quote from a [recent medium article](https://medium.com/@akhounov/ethereum-1x-as-an-attempt-to-change-the-process-783efa23cf60). - ->“Going from funding a few implementation teams continuously and letting them do “their stuff” to funding more specific and temporary initiatives requires looking at funding through different lenses. How much “due diligence” and oversight is too much (in terms of overhead), who can decide whether working groups actually deliver, etc. This is also solvable, and also more on this will come later (not in this post). - -My suggestion would be to create an Eth1.X core developer DAO using [DaoStack](https://daostack.io/) to coordinate memberhips and payment of the CoreDevs, but ultimately they are capable of determining the system that works best for them. As long as the system is transparent and mature enough to distribute funds when the time comes, this is sufficient for now. - -### Isn't a loan considered a security, or is it? - -I am not a lawyer and will seek further guidance from lawyers in the field on this point in particular. From the research I have done and conversations I have had there is a very good argument that a loan of this nature will not be considered a security by the US Supreme Court. -As the result of [REVES ET AL. v . ERNST YOUNG 1990](https://casetext.com/case/reves-v-ernst-young), the court stated that a home loan, consumer financing, a loan secured by a lien on a small business or some assets of a small business, short term notes, or notes that formalize a debt incurred in the ordinary course of business are not securities. If the note resembles the items listed above (home loans, etc.) then the note will not be deemed a security. The Supreme Court provided four factors to determine if a note sufficiently resembles the types of notes that are not classified as securities. [src](https://www.invigorlaw.com/loan-subject-securities-regulations/) - -**Family Resemblance Test** - 1) The intentions of the company and the individual—if the company raised money for general use in a business enterprise, then the note is more likely to be a security; if the individual agreed to the loan primarily for the profit the note was expected to generate, the note is more likely to be a security. - 2)The plan of distribution—the more widely the note is offered, the more likely it is to be found a security. - 3) The expectations of the investing public—if the investors thought they were investing in a business to make a profit on their investment, the note is more likely to be found a security. - 4) Other risk-reducing factor—if the note is collateralized or otherwise less risky than common notes, the note is less likely to be found to be a security. - -The loan is for the specific use of supporting Eth1.X research and deployment. The Distribution will not be widely offered and the note will be collateralized by the network itself, Made in ETH and repaid in ETH. I in coordinating the collection of these funds recognise I may be legally liable for some of this work and I will do all of the duedillegence I can, seek legal counsel, and accept any legal repercussions resulting from this work. - -#### - -## Copyright -Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From ef115c124892c03ac3666a37768b14493244520b Mon Sep 17 00:00:00 2001 From: James Hancock Date: Mon, 13 May 2019 19:01:38 -0400 Subject: [PATCH 023/137] Created initial File --- EIPS/eip-Blake2b | 96 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 96 insertions(+) create mode 100644 EIPS/eip-Blake2b diff --git a/EIPS/eip-Blake2b b/EIPS/eip-Blake2b new file mode 100644 index 0000000000000..a9d694bc27df5 --- /dev/null +++ b/EIPS/eip-Blake2b @@ -0,0 +1,96 @@ +--- +eip: +title: Blake2b Ethereum Implementation +author: James Hancock (@madeoftin) - Tjaden Hess (@tjade273) +discussions-to: https://ethereum-magicians.org/t/blake2b-f-precompile/3157/6 +status: Draft +type: Standards Track +category: Core +created: 2019-13-05 +requires: +replaces: +--- + + +This is the suggested template for new EIPs. + +Note that an EIP number will be assigned by an editor. When opening a pull request to submit your EIP, please use an abbreviated title in the filename, `eip-draft_title_abbrev.md`. + +The title should be 44 characters or less. + +## Simple Summary + +If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the EIP. + +## 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 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. + +## 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. + +## Alternative Implementations +Within the [Ethereum Magicans Thread](https://ethereum-magicians.org/t/blake2b-f-precompile/3157/11) it is noted that a seperate precompile may not be needed, instead optimizations to the EVM may be sufficient. This avenue will also be explored in the process of researching this EIP. + +## 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 + +TBD + +## Implementation + +The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details. + +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) + +## Further Notes + +James Hancock's role in this EIP is not as an author in the technical sense, but is acting as coordinator and point of contact for development of this EIP. Please reach out to him if you are an interested Developer. Special thanks to Tjaden Hess (@tjade273) who is the original author of [EIP 131](https://github.com/ethereum/EIPs/pull/131/) + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 36a784519d7b7cf74d9d3c218c35b26315fe7723 Mon Sep 17 00:00:00 2001 From: James Hancock Date: Mon, 13 May 2019 19:03:13 -0400 Subject: [PATCH 024/137] Renamed to eip-blake2b.md --- EIPS/{eip-Blake2b => eip-Blake2b.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename EIPS/{eip-Blake2b => eip-Blake2b.md} (100%) diff --git a/EIPS/eip-Blake2b b/EIPS/eip-Blake2b.md similarity index 100% rename from EIPS/eip-Blake2b rename to EIPS/eip-Blake2b.md From ef02974aac2676893b3bfab84ac182c6c9bacddd Mon Sep 17 00:00:00 2001 From: James Hancock Date: Mon, 13 May 2019 19:08:50 -0400 Subject: [PATCH 025/137] updated authors --- EIPS/eip-Blake2b.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-Blake2b.md b/EIPS/eip-Blake2b.md index a9d694bc27df5..8bf7db9d051b5 100644 --- a/EIPS/eip-Blake2b.md +++ b/EIPS/eip-Blake2b.md @@ -1,7 +1,7 @@ --- eip: title: Blake2b Ethereum Implementation -author: James Hancock (@madeoftin) - Tjaden Hess (@tjade273) +author: James Hancock <@madeoftin> , Tjaden Hess <@tjade273> discussions-to: https://ethereum-magicians.org/t/blake2b-f-precompile/3157/6 status: Draft type: Standards Track From 0d659c3ec12ebf9e60d46705eec8a35f9f1566e3 Mon Sep 17 00:00:00 2001 From: James Hancock Date: Mon, 13 May 2019 19:46:06 -0400 Subject: [PATCH 026/137] Updated to Historic EIP Number --- EIPS/eip-Blake2b.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-Blake2b.md b/EIPS/eip-Blake2b.md index 8bf7db9d051b5..961710d3ef6e6 100644 --- a/EIPS/eip-Blake2b.md +++ b/EIPS/eip-Blake2b.md @@ -1,5 +1,5 @@ --- -eip: +eip: EIP 131 title: Blake2b Ethereum Implementation author: James Hancock <@madeoftin> , Tjaden Hess <@tjade273> discussions-to: https://ethereum-magicians.org/t/blake2b-f-precompile/3157/6 From 7354cb4774b1d72161714c032831fcf451f43477 Mon Sep 17 00:00:00 2001 From: James Hancock Date: Mon, 13 May 2019 19:46:46 -0400 Subject: [PATCH 027/137] Number 2024 --- EIPS/eip-Blake2b.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-Blake2b.md b/EIPS/eip-Blake2b.md index 961710d3ef6e6..f5ae2cc62c1f5 100644 --- a/EIPS/eip-Blake2b.md +++ b/EIPS/eip-Blake2b.md @@ -1,5 +1,5 @@ --- -eip: EIP 131 +eip: EIP 2024 title: Blake2b Ethereum Implementation author: James Hancock <@madeoftin> , Tjaden Hess <@tjade273> discussions-to: https://ethereum-magicians.org/t/blake2b-f-precompile/3157/6 From 601cc3582b9c4b16b9a5f5323301e6b980f6fa64 Mon Sep 17 00:00:00 2001 From: James Hancock Date: Mon, 13 May 2019 19:50:15 -0400 Subject: [PATCH 028/137] Update eip-Blake2b.md --- EIPS/eip-Blake2b.md | 1 - 1 file changed, 1 deletion(-) diff --git a/EIPS/eip-Blake2b.md b/EIPS/eip-Blake2b.md index f5ae2cc62c1f5..d3250daf6f5dd 100644 --- a/EIPS/eip-Blake2b.md +++ b/EIPS/eip-Blake2b.md @@ -79,7 +79,6 @@ TBD ## Implementation -The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details. The Go implementation is available from [golang.org](golang.org/x/crypto/blake2b) as well as [on github](https://github.com/dchest/blake2b). From 46babcb554cfcc7bcc368a3b4a343635a5f482d0 Mon Sep 17 00:00:00 2001 From: James Hancock Date: Mon, 13 May 2019 19:53:08 -0400 Subject: [PATCH 029/137] Rename eip-Blake2b.md to eip-2024.md --- EIPS/{eip-Blake2b.md => eip-2024.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename EIPS/{eip-Blake2b.md => eip-2024.md} (100%) diff --git a/EIPS/eip-Blake2b.md b/EIPS/eip-2024.md similarity index 100% rename from EIPS/eip-Blake2b.md rename to EIPS/eip-2024.md From c260a55a4e21ac8141b3c776457657516a734e27 Mon Sep 17 00:00:00 2001 From: James Hancock Date: Mon, 13 May 2019 19:59:06 -0400 Subject: [PATCH 030/137] Update eip-2024.md --- EIPS/eip-2024.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-2024.md b/EIPS/eip-2024.md index d3250daf6f5dd..66e9a6a19cd56 100644 --- a/EIPS/eip-2024.md +++ b/EIPS/eip-2024.md @@ -1,5 +1,5 @@ --- -eip: EIP 2024 +eip: eip-2024 title: Blake2b Ethereum Implementation author: James Hancock <@madeoftin> , Tjaden Hess <@tjade273> discussions-to: https://ethereum-magicians.org/t/blake2b-f-precompile/3157/6 From f5927577e61854336ef5fb6eef2de16d9a19585b Mon Sep 17 00:00:00 2001 From: James Hancock Date: Mon, 13 May 2019 20:00:52 -0400 Subject: [PATCH 031/137] Update eip-2024.md --- EIPS/eip-2024.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-2024.md b/EIPS/eip-2024.md index 66e9a6a19cd56..9360a4215864d 100644 --- a/EIPS/eip-2024.md +++ b/EIPS/eip-2024.md @@ -1,5 +1,5 @@ --- -eip: eip-2024 +eip: 2024 title: Blake2b Ethereum Implementation author: James Hancock <@madeoftin> , Tjaden Hess <@tjade273> discussions-to: https://ethereum-magicians.org/t/blake2b-f-precompile/3157/6 From ebe1d11bd3aad2f43e56bfe561c091c3b5caceae Mon Sep 17 00:00:00 2001 From: James Hancock Date: Mon, 13 May 2019 20:03:15 -0400 Subject: [PATCH 032/137] Update eip-2024.md --- EIPS/eip-2024.md | 5 ----- 1 file changed, 5 deletions(-) diff --git a/EIPS/eip-2024.md b/EIPS/eip-2024.md index 9360a4215864d..adec8ddc5cbb5 100644 --- a/EIPS/eip-2024.md +++ b/EIPS/eip-2024.md @@ -12,11 +12,6 @@ replaces: --- -This is the suggested template for new EIPs. - -Note that an EIP number will be assigned by an editor. When opening a pull request to submit your EIP, please use an abbreviated title in the filename, `eip-draft_title_abbrev.md`. - -The title should be 44 characters or less. ## Simple Summary From 719318b9d224865e8c4154ba11a3c8ce3ba51c9a Mon Sep 17 00:00:00 2001 From: James Hancock Date: Mon, 13 May 2019 20:04:32 -0400 Subject: [PATCH 033/137] Update eip-2024.md --- EIPS/eip-2024.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-2024.md b/EIPS/eip-2024.md index adec8ddc5cbb5..756fecefd445b 100644 --- a/EIPS/eip-2024.md +++ b/EIPS/eip-2024.md @@ -15,7 +15,7 @@ replaces: ## Simple Summary -If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the EIP. +Special Projects wishes greater Ethereum interopability with Zcash, IPFS, and Handshake. Coincidentally, all of these projects use the Blake2 hash function. So, this is a request to add the Blake2b F precompile 11 to the Istanbul hardfork. The first special project here will probably be creating a wrapped ZEC (WZEC) within Ethereum as well as wrapped Ether within Zcash. After that, some yet-to-be-determined bridge architecture will allow Ethereum to benefit from Zcash’s shielded transactions. ## Abstract From 072efb9ee7b0400b19b2fc11949c1552263905cc Mon Sep 17 00:00:00 2001 From: James Hancock Date: Mon, 13 May 2019 20:04:52 -0400 Subject: [PATCH 034/137] Update eip-2024.md --- EIPS/eip-2024.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-2024.md b/EIPS/eip-2024.md index 756fecefd445b..8bb2fb253b4d5 100644 --- a/EIPS/eip-2024.md +++ b/EIPS/eip-2024.md @@ -1,7 +1,7 @@ --- eip: 2024 title: Blake2b Ethereum Implementation -author: James Hancock <@madeoftin> , Tjaden Hess <@tjade273> +author: James Hancock (@madeoftin) , Tjaden Hess (@tjade273) discussions-to: https://ethereum-magicians.org/t/blake2b-f-precompile/3157/6 status: Draft type: Standards Track From e403a10d9fb3a8e0c748c7e89a38694d99bb1092 Mon Sep 17 00:00:00 2001 From: James Hancock Date: Mon, 13 May 2019 20:13:50 -0400 Subject: [PATCH 035/137] Update eip-2024.md --- EIPS/eip-2024.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-2024.md b/EIPS/eip-2024.md index 8bb2fb253b4d5..f2e30cb659877 100644 --- a/EIPS/eip-2024.md +++ b/EIPS/eip-2024.md @@ -75,7 +75,7 @@ TBD ## Implementation -The Go implementation is available from [golang.org](golang.org/x/crypto/blake2b) as well as [on github](https://github.com/dchest/blake2b). +The Go implementation is available from [golang.org](https://golang.org/x/crypto/blake2b) as well as [on github](https://github.com/dchest/blake2b). Other languages: [Javascript implementation](https://github.com/dcposch/blakejs) From e774c4402a0131dc5b67bb59e3d762d7667f67e8 Mon Sep 17 00:00:00 2001 From: James Hancock Date: Mon, 13 May 2019 20:14:33 -0400 Subject: [PATCH 036/137] Update and rename eip-2024.md to eip-131.md --- EIPS/{eip-2024.md => eip-131.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename EIPS/{eip-2024.md => eip-131.md} (99%) diff --git a/EIPS/eip-2024.md b/EIPS/eip-131.md similarity index 99% rename from EIPS/eip-2024.md rename to EIPS/eip-131.md index f2e30cb659877..6becc99b3076c 100644 --- a/EIPS/eip-2024.md +++ b/EIPS/eip-131.md @@ -1,5 +1,5 @@ --- -eip: 2024 +eip: 131 title: Blake2b Ethereum Implementation author: James Hancock (@madeoftin) , Tjaden Hess (@tjade273) discussions-to: https://ethereum-magicians.org/t/blake2b-f-precompile/3157/6 From b4fcd681a37c07bc979bae3a1e09cb6d5c43e06a Mon Sep 17 00:00:00 2001 From: James Hancock Date: Mon, 13 May 2019 20:16:58 -0400 Subject: [PATCH 037/137] Update eip-131.md --- EIPS/eip-131.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-131.md b/EIPS/eip-131.md index 6becc99b3076c..da5ca77799e99 100644 --- a/EIPS/eip-131.md +++ b/EIPS/eip-131.md @@ -1,7 +1,7 @@ --- eip: 131 title: Blake2b Ethereum Implementation -author: James Hancock (@madeoftin) , Tjaden Hess (@tjade273) +author: James Hancock (@madeoftin) , Tjaden Hess (@tjade273) , Jay Graber discussions-to: https://ethereum-magicians.org/t/blake2b-f-precompile/3157/6 status: Draft type: Standards Track From 5e745da091a53deec63d7fa4e2b912bc735d6ed4 Mon Sep 17 00:00:00 2001 From: James Hancock Date: Mon, 13 May 2019 20:35:47 -0400 Subject: [PATCH 038/137] Updated Formatting to current standards --- EIPS/eip-9.md | 28 ++++++++++++++++++++-------- 1 file changed, 20 insertions(+), 8 deletions(-) diff --git a/EIPS/eip-9.md b/EIPS/eip-9.md index 3003824eb76e7..0a31eb3ae6599 100644 --- a/EIPS/eip-9.md +++ b/EIPS/eip-9.md @@ -1,11 +1,19 @@ -### Title - - Title: Add precompiled BLAKE2b contract - Author: Tjaden Hess & Jay Graber - Status: Draft - Type: Standard Track - Layer: Consensus (hard-fork) - Created 2016-06-30 +--- +eip: 131 +title: Blake2b Ethereum Implementation +author: James Hancock (@madeoftin) , Tjaden Hess (@tjade273) , Jay Graber +discussions-to: https://ethereum-magicians.org/t/blake2b-f-precompile/3157/6 +status: Draft +type: Standards Track +category: Core +created: 2019-13-05 +requires: +replaces: +--- + +## Simple Summary + +Special Projects wishes greater Ethereum interopability with Zcash, IPFS, and Handshake. Coincidentally, all of these projects use the Blake2 hash function. So, this is a request to add the Blake2b F precompile 11 to the Istanbul hardfork. The first special project here will probably be creating a wrapped ZEC (WZEC) within Ethereum as well as wrapped Ether within Zcash. After that, some yet-to-be-determined bridge architecture will allow Ethereum to benefit from Zcash’s shielded transactions. ## Abstract @@ -71,5 +79,9 @@ Other languages: [Java implementation](https://github.com/alphazero/Blake2b) [Python implementatoin](https://github.com/buggywhip/blake2_py) +## Further Notes + +James Hancock's role in this EIP is not as an author in the technical sense, but is acting as coordinator and point of contact for development of this EIP. Please reach out to him if you are an interested Developer. Special thanks to Tjaden Hess (@tjade273) who is the original author of [EIP 131](https://github.com/ethereum/EIPs/pull/131/) + ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 925841449e96258fb003cbbfdba0ee89aa20b667 Mon Sep 17 00:00:00 2001 From: James Hancock Date: Mon, 13 May 2019 20:36:12 -0400 Subject: [PATCH 039/137] Delete eip-131.md --- EIPS/eip-131.md | 90 ------------------------------------------------- 1 file changed, 90 deletions(-) delete mode 100644 EIPS/eip-131.md diff --git a/EIPS/eip-131.md b/EIPS/eip-131.md deleted file mode 100644 index da5ca77799e99..0000000000000 --- a/EIPS/eip-131.md +++ /dev/null @@ -1,90 +0,0 @@ ---- -eip: 131 -title: Blake2b Ethereum Implementation -author: James Hancock (@madeoftin) , Tjaden Hess (@tjade273) , Jay Graber -discussions-to: https://ethereum-magicians.org/t/blake2b-f-precompile/3157/6 -status: Draft -type: Standards Track -category: Core -created: 2019-13-05 -requires: -replaces: ---- - - - -## Simple Summary - -Special Projects wishes greater Ethereum interopability with Zcash, IPFS, and Handshake. Coincidentally, all of these projects use the Blake2 hash function. So, this is a request to add the Blake2b F precompile 11 to the Istanbul hardfork. The first special project here will probably be creating a wrapped ZEC (WZEC) within Ethereum as well as wrapped Ether within Zcash. After that, some yet-to-be-determined bridge architecture will allow Ethereum to benefit from Zcash’s shielded transactions. - -## 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 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. - -## 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. - -## Alternative Implementations -Within the [Ethereum Magicans Thread](https://ethereum-magicians.org/t/blake2b-f-precompile/3157/11) it is noted that a seperate precompile may not be needed, instead optimizations to the EVM may be sufficient. This avenue will also be explored in the process of researching this EIP. - -## 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 - -TBD - -## Implementation - - -The Go implementation is available from [golang.org](https://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) - -## Further Notes - -James Hancock's role in this EIP is not as an author in the technical sense, but is acting as coordinator and point of contact for development of this EIP. Please reach out to him if you are an interested Developer. Special thanks to Tjaden Hess (@tjade273) who is the original author of [EIP 131](https://github.com/ethereum/EIPs/pull/131/) - -## Copyright -Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 8613c5002a2fd6059ff0e020b03d1ed53bc20ecf Mon Sep 17 00:00:00 2001 From: James Hancock Date: Mon, 13 May 2019 20:36:23 -0400 Subject: [PATCH 040/137] Rename eip-9.md to eip-131.md --- EIPS/{eip-9.md => eip-131.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename EIPS/{eip-9.md => eip-131.md} (100%) diff --git a/EIPS/eip-9.md b/EIPS/eip-131.md similarity index 100% rename from EIPS/eip-9.md rename to EIPS/eip-131.md From ceaa65384b2d5daeaf087e3a05cbf8ac69e6f949 Mon Sep 17 00:00:00 2001 From: James Hancock Date: Mon, 13 May 2019 20:36:40 -0400 Subject: [PATCH 041/137] Update eip-131.md --- EIPS/eip-131.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-131.md b/EIPS/eip-131.md index 0a31eb3ae6599..e0ee3ab314f48 100644 --- a/EIPS/eip-131.md +++ b/EIPS/eip-131.md @@ -72,7 +72,7 @@ The community response to this EIP has been largely positive, and besides the "n ## Implementation -The Go implementation is available from [golang.org](golang.org/x/crypto/blake2b) as well as [on github](https://github.com/dchest/blake2b). +The Go implementation is available from [golang.org](https://golang.org/x/crypto/blake2b) as well as [on github](https://github.com/dchest/blake2b). Other languages: [Javascript implementation](https://github.com/dcposch/blakejs) From 5fa430f10aec5c9e7a6e5340b221ac489100d9df Mon Sep 17 00:00:00 2001 From: James Hancock Date: Mon, 13 May 2019 20:39:05 -0400 Subject: [PATCH 042/137] Update eip-131.md --- EIPS/eip-131.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-131.md b/EIPS/eip-131.md index e0ee3ab314f48..82a46b0eef0b4 100644 --- a/EIPS/eip-131.md +++ b/EIPS/eip-131.md @@ -1,7 +1,7 @@ --- eip: 131 title: Blake2b Ethereum Implementation -author: James Hancock (@madeoftin) , Tjaden Hess (@tjade273) , Jay Graber +author: Tjaden Hess (@tjade273) , Jay Graber , James Hancock (@madeoftin) , discussions-to: https://ethereum-magicians.org/t/blake2b-f-precompile/3157/6 status: Draft type: Standards Track From e79b430cfe94d31dfee609804c89f3dd1f85a3b2 Mon Sep 17 00:00:00 2001 From: James Hancock Date: Mon, 13 May 2019 20:39:19 -0400 Subject: [PATCH 043/137] Update eip-131.md --- EIPS/eip-131.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-131.md b/EIPS/eip-131.md index 82a46b0eef0b4..4b5349070a0cb 100644 --- a/EIPS/eip-131.md +++ b/EIPS/eip-131.md @@ -1,7 +1,7 @@ --- eip: 131 title: Blake2b Ethereum Implementation -author: Tjaden Hess (@tjade273) , Jay Graber , James Hancock (@madeoftin) , +author: Tjaden Hess (@tjade273) , Jay Graber , James Hancock (@madeoftin) discussions-to: https://ethereum-magicians.org/t/blake2b-f-precompile/3157/6 status: Draft type: Standards Track From 285c6f752a4fee62615f2fe9345863aaae040e75 Mon Sep 17 00:00:00 2001 From: James Hancock Date: Mon, 13 May 2019 23:22:34 -0400 Subject: [PATCH 044/137] Added a Gitter room in the "discussions to" field --- EIPS/eip-131.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-131.md b/EIPS/eip-131.md index 4b5349070a0cb..216cde6f786a5 100644 --- a/EIPS/eip-131.md +++ b/EIPS/eip-131.md @@ -2,7 +2,7 @@ eip: 131 title: Blake2b Ethereum Implementation author: Tjaden Hess (@tjade273) , Jay Graber , James Hancock (@madeoftin) -discussions-to: https://ethereum-magicians.org/t/blake2b-f-precompile/3157/6 +discussions-to: https://ethereum-magicians.org/t/blake2b-f-precompile/3157/6 https://gitter.im/EIPshepherding/eip-131 status: Draft type: Standards Track category: Core From 53dfa16d1282a13c4d436f1631be8b2232ab436c Mon Sep 17 00:00:00 2001 From: Pedro Gomes Date: Tue, 14 May 2019 14:02:05 -0400 Subject: [PATCH 045/137] EIP-2015: Wallet Update Chain Method (#2015) * Create eip-2015.md * Include JSON RPC method in title * add requires 155 * update nativeCurrency field for wallet_updateChain * EIP-2015 format review changes * Update EIP-2015 discussions-to link --- EIPS/eip-2015.md | 81 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 81 insertions(+) create mode 100644 EIPS/eip-2015.md diff --git a/EIPS/eip-2015.md b/EIPS/eip-2015.md new file mode 100644 index 0000000000000..f3f0a1878575d --- /dev/null +++ b/EIPS/eip-2015.md @@ -0,0 +1,81 @@ +--- +eip: 2015 +title: Wallet Update Chain JSON-RPC Method (`wallet_updateChain`) +author: Pedro Gomes (@pedrouid) +discussions-to: https://ethereum-magicians.org/t/eip-2015-wallet-update-chain-json-rpc-method-wallet-updatechain/3274 +status: Draft +type: Standards Track +category: ERC +created: 2019-05-12 +requires: 155, 1474 +--- + +## Simple Summary +Wallets can update the active chain when connected to a Dapp but not vice-versa, with `wallet_updateChain` the Dapp will be able to request this change from the Wallet. + +## Abstract +Dapp can request the Wallet to switch chains by providing the minimal parameters of `chainId`, `networkId`, `rpcUrl` and `nativeCurrency`. The Wallet will display a UI element to inform the user of this change. + +## Motivation +Wallet and Dapp communication rely on the present provider that acts as middleware between the two. Using JSON-RPC methods, the Dapp is able to access not only the active accounts but also the active chain. With [EIP-1102](https://eips.ethereum.org/EIPS/eip-1102) we introduced the ability for Dapps to request access to the active accounts and the Wallet is able to provide a simple UI to inform the user of this action however the same is not currently possible for switching chains. The current pattern is to display some UI to request the user to switch chains within the Dapp, however this could be easily improved by triggering a UI from the Wallet side that can be approved or rejected by the user instead. + +## Specification +The JSON RPC method will be part of `wallet_` namespaced methods which aim to improve the UX and interoperability between Dapps and Wallets. + +### Required Parameters +- chainId (number): the id of the chain complaint with EIP-155 +- networkId (number): the id of the chain's network +- rpcUrl (string): the url endpoint for RPC requests for this chain +- nativeCurrency (Object): includes two fields for `name` (string) and `symbol` (string) + + +### Best Practices +- The Wallet should display a UI view similar to a [EIP-1102](https://eips.ethereum.org/EIPS/eip-1102) informing the user that the currently connected Dapp wants to switch to the specified chain. +- the Wallet should default the rpcUrl to any existing endpoints matching a chainId known previously to the wallet, otherwise it will use the provided rpcUrl as a fallback. +- the Wallet should call the rpcUrl with `net_version` and `eth_chainId` to verify the provided chainId and networkId match the responses from the rpcUrl +- the Wallet should change all nativeCurrency symbols to the provided parameter + +### Example 1 +A JSON-RPC request from a Dapp to switch the Ethereum Goerli chain would be as follows: +```json +{ + "id":1, + "jsonrpc": "2.0", + "method": "wallet_updateChain", + "params": [ + { + "chainId": 5, + "networkId": 5, + "rpcUrl": "https://goerli.infura.io/v3/406405f9c65348f99d0d5c27104b2213", + "nativeCurrency": { + "name": "Goerli ETH", + "symbol": "gorETH" + } + } + ] +} +``` + +### Example 2 +A JSON-RPC request from a Dapp to switch the POA Network's xDAI chain would be as follows: +```json +{ + "id":1, + "jsonrpc": "2.0", + "method": "wallet_updateChain", + "params": [ + { + "chainId": 100, + "networkId": 100, + "rpcUrl": "https://dai.poa.network", + "nativeCurrency": { + "name": "xDAI", + "symbol": "xDAI" + } + } + ] +} +``` + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 90d9ce607c872f7a87e928d37a8d12983a3e8f28 Mon Sep 17 00:00:00 2001 From: Brooklyn Zelenka Date: Thu, 16 May 2019 13:04:57 -0700 Subject: [PATCH 046/137] Automatically merged updates to draft EIP(s) 1679 (#2034) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-1679.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/EIPS/eip-1679.md b/EIPS/eip-1679.md index 374cf6ed00bc2..4627ae4905028 100644 --- a/EIPS/eip-1679.md +++ b/EIPS/eip-1679.md @@ -28,13 +28,14 @@ This meta-EIP specifies the changes included in the Ethereum hardfork named Ista ### Proposed EIPs +- [EIP-615](https://eips.ethereum.org/EIPS/eip-615): Subroutines and Static Jumps for the EVM - [EIP-1057](https://eips.ethereum.org/EIPS/eip-1057): ProgPoW, a Programmatic Proof-of-Work - There is a [pending audit](https://medium.com/ethereum-cat-herders/progpow-audit-goals-expectations-75bb902a1f01), above and beyond standard security considerations, that should be evaluated prior to inclusion. -- [EIP-1108](https://eips.ethereum.org/EIPS/eip-1108): Reduce alt_bn128 precompile gas costs +- [EIP-1108](https://eips.ethereum.org/EIPS/eip-1108): Reduce alt_bn128 precompile gas costs - [EIP-1283](https://eips.ethereum.org/EIPS/eip-1283): Net gas metering for SSTORE without dirty maps - [EIP-1344](https://eips.ethereum.org/EIPS/eip-1344): Add ChainID opcode - [EIP-1352](https://eips.ethereum.org/EIPS/eip-1352): Specify restricted address range for precompiles/system contracts From 9ac83ee2a1a6a58bd2ec962215791cf5ffdd709d Mon Sep 17 00:00:00 2001 From: James Hancock Date: Thu, 16 May 2019 18:57:54 -0400 Subject: [PATCH 047/137] Update eip-131.md --- EIPS/eip-131.md | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/EIPS/eip-131.md b/EIPS/eip-131.md index 216cde6f786a5..36b54c2eef483 100644 --- a/EIPS/eip-131.md +++ b/EIPS/eip-131.md @@ -1,14 +1,12 @@ --- eip: 131 -title: Blake2b Ethereum Implementation -author: Tjaden Hess (@tjade273) , Jay Graber , James Hancock (@madeoftin) -discussions-to: https://ethereum-magicians.org/t/blake2b-f-precompile/3157/6 https://gitter.im/EIPshepherding/eip-131 +title: Add precompiled BLAKE2b contract +author: Tjaden Hess (@tjade273), Jay Graber, James Hancock (@madeoftin) +discussions-to: https://gitter.im/EIPshepherding/eip-131 status: Draft type: Standards Track category: Core -created: 2019-13-05 -requires: -replaces: +created: 2016-06-30 --- ## Simple Summary @@ -23,7 +21,7 @@ This EIP introduces a new precompiled contract which implements the BLAKE2b cryp 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. +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.cryptolux.org/images/b/b9/Equihash.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. From 9d73b0b7f424cea4663bc7a40de1d82811d0f860 Mon Sep 17 00:00:00 2001 From: James Hancock Date: Thu, 16 May 2019 19:20:53 -0400 Subject: [PATCH 048/137] updated backwards compatibility --- EIPS/eip-131.md | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/EIPS/eip-131.md b/EIPS/eip-131.md index 36b54c2eef483..c0ab6826f61a8 100644 --- a/EIPS/eip-131.md +++ b/EIPS/eip-131.md @@ -59,11 +59,7 @@ Note that the function can produce a variable-length digest, up to 64 bytes, whi ## 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. +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 `0x9` 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. ## Test Cases From 9f5008e9e1784d6ae305e65a2c8d27f5308cbd09 Mon Sep 17 00:00:00 2001 From: James Hancock Date: Thu, 16 May 2019 19:59:35 -0400 Subject: [PATCH 049/137] Added References and carterpy as an Author --- EIPS/eip-131.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/EIPS/eip-131.md b/EIPS/eip-131.md index c0ab6826f61a8..2445cdea81481 100644 --- a/EIPS/eip-131.md +++ b/EIPS/eip-131.md @@ -1,8 +1,8 @@ --- eip: 131 title: Add precompiled BLAKE2b contract -author: Tjaden Hess (@tjade273), Jay Graber, James Hancock (@madeoftin) -discussions-to: https://gitter.im/EIPshepherding/eip-131 +author: Tjaden Hess (@tjade273), Jay Graber, (@carterpy), James Hancock (@madeoftin) +discussions-to: https://ethereum-magicians.org/t/blake2b-f-precompile/3157 status: Draft type: Standards Track category: Core @@ -73,9 +73,11 @@ Other languages: [Java implementation](https://github.com/alphazero/Blake2b) [Python implementatoin](https://github.com/buggywhip/blake2_py) -## Further Notes +## References + + * [Gitter Channel](https://gitter.im/EIPshepherding/eip-131) + * [Original Issue](https://github.com/ethereum/EIPs/issues/152) -James Hancock's role in this EIP is not as an author in the technical sense, but is acting as coordinator and point of contact for development of this EIP. Please reach out to him if you are an interested Developer. Special thanks to Tjaden Hess (@tjade273) who is the original author of [EIP 131](https://github.com/ethereum/EIPs/pull/131/) ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 0ec6181771607c0f2b0eec95701af84442ec9b6c Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Fri, 17 May 2019 03:16:37 +0100 Subject: [PATCH 050/137] Automatically merged updates to draft EIP(s) 663 (#2038) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-663.md | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/EIPS/eip-663.md b/EIPS/eip-663.md index 47786a1d24a3a..fe42c2b768ffa 100644 --- a/EIPS/eip-663.md +++ b/EIPS/eip-663.md @@ -10,7 +10,7 @@ created: 2017-07-03 ## Abstract -`SWAP` and `DUP` instructions are limited to a stack depth of 16. Introduce two new instructions, `SWAPn` and `DUPn`, which lift this limitation and allow accessing the stack up to its full depth of 1024 items. +Currently, `SWAP` and `DUP` instructions are limited to a stack depth of 16. Introduce two new instructions, `SWAPn` and `DUPn`, which lift this limitation and allow accessing the stack up to its full depth of 1024 items. ## Motivation @@ -22,9 +22,12 @@ Introducing `SWAPn` and `DUPn` will provide an option to compilers to simplify a ## Specification +### Option A + Instructions `DUPn` (`0xb0`) and `SWAPn` (`0xb1`) are introduced, which take the top item from stack (referred to as `n`). If `n` exceeds 1024 or the current stack depth is less than `n`, then a stack underflow exception is issued. If the current stack depth is at the limit, a stack overflow exception is issued. +In both of these cases the EVM stops and all gas is consumed. Otherwise - for `DUPn` the stack item at depth `n` is duplicated at the top of the stack @@ -34,6 +37,20 @@ The gas cost for both instructions is set at 3. In reality the cost for such an Since both of these instructions require the top stack item to contain the position, it is still only possible to reach more than 16 stack items if there is at least one free stack slot. +This option has no effect no static analyzers, given no immediate value is introduced. + +### Option B + +The difference to Option A is that `DUPn` and `SWAPn` do not take the value of `n` from the top stack item, but instead encode it as a 16-bit big endian immediate value following the opcode. + +This results in wasting a byte in the cases of only referring to the top 255 stack items. + +### Option C + +This option extends Option A with two new instructions, `DUPSn` and `SWAPSn`, where the value of `n` is encoded as an 8-bit immediate value following the opcode. + +The value `n` has a range of 0 to 255, but otherwise the same rules apply as in Option A. + ## Rationale TBA From b55bd38afd432cc96b803079c4f68ee83c9cd67f Mon Sep 17 00:00:00 2001 From: "A. F. Dudley" Date: Fri, 17 May 2019 11:07:47 -0400 Subject: [PATCH 051/137] Automatically merged updates to draft EIP(s) 1679 (#2043) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-1679.md | 1 + 1 file changed, 1 insertion(+) diff --git a/EIPS/eip-1679.md b/EIPS/eip-1679.md index 4627ae4905028..17b0a6a39c029 100644 --- a/EIPS/eip-1679.md +++ b/EIPS/eip-1679.md @@ -40,6 +40,7 @@ This meta-EIP specifies the changes included in the Ethereum hardfork named Ista - [EIP-1344](https://eips.ethereum.org/EIPS/eip-1344): Add ChainID opcode - [EIP-1352](https://eips.ethereum.org/EIPS/eip-1352): Specify restricted address range for precompiles/system contracts - [EIP-1380](https://eips.ethereum.org/EIPS/eip-1380): Reduced gas cost for call to self +- [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559): Fee market change for ETH 1.0 chain - [EIP-1702](https://eips.ethereum.org/EIPS/eip-1702): Generalized account versioning scheme - [EIP-1706](https://eips.ethereum.org/EIPS/eip-1706): Disable SSTORE with gasleft lower than call stipend - [EIP-1803](https://eips.ethereum.org/EIPS/eip-1803): Rename opcodes for clarity From a1ff047fab03b90da0022cdb1451c9fbbde5c99d Mon Sep 17 00:00:00 2001 From: Brooklyn Zelenka Date: Fri, 17 May 2019 09:31:59 -0700 Subject: [PATCH 052/137] Automatically merged updates to draft EIP(s) 615 (#2044) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-615.md | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/EIPS/eip-615.md b/EIPS/eip-615.md index 3db860cfbe3c6..b584498d8a025 100644 --- a/EIPS/eip-615.md +++ b/EIPS/eip-615.md @@ -69,9 +69,9 @@ Especially important is efficient translation to and from [eWasm](https://github These forms > *`INSTRUCTION`* > -> *`INSTRUCTION x`* +> *`INSTRUCTION x`* > -> *`INSTRUCTION x, y`* +> *`INSTRUCTION x, y`* name an *`INSTRUCTION`* with no, one and two arguments, respectively. An instruction is represented in the bytecode as a single-byte opcode. Any arguments are laid out as immediate data bytes following the opcode inline, interpreted as fixed length, MSB-first, two's-complement, two-byte positive integers. (Negative values are reserved for extensions.) @@ -102,7 +102,7 @@ To support subroutines, `BEGINSUB`, `JUMPSUB`, and `RETURNSUB` are provided. Br #### Switches, Callbacks, and Virtual Functions -Dynamic jumps are also used for `O(1)` indirection: an address to jump to is selected to push on the stack and be jumped to. So we also propose two more instructions to provide for constrained indirection. We support these with vectors of `JUMPDEST` or `BEGINSUB` offsets stored inline, which can be selected with an index on the stack. That constrains validation to a specified subset of all possible destinations. The danger of quadratic blow up is avoided because it takes as much space to store the jump vectors as it does to code the worst case exploit. +Dynamic jumps are also used for `O(1)` indirection: an address to jump to is selected to push on the stack and be jumped to. So we also propose two more instructions to provide for constrained indirection. We support these with vectors of `JUMPDEST` or `BEGINSUB` offsets stored inline, which can be selected with an index on the stack. That constrains validation to a specified subset of all possible destinations. The danger of quadratic blow up is avoided because it takes as much space to store the jump vectors as it does to code the worst case exploit. Dynamic jumps to a `JUMPDEST` are used to implement `O(1)` jumptables, which are useful for dense switch statements. Wasm and most CPUs provide similar instructions. @@ -193,7 +193,7 @@ frame | 21 ______|___________ 22 <- SP ``` -and after pushing two arguments and branching with `JUMPSUB` to a `BEGINSUB 2, 3` +and after pushing two arguments and branching with `JUMPSUB` to a `BEGINSUB 2, 3` ``` PUSH 10 PUSH 11 @@ -256,7 +256,7 @@ _Execution_ is as defined in the [Yellow Paper](https://ethereum.github.io/yello >**5** Invalid instruction -We propose to expand and extend the Yellow Paper conditions to handle the new instructions we propose. +We propose to expand and extend the Yellow Paper conditions to handle the new instructions we propose. To handle the return stack we expand the conditions on stack size: >**2a** The size of the data stack does not exceed 1024. @@ -290,7 +290,7 @@ All of the remaining conditions we validate statically. #### Costs & Codes -All of the instructions are `O(1)` with a small constant, requiring just a few machine operations each, whereas a `JUMP` or `JUMPI` must do an O(log n) binary search of an array of `JUMPDEST` offsets before every jump. With the cost of `JUMPI` being _high_ and the cost of `JUMP` being _mid_, we suggest the cost of `JUMPV` and `JUMPSUBV` should be _mid_, `JUMPSUB` and `JUMPIF` should be _low_, and`JUMPTO` and the rest should be _verylow_. Measurement will tell. +All of the instructions are `O(1)` with a small constant, requiring just a few machine operations each, whereas a `JUMP` or `JUMPI` must do an `O(log n)` binary search of an array of `JUMPDEST` offsets before every jump. With the cost of `JUMPI` being _high_ and the cost of `JUMP` being _mid_, we suggest the cost of `JUMPV` and `JUMPSUBV` should be _mid_, `JUMPSUB` and `JUMPIF` should be _low_, and`JUMPTO` and the rest should be _verylow_. Measurement will tell. We suggest the following opcodes: ``` @@ -315,7 +315,7 @@ These changes would need to be implemented in phases at decent intervals: If desired, the period of deprecation can be extended indefinitely by continuing to accept code not versioned as new—but without validation. That is, by delaying or canceling phase 2. -Regardless, we will need a versioning scheme like [EIP-1702](https://github.com/ethereum/EIPs/pull/1702) to allow current code and EIP-615 code to coexist on the same blockchain. +Regardless, we will need a versioning scheme like [EIP-1702](https://github.com/ethereum/EIPs/pull/1702) to allow current code and EIP-615 code to coexist on the same blockchain. ## Rationale @@ -325,7 +325,7 @@ As described above, the approach was simply to deprecate the problematic dynamic ## Implementation -Implementation of this proposal need not be difficult. At the least, interpreters can simply be extended with the new opcodes and run unchanged otherwise. The new opcodes require only stacks for the frame pointers and return offsets and the few pushes, pops, and assignments described above. The bulk of the effort is the validator, which in most languages can almost be transcribed from the pseudocode above. +Implementation of this proposal need not be difficult. At the least, interpreters can simply be extended with the new opcodes and run unchanged otherwise. The new opcodes require only stacks for the frame pointers and return offsets and the few pushes, pops, and assignments described above. The bulk of the effort is the validator, which in most languages can almost be transcribed from the pseudocode above. A lightly tested C++ reference implementation is available in [Greg Colvin's Aleth fork.](https://github.com/gcolvin/aleth/tree/master/libaleth-interpreter) This version required circa 110 lines of new interpreter code and a well-commented, 178-line validator. @@ -346,7 +346,7 @@ Validating that jumps are to valid addresses takes two sequential passes over th is_sub[code_size] // is there a BEGINSUB at PC? is_dest[code_size] // is there a JUMPDEST at PC? sub_for_pc[code_size] // which BEGINSUB is PC in? - + bool validate_jumps(PC) { current_sub = PC @@ -366,7 +366,7 @@ Validating that jumps are to valid addresses takes two sequential passes over th is_dest[PC] = true sub_for_pc[PC] = current_sub } - + // check that targets are in subroutine for (PC = 0; instruction = bytecode[PC]; PC = advance_pc(PC)) { @@ -390,7 +390,7 @@ Note that code like this is already run by EVMs to check dynamic jumps, includin #### Subroutine Validation -This function can be seen as a symbolic execution of a subroutine in the EVM code, where only the effect of the instructions on the state being validated is computed. Thus the structure of this function is very similar to an EVM interpreter. This function can also be seen as an acyclic traversal of the directed graph formed by taking instructions as vertexes and sequential and branching connections as edges, checking conditions along the way. The traversal is accomplished via recursion, and cycles are broken by returning when a vertex which has already been visited is reached. The time complexity of this traversal is `O(|E|+|V|): The sum of the number of edges and number of verticies in the graph. +This function can be seen as a symbolic execution of a subroutine in the EVM code, where only the effect of the instructions on the state being validated is computed. Thus the structure of this function is very similar to an EVM interpreter. This function can also be seen as an acyclic traversal of the directed graph formed by taking instructions as vertexes and sequential and branching connections as edges, checking conditions along the way. The traversal is accomplished via recursion, and cycles are broken by returning when a vertex which has already been visited is reached. The time complexity of this traversal is `O(|E|+|V|)`: The sum of the number of edges and number of verticies in the graph. The basic approach is to call `validate_subroutine(i, 0, 0)`, for `i` equal to the first instruction in the EVM code through each `BEGINDATA` offset. `validate_subroutine()` traverses instructions sequentially, recursing when `JUMP` and `JUMPI` instructions are encountered. When a destination is reached that has been visited before it returns, thus breaking cycles. It returns true if the subroutine is valid, false otherwise. @@ -440,7 +440,7 @@ The basic approach is to call `validate_subroutine(i, 0, 0)`, for `i` equal to t return false if instruction is STOP, RETURN, or SUICIDE - return true + return true // violates single entry if instruction is BEGINSUB @@ -463,10 +463,10 @@ The basic approach is to call `validate_subroutine(i, 0, 0)`, for `i` equal to t if instruction is JUMPTO { PC = jump_target(PC) - continue + continue } - // recurse to jump to code to validate + // recurse to jump to code to validate if instruction is JUMPIF { if not validate_subroutine(jump_target(PC), return_pc, SP) From 495062dc492cb28023b2e0c0e280504c8e0226c5 Mon Sep 17 00:00:00 2001 From: James Hancock Date: Fri, 17 May 2019 17:00:43 -0400 Subject: [PATCH 053/137] Added to EIP-1679 for Istanbul --- EIPS/eip-1679.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/EIPS/eip-1679.md b/EIPS/eip-1679.md index 374cf6ed00bc2..3222ee7abd372 100644 --- a/EIPS/eip-1679.md +++ b/EIPS/eip-1679.md @@ -28,6 +28,7 @@ This meta-EIP specifies the changes included in the Ethereum hardfork named Ista ### Proposed EIPs +- [EIP-131] : Add Precompiled BLAKE2b Contract - [EIP-1057](https://eips.ethereum.org/EIPS/eip-1057): ProgPoW, a Programmatic Proof-of-Work - There is a @@ -45,6 +46,7 @@ This meta-EIP specifies the changes included in the Ethereum hardfork named Ista - [EIP-1829](https://eips.ethereum.org/EIPS/eip-1829): Precompile for Elliptic Curve Linear Combinations - [EIP-1884](https://eips.ethereum.org/EIPS/eip-1884): Repricing for trie-size-dependent opcodes + ## Timeline * 2019-05-17 (Fri) hard deadline to accept proposals for "Istanbul" From 9ed4e96857e436916c0c3df6879803166ba58ad5 Mon Sep 17 00:00:00 2001 From: Tom Brand <45038918+TomStarkWare@users.noreply.github.com> Date: Sat, 18 May 2019 03:26:00 +0300 Subject: [PATCH 054/137] Calldata gas cost reduction (#2028) * Calldata gas cost reduction Added a draft of EIP to reduce the gas cost of Calldata * changed name to 2028 * Added EIP-2028 to meta eip-1679 * Added discussion url * edited 'motivation' & 'specification' Edited motivation to increase readability. Edited specification to clarify terms. --- EIPS/eip-1679.md | 1 + EIPS/eip-2028.md | 75 ++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 76 insertions(+) create mode 100644 EIPS/eip-2028.md diff --git a/EIPS/eip-1679.md b/EIPS/eip-1679.md index 17b0a6a39c029..866cf7807e59e 100644 --- a/EIPS/eip-1679.md +++ b/EIPS/eip-1679.md @@ -46,6 +46,7 @@ This meta-EIP specifies the changes included in the Ethereum hardfork named Ista - [EIP-1803](https://eips.ethereum.org/EIPS/eip-1803): Rename opcodes for clarity - [EIP-1829](https://eips.ethereum.org/EIPS/eip-1829): Precompile for Elliptic Curve Linear Combinations - [EIP-1884](https://eips.ethereum.org/EIPS/eip-1884): Repricing for trie-size-dependent opcodes +- [EIP-2028](https://eips.ethereum.org/EIPS/eip-2028): Calldata gas cost reduction ## Timeline diff --git a/EIPS/eip-2028.md b/EIPS/eip-2028.md new file mode 100644 index 0000000000000..e5fbb8a28af0c --- /dev/null +++ b/EIPS/eip-2028.md @@ -0,0 +1,75 @@ +--- +eip: 2028 +title: Calldata gas cost reduction +author: Alexey Akhunov(@AlexeyAkhunov), Eli Ben Sasson (eli@starkware.co), Tom Brand (tom@starkware.co), Avihu Levy (avihu@starkware.co) +discussions-to: https://ethereum-magicians.org/t/eip-2028-calldata-gas-cost-reduction/3280 +status: Draft +type: Standards Track +category: Core +created: 2019-05-03 +--- + +## Simple Summary +We propose to reduce the gas cost of Calldata (`GTXDATANONZERO`) from its current value of 68 gas per byte to a lower cost, to be backed by mathematical modeling and empirical estimates. The mathematical model is the one used in the works of Sompolinsky and Zohar [1] and Pass, Seeman and Shelat [2], which relates network security to network delay. We shall (1) evaluate the theoretical impact of lower Calldata gas cost on network delay using this model, (2) validate the model empirically, and (3) base the proposed gas cost on our findings. + +## Motivation +There are a couple of main benefits to accepting this proposal and lowering gas cost of Calldata +On-Chain Scalability: Generally speaking, higher bandwidth of Calldata improves scalability, as more data can fit within a single block. +* Layer two scalability: Layer two scaling solutions can improve scalability by moving storage and computation off-chain, but often introduce data transmission instead. + - Proof systems such as STARKs and SNARKs use a single proof that attests to the computational integrity of a large computation, say, one that processes a large batch of transactions. + - Some solutions use fraud proofs which requires a transmission of merkle proofs. + - Moreover, one optional data availability solution to layer two is to place data on the main chain, via Calldata. +* Stateless clients: The same model will be used to determine the price of the state access for the stateless client regime, which will be proposed in the State Rent (from version 4). There, it is expected that the gas cost of state accessing operation will increase roughly proportional to the extra bandwidth required to transmit the “block proofs” as well as extra processing required to verify those block proofs. + +## Specification +The gas per non-zero byte is reduced from 68 to TBD. Gas cost of zero bytes is unchanged. + +## Rationale +Roughly speaking, reducing the gas cost of Calldata leads to potentially larger blocks, which increases the network delay associated with data transmission over the network. This is only part of the full network delay, other factors are block processing time (and storage access, as part of it). Increasing network delay affects security by lowering the cost of attacking the network, because at any given point in time fewer nodes are updated on the latest state of the blockchain. + +Yonatan Sompolinsky and Aviv Zohar suggested in [1] an elegant model to relate network delay to network security, and this model is also used in the work of Rafael Pass, Lior Seeman and Abhi Shelat [2]. We briefly explain this model below, because we shall study it theoretically and validate it by empirical measurements to reach the suggested lower gas cost for Calldata. + +The model uses the following natural parameters: +* _lambda_ denotes the block creation rate [1/s]: We treat the process of finding a PoW +solution as a poisson process with rate _lambda_. +* _beta_ - chain growth rate [1/s]: the rate at which new blocks are added to +the heaviest chain. +* _D_ - block delay [s]: The time that elapses between the mining of a new block and its acceptance by all the miners (all miners switched to mining on top of that block). + +### _Beta_ Lower Bound +Notice that _lambda_ => _beta_, because not all blocks that are found will enter the main chain (as is the case with uncles). In [1] it was shown that for a blockchain using the longest chain rule, one may bound _beta_ from below by _lambda_/ (1+ D * _lambda_). This lower bound holds in the extremal case where the topology of the network is a clique in which the delay between each pair of nodes is D, the maximal possible delay. Recording both the lower and upper bounds on _beta_ we get + + _lambda_ >= _beta_ >= _lambda_ / (1 + D * _lambda_) (*) + +Notice, as a sanity check, that when there is no delay (D=0) then _beta_ equals _lambda_, as expected. + +### Security of the network +An attacker attempting to reorganize the main chain needs to generate blocks at a rate that is greater than _beta_. +Fixing the difficulty level of the PoW puzzle, the total hash rate in the system is correlated to _lambda_. Thus, _beta_ / _lambda_ is defined as the the *efficiency* of the system, as it measures the fraction of total hash power that is used to generate the main chain of the network. + +Rearranging (*) gives the following lower bound on efficiency in terms of delay: + + _beta_ / _lambda_ >= 1 / (1 + D * _lambda_) (**) + +### The _delay_ parameter D +The network delay depends on the location of the mining node within the network and on the current network topology (which changes dynamically), and consequently is somewhat difficult to measure directly. +Previously, Christian Decker and Roger Wattenhofer [3] showed that propagation time scales with blocksize, and Vitalik Buterin showed that uncle rate, which is tightly related to efficiency (**) measure, also scales with block size [4]. + +However, the delay function can be decomposed into two parts D = *D_t* + *D_p*, where _D_t_ is the delay caused by the transmission of the block and _D_p_ is the delay caused by the processing of the block by the node. Our model and tests will examine the effect of Calldata on each of _D_t_ and _D_p_, postulating that their effect is different. This may be particularly relevant for Layer 2 Scalability and for Stateless Clients (Rationales 2, 3 above) because most of the Calldata associated with these goals are Merkle authentication paths that have a large _D_t_ component but relatively small _D_p_ values. + +## Test Cases +To suggest the gas cost of calldata we shall conduct two types of tests: +1. Network tests, conducted on the Ethereum mainnet, used to estimate the effect on increasing block size on _D_p_ and _D_t_, on the overall network delay D and the efficiency ratio (**), as well as delays between different mining pools. Those tests will include regression tests on existing data, and stress tests to introduce extreme scenarios. +2. Local tests, conducted on a single node and measuring the processing time as a function of Calldata amount and general computation limits. + +## References +[1] Yonatan Sompolinsky, Aviv Zohar: [Secure High-Rate Transaction Processing in Bitcoin](https://eprint.iacr.org/2013/881.pdf). Financial Cryptography 2015: 507-527 + +[2] Rafael Pass, Lior Seeman, Abhi Shelat: [Analysis of the Blockchain Protocol in Asynchronous Networks](https://eprint.iacr.org/2016/454.pdf), ePrint report 2016/454 + +[3] Christian Decker, Roger Wattenhofer: [Information propagation in the Bitcoin network](http://www.gsd.inesc-id.pt/~ler/docencia/rcs1314/papers/P2P2013_041.pdf). P2P 2013: 1-10 + +[4] Vitalik Buterin: [Uncle Rate and Transaction Fee Analysis](https://blog.ethereum.org/2016/10/31/uncle-rate-transaction-fee-analysis/) + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 5e6d4885f965dd7a54c9e665832d9ba2e25088c5 Mon Sep 17 00:00:00 2001 From: Andrew Cooke Date: Sat, 18 May 2019 11:16:55 -0400 Subject: [PATCH 055/137] Automatically merged updates to draft EIP(s) 1155 (#2049) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-1155.md | 56 +++++++++++++++++++++++++++++------------------- 1 file changed, 34 insertions(+), 22 deletions(-) diff --git a/EIPS/eip-1155.md b/EIPS/eip-1155.md index 322738e3741b1..f7c1de4813aac 100644 --- a/EIPS/eip-1155.md +++ b/EIPS/eip-1155.md @@ -1,7 +1,7 @@ --- eip: 1155 title: ERC-1155 Multi Token Standard -author: Witek Radomski , Andrew Cooke , Philippe Castonguay , James Therien , Eric Binet +author: Witek Radomski , Andrew Cooke , Philippe Castonguay , James Therien , Eric Binet , Ronan Sandford type: Standards Track category: ERC status: Draft @@ -13,7 +13,7 @@ requires: 165 ## Simple Summary -A standard interface for contracts that manage multiple token types. A single deployed contract may include any combination of fungible tokens, non-fungible tokens, or other configurations (for example, semi-fungible tokens). +A standard interface for contracts that manage multiple token types. A single deployed contract may include any combination of fungible tokens, non-fungible tokens, or other configurations (e.g. semi-fungible tokens). ## Abstract @@ -84,13 +84,13 @@ interface ERC1155 /* is ERC165 */ { MUST revert if `_to` is the zero address. MUST revert if balance of holder for token `_id` is lower than the `_value` sent. MUST revert on any other error. - After the above conditions are met, this function MUST check if `_to` is a smart contract (eg. code size > 0). If so, it MUST call `onERC1155Received` on `_to` and act appropriately (see "Safe Transfer Rules" section of the standard). - MUST emit `TransferSingle` event on transfer success (see "Safe Transfer Rules" section of the standard). + MUST emit the `TransferSingle` event to reflect the balance change (see "Safe Transfer Rules" section of the standard). + After the above conditions are met, this function MUST check if `_to` is a smart contract (e.g. code size > 0). If so, it MUST call `onERC1155Received` on `_to` and act appropriately (see "Safe Transfer Rules" section of the standard). @param _from Source address @param _to Target address @param _id ID of the token type @param _value Transfer amount - @param _data Additional data with no specified format, MUST be sent in call to `onERC1155Received` on `_to` + @param _data Additional data with no specified format, MUST be sent unaltered in call to `onERC1155Received` on `_to` */ function safeTransferFrom(address _from, address _to, uint256 _id, uint256 _value, bytes calldata _data) external; @@ -100,15 +100,15 @@ interface ERC1155 /* is ERC165 */ { MUST revert if `_to` is the zero address. MUST revert if length of `_ids` is not the same as length of `_values`. MUST revert if any of the balance(s) of the holder(s) for token(s) in `_ids` is lower than the respective amount(s) in `_values` sent to the recipient. - MUST revert on any other error. - Transfers and events MUST follow the ordering of the arrays (_ids[0]/_values[0] before _ids[1]/_values[1], etc). - After the above conditions for the transfer(s) in the batch are met, this function MUST check if `_to` is a smart contract (eg. code size > 0). If so, it MUST call the relevant `ERC1155TokenReceiver` hook(s) on `_to` and act appropriately (see "Safe Transfer Rules" section of the standard). - MUST emit `TransferSingle` or `TransferBatch` event(s) on transfer success (see "Safe Transfer Rules" section of the standard). + MUST revert on any other error. + MUST emit `TransferSingle` or `TransferBatch` event(s) such that all the balance changes are reflected (see "Safe Transfer Rules" section of the standard). + Balance changes and events MUST follow the ordering of the arrays (_ids[0]/_values[0] before _ids[1]/_values[1], etc). + After the above conditions for the transfer(s) in the batch are met, this function MUST check if `_to` is a smart contract (e.g. code size > 0). If so, it MUST call the relevant `ERC1155TokenReceiver` hook(s) on `_to` and act appropriately (see "Safe Transfer Rules" section of the standard). @param _from Source address @param _to Target address @param _ids IDs of each token type (order and length must match _values array) @param _values Transfer amounts per token type (order and length must match _ids array) - @param _data Additional data with no specified format, MUST be sent in call to the `ERC1155TokenReceiver` hook(s) on `_to` + @param _data Additional data with no specified format, MUST be sent unaltered in call to the `ERC1155TokenReceiver` hook(s) on `_to` */ function safeBatchTransferFrom(address _from, address _to, uint256[] calldata _ids, uint256[] calldata _values, bytes calldata _data) external; @@ -193,13 +193,13 @@ interface ERC1155TokenReceiver { This function MUST NOT consume more than 5,000 gas. @return `bytes4(keccak256("isERC1155TokenReceiver()"))` */ - function isERC1155TokenReceiver() external pure returns (bytes4); + function isERC1155TokenReceiver() external view returns (bytes4); } ``` ### Safe Transfer Rules -To be more explicit about how safeTransferFrom and safeBatchTransferFrom MUST operate with respect to the `ERC1155TokenReceiver`, a list of scenarios and rules follows. +To be more explicit about how safeTransferFrom and safeBatchTransferFrom MUST operate with respect to the `ERC1155TokenReceiver` hook functions, a list of scenarios and rules follows. #### Scenarios @@ -219,22 +219,30 @@ To be more explicit about how safeTransferFrom and safeBatchTransferFrom MUST op **_Scenario#5 :_** The receiver implements the necessary `ERC1155TokenReceiver` interface function(s) but throws an error. * The transfer MUST be reverted. -**_Scenario#6 :_** The receiver implements the `ERC1155TokenReceiver` interface and is the recipient of one and only one balance change (eg. safeTransferFrom called). +**_Scenario#6 :_** The receiver implements the `ERC1155TokenReceiver` interface and is the recipient of one and only one balance change (e.g. safeTransferFrom called). * All the balances in the transfer MUST have been updated to match the senders intent before any hook is called on a recipient. +* All the transfer events for the transfer MUST have been emitted to reflect the balance changes before any hook is called on a recipient. * One of `onERC1155Received` or `onERC1155BatchReceived` MUST be called on the recipient. * The `onERC1155Received` hook SHOULD be called on the recipient contract and its rules followed. - See "onERC1155Received rules" for further rules that MUST be followed. * The `onERC1155BatchReceived` hook MAY be called on the recipient contract and its rules followed. - See "onERC1155BatchReceived rules" for further rules that MUST be followed. -**_Scenario#7 :_** The receiver implements the `ERC1155TokenReceiver` interface and is the recipient of more than one balance change (eg. safeBatchTransferFrom called). +**_Scenario#7 :_** The receiver implements the `ERC1155TokenReceiver` interface and is the recipient of more than one balance change (e.g. safeBatchTransferFrom called). * All the balances in the transfer MUST have been updated to match the senders intent before any hook is called on a recipient. +* All the transfer events for the transfer MUST have been emitted to reflect the balance changes before any hook is called on a recipient. * `onERC1155Received` or `onERC1155BatchReceived` MUST be called on the recipient as many times as necessary such that every balance change for the recipient in the scenario is accounted for. - The return magic value for every hook call MUST be checked and acted upon as per "onERC1155Received rules" and "onERC1155BatchReceived rules". * The `onERC1155BatchReceived` hook SHOULD be called on the recipient contract and its rules followed. - See "onERC1155BatchReceived rules" for further rules that MUST be followed. * The `onERC1155Received` hook MAY be called on the recipient contract and its rules followed. - See "onERC1155Received rules" for further rules that MUST be followed. + +**_Scenario#8 :_** You are the creator of a contract that implements the `ERC1155TokenReceiver` interface and you forward the token(s) onto another address in one or both of `onERC1155Received` and `onERC1155BatchReceived`. +* Forwarding should be considered acceptance and then initiating a new `safeTransferFrom` or `safeBatchTransferFrom` in a new context. + - The prescribed keccak256 acceptance value magic for the receiver hook being called MUST be returned after forwarding is successful. +* The `_data` argument MAY be re-purposed for the new context. +* If forwarding unexpectedly fails the transaction MUST be reverted. #### Rules @@ -243,8 +251,8 @@ To be more explicit about how safeTransferFrom and safeBatchTransferFrom MUST op * MUST revert if `_to` is the zero address. * MUST revert if balance of holder for token `_id` is lower than the `_value` sent to the recipient. * MUST revert on any other error. -* After the above conditions are met, this function MUST check if `_to` is a smart contract (eg. code size > 0). If so, it MUST call `onERC1155Received` on `_to` and act appropriately (see "onERC1155Received rules" section). -* MUST emit `TransferSingle` event on transfer success (see "TransferSingle and TransferBatch event rules" section). +* MUST emit the `TransferSingle` event to reflect the balance change (see "TransferSingle and TransferBatch event rules" section). +* After the above conditions are met, this function MUST check if `_to` is a smart contract (e.g. code size > 0). If so, it MUST call `onERC1155Received` on `_to` and act appropriately (see "onERC1155Received rules" section). **_safeBatchTransferFrom rules:_** * Caller must be approved to manage all the tokens being transferred out of the `_from` account (see "Approval" section). @@ -252,9 +260,9 @@ To be more explicit about how safeTransferFrom and safeBatchTransferFrom MUST op * MUST revert if length of `_ids` is not the same as length of `_values`. * MUST revert if any of the balance(s) of the holder(s) for token(s) in `_ids` is lower than the respective amount(s) in `_values` sent to the recipient. * MUST revert on any other error. -* After the above conditions are met, this function MUST check if `_to` is a smart contract (eg. code size > 0). If so, it MUST call `onERC1155Received` or `onERC1155BatchReceived` on `_to` and act appropriately (see "`onERC1155Received` and onERC1155BatchReceived rules" section). -* MUST emit `TransferSingle` or `TransferBatch` event(s) on transfer success (see "TransferSingle and TransferBatch event rules" section). -* Transfers and events MUST occur in the array order they were submitted (_ids[0]/_values[0] before _ids[1]/_values[1], etc). +* MUST emit `TransferSingle` or `TransferBatch` event(s) such that all the balance changes are reflected (see "TransferSingle and TransferBatch event rules" section). +* The balance changes and events MUST occur in the array order they were submitted (_ids[0]/_values[0] before _ids[1]/_values[1], etc). +* After the above conditions are met, this function MUST check if `_to` is a smart contract (e.g. code size > 0). If so, it MUST call `onERC1155Received` or `onERC1155BatchReceived` on `_to` and act appropriately (see "`onERC1155Received` and onERC1155BatchReceived rules" section). **_TransferSingle and TransferBatch event rules:_** * `TransferSingle` SHOULD be used to indicate a single balance transfer has occurred between a `_from` and `_to` pair. @@ -278,6 +286,8 @@ To be more explicit about how safeTransferFrom and safeBatchTransferFrom MUST op - When burning/destroying tokens, the `_to` argument MUST be set to `0x0` (i.e. zero address). * The total value transferred from address 0x0 minus the total value transferred to 0x0 MAY be used by clients and exchanges to be added to the "circulating supply" for a given token ID. * To broadcast the existence of a token ID with no initial balance, the contract SHOULD emit the `TransferSingle` event from `0x0` to `0x0`, with the token creator as `_operator`, and a `_value` of 0. +* All `TransferSingle` and `TransferBatch` events MUST be emitted to reflect all the balance changes that have occurred before any call(s) to `onERC1155Received` or `onERC1155BatchReceived`. + - To make sure event order is correct in the case of valid re-entry (e.g. if a receiver contract forwards tokens on receipt) state balance and events balance MUST match before calling an external contract. **_onERC1155Received rules:_** * The `_operator` argument MUST be the address of the account/contract that initiated the transfer (i.e. msg.sender). @@ -285,7 +295,8 @@ To be more explicit about how safeTransferFrom and safeBatchTransferFrom MUST op - `_from` MUST be 0x0 for a mint. * The `_id` argument MUST be the token type being transferred. * The `_value` argument MUST be the number of tokens the holder balance is decreased by and match what the recipient balance is increased by. -* The `_data` argument MUST contain the extra information provided by the sender for the transfer. +* The `_data` argument MUST contain the unaltered information provided by the sender for the transfer. + - i.e. it MUST pass on the unaltered `_data` argument sent via the `safeTransferFrom` or `safeBatchTransferFrom` call for this transfer. * The recipient contract MAY accept an increase of its balance by returning the acceptance magic value `bytes4(keccak256("accept_erc1155_tokens()"))` - If the return value is `bytes4(keccak256("accept_erc1155_tokens()"))` the transfer MUST be completed or MUST revert if any other conditions are not met for success. * The recipient contract MAY reject an increase of its balance by calling revert. @@ -301,7 +312,8 @@ To be more explicit about how safeTransferFrom and safeBatchTransferFrom MUST op - `_from` MUST be 0x0 for a mint. * The `_ids` argument MUST be the list of tokens being transferred. * The `_values` argument MUST be the list of number of tokens (matching the list and order of tokens specified in `_ids`) the holder balance is decreased by and match what the recipient balance is increased by. -* The `_data` argument MUST contain the information provided by the sender for a transfer. +* The `_data` argument MUST contain the unaltered information provided by the sender for the transfer. + - i.e. it MUST pass on the unaltered `_data` argument sent via the `safeTransferFrom` or `safeBatchTransferFrom` call for this transfer. * The recipient contract MAY accept an increase of its balance by returning the acceptance magic value `bytes4(keccak256("accept_batch_erc1155_tokens()"))` - If the return value is `bytes4(keccak256("accept_batch_erc1155_tokens()"))` the transfer MUST be completed or MUST revert if any other conditions are not met for success. * The recipient contract MAY reject an increase of its balance by calling revert. @@ -314,7 +326,7 @@ To be more explicit about how safeTransferFrom and safeBatchTransferFrom MUST op **_isERC1155TokenReceiver rules:_** * The implementation of `isERC1155TokenReceiver` function SHOULD be as follows: ``` - function isERC1155TokenReceiver() external pure returns (bytes4) { + function isERC1155TokenReceiver() external view returns (bytes4) { return 0x0d912442; // bytes4(keccak256("isERC1155TokenReceiver()")) } ``` From 433a6ce99825b134e3c5dbf6792667f7331ad941 Mon Sep 17 00:00:00 2001 From: Ronan Sandford Date: Sun, 19 May 2019 07:51:33 +0100 Subject: [PATCH 056/137] EIP-1965 Method to check if a chainID is valid at a specific block Number (#1965) --- EIPS/eip-1965.md | 63 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 63 insertions(+) create mode 100644 EIPS/eip-1965.md diff --git a/EIPS/eip-1965.md b/EIPS/eip-1965.md new file mode 100644 index 0000000000000..ff432fa0c11b1 --- /dev/null +++ b/EIPS/eip-1965.md @@ -0,0 +1,63 @@ +--- +eip: 1965 +title: Method to check if a chainID is valid at a specific block Number +author: Ronan Sandford (@wighawag) +category: Core +type: Standards Track +discussions-to: https://ethereum-magicians.org/t/eip-1965-valid-chainid-for-specific-blocknumber-protect-all-forks/3181 +status: Draft +created: 2019-04-20 +requires: 155 +--- + +## Abstract +This EIP adds a precompile that returns whether a specific chainID (EIP-155 unique identifier) is valid at a specific blockNumber. ChainID are assumed to be valid up to the blockNumber at which they get replaced by a new chainID. + +## Motivation +[EIP-155](https://eips.ethereum.org/EIPS/eip-155) proposes to use the chain ID to prevent the replay of transactions between different chains. It would be a great benefit to have the same possibility inside smart contracts when handling off-chain message signatures, especially for Layer 2 signature schemes using [EIP-712](https://eips.ethereum.org/EIPS/eip-712). + +[EIP-1344](http://eips.ethereum.org/EIPS/eip-1344) is attempting to solve this by giving smart contract access to the tip of the chainID history. This is insuficient as such value is changing. Hence why EIP-1344 describes a contract based solution to work arround the problem. It would be better to solve it in a simpler, cheaper and safer manner, removing the potential risk of misuse present in EIP-1344. Furthermore EIP-1344 can't protect replay properly for minority-led hardfork as the caching system cannot guarantee accuracy of the blockNumber at which the new chainID has been introduced. + +[EIP-1959](https://github.com/ethereum/EIPs/pull/1959) solves the issue of EIP-1344 but do not attempt to protect from minority-led hardfork as mentioned in the rationale. We consider this a mistake, since it remove some freedom to fork. We consider that all fork should be given equal oportunities. And while there will always be issues we can't solve for the majority that ignore a particular fork, **users that decide to use both the minority-fork and the majority-chain should be protected from replay without having to wait for the majority chain to update its chainID.** + +## Specification +Adds a new precompile which uses 2 argument : a 32 bytes value that represent the chainID to test and a 32 bytes value representing the blockNumber at which the chainID is tested. It return 0x1 if the chainID is valid at the specific blockNumber, 0x0 otherwise. Note that chainID are considered valid up to the blockNumber at which they are replaced. So they are valid for every blockNumber past their replacement. + +The operation will costs no more than `G_blockhash` + `G_verylow` to execute. This could be lower as chainID are only introduced during hardfork. + +The cost of the operation might need to be adjusted later as the number of chainID in the history of the chain grows. + +Note though that the alternative to keep track of old chainID is to implement a smart contract based caching solution as EIP-1344 proposes comes with an overall higher gas cost and exhibit issues for minority-led hardfork (see Rationale section below). As such the gas cost is simply a necessary cost for the feature. + +## Rationale + +The rationale at EIP-1959 applies here as well too : + +- An opcode is better than a caching system for past chainID, It is cheaper, safer and do not include gaps. +- Direct access to the latest chainID is dangerous since it make it easy for contract to use it as a replay protection mechanism while preventing otherwise valid old messages to be valid after a fork that change the chainID. This can have disastrous consequences on users. +- all off-chain messaged signed before a fork should be valid across all side of the fork. + +The only difference is that this current proposal propose a solution to protect hardfork led by a minority. + +To summarize there is 2 possible fork scenario : + +1) The majority decide to make an hardfork but a minority disagree with it (ETC is such example). The fork is planned for block X. If the majority is not taking any action to automate the process of assigning a different chainID for both, the minority has plenty of time to plan for a chainID upgrade to happen at that same block X. Now if they do not do it, their users will face the problem that their messages will be replayable on the majority chain (Note that this is not true the other way around as we assume the majority decided to change the chainID). As such there is no reason that they’ll leave it that way. + +2) A minority decide to create an hardfork that the majority disagree with (or simply ignore). Now, the same as above can happen but since we are talking about a minority there is a chance that the majority do not care about the minority. In that case, there would be no incentive for the majority to upgrade the chainID. This means that user of both side of the fork will have the messages meant for the majority chain replayable on the minority-chain (even if this one changed its chainID) unless extra precaution is taken. + +The solution is to add the blockNumber representing the time at which the message was signed and use it as an argument to the opcode proposed here. This way, when the minority forks with a new chainID, the previous chainID become invalid from that time onward. So new messages destinated to the majority chain can't be replayed on the minority fork. + + +## Backwards Compatibility + +EIP-712 is still in draft but would need to be updated to include the blockNumber as part of the values that wallets need to verify for the protection of their users. + +Since chainID and blockNumber will vary, they should not be part of the domain separator (meant to be generated once) but another part of the message. + +While the pair could be optional for contract that do not care about replays or have other ways to prevent them, if chainID is present, the blockNumber must be present too. And if any of them is present, wallet need to ensure that the chainID is indeed the latest one of the chain being used, while the blockNumber is the latest one at the point of signing. During fork transition, the wallet can use the blockNumber to know which chainID to use. + +## References +This was previously suggested as part of [EIP1959 discussion](https://ethereum-magicians.org/t/eip-1959-valid-chainid-opcode/3170). + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). \ No newline at end of file From af982f1470624791da334b09d3e4f2e4de5e1265 Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Sun, 19 May 2019 07:54:10 +0100 Subject: [PATCH 057/137] Run spelling checks on CI (#2040) --- .codespell-whitelist | 7 +++++++ .travis-ci.sh | 2 ++ .travis.yml | 5 ++++- EIPS/eip-1011.md | 4 ++-- EIPS/eip-1015.md | 8 ++++---- EIPS/eip-1057.md | 6 +++--- EIPS/eip-1066.md | 12 ++++++------ EIPS/eip-107.md | 8 ++++---- EIPS/eip-1077.md | 4 ++-- EIPS/eip-1078.md | 2 +- EIPS/eip-1080.md | 2 +- EIPS/eip-1081.md | 2 +- EIPS/eip-1108.md | 2 +- EIPS/eip-1109.md | 4 ++-- EIPS/eip-1123.md | 2 +- EIPS/eip-1154.md | 2 +- EIPS/eip-1155.md | 2 +- EIPS/eip-1167.md | 2 +- EIPS/eip-1186.md | 2 +- EIPS/eip-1193.md | 2 +- EIPS/eip-1202.md | 2 +- EIPS/eip-1261.md | 4 ++-- EIPS/eip-1271.md | 2 +- EIPS/eip-1283.md | 2 +- EIPS/eip-1380.md | 2 +- EIPS/eip-1388.md | 2 +- EIPS/eip-1417.md | 12 ++++++------ EIPS/eip-145.md | 2 +- EIPS/eip-1450.md | 2 +- EIPS/eip-1462.md | 2 +- EIPS/eip-1470.md | 2 +- EIPS/eip-1484.md | 10 +++++----- EIPS/eip-1485.md | 6 +++--- EIPS/eip-1491.md | 34 ++++++++++++++++----------------- EIPS/eip-1571.md | 14 +++++++------- EIPS/eip-1613.md | 2 +- EIPS/eip-1616.md | 4 ++-- EIPS/eip-162.md | 2 +- EIPS/eip-165.md | 2 +- EIPS/eip-1681.md | 2 +- EIPS/eip-1702.md | 2 +- EIPS/eip-1775.md | 30 ++++++++++++++--------------- EIPS/eip-1895.md | 2 +- EIPS/eip-1922.md | 2 +- EIPS/eip-1930.md | 8 ++++---- EIPS/eip-1973.md | 8 ++++---- EIPS/eip-210.md | 2 +- EIPS/eip-3.md | 4 ++-- EIPS/eip-5.md | 2 +- EIPS/eip-615.md | 2 +- EIPS/eip-627.md | 4 ++-- EIPS/eip-706.md | 4 ++-- EIPS/eip-712.md | 4 ++-- EIPS/eip-725.md | 2 +- EIPS/eip-758.md | 4 ++-- EIPS/eip-823.md | 2 +- EIPS/eip-918.md | 8 ++++---- EIPS/eip-998.md | 4 ++-- README.md | 2 +- assets/eip-1057/test-vectors.md | 4 ++-- index.html | 2 +- 61 files changed, 152 insertions(+), 140 deletions(-) create mode 100644 .codespell-whitelist diff --git a/.codespell-whitelist b/.codespell-whitelist new file mode 100644 index 0000000000000..21c9c7e4ce907 --- /dev/null +++ b/.codespell-whitelist @@ -0,0 +1,7 @@ +uint +ith +mitre +readded +crate +developper +ist diff --git a/.travis-ci.sh b/.travis-ci.sh index f907ac4dbfc6a..98b6f81471edd 100755 --- a/.travis-ci.sh +++ b/.travis-ci.sh @@ -24,4 +24,6 @@ elif [[ $TASK = 'eip-validator' ]]; then FILES="$(ls EIPS/*.md | egrep "eip-[0-9]+.md")" bundle exec eip_validator $FILES +elif [[ $TASK = 'codespell' ]]; then + codespell -q4 -I .codespell-whitelist eip-X.md EIPS/ fi diff --git a/.travis.yml b/.travis.yml index a4e1fb8857cc1..70b2fd191a57f 100644 --- a/.travis.yml +++ b/.travis.yml @@ -10,7 +10,7 @@ cache: - bundler - directories: - $TRAVIS_BUILD_DIR/tmp/.htmlproofer #https://github.com/gjtorikian/html-proofer/issues/381 - + - /usr/local/lib/python3.3/dist-packages/pip/ # Assume bundler is being used, therefore # the `install` step will run `bundle install` by default. @@ -29,6 +29,9 @@ matrix: env: TASK='htmlproofer-external' - rvm: 2.2.5 env: TASK='eip-validator' + - python: 3.3 + env: TASK='codespell' + before_script: "sudo pip install urllib3[secure] && sudo pip install codespell" allow_failures: - rvm: 2.2.5 env: TASK='htmlproofer-external' diff --git a/EIPS/eip-1011.md b/EIPS/eip-1011.md index 58b9264b87827..a35c0a7b6de81 100644 --- a/EIPS/eip-1011.md +++ b/EIPS/eip-1011.md @@ -183,7 +183,7 @@ def check_and_finalize_new_checkpoint(new_block): db.last_finalized_block = finalized_hash ``` -The new chain scoring rule queries the casper contract to find the highest justified epoch that meets the client's minimum deposit requirement (`NON_REVERT_MIN_DEPOSITS`). The `10**40` multiplier ensures that the justified epoch takes precendence over block mining difficulty. `total_difficulty` only serves as a tie breaker if the two blocks in question have an equivalent `highest_justified_epoch`. +The new chain scoring rule queries the casper contract to find the highest justified epoch that meets the client's minimum deposit requirement (`NON_REVERT_MIN_DEPOSITS`). The `10**40` multiplier ensures that the justified epoch takes precedence over block mining difficulty. `total_difficulty` only serves as a tie breaker if the two blocks in question have an equivalent `highest_justified_epoch`. _Note_: If the client has no justified checkpoints, the contract returns `highest_justified_epoch` as `0` essentially reverting the fork choice rule to pure PoW. @@ -379,7 +379,7 @@ Any call to this method fails prior to the end of the `WARM_UP_PERIOD`. Thus the #### Issuance A fixed amount of 1.25M ETH was chosen as `CASPER_BALANCE` to fund the casper contract. This gives the contract enough runway to operate for approximately 2 years (assuming ~10M ETH in validator deposits). Acting similarly to the "difficulty bomb", this "funding crunch" forces the network to hardfork in the relative near future to further fund the contract. This future hardfork is an opportunity to upgrade the contract and transition to full PoS. -The PoW block reward is reduced from 3.0 to 0.6 ETH/block over the course of approximately one year because the security of the chain is greatly shifted from PoW difficulty to PoS finality and because rewards are now issued to both validators and miners. Rewards are stepped down by 0.6 ETH/block every 3 months (`REWARD_STEPDOWN_BLOCK_COUNT`) to provide for a conservative transition period from full PoW to hybrid PoS/PoW. This gives validators time to become familiar with the new technology and begin logging on and also provides the network with more leeway in case of any unforseen issues. If any major issues do arise, the Ethereum network will still have substantial PoW security to rely upon while decisions are made and/or patches are deployed. See [here](https://gist.github.com/djrtwo/bc864c0d0a275170183803814b207b9a) for further analysis of the current PoW security and of the effect of PoW block reward reduction in the context of Hybrid Casper FFG. +The PoW block reward is reduced from 3.0 to 0.6 ETH/block over the course of approximately one year because the security of the chain is greatly shifted from PoW difficulty to PoS finality and because rewards are now issued to both validators and miners. Rewards are stepped down by 0.6 ETH/block every 3 months (`REWARD_STEPDOWN_BLOCK_COUNT`) to provide for a conservative transition period from full PoW to hybrid PoS/PoW. This gives validators time to become familiar with the new technology and begin logging on and also provides the network with more leeway in case of any unforeseen issues. If any major issues do arise, the Ethereum network will still have substantial PoW security to rely upon while decisions are made and/or patches are deployed. See [here](https://gist.github.com/djrtwo/bc864c0d0a275170183803814b207b9a) for further analysis of the current PoW security and of the effect of PoW block reward reduction in the context of Hybrid Casper FFG. In addition to block rewards, miners now receive an issuance reward for including successful `vote` transactions into the block on time. This reward is equal to 1/8th that of the reward the validator receives for a successful `vote` transaction. Under optimal FFG conditions after group validator reward adjustments are made, miners receive approximately 1/5th of the total ETH issued by the Casper contract. diff --git a/EIPS/eip-1015.md b/EIPS/eip-1015.md index 4aecc15a1896e..0d690fa6ccc18 100644 --- a/EIPS/eip-1015.md +++ b/EIPS/eip-1015.md @@ -12,7 +12,7 @@ created: 2018-04-20 ## Simple Summary -This EIP changes the block reward step by instead of setting it to be hard coded on the clients and to be given to the miner/validator etherbase, it should instead go to an address decided by an on-chain contract, with hard limits on how it would be issued (six month lock-in; issuance can only decrease or be mantained, but not increase;). A decision method is suggested but not essential to the notion of this EIP. This would **not be a generic governance solution**, which is a much broader and harder topic, would **not** affect technical upgrade decisions or other hard forks, but seen as *a forum to attempt to prevent contentious hard forks* that can be solved with the issuance. +This EIP changes the block reward step by instead of setting it to be hard coded on the clients and to be given to the miner/validator etherbase, it should instead go to an address decided by an on-chain contract, with hard limits on how it would be issued (six month lock-in; issuance can only decrease or be maintained, but not increase;). A decision method is suggested but not essential to the notion of this EIP. This would **not be a generic governance solution**, which is a much broader and harder topic, would **not** affect technical upgrade decisions or other hard forks, but seen as *a forum to attempt to prevent contentious hard forks* that can be solved with the issuance. ## Summary ### Thesis: many controversial issues boil down to resources @@ -24,7 +24,7 @@ Moving to PoS has been on the roadmap since day 0 for ethereum, along with a red #### Issuance Cap at 120 Million -[EIP 960](https://github.com/ethereum/EIPs/issues/960), Vitalik's not so jokey april's fool has been taken seriously. It proposes the issuance to be slowly reduced until it reaches 120 million ether. One of the main counterpoints by Vlad can be simplified by [we don't know enough to know what that ether can be used for](https://medium.com/@Vlad_Zamfir/against-vitaliks-fixed-supply-eip-eip-960-18e182a7e5bd) and Vitalik's counterpoint is that [reducing emissions can be a way to reduce future abuse of these funds by finding a schelling point at 0](https://medium.com/@VitalikButerin/to-be-clear-im-not-necessarily-wedded-to-a-finite-supply-cap-a7aa48ab880c). Issuance has already been reduced once, from 5 ether to the current 3 ether per block. The main point of a hard cap is that a lot of people consider *not issuing* as having a positive contribution, that can outweight other actions. Burning ether is also a valid issuance decision. +[EIP 960](https://github.com/ethereum/EIPs/issues/960), Vitalik's not so jokey april's fool has been taken seriously. It proposes the issuance to be slowly reduced until it reaches 120 million ether. One of the main counterpoints by Vlad can be simplified by [we don't know enough to know what that ether can be used for](https://medium.com/@Vlad_Zamfir/against-vitaliks-fixed-supply-eip-eip-960-18e182a7e5bd) and Vitalik's counterpoint is that [reducing emissions can be a way to reduce future abuse of these funds by finding a schelling point at 0](https://medium.com/@VitalikButerin/to-be-clear-im-not-necessarily-wedded-to-a-finite-supply-cap-a7aa48ab880c). Issuance has already been reduced once, from 5 ether to the current 3 ether per block. The main point of a hard cap is that a lot of people consider *not issuing* as having a positive contribution, that can outweigh other actions. Burning ether is also a valid issuance decision. #### Asics and advantadges of PoW @@ -52,7 +52,7 @@ It's not meant to be a general governance contract. The contract **should NOT be ##### It cannot only decrease issuance, and once decreased it cannot be increased again -In order to reduce future abuse and uncertainity, **once issuance is reduced, it cannot be increased**. To prevent a single action reducing it to 0, the reduction is limited up to a percentage per time, so if the **decision assembly** is agressively to reduce issuance to zero, it would take a known number of years. +In order to reduce future abuse and uncertainty, **once issuance is reduced, it cannot be increased**. To prevent a single action reducing it to 0, the reduction is limited up to a percentage per time, so if the **decision assembly** is aggressively to reduce issuance to zero, it would take a known number of years. ##### Results are locked for six months @@ -109,7 +109,7 @@ A lot of things are suggested in this EIP, so I would like to propose these ques 1. Do we want to have dynamically changing block rewards, instead of having them be hard coded in the protocol? 2. If the answer above is yes, then what would be the best governance process to decide it, and what sorts of limits would we want that governance contract to have? -3. If the answer is a multi-signalling contract, then what sorts of signals would we want, what sort of relative weight should they have and what would be the proccess to add and remove them? +3. If the answer is a multi-signalling contract, then what sorts of signals would we want, what sort of relative weight should they have and what would be the process to add and remove them? diff --git a/EIPS/eip-1057.md b/EIPS/eip-1057.md index b3b897b9e7d91..5ffc0b9f7d313 100644 --- a/EIPS/eip-1057.md +++ b/EIPS/eip-1057.md @@ -15,7 +15,7 @@ A new Proof-of-Work algorithm to replace Ethash that utilizes almost all parts o ## Abstract -ProgPoW is a proof-of-work algorithm designed to close the efficency gap available to specialized ASICs. It utilizes almost all parts of commodity hardware (GPUs), and comes pre-tuned for the most common hardware utilized in the Ethereum network. +ProgPoW is a proof-of-work algorithm designed to close the efficiency gap available to specialized ASICs. It utilizes almost all parts of commodity hardware (GPUs), and comes pre-tuned for the most common hardware utilized in the Ethereum network. ## Motivation @@ -53,7 +53,7 @@ With the growth of large mining pools, the control of hashing power has been del While the goal of “ASIC resistance” is valuable, the entire concept of “ASIC resistance” is a bit of a fallacy. CPUs and GPUs are themselves ASICs. Any algorithm that can run on a commodity ASIC (a CPU or GPU) by definition can have a customized ASIC created for it with slightly less functionality. Some algorithms are intentionally made to be “ASIC friendly” - where an ASIC implementation is drastically more efficient than the same algorithm running on general purpose hardware. The protection that this offers when the coin is unknown also makes it an attractive target for a dedicate mining ASIC company as soon as it becomes useful. -Therefore, ASIC resistance is: the efficiency difference of specilized hardware versus hardware that has a wider adoption and applicability. A smaller efficiency difference between custom vs general hardware mean higher resistance and a better algorithm. This efficiency difference is the proper metric to use when comparing the quality of PoW algorithms. Efficiency could mean absolute performance, performance per watt, or performance per dollar - they are all highly correlated. If a single entity creates and controls an ASIC that is drastically more efficient, they can gain 51% of the network hashrate and possibly stage an attack. +Therefore, ASIC resistance is: the efficiency difference of specialized hardware versus hardware that has a wider adoption and applicability. A smaller efficiency difference between custom vs general hardware mean higher resistance and a better algorithm. This efficiency difference is the proper metric to use when comparing the quality of PoW algorithms. Efficiency could mean absolute performance, performance per watt, or performance per dollar - they are all highly correlated. If a single entity creates and controls an ASIC that is drastically more efficient, they can gain 51% of the network hashrate and possibly stage an attack. ### Review of Existing PoW Algorithms @@ -134,7 +134,7 @@ The random program changes every `PROGPOW_PERIOD` blocks to ensure the hardware Sample code is written in C++, this should be kept in mind when evaluating the code in the specification. -All numerics are computed using unsinged 32 bit integers. Any overflows are trimmed off before proceeding to the next computation. Languages that use numerics not fixed to bit lenghts (such as Python and JavaScript) or that only use signed integers (such as Java) will need to keep their languages' quirks in mind. The extensive use of 32 bit data values aligns with modern GPUs internal data architectures. +All numerics are computed using unsigned 32 bit integers. Any overflows are trimmed off before proceeding to the next computation. Languages that use numerics not fixed to bit lengths (such as Python and JavaScript) or that only use signed integers (such as Java) will need to keep their languages' quirks in mind. The extensive use of 32 bit data values aligns with modern GPUs internal data architectures. ProgPoW uses a 32-bit variant of **FNV1a** for merging data. The existing Ethash uses a similar vaiant of FNV1 for merging, but FNV1a provides better distribution properties. diff --git a/EIPS/eip-1066.md b/EIPS/eip-1066.md index bfb15d1d2ac90..c8755a5b52d75 100644 --- a/EIPS/eip-1066.md +++ b/EIPS/eip-1066.md @@ -104,10 +104,10 @@ General codes. These double as bare "reasons", since `0x01 == 1`. | `0x02` | Awaiting Others | | `0x03` | Accepted | | `0x04` | Lower Limit or Insufficient | -| `0x05` | Reciever Action Requested | +| `0x05` | Receiver Action Requested | | `0x06` | Upper Limit | | `0x07` | [reserved] | -| `0x08` | Duplicate, Unnessesary, or Inapplicable | +| `0x08` | Duplicate, Unnecessary, or Inapplicable | | `0x09` | [reserved] | | `0x0A` | [reserved] | | `0x0B` | [reserved] | @@ -130,7 +130,7 @@ Also used for common state machine actions (ex. "stoplight" actions). | `0x15` | Needs Your Permission or Request for Continuation | | `0x16` | Revoked or Banned | | `0x17` | [reserved] | -| `0x18` | Not Applicatable to Current State | +| `0x18` | Not Applicable to Current State | | `0x19` | [reserved] | | `0x1A` | [reserved] | | `0x1B` | [reserved] | @@ -286,7 +286,7 @@ Currently unspecified. (Full range reserved) Actions around signatures, cryptography, signing, and application-level authentication. -The meta code `0xEF` is often used to signal a payload descibing the algorithm or process used. +The meta code `0xEF` is often used to signal a payload describing the algorithm or process used. | Code | Description | |--------|-------------------------------------| @@ -344,7 +344,7 @@ Among other things, the meta code `0xFF` may be used to describe what the off-ch | `0x*5` | `0x05` Receiver Action Required | `0x15` Needs Your Permission or Request for Continuation | `0x25` Request for Match | `0x35` Receiver's Ratification Requested | `0x45` Awaiting Your Availability | `0x55` Funds Requested | `0x65` [reserved] | `0x75` [reserved] | `0x85` [reserved] | `0x95` [reserved] | `0xA5` App-Specific Receiver Action Requested | `0xB5` [reserved] | `0xC5` [reserved] | `0xD5` [reserved] | `0xE5` Signature Required | `0xF5` Off-Chain Action Required | | `0x*6` | `0x06` Upper Limit | `0x16` Revoked or Banned | `0x26` Above Range or Overflow | `0x36` Offer or Vote Limit Reached | `0x46` Expired | `0x56` Transfer Volume Exceeded | `0x66` [reserved] | `0x76` [reserved] | `0x86` [reserved] | `0x96` [reserved] | `0xA6` App-Specific Expiry or Limit | `0xB6` [reserved] | `0xC6` [reserved] | `0xD6` [reserved] | `0xE6` Known to be Compromised | `0xF6` Off-Chain Expiry or Limit Reached | | `0x*7` | `0x07` [reserved] | `0x17` [reserved] | `0x27` [reserved] | `0x37` [reserved] | `0x47` [reserved] | `0x57` [reserved] | `0x67` [reserved] | `0x77` [reserved] | `0x87` [reserved] | `0x97` [reserved] | `0xA7` [reserved] | `0xB7` [reserved] | `0xC7` [reserved] | `0xD7` [reserved] | `0xE7` [reserved] | `0xF7` [reserved] | -| `0x*8` | `0x08` Duplicate, Unnessesary, or Inapplicable | `0x18` Not Applicatable to Current State | `0x28` Duplicate, Conflict, or Collision | `0x38` Already Voted | `0x48` Already Done | `0x58` Funds Not Required | `0x68` [reserved] | `0x78` [reserved] | `0x88` [reserved] | `0x98` [reserved] | `0xA8` App-Specific Inapplicable Condition | `0xB8` [reserved] | `0xC8` [reserved] | `0xD8` [reserved] | `0xE8` Already Signed or Not Encrypted | `0xF8` Duplicate Off-Chain Request | +| `0x*8` | `0x08` Duplicate, Unnecessary, or Inapplicable | `0x18` Not Applicable to Current State | `0x28` Duplicate, Conflict, or Collision | `0x38` Already Voted | `0x48` Already Done | `0x58` Funds Not Required | `0x68` [reserved] | `0x78` [reserved] | `0x88` [reserved] | `0x98` [reserved] | `0xA8` App-Specific Inapplicable Condition | `0xB8` [reserved] | `0xC8` [reserved] | `0xD8` [reserved] | `0xE8` Already Signed or Not Encrypted | `0xF8` Duplicate Off-Chain Request | | `0x*9` | `0x09` [reserved] | `0x19` [reserved] | `0x29` [reserved] | `0x39` [reserved] | `0x49` [reserved] | `0x59` [reserved] | `0x69` [reserved] | `0x79` [reserved] | `0x89` [reserved] | `0x99` [reserved] | `0xA9` [reserved] | `0xB9` [reserved] | `0xC9` [reserved] | `0xD9` [reserved] | `0xE9` [reserved] | `0xF9` [reserved] | | `0x*A` | `0x0A` [reserved] | `0x1A` [reserved] | `0x2A` [reserved] | `0x3A` [reserved] | `0x4A` [reserved] | `0x5A` [reserved] | `0x6A` [reserved] | `0x7A` [reserved] | `0x8A` [reserved] | `0x9A` [reserved] | `0xAA` [reserved] | `0xBA` [reserved] | `0xCA` [reserved] | `0xDA` [reserved] | `0xEA` [reserved] | `0xFA` [reserved] | | `0x*B` | `0x0B` [reserved] | `0x1B` [reserved] | `0x2B` [reserved] | `0x3B` [reserved] | `0x4B` [reserved] | `0x5B` [reserved] | `0x6B` [reserved] | `0x7B` [reserved] | `0x8B` [reserved] | `0x9B` [reserved] | `0xAB` [reserved] | `0xBB` [reserved] | `0xCB` [reserved] | `0xDB` [reserved] | `0xEB` [reserved] | `0xFB` [reserved] | @@ -491,7 +491,7 @@ Alternate schemes include `bytes32` and `uint8`. While these work reasonably wel `uint8` feels even more similar to HTTP status codes, and enums don't require as much casting. However does not break as evenly as a square table (256 doesn't look as nice in base 10). -Packing multiple codes into a single `bytes32` is nice in theory, but poses additional challenges. Unused space may be interpeted as `0x00 Failure`, you can only efficiently pack four codes at once, and there is a challenge in ensuring that code combinations are sensible. Forcing four codes into a packed representation encourages multiple status codes to be returned, which is often more information than strictly necessarily. This can lead to paradoxical results (ex `0x00` and `0x01` together), or greater resorces allocated to interpreting 2564 (4.3 billion) permutations. +Packing multiple codes into a single `bytes32` is nice in theory, but poses additional challenges. Unused space may be interpreted as `0x00 Failure`, you can only efficiently pack four codes at once, and there is a challenge in ensuring that code combinations are sensible. Forcing four codes into a packed representation encourages multiple status codes to be returned, which is often more information than strictly necessarily. This can lead to paradoxical results (ex `0x00` and `0x01` together), or greater resources allocated to interpreting 2564 (4.3 billion) permutations. ### Multiple Returns diff --git a/EIPS/eip-107.md b/EIPS/eip-107.md index 48b13a0390b60..897feb804b6f9 100644 --- a/EIPS/eip-107.md +++ b/EIPS/eip-107.md @@ -16,7 +16,7 @@ Every read only rpc call the dapp wants to perform is redirected to an invisible Motivation ========== -Currently, if a user navigates to a dapp running on a website using her/his everyday browser, the dapp will by default have no access to the rpc api for security reasons. The user will have to enable CORS for the website's domain in order for the dapp to work. Unfortunately if the user does so, the dapp will be able to send transactions from any unlocked account without the need for any user consent. In other words, not only does the user need to change the node's default setting, but the user is also forced to trust the dapp in order to use it. This is of course not acceptable and forces existing dapps to rely on the use of workarrounds like: +Currently, if a user navigates to a dapp running on a website using her/his everyday browser, the dapp will by default have no access to the rpc api for security reasons. The user will have to enable CORS for the website's domain in order for the dapp to work. Unfortunately if the user does so, the dapp will be able to send transactions from any unlocked account without the need for any user consent. In other words, not only does the user need to change the node's default setting, but the user is also forced to trust the dapp in order to use it. This is of course not acceptable and forces existing dapps to rely on the use of workarounds like: - if the transaction is a plain ether transfer, the user is asked to enter it in a dedicated trusted wallet like "Mist" - For more complex case, the user is asked to enter the transaction manually via the node command line interface. @@ -50,12 +50,12 @@ In order for the mechanism to work, the node needs to serve an html file via htt This file will then be used by the dapp in 2 different modes (invisible iframe and popup window). -The invisible iframe will be embeded in the dapp to allow the dapp to send its read-only rpc call without having to enable CORS for the dapp's website domain. This is done by sending message to the iframe (via javascript ```window.postMessage```) which in turn execute the rpc call. This works since the iframe and the node share the same domain/port. +The invisible iframe will be embedded in the dapp to allow the dapp to send its read-only rpc call without having to enable CORS for the dapp's website domain. This is done by sending message to the iframe (via javascript ```window.postMessage```) which in turn execute the rpc call. This works since the iframe and the node share the same domain/port. In the iframe mode, the html file's javascript code will ensure that no call requiring an unlocked key can be made. This is to prevent dapps from embedding the invisible iframe and tricking the user into clicking the confirm button. If the dapp requires an ```eth_sendTransaction``` call, the dapp will instead open a new window using the same url. -In this popup window mode, the html file's javascript code will alow ```eth_sendTransaction``` (but not ```eth_sign```, as there is no way to display to the user the meaningful content of the transaction to sign in a safe way) to be called. But instead of sending the call to the node directly, a confirmation dialog will be presented showing the sender and recipient addresses, as well as the amount being transfered along with the potential gas cost. Upon the user approving, the request will be sent and the result returned to the dapp. An error will be returned in case the user cancel the request. +In this popup window mode, the html file's javascript code will allow ```eth_sendTransaction``` (but not ```eth_sign```, as there is no way to display to the user the meaningful content of the transaction to sign in a safe way) to be called. But instead of sending the call to the node directly, a confirmation dialog will be presented showing the sender and recipient addresses, as well as the amount being transferred along with the potential gas cost. Upon the user approving, the request will be sent and the result returned to the dapp. An error will be returned in case the user cancel the request. The html page also checks for the availability of the "personal" api and if so, will ask the user to unlock the account if necessary. The unlocking is temporary (3s) so the password will be asked again if a transaction is attempted before the end of this short time. @@ -75,7 +75,7 @@ Upon receiving such message, the iframe will perform the actual rpc call to the In all the cases, the iframe/window will send a message back to the dapp using the following object: ``` { - id:, + id:, result:, error: } diff --git a/EIPS/eip-1077.md b/EIPS/eip-1077.md index 81ff8f8b43275..4e7e08fdd36c2 100644 --- a/EIPS/eip-1077.md +++ b/EIPS/eip-1077.md @@ -84,7 +84,7 @@ Regardless of which fields you use, in your contract you **must** accept an extr #### Multiple signatures -If multiple signatures are required, then all signed messageHashes should then be *ordered by account* and sent to the receiveing contract which then will execute the following actions: +If multiple signatures are required, then all signed messageHashes should then be *ordered by account* and sent to the receiving contract which then will execute the following actions: #### keep track of nonces: @@ -166,7 +166,7 @@ A function which returns the amount of signatures that are required for a given `event ExecutedSigned(bytes32 signHash, uint nonce, bool success);` -Whenever a new transaction is executed it **must** emit an event with the signHash, nonce and either the transaction was sucessfully executed or not. Apps that are waiting for a transaction to be executed should subscribe to the identity and watch this event to see if their transaction was sucessful. If a different signHash is executed with an equal or higher nonce, it means that your transaction has been replaced. +Whenever a new transaction is executed it **must** emit an event with the signHash, nonce and either the transaction was successfully executed or not. Apps that are waiting for a transaction to be executed should subscribe to the identity and watch this event to see if their transaction was successful. If a different signHash is executed with an equal or higher nonce, it means that your transaction has been replaced. ## Implementation One initial implementation of such a contract can be found at [the Identity Gas Relay at the Status repository](https://github.com/status-im/contracts/blob/73-economic-abstraction/contracts/identity/IdentityGasRelay.sol) diff --git a/EIPS/eip-1078.md b/EIPS/eip-1078.md index f004566667cc6..990d446f833ce 100644 --- a/EIPS/eip-1078.md +++ b/EIPS/eip-1078.md @@ -71,7 +71,7 @@ Here's an example of a EIP681 compatible address to add a public key generated l `ethereum:bob.example.eth?function=addKey(address='0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef',uint=1)` -If adding the new key requires multiple signatures, or if the app receiving that request exclusiveky deals with executeable signed messages and has no ether on itself, then it should follow the steps in the next section on how to request transactions. +If adding the new key requires multiple signatures, or if the app receiving that request exclusiveky deals with executable signed messages and has no ether on itself, then it should follow the steps in the next section on how to request transactions. As before, the user shouldn’t be forced to wait for transaction confirmation times. Instead, have an indicator somewhere on the app the shows the progress and then allow the user to interact with your app normally. diff --git a/EIPS/eip-1080.md b/EIPS/eip-1080.md index e5f7a46717772..18277e8fcba4a 100644 --- a/EIPS/eip-1080.md +++ b/EIPS/eip-1080.md @@ -172,7 +172,7 @@ event AccountFrozen(address indexed reported) ## Rationale -* A recoverable token standard can provide configurable saftey for users or contracts who desire this saftey. +* A recoverable token standard can provide configurable safety for users or contracts who desire this safety. * Implementations of this standard will give users the ability to select a dispute resolution process on an opt-in basis and benefit the community by decreasing the necessity of consideration of token recovery actions. diff --git a/EIPS/eip-1081.md b/EIPS/eip-1081.md index d5a7556c86db4..835ecac7edefd 100644 --- a/EIPS/eip-1081.md +++ b/EIPS/eip-1081.md @@ -42,7 +42,7 @@ Optional Functions: - `acceptAndFulfill(address[] _fulfillers, uint[] _numerators, uint _denomenator, string _data, StandardToken[] _payoutTokens, uint[] _tokenAmounts)`: During the course of the development of this standard, we discovered the desire for fulfillers to avoid paying gas fees on their own, entrusting the bounty's `issuer` to make the submission for them, and at the same time accept it. This is useful since it still immutably stores the exchange of tokens for completed work, but avoids the need for new bounty fulfillers to have any ETH to pay for gas costs in advance of their earnings. - `changeMasterCopy(StandardBounty _masterCopy)`: For `issuer`s to be able to change the masterCopy which their proxy contract relies on, if the proxy design pattern is being employed. - `refundableContribute(uint[] _amounts, StandardToken[] _tokens)`: While non-refundable contributions may be sent to a bounty simply by transferring those tokens to the address where it resides, one may also desire to contribute to a bounty with the option to refund their contribution, should the bounty never receive a correct submission which is paid out. -`refundContribution(uint _contributionId)`: If a bounty hasn't yet paid out to any correct submissions and is past it's deadline, those individuals who employed the `refundableContribute` function may retreive their funds from the contract. +`refundContribution(uint _contributionId)`: If a bounty hasn't yet paid out to any correct submissions and is past it's deadline, those individuals who employed the `refundableContribute` function may retrieve their funds from the contract. **Schemas** Persona Schema: diff --git a/EIPS/eip-1108.md b/EIPS/eip-1108.md index b77e50df270ab..792cc9085c016 100644 --- a/EIPS/eip-1108.md +++ b/EIPS/eip-1108.md @@ -75,7 +75,7 @@ Fast elliptic curve cryptography is a keystone of a growing number of protocols * [The AZTEC protocol](https://github.com/AztecProtocol/AZTEC) utilizes the elliptic curve precompiles to construct private tokens, with zero-knowledge transaction logic, via the [ERC1723](https://github.com/ethereum/EIPs/issues/1723) and [ERC1724](https://github.com/ethereum/EIPs/issues/1724) standard. * [Matter Labs](https://github.com/matter-labs/matter-network) utilizes the precompiles to implement Ignis, a scaling solution with a throughput of 500txns per second -* [Rollup](https://github.com/rollup/rollup) utilizes the precompiles to create L2 scaling solutions, where the correctness of transactions is gauranteed by main-net, without an additional consensus layer +* [Rollup](https://github.com/rollup/rollup) utilizes the precompiles to create L2 scaling solutions, where the correctness of transactions is guaranteed by main-net, without an additional consensus layer * [ZEther](https://crypto.stanford.edu/~buenz/papers/zether.pdf) uses precompiles `ECADD` and `ECMUL` to construct confidential transactions These are all technologies that have been, or are in the process of being, deployed to main-net. There protocols would all benefit from reducing the gas cost of the precompiles. diff --git a/EIPS/eip-1109.md b/EIPS/eip-1109.md index 1d80f9101dc9b..647796a77479f 100644 --- a/EIPS/eip-1109.md +++ b/EIPS/eip-1109.md @@ -37,7 +37,7 @@ The input stack values are: mu_s[0] = The address of the precompiled smart contract that is called. mu_s[1] = Pointer to memory for the input parameters. -mu_s[2] = Length of the input parametes in bytes. +mu_s[2] = Length of the input parameters in bytes. mu_s[3] = Pointer to memory where the output is stored mu_s[4] = Length of the output buffer. @@ -75,7 +75,7 @@ Old contracts that call precompiled smart contracts with the CALL method, will c - Call to a regular contract - Call to a regular account - Call to 0x0 smart contract (Does not exists). -- Call with large values for the offste pointers and lenghts +- Call with large values for the offste pointers and lengths - Call with the exact gas remaining needed to call smart contract. - Call with the exact gas remaining minus one needed to call smart contract. diff --git a/EIPS/eip-1123.md b/EIPS/eip-1123.md index 11605fcfebe02..aa0cf3170c52a 100644 --- a/EIPS/eip-1123.md +++ b/EIPS/eip-1123.md @@ -89,7 +89,7 @@ Guiding Principles This specification makes the following assumptions about the document lifecycle. -1. Package manifests are intended to be generated programatically by +1. Package manifests are intended to be generated programmatically by package management software as part of the release process. 2. Package manifests will be consumed by package managers during tasks diff --git a/EIPS/eip-1154.md b/EIPS/eip-1154.md index a9fedf4d2e206..4e8dc483fdd13 100644 --- a/EIPS/eip-1154.md +++ b/EIPS/eip-1154.md @@ -100,7 +100,7 @@ Transaction-wise, both systems are roughly equivalent in efficiency in this scen #### Result Immutability In both the proposed specification and the alternate specification, results are immutable once they are determined. This is due to the expectation that typical consumers will require results to be immutable in order to determine a resulting state consistently. With the proposed push-based system, the consumer enforces the result immutability requirement, whereas in the alternate pull-based system, either the oracle would have to be trusted to implement the spec correctly and enforce the immutability requirement, or the consumer would also have to handle result immutability. -For data which mutates over time, the `id` field may be structured to specify "what" and "when" for the data (using 128 bits to specify "when" is still safe for many millenia). +For data which mutates over time, the `id` field may be structured to specify "what" and "when" for the data (using 128 bits to specify "when" is still safe for many millennia). ## Implementation diff --git a/EIPS/eip-1155.md b/EIPS/eip-1155.md index f7c1de4813aac..bfd1539c98bc6 100644 --- a/EIPS/eip-1155.md +++ b/EIPS/eip-1155.md @@ -67,7 +67,7 @@ interface ERC1155 /* is ERC165 */ { event TransferBatch(address indexed _operator, address indexed _from, address indexed _to, uint256[] _ids, uint256[] _values); /** - @dev MUST emit when approval for a second party/operator address to manage all tokens for an owner address is enabled or disabled (absense of an event assumes disabled). + @dev MUST emit when approval for a second party/operator address to manage all tokens for an owner address is enabled or disabled (absence of an event assumes disabled). */ event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved); diff --git a/EIPS/eip-1167.md b/EIPS/eip-1167.md index 4b35d0462aee2..30154b6ad146d 100644 --- a/EIPS/eip-1167.md +++ b/EIPS/eip-1167.md @@ -22,7 +22,7 @@ By standardizing on a known minimal bytecode redirect implementation, this stand ## Motivation -This standard supports use-cases wherein it is desireable to clone exact contract functionality with a minimum of side effects (e.g. memory slot stomping) and with low gas cost deployment of duplicate proxies. +This standard supports use-cases wherein it is desirable to clone exact contract functionality with a minimum of side effects (e.g. memory slot stomping) and with low gas cost deployment of duplicate proxies. ## Specification diff --git a/EIPS/eip-1186.md b/EIPS/eip-1186.md index 3398e5b5819bf..84f7442d01622 100644 --- a/EIPS/eip-1186.md +++ b/EIPS/eip-1186.md @@ -124,7 +124,7 @@ This one Method actually returns 3 different important data points: Combining these in one Method allows the client to work very efficient since the required data are already fetched from the db. -### Proofs for non existant values +### Proofs for non existent values In case an address or storage-value does not exist, the proof needs to provide enough data to verify this fact. This means the client needs to follow the path from the root node and deliver until the last matching node. If the last matching node is a branch, the proof value in the node must be an empty one. In case of leaf-type, it must be pointing to a different relative-path in order to proof that the requested path does not exist. diff --git a/EIPS/eip-1193.md b/EIPS/eip-1193.md index 26fd23fbf3b5f..7398f75db8804 100644 --- a/EIPS/eip-1193.md +++ b/EIPS/eip-1193.md @@ -47,7 +47,7 @@ All subscriptions from the node emit on "subscription type" (e.g. `eth_subscript ethereum.on('eth_subscription', listener: (result: any) => void): this; ``` -To create a subscription, call `ethereum.send('eth_subscribe')` or `ethereum.send('shh_subscribe')`. The subscription object will emit through the specifc subscription type. +To create a subscription, call `ethereum.send('eth_subscribe')` or `ethereum.send('shh_subscribe')`. The subscription object will emit through the specific subscription type. The result object will look as follows: diff --git a/EIPS/eip-1202.md b/EIPS/eip-1202.md index a114f2e2c09b5..a6de062f8f4a7 100644 --- a/EIPS/eip-1202.md +++ b/EIPS/eip-1202.md @@ -23,7 +23,7 @@ following category: - [Telegram Channel t.me/erc1202](https://t.me/erc1202) for real-time and related random chat. 3. We are actively working on updating this draft as many feedbacks have come in since it merged into official EIP repo. -If you are viewing a snapshot of this draft, please be adviced the latest dev version of ERC 1202 can be found [here](https://github.com/xinbenlv/eip-1202-draft/blob/master/EIP-1202.md) +If you are viewing a snapshot of this draft, please be advised the latest dev version of ERC 1202 can be found [here](https://github.com/xinbenlv/eip-1202-draft/blob/master/EIP-1202.md) ## Simple Summary Propose a standard interface for voting. diff --git a/EIPS/eip-1261.md b/EIPS/eip-1261.md index 5645d025a99fd..75dd50da28c7f 100644 --- a/EIPS/eip-1261.md +++ b/EIPS/eip-1261.md @@ -106,9 +106,9 @@ interface IERC1261 {/* is ERC173, ERC165 */ /// @notice Requests membership from any address. /// @dev Throws if the `msg.sender` already has the token. - /// The individual `msg.sender` can request for a membership if some exisiting criteria are satisfied. + /// The individual `msg.sender` can request for a membership if some existing criteria are satisfied. /// When a membership is requested, this function emits the RequestedMembership event. - /// dev can store the membership request and use `approveRequest` to assign memebership later + /// dev can store the membership request and use `approveRequest` to assign membership later /// dev can also oraclize the request to assign membership later /// @param _attributeIndexes the attribute data associated with the member. /// This is an array which contains indexes of attributes. diff --git a/EIPS/eip-1271.md b/EIPS/eip-1271.md index 94b8551e61b93..a76c905d60896 100644 --- a/EIPS/eip-1271.md +++ b/EIPS/eip-1271.md @@ -61,7 +61,7 @@ contract ERC1271 { } ``` -`isValidSignature` can call arbitrary methods to validate a given signature, which could be context dependent (e.g. time based or state based), EOA dependant (e.g. signers authorization level within smart wallet), signature scheme Dependant (e.g. ECDSA, multisig, BLS), etc. +`isValidSignature` can call arbitrary methods to validate a given signature, which could be context dependent (e.g. time based or state based), EOA dependent (e.g. signers authorization level within smart wallet), signature scheme Dependent (e.g. ECDSA, multisig, BLS), etc. diff --git a/EIPS/eip-1283.md b/EIPS/eip-1283.md index 7361bdd89eaf8..38df50bc111a0 100644 --- a/EIPS/eip-1283.md +++ b/EIPS/eip-1283.md @@ -286,7 +286,7 @@ When *original value* is not 0, we want to prove that: charge `200 * N` gases, because no disk write is needed. * **Case II**: If the *final value* ends up being zero, we want to charge `5000 - 15000 + 200 * (N-1)` gas. Note that `15000` is the - refund in actual defintion. + refund in actual definition. * **Case III**: If the *final value* ends up being a changed non-zero value, we want to charge `5000 + 200 * (N-1)` gas. diff --git a/EIPS/eip-1380.md b/EIPS/eip-1380.md index 87a29aadeda43..f8476e1f4673b 100644 --- a/EIPS/eip-1380.md +++ b/EIPS/eip-1380.md @@ -25,7 +25,7 @@ Using `JUMP` comes at a considerable cost in complexity to the implementation of must be swapped in and out of the calling functions context. A desired feature is having *pure* functions, which do not modify the state of memory, and realising them through `JUMP` requires a bigger effort from the compiler as opposed to being able to use `CALL`s. -Using call-to-self provides the guarentee that when making an internal call the function can rely on a clear reset state of memory or context, benefiting both +Using call-to-self provides the guarantee that when making an internal call the function can rely on a clear reset state of memory or context, benefiting both contract writers and contract consumers against potentially undetetected edge cases were memory could poison the context of the internal function. Because of the `JUMP` usage for internal functions a smart contract languages are also at risk of reaching the stack depth limit considerbly faster, if nested diff --git a/EIPS/eip-1388.md b/EIPS/eip-1388.md index 84c2f296702b8..6bf1ca4ec8bee 100644 --- a/EIPS/eip-1388.md +++ b/EIPS/eip-1388.md @@ -23,7 +23,7 @@ This ERC provides a smart contract interface for anyone to manage a list of atte ### Draft implementation ``` /* The purpose of this contract is to manage the list of attestation - * issuer contracts and their capacity to fulfil requirements + * issuer contracts and their capacity to fulfill requirements */ contract ManagedListERC { diff --git a/EIPS/eip-1417.md b/EIPS/eip-1417.md index 81f11a79e6cd3..f30735effc242 100644 --- a/EIPS/eip-1417.md +++ b/EIPS/eip-1417.md @@ -26,7 +26,7 @@ The following standard allows for the implementation of a standard API for polls We considered the usage of polls with MVTs because MVTs serve as a permissioning mechanism. The manual permissioning of polls allows for vote weightage functions to take up several shapes and forms. Hence the voterbase function applies several logical checks on the vote sender to confirm that they are member(see EIP 1261) of a certain entity or combination of entities. For the specification of the nature of voting, we define the vote weight function. The vote weight function decides how much of vote share each voter will receive and this can be based on several criteria, some of which are listed below in this article. There are certain kinds of polls that enforce certain consequences on the voter, for example a poll may require a voter to lock in a certain amount of tokens, or require the voter to pay a small fee. These on-chain consequences can be coded into the consequence module of the poll standard. Finally, the last module is where the votes are added. A ballot for each candidate is updated whenever relevant, depending on the vote value, and the corresponding NoV count(number of voters). This module is common for most polls, and is the most straightforward. Polls may be time bound, ie. having a finish time, after which no votes are recorded, or be unbound, such that there is no finish time. The following are some examples of specific polls which leverage the flexibility of the poll standard, and it is possible to come up with several others: - Plurality Voting: The simplest form of voting is when you want all eligible voters to have one vote per person. This is the simplest to code, as the vote weight is 1, and there is no vote consequence. The only relevant module here is the voterbase, which can be categorized by one or more MVT contracts. -- Token proportional voting: This kind of a poll is actually possible without the use of a voterbase function, because the vote weight function having token proportionality automatically rules out addresses which dont hold the appropriate ERC - 20/ ERC - 777 token. However the voterbase function may be leveraged to further permission the system and give voting rights only to a fixed subset of token holders. +- Token proportional voting: This kind of a poll is actually possible without the use of a voterbase function, because the vote weight function having token proportionality automatically rules out addresses which don't hold the appropriate ERC - 20/ ERC - 777 token. However the voterbase function may be leveraged to further permission the system and give voting rights only to a fixed subset of token holders. - Capped Token Proportional Voting: This is a modified version of the previous example, where each voter is given proportional vote share only until a certain limit of token ownership. After exceeding that limit, holding more coins does not add more vote share. This format leverages the voterbase module effectively, disallowing people from spreading their coins across multiple addresses by allowing the admin to control which addresses can vote. - Delegated Voting: Certain polls may allow voters to delegate their votes to other voters. This is known as delegated voting or liquid democracy. For such a poll, a complicated vote weight function is needed, and a data structure concerning the voterbase is also required. A consequence of voting here would be that a user cannot delegate, and a consequence of delegating is that a user cannot vote. Sample implementation of polls contains an example of this vote scheme. - Karma Based Voting: A certain form of poll may be based on weightage from digital respect. This digital respect would be like a simple upvote from one member of voterbase to another. A mapping of mappings along with an appropriate vote weight function can serve this purpose. Sample implementation has an example. @@ -46,7 +46,7 @@ This realization happened while conducting market research on DAICOs. The first 2. Permissioning: Permissioning is an important aspect of polls, and is missing in most poll proposals so far, on the blockchain. For some reason, most blockchain based polls seem to consider token holding as the only way to permission a poll. However this hampers flexibility, and hence our poll standard is leveraging EIP 1261 in order to clear the permissioning hurdle. Not only does it allow for more creative poll structures in terms of vote weightage, but even improves the flexibility in permissioning by allowing developers to combine several entities and read attributes from entities. -3. Flexibilty: The vote weight module of the poll standard can be used effectively to design various kinds of poll contracts which function differently and are suited to different environments. Some examples are quadratic voting, karma voting, delegated voting, token based voting, and one person one vote systems. These schemes are possible due to the separation of voterbase creation and vote weight calculation. +3. Flexibility: The vote weight module of the poll standard can be used effectively to design various kinds of poll contracts which function differently and are suited to different environments. Some examples are quadratic voting, karma voting, delegated voting, token based voting, and one person one vote systems. These schemes are possible due to the separation of voterbase creation and vote weight calculation. 4. NoV Counts: Several weighted polls have struggled to provide proper transparency because they only show the final result without enough granularity. This is because they do not store the number of voters that have voted for each proposal, and only store the total accrued vote for each option. EIP 1417 solves this by additionally recording number of voters(NoV) in each proposal. This NoV count is redundant in the case of one person one vote, but elsewhere, it is helpful in figuring out concentration of power. This ensures that malicious parties can be traced to a larger extent. @@ -59,13 +59,13 @@ All that being said, we are very excited to share our proposal with the communit ### Benefits 1. Building applications (pollscan.io) on top of a standardized voting interface enables transparency and encourage more DAO/DAICO's to act responsibly in terms of governance -2. Create Action contracts which take actions programatically based on the result of a poll +2. Create Action contracts which take actions programmatically based on the result of a poll 3. Allow the compatibility with token standard such as [ERC-20](https://eips.ethereum.org/EIPS/eip-20) or (https://eips.ethereum.org/EIPS/eip-777)) and membership standard such as [EIP-1261](https://eips.ethereum.org/EIPS/eip-1261) 4. Flexibility allows for various voting schemes including but not limited to modern schemes such as PLCR Voting ### Use-cases: -Polls are useful in any context of collective decision making, which include but arent limited to: +Polls are useful in any context of collective decision making, which include but aren't limited to: 1. Governing public resources, like ponds, playgrounds, streets etc 2. Maintaining fiscal policy in a transparent consensus driven manner @@ -177,7 +177,7 @@ interface IPoll { /// @return end time as Unix Standard Time function getEndTime() external view returns (uint); - /// @notice retuns the list of entity addresses (eip-1261) used for perimissioning purposes. + /// @notice returns the list of entity addresses (eip-1261) used for perimissioning purposes. /// @dev addresses list can be used along with IERC1261 interface to define the logic inside `canVote()` function /// @return the list of addresses of entities function getProtocolAddresses() external view returns (address[]); @@ -231,7 +231,7 @@ Having explained our rationale, we are looking forward to hearing from the commu **Gas and Complexity** (regarding the enumeration for proposal count) -This specification contemplates implementations that contain a sample of 32 proposals (max upto blockgaslimit). If your application is able to grow and needs more than 32 proposals, then avoid using for/while loops in your code. These indicate your contract may be unable to scale and gas costs will rise over time without bound +This specification contemplates implementations that contain a sample of 32 proposals (max up to blockgaslimit). If your application is able to grow and needs more than 32 proposals, then avoid using for/while loops in your code. These indicate your contract may be unable to scale and gas costs will rise over time without bound **Privacy** diff --git a/EIPS/eip-145.md b/EIPS/eip-145.md index e3cc659122ac5..d0b38cf76c7cd 100644 --- a/EIPS/eip-145.md +++ b/EIPS/eip-145.md @@ -18,7 +18,7 @@ Native bitwise shifting instructions are introduced, which are more efficient pr ## Motivation -EVM is lacking bitwise shifting operators, but supports other logical and arithmetic operators. Shift operations can be implemented via arithmetic operators, but that has a higher cost and requires more processing time from the host. Implementing `SHL` and `SHR` using arithmetics cost each 35 gas, while the proposed instructions take 3 gas. +EVM is lacking bitwise shifting operators, but supports other logical and arithmetic operators. Shift operations can be implemented via arithmetic operators, but that has a higher cost and requires more processing time from the host. Implementing `SHL` and `SHR` using arithmetic cost each 35 gas, while the proposed instructions take 3 gas. ## Specification diff --git a/EIPS/eip-1450.md b/EIPS/eip-1450.md index 1eeb19903971a..ddbb8ba157f4a 100644 --- a/EIPS/eip-1450.md +++ b/EIPS/eip-1450.md @@ -301,7 +301,7 @@ Investors may “lose” their credentials for a number of reasons: they simply If an Investor (or, say, the Investor’s heir) loses their credentials, the Investor must go through a notarized process to notify the RTA of the situation and supply a new Investor address. From there, the RTA can `mint` the “lost” securities to the new Investor address and `burnFrom` the old Investor address (because the RTA knows all Investors’ addresses). ## Rationale -The are currently no token standards that faciliate compliance with SEC regulations. The closest token is [ERC-884 (Delaware General Corporations Law (DGCL) compatible share token)](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-884.md) which states that SEC requirements are out of scope. [EIP-1404 (Simple Restricted Token Standard)](https://github.com/ethereum/EIPs/issues/1404) does not go far enough to address SEC requirements around re-issuing securities to Investors. +The are currently no token standards that facilitate compliance with SEC regulations. The closest token is [ERC-884 (Delaware General Corporations Law (DGCL) compatible share token)](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-884.md) which states that SEC requirements are out of scope. [EIP-1404 (Simple Restricted Token Standard)](https://github.com/ethereum/EIPs/issues/1404) does not go far enough to address SEC requirements around re-issuing securities to Investors. ## Backwards Compatibility `ERC-1450` maintains compatibility with ERC-20 tokens with the following stipulations: diff --git a/EIPS/eip-1462.md b/EIPS/eip-1462.md index f2004d0adc106..59713317ba9d9 100644 --- a/EIPS/eip-1462.md +++ b/EIPS/eip-1462.md @@ -83,7 +83,7 @@ Each function must return a status code from the common set of Ethereum status c For both cases, * It is required for guaranteed compatibility with ERC-20 and ERC-777 wallets that each checking function returns `0x11` (Allowed) if not overridden with the issuer's custom logic. -* It is required that all overriden checking functions must revert if the action is not allowed or an error occured, according to the returned status code. +* It is required that all overridden checking functions must revert if the action is not allowed or an error occurred, according to the returned status code. Inside checker functions the logic is allowed to use any feature available on-chain: perform calls to registry contracts with whitelists/blacklists, use built-in checking logic that is defined on the same contract, or even run off-chain queries through an oracle. diff --git a/EIPS/eip-1470.md b/EIPS/eip-1470.md index bda13e61495b6..d6f9dffc24f45 100644 --- a/EIPS/eip-1470.md +++ b/EIPS/eip-1470.md @@ -54,7 +54,7 @@ The SWC in its most basic form links a numeric identifier to a weakness variant. **SWC definition** -A SWC definition is formated in markdown to allow good readability and tools to process them easily. It consists of the following attributes. +A SWC definition is formatted in markdown to allow good readability and tools to process them easily. It consists of the following attributes. - Title: A name for the weakness that points to the technical root cause. - Relationships: Links a CWE _Base_ or _Class_ type to its CWE variant. The _Integer Overflow and Underflow_ variant for example is linked to [CWE-682 - Incorrect Calculation](https://cwe.mitre.org/data/definitions/682.html). diff --git a/EIPS/eip-1484.md b/EIPS/eip-1484.md index 87d4340040b20..ebe60637774e6 100644 --- a/EIPS/eip-1484.md +++ b/EIPS/eip-1484.md @@ -179,7 +179,7 @@ Triggers event: [IdentityCreated](#identitycreated) #### createIdentityDelegated -Preforms the same logic as `createIdentity`, but can be called by any address. This function requires a signature from the `associatedAddress` to ensure their consent. +Performs the same logic as `createIdentity`, but can be called by any address. This function requires a signature from the `associatedAddress` to ensure their consent. ```solidity function createIdentityDelegated( @@ -252,7 +252,7 @@ Triggers event: [ProviderAdded](#provideradded) #### addProvidersFor -Preforms the same logic as `addProviders`, but must be called by a `Provider`. +Performs the same logic as `addProviders`, but must be called by a `Provider`. ```solidity function addProvidersFor(uint ein, address[] memory providers) public; @@ -273,7 +273,7 @@ Triggers event: [ProviderRemoved](#providerremoved) #### removeProvidersFor -Preforms the same logic as `removeProviders`, but is called by a `Provider`. +Performs the same logic as `removeProviders`, but is called by a `Provider`. ```solidity function removeProvidersFor(uint ein, address[] memory providers) public; @@ -294,7 +294,7 @@ Triggers event: [ResolverAdded](#resolveradded) #### addResolversFor -Preforms the same logic as `addResolvers`, but must be called by a `Provider`. +Performs the same logic as `addResolvers`, but must be called by a `Provider`. ```solidity function addResolversFor(uint ein, address[] memory resolvers) public; @@ -314,7 +314,7 @@ Triggers event: [ResolverRemoved](#resolverremoved) #### removeResolversFor -Preforms the same logic as `removeResolvers`, but must be called by a `Provider`. +Performs the same logic as `removeResolvers`, but must be called by a `Provider`. ```solidity function removeResolversFor(uint ein, address[] memory resolvers) public; diff --git a/EIPS/eip-1485.md b/EIPS/eip-1485.md index 716455caf8eca..12040c4afdb76 100644 --- a/EIPS/eip-1485.md +++ b/EIPS/eip-1485.md @@ -97,7 +97,7 @@ In TETHashV1, Adapts fully follow the FNV1A implementation. - TETHASHV1 FNV1A implementation -Followings are reference implementation of FNV1A adapted in TETHashV1. +Following are reference implementation of FNV1A adapted in TETHashV1. ```cpp // Reference Pseudo c/cpp implementation @@ -177,7 +177,7 @@ F(00,10)::VEC(0, 10, ffffffff, 0):: FNV :00000010, DF=0000001f(05) DS(00000 In case of ethash algorithm, it can't prevent ASIC forever. -And, current ethash algorithm's FNV function is depricated. +And, current ethash algorithm's FNV function is deprecated. So, It needs to be upgraded and it will make current ethash based ASICs obsolete. @@ -187,7 +187,7 @@ Another propose of big differencing the Ethash algorithm need to crypto analysis **Verification and Optimization timeline Examples** -orignal ethminer (2015) -> claymore optimized miner (2016) [1year] +original ethminer (2015) -> claymore optimized miner (2016) [1year] genoil ethminer (2015) -> ethereum-mining/ethminer (2017) [2year] diff --git a/EIPS/eip-1491.md b/EIPS/eip-1491.md index 3b9c9a645755c..66502ef07748b 100644 --- a/EIPS/eip-1491.md +++ b/EIPS/eip-1491.md @@ -18,7 +18,7 @@ A standard interface for Human Capital Accounting tokens. ## Abstract -The following standard allows for the implementation of a standard API for HUCAP tokens within smart contracts. This standard provides basic functionality to discover, track and transfer the motivational hierarchy of human resources. While blockchain architecture has suceeded in the financialisation of integrity by way of transparency; correspondingly real world outcomes will be proportional to the degree of individualisation of capital by way of knowledge. +The following standard allows for the implementation of a standard API for HUCAP tokens within smart contracts. This standard provides basic functionality to discover, track and transfer the motivational hierarchy of human resources. While blockchain architecture has succeeded in the financialisation of integrity by way of transparency; correspondingly real world outcomes will be proportional to the degree of individualisation of capital by way of knowledge. ## Motivation @@ -425,21 +425,21 @@ interface IERC_HUCAP_KEYSIGNING_EXTENSION { /** /// @notice Cycle through state transition of an Agent in the ecosystem. /// @param _address toggle on/off a doer agent - // @dev `anybody` can retrive the talent data in the contract + // @dev `anybody` can retrieve the talent data in the contract */ function flipTo(address _address) external onlyOwner returns (IS); /** /// @notice Turn Agent in the ecosystem to on/off. /// @param _address toggle on/off a doer agent - // @dev `anybody` can retrive the talent data in the contract + // @dev `anybody` can retrieve the talent data in the contract */ function toggle(address _address) external onlyOwner returns (bool); /** /// @notice Set the trust level of an Agent in the ecosystem. /// @param _level toggle on/off a doer agent - // @dev `anybody` can retrive the talent data in the contract + // @dev `anybody` can retrieve the talent data in the contract */ function trust(Trust _level) returns (bytes32 Trust); @@ -457,66 +457,66 @@ pragma experimental ABIEncoderV2; interface IERC_HUCAP_TRACKUSERS_EXTENSION { - /// @notice Instatiate an Agent in the ecosystem with default data. + /// @notice Instantiate an Agent in the ecosystem with default data. /// @param _address initialise a doer agent - // @dev `anybody` can retrive the talent data in the contract + // @dev `anybody` can retrieve the talent data in the contract function initAgent(Doers _address) external onlyControlled returns (bool); /// @notice Get the data by uuid of an Agent in the ecosystem. /// @param _uuid Get the address of a unique uid - // @dev `anybody` can retrive the talent data in the contract + // @dev `anybody` can retrieve the talent data in the contract function getAgent(bytes32 _uuid) view external returns (address); /// @notice Get the data of all Talents in the ecosystem. /// @param _address Query if address belongs to an agent - // @dev `anybody` can retrive the talent data in the contract + // @dev `anybody` can retrieve the talent data in the contract function iam(address _address) view public returns (bool); /// @notice Get the data of all Talents in the ecosystem. /// @param _address Query if address belongs to a doer - // @dev `anybody` can retrive the talent data in the contract + // @dev `anybody` can retrieve the talent data in the contract function isDoer(address _address) view public returns (IS); /// @notice Get the number of doers that can be spawned by a Creators. /// The query condition of the contract - // @dev `anybody` can retrive the count data in the contract + // @dev `anybody` can retrieve the count data in the contract function getAgent(address _address) view public returns (bytes32 keyid_, IS state_, bool active_, uint myDoers_); /// @notice Get the data of all Talents in the ecosystem. /// @param _talent The talent whose frequency is being queried - // @dev `anybody` can retrive the talent data in the contract + // @dev `anybody` can retrieve the talent data in the contract function getTalents(bytes32 _talent) view external returns (uint talentK_, uint talentI_, uint talentR_, uint talentF_); /// @notice Increment a kind of talent in the ecosystem. /// @param The talent whose frequency is being queried - // @dev `anybody` can retrive the talent data in the contract + // @dev `anybody` can retrieve the talent data in the contract function incTalent() payable public onlyDoer returns (bool); /// @notice Decrement a kind of talent in the ecosystem.. /// @param The talent whose frequency is being queried - // @dev `anybody` can retrive the talent data in the contract + // @dev `anybody` can retrieve the talent data in the contract function decTalent() payable public onlyDoer returns (bool); /// @notice Set the Public-Key Id of an Agent in the ecosystem. /// @param _address Set the Public-key Id of an agent - // @dev `anybody` can retrive the talent data in the contract + // @dev `anybody` can retrieve the talent data in the contract function setAgent(address _address, bytes32 _keyId) external onlyControlled returns (bytes32); /// @notice Transition the states of an Agent in the ecosystem. /// @param _address Set the stance of an agent - // @dev `anybody` can retrive the talent data in the contract + // @dev `anybody` can retrieve the talent data in the contract function setAgent(address _address, IS _state) external onlyControlled returns (IS); /// @notice Set the active status of an Agent in the ecosystem. /// @param _address Toggle the true/false status of an agent - // @dev `anybody` can retrive the talent data in the contract + // @dev `anybody` can retrieve the talent data in the contract function setAgent(address _address, bool _active) external onlyControlled returns (bool); /// @notice Set the data of all Intentions of Agents in the ecosystem. /// @param _serviceId Track number of offers available - // @dev `anybody` can retrive the talent data in the contract + // @dev `anybody` can retrieve the talent data in the contract function setAllPromises(bytes32 _serviceId) external onlyControlled; /* End of interface IERC_HUCAP_TRACKUSERS_EXTENSION */ diff --git a/EIPS/eip-1571.md b/EIPS/eip-1571.md index fedc29b994b48..942d0e359bbcc 100644 --- a/EIPS/eip-1571.md +++ b/EIPS/eip-1571.md @@ -80,7 +80,7 @@ The JSON representation of `request` object is made of these parts: The JSON representation of `response` object is made of these parts: - mandatory `id` member of type Integer : the identifier of the request this response corresponds to - optional `error` member : whether an error occurred during the parsing of the method or during it's execution this member **MUST** be present and valued. If no errors occurred this member **MUST NOT** be present. For a detailed structure of the `error` member see below. -- optional `result` member : This has to be set, if the corresponding request requires a result from the user. If no errors occurred by invoking the corresponding function, this member **MUST** be present even if one or more informations are null. The type can be of Object or single type Array or Primitive string/number. If no data is meant back for the issuer (the method is void on the receiver) or an error occurred this member **MUST NOT** be present. +- optional `result` member : This has to be set, if the corresponding request requires a result from the user. If no errors occurred by invoking the corresponding function, this member **MUST** be present even if one or more information are null. The type can be of Object or single type Array or Primitive string/number. If no data is meant back for the issuer (the method is void on the receiver) or an error occurred this member **MUST NOT** be present. You'll notice here some differences with standard JSON-RPC-2.0. Namely the result member is not always required. Basically a response like this : ```json @@ -141,13 +141,13 @@ Using proper error codes pools may properly inform miners of the condition of th - Error codes 5xx : server could not process the request due to internal errors ### Notifications -A notification message has the very same representation of a `request` with the only difference the `id` member **MUST NOT** be present. This means the issuer is not interested nor expects any reponse to this message. It's up to the receiver to take actions accordingly. For instance the receiver **MAY** decide to execute the method, or, in case of errors or methods not allowed, drop the connection thus closing the session. +A notification message has the very same representation of a `request` with the only difference the `id` member **MUST NOT** be present. This means the issuer is not interested nor expects any response to this message. It's up to the receiver to take actions accordingly. For instance the receiver **MAY** decide to execute the method, or, in case of errors or methods not allowed, drop the connection thus closing the session. #### Error member As seen above a `response` **MAY** contain an `error` member. When present this member **MUST** be an Object with: - mandatory member `code` : a Number which identifies the error occurred - mandatory member `message` : a short human readable sentence describing the error occurred -- optional member `data` : a Structured or Primitive value that contains additional informations about the error. The value of this member is defined by the Server (e.g. detailed error information, nested errors etc.). +- optional member `data` : a Structured or Primitive value that contains additional information about the error. The value of this member is defined by the Server (e.g. detailed error information, nested errors etc.). ## Protocol Flow - Client starts session by opening a TCP socket to the server @@ -373,7 +373,7 @@ At the beginning of each `session` the server **MUST** send this notification be Whenever the server detects that one, or two, or three or four values change within the session, the server will issue a notification with one, or two or three or four members in the `param` object. For this reason on each **new** session the server **MUST** pass all four members. As a consequence the miner is instructed to adapt those values on **next** job which gets notified. The new `algo` member is defined to be prepared for possible presence of algorithm variants to ethash, namely ethash1a or ProgPow. Pools providing multicoin switching will take care to send a new `mining.set` to miners before pushing any job after a switch. -The client wich can't support the data provided in the `mining.set` notification **MAY** close connection or stay idle till new values satisfy it's configuration (see `mining.noop`). +The client which can't support the data provided in the `mining.set` notification **MAY** close connection or stay idle till new values satisfy it's configuration (see `mining.noop`). All client's implementations **MUST** be prepared to accept new extranonces during the session: unlike in EthereumStratum/1.0.0 the optional client advertisement `mining.extranonce.subscribe` is now implicit and mandatory. The miner receiving the `extranonce` **MUST** initialize the search segment for next job resizing the extranonce to a hex of 16 bytes thus appending as many zeroes as needed. @@ -462,7 +462,7 @@ When a miner finds a solution for a job he is mining on it sends a `mining.submi ] } ``` -First element of `params` array is the jobId this solution refers to (as sent in the `mining.notify` message from the server). Second element is the `miner nonce` as hex. Third element is the token given to the worker previous `mining.authorize` request. Any `mining.submit` request bound to a worker which was not succesfully authorized - i.e. the token does not exist in the session - **MUST** be rejected. +First element of `params` array is the jobId this solution refers to (as sent in the `mining.notify` message from the server). Second element is the `miner nonce` as hex. Third element is the token given to the worker previous `mining.authorize` request. Any `mining.submit` request bound to a worker which was not successfully authorized - i.e. the token does not exist in the session - **MUST** be rejected. You'll notice in the sample above the `miner nonce` is only 12 bytes wide (should be 16). Why ? That's because in the previous `mining.set` the server has set an `extranonce` of `af4c`. This means the full nonce is `af4c68765fccd712` @@ -488,7 +488,7 @@ or, in case of any error or condition with a detailed error object Client **should** treat errors as "soft" errors (stales) or "hard" (bad nonce computation, job not found etc.). Errors in 5xx range are server errors and suggest the miner to abandon the connection and switch to a failover. ### Hashrate -Most pools offer statistic informations, in form of graphs or by API calls, about the calculated hashrate expressed by the miner while miners like to compare this data with the hashrate they read on their devices. Communication about parties of these informations have never been coded in Stratum and most pools adopt the method from getWork named `eth_submitHashrate`. +Most pools offer statistic information, in form of graphs or by API calls, about the calculated hashrate expressed by the miner while miners like to compare this data with the hashrate they read on their devices. Communication about parties of these information have never been coded in Stratum and most pools adopt the method from getWork named `eth_submitHashrate`. In this document we propose an official implementation of the `mining.hashrate` request. This method behaves differently when issued from client or from server. #### Client communicates it's hashrate to server. @@ -540,7 +540,7 @@ Optionally the server can **notify** client about it's overall performance (acco } } ``` -Where `params` is an object which holds theese members for values of the **whole session**: +Where `params` is an object which holds these members for values of the **whole session**: - `interval` (number) the width, in minutes, of the observation window. "_in the last x minutes we calculated ..._" - `hr` (hex) representation of the hashrate the pool has calculated for the miner - `accepted` is an array of two number elements : the first is the overall count of accepted shares and the second is the number of stale shares. The array must be interpreted as "total accepted of which x are stale" diff --git a/EIPS/eip-1613.md b/EIPS/eip-1613.md index 7ed7b64c2a6db..973e040f1ef96 100644 --- a/EIPS/eip-1613.md +++ b/EIPS/eip-1613.md @@ -225,7 +225,7 @@ Scaling such attack would be prohibitively expensive, and actually quite profita ##### Attack: Relay attempts to censor a transaction by signing it, but using a nonce higher than it's current nonce. In this attack, the Relay did create and return a perfectly valid transaction, but it will not be mined until this Relay fills the gap in the nonce with 'missing' transactions. -This may delay the relaying of some transactions indefinately. In order to mitigate that, the sender includes a `max_nonce` parameter with it's signing request. +This may delay the relaying of some transactions indefinitely. In order to mitigate that, the sender includes a `max_nonce` parameter with it's signing request. It is suggested to be higher by 2-3 from current nonce, to allow the relay process several transactions. When the sender receives a transaction signed by a Relay he validates that the nonce used is valid, and if it is not, the client will ignore the given relay and use other relays to relay given transaction. Therefore, there will be no actual delay introduced by such attack. diff --git a/EIPS/eip-1616.md b/EIPS/eip-1616.md index c709dd104ccb2..c22cdec233d9a 100644 --- a/EIPS/eip-1616.md +++ b/EIPS/eip-1616.md @@ -25,7 +25,7 @@ This EIP contains the following core ideas: Potential advanced uses of attribute registries include: * Encoding complex boolean expressions which combine multiple attributes into a single uint256 key, which is then parsed and evaluated by the registry logic. * Using values associated with an attribute to query additional on-chain or off-chain metadata. -* Resolving attribute values by calling into seperate attribute registries or other contracts, delegating authority without changing the interface of the registry. +* Resolving attribute values by calling into separate attribute registries or other contracts, delegating authority without changing the interface of the registry. ## Motivation @@ -213,7 +213,7 @@ contract AttributeRegistry is AttributeRegistryInterface { mapping(address => mapping(uint256 => uint256)) private _issuedAttributeValues; /** - * @notice The constructor function, defines the two attribute types avaiable + * @notice The constructor function, defines the two attribute types available * on this particular registry. */ constructor() public { diff --git a/EIPS/eip-162.md b/EIPS/eip-162.md index 60cec465991f9..d1936bd63b0df 100644 --- a/EIPS/eip-162.md +++ b/EIPS/eip-162.md @@ -135,7 +135,7 @@ The following table outlines what portion of the balance held in a deed contract ### Deployment and Upgrade process -The Initial Registrar requires the ENS's address as a contructor, and should be deployed after the ENS. The multisig account owning the root node in the ENS should then set the Initial Registrar's address as owner of the `eth` node. +The Initial Registrar requires the ENS's address as a constructor, and should be deployed after the ENS. The multisig account owning the root node in the ENS should then set the Initial Registrar's address as owner of the `eth` node. The Initial Registrar is expected to be replaced by a Permanent Registrar approximately 2 years after deployment. The following process should be used for the upgrade: 1. The Permanent Registrar contract will be deployed. diff --git a/EIPS/eip-165.md b/EIPS/eip-165.md index 5d333aab4f91e..e71e96e02a462 100644 --- a/EIPS/eip-165.md +++ b/EIPS/eip-165.md @@ -144,7 +144,7 @@ contract ERC165Query { assembly { let x := mload(0x40) // Find empty storage location using "free memory pointer" - mstore(x, erc165ID) // Place signature at begining of empty storage + mstore(x, erc165ID) // Place signature at beginning of empty storage mstore(add(x, 0x04), _interfaceId) // Place first argument directly next to signature success := staticcall( diff --git a/EIPS/eip-1681.md b/EIPS/eip-1681.md index 2e557f28cbf73..28c6b2fca4a72 100644 --- a/EIPS/eip-1681.md +++ b/EIPS/eip-1681.md @@ -51,7 +51,7 @@ For the dust-account clearing usecase, - Other schemas which uses the `nonce` can have unintended side-effects, - such as inability to create contracts at certain addresses. - more difficult to integrate with offline signers, since more elaborate nonce-schemes requires state access to determine. - - More intricate schemes like `highest-nonce` are a lot more difficult, since highest-known-nonce will be a consensus-struct that is incremented and possibly reverted during transaction execution, requireing one more journalled field. + - More intricate schemes like `highest-nonce` are a lot more difficult, since highest-known-nonce will be a consensus-struct that is incremented and possibly reverted during transaction execution, requiring one more journalled field. ### Rationale for walltime diff --git a/EIPS/eip-1702.md b/EIPS/eip-1702.md index 1dc088d2a76f9..e6096ee500971 100644 --- a/EIPS/eip-1702.md +++ b/EIPS/eip-1702.md @@ -171,7 +171,7 @@ change how current contracts are executed. ### Performance Currently nearly all full node implementations uses config parameters -to decide which virtual machine version to use. Switching vitual +to decide which virtual machine version to use. Switching virtual machine version is simply an operation that changes a pointer using a different set of config parameters. As a result, this scheme has nearly zero impact to performance. diff --git a/EIPS/eip-1775.md b/EIPS/eip-1775.md index 1c62388756299..8aa747219a230 100644 --- a/EIPS/eip-1775.md +++ b/EIPS/eip-1775.md @@ -16,7 +16,7 @@ requires: 137 Among others cryptographic applications, scalability and privacy solutions for ethereum blockchain require that an user performs a significant amount of signing operations. It may also require her to watch some state and be ready to sign data automatically (e.g. sign a state or contest a withdraw). The way wallets currently implement accounts poses several obstacles to the development of a complete web3.0 experience both in terms of UX, security and privacy. -This proposal describes a standard and api for a new type of wallet accounts that are derived specifically for a each given application. We propose to call them `app keys`. They allow to isolate the accounts used for each application, thus potentially increasing privacy. They also allow to give more control to the applications developpers over account management and signing delegation. For these app keys, wallets can have a more permissive level of security (e.g. not requesting user's confirmation) while keeping main accounts secure. Finally wallets can also implement a different behavior such as allowing to sign transactions without broadcasting them. +This proposal describes a standard and api for a new type of wallet accounts that are derived specifically for a each given application. We propose to call them `app keys`. They allow to isolate the accounts used for each application, thus potentially increasing privacy. They also allow to give more control to the applications developers over account management and signing delegation. For these app keys, wallets can have a more permissive level of security (e.g. not requesting user's confirmation) while keeping main accounts secure. Finally wallets can also implement a different behavior such as allowing to sign transactions without broadcasting them. This new accounts type can allow to significantly improve UX and permit new designs for applications of the crypto permissionned web. @@ -26,7 +26,7 @@ In a wallet, an user often holds most of her funds in her main accounts. These a We introduce here a new account type, app keys, which permits signing delegation and accounts isolation across applications for privacy and security. -In this EIP, we provide a proposal on how to uniquely identify and authenticate each application, how to derive the accounts along an Hierachical Deterministic (HD) path restricted for the domain and we finally define an API for applications to derive and use these app keys. This ERC aims at finding a standard that will fit the needs of wallets and application developers while also allowing app keys to be used across wallets and yield the same accounts for the user for each application. +In this EIP, we provide a proposal on how to uniquely identify and authenticate each application, how to derive the accounts along an Hierarchical Deterministic (HD) path restricted for the domain and we finally define an API for applications to derive and use these app keys. This ERC aims at finding a standard that will fit the needs of wallets and application developers while also allowing app keys to be used across wallets and yield the same accounts for the user for each application. ## Motivation @@ -86,7 +86,7 @@ However, there may be benefits to use only one depth instead of 3. We could use ### Personas -We allow the user to use different personas in combination to her mnemonic to potentially fully isolate her interaction with a given app accross personas. One can use this for instance to create a personal and business profile for a given's domain both backup up from the same mnemonic, using 2 different personnas indexes. The app or domain, will not be aware that it is the same person and mnemonic behind both. +We allow the user to use different personas in combination to her mnemonic to potentially fully isolate her interaction with a given app across personas. One can use this for instance to create a personal and business profile for a given's domain both backup up from the same mnemonic, using 2 different personnas indexes. The app or domain, will not be aware that it is the same person and mnemonic behind both. We use a string following BIP32 format (can be hardened) to define personas. The indexes should be hex under 0x80000000, 31 bits. @@ -105,7 +105,7 @@ There are a few restrictions however on the characters used and normalisation, e In addition there must be a maximum size to the domain string that we need to determine such that the mapping from strings to nodes remains injective, to avoid collision. -We recommend this standard to be following the [ENS Specs](http://docs.ens.domains/en/latest/implementers.html#namehash), reproduced below for convinience and reference. +We recommend this standard to be following the [ENS Specs](http://docs.ens.domains/en/latest/implementers.html#namehash), reproduced below for convenience and reference. ``` Normalising and validating names @@ -239,9 +239,9 @@ and converted to uints ``` -* Second approach favors an homogenous decomposition: +* Second approach favors an homogeneous decomposition: -Equal lenght indexes would be 16 * 16 bits or in other words 16 * 2 bytes, cleanest and favored spec: +Equal length indexes would be 16 * 16 bits or in other words 16 * 2 bytes, cleanest and favored spec: ``` x = x0 || x1 || x2 || x3 || x4 || x5 || x6 || x7 || x8 || x9 || x10 || x11 || x12 || x13 || x14 || x15 @@ -270,7 +270,7 @@ Finally, the last part of the hd path is under the application's control. This w We consider that a given child on the HD tree should be called an `account` and not an `address` since it is composed of a private key, a public key and an address. Similarly to the persona path, this sub path must follow bip32, with hex under 0x80000000, 31 bits. -It can be hardened depending on each application's needs and can be writen as hex or unsigned integers. +It can be hardened depending on each application's needs and can be written as hex or unsigned integers. It can include a large number of indexes. Q [Should we set a limit on the persona and application customsable hd path number of indexes?] @@ -299,7 +299,7 @@ We propose to introduce new RPC methods but they should be restricted and wrappe * `wallet.appkey.enable(options)` This method allows to enable app keys (getting user permission to use and allow him to select the persona she would like to use). -[TBD] Could return the account public key from the HD path before `the app's custom subPath`. Hence from this app's root account, one could derive all non hardened childs public keys of the app's keys. +[TBD] Could return the account public key from the HD path before `the app's custom subPath`. Hence from this app's root account, one could derive all non hardened children public keys of the app's keys. [TBD] where `options` is a javascript object containing the permissions requested for these app keys. Options could also include a challenge to be signed by the app's root account (would serve as authentication of the users from the app's perspective). The signature should then be also returned. @@ -390,7 +390,7 @@ If there is a strong demand, we could add a method that exposes the private keys We indeed think that writing applications that don't need to manipulate the user private keys is a better pattern. For instance, if one needs the user to sign data while being offline, one should for instance rather implement a delegation method to an external application's controlled account rather than storing the user private key on a server that stays online. -### Persona isolation accross applications for privacy +### Persona isolation across applications for privacy The persona path is set by the user-wallet interaction and known only by them. There is thus a strict isolation between 2 different persona subpaths as if they were generated by different mnemonics. @@ -417,13 +417,13 @@ For the persona specification this may not be possible, unless we impose some st ### Hardened and non-hardened indexes: privacy and functionality -Hardening allows to increase privacy. If the extended public key of a parent level in the HD tree is known, public keys of its childs can not be computed if they are hardened. On the contrary if the child indexes are not hardened one can enumerate the child public keys and use that for the application design or to easily restore a wallet and it increases functionality. +Hardening allows to increase privacy. If the extended public key of a parent level in the HD tree is known, public keys of its children can not be computed if they are hardened. On the contrary if the child indexes are not hardened one can enumerate the child public keys and use that for the application design or to easily restore a wallet and it increases functionality. For the first parts of the HD tree, we need isolation and privacy. Thus we use hardened indexes for the persona and application paths in case some extended public key leaks at some previous level of the tree, it would protect the sub trees (of course this has no impact if private keys leak). For instance if we don't harden the application path, in case a persona public key is known and the application subpath does not use hardening either, one could get all `app keys` public keys for every application for this persona. -However the app can use non hardened indexes in their custom path part to be able to benefit from guessing child public keys from parent one (for instance for counterfactual state channel interaction accross 2 peers that would like to use new keys every time they counterfactually instantiate a new sub app). +However the app can use non hardened indexes in their custom path part to be able to benefit from guessing child public keys from parent one (for instance for counterfactual state channel interaction across 2 peers that would like to use new keys every time they counterfactually instantiate a new sub app). ### Alternatives for the HD derivation path @@ -478,7 +478,7 @@ We think our approach while also being more englobing benefits from not requirin #### Shortening the Hash node -Our current approach uses identification through an ENS name converted to a hash node and sliced fully but one could potentially keep only the first 16 bytes of the node for instance and slice them similarly. This may increase the chance of app collision but we probably can reduce the lenght while retaining an injective mapping from strings to hashes. +Our current approach uses identification through an ENS name converted to a hash node and sliced fully but one could potentially keep only the first 16 bytes of the node for instance and slice them similarly. This may increase the chance of app collision but we probably can reduce the length while retaining an injective mapping from strings to hashes. #### Alternative application identification specification @@ -509,18 +509,18 @@ Another alternative could be to use the plain website url and get rid of ens alt For authentication we use DNS and ENS resolution, and browsing to a given url resolved. A few comments on this: A few comments in case of ENS resolution: -* First connection requires the wallet to connect to ethereum mainnet, but once first resolution is done we could use some metadata paramater such as `author address` for a blockchain less authentication of the application (e.g. application server signs a challenge message with the author address resolved in the ENS metadata). +* First connection requires the wallet to connect to ethereum mainnet, but once first resolution is done we could use some metadata parameter such as `author address` for a blockchain less authentication of the application (e.g. application server signs a challenge message with the author address resolved in the ENS metadata). * The url the name resolves to through ENS can change without the user knowing and then a different application/website may be granted access to his app keys. But this means the ENS name owner address was copromised. This would be similar to using a signing challenge authentified by a known public key. If this known public key is compromised we have a similar problem. * Homoglyph attacks are not a bigger problem for `app keys` than it is for ENS since it will not grant access to `app keys` from the real domain (they would be derived along a different path). However homoglyph applications may lure the user to send funds from her main account to an `app key` of a malicious homoglyphic domain. Other metadata resolution through ENS that can be used alongside: -* `author address`: already mentionned above +* `author address`: already mentioned above * `contract address`: For app keys that would be designed to interact with a given ethereum contract (for instance app keys for a given token, if one desires to do so), other metadata fields could be used such as contract addresses. * [TBD] -In relation to the SLIP13 proposal mentionned above, one could think of alternative specifications that would use some certificate for authentication similar to https. +In relation to the SLIP13 proposal mentioned above, one could think of alternative specifications that would use some certificate for authentication similar to https. ### An Account gap limit standard for application controlled hd sub-path? diff --git a/EIPS/eip-1895.md b/EIPS/eip-1895.md index 4067b3a5f84a8..5c097b75c4115 100644 --- a/EIPS/eip-1895.md +++ b/EIPS/eip-1895.md @@ -132,7 +132,7 @@ In the EVM the compressed form allows us to represents curve points with 2 uint2 ## Rationale -The curve has 80 bits of security (whereas MNT6 has 120 bits) which might not be considered enough for critical security level, (for instance transfering several billions), but enough for others. If it turns out this is not enough security for adoption, there is another option : another cycle is being used by Coda but is defined over a 753 bits sized field which might also be prohibitively low (no reference to this curve from Coda's publications found). +The curve has 80 bits of security (whereas MNT6 has 120 bits) which might not be considered enough for critical security level, (for instance transferring several billions), but enough for others. If it turns out this is not enough security for adoption, there is another option : another cycle is being used by Coda but is defined over a 753 bits sized field which might also be prohibitively low (no reference to this curve from Coda's publications found). Independently of the cycle chosen, the groups and field elements are represented with integers larger than 256 bits (even for the 80 bits of security), therefore it might be necessary to also add support for larger field size operations. diff --git a/EIPS/eip-1922.md b/EIPS/eip-1922.md index 9742dd364f939..e0f9d76ae6150 100644 --- a/EIPS/eip-1922.md +++ b/EIPS/eip-1922.md @@ -89,7 +89,7 @@ interface ERC165 { ⚠️ TODO: Add a specific reference to libsnark here, explaining the choice of variable names. -:warning: TODO: Explain how _C_ may not necessarilly be a satisfiable arithmetic circuit of logical statements. As current, this is a limitation to certain kinds of SNARKS. Whereas the source references also mention polynomials, and other applications. +:warning: TODO: Explain how _C_ may not necessarily be a satisfiable arithmetic circuit of logical statements. As current, this is a limitation to certain kinds of SNARKS. Whereas the source references also mention polynomials, and other applications. _C_ — A satisfiable arithmetic circuit abstraction of logical statements. diff --git a/EIPS/eip-1930.md b/EIPS/eip-1930.md index 7452c7fff0b8c..abf1456cb9b15 100644 --- a/EIPS/eip-1930.md +++ b/EIPS/eip-1930.md @@ -54,20 +54,20 @@ if !callCost.IsUint64() || gas < callCost.Uint64() { ### Rationale -Currenlty the gas specified as part of these opcodes is simply a maximum value. And due to the behavior of [EIP-150](http://eips.ethereum.org/EIPS/eip-150) it is possible for an external call to be given less gas than intended (less than the gas specified as part of the CALL) while the rest of the current call is given enough to continue and succeed. Indeed since with EIP-150, the external call is given at max ```G - Math.floor(G/64)``` where G is the gasleft() at the point of the CALL, the rest of the current call is given ```Math.floor(G/64)``` which can be plenty enough for the transaction to succeed. For example, when G = 6,400,000 the rest of the transaction will be given 100,000 gas plenty enough in many case to succeed. +Currently the gas specified as part of these opcodes is simply a maximum value. And due to the behavior of [EIP-150](http://eips.ethereum.org/EIPS/eip-150) it is possible for an external call to be given less gas than intended (less than the gas specified as part of the CALL) while the rest of the current call is given enough to continue and succeed. Indeed since with EIP-150, the external call is given at max ```G - Math.floor(G/64)``` where G is the gasleft() at the point of the CALL, the rest of the current call is given ```Math.floor(G/64)``` which can be plenty enough for the transaction to succeed. For example, when G = 6,400,000 the rest of the transaction will be given 100,000 gas plenty enough in many case to succeed. This is an issue for contracts that require external call to only fails if they would fails with enough gas. This requirement is present in smart contract wallet and meta transaction in general, where the one executing the transaction is not the signer of the execution data. Because in such case, the contract needs to ensure the call is executed exactly as the signing user intended. But this is also true for simple use case, like checking if a contract implement an interface via EIP-165. Indeed as specified by such EIP, the ```supporstInterface``` method is bounded to use 30,000 gas so that it is theorically possible to ensure that the throw is not a result of a lack of gas. Unfortunately due to how the different CALL opcodes behave contracts can't simply rely on the gas value specified. They have to ensure by other means that there is enough gas for the call. -Indeed, if the caller do not ensure that 30,000 gas or more is provided to the callee, the callee might throw because of a lack of gas (and not because it does not support the interace), and the parent call will be given up to 476 gas to continue. This would result in the caller interepreting wrongly that the callee is not implementing the interface in question. +Indeed, if the caller do not ensure that 30,000 gas or more is provided to the callee, the callee might throw because of a lack of gas (and not because it does not support the interface), and the parent call will be given up to 476 gas to continue. This would result in the caller interepreting wrongly that the callee is not implementing the interface in question. While such requirement can be enforced by checking the gas left according to EIP-150 and the precise gas required before the call (see solution presented in that [bug report](https://web.solidified.io/contract/5b4769b1e6c0d80014f3ea4e/bug/5c83d86ac2dd6600116381f9) or after the call (see the native meta transaction implementation [here](https://github.com/pixowl/thesandbox-contracts/blob/623f4d4ca10644dcee145bcbd9296579a1543d3d/src/Sand/erc20/ERC20MetaTxExtension.sol#L176), it would be much better if the EVM allowed us to strictly specify how much gas is to be given to the CALL so contract implementations do not need to follow [EIP-150](http://eips.ethereum.org/EIPS/eip-150) behavior and the current gas pricing so closely. This would also allow the behaviour of [EIP-150](http://eips.ethereum.org/EIPS/eip-150) to be changed without having to affect contract that require this strict gas behaviour. As mentioned, such strict gas behaviour is important for smart contract wallet and meta transaction in general. -The issue is actually already a problem in the wild as can be seen in the case of Gnosis safe which did not consider the behavior of EIP-150 and thus fails to check the gas properly, requiring the safe owners to add otherwise unecessary extra gas to their signed message to avoid the possibility of losing funds. See https://github.com/gnosis/safe-contracts/issues/100 +The issue is actually already a problem in the wild as can be seen in the case of Gnosis safe which did not consider the behavior of EIP-150 and thus fails to check the gas properly, requiring the safe owners to add otherwise unnecessary extra gas to their signed message to avoid the possibility of losing funds. See https://github.com/gnosis/safe-contracts/issues/100 As for EIP-165, the issue already exists in the example implementation presented in the EIP. Please see the details of the issue [here](https://github.com/ethereum/EIPs/pull/881#issuecomment-491677748) @@ -85,7 +85,7 @@ uint256 gasAvailable = gasleft() - E; require(gasAvailable - gasAvailable / 64 >= `txGas`, "not enough gas provided") to.call.gas(txGas)(data); // CALL ``` -where E is the gas required for the operation beteen the call to ```gasleft()``` and the actual call PLUS the gas cost of the call itself. +where E is the gas required for the operation between the call to ```gasleft()``` and the actual call PLUS the gas cost of the call itself. While it is possible to simply over estimate ```E``` to prevent call to be executed if not enough gas is provided to the current call it would be better to have the EVM do the precise work itself. As gas pricing continue to evolve, this is important to have a mechanism to ensure a specific amount of gas is passed to the call so such mechanism can be used without having to relies on a specific gas pricing. diff --git a/EIPS/eip-1973.md b/EIPS/eip-1973.md index ed108da14eb20..64c7a9cf15cb6 100644 --- a/EIPS/eip-1973.md +++ b/EIPS/eip-1973.md @@ -29,7 +29,7 @@ A pull system is required to keep the application completely decentralized and t `token amount per participant in the ecosytem or TPP (token per participant)`: TPP = (token amount to mint / total active participants) - `roundMask`: the cummulative snapshot of TPP over time for the token contract. E.g. transactionOne = 10 tokens are minted with 100 available participants (TPP = 10 / 100) , transactionTwo = 12 tokens are minted with 95 participants (TPP = 12 / 95 ) + `roundMask`: the cumulative snapshot of TPP over time for the token contract. E.g. transactionOne = 10 tokens are minted with 100 available participants (TPP = 10 / 100) , transactionTwo = 12 tokens are minted with 95 participants (TPP = 12 / 95 ) roundMask = (10/100) + (12/95) @@ -39,7 +39,7 @@ A pull system is required to keep the application completely decentralized and t `rewards for msg.sender`: roundMask - participantMask - E.g. Let's assume a total of 6 transactions (smart contract triggers or functions calls) are in place with 10 exising participants (denominator) and 20 tokens (numerator) are minted per transaction. At 2nd transaction, the 11th participant joins the network and exits before 5th transaction, the 11th participant's balance is as follows: + E.g. Let's assume a total of 6 transactions (smart contract triggers or functions calls) are in place with 10 existing participants (denominator) and 20 tokens (numerator) are minted per transaction. At 2nd transaction, the 11th participant joins the network and exits before 5th transaction, the 11th participant's balance is as follows: ``` t1 roundMask = (20/10) @@ -52,7 +52,7 @@ A pull system is required to keep the application completely decentralized and t Total tokens released in 6 transactions = 60 tokens - As the participant joins at t2 and leaves before t5, the participant deserves the rewards between t2 and t4. When the participant joins at t2, the 'participantMask = (20/10)', when the participant leaves before t5, the cummulative deserved reward tokens are : + As the participant joins at t2 and leaves before t5, the participant deserves the rewards between t2 and t4. When the participant joins at t2, the 'participantMask = (20/10)', when the participant leaves before t5, the cumulative deserved reward tokens are : rewards for msg.sender: `[t4 roundMask = (20/10) + (20/11)+ (20/11) + (20/11)] - [participantMask = (20/10)] = [rewards = (20/11)+ (20/11) + (20/11)]` @@ -89,7 +89,7 @@ address public tokencontractAddress = address(this); mapping(address => uint256) public participantMask; /** - * @dev constructor, initilizes variables. + * @dev constructor, initializes variables. * @param _tokensPerBlock The amount of token that will be released per block, entered in wei format (E.g. 1000000000000000000) * @param _blockFreezeInterval The amount of blocks that need to pass (E.g. 1, 10, 100) before more tokens are brought into the ecosystem. */ diff --git a/EIPS/eip-210.md b/EIPS/eip-210.md index 859991c1f026d..abba50af202e5 100644 --- a/EIPS/eip-210.md +++ b/EIPS/eip-210.md @@ -83,4 +83,4 @@ The EVM bytecode that the contract code should be set to is: ### Rationale -This removes the need for implementaitons to have an explicit way to look into historical block hashes, simplifying the protocol definition and removing a large component of the "implied state" (information that is technically state but is not part of the state tree) and thereby making the protocol more "pure". Additionally, it allows blocks to directly point to blocks far behind them, which enables extremely efficient and secure light client protocols. +This removes the need for implementations to have an explicit way to look into historical block hashes, simplifying the protocol definition and removing a large component of the "implied state" (information that is technically state but is not part of the state tree) and thereby making the protocol more "pure". Additionally, it allows blocks to directly point to blocks far behind them, which enables extremely efficient and secure light client protocols. diff --git a/EIPS/eip-3.md b/EIPS/eip-3.md index 6337851663540..621b143554d6b 100644 --- a/EIPS/eip-3.md +++ b/EIPS/eip-3.md @@ -16,11 +16,11 @@ This is a proposal to add a new opcode, `CALLDEPTH`. The `CALLDEPTH` opcode woul There is a limit specifying how deep contracts can call other contracts; the call stack. The limit is currently `256`. If a contract invokes another contract (either via `CALL` or `CALLCODE`), the operation will fail if the call stack depth limit has been reached. -This behaviour makes it possible to subject a contract to a "call stack attack" [1]. In such an attack, an attacker first creates a suitable depth of the stack, e.g. by recursive calls. After this step, the attacker invokes the targeted contract. If the targeted calls another contract, that call will fail. If the return value is not properly checked to see if the call was successfull, the consequences could be damaging. +This behaviour makes it possible to subject a contract to a "call stack attack" [1]. In such an attack, an attacker first creates a suitable depth of the stack, e.g. by recursive calls. After this step, the attacker invokes the targeted contract. If the targeted calls another contract, that call will fail. If the return value is not properly checked to see if the call was successful, the consequences could be damaging. Example: -1. Contract `A` want's to be invoked regularly, and pays Ether to the invoker in every block. +1. Contract `A` wants to be invoked regularly, and pays Ether to the invoker in every block. 2. When contract `A` is invoked, it calls contracts `B` and `C`, which consumes a lot of gas. After invocation, contract `A` pays Ether to the caller. 3. Malicious user `X` ensures that the stack depth is shallow before invoking A. Both calls to `B` and `C` fail, but `X` can still collect the reward. diff --git a/EIPS/eip-5.md b/EIPS/eip-5.md index dfde87b3f110b..bb47fbe6d9300 100644 --- a/EIPS/eip-5.md +++ b/EIPS/eip-5.md @@ -108,7 +108,7 @@ The change in semantics affects existing contracts in two ways: all be written in a way, though, such that objects in memory are _relocatable_, i.e. their absolute position in memory and their relative position to other objects does not matter. This is of course not the case for arrays, but they - are allocated in a single allocation and not with an intermidiate `CALL`. + are allocated in a single allocation and not with an intermediate `CALL`. ### Implementation diff --git a/EIPS/eip-615.md b/EIPS/eip-615.md index b584498d8a025..d9d2b203f3ec7 100644 --- a/EIPS/eip-615.md +++ b/EIPS/eip-615.md @@ -390,7 +390,7 @@ Note that code like this is already run by EVMs to check dynamic jumps, includin #### Subroutine Validation -This function can be seen as a symbolic execution of a subroutine in the EVM code, where only the effect of the instructions on the state being validated is computed. Thus the structure of this function is very similar to an EVM interpreter. This function can also be seen as an acyclic traversal of the directed graph formed by taking instructions as vertexes and sequential and branching connections as edges, checking conditions along the way. The traversal is accomplished via recursion, and cycles are broken by returning when a vertex which has already been visited is reached. The time complexity of this traversal is `O(|E|+|V|)`: The sum of the number of edges and number of verticies in the graph. +This function can be seen as a symbolic execution of a subroutine in the EVM code, where only the effect of the instructions on the state being validated is computed. Thus the structure of this function is very similar to an EVM interpreter. This function can also be seen as an acyclic traversal of the directed graph formed by taking instructions as vertices and sequential and branching connections as edges, checking conditions along the way. The traversal is accomplished via recursion, and cycles are broken by returning when a vertex which has already been visited is reached. The time complexity of this traversal is `O(|E|+|V|)`: The sum of the number of edges and number of vertices in the graph. The basic approach is to call `validate_subroutine(i, 0, 0)`, for `i` equal to the first instruction in the EVM code through each `BEGINDATA` offset. `validate_subroutine()` traverses instructions sequentially, recursing when `JUMP` and `JUMPI` instructions are encountered. When a destination is reached that has been visited before it returns, thus breaking cycles. It returns true if the subroutine is valid, false otherwise. diff --git a/EIPS/eip-627.md b/EIPS/eip-627.md index 0fe174eaf7584..00f0133baa569 100644 --- a/EIPS/eip-627.md +++ b/EIPS/eip-627.md @@ -66,7 +66,7 @@ This packet is used for sending the standard Whisper envelopes. This packet contains two objects: integer message code (0x02) followed by a single floating point value of PoW. This value is the IEEE 754 binary representation of 64-bit floating point number. Values of qNAN, sNAN, INF and -INF are not allowed. Negative values are also not allowed. -This packet is used by Whisper nodes for dynamic adjustment of their individual PoW requirements. Receipient of this message should no longer deliver the sender messages with PoW lower than specified in this message. +This packet is used by Whisper nodes for dynamic adjustment of their individual PoW requirements. Recipient of this message should no longer deliver the sender messages with PoW lower than specified in this message. PoW is defined as average number of iterations, required to find the current BestBit (the number of leading zero bits in the hash), divided by message size and TTL: @@ -165,7 +165,7 @@ Symmetric encryption uses AES GCM algorithm with random 96-bit nonce. Packet codes 0x00 and 0x01 are already used in all Whisper versions. -Packet code 0x02 will be necessary for the future developement of Whisper. It will provide possiblitity to adjust the PoW requirement in real time. It is better to allow the network to govern itself, rather than hardcode any specific value for minimal PoW requirement. +Packet code 0x02 will be necessary for the future development of Whisper. It will provide possiblitity to adjust the PoW requirement in real time. It is better to allow the network to govern itself, rather than hardcode any specific value for minimal PoW requirement. Packet code 0x03 will be necessary for scalability of the network. In case of too much traffic, the nodes will be able to request and receive only the messages they are interested in. diff --git a/EIPS/eip-706.md b/EIPS/eip-706.md index e1f601250f0ea..4211c23b75a42 100644 --- a/EIPS/eip-706.md +++ b/EIPS/eip-706.md @@ -16,7 +16,7 @@ This EIP proposes a tiny extension to the DEVp2p protocol to enable [Snappy comp ## Motivation Synchronizing the Ethereum main network (block 4,248,000) in Geth using fast sync currently consumes 1.01GB upload and 33.59GB download bandwidth. On the Rinkeby test network (block 852,000) it's 55.89MB upload and 2.51GB download. -However, most of this data (blocks, transactions) are heavily compressable. By enabling compression at the message payload level, we can reduce the previous numbers to 1.01GB upload / 13.46GB download on the main network, and 46.21MB upload / 463.65MB download on the test network. +However, most of this data (blocks, transactions) are heavily compressible. By enabling compression at the message payload level, we can reduce the previous numbers to 1.01GB upload / 13.46GB download on the main network, and 46.21MB upload / 463.65MB download on the test network. The motivation behind doing this at the DEVp2p level (opposed to eth for example) is that it would enable compression for all sub-protocols (eth, les, bzz) seamlessly, reducing any complexity those protocols might incur in trying to individually optimize for data traffic. @@ -46,7 +46,7 @@ Important caveats: ### Avoiding DOS attacks -Currently a DEVp2p message length is limited to 24 bits, amounting to a maximum size of 16MB. With the introduction of Snappy compression, care must be taken not to blindy decompress messages, since they may get significantly larger than 16MB. +Currently a DEVp2p message length is limited to 24 bits, amounting to a maximum size of 16MB. With the introduction of Snappy compression, care must be taken not to blindly decompress messages, since they may get significantly larger than 16MB. However, Snappy is capable of calculating the decompressed size of an input message without inflating it in memory (*[the stream starts with the uncompressed length up to a maximum of `2^32 - 1` stored as a little-endian varint](https://github.com/google/snappy/blob/master/format_description.txt#L20)*). This can be used to discard any messages which decompress above some threshold. **The proposal is to use the same limit (16MB) as the threshold for decompressed messages.** This retains the same guarantees that the current DEVp2p protocol does, so there won't be surprises in application level protocols. diff --git a/EIPS/eip-712.md b/EIPS/eip-712.md index f7e8f893fc12f..14fa4c37ad8e8 100644 --- a/EIPS/eip-712.md +++ b/EIPS/eip-712.md @@ -157,7 +157,7 @@ If the struct type references other struct types (and these in turn reference ev ### Definition of `encodeData` -The encoding of a struct instance is `enc(value₁) ‖ enc(value₂) ‖ … ‖ enc(valueₙ)`, i.e. the concatenation of the encoded member values in the order that they apear in the type. Each encoded member value is exactly 32-byte long. +The encoding of a struct instance is `enc(value₁) ‖ enc(value₂) ‖ … ‖ enc(valueₙ)`, i.e. the concatenation of the encoded member values in the order that they appear in the type. Each encoded member value is exactly 32-byte long. The atomic values are encoded as follows: Boolean `false` and `true` are encoded as `uint256` values `0` and `1` respectively. Addresses are encoded as `uint160`. Integer values are sign-extended to 256-bit and encoded in big endian order. `bytes1` to `bytes31` are arrays with a beginning (index `0`) and an end (index `length - 1`), they are zero-padded at the end to `bytes32` and encoded in beginning to end order. This corresponds to their encoding in ABI v1 and v2. @@ -205,7 +205,7 @@ By adding a prefix to the message makes the calculated signature recognisable as 1. `Address` - 20 Bytes - Address of the account that will sign the messages. 2. `TypedData` - Typed structured data to be signed. -Typed data is a JSON object containing type information, domain seprator parameters and the message object. Below is the [json-schema][jsons] definition for `TypedData` param. +Typed data is a JSON object containing type information, domain separator parameters and the message object. Below is the [json-schema][jsons] definition for `TypedData` param. [jsons]: https://json-schema.org/ diff --git a/EIPS/eip-725.md b/EIPS/eip-725.md index c69731a5b90b4..8688e9cc86975 100644 --- a/EIPS/eip-725.md +++ b/EIPS/eip-725.md @@ -19,7 +19,7 @@ The following describes standard functions for a unique identifiable proxy accou ## Motivation Standardizing a minimal interface for an proxy account allows third parties to interact with various proxy accounts contracts in a consistent manner. -the benefit is a persistent account that is independed from single keys and can attach an arbitrary amount of information to verifiy, or enhance the accounts purpose. +the benefit is a persistent account that is independent from single keys and can attach an arbitrary amount of information to verifiy, or enhance the accounts purpose. ## Specification diff --git a/EIPS/eip-758.md b/EIPS/eip-758.md index 8d7df949ce890..89a5bffa1be28 100644 --- a/EIPS/eip-758.md +++ b/EIPS/eip-758.md @@ -46,7 +46,7 @@ Or to be notified of any transactions submitted by this rpc client when they com filter = {} ``` -After the request is recieved, the Ethereum node responds with a subscription ID: +After the request is received, the Ethereum node responds with a subscription ID: ```json {"jsonrpc": "2.0", "id": 1, "result": "0x00000000000000000000000000000b0b"} @@ -106,7 +106,7 @@ The node responds with an array of transaction hashes and their corresponding re } ``` -All transactions that were sealed _after_ the initial `eth_newCompletedTransactionFilter` request are included in this array. Again, if the `filter` param is a non-empty dictinary (contains either `from`, `to`, or `hasReturnData`) then only transactions matching the filter criteria generate notifications. Note that in the polling case, there is no way for the Ethereum node to be sure that an RPC client which submits a transaction was the same as the one who created the filter, so there is no restriction based on where the transaction was submitted. +All transactions that were sealed _after_ the initial `eth_newCompletedTransactionFilter` request are included in this array. Again, if the `filter` param is a non-empty dictionary (contains either `from`, `to`, or `hasReturnData`) then only transactions matching the filter criteria generate notifications. Note that in the polling case, there is no way for the Ethereum node to be sure that an RPC client which submits a transaction was the same as the one who created the filter, so there is no restriction based on where the transaction was submitted. ## Rationale diff --git a/EIPS/eip-823.md b/EIPS/eip-823.md index 727af0cf04e4f..f9eb4149be163 100644 --- a/EIPS/eip-823.md +++ b/EIPS/eip-823.md @@ -184,7 +184,7 @@ This event logs any new exchange that have taken place and have been spent immed event ExchangeAndSpent ( address _from, address _by, uint _value ,address _target ,address _to) ``` -### Diagramatic Explaination +### Diagramatic Explanation #### Exchanging Tokens ![token-exchange-standard-visual-representation-1](https://raw.githubusercontent.com/kashishkhullar/EIPs/master/assets/eip-823/eip-823-token-exchange-standard-visual-representation-1.PNG) diff --git a/EIPS/eip-918.md b/EIPS/eip-918.md index 1dc296e56d3dd..10047046b5e4b 100644 --- a/EIPS/eip-918.md +++ b/EIPS/eip-918.md @@ -66,7 +66,7 @@ bytes32 public adjustmentInterval; ``` #### challengeNumber -The current challenge number. It is expected tha a new challenge number is generated after a new reward is minted. +The current challenge number. It is expected that a new challenge number is generated after a new reward is minted. ``` solidity bytes32 public challengeNumber; @@ -145,7 +145,7 @@ contract AbstractERC918 is EIP918Interface { epochCount = _epoch(); - //every so often, readjust difficulty. Dont readjust when deploying + //every so often, readjust difficulty. Don't readjust when deploying if(epochCount % blocksPerReadjustment == 0){ _adjustDifficulty(); } @@ -273,7 +273,7 @@ contract ERC918Merged is AbstractERC918 { } /* - * @notice Externally facing merge function kept for backwards compatability with previous definition + * @notice Externally facing merge function kept for backwards compatibility with previous definition * * @param _nonce the solution nonce * @param _challenge_digest the keccak256 encoded challenge number + message sender + solution nonce @@ -442,7 +442,7 @@ Earlier versions of this standard incorporated a redundant 'challenge_digest' pa contract ERC918BackwardsCompatible is AbstractERC918 { /* - * @notice Externally facing mint function kept for backwards compatability with previous mint() definition + * @notice Externally facing mint function kept for backwards compatibility with previous mint() definition * @param _nonce the solution nonce * @param _challenge_digest the keccak256 encoded challenge number + message sender + solution nonce **/ diff --git a/EIPS/eip-998.md b/EIPS/eip-998.md index 88f0b9205245f..bc87b8b1fb20a 100644 --- a/EIPS/eip-998.md +++ b/EIPS/eip-998.md @@ -856,7 +856,7 @@ interface ERC998ERC721BottomUp { /// @return rootOwner The root owner at the top of tree of tokens and ERC998 magic value. function rootOwnerOf(uint256 _tokenId) external view returns (bytes32 rootOwner); - /// @notice Get the owner addess and parent token (if there is one) of a token + /// @notice Get the owner address and parent token (if there is one) of a token /// @param _tokenId The tokenId to query. /// @return tokenOwner The owner address of the token /// @return parentTokenId The parent owner of the token and ERC998 magic value @@ -947,7 +947,7 @@ Here is an example of a value returned by `rootOwnerOf`. #### tokenOwnerOf ```solidity -/// @notice Get the owner addess and parent token (if there is one) of a token +/// @notice Get the owner address and parent token (if there is one) of a token /// @param _tokenId The tokenId to query. /// @return tokenOwner The owner address of the token and ERC998 magic value. /// @return parentTokenId The parent owner of the token diff --git a/README.md b/README.md index 03278d567ae9d..3d0d63066ec1b 100644 --- a/README.md +++ b/README.md @@ -25,7 +25,7 @@ When you believe your EIP is mature and ready to progress past the draft phase, * **Draft** - an EIP that is undergoing rapid iteration and changes. * **Last Call** - an EIP that is done with its initial iteration and ready for review by a wide audience. -* **Accepted** - a core EIP that has been in Last Call for at least 2 weeks and any technical changes that were requested have been addressed by the author. The process for Core Devs to decide whether to encode an EIP into their clients as part of a hard fork is not part of the EIP process. If such a decision is made, the EIP wil move to final. +* **Accepted** - a core EIP that has been in Last Call for at least 2 weeks and any technical changes that were requested have been addressed by the author. The process for Core Devs to decide whether to encode an EIP into their clients as part of a hard fork is not part of the EIP process. If such a decision is made, the EIP will move to final. * **Final (non-Core)** - an EIP that has been in Last Call for at least 2 weeks and any technical changes that were requested have been addressed by the author. * **Final (Core)** - an EIP that the Core Devs have decided to implement and release in a future hard fork or has already been released in a hard fork. * **Deferred** - an EIP that is not being considered for immediate adoption. May be reconsidered in the future for a subsequent hard fork. diff --git a/assets/eip-1057/test-vectors.md b/assets/eip-1057/test-vectors.md index 991e2509acb49..5fcec000ab513 100644 --- a/assets/eip-1057/test-vectors.md +++ b/assets/eip-1057/test-vectors.md @@ -1,6 +1,6 @@ # Test Vectors for EIP-1057 - ProgPow -Many of these vectors are dervived from [chfast/ethash](https://github.com/chfast/ethash) +Many of these vectors are derived from [chfast/ethash](https://github.com/chfast/ethash) ## fnv1a @@ -121,7 +121,7 @@ Kiss 99 state: For the first loop iteration of block 30,000 the seed to use for `fill_mix` would be `0xEE304846DDD0A47B`. A two dimensional `mix` array should be created -passing the rows into `fill_mix` witht he column number as the loop argument. +passing the rows into `fill_mix` with the column number as the loop argument. The state of the mix array after the call to `progPowLoop` for block 30,000, loop 1 are as follows. diff --git a/index.html b/index.html index c79bd888d21d0..507775cb35acf 100644 --- a/index.html +++ b/index.html @@ -16,7 +16,7 @@

EIP status terms

  • Draft - an EIP that is open for consideration and is undergoing rapid iteration and changes.
  • Last Call - an EIP that is done with its initial iteration and ready for review by a wide audience.
    • -
  • Accepted - a core EIP that has been in Last Call for at least 2 weeks and any technical changes that were requested have been addressed by the author. The process for Core Devs to decide whether to encode an EIP into their clients as part of a hard fork is not part of the EIP process. If such a decision is made, the EIP wil move to final.
    • +
  • Accepted - a core EIP that has been in Last Call for at least 2 weeks and any technical changes that were requested have been addressed by the author. The process for Core Devs to decide whether to encode an EIP into their clients as part of a hard fork is not part of the EIP process. If such a decision is made, the EIP will move to final.
  • Final (non-Core) - an EIP that has been in Last Call for at least 2 weeks and any technical changes that were requested have been addressed by the author.
  • Final (Core) - an EIP that the Core Devs have decided to implement and release in a future hard fork or has already been released in a hard fork.
  • Deferred an EIP that is not being considered for immediate adoption. May be reconsidered in the future for a subsequent hard fork.
    • From 0fb666ba355d4844f8277427308a2da6340998cf Mon Sep 17 00:00:00 2001 From: Ronan Sandford Date: Sun, 19 May 2019 10:45:48 +0100 Subject: [PATCH 058/137] Automatically merged updates to draft EIP(s) 1679, 1965 (#2047) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-1679.md | 1 + EIPS/eip-1965.md | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/EIPS/eip-1679.md b/EIPS/eip-1679.md index 866cf7807e59e..e48285780984f 100644 --- a/EIPS/eip-1679.md +++ b/EIPS/eip-1679.md @@ -41,6 +41,7 @@ This meta-EIP specifies the changes included in the Ethereum hardfork named Ista - [EIP-1352](https://eips.ethereum.org/EIPS/eip-1352): Specify restricted address range for precompiles/system contracts - [EIP-1380](https://eips.ethereum.org/EIPS/eip-1380): Reduced gas cost for call to self - [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559): Fee market change for ETH 1.0 chain +- [EIP-1965](https://eips.ethereum.org/EIPS/eip-1965): Method to check if a chainID is valid at a specific block Number - [EIP-1702](https://eips.ethereum.org/EIPS/eip-1702): Generalized account versioning scheme - [EIP-1706](https://eips.ethereum.org/EIPS/eip-1706): Disable SSTORE with gasleft lower than call stipend - [EIP-1803](https://eips.ethereum.org/EIPS/eip-1803): Rename opcodes for clarity diff --git a/EIPS/eip-1965.md b/EIPS/eip-1965.md index ff432fa0c11b1..aad5ea94dd499 100644 --- a/EIPS/eip-1965.md +++ b/EIPS/eip-1965.md @@ -16,7 +16,7 @@ This EIP adds a precompile that returns whether a specific chainID (EIP-155 uniq ## Motivation [EIP-155](https://eips.ethereum.org/EIPS/eip-155) proposes to use the chain ID to prevent the replay of transactions between different chains. It would be a great benefit to have the same possibility inside smart contracts when handling off-chain message signatures, especially for Layer 2 signature schemes using [EIP-712](https://eips.ethereum.org/EIPS/eip-712). -[EIP-1344](http://eips.ethereum.org/EIPS/eip-1344) is attempting to solve this by giving smart contract access to the tip of the chainID history. This is insuficient as such value is changing. Hence why EIP-1344 describes a contract based solution to work arround the problem. It would be better to solve it in a simpler, cheaper and safer manner, removing the potential risk of misuse present in EIP-1344. Furthermore EIP-1344 can't protect replay properly for minority-led hardfork as the caching system cannot guarantee accuracy of the blockNumber at which the new chainID has been introduced. +[EIP-1344](http://eips.ethereum.org/EIPS/eip-1344) is attempting to solve this by giving smart contract access to the tip of the chainID history. This is insuficient as such value is changing. Hence why EIP-1344 describes a contract based solution to work around the problem. It would be better to solve it in a simpler, cheaper and safer manner, removing the potential risk of misuse present in EIP-1344. Furthermore EIP-1344 can't protect replay properly for minority-led hardfork as the caching system cannot guarantee accuracy of the blockNumber at which the new chainID has been introduced. [EIP-1959](https://github.com/ethereum/EIPs/pull/1959) solves the issue of EIP-1344 but do not attempt to protect from minority-led hardfork as mentioned in the rationale. We consider this a mistake, since it remove some freedom to fork. We consider that all fork should be given equal oportunities. And while there will always be issues we can't solve for the majority that ignore a particular fork, **users that decide to use both the minority-fork and the majority-chain should be protected from replay without having to wait for the majority chain to update its chainID.** From b1dd057c0fc1033e241e9648bb4d2d8d303db210 Mon Sep 17 00:00:00 2001 From: Ronan Sandford Date: Sun, 19 May 2019 15:42:39 +0100 Subject: [PATCH 059/137] Automatically merged updates to draft EIP(s) 1679 (#1990) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-1679.md | 1 + 1 file changed, 1 insertion(+) diff --git a/EIPS/eip-1679.md b/EIPS/eip-1679.md index e48285780984f..6c6d2187f8214 100644 --- a/EIPS/eip-1679.md +++ b/EIPS/eip-1679.md @@ -47,6 +47,7 @@ This meta-EIP specifies the changes included in the Ethereum hardfork named Ista - [EIP-1803](https://eips.ethereum.org/EIPS/eip-1803): Rename opcodes for clarity - [EIP-1829](https://eips.ethereum.org/EIPS/eip-1829): Precompile for Elliptic Curve Linear Combinations - [EIP-1884](https://eips.ethereum.org/EIPS/eip-1884): Repricing for trie-size-dependent opcodes +- [EIP-1930](https://eips.ethereum.org/EIPS/eip-1930): CALLs with strict gas semantic. Revert if not enough gas available. - [EIP-2028](https://eips.ethereum.org/EIPS/eip-2028): Calldata gas cost reduction ## Timeline From 6f35f9f376c6b4a299f14283171ce2fba5d403c6 Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Fri, 8 Mar 2019 14:13:12 +0100 Subject: [PATCH 060/137] Add special requirement for mentioning EVM instructions --- EIPS/eip-1.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/EIPS/eip-1.md b/EIPS/eip-1.md index 6596e6999d3cf..6d021ffbff4c8 100644 --- a/EIPS/eip-1.md +++ b/EIPS/eip-1.md @@ -35,6 +35,13 @@ It is highly recommended that a single EIP contain a single key proposal or new An EIP must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly. +### Special requirements for Core EIPs + +If a **Core** EIP mentions or proposes changes to the EVM (Ethereum Virtual Machine), it should refer to the instructions by their mnemonics and define the opcodes of those mnemonics at least once. A preferred way is the following: +``` +REVERT (0xfe) +``` + ## EIP Work Flow Parties involved in the process are you, the champion or *EIP author*, the [*EIP editors*](#eip-editors), and the [*Ethereum Core Developers*](https://github.com/ethereum/pm). From c2eca1eae4356680455c80967646b2793ea7d230 Mon Sep 17 00:00:00 2001 From: Bruno Barbieri Date: Sun, 19 May 2019 14:43:39 -0400 Subject: [PATCH 061/137] EIP-1710: URL Format for Web3 Browsers (#1710) --- EIPS/eip-1710.md | 66 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 66 insertions(+) create mode 100644 EIPS/eip-1710.md diff --git a/EIPS/eip-1710.md b/EIPS/eip-1710.md new file mode 100644 index 0000000000000..876910ae7be2d --- /dev/null +++ b/EIPS/eip-1710.md @@ -0,0 +1,66 @@ +--- +eip: 1710 +title: URL Format for Web3 Browsers +author: Bruno Barbieri (@brunobar79) +discussions-to: https://ethereum-magicians.org/t/standarize-url-format-for-web3-browsers/2422 +status: Draft +type: Standards Track +category: ERC +created: 2019-01-13 +requires: 155 +--- + + + +## Simple Summary + +A standard way of representing web3 browser URLs for decentralized applications. + +## Abstract + + +Since most normal web browsers (specifically on mobile devices) can not run decentralized applications correctly because of the lack of web3 support, it is necessary to differentiate them from normal urls, so they can be opened in web3 browsers if available. + +## Motivation + + +Lots of dApps that are trying to improve their mobile experience are currently (deep)linking to specific mobile web3 browsers which are currently using their own url scheme. + +In order to make the experience more seamless, dApps should still be able to recommend a specific mobile web3 browser via [deferred deeplinking](https://en.wikipedia.org/wiki/Deferred_deep_linking) but by having a standard url format, if the user already has a web3 browser installed that implements this standard, it will be automatically linked to it. + +There is also a compatibility problem with the current `ethereum:` url scheme described in [EIP-831](https://eips.ethereum.org/EIPS/eip-831) where any ethereum related app (wallets, identity management, etc) already registered it and because of iOS unpredictable behavior for multiple apps handling a single url scheme, users can end up opening an `ethereum:` link in an app that doesn not include a web3 browser and will not be able to handle the deeplink correctly. + +## Specification + + + +### Syntax + +Web3 browser URLs contain "dapp" in their schema (protocol) part and are constructed as follows: + + request = "dapp" ":" [chain_id "@"] dapp_url + chain_id = 1*DIGIT + dapp_url = URI + +### Semantics + +`chain_id` is optional and it is a parameter for the browser to automatically select the corresponding chain ID as specified in [EIP-155](https://eips.ethereum.org/EIPS/eip-155) before opening the dApp. + +`dapp_url` is a valid [RFC3986](https://www.ietf.org/rfc/rfc3986.txt) URI + +This a complete example url: + +`dapp:1@peepeth.com/brunobar79?utm_source=github` + +which will open the web3 browser, select `mainnet` (chain_id = 1) and then navigate to: + +`https://peepeth.com/brunobar79?utm_source=github` + +## Rationale + + +The proposed format attempts to solve the problem of vendor specific protocols for web3 browsers, avoiding conflicts with the existing 'ethereum:' URL scheme while also adding an extra feature: `chain_id` which will help dApps to be accessed with the right network preselected, optionally extracting away that complexity from end users. + +## Copyright + +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 27b24eb316939ef45de4b18dc6064b9fa9888a13 Mon Sep 17 00:00:00 2001 From: Christoph Mussenbrock Date: Mon, 20 May 2019 02:02:00 +0200 Subject: [PATCH 062/137] EIP 1523: Standard for storing insurance policies as extension of ERC-721 token (#1512) --- EIPS/eip-1523.md | 129 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 129 insertions(+) create mode 100644 EIPS/eip-1523.md diff --git a/EIPS/eip-1523.md b/EIPS/eip-1523.md new file mode 100644 index 0000000000000..31c2fef02c11b --- /dev/null +++ b/EIPS/eip-1523.md @@ -0,0 +1,129 @@ +--- +eip: 1523 +title: Standard for Insurance Policies as ERC-721 Non Fungible Tokens +author: Christoph Mussenbrock (@christoph2806) +discussions-to: https://github.com/ethereum/EIPs/issues/1523 +status: Draft +type: Standards Track +category: ERC +created: 2018-10-10 +requires: 721 +--- + +## Simple Summary + +A standard interface for insurance policies, based on ERC 721. + +## Abstract + +The following standard allows for the implementation of a standard API for insurance policies within smart contracts. +Insurance policies are financial assets which are unique in some aspects, as they are connected to a customer, a specific risk, or have other unique properties like premium, period, carrier, underwriter etc. +Nevertheless, there are many potential applications where insurance policies can be traded, transferred or otherwise treated as an asset. +The ERC 721 standard already provides the standard and technical means to handle policies as a specific class of non fungible tokens. +insurance In this proposal, we define a minimum metadata structure with properties which are common to the greatest possible class of policies. + +## Motivation + +For a decentralized insurance protocol, a standard for insurance policies is crucial for interoperability of the involved services and application. +It allows policies to be bundled, securitized, traded in a uniform and flexible way by many independent actors like syndicates, brokers, and insurance companies. + +## Specification + +The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. + +An ERC-1523 compliant insurance policy is a non-fungible token which **MUST adhere to the ERC-721 token standard** and **MUST implement theERC721Metadata and the ERC721Enumerable interface**: + +```solidity +/// @title ERC-1523 Insurance Policy Standard +/// Note: the ERC-165 identifier for this interface is 0x5a04be32 +interface ERC1523 /* is ERC721, ERC721Metadata, ERC721Enumerable */ { + +} +``` + +The implementor MAY choose values for the ```name``` and ```symbol```. + +The **policy metadata extension** is **RECOMMENDED** for ERC-1523 smart contracts. +This allows your smart contract to be interrogated for policy metadata. + +```solidity +/// @title ERC-1523 Insurance Policy Standard, optional policy metadata extension +/// @dev See ... +/// Note: the ERC-165 identifier for this interface is 0x5a04be32 +interface ERC1523PolicyMetadata /* is ERC1523 */ { + + /// @notice Metadata string for a given property. + /// Properties are identified via hash of their property path. + /// e.g. the property "name" in the ERC721 Metadata JSON Schema has the path /properties/name + /// and the property path hash is the keccak256() of this property path. + /// this allows for efficient addressing of arbitrary properties, as the set of properties is potentially unlimited. + /// @dev Throws if `_propertyPathHash` is not a valid property path hash. + function policyMetadata(uint256 _tokenId, bytes32 _propertyPathHash) external view returns (string _property); + +} +``` + +In analogy to the “ERC721 Metadata JSON Schema”, the tokenURI **MUST** point to a JSON file with the following properties: +```json +{ + "title": "Asset Metadata", + "type": "object", + "properties": { + "name": { + "type": "string", + "description": "Identifies the asset to which this NFT represents", + }, + "description": { + "type": "string", + "description": "Describes the asset to which this NFT represents", + }, + "carrier": { + "type": "string", + "description": "Describes the carrier which takes the primary risk", + }, + "risk": { + "type": "string", + "description": "Describes the risk", + }, + "parameters": { + "type": "string", + "description": "Describes further parameters characterizing the risk", + }, + "status": { + "type": "string", + "description": "Defines the status of the policy, e.g. Applied, Underwritten, Claimed, Paid out, etc." + } + } +} +``` + +## Rationale + +Insurance policies form an important class of financial assets, and it is natural to express those assets as a class of non-fungible tokens which adhere to the established ERC-721 standard. +We propose a standard for the accompanying metadata structures which are needed to uniquely define an insurance policy. +While policies can have a multitude of possible properties, it is common that policies are issued by some entity, which is basically the entity responsible for paying out claims. +Second, an insurance policy is typically related to a specific risk. Some risks are unique, but there are cases where many policies share the same risk +(e.g. all flight delay policies for the same flight). +In general, the relation of policies to risks is a many-to-one relation with the special case of a one-to-one relation. +Third, most policies need more parameters to characterize the risk and other features, like premium, period etc. +Forth, a policy has a lifecycle of different statuses. +We believe that those four properties are necessary to describe a policy. For many applications, those properties may be even sufficient. +However, any implementation **MAY** chose to implement more properties. + +### On-chain vs. off-chain metadata +For some applications it will be sufficient to store the metadata in an off-chain repository or database which can be addressed by the tokenURI resource locator. +For more advanced applications, it can be desirable to have metadata available on-chain. +Therefore, we require that the ```tokenURI``` **MUST** point to a JSON with the above structure, while the implementation of the ```policyMetadata``` function is **OPTIONAL**. + + +## Backwards Compatibility + + +## Test Cases + + +## Implementation + + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 68944626273e68b20c4f4833c08527cbc3feccf8 Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Mon, 20 May 2019 07:13:34 +0100 Subject: [PATCH 063/137] Automatically merged updates to draft EIP(s) 2028 (#2052) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-2028.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-2028.md b/EIPS/eip-2028.md index e5fbb8a28af0c..65d535b9e3628 100644 --- a/EIPS/eip-2028.md +++ b/EIPS/eip-2028.md @@ -1,7 +1,7 @@ --- eip: 2028 title: Calldata gas cost reduction -author: Alexey Akhunov(@AlexeyAkhunov), Eli Ben Sasson (eli@starkware.co), Tom Brand (tom@starkware.co), Avihu Levy (avihu@starkware.co) +author: Alexey Akhunov (@AlexeyAkhunov), Eli Ben Sasson , Tom Brand , Avihu Levy discussions-to: https://ethereum-magicians.org/t/eip-2028-calldata-gas-cost-reduction/3280 status: Draft type: Standards Track From fe44e99e273bf263b64f20ef212754b1370cdab6 Mon Sep 17 00:00:00 2001 From: Alexander Date: Mon, 20 May 2019 14:14:16 +0300 Subject: [PATCH 064/137] EC arithmetics and pairings with runtime definitions (#1962) --- EIPS/eip-1962.md | 225 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 225 insertions(+) create mode 100644 EIPS/eip-1962.md diff --git a/EIPS/eip-1962.md b/EIPS/eip-1962.md new file mode 100644 index 0000000000000..93a6937c8af9a --- /dev/null +++ b/EIPS/eip-1962.md @@ -0,0 +1,225 @@ +--- +eip: 1962 +title: EC arithmetic and pairings with runtime definitions +author: Alex Vlasov (@shamatar) +discussions-to: https://ethereum-magicians.org/t/generalised-precompile-for-elliptic-curve-arithmetics-and-pairings-working-group/3208/2 +type: Standards Track +category: Core +status: Draft +created: 2019-04-22 +requires: 1109 +--- + +# Simple summary + +This proposal is an extension and formalization of [EIP1829](https://eips.ethereum.org/EIPS/eip-1829) with an inclusion of pairings. [EIP1109](https://eips.ethereum.org/EIPS/eip-1109) is required due to low cost of some operations compared to the `STATICCALL` opcode (more information in the corresponding section below). + +## Abstract + +This EIP proposes a new precompile to bring cryptographic functionality desired for privacy and scaling solutions. Functionality of such precompile will require the following: + +- Implementation the following operations over elliptic curves in the Weierstrass form with curve parameters such as base field, A, B coefficients defined in runtime: + - Point addition + - Multiplication of a single point over a scalar + - Multiexponentiation +- Implementation pairing operation over elliptic curves from the following "families" with parameters such as base field, extension tower structure, coefficients defined in runtime: + - BLS12 + - BN + - MNT4/6 +- Implementation pairing operation over elliptic curves found by Cocks-Pinch method. Limit k <= 8. + +Full functionality of the precompile is described below in `Specification` section. + +## Motivation + +- There is a pending proposal to implement base elliptic curve arithmetic is covered by [EIP1829](https://eips.ethereum.org/EIPS/eip-1829) and will allow to implement various privacy-preserving protocols with a reasonable gas costs per operation. +- Pairings are an important extension for basic arithmetic and so this new precompile is proposed with the following benefits: + - Extended set of curves will be available to allow Ethereum users to choose their security parameters and required functionality. + - Generic approach of this precompile will allow Ethereum users to experiment with newly found curves of their choice and new constructions constructions without waiting for new forks. + - EC arithmetic is indeed re-implemented in this precompile, but it's strictly required. Most of the pairing-based protocols still need to perform standard EC multiplications or additions and thus such operations must be available on generic set of curves. +- Gas costs - this EIP is designed to estimate gas-cost of performed operation as early as possible during the call and base if solely on specified parameters and operation type. This is a strict requirement for any precompile to allow Ethereum nodes to efficiently reject transactions and operations as early as possible. + +Functionality of this newly proposed precompile is different from [EIP1829](https://eips.ethereum.org/EIPS/eip-1829) in the following aspects: +- Operation on arbitrary-length modulus (up to some upper-limit) for a base field and scalar field of the curve +- Pairing operations are introduced +- Different ABI due to variable parameter length + +## Specification + +If `block.number >= XXXXX`, define a new precompile with an address `0x..` and the following functionality. + +This specification will not yet provide concrete numbers for every operation, but will first introduce interfaces and gas calculation approaches. + +In every call to the precompile the first byte specifies an operation that should be performed: +- `0x01`: Point addition +- `0x02`: Single point multiplication +- `0x03`: Multiexponentiation +- `0x04`: Pairing + +For parameter encoding there is no dense bit packing. All the parameters (sizes, scalars, field elements, etc.) are Big Endian (BE) encoded unsigned integers. + +Points are always encoded in affine coordinates as `(x, y)`. Extension field elements are always encoded as `(c0, c1, c2, ...)` where the element itself is interpreted as `c0 + c1 * u + c2 * u^2 + ...`. + +During the execution all the parameters that should be interpreted as "points" are first checked that those are "on curve", otherwise error is thrown. + +Maximum proposed field bit size is 1023 bits. + +### Binary interface for non-pairing operations + +Every operation of such kind should specify curve parameters right after the "operation" byte: +- 1 byte that encodes byte size of the modulus for a base field. Will be referred as "field element length". +- BE encoded modulus. Field modulo this parameter is referred as the "base field". +- BE encoded parameter `A` for a curve in the Weierstrass form. May be zero but still must take the whole field element length. Must be less than modulus, no reduction should be performed by the precompile. +- BE encoded parameter `B` for a curve in the Weierstrass form. May be zero but still must take the whole field element length. Must be less than modulus, no reduction should be performed by the precompile. +- 1 byte that encodes byte size of the main group on the curve (over which arithmetic should happen). Will be referred as "scalar element length". +- BE encoded size of the main group. Will be referred as "scalar field size". + +While "scalar field size" is not used anywhere in principal operations (point additions, multiplications, multiexponentiations) do not depend on it, this parameter is required to calculate a gas cost for this operation (that's not true for point addition, but interface should be kept universal). E.g. for a naive "double and add" point multiplication approach the worst case scenario is when "add" operation is performed as many times a possible, it can be estimated as if the scalar had the same bit length as a size of the main group, but consisted of only `1` in it's bit decomposition. + +#### Point addition + +After the curve parameters (from above) two points must be specified to perform an addition. Output is a point in affine coordinates. + +#### Point multiplication + +After the curve parameters (from above) one point and one scalar must be specified to perform a multiplication. Output is a point in affine coordinates. Scalar must be less than the size of the group, otherwise error is thrown. + +#### Multiexponentiation + +After the curve parameters (from above) a list of `N` pairs `(point, scalar)` must be specified to perform a multiexponentiation. Output is a point in affine coordinates. Scalars must be less than the size of the group, otherwise error is thrown. For efficiency reasons this operations should use Peppinger algorithm with huge performance benefits. + +#### Gas calculation for non-pairing operations + +For all the operations above arithmetic is performed in a field specified by modulus. Number of operations for point addition is known beforehand, so the bit length (or byte length, more likely) of the modulus clearly must be one of the parameters. Second parameter is length of the bit (or byte) length of the scalar field. Third parameter is number of `(point, scalar)` pairs for multiexponentiation. + +Let's denote field element byte length as `fe_length`, +scalar length as `scalar_length` and number of points as `N`. Concrete coefficients that are to be determined will be labeled as `C_*`. Notation `quadratic` is to indicate a function that is quadratic over it's parameter. + +Quadratic dependency over field element byte length is due to multiplication. + +Proposed formulas: +- Point addition: `C_0*quadratic(fe_length)` +- Point multiplication: `C_1 * quadratic(fe_length) * scalar_length` +- Multiexponentiation: `C_2 * N * quadratic(fe_length) * scalar_length` + +Multiexponentiation formula is different due to use of the specialized algorithm. + +### Binary interface for pairing operations + +Pairing operations have other parameters required to estimate gas costs, so common part of the interface is different from non-pairing operations + +- 1 byte that encodes byte size of the modulus for a base field. Will be referred as "field element length". +- BE encoded modulus. Field modulo this parameter is referred as the "base field". +- BE encoded parameter `A` for a curve in the Weierstrass form. May be zero but still must take the whole field element length. Must be less than modulus, no reduction should be performed by the precompile. +- BE encoded parameter `B` for a curve in the Weierstrass form. May be zero but still must take the whole field element length. Must be less than modulus, no reduction should be performed by the precompile. +- 1 byte that encodes curve "family" + - `0x01` BLS12 + - `0x02` BN + - `0x03` MNT4 + - `0x04` MNT6 + - `0x05` Cocks-Pinch (Tate pairing) + +Parameters for a pairing are encoded as a list of `N` pairs `(p1, p2)` with `p1` being point from `G1` (curve over base field) in affine coordinates, and `p2` being point from `G2` (over the extension). + +Pairing operation consists of two major contributors: +- Miller loop. This part does depend from the number of pairs `N` and has number of steps that is specific for every curve family. For example, BLS12 family is generated by a single scalar `x` (standard notation) that determines number of steps in this loop. Any such parameters must be provided in the binary interface for gas costs estimation. +- Final exponentiation. This part does not depend from the number of pairs. Length of the loop for this operation is different for different families and can either be calculated in from other parameters or specified in the interface. In any case, gas costs can be estimated upfront. + +Below there will be proposed interface for BLS12 family of curves with other interfaces being built in a similar manner. + +#### BLS12 family pairing operation interface + +- 1 byte, length of the `x` parameter. +- BE encoding of parameter `x` (unsigned). +- 1 byte, sign of parameter `x`. `0x00` is `+`, `0x01` is `-`. +- 1 byte, specifies type of the pairing. Either `0x01` or `0x02`. This type depends of the curve and does not affect the gas cost. +- structure of the extension tower: + - non-residue for Fp2 extension in BE encoding. This is just a single element in the base field and must be less than modulus. + - non-residue for Fp6 extension (that is "3 over 2"). This is an element in Fp2 and encoded using the rules from the beginning of this EIP. +- Encoding of the "A" parameter in Fp2 for the curve over the extension (Fp2). +- Encoding of the "B" parameter in Fp2 for the curve over the extension (Fp2). + +For BLS12 family `x` parameter is enough for gas costs estimation. It's Hamming weight and bit length determines complexity of the Miller loop. Final exponentiation depends of the base field size. + +Proposed gas cost formula: `C_0 * quadratic(fe_length) + N * C_1 * fe_length * Hamming_and_bit_length(x)` + +#### Pairing operation interface for other families + +Complexity for BN family is also determined by the single scalar parameter, so interface will be similar to BLS12. For MNT4/6 and Cocks-Pinch curves there would be required to specify number of steps in the Miller loop explicitly in the interface. + +### Possible simplifications + +Due to high complexity of the proposed operations in the aspects of implementation, debugging and evaluation of the factors for gas costs it may be appropriate to either limit the set of curves at the moment of acceptance to some list and then extend it. Another approach (if it's technically possible) would be to have the "whilelist" contract that can be updated without consensus changes (w/o fork). + +In the case of limited set of curve the following set is proposed as a minimal: +- BN254 curve from the current version of Ethereum +- BN curve from DIZK with 2^32 roots of unity +- BLS12-381 +- BLS12-377 from ZEXE with large number of roots of unity +- MNT4/6 cycle from the original [paper](https://eprint.iacr.org/2014/595.pdf). It's not too secure, but may give some freedom for experiments. +- MNT4/6 cycle from Coda if performance allows +- Set of CP generated curves that would allow embedding of BLS12-377 and may be some BN curve that would have large power of two divisor for both base field and scalar field modulus (example of CP curve for BLS12-377 can be found in ZEXE). + +## Rationale + +Only the largest design decisions will be covered: +- While there is no arithmetic over the scalar field (which is modulo size of the main group) of the curve, it's required for gas estimation purposes. +- One may separate interfaces for additions, multiplications and multiexponentiations and estimate gas costs differently for every operation, but it would bring confusion for users and will make it harder to use a precompile from the smart-contract. +- Multiexponentiation is a separate operation due to large cost saving +- There are no point decompressions due to impossibility to get universal gas estimation of square root operation. For a limited number of "good" cases prices would be too different, so specifying the "worst case" is expensive and inefficient, while introduction of another level if complexity into already complicated gas costs formula is not worth is. + +### This precompile and EIP 1109 + +While there is no strict requirement of EIP 1109 for functionality, here is an example why it would be desired: +- BLS12-381 curve, 381 bit modulus, 255 bit scalar field, no native arithmetic is available in EVM for this +- Point addition would take 5000ns (quite overestimated) +- Point multiplication would take roughly 150000ns +- Crude gas schedule 15 Mgas/second from ECRecover precompile +- Point addition would cost 75 gas, with `STATICCALL` adding another 700 +- Point multiplication would cost 2250 gas +- One should also add the cost of memory allocation that is at least `1 + 1 + 48 + 48 + 48 + 1 + 32 + 2*48 + 2*48 = 371 byte` that is around 12 native Ethereum "words" and will require extra 36 gas (with negligible price for memory extension) + +Based on these quite crude estimations one can see that `STATICCALL` price will dominate the total cost (in case of addition) or bring significant overhead (in case of multiplication operation) in case of calls to this precompile. + + +## Backwards Compatibility + +This change is not backwards compatible and requires hard fork to be activated. + +Functionality of the new precompile itself does not affect any existing functionality of Ethereum or EVM. + +This precompile may serve as a complete replacement of the current set of `ECADD`, `ECMUL` and pairing check precompiles (`0x06`, `0x07`, `0x08`) + +## Test Cases +Test cases are the part of the implementation with a link below. + +## Implementation +There is an ongoing implementation effort [here](https://github.com/matter-labs/eip1829). Right now: +- Non-pairing operations are implemented and tested. +- BLS12 family is completed and tested for BLS12-381 and BLS12-377 curves. +- BN family is completed and tested with BN254 curve. +- Cocks-Pinch method curve is tested for k=6 curve from ZEXE. + +## Preliminary benchmarks + +cp6 in benchmarks is a Cocks-Pinch method curve that embeds BLS12-377. Machine: Core i7, 2.9 GHz. + +Multiexponentiation benchmarks take 100 pairs `(generator, random scalar)` as input. Due to the same "base" it may be not too representative benchmark and will be updated. + +``` +test pairings::bls12::tests::bench_bls12_381_pairing ... bench: 2,348,317 ns/iter (+/- 605,340) +test pairings::cp::tests::bench_cp6_pairing ... bench: 86,328,825 ns/iter (+/- 11,802,073) +test tests::bench_addition_bn254 ... bench: 388 ns/iter (+/- 73) +test tests::bench_doubling_bn254 ... bench: 187 ns/iter (+/- 4) +test tests::bench_field_inverse ... bench: 2,478 ns/iter (+/- 167) +test tests::bench_field_mont_inverse ... bench: 2,356 ns/iter (+/- 51) +test tests::bench_multiplication_bn254 ... bench: 81,744 ns/iter (+/- 6,984) +test tests::bench_multiplication_bn254_into_affine ... bench: 81,925 ns/iter (+/- 3,323) +test tests::bench_multiplication_bn254_into_affine_wnaf ... bench: 74,716 ns/iter (+/- 4,076) +test tests::bench_naive_multiexp_bn254 ... bench: 10,659,911 ns/iter (+/- 559,790) +test tests::bench_peppinger_bn254 ... bench: 2,678,743 ns/iter (+/- 148,914) +test tests::bench_wnaf_multiexp_bn254 ... bench: 9,161,281 ns/iter (+/- 456,137) +``` + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). \ No newline at end of file From 953135131389e86d48f83d0a24370a912458e17f Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Tue, 21 May 2019 01:19:46 +0100 Subject: [PATCH 065/137] Automatically merged updates to draft EIP(s) 663 (#2056) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-663.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/EIPS/eip-663.md b/EIPS/eip-663.md index fe42c2b768ffa..feae741cab8b9 100644 --- a/EIPS/eip-663.md +++ b/EIPS/eip-663.md @@ -47,7 +47,7 @@ This results in wasting a byte in the cases of only referring to the top 255 sta ### Option C -This option extends Option A with two new instructions, `DUPSn` and `SWAPSn`, where the value of `n` is encoded as an 8-bit immediate value following the opcode. +This option extends Option B with two new instructions, `DUPSn` (`0xb2`) and `SWAPSn` (`0xb3`), where the value of `n` is encoded as an 8-bit immediate value following the opcode. The value `n` has a range of 0 to 255, but otherwise the same rules apply as in Option A. @@ -68,6 +68,12 @@ This has no effect on backwards compatibility. TBA +## References + +A similar proposal was made with [EIP-174](https://github.com/ethereum/EIPs/issues/174). Read the thread for some detailed discussion. + +Rootstock [RSKIP26](https://github.com/rsksmart/RSKIPs/blob/master/IPs/RSKIP26.md) also introduced `SWAPN` and `DUPN` with Option A described above. + ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 6366821e0270eadca23e1c9c913dfb17329b7234 Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Tue, 21 May 2019 04:34:16 +0100 Subject: [PATCH 066/137] Mention that the header is also called "front matter" in EIP1 (#2037) --- EIPS/eip-1.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-1.md b/EIPS/eip-1.md index 6596e6999d3cf..642965c0dab5a 100644 --- a/EIPS/eip-1.md +++ b/EIPS/eip-1.md @@ -93,7 +93,7 @@ Image files should be included in a subdirectory of the `assets` folder for that ## EIP Header Preamble -Each EIP must begin with an RFC 822 style header preamble, preceded and followed by three hyphens (`---`). The headers must appear in the following order. Headers marked with "*" are optional and are described below. All other headers are required. +Each EIP must begin with an [RFC 822](https://www.ietf.org/rfc/rfc822.txt) style header preamble, preceded and followed by three hyphens (`---`). This header is also termed ["front matter" by Jekyll](https://jekyllrb.com/docs/front-matter/). The headers must appear in the following order. Headers marked with "*" are optional and are described below. All other headers are required. ` eip:` (this is determined by the EIP editor) From 2015ea379766c7cf933407b5f3d86de52bc40fea Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Tue, 21 May 2019 15:01:08 +0100 Subject: [PATCH 067/137] Add EIP-1474 as a requirement to RPC ERCs --- EIPS/eip-1102.md | 1 + EIPS/eip-1186.md | 1 + EIPS/eip-1898.md | 2 +- EIPS/eip-234.md | 1 + EIPS/eip-695.md | 1 + EIPS/eip-758.md | 1 + 6 files changed, 6 insertions(+), 1 deletion(-) diff --git a/EIPS/eip-1102.md b/EIPS/eip-1102.md index e5eaa74f28366..cd28eeef5bd1c 100644 --- a/EIPS/eip-1102.md +++ b/EIPS/eip-1102.md @@ -7,6 +7,7 @@ status: Draft type: Standards Track category: Interface created: 2018-05-04 +requires: 1474 --- ## Simple summary diff --git a/EIPS/eip-1186.md b/EIPS/eip-1186.md index 84f7442d01622..370581a08db38 100644 --- a/EIPS/eip-1186.md +++ b/EIPS/eip-1186.md @@ -7,6 +7,7 @@ status: Draft type: Standards Track category: Interface created: 2018-06-24 +requires: 1474 --- diff --git a/EIPS/eip-1898.md b/EIPS/eip-1898.md index 4968105388e80..677c7e85a6269 100644 --- a/EIPS/eip-1898.md +++ b/EIPS/eip-1898.md @@ -6,7 +6,7 @@ type: Standards Track category: Interface status: Draft created: 2019-04-01 -requires: 234 +requires: 234, 1474 --- ## Simple Summary diff --git a/EIPS/eip-234.md b/EIPS/eip-234.md index 06f99c5e59ffc..1398c161b9b6f 100644 --- a/EIPS/eip-234.md +++ b/EIPS/eip-234.md @@ -6,6 +6,7 @@ type: Standards Track category: Interface status: Draft created: 2017-03-24 +requires: 1474 --- ## Simple Summary diff --git a/EIPS/eip-695.md b/EIPS/eip-695.md index 848d5335bf33b..ddca7839fc7d9 100644 --- a/EIPS/eip-695.md +++ b/EIPS/eip-695.md @@ -6,6 +6,7 @@ type: Standards Track category: Interface status: Draft created: 2017-08-21 +requires: 1474 --- ## Simple Summary diff --git a/EIPS/eip-758.md b/EIPS/eip-758.md index 89a5bffa1be28..5cc85bb6f2a86 100644 --- a/EIPS/eip-758.md +++ b/EIPS/eip-758.md @@ -6,6 +6,7 @@ type: Standards Track category: Interface status: Draft created: 2017-11-09 +requires: 1474 --- ## Simple Summary From d4287494a1081d8a90263b0868b70ba80a1a7edf Mon Sep 17 00:00:00 2001 From: James Hancock Date: Tue, 21 May 2019 15:05:38 -0400 Subject: [PATCH 068/137] Added additional references * Ethereum Cat Herders Issue * Gitcoin Bounty link --- EIPS/eip-131.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/EIPS/eip-131.md b/EIPS/eip-131.md index 2445cdea81481..3a6147cff74d8 100644 --- a/EIPS/eip-131.md +++ b/EIPS/eip-131.md @@ -77,6 +77,8 @@ Other languages: * [Gitter Channel](https://gitter.im/EIPshepherding/eip-131) * [Original Issue](https://github.com/ethereum/EIPs/issues/152) + * [Ethereum Cat Herders Issue](https://github.com/ethereum-cat-herders/PM/issues/64) + * [Gitcoin Bounty](https://gitcoin.co/issue/ethereum-cat-herders/PM/64/2955) ## Copyright From 7c10d583d9cf21be0e2bf34e59a2ae4ecd1ca615 Mon Sep 17 00:00:00 2001 From: Agustin Aguilar Date: Wed, 22 May 2019 03:31:19 +0200 Subject: [PATCH 069/137] Fix Wrong Input Length - ERC165 Example (#1640) * Wrong input size - noThrowCall ERC165 Input should be 36 bytes (4 signature bytes + 32 bytes parameter) Solidity 5 validates the length of msg.data, reverting on the 32 bytes input, all contracts using the broken 'doesContractImplementInterface' will not be able to read an ERC165 implementation targetting Solidity 5. A legacy-compatible strategy should be defined to make all the "ERC165 readers" sending a 32 bytes sized data compatible with ERC165 contracts compiled targeting this new version of the compiler. A possible solution could be to add a keyword on Solidity to disable the validation of the calldata length. * Add version history section to EIP165 * EIP 1640 -> PR 1640 --- EIPS/eip-165.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/EIPS/eip-165.md b/EIPS/eip-165.md index e71e96e02a462..b930acbcc045d 100644 --- a/EIPS/eip-165.md +++ b/EIPS/eip-165.md @@ -151,7 +151,7 @@ contract ERC165Query { 30000, // 30k gas _contract, // To addr x, // Inputs are stored at location x - 0x20, // Inputs are 32 bytes long + 0x24, // Inputs are 36 bytes long x, // Store output over input (saves space) 0x20) // Outputs are 32 bytes long @@ -225,6 +225,11 @@ contract Homer is ERC165, Simpson { With three or more supported interfaces (including ERC165 itself as a required supported interface), the mapping approach (in every case) costs less gas than the pure approach (at worst case). +## Version history +* PR 1640, finalized 2019-01-23 -- This corrects the noThrowCall test case to use 36 bytes rather than the previous 32 bytes. The previous code was an error that still silently worked in Solidity 0.4.x but which was broken by new behavior introduced in Solidity 0.5.0. This change was discussed at [#1640](https://github.com/ethereum/EIPs/pull/1640). + +* EIP 165, finalized 2018-04-20 -- Original published version. + ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 36d29921abd7b366dc1d9dd39b97283f1a4a154b Mon Sep 17 00:00:00 2001 From: Andrew Cooke Date: Wed, 22 May 2019 19:13:16 -0400 Subject: [PATCH 070/137] Automatically merged updates to draft EIP(s) 1155 (#2063) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-1155.md | 24 +++++++++++++----------- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/EIPS/eip-1155.md b/EIPS/eip-1155.md index bfd1539c98bc6..05b4e768056c8 100644 --- a/EIPS/eip-1155.md +++ b/EIPS/eip-1155.md @@ -17,7 +17,7 @@ A standard interface for contracts that manage multiple token types. A single de ## Abstract -This standard outlines a smart contract interface that can represent any number of Fungible and Non-Fungible token types. Existing standards such as ERC-20 require deployment of separate contracts per token type. The ERC-721 standard's Token ID is a single non-fungible index and the group of these non-fungibles is deployed as a single contract with settings for the entire collection. In contrast, the ERC-1155 Multi Token Standard allows for each Token ID to represent a new configurable token type, which may have its own metadata, supply and other attributes. +This standard outlines a smart contract interface that can represent any number of Fungible and Non-Fungible token types. Existing standards such as ERC-20 require deployment of separate contracts per token type. The ERC-721 standard's token ID is a single non-fungible index and the group of these non-fungibles is deployed as a single contract with settings for the entire collection. In contrast, the ERC-1155 Multi Token Standard allows for each token ID to represent a new configurable token type, which may have its own metadata, supply and other attributes. The `_id` argument contained in each function's argument set indicates a specific token or token type in a transaction. @@ -115,8 +115,8 @@ interface ERC1155 /* is ERC165 */ { /** @notice Get the balance of an account's Tokens. @param _owner The address of the token holder - @param _id ID of the Token - @return The _owner's balance of the Token type requested + @param _id ID of the token + @return The _owner's balance of the token type requested */ function balanceOf(address _owner, uint256 _id) external view returns (uint256); @@ -124,7 +124,7 @@ interface ERC1155 /* is ERC165 */ { @notice Get the balance of multiple account/token pairs @param _owners The addresses of the token holders @param _ids ID of the Tokens - @return The _owner's balance of the Token types requested (i.e. balance for each (owner, id) pair) + @return The _owner's balance of the token types requested (i.e. balance for each (owner, id) pair) */ function balanceOfBatch(address[] calldata _owners, uint256[] calldata _ids) external view returns (uint256[] memory); @@ -165,7 +165,7 @@ interface ERC1155TokenReceiver { Return of any other value than the prescribed keccak256 generated value MUST result in the transaction being reverted by the caller. @param _operator The address which initiated the transfer (i.e. msg.sender) @param _from The address which previously owned the token - @param _id The id of the token being transferred + @param _id The ID of the token being transferred @param _value The amount of tokens being transferred @param _data Additional data with no specified format @return `bytes4(keccak256("accept_erc1155_tokens()"))` @@ -253,6 +253,7 @@ To be more explicit about how safeTransferFrom and safeBatchTransferFrom MUST op * MUST revert on any other error. * MUST emit the `TransferSingle` event to reflect the balance change (see "TransferSingle and TransferBatch event rules" section). * After the above conditions are met, this function MUST check if `_to` is a smart contract (e.g. code size > 0). If so, it MUST call `onERC1155Received` on `_to` and act appropriately (see "onERC1155Received rules" section). + - The `_data` argument provided by the sender for the transfer MUST be passed with its contents unaltered to the `onERC1155Received` hook function via its `_data` argument. **_safeBatchTransferFrom rules:_** * Caller must be approved to manage all the tokens being transferred out of the `_from` account (see "Approval" section). @@ -263,6 +264,7 @@ To be more explicit about how safeTransferFrom and safeBatchTransferFrom MUST op * MUST emit `TransferSingle` or `TransferBatch` event(s) such that all the balance changes are reflected (see "TransferSingle and TransferBatch event rules" section). * The balance changes and events MUST occur in the array order they were submitted (_ids[0]/_values[0] before _ids[1]/_values[1], etc). * After the above conditions are met, this function MUST check if `_to` is a smart contract (e.g. code size > 0). If so, it MUST call `onERC1155Received` or `onERC1155BatchReceived` on `_to` and act appropriately (see "`onERC1155Received` and onERC1155BatchReceived rules" section). + - The `_data` argument provided by the sender for the transfer MUST be passed with its contents unaltered to the `ERC1155TokenReceiver` hook function(s) via their `_data` argument. **_TransferSingle and TransferBatch event rules:_** * `TransferSingle` SHOULD be used to indicate a single balance transfer has occurred between a `_from` and `_to` pair. @@ -295,7 +297,7 @@ To be more explicit about how safeTransferFrom and safeBatchTransferFrom MUST op - `_from` MUST be 0x0 for a mint. * The `_id` argument MUST be the token type being transferred. * The `_value` argument MUST be the number of tokens the holder balance is decreased by and match what the recipient balance is increased by. -* The `_data` argument MUST contain the unaltered information provided by the sender for the transfer. +* The `_data` argument MUST contain the information provided by the sender for the transfer with its contents unaltered. - i.e. it MUST pass on the unaltered `_data` argument sent via the `safeTransferFrom` or `safeBatchTransferFrom` call for this transfer. * The recipient contract MAY accept an increase of its balance by returning the acceptance magic value `bytes4(keccak256("accept_erc1155_tokens()"))` - If the return value is `bytes4(keccak256("accept_erc1155_tokens()"))` the transfer MUST be completed or MUST revert if any other conditions are not met for success. @@ -312,8 +314,8 @@ To be more explicit about how safeTransferFrom and safeBatchTransferFrom MUST op - `_from` MUST be 0x0 for a mint. * The `_ids` argument MUST be the list of tokens being transferred. * The `_values` argument MUST be the list of number of tokens (matching the list and order of tokens specified in `_ids`) the holder balance is decreased by and match what the recipient balance is increased by. -* The `_data` argument MUST contain the unaltered information provided by the sender for the transfer. - - i.e. it MUST pass on the unaltered `_data` argument sent via the `safeTransferFrom` or `safeBatchTransferFrom` call for this transfer. +* The `_data` argument MUST contain the information provided by the sender for the transfer with its contents unaltered. + - i.e. it MUST pass on the unaltered `_data` argument sent via the `safeBatchTransferFrom` call for this transfer. * The recipient contract MAY accept an increase of its balance by returning the acceptance magic value `bytes4(keccak256("accept_batch_erc1155_tokens()"))` - If the return value is `bytes4(keccak256("accept_batch_erc1155_tokens()"))` the transfer MUST be completed or MUST revert if any other conditions are not met for success. * The recipient contract MAY reject an increase of its balance by calling revert. @@ -538,7 +540,7 @@ fr.json: ### Approval The function `setApprovalForAll` allows an operator to manage one's entire set of tokens on behalf of the approver. To permit approval of a subset of token IDs, an interface such as [ERC-1761 Scoped Approval Interface](https://eips.ethereum.org/EIPS/eip-1761) is suggested. -The counterpart `isAprrovedForAll` provides introspection into status set by `setApprovalForAll`. +The counterpart `isApprovedForAll` provides introspection into status set by `setApprovalForAll`. An owner SHOULD be assumed to always be able to operate on their own tokens regardless of approval status, so should SHOULD NOT have to call `setApprovalForAll` to approve themselves as an operator before they can operate on them. @@ -570,7 +572,7 @@ As the Ethereum ecosystem continues to grow, many dapps are relying on tradition The function `setApprovalForAll` allows an operator to manage one's entire set of tokens on behalf of the approver. It enables frictionless interaction with exchange and trade contracts. -Restricting approval to a certain set of Token IDs, quantities or other rules MAY be done with an additional interface or an external contract. The rationale is to keep the ERC-1155 standard as generic as possible for all use-cases without imposing a specific approval scheme on implementations that may not need it. Standard token approval interfaces can be used, such as the suggested [ERC-1761 Scoped Approval Interface](https://github.com/ethereum/EIPs/issues/1761) which is compatible with ERC-1155. +Restricting approval to a certain set of token IDs, quantities or other rules MAY be done with an additional interface or an external contract. The rationale is to keep the ERC-1155 standard as generic as possible for all use-cases without imposing a specific approval scheme on implementations that may not need it. Standard token approval interfaces can be used, such as the suggested [ERC-1761 Scoped Approval Interface](https://github.com/ethereum/EIPs/issues/1761) which is compatible with ERC-1155. ## Usage @@ -588,7 +590,7 @@ The `balanceOfBatch` function allows clients to retrieve balances of multiple ow ### Enumerating from events -In order to keep storage requirements light for contracts implementing ERC-1155, enumeration (discovering the IDs and values of tokens) must be done using event logs. It is RECOMMENDED that clients such as exchanges and blockchain explorers maintain a local database containing the Token ID, Supply, and URI at the minimum. This can be built from each TransferSingle, TransferBatch, and URI event, starting from the block the smart contract was deployed until the latest block. +In order to keep storage requirements light for contracts implementing ERC-1155, enumeration (discovering the IDs and values of tokens) must be done using event logs. It is RECOMMENDED that clients such as exchanges and blockchain explorers maintain a local database containing the token ID, Supply, and URI at the minimum. This can be built from each TransferSingle, TransferBatch, and URI event, starting from the block the smart contract was deployed until the latest block. ERC-1155 contracts must therefore carefully emit `TransferSingle` or `TransferBatch` events in any instance where tokens are created, minted, or destroyed. From 0755e0c581804a6f526eeb0f2989d274c0c7f198 Mon Sep 17 00:00:00 2001 From: Andrew Cooke Date: Wed, 22 May 2019 20:32:28 -0400 Subject: [PATCH 071/137] Automatically merged updates to draft EIP(s) 1155 (#2064) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-1155.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-1155.md b/EIPS/eip-1155.md index 05b4e768056c8..7dccdcdc2ae49 100644 --- a/EIPS/eip-1155.md +++ b/EIPS/eip-1155.md @@ -263,7 +263,7 @@ To be more explicit about how safeTransferFrom and safeBatchTransferFrom MUST op * MUST revert on any other error. * MUST emit `TransferSingle` or `TransferBatch` event(s) such that all the balance changes are reflected (see "TransferSingle and TransferBatch event rules" section). * The balance changes and events MUST occur in the array order they were submitted (_ids[0]/_values[0] before _ids[1]/_values[1], etc). -* After the above conditions are met, this function MUST check if `_to` is a smart contract (e.g. code size > 0). If so, it MUST call `onERC1155Received` or `onERC1155BatchReceived` on `_to` and act appropriately (see "`onERC1155Received` and onERC1155BatchReceived rules" section). +* After the above conditions are met, this function MUST check if `_to` is a smart contract (e.g. code size > 0). If so, it MUST call `onERC1155Received` or `onERC1155BatchReceived` on `_to` and act appropriately (see "onERC1155Received and onERC1155BatchReceived rules" section). - The `_data` argument provided by the sender for the transfer MUST be passed with its contents unaltered to the `ERC1155TokenReceiver` hook function(s) via their `_data` argument. **_TransferSingle and TransferBatch event rules:_** From f417718abdf63424f1517165db3e433345c5bb96 Mon Sep 17 00:00:00 2001 From: ledgerwatch Date: Thu, 23 May 2019 11:06:53 +0100 Subject: [PATCH 072/137] State Rent change H placeholder EIP - fixed rent prepayment for all accounts (#2026) --- EIPS/eip-2026.md | 71 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 71 insertions(+) create mode 100644 EIPS/eip-2026.md diff --git a/EIPS/eip-2026.md b/EIPS/eip-2026.md new file mode 100644 index 0000000000000..376c8c8da5795 --- /dev/null +++ b/EIPS/eip-2026.md @@ -0,0 +1,71 @@ +--- +eip: 2026 +title: State Rent H - Fixed Prepayment for accounts +author: Alexey Akhunov (@AlexeyAkhunov) +discussions-to: https://ethereum-magicians.org/t/eip-2026-fixed-rent-prepayment-for-all-accounts-change-h-from-state-rent-v3-proposal/3273 +status: Draft +type: Standards Track +category: Core +created: 2019-05-14 +--- + + + +## Simple Summary + +Creation of new accounts (both contracts and non-contracts) requires a fixed one-off rent prepayment. Pre-existed accounts require the same prepayment upon +the first modification. The act of rent prepayment causes the addition of an extra field to accounts, called `rentbalance`. This field becomes part of state. + +## Abstract + +This is part of the State Rent roadmap. This particular change introduces a fixed charge for state expansion that comes from adding new accounts to the state. Theoretically, it puts a bound on the number of accounts that can be ever created, because that fixed charge cannot be recycled via mining. + +## Motivation + +The penalty is levied to the transaction sender. Rather than raising the gas cost of account creation (that would direct levy towards the miner), this change directs prepayment into the account's special field, `rentbalance`. It addresses several shortcomings of the simple raising of the gas cost: +1. Prepayments cannot be recycled via mining, which puts a theoretical bound on number of accounts in the state (though it is unlikely to ever be reached). +2. It is not possible for miners to circumvent the penalty or to extend such circumventions onto other users (via private fee rebates, for example). +3. This prepayment will be used to cover state rent in the future, and it will allow newly created contracts with 0 endowment not to be evicted in the same block. +4. It makes is possible to refund `rentbalance` upon self-destruction - when contract is self-destructed, both `balance` and `rentbalance` are returned. +5. Prepayments on pre-existing accounts are necessary to prevent hoarding of accounts ahead of this change. + +## Specification + +On and after block `H`, every newly created account gets a new field `rentbalance` of type unsigned 256-bit integer. +On and after block `H`, any operation that leads to the creation of a new account, deducts the amount `ACCOUNT_PREPAYMENT` from `tx.origin`. This amount is added to the `rentbalance` field of the created account. +On and after block `H`, any operation that modifies an account that does not yet have `rentbalance` field, deducts the amount `ACCOUNT_PREPAYEMENT` from `tx.origin`. This amount is added to the `rentbalance` field of the modified account. This is a anti-hoarding measure. + +Operations leading to the creations of a new account: +1. Creation of a non-contract account by sending non-zero ETH to an address with no associated account +2. Creation of a non-contract account by the block with `coinbase` pointing to an address with no associated account +3. Creation of a non-contract account by `SELFDESTRUCT` with the argument being an address with no associated account +4. Creation of a contract by transaction without destination but with data. This can result in either converting a non-countract account into a contract account, or creation of a contract account. +5. Creation of a contract by execution of `CREATE` or `CREATE2`. This can result in either converting a non-countract account into a contract account, or creation of a contract account. + +After prepayments are introduced, there can be two reasons for ether to be deducted from `tx.origin`: purchasing and spending gas, and spending gas for prepayments. Gaslimit of a transaction currently plays a role of safety limit, where `gaslimit` * `gasprice` represents the maximum amount of wei the sender (`tx.origin`) authorises the transaction to deduct from its account. +After prepayments are introduced, `gaslimit` * `gasprice` will still represent the maximum amount of wei spend, but it will be used for both gas purchases and prepayments, as necessary. + +## Rationale + +Prior to rent prepayments, other alternatives were considered: +1. Simple raising of the gas cost - discussed in the Motivation section. +1. In [first version of State Rent proposal](https://github.com/ledgerwatch/eth_state/blob/master/State_rent.pdf), there was no notion of extra levy upon account creation. It created a slight usability issue, where newly created contracts with 0 endowment would be evicted in the same block (when rent is introduced). It delays the benefits of the State Rent programme until the actual introduction of rent (in second or third hard-fork). +2. In the [second version of State Rent proposal](https://github.com/ledgerwatch/eth_state/blob/master/State_Rent_2.pdf), there was a notion of lock-up. It is very similar to rent prepayment, with the different that lock-up would not be covering future rent payments. + +An alternative approach to limiting the prepayments (instead of the using `gaslimit` * `gasprice` as the limit) is to introduce a new dedicated field `prepaymenlimit` into the transaction. This field would only limit prepayments). Such approach would require changes in the transaction format, as well as changes in the user interface for transaction sender, and having two counters during the transaction execution - one for gas, and one for prepayments. + +## Backwards Compatibility + +This change is not backwards compatible and requires hard fork to be activated. +It might have some adverse effects on the existing contracts, due to more gas needed to be allocated for the creation of new accounts. These adverse effects need to analysed in more detail. + +## Test Cases + +Tests cases will be generated out of a reference implementation. + +## Implementation + +There will be proof of concept implementation to refine and clarify the specification. + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From d6dfa555be623ff71f1f4b205aba8ffa2bc278dd Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Thu, 23 May 2019 21:23:03 +0100 Subject: [PATCH 073/137] Fix author fields (#2065) --- EIPS/eip-100.md | 2 +- EIPS/eip-1077.md | 2 +- EIPS/eip-145.md | 2 +- EIPS/eip-1485.md | 2 +- EIPS/eip-150.md | 2 +- EIPS/eip-155.md | 2 +- EIPS/eip-160.md | 2 +- EIPS/eip-170.md | 2 +- EIPS/eip-4.md | 2 +- EIPS/eip-779.md | 2 +- EIPS/eip-86.md | 2 +- 11 files changed, 11 insertions(+), 11 deletions(-) diff --git a/EIPS/eip-100.md b/EIPS/eip-100.md index f1ded40d3d19f..78b94002190eb 100644 --- a/EIPS/eip-100.md +++ b/EIPS/eip-100.md @@ -1,7 +1,7 @@ --- eip: 100 title: Change difficulty adjustment to target mean block time including uncles -author: Vitalik Buterin +author: Vitalik Buterin (@vbuterin) type: Standards Track category: Core status: Final diff --git a/EIPS/eip-1077.md b/EIPS/eip-1077.md index 4e7e08fdd36c2..bd509879b5473 100644 --- a/EIPS/eip-1077.md +++ b/EIPS/eip-1077.md @@ -1,7 +1,7 @@ --- eip: 1077 title: Executable Signed Messages refunded by the contract -author: Alex Van de Sande , Ricardo Guilherme Schmidt +author: Alex Van de Sande , Ricardo Guilherme Schmidt (@3esmit) discussions-to: https://ethereum-magicians.org/t/erc1077-and-1078-the-magic-of-executable-signed-messages-to-login-and-do-actions/351 status: Draft type: Standards Track diff --git a/EIPS/eip-145.md b/EIPS/eip-145.md index d0b38cf76c7cd..55ae9c39cebce 100644 --- a/EIPS/eip-145.md +++ b/EIPS/eip-145.md @@ -1,7 +1,7 @@ --- eip: 145 title: Bitwise shifting instructions in EVM -author: Alex Beregszaszi (@axic), Paweł Bylica +author: Alex Beregszaszi (@axic), Paweł Bylica (@chfast) type: Standards Track category: Core status: Final diff --git a/EIPS/eip-1485.md b/EIPS/eip-1485.md index 12040c4afdb76..9dbdbcb3ef811 100644 --- a/EIPS/eip-1485.md +++ b/EIPS/eip-1485.md @@ -1,7 +1,7 @@ --- eip: 1485 title: TEthashV1 -author: trustfarm (KT Ahn - 안씨아저씨) , , +author: trustfarm (KT Ahn - 안씨아저씨) , trustfarm discussions-to: https://ethereum-magicians.org/t/anti-eth-asic-mining-eip-1488-pr/1807 status: Draft type: Standards Track diff --git a/EIPS/eip-150.md b/EIPS/eip-150.md index 709ffaecdca59..c9bef1ed15210 100644 --- a/EIPS/eip-150.md +++ b/EIPS/eip-150.md @@ -1,7 +1,7 @@ --- eip: 150 title: Gas cost changes for IO-heavy operations -author: Vitalik Buterin +author: Vitalik Buterin (@vbuterin) type: Standards Track category: Core status: Final diff --git a/EIPS/eip-155.md b/EIPS/eip-155.md index 52324ad10820a..11efe541c5dc3 100644 --- a/EIPS/eip-155.md +++ b/EIPS/eip-155.md @@ -1,7 +1,7 @@ --- eip: 155 title: Simple replay attack protection -author: Vitalik Buterin +author: Vitalik Buterin (@vbuterin) type: Standards Track category: Core status: Final diff --git a/EIPS/eip-160.md b/EIPS/eip-160.md index 4749d89f45985..21a12dfef18bb 100644 --- a/EIPS/eip-160.md +++ b/EIPS/eip-160.md @@ -1,7 +1,7 @@ --- eip: 160 title: EXP cost increase -author: Vitalik Buterin +author: Vitalik Buterin (@vbuterin) type: Standards Track category: Core status: Final diff --git a/EIPS/eip-170.md b/EIPS/eip-170.md index 5fd1b3d99397f..4f96551984122 100644 --- a/EIPS/eip-170.md +++ b/EIPS/eip-170.md @@ -1,7 +1,7 @@ --- eip: 170 title: Contract code size limit -author: Vitalik Buterin +author: Vitalik Buterin (@vbuterin) type: Standards Track category: Core status: Final diff --git a/EIPS/eip-4.md b/EIPS/eip-4.md index 666436bc8caba..ad647ac5206be 100644 --- a/EIPS/eip-4.md +++ b/EIPS/eip-4.md @@ -1,7 +1,7 @@ --- eip: 4 title: EIP Classification -author: Joseph Chow +author: Joseph Chow (@ethers) status: Draft type: Meta created: 2015-11-17 diff --git a/EIPS/eip-779.md b/EIPS/eip-779.md index 4d18547193791..1d658b0854779 100644 --- a/EIPS/eip-779.md +++ b/EIPS/eip-779.md @@ -1,7 +1,7 @@ --- eip: 779 title: "Hardfork Meta: DAO Fork" -author: Casey Detrio +author: Casey Detrio (@cdetrio) type: Meta status: Final created: 2017-11-26 diff --git a/EIPS/eip-86.md b/EIPS/eip-86.md index 6b9494b9ecd8c..a76ccbc33464a 100644 --- a/EIPS/eip-86.md +++ b/EIPS/eip-86.md @@ -1,7 +1,7 @@ --- eip: 86 title: Abstraction of transaction origin and signature -author: Vitalik Buterin +author: Vitalik Buterin (@vbuterin) type: Standards Track category: Core status: Draft From ae595911ae1ff95484ea9af20a5e4280b0a1e150 Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Thu, 23 May 2019 22:09:45 +0100 Subject: [PATCH 074/137] Sane limits for certain EVM parameters (#1985) * sane * some clarifications * remove cruft * some clarifications * propose spec changes * limit the scope to EVM only * more rationale * group affected opcodes by ranges * Rename to EIP-1985 * Add discussion URL to EIP-1985 * Include a reference to EIP106 * Add more rationale * fix typo * Remove unfounded worry * mention timestamp being 64-bit value in Aleth * resolved an TODO item as Rationale entry --- EIPS/eip-1985.md | 121 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 121 insertions(+) create mode 100644 EIPS/eip-1985.md diff --git a/EIPS/eip-1985.md b/EIPS/eip-1985.md new file mode 100644 index 0000000000000..8f3eca24a883b --- /dev/null +++ b/EIPS/eip-1985.md @@ -0,0 +1,121 @@ +--- +eip: 1985 +title: Sane limits for certain EVM parameters +author: Alex Beregszaszi (@axic), Paweł Bylica (@chfast) +discussions-to: https://ethereum-magicians.org/t/eip-1985-sane-limits-for-certain-evm-parameters/3224 +status: Draft +type: Standards Track +category: Core +created: 2018-08-01 +--- + +## Abstract + +Introduce an explicit value range for certain EVM parameters +(such as gas limit, block number, block timestamp, size field when returning/copying data within EVM). +Some of these already have an implicit value range due to various (practical) reasons. + +## Motivation + +Having such an explicit value range can help in creating compatible client implementations, +in certain cases it can also offer minor speed improvements, +and can reduce the effort needed to create consensus critical test cases +by eliminating unrealistic edge cases. + +## Specification + +If `block.number >= {FORK_BLOCK}`, the following value ranges are introduced. +They restrict the results (i.e. values pushed to the stack) of the opcodes listed below. + +1. *gas*, *gas limit*, *block gas limit* + is a range between `0` and `9223372036854775807` (`2**63 - 1`). + It affects following the opcodes: + - `GASLIMIT` (`0x45`), + - `GAS` (`0x5a`). + +2. *block number*, *timestamp* + is a range between `0` and `9223372036854775807` (`2**63 - 1`). + It affects the following opcodes: + - `TIMESTAMP` (`0x42`), + - `NUMBER` (`0x43`). + +3. *account address* + is a range between `0` and `1461501637330902918203684832716283019655932542975` (`2**160 - 1`). + It affects the following opcodes: + - `ADDRESS` (`0x30`), + - `ORIGIN` (`0x32`), + - `CALLER` (`0x33`), + - `COINBASE` (`0x41`), + - `CREATE` (`0xf0`), + - `CREATE2` (`0xf5`). + +4. *buffer size* + is a range between `0` and `4294967295` (`2**32 - 1`). + It affects the following opcodes: + - `CALLDATASIZE` (`0x36`), + - `CODESIZE` (`0x38`), + - `EXTCODESIZE` (`0x3b`), + - `RETURNDATASIZE` (`0x3d`), + - `MSIZE` (`0x59`). + + +## Rationale + +These limits have been: +- proposed by [EVMC] +- implemented partially by certain clients, such as [Aleth], [geth], [Parity] and [ethereumjs] +- allowed by certain test cases in the [Ethereum testing suite] +- and implicitly also allowed by certain assumptions, such as due to gas limits some of these values cannot grow past a certain limit + +Most of the limits proposed in this document have been previously explored and tested in [EVMC]. + +Using the `2**63 - 1` constant to limit some of the ranges: +- allows using signed 64-bit integer type to represent it, + what helps programming languages not having unsigned types, +- makes arithmetic simpler (e.g. checking out-of-gas conditions is simple as `gas_counter < 0`). + +### Timestamp + +The [Yellow Paper] defines the timestamp in block as "A scalar value equal to the reasonable output of Unix’s time() at this block’s inception". +IEEE Std 1003.1-2001 (POSIX.1) leaves that definition implementation defined. + +### Addresses + +The size of addresses is specified in the [Yellow Paper] as 20 bytes. +E.g. the `COINBASE` instruction is specified to return *H*c ∈ 𝔹20 which has 20 bytes. + +### Comparing current implementations + +- Timestamp is implemented as a 64-bit value in [Aleth], [geth] and [Parity] +- Block gas limit is implemented as a 64-bit in [Aleth] and [geth] + +## Backwards Compatibility + +All of these limits are already enforced mostly through the block gas limit. Since the out of range case results in a transaction failure, there should not be a change in behaviour. + +## Test Cases + +TBA + +## Implementation + +TBA + +## References + +[EIP-106](https://github.com/ethereum/EIPs/issues/106) proposed the block gas limit to be limited at `2**63 - 1`. + +## TODO + +1. Does the gas limit apply to the gas argument for call instructions? + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). + +[EVMC]: https://github.com/ethereum/evmc +[Aleth]: https://github.com/ethereum/aleth +[geth]: https://github.com/ethereum/go-ethereum +[Parity]: https://github.com/paritytech/parity-ethereum +[ethereumjs]: https://github.com/ethereumjs +[Ethereum testing suite]: https://github.com/ethereum/tests +[Yellow Paper]: https://github.com/ethereum/yellowpaper From f993edd933804131d14de17014e02005c03271f1 Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Thu, 23 May 2019 22:13:26 +0100 Subject: [PATCH 075/137] Reduced gas cost for static calls made to precompiles (#2046) * Reduced gas cost for static calls made to precompiles * Rename to EIP-2046 * Add discussion URL * Add 2046 to Istanbul * Fix header --- EIPS/eip-1679.md | 1 + EIPS/eip-2046.md | 69 ++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 70 insertions(+) create mode 100644 EIPS/eip-2046.md diff --git a/EIPS/eip-1679.md b/EIPS/eip-1679.md index 6c6d2187f8214..7b29f74b76aed 100644 --- a/EIPS/eip-1679.md +++ b/EIPS/eip-1679.md @@ -49,6 +49,7 @@ This meta-EIP specifies the changes included in the Ethereum hardfork named Ista - [EIP-1884](https://eips.ethereum.org/EIPS/eip-1884): Repricing for trie-size-dependent opcodes - [EIP-1930](https://eips.ethereum.org/EIPS/eip-1930): CALLs with strict gas semantic. Revert if not enough gas available. - [EIP-2028](https://eips.ethereum.org/EIPS/eip-2028): Calldata gas cost reduction +- [EIP-2046](https://eips.ethereum.org/EIPS/eip-2046): Reduced gas cost for static calls made to precompiles ## Timeline diff --git a/EIPS/eip-2046.md b/EIPS/eip-2046.md new file mode 100644 index 0000000000000..ca35c7eefe8e8 --- /dev/null +++ b/EIPS/eip-2046.md @@ -0,0 +1,69 @@ +--- +eip: 2046 +title: Reduced gas cost for static calls made to precompiles +author: Alex Beregszaszi (@axic) +discussions-to: https://ethereum-magicians.org/t/eip-2046-reduced-gas-cost-for-static-calls-made-to-precompiles/3291 +status: Draft +type: Standards Track +category: Core +created: 2019-05-17 +requires: 214, 1352 +--- + +## Simple Summary + +This change reduces the gas cost of using precompiled contracts. + +## Abstract + +Reduce the base gas cost of calling precompiles using `STATICCALL` from 700 to 40. This should allow more efficient use of precompiles as well as precompiles with a total cost below 700. + +## Motivation + +The Spurious Dragon hard fork increased the cost of calls significantly to account for loading contract code from the state without making an exception for precompiles, whose "code" is always loaded. + +This made use of certain precompiles impractical. + +FIXME: extend this with recent reasoning about ECC repricings. + +## Specification + +After block `HF` the `STATICCALL` (`0xfa`) instruction charges different basic gas cost (Gcall in [Yellow Paper]'s notation) depending on the destination address provided: +- for precompiles (address range as per [EIP-1352]) the cost is `40` +- for every other address the cost remains unchanged (`700`) + +## Rationale + +Only the `STATICCALL` instruction was changed to reduce the impact of the change. This should not be a limiting factor, given precompiles (currently) do not have a state and cannot change the state. +However, contracts created and deployed before Byzantium likely will not use `STATICCALL` and as a result this change will not reduce their costs. + +Contrary to EIP-1109 gas reduction to `0` is not proposed. The cost `40` is kept as a cost representing the context switching needed. + +## Backwards Compatibility + +This EIP should be backwards compatible. The only effect is that the cost is reduced. Since the cost is not reduced to zero, it should not be possible for a malicious proxy contract, when deployed before +the `HF`, to do any state changing operation. + +## Test Cases + +TBA + +## Implementation + +TBA + +## References + +This has been previously suggested as part of [EIP-1109](https://github.com/ethereum/EIPs/pull/1109) and [EIP-1231](https://github.com/ethereum/EIPs/pull/1231). +However EIP-1109 was later changed to a very different approach. The author [has suggested to change EIP-1109](https://ethereum-magicians.org/t/eip-1109-remove-call-costs-for-precompiled-contracts/447/7). + +## Acknowledgements + +Jordi Baylina (@jbaylina) and Matthew Di Ferrante (@mattdf) who have proposed this before. + +## Copyright + +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). + +[Yellow Paper]: https://github.com/ethereum/yellowpaper +[EIP-1352]: https://eips.ethereum.org/EIPS/eip-1352 From d2aa4aeb21208a0d18c35f4c2ad6d670f78c2764 Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Thu, 23 May 2019 22:15:26 +0100 Subject: [PATCH 076/137] Add draft for ESO (extended state oracle) (#2014) * Add draft for ESO (extended state oracle) * Add mention of revert to ESO * Add EIP-2014 number and rename file * Add reference to EIP-1959 and EIP-1965 * Add discussions-to URL --- EIPS/eip-2014.md | 94 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 94 insertions(+) create mode 100644 EIPS/eip-2014.md diff --git a/EIPS/eip-2014.md b/EIPS/eip-2014.md new file mode 100644 index 0000000000000..95c88d908f0e8 --- /dev/null +++ b/EIPS/eip-2014.md @@ -0,0 +1,94 @@ +--- +eip: 2014 +title: Extended State Oracle +author: Alex Beregszaszi (@axic) +discussions-to: https://ethereum-magicians.org/t/eip-2014-extended-state-oracle/3301 +status: Draft +type: Standards Track +category: Core +created: 2019-05-10 +requires: 140 +--- + +## Simple Summary + + +## Abstract + +Introduce a new system contract with an extensible interface following the [Contract ABI Encoding] to access extended data sets, such as chain identifiers, block hashes, etc. + +This allows Ethereum contract languages to interact with this contract as if it were a regular contract and not needing any language support. + +## Motivation + +Over the past couple of years several proposals were made to extend the EVM with more data. Some examples include extended access to block hashes ([EIP-210]) and chain identifiers ([EIP-1344]). + +Adding them as EVM opcodes seems to be using the scarce opcode space for relatively less frequently used features, while adding them as precompiles is perceived as more complicated due to an interface +needs to be defined and agreed on for every case. + +This proposal tries to solve both issues with defining an extensible standard interface. + +## Specification + +A new system contract ("precompile") is introduced at address `0x0000000000000000000000000000000000000009` called ESO (Extended State Oracle). + +It can be queried using `CALL` or `STATICCALL` and follows the [Contract ABI Encoding] for the inputs and outputs. Using elementary types in the ABI encoding is encouraged to keep complexity low. + +In the future it could be possible to extend ESO to have a state and accept transactions from a system address to store the passed data -- similarly to what [EIP-210] proposed. + +Proposals wanting to introduce more data to the state, which is not part of blocks or transactions, should aim to extend the ESO. + +At this time it is not proposed to make the ESO into a contract existing in the state, but to include it as a precompile and leave the implementation details to the client. +In the future if it is sufficiently extended and a need arises to have a state, it would make sense to move it from being a precompile and have actual code. + +### Chain identifier + +Initially, a feature to read the current chain identifier is introduced: `getCurrentChainId()` returns the current chain identifier as a `uint64` encoded value. +It should be a non-payable function, which means sending any value would revert the transaction as described in [EIP-140]. +This has been proposed as [EIP-1344]. + +The contract ABI JSON is the following: +```json +[ + { + "constant": true, + "inputs": [], + "name": "getCurrentChainId", + "outputs": [ + { + "name": "", + "type": "uint64" + } + ], + "payable": false, + "stateMutability": "pure", + "type": "function" + } +] +``` + +This will be translated into sending the bytes `5cf0e8a4` to the ESO and returning the bytes `0000000000000000000000000000000000000000000000000000000000000001` for Ethereum mainnet. + +**Note:** It should be possible to introduce another interface checking the validity of a chain identifier in the chain history or for a given block (see [EIP-1959] and [EIP-1965]). + +## Rationale + + +## Backwards Compatibility + + +## Test Cases + + +## Implementation + + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). + +[Contract ABI Encoding]: https://solidity.readthedocs.io/en/latest/abi-spec.html +[EIP-140]: https://eips.ethereum.org/EIPS/eip-140 +[EIP-210]: https://eips.ethereum.org/EIPS/eip-210 +[EIP-1344]: https://eips.ethereum.org/EIPS/eip-1344 +[EIP-1959]: https://github.com/ethereum/EIPs/pull/1959 +[EIP-1965]: https://github.com/ethereum/EIPs/pull/1965 From 5996a13c22ec3e350d137c1d0eef7562b1db489e Mon Sep 17 00:00:00 2001 From: Nick Johnson Date: Fri, 24 May 2019 09:35:06 +1200 Subject: [PATCH 077/137] Update eip-181.md --- EIPS/eip-181.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/EIPS/eip-181.md b/EIPS/eip-181.md index 3f0107df30c65..cd8dd71334303 100644 --- a/EIPS/eip-181.md +++ b/EIPS/eip-181.md @@ -204,3 +204,6 @@ This registrar, written in Solidity, implements the specifications outlined abov } } } + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 4fe5a9ada3aa5ccd8a3620c1a56633484f24fed5 Mon Sep 17 00:00:00 2001 From: Nick Johnson Date: Fri, 24 May 2019 09:35:16 +1200 Subject: [PATCH 078/137] Update eip-162.md --- EIPS/eip-162.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/EIPS/eip-162.md b/EIPS/eip-162.md index d1936bd63b0df..eaefc623561a1 100644 --- a/EIPS/eip-162.md +++ b/EIPS/eip-162.md @@ -243,3 +243,6 @@ This document borrows heavily from several sources: - 2016-10-26 Added link Alex's design in abstract - 2016-11-01 change 'Planned deactivation' to h3' - 2017-03-13 Update timelines for bidding and reveal periods + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From ea827e875cd52027c2cbc9bc8a8993c8239173a8 Mon Sep 17 00:00:00 2001 From: ledgerwatch Date: Thu, 23 May 2019 23:16:58 +0100 Subject: [PATCH 079/137] State Rent Change A EIP placeholder - State counters contract (#2029) * Create eip-StateRentACountersContract.md * Update eip-StateRentACountersContract.md * Rename eip-StateRentACountersContract.md to eip-2029.md * Update eip-2029.md * Update eip-2029.md * Fix typos * Make EIP-2014 into a proper link --- EIPS/eip-2029.md | 61 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 EIPS/eip-2029.md diff --git a/EIPS/eip-2029.md b/EIPS/eip-2029.md new file mode 100644 index 0000000000000..5a2c49345efec --- /dev/null +++ b/EIPS/eip-2029.md @@ -0,0 +1,61 @@ +--- +eip: 2029 +title: State Rent A - State counters contract +author: Alexey Akhunov (@AlexeyAkhunov) +discussions-to: https://ethereum-magicians.org/t/eip-2029-state-counters-contract-change-a-from-state-rent-v3-proposal/3279 +status: Draft +type: Standards Track +category: Core +created: 2019-05-15 +--- + + + +## Simple Summary + +A smart contract is deployed on all Ethereum networks, at a pre-determined address, with the code that simply reads the slot in its storage specified by the +only parameter. Later, this contract becomes "special" in that Ethereum start writing state counters (number of total transactions, number of accounts, +etc.) into that contract. + +## Abstract + +This is part of the State Rent roadmap. This particular change introduces a place in the Ethereum state where various state counters can be stored. At this +point, the most important counter is the total number of transactions happened, and this counter will be used to populate the nonces of newly created +non-contract accounts. This way of populating nonce ensures replay protection for accounts that were evicted and then brought back by sending ether to them. + +## Motivation + +Ethereum currently does not have a special place in the state for tracking state counters such as number of transactions or number of accounts. + +## Specification + +Prior to the block A, a contract is deployed with the following code: +`0x60 0x20 0x60 0x00 0x80 0x80 0x35 0x54 0x90 0x52 0xF3`, which corresponds to this assembly: +`PUSH1 32 PUSH1 0 DUP1 DUP1 CALLDATALOAD SLOAD SWAP1 MSTORE RETURN` +Call to this contract accepts one 32-byte argument, `x`, and returns the value of the storage item [`x`]. + +This contract is deployed using `CREATE2` opcode in such a way that it has the same address on any network. + +## Rationale + +Two alternative solutions were considered so far: +1. Extending the structure of the Ethereum state to introduce more fields, and hence change the way the state root is constructed. The main downside of this +approach is the impact on the software what is currently coupled with the particular way the state root is constructed. Particularly it affects the software +that deals with merkle proofs derived from the state root. +2. Extended State Oracle ([EIP-2014](https://eips.ethereum.org/EIPS/eip-2014)). Under such proposal, there will be a precompile contract with standardised interface, capable of returning +current values of the counters. However, the actual data being returned by such oracle is not explicitly in the state, and is not Merkelised. It means that all the counters need to be added to the snapshots when the snapshot sync is perform, so they still present in the state, but implicitly. + +## Backwards Compatibility + +This change is backwards compatible and does not require hard fork to be activated. + +## Test Cases + +Tests cases will be created to ensure that the state counter contract returns its storage items correctly. + +## Implementation + +Implementation is envisaged as a transaction that can be posted from any Ethereum address and will cause the deployment of the state counter contract. + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 656aeda526d67da8f2dd06291465330c354cf777 Mon Sep 17 00:00:00 2001 From: Ronan Sandford Date: Fri, 24 May 2019 00:33:26 +0200 Subject: [PATCH 080/137] New Opcode to check if a chainID is part of the history of chainIDs (#1959) --- EIPS/eip-1959.md | 79 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 79 insertions(+) create mode 100644 EIPS/eip-1959.md diff --git a/EIPS/eip-1959.md b/EIPS/eip-1959.md new file mode 100644 index 0000000000000..40af70b401ca7 --- /dev/null +++ b/EIPS/eip-1959.md @@ -0,0 +1,79 @@ +--- +eip: 1959 +title: New Opcode to check if a chainID is part of the history of chainIDs +author: Ronan Sandford (@wighawag) +category: Core +type: Standards Track +discussions-to: https://ethereum-magicians.org/t/eip-1959-valid-chainid-opcode/3170 +status: Draft +created: 2019-04-20 +requires: 155 +--- + + +## Simple Summary +To protect off-chain messages from being reused across different chain, a mechanism need to be given to smart contract to only accept messages for that chain. Since a chain can change its chainID, the mechanism should consider old chainID valid. + +## Abstract +This EIP adds an opcode that returns whether the specific number passed in has been a valid chainID (EIP-155 unique identifier) in the history of the chain (including the current chainID). + +## Motivation +[EIP-155](https://eips.ethereum.org/EIPS/eip-155) proposes to use the chain ID to prevent replay attacks between different chains. It would be a great benefit to have the same possibility inside smart contracts when handling signatures, especially for Layer 2 signature schemes using [EIP-712](https://eips.ethereum.org/EIPS/eip-712). + +[EIP-1344](https://eips.ethereum.org/EIPS/eip-1344) is attempting to solve this by giving smart contract access to the tip of the chainID history. This is insufficient as such value is changing. Hence why EIP-1344 describes a contract based solution to work around the problem. It would be better to solve it in a simpler, cheaper and safer manner, removing the potential risk of misuse present in EIP-1344. + +## Specification +Adds a new opcode ```VALID_CHAINID``` at 0x46, which uses 1 stack argument : a 32 bytes value that represent the chainID to test. It will push ```0x1``` onto the stack if the uint256 value is part of the history (since genesis) of chainIDs of that chain, ```0x0``` otherwise. + +The operation costs `G_blockhash` to execute. + +The cost of the operation might need to be adjusted later as the number of chainID in the history of the chain grows. + +Note though that the alternative to keep track of old chainID is to implement a smart contract based caching solution as EIP-1344 proposes comes with an overall higher gas cost. As such the gas cost is simply a necessary cost for the feature. + +## Rationale +The only approach available today is to specify the chain ID at compile time. Using this approach will result in problems after a contentious hardfork as the contract can't accept message signed with a new chainID. + +The approach proposed by EIP-1344 is to give access to the latest chainID. This is in itself not sufficient and pose the opposite of the problem mentioned above since as soon as a hardfork that change the chainID happens, every L2 messages signed as per [EIP-712](https://eips.ethereum.org/EIPS/eip-712) (with the previous chainID) will fails to be accepted by the contracts after the fork. + +That's why in the rationale of EIP-1344 it is mentioned that users need to implement/use a mechanism to verify the validity of past chainID via a trustless cache implemented via smart contract. + +While this works (except for a temporary gap where the immediately previous chainID is not considered valid), this is actually a required procedure for all contracts that want to accept L2 messages since without it, messages signed before an hardfork that updated the chainID would be rejected. In other words, EIP-1344 expose such risk and it is easy for contract to not consider it by simply checking ```chainID == CHAIN_ID()``` without considering past chainIDs. + +Indeed letting contracts access the latest chainID for L2 message verification is dangerous. The latest chainID is only the tip of the chainID history. As a changing value, the latest chainID is thus not appropriate to ensure the validity of L2 messages. + +Users signing off-chain messages expect their messages to be valid from the time of signing and do not expect these message to be affected by a future hardfork. If the contract use the latest chainID as is for verification, the messages would be invalid as soon as a hardfork that update the chainID happens. For some applications, this will require users to resubmit a new message (think meta transaction), causing them potential loss (or some inconvenience during the hardfork transition), but for some other applications (think state channel) the whole off-chain state become inaccessible, resulting in potentially disastrous situations. + +In other words, we should consider all off-chain messages (with valid chainID) as part of the chain's offchain state. The opcode proposed here, offer smart contracts a simple and safe method to ensure that the offchain state stay valid across fork. + +As for replay protection, the idea of considering all of the off-chain messages signed with valid chainID as part of the chain's offchain-state means that all of these off-chain messages can be reused on the different forks which share a common chainID history (up to where they differ). This is actually an important feature since as mentioned, users expect their signed messages to be valid from the time of signing. From that time onwards these messages should be considered as part of the chain's offchain state. A hardfork should not thus render them invalid. This is similar to how the previous on-chain state is shared between 2 hardforks. + +The wallets will make sure that at any time, a signing message request use the latest chainID of the chain being used. This prevent replay attack onto chain that have different chainID histories (they would not have the same latest chainID). + +Now it is argued in the [EIP1344 discussion](https://ethereum-magicians.org/t/eip-1344-add-chain-id-opcode/1131) that when a contentious hardfork happen and one side of the fork decide to not update its chainID, that side of the chain would be vulnerable to replays since users will keep signing with a chainID that is also valid in the chain that forked. An issue also present in EIP-1344. + +This is simply a natural consequence of using chainID as the only anti-replay information for L2 messages. But this can indeed be an issue if the hardfork is created by a small minority. In that case if the majority ignore the fork and do not update its chainID, then all new message from the majority chain (until they update their chainID) can be replayed on the minority-led hardfork since the majority's current chainID is also part of the minority-led fork's chainID history. + +To fix this, every message could specify the block number representing the time it was signed. The contract could then verify that chainID specified as part of that message was valid at that particular block. + + +While EIP-1344 can't do that accurately as the caching system might leave a gap, this proposal can solve it if it is modified to return the blockNumber at which a chainID become invalid. Unfortunately, this would be easy for contracts to not perform that check. And since it suffice of only one important applications to not follow this procedure to put the minority-led fork at a disadvantage, this would fail to achieve the desired goal of protecting the minority-led fork from replay. + +Since a minority-led fork ignored by the majority means that the majority will not keep track of the messages to be submitted (state channel, ...), if such fork get traction later, this would be at the expense of majority users who were not aware of it. As such this proposal assume that minority-led fork will not get traction later and thus do not require to be protected. + +## Test Cases +TBD + +## Implementation +TBD + +## Backwards Compatibility +This EIP is fully backwards compatible with all chains which implement EIP-155 chain ID domain separator for transaction signing. Existing contract are not affected. + +Similarly to EIP-1344, it might be beneficial to update EIP-712 (still in Draft) to deal with chainID separately from the domain separator. Indeed since chainID is expected to change, if the domain separator include chainID, it would have to be dynamically computed. A caching mechanism could be used by smart contract instead though. + +## References +This was previously suggested as part of [EIP-1344 discussion](https://ethereum-magicians.org/t/eip-1344-add-chain-id-opcode/1131/39). + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). \ No newline at end of file From cef55f5cb9de4c9d1317cb28c0710194ad7a30d9 Mon Sep 17 00:00:00 2001 From: Ronan Sandford Date: Fri, 24 May 2019 00:38:29 +0200 Subject: [PATCH 081/137] Automatically merged updates to draft EIP(s) 1679 (#2055) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-1679.md | 1 + 1 file changed, 1 insertion(+) diff --git a/EIPS/eip-1679.md b/EIPS/eip-1679.md index 7b29f74b76aed..0021feaae2663 100644 --- a/EIPS/eip-1679.md +++ b/EIPS/eip-1679.md @@ -48,6 +48,7 @@ This meta-EIP specifies the changes included in the Ethereum hardfork named Ista - [EIP-1829](https://eips.ethereum.org/EIPS/eip-1829): Precompile for Elliptic Curve Linear Combinations - [EIP-1884](https://eips.ethereum.org/EIPS/eip-1884): Repricing for trie-size-dependent opcodes - [EIP-1930](https://eips.ethereum.org/EIPS/eip-1930): CALLs with strict gas semantic. Revert if not enough gas available. +- [EIP-1959](https://eips.ethereum.org/EIPS/eip-1959): New Opcode to check if a chainID is part of the history of chainIDs - [EIP-2028](https://eips.ethereum.org/EIPS/eip-2028): Calldata gas cost reduction - [EIP-2046](https://eips.ethereum.org/EIPS/eip-2046): Reduced gas cost for static calls made to precompiles From d7db470b40947f98fd6cc0c9e4826007124d89e2 Mon Sep 17 00:00:00 2001 From: Ronan Sandford Date: Fri, 24 May 2019 00:43:43 +0200 Subject: [PATCH 082/137] Copyright 107 (#2068) * add copyrights for 107 * use github username --- EIPS/eip-107.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/EIPS/eip-107.md b/EIPS/eip-107.md index 897feb804b6f9..67caa48d96d45 100644 --- a/EIPS/eip-107.md +++ b/EIPS/eip-107.md @@ -1,7 +1,7 @@ --- eip: 107 title: safe "eth_sendTransaction" authorization via html popup -author: Ronan Sandford +author: Ronan Sandford (@wighawag) created: 2016-06-05 status: Draft type: Standards Track @@ -612,3 +612,6 @@ That's it. ``` +## Copyright + +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From ae038c82bf5a3028bed44fa4aca2005d67ed5f29 Mon Sep 17 00:00:00 2001 From: James Hancock Date: Fri, 24 May 2019 01:52:09 -0400 Subject: [PATCH 083/137] Update eip-1679.md --- EIPS/eip-1679.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-1679.md b/EIPS/eip-1679.md index 3222ee7abd372..d06207b147d0e 100644 --- a/EIPS/eip-1679.md +++ b/EIPS/eip-1679.md @@ -28,7 +28,7 @@ This meta-EIP specifies the changes included in the Ethereum hardfork named Ista ### Proposed EIPs -- [EIP-131] : Add Precompiled BLAKE2b Contract +- [EIP-131](https://github.com/ethereum/EIPs/pull/2024) : Add Precompiled BLAKE2b Contract - [EIP-1057](https://eips.ethereum.org/EIPS/eip-1057): ProgPoW, a Programmatic Proof-of-Work - There is a From dbf67d4f993d25053de8f0423eba8f5e6a05c0aa Mon Sep 17 00:00:00 2001 From: Andrew Cooke Date: Fri, 24 May 2019 03:02:34 -0400 Subject: [PATCH 084/137] Automatically merged updates to draft EIP(s) 1155 (#2074) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-1155.md | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/EIPS/eip-1155.md b/EIPS/eip-1155.md index 7dccdcdc2ae49..c736f9bf8f84e 100644 --- a/EIPS/eip-1155.md +++ b/EIPS/eip-1155.md @@ -44,7 +44,7 @@ pragma solidity ^0.5.8; interface ERC1155 /* is ERC165 */ { /** @dev Either `TransferSingle` or `TransferBatch` MUST emit when tokens are transferred, including zero value transfers as well as minting or burning (see "Safe Transfer Rules" section of the standard). - The `_operator` argument MUST be msg.sender. + The `_operator` argument MUST be the address of an account/contract that is approved to make the transfer (SHOULD be msg.sender). The `_from` argument MUST be the address of the holder whose balance is decreased. The `_to` argument MUST be the address of the recipient whose balance is increased. The `_id` argument MUST be the token type being transferred. @@ -56,7 +56,7 @@ interface ERC1155 /* is ERC165 */ { /** @dev Either `TransferSingle` or `TransferBatch` MUST emit when tokens are transferred, including zero value transfers as well as minting or burning (see "Safe Transfer Rules" section of the standard). - The `_operator` argument MUST be msg.sender. + The `_operator` argument MUST be the address of an account/contract that is approved to make the transfer (SHOULD be msg.sender). The `_from` argument MUST be the address of the holder whose balance is decreased. The `_to` argument MUST be the address of the recipient whose balance is increased. The `_ids` argument MUST be the list of tokens being transferred. @@ -242,7 +242,8 @@ To be more explicit about how safeTransferFrom and safeBatchTransferFrom MUST op * Forwarding should be considered acceptance and then initiating a new `safeTransferFrom` or `safeBatchTransferFrom` in a new context. - The prescribed keccak256 acceptance value magic for the receiver hook being called MUST be returned after forwarding is successful. * The `_data` argument MAY be re-purposed for the new context. -* If forwarding unexpectedly fails the transaction MUST be reverted. +* If forwarding fails the transaction MAY be reverted. + - If the contract logic wishes to keep the ownership of the token(s) itself in this case it MAY do so. #### Rules @@ -269,7 +270,7 @@ To be more explicit about how safeTransferFrom and safeBatchTransferFrom MUST op **_TransferSingle and TransferBatch event rules:_** * `TransferSingle` SHOULD be used to indicate a single balance transfer has occurred between a `_from` and `_to` pair. - It MAY be emitted multiple times to indicate multiple balance changes in the transaction, but note that `TransferBatch` is designed for this to reduce gas consumption. - - The `_operator` argument MUST be msg.sender. + - The `_operator` argument MUST be the address of an account/contract that is approved to make the transfer (SHOULD be msg.sender). - The `_from` argument MUST be the address of the holder whose balance is decreased. - The `_to` argument MUST be the address of the recipient whose balance is increased. - The `_id` argument MUST be the token type being transferred. @@ -278,7 +279,7 @@ To be more explicit about how safeTransferFrom and safeBatchTransferFrom MUST op - When burning/destroying tokens, the `_to` argument MUST be set to `0x0` (i.e. zero address). * `TransferBatch` SHOULD be used to indicate multiple balance transfers have occurred between a `_from` and `_to` pair. - It MAY be emitted with a single element in the list to indicate a singular balance change in the transaction, but note that `TransferSingle` is designed for this to reduce gas consumption. - - The `_operator` argument MUST be msg.sender. + - The `_operator` argument MUST be the address of an account/contract that is approved to make the transfer (SHOULD be msg.sender). - The `_from` argument MUST be the address of the holder whose balance is decreased for each entry pair in `_ids` and `_values`. - The `_to` argument MUST be the address of the recipient whose balance is increased for each entry pair in `_ids` and `_values`. - The `_ids` array argument MUST contain the ids of the tokens being transferred. @@ -292,7 +293,7 @@ To be more explicit about how safeTransferFrom and safeBatchTransferFrom MUST op - To make sure event order is correct in the case of valid re-entry (e.g. if a receiver contract forwards tokens on receipt) state balance and events balance MUST match before calling an external contract. **_onERC1155Received rules:_** -* The `_operator` argument MUST be the address of the account/contract that initiated the transfer (i.e. msg.sender). +- The `_operator` argument MUST be the address of an account/contract that is approved to make the transfer (SHOULD be msg.sender). * The `_from` argument MUST be the address of the holder whose balance is decreased. - `_from` MUST be 0x0 for a mint. * The `_id` argument MUST be the token type being transferred. @@ -309,7 +310,7 @@ To be more explicit about how safeTransferFrom and safeBatchTransferFrom MUST op - The set of all calls to `onERC1155Received` and `onERC1155BatchReceived` describes all balance changes that occurred during the transaction in the order submitted. **_onERC1155BatchReceived rules:_** -* The `_operator` argument MUST be the address of the account/contract that initiated the transfer (i.e. msg.sender). +- The `_operator` argument MUST be the address of an account/contract that is approved to make the transfer (SHOULD be msg.sender). * The `_from` argument MUST be the address of the holder whose balance is decreased. - `_from` MUST be 0x0 for a mint. * The `_ids` argument MUST be the list of tokens being transferred. From e8098d23dc25b2bd4fb76e30f70152081df0e361 Mon Sep 17 00:00:00 2001 From: ledgerwatch Date: Fri, 24 May 2019 11:08:48 +0100 Subject: [PATCH 085/137] State Rent change C draft EIP - Net contract storage size accounting (#2027) * State Rent change C draft EIP * Update eip-draft_StateRentCnetContractSizes.md * Update eip-draft_StateRentCnetContractSizes.md * Rename eip-draft_StateRentCnetContractSizes.md to eip-2027.md * Update eip-2027.md * Update eip-2027.md * Update eip-2027.md * Quote "block C" properly * Update eip-2027.md --- EIPS/eip-2027.md | 74 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 74 insertions(+) create mode 100644 EIPS/eip-2027.md diff --git a/EIPS/eip-2027.md b/EIPS/eip-2027.md new file mode 100644 index 0000000000000..eb7b4ced6bd71 --- /dev/null +++ b/EIPS/eip-2027.md @@ -0,0 +1,74 @@ +--- +eip: 2027 +title: State Rent C - Net contract size accounting +author: Alexey Akhunov (@AlexeyAkhunov) +discussions-to: https://ethereum-magicians.org/t/eip-2027-net-contract-size-accounting-change-c-from-state-rent-v3-proposal/3275 +status: Draft +type: Standards Track +category: Core +created: 2019-05-14 +--- + + + +## Simple Summary + +Ethereum starts counting the number of storage slots filled and emptied in the contracts. Since the number of pre-existing slots is not currently accounted +in the state, effectively, only net change in the number of slots is tracked. In the subsequent change, called *Gross contract size accounting*, the total +number of storage slots starts being tracked. + +## Abstract + +This is part of the State Rent roadmap. This particular change introduces initial, net accounting of the number of the contract storage slots. Though not very +useful on its own, it makes it possible to introduce gross accounting of the number of storage slots, which is useful for number of things: +1. Gas cost of operations suchs as `SLOAD` and `SSTORE` will need to be increased to compensate for extra bandwidth consumed by the block proofs. Although in +the beginning the cost would be fixed, it will later be automatically calibrated depending on the size of the contract `SLOAD` and `SSTORE` operate on. +2. Snapshot sync protocols, like *fast sync*, *warp sync*, *firehose*, *red queen*, and perhaps others, will benefit from having the correct size of the +contract storage present in the state (and therefore being provable via Merkle proofs). + +## Motivation + +Ethereum currently does not track the number of contract storage slots at all, and producing such number given the downloaded state cannot be done in +constant *O(1)* time. + +## Specification + +Each contract (account with `codeHash` field not equal to 0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470, which the hash of the empty code) gets a new uint64 field, called `storagesize`. On and after block `C`, the semantics of the operation `SSTORE` (`location`, `value`) changes as follows: +- If previous value of the [`location`] is 0, and value is not 0, *increment* `storagesize` (semantics of *increment* described below) +- If previous value of the [`location`] is not 0, and value is 0, *decrement* `storagesize` (semantics of *decrement* described below) +- As with other state changes, changes of `storagesize` get reverted when the execution frame reverts, i.e. it needs to use the same techniques as storage values, like journalling (in Geth), and substates (in Parity). +Value of `storagesize` is not observable from contracts at this point. + +### Semantics of *increment* `storagesize` +If `storagesize` is not present, `storagesize` = `HUGE_NUMBER` + 1. +If `storagesize` is present, `storagesize` = `storagesize` + 1. + +### Semantics of *decrement* `storagesize` +If `storagesize` is not present, `storagesize` = `HUGE_NUMBER` - 1. +If `storagesize` is present, `storagesize` = `storagesize` - 1. + +### Note of `HUGE_NUMBER` +There is a constant `HUGE_NUMBER`. It needs to be large enough so that no real metrics (contract storage size, number of accounts, number of contracts, total size of code, total size of storage) will never reach that number, and small enough that it fits in an unsigned 64-bit integer. +Current suggestion is to have `HUGE_NUMBER` = 2^63, which is binary representation is the a single bit in a 64-bit number. + +The idea is to make it decidable later whether the storagesize was ever incremented/decremented (presence of the field), and whether it has been converted from net to gross (by value being smaller than `HUGE_NUMBER/2` - because it will not be possible for any contract be larger than 2^62 at the block `C`). + +## Rationale + +A mechanism for estimation of contract storage size has been proposed [here](https://medium.com/@akhounov/estimation-approximate-of-the-size-of-contracst-in-ethereum-4642fe92d6fe). But it does have a big drawback of introducing a lot of complexity into the consensus +(in the form of estimation algorithm, which has quite a few edge cases to cater for different sizes of the storage). + +## Backwards Compatibility + +This change is not backwards compatible and requires hard fork to be activated. Since the newly introduced field is not observable, this change does not impact any operations of the existing smart contracts. + +## Test Cases + +Tests cases will be generated out of a reference implementation. + +## Implementation + +There will be proof of concept implementation to refine and clarify the specification. + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From fdf85082996d69024700e579bcce6d5bd956f9dd Mon Sep 17 00:00:00 2001 From: ledgerwatch Date: Fri, 24 May 2019 11:12:59 +0100 Subject: [PATCH 086/137] State Rent change B placeholder EIP - net transaction counter (#2031) * Create eip-draft_StateRentBNetTransactionCounter.md * Update and rename eip-draft_StateRentBNetTransactionCounter.md to eip-2031.md * Update eip-2031.md * Update eip-2031.md * Update eip-2031.md * Fix some typos * Use canonical link to EIP-2029 * Update eip-2031.md * Update eip-2031.md --- EIPS/eip-2031.md | 61 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 EIPS/eip-2031.md diff --git a/EIPS/eip-2031.md b/EIPS/eip-2031.md new file mode 100644 index 0000000000000..894eb0d9fc032 --- /dev/null +++ b/EIPS/eip-2031.md @@ -0,0 +1,61 @@ +--- +eip: 2031 +title: State Rent B - Net transaction counter +author: Alexey Akhunov (@AlexeyAkhunov) +discussions-to: https://ethereum-magicians.org/t/eip-2031-net-transaction-counter-change-b-from-state-rent-v3-proposal/3283 +status: Draft +type: Standards Track +category: Core +created: 2019-05-15 +requires: 2029 +--- + + + +## Simple Summary + +Ethereum starts to track the number of transactions inside its state (for now, only number of transactions after this change is introduced, therefore +it is called *Net* transaction count). +It is done by incrementing a storage slot in the special contract, called *State counter contract* ([EIP-2029](https://eips.ethereum.org/EIPS/eip-2029)). + +## Abstract + +It is part of the State Rent roadmap. This particular change makes any Ethereum transaction increment the transaction counter, which is a special storage slot +in the *State counter contract*. This counter will be used to populate the nonces of newly created +non-contract accounts. This way of populating nonce ensures replay protection for accounts that were evicted and then brought back by sending ether to them. + +## Motivation + +Ethereum currently does not have a special place in the state for tracking number of transactions. + +## Specification + +A new field, with the location 0 (that means it resides in the storage slot 0 in the state counter contract, and can +be read by calling that contract with argument being 32 zero bytes), is added to the state counter contract. It will eventually contain `txCount`, the total number of transactions processed up until that point. +On an after block B, or after the deployment of the state counter contract (which comes first), the field `txCount` is incremented after each transaction. Updating `txCount` means updating the storage of state counter contract at the location 0. These changes are never reverted. + +## Rationale + +Two main alternatives were proposed for the replay protection of the accounts that were evicted by subsequently brought back by sending ether to them: +1. Temporal replay protection. The nonce of the new accounts (and those brought back) is still zero, but a new `valid-until` field is introduced, making +transactions invalid for inclusion after the time specified in this field. This, however, has unwanted side effected related to the fact that account +nonces are not only used for replay protection, but also for computing the addresses of the deployed contracts (except those created by `CREATE2`). +2. Setting nonce of new accounts (and those brought back) to something depending on the current block number. This approach requires coming up with +an arbitrary parameter, which is the maximum number of transaction in the block, so that the new nonces never clash with the existing nonces. +This is mostly a concern for private networks at the moment, because they will potentially have significantly more transactions in a block. + +## Backwards Compatibility + +This change is not backwards compatible and requires hard fork to be activated. + +## Test Cases + +Tests cases will be generated out of a reference implementation. + +## Implementation + +There will be proof of concept implementation to refine and clarify the specification. + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). + From 1f7987f9b72335e0db7430fd88ef6361e46255c3 Mon Sep 17 00:00:00 2001 From: ledgerwatch Date: Fri, 24 May 2019 11:15:52 +0100 Subject: [PATCH 087/137] Stateless Clients: Repricing SLOAD and SSTORE to pay for block proofs (#2035) * Create eip-draft_StatelessClientGasRepricing.md * Update and rename eip-draft_StatelessClientGasRepricing.md to eip-2035.md * Update eip-2035.md * Update eip-2035.md * Update eip-2035.md * Update eip-2035.md * Update eip-2035.md * Update eip-2035.md * Fix typos * Use canonical links to other EIPs * Update eip-2035.md * Fix link to EIP-2028 --- EIPS/eip-2035.md | 81 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 81 insertions(+) create mode 100644 EIPS/eip-2035.md diff --git a/EIPS/eip-2035.md b/EIPS/eip-2035.md new file mode 100644 index 0000000000000..6b0eac7f5866a --- /dev/null +++ b/EIPS/eip-2035.md @@ -0,0 +1,81 @@ +--- +eip: 2035 +title: Stateless Clients - Repricing SLOAD and SSTORE to pay for block proofs +author: Alexey Akhunov (@AlexeyAkhunov) +discussions-to: https://ethereum-magicians.org/t/eip-2035-stateless-clients-repricing-sload-and-sstore-to-pay-for-block-proofs/3284 +status: Draft +type: Standards Track +category: Core +created: 2019-05-16 +--- + + + +## Simple Summary + +The gas cost of EVM opcodes `SLOAD` and `SSTORE` increases in order to accommodate extra bandwidth required to propagate block proof together with the block +headers and block bodies, as explained [here](https://medium.com/@akhounov/data-from-the-ethereum-stateless-prototype-8c69479c8abc). + +## Abstract + +It is part of the State Rent roadmap. This particular change prepares Ethereum for introduction of the block proofs (current understanding is that they +can be introuced without a hard fork). The introduction of the block proofs allows any Ethereum node that wishes to receive them, to process transactions +in the blocks without needing to access the Ethereum state. All necessary information for the execution (and the proof of validity) is continued in the +block proofs. In most Ethereum nodes, it will speed up the block processing and reduce the memory footprint of such processing. For mining nodes, however, +there will be more work to do to construct and transmit the block proofs. Therefore, the extra charge (payable to the miners) is introduced. In the first +phase, only contract storage will be covered by the block proofs. It means that the Ethereum nodes will still need access to the accounts in the state, +but block proofs will make it optional to have access to contract storage for executing transactions. Therefore, only `SSTORE` and `SLOAD` opcodes are +affected. + +## Motivation + +There is [empirical analysis](https://github.com/holiman/vmstats/blob/master/README.md) showing that `SLOAD` opcode is currently underpriced in terms +of execution latency it adds to the block processing. The hypothesis is that it is due to the latency of the database accesses. In the same +analysis, `SSTORE` is not considered, because its effect on the database accesses can be (and are in many implementations) delayed until the end of +the block. Stateless clients approach to the contract storage will largely negate that latency because no database accesses will be required. +Instead, bandwidth consumption goes up. There is emprical analysis (unpublished, but will be) suggesting that 1 uncached `SSTORE` or `SLOAD` adds +at most 1 kB to the block proofs. At the current cost of data transmission (68 gas per byte), this translates to the increase of gas cost of both +operations by 69k gas. However, in light of proposal in [EIP-2028](https://eips.ethereum.org/EIPS/eip-2028), the increase can be made much smaller. + +## Specification + +Not very formal at the moment, but will be formalised with more research and prototyping. Gas of operations `SLOAD` and `SSTORE` increases by `X` gas when the storage slots accessed (read by `SLOAD` or written by `SSTORE`) were not previously accessed (by another `SLOAD` or `SSTORE`) during the same transaction. + +Future variant (will be possible after the implementation of the *Gross contract size acccounting*) is researched, where the increase is varied +depending on the size of the contract storage, i.e. `SLOAD` and `SSTORE` for smaller contracts will be cheaper. + +## Rationale + +[EIP-1884](https://eips.ethereum.org/EIPS/eip-1884) seeks to increase the gas cost of `SLOAD` but using a different justification +(latency of the execution as described in the Motivation). This EIP is likely to increase the cost of `SLOAD` by a larger amount, therefore partially +(because EIP-1884 also proposed other increases) supersedes EIP-1884. + +[EIP-2028](https://eips.ethereum.org/EIPS/eip-2028) describes the model that can be used for deciding the gas cost of data transmission. It is relevant +because in the stateless client regime `SSTORE` and `SLOAD` operations add more data to be transmitted (as well as computation to verify the proofs). + +The main alternate design is the rent proportional to the size of the contract storage, which unfortunately introduces a serious griefing +vulnerability problem, and so far the solution seems to be in redesigning and rewriting smart contracts in a way, which makes them not vulnerable. +However, this approach is likely to be very expensive on the non-technical (ecosystem) level. + +## Backwards Compatibility + +This change is not backwards compatible and requires hard fork to be activated. +There might also be an adverse effect of this change on the already deployed contract. It is expected that after this EIP and +[EIP-2026](https://eips.ethereum.org/EIPS/eip-2026) (rent prepayment for accounts), the recommendation will be made to raise the gas limit. This can somewhat dampen the +adverse effect of EIP. The most problematic cases would be with the contracts that assume certain gas costs of `SLOAD` +and `SSTORE` and hard-code them in their internal gas computations. For others, the cost of interacting with the contract +storage will rise and may make some dApps based on such interactions, non-viable. This is a trade off to avoid even bigger +adverse effect of the rent proportional to the contract storage size. However, more research is needed to more fully +analyse the potentially impacted contracts. + +## Test Cases + +Tests cases will be generated out of a reference implementation. + +## Implementation + +There will be proof of concept implementation to refine and clarify the specification. + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). + From 8b8d2eaaaf093ab77b4a990065c22a1234329035 Mon Sep 17 00:00:00 2001 From: ledgerwatch Date: Fri, 24 May 2019 11:27:09 +0100 Subject: [PATCH 088/137] Automatically merged updates to draft EIP(s) 1679 (#2036) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-1679.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/EIPS/eip-1679.md b/EIPS/eip-1679.md index 0021feaae2663..f895a1dbbe2af 100644 --- a/EIPS/eip-1679.md +++ b/EIPS/eip-1679.md @@ -36,6 +36,8 @@ This meta-EIP specifies the changes included in the Ethereum hardfork named Ista above and beyond standard security considerations, that should be evaluated prior to inclusion. - [EIP-1108](https://eips.ethereum.org/EIPS/eip-1108): Reduce alt_bn128 precompile gas costs +- [EIP-1109](https://eips.ethereum.org/EIPS/eip-1109): PRECOMPILEDCALL opcode (Remove CALL costs for precompiled contracts) + - requirement of EIP-1962 - [EIP-1283](https://eips.ethereum.org/EIPS/eip-1283): Net gas metering for SSTORE without dirty maps - [EIP-1344](https://eips.ethereum.org/EIPS/eip-1344): Add ChainID opcode - [EIP-1352](https://eips.ethereum.org/EIPS/eip-1352): Specify restricted address range for precompiles/system contracts @@ -49,7 +51,15 @@ This meta-EIP specifies the changes included in the Ethereum hardfork named Ista - [EIP-1884](https://eips.ethereum.org/EIPS/eip-1884): Repricing for trie-size-dependent opcodes - [EIP-1930](https://eips.ethereum.org/EIPS/eip-1930): CALLs with strict gas semantic. Revert if not enough gas available. - [EIP-1959](https://eips.ethereum.org/EIPS/eip-1959): New Opcode to check if a chainID is part of the history of chainIDs +- [EIP-1962](https://eips.ethereum.org/EIPS/eip-1962): EC arithmetic and pairings with runtime definitions + - replaces EIP-1829 +- [EIP-2026](https://eips.ethereum.org/EIPS/eip-2026): State Rent H - Fixed Prepayment for accounts +- [EIP-2027](https://eips.ethereum.org/EIPS/eip-2027): State Rent C - Net contract size accounting - [EIP-2028](https://eips.ethereum.org/EIPS/eip-2028): Calldata gas cost reduction +- [EIP-2029](https://eips.ethereum.org/EIPS/eip-2029): State Rent A - State counters contract + - requirement of EIP-2031 +- [EIP-2031](https://eips.ethereum.org/EIPS/eip-2031): State Rent B - Net transaction counter +- [EIP-2035](https://eips.ethereum.org/EIPS/eip-2035): Stateless Clients - Repricing SLOAD and SSTORE to pay for block proofs - [EIP-2046](https://eips.ethereum.org/EIPS/eip-2046): Reduced gas cost for static calls made to precompiles ## Timeline From e2f9acef1f9a3c3c99252d3a54199304f2df9238 Mon Sep 17 00:00:00 2001 From: Ronan Sandford Date: Fri, 24 May 2019 12:32:25 +0200 Subject: [PATCH 089/137] Automatically merged updates to draft EIP(s) 1930 (#2076) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-1930.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/EIPS/eip-1930.md b/EIPS/eip-1930.md index abf1456cb9b15..8223277326e09 100644 --- a/EIPS/eip-1930.md +++ b/EIPS/eip-1930.md @@ -52,6 +52,23 @@ if !callCost.IsUint64() || gas < callCost.Uint64() { } ``` +Since checks on gas break current implementation of `eth_estimateGas`, the opcodes need to also use the mechanism described in [EIP-2075](https://github.com/ethereum/EIPs/pull/2075) to ensure `eth_estimateGas` return a value that is sufficient for the transaction to succeed. It must thus set `minimalGas` to equal the max of the current value of `minimalGas` and the sum of the gas spent so far added to the gas required. + +More precisely, as described in EIP-2075: + +Let specify `minimalGas` as a new variable that the EVM need to keep track for the purpose of `eth_estimateGas`. At the start of a tx, it is set to zero. + +At the end of an `eth_estimateGas` call, the gas spent is compared to `minimalGas`. The bigger value of the two is returned as "estimate". It does not have any other role in the context of a transaction call, its only purpose is to fix the current behavior of `eth_estimateGas` so that call to the opcodes describe here return a useful estimate + +If there is enough gas, the gas amount specified will be added to the gas spent up to that point. If that amount is bigger than minimalGas it replaces it. In other words: + +```minimalGas = max(minimalGas, X + )``` +where X is the value passed to REQUIRE_GAS + +As mentioned the result of an `eth_estimateGas` is now + +```max(, minimalGas)``` + ### Rationale Currently the gas specified as part of these opcodes is simply a maximum value. And due to the behavior of [EIP-150](http://eips.ethereum.org/EIPS/eip-150) it is possible for an external call to be given less gas than intended (less than the gas specified as part of the CALL) while the rest of the current call is given enough to continue and succeed. Indeed since with EIP-150, the external call is given at max ```G - Math.floor(G/64)``` where G is the gasleft() at the point of the CALL, the rest of the current call is given ```Math.floor(G/64)``` which can be plenty enough for the transaction to succeed. For example, when G = 6,400,000 the rest of the transaction will be given 100,000 gas plenty enough in many case to succeed. From 734934e24683234d81184bb3028ce7ae5225ad99 Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Fri, 24 May 2019 11:44:03 +0100 Subject: [PATCH 090/137] Automatically merged updates to draft EIP(s) 1679 (#2042) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-1679.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/EIPS/eip-1679.md b/EIPS/eip-1679.md index f895a1dbbe2af..c7e99985869ec 100644 --- a/EIPS/eip-1679.md +++ b/EIPS/eip-1679.md @@ -29,6 +29,7 @@ This meta-EIP specifies the changes included in the Ethereum hardfork named Ista ### Proposed EIPs - [EIP-615](https://eips.ethereum.org/EIPS/eip-615): Subroutines and Static Jumps for the EVM +- [EIP-663](https://eips.ethereum.org/EIPS/eip-663): Unlimited SWAP and DUP instructions - [EIP-1057](https://eips.ethereum.org/EIPS/eip-1057): ProgPoW, a Programmatic Proof-of-Work - There is a @@ -50,9 +51,11 @@ This meta-EIP specifies the changes included in the Ethereum hardfork named Ista - [EIP-1829](https://eips.ethereum.org/EIPS/eip-1829): Precompile for Elliptic Curve Linear Combinations - [EIP-1884](https://eips.ethereum.org/EIPS/eip-1884): Repricing for trie-size-dependent opcodes - [EIP-1930](https://eips.ethereum.org/EIPS/eip-1930): CALLs with strict gas semantic. Revert if not enough gas available. +- [EIP-1985](https://eips.ethereum.org/EIPS/eip-1985): Sane limits for certain EVM parameters - [EIP-1959](https://eips.ethereum.org/EIPS/eip-1959): New Opcode to check if a chainID is part of the history of chainIDs - [EIP-1962](https://eips.ethereum.org/EIPS/eip-1962): EC arithmetic and pairings with runtime definitions - replaces EIP-1829 +- [EIP-2014](https://eips.ethereum.org/EIPS/eip-2014): Extended State Oracle - [EIP-2026](https://eips.ethereum.org/EIPS/eip-2026): State Rent H - Fixed Prepayment for accounts - [EIP-2027](https://eips.ethereum.org/EIPS/eip-2027): State Rent C - Net contract size accounting - [EIP-2028](https://eips.ethereum.org/EIPS/eip-2028): Calldata gas cost reduction From fc56b068df303a9c5e031b0908f243e60c67092d Mon Sep 17 00:00:00 2001 From: James Hancock Date: Fri, 24 May 2019 08:41:40 -0400 Subject: [PATCH 091/137] updated authors formating --- EIPS/eip-131.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-131.md b/EIPS/eip-131.md index 3a6147cff74d8..0c8f97b41f870 100644 --- a/EIPS/eip-131.md +++ b/EIPS/eip-131.md @@ -1,7 +1,7 @@ --- eip: 131 title: Add precompiled BLAKE2b contract -author: Tjaden Hess (@tjade273), Jay Graber, (@carterpy), James Hancock (@madeoftin) +author: Tjaden Hess (@tjade273), Jay Graber, Carterpy (@carterpy), James Hancock (@madeoftin) discussions-to: https://ethereum-magicians.org/t/blake2b-f-precompile/3157 status: Draft type: Standards Track From 3f181cb338ae08cb3c55e60f9239e63c06ea1397 Mon Sep 17 00:00:00 2001 From: James Hancock Date: Fri, 24 May 2019 08:45:01 -0400 Subject: [PATCH 092/137] Updated Formating --- EIPS/eip-1679.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/EIPS/eip-1679.md b/EIPS/eip-1679.md index d06207b147d0e..95aabcdea6232 100644 --- a/EIPS/eip-1679.md +++ b/EIPS/eip-1679.md @@ -28,7 +28,7 @@ This meta-EIP specifies the changes included in the Ethereum hardfork named Ista ### Proposed EIPs -- [EIP-131](https://github.com/ethereum/EIPs/pull/2024) : Add Precompiled BLAKE2b Contract +- [EIP-131](https://eips.ethereum.org/EIPS/eip-131): Add Precompiled BLAKE2b Contract - [EIP-1057](https://eips.ethereum.org/EIPS/eip-1057): ProgPoW, a Programmatic Proof-of-Work - There is a @@ -46,7 +46,6 @@ This meta-EIP specifies the changes included in the Ethereum hardfork named Ista - [EIP-1829](https://eips.ethereum.org/EIPS/eip-1829): Precompile for Elliptic Curve Linear Combinations - [EIP-1884](https://eips.ethereum.org/EIPS/eip-1884): Repricing for trie-size-dependent opcodes - ## Timeline * 2019-05-17 (Fri) hard deadline to accept proposals for "Istanbul" From a573835f23297f7faad6c2eb8543f4839baa81b6 Mon Sep 17 00:00:00 2001 From: William Entriken Date: Fri, 24 May 2019 08:54:14 -0400 Subject: [PATCH 093/137] Automatically merged updates to draft EIP(s) 1418 (#2078) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-1418.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-1418.md b/EIPS/eip-1418.md index 6289137a62550..398adaa3f87e0 100644 --- a/EIPS/eip-1418.md +++ b/EIPS/eip-1418.md @@ -1,7 +1,7 @@ --- eip: 1418 title: Blockchain Storage Rent Payment -author: William Entriken <@fulldecent> +author: William Entriken (@fulldecent) discussions-to: https://github.com/ethereum/EIPs/issues/1418 status: Draft type: Standards Track From 9af2a9b1efb89b8b3d927b29081ff7dafadf26e8 Mon Sep 17 00:00:00 2001 From: Antonio Salazar Cardozo Date: Fri, 24 May 2019 11:32:38 -0400 Subject: [PATCH 094/137] Automatically merged updates to draft EIP(s) 1108 (#2067) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-1108.md | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/EIPS/eip-1108.md b/EIPS/eip-1108.md index 792cc9085c016..e67cd8a8f286c 100644 --- a/EIPS/eip-1108.md +++ b/EIPS/eip-1108.md @@ -59,7 +59,19 @@ Following is a table with the current gas cost and new gas cost: The gas costs for `ECADD` and `ECMUL` are updates to the costs listed in EIP-196, while the gas costs for the pairing check are updates to the cost listed in EIP-197. Updated gas costs have been adjusted to the less performant -client which is Parity, according to benchmarks[3]. The updated gas costs are scaled relative to the `ecrecover` precompile. i.e. in the benchmark, `ecrecover` ran in 116 microseconds. If we consider 3,000 gas the fair price for `ecrecover`, we can obtain a metric how much gas should be charged per microsecond of an algorithm's runtime, and use that to price the elliptic curve precompiles. +client which is Parity, according to benchmarks[3]. + +To come up with these updates gas costs, the performance of the `ecrecover` precompile +was measured at 116 microseconds per `ecrecover` invocation. Assuming the `ecrecover` +gas price is fair at 3,000 gas, we get a price of 25.86 gas per microsecond of a precompile +algorithm's runtime. With this in mind, the pairing precompile took 3,037 microseconds to +compute 1 pairing, and 14,663 microseconds to compute 10 pairings. From this, the pairing +algorithm has a fixed 'base' run-time of 1,745 microseconds, plus 1,292 microseconds per +pairing. We can split the run-time into 'fixed cost' and 'linear cost per pairing' +components because of the structure of the algorithm. + +Thus using a 'fair' price of 25.86 gas per microsecond, we get a gas formula of +~`35,000 * k + 45,000` gas, where `k` is the number of pairings being computed. [4] [1]- Per [EIP-196](https://github.com/ethereum/EIPs/blob/984cf5de90bbf5fbe7e49be227b0c2f9567e661e/EIPS/eip-196.md#gas-costs). @@ -67,6 +79,8 @@ client which is Parity, according to benchmarks[3]. The updated gas c [3]- [Parity benchmarks.](https://gist.github.com/zac-williamson/838410a3da179d47d31b25b586c15e53) +[4]- [PR comment clarifying gas cost math](https://github.com/ethereum/EIPs/pull/1987#discussion_r280977066). + ## Rationale ### Existing protocols would benefit immensely from cheaper elliptic curve cryptography @@ -116,3 +130,7 @@ Both the Parity and Geth clients have already implemented cryptographic librarie * [Geth bn256 library (golang)](https://github.com/ethereum/go-ethereum/tree/master/crypto/bn256/cloudflare) * [MCL, a portable C++ pairing library](https://github.com/herumi/mcl) * [Libff, a C++ pairing library used in many zk-SNARK libraries](https://github.com/scipr-lab/libff) + + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 4b676ff535ce02443433d03c78e014341e20d11d Mon Sep 17 00:00:00 2001 From: Andrew Cooke Date: Fri, 24 May 2019 21:27:32 -0400 Subject: [PATCH 095/137] Automatically merged updates to draft EIP(s) 1155 (#2083) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-1155.md | 78 +++++++++++++++++++++++++++++++----------------- 1 file changed, 51 insertions(+), 27 deletions(-) diff --git a/EIPS/eip-1155.md b/EIPS/eip-1155.md index c736f9bf8f84e..bb33ef2e55ead 100644 --- a/EIPS/eip-1155.md +++ b/EIPS/eip-1155.md @@ -160,7 +160,7 @@ interface ERC1155TokenReceiver { /** @notice Handle the receipt of a single ERC1155 token type. @dev An ERC1155-compliant smart contract MUST call this function on the token recipient contract, at the end of a `safeTransferFrom` after the balance has been updated. - This function MUST return `bytes4(keccak256("accept_erc1155_tokens()"))` (i.e. 0x4dc21a2f) if it accepts the transfer. + This function MUST return `bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)"))` (i.e. 0xf23a6e61) if it accepts the transfer. This function MUST revert if it rejects the transfer. Return of any other value than the prescribed keccak256 generated value MUST result in the transaction being reverted by the caller. @param _operator The address which initiated the transfer (i.e. msg.sender) @@ -168,14 +168,14 @@ interface ERC1155TokenReceiver { @param _id The ID of the token being transferred @param _value The amount of tokens being transferred @param _data Additional data with no specified format - @return `bytes4(keccak256("accept_erc1155_tokens()"))` + @return `bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)"))` */ function onERC1155Received(address _operator, address _from, uint256 _id, uint256 _value, bytes calldata _data) external returns(bytes4); /** @notice Handle the receipt of multiple ERC1155 token types. @dev An ERC1155-compliant smart contract MUST call this function on the token recipient contract, at the end of a `safeBatchTransferFrom` after the balances have been updated. - This function MUST return `bytes4(keccak256("accept_batch_erc1155_tokens()"))` (i.e. 0xac007889) if it accepts the transfer(s). + This function MUST return `bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))` (i.e. 0xbc197c81) if it accepts the transfer(s). This function MUST revert if it rejects the transfer(s). Return of any other value than the prescribed keccak256 generated value MUST result in the transaction being reverted by the caller. @param _operator The address which initiated the batch transfer (i.e. msg.sender) @@ -183,7 +183,7 @@ interface ERC1155TokenReceiver { @param _ids An array containing ids of each token being transferred (order and length must match _values array) @param _values An array containing amounts of each token being transferred (order and length must match _ids array) @param _data Additional data with no specified format - @return `bytes4(keccak256("accept_batch_erc1155_tokens()"))` + @return `bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))` */ function onERC1155BatchReceived(address _operator, address _from, uint256[] calldata _ids, uint256[] calldata _values, bytes calldata _data) external returns(bytes4); @@ -199,7 +199,7 @@ interface ERC1155TokenReceiver { ### Safe Transfer Rules -To be more explicit about how safeTransferFrom and safeBatchTransferFrom MUST operate with respect to the `ERC1155TokenReceiver` hook functions, a list of scenarios and rules follows. +To be more explicit about how the standard `safeTransferFrom` and `safeBatchTransferFrom` functions MUST operate with respect to the `ERC1155TokenReceiver` hook functions, a list of scenarios and rules follows. #### Scenarios @@ -219,18 +219,18 @@ To be more explicit about how safeTransferFrom and safeBatchTransferFrom MUST op **_Scenario#5 :_** The receiver implements the necessary `ERC1155TokenReceiver` interface function(s) but throws an error. * The transfer MUST be reverted. -**_Scenario#6 :_** The receiver implements the `ERC1155TokenReceiver` interface and is the recipient of one and only one balance change (e.g. safeTransferFrom called). -* All the balances in the transfer MUST have been updated to match the senders intent before any hook is called on a recipient. -* All the transfer events for the transfer MUST have been emitted to reflect the balance changes before any hook is called on a recipient. -* One of `onERC1155Received` or `onERC1155BatchReceived` MUST be called on the recipient. +**_Scenario#6 :_** The receiver implements the `ERC1155TokenReceiver` interface and is the recipient of one and only one balance change (e.g. `safeTransferFrom` called). +* The balances for the transfer MUST have been updated before the `ERC1155TokenReceiver` hook is called on a recipient contract. +* The transfer event MUST have been emitted to reflect the balance changes before the `ERC1155TokenReceiver` hook is called on the recipient contract. +* One of `onERC1155Received` or `onERC1155BatchReceived` MUST be called on the recipient contract. * The `onERC1155Received` hook SHOULD be called on the recipient contract and its rules followed. - See "onERC1155Received rules" for further rules that MUST be followed. * The `onERC1155BatchReceived` hook MAY be called on the recipient contract and its rules followed. - See "onERC1155BatchReceived rules" for further rules that MUST be followed. -**_Scenario#7 :_** The receiver implements the `ERC1155TokenReceiver` interface and is the recipient of more than one balance change (e.g. safeBatchTransferFrom called). -* All the balances in the transfer MUST have been updated to match the senders intent before any hook is called on a recipient. -* All the transfer events for the transfer MUST have been emitted to reflect the balance changes before any hook is called on a recipient. +**_Scenario#7 :_** The receiver implements the `ERC1155TokenReceiver` interface and is the recipient of more than one balance change (e.g. `safeBatchTransferFrom` called). +* All the balances in the transfer related to the next hook call MUST have been updated before that `ERC1155TokenReceiver` hook is called on a recipient contract. +* All transfer events MUST have been emitted to reflect current balance changes before an `ERC1155TokenReceiver` hook is called on the recipient contract. * `onERC1155Received` or `onERC1155BatchReceived` MUST be called on the recipient as many times as necessary such that every balance change for the recipient in the scenario is accounted for. - The return magic value for every hook call MUST be checked and acted upon as per "onERC1155Received rules" and "onERC1155BatchReceived rules". * The `onERC1155BatchReceived` hook SHOULD be called on the recipient contract and its rules followed. @@ -244,6 +244,14 @@ To be more explicit about how safeTransferFrom and safeBatchTransferFrom MUST op * The `_data` argument MAY be re-purposed for the new context. * If forwarding fails the transaction MAY be reverted. - If the contract logic wishes to keep the ownership of the token(s) itself in this case it MAY do so. + +**_Scenario#9 :_** You are transferring tokens via a non-standard api call i.e. an implementation specific api and NOT `safeTransferFrom` or `safeBatchTransferFrom`. +* In this scenario all balance updates and events outputs rules are the same as if a standard function had been called. + - i.e. an external viewer should still be able to query a balance via a function and it be identical to the balance as determined by `TransferSingle` and '`TransferBatch` events alone. +* If the receiver is a contract the `ERC1155TokenReceiver` hooks still need to be called on it and the return values respected the same as if a standard function had been called. + - However while the `safeTransferFrom` or `safeBatchTransferFrom` functions MUST revert if a receiving contract does not implement the `ERC1155TokenReceiver` interface, a non-standard function MAY proceed with the transfer. + - See "Implementation specific transfer api rules". + #### Rules @@ -300,11 +308,11 @@ To be more explicit about how safeTransferFrom and safeBatchTransferFrom MUST op * The `_value` argument MUST be the number of tokens the holder balance is decreased by and match what the recipient balance is increased by. * The `_data` argument MUST contain the information provided by the sender for the transfer with its contents unaltered. - i.e. it MUST pass on the unaltered `_data` argument sent via the `safeTransferFrom` or `safeBatchTransferFrom` call for this transfer. -* The recipient contract MAY accept an increase of its balance by returning the acceptance magic value `bytes4(keccak256("accept_erc1155_tokens()"))` - - If the return value is `bytes4(keccak256("accept_erc1155_tokens()"))` the transfer MUST be completed or MUST revert if any other conditions are not met for success. +* The recipient contract MAY accept an increase of its balance by returning the acceptance magic value `bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)"))` + - If the return value is `bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)"))` the transfer MUST be completed or MUST revert if any other conditions are not met for success. * The recipient contract MAY reject an increase of its balance by calling revert. - If recipient contract throws/reverts the transaction MUST be reverted. -* If the return value is anything other than `bytes4(keccak256("accept_erc1155_tokens()"))` the transaction MUST be reverted. +* If the return value is anything other than `bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)"))` the transaction MUST be reverted. * `onERC1155Received` (and/or `onERC1155BatchReceived`) MAY be called multiple times in a single transaction and the following requirements must be met: - All callbacks represent mutually exclusive balance changes. - The set of all calls to `onERC1155Received` and `onERC1155BatchReceived` describes all balance changes that occurred during the transaction in the order submitted. @@ -317,11 +325,11 @@ To be more explicit about how safeTransferFrom and safeBatchTransferFrom MUST op * The `_values` argument MUST be the list of number of tokens (matching the list and order of tokens specified in `_ids`) the holder balance is decreased by and match what the recipient balance is increased by. * The `_data` argument MUST contain the information provided by the sender for the transfer with its contents unaltered. - i.e. it MUST pass on the unaltered `_data` argument sent via the `safeBatchTransferFrom` call for this transfer. -* The recipient contract MAY accept an increase of its balance by returning the acceptance magic value `bytes4(keccak256("accept_batch_erc1155_tokens()"))` - - If the return value is `bytes4(keccak256("accept_batch_erc1155_tokens()"))` the transfer MUST be completed or MUST revert if any other conditions are not met for success. +* The recipient contract MAY accept an increase of its balance by returning the acceptance magic value `bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))` + - If the return value is `bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))` the transfer MUST be completed or MUST revert if any other conditions are not met for success. * The recipient contract MAY reject an increase of its balance by calling revert. - If recipient contract throws/reverts the transaction MUST be reverted. -* If the return value is anything other than `bytes4(keccak256("accept_batch_erc1155_tokens()"))` the transaction MUST be reverted. +* If the return value is anything other than `bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))` the transaction MUST be reverted. * `onERC1155BatchReceived` (and/or `onERC1155Received`) MAY be called multiple times in a single transaction and the following requirements must be met: - All callbacks represent mutually exclusive balance changes. - The set of all calls to `onERC1155Received` and `onERC1155BatchReceived` describes all balance changes that occurred during the transaction in the order submitted. @@ -338,26 +346,42 @@ To be more explicit about how safeTransferFrom and safeBatchTransferFrom MUST op - It MUST NOT consume more than 5,000 gas. **_Implementation specific transfer api rules:_** -* If implementation specific api functions are used to transfer 1155 tokens to a contract, the safeTransferFrom, or safeBatchTransferFrom (as appropriate) rules MUST be followed. +* If implementation specific api functions are used to transfer ERC-1155 tokens to a contract, the `safeTransferFrom`, or `safeBatchTransferFrom` (as appropriate) rules MUST still be followed if the receiver implements the `ERC1155TokenReceiver` interface. If not it is up to the implementation to revert or proceed. +* An example: + 1. A approved user calls a function such as `function myTransferFrom(address _from, address _to, uint256[] calldata _ids, uint256[] calldata _values);`. + 2. `myTransferFrom` updates the balances for `_from` and `_to` addresses for all `_ids` and `_values`. + 3. `myTransferFrom` emits `TransferBatch` with the details of what was transferred from address `_from` to address `_to`. + 4. `myTransferFrom` checks if `_to` is a contract address and determines that it is (if not, then the transfer can be considered successful). + 5. `myTransferFrom` calls `onERC1155BatchReceived` on `_to` and it reverts or returns an unknown value (if it had returned `bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))` the transfer can be considered successful). + 6. At this point `myTransferFrom` MAY decide to revert the transaction immediately as receipt of the tokens was not explicitly accepted by the `onERC1155BatchReceived` function. + 7. If `myTransferFrom` wishes to continue it MUST call `isERC1155TokenReceiver()` on `_to` and if it returns `bytes4(keccak256("isERC1155TokenReceiver()"))` the transaction MUST be reverted, as it is a valid receiver and the previous step failed. + 8. If the above call to `isERC1155TokenReceiver()` on `_to` reverts or returns an unknown value the `myTransferFrom` function MAY consider this transfer successful (__NOTE__: this MAY result in unrecoverable tokens if sent to an address that does not expect to receive ERC-1155 tokens). +* The above example is not exhaustive but illustrates the major points (and shows that most are shared with `safeTransferFrom` and `safeBatchTransferFrom`): + - Balances that are updated MUST have equivalent transfer events emitted. + - A receiver address has to be checked if it is a contract and if so relevant `ERC1155TokenReceiver` hook function(s) have to be called on it. + - Balances (and events associated) that are referenced in a call to a receiver hook MUST be updated (and emitted) before the `ERC1155TokenReceiver` hook is called. + - The return values of the `ERC1155TokenReceiver` hook functions that are called MUST be respected if they are implemented. + - Only in the case that a recipient contract does NOT implement the necessary `ERC1155TokenReceiver` hook functions can a non-standard implementation allow tokens to be sent to it. A standard function MUST always revert regardless (unless it is a hybrid implementation see "Compatibility with other standards"). + ###### A solidity example of the keccak256 generated constants for the return magic is: - - bytes4 constant public ERC1155_ACCEPTED = 0x4dc21a2f; // bytes4(keccak256("accept_erc1155_tokens()")) - - bytes4 constant public ERC1155_BATCH_ACCEPTED = 0xac007889; // bytes4(keccak256("accept_batch_erc1155_tokens()")) + - bytes4 constant public ERC1155_ACCEPTED = 0xf23a6e61; // bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)")) + - bytes4 constant public ERC1155_BATCH_ACCEPTED = 0xbc197c81; // bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)")) #### Compatibility with other standards There have been requirements during the design discussions to have this standard be compatible with existing standards when sending to contract addresses, specifically ERC-721 at time of writing. To cater for this scenario, there is some leeway with the rejection logic should a contract not implement the `ERC1155TokenReceiver` as per "Safe Transfer Rules" section above, specifically "Scenario#3 : The receiver does not implement the necessary `ERC1155TokenReceiver` interface function(s)". -Hence in a hybrid 1155 contract implementation an extra call MUST be made on the recipient contract and checked before any hook calls to `onERC1155Received` or `onERC1155BatchReceived` are made. +Hence in a hybrid ERC-1155 contract implementation an extra call MUST be made on the recipient contract and checked before any hook calls to `onERC1155Received` or `onERC1155BatchReceived` are made. Order of operation MUST therefore be: -1. The implementation MUST call the function `isERC1155TokenReceiver` on the recipient, providing at least 5,000 gas. -2. If the function call succeeds and the return value is `bytes4(keccak256("isERC1155TokenReceiver()"))` the implementation proceeds as a regular 1155 implementation, with the call(s) to the `onERC1155Received` or `onERC1155BatchReceived` hooks and rules associated. -3. If the function call fails or the return value is NOT `bytes4(keccak256("isERC1155TokenReceiver()"))` the implementation can assume the contract recipient is not an `ERC1155TokenReceiver` and follow its other standard's rules for transfers. +1. The implementation MUST call the function `isERC1155TokenReceiver` on the recipient contract, providing at least 5,000 gas. +2. If the function call succeeds and the return value is `bytes4(keccak256("isERC1155TokenReceiver()"))` the implementation proceeds as a regular ERC-1155 implementation, with the call(s) to the `onERC1155Received` or `onERC1155BatchReceived` hooks and rules associated. +3. If the function call fails or the return value is NOT `bytes4(keccak256("isERC1155TokenReceiver()"))` the implementation can assume the recipient contract is not an `ERC1155TokenReceiver` and follow its other standard's rules for transfers. -*__Note that a pure implementation of a single standard is recommended__* rather than a hybrid solution, but an example of a hybrid 1155+721 contract is linked in the references section under implementations. +*__Note that a pure implementation of a single standard is recommended__* rather than a hybrid solution, but an example of a hybrid ERC-1155/ERC-721 contract is linked in the references section under implementations. -An important consideration is that even if the tokens are sent with another standard's rules the *__1155 transfer events MUST still be emitted.__* This is so the balances can still be determined via events alone as per 1155 standard rules. +An important consideration is that even if the tokens are sent with another standard's rules the *__1155 transfer events MUST still be emitted.__* This is so the balances can still be determined via events alone as per ERC-1155 standard rules. ### Metadata From 9fa08d11a65e6c44b7b7a1e266017c3d0f9fa197 Mon Sep 17 00:00:00 2001 From: Andrew Cooke Date: Fri, 24 May 2019 22:49:29 -0400 Subject: [PATCH 096/137] Automatically merged updates to draft EIP(s) 1155 (#2084) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-1155.md | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/EIPS/eip-1155.md b/EIPS/eip-1155.md index bb33ef2e55ead..f551d3ed4e427 100644 --- a/EIPS/eip-1155.md +++ b/EIPS/eip-1155.md @@ -229,7 +229,7 @@ To be more explicit about how the standard `safeTransferFrom` and `safeBatchTran - See "onERC1155BatchReceived rules" for further rules that MUST be followed. **_Scenario#7 :_** The receiver implements the `ERC1155TokenReceiver` interface and is the recipient of more than one balance change (e.g. `safeBatchTransferFrom` called). -* All the balances in the transfer related to the next hook call MUST have been updated before that `ERC1155TokenReceiver` hook is called on a recipient contract. +* All balance transfers that are referenced in a call to an `ERC1155TokenReceiver` hook MUST be updated before the `ERC1155TokenReceiver` hook is called on the recipient contract. * All transfer events MUST have been emitted to reflect current balance changes before an `ERC1155TokenReceiver` hook is called on the recipient contract. * `onERC1155Received` or `onERC1155BatchReceived` MUST be called on the recipient as many times as necessary such that every balance change for the recipient in the scenario is accounted for. - The return magic value for every hook call MUST be checked and acted upon as per "onERC1155Received rules" and "onERC1155BatchReceived rules". @@ -245,12 +245,12 @@ To be more explicit about how the standard `safeTransferFrom` and `safeBatchTran * If forwarding fails the transaction MAY be reverted. - If the contract logic wishes to keep the ownership of the token(s) itself in this case it MAY do so. -**_Scenario#9 :_** You are transferring tokens via a non-standard api call i.e. an implementation specific api and NOT `safeTransferFrom` or `safeBatchTransferFrom`. -* In this scenario all balance updates and events outputs rules are the same as if a standard function had been called. - - i.e. an external viewer should still be able to query a balance via a function and it be identical to the balance as determined by `TransferSingle` and '`TransferBatch` events alone. +**_Scenario#9 :_** You are transferring tokens via a non-standard API call i.e. an implementation specific API and NOT `safeTransferFrom` or `safeBatchTransferFrom`. +* In this scenario all balance updates and events output rules are the same as if a standard function had been called. + - i.e. an external viewer should still be able to query a balance via a function and it be identical to the balance as determined by `TransferSingle` and `TransferBatch` events alone. * If the receiver is a contract the `ERC1155TokenReceiver` hooks still need to be called on it and the return values respected the same as if a standard function had been called. - However while the `safeTransferFrom` or `safeBatchTransferFrom` functions MUST revert if a receiving contract does not implement the `ERC1155TokenReceiver` interface, a non-standard function MAY proceed with the transfer. - - See "Implementation specific transfer api rules". + - See "Implementation specific transfer API rules". #### Rules @@ -345,23 +345,23 @@ To be more explicit about how the standard `safeTransferFrom` and `safeBatchTran - It MUST return the same value. - It MUST NOT consume more than 5,000 gas. -**_Implementation specific transfer api rules:_** -* If implementation specific api functions are used to transfer ERC-1155 tokens to a contract, the `safeTransferFrom`, or `safeBatchTransferFrom` (as appropriate) rules MUST still be followed if the receiver implements the `ERC1155TokenReceiver` interface. If not it is up to the implementation to revert or proceed. +**_Implementation specific transfer API rules:_** +* If an implementation specific API function is used to transfer ERC-1155 token(s) to a contract, the `safeTransferFrom` or `safeBatchTransferFrom` (as appropriate) rules MUST still be followed if the receiver implements the `ERC1155TokenReceiver` interface. If it does not the non-standard implementation MAY revert or MAY proceed. * An example: - 1. A approved user calls a function such as `function myTransferFrom(address _from, address _to, uint256[] calldata _ids, uint256[] calldata _values);`. + 1. An approved user calls a function such as `function myTransferFrom(address _from, address _to, uint256[] calldata _ids, uint256[] calldata _values);`. 2. `myTransferFrom` updates the balances for `_from` and `_to` addresses for all `_ids` and `_values`. 3. `myTransferFrom` emits `TransferBatch` with the details of what was transferred from address `_from` to address `_to`. - 4. `myTransferFrom` checks if `_to` is a contract address and determines that it is (if not, then the transfer can be considered successful). + 4. `myTransferFrom` checks if `_to` is a contract address and determines that it is so (if not, then the transfer can be considered successful). 5. `myTransferFrom` calls `onERC1155BatchReceived` on `_to` and it reverts or returns an unknown value (if it had returned `bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))` the transfer can be considered successful). - 6. At this point `myTransferFrom` MAY decide to revert the transaction immediately as receipt of the tokens was not explicitly accepted by the `onERC1155BatchReceived` function. - 7. If `myTransferFrom` wishes to continue it MUST call `isERC1155TokenReceiver()` on `_to` and if it returns `bytes4(keccak256("isERC1155TokenReceiver()"))` the transaction MUST be reverted, as it is a valid receiver and the previous step failed. + 6. At this point `myTransferFrom` MAY decide to revert the transaction immediately as receipt of the token(s) was not explicitly accepted by the `onERC1155BatchReceived` function. + 7. If `myTransferFrom` wishes to continue it MUST call `isERC1155TokenReceiver()` on `_to` and if it returns `bytes4(keccak256("isERC1155TokenReceiver()"))` the transaction MUST be reverted, as it is now known to be a valid receiver and the previous acceptance step failed. 8. If the above call to `isERC1155TokenReceiver()` on `_to` reverts or returns an unknown value the `myTransferFrom` function MAY consider this transfer successful (__NOTE__: this MAY result in unrecoverable tokens if sent to an address that does not expect to receive ERC-1155 tokens). * The above example is not exhaustive but illustrates the major points (and shows that most are shared with `safeTransferFrom` and `safeBatchTransferFrom`): - Balances that are updated MUST have equivalent transfer events emitted. - A receiver address has to be checked if it is a contract and if so relevant `ERC1155TokenReceiver` hook function(s) have to be called on it. - - Balances (and events associated) that are referenced in a call to a receiver hook MUST be updated (and emitted) before the `ERC1155TokenReceiver` hook is called. + - Balances (and events associated) that are referenced in a call to an `ERC1155TokenReceiver` hook MUST be updated (and emitted) before the `ERC1155TokenReceiver` hook is called. - The return values of the `ERC1155TokenReceiver` hook functions that are called MUST be respected if they are implemented. - - Only in the case that a recipient contract does NOT implement the necessary `ERC1155TokenReceiver` hook functions can a non-standard implementation allow tokens to be sent to it. A standard function MUST always revert regardless (unless it is a hybrid implementation see "Compatibility with other standards"). + - Only non-standard transfer functions MAY allow tokens to be sent to a recipient contract that does NOT implement the necessary `ERC1155TokenReceiver` hook functions. `safeTransferFrom` and `safeBatchTransferFrom` MUST revert in that case (unless it is a hybrid standards implementation see "Compatibility with other standards"). ###### A solidity example of the keccak256 generated constants for the return magic is: From 69217d89e53dfda3225a4a529b1b33c06333ca1d Mon Sep 17 00:00:00 2001 From: Andrew Cooke Date: Fri, 24 May 2019 23:12:44 -0400 Subject: [PATCH 097/137] Automatically merged updates to draft EIP(s) 1155 (#2085) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-1155.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-1155.md b/EIPS/eip-1155.md index f551d3ed4e427..24d5ebefea7fb 100644 --- a/EIPS/eip-1155.md +++ b/EIPS/eip-1155.md @@ -346,7 +346,7 @@ To be more explicit about how the standard `safeTransferFrom` and `safeBatchTran - It MUST NOT consume more than 5,000 gas. **_Implementation specific transfer API rules:_** -* If an implementation specific API function is used to transfer ERC-1155 token(s) to a contract, the `safeTransferFrom` or `safeBatchTransferFrom` (as appropriate) rules MUST still be followed if the receiver implements the `ERC1155TokenReceiver` interface. If it does not the non-standard implementation MAY revert or MAY proceed. +* If an implementation specific API function is used to transfer ERC-1155 token(s) to a contract, the `safeTransferFrom` or `safeBatchTransferFrom` (as appropriate) rules MUST still be followed if the receiver implements the `ERC1155TokenReceiver` interface. If it does not the non-standard implementation SHOULD revert but MAY proceed. * An example: 1. An approved user calls a function such as `function myTransferFrom(address _from, address _to, uint256[] calldata _ids, uint256[] calldata _values);`. 2. `myTransferFrom` updates the balances for `_from` and `_to` addresses for all `_ids` and `_values`. From ae0c0d8fa17b1ee84b69aa5294c550e14492c577 Mon Sep 17 00:00:00 2001 From: Ronan Sandford Date: Sat, 25 May 2019 22:06:21 +0100 Subject: [PATCH 098/137] Automatically merged updates to draft EIP(s) 1930 (#2086) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-1930.md | 17 ----------------- 1 file changed, 17 deletions(-) diff --git a/EIPS/eip-1930.md b/EIPS/eip-1930.md index 8223277326e09..abf1456cb9b15 100644 --- a/EIPS/eip-1930.md +++ b/EIPS/eip-1930.md @@ -52,23 +52,6 @@ if !callCost.IsUint64() || gas < callCost.Uint64() { } ``` -Since checks on gas break current implementation of `eth_estimateGas`, the opcodes need to also use the mechanism described in [EIP-2075](https://github.com/ethereum/EIPs/pull/2075) to ensure `eth_estimateGas` return a value that is sufficient for the transaction to succeed. It must thus set `minimalGas` to equal the max of the current value of `minimalGas` and the sum of the gas spent so far added to the gas required. - -More precisely, as described in EIP-2075: - -Let specify `minimalGas` as a new variable that the EVM need to keep track for the purpose of `eth_estimateGas`. At the start of a tx, it is set to zero. - -At the end of an `eth_estimateGas` call, the gas spent is compared to `minimalGas`. The bigger value of the two is returned as "estimate". It does not have any other role in the context of a transaction call, its only purpose is to fix the current behavior of `eth_estimateGas` so that call to the opcodes describe here return a useful estimate - -If there is enough gas, the gas amount specified will be added to the gas spent up to that point. If that amount is bigger than minimalGas it replaces it. In other words: - -```minimalGas = max(minimalGas, X + )``` -where X is the value passed to REQUIRE_GAS - -As mentioned the result of an `eth_estimateGas` is now - -```max(, minimalGas)``` - ### Rationale Currently the gas specified as part of these opcodes is simply a maximum value. And due to the behavior of [EIP-150](http://eips.ethereum.org/EIPS/eip-150) it is possible for an external call to be given less gas than intended (less than the gas specified as part of the CALL) while the rest of the current call is given enough to continue and succeed. Indeed since with EIP-150, the external call is given at max ```G - Math.floor(G/64)``` where G is the gasleft() at the point of the CALL, the rest of the current call is given ```Math.floor(G/64)``` which can be plenty enough for the transaction to succeed. For example, when G = 6,400,000 the rest of the transaction will be given 100,000 gas plenty enough in many case to succeed. From 9b1c22d2850cc8efb7aabb2aba4098873ed0d5a9 Mon Sep 17 00:00:00 2001 From: Felix Lange Date: Mon, 27 May 2019 14:05:18 +0200 Subject: [PATCH 099/137] Automatically merged updates to draft EIP(s) 778 (#2087) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-778.md | 56 ++++++++++++++++++++++++++----------------------- 1 file changed, 30 insertions(+), 26 deletions(-) diff --git a/EIPS/eip-778.md b/EIPS/eip-778.md index 72d33157f4802..ae64e93da52e0 100644 --- a/EIPS/eip-778.md +++ b/EIPS/eip-778.md @@ -45,6 +45,20 @@ The components of a node record are: A record's signature is made and validated according to an *identity scheme*. The identity scheme is also responsible for deriving a node's address in the DHT. +The keys in key/value pairs can technically be any byte sequence, but ASCII text is +preferred. Keys in the table below have pre-defined meaning. + +| Key | Value | +|:------------|:------------------------------------------| +| `id` | name of identity scheme, e.g. "v4" | +| `secp256k1` | compressed secp256k1 public key, 33 bytes | +| `ip` | IPv4 address, 4 bytes | +| `ip6` | IPv6 address, 16 bytes | +| `tcp` | TCP port, big endian integer | +| `udp` | UDP port, big endian integer | + +All keys except `id` are optional. + ### RLP Encoding The canonical encoding of a node record is an RLP list of `[signature, seq, k, v, ...]`. @@ -57,18 +71,10 @@ Records are signed and encoded as follows: signature = sign(content) record = [signature, seq, k, v, ...] -### Key/Value Pairs +### Text Encoding -The keys in key/value pairs can technically be any byte sequence, but ASCII text is -preferred. The following keys are pre-defined: - -| Key | Value | -|:------------|:------------------------------------------| -| `id` | name of identity scheme, e.g. "v4" | -| `secp256k1` | compressed secp256k1 public key, 33 bytes | -| `ip` | IP address, 4 or 16 bytes | -| `tcp` | TCP port, big endian integer | -| `udp` | UDP port, big endian integer | +The textual form of a node record is the base64 encoding of its RLP representation, +prefixed by `enr:`. ### "v4" Identity Scheme @@ -101,17 +107,23 @@ metadata. # Test Vectors -Example (valid) record: +This is an example record containing the IPv4 address `127.0.0.1` and UDP port `30303`. +The node ID is `a448f24c6d18e575453db13171562b71999873db5b286df957af199ec94617f7`. ```text -f884b8407098ad865b00a582051940cb9cf36836572411a4727878307701 -1599ed5cd16b76f2635f4e234738f30813a89eb9137e3e3df5266e3a1f11 -df72ecf1145ccb9c01826964827634826970847f00000189736563703235 -366b31a103ca634cae0d49acb401d8a4c6b6fe8c55b70d115bf400769cc1 -400f3258cd31388375647082765f +enr:+IS4QHCYrYZbAKWCBRlAy5zzaDZXJBGkcnh4MHcBFZntXNFrdvJjX04jRzjzCBOonrkTfj +499SZuOh8R33Ls8RRcy5wBgmlkgnY0gmlwhH8AAAGJc2VjcDI1NmsxoQPKY0yuDUmstAHYpMa2 +/oxVtw0RW/QAdpzBQA8yWM0xOIN1ZHCCdl8= ``` -The raw RLP structure of this record is: +The record is signed using the "v4" identity scheme using sequence number `1` and this +private key: + +```text +b71c71a67e1177ad4e901695e1b4b9ee17ae16c6668d313eac2f96dbcda3f291 +``` + +The RLP structure of the record is: ```text [ @@ -128,14 +140,6 @@ The raw RLP structure of this record is: ] ``` -The record contains sequence number `1`. - -A v4 enode URL containing the same information (but no signature or sequence number): - -```text -enode://ca634cae0d49acb401d8a4c6b6fe8c55b70d115bf400769cc1400f3258cd31387574077f301b421bc84df7266c44e9e6d569fc56be00812904767bf5ccd1fc7f@127.0.0.1:0?discport=30303 -``` - # Copyright Copyright and related rights waived via CC0. From 638b7400a1dbc0029123f55535ce312d4f8d8bd8 Mon Sep 17 00:00:00 2001 From: Andrew Cooke Date: Mon, 27 May 2019 17:24:13 -0400 Subject: [PATCH 100/137] Automatically merged updates to draft EIP(s) 1155 (#2088) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-1155.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/EIPS/eip-1155.md b/EIPS/eip-1155.md index 24d5ebefea7fb..a4248e35367e0 100644 --- a/EIPS/eip-1155.md +++ b/EIPS/eip-1155.md @@ -311,7 +311,7 @@ To be more explicit about how the standard `safeTransferFrom` and `safeBatchTran * The recipient contract MAY accept an increase of its balance by returning the acceptance magic value `bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)"))` - If the return value is `bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)"))` the transfer MUST be completed or MUST revert if any other conditions are not met for success. * The recipient contract MAY reject an increase of its balance by calling revert. - - If recipient contract throws/reverts the transaction MUST be reverted. + - If the recipient contract throws/reverts the transaction MUST be reverted. * If the return value is anything other than `bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)"))` the transaction MUST be reverted. * `onERC1155Received` (and/or `onERC1155BatchReceived`) MAY be called multiple times in a single transaction and the following requirements must be met: - All callbacks represent mutually exclusive balance changes. @@ -328,7 +328,7 @@ To be more explicit about how the standard `safeTransferFrom` and `safeBatchTran * The recipient contract MAY accept an increase of its balance by returning the acceptance magic value `bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))` - If the return value is `bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))` the transfer MUST be completed or MUST revert if any other conditions are not met for success. * The recipient contract MAY reject an increase of its balance by calling revert. - - If recipient contract throws/reverts the transaction MUST be reverted. + - If the recipient contract throws/reverts the transaction MUST be reverted. * If the return value is anything other than `bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))` the transaction MUST be reverted. * `onERC1155BatchReceived` (and/or `onERC1155Received`) MAY be called multiple times in a single transaction and the following requirements must be met: - All callbacks represent mutually exclusive balance changes. @@ -353,8 +353,8 @@ To be more explicit about how the standard `safeTransferFrom` and `safeBatchTran 3. `myTransferFrom` emits `TransferBatch` with the details of what was transferred from address `_from` to address `_to`. 4. `myTransferFrom` checks if `_to` is a contract address and determines that it is so (if not, then the transfer can be considered successful). 5. `myTransferFrom` calls `onERC1155BatchReceived` on `_to` and it reverts or returns an unknown value (if it had returned `bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))` the transfer can be considered successful). - 6. At this point `myTransferFrom` MAY decide to revert the transaction immediately as receipt of the token(s) was not explicitly accepted by the `onERC1155BatchReceived` function. - 7. If `myTransferFrom` wishes to continue it MUST call `isERC1155TokenReceiver()` on `_to` and if it returns `bytes4(keccak256("isERC1155TokenReceiver()"))` the transaction MUST be reverted, as it is now known to be a valid receiver and the previous acceptance step failed. + 6. At this point `myTransferFrom` SHOULD revert the transaction immediately as receipt of the token(s) was not explicitly accepted by the `onERC1155BatchReceived` function. + 7. If however `myTransferFrom` wishes to continue it MUST call `isERC1155TokenReceiver()` on `_to` and if it returns `bytes4(keccak256("isERC1155TokenReceiver()"))` the transaction MUST be reverted, as it is now known to be a valid receiver and the previous acceptance step failed. 8. If the above call to `isERC1155TokenReceiver()` on `_to` reverts or returns an unknown value the `myTransferFrom` function MAY consider this transfer successful (__NOTE__: this MAY result in unrecoverable tokens if sent to an address that does not expect to receive ERC-1155 tokens). * The above example is not exhaustive but illustrates the major points (and shows that most are shared with `safeTransferFrom` and `safeBatchTransferFrom`): - Balances that are updated MUST have equivalent transfer events emitted. @@ -381,7 +381,7 @@ Order of operation MUST therefore be: *__Note that a pure implementation of a single standard is recommended__* rather than a hybrid solution, but an example of a hybrid ERC-1155/ERC-721 contract is linked in the references section under implementations. -An important consideration is that even if the tokens are sent with another standard's rules the *__1155 transfer events MUST still be emitted.__* This is so the balances can still be determined via events alone as per ERC-1155 standard rules. +An important consideration is that even if the tokens are sent with another standard's rules the *__ERC-1155 transfer events MUST still be emitted.__* This is so the balances can still be determined via events alone as per ERC-1155 standard rules. ### Metadata From 32b82ef63b99eaf86b84a643b3dc2eb391b83684 Mon Sep 17 00:00:00 2001 From: Andrew Cooke Date: Tue, 28 May 2019 17:00:42 -0400 Subject: [PATCH 101/137] Automatically merged updates to draft EIP(s) 1155 (#2089) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-1155.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/EIPS/eip-1155.md b/EIPS/eip-1155.md index a4248e35367e0..75a0e1f411ece 100644 --- a/EIPS/eip-1155.md +++ b/EIPS/eip-1155.md @@ -34,7 +34,7 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S **Smart contracts implementing the ERC-1155 standard MUST implement the `ERC1155` and `ERC165` interfaces.** ```solidity -pragma solidity ^0.5.8; +pragma solidity ^0.5.9; /** @title ERC-1155 Multi Token Standard @@ -151,7 +151,7 @@ interface ERC1155 /* is ERC165 */ { Smart contracts **MUST** implement this interface to accept transfers. See "Safe Transfer Rules" for further detail. ```solidity -pragma solidity ^0.5.8; +pragma solidity ^0.5.9; /** Note: The ERC-165 identifier for this interface is 0x43b236a2. @@ -398,7 +398,7 @@ The following optional extensions can be identified with the (ERC-165 Standard I Changes to the URI MUST emit the `URI` event if the change can be expressed with an event (i.e. it isn't dynamic). If the optional ERC1155Metadata_URI extension is included, the 'uri' function SHOULD be used to retrieve values for which no event was emitted. The function MUST return the same value as the event if it was emitted. ```solidity -pragma solidity ^0.5.8; +pragma solidity ^0.5.9; /** Note: The ERC-165 identifier for this interface is 0x0e89341c. From 622136a5b6619b85e77a49c3ea3c4c4b195006a6 Mon Sep 17 00:00:00 2001 From: Witek Date: Wed, 29 May 2019 19:13:13 -0700 Subject: [PATCH 102/137] Last call for ERC-1155 (#2091) --- EIPS/eip-1155.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-1155.md b/EIPS/eip-1155.md index 75a0e1f411ece..8425440e30c92 100644 --- a/EIPS/eip-1155.md +++ b/EIPS/eip-1155.md @@ -4,8 +4,8 @@ title: ERC-1155 Multi Token Standard author: Witek Radomski , Andrew Cooke , Philippe Castonguay , James Therien , Eric Binet , Ronan Sandford type: Standards Track category: ERC -status: Draft -review-period-end: 2019-03-28 +status: Last Call +review-period-end: 2019-06-12 created: 2018-06-17 discussions-to: https://github.com/ethereum/EIPs/issues/1155 requires: 165 From 96e8093f6ac1e126dc18eb8485b81e369c9b5538 Mon Sep 17 00:00:00 2001 From: cdetrio Date: Thu, 30 May 2019 13:24:17 -0400 Subject: [PATCH 103/137] add EIP for particle gas costs (#2045) * add EIP for fractional gas costs * use EIP number 2045, add references, discussion-to * add EIP-2045 to Istanbul * Formatting * Add ewasm to rationale * Clarify cost reduction examples * Clarify the increase of particles * link to eip-2035, edit for clarity * add reference to eip-2035 * add axic as author * rename title to "particle gas costs", edit ewasm section * fix header --- EIPS/eip-1679.md | 1 + EIPS/eip-2045.md | 121 +++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 122 insertions(+) create mode 100644 EIPS/eip-2045.md diff --git a/EIPS/eip-1679.md b/EIPS/eip-1679.md index c7e99985869ec..83d97df28b700 100644 --- a/EIPS/eip-1679.md +++ b/EIPS/eip-1679.md @@ -63,6 +63,7 @@ This meta-EIP specifies the changes included in the Ethereum hardfork named Ista - requirement of EIP-2031 - [EIP-2031](https://eips.ethereum.org/EIPS/eip-2031): State Rent B - Net transaction counter - [EIP-2035](https://eips.ethereum.org/EIPS/eip-2035): Stateless Clients - Repricing SLOAD and SSTORE to pay for block proofs +- [EIP-2045](https://eips.ethereum.org/EIPS/eip-2045): Particle gas costs for EVM opcodes - [EIP-2046](https://eips.ethereum.org/EIPS/eip-2046): Reduced gas cost for static calls made to precompiles ## Timeline diff --git a/EIPS/eip-2045.md b/EIPS/eip-2045.md new file mode 100644 index 0000000000000..9836b9dbbaa61 --- /dev/null +++ b/EIPS/eip-2045.md @@ -0,0 +1,121 @@ +--- +eip: 2045 +title: Particle gas costs for EVM opcodes +author: Casey Detrio (@cdetrio), Alex Beregszaszi (@axic) +discussions-to: https://ethereum-magicians.org/t/eip-2045-fractional-gas-costs/3311 +status: Draft +type: Standards Track +category: Core +created: 2019-05-17 +--- + +## Abstract +According to recent benchmarks, EVM opcodes for computation (`ADD`, `SUB`, `MUL`, etc.) are generally overpriced relative to opcodes for storage I/O (`SLOAD`, `SSTORE`, etc.). Currently the minimum gas cost is 1 (i.e. one unit of gas), and most computational opcodes have a cost near to 1 (e.g. 3, 5, or 8), so the range in possible cost reduction is limited. A new minimum unit of gas, called a "particle", which is a fraction of 1 gas, would expand the range of gas costs and thus enable reductions below the current minimum. + +## Motivation +The transaction capacity of an Ethereum block is determined by the gas cost of transactions relative to the block gas limit. One way to boost the transaction capacity is to raise the block gas limit. Unfortunately, raising the block gas limit would also increase the rate of state growth, unless the costs of state-expanding storage opcodes (`SSTORE`, `CREATE`, etc.) are simultaneously increased to the same proportion. Increasing the cost of storage opcodes may have adverse side effects, such as shifting the economic assumptions around gas fees of deployed contracts, or possibly breaking invariants in current contract executions (as mentioned in [EIP-2035](https://eips.ethereum.org/EIPS/eip-2035)[1](#eip2035), more research is needed on the potential effects of increasing the cost of storage opcodes). + +Another way to boost the transaction capacity of a block is to reduce the gas cost of transactions. Reducing the gas costs of computational opcodes while keeping the cost of storage opcodes the same, is effectively equivalent to raising the block gas limit and simultaneously increasing the cost of storage opcodes. However, reducing the cost of computational opcodes might avoid the adverse side effects of an increase in cost of storage opcodes (again, more research is needed on this topic). + +Currently, computational opcode costs are already too close to the minimum unit of 1 gas to achieve the large degree of cost reductions that recent benchmarks[2](#evmbenchmarks) indicate would be needed to tune opcode gas costs to the performance of optimized EVM implementations. A smaller minimum unit called a "particle", which is a fraction (or subdivision) of 1 gas, would enable large cost reductions. + +## Specification +A new gas counter `particlesUsed` is added to the EVM, in addition to the existing gas counter `gasUsed`. The unit 1 gas is equal to 10000 particles (`PARTICLES_PER_GAS`). The `particlesUsed` counter is only increased for opcodes priced in particles (i.e. opcodes that cost less than 1 gas). If increasing `particlesUsed` results in an excess of 1 gas, then 1 gas is added to `gasUsed` (and deducted from `particlesUsed`). + +Where the current gas logic looks like this: +``` +def vm_execute(ext, msg, code): + # Initialize stack, memory, program counter, etc + compustate = Compustate(gas=msg.gas) + codelen = len(code) + + while compustate.pc < codelen: + opcode = code[compustate.pc] + compustate.pc += 1 + + compustate.gasUsed += opcode.gas_fee + + # out of gas error + if compustate.gasUsed > compustate.gasLimit: + return vm_exception('OUT OF GAS') + + if op == 'STOP': + return peaceful_exit() + elif op == 'ADD': + stk.append(stk.pop() + stk.pop()) + elif op == 'SUB': + stk.append(stk.pop() - stk.pop()) + elif op == 'MUL': + stk.append(stk.pop() * stk.pop()) + +..... +``` + +The new gas logic using particles might look like this: +``` +PARTICLES_PER_GAS = 10000 + +def vm_execute(ext, msg, code): + # Initialize stack, memory, program counter, etc + compustate = Compustate(gas=msg.gas) + codelen = len(code) + + while compustate.pc < codelen: + opcode = code[compustate.pc] + compustate.pc += 1 + + if opcode.gas_fee: + compustate.gasUsed += opcode.gas_fee + elif opcode.particle_fee: + compustate.particlesUsed += opcode.particle_fee + if compustate.particlesUsed >= PARTICLES_PER_GAS: + # particlesUsed will be between 1 and 2 gas (over 10000 but under 20000) + compustate.gasUsed += 1 + # remainder stays in particle counter + compustate.particlesUsed = compustate.particlesUsed % PARTICLES_PER_GAS + + # out of gas error + if compustate.gasUsed > compustate.gasLimit: + return vm_exception('OUT OF GAS') + + if op == 'STOP': + return peaceful_exit() + elif op == 'ADD': + stk.append(stk.pop() + stk.pop()) + elif op == 'SUB': + stk.append(stk.pop() - stk.pop()) + elif op == 'MUL': + stk.append(stk.pop() * stk.pop()) + +..... +``` + +The above pseudocode is written for clarity. A more performant implementation might instead keep a single `particlesUsed` counter by multiplying opcode gas costs by 10000 and the `gasLimit` by 10000, and convert particles back to gas with `ceil(particlesUsed / PARTICLES_PER_GAS)` at the end of execution. It may also be more performant to use a `PARTICLES_PER_GAS` ratio that is a power of 2 (such as 8192 or 16384) instead of 10000; the spec above is a draft and updates in response to feedback are expected. + +#### Opcode cost changes +Many computational opcodes will undergo a cost reduction, with new costs suggested by benchmark analyses. For example, the cost of `DUP` and `SWAP` are reduced from 3 gas to 3000 particles (i.e. 0.3 gas). The cost of `ADD` and `SUB` are reduced from 3 gas to 6000 particles. The cost of `MUL` is reduced from 5 gas to 5000 particles (i.e. 0.5 gas). + +## Rationale +Adoption of fractional gas costs should only be an implementation detail inside the EVM, and not alter the current user experience around transaction gas limits and block gas limits. The concept of `particles` need not be exposed to Ethereum users nor most contract authors, but only to EVM implementers and contract developers concerned with optimized gas usage. Furthermore, only the EVM logic for charging gas per opcode executed should be affected by this change. All other contexts dealing with gas and gas limits, such as block headers and transaction formats, should be unaffected. + +### Ewasm +The term "particles" was first introduced for Ewasm[3](#particle) to enable gas accounting for low cost wasm instructions, while remaining compatible with EVM gas costs. This EIP proposes introducing particles as a new minimum gas unit for EVM opcodes, and is not related to Ewasm. + +## Backwards Compatibility +This change is not backwards compatible and requires a hard fork to be activated. + +## Test Cases +TODO + +## Implementation +TODO + +## References +1. [EIP-2035](https://eips.ethereum.org/EIPS/eip-2035): Stateless Clients - Repricing SLOAD and SSTORE to pay for block proofs + +2. https://github.com/ewasm/benchmarking + +3. The term "particle" was inspired by a proposal for [Ewasm gas costs](https://github.com/ewasm/design/blob/e77d8e3de42784f40a803a23f58ef06881142d9f/determining_wasm_gas_costs.md). + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 186c1dbbdd6d97315d238f5cb9ef3b0155fab639 Mon Sep 17 00:00:00 2001 From: James Hancock Date: Fri, 31 May 2019 18:41:35 -0400 Subject: [PATCH 104/137] Clarified Specification --- EIPS/eip-131.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/EIPS/eip-131.md b/EIPS/eip-131.md index 0c8f97b41f870..22daa4cffc8f0 100644 --- a/EIPS/eip-131.md +++ b/EIPS/eip-131.md @@ -37,15 +37,17 @@ Adds a precompiled contract for the blake2b hash function. Address of `0x9` -Function accepts a variable length input interpreted as: +Function accepts a variable length input interpreted as an array of bytes: - [OUTSIZE, D_1, D_2, ..., D_INSIZE] + [OUTSIZE, D1, D2, ..., DINSIZE] -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). +where INSIZE is the length in bytes of the input. Throws if the value of 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)` +Gas costs would be equal to `Gblakebase + Gblakeword + floor((INSIZE - 1) / 32)` + +This is not the final equation as this has not yet been adequately benchmarked. Another option is for Gas cost to depend on the value of `OUTSIZE`. Through testing we will identify which is most accurate update accordingly. ## Rationale From 9084f86d63639792e8762d875f301e710ff991e9 Mon Sep 17 00:00:00 2001 From: James Hancock Date: Fri, 31 May 2019 18:42:33 -0400 Subject: [PATCH 105/137] Spelling --- EIPS/eip-131.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-131.md b/EIPS/eip-131.md index 22daa4cffc8f0..f6847a125ba30 100644 --- a/EIPS/eip-131.md +++ b/EIPS/eip-131.md @@ -47,7 +47,7 @@ where INSIZE is the length in bytes of the input. Throws if the value of OUTSIZE Gas costs would be equal to `Gblakebase + Gblakeword + floor((INSIZE - 1) / 32)` -This is not the final equation as this has not yet been adequately benchmarked. Another option is for Gas cost to depend on the value of `OUTSIZE`. Through testing we will identify which is most accurate update accordingly. +This is not the final equation as this has not yet been adequately benchmarked. Another option is for Gas cost to depend on the value of `OUTSIZE`. Through testing we will identify which is most accurate and update accordingly. ## Rationale From 5b3345b2461a5c426202dd67b00dec450f94962f Mon Sep 17 00:00:00 2001 From: James Hancock Date: Fri, 31 May 2019 18:45:01 -0400 Subject: [PATCH 106/137] Removed metropolis block number from params --- EIPS/eip-131.md | 1 - 1 file changed, 1 deletion(-) diff --git a/EIPS/eip-131.md b/EIPS/eip-131.md index f6847a125ba30..0434bbee6f7e0 100644 --- a/EIPS/eip-131.md +++ b/EIPS/eip-131.md @@ -27,7 +27,6 @@ Adding a precompile for the BLAKE2b hashing function will make the operation sig ## Parameters -* `METROPOLIS_FORK_BLKNUM`: TBD * `GBLAKEBASE`: 30 * `GBLAKEWORD`: 6 From 550fb104226f93b646b75a25a93341aac55b26eb Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Sun, 2 Jun 2019 23:57:07 +0100 Subject: [PATCH 107/137] Automatically merged updates to draft EIP(s) 1803 (#2093) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-1803.md | 1 + 1 file changed, 1 insertion(+) diff --git a/EIPS/eip-1803.md b/EIPS/eip-1803.md index 303879c30725e..448ccbcc62d87 100644 --- a/EIPS/eip-1803.md +++ b/EIPS/eip-1803.md @@ -2,6 +2,7 @@ eip: 1803 title: Rename opcodes for clarity author: Alex Beregszaszi (@axic) +discussions-to: https://ethereum-magicians.org/t/eip-1803-rename-opcodes-for-clarity/3345 type: Standards Track category: Interface status: Draft From 5b60eb679b85eaf93895a980e1b3d2ab58310d7d Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Mon, 3 Jun 2019 00:03:07 +0100 Subject: [PATCH 108/137] Automatically merged updates to draft EIP(s) 1803, 663 (#2094) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-663.md | 1 + 1 file changed, 1 insertion(+) diff --git a/EIPS/eip-663.md b/EIPS/eip-663.md index feae741cab8b9..eefa7f6f455cf 100644 --- a/EIPS/eip-663.md +++ b/EIPS/eip-663.md @@ -2,6 +2,7 @@ eip: 663 title: Unlimited SWAP and DUP instructions author: Alex Beregszaszi (@axic) +discussions-to: https://ethereum-magicians.org/t/eip-663-unlimited-swap-and-dup-instructions/3346 type: Standards Track category: Core status: Draft From 36f02dffec3b079065ad68eef74d863c98487e8e Mon Sep 17 00:00:00 2001 From: Samuel Furter Date: Mon, 3 Jun 2019 20:10:13 +0200 Subject: [PATCH 109/137] Automatically merged updates to draft EIP(s) 1193 (#2092) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-1193.md | 78 ++++++------------------------------------------ 1 file changed, 9 insertions(+), 69 deletions(-) diff --git a/EIPS/eip-1193.md b/EIPS/eip-1193.md index 7398f75db8804..e2e51a4827d25 100644 --- a/EIPS/eip-1193.md +++ b/EIPS/eip-1193.md @@ -27,36 +27,19 @@ Promise resolves with `result` or rejects with `Error`. See the [available methods](https://github.com/ethereum/wiki/wiki/JSON-RPC#json-rpc-methods). -#### eth_requestAccounts - -By default, the provider supplied to a new dapp has is a "read-only" provider with no accounts authenticated. See [EIP 1102: Opt-in account exposure](https://eips.ethereum.org/EIPS/eip-1102). - -To request accounts, call `ethereum.send('eth_requestAccounts')`. This will ask the user which account(s) they would like to authenticate to the dapp. - -Promise resolves with an array of the enabled account(s) addresses. - ### Events Events are emitted using [EventEmitter](https://nodejs.org/api/events.html). #### notification -All subscriptions from the node emit on "subscription type" (e.g. `eth_subscription`, or `ssh_subscription`). Attach listeners with: +All subscriptions from the node emit on notification. Attach listeners with: ```js -ethereum.on('eth_subscription', listener: (result: any) => void): this; +ethereum.on('notification', listener: (result: any) => void): this; ``` -To create a subscription, call `ethereum.send('eth_subscribe')` or `ethereum.send('shh_subscribe')`. The subscription object will emit through the specific subscription type. - -The result object will look as follows: - -```js -{ - "subscription":"0xc3b33aa549fb9a60e95d21862596617c", - "result": {...} -} -``` +To create a subscription, call `ethereum.send('eth_subscribe', [])` or `ethereum.send('shh_subscribe', [])`. See the [eth subscription methods](https://github.com/ethereum/go-ethereum/wiki/RPC-PUB-SUB#supported-subscriptions) and [shh subscription methods](https://github.com/ethereum/go-ethereum/wiki/Whisper-v6-RPC-API#shh_subscribe). @@ -112,6 +95,7 @@ const ethereum = window.ethereum; // A) Set provider in web3.js var web3 = new Web3(ethereum); +// web3.eth.getBlock('latest', true).then(...) // B) Use provider object directly @@ -128,26 +112,7 @@ ethereum ); }); - -// Example 2: Request accounts -ethereum - .send('eth_requestAccounts') - .then(accounts => { - if (accounts.length > 0) { - console.log(`Accounts enabled:\n${accounts.join('\n')}`); - } else { - console.error(`No accounts enabled.`); - } - }) - .catch(error => { - console.error( - `Error requesting accounts: ${error.message}. - Code: ${error.code}. Data: ${error.data}` - ); - }); - - -// Example 3: Log available accounts +// Example 2: Log available accounts ethereum .send('eth_accounts') .then(accounts => { @@ -161,13 +126,13 @@ ethereum }); -// Example 4: Log new blocks +// Example 3: Log new blocks let subId; ethereum .send('eth_subscribe', ['newHeads']) .then(subscriptionId => { subId = subscriptionId; - ethereum.on('eth_subscription', result => { + ethereum.on('notification', result => { if (result.subscription === subscriptionId) { if (result.result instanceof Error) { const error = result.result; @@ -188,22 +153,9 @@ ethereum Code: ${error.code}. Data: ${error.data}` ); }); - -// to unsubscribe -ethereum - .send('eth_unsubscribe', [subId]) - .then(result => { - console.log(`Unsubscribed newHeads subscription ${subId}`); - }) - .catch(error => { - console.error( - `Error unsubscribing newHeads subscription: ${error.message}. - Code: ${error.code}. Data: ${error.data}` - ); - }); -// Example 5: Log when accounts change +// Example 4: Log when accounts change const logAccounts = accounts => { console.log(`Accounts:\n${accounts.join('\n')}`); }; @@ -211,7 +163,7 @@ ethereum.on('accountsChanged', logAccounts); // to unsubscribe ethereum.removeListener('accountsChanged', logAccounts); -// Example 6: Log if connection ends +// Example 5: Log if connection ends ethereum.on('close', (code, reason) => { console.log(`Ethereum provider connection closed: ${reason}. Code: ${code}`); }); @@ -227,18 +179,6 @@ If an error occurs during processing, such as an HTTP error or internal parsing If the request requires an account that is not yet authenticated, the Promise **MUST** reject with Error code 4100. -#### eth_requestAccounts - -The provider supplied to a new dapp **MUST** be a "read-only" provider: authenticating no accounts by default, returning a blank array for `eth_accounts`, and rejecting any methods that require an account with Error code `4100`. - -If the dapp has been previously authenticated and remembered by the user, then the provider supplied on load **MAY** automatically be enabled with the previously authenticated accounts. - -If no accounts are authenticated, the `eth_requestAccounts` method **MUST** ask the user which account(s) they would like to authenticate to the dapp. If the request has been previously granted and remembered, the `eth_requestAccounts` method **MAY** immediately return. - -The `eth_requestAccounts` method **MUST** resolve with an array of the account(s) addresses or reject with an `Error`. If the account(s) enabled by the provider change, the `accountsChanged` event **MUST** also emit. - -For full specification of the `eth_requestAccounts` RPC method, see [EIP 1102: Opt-in account exposure](https://eips.ethereum.org/EIPS/eip-1102). - ### Events The provider **SHOULD** extend from `EventEmitter` to provide dapps flexibility in listening to events. In place of full `EventEmitter` functionality, the provider **MAY** provide as many methods as it can reasonably provide, but **MUST** provide at least `on`, `emit`, and `removeListener`. From f1df38707b6c8b3779fcf7a2789c38e88121ac22 Mon Sep 17 00:00:00 2001 From: Andrew Cooke Date: Tue, 4 Jun 2019 13:59:39 -0400 Subject: [PATCH 110/137] Automatically merged updates to draft EIP(s) 1155 (#2096) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-1155.md | 51 +++++++++++++++++++++++++++++++++++------------- 1 file changed, 37 insertions(+), 14 deletions(-) diff --git a/EIPS/eip-1155.md b/EIPS/eip-1155.md index 8425440e30c92..56ed85b5ed34c 100644 --- a/EIPS/eip-1155.md +++ b/EIPS/eip-1155.md @@ -148,7 +148,7 @@ interface ERC1155 /* is ERC165 */ { ### ERC-1155 Token Receiver -Smart contracts **MUST** implement this interface to accept transfers. See "Safe Transfer Rules" for further detail. +Smart contracts **MUST** implement all the functions in this interface to accept transfers. See "Safe Transfer Rules" for further detail. ```solidity pragma solidity ^0.5.9; @@ -283,8 +283,8 @@ To be more explicit about how the standard `safeTransferFrom` and `safeBatchTran - The `_to` argument MUST be the address of the recipient whose balance is increased. - The `_id` argument MUST be the token type being transferred. - The `_value` argument MUST be the number of tokens the holder balance is decreased by and match what the recipient balance is increased by. - - When minting/creating tokens, the `_from` argument MUST be set to `0x0` (i.e. zero address). - - When burning/destroying tokens, the `_to` argument MUST be set to `0x0` (i.e. zero address). + - When minting/creating tokens, the `_from` argument MUST be set to `0x0` (i.e. zero address). See "Minting/creating and burning/destroying rules". + - When burning/destroying tokens, the `_to` argument MUST be set to `0x0` (i.e. zero address). See "Minting/creating and burning/destroying rules". * `TransferBatch` SHOULD be used to indicate multiple balance transfers have occurred between a `_from` and `_to` pair. - It MAY be emitted with a single element in the list to indicate a singular balance change in the transaction, but note that `TransferSingle` is designed for this to reduce gas consumption. - The `_operator` argument MUST be the address of an account/contract that is approved to make the transfer (SHOULD be msg.sender). @@ -293,9 +293,9 @@ To be more explicit about how the standard `safeTransferFrom` and `safeBatchTran - The `_ids` array argument MUST contain the ids of the tokens being transferred. - The `_values` array argument MUST contain the number of token to be transferred for each corresponding entry in `_ids`. - `_ids` and `_values` MUST have the same length. - - When minting/creating tokens, the `_from` argument MUST be set to `0x0` (i.e. zero address). - - When burning/destroying tokens, the `_to` argument MUST be set to `0x0` (i.e. zero address). -* The total value transferred from address 0x0 minus the total value transferred to 0x0 MAY be used by clients and exchanges to be added to the "circulating supply" for a given token ID. + - When minting/creating tokens, the `_from` argument MUST be set to `0x0` (i.e. zero address). See "Minting/creating and burning/destroying rules". + - When burning/destroying tokens, the `_to` argument MUST be set to `0x0` (i.e. zero address). See "Minting/creating and burning/destroying rules". +* The total value transferred from address `0x0` minus the total value transferred to `0x0` observed via the `TransferSingle` and `TransferBatch` events MAY be used by clients and exchanges to determine the "circulating supply" for a given token ID. * To broadcast the existence of a token ID with no initial balance, the contract SHOULD emit the `TransferSingle` event from `0x0` to `0x0`, with the token creator as `_operator`, and a `_value` of 0. * All `TransferSingle` and `TransferBatch` events MUST be emitted to reflect all the balance changes that have occurred before any call(s) to `onERC1155Received` or `onERC1155BatchReceived`. - To make sure event order is correct in the case of valid re-entry (e.g. if a receiver contract forwards tokens on receipt) state balance and events balance MUST match before calling an external contract. @@ -316,6 +316,7 @@ To be more explicit about how the standard `safeTransferFrom` and `safeBatchTran * `onERC1155Received` (and/or `onERC1155BatchReceived`) MAY be called multiple times in a single transaction and the following requirements must be met: - All callbacks represent mutually exclusive balance changes. - The set of all calls to `onERC1155Received` and `onERC1155BatchReceived` describes all balance changes that occurred during the transaction in the order submitted. +* A contract MAY skip calling the `onERC1155Received` hook function if the transfer operation is transferring the token to itself. **_onERC1155BatchReceived rules:_** - The `_operator` argument MUST be the address of an account/contract that is approved to make the transfer (SHOULD be msg.sender). @@ -333,6 +334,7 @@ To be more explicit about how the standard `safeTransferFrom` and `safeBatchTran * `onERC1155BatchReceived` (and/or `onERC1155Received`) MAY be called multiple times in a single transaction and the following requirements must be met: - All callbacks represent mutually exclusive balance changes. - The set of all calls to `onERC1155Received` and `onERC1155BatchReceived` describes all balance changes that occurred during the transaction in the order submitted. +* A contract MAY skip calling the `onERC1155BatchReceived` hook function if the transfer operation is transferring the token(s) to itself. **_isERC1155TokenReceiver rules:_** * The implementation of `isERC1155TokenReceiver` function SHOULD be as follows: @@ -354,8 +356,10 @@ To be more explicit about how the standard `safeTransferFrom` and `safeBatchTran 4. `myTransferFrom` checks if `_to` is a contract address and determines that it is so (if not, then the transfer can be considered successful). 5. `myTransferFrom` calls `onERC1155BatchReceived` on `_to` and it reverts or returns an unknown value (if it had returned `bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))` the transfer can be considered successful). 6. At this point `myTransferFrom` SHOULD revert the transaction immediately as receipt of the token(s) was not explicitly accepted by the `onERC1155BatchReceived` function. - 7. If however `myTransferFrom` wishes to continue it MUST call `isERC1155TokenReceiver()` on `_to` and if it returns `bytes4(keccak256("isERC1155TokenReceiver()"))` the transaction MUST be reverted, as it is now known to be a valid receiver and the previous acceptance step failed. - 8. If the above call to `isERC1155TokenReceiver()` on `_to` reverts or returns an unknown value the `myTransferFrom` function MAY consider this transfer successful (__NOTE__: this MAY result in unrecoverable tokens if sent to an address that does not expect to receive ERC-1155 tokens). + 7. If however `myTransferFrom` wishes to continue it MUST call `isERC1155TokenReceiver()` on `_to` and if it returns `bytes4(keccak256("isERC1155TokenReceiver()"))` the transaction MUST be reverted, as it is now known to be a valid receiver and the previous acceptance step failed. + - NOTE: You could have called `isERC1155TokenReceiver()` at a previous step if you wanted to gather and act upon that information earlier, such as in a hybrid standards scenario. + 8. If the above call to `isERC1155TokenReceiver()` on `_to` reverts or returns an unknown value the `myTransferFrom` function MAY consider this transfer successful. + - __NOTE__: this MAY result in unrecoverable tokens if sent to an address that does not expect to receive ERC-1155 tokens. * The above example is not exhaustive but illustrates the major points (and shows that most are shared with `safeTransferFrom` and `safeBatchTransferFrom`): - Balances that are updated MUST have equivalent transfer events emitted. - A receiver address has to be checked if it is a contract and if so relevant `ERC1155TokenReceiver` hook function(s) have to be called on it. @@ -363,6 +367,20 @@ To be more explicit about how the standard `safeTransferFrom` and `safeBatchTran - The return values of the `ERC1155TokenReceiver` hook functions that are called MUST be respected if they are implemented. - Only non-standard transfer functions MAY allow tokens to be sent to a recipient contract that does NOT implement the necessary `ERC1155TokenReceiver` hook functions. `safeTransferFrom` and `safeBatchTransferFrom` MUST revert in that case (unless it is a hybrid standards implementation see "Compatibility with other standards"). +**_Minting/creating and burning/destroying rules:_** +* A mint/create operation is essentially a specialized transfer and MUST follow these rules: + - To broadcast the existence of a token ID with no initial balance, the contract SHOULD emit the `TransferSingle` event from `0x0` to `0x0`, with the token creator as `_operator`, and a `_value` of 0. + - The "TransferSingle and TransferBatch event rules" MUST be followed as appropriate for the mint(s) (i.e. singles or batches) however the `_from` argument MUST be set to `0x0` (i.e. zero address) to flag the transfer as a mint to contract observers. + - __NOTE:__ This includes tokens that are given an initial balance in the contract. The balance of the contract MUST also be able to be determined by events alone meaning initial contract balances (for eg. in construction) MUST emit events to reflect those balances too. + +* A burn/destroy operation is essentially a specialized transfer and MUST follow these rules: + - The "TransferSingle and TransferBatch event rules" MUST be followed as appropriate for the burn(s) (i.e. singles or batches) however the `_to` argument MUST be set to `0x0` (i.e. zero address) to flag the transfer as a burn to contract observers. + - NOTE: When burning/destroying you do not have to actually transfer to `0x0` (that is impl specific), only the `_to` argument in the event MUST be set to `0x0` as above. +* The total value transferred from address `0x0` minus the total value transferred to `0x0` observed via the `TransferSingle` and `TransferBatch` events MAY be used by clients and exchanges to determine the "circulating supply" for a given token ID. +* As mentioned above mint/create and burn/destroy operations are specialized transfers and so will likely be accomplished with a custom transfer functions rather than `safeTransferFrom` or `safeBatchTransferFrom`. If so the "Implementation specific transfer API rules" section would be appropriate. + - Even in a non-safe API and/or hybrid standards case the above event rules MUST still be adhered to when minting/creating or burning/destroying. +* A contract MAY skip calling the `ERC1155TokenReceiver` hook function(s) if the mint/create operation is transferring the token(s) to itself. In all other cases the `ERC1155TokenReceiver` rules MUST be followed as appropriate for the implementation (i.e. safe, custom and/or hybrid). + ###### A solidity example of the keccak256 generated constants for the return magic is: - bytes4 constant public ERC1155_ACCEPTED = 0xf23a6e61; // bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)")) @@ -386,10 +404,12 @@ An important consideration is that even if the tokens are sent with another stan ### Metadata -The URI value allows for ID substitution by clients. If the string `{id}` exists in any URI, clients MUST replace this with the actual token ID in hexadecimal form. This allows for large number of tokens to use the same on-chain string by defining a URI once, for a large collection of tokens. Example of such a URI: `https://token-cdn-domain/{id}.json` would be replaced with `https://token-cdn-domain/000000000000000000000000000000000000000000000000000000000004cce0.json` if the client is referring to token ID 314592/0x4CCE0. +The URI value allows for ID substitution by clients. If the string `{id}` exists in any URI, clients MUST replace this with the actual token ID in hexadecimal form. This allows for large number of tokens to use the same on-chain string by defining a URI once, for a large collection of tokens. + +* The string format of the substituted hexadecimal ID MUST be lowercase alphanumeric: `[0-9a-f]` with no 0x prefix. +* The string format of the substituted hexadecimal ID MUST be leading zero padded to 64 hex characters length if necessary. -The string format of the substituted hexadecimal ID MUST be lowercase alphanumeric: `[0-9a-f]` with no 0x prefix. -The string format of the substituted hexadecimal ID MUST be leading zero padded to 64 hex characters length if necessary. +Example of such a URI: `https://token-cdn-domain/{id}.json` would be replaced with `https://token-cdn-domain/000000000000000000000000000000000000000000000000000000000004cce0.json` if the client is referring to token ID 314592/0x4CCE0. #### Metadata Extensions @@ -418,7 +438,8 @@ interface ERC1155Metadata_URI { This JSON schema is loosely based on the "ERC721 Metadata JSON Schema", but includes optional formatting to allow for ID substitution by clients. If the string `{id}` exists in any JSON value, it MUST be replaced with the actual token ID, by all client software that follows this standard. -The string format of the substituted hexadecimal ID MUST be lowercase alphanumeric: `[0-9a-f]` with no 0x prefix. +* The string format of the substituted hexadecimal ID MUST be lowercase alphanumeric: `[0-9a-f]` with no 0x prefix. +* The string format of the substituted hexadecimal ID MUST be leading zero padded to 64 hex characters length if necessary. ```json { @@ -605,13 +626,15 @@ This standard can be used to represent multiple token types for an entire domain ### Batch Transfers -The `safeBatchTransferFrom` function allows for batch transfers of multiple token ids and values. The design of ERC-1155 makes batch transfers possible without the need for a wrapper contract, as with existing token standards. This reduces gas costs when more than one token type is included in a batch transfer, as compared to single transfers with multiple transactions. +The `safeBatchTransferFrom` function allows for batch transfers of multiple token IDs and values. The design of ERC-1155 makes batch transfers possible without the need for a wrapper contract, as with existing token standards. This reduces gas costs when more than one token type is included in a batch transfer, as compared to single transfers with multiple transactions. Another advantage of standardized batch transfers is the ability for a smart contract to respond to the batch transfer in a single operation using `onERC1155BatchReceived`. +It is RECOMMENDED that clients and wallets sort the token IDs and associated values (in ascending order) when posting a batch transfer, as some ERC-1155 implementations offer significant gas cost savings when IDs are sorted. See [Horizon Games - Multi-Token Standard](https://github.com/horizon-games/multi-token-standard) "packed balance" implementation for an example of this. + ### Batch Balance -The `balanceOfBatch` function allows clients to retrieve balances of multiple owners and token ids with a single call. +The `balanceOfBatch` function allows clients to retrieve balances of multiple owners and token IDs with a single call. ### Enumerating from events From 5a0665ca9cece6172087fe9eadcfd1c6d22ba9c9 Mon Sep 17 00:00:00 2001 From: Felix Lange Date: Tue, 4 Jun 2019 20:47:14 +0200 Subject: [PATCH 111/137] Automatically merged updates to draft EIP(s) 778 (#2097) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-778.md | 56 ++++++++++++++++++++++++++++++------------------- 1 file changed, 35 insertions(+), 21 deletions(-) diff --git a/EIPS/eip-778.md b/EIPS/eip-778.md index ae64e93da52e0..b0976c8784a74 100644 --- a/EIPS/eip-778.md +++ b/EIPS/eip-778.md @@ -39,25 +39,31 @@ The components of a node record are: - `signature`: cryptographic signature of record contents - `seq`: The sequence number, a 64-bit unsigned integer. Nodes should increase the number whenever the record changes and republish the record. -- The remainder of the record consists of arbitrary key/value pairs, which must be sorted - by key. Keys must be unique. +- The remainder of the record consists of arbitrary key/value pairs A record's signature is made and validated according to an *identity scheme*. The identity scheme is also responsible for deriving a node's address in the DHT. -The keys in key/value pairs can technically be any byte sequence, but ASCII text is -preferred. Keys in the table below have pre-defined meaning. - -| Key | Value | -|:------------|:------------------------------------------| -| `id` | name of identity scheme, e.g. "v4" | -| `secp256k1` | compressed secp256k1 public key, 33 bytes | -| `ip` | IPv4 address, 4 bytes | -| `ip6` | IPv6 address, 16 bytes | -| `tcp` | TCP port, big endian integer | -| `udp` | UDP port, big endian integer | - -All keys except `id` are optional. +The key/value pairs must be sorted by key and must be unique, i.e. any key may be present +only once. The keys can technically be any byte sequence, but ASCII text is preferred. Key +names in the table below have pre-defined meaning. + +| Key | Value | +|:------------|:-------------------------------------------| +| `id` | name of identity scheme, e.g. "v4" | +| `secp256k1` | compressed secp256k1 public key, 33 bytes | +| `ip` | IPv4 address, 4 bytes | +| `tcp` | TCP port, big endian integer | +| `udp` | UDP port, big endian integer | +| `ip6` | IPv6 address, 16 bytes | +| `tcp6` | IPv6-specific TCP port, big endian integer | +| `udp6` | IPv6-specific UDP port, big endian integer | + +All keys except `id` are optional, including IP addresses and ports. A record without +endpoint information is still valid as long as its signature is valid. If no `tcp6` / +`udp6` port is provided, the `tcp` / `udp` port applies to both IP addresses. Declaring +the same port number in both `tcp`, `tcp6` or `udp`, `udp6` should be avoided but doesn't +render the record invalid. ### RLP Encoding @@ -74,12 +80,14 @@ Records are signed and encoded as follows: ### Text Encoding The textual form of a node record is the base64 encoding of its RLP representation, -prefixed by `enr:`. +prefixed by `enr:`. Implementations should use the [URL-safe base64 alphabet][base64url] +and omit padding characters. ### "v4" Identity Scheme -This specification defines a single scheme to be used as the default. The "v4" scheme is -backwards-compatible with the cryptosystem used by Node Discovery v4. +This specification defines a single identity scheme to be used as the default until other +schemes are defined by further EIPs. The "v4" scheme is backwards-compatible with the +cryptosystem used by Node Discovery v4. - To sign record `content` with this scheme, apply the keccak256 hash function (as used by the EVM) to `content`, then create a signature of the hash. The resulting 64-byte @@ -105,15 +113,19 @@ in size-constrained protocols such as DNS. A record containing a IPv4 address, w using the "v4" scheme occupies roughly 120 bytes, leaving plenty of room for additional metadata. +You might wonder about the need for so many pre-defined keys related to IP addresses and +ports. This need arises because residential and mobile network setups often put IPv4 +behind NAT while IPv6 traffic—if supported—is directly routed to the same host. Declaring +both address types ensures a node is reachable from IPv4-only locations and those +supporting both protocols. + # Test Vectors This is an example record containing the IPv4 address `127.0.0.1` and UDP port `30303`. The node ID is `a448f24c6d18e575453db13171562b71999873db5b286df957af199ec94617f7`. ```text -enr:+IS4QHCYrYZbAKWCBRlAy5zzaDZXJBGkcnh4MHcBFZntXNFrdvJjX04jRzjzCBOonrkTfj -499SZuOh8R33Ls8RRcy5wBgmlkgnY0gmlwhH8AAAGJc2VjcDI1NmsxoQPKY0yuDUmstAHYpMa2 -/oxVtw0RW/QAdpzBQA8yWM0xOIN1ZHCCdl8= +enr:-IS4QHCYrYZbAKWCBRlAy5zzaDZXJBGkcnh4MHcBFZntXNFrdvJjX04jRzjzCBOonrkTfj499SZuOh8R33Ls8RRcy5wBgmlkgnY0gmlwhH8AAAGJc2VjcDI1NmsxoQPKY0yuDUmstAHYpMa2_oxVtw0RW_QAdpzBQA8yWM0xOIN1ZHCCdl8 ``` The record is signed using the "v4" identity scheme using sequence number `1` and this @@ -143,3 +155,5 @@ The RLP structure of the record is: # Copyright Copyright and related rights waived via CC0. + +[base64url]: https://tools.ietf.org/html/rfc4648#section-5 From 9a35c0afc000850d92980e93cae2e7f54564155d Mon Sep 17 00:00:00 2001 From: Andrew Cooke Date: Wed, 5 Jun 2019 16:52:26 -0400 Subject: [PATCH 112/137] Automatically merged updates to draft EIP(s) 1155 (#2101) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-1155.md | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/EIPS/eip-1155.md b/EIPS/eip-1155.md index 56ed85b5ed34c..977c9f48c5c5b 100644 --- a/EIPS/eip-1155.md +++ b/EIPS/eip-1155.md @@ -74,7 +74,7 @@ interface ERC1155 /* is ERC165 */ { /** @dev MUST emit when the URI is updated for a token ID. URIs are defined in RFC 3986. - The URI MUST point a JSON file that conforms to the "ERC-1155 Metadata URI JSON Schema". + The URI MUST point to a JSON file that conforms to the "ERC-1155 Metadata URI JSON Schema". */ event URI(string _value, uint256 indexed _id); @@ -371,13 +371,12 @@ To be more explicit about how the standard `safeTransferFrom` and `safeBatchTran * A mint/create operation is essentially a specialized transfer and MUST follow these rules: - To broadcast the existence of a token ID with no initial balance, the contract SHOULD emit the `TransferSingle` event from `0x0` to `0x0`, with the token creator as `_operator`, and a `_value` of 0. - The "TransferSingle and TransferBatch event rules" MUST be followed as appropriate for the mint(s) (i.e. singles or batches) however the `_from` argument MUST be set to `0x0` (i.e. zero address) to flag the transfer as a mint to contract observers. - - __NOTE:__ This includes tokens that are given an initial balance in the contract. The balance of the contract MUST also be able to be determined by events alone meaning initial contract balances (for eg. in construction) MUST emit events to reflect those balances too. - + - __NOTE:__ This includes tokens that are given an initial balance in the contract. The balance of the contract MUST also be able to be determined by events alone meaning initial contract balances (for eg. in construction) MUST emit events to reflect those balances too. * A burn/destroy operation is essentially a specialized transfer and MUST follow these rules: - The "TransferSingle and TransferBatch event rules" MUST be followed as appropriate for the burn(s) (i.e. singles or batches) however the `_to` argument MUST be set to `0x0` (i.e. zero address) to flag the transfer as a burn to contract observers. - - NOTE: When burning/destroying you do not have to actually transfer to `0x0` (that is impl specific), only the `_to` argument in the event MUST be set to `0x0` as above. + - When burning/destroying you do not have to actually transfer to `0x0` (that is impl specific), only the `_to` argument in the event MUST be set to `0x0` as above. * The total value transferred from address `0x0` minus the total value transferred to `0x0` observed via the `TransferSingle` and `TransferBatch` events MAY be used by clients and exchanges to determine the "circulating supply" for a given token ID. -* As mentioned above mint/create and burn/destroy operations are specialized transfers and so will likely be accomplished with a custom transfer functions rather than `safeTransferFrom` or `safeBatchTransferFrom`. If so the "Implementation specific transfer API rules" section would be appropriate. +* As mentioned above mint/create and burn/destroy operations are specialized transfers and so will likely be accomplished with custom transfer functions rather than `safeTransferFrom` or `safeBatchTransferFrom`. If so the "Implementation specific transfer API rules" section would be appropriate. - Even in a non-safe API and/or hybrid standards case the above event rules MUST still be adhered to when minting/creating or burning/destroying. * A contract MAY skip calling the `ERC1155TokenReceiver` hook function(s) if the mint/create operation is transferring the token(s) to itself. In all other cases the `ERC1155TokenReceiver` rules MUST be followed as appropriate for the implementation (i.e. safe, custom and/or hybrid). @@ -415,7 +414,7 @@ Example of such a URI: `https://token-cdn-domain/{id}.json` would be replaced wi The following optional extensions can be identified with the (ERC-165 Standard Interface Detection)[https://eips.ethereum.org/EIPS/eip-165]. -Changes to the URI MUST emit the `URI` event if the change can be expressed with an event (i.e. it isn't dynamic). If the optional ERC1155Metadata_URI extension is included, the 'uri' function SHOULD be used to retrieve values for which no event was emitted. The function MUST return the same value as the event if it was emitted. +Changes to the URI MUST emit the `URI` event if the change can be expressed with an event (i.e. it isn't dynamic). If the optional ERC1155Metadata_URI extension is included, the `uri` function SHOULD be used to retrieve values for which no event was emitted. The function MUST return the same value as the event if it was emitted. ```solidity pragma solidity ^0.5.9; @@ -427,7 +426,7 @@ interface ERC1155Metadata_URI { /** @notice A distinct Uniform Resource Identifier (URI) for a given token. @dev URIs are defined in RFC 3986. - The URI may point to a JSON file that conforms to the "ERC-1155 Metadata URI JSON Schema". + The URI MUST point to a JSON file that conforms to the "ERC-1155 Metadata URI JSON Schema". @return URI string */ function uri(uint256 _id) external view returns (string memory); From e3c2db13b5ee2a65cfef1782ecfcda622b468956 Mon Sep 17 00:00:00 2001 From: Lucas Cullen Date: Thu, 6 Jun 2019 15:59:45 +1000 Subject: [PATCH 113/137] Automatically merged updates to draft EIP(s) 1261 (#2102) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-1261.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-1261.md b/EIPS/eip-1261.md index 75dd50da28c7f..732faeabeb2dc 100644 --- a/EIPS/eip-1261.md +++ b/EIPS/eip-1261.md @@ -25,7 +25,7 @@ We considered use cases of MVTs being assigned to individuals which are non-tran - Investor permissioning: Making regulatory compliance a simple on chain process. Tokenization of securities, that are streamlined to flow only to accredited addresses, tracing and certifying on chain addresses for AML purposes. - Software licencing: Software companies like game developers can use the protocol to authorize certain hardware units(consoles) to download and use specific software(games) -In general, an individual can have different memberships in his day to day life. The protocol allows for the creation of software that puts everything all at one place. His identity can be verified instantly. Imagine a world where you don't need to carry a wallet full of identity cards (Passport, gym membership, SSN, Company ID etc) and organizations can easily keep track of all its members. Organizations can easily identify and disallow fake identities. +In general, an individual can have different memberships in their day to day life. The protocol allows for the creation of software that puts everything all at one place. Their identity can be verified instantly. Imagine a world where you don't need to carry a wallet full of identity cards (Passport, gym membership, SSN, Company ID etc) and organizations can easily keep track of all its members. Organizations can easily identify and disallow fake identities. Attributes are a huge part of ERC-1261 which help to store identifiable information regarding its members. Polls can make use of attributes to calculate the voterbase. E.g: Users should belong to USA entity and not belong to Washington state attribute to be a part of a poll. @@ -43,7 +43,7 @@ Because a person is not necessitated to have EXACTLY one of the elements. He or ## Motivation -A standard interface allows any user,applications to work with any MVT on Ethereum. We provide for simple ERC-1261 smart contracts. Additional applications are discussed below. +A standard interface allows any user, applications to work with any MVT on Ethereum. We provide for simple ERC-1261 smart contracts. Additional applications are discussed below. This standard is inspired from the fact that voting on the blockchain is done with token balance weights. This has been greatly detrimental to the formation of flexible governance systems on the blockchain, despite the tremendous governance potential that blockchains offer. The idea was to create a permissioning system that allows organizations to vet people once into the organization on the blockchain, and then gain immense flexibility in the kind of governance that can be carried out. From 95dfa3441a62d94c4271d9e8e54714e132709728 Mon Sep 17 00:00:00 2001 From: Peter Grassberger Date: Thu, 6 Jun 2019 14:16:05 +0200 Subject: [PATCH 114/137] fix typo: "as follows" (#2099) see: https://ell.stackexchange.com/a/31673 --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 3d0d63066ec1b..4993f82759437 100644 --- a/README.md +++ b/README.md @@ -12,7 +12,7 @@ A browsable version of all current and draft EIPs can be found on [the official Your first PR should be a first draft of the final EIP. It must meet the formatting criteria enforced by the build (largely, correct metadata in the header). An editor will manually review the first PR for a new EIP and assign it a number before merging it. Make sure you include a `discussions-to` header with the URL to a discussion forum or open GitHub issue where people can discuss the EIP as a whole. -If your EIP requires images, the image files should be included in a subdirectory of the `assets` folder for that EIP as follow: `assets/eip-X` (for eip **X**). When linking to an image in the EIP, use relative links such as `../assets/eip-X/image.png`. +If your EIP requires images, the image files should be included in a subdirectory of the `assets` folder for that EIP as follows: `assets/eip-X` (for eip **X**). When linking to an image in the EIP, use relative links such as `../assets/eip-X/image.png`. Once your first PR is merged, we have a bot that helps out by automatically merging PRs to draft EIPs. For this to work, it has to be able to tell that you own the draft being edited. Make sure that the 'author' line of your EIP contains either your Github username or your email address inside . If you use your email address, that address must be the one publicly shown on [your GitHub profile](https://github.com/settings/profile). From 296ba62c5f7b9451c831a88ccb3ac0890ec09997 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Pawe=C5=82=20Bylica?= Date: Thu, 6 Jun 2019 23:58:50 +0200 Subject: [PATCH 115/137] EIP-2003 - EVMC modules for implementations of precompiled contracts (#2003) --- EIPS/eip-2003.md | 134 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 134 insertions(+) create mode 100644 EIPS/eip-2003.md diff --git a/EIPS/eip-2003.md b/EIPS/eip-2003.md new file mode 100644 index 0000000000000..08786e9e81561 --- /dev/null +++ b/EIPS/eip-2003.md @@ -0,0 +1,134 @@ +--- +eip: 2003 +title: EVMC modules for implementations of precompiled contracts +author: Paweł Bylica (@chfast), Alex Beregszaszi (@axic) +discussions-to: https://github.com/ethereum/evmc/issues/259 +status: Draft +type: Informational +created: 2019-05-09 +requires: 1352 +--- + +## Abstract + +[EVMC] specifies a generic API for Ethereum execution engines. +This EIP specifies a way of providing implementations of Ethereum precompiled contracts +using the [EVMC VM API]. + + +## Specification + +For the complete [EVMC] specification visit the [EVMC documentation] first. +This EIP is based on and is compatible with EVMC ABI version 6. + +The EVMC module with implementations of precompiled contracts SHOULD: + +1. Advertise the [`EVMC_CAPABILITY_PRECOMPILES`] capability + in the [`get_capabilities()`] method. + +2. Implement the [`execute()`] method in the following way: + + 1. Validate the incoming execution request requirements: + + 1. The message kind ([`evmc_message::kind`]) is a call ([`EVMC_CALL`]). + + 2. The call destination address ([`evmc_message::destination`]) + is within the range of precompiled contracts defined by [EIP-1352]. + + 3. There is no code provided (the `code` argument is `NULL` and `code_size` argument is `0`). + + If the requirements are not fulfilled, abort execution with the [`EVMC_REJECTED`] status code. + + 2. Check if the call destination address ([`evmc_message::destination`]) + targets existing precompiled contract. + Consider the EVM revision ([`evmc_revision`]) requested by + the `rev` parameter of [`execute()`]. + + If yes, execute as follows: + + 1. Inspect the input data ([`evmc_message::input_data`], [`evmc_message::input_size`]) + and calculate the _gas cost_ of the execution. + + 2. Compute the amount of _gas left_ after execution by + subtracting the _gas cost_ from the call gas limit ([`evmc_message::gas`]). + + 3. If _gas left_ is negative, + abort execution with the [`EVMC_OUT_OF_GAS`] status code. + + 4. Otherwise, + execute the code of the precompiled contract, + return the [`EVMC_SUCCESS`] status code, the output and _gas left_ + ([`evmc_result::output_data`], [`evmc_result::output_size`], [`evmc_result::gas_left`]). + + 3. Otherwise, emulate execution of empty code by returning + the [`EVMC_SUCCESS`] status code + and _gas left_ equal the call gas limit ([`evmc_message::gas`]). + +Precompiled contract implementations are allowed to return two more EVMC error codes: +- [`EVMC_FAILURE`] if the failure was caused due to something other than out of gas (e.g. input validation error) +- [`EVMC_REVERT`] if the precompile doesn't want to forfeit all supplied gas (as of May 2019 no such precompile exists) + +The Client is not required to provide the Host interface ([`evmc_context`] argument of [`execute()`] is set to NULL). +Therefore, the precompiled contracts implementation MUST NOT access the `evmc_context`. + + +## Rationale + +It is very unlikely that any precompile will need to access or modify a contract state. +Not requiring the Client to implement the EVMC Host interface removes the big portion of work +needed for full EVMC integration. + + +## Test Cases + +EVMC provides the [evmc-vmtester] tool for checking compatibility with the EVMC specification. + + +## Implementations + +- [Example of Precompiles VM implementation][example_precompiles_vm.cpp] +- [ewasm precompiles] +- Aleth code for precompiles +- Parity code for precompiles +- [EIP-1962 implemented as an EVMC precompile module](https://github.com/axic/eip1962-evmc) + + +## References + +- [EVMC – Ethereum Client-VM Connector API][EVMC] +- [EVMC documentation] +- [EVMC VM Implementation Guide][EVMC VM API] +- [EIP 1352: Specify restricted address range for precompiles/system contracts][EIP-1352] + + +## Copyright + +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). + + +[EIP-1352]: https://eips.ethereum.org/EIPS/eip-1352 +[EVMC]: https://github.com/ethereum/evmc +[EVMC documentation]: https://ethereum.github.io/evmc/ +[EVMC VM API]: https://ethereum.github.io/evmc/vmguide.html +[evmc-vmtester]: https://ethereum.github.io/evmc/vmtester.html +[example_precompiles_vm.cpp]: https://github.com/ethereum/evmc/blob/master/examples/example_precompiles_vm/example_precompiles_vm.cpp +[ewasm precompiles]: https://github.com/ewasm/ewasm-precompiles + +[`EVMC_CALL`]: https://ethereum.github.io/evmc/group__EVMC.html#ggab2fa68a92a6828064a61e46060abc634abcf3ae29d9a88ff70b98374fc665694a +[`EVMC_CAPABILITY_PRECOMPILES`]: https://ethereum.github.io/evmc/group__EVMC.html#gga44f9ecb88cf6422a0072936494fd6ac7a43ea2aa7b099a2d67bc53c118ff3683d +[`EVMC_FAILURE`]: https://ethereum.github.io/evmc/group__EVMC.html#gga4c0be97f333c050ff45321fcaa34d920aed5b2a4afa5a47af732569445920a4a9 +[`EVMC_OUT_OF_GAS`]: https://ethereum.github.io/evmc/group__EVMC.html#gga4c0be97f333c050ff45321fcaa34d920abfc47f75656c996c0b29c0553c00fc18 +[`EVMC_REJECTED`]: https://ethereum.github.io/evmc/group__EVMC.html#gga4c0be97f333c050ff45321fcaa34d920a2f3e0d8777f8d974ead27ae2a6eb2005 +[`EVMC_REVERT`]: https://ethereum.github.io/evmc/group__EVMC.html#gga4c0be97f333c050ff45321fcaa34d920aed708e84d49cc1270e54ec20b0ca0a05 +[`EVMC_SUCCESS`]: https://ethereum.github.io/evmc/group__EVMC.html#gga4c0be97f333c050ff45321fcaa34d920a4bc3069fec2bab2a55355a72b7db68b7 +[`execute()`]: https://ethereum.github.io/evmc/structevmc__instance.html#a0823ebff21f9b0395b157e8c6b14a207 +[`get_capabilities()`]: https://ethereum.github.io/evmc/structevmc__instance.html#ae63b9ca898aa41cbd1e2fe86ca8f4e1c +[`evmc_message::destination`]: https://ethereum.github.io/evmc/structevmc__message.html#a88ecfaa03a85a31c6da36fa043b98cea +[`evmc_message::input_data`]: https://ethereum.github.io/evmc/structevmc__message.html#a1adee3454b105eb29cd659ee0cf65c77 +[`evmc_message::input_size`]: https://ethereum.github.io/evmc/structevmc__message.html#a2cf1deebd0dbbb20f25ecdfa299f4b5d +[`evmc_message::gas`]: https://ethereum.github.io/evmc/structevmc__message.html#ae8deff46588584fa27890e74c82db5e7 +[`evmc_message::kind`]: https://ethereum.github.io/evmc/structevmc__message.html#a691cb93e81d6dfd4fd7e2fa3d06a6bfa +[`evmc_result::gas_left`]: https://ethereum.github.io/evmc/structevmc__result.html#af8478c93dbcc3cb2876037c5a5afd4c0 +[`evmc_result::output_data`]: https://ethereum.github.io/evmc/structevmc__result.html#a61978e85f9d795a7b9695b9cbf1748d6 +[`evmc_result::output_size`]: https://ethereum.github.io/evmc/structevmc__result.html#a93bb7419aff492cdef754421c6d74e26 +[`evmc_revision`]: https://ethereum.github.io/evmc/group__EVMC.html#gae5759b1590071966ccf6a505b52a0ef7 From 7b6925e69f559ac7618f3d22d3f4c62946cf5690 Mon Sep 17 00:00:00 2001 From: Lucas Cullen Date: Fri, 7 Jun 2019 20:00:05 +1000 Subject: [PATCH 116/137] Automatically merged updates to draft EIP(s) 1261 (#2107) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-1261.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/EIPS/eip-1261.md b/EIPS/eip-1261.md index 732faeabeb2dc..132383e5eee99 100644 --- a/EIPS/eip-1261.md +++ b/EIPS/eip-1261.md @@ -94,7 +94,7 @@ interface IERC1261 {/* is ERC173, ERC165 */ /// Contract can set a max number of attributes and throw if limit is reached. /// @param _name Name of the attribute which is to be added. /// @param values List of values of the specified attribute. - function addAttributeSet(bytes32 _name, bytes32[] values) external; + function addAttributeSet(bytes32 _name, bytes32[] calldata values) external; /// @notice Modifies the attribute value of a specific attribute for a given `_to` address. /// @dev Use appropriate checks for whether a user/admin can modify the data. @@ -112,7 +112,7 @@ interface IERC1261 {/* is ERC173, ERC165 */ /// dev can also oraclize the request to assign membership later /// @param _attributeIndexes the attribute data associated with the member. /// This is an array which contains indexes of attributes. - function requestMembership(uint[] _attributeIndexes) external payable; + function requestMembership(uint[] calldata _attributeIndexes) external payable; /// @notice User can forfeit his membership. /// @dev Throws if the `msg.sender` already doesn't have the token. @@ -146,7 +146,7 @@ interface IERC1261 {/* is ERC173, ERC165 */ /// @param _to The address to which the token is assigned. /// @param _attributeIndexes The attribute data associated with the member. /// This is an array which contains indexes of attributes. - function assignTo(address _to, uint[] _attributeIndexes) external; + function assignTo(address _to, uint[] calldata _attributeIndexes) external; /// @notice Only Owner can revoke the membership. /// @dev This removes the membership of the user. @@ -168,7 +168,7 @@ interface IERC1261 {/* is ERC173, ERC165 */ /// @dev Returns the values of attributes as a bytes32 array. /// @param _name Name of the attribute whose values are to be fetched /// @return The values of attributes. - function getAttributeExhaustiveCollection(bytes32 _name) external view returns (bytes32[]); + function getAttributeExhaustiveCollection(bytes32 _name) external view returns (bytes32[] memory); /// @notice Returns the list of all past and present members. /// @dev Use this function along with isCurrentMember to find wasMemberOf() in Js. @@ -190,7 +190,7 @@ interface IERC1261 {/* is ERC173, ERC165 */ /// Which has a single attributeValue for each attributeName in an array. /// Use web3.toAscii(data[0]).replace(/\u0000/g, "") to convert to string in JS. /// @return The names of attributes. - function getAttributeNames() external view returns (bytes32[]); + function getAttributeNames() external view returns (bytes32[] memory); /// @notice Returns the attributes of `_to` address. /// @dev Throws if `_to` is the zero address. @@ -215,7 +215,7 @@ interface ERC173 /* is ERC165 */ { /// @notice Get the address of the owner /// @return The address of the owner. - function owner() view external; + function owner() external view; /// @notice Set the address of the new owner of the contract /// @param _newOwner The address of the new owner of the contract From 193fdeb56f8f7721651efa8dfcfc1e7bf50b2dec Mon Sep 17 00:00:00 2001 From: Andrew Cooke Date: Fri, 7 Jun 2019 06:07:51 -0400 Subject: [PATCH 117/137] Automatically merged updates to draft EIP(s) 1155 (#2108) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-1155.md | 59 +++++++++++++++++++++++++----------------------- 1 file changed, 31 insertions(+), 28 deletions(-) diff --git a/EIPS/eip-1155.md b/EIPS/eip-1155.md index 977c9f48c5c5b..24c76699e7101 100644 --- a/EIPS/eip-1155.md +++ b/EIPS/eip-1155.md @@ -149,12 +149,13 @@ interface ERC1155 /* is ERC165 */ { ### ERC-1155 Token Receiver Smart contracts **MUST** implement all the functions in this interface to accept transfers. See "Safe Transfer Rules" for further detail. +Smart contracts **MUST** implement the ERC-165 `supportsInterface` function and signify support for this interface. See "ERC1155TokenReceiver ERC-165 rules" for further detail. ```solidity pragma solidity ^0.5.9; /** - Note: The ERC-165 identifier for this interface is 0x43b236a2. + Note: The ERC-165 identifier for this interface is 0x4e2312e0. */ interface ERC1155TokenReceiver { /** @@ -185,15 +186,7 @@ interface ERC1155TokenReceiver { @param _data Additional data with no specified format @return `bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))` */ - function onERC1155BatchReceived(address _operator, address _from, uint256[] calldata _ids, uint256[] calldata _values, bytes calldata _data) external returns(bytes4); - - /** - @notice Indicates whether a contract implements the `ERC1155TokenReceiver` functions and so can accept ERC1155 token types. - @dev This function MUST return `bytes4(keccak256("isERC1155TokenReceiver()"))` (i.e. 0x0d912442). - This function MUST NOT consume more than 5,000 gas. - @return `bytes4(keccak256("isERC1155TokenReceiver()"))` - */ - function isERC1155TokenReceiver() external view returns (bytes4); + function onERC1155BatchReceived(address _operator, address _from, uint256[] calldata _ids, uint256[] calldata _values, bytes calldata _data) external returns(bytes4); } ``` @@ -336,16 +329,19 @@ To be more explicit about how the standard `safeTransferFrom` and `safeBatchTran - The set of all calls to `onERC1155Received` and `onERC1155BatchReceived` describes all balance changes that occurred during the transaction in the order submitted. * A contract MAY skip calling the `onERC1155BatchReceived` hook function if the transfer operation is transferring the token(s) to itself. -**_isERC1155TokenReceiver rules:_** -* The implementation of `isERC1155TokenReceiver` function SHOULD be as follows: - ``` - function isERC1155TokenReceiver() external view returns (bytes4) { - return 0x0d912442; // bytes4(keccak256("isERC1155TokenReceiver()")) +**_ERC1155TokenReceiver ERC-165 rules:_** +* The implementation of the ERC-165 `supportsInterface` function SHOULD be as follows: + ``` + function supportsInterface(bytes4 interfaceID) external view returns (bool) { + return interfaceID == 0x01ffc9a7 || // ERC-165 support (i.e. `bytes4(keccak256('supportsInterface(bytes4)'))`). + interfaceID == 0x4e2312e0; // ERC-1155 `ERC1155TokenReceiver` support (i.e. `bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)")) ^ bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))`). } - ``` + ``` * The implementation MAY differ from the above but: - - It MUST return the same value. - - It MUST NOT consume more than 5,000 gas. + - It MUST return the constant value `true` if `0x01ffc9a7` is passed through the `interfaceID` argument. This signifies ERC-165 support. + - It MUST return the constant value `true` if `0x4e2312e0` is passed through the `interfaceID` argument. This signifies ERC-1155 `ERC1155TokenReceiver` support. + - It MUST NOT consume more than 10,000 gas. + - This keeps it below the ERC-165 requirement of 30,000 gas, reduces the gas reserve needs and minimises possible side-effects of gas exhaustion during the call. **_Implementation specific transfer API rules:_** * If an implementation specific API function is used to transfer ERC-1155 token(s) to a contract, the `safeTransferFrom` or `safeBatchTransferFrom` (as appropriate) rules MUST still be followed if the receiver implements the `ERC1155TokenReceiver` interface. If it does not the non-standard implementation SHOULD revert but MAY proceed. @@ -356,9 +352,9 @@ To be more explicit about how the standard `safeTransferFrom` and `safeBatchTran 4. `myTransferFrom` checks if `_to` is a contract address and determines that it is so (if not, then the transfer can be considered successful). 5. `myTransferFrom` calls `onERC1155BatchReceived` on `_to` and it reverts or returns an unknown value (if it had returned `bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))` the transfer can be considered successful). 6. At this point `myTransferFrom` SHOULD revert the transaction immediately as receipt of the token(s) was not explicitly accepted by the `onERC1155BatchReceived` function. - 7. If however `myTransferFrom` wishes to continue it MUST call `isERC1155TokenReceiver()` on `_to` and if it returns `bytes4(keccak256("isERC1155TokenReceiver()"))` the transaction MUST be reverted, as it is now known to be a valid receiver and the previous acceptance step failed. - - NOTE: You could have called `isERC1155TokenReceiver()` at a previous step if you wanted to gather and act upon that information earlier, such as in a hybrid standards scenario. - 8. If the above call to `isERC1155TokenReceiver()` on `_to` reverts or returns an unknown value the `myTransferFrom` function MAY consider this transfer successful. + 7. If however `myTransferFrom` wishes to continue it MUST call `supportsInterface(0x4e2312e0)` on `_to` and if it returns the constant value `true` the transaction MUST be reverted, as it is now known to be a valid receiver and the previous acceptance step failed. + - NOTE: You could have called `supportsInterface(0x4e2312e0)` at a previous step if you wanted to gather and act upon that information earlier, such as in a hybrid standards scenario. + 8. If the above call to `supportsInterface(0x4e2312e0)` on `_to` reverts or returns a value other than the constant value `true` the `myTransferFrom` function MAY consider this transfer successful. - __NOTE__: this MAY result in unrecoverable tokens if sent to an address that does not expect to receive ERC-1155 tokens. * The above example is not exhaustive but illustrates the major points (and shows that most are shared with `safeTransferFrom` and `safeBatchTransferFrom`): - Balances that are updated MUST have equivalent transfer events emitted. @@ -381,20 +377,25 @@ To be more explicit about how the standard `safeTransferFrom` and `safeBatchTran * A contract MAY skip calling the `ERC1155TokenReceiver` hook function(s) if the mint/create operation is transferring the token(s) to itself. In all other cases the `ERC1155TokenReceiver` rules MUST be followed as appropriate for the implementation (i.e. safe, custom and/or hybrid). -###### A solidity example of the keccak256 generated constants for the return magic is: - - bytes4 constant public ERC1155_ACCEPTED = 0xf23a6e61; // bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)")) - - bytes4 constant public ERC1155_BATCH_ACCEPTED = 0xbc197c81; // bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)")) +##### A solidity example of the keccak256 generated constants for the various magic values (these MAY be used by implementation): + +``` +bytes4 constant public ERC1155_ERC165 = 0xd9b67a26; // ERC-165 identifier for the main token standard. +bytes4 constant public ERC1155_ERC165_TOKENRECEIVER = 0x4e2312e0; // ERC-165 identifier for the `ERC1155TokenReceiver` support (i.e. `bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)")) ^ bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))`). +bytes4 constant public ERC1155_ACCEPTED = 0xf23a6e61; // Return value from `onERC1155Received` call if a contract accepts receipt (i.e `bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)"))`). +bytes4 constant public ERC1155_BATCH_ACCEPTED = 0xbc197c81; // Return value from `onERC1155BatchReceived` call if a contract accepts receipt (i.e `bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))`). +``` #### Compatibility with other standards There have been requirements during the design discussions to have this standard be compatible with existing standards when sending to contract addresses, specifically ERC-721 at time of writing. -To cater for this scenario, there is some leeway with the rejection logic should a contract not implement the `ERC1155TokenReceiver` as per "Safe Transfer Rules" section above, specifically "Scenario#3 : The receiver does not implement the necessary `ERC1155TokenReceiver` interface function(s)". +To cater for this scenario, there is some leeway with the revert logic should a contract not implement the `ERC1155TokenReceiver` as per "Safe Transfer Rules" section above, specifically "Scenario#3 : The receiver does not implement the necessary `ERC1155TokenReceiver` interface function(s)". Hence in a hybrid ERC-1155 contract implementation an extra call MUST be made on the recipient contract and checked before any hook calls to `onERC1155Received` or `onERC1155BatchReceived` are made. Order of operation MUST therefore be: -1. The implementation MUST call the function `isERC1155TokenReceiver` on the recipient contract, providing at least 5,000 gas. -2. If the function call succeeds and the return value is `bytes4(keccak256("isERC1155TokenReceiver()"))` the implementation proceeds as a regular ERC-1155 implementation, with the call(s) to the `onERC1155Received` or `onERC1155BatchReceived` hooks and rules associated. -3. If the function call fails or the return value is NOT `bytes4(keccak256("isERC1155TokenReceiver()"))` the implementation can assume the recipient contract is not an `ERC1155TokenReceiver` and follow its other standard's rules for transfers. +1. The implementation MUST call the function `supportsInterface(0x4e2312e0)` on the recipient contract, providing at least 10,000 gas. +2. If the function call succeeds and the return value is the constant value `true` the implementation proceeds as a regular ERC-1155 implementation, with the call(s) to the `onERC1155Received` or `onERC1155BatchReceived` hooks and rules associated. +3. If the function call fails or the return value is NOT the constant value `true` the implementation can assume the recipient contract is not an `ERC1155TokenReceiver` and follow its other standard's rules for transfers. *__Note that a pure implementation of a single standard is recommended__* rather than a hybrid solution, but an example of a hybrid ERC-1155/ERC-721 contract is linked in the references section under implementations. @@ -416,6 +417,8 @@ The following optional extensions can be identified with the (ERC-165 Standard I Changes to the URI MUST emit the `URI` event if the change can be expressed with an event (i.e. it isn't dynamic). If the optional ERC1155Metadata_URI extension is included, the `uri` function SHOULD be used to retrieve values for which no event was emitted. The function MUST return the same value as the event if it was emitted. +Note that if this extension is enabled: if the URI event is to be used for metadata uri's changes, it does not need to be emitted first at Mint time. Observer can fetch the metadata uri at mint time from the `uri` function. + ```solidity pragma solidity ^0.5.9; From 914c3baad11ea4719162f7cc279000dd5cbb06c9 Mon Sep 17 00:00:00 2001 From: Andrew Cooke Date: Fri, 7 Jun 2019 07:32:16 -0400 Subject: [PATCH 118/137] Automatically merged updates to draft EIP(s) 1155 (#2109) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-1155.md | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/EIPS/eip-1155.md b/EIPS/eip-1155.md index 24c76699e7101..e79c4d07fd11d 100644 --- a/EIPS/eip-1155.md +++ b/EIPS/eip-1155.md @@ -31,7 +31,8 @@ New functionality is possible with this design, such as transferring multiple to The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. -**Smart contracts implementing the ERC-1155 standard MUST implement the `ERC1155` and `ERC165` interfaces.** +**Smart contracts implementing the ERC-1155 standard MUST implement all of the functions in the `ERC1155` interface.** +**Smart contracts implementing the ERC-1155 standard MUST implement the ERC-165 `supportsInterface` function and MUST return the constant value `true` if `0xd9b67a26` is passed through the `interfaceID` argument.** ```solidity pragma solidity ^0.5.9; @@ -148,8 +149,8 @@ interface ERC1155 /* is ERC165 */ { ### ERC-1155 Token Receiver -Smart contracts **MUST** implement all the functions in this interface to accept transfers. See "Safe Transfer Rules" for further detail. -Smart contracts **MUST** implement the ERC-165 `supportsInterface` function and signify support for this interface. See "ERC1155TokenReceiver ERC-165 rules" for further detail. +**Smart contracts MUST implement all of the functions in the `ERC1155TokenReceiver` interface to accept transfers. See "Safe Transfer Rules" for further detail.** +**Smart contracts MUST implement the ERC-165 `supportsInterface` function and signify support for the `ERC1155TokenReceiver` interface to accept transfers. See "ERC1155TokenReceiver ERC-165 rules" for further detail.** ```solidity pragma solidity ^0.5.9; @@ -413,11 +414,14 @@ Example of such a URI: `https://token-cdn-domain/{id}.json` would be replaced wi #### Metadata Extensions -The following optional extensions can be identified with the (ERC-165 Standard Interface Detection)[https://eips.ethereum.org/EIPS/eip-165]. +The optional `ERC1155Metadata_URI` extension can be identified with the (ERC-165 Standard Interface Detection)[https://eips.ethereum.org/EIPS/eip-165]. -Changes to the URI MUST emit the `URI` event if the change can be expressed with an event (i.e. it isn't dynamic). If the optional ERC1155Metadata_URI extension is included, the `uri` function SHOULD be used to retrieve values for which no event was emitted. The function MUST return the same value as the event if it was emitted. - -Note that if this extension is enabled: if the URI event is to be used for metadata uri's changes, it does not need to be emitted first at Mint time. Observer can fetch the metadata uri at mint time from the `uri` function. +If the optional `ERC1155Metadata_URI` extension is included: +* The ERC-165 `supportsInterface` function MUST return the constant value `true` if `0x0e89341c` is passed through the `interfaceID` argument. +* _Changes_ to the URI MUST emit the `URI` event if the change can be expressed with an event (i.e. it isn't dynamic/programmatic). + - An implementation MAY emit the `URI` event during a mint operation but it is NOT mandatory. An observer MAY fetch the metadata uri at mint time from the `uri` function if it was not emitted. +* The `uri` function SHOULD be used to retrieve values if no event was emitted. +* The `uri` function MUST return the same value as the latest event for an `_id` if it was emitted. ```solidity pragma solidity ^0.5.9; From 4694622aadaaad018fa4cb87db75de3bd2565e19 Mon Sep 17 00:00:00 2001 From: Andrew Cooke Date: Fri, 7 Jun 2019 07:47:31 -0400 Subject: [PATCH 119/137] Automatically merged updates to draft EIP(s) 1155 (#2110) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-1155.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/EIPS/eip-1155.md b/EIPS/eip-1155.md index e79c4d07fd11d..b12fb2c853ca5 100644 --- a/EIPS/eip-1155.md +++ b/EIPS/eip-1155.md @@ -32,6 +32,7 @@ New functionality is possible with this design, such as transferring multiple to The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. **Smart contracts implementing the ERC-1155 standard MUST implement all of the functions in the `ERC1155` interface.** + **Smart contracts implementing the ERC-1155 standard MUST implement the ERC-165 `supportsInterface` function and MUST return the constant value `true` if `0xd9b67a26` is passed through the `interfaceID` argument.** ```solidity @@ -150,6 +151,7 @@ interface ERC1155 /* is ERC165 */ { ### ERC-1155 Token Receiver **Smart contracts MUST implement all of the functions in the `ERC1155TokenReceiver` interface to accept transfers. See "Safe Transfer Rules" for further detail.** + **Smart contracts MUST implement the ERC-165 `supportsInterface` function and signify support for the `ERC1155TokenReceiver` interface to accept transfers. See "ERC1155TokenReceiver ERC-165 rules" for further detail.** ```solidity @@ -332,12 +334,12 @@ To be more explicit about how the standard `safeTransferFrom` and `safeBatchTran **_ERC1155TokenReceiver ERC-165 rules:_** * The implementation of the ERC-165 `supportsInterface` function SHOULD be as follows: - ``` + ```solidity function supportsInterface(bytes4 interfaceID) external view returns (bool) { return interfaceID == 0x01ffc9a7 || // ERC-165 support (i.e. `bytes4(keccak256('supportsInterface(bytes4)'))`). interfaceID == 0x4e2312e0; // ERC-1155 `ERC1155TokenReceiver` support (i.e. `bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)")) ^ bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))`). } - ``` + ``` * The implementation MAY differ from the above but: - It MUST return the constant value `true` if `0x01ffc9a7` is passed through the `interfaceID` argument. This signifies ERC-165 support. - It MUST return the constant value `true` if `0x4e2312e0` is passed through the `interfaceID` argument. This signifies ERC-1155 `ERC1155TokenReceiver` support. @@ -380,7 +382,7 @@ To be more explicit about how the standard `safeTransferFrom` and `safeBatchTran ##### A solidity example of the keccak256 generated constants for the various magic values (these MAY be used by implementation): -``` +```solidity bytes4 constant public ERC1155_ERC165 = 0xd9b67a26; // ERC-165 identifier for the main token standard. bytes4 constant public ERC1155_ERC165_TOKENRECEIVER = 0x4e2312e0; // ERC-165 identifier for the `ERC1155TokenReceiver` support (i.e. `bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)")) ^ bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))`). bytes4 constant public ERC1155_ACCEPTED = 0xf23a6e61; // Return value from `onERC1155Received` call if a contract accepts receipt (i.e `bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)"))`). From c8735245a4e3fbe655bbaba56099ce5761bcc525 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Pawe=C5=82=20Bylica?= Date: Mon, 10 Jun 2019 15:49:26 +0200 Subject: [PATCH 120/137] Automatically merged updates to draft EIP(s) 2003 (#2112) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-2003.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/EIPS/eip-2003.md b/EIPS/eip-2003.md index 08786e9e81561..c5ab43fa18435 100644 --- a/EIPS/eip-2003.md +++ b/EIPS/eip-2003.md @@ -4,7 +4,8 @@ title: EVMC modules for implementations of precompiled contracts author: Paweł Bylica (@chfast), Alex Beregszaszi (@axic) discussions-to: https://github.com/ethereum/evmc/issues/259 status: Draft -type: Informational +type: Standards Track +category: Interface created: 2019-05-09 requires: 1352 --- From 083129dd1e9eeda1395be4c4ebeafa69232026a1 Mon Sep 17 00:00:00 2001 From: Andrew Cooke Date: Wed, 12 Jun 2019 00:11:43 -0400 Subject: [PATCH 121/137] Automatically merged updates to draft EIP(s) 1155 (#2113) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-1155.md | 36 ++++++++++++++++++------------------ 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/EIPS/eip-1155.md b/EIPS/eip-1155.md index b12fb2c853ca5..ba4f55416a701 100644 --- a/EIPS/eip-1155.md +++ b/EIPS/eip-1155.md @@ -13,19 +13,19 @@ requires: 165 ## Simple Summary -A standard interface for contracts that manage multiple token types. A single deployed contract may include any combination of fungible tokens, non-fungible tokens, or other configurations (e.g. semi-fungible tokens). +A standard interface for contracts that manage multiple token types. A single deployed contract may include any combination of fungible tokens, non-fungible tokens or other configurations (e.g. semi-fungible tokens). ## Abstract -This standard outlines a smart contract interface that can represent any number of Fungible and Non-Fungible token types. Existing standards such as ERC-20 require deployment of separate contracts per token type. The ERC-721 standard's token ID is a single non-fungible index and the group of these non-fungibles is deployed as a single contract with settings for the entire collection. In contrast, the ERC-1155 Multi Token Standard allows for each token ID to represent a new configurable token type, which may have its own metadata, supply and other attributes. +This standard outlines a smart contract interface that can represent any number of fungible and non-fungible token types. Existing standards such as ERC-20 require deployment of separate contracts per token type. The ERC-721 standard's token ID is a single non-fungible index and the group of these non-fungibles is deployed as a single contract with settings for the entire collection. In contrast, the ERC-1155 Multi Token Standard allows for each token ID to represent a new configurable token type, which may have its own metadata, supply and other attributes. The `_id` argument contained in each function's argument set indicates a specific token or token type in a transaction. ## Motivation -Tokens standards like ERC-20 and ERC-721 require a separate contract to be deployed for each token type or collection. This places a lot of redundant bytecode on the Ethereum blockchain and limits certain functionality by the nature of separating each token contract into its own permissioned address. With the rise of blockchain games and platforms like Enjin Coin, game developers may be creating thousands of token types, and a new type of token standard is needed to support them. However, ERC-1155 is not specific to games, and many other applications can benefit from this flexibility. +Tokens standards like ERC-20 and ERC-721 require a separate contract to be deployed for each token type or collection. This places a lot of redundant bytecode on the Ethereum blockchain and limits certain functionality by the nature of separating each token contract into its own permissioned address. With the rise of blockchain games and platforms like Enjin Coin, game developers may be creating thousands of token types, and a new type of token standard is needed to support them. However, ERC-1155 is not specific to games and many other applications can benefit from this flexibility. -New functionality is possible with this design, such as transferring multiple token types at once, saving on transaction costs. Trading (escrow / atomic swaps) of multiple tokens can be built on top of this standard and it removes the need to "approve" individual token contracts separately. It is also easy to describe and mix multiple fungible or non-fungible token types in a single contract. +New functionality is possible with this design such as transferring multiple token types at once, saving on transaction costs. Trading (escrow / atomic swaps) of multiple tokens can be built on top of this standard and it removes the need to "approve" individual token contracts separately. It is also easy to describe and mix multiple fungible or non-fungible token types in a single contract. ## Specification @@ -115,7 +115,7 @@ interface ERC1155 /* is ERC165 */ { function safeBatchTransferFrom(address _from, address _to, uint256[] calldata _ids, uint256[] calldata _values, bytes calldata _data) external; /** - @notice Get the balance of an account's Tokens. + @notice Get the balance of an account's tokens. @param _owner The address of the token holder @param _id ID of the token @return The _owner's balance of the token type requested @@ -125,7 +125,7 @@ interface ERC1155 /* is ERC165 */ { /** @notice Get the balance of multiple account/token pairs @param _owners The addresses of the token holders - @param _ids ID of the Tokens + @param _ids ID of the tokens @return The _owner's balance of the token types requested (i.e. balance for each (owner, id) pair) */ function balanceOfBatch(address[] calldata _owners, uint256[] calldata _ids) external view returns (uint256[] memory); @@ -140,7 +140,7 @@ interface ERC1155 /* is ERC165 */ { /** @notice Queries the approval status of an operator for a given owner. - @param _owner The owner of the Tokens + @param _owner The owner of the tokens @param _operator Address of authorized operator @return True if the operator is approved, false if not */ @@ -207,7 +207,7 @@ To be more explicit about how the standard `safeTransferFrom` and `safeBatchTran **_Scenario#3 :_** The receiver does not implement the necessary `ERC1155TokenReceiver` interface function(s). * The transfer MUST be reverted with the one caveat below. - - If the tokens being sent are part of a hybrid implementation of another standard, that particular standard's rules on sending to a contract MAY now be followed instead. See "Compatibility with other standards" section. + - If the token(s) being sent are part of a hybrid implementation of another standard, that particular standard's rules on sending to a contract MAY now be followed instead. See "Compatibility with other standards" section. **_Scenario#4 :_** The receiver implements the necessary `ERC1155TokenReceiver` interface function(s) but returns an unknown value. * The transfer MUST be reverted. @@ -242,9 +242,9 @@ To be more explicit about how the standard `safeTransferFrom` and `safeBatchTran - If the contract logic wishes to keep the ownership of the token(s) itself in this case it MAY do so. **_Scenario#9 :_** You are transferring tokens via a non-standard API call i.e. an implementation specific API and NOT `safeTransferFrom` or `safeBatchTransferFrom`. -* In this scenario all balance updates and events output rules are the same as if a standard function had been called. - - i.e. an external viewer should still be able to query a balance via a function and it be identical to the balance as determined by `TransferSingle` and `TransferBatch` events alone. -* If the receiver is a contract the `ERC1155TokenReceiver` hooks still need to be called on it and the return values respected the same as if a standard function had been called. +* In this scenario all balance updates and events output rules are the same as if a standard transfer function had been called. + - i.e. an external viewer MUST still be able to query the balance via a standard function and it MUST be identical to the balance as determined by `TransferSingle` and `TransferBatch` events alone. +* If the receiver is a contract the `ERC1155TokenReceiver` hooks still need to be called on it and the return values respected the same as if a standard transfer function had been called. - However while the `safeTransferFrom` or `safeBatchTransferFrom` functions MUST revert if a receiving contract does not implement the `ERC1155TokenReceiver` interface, a non-standard function MAY proceed with the transfer. - See "Implementation specific transfer API rules". @@ -377,7 +377,7 @@ To be more explicit about how the standard `safeTransferFrom` and `safeBatchTran * The total value transferred from address `0x0` minus the total value transferred to `0x0` observed via the `TransferSingle` and `TransferBatch` events MAY be used by clients and exchanges to determine the "circulating supply" for a given token ID. * As mentioned above mint/create and burn/destroy operations are specialized transfers and so will likely be accomplished with custom transfer functions rather than `safeTransferFrom` or `safeBatchTransferFrom`. If so the "Implementation specific transfer API rules" section would be appropriate. - Even in a non-safe API and/or hybrid standards case the above event rules MUST still be adhered to when minting/creating or burning/destroying. -* A contract MAY skip calling the `ERC1155TokenReceiver` hook function(s) if the mint/create operation is transferring the token(s) to itself. In all other cases the `ERC1155TokenReceiver` rules MUST be followed as appropriate for the implementation (i.e. safe, custom and/or hybrid). +* A contract MAY skip calling the `ERC1155TokenReceiver` hook function(s) if the mint operation is transferring the token(s) to itself. In all other cases the `ERC1155TokenReceiver` rules MUST be followed as appropriate for the implementation (i.e. safe, custom and/or hybrid). ##### A solidity example of the keccak256 generated constants for the various magic values (these MAY be used by implementation): @@ -407,7 +407,7 @@ An important consideration is that even if the tokens are sent with another stan ### Metadata -The URI value allows for ID substitution by clients. If the string `{id}` exists in any URI, clients MUST replace this with the actual token ID in hexadecimal form. This allows for large number of tokens to use the same on-chain string by defining a URI once, for a large collection of tokens. +The URI value allows for ID substitution by clients. If the string `{id}` exists in any URI, clients MUST replace this with the actual token ID in hexadecimal form. This allows for a large number of tokens to use the same on-chain string by defining a URI once, for that large number of tokens. * The string format of the substituted hexadecimal ID MUST be lowercase alphanumeric: `[0-9a-f]` with no 0x prefix. * The string format of the substituted hexadecimal ID MUST be leading zero padded to 64 hex characters length if necessary. @@ -594,7 +594,7 @@ fr.json: ### Approval The function `setApprovalForAll` allows an operator to manage one's entire set of tokens on behalf of the approver. To permit approval of a subset of token IDs, an interface such as [ERC-1761 Scoped Approval Interface](https://eips.ethereum.org/EIPS/eip-1761) is suggested. -The counterpart `isApprovedForAll` provides introspection into status set by `setApprovalForAll`. +The counterpart `isApprovedForAll` provides introspection into any status set by `setApprovalForAll`. An owner SHOULD be assumed to always be able to operate on their own tokens regardless of approval status, so should SHOULD NOT have to call `setApprovalForAll` to approve themselves as an operator before they can operate on them. @@ -630,7 +630,7 @@ Restricting approval to a certain set of token IDs, quantities or other rules MA ## Usage -This standard can be used to represent multiple token types for an entire domain. Both Fungible and Non-Fungible tokens can be stored in the same smart-contract. +This standard can be used to represent multiple token types for an entire domain. Both fungible and non-fungible tokens can be stored in the same smart-contract. ### Batch Transfers @@ -648,13 +648,13 @@ The `balanceOfBatch` function allows clients to retrieve balances of multiple ow In order to keep storage requirements light for contracts implementing ERC-1155, enumeration (discovering the IDs and values of tokens) must be done using event logs. It is RECOMMENDED that clients such as exchanges and blockchain explorers maintain a local database containing the token ID, Supply, and URI at the minimum. This can be built from each TransferSingle, TransferBatch, and URI event, starting from the block the smart contract was deployed until the latest block. -ERC-1155 contracts must therefore carefully emit `TransferSingle` or `TransferBatch` events in any instance where tokens are created, minted, or destroyed. +ERC-1155 contracts must therefore carefully emit `TransferSingle` or `TransferBatch` events in any instance where tokens are created, minted, transferred or destroyed. ### Non-Fungible Tokens The following strategy is an example of how to mix fungible and non-fungible tokens together in the same contract. The top 128 bits of the uint256 `_id` parameter in any ERC-1155 function could represent the base token ID, while the bottom 128 bits might be used for any extra data passed to the contract. -Non-Fungible tokens can be interacted with using an index based accessor into the contract/token data set. Therefore to access a particular token set within a mixed data contract and particular NFT within that set, `_id` could be passed as ``. +Non-fungible tokens can be interacted with using an index based accessor into the contract/token data set. Therefore to access a particular token set within a mixed data contract and particular NFT within that set, `_id` could be passed as ``. Inside the contract code the two pieces of data needed to access the individual NFT can be extracted with uint128(~0) and the same mask shifted by 128. @@ -665,7 +665,7 @@ uint256 baseToken = 12345 << 128; uint128 index = 50; balanceOf(baseToken, msg.sender); // Get balance of the base token -balanceOf(baseToken + index, msg.sender); // Get balance of the Non-Fungible token index +balanceOf(baseToken + index, msg.sender); // Get balance of the non-fungible token index ``` ## References From d95612c8206b7e225bec5dc34c4b019c9531e44d Mon Sep 17 00:00:00 2001 From: Witek Date: Wed, 12 Jun 2019 11:18:10 -0700 Subject: [PATCH 122/137] Automatically merged updates to draft EIP(s) 1155 (#2114) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-1155.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/EIPS/eip-1155.md b/EIPS/eip-1155.md index ba4f55416a701..1369d54251eb0 100644 --- a/EIPS/eip-1155.md +++ b/EIPS/eip-1155.md @@ -1,7 +1,7 @@ --- eip: 1155 title: ERC-1155 Multi Token Standard -author: Witek Radomski , Andrew Cooke , Philippe Castonguay , James Therien , Eric Binet , Ronan Sandford +author: Witek Radomski , Andrew Cooke , Philippe Castonguay , James Therien , Eric Binet , Ronan Sandford type: Standards Track category: ERC status: Last Call @@ -668,6 +668,10 @@ balanceOf(baseToken, msg.sender); // Get balance of the base token balanceOf(baseToken + index, msg.sender); // Get balance of the non-fungible token index ``` +### Natural Non-Fungible tokens + +Another simple way to represent NFTs is to allow a maximum value of 1 for each non-fungible token. This would naturally mirror the real world, where unique items have a quantity of 1, and fungible items have a quantity greater than 1. + ## References **Standards** From db441bb67dd38dad86f06280e6bdffccb6a6d2cd Mon Sep 17 00:00:00 2001 From: Andrew Cooke Date: Wed, 12 Jun 2019 20:20:24 -0400 Subject: [PATCH 123/137] Automatically merged updates to draft EIP(s) 1155 (#2116) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-1155.md | 32 ++++++++++++++++++++++---------- 1 file changed, 22 insertions(+), 10 deletions(-) diff --git a/EIPS/eip-1155.md b/EIPS/eip-1155.md index 1369d54251eb0..bb1d4762a1c82 100644 --- a/EIPS/eip-1155.md +++ b/EIPS/eip-1155.md @@ -652,25 +652,37 @@ ERC-1155 contracts must therefore carefully emit `TransferSingle` or `TransferBa ### Non-Fungible Tokens -The following strategy is an example of how to mix fungible and non-fungible tokens together in the same contract. The top 128 bits of the uint256 `_id` parameter in any ERC-1155 function could represent the base token ID, while the bottom 128 bits might be used for any extra data passed to the contract. +The following strategies are examples of how you MAY mix fungible and non-fungible tokens together in the same contract. The standard does NOT mandate how an implementation must do this. -Non-fungible tokens can be interacted with using an index based accessor into the contract/token data set. Therefore to access a particular token set within a mixed data contract and particular NFT within that set, `_id` could be passed as ``. +##### Split ID bits -Inside the contract code the two pieces of data needed to access the individual NFT can be extracted with uint128(~0) and the same mask shifted by 128. +The top 128 bits of the uint256 `_id` parameter in any ERC-1155 function MAY represent the base token ID, while the bottom 128 bits MAY represent the index of the non-fungible to make it unique. -### Example of split ID bits +Non-fungible tokens can be interacted with using an index based accessor into the contract/token data set. Therefore to access a particular token set within a mixed data contract and a particular non-fungible within that set, `_id` could be passed as ``. + +To identify a non-fungible set/category as a whole (or a fungible) you COULD just pass in the base id via the `_id` argument as ``. If your implementation uses this technique this naturally means the index of a non-fungible SHOULD be 1-based. + +Inside the contract code the two pieces of data needed to access the individual non-fungible can be extracted with uint128(~0) and the same mask shifted by 128. ```solidity -uint256 baseToken = 12345 << 128; -uint128 index = 50; +uint256 baseTokenNFT = 12345 << 128; +uint128 indexNFT = 50; + +uint256 baseTokenFT = 54321 << 128; -balanceOf(baseToken, msg.sender); // Get balance of the base token -balanceOf(baseToken + index, msg.sender); // Get balance of the non-fungible token index +balanceOf(baseTokenNFT, msg.sender); // Get balance of the base token for non-fungible set 12345 (this MAY be used to get balance of the user for all of this token set if the implementation wishes as a convenience). +balanceOf(baseTokenNFT + indexNFT, msg.sender); // Get balance of the token at index 50 for non-fungible set 12345 (should be 1 if user owns the individual non-fungible token or 0 if they do not). +balanceOf(baseTokenFT, msg.sender); // Get balance of the fungible base token 54321. ``` -### Natural Non-Fungible tokens +Note that 128 is an arbitrary number, an implementation MAY choose how they would like this split to occur as suitable for their use case. An observer of the contract would simply see events showing balance transfers and mints happening and MAY track the balances using that information alone. +For an observer to be able to determine type (non-fungible or fungible) from an ID alone they would have to know the split ID bits format on a implementation by implementation basis. + +The [ERC-1155 Reference Implementation](https://github.com/enjin/erc-1155) is an example of the split ID bits strategy. + +##### Natural Non-Fungible tokens -Another simple way to represent NFTs is to allow a maximum value of 1 for each non-fungible token. This would naturally mirror the real world, where unique items have a quantity of 1, and fungible items have a quantity greater than 1. +Another simple way to represent non-fungibles is to allow a maximum value of 1 for each non-fungible token. This would naturally mirror the real world, where unique items have a quantity of 1 and fungible items have a quantity greater than 1. ## References From 9691bd6491ae9d0339148afdcd387e80836aa147 Mon Sep 17 00:00:00 2001 From: Witek Date: Wed, 12 Jun 2019 21:02:56 -0700 Subject: [PATCH 124/137] Automatically merged updates to draft EIP(s) 1155 (#2117) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-1155.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-1155.md b/EIPS/eip-1155.md index bb1d4762a1c82..d3bb63faa173f 100644 --- a/EIPS/eip-1155.md +++ b/EIPS/eip-1155.md @@ -5,7 +5,7 @@ author: Witek Radomski , Andrew Cooke , P type: Standards Track category: ERC status: Last Call -review-period-end: 2019-06-12 +review-period-end: 2019-06-13 created: 2018-06-17 discussions-to: https://github.com/ethereum/EIPs/issues/1155 requires: 165 From 4ea97fa77f069583e91458d95cd80659bcc32906 Mon Sep 17 00:00:00 2001 From: Witek Date: Thu, 13 Jun 2019 16:50:13 -0700 Subject: [PATCH 125/137] Automatically merged updates to draft EIP(s) 1155 (#2118) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-1155.md | 1 + 1 file changed, 1 insertion(+) diff --git a/EIPS/eip-1155.md b/EIPS/eip-1155.md index d3bb63faa173f..4f1bfb4cafa9b 100644 --- a/EIPS/eip-1155.md +++ b/EIPS/eip-1155.md @@ -705,6 +705,7 @@ Another simple way to represent non-fungibles is to allow a maximum value of 1 f - [Here Be Dragons - Going Beyond ERC-20 and ERC-721 To Reduce Gas Cost by ~80%](https://medium.com/horizongames/going-beyond-erc20-and-erc721-9acebd4ff6ef) - [Blockonomi - Ethereum ERC-1155 Token Perfect for Online Games, Possibly More](https://blockonomi.com/erc1155-gaming-token/) - [Beyond Gaming - Exploring the Utility of ERC-1155 Token Standard!](https://blockgeeks.com/erc-1155-token/) +- [ERC-1155: A new standard for The Sandbox](https://medium.com/sandbox-game/erc-1155-a-new-standard-for-the-sandbox-c95ee1e45072) ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 39d47efb6f0335a5800524a98659712e0eb78123 Mon Sep 17 00:00:00 2001 From: Andrew Cooke Date: Fri, 14 Jun 2019 19:37:43 -0400 Subject: [PATCH 126/137] Automatically merged updates to draft EIP(s) 1155 (#2120) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-1155.md | 1 + 1 file changed, 1 insertion(+) diff --git a/EIPS/eip-1155.md b/EIPS/eip-1155.md index 4f1bfb4cafa9b..d724da1c29000 100644 --- a/EIPS/eip-1155.md +++ b/EIPS/eip-1155.md @@ -424,6 +424,7 @@ If the optional `ERC1155Metadata_URI` extension is included: - An implementation MAY emit the `URI` event during a mint operation but it is NOT mandatory. An observer MAY fetch the metadata uri at mint time from the `uri` function if it was not emitted. * The `uri` function SHOULD be used to retrieve values if no event was emitted. * The `uri` function MUST return the same value as the latest event for an `_id` if it was emitted. +* The `uri` function MUST NOT be used to check for the existence of a token as it is possible for an implementation to return a valid string even if the token does not exist. ```solidity pragma solidity ^0.5.9; From 89a87948bf18bd456092665cb79eb7ffaf80dac0 Mon Sep 17 00:00:00 2001 From: Matt Luongo Date: Sun, 16 Jun 2019 00:11:40 -0400 Subject: [PATCH 127/137] Brought issue #152 into the repo as a draft EIP. Thanks @tjade273! --- EIPS/eip-draft-blake2b-f-precompile.md | 49 ++++++++++++++++++++++++++ 1 file changed, 49 insertions(+) create mode 100644 EIPS/eip-draft-blake2b-f-precompile.md diff --git a/EIPS/eip-draft-blake2b-f-precompile.md b/EIPS/eip-draft-blake2b-f-precompile.md new file mode 100644 index 0000000000000..87eea5344e46e --- /dev/null +++ b/EIPS/eip-draft-blake2b-f-precompile.md @@ -0,0 +1,49 @@ +# Title + +Title: Add RFC 7693 compression function `F` contract +Author: Tjaden Hess +Status: Draft +Type: Standard Track +Layer: Consensus (hard-fork) +Created 2016-10-04 + +### Abstract + +This EIP introduces a new precompiled contract which implements the compression function F used in the BLAKE2b cryptographic hashing algorithm, for the purpose of allowing interoperability between the Zcash blockchain and the EVM, and introducing more flexible cryptographic hash primitives to the EVM. + +## Parameters + +* `METROPOLIS_FORK_BLKNUM`: TBD +* `GFROUND`: TBD + +## Specification + +Adds a precompile at address `0x0000....0d` which accepts [ABI encoded](https://github.com/ethereum/wiki/wiki/Ethereum-Contract-ABI) arguments corresponding to the function signature + +``` +F(bytes32[2] h, bytes32[4] m, uint t , bool f, uint rounds) returns (bytes32[2] h_new); +``` + +where `h`, `m`, `t` and `f` are the current state, the new message, the byte counter and a finalization flag, as defined in [RFC 7693](https://tools.ietf.org/html/rfc7693), and `rounds` is the number of rounds of mixing to perform (BLAKE2b uses 12, BLAKE2s uses 10). `h_new` is the updated state of the hash. + +Each operation will cost `GFROUND * rounds`. + +## 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. A single verification of an Equihash PoW verification requires 512 iterations of the hash function, making verification of Zcash block headers prohibitively expensive if a Solidity implementation of BLAKE2b is used. + +The BLAKE2b algorithm is highly optimized for 64-bit CPUs, and is faster than MD5 on modern processors. + +Interoperability with Zcash could enable contracts like 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. + +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 little-endian arithmetic. 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. + +Implementation of only the core F compression function allows substantial flexibility and extensibility while keeping changes at the protocol level to a minimum. This will allow functions like tree hashing, incremental hashing, and keyed, salted, and personalized hashing as well as variable length digests, none of which are currently available on the EVM. + +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....0000d` 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. From 843d377daa125ed702fefbd54259d2a0655b33b6 Mon Sep 17 00:00:00 2001 From: Matt Luongo Date: Sun, 16 Jun 2019 00:27:17 -0400 Subject: [PATCH 128/137] Make the draft EIP consistent with the template Also added myself as an author --- EIPS/eip-draft-blake2b-f-precompile.md | 59 ++++++++++++++++++-------- 1 file changed, 41 insertions(+), 18 deletions(-) diff --git a/EIPS/eip-draft-blake2b-f-precompile.md b/EIPS/eip-draft-blake2b-f-precompile.md index 87eea5344e46e..45608eed5b6ec 100644 --- a/EIPS/eip-draft-blake2b-f-precompile.md +++ b/EIPS/eip-draft-blake2b-f-precompile.md @@ -1,22 +1,37 @@ -# Title - -Title: Add RFC 7693 compression function `F` contract -Author: Tjaden Hess +--- +eip: +Title: Add Blake2 compression function `F` precompile +Author: Tjaden Hess , Matt Luongo (@mhluongo) +discussions-to: https://ethereum-magicians.org/t/blake2b-f-precompile/3157 Status: Draft -Type: Standard Track -Layer: Consensus (hard-fork) +type: Standards Track +category Core Created 2016-10-04 +--- + + + +## Simple Summary + -### Abstract +This EIP will enable the Blake2b hash function to run cheaply on the EVM, allowing easier interoperability between Ethereum and Zcash as well as other Equihash-based PoW coins. + +## Abstract + This EIP introduces a new precompiled contract which implements the compression function F used in the BLAKE2b cryptographic hashing algorithm, for the purpose of allowing interoperability between the Zcash blockchain and the EVM, and introducing more flexible cryptographic hash primitives to the EVM. -## Parameters +## Motivation + -* `METROPOLIS_FORK_BLKNUM`: TBD -* `GFROUND`: TBD +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. A single verification of an Equihash PoW verification requires 512 iterations of the hash function, making verification of Zcash block headers prohibitively expensive if a Solidity implementation of BLAKE2b is used. + +The BLAKE2b algorithm is highly optimized for 64-bit CPUs, and is faster than MD5 on modern processors. + +Interoperability with Zcash could enable contracts like trustless atomic swaps between the chains, which could provide a much needed aspect of privacy to the very public Ethereum blockchain. ## Specification + Adds a precompile at address `0x0000....0d` which accepts [ABI encoded](https://github.com/ethereum/wiki/wiki/Ethereum-Contract-ABI) arguments corresponding to the function signature @@ -28,15 +43,8 @@ where `h`, `m`, `t` and `f` are the current state, the new message, the byte cou Each operation will cost `GFROUND * rounds`. -## 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. A single verification of an Equihash PoW verification requires 512 iterations of the hash function, making verification of Zcash block headers prohibitively expensive if a Solidity implementation of BLAKE2b is used. - -The BLAKE2b algorithm is highly optimized for 64-bit CPUs, and is faster than MD5 on modern processors. - -Interoperability with Zcash could enable contracts like 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. @@ -47,3 +55,18 @@ In contrast, the big-endian 32 byte semantics of the EVM are not conducive to ef Implementation of only the core F compression function allows substantial flexibility and extensibility while keeping changes at the protocol level to a minimum. This will allow functions like tree hashing, incremental hashing, and keyed, salted, and personalized hashing as well as variable length digests, none of which are currently available on the EVM. 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....0000d` 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 + +All EIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The EIP must explain how the author proposes to deal with these incompatibilities. EIP submissions without a sufficient backwards compatibility treatise may be rejected outright. + +## Test Cases + +Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Other EIPs can choose to include links to test cases if applicable. + +## Implementation + +The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details. + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 3bcce1dffc36f239d67740f3ac46e11dc25ecd17 Mon Sep 17 00:00:00 2001 From: Matt Luongo Date: Sun, 16 Jun 2019 00:52:55 -0400 Subject: [PATCH 129/137] Break backwards compatibility into its own section --- EIPS/eip-draft-blake2b-f-precompile.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/EIPS/eip-draft-blake2b-f-precompile.md b/EIPS/eip-draft-blake2b-f-precompile.md index 45608eed5b6ec..6a943865bd32d 100644 --- a/EIPS/eip-draft-blake2b-f-precompile.md +++ b/EIPS/eip-draft-blake2b-f-precompile.md @@ -19,7 +19,7 @@ This EIP will enable the Blake2b hash function to run cheaply on the EVM, allowi ## Abstract -This EIP introduces a new precompiled contract which implements the compression function F used in the BLAKE2b cryptographic hashing algorithm, for the purpose of allowing interoperability between the Zcash blockchain and the EVM, and introducing more flexible cryptographic hash primitives to the EVM. +This EIP introduces a new precompiled contract which implements the compression function `F` used in the BLAKE2b cryptographic hashing algorithm, for the purpose of allowing interoperability between the EVM and Zcash, as well as introducing more flexible cryptographic hash primitives to the EVM. ## Motivation @@ -33,7 +33,7 @@ Interoperability with Zcash could enable contracts like trustless atomic swaps b ## Specification -Adds a precompile at address `0x0000....0d` which accepts [ABI encoded](https://github.com/ethereum/wiki/wiki/Ethereum-Contract-ABI) arguments corresponding to the function signature +Adds a precompile at address `0x0d` which accepts [ABI encoded](https://github.com/ethereum/wiki/wiki/Ethereum-Contract-ABI) arguments corresponding to the function signature ``` F(bytes32[2] h, bytes32[4] m, uint t , bool f, uint rounds) returns (bytes32[2] h_new); @@ -54,11 +54,10 @@ In contrast, the big-endian 32 byte semantics of the EVM are not conducive to ef Implementation of only the core F compression function allows substantial flexibility and extensibility while keeping changes at the protocol level to a minimum. This will allow functions like tree hashing, incremental hashing, and keyed, salted, and personalized hashing as well as variable length digests, none of which are currently available on the EVM. -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....0000d` 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 -All EIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The EIP must explain how the author proposes to deal with these incompatibilities. EIP submissions without a sufficient backwards compatibility treatise may be rejected outright. + +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 `0x0d` 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. ## Test Cases From c3f4c685428ac1d8bd0169657a82ac067a7f8839 Mon Sep 17 00:00:00 2001 From: Matt Luongo Date: Sun, 16 Jun 2019 01:11:11 -0400 Subject: [PATCH 130/137] Added notes about the in-progress implementation Should have a working geth precompile and initial benchmarks shortly --- EIPS/eip-draft-blake2b-f-precompile.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-draft-blake2b-f-precompile.md b/EIPS/eip-draft-blake2b-f-precompile.md index 6a943865bd32d..7ae7ec7ae0a50 100644 --- a/EIPS/eip-draft-blake2b-f-precompile.md +++ b/EIPS/eip-draft-blake2b-f-precompile.md @@ -60,12 +60,16 @@ Implementation of only the core F compression function allows substantial flexib 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 `0x0d` 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. ## Test Cases + -Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Other EIPs can choose to include links to test cases if applicable. + +Test cases are in progress, and can be followed along in our [Golang Blake2 library fork](https://github.com/keep-network/blake2-f) as well as our fork of [go-ethereum](https://github.com/keep-network/go-ethereum). ## Implementation -The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details. + +Implementations are in progress, and can be followed along in our [Golang Blake2 library fork](https://github.com/keep-network/blake2-f) as well as our fork of [go-ethereum](https://github.com/keep-network/go-ethereum). ## Copyright + Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 92916e129b0f701c7814face19cf9d6608f008d0 Mon Sep 17 00:00:00 2001 From: Matt Luongo Date: Sun, 16 Jun 2019 17:45:57 -0400 Subject: [PATCH 131/137] Specify EIP-2046 as a requirement While 2046's cheaper precompile contract calls aren't a requirement for this EIP's implementation, shipping this precompile without EIP-2046 would make the F function expensive for some of the motivating usecases. --- EIPS/eip-draft-blake2b-f-precompile.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/EIPS/eip-draft-blake2b-f-precompile.md b/EIPS/eip-draft-blake2b-f-precompile.md index 7ae7ec7ae0a50..506b317120cb0 100644 --- a/EIPS/eip-draft-blake2b-f-precompile.md +++ b/EIPS/eip-draft-blake2b-f-precompile.md @@ -1,12 +1,13 @@ --- eip: -Title: Add Blake2 compression function `F` precompile -Author: Tjaden Hess , Matt Luongo (@mhluongo) +title: Add Blake2 compression function `F` precompile +author: Tjaden Hess , Matt Luongo (@mhluongo) discussions-to: https://ethereum-magicians.org/t/blake2b-f-precompile/3157 -Status: Draft +status: Draft type: Standards Track -category Core -Created 2016-10-04 +category: Core +created 2016-10-04 +requires: 2046 --- From 764ff73bca1702c6bbb582f52d77282ffd977d5e Mon Sep 17 00:00:00 2001 From: Matt Luongo Date: Thu, 20 Jun 2019 15:31:40 -0400 Subject: [PATCH 132/137] Don't use ABI encoding for precompile Replace the existing ABI encoding interface to the BLAKE2b `F` precompile with a loosely pack struct that's `staticcall`-friendly. H/t to @pdyraga for putting together the interface! --- EIPS/eip-draft-blake2b-f-precompile.md | 72 ++++++++++++++++++++++++-- 1 file changed, 69 insertions(+), 3 deletions(-) diff --git a/EIPS/eip-draft-blake2b-f-precompile.md b/EIPS/eip-draft-blake2b-f-precompile.md index 506b317120cb0..f23a16bbf788c 100644 --- a/EIPS/eip-draft-blake2b-f-precompile.md +++ b/EIPS/eip-draft-blake2b-f-precompile.md @@ -34,13 +34,79 @@ Interoperability with Zcash could enable contracts like trustless atomic swaps b ## Specification -Adds a precompile at address `0x0d` which accepts [ABI encoded](https://github.com/ethereum/wiki/wiki/Ethereum-Contract-ABI) arguments corresponding to the function signature +We propose adding a precompiled contract at address `0x09` wrapping the [BLAkE2b `F` compression function](https://tools.ietf.org/html/rfc7693#section-3.2). Rather than the ABI-encoded call structure proposed in [#152](https://github.com/ethereum/EIPs/issues/152), this design better matches other precompiles and works well with a standard `staticcall`. +The precompile requires 6 inputs, corresponding to the inputs specified in the [BLAKE2b RFC](https://tools.ietf.org/html/rfc7693#section-3.2) + +- `h` - the state vector +- `m` - the message block vector +- `t_0, t_1` - offset counters +- `f` - the final block indicator flag +- `rounds` - the number of rounds + +Loosely packing the data in equal 32-byte slots means an easier job for app developers, and also appears to be compatible with how other precompiles accept input data. + +``` +[ bytes32[0] | bytes32[1] ][ bytes32[2] | bytes32[3] | bytes32[4] | bytes32[5] ] +[ 64 bytes for h ][ 128 bytes for m ] + +[ bytes32[6] ][ bytes32[7] ] +[ 24 bytes padding | 8 bytes for t_0 ][ 24 bytes padding | 8 bytes for t_1 ] + +[ bytes32[8] ][ bytes32[9] ] +[ 31 bytes padding | 1 byte for f ][ 28 bytes padding | 4 bytes for rounds] ``` -F(bytes32[2] h, bytes32[4] m, uint t , bool f, uint rounds) returns (bytes32[2] h_new); + +The precompile can be wrapped easily in Solidity to provide a more development-friendly interface to `F`. + +```solidity + function F(bytes32[2] memory h, bytes32[4] memory m, uint64[2] memory t, bool f, uint32 rounds) public view returns (bytes32[2] memory) { + bytes32[2] memory output; + + bytes32 _t0 = bytes32(uint256(t[0])); + bytes32 _t1 = bytes32(uint256(t[1])); + + bytes32 _f; + if (f) { + _f = hex"0000000000000000000000000000000000000000000000000000000000000001"; + } + + bytes32 _rounds = bytes32(uint256(rounds)); + + bytes32[10] memory args = [ h[0], h[1], m[0], m[1], m[2], m[3], _t0, _t1, _f, _rounds ]; + + assembly { + if iszero(staticcall(not(0), 0x09, args, 0x140, output, 0x40)) { + revert(0, 0) + } + } + return output; + } + + function callF() public view returns (bytes32[2] memory) { + bytes32[2] memory h; + h[0] = hex"6a09e627f3bcc909bb67ae8484caa73b3c6ef372fe94b82ba54ff53a5f1d36f1"; + h[1] = hex"510e527fade682d19b05688c2b3e6c1f1f83d9abfb41bd6b5be0cd19137e2179"; + + bytes32[4] memory m; + m[0] = hex"278400340e6b05c5752592c52c4f121292eafc51cc01a997b4aed13409298fad"; + m[1] = hex"0d99ccc8f76453d9b3661e5c4d325d7751147db17489046d1682d50eefa4a1da"; + m[2] = hex"0000000000000000000000000000000000000000000000000000000000000000"; + m[3] = hex"0000000000000000000000000000000000000000000000000000000000000000"; + + uint64[2] memory t; + t[0] = 18446744073709551552; + t[1] = 18446744073709551615; + + bool f = true; + + uint32 rounds = 12; + + return F(h, m, t, f, rounds); + } ``` -where `h`, `m`, `t` and `f` are the current state, the new message, the byte counter and a finalization flag, as defined in [RFC 7693](https://tools.ietf.org/html/rfc7693), and `rounds` is the number of rounds of mixing to perform (BLAKE2b uses 12, BLAKE2s uses 10). `h_new` is the updated state of the hash. +### Gas costs and benchmarks Each operation will cost `GFROUND * rounds`. From 15c33529d06ca3f6a6e7eecf2984073d4e1f2176 Mon Sep 17 00:00:00 2001 From: Matt Luongo Date: Thu, 20 Jun 2019 15:37:53 -0400 Subject: [PATCH 133/137] Add @pdyraga to the EIP authors. --- EIPS/eip-draft-blake2b-f-precompile.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-draft-blake2b-f-precompile.md b/EIPS/eip-draft-blake2b-f-precompile.md index f23a16bbf788c..08f559da80fb1 100644 --- a/EIPS/eip-draft-blake2b-f-precompile.md +++ b/EIPS/eip-draft-blake2b-f-precompile.md @@ -1,7 +1,7 @@ --- eip: title: Add Blake2 compression function `F` precompile -author: Tjaden Hess , Matt Luongo (@mhluongo) +author: Tjaden Hess , Matt Luongo (@mhluongo), Piotr Dyraga (@pdyraga) discussions-to: https://ethereum-magicians.org/t/blake2b-f-precompile/3157 status: Draft type: Standards Track From 552e602db6c8c5c98457d0d4594226bdc6a68256 Mon Sep 17 00:00:00 2001 From: Matt Luongo Date: Thu, 20 Jun 2019 15:42:46 -0400 Subject: [PATCH 134/137] Remove less relevant EIP rationale Let's not relitigate precompiles, WASM, etc in thie EIP :) --- EIPS/eip-draft-blake2b-f-precompile.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/EIPS/eip-draft-blake2b-f-precompile.md b/EIPS/eip-draft-blake2b-f-precompile.md index 08f559da80fb1..afef34c684da7 100644 --- a/EIPS/eip-draft-blake2b-f-precompile.md +++ b/EIPS/eip-draft-blake2b-f-precompile.md @@ -113,9 +113,7 @@ Each operation will cost `GFROUND * rounds`. ## 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. - -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 little-endian arithmetic. These characteristics provide exceptional speed on native CPUs: 3.08 cycles per byte, or 1 gibibyte per second on an Intel i5. +BLAKE2b is an excellent candidate for precompilation. It exhibits an extremely asymetric efficiency. BLAKE2b is heavily optimized for modern 64-bit CPUs, specifically utilizing 24 and 63-bit rotations to allow parallelism through SIMD instructions and little-endian arithmetic. 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 5a293387b3db6733189af2413b59ca0eb997f28f Mon Sep 17 00:00:00 2001 From: Matt Luongo Date: Thu, 20 Jun 2019 15:44:35 -0400 Subject: [PATCH 135/137] Use 0x09 as the precompile address If a conflicting EIP is moving forward the EIP editor can assign a new address --- EIPS/eip-draft-blake2b-f-precompile.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-draft-blake2b-f-precompile.md b/EIPS/eip-draft-blake2b-f-precompile.md index afef34c684da7..6070e793f7143 100644 --- a/EIPS/eip-draft-blake2b-f-precompile.md +++ b/EIPS/eip-draft-blake2b-f-precompile.md @@ -122,7 +122,7 @@ Implementation of only the core F compression function allows substantial flexib ## 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 `0x0d` 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. +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 `0x09` 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. ## Test Cases From 5d203c4ae6ec24d6f7753971e6b3a35f116b609c Mon Sep 17 00:00:00 2001 From: Matt Luongo Date: Fri, 21 Jun 2019 08:20:14 -0400 Subject: [PATCH 136/137] Choosing an EIP number Contributing docs suggest EIPs be named `eip-draft-with-a-title` until an editor has been assigned, but discussing this work off-platform without a number is a problem. Assigning 152 as the issue number where the `F` precompile was originally raised (https://github.com/ethereum/EIPs/issues/152) --- EIPS/{eip-draft-blake2b-f-precompile.md => eip-152.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename EIPS/{eip-draft-blake2b-f-precompile.md => eip-152.md} (99%) diff --git a/EIPS/eip-draft-blake2b-f-precompile.md b/EIPS/eip-152.md similarity index 99% rename from EIPS/eip-draft-blake2b-f-precompile.md rename to EIPS/eip-152.md index 6070e793f7143..f19afaa99adea 100644 --- a/EIPS/eip-draft-blake2b-f-precompile.md +++ b/EIPS/eip-152.md @@ -1,5 +1,5 @@ --- -eip: +eip: 152 title: Add Blake2 compression function `F` precompile author: Tjaden Hess , Matt Luongo (@mhluongo), Piotr Dyraga (@pdyraga) discussions-to: https://ethereum-magicians.org/t/blake2b-f-precompile/3157 From 487aea3eb74c63598bd2b543d06dcffec16683bb Mon Sep 17 00:00:00 2001 From: James Hancock Date: Sun, 23 Jun 2019 21:59:35 -0400 Subject: [PATCH 137/137] Added References --- EIPS/eip-152.md | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-152.md b/EIPS/eip-152.md index f19afaa99adea..cd1074d59ed81 100644 --- a/EIPS/eip-152.md +++ b/EIPS/eip-152.md @@ -1,13 +1,12 @@ --- eip: 152 title: Add Blake2 compression function `F` precompile -author: Tjaden Hess , Matt Luongo (@mhluongo), Piotr Dyraga (@pdyraga) +author: Tjaden Hess , Matt Luongo (@mhluongo), Piotr Dyraga (@pdyraga), James Hancock (@madeoftin) discussions-to: https://ethereum-magicians.org/t/blake2b-f-precompile/3157 status: Draft type: Standards Track category: Core created 2016-10-04 -requires: 2046 --- @@ -135,6 +134,13 @@ Test cases are in progress, and can be followed along in our [Golang Blake2 libr Implementations are in progress, and can be followed along in our [Golang Blake2 library fork](https://github.com/keep-network/blake2-f) as well as our fork of [go-ethereum](https://github.com/keep-network/go-ethereum). +## References + +For historic purposes discussion on this EIP also occured in the following PRs. + + * [Original Issue](https://github.com/ethereum/EIPs/issues/152) + * [Keep Networks Updated PR 2129](https://github.com/ethereum/EIPs/pull/2129) + ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).