본문으로 이동
Financial Context Wiki

계층적 결정론(HD) 지갑

HD 지갑이 하나의 시드에서 키 트리를 파생하는 방법, 강화 파생과 일반 파생의 차이, 완전하고 검증 가능한 지갑 백업에 보존해야 할 정보를 알아봅니다.

업데이트

교육 목적으로만 제공되며 투자 조언이 아닙니다. 투자로 손실이 발생할 수 있습니다.

직접 답변

계층적 결정론(HD) 지갑은 하나의 루트 시드에서 재현 가능한 암호화 키 쌍의 트리를 파생합니다. BIP-32는 키 트리 메커니즘을 정의합니다. 각 노드는 키와 32-byte 체인 코드를 포함하는 확장 키이며, 각 자식 노드는 인덱스로 선택됩니다. 동일한 루트 재료, 파생 규칙, 경로를 사용하면 동일한 자식 키가 재현됩니다.

“결정론적”이라는 특성은 백업을 실용적으로 만들지만, 모든 지갑이 서로 호환된다는 뜻은 아닙니다. 니모닉 문구는 엔트로피를 인코딩하고 시드를 만드는 한 가지 방법입니다. 파생 경로는 노드를 선택하고, 주소 또는 스크립트 규칙은 그 공개 키를 체인이 인식하는 형태로 변환합니다. 암호 문구, 경로, 네트워크, 스크립트 유형 또는 계정 탐색 규칙이 다르면 단어만 복원했을 때 빈 지갑이 표시될 수 있습니다.

“계층적”이라는 말은 권한을 하위 트리별로 나눌 수 있다는 뜻입니다. 계정 수준 확장 공개 키가 있으면 관찰 전용 서비스가 지출 키를 보유하지 않고도 일반 방식으로 후손 공개 키를 파생할 수 있습니다. 확장 개인 키는 이에 대응하는 개인 키 하위 트리를 파생할 수 있으므로, 주소 하나가 아니라 여러 개인 키의 묶음처럼 보호해야 합니다.

HD 지갑은 키 관리 설계이지 온체인 지갑 객체가 아닙니다. 블록체인은 니모닉, 시드, 경로, 라벨 또는 백업을 저장하지 않습니다. 이는 지갑 소프트웨어와 사용자가 관리하는 오프체인 기록입니다.

작동 방식

1. 엔트로피에서 루트까지

BIP-39는 BIP-32에 앞서 흔히 사용되지만 두 표준은 서로 별개입니다. BIP-39는 128-256 bits의 엔트로피와 체크섬을 12-24 words로 인코딩한 다음, 정규화된 니모닉과 선택적 암호 문구에 PBKDF2-HMAC-SHA512를 2048회 적용해 512-bit 시드를 생성합니다. 모든 암호 문구는 유효하지만 서로 다른 시드를 생성하므로, 암호 문구를 빠뜨리거나 잘못 입력해도 “잘못된 비밀번호” 메시지로 확실히 감지되지 않습니다.

BIP-32는 Bitcoin seed를 키로 사용하는 HMAC-SHA512를 통해 시드 바이트를 마스터 개인 키와 마스터 체인 코드로 변환합니다. 이 루트 확장 개인 키가 BIP-32 트리의 출발점입니다. 모든 결정론적 지갑이 BIP-39나 BIP-32를 사용하는 것은 아니므로, 복구할 때는 복구 단어가 있다는 사실만으로 추론하지 말고 실제 방식을 확인해야 합니다.

2. 확장 키와 자식 키 파생

BIP-32 확장 개인 키는 개인 키와 체인 코드를 결합합니다. 개인 키 정보를 제거한 확장 공개 키는 이에 대응하는 공개 키와 동일한 체인 코드를 결합합니다. 일반 자식 키 파생은 부모 공개 키, 체인 코드, 자식 인덱스를 사용하므로 확장 공개 키에서 일반 자식 공개 키를 파생할 수 있습니다. 그러나 자식 개인 키는 파생할 수 없습니다.

강화 자식 노드는 2^31부터 2^32 - 1까지의 인덱스를 사용하며 부모 개인 키 재료를 계산에 포함합니다. 따라서 부모 확장 공개 키로는 파생할 수 없습니다. 경로에서는 일반적으로 m/84'/0'/0'처럼 아포스트로피로 강화 노드를 표시합니다. 강화는 특정 BIP-32 장애가 초래하는 피해를 제한합니다. 부모 확장 공개 키와 그에 대응하는 비강화 자식 개인 키 하나가 함께 노출되면 부모 확장 개인 키가 드러날 수 있습니다.

