# [ERC7512] オンチェーンでコントラクト監査の検証を行える仕組みを理解しよう！ > この提案は、オンチェーン（ブロックチェーン上）で監査報告書を表現するための標準を作成することを目指しています。 - URL: https://cardene.dev/articles/4c174d7051247c490660 - 公開日: 2024-03-22 - 更新日: 2024-03-22 - トピック: Blockchain - タグ: ethereum, solidity, smartcontract, ブロックチェーン ## はじめに 初めまして。 **CryptoGames**というブロックチェーンゲーム企業でエンジニアをしている **cardene（かるでね）** です！ スマートコントラクトを書いたり、フロントエンド・バックエンド・インフラと幅広く触れています。 https://cryptogames.co.jp/ 代表的なゲームは**クリプトスペルズ**というブロックチェーンゲームです。 https://cryptospells.jp/ 今回は、コントラクト監査の透明性と安全性を向上させるために、オンチェーンでの検証などの仕組みを提案している**ERC7512**についてまとめていきます！ :::message 以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。 ::: https://eips.ethereum.org/EIPS/eip-7512 他にも様々なEIPについてまとめています。 https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4 ## 概要 この提案は、オンチェーン（ブロックチェーン上）で監査報告書を表現するための標準を作成することを目指しています。 この標準を用いることで、監査が誰によって実施され、どのような基準が検証されたかといった関連情報を、コントラクトが解析して抽出することが可能になります。 :::message 監査報告書をブロックチェーンに保存し、その内容を自動的に解析して、重要な情報を取り出すことができるようにするためのルールやフォーマットを定義することがこの提案の核心です。 このプロセスを通じて、透明性と信頼性が向上し、監査情報のアクセス性が改善されることが期待されます。 ::: ## 動機 スマートコントラクトのセキュリティフレームワークにおける監査の重要性についての説明です。 スマートコントラクトはブロックチェーンエコシステムの基盤を形成しており、ブリッジ、トークンコントラクト、スマートコントラクトアカウント（SCA）、相互運用性など、多岐にわたる用途に利用されています。 これらはそれぞれ異なる機能を持ち、ブロックチェーンの効率的な運用に寄与していますが、セキュリティ上の問題が発生すると大きなリスクをもたらす可能性があります。 そのため、監査はスマートコントラクトがセキュリティ基準やベストプラクティスに従っていることを確認し、**ERC20**や**ERC721**などの標準に正しく準拠しているかを検証するために不可欠です。 :::message **ERC20**については以下の記事を参考にしてください。 ::: https://chaldene.net/erc20 :::message **ERC721**については以下の記事を参考にしてください。 ::: https://chaldene.net/erc721 監査により、スマートコントラクトの安全性を高めることができますが、監査が実施されたことを検証するためには、オンチェーンの検証方法が必要です。 これにより、スマートコントラクトエコシステム全体のセキュリティ保証を強化し、分散型アプリケーション（DApps）の日々の運用におけるスマートコントラクトの利用と影響を安全に管理するための基盤を築くことができます。 提案されているシステムは、特定のコントラクトが監査されたことを確認することができる機能を提供し、これによりスマートコントラクトに関するイノベーティブなセキュリティシステムをオンチェーン上で構築するための重要な構成要素となります。 ただし、監査が実施されたという情報だけでは、コントラクトにバグや欠陥がないことを保証するものではありませんが、より安全なスマートコントラクトエコシステムを構築するための一歩となります。 ### 例 ![example_use_case.png](/images/qiita-af58195f-fd33-da2d-7506-8a9ac5f23a06.webp) 引用: https://eips.ethereum.org/EIPS/eip-7512 このシナリオでは、**ERC1155**トークンを扱うブリッジシステムの構築について考えています。 ブリッジシステムの目標は、新しいトークンを簡単に登録してブリッジできるスケーラブルなシステムを作ることです。 悪意のあるトークンや不具合のあるトークンが登録されるリスクを最小限に抑えるために、監査を用いてそれらをオンチェーンで検証します。 :::message **ERC1155**については以下の記事を参考にしてください。 ::: https://chaldene.net/erc1155 システムには4名の関係者がいます。 1. **ユーザー** - トークンをブリッジしたい最終的な利用者。 2. **ブリッジ運営者** - ブリッジを維持する運営者。 3. **ブリッジ** - ユーザーがブリッジ操作をトリガーするために交流するコントラクト。 4. **バリデーター**（検証者） - トークンがブリッジされることを検証するコントラクト。 プロセスは以下の手順に従います。 1. 最初に、ブリッジ運営者は、トークン登録プロセスで受け入れられる監査のキーまたはアカウントを特定の監査者から定義します。 2. これにより、ユーザー（またはトークン所有者）は登録フローをトリガーすることができます。 3. そして2つのステップが実行されます。 - 提供された監査が有効であり、信頼できる監査者によって署名されていることを検証します（ステップ4）。 - トークンコントラクトがブリッジがサポートするトークン標準（**ERC1155**）を実装していることを確認します（ステップ7）。 4. 監査とトークン標準の検証が完了した後でも、運営者による手動介入を設けて、トークンをブリッジ用にアクティブにすることが推奨されます（ステップ10）。 5. トークンがブリッジ上でアクティブになると、ユーザーはそれをブリッジすることができます（ステップ11）。 :::message このプロセスはトークンが安全にブリッジされるための複数の検証ステップを含み、悪意のあるまたは不具合のあるトークンがシステムに登録されることを防ぐことを目的としています。 ::: ## 仕様 ### プロパティ ブロックチェーン上で監査報告書を表現するためのプロパティ（属性）のセットについての説明です。 具体的には、監査者（Auditor）、監査（Audit）、そしてコントラクトに関連する情報を標準化するための構造を定義しています。 これらのプロパティは、監査情報をオンチェーンで扱う際の透明性と信頼性を高めるために設計されています。 #### 監査者（Auditor）に関するプロパティ - **name** - 監査者の名前。 - ユーザーに表示するために使われます。 - **uri** - 監査者についての詳細情報を取得できるURI。 - **authors** - この監査に貢献した著者のリスト。 - コントラクトを監査し、監査報告書を作成した人物が含まれるべきです。 #### 監査（Audit）に関するプロパティ - **auditor** - 監査者に関する情報。 - **auditedContract** - 監査が関連するコントラクトのchainIdおよびデプロイメントを含むべきです。 - **issuedAt** - オリジナルの監査（auditHashによって特定される）が発行された時の情報を含むべきです。 - **ercs** - 対象のコントラクトによって実装されているERCのリスト。 - リストされたERCは完全に実装されている必要があります。このリストは空でも構いません。 - **auditHash** - オリジナルの監査のハッシュ。 - 特定の監査に属する情報をオンチェーンで検証するために使用されます。 - **auditUri** - 監査を取得できるソースを指すべきです。 #### コントラクトに関するプロパティ - **chainId** - コントラクトがデプロイされたブロックチェーンの**EIP155**チェーンIDのbytes32表現。 - **deployment** - コントラクトのデプロイメントアドレスのアドレス表現。 :::message **EIP155**については以下の記事を参考にしてください。 ::: [\[EIP155\] Ethereumネットワークでリプレイ攻撃を防ぐ仕組みを理解しよう！](/articles/2526432899353e4a0225) これらのプロパティを使用することで、ブロックチェーン上で監査情報を効果的に管理し、ユーザーや他のコントラクトが監査されたコントラクトに関する信頼できる情報を簡単に取得できるようになります。 これは、デジタルアセットのセキュリティと透明性を高めるための重要なステップです。 ### 検証 監査者の検証に使用される署名の種類とデータ形式についての説明です。 ブロックチェーンやスマートコントラクトのコンテキストで、トランザクションやコントラクトの正当性を証明するためにデジタル署名が使用されます。 ここで挙げられているのは、署名アルゴリズムの種類と、それらのアルゴリズムによって生成される署名データの形式です。 #### 署名の種類 - **SECP256K1** - よく知られている楕円曲線暗号アルゴリズムで、特にビットコインやイーサリアムなどの多くのブロックチェーンで使用されています。 - このアルゴリズムによる署名データは、`r`、`s`、および`v`のエンコードされた表現です。 - **BLS** - 異なる特性を持つ署名アルゴリズムで、集約署名などの特別な機能に利用されます。 - このアルゴリズムの具体的なデータ形式は「未定義（TBD）」とされています。 - **ERC1271** - スマートコントラクトが署名の検証者として機能することを可能にするイーサリアムの標準です。 - データは`chainId`、`address`、`blocknumber`、および署名バイトのABIエンコードされた表現です。 :::message **ERC1271**については以下の記事を参考にしてください。 ::: [\[ERC1271\] コントラクトで署名を検証する仕組みを理解しよう！](/articles/da237b1b8cc185491512) - **SECP256R1** - SECP256K1と同様の楕円曲線暗号アルゴリズムでありながら、異なる楕円曲線を使用します。 - このアルゴリズムによる署名データも、`r`、`s`、および`v`のエンコードされた表現です。 #### データ これらの署名アルゴリズムで使用される「**データ**」とは、署名プロセスにおいて検証されるメッセージやトランザクションの内容を指します。 署名は、送信者がメッセージの内容を変更せずに送信したこと、そして送信者がそのメッセージまたはトランザクションを承認したことを証明するために使用されます。 この情報は、監査情報の検証プロセスを理解する上で重要です。 監査者による署名を正しく検証することで、ブロックチェーン上でのトランザクションや契約の信頼性と安全性を保証することができます。 ### データタイプ #### Auditor ```javascript struct Auditor { string name; string uri; string[] authors; } ``` **概要** 監査者の基本情報を格納するための構造体。 **詳細** この構造体は、監査を行う人物や組織に関する情報を表します。 名前、情報へのURI、および監査に貢献した著者のリストを含みます。 **パラメータ** - `name` - 監査者の名前。 - `uri` - 監査者に関する追加情報へのURI。 - `authors` - 監査に貢献した人々の名前のリスト。 #### コントラクト ```javascript struct Contract { bytes32 chainId; address deployment; } ``` **概要** ブロックチェーン上でデプロイされたコントラクトに関する情報を格納するための構造体。 **詳細** この構造体は、コントラクトがデプロイされたブロックチェーンの識別子と、コントラクトのデプロイメントアドレスを含みます。 これにより、特定のコントラクトを一意に識別することができます。 **パラメータ** - `chainId` - コントラクトがデプロイされたブロックチェーンの識別子。 - `deployment` - コントラクトのデプロイメントアドレス。 #### AuditSummary ```javascript struct AuditSummary { Auditor auditor; uint256 issuedAt; uint256[] ercs; Contract auditedContract; bytes32 auditHash; string auditUri; } ``` **概要** 監査の要約情報を格納するための構造体。 **詳細** この構造体は、監査に関する重要な情報をまとめています。 監査者の情報、監査が発行された日時、監査されたコントラクトが実装している**ERC**標準、監査されたコントラクトに関する情報、監査のハッシュ値、および監査報告書が公開されているURIを含みます。 **パラメータ** - `auditor` - 監査を行った監査者に関する情報です。 - `issuedAt` - 監査が発行された日時のタイムスタンプです。 - `ercs` - 監査されたコントラクトが実装している**ERC**標準のリストです。 - `auditedContract` - 監査されたコントラクトに関する情報です。 - `auditHash` - 監査のハッシュ値です。 - これにより、監査報告書のオンチェーンでの検証が可能になります。 - `auditUri` - 監査報告書が公開されているURIです。 ### 署名 #### EIP712Domain ```javascript struct EIP712Domain { string name; string version; } ``` **概要** **EIP712**標準に基づくメッセージ署名のためのドメイン情報を定義する構造体。 **詳細** **EIP712**は、イーサリアム上での構造化データ署名を可能にする標準です。 この`EIP712Domain`構造体は、署名されるデータがどのドメイン（アプリケーションやコントラクト）に属しているかを定義するために使用されます。 `name`と`version`属性によって、特定のドメインの名前とバージョンが指定されます。 **パラメータ** - `name` - ドメインの名前。 - `version` - ドメインのバージョン。 #### SignatureType ```javascript enum SignatureType { SECP256K1, BLS, ERC1271, SECP256R1 } ``` **概要** 署名の種類を表す列挙型。 **詳細** この列挙型は、使用される署名アルゴリズムのタイプを指定するために使用されます。 `SECP256K1`、`BLS`、`ERC1271`、`SECP256R1`の4つの署名タイプが定義されており、それぞれ異なる特性や用途を持っています。 **パラメータ** - 署名アルゴリズムのタイプを指定します。 #### Signature ```javascript struct Signature { SignatureType type; bytes data; } ``` **概要** 署名情報を格納するための構造体。 **詳細** `Signature`構造体は、署名のタイプ（`SignatureType`）と、署名データそのもの（`data`）を含みます。 この構造体は、様々なタイプのデジタル署名を一般的な形式で表現するために使用されます。 **パラメータ** - `type` - 署名のタイプ。 - `data` - 署名データ本体。 #### SignedAuditSummary ```javascript struct SignedAuditSummary extends AuditSummary { uint256 signedAt; Signature auditorSignature; } ``` **概要** 署名された監査要約情報を格納するための構造体。 **詳細** `SignedAuditSummary`構造体は、`AuditSummary`に署名時刻（`signedAt`）と監査者の署名（`auditorSignature`）を追加したものです。 これにより、監査要約が特定の監査者によって承認され、その時刻に署名されたことが証明されます。 **パラメータ** - `signedAt` - 署名された時刻です。 - `auditorSignature` - 監査者による署名情報です。 これらの定義を通じて、**EIP712**を利用した構造化データの署名プロセスが可能になり、監査情報の真正性と不変性を保証することができます。 :::message **ERC712**については以下の記事を参考にしてください。 ::: [\[EIP712\] 型付き構造化データのハッシュ化と署名の仕組みを理解しよう！](/articles/f54bc85cb66de5a54257) ## 補足 このERC（イーサリアムリクエストコメント）は、監査の結果については意図的に定義していません。 監査結果を定義するには、サポートされる重大度の定義、オンチェーン対オフチェーンで保存されるべき監査結果のデータ、および他の類似した監査関連属性について合意を取る必要がありますが、これらは厳格に記述するのが難しいためです。 この課題の複雑さを考慮して、このEIP（イーサリアム改善提案）ではこの課題を範囲外としています。 重要な点として、このERCは署名された監査要約が、特定のコントラクトインスタンス（その`chainId`とデプロイメントによって指定される）がセキュリティ監査を受けたことを示すものと提案しています。 さらに、このコントラクトインスタンスがリストされた**ERC**を正しく実装していることも示します。 これは通常、コントラクトの最終監査リビジョンに対応し、そのデプロイメントに接続されます。 このERCはコントラクトのセキュリティの証明とは見なされるべきではなく、むしろスマートコントラクトに関連するデータを抽出する方法論として考えるべきです。 データの品質、範囲、および保証の評価は、このERCを統合する側に委ねられます。 :::message この提案はスマートコントラクトが監査され、特定の**ERC**標準を実装していることを示す手段を提供しますが、そのセキュリティや品質を保証するものではありません。 それは、監査されたデータを活用する開発者や組織が、その品質や適用性を自身で評価するためのフレームワークを提供するものです。 ::: ### 考察 スマートコントラクトの監査に関連する追加の考慮事項について説明しています。 ##### 標準とERC EVM（Ethereum Virtual Machine）ベースのスマートコントラクトアカウントに関連する監査の範囲を限定することで、パラメータの定義がより明確になります。 ##### chainIdとデプロイメント コントラクトの振る舞いは、そのコントラクトがデプロイされたブロックチェーンに依存するため、監査に関連する各コントラクトには`chainId`（チェーン識別子）とデプロイメントアドレスが関連付けられます。 ##### コントラクトと複数のコントラクト 多くの監査は、プロトコルを構成する複数のコントラクトに関連しています。 このERCの初期バージョンの単純さを保つために、1つの監査要約につき1つのコントラクトのみを参照することにしました。 同じ監査活動で複数のコントラクトが監査された場合、同じ監査要約を異なるコントラクトインスタンスに関連付けることができます。 これにより、コントラクトインスタンスがサポートするERCを適切に関連付けることができますが、監査者による複数回の署名が必要となるという主な欠点があります。 ##### なぜEIP712か？ **EIP712**は、そのツール互換性（例えば署名のため）のために基盤として選ばれました。 ##### 監査者に特定の署名キーを割り当てる方法は？ 監査者は署名の公開部分を公に共有するべきです。 これは、彼らのウェブサイト、プロフェッショナルページ、その他のソーシャルメディアを通じて行うことができます。 このERCの拡張として、公開リポジトリを構築することが可能ですが、これはERCの範囲外です。 ##### ポリモーフィックコントラクトとプロキシ このERCは、ポリモーフィックコントラクトとプロキシについて明示的には触れていません。これらは考慮すべき重要な要素ですが、その適切な管理は監査者およびこのERCの実装者に委ねられます。 :::message これらの追加の考慮事項は、スマートコントラクトの監査プロセスをより具体的に定義し、監査の信頼性と有効性を高めるための指針を提供します。 同時に、監査プロセスの柔軟性と適用性を確保するための課題にも対処しています。 ::: ### 拡張 将来の拡張性に関して、スマートコントラクトの監査に関連するERC（イーサリアムリクエストコメント）の可能性について述べています。 #### 非EVMチェーンへの対応拡大 現在のERCは、EVM（イーサリアム仮想マシン）ベースのチェーンに焦点を当てていますが、将来的にはEVM以外のブロックチェーン、例えばSolanaやPolkadotなど、異なる仮想マシンを使用するチェーンにも対応を拡大する可能性があります。 これにより、より広範なブロックチェーンエコシステムでの監査標準の統一と利用が期待できます。 #### 多態性（ポリモーフィック）/アップグレード可能なコントラクトと複数コントラクト監査へのサポート強化 多態性のあるコントラクトやアップグレード可能なコントラクト、または複数のコントラクトからなるプロトコルの監査へのサポートを強化することが検討されています。 これらのタイプのコントラクトは、現在のERCでは完全には対応していない複雑な構造を持つため、より適切な管理と標準化が必要です。 #### 監査者の署名キーの管理 監査者が監査報告を署名する時に使用するキーの管理に関するより明確なガイドラインまたは機能の導入が検討されています。 これは、監査の真正性と監査者の認証を強化するために重要です。 #### 監査結果の定義 監査の結果や所見に関するより詳細な定義や標準化が検討されています。 現在、監査の所見はオンチェーンに記録するには複雑すぎると考えられていますが、将来的にはこれらの情報を適切に管理し、利用者が容易にアクセスできるような方法が模索されています。 これらの将来の拡張は、スマートコントラクトの監査プロセスをさらに進化させ、ブロックチェーンエコシステム全体での安全性、透明性、および信頼性の向上を目指しています。 ## 互換性 現在のERC規格との互換性の問題は確認されていません。 ## セキュリティ ### 監査者のキーマネジメント このERC（イーサリアムリクエストコメント）の前提は、システムに参加する監査者による適切なキーマネジメントに依存しています。 監査者のキーが侵害された場合、彼らは標準に準拠していない可能性のあるコントラクトに対して、見かけ上監査されたり、ERC準拠であるかのように関連付けられるかもしれません。 キーが漏洩した場合の二次的なセキュリティ対策として、既存の監査者の署名を取り消すことができる二次キーを許可する「**監査者協会**」を定義することが、潜在的な保護策として提案されています。 この提案は、監査プロセスの信頼性とセキュリティを保持するために重要です。 監査者のキーが漏洩すると、信頼できないコントラクトが監査済みや規格準拠として誤って認識されるリスクがあります。 このリスクを軽減するために、監査者のキーマネジメントは非常に重要です。 #### 提案された保護策 - **監査者協会** - 監査会社などの監査者グループを形成し、このグループが監査者に代わってキーマネジメントの責任を負います。 - **二次キー** - 監査者のキーが侵害された場合に、既存の署名を取り消すための追加のセキュリティ対策として、二次キーを使用することが提案されています。 このようなシステムにより、監査者のキーが侵害された場合でも監査プロセスの整合性を保護し、監査されたコントラクトの信頼性を維持することが可能になります。 ## 引用 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. ## 最後に 今回は「コントラクト監査の透明性と安全性を向上させるために、オンチェーンでの検証などの仕組みを提案している**ERC7512**」についてまとめてきました！ いかがだったでしょうか？ 質問などがある方は以下の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