עסקאות Lightning Network נתקעות בעומס שיא
כאשר תשלום ברשת Lightning לא עובר בתוך חלון הזמן שהוקצב, החשבונית בבוט נכנסת ל-timeout — אך אינה נעלמת. המשתמש רואה «התשלום לא עבר», לוחץ שוב על הכפתור, והניסיון הראשון באותו רגע עדיין תלוי במסלול. כך נוצר תשלום תקוע ב-Lightning Network: הרשת מחזיקה רזרבה עבור הפעולה, והממשק כבר מציע לחזור עליה.
לרוב הבעיה היא במחסור בנזילות בערוץ. המאזנים של הצד הנכנס והצד היוצא מוטים: משתתף במסלול פיזית אינו יכול להעביר תשלום בגודל הנדרש, והוא שוב ושוב נכנס לסבב חיפוש מסלולים עוקפים במקום סירוב מהיר. ככל שהסכום גדול יותר והמלאי הפנוי בצומת קטן יותר, כך עולה הסיכוי שהפעולה תיתקע או תיפול בזמן.
הסיבה השנייה — חוסר סנכרון בין הסטטוסים. הבוט סופר את המצב לפי הטיימר שלו, הרשת לפי שלה, ובעוד הראשון ממתין לתשובה, התשלום מספיק לעבור. לחיצה חוזרת על «שלם» מביאה לחיוב חוזר בבוט, והיתרה של המשתמש אינה תואמת את המצב האמיתי ברשת — את ההשוואה יש לעשות ידנית, לפי יומן הפעולות.
הוסיפו לכך את ה-timeout של חשבונית התשלום, שהוגדר «עם מרווח»: המשתמש לא מבין אם עליו להמתין או לשלם מחדש, ובוחר באפשרות השנייה. לכן תשלום בבוט Telegram אינו עובר דווקא בשעות שיא — כשהנזילות מתחלקת בצורה לא אחידה, והחשבוניות מחזיקות מעמד זמן רב מהרגיל. בהמשך נסביר כיצד זה נסגר ברמת הארכיטקטורה.
מה נותנת סכימת משמורת: מהירות ויכולת חיזוי
סכימת משמורת מסירה מנתיב התשלום את כל מה שתלוי בצמתים זרים. המפתחות והערוצים מוחזקים בידי השירות, ולכן העברה בין שני משתמשי בוט היא רישום בפנקס המאזנים הפנימי: הזיכוי אורך שברירי שנייה, ולא דקות של המתנה לאישור.
ההתחשבנות עם רשת Lightning Network נדחקת למקום שני ומתבצעת באצוות, כבר לאחר שהמשתמש ראה את הכסף ביתרה.
מכאן ההשפעה השנייה — שיעור התשלומים המוצלחים. ברשת הציבורית העברה עלולה שלא למצוא מסלול עם נזילות מספקת, והמשתמש מקבל סירוב סתם כך. בתוך השירות אין מסלולים כלל, והתשלומים היוצאים עוברים בערוצים שלנו, שבהם הנזילות מתחדשת מראש — שיעור הפעולות המוצלחות נשמר מעל 99%.
סוג שלם של כשלים נעלם — «תשלום תקוע», שבו הכספים חסומים במסלול זר, הסטטוס אינו ידוע, והתמיכה מטפלת בכך ידנית. העברה פנימית היא אטומית: או זיכוי, או שגיאה לפני החיוב. מצב של «בתהליך» שנמשך שעות פשוט אינו קיים בסכימה הזו.
זמן החזרה לפעילות נמדד אחרת. מצב הערוצים והפנקס משוחזרים מהעותק החתום האחרון — בלי סנכרון מחדש עם הבלוקצ'יין ובלי טיפול ידני בפעולות שנתקעו. לאחר תקלה הצומת שוב מקבל תשלומים תוך דקות, ולא תוך שעות.
יכולת החיזוי של ההתחשבנות היא תוצאה של שליטה: העמלות והנזילות בניהולנו, תשלומים המוניים מתבצעים לפי לוח זמנים ואינם תלויים במידת העומס על הרשת באותו רגע.
Lightning Network: מצבי החזקת כספים בבוט
מצב ההחזקה קובע מי אחראי לכספים בעת תקלה בבוט, וכמה יקרה היא התמיכה. להלן ארבע סכימות, שביניהן בוחרים למעשה בעת השקת תשלומי Lightning בבוט, עם המגבלות שלהן.
| מצב | מתי מתאים | מגבלות |
|---|---|---|
| משמורת | תשלומי מיקרו המוניים והשקה מהירה: המשתמש אינו מוכן להחזיק מפתח בעצמו | אמון מלא במפעיל; הוא גם נקודת כשל יחידה ומושא לדרישות להחזקת כספי אחרים |
| ללא משמורת | סכומים גדולים, כאשר המשתמש מנהל את היתרה בעצמו | שחזור גישה הוא באחריות המשתמש, התמיכה מורכבת יותר, חלק מהקהל מנופה בכניסה |
| היברידי | המחזור עובר דרך הבוט, והרזרבה נמצאת בארנק של המשתמש | לוגיקה כפולה של מגבלות והעברות בין מעגלים, השוואה ודיווח מורכבים יותר |
| ספק חיצוני | אין תשתית משלך, ההשקה נדרשת ללא תורנות | תלות במגבלות ובזמינות של הספק, ניתוב מחוץ לשליטה, נתוני תשלומים עוברים לצד שלישי |
כאשר חשובים השליטה במסלולים ובעמלות, מקימים את הסכימה על צומת משלך — אבל זו כבר הפעלה עם ניטור נזילות הערוצים ותורנות. מפתחות וגישה לכספים בכל וריאציה מתוארים במדיניות: מי בצוות מה רשאי, באיזו תדירות מסובבים מפתחות, מה קורה בעת חשיפה לרמאות וכיצד משחזרים גישה. את ההיברידי נוטים לקחת כפשרה — המחזור נשמר קטן, והיתרה אינה נשמרת בצד הבוט.
שלבי הטמעה: מניתוח תרחישים ועד מסירה
שלב ההתחלה אינו קוד, אלא ניתוח של איך התשלומים באמת זורמים במוצר: מי יוזם את ההעברה, באיזה רגע האחריות עוברת לשירות המשמורת, מה רואה המשתמש בעת ניתוק הקשר בין Telegram לצומת.
תרחישים אלה אנו מתעדים בכתב, מפני שמהם תלויים גם הטופולוגיה של הערוצים, גם הדרישות ליומן הפעולות, וגם עומק הבדיקה לתקלות.
- ביקורת תרחישי תשלום. אוספים את כל הענפים: העברות נכנסות ויוצאות, החזרים, תשלומי חסר, ניסיונות חוזרים לאחר פקיעת תוקף החשבונית. בפלט — רשימת מצבי הבוט וכללי המעבר ביניהם.
- תרשים תנועת הכספים. מתארים כיצד היתרה הפנימית של המשתמש מתייחסת ליתרה בצומת, היכן נשמרים המפתחות ובאיזה רגע הפעולה נחשבת להסתיימה. תרשים זה הופך לבסיס הלוגיקה החשבונאית ולפנקס הפעולות.
- הגדרת ערוצים ונזילות. קובעים את מספר הערוצים, את התפלגותם לפי כיוונים ואת ספי האיזון מחדש האוטומטי, כדי שהקיבולת הנכנסת לא תאזל בשעות שיא.
- בדיקת עמידות בתקלות. מריצים תרחישים של אובדן צומת, אי-זמינות ספק ומצב מיושן: שחזור מגיבוי, סגירת ערוצים תקינה, טיפול בתשלומים תקועים בלי זיכוי כפול.
- השוואה וניטור. מאוטמטים את ההשוואה בין הפנקס הפנימי למצב הצומת ומוציאים התראות על אי-התאמה, מחסור בקיבולת וגידול בתור הפעולות הכושלות.
- מסירה והדרכת תמיכה. מוסרים קונפיגורציות, תרשימים, הוראות לאירועים טיפוסיים ומקיימים הדרכה לקו הראשון: כיצד לקרוא סטטוסים, מה להסלים ואילו פעולות בטוחות ללא מהנדס.
מה נשאר אצלכם: קונפיגורציות, תרשימים, נהלים
אנחנו מוסרים לא גישה לבוט, אלא ערכה שלפיה ניתן להקים ולתחזק את התשתית בצוות שלכם. הכול נמצא במאגר סגור עם היסטוריית עריכות: רואים מי ומתי שינה את פרמטרי צומת ה-Lightning, את המגבלות ואת כללי הניתוב.
- קונפיגורציית הבוט — קבצי הגדרות של הצומת והשירות, מגבלות על תשלום בודד ומחזור יומי למשתמש, כללי בחירת מסלול וגובה העמלה.
- תרשים זרימות כספים — דיאגרמה של תנועת הכספים בין ארנקים, ערוצים ורזרבה, עם גבול מעגל המשמורת ורשימת מפתחות.
- מדיניות גישה ותפקידים — מטריצה: מי מוציא כספים, מי רק צופה, מי משנה קונפיגורציה; אישור שני לפעולות קריטיות.
- נוהל תגובה לתקלה — מה בודקים בעת אי-זמינות צומת, ניתוק ערוץ או עסקה תקועה, מה מפעילים מחדש ומתי מסלימים.
- תיעוד הסכימה — תיאור הארכיטקטורה, נקודות הכשל וסדר השחזור מגיבוי עם זמן פריסה מאומת.
- ניטור והתראות — ספים למאזן הערוצים, לעיכוב בתשלומים ולשיעור השגיאות; ההתראות נשלחות לערוץ תורנות, ולא לפרטי המהנדס.
מסיימים במפגש מסירה: הצוות שלכם משחזר את הצומת במעגל בדיקה במו ידיו, ומכאן ואילך ממשיך בתחזוקה באופן עצמאי.
מקרה בוחן: בוט מנויים עם גידול בתשלומים ללא קריעת ערוצים
מה היה לפני המעבר
בוט המנויים טיפל בכמה אלפי חידושים ביום, וכל תשלום עבר בערוץ נפרד עם מאזן משלו. בשעות שיא הנזילות התפזרה: שיעור התשלומים המוצלחים ירד ל-62%, חשבוניות פגו, וחלק מהערוצים הגיעו למצב שבו התשלום אינו עובר לשום כיוון. החיובים החוזרים לא היו אידמפוטנטיים — בעת timeout החידוש יצא בחשבונית שנייה, וההחזרים טופלו ידנית.
מה שינינו
הרכבנו סכימת משמורת: מאגר אחיד של ערוצים מנוהלים ואיזון מחדש לפי לוח זמנים, בתוספת טריגר בעת ירידת המאזן המקומי מתחת לסף. כל חידוש קיבל מזהה קבוע — ניסיון חוזר מחזיר את התוצאה של הראשון, ואינו יוצר חיוב חדש. בשעות שיא החידושים עוברים דרך תור עם הגבלת מקביליות, כדי שהזרימה לא תכלה את הנזילות של צומת אחד.
מדדים לפני ואחרי
- שיעור התשלומים המוצלחים: 62% → 96% ביום רגיל ולא פחות מ-94% בעומס שיא כפול מארבעה.
- חיובים חוזרים: 1.8% → 0.02% ממספר החידושים.
- שחזור לאחר כשל בצומת: מ-40 דקות של מיתוג ידני ל-3 דקות של העברה אוטומטית לגיבוי.
הסכימה עובדת על Lightning Network; העמידות בתקלות נשענת על אוטומציה, ולא על מהנדס תורן, — ולכן הגידול במספר המנויים אינו נתקע עוד בטיפול ידני.
מה לעשות אם הבוט כבר פעיל ונדרש קליטת תשלומים
בוט פעיל הוא זרימה מתמדת של בקשות ומסד נתונים חי, ולכן השדרוג של בוט קיים מתחיל לא בעריכת קוד, אלא בהפרדת מעגלים: קליטת התשלומים החדשה מוקמת לצד זו הקיימת וכותבת לאותן טבלאות, והתרחישים הנוכחיים ממשיכים להיות מטופלים.
הוספת תשלום לבוט אינה דורשת עצירה — המטפלים הישנים נשארים פעילים, בעוד החדשים עוברים בדיקה על פעולות אמת בהיקף מוגבל.
משתנה רק שכבת האישור: במקום השוואה ידנית מופיע צומת Lightning Network עם ערוצים, נזילות נכנסת וקישור האישור לחשבונית מסוימת. הלוגיקה של הבוט עצמו — פקודות, תפקידים, תפריטים, מתן גישה — נשארת כשהייתה, מפני שהיא אינה יודעת מהיכן הגיע האישור.
ההגירה ללא עצירת השירות מתבצעת בשלבים: תחילה הרחבת הסכימה עם תאימות לאחור (השדות החדשים אופציונליים, הקוד הישן מתעלם מהם), אחר כך מצב צל, שבו התשלום נקלט אך הזיכוי מושווה למנגנון הנוכחי, ורק לאחר התאמה — מיתוג. החזרה לאחור — הגדרה אחת שמחזירה את נתיב האישור הקודם.
התאימות למסד הנתונים הנוכחי תלויה בשאלה אחת: האם יש לכם מזהה פנימי של משתמש שאינו תלוי במסנג'ר. אם כן, התשלום נקשר אליו ישירות, ויומן הפעולות, שאליו רק מוסיפים רשומות, סוגר את ההשוואה ואת בירור אי-ההתאמות בשאילתה במקום קריאת לוגים.
בנפרד אנו מתכננים את חלק המשמורת: היכן נמצאים המפתחות, מי יוזם החזר, מה קורה בעת מחסור בנזילות נכנסת וכיצד הבוט מתנהג בעת אי-זמינות צומת. תרחישים אלה נבדקים לפני הפעלת הקליטה — אחרת התקלה הראשונה תקרה בדיוק בפעולה הגדולה הראשונה.
שאלות טכניות: נזילות, מפתחות, עמידות בתקלות
ספקות טכניים סביב בוט משמורת ב-Lightning Network מצטמצמים לגבול האחריות: מה השירות שולט בו, ומה נשאר בצד המשתמש. להלן תשובות לשאלות שצצות לרוב לפני תחילת הפיתוח.
מי אחראי לכספי המשתמשים?
מפתחות הצומת בשליטת השירות — כלומר האחריות לכספים שבו. חשבונאות הפעולות מנוהלת בנפרד ממצב הערוצים, המאזנים מושווים אוטומטית, ואי-התאמה חוסמת משיכה עד לבירור.
כיצד מוגנים המפתחות?
עיקר הכספים נמצא מחוץ למעגל החם, הצומת עובד עם יתרת תפעול מוגבלת. המפתחות אינם יוצאים מהסביבה המאובטחת, הגישה מופרדת לפי תפקידים ומתועדת בלוג.
מה קורה בעת אתחול מחדש של הצומת?
מצב הערוצים נשמר לדיסק, לאחר העלייה הצומת משחזר חיבורים ומשלים סנכרון. התשלומים בינתיים נכנסים לתור ויוצאים לאחר העלייה, כפילויות נמנעות לפי מזהה הפעולה.
מה לעשות בעת מחסור בנזילות?
נזילות נכנסת ויוצאת מתחלקת בין הערוצים; בעת הטיה מופעל איזון מחדש או נפתחים חדשים. הספים מתריעים מראש, וחלק מהתשלומים עוברים במסלול גיבוי.
האם ניתן להחליף את מודל ההחזקה?
מעבר להחזקת מפתחות עצמאית בידי המשתמש אפשרי, אך זוהי עיבוד מחדש של החשבונאות, הנפקת מפתחות והגירת ערוצים פעילים — אנו מתכננים זאת כשלב נפרד.
נדון במשימה: ננתח את הסכימה ונחזור עם הערכה
כדי לחזור עם הערכה ותוכנית עבודה, ולא עם טווח משוער «פחות או יותר», אנו זקוקים לנתוני קלט מהלקוח. הניתוח מתחיל בתרחישי התשלום: מי ממלא את היתרה, מה קורה בעת ניתוק הקשר וכיצד הבוט צריך להתנהג באותו רגע.
מהתשובות הללו נראה אילו חלקים מסכימת המשמורת מונחים על השרת, ואילו נשארים בצד הצומת של Lightning Network.
מה להכין לשיחה:
- תרחישי תשלום: קליטה, תשלום, העברה בין רשתות, פיצול סכום גדול לחלקים.
- היקפים: עומס שיא, מספר פעולות יומי, גידול צפוי, תשלום ממוצע ומקסימלי.
- דרישות להחזרים: מועדים, החזר חלקי, פעולות שנויות במחלוקת, אישור ידני בידי מנהל.
- תפקידי גישה: מי רואה יתרה, מי יוזם תשלום, האם נדרשים אישורים של גורם שני, כיצד מנוהל יומן פעולות.
- מגבלות תמיכה: מצב עבודה, זמן השבתה מותר, מי בצד הלקוח מגיב לתקלות.
- סדר מסירת הפרויקט: קוד מקור, תרשים תשתית, הוראות לתורן, הדרכת הצוות.
- תשתית נוכחית: צומת משלך או חיצוני, אילו אינטגרציות עם חשבונאות ודיווח הן חובה.
בהמשך נרכיב את הסכימה ונעריך את עלות העבודה לפי שלבים. אם חלק מהנתונים עדיין אינו ידוע, אנו מתעדים הנחות ובודקים אותן בשלב הראשון — כך הדרישות להחזרים וסדר מסירת הפרויקט לא יצוצו בהפתעה באמצע העבודה. תארו את המשימה בצורה נוחה, ונחזור עם תוכנית.