はじめに

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

https://amzn.asia/d/gxvJ0Pw

今回は、外部発行者によるKYCや本人確認情報などを共通の形式でコントラクト内で確認できるようにする仕組みを提案しているERC735についてまとめていきます！

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

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

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

Notion | Where teams and agents work togetherMade in Notion, the connected workspace where AI agents and teams organize docs, projects and knowledge together.Notion

概要

ERC735は、「クレーム（Claim）」と呼ばれる情報をスマートコントラクト上で取り扱うための、共通インターフェースの標準仕様を定めたものです。 ここでいうクレームとは、ある主体（個人やエンティティ）に関して第三者が発行・証明した情報のことで、例えば「この人は日本に居住している」、「このユーザーは生体認証を通過している」といった事実を表すものです。

クレームは外部の第三者（Issuer）によって発行される場合もあれば、当事者自身による自己証明（Self-attested）として発行されることもあります。 いずれにしても、スマートコントラクトやDAppsがこのクレーム情報を利用することで、ある主体に関する判断（たとえばKYCの完了確認など）を行うことが可能になります。

この標準仕様では、クレームの追加、削除、保持のための関数を定め、誰が、どのような形式で、どのような種類の情報を発行し、それをどこで検証できるのかを一貫した形式で定義しています。

動機

ブロックチェーン上でのアイデンティティの管理や、本人確認に関するニーズが高まる中、DAppsが個々のユーザーについて「どんな情報を持っているか」を確認するための手段が必要とされています。 しかし、現状ではクレームの発行・検証の仕組みが標準化されておらず、プロジェクトごとに独自の実装がなされているため、相互運用性や拡張性に課題がありました。

この仕様の導入により、DAppsやスマートコントラクトは「クレームを確認する」という操作を共通の方法で実行できるようになります。 これにより、例えば複数のアプリケーション間で同じKYC情報を使い回すことができたり、あるクレームの信頼性を「誰がそれを証明したか（Issuer）」に基づいて判断できるようになります。 つまり、「クレーム保持者」ではなく「クレーム発行者」に信頼を委ねる構造へと転換されます。

用語

  • Claim（クレーム） 発行者がある主体に対して持つ情報（例：居住地、生体認証済みかなど）。
  • Claim Issuer（発行者 クレームを発行するスマートコントラクトや外部アカウント。
  • Claim Holder（保持者） クレームの対象となるアイデンティティ（例：ユーザーアドレス）。
  • Topic（トピック） クレームの種類を識別するための数値。 例：1 = 生体情報、2 = 居住地。
  • Scheme（スキーム） クレームをどのように検証すべきかを示す形式。例：ECDSA署名、RSA署名、コントラクト呼び出しなど。
  • Signature（署名） 発行者が本当にそのクレームを出したことを証明するための電子署名。
  • Data（データ） 実際のクレームの内容のハッシュ。
  • URI クレームの実体データが格納されている場所（例：IPFS、Swarm、HTTPリンクなど）。

この標準インターフェースを活用することで、スマートコントラクトは単一の関数呼び出しで複数の発行者からのクレームを検証・活用できるようになります。 これは分散的な信頼モデルの構築に向けた大きな一歩となります。

仕様

Claim

javascript
struct Claim {
    uint256 topic;
    uint256 scheme;
    address issuer;
    bytes signature;
    bytes data;
    string uri;
}

クレームの内容を表す構造体。 クレームは、ある主体に関して発行された検証可能な情報を保持するためのデータ構造です。 各クレームは、どのような種類の情報か（topic）、どの方式で証明されるか（scheme）、誰が発行したか（issuer）、署名データや参照先URIなどの詳細情報を含みます。

パラメータ

  • topic
    • クレームの種類を識別する番号（例：1 = 生体認証、2 = 住所など）。
  • scheme
    • 検証方式（例：ECDSA署名、コントラクト検証など）を示す数値。
  • issuer
    • クレームを発行したアドレス（通常は発行元コントラクトまたは外部アカウント）。
  • signature
    • クレーム内容に対する発行者の署名。address + topic + dataのKeccak256ハッシュに署名したもの。
  • data
    • クレームの内容本体のハッシュ値や実データ。
  • uri
    • クレームの内容の外部参照先（例：IPFS、Swarm、HTTPなど）。

