פיתוח Safe{Wallet} Plugin: מודולים מותאמים, הוקים ואינטגרציות

פלאגין Safe Wallet מותאם אישית: איפה נשברות אינטגרציות מוכנות

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

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

סוג התקלות השני הוא חוסר סנכרון בין יומנים. פלאגינים מוכנים קוראים מצב ממקור אחד ואינם משווים את מונה הפעולות לסטטוס הביצוע ברשת; בעת עיכוב באינדוקס נשארת במסד נתונים טרנזקציה "מאושרת" שלא קיימת ברשת. בדוחות זה צף רק אחרי שהפעולה כבר שוכפלה.

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

לכן פיתוח של פלאגין Safe Wallet מתחיל לא בקוד, אלא במודל: אילו פעולות מתבצעות ללא מעורבות אדם, אילו דורשות סף, מי ומה רואה ביומן. מודולים מותאמים אישית לריבוי חתימות נבנים סביב המודל הזה — חוקים, מגבלות, ביקורת של כל ביצוע וחזרה צפויה לאחור במקרה של דחייה.

מה נותן מודול Safe Wallet עצמאי לריבוי חתימות

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

Guard בודק את הפעולה לפני הכנסתה לתור ודוחה כל מה שחורג מהמדיניות — החותמים לא מבזבזים זמן על איסוף אישורים לפעולה שממילא לא תעבור.

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

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

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

דרכים להרחיב את הארנק: מודול, הוק או שירות חיצוני

הדרכים להרחיב את הארנק Safe{Wallet} אינן תחליפיות זו לזו, והבחירה ביניהן קובעת לא את נוחות הפיתוח, אלא את המקום שבו הלוגיקה צריכה לחיות. מודול מטמיע את החוק בתוך החשבון החכם ומבוצע ברגע הבדיקה והביצוע של הפעולה. הוק נרשם לאירוע ומגיב לו מבלי להתערב בזרימה עצמה. שירות חיצוני-מבצע עושה את העבודה מחוץ לשרשרת ופונה לארנק לפי טריגר.

השוואה לפי תחומי התאמה ומגבלות

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

שלבי פיתוח והטמעת המודול: מהסכימה ועד למסירה

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

1. ביקורת של סכימת החתימה. מנתחים את התצורה הנוכחית של ריבוי החתימות Safe{Wallet}: בעלים, סף, מודולים והוקים פעילים, קשרים עם פרוטוקולים חיצוניים. בפלט — מפה שבה המודול החדש ישתלב מבלי להחליש את ההגנה.
2. תכנון. מגדירים את גבולות המודול: אילו פעולות הוא מאציל, היכן הוא בודק הרשאות, כיצד הוא מתנהג בעת כשל בקריאה חיצונית. בנפרד מתארים את החזרה לאחור ואת ההתנהגות כאשר אין מניין חתימות מלא.
3. מימוש. כותבים את חוזה המודול ואת החלקים המסייעים, מכסים את ההסתעפויות בבדיקות. מוודאים שהמודול אינו יכול להוציא כספים תוך עקיפת הסף.
4. בדיקות אינטגרציה בסביבת בדיקה. פורסים עותק של תצורת הלקוח ומריצים תרחישים: קריאה שגרתית, כשל של מערכת חיצונית, חתימה חוזרת, שלילת הרשאות.
5. בדיקה בלתי תלויה. ניתוח קוד וסימולציה של התקפות: החלפת נמען, עקיפת הוקים, שימוש חוזר בחתימה. את ההערות סוגרים לפני ההטמעה.
6. הטמעת הפלאגין בסביבת העבודה. מחברים את המודול בשלבים, החל ממגבלת פעולות מצומצמת, ועוקבים אחר מדדי ביצוע החתימות.
7. העברת הרשאות גישה וליווי. מוסרים סכימות, הנחיות והרשאות לצוות שלכם, עוברים על נהלי העדכון ונשארים בקשר בכל הנוגע לאירועים.

מה מועבר לידיים שלכם: תצורות, סכימות, נהלים

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

