EIP-2488 CALLCODE 명령어 폐지 (Deprecate the CALLCODE opcode)
Hegota 포함 제외 (DFI) · EVM·실행 · 원문 상태 Stagnant · 2019-12-20 작성
쓰이지 않는 초기 EVM 명령어 CALLCODE(0xf2)가 포크 블록 이후 항상 실패(0)를 반환하게 만들어 사실상 폐지하는 제안입니다.
왜 필요한가
CALLCODE는 이더리움의 첫 릴리스인 프런티어(Frontier)부터 있던 EVM 명령어입니다. 출시 후 몇 주에서 몇 달 사이에 원래 설계 목표를 이룰 수 없다는 사실이 분명해졌고 2016년 초 홈스테드(Homestead) 업그레이드에서 DELEGATECALL(EIP-7)이 도입되면서 문제가 바로잡혔습니다. 이후 CALLCODE는 전혀 활용되지 않게 됐지만 모든 EVM 구현체는 여전히 이 명령어를 지원해야 하는 부담을 집니다. 이 EIP는 CALLCODE가 항상 실패를 반환하게 해서 사실상 폐지하자고 제안합니다. 제네시스부터 전체 기록을 동기화하는 것이 목표인 클라이언트에게는 상황이 나아지지 않지만 라이트 클라이언트나 나중 시점부터 동기화할 계획인 클라이언트는 구현 부담을 덜 수 있습니다.
무엇이 바뀌나
지금
- CALLCODE(0xf2)가 EVM에 남아 있어 모든 클라이언트가 구현을 유지해야 합니다
- 명령어는 사실상 쓰이지 않지만 구현 부담은 그대로입니다
- 라이트 클라이언트도 쓰지 않는 명령어를 지원해야 합니다
EIP-2488 이후
- 포크 블록 이후 CALLCODE는 항상 0(실패)을 반환합니다
- 호출한 계약은 실패를 감지하고 대응할 기회가 생깁니다
- 라이트 클라이언트와 나중 시점부터 동기화하는 클라이언트는 구현 부담을 덜 수 있습니다
누구에게 영향이 있나
- 클라이언트 팀: 라이트 클라이언트나 나중 시점부터 동기화하는 클라이언트는 CALLCODE 구현 부담을 덜 수 있습니다. 제네시스부터 동기화하는 클라이언트에게는 개선이 없습니다.
- 컨트랙트 개발자: CALLCODE를 쓰는 계약은 포크 이후 호출이 항상 실패하므로 점검이 필요합니다. 저자는 가치 있는 계약은 영향받지 않을 것으로 예상합니다.
- 일반 사용자: CALLCODE는 사실상 쓰이지 않는 명령어라서 체감 변화는 거의 없습니다.
심층 설명
명세: 포크 이후 항상 0을 반환
명세는 한 줄입니다. block.number가 FORK_BLOCK 이상이면 CALLCODE(0xf2) 명령어는 항상 0을 반환하고 이 값은 호출 실패를 뜻합니다. 구체적인 FORK_BLOCK 값은 원문에 정해져 있지 않습니다. 명령어 자체를 없애는 것이 아니므로 CALLCODE를 만나도 실행이 예외로 중단되지 않고 호출한 계약은 반환값 0을 받아 실패를 인지한 뒤 다음 동작을 이어갈 수 있습니다.
제거 대신 실패 반환을 택한 이유
옵코드를 아예 제거하고 이 명령어를 만나면 실행을 예외로 중단시키는 방법도 가능했습니다. 그러나 실패를 반환하는 방식을 택하면 호출한 계약이 결과를 보고 대응하거나 복구를 시도할 기회가 생깁니다. 제목 격인 Abstract에서 이 방식을 어느 정도(somewhat) 하위 호환적인 폐지라고 부르는 이유입니다.
CALLCODE에서 DELEGATECALL로
CALLCODE는 프런티어 릴리스에 포함됐지만 첫 몇 주에서 몇 달 만에 의도한 설계 목표를 달성할 수 없다는 점이 분명해졌습니다. 이 문제는 2016년 초 홈스테드 업데이트에서 DELEGATECALL(EIP-7)을 도입하면서 바로잡혔습니다. 그 뒤로 CALLCODE는 전혀 활용되지 않았지만 EVM 구현에는 계속 부담을 주고 있습니다.
누가 이득을 보는가
제네시스부터 동기화하는 것이 목표인 클라이언트는 과거 블록을 처리해야 하므로 이 변경으로 상황이 나아지지 않습니다. 반면 라이트 클라이언트나 나중 시점부터 동기화할 계획인 클라이언트에게는 도움이 됩니다. 폐지의 실익이 전체 노드보다는 가벼운 구현을 지향하는 쪽에 있다는 뜻입니다.
하위 호환성과 미완성 항목
이 제안은 기존 동작을 바꾸는 변경(breaking change)이라서 계약을 깨뜨릴 가능성이 있습니다. 저자는 가치 있는 계약은 어느 것도 영향받지 않을 것으로 예상하지만 원문에는 이 주장을 검증해야 한다는 TODO가 그대로 남아 있습니다. Security Considerations, Test Cases, Implementation 절도 모두 TBA(추후 작성)로 비어 있어 명세로서 완성도가 낮은 상태입니다.
문서 상태와 포크 논의 결과
이 EIP의 상태는 Stagnant로, 오랫동안 진전 없이 멈춰 있습니다. 포크 포함 논의에서도 채택되지 않았습니다. 09.10 ACDE #245 콜에서 Hegota 대상 검토 중 EIP-2488을 제외했고 EIP-8219, EIP-8182, EIP-7645와 함께 전 클라이언트 만장일치 저평가(0.0~0.8)를 받았습니다.