はじめに

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

https://amzn.asia/d/gxvJ0Pw

今回は、クレームの取り消し情報や信頼できる発行者情報などをチェーン上で管理し、信頼性を強化する仕組みを提案しているERC7506についてまとめていきます！

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

ERC-7506: Trusted Hint RegistryA system for managing on-chain metadata, enabling verification of ecosystem claims.Ethereum Improvement Proposals

他にも様々なEIP・BIP・SLIP・CAIP・ENSIP・RFC・ACPについてまとめています。

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

概要

ERC Trusted Hint Registry は、「ヒント」と呼ばれるオンチェーンメタデータを標準的な形で管理するための仕組みを提案しています。 ここでいうオンチェーンメタデータとは、「チェーン上に記録された、他の情報（クレーム）を補足・説明するための付随情報」のことです。

ERC Trusted Hint Registryでは、このヒントを「ネームスペース」と「リスト」という単位で整理して管理します。 ネームスペースは、あるまとまり（例えば1つのエコシステムや組織）ごとの領域のようなもので、その中に複数のヒントリストを持てるイメージです。 こうした構造にすることで、ヒントを体系立てて整理し、必要なものを取り出しやすくしています。

さらに、ヒントの書き込みには権限管理の仕組みがあります。 ネームスペースの所有者だけがヒントを書き込めるように制御できるだけでなく、その管理作業を他の信頼できるアドレスに委任することもできます。 これにより、運用を柔軟にしつつ、誰でも勝手に書き換えられないようにできます。

トランザクションの送信方法については、「メタトランザクション」を安全に扱う仕組みも組み込まれています。 メタトランザクションとは、「実際にガスを払う送信者」と「内容に署名した当人」が分かれているトランザクションの仕組みのことです。 ERC Trusted Hint RegistryではEIP712形式の署名を使って、署名内容が改ざんされていないことや、誰がその操作に同意したのかを検証できるようにしています。 EIP712は「構造化されたデータに対して署名するための標準」で、ユーザーにとって分かりやすく、安全に署名できるようにする仕様です。

EIP712については以下の記事を参考にしてください。

[EIP712] 型付き構造化データのハッシュ化と署名の仕組みを理解しよう！

またオプションとして、ENS（Ethereum Name Service）との連携も考慮されています。 ENSはアドレスに人間が読める名前（例: example.eth）を紐づける名前解決サービスです。 ヒント管理にENSを組み合わせることで、「このネームスペースやヒントは誰のものか」を人間にも分かりやすい形で確認しやすくなり、信頼性の確認や発見性の向上に役立ちます。

インターフェースは、ヒントが変更されたときなどに特定のイベントを発行するようになっています。 これにより、「いつ」、「誰が」、「どのヒントを」変更したのかをオンチェーンのログから追跡しやすくなります。

ERC Trusted Hint Registryは、クレームやエコシステムに関するメタデータを扱うための、信頼性の高い標準的な枠組みを提供することを狙っています。 これによって、分散型環境におけるデータの解釈や検証の整合性を保ち、信頼性を維持する基盤となることを目指しています。

動機

ERC Trusted Hint Registryの背景には、「分散型の世界でどう信頼を築くか」という課題があります。 ブロックチェーンや分散型技術は、「相手を信頼しなくても成り立つ（トラストレス）」仕組みを提供しますが、その上で動くエコシステム（ビジネス、コミュニティ、社会的なプロジェクトなど）は、逆に「誰をどこまで信頼するか」を決める必要があります。

こうしたエコシステムでは、参加者に対して「クレーム」が頻繁に発行されます。 ここでのクレームとは、「ある主体が、別の主体について主張する情報」のことで、例えば「このアドレスはKYC済みである」、「この法人はこの団体のメンバーである」といった主張が該当します。これらのクレームが、エコシステム内で信頼を形成する土台になり、取引や連携をスムーズにします。

一方で、これまでの実例から、「単に検証可能なクレーム（Verifiable Credential など）が存在するだけでは、十分な信頼を作れない」ことが分かってきました。 どのクレームをどのように解釈すべきか、いつ無効になったのか、誰を信頼できる発行者と見なすべきか、といった周辺情報が欠けていると、クレームを安全に利用できません。 そこで必要になるのが、クレームを補助するオンチェーンメタデータのレイヤーです。

