[ERC7535] ERC4626にネイティブトークンを活用する仕組みを理解しよう！

はじめに

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

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

今回は、ERC4626にETHなどのネイティブトークンを使用する仕組みを提案している規格であるERC7535についてまとめていきます！

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

7535は現在（2024年1月14日）では「Review」段階です。

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

概要

この規格は、ERC4626という既存の Ethereum コントラクト規格に追加機能をもたらすもので、特に Ether や他のネイティブアセットを基盤資産として取り扱う時のインターフェースと動作をカスタマイズする点に特徴があります。

ERC4626は、トークン化された資産を管理するための標準的な方法を定義するEthereumの規格です。
例えば投資ファンドのような金融商品をトークンとして表現するために使用されます。
これにより、トークンホルダーは、そのファンドの資産に対する権利や持ち分を持つことができます。

この拡張を通じて、開発者はERC4626の基本的なフレームワークを利用しつつ、Etherや他のブロックチェーンのネイティブ資産を、コントラクト内で直接的に管理する機能を実装することができます。

この拡張により、Ether やその他のネイティブ資産を使用した新しいタイプの金融商品やサービスを、ERC4626の枠組みを活用してより容易に開発することが可能になります。
これにより、Ethereum ブロックチェーン上での資産の取り扱いがより柔軟かつ効率的になることが期待されます。

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

動機

上記のテキストは、Ether（ETH）をトークン化したヴォルト（Vaults）のための新しい標準に関するものです。
この標準は、特に流動性が高いステーキングトークンに焦点を当てており、これらのトークンはERC20ラッパーを介してETHのステーキングを表現します。
言い換えれば、ERC20トークンを使用してETHステーキングを可能にします。

この新しい標準はERC4626と同様の利点を持っています。
ERC4626は、デジタル資産の管理と流動性を提供するためのEthereumのコントラクト規格です。
新しい標準がERC4626のインターフェースをそのまま維持することで、既存のERC4626ツールやプロトコルとの互換性が最大化され、より多くの利点が得られます。

この標準により、開発者はETHのステーキングに関連する新しいタイプのトークンを効率的に管理するためのフレームワークを利用できます。
これらのトークンは、ETHのステーキングのためのERC20ラッパーとして機能し、ユーザーはこれを使用してETHをステーキングできます。

また、ERC4626と同じインターフェースを使用することで、新しい標準は既に存在するERC4626対応のツールやプロトコルと簡単に統合できるようになります。
これは、開発者が新しいコードを書く必要が少なくなることを意味し、ユーザーはこれらのトークンをよりスムーズに使用できるようになります。

ETHをトークン化したヴォルトのためのこの新しい標準は、ERC4626の既存の枠組みを活用して、ETHのステーキングに関連するトークンをより効率的かつ容易に管理できる方法を提供します。
これにより、Ethereum上での資産管理の柔軟性と利便性が高まります。

仕様

ERC7535に準拠するコントラクトは、以下に指定するERC4626のasset、deposit、mintメソッドをオーバーライドして実装する必要があります。

ERC-4626 変更点

ERC7535 標準では以下のような変更点があります。

• **アセットの量

  • ERC4626ではアセットの量は通常ERC20トークンのバランスとして扱われますが、ERC7535ではアセットの量はEtherのウェイ（wei）として扱われます。

• トランスファーの置き換え

  • ERC20のtransfer関数の呼び出しが、Etherの送付（send または call）に置き換えられます。

• 承認フローの除外**

  • ERC20 でのtransferFromを使用したアセットの承認フローは、ERC7535では実装されていません。

• depositとmintの状態変更

  • これらの関数はpayableとしてマークされており、状態変更が可能です。

• depositの使い方

  • deposit関数はmsg.valueを主要な入力として使用し、アセットの指定を無視することが許されます。

これらの変更により、ERC7535 は、Etherを基本資産とするトークン化されたヴォルトにおいて、より効率的かつ柔軟な操作を可能にします。
ERC4626とERC20の標準に基づいているため、これらの標準に準拠した既存のツールやプロトコルとの互換性も維持しつつ、Etherの直接取り扱いに特化した機能を提供します。
これにより、Etherを使用する新しい種類のトークン化されたヴォルトを効果的に開発し、運用することが可能になります。

メソッド

asset

• 関数名
  • asset
• タイプ
  • 関数
• 状態
  • view（状態を変更しない読み取り専用の関数）

この asset 関数は、入力パラメータを取らず、出力として assetTokenAddress という名前のアドレス型の値を返します。
asset 関数は、特定のアドレス値「0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE」を必ず返すように設定されています。

