עיצוב ארכיטקטורת שער תשלומי קריפטו

בעת בניית שער תשלומים מבוסס קריפטו, מפתחים מגלים בעיות לא מובנות מאליהן. ארגון מחדש של בלוקצ'יין יכול לבטל עסקאות שכבר נחשבו מאושרות. מודל אחסון מפתחות שגוי—והאבטחה נפגעת. היעדר ארכיטקטורת מחברים עם מפסקי מעגל מוביל לירידה ב-SLA. בפועל, לקוח אחד איבד 200 אלף דולר עקב ריאורג—לקחנו זאת בחשבון בארכיטקטורה שלנו. תכנון לפני כתיבת קוד חוסך חודשים של עבודה חוזרת, ותיעוד מוצק מהווה בסיס לסקייל. אנו מביאים 10+ שנות פיתוח בלוקצ'יין ו-50+ פרויקטים פינטק מיושמים. אנו בונים שערים שמטפלים בעד 10,000 עסקאות בשעה. נעריך את הפרויקט שלך ביום אחד—צור קשר.

כיצד לבחור בין סכמות קסטודיאליות ללא-קסטודיאליות?

לפני ציור דיאגרמות, יש לענות על שאלות שקובעות את כל השאר. השווה בין שתי הגישות:

בחר בסכמה קסטודיאלית אם אתה צריך שליטה מלאה על כספי המשתמשים ומוכן לדרישות רגולטוריות. בחר בסכמה לא-קסטודיאלית אם הסוחר רוצה לנהל סיכונים בעצמו והשער רק מבטיח אישור תשלום.

דרישות יסוד

בחירת רשת קובעת את התשתית. מודל ה-UTXO של ביטקוין אינו תואם למודל החשבונות של EVM. ל-TON יש VM משלה. כל רשת מוסיפה עומס תפעולי.

מודל סילוק: האם הסוחר מקבל קריפטו כפי שהוא, או שהשער ממיר לפייט? המרה מציגה סיכון שער חליפין ודורשת אינטגרציה עם בורסה/OTC.

נפח ו-SLA: 100 עסקאות/יום לעומת 100,000 דורשים ארכיטקטורות שונות. SLA של 99.9% (8.7 שעות השבתה בשנה) לעומת 99.99% (52 דקות בשנה) הם דרישות יתירות שונות מהותית.

ארכיטקטורת רכיבים

┌─────────────────────────────────────────────────────────────┐
│ Merchant-facing API                                        │
│ REST / Webhooks / SDK библиотеки                           │
└───────────────────────┬─────────────────────────────────────┘
                        │
┌───────────────────────▼─────────────────────────────────────┐
│ Core Services                                              │
│                                                            │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────────┐  │
│  │Invoice Service│  │Address Alloc │  │ Exchange Rate    │  │
│  │(create/query) │  │(HD wallet    │  │ Service          │  │
│  └──────────────┘  │ derivation)   │  └──────────────────┘  │
│                    └──────────────┘                        │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────────┐  │
│  │Confirmation  │  │Settlement    │  │ Notification     │  │
│  │Tracker       │  │Service       │  │ Service          │  │
│  └──────────────┘  └──────────────┘  └──────────────────┘  │
└───────────┬──────────────────────────────────┬──────────────┘
            │                                  │
┌───────────▼──────────┐  ┌────────────────────▼──────────────┐
│ Blockchain Layer     │  │ Data Layer                        │
│                      │  │                                   │
│ BTC Connector        │  │ PostgreSQL (orders,txns)          │
│ EVM Connector        │  │ Redis (rates, sessions)           │
│ TON Connector        │  │ Message Queue (Kafka/RMQ)         │
│ TRON Connector       │  └───────────────────────────────────┘
└──────────────────────┘

שירותי ליבה: חשבונית וכתובת