この仕様では、そうした補助的なメタデータを「ヒント」と呼んでいます。 ヒントは、エコシステムがクレームを信頼できる形でやり取りし、検証するための手がかりとして使われます。ヒントの具体的な役割の例は、次のように整理できます。

ヒントの役割 説明
失効・取り消し情報 「このクレームはいつ、どの理由で無効になったか」といった情報を示します。
信頼できる発行者の識別 「どの発行者（アドレスや組織）を信頼してよいか」といった情報を示します。
タイムスタンプ付きハッシュ クレームの内容のハッシュとその時刻を記録し、後から改ざんされていないかを確認できます。

これらはあくまで一例であり、ヒントはエコシステムの要件に応じてさまざまな用途に使えますが、共通しているのは「クレームの信頼性やデータの完全性を時間を通じて検証できるようにする」という点です。

ERC Trusted Hint Registryは、こうしたヒントを管理するための、堅牢で柔軟かつ標準化されたインターフェースを提供することを目的としています。 任意のアドレスが、自分に紐づく複数のヒントリストを管理できるようになっており、ヒントの作成・更新をしやすくする機能に加えて、その操作権限を別の信頼できるアドレスに委譲できるようになっています。 これにより、エコシステムごとに求められる運用形態やユースケースに合わせて、ヒントリストを動的に活用できるようになります。

また、インターフェース設計にあたっては、相互運用性が強く意識されています。 具体的には、W3Cが策定する Decentralized Identifiers（分散型識別子）や Verifiable Credentials（検証可能な証明）といった仕様との整合性を考慮しています。 これらはID管理や証明情報の標準仕様であり、オンチェーン・オフチェーン双方で広く利用されることを想定したものです。 さらに、Ethereum Attestation Service（イーサリアム上でアテステーション、つまり「ある主張に対する署名付き証明」を扱うプロジェクト）との整合も視野に入れられており、既存のエコシステムとの連携をしやすくしています。

このように、ERC Trusted Hint Registryは、ヒント管理のスマートコントラクトインターフェースを標準化することで、分散型エコシステムにおける信頼の構築と拡張を支える役割を果たします。 オンチェーン・オフチェーンを問わずクレームを発行し、それを検証してどう解釈するかを共通の土台の上で扱えるようにするための基盤です。 そのためERC Trusted Hint Registryは、単に便利な追加機能というよりも、「分散型の世界で信頼をどう構成するか」という課題に対する、次のステップとなる仕組みとして位置づけられています。

仕様

TrustedHintRegistryコントラクト

ERC Trusted Hint Registryは、オンチェーン上で「ヒント（hint）」と呼ばれるメタデータを扱うための標準インターフェースを定義したものです。 ヒントは、クレーム（claim）の信頼性や解釈、検証の補助として使われます。

ERC7506はm必須となる基本機能（ヒント取得・設定）、任意とされる管理系の機能（委任設定・メタデータ管理・署名付き操作など）を定義しています。

ガバナンスの仕組みは仕様に含まれていないため、各エコシステムが独自に実装できます。

定義

仕様で使用される用語を整理します。

用語 説明
claim 他の主体についてある主体が発行する主張のこと。
hint クレームを解釈したり信頼性を補強したりするための補助情報。
namespace 登録されたアドレスが所有する領域で、その中にヒントリストが配置される。
hint list namespace の中に存在するヒントの集合体で、複数のkey/valueを格納する。
hint key hint value を特定するための識別子。
hint value エコシステム内の主体に関する何らかの情報。
delegate hint list への書き込み権限を委任されたアドレス。

インターフェース

イベント

HintValueChanged
javascript
event HintValueChanged(
  address indexed namespace,
  bytes32 indexed list,
  bytes32 indexed key,
  bytes32 value
);

ヒント値が変更された時に発行されるイベント。 このイベントは、指定された namespace 内の特定のヒントリストに含まれる key の値が変更された際に発行されます。 どの namespace・list・key に対して変更が発生したかを明確に記録することで、 オンチェーン上のヒント変更履歴を追跡しやすくなります。 ヒントは信頼性評価やデータの補強に利用されるため、変更ログが残ることはエコシステム全体の透明性を高めます。

パラメータ

  • namespace
    • ヒントが属する namespace のアドレス。
  • list
    • 値が変更されたヒントリストを表すキー。
  • key
    • 値が変更されたヒントのキー。
  • value
    • 新しく設定されたヒント値。
