ეკოსისტემის მონაწილეთა რუკა

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

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

მონაწილეთა რუკა არის საერთო მოდელი „ვინ არის ვინ“ ეკოსისტემაში: როლები, ურთიერთობები, უფლებები, პასუხისმგებლობის საზღვრები და შესაბამისობის კონტურები. ეს აღმოფხვრის ტერმინების უთანხმოებას, აჩქარებს პარტნიორების ონბორდინგს, ამარტივებს ინციდენტების კვალდაკვალ და ზრდის ქსელის მართვას (მთავრობა, რისკი, უსაფრთხოება, განვითარება).

2) როლების ტაქსონომია (ზედა დონე)

1. ოპერატორები (ოპერატორები) - ბრენდები/პლატფორმები, რომლებიც ფლობენ კლიენტის გამოცდილებას.
2. შინაარსის პროვაიდერები (Studios/Content Providers) - სლოტები, ცოცხალი თამაშები, სპორტული ფიდები, მინი თამაშები.
3. გადახდის პროვაიდერები (PSP/On-Off Ramp) - ბარათები, APM, stables, კრიპტო-საფულეები.
4. იდენტიფიკაცია და რისკი (KYC/KYB/AML/Trust) - გადამოწმება, მორიელები, სანქციების ფილტრები.
5. ინფრასტრუქტურა/ქსელი (Nodes/Relays/Edge/CDN/ხიდები) - ტრანსპორტი, მარშრუტიზაცია, ჯაჭვის კავშირები.
6. აფილატები/აგრეგატორები/ტრაფიკი - ლიდერების, ფანჯრების, მედია ქსელების წყაროები.
7. ანალიტიკა და მონაცემები (DWH/BI/Anti-Fraud) - დაკვირვება, მოხსენება, მოდელირება.
8. საზოგადოება და DevRel არიან დეველოპერები, ინტეგრატორები, პარტნიორი გუნდები.
9. რეგულატორები და აუდიტორები (B2G) - ლიცენზია, შემოწმება, მოხსენებები.
10. ჰოვერნანსი და ხაზინა - წესები, ბიუჯეტები, გრანტები.
11. პარტნიორი ბროკერები/Market Places - ტრაფიკის გაცვლა, ლიკვიდობა, ინტეგრაცია.

3) როლებისა და ობიექტების ქვეშ (დეტალები)

ოპერატორები: B2C ბრენდი, White-Label, რეგიონალური ქვე-ოპერატორი, PSP მარშრუტიზატორი.
სტუდიები/პროვაიდერები: RGS, ცოცხალი სტუდია, ტურნირების „რანერი“, სპორტული ფიდის მიმწოდებელი.
PSP: ბარათის შეძენა, ადგილობრივი APM (Papara, Mefete და ა.შ.), კრიპტო დამუშავება, რისკის გამყიდველი.
KYC/KYB/AML: KYC მიმწოდებელი, სანქციების ჩამონათვალის წყარო, PEP/Adverse Media პროვაიდერი, ქცევითი მორიელი.
ინფრასტრუქტურა: დამადასტურებელი/noda, სუპერ კვანძი/relay, ხიდი (მსუბუქი/optimistic/ZK), CDN/edge ქეში.
ტრაფიკი/მედია: ვიტრინა, არბიტრაჟი, გავლენის მქონე ქსელი, განმეორებითი DSP, პარტნიორი CRM იარაღებში.
მონაცემები: ბლოკჩეინის ინდექსერი, CDC კონექტორი, inti from DSS, BI.
საზოგადოება: SDK ანაზღაურება, ინტეგრატორი, ადგილობრივი წარმომადგენელი/ამბასადორი.
B2G: რეგულატორი, საგადასახადო ანგარიშგება, აუდიტი (გარე/შიდა).
ჰოვერნანსი/ხაზინა: ოქმის საბჭო, დელეგატები, საგრანტო კომიტეტი.
ბროკერები: ინტეგრაციის აგრეგატორი (API ბაზარი), ტრაფიკის გაცვლა/ლიკვიდობა.

4) ნდობისა და იდენტურობის მოდელები

იურიდიული თვითმყოფადობა: KYB (რეგი. ნომერი, ქვეყანა, ბენეფიციარები), ლიცენზია/ნებართვები.
ტექნიკური იდენტურობა: 'org _ id', 'peer _ id' (ed25519/secp256k1), X.509 (mTLS), მისამართები/საფულეები.
ნდობის დონე: T0 (საზოგადოებრივი), T1 (ძირითადი სერტიფიკაციით), T2 (გაფართოებული შემოწმება + ანაბრები), T3 (კრიტიკული როლები/ხიდები).
გასაღების პოლიტიკა: ორგანიზაციის ფესვის გასაღებები + სესია; როტაცია/მიმოხილვა, სანდო კლავიშების ჟურნალი.

