メインコンテンツへスキップ
NetsujoNetsujo Inc.

NETSUJO LAB 001 — TRUSTED EXTERNAL DATA

ブロックチェーンのオラクル問題を、
「外部API接続」ではなく「信頼設計」として捉え直す。

スマートコントラクトに外部データを渡すとき、問題はAPIへ接続できるかではありません。その値を、なぜ信頼できるのか。誰が確認し、どの証拠を残し、異常時に誰が止めるのか。Netsujo Labは、複数ソース検証、信頼スコア、人間レビュー、監査ハッシュを組み合わせたOracle Agentの参照設計を公開します。

STATUS
REFERENCE ARCHITECTURE
STAGE
DESIGN / LOCAL MVP SPECIFICATION
PRODUCTION
NOT YET
VERSION
0.1.0
参照アーキテクチャを見る設計書を読むオラクル設計を相談する

OFF-CHAIN WORLD

不確実な外部世界

  • API A
  • API B
  • CSV
  • Manual evidence
  • Signed data
  • Sensor / location / inventory

ORACLE DECISION LAYER

検証と判断のレイヤー

  • Normalize
  • Schema validation
  • Freshness validation
  • Source agreement
  • Signature validation
  • Trust score
  • Human review
  • Audit hash

ON-CHAIN CONTRACT

検証可能な最小証跡

  • approved value
  • observedAt
  • sourceCount
  • trustScore
  • auditHash
図: オフチェーンの不確実な情報は、検証・判断のレイヤーを通過して初めて、オンチェーンの最小証跡になります。本研究ページ全体がこの3領域を軸に構成されています。

— EXECUTIVE SUMMARY

オラクル問題の本質は、ブロックチェーンの外側にある「事実」を、ブロックチェーン自身では検証できないことです。

— 定義

オラクル問題とは、スマートコントラクトがブロックチェーン外部の事実を直接確認できず、外部データの取得元、正確性、鮮度、改ざん耐性、責任主体を別途設計しなければならない問題です。

  1. 1スマートコントラクトは、外部世界の事実を自力で確認できない
  2. 2データソースを複数にしても、真実が保証されるわけではない
  3. 3必要なのは、ソースの多重化、鮮度、乖離、署名、履歴、責任分界を組み合わせた信頼設計である
  4. 4LLMは異常説明やレビュー補助には使えるが、最終的な真偽判定者にしてはいけない
  5. 5オンチェーンにはrawデータを大量保存せず、値、時刻、ソース数、判定、監査hashなど最小限の証跡を載せる

— オラクル問題とは

スマートコントラクトは、現実世界を自分では見られない。

結論から言うと、スマートコントラクトが一般的なWeb APIを任意に直接参照する構造は成立しません。ブロックチェーンは、ネットワーク参加者が同じ入力から同じ結果を再現できる必要があります。一方、外部APIの結果は、取得時刻、接続先、地域、障害、改ざんで変わり得ます。全員が同じ答えを再現できない入力は、合意形成を壊してしまうためです。

そこで、外部情報を取得し、検証し、オンチェーンへ渡す仕組みが必要になります。これがオラクルです。

現実世界の事実

↓

API / センサー / 管理者 / 署名者

↓

オラクル

↓

スマートコントラクト

オラクルは「真実を自動的に作る装置」ではありません。外部情報をどの条件で採用するかを設計した境界レイヤーです。

— 本研究の中心メッセージ

オラクル問題は、正しいAPIを一つ選ぶ問題ではない。

本質は、外部世界の不確実な情報を、どの程度の証拠、検証、責任分界でスマートコントラクトへ渡すかというガバナンス設計です。

01データソースの多重化
02検証過程の記録
03人間レビューの挿入余地
04署名・監査ログ・hashによる説明責任
05LLMを真実判定者にしない
06オンチェーンには最小限の証跡のみ載せる

この6つの設計原則を、以降のすべてのセクションで繰り返し参照します。

— THREAT MODEL

何を防ぐ設計なのか。

この参照設計は、次の8つの脅威への対応を目的にしています。逆に言えば、この表にない脅威（経済インセンティブ設計や談合耐性など）は本研究の対象外です。

脅威例対応方針
データ改ざんAPIレスポンスの書き換え署名確認、複数ソース、raw response保存
単一障害点1社API停止requiredSources、代替ソース
価格操作薄い市場の瞬間価格中央値、乖離率、時間窓
古いデータキャッシュ・通信遅延observedAt / fetchedAt、鮮度閾値
投稿者不正管理鍵の悪用allowlist、multi-sig、権限分離
API形式変更field名・型の変更zod schema validation
ブラックボックス化採用理由を説明できないdecision reason、audit log
LLM幻覚存在しない値の生成LLMをデータソースにしない

