곰투 크립토
guide전체 47편 중 46편

이더리움 프리컴파일 완전 정리: 내장 컨트랙트 주소·가스·안전한 호출법

이더리움 프리컴파일이 고정 주소에서 네이티브 암호 연산을 제공하는 원리, Fusaka 이후 활성 목록과 안전한 호출 체크리스트를 설명해요.

GOMTU
GOMTU
크립토 리서치 · 발행 · 약 8분
공유𝕏in
이더리움 프리컴파일 완전 정리: 내장 컨트랙트 주소·가스·안전한 호출법

컨트랙트가 아주 작은 주소를 호출했는데 저장된 바이트코드는 보이지 않고, 암호 연산 결과는 정상적으로 돌아옵니다. 모순처럼 느껴지셨나요? 블록체인 인프라를 들여다보다 보면 이더리움 가상머신(EVM)의 특별한 예외인 **프리컴파일 컨트랙트(Precompiled Contract)**를 만나게 돼요.

프리컴파일은 서명 복구, 해시, 모듈러 연산, 타원곡선 수학, 증명 검증처럼 비싼 표준 연산을 긴 Solidity 코드로 한 명령씩 실행하지 않고 프로토콜의 네이티브 함수로 처리합니다. 효율적이지만 자동 안전장치는 아니에요. 정확한 주소와 바이트 인코딩, 충분한 가스, 활성 포크에 맞는 반환값 검사가 모두 필요합니다.

이 글은 Fusaka/Osaka 업그레이드 이후 이더리움 메인넷을 기준으로 설명해요. 다른 EVM 호환 네트워크는 프리컴파일 종류나 가스 가격이 다를 수 있습니다. 교육 목적이며 투자 조언이 아닙니다(NFA). 저수준 호출에 의존하기 전에 대상 체인과 최신 명세를 직접 확인하세요.

이더리움 프리컴파일이란 무엇인가요?

광고

EVM을 작업장에 비유해 볼게요. 일반 스마트 컨트랙트는 배포한 바이트코드라는 작업 지시서를 가져오고, 작업장은 명령을 하나씩 실행합니다. 프리컴파일은 작업장 바닥에 이미 설치된 인증 장비에 가까워요. 정해진 모양의 입력을 고정 주소로 보내면 실행 클라이언트가 프로토콜에 내장된 함수를 실행합니다.

컨트랙트 입장에서는 여전히 메시지 호출처럼 보여요. CALL이나 읽기 전용 STATICCALL로 콜데이터와 가스를 전달하고 성공 여부와 반환 데이터를 확인합니다. 하지만 내부 동작은 계정에 저장된 코드가 아니라 합의 규칙에 포함돼요. 모든 정상 실행 클라이언트가 같은 결과를 내야 합니다.

이 차이에서 세 가지 실무 포인트가 나옵니다.

  • eth_getCode 결과가 0x여도 해당 주소가 실제 기능을 수행할 수 있어요.
  • 입력과 출력은 보통 Solidity 함수 셀렉터 ABI가 아니라 해당 프리컴파일 명세를 따릅니다.
  • 프리컴파일 추가나 변경은 모든 실행 클라이언트의 합의가 필요하므로 네트워크 업그레이드를 거쳐요.

이더리움 옐로 페이퍼는 초기 실행 예외를 형식적으로 설명하고, 현재 이더리움 실행 명세는 포크별 동작을 추적합니다.

현재 이더리움 프리컴파일 주소 지도

이더리움 메인넷의 활성 목록은 여러 업그레이드를 거쳐 늘어났어요. 아래 표는 Pectra의 BLS12-381 연산과 Fusaka의 P-256 검증기를 포함한 현재 기준입니다.

주소기능대표 용도도입·변경 명세
0x01ECRECOVERsecp256k1 서명에서 이더리움 주소 복구Frontier 규칙
0x02SHA2-256임의 입력의 SHA-256 해시Frontier 규칙
0x03RIPEMD-160RIPEMD-160 다이제스트 계산Frontier 규칙
0x04Identity입력 바이트를 그대로 반환Frontier 규칙
0x05MODEXP모듈러 거듭제곱 계산EIP-198, Fusaka에서 재가격·상한 적용
0x06–0x08BN254 덧셈·곱셈·페어링페어링 곡선 연산과 증명 검증EIP-196·197·1108
0x09BLAKE2 FBLAKE2b 압축 함수EIP-152
0x0aKZG 포인트 평가블롭 커밋먼트 평가 증명 검증EIP-4844
0x0b–0x11BLS12-381 연산덧셈·다중 스칼라 곱셈·페어링·곡선 매핑EIP-2537
0x100P256VERIFYsecp256r1/P-256 서명 검증EIP-7951

