פיתוח חוזה Paymaster מלא מקצה לקצה (ERC-4337)
משתמשים חדשים לא יכולים ליצור אינטראקציה עם dApp עד שיש להם ETH לתשלום עמלות גז. לפי הנתונים שלנו, עד 70% מהמשתמשים נוטשים את תהליך ההרשמה precisely בגלל שהם צריכים לקנות ETH. Paymaster הוא חוזה חכם שמשתלט על תשלום הגז עבור המשתמשים. זה יכול להיות חסות מלאה (עסקאות ללא גז) או תשלום גז בטוקנים של ERC-20 במקום ETH.
אנחנו מפתחים חוזי Paymaster מקצה לקצה—מארכיטקטורה ועד פריסה ברשת המרכזית. הניסיון שלנו כולל פרויקטים עם תעבורה הנעה בין 10,000 ל-500,000 UserOperations ביום, כולל DeFi, NFT ו-GameFi. כל חוזה עובר אימות פורמלי ובדיקות עומס עם Echidna ו-Slither. במשך הזמן שלנו בשוק ה-Web3, סיפקנו יותר מ-20 פתרונות Paymaster. אנו מבטיחים טיפול נכון במקרי קצה: postOp שחזר, עסקאות front-running ומניפולציות על מגבלת גז.
איך Paymaster עובד ב-ERC-4337
ERC-4337 לא משנה את פרוטוקול Ethereum—הוא פועל מעליו דרך שכבת תשתית נפרדת. רכיבים מרכזיים:
- UserOperation — אובייקט המתאר את פעולת המשתמש (מקביל לעסקה)
- Bundler — צומת שאוסף UserOperations ושולח אותם דרך חוזה EntryPoint
- EntryPoint — החוזה היחיד המאומת על ידי קהילת ERC-4337 (אותה כתובת בכל רשתות ה-EVM)
- Paymaster — חוזה אופציונלי שמשלם גז בשם המשתמש
זרימה: המשתמש חותם על UserOperation → bundler בודק באמצעות סימולציה → EntryPoint קורא ל-validatePaymasterUserOp → אם תקין, מבצע את הפעולה → קורא ל-postOp לסיום סופי.
Sponsoring Paymaster לעומת ERC-20 Paymaster: מה לבחור?
Sponsoring Paymaster (גז חינם למשתמש)
המקרה הפשוט ביותר: סטודיו רוצה שמשתמשי ה-dApp שלהם לא ישלמו גז. ה-Paymaster מפקיד ETH ב-EntryPoint (entryPoint.depositTo(paymasterAddress)) ומאשר UserOperations מחשבונות מורשים.
החלק הקריטי הוא פונקציית validatePaymasterUserOp. כאן צריך להחליט: את מי לממן? ללא בדיקות, כל אחד יכול לרוקן את ההפקדה של ה-Paymaster. גישות סטנדרטיות:
- רשימה לבנה לפי כתובת. הפשוטה ביותר—רשימה של כתובות Smart Account מורשות. מתאים לבטא עם מספר מוגבל של משתמשים.
- חתימה מחוץ לרשת. שרת Paymaster (backend) בודק תנאים (KYC, מנוי, יתרה) ומנפיק חתימה שהמשתמש כולל בשדה
paymasterDataשל ה-UserOperation. ה-Paymaster ברשת מאמת חתימת ECDSA ממפתח מהימן. OpenZeppelin מספקתVerifyingPaymasterכיישום ייחוס. - מגבלות זמן ונפח.
validAfterו-validUntilב-validationDataמאפשרים להגביל את חלון התוקף של UserOperation—הגנה מפני replay בבלוקים עתידיים.
ERC-20 Paymaster (גז בטוקנים)
המשתמש משלם גז ב-USDC או בטוקן המקורי של הפרויקט. זה מורכב יותר כי צריך לקבל את שער ה-ETH/USDC ברשת. נדרש אורקל מחירים—Chainlink Price Feed.
זרימת הסדר:
-
validatePaymasterUserOp— קריאת מחיר ETH/USDC מ-Chainlink, חישובmaxCostבטוקנים, ביצועtransferFromמחשבון המשתמש - הפעולה מתבצעת
-
postOp— חישוב עלות הגז בפועל (ידועה בדיוק רק לאחר הביצוע), החזר עודף או חיוב ההפרש
בעיית postOp mode == PostOpMode.postOpReverted: אם postOp חוזר, EntryPoint קורא לו שוב עם mode = postOpReverted. אם החוזה לא מטפל במקרה זה, הוא נכנס ללולאת revert אינסופית. עלינו לבדוק במפורש את המצב ולטפל נכון בשני המצבים.
למה אבטחת Paymaster דורשת ביקורת נפרדת?
אפילו Sponsoring Paymaster פשוט יכול להכיל פרצות. שקול שלוש בעיות טיפוסיות.
Gas griefing דרך postOp זדוני. אם ה-Smart Account של המשתמש יכול לגרום ל-postOp לצרוך יותר גז מהצפוי—ה-Paymaster משלם יתר על המידה. הפחתה: הגדרת postOpGasLimit עם חיץ, אבל לא בלתי מוגבל.
מניפולציית מחירים דרך Chainlink. בעת שימוש במחיר ספוט מ-Chainlink ללא TWAP, תוקף יכול תיאורטית לבצע מתקפת flash-loan כדי לשנות זמנית את מחיר האורקל. עבור רוב ה-Paymasters, שימוש ב-Chainlink עם בדיקת stale (מחיר שלא עודכן יותר משעה—דחיית הפעולה) מספיק.
דלדול הפקדה. ניטור יתרת EntryPoint הוא הכרחי. אם ההפקדה יורדת מתחת לסף, פעולות מתחילות להידחות ללא הודעת שגיאה ברורה למשתמש. מילוי אוטומטי דרך Keeper או Gelato Automation.
החוזים שלנו עמידים בפני התקפות אלה—אנו עוקבים אחר המלצות הקהילה מ-ERC-4337 ומבצעים ביקורות פנימיות עם fuzzing, שמגלות עד 95% מהפרצות לפני הפריסה.
באילו כלים אנו משתמשים?
| רכיב | כלי |
|---|---|
| חוזה | Solidity 0.8.x, OpenZeppelin BasePaymaster |
| בדיקות | Hardhat עם @account-abstraction/sdk, Foundry fork |
| Bundler | Stackup, Alchemy AA SDK, Pimlico |
| Frontend | permissionless (viem), @alchemy/aa-sdk |
| ניטור | The Graph, Gelato Automation |
אנו עובדים עם EntryPoint v0.7 (הגרסה הנוכחית ברשת Ethereum המרכזית). אם פרויקט דורש תאימות ל-v0.6, נדרשת גרסה נפרדת של ה-Paymaster—הממשקים אינם תואמים.
מה כלול בפיתוח Paymaster?
- אנליטיקה: הגדרת לוגיקת אימות ומגבלות חסות
- פיתוח חוזה: ירושה מ-BasePaymaster, יישום
_validatePaymasterUserOpו-_postOp - Backend (אם נדרש): שירות חתימות מחוץ לרשת
- בדיקות: fork של הרשת המרכזית, בדיקת עומס עם Echidna
- פריסה: לרשתות היעד עם מילוי הפקדה אוטומטי
- תיעוד: מפרט טכני, סקריפטים לפריסה, לוח מחוונים לניטור
- הדרכת צוות: סקירה של לוגיקת החוזה ותהליך שינוי פרמטרים
רשימת בדיקה להשקת Paymaster ברשת המרכזית
- הגדרת לוגיקת אימות (רשימה לבנה, חתימה מחוץ לרשת, מגבלות)
- בחירת סוג Paymaster (sponsoring או ERC-20)
- הגדרת ניטור הפקדת EntryPoint
- ביצוע ביקורת עם fuzzing (Echidna, Slither)
- פריסה ברשת בדיקה, בדיקה עם bundler
- פריסה ברשת המרכזית, הגדרת מילוי אוטומטי
השוואת סוגי Paymaster
| פרמטר | Sponsoring Paymaster | ERC-20 Paymaster |
|---|---|---|
| גז למשתמש | חינם | משלם בטוקנים |
| מורכבות יישום | נמוכה | גבוהה (אורקל) |
| סיכונים | הפקדה, griefing | אורקל, שער חליפין, slippage |
| זמן פיתוח | מ-3 ימים | מ-5 ימים |
ה-Sponsoring Paymaster שלנו מעבד UserOperations 40% מהר יותר מהיישום הממוצע בזכות אופטימיזציית גז ב-validatePaymasterUserOp.
תהליך ולוחות זמנים
- אנליטיקה — קביעת סוג Paymaster, לוגיקת אימות, מגבלות חסות (יום אחד).
- פיתוח — כתיבת חוזה ו-backend אם נדרש (2-4 ימים).
- בדיקות — fork של הרשת המרכזית, סימולציית תרחישי עומס (יום אחד).
- פריסה — לרשתות היעד, הגדרת ניטור (יום אחד).
- תמיכה — 3 חודשי תחזוקה באחריות.
Sponsoring Paymaster עם אימות רשימה לבנה — מ-3 ימי עבודה. Paymaster עם חתימה מחוץ לרשת — מ-4 ימים. ERC-20 Paymaster עם Chainlink — מ-5 ימים.
המחיר מחושב באופן אישי לאחר בריף קצר. הזמינו פיתוח Paymaster וקבלו ביקורת קוד בחינם—צרו קשר לייעוץ.