פיתוח טוקן ERC-20: היכן נשברים החוזים
שגיאות בהנפקת טוקן כמעט אף פעם לא בלוגיקה — הן בפרטים שלא שוברים דבר ברשת הבדיקות. דיוק עשרוני נקבע פעם אחת ולכל חיי החוזה: אפס במקום שמונה עשרה — והארנק יציג יחידה אחת במקום כל הנפח. גלישה בחיבור יתרות במבנה ללא בדיקות יוצרת העברה מעגלית ויתרה "אינסופית" בכתובת אחת.
קבוצה נפרדת — הרשאות. אם ההנפקה לא מוגנת בתפקיד, כל כתובת יכולה להנפיק לעצמה נפח שרירותי. גם ההפך בעייתי: תפקיד ההנפקה מוצמד לארנק רגיל ללא ריבוי חתימות — אובדן מפתח עוצר את ההנפקה לתמיד, ופריצה מוסרת שליטה על ההיצע לתוקף.
השלישית — פעולות לא מוגנות עם יתרה. העברה ללא בדיקת כתובת אפס שולחת טוקנים למקום בלתי נגיש, היעדר אירוע Transfer שובר אינדקסרים ושירותי החלפה, וחיוב לפי הרשאה ללא התחשבות בשארית המגבלה מאפשר למשוך יותר מהמאושר.
הרביעית — אי-תאימות הטוקן עם ארנקים ושירותים חיצוניים: החזרה לא תקנית בהעברה ובאישור, שמות שדות מטא-נתונים שונים, היעדר אירועים מוכרים. הנכס לא מוצג בארנק או לא מזוכה לפיקדון בבורסה, ופגיעות בחוזה החכם צפה רק לאחר הרישום למסחר — תיקון מחייב הנפקה מחדש וחלוקת נכס חדש למחזיקים.
איך התרחישים האלה נסגרים בשלב התכנון והבדיקות — נפרט בהמשך.
מה נותן טוקן שתוכנן נכון
חוזה ERC-20 שתוכנן נכון — זה לא רק העברה שעובדת. בו מוטמעות מראש בדיקות שמסירות מחלקה שלמה של כשלים: שליחה לכתובת חוזה שלא יודע לקבל טוקנים, אובדן דיוק בעת פיצול חלקים, קריאה חוזרת לאותה פעולה.
שיעור העסקאות הנדחות יורד מכמה אחוזים למקרים בודדים, וכל פעולה כזו מפסיקה להפוך לבדיקה ידנית עם שליחה חוזרת.
תאימות עם ארנקים ושירותים נבדקת, ולא מונחת כמובן מאליו. החוזה מתנהג באותו אופן לפתרונות קסטודיאליים, לכתובות פיקדון של בורסות ולסיירי רשת: אירועי העברה נמסרים בצורה הצפויה, והיתרות מתאימות עד הספרה האחרונה. חיבור שירות חדש מתקצר משבועות של התכתבות והתאמות לכמה ימים — בצד האינטגרציה פשוט אין מה לתקן.
הנפקה יציבה של טוקן נשענת על צפיות. מגבלות, תפקידים והרשאות הנפקה מתוארים במפורש, סקריפטים לזיכוי המוני הם אידמפוטנטיים, וחזרה לא יוצרת כפילויות. מספר הפעולות הידניות בזיכויים יורד פי כמה: ההתאמה מתבצעת לפי ייצוא נתונים, ולא שורה-שורה.
אפקט נפרד — יכולת ניהול בלי לשבור יתרות שהונפקו. פונקציות ניהוליות מופרדות מלוגיקת ההעברות, מגבלות והשהיות משתנות בפרמטרים, ולא בהנפקה מחדש של החוזה. זה מרווח ביטחון שמאפשר להוסיף תרחישים חדשים — זיכויים, קאשבק, סטייקינג — בלי לעצור את המחזור.
פורמטי הנפקה: תקן בסיסי ולוגיקה מורחבת
פורמט הנפקת הטוקן לא קובע "כמה מתוחכם" הוא, אלא אילו פעולות בנכס דרושות בהתחלה ומה יהיה צריך להוסיף אחר כך. לוגיקת חוזה תקנית — העברה, יתרה, הרשאה לחיוב, הנפקה ושריפה — היא מינימום קוד ומינימום משטח לשגיאות.
לוגיקת טוקן מורחבת מוסיפה תפקידים, מגבלות על פעולות, זיכוי והקפאה: כל תוספת מסבכת את הביקורת ומשנה את האופן שבו ארנקים ובורסות מקבלים את הטוקן.
להלן ארבע אפשרויות, שביניהן באמת בוחרים בשלב התכנון. מגבלות ERC-20 מוצגות בכנות: חלק מהמשימות התקן אינו פותר באופן עקרוני, ומוטב לראות זאת לפני הפיתוח.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| תקן מינימלי | הפצה, רישום למסחר, רישום חלק ללא כללים מורכבים | אין תפקידים ומגבלות; כללים חדשים יחייבו מעבר לחוזה חדש |
| טוקן עם תפקידים ומגבלות | נדרשים מנהל, השהיית העברות, מגבלות יומיות, הפרדת הרשאות | יותר קוד — יותר משטח תקיפה; שינוי תכוף של כללים מדאיג מחזיקים ובורסות |
| חוזה עם זיכוי והקפאה | תגמול מחזיקים, וסטינג לצוות, נעילת חלק עד מועד | נדרשים מקורות נתונים חיצוניים אמינים; מסובך יותר הרישום והדיווח מול הבורסה |
| עטיפה סביב נכס קיים | העברת נכס מוכן לרשת בלי היצע חדש | דורש מחזיק רזרבה אחראי ואישור ביטחונות שוטף; האמון בעטיפה אינו גבוה מזה שבו |
לפני הבחירה אנחנו מפרקים תרחישים שצריכים לעבוד בעוד שנה: מעבר, התערבות ידנית לפי החלטת הבעלים, קבלת הטוקן בפלטפורמות.
שלבי העבודה ההנדסית על החוזה
סדר השלבים נדרש לא לשם דיווח, אלא כדי לתפוס שגיאות יקרות לפני הפרסום. הקוד ברשת בלתי ניתן לשינוי: לאחר הפריסה אי אפשר לתקן שגיאת כתיב בתנאי או חור בהרשאות גישה בלי להנפיק חוזה חדש ולהעביר את המחזיקים. לכן מחיר התיקון עולה בכל שלב — הולכים מהמפרט לקוד, ולא להפך.
- פירוק המשימה ומודל הכלכלה של הנכס: כמה טוקנים מונפקים, האם יש הנפקה נוספת ושריפה, אילו מגבלות על העברות ועמלות. המודל נק�ע במפרט לפני שורת הקוד הראשונה.
- סכמת תפקידים והרשאות: מי מנפיק, מקפיא כתובות, משנה פרמטרים. בנפרד בודקים שאי אפשר לקבל הרשאות בעקיפין — דרך פרוקסי, האצלה או קריאה מחוזה אחר.
- הרכבת החוזה: פונקציות בסיס של התקן נלקחות מספריות מהימנות, ומוסיפים רק את הלוגיקה החסרה. משטח השגיאה יוצא קטן יותר מאשר בכתיבה מאפס.
- הרצות מקומיות ובדיקת החוזה: ערכי קצה — כתובות אפס, גלישות, קריאות חוזרות, מגבלות. לאחר מכן הרצה ברשת בדיקות עם ארנקים ותרחישים אמיתיים.
- ביקורת בלתי תלויה של החוזה החכם: מפרקים את הדוח, סוגרים הערות, ובודקים שוב נקודות שנויות במחלוקת.
- פרסום הטוקן: פריסה ברשת הראשית ואימות קוד המקור בסייר, כדי שניתן יהיה להשוות את הכתובת לקוד.
- מסירה והדרכת הצוות: תיעוד תפקידים, הוראות הנפקה וביטול, ונוהל פעולה בעת תקרית.
תוצרי מסירה: קוד, סכמות, נהלי הנפקה
מסירת הפרויקט לא מסתיימת בפריסת החוזה ברשת הראשית. הלקוח מקבל ערכה שלפיה אפשר לפתח ולתחזק את הטוקן בלעדינו: קוד, הפרדת הרשאות, נהלים ובדיקות. להלן מה בדיוק נקבע במסמך המסירה.
- קוד המקור של החוזה עם הערות: מבנה קריא, הסברים לקריאות חוץ ולאירועים, היעדר קבועים "קסומים" שמוטבעים בלוגיקה.
- סכמת תפקידים והרשאות גישה: מי יכול להנפיק ולשרוף טוקנים, לעצור פעולות ולשנות פרמטרים, וכיצד ההרשאות מתחלקות בין כתובות וריבוי חתימות.
- נוהל הנפקת טוקן: תהליך הנפקה שלב-אחר-שלב עם מגבלות על פעולה, סדר חתימות ובדיקת כתובת הנמען לפני ההנפקה.
- נוהל עצירת פעולות: באילו תנאים מופעלת השהיה, מי מקבל את ההחלטה, כיצד הפעולות מתחדשות ומה קורה עם יתרות שכבר הונפקו.
- הוראות לשחזור גישה: רוטציית מפתחות, העברת תפקיד ניהולי, ונוהל פעולה בעת חשיפת חותם.
- סט בדיקות: בדיקות יחידה ואינטגרציה לתרחישי המפתח, ניתוח סטטי ודוח ביקורת חיצונית עם רשימת הערות סגורות.
- תיעוד לחוזה: תיאור הממשק החיצוני, כתובות העותקים שנפרסו ברשת הבדיקות וברשת הראשית, פרמטרי הנפקה ומגבלות.
כל התוצרים נמסרים במאגר של הלקוח יחד עם היסטוריית השינויים — עדכון טוקן או החלפת ספק לא מתחילים מהנדסה לאחור.
מקרה בוחן: הסרנו מחלקה של כשלים בהנפקת נכס
נקודת פתיחה
הנכס הונפק כאב-טיפוס מהיר: הנפקה נוספת, הקפאת כתובות והתאמת יתרות עברו דרך סקריפטים ידניים — תשע פעולות למחזור אחד, וכל אחת הורצה רק לאחר בדיקה בעיניים. שיעור העסקאות הנדחות עמד על כ-7%: חלקן נפלו בגלל מגבלות שגויות, וחלקן בחיוב כפול, כששני סקריפטים הספיקו לפנות לאותה רזרבה. טיפול במקרה אחד כזה ארך עד שעה, והתאמה מלאה של המרשם גזלה עוד חצי יום עבודה.
מה שינו ומה השתנה
הלוגיקה הועברה לחוזה אחד עם תפקידים מופרדים והגנה מפני ביצוע חוזר, והפעולות השגרתיות — לסקריפטים עם סימולציה מחייבת ברשת הבדיקות לפני שליחה. אצווה מונפקת בקריאה אחת, המגבלות מחושבות ממצב הרשת הנוכחי, ולכן העסקה לא "נשרפת" לחינם. מחלקת הכשלים שקשורה להזנת כתובות וסכומים ידנית נסגרה לחלוטין.
התוצאה: שיעור העסקאות הנדחות — 0.4%, ואלה ביטולים מודעים של המפעיל, לא תקלות. מחזור ההנפקה התקצר מ-40 ל-6 דקות, פעולות ידניות לאצווה — שתיים במקום תשע.
התאמת המרשם מתבצעת אוטומטית לפי נתוני Etherscan, ואין אי-התאמות עם החשבונאות הפנימית כבר כמה גרסאות ברצף — הבדיקה אורכת דקות במקום חצי יום.
מה לעשות אם החוזה כבר נפרס ואי אפשר לשנות אותו
חוזה שנפרס אי אפשר לשנות — זה בדיוק смысл אי-הניתנות לשינוי: לא יופיעו בו פונקציות ניהוליות ולא החלפת כתובת בדיעבד. אבל מצב הטוקן חי לא בקוד, אלא במאגר היתרות, ולכן מעבר החוזה נבנה לא על תיקון הישן, אלא על הנפקת חוזה חדש והעברת המחזיקים.
פעולת הבסיס — סנאפשוט של היתרות בגובה מספר בלוק מסוים. לפיו נקראים כל הכתובות והסכומים פעם אחת, ומכאן ואילך הרשימה לא מחושבת מחדש: כך לא נשארת למחזיקים דרך להעביר טוקנים בין ארנקים ולכפול זיכויים. הסנאפשוט הופך למקור הרשמי לזכויות בעת החלפת טוקן שנפרס.
החוזה החדש מפורסם בנפרד, והישן ממשיך לעבוד — פלטפורמות לא מתחלפות ביום אחד. המחזיק שולח את הטוקנים הקודמים לחוזה ההחלפה ומקבל חדשים לפי שער קבוע, בדרך כלל אחד לאחד; כתובת המחליף והשער מוכרזים מראש.
תקופת המעבר נקבעת עם מרווח, ולאחריה ההחלפה נסגרת והיתרות שלא הוחלפו נחסמות. זה מחנך את המחזיקים ולא נותן לנזילות להתפזר בין שתי גרסאות של הנכס.
כיוון נפרד — תיאום עם בורסות, ארנקים וסיירים: הם צריכים את כתובת החוזה החדש, תאריך החלפת הטיקר ואישור סנאפשוט. כשזה נעשה, המעבר עובר בלי לאבד היסטוריה ובלי תיקון ידני של היתרות של כל מחזיק.
ספקות טכניים: גישה, מגבלות, בדיקת קוד
הרשאות הנפקה, מגבלות והקפאה הם חלק ממודל הגישה שמתכננים יחד עם החוזה, ולא מוסיפים אחרי ההשקה. להלן שאלות שצוותי הנדסה מעלים לרוב בדיון על הרשאות מנהל ובקבלת קוד.
למי שייכות הרשאות הנפקת הטוקן וכיצד הן מועברות?
ההנפקה נפתחת בתפקיד נפרד: כתובת שיכולה ליצור טוקנים חדשים. בהתחלה זה ארנק הפריסה, אחר כך ההרשאות עוברות לריבוי חתימות, ותפקיד הפורס נשלל. תפקידים להקפאה ולשינוי פרמטרים ניתנים בנפרד — חשיפה של מפתח אחד לא מאפשרת לשלוט בכל ההיצע.
האם אפשר לשנות את לוגיקת החוזה לאחר ההשקה?
תלוי בתבנית. חוזה בלתי ניתן לשינוי לא ניתן לתקן: שיפורים משמעותם מעבר לכתובת חדשה. חוזה מתעדכן מחזיק את הלוגיקה מאחורי פרוקסי, והמנהל משנה אותה — נוח, אבל כל הסיכון עובר להרשאות המנהל. לכן אנחנו סוגרים אותן בריבוי חתימות ובעיכוב ביצוע: למחזיקים יש חלון לראות את השינוי מראש.
כיצד מאושרת התאמת הקוד המפורסם לקוד המקור?
אימות החוזה הוא פרסום קוד המקור ופרמטרי הבנייה, שמהם משוחזר אותו בייט-קוד שנמצא בכתובת. אנחנו עוברים אותו מיד לאחר הפריסה: לפני כן מבחוץ רואים רק בייט-קוד, ואף אחד לא יבדוק את הלוגיקה. סכומי בקרה של התוצרים נרשמים בדוח ההנפקה.
מה בדיוק בודקת הביקורת ומה נשאר מחוץ לתחומה?
הביקורת בוחנת אריתמטיקה, הפרדת תפקידים, קריאות חוץ ותרחישי קצה של העברות. בנפרד מריצים אינווריאנטים על מגבלות העברות והקפאת נכסים: סכום היתרות לא סוטה מההנפקה, וכתובת חסומה לא עוקפת את המגבלה דרך מתווך. הביקורת לא מאשרת את המודל הכלכלי ולא מחליפה נהלי עבודה עם מפתחות — זה אזור התפעול בצד שלכם.
נדון במשימה ונחזור עם תוכנית הנפקה
הערכת פיתוח טוקן בלי הקשר הופכת לטווח רחב "מכאן ועד כאן", ולכן אנחנו מתחילים לא בשעות, אלא במודל הנכס. שלחו את מה שכבר קיים — טיוטת טוקנומיקה, מצגת למשקיעים, התכתבות עם עורכי דין: זה מספיק כדי לראות את היקף העבודה האמיתי ואת צווארי הבקבוק.
- ייעוד הנכס: מה הטוקן מאשר — חלק, זכות תביעה, גישה לשירות או יחידת חשבונאות פנימית.
- תרחישי שימוש: הנפקה, העברות, שריפה, הקפאת כתובות, מגבלות על העברה, תפקידי מנהל וסמכויותיהם.
- דרישות רגולטור ושותפים: נהלי בדיקת מחזיקים, מגבלות על פעולות, דיווח, תחומי שיפוט של המשתתפים.
- היכן מתוכננת ההנפקה: פלטפורמות וארנקים, הדרישות שלהם לתקן הטוקן ולמטא-נתונים.
- תוצרים קיימים: טיוטות חוזים, בדיקות, דוחות ביקורת, אם הקוד כבר נכתב בידי צוות אחר.
- מסגרות קשיחות: הצמדות לאירוע, היקפי הנפקה, תנאי שחרור ולוח תשלומים.
לפי הנתונים האלה אנחנו חוזרים עם תוכנית עבודה לחוזה: סכמת החוזה עם רשימת פונקציות, תפקידים והרשאות גישה, הרכב שלבים עם תוצאה מדידה בכל אחד, לוחות זמנים להנפקה וסדר הבדיקות לפני הפרסום.
כדי לדון במשימת ההנפקה באופן ענייני, מספיק לתאר אותה בצורה חופשית — נאסוף הערכה, תוכנית ונחזור עם שאלות אם משהו יחסר.