SSP의 계정 추상화 아키텍처 들여다보기
SSP는 2-of-2 multisig을 중심으로 구축된 자가 수탁 지갑입니다. 첫 번째 키는 SSP Wallet 브라우저 확장에, 두 번째 키는 SSP Key 모바일 앱에 보관되며, 두 기기가 모두 승인하지 않는 한 어떤 거래도 확정되지 않습니다. EVM 체인에서 SSP는 이 보장을 ERC-4337 account abstraction으로 실현합니다. 지갑은 smart account이며, 그 검증 로직은 두 키로부터 구성된 단일 Schnorr 집계 서명을 받아들입니다. 이 글은 그 아키텍처를 처음부터 끝까지 따라갑니다 — 각 구성 요소, 정확한 서명 흐름, 그리고 그것이 만들어 내는 보안 속성을.
account abstraction이 처음이라면 먼저 제1원리에서 본 계정 추상화와 표준 자체에 집중한 ERC-4337 해설부터 보세요. 여기서는 smart account와 UserOperation이 대략 무엇인지 안다고 전제하고, SSP가 그것들을 어떻게 엮어 내는지에 집중합니다.
SSP가 의지하는 부품들
흐름을 따라가기 전에, 구성 요소와 각자가 하는 일을 짚어 두면 도움이 됩니다:
- smart account. EVM 체인에서 당신의 SSP 지갑은 단일 키로 통제되는 EOA가 아닙니다. 그것은 ERC-4337 smart account — 당신의 자금을 보관하고 자체 검증 로직을 담은 계약입니다. 이 로직이 설계의 핵심입니다. 제공된 서명이 지갑이 기대하는 집계 키와 일치할 때만 거래를 받아들입니다.
- 두 기기. 키 1은 SSP Wallet 브라우저 확장에 보관됩니다. 키 2는 SSP Key 모바일 앱에 보관됩니다. 각 기기는 하나의 분할 조각을 보관하고 하나의 부분 서명을 생성합니다. 어떤 조각도 혼자서는 아무것도 승인할 수 없습니다.
UserOperation. 확장은 일반 거래 대신 당신의 의도를UserOperation으로 표현합니다 — account가 무엇을 해야 하는지, 그리고 그것을 승인하는 서명을 기술한 구조화된 객체입니다.- bundler. bundler는 전용 mempool에서
UserOperation을 꺼내, 실제 온체인 거래로 묶고, 이를 제출하기 위해 베이스 레이어의 gas를 지불합니다. - EntryPoint. 감사를 거친 단일 EntryPoint 계약이 모든 ERC-4337 작업의 온체인 진입점입니다. 그것은 당신의 smart account를 호출해 그 account 자체의 검증 로직을 실행하고, 검증이 통과하면 실행을 촉발합니다.
paymaster는 선택적으로 UserOperation의 gas를 대신 부담할 수 있습니다. 그것은 그 자체로 하나의 주제이며 Gas 후원과 paymaster 해설에서 다룹니다.
정확한 서명 흐름
EVM 체인에서 SSP로 거래를 보낼 때 단계별로 일어나는 일은 다음과 같습니다:
SSP Wallet extension (key 1) SSP Key mobile app (key 2)
| |
| 1. initiate tx |
| 2. build UserOperation |
| 3. partial Schnorr sig --- push -->| 4. approve
| | 5. partial Schnorr sig
| |
| 6. aggregate (MuSig2 / secp256k1)
| v
| ONE Schnorr signature
| |
v v
7. UserOperation --> 8. bundler --> 9. EntryPoint --> smart account
|
validate aggregate sig
|
valid? --> execute call
산문으로 읽으면:
- 키 1을 보관한 SSP Wallet 브라우저 확장에서 거래를 개시합니다.
- 확장은 그 동작을 기술하는 ERC-4337
UserOperation을 구성합니다. - 키 1이 그 작업에 대해 부분 Schnorr 서명을 생성합니다.
- 요청은 승인을 위해 SSP Key 모바일 앱으로 푸시됩니다(키 2).
- 키 2가 자신의 부분 서명을 생성합니다.
- 두 부분 서명은 secp256k1 위에서 MuSig2 방식으로, 하나의 Schnorr 서명으로 집계됩니다.
- 이제 그 단일 집계 서명을 지닌
UserOperation은 전송할 준비가 됩니다. - 그것은 bundler로 가고, bundler는 그것을 거래로 묶어 gas를 지불합니다.
- bundler는 그것을 EntryPoint 계약에 제출하고, 계약은 SSP의 smart account를 호출합니다. account는 그 단일 집계 서명을 지갑이 기대하는 집계 키에 대해 검증하고, 유효하면 호출을 실행합니다.
6단계에 도달하려면 두 기기가 모두 필요하며, 바로 이것이 이를 진정한 2-of-2로 만듭니다. 부분 서명 중 어느 하나를 빼면, 집계는 계약이 받아들일 서명을 만들어 낼 수 없습니다.
왜 체인에는 서명이 하나만 보이는가
SSP의 설계를 우아하게 만드는 세부 사항은 6단계의 집계입니다. 확장과 휴대폰은 작업에 각자 별도의 서명을 붙이지 않습니다. 그들의 두 부분 Schnorr 서명은 — MuSig2 방식으로, Ethereum이 이미 쓰는 동일한 secp256k1 곡선 위에서 — 하나의 Schnorr 서명으로 결합됩니다. smart account는 그 하나의 서명을 기대되는 하나의 집계 키에 대해 확인합니다.
여기에는 머물러 볼 만한 두 가지 결과가 있습니다:
- 온체인 흔적이 작게 유지됩니다.
UserOperation은 둘이 아니라 하나의 서명을 운반합니다. 저장하거나 순회할 서명자 목록도 없고, 서명자별 검증 루프도 없습니다. 계약은 단일 서명자에 대해 할 검증 작업과 동일한 양을 수행합니다. - 체인은 그것이 multisig임을 알아챌 수 없습니다. EntryPoint에 도달하는 것은 평범한 서명된 작업처럼 보입니다. 2-of-2 강제는 서명이 — 두 기기에 걸쳐 — 어떻게 생성되었는지에 있는 것이지, 체인 위에 보이는 어떤 다자 구조에 있는 것이 아닙니다. 외부 관찰자에게 그 지갑은 다른 여느 smart account와 똑같이 행동합니다.
이것이 SSP의 방식과, N개의 별도 서명을 게시하고 각각을 검증하는 순진한 multisig 사이의 차이입니다. EVM 위에서 이런 방식으로 multisig을 하는 메커니즘은 계정 추상화 방식의 EVM 멀티시그에서 더 깊이 다룹니다.
각 기기가 실제로 보호하는 것
보안 속성에 대해서는 정확히 짚을 가치가 있습니다. 그것이 이 아키텍처의 전부이기 때문입니다.
- 어떤 키도 혼자서는 자금을 옮길 수 없습니다. 확장의 키 1은
UserOperation을 구성하고 자기 절반을 서명할 수 있지만, 절반의 서명은 계약이 받아들이지 않을 무언가로 집계됩니다. 휴대폰의 키 2는 승인하고 자기 절반을 서명할 수 있지만, 혼자서 송금을 시작하거나 완료할 수 없습니다. - 한 기기를 침해하는 것으로는 충분하지 않습니다. 당신의 브라우저 확장을 완전히 장악한 공격자라도 여전히 지출할 수 없습니다. 휴대폰 없이는 키 2의 부분 서명을 만들어 낼 수 없기 때문입니다. 그 반대도 성립합니다. 단일 키 EOA가 견디지 못하는 위협 모델 — 키 하나의 유출, 전액 손실 — 은 여기에는 적용되지 않습니다.
- 승인은 명시적이며 두 번째 화면에서 이루어집니다. 4단계가 요청을 SSP Key 앱으로 푸시하므로, 작업이 집계되어 전송될 수 있기 전에 당신은 물리적으로 분리된 기기에서 그것을 보고 승인합니다.
이는 2-of-2 multisig이란?에서 설명한 것과 동일한 2-of-2 속성이며, 네이티브 multisig 옵코드가 아니라 계정 추상화를 통해 EVM 체인 위에서 실현됩니다.
이점 요약
실들을 한데 모으면, 이 아키텍처는 SSP 사용자에게 달리 얻기 어려운 특정 조합을 제공합니다:
- 지원되는 모든 EVM 체인에서의 multisig 보안. 동일한 2-of-2 설계가 Ethereum, Polygon, Base, BNB Smart Chain, Avalanche 위에서 동작합니다. ERC-4337이 체인 고유 기능이 아니라 계약 수준의 표준이기 때문입니다.
- 작은 온체인 흔적. 단일 집계 서명은 smart account가 단일 서명자처럼 검증함을 의미하며, 검증을 가볍게 유지합니다.
- 단일 서명자 같은 UX. 당신 쪽에서는 위원회를 꾸리는 것이 아니라 두 기기에서 거래를 승인하는 것처럼 느껴집니다. 관리할 공동 서명자 주소도, 송금마다 설정할 별도의 multisig 계약도 없습니다.
- 프로토콜 변경이 필요 없습니다. 모든 것이 ERC-4337 위에서 굴러가므로, SSP는 베이스 레이어 계정 추상화가 출시되기를 기다리지 않고도 이 모든 것을 얻습니다.
감사에 관한 한마디
보안 아키텍처는 그 검토만큼만 신뢰할 수 있습니다. SSP의 smart contracts는 2025년에 Halborn의 감사를 받았습니다. 외부 감사가 어떤 시스템도 완벽하게 만들지는 않지만, 위에서 설명한 2-of-2 규칙을 강제하는 계약 로직에 대해 의미 있는 신뢰 신호입니다.
다음으로 갈 곳
이 글은 SSP의 계정 추상화를 처음부터 끝까지 따라갔습니다. 주변 표준과 개념을 더 깊이 파고들려면:
- 제1원리에서 본 계정 추상화 — 왜 EOA가 제약적인지, 그리고 계정 추상화가 무엇을 의미하는지.
- 계정 추상화(ERC-4337)란? —
UserOperation, bundler, EntryPoint의 역할을 포함해 표준을 단독으로 본 것. - Gas 후원과 paymaster 해설 —
paymaster가UserOperation의 gas를 어떻게 대신 부담할 수 있는지. - 계정 추상화 방식의 EVM 멀티시그 — EVM 위 multisig 메커니즘을 더 자세히.
정식 명세는 EIP-4337을 참고하세요. 더 넓은 노력에 관해서는 Ethereum의 계정 추상화 로드맵이 어디로 향하는지 추적합니다. 핵심은 이렇습니다. SSP는 프로그래밍 가능한 account라는 추상적 약속을 구체적인 2-of-2 지갑으로 바꿔 냅니다. 거기서 두 기기는 하나의 서명을 생성하고, 체인은 그저 유효한 작업 하나를 볼 뿐입니다.