3. 경로가 키 트리에 의미를 부여합니다

BIP-44는 m / purpose' / coin_type' / account' / change / address_index를 정의합니다. 처음 3개 수준은 강화되며, change와 address_index는 일반 파생이므로 계정 공개 키에서 수신 주소와 잔돈 주소를 생성할 수 있습니다. 관례상 분기 0은 외부용이고 분기 1은 내부 잔돈용입니다. BIP-44 탐색은 거래 내역을 스캔하며, 연속된 미사용 외부 주소 20개를 갭 한도로 사용합니다.

경로는 메타데이터이지 비밀이나 보편적 보장이 아닙니다. BIP-84는 네이티브 SegWit P2WPKH 계정에 목적 84'를 할당하지만, 다른 목적 또는 지갑 고유의 배치는 다른 하위 트리를 생성합니다. 코인 유형은 네임스페이스 관례이며 블록체인이 강제하는 규칙이 아닙니다.

4. 키가 지갑의 전부는 아닙니다

공개 키에는 네트워크와 주소 또는 스크립트 규칙도 필요합니다. Bitcoin에서는 같은 키가 서로 다른 출력 스크립트에 쓰일 수 있고, 다중 서명 지갑에는 임계값, 공동 서명자 키, 키 순서, 파생 출처도 필요합니다. BIP-380 출력 디스크립터는 키와 그 출처를 명시적인 스크립트 표현식에 결합하며 체크섬을 포함할 수도 있습니다. 그러므로 시드만 백업해서는 원래 지갑이 감시하거나 지출할 수 있었던 대상을 재구성하지 못할 수 있습니다.

지갑 라벨, 연락처, 거래 메모, 가져온 키, 계정 이름, 일부 계약 또는 스마트 계정의 복구 설정은 일반적으로 결정론적으로 파생되지 않습니다. 별도로 내보내거나 기록해야 합니다.

5. 백업과 복구는 검증해야 하는 절차입니다

지갑 구현, 니모닉 또는 시드 형식, 암호 문구 존재 여부, 마스터 지문, 관련 경로, 네트워크, 계정 인덱스, Bitcoin 디스크립터 또는 이에 상응하는 정책 데이터를 기록하십시오. 가능하면 루트 비밀은 오프라인에 보관하고 공개 복구 메타데이터와 분리하십시오. xpub 자체로는 지출할 수 없지만 잔액, 주소 간 관계, 향후 일반 파생 주소를 노출할 수 있습니다.

백업에 의존하기 전에 신뢰할 수 있는 환경에서 복구를 테스트하십시오. 먼저 자금을 옮기지 않고 알려진 주소나 디스크립터를 비교한 다음, 수신 분기와 잔돈 분기, 이후 계정, 거래 내역을 확인하고 통제된 소액 거래로 서명을 검증하십시오. 신뢰할 수 없는 웹사이트나 고객 지원 채팅에 니모닉, 암호 문구 또는 xprv를 입력하지 마십시오.

예시

m/84'/0'/0' 경로의 Bitcoin 네이티브 SegWit 계정을 생각해 보겠습니다. 목적 84'는 BIP-84 관례를 선택하고, 0'는 Bitcoin 코인 유형 네임스페이스를 선택하며, 마지막 0'는 첫 번째 계정을 선택합니다. 관찰 전용 시스템은 계정 확장 공개 키를 받아 계정 개인 키를 받지 않고도 일반 분기를 파생할 수 있습니다.

첫 번째 외부 수신 키는 m/84'/0'/0'/0/0에 있고 다음 키는 m/84'/0'/0'/0/1에 있습니다. 첫 번째 내부 잔돈 키는 m/84'/0'/0'/1/0에 있습니다. 모두 같은 계정에서 파생되지만 분기와 인덱스에 따라 서로 다른 키가 선택됩니다. 같은 시드를 m/44'/0'/0'/0/0과 함께 사용하면 다른 하위 트리와 다른 출력 관례가 선택됩니다. 결과가 비어 있다고 해서 시드가 잘못되었다는 뜻은 아닙니다.

