פיתוח אישורי soul-bound עם אימות on-chain

Soul-bound credentials: היכן נשברים טוקנים רגילים

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

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

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

Soul-bound credentials סוגרים זאת ברמת ההסמכה עצמה: הרשומה נקשרת לכתובת של המקבל, ופעולת ההעברה מבוטלת על ידי לוגיקת החוזה — ההסמכה הופכת לבלתי ניתנת להעברה.

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

נפרט כיצד זה בנוי והיכן עובר הגבול בין טוקן שניתן להעביר לבין הסמכה בלתי ניתנת להעברה.

מה נותנת הסמכה בלתי ניתנת להעברה במרשם

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

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

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

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

מצבי הנפקה ואימות של הסמכות

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

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

שלבי הטמעה: מביקורת דרישות ועד למסירה

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

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

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

תצורה, סכימות ותקנוני הנפקה

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

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

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

מקרה בוחן: מרשם תעודות עם שלילה ובדיקה

כיצד זה היה

את התעודות הנפיקו בנייר וב-PDF, ואת האותנטיות אישרו בבקשה כתובה למחלקה האקדמית: התשובה ארכה עד שלושה ימי עבודה, ובעונת ההנפקות התור גדל.

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

מה נבנה ומה זה הניב

רשומת ההסמכה מונפקת כטוקן soulbound לכתובת הבוגר: הוא אינו ניתן להעברה ואינו נמכר, והמטא-נתונים מכילים את המקצוע, השנה והגיבוב של המקור בנייר.

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

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

במה נבדלים soul-bound credentials מטוקנים רגילים

טוקן רגיל הוא תעודת בעלות: הוא מועבר, נמכר וממושכן, וערכו נקבע על ידי השוק. Soul-bound credentials בנויים אחרת — זוהי רשומה הנקשרת לחשבון הבעלים: תעודה, אישור, הרשאה. משמעותה היא בדיוק באי-ניתנות להעברה: אין אפשרות להעביר או למכור רשומה כזו.

איסור ההעברה מוטבע בחוזה עצמו: אין מתודת העברה ציבורית, וקריאות עוקפות, כולל העברה באמצעות אישור מפעיל, מבוטלות על ידי הטרנזקציה. בתקנים מוכרים כמו ERC-721 ההעברה היא חלק חובה מהלוגיקה; כאן מסירים אותה במכוון ומחליפים בסירוב מוחלט.

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

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

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

שלילה, פרטיות, מיגרציה: ספקות טכניים

הספקות הטכניים סביב soul-bound credentials מצטמצמים לארבעה: אובדן מפתח בידי הבעלים, שלילת הסמכה שכבר הונפקה, היקף הנתונים שעוברים לחלק הציבורי, והעברת מרשם בלי הנפקה מחדש. כל אחד מהם נסגר במנגנון שמוטבע בארכיטקטורה מראש, ולא בתיקון ידני בדיעבד.

כיצד לשלול הסמכה אם היא כבר בידי המחזיק?

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

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

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

נדון במשימה: מה להכין לשיחה

כדי לחזור עם הערכת היקף העבודה ולא עם שאלות הבהרה, די בכמה נתוני פתיחה לשיחה הראשונה. הם בדיוק מגדירים את ארכיטקטורת ההנפקה והבדיקה של soul-bound credentials — ממודל המרשם ועד נוהל השלילה — ואנחנו על בסיסם מרכיבים תוכנית הטמעה והרכב צוות.

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

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