What’s in the Ethereum Classic Atlantis Hard Fork? Ain’t no code like an opcode
Ethereum Classic is going to Atlantis at block 8,772,000 or around September 17th this year! The Atlantis Fork includes a set of upgrades from the state-trie clearing, contract size limits, zkSNARKs, but ETC has some new opcodes in Atlantis too.
The Ethereum Virtual Machine (EVM) is a stack-based, big-endian VM with a word size of 256-bits and is used to run the smart contracts on the EVM based blockchain (ETC, ETH, etc…). Smart contracts run EVM bytecode when receiving a transaction, allowing them to perform computations (transactions). Contracts are executed at the beginning of the bytecode and each opcode is encoded as one byte, except for PUSH opcodes.
Solidity is a high-level programming language that we understand, but machines do not. When we run an Ethereum client such as Geth, Multi-Geth, or Parity Ethereum, it also comes with the operating system (the EVM) specifically created to run smart contracts. Opcodes are low-level instructions of the program we humans can understand. When we PUSH instructions to the EVM they get compiled into EVM bytecode which can be executed by the EVM and officially broadcasted to the network.
EIP140 REVERT, EIP658
There are two ways to revert a transaction from within a contract; running out of gas or executing an invalid transaction. Both options are expensive and information regarding the revert is lost with no LOGs or reasoning. EIP140’s 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.
EIP140 did not include a clear mechanism for callers to determine if a transaction succeeded or state changes were applied. Therefore, EIP658 replaces the intermediate state root with return status of 1 for success or 0 for failure. Read more on EIP140 or EIP658.
EIP211 RETURNDATASIZE & RETURNDATACOPY
EIP211 introduces a simple gas charging mechanism that allows the return of arbitrary length data inside the EVM. After a call, return data is kept inside a virtual buffer from which the caller can copy into memory. At the next call, the buffer is overwritten and so on.
Note that this proposal also makes the EIP that proposes to allow to return data in case of an intentional state reversion (EIP-140) much more useful. Since the size of the failure data might be larger than the regular return data (or even unknown), it is possible to retrieve the failure data after the CALL opcode has signaled a failure, even if the regular output area is not large enough to hold the data. Read more on EIP658.
EIP214 STATICCALL
As long as computation can be performed, then the state of a smart contract cannot be assumed. For example, performing a transaction with a DApp will only order your transaction when it is confirmed by miners. The STATICALL opcode allows users to call a contract and safely assume the state of all accounts is the same before and after the static call.
This new opcode is ideal for smart contract security because it allows contracts to make calls that are non-state-changing, reassuring developers and observers that re-entrancy bugs or other problems cannot arise. Since this opcode is not modifying other opcodes, it is simply provided pure output and backward compatible. Read more on EIP214.
