# [ERC7196] コントラクトウォレットに最適化させたERC20の仕組みを理解しよう！

> このERC（イーサリアムリクエストコメント）は、コントラクトウォレット（アカウント抽象化を含む）に基づいて設計された新しい資産であり、ERC20との互換性を保持しつつ、ERC20のtransferFrom、approve、allowance

- URL: https://cardene.dev/articles/6c7909fe161a7d97aab6
- 公開日: 2024-03-14
- 更新日: 2024-03-14
- トピック: Blockchain
- タグ: ethereum, solidity, smartcontract, ブロックチェーン

## はじめに

初めまして。
**CryptoGames**というブロックチェーンゲーム企業でエンジニアをしている **cardene（かるでね）** です！
スマートコントラクトを書いたり、フロントエンド・バックエンド・インフラと幅広く触れています。

https://cryptogames.co.jp/

代表的なゲームは**クリプトスペルズ**というブロックチェーンゲームです。

https://cryptospells.jp/

今回は、**ERC20**の基本的な機能を維持しつつ、`transferFrom`、`approve`、`allowance`の機能を削除し、コントラクトウォレットに基づいてトークン管理をシンプルにする仕組みを提案している**ERC7196**についてまとめていきます！

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

https://eips.ethereum.org/EIPS/eip-7196

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

https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4

## 概要

このERC（イーサリアムリクエストコメント）は、コントラクトウォレット（アカウント抽象化を含む）に基づいて設計された新しい資産であり、**ERC20**との互換性を保持しつつ、**ERC20**の`transferFrom`、`approve`、`allowance`関数を取り除くことで、トークン資産をシンプルに保つことを目的としています。

:::message
**ERC20**については以下の記事を参考にしてください。
:::

https://chaldene.net/erc20

#### アカウント抽象化 (Account Abstraction)
イーサリアムでは、アカウントは一般的に2種類に分類されます。
外部所有アカウント（EOA）とコントラクトアカウントです。
外部所有アカウントは人が操作し、コントラクトアカウントはコードで構成されています。
アカウント抽象化は、これらの区別をなくし、任意のアカウントがトランザクションの署名や送信などの機能を自由に定義できるようにするコンセプトです。
これにより、より高度な認証メカニズムやウォレット機能を実装できるようになります。

:::message
コントラクトアカウントに関連する提案である**ERC4337**については以下の記事を参考にしてください。
:::

[\[ERC4337\] プロトコルの変更をせずにAAを実装する仕組みを理解しよう！](/articles/8c97ca7c93c4557ebfc2)

#### ERC20との互換性
**ERC20**は、イーサリアム上でのトークン標準として広く採用されています。
これにより、トランザクションの送信、受信、承認などの基本的なトークン操作が定義されます。
互換性を持つということは、この新しいERCが**ERC20**トークンとして機能し、**ERC20**トークンと互換性のある既存のインフラストラクチャやサービスで使用できることを意味します。

#### `transferFrom`, `approve`, `allowance`関数の除去
- `transferFrom`
    - 他のアドレスが所有者の代わりにトークンを送信することを可能にします。
- `approve`
    - 他のアドレスが特定量のトークンを送信することを承認します。
- `allowance`
    - 承認されたトークンの量を確認します。

これらの関数は、トークンの委任や許可メカニズムに関連しています。
この新しいERCでは、これらの機能を取り除くことで、トークンの管理をシンプルにし、ユーザーが自身のトークンをより直接的に制御できるようにしています。

#### なぜこれが重要か
この新しいERCの設計は、ユーザーがより直感的に、かつ安全に自分の資産を管理できるようにすることを目指しています。
アカウント抽象化により、ユーザーエクスペリエンスが向上し、新しい種類のアプリケーションやウォレット機能の開発が可能になります。
また、**ERC20**との互換性を保持しながら、よりシンプルな資産管理を提供することで、ユーザーにとっての利便性と安全性が向上します。

## 動機

提案されているこの新しいERCは、スマートコントラクトウォレットに基づいた、よりシンプルなトークン資産設計を目指しています。
このアプローチは、**ERC20**標準の一部の機能を削除し、トークンコントラクト自体よりもスマートコントラクトウォレットにより多くの機能を持たせることで、以下を達成しようとしています。

#### トークンコントラクトをシンプルに保つ
この提案の核心は、トークンコントラクトをシンプルに保ち、主に`transfer`機能（送金機能）にのみ責任を持たせることです。
これは、トークンの基本的な動作、すなわちユーザー間での資産の移動に焦点を当てることで、コントラクトの複雑さを減少させ、セキュリティリスクを低減することができます。

#### `approve`と`allowance`機能の除外
これまでの**ERC20**トークンでは、`approve`関数は第三者がユーザーのトークンをある量まで移動できるように許可し、`allowance`関数はその許可された量を確認します。
しかし、この提案ではこれらの機能をトークンコントラクトから削除し、その代わりにユーザーレベルでこれらの許可を管理します。
これにより、ユーザーにより大きな柔軟性と制御が提供され、特に**ERC20**コントラクトのこれらの機能の実装に関連する特定のリスクが軽減されます。

