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

はじめに

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

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

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

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

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

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

概要

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

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

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

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

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

動機

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

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

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

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

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

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を識別するためにはあまり特徴的ではありません。

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

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

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

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

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

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