פיתוח חוזי כריית נזילות: ביקורת ואופטימיזציית גז

מדוע חוזי ליקווידציה-מיינינג נכשלים בעומס שיא

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

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

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

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

מה נותן חוזה מותאם: מהירות ועמידות

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

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

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

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

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

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

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

מתי כל מצב מתאים

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

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

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

כיצד בנויה העבודה: מביקורת ועד מסירת הפתרון

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

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

דוח ביקורת, סכמת לוגיקה ותקנון ליווי

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

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

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

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

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

מה הראו המדידות

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

מה שינינו ומה קיבלנו

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

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

מה לעשות אם הפתרון כבר הוטמע ואי אפשר לעצור אותו

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

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

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

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

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

שאלות טכניות נפוצות בנוגע לאינטגרציה ולליווי

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

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

מה יקרה לאינטגרציות לאחר עדכון החוזה?

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

מי מנהל את החוזה לאחר ההשקה וכיצד בנויות ההרשאות?

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

נדון במשימה: אילו נתונים נדרשים להערכה

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

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

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