שירות החשבוניות מנהל את מכונת המצבים: נוצר → הוקצתה_כתובת → זוהה_תשלום → מאשר → אושר → סולק | פג | נכשל. כל חשבונית מאחסנת ┌─────────────────────────────────────────────────────────────┐ │ Merchant-facing API │ │ REST / Webhooks / SDK библиотеки │ └───────────────────────┬─────────────────────────────────────┘ │ ┌───────────────────────▼─────────────────────────────────────┐ │ Core Services │ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────────┐ │ │ │Invoice Service│ │Address Alloc │ │ Exchange Rate │ │ │ │(create/query) │ │(HD wallet │ │ Service │ │ │ └──────────────┘ │ derivation) │ └──────────────────┘ │ │ └──────────────┘ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────────┐ │ │ │Confirmation │ │Settlement │ │ Notification │ │ │ │Tracker │ │Service │ │ Service │ │ │ └──────────────┘ └──────────────┘ └──────────────────┘ │ └───────────┬──────────────────────────────────┬──────────────┘ │ │ ┌───────────▼──────────┐ ┌────────────▼──────────────┐ │ Blockchain Layer │ │ Data Layer │ │ │ │ │ │ BTC Connector │ │ PostgreSQL (orders,txns) │ │ EVM Connector │ │ Redis (rates, sessions) │ │ TON Connector │ │ Message Queue (Kafka/RMQ) │ │ TRON Connector │ └────────────────────────────┘ └──────────────────────┘ בנפרד מ-exchange_rate_expires_at—זה מאפשר עדכוני שער ללא יצירת חשבונית מחדש.

interface Invoice {
  id: string;
  merchant_id: string;
  external_order_id: string;
  requested_currency: 'USD' | 'EUR';
  requested_amount: Decimal;
  payment_currency: 'BTC' | 'ETH' | 'USDT_ERC20' | 'USDT_TRC20';
  payment_network: 'bitcoin' | 'ethereum' | 'tron';
  payment_address: string;
  payment_amount: Decimal;
  exchange_rate: Decimal;
  exchange_rate_expires_at: Date;
  status: InvoiceStatus;
  received_amount: Decimal;
  tx_hash: string | null;
  confirmations: number;
  required_confirmations: number;
  created_at: Date;
  expires_at: Date;
  confirmed_at: Date | null;
  settled_at: Date | null;
}

הקצאת כתובות משתמשת בארנק HD עם BIP-44. יצירה מוקדמת בקבוצות של 1000 כתובות מונעת עיכובים ביצירת חשבוניות. כלל קריטי: כתובת אחת—חשבונית אחת. גם אם חשבונית פגה, הכתובת לא בשימוש חוזר. למידע נוסף על BIP-44, ראה את המפרט.

CREATE TABLE address_pool (
    id BIGSERIAL PRIMARY KEY,
    network VARCHAR(20) NOT NULL,
    coin_type INTEGER NOT NULL,
    address_index BIGINT NOT NULL,
    address VARCHAR(200) NOT NULL,
    allocated_at TIMESTAMPTZ,
    invoice_id UUID REFERENCES invoices(id),
    UNIQUE(network, address_index)
);

מחברי בלוקצ'יין: כיצד להבטיח אמינות

כל המחברים מיישמים ממשק משותף. עבור רשתות EVM, מופע יחיד עם רוטציה דינמית של נקודות קצה RPC באמצעות מפסק מעגל—לאחר 3 ניסיונות כושלים, הוא עובר לגיבוי.

interface BlockchainConnector {
  watchAddress(address: string, callback: (tx: IncomingTransaction) => void): () => void;
  getTransaction(txHash: string): Promise<TransactionDetail>;
  getConfirmations(txHash: string, blockNumber: number): Promise<number>;
  buildSweepTransaction(from: string, to: string, amount: bigint): Promise<UnsignedTx>;
  broadcastTransaction(signedTx: string): Promise<string>;
  validateAddress(address: string): boolean;
  estimateFee(): Promise<bigint>;
}

מחבר ה-EVM מעבד עסקאות פי 10 מהר יותר מביטקוין בשל היעדר מודל UTXO. עבור TRON, אנו משתמשים ב-tronweb.

מדוע טיפול בריאורג הוא קריטי לשער?

ריאורג—בלוקים שכבר עיבדת הופכים ללא-קנוניים. עסקה שנחשבה מאושרת נעלמת. הגנה: לעולם אל תסמן חשבונית כ-expires_at עם פחות אישושים מסף הבטיחות.

