Multisig 실패 모드와 SSP가 어떻게 완화하는가

이것은 Multisig Deep Dive의 마무리 글이다. 이전 여섯 편을 통해 그림을 만들어왔다: multisig가 무엇인지, 어떤 임계값을 고를지, BIP48 배선, Schnorr 집계, 소셜 복구 비교, 그리고 실제 사람들을 위해 모든 것을 묶어주는 single-signer UX. 추상화는 정상 조건에서 잘 작동한다. 이 글은 비정상 조건에 관한 것이다.

모든 multisig 지갑은 예측 가능한 실패 모드를 가진다 — 편안한 single-signer 추상화가 깨지고 그 아래의 프로토콜이 보이는 지점들. 어떤 실패가 어떤 복구로 매핑되는지 아는 것이 스트레스 가득한 사건과 일상적인 사건의 차이다. 우리는 가장 가능성이 높은 순서로 다섯 가지를 살펴보고, 각 경우에 SSP가 실제로 무엇을 하는지(그리고 당신이 무엇을 해야 하는지)를 다룬다.

TL;DR

• 모드 1: 한 기기 분실, 그 기기의 seed 무사. 사소한 복구 — 대체 기기에 SSP 설치, seed로 복원, 재페어. 자금 위험 없음.
• 모드 2: 한 기기 분실 그리고 그 seed도 분실. 지갑은 손상되었지만 잃지는 않았다: 남은 기기에서 두 번째 seed를 유일한 복구 키로 사용해 지출하고, 자금을 새로 페어링된 지갑으로 옮겨라.
• 모드 3: 한 기기가 malware/phishing에 의해 손상. 공격자가 두 서명 중 하나만 가지고 있어서 자금은 안전. 깨끗한 기기와 재페어링해 침해를 차단; SSP는 단일 손상 기기에서 비울 수 없다.
• 모드 4: SSP의 조정 레이어가 가용 불가능. 불편하지만 재앙은 아니다. 조정은 메타데이터 운반; 기저의 multisig 지갑은 두 seed만으로 BIP48 호환 소프트웨어로 복구 가능하다.
• 모드 5: 두 기기와 두 장의 seed 종이가 동시에 파괴. 이것이 유일한 재앙 실패 모드이며, 또한 너의 self-custody 체크리스트가 지리적으로 불가능에 가깝게 만들도록 설계된 것이다.

이 글은 한 번 읽으면 충분하다. 외울 필요 없다. 요점은 당신의 미래의 자아가 걱정할 수 있는 모든 실패에 대해 구체적이고 실행 가능한 응답이 있다는 것이다.

모드 1: 단일 기기 분실, seed 무사

이것이 가장 흔한 실패다: 폰을 바꾸거나, 노트북을 떨어뜨리거나, OS를 깨끗이 다시 설치한다. 너의 SSP 지갑의 한 절반을 운영하던 기기는 사라졌지만, 그 절반의 seed phrase는 여전히 제자리에 있다(첫 1000 체크리스트를 따랐고 물리적으로 분리해서 보관했기 때문에).

복구는:

1. 대체 기기(새 폰, 새 노트북 등)에 SSP를 설치하라.
2. 그 절반을 seed phrase로부터 복원하라.
3. 살아남은 기기와 재페어링하라. SSP는 두 기기를 다시 서로에게 보여주는 과정을 안내한다 — multisig 조정 레이어가 새 기기에서 같은 xpub을 감지하고 받아들인다.
4. 지갑을 평소처럼 계속 사용하라. 지갑의 온체인 정체성은 변하지 않았다 — 같은 주소, 같은 잔액, 같은 이력.

이 흐름 동안 자금은 어떤 시점에도 위험에 처하지 않는다. seed phrase는 정확히 이를 위해 만들어졌다: 하나의 서명 절반을 처음부터 재구성하기. SSP의 온보딩이 두 seed를 별도로 백업하는 것에 대해 그렇게 끈질긴 이유는 이것이 당신이 돈을 내고 있는 복구이기 때문이다.

