ERC-7908 자금 관리용 HD 지갑 경로 표준 (HD wallet In Treasury Management)

Final · 계정·지갑 · 2025-03-07 작성

기업이 마스터 키 하나에서 자회사·부서별로 격리된 이더리움 계정을 정해진 규칙으로 파생하는 HD 지갑 경로를 정합니다. 그룹 통합 관리와 부서 간 권한 분리를 동시에 할 수 있습니다.

왜 필요한가

블록체인과 디파이(DeFi)가 빠르게 성장하면서 기업이 온체인 자산을 직접 관리하는 일이 중요해졌습니다. 그런데 개인키를 계정마다 따로 만들어 보관하는 전통적인 방식은 큰 조직의 복잡한 요구를 채우기 어렵습니다. 자회사와 부서가 여럿인 그룹에는 계층적인 키 관리, 권한 통제, 다중 서명 같은 장치가 꼭 필요한데, 공통 규칙이 없으면 조직마다 키를 제각각 관리하게 되고 부서 사이의 권한 경계도 흐려집니다. 감사를 하려 해도 어떤 키가 어느 부서 것인지 체계적으로 추적할 방법이 없습니다. 이 표준은 하나의 마스터 키에서 자회사와 부서별 계정을 통일된 경로로 파생하는 방법과 보안 요건을 정해, 여러 체인을 쓰는 환경에서도 자산 보안과 거래 효율을 함께 확보하는 해법을 제시합니다.

심층 설명

파생 경로 구조

구현은 반드시 m/44'/60'/entity_id'/department_id'/account_index 경로를 사용해야 합니다. m은 루트 HD 지갑 개인키이고, 44'는 BIP 44 준수를 나타내는 강화(hardened) 계층, 60'은 이더리움과 EVM 호환 체인용 코인 타입입니다. entity_id'는 자회사 이름을 해시해 만든 강화 인덱스로, 서로 다른 자회사가 같은 값을 재사용해서는 안 됩니다. department_id'도 부서 이름을 해시한 강화 인덱스이며, 강화 파생으로 부서 간 키를 격리해야 합니다. 마지막 account_index만 비강화 파생을 써서 통합 계정 관리를 허용합니다. 이더리움은 UTXO가 아닌 계정 모델이므로 BIP 44의 change 계층은 생략하는 것이 좋습니다.

이름을 인덱스로 바꾸는 해시 변환

entity_id는 문자열 "ENTITY:{entity}"를 SHA-256으로 해시한 뒤 앞 4바이트를 빅엔디언 정수로 읽고 0x80000000과 OR 연산해 계산합니다. department_id는 "DEPT:{entity_hash}:{department}"를 같은 방식으로 해시해 계산합니다. 부서 해시 입력에 자회사 해시가 들어가므로 같은 부서 이름이라도 자회사가 다르면 다른 인덱스가 나옵니다. 생성된 인덱스는 반드시 2^31 이상 2^32-1 이하의 정수여야 하며, 이 범위가 강화 파생을 강제합니다.

역할 기반 접근을 위한 확장 경로

부서 안에서 역할별로 더 세밀한 접근 통제가 필요하면 m/60'/entity_id'/department_id'/role_id'/account_index 경로를 쓸 수 있습니다. role_id'는 강화 파생을 써서 역할별 키를 격리하는 것이 좋습니다. 다만 이 경로는 44' 계층을 생략하므로 MetaMask 같은 표준 지갑과 호환되지 않을 수 있고 그런 지갑과 연동하려면 반드시 이 차이를 처리하는 커스텀 플러그인을 구현해야 합니다.

소규모 조직용 단순 경로

자회사가 없는 조직은 m/44'/60'/department_id'/0/account_index 형태의 단순 경로를 쓸 수 있습니다. 이 구조는 주류 BIP 44 지갑과의 호환성을 보장하는 것이 좋다고 명시되어 있습니다. 전체적으로 이 표준은 BIP 44의 5계층 구조(m/purpose'/coin_type'/account'/change/address_index)에서 착안했지만 이더리움 기반 시스템에서는 change 계층을 쓰지 않아야 하고 조직 필요에 따라 5계층을 넘는 계층 확장을 허용합니다.

키 파생 알고리즘 요건

키 파생은 secp256k1 곡선 위에서 공식 BIP 32 파생 함수를 사용해야 합니다. 원문 의사코드는 조직을 자회사와 부서 목록의 맵으로 두고 경로로 루트 키를 만든 뒤 각 조직에 대해 루트 키와 계층 해시 인덱스를 연결(concatenate)해 SHA-256으로 해시한 값을 키로 씁니다. 해시를 루트 키와 연결하는 이유는 계층 사이의 키 유출을 막기 위해서이며 이는 필수 요건입니다. 이 표준은 BIP 39, BIP 32, BIP 44를 준수합니다.

네 가지 활용 시나리오

원문은 네 가지 적용 시나리오를 듭니다. 첫째, 그룹 내 자회사와 부서마다 격리된 온체인 계정을 만들고 강화 파생으로 노출 위험을 차단합니다. 둘째, 그룹 관리자가 마스터 개인키를 쥐고 모든 자회사 개인키를 파생해 그룹 전체의 조회·거래 최고 권한을 갖습니다. 셋째, 자회사 A의 관리자 Alice가 새 관리자 Bob에게 자회사 A의 마스터 개인키만 공유하면 각 부서 계정을 모두 파생할 수 있습니다. 넷째, 감사 부서에 특정 부서의 확장 공개키를 공유하면 하위 공개키를 모두 파생해 그 주소들의 거래를 추적할 수 있습니다. 참조 구현은 파이썬으로 계정 생성, 감사용 확장 공개키 조회, 부서 격리, 확장 개인키 공유를 시연합니다.

쓸 때 주의할 점

ERC 원문 · ← ERCs