LoginSignup
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@cardene(かるでね)

[ERC7741] EIP712を使用してメタトランザクションを実行する仕組みを理解しよう！

Posted at

はじめに

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

今回は、EIP712を活用してガスレスでトランザクションを実行してもらう仕組みを提案しているERC7741についてまとめていきます！

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

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

概要

ERC7741は、EIP712に基づく署名を活用し、オペレーター（代理人）を管理するためのメタトランザクションやアトミックなコントラクト実行を可能にする一連の関数を提案しています。
EIP712は、ブロックチェーン上の署名データに明確な型情報を付与することでセキュリティと利便性を向上させる規格です。
この仕組みを利用することで、ユーザーはブロックチェーン上で直接トランザクションを実行することなく（特定のアドレスにガス代を負担しつつ処理を実行してもらう）、オペレーターの権限を設定・変更することができます。

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

動機

ERC7741の主な目的は、オペレーター管理の柔軟性、安全性、効率性を向上させることです。
特に、EIP712の署名方式を採用することで、ユーザーはガス代（トランザクション手数料）を支払わずにオペレーターを認証・管理できるようになり、エンドユーザーの利便性が大きく向上します。

また、この標準が解決しようとする課題は以下の通りです。

メタトランザクションの実現

メタトランザクションとは、ユーザー自身が直接ブロックチェーン上でトランザクションを送信するのではなく、第三者（リレイヤーやオペレーター）が代理で実行する仕組みです。
EIP712署名を利用すれば、ユーザーはオフチェーン（ブロックチェーン外）でオペレーターに権限を与えることができ、実際のトランザクションはオペレーターが送信します。
このため、ユーザーはネイティブトークン（ETHやMATICなど）を持っていなくても、ブロックチェーン上で何らかの処理の実行が可能になります。
特に、頻繁なオペレーター変更が求められるシナリオでは、トランザクションコストの削減と利便性の向上に貢献します。

セキュリティの向上

EIP712の署名方式を採用することで、より安全なメッセージ署名が可能になります。
従来の単純なハッシュデータに署名する方式（EIP191など）では、メッセージの意味が分かりにくく、フィッシング攻撃のリスクが高まる問題がありました。
EIP712では、署名対象のデータに型情報を付与して構造化されたメッセージを作成するため、ユーザーは何に署名しているのかを明確に認識できます。
これにより、誤った操作を防ぎ、安全性が向上します。

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

相互運用性

この標準は、オペレーター管理のための統一されたインターフェースを提供します。
これにより、異なるコントラクトやプロトコル間でのオペレーター管理が統一されて開発者の負担が軽減されます。
特に、さまざまなVaultプロトコルにおいて、オペレーターが資産管理を行うケースでは、この標準を採用することで互換性が確保され、異なるプラットフォーム間での統合が容易になります。

Vaultとは、ブロックチェーンにおいて資産を管理・運用するためのコントラクトのことを指します。
特に、DeFi（分散型金融）においてよく使用されており、ユーザーがトークンを預けてステーキング、利回りの最適化、資産の自動運用などを行う仕組みを提供します。

クロスチェーン環境での運用の簡素化

複数のブロックチェーンをまたいでオペレーターを管理する場合、一貫した権限管理を維持することは大きな課題となります。
この標準を導入することで、オフチェーン署名によるオペレーターの設定や権限移行が容易になり、異なるチェーン間での操作の一貫性を保つことができます。
特に、クロスチェーンでの資産管理を行うプロジェクトにとっては、運用の負担を大幅に軽減できます。

仕様

ERC7741は、オペレーター（代理人）を管理するためのEIP712署名方式に基づく承認スキームを定義しています。
これにより、EIP6909やEIP7540といった既存のオペレーター管理プロトコルと互換性を持ち、コントラクトが一貫した方法でオペレーターの設定や権限管理を行えるようになります。

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

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

オペレーター対応コントラクト

この承認スキームを適用できるのは、IOperatorインターフェースを実装したコントラクトです。
このインターフェースには、以下のような機能が含まれています。

OperatorSet

ownerが特定のオペレーター（operator）に権限を付与または取り消した時に発行されるイベントです。
これにより、オフチェーンでオペレーターの変更履歴を追跡できます。

setOperator関数

オペレーターの権限を設定または解除する関数です。
外部からの呼び出しが可能であり、指定したオペレーターに対してapproved（承認または非承認）を設定します。

isOperator関数

指定されたownerとオペレーターの組み合わせが現在承認されているかどうかを確認する関数です。
オペレーターが権限を持っているかどうかをブール値（trueまたはfalse）で返します。

EIP6909では、オペレーター（operator）の代わりに「spender」という名称を使用するなど、引数の命名には若干の違いがありますが機能自体は同じであるため、この規格と互換性を持たせることが可能です。

関数

authorizeOperator

EIP712署名を使用して、ownerがオペレーターに対して特定の権限を付与または取り消す関数。
メタトランザクションを活用することで、owner自身が直接トランザクションを送信することなく、オフチェーンで署名するだけでオペレーターの管理が可能になります。

