פיתוח ארנק MPC סוהרי (Custodial) למוסדות

אנו בונים ארנקי MPC סוהריים שבהם המפתח הפרטי לעולם אינו קיים בצורתו המלאה באף מכשיר. במקום זאת, כל צד מחזיק ב"חלק" (share) של המפתח, וחתימות עסקאות מחושבות במשותף באמצעות פרוטוקול MPC. גניבת חלק אחד חסרת תועלת—נדרשת השתתפות של כל הצדדים בתוכנית לחתימה. ארכיטקטורה זו מבטלת את נקודת הכשל היחידה והופכת את הארנק לעמיד בפני פריצה לשרת: גם אם תוקף משיג גישה לחלק השרת, הוא אינו יכול לחתום על עסקה ללא חלק המשתמש. למהנדסים שלנו יש ניסיון של 10+ שנים בפיתוח בלוקצ'יין וקריפטוגרפיה, עם למעלה מ-20 פרויקטים מוצלחים של ארנקי MPC שנמסרו לבורסות ולסוהרים (Custodians). אנו מבטיחים שהשירות שלך יקבל אחסון ברמה מוסדית ללא נקודת כשל יחידה. זהו אחסון קריפטו ארגוני ברמה חדשה—ארנק ללא ביטוי גיבוי (Seed Phrase), שבו הגישה משוחזרת באמצעות חלק גיבוי.

זהו הבדל מהותי מחתימה מרובת-חתימות (Multisig) מסורתית על-גבי הבלוקצ'יין (M-of-N): Multisig נראה על הבלוקצ'יין, דורש N חתימות על-גבי הרשת (גז), והעובדה שנעשה שימוש ב-Multisig היא פומבית. חתימת MPC נראית כמו חתימה רגילה בודדת—לא הבלוקצ'יין ולא צופה חיצוני יכולים לראות שהיא נוצרה מחישוב משותף. Fireblocks, ZenGo, Coinbase WaaS, Web3Auth—כולם מוצרים מבוססי MPC. המגזר הבנקאי והמוסדי עובר ל-MPC דווקא בגלל היעדר נקודת כשל יחידה באחסון מפתחות. חיסכון בגז יכול להגיע ל-50% בהשוואה ל-Multisig על-גבי הבלוקצ'יין; לקוחות בדרך כלל רואים הפחתה של 40-60% בעמלות עסקה.

תפעול ארנק MPC

פרוטוקול חתימת סף (Threshold Signature Scheme - TSS)

עבור Ethereum (secp256k1), הפרוטוקול הנפוץ ביותר הוא GG20 (Genaro-Goldfeder 2020) או הגרסה המשופרת שלו CGGMP21. סכמת t-of-n: כל t מתוך n משתתפים יכולים לחשב חתימה; ללא t, זה בלתי אפשרי. הפרוטוקול דורש 3 סבבים ליצירת מפתחות (Keygen) (כל אחד ~200 בתים) ו-2 סבבים לחתימה.

התהליך מורכב משני שלבים:

• יצירת מפתחות (Keygen - יצירת מפתח מבוזרת): המשתתפים מייצרים חלקים (Shares) באופן אינטראקטיבי מבלי לחשוף את המפתח הסופי. עם השלמתו, לכל אחד יש share_i, והמפתח הציבורי P = G * privateKey ידוע לכולם. המפתח הפרטי privateKey לעולם אינו קיים בשום מקום.
• חתימה: כדי לחתום על עסקה, t משתתפים מריצים את פרוטוקול MPC, כל אחד מזין את share_i שלו, והפלט הוא חתימת ECDSA תקפה. אף משתתף אינו לומד את המפתחות של האחרים.

ספריות MPC אמיתיות

יישומים מוכנים לייצור:

• tss-lib (Binance): ספריית Go, מיישמת GG18/GG20. בשימוש ב-Binance Chain, Thorchain. קוד פתוח.
• multi-party-ecdsa (ZenGo): Rust, מיישמת GG20. עדכנית יותר, עם תמיכה פעילה.
• @sodot/sodot-node-sdk: SDK מסחרי עבור MPC-as-a-service. התחלה מהירה, אין צורך ליישם את הפרוטוקול בעצמך. רישוי ~$5,000–$20,000 לשנה.
• Silence Laboratories SDK: יישום מאומת אקדמית, בשימוש ב-Web3Auth עבור MPC כשירות.