このアドレス値は、Ether自体を示すための標準的な方法であり、ERC7528 で定められています。
通常、トークンのアドレスは特定のコントラクトのアドレスを指しますが、この特別な値はEtherを表すために使用されます。
つまり、asset 関数はこのコントラクトがEtherを扱っていることを示すためのもので、実際のトークンのアドレスではなく、Ether自体を表す特殊な値を返します。

asset 関数はコントラクトが扱う資産がEtherであることを示すために使用され、ERC7528 に従って特定のアドレス値を返します。
これは、コントラクトがトークンではなく、直接的にEtherを扱っていることを意味します。

deposit

• 関数名
  • deposit
• タイプ
  • 関数
• 状態
  • payable（Etherの支払いを受け付ける関数）

deposit 関数の主な役割は、Etherを預けることによってヴォルトのシェアを発行することです。
この関数は以下のように動作します。

• payable

  • 関数は payable であり、Etherの送金を受け付けます。

• 主要な入力パラメータ

  • この関数は msg.value（送信されたEtherの量）を主要な入力パラメータとして使用し、シェアの出力量を計算します。
  • assets パラメータは無視される可能性があります。

• イベントの発生

  • Deposit イベントを発生させる必要があります。

• 取り消しの条件

  • もし msg.value の全額が預けられない場合（例えば、預金限度に達している、スリッページが発生しているなどの理由で）、関数は取り消し（revert）する必要があります。

関数の入力と出力は以下の通りです。

• 入力

  • assets
    • uint256。
    • Etherの量を表すが、この関数では主に無視される可能性があります。
  • receiver
    • address。
    • シェアが発行される受取人のアドレス。

• 出力:

  • shares
    • uint256。
    • 預けられたEtherに対して発行されるヴォルトのシェアの量。

deposit 関数はユーザーがEtherを預けることによってヴォルトのシェアを発行するために使われます。
この過程で、預けられたEtherの量（msg.value）がシェアの計算の基礎となり、特定の条件下で取り消しを行うことが必要です。

mint

• 関数名
  • mint
• タイプ
  • 関数
• 状態
  • payable（Etherの支払いを受け付ける関数）

mint 関数の主な目的は、ETHの資産を預けることによってヴォルトのシェアを正確に発行することです。
この関数の動作は以下の通りです。

• payable

  • 関数は payable であり、Etherの送金を受け付けます。

• イベントの発行

  • Deposit イベントを発行する必要があります。

• revertの条件

  • もしリクエストされたすべてのシェアが発行できない場合（例えば、預金限度に達している、スリッページが発生している、ユーザーが十分な量の msg.value のEtherをヴォルトコントラクトに送っていないなどの理由で）、関数は処理の取り消し（revert）する必要があります。

関数の入力と出力は以下の通りです。

• 入力:

  • shares
    • uint256。
    • 発行されるヴォルトのシェアの量。
  • receiver
    • address。
    • シェアが発行される受取人のアドレス。

• 出力:

  • assets
    • uint256。
    • 預けられたEtherに対して発行されるヴォルトのシェアに対応する資産の量。

mint 関数は、ユーザーがEtherを預けることによって指定された量のヴォルトのシェアを発行するために使われます。
この過程で、特定の条件下での取り消しを行うことが必要です。

イベント

イベントの使用法はERC4626と同じにする必要があります。

Wrapped ETH

Wrapped ETH ERC-20をアセットとして使用するERC4626 Vaultは、ERC7535を実装できません。
ERC7535はネイティブETHにのみ適用されます。

補足

ここでの説明はERC-4626との互換性を最大化しつつ、インターフェースにおける詳細を最小限に抑えることを目的としています。

deposit 関数の assets 入力の保持

この標準では、deposit 関数で assets 入力を保持しつつ、その使用をオプショナル（任意）にしています。
msg.value（送金されたEtherの量）が預け入れに必要であるため、これを主要な入力数値として扱うことが推奨されます。
assets を使用することによる厳密な等価性の強制は余分なガスコストを発生させ、異なる値を許容することは予期せぬ挙動を引き起こす可能性があるためです。

mint 呼び出しにおける msg.value と assets の不一致

ユーザーが mint 関数を呼び出す時に、Etherを多く預けることがあり得ます。
この場合、msg.value が assets と完全に一致することを強制すると、不必要な取り消しを引き起こすことがあります。
ヴォルトの実装者は、過剰なEtherを返金するか吸収するかを決定する責任があり、預金者は可能な限り正確な額を預けることが推奨されます。

ERC4626からの変更

fallback/__default__ メソッド、追加のヴォルト関数の支払可能性、コントラクトに強制的に送られたETHの取り扱いに関する強制的な行動やその欠如の不許可などのERC4626 との実装レベルでのすべての変更は、ERC20 トークンではなく、Etherまたは他のネイティブ資産の使用に適応するためのものです。

