# [ERC780] オンチェーンでの証明情報管理の仕組みを理解しよう！

> Ethereum Claims Registry（ECR）は、Ethereum上で「誰が、誰に対して、どのような主張（クレーム）をしているか」を一元的に記録・参照できる仕組みを提供する提案です。

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

## はじめに

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

https://amzn.asia/d/gxvJ0Pw

今回は、あるアカウントが別のアカウントに関して発行する情報（例：本人確認済み、所属組織など）をブロックチェーン上に記録・参照できる共通レジストリである、Ethereum Claims Registry（ECR）の仕組みを提案している**ERC780**についてまとめていきます！

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

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

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

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

## 概要

Ethereum Claims Registry（ECR）は、Ethereum上で「**誰が、誰に対して、どのような主張（クレーム）をしているか**」を一元的に記録・参照できる仕組みを提供する提案です。
この主張には、他者によるものだけでなく、自分自身に関する自己発行のクレーム（self-issued claim）も含まれます。

このレジストリの特徴は、Ethereum上のアカウントの種類（Externally Owned AccountやSmart Contract Account）に関係なく、同じようにクレームを発行・登録・参照できる柔軟な設計になっている点です。
つまり、人間、スマートコントラクトなど、あらゆるEthereumアカウントが、相互にクレームを発行しあうことが可能です。

この仕組みにより、Ethereumブロックチェーン上における信頼と認証の基盤として、さまざまなユースケースに対応できる中心的なレジストリの役割を果たすことを目指しています。

## 動機

Ethereumにおいて、あるユーザーやコントラクトの属性情報（例えばKYC済みかどうか、特定のロールを持っているかどうかなど）を検証したいというニーズが高まっています。
これまでは、各コントラクトが独自に署名の検証や鍵の管理を行う必要があり、煩雑かつガスコストが高くなる傾向がありました。

ECRの導入により、こうした問題を解消し、以下のような利点を提供します。

* クレーム情報を一元管理することで、検証のための外部コールが1回で済むようになり、処理がシンプルかつガス効率の高いものになります。
* 各スマートコントラクトが独自にクレーム管理機能を実装しなくても、標準化されたレジストリを参照するだけで済むため、開発が効率化されます。
* 統一された形式により、異なるアプリケーション間での相互運用性（interoperability）が高まります。
* 自己発行クレームをサポートすることで、自己主権型ID（Self-Sovereign Identity）のような応用にも対応可能です。

このように、ECRは「**Ethereum上での信頼情報を標準化された方法で取り扱うための共通基盤**」としての役割を果たすことを目指しています。
これは単なる属性検証にとどまらず、DAO、DeFi、NFTなど多様な分野で活用可能な柔軟な土台を提供する提案です。

## 仕様

Ethereum Claims Registry（ECR）は、一度デプロイされればEthereum上の誰でも共通に利用できる「**クレーム（主張）情報の記録・参照**」のためのコントラクトです。
この仕組みにより、アカウント同士が属性情報を発行し合い、それを他者がシンプルかつ効率的に確認できるようになります。
コントラクトの構造はシンプルで汎用性が高く、将来の拡張性にも配慮された設計となっています。

### クレームの構造と用途

クレームは「**発行者（issuer）**」が「**対象（subject）**」に対して何らかの主張（claim）を行う形式で登録されます。
クレームの内容は以下の3つの要素で構成されます。

* `key`（クレームの種類を示す識別子。`bytes32`型）
* `value`（主張される内容そのもの。`bytes32`型）
* `issuer`と`subject`（Ethereumアドレス）

例えば「**AさんがBさんを『本人確認済み（KYC済み）』と主張する**」といった情報が登録できます。

### クレームの分類（Claim types）

クレームの`key`には、クレームの種類（例えば「Owner-Address」や「Age」など）を特定するための識別子が使われます。この識別子は`keccak256()`でハッシュ化され、32バイトの固定長に変換されて保存されます。

`key`の使い方には以下の3種類が推奨されています。

* **標準化クレーム**
    HTTPライクな形式で、`X-`で始まらない（例: `'Owner-Address'` → `keccak256`でハッシュ）
