Base URI

暗号資産におけるBase URIとは？

Base URIとは、暗号資産コレクション内のトークンについて、スマートコントラクトが完全なメタデータリンクを組み立てる際に使う共通の開始パスです。

NFTやトークンのメタデータシステムでは、URIによって、ウォレット、エクスプローラー、アプリケーションがトークンを説明するJSONメタデータの保存場所を特定します。

公式のERC-721規格では、tokenURIは特定のアセットについて一意のUniform Resource Identifierを返す関数として定義されています。

多くの場合、Base URIにトークンIDを組み合わせて完全なtokenURIを生成します。

たとえば、Base URIがipfs://exampleCID/で、トークンIDが25の場合、ipfs://exampleCID/25となることがあります。

別の設計では、ipfs://exampleCID/25.jsonのように、完全なメタデータパスにファイル拡張子が含まれる場合もあります。

具体的な結果は、スマートコントラクトがtokenURIをどのように構築するかによって異なります。

OpenZeppelinのERC-721ドキュメントによると、_baseURI関数はERC721.tokenURIの計算に使われ、そのURIはbaseURIとtokenIdを連結して生成できます。

Base URIは、ガス代の節約、メタデータの整理、大規模なNFTコレクションの管理に役立ちます。

暗号資産ユーザーにとってBase URIが重要なのは、NFTの画像、特性、説明などのメタデータの読み込み先に影響するためです。

Base URIが重要な理由

トークンの所有権とメタデータが、必ずしも同じ場所に保存されているとは限らないため、Base URIは重要です。

ブロックチェーンには、トークンの所有者、トークンID、移転履歴、承認、コントラクトのロジックが記録される場合があります。

一方、画像、名前、説明、属性、アニメーション、外部メディアは、多くの場合ブロックチェーン外に保存されます。

Base URIは、オンチェーンのトークンと、オフチェーンまたは分散型のメタデータ保存先をつなぎます。

Base URIが正しければ、ウォレットやアプリケーションはトークンを適切に表示できます。

Base URIが誤っている、機能しない、中央集権型である、または悪意を持って変更された場合、画像が表示されなかったり、特性が誤っていたり、誤解を招く情報が表示されたりする可能性があります。

メタデータがユーザー向け価値の多くを左右するNFTでは、特に重要です。

希少な特性を持つコレクティブルも、メタデータが利用可能で信頼できる場合にのみ価値があるように見えることがあります。

ゲームアイテムでは、レベル、クラス、ビジュアルデザイン、ユーティリティの表示にメタデータが必要な場合があります。

メンバーシップNFTでは、ランクやアクセス権の表示にメタデータが必要になることがあります。

そのためBase URIは、ユーザー体験、メタデータの完全性、コレクションへの信頼、長期的なアセットの可読性に影響します。

Base URIの仕組み

一般にBase URIは、トークンコントラクト内に共通の接頭辞を保存または返すことで機能します。

コントラクトはその後、トークンIDなどのトークン固有の値を追加して、完全なメタデータURIを生成します。

たとえば、Base URIがipfs://bafyExampleCollection/で、トークンIDが100の場合、最終的なtokenURIはipfs://bafyExampleCollection/100となることがあります。

コントラクトがJSONの接尾辞を追加する場合、最終的なtokenURIはipfs://bafyExampleCollection/100.jsonとなる可能性があります。

コントラクトによっては、権限を持つアドレスが更新できる状態変数としてBase URIを保存します。

デプロイ時にBase URIを永久にハードコードするコントラクトもあります。

リビールの状態、トークンの種類、チェーンID、独自ロジックに応じて異なるBase URIを返すコントラクトもあります。

Base URIを使わず、各トークンの完全なURIを個別に保存するコントラクトもあります。

すべてのNFTコントラクトでBase URIが必須というわけではありません。

Base URIは、トークンのメタデータパスを効率よく生成するために広く使われる実装パターンです。

Base URIとtokenURI

tokenURIは、特定のトークンについて返される完全なURIです。

Base URIは、多数のtokenURIの生成に使える再利用可能な接頭辞です。

ERC-721コントラクトでは、tokenURIはオプションのメタデータ拡張機能の一部です。

ERC-721規格では、tokenURIはERC-721 Metadata JSON Schemaに準拠したJSONファイルを指す場合があります。

このJSONファイルには通常、name、description、imageなどのフィールドが含まれます。

Base URIはJSONメタデータそのものではありません。

ウォレットやアプリケーションがJSONメタデータを見つけるためのパスです。

シンプルなコントラクトでは、Base URIとトークンIDを結合してtokenURIを返します。

より複雑なコントラクトでは、トークンごとに完全にカスタム化されたURIを返すことがあります。

ダイナミックNFTのコントラクトでは、固定のBase URIを使わず、オンチェーンの状態からtokenURIを生成することもあります。

アプリケーションが実際に利用するメタデータの場所はtokenURIが示すため、ユーザーはその戻り値を確認する必要があります。

ERC-721 NFTにおけるBase URI

ERC-721は、唯一無二のNFTや一意のトークンIDに関連する最も一般的なトークン規格です。

各ERC-721トークンには、特定のコントラクト内で一意のトークンIDがあります。

コントラクトアドレスとトークンIDの組み合わせによって、そのブロックチェーン上のNFTが一意に特定されます。

メタデータ拡張機能を使うと、アプリケーションはコントラクトにtokenURIを問い合わせられます。

Base URIを使えば、コントラクトが各トークンの完全なURIを保存する必要がなくなります。

