قابلیت همکاری شرکت کنندگان

(بخش: اکوسیستم و شبکه)

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. رویدادها و داده ها: طرح های رویداد یکپارچه، کاتالوگ دارایی/شبکه، idempotency.
4. فرآیندها و قراردادهای کسب و کار: پرداخت/حل و فصل، تخصیص، سیگنال های ریسک، محدود کردن تکرار.
5. لایه مدیریت/قانونی: SLA/SLO، DPA، مجوزها، مقررات فرمانداری.
6. قابلیت مشاهده و کیفیت: SLI/SLO، ورود به سیستم، ردیابی، حسابرسی.

هر لایه قراردادها، تست ها و سیاست سازگاری خود را دارد.

3) اصول طراحی

قرارداد اول: API ها/طرح ها/رویدادها قبل از پیاده سازی رسمی می شوند.
تغییرات سازگار با عقب: استراتژی «اضافه کردن فقط فیلدها» و پنجره مستهلک ≥ 90 روز.
مذاکره قابلیت: شرکت کنندگان قابلیت های پشتیبانی شده را مبادله می کنند و یک زیر مجموعه مشترک را انتخاب می کنند.
جداسازی و PoLP: دسترسی و محدودیت ها «حداقل لازم» صادر می شوند.

Idempotence و جبرگرایی: عملیات تکرار امن، قوانین درگیری قابل پیش بینی

مشاهده پذیری پیش فرض: همبستگی ردیابی درخواست ها/رویدادها، صورتحساب های قابل تایید.
به حداقل رساندن داده ها: فقدان PII در تله متری/برچسب، pseudonymization.

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، کدهای خطای واضح، کلید های idempotent («Idempotency-Key»)، محدودیت های بدن.
مدل رویداد: "سپرده. '، پرداخت. '،' پل. '،' KYC. '،' خطر. '،' محصول. '- با زمینه های پایدار.
دایرکتوری ها/کاتالوگ ها: شبکه ها، دارایی ها، روش های پرداخت، نسخه های 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. جزئی است. پچ.
قوانین: جزئی/PATCH - سازگار با عقب ؛ MAJOR - وجود موازی با «آداپتورها»، ≥ 90 روز کاهش می یابد.
کتاب های مهاجرت: قالب های مهاجرت برای API/رویدادها/دایرکتوری ها ؛ شبیه سازهای فرمت های قدیمی.

7) الگوهای ادغام (الگوهای)

درخواست-پاسخ + Idempotency: پرداخت امن/محدودیت/ذخایر.
رویداد محور: «منابع حقیقت» تغییر را ارسال می کنند. مشترکین، ویترین فروشگاه ها را تحقق می بخشند.
Outbox/Inbox: انتشار اتمی رویدادها از پایگاه داده ؛ پذیرش بی نظیر در مشترک.
SAGA (ارکستراسیون/رقص): عملیات هماهنگ چند دامنه (به عنوان مثال، «popolneniye → igrovoye sobytiye → vyplata»).
Dual-write guard: بدون ورودی مستقیم بدون صندوق خروجی.
Replay/Backfill: شکست با نظم و نهایی سازی.

8) امنیت و اعتماد

mTLS و اتصال کلید به 'org _ id/peer _ id'.
امضای رویداد، ورود اعتماد (چه کسی و چه امضا/دریافت).
RBAC/ABAC و سهمیه: حقوق توسط نقش، محدودیت های عملیات/حجم.
مدیریت مخفی: چرخش، ممنوعیت نشانه های «طولانی مدت»، حوزه های کوتاه.
PII/حریم خصوصی: نشانه گذاری، تفکیک داده های منطقه ای (EU/ROW)، فرآیندهای DSR (حذف/صادرات).
حفاظت در برابر سوء استفاده: محدودیت سرعت، سیگنال های ضد تقلب، چک های تحریم.

9) SLI/SLO و قابلیت مشاهده قابلیت همکاری

• 'p95 زمان به اذعان'.
• 'p95 End-to-End' (ایجاد → نهایی/اجرا).
• 'میزان موفقیت' توسط رویداد/نوع عملیات.
• «طرحواره/انطباق قرارداد%») پیامهای معتبر (.
• 'پوشش اثبات٪' (نسبت شواهد امضا شده/پیوست شده).
• «خطای سوزاندن بودجه» по P0/P1.

• P0 (پرداخت/پل): p95 E2E ≤ 5 دقیقه، موفقیت ≥ 99. 5٪، ACK ≤ 2 ثانیه.
• P1 (محصول): طراوت p95 ≤ 3 دقیقه، انطباق ≥ 99. 9%.
• قراردادهای داده: رانش MTTA ≤ 5 دقیقه، تغییرات شکستن = 0 بدون MAJOR.

Дашборды: عملیات متقابل, سلامت قرارداد, تاخیر و موفقیت, رانش طرح, امنیت و کلید.

10) ماتریس سازگاری (طراحی آزمون)

