EIP-8163 EXTENSION(0xae) 옵코드 예약 (Reserve `EXTENSION (0xae)` opcode)
Hegota 포함 검토 (CFI) · EVM·실행 · 원문 상태 Review · 2026-02-13 작성
이더리움 L1에서는 영원히 유효한 명령어가 되지 않는 옵코드 EXTENSION(0xae)을 예약해 다른 EVM 체인들이 새 명령어를 안전하게 추가할 수 있는 확장 접두어로 쓰게 합니다.
왜 필요한가
이더리움이 아닌 EVM 체인들은 지금 EVM에 새 명령어(옵코드, opcode)를 마음대로 추가하기 어렵습니다. 나중에 이더리움 L1이나 다른 체인이 같은 번호의 옵코드를 다른 기능으로 쓰기로 하면, 같은 코드가 체인마다 다르게 동작하는 호환성 문제가 생기기 때문입니다. 이 제안은 옵코드 하나(0xae)를 골라 이더리움 L1에서는 절대 유효한 명령어로 만들지 않겠다고 약속합니다. 그러면 다른 EVM 체인들은 이 옵코드를 확장 명령어의 접두어로 안심하고 쓸 수 있습니다. 거기서 검증된 기능은 나중에 별도 제안으로 이더리움 L1에 다시 들여올 수 있고 혁신이 EVM 밖이 아니라 EVM 안에서 일어나 도구 생태계의 네트워크 효과도 강해집니다. 이더리움 L1 자체의 동작은 전혀 바뀌지 않고 실행 클라이언트 수정도 필요 없습니다.
무엇이 바뀌나
지금
- L1 밖 EVM 체인이 새 옵코드를 추가하면 나중에 L1과 충돌할 위험을 떠안습니다
- 어떤 옵코드가 영원히 비어 있을지 아무도 보장하지 않습니다
- EVM 혁신이 호환성 걱정 때문에 EVM 밖에서 이뤄지기 쉽습니다
EIP-8163 이후
- 0xae는 L1에서 영원히 INVALID처럼 동작한다고 보장됩니다
- 다른 EVM 체인은 0xae 뒤에 바이트를 붙이는 방식으로 자체 확장 명령어를 만들 수 있습니다
- L2 등에서 검증된 확장 기능을 별도 EIP로 L1에 역이식할 수 있습니다
- L1 클라이언트는 코드를 바꿀 필요가 없습니다
누구에게 영향이 있나
- 이더리움 L2·대안 L1: 0xae를 접두어로 삼아 자체 확장 명령어를 실험할 수 있고 사용 방식은 이 EIP의 토론 스레드에서 조율합니다.
- L1 클라이언트 팀: 실행 동작 변경이 없어 수정이 필요 없습니다. 트레이스 같은 표시 계층에서 예약된 옵코드 이름을 보여 주는 것은 선택 사항입니다.
- 일반 사용자: L1 동작이 바뀌지 않으므로 직접 체감하는 변화는 없습니다.
- 컴파일러·분석 도구 개발자: 여러 체인에서 같은 접두어 규약을 전제로 도구를 만들 수 있어 EVM 도구 생태계가 넓어집니다.
심층 설명
L1에서는 INVALID와 완전히 동일하게 동작
새 옵코드 EXTENSION(0xae)은 이더리움 메인넷과 테스트넷 등 모든 이더리움 L1 체인에서 EIP-141의 INVALID(0xfe)와 정확히 같게 동작해야 합니다(MUST). 구체적으로 세 가지입니다. 첫째, EXTENSION을 실행하면 예외적 중단(exceptional halt)이 일어나 현재 실행 프레임을 빠져나가고 남은 가스를 전부 소모합니다. 둘째, 바이트코드 안의 EXTENSION 바이트는 JUMPDEST 분석에 어떤 영향도 주어서는 안 되며 모든 점프 목적지의 유효성이 그대로 유지되어야 합니다. 셋째, 앞으로 바이트코드 검증·정적 분석·전처리가 도입되더라도 EXTENSION 바이트는 INVALID가 주는 영향 이상으로 그 과정에 영향을 주어서는 안 됩니다.
L1 밖에서의 사용 규약
이더리움 L1 밖에서는 EXTENSION이 실행 시 의미 있는 동작을 할 수 있으며 구체적 동작은 각 EVM 구현이 정합니다. 다만 EXTENSION을 실행하는 EVM에서도 JUMPDEST 분석은 영향받지 않아야 하고 유효한 점프 목적지 집합은 이더리움 L1에서 얻는 것과 동일해야 합니다. 확장 명령어의 동작은 EXTENSION 뒤에 오는 바이트들을 즉시 인자(immediate args)로 해석해 결정합니다. 0xae가 바이트코드의 마지막 바이트이면 실행은 예외적 중단으로 끝나야 하는데, 이는 PUSHn, EIP-8024 옵코드, CODECOPY, EXTCODECOPY의 제로 패딩 동작과 반대입니다. 각 체인의 구체적 사용법은 이 EIP의 토론 스레드에서 조율합니다.
JUMPDEST 분석을 건드리지 않는 설계
EXTENSION 뒤의 0x5b를 점프 목적지에서 제외하고 뒤따르는 PUSHx를 건너뛰는 대안도 검토됐지만 채택하지 않았습니다. 그렇게 하면 이 EIP가 즉시 인자의 크기를 규정해야 하고 다른 EIP가 도입하는 즉시 인자 옵코드와 충돌하며 같은 바이트코드가 L1 안팎에서 다른 점프 목적지 유효성을 갖게 되어 코드 이식성이 깨지기 때문입니다. 그래서 0xae5b 시퀀스는 유효한 확장 명령어가 될 수 없고 두 번째 바이트는 유효한 점프 목적지로 남는다고 전제합니다. 0xae60부터 0xae7f까지의 시퀀스도 유효한 확장 명령어가 아니지만 PUSH1(0x60)부터 PUSH32(0x7f) 바이트를 써서 JUMPDEST에 중립적인 즉시 인자를 넣는 경우는 예외입니다. PUSHx의 데이터는 이미 JUMPDEST 분석에서 건너뛰기 때문입니다. 예를 들어 0xae605b...는 0x5b 인자를 PUSH1 데이터에 담은 유효한 확장이고 이때 0x5b는 점프 목적지로 무효가 됩니다.
인코딩 방식은 정의하지 않고, L1 멀티바이트 옵코드는 명시적으로 금지
이 EIP는 범위를 최대한 좁히기 위해 확장 인코딩 방식을 전혀 정의하지 않습니다. 인코딩 체계가 필요하면 별도 제안에서 도입하고 논의합니다. 또한 이더리움 L1 EVM에서 EXTENSION을 이용한 멀티바이트 옵코드 지원은 명시적으로 금지합니다. 장래에 L1에서 멀티바이트 옵코드가 필요해지면 다른 접두어로 구현해야 합니다. EXTENSION으로 구현된 기능을 L1으로 역이식해야 할 때는 별도 EIP에서 별개의 옵코드를 고릅니다. 그 EIP가 원래 체인에도 채택되면 그 체인은 같은 기능에 접근하는 두 가지 방법을 함께 운영하게 됩니다.
하위 호환성과 클라이언트 영향
EXTENSION은 현재 이더리움에서 무효 옵코드이고 JUMPDEST 분석에도 영향을 주지 않으므로, 이 바이트를 포함한 기존 코드의 동작이 바뀌는 일은 없습니다. 이더리움 실행 계층 클라이언트의 동작이 변하지 않으므로 참조 구현은 없으며 보안 고려 사항도 원문에 없음으로 적혀 있습니다. 클라이언트는 트레이스 같은 표시 계층에서 예약된 옵코드의 이름을 보여 주도록 선택적으로 업데이트할 수 있습니다. 테스트 케이스는 Ethereum Execution Layer Specs 형식으로 제공될 예정입니다.
진행 상태와 콜 결정
이 EIP의 상태는 Review로, 내용이 아직 바뀔 수 있습니다. 코어 개발자 콜에서는 09.10 ACDE #245에서 결정을 2주 미루면서 챔피언(champion)이 L2와 대안 L1들의 실제 수요 신호를 모아 오지 못하면 DFI가 기본값이라고 정리했습니다. 이후 09.24 ACDE #246에서 EIP-8163을 헤고타(Hegota) 포함 검토(CFI)로 올렸습니다. L1에서는 아무 일도 안 하는 옵코드 하나를 다른 용도로 쓰지 않겠다고 보장하는 것이라는 설명이 함께 있었습니다.