はじめに

初めまして。
CryptoGamesというブロックチェーンゲーム企業でエンジニアをしている cardene（かるでね） です！
スマートコントラクトを書いたり、フロントエンド・バックエンド・インフラと幅広く触れています。

代表的なゲームはクリプトスペルズというブロックチェーンゲームです。

今回は、ユーザー認証とスマートコントラクト関数への安全なアクセスを実現する仕組みである、Ethereum Access Token（EAT）を提案しているERC7272についてまとめていきます！

以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。

他にも様々なEIPについてまとめています。

概要

Ethereum Access Token（EAT）についての提案です。

EATは、Ethereumプラットフォーム上でアカウントが特定のオンチェーンリソースにアクセスできるようにするための署名付きメッセージです。

EATはEIP712というEthereumの提案に準拠しています。
EIP712は、Ethereum上でより安全かつユーザーフレンドリーな署名メッセージの標準を提供することを目的としています。
これにより、メッセージの署名と検証がより透明で信頼性の高い方法で行われます。

ERC712については以下の記事を参考にしてください。

JSON Web Tokens（JWTs）と比較して、EATも短期間の認証に使われます。
JWTはWebアプリケーションで広く使われている認証トークンで、ユーザーがサービスにログインしていることを確認するのに役立ちます。
しかし、EATは特にEthereumのブロックチェーン上で検証され、スマートコントラクトの関数呼び出しを承認するためにデザインされています。

JWT

JSON Web Tokens（JWT、ジェイダブリューティー）は、インターネット上で二者間の情報を安全に伝達するためのコンパクトで自己完結型の方法です。
JWTは、JSONオブジェクトを用いて、エンティティ間で伝達する情報（クレーム）を構造化します。
この情報はデジタル署名されているため、検証後に信頼性が確保されます。
JWTは主に認証や情報交換に使用されます。

JWTの構成要素

JWTは以下の三つの部分から成り立っています。

ヘッダー（Header）
ペイロード（Payload）
署名（Signature）
ヘッダー
- ヘッダーは、トークンのタイプ（JWT）と署名や暗号化に使われるアルゴリズム（例えば、HMAC SHA256やRSA）を宣言するJSONです。
ペイロード
- ペイロード部分には、トークンに関するクレーム（主張）が含まれます。
- これには、トークンの発行者、有効期限、ユーザーIDなど、トークンが伝えるべき具体的な情報が含まれます。
- クレームは名前/値のペアで構成され、必要に応じて追加できます。
署名
- 署名は、ヘッダーとペイロードを合わせたものを指定されたアルゴリズムで暗号化することで生成されます。
- 署名によって、トークンが途中で改ざんされていないことを検証することができます。

使用方法

JWTは、認証の時にサーバーからクライアントに発行されます。
クライアントはその後のリクエストでこのトークンをサーバーに送り返すことで、自身が認証済みであることを示します。
サーバーはトークンの署名を検証し、ペイロードからユーザーの情報を読み取ることができます。
これにより、毎回ユーザー名とパスワードを送信する必要がなく、セキュアな認証が可能になります。

利点

自己完結型
- JWTは必要なすべての情報を自身内に持っているため、データベースへの問い合わせを減らしてパフォーマンスを向上させることができます。
拡張性
- JWTはHTTPヘッダーに簡単に含めることができ、クロスオリジンリソース共有（CORS）の制約を受けることなく、異なるドメイン間で安全に情報を伝達することができます。
セキュリティ
- デジタル署名により、トークンが改ざんされていないことを確認できます。

注意点

セキュリティには注意が必要で、特にJWTはデコード可能なため、機密情報をペイロードに含める場合は暗号化するなどの対策が必要です。
また、有効期限の管理やトークンの取り扱いにも注意が必要です。

EATはEthereumのブロックチェーン上で特定の操作やリソースへのアクセス権を付与するための「鍵」のようなものです。
これにより、オフチェーンサービス（ブロックチェーン外のサービス）がEthereumアカウントに対して、特定のスマートコントラクト機能へのアクセス権を与えることができます。
EATの使用により、セキュリティが強化され、透明性と効率性が向上します。

動機

Ethereum Access Token（EAT）がどのようにEthereumエコシステムの認証と承認の問題を解決するか、またそれが他のアクセス制御メカニズムとどう異なるかについての説明です。
具体的には、EATはスマートコントラクトの機能にアクセス制御層を追加するための柔軟な方法を提供し、特定の使用例に特化しています。