HintListOwnerChanged
javascript
event HintListOwnerChanged(
  address indexed namespace,
  bytes32 indexed list,
  address indexed newOwner
);

ヒントリストの所有者が変更された時に発行されるイベント。 このイベントは、特定のヒントリストの所有者（管理者権限を持つアドレス）が別のアドレスへ変更された時に発行されます。 ただしリストが所属する namespace（アドレス自体）は変わらず、 あくまで「そのリストを管理する権限の移転」が行われます。 これにより、namespace の階層構造はそのまま保たれた状態で、 権限の移譲のみが行われたことを明確に追跡できます。

パラメータ

  • namespace
    • 変更対象のヒントリストが属する namespace のアドレス。
  • list
    • 所有者が変更されたヒントリスト。
  • newOwner
    • ヒントリストの新しい所有者となるアドレス。
HintListDelegateAdded
javascript
event HintListDelegateAdded(
  address indexed namespace,
  bytes32 indexed list,
  address indexed newDelegate
);

ヒントリストに delegate が追加された時に発行されるイベント。 namespace の所有者が、特定のヒントリストに対して delegate（書き込み権限を委任されたアドレス）を追加した時に発行されます。 delegate を追加することで、複数の主体が共同でヒントリストを管理しやすくなり、 権限の変化を追跡できるようにします。

パラメータ

  • namespace
    • 対象の namespace。
  • list
    • delegate が追加されたヒントリスト。
  • newDelegate
    • 書き込み権限を付与されたアドレス。
HintListDelegateRemoved
javascript
event HintListDelegateRemoved(
  address indexed namespace,
  bytes32 indexed list,
  address indexed oldDelegate
);

ヒントリストから delegate が削除された時に発行されるイベント。 ヒントリストに対する書き込み権限が委任されていた delegate が、権限を失った際に発行されます。 delegate の削除は権限管理上重要な操作のため、チェーン上に明確な履歴を残すことができます。

パラメータ

  • namespace
    • 該当する namespace のアドレス。
  • list
    • delegate が削除されたヒントリスト。
  • oldDelegate
    • 削除された delegate のアドレス。
HintListStatusChanged
javascript
event HintListStatusChanged(
  address indexed namespace,
  bytes32 indexed list,
  bool indexed revoked
);

ヒントリストの有効状態が変更された時に発行されるイベント。 ヒントリストが無効化された、あるいは再び有効化された際に発行されます。 revoked が true の場合は「リスト全体が無効化された」ことを意味し、 そのリストに含まれるすべてのヒント値が信頼できない状態とみなされます。 これにより、クレームの取り消しやデータの有効期限切れなどの情報を効率的に伝えられます。

パラメータ

  • namespace
    • 対象 namespace のアドレス。
  • list
    • 有効状態が変更されたヒントリスト。
  • revoked
    • true の場合は無効化されたことを示す。
getHint
javascript
function getHint(address _namespace, bytes32 _list, bytes32 _key) external view returns (bytes32);

指定された namespace とヒントリストから、特定キーに対応するヒント値を取得する関数。 この関数は読み取り専用で、namespace 内の list に含まれる key に対して保存されている bytes32 の値を返します。 ヒント値はクレームの信頼性確認やデータ検証に利用されるため、この関数はシステム内で頻繁に呼び出される基礎的な機能です。 値を変更することはなく、ストレージへの書き込みも行いません。

引数

  • _namespace
    • 参照対象となる namespace のアドレス。
  • _list
    • 参照対象のヒントリストを識別する bytes32 値。
  • _key
    • 取得対象のヒントキー。

戻り値

  • bytes32
    • 指定された key に対応するヒント値。
setHint
javascript
function setHint(address _namespace, bytes32 _list, bytes32 _key, bytes32 _value) public;

特定のヒントキーに対応する値を更新する関数。 namespace の所有者または書き込み権限を持つ delegate が、 指定した key に対して新しい value を設定します。 ヒント値の変更はデータの解釈や信頼性の判断に影響するため、 権限管理が重要な関数です。 必要に応じてメタデータを追加できるオーバーロード版も用意されています。

引数

  • _namespace
    • 更新対象となる namespace のアドレス。
  • _list
    • ヒントリストを識別する bytes32 のキー。
  • _key
    • 値を更新する対象のヒントキー。
  • _value
    • 新しく設定するヒント値。
