פיתוח מערכות זהות דיגיטלית

זהות דיגיטלית על בלוקצ'יין: DID, SBT ואישורים ניתנים לאימות

לעתים קרובות אנו נתקלים בבקשות שבהן פרויקט Web3 בנה מאגר AMM או פרוטוקול הלוואות, אך עדיין מאמת משתמשים עם JWT ו-MongoDB. זה יוצר סתירה מהותית — האפליקציה טוענת שהיא מבוזרת, אך זהות המשתמש נשענת על שרת יחיד. עבור מערכות זהות דיגיטלית ב-Web3, גישה זו נכשלת בדרישות רגולציה (KYC ל-DeFi, משקיעים מוסמכים) ופוגעת במוניטין על-השרשרת ב-DAO. אנו מתמחים בבניית מערכות זהות דיגיטלית לפרויקטי Web3 — מ-SIWE ועד מחסנית DID/VC מלאה. הניסיון שלנו — 80+ פרויקטי בלוקצ'יין — מראה שארכיטקטורת זהות חייבת להיות מבוזרת מההתחלה.

כיצד Sign-In with Ethereum פותר אימות?

EIP-4361 (SIWE) מסיר לחלוטין התחברות/סיסמה. המשתמש חותם על הודעה מובנית עם הארנק שלו; השרת האחורי מאמת את החתימה באמצעות ecrecover. אין דליפת אישורים, אין hashing של סיסמאות.

יישום: ספריית siwe (JS/TS) בפרונטאנד, SiweMessage.verify() בשרת האחורי. ההודעה כוללת דומיין, כתובת, nonce (אקראי, חד-פעמי), הצהרה, ותפוגה. ה-nonce נשמר ב-Redis עד לאימות — הגנה מפני התקפות replay. כיום, SIWE נמצא בשימוש על ידי למעלה מ-80 פרויקטים ב-100 המובילים ב-DeFi.

טעות קריטית שאנו מוצאים בביקורות: חוסר אימות של דומיין ו-chain ID. אם השרת האחורי לא בודק את message.domain מול הדומיין בפועל, תוקף יכול לעשות שימוש חוזר בחתימת SIWE מאתר אחר. ראינו מספר dApps שאיבדו חשבונות בשל כך — כל שחזור עלה סכומים משמעותיים (לעתים קרובות >$50,000 בפיקדונות שאבדו).

עבור אפליקציות מובייל, SIWE עובד דרך WalletConnect v2: QR או deeplink, חתימה בארנק, callback לשרת האחורי. WalletConnect משתמש ב-Sign API (נפרד מ-Transaction API), סשנים מוצפנים עם X25519 + ChaCha20-Poly1305.

SIWE אמין פי 3 מסשני JWT מסורתיים: אימות חתימה באמצעות did:method:identifier מוכיח בעלות על מפתח, לא רק ידיעת סיסמה. עלויות ניהול סשן מופחתות ב-40–60% — אין hashing של סיסמאות, אין איפוס סשן. עבור פרוטוקול DeFi גדול, זה חוסך עד $70,000 בשנה על תשתית.

מה זה DID ואיזו שיטה לבחור?

DID (מזהה מבוזר) — תקן W3C למזהים מבוזרים — הוא מחרוזת did:ethr. השיטה מגדירה היכן מאוחסן מסמך ה-DID וכיצד הוא נפתר (ראה ויקיפדיה: מזהה מבוזר). השיטות העיקריות בהן אנו משתמשים בייצור:

עבור רוב פרויקטי ה-DeFi, did:key או did:web מספיקים. מסמך DID מכיל שיטות אימות (מפתחות ציבוריים, עד 10 מפתחות למסמך), authentication, assertionMethod, נקודות קצה לשירות (למשל, קישור לשירות KYC). אנו מבטיחים שהשיטה שנבחרה תואמת לשרשראות היעד (Ethereum, Polygon, Arbitrum, Optimism, Base) ומונעת עיצוב מחדש של ממשק.

טעויות נפוצות בבחירת שיטת DID:

• בחירת did:ethr ללא הבנת הריכוזיות — אם דומיין ה-DNS נחטף, הזהות נפגעת.
• התעלמות מרוטציית מפתחות — did:key מאפשר הוספה/הסרה של מפתחות, בעוד did:ion לא.
• חוסר גיבוי L2 לתפוקה גבוהה — בעומס שיא, Ethereum mainnet יכול להיות עמוס במשך שעות; אנו משתמשים ב-@context או L2.

כיצד עובד אימות באמצעות אישורים ניתנים לאימות?

אישור ניתן לאימות (VC) — הצהרה חתומה ממנפיק על נושא. פורמט W3C: JSON-LD או JWT. מבנה: type, issuer, credentialSubject (DID), proof, ICircuitValidator (חתימת מנפיק).

תרחיש מעשי: ספק KYC (מנפיק) מאמת משתמש ומנפיק VC 'גיל ≥ 18, לא ברשימת OFAC'. המשתמש מאחסן את ה-VC מקומית (הרחבת ארנק או אפליקציית מובייל). בעת גישה לפרוטוקול, המשתמש מציג Presentation ניתן לאימות — מיכל עם ה-VC חתום על ידי המשתמש. הפרוטוקול מאמת את חתימת המנפיק (דרך מסמך ה-DID של המנפיק) ואת חתימת המחזיק. אין נתונים אישיים שעולים על-השרשרת. הפרוטוקול אינו מאחסן מסד נתונים של משתמשים שעברו KYC. זו עמידה ברגולציה תוך שמירה על פרטיות — בדיוק מה ש-DeFi מפוקח צריך.

