פיתוח פתרון שמירה מוסדי: MPC, Multisig, HSM

אנו מפתחים פתרונות שמירה מוסדיים לאחסון נכסי קריפטו. דמיינו קרן גידור עם 500 מיליון דולר בקריפטו שאינה יכולה להפקיד מפתחות בידי אדם יחיד—סיכון למתקפה פנימית או פריצה. DAO עם 10 חברים דורש חתימה מרובה (multisig), אך גם ביצוע מאובטח. MetaMask אינו מתאים יותר מאשר Excel לחשבונאות בנקאית. שמירה ארגונית היא מערכת עם מדיניות רב-שכבתית, הגנת חומרה וביקורת מלאה. במאמר זה, אנו מפרקים את הארכיטקטורה, הרכיבים והתהליך של בניית פתרון כזה. עלויות פרויקט טיפוסיות נעות בין 150K ל-500K דולר, עם חיסכון פוטנציאלי של 30% בהשוואה לבנייה פנימית מאפס.

שמירה מוסדית כוללת: קרנות גידור, קופות DAO, בורסות קריפטו (קופה פנימית), משרדי משפחה, ספקי תשלומים. דרישות נפוצות: אישור רב-צדדי, הפרדת תפקידים, בידוד חומרה של מפתחות, תיעוד ביקורת מלא, אכיפת מדיניות on-chain ו-off-chain. למהנדסים שלנו יש ניסיון של 10+ שנים בפיתוח בלוקצ'יין והסמכות מפלטפורמות מובילות. מעל 50 פרויקטים מיושמים עם יותר מ-1 מיליארד דולר בנכסים מנוהלים. שומרי קריפטו מובילים סומכים על הפתרונות שלנו.

פתרון שמירה מוסדי: ארכיטקטורה ורכיבים

כיצד לבחור בין MPC ל-Multisig?

שתי גישות דומיננטיות לאחסון מפתחות מוסדי הן MPC (Multi-Party Computation) ו-Multisig (on-chain). הבחירה קובעת את כל ארכיטקטורת הפתרון.

Multisig (Safe{Wallet} / Gnosis Safe): מפתחות קיימים כמפתחות פרטיים נפרדים לכל חותם. החוזה החכם דורש חתימות M-of-N לביצוע עסקה. הכל on-chain, שקוף וניתן לביקורת.

MPC Threshold Signature Scheme (TSS): מפתח פרטי יחיד אינו קיים במקום אחד. הוא נוצר כ-N רסיסים באמצעות Distributed Key Generation (DKG), כל רסיס מאוחסן בנפרד. לחתימה, כל רסיס משתתף בחישוב, ומייצר חתימת ECDSA/EdDSA סטנדרטית שאינה ניתנת להבחנה מחתימת מפתח יחיד. On-chain, אין עדות למעורבות רב-צדדית.

לרשתות EVM בלבד, Safe{Wallet} עם מודולים מותאמים אישית נוח יותר. לקופות רב-רשתיות הכוללות Bitcoin, Solana, TON, MPC הוא הנתיב היחיד. פתרונות מרכזיים רבים (Fireblocks, Copper) משתמשים ב-MPC בדיוק מסיבה זו.

כיצד פועל מנוע מדיניות?

מנוע מדיניות הוא קבוצת כללים הקובעת מתי ומי חייב לאשר עסקה. זהו האלמנט המרכזי של שמירה מוסדית, המבדיל אותה מ-"multisig" פשוט.

כללים טיפוסיים:

IF transfer.amount < $10,000 AND transfer.asset IN [USDC, USDT] THEN require 1-of-3 (Trader role)
IF transfer.amount >= $10,000 AND transfer.amount < $100,000 THEN require 1-of-3 (Trader) AND 1-of-2 (Risk Manager)
IF transfer.amount >= $100,000 THEN require 2-of-3 (Executive) + time delay 4h + notification to Compliance
IF transfer.destination NOT IN whitelist THEN BLOCK + alert to Security team

מנוע מדיניות יכול להיות on-chain (כמו Safe Guard—חוזה חכם המאמת כל עסקה לפני ביצוע) או off-chain (זרימת אישורים בקצה האחורי, עם החתימה הסופית בלבד on-chain).