setHintSigned
javascript
function setHintSigned(
  address _namespace,
  bytes32 _list,
  bytes32 _key,
  bytes32 _value,
  address _signer,
  bytes calldata _signature
) public;

署名によってヒント値を更新する関数。 メタトランザクションの仕組みを利用し、署名者がEIP712準拠のデータに署名することで意図を示し、 別の sender がその署名データを使ってトランザクションを実行します。 署名内容には nonce が含まれ、再利用（リプレイ攻撃）を防ぎます。 この関数はユーザーが自分でガスを支払わなくても操作できるという利点があります。

引数

  • _namespace
    • 更新対象の namespace。
  • _list
    • 対象のヒントリスト。
  • _key
    • 更新対象のヒントキー。
  • _value
    • 新しいヒント値。
  • _signer
    • EIP712署名を生成したアドレス。
  • _signature
    • 署名データ（EIP712準拠）。
setHints
javascript
function setHints(
  address _namespace,
  bytes32 _list,
  bytes32[] calldata _keys,
  bytes32[] calldata _values
) public;

複数のヒントキーに対してまとめて値を更新する関数。 複数のkey/valueを一度に変更できるため、大量のヒント更新が必要な場合に効率的です。 _key と _values の長さが一致している必要があります。 namespace の所有者または delegate のみが利用できます。

引数

  • _namespace
    • 対象 namespace のアドレス。
  • _list
    • 対象ヒントリスト。
  • _keys
    • 更新対象となる複数のヒントキー。
  • _values
    • 各キーに対応する新しいヒント値。
setHintsSigned
javascript
function setHintsSigned(
  address _namespace,
  bytes32 _list,
  bytes32[] calldata _keys,
  bytes32[] calldata _values,
  address _signer,
  bytes calldata _signature
) public;

署名付きメタトランザクションで複数のヒント値をまとめて更新する関数。 setHintSigned の複数キー対応版です。 ユーザーはEIP712署名を生成するだけでよく、実際のトランザクションは sender が送信します。 これによりユーザー負担を減らしつつ、複数の更新を安全に実行できます。

引数

  • _namespace
    • 対象 namespace。
  • _list
    • 対象ヒントリスト。
  • _keys
    • 更新対象キーの配列。
  • _values
    • 新しく設定する値の配列。
  • _signer
    • EIP712署名を生成したアドレス。
  • _signature
    • meta transaction用の署名データ。
setHintDelegated
javascript
function setHintDelegated(address _namespace, bytes32 _list, bytes32 _key, bytes32 _value) public;

事前に承認された delegate がヒント値を更新するための関数。 namespace の所有者によって delegate として登録されたアドレスのみが実行できます。 delegate は、所有者の代わりに特定のヒントリストのkey/valueを変更できます。 権限の範囲は namespace 全体ではなく、特定の list ごとに管理されるため、精密な権限コントロールが可能です。

引数

  • _namespace
    • 対象となる namespace のアドレス。
  • _list
    • delegate が書き込み権限を持つヒントリスト。
  • _key
    • 更新対象のヒントキー。
  • _value
    • 新しいヒント値。
setHintDelegatedSigned
javascript
function setHintDelegatedSigned(
  address _namespace,
  bytes32 _list,
  bytes32 _key,
  bytes32 _value,
  address _signer,
  bytes calldata _signature
) public;

署名付きメタトランザクションで delegate がヒント値を更新する関数。 delegate に書き込み権限はあるものの、ガス代を支払う必要はありません。 delegate はEIP712形式の署名を提供し、第三者の sender がその署名を使ってトランザクションを送信します。 そのため、ユーザー負担を最小限にしつつ、安全に更新処理を行えます。 署名には nonce が含まれ、リプレイ攻撃を防ぎます。

引数

  • _namespace
    • ヒントリストが属する namespace のアドレス。
  • _list
    • delegate の対象となるヒントリスト。
  • _key
    • 更新対象のヒントキー。
  • _value
    • 新しいヒント値。
  • _signer
    • EIP712 署名を生成した delegate のアドレス。
  • _signature
    • 署名データ。
setHintsDelegated
javascript
function setHintsDelegated(
  address _namespace,
  bytes32 _list,
  bytes32[] calldata _keys,
  bytes32[] calldata _values
) public;

複数のヒント値を delegate がまとめて更新する関数。 delegate が複数のkey/valueを一度に変更するための関数です。 大量のデータ更新を同時に行う場合に効率的で、各キーと値のペアがまとめて更新されます。 権限は list 単位で付与されているため、delegate が更新可能な範囲を明確に制御できます。

