제1원리에서 출발하는 계정 추상화
Ethereum에서 자기수탁 지갑을 써본 적이 있다면, 알았든 몰랐든 외부 소유 계정 — EOA — 을 사용한 것입니다. 계정 추상화에 관한 이야기는 EOA가 무엇인지, 그 설계가 왜 온체인에서 할 수 있는 모든 것을 옭아매는지, 그리고 ERC-4337 계정 추상화가 베이스 프로토콜을 건드리지 않고 어떻게 그 제약을 우회하는지를 이해하는 데서 시작합니다. 이 글은, 본래의 제약에서부터 SSP가 EVM 체인에서 2-of-2 multisig를 구동하기 위해 계정 추상화를 어떻게 사용하는지까지 안내하는 시리즈의 입구입니다.
이것은 토대가 되는 개념적인 글입니다. ERC-4337 표준 자체에 초점을 맞춘 설명이 필요하다면, 이 글과 함께 계정 추상화(ERC-4337)란?을 읽어보세요. 여기서는 그 표준이 왜 존재하는지에 대한 직관을 쌓아 올립니다.
Ethereum이 당신에게 준 계정
Ethereum에는 두 종류의 계정이 있습니다. 컨트랙트 계정은 코드에 의해 다스려집니다. EOA — 대부분의 사람이 쓰는 평범한 지갑 — 는 단 하나의 개인 키에 의해 다스려집니다. 그 키를 쥔 사람은 계정에서 어떤 트랜잭션이든 승인할 수 있고, 프로토콜은 정확히 한 가지만 검증합니다. 즉, 트랜잭션이 주소를 통제하는 키가 생성한, secp256k1 곡선 위의 유효한 ECDSA 서명을 지니고 있는지입니다.
그 단 하나의 규칙은 우아하며, 동시에 아래에서 다룰 모든 제약의 근원이기도 합니다. 트랜잭션의 유효성은 프로토콜에 단단히 박혀 있습니다. 계정 소유자인 당신은 "유효함"이 무엇을 뜻하는지 정할 수 없습니다. 프로토콜이 정하며, 그것은 하나의 키에 대한 하나의 서명 방식만 확인할 줄 압니다.
그 설계가 뿌리부터 박아 넣는 것
네 가지 제약이 키 하나, 서명 하나라는 모델에서 곧장 흘러나옵니다.
- 키 하나는 단일 장애점입니다. 키를 잃으면 자금이 사라집니다. 유출하면 공격자가 전부를 가집니다. 프로토콜 수준에는 제2 요소도, 공동 서명자도, 도난을 막을 수 있었던 정책도 없습니다.
- 맞춤형 검증 로직이 없습니다. EOA는 "서명 두 개를 요구하라"고도, "이 소액 결제는 자동으로 허용하되 임계값을 넘으면 추가 승인을 요구하라"고도, "이 키는 평일에만 쓰게 하라"고도 말할 수 없습니다. 계정에는 로직이 없습니다. 서명 확인이 있을 뿐입니다.
- 보내는 쪽은 gas를 위해 ETH를 보유해야 합니다. 모든 EOA 트랜잭션은 자신의 gas를 ETH로 냅니다. ERC-20 토큰만 있고 ETH가 없는 새 사용자는 수수료를 낼 수 없으므로 그 토큰을 움직일 수 없습니다. 수수료를 내는 쪽과 트랜잭션을 보내는 쪽이 같은 계정이도록 강제됩니다.
- 시드 문구의 UX는 가차 없습니다. 키가 곧 계정이기에, 시작이란 시드 문구를 적어두고 영원히 지키는 일입니다. 그 문구를 거치지 않는 복구 경로는 없으며, 단 한 번의 실수가 영구적입니다.
이것들은 버그가 아닙니다. 검증이 계정이 아니라 프로토콜에 깃든 데서 비롯된 결과입니다.
핵심 발상: 계정을 프로그래밍 가능하게 만들기
계정 추상화는 그 검증 로직을 프로토콜에서 꺼내어 계정 자체로 옮긴다는 발상입니다. 네트워크가 "올바른 ECDSA 서명 하나가 있으면 트랜잭션이 유효하다"고 하드코딩하는 대신, 당신의 자금을 보관하는 컨트랙트인 smart account 가 무엇을 유효한 트랜잭션으로 칠지 스스로 정합니다.
계정이 프로그래밍 가능한 컨트랙트가 되는 순간, 네 가지 제약은 설계상의 선택으로 녹아듭니다.
- 하나가 아니라 서명 두 개를 요구할 수 있으며, 이것이 바로 프로토콜의 네이티브 지원 없이 multisig가 가능해지는 방식입니다.
- 복구 규칙을 구현할 수 있어, 잃어버린 키가 더는 이야기의 끝이 아니게 됩니다.
- 다른 누군가가 gas를 내게 할 수 있어, 수수료를 내는 쪽을 보내는 쪽에서 분리합니다.
- 여러 동작 — 예컨대 승인과 스왑 — 을 하나의 원자적 작업으로 묶을 수 있습니다.
계정은 수동적인 키 쌍이기를 멈추고, 당신이 통제하는 프로그래밍 가능한 로직이 됩니다.
ERC-4337이 하드포크 없이 이를 이루는 방식
어려운 점은, Ethereum이 트랜잭션을 검증하는 방식을 바꾸는 일이 보통 베이스 프로토콜을 바꾸는 일 — 느리고 논쟁적이며 네트워크 전체에 걸친 업그레이드 — 을 뜻한다는 것입니다. ERC-4337은 이를 통째로 우회합니다. 합의 변경을 전혀 요구하지 않으면서, 계정 추상화를 기존 네트워크 위에 얹는 계층으로 도입합니다.
그 메커니즘은 몇 가지 부품에 기댑니다.
- UserOperations. 평범한 트랜잭션을 보내는 대신, smart account는 의도를
UserOperation— 계정이 무엇을 하려는지와 어떻게 검증되어야 하는지를 기술하는 구조화된 객체 — 으로 표현합니다. - 대체 mempool. UserOperations는 일반 트랜잭션과 분리된, 자신만의 mempool에 머뭅니다.
- Bundlers. bundler는 그 mempool에서 UserOperations를 모아 함께 묶고, 베이스 레이어의 gas를 내면서 실제 트랜잭션으로 체인에 제출합니다.
- EntryPoint 컨트랙트. 감사를 거친 단 하나의
EntryPoint컨트랙트가 온체인의 길목입니다. 각 smart account를 호출해 그 계정 자신의 검증 로직을 돌리고, 검증을 통과하면 작업을 실행합니다. - Paymasters. 선택적인
paymaster컨트랙트는 어떤 UserOperation의 gas를 대신 떠맡기로 동의할 수 있으며, 이것이 무가스 및 토큰 결제 흐름을 가능케 하는 것입니다.
이를 한데 모으면, 바탕에 깔린 Ethereum 프로토콜은 있던 그대로 두면서, 어떤 컨트랙트든 자신의 규칙으로 검증되는 완전히 프로그래밍 가능한 계정으로 행동할 수 있게 됩니다. 이 표준은 EIP-4337에 규정되어 있고, Ethereum 자체의 계정 추상화 로드맵이 더 넓은 노력이 어디로 향하는지를 좇고 있습니다.
왜 이것이 자기수탁 사용자에게 중요한가
자기 키를 직접 쥔 사람에게 계정 추상화는 추상적인 프로토콜 세부 사항이 아닙니다 — 지갑이 안전하게 할 수 있는 일을 바꿉니다.
- 네이티브 지원 없는 multisig. smart account는 둘 이상의 서명을 요구할 수 있어, 지갑은 모든 이체를 두 대의 독립된 기기가 승인하도록 요구할 수 있습니다. 이것이 SSP가 기대는 빌딩 블록이며, 계정 추상화 방식의 EVM Multisig에서 더 자세히 설명합니다.
- 복구 선택지. 프로그래밍 가능한 검증은, 하나의 취약한 시드 문구로 무너지지 않는 복구 흐름으로 가는 문을 엽니다.
- Gas 후원. paymasters는 수수료를 보내는 쪽에서 떼어낼 수 있음을 뜻하며, 시작 단계의 가장 심한 마찰을 다듬습니다.
- 묶음 처리. 여러 단계가 하나의 작업으로 정산될 수 있어, 클릭 수도 도중 실패 위험도 줄입니다.
단일 키 EOA와 프로그래밍 가능한 smart account 사이의 실질적 차이는 따로 다룰 만큼 큽니다 — EOA 대 smart account: 정말 중요한 차이를 보세요.
SSP는 어디에 들어맞는가
SSP는 2-of-2 multisig를 중심으로 만들어진 자기수탁 지갑입니다. 키 하나는 SSP Wallet 브라우저 확장에 있고, 두 번째는 SSP Key 모바일 앱에 있습니다. 모든 트랜잭션은 확장에서 구성되고 휴대폰에서 공동 서명되므로, 어느 기기도 혼자서는 자금을 움직일 수 없습니다.
EVM 체인에서 SSP는 그 2-of-2를 ERC-4337을 사용해 구현합니다. 지갑은 검증 로직이 두 키 모두를 요구하는 ERC-4337 smart account이며, 두 부분 서명은 — secp256k1 위에서 MuSig2 방식으로 — 컨트랙트가 온체인에서 검증하는 단 하나의 Schnorr 집계 서명으로 결합됩니다. SSP의 smart contracts는 2025년 Halborn의 감사를 받았습니다. 전체 설계는 SSP 계정 추상화 아키텍처의 주제입니다.
다시 말해, 위에서 설명한 추상적 능력 — 자신의 다중 서명 규칙을 강제하는 계정 — 이 바로 SSP가 Ethereum, Polygon, Base 및 그 밖의 지원되는 EVM 체인에서 동작하는 지갑으로 빚어내는 것입니다.
이 시리즈의 나머지
이 글은 문제와 핵심 발상을 세웠습니다. 시리즈는 여기서부터 쌓아 올립니다.
- 제1원리에서 출발하는 계정 추상화 — 이 글: 왜 EOA가 제약적인지, 그리고 계정 추상화가 무엇을 뜻하는지.
- EOA 대 smart account: 정말 중요한 차이 — 두 계정 모델의 직접 비교.
- SSP 계정 추상화 아키텍처 — SSP가 ERC-4337을 2-of-2 지갑에 어떻게 배선하는지.
- Gas 후원과 paymasters 해설 — paymasters가 "누가 내는가"를 "누가 보내는가"에서 어떻게 떼어내는지.
- Ethereum이 아닌 체인에서의 계정 추상화 — 같은 발상이 Ethereum 너머로 어떻게 퍼지는지.
표준만 따로 알고 싶다면 ERC-4337 해설에서 시작한 뒤, 더 큰 그림을 위해 여기로 돌아오세요. 그 지점부터 계정은 제약이기를 멈추고, 당신이 그 둘레로 프로그래밍할 수 있는 무언가가 되기 시작합니다.
