שירותי פיתוח Paymaster להפשטת חשבונות

פיתוח Paymaster להפשטת חשבונות (Account Abstraction)

החסם המרכזי לאימוץ משתמשים ב-dApps הוא הדרישה להחזיק טוקנים מקומיים לתשלום דמי גז. ERC-4337 Account Abstraction פותר זאת באמצעות חוזי Paymaster המספקים חסות לגז – הם מכסים את דמי הגז, ומאפשרים למשתמשים ליצור אינטראקציה עם dApps ללא צורך בהחזקת ETH. המעבר ל-חוויית משתמש ללא גז (gasless UX) מגדיל את ההמרה ב-40% ומפחית את נטישת המשתמשים ב-30% – פי 2-3 טוב יותר מאשר דרישה לגז מקומי. הצוות שלנו, עם ניסיון של 5+ שנים בפיתוח בלוקצ'יין ו-50+ חוזים חכמים שפרוסים, יוצר פתרונות Paymaster מוכנים לשימוש המבטיחים יעילות גז אופטימלית והגנה מפני התקפות. אנו משתמשים בתבניות מוכחות ומספקים חוויית משתמש חלקה למשחקים, DeFi ויישומים חברתיים, ומשפרים את תהליך ההצטרפות ל-dApps. פתרונות ה-Paymaster שלנו עוזרים ל-dApps לחסוך בממוצע $5,000–$20,000 בחודש בדמי גז.

מדוע Paymaster קריטי לחוויית משתמש ללא גז

ללא Paymaster, משתמשים חייבים לקנות ולהחזיק ETH עבור כל עסקה. זה מפחית את ההמרה פי 2-3 בהשוואה לחוויית משתמש ללא גז. Paymaster פותר את הבעיה על ידי חסות לגז או קבלת תשלום בכל טוקן ERC-20. משתמשים חוסכים 100% על דמי גז, ועסקים רואים הפחתה של 40% בנטישה. עם חסות לגז, dApps יכולים להשיג שימור גבוה פי 3.

כיצד Paymaster משתלב עם ERC-4337

בעסקה רגילה: המשתמש חותם על עסקה → משלם גז ב-ETH. בזרימת ERC-4337: המשתמש חותם על UserOperation (לא עסקה) → Bundler אוסף את ה-UserOps → חוזה EntryPoint קורא ל-validatePaymasterUserOp → אם ה-Paymaster מאשר, הוא משלם את הגז → postOp נקרא לאחר הביצוע.

UserOperation {
  sender, // smart account пользователя
  callData, // что выполнить
  paymasterAndData, // адрес Paymaster + его данные
  signature, // подпись пользователя
  ...gasFields
}

paymasterAndData הוא address(paymaster) + bytes(paymasterSpecificData). ה-Paymaster מפענח את הנתונים שלו משדה זה.

סוגי Paymaster והארכיטקטורה שלהם

Paymaster מאמת (גז בחסות)

התבנית הנפוצה ביותר: שירות off-chain מחליט אם לתת חסות ל-UserOperation ספציפי וחותם על האישור. חוזה ה-Paymaster מאמת חתימה זו. EIP-4337 מתאר את החתימה _validatePaymasterUserOp.

function _validatePaymasterUserOp(
    UserOperation calldata userOp,
    bytes32 userOpHash,
    uint256 maxCost
) internal override returns (bytes memory context, uint256 validationData) {
    // Декодируем данные: подпись backend-а + срок действия
    (uint48 validUntil, uint48 validAfter, bytes calldata signature) = abi.decode(
        userOp.paymasterAndData[20:],
        (uint48, uint48, bytes)
    );
    // Хэш для верификации = хэш UserOp + validUntil + validAfter
    bytes32 hash = ECDSA.toEthSignedMessageHash(
        keccak256(abi.encode(userOpHash, validUntil, validAfter))
    );
    // Если подпись от verifyingSigner — спонсируем
    if (ECDSA.recover(hash, signature) != verifyingSigner) {
        return ("", _packValidationData(true, validUntil, validAfter));
    }
    return ("", _packValidationData(false, validUntil, validAfter));
}

השרת האחורי מקבל את ה-UserOp מהפרונטאנד, בודק תנאים (האם המשתמש ברשימה? האם הושגה מגבלת העסקאות החינמיות? האם סוג הפעולה מותר?), חותם, ומחזיר paymasterAndData. הפרונטאנד מכניס אותו ל-UserOp ושולח אותו ל-Bundler.

ERC-20 Paymaster (גז בטוקנים)

המשתמש משלם גז ב-USDC/USDT במקום ETH. ה-Paymaster מקבל טוקני ERC-20 וממלא את הפיקדון שלו ב-ETH ב-EntryPoint מהכספים שלו.