関数の動作として、以下の条件を満たす必要があります。

  • 期限（deadline）が過ぎていた場合、トランザクションを失敗させる

署名の有効期限が過ぎた場合、トランザクションが実行されないようにすることで、古い署名が悪用されることを防ぎます。

  • 署名のnonceを無効にする

nonceとは、一度しか使用できない一意の値のことです。
これをトランザクションごとに無効化することで、リプレイ攻撃（過去の署名を再利用して不正にトランザクションを実行する攻撃）を防ぎます。

  • EIP712署名が正しいことを検証し、不正な署名の場合はトランザクションを失敗させる

った署名や不正な署名が使われた場合、関数の実行を拒否します。

  • オペレーターのステータスをapprovedの値に設定する

approvedがtrueの場合、オペレーターを有効化し、falseの場合は権限を取り消します。

  • OperatorSetイベントを発行する

ブロックチェーン上にオペレーターの設定変更を記録し、外部のアプリケーションが履歴を追跡できるようにします。

この関数は、実行が成功するとtrueを返します。

invalidateNonce

owner（msg.sender）が特定のnonceを無効化する関数。

EIP712署名を使用する場合、悪意のある第三者が過去の署名を不正に再利用するリスクがあります。
そのため、ownerは不要になったnonceを明示的に無効にすることで、より高いセキュリティを確保できます。

この関数を実行すると、指定したnonceは二度と使用できなくなります。

authorizations

特定のcontrollerとnonceの組み合わせがすでに使用されたか確認する関数。

  • controller（管理者アドレス）
    • 署名を検証するコントラクトまたはエンティティのアドレス。
  • nonce
    • 一意の値で、既に使用されていればtrue、未使用ならfalseを返す。

この機能により、ownerは過去に使用した署名が再利用されるリスクを管理できます。

DOMAIN_SEPARATOR

EIP712で定義されたドメインセパレーターを取得する関数。

ドメインセパレーターとは、異なるブロックチェーンやコントラクト間でのリプレイ攻撃を防ぐために設計された一意の識別子です。

具体的には、以下の情報を組み合わせた値になります。

  • コントラクトのアドレス
  • チェーンID（EthereumやPolygonなどのネットワーク識別子）
  • 特定のメッセージスキーマ

このセパレーターを使用することで、攻撃者が別のブロックチェーン上で同じ署名を流用して不正なトランザクションを実行することを防げます。

ERC165のサポート

ERC7741を実装するコントラクトは、ERC165のsupportsInterface関数を実装する必要があります。

ERC165は、コントラクトがどのインターフェースを実装しているかを識別するための規格です。

具体的には、supportsInterface関数に0xa9e50872という定数を渡した場合、trueを返す必要があります。
これにより、外部のアプリケーションやコントラクトが、この標準を正しく実装しているかを判別できます。

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

補足

ERC2612との類似性

ERC7741は、ERC2612（Permit）と意図的に似た仕様になっています。
その目的は、既にERC2612を実装しているプロジェクトがスムーズにこの規格を導入できるようにすることです。

ERC2612は、EIP712署名を利用して、トークンの承認をオフチェーンで行う規格です。
本来、ERC20トークンのtransferを第三者（たとえばDeFiプロトコル）に許可するには、approve関数を使ってトランザクションを送信する必要があります。
しかし、ERC2612を使うと、トランザクションを発行せずにオフチェーンで署名を作成し、それをオペレーターに渡すことで承認が完了します。
これにより、ユーザーはガス代を削減しつつ、よりスムーズなトランザクション処理が可能になります。

ERC7741も同じく、EIP712署名を利用してオペレーターを承認する仕組みを提供しており、その基本的な設計思想はERC2612と一致しています。

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

ERC2612との主な違い

ERC7741とERC2612の大きな違いは、nonceをbytes32型にしている点です。

ERC2612では、nonceはuint256型を使用しており、基本的に自動でインクリメントされる値です。
つまり、nonceは「0 → 1 → 2 → 3…」というように、順番に使用されることが前提になっています。
この仕組みは単純で理解しやすいですが、以下のような制約が生じます。

  • 未使用のnonceを飛ばすことができない

ERC2612のuint256型のnonceは、順番通りに消費しなければならないため、未使用のnonceを飛ばすとエラーになります。
例えば、nonceが「5」の状態で「7」のnonceを使おうとすると、nonce「6」が飛ばされるため、承認されません。

  • 複数の署名を並列で処理しにくい

ユーザーが並行して異なるトランザクションを処理しようとすると、どのnonceが次に使われるかを正確に管理する必要があり、並列処理が難しくなります。

一方、ERC7741ではnonceをbytes32型にすることで、順序に依存しないnonce管理を可能にしています。

  • nonceの順番を気にせず使用できる

bytes32型のnonceは、単調増加する必要がなく、ランダムな値を使用できます。
例えば、あるオペレーターが「0xabc123」、別のオペレーターが「0xdef456」といった異なるnonceを自由に使用できます。

  • 並列処理が容易になる

