分散ストレージ層
DEAP Networkでは、大容量の行動データやセンサーデータをオンチェーンに直接保存することによるコストやスケーラビリティの問題を回避するため、IPFS、Filecoin、Arweaveなどの分散ストレージ技術を活用して大部分のデータをオフチェーンに保管しています。これらのストレージ層ではデータを複数ノードへ冗長配置し、高可用性と耐改ざん性を確保する設計を導入することで、ノードの一部がダウンしても利用者がデータを失わないようにしています。データを格納した後は、そのハッシュ値（コンテンツID）や関連メタデータをL1チェーン上のスマートコントラクトに記録し、データの真正性を容易に検証できるようにします。ストレージノードに対しては「Proof of Storage」や「Proof of Resource」といったコンセンサスを適用し、正しくデータを保持していることを証明したノードにインセンティブを付与します。ユーザーやサービスプロバイダは「ゲートウェイ」を介するか、またはP2PでコンテンツIDを指定してデータを取得でき、ノードがダウンしても冗長コピーによってデータの可用性が維持される仕組みです。
L1チェーン層
DEAP Network独自のPoS（Proof of Stake）系L1チェーン(Avalanche L1のテックスタック)を用意することで、確実なファイナリティ、比較的高いトランザクション処理性能（TPS）と低手数料、そしてガバナンス機能を同時に実現しています。バリデータはネットワークを維持する要となるノードであり、トランザクションの検証やブロック生成を担当すると同時に、ステーキング報酬を受け取る権利を有します。このチェーン上には、分散ストレージにアップロードされたデータのハッシュ値や、データ所有者、アクセス権限、報酬ポリシーなどのメタデータが記録されます。これにより、誰がどのデータをアップロードしてどのようなルールで活用を許可しているかが改ざん不可能な形で保持されるのです。さらに、インセンティブ設計やガバナンス機構をスマートコントラクトで自動化することで、トークン発行やステーキング報酬、閲覧料の分配などを透明かつ分散的に運用できるようになっています。コミュニティはオンチェーン投票を通じて手数料やパラメータの調整、プロトコルアップデートを行えるため、高い透明性と分散性を担保することが可能です。
アプリケーション層
ユーザーはWebまたはモバイルアプリのクライアントを利用し、行動データのアップロードや閲覧、共有などを操作できます。これらのクライアントアプリは、ウォレット連携（Account Abstraction）や分散ストレージゲートウェイとの通信、暗号化や署名といったローカルでのセキュリティ処理を内包しており、ユーザーは高度な技術を意識せずにデータを扱うことができます。さらに、ゲームやSNS、ヘルスケアアプリなど多様な外部サービス（サービスプロバイダ）との連携を容易にするため、REST/GraphQL/gRPCなどのAPIを提供し、事業者が簡単にDEAP Networkへ接続できるように統合SDKと開発ドキュメントを整備しています。可視化や分析ツールとの統合も視野に入れ、グラフ表示、集計ダッシュボード、AI解析プラットフォームとの連動など、多様な分析機能を提供し、ユーザーが同意した範囲内でのみデータを開示できるようゼロ知識証明（ZKP）への対応をサポートしています。
モジュール構成
データ収集（Ingestion）モジュール
DEAP Networkはウェアラブルデバイスやスマートフォン、Webアプリといった多様なソースからの行動データを標準化フォーマット（JSONやProtocol Buffersなど）に変換し、暗号化モジュールに渡す仕組みを提供します。事業者向けにはデータ収集用SDKが用意されており、サービスプロバイダは数行のコード変更でネットワークと統合が可能になります。zkTLSのように、暗号化された通信経路上で安全かつリアルタイムなログ取得を実現する技術も将来的な実装を見据えています。接続環境が不安定な地域を考慮して、デバイス側に一時的にデータをバッファリングし、バッチ送信やレート制御を行うことで、通信状況に合わせた効率的な送信ができるような構成を考慮します。
以下の表は、DEAP Networkが想定する「行動データ収集モジュール」で取り扱われるデータ形式の例を示したものです。ここでは、ウェアラブルデバイスやスマートフォン、Webアプリなどから取得した行動データを、**標準化フォーマット（JSON など）**にまとめ、暗号化モジュールに渡す直前のイメージを想定しています。実際の実装ではProtocol Buffersや独自のJSONスキーマを利用する場合もあるため、あくまで例示的な構造です。
フィールド | 型 | 例 | 説明 |
version | string | "1.0" | データ形式のバージョン。将来的な互換性を確保するために明記する。 |
deviceId | string | "wearable-abc123" | ウェアラブルやスマートフォンなど、データを生成したデバイスの一意なID。 |
appId | string | "com.example.fitnessApp" | データを収集しているアプリやサービスのID。Webアプリの場合はドメイン名などを利用してもよい。 |
userId | string | "user-xyz789" | デバイスやアプリ内でのユーザー識別子。後続の暗号化モジュールやウォレットとの紐付けで、ユーザーアカウントを一意にトラッキングする際に用いる。 |
dataType | string | "STEP_COUNT" | データの種別を表すフィールド。例: "STEP_COUNT", "LOCATION", "HEART_RATE", "GAME_SCORE" など。 |
timestamp | number | 1680001234 | データが生成または取得された時刻（Unixエポックタイム）。 |
payload | object / array | { "steps": 12000, "units": "count" } | 実際の行動データを表すオブジェクト。例として歩数の場合は{"steps": 12000}、位置情報の場合は{"lat": 35.6895, "lon": 139.6917}など。複数の要素を含む場合は配列構造を利用する。 |
metadata | object | (下記に詳細) | データの補足情報を含むオブジェクト。バージョン、カテゴリ、タグ、センサー精度など、詳細なメタデータを格納可能。 |
metadata.formatVersion | string | "2.0" | payload部分のフォーマットやスキーマのバージョン。 |
metadata.tags | array of strings | ["morning", "exercise"] | データの内容や用途を表すタグ。分析や可視化の際にフィルタリング条件として利用できる。 |
metadata.acquisitionMethod | string | "continuous" | データ取得方法を示す文字列（例: "continuous", "batch", "triggered" など）。 |
metadata.buffered | boolean | TRUE | 通信環境が不安定な地域などで一時的にデバイス側にバッファリングしたかどうかのフラグ。 |
metadata.encryptionPlanned | boolean | FALSE | この段階（暗号化モジュール渡し前）でまだ暗号化されていない場合に false、すでにクライアント側で暗号化済みなら true。将来的にはクライアント暗号化を想定している場合に使用。 |
signature | string (Base64) | "base64EncodedSignature" | ユーザー端末やアプリ側で行った署名（データの改ざん防止用）。暗号化モジュールへ渡す直前に付与される場合や、モジュール内部で付与される場合など実装により異なる。 |
zkTLSFlags (オプション) | object / array | { "enabled": false } | 将来的にzkTLSのような、暗号化された通信経路上での安全なログ取得を行うときの設定。例: {"enabled": true, "protocolVersion": "draft-XX"} などを記述。 |
batchInfo (オプション) | object | { "size": 5, "intervalSec": 60 } | バッチ送信を行う際の情報。バッファにまとめたデータの件数や送信間隔などを記録し、アップロード頻度を制御する仕組みに活用できる。 |
暗号化・署名（Encryption/Signing）モジュール
ユーザーが保持する秘密鍵を用いてクライアント側で行動データを暗号化するエンドツーエンド暗号化モデルを採用することで、ストレージに保管されるデータは常に暗号化された状態になります。これにより、悪意あるストレージノードがデータ内容を取得するリスクを抑制します。さらに、署名付きトランザクションによって、どのユーザーが（またはどのサービスIDが）いつデータをアップロードしたかをオンチェーンで証明できるため、不正改ざんが容易に検知可能です。今後はZK-SNARK/STARKなどのゼロ知識証明を活用し、データの具体的な内容を開示せずに「正当性のみ」を証明するようなユースケースにも対応することが想定されています。
スマートコントラクト（On-Chain）モジュール
L1チェーン上のスマートコントラクトには、データのハッシュ値・所有者アドレス・アクセス条件・インセンティブ発行ロジックなどが記録され、アップロード時やアクセス更新時にトランザクションが実行されます。たとえば、データを閲覧する際には課金が発生し、観測データやノード稼働報酬などを自動的に分配する仕組みも同モジュールで管理されます。ガバナンスやステーキング、トークンの発行・焼却といった重要なプロトコル機能もスマートコントラクトに組み込むことで、管理者の恣意的な介入が難しい分散管理を実現しています。
ストレージ連携（Off-Chain）モジュール
ゲートウェイやノード管理機能を用いて、ユーザーやアプリから分散ストレージへのアップロード・ダウンロードを円滑に行います。ゲートウェイがハッシュ照合やアクセス権検証を実施し、ストレージノードの正当性や稼働状況を定期的にヘルスチェックすることで、ネットワーク全体の信頼性を維持します。IPFSなどの場合、ピン留め（pinning）機能で重要なデータを複数のノードに常駐させる仕組みを採用し、キャッシュやフェイルオーバーによって高速・安定的にコンテンツが取得できるように配慮しています。FilecoinやArweaveといった複数のストレージの導入も検討します。
ノード・オペレーター（Validator/Storage Node）
DEAP Networkでは、バリデータノードがPoSのトランザクション検証とブロック生成を行い、正直な稼働実績に基づいて報酬を獲得する一方、ストレージノードはデータの保持・提供に専念して、量やアップタイムなどに応じた報酬を得ます。ノードの稼働実績や評判値はオンチェーンまたは専用ダッシュボードで可視化されるため、ユーザーは信頼性の高いノードを選択しやすくなっています。長期安定稼働のノードや正当性検証を適切に行うノードを優遇する設計を導入し、不正行為や長期ダウンに対してはステークの一部没収や報酬停止といったペナルティを適用することで、ネットワーク全体のセキュリティを高めています。
API・SDKモジュール
開発者向けには、DEAP Networkの核心機能（データの登録、アクセス管理、報酬計算など）を利用できるAPIやSDKが提供されます。JavaScript/TypeScript、Python、Go、Rustなどの主要言語に対応し、DApp開発者やサービスプロバイダが短期間で連携可能なライブラリを整備することで、エコシステム全体が拡大しやすい環境を構築します。Testnetやステージング環境も用意することで、開発者が安全に実験しながらアプリを開発できる仕組みを提供します。
アカウントモデル
DEAP Networkでは、ユーザーが任意のサービスと連携した行動データを主体的に管理し、さらに報酬を受け取れるようなアカウントモデルを採用しています。
Account Abstractionを活用することで、複数の署名方式やセキュリティポリシーを柔軟に組み合わせられるウォレットを提供し、紛失・盗難時におけるソーシャルリカバリといった高度な機能も利用可能です。
データが閲覧・利用されると、その対価としてのDEPトークンがスマートコントラクトを通じてウォレットに自動的に配分されます。仮登録を行ったユーザーがKYCを完了するとDEAP IDがオンチェーンに記録され、DEAP Network外部での取引所送金などの機能が解放される仕組みです。
KYCには最小限の個人情報しか要求されず、ZK技術を活用することで「KYC済み」である事実だけを証明し、詳細情報を公開しないまま利用可能にすることも視野に入れています。
ユーザーフロー
DEAP Networkに送信されたデータは、各ユーザー専用のWalletに紐づけられて保存されます。データを利用したい需要家は、DEP Coinを支払う必要があり、このDEP Coinはスマートコントラクトを通じてユーザーのWalletに配分されます。
ユーザーのWalletは、Account Abstractionによって作成されます。データ利用で得た収益を引き出す際には、アカウント連携とKYCを完了し、DEAP IDを作成する必要があります。
例えば、BobというユーザーがAというサービスで行動データを蓄積していた場合、まずBobはDEAP NetworkのポータルでIDを作成します。この時点では、どのWalletとも紐づいていません。その後、データ連携済みのサービス一覧から、自身が利用しているサービスを選び、ID認証を行います。
マイページでは、選択したサービスで得られたBobのリワードが蓄積されています。Bobはそこからリワードを引き出せるようになります。
データフロー
DEAP Networkにおけるデータの流れは、大きく「生成」「暗号化・署名」「アップロード」「オンチェーン記録」「検証・報酬」「閲覧・活用」のステップに分かれます。まず、ゲームアプリやスマートフォン、ウェアラブルなどで生成された行動データが、ローカル（端末やアプリケーション）で暗号化されてから分散ストレージにアップロードされ、IPFSなどのハッシュ（コンテンツID）を取得します。そのハッシュと必要なメタデータ（所有者情報、アクセスポリシー、報酬分配率など）をスマートコントラクトへトランザクションとして送信すると、バリデータが検証し、ブロックチェーンへ確定させます。ストレージノードは定期的に正しくデータを保持していることを証明し、PoS報酬とは別にストレージ報酬を受け取ります。ユーザーや開発者がデータを閲覧・取得する際には、独自インデクサーがブロックチェーンの最新情報を解析して検索APIを提供し、スマートコントラクトによるアクセス権限の確認とDEP支払いなどのプロセスを経て、ゲートウェイまたはP2Pで暗号化データを取得・復号します。データを参照するごとに報酬が自動分配され、アクセス履歴もオンチェーンに記録されるため、公平かつ追跡性の高い利用実態を実現します。
セキュリティモデル
データの機密性・プライバシー保護
DEAP Networkでは、ユーザー端末やサービス側で暗号化を完結させるエンドツーエンド暗号化を導入し、ネットワークが転送・保管するデータは常に暗号化された状態となります。加えて、ZK-SNARK/STARKなどのゼロ知識証明技術を応用し、「1万歩以上歩いた」や「ある学習コースを修了した」などの事実のみを証明し、具体的な履歴の詳細を一切開示しないまま検証可能な仕組みも将来的に備える予定です。こうした機密性重視のアプローチによって、ユーザーは自分のデータをコントロールしつつ、必要に応じて利用権限を安全に付与できます。
ストレージデータの真正性・改ざん防止
ストレージに保存されたデータとオンチェーンに登録されているハッシュ値が一致しているかを比較することで、改ざんを即座に検知できるようにしています。また、ユーザーやサービスプロバイダが秘密鍵で署名を施したデータのみを受け付けるため、誰がいつアップロードしたかを不正なく証明できます。データ収集経路でも署名リレーを行うことで、高度に分散した環境下でも改ざん検知がスムーズに働きます。
ストレージノード（コンテナノード）の健全性と耐攻撃性
ストレージノード（コンテナノード）は定期的に暗号学的な証明を要求され、データを正しく保管しているかを検証されることで報酬を獲得します。未保持や消失が確認されれば報酬は与えられず、悪意あるノードは排除されます。Sybil攻撃を防止するため、ノード参加には一定量のDEPをステークするか、長期稼働実績など経済的・評判的な担保が必要です。ネットワーク全体はIPFSのDHTに類似した仕組みやデータの冗長配置を採用し、単一ノードのダウンなど部分的な障害が発生しても自動ルーティングによってサービスを継続可能にします。
ガバナンス・コンプライアンス
提案から投票、実行に至るガバナンスプロセスをスマートコントラクトで管理し、手数料変更やアップグレードといった重要事項はコミュニティの合意によって決定されるようになっています。また、個人行動データを扱うため、必要に応じてGDPRやCCPAなど各国のデータ保護規制に準拠する機能を備え、KYC済みアカウントにのみ法定通貨への換金を許可するなどの段階的制限を導入することで、マネーロンダリングの防止にも配慮しています。