— HYPOTHESIS

外部データは「取得」ではなく「証拠の束」として扱う。

単一の値を直接オンチェーンへ渡すのではなく、複数ソース、観測時刻、乖離、署名、履歴、判定理由を一つの証拠パッケージとして扱えば、完全な真実保証はできなくても、採用判断の透明性と監査可能性を高められる。

研究対象

price / weather / inventory / event / generic

研究対象外

  • 経済インセンティブを含むDON全体の安全性証明
  • Byzantine fault toleranceの形式検証
  • 市場操作耐性の実証
  • 本番資産を扱うオラクル運用
  • TEE / ZKの実装検証

— REFERENCE ARCHITECTURE

取得、検証、判断、証跡を分離する。

Oracle Agentは、取得・正規化・検証・スコアリング・判定・出力を分離したパイプラインです。各ノードを開くと、入力・処理内容・出力・失敗条件・責任主体を確認できます。どのレイヤーで失敗しても、その理由が監査ログに残ることが設計の中心です。

HUMANUser / Admin
INPUT
事業要件（対象データ・許容乖離・鮮度・レビュー閾値）
PROCESS
OracleRequestの発行とpolicyの決定
OUTPUT
OracleRequest
FAILURE
policy設計の誤り（閾値が用途に合っていない）
責任主体
事業責任者・管理者
AGENTOracle Agent
INPUT
OracleRequest
PROCESS
取得〜判定までのオーケストレーションと監査ログ記録
OUTPUT
OracleDecision / Audit Log
FAILURE
エージェント自体の停止（単一障害点にしない運用設計が必要）
責任主体
システム運用者
OFF-CHAINData Source Connectors
INPUT
OracleRequest（対象・ソース定義）
PROCESS
allowlist内の各ソースへ取得を実行し、raw responseを保存
OUTPUT
SourceResult[]
FAILURE
取得失敗、タイムアウト、allowlist外ドメイン
責任主体
各データソース提供者＋コネクタ実装者
VALIDATIONNormalization Layer
INPUT
SourceResult[]（raw）
PROCESS
単位・型・時刻表現の正規化
OUTPUT
正規化済みSourceResult[]
FAILURE
単位不明・型変換不能
責任主体
コネクタ実装者
VALIDATIONValidation Engine
INPUT
SourceResult[]
PROCESS
schema / source agreement / freshness / threshold / signature
OUTPUT
ValidationResult
FAILURE
型不一致、必要ソース数不足、許容乖離超過、データ鮮度超過
責任主体
検証ロジック設計者
VALIDATIONTrust Scoring Engine
INPUT
ValidationResult＋ソース履歴
PROCESS
多様性・合意・鮮度・履歴の重み付き合成と異常減点
OUTPUT
TrustScore（内訳付き）
FAILURE
履歴不足時の初期値扱い、重み設定の誤り
責任主体
スコア設計者（重みは用途ごとに責任を持って調整）
DECISIONDecision Layer
INPUT
TrustScore＋policy
PROCESS
approved / needs_human_review / rejectedの判定と理由生成
OUTPUT
OracleDecision
FAILURE
判定は必ず返す（迷う場合はレビューへ回す設計）
責任主体
自動判定＋閾値帯は人間レビュー担当者
ON-CHAIN / RECORDOutput
INPUT
OracleDecision
PROCESS
JSON Record・Audit Log・Human Review Request・Blockchain Submission Payloadの生成
OUTPUT
approved時のみ投稿payload（それ以外はblocked）
FAILURE
approved以外での投稿試行（投稿レイヤーで拒否）
責任主体
投稿者（allowlistアドレス・重要データはmulti-sig）
図: 取得・検証・判断・証跡を分離したOracle Agentの参照アーキテクチャ。各ノードを開くと、入力・処理・出力・失敗条件・責任主体を確認できます。

— DATA MODEL

証拠パッケージを構成する5つの型

依頼（OracleRequest）から判定（OracleDecision）まで、証拠がどのように構造化されるかを重要フィールドで示します。完全な型定義は設計書（Markdown）に掲載しています。

OracleRequest

何を・どの条件で取得するかの依頼

