From cd26a35017456f92b6d1ab4dbccb0f621754d0a5 Mon Sep 17 00:00:00 2001 From: meows Date: Mon, 11 Feb 2019 10:01:07 -0600 Subject: [PATCH 01/10] Init bare file --- ECLIPs/ECLIP-etcbyz.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 ECLIPs/ECLIP-etcbyz.md diff --git a/ECLIPs/ECLIP-etcbyz.md b/ECLIPs/ECLIP-etcbyz.md new file mode 100644 index 0000000..e69de29 From d9813d95aaa8053039729aaa18198c54385dd6dd Mon Sep 17 00:00:00 2001 From: meows Date: Mon, 11 Feb 2019 10:05:46 -0600 Subject: [PATCH 02/10] Init copy ECIP-1045 --- ECLIPs/ECLIP-etcbyz.md | 97 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 97 insertions(+) diff --git a/ECLIPs/ECLIP-etcbyz.md b/ECLIPs/ECLIP-etcbyz.md index e69de29..b0c194b 100644 --- a/ECLIPs/ECLIP-etcbyz.md +++ b/ECLIPs/ECLIP-etcbyz.md @@ -0,0 +1,97 @@ +### ECLIP-1045: Support for ETH Byzantium & Constantinople EVM and Protocol Upgrades + + ECIP: 1045/undecided + Title: Support for ETH Byzantium & Constantinople EVM and Protocol Upgrades + Status: Draft + Type: Standard Track + Author: Isaac Ardis + Created: 2018-06-18 + + +### Abstract + +Add support for a subset of protocol-impacting changes introduced in the Ethereum Foundation (ETH) network via the _Byzantium_ hardfork. The proposed changes include: + +- Byzantium EVM opcodes and precompiled contracts, namely opcodes `REVERT` (EIP 206/140), `RETURNDATASIZE` (EIP 211), `RETURNDATACOPY` (EIP 211), and `STATICCALL` (EIP 214/116); and precompiled contracts for modular exponentiation, elliptic curve addition, scalar multiplication, and pairing (EIPs 198, 212/197, 213/196) +- Expected Constantinople EVM opcodes, namely bitwise shifting operators `SHL`, `SHR`, and `SAR` (EIP 215); `CREATE2` (EIP 1014); and `EXTCODEHASH` (EIP 1052). + + TODO: Research and discuss gas metering changes for `SSTORE`, proposed in EIP 1283. +- Replacing the intermediate state root field in transaction receipts with the contract return status (EIP 658). + +This document proposes block `7,100,000` as the upcoming block height at which to implement these changes in the network, placing the expected date of protocol hardfork in January 2019. + +For more information on the opcodes and their respective EIPs and implementations, please see the __History__ section of this document. + +### Motivation + +To enable and maintain interoperability between Foundation and Classic Ethereum Virtual Machines ("EVM"s). + +### Specification + +As per associated EIPs's specifications and implementations, and success determined by interoperability (implementation) of smart contracts utilizing the introduced opcode and precompiled contracts (implementation before technical specification in case of discrepency). + +### Rationale + +__Interoperability__: establishing and maintaining interoperable behavior between Ethereum clients is important for developers and end-user adoption, yielding benefits for all participating chains (eg. ETH and ETC). + +__On Immutability__: Introducing new opcodes in the VM has the potential to change behavior of existing contracts; in the case where previously an arbitrary invalid bytecode series (yielding _invalid opcode_) would now be assigned a meaning, and thus could generate or return a value other than _invalid_. In essence, this means "making music where there was only noise before." There is a concern that this behavior change contradicts an essential promise of Immutability, since an existing failing smart contract is liable to become a succeeding (not failing) contract. In counterargument to this concern are two critical points: + +1. account states remain changed +2. the "Homestead" hardfork established a precedent for this type of change, having introduced the `DELEGATECALL` opcode at block 1,150,000. + +With these arguments in place, along with precedence and expectation for other continuing and varied consensus-impacting protocol upgrades (eg soft- and hard-forks), it follows that the definition of Immutability is not extended to guarantee perfect consistency for future _behavior_ of historical account states, but only to only to guarantee the immutability of the account states themselves. + +### Implementation + +Adoption of the content of this ECIP requires a hard fork, and herein that adoption is proposed to be scheduled for block 7,100,000, roughly estimated to arrive in January 2019. + +The `ethereumproject/go-ethereum` client implemented an API-only (non-consensus impacting) partial adoption of EIP-658 Transaction status code change via the [v5.5.0](https://github.com/ethereumproject/go-ethereum/releases/tag/v5.5.0) release, and this proposal would augment that change to extend through to the RLP encoding (and thus modify consensus protocol). + +### History + +##### Byzantium changes + +These changes were introduced in the Ethereum Foundation go-ethereum client via the [1.7 "Megara" release](https://github.com/ethereum/go-ethereum/releases/tag/v1.7.0). + +These changes were catalogued via the EIP process in the following: + +- EIP-658: Transaction receipts embedding status code instead of intermediate state root field - https://github.com/ethereum/EIPs/pull/658 + +- EIP-140: `REVERT` - https://github.com/ethereum/EIPs/pull/206/files + +> The `REVERT` instruction provides a way to stop execution and revert state changes, without consuming all provided gas and with the ability to return a reason. + + +- EIP-211: `RETURNDATASIZE`, `RETURNDATACOPY` - https://github.com/ethereum/EIPs/pull/211/files + +> A mechanism to allow returning arbitrary-length data inside the EVM has been requested for quite a while now. Existing proposals always had very intricate problems associated with charging gas. This proposal solves the same problem while at the same time, it has a very simple gas charging mechanism and requires minimal changes to the call opcodes. Its workings are very similar to the way calldata is handled already; after a call, return data is kept inside a virtual buffer from which the caller can copy it (or parts thereof) into memory. At the next call, the buffer is overwritten. This mechanism is 100% backwards compatible. + + +- EIP-214: `STATICCALL` - https://github.com/ethereum/EIPs/pull/214/files + +> To increase smart contract security, this proposal adds a new opcode that can be used to call another contract (or itself) while disallowing any modifications to the state during the call (and its subcalls, if present). + +- EIP-198: Precompiled contract for modular exponentiation - https://github.com/ethereum/EIPs/pull/198 + +- EIP-212: Precompiled contract for elliptic curve pairing - https://github.com/ethereum/EIPs/pull/212 + +- EIP-213: Precompiled contract for elliptic curve addition and scalar multiplication - https://github.com/ethereum/EIPs/pull/213 + +##### Constantinople changes + +These changes are _expected_ to be implemented by the anticipated Constantinople hard fork, which _may_ take place on the ETH network sometime near October 30, 2018, although to date no block number configuration has been accepted to the master branch of the ethereum/go-ethereum client. + +- EIP-215:(replacing EIP-145) (https://github.com/ethereum/EIPs/pull/215): Introduce bitwise shifting + +> To provide native bitwise shifting with cost on par with other arithmetic operations. + +- EIP-1014 (https://github.com/ethereum/EIPs/pull/1247): Use keccak256 name instead of sha3 (`CREATE2`) + +> Adds a new opcode at 0xf5, which takes 4 stack arguments: endowment, memory_start, memory_length, salt. Behaves identically to CREATE, except using `keccak256(msg.sender ++ salt ++ init_code)[12:]` instead of the usual sender-and-nonce-hash as the address where the contract is initialized at. + +- EIP-1052 (https://github.com/ethereum/EIPs/pull/1052): `EXTCODEHASH` opcode + +> Returns the keccak256 hash of a contract's code + + + + From 5448cb500f97f06997f187262c4c5c303955d839 Mon Sep 17 00:00:00 2001 From: meows Date: Mon, 11 Feb 2019 10:56:43 -0600 Subject: [PATCH 03/10] Swap ECIP for ECLIP, remove Const. from Header --- ECLIPs/ECLIP-etcbyz.md | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/ECLIPs/ECLIP-etcbyz.md b/ECLIPs/ECLIP-etcbyz.md index b0c194b..73bc9f0 100644 --- a/ECLIPs/ECLIP-etcbyz.md +++ b/ECLIPs/ECLIP-etcbyz.md @@ -1,12 +1,11 @@ -### ECLIP-1045: Support for ETH Byzantium & Constantinople EVM and Protocol Upgrades +### ECLIP-?: Support for ETH Byzantium EVM and Protocol Upgrades - ECIP: 1045/undecided - Title: Support for ETH Byzantium & Constantinople EVM and Protocol Upgrades + ECLIP: undecided + Title: Support for ETH Byzantium EVM and Protocol Upgrades Status: Draft - Type: Standard Track - Author: Isaac Ardis - Created: 2018-06-18 - + Type: Standards Track + Author: Isaac Ardis + Created: 2019-02-11 ### Abstract @@ -42,7 +41,7 @@ With these arguments in place, along with precedence and expectation for other c ### Implementation -Adoption of the content of this ECIP requires a hard fork, and herein that adoption is proposed to be scheduled for block 7,100,000, roughly estimated to arrive in January 2019. +Adoption of the content of this ECLIP requires a hard fork, and herein that adoption is proposed to be scheduled for block 7,100,000, roughly estimated to arrive in January 2019. The `ethereumproject/go-ethereum` client implemented an API-only (non-consensus impacting) partial adoption of EIP-658 Transaction status code change via the [v5.5.0](https://github.com/ethereumproject/go-ethereum/releases/tag/v5.5.0) release, and this proposal would augment that change to extend through to the RLP encoding (and thus modify consensus protocol). From 55c44609b989781ec198855eabeb347c3fc6f2b6 Mon Sep 17 00:00:00 2001 From: meows Date: Mon, 11 Feb 2019 11:42:40 -0600 Subject: [PATCH 04/10] Remove Constantinople specs and undefine ETA Along w/ a few other minor grammatical tweaks --- ECLIPs/ECLIP-etcbyz.md | 43 ++++++++++++------------------------------ 1 file changed, 12 insertions(+), 31 deletions(-) diff --git a/ECLIPs/ECLIP-etcbyz.md b/ECLIPs/ECLIP-etcbyz.md index 73bc9f0..44dedbc 100644 --- a/ECLIPs/ECLIP-etcbyz.md +++ b/ECLIPs/ECLIP-etcbyz.md @@ -12,21 +12,19 @@ Add support for a subset of protocol-impacting changes introduced in the Ethereum Foundation (ETH) network via the _Byzantium_ hardfork. The proposed changes include: - Byzantium EVM opcodes and precompiled contracts, namely opcodes `REVERT` (EIP 206/140), `RETURNDATASIZE` (EIP 211), `RETURNDATACOPY` (EIP 211), and `STATICCALL` (EIP 214/116); and precompiled contracts for modular exponentiation, elliptic curve addition, scalar multiplication, and pairing (EIPs 198, 212/197, 213/196) -- Expected Constantinople EVM opcodes, namely bitwise shifting operators `SHL`, `SHR`, and `SAR` (EIP 215); `CREATE2` (EIP 1014); and `EXTCODEHASH` (EIP 1052). - + TODO: Research and discuss gas metering changes for `SSTORE`, proposed in EIP 1283. - Replacing the intermediate state root field in transaction receipts with the contract return status (EIP 658). -This document proposes block `7,100,000` as the upcoming block height at which to implement these changes in the network, placing the expected date of protocol hardfork in January 2019. +This document proposes block `X,XXX,XXX` as the upcoming block height at which to implement these changes in the network, placing the expected date of protocol hardfork date on _XXXX-XX-XX_. For more information on the opcodes and their respective EIPs and implementations, please see the __History__ section of this document. ### Motivation -To enable and maintain interoperability between Foundation and Classic Ethereum Virtual Machines ("EVM"s). +To enable and maintain interoperability between Foundation and Classic Ethereum Virtual Machines ("EVM"s). This protocol specification notably omits the scheduled features of the anticipated _Constantinople_ fork, which would be expected to include various further EVM upgrades. The reasoning for this omission hinges on a hedge toward battle-testing of those changes in light of multiple delays of that fork ([here](https://medium.com/ethereum-cat-herders/a-post-mortem-report-the-constantinople-ethereum-hard-fork-postponement-dd780d7ae63d), a postmortem of the latest delay) due to security and implementation discrepencies. ### Specification -As per associated EIPs's specifications and implementations, and success determined by interoperability (implementation) of smart contracts utilizing the introduced opcode and precompiled contracts (implementation before technical specification in case of discrepency). +As per associated EIPs's specifications and implementations, with feature-readiness determined by interoperability (implementation) of smart contracts utilizing the introduced opcode and precompiled contracts (implementation before technical specification in case of discrepency). Technical specifications for each EIP can be found at those documents respectively. ### Rationale @@ -41,19 +39,21 @@ With these arguments in place, along with precedence and expectation for other c ### Implementation -Adoption of the content of this ECLIP requires a hard fork, and herein that adoption is proposed to be scheduled for block 7,100,000, roughly estimated to arrive in January 2019. +Adoption of the content of this ECLIP requires a hard fork, and herein that adoption is proposed to be scheduled for block X,XXX,XXX roughly estimated to arrive _XXXX-XX-XX_. The `ethereumproject/go-ethereum` client implemented an API-only (non-consensus impacting) partial adoption of EIP-658 Transaction status code change via the [v5.5.0](https://github.com/ethereumproject/go-ethereum/releases/tag/v5.5.0) release, and this proposal would augment that change to extend through to the RLP encoding (and thus modify consensus protocol). +ETC Labs Core plans to advocate and support the adoption of [ethoxy/multi-geth](https://github.com/ethoxy/multi-geth) as a fully-featured and maintenance-scheduled client for this fork and beyond. + ### History ##### Byzantium changes -These changes were introduced in the Ethereum Foundation go-ethereum client via the [1.7 "Megara" release](https://github.com/ethereum/go-ethereum/releases/tag/v1.7.0). +These changes were introduced in the `ethereum/go-ethereum` client via the [1.7 "Megara" release](https://github.com/ethereum/go-ethereum/releases/tag/v1.7.0). -These changes were catalogued via the EIP process in the following: +These changes are catalogued via the EIP process in the following: -- EIP-658: Transaction receipts embedding status code instead of intermediate state root field - https://github.com/ethereum/EIPs/pull/658 +- EIP-658: Transaction receipts embedding status code instead of intermediate state root field - https://github.com/ethereum/EIPs/pull/658/files - EIP-140: `REVERT` - https://github.com/ethereum/EIPs/pull/206/files @@ -69,28 +69,9 @@ These changes were catalogued via the EIP process in the following: > To increase smart contract security, this proposal adds a new opcode that can be used to call another contract (or itself) while disallowing any modifications to the state during the call (and its subcalls, if present). -- EIP-198: Precompiled contract for modular exponentiation - https://github.com/ethereum/EIPs/pull/198 - -- EIP-212: Precompiled contract for elliptic curve pairing - https://github.com/ethereum/EIPs/pull/212 - -- EIP-213: Precompiled contract for elliptic curve addition and scalar multiplication - https://github.com/ethereum/EIPs/pull/213 - -##### Constantinople changes - -These changes are _expected_ to be implemented by the anticipated Constantinople hard fork, which _may_ take place on the ETH network sometime near October 30, 2018, although to date no block number configuration has been accepted to the master branch of the ethereum/go-ethereum client. - -- EIP-215:(replacing EIP-145) (https://github.com/ethereum/EIPs/pull/215): Introduce bitwise shifting - -> To provide native bitwise shifting with cost on par with other arithmetic operations. - -- EIP-1014 (https://github.com/ethereum/EIPs/pull/1247): Use keccak256 name instead of sha3 (`CREATE2`) - -> Adds a new opcode at 0xf5, which takes 4 stack arguments: endowment, memory_start, memory_length, salt. Behaves identically to CREATE, except using `keccak256(msg.sender ++ salt ++ init_code)[12:]` instead of the usual sender-and-nonce-hash as the address where the contract is initialized at. - -- EIP-1052 (https://github.com/ethereum/EIPs/pull/1052): `EXTCODEHASH` opcode - -> Returns the keccak256 hash of a contract's code - +- EIP-198: Precompiled contract for modular exponentiation - https://github.com/ethereum/EIPs/pull/198/files +- EIP-212: Precompiled contract for elliptic curve pairing - https://github.com/ethereum/EIPs/pull/212/files +- EIP-213: Precompiled contracts for elliptic curve addition and scalar multiplication - https://github.com/ethereum/EIPs/pull/213/files From 9081155c581989c5e0df89ea9671889c46ea2bdb Mon Sep 17 00:00:00 2001 From: Zac Mitton Date: Tue, 12 Feb 2019 08:06:50 -0600 Subject: [PATCH 05/10] Update ECLIPs/ECLIP-etcbyz.md Fixes EIP658 name; Tx status code -> receipt status code Co-Authored-By: meowsbits <45600330+meowsbits@users.noreply.github.com> --- ECLIPs/ECLIP-etcbyz.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ECLIPs/ECLIP-etcbyz.md b/ECLIPs/ECLIP-etcbyz.md index 44dedbc..fb79e56 100644 --- a/ECLIPs/ECLIP-etcbyz.md +++ b/ECLIPs/ECLIP-etcbyz.md @@ -41,7 +41,7 @@ With these arguments in place, along with precedence and expectation for other c Adoption of the content of this ECLIP requires a hard fork, and herein that adoption is proposed to be scheduled for block X,XXX,XXX roughly estimated to arrive _XXXX-XX-XX_. -The `ethereumproject/go-ethereum` client implemented an API-only (non-consensus impacting) partial adoption of EIP-658 Transaction status code change via the [v5.5.0](https://github.com/ethereumproject/go-ethereum/releases/tag/v5.5.0) release, and this proposal would augment that change to extend through to the RLP encoding (and thus modify consensus protocol). +The `ethereumproject/go-ethereum` client implemented an API-only (non-consensus impacting) partial adoption of EIP-658 receipt status code change via the [v5.5.0](https://github.com/ethereumproject/go-ethereum/releases/tag/v5.5.0) release, and this proposal would augment that change to extend through to the RLP encoding (and thus modify consensus protocol). ETC Labs Core plans to advocate and support the adoption of [ethoxy/multi-geth](https://github.com/ethoxy/multi-geth) as a fully-featured and maintenance-scheduled client for this fork and beyond. From b07af653d3054004c35864ad5ea6ef4bcbfcc541 Mon Sep 17 00:00:00 2001 From: meows Date: Tue, 12 Feb 2019 08:24:40 -0600 Subject: [PATCH 06/10] Revise motivation section Prioritize the actual outcomes of the proposed features, not first the case of interoperability. Rel https://github.com/etclabscore/ECLIPs/pull/2#discussion_r255920563 --- ECLIPs/.#ECLIP-etcbyz.md | 1 + ECLIPs/ECLIP-etcbyz.md | 4 +++- 2 files changed, 4 insertions(+), 1 deletion(-) create mode 120000 ECLIPs/.#ECLIP-etcbyz.md diff --git a/ECLIPs/.#ECLIP-etcbyz.md b/ECLIPs/.#ECLIP-etcbyz.md new file mode 120000 index 0000000..87495b9 --- /dev/null +++ b/ECLIPs/.#ECLIP-etcbyz.md @@ -0,0 +1 @@ +ia@ubp52.17806:1549812866 \ No newline at end of file diff --git a/ECLIPs/ECLIP-etcbyz.md b/ECLIPs/ECLIP-etcbyz.md index fb79e56..96d40a1 100644 --- a/ECLIPs/ECLIP-etcbyz.md +++ b/ECLIPs/ECLIP-etcbyz.md @@ -20,7 +20,9 @@ For more information on the opcodes and their respective EIPs and implementation ### Motivation -To enable and maintain interoperability between Foundation and Classic Ethereum Virtual Machines ("EVM"s). This protocol specification notably omits the scheduled features of the anticipated _Constantinople_ fork, which would be expected to include various further EVM upgrades. The reasoning for this omission hinges on a hedge toward battle-testing of those changes in light of multiple delays of that fork ([here](https://medium.com/ethereum-cat-herders/a-post-mortem-report-the-constantinople-ethereum-hard-fork-postponement-dd780d7ae63d), a postmortem of the latest delay) due to security and implementation discrepencies. +To enhance the EVM's capabilities by adding 5 opcodes and 4 precompiled contracts, all of which have been in use on the ETH network since 2017-10-16. Adoption of the "receipt status" feature provides a helpful method for Dapp developers to access the successful or failed state a contact. This would (re)establish a greater level of interoperability between Foundation and Classic Ethereum Virtual Machines ("EVM"s), and make a wider array of tooling available for the ETC network (eg. Solidity version, several contract debugging tools). + +This protocol specification notably omits the scheduled features of the anticipated _Constantinople_ fork, which would be expected to include various further EVM upgrades. The reasoning for this omission hinges on a hedge toward battle-testing of those changes in light of multiple delays of that fork ([here](https://medium.com/ethereum-cat-herders/a-post-mortem-report-the-constantinople-ethereum-hard-fork-postponement-dd780d7ae63d), a postmortem of the latest delay) due to security and implementation discrepencies. ### Specification From 9dfa5dc33032f84e933730d2b5b9dceefc8ed3bc Mon Sep 17 00:00:00 2001 From: meows Date: Tue, 12 Feb 2019 08:34:57 -0600 Subject: [PATCH 07/10] Fix typo, add note about strangeness of 'unbreaking opcode' case Rel https://github.com/etclabscore/ECLIPs/pull/2#discussion_r255923767 --- ECLIPs/.#ECLIP-etcbyz.md | 1 - ECLIPs/ECLIP-etcbyz.md | 9 ++++----- 2 files changed, 4 insertions(+), 6 deletions(-) delete mode 120000 ECLIPs/.#ECLIP-etcbyz.md diff --git a/ECLIPs/.#ECLIP-etcbyz.md b/ECLIPs/.#ECLIP-etcbyz.md deleted file mode 120000 index 87495b9..0000000 --- a/ECLIPs/.#ECLIP-etcbyz.md +++ /dev/null @@ -1 +0,0 @@ -ia@ubp52.17806:1549812866 \ No newline at end of file diff --git a/ECLIPs/ECLIP-etcbyz.md b/ECLIPs/ECLIP-etcbyz.md index 96d40a1..672039b 100644 --- a/ECLIPs/ECLIP-etcbyz.md +++ b/ECLIPs/ECLIP-etcbyz.md @@ -20,7 +20,7 @@ For more information on the opcodes and their respective EIPs and implementation ### Motivation -To enhance the EVM's capabilities by adding 5 opcodes and 4 precompiled contracts, all of which have been in use on the ETH network since 2017-10-16. Adoption of the "receipt status" feature provides a helpful method for Dapp developers to access the successful or failed state a contact. This would (re)establish a greater level of interoperability between Foundation and Classic Ethereum Virtual Machines ("EVM"s), and make a wider array of tooling available for the ETC network (eg. Solidity version, several contract debugging tools). +To enhance the EVM's capabilities by adding 5 opcodes and 4 precompiled contracts, all of which have been in use on the ETH network since 2017-10-16. Adoption of the "receipt status" feature provides a helpful method for Dapp developers to access the successful or failed state a contact. This would (re)establish a greater level of interoperability between Foundation and Classic Ethereum Virtual Machines ("EVM"s), and make a wider array of tooling available for the ETC network (eg. Solidity version, several contract debugging tools). This protocol specification notably omits the scheduled features of the anticipated _Constantinople_ fork, which would be expected to include various further EVM upgrades. The reasoning for this omission hinges on a hedge toward battle-testing of those changes in light of multiple delays of that fork ([here](https://medium.com/ethereum-cat-herders/a-post-mortem-report-the-constantinople-ethereum-hard-fork-postponement-dd780d7ae63d), a postmortem of the latest delay) due to security and implementation discrepencies. @@ -30,11 +30,11 @@ As per associated EIPs's specifications and implementations, with feature-readin ### Rationale -__Interoperability__: establishing and maintaining interoperable behavior between Ethereum clients is important for developers and end-user adoption, yielding benefits for all participating chains (eg. ETH and ETC). +__Interoperability__: establishing and maintaining interoperable behavior between Ethereum clients is important for developers and end-user adoption, yielding benefits for all participating chains (eg. ETH and ETC). -__On Immutability__: Introducing new opcodes in the VM has the potential to change behavior of existing contracts; in the case where previously an arbitrary invalid bytecode series (yielding _invalid opcode_) would now be assigned a meaning, and thus could generate or return a value other than _invalid_. In essence, this means "making music where there was only noise before." There is a concern that this behavior change contradicts an essential promise of Immutability, since an existing failing smart contract is liable to become a succeeding (not failing) contract. In counterargument to this concern are two critical points: +__On Immutability__: Introducing new opcodes in the VM has the potential to change behavior of existing contracts; in the case where previously an arbitrary invalid bytecode series (yielding _invalid opcode_) would now be assigned a meaning, and thus could generate or return a value other than _invalid_. In essence, this means "possibly making music where there was only noise before." There is a concern that this behavior change contradicts an essential promise of Immutability, since an existing failing smart contract is liable to become a succeeding (not failing) contract, albeit in a hypothetical case of extreme coincidence and gross misuse of an opcode. In counterargument to this concern are two critical points: -1. account states remain changed +1. account states remain unchanged 2. the "Homestead" hardfork established a precedent for this type of change, having introduced the `DELEGATECALL` opcode at block 1,150,000. With these arguments in place, along with precedence and expectation for other continuing and varied consensus-impacting protocol upgrades (eg soft- and hard-forks), it follows that the definition of Immutability is not extended to guarantee perfect consistency for future _behavior_ of historical account states, but only to only to guarantee the immutability of the account states themselves. @@ -76,4 +76,3 @@ These changes are catalogued via the EIP process in the following: - EIP-212: Precompiled contract for elliptic curve pairing - https://github.com/ethereum/EIPs/pull/212/files - EIP-213: Precompiled contracts for elliptic curve addition and scalar multiplication - https://github.com/ethereum/EIPs/pull/213/files - From 210894061ebc7d89cb8f6d2877da351bb59ba16d Mon Sep 17 00:00:00 2001 From: meows Date: Tue, 12 Feb 2019 08:41:38 -0600 Subject: [PATCH 08/10] Add Rationale conclusion note about feature upgrade Rel https://github.com/etclabscore/ECLIPs/pull/2#discussion_r255925157 --- ECLIPs/ECLIP-etcbyz.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/ECLIPs/ECLIP-etcbyz.md b/ECLIPs/ECLIP-etcbyz.md index 672039b..b257c44 100644 --- a/ECLIPs/ECLIP-etcbyz.md +++ b/ECLIPs/ECLIP-etcbyz.md @@ -39,6 +39,8 @@ __On Immutability__: Introducing new opcodes in the VM has the potential to chan With these arguments in place, along with precedence and expectation for other continuing and varied consensus-impacting protocol upgrades (eg soft- and hard-forks), it follows that the definition of Immutability is not extended to guarantee perfect consistency for future _behavior_ of historical account states, but only to only to guarantee the immutability of the account states themselves. +Adding opcodes and precompiled contracts to the EVM increases its functionality (only in an extremely rare case of gross misuse would be seen to _change_ it's functionality), and should be considered a feature upgrade rather than a modification. + ### Implementation Adoption of the content of this ECLIP requires a hard fork, and herein that adoption is proposed to be scheduled for block X,XXX,XXX roughly estimated to arrive _XXXX-XX-XX_. From eef2e02e02d3332245c923d66ec5f4f721a2eca3 Mon Sep 17 00:00:00 2001 From: Zachary Belford Date: Tue, 19 Feb 2019 07:06:42 -0600 Subject: [PATCH 09/10] Update ECLIPs/ECLIP-etcbyz.md Fixes typo. Co-Authored-By: meowsbits <45600330+meowsbits@users.noreply.github.com> --- ECLIPs/ECLIP-etcbyz.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ECLIPs/ECLIP-etcbyz.md b/ECLIPs/ECLIP-etcbyz.md index b257c44..1da36e3 100644 --- a/ECLIPs/ECLIP-etcbyz.md +++ b/ECLIPs/ECLIP-etcbyz.md @@ -20,7 +20,7 @@ For more information on the opcodes and their respective EIPs and implementation ### Motivation -To enhance the EVM's capabilities by adding 5 opcodes and 4 precompiled contracts, all of which have been in use on the ETH network since 2017-10-16. Adoption of the "receipt status" feature provides a helpful method for Dapp developers to access the successful or failed state a contact. This would (re)establish a greater level of interoperability between Foundation and Classic Ethereum Virtual Machines ("EVM"s), and make a wider array of tooling available for the ETC network (eg. Solidity version, several contract debugging tools). +To enhance the EVM's capabilities by adding 5 opcodes and 4 precompiled contracts, all of which have been in use on the ETH network since 2017-10-16. Adoption of the "receipt status" feature provides a helpful method for Dapp developers to access the successful or failed state of a contract. This would (re)establish a greater level of interoperability between Foundation and Classic Ethereum Virtual Machines ("EVM"s), and make a wider array of tooling available for the ETC network (eg. Solidity version, several contract debugging tools). This protocol specification notably omits the scheduled features of the anticipated _Constantinople_ fork, which would be expected to include various further EVM upgrades. The reasoning for this omission hinges on a hedge toward battle-testing of those changes in light of multiple delays of that fork ([here](https://medium.com/ethereum-cat-herders/a-post-mortem-report-the-constantinople-ethereum-hard-fork-postponement-dd780d7ae63d), a postmortem of the latest delay) due to security and implementation discrepencies. From 4113214861b81f5718af94cad777152ef10158fd Mon Sep 17 00:00:00 2001 From: Zachary Belford Date: Tue, 19 Feb 2019 07:08:14 -0600 Subject: [PATCH 10/10] Update ECLIPs/ECLIP-etcbyz.md Makes sentence more assertive. Co-Authored-By: meowsbits <45600330+meowsbits@users.noreply.github.com> --- ECLIPs/ECLIP-etcbyz.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ECLIPs/ECLIP-etcbyz.md b/ECLIPs/ECLIP-etcbyz.md index 1da36e3..11ecafb 100644 --- a/ECLIPs/ECLIP-etcbyz.md +++ b/ECLIPs/ECLIP-etcbyz.md @@ -47,7 +47,7 @@ Adoption of the content of this ECLIP requires a hard fork, and herein that adop The `ethereumproject/go-ethereum` client implemented an API-only (non-consensus impacting) partial adoption of EIP-658 receipt status code change via the [v5.5.0](https://github.com/ethereumproject/go-ethereum/releases/tag/v5.5.0) release, and this proposal would augment that change to extend through to the RLP encoding (and thus modify consensus protocol). -ETC Labs Core plans to advocate and support the adoption of [ethoxy/multi-geth](https://github.com/ethoxy/multi-geth) as a fully-featured and maintenance-scheduled client for this fork and beyond. +ETC Labs Core advocates and supports the adoption of [ethoxy/multi-geth](https://github.com/ethoxy/multi-geth) as a fully-featured and maintenance-scheduled client for this fork and beyond. ### History