[ERC7528] ETHの送付をERC20トークンの送付と同等に扱う仕組みを理解しよう！

# はじめに

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

https://cryptogames.co.jp/

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

https://cryptospells.jp/

今回は、**ERC20**トークンの送付を同じようにETHを送付するためのアドレスを提案している規格である、**ERC7528**についてまとめていきます！

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

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

:::note warn
**7528**は現在（2023年10月27日）では「**Review**」段階です。
:::

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

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

# 概要

この規格では、アドレスが**ERC20**トークンと同じようにETHを使用する時のルールを提案しています。
アドレスフィールドがETHまたは**ERC20**トークンを示す場合や、**ERC4626**ボールトのアセットフィールドなど、特定の場面で適用されます。

:::note info
**ERC20**については以下を参考にしてください。
:::

https://chaldene.net/erc20

:::note info
**ERC4626**については以下を参考にしてください。
:::

https://qiita.com/cardene/items/99db4ee3074ab6c8c4e2

この規格は、ETH以外のネイティブアセットが存在するEVMチェーンにも適用できます。
つまり、他のEVMチェーンでも同じ規則を利用できるように一般化されています。

この規則は、ETHをトークンとして扱う時の一貫性を保ち、他のEVMチェーンにも適用できるようにすることを目的としています。

# 動機

ETHは価値の交換可能な単位であり、**ERC20**トークンと似たように動作します。
プロトコルは通常、**ERC20**トークンの標準インターフェースを実装し、ETHの実装が**ERC20**の実装と一致することから利益を得ます。

:::note info
通常、プロトコルは**ERC20**トークンの標準的なインターフェースを使うことがあり、これにより**ETH**と**ERC20**トークンの操作方法が似ています。
**ERC20**トークンの標準を実装することで、プロトコルは**ETH**と**ERC20**トークンを同じように扱えるため、効率的に利用できるようになります。
:::

多くの場合、プロトコルは**ERC20**の規格に準拠するために**Wrapped ETH**（たとえば、Ethereum Mainnetのアドレス`0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2`にデプロイされた**WETH9**）を選択します。
他の場合では、ガスのコストや**Liquid Staking Token（LST）**のようなネイティブETHの必要性に応じて、プロトコルはネイティブETHを使用することもあります。

さらに、プロトコルはETHのネイティブなケースと**ERC20**のケースを区別するために異なるイベントを作成することがあります。
これにより、オフチェーンのデータインフラストラクチャにおいてデータの断片化や統合のコストが発生します。
`0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE`という**ETH**アドレスが**ERC20**の文脈で使用される場合、両方のケースで同じイベントフォーマットを使用することは効率的です。

:::note info
あるコントラクトで**ERC20**トークンを送付するときに、以下のようなイベントを発行するとします。

```javascript
TransferToken(address token, address from, address to, unit256 value)
```

各パラメータは以下の情報を含んでいます。

- `token`
    - 送付対象トークンのコントラクトアドレス。
- `from`
    - トークン送付元アドレス。
- `to`
    - トークン送付先アドレス。
- `value`
    - 送付トークン量。

この時、`token`は送付するトークンのコントラクトアドレスを表しています。
**ECR20**トークンを送付するのであれば、ここに**ERC20**トークンのコントラクトアドレスを格納すれば良いです。
しかし、ネイティブトークンである**ETH**のコントラクトアドレスはありません。
そのため、ここに`0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE`というアドレスを格納することで、「**ERC20**トークンの送付時と同じイベントを使用することができる」、という提案をしています。
:::

この規格の一つの意図される使用ケースは、ETHをアセットとして使用する**ERC4626**に準拠した**LST（Liquid Staking Tokens）**です。
これにより、**ERC4626**の利点やツールをLSTと統合プロトコルに拡張できます。

この規格により、プロトコルとオフチェーンのデータインフラストラクチャは、`0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE`が**ERC20**の文脈でアドレスとして使用される場合、それがETHを指しているという共通の理解を共有できるようになります。

# 仕様

この規格は、スマートコントラクトシステムのすべての部分に適用されます。
このシステムでは、アドレスが**ERC20**トークンを特定するために使用され、同時に特定の場合にはネイティブETHが**ERC20**トークンの代わりに使用されます。
ここでの「**トークン**」という用語は、**ETH**または**ERC20**トークンを指します。

**ERC20**アドレスが使用され、そのアドレスが示すトークンが**ETH**である場合、アドレスフィールドは必ず`0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE`を返す必要があります。

一方、トークンがETHの非公式なラップトークン（たとえば**WETH9**）である場合、そのトークンのアドレスを使用しなければならず、`0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE`を使用してはいけません。

# 補足

