イーサリアムメタトランザクションの共通標準の探索
編集者注: この記事は以下からのものです。イーサリアム愛好家 (ID: ethfans)編集者注: この記事は以下からのものです。
イーサリアム愛好家 (ID: ethfans)
この記事は、Gitcoin 上のメタトランザクションを一般化するための Metamask の競争に対する Bloxis の回答です。この機能を今後の製品に組み込む予定であるため、この分野に多大な時間と労力を費やしてきました。そのため、この分野の議論にぜひ参加したいと考えています。私の意見に異論がある場合は、ぜひご指摘ください。喜んで議論させていただきます。
導入
- 出典: Gitcoin -
導入
お金を使う意思がある限り、ほぼ完全に分散化されたボーダレス ブロックチェーン ネットワーク上で、イーサリアム トランザクションであらゆる操作 (Gas 制限を超えない範囲で) を実行できます。とてもクールだと思いませんか？それが真実です。しかし！問題は、トランザクションを実行するにはGasが必要で、Gasはイーサリアムで支払われることですが、新規ユーザーのためにイーサリアムを持っているのは誰でしょうか? (何? サイバーパンク、コイン買い占めパーティー、MLM 組織が存在すると言いましたか? いいですか、それらは普通の人々ではありません)
画像の説明
- 画像出典: この絵文字パッケージは私自身の P: ) -
DeFi、ブロックチェーンゲーム、dAppエコロジーの将来は、市場に参入するプレーヤーの規模に依存します。これは、新規プレイヤーのオンボーディングの問題を解決し、安全な操作のために知識の閾値を下げる必要があることを意味します。現時点での 2 つの主な問題は、プレイヤーが始めるためにデジタル ウォレットとイーサリアムを持っている必要があることです。これは、業界の多くの人々が解決に向けて懸命に取り組んでいることです。
メタトランザクションが登場する前は、上記のサービスを完了するには事前資金調達が必要でした。つまり、トランザクションを容易にするために最初にエンドユーザーのアカウントにイーサを入金する必要がありました。 Uport の Lambda Sensui は、この点における典型的なアプリケーションです。
成し遂げる
メタ トランザクションについて詳しく知りたい場合は、コミュニティのベンチマークである Austin Griffith が執筆した次の記事を参照してください。
イーサリアムのメタトランザクション: イーサリアムの普及への障壁を下げる (編集者注: 中国語訳については記事の最後を参照)
成し遂げる
オンチェーンでメタトランザクションを実装するには、元の送信者によって送信されたトランザクション データをエンコードするためのエンコード標準が必要です。これにより、ターゲット コントラクトは、msg.sender (つまり中継者) の影響を受けることなく署名とデータを回復できます。ただし、オフチェーンのエンドユーザーは、API または通信プロトコルを通じてリレーラーに接続する必要があります。そして、リレーラー自体には、メタトランザクションを取得して転送するためのイーサとインフラストラクチャが必要です。
DaiのERC-20トークンコントラクトで使用されているpermit()メソッドなど、特定のシナリオに非常に適したソリューションは、チェーン上の問題をエレガントに解決します。これは、によって直接送信される必要がある一種の問題です。エンドユーザーの承認方法。さらに、このアプローチは、オンチェーンで使用するメッセージ データを表現および署名するための標準である EIP-712 を実装します。おそらく、Dai がサポートする必要があるのはこの 1 つのメタトランザクションだけであり、他のすべてのユースケース (Dai の送信や DeFi オペレーションの調整など) はこのソリューションを使用して実装できるためです。
コントラクトウォレット
Dapper Labs、Gnosis、Argent などの多くの組織が、ユーザー エクスペリエンスとセキュリティのバランスをとることを目的とした契約ウォレットを立ち上げています。コントラクト ウォレットはスマート コントラクト内のユーザーの資金をホストし、コントラクト内のトランザクションの送信とアカウントのセキュリティの保護の機能は、イーサリアム プロトコル自体のレベルをはるかに超える可能性があります。
画像の説明
- 出典: Dapper Labs -
このアプローチでは、アカウントにイーサがなくてもトランザクションを送信でき、業界が同じ標準を受け入れる必要はありません。コントラクトウォレットは外部所有者のアカウント（つまり、標準キーによって制御される通常のユーザーアドレス）のようにすることができます。ペア、EOA) を使用して他のコントラクトを呼び出します。さらに、Authereum のトランザクション ファイアウォールなどの一連のセキュリティ機能も提供します。
画像の説明
- 出典: オーテリウム -
コントラクトウォレットがもたらすトラブル
コントラクト ウォレットやイーサリアム ネーミング サービス (ENS) などのイノベーションについては、イーサリアム コミュニティ内で多くの話題が広がっています。しかし、多くのユーザーがすべてのオンチェーン アクティビティの ID として ENS ドメインを使用している (また、ドメインの読み取り可能な部分には実名を使用している) ため、プライバシーとセキュリティに関する大きな懸念が生じ始めています。
イーサリアムウォレットのアドレス自体は「擬似匿名」（したがってある程度プライベート）ですが、多くのウォレットソフトウェアプロバイダーは現在、ユーザーにその結果について通知せずにENSアドレスを取得するよう奨励しています。つまり、イーサリアム アカウントの取引記録 (投資ポートフォリオや dApp とのやり取り記録を含む) はチェーン上で公開されており、アドレスが ENS ドメイン名を登録すると、これらの取引活動はこの ENS ドメイン名に関連付けられます。ユーザーが登録した ENS 名は、ユーザーが他のサービスや実生活ですでに使用している名前である可能性があります。これが、ENS を契約ウォレット アドレス (個人使用用) にバインドすることに私が懐疑的な主な理由です。
ただし、私は、スマート コントラクトを識別して不正行為を防止するために ENS を使用するコントラクト ウォレット/マルチシグ ウォレット、および透明性のある運用から恩恵を受ける可能性がある組織に賛成です 🙌
Hierarchical Deterministic Wallet (略称 HD ウォレット) を通じて、ユーザーは 1 つの秘密キーを使用して多数の EOA アドレスを生成し、さまざまな資産を保存できます。ユーザーが dApp および DeFi プロトコルの使用方法を知っている場合でも、複数のアドレスを使用して個別に操作し、開始することができます。多数のトランザクションを処理し、ある程度の匿名性を維持します。この一連のルールを使用すると、ユーザーは秘密キーを 1 つだけ保持し、対話に使用する dApp とトークンごとに EOA アドレスを作成することもできます。コントラクトウォレットでもこれを行うことができますが、ガス料金が存在するため、ユーザーが使用する dApp/トークンごとにコントラクトウォレットを作成するのは非常にコストがかかり、非現実的です。ガス料金を考慮しない場合でも、ネットワークの混雑の原因となります。
画像の説明
- 階層的決定論的ウォレットはそれ自体がプライバシー ソリューションであり、イーサリアム ウォレットにも適用されます。出典: Casa-
イーサリアムエコシステム内のすべてのユーザーが、メタトランザクション機能を使用してプライバシーを保護できるように、対話する各 dApp に対応するコントラクトウォレットを持っていると仮定すると、スマートコントラクトが共通の標準を採用するのがより合理的になります。 。
普遍的な標準を目指して
契約ベースおよび契約ウォレットベースのソリューションに対するスタンスが何であれ、現時点では決定的な標準はありません。メソッド呼び出しは契約ごとに異なり、トランザクションを中継するシステムも異なります。ガソリン スタンド ネットワークは多くの基本的な作業を行ってきましたが、まだ柔軟性が十分ではありません。受取人契約によりガス料金が支払われない場合があります。では、ユーザーは自分の資産をどのようにして中継者に支払うのでしょうか?この取引のガス料金を相手方に支払ってもらうにはどうすればよいですか?これらは、メタトランザクションを一般化する競争において私たちが対処したいと考えている種類の質問です。本当に価値のある提案は、これらの質問に対峙するものです。
私たちが提案したアイデアに基づいて、法務顧問の Vincent は次のアイデアを提案しました: dApp プロジェクトが取引所として特定されるのを避けるために、dApp 開発者がユーザーがガス料金を支払うために資金を事前にデポジットし、ユーザーがそれを法定通貨と交換するというものです。エーテルは dApp 内でのみ使用できます。これは、将来の一般化されたメタトランザクション標準でサポートしたいと考えているメカニズムです (これは、1 年前に別のことに取り組んでいたときに思いついたものです)。ガソリン スタンド ネットワークは、acceptRelayedCall() メソッドのカスタム実装でこのアイデアをサポートしています。
さらに、中継者がトランザクションをバッチ処理できるようにすると、ガス料金も削減されますか?
代替リレーラーの払い戻し/支払い方法をサポートするメカニズムの整備
(コントラクトウォレット標準ではなく) アセット dApps および DeFi のスマートコントラクトでの実行に適した方法
ターゲット コントラクトまたはトランザクションの中継に使用されるコントラクト内でトランザクションのバッチ処理をサポートするメカニズム
ethereum/EIP-1613：Gas Station Network
ethereum/EIP-712
私たちの提案の概要
ご覧のとおり、私たちはガソリン スタンド ネットワークによって提案されたアイデアを強く支持します。 RelayRecipient によって提供される getSender() メソッドと getMessageData() メソッドは統合インターフェイスを実装し、すべてのコントラクトのメタトランザクションに相互互換性を持たせます。ただし、現在の形式では、これらのアプローチには、フィッシング攻撃やリプレイ攻撃から保護できないという 2 つの欠点があります。詳細：
フィッシングを防ぐために、EIP-712 はドメイン名セパレーターという独創的なソリューションを提案しています。このオブジェクトには、契約の詳細 (転送先のトランザクションにユーザーが署名する)、つまりアドレス、dApp の名前とバージョンが含まれます。このデータは署名に含まれており、他のすべてのトランザクション データとともに非常にわかりやすい方法でエンド ユーザーに提示されます。これにより、ユーザーがトランザクションに署名する方法が制限され、予期しないタイプのトランザクション (意図的に間違ったコントラクトにトランザクションを送信するなど) が開始されることが防止されます。
Makerdao/dss：https://github.com/makerdao/
画像の説明
- SignTypedData_v4 メソッドを使用してデータに署名するためのメタマスク インターフェイス。出典: メタマスク -
EIP-712 をサポートする契約では、ドメイン名の区切り文字が契約自体と一致することを確認し、一致しない場合はトランザクションを拒否する必要があります。これは、以下にリストされている Dai コントラクトのコードで確認できます。 EIP-712 を getSender() と getMessageData() に統合して、メソッド呼び出しごとにこのチェックを実行できるようにしたいと考えています。署名が一致しない場合はトランザクションを拒否します。下のリンクをクリックすると、この関数のコードが表示されます。 (記事の埋め込みコードの形式が正しく表示されないため、申し訳ありません)
さらに、上記のコードでは、MakerDAO 自体が nonce 属性を使用してリプレイ保護を実装していることもわかります。この属性がないと、承認された当事者がトランザクションをリプレイしてユーザーの資金を流出させる可能性があります。
メタトランザクションは、以前のトランザクションに依存する可能性のある一連の操作の一部であることがよくあります。たとえば、私たちが構築した概念実証のケースでは、ユーザーは xDai を Compound プロトコルにデポジットできます。メインネットでは、これは cDai コントラクトにユーザー資金へのアクセスを許可し、その後 mint() メソッドを呼び出してその資金を融資プロトコルに入金することを意味します。
ユーザーのアカウントがコントラクトウォレットではない場合、このプロセスを完了するには一連の操作が必要です。まず、トランザクションを通じてapprove()/permit()メソッドを呼び出す必要があり、次にトランザクションの後にmint()メソッドを呼び出す必要があります。トランザクションはパッケージ化されます。コントラクト ウォレットを使用すると、特別なコントラクト メソッドを呼び出すことで、これらのトランザクションをバッチ処理できます。
誰もが利用できる汎用化されたメタトランザクションのバッチ処理方法があれば、それは確かに大きな革新となるでしょう。これにより、上記のさまざまな例と同様に、チェーン上のアクティビティが大幅に簡素化されます。さらに、この方法により、ユーザーは複数の無関係なトランザクションに同時に署名し、転送することができます。
ただし、場合によっては、ユーザーが複数のメタ トランザクションを 1 つのコントラクトに送信したい場合があります。たとえば、資産を 1 つだけ保有する EOA が給与を一括で支払いたい場合です。メタトランザクションをバッチ処理するシステムは、これを念頭に置いて設計し、トランザクションが送信される順序が確実に保持されるようにする必要があります。
さらに、バッチ処理により、中継者はユーザー署名トランザクション、つまりトランザクションのバッチに転送トランザクションを中継者に追加することで料金を集中的に徴収することもでき、その方法もカスタマイズできます。これには、ERC-20 トークンを中継者に転送するか、ユーザーのターゲット契約に料金を支払わせることが考えられます。
リレー アグリゲーターはトランザクションのバッチ処理をサポートし、同じユーザーによる複数のトランザクションを送信するために sendRawTransactionSet() メソッドで sendRawTransaction() を補完する必要があります。 sendRawTransactionSetPlural() メソッドは、ガスコストを最小限に抑えるために、複数のユーザーからのリレーバッチトランザクションを容易にするためにも利用する必要があります。
- 出典: タビー -
要約する
トランザクション セット内のトランザクションによって資金提供できる場合、リレー アグリゲーターの現在のワークフローに少し変更を加えるだけで実現できます。リレーラーは、gasPrice を渡すことができ、料金パラメーター acceptRelayCall() は 0 に設定されます。リレーラーはトランザクション セットからトランザクションを継続的に抽出し、完了するまで標準に従って処理できます。
私たちが直面している本当の課題は、トランザクションをトランザクション セットにパッケージ化し、(トランザクションのアトミック性を確保しながら) トランザクションをアンパックして実行するための標準を作成する方法です。トランザクションのアトミック性が保証できない場合、中継者はセット内の他のトランザクションを無視して、有料トランザクションのみを転送することで問題を回避できます。それが本当の仕事なのです！現時点ではやり方が分かりませんが、次回の投稿を楽しみにしていてください。これを競争のための実行可能なソリューションに変えることができれば幸いです。
要約する
