Ethereum EIP-3074の簡単な分析: 一般ユーザーはETHなしでも信頼なくトランザクションを送信できる

元のタイトル: 「はじめに | EIP-3074 の紹介」
著者: lightclients
翻訳・校正：ミンミン＆ア・ジアン

イーサリアムウォレットは近々大幅なアップグレードを受けるかもしれない。アップグレードが完了すると、通常のアカウント (EOA) はバッチ トランザクション、期限トランザクション、順序なしトランザクションなどを送信できるようになります。

私の 2 人の同僚 @SamWilsn と @adietrichs と私は、Ethereum のインタラクティブなエクスペリエンスを改善する方法に取り組んでいます。数回の反復を経て、EIP 3074: オペコード AUTH および AUTHCALL が完成しました。

これら 2 つのオペコードを使用するには、外部アカウントがオフチェーンでメッセージに署名し、そのメッセージをリレーに送信する必要があります。リレーは、署名と呼び出しデータをオンチェーン コントラクト (「呼び出し元」と呼ばれる) に送信します。呼び出し元のコントラクトは、最初にオペコード AUTH を使用して署名を検証し、次にオペコード AUTHCALL を使用して呼び出しを外部アカウントに中継します。

AUTHCALL が通常の呼び出しと異なる点は 1 つだけです。AUTHCALL は、呼び出し元 (つまり、メッセージの送信者) を、オペコード AUTH で復元された外部アドレスに設定します。これにより、ユーザーは Ether を使用せずに Ethereum と対話できるようになります。言い換えれば、その取引はリレー業者によって「後援」されているのです。

このメカニズムはおなじみかもしれません。実際、メタトランザクションはほぼこのように動作します。ただし、ここで強調しておきたいのは、メタトランザクションではメッセージの送信者を任意に設定することはできないということです。したがって、契約はメタトランザクションを明示的にサポートする必要があります。 EIP 3074 は、メタトランザクションを排除し、契約の複雑さを軽減することを目的としています。

これがどのように機能するかを詳しく説明する前に、まず何を構築したいのかを説明しましょう。私たちは、一般ユーザーが Ether を使用せずに信頼のない方法でトランザクションを送信できるメカニズムを構築したいと考えています。ここでのキーワードは「トラストレス」です。つまり、ユーザーはリレーヤーに悪用される可能性のある権限を付与しません。

EIP 3074 は、通常のアカウント署名に含まれるパラメータを慎重に選択することで、信頼できないシステムを作成します。ユーザーは keccak (0x03++invoker_address++commit_hash) に署名します。

「type byte」は、値が 0x03 である EIP 2718 の定数バイトです。このバイトの目的は、EIP 2930 のアクセス リスト トランザクション、EIP 1559 の手数料市場トランザクション、EIP 191 の 0x19 署名メッセージなどの他の署名メカニズムとの競合を回避することです。

発信者アドレスは、ユーザーの通話を特定の契約にバインドします。ユーザーの署名は、発信者の契約に対してのみ有効です。したがって、ユーザーは、資産を保管するためのスマート コントラクト ウォレットを選択するのと同じように、信頼できる発信者を選択できます。

呼び出し元のコントラクトの実装が正しくない場合、ユーザーが損失を被る可能性があるため、呼び出し元の数は少数であると予想されます (呼び出し元はオプトインであることに注意してください)。安全な発信者契約の開発には多大なコストがかかり、複数当事者による監査と静的証明が必要になります。

しかし、これは今日の慣行とそれほど変わりません。スマート コントラクト ウォレットも、多額の資金を保管する前に、完全に監査および証明される必要があります。多くの大規模 DeFi プロジェクトでも同様です。

最後の署名パラメータは commit_hash (または単に commit) です。これにより、発信者の設計者の柔軟性が向上し、さまざまなソリューションを開発できるようになります。

このコミットは、呼び出し元を特定の操作に制限し、呼び出しを処理するための特定の有効性要件を作成します。ユーザーは、オンチェーンでコードを検証できるため、呼び出し元がこのプロセスに従うことを信頼できます。これがブロックチェーンの美しさです。

簡単なケースを見てみましょう。ユーザーは発信者を通じて通話を送信したいと考えています。呼び出しが無限に中継されるのを防ぐには、他の不変の値とともに nonce を提供する必要があります。ユーザーはこれらの値をハッシュしてコミットを作成し、オペコード AUTH を使用してコントラクトが検証できるように、署名済みメッセージにコミットを含めます。

呼び出し元は渡された値を使用してコミット ハッシュを再生成します。このように、スポンサーが値の 1 つを変更すると、呼び出し元によって計算されたコミット ハッシュは外部アカウントによって署名されたコミット ハッシュとはまったく異なるものになり、次の図に示すように、AUTH によってガベージ アドレスが復元されます。

これで、呼び出し側が通常のアカウントで使用できるスマート コントラクト ウォレットと同じものであることがご理解いただけたと思います。ここで、コミットを使用してより興味深いシナリオを構築する方法を見てみましょう。

一般的に言えば、「1 つの操作は 1 つの署名に対応する」というのが経験則になっています。これは比較的単純な理解です。署名はトランザクションのハッシュ値に基づいて作成されますが、ハッシュ計算のために複数のトランザクションを結合しないのはなぜですか? EIP 3074 はまさにそれを実現できることがわかりました。

アカウントが AUTH 検証に合格できる限り、発信者はアカウントの要求に応じて任意の数の AUTHCALL を実行できます。呼び出し元がコードを正直に実行すると信頼しているので、これは問題ありません。複数の呼び出しをマージし、それらをコミットにハッシュするスキームを設計できます。

上の図に示すスキームでは、呼び出し元はすべての値 (nonce1、nonce2 など) を組み合わせてハッシュし、コミットを生成します。呼び出し元はこのコミットとユーザー署名を使用して AUTH を呼び出します。 AUTH は、ユーザーが実際にパラメータに署名したことを確認します。

次に、呼び出し元は各呼び出しを反復処理し、認証された呼び出しデータを許可されたアドレスに送信する前に、nonce とその他のパラメータを検証します。

これに基づいて、さらに多くのソリューションを構築できます。たとえば、新しいパラメータ「Shelf Life」を追加するとします。このパラメータは他のパラメータと一緒にハッシュされ、コミットされます。さらに、検証中に、呼び出し元は有効期限 < block.number であることを確認します。外部アカウントでも期間限定取引が可能になりました！