はじめに
『DApps開発入門』という本や色々記事を書いているかるでねです。
今回は、監査者の署名を使ってコントラクトの監査状況やERC準拠をオンチェーンで確認できる仕組みを提案しているERC7512についてまとめていきます！
以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。
他にも様々なEIP・BIP・SLIP・CAIP・ENSIP・RFC・ACPについてまとめています。
概要
ERC7512で提案されている仕組みは、監査レポートをオンチェーン上で表現し、スマートコントラクト側がその内容を解析できるようにする標準を整えることを目的としています。
ここでいう「監査レポートのオンチェーン化」とは、単にPDFやテキストをチェーンに載せるという意味ではなく、監査者（Auditor）が誰なのか、どの基準に基づいて監査が行われたのか、どの仕様（例：ERC20、ERC721、ERC1155など）が検証済みなのかといった情報を、コントラクト側が直接取り出せる形式で扱うための仕組みです。
ERC20については以下の記事を参考にしてください。
ERC721については以下の記事を参考にしてください。
ERC1155については以下の記事を参考にしてください。
従来のスマートコントラクト監査は、オフチェーンの文書ベースで行われていました。
アプリケーションやユーザーは、その監査が本物であるかどうか、監査者が信頼できるか、対象コントラクトがどの仕様を満たしているのかを自ら判断する必要がありました。
一方、この規格の目的は、「監査結果をスマートコントラクト自身が検証し利用できる状態にする」ことにあります。
これにより、ブリッジやプロトコル、アプリケーションがトラストレスに近い形で監査情報を利用でき、セキュリティの底上げにつながります。
動機
スマートコントラクトに対する監査は、セキュリティを確保し、想定通りの動作を担保するうえで非常に重要な工程です。
監査はバグの発見だけでなく、ERC20やERC721、ERC1155といった標準仕様に正しく準拠しているかを確認する役割も持っています。
しかし、ブロックチェーンを取り巻く状況が高度化・複雑化する中で、監査をより活用するためのオンチェーンで検証可能な仕組みが必要になってきました。
特に、以下の領域では、監査が正しく行われているかどうかをチェーン上で即座に判定できるメリットが大きくなっています。
ブリッジ
ブリッジは複数のチェーン間で資産を移動させるための仕組みです。
多くの場合、ブリッジには「ブリッジヘッド」や「ロックボックス」と呼ばれる資産保管のためのコントラクトが存在します。
これらが不具合を持っていた場合、以下の重大事故につながる恐れがあります。
- ブリッジ全体の停止
- 過剰発行などによる資産毀損
チェーン上で監査の真偽を確認できれば、安全に扱えるコントラクトのみを自動的にブリッジ対象として選ぶことが可能になります。
トークンコントラクト
Ethereum上のすべてのトークンはスマートコントラクトです。
アプリケーションは、そのトークンがERC20やERC721などの標準通りに動作することを前提に設計されています。
もし標準から逸脱していた場合、アプリケーション側で予期しない動作が発生し、ユーザー資産の損失に発展する可能性まであります。
チェーン上で監査内容を確認できるようになれば、アプリケーションは「このトークンはERC20の必須仕様を満たしている」などを自動的に判断でき、より堅牢なエコシステムを構築できます。
スマートコントラクトアカウント（SCA）
ERC4337によって、スマートコントラクトをアカウントとして扱う仕組みが広く知られるようになりました。これにより、柔軟なアカウント設計や拡張が可能になり、モジュール（プラグイン）的な拡張仕様として ERC-6900 が登場しています。
こうしたモジュール構造は便利ですが、外部コードを取り込む以上、以下を確認する必要があります。
- 信頼できるモジュールか
- 安全性は担保されているか
オンチェーンで監査を検証できれば、「このモジュールは安全と確認されているものだけ受け入れる」といった自動化が可能になります。
相互運用（フックやコールバック）
より多くのプロトコルが外部コントラクトと連携するためのフック（特定のタイミングで呼ばれる関数）を提供し、トークン標準の中にも転送時にコールバックを呼ぶ仕組み（ERC1155など）が広がっています。
外部のコントラクトを呼び出すということは、その先のコードが安全に動作することが大前提になります。
予期せぬ再入稿攻撃（reentrancy）や、エラー処理の不整合が起きる可能性もあります。
オンチェーンで監査内容を確認できれば、安全性が確認されたコントラクトだけを自動で許可する仕組みが作りやすくなります。
必要性の高まり
スマートコントラクトを利用したサービスやプロトコルは今後さらに増え、複合的な動作が求められていきます。
その中で、監査された事実をオンチェーンで保証する仕組みは、他のコントラクトが安心して連携するための基盤になります。
もちろん、監査情報があることは「バグが完全にない」ことを保証するわけではありません。
しかし、以下の要素はエコシステム全体のセキュリティを高める重要な土台となります。
- 信頼できる監査者の存在
- 準拠している仕様の明確化
- 監査データへのトラストレスなアクセス
オンチェーンで検証可能な監査情報が整備されることで、スマートコントラクト同士が安全に連携してより高度な仕組みを構築できる未来が開けます。
仕様
監査プロパティ
監査情報は、大きく「監査者の情報」と「監査内容そのもの」の2つの要素で構成されます。
監査者（Auditor）
監査者に関する情報は、以下の項目から構成されます。
| 項目 | 説明 |
|---|---|
name |
監査者の名前。ユーザーに表示するためのもの。 |
uri |
監査者についての追加情報を取得できるURI。 |
authors |
監査に実際に携わった人物のリスト。監査報告書の作成に関わった人を示す。 |
これらは、監査の信頼性を判断するうえで重要な情報となります。
監査内容（Audit）
監査されたコントラクトについて記述する項目です。
以下の内容を含む必要があります。
| 項目 | 説明 |
|---|---|
auditor |
監査者（Auditor 構造体）の情報。 |
auditedContract |
監査対象となるコントラクトのチェーンIDとデプロイ先アドレス。 |
issuedAt |
元となる監査（auditHash で識別される）が発行された日時。必須。 |
ercs |
実装されているERC規格番号のリスト。完全に準拠しているものだけを列挙。空でもよい。 |
auditHash |
元の監査レポートのハッシュ値。特定の監査に対応づけるため必須。 |
auditUri |
実際の監査レポートを取得できる URI。 |
特に auditHash により、オンチェーンの監査情報とオフチェーン文書が一致しているか確かめられます。
コントラクト情報
監査対象となるコントラクトを正確に識別するための情報です。
| 項目 | 説明 |
|---|---|
chainId |
EIP155形式のチェーンIDを bytes32 で表現したもの。 |
deployment |
コントラクトのデプロイされているアドレス。 |
これにより、メインネット・テストネットなどの区別や、対象コントラクトの一意性が担保されます。
EIP155については以下の記事を参考にしてください。
監査者の署名（Auditor Verification）
監査情報を信頼できる形で証明するため、署名方式が定義されています。
サポートされる署名方式
| 種類 | データ形式 |
|---|---|
| SECP256K1 | Ethereum の標準鍵方式。r, s, v のエンコード値。 |
| SECP256R1 |
r, s, v のエンコード値。 |
| ERC1271 | コントラクト署名検証方式。ABIエンコード形式を使用。 |
| BLS | 内容はTBD（未確定）。 |
特にERC1271による署名検証は、マルチシグなどコントラクトベースの署名方法を利用できるようにするために重要です。
ERC1271については以下の記事を参考にしてください。
署名方式（Signing）
監査サマリー（AuditSummary）の署名はEIP712によって行われます。
この署名方式は、構造化データに署名できるため、安全で信頼性が高く、ウォレットとの互換性も高い特徴があります。
EIP712については以下の記事を参考にしてください。
EIP712Domainは以下のように定義されます。
struct EIP712Domain {
string name;
string version;
}
EIP712Domain auditDomain = EIP712Domain("ERC-7652: Onchain Audit Representation", "1.0");
監査サマリーに署名を付与することで、SignedAuditSummary が生成されます。
これは、署名時刻（signedAt）と監査者の署名（auditorSignature）を含む拡張構造体です。
データ構造
ERC7652で実際に扱うデータ型の定義は以下です。
構造体
Auditor
struct Auditor {
string name;
string uri;
string[] authors;
}
監査者に関する情報を保持する構造体。
監査者の表示名、監査者に関する追加情報の参照先、監査に携わった著者の一覧を保持します。
監査の信頼性を判断するために必要な情報をまとめた構造体です。
パラメータ
-
name- 監査者の名前。
-
uri- 監査者に関する詳細情報を取得するためのURI。
-
authors- 監査を実施した人物（著者）のリスト。
Contract
struct Contract {
bytes32 chainId;
address deployment;
}
監査対象コントラクトを表す構造体。
どのチェーンにデプロイされているかを示す chainId と、そのコントラクトのアドレスを保持します。
監査対象を一意に識別するために使用されます。
パラメータ
-
chainId-
EIP155に基づくチェーンIDを
bytes32形式で保持する値。
-
EIP155に基づくチェーンIDを
-
deployment- コントラクトのデプロイアドレス。
AuditSummary
struct AuditSummary {
Auditor auditor;
uint256 issuedAt;
uint256[] ercs;
Contract auditedContract;
bytes32 auditHash;
string auditUri;
}
監査内容をオンチェーンで扱うための要約情報を表す構造体。
監査者の情報、監査が発行された日時、対象コントラクト、準拠するERC規格、監査レポートのハッシュ値など、監査を識別し検証するために必要な情報をまとめています。
パラメータ
-
auditor- 監査者を示す
Auditor構造体。
- 監査者を示す
-
issuedAt- 元の監査が発行された日時。
-
ercs- 対象コントラクトで実装されているERC規格番号の一覧。
-
auditedContract- 対象となるコントラクト情報。
-
auditHash- オリジナル監査レポートのハッシュ値。
-
auditUri- 監査レポートへアクセスできるURI。
Signature
enum SignatureType {
SECP256K1,
BLS,
ERC1271,
SECP256R1
}
struct Signature {
SignatureType type;
bytes data;
}
監査者の署名を表す構造体。
署名方式（SignatureType）と、署名データ（bytes）を保持します。
どの署名アルゴリズムで検証すべきかを指定できる仕組みです。
パラメータ
-
type- 使用された署名方式。
-
data- 署名データ（形式は署名方式によって異なる）。
SignedAuditSummary
struct SignedAuditSummary extends AuditSummary {
uint256 signedAt;
Signature auditorSignature;
}
署名付きの監査サマリーを表す構造体。
AuditSummary を継承し、署名された時刻と監査者の署名データを追加で保持します。
これにより、監査内容の正当性をオンチェーンで検証できるようになります。
パラメータ
-
signedAt- 監査サマリーが署名された時刻。
-
auditorSignature- 監査者の署名情報（
Signature構造体）。
- 監査者の署名情報（
EIP712Domain
struct EIP712Domain {
string name;
string version;
}
EIP712署名に使用するドメイン情報を表す構造体。
署名に名前とバージョンを付与し、データ構造の一貫性を保つために使用されます。
これにより、異なる用途の署名を混同しないようにしています。
パラメータ
-
name- ドメイン名。
-
version- ドメインのバージョン番号。
補足
ERC7652は、監査の「結果」や「指摘事項（findings）」そのものをオンチェーンの形式として定義していません。
これは、監査の指摘内容を標準化しようとすると、多くの複雑な問題が発生するためです。
監査レポートには、重大度（Severity）、問題の詳細、修正状況、影響範囲など、多くの項目が含まれます。
これらを完全に標準化するには、以下の議論が必要になります。
- 重大度をどの種類に分けるのか
- どの情報をオンチェーンに保存し、どの情報をオフチェーンに残すのか
- 監査会社ごとの差異をどう調整するか
このような背景から、ERC7652は「監査内容の指摘を定義すること」ではなく、「監査が存在することを証明し、その監査に関連する基本情報をオンチェーンで読み取れるようにすること」を目的としています。
ここで重要なのは、署名付きの監査サマリーが示す内容が以下の点に限定されていることです。
- 特定のコントラクトインスタンス（
chainId×deployment）が監査を受けた事実を示す - そのコントラクトが、監査時点で指定された ERC を正しく実装していることを示す
これは通常、監査の最終版に相当するもので、その監査と実際のデプロイ済みコントラクトを結びつける働きを持ちます。
ただし、ERC7652は「このコントラクトは完全に安全である」と証明するものではありません。**
あくまで「監査情報にアクセスしやすくする仕組み」であり、その情報の質や網羅性をどう評価するかは、利用する側（ブリッジ、プロトコル、アプリケーション）に委ねられています。
規格とERCの違い
監査対象をEVMベースのスマートコントラクトアカウントに限定することで、必要なパラメータをより明確に定義できるようになります。
範囲が広すぎると共通仕様を作ることが難しくなるため、EVMに焦点を絞る判断がされています。
chainId と deployment の扱い
コントラクトの挙動は、どのチェーンで動いているかによって変わる可能性があります。
そのため、ERC7652では監査対象を識別するため、必ず以下の2つをセットで記録します。
| 項目 | 意味 |
|---|---|
chainId |
コントラクトが動作するブロックチェーンのネットワーク識別子。 |
deployment |
デプロイされているコントラクトのアドレス。 |
この2つを組み合わせることで、同じコードでもネットワークごとに別の監査対象として扱うことができます。
単一コントラクトと複数コントラクト
実際の監査では、1回の監査で複数のコントラクトが対象になることは珍しくありません。
しかし、ERC7652の初期仕様では、シンプルさを優先して1つの AuditSummary には1つのコントラクトのみを紐づける設計を採用しています。
この設計の利点は以下のとおりです。
- コントラクトごとに正確に ERC 準拠状況を記録できる。
- 監査情報の取り扱いがシンプルになる。
一方、欠点としては、複数のコントラクトを監査した場合に、監査者が複数回署名しなければならない点があります。
なぜEIP712なのか
EIP712が採用されている理由は、すでに多くの開発ツールやウォレットでサポートされており、署名付き構造化データの扱いが標準化されているためです。
監査サマリーは構造化されたデータであるため、EIP712の形式に自然に適合します。
監査者に署名鍵を割り当てる方法
監査者は、自分の署名鍵の公開鍵部分を公開する必要があります。
公開方法としては、以下が利用できます。
また、将来的には監査者の鍵を集約する公開リポジトリを作ることもできますが、それはERC7652の範囲外とされています。
Polymorphic Contracts and Proxies
アップグレード可能なコントラクトやプロキシを持つ仕組みは、実際には広く使われていますが、ERC7652ではこれらを特別に扱うための仕様を定義していません。
実際の運用においては、監査者がどのように扱うか、この規格を利用する開発者がどのように判断するか委ねられています。
将来の拡張可能性
今後検討され得る拡張項目は以下です。
| 項目 | 内容 |
|---|---|
| 非EVMチェーンへの対応 | EVM以外のチェーンでも監査情報を扱える仕組みに拡張する可能性。 |
| polymorphic / upgradeable コントラクト対応 | プロキシやアップグレード構造体をより適切に扱う標準の追加検討。 |
| 監査者の鍵管理 | 署名鍵をより体系的に管理する方法の確立。 |
| 監査結果（findings）の標準化 | 監査指摘事項をどう標準化するかという課題への取り組み。 |
いずれも、エコシステムが成熟するにつれて重要性が増す分野であり、今後の発展が期待されています。
セキュリティ
監査者の鍵管理
ERC7652の仕組みは、監査者が適切に鍵を管理できていることを前提に成り立っています。
監査情報は署名とともにオンチェーンに登録されるため、署名に使用される鍵が信頼の根拠になります。
ところが、もし監査者の秘密鍵が漏えいした場合、攻撃者がその鍵を使って次のような偽装を行う可能性があります。
- 実際には監査を受けていないコントラクトに対して「監査済み」であるかのような署名を作成する。
- ERC規格に準拠していないコントラクトに対して「準拠している」と誤った情報を流す。
このような状況が起きると、ERC7652を利用するシステム全体の信頼性に大きな影響が出てしまいます。
鍵漏えいへの対策
鍵が漏えいした時の補償策として、監査者全体または組織単位での「監査者の集合体（association）」を定義する仕組みが考えられています。
これは監査会社全体を 1つのグループとして捉え、そのグループに「署名の取り消し権限（revocation key）」を与えるようなイメージです。
この方法では、個々の監査者が持つ署名鍵が漏えいした場合でも、同じ監査会社に属する別の鍵を使って以下の操作を行うことができます。
- 漏えいした鍵によって作成された署名を取り消す（revoke）
- 不正に関連づけられたコントラクト情報を無効化する
この仕組みがあれば、鍵漏えいによる影響を最小限に抑えることができ、監査情報の信頼性を維持しやすくなります。
この仕組みが重要な理由
ERC7652は「この監査情報は誰が署名したのか」を最も重要な信頼の出発点としています。
そのため、鍵が攻撃者に奪われると、不正な監査レポートが合法的なものとして扱われてしまいます。
監査情報の信頼が損なわれるということは、ブリッジ、トークン管理、プロトコル連携など多くのシステムに影響が及びます。
特に、ERC準拠の正当性チェックは自動化しやすいため、偽の監査結果が広がる危険性があります。
そのため、鍵管理と鍵漏えい時の対策は、ERC7652を活用するうえで避けて通れない重要なセキュリティ項目です。
引用
Richard Meissner - Safe (@rmeissner), Robert Chen - OtterSec (@chen-robert), Matthias Egli - ChainSecurity (@MatthiasEgli), Jan Kalivoda - Ackee Blockchain (@jaczkal), Michael Lewellen - OpenZeppelin (@cylon56), Shay Zluf - Hats Finance (@shayzluf), Alex Papageorgiou - Omniscia (@alex-ppg), "ERC-7512: Onchain Representation for Audits [DRAFT]," Ethereum Improvement Proposals, no. 7512, September 2023. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7512.
最後に
今回は「監査者の署名を使ってコントラクトの監査状況やERC準拠をオンチェーンで確認できる仕組みを提案しているERC7512」についてまとめてきました！
いかがだったでしょうか？
質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！
他の媒体でも情報発信しているのでぜひ他も見ていってください！