5) ურთიერთქმედების მატრიცა (B2B/B2C/B2G)

ოპერატორი Provider: შინაარსი, ლიმიტები, ტურნირები, ბილინგი, SLA.
ოპერატორი - PSP/KYC: ანაბრები, გადახდები, გადამოწმება, ჩარჩბეკი.
ოპერატორი Affiliates: lides, ატრიბუტი, გადახდები, QoT.
Provider-Network/Infra: განაწილება, შეფერხება, დასრულება.
მთავრობა: ყველაფერი: წესები, ხმის მიცემა, გრანტები.
რეგულატორი/აუდიტი/ოპერატორი/PSP: მოხსენებები, შემოწმებები, ინციდენტები.
Data/BI ყველა: მოვლენების სქემები, ფანჯრები, კონფიდენციალურობა.

ობლიგაციების ტიპები: მონაცემები (events), გამოწვევები (RPC/API), ღირებულება (გადახდა/აქტივები), ნდობა (გასაღებები/ხელმოწერები), მენეჯმენტი (proposal/გადაწყვეტილებები).

6) მონაწილის სასიცოცხლო ციკლი (Lifecycle)

1. Onboarding: რეგისტრაცია, KYB, ლიცენზიის გადამოწმება, დოკუმენტების დატვირთვა, „org _ id“ წარმოება, გასაღებების გამოშვება.
2. ტექნიკური ინტეგრაცია: sandbox - სცენა - წარმოება, ტესტის შემთხვევები, პირველი მოვლენების ხელმოწერა.
3. გააქტიურება: SLO მიზნები, კვოტები/ლიმიტები, აუზებში ჩართვა (ტრაფიკი/ლიკვიდობა).
4. ზრდა: რეგიონების/მეთოდების გაფართოება, გრანტები/მარკეტინგი, SDK განახლებები.
5. შესაბამისობა: პერიოდული შურისძიება, კლავიშების აუდიტი, როტაცია, DR ტესტები.
6. ევოლუცია/შეწყვეტა: კონტრაქტების მიგრაცია, თანხების გატანა, არქივი, გასაღებების გაცნობა.

7) მონაწილეთა რეესტრი და წვდომა (რეფერენდუმის მოდელი)

• 'org' (ორგანიზაცია), 'role _ binding' (როლი და გაფართოება), 'credential' (გასაღები/სერთიფიკატი), 'capability' (ნებართვის ნაკრები), 'limit' (კვოტები), 'contact' (ოპერატიული).

სქემის მაგალითი (ფსევდო-SQL)

sql
CREATE TABLE orgs (
org_id TEXT PRIMARY KEY,
legal_name TEXT, country TEXT, regulator TEXT,
trust_tier SMALLINT, status TEXT, created_at TIMESTAMPTZ
);

CREATE TABLE role_bindings (
org_id TEXT REFERENCES orgs(org_id),
role TEXT,     -- operator    provider    psp    kyc    relay    bridge    affiliate...
scope JSONB, -- regions/networks/products
PRIMARY KEY (org_id, role)
);

CREATE TABLE credentials (
org_id TEXT REFERENCES orgs(org_id),
peer_id TEXT, type TEXT, public_key TEXT, valid_to TIMESTAMPTZ,
revoked BOOLEAN DEFAULT FALSE,
PRIMARY KEY (org_id, peer_id)
);

CREATE TABLE capabilities (
org_id TEXT REFERENCES orgs(org_id),
capability TEXT,  -- payouts. write, events. publish, traffic. receive, bridge. sign,...
conditions JSONB, -- limits/hours/countries/assets
PRIMARY KEY (org_id, capability)
);

CREATE TABLE compliance_records (
org_id TEXT REFERENCES orgs(org_id),
kyb_status TEXT, licenses JSONB, sanctions_check TEXT,
last_audit TIMESTAMPTZ, next_review TIMESTAMPTZ
);

პოლიტიკის მაგალითი (YAML)

yaml access:
tiers:
T1: { max_regions: 2, payouts_daily_usd: 100000, assets: [USDC, EUR] }
T2: { max_regions: 6, payouts_daily_usd: 1000000, assets: [USDC, EUR, TRY] }
T3: { max_regions: 32, unlimited: true, bridge_sign: true }
roles:
operator:
caps: [events. publish, payouts. write, users. read]
provider:
caps: [content. serve, limits. read, events. publish]
psp:
caps: [payments. process, payouts. execute]

8) ობლიგაციების გრაფიკი და დაკვირვების წრე