• سناریوها: پرداخت، سپرده، پل، خطر، محصول، تله متری.
• نسخه ها: API v2. 6/v2 5، رویدادهای v1. 9/v1 8.
• حالت های شبکه: طبیعی، تخریب، ریزش، تاخیر DA.
• حوزه های قضایی: EU/UK/TR/LA - کاتالوگ ها و قوانین مختلف.

Autotests: تست قرارداد (تولید کننده/مصرف کننده)، idempotency، سعی مجدد/جبران خسارت، طرح-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 }

بی نظمی و تکرار

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.
هفتگی: کمیته قابلیت همکاری (فرصت های جدید، مهاجرت، مستهلک).
قبل از انتشار: تست قرارداد، canary با معیارهای «شیشه ای»، برنامه های برگشت.
حوادث: کانال تک وضعیت، قالب پیام برای همکاران، پس از مرگ ≤ 72 ساعت.

14) حوادث کتاب بازی

A. رانش طرح/قرارداد

1. فعال کردن «حالت سخت» (قطع پیام های نامناسب),

2. حادثه را باز کنید و به منابع اطلاع دهید،

3. ایجاد یک تفاوت

4. آداپتور/ثابت را آزاد کنید

5. به روز رسانی پس از مرگ و لینتر.

B. پخش فله/پیام های دوگانه

1. بررسی idempotence/کلید،

2. فیلترهای dedup را روشن کنید

3. محدود کردن تولید کننده پر سر و صدا،

4. دوباره محاسبه پنجره فروشگاه.

C. افزایش تأخیر/کاهش ACK

1. اولویت بندی P0، افزایش مصرف کنندگان،

2. به طور موقت نمونه P2 را کاهش می دهد،

3. مسیر و تجزیه و تحلیل تنگنا شبکه.

د. سازش کلیدی عضو

1. لغو، چرخش، به روز رسانی رجیستری قابل اعتماد،

2. امضای مجدد دسته های مهم/گواهینامه ها،

3. حسابرسی از اقدامات، گزارش به شرکای.

E. عدم تطابق دایرکتوری (دارایی/شبکه)

1. پیام های درگیری قرنطینه،

2. بازگشت به کاتالوگ

3. محاسبه مجدد دانه ها،

4. تکه های انتشار.

15) چک لیست پیاده سازی

1. تعریف سطوح و قراردادها (API ها، رویدادها، دایرکتوری ها، کلید ها).
2. اجرای مذاکره قابلیت و نسخه/قابلیت ثبت نام.
3. شامل idempotency، سهمیه، QoS، امضا، و mTLS.
4. پیکربندی SLI/SLO، داشبورد و هشدارها (Ack، E2E، Compliance).
5. خودکار تست قرارداد و ماتریس تست سازگاری.
6. وارد کردن رویههای مستهلک و مهاجرت) MAJOR به موازات (.
7. به طور منظم کاتالوگ ها/قوانین حفظ حریم خصوصی و دسترسی را بررسی کنید.

16) واژه نامه

مذاکره قابلیت - آشتی دادن قابلیت های پشتیبانی و مشخصات کار.
قرارداد اول - رابط های طراحی از طریق قراردادهای رسمی قبل از اجرای.
Idempotency - تکرار عملیات امنیتی.
انحراف طرح/قرارداد - اختلاف بین پیام های واقعی و قراردادهای اعلام شده.
PoLP اصل حداقل حقوق لازم است.
درصد انطباق، درصد پیام ها/درخواست هایی است که با قرارداد مطابقت دارند.

خط پایین: قابلیت همکاری شرکت کنندگان یک سیستم مدیریت شده از قراردادها، نسخه ها، قابلیت ها و قابلیت مشاهده است. با پیروی از این چارچوب، اکوسیستم فراهم می کند ادغام سریع، جریان کسب و کار پایدار و تکامل امن بدون خرابی - از سطح شبکه و هویت به فرآیندها و حکومت است.