EIP-6780 이후 SELFDESTRUCT는 코드와 저장소를 지우지 않고 잔액만 대상에 옮기며, 계약을 만든 같은 거래 안에서 호출될 때만 예전처럼 삭제합니다. 이 글은 2026-10-27에 연 EIP-6780 원문(상태 Final)으로 확인한 범위만 다룹니다.
확인 기준일 2026-10-27 · 다음 확인 예정 2026-11-26
호출 시점에 따라 무엇이 달라질까?
원문 Specification은 두 경우로 나눕니다. 계약을 만든 거래와 다른 거래에서 호출하면 저장소 키, 코드, 계정 자체를 삭제하지 않고 전체 잔액만 대상에 보냅니다. 같은 거래 안이면 이전 명세대로 데이터를 삭제합니다.
| 호출 상황 | 저장소·코드·계정 | 잔액 |
|---|---|---|
| 계약을 만든 거래와 다른 거래 | 삭제하지 않음 | 전부 대상으로 이전 |
| 계약을 만든 같은 거래 | 이전 명세대로 삭제 | 대상으로 이전 |
| 대상이 자기 자신, 다른 거래 | 삭제하지 않음 | 순변화 없음 |
| 대상이 자기 자신, 같은 거래 | 삭제 | 이더 소각 |
자기 자신을 대상으로 하면?
원문은 대상이 호출한 계약 자신일 때 다르게 적습니다. 다른 거래에서는 잔액 변화가 없고, 만든 거래 안에서는 이더가 소각됩니다.
왜 줄였고 무엇이 영향을 받을까?
원문 Rationale은 강한 사용 이유가 현재 없다고 설명합니다. Security considerations에는 CREATE2로 같은 자리에 재배포해 업그레이드하는 방식과 자기 자신을 수혜자로 해 이더를 소각하는 방식이 영향을 받는다고 나옵니다. 주소 결정은 CREATE와 CREATE2 계약 주소는 어떻게 결정될까 글에, 프록시 구조는 ERC-1967 프록시 슬롯에서 구현·관리자 주소를 찾는 법 글에 있습니다.
같은 거래 안이라는 조건은 무슨 뜻일까?
계약이 생성된 거래와 SELFDESTRUCT가 호출된 거래가 같은지가 기준입니다. 원문은 계정 생성과 계약 생성을 구분해서 다루는 이유로 반사실적 계정(counterfactual account)을 듭니다. 같은 거래 안에서 만들고 곧바로 없애는 임시 계약은 과거와 같이 흔적이 남지 않지만, 이미 배포된 계약에 대해서는 저장소와 코드가 그대로 남습니다. 따라서 오래된 계약 주소에 코드가 사라졌는지 확인하는 방식의 가정은 달라질 수 있습니다. 이 EIP는 합의 규칙을 바꾸므로 하드포크가 필요하다고 원문이 명시합니다.
이 글에서 확인하지 못한 것은?
활성화된 하드포크 이름과 시점은 열람한 원문에 적혀 있지 않아 쓰지 않았습니다. 이 변경이 실제 배포 계약에 미친 영향의 규모와 가스 비용 변화도 이번에 확인하지 못했습니다. 원문은 필수 선행 EIP로 2681, 2929, 3529를 나열합니다. 이 숫자들의 내용은 따로 확인하지 않았습니다. 정리하면 삭제는 계약을 만든 바로 그 거래 안에서만 일어나고, 그 밖에서는 이더만 이동합니다. 원문 작성일은 2023-03-25이고 상태는 Final입니다. 계약 설계에서 삭제를 전제했다면 이 기준으로 다시 읽어야 합니다.
자주 묻는 질문
SELFDESTRUCT 옵코드가 없어졌나요?
아닙니다. 원문은 동작을 바꿀 뿐이며 같은 거래의 경우 기존 동작을 유지한다고 적습니다.
어느 하드포크에 포함되었나요?
이번에 연 원문에는 활성화 포크 이름이 적혀 있지 않아 확인하지 못했습니다.
계약 주소를 다시 쓰는 CREATE2 재배포는 어떻게 되나요?
원문이 이 방식을 영향을 받는 사례로 꼽습니다. 세부 영향은 계약 설계에 따라 다릅니다.