ClaimRequested

javascript
event ClaimRequested(uint256 indexed claimRequestId, uint256 indexed topic, uint256 scheme, address indexed issuer, bytes signature, bytes data, string uri);

addClaimが呼び出された時に、承認プロセスが存在する場合に発行されるイベント。 クレームが提案状態として追加されたときに通知されます。 このイベントにより、外部の承認機構がこのクレームを確認して追加の判断を行うことができます。

パラメータ

  • claimRequestId
    • クレームリクエストの識別子。
  • topic
    • クレームのトピック。
  • scheme
    • 検証方式。
  • issuer
    • 発行者のアドレス。
  • signature
    • 署名データ。
  • data
    • クレームデータ。
  • uri
    • データのURI。

ClaimAdded

javascript
event ClaimAdded(bytes32 indexed claimId, uint256 indexed topic, uint256 scheme, address indexed issuer, bytes signature, bytes data, string uri);

クレームが正常に追加された時に発行されるイベント。 新しいクレームがコントラクトに登録されたことを通知するためのイベントです。 クレームの一意識別子や内容も出力されます。

パラメータ

  • claimId
    • 追加されたクレームのID（Keccak256ハッシュ）。
  • topic
    • クレームのトピック。
  • scheme
    • 検証方式。
  • issuer
    • 発行者のアドレス。
  • signature
    • 署名データ。
  • data
    • クレームデータ。
  • uri
    • データのURI。

ClaimRemoved

javascript
event ClaimRemoved(bytes32 indexed claimId, uint256 indexed topic, uint256 scheme, address indexed issuer, bytes signature, bytes data, string uri);

removeClaimの呼び出しによりクレームが削除された時に発行されるイベント。 指定されたクレームがコントラクトから削除された際に通知されます。

パラメータ

  • claimId
    • 削除されたクレームのID。
  • topic
    • クレームのトピック。
  • scheme
    • 検証方式。
  • issuer
    • 発行者のアドレス。
  • signature
    • 署名データ。
  • data
    • クレームデータ。
  • uri
    • データのURI。

ClaimChanged

javascript
event ClaimChanged(bytes32 indexed claimId, uint256 indexed topic, uint256 scheme, address indexed issuer, bytes signature, bytes data, string uri);

既存のクレームが変更された時に発行されるイベント。 クレームの更新があった場合に、その内容が新しいものに変更されたことを通知します。

パラメータ

  • claimId
    • 変更されたクレームのID。
  • topic
    • クレームのトピック。
  • scheme
    • 検証方式。
  • issuer
    • 発行者のアドレス。
  • signature
    • 新しい署名データ。
  • data
    • 新しいクレームデータ。
  • uri
    • 新しいURI。

getClaim

javascript
function getClaim(bytes32 _claimId) public constant returns(uint256 topic, uint256 scheme, address issuer, bytes signature, bytes data, string uri);

指定したクレームIDに対応するクレーム情報を取得する関数。 クレームのID（Keccak256ハッシュ）を指定して、登録されたクレームの詳細情報を取得します。

引数

  • _claimId
    • クレームの一意なID。

戻り値

  • topic
    • クレームの種類。
  • scheme
    • 検証方式。
  • issuer
    • 発行者のアドレス。
  • signature
    • クレームに付された署名。
  • data
    • クレームの内容。
  • uri
    • 外部参照先のURI。

getClaimIdsByTopic

javascript
function getClaimIdsByTopic(uint256 _topic) public constant returns(bytes32[] claimIds);

指定したトピックに該当するクレームIDを全て取得する関数。 あるトピックに分類されたすべてのクレームのIDを配列として返します。

引数

  • _topic
    • 検索対象とするクレームのトピック。

戻り値

  • claimIds
    • 該当するクレームIDの配列。

addClaim

javascript
function addClaim(uint256 _topic, uint256 _scheme, address _issuer, bytes _signature, bytes _data, string _uri) public returns (uint256 claimRequestId);

新しいクレームの追加、または既存クレームの変更を要求する関数。 この関数は、第三者（Issuer）によるクレームの追加または変更を要求するために使用されます。 クレームの発行者（Issuer）は、クレーム保持者（identity）に対して特定のトピックに関する情報を主張し、signature によってそれを証明します。

