אינטגרציה של WalletConnect v2 ב-dApp: חיבור ארנקים ניידים

הארנק לא מתחבר: היכן נשברת האינטגרציה של WalletConnect

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

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

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

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

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

מה נותן חיבור חלק של ארנקים באפליקציה

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

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

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

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

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

דרכי חיבור ארנק: השוואת אפשרויות

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

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

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

אינטגרציה של WalletConnect באפליקציה: שלבי העבודה

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

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

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

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

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

מה נשאר בידיים שלכם:

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

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

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

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

מה שינו

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

מה הראו המדדים

שיעור החיבורים הכושלים ירד מ-34% ל-6% — היתרה היא סירובים של המשתמשים עצמם ומהדורות ארנק לא תואמות. הזמן עד לחתימה הראשונה הצטמצם ל-20-25 שניות, הניסיונות החוזרים — ל-1.05 למשתמש, כלומר התרחיש עובר בניסיון הראשון.

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

במה שונה שער מוטמע מארנק חיצוני ומה לבחור

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

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

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

החיצוני מפסיד בפעולות המוניות וקצרות — חלק מהמגיעים просто לא יגיעו לחתימה, לאחר שיאבדו עניין בהתקנת ארנק.

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

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

ספקות טכניים: סשנים, מפתחות, שחזור

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

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

מה קורה לבקשה בעת ניתוק קשר?

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

האם זה עובד עם מהדורות ישנות של ארנקים?

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

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

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

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

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