DePINの報酬不正対策｜署名だけでは防げない水増しとデータ品質の確かめ方

ある運営会社が、道路の画像を集めて地図データとして売るDePINを動かしています。参加者は車に専用の機器を付けて走り、撮った画像に応じてトークンで報酬を受け取ります。

あるとき、1台の車に機器を何台も積んでいる参加者が見つかりました。同じ走行の画像を、別々の機器から出していたのです。どのデータにも、登録済みの機器の正しい署名が付いています。署名を確かめるだけの仕組みでは、この参加者に何倍もの報酬を払ってしまいます。

機器の署名が示すのは「その鍵が送った」ことだけです。センサーが現実を正しく測ったことまでは示しません。では、運営会社は何を確かめてから報酬を払えばよいのか。

短く答えると、次の2つです。

• 品質の条件、時刻・位置、別の系統の観測、重複を、データごとに確かめる
• 報酬はすぐに払わず、確定の手続きと異議申立ての窓口を別に用意する

こうしておけば、機器の誤計測にも、意図的な不正にも同じ仕組みで備えられます。以下では、この運営会社が、測定から報酬の確定、異議申立て、復旧までを順に作っていく流れで見ていきます。需要の検証から本番運用までの開発工程の全体はDePINネットワークの作り方にまとめています。ここではそのうち「証明設計」と「精算」を詳しく扱います。

この記事でわかること

• 売れるデータの品質をどう決め、署名で何が分かり何が分からないか
• 報酬不正の5つの型と、それぞれを見抜く手がかり
• 報酬の確定・異議申立て・PoCで、二重払いと誤検知にどう備えるか

「売れるデータ」の品質は、何で決めるか

さきほどの運営会社が売る地図画像なら、確かめたい項目は次のとおりです。

• 撮影位置、時刻、画角
• 鮮度、重複率、読み取れるかどうか
• 対象の道路と対応しているか

車両の遠隔計測データを売る会社なら、項目は変わります。車両との結び付き、サンプリング間隔、単位、欠損率、位置と走行距離が合っているか、です。同じ未加工データでも、用途によって合格の条件は変わるのです。だから品質は、「正しそう」という総合点ではなく、顧客がお金を払うサービス単位ごとに決めます。

品質の観点は5つです。満たさないデータをどう扱うかまで、先に決めておきます。

判定ルールは、あとで変えることがあります。そのときも過去の報酬をどの条件で計算したかを再現できるよう、どの品質条件の版で、どんな理由で判定したかを、データ1件ごとに記録します。異常検知モデルの点数だけを判定の根拠にはしません。観点ごとに残す記録は、後半の「実装する人向けの詳細」にまとめています。

署名で分かること、分からないこと

署名は「その鍵が送った」ことを示します。しかし、センサーが現実を正しく測ったことまでは示しません。

機器側の守りを固めても同じです。セキュアエレメント（鍵を取り出しにくくする専用チップ）やリモート構成証明（リモートアテステーション。機器のソフトが改変されていないことを外から確かめる仕組み）は、鍵の抜き取りやソフトの改変を難しくします。けれども、それだけでは次のことを防げません。

• 機器の誤った設置や、センサーの遮蔽
• 参加者どうしの共謀
• 現実の場面を再現してだます攻撃

鍵の保管とリモート構成証明の作り方はDePIN機器のIDとリモートアテステーション設計で扱います。

ではどうするか。データが報酬になるまでの仕事を5つの段階に分け、段階ごとに誰が何を確かめるかをはっきりさせます。

1. 機器の登録：製造時のID、鍵の生成、所有者の変更、ファームウェアの版、失効を管理する。
2. データの受け取り：データごとの番号、増えていく連番、機器の時刻とサーバーの受信時刻、データ形式の版を付ける。再送されても結果が変わらない処理にする。
3. 中身の確認：物理的な制約、過去の履歴、近くの機器、通信網、需要者側の記録を突き合わせる。攻撃者が同時に操作しにくいデータ源を選ぶ。
4. 報酬の計算：確認を担うサービスは報酬額を直接書き換えず、版付きの判定だけを出す。報酬の計算は、承認済みの判定だけを読む。
5. 支払の確定：期間を締め、重複・上限・取消しを反映した集計結果をチェーンに記録する。記録するのはMerkle root（集計結果の要約値）か集計結果そのもの。

車両データのDePINであるDIMOの例を見てみます。ライセンス提案DLP-4では、機器の接続ごとに固有の署名鍵を割り当てます。そして、個々の接続がその鍵でデータに署名する構成が示されています（DIMO: DLP-4 Device Integration）。

ただ、この鍵で署名しても、示せるのは「その鍵が送った」ことだけです。そこで品質は、GPS、加速度、携帯網など、別の系統の観測と突き合わせて判定します。同じ攻撃でまとめて偽装できるデータ源なら、いくつ増やしても確かめたことになりません。だから別のデータ源は、同時に偽装できないかを見て選びます。

報酬不正には、どんな型があるか

不正は5つの型に分けられます。型ごとに、見抜くための手がかりが違います。

