ERC-1271 스마트 컨트랙트 서명: 지갑은 권한을 어떻게 검증할까?

스마트 계정은 여러 소유자, 패스키, 복구 정책, 시간이 지나며 바뀌는 규칙으로 제어될 수 있어요. 그렇다면 계정 주소 자체에 하나의 개인 키가 없는데도 dApp은 그 계정이 메시지를 승인했다고 어떻게 판단할까요? ERC-1271 스마트 컨트랙트 서명은 서명의 유효성을 컨트랙트가 직접 판단하게 해 이 문제를 풀어요. 실전 크립토 지갑 보안에서 작지만 중요한 표준입니다.

이 글에서는 검증 흐름, 일반 지갑 서명과의 차이, 사용자와 개발자가 확인할 항목을 설명해요. 교육 목적이며 투자 조언이 아닙니다(NFA). 컨트랙트 코드, 연동, 서명 권한은 실패하거나 악용될 수 있으니 최신 구현을 직접 검증하고 스스로 조사하세요(DYOR).

ERC-1271은 어떤 문제를 해결하나요?

외부 소유 계정(Externally Owned Account, EOA)에는 개인 키가 있어요. EOA가 메시지에 서명하면 소프트웨어가 타원곡선 암호학으로 서명 주소를 복구하고 예상 주소와 비교할 수 있습니다. 스마트 컨트랙트 계정은 달라요. 컨트랙트 주소 자체에는 개인 키가 없습니다.

EOA를 한 사람의 자필 서명만 받는 문서라고 생각해 보세요. 스마트 계정은 회사의 승인 창구와 비슷합니다. 이사 두 명이 서명했는지, 한도를 넘지 않았는지, 지정 기기가 승인했는지 규칙으로 판단해요. ‘회사의 펜’을 찾는 대신 회사 규정이 이 승인을 유효하다고 보는지 묻는 셈입니다.

ERC-1271 명세는 이 질문의 형식을 표준화해요. 컨트랙트는 isValidSignature(bytes32 hash, bytes signature) 함수를 제공합니다. 해당 해시와 서명이 유효하면 4바이트 매직 값 0x1626ba7e를 반환하고, 아니라면 다른 값을 반환하거나 실행을 되돌려요.

표준은 승인 정책까지 정하지 않습니다. 한 명의 소유자, 다중서명 임계값, 온체인에서 미리 승인한 메시지, 패스키 검증기 등 다양한 규칙을 쓸 수 있어요. 이런 유연성 덕분에 ERC-1271은 프로그래밍 가능한 계정 추상화와 스마트 지갑에 잘 맞습니다.

ERC-1271 서명 검증은 어떻게 작동하나요?

일반적인 애플리케이션은 다음 순서로 확인해요.

1. 사용자가 승인할 정확한 메시지 또는 구조화 데이터 해시를 만듭니다.
2. 스마트 계정의 소유자나 승인 기기가 계정 규칙에 맞는 증명을 만들어요.
3. 애플리케이션은 서명자 주소에 컨트랙트 코드가 있는지 확인합니다.
4. 해당 컨트랙트의 isValidSignature에 해시와 서명 바이트를 전달해요.
5. ERC-1271 매직 값이 반환될 때만 승인을 인정합니다.

서명은 형식이 고정되지 않은 바이트 배열이에요. 어떤 계정은 소유자 한 명의 일반 서명을 담고, 다중서명 지갑은 여러 서명을 담을 수 있습니다. 다른 구현은 완전히 다른 방식으로 해석할 수도 있어요. 검증자가 형식을 추측하는 대신 스마트 계정의 로직에 판단을 맡기는 구조입니다.

검증 함수는 상태를 바꾸면 안 돼요. 읽기 전용으로 확인해야 서명 검증 자체가 계정 작업으로 변하지 않습니다. ethereum.org의 ERC-1271 튜토리얼은 Safe를 예로 들어 소유자들의 오프체인 서명과 다중서명 임계값을 거쳐 온체인에서 승인한 메시지를 설명합니다.

EOA 서명과 스마트 컨트랙트 서명 비교

