【前編】2025年版 EthereumデジタルID標準の進化とDIDの基礎 📜
はじめに: ブロックチェーンID標準のこれまでと今 🏁
ブロックチェーン上で「自分は自分である」と証明する方法は、この数年で劇的に進化しました。
2017～2018年頃、EthereumコミュニティはデジタルID管理のために数々のERC規格（ERC-725やERC-735など）を提案し、ブロックチェーン上に自己主権型アイデンティティを構築しようと試みました。
当時はユーザーごとにスマートコントラクトをデプロイしてIDを管理しよう！という豪快なアプローチで、複数の鍵によるマルチシグ制御や、他のコントラクトからも使えるプロキシとして機能する"デジタルIDコントラクト"が真面目に検討されていたのです。
加えて、そのIDに他者からの証明書(クレーム)を登録できる仕組み(ERC-735)まで提案され、発行者が署名した証明データをオンチェーンで保管する仕様も議論されました。ブロックチェーン上に運転免許証や会員証まで載せてしまおうという勢いです。
しかし2025年の現在、こうした初期のERC標準はすっかり影が薄くなり、代わりにW3Cが策定したDecentralized Identifiers (DID)標準が主役に躍り出ました。
分散型ID（DID）はブロックチェーンに限らず様々なネットワークで使える汎用仕様で、Ethereum由来の技術もこの潮流に乗っています。
さらにオフチェーンで証明（アテステーション）を扱う新手法や、アカウント抽象化(ERC-4337)によるウォレット機能強化など、周辺技術の進歩もめざましい状況です。
本記事では、ちょっとユーモラスな視点を交えつつ、Ethereum系デジタルID標準の進化と最新のブロックチェーン・デジタルIDインフラの現状をエンジニア向けに解説します。
初期のERC標準(725/735/780/1056/1484など)から、W3C DIDコア標準とその実装例（did:ethr, did:pkh, did:webなど）、オフチェーン証明の雄であるEthereum Attestation Service (EAS)、そしてアカウント抽象化(ERC-4337)や主要ツール(SpruceID, Veramo, Ceramic, EAS SDK)に至るまで幅広くカバーし、古い仕組みと最新アプローチをガス代・UX・相互運用性などの観点で比較します。
笑いあり（多分）、学びあり（きっと）のブロックチェーンIDの世界へ、いざ参りましょう！
昔々のEthereum ID標準たち (ERC-725/735/780/1056/1484) 🏛️
まずは昔ながらのEthereum ID標準を振り返ります。当時の提案たちをざっと紹介すると、どれも「ブロックチェーン上にアイデンティティ情報を載せて管理しよう」という発想で一貫していました。
ERC-725 (Identity)
スマートコントラクトを各ユーザーの「IDカード替わり」に見立てた規格です。このコントラクトはプロキシコントラクトとして動作し、複数の鍵や他のコントラクトによってコントロール可能でした。ユーザーは自分用にERC-725準拠コントラクトをデプロイし、その中に自分の公開鍵や許可する操作を登録できます。まさに自前のIDボックスをチェーン上に置くイメージですね。将来的にはこのIDコントラクトを使って、アクセス制御やウォレット代理操作（コントラクト経由でトランザクション実行）もできるぞ、という野心的な内容でした。
ERC-735 (Claim Holder)
ERC-725で作ったIDコントラクトに対し、他者からの証明書(クレーム)を追加・削除するためのインタフェース規格です。例えば、ある認証局が「あの人は年齢確認済みだよ」というクレームを発行し、ユーザーのERC-725コントラクトに書き込めるイメージです。クレームは発行者の署名付きデータであり、トピック（例えば「年齢確認」）ごとに格納されます。オンチェーン上で第三者発行の証明を保持・検証できる点は画期的でしたが、一方でクレーム内容が全て公開情報になってしまうためプライバシーの懸念もありました。
ERC-780 (Ethereum Claims Registry)
複数のユーザー間でクレームを共有利用できるようグローバルなクレーム登録台帳を定義した規格です。個別のIDコントラクト(ERC-725)ごとにクレームを抱え込むのではなく、誰でも使える単一のクレーム用コントラクトに発行者→対象アドレスへのクレームを書き込む形をとります。いわば公共図書館方式の証明書ストレージですね。これにより同じ発行者が複数ユーザーに証明を出す場合でも、一箇所で管理でき効率的…と言いたいところですが、やはりこちらも内容がオンチェーンに丸見えになる問題は解決せず、重要情報はゼロ知識証明やオフチェーンで扱わないと筒抜けになってしまうため、結局「これは一体何のためのオンチェーン化？」という本末転倒な状況も指摘されました。
ERC-1056 (Ethereum Lightweight Identity)
こちらは少し時代が下って2018年に提案された規格で、上記の重厚な仕組みを反省し「もっとシンプルに軽量ID管理をしよう」というコンセプトでした。ERC-1056ことEthereum DID Registryでは、「Ethereum上のすべてのアカウント（アドレス）はそれ自体がIDである」と定義し直しました。つまり、新たにスマートコントラクトをデプロイしなくても、Ethereumアドレスさえ作ればそれがIDになるという割り切りです。この規格ではひとつの共通レジストリコントラクト（EthereumDIDRegistry）をネットワークに1個だけデプロイし、全ユーザーはそこに対して自分の鍵情報（公開鍵の変更や委任情報など）を登録・更新します。ユーザーごとに個別コントラクトを持つ必要がないので、ID作成コストはゼロ（鍵ペアを生成するだけ）で済み、必要なときだけ鍵の更新や委任追加のトランザクションを発行すれば良いという「徹底した省エネ設計」です。ERC-1056は、既存のERC-725の反省から生まれたもので、ERC-725では何かと金のかかる(ガス代のかかる)スマコン作成が必要だった点に対し、アイデンティティ作成は無料であるべきという要件を掲げて設計されました。また、主要識別子（アドレス）を変えずに鍵のローテーションが可能であることや、オフチェーンでの利用も視野に入れることが明示されています。このERC-1056は後述のW3C DID仕様にも真っ向から準拠しており、EthereumにおけるDIDメソッド（後述するdid:ethr）のベースともなりました。
ERC-1484 (Digital Identity Aggregator)
こちらは少し変わり種で、複数のEthereumアドレスを一人のユーザーIDの下にまとめることを狙った規格です。要は人がアドレスをいっぱい持っていても一つのIDに紐付けられるようにし、複数の鍵（アドレス）に跨る統合管理や、アプリごとの使い分けを可能にしようという提案でした。グローバルなアイデンティティ番号(EIN: Ethereum Identification Number)を発行し、それに様々なアドレスを関連付ける形で「メタID」を作ろうとしたのです。「IDの上位にマスタIDを作る」という発想は一見便利そうでしたが、これを機能させるにはネットワーク上に専用の巨大なIDレジストリ(ERC-1484コントラクト)を永続稼働させる必要があり、またERC-725や1056との互換も図ろうとするなど設計が複雑でした。結果的に採用は限定的で、「発想は面白いが実験的段階に留まった」という評価に落ち着いています。
ざっと見てきたように、初期のEthereum ID標準は「何でもオンチェーンでやってしまえ」という力技が目立ちました。実装すれば確かに完全な分散ID基盤になり得ますが、逆に言えばオンチェーンにデータを載せすぎてプライバシーが心配、ガスコストが馬鹿にならない、標準ごとに互換性が乏しいなど、課題も山積みでした。
言うなれば、当時のこれらERC標準は「ブロックチェーンID界の黒歴史」…いえ、貴重な実験であり、この経験が後の進化につながったのです。
DIDコアの台頭: W3C標準とEthereum発のDIDメソッド 🌐
2019年以降、ブロックチェーンに限らず世界中で分散型アイデンティティ (Self-Sovereign Identity, SSI)への関心が高まる中、ついにW3C（ワールドワイドウェブ協会）が音頭を取ってDID標準の策定に乗り出しました。
こうして2022年7月、「Decentralized Identifiers (DID) v1.0」がW3C勧告（公式標準）として承認されました。
これはブロックチェーンID界にとって黒船襲来とも言える出来事で、各種ブロックチェーン毎にバラバラだったID方式が共通の土俵に上がった瞬間です。
DIDとは？ざっくりおさらい 📝
DID（分散型識別子）とは、did:example:123... のようなURI形式の識別子で、中央集権的な機関に頼らず永続的に使えるIDを表します。
各DIDはそれに対応するDIDドキュメントを持ち、公開鍵や認証方法、サービスエンドポイントなどを記載できます。
DID自体はただの識別子（文字列）ですが、それを解決(resolution)するとJSON形式のDIDドキュメントが得られ、そこから「このDIDを制御するにはこういう鍵で署名/認証せよ」といった情報がわかる仕組みです。
要するに「DID = 主体を指すID、DIDドキュメント = その主体の公開情報プロフィール」という関係になります。
DIDのミソは「DIDメソッド」と呼ばれる拡張ポイントにあります。
did:xxx:... の「xxx」に当たる部分がメソッド名で、各メソッドごとにDIDの生成・更新・削除方法(CRUD)が異なります。
例えば、DID文脈でEthereumを使いたい場合はそれ専用のメソッドを定義し、「Ethereum上のどのデータをもとにDIDドキュメントを構成するか」を決めます。
これによって、どんなブロックチェーンやシステムでも、それに見合ったDIDメソッドを定義すればDID標準に乗っかれるという柔軟性が生まれました。
現在、世の中には実に200種類以上のDIDメソッドが存在すると言われており、それらはW3C管理の登録リストにずらり並んでいます。
選び放題・作り放題の状況に「メソッドが多すぎて逆に分散しすぎ問題では？」との声もありますが、そこは業界が知恵を出し合い相互運用可能な標準作りを進めているところです（たとえばDIDメソッドを評価する「ルーブリック」策定や主要メソッドのガイドライン作り）。
Ethereum界隈のDID実装: did:ethr, did:pkh, did:web… 🔗
W3C DID標準が制定される以前から、Ethereumコミュニティも実験的に独自DIDメソッドを模索してきました。
その代表例が先述のERC-1056をベースにした did:ethr です。
did:ethrはEthereumアドレスをそのままDIDの一部として利用するメソッドで、たとえば did:ethr:0x1234...ABCD のようなDIDを生成できます。
解決方法は簡単で、Ethereum上のEthereumDIDRegistryコントラクト（ERC-1056で規定）に問い合わせることで、そのアドレスに紐づく公開鍵やコントローラ情報を取得しDIDドキュメントを構築するというものです。
鍵のローテーションや委任設定もERC-1056の機能として備わっているため、did:ethrではフルオンチェーン運用ながら効率的でプライバシーに配慮したID管理が可能です。
このメソッドはConsenSysのuPortプロジェクトなどで活用され、W3C DID標準にも完全準拠しているため国際相互運用性も確保されています。
言うなれば、did:ethr = Ethereum公式DIDといった存在感です。
続いて登場したのが did:pkh というメソッドです。
こちらはSpruceIDという企業/コミュニティが中心となり提唱したもので、「公開鍵ハッシュ (PKH)」に基づく汎用的なDIDメソッドとなっています。
did:pkhのキモは、Ethereumに限らずビットコイン等あらゆるブロックチェーンのアドレスをDID化できる点です。
例えばEthereumのアドレス0xABC...に対し、チェーンIDを指定して did:pkh:eth:1:0xABC... のようなDIDを作れます。
同様にビットコインなら did:pkh:btc:mainnet:1A1zP1... のような形式です。
did:pkhではブロックチェーンごとのアドレス標準(CAIP-10形式)を取り入れており、一種のブロックチェーン横断DIDメソッドと言えます。
技術的には「純粋ジェネレーティブ」なメソッド、つまりオンチェーンの追加データ参照を一切必要とせず、アドレスから機械的にDIDドキュメントを生成する方式を採っています。
そのためDID作成にトランザクション不要でガス代もゼロ、ユーザーは既存のウォレットアドレスだけで即席DIDを名乗れるお手軽さがウリです。
もっとも、did:pkhの弱点は鍵のローテーションや失効といった高度な機能が無いことです。
言い換えれば、did:pkhは「今持っている鍵」をそのままID化するだけで、あとから鍵を変えたくなったら別のDIDにするしかありません。
この点はトレードオフで、SpruceIDの提唱では「まずdid:pkhで素早くDIDデビューし、後で必要に応じてより機能豊富なDIDに"進化"すればよい（例: did:pkhのDIDを認証手段としてdid:ethrやdid:ionに紐付け直す）」という運用も想定されています。
まるでポケモンの進化みたいですが、ユーザーに新規登録の手間を強いることなく徐々にDIDを高度化できるのはUX上のメリットでしょう。
さらに did:web という異色のメソッドも普及してきました。
did:webはブロックチェーンを使わず、既存のWebインフラ(HTTPS)上でDIDドキュメントをホスティングするというアプローチです。
具体的には、所有するドメイン上に .well-known/did.json を置いておき、例えば did:web:example.com のDIDに対してはhttps://example.com/.well-known/did.json を取りに行く、といった仕組みです。
「中央集権ぽいじゃないか」という批判もありますが、Web上の既存信頼（DNSや証明書）を活用することで導入コストを下げる現実的な方法として注目されています。
特に企業や政府が既存のWeb認証基盤とDIDを橋渡しする用途でdid:webを採用する例が増えています。
これはWeb2.0からWeb3.0へのスムーズな橋渡し役とも言えるでしょう。
他にもEthereum関連では、ENS(Ethereum Name Service)と紐付けた did:ens や、ERC-1056＋チェーン間アブストラクションから発展した did:pkh のようなマルチチェーン対応メソッド、さらにはConsenSysやSpruceIDが携わったDID規格実装ライブラリなどが登場しています。
2025年現在、Ethereumエコシステムのアイデンティティ管理はこれらDIDメソッドを中心に据え、「必要最低限だけオンチェーン、肝心のデータはオフチェーン」という設計思想に移行しました。
初期ERC時代に比べると、ガス代節約とプライバシー保護を両立しつつ、他チェーンや他システムとも連携可能な形に洗練されたと言えます。
ここまでがEthereum ID標準の歴史とDIDの基礎的な解説です。
次回は、現代のEthereum ID技術の中心となるオフチェーン証明、アカウント抽象化、そしてエコシステムを支える主要ツールについて深掘りしていきます！お楽しみに！
続きを読む
NONENTROPY JAPAN株式会社は、Blockchain、IPFS、DID/VC、生成AIなどを活用し、Web3時代の信頼を支える技術を開発しています！技術情報を中心に投稿します！
Discussion