סטייקינג NFT: פיתוח חוזים עם ביקורת ואינטגרציה

פיתוח סטייקינג NFT: היכן נשברת הכלכלה של הפול

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

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

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

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

תוצאה של הטמעה: תגמולים, עמידות, מעקב פוזיציות

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

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

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

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

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

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

השוואת מודלים: פול, סטייקינג ישיר, היברידי

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

עומס ומעקב

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

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

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

סדר העבודה: מהסכמה ועד מסירת החוזה

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

שלבי העבודה

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

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

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

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

5. ביקורת חיצונית. מעבירים את הקוד ואת תיאור ההתנהגות לבודקים בלתי תלויים, מנתחים הערות, מקבעים תיקונים. את הדוח מוסרים ללקוח יחד עם החוזה.

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

מה נשאר אצלכם: חוזים, סכמות, נהלים

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

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

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

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

מה היה לפני האתחול מחדש

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

בחתך שלפני האתחול מחדש: שיעור המשיכות המוצלחות — 87%, אישור ממוצע — כשש דקות, תמיכה — 30–40 פניות בשבוע.

הגירת פוזיציות ומדדים לאחר מכן

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

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

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

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

מה לעשות אם החוזה כבר פרוס ומחזיק נכסים?

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

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

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

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

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

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

ספקות טכניים נפוצים לפני ההתחלה

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

כאשר הרשת עמוסה, התגמולים לא יאבדו?

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

האם אפשר לשנות תנאי צבירה בדיעבד?

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

האם החוזה יכול להחזיק את הנכסים שלי?

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

נדבר על המשימה: מה צריך כדי להתחיל

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

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

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