引数

  • _namespace
    • 対象 namespace のアドレス。
  • _list
    • delegate が担当するヒントリスト。
  • _keys
    • 更新対象の複数のヒントキー。
  • _values
    • _keys に対応する複数の新しいヒント値。
setHintsDelegatedSigned
javascript
function setHintsDelegatedSigned(
  address _namespace,
  bytes32 _list,
  bytes32[] calldata _keys,
  bytes32[] calldata _values,
  address _signer,
  bytes calldata _signature
) public;

署名付きメタトランザクションで、複数のヒント値を delegate がまとめて更新する関数。 複数のkey/valueの更新を、delegate がEIP712署名によって承認し、sender が実際のトランザクションを送信する形式です。 大量データを扱う場面でも効率性と安全性を両立できます。 nonce を用いることで署名が再利用されることを防ぎます。

引数

  • _namespace
    • 対象 namespace。
  • _list
    • 対象ヒントリスト。
  • _keys
    • 更新対象のキー一覧。
  • _values
    • 新しい値の一覧。
  • _signer
    • 署名を生成した delegate のアドレス。
  • _signature
    • 署名データ。
setListStatus
javascript
function setListStatus(address _namespace, bytes32 _list, bool _revoked) public;

ヒントリストの有効／無効状態を変更する関数。 この関数は、特定のヒントリストが「有効か」、「無効か」を示す状態を更新します。 _revoked が true の場合、そのリストは無効化されたとみなされます。 仕様上、「リストの無効化」は、そのリスト内のすべてのヒント値を一括で無効であると扱うために利用できます。 これにより、個別の key を逐一更新しなくても、リスト単位で一括無効化の扱いが可能になります。

引数

  • _namespace
    • 対象となる namespace のアドレス。
  • _list
    • 状態を変更する対象のヒントリストを表す bytes32 値。
  • _revoked
    • true の場合はリストを無効化し、false の場合は有効として扱う状態にします。
setListStatusSigned
javascript
function setListStatusSigned(
  address _namespace,
  bytes32 _list,
  bool _revoked,
  address _signer,
  bytes calldata _signature
) public;

署名付きメタトランザクションでヒントリストの有効／無効状態を変更する関数。 この関数は setListStatus のメタトランザクション版です。 リストの状態変更を行う権限を持つ _signer が、EIP712形式のデータに署名し、 別の sender が _signature を含めたトランザクションを送ることで処理を実行します。 署名データには nonce が含まれ、同じ署名が再利用されることを防ぎます。

引数

  • _namespace
    • 対象 namespace のアドレス。
  • _list
    • 状態変更対象のヒントリスト。
  • _revoked
    • リストを無効とするかどうかを示すフラグ。
  • _signer
    • 状態変更を承認する署名者のアドレス。
  • _signature
    • EIP712準拠で生成された署名データ。
setListOwner
javascript
function setListOwner(address _namespace, bytes32 _list, address _newOwner) public;

ヒントリストの所有者を別のアドレスに移転する関数。 この関数は、指定されたヒントリストのオーナーを _newOwner に変更します。 重要なのは、リストが所属する _namespace 自体は変更されない点です。 つまり、リストの「場所」は同じ namespace に残りつつ、そのリストを管理するアドレスだけが切り替わります。 これにより、既存の参照パス（namespace → list → key → value）が壊れずに、 運用上の管理者だけを入れ替えることができます。

引数

  • _namespace
    • 対象リストが属する namespace のアドレス。
  • _list
    • 所有者を変更したいヒントリストの識別子。
  • _newOwner
    • 新たにそのリストの所有者となるアドレス。
setListOwnerSigned
javascript
function setListOwnerSigned(
  address _namespace,
  bytes32 _list,
  address _newOwner,
  address _signer,
  bytes calldata _signature
) public;

署名付きメタトランザクションにより、ヒントリストの所有者を移転する関数。 この関数は setListOwner のメタトランザクション版です。 現在のリスト所有者など、権限を持つ _signer がEIP712署名を生成し、別の sender が _signature をコントラクトに渡して所有者変更を実行します。 これにより、オーナー自身がガスを払わなくても管理変更を行える一方、署名と nonce によって安全性が確保されます。