시간 비용: seed 종이가 손에 있다면 약 20분.

모드 2: 기기 그리고 그 seed 분실

모드 1의 더 힘든 버전: 기기 그리고 그 seed 종이를 동시에 잃었다. 집 화재, 홍수, 단일 물리적 위치 도난 등. 이제 그 서명 절반을 자기 seed로부터 재구성할 수 없다.

이것이 정확히 2-of-2 대 2-of-3 결정이 결과를 보여주는 경우다. 2-of-2 아래에서 — SSP의 기본값 — 정확히 한 서명 절반(살아남은 기기와 그 seed)만 남는다. 2-of-3 아래라면 셋 중 둘의 키를 가지고 있고 서두름 없이 지출할 수 있겠지만; 2-of-2 아래에서는 이 지갑에서 전혀 지출할 수 없다, 체인이 여전히 두 원본 서명을 요구하기 때문이다.

복구는:

1. 당황하지 마라. 자금은 안전하다 — 어떤 공격자도 그것을 지출할 수 없다. 그것들이 2-of-2 규칙 아래에 있기 때문이다.
2. 살아남은 기기의 seed가 여전히 백업되고 접근 가능한지 확인하라. 그것이 갑자기 너의 유일한 안전망이다.
3. 신선한 기기 쌍에 새로운 SSP 지갑을 설정하라(남은 기기와 새 기기, 각각 새 seed로).
4. 오래된 지갑에서 자금을 보내라 — 잠깐, 당신은 할 수 없다. 2-of-2가 깨졌다.

음. 4단계는 2-of-2에 대한 정직한 진실을 드러낸다: 이 특정 실패 모드에서 자금은 얼어붙는다. 도난당하지 않았다. 암호학적 의미에서 잃지 않았다. 여전히 온체인 주소에 있다. 하지만 당신은 그것을 옮길 수 없다, 지갑이 2-of-2 지출 규칙을 강제하고 당신이 한 절반만 가지고 있기 때문이다.

당신이 할 수 있는 것은 지갑을 다시 만드는 것이다. 구체적으로: 살아남은 기기는 여전히 그 seed를 가지고 있고, 당신은 새로운 기기를 새로운 seed로 설정하고, 그것들을 새로운 2-of-2 지갑으로 페어링하고, 오래된 지갑에서 새 것으로 지출한다 — 그리고 이것이 핵심 — 살아남은 원본 seed와 잃어버린 것을 다른 곳에서 복구해서 결합함으로써. 잃어버린 seed의 다른 복사본이 없다면, 자금은 진정으로 좌초된다.

이것이 체크리스트의 "두 seed, 물리적으로 분리된 두 위치, 그중 하나는 내화" 지시가 편집증이 아닌 이유다. 그것이 모드 2의 답이다. 만약 하나의 self-custody 조언만 따른다면, 두 SSP seed 모두에 대해 seed phrase 모범 사례를 따르라. 지갑의 나머지는 당신이 그것을 했다는 가정 주위에서 잘 설계되었다.

모드 3: 한 기기가 손상

더 어두운 시나리오를 상상해보라: 너의 노트북이 malware에 의해 손상되었다. 브라우저 확장은 여전히 설치되어 있다; 공격자가 잠재적으로 당신의 사용을 관찰했고, 그 기기의 서명 키에 완전한 접근권을 가질 수 있다. 그들이 무엇을 얻는가?

단일 서명 hot wallet 아래에서 — 그들은 모든 것을 얻는다. 다음에 지출을 시도할 때(또는 더 일찍, malware가 조용히 지출을 시작할 수 있다면) 지갑이 비워진다.

2-of-2 SSP 지갑 아래에서, 그들은 아직 아무것도 얻지 못한다. 그들은 한 서명을 가지고 있다; 체인은 둘을 요구한다. 그들은 혼자서 지출할 수 없다. 그들이 할 수 있는 최대는 거래 제안을 조작하고, SSP의 조정 레이어를 통해 당신의 폰으로 푸시하고, 당신이 알아차리지 않고 폰에서 승인하기를 바라는 것이다.