EATの利点と使用例

短期間のアクセス制御
- EATは短命で、特定のトランザクションまたはアクションにのみ使用されます。
- これは、永続的なアクセス権限ではなく、一時的な権限付与に適しています。
柔軟性と動的な条件
- アクセス条件を変更する場合、ブロックチェーン上のコードを更新する必要はありません。
- この柔軟性は、アクセス要件が頻繁に変更される可能性があるシナリオに特に有用です。
オンチェーントークンの代替
- 特定の条件下でのアクセス権を提供するためにオンチェーンのレジストリやトークンを使用する代わりに、EATを利用することができます。
- これにより、レジストリの所有者が情報を常に最新の状態に保つ必要がなくなり、プライバシーに関する懸念も軽減されます。
プライバシーの保護
- Ethereumのような公開ブロックチェーンでは、データが公にアクセス可能であるため、個人情報を直接保存してアクセス制御に利用することは推奨されません。
- EATは、ブロックチェーン上で個人情報を露出させることなく、オフチェーンでの検証後にアクセス権を付与する手段を提供します。

使用例

資格の検証
- オフチェーンの検証者が、特定のトークンを発行するための資格要件を評価する場合（例えば、検証可能な資格を検証する）や、特定のコンプライアンスステータスが必要なスマートコントラクトとのやり取りを行う場合などです。

この仕様は、Ethereumエコシステムにおける相互運用性を改善し、一貫性のあるメッセージフォーマットを通じてユーザーエクスペリエンスを向上させることを目指しています。
EATは、既存の標準アクセス制御メカニズムとは異なるアクセス制御要件を持つシナリオにおいて、特に有用なソリューションを提供します。

仕様

以下はDeFi（分散型金融）アプリケーションにおけるEthereum Access Token（EAT）の利用フローの例です。
このプロセスは、ユーザーがオフチェーンサービスとやり取りし、特定の条件を満たした後、スマートコントラクトの特定の機能にアクセスできるようになるまでの一連の手順を説明しています。

引用: https://eips.ethereum.org/EIPS/eip-7272

フローの概要

ユーザーの認証
- ユーザーは、DeFiのオフチェーンサービスとやり取りします。
- この時、ユーザーは自身がサービスの基準を満たしていることを示すために、十分な情報（例えば、認証情報）を提供する必要があります。
EATの発行
- EATに署名をしたユーザーには、EATが発行されます。
- このトークンは、ユーザーが特定のスマートコントラクト機能にアクセスするための「鍵」となります。
スマートコントラクトとのやり取り
- ユーザーは、EATをトランザクションの一部として使用し、許可された時間内にゲート付きスマートコントラクト機能とやり取りします。
EATの検証
- トランザクションがブロックチェーン上で実行される時、EATはオンチェーンで検証されます。

EATによる細かいアクセス制御

EATを使ったアクセス制御では、以下の点が保証されなければなりません。

関数呼び出しの正確性
- 呼び出される関数は、期待されたものでなければなりません。
パラメータの正確性
- 関数のパラメータは、期待されたものである必要があります。
呼び出し元の正確性
- 関数を呼び出すユーザーは、期待されたものである必要があります。
認証された時間枠内での実行
- EATが有効期限内であることを確認する必要があります。
呼び出されるスマートコントラクトの正確性
- 呼び出されるスマートコントラクトは、期待されたものである必要があります。
有効な発行者による認証
- EATは、期待された発行者の一人によって署名されている必要があります。

このプロセスを通じて、DeFiアプリケーションはユーザーが特定の操作を行うための正確な認証と承認を確実に行うことができます。
EATは、特定の操作やリソースへのアクセスを細かく制御するための強力なツールです。

Ethereum Access Tokenの構造

Ethereum Access Token（EAT）の構造について説明します。
EATは、Ethereumのスマートコントラクトや機能へのアクセス権を証明するためのトークンで、特定の条件下でその権限を利用することができます。
このトークンは、特にEIP-712規格を用いて構造化されたデータのハッシュ化と署名によって生成されます。

EATの主な構成要素

{
 uint8 v,
 bytes32 r,
 bytes32 s,
 uint256 expiry
}

