DEIM Forum 2023 4a-8

IPFS におけるデジタルアート流通のための最適化機構
吉川 綾乃†

松原 克弥†† 公立はこだて未来大学 〒 041–8655 北海道函館市亀田中野町 116 番地 2
E-mail: †{g2121060,matsu}@fun.ac.jp
あらまし デジタルアートの安全なオンライン流通を可能にした NFT マーケットの多くは，作品データをオフチェー
ン上で保管するために，IPFS を採用している．主要なデジタルアートのひとつである，写真やイラストなどのデジタル画像は，使用用途に合わせて，高さや幅，フォーマット形式などに対する様々な加工が施されることが多い．しかし，コンテンツ指向アドレッシングを採用する IPFS では，これらの加工された派生画像がオリジナルとは異なるデータとして管理されるため，派生画像の再活用が難しい．その結果，同じ加工処理を何度も繰り返したり，多数の派生画像がストレージ容量を圧迫したりする不具合が発生する．本研究では，動的画像変換と派生画像の効率的な検索機構を IPFS へ実装し，派生画像の再活用を可能にする．また．構築した IPFS システムを用いた実験の結果から，
本提案機構が画像処理のオーバーヘッドを削減できることを示す．

1 はじめに
1. 1 デジタルアートの流通[USドル]

キーワード 画像処理，ストレージ管理，NFT，IPFS
100,000,000,000
17,694,851,721
10,000,000,000

近年，デジタルアートなどのデジタルコンテンツを安全に流通するための仕組みとして，Non-Fungible Token（以下，1,000,000,000

NFT）が活用されている．NFT を活用しているマーケットの例
として，OpenSea 1 や Magic Eden 2 ，LooksRare 3 などがある．

82,492,916

100,000,000

NonFungible が行った調査 [1] によると，NFT を利用して 1 年

24,532,783

間でやり取りされている金額（US ドル）は，図 1 のようにな
10,000,000

る．2019 年では，約 2400 万ドル，2020 年では，約 8200 万ド

2019

ル，2021 年には約 170 億ドルであり，ここ数年で急成長して

2020

2021

[年]

いることがわかる．
図 1 NFT でやり取りされた金額

NFT は，ブロックチェーンをベースとした暗号資産で，同じトークンは存在せず，それぞれのトークンを識別するのに適しているという特徴がある [2]．そのため，NFT では，イラスツの管理にコンテンツ指 S 向アドレッシングという方法を用い

トやアート作品，写真などのデジタル画像の他，音楽作品や，ている．従来のファイルシステムや HTTP プロトコルの様に，

ゲームアイテム，イベントチケットなどがやり取りされている．

ファイルが保存されている場所にもとづいてアクセスするロ

ブロックチェーンは，ブロックサイズが大きくなるとコンセ

ケーション指向アドレッシングとは異なり，コンテンツのデー

ンサスにかかる時間が長くなるという特徴がある．加えて，デタにもとづいた ID でアクセスする．この ID は，コンテンツ

ジタル画像はファイルサイズが大きくなりやすい．この課題をID（以下，CID）と呼ばれている．

回避するため，いくつかの主要な NFT マーケットでは，コンテ

CID はデータにもとづいて生成されるため，コンテンツのンツのメタデータやスマートコントラクトのみをチェーン上にデータが変更されると CID も変化するという特徴がある．こ

保存し，コンテンツはオフチェーンに保存している．このコンテれにより，IPFS はコンテンツが改ざんされたかどうかを検証

ンツを保存する外部ストレージの 1 つとして，InterPlanetary

することができ，P2P でも信頼したデータの送受信が可能とFile System（以下，IPFS）が使用されている．

なる．

IPFS は Protocol Labs が開発したプロトコルとネットワー
ク実装であり，Peer-to-Peer（以下，P2P）をベースとした非集中的な分散ファイルシステムである [3]．IPFS は，コンテン
1：https://opensea.io/
2：https://magiceden.io/
3：https://looksrare.org/

1. 2 IPFS での派生画像管理の課題
IPFS で画像を扱う際の課題として，派生画像の管理に関する問題がある．派生画像とは，あるデジタル画像（以下，オリジナル画像）に対して，画像の編集や加工などを行い生成された画像群のことを指す．派生画像の具体例を図 2 に示す．

がリクエストしたものであるかどうかを検証できるようにした．
GIF