長い文字列をオンチェーンに保存するとコストがかかるため、これは有用です。

コレクションは、完全なメタデータリンクを10,000個保存する代わりに、Base URIを1つ保存し、トークンIDから個別のリンクを生成できます。

この設計は、プロフィール画像コレクション、ゲームアイテム、メンバーシップパス、アートシリーズ、コレクティブルセットで一般的です。

たとえば、トークン1、トークン2、トークン3が同じBase URIを使いながら、それぞれ異なるメタデータファイルを参照できます。

共通のBase URIにより、構造をシンプルで予測しやすくできます。

ERC-1155トークンにおけるBase URI

ERC-1155は、1つのコントラクトで代替性トークン、準代替性トークン、NFTを扱えるマルチトークン規格です。

ERC-1155のメタデータ処理は、多くのERC-721実装とは異なります。

公式のERC-1155規格では、URI内に文字列{id}がある場合、クライアントがIDを置換できると定めています。

クライアントは{id}を実際のトークンIDに置換します。必要に応じて、小文字の16進数形式で64文字になるようゼロ埋めします。

これにより、多数のトークンIDで1つの共通URIパターンを利用できます。

たとえば、URIはhttps://example.com/metadata/{id}.jsonのようになります。

ウォレットやアプリケーションは{id}を所定の形式のトークンIDに置換し、該当するJSONファイルを探します。

これは、1つの共通パターンから多数のトークンメタデータリンクを生成するという点で、Base URIと目的が似ています。

ただしERC-1155では、多くのERC-721コントラクトで見られる単純な「Base URI＋トークンID」ではなく、固有の置換ルールを使います。

開発者は、ERC-721とERC-1155のメタデータパスが同じ方法で構築されると考えてはいけません。

Base URIとNFTメタデータ

NFTメタデータとは、トークンが何を表すかをユーザーに伝える構造化情報です。

メタデータには、名前、説明、画像、アニメーションURL、属性、背景、希少性の特性、レベル、アンロック可能なコンテンツへの参照、外部リンクなどが含まれる場合があります。

ERC-721のメタデータスキーマには、name、description、imageなどの基本フィールドが含まれます。

ERC-1155のメタデータスキーマにも一般的な説明フィールドが含まれ、トークン固有の表示データに対応しています。

通常、Base URIはメタデータファイルを取得できるディレクトリまたはエンドポイントを指します。

メタデータがJSONファイルとして保存される場合、各トークンIDは多くの場合1つのJSONファイルに対応します。

メタデータが動的な場合、Base URIは時間とともに異なるJSONを返すAPIエンドポイントを指すことがあります。

メタデータがコンテンツアドレス方式で保存されている場合、Base URIは分散型ストレージの識別子を指すことがあります。

Base URIの品質によって、アプリケーションがメタデータを一貫して取得・表示できるかが左右されます。

メタデータがないトークンもオンチェーンには存在しますが、ユーザーが内容を理解したり価値を判断したりするのが難しくなる場合があります。

Base URIとIPFS

IPFSは、NFTのメタデータやメディアによく使われる分散型ストレージシステムです。

公式のIPFS NFTデータガイドは、IPFS上に保存された外部NFTデータへスマートコントラクトからリンクする際、IPFS URIを使うことを推奨しています。

IPFS URIは通常ipfs://で始まり、CIDとも呼ばれるコンテンツ識別子を含みます。

IPFSを使ったBase URIは、ipfs://bafyExampleCID/のようになります。

各トークンのメタデータファイルは、そのIPFSディレクトリ内に保存できます。

CIDはサーバーの場所ではなくデータそのものを参照するため、この設計はNFTメタデータを通常のウェブリンクより改ざんされにくくする可能性があります。

コンテンツが変わるとCIDも変わります。

これにより、ユーザーはメタデータが変更されたかどうかを確認しやすくなります。

ただし、ユーザーが簡単に取得できるようにするには、少なくとも1つのノードまたはピンニングプロバイダーでIPFSコンテンツを利用可能な状態にしておく必要があります。

IPFSのBase URIは完全性の向上に役立ちますが、長期保存の計画が不要になるわけではありません。

Base URIとHTTP URL

Base URIには通常のHTTPS URLも使用できます。

たとえば、コレクションのBase URIをhttps://example.com/metadata/にできます。

その場合、トークン100のtokenURIはhttps://example.com/metadata/100.jsonとなる可能性があります。

HTTPSメタデータは、プロジェクトがウェブサーバー上のファイルを更新できるため、シンプルで柔軟です。

この柔軟性は、ゲーム、ダイナミックNFT、メンバーシップ、進化するアートなどに役立つ場合があります。

一方で、サーバー所有者がメタデータを変更、削除、リダイレクト、またはブロックできるため、信頼上のリスクも生じます。

ドメインの有効期限が切れたり、ホスティングプロバイダーが停止したりすると、NFTが正しく表示されなくなる可能性があります。

プロジェクトの管理者が侵害された場合、Base URIやメタデータエンドポイントから悪意のあるコンテンツや誤解を招くコンテンツが配信される可能性があります。

中央集権型のHTTPメタデータは使いやすい一方、長期的な永続性を損なう可能性があります。

プロジェクトがコンテンツアドレス方式のストレージ、中央集権型ウェブサーバー、またはハイブリッド方式のどれを使っているか確認してください。

Base URIとArweave型ストレージ

メタデータやメディアに永続ストレージシステムを利用するNFTプロジェクトもあります。

