הגדרת Web3.js ב-DApp: עסקאות, אירועים ואופטימיזציה של גז

אינטגרציה של Web3.js: מדוע טרנזקציות נתקעות והולכות לאיבוד

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

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

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

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

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

מה משתנה לאחר ההגדרה: אישורים, אירועים, עמידות

תגובת האפליקציה: מצב לפי האירוע עצמו

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

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

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

שיעור הפעולות המוצלחות: מגבלת גז ותור חתימות

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

אישור צפוי: עומק ונסיגה

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

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

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

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

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

סדר העבודה: מניתוח קריאות ועד מסירה לתמיכה

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

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

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

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

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

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

תוצאת ההטמעה: כיצד הצטמצמו שליחות חוזרות וכשלים

מה היה לפני ההטמעה

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

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

מה שינו

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

מה נהיה

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

במה שונה עבודה דרך ארנק מחתימה בשרת?

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

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

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

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

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

ספקות טכניים נפוצים בעת חיבור לרשת

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

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

האם אפשר להריץ את האינטגרציה בלי כספים אמיתיים?

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

מה נשאר לצוות לאחר מסירת הפרויקט?

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

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

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

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

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