multisig가 무엇인가부터 이 시리즈를 따라왔다면 프로토콜을 알 것이다: 돈이 움직이기 전에 둘 이상의 프라이빗 키가 서명해야 한다. 너는 m-of-n 선택기, BIP48 배선, Schnorr 집계 지평선, 소셜 복구 비교를 보았다. 그 모든 것이 기계다. 이 글은 경험에 관한 것이다.
Multisig에 대한 정직한 역사적 비판은 사용하기 적대적이었다는 것이다. 여러 지갑, 수동 PSBT 셔플, 코디네이터 소프트웨어, 서명 파티 — 프로토콜은 견고했지만 UX는 처벌이었다. Single-signer multisig는 이를 고치는 제품 아이디어다: 체인 위에서 완전한 multisig 지출 규칙을 사용하지만, 그것을 사용하는 사람에게는 — 버튼 하나가 있는 하나의 지갑처럼 느껴지는 지갑. SSP는 이 아이디어를 중심으로 만들어졌다.
TL;DR
- "Single-signer"는 한 키를 의미하지 않는다. 프로토콜은 여전히
m개의n키를 가지지만, 서명 UX가 단일 흐름으로 압축된다는 의미다. 사용자는 한 곳에서 서명하고; 지갑이 기기 간 조정을 처리한다. - SSP의 구체적 형태: 하나의 브라우저 확장, 하나의 모바일 앱(SSP Key), 하나의 지갑 정체성. Send를 클릭하고, 폰에서 확인하면, 트랜잭션이 방송된다. 두 서명이 일어나고; 너는 하나를 경험한다.
- 승리는 임계값의 이익(도난 저항, 단일 장애점 없음)이 보존되면서 조정 비용이 거의 single-sig UX 수준으로 떨어진다는 것이다.
- 비용은 이것이 두 기기가 모두 도달 가능한 한에서만 작동한다는 것이다. UX가 다중성을 노출해야 하는 순간 — 복구, 기기 교체, 제3자에서의 복원 — 추상화는 깨진다. 의도된 대로.
- 이 패턴은 리테일 규모의 솔로 self-custody에 대한 "타협 없음" 답에 가장 가까운 것이다. 그것은 SSP의 베팅이며 점점 더 모든 현대 multisig 제품(Coinbase Wallet, Phantom의 진화하는 custody 이야기, Ethereum에서 Safe의 smart-account 흐름)의 베팅이다.
Single-signer 이상: 사용자가 정말로 원하는 것
만약 너가 self-custody 사용자에게 무엇을 원하는지 묻는다면, 모순되는 답을 얻는다:
- "코인이 안전했으면 좋겠다." — Multisig, 하드웨어, 이중화를 함의한다.
- "5초 안에 트랜잭션에 서명하고 싶다." — 단일 기기, 한 번 탭을 함의한다.
- "무언가를 잃으면 복구하고 싶다." — Seed 백업, 이중화를 함의한다.
- "다시는 seed를 적고 싶지 않다." — 플랫폼 관리 키 custody를 함의한다.
- "싸야 한다." — 최소한의 온체인 발자국을 함의한다.
이러한 목표들은 모두 일직선으로 정렬되지 않는다. Self-custody 지갑 디자인의 역사는 어떤 목표를 존중하고 어떤 목표를 정중히 거절할지의 역사다. 하드웨어 지갑은 UX 비용으로 안전과 복구를 존중한다. 스마트 컨트랙트 지갑은 cross-chain 도달의 비용으로 UX와 복구를 존중한다. 순수 hot wallet은 안전성 비용으로 UX와 저렴함을 존중한다.
Single-signer multisig는 프로토콜 의미론을 인터페이스 의미론에서 분리함으로써 다섯 가지 모두를 — 부분적으로 — 존중하려는 시도다. 지갑은 여전히 체인 위에서 완전한 multisig 춤을 춘다; 사용자는 단지 트랜잭션당 한 번 이상 그 춤에 참여하지 않아도 된다.
SSP가 그것을 어떻게 전달하는가
SSP의 구체적 구현, 간단한 한국어로:
- 셋업에서, 너는 브라우저 확장과 모바일 앱(SSP Key)을 설치한다. 각각 자신의 seed를 생성하고, 너는 그것을 별도로 백업한다(이것이 첫 1000 체크리스트 단계다). 두 기기는 공개 키를 교환하고; 그 시점부터 그들은 프로토콜 수준에서 지갑 정체성을 공유한다.
- 일상 서명에서, 너는 브라우저 확장에서 Send를 클릭하고, 트랜잭션을 검토하고, 승인한다. 확장은 부분 서명된 트랜잭션을 구성하고 너의 폰으로 알림을 푸시한다. 모바일 앱은 트랜잭션 세부사항을 보여주고, 너는 승인을 탭하고, 앱은 두 번째 서명을 생성한다. 확장은 두 서명을 결합하고 방송한다. 총 경과 시간: 두 기기가 너 앞에 있을 때 약 8초.
- 수신 시간에, 표시되는 주소는 두 xpubs로부터 BIP48-파생된 multisig 주소다. 너는 그것을 스캔하거나 복사하고; 송신자는 특별한 것을 보지 않는다. 그들의 측에서는 다른 어떤 암호 주소와도 같이 보인다.
- 정산에서, 지갑은 잔액, 이력, 수수료 등을 single-sig 지갑과 동일하게 보여준다. 별도의 "multisig 화면"이 없다. 프로토콜 형태는 정상 사용 중 보이지 않는다.
핵심 디자인 선택은 사용자가 결코 생각해야 하는 유일한 다중성은 두 번째 서명이라는 것이다. 셋업은 두 기기이고, 서명은 한 번 추가 탭이며, 그것이 사용자 관점에서 multisig 프로토콜의 전체 표면이다.
작지만 중요한 디테일: SSP 브라우저 확장과 SSP Key는 같은 위치에 있지 않다. 그들은 다른 OS, 다른 하드웨어, 다른 공격 표면에 있다. 이것이 두 서명 셋업을 단순한 UX 과속방지턱이 아니라 실제 도난 장벽으로 만드는 것이다. (우리는 일곱 가지 실패 모드 글과 2-of-2 multisig가 무엇인가에서 이를 풀어낸다.)
사용자가 결코 보지 않는 것
사용자가 multisig 배관을 절대 다룰 필요 없도록 유지하는 데 많은 작업이 들어간다. 구체적으로:
- **PSBT (Partially Signed Bitcoin Transactions)**는 공동 서명 기기 사이를 이동하는 두꺼운 데이터 구조다. 전통적인 multisig 셋업에서 너는 이것을 수동으로 복사 붙여넣기 한다. SSP는 자체 조정 채널을 통해 직렬화하고 전송한다; 사용자는 알림을 보지, base64 문자열이 아니다.
- Cosigner xpub 교환은 일회성 셋업 이벤트다. 전통 multisig에서 너는 각 cosigner로부터 xpubs를 명시적으로 가져온다. SSP는 셋업의 페어링 흐름에 이것을 감싼다; 너는 QR 코드나 6자리 코드를 확인하고 기저 자료를 절대 만지지 않는다.
- 수수료 추정, 거스름돈 처리, 주소 회전은 지갑이 single-sig 지갑이 하는 것과 정확히 같은 방식으로 처리한다, 지갑 자체가 후드 아래에서는 multisig임에도 불구하고.
- Redeem script — multisig 규칙을 설명하는 BIP48-정규 스크립트 — 는 지갑에 의해 자동으로 구성된다. 사용자는 그것을 보지 않고, 라인별로 승인하지 않으며, 그것이 존재하는지 알 필요가 없다. (그들이 보고 싶다면 block explorer에서 볼 수 있다, 이는 multisig 지갑의 가장 깨끗한 "네 일을 보여줘" 속성이다.)
모든 그 추상화는 필요한 작업이지만, 또한 위험이다 — 프로토콜이 사용자로부터 숨겨질 때마다 지갑은 숨겨진 부분을 올바로 하는 책임을 떠맡는다. SSP의 감사 작업(Halborn)은 대체로 정확히 이 보이지 않는 코드 경로에 관한 것이다.
Single-signer로 느껴지지 않게 될 때
추상화는 완벽하지 않고, 그것이 어디서 깨지는지 아는 것이 중요하다. Single-signer UX는 두 기기가 모두 사용 가능한 한 유지된다. 균열은 하나가 그렇지 않을 때 나타난다:
- 기기 교체. 폰을 교체할 때, 새 기기를 다시 페어링해야 한다. 그것은 일회성 multisig 조정 단계이며 실제로 보이는 — 지갑은 두 기기가 서로를 다시 보이도록 너를 안내한다.
- Seed 복구. 기기가 파괴되면, 너는 그것을 seed phrase로부터 새 기기에 복구한 다음 다시 페어링한다. 너가 두 개의 seed(기기당 하나)를 가지고 있다는 사실이 이 순간에 정상 사용 중에 없었던 방식으로 보이게 된다.
- Cross-software 복구. 만약 너가 언젠가 두 SSP seed를 제3자 multisig 지갑(Sparrow, Electrum 등)에 로드하면, 모든 multisig 배관이 보이게 된다 — 그것은 버그가 아니라 기능이다. 왜냐하면 너의 지갑이 상호운용 가능함을 증명하기 때문이다, 그러나 SSP UX는 아니다.
- 한 기기가 오프라인일 때 지출. 지갑은 두 기기 없이 공동 서명할 수 없다; 그것은 프로토콜이다. 너는 다른 기기가 온라인에 올 때까지 "두 번째 서명 대기 중" 상태를 볼 것이다.
처음 세 가지는 평균 UX를 실제로 저하시키지 않을 정도로 충분히 드물다. 네 번째가 가장 흔한 마찰 지점이며 — 올바른 마찰 지점이다. 만약 지갑이 두 번째 기기 없이 지출하도록 허용한다면, 그것은 더 이상 2-of-2 지갑이 아니다. 그 마찰이 보안이다; 너가 지불하고 있던 속성을 제거하지 않고서는 그것을 공학적으로 없앨 수 없다.
Single-signer UX를 둘러싼 디자인
SSP — 그리고 다른 현대 multisig 제품들 — 이 이 추상화를 단단히 유지하기 위해 따르는 세 가지 디자인 원칙:
- 두 cosigner는 다른 위협 표면에 살아야 한다. 두 cosign 키를 같은 OS에 두는 지갑은 실제로 보안 이익을 제공하지 않는다; 그것은 단지 단일 공격 표면을 두 잠금 장치에 펼친다. SSP의 브라우저 확장과 모바일 앱 간 분할은 이를 자연스럽게 강제한다.
- 조정 채널은 위조할 수 없어야 한다. 브라우저 확장이 모바일 앱에 보내는 PSBT는 올바른 지갑과 올바른 트랜잭션에 암호학적으로 묶여 있어야 한다; 그렇지 않으면 추상화가 그 자체로 공격 표면이 된다. SSP는 프로토콜 계층에서 이 자료에 서명하고 검증한다.
- 사용자 계약은 숨겨진 것에 대해 정직해야 한다. "완전히 신뢰 없는 single-signer 경험"이라고 말하지만 복구에서 무엇이 일어나는지 설명하지 않는 지갑은 사용자를 불쾌한 놀라움에 빠지게 준비시킨다. SSP의 온보딩은 명시적으로 두 seed, 두 백업, 두 복구 시나리오를 모두 걷는다 — 추상화는 사용 중에는 숨겨지지만 온보딩 중에는 노출되어 나중에 너를 매복하지 않도록 한다.
Ethereum의 account abstraction 지갑은 네 번째 도구를 얻는다: 스마트 컨트랙트 레이어. ERC-4337을 사용하면 지갑은 가스 수수료를 흡수하고, 트랜잭션을 배치하며, 더욱 "single-signer 같은" UX를 제시할 수 있고 동시에 후드 아래에서 multisig를 구현할 수 있다. SSP는 Bitcoin에서 그 레이어가 없다(스마트 컨트랙트 없음), 그래서 추상화는 체인-측 흡수보다 UX 엔지니어링에 더 의존한다. 두 경로 모두 유효하다; Ethereum 경로는 체인 특정의 비용으로 더 유연하고, SSP 경로는 더 많은 UI 작업 비용으로 더 휴대성이 좋다.
이것이 너에게 의미하는 것
세 가지 결론:
- "하나의 지갑처럼 느낌"의 경험이 헤드라인 기능이지, multisig 자체가 아니다. 만약 너의 친구가 "SSP는 multisig 지갑이야?"라고 묻는다면, 기술적으로 참인 답은 예이지만, 유용한 답은 "폰에서 한 번 탭으로 지출을 확인하는 2기기 지갑"이다. 그것이 사람들이 실제로 느끼는 것을 포착한다.
- 너가 보는 마찰은 실제 작업을 하고 있다. SSP가 너에게 폰에서 확인하라고 요청할 때마다 그것은 손상된 노트북이 너의 자금을 비우는 것을 막는 프로토콜을 강제하고 있다. 그 마찰이 너가 처음에 hot wallet 대신 2-of-2 지갑을 사용하는 주된 이유다.
- 추상화를 마법이 아니라 계약으로 다루어라. 이 시리즈의 마지막 글, Multisig 실패 모드와 SSP가 어떻게 완화하는가는 추상화의 각 조각이 깨질 때 무엇이 일어나는지를 걷는다 — 기기 상실, 키 손상, 서명 서버 중단. 한 번 읽어라. 추상화는 잘 설계되었지만, 실패 모드를 이해하는 것이 이 전체 시리즈가 향하는 종류의 self-custody 사용자로 너를 만드는 것이다.