처음 아홉 개는 옐로 페이퍼에서 확인할 수 있어요. EIP-4844는 KZG 포인트 평가 프리컴파일을 0x0a에 배정합니다. EIP-25370x0b부터 0x11까지 일곱 BLS12-381 주소를 정의해요. 실행 명세에는 이 기능들이 2025년 5월 7일 Pectra 메인넷에서 활성화된 사실이 기록돼 있습니다.

가장 새로운 항목은 연속된 주소 밖에 있어요. EIP-7951은 160바이트 입력과 32바이트 성공값을 사용하는 P256VERIFY0x100에 정의합니다. 이더리움 재단의 Fusaka 메인넷 공지에 따르면 2025년 12월 3일 활성화됐어요. 같은 업그레이드는 MODEXP도 바꿨습니다. EIP-7823은 각 입력 수를 8192비트로 제한하고, EIP-7883은 실제 연산 비용에 맞춰 가스를 재책정했어요.

Note

EIP가 제안됐다고 곧바로 메인넷 프리컴파일이 되는 것은 아닙니다. EIP 포함 여부와 대상 네트워크의 포크 활성화를 모두 확인하세요. 아직 활성화되지 않은 Glamsterdam 제안을 현재 메인넷 규칙으로 다루면 안 돼요.

프리컴파일 호출은 어떻게 작동하나요?

일반 Solidity 함수 호출보다는 바이너리 프로토콜 요청에 더 가깝습니다.

  1. 해당 EIP가 요구하는 정확한 바이트열을 인코딩하세요.
  2. 상태 변경과 가치 전송이 필요 없다면 보통 staticcall로 고정 주소를 호출합니다.
  3. EVM 호출의 성공 플래그를 확인하세요.
  4. 명세가 정의한 반환 데이터 길이와 값을 모두 검사하세요.
  5. 잘못된 입력, 빈 출력, 미지원 체인 동작을 명시적으로 처리하세요.

예를 들어 EIP-7951은 메시지 해시, 서명 r, 서명 s, 공개키 x, 공개키 y 순서로 다섯 개의 32바이트 값을 요구해요. 최소 래퍼는 다음과 같이 만들 수 있습니다.

library P256Verifier {
    address internal constant P256 = address(0x100);
 
    function verify(
        bytes32 messageHash,
        bytes32 r,
        bytes32 s,
        bytes32 x,
        bytes32 y
    ) internal view returns (bool) {
        bytes memory input = abi.encodePacked(messageHash, r, s, x, y);
        (bool ok, bytes memory output) = P256.staticcall(input);
 
        return ok
            && output.length == 32
            && abi.decode(output, (uint256)) == 1;
    }
}

반환 길이 검사가 특히 중요해요. 코드가 없는 일반 주소를 호출해도 성공하면서 빈 바이트를 반환할 수 있습니다. ok만 확인하면 0x100을 지원하지 않는 체인에서 아무것도 실행되지 않은 상황을 유효한 검증으로 오해할 수 있어요. EIP-7951은 유효하지 않은 서명에도 빈 데이터를 반환하므로, 명세의 32바이트 성공값과 모든 빈 출력 경로를 구분해야 합니다.

실서비스에서는 충분히 검토된 라이브러리를 사용하고 공식 테스트 벡터를 실행하며 지원 체인과 포크 조건을 명시하세요. 위 코드는 반환 처리의 핵심을 보여주는 예시일 뿐, 완성된 인증 시스템은 아닙니다.

이더리움은 왜 프리컴파일을 사용하나요?

특수 수학을 실용적인 비용으로 실행해요

일부 암호 연산은 EVM 바이트코드로 구현할 수 있어도 일상적으로 사용하기에는 너무 비쌉니다. 프리컴파일은 클라이언트의 최적화된 구현과 합의로 정한 가스 비용을 제공해요. BN254 페어링은 간결한 증명 검증을 블록 한도 안에서 실용적으로 만들었습니다. 자세한 연결은 영지식 증명 가이드에서 확인할 수 있어요.

표준 주소가 상호운용성을 높여요

