チェーン間の分析

（セクション： エコシステムとネットワーク）

1）インターチェーン分析とは何か、なぜ必要なのか

クロスチェーン分析は、複数のチェーン、ブリッジ、プロバイダ、アプリケーションからのテレメトリーとイベントを単一のデータモデルに統合する方法論およびスタックです。目的：

価値と活動の統一された会計：ボリューム、流動性、手数料、保持。
ブリッジとP2P接続の可視性：ファイナライゼーション、ラグ、再編/チャレンジイベント。
トラフィックと変換属性：cheyn→cheyn、 kanal→produkt。
リスクとコンプライアンス：AML、制裁、行動詐欺、エンティティの識別。
意思決定：OKR/予算、制限、更新および流動性規制。

2）データソースとイベント（正規リスト）

1.チェーン/レジスタ：ブロック、トランザクション、イベントログ、スマートコントラクトの状態。
2.ブリッジ：アプリケーション、領収書、証拠（光/楽観的/ZK）、最終化状態。
3.決済プロバイダ/CCS：小切手、限度額、支払いステータスを渡す。
4.製品イベント：オンボーディング、預金/賭け/結論、ゲームおよび行動指標。
5.P2Pトランスポート：パブ/サブレシート、RPC成功、レイテンシ。
6.参考文献：ネットワーク、資産、小数、chainId、契約アドレス、SDKバージョン。

💡 各ソースについて、修正：scheme、 update log、「finalization window」、 owner、 SLO。

3）データアーキテクチャ（ストリームとストレージ）

Ingest（ストリーミング）：ノード/インデックスへのコネクタ、Webhooksブリッジ、オペレーティングデータベースからのCDC。
Raw （Bronze/Raw）：ソースメタデータで'observed_at'とラベル付けされた不変のバッチ。
Clearing/Normalization （Silver）： dedup、 semantic enrichment、 timezone alignment、 asset mapping。
カーネルモデル（Gold/Core）：統一ファクト'転送'、'ブリッジ'、'onchain_events'、 'kyc_status'、 'payout'。
Marts：ファイナンス（GTV/TVL/テイクレート）、製品（保持/漏斗）、リスク（スコアリング）、オペレーティングシステム（SLO）。
キャッシュ/サーブ：ダッシュボードとAPIのOLAP/HTAP、および/txアドレスの別の検索。

Transport： Kafka/Pulsar（正確に1回のセマンティクスをidempotency）、原材料のオブジェクトストレージ、分析用の寄木細工/カラム形式。

4）ファイナライズ、再オーグ、idempotence

イベント状態は'observed'→'confirmed （k）'→'finalized'→'invalidated （reorg）'です。
K-confirmations rule-ネットワーク/アセットタイプで構成されます。
楽観的/チャレンジウィンドウ：ブリッジの「競合」ステータスをサポートします。
Idempotency： 'idempotency_key=chainId' block 'tx' logIndex'トピック'（またはペイロードハッシュ）。
リプレイ：スケジュールされたバックフィルとインデックス変更のリカバリ。

5）エンティティ解像度モデル

アドレス→アクター：アドレス、キー、財布↔アカウント/組織/プロバイダー。
クロスチェーングラフ：1人の所有者による関係（ヒューリスティクス、署名、オンボーディングデータ）に対処します。
信頼レベル：ハードリンク（KYC、オンチェーン署名）、ソフトリンク（行動相関）。
エイリアス：アナリティクスにPIIの代わりに安定した識別子（PID）を格納します。

6）統一イベント図（簡略化）

yaml event:
id: string # global UUID observed_at: timestamp # when they saw chain_id: string # 'eth-mainnet', 'solana-mainnet',...
block_height: long tx_hash: string log_index: int event_type: string    # transfer    bridge. lock    bridge. mint    kyc. pass    payout. done...
status: string      # observed    confirmed    finalized    invalid actor_src: string # address/peer-id/source organization actor_dst: string # address/peer-id/destination organization asset: string # canonical symbol (e. g., USDC), + decimals amount: decimal usd_value: decimal # rate normalization at the observed_at bridge_ref: string # link with the application/receipt of the metadata bridge: object # network/contract/version/gac/fee, etc.
idempotency_key: string

7）資産・物価の正常化

正規のアセットディレクトリ：シンボル、小数点、チェーンマッピング、コントラクトのアドレス。
FX正規化：'observed_at'タイムスタンプでの過去のレートと資産価格。
マルチアクティブバンドル：グループ「ラップ」とネイティブアセット。

