ERC-6492 카운터팩추얼 서명: 배포 전 스마트 지갑 검증 원리

스마트 지갑은 컨트랙트가 온체인에 생기기 전에도 주소를 가질 수 있어요. 가입 과정은 매끄러워지지만 난감한 질문이 남습니다. 아직 배포되지 않은 코드를 대신해 만든 서명을 dApp은 어떻게 검증할까요? **ERC-6492 카운터팩추얼 서명(Counterfactual Signature)**은 여기에 필요한 봉투 역할을 해요. 크립토 지갑 보안의 서명 도구를 확장하지만, 배포 전 계정을 자동으로 안전하게 만들어 주는 인증서는 아닙니다.

이 글에서는 표준이 무엇을 감싸는지, 검증자가 어떤 순서를 지켜야 하는지, 사용자와 개발자가 주의할 실패 지점을 설명해요. 교육 목적이며 투자 조언이 아닙니다(NFA). 스마트 계정 팩토리(Factory), 검증기, 서명 권한에는 버그나 악용 위험이 있으니 최신 구현을 확인하고 스스로 조사하세요(DYOR).

ERC-6492는 어떤 문제를 해결하나요?

많은 스마트 계정은 카운터팩추얼 방식으로 만들어져요. 보통 CREATE2를 이용해 미래 주소를 먼저 계산하고, 첫 트랜잭션이 필요할 때 계정 컨트랙트를 배포합니다. dApp은 배포 전부터 그 주소를 표시하거나 자산을 받거나 로그인을 요청할 수 있어요.

하지만 일반적인 서명 검증은 여기서 막힙니다. 외부 소유 계정(Externally Owned Account, EOA)은 타원곡선 서명으로 주소를 복구할 수 있어요. 이미 배포된 스마트 계정은 ERC-1271 스마트 컨트랙트 서명으로 대답할 수 있습니다. 반면 미배포 계정 주소에는 호출할 코드가 없어요.

이를 아직 문을 열지 않은 예약 매장에 비유해 볼게요. 주인은 서명된 임대 계약서를 보여줄 수 있지만, 직원이 출근하지 않아 방문자가 매장 규칙에 맞는 계약인지 물을 수 없습니다. ERC-6492는 건물을 세울 지시와 승인 증명을 한 봉투에 담아요. 검증자는 매장이 열리는 상황을 시뮬레이션한 뒤, 그 계정 규칙에 증명이 맞는지 묻습니다.

ERC-6492 명세는 최종(Final) 상태의 표준 ERC예요. ERC-1271을 대체하지 않습니다. 컨트랙트 계정이 ERC-1271로 직접 대답할 준비가 되기 전까지 쓸 수 있는 식별 가능한 래퍼(Wrapper)를 추가해요.

카운터팩추얼 스마트 계정 주소는 어떻게 정해지나요?

카운터팩추얼은 가짜 주소나 임의 주소라는 뜻이 아니에요. 배포 트랜잭션보다 먼저 계정 주소를 계산한다는 의미입니다. EIP-1014의 CREATE2는 배포자 주소, 솔트(Salt), 초기화 코드 해시로 컨트랙트 주소를 계산해요. 입력값이 같으면 미래 주소를 미리 알 수 있습니다.

이 특성은 계정 추상화(Account Abstraction)와 스마트 지갑 온보딩에 유용해요. 지갑 제공자는 새 사용자에게 곧바로 가스비를 마련하고 배포하라고 요구하지 않아도 계정 주소를 준비할 수 있습니다. 첫 번째 묶음 거래나 가스비 후원 작업이 생길 때까지 배포를 미룰 수 있어요.

하지만 예측 가능한 주소가 승인 권한을 증명하지는 않아요. 검증자는 팩토리 호출이 예상 계정을 만드는지, 그 계정의 검증 정책이 원래 서명을 받아들이는지 별도로 확인해야 합니다.

ERC-6492 래퍼에는 무엇이 들어가나요?

배포 전 서명자는 세 값을 감싸요.

1. create2Factory: 계정을 생성하거나 준비할 수 있는 팩토리 주소예요.
2. factoryCalldata: 팩토리에 전달할 정확한 호출 데이터입니다.
3. originalERC1271Signature: 계정이 만들어진 뒤 평가할 원래 증명이에요.

인코딩된 튜플 뒤에는 매직 바이트(Magic Bytes)라고 부르는 고정 32바이트 접미사가 붙습니다.

0x6492649264926492649264926492649264926492649264926492649264926492

반복되는 값은 형식을 표시할 뿐, 서명이 유효하다는 증거가 아니에요. 마지막 바이트는 일반적인 65바이트 ECDSA 서명의 유효한 v 값이 될 수 없어서, 검증자가 EOA 주소 복구 전에 이 래퍼를 구분하는 데 도움을 줍니다.

스마트 계정이 이미 배포됐다면 보통 일반 ERC-1271 서명을 만들어요. 다만 배포된 코드가 검증 전에 마이그레이션이나 업데이트가 필요할 때도 준비 호출을 래핑할 수 있습니다. 따라서 감싼 서명은 항상 코드가 비어 있는 주소에서만 온다고 가정하면 안 돼요.