idリクエスト識別子
oracleType'price' | 'weather' | 'inventory' | 'event' | 'generic'
target対象（例: ETH/USD、倉庫Aの在庫）
requiredSources採用に必要な最小ソース数
maxSourceDeviationRate許容乖離率
freshnessThresholdSec鮮度閾値（秒）
humanReviewThreshold人間レビューへ回すスコア閾値
createdAt作成時刻

SourceResult

各ソースからの取得結果（raw込みの証拠）

sourceId / sourceName / sourceTypeソース識別情報
value / unit観測値と単位（精度保持のため値は文字列）
observedAt元データの観測時刻
fetchedAt取得時刻。observedAtと必ず分離する
rawDataraw response（オフチェーン保存のみ）
success / error取得成否と失敗理由

ValidationResult

検証の合否と根拠

isValid検証全体の合否
errors / warnings却下要因とレビュー要因の区別
sourceAgreementRate許容乖離内で合意したソースの割合
deviationRate中央値基準の乖離率
freshnessOk鮮度閾値内か

TrustScore

採用判断の補助指標（真実度ではない）

totalScore重み付き合成スコア（0〜100）
sourceDiversityScoreソース多様性
sourceAgreementScoreソース間合意
freshnessScore鮮度
historicalReliabilityScoreソースの履歴信頼度
anomalyPenalty異常による減点
requiresHumanReview人間レビュー要否

OracleDecision

最終判定と監査証跡

status'approved' | 'needs_human_review' | 'rejected'
finalValue採用値（中央値ベース）
trustScore / validationスコアと検証結果への参照
reason判定理由（人間が読める形式）
auditHash監査ログのハッシュ
createdAt判定時刻

— VALIDATION ENGINE

値だけではなく、値が成立した条件を検証する。

1. Schema Validation

外部レスポンスをzodで検証します。型・必須項目・日時形式が不正なデータは、値の中身を見る前に採用候補から外します。API仕様の静かな変更を最初に検知する層でもあります。

2. Source Agreement

価格データの例:

maxDeviationRate = abs(max - min) / median

基準に中央値を使うのは、平均値より外れ値の影響を受けにくいためです（分母は中央値の絶対値。気温のように値が0近傍になり得るデータでは、比率ではなく絶対差の閾値を使う設計が必要です）。ただし、中央値も真実を保証しません。過半数のソースが同じ誤情報を返せば、中央値はその誤情報になります。

3. Freshness Validation

now - observedAt <= freshnessThresholdSec

fetchedAt（取得時刻）とobservedAt（観測時刻）を分けます。取得した時刻が新しくても、元データの観測時刻が古い可能性があるためです。キャッシュされた古い値を「新鮮な取得」と誤認しないための分離です。

4. Threshold Validation

閾値は用途ごとに異なります。以下は固定ルールではなく設計例です。

oracleType許容乖離の例鮮度の例
price0.5〜2.0%60〜300秒
weather5〜10%1800〜3600秒
inventory原則0%300〜3600秒
event0〜5%3600秒〜1日

上記は参照値です。資産規模、更新頻度、障害時の影響、データ取得方式に応じて個別設計が必要です。

— TRUST SCORE

信頼スコアは「真実度」ではなく、採用判断の補助指標。

totalScore =
  sourceDiversityScore * 0.20 +
  sourceAgreementScore * 0.30 +
  freshnessScore * 0.20 +
  historicalReliabilityScore * 0.20 -
  anomalyPenalty * 0.10
スコア判定
80以上approved
60〜79needs_human_review
59以下rejected

この重みと閾値は研究用の参照設計です。スコアは外部世界の真実を保証しません。用途ごとの損失許容度、データ更新頻度、ソース構成、法的責任に応じた調整が必要です。

だからこそ、スコアを単一のゲージとして見せるのではなく、内訳・理由・警告を必ず併記します。後述のシミュレーターでも同じ方針です。

— DECISION FLOW

判定フロー

判定は「必ず理由付きで返す」ことを優先します。迷うケースは自動承認せず、人間レビューへ回します。

requiredSourcesを満たすか

NO → rejectedYES → 次の検証へ

schema validationを通過するか

NO → rejectedYES → 次の検証へ

鮮度・乖離・署名に問題があるか

HIGH RISK → rejectedREVIEWABLE → needs_human_reviewNO → approved候補

trust scoreとpolicyを確認

approvedneeds_human_reviewrejectedのいずれかを理由付きで返す（OracleDecision生成）
図: 判定フロー。approvedであっても、重要データではmulti-sigや人間レビューを追加できる設計とします。

