フルオンチェーンとは
**フルオンチェーン（Full On-chain）**とは、データ実体そのものをブロックチェーン上のトランザクションに含めて記録し、データ実体をチェーンの検証対象に含める方式です。
ここで重要なのは、単に「チェーンを保存場所にする」ことではありません。記録されたバイト列とトランザクション、ブロック、チェーンの関係を同じ履歴から取得・照合できるようにすることです。チェーンへの包含は、データ実体の内容が社会的・法的・事実的に真実であることまでは保証しません。
この検証可能性は、1文字のテキストにも意味があります。その文字を表すバイト列を記録すれば、後からどのデータがどのトランザクションやブロックに含まれるかを確認できます。フルオンチェーンの価値は、データの大きさや保存年数によって決まるものではなく、日常的な記録にも適用できます。
具体的な保存と復元の仕組みは、次のページ NFTDriveの保存メカニズム で説明します。
保存・可用性・検証可能性
保存方式を評価するときは、次の3つを独立した性質として区別する必要があります。
- データの保存：データ実体となるバイト列を永続的な媒体へ配置し、保持できること。
- データの可用性：必要なときに、データ実体を取得・復元できること。
- データの検証可能性：取得したデータ実体と、ハッシュや識別情報、トランザクション、ブロック、チェーン、ネットワークとの関係を照合し、検証条件を満たしているか判断できること。
いずれか一つが満たされても、ほかの性質が自動的に保証されるわけではありません。ハッシュがチェーン上に記録されていてもデータ実体を取得できるとは限らず、データ実体を取得できてもチェーン上の記録との対応関係を確認できるとは限りません。
フルオンチェーンは、データ実体とその検証根拠を同じチェーン履歴に関連付けることで、これら3つを一体として扱えるようにする方式です。ただし、可用性はチェーン履歴を保持するノードやアーカイブ、取得経路、復元仕様などにも依存します。
保存方式の比較
後から何を検証したいかによって、適した方式は異なります。
| 方式 | チェーン上の記録 | データ実体の取得元 | 確認できる範囲 | 主な依存・制約 |
|---|---|---|---|---|
| ハッシュのみを記録 | ハッシュや識別情報 | 利用者などが管理するチェーン外の媒体 | 実体を別途取得できれば、記録されたハッシュとの一致を照合できる | 実体の保管と取得経路を別に維持する必要がある |
| 外部ストレージへ保存 | ハッシュ、URI、コンテンツ識別子など | IPFS、Arweave、クラウドなど | 実体と参照情報を取得できれば、チェーン上の記録との対応を照合できる | 外部システムの可用性、保持方針、参照方式に依存する |
| フルオンチェーンで保存 | データ実体を含むトランザクション | チェーン履歴を提供するノードやアーカイブ | 実体、トランザクション、ブロックの関係を同じ履歴から照合できる | 履歴の保持・同期、書き込み条件、取得可能性など、対象ネットワークの設計と運用に依存する |
ハッシュのみを記録する方式では、変更を検知しても、そのハッシュからデータ実体を復元できません。外部ストレージを使う場合は、チェーン上の検証根拠と、外部に置いたデータ実体の保持・取得経路をともに維持します。フルオンチェーンでは、検証根拠と復元元を同じチェーン履歴に保持し、変更の検知から復元・再検証までを一体として設計できます。
比較するときは、対象データの完全なコピーをどの保存先が保持し、それぞれから復元できるかも確認します。ネットワーク全体のノード数が、そのデータの完全なコピー数と一致するとは限りません。複製範囲と保持方針は利用する方式や実装、構成によって異なります。具体的な違いは FAQ で説明しています。
容量や運用コストは、ストレージやデータベースを含むあらゆる情報システムで考慮すべき事項であり、フルオンチェーンだけに生じる制約ではありません。必要な保存容量、書き込みに伴う手数料の有無や額、ノードが負担する計算・通信資源は、対象ネットワークの仕様、ノード構成、運用方針によって異なります。
データ実体が検証対象に含まれる意味
フルオンチェーン方式では、データ実体を構成する情報がトランザクションに含まれ、そのトランザクションがブロック履歴に取り込まれます。そのため、履歴を取得できれば次の関係をたどれます。
- 対象ブロックからトランザクションを取得する。
- 一つまたは複数のトランザクションからデータ実体を復元する。
- 復元結果のハッシュ、識別情報、分割順序などを記録内容と照合する。
- トランザクションのブロックへの包含、チェーン上の位置、対象ネットワークを確認する。
つまり、データ実体の取得とチェーン上の記録の確認を、一続きの検証として扱えます。ただし、ノードが該当履歴を提供しない場合や、チェーン履歴と必要なソフトウェアが失われた場合には、データ実体を取得・復元できない可能性があります。
フルオンチェーンの特性と設計上の考慮事項
フルオンチェーンは、データの保存・取得・照合・検証をブロックチェーンの履歴に関連付けて行えるようにする方式です。
情報システムに共通する容量、コスト、セキュリティ、長期運用などの課題は存在しますが、これらはブロックチェーン固有の欠点ではありません。
重要なのは、それぞれの保存方式がどのような依存関係を持ち、何を検証できるかという点です。
1. データ容量と保存方式
あらゆる情報システムには、物理的な保存容量や処理能力だけでなく、データ形式、ファイルシステム、OS、ソフトウェア実装、通信経路、プロトコルなど、複数の層に制限があります。
例えば、保存媒体に空き容量があっても、ファイル形式やエンコード方式が扱えるサイズ、OSやファイルシステムの上限、アプリケーションが一度に処理できるメモリ量、送受信できるデータ量によって、保存・取得・復元が制限される場合があります。
フルオンチェーンでは、データ実体をトランザクションとして記録するため、保存量に応じてチェーン履歴が増加します。さらに、トランザクションやブロックの上限、ノード実装が受け入れるデータ量、同期や取得に使用するAPIの制限など、対象ネットワーク固有の条件も関係します。
データをチャンクに分割して記録する場合、データ実体に加えて、各チャンクやトランザクションの管理情報などの分だけ保存量が増えます。この追加量は保存形式や分割方法によって異なり、それ自体が「ブロックチェーンだけが容量制限を受ける」理由にはなりません。ファイルシステムやデータベースでも、管理情報や索引などのために元データ以外の領域を使用します。追加量の大きさは方式ごとに評価し、必要な保存資源を確保する課題はデジタル保存全般に共通すると捉える必要があります。
また、チャンクごとの管理情報による増加と、複数の保存先へ複製することによる増加も別です。複数ノードが履歴を保持・同期する構成では、各ノードと通信経路にも相応の資源が必要です。これは、ほかの保存方式で冗長化やバックアップを行う場合と同様に、システム全体で計画します。
したがって、個々のファイル、トランザクション、ブロックなどに適用される上限と、システム全体で継続的に蓄積できるデータ総量は区別して評価する必要があります。ブロックチェーンに保存できる総データ量が一律に小さいわけではなく、実際に扱える範囲はシステム全体の構成と運用によって決まります。
2. 保存・運用コスト
データの保存と提供には、方式を問わずストレージ、計算資源、通信、保守などの費用が発生します。
書き込みに利用料や手数料を設けるかどうかは、ネットワークやサービスの設計・運用方針によって異なります。ブロックチェーンでも、対象ネットワークによってはトランザクション手数料が発生しますが、必須または一律の費用ではありません。
手数料体系はネットワークごとに異なり、独自ネットワークでは運用方針に応じて設定できる場合があります。
コストはブロックチェーンという方式だけで決まるものではなく、保存量、冗長化、ノード構成、運用期間を含めた総コストで比較する必要があります。
3. データの公開範囲と管理
データの公開範囲は、利用するネットワークと暗号化・アクセス制御の設計によって異なります。
パブリックネットワークに平文で保存された情報は、第三者が取得できることを前提に扱う必要があります。
一方、暗号化によってデータの内容を保護したり、プライベートネットワークによって参加者や取得経路を制限したりする設計も可能です。
フルオンチェーンでは記録の事後変更や削除が難しいため、保存前の情報分類と公開範囲の判断が特に重要です。
なお、暗号化やアクセス制御は、既に複製されたデータそのものを消去する仕組みではありません。
4. 暗号技術と長期安全性
暗号アルゴリズムの安全性や将来の計算技術による影響は、クラウドストレージ、通信システム、データベースを含む情報システム全般に共通する課題です。
フルオンチェーンでは暗号化されたデータが長期間保存される可能性があるため、記録時の暗号方式、鍵管理、将来の復号リスクを考慮する必要があります。
これはブロックチェーン固有の脆弱性を意味するものではなく、長期保存する情報の機密性を確保するための設計課題です。
5. ネットワークの継続性とデータの可用性
すべての情報システムは、運用主体、設備、ネットワーク、ソフトウェアなどに依存しています。
クラウドサービスや従来のWebサービスが停止・終了する可能性があるのと同様に、ブロックチェーンネットワークにも運用停止やノード減少の可能性があります。
ブロック生成の停止と、履歴を提供するノードやAPIの停止は区別します。新しいブロックが生成されなくても、必要な履歴を保持し、取得要求に応答するノードやAPIがあれば、記録済みデータは取得できます。取得元がすべて停止した場合も、履歴やアーカイブが残っていれば、取得環境の復旧や別の読み取り手段による復元・検証を検討できます。
フルオンチェーンでは、データ実体と検証に必要な履歴を一体として保持し、対応する復元手段を保全することで、元の提供サービスに依存せずデータを復元・検証できる構成を実現できます。
この検証可能性を継続させる取り組みの一つが、DAOの運用 です。不特定多数の参加者がノード運用や履歴の保持を引き継ぎ、担い手が交代しても記録を利用できる状態を目指します。データに検証可能性をもたらす保存方式と、それを保持・継承して永続性を目指す運用は、役割を分けて設計します。
事業年度や取得・提供期間などに合わせて運用を区切る場合は、Chain Finalization によって、書き込み終了後も必要な期間にわたり履歴を取得・復元・検証できるよう計画します。継続運用と計画的な終了・移行のどちらも、記録を継承するための選択肢です。
6. 長期的な再現性と検証
長期間保存されたデータを利用するためには、データ形式や復元手順を維持する必要があります。これはあらゆるデジタルアーカイブに共通する課題です。
フルオンチェーンでは、データ実体に加えてトランザクションやブロックとの関係を保持できるため、検証根拠を記録された履歴から確認できます。
必要なチェーン履歴、検証情報、復元仕様が残されていれば、記録当時のサービスやアプリケーションが終了した後でも、別の実装による復元・検証が可能です。
ただし、過去の記録内容を検証できることと、当時のネットワークの合意形成が正当であったことを独立して証明できることは区別する必要があります。
7. 記録の訂正と履歴管理
フルオンチェーンの重要な特性は、確定した記録を後から自由に書き換える設計ではないことです。
これは誤記や更新に対応できないという意味ではありません。
訂正や改訂を新しい記録として追加し、元の記録との関係を保持することで、変更の経緯を追跡できます。
一方、保存した情報を後から完全に消去することが要求される用途では、記録対象や保存方式を慎重に選択する必要があります。
保存方式を評価する視点
フルオンチェーンを採用するかどうかは、方式そのものの優劣ではなく、解決する課題と必要な性質から判断します。単純な容量やコストの比較だけで決まるものではありません。
重要なのは、次のような要件です。
- データ実体を誰が、どの媒体で保存するのか
- 保存サービスの終了後も取得できるのか
- サイバー攻撃、ランサムウェア、災害によって一部の保存先が失われても、別の保存先からデータ実体と検証根拠を取得・復元できるのか
- 復旧したデータが記録内容と一致していることを確認できるのか
- 第三者が独立してデータ実体と記録の関係を検証できるのか
- データの変更や改訂の経緯を追跡できるのか
- 特定の事業者への依存をどこまで減らせるのか
- 保存対象に必要な公開性・機密性・削除要件を満たせるのか
フルオンチェーンは、障害や被害からの復旧性を高めるためにも活用できます。データ実体と検証に必要な履歴を複数の独立したノードやアーカイブで保持していれば、一部の保存先が改ざん、暗号化、消失などの被害を受けた場合でも、被害を受けていない保存先からデータを復元し、記録内容との一致を検証できる構成を実現できます。
この復旧性を支えるのは、保存先の地理的な分散、管理権限や認証情報の分離、必要な履歴を保持する方針、隔離されたバックアップ、復元手順の確認などの設計と運用です。同じ拠点や管理権限に依存するノード群は、同時に被害を受ける可能性があります。暗号化したデータでは復号鍵も保全し、必要なソフトウェアや復元仕様とともに利用できる状態を維持する必要があります。
BEYONDは、フルオンチェーンに記録されたデータの取得・復元・検証を利用者自身が行える環境を提供します。これらは復旧したデータを確認するためにも利用できますが、フルオンチェーンへの保存やBEYONDの利用だけで、攻撃の防止やあらゆる被害からの復旧が保証されるわけではありません。
フルオンチェーンの価値は、単にブロックチェーンにデータを保存することではありません。
データ実体と検証根拠を一体として保持することで、1文字のデータから検証可能性をもたらし、必要な履歴からの復元と再検証を一体として設計できることにあります。