この規格に関連して、以前の実装では、アドレスの最初にゼロバイト（`0x0`、`0x1`、`0xe`など）を持つアドレスを使用することが一般的でした。
これは、ガスの使用効率を向上させるための工夫でした。

しかし、このようなアドレスは潜在的にプリコンパイルアドレスと重複する可能性があり、また**ETH**を識別するためにはあまり特徴的ではありません。

:::note info
**プリコンパイルアドレス（Precompiled Addresses）**は、Ethereumのスマートコントラクトプラットフォームにおいて、事前にコンパイルされた特殊なコントラクトのアドレスです。
これらのプリコンパイルコントラクトはEthereumのバックエンドで特定の計算を高速に実行するために使用されます。
通常、これらのコントラクトはEthereumの低レベルのオペレーションや暗号学的な操作を効率的に実行するために存在します。

例えば、ECDSA署名検証やSHA-256ハッシュ計算など、一般的な計算タスクを高速に処理できるように設計されています。
これらのプリコンパイルアドレスは、スマートコントラクトから呼び出すことができ、トランザクションの処理速度向上やガスコストの削減に役立ちます。

一般的な例として、Ethereumのプリコンパイルアドレスには、`ecrecover`（ECDSA署名の検証）、`sha256`（SHA-256ハッシュ計算）、`keccak256`（Keccak-256ハッシュ計算）などがあります。
これらのアドレスはEthereumのネットワーク上で共通して使用され、高度な計算やセキュリティ関連の操作を効率的に実行するのに役立ちます。
:::

それに対して、`0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE`は現代的に最も一般的に使用されており、識別的であり、プリコンパイルアドレスとの衝突の心配がありません。
そのため、他の代替案に比べて、このアドレスを使用する利点は潜在的なガスの効率性の利点を上回ります。

:::note info
`0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE`は主に以下のような場面で使用されています。

- **DeFi プロトコル**
    - 多くの分散型ファイナンス（DeFi）プロトコルでは、ETHをトークンとして扱う必要がある場合に、このアドレスを使用していました。
    - これにより、ETHのトランザクションを**ERC20**トークンと同じインターフェースで取り扱えるようになり、DeFiアプリケーション内での一貫性が維持されました。

- **流動性プール**
    - 一部の流動性プールプラットフォームでは、ETHの流動性を提供するために`0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE`を使用しました。
    - これにより、ユーザーは**ETH**と**ERC20**トークンのトークンペアを同じインターフェースでトレードできました。

- **ユーザーウォレット**
    - 一部のウォレットアプリケーションやブラウザ拡張機能は、**ETH**と**ERC20**トークンを管理するためにこのアドレスを使用しました
    - ユーザーがウォレット内でETHをトークンとして取り扱う際に、このアドレスが使用されました。
:::

# 後方互換性

この規格は、他の規格との互換性に問題はありません。

# セキュリティ考慮事項

**WETH（Wrapped ETH）**の代わりに**ETH**をトークンとして使用する場合、スマートコントラクトシステムは再入攻撃などの脆弱性に対処しなければなりません。
この問題に対処するために、以下のCEIパターンに従うことが重要です。

1. **チェック（検証）**
トークンがETHの場合、トランザクションを実行する前に必ず事前のチェックと検証を行う必要があります。
これにより、トランザクションが実行可能かどうかを確認し、不正なトランザクションを防ぎます。

2. **効果（ステート変更）**
トークンが**ETH**の場合、トランザクションが正常に完了した場合と異常終了した場合の両方に対応する効果を確実に処理する必要があります。
ステート変更を適切に管理し、コントラクトの状態が一貫性を持つようにします。

3. **対話（外部コントラクトとのやり取り）**
トークンが**ETH**の場合、外部コントラクトとのやり取りを行う時に注意が必要です。
再入攻撃を防ぐために、外部コントラクトに対するトランザクションを送信する前に、スマートコントラクトの状態を確認し、対話を慎重に制御します。

再入攻撃は、外部コントラクトがスマートコントラクト内の関数を再帰的に呼び出すことで発生する危険な脆弱性です。
したがって、開発者はトランザクションの実行と外部コントラクトとのやり取りを慎重に管理し、セキュリティプラクティスと業界標準の開発パターンを遵守することが非常に重要です。
これにより、スマートコントラクトシステムが安全に機能し、攻撃から保護されます。

# 引用

Joey Santoro (@joeysantoro), "ERC-7528: ETH (Native Asset) Address Convention [DRAFT]," Ethereum Improvement Proposals, no. 7528, October 2023. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7528.

# 最後に

今回は「**ERC20**トークンの送付を同じようにETHを送付するためのアドレスを提案している規格である**ERC7528**」についてまとめてきました！
いかがだったでしょうか？

質問などがある方は以下の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