완전한 Bitcoin 복구 기록을 만들려면 루트 비밀 백업을 지문, 경로, 확장 공개 키, 스크립트 유형, 체크섬을 식별하는 디스크립터 또는 이에 상응하는 메타데이터와 분리해 보관하십시오. 두 분기에서 이전에 사용한 주소 여러 개를 확인하십시오. 첫 번째 수신 주소만 찾는 것은 올바른 리프 하나를 확인한 증거일 뿐, 모든 계정, 잔돈 출력 또는 지갑 정책이 복구되었다는 증거는 아닙니다.

위험

  • 단일 루트 집중: 루트 시드 또는 충분히 높은 수준의 확장 개인 키가 침해되면 그 범위의 모든 후손이 노출될 수 있습니다.
  • 백업 분실: 유일한 시드 백업을 잃거나 별도로 관리하던 기록되지 않은 BIP-39 암호 문구를 잃으면 모든 파생 키를 복구하지 못할 수 있습니다.
  • 암호 문구에 대한 잘못된 확신: 잘못된 BIP-39 암호 문구는 서로 다른 유효한 지갑을 생성하므로, 복구에는 성공했지만 비어 있는 것처럼 보일 수 있습니다.
  • 경로 또는 스크립트 불일치: 올바른 시드라도 목적, 계정, 분기, 네트워크 또는 출력 유형이 잘못되면 유효하지만 무관한 주소가 생성됩니다.
  • 불완전한 정책 백업: 시드와 경로만으로는 다중 서명, 디스크립터, 스마트 계정 또는 지갑 고유의 지출 조건을 재구성하지 못할 수 있습니다.
  • 확장 공개 키의 개인정보 노출: xpub는 서로 연관된 주소들을 드러내고 일반 파생 후손을 계속 추적할 수 있게 할 수 있습니다.
  • BIP-32 부모 키 침해: 부모 xpub와 유출된 대응 비강화 자식 개인 키가 함께 있으면 부모 개인 키 하위 트리가 노출될 수 있습니다.
  • 신뢰할 수 없는 복구 도구: 웹사이트, 확장 프로그램, 위조 장치, 클립보드 도구 또는 화면 공유가 루트 비밀 전체를 탈취할 수 있습니다.
  • 검증하지 않은 보관 매체: 종이, 금속, 암호화 파일 또는 하드웨어 백업은 전사 오류, 부식, 잊어버린 비밀번호 또는 지원되지 않는 형식 때문에 실패할 수 있습니다.
  • 불완전한 이전: 보이는 코인만 옮기고 토큰, 잔돈 출력, 계약 역할, 승인 또는 이후 계정을 기존 루트 아래에 남겨 두면 위험 노출도 남습니다.

흔한 오해

하나의 백업 문구에 지갑의 모든 세부 정보가 포함되나요?

아닙니다. 루트 키 재료는 재현할 수 있어도 암호 문구, 파생 관례, 네트워크, 스크립트, 다중 서명 정책, 라벨, 가져온 키 또는 계정 탐색 내역은 포함되지 않을 수 있습니다. 실제 지갑에 필요한 메타데이터를 보존하십시오.

xpub로는 지출할 수 없으니 공개해도 안전한가요?

아닙니다. 일반적으로 서명은 할 수 없지만, 과거와 미래의 일반 파생 주소 및 이들의 통합 내역을 드러낼 수 있습니다. 앞서 설명한 BIP-32 장애에서는 대응하는 비강화 자식 개인 키와 결합될 경우 부모 하위 트리까지 침해될 수 있습니다.

새 주소를 만들면 독립적인 백업도 생기나요?

아닙니다. 새 주소는 주소 재사용을 줄이고 개인정보 보호를 개선하지만, 결정론적 후손은 여전히 같은 조상의 통제를 받습니다. 결제마다 새 주소를 사용했더라도 루트가 침해되면 하위 트리가 영향을 받습니다.

익숙한 주소 하나를 복원하면 지갑 전체가 복구되었다고 볼 수 있나요?

아닙니다. 이는 루트 재료, 경로, 주소 구성의 한 조합만 검증합니다. 복구는 수신 분기와 잔돈 분기, 사용한 모든 계정, 스크립트 또는 정책, 관련 네트워크를 포괄해야 합니다.

관련 주제

출처

탐색

위키 검색...