მონაწილეთა ინტერიერი

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

1) რა არის მონაწილეთა ინტერიერი

ინტეგრაცია - სხვადასხვა ორგანიზაციების (ოპერატორების, სტუდიების, PSP, KYC/AML პროვაიდერების, ხიდების, აფილიატების, ანალიტიკოსების და ჰოვერნანსის) უნარი, ერთმანეთთან საიმედოდ ურთიერთქმედება შეთანხმებული ოქმებისა და კონტრაქტების საშუალებით, შეინარჩუნოს ბიზნესის შედეგების უსაფრთხოება, კონფიდენციალურობა და რეპროდუქცია.

• ინტეგრაციის სიჩქარე და სკალირება (დროის ინტეგრაცია).
• პროგნოზირება (სტაბილური SLO/SLA კრიტიკული ნაკადების თვალსაზრისით).
• უსაფრთხოება და შესაბამისობა (მინიმალური საკმარისი უფლებები, აუდიტი).
• ევოლუცია ავარიის გარეშე (ვერსია, თავსებადობა).

2) ინტეგრაციის დონე (ფენის მოდელი)

1. ტრანსპორტი და ქსელი: HTTP/2/3, gRPC/QUIC, WebSockets, P2P, mTLS.
2. იდენტურობა და ნდობა: org _ id, peer _ id, X.509/mTLS, ხელმოწერები, კლავიშების როტაცია.
3. მოვლენები და მონაცემები: ერთიანი ღონისძიების სქემები, აქტივების/ქსელების კატალოგები, იდემპოტენციები.
4. პროცესები და ბიზნეს კონტრაქტები: payout/settlement, ატრიბუტი, რისკის სიგნალები, შეზღუდვების რეპლიკაცია.
5. მენეჯმენტი/იურიდიული ფენა: SLA/SLO, DPA, ლიცენზიები, ჰოვერნანსის რეგულაციები.
6. დაკვირვება და ხარისხი: SLI/SLO, ლოგიკა, ტრეკერი, აუდიტი.

თითოეულ ფენას აქვს საკუთარი კონტრაქტები, ტესტები და თავსებადობის პოლიტიკა.

3) დიზაინის პრინციპები

Contract-first: API/სქემები/მოვლენები ფორმირდება განხორციელებამდე.
Backward Compatible ცვლილებები: სტრატეგია „მხოლოდ ველების დამატება“ და სადეპოზიტო ფანჯრები 90 დღის განმავლობაში.
კაპიტალური ნეგოტია: მონაწილეები გაცვლიან მხარდაჭერილ შესაძლებლობებს და ირჩევენ საერთო ქვესათაურს.
იზოლაცია და PoLP: ხელმისაწვდომობა და შეზღუდვები გაიცემა „მინიმალური საჭირო“.
იდემპოტენტობა და დეტერმინიზმი: განმეორებითი უსაფრთხო ოპერაციები, კონფლიქტის პროგნოზირებადი წესები.
ნაგულისხმევი დაკვირვება: მოთხოვნის/მოვლენების კორელაცია, შემოწმებული ქვითრები.
Data minimization: PII- ის არარსებობა ტელემეტრიაში/ეტიკეტებში, ფსევდონიზაცია.

4) კაპიტულაციის შესაძლებლობები (მოლაპარაკებები)

ხელის შეშლის დროს, მონაწილეები აქვეყნებენ შესაძლებლობებისა და ვერსიების მანიფესტს.

yaml participant:
org_id: "ORG:ACME"
versions:
api: "2. 6. 1"
events: "1. 9. 0"
capabilities:
payouts: { create: true, cancel: true, currencies: [USD, EUR, USDC] }
kyc: { level: ["basic","enhanced"], sla_minutes_p95: 15 }
bridge: { proof: ["light","zk"], challenge_supported: true }
telemetry: { qos: ["P0","P1"], traces: true }
limits:
payouts_daily_usd: 1_000_000 rate_limits: { create_per_minute: 500 }

თავსებადობის ძრავა ადარებს მხარეთა მანიფესტებს და ირჩევს სამუშაო პროფილს (მაგალითად, 'payouts: v2', 'events: v1). 9`).

5) API/ღონისძიებების და სქემების ხელშეკრულებები

API კონტრაქტები: OpenAPI/gRPC IDL, შეცდომების მკაფიო კოდები, Idempotence გასაღებები ('Idempotency-Key'), სხეულის შეზღუდვები.
ღონისძიების მოდელი: 'deposit.', 'payout.', 'bridge.', 'kyc.', 'risk.', 'product.' - სტაბილური ველებით.
საცნობარო წიგნები/კატალოგები: ქსელები, აქტივები, გადახდის მეთოდები, SDK ვერსიები, რეგიონები/იურისდიქციები.
მონაცემთა კონტრაქტები: ტესტირება CI- ში, ცვლილებები - მთავრობის მეშვეობით timelock- ით.

