ארנק מולטי-צ'יין (Ethereum, BSC, Polygon, Solana, TON)

ארנק מולטי-צ'יין: היכן הלוגיקה נשברת עם צמיחת הרשתות

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

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

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

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

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

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

מה נותנת ארכיטקטורה אחודה של ארנק מולטי-צ'יין

ארכיטקטורה אחודה של ארנק נבנית סביב שכבת חתימה אחת ושכבת רישום מצב אחת, וההבדלים בין הרשתות מוצאים אל מתאמים. Ethereum, BSC, Polygon, Solana ו-TON פועלות דרך מודלים שונים של חשבונות ופורמטים שונים של חתימה, אך הלקוח רואה יתרה אחת, היסטוריה אחת ותרחיש שליחה אחד.

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

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

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

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

גישות למימוש: מודולים מובנים, שירותים חיצוניים, היברידי

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

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

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

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

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

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

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

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

1. ביקורת התרשים ומיפוי נכסים. מרכזים רשימה של רשתות (Ethereum, BSC, Polygon, Solana, TON), סוגי כתובות ומאגרי מפתחות קיימים. בפלט — מפה: היכן הנכסים, למי יש גישה, אילו פעולות מתבצעות מחוץ לארנק.
2. תכנון מודל המפתחות וההרשאות. קובעים אילו רשתות פועלות על seed-phrase משותף, אילו דורשות נפרד, וכיצד מופרדים תפקידי המפעיל והמנהל. מפרקים מה עובר למאגר מאובטח ומה נשאר במעגל החם.
3. הגדרת חתימת עסקאות. מרכיבים חתימה לכל רשת בהתאם לפורמט שלה: סכימות מיעון שונות, שדות עמלה שונים, דרישות שונות ל-nonce. בודקים שהחתימה נוצרת באופן מקומי ושהמפתח הפרטי אינו יוצא מהמעגל המאובטח.
4. בדיקת עסקאות ברשתות בדיקה. מריצים מחזור מלא — הרכבה, חתימה, שליחה, אישור — בכל בלוקצ'יין בנפרד. בנפרד בודקים תרחישי כשל: עסקה שנדחתה, עסקה שנתקעה ב-mempool, חוסר באמצעים לעמלה.
5. נהלי תפעול. מתארים את סדר הוספת רשת חדשה, רוטציית מפתחות, שחזור גישה ותגובה לאירוע. הנהלים צריכים להיות קריאים למהנדס תורן ללא הסברים נוספים.
6. מסירת תיעוד והדרכת הצוות. מוסרים תרשימי ארכיטקטורה, הוראות תפעול, רשימות בדיקה. מקיימים תרגול על תרחישים חיים, כדי שצוות הלקוח יוכל ללוות את הארנק באופן עצמאי.

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

מדיניות גישה וניהול מפתחות בארנק מולטי-צ'יין

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

• סכימת אחסון מפתחות — היכן חי המפתח הפרטי (אחסון מאובטח במכשיר, מודול חומרה, אחסון שרתי עם הצפנה), כיצד מופרדים המעגל החם והמעגל הקר, מה קורה בעת פגיעה במכשיר.
• מדיניות גישה — מטריצת תפקידים: מי חותם על עסקאות, מי משנה מגבלות, מי רק צופה ביתרה; כללי אישור לפעולות גדולות והפרדת תחומי אחריות בין המנהלים.
• תצורות רשתות — קבצים עם פרמטרי חיבור ל-Ethereum, BSC, Polygon, Solana ו-TON: כתובות צמתים, ספקים חלופיים, עמלות, זמני המתנה, כללי מעבר בעת אי-זמינות הערוץ הראשי.
• נהלי גיבוי ושחזור — כיצד ובאיזו תדירות נשמרים עותקים מוצפנים, היכן הם מאוחסנים, כיצד נבדק שחזור גישה במעגל בדיקה.
• סכימת זרימות חתימה — תרשים המציג את מסלול העסקה מהממשק ועד לשליחה לרשת: היכן נבדקות המגבלות, היכן מופעל האישור, היכן מתועד האירוע.
• תיעוד לרוטציית מפתחות — סדר פעולות שלב-אחר-שלב להחלפה מתוכננת של מפתחות ולשלילת מפתחות שנפגעו ללא עצירת השירות.
• יומן ביקורת פעולות — אילו אירועים נרשמים, באיזה פורמט, כמה זמן נשמרים וכיצד מיוצאים לניתוח תקיפות.

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

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

המשימה הגיעה מצוות שהוביל ארנק מולטי-צ'יין עם תמיכה ב-Ethereum, BSC, Polygon, Solana ו-TON. המשתמשים התלוננו על עסקאות "תקועות": החיוב מהחשבון עבר, אך האישור ברשת לא הגיע.

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

מה היה לפני

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

מה שינו

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

מה התוצאה

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

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

במה שונה ארנק מולטיצ'יין מאוסף ארנקים נפרדים?

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

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

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

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

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

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

מה לעשות אם כבר פרוס ארנק אחד וצריך להוסיף רשתות

הרחבת ארנק מולטי-צ'יין כמעט לעולם אינה דורשת כתיבה מחדש מאפס — אם הארכיטקטורה מלכתחילה הפרידה בין הליבה למתאמי הרשת. מפתחות, חתימת עסקאות, עבודה עם seed-фраза ואחסון מקומי נשארים משותפים: הם אינם תלויים באיזו רשת אתה חותם.

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

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

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

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

אנו בודקים בנפרד שגזירת הכתובות עבור הרשת החדשה מניבה ערכים תקינים וששחזור מ-seed-фраза מחזיר את כל הרשתות בבת אחת.

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

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

נדון במשימה: נחזור עם הערכה ותוכנית

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

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

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