CREATE와 CREATE2 계약 주소는 어떻게 결정될까

CREATE 주소는 생성자 계정 주소와 그 계정의 creation nonce를 RLP로 인코딩한 뒤 Keccak-256한 값의 마지막 20바이트로 정합니다. CREATE2는 0xff, deployer 주소, 32바이트 salt, keccak256(init_code)를 이어 해시한 마지막 20바이트를 사용합니다. CREATE2는 같은 deployer·salt라도 constructor 인수나 creation bytecode가 달라 init code hash가 바뀌면 주소도 달라집니다. 예상 주소에 기존 nonce나 code가 있으면 생성이 실패하므로 결정적 주소라는 말은 재배포가 언제나 성공하거나 그 주소의 runtime code가 영원히 같다는 보장이 아닙니다.

CREATE 주소는 생성 순서에 묶입니다

EOA가 recipient 없는 creation transaction을 보내거나 contract가 CREATE opcode를 실행하면 새 account 주소는 creator와 nonce에서 파생됩니다. Contract account의 creation nonce는 그 contract가 만든 배포 순서를 반영합니다. 같은 bytecode라도 앞선 생성이 하나 추가되면 nonce가 바뀌어 이후 주소가 모두 달라집니다.

Creation payload는 init code입니다. EVM은 init code를 실행하고 RETURN된 bytes를 새 account의 runtime code로 저장합니다. Constructor arguments도 creation bytecode 뒤 ABI bytes로 붙으므로 CREATE 주소는 init code 내용이 아니라 creator nonce에만 의존하지만 배포 결과와 실패 여부는 init execution에 달려 있습니다.

결정적 주소는 코드를 아직 실행하지 않고 위치를 계산할 수 있다는 뜻이지, 그 위치의 계약 동작까지 자동으로 신뢰할 수 있다는 뜻은 아닙니다.

JOBCOIN 해설

VISUAL GUIDE프로토콜 실행의 기본 구조

1. 01
   CREATE 주소는 생성 순서에 묶입니다

   EOA가 recipient 없는 creation transaction을 보내거나 contract가 CREATE opcode를 실행하면 새 account 주소는 creator와 nonce에서 파생됩니다.

2. 02
   CREATE2는 init code를 주소 약속에 넣습니다

   EIP-1014의 CREATE2 preimage는 정확히 0xff || deployer || salt || keccak256(init_code)입니다.

3. 03
   Factory 배포 사례를 네 값으로 재현합니다

   Factory F가 salt S와 creation bytecode C, constructor args A로 wallet을 배포한다고 하겠습니다.

AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.

CREATE2는 init code를 주소 약속에 넣습니다

EIP-1014의 CREATE2 preimage는 정확히 0xff || deployer || salt || keccak256(init_code)입니다. 고정 길이 prefix가 기존 CREATE RLP 주소 형식과 충돌하지 않게 하고 마지막 20바이트를 주소로 사용합니다. Salt는 opcode stack의 256비트 값이라 UI 문자열을 그대로 넣지 말고 실제 bytes32 encoding을 확인합니다.

Init code hash는 배포 후 runtime bytecode hash가 아닙니다. 같은 runtime code를 반환하더라도 constructor logic이나 metadata, 인수가 다른 init code면 주소가 달라질 수 있습니다. 반대로 같은 preimage라면 같은 주소를 계산하지만 이미 account nonce나 code가 있으면 EIP-684 조건으로 creation이 throw됩니다.

Factory 배포 사례를 네 값으로 재현합니다

Factory F가 salt S와 creation bytecode C, constructor args A로 wallet을 배포한다고 하겠습니다. 먼저 init=C||ABI(A)를 정확히 만들고 H=keccak256(init)을 계산합니다. 다음으로 keccak256(0xff||F||S||H)의 마지막 20바이트를 취합니다. Library link address나 compiler metadata가 C에 들어가면 같은 source라도 H가 달라질 수 있습니다.

프런트엔드가 예상 주소에 미리 token을 보내기 전 chain id와 factory address, factory runtime code hash, salt encoding, init code hash를 서명 화면에 보여 줍니다. 다른 chain에 같은 F가 존재하지 않거나 factory code가 다르면 계산 결과의 의미가 달라집니다. 주소 문자열 하나만 비교하지 않습니다.

• 배포 chain과 factory 주소·code hash를 고정합니다.
• Creation bytecode와 constructor ABI bytes를 결합합니다.
• Salt를 정확한 bytes32로 정규화합니다.
• EIP-1014 preimage와 예상 주소를 독립 계산합니다.
• 배포 뒤 runtime code hash와 initialization 상태를 확인합니다.

Counterfactual 주소에도 충돌과 점유 위험이 있습니다

State channel이나 account wallet은 아직 배포되지 않은 CREATE2 주소를 참여자 식별에 쓸 수 있습니다. 하지만 주소에 ETH나 token을 먼저 보냈다면 올바른 factory만 원하는 init code를 배포할 수 있는지 검증해야 합니다. 누구나 호출 가능한 factory가 salt ownership을 검사하지 않으면 제3자가 먼저 다른 인수로 transaction을 제출할 수 있습니다.

같은 deployer·salt에서 init code가 다르면 주소도 다르므로 단순 salt 선점과 동일 주소 선점은 구분합니다. 동일 preimage의 주소가 이미 생성되어 nonce 또는 code가 남으면 같은 transaction 안의 반복 생성도 실패합니다. CREATE2를 주소 덮어쓰기 기능으로 설명하면 안 됩니다.

SELFDESTRUCT 뒤 재배포 가정은 fork에 따라 깨집니다

과거 metamorphic contract 패턴은 code 삭제 뒤 같은 CREATE2 주소에 새 code를 배포하는 흐름을 이용했습니다. Cancun의 EIP-6780 이후 기존 contract에서 SELFDESTRUCT를 호출해도 일반적으로 code와 storage가 삭제되지 않으므로 다음 transaction 재배포 전제가 성립하지 않습니다.

생성한 바로 그 transaction 안에서 SELFDESTRUCT한 예외는 별도이지만 장기 upgrade 도구로 의존하면 안 됩니다. 배포 시스템은 target chain fork, account nonce·code와 receipt status를 확인하고 proxy upgrade와 CREATE2 redeploy를 서로 다른 모델로 다룹니다.

자주 묻는 질문