報酬の決め方にも、不正を招きやすい形があります。上の型に対応させると、避けたいのは次の5つです。

• ウォレットの数だけで決まる報酬（シビル攻撃を招く）
• 署名が有効なら毎回加算する報酬（再送・複製を招く）
• 1つのGPS信号だけに頼る判定（位置の偽装を招く）
• 取引量をそのまま貢献とみなす報酬（自己取引・共謀を招く）
• データ量や稼働時間だけで決まる報酬（低品質の量産を招く）

冒頭の運営会社の場面は、地図画像のDePINであるHivemapperが想定している不正に近いものです。公式Docsでは、AI生成画像や再送攻撃を想定しています。同じ場所・同じ時間帯の、独立した機器の観測を照らし合わせます。同一車両の複数機器や、よく似た経路のデータは重複として除き、報酬を二重に出しません（Hivemapper: Map Data Structure and Verification）。

ただし限界もあります。交通量の少ない地域では独立した観測が集まらず、正しいデータまで確定が遅れます。多数決を、何でも決められる真実の判定だと考えないことが大切です。

データは、どの順番で確かめるか

機械学習の点数は、見たことのないパターンを拾うのに役立ちます。ただ、点数だけで、取り消せない没収まで行うことはしません。決まった規則で判定できるものを先に処理し、点数は未知のパターンの候補を拾うのに使います。確かめる順番は、次の7段階です。

1. 受け取り：署名、データ形式、サイズ、時刻の範囲を調べる。データごとの番号で、重複登録を止める。
2. 形をそろえる：単位、座標系、機器の時刻を変換する。未加工データは変えず、変換後のデータと処理の版を別に持つ。
3. 決まった規則で判定：欠損、範囲、速度、連番、使用禁止のファームウェア、既知の重複を判定する。
4. ほかの記録と突き合わせ：履歴、近くの機器、通信・需要の記録と比べ、独立しているか、つじつまが合うかを見る。
5. 統計・機械学習：見たことのないパターンの候補を拾う。ただし、点数だけで、取り消せない没収はしない。
6. 判定：受理・却下・保留・要審査の4つに分ける。判定ルールの版と理由コード（判定理由を表す決まった記号）を保存する。
7. 報酬の計算：受理したデータをサービス単位にまとめる。品質係数、需要係数、重複の除外、期間の上限を当てはめる。

DePIN向けの基盤を提供するIoTeXも、確かめる難しさを挙げています。自己取引、仕事を終えずに報酬を狙う供給者、悪意ある応答です。そのうえで、機器の識別とオフチェーンの検証を組み合わせています（IoTeX: The DePIN Verification Problem）。

ゼロ知識証明などの方式は、何を誰から隠したいのか、どの計算が正しかったと示したいのかが決まって、はじめて要否を判断できます。方式を先に選ぶ必要はありません。

報酬はいつ確定させ、二重払いをどう防ぐか

不正の検知には誤検知がつきものです。提出直後に送金できる報酬を出してしまうと、あとで取り戻すのは困難です。

そこで報酬には、はっきりした段階を持たせます。

受信 → 確認中 → 受理／却下／保留 → 報酬見込み → 確定 → 支払済み

• 報酬の候補は、受理したデータからだけ作る。締めの期間中は再判定を認める。
• 報酬見込みは画面に出す見込み額にとどめ、送金できる資産とは区別する。
• 確定した精算バッチには、期間・判定ルールの版・入力と結果の要約値を残す。バッチには一意の番号を付ける。
• チェーンへの送信がタイムアウトしても、すぐには送り直さない。チェーン上に反映されていないと確かめられるまで待つ。
• 確定後の訂正では、履歴を書き換えない。次の期間での相殺、準備金、はっきりした取消しの記録で処理する。

未加工のセンサーデータや個人・位置情報を、チェーンに載せる必要はありません。削除・訂正・アクセス制御が必要なデータは、詳しい理由コードとともにチェーンの外に保存します。チェーンに記録するのは、みんなで確かめる必要がある最小限のものです。機器の登録簿、判定バッチの確約値、請求済みかどうかの状態です。

誤検知やルールの変更に、どう備えるか

「疑わしい」だけのデータを、「不正と確定した」データと同じに扱うとどうなるか。正しく運用している参加者が離れていきます。監視の担当者も、判定の理由を説明できなくなります。だから、この2つは別の状態にします。

異議申立ての受け付けには、次の情報を含めます。

• 対象のデータ、判定の理由、適用した判定ルールの版
• 出してもらえる追加の証拠、回答の期限、再審査の担当
• 再計算の対象になる精算バッチ

運用が健全かどうかは、次の5つの指標で見ます。数字が崩れたら、右の列の単位で原因を絞り込みます。

Heliumでは、それまで使っていた証明方式Proof-of-Coverageが2026年7月6日に廃止されました。関連データは履歴として参照できる形で残されています（Helium: Oracle Data File Format）。このように、証明の方式や報酬のルールも、ずっと同じとは限りません。

