אישורי טוקנים ו-Allowance: בדיקה וביטול של הרשאות ERC-20

חיבור לאתר מאפשר בדרך כלל לאפליקציה לראות כתובת ציבורית ולבקש חתימות. הוא לא מעניק כשלעצמו הרשאה להעביר את כל טוקני ERC-20. ה-allowance נשמר בנפרד בחוזה הטוקן. גם MetaMask מבחינה בין ניתוק dapp לבין ביטול אישורי טוקנים.

Allowance של ERC-20 קשור לחוזה הטוקן, לרשת, לכתובת הבעלים ולכתובת ה-spender. אישור ב-Ethereum אינו אותו אישור לאותו סמל ב-Polygon או לטוקן אחר. אם זוכרים רק ש״אישרתי את האתר״, קל לפספס איזה טוקן ואיזו רשת עדיין מורשים.

המדריך עוסק ב-approve, allowance ו-transferFrom של ERC-20 ב-Ethereum וברשתות תואמות. העברות ETH מקורי, setApprovalForAll של NFT, תקנים אחרים וחיבור כניסה לארנק פועלים אחרת. לגיבוי ושחזור מפתחות ראו את המדריך לביטוי שחזור ולשחזור ארנק.

הבעלים יכול לקרוא approve(spender, amount) בחוזה הטוקן כדי לאפשר ל-spender מסוים להשתמש עד לכמות מוגדרת. transferFrom מאפשר לו להעביר טוקנים בשם הבעלים. לכן approve בדרך כלל לא משנה את היתרה מיד, אך קריאה מאוחרת יותר לחוזה יכולה להשתמש ב-allowance. זהו הזרם שמוגדר ב-תקן ERC-20.

לדוגמה, אם בארנק יש 300 טוקנים והוא מעניק ל-router allowance של 80, ב-ERC-20 רגיל הכמות המותרת מוגבלת לנמוך מבין היתרה וה-allowance שנותר. ההרשאה לא חייבת להתייחס לעסקה אחת; החוזה יכול לקרוא transferFrom כמה פעמים. שימוש לרעה בחוזה שאושר או בנתיב הפעולה שלו עלול להזיז טוקנים באופן שלא ציפיתם לו. חשוב לבדוק גם התנהגות חריגה של הטוקן.

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

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

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

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

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

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

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

חלק מטוקני ERC-20 תומכים ב-ERC-2612 permit. במקום לשלוח עסקת approve רגילה, הבעלים חותם על נתונים מובְנים; צד אחר יכול להגיש את החתימה כדי להגדיר allowance. ההודעה התקנית כוללת בעלים, spender, ערך, nonce ו-deadline, וכן תחום הקושר את החתימה לרשת ולחוזה.

ה-deadline של ERC-2612 הוא המועד האחרון שבו ניתן להגיש את ה-permit החתום. הוא לא אומר ש-allowance שכבר נקבע בהצלחה פוקע אוטומטית באותו מועד. ההרשאה יכולה להישאר עד שתנוצל, תשונה או תבוטל. יש טוקנים שמשתמשים בגרסאות permit אחרות או בכללי תפוגה נוספים; אל תניחו שכל בקשה בשם “permit” פועלת לפי ERC-2612.

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

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

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

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

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

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

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

תקן ERC-20 ממליץ לממשקים לאפס allowance שאינה אפס לפני החלפתה לערך אחר שאינו אפס. אם עסקת spender נכנסת בין האישור הישן לחדש, ייתכן שניתן יהיה להשתמש ביותר מהצפוי. לדוגמה, במעבר מ-100 ל-25, spender עשוי להשתמש ב-100 הישנים לפני שה-25 החדשים נרשמים ואז להשתמש גם בהם.

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

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

1. אמתו את הדומיין הרשמי של הפרויקט ואת הרשת שנבחרה.
2. בדקו את כתובות חוזה הטוקן וה-spender והשוו את התקרה לכמות הדרושה לפעולה.
3. קראו את העסקה או הנתונים המובְנים שהארנק מציג בפועל. אל תחתמו על בקשה שאינכם מבינים.
4. ברשת המתאימה, בדקו spenders שאינכם משתמשים בהם או שאינכם סומכים עליהם; אפסו allowance כשנדרש ואמתו את התוצאה.
5. בהשוואת ארנקים בדקו לא רק תמיכה ברשתות אלא גם עד כמה ברור פירוט האישורים והאם הנחיות עדכון ושחזור מובנות.

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