引数

  • _namespace
    • 対象 namespace のアドレス。
  • _list
    • 所有者を変更するヒントリスト。
  • _newOwner
    • 新しい所有者アドレス。
  • _signer
    • 所有者変更を承認する署名者のアドレス。
  • _signature
    • EIP712準拠の署名データ。
addListDelegate
javascript
function addListDelegate(
  address _namespace,
  bytes32 _list,
  address _delegate,
  uint256 _untilTimestamp
) public;

ヒントリストに対して delegate を追加する関数。 この関数は、特定のヒントリストに対して書き込み権限を委任するアドレスを追加します。 delegate は _untilTimestamp までの期間、そのリストに対する書き込み操作を行うことができます。 これにより、エコシステム内の他の主体に対して限定的な編集権限を付与し、共同編集や運用分担をしやすくします。

引数

  • _namespace
    • 対象 namespace のアドレス。
  • _list
    • delegate を追加するヒントリスト。
  • _delegate
    • 書き込み権限を付与するアドレス。
  • _untilTimestamp
    • delegate 権限の有効期限（UNIX 時刻）。
addListDelegateSigned
javascript
function addListDelegateSigned(
  address _namespace,
  bytes32 _list,
  address _delegate,
  uint256 _untilTimestamp,
  address _signer,
  bytes calldata _signature
) public;

署名付きメタトランザクションでヒントリストに delegate を追加する関数。 この関数は addListDelegate のメタトランザクション版です。 リストの所有者など、権限を持つ _signer がEIP712データに署名し、第三者の sender がトランザクションを送信することで delegate を追加します。 署名には nonce を含めることで、署名の再利用による不正な追加を防ぎます。

引数

  • _namespace
    • 対象 namespace。
  • _list
    • delegate を追加するヒントリスト。
  • _delegate
    • 書き込み権限を付与するアドレス。
  • _untilTimestamp
    • delegate 権限の有効期限。
  • _signer
    • delegate 追加を承認する署名者。
  • _signature
    • EIP712準拠の署名データ。
removeListDelegate
javascript
function removeListDelegate(address _namespace, bytes32 _list, address _delegate) public;

ヒントリストから delegate を削除する関数。 この関数は、特定のヒントリストに対して設定されていた delegate を解除します。 これにより、その delegate は対象リストに対する書き込み権限を失います。 権限が不要になった場合や、信頼性に問題が生じた場合などに利用されます。

引数

  • _namespace
    • 対象 namespace のアドレス。
  • _list
    • delegate を削除するヒントリスト。
  • _delegate
    • 削除対象の delegate アドレス。
removeListDelegateSigned
javascript
function removeListDelegateSigned(
  address _namespace,
  bytes32 _list,
  address _delegate,
  address _signer,
  bytes calldata _signature
) public;

署名付きメタトランザクションにより、ヒントリストから delegate を削除する関数。 この関数は removeListDelegate のメタトランザクション版です。 権限を持つ _signer が、delegate 削除を承認するEIP712署名を行い、sender が _signature を使ってコントラクト呼び出しを行います。 これにより、オーナー自身が直接トランザクションを送信しなくても delegate 権限の管理を安全に行えます。

引数

  • _namespace
    • 対象 namespace。
  • _list
    • delegate を削除するリスト。
  • _delegate
    • 削除対象の delegate。
  • _signer
    • delegate 削除を承認した署名者。
  • _signature
    • EIP712準拠の署名データ。
getMetadata
javascript
function getMetadata(
  address _namespace,
  bytes32 _list,
  bytes32 _key,
  bytes32 _value
) external view returns (bytes memory);

特定のヒント値に紐づいたメタデータを取得する関数。 この関数は、特定の namespace、list、key、value に対応するメタデータを返します。 メタデータには付加的な情報（証跡・ハッシュ・関連する構造化情報など）が含まれる場合があり、 ヒント値の解釈や検証を補強する目的で使われます。

引数

  • _namespace
    • 対象 namespace のアドレス。
  • _list
    • 対象ヒントリスト。
  • _key
    • 対象ヒントキー。
  • _value
    • 対象ヒント値（メタデータが紐づく値）。

戻り値

  • bytes
    • 指定されたヒントに紐づくメタデータ。
setMetadata
javascript
function setMetadata(
  address _namespace,
  bytes32 _list,
  bytes32 _key,
  bytes32 _value,
  bytes calldata _metadata
) public;

