חוזי טיימלוק: OpenZeppelin ופתרונות מותאמים עם ביקורת

פיתוח חוזי טיימלוק: היכן נשברת לוגיקת הנעילה

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

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

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

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

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

מה נותן הטיימלוק לניהול הקופה ולווסטינג

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

לוח זמנים של תשלומים במקום הסכמות בעל פה

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

נעילה אוטומטית של נכסים מסירה פעולות ידניות

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

הצלבת מצב — דקות במקום ימי עבודה

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

סוג התקלות "שולם למי שלא צריך ובזמן הלא נכון" נסגר

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

אפשרויות מימוש: ספרייה מוכנה, לוגיקה מותאמת אישית, היברידי

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

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

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

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

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

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

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

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

הרכב האספקה: קוד, סכמות נעילה, תיעוד

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

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

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

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

לפני: תשלומים ידניים ומפתח אחד

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

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

אחרי: לוח זמנים ומגבלות בחוזה

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

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

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

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

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

ריבוי חתימות סוגר איום אחר — החלטה בידי אדם אחד. סף «M מתוך N» פירושו שהפעולה תקפה רק באיסוף אישורים מבעלי מפתחות שונים, ולכן גניבה או אובדן של התקן אחד אינם פותחים גישה לכספים.

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

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

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

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

התלבטויות בנוגע ללוגיקת הנעילה: ביקורת, עדכון, גישה

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

האם אפשר לשנות את לוח הזמנים לאחר ההשקה?

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

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

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

החוזה ניתן לעדכון או שאינו ניתן לשינוי?

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

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

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

נדון במשימה: נבנה סכמת נעילה ותוכנית עבודה

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

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

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