יישום פרוטוקול MPC בעצמך לוקח חודשים של זמן קריפטוגרף ונושא סיכון גבוה לשגיאות. עבור רוב הפרויקטים, הבחירה הנכונה היא ספרייה מוכנה או MPC-as-a-service.

בחירת ספריית MPC

למה ארנק MPC עדיף על Multisig

MPC מוצדק עבור: אחסון מוסדי, ארנקים-כשירות (Wallets-as-a-service), ארנקים ללא ביטוי גיבוי (ממוקדי מובייל), ארנקים מוטמעים באפליקציות. Gnosis Safe (Multisig על-גבי הבלוקצ'יין) מוצדק עבור: קופות DAO, ארנקי צוות, מקרים שבהם נדרשת שקיפות מקסימלית על-גבי הבלוקצ'יין. ארנקי MPC תואמים לחלוטין לכל רשת EVM, מה שהופך אותם לאידיאליים עבור פרוטוקולי DeFi וארנקים-כשירות. לקוחות חוסכים עד 50% בעלויות גז ונמנעים מהמורכבות של Multisig.

ארכיטקטורת ארנק MPC 2-of-2

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

השרת אינו יודע את המפתח המלא. המכשיר אינו יודע את המפתח המלא. ללא השרת, המשתמש אינו יכול לחתום (הגנה מפני גניבת מכשיר). ללא המכשיר, השרת אינו יכול לחתום (השרת אינו יכול לגנוב כספים).

תהליך יצירת מפתחות (Keygen)

// Упрощённая иллюстрация flow (не production-ready код)
import { MpcSigner } from '@sodot/sodot-node-sdk';

class MPCWallet {
  private deviceSdk: MpcSigner;
  private serverSdk: MpcSigner;

  async generateKey(): Promise<string> {
    const keygenId = crypto.randomUUID();
    const [deviceShare, serverShare] = await Promise.all([
      this.deviceSdk.initKeygen(keygenId, { threshold: 2, parties: 2, partyIndex: 1 }),
      this.serverSdk.initKeygen(keygenId, { threshold: 2, parties: 2, partyIndex: 2 }),
    ]);
    await this.runKeygenRounds(keygenId, deviceShare, serverShare);
    const publicKey = await this.deviceSdk.getPublicKey(keygenId);
    const address = ethers.computeAddress('0x' + publicKey);
    await this.deviceSdk.storeShare(keygenId, deviceShare);
    await this.serverSdk.storeShare(keygenId, serverShare);
    return address;
  }

  async signTransaction(address: string, transaction: ethers.TransactionRequest): Promise<string> {
    await this.authenticateUser();
    const txHash = ethers.keccak256(ethers.Transaction.from(transaction).unsignedSerialized);
    const signingId = crypto.randomUUID();
    const signature = await this.runSigningProtocol(signingId, txHash, address);
    const signedTx = ethers.Transaction.from({ ...transaction, signature });
    return signedTx.serialized;
  }
}

רענון חלקים (אבטחה פרואקטיבית)

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

async function refreshShares(walletId: string): Promise<void> {
  await Promise.all([
    deviceSdk.refreshShare(walletId),
    serverSdk.refreshShare(walletId),
  ]);
}

setInterval(() => {
  for (const walletId of activeWallets) {
    refreshShares(walletId).catch(console.error);
  }
}, 7 * 24 * 60 * 60 * 1000);

שחזור גישה בעת אובדן מכשיר

לסכמת 2-of-2 יש חולשה: אם השרת אינו זמין, המשתמש אינו יכול לחתום על עסקאות. סכמת 2-of-3 פותרת זאת:

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

פעולה רגילה: מכשיר + שרת = חתימה. אם השרת אינו זמין: מכשיר + גיבוי = חתימה (שחזור חירום). אם המכשיר אבד: שרת + גיבוי = שחזור למכשיר חדש.

async function recoverToNewDevice(
    backupShare: CloudEncryptedShare,
    backupPassword: string
): Promise<string> {
    const decryptedBackup = await decryptBackupShare(backupShare, backupPassword);
    await verifyUserIdentity();
    const newDeviceShare = await sdk.refreshWithParties([serverShare, decryptedBackup]);
    await secureStore.save(newDeviceShare);
    return 'Recovery complete';
}

ערוץ תקשורת בין הצדדים: פרוטוקול MPC דורש מספר סבבים של החלפת הודעות בין המשתתפים. עבור 2-of-2 (מכשיר + שרת), WebSocket הוא אופטימלי—השהייה מינימלית. שאילתות REST פשוטות יותר אך מוסיפות 0.5-2.5 שניות לחתימה. זמן חתימת MPC טיפוסי: 0.5-2 שניות עם תנאי רשת טובים. הצג התקדמות בממשק המשתמש.

תשתית שרת

חלק השרת חייב להיות מאוחסן במודול חומרה מאובטח (HSM)—מכשיר פיזי שממנו בלתי אפשרי לחלץ את המפתח באופן תוכנתי. אפשרויות: AWS CloudHSM (FIPS 140-2 Level 3), AWS KMS (תוכנה), HashiCorp Vault (מתארח עצמאית). עבור סטארטאפ, AWS KMS + הצפנה במנוחה מספיקים. HSM מיועד לשלב שבו תגדל ללקוחות מוסדיים.

אימות לפני חתימה

השרת מאמת שבקשת החתימה יזומה על ידי משתמש מורשה (JWT לאחר ביומטריה). בנוסף, מוחלות מדיניות עסקאות: מגבלות, רשימות כתובות מורשות, דרישת אימות נוסף עבור סכומים גדולים.

מה כלול בתוצרים (Deliverables)

בהזמנת פתרון ארנק MPC סוהרי, אתה מקבל את התוצרים הבאים:

• עיצוב ארכיטקטורה ובחירת פרוטוקול MPC (סכמת t-of-n)
• אינטגרציה של ספריית MPC (tss-lib / multi-party-ecdsa / Sodot SDK)
• יישום תהליכי יצירת מפתחות וחתימה עם אחסון חלקים
• אפליקציית מובייל/אינטרנט עם UX עבור התחברות, עסקאות ושחזור
• צד שרת: שירות אימות, API לחתימה, מנוע מדיניות, אינטגרציית HSM
• סקירת אבטחה ובדיקת חדירה (Pentest) (פרוטוקול MPC + תשתית)
• תיעוד מלא: מסמכי ארכיטקטורה, הפניות API, מדריכי פריסה
• גישה לקוד המקור דרך מאגר פרטי
• הדרכות למנהלים ולמפתחים
• תמיכה בהשקה ו-6 חודשים של תחזוקה לאחר ההשקה

התוצרים כוללים תיעוד מקיף, גישה לקוד המקור, הדרכת מנהלים ו-6 חודשים של תמיכה טכנית.

תהליך עבודה

1. עיצוב ארכיטקטוני (1-2 שבועות): בחירת פרוטוקול MPC, חלוקת חלקים, תהליכי גיבוי/שחזור, תשתית שרת.
2. יישום יצירת מפתחות וחתימה (3-4 שבועות): אינטגרציית ספריית MPC, ערוץ תקשורת, אחסון חלקים.
3. אפליקציית מובייל/אינטרנט (2-3 שבועות): UX התחברות, תהליך עסקה, מחווני התקדמות, ממשק שחזור.
4. צד שרת (2-3 שבועות): אימות, API לחתימה, מנוע מדיניות, אינטגרציית HSM.
5. סקירת אבטחה (2 שבועות): ניתוח אבטחת פרוטוקול, בדיקת חדירה, סקירת אחסון חלקים.
6. בדיקות והשקה (1-2 שבועות): בדיקות מקצה-לקצה, בדיקות עומס.

מחזור ארנק MPC מלא: 4-6 חודשים. עלות הפיתוח מתחילה ב-$150,000 עבור סכמת 2-of-2 בסיסית, ונעה עד $300,000 עבור פתרון ארגוני מותאם אישית מלא. זה מורכב יותר מארנק רגיל בגלל פרוטוקול MPC והצורך במומחיות קריפטוגרפית. העלות מחושבת לאחר פירוט הסכמה ובחירת ספריית MPC.

אנו נעריך את הפרויקט שלך בחינם—צור קשר כדי לדון בארכיטקטורה. קרא גם על Secure multi-party computation להבנה כללית של הטכנולוגיה. עם ניסיון של למעלה מ-10 שנים בבלוקצ'יין ו-20+ פרויקטים, אנו מספקים אחסון ברמה מוסדית. קבל ייעוץ לפרויקט שלך—המהנדסים שלנו יענו על שאלות טכניות.