롱테일 프리컴파일 EVM화, 안 쓰는 특수 계약 정리
Strawmap J* (2028~29) · EVMify long-tail precompiles
거의 쓰이지 않는 프리컴파일(precompile) 세 개인 RIPEMD-160, MODEXP, BLAKE2f를 같은 일을 하는 일반 EVM 코드로 바꿉니다. 주소와 기능은 그대로 두고 클라이언트가 따로 유지하던 특수 구현만 없앱니다.
왜 필요한가
이더리움에는 특정 계산을 빠르게 처리하려고 클라이언트 소프트웨어 안에 따로 구현해 둔 특수 계약, 프리컴파일(precompile)이 있습니다. 모든 클라이언트 팀이 이것을 각자 만들고 유지해야 하므로 관리 비용이 계속 듭니다. 구현이 서로 어긋나면 합의 버그로 이어질 수 있습니다. EVM 실행을 영지식 증명으로 검증하는 zkEVM에는 프리컴파일마다 EVM과 별도의 최적화 구현이 필요해 부담이 더 큽니다. 그런데 RIPEMD-160, MODEXP, BLAKE2f 세 프리컴파일은 실제로 거의 쓰이지 않습니다. RIPEMD-160은 체인 위 사용이 극히 적습니다. MODEXP 사용의 99.99%는 영지식 증명(SNARK) 검증 한 가지에 몰려 있고 BLAKE2f는 사실상 계약 하나만 씁니다. 이 항목은 세 주소의 내부 구현을 일반 EVM 바이트코드로 바꿔 클라이언트가 유지할 특수 구현 수를 줄이고 영지식 증명 회로와 감사 범위도 함께 줄입니다. 다만 배포할 정확한 바이트코드와 가스 비교표는 아직 명세되지 않았고 큰 입력을 넣는 MODEXP 호출은 비용이 더 높아질 것으로 예상됩니다. 2026년 7월 헤고타 후보로 접수됐지만 9월 콜에서 대체 코드 성능 벤치마크가 무르익지 않았다는 이유로 제외됐습니다. 방향에는 다들 동의했고 Strawmap은 J* 포크(2028~29) 칸에 두고 있지만 예상일 뿐 확정은 아닙니다.
어떻게 동작하나
- 지금은 세 주소가 프리컴파일 0x03, 0x05, 0x09 주소를 호출하면 클라이언트가 소프트웨어 안에 따로 구현한 코드로 처리하고 프리컴파일 전용 공식으로 가스를 받습니다.
- 포크 블록에서 코드 설치 변경이 활성화되는 블록의 실행 시작 시점에 세 주소에 같은 기능을 하는 EVM 바이트코드를 넣고 그 블록부터 프리컴파일로 취급하지 않습니다. 아이덴티티 프리컴파일(0x04)을 바꾸는 EIP-7666과 같은 방식입니다.
- 이후에는 일반 계약처럼 실행 호출하는 쪽에서 보는 주소와 기능은 그대로입니다. 가스는 전용 공식 대신 실행한 명령어 비용의 합으로 과금되므로 비용은 달라집니다.
관련 EIP
- EIP-8200 프리컴파일의 EVM화