MPC 지갑과 멀티시그
MPC 지갑도 멀티시그 지갑도 같은 표제를 내겁니다. 단일한 침해 지점은 없다는 것. 둘 다 그 약속을 지킵니다. 다만 거기에 이르는 경로가 다르고, 그 경로는 일이 잘못됐을 때 무슨 일이 벌어지는지를 다르게 만듭니다 — 그리고 그때야말로 보안 모델이 실제로 의미를 갖는 유일한 순간입니다.
이 글은 기술적인 정면 대결입니다. 자기수탁 선택지의 전체 지형을 먼저 보고 싶다면 자기수탁 방식 비교가 하드웨어 지갑과 순수한 시드 문구까지 포함해 전 분야를 다룹니다.
같은 문제에 대한 두 가지 다른 답
문제 서술은 두 경우 모두 같습니다. 모든 것을 통제하는 비밀 하나는 받아들일 수 없으니 권한을 흩뜨리자는 것.
MPC는 키를 쪼갭니다. 개념적으로 개인키는 하나지만, 그것은 어디에서도 조립되지 않습니다. 대신 그 조각들이 서로 다른 곳에 놓이고, 암호 프로토콜이 어떤 당사자도 키 전체를 알지 못한 채 그 조각들이 협력해 서명을 만들어 내도록 합니다.
멀티시그는 여러 개의 키를 요구합니다. 여기에는 정말로 서로 독립적인 여러 개의 개인키가 존재합니다. 주소는 규칙을 — 이 키들 가운데 몇 개가 서명해야 한다는 — 부호화하고, 블록체인이 트랜잭션을 검증할 때 그 규칙을 강제합니다.
이 구분은 학술적으로 들립니다. 그렇지 않습니다. 하나는 암호학에 관한 사실이고, 다른 하나는 블록체인에 관한 사실입니다. 체인이 무엇을 아느냐가, 시스템의 한 조각이 무너졌을 때 무슨 일이 일어나는지를 결정합니다.
MPC는 실제로 어떻게 동작하는가
MPC — 다자간 연산, 이 맥락에서는 대개 임계 서명 방식 — 는 여러 당사자가 각자 서명 키의 한 조각만 쥔 채로 메시지에 대한 서명을 함께 계산하게 해 줍니다. 형식적인 서술을 원한다면 NIST가 임계 암호학 프로젝트를 운영하고 있습니다.
출력은 하나의 평범한 서명입니다. 온체인에서 MPC 지갑의 트랜잭션은 한 사람이 키 하나로 서명한 트랜잭션과 구분되지 않습니다. 여기에는 실질적인 장점이 있습니다. 모든 체인에서 동작하고, 단일 서명 트랜잭션과 비용이 같으며, 체인을 지켜보는 누구에게도 당신의 보안 구성을 조금도 드러내지 않습니다.
바로 그 성질의 결과가 주의를 요하는 지점입니다. 체인이 평범한 서명을 본다는 것은, 체인이 당신의 정책에 대해서도 아무것도 강제하지 않는다는 뜻입니다. 조각이 몇 개 있고 누가 쥐며 몇 개가 협력해야 하는지는 소프트웨어와 서버에 관한 사실이지 원장에 관한 사실이 아닙니다. 소프트웨어를 바꾸면 정책이 바뀝니다.
두 번째로 살펴볼 것은 조각의 보관입니다. 소비자용 MPC 지갑 상당수가 한 조각을 제공자의 인프라에 둡니다. 매끄러운 복구 경험을 가능하게 하는 것이 흔히 바로 그것이며 — 동시에 제공자의 존속과 협조가 당신 구성의 하중을 받치는 부분이라는 뜻이기도 합니다. 어떤 설계는 내보낼 수 있는 조각이나 독립적인 백업 경로로 이를 잘 완화합니다. 물어야 할 것은 MPC를 잘 만들 수 있느냐가 아니라, 당신이 살펴보는 그 특정 제품이 당신이 검증할 수 있는 방식으로 그렇게 했느냐입니다.
멀티시그는 실제로 어떻게 동작하는가
멀티시그에서는 정책이 주소의 일부입니다. Bitcoin과 다른 UTXO 체인에서 주소는 공개키들과 임계값을 적어 놓은 스크립트에서 파생됩니다. 유효한 서명이 충분히 실리지 않은 지출은 그냥 무효이고, 네트워크의 모든 노드가 그것을 거부합니다. 스마트 컨트랙트가 있는 체인에서 그 등가물은, 요구된 승인 없이는 움직이지 않는 코드를 가진 계정입니다.
규칙을 적용해 줄 누군가를 신뢰할 필요가 없습니다. 규칙을 적용하는 일이 곧 네트워크가 하는 일이기 때문입니다. 관련된 지갑 소프트웨어가 내일 전부 사라져도 규칙은 그대로 서 있고, 키와 호환되는 아무 도구나 가진 사람은 여전히 지출할 수 있습니다.
비용도 실재합니다. 키 하나가 아니라 여러 개를 관리하게 되고, 백업은 복잡해지며, 트랜잭션은 더 커집니다 — Bitcoin에서는 서명이 늘면 바이트가 늘고 수수료도 약간 올라갑니다. 당신의 정책은 온체인에 드러나기도 하는데, 이는 프라이버시 고려 사항입니다. 관찰자는 누가 무엇을 쥐는지는 못 봐도 어떤 주소가 2-of-3라는 것은 볼 수 있습니다.
멀티시그란 무엇이며 왜 중요한가가 모델을 더 깊이 다룹니다.
SSP는 정확히 어디에 서 있는가
SSP는 2-of-2 멀티시그입니다. 다만 여기서는 솔직함이 한 가지 세부를 요구합니다. 구현이 모든 체인에서 동일하지는 않기 때문입니다.
Bitcoin과 다른 UTXO 체인에서는 BIP-48을 통한 스크립트 수준의 네이티브 멀티시그입니다. 두 개의 키, 하나의 스크립트, 합의에 의한 강제.
Ethereum과 다른 EVM 체인에는 그에 상응하는 네이티브 스크립트가 없어서, SSP는 두 키로부터 만들어진 집계된 Schnorr 서명을 검증하는 스마트 계정을 씁니다. 당신의 두 기기가 MuSig2 방식의 프로토콜을 돌리고 체인은 하나의 서명을 봅니다 — 기계적으로는 그 모양이 Bitcoin의 멀티시그 스크립트보다 MPC에 가깝습니다.
중요한 구분은 "집계됐느냐 아니냐"가 아닙니다. SSP가 지원하는 모든 체인에서 성립하는 다음 두 가지 사실입니다.
- 두 키 모두 당신의 기기에서 생성되고 오직 당신만이 보유합니다. SSP는 어떤 조각도, 어떤 키도, 어떤 부분적 비밀도 보유하지 않습니다. 우리 서버에는 잃어버리거나, 소환당하거나, 인질로 잡힐 조각이 존재하지 않습니다.
- 요건은 온체인에 있습니다. EVM에서 스마트 계정의 코드는 오직 당신의 두 키만이 만들어 낼 수 있는 서명 없이는 어떤 트랜잭션도 승인하지 않습니다. 그 코드는 배포되어 있고, 공개되어 있으며, 감사를 받았습니다 — 우리 소프트웨어가 적용하기로 고른 정책이 아닙니다.
Solana에서는 생성자도 관리자 키도 없는 온체인 프로그램이며, 볼트 주소 자체가 구성원 집합과 임계값의 지문입니다. 메커니즘은 다르고 보장은 같습니다.
집계의 암호학이 궁금하다면 Schnorr 서명과 멀티시그 집계가 하나의 서명이 어떻게 두 개의 키를 요구할 수 있는지 설명합니다.
실패 양상을 나란히 놓고
보안 모델은 무엇이 부서지는지를 물어 비교하는 것이 가장 좋습니다.
기기 하나가 뚫린다. 두 모델 모두 살아남습니다. 공격자는 조각 하나 또는 키 하나를 가졌을 뿐이고 혼자서는 서명할 수 없습니다.
제공자가 사라진다. 멀티시그는 살아남습니다 — 필요한 것은 키와 온체인 규칙뿐입니다. MPC는 제공자의 소프트웨어 없이 당신의 조각을 확보해 사용할 수 있을 때만 살아남고, 그것은 전적으로 설계에 달렸습니다.
제공자가 행동을 강요당한다. 제공자가 조각을 쥐고 있다면 그 조각은 법적 강제로 산출될 수 있고, 방식에 따라 다른 한 조각과 합쳐 자금을 옮기기에 충분할 수 있습니다. 제공자가 아무것도 쥐고 있지 않다면 — SSP처럼 두 키가 모두 당신의 것이라면 — 강제할 대상이 없습니다.
키나 조각 하나를 잃는다. 이는 기술이 아니라 임계값에 달렸습니다. 어느 쪽이든 2-of-3 구성은 한 번의 분실을 견디고, 어느 쪽이든 2-of-2 구성은 견디지 못합니다. 키 하나가 유출되면 어떻게 되는가가 SSP의 경우를 구체적으로 훑습니다.
지갑 소프트웨어가 당신이 무엇에 서명하는지에 대해 거짓말을 한다. 여기서는 어느 모델도 도움이 되지 않으며, 이 점은 분명히 말해 둘 만합니다. 권한을 흩뜨리는 것은 도난당한 키로부터 지켜 주지만, 잘못된 트랜잭션을 승인하는 것으로부터 지켜 주지는 않습니다. 그래서 두 모델 모두에 대해 흥미로운 물음은, 서명 전에 당신의 기기가 무엇을 독립적으로 검증하느냐입니다 — 서버의 설명을 믿는 대신 원시 트랜잭션을 디코딩하느냐.
각자가 이기는 지점
MPC는 좋은 멀티시그 기본 요소가 없는 체인에서 이깁니다. 트랜잭션 크기와 수수료에서도, 구성의 프라이버시에서도, 그리고 흔히 사용 경험에서도 — 특히 복구에서, 잘 설계된 MPC 제품은 여러 개의 시드 백업을 굴리는 것보다 훨씬 친절할 수 있습니다.
멀티시그는 검증 가능성에서 이깁니다. 규칙이 원장 안에 있습니다. 보안 모델에 대한 설명을 믿을 필요가 없습니다. 주소나 컨트랙트를 읽고 정책을 보면 됩니다. 독립성에서도 이깁니다. 당신이 키를 쥔 멀티시그 구성의 신뢰 모델에는 회사가 아예 등장하지 않습니다.
목적에 따라 다른 답을 선호하는 데는 아무 모순이 없습니다. 일상용 소액은 잘 만들어진 MPC 지갑에, 장기 보유분은 키를 따로 보관한 멀티시그에 — 완전히 일관된 배치입니다.
결정하기 전에 물어야 할 것
어느 쪽으로 기울든, 다음 네 가지 물음이 튼튼한 구현과 허술한 구현을 갈라 놓습니다.
- 각 키 또는 조각은 누가 쥐고 있으며, 나는 그것들을 전부 확보할 수 있는가? 솔직한 답에 "제공자, 그리고 못 한다"가 들어 있다면 당신은 상대방이 존재하는 모델을 고른 것입니다.
- 제공자가 내일 사라지면 어떻게 되는가? 그들을 거치지 않는, 문서화된 경로가 있어야 합니다. 필요해지기 전에 시험해 보세요.
- 정책은 어디에 사는가? 온체인의 스크립트나 컨트랙트인가, 아니면 소프트웨어인가? 둘 다 괜찮을 수 있지만, 소프트웨어가 바뀌어도 살아남는 것은 하나뿐입니다.
- 각 기기는 서명 전에 무엇을 검증하는가? 두 기기 모두 서버가 보내는 것을 눈감고 서명한다면 두 번째 키는 아무것도 보태지 못합니다. 멀티시그 실패 양상과 SSP의 완화 방식이 이 점과, 여러 키 구성이 실무에서 무력화될 수 있는 다른 경로들을 훑습니다.
SSP가 딛고 선 모델을 처음부터 설명받고 싶다면 2-of-2 멀티시그란 무엇인가에서 시작하세요. 그리고 당신을 여기까지 데려온 걱정이 키에 대한 통제를 잃는 것이 아니라 키를 잃는 것이라면, 소셜 리커버리 대 멀티시그가 다른 갈래의 답을 다룹니다.