function _validatePaymasterUserOp(...) internal override returns (bytes memory context, uint256 validationData) {
    (address token, uint256 exchangeRate) = abi.decode(userOp.paymasterAndData[20:], (address, uint256));
    uint256 tokenCost = (maxCost * exchangeRate) / 1e18;
    // Проверяем allowance пользователя
    require(
        IERC20(token).allowance(userOp.sender, address(this)) >= tokenCost,
        "Insufficient allowance"
    );
    // context передаём в postOp для реального списания
    return (abi.encode(userOp.sender, token, tokenCost), 0);
}

function _postOp(PostOpMode mode, bytes calldata context, uint256 actualGasCost) internal override {
    (address sender, address token, uint256 maxTokenCost) = abi.decode(context, (address, address, uint256));
    // Реальная стоимость может быть меньше maxCost
    uint256 actualTokenCost = (actualGasCost * exchangeRate) / 1e18;
    IERC20(token).transferFrom(sender, address(this), actualTokenCost);
}

האתגר המרכזי עם ERC-20 Paymaster הוא שער החליפין. יש צורך בשער ETH/טוקן עדכני בזמן העסקה. אפשרויות: אורקל Chainlink, TWAP מ-Uniswap V3, או עדכון מחיר מרכזי מהשרת האחורי.

כיצד להגדיר הגבלת קצב עבור Paymaster?

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

1. מגבלת הוצאה למשתמש. מחוץ לרשת ב-Verifying Paymaster backend: לכל כתובת יש מגבלה חודשית בדולרים. השרת מסרב לחתום כאשר המגבלה חורגת.
2. תקופת צינון. לא יותר מ-N עסקאות בשעה לכל כתובת. מאוחסן ב-Redis עם TTL.
3. רשימת היתר לסוגי עסקאות. השרת בודק userOp.callData: רק קריאות לחוזים ספציפיים מקבלות חסות.
4. מערכת מוניטין. חשבונות חדשים מקבלים מגבלות מינימליות שגדלות לאחר אימות (Worldcoin, Sign In With Ethereum + דוא"ל).

למגבלה למשתמש, השתמש ב-Redis עם מפתח UserOperation { sender, // smart account пользователя callData, // что выполнить paymasterAndData, // адрес Paymaster + его данные signature, // подпись пользователя ...gasFields } ו-TTL חודשי. צינון באמצעות מונה Redis לשעה. רשימת ההיתרים מאוחסנת ב-PostgreSQL. השרת חותם רק אם כל הבדיקות עוברות.

ניהול פיקדון ויתרה

ה-Paymaster חייב להחזיק פיקדון ETH בחוזה EntryPoint. ה-EntryPoint מנכה גז מפיקדון זה לאחר כל UserOperation בחסות.

// Пополнение депозита
entryPoint.depositTo{value: 1 ether}(address(paymaster));

// Просмотр баланса
uint256 balance = entryPoint.balanceOf(address(paymaster));

// Вывод (unstake period для staked Paymaster)
entryPoint.withdrawTo(payable(owner), amount);

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

ערימת טכנולוגיות ותשתית

בחירת ספק Bundler

ה-Bundler הוא שירות שמקבל UserOperations ומכליל אותם בבלוקים. אפשרויות:

• Alchemy — התחלה קלה ביותר, תיעוד טוב, בתשלום בקנה מידה
• Stackup — Bundler בקוד פתוח, ניתן לאירוח עצמי
• Pimlico — מתמחה ב-AA, API נוח ל-Paymaster
• אירוח עצמי (go-bundler) — שליטה מלאה, נדרשת תשתית

מה כלול?

• בדיקת ארכיטקטורה ובחירת סוג Paymaster
• פיתוח חוזה חכם עם בדיקות (Foundry)
• שירות חותם בשרת עם API והגבלת קצב
• אינטגרציה לפרונטאנד (SDK)
• ניטור יתרה ומילוי אוטומטי
• תיעוד והדרכת צוות
• אחריות ל-6 חודשים על החוזים

תהליך הפיתוח

אנליטיקה (2-3 ימים). קביעת סוג Paymaster (בחסות לעומת ERC-20), רשתות יעד, מגבלות ומדיניות חסות, בחירת ספק Bundler.

פיתוח חוזה (1-2 שבועות). Paymaster מאמת או ERC-20, בדיקות מול EntryPoint v0.6/v0.7, ניהול פיקדון.

שירות חותם בשרת (שבוע). API לחתימת UserOps, הגבלת קצב, אורקל מחירים (ל-ERC-20). אינטגרציה לפרונטאנד (3-5 ימים). חיבור SDK, בניית UserOperation, ניטור סטטוס.

ניטור ותפעול (3-5 ימים). התראות יתרה, מילוי אוטומטי, לוח מחוונים להוצאות.

Paymaster מאמת בסיסי עם הגבלת קצב: 3-4 שבועות, החל מ-$8,000. ERC-20 Paymaster עם אורקל וניטור מלא: 5-7 שבועות, החל מ-$15,000.

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