ヒント値に紐づくメタデータを設定する関数。 この関数は、指定のヒントに対して metadata を保存します。 メタデータは bytes 形式であり、外部サービスとの連携情報や証明データなど、 柔軟な用途に利用できます。 ヒント本体（value）とは独立して管理されるため、値を変更せずに付加情報だけを更新できます。

引数

  • _namespace
    • 対象 namespace。
  • _list
    • 対象ヒントリスト。
  • _key
    • 対象ヒントキー。
  • _value
    • メタデータが紐づくヒント値。
  • _metadata
    • 保存するメタデータ（bytes）。
setMetadataSigned
javascript
function setMetadataSigned(
  address _namespace,
  bytes32 _list,
  bytes32 _key,
  bytes32 _value,
  bytes calldata _metadata,
  address _signer,
  bytes calldata _signature
) public;

署名付きメタトランザクションでヒントのメタデータを設定する関数。 この関数は setMetadata をメタトランザクションに対応させたものです。 権限を持つ _signer がメタデータ設定を承認するEIP712署名を行い、sender がトランザクションを送信します。 ユーザー自身がガスを支払う必要がなく、安全性と利便性の両方を満たします。 署名内容には nonce が含まれ、リプレイ攻撃を防止します。

引数

  • _namespace
    • メタデータ対象の namespace。
  • _list
    • 対象ヒントリスト。
  • _key
    • 対象ヒントキー。
  • _value
    • メタデータが紐づくヒント値。
  • _metadata
    • 新しいメタデータ（bytes）。
  • _signer
    • この更新を承認する署名者。
  • _signature
    • EIP712準拠の署名。
setMetadataDelegated
javascript
function setMetadataDelegated(
  address _namespace,
  bytes32 _list,
  bytes32 _key,
  bytes32 _value,
  bytes calldata _metadata
) public;

事前に承認された delegate がメタデータを設定する関数。 この関数は、namespace の所有者によって delegate として登録されたアドレスのみが実行できます。 delegate はヒント値の更新と同様に、メタデータの設定も行えるため、運用負荷を分散したり、複数主体でリストを管理する時に便利です。 ヒント本体の更新同様、書き込み権限は list 単位で制御されます。

引数

  • _namespace
    • 対象 namespace。
  • _list
    • メタデータを追加するヒントリスト。
  • _key
    • 対象ヒントキー。
  • _value
    • 対象ヒント値。
  • _metadata
    • 保存するメタデータ。
setMetadataDelegatedSigned
javascript
function setMetadataDelegatedSigned(
  address _namespace,
  bytes32 _list,
  bytes32 _key,
  bytes32 _value,
  bytes calldata _metadata,
  address _signer,
  bytes calldata _signature
) public;

署名付きメタトランザクションで delegate がメタデータを設定する関数。 この関数は setMetadataDelegated のメタトランザクション対応版です。 delegate は自身の書き込み操作をEIP712署名で承認し、別の sender が実行します。 これにより delegate がガス代を負担する必要がなくなるため、ユーザー体験が向上します。 nonce によって署名の再利用が防がれており、安全性も確保されています。

引数

  • _namespace
    • 対象 namespace。
  • _list
    • 対象ヒントリスト。
  • _key
    • 対象ヒントキー。
  • _value
    • メタデータが紐づくヒント値。
  • _metadata
    • 保存したいメタデータ。
  • _signer
    • メタデータ設定を承認する署名者。
  • _signature
    • EIP712署名データ。

補足

データ構造の意図

ヒント情報は以下のような多層的な構造で管理されます。

javascript
//     namespace          hint list          hint key    hint value
mapping(address => mapping(bytes32 => mapping(bytes32 => bytes32))) hints;

この構造は、以下のような階層的な関係を持っています。

レベル 役割
namespace（address） 所有者のアドレスをそのまま名前空間として扱う。
hint list（bytes32） 用途ごとに分けられたヒントの集合。
hint key（bytes32） 個々のヒントを識別する値。
hint value（bytes32） ヒントの中身。

この構造の特徴は、namespace の所有者が自動的にその namespace 内のすべてのリストの初期所有者になる点です。 このため、別途「リストの所有権を主張する手続き」を用意する必要がありません。

この方式にはいくつかの利点があります。

まず、仕様実装がシンプルになり、権限管理が明確になります。 namespace の所有者が誰なのかが一目で分かり、書き込み権限をどこに付与すべきか判断しやすくなります。 また、意図しない所有権変更や権限混乱のリスクも抑えることができ、攻撃対象が増えにくい構造になっています。

