הטמעת שחזור חברתי לארנק קריפטו לנייד

Social Recovery של ארנק קריפטו: היכן נשבר תהליך השחזור

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

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

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

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

מה נותן היישום: מהירות השחזור ומחלקת הכשלים

הגישה חוזרת תוך דקות במקום «אבודה לתמיד»

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

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

נעלמת מחלקה שלמה של כשלים, ולא מקרים בודדים

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

שחזור עצמאי מסיר עומס מהתמיכה

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

אפשרויות לשחזור גישה: השוואת גישות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מקרה בוחן: שחזור גישה בלי נקודת כשל יחידה

לפני היישום

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

על נושא הגישה היו כ-40% מכלל זרם הפניות, ושיעור השחזורים המוצלחים עמד על 62% — חלק מהמשתמשים לא השלימו את הבדיקה ועזבו בלי לקבל את הארנק בחזרה.

אחרי היישום

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

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

לאחר המעבר לתכנית החדשה, זמן שחזור הגישה הצטמצם ל-8–12 דקות — זה כל המחזור מהבקשה ועד המפתח החדש. שיעור השחזורים המוצלחים עלה ל-96–98%: התרחיש כבר אינו תלוי באדם בתמיכה. פניות בנושא גישה ירדו מ-40% לפחות מ-5% מכלל הזרם.

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

מה לעשות אם לחלק מהמשתמשים כבר יש חתימה מרובה?

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

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

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

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

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

ספקות טכניים: אמון, השהיות ואחסון נתונים

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

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

מה אם איש קשר מהימן אינו זמין?

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

היכן נשמרים הנתונים?

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

כיצד זה מתייחס לדרישות הרגולטורים?

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

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

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

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

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