本研究とは，データ内容が変更されるコンテンツを対象としている点で類似しているが，Nikos らの研究では変更されるコンテンツの検証に着目しているのに対し，本研究では内容が変更

オリジナル

縮小

トリミング

図2

彩度

明るさ

ファイル形式

派生画像の具体例

NFT で売買された画像はそのまま使用されるだけではなく，SNS のアイコンや Web ページへの埋め込みなど様々な用途で使用される．その際，必要に応じて画像サイズの変更やトリ
ミング，色加工処理などが行われる．このように同じ画像から派生した，データが異なる画像群が生成され利用されている．

IPFS 上では，これらの派生画像は画像編集や加工によりデー
タが変更されているため，異なる CID で管理される．また，

CID はハッシュ関数を用いて生成されたランダムな文字列であされるコンテンツの生成や，アクセスの効率化について着目している点が異なる．
また，EU 一般データ保護規則の忘れられる権利を満たすた
めに，IPFS にコンテンツ削除のプロトコルを実装した Politou
らの研究 [6] がある．コンテンツの作成者やコンテンツを委任された人などの，権利を持っている人のみがコンテンツ削除の依頼をできるように，コンテンツに所有権の情報を付与し，削除リクエストの有効性を検証できるようにした．本研究とはコンテンツに着目している点で類似しているが，Politou らの研
究ではコンテンツの削除に着目しているのに対し，本研究ではコンテンツの作成や管理に着目している点が異なる．

2. 2 IPFS の性能に関する研究

り，CID から画像同士の派生関係を推測するのは困難である．

IPFS の設計と実装について解説し，パフォーマンス評価をそこで本研究では，これらの同一画像からの派生画像群を効率行った Trautwein らの研究 [7] がある．この研究では，IPFS が的に扱う方法について提案，実装，実験による検証を行う．

152 カ国，2700 以上の自律型システムで使用されていることを

1. 3 提案

IPFS 上での派生画像の再利用を促進するために，以下の 3つの機能を実現する．初めに，IPFS 上での派生画像の作成を容易にするために，画像の動的変換の機能を実現する．次に，同じユーザによる派生画像の再利用を効率的に行うために，オ
リジナル画像の CID と行った編集内容を示すパラメータの組
み合わせと，変換後の画像の CID の関連性を保存する．最後に，様々なユーザによる派生画像の再利用を可能にするために，ピア間で変換前後の CID 同士の関連性の共有を可能にする．

2 関連研究2. 1 IPFS のコンテンツに関する研究明らかにした．また，コンテンツの取得と配信のベンチマーキ
ングを行うために，異なる地域に設定した 6 つの仮想マシンを使用した．設定された地域は，バーレーン・シドニー・ケープ
タウン・カリフォルニア・フランクフルト・サンパウロである．
これらの仮想マシンをパブリックな IPFS ネットワークに接続
し，データを収集・分析した．その結果，IPFS のコンテンツの公開と取得にかかる遅延が，幅広いユースケースにおいて許容できることを示した．

3 実

装Go で実装された IPFS 標準実装である Kubo 4 を拡張して，
1. 3 節で提案した機能を実装した．使用した Go のバージョンは，go1.17.9 である．また，使用した Kubo のバージョンは，

IPFS に関する様々な先行研究のうち，本節では IPFS のコ

v0.12.2 である．加えて，ノード間での変換前後の CID の関連

ンテンツに着目した研究に関して説明する．サポートベクター性の共有は，go-bitswap 5 のモジュールに実装した．つまり，提回帰を用いて，IPFS のコンテンツの複製数を動的に管理する案システムでは，近隣のピアのみと関連性の共有が可能である．

Dongsheng らの研究 [4] がある．過去のコンテンツへのアクセ

提案システムが対応可能な画像処理は，リサイズとトリミン

ス頻度から数時間後のアクセス数を予測し，予測結果に応じてグのみに限定した．リサイズは，高解像度のオリジナル画像を，

複製数を増減させることで，コンテンツのアクセス待ち時間を

Web 上に埋め込む際に軽量化するために使用されると考え，採効果的に短縮した．本研究とは IPFS コンテンツを動的に管理用した．また，トリミングは，SNS のアイコンやバナーなどにするという点で類似しているが，Dongsheng らの研究では単一NFT のイラストを設定する際に使用する頻度が高いと考えたコンテンツの複製数管理に着目しているのに対し，本研究ではため，採用した．