질문	EOA 서명	ERC-1271 컨트랙트 서명
유효성을 누가 정하나요?	개인 키에서 주소를 복구하는 고정 암호 규칙	스마트 계정 주소의 코드
일반적인 확인 방법	서명에서 주소 복구	isValidSignature 호출
규칙을 바꿀 수 있나요?	계정 수준에서는 매우 제한적	임계값·모듈·패스키·정책 설정 가능
유효성이 나중에 변하나요?	암호학적으로 유효한 서명은 보통 유지	소유자·모듈·상태가 바뀌면 달라질 수 있음
EVM 호출이 필요한가요?	항상 필요하지는 않음	보통 관련 체인의 상태를 조회해야 함

마지막 차이가 중요해요. 컨트랙트 서명은 영원히 유효하다고 볼 수 없습니다. Safe의 소유자나 임계값이 바뀌면 과거에는 유효했던 증명이 현재 규칙에서는 거부될 수 있어요. 검증 결과를 영구 저장하는 애플리케이션은 위험한 가정을 하게 됩니다.

ERC-1271은 어디에 쓰이나요?

스마트 계정 로그인과 증명

서비스는 거래를 보내지 않고 주소의 통제권을 증명해 달라고 요청할 수 있어요. ECDSA 주소 복구만 지원하면 컨트랙트 계정은 제외됩니다. ERC-1271은 표준 검증 경로를 제공하지만, 메시지를 올바른 도메인, 목적, 논스(Nonce), 만료 시각에 결합하는 일은 여전히 필요해요.

오프체인 주문·투표·권한

탈중앙화 거래소, 거버넌스, 토큰 권한 시스템은 오프체인에서 서명을 받은 뒤 나중에 정산하곤 합니다. 검증자는 EOA 서명을 확인하거나 컨트랙트 지갑에 같은 해시가 유효한지 물을 수 있어요. 예를 들어 유니스왑 Permit2는 ERC-1271 컨트랙트 지갑 서명을 지원합니다. 그래도 Permit과 Permit2 서명의 범위는 똑같이 꼼꼼히 읽어야 해요.

다중서명과 프로그래밍 가능한 승인

컨트랙트는 자체 거버넌스 규칙을 하나의 호환 가능한 답으로 바꿔 줍니다. 2-of-3 다중서명은 임계값을 확인하고, 정책 지갑은 한도를 넘거나 기한이 지난 승인을 거부할 수 있어요. ERC-1271이 표준화하는 것은 인터페이스이며 그 뒤의 정책은 아닙니다.

위험과 연동 실패 지점

모든 서명자를 EOA로 취급하는 오류

ECDSA 주소 복구만 실행하는 애플리케이션은 정상적인 스마트 계정을 거부할 수 있어요. 임의로 만든 대체 로직은 엉뚱한 서명을 받아들일 위험도 있습니다. OpenZeppelin의 최신 SignatureChecker 문서는 EOA와 ERC-1271을 함께 확인하는 경로를 제공하지만, 개발자는 여전히 정확한 서명자·해시·체인 맥락을 전달해야 합니다.

호출 성공만 확인하는 오류

검증자는 정확한 매직 반환 값을 확인해야 해요. 호출이 되돌려지지 않았다는 사실만으로 유효성을 증명할 수 없습니다. 반환 데이터가 잘못됐거나 예상보다 많은 가스를 소비하는 컨트랙트도 실패로 안전하게 처리해야 해요.

계정·체인·애플리케이션 사이 재생 공격

ERC-1271은 계정 정책이 받은 증명을 검증할 뿐, 잘못 설계한 메시지를 자동으로 재생 공격(Replay Attack)에서 보호하지 않아요. 보통 EIP-712 도메인 분리(Domain Separation), 논스, 기한으로 승인 대상과 범위를 묶어야 합니다. OpenZeppelin의 스마트 계정 가이드는 같은 서명자가 통제하는 다른 계정에서 재생되는 위험을 줄이기 위해 ERC-7739 방어적 재해싱도 권장해요.

바뀌는 규칙과 유효성