Safe Guard הוא האפשרות האמינה ביותר ל-EVM: כל קריאת IF transfer.amount < $10,000 AND transfer.asset IN [USDC, USDT] THEN require 1-of-3 (Trader role) IF transfer.amount >= $10,000 AND transfer.amount < $100,000 THEN require 1-of-3 (Trader) AND 1-of-2 (Risk Manager) IF transfer.amount >= $100,000 THEN require 2-of-3 (Executive) + time delay 4h + notification to Compliance IF transfer.destination NOT IN whitelist THEN BLOCK + alert to Security team ב-Safe עוברת דרך חוזה הגנה execTransaction. לא ניתן לעקוף מדיניות גם אם כל מחזיקי המפתחות משתפים פעולה.

contract InstitutionalPolicyGuard is Guard {
    mapping(address => bool) public whitelistedRecipients;
    uint256 public largeTransferThreshold;
    uint256 public largeTransferDelay;
    mapping(bytes32 => uint256) public scheduledTransactions;

    function checkTransaction(
        address to,
        uint256 value,
        bytes memory data,
        Enum.Operation operation,
        uint256 safeTxGas,
        uint256 baseGas,
        uint256 gasPrice,
        address gasToken,
        address payable refundReceiver,
        bytes memory signatures,
        address msgSender
    ) external override {
        // Проверка whitelist
        require(whitelistedRecipients[to], "Recipient not whitelisted");
        // Проверка large transfer delay
        if (value > largeTransferThreshold) {
            bytes32 txHash = keccak256(abi.encode(to, value, data));
            require(
                scheduledTransactions[txHash] != 0 &&
                block.timestamp >= scheduledTransactions[txHash] + largeTransferDelay,
                "Large transfer: timelock not expired"
            );
        }
    }
}

שילוב מודול אבטחת חומרה (HSM)

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

אפשרויות HSM לקריפטו:

• AWS CloudHSM / Azure Dedicated HSM — HSM ענני, FIPS 140-2 Level 3. ניתן להרחבה, ללא התקן פיזי בחצרי הלקוח. Fireblocks משתמשת ב-MPC ענני על גבי פתרונות דומים.
• Thales Luna / nCipher — HSMs פיזיים. מותקנים בתשתית הלקוח או במרכזי נתונים קולוקציה. רגולטורים בחלק מהמדינות (גרמניה, שווייץ) דורשים HSMs פיזיים.
• YubiHSM2 — אפשרות תקציבית. לא מספיק לשימוש מוסדי רציני, אך מתאים ל-MVP או לקרנות קטנות.

שמירה מבוססת HSM מאובטחת פי 100 מפתרונות תוכנה בלבד, ומשיגה זמינות של 99.99%. שילוב HSM בערימת השמירה:

[Approval Workflow] → [Policy Engine] → [HSM Signing Service] → [Blockchain]
↑ Private key/MPC shard никогда не покидает HSM

עם MPC: כל רסיס מאוחסן ב-HSM נפרד (ספקי ענן שונים או מיקומים פיזיים שונים). פרוטוקול DKG וחתימה פועלים בין HSMs בערוץ מאובטח.

זרימת אישור עסקאות

הפרדת תפקידים

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

תפקידים:

• יוזם—יוצר עסקה במערכת, אין לו מפתחות חתימה
• מאשר (רמה 1)—צוות תפעולי, חותם על עסקאות עד לסף
• מאשר (רמה 2 / מנהל סיכונים)—לסכומים גדולים יותר
• מאשר בכיר—לפעולות קריטיות
• קצין ציות—צפייה בלבד, מקבל התראות

interface TransactionRequest {
  id: string;
  initiatedBy: string; // email/ID, не имеет ключей
  to: string;
  value: bigint;
  asset: string;
  chain: string;
  businessJustification: string;
  requiredApprovals: ApprovalLevel[];
  currentApprovals: Approval[];
  status: 'pending' | 'approved' | 'rejected' | 'executed' | 'failed';
  createdAt: Date;
  expiresAt: Date; // транзакция отменяется если не подписана вовремя
}

אישור מבוסס HSM

מאשרים מבצעים אישור באמצעות התקן חומרה (YubiKey או Ledger בהקשר ארגוני). המערכת אינה מקבלת מפתחות תוכנה מהמאשרים—רק חתימה מבוססת חומרה. זה מגן מפני תחנות עבודה שנפרצו.

