მონაცემთა შერწყმა სხვადასხვა ჯაჭვიდან

(განყოფილება: ეკოსისტემა და ქსელი)

1) რატომ გვჭირდება შერწყმა?

• სიმართლის ერთი წყარო (კანალური ფაქტები), რომელსაც აქვს impeccable ლოგოები.
• წინააღმდეგობა რეორგასა და შეფერხებებზე: სწორი ფინალიზაცია და გადატვირთვა.
• მეტრის შედარება ქსელებსა და აქტივებს შორის.
• გამჭვირვალე ხაზები და ხარისხის კონტროლი აუდიტისა და რეგულატორებისთვის.

2) მონაცემთა წყაროები და კლასები

1. ონჩეინი: ბლოკები, გარიგებები, კონტრაქტების ლოგოები, სათაურები, სახელმწიფოები.
2. ხიდები/გამყიდველები: განაცხადები, ქვითრები, მტკიცებულებები, საბოლოო სტატუსები.
3. L2/DA ფენები: ბატები, პუბლიკაციები, პრუფები, სადავო ფანჯრები.
4. PSP/KYC/KYB/AML: გადახდის სტატუსები, შემოწმებები, სანქციების ჰიტები.
5. სასურსათო მოვლენები: ონბორდი, დეპოზიტები/გადახდები, თამაში და ქცევითი მოვლენები.
6. ცნობარები: ქსელები, აქტივები, decimals, chainID, მისამართები, SDK ვერსიები.

თითოეული წყაროსთვის ფიქსირდება: მეპატრონე, სქემა, განახლების ლაქი, ფინალიზაციის ფანჯარა, მტკიცებულებების ფორმატი და SLO.

3) შერწყმის არქიტექტურა

Ingest (აგენტები/ინდექსატორები/webhook), Raw/Bronze (უცვლელი ნედლეული), Clean/Silver (ნორმალიზაცია და დედობა), Merge/Core/Gold (კანონიკური ფაქტები და კომუნიკაციები) - Marts (ფინანსები/პროდუქტი/რისკი/ოპერაცია/ოპერაცია )/ოპერაცია) SErErerve (Oerve (of LAP/API/ძებნა).
საკვანძო თვისებები: idempotence, სქემების ვერსია, replay/backfill, late da handling.

4) კანონიკური სქემები (გამარტივებული)

4. 1 მოვლენები (YAML)

yaml event:
id: uuid observed_at: timestamp # when saw event_at: timestamp # when happened (by source)
chain_id: string       # 'eth-mainnet'    'polygon'...
block_height: long tx_hash: string log_index: int type: string         # transfer    bridge. lock    bridge. mint...
status: string        # observed    confirmed    finalized    invalid src: string # address/peer-id/org _ id dst: string asset: string # canonical character (USDC)
amount: decimal usd_value: decimal # normalization at the rate on the meta observed_at: object # gas, fee, contract, sdk_version...
idempotency_key: string    # chainId    block    tx    logIndex    type proof_ref: string # proof/anchor reference

4. 2 თარგმანები და ხიდები (SQL)

sql
CREATE TABLE bridge_transfers (
id TEXT PRIMARY KEY,
src_chain TEXT, dst_chain TEXT,
asset TEXT, amount NUMERIC,
created_at TIMESTAMPTZ,
finalized_at TIMESTAMPTZ,
status TEXT,          -- requested    inflight    finalized    failed    reversed src_tx TEXT, dst_tx TEXT,
proof_ref TEXT, meta JSONB
);

4. 3 აქტივების/ქსელების ცნობარი (YAML)

yaml catalog:
assets:
- symbol: USDC decimals: { eth-mainnet: 6, polygon: 6 }
contracts: { eth-mainnet: "0xA0b8...", polygon: "0x2791..." }
networks:
- id: eth-mainnet k_confirmations: 12
- id: polygon k_confirmations: 256

5) ფინალიზაცია, რეორგები და სტატუსები

Состояния: `observed → confirmed(K) → finalized → invalidated(reorg)` (+ `challenged` для optimistic).