署名
- 署名は、v、r、sの3つのコンポーネントで構成されます。
- これらはEIP712を用いて構造化されたデータを署名する時に得られるもので、EATが正当に発行され、改ざんされていないことを保証します。
有効期限(expiry)
- これは、UNIXタイムスタンプ形式で表され、EATが使用されるべき期限を示します。
- このタイムスタンプは、ブロックチェーンの現在のタイムスタンプ(block.timestamp)よりも前である必要があります。

EATペイロードの構造

struct AccessToken {
    uint256 expiry;
    FunctionCall functionCall;
}

struct FunctionCall {
    bytes4 functionSignature;
    address target;
    address caller;
    bytes parameters;
}

EATのペイロードは、AccessTokenとFunctionCallの2つの構造体で構成されます。

AccessToken

これには、EATの有効期限(expiry)と、関数呼び出しの情報を含むFunctionCall構造体が含まれます。

FunctionCall

この構造体には、以下の情報が含まれます。

functionSignature
- 呼び出される関数の識別子です。
- これはmsg.sigと一致することが期待されます。
target
- 呼び出されるターゲットコントラクトのアドレスです。
caller
- 現在の呼び出し元のアドレスで、msg.senderと一致することが期待されます。
parameters
- 関数呼び出しに使用されるパラメータです。署名（v、r、s）と有効期限(expiry)を除いたものです。

EATは、EIP712を使用して安全に署名された構造化データです。
これにより、Ethereumブロックチェーン上で特定の関数呼び出しを行う権限が付与されます。
EATは、関数の種類、ターゲットコントラクト、呼び出し元、およびパラメーターを厳密に指定することで、非常に詳細なアクセス制御を実現します。
有効期限は、トークンが短期間でのみ使用されることを保証し、セキュリティを向上させます。

EAT検証

Ethereum Access Token（EAT）の構造と検証プロセスについて説明します。

EATの構造

EATは以下のコンポーネントから成り立っています。

署名
- 署名は、v、r、sという3つの部分から構成されます。
- これらはEIP712、つまり型付き構造化データのハッシュ化および署名標準を使用して取得されます。
- EIP712は、Ethereumでより安全で理解しやすいメッセージ署名を可能にします。
有効期限
- expiryは、トークンの有効期限を示すUNIXタイムスタンプです。
- これは、ブロックのタイムスタンプより前であることが期待されます。

EATペイロードには、有効期限と呼び出される関数に関する情報が含まれています。
具体的には、関数の署名（functionSignature）、ターゲットコントラクトのアドレス（target）、呼び出し元のアドレス（caller）、およびパラメータ（parameters）です。

EATの検証プロセス

オンチェーンでは、EATの検証はAccessTokenConsumerとAccessTokenVerifierの二つのスマートコントラクトによって行われます。

AccessTokenConsumer
- これは、その関数の一部を許可する必要があるコントラクトに継承されます。
- つまり、アクセス制御を必要とするスマートコントラクトは、このコントラクトを使用してEATのチェックを行うことができます。
AccessTokenVerifier
- EATの完整性を検証する責任があります。verify()関数は、署名とAccessTokenを入力として受け取り、トークンが有効期限切れでないこと、署名から署名者を復元できること、そして署名者が有効かつ期待された署名者であることを確認します。

このプロセスにより、スマートコントラクトは、関数を安全に実行する前に、EATが有効かつ適切に署名されていることを確認できます。
EATの検証は、ブロックチェーン上での信頼性の高いアクセス制御を可能にし、特定の関数へのアクセスを適切に制限します。

補足

Ethereum Access Tokens（EAT）の特定の設計選択とそれらがもたらす利点および欠点について説明しています。

一回限りの使用

参照実装は、EATが再利用できないこと（ノンリプレイ性）を保証しています。
これは、一度使用されたトークンが再び使われることを防ぐためです。
しかし、他の実装では異なるアプローチを取るかもしれません。
これはセキュリティ面で重要な特徴であり、トークンの悪用を防ぐために役立ちます。

EIP-712の使用

EATがEIP712に準拠していることにより、既存のEthereumインフラとの互換性が確保されます。
これにより、開発者は既存のコードに最小限の変更を加えてアクセス制御を作成できます。
EIP712は、メッセージの署名と検証をより安全かつ理解しやすくすることを目的としたEthereumの改善提案です。
また、EATが特定のチェーンに紐付けられていることを保証します。

ゼロ知識証明の使用

