חוזה חכם למנוי: היכן נשבר תשלום חוזר בקריפטו
חוזה חכם למנוי נשבר לא בשלב של "לחייב את הכסף", אלא במפגש של שלושה מצבים: יתרת המשתמש, ההרשאה לחיוב והעסקה שכבר נשלחה. כשל חיוב קלאסי נראה כך: הלקוח ביטל או הפחית את ה-allowance, והמתזמן ממשיך לשלוח בקשת חיוב לפי המגבלה הישנה — העסקה נכשלת, אבל במסד הנתונים המנוי כבר מסומן כשולם.
חוסר סנכרון בין היתרה ל-allowance הוא הסיבה הנפוצה ביותר לסירובים שקטים של חיובים חוזרים בקריפטו: המשתמש הוציא את הטוקנים במקום אחר, והשירות נודע על כך רק בעקבות עסקה שנכשלה.
הקבוצה השנייה של בעיות — עסקאות תקועות. החיוב נשלח לרשת, אך לא אושר: לא היה מספיק gas, ה-nonce תפוס על ידי פעולה קודמת, העסקה תלויה ב-mempool.
אם הלוגיקה של חידוש מנוי אוטומטי אינה מבחינה בין "לא נשלח" ל"נשלח, אך לא אושר", השירות או יחייב פעמיים בניסיון חוזר, או יאבד את התשלום וינתק גישה ללקוח שמשלם.
המקור השלישי — היעדר אידמפוטנטיות בניסיונות חוזרים. המתזמן חוזר על החיוב לאחר timeout, בלי לבדוק אם הניסיון הראשון עבר. בקריפטו זה יקר יותר מאשר בפיאט: החזר של חיוב שגוי דורש עסקה נפרדת והסכמה של המקבל.
חידושים ידניים, שלעיתים קרובות סוגרים בהם חורים, נותנים אפקט הפוך — העומס על התמיכה גדל, ושיעור המנויים באיחור לא יורד.
מפרקים כיצד זה נסגר ברמת החוזה והמתזמן.
ארכיטקטורת חוזה חכם למנויים ומצבי חיוב
חוזה חכם למנויים אינו "חיוב לפי טיימר", אלא מכונת מצבים סופית: active, past_due, grace, canceled. כל מעבר נרשם כאירוע ביומן, ולכן החידוש אידמפוטנטי: קריאה חוזרת עם אותו מזהה תשלום אינה יוצרת חיוב שני, אלא מחזירה את תוצאת הפעולה הראשונה. בלי זה, כל השהיית רשת הופכת לתשלום כפול.
מצב pull-approve: מינימום אמון, מקסימום חתימות
הסכימה הקלאסית: המשתמש מעניק פעם אחת הרשאה לחיוב, והחוזה מושך כספים לפי לוח זמנים. היתרון — אין צורך להחזיק יתרה בחוזה. המגבלה — ניתן לבטל את ההרשאה בכל רגע, והחידוש ייכשל. שיעור החידושים המוצלחים כאן תלוי בכמה מהר אנחנו מזהים גישה שבוטלה ומעבירים את המנוי ל-past_due עם התראה.
הפקדת Escrow: צפיות במקום הרשאות
המנוי מפקיד פיקדון בחוזה, והחיובים מתבצעים ממנו. החידושים מפסיקים להיות תלויים בחתימות חיצוניות — שיעור החיובים המוצלחים עולה, כי סירוב אפשרי רק ביתרת פיקדון אפסית. המחיר — כספים קפואים של המשתמש ולוגיקת החזרת היתרה בעת ביטול.
ערוץ תשלום: חיוב ללא טרנזקציה על כל חידוש
הערוץ נפתח פעם אחת, ובתוכו החידושים מתבצעים כעדכון מצב — ללא טרנזקציה נפרדת לכל תקופה. זה מסיר את סוג הכשלים של "לא הספיק gas לחידוש" ומאיץ התאוששות לאחר תקלה: מצב הערוץ משוחזר מהעדכון החתום האחרון, ולא משרשרת טרנזקציות.
| וריאנט | מתי מתאים | מגבלות |
|---|---|---|
| Pull-approve | חיובים קטנים ותכופים, המשתמש רוצה שליטה | תלוי בחתימה חיצונית, ביטול קוטע את החידוש |
| הפקדת Escrow | מנויים ארוכים, נדרשת צפיות | כספים קפואים, נדרשת לוגיקת החזר |
| ערוץ תשלום | תדירות חידושים גבוהה | ביקורת מורכבת יותר, נדרש בוררות סכסוכים |
בכל שלושת המצבים, אידמפוטנטיות החידוש מובטחת באמצעות מפתח (מנוי, תקופה): עיבוד חוזר של אותה תקופה אינו מזיז את היתרה. זה מסיר את סוג הכשלים הקשורים לניסיונות חוזרים וארגוני שרשרת מחדש.
OpenZeppelin
כיצד אנו מטמיעים חוזה חכם למנויים: שלבי העבודה
הטמעת חוזה חכם למנויים אינה מתחילה בקוד, אלא בניתוח של האופן שבו הכסף נע כיום: מי יוזם את החיוב, היכן נשמרות הרשאות הגישה, ומה קורה במקרה של תשלום כושל.
בשלב זה אנו מגדירים את התפקידים (משלם, מקבל, בורר), את המגבלות על סכום ותדירות החיובים, ואת תנאי ההשהיה וההחזר — פרמטרים אלה יוטמעו בהמשך בלוגיקה בלתי ניתנת לשינוי, ולא ניתן יהיה לשנותם תוך כדי תנועה.
לאחר מכן מגיעה הפעם היישום והבדיקה. החוזה נבנה כך שכל ענף התנהגות — חידוש מוצלח, חוסר במ� средства, ביטול הרשאה, סיום מוקדם — יהיה ניתן לשחזור ברשת בדיקה על עותק של תרחישים אמיתיים.
- ביקורת הלוגיקה הנוכחית של התשלום. מנתחים את מערכת החיוב, החיובים החוזרים, הטיפול בסירובים ובהחזרים, ומצליבים עם מה שאמור להיכנס לחוזה.
- תרשים תפקידים ומגבלות. מתארים מי רשאי לשנות את התעריף, להשהות את המנוי ולמשוך כספים; קובעים תקרות חיוב והגנה מפני ביצוע כפול.
- תכנון והגדרת החיובים. מגדירים את מודל הגישה לכספים, את התקופה ותנאי החידוש, ואת ההתנהגות במקרה של תשלום חלקי.
- פיתוח ובדיקה פנימית. כותבים את החוזה, מכסים במקרי קצה, ומריצים תרחישי כשל והפעלה מחדש.
- בדיקה ברשת בדיקה. משחזרים את מחזור החיים המלא של המנוי על עותק של נתוני ייצור, ומודדים את צריכת המשאבים לפעולה.
- ביקורת הלוגיקה של התשלום על ידי מומחים חיצוניים. בדיקה בלתי תלויה לאיתור פרצות ואחריות בחישובים לפני היציאה לרשת הראשית.
- מסירת החוזה ותיעוד. מוסרים את קוד המקור, תרשים התפקידים, הוראות לעדכון ולטיפול בתקלות, ומכשירים את צוות הלקוח.
כל שלב מסתיים בארטיפקט שניתן לבדוק: תרשים, דוח בדיקות או גרסה נעולה של החוזה. כך הופכת מסירת החוזה להליך מובן, ולא למסירה של "קופסה שחורה".
במה שונה מנוי דרך approve ממודל הפקדה?
במודל approve המשתמש מעניק לחוזה פעם אחת הרשאה לחייב מהארנק שלו, והשירות קורא ל-transferFrom בכל תקופה על הסכום המוסכם. החוזה לא מחזיק את הכספים אצלו — הכסף נשאר אצל הבעלים עד לרגע החיוב, ולכן אין סיכון של יתרות "תקועות".
הצד השני של המטבע — ההרשאה נשארת בתוקף עד לביטול מפורש, ואם השירות לא בודק את המגבלה המעודכנת לפני החיוב, העסקה נכשלת בגלל allowance לא מספק. ביטול המנוי כאן הוא שלילת ההרשאה מצד המשתמש, והוא פועל באופן מיידי, ללא תלות בלוגיקה של השירות.
מודל ההפקדה עובד אחרת: הלקוח מפקיד כספים בחוזה, והחיובים מתבצעים מהיתרה הפנימית לפי לוח זמנים. זה עמיד יותר לתקלות — התשלום לא תלוי בשאלה אם הארנק פעיל ברגע החיוב, ולא דורש אישורים חוזרים.
מנגד, החזרים בקריפטו הופכים לפעולה נפרדת: יש להחזיר את היתרה שלא נוצלה בקריאה מפורשת, כלומר החוזה חייב לחשב נכון כמה תקופות כבר נסגרו. אם זה לא נעשה, בעת ביטול המנוי המשתמש או מאבד את היתרה, או מקבל אותה פעמיים.
ההבדל המרכזי — היכן נמצא הסיכון. במודל approve הוא בצד השירות: החיוב עלול לא לעבור אם המשתמש ביטל את ההרשאה או משך את הכספים. במודל ההפקדה — בצד החוזה: טעות בהתחשבנות התקופות הופכת להחזרים שגויים ולפערים ביתרות.
בפועל, מודל approve פשוט יותר להתחלה מהירה ולא דורש החזקה קסטודיאלית, בעוד שמודל ההפקדה מנצח במקומות שבהם נדרשים חיובים מובטחים ללא מעורבות המשתמש וביטול מנוי צפוי מראש עם החזר אוטומטי של היתרה.
הגרסה ההיברידית נפוצה ביותר: ההפקדה מכסה חיובים שוטפים, ו-approve משמש לתשלומים חד-פעמיים. חוזה כזה מורכב יותר לביקורת, אך מבטל את שתי קבוצות הכשלים — גם חיוב שלא התבצע וגם יתרה תקועה.
מקרה בוחן: מנוי לשירות — שיעור החידושים המוצלחים גדל פי שלושה
שירות עם מנוי חודשי לתוכן דיגיטלי פעל על חידוש ידני: המשתמש עצמו יזם את התשלום, ובמקרה של סירוב הבנק או פקיעת תוקף הכרטיס המנוי פשוט שתק. שיעור החידושים האוטומטיים המוצלחים עמד על כ-30%, התמיכה טבעה במכתבים "חויבתי פעמיים" ו"למה נעלם הגישה", וההחזרים טופלו ידנית לפי יומן הפעולות.
מה שינו
עיצבנו חוזה חכם למנוי עם לוגיקת escrow: המשתמש נותן פעם אחת הרשאה לחיוב במסגרת תקרה, החוזה שומר את מצב המנוי (פעיל, מושהה, מבוטל) ואת תאריך התשלום הבא.
חיוב חוזר מתבצע לפי לוח זמנים ללא מעורבות אדם, וכל ניסיון נרשם כאירוע בבלוקצ'יין — מקרים שנויים במחלוקת נבחנים לפי יומן בלתי ניתן לשינוי, ולא לפי ייצוא ממערכת החיוב.
הוספנו ניסיון חוזר מושהה במקרה של כישלון: החוזה מנסה לחייב מספר פעמים במרווחים הולכים וגדלים ומודיע למשתמש לפני שהגישה תושהה. ביטול — בעסקה אחת, בלי מכתבים לתמיכה ובלי שיחות טלפון.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| חידושים אוטומטיים מוצלחים | ~30% | ~90% |
| טיפול ידני בכשל תשלום | דקות לכל מקרה | שניות לפי יומן האירועים |
| פניות לתמיכה בנושא תשלום | זרימה בסיסית | ירדו בערך פי שלושה |
| החזרים וחיובים כפולים | קבועים | בודדים |
הגידול בשיעור החידושים המוצלחים נבע לא מ"קסם" של בלוקצ'יין, אלא ממחזור חיים צפוי של המנוי: ההרשאה ניתנת פעם אחת, המצב נשמר בחוזה ולא בראש של המשתמש. התמיכה הפסיקה להיות מחלקת הנהלת חשבונות של מנויים והחלה לעסוק במוצר.
מה אם המשתמש ירצה לבטל את המנוי? ביטול הוא פונקציה נפרדת של החוזה, זמינה בכל רגע; לאחריה החיובים מפסיקים, והגישה נשמרת עד סוף התקופה ששולמה.
מה אם הרשת עמוסה? התשלום מוכנס לתור ומבוצע עם ירידת העומס; המשתמש רואה את הסטטוס, והגישה לא נעלמת באופן מיידי.
אם המנוי שלכם נשען על חידושים ידניים ומכתבים לתמיכה — תארו את המשימה, ונחזור עם הערכה ותוכנית.
תאימות, מיגרציה וחזרה לאחור: ספקות טכניים
חוזה חכם למנויים כמעט לעולם אינו מופעל על מקום ריק: ללקוח כבר יש חיוב, מאגר משלמים, וובהוקים ואנליטיקה. לכן השאלה הראשונה בדיון היא לא "איזה בלוקצ'יין", אלא כיצד החוזה משתלב במערכת הקיימת ומה יקרה למנויים הנוכחיים ברגע המעבר. להלן ארבעה ספקות טכניים שעולים לעתים קרובות ביותר.
מה יקרה למנויים פעילים בעת המיגרציה?
אנחנו מעבירים לא יתרות אלא זכויות: עבור כל משלם אנחנו מתעדים תמונת מצב (תוקף, מסלול, היסטוריית חיובים) ומעלים אותה לחוזה החדש בעסקה אחת במנות. את החוזה הישן אנחנו מעבירים למצב "קריאה בלבד" — חידושים דרכו נעצרים, אך הנתונים נשארים זמינים לבדיקה. את תקופת החשבונאות הכפולה סוגרים בבדיקה: אי-התאמה בכל כתובת נראית לפני שנכבה את הלוגיקה הקודמת.
מה אם יש צורך לחזור לאחור בחוזה? את החזרה לאחור מתכננים מראש: הלוגיקה מוצאת אל מחוץ לעטיפת פרוקסי, המצב נשמר בנפרד מהקוד, והמעבר למימוש הקודם הוא עסקה אחת עם כתובת שנבדקה מראש. מפתחות המנהל נמצאים בחתימה מרובה, ולכן החזרה לאחור לא יכולה להיות מיוזמתו של אדם אחד.
כיצד להפריד הרשאות גישה? אנחנו מפרידים תפקידים: קבוצה אחת מנהלת מסלולים, אחרת — השהיות ועצירות חירום, ושלישית רק קוראת מדדים. כל פעולה נרשמת ביומן אירועים, ומגבלות על שינוי תנאים מוגדרות בתוך החוזה עצמו.
האם זה תואם למחסנית הנוכחית? החוזה מתקשר עם העולם החיצון באמצעות קריאות תקניות ווובהוקים, ולכן החיוב, ה-CRM והאנליטיקה ממשיכים לעבוד ללא כתיבה מחדש — משתנה רק מקור סטטוס המנוי.
הלקוח מקבל לידיו:
- תרשים מיגרציה של מנויים פעילים עם סדר הבדיקה;
- נוהל חזרה לאחור של החוזה ומטריצת תפקידי גישה;
- תיאור התאימות למחסנית הנוכחית ונקודות האינטגרציה;
- יומן אירועים וכללי ביקורת על פעולות המנהלים;
- הוראות לעצירת חיובים בשעת חירום;
- סביבת בדיקה עם הרצת מיגרציה על עותק של הנתונים.
תארו את המשימה שלכם — נחזור עם הערכה ותוכנית עבודה לחוזה ולמיגרציה.
לוחות זמנים ליישום חוזה חכם מבוסס מנוי לפי שלבים
לוחות הזמנים ליישום חוזה חכם מבוסס מנוי נקבעים לא לפי נפח הקוד, אלא לפי מספר התלויות החיצוניות: כמה טוקנים אנו מקבלים, דרך איזה שער תשלום, והאם נדרשת רגל פיאט. להלן שלבי פיתוח משוערים שאנו עוברים בכל פרויקט.
את פיזור לוחות הזמנים יוצר דווקא החלק האינטגרטיבי: אם המנוי מקושר לספק תשלום חיצוני או דורש חישוב פיאט, שלב הפיתוח מתארך. כאשר המודל סגור בתוך הרשת והטוקן, אנו עומדים בגבול התחתון.
בנפרד אנו מקצים זמן לביקורת לפני העלאה לרשת הראשית — חוזה שמחייב כספים לפי לוח זמנים אינו ניתן לתיקון לאחר ההפעלה ללא מיגרציה. OpenZeppelin מספק תבניות מאומתות להרשאות ולהגנה מפני כניסה חוזרת, אך את לוגיקת התמחור והחידוש אנו בודקים ידנית בהתאם למודל הספציפי.
לוחות זמנים מדויקים נמסור לאחר אפיון הדרישות: תארו את מודל המנוי ואת הסביבה — נחזור עם הערכה ותוכנית לפי שלבים.