ארנק מולטי-צ'יין: היכן נשברת החתימה ורישום היתרות
הבלוקצ'יין הראשון בארנק מולטי-צ'יין כמעט תמיד עובד באופן צפוי: מודל חשבון אחד, סכמת חתימה אחת על טרנזקציות, דרך אחת לחשב יתרה. הרשת השנייה והשלישית שוברות את ההנחות האלה — והדבר מתבטא לא בממשק, אלא בשני מקומות: בהרכבה ובחתימה של טרנזקציות וברישום היתרות.
כתובות ומפתחות ברשתות שונות בנויים באופן שונה: מחרוזת hex, base58, bech32 עם ספרת ביקורת — מנמוניקה אחת מולידה נתיבי גזירה שונים, ואי אפשר לאמת כתובת בבדיקת אורך פשוטה.
אם שכבת החתימה נכתבה עבור רשת אחת, נמשך לתוכה מודל החשבון שלה וסדר מספור הפעולות, והחתימה על טרנזקציות הופכת תקפה לא במקום שמצפים לה.
רישום היתרות מורכב יותר: "יתרה" היא לפחות שלושה מספרים שונים. מאושרת על הצומת, זמינה להוצאה בהתחשב בפעולות שכבר נשלחו וטרם נכללו, וממתינה לסופיות. אם הארנק מציג אחד מהם כסכום סופי, נוצרת אי-התאמה במצב: החיוב עבר, אבל הסכום לא השתנה, או שזמין יותר ממה שבאמת יש.
צרה נפרדת — טרנזקציות תקועות. ברשתות עם מודל מבוסס חשבון מספר פעולה שהוחמץ חוסם את כל התור שאחריו, ובלי החלפה או שליחה מחדש מפורשת הארנק פשוט מפסיק להזיז כספים. היכן שהסופיות הסתברותית, ביטול בלוק מאפס חיובים שכבר נרשמו ומוסיף כפילויות של פעולות שלא נרשמו.
אנחנו מפרקים איך זה נסגר: שכבת חתימה אחודה עם תיאור של כל רשת, רישום יתרות בלתי תלוי לפי כל ערוץ, ועבודה מנוהלת עם פעולות תקועות ופעולות שהוחזרו לאחור.
מה נותנת שכבת חתימה ורישום אחודה בכל הרשתות
שכבת חתימה אחודה מסירה את הסיבה העיקרית לאי-התאמות בין רשתות: לכל אחת פורמט כתובת משלה, מודל מפתחות משלה ומונה טרנזקציות יוצאות משלה. כשהלוגיקה הזו חיה במודול אחד, חיבור רשת חדשה מצטמצם לתיאור הכללים שלה בקונפיגורציה, ולא לענף קוד נפרד.
זמן החיבור של רשת חדשה נמדד בימים, לא בשבועות: המהנדס מוסיף סכמת יצירת חתימה וכלל בחירת צומת — השאר עובד כמו שהוא.
רישום הפעולות נבנה סביב יומן מצבים אחוד: טרנזקציה נרשמת בכל שלב — נוצרה, נחתמה, נשלחה, אושרה. אם אישור לא הגיע בתוך חלון החישוב, הפעולה לא תוקעת בבלתי-ידוע, אלא חוזרת לבדיקה ונשלחת מחדש עם מונה נכון.
שיעור הפעולות התקועות יורד לאחוזים בודדים, ומקטגוריית הכשלים יוצא היקר ביותר — שימוש חוזר במונה ושליחה כפולה.
עמידות לתקלות נשענת על כמה צמתים לכל רשת: שכבת החתימה משווה את גובה הבלוק ואת אי-ההתאמה במצב, ובמקרה של הדרדרות של צומת מעבירה את הזרימה לגיבוי. זמן ההתאוששות אחרי תקלת צומת — דקות, ומשך זמן ההשבתה לא גדל יחד עם מספר הרשתות המחוברות.
בנפרד נסגרת קטגוריית כשלים שבה החתימה יצאה והטרנזקציה אבדה: היומן שומר את החבילה החתומה, והיא מובאת לרשת שוב.
בסך הכול חמישה אפקטים מדידים: זמן חיבור רשת חדשה, שיעור הפעולות התקועות, זמן ההתאוששות אחרי תקלת צומת, משך זמן ההשבתה וקטגוריית כשלים שנעלמה. כולם נלקחים ממסך ניטור אחד, ולכן הדרדרות נראית לפני שמשתמשים כותבים עליה.
דרכים לחבר ארנק מולטי-צ'יין: השוואת מצבים
ארנק מולטי-צ'יין חותם על טרנזקציות בכמה רשתות בבת אחת, וההחלטה המרכזית כאן היא היכן חי מודול החתימה וכמה הוא מבודד משאר הקוד. מזה תלויים מצבי העבודה, משטח התקיפה, והאופן שבו אפשר אחר כך להחליף סכמה בלי לכתוב מחדש את הלקוח.
יש שלוש אפשרויות: הבחירה נקבעת לפי מספר הפלטפורמות, דרישות לאישור הפעולה בידי הבעלים והעומס.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| מודול חתימה מובנה | לקוח אחד, פלטפורמה אחת, מסלול קצר עד שחרור | המפתח חי בזיכרון התהליך; החלפת סכמה היא שחרור של האפליקציה; מתקשה להתאים את עצמו לכמה פלטפורמות |
| שירות חתימה נפרד | כמה לקוחות, מדיניות אחודה ויומן פעולות | ערוצי אמון, אימות לקוחות, תור וביקורת; השירות עצמו הופך לנקודת כשל |
| היברידי עם מפתחות חומרה | סכומים גדולים, אישור הפעולה בידי הבעלים | סף לפי מספר פעולות, עדכוני קושחה, חלק מהתרחישים דורשים נוכחות של הבעלים |
המצבים תואמים זה לזה אם מוציאים את חוזה החתימה לשכבה נפרדת: מודול מובנה ושירות חתימה מממשים ממשק אחד, ומפתחות חומרה מתחברים כמבצע נוסף. אז המעבר בין סכמות הוא החלפת מימוש, ולא כתיבה מחדש של לוגיקת העסק ורישום הכתובות.
שלבי יישום: מביקורת רשתות ועד מסירת נהלים
סדר העבודות בנוי כך שהחלטות בלתי הפיכות — סכמת אחסון מפתחות, פורמט חתימה, מודל רישום — יתקבלו רק אחרי שנאספה תמונה מלאה על כל הרשתות. תחילה מיפוי, אחר כך תכנון, ורק לאחר מכן קוד. להלן שבעה שלבים שבהם עובר יישום ארנק מולטי-צ'יין.
- ביקורת אינטגרציות. אוספים מה כבר קיים: אילו רשתות מחברים, דרך אילו צמתים ושירותים מקבלים יתרות והיסטוריה, היכן נשמרים המפתחות, אילו מגבלות יש על הרשאות. בפלט — מפת תלויות ורשימת סיכונים עם הערכת עומס עבודה.
- סכמת זרימות. מקבעים בסכמה יצירת חשבון, חתימת טרנזקציה, הפקדה, רישום יתרות והיסטוריית פעולות. אי-התאמה שלא נתפסה בשלב הזה הופכת לעבודה מחדש על ליבת הארנק.
- הגדרת חתימה ורישום. יוצרים ממשק חתימה אחוד לעקומות ולפורמטים שונים של טרנזקציות, מפרידים בין מסלול מפתחות חם למסלול קר, ומקימים רישום מוני טרנזקציות לפי כל רשת.
- בדיקה על רשתות בדיקה. מריצים מחזור מלא: יצירה, הפקדה, העברה, ביטול פעולה שנכשלה. רשתות בדיקה מאפשרות לחזור על התרחיש כמה שצריך ותופסות אי-התאמות בפורמטים לפני היציאה לרשת הראשית.
- בדיקה תחת עומס. מזרימים פרופיל תעבורה אמיתי — בקשות יתרה בשיא, חתימות במקביל, התנהגות כשאין גישה לצומת. בודקים זמן תגובה ושיעור כשלים, ומתקנים צווארי בקבוק לפני השחרור.
- תיעוד. נהלים לעבודה עם מפתחות, סכמת זרימות, תיאור קונפיגורציות, הוראות להוספת רשת חדשה בכוחות הצוות שלך.
- מסירה לצוות הלקוח. סקירה עם המהנדסים, מסירת הרשאות ונהלים, קיבוע נקודת חזרה לגרסה הקודמת וסדר העדכון.
הרכב המסירה: קונפיגורציות, מפתחות, סכמות ונהלים
ארנק מוכן בלי קונפיגורציות ונהלים לא חי אצל הלקוח: בכשל הצומת הראשון או בתחלופה בהרכב הצוות מתחילים לשחזר את הלוגיקה מתוך התכתבות. לכן אנחנו סוגרים את המסירה לא בבנייה, אלא בסט ארטיפקטים שלפיהם אפשר להפעיל את המוצר, להרחיב אותו ולהעביר אותו לצוות אחר.
- קונפיגורציות חיבור לרשתות — כתובות צמתים לפי כל רשת, סדר מעבר כשהראשי לא זמין, פסקי זמן וניסיונות חוזרים, מגבלות בקשות, נקודות מעבר בין קו בדיקה לקו עבודה.
- מדיניות גישה ותפקידים — מטריצת הרשאות למפעילים ולשירותים, הפרדה בין הרשאה לחתום על טרנזקציה לבין שינוי קונפיגורציה, תיעוד חובה של פעולות עם מזהה המבצע.
- סכמות אינטגרציה — דיאגרמות של יחסי הגומלין בין ליבת הארנק לבין חיוב, אינדקסר ושירותים חיצוניים: פורמטים של בקשות, אירועים והתראות, זרימת נתונים לפי כתובות, יתרות והיסטוריית פעולות.
- נוהל למפתחות — מי יוזם יצירת מפתח, איך נשמר ומשוחזר משפט מנמוני או חלק מסכמת חלוקת סוד, סדר רוטציה ורצף פעולות בעת חשיפה.
- תיעוד לתמיכה — תיאור ארכיטקטורה, הוראות פריסה וחזרה לאחור, רשימת מדדים וספי הפעלה של התראות, שגיאות אופייניות ומה לעשות במשמרת תורנית.
- סט תרחישי קבלה — שחזור ארנק מגיבוי, שליחת טרנזקציה בכל רשת נתמכת, התנהגות כשאין גישה לצומת וכאשר יש חוסר סנכרון במצב.
אנחנו מעבירים את זה כגוש: עוברים על כל סעיף יחד עם מהנדסי הלקוח, מראים איזה פרמטר על מה אחראי ומה יקרה בערך שגוי שלו, כדי שהקונפיגורציה לא תישאר "קופסה שחורה". צריך הרכב כזה עבור ארנק המולטי-צ'יין שלכם — תארו את המשימה, ונחזור עם הערכה ותוכנית.
מקרה בוחן: איך צמצמנו את שיעור הפעולות התקועות
הארנק עובד עם שלוש משפחות רשתות — EVM, Solana ו-Cosmos, ולכל אחת מודל אישור פעולה משלה. בגלל ההבדל הזה טרנזקציות נתקעו במצב ביניים: הצומת יצא לסנכרון, הרשת דחתה את החתימה, והמשתמש ראה "נשלח" במקום שבו לא היה חיוב.
כל מקרה נותח ידנית לפי לוגים, היתרות בין הרשתות לא התאימו, והתמיכה לא יכלה לענות אם הפעולה הסתיימה או לא.
העברנו את העיבוד לסטטוס פעולה אחוד ולניסיון חוזר אוטומטי עם מפתח אידמפוטנטי: הניסיונות מתבצעים בהשהיה גדלה ובמגבלה קשיחה, וחריגה ממנה מעבירה את הפעולה לסטטוס מפורש "דורש בירור". האבחון נשען על מזהה אחד — לפיו רואים את הרשת, מספר הניסיון, תגובת הצומת וסיבת הכשל. הקטע הרגיש ביותר היה Solana: האישור שם מגיע בגלים, ובלי מפתח החזרה יצרה כפילויות.
מה בחרו לשליחה מחדש
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| חזרה לפי טיימר בלי מפתח | פעולות חד-פעמיות ברשת אחת | כפילויות חיובים כשהצומת לא יציב |
| חזרה אוטומטית עם מפתח אידמפוטנטי | מולטי-צ'יין עם שיעור גבוה של חזרות | צריך בדיקת מצב אחרי מגבלת הניסיונות |
| בירור ידני לחלוטין | העברות גדולות נדירות | לא מתרחב לזרימת פעולות |
תוצאה אחרי היישום
שיעור הפעולות התקועות הצטמצם מכ-7% ל-0.4% מהזרימה היומית, זמן האבחון הממוצע — מכמה שעות לכמה דקות. בדיקת יתרות ברקע בין הרשתות מתבצעת לפי לוח זמנים ומסמנת אי-התאמות לפני שהמשתמש שם לב אליהן.
מה לעשות אם הפתרון כבר נפרס לרשת אחת?
אם הארנק כבר עובד ברשת אחת, הבעיה בדרך כלל לא בממשק: לוגיקת החתימה, פורמט הכתובת ומודל מצב החשבון תפורים דרך כל המוצר — מאחסון המפתחות ועד היסטוריית הפעולות. להוסיף רשת שנייה "ליד" לא מצליח: כל רשת חדשה גוררת אחריה ענפי תנאי בקוד המשותף. להלן סדר המעבר לכמה רשתות בלי לכתוב מחדש את המוצר.
ריפקטור מתחיל לא בקוד, אלא בגבולות. אחסון מפתחות, הצפנה, ביומטריה, ישויות דומיין של חשבון וטרנזקציה נשארים במקומם — הם לא תלויים ברשת. משנים רק את הקטעים שבהם מתקבלת ההחלטה "איך לחתום ואיך לשלוח": זה נותן מינימום תיקונים בתרחישים שכבר נבדקו.
השלב הראשון — הוצאת שכבת החתימה למודול נפרד מאחורי חוזה יציב: בקלט בקשת חתימה, בפלט מטען שימושי חתום. המימושים מוסתרים מאחורי מתאמים, כי סכמות קריפטו, נתיבי גזירה של מפתחות ופורמט כתובת בכל רשת שונים — ברשתות EVM אחד, וב-Solana ו-Cosmos אחרים. המוצר ממשיך לעבוד ברשת הנוכחית: הממשק כבר קיים, המתאם לעת עתה אחד.
בהמשך מוציאים את שכבת הטרנזקציות ורישום המצב: הרכבת מטען שימושי, חישוב עמלה, מעקב אחר אישורים, יתרות וטוקנים. כאן עובד התרחיש המשותף "להכין → לחתום → לשלוח → להמתין", וההבדלים בין הרשתות עוברים למימושים.
תאימות לאחור נשמרת בכך שכתובות ישנות, מפתחות והיסטוריה נשארים תקפים: מיגרציית סכמת הנתונים מתבצעת בשלב נפרד והפיך, ולא יחד עם הריפקטור.
הסדר הוא כזה: לקבע גבולות וחוזים, להוציא את שכבת החתימה, לכסות אותה בבדיקות ברשת הנוכחית, אחר כך להוסיף רשת חדשה ראשונה כמתאם, ורק לאחר מכן לגעת בממשק ובמצב. כל רשת נוספת מתחברת כמודול, ולא כענפים בכל הקוד, והחזרה לגרסה הקודמת נשארת ישימה.
מגבלות הגישה וספקות טכניים נפוצים
הסכמה לא מתאימה במקום שצריך גישה מיידית לנכסים בלי מעורבות הבעלים: אחסון נאמן והחזרת גישה דרך פנייה לתמיכה — זו ארכיטקטורה אחרת, ואנחנו מבהירים זאת בשלב ההערכה, ולא אחרי השחרור.
פתרון נפרד דורשות רשתות שמודל הכתובות שלהן שונה מ-EVM, Solana ו-Cosmos — עבורן בונים מחדש את החתימה ואת הרכבת הטרנזקציה.
להלן ספקות שצפים לרוב בדיונים טכניים.
היכן נשמרים מפתחות פרטיים?
המפתחות נוצרים ונשארים במכשיר המשתמש, החוצה יוצאת רק טרנזקציה חתומה. בשרת אין לא משפט שחזור ולא העתק שלו, לכן חשיפה של התשתית לא נותנת גישה לנכסים.
מה קורה כשהרשת לא זמינה?
החתימה מתבצעת באופן מקומי ולא דורשת קשר. הטרנזקציה נכנסת לתור לשליחה, הלקוח עובר לצומת גיבוי, והיתרה מהמטמון מסומנת כלא מאושרת — המשתמש לא יקבל ערך מיושן כעובדה.
כמה עבודה דורש חיבור רשת חדשה?
הרשת מתחברת כמתאם בשכבת התרגום: הממשק, האחסון ולוגיקת השחזור לא משתנים. רשתות חדשות מוציאים באיטרציות, בלי לכתוב מחדש את ליבת הארנק.
איך משחזרים גישה כשמאבדים את המכשיר?
המסלול הבסיסי — משפט שחזור של 12 או 24 מילים. בנוסף מתכננים חלוקת מפתח בין כמה מחזיקים ובודקים את התרחיש ברשתות בדיקה לפני השחרור, כדי שהשחזור לא יישאר תיאורטי.
נדבר על המשימה: מה צריך להערכה ולתוכנית
כדי לחזור עם הערכת פרויקט, סכמת עבודות ותוכנית עבודות לפי שלבים, ולא עם שאלות הבהרה, אנחנו צריכים סט קצר של נתוני פתיחה. תארו את המשימה במילים — את השאר ננתח יחד: מספיק למנות רשתות, תרחישי שימוש והמצב הנוכחי של הקוד, אם הוא קיים.
מה עוזר להעריך את ההיקף בצורה מדויקת יותר:
- רשימת רשתות ותקנים: תואמי EVM, Solana, Cosmos — אילו בראש התור, ואילו "לצמיחה".
- מודל אחסון מפתחות: ארנק לא-נאמן, חותם חומרה, ריבוי חתימות — מזה תלויים הארכיטקטורה והיקף בדיקות האבטחה.
- פלטפורמות: אפליקציות מובייל, ווב, תוסף דפדפן — והאם צריך סנכרון ביניהן.
- תרחישים: שליחה וקבלה של נכסים, סטייקינג, החלפה, חיבור לשירותים חיצוניים דרך הארנק.
- אינטגרציות: צמתי רשת וספקי גישה, אינדקסרים של היסטוריית טרנזקציות, אנליטיקה, בדיקות לקוחות לפי הצורך.
- מגבלות: דרישות אבטחה וביקורת, לוחות זמנים להשקה, מי בצד הלקוח מקבל החלטות על המוצר.
- מצב נוכחי: קוד מוכן, אב טיפוס, עיצוב — או התחלה מאפס.
לפי נתוני הפתיחה האלה אנחנו מרכיבים סכמת עבודות: אילו מודולים מפרידים, מה עושים ראשון, היכן צווארי בקבוק בלוחות הזמנים. חוזרים עם תוכנית לפי שלבים, הרכב צוות וקריטריוני קבלה בכל שלב.