こうしたシステムでは、トランザクションIDや永続的なコンテンツパスを通じてメタデータを参照する場合があります。

Base URIは、永続ストレージのゲートウェイやマニフェストパスを指し、多数のトークンメタデータファイルを整理できます。

この方法は、通常のウェブサーバーが消失するリスクを抑える可能性があります。

また、長期保存を目的として設計されたストレージシステムであれば、継続的なピンニング費用の必要性を減らせる場合があります。

それでも、URIの正確な形式とゲートウェイの挙動を理解する必要があります。

ゲートウェイURLは、その基盤となる永続コンテンツ識別子と常に同じとは限りません。

コントラクトにゲートウェイ形式のURLだけが保存されている場合、表示はそのゲートウェイの利用可能性に依存する可能性があります。

より堅牢な設計では、永続識別子が明確で検証可能です。

Base URIの設計では、長期的なデータ保存先を監査しやすくする必要があります。

Base URIとオンチェーンメタデータ

メタデータを完全にオンチェーンに保存または生成するトークンは、外部のBase URIに依存しません。

オンチェーンメタデータは、スマートコントラクトからエンコード済みJSONを含むdata URIとして返せます。

この設計では、tokenURIはipfs://やhttps://ではなく、data:application/jsonで始まる文字列を返す場合があります。

スマートコントラクト自体がメタデータを生成するため、メタデータをより自己完結的にできます。

オンチェーンメタデータは、ジェネラティブアート、完全オンチェーンのゲーム、IDシステム、不変のコレクティブルに役立ちます。

その代わり、オンチェーンの保存や計算にはコストがかかる場合があります。

大きな画像、アニメーション、複雑なメタデータをオンチェーンに直接保存するのは困難なことがあります。

そのため、多くのプロジェクトは外部メタデータにBase URIを使い、完全なオンチェーンメタデータは特別な用途に限定します。

すべてのプロジェクトに当てはまる唯一の最適なモデルはありません。

適切なメタデータ設計は、コスト、永続性、柔軟性、ユーザーの期待、技術的な複雑さによって異なります。

Base URIとメタデータのリビール

多くのNFTコレクションは、リビールの過程でBase URIを使用します。

リビール前は、すべてのトークンが同じプレースホルダーメタデータを返す場合があります。

プレースホルダーには、ミステリー画像や一般的なコレクション説明が表示されることがあります。

リビール後、プロジェクトがBase URIを更新し、各トークンが最終的なメタデータファイルを参照するようにします。

リビール前に各トークンの最終的な特性が分からないため、この方式はミントをより公平に感じさせる可能性があります。

ただし、リビール方式には信頼が必要です。

プロジェクトがBase URIを管理している場合、ミント後にメタデータを変更できる可能性があります。

リビールのプロセスが透明でないと、希少な特性が不公平に割り当てられたのではないかとユーザーが懸念する場合があります。

プロジェクトは、プロベナンスハッシュの公開、検証可能な乱数の利用、リビール後のメタデータのロック、監査可能なメタデータ生成などにより、こうした懸念を抑えられます。

コレクションのBase URIが一時的なのか、リビール済みなのか、変更可能なのか、永久にロックされているのかを確認してください。

変更可能なBase URI

変更可能なBase URIとは、コントラクトのデプロイ後に変更できるBase URIです。

ローンチ時にメタデータの準備ができていない場合、メディアを移行する場合、またはダイナミックNFTを更新する場合などに役立ちます。

一方、更新機能を管理する者がすべてのトークンの表示内容を変更できる可能性があるため、危険を伴うこともあります。

プロジェクトはアートワークを差し替えたり、特性を変更したり、メタデータを新しいサーバーにリダイレクトしたり、コンテンツを削除したりする可能性があります。

悪意のある管理者がメタデータを変更し、トークンの価値を損なったり、ユーザーを誤解させたりすることもあります。

当初のチームが誠実であっても、管理者キーが侵害されれば同じ結果になる可能性があります。

Base URIを現在も変更できるか確認してください。

また、誰が変更できるのかも確認してください。

1つの外部所有ウォレットが管理する変更可能なBase URIは、適切に統制された更新プロセスよりリスクが高くなります。

変更可能なメタデータはトークンの信頼モデルを変えるため、その旨を明確に開示する必要があります。

不変のBase URI

不変のBase URIとは、デプロイ後または最終ロック操作後に変更できないBase URIです。

管理者が後からメタデータのパスを変更できないと分かるため、信頼性の向上につながる場合があります。

長期的なコレクティブルの永続性を重視するプロジェクトでは、不変のBase URIがよく使われます。

特に、IPFS CIDなどのコンテンツアドレス方式のストレージと組み合わせると、より強固になります。

ただし、元のURIに誤りがある場合、不変性によって問題が生じることもあります。

メタデータファイルが欠落している、形式に誤りがある、または誤ったパスにアップロードされている場合、プロジェクトは修正できない可能性があります。

ストレージゲートウェイの挙動が変わっても、コントラクトを適応させられないことがあります。

開発者はBase URIをロックする前に、メタデータパスを十分にテストする必要があります。

不変性は後からの変更を防ぎますが、元のメタデータが正しいことを保証するものではありません。

恒久的な誤りも、そのまま恒久的に残ります。

Base URIとERC-4906メタデータ更新

ERC-4906は、ERC-721トークンのメタデータ更新拡張規格です。

公式のERC-4906規格は、メタデータの変更を通知するMetadataUpdateイベントとBatchMetadataUpdateイベントを追加します。

