פיתוח לוטריה על בלוקצ'יין: היכן נשבר הגרלה הוגנת
הלוטריה נשברת לא במחולל המספרים, אלא במפגש של שלושה מעגלים: קליטת הימורים, קביעת הזוכה ותשלום הפרס. כל עוד כל השלושה חיים במעגל ניהולי אחד של המפעיל, החלפת תוצאת ההגרלה אינה מותירה עקבות — כרטיסים מתוקנים במסד הנתונים, ההגרלה מחושבת מחדש, והלוגים מנוקים. המשתתף לא יכול להוכיח לא את עצם הרכישה ולא את המספר שנבחר.
צוואר הבקבוק השני — אקראיות ניתנת לחיזוי. אם התוצאה נלקחת מזמן השרת, ממספר הסבב או מערך הבלוק הקודם, שחקן עם גישה לזרם העסקאות מחשב את הצירוף הזוכה מראש ולוקח את סבבי הפרסים.
זה נסגר באמצעות סכימה דו-שלבית: התחייבות עם האש מפורסמת לפני תחילת המכירות, הערך עצמו נחשף רק לאחר סגירת קליטת הכרטיסים, ואף המפעיל או המשתתף לא יכולים לראות את המספר קודם לכן.
נקודת הכשל השלישית — אישור ידני של התשלום. כאשר אדם עם ארנק יחיד שם חתימה על העברה, הפרס יוצא באיחור או לא יוצא כלל, וקרן הפרסים עומדת ללא תנועה עד להחלטה של מישהו. חוזה שמעביר את הזכייה עם אירוע של סבב שהסתיים מסיר את הצעד הידני ומבטל את שאלת האמון במנהל.
הרביעי — מחלוקת על תוצאת ההגרלה. כל עוד היסטוריית ההימורים והתוצאות נשמרות אצל המפעיל, אין למי לערער: הצדדים מציגים דוחות שונים, והבירור הופך להתכתבות בלי בורר.
סט אירועים ציבורי בתוספת חישוב מחדש דטרמיניסטי מזרע קבוע נותנים לכל משתתף אפשרות לבדוק את ההגרלה בעצמו ולשחזר את התוצאה.
פיתוח לוטריה על בלוקצ'יין הוא בדיוק על כך שכל אחד מהכשלים האלה ייסגר ברמת הארכיטקטורה, ולא ברמת התקנון. נסביר איך זה בנוי.
מה נותנת הגרלה הוגנת: השפעה על המפעיל והשחקנים
המפעיל מפסיד לא בקרן הפרסים, אלא בשלושה תחומים: תשלום, בדיקת סבב ובדיקה ידנית. להלן מה בדיוק משתנה כאשר את ההגרלה מחשב חוזה חכם, ולא המפעיל.
תשלום: דקות במקום יממות
סבב ידני הוא בדיקת רשימת הזוכים, אימות פרטי התשלום והרצת תשלום נפרדת. החוזה שומר את קרן הפרסים בפתיחת הסבב ומוציא את הזכייה באותה עסקה שבה הוא מתעד את התוצאה. תשלום אוטומטי לזוכה אורך דקות, ולא את יום העבודה הבא, והמפעיל לא צריך להחזיק כספים עבור העברות תקועות.
בדיקת הסבב: כל צד מחשב מחדש בעצמו
מקור האקראיות וההאש של רשימת הכרטיסים נרשמים לפני סגירת המכירות — אי אפשר להתאים את התוצאה בדיעבד. השחקן מחשב מחדש את הסבב לפי היומן הפתוח ומקבל את אותו מספר זוכה כמו המפעיל. בדיקה ציבורית של הסבב מפסיקה להיות שירות אמון והופכת לאריתמטיקה שזמינה לכל משתתף.
פעולות ידניות וסוג המחלוקות
הזנת כרטיסים, בדיקה, תשלום ודיווח עוברים לחוזה ולניטור — עד 90% מהפעולות יוצאות מהמצב הידני. יחד איתן נעלם סוג שלם של כשלים: תשלום כפול, העברה לפרטי תשלום שגויים, אי-התאמה בין דוח פנימי להעברות בפועל. מחלוקת על התוצאה נסגרת בקישור לעסקה ב-Ethereum, ולא בהתכתבות עם שירות התמיכה.
השוואת מודלי הגרלה: רשת, שרת והיבריד
מודל ההגרלה קובע היכן חי הכרטיס, היכן מתועדת התוצאה ומי יכול להתערב בתהליך לאחר תחילת הסבב. בפועל הבחירה מצטמצמת לשלוש סכימות: כולו ברשת, שרת ריכוזי עם פרסום התוצאות, והיבריד.
המגבלה העיקרית של הגרלה ברשת — עמלת עסקה ברשת: כל הימור וכל תשלום עולים כסף וזמן לאישור. כאשר יש אלפי משתתפים, הסבב נתקע דווקא בעמלה הזו ובהשהיית האישור, ולא בעוצמת השרת. לכן סבבים תכופים כמעט תמיד עוברים לסכימה היברידית.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| כולו ברשת | שקיפות קריטית, הימורים נדירים | מהירות ועלות הפעולה תלויות בעומס הרשת, סבבים המוניים נחנקים |
| שרת עם פרסום תוצאות | דרושים סבבים תכופים ומכניקה מורכבת | יכולת הבדיקה חלשה יותר: המשתתף לא יכול לחשב את הסבב בעצמו |
| סכימה היברידית לסבב | הימורים ותשלומים ברשת, עריכת הסבב בשרת | נדרשת תיעוד נכון של הקשר בין השרת לרשת, אחרת אי אפשר לבדוק הוגנות |
לכל לוטריה אנו מחשבים פרופיל עומס: הימורים בשעה, תשלומים לסבב, השהיה מותרת, עומק יכולת הבדיקה מצד המשתתף. לפיו אנו בוחרים מודל — לפעמים סבבים מהירים ואיטיים בתוך אותה לוטריה עובדים לפי סכימות שונות, וזה מוטמע בארכיטקטורה כבר מלכתחילה.
שלבי העבודה: מביקורת כללים ועד קבלת ההגרלה
השלבים בנויים כך שכל החלטה נבדקת עד לרגע שבו היא הופכת לחלק מהחוזה. כללי הסבב, תנועת קרן הפרסים ומקור האקראיות מתעדים בכתב: אם הנוסחה לא מסתדרת על הנייר, בקוד היא על אחת כמה וכמה לא תסתדר.
- ביקורת כללי ההגרלה. מפרקים את התקנון: התנהגות במכירת כרטיסים חלקית, התאמת מספרים, פרס שלא נפדה. הפלט — רשימת מצבי קצה וניסוחים חד-משמעיים שהופכים אחר כך לבדיקות.
- מודל חלוקת קרן הפרסים. מתארים את תנועת הכספים מההימור ועד התשלום, את תפקיד הרזרבה וההעברות האוטומטיות. מחשבים כמה פעולות יש לסבב אחד והיכן נדרש בירור ידני.
- מימוש לוגיקת הסבב, הכרטיסים והתשלומים. את הלוגיקה מחלקים למודולים כדי לשנות כללים בלי לכתוב מחדש את חלק החישוב, ומכסים בבדיקות תרחישי קצה.
- בדיקת מקור האקראיות. את הצירוף מתעדים מראש וחושפים לאחר הסבב: לא המארגן ולא השחקן יכולים להשפיע על התוצאה או להתאים אותה בדיעבד. המשתתף מחשב את הזכייה בעצמו.
- הרצות עומס. בודקים רכישה המונית של כרטיסים בבלוק אחד ומוצאים את המקומות שבהם העיבוד מתחיל לפגר. המטרה — אישור צפוי ללא תור לסבב.
- מסירה והדרכה. מוסרים מערכת פרוסה, דיאגרמות, הרשאות והוראות למפעיל: הפעלת סבב, השהיה, עצירה חירום, בירור ידני של מצב שנוי במחלוקת.
ערכת האספקה: חוזים, דיאגרמות, תקנונים
הפרויקט סגור לא כאשר החוזה נפרס ברשת הראשית, אלא כאשר אתם יכולים לתחזק אותו בלעדינו. לכן את ערכת האספקה של הפרויקט מרכיבים כך שאף צומת במערכת לא יישען על הידע של הקבלן: קוד, דיאגרמות, מדיניות ותקנונים עוברים למאגר שלכם עם היסטוריית שינויים.
- קוד מקור ובנייה: חוזי הלוטריה, סקריפטים לפריסה ולמיגרציות, קונפיגורציות סביבה, הוראות לשחזור הבנייה מאפס.
- דיאגרמות אינטראקציה: זרימות רכישת כרטיס, תיעוד סבב, יצירת אקראיות ותשלום, בנפרד — מודל נתונים ואינדוקס אירועים לדיווח.
- הפרדת הרשאות גישה: מטריצת תפקידים — מנהל, מפעיל, מבקר, תמיכה — עם רשימת פעולות מותרות ואיסורים מפורשים; פעולות קריטיות סגורות בחתימה מרובה ובהשהיית ביצוע.
- תקנון תפעול: לוח סבבים, סדרי השהיה וחידוש, נוהל שינוי פרמטרים, תרחישי תקלה וזמן תגובה יעד.
- הוראות לשירות התמיכה: טיפול בפניות טיפוסיות — התשלום לא הגיע, העסקה ממתינה — וכיצד לבדוק סטטוס לפי האש בסייר הבלוקים.
- מתודולוגיה לבדיקת הוגנות: כיצד לחשב מחדש באופן בלתי תלוי את תוצאת הסבב, אילו נתונים נדרשים לכך וכיצד להכין דוח לשחקנים.
מוסרים הרשאות, מקימים את הסביבה שלכם ומקיימים בירור של תרחישי תקלה. לאחר מכן תיעוד הלוטריה מספיק כדי שהצוות ימשיך לפתח בכוחות עצמו או עם קבלן אחר בלי הנדסה לאחור.
מקרה בוחן: סבב עם בדיקה ציבורית של התוצאות
מפעיל הגרלות עם קהל של עשרות אלפי משתתפים ערך סבבים על מחולל מספרים אקראיים בשרת. את התוצאה לא ניתן היה לחשב מחדש מבחוץ, ומצבים שנויים במחלוקת טופלו ידנית: הוציאו לוגים, בדקו תשלומים, כתבו למשתתפים הסברים. מתוך שנים עשר סבבים, שישה הסתיימו בדרישה "תוכיחו שהזכייה הוגנת".
מה הועבר לחוזה
הסבב עבר לחוזה חכם: הוא מקבל תשלום, מתעד את הרכב המשתתפים וסוגר את קליטת ההימורים בבלוק מוגדר. מקור האקראיות — אורקל חיצוני Chainlink: מספר ניתן לאימות נרשם לשרשרת בעסקה נפרדת, וכל משתתף מחשב מחדש את הזוכה בסייר בלוקים ציבורי. כתובת מקור האקראיות מפורסמת לפני תחילת המכירות, ולא ניתן להחליף אותה לאחר סגירת קליטת ההימורים.
| מדד | לפני | אחרי |
|---|---|---|
| זמן תשלום לזוכה | 3–5 ימי עבודה, ידנית | דקות לאחר אישור העסקה |
| שיעור הסבבים עם פעולות ידניות | כ-40% | אחוזים בודדים — אימות החוזה |
| סבבים שנויים במחלוקת | 6 מתוך 12 | אפס לאורך כל זמן הפעילות |
| עומס שיא במכירות | הפעלה מחדש של הסבב | ההגרלה אינה תלויה בעומס |
בנפרד נעלם סוג כשלים שקשור לשיא המכירות. בעבר זרימת משתתפים בשעות האחרונות שברה את סדר הרישומים ביומן, והיה צריך להפעיל מחדש את הסבב. כעת התוצאה תלויה רק במקור האקראיות המעודכן ובנתוני הבלוק, ולכן זינוק ברכישות אינו משפיע על מהלך ההגרלה.
שלושה חודשים לאחר ההשקה הבירורים הידניים פסקו: לוגיקת התשלום מתוארת בחוזה, וטענה נבדקת בחישוב מחדש, ולא בהתכתבות. את אותו מעגל אנו מרכיבים כמפתח — עם בדיקה בלתי תלויה של קוד החוזה והוראה ציבורית לאימות הסבב.
כיצד להשתכנע שהלוטריה על בלוקצ'יין הוגנת?
הוגנות ההגרלה נשענת על סכימת "התחייבות — חשיפה". לפני הסבב המפעיל מפרסם בבלוקצ'יין האש של מספר סודי ואת הכללים עצמם: כמה כרטיסים, כיצד הם ממוספרים, לפי איזו נוסחה נבחר המספר הזוכה. הסוד נשאר סגור — נראה רק טביעת האצבע שלו.
אי אפשר להחליף את הכללים או את המספר לאחר הפרסום: הרשומה בלתי ניתנת לשינוי, ורגע הופעתה מאושר על ידי הרשת.
לאחר הסבב המפעיל חושף את המספר הסודי. כל אחד לוקח אותו, מחשב האש ומשווה לזה שפורסם קודם — ההתאמה היא ההוכחה לתוצאת הסבב. אם טביעות האצבע לא תואמות, ההחלפה נראית באופן ציבורי, ולא רק בבדיקה פנימית של המפעיל.
בדיקה עצמאית של השחקן נשענת על כך שרשימת הכרטיסים נמצאת בחוזה חכם ברשת Ethereum ומתועדת לפני ההגרלה. הזוכה מחושב באופן דטרמיניסטי מהמספר הנחשף ומהרשימה הזו: השחקן מציב את אותם נתונים באותה נוסחה ומקבל את אותה תוצאה. אין צורך בגישה למערכות הפנימיות של המפעיל — האמון מוחלף בחישוב שניתן לשחזר.
בנפרד נסגרה שאלת שמירת הסוד. חלון החשיפה נקבע מראש; אם המפעיל לא עמד בו, החוזה מחשיב את הסבב כלא-תקף ומחזיר את ההימורים למשתתפים. השתיקה הופכת ללא משתלמת, ולמצוא מספר אחר תחת טביעת האצבע שכבר פורסמה אינו אפשרי מבחינה חישובית — לא למפעיל ולא לנו.
שאלות טכניות לפני ההתחלה: אקראיות, מפתחות, תקלות
לפני תיעוד הארכיטקטורה כדאי לסגור חמש התפצלויות הנדסיות: מהיכן מגיעה האקראיות, מי מחזיק במפתחות, כיצד משתנים הכללים, מה קורה כאשר הרשת עמוסה וכיצד מבררים הגרלה שנויה במחלוקת. להלן תשובות מעשיות לכל אחת.
מהיכן מגיע המספר האקראי והאם אפשר לסמוך עליו?
מקור אקראיות אחד תמיד פגיע: המפעיל חוסם אותו — וחוזה את התוצאה. לכן התוצאה נאספת מכמה תרומות בלתי תלויות, והערך מפורסם לפני התשלומים. כל משתתף יכול לחשב מחדש את התוצאה לפי הנתונים השמורים ולהשתכנע שהחלפה אינה אפשרית.
היכן נשמרים המפתחות ומה יקרה אם אחד מהם יאבד?
מפתח פרטי לא נמצא בקוד ולא תלוי בשרת אחד. החתימה נאספת לפי סכימת סף מכמה חלקים אצל מחזיקים שונים, ואובדן חלק אחד אינו מפסיק את התשלומים. מפתח נפרד אחראי רק על השהיית חירום ואינו נותן זכות לשנות סכומים.
האם אפשר לשנות את כללי הלוטריה לאחר ההתחלה?
סיכויים, מגבלות וסדר התשלומים מוציאים לפרמטרים ואינם נכתבים מחדש בדיעבד עבור סבב שכבר מתקיים. גרסה חדשה נכנסת לתוקף רק מהסבב הבא, ובין ההודעה לכניסה לתוקף יש חלון שבו המשתתפים רואים את השינוי.
מה לעשות אם הרשת עמוסה והעסקה תקועה?
עומס הרשת משתנה, האישור מתארך, וחלק מהפעולות נתקעות בתור. התהליך מחולק לשלבים: רישום הכרטיס נקלט מיד, התשלום ממתין לאישור, ובמקרה של תקיעה — חזרה על אותה פעולה עם אותו מזהה או החזר לפי פסק זמן. צומת איטי אחד אינו עוצר את ההגרלה כולה.
כיצד מבררים מצב שנוי במחלוקת?
התוצאה דטרמיניסטית מהמספר שפורסם, ולכן המחלוקת נפתרת לפי רשומות ויומנים, ולא לפי הזיכרון של המפעיל. למקרה כזה יש השהיית חירום עם בירור ידני וסדר מתואר מראש: מי מקבל החלטה, באיזה מועד וכיצד זה משתקף בדיווח.
נדון במשימה: כללים, סכימת בדיקה, תוכנית עבודה
לפני שאנו נוקבים בתאריכים, אנו מפרקים את הלוטריה כמערכת: מהיכן מגיעה האקראיות, מי ומתי מתעד את ההימורים, כיצד השחקן משתכנע שהזכייה נקבעה ביושר ולא סובבה על ידי מנהל. בירור כזה אורך פגישה אחת וקובע את תוכנית העבודה לפרויקט — בלעדיו כל הערכה הופכת לניחוש.
- מקור האקראיות — מה משמש כאנטרופיה להגרלה, כיצד השחקן עצמו תורם לה ומה יקרה אם המקור לא יהיה זמין ברגע הסבב.
- סכימת בדיקת הסבב — אילו נתונים נכנסים לשרשרת לפני סגירת קליטת ההימורים, אילו אחרי, וכיצד משתתף בלתי תלוי חוזר על החישוב ומקבל את אותה תוצאה.
- גבולות העבודה — בנפרד מפרטים מה נכנס לשלב הראשון, ומה נשאר מחוץ למסגרת ומוערך בנפרד: תשלומים, אינטגרציות חיצוניות, מעטפת משפטית.
- תפקידים והרשאות — מי מפרסם את הכללים, מי יכול לעצור את הסבב, אילו פעולות נרשמות ביומן ונשארות גלויות לנצח.
- תשלומים וכרטיסים שנויים במחלוקת — תרחישים שבהם הפעולה לא עוברת, כיצד מטופל קונפליקט ומה רואה השחקן באותו רגע.
- קבלה — אילו בדיקות ברשת הבדיקות צריך לעבור מחזור סבב מלא לפני שנמסור לכם את המערכת.
נחזור עם הערכה ותוכנית: חלוקה לשלבים, הרכב הצוות, נקודות שבהן נדרשת ההחלטה שלכם. תארו את המשימה — פורמט ההגרלה, מספר המשתתפים, דרישות הרגולטור — ונדון בה בצורה עניינית.