yaml event:
id: uuid ts: timestamp_utc type: payout. created    payout. finalized    bridge. lock...
src_org: string dst_org: string payload: object trace_id: string idempotency_key: string signature: string # source signature

6) ვერსია და თავსებადობა

სემანტიკური ვერსიები: 'MAJOR. MINOR. PATCH`.
წესები: MINOR/PATCH - საპირისპირო; MAJOR - პარალელური არსებობა „ჯვარედინი“, დეპრესია 90 დღე.
Migration playbooks: მიგრაციის შაბლონები API/მოვლენებისთვის/კატალოგებისთვის; ძველი ფორმატის ემულატორები.

7) ინტეგრაციის შაბლონები (ნიმუშები)

Request-Reply + Idempotence: უსაფრთხო გადახდები/ლიმიტები/რეზერვები.
Event-Driven: „ჭეშმარიტების წყაროები“ უგზავნიან ცვლილებებს; აბონენტები მატერიალიზაციას უწევენ ფანჯრებს.
Outbox/Inbox: მოვლენების ატომური გამოცემა BD- დან; იდემპოტენტური მიღება აბონენტთან.
SAGA (ორკესტრი/ქორეოგრაფია): შეთანხმებული მრავალ დომენის ოპერაციები (მაგალითად, „შევსება - თამაშის მოვლენა - გადახდა“).
ორმაგი ორმაგი ჩანაწერის აკრძალვა გარედან.
Replay/Backfill: აღდგენა შეკვეთა და დასრულება.

8) უსაფრთხოება და ნდობა

mTLS და ღილაკების ბმული 'org _ id/peer _ id'.
მოვლენების ხელმოწერები, ნდობის ჟურნალი (ვინ და რა ხელი მოაწერა/მიიღო).
RBAC/ABAC და კვოტები: როლების უფლებები, ოპერაციების ლიმიტები/მოცულობა.
საიდუმლო მენეჯმენტი: როტაცია, „გრძელი“ ნიშნების აკრძალვა, მოკლე ნაგავი.
PII/კონფიდენციალურობა: ტოკენიზაცია, რეგიონალური მონაცემთა სეგრეგაცია (EU/ROW), DSR პროცესები (მოცილება/ექსპორტი).
ბოროტად გამოყენებისგან დაცვა: velocity limites, საწინააღმდეგო სიგნალები, სანქციების შემოწმება.

9) SLI/SLO და ინტეროპერაციული დაკვირვება

• 'p95 დრო to-Acknowledge' (ღონისძიების ქვითარი).
• 'p95 End-to-End' (შექმნა, დასრულება/განხორციელება).
• 'Success Rate' მოვლენების/ოპერაციების ტიპების მიხედვით.
• 'Schema/Contract Compliance%' (აქტიური შეტყობინებები).
• 'Proof Coverage%' (ხელმოწერილი/თანდართული მტკიცებულებების წილი).
• `Error Budget Burn` по P0/P1.

• P0 (გადახდა/ხიდი): p95 E2E - 5 წთ, Success - 99. 5%, Ack-2.
• P1 (საკვები): Freshness p95-3 წუთი, კომპლექსი 99. 9%.
• მონაცემთა კონტრაქტები: Drift MTTA - 5 წთ, Breaking changes = 0 MAJOR- ის გარეშე.

Дашборды: Interop Ops, Contract Health, Latency & Success, Schema Drift, Security & Keys.

10) თავსებადობის მატრიცა (ტესტის დიზაინი)

• სკრიპტები: payouts, deposits, bridge, risk, product, telemetry.
• ვერსიები: API v2. 6/v2. 5, events v1. 9/v1. 8.
• ქსელის რეჟიმები: ნორმალური, დეგრადაცია, რეორგია, DA შეფერხებები.
• იურისდიქციები: EU/UK/TR/LA - სხვადასხვა კატალოგები და წესები.

Autostes: საკონტრაქტო ტესტები (product/consumer), idempotence, retry/compensation, schema-linters, დატვირთვის პროფილები.

11) რეფერენდუმის სქემები და კატალოგები

შესაძლებლობების კატალოგი (SQL)

sql
CREATE TABLE capabilities (
org_id TEXT,
cap_name TEXT,
version TEXT,
params JSONB,
PRIMARY KEY (org_id, cap_name)
);

ხელშეკრულებების/ვერსიების რეესტრი

sql
CREATE TABLE contracts (
name TEXT, kind TEXT,     -- api    events    catalog version TEXT, status TEXT,  -- active    deprecated    retired breaking BOOLEAN DEFAULT FALSE,
effective_from TIMESTAMPTZ,
deprecates_at TIMESTAMPTZ,
PRIMARY KEY (name, version)
);