소유자가 교체되고, 모듈이 바뀌며, 계정 로직이 업그레이드될 수 있어요. 한 블록에서 유효했던 결과가 나중에는 달라질 수 있습니다. 검증자는 현재 블록, 과거 블록, 실제 정산 시점 중 어느 시점의 유효성이 필요한지 정하고 적절한 체인 맥락을 기록해야 해요.

유효한 서명이 나쁜 행동을 승인할 수도 있어요

암호학적 유효성은 ‘이 계정이 규칙에 따라 이 해시를 승인했는가’에만 답합니다. ‘이 행동이 안전하거나 유리한가’는 알려 주지 않아요. 피싱 사이트도 유해한 권한에 정상 서명을 요청할 수 있습니다. 클리어 사이닝으로 출처와 범위를 확인하고, 설명할 수 없는 요청은 거절하세요.

실전 확인 체크리스트

사용자라면 다음을 확인해 보세요.

1. 스마트 계정을 연결하기 전에 사이트와 체인을 독립적으로 검증해요.
2. 행동, 컨트랙트, 자산, 한도, 논스, 만료 시각을 읽습니다.
3. 특히 임계값 계정에서는 예상한 소유자나 기기가 승인했는지 확인해요.
4. 가스비가 없어도 읽을 수 없거나 설명되지 않은 메시지는 거절합니다.
5. 소유자·가디언·모듈 변경 뒤에는 대기 중인 승인을 다시 점검해요.

개발자라면 다음 원칙이 중요합니다.

1. 검증에 필요한 체인 상태를 기준으로 컨트랙트 서명자를 식별해요.
2. EOA에는 ECDSA 복구, 컨트랙트 계정에는 ERC-1271 경로를 사용합니다.
3. 정확한 0x1626ba7e만 인정하고 오류와 잘못된 데이터는 실패로 처리해요.
4. 메시지를 도메인으로 분리하고 목적별 논스와 합리적인 만료를 넣습니다.
5. 계정 규칙이 바뀔 수 있다면 결과를 영구 캐시하지 말고 다중서명·업그레이드·실패 사례를 테스트해요.

자주 묻는 질문

스마트 컨트랙트 지갑에도 개인 키가 있나요?

컨트랙트 주소 자체에는 없어요. 소유자나 기기가 개인 키 또는 패스키를 사용할 수 있지만, 그 증명이 계정 권한을 충족하는지는 컨트랙트 규칙이 판단합니다.

ERC-1271과 계정 추상화는 같은 개념인가요?

아니에요. 계정 추상화는 프로그래밍 가능한 계정이라는 더 넓은 모델입니다. ERC-1271은 다른 소프트웨어가 컨트랙트 계정에 메시지 서명의 유효성을 물을 수 있게 하는 좁은 인터페이스예요.

isValidSignature 호출에는 가스비가 드나요?

오프체인 읽기 호출은 사용자가 거래를 제출하지 않으므로 별도 가스비가 없어요. 다른 온체인 거래 안에서 검증하면 해당 거래의 연산 비용에는 포함됩니다.

ERC-1271 서명이 나중에 무효가 될 수 있나요?

그럴 수 있어요. 현재 소유자, 임계값, 모듈, 승인 메시지 상태, 업그레이드 가능한 로직에 따라 결과가 달라질 수 있습니다. 답이 영원히 같다고 가정하면 안 돼요.

핵심 정리

ERC-1271은 스마트 계정이 특정 해시와 증명을 승인했는지 표준 형식으로 답하게 해요. 이 작은 인터페이스 덕분에 다중서명과 프로그래밍 가능한 지갑도 EOA 한 개의 키를 전제로 만든 로그인, 주문, 투표, 권한 흐름에 참여할 수 있습니다.

하지만 안전 인증 마크는 아니에요. 정확한 메시지 구성, 반환 값 확인, 재생 방지, 현재 체인 상태, 이해할 수 있는 지갑 표시가 모두 필요합니다. 서명뿐 아니라 승인하는 행동도 검증하세요. 이 글은 교육 목적이며 투자 조언이 아닙니다. 스마트 컨트랙트 사용은 전액 손실로 이어질 수 있으니 감당 가능한 범위에서만 이용하고 항상 DYOR를 실천하세요.