ある画像から派生した複数コンテンツの管理に着目している点が異なる．そのため，提案システムと組み合わせることで，利用頻度の高い派生画像の複製数を増加させることで待ち時間を短縮することが可能であると考える．
他にも，DNSLink と分散型の識別子（DID）を組み合わせ

3. 1 動的画像変換
初めに，IPFS 上での派生画像の生成を容易にするために，
パラメータを用いた動的画像変換を実現する（図 3）．オリジ
ナル画像の CID とどのような編集を行うかを示すパラメータて，IPFS 上で自己検証することができる，データが更新可能なコンテンツを実現した Nikos らの研究 [5] がある．コンテン

4：https://github.com/ipfs/kubo

ツに検証可能な証明書を付与することで，取得したコンテンツ

5：https://github.com/ipfs/go-bitswap

表1

画像のトリミングを指示するパラメータ

パラメータ 説明2ULJLQDO 5HVL]HG

x

トリミング後の画像（左上）の x 座標y

トリミング後の画像（左上）の y 座標w

トリミング後の画像の幅h

トリミング後の画像の高さ①CID 同士の関連性を保存
リクエスト : QmbLmm...&w=100
結果 : QmNihxN...

&,'৊૒भ
ঢ়৴ਙ

Client2ULJLQDO④保存している CID を用いて直接変換後の画像を取得③関連性の一覧を確認(A)

QmbLmm...&w=100②同じ CID で再度リクエスト
2ULJLQDO④パラメータに応じた画像変換③オリジナル画像を送信

2ULJLQDO

図4

関連性の保存と再利用

5HVL]HG①CID とパラメータを分離

Client②オリジナル画像を検索(A)ため，使用頻度の高いコンテンツが様々なピアに分散され，取QmbLmm....&w=100

得が容易になる．また，画像処理をそれぞれのピアが実施するオリジナル : QmbLmm....
パラメータ : w=100

ため，画像処理の負荷分散が期待できる．一方で，行われる画像処理がデータサイズが縮小する処理だと仮定した場合，変換後の画像が送信できる後者と比較して，ネットワーク上のデー

図3

画像の動的変換の流れ

タ転送量が増加する．後者の場合，オリジナル画像を自身のデータストアのみに限定することができる．また，前述の仮定を組み合わせることで，IPFS 上でどのような派生画像の作を考慮すると，ネットワーク上のデータ転送量を削減すること成を行うかの指示を可能にする．CID とパラメータを，CIDができる．一方で，オリジナル画像を所有している端末に画像で使われることのない文字である “&” で接続することによ

処理の負荷が集中する．画像変換を行うメリット・デメリットはり，CID とパラメータの判別を行う．トリミングを行う際の対照的になっている．そのため，今回の実装では IPFS の分散パラメータの例を，表 1 に示す．例えば，オリジナル画像性を重視し，クライアント上で画像処理を行うように実装した．

の左上を原点として，右に 100px, 下に 200px の点から，幅300px，高さ 400px でトリミングを行う場合，提案システムでは < CID > &x = 100, y = 200, w = 300, h = 400 と指定

3. 2 関連性の保存と再利用
続いて，上記で作成した変換後の画像を再利用するために，変換前後の CID 同士の関連性を保存する仕組み（図 4）につする．
パラメータに応じた画像の動的変換を行うために，IPFS 上

いて説明する．オリジナル画像の CID と画像変換に関するパでパラメータを付与した CID を扱えるように，go-cid 6 の実装

ラメータの組み合わせと，変換後画像の CID の関連性の保存を変更した．変更後の CID 構造体は，以下のようになる．与

は，動的変換で取得した変換後の画像を IPFS に追加した後にえられた入力に “&” の文字が含まれているかどうかを確認し，行う．パラメータ付きの CID と変換後の CID の組み合わせを含まれていれば “&” を目印として CID とパラメータを分離す

一対一で保存する．現在の実装ではテキスト形式のファイルとる．オリジナル画像の CID は str 変数に，パラメータは param

して，クライアントのストレージに保存している．また，保存変数にそれぞれ格納する．

