ERC-1271은 개인키가 없는 계약도 서명을 검증할 수 있도록 isValidSignature(bytes32, bytes) 함수와 성공 시 반환값 0x1626ba7e를 정합니다. 이 글은 2026-10-27에 연 ERC-1271 원문(상태 Final)으로 확인한 범위만 다룹니다.
확인 기준일 2026-10-27 · 다음 확인 예정 2026-11-26
왜 계약에는 별도 표준이 필요했을까?
원문 Abstract는 외부 소유 계정(EOA)은 개인키로 메시지를 서명할 수 있지만 계약은 그럴 수 없다는 문제에서 출발합니다. 계약이 자신을 대신한 서명을 검증하는 표준 방법을 정합니다.
| 항목 | 원문 내용 |
|---|---|
| 함수 | isValidSignature(bytes32 _hash, bytes memory _signature) returns (bytes4) |
| 성공 반환값 | 0x1626ba7e (MAGICVALUE) |
| 상태 변경 | 금지 (solc 0.5 이전은 STATICCALL, 이후는 view) |
| 실패 반환값 | 명세에 없음, 참조 구현은 0xffffffff |
함수는 무엇을 받고 무엇을 돌려줄까?
함수는 32바이트 해시와 서명 바이트를 받아 bytes4 값을 돌려줍니다. 서명이 유효하면 반드시 0x1626ba7e를 돌려줘야 하고, 상태를 바꾸면 안 됩니다. 실패 때 돌려줄 값은 명세에 정해져 있지 않고 참조 구현이 0xffffffff를 씁니다. 불리언 대신 특정 값을 쓰는 이유는 더 엄격하고 단순한 검증을 위해서라고 원문이 설명합니다.
앱과 지갑은 어떻게 이용할까?
계약 지갑이 서명 로그인에 쓰이는 과정은 이더리움으로 로그인(SIWE) 서명은 무엇을 승인하나: ERC-4361 메시지 읽는 법 글에, 권한 구조는 계정 추상화란? 스마트 계정의 권한과 수수료 구조 글에 있습니다. 서명 자체가 유효해도 어떤 권한을 주는 내용인지는 별도로 읽어야 합니다.
호출하는 쪽은 무엇을 지켜야 할까?
검증을 요청하는 쪽은 서명자 계약의 isValidSignature를 호출해 반환값이 정확히 0x1626ba7e인지 비교하면 됩니다. 원문이 상태 변경을 금지하므로 이 호출은 읽기 전용으로 부를 수 있습니다. 반환값이 매직값과 다르면 모두 실패로 취급하는 것이 단순하고 엄격한 방식이며, 이것이 불리언 대신 특정 값을 쓴 취지입니다. 다만 계약 내부에서 서명 유효 조건을 어떻게 정하는지는 계약마다 다르므로, 같은 서명이 어느 계약에서는 통과하고 다른 계약에서는 거절될 수 있습니다.
이 글에서 확인하지 못한 것은?
계약 지갑이 서명을 어떻게 구성하는지, 여러 서명자가 필요한 경우의 검증 방식, 호출 가스 한도는 원문이 정하지 않아 적지 않았습니다. 이후 확장된 서명 검증 표준이 있는지도 이번에 확인하지 않았습니다. 이 글은 원문 Specification과 Rationale에 적힌 범위로 한정합니다. 정리하면 이 표준은 계약이 서명 질문에 답하는 공통 창구이고, 답은 매직값 하나로 통일되어 있습니다. 반환값이 다르면 유효하지 않은 서명으로 읽는 것이 원문의 취지에 맞습니다. 상태는 Final, 작성일은 2018-07-25입니다.
자주 묻는 질문
계약 지갑 서명도 ecrecover로 확인하나요?
ecrecover는 EOA 서명용입니다. 계약에는 이 표준의 함수를 호출해 매직값을 확인합니다.
반환값이 true가 아니라 0x1626ba7e인 이유는요?
원문은 특정 값을 쓰면 검증이 더 엄격하고 단순해진다고 설명합니다.
이 표준이 서명 방식을 정해 주나요?
아닙니다. 계약이 서명을 어떻게 검증할지는 구현에 맡기고 호출 인터페이스만 정합니다.
