Tally governance: היכן נשברת ההצבעה ב-DAO
ההצבעה ב-DAO נשברת לא ביצירת ההצעה, אלא בספירה. Tally ו-Governor מחשבים את הקוורום לפי תמונת מצב של היתרות בבלוק שבו הוגשה ההצעה: אם האצלת ההצבעות בוצעה מאוחר יותר, הארנק עם הטוקנים אינו נכלל בקוורום. מבחוץ זה נראה כמו כישלון למרות תמיכה ברורה, וסף הקוורום נותר בלתי מושג למרות פעילות ערה בצ'אט.
סוג התקלות השני — הצעה תקועה. ההחלטה עברה, אך נותרה בתור עם השהיה: למולטיסיג התפעולי אין תפקיד לביצוע, סמכויות היוזם הוחלפו, ואין מי שיפעיל. הרשאות הביצוע התפזרו בין תפקידים, ולא ניתן להחזיר זאת במהירות בהצבעה חדשה — יש לעבור שוב קוורום ותור.
המחיר כאן אינו בעסקאות שהוצאו, אלא באמון: הקהילה רואה שההצבעה אינה הופכת לשינוי בפרוטוקול, ומפסיקה להשתתף. הפעילות יורדת, קשה עוד יותר לאסוף את הקוורום הבא, והממשל למעשה עובר למי שיש לו מספיק משקל.
כל שלושת התרחישים הם תוצאה של קונפיגורציה, ולא של טעויות המצביעים: השהיה, חלון ההצבעה, סף הגשת ההצעה ומטריצת התפקידים מוגדרים ב-Governor ולאחר ההשקה כמעט אינם נבחנים מחדש. נבחן היכן בדיוק נשברת ההצבעה ב-DAO וכיצד זה נפתר באמצעות הגדרה נכונה.
מה נותן מעגל הצבעה מנוהל ב-DAO
פרמטרי הממשל מוגדרים בעת פריסת חוזה Governor, ומכאן והלאה קובעים את התנהגות כל מערכת ההצבעה. סף הקוורום קובע כמה הצבעות יש להגיש כדי שהחלטה תיחשב כמאושרת, וסף הגשת ההצעה חוסם זרם של יוזמות ריקות.
השהיית הביצוע בין קבלת ההחלטה ליישומה מקנה למשתתפים זמן לצאת מהפרוטוקול או לערער על שינוי שנוי במחלוקת.
לוח Tally מרכז את הסטטוס של כל הצעה במקום אחד: כמה הצבעות "בעד" ו"נגד", מי האציל את זכות ההצבעה, ובאיזה בלוק נרשמה תמונת המצב של הזכויות. שקיפות התוצאות הופכת לניתנת לבדיקה, ולא להצהרתית — המספרים בממשק נבדקים מול נתוני הרשת באופן בלתי תלוי בו.
ההגנה מפני מניפולציות אינה נשענת על מנגנון אחד. תמונת המצב של זכויות ההצבעה בבלוק שלפני תחילת ההצבעה סוגרת את התרחיש של קניית קולות בכספים שאולים ממש לפני ההגשה. הקוורום מחושב מסך הטוקנים הכולל, ולא מההצבעות שהוגשו — תרחיש שבו החלטה מתקבלת בידי חלק קטן בעוד הרוב שותק מפסיק לעבוד.
גם מועד הביצוע של ההצעה הופך לכמות מנוהלת: החלון בין קבלה לביצוע מחייב מותאם לקצב הפרויקט — קצר לתיקונים תפעוליים, ארוך לשינויים הנוגעים לאוצר.
ההשתתפות בהצבעה גדלה לא משכנוע, אלא מהיכולת לחזות את הכללים: רואים מתי נסגרת קבלת ההצבעות, מתי ההחלטה תיכנס לתוקף וכיצד נבדקת התוצאה. מכאן ההשפעות המדידות — שיעור ההצעות שמגיעות לקוורום בלי הארכה, הזמן הממוצע מהגשה ועד ביצוע, מספר ההחלטות שעורערו.
שלוש גישות לאינטגרציה: פלטפורמה, חוזה עצמאי, היברידי
שלוש הגישות נבדלות בשאלה מי אחראי על ספירת ההצבעות ועל נקודת הכניסה למחזיקים. מעגל הצבעה מוכן — לדוגמה Tally — לוקח על עצמו את אינדוקס אירועי החוזה, רשימת ההצעות והיסטוריית ההצבעות: תהליך הממשל עובד מיד לאחר החיבור.
חוזה ממשל עצמאי נכתב לפי הלוגיקה שלכם — ספי קוורום, השהיית ביצוע, סדר הגשת ההצעות. תרחיש היברידי משאיר את החוזה אצלכם, בעוד התצוגה וההתראות מועברים לפלטפורמה.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| מעגל הצבעה מוכן | לוגיקת ההצבעה סטנדרטית, נדרשת השקה בזמן קצר | הממשק והמדדים מוגדרים בידי הפלטפורמה; סוגי הצעות לא סטנדרטיים ידרשו פיתוח נוסף |
| חוזה ממשל עצמאי | כללים מיוחדים: ספים מותאמים אישית, ביצוע דרך תור, מספר לשכות | את הממשק, אינדוקס האירועים והתמיכה מנהלתם בעצמכם |
| תרחיש היברידי | הלוגיקה שלכם כבר עובדת, נדרשת נקודת כניסה נוחה למחזיקים | יש לעקוב אחר התאמה בין החוזה לציפיות הפלטפורמה |
האצלת הצבעות נוגעת בכל שלוש האפשרויות: הפלטפורמה קוראת את רישום ההאצלה מהחוזה, לכן ודאו שהמשקלים מחושבים מחדש ברגע תמונת המצב, ולא ברגע הגשת ההצבעה.
ממשל רב-רשתי מוסיף מעגל שני — אם הצעות מבוצעות במספר רשתות, בחרו תרחיש עם קישור מפורש בין מזהה ההצעה לרשת, אחרת ההצבעות והתוצאות יתחילו להתערבב.
סדר היישום: מהביקורת ועד העברת הממשל
מערך הממשל נשבר לא בהצבעה, אלא בפרמטרים: סף הקוורום, השהיית הביצוע, הרשאות על האוצר. לכן היישום מתבצע במסלול של שישה שלבים — כל אחד נשען על קודמו ונבדק לפני שנכסים ייכנסו תחת ניהול החוזה.
- ביקורת מערך הממשל. בודקים כיצד מתקבלות החלטות כיום: מי מגיש הצעות, איזה סף קוורום קיים, היכן נמצא האוצר, ואילו תפקידים כבר הוענקו. התוצר — מפה של הפערים בין האופן שבו הקהילה מתארת את התהליך לבין מה שהקוד בפועל מבצע.
- עיצוב התפקידים. מפרקים את הסמכויות: מחבר ההצעות, המבצע עם השהיה, תפקיד הביטול, מנהל הפרמטרים. כל אחד מקבל הרשאות מינימליות מספיקות, ומפתחות המולטיסיג מתחלקים בין משתתפים שונים.
- הגדרת פרמטרי החוזה. סף ההגשה, הקוורום, תקופת ההצבעה, השהיית הביצוע, צעד השינוי — מתאימים לפעילות בפועל של הנציגים, ולא לוקחים ערכי תבנית.
- הצבעת מבחן. ברשת נפרדת מריצים מחזור מלא: הגשה, הצבעה, הכנסה לתור, ביצוע. בודקים את השגת הקוורום במספר הנציגים בפועל ואת תקינות הביטול של הצעה שנדחתה.
- העברת האוצר. מעבירים נכסים והרשאות ניהול לחוזה הממשל החדש, והגישה הישנה נסגרת. תחילה — חלק מפקח, והיתר לאחר ביצוע מאומת של הצעת המבחן.
- העברת הממשל. מסירים מפתחות טכניים, מוסרים את תפקיד המנהל למבנה הקהילתי הנבחר, ומקבעים את תקנון שינוי הפרמטרים והתיעוד. מכאן והלאה הפרמטרים גלויים ומשתנים דרך ממשק Tally בהצבעה, בלי מעורבות שלנו.
תוצרי היישום: קונפיגורציות, תרשימים, תקנונים
לאחר ההשקה כל הקונפיגורציה נשארת אצלכם במאגר הקוד, ולא בהתכתבות ולא בלוח בקרה של מישהו אחר. להלן רשימת מה שאנחנו מוסרים יחד עם הגישה וההסבר: לפיה הצוות יוכל לשנות פרמטרים בלי לשחזר את הלוגיקה לפי רמזים עקיפים.
- קבצי קונפיגורציה: סף הקוורום, תקופת ההצבעה, השהיית הביצוע — עם הערות מה כל ערך משנה ולאן מובילה הסטה לכל כיוון.
- מפת תפקידים והרשאות: מי מגיש, מי מבטל, מי מבצע, איזה תפקיד מוצמד למולטיסיג והיכן הגבול בין סמכויות מנהליות לתפעוליות.
- תקנון הגשה: סעיפי תיאור חובה, תקופת דיון מינימלית לפני תחילת ההצבעה, דרישות מהמקבל וסדר משיכת ההצעה.
- מדריך למשתתפים: חיבור ארנק, האצלת הצבעה, בדיקת סטטוס ההצעה, פעולות במקרה של עסקה שלא עברה.
- תוכנית התאוששות: ביטול הצעה כושלת, סדר פעולות במקרה של אובדן גישה למפתחות, העברת הרשאות בין מולטיסיגים.
- תרשים התהליך: המסלול מטיוטה ועד ביצוע ההחלטה שהתקבלה, עם נקודות מסומנות שבהן התערבות אנושית הכרחית.
- יומן שינויים: היכן מתועדות גרסאות הקונפיגורציה וכיצד לראות מי ומתי שינה את הספים.
את כל התוצרים בודקים ברשת מבחן לפני המסירה — הצוות מקבל לא תיאור, אלא קונפיגורציה עובדת.
מקרה בוחן: שיעור ההצעות הכושלות ירד פי שלושה
רשת המשתתפים גדלה, אך ההצבעה התנהלה בערוצים מפוזרים: חלק הצביעו בצ'אט, חלק שלחו עסקה ידנית, וחלק מהמחזיקים פשוט לא שמו לב להחלטות חדשות. שיעור ההצעות הכושלות עמד על כשליש — לא משום שהקהילה התנגדה, אלא משום שהקוורום לא הושג בזמן. הזמן עד להשגת הקוורום התארך לימים, והיוזמים משכו את הצעותיהם כדי לא לבזבז את תקופת ההצבעה לשווא.
מה שינינו בחוזה
הגדרנו את חוזה Governor בהתאם לקצב האמיתי של הקהילה: השהיה לפני תחילת ההצבעה, משך ההצבעה וסף הקוורום הותאמו לפעילות המחזיקים, ולא לערכי ברירת מחדל. ממשק Tally חובר לחוזה, כך שהקוורום הנוכחי, הסטטוס והזמן עד סוף ההצבעה נראים במקום אחד. המשתתף הפסיק לנחש כמה הצבעות חסרות, ויכל להאציל אותן במודע לפני שההצעה נשרפת.
שיעור ההצעות הכושלות ירד פי שלושה — מכשליש לערך לעשירית. הזמן עד להשגת הקוורום התקצר מימים ספורים לשעות: ההצעה כבר לא "נתלתה", משום שהמשתתפים נודעו על תחילת ההצבעה מיד. מספר ההחלטות שבוטלו ירד כמעט לאפס — היוזמים הפסיקו למשוך יוזמות מחשש שלא לאסוף מספיק קולות.
השארנו את יומן ההצבעות ואת פרמטרי הממשל פתוחים: כל משתתף בודק כיצד חושב הקוורום עבור כל הצעה. זה מסיר את המקור העיקרי למחלוקות בממשל — חוסר אמון בספירת ההצבעות.
במה נבדלת הצבעה פלטפורמית מחוזה עצמאי?
מעגל מוכן כמו Tally הוא תוספת מעל החוזה: השירות קורא את אירועי Governor, אוסף הצעות, בונה ממשק והיסטוריית הצבעות. החוזה עצמו נשאר מקור האמת, והפלטפורמה נותנת למשתתפים מסלול מוכר: לחבר ארנק, לראות הצעות פעילות, להצביע בקליק אחד. ההשקה אורכת ימים, אך את כללי ההצבעה קובעת התבנית, ולא אתם.
חוזה עצמאי הוא גמישות בהגדרת כללים ברמת הקוד. סף הקוורום, חלון ההצבעה, השהיית ההכנסה לביצוע, תרשים ההאצלה, זכות הביטול, סדר העדכון — הכול נכתב לפי מודל הממשל שלכם. אין צורך להתאים דבר לתבנית של אחרים, אך כל שינוי עובר דרך הליך ממשל — באחריותכם.
מכאן והלאה שני הבדלים מעשיים. עלות הפעולה של המשתתף: בפלטפורמה הוא משלם רק על עסקת ההצבעה עצמה, ובחוזה עצמאי אפשר לקצץ רשומות מיותרות באחסון, לאגד האצלות ולהוזיל את עלות ההצבעה ההמונית. מהירות השינויים: השירות מתעדכן לפי לוח הזמנים שלו, ואילו החוזה שלכם משתנה מתי שתצטרכו.
נושא נפרד — התלות בשירות. אם הממשק אינו זמין, ההצעות וההצבעות לא נעלמות לשום מקום: אפשר להגיש ולמשוך אותן בקריאות ישירות. אך עבור מחזיק טוקן מן השורה, היעלמות הממשק המוכר משמעה אובדן נוכחות, ונוכחות נמוכה שוברת את הקוורום. לכן לרוב בוחרים בהיברידי: כללים מוכחים מהתבנית המוכנה, והקריטיים — בחוזה עצמאי.
Tally governance: ספקות טכניים לפני היישום
לגבי Tally וחוזה Governor, הספקות מתעוררים לא ברמה של "עובד או לא", אלא ברמה של הגדרות עדינות. נבחן ארבע שאלות שעולות בעת התכנון: גורל הטוקנים שכבר הונפקו, הגבלת מעגל המצביעים, ביטול הצעה, השהיית ביצוע.
הטוקנים כבר חולקו — האם כתובת אחת לא תקבל שליטה מיד לאחר ההשקה?
המשקל מחושב לא לפי היתרה הנוכחית, אלא לפי תמונת מצב של המצב בבלוק נבחר. חלוקה לאחר תמונת המצב אינה משתתפת במחזור הנוכחי, והעברות בתוך אותו בלוק אינן מאפשרות להצביע פעמיים באותו נפח. אם ההתפלגות משתנה — היא משפיעה על המחזור הבא, ועל סף הקוורום יחד איתה.
כיצד להגביל את מעגל המצביעים?
דרך מודול גישה: רשימת כתובות, סף לפי יתרה או האצלת הצבעות. הכלל מקובע לפני ההצעה הראשונה — לשנותו בדיעבד לטובת קבוצה אחת גם יקר יותר, וגם בולט יותר לקהילה.
מי יכול לבטל הצעה ולשם מה נדרשת השהיית הביצוע?
זכות הביטול מופרדת לתפקיד נפרד — בדרך כלל לתרשים עם מספר חתימות, ולא למנהל אחד, ופועלת רק עד הביצוע. ההשהיה בין החלטה שהתקבלה ליישומה מוגדרת בנפרד: בחלון הזה המשתתפים מספיקים להגיב לפגיעה במפתח. הקוורום והסף נבחרים כך שהחלטות שגרתיות לא נתקעות, ומושמעות לא עוברות בקושי.
נבחן את מערך ההצבעה שלכם ונחזור עם הערכה
כדי שהביקורת של מערך ההצבעה והערכת העבודה יישענו על עובדות ולא על השערות, די לצרף לבקשה את הקונפיגורציה של מעגל הממשל. ממנה רואים אילו פרמטרים של Governor יהיה צורך לשנות, היכן יידרש העברת הרשאות, ומה באינטגרציה עם Tally ייקח את עיקר הזמן.
- הכתובת והגרסה של מופע Governor, הרשת, וכן סוגי ההצעות שבאמת עולות להצבעה;
- טוקן הממשל: תקן הרישום (ניתן להחלפה או ייחודי), האם האצלה מופעלת ומאיזה בלוק נרשם חיתוך המשקלים;
- הפרמטרים הנוכחיים: השהיית ההתחלה, משך ההצבעה, סף ההגשה, הקוורום, חלון הביצוע;
- מעגל הביצוע: מי מפעיל את ההחלטה — TimelockController או ארנק עם כמה חותמים;
- תרשים ההאצלה: רשימת הנציגים, דרישות לפרסומם, האם נדרשת ספירת הצבעות לפי כמה טוקנים בבת אחת;
- תפקידים וגישות: מי יכול לבטל הצעות, להשהות את הביצוע, לעדכן את המימוש;
- משאלות לגבי הלוח: הצבעה רק דרך Tally או עמוד הצעות משלכם עם היסטוריה והתראות.
בתגובה תקבלו תוכנית יישום לפי שלבים, הרכב העבודה עם גבולות אחריות, הערכה ולוחות זמנים, וכן רשימת סיכונים ונקודות נסיגה. תארו את המשימה — נחזור עם הערכה ותוכנית.