この関数は以下の性質を持っています。

  • 誰でも呼び出せる（発行者本人、自己発行（self-issued）も含む）。
  • クレームは issuer アドレスと topic を組み合わせて keccak256(issuer, topic) によって一意に識別されます（Claim IDの生成）。
  • signature は以下の形式で署名されたデータです。 keccak256(address identityHolder, uint256 topic, bytes data) この署名により、発行者がその内容を正当性をもって発行したことを証明します。
  • コントラクトは「即時追加」または「承認待ち状態（Pending）」のどちらかでクレームを登録できます。 これは、実装次第で承認プロセス（approve()関数など）を導入できる柔軟性を持たせています。
  • この関数の呼び出しは、以下の3つの異なるイベントをトリガーする可能性があります。
    • 新規クレームで承認プロセスがある場合 → ClaimRequested イベント
    • 新規クレームで即時登録された場合 → ClaimAdded イベント
    • 既存のクレームが上書きされた場合 → ClaimChanged イベント

トピックの例（Topic Examples）

  • 1: 生体情報（Biometric Data）
  • 2: 居住地情報（Permanent Address）
  • 3: クレームレジストリ（Claim Registry）※未定義のトピックとして拡張可能
引数
名前 型 説明
_topic uint256 クレームの分類（トピック）番号。例：1 = 生体情報、2 = 居住地など。
_scheme uint256 検証スキーム。例：1 = ECDSA、2 = RSA、3 = コントラクト検証など。
_issuer address クレームを発行するアドレス。本人でも外部でも構いません。
_signature bytes keccak256(identity, topic, data) に対する署名（発行者による）。
_data bytes クレームのデータ本体またはそのハッシュ。
_uri string クレームデータの保存先（HTTPリンク、IPFSハッシュなど）。
戻り値
名前 型 説明
claimRequestId uint256 承認フローがある場合に承認関数に渡すためのID。ない場合は無視可能。

引数

  • _topic
    • クレームの種類。
  • _scheme
    • 検証方式。
  • _issuer
    • クレームの発行者アドレス。
  • _signature
    • 署名データ。
  • _data
    • クレームのデータ。
  • _uri
    • データのURI。

戻り値

  • claimRequestId

    • 承認プロセスに使えるクレームリクエストID。

changeClaim

javascript
function changeClaim(bytes32 _claimId, uint256 _topic, uint256 _scheme, address _issuer, bytes _signature, bytes _data, string _uri) returns (bool success);

既存のクレーム情報を変更する関数。 指定されたクレームIDの内容を、新しい値で更新します。 更新後にはClaimChangedイベントが発行されます。

引数

  • _claimId
    • 変更対象のクレームID。
  • _topic
    • 新しいトピック。
  • _scheme
    • 新しい検証方式。
  • _issuer
    • 新しい発行者。
  • _signature
    • 新しい署名。
  • _data
    • 新しいクレームデータ。
  • _uri
    • 新しいURI。

戻り値

  • success
    • 変更が成功したかどうかの真偽値。

removeClaim

javascript
function removeClaim(bytes32 _claimId) public returns (bool success);

指定したクレームを削除する関数。 クレーム発行者自身、またはクレーム保持者自身が呼び出すことにより、クレームを削除することができます。 削除後はClaimRemovedイベントが発行されます。

引数

  • _claimId
    • 削除するクレームのID。

戻り値

  • success
    • 削除処理が成功したかどうかの真偽値。

引用

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

最後に

今回は「外部発行者によるKYCや本人確認情報などを共通の形式でコントラクト内で確認できるようにする仕組みを提案しているERC735」についてまとめてきました！ いかがだったでしょうか？

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

Twitter @cardene777

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

https://chaldene.net/

かるでねさんのプロフィールスマートコントラクトやAIを楽しんでいます。主にSolidityやSmart Contract、AIを使用した記事を書いてます。Zenn

https://cardene.substack.com/

https://mirror.xyz/0xcE77b9fCd390847627c84359fC1Bc02fC78f0e58

Notion | Where teams and agents work togetherMade in Notion, the connected workspace where AI agents and teams organize docs, projects and knowledge together.Notion