最近、イーサリアムコミュニティでは、意図とその応用について白熱した議論が交わされています。 この記事では、意図の背後にある原則、現在のアプリケーション、潜在的なリスク、およびそれらに対処する方法の概要を説明することを目的としています。
トランザクションが動作の実行方法を明示的に参照する場合、intent はその動作の予期される結果を参照します。
たとえば、トランザクションの指示が次のようになっているとします。
「AをやってからBをして、Cを払ってDをゲットする」
対応するインテントは次のようになります。
「お金も払えるし、Dも取りたい」
インテント中心のプロトコルは、ユーザー エクスペリエンスと効率を大幅に向上させることができます。 トランザクションでは、ユーザーが各パラメーターを明示的に指定する必要があるため、参入障壁が高くなります。 対照的に、Intentを使用すると、ユーザーは期待される結果を簡単に表現しながら、結果を最適に達成するタスクを成熟したサードパーティにアウトソーシングできます。
インテントはエコシステムにより多くの可能性を提供しますが、イーサリアムチェーンのインテントベースの設計は、オフチェーンのインフラストラクチャに大きな影響を与える可能性があります。 MEVと市場管理に関連する活動は、オンチェーンのインテントベース設計と決定的に関連しています。
現在、ユーザーがイーサリアムと対話するための標準的な方法は、状態遷移を実行するために必要なすべての情報をEVMに提供する特定の形式でトランザクションとメッセージを定式化して署名することです。 しかし、トランザクションの作成には、ガス料金を支払うために特定の資産を保有しながら、スマートコントラクトやノンス管理に関するかなり複雑な操作が必要になるなど、非常に複雑な操作が必要になることがあります。 複雑さは、ユーザーが十分な情報や複雑な実行戦略を伴わずに意思決定を行う必要があるため、ユーザーエクスペリエンスの低下と効率の低下につながります。
意図の目的は、ユーザーの負担を軽減することです。 インテントを使用すると、ユーザーは一連の記述的制約に署名することで、完全な制御を放棄することなく、トランザクションの作成をサードパーティにアウトソーシングできます。
標準的なトランザクションベースのプロセスでは、バリデーターが検証するようにインセンティブが与えられている場合、トランザクション署名により、バリデーターは特定の状態の計算パスを正確にたどることができます。 対照的に、インテントでは、どの計算パスを実行する必要があるかは正確に指定されませんが、特定の制約を満たす任意のアクションが許可されます。 インテントに署名して共有することで、ユーザーは受信者に計算パスを選択する権限を効果的に付与します(下の図を参照)。 1つのトランザクションに複数のインテントを含めることができるため、重複するインテントを一致させることができ、ガス料金を節約し、経済効率を向上させることができることは注目に値します。 さらに、ユーザーはガス料金をより柔軟に支払うことができ、ガスの第三者スポンサーシップや代替トークンを使用した支払いが可能になります。
図に示すように、トランザクションを送信するときにユーザーは正確な計算パスを指定し、インテントを送信するときに、ユーザーは目的といくつかの制約条件を指定し、マッチメイキングによって実行される計算パスを決定します。
インテントを作成することで、ブロックチェーンとのやり取りの複雑さをアウトソーシングしながら、ユーザーは自分の資産と暗号IDの管理を維持できます。 実際、インテントに関する多くの概念は、次のような数年間実行されているシステムに対応しています。
指値注文:ユーザーが少なくとも200 Bトークンを受け取った場合、アカウントから100 Aトークンを引き出すことができます。
カウスワップ スタイルのオークション: 指値注文と似ていますが、執行品質を最適化するために、複数の注文を照合する第三者またはメカニズムに依存しています。
ガススポンサーシップ:ユーザーはETHではなくUSDCで取引手数料を支払うことを選択でき、ガス料金を支払うためのUSDCが口座にあります。
委任された承認: 特定の事前承認された方法でのみ、特定のアカウントとの対話を許可します。 インテントは、最終トランザクションがインテントで指定されたアクセス制御リストに従う場合にのみ実行できます。
バッチ トランザクション処理: 複数のインテントのバッチ処理により、ガス効率が向上します。
アグリゲーター:最高の価格/利回りでのみ動作します。 複数のシナリオの集約を証明し、最適なパスを取ることで、意図を満たします。
現在、インテントは、クロスチェーンMEV(SUAVEなど)、ERC4337アカウントの抽象化、およびシーポートの注文シナリオで新しいアプリケーションを見つけています。 ERC4337が進化するにつれて、クロスドメインインテントなど、他の新しいアプリケーションの調査も進行中です。
すべてのインテントベースのアプリケーションには、インテントを理解し、インテントをタイムリーに実行するようにインセンティブを与えるグループが少なくとも1つ必要です。 誰がこの役割を演じるのか、どのように実装されるのか、そのインセンティブについては、インテントドリブンシステムの有効性、信頼性、その他の影響を判断するために、さらなる調査と実践が必要です。
仲介者とMempool
意図を意欲的な仲介者の手に渡す最も明白な方法は、イーサリアムMempoolです。 ただし、Mempool の現在の設計では、インテントの伝播はサポートされていません。 長期的な見通しでは、DOS攻撃の脆弱性を考慮すると、イーサリアムMempool内で意図が広くサポートされる可能性は最小限であることを示唆しています。 イーサリアムMempoolのオープンでパーミッションレスな性質は、インテントの採用に対する障壁となっています。
イーサリアムMempoolがない場合、インテントシステムの設計者はいくつかの課題に直面します。 現在のジレンマは、許可された当事者に意図を伝播するか、許可のない方法で伝達して、どの当事者も意図を実行できるようにするかを中心に展開します。
上の図に示すように、インテントはまずユーザーからパーミッション/パーミッションレス、パブリック/プライベートのインテントプールに流れ、次にマッチメーカーを介してトランザクションに変換し、最後にパブリックMempoolに変換するか、MEV Boostオークションを通じてオンチェーンで直接表示します。
パーミッションレスなMempool
実験中の設計の1つは、システム内のさまざまなノードがゴシップを通じてインテントをブロードキャストできるようにする分散型APIであり、それによってエグゼキューターにパーミッションレスアクセスを許可します。
例えば、0xプロトコルのリレイヤーでは、指値注文のゴシップブロードキャストが促進され、一致するものを見つけるとオンチェーンにプッシュされます。 このアプローチは、中央集権化と検閲のリスクに対抗するために、共有ERC4337 Mempoolのコンテキストでも検討されています。 ただし、このパーミッションレスなIntentpoolの設計には、次のようないくつかの課題もあります。
DoS耐性: 開発者は、潜在的なDoS攻撃を回避するために、インテントの機能を制限する必要がある場合があります。
伝播インセンティブ: 多くのアプリケーションにとって、インテントの実行は有益なアクティビティです。 したがって、理論的には、インテントプールを運用するノードには、インテントの実行競争を減らすためにインテントを伝播しないインセンティブがあります。
MEV: インテントの実行品質はオフチェーン参加者の適切な行動に依存するため、パブリックでパーミッションレスなインテントプールを使用する際にはいくつかの困難に直面します。 実行が利益を生む場合、パーミッションレスのIntentpoolはユーザーに対してアービトラージを試みる可能性があります。 これは、Ethereum Mempoolの「サンドイッチ攻撃」に似ており、Defi関連のインテントで一般的な問題になります。 改善の余地があるのは、パーミッションレスで暗号化されたIntentpoolを作成することです。
許可型 Mempool
信頼できる集中型APIは、DOS攻撃に対する耐性が高く、インテントを伝播する必要はありません。 この信頼モデルは、MEV の懸念事項に対するある程度の根拠となります。 信頼の前提が成り立つ限り、実行品質は保証されます。 また、信頼できる仲介業者は、評判が良い場合があり、真剣な執行の動機付けとなります。
したがって、許可型インテントプールは、短期的にはインテントベースのアプリケーション開発者にとって魅力的です。 しかし、強い信頼の前提には本質的に欠陥があり、ブロックチェーンの元の設計とある程度矛盾しています。
ハイブリッドソリューション
上記の 2 つの状況が混在するソリューションもあります。 たとえば、伝播プロセスには許可があるが、実行には許可がない状況があり、その逆も同様です。 ハイブリッドソリューションの一般的な例は、注文フローオークションです。
このタイプの設計の背後にある考え方は、取引相手を必要とするユーザーは、より有利な価格で取引するために、より良い取引相手と悪い取引相手を区別する必要があるかもしれないということです。 設計プロセスには、通常、ユーザーからインテント(またはトランザクション)を取得し、ユーザーに代わってオークションを促進する信頼できる当事者が関与します。 オークションへの参加に許可は必要ありません。 ただし、これらの設計には、許可されたIntentpool内のさまざまな妨害の影響を受けやすいという欠点もあります。
このアプローチの肝心な点は、インテントベースのアプリケーションには、スマートコントラクトと対話するための新しいメッセージ形式だけでなく、Mempoolの代替という形での伝播とピアディスカバリーのメカニズムも含まれるということです。 現在最も重要なことは、分散化を維持しながらインセンティブと互換性のある意図の発見とマッチングのメカニズムを設計することです。
インテントはトランザクションにとってエキサイティングな新しいパラダイムですが、その広範な採用は、ユーザーアクティビティが代替メモリプールに移行するというより大きな傾向が加速することを意味する可能性があります。 この移行が不適切に管理されると、イーサリアムの分散化が損なわれ、信頼できる当事者の過剰な力につながる可能性があります。 潜在的なリスクには、次のものがあります。
注文フロー:インテントの実行に許可があっても、ユーザーが不注意に選択してパブリックMempoolから移行した場合、イーサリアムブロックの生成が一元化される可能性があります。
信頼:多くのソリューションでは仲介者への信頼が必要なため、インテントの実行品質を確保するために、この高い参入障壁は新しいインテントベースのアーキテクチャの開発を妨げ、イノベーションと競争のスピードを低下させます。
透明性:いくつかのインテントアーキテクチャは、オンチェーン資産と許可されたmempoolに対するユーザーの制御を損ない、ある程度の不透明性を導入します。 この不透明度は、構築中のシステムが不透明になるリスクをもたらします。 この場合、ユーザーの期待がどのように満たされているか、エコシステムに検出されていない脅威があるかどうかは不明です。 ユーザーとブロックチェーンの間で進化するミドルウェアやmempoolのエコシステムでさえも、不透明になる可能性があります。
では、これらのリスクを軽減するにはどうすればよいでしょうか。 イーサリアムMempoolのスペースは限られていることを私たちは知っています。 一部のアプリケーションでは、プライバシーの欠如によりリスクが発生し、より広範なメッセージ形式をサポートできなくなります。 これにより、ウォレットとアプリケーションの開発者は、上記のリスクを回避しながらユーザーがブロックチェーンに接続できるようにする方法を見つけなければならないため、難しい立場に立たされています。 理想的なシステムは、実行品質を過度に犠牲にすることなく、誰もがインテントを照合して実行できるように、パーミッションレスである必要があります。 システムは、新しいmempoolを作成しなくても新しいアプリケーションをデプロイできるように、汎用性が高い必要があります。 システムは透明性があり、インテントの実行プロセスの公開レポートを可能にし、プライバシー保証が許す場合は品質監査を実施するためのデータを提供する必要があります。
FlashBotsやAnomaのようなチームは、プライバシーとパーミッションレスを組み合わせることで、ユニバーサルソリューションのための上記の要件を満たすために懸命に取り組んでいますが、近い将来、そのような完璧なシステムを作成することは難しいでしょう。 したがって、ユーザーはトレードオフを行い、アプリケーションごとに異なるソリューションを選択する必要があります。 同様に、インテントプールを開始するアプリケーションは、許可なくユビキタス性を求め、許可が得られる仲介者を慎重に選択する必要があります。
インテントベースアプリケーションの設計者は、ユーザーベースだけでなく、より広いコミュニティにも関わるアプリケーションのオフチェーンへの影響を十分に考慮する必要があります。 そのためには、より広いコミュニティがイーサリアム周辺のオフチェーンエコシステムに特別な注意を払う必要があります。
インテントベース アプリケーションに対する市場の需要は明らかであるため、多くのインテントベース アプリケーションが数年前から広く使用されています。 ERC4337も影響するインテントの採用が進むことで、イーサリアムのMempoolから新しいスペースへの移行が加速する可能性があります。 インテントの採用は、ユーザーにとって「強制操作」パラダイムから「記述的」パラダイムへのシフトを表し、ユーザーエクスペリエンスと効率の大幅な向上が期待されます。
イーバンカー公式サイト:https://www.ebunker.io
その他のディスカッションについては、以下に参加してください: https://t.me/ebunkerio
Ebunker Twitter: https://twitter.com/ebunker_eth
最近、イーサリアムコミュニティでは、意図とその応用について白熱した議論が交わされています。 この記事では、意図の背後にある原則、現在のアプリケーション、潜在的なリスク、およびそれらに対処する方法の概要を説明することを目的としています。
トランザクションが動作の実行方法を明示的に参照する場合、intent はその動作の予期される結果を参照します。
たとえば、トランザクションの指示が次のようになっているとします。
「AをやってからBをして、Cを払ってDをゲットする」
対応するインテントは次のようになります。
「お金も払えるし、Dも取りたい」
インテント中心のプロトコルは、ユーザー エクスペリエンスと効率を大幅に向上させることができます。 トランザクションでは、ユーザーが各パラメーターを明示的に指定する必要があるため、参入障壁が高くなります。 対照的に、Intentを使用すると、ユーザーは期待される結果を簡単に表現しながら、結果を最適に達成するタスクを成熟したサードパーティにアウトソーシングできます。
インテントはエコシステムにより多くの可能性を提供しますが、イーサリアムチェーンのインテントベースの設計は、オフチェーンのインフラストラクチャに大きな影響を与える可能性があります。 MEVと市場管理に関連する活動は、オンチェーンのインテントベース設計と決定的に関連しています。
現在、ユーザーがイーサリアムと対話するための標準的な方法は、状態遷移を実行するために必要なすべての情報をEVMに提供する特定の形式でトランザクションとメッセージを定式化して署名することです。 しかし、トランザクションの作成には、ガス料金を支払うために特定の資産を保有しながら、スマートコントラクトやノンス管理に関するかなり複雑な操作が必要になるなど、非常に複雑な操作が必要になることがあります。 複雑さは、ユーザーが十分な情報や複雑な実行戦略を伴わずに意思決定を行う必要があるため、ユーザーエクスペリエンスの低下と効率の低下につながります。
意図の目的は、ユーザーの負担を軽減することです。 インテントを使用すると、ユーザーは一連の記述的制約に署名することで、完全な制御を放棄することなく、トランザクションの作成をサードパーティにアウトソーシングできます。
標準的なトランザクションベースのプロセスでは、バリデーターが検証するようにインセンティブが与えられている場合、トランザクション署名により、バリデーターは特定の状態の計算パスを正確にたどることができます。 対照的に、インテントでは、どの計算パスを実行する必要があるかは正確に指定されませんが、特定の制約を満たす任意のアクションが許可されます。 インテントに署名して共有することで、ユーザーは受信者に計算パスを選択する権限を効果的に付与します(下の図を参照)。 1つのトランザクションに複数のインテントを含めることができるため、重複するインテントを一致させることができ、ガス料金を節約し、経済効率を向上させることができることは注目に値します。 さらに、ユーザーはガス料金をより柔軟に支払うことができ、ガスの第三者スポンサーシップや代替トークンを使用した支払いが可能になります。
図に示すように、トランザクションを送信するときにユーザーは正確な計算パスを指定し、インテントを送信するときに、ユーザーは目的といくつかの制約条件を指定し、マッチメイキングによって実行される計算パスを決定します。
インテントを作成することで、ブロックチェーンとのやり取りの複雑さをアウトソーシングしながら、ユーザーは自分の資産と暗号IDの管理を維持できます。 実際、インテントに関する多くの概念は、次のような数年間実行されているシステムに対応しています。
指値注文:ユーザーが少なくとも200 Bトークンを受け取った場合、アカウントから100 Aトークンを引き出すことができます。
カウスワップ スタイルのオークション: 指値注文と似ていますが、執行品質を最適化するために、複数の注文を照合する第三者またはメカニズムに依存しています。
ガススポンサーシップ:ユーザーはETHではなくUSDCで取引手数料を支払うことを選択でき、ガス料金を支払うためのUSDCが口座にあります。
委任された承認: 特定の事前承認された方法でのみ、特定のアカウントとの対話を許可します。 インテントは、最終トランザクションがインテントで指定されたアクセス制御リストに従う場合にのみ実行できます。
バッチ トランザクション処理: 複数のインテントのバッチ処理により、ガス効率が向上します。
アグリゲーター:最高の価格/利回りでのみ動作します。 複数のシナリオの集約を証明し、最適なパスを取ることで、意図を満たします。
現在、インテントは、クロスチェーンMEV(SUAVEなど)、ERC4337アカウントの抽象化、およびシーポートの注文シナリオで新しいアプリケーションを見つけています。 ERC4337が進化するにつれて、クロスドメインインテントなど、他の新しいアプリケーションの調査も進行中です。
すべてのインテントベースのアプリケーションには、インテントを理解し、インテントをタイムリーに実行するようにインセンティブを与えるグループが少なくとも1つ必要です。 誰がこの役割を演じるのか、どのように実装されるのか、そのインセンティブについては、インテントドリブンシステムの有効性、信頼性、その他の影響を判断するために、さらなる調査と実践が必要です。
仲介者とMempool
意図を意欲的な仲介者の手に渡す最も明白な方法は、イーサリアムMempoolです。 ただし、Mempool の現在の設計では、インテントの伝播はサポートされていません。 長期的な見通しでは、DOS攻撃の脆弱性を考慮すると、イーサリアムMempool内で意図が広くサポートされる可能性は最小限であることを示唆しています。 イーサリアムMempoolのオープンでパーミッションレスな性質は、インテントの採用に対する障壁となっています。
イーサリアムMempoolがない場合、インテントシステムの設計者はいくつかの課題に直面します。 現在のジレンマは、許可された当事者に意図を伝播するか、許可のない方法で伝達して、どの当事者も意図を実行できるようにするかを中心に展開します。
上の図に示すように、インテントはまずユーザーからパーミッション/パーミッションレス、パブリック/プライベートのインテントプールに流れ、次にマッチメーカーを介してトランザクションに変換し、最後にパブリックMempoolに変換するか、MEV Boostオークションを通じてオンチェーンで直接表示します。
パーミッションレスなMempool
実験中の設計の1つは、システム内のさまざまなノードがゴシップを通じてインテントをブロードキャストできるようにする分散型APIであり、それによってエグゼキューターにパーミッションレスアクセスを許可します。
例えば、0xプロトコルのリレイヤーでは、指値注文のゴシップブロードキャストが促進され、一致するものを見つけるとオンチェーンにプッシュされます。 このアプローチは、中央集権化と検閲のリスクに対抗するために、共有ERC4337 Mempoolのコンテキストでも検討されています。 ただし、このパーミッションレスなIntentpoolの設計には、次のようないくつかの課題もあります。
DoS耐性: 開発者は、潜在的なDoS攻撃を回避するために、インテントの機能を制限する必要がある場合があります。
伝播インセンティブ: 多くのアプリケーションにとって、インテントの実行は有益なアクティビティです。 したがって、理論的には、インテントプールを運用するノードには、インテントの実行競争を減らすためにインテントを伝播しないインセンティブがあります。
MEV: インテントの実行品質はオフチェーン参加者の適切な行動に依存するため、パブリックでパーミッションレスなインテントプールを使用する際にはいくつかの困難に直面します。 実行が利益を生む場合、パーミッションレスのIntentpoolはユーザーに対してアービトラージを試みる可能性があります。 これは、Ethereum Mempoolの「サンドイッチ攻撃」に似ており、Defi関連のインテントで一般的な問題になります。 改善の余地があるのは、パーミッションレスで暗号化されたIntentpoolを作成することです。
許可型 Mempool
信頼できる集中型APIは、DOS攻撃に対する耐性が高く、インテントを伝播する必要はありません。 この信頼モデルは、MEV の懸念事項に対するある程度の根拠となります。 信頼の前提が成り立つ限り、実行品質は保証されます。 また、信頼できる仲介業者は、評判が良い場合があり、真剣な執行の動機付けとなります。
したがって、許可型インテントプールは、短期的にはインテントベースのアプリケーション開発者にとって魅力的です。 しかし、強い信頼の前提には本質的に欠陥があり、ブロックチェーンの元の設計とある程度矛盾しています。
ハイブリッドソリューション
上記の 2 つの状況が混在するソリューションもあります。 たとえば、伝播プロセスには許可があるが、実行には許可がない状況があり、その逆も同様です。 ハイブリッドソリューションの一般的な例は、注文フローオークションです。
このタイプの設計の背後にある考え方は、取引相手を必要とするユーザーは、より有利な価格で取引するために、より良い取引相手と悪い取引相手を区別する必要があるかもしれないということです。 設計プロセスには、通常、ユーザーからインテント(またはトランザクション)を取得し、ユーザーに代わってオークションを促進する信頼できる当事者が関与します。 オークションへの参加に許可は必要ありません。 ただし、これらの設計には、許可されたIntentpool内のさまざまな妨害の影響を受けやすいという欠点もあります。
このアプローチの肝心な点は、インテントベースのアプリケーションには、スマートコントラクトと対話するための新しいメッセージ形式だけでなく、Mempoolの代替という形での伝播とピアディスカバリーのメカニズムも含まれるということです。 現在最も重要なことは、分散化を維持しながらインセンティブと互換性のある意図の発見とマッチングのメカニズムを設計することです。
インテントはトランザクションにとってエキサイティングな新しいパラダイムですが、その広範な採用は、ユーザーアクティビティが代替メモリプールに移行するというより大きな傾向が加速することを意味する可能性があります。 この移行が不適切に管理されると、イーサリアムの分散化が損なわれ、信頼できる当事者の過剰な力につながる可能性があります。 潜在的なリスクには、次のものがあります。
注文フロー:インテントの実行に許可があっても、ユーザーが不注意に選択してパブリックMempoolから移行した場合、イーサリアムブロックの生成が一元化される可能性があります。
信頼:多くのソリューションでは仲介者への信頼が必要なため、インテントの実行品質を確保するために、この高い参入障壁は新しいインテントベースのアーキテクチャの開発を妨げ、イノベーションと競争のスピードを低下させます。
透明性:いくつかのインテントアーキテクチャは、オンチェーン資産と許可されたmempoolに対するユーザーの制御を損ない、ある程度の不透明性を導入します。 この不透明度は、構築中のシステムが不透明になるリスクをもたらします。 この場合、ユーザーの期待がどのように満たされているか、エコシステムに検出されていない脅威があるかどうかは不明です。 ユーザーとブロックチェーンの間で進化するミドルウェアやmempoolのエコシステムでさえも、不透明になる可能性があります。
では、これらのリスクを軽減するにはどうすればよいでしょうか。 イーサリアムMempoolのスペースは限られていることを私たちは知っています。 一部のアプリケーションでは、プライバシーの欠如によりリスクが発生し、より広範なメッセージ形式をサポートできなくなります。 これにより、ウォレットとアプリケーションの開発者は、上記のリスクを回避しながらユーザーがブロックチェーンに接続できるようにする方法を見つけなければならないため、難しい立場に立たされています。 理想的なシステムは、実行品質を過度に犠牲にすることなく、誰もがインテントを照合して実行できるように、パーミッションレスである必要があります。 システムは、新しいmempoolを作成しなくても新しいアプリケーションをデプロイできるように、汎用性が高い必要があります。 システムは透明性があり、インテントの実行プロセスの公開レポートを可能にし、プライバシー保証が許す場合は品質監査を実施するためのデータを提供する必要があります。
FlashBotsやAnomaのようなチームは、プライバシーとパーミッションレスを組み合わせることで、ユニバーサルソリューションのための上記の要件を満たすために懸命に取り組んでいますが、近い将来、そのような完璧なシステムを作成することは難しいでしょう。 したがって、ユーザーはトレードオフを行い、アプリケーションごとに異なるソリューションを選択する必要があります。 同様に、インテントプールを開始するアプリケーションは、許可なくユビキタス性を求め、許可が得られる仲介者を慎重に選択する必要があります。
インテントベースアプリケーションの設計者は、ユーザーベースだけでなく、より広いコミュニティにも関わるアプリケーションのオフチェーンへの影響を十分に考慮する必要があります。 そのためには、より広いコミュニティがイーサリアム周辺のオフチェーンエコシステムに特別な注意を払う必要があります。
インテントベース アプリケーションに対する市場の需要は明らかであるため、多くのインテントベース アプリケーションが数年前から広く使用されています。 ERC4337も影響するインテントの採用が進むことで、イーサリアムのMempoolから新しいスペースへの移行が加速する可能性があります。 インテントの採用は、ユーザーにとって「強制操作」パラダイムから「記述的」パラダイムへのシフトを表し、ユーザーエクスペリエンスと効率の大幅な向上が期待されます。
イーバンカー公式サイト:https://www.ebunker.io
その他のディスカッションについては、以下に参加してください: https://t.me/ebunkerio
Ebunker Twitter: https://twitter.com/ebunker_eth