ウォレット、インデクサー、アプリケーションはメタデータをキャッシュすることが多いため、これは重要です。

Base URIが変わってもアプリケーションがキャッシュを更新しなければ、ユーザーには古いメタデータが表示され続ける場合があります。

ERC-4906により、コントラクトはメタデータが変更されたことをサードパーティーのシステムに標準的な方法で通知できます。

リビール、ダイナミックNFT、進化するゲームアイテム、ミント後のメタデータ修正に役立ちます。

ただし、この規格自体がメタデータ変更を安全にするわけではありません。

変更を通知しやすくするだけです。

メタデータ変更を管理する権限も引き続き重要です。

変更可能なBase URIや動的メタデータを使う場合、更新権限を安全に管理し、明確に文書化する必要があります。

Base URIとERC-7160マルチメタデータ

ERC-7160は、トークンごとに複数のメタデータURIをサポートするERC-721拡張規格です。

公式のERC-7160規格は、トークンが複数のメタデータURIと固定されたプライマリーURIを持てる仕組みを説明しています。

メタデータの場所が常に1つの静的なものとは限らなくなるため、Base URIにも関係します。

トークンは複数のバージョン、形式、改訂版、表示方法を持つ場合があります。

たとえば、ダイナミックアートに複数の承認済みメタデータ状態を設定できます。

ゲームアイテムは、アップグレードやイベント後に異なるメタデータを持つ場合があります。

共同制作NFTには、複数のクリエイターによるメタデータが含まれることがあります。

複数メタデータへの対応は柔軟性を高めますが、メタデータの監査を複雑にします。

ユーザーやアプリケーションは、どのURIがプライマリーなのか、古いURIに引き続きアクセスできるのかを把握する必要があります。

Base URIは、1つ以上のメタデータ保存先の基点となることが多いため、引き続き重要です。

Base URIとガス代の効率化

Base URIは、ガス代を抑える目的でよく使われます。

オンチェーンのストレージにはガス代がかかるため、トークンごとに完全なメタデータURIを保存するとコストが高くなる場合があります。

共通のBase URIを使えば、コントラクトが保存する情報を減らせます。

長い文字列を何千個も保存する代わりに、コントラクトは1つの接頭辞を保存し、必要に応じてトークン固有のパスを計算できます。

トークンIDが多い大規模なコレクションで特に有用です。

たとえば、10,000個のトークンを持つコレクションは、1つのBase URIとトークンIDを名前にした10,000個のJSONファイルを利用できます。

コントラクトには、Base URIとトークンIDを結合するためのロジックだけが必要です。

これによりストレージを節約できますが、トークンごとにカスタムURIを保存する方法より柔軟性は低くなります。

開発者は、ガス代の節約とメタデータの柔軟性のどちらを優先するか選ぶ必要があります。

低コストの設計でも、メタデータを簡単に変更できたり、検証しにくくなったりすれば、安全とは限りません。

Base URIとファイル名

tokenURIの構築結果は実際のメタデータファイルと一致させる必要があるため、ファイル名は重要です。

コントラクトがipfs://CID/1を返す場合、ストレージには1という名前のファイルまたはオブジェクトが必要です。

保存先に1.jsonがあるのに、コントラクトが1だけを返すと、一部のアプリケーションでメタデータを読み込めない可能性があります。

ファイル名が1.jsonなのに、コントラクトが0001.jsonを返す場合も、メタデータが壊れる可能性があります。

ERC-1155では、トークンIDの置換時に小文字の16進数形式でゼロ埋めするため、さらに注意が必要です。

開発者はデプロイ前にファイル名を決めておく必要があります。

テストネットで実際のメタデータファイルを使い、tokenURIの出力を確認してください。

小さなID、大きなID、連番ではないIDを含む複数のトークンIDでテストする必要があります。

ウォレットやインデクサーがメタデータをどのように解釈するかもテストしてください。

小さな命名ミスでも、コレクション全体に大きな表示上の問題を引き起こすことがあります。

Base URIと末尾のスラッシュ

末尾のスラッシュとは、Base URIの最後に付く「/」です。

これが最終的なtokenURIの有効性を左右する場合があります。

たとえば、ipfs://CID/にトークンIDの1を加えると、ipfs://CID/1になります。

スラッシュがない状態でipfs://CIDに1を加えるとipfs://CID1となり、誤ったパスになる場合があります。

HTTPSのパスでも同じ問題が起こることがあります。

https://example.com/metadata/に1.jsonを加えると、明確なファイルパスになります。

https://example.com/metadataに1.jsonを加えるとhttps://example.com/metadata1.jsonとなり、そのファイルが存在しない可能性があります。

開発者はコントラクト内でスラッシュと接尾辞を一貫して処理する必要があります。

マーケットプレイスの表示だけでは、ユーザーがこの問題に気付けないこともあります。

メタデータが読み込まれない場合、まずコントラクトが返すtokenURI文字列を正確に確認するのが一般的です。

Base URIとメタデータのキャッシュ

多くのウォレット、マーケットプレイス、エクスプローラー、インデックスサービスはNFTメタデータをキャッシュします。

毎回メタデータを最初から取得する必要がなくなるため、キャッシュは表示速度の向上に役立ちます。

ただし、キャッシュによってBase URIの変更が分かりにくくなることがあります。

プロジェクトがメタデータを更新しても、一部のアプリケーションには古い画像や属性が表示され続ける場合があります。

メタデータ更新イベントが役立つ理由の1つは、これです。