8）主な指標とショーケース

8.1ファイナンスと流動性

ネットワーク/アセット/ブリッジ上のGTV （Gross Transaction Volume）。
橋およびプール上のTVLそして網の流れ。
料金/容積料金を取って下さい；転送するための費用対効果。
Payout SLAヒット率、Finality p50/p95、保留中のBacklog。

8.2プロダクトおよびユーザー

クロスチェーンMAU/DAU （dedup PID）、

保持D1/D7/D30マルチチェーン活動を考慮し、

ファネル：入力ネットワーク→ブリッジ→ターゲット製品→アクション。
QoT（トラフィック品質）：不正防止後のトラフィック検証。

8.3リスクとコンプライアンス

詐欺/紛争率、高リスクスコア％、制裁ヒット％。
翻訳パターン、ベロシティチェック、クラスタリングによる異常率。
KYB/KYCのパス％とタイミング。

8.4オペレーティングシステムおよびSLO

ブリッジサクセスレート、p95 Finality、リレー可用性、

Reorg/Challengeイベント、Error budget burn。

9） SQL/Pseudoクエリの例

回路ペアによるGTV

sql
SELECT src. chain_id AS src_chain,
dst. chain_id AS dst_chain,
date_trunc('day', e. observed_at) AS d,
SUM(e. usd_value) AS gtv_usd
FROM events e
JOIN bridges b ON e. bridge_ref = b. id
JOIN networks src ON b. src_chain_id = src. id
JOIN networks dst ON b. dst_chain_id = dst. id
WHERE e. status = 'finalized' AND e. event_type IN ('bridge. lock','bridge. mint','transfer')
GROUP BY 1,2,3;

クロスチェーン保持D7

sql
WITH first_touch AS (
SELECT pid, MIN(observed_at) AS t0
FROM product_events
WHERE event IN ('signup','first_deposit')
GROUP BY pid
),
week_activity AS (
SELECT DISTINCT pid
FROM product_events pe
JOIN first_touch ft USING(pid)
WHERE pe. observed_at BETWEEN ft.t0 + INTERVAL '1 day'
AND ft.t0 + INTERVAL '7 day'
)
SELECT 100. 0 COUNT() / (SELECT COUNT() FROM first_touch) AS d7_retention_pct
FROM week_activity;

SLOブリッジショーケース

sql
SELECT date_trunc('hour', observed_at) AS h,
100. 0 SUM(CASE WHEN status='finalized' THEN 1 END)/COUNT() AS success_rate,
percentile_cont(0. 95) WITHIN GROUP (ORDER BY (finalized_at - observed_at)) AS p95_finality_min,
SUM(CASE WHEN challenge_event THEN 1 END) AS challenges
FROM bridge_events
WHERE observed_at >= now() - INTERVAL '7 days'
GROUP BY 1;

10）アトリビューションとマルチチャンネルパス

ネットワークソース、ブリッジ、製品の重みを備えたラストタッチ/ポジションベースのモデル。
UTM→On -chain：初期登録時にonchainアドレスにクリック/紹介を関連付ける（同意を得て）。
連想モデル：Shapley/Markov for complex set→most→produkt paths。

11）詐欺防止と行動シグナル

グラフの特徴：一般的な取引相手、円形の転送、迅速な売上高。
速度制限と異常：バースト、量の「分割」、ナイトクラスタ。
ブリッジ詐欺スキーム：再送信、KYCバイパス試行、流動性のあるサンドイッチパターン。
モデル：グラデーションブースト/グラフ埋め込み；インシデントマーキングを教えてくれ。

12）プライバシーとコンプライアンス（プライバシー・バイ・デザイン）

PII最小化：直接識別子の代わりにPID、トークン化。
データレジデンシー：地域別の分割、暗号化「at rest/on the road」。
削除する権利：証明可能性を持つ墓石/redactionイベント。
アクセスと監査：ロールACL、ログの読み取り、チェックのための署名されたレポート。

13）分析パイプラインのためのSLI/SLO

SLI（例）：

鮮度（'observed_at'からゴールドの外観までの平均遅延）、
完全性（K-確認によって期待されるように穴のないイベントの％）、
Correctness（スキーム/ルールによって検証されたイベントの％）、
成功の処理の再編
サービスレイテンシー（ストアフロント/ダッシュボードへのp95リクエスト）。

SLO（ランドマーク）：