반드시 지켜야 할 검증 순서

표준은 잘못된 결과를 피하기 위해 검증 순서를 정해 둡니다.

1. ERC-6492 접미사를 먼저 확인해요. 접미사가 있으면 팩토리, 호출 데이터, 내부 서명을 디코딩합니다.
2. 검증 문맥에서 계정을 준비하거나 배포해요. 필요하면 팩토리를 호출한 뒤 만들어진 계정에 내부 증명의 유효성을 묻습니다.
3. 컨트랙트 코드가 있으면 ERC-1271을 사용해요. 계정은 해시와 서명에 대해 예상 값 0x1626ba7e를 반환해야 합니다.
4. 컨트랙트 경로가 없을 때만 EOA 주소 복구를 시도해요. 복구 가능한 모양의 바이트가 컨트랙트 규칙을 우회하게 두면 안 됩니다.

오프체인 검증은 범용 검증기(Universal Validator)에서 이 흐름을 eth_call로 시뮬레이션할 수 있어요. 명세의 참조 설계는 결과를 돌려주면서 모의 배포의 상태 변경을 되돌립니다. 그렇다고 모든 자체 검증기가 부작용 없이 동작하는 것은 아니에요. 외부 팩토리를 CALL하는 온체인 검증에는 재진입(Reentrancy) 같은 별도 공격 표면이 생깁니다.

현재 Viem의 verifyMessage 문서는 배포 전 ERC-6492 계정을 지원하는 서명자 유형으로 안내해요. 접미사를 직접 떼고 어떤 검증법을 실행할지 추측하기보다, 유지 관리되는 도구를 사용하는 편이 일반적으로 안전합니다.

ERC-6492는 실무에서 어디에 쓰이나요?

첫 트랜잭션 전 로그인

새 스마트 지갑 사용자는 가스비를 내거나 사용자 작업(UserOperation)을 제출하기 전에 인증하려 할 수 있어요. ERC-6492를 지원하는 서비스는 현재 eth_getCode 결과가 비어 있다는 이유만으로 거부하지 않고 준비된 계정의 증명을 확인할 수 있습니다. 로그인 메시지에는 여전히 Sign-In with Ethereum에서 설명한 출처, 체인, 논스(Nonce), 발급 시각, 만료 보호가 필요해요.

오프체인 주문·클레임·증명

애플리케이션은 지금 서명을 받고 나중에 정산할 수 있어요. 래퍼를 지원하면 아직 배포되지 않은 스마트 계정도 참여할 수 있습니다. 배포 뒤 소유자, 모듈(Module), 구현 로직이 바뀔 수 있으므로 관련 시점에 다시 검증해야 해요.

지연 스마트 계정 배포

지갑 플랫폼은 계정이 실제 작업을 할 때까지 배포 비용을 미룰 수 있어요. Alchemy의 최신 스마트 지갑 서명 문서는 미배포 스마트 지갑의 서명을 ERC-6492로 래핑하며, 배포된 지갑은 ERC-1271 호환 방식으로 검증한다고 설명합니다.

위험과 흔한 연동 실수

매직 접미사를 유효성 도장처럼 보는 실수

누구나 알아볼 수 있는 바이트를 뒤에 붙일 수 있어요. 검증자는 래퍼를 안전하게 디코딩하고 올바른 흐름을 실행한 뒤, 계정이 ERC-1271 성공 값을 반환하는지 확인해야 합니다. 접미사가 일치한다는 사실만으로 서명자, 팩토리, 메시지는 증명되지 않아요.

신뢰하지 않은 팩토리 데이터를 무심코 호출하는 실수

래퍼에는 서명과 함께 전달된 대상과 호출 데이터가 들어 있어요. 따라서 검증에는 외부 호출이 포함됩니다. ERC 참조 구현은 읽기형 검증의 부작용을 격리하고, 부작용이 있는 검증에서는 재진입 위험을 경고해요. 권한이나 자산을 가진 컨트랙트에서 임의의 배포 호출을 직접 실행하지 말고, 검증 문맥에 맞게 감사된 구현을 사용해야 합니다.

맞는 서명을 틀린 메시지에 검증하는 실수

ERC-6492는 준비된 계정이 특정 다이제스트(Digest)를 규칙에 따라 승인하는지만 보여줘요. 도메인, 체인 ID, 목적, 논스, 기한, 지출 한도, 사람이 읽을 수 있는 안내를 자동으로 넣지 않습니다. 이런 속성은 보통 EIP-712 타입 데이터로 서명할 메시지에 담아야 해요.

크로스체인 재생과 바뀌는 승인 권한

명세는 네트워크 사이의 재생 공격(Replay Attack)을 명시적으로 경고합니다. 한 체인에서 소유자가 바뀌어 더는 유효하지 않은 서명도, 예전 권한으로 같은 팩토리와 계정을 배포할 수 있는 다른 체인에서는 통과할 수 있어요. 승인을 의도한 체인과 애플리케이션에 묶고, 정산할 때 최신 컨트랙트 상태를 다시 확인해야 합니다.