여기가 single-signer UX 논의가 보안과 교차하는 지점이다. 폰의 확인 단계는 UX의 멋진 디테일이 아니다; 그것이 손상된 노트북과 비워진 지갑 사이에 서 있는 유일한 것이다. 폰에서 거래 세부 정보를 읽어라. 수신자 주소를 맞춰라. 금액을 맞춰라. 무언가가 잘못 보이면, 프롬프트가 어떻게 거기에 왔는지에 관계없이 승인하지 마라.

손상을 발견했을 때의 봉쇄 응답:

1. 너의 손상되지 않은 기기에서, 자금을 완전히 새로운 SSP 지갑(두 새 기기, 두 새 seed로 설정된)에 보내라. 이것은 단일 multisig 거래다 — 두 옛 기기 모두 한 번 서명해야 하지만, 즉시 손상된 것을 사용하는 것을 중단한다.
2. 손상된 기기를 지워라. 공장 초기화; 단지 확장을 제거하는 것이 아니다.
3. 손상된 seed를 태워진 것으로 취급하라. 그 특정 seed를 절대 다시 가져오지 마라; 유출된 것으로 간주하라.

이 봉쇄는 공격자를 능가해야 하는 단일 서명 지갑에 대한 동등한 것보다 훨씬 빠르고 위험이 낮다. multisig로는, 공격자가 두 번째 서명 없이 잠겨 있기 때문에 침착하게 행동할 시간이 있다. 이전 시리즈의 일곱 실패 모드 글은 이를 달러로 표현한다: 리테일 self-custody 손실의 대부분은 단일 키 손상이며, 2-of-2가 가장 흔한 시나리오에 대한 답이다.

모드 4: SSP의 조정 레이어가 가용 불가능

만약 SSP, 회사에 장애가 생기면 어떻게 되는가? 또는 너의 브라우저 확장과 폰 사이에서 PSBT를 운반하는 조정 서비스가 다운되면? 또는 당신이 SSP를 더 이상 전혀 사용하고 싶지 않다고 결정했다면?

정직한 답은 조정 레이어가 메타데이터 운반 — 편리하지만 부하를 견디지 않는 — 이라는 것이다. 실제 지갑은 온체인에 살고, 너의 두 BIP48 seed로부터 파생된다. SSP의 서명 서버가 한 시간 다운되면, 한 시간 기다릴 수 있다. 일주일 다운되면, 짜증난다. 영원히 다운되면, 두 seed를 다른 BIP48 호환 지갑에 로드해 여전히 지갑을 복구할 수 있다 — Bitcoin의 Sparrow, Electrum, Bitcoin Core descriptor 지갑, EVM 체인의 동등한 multisig 클라이언트 등.

여기서 복구 경로는:

1. 문제가 SSP 측(너의 로컬 기기가 아닌)에 있다는 것을 확인하라 — SSP의 상태 페이지나 커뮤니티 채널이 말해줄 것이다.
2. 긴급히 지출해야 한다면, BIP48 multisig 경로를 지원하는 제3자 지갑을 설치하라. Sparrow가 Bitcoin에 가장 사용자 친화적인 선택; EVM의 경우 Safe 또는 유사한 multisig 클라이언트를 사용할 것이다.
3. 두 seed를 그 제3자 지갑에 로드하라. 같은 주소가 나타나고, 같은 잔액, 같은 지출 능력.
4. 거기서 정상적으로 서명하고 브로드캐스트하라.

당신이 이것을 할 수 있는 이유 — 이것이 마케팅 주장이 아니라 검증 가능한 속성인 이유 — 는 SSP가 표준을 사용하기 때문이다. BIP48 글과 2-of-2 multisig가 무엇인가가 이것을 살펴본다. SSP는 SSP와 독립적으로 존재하는 지갑 위의 편리한 프런트엔드다.