この新しい標準は、ERC4626との互換性を維持しつつ、Etherやその他のネイティブ資産の効率的かつ柔軟な取り扱いを可能にすることを目的としています。
これにより、開発者やユーザーは既存のツールやプロトコルとの互換性を保ちつつ、Etherの取り扱いをより効率的かつ安全に行うことができるようになります。

デポジットにおける assets パラメーターの無視

デポジットを行う時、msg.value（送金されたEtherの量）を指定する必要があります。
このため、msg.value を主要な入力数値として扱うことが推奨されています。
assets パラメーターを使用することは、厳密な等価性を強制して余分なガス（手数料）コストを発生させる可能性があるため、このパラメーターの使用は省略可能とされています。
また、assets が0であることを要求することも可能ですが、これは実装レベルでのガスコストが発生するため、assets は実質的に無視しても良いとされています。

ミントにおいて msg.value が assets 出力と等しくない場合の許容

ユーザーがミントの時にEtherを多く預けるケースが考えられます。
この場合、msg.value と assets 出力が等しいことを強制すると、不必要な取り消し（revert）が生じる可能性があります。
そのため、ヴォルトの実装者は余剰なEtherを返金するか受け取るかを決定する責任があります。
また、預金者はできるだけ正確な金額を預けることが推奨されます。

これらのガイドラインは、Etherの取り扱いをより効率的かつ安全にするためのものです。
ユーザーが予期せぬ手数料を払うリスクを減らし、コントラクトの実装者がシステムを柔軟に運用できるようにするための措置として導入されています。

互換性

ERC7535 は ERC4626 のインターフェースと基本的な機能をそのまま保持しつつ、Ether（ETH）の取り扱いに関して特別な考慮を加えた設計がなされています。

ERC7535では、ETHがERC20に準拠していないという事実を考慮して、いくつかの実装に違いがあります。
例えば、assetsパラメータよりもmsg.value送金されたEtherの量）を優先するという点です。
これは、ETHの特性に基づいた適応であり、ERC4626の基本的なフレームワークを変えるものではありません。

さらに、ERC7535には他の既存の標準との互換性問題がないとされています。
これは、ERC7535がEthereumの広範なエコシステム内で問題なく機能し、他の標準ともうまく共存できるように設計されていることを意味します。

ERC7535は、ERC4626 との互換性を維持しつつ、ETHの独自の特性を考慮した拡張を提供することで、Ethereumの様々なアプリケーションやプロトコルにおいて利用の幅を広げることが期待されます。

セキュリティ

ERC4626 に関連するセキュリティ上の考慮事項に加えて、ETHをヴォルト資産として使用する時のセキュリティ上の影響について述べています。

call と send の使用に関する注意

コントラクトがETHをtransferする時、call メソッドの使用には注意が必要です。
call を使用すると、信頼できるERC20トークンでは発生しない追加のリエントランシー（再入）の脆弱性や任意のコード実行が可能になるリスクがあります。
そのため、少量のガス手当てを伴う send を使用してETHを送る方が安全です。
ETHのtransfer方法を決定する時は、実装者は特に注意を払う必要があります。

強制的なETH転送

SELFDESTRUCT オペコードを使って、ETHは任意のヴォルトに強制的に送り込むことができます。
このため、ヴォルトの実装者は、このような転送がヴォルトの会計に何らかの形で影響を与えないことを確認する必要があります。
また、追加の支払い可能なメソッドも、ヴォルトの会計に影響を与えないよう慎重にチェックする必要があります。

SELFDESTRUCT オペコードについては以下の記事を参考にしてください。

SELFDESTRUCTの動作については以下の記事を参考にしてください。

Wrapped ETHの使用

ERC4626を実装するスマートコントラクトシステムは、基本資産としてERC20をサポートすることを検討し、ETHの直接的な取り扱いにERC7535を使用する代わりに、Wrapped ETHのようなERC20ラッパーを使用することが推奨されています。
これは、ERC4626とERC7535の間の微妙な違いがコードの断片化やセキュリティ上の懸念を引き起こす可能性があるためです。
Wrapped ETHやLiquid Staking Tokensのような、ETH専用のケースはERC7535にとってより適切な使用例です。

これらのポイントは、ETHをヴォルト資産として取り扱う時の特有のセキュリティリスクを強調し、それらを軽減するための推奨されるアプローチを提供しています。
安全性を確保するために、実装者はこれらの懸念事項を慎重に考慮し、適切な対策を講じる必要があります。

引用

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

最後に

今回は「ERC4626にETHなどのネイティブトークンを使用する仕組みを提案している規格であるERC7535」についてまとめてきました！
いかがだったでしょうか？

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

Twitter @cardene777

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