した CID 同士の関連性を利用するのは，CID とパラメータをtype Cid struct {分離した後に行う．保存しているファイルから，CID 同士の関string連性を 1 行ずつ読み出し，リクエストされたパラメータ付きのparam string

CID が存在するかを確認する．存在していた場合は，変換後のstr

画像の CID を利用してコンテンツを検索する．存在していな}
続いて，パラメータに応じた動的画像変換について説明する．
まず，オリジナル画像を CID 構造体の str 変数のみを用いて検索する．オリジナル画像の取得後，param 変数を参照して画像変換を行い，変換後の画像を取得する．取得した変換後の画像を IPFS のデータストアに追加することによって，変換後の画像の CID を取得する．以上の流れで，パラメータを用いた

IPFS 上での動的画像変換を実現した．
画像変換に関して，オリジナル画像を取得後に検索を行ったノードで実施する方法と，検索対象となっているコンテンツを所持している端末で実施し，変換後の画像を送信する方法がある．前者の場合，オリジナル画像が検索した端末に複製される
6：https://github.com/ipfs/go-cid

い場合は，オリジナル画像を検索して動的変換を行う．

3. 3 ピアへの関連性の共有
前述した CID 同士の関連性は，端末内のストレージに保存されているため，別の IPFS ノードから利用することができない．
そのため，他のピアが保存している CID 同士の関連性をピアからクライアントに伝達する方法を実装した（図 5）．ピア間
で CID 同士の関連性の共有を可能にするために，go-bitswapのメッセージを拡張した．拡張後のメッセージ構造体は以下のようになる．

いずれかの方法でコンテンツを取得できた場合には変換後の画②リクエストされたパラメータ付き
2ULJLQDOCID に対応する変換後 CID を探索③CID 同士の対応付けを送信④対応付けから
変換後 CID を取得&,'৊૒भ
ঢ়৴ਙ①パラメータ付き CID で問い合わせ

Client(A)像を利用し，取得できなかった場合にはコンテンツが取得できないというエラーを表示する．
また，提案システムのコンテンツ取得方法は，コンテンツをどこから取得するかと，どのように取得するかによって，大まかに 5 つに分類することができる．取得場所に関してはクライ
アントのローカル・データストアとピアのデータストアの 2 種類である．どのように取得するかは，オリジナル画像を取得し⑤変換後の CID で問い合わせ⑥変換後の画像を送信て変形する方法と，変換前後の CID 同士の関連性を利用して変換後の画像を直接取得する方法である．また，ネットワーク

2ULJLQDO 5HVL]HG(B)

上にコンテンツが存在しないなどの理由で取得できない場合もある．詳しい取得方法をまとめたものを以下に示す．
（ 1 ） クライアントが所持している変換後の画像を取得（ 2 ） ピアが所持している変換後の画像を取得（ 3 ） クライアントが所持しているオリジナル画像を取得して変形

図 5 CID 同士の関連性を他のピアへ共有（ 4 ） ピアが所持しているオリジナル画像を取得して変形（ 5 ） 取得不可能

type impl struct {提案システムがどのように変換後の派生画像を取得するかは，

full

bool

クライアントとピアの状態に依存する．クライアントとピアの

wantlist

map[cid.Cid]*Entry

状態として，オリジナル画像を所持しているか，変換後の画像

blocksmap[cid.Cid]blocks.Blockを所持しているか，変換前後の CID の関連性を知っているか

blockPresences map[cid.Cid]pb.Message_Blockの 3 つがある．それぞれの状態において，提案システムがコン

PresenceType

テンツを取得する方法を，図 7 に示す．ノードの状態によってcorresponds

map[cid.Cid]cid.Cidは，複数種類の方法で取得できる可能性があるが，その場合はpendingBytes

int32

上記の箇条書きの数字が最も小さいものを図中に記載した．

}
CID 同士の関連性をプログラム上で実現するために，キーを4 評価実験

変換前のパラメータ付きの CID として，バリューを変換後のCID としたマップ変数に保存した．関連性を共有する具体的な

4. 1 概要流れとしては，ピアからパラメータ付きの CID でブロックの変換前後の CID 同士の関連性の保存・共有が，動的画像変問い合わせがあった場合，保存している関連性を検索する．関換のオーバーヘッドを削減できているか検証するために，評価

連性が見つかった場合には，マップ変数に変換前後の CID の実験を行った．ネットワークの状況などが及ぼす影響を確認す

関連性を代入して返信する．返信を受け取った IPFS ノードは，るために，異なる条件を持つ複数ノードが接続しているプライ

このマップ変数を確認してリクエストに対応した変換後の CID

