CWLog - crypto 개발 & 해킹 좋아하는 사람의 블로그 Zola 2026-05-11T00:00:00+00:00 https://blog.devcw.xyz/tags/crypto/atom.xml 머클 트리 (Merkle Tree) 2026-05-11T00:00:00+00:00 2026-05-11T00:00:00+00:00 Unknown https://blog.devcw.xyz/posts/merkle-tree/ <p>블록체인 L1 레이어에선 블록이 정상적인지 판별하기 위해 머클 트리를 이용해서 만든 트랜잭션 해시값을 대조한다.</p> <p><img src="../../images/merkle-2.png" alt="merkle-2" /></p> <p>위와 같이 각 트랜잭션들의 해시를 트리 형태로 합해서(H(L1 | L2)) 머클 루트를 만든다. 해시 특성상 1 바이트라도 바뀌면 트리 전체가 무너지기 때문에 정합성을 검증할 수 있다. 머클 트리 자체의 방식은 이게 끝이다. 설명할게 따로 없다. 그냥 해시 이어붙여서 또 해시하기, 그걸 올리기다.</p> <p>중요한 부분은 이게 실제 블록체인에서 어떻게 사용되는지이다. 보통 일반적으로 블록의 형태는 다음과 같다.</p> <pre class="giallo" style="color-scheme: light dark; color: light-dark(#24292E, #E1E4E8); background-color: light-dark(#FFFFFF, #24292E);"><code data-lang="rust"><span class="giallo-l"><span style="color: light-dark(#D73A49, #F97583);">type</span><span style="color: light-dark(#6F42C1, #B392F0);"> Hash</span><span style="color: light-dark(#D73A49, #F97583);"> =</span><span> [</span><span style="color: light-dark(#6F42C1, #B392F0);">u8</span><span>;</span><span style="color: light-dark(#005CC5, #79B8FF);"> 32</span><span>]</span><span>;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span style="color: light-dark(#D73A49, #F97583);">struct</span><span style="color: light-dark(#6F42C1, #B392F0);"> BlockHeader</span><span> {</span></span> <span class="giallo-l"><span> version</span><span style="color: light-dark(#D73A49, #F97583);">:</span><span style="color: light-dark(#6F42C1, #B392F0);"> u32</span><span>,</span></span> <span class="giallo-l"><span> prev_block_hash</span><span style="color: light-dark(#D73A49, #F97583);">:</span><span style="color: light-dark(#6F42C1, #B392F0);"> Hash</span><span>,</span></span> <span class="giallo-l"><span> merkle_root</span><span style="color: light-dark(#D73A49, #F97583);">:</span><span style="color: light-dark(#6F42C1, #B392F0);"> Hash</span><span>,</span></span> <span class="giallo-l"><span> timestamp</span><span style="color: light-dark(#D73A49, #F97583);">:</span><span style="color: light-dark(#6F42C1, #B392F0);"> u64</span><span>,</span></span> <span class="giallo-l"><span>}</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span style="color: light-dark(#D73A49, #F97583);">struct</span><span style="color: light-dark(#6F42C1, #B392F0);"> Block</span><span> {</span></span> <span class="giallo-l"><span> header</span><span style="color: light-dark(#D73A49, #F97583);">:</span><span style="color: light-dark(#6F42C1, #B392F0);"> BlockHeader</span><span>,</span></span> <span class="giallo-l"><span> transactions</span><span style="color: light-dark(#D73A49, #F97583);">:</span><span style="color: light-dark(#6F42C1, #B392F0);"> Vec</span><span>&lt;</span><span style="color: light-dark(#6F42C1, #B392F0);">Transaction</span><span>&gt;</span><span>,</span></span> <span class="giallo-l"><span>}</span></span></code></pre><h2 id="beulrogceini-meokeul-ruteureul-sseuneun-sijeom">블록체인이 머클 루트를 쓰는 시점<a class="anchor" aria-hidden="true" href="#beulrogceini-meokeul-ruteureul-sseuneun-sijeom" hidden="">#</a> </h2> <p>크게 세 군데가 있는데,</p> <ol> <li> <p>블록 생성: 블록 생성자(PoW면 마이너, PoS면 프로포저)는 멤풀에서 트랜잭션을 골라 머클 트리를 계산하고, 그 루트를 <code>merkle_root</code>에 박는다. 이 시점부터 본문은 사실상 동결이다. 트랜잭션 하나만 바꿔도 루트가 바뀌고, 그 위에서 진행한 봉인 작업(PoW 해싱이든 PoS 서명이든)이 전부 무효가 된다.</p> </li> <li> <p>블록 검증: 풀노드는 본문 트랜잭션 전부로 머클 루트를 재계산해서 헤더의 <code>merkle_root</code>와 대조한다. 일치하지 않으면 거부 처리된다. 트랜잭션 위변조나 누락은 여기서 잡힌다.</p> </li> <li> <p>풀노드 없이 검증할 때 (라이트 클라이언트): 32바이트 해시 하나가 본문 전체를 대표하니까, 헤더만 따라가도 체인 상태를 검증할 수 있다. 본문(MB 단위)은 필요할 때만 받는다. 모바일 지갑이 이 방식으로 동작한다.</p> </li> </ol> <p>그럼 라이트 클라이언트는 내 트랜잭션이 이 블록에 진짜 들어있다는 걸 어떻게 검증할까. 여기서 머클 증명이 나온다.</p> <h2 id="meokeul-jeungmyeong-merkle-proof">머클 증명 (Merkle Proof)<a class="anchor" aria-hidden="true" href="#meokeul-jeungmyeong-merkle-proof" hidden="">#</a> </h2> <p>트리에서 잎부터 루트까지 올라가는 경로의 형제(sibling) 해시만 있으면 된다. 트랜잭션이 N개일 때 필요한 해시는 log₂(N)개이다.</p> <p>Tx1~Tx4 네 트랜잭션이 잎으로 있는 트리(<code>L1 = hash(H1|H2)</code>, <code>L2 = hash(H3|H4)</code>, <code>root = hash(L1|L2)</code>)에서 Tx3이 들어있다는 걸 증명한다고 치자.</p> <ul> <li>클라이언특 가지고 있는 것: Tx3</li> <li>밸리데이터가 줘야 할 것: H4, L1</li> <li>검증: <ol> <li>H3 = hash(Tx3)</li> <li>L2' = hash(H3 | H4)</li> <li>root' = hash(L1 | L2')</li> <li>root'가 헤더의 <code>merkle_root</code>와 같으면 끝</li> </ol> </li> </ul> <p>이게 끝이다. 별 거 없어 보이지만 이 검증 단계 개수에 머클 증명의 효율성이 다 들어있다.</p> <p>트리 구조는 한 층 올라갈 때마다 노드 수가 절반이 되니까, 잎이 N개라면 루트까지 깊이는 log₂(N)이고, 각 층에서 형제 해시 하나씩만 받으면 위로 합쳐 올라갈 수 있다. 필요한 해시 개수도 결국 log₂(N)개가 된다.</p> <p>숫자로 보면 얼추 감이 잡히는데,</p> <ul> <li>트랜잭션 4개 → 해시 <strong>2개</strong></li> <li>트랜잭션 1,024개 → 해시 <strong>10개</strong></li> <li>트랜잭션 100만 개 → 해시 <strong>20개</strong></li> <li>트랜잭션 10억 개 → 해시 <strong>30개</strong></li> </ul> <p>가 된다. 본문은 O(N)으로 늘어나는데 증명은 O(log N)로만 자란다. 트랜잭션을 1000배로 늘려도 해시는 10개 더 받으면 끝인 것이다.</p> <pre class="giallo" style="color-scheme: light dark; color: light-dark(#24292E, #E1E4E8); background-color: light-dark(#FFFFFF, #24292E);"><code data-lang="rust"><span class="giallo-l"><span style="color: light-dark(#D73A49, #F97583);">enum</span><span style="color: light-dark(#6F42C1, #B392F0);"> Direction</span><span> {</span></span> <span class="giallo-l"><span style="color: light-dark(#6F42C1, #B392F0);"> Left</span><span>,</span></span> <span class="giallo-l"><span style="color: light-dark(#6F42C1, #B392F0);"> Right</span><span>,</span></span> <span class="giallo-l"><span>}</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span style="color: light-dark(#D73A49, #F97583);">struct</span><span style="color: light-dark(#6F42C1, #B392F0);"> MerkleProof</span><span> {</span></span> <span class="giallo-l"><span> leaf</span><span style="color: light-dark(#D73A49, #F97583);">:</span><span style="color: light-dark(#6F42C1, #B392F0);"> Hash</span><span>,</span></span> <span class="giallo-l"><span> siblings</span><span style="color: light-dark(#D73A49, #F97583);">:</span><span style="color: light-dark(#6F42C1, #B392F0);"> Vec</span><span>&lt;</span><span>(</span><span style="color: light-dark(#6F42C1, #B392F0);">Hash</span><span>,</span><span style="color: light-dark(#6F42C1, #B392F0);"> Direction</span><span>)</span><span>&gt;</span><span>,</span></span> <span class="giallo-l"><span>}</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span style="color: light-dark(#D73A49, #F97583);">fn</span><span style="color: light-dark(#6F42C1, #B392F0);"> verify</span><span>(</span><span>proof</span><span style="color: light-dark(#D73A49, #F97583);">:</span><span style="color: light-dark(#D73A49, #F97583);"> &amp;</span><span style="color: light-dark(#6F42C1, #B392F0);">MerkleProof</span><span>,</span><span> root</span><span style="color: light-dark(#D73A49, #F97583);">:</span><span style="color: light-dark(#D73A49, #F97583);"> &amp;</span><span style="color: light-dark(#6F42C1, #B392F0);">Hash</span><span>)</span><span style="color: light-dark(#D73A49, #F97583);"> -&gt;</span><span style="color: light-dark(#6F42C1, #B392F0);"> bool</span><span> {</span></span> <span class="giallo-l"><span style="color: light-dark(#D73A49, #F97583);"> let</span><span style="color: light-dark(#D73A49, #F97583);"> mut</span><span> acc</span><span style="color: light-dark(#D73A49, #F97583);"> =</span><span> proof</span><span style="color: light-dark(#D73A49, #F97583);">.</span><span>leaf</span><span>;</span></span> <span class="giallo-l"><span style="color: light-dark(#D73A49, #F97583);"> for</span><span> (</span><span>sibling</span><span>,</span><span> dir</span><span>)</span><span style="color: light-dark(#D73A49, #F97583);"> in</span><span style="color: light-dark(#D73A49, #F97583);"> &amp;</span><span>proof</span><span style="color: light-dark(#D73A49, #F97583);">.</span><span>siblings </span><span>{</span></span> <span class="giallo-l"><span> acc</span><span style="color: light-dark(#D73A49, #F97583);"> =</span><span style="color: light-dark(#D73A49, #F97583);"> match</span><span> dir</span><span> {</span></span> <span class="giallo-l"><span style="color: light-dark(#6F42C1, #B392F0);"> Direction</span><span style="color: light-dark(#D73A49, #F97583);">::</span><span style="color: light-dark(#6F42C1, #B392F0);">Left</span><span style="color: light-dark(#D73A49, #F97583);"> =&gt;</span><span style="color: light-dark(#6F42C1, #B392F0);"> hash_pair</span><span>(</span><span>sibling</span><span>,</span><span style="color: light-dark(#D73A49, #F97583);"> &amp;</span><span>acc</span><span>)</span><span>,</span></span> <span class="giallo-l"><span style="color: light-dark(#6F42C1, #B392F0);"> Direction</span><span style="color: light-dark(#D73A49, #F97583);">::</span><span style="color: light-dark(#6F42C1, #B392F0);">Right</span><span style="color: light-dark(#D73A49, #F97583);"> =&gt;</span><span style="color: light-dark(#6F42C1, #B392F0);"> hash_pair</span><span>(</span><span style="color: light-dark(#D73A49, #F97583);">&amp;</span><span>acc</span><span>,</span><span> sibling</span><span>)</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>;</span></span> <span class="giallo-l"><span> }</span></span> <span class="giallo-l"><span style="color: light-dark(#D73A49, #F97583);"> &amp;</span><span>acc</span><span style="color: light-dark(#D73A49, #F97583);"> ==</span><span> root</span></span> <span class="giallo-l"><span>}</span></span></code></pre> <p>방향이 필요한 이유는 <code>hash(A|B) ≠ hash(B|A)</code>이기 때문이다. (문자열을 앞뒤로 단순히 붙이기 때문) 형제가 왼쪽인지 오른쪽인지 모르면 다른 루트가 나온다.</p> <p>이 구조의 안전성은 결국 해시 함수의 충돌 저항성에 기대는데 공격자가 <code>hash(X | H4) = hash(H3 | H4)</code>인 가짜 <code>X</code>를 만들 수 있다면 변조가 가능하겠지만.. SHA-256 같은 함수에선 확률적으로 불가능하다.</p> <h2 id="dareun-goseseodo-sseuinda">다른 곳에서도 쓰인다<a class="anchor" aria-hidden="true" href="#dareun-goseseodo-sseuinda" hidden="">#</a> </h2> <p>해시 트리 자체는 블록체인 전용 자료구조가 아니라서 곳곳에 박혀있다.</p> <ul> <li>Git: 객체 저장소가 머클 DAG다. 커밋 해시 하나가 트리 전체를 대표한다.</li> <li>Certificate Transparency: TLS 인증서 발급 로그</li> <li>이더리움: 상태(state)까지 머클로 박는 Merkle Patricia Trie를 쓴다</li> <li>ZK 시스템: 상태 커밋먼트로 머클 루트 사용</li> </ul> <p>내부 구조 까보면 해시 묶어서 트리 쌓고 루트만 들고 다니기가 전부인데 의외로 응용 폭이 넓은 자료구조다.</p> Consensus Engine (합의 엔진) 이해하기 2026-01-15T00:00:00+00:00 2026-01-15T00:00:00+00:00 Unknown https://blog.devcw.xyz/posts/consensuses/ <p>근래에 블록체인에 꽤 관심이 생겼다. 생태계를 쭉 둘러봤는데, 대략적으로 dApp이나 Consensus 엔진 정도가 눈에 먼저 보인 것 같다.</p> <p>차차 전반적으로 이해한 걸 바탕으로 글을 쓸 예정이다. 다만 우선 첫글은 가장 low-level 레이어인 합의 엔진 (Consensus Engine)을 이론이랑 구현체를 까보며 이해해보려고 한다.</p> <p>이런 게 왜 필요할까? 그리고 구현은 왜 그렇게 돼있을까? 이걸 알기 위해선 우선 분산 시스템을 이해할 필요가 있다.</p> <h2 id="bunsan-siseutem">분산 시스템<a class="anchor" aria-hidden="true" href="#bunsan-siseutem" hidden="">#</a> </h2> <p>일단 사전적인 정의로는, 여러 독립적인 노드(컴퓨터)들이 네트워크로 연결되어 하나의 공동 목표를 수행하기 위한 시스템이다.</p> <p>예를 들어..</p> <ul> <li>Redis에서 샤딩 기능을 이용해서 여러 노드가 연결되고 캐싱을 수행하면 분산 시스템이다. (장애 복구)</li> <li>인프라에서 de facto인 쿠버네티스같은 경우도 동일하다.</li> </ul> <p>결국 여러 노드가 <strong>동일한 순서의 로그를 통해 동일한 State</strong>를 갖게 만드는 것이 핵심이다. 이걸 학술적으로는 **상태 머신 전파(State Machine Replication)**라고 부른다.</p> <h3 id="raft-habyi-algorijeum">Raft 합의 알고리즘<a class="anchor" aria-hidden="true" href="#raft-habyi-algorijeum" hidden="">#</a> </h3> <p>대표적으로 흔히 사용되고 있는 것은 <code>Raft</code>다.</p> <p>쿠버네티스의 <code>etcd</code>에서 사용하고, <code>Redis</code>도 <code>Sentinel</code>이나 <code>Cluster</code>의 리더 선출 과정에서 <code>Raft-like</code>를 사용한다.</p> <p>함축적으로 플로우를 설명하자면 다음과 같다:</p> <ol> <li>리더가 없을 시 리더 투표를 한다.</li> <li>투표가 정족수, 즉 과반수가 넘으면 해당 노드를 리더로 승격시킨다.</li> <li>리더가 상태 전파를 담당한다.</li> <li>위 과정 반복</li> </ol> <p>이건 모든 노드들이 '착하다' 라는 전제이다. 만약 악의적인 노드가 있다고 하고, 해당 노드가 리더가 되면 잘못된 로그를 줘서 시스템을 붕괴시킬 수도 있다.</p> <p>위의 예시들은 내부 시스템에서 사용하고 있기 때문에 (물론 요새 Zero-Trust로 얼추 방어한다) 이런 경우가 많지 않겠지만, <strong>블록체인</strong>은 다르다. <strong>누구나</strong> 참여할 수 있기 때문에 악의적인 노드가 있을 확률이 존재한다.</p> <p>이를 해결하기 위해 고안된 것이 <strong>비잔틴 장애 허용(Byzantine Fault Tolerance, BFT)</strong> 알고리즘이다.</p> <h2 id="bijantin-jangae-heoyong-algorijeum">비잔틴 장애 허용 알고리즘<a class="anchor" aria-hidden="true" href="#bijantin-jangae-heoyong-algorijeum" hidden="">#</a> </h2> <p>알고리즘을 알기 전 배경적으로 알아야 할 딜레마적 개념이 있는데, <strong>비잔틴 장군 문제</strong>이다.</p> <p>배경은 이렇다:</p> <pre class="giallo" style="color-scheme: light dark; color: light-dark(#24292E, #E1E4E8); background-color: light-dark(#FFFFFF, #24292E);"><code data-lang="plain"><span class="giallo-l"><span>비잔틴 제국의 장군들이 적의 도시를 포위하고 있다.</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>해당 전투에서 이기려면 양자택일을 해야한다: 모든 장군이 전부 공격하거나, 모든 장군이 전부 후퇴하거나</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>현실적인 제약은 다음과 같다:</span></span> <span class="giallo-l"><span>- 장군들끼리는 전령을 통해서만 소통 가능하다.</span></span> <span class="giallo-l"><span>- 장군들 중에서 배신자가 몇몇 섞여있다. 예를 들어, 이런식으로: 몇몇 장군들에게는 후퇴하라고하고 몇몇 장군들에게는 공격하라고 한다.</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span>이 상황에서 어떻게 배신자들을 뚫고 승리할 수 있을까?</span></span></code></pre> <p>위 내용을 해결하기 위한 여러 합의 이론들이 존재한다. 크게 두가지로 나눌 수 있는데</p> <ul> <li>PoW: 연산력 기반 합의 (메세지에 이어진 체인이 가장 긴 게 진실로 합의됨)</li> <li>BFT: 메세지들 던지면 2/3 노드들이 검증 후 메세지를 합의함</li> </ul> <p>와 같이 나눌 수 있다.</p> <p>여기까지가 백서 내용이다. 백서 자체도 장황하지만.. 분산 시스템이 다 그렇듯 엣지케이스 처리를 엄청나게 해줘야 하기 때문에 구현체 내부 동작도 중요하다.</p> <p>현재 공부중인 내용이라 부족한 부분이 존재할 수 있다. 여러가지 엣지케이스가 생각나는데, 다음 글에서 어떻게 핸들링하는지 알아보도록 하겠다.</p> HD Wallet 동작 알아보기 2025-11-25T00:00:00+00:00 2025-11-25T00:00:00+00:00 Unknown https://blog.devcw.xyz/posts/how-hd-wallet-works/ <p><img src="../../images/cold-wallet.png" alt="cold-wallet" /></p> <p>흔히 Hot Wallet, HD Wallet라고 하면 대표적인 소프트웨어들이 많다. <code>Exodus</code>부터 시작해서 <code>MetaMask</code>까지.</p> <p>이 소프트웨어들 전부 갖고있는 특징이 있는데 '비밀 문구'만 알고있다면 오프체인에서 지갑을 복구할 수 있다.</p> <p>Magic 같아 보이는 구조를 톺아보도록 하자.</p> <h2 id="hd-wallet">HD Wallet<a class="anchor" aria-hidden="true" href="#hd-wallet" hidden="">#</a> </h2> <p>HD Wallet은 <code>Hierarchical Deterministic Wallet</code>의 약자다. 계층형 결정론적 지갑이란 뜻인데, 사전적 의미만 봐선 역할 파악이 쉽지가 않다.</p> <p>아래가 HD Wallet의 전체 흐름 구조이다.</p> <pre class="giallo" style="color-scheme: light dark; color: light-dark(#24292E, #E1E4E8); background-color: light-dark(#FFFFFF, #24292E);"><code data-lang="plain"><span class="giallo-l"><span>Master Seed (니모닉 → 512bit Seed)</span></span> <span class="giallo-l"><span> │</span></span> <span class="giallo-l"><span> └── Master Key (m)</span></span> <span class="giallo-l"><span> │</span></span> <span class="giallo-l"><span> ├── Purpose (m/44&#39;) ← BIP-44 표준</span></span> <span class="giallo-l"><span> │ │</span></span> <span class="giallo-l"><span> │ ├── Coin Type (m/44&#39;/0&#39;) ← Bitcoin</span></span> <span class="giallo-l"><span> │ │ │</span></span> <span class="giallo-l"><span> │ │ └── Account (m/44&#39;/0&#39;/0&#39;)</span></span> <span class="giallo-l"><span> │ │ │</span></span> <span class="giallo-l"><span> │ │ ├── External (m/44&#39;/0&#39;/0&#39;/0) ← 수신 주소</span></span> <span class="giallo-l"><span> │ │ │ ├── Address 0</span></span> <span class="giallo-l"><span> │ │ │ ├── Address 1</span></span> <span class="giallo-l"><span> │ │ │ └── ...</span></span> <span class="giallo-l"><span> │ │ │</span></span> <span class="giallo-l"><span> │ │ └── Internal (m/44&#39;/0&#39;/0&#39;/1) ← 잔돈 주소</span></span> <span class="giallo-l"><span> │ │</span></span> <span class="giallo-l"><span> │ ├── Coin Type (m/44&#39;/60&#39;) ← Ethereum</span></span> <span class="giallo-l"><span> │ │ └── ...</span></span> <span class="giallo-l"><span> │ │</span></span> <span class="giallo-l"><span> │ └── Coin Type (m/44&#39;/501&#39;) ← Solana</span></span> <span class="giallo-l"><span> │ └── ...</span></span></code></pre> <p>'비밀 문구'. 즉, 니모닉에서 <code>Seed</code>로 변환하고, 거기서 파생된 <code>Master Key</code>를 사용하여 계층적으로 파생된 키를 사용한다.</p> <p>이런 수학적 알고리즘을 통해 한 시드에서 여러 키를 관리할 수 있는 것이다. 반대로 말하면 시드가 털리면 모든 지갑이 다 털릴 것이다.</p> <p>세부적으로 톺기 전 <strong>BIP</strong>에 대해서 간략하게 소개하자면 <strong>비트코인 개선 제안</strong>(<strong>B</strong>itcoin <strong>I</strong>mprovement <strong>P</strong>roposal) 의 약자이다.</p> <p>대강 탈중앙화 기술 논의 결정을 위한 제안서 정도로 생각하면 될 것 같다. 실제로 거기서 채택된 것들이 <strong>BIP-32</strong>와 <strong>BIP-44</strong>이다.</p> <p>표준을 지키지 않아도 지갑 주소 찍어내서 체인에서 쓰는 건 문제없다. 근데.. 예를 들자면 메타마스크에서 콜드월렛으로 지갑 백업을 못한다.</p> <p>즉 각 지갑별로 호환성을 지키려고 존재한다 생각하면 된다.</p> <h3 id="bip-32">BIP-32<a class="anchor" aria-hidden="true" href="#bip-32" hidden="">#</a> </h3> <p>계층적 파생을 위한 표준으로 알고리즘으로, 마스터 키를 만들 때 사용된다.</p> <p>512비트 시드를 받아서 반으로 쪼개서 (256비트 씩) 왼쪽은 마스터 개인키, 오른쪽은 마스터 체인 코드로 쓴다.</p> <p>왜 이렇게 하나 싶겠지만, 마스터 체인 코드가 엔트로피 역할을 해서 자식 키를 만들 때 무작위성을 부여해준다. (실질적으로는 관련이 있긴 하지만)</p> <p>키 찍어내는 핵심 알고리즘이다.</p> <h3 id="bip-44">BIP-44<a class="anchor" aria-hidden="true" href="#bip-44" hidden="">#</a> </h3> <p>크립토별 계층 구조를 정형화 시켜주는 표준 규약이다. 이건 알고리즘은 아니고 규약인데,</p> <p>아까 트리 구조에서 <code>m/44'/..</code> 하던게 이거다. 규약 안 지키고 멋대로 <code>Path</code> 만들면 아까 말했던 것처럼 해당 지갑 서비스가 망해버린다면, 자산 복구가 매우 힘들어진다. 암호화폐 생태계의 철학인 탈중앙화, 자기 주권이 훼손된다.</p> <p>경로 구조는 이렇게 생겼다.</p> <pre class="giallo" style="color-scheme: light dark; color: light-dark(#24292E, #E1E4E8); background-color: light-dark(#FFFFFF, #24292E);"><code data-lang="plain"><span class="giallo-l"><span>m / purpose&#39; / coin_type&#39; / account&#39; / change / address_index</span></span></code></pre><table><thead><tr><th>레벨</th><th>설명</th><th>예시</th></tr></thead><tbody> <tr><td><code>purpose'</code></td><td>BIP 번호</td><td>44'</td></tr> <tr><td><code>coin_type'</code></td><td>코인 종류</td><td>0'=BTC, 60'=ETH</td></tr> <tr><td><code>account'</code></td><td>계정 번호</td><td>0', 1', 2'...</td></tr> <tr><td><code>change</code></td><td>외부/내부</td><td>0=수신, 1=잔돈</td></tr> <tr><td><code>address_index</code></td><td>주소 인덱스</td><td>0, 1, 2...</td></tr> </tbody></table> <p>참고로 <code>'</code> (프라임)은 <strong>Hardened Derivation</strong>을 의미한다. 쉽게 말하면 자식 키가 유출되어도 부모 키를 역추적 못하게 보안을 강화한 파생 방식이다. Purpose, Coin Type, Account처럼 중요한 레벨에는 다 붙어있다.</p> <h3 id="bip-38">BIP-38<a class="anchor" aria-hidden="true" href="#bip-38" hidden="">#</a> </h3> <p>이건 니모닉을 만들 때 쓰는 알고리즘인데, 랜덤으로 생성한 엔트로피를 사람이 기억하기 쉽게 <code>word list</code> 인덱스로 매핑 시키는거다.</p> <p>그래서 초기에 말했던 <code>비밀 문구</code>만 있으면 지갑이 복구가 되는거다.</p> <hr /> <p>이런 BIP들이 지켜지며 블록체인 탈중앙화 생태계가 구축된건데, 개인적으로 매우 신기하다. 그냥 수학, 암호학 놀음에 불과한데 (내려치기 하는게 아니다), 이걸 어떻게 공동이 다 지키게 만들었나 싶다.</p> <h2 id="camjo">참조<a class="anchor" aria-hidden="true" href="#camjo" hidden="">#</a> </h2> <ul> <li><a rel="external" href="https://github.com/bitcoin/bips">https://github.com/bitcoin/bips</a></li> <li><a rel="external" href="https://walletrecoveryservice.com/ko/what-is-bip39/">https://walletrecoveryservice.com/ko/what-is-bip39/</a></li> </ul>