פיתוח חוזים חכמים ל-governance עבור DAO

פיתוח governance לחוזים חכמים: היכן נשבר הממשל

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

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

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

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

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

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

אפקט מדיד: מהירות ההחלטות ויציבות הקופה

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

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

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

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

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

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

פורמטים של ממשל: ריבוי-חתימות, היברידי, הצבעה על השרשרת

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

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

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

שלבי הטמעת governance: מביקורת ועד מסירה

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

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

לאחר המסירה נשארת בידיכם מערכת עובדת ונוהל שינויים ברור — בלי תלות בצוות שלנו בהחלטות היומיומיות.

ערכת מסירה: קונפיגורציות, סכמות תפקידים, נהלים

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

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

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

מקרה בוחן: בנייה מחדש של ממשל הקופה וההצבעה

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

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

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

מדדים לפני ואחרי

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

במה שונה ריבוי-חתימות מהצבעה על השרשרת?

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

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

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

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

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

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

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

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

כיצד החוזה מוגן מפני השתלטות על הקולות?

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

מה לעשות עם אובדן המפתחות של משתתף?

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

האם ביקורת חוזים חיצונית היא חובה?

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

האם אפשר לשנות את פרמטרי ההצבעה?

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

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

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

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

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

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

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