• K- მტკიცებულებები ქსელში/აქტივი/რისკი.
• Delayed Finalization დიდი თანხებისთვის.
• Reorg handling: ავტომატური ინვალიდობა და რეპლეი.
• Proof coverage: ჩანაწერების წილი proufs/rackers სამიზნე SLO.

6) დროისა და ვალუტის ნორმალიზაცია

დრო: ყველა timestampts UTC- ში, შეინახეთ 'observed _ at' და 'event _ at'.
FX/აქტივების ფასები: 'usd _ value' გადაანგარიშება '' observed _ at 'კურსით (ან' event _ at '- პოლიტიკის მიხედვით).
Decimals/scale: შედარებისთვის რაოდენობების მკაცრი კანონიზაცია.
დროის ზონები მოხსენებებში: მკვეთრი შერჩევის დროს (ვიტრინა), არა core.

7) Idempotence და deduplication

• `idempotency_key = chainId|block_height|tx_hash|log_index|type`

• გამეორება რამდენიმე ინდექსისგან - upsert idempotency _ key.
• Payload- ის კონფლიქტთან ერთად, ხდება ვაჭრობის პოლიტიკა (წყაროს პრიორიტეტი/ვერსია/დრო).
• ბაბუის ფანჯარა ინახება 48-72 საათზე „მოხეტიალე“ გამეორებისთვის.

8) Entity Resolution (ერთეულების შედარება)

მისამართები - მსახიობები: საფულე/კონტრაქტი - მომხმარებელი/ორგანიზაცია/როლი.
ჯვარედინი ჯაჭვის კავშირები: hard-link (ხელმოწერა/kyc), რბილი ლინჩი (ქცევა/გრაფიკი).
ფსევდონიმი: სტაბილური PID/ORG _ ID; PII ინახება მონაცემთა კონტროლერში.

9) შერწყმის წესები და პრიორიტეტები (პოლიტიკა)

1. თარგმანის შესახებ ჭეშმარიტების წყარო არის ონჩეინის მოვლენა 'finalized' + group.
2. აგრეგატებში ჭეშმარიტების წყაროა ცხრილების core 'transfers' bridge _ transfers 'და არა „ნედლეული“.
3. დროის კონფლიქტი (event _ at vs observed _ at) - ანგარიშის პოლიტიკის მიხედვით (ფინანსები - event _ at; ოპერაცია - observed _ at).
4. თანხების/აქტივების კონფლიქტი არის მერჯისა და კარანტინის შეჩერება აქტივების კატალოგის შერიგებამდე.
5. ხიდის ლიგატები - საჭიროა ორივე მხარის ქვითრები (src/dst) + receipt pairing.

10) ფსევდო მოთხოვნები და ალგორითმები

10. 1 მოვლენების კანონიკური „ოპერაცია“

sql
WITH base AS (
SELECT e.,
CONCAT(e. chain_id,'    ',e. block_height,'    ',e. tx_hash,'    ',e. log_index,'    ',e. type) AS idem
FROM raw_events e
)
INSERT INTO core_events AS c (id, observed_at, event_at, chain_id, block_height,
tx_hash, log_index, type, status, src, dst, asset, amount, usd_value, meta, idempotency_key, proof_ref)
SELECT gen_random_uuid(), observed_at, event_at, chain_id, block_height,
tx_hash, log_index, type, status, src, dst, asset, amount, usd_value, meta, idem, proof_ref
FROM base
ON CONFLICT (idempotency_key) DO UPDATE
SET status = EXCLUDED. status,
usd_value = COALESCE(EXCLUDED. usd_value, core_events. usd_value),
proof_ref = COALESCE(EXCLUDED. proof_ref, core_events. proof_ref),
meta   = core_events. meta          EXCLUDED. meta;

10. 2 ხიდის წყვილების მატჩები (წყარო - მიზანი)

