# [ERC5252] アカウントバウンドトークンの資金喪失を防止する仕組みを理解しよう！ > このEIPは、イーサリアム（Ethereum）のアップグレード提案で、資産の管理と投資の透明性を確保し、金融運用業者からの独立性を守るための新しいスマートコントラクトのデザインパターンを提案しています。 - URL: https://cardene.dev/articles/4bc7450d05678a4729ea - 公開日: 2023-10-18 - 更新日: 2023-10-18 - トピック: Blockchain - タグ: ethereum, solidity, ブロックチェーン, nft ## はじめに 初めまして。 **CryptoGames**というブロックチェーンゲーム企業でエンジニアをしている **cardene（かるでね）** です！ スマートコントラクトを書いたり、フロントエンド・バックエンド・インフラと幅広く触れています。 https://cryptogames.co.jp/ 代表的なゲームは**クリプトスペルズ**というブロックチェーンゲームです。 https://cryptospells.jp/ 今回は、アカウントバウンドトークンの仕組みを提案している**ERC5114**において、資金喪失を防止する規格である**ERC5252**についてまとめていきます！ :::message 以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。 ::: https://eips.ethereum.org/EIPS/eip-5252 :::message alert **5252**は現在（2023年10月14日）では「**Review**」段階です。 ::: ## 概要 このEIPは、イーサリアム（Ethereum）のアップグレード提案で、資産の管理と投資の透明性を確保し、金融運用業者からの独立性を守るための新しいスマートコントラクトのデザインパターンを提案しています。 具体的には、個人の資産を管理するために個別のファイナンスコントラクトを使用する方法を導入しています。 これにより、投資家は自分の資産に高い自己主権を持つことができます。 また、投資家の資金と運用手数料の区別が個別のスマートコントラクトで明示的に行われるため、運用チームによる資金の任意の損失から保護されます。 この提案は、**ERC5114**と呼ばれる既存の規格を拡張し、複数のウォレットを管理するための新しい機能を提供します。 :::message **ERC5114**については以下を参考にしてください。 ::: [\[ERC5114\] NFTとアドレスに紐づいたSBTライクな仕組みを理解しよう！](/articles/f447336e0c4eb3f886ad) これにより、投資家は異なるウォレット間で資金を移動しやすくなります。 :::message この提案は個人の資産を保護し、投資を透明かつ効果的に管理する方法を改善するものです。 自己主権を持ちつつ、金融運用業者からのリスクを軽減し、資産の移動を容易にすることを目指しています。 ::: ## 動機 分散型金融（DeFi）は信頼性の課題に直面しています。 まず、DeFiスマートコントラクトはしばしば、実際のコントラクトのロジックが個別のロジックコントラクトに隠れているプロキシのような役割を果たします。 :::message 例として、AとBという2つのユーザーが資産を交換するDeFiプラットフォームを想像してみます。 1. **通常のスマートコントラクト** - ユーザーAがユーザーBにイーサリアム（ETH）を送金する必要があるとします。 - この場合、通常のスマートコントラクトはAからETHを引き出し、それをBに送金するためのトランザクションを直接実行します。 - スマートコントラクト内でのロジックは透明で、AとBのアクションがブロックチェーン上に記録されます。 - ユーザーはスマートコントラクトのロジックに信頼を置いています。 2. **プロキシスマートコントラクト** - 一方、プロキシスマートコントラクトでは、トランザクションの実行が別のスマートコントラクト（ロジックコントラクト）を介して行われます。 - ユーザーAはプロキシコントラクトにトランザクションを送信し、そのトランザクションに従ってロジックコントラクトが操作を実行します。 - プロキシコントラクトは一種のインターフェースのような役割を果たし、ユーザーのリクエストをロジックコントラクトに中継します。 - プロキシスマートコントラクトには通常のスマートコントラクトと比べて制約が少ないため、セキュリティ上のリスクが低いとされています。 - しかし、ロジックコントラクトに依存するため、そのロジックコントラクトの信頼性が問われます。 この例では、プロキシスマートコントラクトは、ユーザーの操作をロジックコントラクトに委任し、プロキシ自体は制約が少ない役割を果たすことがわかります。 ユーザーはロジックコントラクトの信頼性に依存するため、そのロジックコントラクトが正当であることを確認する必要があります。 ::: また、多くのプロジェクトでは、過度な権限を持つマルチシグネチャの「**ウォレット**」が使われています。 さらに、ステーブルコインがその価値を維持するために十分な資産を保有しているかどうかを独立して検証することが難しく、これが大規模な資金の損失を招くことがあります。 具体的な例として、Celsiusの公式破産発表やUST（Terraのステーブルコイン）のペッグ解除、Anchorプロトコルの失敗が挙げられます。 このような状況下では、Web3.0においても運営者や中間者に投資を全面的に信頼することは難しいと言えます。 スマートコントラクトは本来、コードで記述された約束を実現するためのものであり、信頼性を高めるために設計されています。 しかし、現在のDeFiコントラクトは、通常、非常に少数のスマートコントラクトを使用して全体の投資家資金を管理しており、さらに信頼されたキーが完全な制御を持っている場合があります。 これにより、投資家は資金をコントラクトの運営者に全面的に委ねなければならず、実際にはユーザー自身が資産を所有していない可能性があります。 一方で、個人のファイナンスコントラクトのアプローチは、より透明性を提供します。 各個人に対する個別のファイナンスコントラクトを使用することで、資産の活動を追跡しやすくなります。 これにより、投資家は自分の資金の動向をより詳細に監視できます。 また、このパターンは、個人のファイナンスコントラクトからの資格情報を格納するための特別なトークンである「**非交換可能なアカウントバウンドトークン（ABT）**」を導入しています。 :::message このアプローチはDeFiにおける信頼性の問題に対処し、より透明性を持たせながら、投資家が資産をより効果的に管理できる方法を提供しています。 ::: ### オフチェーン・アイデンティティとソウル・バウンド・トークンのクレデンシャル比較 このEIPは、オフチェーンのアイデンティティソリューションと「**ソウルバウンドトークン**」を使用した資格情報に関する議論を提供しています。 オフチェーンのアイデンティティソリューションは、そのバックエンドが運営者の信頼に依存するため、全体のシステムを運営者の信頼に左右される傾向があります。 これらのソリューションは、ブロックチェーン技術の基本的な考え方である、数学的な証明（例：プルーフ・オブ・ワーク、プルーフ・オブ・ステークなど）ではなく、運営者の信頼に依存しています。 オフチェーンのアイデンティティは、そのアイデンティティ情報がブロックチェーン以外の場所に保存されるため、暗号通貨の基本的な原則と直接対立しています。 一方、「**ソウルバウンドトークン**」は、信頼性の高い資格情報を提供するための優れた代替手段です。 ソウルバウンドトークンは、数学的な証明に依存し、ブロックチェーン上で検証可能な資格情報を提供します。 アイデンティティ情報そのものはブロックチェーンの外部に保存されず、代わりにトークンのメタデータだけがオフチェーンに保存されます。 :::message このEIPは、オフチェーンのアイデンティティ情報に対する新しいアプローチとして、ソウルバウンドトークンを提案しています。 これにより、ブロックチェーン上で信頼性の高い資格情報を提供し、運営者の信頼に依存せずに済む方法が採用されることを目指しています。 ::: ## 仕様 この仕様は、「**インタラクション**」と「**ガバナンス**」の2つのパターンで構成されている。 ### インタラクション #### インターフェース このインタラクションパターンは、5つの異なる役割を持つコントラクトで構成されています。 これらの以下のような役割を担っています。 ##### アカウントバウンドトークンコントラクト このコントラクトは、資格情報を持つユーザーにファイナンスコントラクトとのやり取り権限を付与するために使用されます。 これにより、このトークンを持っているユーザーはファイナンスコントラクトと連携できます。 ##### マネージャーコントラクト マネージャーコントラクトは、最初に投資家とコンタクトを取り、その後のやり取りを調整する役割を果たします。 投資家との最初の接触ポイントであり、その後の操作に関する指示を提供します。 ##### ファクトリーコントラクト ファクトリーコントラクトは、各ユーザーに対して個別のファイナンスコントラクトを生成するために使用されます。 各ユーザーは、自分専用のファイナンスコントラクトを持ちます。 ##### ファイナンスコントラクト ファイナンスコントラクトは、投資家とのやり取りを管理するコントラクトです。 投資家とのやり取りには、資産の管理、取引の実行、その他の操作が含まれます。 ##### エクステンション（拡張） エクステンションは、特定の追加機能や拡張機能を提供する役割を果たすコントラクトです。 このコントラクトは、必要に応じてプラットフォームに追加の機能を組み込むために使用されます。 このパターンによって、アカウントバウンドトークンを通じてユーザーはファイナンスコントラクトとのやり取り権限を持ち、マネージャーコントラクトが最初の接触ポイントとして機能し、ファクトリーコントラクトが個別のファイナンスコントラクトを生成し、ファイナンスコントラクトがやり取りを処理します。 エクステンションコントラクトは、必要に応じて追加の機能を提供するために使用されます。 このように、各コントラクトが異なる役割を果たし、全体として効果的なインタラクションパターンを形成しています。 #### 必要条件 ##### ソウルバウンドまたはアカウントバウンドトークンコントラクト **ERC721**に従う非代替可能なトークン。 資格情報は`tokenURI()`関数を使ってメタデータとして表現。 トークンの生成を検証するのにファクトリー（factory）を参照。 譲渡可能かどうかでアカウントバウンドかソウルバウンドかを区別。 ##### マネージャーコントラクト ファクトリーを使ってユニークなコントラクトの生成を行う。 金融パラメータの関連構成を保存。 ##### ファクトリーコントラクト 一貫した実装でファイナンスコントラクトを複製。 アカウントバウンドトークンを生成する唯一のファクトリーを使ってユニークなコントラクトの生成を行う。。 アカウントバウンドトークンの最新IDを保持。 ##### ファイナンスコントラクト ファイナンスコントラクトはコンストラクタでファクトリーコントラクトから一度だけ初期化。 資金はアカウントバウンドトークン所有者が署名しない限り他のコントラクトやアカウントに転送不可。 スマートコントラクトの状態変更関数はアカウントバウンドトークン所有者のみ受け付け、グローバル関数は誰でもアクセス可能とコメント。 各ファイナンスコントラクトはアカウントバウンドトークン所有者間の取引のみを表現。 ソウルバウンドトークン使用時は、プライベートキー所有者との取引のみを表現。 これにより、資格情報とアクセスのセキュリティを確保し、操作の透明性を実現するコントラクト設計が提供されます。 ### コントラクト ![media.png](/images/qiita-51fedfd9-8ae9-88a2-3622-e660bd7acd3c.webp) 引用: https://eips.ethereum.org/EIPS/eip-5252 ##### マネージャーコントラクト マネージャーコントラクトは投資家とのやり取りの入り口であり、ファイナンスコントラクトのパラメータを保存します。 ##### ファクトリーコントラクト ファクトリーコントラクトは、投資家の資金を管理するためのコントラクトバイトコードを管理し、マネージャーコントラクトの承認に基づいてファイナンスコントラクトを複製します。 また、ファイナンスコントラクトとのやり取りに必要なアカウントバウンドトークンを生成します。 ##### ファイナンスコントラクト ファイナンスコントラクトは、投資家の資金を管理するルールを指定します。 このコントラクトはアカウントバウンドトークンを持つアカウントからのみアクセス可能です。 投資家がマネージャーコントラクトに資金を預けると、手数料を差し引いた後、その資金をファイナンスコントラクトのアカウントに送信します。 ##### アカウントバウンドトークン このEIPのアカウントバウンドトークンコントラクトは、ファイナンスコントラクトのデータを持ち、メタデータを追加できます。 たとえば、マネーマーケットレンディングのファイナンスコントラクトがある場合、そのアカウントバウンドトークンはSVGを使用して合意の中でどれだけの残高があるかを表示できます。 ##### エクステンション エクステンションコントラクトは、ファイナンスコントラクト内のロックされた資金を利用できる別のコントラクトです。 このコントラクトは、マネージャーコントラクトで管理されるオペレーターの承認に基づいてファイナンスコントラクトにアクセスできます。 エクステンションの使用例は会員制のサービスなどが考えられます。 ##### メタデータ メタデータコントラクトは、アカウントの資格情報に関連するメタデータを保存するコントラクトです。 資格関連のデータは特定のキーで保存されます。 通常、画像はSVGとして表示されますが、オフチェーンの画像も可能です。 これらのコントラクトは、投資家の資産の管理とアクセスのセキュリティを向上させるために使用されます。 ### ガバナンス ガバナンスのパターンは、「**インフルエンサー**」と「**ガバナー**」という2つの要素で構成されています。 #### 必要条件 ##### インフルエンサーコントラクト このコントラクトは、投票時のスコアに対する乗数を管理します。 スコアの正規化に使用する小数を設定します。 ガバナンスがファクターパラメータを決定できる機能を提供します。 ##### ガバナーコントラクト このコントラクトは、OpenZeppelinのガバナーコントラクトに従います。 乗数計算に必要な情報をインフルエンサーコントラクトから取得します。 アカウントバウンドトークンが二重投票を防ぐため、請求後のトークン移転を制限します。 https://docs.openzeppelin.com/contracts/4.x/api/governance :::message インフルエンサーコントラクトは、投票スコアに対する乗数と正規化に必要な情報を管理し、ガバナンスがファクターパラメータを調整できる機能を提供します。 ガバナーコントラクトはOpenZeppelinの規格に従いつつ、インフルエンサーコントラクトから必要な情報を取得し、アカウントバウンドトークンが二重投票を防ぐセキュリティを確保します。 ::: #### トークンのガバナンスから貢献ベースのガバナンスへ | | トークンガバナンス | 資格ベースのガバナンス | | ------------ | --------------------------- | ---------------------------- | | 強制力 | トークン数が多ければ権力が大きい。 | 寄与が多ければ権力が大きい。 | | インセンティブ | トークン数が多ければインセンティブが大きい。 | 寄与が多ければインセンティブが大きい。 | | 制裁 | 制裁はない。 | 権力の喪失。 | | 割り当て | トークンを保持する者が権限を持つ。 | 最も影響力のある者が権限を持つ。 | :::message この表は、トークンベースのガバナンスと資格ベースのガバナンスの違いを示しています。 トークンベースのガバナンスでは、トークンの数量が権力やインセンティブを決定する一方、資格ベースのガバナンスでは寄与度が権力やインセンティブに影響を与えます。 また、トークンベースのガバナンスでは制裁が存在せず、トークンを保持する者が権限を持ちますが、資格ベースのガバナンスでは制裁が権力の喪失として適用され、最も影響力のある者が権限を持ちます。 ::: トークンガバナンスは、単にトークンの数量に依存するため、その持続性に課題があります。 このアプローチでは、トークンの51％以上を保有する個人が強制的にコントロールを握ることができ、これは公平性に欠ける問題です。 新しいガバナンスアプローチは、プロトコルへの実際の貢献度を考慮することを重視しています。 なぜなら、このアプローチには以下の利点があるからです。 ##### 罰則の導入 新しいガバナンスでは、プロトコルを破壊しようとする支配者に罰則を課すことができます。 つまり、ルールを守らない行為には制裁があります。 ##### 効果的なインセンティブ 貢献者に対するインセンティブを効果的に提供できます。 プロトコルの維持や発展に貢献した者に対して報酬を与えることが可能です。 ##### 責任ある者への権限付与 権力は、単にトークンの所有者に与えられるのではなく、プロトコルに対する実際の貢献に基づいて決定されます。 具体的には、アカウントバウンドトークン（ABT）と呼ばれるトークンを通じて、プロトコルへの寄与度を示す投票権が与えられます。 この新しい投票権は「**インフルエンス**」と呼ばれます。 この新しいガバナンスアプローチの目的は、単なるトークンの保有量に依存せず、プロトコルへの実際の寄与度に基づいて権力を分配し、より公平で持続可能なシステムを実現することです。 #### 影響力の計算 インフルエンス（Influence）は、DAOのステークトークンに対する乗数です。 この乗数により、DAOのコントリビューターはより多くの投票権を持つことができます。 インフルエンスを計算するプロセスは次のとおりです。 ##### 貢献度行列のスコア計算 まず、コントリビューターの貢献度行列が作成されます。 この行列には、コントリビューターごとに貢献度が評価されたスコアが含まれています。 貢献度は様々な要因に基づいて計算されます。 ##### スコアの正規化 計算されたスコアは、メンバーの全体分布内での位置を示すために正規化されます。 これにより、各メンバーの貢献度が全体の分布に対してどれだけの相対的な位置にあるかがわかります。 ##### 乗数の決定 最後に、各コミュニティメンバーの位置に基づいてインフルエンスの乗数が決定されます。 これにより、コミュニティメンバーごとに異なる投票権が与えられ、貢献度に基づいて投票権が調整されます。 このプロセスによって、トークンの保有量だけでなく、実際の貢献度に基づいて投票権が分配され、より公平で持続可能なガバナンスシステムが実現されます。 #### スコアの計算 | 要因 | 説明 | |---------------|----------------------------------------------------------------| | α（アルファ） | 各提案の中で、現在のファイナンス契約からの貢献価値を示します。 | | β（ベータ） | 各ファイナンスコントラクトが提案のタイムスタンプからファイナンス契約を維持した時間を示します。 | 上記の表は、異なる要因であるαとβに関する説明を提供しています。 これらの要因は、提案の重要性を評価する時に使用され、相対的な重要性を示します。 要因の合計重要性は、すべての要因の重要度の合計です。 コミュニティは提案時に、これらの要因に正規化を適用することができ、その結果、提案の評価に対する各要因の寄与が均等になります。 ##### α（アルファ） 各提案において、現在のファイナンスコントラクトからの貢献価値を示します。 つまり、各ファイナンスコントラクトが提案に対してどれだけの価値を提供しているかを評価します。 ##### β（ベータ） 各ファイナンスコントラクトが提案のタイムスタンプからファイナンスコントラクトを維持した時間を示します。 これは、各コントラクトがプロトコルに対する継続的な貢献をどれだけ行っているかを測定します。 これらの要因は提案の評価に使用され、コミュニティは提案時にこれらの要因に正規化を適用することができ、その結果、提案の評価に対する各要因の寄与が均等になります。 ```javascript (score per each ABT) = α * (contribution value) + β * (time that abt was maintained from now) ``` #### 正規化 DAO内のユーザーの貢献度を公平に評価するための手法です。 正規化されたスコアは、提案を送信した状態から計算され、各アカウントバウンドトークン（ABT）の貢献度を示す指標として使用されます。 この計算は、以下の式に従います。 ```javascript (Normalized score per each ABT) = α * (contribution value)/(total contribution value at submitting tx) + β * (time that abt was maintained)/(time passed from genesis to proposal creation) ``` :::message (各ABTの正規化スコア) = α * (貢献価値) / (提案送信時の総貢献価値) + β * (ABTが維持された時間) / (ジェネシスから提案作成までの経過時間) ::: この式では、2つの要因でスコアが計算されます。 ##### 貢献価値（Contribution Value） αで重みづけされています。 各ファイナンスコントラクトからの貢献度を表します。 つまり、各コントラクトが提案に対してどれだけの価値を提供しているかを示します。 ##### ABTの維持時間（Time that ABT was maintained） βで重みづけされています。 各コントラクトがファイナンスコントラクトを維持した時間を表します。 これは、コントラクトがプロトコルに対する継続的な貢献をどれだけ行っているかを測定します。 これらの要因の合計により、各ABTの正規化スコアが計算されます。 正規化スコアは0から1の範囲の値を取り、ユーザーの貢献度を公平に評価します。 このシステムにおいて、αとβの合計は1になるように調整されています。 :::message 正規化は貢献度を均等に評価し、DAO内の各メンバーの影響力を公平に計算するための手法です。 ::: #### マルチプレイヤー マルチプライヤーは、ベースファクター（b）とマルチプライヤー（m）によって線形に決定されます。 これは、インフルエンス（投票権の乗数）を計算するための重要な要素です。 インフルエンスの計算式は以下のようになります。 ```javascript (influence) = m * (sum(normalized_score)) ``` :::message (インフルエンス) = m * (正規化スコアの合計) ::: この式では、まず正規化スコアの合計が計算され、その後にマルチプライヤー（m）が掛けられて、最終的なインフルエンス値が得られます。 この計算方法により、各メンバーの正規化スコアの合計に対して、マルチプライヤーが適用され、それに基づいてインフルエンスが計算されます。 インフルエンスは、メンバーの投票権を決定する重要な指標であり、マルチプライヤーはその値を調整するための要素です。 :::message マルチプライヤーは正規化スコアの合計に影響を与え、最終的なインフルエンス値を決定するための計算に使用されます。 ::: #### 例 具体的に説明します。 あるユーザーが以下の条件で計算されたインフルエンスと総投票権を持っていると仮定しましょう。 - ユーザーが3つのアカウントバウンドトークンを持っており、それぞれの正規化スコアは`1.0`、`0.5`、`0.3`です。 - ユーザーは追加でロックされたトークン`100`を持っています。 - マルチプライヤー（m）は`0.5`です。 - ベースファクター（b）は`1.5`です。 1. まず、各アカウントバウンドトークンの正規化スコアを合計して平均を取ります。 ```math (1.0 + 0.5 + 0.3) / 3 = 0.6 ``` 2. 次に、この平均正規化スコアにマルチプライヤーを掛けて、ベースファクターを加えてインフルエンスを計算します。 ```math インフルエンス = 0.5 * 0.6 + 1.5 = 0.9 + 1.5 = 2.4 ``` 3. 最後に、総投票権を計算します。これはインフルエンスにロックされたトークンの平方根を掛けたものです。 ```math 総投票権 = 2.4 * √100 = 2.4 * 10 = 24 ``` したがって、このユーザーは総投票権が`24`を持っており、これを用いてDAO内での投票や決定に参加することができます。 この計算により、ユーザーの貢献度、正規化スコア、ロックされたトークンの量、マルチプライヤー、ベースファクターが考慮され、最終的な投票権が算出されました。 #### ステーカー VS エンフォーサー 以下の表は、「**Stakers**」と「**Enforcers**」の役割、人口、貢献度、およびインフルエンスについて簡潔に説明しています。 | | 役割 | 人口 | 貢献度 | インフルエンス | |-----------|----------------------------------------|---------|--------------|------------------------------| | Stakers | 投票のためにガバナンストークンをステーク。 | 多数。 | 影響が少ない。 | 平方根（ロックトークンの数）。 | | Enforcers | システムへの貢献者で、ルール変更提案可能、1.5倍の投票権。 | 少数。 | 影響が大きい。 | インフルエンス × 平方根（ロックトークンの数）。 | この表によれば、Stakersは主にガバナンストークンをステークして投票に参加し、多数派ですが、個々の影響力は比較的小さいです。 一方、Enforcersはシステムへの貢献者で、ルール変更の提案を行うことができ、1.5倍の投票権を持っています。 Enforcersは少数派ですが、その個々の貢献度が大きく、ロックされたトークンの数に応じてインフルエンスが増加します。 ##### Stakers（ステーカー） Stakersは、エンフォーサーの提案に投票し、ステークしたトークンに対する配当を受け取る人々です。 彼らの主な役割は、システムの提案に投票し、そのためにトークンをステークすることです。 ステークによって、彼らはシステムの運営に参加し、トークンを保有することで報酬を得ることができます。 ##### Enforcers（エンフォーサー） Enforcersは、プロトコルの管理に関連するリスクを引き受け、提案を行い、プロトコルへの変更に貢献する人々です。 彼らの主な役割は、プロトコルに変更を提案し、それを実現するために努力することです。 エンフォーサーはプロトコルの健全性と発展に貢献し、そのために特別な権限や投票権を持つことがあります。 :::message Stakersはトークンをステークして投票し、報酬を得る役割を果たし、Enforcersはプロトコルの管理と改善に取り組む役割を果たす人々です。 両者はプロトコルの運営と成長に寄与しますが、役割と責任が異なります。 ::: #### コントラクト ##### Influencerコントラクト Influencerコントラクトは、インフルエンスの設定を保持し、ユーザーが登録したアカウントバウンドトークンコントラクトで行った活動からの貢献度を計測します。 このコントラクトは、提案が最終化されるまで、そのアカウントバウンドトークンにロックをかけます。 :::message ユーザーの貢献度を測定し、提案が確定するまでトークンをロックする役割を担います。 ::: ##### Governorコントラクト Governorコントラクトは、OpenZeppelinの現行のガバナーコントラクトと互換性があります。 特定のユースケースに適しており、インフルエンサーが管理し、マネージャーコンフィグのパラメータを変更できるように設定します。 新しいパラメータを提案できるのはエンフォーサーだけです。 :::message Governorコントラクトは、マネージャーコンフィグのパラメータを管理し、変更するための特別なユースケースに使用され、エンフォーサーのみが新しいパラメータを提案できます。 ::: これらのコントラクトは、プロトコルの運営やパラメータの変更に貢献する役割を果たします。 ## 補足 ### エンドユーザー向けのガス節約 複数のコントラクトを使用することによるガスコストの節約は、長期的にはガスの使用料を削減できるメリットがあります。 ただし、この節約はクローンファクトリーパターンを適用することで実現されます。 通常、1つのコントラクトがユーザーの状態をグローバルに管理しますが、これにより各ユーザーはコントラクトとやり取りした後に他のユーザーのデータストレージコストを支払うことになります。 例えば、MakerDAOのようなコントラクトでは、この方法によって運用コストが時折`0.1 ETH`を超え、ユーザーの最低入金額が制限されています。 将来のユーザーに対して非効率的なn回のガスコストを請求する代わりに、各ユーザーに対して1つのコントラクトが使用されます。 ### 投資家資金と運用資金の分離 スマートコントラクトにおいて、投資家の資金と運用手数料は厳密に分離されており、投資家は運用チームによる資金の不正使用から保護されます。 つまり、投資家の資金は運用資金とは別に保管され、運用手数料は明確に規定されています。 これにより、運用チームが運用資金を乱用することから投資家の資金を守ることができます。 :::message 複数のコントラクトを使用することでガスコストを削減し、投資家の資金と運用資金を分離することでセキュリティと効率を向上させます。 ::: ## 後方互換性 既知の後方互換性の問題はありません。 ## 参考実装 以下のGithubに参考実装が格納されています。 https://github.com/ethereum/EIPs/tree/master/assets/eip-5252/contracts ## セキュリティ考慮事項 ### ファクトリーコントラクト ファクトリーコントラクトは、ファイナンスコントラクトがファクトリーに登録され、それらのファイナンスコントラクトが正当なトランザクションを送信していることを確認する役割を担います。 ファクトリーコントラクトは、ファイナンスコントラクトの登録とトランザクションの正当性を管理します。 ### 再入攻撃対策 再入攻撃対策は、マネージャーコントラクトやファイナンスコントラクト内の各ユーザー関数で重要です。 これにより、デリゲートコールの前に再入攻撃を防ぐためのガードが適用され、状態が変更されます。 再入攻撃はセキュリティ上の脆弱性であり、防止するための対策が必要です。 再入攻撃が発生すると、ファイナンスコントラクトが2重に生成され、システム全体が崩壊する可能性があります。 ### インフルエンスのロック ユーザーが提案の投票にインフルエンスをロックした場合、関連するアカウントバウンドトークンは別のウォレットに転送できなくなります。 これは、投票の正当性と一貫性を保つための重要なセキュリティ対策です。 インフルエンスのロックを実施しないと、2重のインフルエンスが生じ、システムの信頼性が損なわれる可能性があります。 ## 引用 Hyungsuk Kang (@hskang9), Viktor Pernjek (@smuxx), "ERC-5252: Account-bound Finance [DRAFT]," Ethereum Improvement Proposals, no. 5252, June 2022. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-5252. ## 最後に 今回は「アカウントバウンドトークンの仕組みを提案している**ERC5114**において、資金喪失を防止する規格である**ERC5252**」についてまとめてきました！ いかがだったでしょうか？ 質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！ [Twitter @cardene777](https://twitter.com/cardene777) 他の媒体でも情報発信しているのでぜひ他も見ていってください！ https://chaldene.net/ https://zenn.dev/heku https://mirror.xyz/0xcE77b9fCd390847627c84359fC1Bc02fC78f0e58