Cancun 규칙의 EIP-6780이 활성화된 Ethereum에서는 기존 계약이 SELFDESTRUCT를 실행해도 지정 beneficiary로 전체 ETH balance를 이전할 뿐 계약 code, storage와 account를 삭제하지 않습니다. 예외는 그 계약이 생성된 바로 같은 transaction 안에서 SELFDESTRUCT를 실행한 경우이며 이때는 이전과 같은 삭제 동작을 유지합니다. 이 조건은 Solidity compiler의 evm-version 설정이 아니라 실행 block의 chain fork rules가 결정합니다. 따라서 SELFDESTRUCT를 영구 비활성화, storage 삭제 또는 다음 transaction의 CREATE2 재배포 수단으로 의존해서는 안 됩니다.
먼저 실행 block의 fork를 확인합니다
SELFDESTRUCT 의미는 source가 compile된 시점만으로 결정되지 않습니다. 동일 bytecode라도 Cancun 규칙이 활성화된 chain과 이전 규칙의 chain에서 결과가 다를 수 있습니다. Solidity 문서는 EVM Cancun 이후 balance를 recipient에게 보내되 계약을 파괴하지 않는다고 명시하며 compiler –evm-version은 network-wide 실행 규칙을 바꾸지 못한다고 경고합니다.
Solidity 0.8.18부터 이 opcode 사용은 deprecated warning 대상입니다. Deprecated는 opcode가 즉시 사라졌다는 뜻이 아니라 앞으로 semantics가 더 제한될 가능성과 새 설계가 의존하지 말아야 한다는 신호입니다. EVM 호환 chain이 Ethereum과 같은 fork를 적용했는지는 해당 chain 규격으로 별도 확인합니다.
SELFDESTRUCT라는 이름은 현재 결과를 요약하지 못합니다. 기존 계약에서는 파괴보다 잔액 이전이 핵심 효과입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 먼저 실행 block의 fork를 확인합니다
SELFDESTRUCT 의미는 source가 compile된 시점만으로 결정되지 않습니다.
- 기존 계약과 같은 거래 생성 예외를 나눕니다
계약 C가 이전 block부터 존재했다면 SELFDESTRUCT(B)는 C의 현재 ETH balance를 B로 옮기지만 C의 code와 storage는 그대로 남습니다.
- 잔액은 receive·fallback에서 revert하더라도
Contract가 receive·fallback에서 revert하더라도 다른 계약의 SELFDESTRUCT beneficiary로 지정되면 message call 없이 ETH balance가 늘 수 있습니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
기존 계약과 같은 거래 생성 예외를 나눕니다
계약 C가 이전 block부터 존재했다면 SELFDESTRUCT(B)는 C의 현재 ETH balance를 B로 옮기지만 C의 code와 storage는 그대로 남습니다. 다음 transaction에서 C 함수를 다시 호출할 수 있습니다. Beneficiary가 C 자신이어도 balance는 소각되는 특수 결과가 될 수 있어 정확한 EIP 규칙을 확인합니다.
Factory가 transaction 안에서 새 C를 CREATE 또는 CREATE2로 만들고 C가 같은 transaction 안에서 SELFDESTRUCT하면 이전 semantics처럼 code·storage 삭제와 balance 이전이 적용됩니다. ‘같은 block’이 아니라 같은 transaction이 조건입니다. 먼저 생성된 뒤 다른 transaction에서 파괴하면 예외가 아닙니다.
| 조건 | ETH balance | Code·storage | 재호출 |
|---|---|---|---|
| Cancun 전 규칙 | beneficiary 이전 | 삭제 예정 | 이후 code 없음 |
| Cancun 후 기존 계약 | beneficiary 이전 | 유지 | 가능 |
| 같은 tx에서 생성·파괴 | beneficiary 이전 | 예전 방식 삭제 | 이후 code 없음 |
| 호출 frame revert | 효과 취소 | 변경 없음 | 기존 상태 |
| Delegatecall 경유 | 호출자 문맥 balance | 호출자 조건에 따름 | 문맥 추적 필요 |
잔액은 receive·fallback에서 revert하더라도
Contract가 receive·fallback에서 revert하더라도 다른 계약의 SELFDESTRUCT beneficiary로 지정되면 message call 없이 ETH balance가 늘 수 있습니다. 따라서 address(this).balance가 내부 회계 합계와 항상 같다는 invariant는 강제 전송 때문에 깨질 수 있습니다. 로직은 초과 ETH를 어떻게 처리할지 정해야 합니다.
Opcode가 delegatecall로 실행되면 현재 실행 문맥 계약에 효과가 적용됩니다. Library bytecode에 SELFDESTRUCT가 없다고 안심하기보다 delegatecall 가능한 target과 upgrade authority를 제한합니다. Staticcall 문맥에서는 SELFDESTRUCT 시도가 state-changing opcode라 예외가 납니다.
- Chain id와 SELFDESTRUCT 관련 fork 활성 높이를 확인합니다.
- 대상 계약이 현재 transaction에서 생성됐는지 판정합니다.
- Opcode가 CALL인지 DELEGATECALL 문맥인지 추적합니다.
- Beneficiary와 실행 전후 balance를 비교합니다.
- Code hash·storage와 후속 호출 결과를 별도로 검증합니다.
Code 삭제 기반 upgrade 패턴을 폐기합니다
과거 metamorphic pattern은 CREATE2 주소의 code를 SELFDESTRUCT로 지운 뒤 다른 init code를 배포하는 설계를 사용했습니다. 기존 계약 code가 남는 EIP-6780 환경에서는 collision 조건 때문에 같은 주소 재배포가 실패합니다. Proxy implementation slot을 변경하는 upgrade와 주소 재사용은 완전히 다른 방법입니다.
비활성화가 목적이면 paused state, access control과 명시적 withdrawal 같은 기능을 설계합니다. 다만 관리자 pause도 권한 탈취와 영구 잠금 위험이 있어 timelock·multisig·복구 절차를 검토합니다. SELFDESTRUCT 한 줄을 emergency stop으로 부르지 않습니다.
탐색기 표시는 세 상태를 구분해야 합니다
Transaction trace에 SELFDESTRUCT opcode가 있다는 사실, balance가 이동한 사실, code가 실제 사라진 사실을 각각 기록합니다. 오래된 decoder가 opcode 이름만 보고 destroyed=true를 표시할 수 있으므로 block number와 chain fork로 재검증합니다.
Archive history에는 과거 code와 storage 변화가 남을 수 있어 예외 조건으로 state에서 삭제된 계약도 개인정보가 디스크에서 지워진 것은 아닙니다. 현재 eth_getCode 결과 0x, historical state, explorer metadata를 서로 다른 증거로 다룹니다.
자주 묻는 질문
Cancun 이후 SELFDESTRUCT를 호출한 계약은 다시 실행되나요?
기존 계약이면 code와 storage가 유지되어 다시 호출할 수 있습니다. 같은 transaction에서 생성된 계약 예외는 다릅니다.
Compiler evmVersion을 Shanghai로 두면 code가 삭제되나요?
실행 결과는 chain의 block fork rules가 정합니다. Compiler 설정만으로 network semantics를 되돌릴 수 없습니다.
SELFDESTRUCT refund도 남아 있나요?
EIP-3529가 London에서 SELFDESTRUCT gas refund를 제거했습니다. EIP-6780의 code 삭제 변경과 별도 변화입니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