sql
INSERT INTO bridge_transfers (id, src_chain, dst_chain, asset, amount, created_at, status, src_tx, proof_ref)
SELECT
CONCAT('br:', e. tx_hash) AS id,
e. chain_id, b. dst_chain, e. asset, e. amount, e. event_at, 'inflight', e. tx_hash, e. proof_ref
FROM core_events e
JOIN bridge_book b ON e. type='bridge. lock' AND e. asset=b. asset AND e. chain_id=b. src_chain
ON CONFLICT (id) DO NOTHING;

UPDATE bridge_transfers bt
SET finalized_at = e. event_at,
dst_tx    = e. tx_hash,
status    = 'finalized'
FROM core_events e
WHERE e. type='bridge. mint'
AND bt. status='inflight'
AND bt. asset=e. asset
AND bt. src_chain=bridge_book. src_chain
AND bt. dst_chain=bridge_book. dst_chain
AND abs(e. amount - bt. amount) < 1e-9;

10. 3 რეორგის დამუშავება

sql
UPDATE core_events
SET status='invalidated'
WHERE chain_id=$1 AND block_height BETWEEN $2 AND $3
AND status IN ('observed','confirmed','finalized');

-- Reassembly of aggregates (example)
CALL recompute_materialized_views($1, $2, $3);

11) სქემებისა და ევოლუციის მართვა

ვერსია: 'schema _ version' მონაცემთა ნაკრების ქუდში, მიგრაცია იწერება ჟურნალში.
თავსებადობის პოლიტიკა: 'BACKWARD' მოვლენებისთვის (მხოლოდ ველების დამატება).
Data Contracts წყაროებით: CI კონტრაქტების ტესტები, სქემების ლინზები.

12) მონაცემთა ხარისხი: SLI/SLO

• Freshness p95: lag ingest - Gold (წთ).
• Completeness%: ჩანაწერების წილი, რომლებმაც მიაღწიეს „ფინალიზაციას“ ფანჯარაში.
• Correctness%: მოქმედი სქემები/ხელმოწერები/პრუფები.
• Proof Coverage%: კანონიკური ჩანაწერების წილი პრუფებით/კითხვარებით.
• Dedup Efficiency: იდემპოტენტურად შეიწოვება დუბლირების წილი.
• Reorg Handling Success%: სწორად ინვალიდობა და რეპლეისი.

SLO (სახელმძღვანელო): Freshness - 3 წუთი (ნაკადი )/15 წთ (batch); Completeness ≥ 99. 7%; Correctness ≥ 99. 9%; Proof Coverage ≥ 99. 0%; Reorg Success ≥ 99. 9%; Merge MTTR (ინციდენტი) 30 წთ

13) დაშბორდი (განლაგება)

Merge Ops (реал-тайм/час): Freshness, Queue lag, Dedup rate, Finalized %, Reorg spikes, Error-budget burn.
Proof & Finality: proof coverage, p95 finality per chain, challenge/reorg события.
Catalog Health: აქტივების, decimals, SDK ვერსიების განსხვავებები.
Quality & Drift: completeness/correctness, schema drift, late data.
Finance Lens: GTV, Net Flow, TVL ჯაჭვებით/ხიდებით (მხოლოდ 'finalized').

14) კონფიგურაცია (YAML)

ფინალიზაციის ფანჯრები

yaml finality:
eth-mainnet: { k: 12, delayed_for_usd_gt: 100000 }
polygon:   { k: 256 }
optimistic-L2:
k: 0 challenge_minutes: 20 delayed_for_usd_gt: 50000

მერჯისა და პრიორიტეტების პოლიტიკა

yaml merge_policy:
source_priority: [onchain, bridge, psp, product]
conflict:
time: { prefer: "event_at" }
amount: { action: "quarantine" }
proof_required_for: ["bridge_transfers", "payouts"]
quarantine_topics: ["asset_mismatch", "decimals_mismatch", "time_skew_gt_5m"]

Idempotence/dedup

yaml dedup:
key_template: "${chain_id}    ${block_height}    ${tx_hash}    ${log_index}    ${type}"
ttl_hours: 72

15) კონფიდენციალურობა და შესაბამისობა