ERC-4906は、コントラクトがメタデータの変更を標準的な方法で通知できるようにするために作られました。

それでも、すべてのアプリケーションがすぐに更新するとは限らず、すべてのメタデータイベントに対応しているわけでもありません。

更新に時間がかかる間は、アプリケーションによってトークンのメタデータ表示が異なる場合があります。

これは必ずしも、トークン自体の所有権が変わったり、壊れたりしたことを意味しません。

単にメタデータのキャッシュがまだ更新されていないだけの場合があります。

Base URIと中央集権化のリスク

Base URIが特定の当事者の管理下にあるサーバーやドメインを指す場合、中央集権化のリスクが生じます。

プロジェクトが通常のウェブドメインにメタデータを保存している場合、ドメイン所有者はファイルを変更できます。

ドメインの期限切れ、差し押さえ、ハッキング、停止の可能性もあります。

NFTメタデータの中央集権化リスクに関する研究は、中央集権型ストレージによってNFTデータが検閲、侵害、管理者による変更にさらされる可能性を指摘しています。

多くのユーザーは、NFTを所有すればアセット全体がオンチェーンに永久保存されると考えているため、これは重要です。

実際には、トークンが別の場所に保存されたメタデータを指しているだけの場合があります。

その参照先が不安定なら、ユーザーに表示されるアセットも不安定になる可能性があります。

コンテンツアドレス方式のストレージや、明確なメタデータロックにより、このリスクを軽減できます。

ただし、どのプロジェクトにも長期的なストレージ計画が必要です。

Base URIの管理が不適切だと、魅力的なNFTがリンク切れになることがあります。

Base URIとコンテンツアドレス方式

コンテンツアドレス方式では、コンテンツ自体を基に識別子が決まります。

暗号資産のメタデータでは、IPFS CIDが一般的な例です。

メタデータがコンテンツアドレス方式の場合、メタデータを変更すると識別子も変わります。

これにより、改ざんを検出しやすくなります。

そのため、CIDを含むBase URIは、参照先のファイルが気付かれないまま変更されていないことについて、ユーザーにより強い確信を与える場合があります。

サーバーが同じアドレスで新しいコンテンツを配信できる通常のURLとは異なります。

コンテンツアドレス方式だからといって、コンテンツが自動的に永久保存されるわけではありません。

誰かがデータをホスト、ピンニング、または別の方法で維持する必要があります。

また、元のメタデータが誠実で質の高いものだったことを保証するものでもありません。

その識別子が指すコンテンツが同じであることの検証に役立つだけです。

Base URIとダイナミックNFT

ダイナミックNFTとは、イベント、時間、ユーザー操作、ゲームの状態、オラクルデータ、コントラクトロジックに応じてメタデータが変化するトークンです。

ダイナミックNFTは、APIや動的メタデータサービスを指すBase URIを使う場合があります。

状態の変化に応じて、オンチェーンでメタデータを生成することもあります。

動的なBase URIにより、NFTの双方向性や有用性を高められる可能性があります。

たとえば、ゲームのキャラクターNFTがレベルアップし、新しい属性を表示することがあります。

メンバーシップNFTは、ユーザーが特定のステータスに達すると外観が変わることがあります。

現実資産トークンは、書類が更新された際にメタデータが変わる場合があります。

動的メタデータのリスクは、更新ルールへの信頼が必要なことです。

何が変更可能なのか、誰が変更できるのか、変更がコード、管理者、オフチェーンシステムのどれによって管理されるのかを把握してください。

動的メタデータが有効に機能するには、ルールの透明性が必要です。

Base URIとセキュリティ

Base URIのセキュリティは、ストレージ、アクセス制御、コントラクトロジック、ユーザーの期待によって決まります。

Base URIを更新できる場合、更新機能には強固な権限管理が必要です。

1つの秘密鍵がBase URIを管理している場合、その鍵は価値の高い標的になります。

マルチシグウォレットがBase URIを管理している場合、セキュリティは署名者の信頼性と必要署名数のルールに左右されます。

ガバナンスがBase URIを管理している場合、セキュリティは投票権の分布とアップグレードプロセスに左右されます。

Base URIがサーバーを指す場合、サーバーとドメインのセキュリティが重要です。

Base URIがIPFSを指す場合、ピンニングとコンテンツの利用可能性が重要です。

メタデータがオンチェーンで生成される場合、コントラクトの正確性が重要です。

すべてに当てはまる単一のBase URIセキュリティモデルはありません。

重要なのは、何を誰が変更できるのか、ユーザーがどのように検証できるのかです。

Base URIとスマートコントラクトのアップグレード

アップグレード可能なスマートコントラクトでは、tokenURIの計算方法を変更できます。

そのため、Base URI変数の表示が変わらなくても、Base URIのロジックが変更される可能性があります。

アップグレード可能なNFTコントラクトを使えば、開発者はバグ修正や機能追加を行えます。

一方、ユーザーがトークンを購入した後にメタデータの挙動を変更できる場合もあります。

コントラクトがアップグレード可能かどうかを確認してください。

また、誰がアップグレードを管理しているか、タイムロックやガバナンスプロセスがあるかも確認してください。

アップグレードによってtokenURI関数全体を置き換えられるなら、Base URIがロックされていても、その意味は限定的です。

メタデータの強い保証を得るには、Base URIとコントラクトのアップグレード経路の両方を確認する必要があります。

信頼に影響するため、開発者はアップグレード可能性を明確に開示してください。

