はじめに
初めまして。 CryptoGamesというブロックチェーンゲーム企業でエンジニアをしている cardene（かるでね） です！ スマートコントラクトを書いたり、フロントエンド・バックエンド・インフラと幅広く触れています。
代表的なゲームはクリプトスペルズというブロックチェーンゲームです。
今回は、WETHの使用の回避とガス効率の向上などを考慮し、ETHをERC20トークンと同様に振る舞う仕組みの標準化を提案しているEIP7528についてまとめていきます！
以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。
他にも様々なEIPについてまとめています。
概要
提案されている規格は、EthereumなどのEVM (Ethereum Virtual Machine) チェーン上で、ETH（Ethereumのネイティブ通貨）をERC20トークンと同じように扱う時の標準的な方法に関するものです。
ETHを表すために特定のアドレス0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeを使用することを提案しています。
このアドレスは、ETHをERC20トークンとして表現するための「擬似アドレス」として機能します。
ERC20については以下の記事を参考にしてください。
背景と目的
Ethereum上のトークンは主にERC20標準に従って発行されます。 ERC20トークンは、スマートコントラクトによって定義された規則に基づいて動作し、トークンの移転や残高の確認などが行えます。 しかし、ETH自体はERC20トークンではなく、Ethereumのネイティブな資産であるため、ERC20トークンと同じ方法で扱うことはできません。
提案されている標準は、ETHをERC20トークンとして取り扱う時の統一された方法を提供しようとしています。
0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeというアドレスをETHの代わりに使用することで、スマートコントラクトやアプリケーションはETHとERC20トークンを区別せずに一貫した方法で操作できるようになります。
適用例
- イベントログ
- スマートコントラクトがイベントを発行する時、ETHの移動を表すためにこのアドレスを使用します。
- 資産の識別
- 例えば、ERC4626などの規格で資産の種類を指定するフィールドにこのアドレスを使って、ETHを表現します。
ERC4626については以下の記事を参考にしてください。
他のEVMチェーンへの応用
この標準はETHに限定されず、他のEVM互換チェーン（例えば、Binance Smart ChainのBNBやPolygonのMATICなど）においても、そのチェーンのネイティブ資産を表すために同じアドレスを使用することが提案されています。 これにより、異なるブロックチェーン間での資産の統一的な扱いが可能になり、開発者は複数のチェーンにまたがるアプリケーションをより簡単に開発できるようになります。
この提案は、ブロックチェーンエコシステムにおける資産の取り扱いをより柔軟かつ一貫性のあるものにしようとするものです。 ETHやその他のネイティブ資産をERC20トークンと同様に扱うことで、開発の複雑さを軽減し、異なる資産間での相互運用性を高めることを目指しています。
動機
上記の説明は、Ethereum上でETHをERC-20トークンのように扱いたい場合の標準化提案についての詳細な背景とその目的を示しています。具体的には、ETHの取扱いをERC-20トークンと同様にするための方法として、特定のアドレス0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeを使用する提案に焦点を当てています。ここでは、このアプローチの背景、利点、および意図された使用例について掘り下げていきます。
背景
Ethereumのネイティブ通貨であるETHは、ERC20トークンと同じように交換可能な価値単位として機能しますが、技術的にはERC20トークン標準に従っていません。 多くのプロトコルやアプリケーションはERC20トークンとの互換性を確保するためのインターフェースを実装していますが、ETHを直接使用する場合はこの互換性がありません。
Wrapped ETH (WETH)
解決策の一つとして、Wrapped ETH (WETH) があります。 WETHはETHをERC20互換トークンに変換することで、ETHをERC20トークンとして扱うことを可能にします。 これにより、ETHをERC20トークンを要求するスマートコントラクトやプロトコルで使用できるようになります。
ネイティブETHの使用
しかし、ガスのコストや特定の用途（例えば、Liquid Staking Token (LST) など）によっては、ネイティブのETHを直接使用する必要があります。 ネイティブETHとERC20トークンの間での処理の違いは、データの断片化やオフチェーンのインフラストラクチャーにおける統合のオーバーヘッドを引き起こします。
統一イベントフォーマットの利点
0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeアドレスを標準としてETHを表すことで、ETHとERC20トークンの両方を同一のイベントフォーマットで扱えるようになります。
これは、データの統合性を向上させ、オフチェーンのインフラストラクチャーにおける複雑さを軽減します。
ERC4626とLSTの統合
この提案の一つの使用例として、ERC4626準拠のLSTが挙げられます。 ERC4626は、トークン化されたボールトのための標準インターフェースを提供します。 ETHを資産として使用するLSTの場合、この提案によって、ERC4626のツールや利点をLSTに拡張し、さまざまなプロトコルとの統合を容易にします。
ERC4626
ERC4626とは、Ethereumのスマートコントラクトで使用される、トークン化された金融ボールト（投資ファンドや貯蓄アカウントなど）のための標準インターフェースを定義するEthereum Improvement Proposal（EIP）です。 この標準は、トークン化されたボールト内の資産に対する一般的なアクション（預金、引き出し、残高の確認など）を実行するための共通の方法を提供します。
Liquid Staking Token (LST) は、ユーザーがステーキング（仮想通貨をプロトコルに預けて報酬を得る行為）に参加しながら、その預けた資産の流動性を保持することを可能にするトークンです。 ユーザーは、ステーキングに参加することで報酬を得る一方で、LSTを通じていつでもその資産にアクセスできるようになります。
ERC4626とLSTの統合の意味
この提案では、ERC4626準拠のインターフェースを使用してLSTを実装することで、ETHを資産として使用するLSTが、ERC4626が提供するツールや利点を享受できるようになります。 具体的には、以下のようなメリットがあります。
-
標準化されたインターフェース
- ERC4626に準拠することで、LSTを含む任意のトークン化されたボールトが、一貫した方法で預金、引き出し、残高確認などの操作をサポートできるようになります。
- これにより、ユーザーや開発者は異なるプロトコル間での操作において一貫性と予測可能性を享受できます。
-
流動性とアクセシビリティの向上
- LSTがERC4626のインターフェースを採用することで、ステーキングに参加しているETHの流動性を保ちつつ、ステーキングの報酬を享受することが可能になります。
- ユーザーは、トークン化されたボールトから簡単に資産を預けたり引き出したりできるようになります。
-
プロトコル間の統合の容易化
- ERC4626の標準インターフェースを採用することで、LSTを含むトークン化されたボールトは、他のプロトコルやアプリケーションとの統合が容易になります。
- 開発者は、異なるプロトコル間で資産を移動させる際の複雑さを減らすことができ、ユーザーエクスペリエンスを向上させることが可能になります。
結論
ERC4626準拠のLSTの使用は、Ethereumブロックチェーン上での資産管理とステーキングのプロセスをより効率的でユーザーフレンドリーにする革新的なアプローチです。 この標準により、ETHを含むさまざまな資産のトークン化されたボールトの開発と統合が促進され、Ethereumエコシステム全体の成長と発展に貢献することが期待されます。
この標準化提案により、プロトコルやオフチェーンのデータインフラは、0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeアドレスがERC20コンテキストで使用される場合、それがETHを意味するという共有された理解に基づいて扱うことができます。
これにより、ETHとERC20トークンをより一貫して扱うことが可能になり、開発者やユーザーにとっての利便性が向上します。
仕様
提案されている標準は、スマートコントラクトシステム内でETHとERC20トークンを識別するために使用されるアドレスに関するものです。 この標準は、特定のインスタンスでネイティブETHがERC20トークンの代わりに使用される場面に適用されます。 「Token」という用語は、この文脈ではETHまたはERC20トークンのどちらかを指します。
基本原則
ETHの表現
スマートコントラクトのフィールドやイベントでERC20トークンのアドレスが使用される場合でも、基礎となるTokenがETHであるならば、そのアドレスフィールドは0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeを返さなければなりません。
WETHの取り扱い
ETHの非公式な包括されたERC20バージョン（例えばWETH9）の場合、そのTokenのアドレスを使用しなければならず、0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeを使用してはなりません。
チェックサムアドレス
Ethereumでは、大文字と小文字の区別があるチェックサムアドレスを使用することが推奨されています。
これは、アドレスの誤入力を防ぐためのものです。
EIP155によるチェックサムは、アドレスの正確性を保証するために重要な要素です。
例えば、提案されたETHの表現におけるチェックサムアドレスは0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeEです。
EIP155については以下の記事を参考にしてください。
意図と利点
この標準の主な目的は、スマートコントラクトがETHとERC20トークンを一貫して扱うことを容易にすることです。 ETHを特定の「擬似ERC20アドレス」にマッピングすることで、開発者はETHとERC20トークンを同一のロジックで処理できるようになり、コードの複雑さとエラーの可能性を減少させることができます。
また、この標準はオフチェーンのデータ処理や分析にも利点を提供します。 ETHとERC20トークンの取引やイベントを一貫した形式で記録できるため、データの統合性が向上し、分析やレポーティングの効率が高まります。
この標準は、ETHとERC20トークンをスマートコントラクトシステム内で一貫して扱うための明確なガイドラインを提供します。 これにより、開発の柔軟性が向上し、スマートコントラクトとデータインフラストラクチャの両方におけるエラーのリスクが低減されます。 標準化されたアプローチは、Ethereumエコシステム全体の相互運用性と効率を高めることに貢献します。
補足
提案されている標準に関連して、ETHを表すために様々な代替アドレスが検討されました。
これらには0x0、0x1、0xeなどが含まれており、これらのアドレスは先頭のゼロバイトを持つことでガス効率を向上させる利点があります。
Ethereumでは、トランザクションのガスコストは送信されるデータの量に依存するため、アドレスにゼロバイトが多いほど、トランザクションのコストが低くなる可能性があります。
検討された代替アドレスの問題点
しかし、これらのアドレスにはいくつかの問題があります。
プリコンパイルアドレスとの衝突
0x0、0x1、0xeなどのアドレスは、Ethereumのプリコンパイルされたスマートコントラクト（Ethereumの仮想マシンに事前に組み込まれた特別な関数を持つコントラクト）のアドレスと衝突する可能性があります。
プリコンパイルアドレスはシステムレベルで特別な意味を持ち、そのため、これらを一般的な識別子として使用することは避けるべきです。
識別性の低さ
これらのアドレスは非常に単純であり、ETHを表すための識別子としての特徴が乏しいです。 これにより、ユーザーや開発者がこれらのアドレスをETHの特別な表現として認識しにくくなります。
0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeの選択理由
最終的に、0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeがETHを表すためのアドレスとして選ばれました。
このアドレスは以下の利点を持っています。
現在の使用状況
このアドレスは既にETHを表すために使用されており、エコシステム内での認知度が高いです。
識別性
0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeは非常に特徴的なアドレスであり、ETHのための識別子としてすぐに認識できます。
プリコンパイルアドレスとの衝突なし
このアドレスはプリコンパイルされたスマートコントラクトのアドレスと衝突することはなく、システムレベルでの問題を避けることができます。
これらの理由から、0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeがETHをERC20トークンのように扱う時の標準アドレスとして選ばれました。
他の代替案が提供する潜在的なガス効率の利点は、識別性の高さ、既存の使用状況、およびプリコンパイルアドレスとの衝突のなさという利点によって上回られます。
この選択は、EthereumエコシステムにおけるETHの一貫した表現を提供し、開発者やユーザーがETHをより簡単に扱えるようにすることを目的としています。
互換性
この規格は、他の規格との互換性に問題はありません。
セキュリティ
ETHを直接使用することがスマートコントラクトシステムに再入力（re-entrancy）攻撃や類似の脆弱性をもたらす可能性があることを指摘しています。 これらの問題を避けるためには、開発者が業界標準の開発パターンに従うことが重要です。
再入力攻撃とは
再入力攻撃は、スマートコントラクトが外部のコントラクト（悪意のあるコントラクトを含む）を呼び出し、そのコントラクトが元のコントラクトの関数を再度呼び出すことで発生します。 この攻撃は、スマートコントラクトが状態を更新する前に外部のコントラクトに制御を移してしまう場合に特に有効です。 攻撃者はこの脆弱性を利用して、たとえば、同じETHを複数回引き出すなどの不正行為を行うことができます。
WETHとETHの違い
WETH（Wrapped ETH）は、ETHをERC20互換の形式に変換したものです。
WETHを使用すると、ETHを直接使用する場合に比べて、再入力攻撃のリスクが低減します。
これは、WETHトランザクションがERC20トークンの標準的なtransferメカニズムを使用するため、不正な再入力の機会が減るからです。
業界標準の開発パターン
再入力攻撃を防ぐためには、以下のような業界標準の開発パターンに従うことが推奨されます。
- チェック-効果-相互作用（Checks-Effects-Interactions）パターン
- このパターンでは、まずトランザクションの前提条件をチェック（Checks）し、次にコントラクトの状態を更新する（Effects）、最後に外部のコントラクトやアドレスとの相互作用（Interactions）を行います。
- この順序に従うことで、外部のコントラクトに制御を移す前に状態の更新を完了させることができ、再入力攻撃のリスクを減らすことができます。
実装時の注意点
ETHをトークンとして直接使用する場合、特に上記の開発パターンを徹底する必要があります。 ETHを送金する操作は、外部コントラクトのフォールバック関数や受信関数をトリガーする可能性があり、これが再入力攻撃の機会を提供することになるためです。 開発者は、スマートコントラクトが安全に外部のコントラクトと相互作用できるように、慎重に設計と実装を行う必要があります。
ETHを直接使用することには、再入力攻撃などの脆弱性への露出というリスクが伴います。 このリスクを最小限に抑えるためには、業界標準の開発パターンに従うことが不可欠です。 WETHの使用は、これらのリスクを低減する一方で、ETHをERC20トークンのように扱うことを可能にします。 どちらのアプローチを選択するにせよ、セキュリティはスマートコントラクトの設計と開発の最優先事項でなければなりません。
引用
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.
最後に
今回は「WETHの使用の回避とガス効率の向上などを考慮し、ETHをERC20トークンと同様に振る舞う仕組みの標準化を提案しているEIP7528」についてまとめてきました！ いかがだったでしょうか？
質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！
他の媒体でも情報発信しているのでぜひ他も見ていってください！