메인넷의 모든 컨트랙트가 같은 주소와 인코딩을 사용할 수 있습니다. 호출자가 SHA-256이나 타원곡선 구현을 매번 새로 배포할 필요가 없어요. 증명 시스템, 브릿지, 서명 체계, 지갑 컨트랙트에 특히 유용합니다.

새 암호 프리미티브가 사용자 경험을 개선해요

P-256은 스마트폰, 보안 키, 보안 영역(Secure Enclave), WebAuthn 생태계에서 널리 지원돼요. 네이티브 서명 검증은 계정 시스템이 기기 기반 자격 증명을 활용할 수 있는 직접적인 길을 제공합니다. 그렇다고 모든 패스키 크립토 지갑이 안전해지는 것은 아니에요. 복구 정책, 트랜잭션 의도, 스마트 계정 코드의 위험은 그대로 남습니다.

프리컴파일·옵코드·시스템 컨트랙트의 차이

세 방식 모두 프로토콜 기능을 노출할 수 있지만 경계가 달라요.

방식접근 방법동작의 출처예시
프리컴파일고정 주소로 메시지 호출실행 클라이언트 네이티브 로직과 포크 규칙0x100P256VERIFY
옵코드(Opcode)EVM 바이트코드에 직접 포함EVM 명령어 집합SHA3, TLOAD, CLZ
시스템 컨트랙트프로토콜 관리 코드·상태의 고정 주소 호출배포 코드와 특별한 프로토콜 업데이트EIP-4788 비콘 루트 컨트랙트
일반 컨트랙트배포 주소로 메시지 호출사용자가 배포한 바이트코드와 스토리지ERC-20 토큰

디버깅할 때 이 구분이 중요합니다. 프리컴파일에는 검증할 일반 런타임 바이트코드가 없으므로 블록 탐색기에 소스가 보이지 않을 수 있어요. 반대로 고정 주소의 시스템 컨트랙트는 프로토콜이 상태를 갱신하면서도 코드와 스토리지를 가질 수 있습니다. 주소 모양만 보고 동작을 추측하지 마세요.

가스 계산도 인터페이스의 일부예요

프리컴파일은 효율적이지만 무료가 아닙니다. 호출자는 메시지 호출 오버헤드, 메모리 확장과 복사 비용, 프리컴파일 자체 비용을 냅니다. 고정 비용인 함수도 있고 입력 길이나 곡선 포인트 수에 따라 달라지는 함수도 있어요.

벤치마크에서 과소·과대 가격이 드러나면 하드포크로 가스 일정이 바뀔 수 있습니다. Fusaka의 MODEXP 재가격이 최근의 대표 사례예요. 과거 추정치를 하드코딩하면 위험한 이유입니다. 대상 포크의 최신 규칙으로 전체 거래를 추정하고 영수증의 실제 gasUsed를 비교하세요. 가스 단위가 ETH 수수료가 되는 과정은 가스비 설명 가이드에 정리돼 있어요.

Warning

가스를 많이 전달한다고 잘못된 입력이 안전해지지는 않습니다. 일부 프리컴파일은 검증 실패 시 전달받은 가스를 모두 소모할 수 있어요. 사용자 입력의 길이와 범위를 먼저 제한하고 남은 가스를 무제한으로 넘기지 마세요.

리스크와 한계

인코딩 실수는 엉뚱한 계층에서 실패해요

필드 원소, 곡선 점, 스칼라, 서명에는 정확한 바이트 순서·길이·범위 규칙이 있습니다. abi.encodeabi.encodePacked는 서로 바꿔 쓸 수 없어요. 래퍼가 정상 컴파일돼도 프리컴파일이 거부하는 바이트를 만들 수 있습니다.

EVM 호환이 프리컴파일 동일성을 뜻하지 않아요

L2와 다른 EVM 체인은 특정 프리미티브를 더 일찍 활성화하거나 사용자 정의 프리컴파일을 다른 주소에 두고 가스 일정을 바꿀 수 있어요. RIP-7212 구현은 이더리움 L1이 EIP-7951을 채택하기 전에 P-256 인터페이스를 확산시켰지만, 지원 여부는 여전히 체인별로 확인해야 합니다.

네이티브 코드는 합의 표면을 넓혀요

모든 클라이언트가 경계 조건에 동의해야 합니다. 잘못된 곡선 점 처리, 입력 패딩, 가스 계산이 모두 합의에 영향을 줘요. 그래서 프리컴파일 제안에는 명세, 테스트 벡터, 벤치마크, 조정된 활성화가 필요합니다.

