# [ERC7617] 大容量データを小分けにして取得ができる仕組みを理解しよう！

> この規格は、ERC6860のweb3URL標準の文脈において、ERC6944のresolveモードを拡張する仕組みを提案しています。

- URL: https://cardene.dev/articles/e834423ba74beecb433b
- 公開日: 2024-06-28
- 更新日: 2024-06-28
- トピック: Blockchain
- タグ: ethereum, solidity, smartcontract, ブロックチェーン

## はじめに

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

https://cryptogames.co.jp/

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

https://cryptospells.jp/

今回は、**ERC5219**を拡張して、複数のチャンクで構成されたWeb3URLリソースを取得する仕組みを提案している**ERC7617**についてまとめていきます！

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

https://eips.ethereum.org/EIPS/eip-7617

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

https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4

## 概要

この規格は、**ERC6860**のweb3URL標準の文脈において、**ERC6944**のresolveモードを拡張する仕組みを提案しています。

:::message
**ERC6860**については以下の記事を参考にしてください。
:::

[\[ERC6860\] HTTPスタイルのWeb3URLを使用してオンチェーンコンテンツにアクセスする仕組みを理解しよう！](/articles/30bdd75be892cf776b88)

:::message
**ERC6944**については以下の記事を参考にしてください。
:::

[\[ERC6944\] コントラクトが特定のリソース要求をどのようの処理するか指定するための仕組みを理解しよう！](/articles/c8f906536dcb7fe7492d)

具体的には、**web3-next-chunk**という新しいオプションのHTTPヘッダーが導入され、このヘッダーには次のデータチャンクを指すweb3URLが含まれます。
レスポンスを返すときに、次のデータチャンクのURLを含めることで、呼び出し元が指定されたURLにアクセスしてデータを取得することができます。
この処理を**web3-next-chunk**ヘッダーが存在する限り繰り返すことで、大量のデータを一度に送らずにチャンクごとに分割して取得することができます。

例えば、大きなファイルをダウンロードする時、呼び出し元は初回の`request()`呼び出しを行い、最初のチャンクとともに**web3-next-chunk**ヘッダーを返します。
呼び出し元はこのヘッダーのURLにアクセスし、次のチャンクを取得するプロセスを繰り返します。
このようにすると、特にオンチェーンにおいては一度に返せるデータに制限があるため便利です。

:::message
**ERC6944**は、**ERC5219**を拡張していて、`request()`メソッドの呼び出しは**ERC5219**に関連する部分です。
:::

:::message
**ERC5219**については以下の記事を参考にしてください。
:::

[\[ERC5219\] GETリクエストのみの効率的なDapp通信の仕組みを理解しよう！](/articles/a96196b201a34e6eb640)

## 動機

Ethereum RPCエンドポイントにはガスコストの制限があり、大容量のコンテンツを提供するときに制限に達してしまう可能性があります。
この規格で提案されているチャンク機能を実装することで、大容量のデータを小分けにした任意のサイズのコンテンツを提供できるようになります。

:::message
フルオンチェーンなどで特に活用できそうです。
:::

## 仕様

この規格を使用することで、**ERC6944**のresolveモードを拡張して、`request()`メソッドで返される`headers`と`KeyValue`配列に新しいオプションのHTTPヘッダーである**web3-next-chunk**が追加されます。
**web3-next-chunk**の値は、完全なweb3URLか相対URLのcどちらかで、呼び出すコントラクトは**ERC6944**を実装している必要があります。

最初の`request()`呼び出しでデータをリクエストすると、HTTPステータスコード、HTTPヘッダー、bodyを返します。
もし**web3-next-chunk**ヘッダーが存在する場合、まずはURLを無効か有効か検証します。
呼び出すこんとらくとが**ERC6944**を実装していない場合などはエラーを出して処理を終了させます。
有効の場合は、返された`statusCode`を無視して**ERC6944**のresolveモードを使用して再度`request()`メソッドを呼び出します。
**web3-next-chunk**ヘッダーが存在しなくなるまでこの処理を繰り返します。
これにより、大量のデータを小さなチャンクに分割して小分け実行ができて効率的なデータ転送が可能になります。

## 補足

次のチャンクの場所をしているするデータの保管場所としてヘッダーが選ばれたのは、**ERC6944**の`request()`インターフェースを変更する必要がなく、ヘッダーにweb3URLを追加するだけで良いからです。
これにより、柔軟に次のチャンクの情報を提供できます。

## 引用

Qi Zhou (@qizhou), Nicolas Deschildre (@nand2), "ERC-7617: Chunk support for ERC-5219 mode in Web3 URL [DRAFT]," Ethereum Improvement Proposals, no. 7617, February 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7617.

## 最後に

今回は「**ERC5219**を拡張して、複数のチャンクで構成されたWeb3URLリソースを取得する仕組みを提案している**ERC7617**」についてまとめてきました！
いかがだったでしょうか？

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

[Twitter @cardene777](https://twitter.com/cardene777)

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

https://chaldene.net/

https://zenn.dev/heku

https://cardene.substack.com/

https://mirror.xyz/0xcE77b9fCd390847627c84359fC1Bc02fC78f0e58

https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4