칸쿤(Cancun) 규칙의 EIP-6780이 켜진 이더리움에서는 기존 계약이 SELFDESTRUCT를 실행해도 지정한 수취인(beneficiary)에게 ETH 잔액 전부를 넘길 뿐, 계약 코드와 저장소, 계정을 지우지 않습니다. 예외는 계약이 만들어진 바로 그 거래 안에서 SELFDESTRUCT를 실행한 경우로, 이때만 예전처럼 삭제가 일어납니다. 이 조건을 정하는 것은 솔리디티 컴파일러의 evm-version 설정이 아니라 실행 블록에 적용되는 체인 포크 규칙입니다. 그러니 SELFDESTRUCT를 영구 비활성화나 저장소 삭제, 다음 거래에서의 CREATE2 재배포 수단으로 믿어서는 안 됩니다.
실행 블록의 포크부터 확인합니다
SELFDESTRUCT의 의미는 소스를 언제 컴파일했는지만으로 정해지지 않습니다. 같은 바이트코드라도 칸쿤 규칙이 켜진 체인과 이전 규칙을 쓰는 체인에서 결과가 달라질 수 있습니다. 솔리디티 문서는 칸쿤 이후 EVM에서 이 명령이 잔액을 받는 쪽에 보내기만 하고 계약을 파괴하지 않는다고 밝히며, 컴파일러의 –evm-version으로는 네트워크 전체의 실행 규칙을 바꿀 수 없다고 경고합니다.
솔리디티 0.8.18부터 이 옵코드를 쓰면 지원 중단(deprecated) 경고가 뜹니다. 지원 중단이란 옵코드가 당장 사라졌다는 뜻이 아니라, 앞으로 의미가 더 좁아질 수 있으니 새 설계에서 기대지 말라는 신호입니다. EVM 호환 체인이 이더리움과 같은 포크를 적용했는지는 그 체인의 규격으로 따로 확인합니다.
SELFDESTRUCT라는 이름은 지금의 결과를 제대로 담지 못합니다. 기존 계약에서는 파괴보다 잔액 이전이 핵심 효과입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 실행 블록의 포크부터 확인합니다
SELFDESTRUCT의 의미는 소스를 언제 컴파일했는지만으로 정해지지 않습니다.
- 기존 계약과 같은 거래 안 생성 예외를 나눕니다
계약 C가 이전 블록부터 있었다면 SELFDESTRUCT(B)는 C의 현재 ETH 잔액을 B로 옮기지만, C의 코드와 저장소는 그대로 남습니다.
- 받기를 거부하는 계약에도 잔액이 늘 수 있습니다
계약이 receive·fallback에서 revert하더라도 다른 계약의 SELFDESTRUCT 수취인으로 지정되면, 메시지 호출 없이 ETH 잔액이 늘어날 수 있습니다.
설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
기존 계약과 같은 거래 안 생성 예외를 나눕니다
계약 C가 이전 블록부터 있었다면 SELFDESTRUCT(B)는 C의 현재 ETH 잔액을 B로 옮기지만, C의 코드와 저장소는 그대로 남습니다. 다음 거래에서 C의 함수를 다시 부를 수도 있습니다. 수취인이 C 자신이라면 잔액이 소각되는 특수한 결과가 될 수 있으니 정확한 EIP 규칙을 확인합니다.
팩토리가 한 거래 안에서 새 C를 CREATE나 CREATE2로 만들고, C가 같은 거래 안에서 SELFDESTRUCT를 실행하면 예전 의미대로 코드·저장소 삭제와 잔액 이전이 함께 적용됩니다. 조건은 ‘같은 블록’이 아니라 같은 거래입니다. 먼저 생성된 뒤 다른 거래에서 파괴하면 예외에 해당하지 않습니다.
| 조건 | ETH 잔액 | 코드·저장소 | 재호출 |
|---|---|---|---|
| 칸쿤 이전 규칙 | 수취인에게 이전 | 삭제 예정 | 이후 코드 없음 |
| 칸쿤 이후 기존 계약 | 수취인에게 이전 | 유지 | 가능 |
| 같은 거래에서 생성·파괴 | 수취인에게 이전 | 예전 방식대로 삭제 | 이후 코드 없음 |
| 호출 프레임 되돌림 | 효과 취소 | 변경 없음 | 기존 상태 |
| DELEGATECALL 경유 | 호출자 문맥의 잔액 | 호출자 조건에 따름 | 문맥 추적 필요 |
받기를 거부하는 계약에도 잔액이 늘 수 있습니다
계약이 receive·fallback에서 revert하더라도 다른 계약의 SELFDESTRUCT 수취인으로 지정되면, 메시지 호출 없이 ETH 잔액이 늘어날 수 있습니다. 그래서 address(this).balance가 내부 장부 합계와 언제나 같다는 불변 조건은 이런 강제 송금 때문에 깨질 수 있습니다. 초과로 들어온 ETH를 어떻게 다룰지 로직에서 정해 둬야 합니다.
옵코드가 위임 호출(delegatecall)로 실행되면 현재 실행 문맥의 계약에 효과가 적용됩니다. 라이브러리 바이트코드에 SELFDESTRUCT가 없다고 안심하기보다, 위임 호출이 가능한 대상과 업그레이드 권한을 제한합니다. 정적 호출(staticcall) 문맥에서는 SELFDESTRUCT가 상태를 바꾸는 옵코드이므로 시도하는 순간 예외가 납니다.
- 체인 ID와 SELFDESTRUCT 관련 포크가 켜진 높이를 확인합니다.
- 대상 계약이 지금 거래에서 생성됐는지 판정합니다.
- 옵코드가 일반 호출(CALL) 문맥인지 DELEGATECALL 문맥인지 추적합니다.
- 수취인과 실행 전후 잔액을 비교합니다.
- 코드 해시·저장소와 이후 호출 결과를 따로 검증합니다.
코드 삭제에 기댄 업그레이드 패턴은 버립니다
예전의 변신형(metamorphic) 패턴은 CREATE2 주소의 코드를 SELFDESTRUCT로 지운 뒤 다른 초기화 코드를 배포하는 방식이었습니다. 기존 계약 코드가 남는 EIP-6780 환경에서는 주소 충돌 조건 때문에 같은 주소에 다시 배포하는 일이 실패합니다. 프록시의 구현 주소 슬롯을 바꾸는 업그레이드와 주소 재사용은 완전히 다른 방법입니다.
비활성화가 목적이라면 일시 정지 상태, 접근 제어, 명시적인 출금 기능을 설계합니다. 다만 관리자의 일시 정지도 권한 탈취나 영구 잠금 위험이 있으니 타임록·멀티시그·복구 절차를 함께 검토합니다. SELFDESTRUCT 한 줄을 비상 정지 장치라고 부르지 않습니다.
탐색기 표시는 세 가지 상태를 구분해야 합니다
거래 실행 추적에 SELFDESTRUCT 옵코드가 있다는 사실, 잔액이 옮겨진 사실, 코드가 실제로 사라진 사실을 하나씩 따로 기록합니다. 오래된 디코더는 옵코드 이름만 보고 destroyed=true로 표시할 수 있으므로 블록 번호와 체인 포크로 다시 확인합니다.
아카이브 기록에는 과거 코드와 저장소 변화가 남아 있을 수 있습니다. 예외 조건으로 상태에서 지워진 계약이라도 개인정보가 디스크에서 사라졌다는 뜻은 아닙니다. 현재 eth_getCode 결과 0x, 과거 상태, 탐색기 메타데이터는 서로 다른 증거로 다룹니다.
자주 묻는 질문
칸쿤 이후 SELFDESTRUCT를 호출한 계약은 다시 실행되나요?
기존 계약이라면 코드와 저장소가 남아 있어 다시 호출할 수 있습니다. 같은 거래 안에서 생성된 계약에 대한 예외는 다르게 동작합니다.
컴파일러 evmVersion을 상하이(Shanghai)로 두면 코드가 삭제되나요?
실행 결과는 체인에서 그 블록에 적용되는 포크 규칙이 정합니다. 컴파일러 설정만으로 네트워크의 동작을 되돌릴 수는 없습니다.
SELFDESTRUCT 가스 환급도 아직 남아 있나요?
EIP-3529가 런던(London) 업그레이드에서 SELFDESTRUCT 가스 환급을 없앴습니다. EIP-6780의 코드 삭제 변경과는 별개의 변화입니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