თავსებადობის მონიტორინგი

sql
SELECT name, version, 100. 0SUM(CASE WHEN compliant THEN 1 END)/COUNT() AS compliance_pct
FROM contract_checks
WHERE ts >= now() - INTERVAL '7 days'
GROUP BY name, version;

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

ვერსიის პოლიტიკა

yaml versioning:
events: { compatibility: "BACKWARD", deprecate_days: 90 }
api:  { parallel_majors: true, support_minors: 2 }

Idempotence და გამეორება

yaml idempotency:
header: "Idempotency-Key"
ttl_hours: 72 conflict_policy: "prefer-latest-payload-with-signature"

QoS კლასები

yaml qos:
P0: { ack_timeout_ms: 2000, retries: 3, backoff_ms: [100,400,800] }
P1: { ack_timeout_ms: 5000, retries: 2 }
P2: { best_effort: true }

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

ყოველდღიურად: ხელშეკრულების/სქემების ანგარიში, ვადაგადაცილებული გასაღებები, SLO burn.
ყოველკვირეულად: ინტეგრაციის კომიტეტი (ახალი შესაძლებლობები, მიგრაცია, დეპრესიები).
გათავისუფლებამდე: კონტრაქტის ტესტები, „მინის“ მეტრიკის მარყუჟები, დასაკეცი გეგმები.

ინციდენტები: ერთი სტატუსის არხი, პარტნიორების შეტყობინებების შაბლონები, პოსტ-mortem - 72;

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

A. Schema/Contract Drift

1. ჩართეთ „მკაცრი რეჟიმი“ (შეწყვიტეთ შეუსაბამო შეტყობინებები),

2. ინციდენტის გახსნა და წყაროების ინფორმირება,

3. diff- ის წარმოქმნა

4. ადაპტერის/ფიქსის გამოშვება

5. პოსტ-morthem და ლინტერების განახლება.

B. მასიური გამეორება/ორმაგი შეტყობინებები

1. შეამოწმეთ idempotence/გასაღებები,

2. შუადღის ფილტრების ჩართვა

3. შეზღუდეთ ხმაურიანი პროდიუსერი

4. გადაანგარიშების ფანჯარა.

C. ლატენტობის ზრდა/ack

1. პრიორიტეტული P0, კონსიუმერების გაზრდა,

2. დროებით შეამცირეთ P2 sampling,

3. მარშრუტების და ქსელის ვიწრო ადგილების ანალიზი.

დ. მონაწილის გასაღების კომპრომისი

1. Revoke, როტაცია, სანდო რეესტრის განახლება,

2. კრიტიკული ბრძოლების/სერთიფიკატების ხელახლა დაწერა,

3. ოპერაციების აუდიტი, პარტნიორების ანგარიში.

E. დირექტორიის შეუსაბამობა (აქტივები/ქსელები)

1. კონფლიქტური შეტყობინებების კარანტინი,

2. კატალოგის გამოტოვება

3. დანაყოფების გადაანგარიშება

4. კორექტირების გამოქვეყნება.

15) განხორციელების სია

1. განსაზღვრეთ დონე და კონტრაქტები (API, მოვლენები, კატალოგები, გასაღებები).
2. საქაღალდე negotiation და ვერსიების/შესაძლებლობების რეესტრი.
3. ჩართეთ idempotence, კვოტები, QoS, ხელმოწერები და mTLS.
4. პარამეტრები SLI/SLO, დაშბორდები და ალერტები (Ack, E2E, Compliance).
5. ავტომატიზაცია მოახდინეთ კონტრაქტის ტესტები და თავსებადობის ტესტის მატრიცა.
6. შეიყვანეთ დეპრესიისა და მიგრაციის რეგულაციები (MAJOR პარალელურად).
7. რეგულარულად გადახედეთ კატალოგებს/კონფიდენციალურობისა და წვდომის წესებს.

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

კაპიტალური ნეგოტიაცია მხარდაჭერილი შესაძლებლობებისა და მუშაობის პროფილის კოორდინაციაა.
Contract-first - ინტერფეისის დიზაინი ფორმალური კონტრაქტების საშუალებით განხორციელებამდე.
Idempotence - ოპერაციების გამეორების უსაფრთხოება.
Schema/Contract Drift - ფაქტობრივი შეტყობინებების შეუსაბამობა გამოცხადებულ კონტრაქტებთან.
PoLP არის მინიმალური საჭირო უფლებების პრინციპი.
Compliance% არის ხელშეკრულების შესაბამისი შეტყობინებების/მოთხოვნების წილი.

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