Skip to content

Latest commit

 

History

History
41 lines (26 loc) · 2.28 KB

tip-318.md

File metadata and controls

41 lines (26 loc) · 2.28 KB
tip: 318
title: Adapt to Ethereum London Upgrade
author: neo.hong@tron.network
status: Final
type: Standards Track
category: VM
created: 2021-08-16

Abstract

  • Add a BASEFEE(0x48) that returns the value of the network parameter that defines the fee of 1 unit of Energy
  • Disallow new code starting with the 0xEF byte to be deployed. Code already existing in the code store starting with 0xEF byte is not affected semantically by this change.

Motivation

The Ethernet London Upgrade has been activated on its mainnet on August 5 2021 and this upgrade includes several new EIPs. As a fully EVM-compatible vm implementation for TRON network, TVM needs to introduce two of these changes involving virtual machines.

Specifications

Specification-A

Add a BASEFEE opcode at (0x48), with energy cost E_base(2).

The BASEFEE takes no operand pop up from the stack and push the value of the fee for 1 energy to the stack.

Specification-B

After the ALLOW_TVM_LONDON proposal approved, new contract creation (via deploy transaction, CREATE or CREATE2 instructions) results in an exceptional abort if the code’s first byte is 0xEF.

The initcode is the code executed in the context of the deploy transaction, CREATE, or CREATE2 instructions. The initcode returns code (via the RETURN instruction), which is inserted into the code store.

The opcode 0xEF is currently an undefined instruction, therefore: It pops no stack items and pushes no stack items, and it causes an exceptional abort when executed. This means initcode or already deployed code starting with this instruction will continue to abort execution.

The exceptional abort due to code starting with 0xEF behaves exactly the same as any other exceptional abort that can occur during initcode execution, i.e. in case of abort all gas provided to a CREATE* or deploy transaction is consumed.

Backwards Compatibility

For Specification-A, there are no known backward compatibility issues with the BASEFEE opcode.

For Specification-B, it is a breaking change given new code starting with the 0xEF byte will not be deployable, and contract creation will result in a failure. However, given bytecode is executed starting at its first byte, code deployed with 0xEF as the first byte is not executable anyway.