მონაწილეთა გრაფიკი: მწვერვალები - 'org _ id', ნეკნები - 'relation (ტიპი, scope, slas, limits) ".
ნეკნების კატეგორიები: 'შინაარსი', 'payments', 'bridge', 'traffic', 'data', 'governance'.
დაკვირვება: P2P ჰოპების კვალი, ნდობის ჟურნალი (ხელმოწერები), SLI/SLO თითოეული ტიპის ნეკნისთვის.

ნეკნის მოდელის მაგალითი (ფსევდო-SQL)

sql
CREATE TABLE edges (
src_org TEXT, dst_org TEXT, edge_type TEXT, -- payments    content    traffic    bridge    data    gov slas JSONB, limits JSONB, status TEXT, since TIMESTAMPTZ,
PRIMARY KEY (src_org, dst_org, edge_type)
);

9) Mapping პროცესებზე და მონაცემებზე

ღონისძიების მოდელი: 'signup/kyc/pass', 'deposit/payout', 'game _ start/event', 'bridge. lock/mint`, `traffic. view/click '- ერთიანი სქემა და იდუმალი გასაღებები.
კატალოგები: ქსელები/აქტივები/გადახდის მეთოდები/SDK/რეგულატორები/ქვეყნები.
ლოდინი და აუდიტი: უცვლელი ჟურნალები (hash ჯაჭვები), მითითება 'proposal _ id' (მთავრობის) და 'org _ id'.

10) „ბარათის“ ჯანმრთელობის მეტრიკა (KPI/SLO)

საფარი და სისრულე

Coverage% როლებით (მონაწილეთა მიერ დახურული ეკოსისტემური ფუნქციების წილი).
რეგულირების კოვერაჟი% (× მეთოდების ქვეყნები × პროვაიდერები).
Version Coverage% (SDK/პროტოკოლი).

ხარისხი და რისკი

Compliance Freshness (KUV/აუდიტის ბოლო შემოწმების დრო).
კეი ჰიგენი (დროულად როტაცია, გადაშენებული გასაღებების წილი).
Incident Rate როლები/ნეკნები; MTTA/MTTR.

ეკონომიკა და ზრდა

New Partners/თვე, Activation Velocity (ონბორდიდან პირველ მოვლენებამდე), Net Contribution (მონაწილის ღვაწლი GTV/MAU/ლიკვიდობაში).
Partner Churn%.

SLO მაგალითები

KYB მიმოხილვა - 5 სამუშაო დღე; გასაღებები T3 როტაცია 90 დღე; Incident SEV-1 MTTR - 30 წთ; Post-mortem ≤ 72 ч.

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

ატლასი (ზოგადი რუკა): ინტერაქტიული გრაფიკი: როლები, კომუნიკაციები, სტატუსები (ცხოველი/ჟელტი/წითელი), ფილტრები ქვეყნის/ნეკნების მიხედვით.
Compliance: აუდიტის ვადები, ვადაგადაცილებული CW/აუდიტი, სანქციების ჰიტები.
კავშირი: p95 ლატენტობა და ნეკნები, პირდაპირი P2P, relay პროცენტი.
ეკონომიკა: მონაწილეთა წვლილი (GTV/MAU/Take Rate), ტოპ ზრდა/ვარდნა.
რიკი: ინციდენტები კლასებში, burn-rate SLO, ექსპოზიციები კონტრარგუმენტებზე.
მთავრობის საქმიანობა: წინადადებების აქტივობა, ხმების განაწილება, გრანტები.

12) მონაწილის ონბორდინგი: ჩეკის სია

1. იურიდიული კითხვარი + დოკუმენტები (KYB, ლიცენზიები, ბენეფიციარები).
2. ტექნიკური რეგისტრაცია 'org _ id', კლავიშების გამოშვება/დატვირთვა, mTLS კონფიგურაცია.
3. როლებისა და შეკრების არჩევანი, „კაპიტების“ და ლიმიტების დანიშვნა.
4. დაკავშირება sandbox, ტესტის სიუტა (events, payouts, limits, bridge).
5. SLO/ალერტებისა და საკონტაქტო ხაზის კონფიგურაცია (კრიტიკული როლებისთვის 24/7).
6. SLA/რეგულაციების დამტკიცება, რეესტრში გამოქვეყნება.
7. კანარის პერიოდი (1-2 კვირა), შემდეგ კვოტების გაფართოება.

13) ცვლილებები და თავსებადობა

API/მოვლენების/სქემების ვერსია: პოლიტიკა „მხოლოდ დამატება“, სადეპოზიტო ფანჯარა 90 დღე.
კაპიტალური ნეგოტია: handshake- ზე მხარდაჭერილი შესაძლებლობების გამოცხადება.
როლების/შეკრების მიგრაცია: განაცხადები მთავრობის, timelock- ის, აუდიტის საშუალებით.

14) უსაფრთხოება და კონფიდენციალურობა