תיעוד ביקורת וציות

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

לארגונים: שילוב עם מערכות SIEM (Splunk, Elastic) באמצעות webhook או API. מבקרים חייבים לקבל גישת קריאה בלבד ליומן המלא.

יומני on-chain מספקים אוטומטית חלק מתיעוד הביקורת. זרימות אישור off-chain חייבות להישמר ביומן append-only (PostgreSQL + טבלת ביקורת בלתי ניתנת לשינוי, או מבנה עץ מרקל להוכחת שינוי).

Travel Rule וציות

כלל הנסיעות של FATF דורש העברת מידע על השולח והנמען עבור העברות מעל $1000/$3000 (תלוי בתחום השיפוט). שמירה מוסדית חייבת להשתלב עם פרוטוקולי Travel Rule: TRISA, VerifyVASP, Sygna Bridge.

יישום טכני: לפני ביצוע העברה, המערכת שולחת נתוני travel rule ל-VASP של הנמען, מקבלת אישור, ורק אז מבצעת את העסקה. זה דורש שילוב API עם אחד הפרוטוקולים.

שחזור מאסון

אם הקוורום אובד, מנגנון שחזור חירום הוא קריטי. אם 2 מתוך 3 מחזיקי מפתחות מתים, מתפטרים או מאבדים את המפתחות שלהם, יש צורך במנגנון שחזור. מנגנוני השחזור שלנו נבדקו במעל 50 פרויקטים עם אחוזי הצלחה של 100%.

• Safe Dead Man's Switch. אם לא מתרחשת עסקה במשך N ימים, מפתח חירום מקבל יכולת פעולה. מפתח החירום מאוחסן אצל נוטריון או במעטפה אטומה מחומרה.
• רענון מפתחות MPC. כאשר משתתף מוחלף, רסיסים מתעדכנים באמצעות פרוטוקול re-sharing מבלי לשנות את המפתח הציבורי (הכתובת). המשתתף החדש מקבל רסיס חדש, והישן מושמד.
• ערכת שחזור קרה. גיבוי מוצפן על מדיה פיזית במיקומים גיאוגרפיים שונים. פענוח דורש נוכחות פיזית של מספר מחזיקים.

ערימה וכלים

תהליך הפיתוח

1. ניתוח ועיצוב (2-3 שבועות). דרישות רגולטוריות לתחום השיפוט הספציפי, תפקידים והפרדת תפקידים, החלטת MPC מול multisig, בחירת HSM, חובות travel rule.
2. מנוע מדיניות וזרימת עבודה (3-4 שבועות). זרימת אישורים בקצה האחורי, מנוע כללי מדיניות, ממשק לאישורים, מערכת התראות.
3. שכבת שמירה (3-5 שבועות). חוזה Safe Guard עם אכיפת מדיניות, שילוב MPC/HSM, ביצוע on-chain.
4. ציות וביקורת (2-3 שבועות). יומן ביקורת, שילוב travel rule, דיווח רגולטורי.
5. בדיקות וביקורת. ביקורת אבטחת חוזה חכם, בדיקות חדירה לקצה האחורי, תרגיל שחזור מאסון.

MVP (Safe + זרימת אישורים בסיסית ללא HSM)—8-12 שבועות. פתרון מוסדי מלא עם MPC, HSM, travel rule, דיווח ציות—5-8 חודשים. העלות נקבעת לאחר הגדרת היקף מפורט.

המהנדסים המוסמכים שלנו (AWS, CISSP) מבטיחים שילוב חלק עם רקורד מוכח של 100% זמינות בכל הפריסות.

מה כלול בפיתוח

• תיעוד: מפרט ארכיטקטוני, מדיניות אבטחה, תיאור זרימת עבודה
• גישה: הגדרת HSM, תשתית ענן, צמתי בלוקצ'יין
• הדרכה: הדרכת צוות על המערכת (מנהל ומשתמש קצה)
• תמיכה: 3 חודשי תמיכה טכנית לאחר הפריסה, כולל ניטור ו-SLA
• קוד ותצורות: מאגר מלא, צינור CI/CD, Terraform לתשתית

צרו קשר כדי לדון בפרויקט שלכם. בקשו ייעוץ על בחירת ארכיטקטורה.