ベートな IPFS ネットワークを構築した．実験環境を図 8 に示を得る．取得した変換後の CID を利用してコンテンツを検索す．クライアントはコンテンツのリクエストを行うノードで，することで，ピアに保存された CID 同士の関連性を活用する

ノード A，B，C は変換前後の画像の保持や，クライアントへことができる．

変換前後の CID 同士の関連性を伝達するノードである．クラ3. 4 提案システムの全体像
以上の実装を踏まえて，提案システムで IPFS のコンテンツを取得する流れを図 6 に示す．まず，クライアントに変換前後の CID 同士の関連性があるかどうかで分岐する．関連性がある場合には，変換後の CID を用いたコンテンツの探索とオリジナル画像の動的変換を同時に実行し，早く取得できたものを結果として使用する．関連性がない場合には，ピアへの関連性の問い合わせとオリジナル画像の動的変換を同時に実行する．

2 種類の方法で同時に検索を行う理由は，対象となる画像や変換によって最適な検索方法が異なるため，どのような場合でも最適な方法で取得を可能にするためである．どちらの場合でも，イアントとノード B の間には 100ms のレイテンシを、ノード

C との間には 200ms のレイテンシをそれぞれ設定した．レイ
テンシは，tc コマンドを用いて設定した．ノードそれぞれのCPU，メモリ，OS を，表 2 に示す．
また，実験の対象とする編集は 3 種類であり，それぞれ画像の縮小と拡大，そしてトリミングを行うものである．縮小は，NFT でやり取りされているような高解像度の画像 [8] を Webで掲載するために縮小することを想定して設定した．また，拡大はデジタル画像に対して本来あまり行われない処理であるが，2 種類の方法で同時にコンテンツを検索する機能が有効である
かを確かめるために計測した．さらに，トリミングは編集内容による実行時間の差を計測するために実験を行った．縮小の場

図6ड़জ४ॼঝभർดٔ૗஄ध
জ१ॖ६઺൸भർด॑ధষखथষअ

提案システムの流れड़জ४ॼঝभർดٔ૗஄ध
আ॔षभ૗ఌभਖः়ॎच॑ధষखथষअ

॥থॸথॶ਄੭ਂ૭

䝢䜰䜸䝸䝆䝘䝹䛒䜚
ኚ᥮䛧䛯䛣䛸䛜䛒䜛䜸䝸䝆䝘䝹䛺䛧
ኚ᥮䛧䛯䛣䛸䛜䛺䛔䝸䝃䜲䝈䛒䜚

䝸䝃䜲䝈䛺䛧

䝸䝃䜲䝈䛒䜚

䝢䜰䛾
䝸䝃䜲䝈

䝢䜰䛾
䜸䝸䝆䝘䝹䠇ኚᙧ䝢䜰䛾䝸䝃䜲䝈䝸䝃䜲䝈䛒䜚
ኚ᥮䛧䛯䛣䛸䛜䛒䜛䝸䝃䜲䝈䛺䛧

䜸䝸䝆䝘䝹䛒䜚
吆呀叻叹呉吟ኚ᥮䛧䛯䛣䛸䛜䛺䛔䝸䝃䜲䝈䛒䜚
䝸䝃䜲䝈䛺䛧
䝸䝃䜲䝈䛒䜚

ኚ᥮䛧䛯䛣䛸䛜䛒䜛䝸䝃䜲䝈䛺䛧

䜸䝸䝆䝘䝹䛺䛧
ኚ᥮䛧䛯䛣䛸䛜䛺䛔䝸䝃䜲䝈䛒䜚

図7

OS

䝢䜰䛾
䝸䝃䜲䝈

ኚ᥮䛧䛯䛣䛸䛜䛺䛔䝸䝃䜲䝈䛺䛧

䝸䝃䜲䝈䛒䜚

䝸䝃䜲䝈䛺䛧

ྲྀᚓ୙ྍ

䝢䜰䛾
䝸䝃䜲䝈

ྲྀᚓ୙ྍ

䜽䝷䜲䜰䞁䝖䛾
䝸䝃䜲䝈
ྲྀᚓ୙ྍ

ྲྀᚓ୙ྍ

提案システムの状態

表2

メモリ