ユーザーはBase URIだけを見てメタデータの永続性を評価すべきではありません。

Base URIとトークンの検証

Base URIは、トークンのメタデータが想定されたコレクションのソースに由来するかを確認する手掛かりになります。

ただし、画像の見た目やトークン名だけを根拠にしてはいけません。

偽トークンが、実在するコレクションのメタデータ、名前、シンボル、画像をコピーすることがあります。

実際の識別情報は、正しいブロックチェーン上のコントラクトアドレスとトークンIDです。

Base URIでメタデータの参照先は確認できますが、それだけでトークンの正当性が証明されるわけではありません。

詐欺コントラクトが、正規コレクションのメタデータをコピーして参照することもあります。

コントラクトアドレス、トークン規格、作成者情報、メタデータパス、所有履歴、プロジェクトの公式情報を確認してください。

開発者はtokenURIの戻り値を予測しやすく、簡単に調査できるようにする必要があります。

明確なBase URI設計は検証に役立ちますが、コントラクトの検証に取って代わるものではありません。

真正性は、トークンの識別情報とメタデータの完全性の両方に左右されます。

Base URIとコレクション単位のメタデータ

Base URIは通常、トークン単位のメタデータパスを指します。

コレクション単位のメタデータは、コントラクトやコレクション全体を説明するもので、別のものです。

コレクションのメタデータには、コレクション名、説明、画像、バナー、外部リンク、手数料、ソーシャル情報などが含まれる場合があります。

一部のコントラクトは、contractURIなどの別の関数を通じてコレクション単位のメタデータを公開します。

トークンのBase URIとコレクションメタデータURIを混同してはいけません。

トークンのBase URIは、個々のトークンIDのメタデータ生成に使われます。

コレクションメタデータURIは、コレクション全体を説明します。

どちらも、ウォレットやアプリケーションでのプロジェクトの表示に影響します。

どちらにも、中央集権化や変更可能性のリスクがあります。

個々のトークンデータを制御するURIと、コレクション表示データを制御するURIを把握してください。

Base URIとメタデータの凍結

メタデータの凍結とは、メタデータを永久に変更できない状態にする、または今後変更しないと示すことです。

プロジェクトは、Base URIを更新する機能を削除してメタデータを凍結する場合があります。

また、Base URIをコンテンツアドレス方式のストレージパスに設定し、更新権限を放棄して凍結することもできます。

リビール後にメタデータを凍結したと発表するプロジェクトもあります。

凍結がコードによって強制されているのか、チームがそう約束しているだけなのかを確認してください。

約束は、コントラクトレベルでのロックよりも弱いものです。

コントラクトをアップグレードできる場合、コントラクトレベルのロックもそれだけでは十分ではありません。

メタデータを真に凍結するには、tokenURIの結果を変更できるすべての経路を確認する必要があります。

永続性が重要な場合、凍結はコレクターの信頼を高める可能性があります。

ただし、早すぎる凍結は、後から直せない誤りを残すことがあります。

Base URIとユーザー体験

アプリケーションはメタデータを使ってユーザーの保有物を表示するため、Base URIはユーザー体験に影響します。

Base URIがすばやく読み込まれれば、NFTはスムーズに表示されます。

Base URIが遅い、利用できない、またはブロックされている場合、ウォレットには空白の画像や汎用プレースホルダーが表示されることがあります。

メタデータJSONの形式が不正だと、アプリケーションが解析できない場合があります。

メタデータ内の画像リンクが壊れている場合、トークンに文章だけが表示され、メディアが表示されないことがあります。

特性に一貫性がないと、レアリティ判定ツールやゲームがトークンを誤って読み取る可能性があります。

ユーザーはウォレットで見える内容を基にコレクションを評価することがよくあります。

そのため開発者は、Base URIの設計を製品品質の一部として扱う必要があります。

メタデータは有効で安定しており、十分な速度で取得でき、トークンID間で一貫している必要があります。

スマートコントラクトが堅牢でも、Base URIやメタデータの管理が不適切なら、機能不全のように感じられることがあります。

Base URIの例

シンプルなIPFS Base URIは、ipfs://bafyExampleCID/のようになります。

コントラクトがトークンIDの7と.jsonを追加する場合、完全なtokenURIはipfs://bafyExampleCID/7.jsonとなる可能性があります。

シンプルなHTTPS Base URIは、https://example.com/api/token/のようになります。

コントラクトがトークンIDの7を追加する場合、完全なtokenURIはhttps://example.com/api/token/7となる可能性があります。

ERC-1155のURIテンプレートは、https://example.com/metadata/{id}.jsonのようになります。

この場合、対応するクライアントは{id}を所定の形式のトークンIDに置換します。

オンチェーンのdata URIは、Base URIではなくdata:application/json;base64,で始まる場合があります。

コレクションのウェブサイトから推測するのではなく、実際に返されるtokenURIを確認すべき理由が、これらの例から分かります。

通常、アプリケーションが問い合わせるのはコントラクトのtokenURI関数です。

有効でアクセス可能なtokenURIを生成できて初めて、Base URIは役に立ちます。

Base URIを利用するメリット

Base URIの第一のメリットは、ガス代の効率化です。

共通の接頭辞により、オンチェーンに保存するデータ量を減らせる場合があります。

第二のメリットは、コレクションの整理が容易になることです。

開発者はメタデータファイルを1つのフォルダーやエンドポイントに保存し、トークンIDに対応付けられます。

第三のメリットは、大規模コレクションのミントが簡単になることです。

