הסבר על עסקאות Ethereum ממתינות: nonce, החלפה וביטול

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

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

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

לחשבון Ethereum רגיל בבעלות חיצונית (EOA) יש nonce שמסדר את העסקאות שלו. nonce הוא מונה, לא עמלה, חותמת זמן או גיבוב עסקה ייחודי. עבור כל חשבון, השרשרת מקבלת עסקה רק כשהיא משתמשת ב-nonce הבא שהמצב של החשבון מצפה לו. אותו חשבון אינו יכול לבצע שתי עסקאות עם אותו nonce בשרשרת הקנונית. תיעוד החשבונות של Ethereum.org מתאר את nonce כמונה העסקאות של החשבון וכמנגנון הגנה מפני replay.

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

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

כלל ה-nonce חל על עסקאות EOA רגילות בשכבת הביצוע של Ethereum. הוא אינו תיאור אוניברסלי של כל הפשטות הארנק, רצף הפעולות של rollup או שרשרת אחרת. מערכות smart account עשויות להוסיף כללי פעולה ו-nonce משלהן, כפי שמוסבר בהמשך המדריך.

ב-Ethereum אין חדר המתנה יחיד ומסונכרן שכל ארנק, צומת, סייר בלוקים ומציע בלוק רואה בדיוק באותה צורה. כל לקוח ביצוע מחזיק מאגר עסקאות מקומי של עסקאות שקיבל ונראות לו כשירות לפי המגבלות והמדיניות שלו. עסקה יכולה להופיע במאגר של צומת אחד ולהיעדר מזה של צומת אחר. תיעוד ה-RPC של txpool ב-Geth מציג את הקבוצות המקומיות pending ו-queued של אותו לקוח ומציין שייתכן שכמה עסקאות משויכות לאותו שולח ולאותו nonce.

במונחים של Geth, pending מתייחס בדרך כלל לעסקאות שאפשר לעבד לפי סדר nonce ממצב החשבון הנוכחי; queued עשוי לכלול עסקאות עם nonce עתידי שממתינות לסגירת פער. אלה שמות בממשק של לקוח, לא מצבי קונצנזוס שכל תוכנת Ethereum חייבת להציג. ארנק עשוי לכנות את כל רשימת העסקאות הלא מאושרות שלו „ממתינות”, ואילו סייר עשוי להציג רק עסקאות שספקי הנתונים שלו הבחינו בהן.

לדוגמה, אם צומת מכיר עסקה עם nonce 41 ועסקה אחרת עם nonce 43, הוא אינו יכול לבצע את 43 לפני 42. הצומת עשוי להשאיר את 43 בתור עד ש-42 תגיע או שמצב החשבון יתקדם בדרך אחרת. צומת אחר שמעולם לא קיבל את 43 לא יציג אותה כלל. לכן שני סיירים עשויים לחלוק בשאלה אם עסקה ממתינה או חסרה, בלי שאף מסך מוכיח מה כל המאמתים ראו.

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

נניח שה-nonce הבא בחשבון בשרשרת הוא 41. שידרתם עסקה A עם nonce 41 ולאחר מכן עסקה B עם nonce 42. כל עוד A לא נפתרה, אי אפשר להחיל את B לפניה. ייתכן ש-B תישאר בתור מקומי, תופיע כממתינה רק בארנק או לא תופיע בסייר שעדיין לא קיבל אותה. הקשר החשוב הוא סדר ה-nonce, לא הסדר שבו הארנק יצר או הציג את שתי העסקאות.

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

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

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

סדר nonce והתאמה לתנאי עמלה הם מגבלות נפרדות. עסקה עם ה-nonce הבאה הנכונה עדיין עשויה להמתין אם פרמטרי העמלה שלה אינם עומדים בתנאים להכללה בבלוק. עסקה עם nonce גבוהה יותר אינה יכולה לעקוף אותה רק באמצעות טיפ גדול יותר. העלאת העמלה של nonce 42 אינה מעלימה את nonce 41.

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

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

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

פעולת „האצה” בארנק יוצרת בדרך כלל עסקה חדשה מאותו חשבון, עם אותה nonce ופרמטרי עמלה מותאמים. שתי המועמדות מתנגשות, כי החשבון יכול לבצע רק עסקה אחת עבור אותה nonce. אם עסקת ההחלפה מתקבלת במאגרי העסקאות הרלוונטיים ונכללת, היא יכולה לתפוס את משבצת ה-nonce; העסקה המקורית לא יכולה להתבצע יחד איתה בשרשרת הקנונית. ההנחיות של MetaMask לעסקאות ממתינות מתארות את פעולת ההאצה שלה כשליחה מחדש עם אותה nonce ועמלה גבוהה יותר.

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

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

„החלפה” כאן פירושה עסקה מתחרה מאותו חשבון ועם אותה nonce. אל תעתיקו ל-Ethereum את הליכי RBF או CPFP של Bitcoin. Bitcoin משתמשת במודל עסקאות אחר, ומנגנוני העלאת העמלות שלה אינם הוראות לעסקאות בחשבון Ethereum.

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

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

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

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

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

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

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

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

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

אם הגיבוב אינו מוצג, השוו את ה-nonce המאושרת העדכנית של החשבון לזו שמוצגת בארנק. מפתח או מפעיל צומת יכול להריץ שאילתת eth_getTransactionCount עם תגיות הבלוק latest ו-pending. מדריך JSON-RPC של Ethereum.org מגדיר אותן: latest מתייחס למצב הבלוק האחרון, ו-pending למצב הממתין. תוצאת pending עדיין תלויה בתצוגה של נקודת הקצה של RPC; שתי ספקיות עשויות להחזיר ערכים שונים. רוב המשתמשים יכולים לקבל את אותם רמזים ראשוניים מפעילות החשבון בארנק ומסייר אמין, בלי להריץ פקודות.

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

הצעדים האלה מיועדים לעסקאות רגילות מחשבונות Ethereum בבעלות חיצונית. מערכות הפשטת חשבון יכולות לשלוח UserOperations באמצעות bundlers, וה-smart accounts שלהן עשויות להשתמש במפתחות nonce וברצפים מעבר למונה יחיד ופשוט. EIP-4337 מגדיר מבנה nonce לפעולות האלה, ולכן ארנק עם הפשטת חשבון עשוי לא להתנהג בדיוק כמו בדוגמאות ה-EOA במאמר. לפרטים על רשתות יעד, כתובות וסטטוס העברה, המשיכו אל רשימת הבדיקה להעברות קריפטו.