ECIP 1056: Agharta EVM and Protocol Upgrades

Simple Summary


Enable the outstanding Ethereum Foundation Constaninople and Petersburg network protocol upgrades on the Ethereum Classic network in a hard-fork code-named Agharta to enable maximum compatibility across these networks.


Abstract


Add support for a subset of protocol-impacting changes introduced in the Ethereum Foundation (ETH) network via the Constaninople and Petersburg hardforks. The proposed changes for Ethereum Classic’s Agharta upgrade include:

· Constantinople bitwise shifting instructions

· Constantinople skinny CREATE2 opcode

· Constantinople EXTCODEHASH opcode


This document proposes the following blocks at which to implement these changes in the Classic networks:


· 5_000_381 on Morden Classic Testnet (November 13, 2019)

· 301_243 on Mordor Classic Testnet (November 20, 2019)

· 1_705_549 on Kotti Classic Testnet (December 11, 2019)

· TBD on Ethereum Classic Mainnet (January 15, 2020)


For more information on the opcodes and their respective EIPs and implementations, please see the Specification section of this document.


Motivation


To enhance the Ethereum Virtual Machine’s (EVM) capabilities, various opcodes shall be added to the Ethereum Classic networks, all of which have been in use on the Ethereum Foundation networks since early 2019.


Specification


Enable the following three hard fork features:

· EIP 145 (Bitwise shifting instructions)

· EIP 1014 (Skinny CREATE2 opcode)

· EIP 1052 (EXTCODEHASH opcode)

Rationale


Atomicity: This protocol specification notably merges the scheduled features of the anticipated Petersburg protocol upgrade, which would removes the buggy proposal SSTORE net-gas metering.


Interoperability: Establishing and maintaining interoperable behavior between Ethereum clients is essential for developers and end-user adoption, yielding benefits for all participating chains (e.g., ETH and ETC, Ropsten and Morden, Görli and Kotti).


Immutability: None of the introduced new opcodes in the EVM has the potential to change the behavior of existing contracts; in the case where previously an arbitrary invalid bytecode would have been deployed to the network, none of them would be able to modify the state of the Ethereum Classic networks retrospectively. Adding opcodes to the EVM increases its functionality and should be considered a feature upgrade rather than a modification.


Implementation


Adoption of the content of this ECIP requires a hard fork as it introduces changes that are not backward compatible.


The following clients with Ethereum Classic support implement the Constaninople and Petersburg features currently:

· Geth Classic: full support in v6.1.0 and later

· Parity Ethereum: all features due to Ethereum Foundation compatibility

· Multi Geth: all features due to Ethereum Foundation compatibility

· IOHK Mantis: no support

· Hyperledger Besu: all features due to Ethereum Foundation compatibility


Copyright

Copyright and related rights waived via CC0.

Recent Posts

See All

ETC 피닉스 하드포크 업데이트 6월 1일 진행 예정

이더리움 클래식 메인넷은 다가오는 10.500.839블록에서 피닉스 하드포크를 활성화합니다. 예상 시점은 2020년 6월 1일입니다. 이번 하드포크는 아틀란티스, 아가타에 이어 이더리움 클래식의 세 번째 업그레이드입니다. 피닉스 하드포크 이후 이더리움 클래식과 이더리움은 완벽하게 호환되며 동일한 기능을 갖게 됩니다. 이번 하드포크의 주요 목표는 이더리움 이

LLVM을 사용하여 ETC 스마트 컨트랙트 언어 만들기 - 기타주제

LLVM IR 코드 생성 allocatea 명령은 현재 기능의 메모리 프레임에 32바이트 프레임 객체(기능-로컬 객체)를 할당. 메모리 공간 인덱싱 보통 EVM 스마트 계약 ABI 정보를 내보내는 것은 언어에 달려 있다. 하지만 우리는 계약서 ABI를 방출하기 위해 LLVM IR 패스를 작성할 수 있다. 제한 사항 EVM은 결정적 실행을 위해 설계되었습니다