לפי ויקי ביטקוין, לעסקאות גדולות מומלצים 6 אישושים. בנוסף: אחסן interface Invoice { id: string; merchant_id: string; external_order_id: string; requested_currency: 'USD' | 'EUR'; requested_amount: Decimal; payment_currency: 'BTC' | 'ETH' | 'USDT_ERC20' | 'USDT_TRC20'; payment_network: 'bitcoin' | 'ethereum' | 'tron'; payment_address: string; payment_amount: Decimal; exchange_rate: Decimal; exchange_rate_expires_at: Date; status: InvoiceStatus; received_amount: Decimal; tx_hash: string | null; confirmations: number; required_confirmations: number; created_at: Date; expires_at: Date; confirmed_at: Date | null; settled_at: Date | null; } יחד עם CREATE TABLE address_pool ( id BIGSERIAL PRIMARY KEY, network VARCHAR(20) NOT NULL, coin_type INTEGER NOT NULL, address_index BIGINT NOT NULL, address VARCHAR(200) NOT NULL, allocated_at TIMESTAMPTZ, invoice_id UUID REFERENCES invoices(id), UNIQUE(network, address_index) ); . בכל בדיקת אישוש, ודא שהבלוק עם ה-hash הזה עדיין בשרשרת הקנונית.

פעולות: Sweep ו-Webhooks

Sweep—העברה אוטומטית של כספים מכתובת התשלום לארנק קר. עובד רץ לאחר כל אישוש. אם הסכום נמוך מהעמלה, הוא מתעד אך לא שולח.

מערכת Webhook—הסוחר נרשם לאירועים. Backoff אקספוננציאלי: 30 שניות → 5 דקות → 30 דקות → שעתיים → 24 שעות. לאחר 5 כשלונות, מופעלת התראה. כל payload חתום ב-HMAC לצורך אימות.

interface WebhookDelivery {
  id: string;
  merchant_id: string;
  invoice_id: string;
  event_type: 'payment.detected' | 'payment.confirmed' | 'payment.settled' | 'payment.expired';
  payload: object;
  status: 'pending' | 'delivered' | 'failed';
  attempts: number;
  next_retry_at: Date;
  delivered_at: Date | null;
}

אבטחה

מפתחות לעולם לא מאוחסנים בשרתי יישום—רק ב-HSM או KMS (AWS KMS, HashiCorp Vault). שירות החתימה הוא מיקרוסרוויס מבודד עם הרשאות מינימליות. רשימת IP מותרת לנקודת הקצה של ה-webhook של הסוחר (אופציונלי). הגבלת קצב ביצירת חשבוניות: לא יותר מ-100/דקה לסוחר. ביקורת של כל הפעולות באמצעות טבלת append-only.

מה כלול בעבודה

• רשומות החלטות ארכיטקטוניות לכל החלטה מרכזית
• מפרט OpenAPI של כל נקודות הקצה של ה-API
• דיאגרמת ER של סכמת מסד הנתונים
• דיאגרמות רכיבים ורצף
• תיעוד פריסה וניטור
• גישה למאגר עם תבנית מחבר
• הדרכת צוות (סדנה של שעתיים)
• תמיכה בשלב הפיתוח (שבועיים)

תהליך התכנון

1. יום 1: איסוף דרישות—רשתות, מטבעות, נפחים, SLA, מודל סילוק, תחום שיפוט.
2. יום 2: עיצוב סכמת נתונים ושירותי ליבה.
3. יום 3: מחברי בלוקצ'יין, חוסן, אסטרטגיית ריאורג.
4. יום 4: חוזי API, אירועי webhook, SDK.
5. יום 5: סקירת אבטחה, מודל איומים, תיעוד סופי.

התוצאה היא סט מלא של ארטיפקטים לפיתוח. הודות לארכיטקטורה מחושבת היטב, לקוחות חוסכים מ-$20,000 בעבודה חוזרת. פרויקט טיפוסי מחזיר את עצמו ברבעון. קבל ייעוץ לפרויקט שלך—צור קשר.