#### `transferFrom`機能の削除
`transferFrom`機能は、他人のトークンを移動することを可能にしますが、この提案ではこの機能を削除し、代わりにコントラクトアカウントにアクセスすることでトークンコントラクトのトークンを呼び出す方法を提案します。
これは、トークンコントラクトに直接アクセスするよりも、よりセキュアで柔軟な方法を提供します。

#### ERC20との前方互換性
この提案は、すべての分散型トークンがこの新しい設計と互換性を持つように、**ERC20**との互換性を維持することを意図しています。
これにより、既存の**ERC20**トークンエコシステムとの統合が容易になり、新しいトークン標準への移行を促進します。

:::message
この提案は、トークンの実装と管理に関して、よりシンプルで柔軟性の高いアプローチを提供することにより、ユーザーエクスペリエンスを向上させ、セキュリティリスクを軽減しようとするものです。
スマートコントラクトウォレットをトークンの機能性の中心として使用することで、資産管理の新しいパラダイムを提案しています。
これにより、ユーザーは自分の資産をより直接的に、かつ安全に管理できるようになります。
:::

## 仕様

この規格に準拠するコントラクトは、以下のインターフェイスを実装する必要があります。

```ts
pragma solidity ^0.8.20;

/**
 * @title ERC7196 Simple token interface 
 * @dev See https://ercs.ethereum.org/ERCS/erc-7196
 */
interface IERC7196 {
    /**
     * @notice Used to notify transfer tokens.
     * @param from Address of the from
     * @param to Address of the receive
     * @param value The transaction amount 
     */
    event Transfer(
        address indexed from,
        address indexed to,
        uint256 value
    );
	
    /**
     * @notice Get the total supply
     * @return total The total supply amount
     */
    function totalSupply() 
        external  
        view
        returns (uint256 total);
	  
    /**
     * @notice get the balance of owenr address
     * @param owner Address of the owner
     * @return balance The balance of the owenr address
     */
    function balanceOf(address owner) 
        external
        view
        returns (uint256 balance);

    /**
     * @notice Transfer token
     * @param to Address of the to
     * @param value The transaction amount 
     * @return success The bool value returns whether the transfer is successful
     */
    function transfer(address to, uint256 value)
        external
        returns (bool success);

}
```

#### `totalSupply`

```javascript
function totalSupply() 
    external  
    view
    returns (uint256 total);
```

**概要**

トータルサプライ（総供給量）を取得する関数。

**詳細**

この関数はコントラクトが管理するトークンの総量を返します。
トークンの発行量や市場に流通しているトークンの量を示す指標として使用されます。

**戻り値**

- `total`
    - コントラクトによって発行されたトークンの総量。

---

#### `balanceOf`

```javascript
function balanceOf(address owner) 
    external
    view
    returns (uint256 balance);
```

**概要**

指定されたアドレスのトークン残高を取得する関数。

**詳細**

この関数は、指定されたアドレス（`owner`）が保有するトークンの量を返します。
トークンの所有量を確認するために使用されます。

**引数**

- `owner`
    - トークン残高を確認したいアドレス。

**戻り値**

- `balance`
    - 指定されたアドレスが保有するトークンの量。

---

#### `transfer`

```javascript
function transfer(address to, uint256 value)
    external
    returns (bool success);
```

**概要**

トークンを送信する関数。

**詳細**

この関数は、コントラクトの呼び出し元から指定されたアドレス（`to`）へトークンを送信するために使用されます。
トランザクションの成功または失敗を`bool`値で返します。

**引数**

- `to`
    - トークンを送信する先のアドレス。
- `value`
    - 送信するトークンの量。

**戻り値**

- `success`
    - トランザクションの成功したかどうかを示す`bool`値。

---

## 補足

提案されたトークン標準の簡素化は、`transferFrom`、`approve`、`allowance`関数を取り除くことに焦点を当てています。
この簡素化の目的は、セキュリティの向上、複雑性の低減、および効率性の改善にあり、これにより標準がコントラクトウォレット環境により適したものになりつつ、必要な機能性を維持します。

#### セキュリティの向上

`approve`と`allowance`メカニズムは、第三者がユーザーのトークンを代わりに移動できるようにするものですが、これが悪用されるリスクがあります。
例えば、ユーザーが意図せずに大量のトークンを承認してしまう場合や、スマートコントラクトに脆弱性がある場合などです。
これらの関数を除去することで、ユーザーは自身のトークンに対する直接的な制御を保持し、不正な取引のリスクを減少させることができます。

#### 複雑性の低減