— ORACLE DECISION SIMULATOR

判定がどう変わるか、手を動かして確かめる。

ソース数、値、観測時刻、失敗状態を変更すると、検証・信頼スコア・判定がどう変わるかを確認できます。すべて例示用データのローカル計算で、入力値が外部へ送信されることはありません。

STATIC EXAMPLE — シナリオ「One outlier」の実行例（例示用データ）

入力

  • Source A: 3760.12（30秒前・署名あり）
  • Source B: 3761.05（45秒前・署名あり）
  • Source C: 3916.00（25秒前・署名あり）
  • policy: requiredSources=3 / 許容乖離2% / 鮮度300秒

出力

NEEDS HUMAN REVIEW

  • normalizedValue（中央値）: 3761.05
  • deviationRate: 4.14%
  • trust score: 62 / 100

警告があるため自動承認せず、人間レビューへ回します（trust score 62）。

1ソースだけが中央値から大きく乖離すると、値そのものは取得できていても自動承認されず、人間レビューまたは却下へ回ります。

— HUMAN REVIEW

自動化できない判断を、曖昧なまま残さない。

レビュー閾値帯の判定は、ReviewAgentが「何が問題か」「どのソースが乖離しているか」「なぜ自動承認できないか」を整理し、承認・再取得・却下の選択肢と推奨アクションを提示します。判断者・判断時刻・判断理由は監査ログに残ります。

STATUS: NEEDS HUMAN REVIEW

REASON

Source C is 6.8% above the median and exceeds the allowed deviation rate of 2.0%.

RECOMMENDED ACTIONS

  1. Source Cを再取得
  2. 代替ソースを追加
  3. 市場停止・異常相場を確認
  4. 判定を却下
図: 人間レビュー要求のUI例。レビュー担当者の判断材料までを自動生成し、最終判断は人間が担います。

— LLM BOUNDARY

AIは説明者になれる。しかし、真実の判定者にはしない。

AIとWeb3の両方を扱う会社として、Netsujoはこの境界を明確にします。LLMには幻覚のリスクがあり、検証データの生成者や最終判定者に置いた瞬間、監査可能性が崩れます。

任せてよい

  • ソース間差分の説明
  • 人間レビュー向けの要約
  • 異常理由の仮説出し
  • データソース候補の提案
  • audit logの自然言語化

任せてはいけない

  • 最終的な真偽判定
  • 価格データの生成
  • APIレスポンスの代替
  • 署名検証の代替
  • オンチェーン投稿の自動承認

— ON-CHAIN FOOTPRINT

すべてをオンチェーンに載せるのではなく、検証可能な最小証跡を残す。

オンチェーン保存コスト、プライバシー、更新頻度、削除不能性を考慮し、raw responseや個人情報は直接載せません。投稿できるのはapprovedの判定だけで、payloadは次の形を想定しています。

{
  "requestId": "oracle_20260521_001",
  "oracleType": "price",
  "target": "ETH/USD",
  "value": "3760.12",
  "unit": "USD",
  "observedAt": "2026-05-21T10:00:00Z",
  "trustScore": 87,
  "sourceCount": 3,
  "auditHash": "0x..."
}
  • 投稿者アドレスを制限（allowlist）
  • payload hashを保存
  • raw dataはオンチェーンに載せない
  • オフチェーン監査ログのhashのみオンチェーンへ記録
  • 重要データはmulti-sig承認
  • approved以外は投稿しない

— FAILURE TEST MATRIX

正常系より、失敗時の設計を先に公開する。

この設計で重視するのは「正常に動くこと」より「失敗が説明可能な形で止まること」です。ローカルMVPで検証対象とする10ケースを公開します。

#InputExpected validationExpected decisionExpected logOn-chain
13ソースのうち1つが極端に乖離乖離超過を検出（中央値基準）needs_human_review / rejected乖離ソース名と乖離率を記録blocked
2観測時刻（observedAt）が古いfreshnessOk = falserejected鮮度超過の秒数を記録blocked
3requiredSources未達ソース数不足エラーrejected有効ソース数と必要数を記録blocked
4API取得失敗success=falseを除外して再評価残存ソース数に依存失敗ソースとエラー内容を記録条件付き
5normalizedValue不正schema / 型エラーrejected不正値のraw responseを保存blocked
6trustScoreがレビュー閾値未満検証は通過needs_human_reviewスコア内訳と理由を記録blocked
7approved以外でpayload投稿を試行—投稿レイヤーで拒否拒否イベントを記録blocked
8API schema変更zod検証エラーrejectedスキーマ差分を記録blocked
9署名欠落signature警告 / エラーpolicy次第でreview / rejected未署名ソースを記録blocked
10allowlist外ドメインコネクタ層で拒否ソース除外として扱う拒否ドメインを記録blocked

