はじめに
初めまして。 CryptoGamesというブロックチェーンゲーム企業でエンジニアをしている cardene（かるでね） です！ スマートコントラクトを書いたり、フロントエンド・バックエンド・インフラと幅広く触れています。
代表的なゲームはクリプトスペルズというブロックチェーンゲームです。
今回は、ERC5219のresolveモードで、圧縮されたリソースをクライアントに渡す前にデコードする仕組みを提案しているERC7618についてまとめていきます！
以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。
他にも様々なEIPについてまとめています。
概要
この規格は、ERC6860のweb3URL標準の文脈において、ERC6944のresolveモードを拡張する仕組みを提案しています。
ERC6860については以下の記事を参考にしてください。
ERC6944については以下の記事を参考にしてください。
request()呼び出しによって、Content-Encodingヘッダーが返された場合に、返されたデータがクライアントに返される前に指定されたアルゴリズムに従ってデコードすることを提案しています。
この規格は以下のERC7617と似ているので、合わせて読むと理解が深まるかもしれないです。
動機
ブロックチェーンにおいてストレージは高価であるため、データを圧縮して保存・提供することが最適です。
「ストレージが高価」とは以下のようなことを意味しています。
トランザクションコスト
ブロックチェーンにデータを書き込む時、各トランザクションごとにガス代がかかります。 ガス代はデータの量やネットワークの混雑状況に応じて変動しますが、大量のデータを保存する場合は高額になります。
ストレージ書き込み制限
ストレージにデータを書き込むとき、大量のデータを一度に書き込むことができずエラーになってしまいます。
標準HTTPでは、クライアントがサポートしている圧縮アルゴリズムのリストをサーバー側に渡し、その中から1つのメカニズムで圧縮されたデータを返す、Accept-Encoding/Content-Encodingメカニズムが使用されます。 正し、web3://プロトコルにそのまま適用することは、ブロックチェーンのストレージと計算の制約により最適ではないです。 また、固定のContent-Encodingヘッダを使用してコンテンツを提供することは、HTTPクライアントがその圧縮アルゴリズムをサポートしていない可能性があるためできないです。
この問題を解決するために以下のアプローチが提案されています。
- 対応圧縮アルゴリズムのリストの指定
- クライアントがサポートしている圧縮アルゴリズムのリストをプロトコル側で指定。
- プロトコル側での解凍
- 圧縮されたデータをプロトコル側で解凍しクライアントに提供。
このアプローチにより、圧縮データを安全に保存してクライアントが対応する形で提供することができます。
仕様
ERC6944は、web3://プロトコルにおけるコンテンツ圧縮と解凍に関する標準を定めています。
Content-Encodingの検査とデコード
クライアントが送信したリクエストにAccept-Encodingヘッダーが含まれていないか、またはContent-Encodingヘッダーに指定された圧縮アルゴリズムがクライアントのAccept-Encodingヘッダーに含まれていない場合、プロトコルはコンテンツをデコードしてからクライアントに転送します。 プロトコルでは以下の圧縮アルゴリズムをサポートします。
- gzip
- br (brotli)
非対応の圧縮アルゴリズムの処理
コンテンツのContent-Encodingヘッダーに指定された圧縮アルゴリズムが、プロトコルのサポートリストに含まれていない場合、プロトコルは「サポートされていないコンテンツエンコーディング」を示すエラーをクライアントに送信しなければなりません。
デコード後のデータ送信
コンテンツがデコードされた後、解凍されたデータをクライアントに送信します。 このとき、送られたContent-Encodingヘッダーを含めてクライアントに送信してはいけません。
実際の処理フロー
-
クライアントからのリクエスト受信
- クライアントがweb3://プロトコルを使ってリクエストを送信。
- このリクエストにAccept-Encodingヘッダーが含まれている場合、そのヘッダー内の圧縮アルゴリズムが指定されています。
-
サーバからのレスポンス受信
- サーバがレスポンスを返し、このレスポンスにContent-Encodingヘッダーが含まれている場合、そのデータが特定の圧縮アルゴリズムで圧縮されています。
-
プロトコルによるデコード
- プロトコルはレスポンスのContent-Encodingヘッダーをチェックします。
- クライアントのAccept-Encodingヘッダーと照合し、サポートされていない場合やAccept-Encodingヘッダーが無い場合、プロトコルはデータをデコードします。
-
エラーハンドリング
- デコードが必要な場合、指定された圧縮アルゴリズムがgzipまたはbrでない場合、プロトコルはエラーをクライアントに返します。
-
クライアントへのデータ送信
- デコード後、Content-Encodingヘッダーを除去したデータをクライアントに送信します。
補足
この機能はインターフェースを変更せずに追加できるため、ERC6944resolveモードに追加しました。
標準HTTPにできるだけ近づけるため、新しいHTTPヘッダーを導入するのではなく既存のContent-Encodingヘッダーを利用しています。
引用
Qi Zhou (@qizhou), Nicolas Deschildre (@nand2), "ERC-7618: Content encoding in ERC-5219 mode Web3 URL [DRAFT]," Ethereum Improvement Proposals, no. 7618, February 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7618.
最後に
今回は「ERC5219のresolveモードで、圧縮されたリソースをクライアントに渡す前にデコードする仕組みを提案しているERC7618」についてまとめてきました！ いかがだったでしょうか？
質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！
他の媒体でも情報発信しているのでぜひ他も見ていってください！