ゼロ知識証明（ZKP）は、ある情報を他者に伝えることなく、その情報が真実であることを証明する技術です。
ZKPの使用は、複雑性の追加といったコストを伴います。
一方で、EATは署名されたメッセージとしてはるかに単純で、理解しやすいです。
Ethereumのスマートコントラクトではecrecover関数が標準で提供されており、これを用いて署名の検証が簡単に行えます。
しかし、ZKPはさまざまな形式があり、それぞれに異なる実装が必要であるため、互換性に課題をもたらします。

EATは再利用不可、EIP712準拠、およびゼロ知識証明を使用しないという設計選択を通じて、セキュリティ、互換性、およびシンプルさのバランスを提供します。
これにより、Ethereum上でのアクセス制御を効果的かつ効率的に実装することが可能になります。

互換性

Ethereum Access Token（EAT）を使用して、特定のスマートコントラクト関数へのアクセスを制限（ゲート化）することができますが、「receive」関数と「fallback」関数を除くすべての関数に対してこれが可能です。

ゲート化された関数
- 「ゲート化」とは、関数が特定の条件（この場合は適切なEATの提出）を満たしたときにのみ実行されるようにすることです。
- EATを用いることで、スマートコントラクトの特定の機能へのアクセスを制限し、認証されたユーザーのみがその機能を利用できるようにします。
「receive」と「fallback」
- Ethereumスマートコントラクトには、receive関数とfallback関数という特別な関数があります。
- これらはコントラクトがイーサリアムを受け取った時に自動的に呼び出される関数で、直接的なアクセス制御を目的としたものではありません。
- receive関数は、コントラクトが純粋にイーサリアムを受け取る（データなしで送信されるトランザクション）ときに呼び出されます。
- fallback関数は、コントラクトが関数の呼び出しやイーサリアムの受け取り（データ付き）を行ったが、どの関数にもマッチしなかった場合に呼び出されます。

これらの関数は、イーサリアムの受け取りといった基本的な操作を管理するために特別に設計されているため、EATによるアクセス制御の対象外とされています。
そのため、これらを除くすべてのスマートコントラクト関数に対して、EATを用いたアクセス制御を適用することができます。
これにより、開発者はスマートコントラクトのセキュリティと柔軟性を高めることが可能になります。

実装

セキュリティ

Ethereum Access Token（EAT）の提案のセキュリティは、いくつかの要因に依存します。
これらの要因を理解することで、EATがどのように安全に設計されているか、そしてどのようなリスクが存在するのかを理解することができます。

リプレイ攻撃

リプレイ攻撃とは、悪意のあるアクターが以前に行われた有効なトランザクションを再び利用（再生）する攻撃です。
EATの実装では、トークンが一度使用された後に再利用できないようにすることで、このタイプの攻撃を防ぐことができます。
これは、_consumeAccessToken関数でEATを「使用済み」としてマークすることで達成されます。

リプレイ攻撃については以下の記事を参考にしてください。

オフチェーン発行のセキュリティ

EATを発行するオフチェーンサービスのセキュリティは非常に重要です。
EATによって保護されるオンチェーンリソースへのアクセスは、このサービスが発行するトークンに依存しています。
もしオフチェーンサービスがハッキングされると、不正なアクターが本来アクセスすべきでないオンチェーンリソースへのアクセス権を得る可能性があります。

有効期限の考慮

EATの有効期限は、使用のしやすさとセキュリティのバランスを考慮して慎重に設定する必要があります。
有効期限が長すぎると、EATの不正使用のリスクが高まる可能性があります。
逆に、有効期限が短すぎると、アプリケーションの使用性が損なわれる可能性があります。

これらの要素は、EATを利用する際に考慮すべき重要なセキュリティ面です。
適切な実装と管理により、EATを安全かつ効果的に利用することが可能になります。

引用

Chris Chung (@0xpApaSmURf), Raphael Roullet (@ra-phael), "ERC-7272: Ethereum Access Token [DRAFT]," Ethereum Improvement Proposals, no. 7272, July 2023. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7272.

最後に

今回は「ユーザー認証とスマートコントラクト関数への安全なアクセスを実現する仕組みである、Ethereum Access Token（EAT）を提案しているERC7272」についてまとめてきました！
いかがだったでしょうか？

質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！

Twitter @cardene777

他の媒体でも情報発信しているのでぜひ他も見ていってください！

[ERC7272] 新しいアクセス制御の方法であるEthereum Access Token（EAT）の仕組みを理解しよう！