一方で、delegate の管理やリスト所有者の変更といった機能には、別の補助的なデータ構造が必要になります。 ただし、これらの追加データは hint のメイン構造に影響を与えず、あくまで権限チェックのための補助的なレイヤーとして機能します。

管理機能を備える理由

ERC Trusted Hint Registryが大切にしているポイントの1つが、豊富な管理機能を備えていることです。 これによって、複数の主体がヒントリストを共同で扱いやすくなり、エコシステム全体の信頼性を高めることにつながります。

関数の構成を見ても、権限管理や委任、所有者変更、メタデータ管理、メタトランザクションなど、管理・運用面を重視した仕様になっています。

この考え方には、以下のような背景があります。

ユーザーの多くはトランザクションの詳細操作に慣れていないため、ユーザーフレンドリーな仕組みが重要です。 とくにメタトランザクションは、ユーザーが自分の秘密鍵の管理権限を保持したまま、プラットフォーム側が手続きを代行できる仕組みであり、使い勝手を大きく向上させます。 ユーザーはEIP712のメッセージに署名するだけでよく、アプリケーションがその署名を使って実際の処理を送信する形になります。

こうした設計により、エコシステムの複雑さをユーザーから隠しつつ、安全で拡張性の高い運用構造を実現しています。

セキュリティ

Meta Transactions

メタトランザクションは便利な仕組みですが、署名済みデータが別の場面で再利用されてしまう「リプレイ攻撃」のリスクがあります。

特に以下のようなケースが懸念されます。

  • 他のチェーンで同じコントラクトが展開された場合
  • コントラクトが再デプロイされた場合

ERC Trusted Hint RegistryはEIP712を採用することで、この問題を防いでいます。 EIP712では、署名の中に「ドメイン情報」が含まれます。 ドメイン情報にはチェーンIDやコントラクトアドレスが含まれるため、異なるコントラクト・異なるチェーンでは同じ署名を使い回すことができません。

メタトランザクションを安全に扱うための基本が、この仕様に組み込まれています。

権限管理（Rights Management）

ERC7506では、権限の管理が非常に重要な要素となっています。

ヒントリストの owner は、そのリストに対して完全な管理権限を持つため、誰を delegate として追加するか、どのキーに対する編集を許可するかなど、書き込みに関する最終的な判断を行います。

権限管理の仕組みは、以下のような目的で設計されています。

  • 不正なアドレスがヒント値を変更できないようにする
  • delegate の操作を必要に応じて細かく制御できるようにする
  • owner が常に全権限を保持し続ける

結果として、ヒント情報の信頼性を保ち、外部からの不正な書き換えを防ぎます。

ガバナンス（Governance）

ERC Trusted Hint Registryはガバナンスの仕組みを標準仕様に含めていません。 その理由は、ガバナンスはエコシステムによって大きく異なるため、共通仕様として定義するのが適さないからです。

ただし、エコシステムによっては、ヒントリストの変更や削除に承認プロセスを必要とする場合があります。 そのため、ERC7506はガバナンスを外側で自由に設定できるようにしています。

ガバナンス方法の例としては以下があります。

方法 説明
コントラクトの拡張 特定のメソッドにガバナンスチェックを追加する。
マルチシグウォレット 複数人の承認を必要とする仕組みを使う。
オフチェーン手続き 外部システムによる承認プロセスを設ける。

これにより、エコシステムの特性に合わせた柔軟な運用が可能になります。

引用

Philipp Bolte (@strumswell), Dennis von der Bey (@DennisVonDerBey), Lauritz Leifermann (@lleifermann), "ERC-7506: Trusted Hint Registry [DRAFT]," Ethereum Improvement Proposals, no. 7506, August 2023. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7506.

最後に

今回は「クレームの取り消し情報や信頼できる発行者情報などをチェーン上で管理し、信頼性を強化する仕組みを提案しているERC7506」についてまとめてきました！ いかがだったでしょうか？

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

Twitter @cardene777

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

かるでねさんのプロフィールスマートコントラクトやAIを楽しんでいます。主にSolidityやSmart Contract、AIを使用した記事を書いてます。Zenn
cardene’s Substack | SubstackMy personal Substack. Click to read cardene’s Substack, a Substack publication. Launched 3 years ago.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