新しいトークンは、予測可能なメタデータパスを自動的に参照できます。

第四のメリットは、リビールを管理しやすいことです。

コントラクトが対応していれば、1回のBase URI変更でプレースホルダーメタデータから最終メタデータに切り替えられます。

第五のメリットは、互換性です。

ウォレット、エクスプローラー、アプリケーションは、tokenURIやURI形式のメタデータパスを読み取ることに慣れています。

第六のメリットは、柔軟性です。

Base URIは、IPFS、HTTPS、永続ストレージリンク、APIエンドポイント、ハイブリッド設計に対応できます。

Base URIを利用するリスク

第一のリスクは、メタデータの破損です。

誤ったBase URIは、コレクション内のすべてのトークンを表示不能にする可能性があります。

第二のリスクは、中央集権化です。

通常のサーバーを指すBase URIは、そのサーバー、ドメイン、運営者に依存します。

第三のリスクは、悪意のある更新です。

管理者がBase URIを変更できる場合、すべてのトークンの表示内容を変更できる可能性があります。

第四のリスクは、隠れた変更可能性です。

Base URIが編集可能なままなのに、ユーザーがメタデータは永続すると信じてしまう可能性があります。

第五のリスクは、キャッシュによる混乱です。

Base URIの更新後も、アプリケーションに古いメタデータが表示される場合があります。

第六のリスクは、ストレージの利用可能性です。

コンテンツアドレス方式のメタデータでも、誰もホストやピンニングをしなければ取得が難しくなる場合があります。

第七のリスクは、アップグレード可能なロジックです。

Base URIがロックされているように見えても、コントラクトのアップグレードによってtokenURIの挙動が変わる可能性があります。

Base URIの確認方法

ユーザーは特定のトークンIDについてtokenURI関数を呼び出し、Base URIの挙動を確認できます。

返されたURIを、プロジェクトが公式に説明しているメタデータと照合してください。

URIがipfs://、https://、data:、ar://など、どのスキームで始まるかを確認してください。

メタデータファイルが読み込めるか、正しいJSONを返すかをテストしてください。

JSONにimage、description、attributesなど、想定されるフィールドが含まれているか確認してください。

JSON内の画像リンクも安定していてアクセス可能か確認してください。

Base URIを変更できるか、コントラクトを調べてください。

コントラクトがアップグレード可能かどうかも確認してください。

コレクションがメタデータを変更したと主張する場合、メタデータ更新イベントを確認してください。

1つのウォレットで正しく表示されたからといって、トークンが安全だと考えてはいけません。

開発者向けのベストプラクティス

開発者は、トークンコントラクトのデプロイ前にメタデータの保存方式を決める必要があります。

Base URIを不変、変更可能、リビール式、動的、または完全オンチェーンのどれにするか選んでください。

長期的な完全性が重要な場合は、コンテンツアドレス方式のリンクを使用してください。

ローンチ前に多数のトークンIDについてtokenURIの出力をテストしてください。

ファイル名、接尾辞、末尾のスラッシュを一貫させてください。

Base URIの更新機能を強固なアクセス制御で保護してください。

ミント後にメタデータが変更可能かどうか開示してください。

メタデータを変更する場合、コントラクトが対応していれば標準のメタデータ更新イベントを発行してください。

すべてのメタデータとメディアについて、バックアップと長期ホスティング計画を維持してください。

メタデータは単なる表示機能ではなく、ユーザーの信頼に関わる要素であることを忘れないでください。

ユーザー向けのベストプラクティス

メタデータを信頼する前に、コントラクトアドレスを確認してください。

スクリーンショットを信頼するのではなく、実際のトークンのtokenURIを確認してください。

メタデータの保存先を明確に説明するプロジェクトを選ぶことを検討してください。

Base URIを引き続き変更できるか確認してください。

メタデータがコンテンツアドレス方式のシステムと中央集権型サーバーのどちらに保存されているか確認してください。

永続性を約束しながら、管理者の更新権限を残しているプロジェクトには注意してください。

リビールや販売後にメタデータが突然変更されていないか確認してください。

NFTを所有していても、メディアファイル、著作権、オフチェーンの権利を所有しているとは限らないことを忘れないでください。

長期的なアクセスが重要であれば、大切なメタデータやメディアをローカルに保存してください。

メタデータが表示されない、または不審な場合は、リスクの兆候として扱ってください。

Base URIに関するよくある誤解

よくある誤解の1つは、Base URIがNFTそのものを保存するというものです。

通常、Base URIはメタデータを指し、所有権はスマートコントラクトで管理されます。

別の誤解は、NFT画像が常にオンチェーンに保存されているというものです。

多くのNFT画像はオフチェーンまたは分散型ストレージに保存され、メタデータを通じて参照されます。

3つ目の誤解は、IPFSを使えばコンテンツが永久にオンラインにあることが保証されるというものです。

IPFSはコンテンツの完全性を高めますが、コンテンツを利用可能にするには、引き続き誰かが維持する必要があります。

4つ目の誤解は、ロックされたBase URIによって、メタデータに表示されたアセットの法的所有権が保証されるというものです。

メタデータの永続性と法的権利は別の問題です。

5つ目の誤解は、Base URIの変更はすべて悪いというものです。

リビール、ダイナミックNFT、バグ修正のための正当な変更もありますが、透明性を保ち、適切に管理する必要があります。

6つ目の誤解は、正しく表示されればBase URIが安全だと証明されるというものです。

キャッシュが問題を隠すことがあるため、可能であれば実際のtokenURIを確認してください。