* **プライベートクレーム**
    他と共有しない用途向け。
    `X-`で始める（例: `'X-My-Thing'`）
* **アドホッククレーム**
    完全にランダムな32バイト値を使用。
    標準化不要な一時的な用途に使われます。

### 主な関数仕様

ECRは、クレームの発行・取得・削除のための以下の関数を提供しています。

#### `setClaim`

他のアカウント（subject）に対するクレームを発行・更新します。
呼び出し元が自動的に`issuer`になります。

```javascript
function setClaim(address subject, bytes32 key, bytes32 value) public
```

#### `setSelfClaim`

自分自身に対するクレームを発行します。
内部的には`setClaim`を呼び出します。

```javascript
function setSelfClaim(bytes32 key, bytes32 value) public
```

#### `getClaim`

指定された発行者・対象・クレーム種別に対応する`value`を取得します。
読み取り専用です。

```javascript
function getClaim(address issuer, address subject, bytes32 key) public view returns (bytes32)
```

#### `removeClaim`

自身が発行したクレームを削除します。
発行者本人（`msg.sender`）である必要があります。

```javascript
function removeClaim(address issuer, address subject, bytes32 key) public
```

### クレーム値の型（Type conversions）

クレームの`value`はあえて`bytes32`型に固定されています。
これは、クレームレジストリの実装をシンプルに保つためです。

一方で、現実の用途ではアドレス型やuint型など、より具体的な型が必要になることがあります。
そのため、型変換はコントラクトの外部で処理する方針が提案されています。
例えば、`bytes32`をアドレスに変換するライブラリを別途実装することで、レジストリ本体を汎用的かつ軽量に保ちつつ、必要な型に変換して利用できます。

### デプロイとアドレス

このレジストリコントラクトは1度だけデプロイされ、Ethereumネットワーク上で共通の参照先として使われます。
Ropsten、Rinkeby、Kovanなどのテストネットにも同様にデプロイされ、そのアドレスが本仕様書に記載される予定です。

### アップデートとガバナンス

将来的にレジストリに新たな機能が必要になった場合は、EIP（Ethereum Improvement Proposal）を通じて提案し、議論のうえでアップグレードされるべきとされています。
この時、既存のクレームデータを新しいコントラクトに移行する方法も、提案に含める必要があります。

### スマートコントラクト実装

以下はECRの実装例です。
クレームは3重のマッピング構造で保存されており、簡潔で効率的な設計になっています。

```javascript
contract EthereumClaimsRegistry {
    mapping(address => mapping(address => mapping(bytes32 => bytes32))) public registry;

    event ClaimSet(address indexed issuer, address indexed subject, bytes32 indexed key, bytes32 value, uint updatedAt);
    event ClaimRemoved(address indexed issuer, address indexed subject, bytes32 indexed key, uint removedAt);

    function setClaim(address subject, bytes32 key, bytes32 value) public {
        registry[msg.sender][subject][key] = value;
        emit ClaimSet(msg.sender, subject, key, value, now);
    }

    function setSelfClaim(bytes32 key, bytes32 value) public {
        setClaim(msg.sender, key, value);
    }

    function getClaim(address issuer, address subject, bytes32 key) public view returns(bytes32) {
        return registry[issuer][subject][key];
    }

    function removeClaim(address issuer, address subject, bytes32 key) public {
        require(msg.sender == issuer);
        delete registry[issuer][subject][key];
        emit ClaimRemoved(msg.sender, subject, key, now);
    }
}
```

この実装は、署名検証や認証処理を持たず、あくまで「**主張された情報を記録・取得・削除**」するためのインフラとして設計されています。
安全性や意味づけの検証は利用側で行う前提です。

## 引用

https://github.com/ethereum/EIPs/issues/780

## 最後に

今回は「あるアカウントが別のアカウントに関して発行する情報（例：本人確認済み、所属組織など）をブロックチェーン上に記録・参照できる共通レジストリである、Ethereum Claims Registry（ECR）の仕組みを提案している**ERC780**」についてまとめてきました！
いかがだったでしょうか？

質問などがある方は以下の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