䝸䝃䜲䝈䛺䛧
䝸䝃䜲䝈䛒䜚
䜽䝷䜲䜰䞁䝖䛾
䝸䝃䜲䝈䜽䝷䜲䜰䞁䝖䛾
䜸䝸䝆䝘䝹䠇ኚᙧ䜽䝷䜲䜰䞁䝖䛾
䜸䝸䝆䝘䝹䠇ኚᙧ䜽䝷䜲䜰䞁䝖䛾
䝸䝃䜲䝈
䝢䜰䛾
䝢䜰䛾
䜸䝸䝆䝘䝹䠇ኚᙧ䝸䝃䜲䝈䝢䜰䛾䜸䝸䝆䝘䝹䠇ኚᙧ䝸䝃䜲䝈䛺䛧

CPU

ኚ᥮䛧䛯䛣䛸䛜䛒䜛

ノードの性能クライアントA

B

CAMD® Ryzen 9Intel® Core™

Intel® Core™

Intel® Core™

3900x

i3-6100U

i7-10700U

i7-10700U

16GiB

12GiB

32GiB

32GiB

UbuntuUbuntuUbuntuUbuntu22.04.1 LTS

20.04.5 LTS

20.04.5 LTS

20.04.5 LTS合と比較しやすくするため，同一のオリジナル画像を使用し，

表3

拡大する画像の詳細

変換後の画像の幅と高さも同じ値に設定した．これにより，編オリジナル画像

変形後

369KB

2.09MB

集の内容がコンテンツの取得時間に及ぼす影響の調査も行った．

ファイルサイズ

それぞれの画像の変換前と変換後の詳細は，表 3，4，5 のよう

ファイルフォーマット

PNG

PNG

になっている．

幅

640px

2048px

高さ

640px

2048px

コンテンツの取得方法として，以下の 10 種類の方法を計測した．それぞれの取得方法を 10 回ずつ実行し，平均取得時間を算出した．

Latency: 100ms
2.5

(B)

(A)

2

(C)
Latency: 200ms

平均取得時間 (s)Client

1.5

1

0.5

図8

実験環境
0

表4

縮小する画像の詳細

ファイルサイズオリジナル画像

変形後

2.66MB

244KB

ファイル形式

PNG

PNG

幅

2048px640px

高さ2048px

640px

(A)

(B)

(C)

(D)

(E)

(F)

(G)

(H)

(I)

(J)

実験条件

図9

画像を拡大する場合の平均取得時間3

表5

トリミングする画像の詳細
オリジナル画像

変形後

ファイルサイズ2.66MB

228KB

ファイル形式

PNG

PNG

幅

2048px640px

高さ2048px

640px

平均取得時間 (s)

2.5

2

1.5

1

0.5

0

(A)

(B)

(C)

(D)

(E)

(F)

(G)

(H)

(I)

(J)

実験条件

(A) クライアントからオリジナル画像を取得して動的変換

図 10(B) ノード A からオリジナル画像を取得して動的変換(C) ノード B からオリジナル画像を取得して動的変換(D) ノード C からオリジナル画像を取得して動的変換(E) クライアントから CID 同士の関連性を取得し，A から変換後の画像を取得(F) クライアントから CID 同士の関連性を取得し，B から変換後の画像を取得(G) クライアントから CID 同士の関連性を取得し，C から変換後の画像を取得(H) ノード A から CID 同士の関連性を取得し，B から変換後の画像を取得(I) ノード B から CID 同士の関連性を取得し，B から変換後の画像を取得(J) ノード C から CID 同士の関連性を取得し，B から変換後の画像を取得
4. 2 結果

画像を縮小する場合の平均取得時間

レイテンシに応じた実行時間の増加が見られない．これも，オ
リジナル画像を取得して動的変換を行うものが早く終了した結果であると考える．
縮小，トリミングに関して，グラフの概形は拡大と一部を除き同様である．異なる点としては，条件 (G)，条件 (H)〜(J) で変換後の CID を用いてアクセスする方が動的変換より早く終了していることがある．そのため，実行結果がノード間のレイ
テンシに応じて増加している．

3 種類の実験結果をまとめたものが図 12 である．まず，画像の動的変換について，近くのノードからオリジナル画像を取得する条件 (A)，(B) では拡大の方が縮小やトリミングに比べて長くなっている．一方で，遠くのノードから取得する条件 (C)，(D) では，拡大よりも縮小やトリミングの実行時間が長くなっている。これは，縮小のオリジナル画像のデータサイズが拡大よりも大きいため，ノードの距離が遠くなると通信にかかる時

