פיתוח לוח וסטינג לצוות ולמשקיעים

מדוע חוזה חכם של וסטינג לא שורד את השחרור הראשון

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

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

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

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

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

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

מה משתנה כשהקוד מחשב את ההקצאות

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

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

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

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

חוזה חכם של וסטינג, החזקה בנאמנות או תשלומים ידניים

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

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

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

סדר ההטמעה: מביקורת לוחות זמנים ועד מסירה

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

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

מה נשאר לצוות לאחר מסירת העבודות

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

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

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

מקרה בוחן: חלוקות טוקנים הועברו לכללים אוטומטיים

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

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

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

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

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

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

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

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

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

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

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

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

שאלות שנויות במחלוקת לפני תחילת החלוקה

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

בידי מי נשארות זכויות המנהל?

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

כיצד להעביר את החלוקה לגרסה חדשה של החוזה בלי לאבד את ההיסטוריה?

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

במה מאושרת אבטחת החוזה החכם?

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

מה יקרה אם משתתף לא משך טוקנים בזמן?

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

נדון בסכימת ההקצאות שלכם

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

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

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

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