# [ERC1581] ブロックチェーン外でも使える鍵管理の仕組みを理解しよう！

> ERC1581では、BIP32によって定義された「階層的な鍵生成方式（HD鍵：Hierarchical Deterministic key）」を活用し、ブロックチェーンの外側でも使用できる鍵の体系的な運用方法を提案しています。

- URL: https://cardene.dev/articles/607c58ca12187848b410
- 公開日: 2025-08-04
- 更新日: 2025-08-04
- トピック: Blockchain
- タグ: ethereum, solidity, smartcontract, ブロックチェーン

## はじめに

『DApps開発入門』という本や色々記事を書いているかるでねです。

https://amzn.asia/d/gxvJ0Pw

今回は、ウォレットと同じマスター鍵から、ブロックチェーン外でも安全に使える専用鍵を分岐して管理できる仕組みを提案している**ERC1581**についてまとめていきます！

:::message
以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。
:::

https://eips.ethereum.org/EIPS/eip-1581

他にも様々なEIPについてまとめています。

https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4

## 概要

**ERC1581**では、BIP32によって定義された「**階層的な鍵生成方式（HD鍵：Hierarchical Deterministic key）**」を活用し、ブロックチェーンの外側でも使用できる鍵の体系的な運用方法を提案しています。
BIP32およびBIP44は主に暗号資産ウォレットのための鍵の管理方式として知られていますが、**ERC1581**ではそれらと共存可能な形で、同じマスター鍵から派生する新たな「**鍵の論理的ツリー構造**」を設けることで、ブロックチェーン外の用途にも安全かつ便利に対応する方法を定義します。

:::message
簡単に言えば、既存のウォレットの鍵と同じマスター鍵から、安全に別の用途（例：認証、暗号化、メッセージ署名など）向けの鍵を分離して運用できるようにする提案です。
:::

## 動機

ブロックチェーンと連携する多くのアプリケーションは、ブロックチェーン以外の技術（例えば、オフチェーンデータ処理や独自の認証システムなど）も組み合わせて動作しています。
こうしたアプリケーションでは、プライバシーやセキュリティの観点から複数の鍵を使用する必要があります。

ただし、ウォレットに使われる鍵をそのまま他の用途に再利用すると、セキュリティ上のリスクが生じます。
一方で、完全に別の鍵を用意してしまうと、バックアップや移行の手間が増し、ユーザーの管理負担が大きくなります。

このジレンマを解決するために、BIP44互換のウォレットとは別の「**鍵の派生ブランチ**」を定義することで、安全性と利便性の両立を目指しています。
つまり、同じマスター鍵を使いながらも用途ごとに鍵を分けて運用でき、しかもバックアップや移行は1つのマスター鍵だけで済むようになります。
これにより、アプリケーションは柔軟に独立した鍵を持ちながら、ユーザーの操作性も損なわずに済むというメリットがあります。

## 仕様

### パス構造の概要

**ERC1581**では、鍵を階層的に管理するためにBIP32パス構造を使用しています。
具体的なパスの形式は以下のようになっています。

```
m / purpose' / coin_type' / subpurpose' / key_type' / key_index
```

ここで、各レベルの末尾に付いているアポストロフィ（'）は「**hardened derivation**」と呼ばれる安全性の高い派生方法を使っていることを意味します。
これはBIP32における仕様で、親の公開鍵から子の秘密鍵を推測されないようにするための仕組みです。

このパス構造は、BIP43で提案された方法に準拠しており、Ethereumなどの非Bitcoin用途にも拡張可能な形式です。
各レベルの役割について以下で説明します。

### Purpose / Coin Type / Subpurpose

パスの最初の3つのレベルは固定値で構成されます。

```
m / 43' / 60' / 1581'
```

* `43'` は、BIP43に準拠した用途であることを示します。
* `60'` はEthereumのコインタイプ（`coin_type`）です。
* `1581'` は**ERC1581**独自の識別子（`subpurpose`）であり、Ethereum内でこの仕様に基づく鍵であることを示します。

この3レベルの下にあるサブツリーすべてが、**ERC1581**の対象範囲になります。

### Key Type（鍵の用途）

4番目のレベルでは、その鍵がどのような用途に使われるかを定義します。
例えば「**メッセージ送信（instant messaging）**」など、汎用的な目的に基づいた分類が推奨されます。

この理由は、サービス固有の名称（例：Whisperなど）ではなく、異なるサービス間でも同じキータイプで同じアイデンティティを使い回せるようにするためです。
将来的にはこの「key type」は標準化される予定です。

このレベルも**hardened derivation**が使われます。

### Key Index（鍵の識別子）

5番目のレベルは、特定の鍵を一意に識別するためのインデックスです。
最も単純なケースでは、`0` から `2^31-1` の整数値を使います。

もしもっと大きな値（例えば128ビットのGUIDやハッシュ値）を使いたい場合は、複数のレベルに分割して格納します。
各レベルは31ビット分の情報を持ち、最上位ビットから左詰めで配置します。
その際のルールとして、以下のようになります。

* 最後のレベル（最下位）は「**公開派生（public derivation）**」を使用します。
* それ以外のレベルはすべて「**hardened derivation**」を使用します。

たとえば、`key_type` が `4'` であり、62ビットのインデックス値 `0x2BCDEFFEDCBAABCD` を使う場合、分割されたパスは次のようになります。

```
m / 43' / 60' / 1581' / 4' / 1469833213' / 1555737549
```

このようにすることで、非常に大きな識別子やランダムに生成された値（例：GUID）もパスとして扱うことができ、セキュアかつ体系的に鍵を管理できます。
特にGUIDのような128ビットの識別子を使う場合は、32ビット単位に分割し、それぞれの最上位ビットを「**hardened**」を意味するように設定（最終レベル以外）すれば、安全性を確保しつつ再現性のあるパス構造を実現できます。

## 引用

Michele Balistreri (@bitgamma), "ERC-1581: Non-wallet usage of keys derived from BIP-32 trees [DRAFT]," Ethereum Improvement Proposals, no. 1581, November 2018. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-1581.

## 最後に

今回は「ウォレットと同じマスター鍵から、ブロックチェーン外でも安全に使える専用鍵を分岐して管理できる仕組みを提案している**ERC1581**」についてまとめてきました！
いかがだったでしょうか？

質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！

[Twitter @cardene777](https://twitter.com/cardene777)

他の媒体でも情報発信しているのでぜひ他も見ていってください！

https://chaldene.net/

https://zenn.dev/heku

https://cardene.substack.com/

https://mirror.xyz/0xcE77b9fCd390847627c84359fC1Bc02fC78f0e58

https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4