---
title: "メタトランザクション(ERC-2771)とは?"
description: "メタトランザクションについて、ガス代を軸に解説し、それが最適な解決策ではなくなった理由を説明します。"
---

# メタトランザクション(ERC-2771)とは?

すべてのEthereumトランザクションはガスを使用し、各トランザクションの送信者はガス代を支払うのに十分なEtherを保有している必要があります。これにより、新規ユーザーはdappを使い始める前にEtherを購入する必要が生じ（これは面倒な作業になり得ます）、ユーザーオンボーディングにおける大きな障壁となっています。

いわゆる「メタトランザクション」は、ユーザーに代わってガス代を支払うことを可能にしました。

しかし、こうしたソリューションの多くは[Account Abstraction（ERC-4337）インフラへ移行しつつあります](http://www.alchemy.com/overviews/4337-vs-2771)。これはガスの抽象化に関してより有望で洗練された方法であり、多くの機能を備えているためです。

## メタトランザクションとは何か

メタトランザクションのアイデアはシンプルです。Relayerと呼ばれる第三者が、ユーザーに代わってトランザクションを送信し、ガス代を支払います。

ユーザーは、実行されるトランザクションの情報を含むメッセージ（できればEIP-712準拠のもの）に署名します。

署名されたメッセージはRelayerに渡され、Relayerは自身が対価を得られるかどうかを検証し（これはオプションの場合もあり、詳細は後述します）、ガス代を支払うのに十分な資金があるかを確認し、ネイティブトランザクションに署名して実行のために送信する責任を負います。

OpenZepplinのRelayerを例に、メタトランザクションを理解していきましょう。

<ImageBlock
  src="https://media.alchemy.com/1703861042-meta-transactions.gif"
  alt="メタトランザクションのアニメーション図：ユーザーがメッセージに署名し、Relayerがそれを送信してガス代を支払う"
  width={720}
  height={405}
  caption="メタトランザクションのステップバイステップガイド"
/>

## メタトランザクションリクエストはどのようなものか

サンプルのメタトランザクションメッセージは以下のようになります。

<ImageBlock
  src="https://media.alchemy.com/1703861080-sample-meta-transaction.jpeg"
  alt="NFTをミントするサンプルのメタトランザクションメッセージ。fromアドレスとcallデータを表示"
  width={1194}
  height={632}
  caption="サンプルのメタトランザクション"
/>

上記のメッセージはNFTをミントするものであり、fromアドレス0x7099797...によって署名されます。

メッセージが署名されると、クライアント（またはユーザー）はメタトランザクションリクエスト（下記参照）を作成できます。これはPOSTリクエストとしてAutotaskに送信されます。AutotaskはWebhookであり、呼び出されると内部的にRelayerの秘密鍵を使ってネイティブトランザクションに署名します。

<ImageBlock
  src="https://media.alchemy.com/1703861109-meta-transaction-post-request.jpeg"
  alt="Autotask relayer webhookに送信されるメタトランザクションのPOSTリクエストペイロード"
  width={2264}
  height={726}
  caption="メタトランザクションのPOSTリクエスト"
/>

## メタトランザクションのRelayerとは何か

Relayerとは、ユーザーのガス代をスポンサーするための資金を保有するEthereumアカウントです。このアカウントの秘密鍵は、プロバイダーのサーバー上の安全なvaultに保管されます。

開発者はRelayerに資金を送金することで、ユーザーのトランザクション手数料をカバーできます。

開発者は好きなだけRelayerを立ち上げることができますが、それぞれ個別にETHで資金を供給する必要があります。

OZ Relayでは、Relayerの一時停止、Whitelistされたアドレスからのリクエストの受け入れ、Gas Price Cappingが可能です。必要であれば、さらに条件付きロジックをAutotaskにプログラムすることもできます。

なお、ユーザーが定義したトランザクションは、現在Relayerのネイティブトランザクションのdataフィールド内に格納されています。メタトランザクションとは、あるトランザクションの中に入った別のトランザクションなのです。

## メタトランザクションにおけるMinimalForwarderとは何か

ここまで、オンチェーンでの検証は一切行われていません。ここで登場するのがMinimalForwarderです。

MinimalForwarderは、ユーザーが署名したメッセージの妥当性とリプレイ保護を検証するオンチェーンのスマートコントラクトです。

<CodeSnippet code={`struct ForwardRequest {
    address from;
    address to;
    uint256 value;
    uint256 gas;
    uint256 nonce;
    bytes data;
}

function verify(ForwardRequest calldata req, bytes calldata signature) public view returns (bool) {

    address signer = _hashTypedDataV4(
        keccak256(
            abi.encode(
                _TYPEHASH,
                req.from,
                req.to,
                req.value,
                req.gas,
                req.nonce,
                keccak256(req.data)
            )
        )
    ).recover(signature);

    return _nonces[req.from] == req.nonce && signer == req.from;

}`} language="text" theme="dark" />

検証に成功すると、MinimalForwarderは適切なcalldataを使ってリクエスト先のコントラクトを呼び出すことで、トランザクションを実行します。

<CodeSnippet code={`function execute(ForwardRequest calldata req, bytes calldata signature)
        public
        payable
        returns (bool, bytes memory)
{
    require(verify(req, signature), "MinimalForwarder: signature does not match request");
    _nonces[req.from] = req.nonce + 1;

    (bool success, bytes memory returndata) = req.to.call{gas: req.gas, value: req.value}(abi.encodePacked(req.data, req.from));

    // Validate that the relayer has sent enough gas for the call.
    // See
    if (gasleft() <= req.gas / 63) {
        // We explicitly trigger invalid opcode to consume all gas and bubble-up the effects, since
        // neither revert or assert consume all gas since Solidity 0.8.0
        //
        /// @solidity memory-safe-assembly
        assembly {
            invalid()
        }
    }

    return (success, returndata);

}`} language="text" theme="dark" />

ここにメタトランザクションの欠点も現れます。というのも、MinimalForwarderが呼び出すコントラクト側で、MinimalForwarderがユーザーに代わってそのコントラクトを呼び出せるようにする必要があるからです。

## ERC-2771とは何か

最終的に、呼び出しが目的のターゲットコントラクトに到達したとき、そのコントラクトはRelayerのトランザクションの中にネストされた、元のユーザー（_msg.sender_）とcalldata（_msg.data_）を特定できる必要があります。このプロセスを標準化するために[ERC2771](https://eips.ethereum.org/EIPS/eip-2771)が提案されました。

OpenZepplinは、[ERC2771Context](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/metatx/ERC2771Context.sol)というユーティリティコントラクトを提供しており、スマートコントラクト開発者がMinimalForwarderから送られてきたデータから、本来のmsg.senderとmsg.dataを容易に取り出せるようにしています。

<CodeSnippet code={`contract YourContract is ERC2771Context {
    constructor(MinimalForwarder forwarder, string memory uri_)
        ERC2771Context(address(forwarder))
    {}

    // Depending on whether the call is made by the \`MinimalForwarder\` or not the \`msg.sender\` and \`msg.data\` will be inferred accordingly

}`} language="text" theme="dark" />

各スマートコントラクトはメタトランザクションの読み取り方法を知っておく必要があるため、すでにデプロイ済みのコントラクトに対してこれを実装するのは難しく、バグの原因にもなりかねません。

他にも多くのメタトランザクションインフラサービスが存在しますが、そのいずれも_msg.sender_と_msg.data_を導出するために、対象コントラクトがEIP-712またはEIP-2771ベースのコントラクトを継承していることを要求します。

この標準は優れたものですが、遡及的には機能しません。これが、ERC-4337が作られた理由であり、既存の多くのERC-2771ソリューションを置き換えつつあります。

## よくある質問

### メタトランザクションとは何か

メタトランザクションは、Relayerと呼ばれる第三者がユーザーに代わってトランザクションを送信しガス代を支払うことを可能にする仕組みで、ユーザーが[アプリ](https://www.alchemy.com/dapps/top/defi-dapps)を利用する前にEtherを保有していなければならないという障壁を取り除きます。

### メタトランザクションはどのように機能するか

ユーザーはトランザクション情報を含むメッセージに署名し、それがRelayerに渡されます。Relayerはリクエストを検証し、ガス代を支払い、ネイティブトランザクションに署名して、ブロックチェーン上での実行のために送信します。

### ERC-2771とは何か

ERC-2771は、信頼されたforwarderを通じてメタトランザクションを受け取った際に、スマートコントラクトが元のユーザーとcalldataを特定できるようにする標準であり、正しいmsg.senderとmsg.dataの抽出を保証します。

### メタトランザクションにおけるMinimalForwarderとは何か

MinimalForwarderは、ユーザーが署名したメッセージの真正性とリプレイ保護を検証したうえで、ターゲットコントラクトを呼び出してトランザクションを実行するオンチェーンのスマートコントラクトです。

### ERC2771Contextとは何か

ERC2771Contextは[OpenZeppelin](https://www.alchemy.com/dapps/openzeppelin)のユーティリティコントラクトで、スマートコントラクト開発者がMinimalForwarderから送られてきたメタトランザクションから、本来のmsg.senderとmsg.dataを容易に取り出せるようにします。

### ERC-2771のメタトランザクションにはどのような制約があるか

ERC-2771は、対象コントラクトがEIP-712またはEIP-2771ベースのコントラクトを継承することでこの標準を明示的にサポートする必要があるため、すでにデプロイ済みのコントラクトへの実装が難しく、バグを引き起こす可能性があります。

### ERC-2771とERC-4337はどのように比較されるか

ERC-2771はRelayerとforwarderを通じてガスレストランザクションを可能にしますが、ERC-4337（Account Abstraction）は遡及的に機能し、既存のコントラクトを変更する必要がないため、ほとんどのERC-2771ソリューションを置き換えつつあります。

### メタトランザクションにおいてRelayerはどのような役割を果たすか

RelayerはユーザーのガスFeeをスポンサーするEthereumアカウントであり、その秘密鍵はプロバイダーのサーバー上に安全に保管されます。また、Whitelist登録、Gas Price Capping、条件付きロジックといった機能を設定することもできます。