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

אופטימיזציית גז: היכן עסקאות מאבדות יעילות

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

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

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

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

מה נותנת אופטימיזציית גז: אפקטים מדידים

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

הפחתת עלויות הרצה

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

שיעור הפעולות המוצלחות

את הערכת העלות מחשבים לתרחיש ספציפי, עם מרווח לשינוי במצב, ולא "בעין". שיעור הפעולות שמגיעות לאישור בניסיון הראשון עולה מ-80–85% ל-97% ומעלה.

זמן אישור

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

כשלי עסקאות

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

חיזוי עומס

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

מצבי ביצוע עסקאות: השוואת גישות

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

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

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

שלבי הטמעה: ממדידות ועד מסירת נהלים

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

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

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

חבילת מסירה: קונפיגורציות, סכמות, נהלים

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

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

מקרה בוחן: הפחתת עלויות הרצת פעולות

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

מה נבנה מחדש

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

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

תוצאה

תשלום היתר ביחס למחיר המחושב ירד מ-38–40% ל-5–7%, שיעור הכשלים — מ-9–12% לפחות מ-1%, מספר הפניות למצב לפעולה הצטמצם פי שלושה, העלות של פעולה טיפוסית — פי 2.4. ההטמעה ארכה שישה שבועות: תחילה תחזית מחיר ושליחה חוזרת, אחר כך עיבוד באצוות, ובסוף — בנייה מחדש של האחסון. המסלול הישן והחדש עבדו במקביל, המעבר — בהגדרה אחת, ולכן חזרה לסכמה הקודמת ארכה דקות.

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

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

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

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

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

מגבלות טכניות ושאלות נפוצות של לקוחות

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

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

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

מה יהיה עם האינטגרציות — ארנקים, בורסות, שירותים פנימיים?

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

איך אתם מוכיחים שהשתפר?

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

נדון במשימה: ממה מתחילה העבודה

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

מה לשלוח לניתוח ראשוני:

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

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

נדון במשימה: תארו אותה בהודעה, את הנתונים החסרים נאסוף יחד עם המהנדסים שלכם.