הוכחות אפס ידע עבור VCs לוקחות את הפרטיות לרמה אחרת. במקום להציג את כל האישור, המשתמש מוכיח תכונה ספציפית (למשל, גיל ≥ 18) מבלי לחשוף את הערך. כלים: Polygon ID (Iden3 zkSNARK), Sismo (תגי ZK), Semaphore (חברות בקבוצה). Polygon ID מיישם אימות zkProof ישירות בחוזים חכמים דרך transferFrom. המהנדסים המוסמכים שלנו בעלי ניסיון בשילוב סכמות ZK כאלה בפרוטוקולים אמיתיים — לקוחות חוסכים עד 70% בעלויות KYC (לעתים קרובות $100,000+ בשנה).

מדוע אסימוני Soulbound אינם מתאימים לאימוץ המוני?

SBTs (EIP-5192, קונספט של ויטליק בוטרין) הם NFTs שאינם ניתנים להעברה. יישום: ERC-721 סטנדרטי עם ERC-5192 שעבר override ותמיד חוזר revert, או locked() עם IEAS.getAttestation(uid).

שימושים בייצור:

• ממשל DAO — Snapshot + SBT להצבעה של אדם אחד-קול אחד. Gitcoin Passport בונה מוניטין מחותמות on-chain ו-off-chain ומנפיק מקבילות SBT (ציון Gitcoin דרך Ceramic/EAS).
• אישורי השכלה — Buildspace הנפיקו NFTs לקורסים, POAP להוכחת נוכחות. SBTs הופכים אותם לבלתי ניתנים להעברה — אי אפשר לקנות היסטוריה של מישהו אחר.
• דירוג אשראי על-השרשרת — Spectral Finance בונה ציון MACRO מהיסטוריית on-chain, וכתוצאה מכך SBT עם ציון מספרי. פרוטוקולי הלוואות משתמשים בו להלוואות עם בטחונות חלקיים.

מגבלה טכנית מרכזית: מנגנון שחזור. אובדן גישה לארנק משמעותו אובדן כל ה-SBTs. ללא שחזור, אימוץ המוני בלתי אפשרי. פתרונות: ארנק שחזור חברתי (Guardian, כמו Argent), DID עם מפתחות מרובים ורוטציה, גיבוי off-chain באמצעות Shamir Secret Sharing. אנו כוללים תכנון שחזור בכל פרויקט SBT.

שירות האישורים של Ethereum כשכבת זהות סטנדרטית

EAS פרוס על Ethereum mainnet, Optimism, Arbitrum, Base. כל כתובת יכולה להנפיק אישורים on-chain או off-chain המבוססים על סכמות רשומות. סכמה היא מבנה מקודד ABI. החותם חותם על נתונים ומתעד אותם על-השרשרת (עם גז) או off-chain עם עיגון IPFS/Ceramic. מאמתים קוראים דרך IEAS.getAttestation(uid).

EAS כבר משולב במערכת האקולוגית של Base (Coinbase משתמשת בו לאימות), Gitcoin (חותמות Passport), Optimism (תרומות RetroPGF). הוא הופך לסטנדרט דה-פקטו לשכבת זהות על-השרשרת ב-L2. המפתחים שלנו מוסמכים ל-EAS (ניסיון עם 5+ פרויקטים). לפי תיעוד EAS, ניתן לבטל אישורים, וסכמות תומכות בעד 32 שדות של סוגי ABI שרירותיים.

כיצד לבחור את פתרון הזהות המתאים לפרויקט שלך?

1. אנליטיקה ועמידה ברגולציה — מיפוי מסע המשתמש: מי המנפיק, מי המאמת, אילו נתונים נדרשים, מה אסור לאחסן על-השרשרת לפי GDPR.
2. עיצוב ארכיטקטורה — בחירה בין SBT על-השרשרת, EAS, מחסנית DID/VC. סכמת נתונים, מעגל ZK (אם נדרש).
3. יישום — חוזים חכמים (Solidity 0.8.x, Foundry/Hardhat), שירות מנפיק (Node.js/Go), ארנק מחזיק (ethers.js viem), חוזה מאמת.
4. בדיקות וביקורת — בדיקות יחידה, בדיקות אינטגרציה, fuzzing (Echidna), ניתוח סטטי (Slither). גיוס מבקר חיצוני.
5. פריסה ותמיכה — פריסה לרשתות יעד, ניטור (Tenderly), תיעוד, הדרכת צוות.

תוצרים

• קוד מקור של חוזים חכמים (Solidity, בקוד פתוח תחת MIT)
• שרת אחורי למנפיק (Node.js/Go) עם API להנפקת VC/SBT
• אינטגרציית ארנק מחזיק (ethers.js viem, RainbowKit, WalletConnect)
• חוזה/סקריפט מאמת
• תיעוד ארכיטקטורה, מדריך פריסה
• חודשיים תמיכה לאחר פריסה

הערכות לוחות זמנים

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

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