VC とブロックチェーンの関係
「VC = ブロックチェーン」という誤解がありますが、実際は異なります。このドキュメントでは、VC とブロックチェーンの関係を整理します。
まず結論：ブロックチェーンは必須ではない
よくある誤解:
「VC はブロックチェーン技術」
「VC を使うにはブロックチェーンが必要」
実際:
VC = デジタル署名技術
ブロックチェーンは「オプションの1つ」に過ぎない
VC の本質は「署名付き JSON」です。 ブロックチェーンがなくても、デジタル署名があれば検証可能です。
VC のどこにブロックチェーンが使われうるか
┌─────────────────────────────────────────────────────────────┐
│ Verifiable Credential │
│ │
│ issuer: "did:ethr:0x..." ◄─── DID がブロックチェーン上 │
│ （オプション） │
│ │
│ credentialSubject: { ... } ◄─── VC 本体をブロックチェーンに │
│ 記録する場合もある │
│ （公開情報の場合） │
│ │
│ credentialStatus: ◄─── 失効リストがブロックチェーン│
│ statusListCredential 上（オプション） │
│ │
│ proof: { ... } ◄─── ブロックチェーンのトランザ │
│ クション自体が proof になる │
│ 場合もある │
└─────────────────────────────────────────────────────────────┘
| 部分 | ブロックチェーンを使う？ |
|---|---|
| DID（issuer 等） | △ 使う場合もある |
| VC 本体 | △ 公開証明書の場合は使う |
| 署名（proof） | △ トランザクション署名を使う場合も |
| 失効リスト | △ 使う場合もある |
| 信頼レジストリ | △ 使う場合もある |
DID メソッドとブロックチェーン
DID（Decentralized Identifier）には様々な「メソッド」があり、ブロックチェーンを使うものと使わないものがあります。
ブロックチェーンを使わない DID
| メソッド | 基盤 | 特徴 |
|---|---|---|
did:web | Web サーバー | 最も実用的。DNS + HTTPS で信頼 |
did:key | なし | 公開鍵から導出。解決不要 |
did:jwk | なし | JWK から導出。did:key の JWK 版 |
did:web の例:
did:web:university.example.com
│
▼
https://university.example.com/.well-known/did.json
│
▼
{
"id": "did:web:university.example.com",
"verificationMethod": [{
"id": "did:web:university.example.com#key-1",
"publicKeyJwk": { ... }
}]
}
→ 通常の Web サーバーで DID Document をホスト
ブロックチェーンを使う DID
| メソッド | 基 盤 | 特徴 |
|---|---|---|
did:ethr | Ethereum | スマートコントラクトで管理 |
did:ion | Bitcoin（Layer 2） | Microsoft 開発、Sidetree プロトコル |
did:indy | Hyperledger Indy | エンタープライズ向け |
did:pkh | 各種チェーン | 既存のウォレットアドレスを活用 |
did:ethr の例:
did:ethr:0x123abc...
│
▼
Ethereum のレジストリコントラクト
│
▼
公開鍵やサービスエンドポイントを取得
なぜブロックチェーンなしでも動くのか
VC 検証に必要なもの
VC の検証に必要なのは:
1. 発行者（issuer）の公開鍵
2. その公開鍵で署名を検証
公開鍵をどこから取得するかは自由:
- Web サーバー（did:web）
- ブロックチェーン（did:ethr）
- DID 自体に埋め込み（did:key）
どれでも「署名検証」という本質は同じ
具体的な比較
did:web（ブロックチェーンなし）:
1. issuer: "did:web:university.example.com"
2. https://university.example.com/.well-known/did.json を取得
3. DID Document から公開鍵を抽出
4. VC の署名を検証
5. 有効/無効を判定
did:ethr（ブロックチェーンあり）:
1. issuer: "did:ethr:0x123..."
2. Ethereum のレジストリコントラクトにクエリ
3. 公開鍵を取得
4. VC の署名を検証
5. 有効/無効を判定
どちらも「公開鍵を取得 → 署名検証」は同じです。
ブロックチェーン証明書（Blockchain Credentials）
VC 本体をブロックチェーンに記録するユースケースもあります。
代表的なプロジェクト
| プロジェクト | 説明 |
|---|---|
| Blockcerts | MIT が開発。学位証明書をブロックチェーンに記録 |
| OpenCerts | シンガポール政府。教育証明書 |
| ERC-721/1155 NFT | 資格やメンバーシップを NFT として発行 |
| Soulbound Token (SBT) | 譲渡不可の NFT として証明書を発行 |
仕組み
ブロックチェーン証明書の発行:
1. 発行者が証明書データを作成
{
"recipient": "0x123...",
"degree": "Bachelor of Science",
"date": "2024-03-25"
}
2. データのハッシュをブロックチェーンに記録
または
データ全体をブロックチェーンに記録（NFT の場合）
3. トランザクションがブロックに含まれる
→ ブロックチェーン自体が「proof」になる
検証:
- ブロックチェーンのトランザクションを確認
- 発行者のアドレスから発行されたことを確認
- データのハッシュが一致することを確認
Blockcerts の例
{
"@context": [
"https://w3id.org/blockcerts/v3"
],
"type": ["VerifiableCredential", "BlockcertsCredential"],
"issuer": "did:ion:EiA...",
"issuanceDate": "2024-03-25T00:00:00Z",
"credentialSubject": {
"id": "did:example:recipient",
"name": "山田太郎",
"degree": "Bachelor of Science in Computer Science"
},
"proof": {
"type": "MerkleProof2019",
"merkleRoot": "0x1234...",
"targetHash": "0x5678...",
"anchors": [{
"sourceId": "0xabcd...",
"type": "ETHData",
"chain": "ethereumMainnet"
}]
}
}
NFT / Soulbound Token として発行
NFT 証明書:
┌─────────────────────────────────────────┐
│ ERC-721 NFT │
│ │
│ tokenId: 12345 │
│ owner: 0x789... │
│ metadata: │
│ name: "Computer Science Degree" │
│ issuer: "Example University" │
│ recipient: "山田太郎" │
│ date: "2024-03-25" │
│ │
│ ※ 譲渡可能（売買できてしまう問題） │
└─────────────────────────────────────────┘
Soulbound Token (SBT):
┌─────────────────────────────────────────┐
│ Soulbound Token │
│ │
│ 同様の構造だが: │
│ - 譲渡不可（transfer 禁止） │
│ - 受取人に紐づく │
│ │
│ ※ 学位や資格は譲渡できないのが自然 │
└─────────────────────────────────────────┘
ブロックチェーン証明書の使い分け
| ユースケース | 適している | 適していない |
|---|---|---|
| 公開してよい証明書 | ✅ 学位、資格、受賞歴 | - |
| 個人情報を含む | - | ❌ 住所、生年月日等 |
| 永続的な記録が必要 | ✅ 歴史的記録 | - |
| 失効・更新が頻繁 | - | ❌ 運転免許証等 |
| 匿名性が必要 | - | ❌ 誰が持っているかわかる |
W3C VC との関係
ブロックチェーン証明書は W3C VC の一種:
W3C VC Data Model
│
├── JSON-LD + Data Integrity Proof
│
├── JWT VC
│
├── SD-JWT VC
│
└── Blockchain Credentials ← ここ
├── Blockcerts
├── OpenCerts
└── NFT/SBT ベース
proof の部分がブロックチェーンへのアンカーになる
ブロックチェーンを使うメリット・デメリット
メリット
| メリット | 説明 |
|---|---|
| 単一障害点なし | サーバーがダウンしても DID は解決可能 |
| 改ざん耐性 | 過去の履歴が変更不可 |
| 中央管理者不要 | 誰かに依存しない |
| 永続性 | 運営者が消えても存続 |
デメリット
| デメリット | 説明 |
|---|---|
| コスト | トランザクション手数料（ガス代）が必要 |
| 速度 | ブロック確認に時間がかかる |
| 複雑さ | ノード運用、ウォレット管理が必要 |
| スケーラビリティ | 大量の DID 操作に向かない場合も |
| 取り消し困難 | 間違いも永久に残る |
| プライバシー | 公開データは誰でも見られる |
ユースケース別の選択
政府系 ID（mDL、国民 ID）
選択: ブロックチェーンを使わない
理由:
- 既存の PKI（X.509）インフラを活用
- 政府が信頼のアンカー
- ブロックチェーンの複雑さを避けたい
- 法的な責任の所在を明確にしたい
使用例:
- ISO 18013-5 mDL
- EU eIDAS 2.0
企業向け（従業員証明、資格証明）
選択: did:web または did:key
理由:
- 既存の Web インフラを活用
- 導入が容易
- IT 部門が管理可能
- コストが低い
使用例:
- 従業員 ID
- 取引先認証
- サプライチェーン証明
Web3 / DeFi
選択: did:ethr, did:pkh
理由:
- 既存のウォレット（MetaMask 等）を活用
- ブロックチェーンネイティブ
- 分散型を重視するユーザー
使用例:
- DAO メンバーシップ
- NFT 関連の証明
- DeFi の KYC
学術・研究
選択: ケースバイケース
考慮点:
- 大学は did:web で十分な場合が多い
- 国際的な相互運用性が必要な場合は標準に従う
- 長期保存が必要な場合はブロックチェーンも検討
現実の採用状況
ブロックチェーンを使わない例
| プロジェクト | DID メソッド | 備考 |
|---|---|---|
| EU eIDAS 2.0 | 未定（PKI ベース想定） | EU 全体のデジタル ID |
| 米国 mDL | PKI ベース | 各州で実装中 |
| 日本の実証実験 | 各種 | ブロックチェーン非依存が多い |
ブロックチェーンを使う例
| プロジェクト | 用途 | 備考 |
|---|---|---|
| Microsoft ION | DID | Bitcoin Layer 2, did:ion |
| Ethereum エコシステム | DID | Web3 ネイティブ, did:ethr |
| Hyperledger Indy | DID + VC | エンタープライズ |
ブロックチェーン証明書の例
| プロジェクト | 用途 | 備考 |
|---|---|---|
| Blockcerts | 学位証明書 | MIT 開発、Bitcoin/Ethereum |
| OpenCerts | 教育証明書 | シンガポール政府 |
| POAP | イベント参加証明 | NFT ベース |
| Galxe | Web3 クレデンシャル | NFT/SBT ベース |
よくある質問
Q: ブロックチェーンを使わないと「分散型」ではない？
A: 「分散型アイデンティティ」の「分散」は、ブロックチェーンを意味しません。
「分散型」の意味:
❌ 「ブロックチェーン上にある」
✅ 「中央の ID プロバイダに依存しない」
「ユーザーが自分の ID を管理できる」
did:web でも、ユーザーが自分の DID を管理し、複数の発行者から VC を受け取れるなら「分散型」と言えます。
Q: VC 本体をブロックチェーンに保存すべき？
A: ユースケースによります。
個人情報を含む VC（運転免許証、住所等）:
❌ ブロックチェーンに保存しない
- 個人情報が公開される
- プライバシーが失われる
- GDPR 等の規制に違反する可能性
→ Wallet に保存し、必要な時だけ提示
公開してよい証明書（学位、資格、受賞歴）:
✅ ブロックチェーンに保存してもよい
- 永続的な記録として価値がある
- 発行者が消えても検証可能
- 改ざん防止
→ Blockcerts, NFT/SBT として発行
Q: ブロックチェーンを使うと偽造できない？
A: ブロックチェーンの有無と偽造防止は関係ありません。
偽造を防いでいるのは:
✅ デジタル署名（暗号技術）
ブロックチェーンの役割:
- DID Document の保管場所
- 改ざん履歴の防止
- 失効情報の管理
署名の偽造防止とは別の話
Q: 将来的にはブロックチェーン必須になる？
A: 現時点では、そのような方向には進んでいません。
主要な標準化団体の方針:
W3C: DID メソッドは複数あり、特定の基盤を強制しない
ISO: mDL はブロックチェーン非依存
OpenID: OID4VC はブロックチェーン非依存
むしろ「基盤に依存しない」方向
選択のガイドライン
ブロックチェーンを使うべき場合:
✅ 単一の管理者を置きたくない
✅ 永続的な記録が必要
✅ Web3 エコシステムとの統合
✅ 既存のブロックチェーンウォレットを活用したい
ブロックチェーンを使わなくてよい場合:
✅ 既存の PKI / Web インフラを活用したい
✅ シンプルな実装を優先
✅ コストを抑えたい
✅ 政府・企業が信頼のアンカーになれ る
✅ 規制対応（責任の所在を明確に）
まとめ
┌─────────────────────────────────────────────────────────────┐
│ │
│ VC とブロックチェーンの関係: │
│ │
│ 1. VC にブロックチェーンは必須ではない │
│ │
│ 2. ブロックチェーンが使われるのは主に: │
│ - DID の管理 │
│ - 失効リスト │
│ - 信頼レジストリ │
│ │
│ 3. VC 本体はブロックチェーンに保存しない │
│ （プライバシーのため） │
│ │
│ 4. ユースケースに応じて選択 │
│ - 政府 ID: PKI ベース（ブロックチェーンなし） │
│ - 企業: did:web（ブロックチェーンなし） │
│ - Web3: did:ethr 等（ブロックチェーンあり） │
│ │
└─────────────────────────────────────────────────────────────┘