אינטגרציה עם Puffer Finance: היכן נקרע מעגל הסטייקינג
ריסטייקינג נזיל נראה פשוט: מפקידים ETH — וביתרה מופיע pufETH. אבל האינטגרציה עם Puffer Finance נשברת בשלושה מקומות טיפוסיים, וכל אחד מהם יוצר או כספים תקועים או יתרה שגויה בדיווח.
הראשון — חוסר סנכרון בשער החליפין. pufETH אינו שווה ל-ETH ביחס אחד לאחד: השער עולה ככל שנצברות תגמולים על סטייקינג וריסטייקינג. אם מערכת החשבונאות לוקחת אותו ממטמון, מתמונת מצב מתחילת היום או מחשבת אותו כ-1:1, הפוזיציה במערכת אינה תואמת ליתרה האונצ'יין — והפער מצטבר מדי יום.
השני — השהיה במשיכה מסטייקינג. המשיכה אינה מיידית: הבקשה נכנסת לתור לאנסטייק ומבוצעת כאשר יגיע תורה ובמאגר יהיה מספיק נזילות. ממשק שמציג את pufETH כאמצעים פנויים מבטיח משיכה שאין אותה ממש עכשיו.
השלישי — חשבונאות פוזיציות סטייקינג. כאשר מחברים pufETH לפרוטוקולים חיצוניים, הפוזיציה מפסיקה להיות רק יתרה בארנק: היא מתפצלת, מושכנת, נודדת בין חוזים. בלי קישור לכתובת הבעלים ולהיסטוריית פעולות, פוזיציה כזו נופלת מהחשבונאות — אי אפשר להציג אותה בדוח ולא להחזיר אותה לבעלים כראוי.
בהמשך נפרק כיצד המעגל הזה נסגר: התאמת שער, טיפול בתור המשיכה וחשבונאות פוזיציות מקצה לקצה.
מה משתנה לאחר חיבור סטייקינג נזיל
לאחר חיבור סטייקינג נזיל, העירבון מפסיק להיות נכס קפוא: אותה פוזיציה מניבה תגמול ובו בזמן נשארת פעילה. להלן שני שינויים שנראים גם בדיווח וגם בהתנהגות המערכת. Puffer Finance מספק ייצוג נזיל של הנתח, וממנו מתחילה האינטגרציה הבאה.
העירבון כבר אינו חסום
המשתמש מפקיד עירבון פעם אחת ומקבל טוקן נזיל של נתח — pufETH. ניתן למשכן, להחליף או למשוך את הנתח בלי לסגור את פוזיציית הסטייקינג. הפשרה וההמתנה בתור היציאה מפסיקות להיות תנאי לגישה לכל ההון: הן משפיעות רק על הנתח עצמו, ולא על הפוזיציה כולה.
חשבונאות שקופה ומהירות משיכה
תגמולי סטייקינג ופעולות בנתח מרוכזים במרשם אחד עם שער חליפין משותף. הנהלת החשבונות רואה לא העברות מפוזרות, אלא פוזיציה עם היסטוריה: כמה נצבר, כמה נמשך, כמה נשאר בפעילות. זה מסיר סוג כשל נפרד — חשבונאות כפולה של אותו נתח בעת העברה בין מעגלים ופער בשער בעת חישוב מחדש.
מהירות המשיכה נקבעת כעת על ידי תור היציאה, ולא על ידי שחרור ידני של הפוזיציה: החלק הנזיל יוצא מיד דרך החלפת הנתח, והשאר — בלוח זמנים צפוי. ההון מפסיק לשהות ללא שימוש, וכל תנועה נרשמת במרשם משותף, ולכן פערים מתגלים בשלב ההתאמה, ולא אחרי תקופת הדיווח.
פורמטים לעבודה עם Puffer Finance: מעגל ישיר ומתווך
הפרוטוקול Puffer Finance מנפיק pufETH תמורת הנכס שהופקד, ופורמט החיבור קובע מי אחראי לתקינות הפעולות הבאות: השירות שלכם, פלטפורמה חיצונית או שני הצדדים. ההבדל נראה לא בהפקדה הראשונה, אלא במשיכה, בצבירת התגמולים וברגע התקלה — שם טעות בחשבונאות עולה ביוקר. להלן שלוש סכמות שביניהן באמת בוחרים.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| חיבור ישיר לחוזה | הצוות מחזיק שירות חשבונאות משלו, נדרשים תרחישים לא סטנדרטיים עם pufETH ושליטה מלאה בארנק | אתם עוקבים בעצמכם אחרי אירועי הפקדה ומשיכה, עוקבים אחרי הפסקות ועדכוני חוזה, מטפלים בכשלי צומת ובבנייה מחדש של בלוקים |
| שירות מתווך | לוחות זמנים קצרים, אין צוות בלוקצ'יין משלכם, נדרשת חשבונאות פוזיציות מלאה | תלות ברמת שירות של צד שלישי ובעמלותיו, סט מוגבל של פעולות, השהיה במשיכה |
| סכמה היברידית של ריסטייקינג | פעולות קריטיות — הפקדה ומשיכה — נשארות אצלכם, שגרתיות (חשבונאות תגמולים, איזון מחדש) נמסרות לשירות | ביקורת מורכבת יותר: צריך לחלק אחריות ולהחזיק שכבת התאמה בין שני מקורות נתונים |
מגבלות האינטגרציה כמעט תמיד נמצאות במקום אחד — סנכרון יתרת pufETH עם החשבונאות הפנימית. אפשרות החיבור המתאימה היא זו שבה הסנכרון הזה ניתן לבדיקה: יש יומן פעולות, סדר חזרה ברור ובדיקת פער ניתנת לשחזור. תארו את המשימה — נחזור עם הערכה ותוכנית.
סדר העבודה: מניתוח פוזיציות ועד העלאה לרשת
סדר העבודה קובע עד כמה צפוי המעגל לעלות לרשת: קודם מתעדים מה כבר נמצא בחשבונות ובמאגרים, אחר כך מתכננים את הסכמה, ורק לאחר מכן כותבים קוד. להלן מסלול האינטגרציה של ריסטייקינג נזיל: מביקורת פוזיציות ועד מסירת מעגל עובד לצוות שלכם.
לפני העלאה לרשת
- ביקורת פוזיציות נוכחיות — ספירת מלאי של ארנקים וחשבונות: אילו נכסים משתתפים, היכן כבר מונחים טוקנים נגזרים, ואילו מגבלות ותפקידים הוקצו.
- סכמת המעגל — מתארים את הזרימות: קבלת pufETH, חלוקה לפי אסטרטגיות, משיכה וחשבונאות תגמולים. מאשרים את הסכמה לפני תחילת העבודה, כדי שפערים לא יצופו בבדיקה.
- הגדרת האינטגרציה — מממשים קריאות, טיפול בכשלים, ניסיונות חוזרים ותיעוד פעולות; מפרידים מפתחות ותפקידים לפי רמות גישה.
בדיקה ומסירה
- הרצת בדיקה — מעבר על מחזור מלא ברשת מבודדת: הנפקה, חשבונאות, משיכה, תרחישי כשל ושחזור מצב אחריו.
- מסירת המעגל לפעילות — פורסים ברשת הראשית, מפעילים ניטור, קובעים נוהל עדכונים וסדר חזרה.
- מוסרים תיעוד ומפרקים את המעגל עם הצוות שלכם: מה הוגדר היכן, כיצד לקרוא מדדים ומה לעשות בחריגות.
תיעוד וארטיפקטים שנשארים אצלכם
תיעוד הוא חלק מהאספקה, ולא נספח אליה. אנחנו מתעדים כל מה שתכננו והגדרנו, כך שמהנדס שלא השתתף בפרויקט יוכל לשחזר את הסביבה ולחזור על כל פעולה — מהנפקת חוזה ועד משיכת כספים.
סכמות ומרשמים
- סכמת המעגל: חוזים, הקשרים ביניהם, נקודות קריאה חיצוניות ומי שולט במה.
- מרשם כתובות: חוזים, ארנקי תפקידים, כתובות חלוקת תשלומים ומפתחות גיבוי — עם ייעוד לכל אחד.
- סכמת זרימות: מסלול ההפקדה, ההנפקה וההחלפה ההפוכה של Puffer Finance עם קטעים שבהם ייתכנו השהיות משיכה.
- מפת תלויות: חוזים ואורקלים חיצוניים שכשל שלהם משפיע על פעילות הפרוטוקול.
נהלים ומסירה
- נוהל משיכת כספים ושחזור גישה: נהלים צעד-אחר-צעד, ספי אישורים, פעולות בעת פגיעה במפתח.
- מדיניות גישה לחוזים: מטריצת תפקידים, מגבלות והשהיות לפעולות קריטיות.
- פריסה ברשת בדיקה וצ'ק-ליסט קבלה לפני העלאה לרשת הראשית.
- כתב מסירת תיעוד עם גרסאות ונקודות עדכון.
סכמת המעגל ומרשם הכתובות מסירים את הסיכון המרכזי — מצב שבו רק אדם אחד יודע לבצע שינויים בחוזה, והשאר פועלים מהזיכרון. את הנהלים בודקים במשיכת כספים לדוגמה: אם ההליך אינו משוחזר לפי המסמך במעבר אחד, חוזרים ומתקנים את הנוסחים עד שהוא נעשה חד-משמעי.
מקרה בוחן: איך הסרנו השהיות במשיכה מסטייקינג
פוזיציות של גזברות נמשכו מסטייקינג באופן ידני: מפעיל עקב אחרי סטטוס הבקשה, השווה אותו למצב הקבלה הנזילה ושליח מחדש את הפעולה אם הראשונה לא עברה. בעומס שיא שיעור המשיכות התקועות הגיע ל-11%, שחזור פוזיציה ארך כשעה, והתחשבנות העסקה נדחקה יחד איתו. את ההטמעה התחלנו דווקא בקטע הזה.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| שיעור פעולות משיכה תקועות | 11% | 0.4% |
| זמן חציוני למשיכת פוזיציה | 6 שעות | 8 דקות |
| שחזור פוזיציה לאחר כשל | ~50 דקות, ידני | עד 3 דקות, אוטומטי |
| פניות חוזרות על אותה פוזיציה | כל שלישית | בודדות |
חיברנו את Puffer Finance והעברנו את המשיכה לקבלה הנזילה pufETH: הפוזיציה כבר לא ממתינה לפירוק בתור היציאה, אלא הופכת מיד לכלי שמשתתף בהתחשבנות ויכול לשמש כעירבון. בדיקת הסטטוס וניסיונות חוזרים הועברו למעגל אוטומטי — השלב הידני של המפעיל הוסר מהסכמה לחלוטין.
מה השתנה בתפעול
סוג הכשל שהוסר — פעולת משיכה שאבדה או נשלחה פעמיים, שבגללה הפוזיציה נתקעה בין מצבים. כעת מקרים כאלה נתפסים על ידי האוטומציה ומובאים לסיום בלי מעורבות אדם, ולכן פניות חוזרות על אותה פוזיציה נעשו בודדות. את הזמן שהתפנה צוות הלקוח משקיע בעסקאות, ולא בהתאמת סטטוסים.
במה ריסטייקינג נזיל שונה מסטייקינג קלאסי?
סטייקינג קלאסי חוסם את העירבון בשכבת הקונצנזוס: הנכס מפסיק להיות נזיל ונשאר צמוד לוולידטור מסוים. זכויות המשיכה של העירבון אינן נפרדות מההפקדה — אפשר להשתמש בהן רק לאחר יציאה מתור ההפעלה. התשואה במקרה זה נצברת על יתרה קפואה.
ריסטייקינג נזיל משאיר את העירבון ברשת, אבל מנפיק מולו טוקן נגזר — באינטגרציה עם Puffer Finance זה pufETH. הטוקן מחזיק נתח במאגר משותף ותשואה מצטברת, בעוד זכויות משיכת העירבון נשארות אצל חוזה העטיפה, שמבצע את ההפקדה והמשיכה ההפוכה. המחזיק מקבל כלי נזיל בלי להוציא את העירבון מהרשת.
המקור העיקרי לפערים בחשבונאות — מה נחשב ליחידת יתרה. שער החליפין עולה ככל שנצברת התגמול, ואינו שווה לאחת, ומחיר השוק של הטוקן סוטה מהשער הזה לשני הכיוונים. חישוב לפי הנתח וחישוב לפי השוק המשני נותנים מספרים שונים לאותה פוזיציה.
יכולת העבודה של העירבון נקבעת לפי אופן חלוקת הקנס על הפרות של הוולידטור. הוא מקטין את המאגר הכללי, ולא הפקדה בודדת באופן אישי, ולכן מחזיק הטוקן הנגזר חולק את הסיכון ביחס לנתח שלו.
אצל סטייקר קלאסי הסיכון ממוקד בוולידטור אחד, וכאן הוא מפוזר על פני סט של מפעילים — מודל הסיכון עצמו משתנה.
בנפרד — תור המשיכה: את הטוקן אפשר למכור מיד, אבל ההחלפה לעירבון עצמו כפופה לתור היציאה ברשת, ומכאן הדיסקאונט ברגעי עומס. בדיוק את הנקודות האלה — זכויות משיכה, שער חליפין ולוגיקת הקנס — בודקים במעגל בדיקה לפני הפעלה בפרודקשן.
ספקות טכניים לפני העלאה לפעילות
לפני העלאת המעגל של Puffer Finance לפעילות, הלקוח שואל אותן שאלות: מה יקרה אם המקבל יוקפא, כיצד מחושב שער החליפין, במה מאושר הדיווח. להלן תשובות קצרות עם הערכת סיכון ודרך להסירו.
מה לעשות אם כתובת המקבל תוקפא?
את ההקפאה מכריז מנפיק או קסטודיאן — לא הקוד שלנו ולא סטטוס הפעולה משפיעים עליה. לכן מראש מתאמים כתובת חלופית, מריצים אותה במעגל בדיקה ומתכננים החזרה לחשבון הראשי במקום תשלום תקוע.
כיצד נבדק שער החליפין לפני עסקה?
שער הטוקן הנגזר עולה ביחס לנכס הבסיס, ולכן מתעדים לא מספר אלא סטייה מותרת ועומק המאגר. אם החלקה מחושבת חורגת מהמגבלה, הפעולה אינה מבוצעת ועוברת לבדיקה ידנית.
כיצד מאושר הדיווח על הצבירות?
כל צבירה נכנסת למרשם עם כתובת, זמן וקישור לפעולה ברשת. ההתאמה נעשית מדי יום, פערים נאספים לרשימה נפרדת ומגיעים יחד עם הסיכום — בלי חישוב מחדש ידני.
למה נדרש ביקורת חיצונית של המעגל?
ביקורת לא מחליפה בדיקות פנימיות, אבל נותנת חוות דעת עצמאית על הקוד, הרשאות הגישה והעבודה עם מפתחות. את הדוח מוסרים עם תיאור תפקידים — אפשר להציג אותו לשותפים ולמערך האבטחה.
נדון במשימה ונחזור עם הערכה ותוכנית
כדי שהחישוב יתבסס על עובדות ולא על הנחות, בשלב הראשון נדרשים נתוני פתיחה: באילו רשתות פועל המוצר, כיצד מתוכנן הטיפול ב-pufETH — להחזיק ביתרה, למשכן כעירבון או לשלב באסטרטגיות — ואילו ממשקים כבר קיימים במערכת.
מצדנו נחזור עם הערכה ותוכנית עבודה: הרכב העבודה, סדר השלבים, לוחות זמנים להפעלה ונקודות שבהן יידרש החלטה שלכם. את ההיקף והרצף רואים לפני ההתחלה, ולא תוך כדי האינטגרציה.
מה מפרקים בפגישה הראשונה:
- תרחישי שימוש ב-pufETH: קליטת הפקדות, הנפקה, החלפה בהתחשב בשער ובעמלות, משיכת כספים;
- נתוני פתיחה לחישוב: הארכיטקטורה הנוכחית, גישות לתשתית בלוקצ'יין ולצמתים, דרישות לאחסון מפתחות;
- מגבלות: זיהוי לקוחות, מגבלות על פעולות, דרישות לדיווח ולשמירת היסטוריה;
- מה כבר נעשה: ביקורת חוזים, סכמות שריון, אחראים בצד שלכם;
- מה מוסרים בתמורה: סכמת אינטגרציה, הרכב עבודה לפי שלבים, לוחות זמנים להפעלה וסדר קבלה;
- נקודות בקרה: באילו שלבים אתם מאשרים את התוצאה והיכן אפשרי חזרה לאחור.
תארו את המשימה וצרפו את מה שיש לגבי המימוש הנוכחי — נחזור עם הערכה ותוכנית עבודה.