실제로, SSP의 서명 인프라는 높은 가용성을 위해 구축되었다 — 하지만 지갑이 SSP 없이 복구 가능하다는 보장이 편의를 두려움이 아니라 중요한 것으로 만든다.

모드 5: 두 기기와 두 seed가 동시에 파괴

이것이 재앙 실패 모드이며 분명하게 말할 가치가 있다: 만약 둘 다 서명 절반과 둘 다 seed 백업을 같은 사건에서 잃으면, 지갑은 영구적으로 접근 불가능하다. 자금은 여전히 온체인 multisig 주소에 있지만, 아무도 — SSP를 포함해서 — 그것을 움직일 수 없다. 이것이 진정한 self-custody의 대가다; SSP가 너의 자금을 동결할 수 없다는 같은 속성이 그것을 해동할 수도 없다는 것을 의미한다.

방어는 지리적이고 구조적이다:

• 두 seed는 물리적으로 분리된 위치에 산다. 첫 1000 체크리스��는 "다른 방, 실용적이라면 다른 건물"을 언급한다.
• 적어도 하나의 seed는 내화 용기에 산다.
• 너의 스택이 그것을 정당화할 만큼 크다면, 결국 2-of-3로 이주한다 — 세 번째 키(종종 변호사, 가족 구성원, 또는 은행 안전 예금 상자에 보관)를 추가하면 재앙 실패 표면이 "두 물리적 위치 모두 파괴"에서 "세 위치 중 어느 두 개 파괴"로 줄어든다.

정직한 프레임은 이 실패 모드가 확률을 심각도로 교환한다는 것이다. 단일 키 지갑은 훨씬 더 자주 실패하지만(모드 1과 3이 데이터를 지배) 사건당 심각도는 더 낮다. 지리적 seed 분리가 있는 multisig는 실패 빈도를 한 자릿수 줄이지만 사건당 심각도를 약간 올린다. 대부분의 사용자는 이득을 본다.

Meet SSP Wallet 소개는 제품을 정교한 리테일 self-custody를 위한 도구로 자리매김한다. 모드 5의 심각성은 그 자리매김이 정직한 이유의 일부다 — 제품은 seed 종이를 한 번 쓰고 잊는 것이 아니라 부하를 지탱하는 인프라로 다룰 의향이 있는 사람들을 위해 만들어졌다.

이것이 너에게 의미하는 것

마무리 시사점:

1. 대부분의 실패 모드는 일상적인 복구를 가진다. 모드 1, 3, 4 — 단연 가장 흔한 — 는 잘 정의된, 스트레스 낮은 복구 경로를 가진다. 2-of-2 모델은 진정으로 약속한 것을 한다: 단일 지점 손상을 흡수하고 응답할 시간을 준다.
2. 재앙적 경우는 지리적이지 암호학적이지 않다. 모드 5는 너의 seed phrase 모범 사례가 다루는 것이다. 지갑의 암호학은 잘 감사되었다; 남은 실패 표면은 두 seed를 물리적으로 다른, 내구성 있는 장소에 저장했는지 여부다.
3. 이제 너는 완전한 그림을 가지고 있다. 이 시리즈(글 1, 글 2, 글 3, 글 4, 글 5, 글 6, 이것)는 multisig가 무엇인지, 어떤 임계값을 언제 선택할지, 모든 것이 어떻게 연결되었는지, 집계가 무엇을 바꾸는지, 복구 모델이 어떻게 다른지, UX가 왜 그렇게 느껴지는지, 그리고 각 실패 모드가 운영적으로 어떻게 보이는지를 다뤘다. 이를 선행하는 Self-Custody Fundamentals 시리즈는 너에게 왜를 주었다; 이 시리즈는 너에게 어떻게를 주었다. 여기서부터 일은 운영 규율이다: 백업 위생, 주기적인 복구 리허설, 그리고 발생할 때 모드 1 / 2 / 3 / 4 복구를 침착하게 할 인내심.

지갑은 잘 설계되었다. 남은 변수는 너다.