**ERC20**などの既存のトークン標準には、多くの関数とイベントが定義されており、これがコントラクトの実装とインタラクションを複雑にします。
提案された簡素化により、開発者はトークンの基本的な`transfer`機能に集中でき、よりシンプルで読みやすいコードを作成することが可能になります。
これは、開発のハードルを下げ、イーサリアムエコシステム内での新しいトークンの採用を促進することが期待されます。

#### 効率性の改善

関数の数を減らすことで、コントラクトの実行コスト（ガス消費量）が低減されます。
特に、`approve`と`allowance`関数を使用する時には、トークンの移動を許可する前に複数のトランザクションが必要となる場合があります。
これらの手続きを簡素化することで、ユーザーはトークンをより効率的に、かつ低コストで移動させることができるようになります。

#### コントラクトウォレット環境における適合性

コントラクトウォレットは、ユーザーにより高度な制御とセキュリティ機能を提供しますが、既存のトークン標準は外部所有アカウント（EOA）を基準に設計されています。
提案された標準は、コントラクトウォレットの能力を活用し、これらのウォレットでトークンをより効果的に管理するためのものです。
例えば、トークンの移動や権限の管理をコントラクトウォレット自身のロジックでより柔軟に制御できるようになります。

:::message
この提案はトークンの取引と管理をシンプルにし、イーサリアムエコシステムにおけるユーザーと開発者の体験を改善することを目指しています。
このような変更は、特にコントラクトウォレットを利用するユーザーにとって、より直感的で安全なトークンの管理を可能にすると期待されています。
:::

## 互換性

このERCは**ERC20**と互換性があります。

## 実装

```ts
pragma solidity ^0.8.20;

import "./IERC7196.sol";
import "../../math/SafeMath.sol";

/**
 * @title Standard ERC7196 token
 * @dev Note: the ERC-165 identifier for this interface is 0xc1b31357
 * @dev Implementation of the basic standard token.
 */
contract ERC7196 is IERC7196 {
    using SafeMath for uint256;

    mapping (address => uint256) private _balances;

    uint256 private _totalSupply;

    function totalSupply() external view returns (uint256) {
        return _totalSupply;
    }

    function balanceOf(address owner) external view returns (uint256) {
        return _balances[owner];
    }

    function transfer(address to, uint256 value) external returns (bool) {
        require(value <= _balances[msg.sender]);
        require(to != address(0));

        _balances[msg.sender] = _balances[msg.sender].sub(value);
        _balances[to] = _balances[to].add(value);
        emit Transfer(msg.sender, to, value);
        return true;
    }

}
```

## セキュリティ

この新しいERC標準は**ERC20**と後方互換性を持ちません。
後方互換性がないということは、新しいERC標準に基づいて作成されたトークンは、既存の**ERC20**トークンと同じ方法で既存のdapps（分散型アプリケーション）に統合することができないという意味です。
これにより、いくつかの重要な影響が生じます。

#### 既存dappsとの互換性問題

既存の多くのdappsは、**ERC20**標準に基づいてトークンを扱うためのロジックを実装しています。
これには、トークンの転送、承認、トークンの許可量の確認などが含まれます。
新しいERC標準がこれらの機能を提供しない場合、これらのdappsは新しい標準に基づくトークンを適切に処理できなくなります。

#### アップグレードと統合の必要性

新しいERC標準を受け入れるためには、dapps開発者は既存のアプリケーションをアップグレードし、新しいトークン標準と互換性を持つように統合ロジックを変更する必要があります。
これは、開発者にとって追加の作業負担となり、全体的なエコシステムのアップデートプロセスを遅らせる可能性があります。

#### エコシステムへの影響

後方互換性がないということは、エコシステム全体が新しい標準に迅速に移行することが難しくなるということです。
既存のトークンやサービスが新しい標準に対応していない場合、ユーザーは新旧のトークン標準間での操作性に関して不便を感じる可能性があります。

#### セキュリティとユーザビリティの向上を目指して

新しいERC標準を導入する主な理由は、トークンのセキュリティを向上させ、スマートコントラクトウォレットを使用する時のユーザビリティを向上させることです。
しかし、後方互換性の欠如は、既存のインフラとの統合における課題を引き起こします。
したがって、新しい標準を広く採用するためには、エコシステム全体での調整と協力が必要になるでしょう。

## 引用

Xiang (@wenzhenxiang), Ben77 (@ben2077), Mingshi S. (@newnewsms), "ERC-7196: Simple token, Simplified ERC-20 [DRAFT]," Ethereum Improvement Proposals, no. 7196, June 2023. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7196.

## 最後に

今回は「**ERC20**の基本的な機能を維持しつつ、`transferFrom`、`approve`、`allowance`の機能を削除し、コントラクトウォレットに基づいてトークン管理をシンプルにする仕組みを提案している**ERC7196**」についてまとめてきました！
いかがだったでしょうか？

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

[Twitter @cardene777](https://twitter.com/cardene777)

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

https://chaldene.net/

https://zenn.dev/heku

https://mirror.xyz/0xcE77b9fCd390847627c84359fC1Bc02fC78f0e58

https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4