פיתוח מערכת הפרדת נכסים לנאמן

תארו לעצמכם: נאמן עם מיליוני לקוחות, כל הנכסים בארנק חם אחד. במקרה של פשיטת רגל — תביעות משפטיות, לקוחות לא יכולים להוכיח את חלקם. לפי Chainalysis, הפסדים מתקריות כאלה מגיעים ל-2 מיליארד דולר בשנה. נשמע מוכר? אנו מפתחים מערכות נאמנות עם הפרדת נכסים קפדנית כדי למנוע זאת. כל לקוח רואה את כספו בכתובת ייחודית או בחשבונאות מוצפנת. עם יותר מ-20 פרויקטים שהושלמו, יש לנו את הניסיון לבנות מערכת חזקה ומוכנה לביקורת.

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

מדוע הפרדת נכסים היא חובה?

רגולטורים (MiCA באיחוד האירופי, FCA בבריטניה) דורשים במפורש הפרדה של נכסי לקוחות מנכסי הנאמן עצמו. לפי סעיף 36 של MiCA, נאמנים חייבים להבטיח הפרדת נכסים. עבור נאמני קריפטו בארה"ב, BitLicense כבר כולל דרישות הפרדה. מבקר חייב להתאים כתובות on-chain לרישומי לקוחות — הנכסים של לקוח א' אסור שיתערבבו עם אלה של לקוח ב'. הפרה מובילה לאובדן רישיון ולתביעות משפטיות.

השוואת מודלים ארכיטקטוניים

המודל ההיברידי מאזן בין אבטחה לעלות — הוא יעיל פי 3 ממודל וירטואלי טהור ומפחית עלויות תפעול ב-30-40% לעומת הפרדה מלאה. ללקוחות גדולים — כתובות ייעודיות; לקמעונאות — הפרדה וירטואלית עם אפשרות שדרוג.

כיצד המערכת עובדת?

הפרדה מלאה

כל לקוח מקבל כתובת on-chain ייחודית (או קבוצה לכל בלוקצ'יין). הנכסים מופרדים פיזית ברמת הבלוקצ'יין. זה מספק שקיפות מקסימלית, הוכחת בעלות פשוטה ובידוד סיכונים. החיסרון הוא עלויות תפעול גבוהות עם לקוחות רבים.

ניהול כתובות

המפתחות מאוחסנים ב-HSM. כתובות נוצרות דטרמיניסטית באמצעות גזירת HD:

m/44'/60'/{clientId}'/0/0 → основной адрес клиента
m/44'/60'/{clientId}'/0/1 → адрес для конкретного актива
m/44'/60'/{clientId}'/1/0 → change адрес

זה מאפשר שחזור של כל הכתובות מהזרע הראשי ללא אחסון נוסף.

חשבונאות ספר ראשי

חשבונאות כפולה היא חובה. כל תנועת נכסים מאוזנת:

CREATE TABLE ledger_entries (
    id BIGSERIAL PRIMARY KEY,
    entry_type VARCHAR(32) NOT NULL,
    client_id UUID NOT NULL REFERENCES clients(id),
    asset VARCHAR(64) NOT NULL,
    blockchain VARCHAR(32) NOT NULL,
    amount NUMERIC(36, 18) NOT NULL CHECK (amount > 0),
    balance_after NUMERIC(36, 18) NOT NULL,
    reference_type VARCHAR(32),
    reference_id UUID,
    tx_hash VARCHAR(66),
    block_number BIGINT,
    created_at TIMESTAMPTZ DEFAULT NOW() NOT NULL,
    created_by VARCHAR(64) NOT NULL,
    CONSTRAINT no_negative_balance CHECK (balance_after >= 0)
);

התאמה — התאמה יומית של יתרות on-chain עם רשומות הספר הראשי. אם הפער עולה על 0.1% מהיתרה הכוללת, המערכת מתריעה.

ניטור הפקדות

המערכת עוקבת אחר כל העסקאות הנכנסות באמצעות מנוי WebSocket לבלוקים חדשים. עבור ERC-20, היא מנטרת אירועי Transfer. לאחר 12-20 אישורים, הכספים מזוכים. אנו מעבדים עד 10,000 הפקדות בשעה לכל בלוקצ'יין.

משיכות

משיכה דורשת אישור מרובה. לאחר האישור: בדיקת יתרה, הזמנה, חתימה ב-HSM, שידור, המתנה ל-6-12 אישורים, חיוב סופי. לכל בקשה יש מפתח אידמפוטנטיות ייחודי למניעת כפילויות.

יישום הוכחת יתרות

להוכחת כושר פירעון פומבית, אנו בונים עץ מרקל מיתרות הלקוחות:

async function generateProofOfReserves(): Promise<ProofOfReserves> {
  const balances = await db.getAllClientBalances();
  const leaves = balances.map(b => keccak256(encode(['address', 'uint256'], [b.address, b.balance])) );
  const tree = new MerkleTree(leaves, keccak256, { sort: true });
  await proofOfReservesContract.updateRoot(tree.getRoot());
  return {
    root: tree.getRoot(),
    totalBalance: balances.reduce((sum, b) => sum + b.balance, 0n),
    timestamp: Date.now(),
    proofs: balances.map((b, i) => ({
      clientId: b.clientId,
      proof: tree.getProof(leaves[i]),
    })),
  };
}

כל לקוח מקבל הוכחת הכללה של יתרתו בעץ מבלי לחשוף נתוני אחרים. השורש מתפרסם על ה-chain, מה שמאפשר ביקורת עצמאית. אנו מבטיחים שיעור מעבר ביקורת של 99.9%.