— APPLICATIONS

価格オラクルだけではない。企業の実世界データへ応用する。

この参照設計が主に想定するのは、汎用フィードが存在しない企業固有のデータです。各ユースケースで「何をオンチェーンへ載せるか」より先に、次の6つを問います。

  1. 1.誰が事実を観測するか
  2. 2.観測者が不正をする動機はあるか
  3. 3.何件の証拠が必要か
  4. 4.どの程度の鮮度が必要か
  5. 5.誤判定時の損失は何か
  6. 6.誰が停止・再判定できるか

RWA / 在庫証明

実物資産の在庫数、倉庫保管証明、鑑定データ、償還処理、監査証跡

RWA（実物資産トークン化）ガイド →

観光 / 地方創生

現地来訪証明、QR読み取り、GPSチェックイン、店舗利用、イベント参加

自治体・公共向け支援 →

コミュニティ / SBT

イベント参加、LT登壇、アンケート回答、connpass / Discord / Google Form連携

コミュニティ活動 →

地域通貨 / ステーブルコイン

決済実績、加盟店利用、ポイント付与条件、外部価格・為替データ

Web3コンサルティング →

DePIN / YaseiGrid

センサー観測値、検知時刻、位置情報、複数ノードの一致、誤検知レビュー、報酬条件

YaseiGrid（鳥獣検知DePIN・R&D） →

— POSITION

既存の分散型オラクルネットワークとの関係

本研究は、既存の分散型オラクルネットワークを置き換えるものではありません。汎用的な価格フィードや外部計算には既存サービスを利用する方が合理的な場合があります。Netsujoの参照設計は、企業固有の在庫、イベント、来訪、業務データなど、既存の汎用フィードだけでは扱いにくい外部データについて、取得・検証・責任分界・監査を整理するためのものです。

Chainlink・Pyth等の各ネットワークの仕様は、参考文献に挙げた各社一次資料をご確認ください。本ページでは優劣の断定やランキングは行いません。

— LIMITATIONS

この設計でも、外部世界の真実を完全には保証できない。

誠実な研究であるために、この設計が抱えたままの限界を隠さず並べます。ここに挙げた項目は、導入判断の際のリスク整理のたたき台として使えます。

  • 複数ソースが同じ誤情報を参照する可能性
  • 独立して見えるソースが同じ一次ソースに依存する可能性
  • 署名は送信者を証明しても、内容の真実性までは証明しない
  • 人間レビュー担当者が不正・誤判断する可能性
  • trust scoreの重みが誤っている可能性
  • 突発的な市場変動と攻撃の区別
  • オンチェーン反映までの遅延
  • 経済インセンティブと談合耐性
  • 規制・契約上の責任分界

— RESEARCH ARTIFACTS

研究成果物

公開研究として、成果物は登録なしで直接読めます。ローカルmock MVPの実装・テスト結果・リポジトリは、公開でき次第このカードに追加します（存在しないものは載せません）。

Markdown / v0.1.0 / 公開中

Oracle Agent参照設計書

最終更新: 2026-07-05

直接読む →

PLANNED

GitHubリポジトリ / テスト結果 / JSONサンプル

ローカルmock MVPの実装後に、package version・test results・coverage・commit hash・licenseとあわせて公開予定です。

— AUTHOR / CHANGELOG

著者・レビュー・更新履歴

この記事の著者

飯田 友広

飯田 友広

代表取締役

Netsujo株式会社 代表取締役。京都発のWeb3・AI実装スタートアップを2023年6月に創業。京都府ワーキンググループ「Chain UP KYOTO」参画(2026-03-10)、京都美術工芸大学での講義・龍谷大学でのセミナー実績、ITコミュニティ「みやこでIT」(connpassメンバー592名・イベント158回以上・2019年2月から運営・2026年6月時点)運営。NPO法人NEMTUS理事、BAR KRYPTO運営。ソーシャル企業認証「S認証」認証企業(2026年2月認証・2026年4月公表)。技術領域はWeb3/ブロックチェーン/DID/NFT/生成AI/コミュニティ運営。

