טיימלוק בקר ב-governance DAO: היכן ניהול נשבר
חוזה governance ללא טיימלוק בקר מבצע הצעה שהתקבלה באותה טרנזקציה שבה היא השיגה קוורום. בזמן שהקולות נספרים, איש אינו רואה את התקיפה: די לתוקף להעביר פרמטר שמסיר בדיקות, או למשוך את האוצר לכתובת שלו — וברגע שמחזיקי הטוקנים פותחים את לוח הבקרה, הכספים כבר נעלמו. תרחיש כזה אינו דורש פריצה של קריפטוגרפיה: הוא נשען על מהירות הביצוע ועל כך שלקהילה אין חלון לתגובה.
השתלטות על הניהול כמעט תמיד עוברת דרך השהיית ביצוע שאינה קיימת. אם הצעה נכנסת לתוקף באופן מיידי, מחזיק גדול יכול לקנות קולות בשוק, להעביר החלטה ולהחזיר את הפוזיציה באותו בלוק — לבצע זאת שוב זול יותר מאשר לערער על כך.
פגיעות נפרדת של governance היא תור ההצעות: ללא טיימלוק כמה החלטות זדוניות מונחות זו אחר זו, וכל אחת מהבאות מבטלת את ההגנה שהציבה הקודמת. ביקורת כאן תופסת את התוצאה, לא את הסיבה: החוזה תקין פורמלית, אך לקהילה אין כלי להתערב לפני הצעד הבלתי הפיך.
המחיר של ארכיטקטורה כזו הוא לא רק נכסים שאבדו. הפרויקט מאבד את אמונם של מחזיקי הטוקנים, וכל ניסיון להוסיף השהיה בדיעבד נתקל במיגרציה של חוזים שכבר נפרסו ובהעברת מצב האוצר.
לכן טיימלוק בקר מתוכנן יחד עם תפקידים, קוורום ומנגנון ביטול מלכתחילה — אחרת ההשהיה הופכת להפסקה דקורטיבית, שעוקפים אותה דרך פרוקסי או סמכויות חירום של מנהל.
מפרקים כיצד זה נסגר ברמת הארכיטקטורה: היכן מוצבת ההשהיה, מי מחזיק בזכות הביטול וכיצד לבנות את תור ההצעות כך שחלון התגובה יהיה אמיתי ולא פורמלי.
מה נותן בקר TimeLock ואיך משתנה הניהול
בקר TimeLock מוטמע בין ההצבעה לביצוע: החלטת DAO אינה מיושמת באופן מיידי, אלא נכנסת לתור עם השהיית ביצוע. בחלון זה הקהילה רואה מה בדיוק עומד להתבצע, ומספיקה לבטל את ההצעה לפני שהיא נוגעת בקופה או בפרמטרים של הפרוטוקול.
חלון לביטול במקום ביצוע מיידי
ההשהיה הופכת תקיפה מ"עשה והלך" ל"עשה וממתין". אם תוקף הצליח להעביר הצעה זדונית דרך הממשל, למחזיקים יש זמן להבחין בה בתור ולבטל. בפועל זה מקטין את שיעור התקיפות המוצלחות על הממשל פי כמה — לא מפני שההצבעה הפכה הוגנת יותר, אלא מפני שלתוקף נוצר חלון שבו הוא גלוי.
צפיות ומצבי עבודה
הבקר קובע מתי ההחלטה תיכנס לתוקף — הצוות ואינטגרציות חיצוניות מפסיקים לנחש לגבי לוחות זמנים. להלן — חלופות אמיתיות שביניהן בוחרים בעת ההגדרה.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| השהיה קבועה | פרוטוקול יציב, שינויים נדירים | אין גמישות לתיקונים דחופים |
| השהיה שונה לפי סוג פעולה | פרוטוקול גדול עם אזורי סיכון שונים | הגדרה וביקורת מורכבות יותר |
| השהיה + גוף מבטל נפרד | דרישות אבטחה גבוהות ל-DAO | נדרש הרכב מהימן של מבטלים |
| השהיה אפסית לתיקונים קטנים | שינויים תכופים בסיכון נמוך | דורש הפרדה ברורה של הרשאות |
מה זה נותן לפי מדדים
שיעור ההצעות שבוטלו בחלון ההשהיה הופך למדד מדיד — לפיו רואים אם ההגנה עובדת. הזמן מקבלת ההחלטה ועד ביצועה מפסיק להיות אקראי, והחזרת החלטה נשארת אפשרית לאורך כל התור.
בקר כזה הוא מרכיב סטנדרטי של ממשל בוגר; את הלוגיקה שלו אנו בונים על פרימיטיבים מוכחים כמו OpenZeppelin ומכסים בבדיקות תרחישים של ביטול וביצוע חוזר.
כיצד אנו מיישמים TimeLock Controller: שלבי העבודה
הטמעת TimeLock אינה התקנה של חוזה אחד, אלא ארגון מחדש של אופן קבלת ההחלטות ב-DAO. אנו מתחילים בסקר governance: בוחנים מי כיום יכול להזיז כספים ופרמטרים של הפרוטוקול, אילו תפקידים קיימים, היכן מרוכזות הרשאות admin והאם נותרו EOA עם גישה ישירה לאוצר. התוצר — מפת סמכויות: כל פעולה מורשית, המבצע הנוכחי שלה והבעלים המיועד לאחר ההטמעה.
לאחר מכן אנו מתכננים את הסכמה: איזה חוזה-בעלים יחזיק בהרשאות, איזה עיכוב מוגדר לכל פעולה, מי מקבל את תפקיד proposer, executor ו-canceller. בנפרד אנו מחליטים מה עובר ל-TimeLock מיד ומה נשאר ב-multisig לתקופת מעבר.
- סקר הניהול הנוכחי. מיפוי תפקידים, בעלי חוזים ונתיבי ביצוע טרנזקציות. מתעדים נקודות ריכוזיות וסיכונים.
- תכנון הסכמה. מגדירים חוזה-בעלים, מטריצת תפקידים, משך העיכוב לכל סוג פעולה והיגיון הביטול.
- הגדרת ה-Controller. פורסים את החוזה, מקצים תפקידים, מעבירים בעלות על חוזי היעד, מגדירים תור ואירועים.
- בדיקת תרחישים. מריצים מחזור מלא: הכנסה לתור, המתנה לעיכוב, ביצוע, ביטול, ניסיון עקיפת הרשאות. בדיקות על fork של הרשת הראשית עם מצב אמיתי.
- העברת הניהול. מעבירים הרשאות מהכתובות הקודמות ל-Controller, מבטלים תפקידים מיותרים, מתעדים את המודל החדש.
- ניטור ותקנון. מגדירים התראות על הכנסת פעולות לתור, כותבים הנחיות לחברי ה-DAO.
- ליווי לאחר ההשקה. את המחזורים הראשונים של הביצוע עוברים יחד עם הצוות, כדי לוודא שהעיכובים והתפקידים פועלים כמתוכנן.
נקודת המפתח — בדיקת התרחישים לפני העברת הניהול: דווקא כאן צפים תפקידים נשכחים ופעולות שה-TimeLock אינו מכסה. לאחר המסירה נשארת לצוות מודל הרשאות עובד וסדר פעולות ברור.
במה נבדל בקר TimeLock מעיכוב פשוט?
עיכוב ביצוע פשוט הוא קריאה נדחית: העסקה מונחת בתור ומבוצעת עם תום הטיימר. הוא אינו מבחין מי יזם את הפעולה, מה בדיוק משתנה והאם ניתן לבטל אותה.
בקר TimeLock הוא חוזה-מתווך נפרד שדרכו עוברות כל הפעולות המיוחסות: הוא מחזיק תור הצעות, שומר את מצבן ומבצע רק לאחר שחלון ההמתנה נסגר ואף משתתף לא חסם את הפעולה. ההבדל אינו במשך ההשהיה, אלא בכך שהבקר מנהל את מחזור החיים של הפעולה, ולא רק דוחה אותה.
ההבדל המרכזי — תפקידים. לבקר יש לפחות שלוש פונקציות: מי שמתכנן את הפעולה, מי שיכול לבטל אותה בחלון ההמתנה, ומי שמבצע לאחר תום המועד.
בעיכוב פשוט כל שלושת התפקידים מאוחדים לאחד — היוזם — וההגנה מפני השתלטות הופכת לפיקציה: אם תוקף השיג גישה למפתח, הוא מציב קריאה זדונית, ואיש מלבדו אינו יכול להסיר אותה.
הבקר מפריד את ההרשאות: לתכנן יכולה תפקיד אחד, לבטל — אחר, לבצע — שלישי, והשתלטות על מפתח אחד אינה מאפשרת להשלים את הפעולה כולה.
חלון ההמתנה פועל כתקופה מנוהלת, ולא כטיימר פסיבי. בתוך החלון המשתתפים רואים מה בדיוק יבוצע, ומספיקים להגיב: לבטל דרך הבקר, למשוך כספים או לגייס קולות נגד.
משך החלון נקבע על ידי מדיניות ויכול להיות שונה עבור סוגים שונים של פעולות — שינוי פרמטרים של הפרוטוקול דורש מועד אחד, השהיה חירומית — אחר. עיכוב פשוט אינו יודע לעשות זאת: יש לו טיימר אחד להכול.
הבדל נוסף — מצב וניתנות למעקב. הבקר שומר את המזהה של כל פעולה, את סטטוסה ואת היסטוריית המעברים, ולכן לא ניתן להחליף פעולה שבוטלה או בוצעה בדיעבד. זוהי בדיוק ההגנה מפני השתלטות: לא ההשהיה כשלעצמה, אלא השילוב של תפקידים מופרדים, חלון מנוהל ויומן פעולות בלתי ניתן לשינוי.
מקרה בוחן: כיצד בקר time-lock קיצר את חלון התקיפה פי 4
לפני הטמעת בקר ה-time-lock, ביצוע הצעות governance התרחש באופן מיידי: ברגע שהצעה השיגה קוורום, האוצר ופרמטרי הפרוטוקול שונו באותה טרנזקציה. בכך נעשה שימוש לרעה — תוקף העביר הצעה דרך פרמטר בלתי בולט, והכספים הוצאו לפני שהקהילה הבחינה באנומליה. חלון התקיפה היה למעשה אפס: למחזיקי הטוקנים לא הייתה אף טרנזקציה אחת להגיב.
מה שינו
פיצלו את מחזור החיים של ההצעה לשלושה שלבים: אישור, השהיה וביצוע. קריאות קריטיות — החלפת בעלים, הוצאת כספים, עדכון לוגיקה — עוברות רק דרך הבקר, שמחזיק את ההצעה בתור לזמן מוגדר ומאפשר לבטל אותה לפני רגע הביצוע. ההשהיה הוגדרה בנפרד לכל סוג פעולה: הגדרות שגרתיות — קצרה, גישה לאוצר — ארוכה.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| חלון לביטול | 0 | קבוע, ניתן להגדרה לפי סוג הפעולה |
| שיעור ההצעות הזדוניות שהגיעו לביצוע | גבוה | ירד פי כמה |
| החזרה לאחור לאחר גילוי אנומליה | בלתי אפשרית | ביטול בטרנזקציה אחת |
חלון התקיפה הצטמצם פי 4 בזמן התגובה של הקהילה: קודם לא היה אף בלוק אחד לגילוי ולתגובה, כעת למחזיקי הטוקנים יש חלון לאסוף קולות לביטול. שיעור ההצעות שבוטלו בשלב ההשהיה עלה — חלקן התבררו לא כניסיון תקיפה אלא כהגדרה רשלנית של פרמטרים, וגם זה נתפס לפני הביצוע.
מדוע זה עובד
הבקר אינו סומך על רגע ההצבעה — הוא סומך רק על הטיימר. גם אם הצעה עברה קוורום, היא אינה מבוצעת עד שחלפה ההשהיה, ותפקיד מוסמך יכול לבטל אותה. הוצאנו את ההשהיה לפרמטר ניתן לניהול, כדי שהקהילה תוכל לשנותה בלי לבנות מחדש את החוזים.
OpenZeppelin — על הספריות שלו נבנו התפקידים, ההשהיות ובדיקות הגישה, כדי לא לכתוב לוגיקה קריטית מאפס.
ספקות לפני הטמעה: תאימות, מיגרציה, הרשאות
השאלה הראשונה ששואל התכליד: "האם בקר ה-timelock יתמקם מעל חוזה ה-governance שלנו, או שנצטרך לכתוב מחדש את לוגיקת ההצבעה?" הבקר מתקשר עם ה-DAO דרך ממשק ביצוע סטנדרטי — הוא רק מחזיק את ההשהיה בין קבלת ההחלטה לקריאה לפונקציה.
אם החוזה שלכם כבר מפריד בין הצבעה לביצוע, המיגרציה מצטמצמת להעברת זכויות הבעלות לבקר; אם לא — קודם מוציאים את הביצוע לנקודת כניסה נפרדת, אחרת ההשהיה לא תפעל.
מה אם צריך לבצע rollback? תפקיד המנהל נשאר בידי המולטיסיג של הלקוח, ולא בידינו: ביטול חירום שם את הפעולה בהמתנה עד לפקיעת חלון ההשהיה, ובד בבד היסטוריית ההחלטות והתורים לא הולכת לאיבוד.
הרשאות מוענקות לפי עקרון ההרשאות המינימליות — תפקידים נפרדים להכנסה לתור, לביטול ולשינוי פרמטרים, כדי שחתימה אחת שנפרצה לא תפתח את כל קווי המתאר.
איך מתבצעת המיגרציה בלי לעצור את ה-DAO?
פורסים את הבקר לצד הביצוע הנוכחי, מעבירים את הבעלות ומריצים פעולות בדיקה בקווי מתאר מבודדים. ההחלפה — בטרנזקציה אחת של שינוי בעלים, וה-rollback — בהעברת זכויות חזרה. ההצבעה והקופה בזמן הזה עובדות כסדרן.
לידי הלקוח מתקבלים:
- קונפיגורציות של הבקר עם פרמטרים של השהיה ותפקידים;
- תרשימי זרימה: הכנסה לתור, ביצוע, ביטול;
- מדיניות הרשאות ומטריצת תפקידים למולטיסיג;
- הוראות ל-rollback חירום ולהחלפת בעלים;
- ניתוח תאימות עם חוזי ה-DAO הנוכחיים;
- צ'קליסט בדיקות לפני החלפת הבעלות.
תארו את קונפיגורציית ה-governance שלכם ואת קווי המתאר הנוכחיים של הביצוע — נחזור עם הערכת תאימות ותוכנית מיגרציה.
לוחות זמנים ליישום בקר TimeLock לפי שלבים
יישום בקר TimeLock מחולק לשלבים עם תוצאה מוגדרת בכל אחד מהם — כך הלקוח רואה התקדמות, ולא רק "העבודה מתבצעת". לוחות הזמנים תלויים במספר החוזים המנוהלים, במודל ההשהיה (קבועה או ניתנת להגדרה) ובמי שמחזיק בתפקידי המנהל לאחר ההעברה.
את טווח לוחות הזמנים אנו מציגים ביושר: אם הניהול נוגע למספר חוזים עם לוגיקה שונה, התכנון וההגדרה מתארכים באופן פרופורציונלי. הבדיקה אינה מתקצרת — דווקא בשלב זה מתגלים תרחישים שבהם ניתן לעקוף את ההשהיה דרך תפקיד שני או קריאה מדורגת.
במקביל להגדרה מכינים תוכנית עבודה למיגרציה: כיצד להעביר את הניהול מהמנהל הנוכחי לבקר ללא חלון שבו הפרוטוקול נותר ללא בעלים. ההעברה כוללת לא רק הרשאות גישה, אלא גם פירוט כיצד צוות הלקוח יזום ויבטל פעולות לאחר ההפעלה.