--- title: "ERC-4626トークン規格とは?" description: "新しいVaultトークン化規格と、DeFiプロジェクトへの実装方法を解説" --- # ERC-4626トークン規格とは? 現在いくつかの主要なトークン規格が存在するものの、[分散型金融（DeFi）](https://www.alchemy.com/overviews/guide-to-defi)の世界では、トークン化されたボールト（vault）に関する根強い問題が依然として残っている。これが、ERC-4626と呼ばれる新しい規格が生まれた背景である。 この記事では、ボールトとは何か、開発者がそれをトークン化する際に直面する問題、そしてERC-4626がDeFi開発においてこの問題をどう解決するかを説明する。その後、この規格がもたらす新しい変更点を詳しく見ていき、スマートコントラクトへの実装方法を示す。 ## **ボールトとは何か** ボールトとは、暗号資産などの資産を保管・管理できるマルチシグソリューションまたはスマートコントラクトである。各ボールトは、リターンの一形態として生成するトークンを常に持つ。これらの生成されたトークンは、後にボールトに元々ロックされていたトークンと交換できる。 例えば、自動マーケットメーカー（AMM）であるSushiswap上でSushiをステークすると、報酬としてxSushiを得る。同様に、DeFiの借入・貸出プロトコルである[Compound](https://www.alchemy.com/dapps/compound)でUSDCステーブルコインをイールドファーミングすると、cUSDCを得る。 cUSDCとxSushiはイールドベアリングトークンであり、元のトークン（この例ではUSDCやSUSHI）と交換して償還できる。イールドベアリングトークンの価値は、ボールトやプールにロックされているトークンが増える限り常に上昇する。 ボールトはウォレットよりも優れており安全であると見なされており、これが多くのDeFiプロトコルが資金をボールトに預ける理由である。ボールトを利用する主なDeFiプロトコルには、Sushiswap、[Aave](https://www.alchemy.com/dapps/aave)、[Balancer](https://www.alchemy.com/dapps/balancer)、Compoundなどがある。 ## **ボールトのトークン化における問題とは** イールドベアリングトークンに関して開発者が直面する問題は、異なるプロトコルのトークンを統合することである。 例えば、[DeFiアプリを構築する](https://www.alchemy.com/docs/alchemy-quickstart-guide)場合、各プロトコルのトークンを統合する必要があるとする。その場合、それぞれを調査し、イールドの発生モデルを理解し、自分のコードベースに合わせて調整する必要がある。 MakerDAOのvDAI、CurveのstETHなど複数のトークンを統合したい場合、それぞれのスマートコントラクトの特殊性を理解し、DeFiアプリに正しく統合するためのカスタムソリューションを構築する必要がある。 異なるイールドベアリングトークンを統合するこのプロセスがどれほど負担が大きく時間のかかるものであるかに加え、潜在的なエラーによりスマートコントラクトのリスクも増大する。 開発者はアダプター内の潜在的な抜け穴をチェックするためにより多くの時間を費やす必要があり、場合によってはスマートコントラクト監査人に外注する必要が生じることもある。これはかなりのコストがかかる可能性がある。攻撃者が多くのプロトコルやDeFiアプリの完全性を侵害している現在、これはより一層重要になっている。 ## **ERC-4626規格を作成したのは誰か** 2021年末に向けて、開発者が個別のイールドベアリングトークンを統合するのが困難であることに気づいたFei Protocolの創設者Joey Santoroは、他の4人のEthereum開発者からなるチームを率いて[**Ethereum Comment Proposal 4626**](https://eips.ethereum.org/EIPS/eip-4626)（ERC-4626）を提出した。 数回のレビューと議論を経て、Ethereumは2022年5月にこの規格を最終的に承認した。 ## **ボールトに関するERC-4626の利点とは** ERC-4626の主な利点は、トークン化されたボールトを標準化することで、プロトコル統合を容易にし、エラーの発生を減らすことである。 統合できる共通規格が存在するため、もはや個別のアダプターを構築する実質的な必要がなくなる。要するに、開発が加速する——コンポーザビリティが極まった形である。 同様に、開発者がアダプターやインターフェースの構築に監査人の助けを借りる必要がなくなるため、コストも削減される。最も重要な点として、ERC-4626はイールドベアリングトークンを扱う[アプリ](https://www.alchemy.com/dapps/top/defi-dapps)やイールドアグリゲーターのセキュリティを強化する。 ## ERC-4626規格が導入する変更点とは **新しいERC-4626トークンにより、イールドトークンを扱うDeFiアプリを構築するための規格が開発者に提供されるようになった。** 要するに、ERC-4626規格は以下の機能を実装する： - 統合したい開発者向けに最適化されたボールトインターフェース - 預け入れに対する交換としてシェアを付与する。シェアはボールトの原資産に対する部分的な所有権を表す - イールドベアリングコントラクトを開発する開発者向けの一貫した規格 - ボールトトークンのための実戦で検証されたセキュリティ ## **ERC-4626の仕組み：関数とイベント** ERC-4626は[ERC-20](https://www.alchemy.com/docs/how-to-interact-with-erc-20-tokens-in-solidity)規格の拡張であり、それと互換性がある。そのため、ERC-20トークンコントラクトに適用される通常の変数、イベント、関数のほとんどは、ERC-4626ボールト規格でもそのまま機能する。 このボールト規格は、プール全体から部分的な所有権を得る方法として_シェア（shares）_という概念を導入している。これらの_シェア_はイールドベアリングトークンを指す。 それでは、ERC-4626での開発を始めよう。 CairoやViperのような言語も使用できるが、ここでは[Solidity](https://www.alchemy.com/overviews/solidity)でこのコントラクトを書く。 ### **1. IDEにOpenZeppelin拡張をインポートする** IDE（Remixを推奨する）を開いたら、コンパイラにコントラクトを書くSolidityのバージョンを指示する。 ここでは0.8を使用すると宣言する。その後、ERC-20とERC-4626の両方の[OpenZeppelin](https://www.alchemy.com/dapps/openzeppelin)拡張をインポートする必要がある。 次に、コントラクトを作成し、名前を付けよう。 ### **2. コントラクトを作成する** コントラクトに名前を付け、それがERC-20トークンとERC-4626の両方に基づいていることをさらに明示する。 _Contract, testingVaults is ERC20, IERC4626 \{ your entire code here\}_ ### **3. 規格を実装する** コントラクトを作成した後、この規格のメソッド、関数、イベントについて知っておくべき重要な変更点がいくつかある。それでは、ERC-4626のメソッドとイベントのいくつかを見ていこう： #### Deposit ユーザーが資金をボールトに預け入れると、deposit関数がトリガーされ、スマートコントラクトが預け入れ者に対応する量のシェアをミントする。イベントとして、預け入れが発生するたびにスマートコントラクトがトリガーされなければならない。 この関数により、コントラクトに対してトークンをボールトに預け入れ、シェアの所有権を呼び出し元に与えるよう指示している。withdrawal関数も同様の方法で書くことができる。 #### **Withdrawal** withdrawal関数は、所有者が資産と引き換えにシェアをバーンするのを助ける。ボールトから引き出しが行われる際には、withdrawalイベントが発火されなければならない。 このイベントにおける address indexed \_from は、トークンのボールトへの預け入れを承認したユーザーを表し、預け入れられたトークンを引き出せる人物は *address indexed \_to* である。 #### Asset and totalAsset ボールトトークンのアドレスは_asset_関数で使用されるべきである。スマートコントラクト内の原資産の総量は*totalAssets*の下で宣言されるべきである。 #### convertToShares and convertToAssets ERC-4626規格の下では、変換に関する2つの関数がある：`convertToShares`と`convertToAssets`である。 資産をシェアに変換する必要がある場合、`convertToShares`が正しい呼び出すべき関数である。これは資産の代わりにリリースするシェアの数を含んでいるからである。 逆に、`convertToAssets`はその逆の方法、つまりシェアを資産に変換する。 #### **Mint** mint関数は、預け入れがあった際に受取人のために呼び出される。`maxMint`は、ボールト内のユーザーまたは受取人に対して作成できるシェアの総量である。開発者としてこれを設定する必要がある。 #### **Redeem** `redeem`関数は、所有者（msg.sender）からいくらかのシェアをバーンし、受取人に資産を送る。何らかの理由でシェアが償還できない場合、`redeem`は元に戻されなければならない。 `maxRedeem`は、所有者がボールトで償還できるシェアの数である。 #### Preview previewメソッドを使用する際、開発者はこれらのメソッドが返す値がまったく正確ではなく、近似値になることを念頭に置かなければならない。これらをオラクルとして頼るべきではない。 previewは、`mint`、`withdraw`、`redeem`、`deposit`といった他のメソッドと合わせて使用できる。 以上である。これでERC-4626での開発の旅を無事に始めることができた！ ## **まとめ – ERC-4626の未来** ERC-4626の登場により、DeFiに新しい潮流が生まれている。 これまでDeFiアグリゲーターは、規格が存在しなかったために複数のイールドベアリングトークンを集約するのに大きな負担を感じてきた。しかし今や、ERC-4626により、1回のAPI呼び出しでイールドベアリングトークンの詳細を取得できるようになった。 イールドベアリングトークンを扱うDeFiアプリケーションのセキュリティを強化するために余分な労力を払うという問題は、この実戦で検証された規格によって、かなりの部分まで解決される。 今後数年間で、さまざまなDeFiプロトコル間でのコンポーザビリティと相互運用性の活用は増加していくだろう。この規格が、DeFiエコシステムにおいて完全に新しい製品を構築・展開するための土台になる可能性すらある。