PII მინიმალიზაცია: PID/ORG _ ID, PII აკრძალვა მეტრიკებში/ეტიკეტებში.
მონაცემთა აღდგენა: რეგიონების სეგრეგაცია (EU/ROW), დაშიფვრა „მშვიდი/გზაზე“.
მოცილების უფლება: tombstone/redaction მოვლენები დადასტურებული გამოყენებით.
აუდიტი: უცვლელი ჟურნალები, ჰაშის დაკითხვა, როლების დაშვების შემოწმება.

16) ოპერაციული რეგულაციები

ყოველდღიურად: Proof coverage- ის შერჩევა, ჯაჭვების ფინალიზაცია, ხიდების რეესტრი და კონფისკაციის დრიფტი.
ყოველკვირეული: აქტივების კატალოგის აუდიტი/decimals, FX ნორმალიზაციის სისწორე.
ყოველთვიურად: reorg/replay ტესტები, SLO შემოწმება და სტრესის შესრულების ტესტი.
Change Management: Timelock merge პოლიტიკის ცვლილებებზე, გადაწყვეტილებების ჟურნალში.

17) Playbook ინციდენტები

A. Russinhron აქტივები/decimals

Proof Coverage

მერკალიზაციის/ანკერის გადატვირთვა, გაუმჯობესების დონის ამაღლება, 100 შემთხვევის სახელმძღვანელო ნიმუში, მოხსენება.

C. Piki Reorg/Challenge

გაზარდეთ 'k '/დავის ფანჯარა, ჩართეთ ძირითადი თანხები, აცნობეთ დაინტერესებულებს.

დუბლის/გამეორების აფეთქება

გამკაცრდება TTL/გასაღები, შეზღუდეთ „ხმაურიანი“ წყაროები, ჩართეთ კარანტინის წრე.

E. დროის დრიფტი

NTP/PTP სინქრონიზაცია, ფანჯრების დათვლა, პრეფერენციული პოლიტიკის დროებითი ცვლა: observed _ at '.

18) განხორციელების შემოწმების სია

1. ჩაწერეთ წყაროები, ფინალიზაციის ფანჯრები და მტკიცებულებები.
2. დანერგეთ კანონიკური მოვლენების სქემა და იდემპოტენტურობის გასაღები.
3. დედოპისა და მერჯე პოლიტიკის პარამეტრები quarantine კონტურით.
4. გაზარდეთ აქტივების/ქსელების რეესტრი და FX ნორმალიზაცია.
5. გააცნობიერეთ replay/backfill და მონაცემთა დამუშავება.
6. განსაზღვრეთ SLI/SLO და ხარისხის დაშბორდები.
7. რეგულარული კითხვარი და აუდიტის ჟურნალები.
8. ჩაატარეთ მფრინავი რეორგ/ხიდის შეფერხებების სიმულაციებით და დააფიქსირეთ MTTR.

19) გლოსარიუმი

Finality არის სახელმწიფოს შეუქცევადობა/მოვლენები.
Reorg არის ჯაჭვის გადაკეთება ბლოკის ნაწილის გაუქმებით.
Idempotence - განმეორებითი მიწოდების წინააღმდეგობა.
Proof Coverage არის რეალური მტკიცებულებების მქონე ჩანაწერების წილი.
Entity Resolution - ერთი არსების მისამართების/ანგარიშების შედარება.
Delayed Finalization - გადავადებული მიღება დანაყოფებში მაღალი რისკის თანხებისთვის.
Quarantine არის იზოლირებული ნაკადი კონფლიქტური/საეჭვო ჩანაწერებისთვის.

შედეგი: ინტერჯექტურული მონაცემების სწორი შერწყმა არის კონტროლირებადი დისციპლინა: კანონიკური სქემა, ფინალიზაცია და პრუფები, მკაცრი იდემპოტენტურობა, გამჭვირვალე შერწყმის პოლიტიკა და ხარისხის დაკვირვება. ამ ჩარჩოს შემდეგ, ეკოსისტემა იღებს მონაცემთა ერთიან, დამოწმებულ და სტაბილურ ფენას - აუდიტის, ანალიტიკისა და პროდუქციის უსაფრთხო მასშტაბის საფუძველს.