CREATE2는 컨트랙트 주소를 keccak256(0xff ++ address ++ salt ++ keccak256(init_code))[12:]로 정합니다. 배포자의 nonce가 아니라 배포자 주소, salt, 초기화 코드의 해시로 정해지므로 배포 전에 주소를 계산할 수 있습니다. 이 글은 2026-10-27에 연 EIP-1014 원문(상태 Final)으로 확인한 범위만 다룹니다.
확인 기준일 2026-10-27 · 다음 확인 예정 2026-11-26
CREATE와 무엇이 달라질까?
CREATE2는 0xf5 opcode이고 스택 인자 네 개(endowment, memory_start, memory_length, salt)를 받습니다. 나머지는 CREATE와 같고 주소를 정하는 공식만 다릅니다. salt는 스택 항목이라 항상 32바이트입니다. 원문이 밝힌 동기는 아직 체인에 없는 주소와 상호작용하되, 나중에 그 주소에 올 수 있는 코드가 특정 초기화 코드에서 나온 것뿐임을 믿을 수 있게 하는 것입니다. 상태 채널의 가상 상호작용이 주된 예입니다. 공식은 2018-08-10 코어 개발자 회의에서 정해졌다고 적혀 있습니다.
| 구성 요소 | 크기 | 설명 |
|---|---|---|
| 0xff | 1바이트 | 고정 접두 |
| address | 20바이트 | CREATE2를 실행하는 주소 |
| salt | 32바이트 | 스택 인자 하나 |
| keccak256(init_code) | 32바이트 | 초기화 코드의 해시 |
| 합계 | 85바이트 | 최종 해시의 입력 길이 |
왜 0xff로 시작할까?
기존 방식의 keccak256(rlp([sender, nonce])) 주소와 겹치지 않게 하기 위해서입니다. 원문은 0xff가 RLP 데이터의 첫 바이트가 되려면 수 페타바이트 길이여야 한다고 설명합니다. 고정 길이 입력이라는 점도 이 설계의 이유로 꼽습니다. 주소 표기는 EIP-55 체크섬 글에서 볼 수 있습니다.
가스는 어떻게 더해질까?
CREATE와 같은 가스에 GSHA3WORD×ceil(len(init_code)/32)의 해시 비용이 더해집니다. 큰 초기화 코드를 반복 해시하게 만드는 서비스 거부를 막기 위해서이며, 이 비용은 메모리 확장 가스와 같은 시점에 주소 계산과 초기화 코드 실행보다 먼저 차감됩니다. 원문 예시에서 메모리 확장이 없을 때 초기화 코드가 1바이트이면 32006, 비어 있으면 32000입니다.
이미 쓰인 주소에는 어떻게 될까?
EIP-684에 따라 목적 주소의 nonce가 0이 아니거나 코드가 있으면 생성은 즉시 실패합니다. 원문은 EIP-161에 따라 생성 직전 nonce가 1 늘어나므로 같은 거래 안의 충돌도 실패한다고 설명합니다. SELFDESTRUCT의 이후 변화는 이번에 확인하지 않았습니다. 프록시가 가리키는 주소를 구분하는 법은 프록시 계약 주소 글에 이어집니다.
자주 묻는 질문
salt를 바꾸면 주소가 달라지나요?
공식에 salt가 들어가므로 salt가 다르면 해시 입력이 달라져 주소도 달라집니다.
배포자의 nonce가 주소에 영향을 주나요?
CREATE2 공식에는 nonce가 없습니다. 영향을 주는 값은 주소, salt, 초기화 코드의 해시뿐입니다.
같은 주소에 다시 배포할 수 있나요?
그 주소에 nonce나 코드가 이미 있으면 생성이 실패합니다. 삭제 이후의 재배포 규칙은 이 글에서 확인하지 못했습니다.