მინიმალური საჭირო უფლებები (PoLP) როლებისა და ნეკნების მიხედვით.
მგრძნობიარე თემებისთვის E2E დაშიფვრა (გადახდები/KUS).
DLP/PII კონტროლი: ტოკენიზაცია, ფსევდონიმიზაცია, რეგიონალური ფანჯრები.
Anti-Sybil- ის კრიტიკული როლებისთვის: ანაბრები/დაზღვევა, authority.
კლავიშების როტაცია/მიმოხილვა: „ორმაგი გასაღებები“, ჟურნალის ცვლა, პარტნიორების შეტყობინებები.

15) Playbook ინციდენტები („ნეკნის“ და „როლების“ მიხედვით)

• მარშრუტის გადართვა, K- კონფიდენციალების ზრდა, throttle მოცულობა, კომუნიკაცია, კომპენსაცია SLO- სთვის.

• ობლიგაციების/შეკრების გაყინვა, სახელმძღვანელო შურისძიება, შესაბამისობის ანგარიში, სიების განახლება.

• ლოგოების შეტაკება (ხელმოწერები/ქვითრები), არბიტრაჟი, დროებითი გრეილისტი, გადახდების კორექტირება.

16) რუქის ანალიტიკოსების მაგალითები (ფსევდო-SQL)

საფარი როლებსა და ქვეყნებში

sql
SELECT role, country, COUNT(DISTINCT org_id) AS orgs
FROM role_bindings rb
JOIN orgs o USING (org_id)
GROUP BY role, country;

შესაბამისობის დრო (შეფერხება)

sql
SELECT org_id, last_audit, next_review,
CASE WHEN next_review < now() THEN 'overdue' ELSE 'ok' END AS status
FROM compliance_records
ORDER BY next_review ASC;

ნეკნების ჯანმრთელობა (წარმატება/ლატენტობა)

sql
SELECT edge_type,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY latency_ms) AS p95_latency,
100. 0 SUM(CASE WHEN status='success' THEN 1 ELSE 0 END)/COUNT() AS success_rate
FROM edge_metrics
WHERE ts >= now() - INTERVAL '7 days'
GROUP BY edge_type;

17) რეესტრები და კატალოგები (რეფერენდუმი-YAML)

yaml catalogs:
networks: [eth-mainnet, polygon, solana, tron]
assets:
- { symbol: USDC, decimals: 6, chains: [eth-mainnet, polygon] }
- { symbol: TRYX, decimals: 2, chains: [tron] }
regulators:
- { code: UKGC, country: GB }
- { code: MGA, country: MT }
sdk_versions:
required: { min: "2. 4. x", lts: "2. 6. x" }

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

ყოველდღიურად: ნეკნების მონიტორინგი (SLO), საკვანძო მდინარეების შემოწმება, ონბორდინგის სტატუსის მოხსენებები.
ყოველკვირეულად: ბარათის კომიტეტი - ახალი როლები/ოფისები, შეფერხებები, გრანტების რეკომენდაციები/MVP ინტეგრაცია.
ყოველთვიურად: აქტივების/ქსელების კატალოგის აუდიტი, SDK ვერსიების აუდიტი, ინციდენტების ანგარიში და time-fix.
კვარტალურად: Trust Tiers- ის გადასინჯვა, სტრესის ტესტი DR და განვითარებადი პროცედურები.

19) „ბარათის“ განხორციელების შემოწმების სია

1. შეთანხმდით როლების/სათაურების და მონაცემთა სქემების ტაქსონომიაზე.
2. განათავსეთ მონაწილეთა რეესტრი, კატალოგები, ACL და კაპიტალური პოლიტიკა.
3. ჩართეთ ნეკნების დაკვირვება (SLI/SLO) და burn-rate ალერტები.
4. კონვეიერის კონვეიერის კონფიგურაცია (KYB, გასაღებები, სანდბოქსი).
5. ბარათის დაკავშირება მთავრობასთან (proposals, timelock, გადაწყვეტილებების ჟურნალი).
6. რეგულარულად გადასინჯეთ კომპლექსის საფარები, რისკები და შეფერხებები.
7. გამოაქვეყნეთ „ეკოსისტემის ატლასი“ შიდა/პარტნიორი მომხმარებლებისთვის.

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

org _ id არის ორგანიზაციის უნიკალური ტექნიკური თვითმყოფადობა.
Trust Tier არის მონაწილის ნდობის/სერტიფიკაციის დონე.
Edge/Rebro არის ოფიციალური კავშირი მონაწილეთა შორის SLO და ლიმიტები.
Capability - ნებადართული ოპერაცია/უფლებები კონკრეტულ წრეში.
Coverage% არის დახურული ფუნქციების/რეგიონების/ვერსიების წილი.
Burn-rate SLO - შეცდომების ბიუჯეტის „დაწვის“ სიჩქარე.

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