시뮬레이션 성공을 안전 보장으로 오해하는 실수

성공한 eth_call은 모의 상태에서 검증기가 증명을 받아들였다는 뜻이에요. 팩토리를 감사하거나 dApp을 인증하거나 이후 트랜잭션의 동일한 결과를 보장하지 않습니다. 사용자는 여전히 무엇을 승인하는지 이해해야 해요.

실전 검증 체크리스트

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

1. dApp 도메인과 선택한 체인을 별도 경로로 확인해요.
2. 서명 전 작업, 계정 주소, 자산, 한도, 논스, 만료를 읽습니다.
3. ‘가스리스(Gasless)’나 ‘아직 미배포’는 구현 방식일 뿐 안전 보장이 아니라고 생각해요.
4. 내용을 해석할 수 없는 서명과 예상하지 못한 계정 초기화·마이그레이션 요청은 거절합니다.
5. 소유자, 가디언(Guardian), 기기, 모듈을 바꾼 뒤에는 대기 중인 서명을 다시 점검해요.

개발자라면 다음을 확인해야 합니다.

1. EOA, ERC-1271, ERC-6492 경로를 모두 지원하는 유지 관리된 검증기를 사용해요.
2. 표준 순서대로 ERC-1271이나 EOA 복구보다 ERC-6492 접미사를 먼저 확인합니다.
3. 다이제스트를 도메인, 체인, 계정, 목적, 논스, 기한에 묶어요.
4. 잘못된 래퍼, 팩토리 실패, 틀린 매직 값, 조회할 수 없는 체인 상태는 안전하게 실패 처리합니다.
5. 온체인 검증의 재진입과 부작용을 모델링해요. 의도적인 설계 없이 권한 있는 문맥에서 신뢰하지 않은 팩토리 호출을 실행하면 안 됩니다.
6. 배포 전, 배포 후, 소유자 변경 후, 의도하지 않은 체인에서 각각 테스트해요.

자주 묻는 질문(FAQ)

ERC-6492와 ERC-1271은 같은가요?

아니요. ERC-1271은 배포된 컨트랙트가 서명의 유효성을 답하게 해요. ERC-6492는 계정 배포 또는 준비 데이터를 ERC-1271 호환 증명과 함께 감싸서, 배포 전이나 준비 전에도 검증할 수 있게 합니다.

검증하면 스마트 지갑이 영구적으로 배포되나요?

반드시 그렇지는 않아요. 오프체인 검증은 eth_call 안에서 배포를 시뮬레이션하고 상태 변경을 버릴 수 있습니다. 온체인 또는 부작용을 허용한 구현은 다르게 동작할 수 있으니 사용하는 검증기와 트랜잭션을 확인하세요.

소유자의 서명에 ecrecover를 쓰면 안 되나요?

승인 권한은 애플리케이션이 아니라 스마트 계정이 정해요. 계정은 여러 소유자, 패스키(Passkey), 모듈, 변경 가능한 정책을 요구할 수 있습니다. EOA 하나만 복구하면 이런 컨트랙트 규칙을 우회하고 잘못된 권한 주체를 찾을 수 있어요.

ERC-6492는 CREATE2 계정 전용인가요?

표준은 예측 가능한 컨트랙트 주소를 제공하는 CREATE2 사용을 권장해요. 다만 래퍼는 하나의 팩토리 인터페이스를 강제하지 않고 팩토리 호출 데이터를 담습니다. 검증자는 여전히 예상 계정 주소에서 시작해 만들어진 계정의 규칙을 검증해야 해요.

오래된 카운터팩추얼 서명도 유효할 수 있나요?

메시지 범위, 계정 정책, 체인, 상태에 따라 가능해요. 논스와 기한을 사용하고, 의도한 체인과 애플리케이션을 메시지에 묶고, 저장된 결과가 영구적이라고 가정하지 말고 다시 검증하세요.

핵심 정리

ERC-6492는 정확한 빈틈을 메워요. 스마트 계정은 주소와 유효한 승인 정책을 미리 가질 수 있지만 그 주소에는 아직 코드가 없을 수 있습니다. 래퍼는 검증자가 계정을 시뮬레이션하거나 준비한 뒤, 이를 EOA로 잘못 취급하지 않고 ERC-1271 규칙을 적용할 정보를 제공해요.

호환성은 좋아지지만 검증 표면은 넓어집니다. 팩토리 호출, 재생 방지, 최신 계정 상태, 정확한 메시지 구성, 사람이 이해할 수 있는 동의가 모두 중요해요. 서명과 그 서명이 승인하는 행동을 함께 검증하세요. 이 글은 교육 목적이며 투자 조언이 아닙니다. 스마트 컨트랙트 사용은 전액 손실로 이어질 수 있으니 잃어도 되는 금액만 사용하고 항상 스스로 조사하세요(DYOR).