안녕하세요. 개발자 모도리입니다.
요즘 참여하고 있는 스터디에서 Mastering Ethereum 를 교재로 하여 매주 스터디를 진행하고 있습니다. 이번에는 이더리움 지갑에 대해 정리해서 올립니다.
지갑(Wallet)
- 이더리움에서 "지갑"이라는 단어는 조금씩 다르게 사용된다.
- 상위 계층에서 봤을 때 이더리움에 대한 기본 사용자 인터페이스 역할을 하는 응용 소프트웨어이다.
- 지갑은 사용자 자산의 제어권의 통제, 키와 주소 관리, 자산 추적 그리고 트랜잭션의 생성과 서명을 한다.
- 몇 몇 이더리움 지갑은 컨트랙트(예 : ERC20 토큰)와 상호작용을 할 수 있다.
- 더 좁게 프로그래머의 관점에서 봤을 때 지갑은 사용자의 키를 저장하고 관리하는데 사용되는 시스템을 의미한다.
- 모든 지갑은 키 관리 컴포넌트를 가지고 있으며, 몇 몇 지갑들은 그게 전부인 경우도 있다.
- 이더리움 기반의 DApp과의 인터페이스로 사용되는 브라우저의 일부로 지갑이 사용되기도 한다.
- 지갑이라는 단어에 대한 명확한 정의는 없다.
- 여기에서는 개인 키 들의 보관함 그리고 이 키 들을 관리하는 시스템이라고 정의하고 진행하겠다.
지갑 기술 오버뷰
지갑 설계 시 고려사항
- 지갑 설계 시 고려해야 될 중요한 점 중 하나는 편의성과 프라이버시의 균형이다.
- 가장 편리한 이더리움 지갑은 하나의 개인 키와 주소를 가지고 매번 재사용하는 것이다. 하지만 이것은 누구나 쉽게 당신의 모든 트랜잭션을 추적하고 연관 지을 수 있기 때문에 프라이버시에 매우 취약하다
- 매 트랜잭션 마다 새로운 키를 사용하는 것은 프라이버시에 가장 좋긴 하지만, 관리가 매우 어려워진다.
- 올바른 평균을 이루게 하는 것은 매우 어렵지만, 좋은 지갑 설계를 위해선 중요하다.
지갑에 대한 오해
- 이더리움에 대한 오해 중 하나는 이더리움 지갑이 이더나 토큰을 가지고 있다는 것이다.
- 매우 엄격히 말하자면 지갑은 단지 키만 가지고 있고, 이더나 다른 토큰들은 이더리움 블록체인에 기록되어 있다.
- 사용자는 자신의 지갑에 있는 키를 이용해서 서명한 트랜잭션을 통해서 이더리움 네트워크에 있는 토큰을 제어한다.
- 어떤 의미에서 지갑은 열쇠고리이다. 하지만 지갑에 보관 될 키가 이더나 토큰을 다른 사람들에게 전달하는데 사용되기 때문에 구분은 무의미하다.
- 중요한 것은 기존 뱅킹의 중앙 집중 방식에서 블록체인 플랫폼의 탈중앙화 된 시스템으로 사고 방식으로 바꾸는 것이다.
- 기존 뱅킹 시스템 : 자신과 은행만 자신의 계좌 잔고를 확인할 수 있고, 자금 이체를 원할 경우 은행만 확신(납득)시키면 된다.
- 블록체인 플랫폼 : 계정의 주인을 알 수는 없지만, 누구나 계정의 이더 잔액을 확인할 수 있다. 그리고 소유자가 자금 이체를 원할 경우 모두에게 확신(납득)시켜야 한다.
- 실제로 블록체인 플랫폼에서는 지갑 없이 계좌 잔고 확인이 가능하다. 그리고 사용하고 있는 지갑이 마음에 들지 않을 경우 다른 지갑으로 옮겨갈 수 있다.
지갑의 종류
- 지갑은 2가지 기존 종류가 있는데, 키 간의 연관성이 있느냐 없느냐에 따라서 나뉜다.
- 첫번째 종류는 비결정적 지갑으로, 각각의 키가 독립적으로 서로 다른 난수에서 생성된다. 이런 지갑을 JBOK(Just a Bunch of Keys) 지갑이라고도 한다.
- 두번째 종류는 결정적 지갑으로, 모든 키가 시드라고 알려진 하나의 마스터 키에서 유도되어 나온다. 모든 키가 서로 연관되어 있으며 원본 시드가 있는 경우 복구가 가능하다. 키 유도 방법은 여러가지가 있는데, 가장 일반적으로 사용하는 방법은 Hierarchical Deterministic Wallets(BIP-32/BIP-44)에 설명되어 있는 트리와 비슷한 방법이다.
결정적 지갑의 복구
- 데이터 손실 사고(예 : 전화를 도난 당하거나 화장실에 떨어뜨림)에 대비해서 결정적 지갑을 보다 안전하게 유지하려면, 단어 목록(영어 또는 다른 언어)으로 된 시드(니모닉 코드)를 적어두고 사고가 발생했을 때 사용하라.
- 복구 단어 목록은 매우 신경써서 다뤄야 한다. 컴퓨터나 스마트폰에 파일 형태로 저장하지 말고, 종이에 적어서 안전한 곳에 보관하라.
비 결정적[Nondeterministic(Random)] 지갑
- 첫번째 이더리움 지갑(이더리움 프리세일을 위해 만들어짐)에는, 랜덤하게 생성 된 하나의 개인 키가 저장 된 각각의 지갑 파일이 저장되었다.
- 이러한 "구식" 지갑은 여러면에서 뒤떨어지기 때문에 결정적 지갑으로 대체되고 있다.
- 예를 들어 프라이버시를 극대화하기 위해 자금을 받을 때 마다 새로운 주소를 사용한다고 하자. 많은 자금을 다루게 되면 키가 점점 늘어나고 주기적으로 백업을 해야 한다. 만약에 데이터 백업 전에 손실된다면 자금과 스마트 컨트랙트에 대한 제어권을 잃게 된다.
- 많은 이더리움 클라이언트는 키 스토어 파일(추가 보안을 위해서 비밀번호로 암호화 된 하나의 개인 키가 포함 된 JSON으로 인코딩 된 파일)을 이용한다.
- JSON 파일 내용
{
"address": "001d3f1ef827552ae1114027bd3ecf1f086ba0f9",
"crypto": {
"cipher": "aes-128-ctr",
"ciphertext":
"233a9f4d236ed0c13394b504b6da5df02587c8bf1ad8946f6f2b58f055507ece",
"cipherparams": {
"iv": "d10c6ec5bae81b6cb9144de81037fa15"
},
"kdf": "scrypt",
"kdfparams": {
"dklen": 32,
"n": 262144,
"p": 1,
"r": 8,
"salt":
"99d37a47c7c9429c66976f643f386a61b78b97f3246adca89abe4245d2788407"
},
"mac": "594c8df1c8ee0ded8255a50caf07e8c12061fd859f4b7c76ab704b17c957e842"
},
"id": "4fcb2ba4-ccdb-424f-89d5-26cce304bf9c",
"version": 3
}
- 키 스토어 형식은 brute-force, dictionary, rainbow table 공격으로 부터 방어하기 위해 key derivation function(KDF) 을 사용한다.
- 쉽게 말해서 개인 키를 비밀번호(passphrase)로 직접 암호화하지 않는 대신 비밀번호를 반복적으로 해싱하여 stretched 비밀번호를 사용한다.
- 해싱을 262,144번 반복한다. JSON 파일의
crypto.kdfparams.n파라미터에서 확인할 수 있다. - brute-force로 비밀번호를 알아내려는 공격자는 매 번 262,144번의 해싱을 해야하는데, 충분히 복잡하고 긴 비밀번호에 대해서 공격이 불가능 하도록 공격 속도를 늦춘다.
비결정적 지갑은 단순한 테스트 이 외에는 사용하는 것을 권장하지 않는다. 백업이 너무 성가시고 가장 기본적인 상황에 사용된다. 대신 산업표준기반의 백업용으로 니모닉 시드가 있는 HD 지갑을 사용하여라.
결정적[Deterministic(Seeded)] 지갑
- 결정적(Deterministic or "seeded") 지갑은 하나의 마스터 키(또는 시드)에서 유도(파생)된 모든 개인 키를 포함하고 있다.
- 시드는 랜덤하게 생성 된 숫자로 인덱스 번호 또는 "체인 코드"와 같은 다른 데이터와 조합되어 개인 키를 유도한다.
- 결정적 지갑 생성 시의 하나의 백업으로도 충분히 모든 유도 된 키를 복구할 수 있어서, 지갑의 모든 자금과 스마트 컨트랙트를 보호하는데 충분한다.
- 시드로 지갑 임포트, 익스포트를 할 수 있어서 쉽게 다른 지갑 간의 키 이동이 허용된다.
- 이러한 설계는 전체 지갑의 접근에 시드 하나만 필요하므로, 시드 보안을 가장 중요하게 만듭니다. 반대로 단일 데이터에만 보안 노력을 집중시킬 수 있어 이점으로 볼 수 있다.
계층 결정적[HD(Hierarchical Deterministic)] 지갑 (BIP-32/BIP-44)
- 결정적 지갑은 단일 시드에서 많은 키를 쉽게 유도하기 위해 만들어졌다.
- 현재 가장 진보한 형태의 결정적 지갑은 계층 결정적(HD) 지갑이다. (비트코인의 BIP-32 표준에 정의)
- HD 지갑은 트리 구조(부모 키가 연속 된 자식 키를 유도할 수 있고, 각각의 자식 키는 손자 키를 유도할 수 있음)의 유도 된 키를 포함하고 있다.
- HD 지갑은 단순한 결정적 지갑보다 몇 가지 장점이 있다.
- 첫째, 트리 구조는 추가적인 조직적 의미를 나타내는데 사용할 수 있다. 특정 서브 키의 브랜치는 입금을 위해 사용하고, 다른 브랜치는 출금의 잔돈 받기 위해 사용할 수 있다. 키 브랜치는 기업 설정에도 사용할 수 있다. 부서, 자회사, 특정 기능 또는 회계 카테고리를 다른 브랜치로 할당할 수 있다.
- 둘째, 사용자가 개인 키에 접근하지 않고도, 연속 된 공개 키를 생성할 수 있다는 것이다. 자금을 사용할 수 있는 개인 키를 지갑이 가지고 있지 않기 때문에, HD 지갑은 안전하지 않은 서버나 감시 전용 또는 수신 전용으로 사용할 수 있다.
시드와 니모닉 코드 (BIP-39)
- 개인 키의 안전한 백업과 복구를 위한 인코딩 방법은 여러가지가 있다. 현재 가장 선호하는 방법은 연속 된 단어를 이용하는 것으로, 올바른 순서로 단어를 입력하면 개인 키를 다시 만들 수 있다.
- 이것을 니모닉이라고 부르며, BIP-39에서 표준화 되었다.
- 요즘 많은 이더리움 지갑(다른 암호화폐 지갑도 마찬가지로)에서 이 표준을 사용한다. 호환 가능한 니모닉을 사용하여 백업과 복구를 위해 임포트, 익스포트 가능하다.
- 왜 이 방법이 널리 사용되지 있는지를 예제를 통해 알아보자.
결정적 지갑에 사용되는 시드
- 16진수 표현
FCCF1AB3329FD5DA3DA9577511F8F137- 니모닉 단어 12개
wolf juice proud gown wool unfair
wall cliff insect more detail hub
- 실제로 나열 된 16진수를 받아 쓸 때 오류가 발생할 확률은 허용할 수 없을 정도로 높다.
- 반대로 알려진 단어들의 목록을 다루는 것은 쉽다. 왜냐하면 단어(특히 영단어) 쓰기는 많이 반복 해봤기 때문이다. 만약 실수로 "inzect"가 기록되었다면, 지갑 복구를 위해서는 "inzect"는 유효하지 않은 단어이고 대신 "insect"를 사용해야 된다는 것을 빠르게 판단할 수 있다.
지갑의 좋은 예
- 암호화폐 지갑 기술이 성숙해지면서 폭 넓게 호환 가능하고, 사용하기 쉬우며, 안전하고 유연하게 만드는 산업 표준들이 등장했다.
- 이런 표준들은 지갑이 하나의 니모닉에서 다중의 다른 종류의 암호화폐 키를 유도하는 것을 허용한다.
- 일반적인 표준들
- Mnemonic code words, based on BIP-39
- HD wallets, based on BIP-32
- Multipurpose HD wallet structure, based on BIP-43
- Multicurrency and multiaccount wallets, based on BIP-44
- 향후 이런 표준은 변경되거나 폐기 될 수 있지만, 현재는 대부분의 블록체인 플랫폼과 그들의 암호화폐를 위한 de facto 지갑 표준으로서 사용되는 연동 기술 집합체이다.
- 이 표준은 광범위한 소프트웨어, 하드웨어 지갑에 사용되어 서로 연동할 수 있게 만들었다. 사용자는 이 지갑 중 하나에서 니모닉을 생성하고, 다른 지갑에서 임포트할 수 있으며, 모든 키와 주소를 복구할 수 있다.
- 이러한 표준을 지원하는 지갑의 예
- 소프트웨어 : Jaxx, MetaMask, MyCrypto, MyEhterWallet(MEW)
- 하드웨어 : Keepkey, Ledger, Trezor
니모닉 코드 단어 (BIP-39)
- 니모닉 코드 단어는 결정적 지갑을 유도하기 위한 시드로 사용되는 난수를 인코딩한 단어 나열이다. 이 나열 된 단어들은 시드를 다시 만들 수 있고, 그것으로 지갑과 모든 유도(파생) 된 키들을 다시 만들 수 있다.
- 니모닉 단어를 사용하는 결정적 지갑을 구현한 지갑 어플리케이션은 지갑을 처음 만들 때 12개에서 24개의 나열 된 단어들을 보여준다. 이 단어들의 나열이 지갑 백업이고 같거나 호환되는 지갑 어플리케이션에서 모든 키를 복구하고 다시 만드는데 사용된다.
NOTE
종종 니모닉 단어와 "브레인지갑(brainwallet)"를 헷갈려하는데, 이 두가지는 같은 것이 아니다. 가장 큰 차이점은 브레인지갑은 사용자가 선택한 단어들로 구성되고, 니모닉 단어는 지갑이 랜던하게 생성한 단어를 사용자한테 보여준다. 이 중요한 차이점이 니모닉 단어를 보다 더 안전하게 하는데, 왜냐하면 사람은 매우 좋지 않은 난수 생성 소스이기 때문이다.
- BIP-39에 정의 된 니모닉 코드와 시드 생성을 9단계에 걸쳐 설명하려한다. 명확하게 하기 위해 1 ~ 6 단계는 니모닉 코드 생성이고, 7 ~ 9 단계는 니모닉에서 시드 추출이다.
니모닉 코드 생성하기
1. 암호학적으로 랜덤한 128 ~ 256 bits의 시퀀스 S를 만든다. 2. S의 SHA-256 해시 값 중에서 앞(왼쪽)에서 S의 길이 / 32 bits 만큼을 체크섬으로 만든다. 3. 2번에서 만든 체크섬을 S의 끝에 추가한다. 4. 3번에서 만든 시퀀스와 체크섬의 연결을 11 bits 단위로 자른다. 5. 각 각의 11 bits를 2048(2^11)개의 미리 정의 된 단어로 치환한다. 6. 단어 시퀀스로부터 순서를 유지하면서 니모닉 코드를 생성한다.
엔트로피에 따른 니모닉 길이
- ENT : 초기 엔트로피의 길이
- CS : 체크섬의 길이
- MS : 생성 된 니모닉 시퀀스의 길이
CS = ENT / 32
MS = (ENT + CS) / 11
| ENT | CS | ENT+CS | MS |
+-------+----+--------+------+
| 128 | 4 | 132 | 12 |
| 160 | 5 | 165 | 15 |
| 192 | 6 | 198 | 18 |
| 224 | 7 | 231 | 21 |
| 256 | 8 | 264 | 24 |
니모닉에서 시드 추출
- 엔트로피는 키 스트레칭 함수 PBKDF2를 통해서 512 bits의 시드를 만드는데 사용된다.
- 키 스트레칭 함수는 니모닉과 솔트(salt)라는 두 개의 파라미터를 사용한다. salt의 목적은 brute-force 공격을 가능하게 하는 lookup table 생성을 힘들게 하는 것이다.
7. PBKDF2 키 스트레칭 함수의 첫번째 파라미터는 6번 단계에서 만든 니모닉이다. 8. 두번째 파라미터는 솔트이다. 솔트는 상수 문자열 "mnemonic"에 사용자가 지정한 암호문을 붙인 것이다. 9. PBKDF2는 니모닉과 솔트를 HMAC-SHA512로 2048번의 해싱해서 512 bits 값을 만들어 내는데, 이 값이 시드이다.
- 니모닉 코드와 암호문에 따른 시드 생성 예
128-bit entropy mnemonic code, no passphrase, resulting seed
- Entropy input (128 bits)
0c1e24e5917779d297e14d45f14e1a1a- Mnemonic (12 words)
army van defense carry jealous true garbage claim echo media make crunch- Passphrase
(none)- Seed (512 bits)
5b56c417303faa3fcba7e57400e120a0ca83ec5a4fc9ffba757fbe63fbd77a89a1a3be4c67196f57c39 a88b76373733891bfaba16ed27a813ceed498804c0570128-bit entropy mnemonic code, with passphrase, resulting seed
- Entropy input (128 bits)
0c1e24e5917779d297e14d45f14e1a1a- Mnemonic (12 words)
army van defense carry jealous true garbage claim echo media make crunch- Passphrase
SuperDuperSecret- Seed (512 bits)
3b5df16df2157104cfdd22830162a5e170c0161653e3afe6c88defeefb0818c793dbb28ab3ab091897d0 715861dc8a18358f80b79d49acf64142ae57037d1d54256-bit entropy mnemonic code, no passphrase, resulting seed
- Entropy input (256 bits)
2041546864449caff939d32d574753fe684d3c947c3346713dd8423e74abcf8c- Mnemonic (24 words)
cake apple borrow silk endorse fitness top denial coil riot stay wolf luggage oxygen faint major edit measure invite love trap field dilemma oblige- Passphrase
(none)- Seed (512 bits)
3269bce2674acbd188d4f120072b13b088a0ecf87c6e4cae41657a0bb78f5315b33b3a04356e53d062e5 5f1e0deaa082df8d487381379df848a6ad7e98798404
BIP-39의 선택적 암호문(passphrase)
- BIP-39는 시드 생성에 선택적 암호문 사용이 가능하다. 만약 암호문을 설정하지 않을 경우에는 기본적으로 솔트는 "mnemonic" 이라는 문자열을 사용한다.
- 니모닉과 암호문으로 만든 솔트를 이용해서 시드를 만들기 때문에 동일한 니모닉이라고 해도 암호문이 다르면 다른 시드를 만들게 된다.
- 선택적 암호문을 사용할 때 이점 : 암호문 없이 니모닉만 탈취되었을 때 쓸모 없게 된다.
- 선택적 암호문을 사용할 때 위험 : 암호문을 알고 있는 사람이 죽게 된다면 자산을 영원히 사용할 수 없다. 니모닉과 암호문을 같은 곳에 보관할 경우 암호문을 사용하는 의미가 없어진다.
시드로 부터 HD 지갑 만들기
- HD 지갑은 루트 시드라는 128, 256, 512 bits의 랜덤한 숫자에 의해 만들어진다.
- HD 지갑 안의 모든 키는 루트 시드로부터 파생되었기 때문에, 어떠한 호환 가능한 HD 지갑에서도 시드로 부터 재생산할 수 있다. 이 때문에 수 천 또는 수 백만개의 키를 가지고 있는 지갑을 쉽게 백업하고 복원하는 것이 쉽게 가능하다.
HD 지갑 (BIP-32)과 패스(Paths) (BIP-43/44)
확장된(extended) 공개 키와 개인 키
- BIP-32에서 정의한 용어로 키는 "확장 될(extended)" 수 있다. 확장 된 "부모" 키는 "자식" 키를 유도하는데 사용될 수 있다.
- 확장 된 키는 키 자체와 체인코드라는 것을 가지고 있다. 체인코드는 256 bits의 바이너리 문자열로 자식 키를 만들어내기 위한 각각의 키가 섞여져있다.
- 확장 된 개인키는 prefix에 의해 구분된다.
xprv:xprv9s21ZrQH143K2JF8RafpqtKiTbsbaxEeUaMnNHsm5o6wCW3z8ySyH4UxFVSfZ8n7ESu7fgir8i... - 확장 된 공개 키 역시 prefix에 의해 구분된다.
xpub:
xpub661MyMwAqRbcEnKbXcCqD2GT1di5zQxVqoHPAgHNe8dv5JP8gWmDproS6kFHJnLZd23tWevhdn - HD 지갑의 유용한 특징은 개인 키 없이 부모의 공개 키로부터 자식 키를 유도해 낼 수 있는 것이다. 이런 것이 가능하기 때문에 자식 공개 키를 만들 수 있는 방법은 두 가지가 된다. 첫번째는 자식 개인 키에서 만드는 방법. 두번째는 부모의 공개 키에서 만드는 방법.
- 예제 두 가지
- 이커머스 어플리케이션을 제공하는 웹 서버
- 콜드 저장소 또는 하드웨어 지갑용 어플리케이션. 확장 된 개인 키는 하드웨어 지갑에 저장하고, 확장 된 공개 키는 온라인 저장소에 저장한다.
강화 된(Hardened) 자식 키 유도
- Extended key의 단점 : 확장 된 공개 키는 체인코드를 포함하고 있어서 하나의 자식 개인 키가 유출될 경우 다른 모든 자식 개인 키를 유도해 낼 수 있다.
- HD 지갑은 강화 된 유도(hardened derivation)이라고 불리는 다른 유도 함수를 사용할 수 있다. 이것은 부모 공개 키와 자식 체인 코드의 관계를 끊었다.
- 이 방식은 자식 체인코드를 유도하는데 부모 공개 키 대신에 부모 개인 키를 사용한다.
일반, 강화 된 유도 방식의 인덱스 번호
- 주어진 부모 키에서 하나 이상의 자식 키를 유도할 수 있어야 한다. 이것을 관리하기 위해서 인덱스 번호를 사용한다.
- 일반 유도 방식과 강화 된 유도 방식을 쉽게 구분하기 위해서, 인덱스 번호를 두 범위로 나눴다.
- 일반 유도 방식의 인덱스 번호 : 0 ~ 2^31–1 (0x0 to 0x7FFFFFFF)
- 강화 된 유도 방식의 인덱스 번호 : 2^31 and 2^32–1 (0x80000000 to 0xFFFFFFFF)
first normal child key :
0
first hardened child key :0'
first hardened child key :1'
When you see an HD wallet indexi': 2^31 + i
HD 지갑 키 식별자 (path)
- HD 지갑의 키는 각 트리 레벨이
/로 나눠지는 "path" 명명 규칙을 사용해서 구별된다. - 마스터 개인 키로 부터 유도 된 개인 키들은
m으로 시작한다. 마스터 공개 키로 부터 유도 된 공개 키들은M으로 시작한다.m/0은 마스터 개인 키의 첫번째 자식 개인 키이다.M/0은 마스터 공개 키의 첫번째 자식 공개 키이다.m/0/1은 마스터 공개 키의 첫번째 자식의 두번째 자식(마스터 키 입장에선 손자)의 공개키 이다.
HD 지갑 path의 예
- m/0
The first (0) child private key of the master private key (m)- m/0/0
The first grandchild private key of the first child (m/0)- m/0'/0
The first normal grandchild of the first hardened child (m/0')- m/1/0
The first grandchild private key of the second child (m/1)- M/23/17/0/0
The first great-great-grandchild public key of the first great-grandchild of the 18th grandchild of the 24th child
HD 지갑 트리 구조 탐색
- HD 지갑 트리 구조는 대단히 유연하다. 이것의 또 다른면은 무한한 복잡성을 허용한다는 것으로, 각 확장 된 부모 키는 40억 개의 자식 키를 가질 수 있다. 20억 개의 일반 자식 키와 20억 개의 강화 된 자식. 그리고 그 각각의 자식 키는 또한 40억개의 자식 키를 가질 수 있다. 트리는 원하는 만큼 깊어질 수 있고, 잠재적으로 무한한 세대가 될 수 있다.
- 두 가지 BIP는 HD 지갑 구조의 표준을 만들어 잠재적인 복잡성을 관리 할 수 있는 방법을 제공한다. BIP-43은 트리 구조의 "목적"을 나타내는 특수 식별자로 첫 번째 강화 된 하위 인덱스를 사용하도록 제안한다. BIP-43을 기반으로 한 HD 지갑은 트리의 나머지 레벨의 구조와 네임 스페이스를 식별하여 지갑의 목적을 정의하는 인덱스 번호와 함께 트리의 레벨-1 브랜치만 사용한다. 좀 더 구체적으로 말하면,
m/i'/...브랜치만을 사용하는 HD 지갑은 특정 목적을 나타내기 위한 것이고 그 목적은 인덱스 번호i로 식별된다. - BIP-44는 이 스펙을 확장하여 "목적"번호를
44 '로 설정하여 다중 통화 다중 계정 구조를 제안한다. BIP-44 구조를 따르는 모든 HD 지갑은 트리의 하나의 브랜치 (m / 44 '/ *) 만 사용한다. - BIP-44는 미리 정의 된 다섯 단계의 트리 구조를 지정한다.
m / 목적' / 코인 종류' / 계정' / 잔돈 계정 여부 / 주소 인덱스
- level-1 : 목적은 항상
44'로 설정한다.- level-2 : 암호화폐 종류를 지정한다. SLIP0044 - 암호화폐 인덱스 매핑 정보
- level-3 : 사용자는 지갑을 회계 또는 조직 목적을 위한 별도의 논리적 하위 계좌로 세분 할 수 있다.
- level-4 : 잔돈. 비트코인에서는 수신 주소와 잔돈 주소(change address)가 따로 있는데, 이더리움은 수신 주소만 사용하므로 항상
0이다. 이전 레벨은 강화 된 유도를 사용했지만 이 레벨은 일반 유도를 사용한다. 이는 안전하지 않은 환경에서 사용할 수 있도록 확장 된 공개 키를 트리의 계정 수준에서 내보낼 수 있게 한다.- level-5 : 주소 인덱스. level-4에서 유도 된 자식 주소들의 인덱스
BIP-44 HD 지갑 구조 예시
M/44'/60'/0'/0/2 : The third receiving public key for the primary Ethereum account
M/44'/0'/3'/1/14 : The 15th change-address public key for the 4th Bitcoin account
m/44'/2'/0'/0/1 : The second private key in the Litecoin main account, for signing transactions
결론
지갑은 블록체인 어플리케이션과 사용자의 접점이다. 사용자가 키와 주소들을 관리할 수 있게 하며, 디지털 서명을 통해서 ether의 소유권을 증명하고 트랜잭션을 인증할 수 있다.