EIP-8200 프리컴파일의 EVM화 (EVMification)
Hegota 포함 제외 (DFI) · EVM·실행 · 원문 상태 Draft · 2026-03-21 작성
RIPEMD-160(0x03), MODEXP(0x05), BLAKE2f(0x09) 세 프리컴파일을 같은 기능을 하는 일반 EVM 바이트코드로 대체합니다. 주소와 기능은 그대로 두고 내부 구현만 바꿉니다.
왜 필요한가
이더리움에는 특정 연산을 빠르게 처리하도록 클라이언트 소프트웨어 안에 따로 구현해 둔 프리컴파일(precompile)이라는 특수 계약이 있습니다. 모든 클라이언트 팀이 이것을 각자 구현하고 유지해야 하므로 관리 비용이 계속 들고 구현이 서로 어긋나면 합의 버그로 이어질 위험이 있습니다. 영지식 증명으로 EVM 실행을 검증하는 zkEVM에는 부담이 더 큽니다. 프리컴파일마다 별도의 최적화된 비EVM 구현이 필요하기 때문입니다. 그런데 이 세 프리컴파일은 실제로 거의 쓰이지 않습니다. RIPEMD-160은 체인 위 사용이 극히 적습니다. MODEXP 사용의 99.99%는 SNARK 검증용 256비트 모듈러스이며 BLAKE2f는 사실상 단일 계약만 씁니다. 이 EIP는 사용이 적거나 적은 비용으로 바꿀 수 있는 세 프리컴파일을 일반 EVM 코드로 교체해서 모든 클라이언트가 유지해야 할 특수 구현 수를 줄이고 프로토콜을 단순하게 만듭니다.
무엇이 바뀌나
지금
- RIPEMD-160(0x03), MODEXP(0x05), BLAKE2f(0x09)가 클라이언트마다 따로 구현한 프리컴파일로 동작합니다
- 가스비는 각 프리컴파일 전용 공식으로 계산됩니다
- zkEVM은 프리컴파일마다 별도의 최적화 구현을 만들어야 합니다
EIP-8200 이후
- 포크가 활성화되는 블록 시작 시점에 세 주소에 동등한 기능의 EVM 바이트코드가 배포됩니다
- 그 블록부터 세 주소는 프리컴파일로 취급되지 않습니다
- 가스비는 실제로 실행된 EVM 명령어 비용의 합으로 계산됩니다
- 기존 계약은 같은 주소를 같은 방식으로 호출해 그대로 동작합니다
누구에게 영향이 있나
- 클라이언트 팀: 유지보수할 프리컴파일 특수 구현이 세 개 줄고 구현 차이에서 오는 합의 버그 위험이 낮아집니다. 새 클라이언트의 진입 장벽도 낮아집니다.
- zkEVM·L2: 별도 회로로 구현해야 할 프리컴파일이 줄어듭니다. 콜 기록에 따르면 ZKVM 회로와 감사 범위가 줄어드는 효과가 있습니다.
- 컨트랙트 개발자: 세 주소를 호출하는 기존 계약은 계속 동작하지만 가스비가 달라집니다. 고정된 가스량을 넘겨 호출하는 계약은 새 비용이 더 비싸면 되돌려질 수 있습니다.
심층 설명
대체 대상 선정 근거: 세 프리컴파일의 실사용
대상은 RIPEMD160_ADDRESS(0x03), MODEXP_ADDRESS(0x05), BLAKE2F_ADDRESS(0x09)입니다. RIPEMD-160은 온체인 사용이 극히 적고 주된 역사적 용도였던 비트코인식 주소 유도는 이더리움 계약에서 흔하지 않습니다. MODEXP는 제안자의 분석에서 사용량의 99.99%가 SNARK 검증을 위한 256비트 모듈러스였고 드물게 쓰이는 RSA 모듈러스가 나머지를 차지했습니다. BLAKE2f는 현재 사실상 단일 계약이 지배적으로 사용합니다. 사용이 적거나 적은 비용으로 EVM화할 수 있다는 점이 선정 기준입니다.
배포 방식: 포크 블록 시작 시 코드 설치
이 변경이 활성화되는 블록의 실행 시작 시점에, 위 세 주소 각각에 대해 (1) 해당 주소의 코드를 대체 대상 프리컴파일과 기능적으로 동등한 EVM 바이트코드로 설정하고, (2) 그 블록부터(그 블록 포함) 해당 주소를 더 이상 프리컴파일로 취급하지 않아야 합니다(MUST). 이는 아이덴티티 프리컴파일(0x04)을 EVM화하는 EIP-7666과 같은 방식입니다. 다만 각 주소에 배포할 정확한 바이트코드는 아직 명세되지 않았습니다.
가스 비용: 전용 공식에서 명령어 비용 합으로
활성화 후 세 주소 호출은 프리컴파일 전용 가스 공식 대신 표준 EVM 실행 비용으로 과금됩니다. 현재 RIPEMD-160 프리컴파일은 600 + 120 * ceil(len(data) / 32) 가스를, BLAKE2f는 입력에 지정된 라운드 수(rounds)만큼 가스를 받습니다. MODEXP는 밑·지수·모듈러스 길이와 지수에서 유도한 반복 횟수에 따른 복잡한 공식을 씁니다. EVM 구현은 실행된 명령어 비용의 합을 과금하므로 비용이 달라질 것으로 보입니다. 특히 MODEXP는 EVM에서 모듈러 지수 연산이 복잡해 큰 입력에서 비용이 더 높아질 것으로 예상됩니다. 각 프리컴파일의 구체적 가스 비교표는 원문에 TODO로 남아 있습니다.
설계 선택: 같은 주소에 배포, 가스 공식 복제는 포기
원래 프리컴파일의 가스 공식을 그대로 재현하려 하지 않고 EVM 실행의 자연스러운 가스 비용을 받아들입니다. 가스 리프라이싱은 이더리움 생태계에서 여러 번 수행되어 그 영향이 잘 이해되어 있다는 것이 근거입니다. 그래도 프리컴파일별 영향 분석은 수행할 예정입니다. 또한 프리컴파일을 제거하고 호출자가 다른 주소의 라이브러리 계약을 쓰게 하는 대안은 이미 배포된 계약의 하위 호환성을 깨므로 기각했습니다. 기존 주소에 바이트코드를 직접 배포하면 그 주소를 호출하는 모든 기존 계약이 같은 인터페이스로 수정 없이 계속 동작합니다.
하위 호환성과 보안 고려
각 주소의 기능 자체는 보존되지만 가스 비용이 달라지므로, 호출 시 정밀한 가스 계산에 의존하는 계약이 영향을 받을 수 있습니다. 특히 고정된 가스량을 넘겨 호출하는 계약은 EVM 구현의 비용이 기존 프리컴파일보다 높으면 되돌려질 수 있습니다. 원문은 프리컴파일 가스 비용이 과거에도 바뀐 적이 있고 하드코딩된 가스 비용에 의존하는 것은 나쁜 관행으로 받아들여져 왔다고 밝힙니다. 구현 정확성 측면에서는, 배포되는 바이트코드가 모든 유효 입력에 대해 원래 프리컴파일과 동일한 출력을 내고 무효 입력도 같은 방식으로 처리하는지 철저히 테스트하고 감사해야 합니다.
진행 상태: Draft, 헤고타 포크에서는 제외
이 EIP는 Draft 상태로, 배포할 바이트코드와 테스트 케이스가 아직 명세되지 않는 등 내용이 바뀔 수 있습니다. 코어 개발자 콜에서는 07.30 ACDE #242에서 헤고타(Hegota) 포크 후보(PFI)로 접수하면서 ZKVM 회로와 감사 범위가 줄어든다는 점을 들었으나, 09.10 ACDE #245에서 헤고타 포함을 철회(DFI)했습니다. 방향은 좋다는 데 모두 동의했지만 대체 바이트코드의 성능 벤치마크가 무르익지 않아 시기상조라는 판단이었습니다.