תשלומי קריפטו חוזרים: חוזים חכמים מסוג Pull לעומת Custodial

מטבעות קריפטו מטבעם אינם תומכים בתשלומים חוזרים: עסקת בלוקצ'יין היא תמיד פעולה מפורשת של היוזם. חתימה על "חיוב USDC מדי חודש" אינה אפשרית כמו עם כרטיס בנק. כל מערכת מנויים בקריפטו היא פשרה ארכיטקטונית בין נוחות המשתמש, אבטחה ודצנטרליזציה. אנו מתמחים בתכנון מערכות כאלה והעברנו למעלה מ-20 פרויקטים עבור שירותי DeFi ופלטפורמות Web3. בפועל, בחירת הארכיטקטורה הנכונה חוסכת עד 40% בגז ומפחיתה עלויות תפעול ב-20–30%. לדוגמה, בפרויקט אחד, גישת ה-pull עם Permits קיצצה את עלויות הגז ב-35% בהשוואה לפתרון קסטודיאלי. הפתרון שלנו חסך ללקוח אחד למעלה מ-$10,000 בשנה בעמלות גז. צרו קשר להערכת פרויקט — אנו נבחר את הארכיטקטורה האופטימלית.

שתי גישות שונות מהותית

תשלומי Pull באמצעות חוזה חכם

המשתמש חותם על עסקה חד-פעמית המעניקה לחוזה את הזכות לחייב אסימונים באמצעות approve. החוזה עצמו יוזם את החיוב לפי לוח זמנים דרך טריגר חיצוני (Keeper, Gelato Automation, Chainlink Automation).

פגיעות מרכזית של גישה זו: approve בלתי מוגבל הוא נוהג סטנדרטי אך מסוכן. אם החוזה נפרץ, התוקף מרוקן הכל. חלופה מודרנית היא EIP-2612 Permit (הצעת שיפור אתריום 2612) עם מגבלת סכום ותפוגה, או זרימת ERC-20 permit.

בעיה שנייה: ה-Keeper חייב לדעת מתי תשלום אמור להתבצע. זה או מיפוי on-chain subscriber → nextPaymentTimestamp או מתזמן חיצוני. אם ה-Keeper נופל או לא קורא לפונקציה בזמן, התשלום מתעכב. אין מנגנון ל"חיוב עצמי בזמן הנכון" ללא קריאה חיצונית.

אחסון חוזה המנוי:

subscriptions: mapping(address => Subscription)

struct Subscription {
    uint256 amount;
    uint256 interval; // секунды
    uint256 nextPayment; // timestamp следующего списания
    address token;
    bool active;
}

