EIP-5478: CREATE2COPY Opcode

eip: 5478
title: CREATE2COPY Opcode
description: Reducing the gas cost of contract creation with existing code
author: Qi Zhou (@qizhou)
discussions-to: EIP-5478: CREATE2COPY Opcode
status: Draft
type: Standards Track
category: Core
created: 2022-08-17
requires: 1014, 2929

that’s a great idea. but instead of introducing a new opcode, did you try to implement this by creating a constructor that accepts an address (and parameters) and uses extcodecopy (instead of calldata)? you will still pay for memory expansion but I think it might be cheaper still. also this works around introducing a new opcode.

Thanks for the comment. We could definitively use extcodecopy to exactly copy the code from another contract in init_code of CREATE/CREATE2, however, this means that for every byte in the code to be copied, the tx needs to pay 200 gas. For example, copying a contract with 10K bytes code will cost 200 * 10K = 2M gas!

The CREATE2COPY opcode addresses this issue by charging only 2600 (for cold account access). This would save the gas cost from 2M to 2600.

I hope this could explain. Feel free to let me know if you have further question.

(correction in the posts below)

I’m not sure where you brought that 200 gas comes from.
I ran a test, please correct me if I’m wrong:

PUSH1 0x40 ; len
PUSH1 0x00 ; dst offset
PUSH1 0x00 ; src offset
ADDRESS    ; addr to copy from (address(this))
PUSH1 0x00 ; just to verify it was copied properly

execute by the running the following:

evm --json --code 604060006000303c600051 run










I have marked in bold the gas used by EXTCODECOPY: 0x70 for 2 words (0x40). notice that for 3 words (0x41~0x60) the gas cost is increase by 6 to 0x76.

The 200 gas per byte is from CREATE2/CREATE2, where the code here only copies the code in memory, but the code is not yet stored as a contract code. Hope this could explain.

Ah my mistake.

I understand now; I interpreted each byte to copy as the cost of EXTCODECOPY. you were talking about deposit gas price, here’s a reference:

1 Like

Yes, that is exactly the EIP is optimizing for :slight_smile:

My attempt at something like this was Skinniest CREATELINK by wjmelements · Pull Request #2185 · ethereum/EIPs · GitHub
I think there are benefits to recognizing that many contracts might have identical code.

1 Like

Agree! I think CREATE2COPY and CREATELINK can co-exist as they serve a bit different purposes:

  • CREATE2COPY can be used to create a contract with a constructor, which initializes contract storage based on ctor logic;
  • CREATELINK can be used to create a “blank” contract. The contract may be have a initialize() method to initialize the storage such as owner, initial parameters, etc.

This EIP seems very limited due fact of popularity of “immutable” values, since they are part of the byte code.

1 Like

If there are “immutable” values, then the contract_code will be generated by init_code, which will be generally different even though most of the parts are the same. Yes, we cannot save any store cost of the contract anymore in this case.

However, it depends on which type of contract we want to copy, e.g., in the smart wallet case, if the operator wants to create millions of such smart wallet contracts with minimal storage cost, then the operator may optimize the contract so that all values are either const or in local storage.