• סכימות ותצורות של המודול: ספי חתימה, מגבלות על פעולות, רשימות נמענים וטוקנים מורשים — כקבצים תחת בקרת גרסאות, ולא כהגדרות "בווב" בלי היסטוריית שינויים.
• סכימות של זרימות חתימה: המסלול מאתחול הטרנזקציה ועד לאישור הסופי, עם נקודות החיבור של מודולים, הוקים ובדיקות אבטחה בכל שלב.
• מדיניות גישה ותפקידים: מי מציע טרנזקציות, מי חותם, מי משנה את הסף ומכבה מודולים; הפרדה בין קו ניהולי לקו שירותי.
• תיעוד האינטגרציה: פורמטים של קריאות, קודי שגיאה ותגובות אליהם, מגבלות של כל הוק, דוגמאות לשירותים סמוכים.
• נהלי תפעול: בדיקה תקופתית של תקינות, עדכון מודולים, סבב מפתחות, בקרת מצב וניתוח אירועים.
• נהלי חזרה לאחור: כיצד להחזיר את התצורה הקודמת, לכבות את המודול בלי לעצור את הארנק ולשחזר את גישת החותמים.
• הנחיות לצוות: הדרכה בסביבת בדיקה חיה, שבה כל מהנדס מבצע בעצמו הגדרה, עדכון וחזרה לאחור.

לאחר המסירה אנחנו מלווים את השינויים הראשונים: רואים כיצד הצוות שלכם מבצע פעולות שגרתיות.

מקרה בוחן: צמצמנו אישורים ידניים והסרנו סוג תקלות

בגזברות על Safe{Wallet} שישה חותמים, וכל תשלום עבר איסוף ידני: הכינו את הטרנזקציה, הפיצו אותה לחותמים, חיכו לאישורים, ביצעו. הזמן הממוצע מהבקשה ועד הביצוע — כ-40 דקות, ובימי תשלומים הגיע למספר שעות.

מה שינו במודול

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

מדדים לפני ואחרי: זמן ביצוע תשלום בטווח הסף — מ-40 דקות ל-2-3 דקות; שיעור הפעולות ללא אישור ידני — 82% לעומת אפס קודם לכן; אישורים ידניים ביום תשלומים — 9-12 במקום 60+.

סוג הכשל "אושר אך לא בוצע" הפסיק לחזור על עצמו: המודול או מביא את הפעולה למצב סופי, או מחזיר אותה באופן מפורש לתור.

אירוע מנותח לפי יומן האירועים בדקות, ולא לפי התכתבות במסנג'ר במשך חצי יום. ספי המגבלות וכללי התור נמצאים בתצורת המודול — משנים אותם בלי לקמפל מחדש את החוזים.

במה נבדל מודול מותאם אישית משירות חיצוני-חותם?

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

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

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

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

ספקות טכניים: מגבלות, חזרה לאחור, תאימות

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

עד כמה רחבות ההרשאות שמוענקות למודול מותאם אישית?

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

מה יקרה בעת עדכון הארנק או החלפת החותמים?

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

כיצד מבצעים חזרה לאחור של השינויים אם הלוגיקה לא התאימה?

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

נדבר על המשימה: מה נדרש כדי לחזור עם הערכה ותוכנית

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

• סכימת חתימה: סף האישורים והרכב בעלי הכספת, אילו התקנים משתתפים בחתימה, האם יש ארנקים חומרתיים.
• תפקידים והרשאות: מי יוזם את הפעולה, מי מאשר, מי מבצע; האם נדרש מבצע תוכנתי ובאילו הרשאות.
• תרחישי ביצוע: מה בדיוק עושה המודול — תשלומים מרוכזים, פעולות נדחות, אוטומציה לפי אירוע, בקרת מגבלות.
• כללי אבטחה: אילו פעולות חייבות להיחסם, את מי אסור לכלול ברשימת הנמענים, היכן נדרשת בקרה ידנית.
• נקודות חיבור: עם אילו שירותים שלכם ומערכות חיצוניות המודול מחליף נתונים וכיצד מאושרת תוצאת הפעולה.
• סביבה: באיזו רשת אתם פועלים, האם יש סביבת בדיקה נפרדת, האם נדרשת בדיקה חיצונית של קוד החוזים.
• מה כבר קיים: כתובות של חוזים פרוסים, גישה למאגר הקוד, תיעוד, מפתחות בדיקה.
• לוחות זמנים: לאיזה תאריך נדרש מודול עובד ומה קריטי במסירה הראשונה, ומה אפשר להעביר לשנייה.

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