암호 검증은 정해진 관계만 증명해요

유효한 서명은 사용자가 거래 내용을 이해했다는 뜻이 아닙니다. 유효한 페어링 결과도 애플리케이션이 안전한 증명 시스템과 신뢰 설정을 골랐다고 보장하지 않아요. 프리컴파일은 프리미티브를 빠르게 실행할 뿐, 앱 보안은 호출자의 책임입니다.

미래 포크가 비용과 가용성 가정을 바꿀 수 있어요

이더리움은 이후 업그레이드에서 기능을 재가격하거나 추가·대체하고 일부를 EVM 코드로 옮길 수 있습니다. 인프라는 목록이 영원히 고정돼 있다고 가정하지 말고 활성 체인 설정을 식별해야 해요.

개발자 체크리스트

  • 정확한 체인과 포크에서 프리컴파일이 활성화됐는지 확인했나요?
  • 최종 EIP와 현재 실행 명세를 읽었나요?
  • 입력 길이, 바이트 순서, 범위, 곡선 멤버십 조건을 검증했나요?
  • 호출 성공과 정확한 반환 데이터 의미를 모두 확인하나요?
  • 가스와 사용자 제어 입력에 상한을 두었나요?
  • 유효·무효·축약·초과·빈 입력을 모두 시험했나요?
  • 지원하는 실행 클라이언트와 테스트 환경에서 공식 벡터를 실행했나요?
  • 업그레이드 후 과거 가스 상수를 재사용하지 않고 다시 추정하나요?
  • 프리미티브가 증명하는 것과 앱이 여전히 신뢰하는 것을 문서화했나요?

자주 묻는 질문

프리컴파일은 일반 스마트 컨트랙트인가요?

아니요. 컨트랙트처럼 주소로 호출하지만, 계정에 저장된 일반 바이트코드가 아니라 합의 규칙에 따른 실행 클라이언트 로직이 동작합니다.

작동하는 프리컴파일에서 eth_getCode가 왜 0x를 반환하나요?

반환할 배포 런타임 바이트코드가 없기 때문이에요. 실행 중 클라이언트가 주소를 인식해 네이티브 함수를 호출합니다.

프리컴파일 주소로 ETH를 보내도 되나요?

주소는 가치를 받을 수 있지만 유용한 연산이나 복구 경로가 생기지는 않습니다. 프리컴파일로 자금을 보내지 마세요. 명세의 입력과 출력을 처리하는 래퍼를 통해서만 호출해야 합니다.

모든 EVM 체인에서 0x100을 쓸 수 있나요?

아니요. 이더리움 메인넷에서는 Fusaka 이후 활성화됐지만 다른 네트워크는 업그레이드 일정과 사용자 정의 주소 지도가 달라요. 체인별로 지원 여부를 감지하거나 설정하세요.

프리컴파일은 항상 Solidity보다 저렴한가요?

네이티브 실행에 적합한 연산을 위해 설계됐지만 총비용에는 호출 오버헤드, 메모리, 입력 크기, 현재 포크의 가스 일정이 포함됩니다. 모든 사용이 더 저렴하다고 가정하지 말고 전체 호출을 측정하세요.

주요 1차 출처

마무리

이더리움 프리컴파일은 컨트랙트 모양의 문 뒤에 있는 프로토콜 네이티브 장비예요. 표준 암호 연산을 실용적인 비용으로 만들지만, 고정 주소는 인터페이스의 시작일 뿐입니다. 안전하게 연결하려면 정확한 인코딩, 포크에 맞는 가스 가정, 엄격한 출력 검사, 프리미티브가 보장하지 않는 범위까지 알아야 해요.

명세를 실행 가능한 보안 문서처럼 다루세요. 대상 체인에서 시험하고 검토된 래퍼를 사용하며 업그레이드마다 가정을 다시 확인해야 합니다. 이 글은 교육 목적이며 투자 조언이 아닙니다(NFA). 크립토 앱과 스마트 컨트랙트는 실패하거나 자금 손실을 일으킬 수 있어요. 잃어도 감당할 수 있는 범위에서 신중하게 시험하고 반드시 스스로 조사하세요(DYOR).

광고

함께 읽으면 좋은 글

관련 주제 살펴보기

GOMTU의 다른 글