プロフィールを見る
Published2026-07-05
Last updated2026-07-05
Version0.1.0
Research statusREFERENCE ARCHITECTURE
Implementation statusDESIGN / LOCAL MVP SPECIFICATION
Test statusローカルMVPのテストは未公開（公開後に本表を更新）
Production usageNOT YET
Technical reviewPending

Changelog

  • v0.1.0（2026-07-05）— Initial reference architecture published

外部データをオンチェーンへ渡す前に、
「誰が、何を、なぜ信じるか」を設計する。

Netsujoは、オラクルネットワークそのものを販売する会社ではありません。事業要件に合わせて、どのデータを、誰の責任で、どこまで検証し、どの証跡をオンチェーンへ残すかを整理し、PoCと実装仕様へ落とし込みます。

オラクル設計を30分相談するWeb3 PoC設計パッケージを見るスマートコントラクト発注前監査を見る

— REFERENCES

参考文献

— FAQ

よくある質問

ブロックチェーンのオラクル問題とは何ですか？

スマートコントラクトがブロックチェーン外部の事実を直接確認できず、外部データの取得元、正確性、鮮度、改ざん耐性、責任主体を別途設計しなければならない問題です。技術の欠陥ではなく、決定論的なシステムが外部世界と接続する境界に必ず生じる設計課題です。

スマートコントラクトはなぜ外部APIを直接呼べないのですか？

ネットワークの全参加者が同じ入力から同じ結果を再現できる必要があるためです。外部APIの結果は取得時刻・接続先・障害・改ざんで変わり得るため、任意のWeb APIを直接参照する構造は合意形成と両立しません。

複数のAPIを使えばオラクル問題は解決しますか？

解決しません。複数ソースは単一障害点を減らしますが、全ソースが同じ誤情報や同じ一次ソースに依存する可能性は残ります。多重化に加えて、鮮度・乖離・署名・履歴・責任分界を組み合わせた信頼設計が必要です。

Chainlinkを使えば独自設計は不要ですか？

汎用的な価格フィードには既存の分散型オラクルを使う方が合理的な場合が多いです。一方、企業固有の在庫・来訪・イベント・業務データは汎用フィードが存在しないことが多く、取得・検証・責任分界を個別に設計する必要があります。

信頼スコアが高ければデータは正しいのですか？

いいえ。信頼スコアは「真実度」ではなく採用判断の補助指標です。ソース多様性・合意・鮮度・履歴から算出しますが、外部世界の真実は保証しません。だからこそ内訳と理由を記録し、閾値帯では人間レビューを挟みます。

AIやLLMでオラクル問題を解決できますか？

できません。LLMは異常の説明やレビュー補助には有効ですが、幻覚のリスクがあるため真偽の最終判定者やデータソースにしてはいけません。本研究ではLLMの役割を「説明者」に限定しています。

RWAではどのような外部データが必要ですか？

実物資産の在庫数、倉庫保管証明、鑑定データ、償還処理の完了など、トークンの価値の裏付けとなる実世界の事実です。これらは汎用価格フィードでは扱えないため、観測者・証拠数・鮮度・監査証跡の個別設計が必要になります。

オラクルの監査ログには何を残すべきですか？

各ソースのraw response、観測時刻と取得時刻、検証の合否と理由、スコア内訳、最終判定と判断者です。後から「なぜこの値を採用したか」を第三者が追跡できることが目的で、ログ全体のhashをオンチェーンへ残します。

rawデータをオンチェーンへ保存するべきですか？

原則、保存すべきではありません。保存コスト、プライバシー、削除不能性の問題があるためです。オンチェーンには採用値・観測時刻・ソース数・判定・監査hashなど検証可能な最小証跡だけを載せ、rawはオフチェーンで保管します。

Netsujoはどこまで支援できますか？

オラクルネットワーク自体の販売ではなく、事業要件の整理からの支援です。どのデータを、誰の責任で、どこまで検証し、どの証跡をオンチェーンへ残すかを整理し、PoC設計と実装仕様へ落とし込みます。構想段階からご相談いただけます。

ブロックチェーンは、記録されたデータを強く守れます。
しかし、そのデータが現実世界で正しかったかまでは、自動では証明できません。

だから必要なのは、チェーンへ書き込む前の設計です。
誰が観測し、何件の証拠を集め、どの条件で採用し、異常時に誰が止めるのか。

Netsujoは、この責任分界をPoCと実装仕様へ落とし込みます。

オラクル・外部データ連携を相談する
無料で相談する