実験結果を図 9，10，11 に示す．まず，拡大の場合の結果に間も増加していることが原因だと考える．リサイズ後の画像をついて動的変換を行う条件 (A)〜(D) では，取得時間がノード取得する条件 (E)〜(J) では，拡大の変換後の画像のデータサイ

間のレイテンシに応じて増加している．クライアントが保存しズが大きいため，どの場合でも実行時間が一番長くなっている．

ている CID 同士の関連性を利用して，変換後のコンテンツを取得する条件 (E)〜(G) でも，取得時間はノード間のレイテン
シに応じて増加している．特に，条件 (G) での実行時間が条件(C) よりもわずかに長いため，オリジナル画像を取得して動的変換を行うものが早く終了した結果であると考える．ピアから変換前後の CID を伝達される条件 (H)〜(J) では，ノード間の4. 3 考察

いくつかのネットワーク条件，編集内容で実験を行った結果，大半の場合でクライアントやピアが保持している CID 同士の関連性を利用した場合の実行時間が短いことがわかった．特に，クライアントが履歴を保持しており，かつ近くのノードに変換

た．ノードに変換前後の情報を保存しておき，オリジナルのコ
3

平均取得時間 (s)ンテンツを探索する前に，変換前後の CID 同士の関連性を参
2.5

照し変換後の CID を入手することで，画像処理にかかる時間2を削減することができた．最後に，変換前後の CID 同士の関連性をピアと共有することで様々なユーザからの再利用を可能

1.5にするために，ピア間で対応の共有を可能にした．ピア間でや1

り取りされているメッセージを改変し，パラメータ付きの CID
0.5と対応する変換後の画像の CID を伝達できるようにした．評

0

(A)

図 11

(B)

(C)

(D)

(E)

(F)

実験条件

(G)

(H)

(I)

(J)

価実験の結果から，変換前後の CID の関連性の保存・共有は，
画像のデータサイズやネットワークの状況によらず，効果的であることが示された．このことから，提案システムは，NFT の画像をトリミングする場合の平均取得時間

オフチェーンデータとして IPFS 上に保存された画像の活用や，作成した派生画像の再利用に貢献できる．

ᣑ኱

⦰ᑠ

ࢺ࣑ࣜࣥࢢ

5. 1 今後の展望

3

今後の展望として，まず，実施することのできる編集・加工

平均取得時間 (s)2.5の種類の増加がある．現状，パラメータとして付与できる編集
2の種類は，画像の幅・高さを指定して拡大・縮小を行う編集と，
1.5

左上の座標と幅・高さを指定することでトリミングを行う編集
1の 2 種類である．今後，画像のトリミングや解像度の変更，画0.5

像の回転，色加工処理など，パラメータとして設定できる編集

0

(A)

(B)

(C)

(D)

(E)

(F)

(G)

(H)

(I)

(J)

実験条件

の種類を増やすことで，より多くのユーザのニーズに対応する必要がある．また，現状の提案システムは，ペイントソフト
ウェアなどを使用して編集・加工したデータが追加されても派

図 12

平均取得時間の比較

生画像として活用することができない．これは，提案システム
が，ペイントソフトウェアを通じて編集・加工された派生画像

後の画像が存在する場合（条件 (E)），高速に変換後の画像を取得することが可能であった．一方で，行われる編集の内容や変換後の画像が保存されているノードとの距離によっては，動的変換を行った方が早く取得できる場合があることがわかった．
例えば，遠くのノードがオリジナル画像よりもデータ量の多いの編集内容を認識できないためである．ペイントソフトウェア
上で編集履歴を管理する研究 [9] や，画像間の編集履歴を推測する研究 [10] を参考にすることで，パラメータでは指定することが難しいような編集・加工が施された派生画像を，提案シス
テム上で関連付けて管理することが可能になると考える．

変換後画像を保持している場合（条件 (G)）などである．他に

次に，複数の画像編集の組み合わせを実現することがある．

も，画像変換を行うクライアントの PC 性能を変化させると，現在の実装では，拡大・縮小かトリミングのどちらか一方しか動的変換にかかる時間も変化するため，また異なった結果になることが考えられる．様々な条件によって早く取得できる方法が異なるため，変換後のコンテンツの探索とオリジナル画像の探索と動的変換を同時に実行することが取得時間の短縮に効果的であることがわかる．