一度決めた方式を、永久に使い続ける前提にはしません。顧客にとっての価値、報酬の抜け道を突かれにくいか、検証にかかる費用を定期的に見直します。切り替えるときは移行期間を設け、過去の精算バッチを再現できるようにしておきます。

PoCでは、何を試せばよいか

ここまで見てきたとおり、判定は誤ることがあり、ルールも変わり、チェーンへの送信がタイムアウトすることもあります。そこでPoC（本番前の小さな試験運用）では、検知の精度だけでなく、失敗したときに元へ戻せるかも試します。

1. 評価用のデータを作る。正常なもののほか、欠損、重複、再送攻撃、時計のずれ、位置の跳躍、同一車両の複数機器、共謀を含める。
2. 不正の検知率に加えて、次の4つを測る。正常なデータの誤検知率、品質等級ごとの顧客の受け入れ率、判定にかかる時間、1件あたりの検証費。
3. 障害をわざと起こす。検証者の停止、外部データ源の遅れ、判定ルールの配布失敗、チェーンの混雑、送信のタイムアウトなど。
4. 同じ精算バッチを再実行しても、報酬の総額と請求結果が増えないことを確かめる。
5. 判定ルールの変更前後の結果を再現する。誤判定だったデータだけを再計算し、差額だけを精算できることを確かめる。
6. 異議申立てを実際に処理する。担当者が理由コードと記録から、判断を説明できるかを確かめる。

採用を判断するときは、検知の精度に加えて3つを見ます。

• 検証の費用が、サービス単位の粗利を超えないか
• 独立したデータ源が少ない地域でも、正常な参加者を扱えるか
• 侵害されたときに支払を止め、復旧できるか

サービス単位ごとの粗利の出し方はDePINの需要と単位採算の設計で扱います。1つの運営者が持つ、監査できるDBと現金での精算で要件を満たせるなら、ブロックチェーンを足さない構成も比べる対象になります。

設計レビューで確かめる10項目

1. 顧客が買うサービス単位と品質等級が決まっている。
2. 署名が示す範囲と、物理的な正しさの確認を別に扱っている。
3. データごとの番号、連番、ハッシュで、再送や重複が何度来ても1回分として扱える。
4. 突き合わせるデータ源が互いに独立しているか、同時に壊れないかを見ている。
5. 決まった判定ルール、統計モデル、人の判断のそれぞれの責任範囲がはっきりしている。
6. 判定理由と判定ルールの版から、過去の結果を再現できる。
7. 保留と不正確定を分け、異議申立てと回答期限がある。
8. 報酬の見込み・確定・支払を分け、二重の精算を防げる。
9. 未加工データをそのままチェーンに載せず、プライバシー・削除・保存期限を考えている。
10. 判定ルールの変更、検証者の停止、チェーン送信のタイムアウトから復旧できるかを試している。

実装する人向けの詳細

ここからは、運営会社で実際にデータモデルと精算処理を組む担当者の話です。

品質の観点ごとに残す記録

判定のたびに、次の記録を残します。あとで判定を説明し、再計算するための材料です。

品質条件の版はquality_contract_versionとして、判定理由とともに貢献イベントへ結び付けます。受け取り時の重複登録はevent_idで止めます。

判定と報酬の状態名

判定の4区分は、accepted（受理）、rejected（却下）、quarantined（保留）、needs_review（要審査）です。報酬までの状態遷移は次のとおりです。

received → validating → accepted | rejected | quarantined → reward_pending → finalized → paid

• 報酬候補はacceptedからだけ作る。
• reward_pendingは表示上の見込み額で、送金できる資産と区別する。
• 確定する精算バッチには、期間、判定ルールの版、入力集合のハッシュ、計算結果のハッシュ、一意なsettlement_idを持たせる。
• チェーンへの送信がタイムアウトしたら、トランザクション、nonce、コントラクトのイベントを突き合わせる。未反映と確かめられるまで再送しない。

関連する記事

DePIN全体の採用条件と開発工程はDePINネットワークの作り方、需要とトークン報酬の釣り合いはDePINトークノミクスの持続性評価、機器交換時の報酬の引き継ぎはDePIN機器の保守・交換・廃棄も参照してください。

XTELAができること

私たちは、サービス単位と品質契約を起点に、機器・バックエンド・検証・報酬をまたぐデータモデルを貴社と一緒に組み立て、判定ルールの版と理由コードから過去の報酬を再計算できる仕組みを実装します。再送攻撃や共謀を含む評価データを作り、同じ精算バッチを何度流しても支払が増えないことを確かめるPoCまで担います。設計の比較はお問い合わせからご相談ください。

主要参考資料

• Hivemapper: Map Data Structure and Verification（2026年9月24日確認）
• DIMO: DLP-4 Device Integration（同日確認）
• IoTeX: The DePIN Verification Problem（同日確認）
• Helium: Oracle Data File Format（同日確認）

資料の確認日と注意

仕様と資料は2026年9月24日に確認しました。技術・運用設計の一般情報です。各プロトコルの仕様、報酬ルール、データ保護・規制要件は変わるため、導入時点の公式資料と専門家の確認が必要です。