כתיבת מסמך לבן: היכן נשברת הלוגיקה של פרויקט בלוקצ'יין
אנחנו מרכיבים תמונה שאנחנו רואים לרוב: פרקים מגיעים ממקורות שונים — תיאור שיווקי של המוצר, טיוטת כלכלה מהמייסד, מזכר טכני מהמהנדסים, ובנפרד מצגת למשקיעים. כל קטע בנפרד נקרא משכנע, אבל יחד הם מתארים פרויקטים שונים: במסמך אחד הטוקן דרוש לגישה, באחר — לתגמול, בשלישי — להצבעה.
זה נשבר בשאלה עניינית ראשונה. איך מחושב התגמול כשפעילות יורדת? מה קורה לכספים נעולים כשותף יוצא? מי ובאיזה בסיס משנה את פרמטרי המערכת?
אם התשובה צריכה להיות מורכבת משלושה קבצים, והיא עדיין לא מתיישבת, בדיקה טכנית מצד משקיע או שותף נעצרת — לא בגלל רעיון חלש, אלא בגלל לוגיקה לא מגובשת.
לכן כתיבת מסמך לבן מתחילה לא בטקסט, אלא במודל: אנחנו מתארים תפקידים של משתתפים, זרימות ערך, מצבי מערכת ותרחישי קצה, ומצליבים אותם עם אב-טיפוס והלוגיקה של החוזים.
רק אחרי זה מרכיבים את המבנה של המסמך הלבן — מוצר ובעיה, ארכיטקטורה ותפקידי רכיבים, מכניקה כלכלית, אבטחה וממשל, מפת דרכים וסיכונים.
כך המסמך הטכני של פרויקט בלוקצ'יין נעשה ניתן לבדיקה: כל טענה נגזרת מהמכניקה, לא מהמצגת, ומאומתת בחישוב, בתרשים או בהפניה למימוש. בהמשך אותו ליבה עובר להכנת מסמך למשקיעים — בלי לכתוב מחדש לכל קהל ובלי סתירות בין גרסאות.
בהמשך נפרק היכן בדיוק הולכת לאיבוד הלוגיקה של הפרויקט ואיך אנחנו משחזרים אותה לפני שהמסמך יוצא לקורא חיצוני.
מה נותן מסמך מעובד לצוות ולמשקיעים
מסמך מעובד נכתב כבסיס טכני של הפרויקט, לא כדי לצאת ידי חובה, — וזה חוסך את היקר ביותר: זמן של מהנדסים ועורכי דין על הסברים.
כשמודל הטוקן, זכויות המחזיקים והלוגיקה של חוזים חכמים מעוגנים בטקסט אחד, שאלות הבהרה בנושאים האלה כמעט נעלמות: התשובה נמצאת בפרק מסוים, לא בראש של מישהו אחר.
את שלד הטקסט הזה קבע עוד Bitcoin — תיאור הבעיה, המכניקה, הכלכלה והסיכונים. את הסדר הזה אנחנו שומרים בכל פרויקט: הוא מכריח את הצוות לענות על שאלות לא נוחות לפני שהמשקיע שואל אותן.
עבודה נפרדת היא תיאום טרמינולוגיה. בפרויקטי בלוקצ'יין אותן מילים מתכוונות לדברים שונים: "הנפקה" אצל מפתח ואצל עורך דין — ישויות שונות, "אנלוק" מתבלבל עם חלק, "קסטודיאלי" מתפרש כל אחד לפי דרכו.
אנחנו מקבעים הגדרות פעם אחת במילון מונחים, ומכאן והלאה פיתוח ועורכי דין קוראים את אותן נוסחאות, ולא מתווכחים על פרשנויות בכל שיחת זום.
תיעוד לסבב גיוס משקיעים עובד כמסנן ראשון: אנליסט ויועץ טכני של הקרן בודקים לפיו את לכידות המודל, חלוקת הזכויות והסיכונים. אם הפרקים מתיישבים זה עם זה, גל הדיונים הראשון מסתיים במספר תיקונים קטן פי 2-3 — הגרסה לא נכתבת מחדש אחרי כל שיחה, אלא מתווספת.
עבור הצוות האפקט לא פחות: מפתח או עורך דין חדש נכנס לפרויקט לפי המסמך, לא לפי סיפורים. זה מוריד באופן ניכר את מספר שאלות ההבהרה ואת עלות הכניסה לפרויקט — ושומר על כולם באותה טרמינולוגיה מהטיוטה הראשונה ועד לשחרור.
פורמטים של מסמך: מרעיון ועד מפרט טכני
פורמט המסמך נקבע לא לפי נפח, אלא לפי איזו החלטה מתקבלת לפיו. משקיע מחפש את לוגיקת הכלכלה, מהנדס — מודל נתונים וסדר חתימת פעולות, פלטפורמת הנפקה — הוכחות למימושיות. קובץ אחד לא סוגר את התפקידים האלה.
לפני הבחירה מקבעים את הקורא ואת השאלה שהוא צריך לסגור אחרי הקריאה: מכאן גם מחושב הנפח.
| פורמט | מתי מתאים | מגבלות |
|---|---|---|
| תמצית רעיון הפרויקט | מגע ראשון עם משקיע או שותף: להסביר את המשימה, תפקיד הטוקן ומודל ההכנסה | לא חושף ארכיטקטורה — בבדיקה טכנית נשארות שאלות בלי תשובה |
| גרסה מורחבת של מסמך לבן | הנפקה, ביקורת, גיוס: כלכלה, חלוקת חלקים, לוח זמנים של שלבים | אי-התאמה בין הלוגיקה המתוארת לכללים המיושמים — סיבה נפוצה לסירוב של פלטפורמות |
| מפרט טכני | פיתוח וביקורת: סכמות נתונים, כללי הנפקה, טיפול בכשלים, דרישות למפתחות | מיותר לקורא חיצוני ומכיל פרטים שלא כדאי לפרסם |
הפורמטים יורשים זה מזה: התמצית קובעת את המסגרת, המסמך הלבן פורש אותה לטענות ניתנות לבדיקה, המפרט מקבע את מה שהצוות מתחייב ליישם. אם הגרסה הציבורית לא תואמת את המפרט, מתקנים את המסמך, ולא משאירים סתירה.
את הנפח גם מתאימים לערוץ: תמצית שומרים בטווח 8–12 עמודים, כדי שיקראו אותה כולה, גרסה ציבורית — פחות מארבעים, מפרט — בלי גבול עליון, קוראים אותו באופן סלקטיבי לפי פרקים. ננתח איזה סט מסמכים דרוש לפרויקט שלכם.
שלבי כתיבת מסמך לבן: מביקורת ועד מסירה
סדר העבודות מקבעים לפני ההתחלה: המסמך נבנה לא מטקסט מוכן, אלא מבסיס טכני מאומת. לכן השלבים הראשונים — איסוף והצלבת עובדות, ורק אחר כך ניסוחים. בכל שלב רואים מה כבר נעשה ואיזה נתונים עוד דרושים מצוות הפרויקט.
- ביקורת חומרי הפרויקט. מפרקים מאגרי קוד, תיאור כלכלת הטוקן, סכמות חלוקה, מצגות, התכתבות עם שותפים. מסמנים סתירות ומקומות שבהם המספרים לא מתיישבים זה עם זה.
- ראיונות עם הצוות. מבהירים תפקידים, מבנה המערכת, מגבלות ותוכנית התפתחות. שם גם סוגרים פערים שאי אפשר לברר מהמסמכים.
- סכמת לוגיקת המסמך. לפני הטקסט מרכיבים שלד: פרקים, סדר הטיעונים, מה מוכח בכל אחד. זה זול באופן ניכר מתיקונים בפרקים שכבר נכתבו.
- הרכבת הטקסט. כותבים לפי השלד, שומרים על מילון מונחים אחיד וסימונים זהים בכל חלקי המסמך.
- בדיקת חיבורים. מצליבים מספרים, הגדרות וטענות בין הפרקים — הגרסה בחלק הכלכלי חייבת להתאים לטכנית.
- מסירה סופית לצוות. מוסרים קבצי מקור בפורמט ניתן לעריכה, מבנה, מילון מונחים ורשימת נתונים שכדאי לעדכן בהמשך התפתחות הפרויקט.
כך המסמך נשאר חי: הצוות יכול לערוך אותו בעצמו, בלי לאבד את הלוגיקה ובלי לשבור קשרים בין פרקים.
מה כלול בחבילה: תרשימים, מודלים, נהלים
מסמך ציבורי של פרויקט הוא לא רק טקסט. אנחנו מוסרים חבילה שלפיה צוות הנדסה, עורכי דין ומשקיעים קוראים את אותה תמונה: המסמך עצמו, תרשימי ארכיטקטורה, תיאור המודל הכלכלי וכללי עבודה עם הטקסט בהמשך. להלן מה בדיוק נכלל באספקה.
- טקסט המסמך — מהצגת המשימה ותפקידי המשתתפים ועד לוגיקת הקונסנזוס, מסלול העסקה והגבולות שמהם המערכת לא יוצאת.
- תרשימי ארכיטקטורת הפרויקט — שכבות הרשת, תפקידי הצמתים, זרימות נתונים ונקודות חיבור לשירותים חיצוניים; הכיתובים בתרשימים תואמים למונחים בטקסט.
- תיאור המודל — כללי הנפקה ומחזור, חלוקת זכויות, תנאי שינוי פרמטרים והשלכות על התחייבויות שכבר הונפקו.
- מטריצת תפקידים והרשאות — מי יוזם פעולה, מי מאשר, מי רשאי לבטל אותה.
- מילון מונחים — למונח אחד יש משמעות אחת בכל הפרקים, בלי מילים נרדפות "לפי הטעם".
- נוהל עדכון המסמך — מי מבצע תיקונים, באיזו תדירות נעשית סקירה, איך משנים מסונכרנים ועל ידי מי מאושרים.
- סדר גרסאות — מספור מהדורות, יומן שינויים וארכיון של גרסאות מאושרות קודמות עם אפשרות לחזור לכל אחת.
- נספחים — חישובי המודל, מקורות נתונים ושאלות פתוחות עם אחראי לכל אחת.
קבצי מקור מוסרים בפורמט ניתן לעריכה יחד עם הגרסה המסונכרנת, כדי שאפשר יהיה לפתח את המסמך בלעדינו. בנפרד מקבעים צ'ק-ליסט אי-התאמות: אם אחרי תיקונים התרשים הפסיק להתאים לטקסט המודל, זה נראה לפני פרסום, לא אחרי.
מקרה בוחן: עיבוד מחדש של מסמך לפני סבב דיונים
לפני העיבוד מחדש
הצוות הגיע עם מסמך לבן שכבר נאסף: הלוגיקה הטכנית של הפרוטוקול מתוארת בפירוט, אבל חלוקת הטוקנים, זכויות המחזיקים וסדר השחרור היו מרוחים על פני הטקסט. על ניתוח ראשוני של החומרים משקיעים בזבזו עד שבועיים, ולכל פגישה הביאו את אותה רשימת שאלות — מהנפקה ועד מי ואיך יכול לשנות כללים.
את העיבוד מחדש התחילו לא מהטקסט, אלא ממפת שאלות: אספו יותר משלושים הבהרות כתובות מהתכתבויות עם קרנות ופרשו אותן לפי פרקים. מודל החלוקה הוציאו לבלוק נפרד עם טבלת חלקים וגרף שחרור, לצדו תיארו תפקידים בממשל וספים לקבלת החלטות.
המכניקה הכלכלית כווצה לשלושה תרחישים במקום תיאור מרוח, והלוגיקה של חוזים חכמים ב-Solidity — להתנהגות: מה קורה במשיכה מוקדמת ובשינוי פרמטרים.
אחרי העיבוד מחדש
ההבהרות הכתובות הצטמצמו לשש במקום שלושים ומשהו, ואלה שאלות על תנאי סבב מסוים, לא על מבנה הפרויקט. הקטגוריה "הסבירו את המכניקה הבסיסית" נעלמה לגמרי — עליה עונה הפרק עם הגרף והטבלה.
הזמן לניתוח ראשוני של החומרים הצטמצם משבועיים לשניים-שלושה ימים, והצוות הפסיק לחזור על אותו דבר בכל פגישה.
במקביל קיבעו גרסאות של המסמך: מהדורת משקיעים, נספח טכני ותמצית של שני עמודים למגע ראשון. מכאן המסמך עובד כמקור אמת — תיקונים בטוקנומיקה או בתפקידים מוכנסים במקום אחד ולא מתפזרים בין מצגות.
במה שונה מסמך קונספט מתיעוד טכני
מסמך קונספט, או מסמך לבן, ותיעוד טכני עונים על שאלות שונות ונקראים על ידי אנשים שונים. הראשון מסביר למה הפרויקט קיים ולמה המכניקה שלו עובדת; השני — איך הכל מורכב ומה לעשות כשיש תקלה. לערבב אותם לטקסט אחד זה או להרתיע את הקורא בפרטים, או להשאיר את הצוות בלי תיעוד עבודה.
לחלק הציבורי נכנסים הצגת הבעיה, עקרונות הפעולה של הפרוטוקול, תפקידי המשתתפים, כללים כלכליים וגבולות אמון: מה מובטח בקוד ומה נשען על הסכמים ארגוניים.
כאן גם מפרטים את הסיכונים שנותרו — טענות ניתנות לבדיקה משכנעות יותר מהבטחות רועשות, כי הקורא יכול לפתוח את הרשת ולהשוות את הנטען למצב בפועל.
החלק הסגור — זה תיעוד פנימי של הפרויקט: מפרטי חוזים, מודל איומים, נהלי הנפקה וחזרה מגרסאות, סדר עבודה עם מפתחות והרשאות גישה. החומרים האלה מועברים למבקרים ולשותפים לפי הסכם סודיות, אבל לא מפורסמים: לקורא הם לא מוסיפים אמון, ולמי שמחפש נקודת תקיפה הם עוזרים ישירות.
גבולות חשיפת המידע נקבעים לפי כלל פשוט: מפרסמים את מה שממילא ניתן לבדוק ברשת, שומרים את מה שנותן יתרון לתוקף. שתיקה סבירה לא מערערת אמון, אם היא מוצהרת במפורש, — מערערת אותו אי-התאמה בין הבטחה לקוד. לכן בפרק נפרד מקבעים מה הועבר למעגל הפנימי ולמה: זה מסיר שאלות לפני שהן הופכות לטענות.
ספקות טכניים שכדאי להסיר לפני ההתחלה
המסמך כמעט תמיד מוכן לפני שפרמטרי הרשת, כלכלת הטוקן ומודל הממשל מעוגנים. לכן שאלות בשלב הזה — לא על עיצוב, אלא על איך לתאר החלטה שעדיין אין, ומה לעשות עם המסמך בהמשך.
אנחנו עונים עליהן לפני תחילת העבודה: זה מסיר כתיבה מחדש של פרקים בשלב שבו הטקסט כבר מסונכרן עם כל הצדדים.
מי כותב את המסמך — מהנדסי הפרויקט או המחבר?
עובד שילוב: המהנדסים שלכם נותנים את החומר — ארכיטקטורה, מנגנון קונסנזוס, כלכלה, והמחבר מתרגם אותו למבנה ולניסוח בהיר. פרקים על הפרוטוקול והטוקנומיקה לא ניתן לכתוב מבחוץ, אבל את לוגיקת הסיפור כדאי להוציא מחוץ לצוות. כך המסמך נשאר מדויק ובו בזמן קריא למשקיע ולמבקר.
חלק מההחלטות עדיין לא מעוגנות — מה לכתוב בפרקים האלה?
אנחנו מסמנים מקומות כאלה כמקדמיים: מציינים טווח עבודה, ממה תלוי הבחירה הסופית ולפי איזה קריטריון היא מתקבלת. זה הוגן יותר מאשר לנחש, ולא מכריח לכתוב מחדש את המסמך אחרי כל שינוי במודל. כשההחלטה מתקבלת, הפרק מתוקן נקודתית, בלי הרכבה מחדש של המבנה.
איך המסמך מתעדכן אחרי השקת הרשת?
המבנה נבנה מראש כניתן להרחבה: פרמטרים מספריים מנוהלים בבלוקים נפרדים, כדי שאפשר יהיה לשנות אותם ללא תלות בתיאור הארכיטקטורה. לעדכון חוזרים לפי יציאת גרסאות חדשות של הפרוטוקול, והיסטוריית השינויים מנוהלת בתוך הקובץ עצמו.
עד כמה החומרים הנמסרים חסויים?
תרשימים, חישובים כלכליים וחלקים בארכיטקטורה שטרם הושקו נשארים תחת הסכם סודיות, גישה — רק למהנדסים שעובדים על המסמך. טיוטות לא מפורסמות ולא מועברות לצדדים שלישיים, ובסיום העבודה אפשר להגביל גם את שמירת ההעתקים שלנו.
נדון במשימה ונחזור עם תוכנית עבודה
כדי לדון במשימה באופן ענייני, לא צריך מסמך מוכן עם תיאור של עשרות עמודים — מספיקים נתוני פתיחה שמהם נראים מהות הפרויקט וגבולות הטקסט העתידי. את השאר מבהירים בשיחה, לא בהתכתבות של שבועיים.
- רעיון הפרויקט ב-5–10 משפטים: איזו משימה המוצר פותר, למי נועד ומה כבר עובד;
- מצב נוכחי: האם יש אב-טיפוס, קוד, חישובי כלכלה או שעדיין רק קונספט;
- קהל המסמך — משקיעים, שותפים, רגולטור או קהילה טכנית: ממנו תלוי עומק הפרקים ושפת הניסוח;
- מה כבר נכתב: טיוטות, מצגות, הערות פנימיות — ניקח אותן כחומר מקור, לא יהיה צורך לספר מחדש;
- דרישות הפלטפורמה או הלקוח שלפיהן מכינים את המסמך: פרקים חובה, נפח, שפה, פורמט הגשה;
- מועד רצוי ונקודות שבהן דרוש אישור שלכם במהלך העבודה.
מנתוני הפתיחה האלה אנחנו בונים תוכנית עבודה על המסמך: מבנה הפרקים, מי מהמהנדסים והאנליסטים מוביל כל בלוק, סדר אישורים, מועד. בתוכנית מיד רואים איזה נתונים כבר יש לכם ואיזה יהיה צריך לאסוף — את זה מבררים בשיחת הזום הראשונה. מוסרים קבצי מקור של העימוד, כדי שאפשר יהיה לערוך ולעדכן את המסמך בכוחות עצמכם.
תארו את המשימה בצורה חופשית — נחזור עם הערכה ותוכנית ונאמר מה לקחת לעבודה ראשון.