関連する暗号資産用語

URIとはUniform Resource Identifierの略で、メタデータファイルなどのリソースを特定する文字列です。

tokenURIとは、特定のトークンIDのメタデータURIを返すERC-721関数です。

ERC-721とは、非代替性トークンで広く使われるEthereumのトークン規格です。

ERC-1155とは、代替性、準代替性、非代替性アセットに対応できるマルチトークン規格です。

NFTメタデータとは、トークンの名前、画像、特性、その他のプロパティを説明するJSONまたは構造化データです。

IPFSとはInterPlanetary File Systemの略で、NFTデータによく使われるコンテンツアドレス方式のストレージネットワークです。

CIDとはコンテンツ識別子のことで、IPFSで使われるコンテンツアドレス方式の参照情報です。

Data URIとは、URI文字列内にデータを直接埋め込むURIです。

メタデータのリビールとは、プレースホルダーメタデータから最終メタデータにトークンを切り替えるプロセスです。

メタデータの凍結とは、一定の時点以降、トークンのメタデータやメタデータパスを変更できなくすることです。

FAQ

NFTにおけるBase URIとは何ですか？

Base URIとは、スマートコントラクトが各NFTの完全なメタデータURIを生成する際に使う共通の開始パスです。

Base URIはtokenURIと同じですか？

いいえ。通常、Base URIは共通の接頭辞であり、tokenURIは特定のトークンについて返される完全なメタデータURIです。

ERC-721におけるBase URIの仕組みは？

多くのERC-721コントラクトでは、Base URIとトークンIDを組み合わせて、そのNFTの最終的なtokenURIを生成します。

ERC-1155におけるBase URIの仕組みは？

ERC-1155では、{id}を含むURIテンプレートをよく使い、クライアントが{id}を所定の形式のトークンIDに置換します。

Base URIは変更できますか？

はい。コントラクトに更新機能があり、権限を持つアカウントが引き続き管理している場合は変更できます。

変更可能なBase URIにはリスクがありますか？

はい。管理者が多数またはすべてのトークンのメタデータを変更できる可能性があるため、リスクがあります。

不変のBase URIは常に優れていますか？

不変のBase URIは信頼性の向上につながる場合がありますが、ローンチ時にメタデータパスが誤っていると、間違いを永久に固定してしまうこともあります。

NFTプロジェクトがBase URIにIPFSを使うのはなぜですか？

IPFS CIDはコンテンツアドレス方式であり、参照先のメタデータが気付かれないまま変更されていないことを検証しやすいため、プロジェクトはIPFSを利用します。

IPFSはNFTメタデータが永久にオンラインにあることを保証しますか？

いいえ。IPFSは完全性の維持に役立ちますが、コンテンツは引き続きホスト、ピンニング、または別の方法で利用可能にする必要があります。

トークンを所有しているのにNFT画像が表示されないのはなぜですか？

Base URIの誤り、メタデータファイルの利用不可、画像リンクの破損、アプリケーションキャッシュの未更新などが原因として考えられます。

メタデータのリビールとは何ですか？

メタデータのリビールとは、多くの場合Base URIまたはtokenURIのロジックを更新して、プレースホルダーメタデータから最終メタデータにトークンを切り替えることです。

NFTのBase URIが安全かどうかを確認するには？

tokenURIの出力、ストレージの種類、更新権限、コントラクトのアップグレード可能性、メタデータ形式、信頼できるストレージを通じたファイルの利用可能性を確認してください。

結論

Base URIは、NFTや暗号資産トークンのコントラクトにおける重要なメタデータ概念です。

個々のトークンの完全なメタデータURIをコントラクトが生成する際に使う共通パスです。

多くのERC-721コレクションでは、Base URIとトークンIDを組み合わせてtokenURIを生成します。

ERC-1155では、{id}の置換を使うURIテンプレートが同様の役割を果たすことがよくあります。

共通の接頭辞で多数のトークンメタデータファイルに対応できるため、Base URIは大規模なコレクションを簡単かつ低コストで管理するのに役立ちます。

一方、メタデータはブロックチェーン外に保存されることが多いため、重要な信頼上の課題も生じます。

Base URIが中央集権型サーバーを指す場合、ユーザーはそのサーバーと運営者に依存します。

コンテンツアドレス方式のストレージを指す場合、完全性に関する保証は強まる可能性がありますが、コンテンツの利用可能性は別途確保する必要があります。

Base URIを変更できる場合、ユーザーは更新権限とそのセキュリティ管理を信頼する必要があります。

Base URIが不変なら永続性は高まりますが、誤りがある場合は柔軟性が失われます。

開発者はローンチ前にBase URIのロジックを慎重に設計し、ファイルパスを十分にテストし、更新権限を保護し、メタデータの変更可能性を明確に開示してください。

ユーザーはtokenURIを確認し、コントラクトアドレスを検証し、ストレージの種類を理解し、表示されるメディアが自動的に永続する、または法的に所有できると思い込まないようにしてください。

最も重要なのは、NFTの所有権とNFTのメタデータは関連しているものの、同じではないという点です。

スマートコントラクトはトークンの所有権を示し、Base URIはアプリケーションがトークンの内容を説明するデータを見つけるのに役立ちます。

適切なBase URI設計は、その結び付きを安定的、透明、検証しやすいものにします。

設計が不適切なBase URIは、価値があるように見えるトークンを、リンク切れ、変更可能な約束、またはメタデータのセキュリティリスクに変える可能性があります。