鮮度p95 ≤ 3分（ストリーミング）、≤ 15分（バッチ）。
完全性≥ 99。7％の正しさ≥ 99。9%.
99 ≥成功を取り戻す。9%.
サーブp95 ≤ 500ミリ秒（メインショーケース）。

14）観察可能性と血統

Data Lineage：ダッシュボードからrawイベント（column-level）まで。
品質信号：完全性、独自性、参照整合性、スキーマドリフト。
アラート：「静かな失敗」（新しいデータなし）、配布ジャンプ、'未知の'フィールドの成長。

15）ダッシュボード（テンプレート）

A。クロスチェーンOps（リアルタイム/時間）：

Success-Rate、 p95 Finality、 Relay Availability、 Challenge/Reorg、 backlog、 error budget burn。

B。流動性とコスト（曜日/週）：

TVL、チェーンごとのNet Flow、転送あたりのコスト、利用、保険ファンド。

C。プロダクト及び成長（週/月）：

MAU/DAU （dedup）、クロスチェーン保持、チャネル漏斗、QoT。

D。リスク&コンプライアンス（週）：

詐欺/紛争率、制裁のヒット、高リスクのシェア、手続きのスピード。

16）操作の規則およびplaybook

インシデント： フレッシュネス・ラグ>SLO

コネクタ/インデックスをチェックし、バックアップに切り替え、劣化モードを有効にします（ショーケースは「最終確定」を示します）。

インシデント： reorg/challengeサージ

K-確認/紛争ウィンドウを拡大し、大量の「遅延確定」を有効にし、ブリッジ/オペレータに通知します。

インシデント通貨/資産の分散

影響を受けるペアを凍結し、ディレクトリをロールバックし、USD正規化を再計算し、レポートを公開します。

インシデント： 詐欺/紛争ジャンプ

限界/得点をきつく締め、手動高リスクレビューをオンにし、新鮮なパターンでモデルのトレーニングを終了します。

17）設定例（Pseudo-YAML）

ネットワークによる最終化ウィンドウ

yaml finality:
eth-mainnet: 12  # блоков polygon: 256 solana: "optimistic: 32 slots"
optimistic-bridge: { challenge_minutes: 20 }
zk-bridge: { proof_time_sla: 180 }

Idempotencyと重複除外ルール

yaml dedup:
key_template: "${chain_id}    ${block_height}    ${tx_hash}    ${log_index}    ${event_type}"
ttl_hours: 48

パイプラインSLO

yaml pipelines:
ingest_stream:
freshness_p95_min: 3 completeness_min_pct: 99. 7 gold_build:
correctness_min_pct: 99. 9 reorg_success_min_pct: 99. 9

18）実装チェックリスト

1.ソース、スキーム、最終化ウィンドウと所有者をキャプチャします。
2.idempotencyとreorg-handling （states+replay）を有効にします。
3.モデルのカーネルを構築する（transfers/bridges/onchain_events/kyc/payouts)。
4.アセットディレクトリとFX正規化を設定します。
5.パイプラインのSLI/SLOとダッシュボードを定義します。
6.エンティティの解決とプライバシー・バイ・デザインを実装します。
7.詐欺防止スコアリングとインシデント規制を含める。
8.過去のreorg/challengeケースでバックフィルとテストを実行します。
9.スキーマ、メトリックウェイト、ソースを定期的にレビューします。

19）用語集

Finality-状態/イベントの不可逆性。
Reorg-チェーンの再構成、ブロックの一部のキャンセルにつながります。
チャレンジ期間-楽観的なモデルのチャレンジウィンドウ。
エンティティ解決-単一のエンティティのアドレス/アカウントのマッピング。
GTV/TVL-トランザクションボリューム/ブロックされた値。
完全性/鮮度/正確性-基本的なデータ品質指標。

ボトムライン：チェーン間アナリティクスは、単なるメトリクスの要約ではなく、管理可能な規律です。単一のイベントスキーム、正しいファイナライゼーション、安定したパイプライン、プライバシー、不正防止、わかりやすいショーケースです。このフレームワークに従うことで、エコシステムは、生のブロックからビジネスソリューションまで、価値、リスク、成長の真の「エンドツーエンド」ビューを獲得します。

チェーン間の分析

クロスチェーン保持D7

SLOブリッジショーケース

Idempotencyと重複除外ルール

パイプラインSLO

お問い合わせ

迅速な連絡

動画はまもなく更新されます

現在、私たちはプロジェクトで非常に多忙です