5 おわりに適用することができない．だが，トリミング後の画像をリサイズするなど，複数の編集を組み合わせて使用する可能性がある．
その機能を実現するために，複数画像編集の手順をどのように指定するかを検討する必要がある．複数画像編集の手順については，CID とパラメータの区切り文字として使用している “&”を複数設定することによって示す方法などを検討している．
最後に IPFS 上にある画像データから加工元が同じデータを

派生画像の再利用を促進するために，以下の機能を IPFS の見つけて統合することがある．適用できる編集の種類が増加す標準実装である Kubo に実装した．初めに，IPFS 上で派生画ることで，同じ編集をオリジナル画像に適用したとしても，最像の作成を容易にするために，画像の動的変換の機能を実現し終的に完成する画像がデータが異なるものになる可能性があた．CID の末尾に画像編集に関するパラメータを付与できるよる．そのため，IPFS に保存されている画像データ群の中からうに実装を変更した．CID が有効かどうかを確認する前に分離

同じ画像から編集・加工して作成された画像を収集し，オリジ

し，オリジナルのコンテンツを取得した後にパラメータの値にナル画像と適用された編集を特定することで，より多くの派生応じた画像処理を行い，IPFS のデータストアに追加すること

画像を活用することができる．同じオリジナル画像から作成さで変換後の画像の CID を取得した．次に，同じユーザからのれた派生画像の特定には，重複画像の判定の研究（ [11]，[12]）再利用を効率的にするために，オリジナル画像の CID と行っを活用できると考える．この技術を活用することにより，すでた編集内容と，変換後の画像の CID の関連性の保存を実装しに IPFS 上に保存されている派生画像の発見や，圧縮方式の違いによって異なるデータになってしまった画像の集約が実現で
きる．

文

献

[1] NonFungible.com. Yearly NFT Market Report 2021, 2021.
[2] Qin Wang, Rujia Li, Qi Wang, and Shiping Chen. NonFungible Token (NFT): Overview, Evaluation, Opportunities and Challenges. 10 2021.
[3] Protocol Labs. IPFS Powers the Distributed Web. https://ipfs.tech/. (Accessed on 02/03/2023).
[4] Dongsheng Huang and Lijun Chen. Dynamic Replica Management based on SVR in IPFS. In 2019 IEEE 14th International Conference on Intelligent Systems and Knowledge
Engineering (ISKE), pp. 591–597, November 2019.
[5] Nikos Fotiou, Vasilios A. Siris, and George C. Polyzos. Enabling self-veriﬁable mutable content items in IPFS using
Decentralized Identiﬁers. arXiv:2105.08395 [cs], 2021.
[6] Eugenia Politou, Efthimios Alepis, Maria Virvou, andConstantinos Patsakis. Implementing Content Erasure in
IPFS. In Privacy and Data Protection Challenges in theDistributed Era. Springer International Publishing, Cham,
2022.
[7] Dennis Trautwein, Aravindh Raman, Gareth Tyson, Ignacio Castro, Will Scott, Moritz Schubotz, Bela Gipp, andYiannis Psaras. Design and evaluation of IPFS | Proceedings of the ACM SIGCOMM 2022 Conference. SIGCOMM’22: Proceedings of the ACM SIGCOMM 2022 Conference,
pp. Pages 739–752, August 2022.
[8] NFTs Guru. Best NFT Art Size & Dimensions For Creators— Ultimate Guide.
https://nftsguru.com/make-nft/best-nft-art-size-dimensions/, 5 2022. (Accessed on
02/13/2023).
[9] Hsiang-Ting Chen, Li-Yi Wei, and Chun-Fa Chang. Nonlinear revision control for images. ACM Transactions on
Graphics, Vol. 30, No. 4, pp. 105:1–105:10, July 2011.
[10] Shi-Min Hu, Kun Xu, Li-Qian Ma, Bin Liu, Bi-Ye Jiang,
and Jue Wang. Inverse image editing: recovering a semantic editing history from a before-and-after image pair. ACM
Transactions on Graphics, Vol. 32, No. 6, pp. 194:1–194:11,
November 2013.
[11] Ming Chen, Shupeng Wang, and Liang Tian. A Highprecision Duplicate Image Deduplication Approach. J.
Comput., Vol. 8, pp. 2768–2775, 2013.
[12] Bin Wang, Zhiwei Li, Mingjing Li, and Wei-ying Ma. LargeScale Duplicate Detection for Web Image Search. In 2006
IEEE International Conference on Multimedia and Expo,pp. 353–356, 7 2006.