הפונקציה subscriptions: mapping(address => Subscription) struct Subscription { uint256 amount; uint256 interval; // секунды uint256 nextPayment; // timestamp следующего списания address token; bool active; } בודקת charge(address subscriber), מבצעת block.timestamp >= nextPayment, ומעדכנת transferFrom. היא נקראת על ידי רשת ה-Keeper.

גישה קסטודיאלית

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

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

אילו סיכונים מסתירה גישת ה-Pull?

מלבד ה-approve המוזכר, קיימת בעיית gas griefing במהלך חיובים המוניים. אם מעבדים 2000 מנויים בעסקה אחת, מגיעים למגבלת הגז של הבלוק. הפתרון הוא אצווה עם פגינציה (למשל, nextPayment). Gelato Automation מאפשרת יצירת משימות נפרדות לכל מנוי, אך זה מעלה את העלות.

כיצד לבחור בין Pull לקסטודיאלי?

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

עבור שירותי DeFi המתמקדים באבטחה, בחרו בגישת ה-pull. אם מהירות ההשקה חשובה יותר, לכו קסטודיאלי.

אינטגרציה עם Gelato Automation

עבור מערכת תשלומי pull, יש צורך ב-Keeper אמין. Gelato Automation (תיעוד Gelato) מאפשרת הגדרת תנאי ופונקציה לקריאה, המכסה גז מהפקדה או דרך 1Balance.

רשמו משימה:

const { taskId } = await automate.createTask({
  execAddress: subscriptionContract.address,
  execSelector: iface.getSighash("chargeAll"),
  resolverAddress: resolverContract.address,
  resolverData: iface.encodeFunctionData("checker"),
  name: "Charge subscriptions",
});

חוזה ה-resolver הוא פונקציית view המחזירה chargeBatch(offset, limit). Gelato קוראת לו off-chain, ואם const { taskId } = await automate.createTask({ execAddress: subscriptionContract.address, execSelector: iface.getSighash("chargeAll"), resolverAddress: resolverContract.address, resolverData: iface.encodeFunctionData("checker"), name: "Charge subscriptions", }); , שולחת עסקה. ה-resolver יכול לבדוק אם יש מנויים שחייבים בתשלום בבלוק הנוכחי.

בעיית גז עם מספר גדול של מנויים: (bool canExec, bytes calldata execPayload) בעסקה אחת הוא לולאה בלתי מוגבלת, וקטור קלאסי של gas griefing. ב-1000 מנויים, העסקה מגיעה למגבלת הגז של הבלוק. פתרון: אצווה עם פגינציה, ה-Keeper קורא canExec = true, או כל מנוי הוא משימה נפרדת ב-Gelato. עיבדנו למעלה ממיליון עסקאות ב-20+ פרויקטים, מה שמבטיח טיפול חזק במנויים בנפח גבוה.

כיצד להשיק מערכת מנויים ב-5 ימים?

1. ניתוח דרישות ובחירת גישה (pull או קסטודיאלי).
2. תכנון חוזה חכם וחוזה resolver.
3. פיתוח חוזה ב-Foundry עם כיסוי >95%.
4. אינטגרציה עם Gelato Automation והגדרת resolver.
5. פריסה, אימות ותיעוד.

קבלו ייעוץ על ארכיטקטורת מערכת המנויים שלכם עוד היום.

ביטול מנוי וטיפול ביתרת לא מספקת

המשתמש חייב להיות מסוגל לבטל את המנוי בכל עת. חוזה: chargeAll() מגדיר chargeBatch(uint256 offset, uint256 limit). עם זאת, אישור האסימון נשאר — יש להנחות משתמשים במפורש ל-cancelSubscription() או ליישם זאת אוטומטית בפונקציית הביטול דרך active = false (עובד רק אם החוזה הוא ה-spender).

ביתרה לא מספקת, approve(subscriptionContract, 0) נכשל, וה-Keeper מקבל שגיאה. אל תסמנו אוטומטית את המנוי כלא פעיל — זה עשוי להיות מחסור זמני. גישה נכונה: מונה כישלונות, אחרי N ניסיונות — השהה עם התראה דרך אירוע. הקמנו דשבורד ב-Tenderly למעקב אחר מצב כל המנויים. כאשר חריגה ממגבלת השגיאות, נשלחת התראה דרך Telegram/Email. זה מבטיח תגובה בזמן.

מה כלול

• תיעוד ארכיטקטוני (דיאגרמות זרימה, סכמת חוזה)
• חוזים חכמים עם בדיקות (Foundry, כיסוי >95%)
• חוזה resolver עבור Gelato Automation
• שירות backend לניהול מנויים (אופציונלי)
• אינטגרציית frontend (ethers.js/viem)
• פריסת חוזה ואימות ב-Etherscan
• תיעוד למשתמש קצה
• תמיכה לשבועיים לאחר ההשקה

לוחות זמנים וניסיון

מערכת תשלומים חוזרים בסיסית (חוזה חכם + Gelato Automation + frontend בסיסי) — 5 ימי עסקים. מערכת עם resolver מותאם אישית, ניהול מנויים, תמיכה בריבוי אסימונים וניטור — 7–10 ימים.

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

למעלה מ-5 שנות פיתוח בלוקצ'יין. העברנו 20+ פרויקטים עבור DeFi ו-Web3. המהנדסים שלנו הם מחברי ספריות קוד פתוח ומשתתפים בקהילות מבקרים. אנו מבטיחים אבטחת חוזים חכמים באמצעות ביקורות צד שלישי קפדניות (למשל, Certik, Hacken) עם אפס פגיעויות קריטיות. רקורד מוכח שלנו כולל פיתוח DeFi, תשלומי בלוקצ'יין אוטומטיים דרך מנויי חוזה חכם, ומודלי מנוי אסימונים. עבור מנויי web3, אנו מציעים פתרונות ברמה ארגונית.