nonceの順番を厳密に管理する必要がないため、ユーザーは複数の異なるオペレーターに対して、並行して異なるトランザクションを発行できます。
これにより、マルチスレッド環境や分散処理を行うコントラクトとの相性が良くなります。

参考実装

// This code snippet is incomplete pseudocode used for example only and is no way intended to be used in production or guaranteed to be secure

bytes32 public constant AUTHORIZE_OPERATOR_TYPEHASH =
    keccak256("AuthorizeOperator(address controller,address operator,bool approved,bytes32 nonce,uint256 deadline)");

mapping(address owner => mapping(bytes32 nonce => bool used)) authorizations;

function DOMAIN_SEPARATOR() public view returns (bytes32) {
  // EIP-712 implementation 
}

function isValidSignature(address signer, bytes32 digest, bytes memory signature) internal view returns (bool valid) {
  // ERC-1271 implementation 
}

function authorizeOperator(
    address controller,
    address operator,
    bool approved,
    bytes32 nonce,
    uint256 deadline,
    bytes memory signature
) external returns (bool success) {
    require(block.timestamp <= deadline, "ERC7540Vault/expired");
    require(controller != address(0), "ERC7540Vault/invalid-controller");
    require(!authorizations[controller][nonce], "ERC7540Vault/authorization-used");

    authorizations[controller][nonce] = true;

    bytes32 digest = keccak256(
        abi.encodePacked(
            "\x19\x01",
            DOMAIN_SEPARATOR(),
            keccak256(abi.encode(AUTHORIZE_OPERATOR_TYPEHASH, controller, operator, approved, nonce, deadline))
        )
    );

    require(SignatureLib.isValidSignature(controller, digest, signature), "ERC7540Vault/invalid-authorization");

    isOperator[controller][operator] = approved;
    emit OperatorSet(controller, operator, approved);

    success = true;
}

function invalidateNonce(bytes32 nonce) external {
    authorizations[msg.sender][nonce] = true;
}

セキュリティ

オペレーターの管理と署名のリスク

オペレーターは、ユーザーの資産やリソースを管理する権限を持つため影響力が大きいです。
EIP712署名を使用したオペレーター承認では、ユーザーが一度署名したメッセージが悪用される可能性があるため慎重な管理が必要になります。

署名が何らかの理由で漏洩して第三者に不正に利用されるなどリスクがあります。
このように、オペレーターが正しく管理されなかった場合、ユーザーの資産が予期せぬ方法で移動されたり、制御不能な状態に陥る可能性があります。

署名の有効期限を短くするべき理由

EIP712による署名は、一度作成されると第三者に渡らない限り、ブロックチェーン上で変更・キャンセルすることができません。
そのため、未使用の署名が流出すると攻撃者が悪用するリスクが生じます。

例えば、ユーザーがオペレーターを承認する署名を作成し、その署名が何らかの形で漏洩した場合オペレーターが意図しない操作を行う可能性があります。
この問題を最小限に抑えるために、署名の有効期限を可能な限り短く設定することが重要です。

有効期限が長すぎると、以下のようなリスクが高まります。

  • 漏洩した署名の悪用リスクが増大する

もし署名が流出した場合、攻撃者は期限が切れるまでそれを利用できるため、被害が発生する可能性が高くなります。

  • ユーザーが意図しない時点でオペレーターが操作を実行する可能性がある
    例えば、ユーザーがオペレーターの権限を与えたものの、そのオペレーターがすぐに実行しなかった場合、後になってユーザーの意図と異なる状況で操作される可能性があります。

  • 署名をキャンセルする手段が限られる

一度発行された署名は、オフチェーンで管理されるため、ブロックチェーン上で直接取り消すことはできません。
短い有効期限を設定することで、署名が未使用のまま残るリスクを低減できます。

短い有効期限の設定がもたらす安全性の向上

署名の有効期限を短くすることで、オペレーター管理における安全性を大幅に向上させることができます。
具体的には、次のようなメリットがあります。

  • 署名が漏洩した場合でも、短期間で無効化されるため悪用される可能性が低くなる。
  • ユーザーが意図したタイミングでのみオペレーターが操作を実行できるようになる。
  • 署名の取り消しができなくても、期限切れによって自然に無効化されるため不要なリスクを最小限に抑えられる。

特に、クロスチェーン環境や頻繁にオペレーターを変更するケースでは、長期間有効な署名を使用するとリスクが高まるため、できるだけ短い有効期限を設定することが望ましいです。

引用

Jeroen Offerijns (@hieronx), João Martins (@0xTimepunk), "ERC-7741: Authorize Operator [DRAFT]," Ethereum Improvement Proposals, no. 7741, June 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7741.

最後に

今回は「EIP712を活用してガスレスでトランザクションを実行してもらう仕組みを提案しているERC7741」についてまとめてきました！
いかがだったでしょうか？

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

Twitter @cardene777

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

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?